doc: Add RFC documents

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]
+