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/rfc7955.txt | 563 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 563 insertions(+) create mode 100644 doc/rfc/rfc7955.txt (limited to 'doc/rfc/rfc7955.txt') diff --git a/doc/rfc/rfc7955.txt b/doc/rfc/rfc7955.txt new file mode 100644 index 0000000..19cc5f4 --- /dev/null +++ b/doc/rfc/rfc7955.txt @@ -0,0 +1,563 @@ + + + + + + +Internet Engineering Task Force (IETF) L. Iannone +Request for Comments: 7955 Telecom ParisTech +Category: Informational R. Jorgensen +ISSN: 2070-1721 Bredbandsfylket Troms + D. Conrad + Virtualized, LLC + G. Huston + APNIC + September 2016 + + + Management Guidelines for the Locator/ID Separation Protocol (LISP) + Endpoint Identifier (EID) Block + +Abstract + + This document proposes a framework for the management of the Locator/ + ID Separation Protocol (LISP) Endpoint Identifier (EID) address + block. The framework described relies on hierarchical distribution + of the address space, granting temporary usage of prefixes of such + space to requesting organizations. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + 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/rfc7955. + + + + + + + + + + + + + + +Iannone, et al. Informational [Page 1] + +RFC 7955 LISP EID Block Management 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 + 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 + 4. EID Prefix Registration Policy . . . . . . . . . . . . . . . 3 + 5. EID Prefixes Registration Requirements . . . . . . . . . . . 4 + 6. EID Prefix Request Template . . . . . . . . . . . . . . . . . 4 + 7. Policy Validity Period . . . . . . . . . . . . . . . . . . . 6 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 + 10. Procedures to be Followed by RIPE NCC . . . . . . . . . . . . 7 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 8 + 11.2. Informative References . . . . . . . . . . . . . . . . . 8 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 + +1. Introduction + + The Locator/ID Separation Protocol (LISP [RFC6830]) and related + mechanisms ([RFC6831], [RFC6832], [RFC6833], [RFC6834], [RFC6835], + [RFC6836], [RFC6837]) separate the IP addressing space into two + logical spaces, the Endpoint Identifier (EID) space and the Routing + Locator (RLOC) space. The first space is used to identify + communication endpoints, while the second is used to locate EIDs in + the Internet routing infrastructure topology. + + [RFC7954] requests an IPv6 address block reservation exclusively for + use as EID prefixes in the LISP experiment. The rationale, intent, + size, and usage of the EID address block are described in [RFC7954]. + + + + + +Iannone, et al. Informational [Page 2] + +RFC 7955 LISP EID Block Management September 2016 + + + This document proposes a management framework for the registration of + EID prefixes from that block, allowing the requesting organization + exclusive use of those EID prefixes limited to the duration of the + LISP experiment. + +2. Requirements Notation + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +3. Definition of Terms + + This document does not introduce any new terms related to the set of + LISP Specifications ([RFC6830], [RFC6831], [RFC6832], [RFC6833], + [RFC6834], [RFC6835], [RFC6836], [RFC6837]), but assumes that the + reader is familiar with the LISP terminology. [INTRO] provides an + introduction to the LISP technology, including its terminology. + +4. EID Prefix Registration Policy + + The request for registration of EID prefixes MUST be done under the + following policies: + + 1. EID prefixes are made available in the reserved space on a + temporary basis and for experimental uses. The requester of an + experimental prefix MUST provide a short description of the + intended use or experiment that will be carried out (see + Section 6). If the prefix will be used for activities not + documented in the original description, renewal of the + registration may be denied. + + 2. EID prefix registrations MUST be renewed on a regular basis to + ensure their use by active participants in the experiment. The + registration period is 12 months. A renewal SHOULD NOT cause a + change in the EID prefix registered in the previous request. The + conditions of registration renewal are to be the same as the + conditions of the first EID prefix registration request. + + 3. It is preferable that EID prefixes whose registrations have + expired not be reused. When an EID prefix registration is + removed from the registry, then the reuse of the EID prefix in a + subsequent registration on behalf of a different end user should + be avoided where possible. If the considerations of overall + usage of the EID block prefix requires reuse of a previously + registered EID prefix, then a minimum delay of at least one week + between removal and subsequent registration SHOULD be applied by + the registry operator. + + + +Iannone, et al. Informational [Page 3] + +RFC 7955 LISP EID Block Management September 2016 + + + 4. When the reserved experimental LISP EID block expires, all EID + prefix registrations expire as well. The further disposition of + these prefixes and the associated registry entries are to be + specified in the announcement of the cessation of this + experiment. + +5. EID Prefixes Registration Requirements + + All EID prefix registrations MUST satisfy the following requirements: + + 1. All EID prefix registrations MUST use a globally unique EID + prefix. + + 2. The EID prefix registration information, as specified in + Section 6, MUST be collected upon initial registration and + renewal, and made publicly available through interfaces allowing + both the retrieval of specific registration details (search) and + the enumeration of the entire registry contents (e.g., RDAP + ([RFC7481]), WHOIS, HTTP, or similar access methods). + + 3. The registry operator MUST permit the delegation of EID prefixes + in the reverse DNS space to holders of registered EID prefixes. + + 4. Anyone can obtain an entry in the EID prefix registry, on the + understanding that the prefix so registered is for the exclusive + use in the LISP experimental network, and that their registration + details (as specified in Section 6) are openly published in the + EID prefix registry. + +6. EID Prefix Request Template + + The following is a basic request template for prefix registration to + ensure a uniform process. This template is inspired by IANA's online + "Private Enterprise Number (PEN) Request" form + . + + Note that all details in this registration become part of the + registry and will be published in the LISP EID Prefix Registry + managed by RIPE NCC. + + The EID Prefix Request template MUST at a minimum contain: + + 1. Organization (In the case of individuals requesting an EID + prefix, this section can be left empty) + + (a) Organization Name + + (b) Organization Address + + + +Iannone, et al. Informational [Page 4] + +RFC 7955 LISP EID Block Management September 2016 + + + (c) Organization Phone + + (d) Organization Website + + 2. Contact Person (Mandatory) + + (a) Name + + (b) Address + + (c) Phone + + (d) Fax (optional) + + (e) Email + + 3. EID Prefix Request (Mandatory) + + (a) Prefix Size + + + Expressed as an address prefix length. + + (b) Prefix Size Rationale + + (c) Lease Period + + + Note well: All EID Prefix registrations will be valid until + the earlier date of 12 months from the date of registration + or August 2019. + + + All registrations may be renewed by the applicant for + further 12-month periods, ending on August 2019. + + + According to the 3+3 year experimentation plan, defined in + [RFC7954], all registrations MUST end by August 2019, unless + the IETF community decides to grant a permanent LISP EID + address block. In the latter case, registrations following + the present document policy MUST end by August 2022 and a + new policy (to be decided -- see Section 7) will apply + thereafter. + + 4. Experiment Description + + (a) Experiment and Deployment Description + + (b) Interoperability with Existing LISP Deployments + + (c) Interoperability with Legacy Internet + + + +Iannone, et al. Informational [Page 5] + +RFC 7955 LISP EID Block Management September 2016 + + + 5. Reverse DNS Servers (Optional) + + (a) Name Server Name + + (b) Name Server Address + + (c) Name Server Name + + (d) Name Server Address + + (Repeat if necessary) + +7. Policy Validity Period + + The policy outlined in the present document is tied to the existence + of the experimental LISP EID block requested in [RFC7954] and is + valid until August 2019. + + If the IETF decides to transform the block into a permanent + allocation, the usage period reserved for the LISP EID block will be + extended for three years (until August 2022) to allow time for the + IETF to define, following the policies outlined in [RFC5226], the + final size of the EID block and create a transition plan, while the + policy in the present document will still apply. + + Note that, as stated in [RFC7954], the transition of the EID block + into a permanent allocation has the potential to pose policy issues + (as recognized in [RFC2860], Section 4.3); hence, discussion with the + IANA, the Regional Internet Registry (RIR) communities, and the IETF + community will be necessary to determine the appropriate policy for + permanent EID prefix management, which will be effective after August + 2022. + +8. Security Considerations + + This document does not introduce new security threats in the LISP + architecture nor in the Legacy Internet architecture. + + For accountability reasons and in line with the security + considerations in [RFC7020], each registration request MUST contain + accurate information about the requesting entity (company, + institution, individual, etc.) and valid and accurate contact + information of a referral person (see Section 6). + + + + + + + + +Iannone, et al. Informational [Page 6] + +RFC 7955 LISP EID Block Management September 2016 + + +9. IANA Considerations + + IANA allocated the following IPv6 address block for experimental use + as the LISP EID prefix [RFC7954]: + + o Address Block: 2001:5::/32 + + o Name: EID Space for LISP + + o RFC: [RFC7954] + + o Further details are at: www.iana.org/assignments/iana-ipv6- + special-registry + + To grant requesting organizations and individuals exclusive use of + EID prefixes out of this reserved block (limited to the duration of + the LISP experiment as outlined in Section 7), there is an + operational requirement for an EID registration service. + + Provided that the policies and requirements outlined in Sections 4, + 5, and 6 are satisfied, EID prefix registration is accorded based on + a "First Come First Served" basis. + + There is no hard limit to the number of registrations an organization + or individual can submit, as long as the information described in + Section 6 is provided, in particular point 4: "Experiment + Description". + + For the duration defined in [RFC7954], RIPE NCC will manage the LISP + EID prefix as described herein. Therefore, this document has no IANA + actions. + +10. Procedures to be Followed by RIPE NCC + + RIPE NCC will provide the registration service following the EID + Prefix Registration Policy (Section 4) and the EID Prefix + Registration Requirements (Section 5) provided in this document. The + request form provided by RIPE NCC will include at least the + information from the template in Section 6. RIPE NCC will make all + received requests publicly available. While this document does not + suggest any minimum allocation size; RIPE NCC is allowed to introduce + such a minimum size for management purposes. + + + + + + + + + +Iannone, et al. Informational [Page 7] + +RFC 7955 LISP EID Block Management September 2016 + + +11. References + +11.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [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, + . + + [RFC7954] Iannone, L., Lewis, D., Meyer, D., and V. Fuller, + "Locator/ID Separation Protocol (LISP) Endpoint Identifier + (EID) Block", RFC 7954, DOI 10.17487/RFC7954, September + 2016, . + +11.2. Informative References + + [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. + + [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, + . + + [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, + . + + + + +Iannone, et al. Informational [Page 8] + +RFC 7955 LISP EID Block Management September 2016 + + + [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation + Protocol (LISP) Map-Server Interface", RFC 6833, + DOI 10.17487/RFC6833, January 2013, + . + + [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, + . + + [RFC7020] Housley, R., Curran, J., Huston, G., and D. Conrad, "The + Internet Numbers Registry System", RFC 7020, + DOI 10.17487/RFC7020, August 2013, + . + + [RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the + Registration Data Access Protocol (RDAP)", RFC 7481, + DOI 10.17487/RFC7481, March 2015, + . + + + + + + + + + + + + + + + + + +Iannone, et al. Informational [Page 9] + +RFC 7955 LISP EID Block Management September 2016 + + +Acknowledgments + + Thanks to A. Retana, J. Arkko, P. Yee, A. de la Haye, A. Cima, + A. Pawlik, J. Curran, A. Severin, B. Haberman, T. Manderson, + D. Lewis, D. Farinacci, M. Binderberger, D. Saucez, E. Lear, for + their helpful comments. + + 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. + +Authors' Addresses + + Luigi Iannone + Telecom ParisTech + France + + Email: ggx@gigix.net + + + Roger Jorgensen + Bredbandsfylket Troms + Norway + + Email: rogerj@gmail.com + + David Conrad + Virtualized, LLC + United States + + Email: drc@virtualized.org + + + Geoff Huston + Asia Pacific Network Information Centre (APNIC) + Australia + + Email: gih@apnic.net + + + + + + + + + + + + + +Iannone, et al. Informational [Page 10] + -- cgit v1.2.3