RFC 7954

Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block

📅 published September 2016, from ietf

Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block ✨

okay bestie, this one is literally the IPv6 address block for LISP 🎀 It was written by L. Iannone, D. Lewis, D. Meyer and V. Fuller, and it's an Experimental document, so it's not a Standards Track spec 🧪 It was published in September 2016 as RFC 7954 📅 It doesn't obsolete or update any other RFCs 💅

Here's the vibe: IANA gets told to hand out a /32 IPv6 prefix for LISP, and that prefix is meant for local routing inside a site and for globally identifying endpoints 🦋

Status of This Memo 🌸

Okay so this is NOT a standards track thing 🙈 It's published so people can look at it, try it out in experiments, and evaluate it 🧪

It's still an Experimental Protocol for the Internet community, and it's an IETF product 🫶 It has public review and it's been approved by the IESG, but being approved doesn't mean it's automatically a candidate for any Internet Standard level. (Check Section 2 of RFC 7841 for that part 💜)

If you want the latest status, errata, or feedback info, the page is http://www.rfc-editor.org/info/rfc7954 🔥

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. 💖

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as in effect on the publication date. Read these carefully, because they spell out your rights and restrictions for this document 📜 Any Code Components pulled out of this doc have to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, per the Simplified BSD License 🌈

Table of Contents 🧚

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Definition of Terms . . . . . . . . . . . . . . . . . . . . .   3
3.  Rationale and Intent  . . . . . . . . . . . . . . . . . . . .   3
4.  Expected Use  . . . . . . . . . . . . . . . . . . . . . . . .   5
5.  Block Dimension . . . . . . . . . . . . . . . . . . . . . . .   5
6.  3+3 Allocation Plan . . . . . . . . . . . . . . . . . . . . .   6
7.  Allocation Lifetime . . . . . . . . . . . . . . . . . . . . .   7
8.  Routing Considerations  . . . . . . . . . . . . . . . . . . .   7
9.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
  11.1.  Normative References . . . . . . . . . . . . . . . . . .   9
  11.2.  Informative References . . . . . . . . . . . . . . . . .  10
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  11
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

Abstract 💜

Here's the TL;DR 👑 IANA is being asked to allocate a /32 IPv6 prefix for LISP. It'll be used for local intra-domain routing and for global endpoint identification, by sites that deploy LISP as their Endpoint Identifier (EID) addressing space ✨

1. Introduction 🦋

Okay so this doc tells IANA to allocate a /32 IPv6 prefix for LISP, which is the Locator/ID Separation Protocol [RFC6830] 💖 It also covers the LISP Map-Server [RFC6833], LISP Alternative Topology (LISP+ALT) [RFC6836], and LISP Interworking [RFC6832], plus other mapping systems too 🌸

This block is going to be used as global Endpoint Identifier (EID) space 🫶

2. Definition of Terms 🎀

No new terms are introduced here, bestie 💅 The doc just relies on the whole set of LISP specs ([RFC6830], [RFC6831], [RFC6832], [RFC6833], [RFC6834], [RFC6835], [RFC6836], [RFC6837]), and it assumes you already know the LISP terminology 🧠 If you don't, [LISP-INTRO] gives you an intro to the tech, terms and all 📚

3. Rationale and Intent 🌈

So the LISP working group talked it through and found a bunch of situations where having a LISP-specific address block is actually useful 🔥 Here are the biggest ones:

Early LISP destination detection: 🔍 Right now there's no direct way to tell if a destination is in a LISP domain without doing a LISP mapping lookup 🙈 An Ingress Tunnel Router (ITR) sends packets to every kind of destination (non-LISP ones, LISP ones outside the IPv6 EID block, and LISP ones inside it). The only way to know whether to encapsulate is to check the cache and, on a LISP cache miss, send a Map-Request to the mapping system. While it waits for the Map-Reply, packets may get dropped to avoid excessive buffering 😭

Avoid penalizing non-LISP traffic: 💜 Sometimes you'd want a router running LISP features to natively forward every packet whose destination isn't in the block. That means no lookup at all, and packets going to non-LISP sites don't get penalized in any way ✨

Traffic Engineering: 🚦 Some deployments want different traffic-engineering policies for LISP and non-LISP traffic 🦋 A LISP-specific EID block would make that easier. LISP traffic could be identified without Deep Packet Inspection (DPI), which means you wouldn't need to parse the encapsulated packet. A simple look at the outer header is enough 💅

Transition Mechanism: 🌸 A LISP-specific EID block could be handy during transition. A non-LISP domain could ask for an allocation from the LISP EID block and use it to deploy LISP in its network. That allocation wouldn't be announced in the BGP routing infrastructure (see Section 4) 🙈 This lets non-LISP domains avoid chopping up their already-allocated non-LISP space, which could inflate the BGP routing table, since that space may (rightfully) be announced in BGP 📈

Limit the impact on the BGP routing infrastructure: 🍑 Following on from the last one, LISP adopters won't have to fragment their address space, because fragmenting would hurt the BGP routing infrastructure 😬 Adopters can use addresses from the EID block, which might be announced in big aggregates, and only in a tightly controlled way, by Proxy Tunnel Routers (PxTRs) 👑

It's worth saying that new use cases might show up later on, because new and unforeseen scenarios always do 🔮

Also, a dedicated address block lets you have tighter control over traffic during the early experimental phase (filtering especially) while making large-scale deployment easier 🧚

[RFC3692] thinks assigning experimental and testing numbers is useful, and a reserved IPv6 prefix makes that possible 💖 This doc follows the [RFC3692] guidelines with one exception 🎀 [RFC3692] suggests values like the ones called "Private Use" in [RFC5226], and by definition those aren't unique 🙈 One big goal of this IANA request is to guarantee uniqueness for the EID block 💜 Without uniqueness, a reserved IPv6 prefix wouldn't be very useful at all 😭

4. Expected Use 🌸

Sites that plan to deploy LISP may request a prefix from the IPv6 EID block ✨ Those prefixes get used for routing and endpoint identification inside the site that asked for them 🏠 Mappings for such a prefix (or part of it) are made available through the mapping system in use and registered to one or more Map-Server(s) 🗺️

The EID block MUST be used for LISP experimentation and MUST NOT be advertised as more specific route advertisements in the non-LISP inter-domain routing environment. 🚫 Interworking between EID block sub-prefixes and the non-LISP Internet is done using the techniques described in [RFC6832] and [RFC7215] 🫶

As LISP adoption grows, the EID block could have a smaller impact on the BGP routing infrastructure than the same number of adopters using global unicast space from Regional Internet Registries (RIRs) ([MobiArch2007]) 📉 In the short term, the EID block offers potentially big aggregation, since Proxy Tunnel Routers (PxTRs) announce it and can bundle lots of contiguous prefixes together 🧩 That should keep getting better in the long term, because more aggressive aggregation becomes possible, which could mean fewer PxTRs announcing the whole EID block ([FIABook2010]) 🌈

The EID block will only be used at the configuration level, so it is RECOMMENDED not to hard-code the IPv6 EID block into router hardware in any way 🔧 That keeps sites from getting locked out when they want to switch to LISP while keeping their own IPv6 prefix, which isn't in the IPv6 EID block 🔐 Also, if the prefix is permanently allocated in the future, it may be different from the experimental temporary prefix handed out during the experiment 🦋

With the exception of the Proxy Ingress Tunnel Router (PITR) case (described in Section 8), prefixes out of the EID block MUST NOT be announced in the BGP routing infrastructure. 🙅‍♀️

5. Block Dimension 🎀

The working group reached consensus on an initial allocation of a /32 prefix 💖 The reasons for that consensus are many, bestie:

  • The working group agreed the /32 prefix is big enough to cover the initial allocation and any requests for prefixes in the EID space over the next few years, for very large-scale experimentation and deployment 🚀
  • For comparison, the current LISP Beta Network ([BETA]) uses a /32 prefix, with more than 250 sites using a /48 sub-prefix 🌐 So a /32 seems big enough for the current deployment to scale up and stay open for interoperation with independent deployments that use EIDs in the new /32 prefix 🤝
  • A /32 prefix is big enough for third parties to deploy independent (commercial) LISP-enabled networks, and it may also boost LISP experimentation and deployment 💼✨
  • Using a /32 prefix matches the earlier prefix allocation for tunneling protocols ([RFC3056]) 🧁

To be continued in part 2! 🌈💅

6. 3+3 Allocation Plan 🎀

okay so bestie, IANA has initially assigned a /32 prefix out of the IPv6 addressing space for use as EID in LISP 🦋

IANA allocated the requested address space in September 2016 for a duration of 3 (three) years, which runs through September 2019 💖 There's also an option to extend that by 3 (three) more years, until September 2022 ✨ By the end of the first period, the IETF will decide whether the prefix becomes a permanent assignment or goes back in the free pool 👑 (more on that in Section 7)

if the IETF decides to make the block permanent, the EID block allocation period gets extended for three years, until September 2022 🌈 That gives the IETF time to figure out the final size of the EID block and write a transition plan 📝 Making it permanent might cause policy issues (as recognized in [RFC2860], Section 4.3), so the IANA, the RIR communities, and the IETF community will all need to talk it through and work out the right policy for permanent EID-block allocation and management 🫶 Also, the final permanent allocation might not match the initial experimental assignment, so it is recommended not to hard-code the experimental EID block on LISP-capable devices in any way 🙈

and if the IETF instead decides to end the experimental-use EID block, then every temporary prefix allocation in this range has to expire and be released by September 2019, so the entire /32 goes back to the free pool 💀

the allocation and management of the EID block for the initial 3-year period (and the optional 3 more years) is detailed in [RFC7955] 📚

7. Allocation Lifetime ⭐

if there's no explicit action by the end of the experiment (by September 2019), it's automatically considered that there wasn't enough interest in a permanent allocation, so the address block goes back to the free pool 😭

otherwise, if the LISP working group sees value in a permanent allocation, then explicit action is needed 💅

to kick off the process for a permanent allocation, a document is required 📄 This document has to explain why a permanent allocation would be beneficial. More specifically, it has to detail the experience gained during experimentation and all of the technical benefits provided by using a LISP-specific prefix ✨ Those technical benefits are expected to lie in the scenarios described in Section 3, but new and unforeseen benefits may show up during experimentation too 🌸 The description should be articulate enough that the needed size of the permanent allocation can be estimated 🔥 Note that, as explained in Section 6, it's up to IANA to decide which address block will be used as a permanent allocation, and that block may be different from the temporary experimental allocation 🙃

8. Routing Considerations 🛣️

to provide connectivity between the Legacy Internet and LISP sites, PITRs announcing large aggregates (ideally one single, large aggregate) of the IPv6 EID block could be deployed 💜 By doing so, the PITRs attract traffic destined for LISP sites so they can encapsulate it and forward it toward the specific destination LISP site 🦋 Routers in the Legacy Internet must treat announcements of prefixes from the IPv6 EID block as normal announcements, applying best current practices for traffic engineering and security 🛡️

even inside a LISP site, not every router needs to run LISP elements 🌷 Routers that aren't at the border of the local domain, and are only used for intra-domain routing, don't need any specific LISP functionality, but they must be able to route traffic using addresses in the IPv6 EID block 🧚

so for the reasons above, routers that don't run any LISP element must not include any special handling code or hardware for addresses in the IPv6 EID block 🚫 In particular, it is recommended that the default router configuration not handle such addresses in any special way 🍓 Doing it differently could prevent communication between the Legacy Internet and LISP sites, or even break local intra-domain connectivity 😱

9. Security Considerations 🔐

this one is short but mighty 🥹 This document does not introduce new security threats in the LISP architecture nor in the legacy Internet architecture 🦋

10. IANA Considerations 📋

IANA has assigned a /32 IPv6 prefix for use as the global EID space for LISP, using a hierarchical allocation as outlined in [RFC5226] and summarized in Table 1 💖 The assigned block comes from the 2001:5 global unicast space 🌈

IANA is not requested to issue an AS0 Route Origin Attestation (ROA [RFC6491]), because the global EID space is be used for routing purposes 🛰️

            +----------------------+--------------------+
            | Attribute            | Value              |
            +----------------------+--------------------+
            | Address Block        | 2001:5::/32        |
            | Name                 | EID Space for LISP |
            | RFC                  | RFC 7954           |
            | Allocation Date      | September 2016     |
            | Termination Date     | September 2019 [1] |
            | Source               | True [2]           |
            | Destination          | True               |
            | Forwardable          | True               |
            | Global               | True               |
            | Reserved-by-protocol | True [3]           |
            +----------------------+--------------------+

   [1] According to the 3+3 Plan outlined in this document, the
       termination date can be postponed to September 2022.
   [2] Can be used as a multicast source as well.
   [3] To be used as EID space by routers enabled by LISP [RFC6830].

                         Table 1: Global EID Space

the reserved address space is requested for an initial 3-year period starting in September 2016 (until September 2019), with an option to extend it by three years (until September 2022) upon the decision of the IETF (see Sections 6 and 7) 🫧 Following the policies outlined in [RFC5226], upon IETF Review, the decision should be made on whether to have a permanent EID block assignment by September 2019 🗓️ If no explicit action is taken, or if the IETF Review outcome is that it isn't worth having a reserved prefix as a global EID space, the whole /32 will be taken out of the "IANA IPv6 Special-Purpose Address Registry" and put back in the free pool managed by IANA 🎈

allocation and management of the global EID space is detailed in [RFC7955] 📖 Nevertheless, all prefix allocations out of this space must be temporary, and no allocation must go beyond September 2019 unless the IETF Review decides on a permanent global EID space assignment 🚨

11. References 📚

11.1. Normative References 🧾

11.2. Informative References

  • [BETA] LISP Beta Network, "Locator/ID Separation Protocol", <http://www.lisp4.net>. 🌈
  • [FIABook2010] Iannone, L. and T. Leva, "Modeling the economics of Loc/ID Separation for the Future Internet", Towards the Future Internet, Pages 11-20, ISBN: 9781607505389, IOS Press, DOI 10.3233/978-1-60750-539-6-11, May 2010. 📚
  • [LISP-INTRO] Cabellos-Aparicio, A. and D. Saucez, "An Architectural Introduction to the Locator/ID Separation Protocol (LISP)", Work in Progress, draft-ietf-lisp-introduction-13, April 2015. 🦋
  • [MobiArch2007] Quoitin, B., Iannone, L., de Launois, C., and O. Bonaventure, "Evaluating the Benefits of the Locator/Identifier Separation", The 2nd ACM-SIGCOMM International Workshop on Mobility in the Evolving Internet Architecture (MobiArch'07), DOI 10.1145/1366919.1366926, August 2007. 🎀
  • [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February 2001, <http://www.rfc-editor.org/info/rfc3056>. ☁️
  • [RFC6491] Manderson, T., Vegoda, L., and S. Kent, "Resource Public Key Infrastructure (RPKI) Objects Issued by IANA", RFC 6491, DOI 10.17487/RFC6491, February 2012, <http://www.rfc-editor.org/info/rfc6491>. 🔐
  • [RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo-Pascual, J., and D. Lewis, "Locator/Identifier Separation Protocol (LISP) Network Element Deployment Considerations", RFC 7215, DOI 10.17487/RFC7215, April 2014, <http://www.rfc-editor.org/info/rfc7215>. 🧚

Acknowledgments 🫶

Okay, big shoutout time! 💖 Special thanks to Roque Gagliano for his suggestions and pointers, you're literally the best. ✨ Thanks also to Alvaro Retana, Deborah Brungard, Ron Bonica, Damien Saucez, David Conrad, Scott Bradner, John Curran, Paul Wilson, Geoff Huston, Wes George, Arturo Servin, Sander Steffann, Brian Carpenter, Roger Jorgensen, Terry Manderson, Brian Haberman, Adrian Farrel, Job Snijders, Marla Azinger, Chris Morrow, and Peter Schoenmaker for their insightful comments. 👑 And thank you to everyone who joined the fruitful discussions on the IETF mailing list. 💜

The work of Luigi Iannone has been partially supported by the ANR-13-INFR-0009 LISP-Lab Project <www.lisp-lab.org> and the EIT KIC ICT-Labs SOFNETS Project. 🌸

Authors' Addresses 🎀

Here's where you can find the authors. 💅

  • Luigi Iannone Telecom ParisTech Email: ggx@gigix.net 🦋
  • Darrel Lewis Cisco Systems, Inc. Email: darlewis@cisco.com 🍓
  • David Meyer Brocade Email: dmm@1-4-5.net 🌈
  • Vince Fuller Email: vaf@vaf.net ⭐
📦 where this page comes from