--- 1/draft-ietf-lisp-eid-block-mgmnt-02.txt 2014-10-25 05:15:12.539423931 -0700 +++ 2/draft-ietf-lisp-eid-block-mgmnt-03.txt 2014-10-25 05:15:12.571424720 -0700 @@ -1,216 +1,187 @@ Network Working Group L. Iannone Internet-Draft Telecom ParisTech Intended status: Informational R. Jorgensen -Expires: January 2, 2015 Bredbandsfylket Troms +Expires: April 27, 2015 Bredbandsfylket Troms D. Conrad Virtualized, LLC - July 1, 2014 + G. Huston + APNIC - Asia Pacific Network Information Center + October 24, 2014 LISP EID Block Management Guidelines - draft-ietf-lisp-eid-block-mgmnt-02.txt + draft-ietf-lisp-eid-block-mgmnt-03.txt Abstract - This document proposes an allocation framework for the management of - the LISP EID address prefix. The framework described relies on - hierarchical distribution of the address space with sub-prefixes - allocated on a temporary basis to requesting organizations. + This document proposes a framework for the management of the LISP EID + Prefix. The framework described relies on hierarchical distribution + of the address space, granting temporary usage of sub-prefixes of + such space to requesting organizations. -Status of this Memo +Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on January 2, 2015. + This Internet-Draft will expire on April 27, 2015. Copyright Notice Copyright (c) 2014 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. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 - 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2 + 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 - 4. EID Prefix Allocation Policy . . . . . . . . . . . . . . . . . 3 - 5. EID Prefixes Allocation Requirements . . . . . . . . . . . . . 5 - 6. EID Prefix Request Template . . . . . . . . . . . . . . . . . 5 - 7. Policy Validity Period . . . . . . . . . . . . . . . . . . . . 7 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 - 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 11.1. Normative References . . . . . . . . . . . . . . . . . . 8 - 11.2. Informative References . . . . . . . . . . . . . . . . . 9 - Appendix A. LISP Terms . . . . . . . . . . . . . . . . . . . . . 10 - Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 12 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 + 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. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 7 + 11.2. Informative References . . . . . . . . . . . . . . . . . 7 + Appendix A. LISP Terms . . . . . . . . . . . . . . . . . . . . . 8 + Appendix B. Document Change Log . . . . . . . . . . . . . . . . 11 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. 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]. 2. Introduction The Locator/ID Separation Protocol (LISP - [RFC6830]) and related mechanisms ([RFC6831], [RFC6832], [RFC6833], [RFC6834], [RFC6835], [RFC6836], [RFC6837]) separates the IP addressing space into two logical spaces, the End-point IDentifier (EID) space and the Routing LOCator (RLOC) space. The first space is used to identify communication end-points, while the second is used to locate EIDs in the Internet routing infrastructure topology. The document [I-D.ietf-lisp-eid-block] requested an IPv6 address - block reservation exclusively for the allocation and assignment of - EID prefixes. The rationale, intent, size, and usage of the EID + 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 [I-D.ietf-lisp-eid-block]. - This document proposes a management framework for the allocation and - assignment of EID addresses from that block based on temporary - allocation of portions of the block to different requesting - organizations. + This document proposes a management framework for the registration of + EID prefixes from that block, allowing the requesting organisation + exclusive use of those EID prefixes limited to the duration of the + LISP experiment. 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]). To help the reading of this document the terminology introduced by LISP is summarized in Appendix A. -4. EID Prefix Allocation Policy +4. EID Prefix Registration Policy - The allocation of EID prefixes MUST be done under the following - policies: + The request registration of EID prefixes MUST be done under the + following policies: - 1. EID addressing 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 + 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, the renewal of the - allocation may be denied or withdrawn (see Section 5). - - 2. EID prefixes are allocated on a lease/license basis for a limited - period of time (which can be renewed). The lease/license period - SHOULD NOT be longer than one year in order to ensure the leases - and registration information about those leases is kept - reasonably up to date. - - 3. Exception to the previous rule may be granted in cases in which - the prefix has been delegated to an organization that will act as - a registry for further sub-allocations. Sub-allocations MUST - abide by these policies as well as the allocation requirements - outlined in Section 5. Requests for a prefix delegation that - will be used for further sub-allocations MUST clearly state such - intent in the short description of the intended use document. - - 4. All of the allocations (renewed or not, including delegations and - sub-allocations) MUST be returned by 31 December 2017, in - accordance with the 3+3 years experimental allocation plan - outlined in [I-D.ietf-lisp-eid-block]. - - 5. Upon IETF review before 31 December 2017, the EID prefix space - may become a permanent allocation. In this case existing - allocations CAN be renewed and new allocations granted (still on - a yearly temporary basis). All allocations (renewed or not, - including delegations and sub-allocations) MUST be returned by 31 - December 2020, in accordance to the 3+3 years plan outlined in - [I-D.ietf-lisp-eid-block]. During the second 3 years phase of - the experiment, following the policies outlined in [RFC5226], the - IETF will decide the final EID prefix block size and elaborate - the allocation and management policies that will be applied - starting 1 January 2021. - - 6. When an allocation is freed because of non-renewal or the - termination of an experiment, the address space is returned to - the global pool of free EID prefixes. This freed allocation MUST - NOT be announced through registration on Map Servers in the LISP - mapping system for at least 72 hours to ensure expiration of all - cached map entries in the global LISP infrastructure. + registration may be denied. - 7. The EID prefix of an allocation that is not renewed (or whose - renewal has been denied) can be re-used after no less than one - week from the date when the EID prefix is freed. This delay will - provide sufficient time for all cached map entries in the global - LISP infrastructure to expire and will allow any management - process for re-allocation to be dealt with. + 2. EID prefix registrations SHOULD be renewed on a regular basis to + ensure their use by active participants in the experiment. The + registration period is proposed to be 12 months. Registration + renewal SHOULD NOT cause a change in the registered EID prefix. + The conditions of registration renewal should no different to the + conditions of registration. - 8. EID prefix allocations can be revoked as a result of abuse, - unjustified usage (e.g., not conforming the intended use provided - at request time), failure to pay maintenance fees, legal court - orders, etc. Withdrawal can be enforced by filtering on Map - Servers so to prevent map registration. + 3. 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. -5. EID Prefixes Allocation Requirements + 4. All registrations of EID prefixes cease at the time of the + expiration of the reserved experimental LISP EID Block. The + further disposition of these prefixes and the associated registry + entries is to be specified in the announcement of the cessation + of this experiment. - All EID prefix allocations (and delegations) MUST respect the - following requirements: +5. EID Prefixes Registration Requirements - 1. Allocations MUST be globally unique. + All EID prefix registrations MUST respect the following requirements: - 2. Requirements for allocation MUST be the same globally. No - regional/national/local variations are permitted. + 1. All EID prefix registrations MUST use a globally unique EID + prefix. - 3. The registration information MUST be maintained and made publicly - available through a searchable interface, preferably RDAP - ([I-D.ietf-weirds-rdap-sec]) and optionally whois, http, or - similar access methods. + 2. If there is more than one registry operator, all operators MUST + use the same registry management policies and practices. - 4. The registration information service should be reasonably - reliable so to make such information readily available. The - allocation service SHOULD be provided during regular business - hours in venue in which the allocation service is housed. + 3. The EID Prefix registration information as specified in + Section 6, MUST be collected upon initial registration and + renewal, and made publicly available though interfaces allowing + both retrieval of specific registration details (search) and + enumeration of the entire registry contents (e.g., + [I-D.ietf-weirds-rdap-sec], whois, http, or similar access + methods). - 5. Facilities SHOULD exist to allow for the delegation of the - reverse DNS for EID address prefixes. Reverse DNS delegation is - not required, and may not be provided from the beginning of the - use of the EID Block. However it may be made available on a - later stage if operational requirements necessitate it or IETF - decides it should be available. + 4. The registry operator MUST permit the delegation of EID prefixes + in the reverse DNS space to holders of registered EID prefixes. - 6. Anyone, private persons, companies, or other entities can request - EID space and those requests MUST be granted, provided that they - can show a clear intent in carrying out LISP experimentation. + 5. 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 allocation (and - delegation) so to ensure a uniform process. Such a template is - inspired by the IANA Private Enterprise Number online request form + The following is a basic request template for prefix registration so + to ensure a uniform process. Such a template is inspired by the IANA + Private Enterprise Number online 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. + The EID Prefix Request template MUST at minimum contain: 1. Organization (In case of individuals requesting an EID prefix this section can be left empty) (a) Organization Name (b) Organization Address (c) Organization Phone @@ -228,36 +199,39 @@ (e) Email 3. EID Prefix Request (Mandatory) (a) Prefix Size (b) Prefix Size Rationale (c) Lease Period - + Start Date + + Note Well: All EID Prefix registrations will be valid until + the earlier date of 12 months from the date of registration + or 31 December 2017. - + End Date + + All registrations may be renewed by the applicant for + further 12 month periods, ending on 31 December 2017. - Note that according to the 3+3 year allocation plan, defined - in [I-D.ietf-lisp-eid-block], all allocations (and - delegations) MUST end by 31 December 2017, unless the IETF - community decides to grant a permanent LISP EID address - block. In the latter case, allocations (and delegations) - following the present document policy MUST end by 31 - December 2020 and a new policy (to be decided see Section 7) - will apply starting 1 January 2021. + + According to the 3+3 year experimentation plan, defined in + [I-D.ietf-lisp-eid-block], all registrations MUST end by 31 + December 2017, 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 31 December 2020 and a new policy (to be decided - see + Section 7) will apply starting 1 January 2021. 4. Experiment Description (a) Experiment and Deployment Description + (b) Interoperability with existing LISP deployments (c) Interoperability with Legacy Internet 5. Reverse DNS Servers (Optional) (a) Name server name: (b) Name server address: @@ -262,73 +236,71 @@ (b) Name server address: (c) Name server name: (d) Name server address: (Repeat if necessary) 7. Policy Validity Period - Policy outlined in the present document is tight to the existence of + Policy outlined in the present document is tied to the existence of the experimental LISP EID block requested in [I-D.ietf-lisp-eid-block] and valid until 31 December 2017. If the IETF decides to transform the block in a permanent allocation, - the LISP EID block allocation period will be extended for three years - (until 31 December 2020) so to give time to the IETF to define the - final size of the EID block and create a transition plan, while the - policy in the present document will still apply. + the LISP EID block reserved usage period will be extended for three + years (until 31 December 2020) so to give time to 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 [I-D.ietf-lisp-eid-block], the transition of - the EID block into a permanent allocation has the potential to pose + the EID block into a permanent allocation, has the potential to pose policy issues (as recognized in [RFC2860], section 4.3) and hence discussion with the IANA, the RIR communities, and the IETF community will be necessary to determine appropriate policy for permanent EID - prefix allocation and management, which will be effective starting 1 - January 2021. + prefix management, which will be effective starting 1 January 2021. 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 allocation request MUST contain + considerations in [RFC7020], each registration request MUST contain accurate information on the requesting entity (company, institution, individual, etc.) and valid and accurate contact information of a referral person (see Section 6). 9. Acknowledgments - Thanks to J. Curran, A. Severin, B. Haberman, T. Manderson, D. Lewis, - D. Farinacci, for their helpful comments. + Thanks to J. Curran, A. Severin, B. Haberman, T. Manderson, D. + Lewis, D. Farinacci, M. Binderberger, 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- + 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. 10. IANA Considerations This document provides only management guidelines for the reserved - LISP EID prefix requested and allocated in [I-D.ietf-lisp-eid-block]. + LISP EID prefix requested in [I-D.ietf-lisp-eid-block]. - There is an operational requirement for an EID allocation service - that ensures uniqueness of EIDs allocated according to the - requirements described in Section 5. Furthermore, there is an - operational requirement for EID registration service that allows a - lookup of the contact information of the entity to which the EID was - allocated. + There is an operational requirement for an EID registration service + that ensures uniqueness of EIDs according to the requirements + described in Section 5. Furthermore, there is an operational + requirement for EID registration service that allows a lookup of the + contact information of the entity that registered the EID. - IANA must ensure both of these services are provided, for the space - directly allocated by IANA, in a globally uniform fashion for the - duration of the experiment. + IANA is to ensure both of these services are provided in a globally + uniform fashion for the duration of the experiment. 11. References 11.1. Normative References [I-D.ietf-lisp-eid-block] Iannone, L., Lewis, D., Meyer, D., and V. Fuller, "LISP EID Block", draft-ietf-lisp-eid-block-09 (work in progress), July 2014. @@ -340,43 +312,42 @@ Plan", BCP 122, RFC 4632, August 2006. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 11.2. Informative References [I-D.ietf-weirds-rdap-sec] Hollenbeck, S. and N. Kong, "Security Services for the - Registration Data Access Protocol", - draft-ietf-weirds-rdap-sec-06 (work in progress), - February 2014. + Registration Data Access Protocol", draft-ietf-weirds- + rdap-sec-06 (work in progress), February 2014. [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority", RFC 2860, June 2000. [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The - Locator/ID Separation Protocol (LISP)", RFC 6830, - January 2013. + Locator/ID Separation Protocol (LISP)", RFC 6830, January + 2013. [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The Locator/ID Separation Protocol (LISP) for Multicast Environments", RFC 6831, 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, January 2013. [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation - Protocol (LISP) Map-Server Interface", RFC 6833, - January 2013. + Protocol (LISP) Map-Server Interface", RFC 6833, January + 2013. [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID Separation Protocol (LISP) Map-Versioning", RFC 6834, January 2013. [RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation Protocol Internet Groper (LIG)", RFC 6835, January 2013. [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol Alternative Logical @@ -501,20 +472,26 @@ logical next-hop on the overlay network. The primary function of LISP+ALT routers is to provide a lightweight forwarding infrastructure for LISP control-plane messages (Map-Request and Map-Reply), and to transport data packets when the packet has the same destination address in both the inner (encapsulating) destination and outer destination addresses ((i.e., a Data Probe packet). See [RFC6830] for more details. Appendix B. Document Change Log + Version 03 Posted October 2014. + + o Re-worded the document so to avoid confusion on "allocation" and + "assignement". The document now reffers to "registration". As + for comments by G. Huston and M. Binderberger. + Version 02 Posted July 2014. o Deleted the trailing paragraph of Section 4, as for discussion in the mailing list. o Deleted the fees policy as of suggestion of G. Huston and discussion during 89th IETF. o Re-phrased the availability of the registration information requirement avoiding putting specific numbers (previously @@ -537,20 +514,24 @@ Version 00 Posted December 2013. o Rename of draft-iannone-lisp-eid-block-mgmnt-03.txt. Authors' Addresses Luigi Iannone Telecom ParisTech Email: ggx@gigix.net - Roger Jorgensen Bredbandsfylket Troms Email: rogerj@gmail.com David Conrad Virtualized, LLC Email: drc@virtualized.org + + Geoff Huston + APNIC - Asia Pacific Network Information Center + + Email: gih@apnic.net