From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7954.txt | 675 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 675 insertions(+) create mode 100644 doc/rfc/rfc7954.txt (limited to 'doc/rfc/rfc7954.txt') diff --git a/doc/rfc/rfc7954.txt b/doc/rfc/rfc7954.txt new file mode 100644 index 0000000..4f69972 --- /dev/null +++ b/doc/rfc/rfc7954.txt @@ -0,0 +1,675 @@ + + + + + + +Internet Engineering Task Force (IETF) L. Iannone +Request for Comments: 7954 Telecom ParisTech +Category: Experimental D. Lewis +ISSN: 2070-1721 Cisco Systems, Inc. + D. Meyer + Brocade + V. Fuller + September 2016 + + + Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block + +Abstract + + This document directs IANA to allocate a /32 IPv6 prefix for use with + the Locator/ID Separation Protocol (LISP). The prefix will be used + for local intra-domain routing and global endpoint identification, by + sites deploying LISP as Endpoint Identifier (EID) addressing space. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for examination, experimental implementation, and + evaluation. + + This document defines an Experimental Protocol for the Internet + community. This document is a product of the Internet Engineering + Task Force (IETF). It represents the consensus of the IETF + community. It has received public review and has been approved for + publication by the Internet Engineering Steering Group (IESG). Not + all documents approved by the IESG are a candidate for any level of + Internet Standard; see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7954. + + + + + + + + + + + + + + + +Iannone, et al. Experimental [Page 1] + +RFC 7954 LISP EID Block September 2016 + + +Copyright Notice + + 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) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in 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 + + + + + + + + + + + + + + + + + + + +Iannone, et al. Experimental [Page 2] + +RFC 7954 LISP EID Block September 2016 + + +1. Introduction + + This document directs the IANA to allocate a /32 IPv6 prefix for use + with the Locator/ID Separation Protocol (LISP [RFC6830]), LISP Map- + Server ([RFC6833]), LISP Alternative Topology (LISP+ALT [RFC6836]) + (or other) mapping systems, and LISP Interworking ([RFC6832]). + + This block will be used as global Endpoint Identifier (EID) space. + +2. Definition of Terms + + The present document does not introduce any new terms with respect to + the set of LISP Specifications ([RFC6830], [RFC6831], [RFC6832], + [RFC6833], [RFC6834], [RFC6835], [RFC6836], [RFC6837]), but it + assumes that the reader is familiar with the LISP terminology. + [LISP-INTRO] provides an introduction to the LISP technology, + including its terminology. + +3. Rationale and Intent + + Discussion within the LISP working group led to the identification of + several scenarios in which the existence of a LISP-specific address + block brings technical benefits. The most relevant scenarios are + described below: + + Early LISP destination detection: With the current specifications, + there is no direct way to detect whether or not a certain + destination is in a LISP domain without performing a LISP + mapping lookup. For instance, if an Ingress Tunnel Router + (ITR) is sending packets to all types of destinations (i.e., + non-LISP destinations, LISP destinations not in the IPv6 EID + block, and LISP destinations in the IPv6 EID block), the only + way to understand whether or not to encapsulate the traffic is + to perform a cache lookup and, in case of a LISP cache miss, + send a Map-Request to the mapping system. In the meanwhile + (while waiting for the Map-Reply), packets may be dropped to + avoid excessive buffering. + + Avoid penalizing non-LISP traffic: In certain circumstances, it + might be desirable to configure a router using LISP features to + natively forward all packets that do not have a destination + address in the block and, hence, no lookup whatsoever is + performed and packets destined to non-LISP sites are not + penalized in any manner. + + + + + + + +Iannone, et al. Experimental [Page 3] + +RFC 7954 LISP EID Block September 2016 + + + Traffic Engineering: In some deployment scenarios, it might be + desirable to apply different traffic-engineering policies for + LISP and non-LISP traffic. A LISP-specific EID block would + allow improved traffic-engineering capabilities with respect to + LISP vs. non-LISP traffic. In particular, LISP traffic might + be identified without having to use Deep Packet Inspection + (DPI) techniques in order to parse the encapsulated packet. + Instead, performing a simple inspection of the outer header is + sufficient. + + Transition Mechanism: The existence of a LISP-specific EID block may + prove useful in transition scenarios. A non-LISP domain would + ask for an allocation in the LISP EID block and use it to + deploy LISP in its network. Such allocation would not be + announced in the BGP routing infrastructure (cf. Section 4). + This approach will allow non-LISP domains to avoid fragmenting + their already allocated non-LISP addressing space, which may + lead to BGP routing table inflation since it may (rightfully) + be announced in the BGP routing infrastructure. + + Limit the impact on the BGP routing infrastructure: As described in + the previous scenario, LISP adopters will avoid fragmenting + their addressing space, since fragmentation would negatively + impact the BGP routing infrastructure. Adopters will use + addressing space from the EID block, which might be announced + in large aggregates and in a tightly controlled manner only by + Proxy Tunnel Routers (PxTRs). + + It is worth mentioning that new use cases may arise in the future, + due to new and unforeseen scenarios. + + Furthermore, the use of a dedicated address block allows for tighter + control over the traffic in the initial experimental phase + (especially filtering), while facilitating its large-scale + deployment. + + [RFC3692] considers assigning experimental and testing numbers + useful; having a reserved IPv6 prefix enables this practice. The + present document follows the guidelines provided in [RFC3692], with + one exception. [RFC3692] suggests the use of values similar to those + called "Private Use" in [RFC5226], which by definition are not + unique. One purpose of the present request to IANA is to guarantee + uniqueness to the EID block. The lack thereof would result in a lack + of real utility of a reserved IPv6 prefix. + + + + + + + +Iannone, et al. Experimental [Page 4] + +RFC 7954 LISP EID Block September 2016 + + +4. Expected Use + + Sites planning to deploy LISP may request a prefix in the IPv6 EID + block. Such prefixes will be used for routing and endpoint + identification inside the site requesting it. Mappings related to + such a prefix, or part of it, will be 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 in the form of more specific route advertisements in the + non-LISP inter-domain routing environment. Interworking between the + EID block sub-prefixes and the non-LISP Internet is done according to + the techniques described in [RFC6832] and [RFC7215]. + + As the LISP adoption progresses, the EID block may potentially have a + reduced impact on the BGP routing infrastructure, compared to the + case of having the same number of adopters using global unicast space + allocated by Regional Internet Registries (RIRs) ([MobiArch2007]). + From a short-term perspective, the EID block offers potentially large + aggregation capabilities since it is announced by Proxy Tunnel + Routers (PxTRs), possibly concentrating several contiguous prefixes. + This trend should continue with even lower impact from a long-term + perspective, because more aggressive aggregation can be used, + potentially leading to using fewer PxTRs announcing the whole EID + block ([FIABook2010]). + + The EID block will be used only at the configuration level, so it is + recommended not to hard-code the IPv6 EID block in the router + hardware in any way. This prevents locking out sites that may want + to switch to LISP while keeping their own IPv6 prefix, which is not + in the IPv6 EID block. Furthermore, in the case of a future + permanent allocation, the allocated prefix may differ from the + experimental temporary prefix allocated during the experimentation + phase. + + 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 reason of such consensus is manifold: + + o The working group agreed that the /32 prefix is sufficiently large + to cover initial allocation and requests for prefixes in the EID + space in the next few years for very large-scale experimentation + and deployment. + + + +Iannone, et al. Experimental [Page 5] + +RFC 7954 LISP EID Block September 2016 + + + o As a comparison, it is worth mentioning that the current LISP Beta + Network ([BETA]) is using a /32 prefix, with more than 250 sites + using a /48 sub-prefix. Hence, a /32 prefix appears sufficiently + large to allow the current deployment to scale up and be open for + interoperation with independent deployments using the EIDs in the + new /32 prefix. + + o A /32 prefix is sufficiently large to allow deployment of + independent (commercial) LISP-enabled networks by third parties, + but may as well boost LISP experimentation and deployment. + + o The use of a /32 prefix is in line with previous similar prefix + allocation for tunneling protocols ([RFC3056]). + +6. 3+3 Allocation Plan + + Per this document, 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 (through September 2019), with an option + to extend this period by 3 (three) more years (until September 2022). + By the end of the first period, the IETF will provide a decision on + whether to transform the prefix into a permanent assignment or to put + it back in the free pool (see Section 7 for more information). + + In the first case, i.e., if the IETF decides to transform the block + into a permanent allocation, the EID block allocation period will be + extended for three years (until September 2022) to give the IETF time + to define the final size of the EID block and create a transition + plan. The transition of the EID block into a permanent allocation + might pose policy issues (as recognized in [RFC2860], Section 4.3); + therefore, discussion with the IANA, the RIR communities, and the + IETF community will be necessary to determine the appropriate policy + for permanent EID-block allocation and management. Note as well that + the final permanent allocation may differ from the initial + experimental assignment; hence, it is recommended not to hard-code + the experimental EID block on LISP-capable devices in any way. + + In the latter case, i.e., if the IETF decides to terminate the + experimental-use EID block, all temporary prefix allocations in this + address range must expire and be released by September 2019, so that + the entire /32 is returned 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]. + + + + + +Iannone, et al. Experimental [Page 6] + +RFC 7954 LISP EID Block September 2016 + + +7. Allocation Lifetime + + If no explicit action is carried out by the end of the experiment (by + September 2019), it is automatically considered that there was not + sufficient interest in having a permanent allocation; therefore, the + address block will be returned to the free pool. + + Otherwise, if the LISP working group recognizes that there is value + in having a permanent allocation, then explicit action is needed. + + In order to trigger the process for a permanent allocation, a + document is required. Such a document has to articulate the + rationale for why a permanent allocation would be beneficial. More + specifically, the document has to detail the experience gained during + experimentation and all of the technical benefits provided by the use + of a LISP-specific prefix. Such technical benefits are expected to + lay in the scenarios described in Section 3. However, new and + unforeseen benefits may appear during experimentation. The + description should be sufficiently articulate that the needed size of + the permanent allocation can be estimated. However, note that, as + explained in Section 6, it is up to IANA to decide which address + block will be used as a permanent allocation and that such a block + may be different from the temporary experimental allocation. + +8. Routing Considerations + + In order 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, + PITRs will attract traffic destined for LISP sites in order to + encapsulate 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 in a LISP site, not all routers need to run LISP elements. In + particular, routers that are not at the border of the local domain, + used only for intra-domain routing, do not need to provide any + specific LISP functionality but must be able to route traffic using + addresses in the IPv6 EID block. + + For the above-mentioned reasons, routers that do not 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 differently could prevent communication + between the Legacy Internet and LISP sites or even break local intra- + domain connectivity. + + + +Iannone, et al. Experimental [Page 7] + +RFC 7954 LISP EID Block September 2016 + + +9. Security Considerations + + 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 is 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 is + not worth having a reserved prefix as a global EID space, the whole + /32 will be taken out from the "IANA IPv6 Special-Purpose Address + Registry" and put back in the free pool managed by IANA. + + + +Iannone, et al. Experimental [Page 8] + +RFC 7954 LISP EID Block September 2016 + + + 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 for a permanent global EID space + assignment. + +11. References + +11.1. Normative References + + [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of + Understanding Concerning the Technical Work of the + Internet Assigned Numbers Authority", RFC 2860, + DOI 10.17487/RFC2860, June 2000, + . + + [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers + Considered Useful", BCP 82, RFC 3692, + DOI 10.17487/RFC3692, January 2004, + . + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + DOI 10.17487/RFC5226, May 2008, + . + + [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The + Locator/ID Separation Protocol (LISP)", RFC 6830, + DOI 10.17487/RFC6830, January 2013, + . + + [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The + Locator/ID Separation Protocol (LISP) for Multicast + Environments", RFC 6831, DOI 10.17487/RFC6831, January + 2013, . + + [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, + "Interworking between Locator/ID Separation Protocol + (LISP) and Non-LISP Sites", RFC 6832, + DOI 10.17487/RFC6832, January 2013, + . + + [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation + Protocol (LISP) Map-Server Interface", RFC 6833, + DOI 10.17487/RFC6833, January 2013, + . + + + + + +Iannone, et al. Experimental [Page 9] + +RFC 7954 LISP EID Block September 2016 + + + [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID + Separation Protocol (LISP) Map-Versioning", RFC 6834, + DOI 10.17487/RFC6834, January 2013, + . + + [RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation + Protocol Internet Groper (LIG)", RFC 6835, + DOI 10.17487/RFC6835, January 2013, + . + + [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, + "Locator/ID Separation Protocol Alternative Logical + Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, + January 2013, . + + [RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to + Routing Locator (RLOC) Database", RFC 6837, + DOI 10.17487/RFC6837, January 2013, + . + + [RFC7955] Iannone, L., Jorgensen, R., Conrad, D., and G. Huston, + "Locator/ID Separation Protocol (LISP) Endpoint Identifier + (EID) Block Management Guidelines", RFC 7955, + DOI 10.17487/RFC7955, September 2016, + . + +11.2. Informative References + + [BETA] LISP Beta Network, "Locator/ID Separation Protocol", + . + + [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. + + + + + + + + + +Iannone, et al. Experimental [Page 10] + +RFC 7954 LISP EID Block September 2016 + + + [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, . + + [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, + . + + [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, . + +Acknowledgments + + Special thanks to Roque Gagliano for his suggestions and pointers. + Thanks 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. Thanks as well to all participants for + 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 and the EIT KIC + ICT-Labs SOFNETS Project. + + + + + + + + + + + + + + +Iannone, et al. Experimental [Page 11] + +RFC 7954 LISP EID Block September 2016 + + +Authors' Addresses + + 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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Iannone, et al. Experimental [Page 12] + -- cgit v1.2.3