summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7955.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7955.txt')
-rw-r--r--doc/rfc/rfc7955.txt563
1 files changed, 563 insertions, 0 deletions
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
+ <http://pen.iana.org/pen/PenApplication.page>.
+
+ 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,
+ <http://www.rfc-editor.org/info/rfc2119>.
+
+ [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,
+ <http://www.rfc-editor.org/info/rfc5226>.
+
+ [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, <http://www.rfc-editor.org/info/rfc7954>.
+
+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,
+ <http://www.rfc-editor.org/info/rfc2860>.
+
+ [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
+ Locator/ID Separation Protocol (LISP)", RFC 6830,
+ DOI 10.17487/RFC6830, January 2013,
+ <http://www.rfc-editor.org/info/rfc6830>.
+
+ [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, <http://www.rfc-editor.org/info/rfc6831>.
+
+ [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,
+ <http://www.rfc-editor.org/info/rfc6832>.
+
+
+
+
+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,
+ <http://www.rfc-editor.org/info/rfc6833>.
+
+ [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID
+ Separation Protocol (LISP) Map-Versioning", RFC 6834,
+ DOI 10.17487/RFC6834, January 2013,
+ <http://www.rfc-editor.org/info/rfc6834>.
+
+ [RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation
+ Protocol Internet Groper (LIG)", RFC 6835,
+ DOI 10.17487/RFC6835, January 2013,
+ <http://www.rfc-editor.org/info/rfc6835>.
+
+ [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, <http://www.rfc-editor.org/info/rfc6836>.
+
+ [RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to
+ Routing Locator (RLOC) Database", RFC 6837,
+ DOI 10.17487/RFC6837, January 2013,
+ <http://www.rfc-editor.org/info/rfc6837>.
+
+ [RFC7020] Housley, R., Curran, J., Huston, G., and D. Conrad, "The
+ Internet Numbers Registry System", RFC 7020,
+ DOI 10.17487/RFC7020, August 2013,
+ <http://www.rfc-editor.org/info/rfc7020>.
+
+ [RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the
+ Registration Data Access Protocol (RDAP)", RFC 7481,
+ DOI 10.17487/RFC7481, March 2015,
+ <http://www.rfc-editor.org/info/rfc7481>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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 <www.lisp-lab.org> 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]
+