idnits 2.17.1 draft-ietf-lisp-eid-block-mgmnt-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 6, 2016) is 2913 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-15) exists of draft-ietf-lisp-introduction-13 -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) -- Obsolete informational reference (is this intentional?): RFC 6833 (Obsoleted by RFC 9301) -- Obsolete informational reference (is this intentional?): RFC 6834 (Obsoleted by RFC 9302) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Iannone 3 Internet-Draft Telecom ParisTech 4 Intended status: Informational R. Jorgensen 5 Expires: October 8, 2016 Bredbandsfylket Troms 6 D. Conrad 7 Virtualized, LLC 8 G. Huston 9 APNIC - Asia Pacific Network 10 Information Center 11 April 6, 2016 13 LISP EID Block Management Guidelines 14 draft-ietf-lisp-eid-block-mgmnt-07.txt 16 Abstract 18 This document proposes a framework for the management of the LISP EID 19 Address Block. The framework described relies on hierarchical 20 distribution of the address space, granting temporary usage of 21 prefixes of such space to requesting organizations. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on October 8, 2016. 40 Copyright Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 58 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 60 4. EID Prefix Registration Policy . . . . . . . . . . . . . . . . 3 61 5. EID Prefixes Registration Requirements . . . . . . . . . . . . 4 62 6. EID Prefix Request Template . . . . . . . . . . . . . . . . . 5 63 7. Policy Validity Period . . . . . . . . . . . . . . . . . . . . 6 64 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 65 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 10. Procedures to be followed by RIPE NCC . . . . . . . . . . . . 8 67 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 68 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 12.1. Normative References . . . . . . . . . . . . . . . . . . 9 70 12.2. Informative References . . . . . . . . . . . . . . . . . 9 71 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 10 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 74 1. Requirements Notation 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in [RFC2119]. 80 2. Introduction 82 The Locator/ID Separation Protocol (LISP - [RFC6830]) and related 83 mechanisms ([RFC6831], [RFC6832], [RFC6833], [RFC6834], [RFC6835], 84 [RFC6836], [RFC6837]) separate the IP addressing space into two 85 logical spaces, the End-point IDentifier (EID) space and the Routing 86 LOCator (RLOC) space. The first space is used to identify 87 communication end-points, while the second is used to locate EIDs in 88 the Internet routing infrastructure topology. 90 The document [I-D.ietf-lisp-eid-block] requested an IPv6 address 91 block reservation exclusively for use as EID prefixes in the LISP 92 experiment. The rationale, intent, size, and usage of the EID 93 address block are described in [I-D.ietf-lisp-eid-block]. 95 This document proposes a management framework for the registration of 96 EID prefixes from that block, allowing the requesting organization 97 exclusive use of those EID prefixes limited to the duration of the 98 LISP experiment. 100 3. Definition of Terms 102 This document does not introduce any new terms related to the set of 103 LISP Specifications ([RFC6830], [RFC6831], [RFC6832], [RFC6833], 104 [RFC6834], [RFC6835], [RFC6836], [RFC6837]), but assumes that the 105 reader is familiar with the LISP terminology. 106 [I-D.ietf-lisp-introduction] provides an introduction to the LISP 107 technology, including its terminology. . 109 4. EID Prefix Registration Policy 111 The request for registration of EID prefixes MUST be done under the 112 following policies: 114 1. EID prefixes are made available in the reserved space on a 115 temporary basis and for experimental uses. The requester of an 116 experimental prefix MUST provide a short description of the 117 intended use or experiment that will be carried out (see 118 Section 6). If the prefix will be used for activities not 119 documented in the original description, the renewal of the 120 registration may be denied. 122 2. EID prefix registrations MUST be renewed on a regular basis to 123 ensure their use by active participants in the experiment. The 124 registration period is 12 months. A renewal SHOULD NOT cause a 125 change in the EID prefix registered in the previous request. The 126 conditions of registration renewal are the same as the conditions 127 of first EID prefix registration request. 129 3. It is preferable not to reuse EID prefixes whose registration is 130 expired. When an EID prefix registration is removed from the 131 registry, then the reuse of the EID prefix in a subsequent 132 registration on behalf of a different end user should be avoided 133 where possible. If the considerations of overall usage of the 134 EID block prefix requires reuse of a previously registered EID 135 prefix, then a minimum delay of at least one week between removal 136 and subsequent registration SHOULD be applied by the registry 137 operator. 139 4. All registrations of EID prefixes cease at the time of the 140 expiration of the reserved experimental LISP EID Block. The 141 further disposition of these prefixes and the associated registry 142 entries is to be specified in the announcement of the cessation 143 of this experiment. 145 5. EID Prefixes Registration Requirements 147 All EID prefix registrations MUST respect the following requirements: 149 1. All EID prefix registrations MUST use a globally unique EID 150 prefix. 152 2. The EID Prefix registration information, as specified in 153 Section 6, MUST be collected upon initial registration and 154 renewal, and made publicly available through interfaces allowing 155 both retrieval of specific registration details (search) and 156 enumeration of the entire registry contents (e.g., [RFC7481], 157 WHOIS, HTTP, or similar access methods). 159 3. The registry operator MUST permit the delegation of EID prefixes 160 in the reverse DNS space to holders of registered EID prefixes. 162 4. Anyone can obtain an entry in the EID prefix registry, on the 163 understanding that the prefix so registered is for the exclusive 164 use in the LISP experimental network, and that their registration 165 details (as specified in Section 6) are openly published in the 166 EID prefix registry. 168 6. EID Prefix Request Template 170 The following is a basic request template for prefix registration so 171 to ensure a uniform process. Such a template is inspired by the IANA 172 Private Enterprise Number online request form 173 (http://pen.iana.org/pen/PenApplication.page). 175 Note that all details in this registration become part of the 176 registry and will be published in the LISP EID Prefix Registry. 178 The EID Prefix Request template MUST at minimum contain: 180 1. Organization (In the case of individuals requesting an EID prefix 181 this section can be left empty) 183 (a) Organization Name 185 (b) Organization Address 187 (c) Organization Phone 189 (d) Organization WebSite 191 2. Contact Person (Mandatory) 193 (a) Name 195 (b) Address 197 (c) Phone 199 (d) Fax (optional) 201 (e) Email 203 3. EID Prefix Request (Mandatory) 205 (a) Prefix Size 207 + Expressed as an address prefix length. 209 (b) Prefix Size Rationale 211 (c) Lease Period 213 + Note Well: All EID Prefix registrations will be valid 214 until the earlier date of 12 months from the date of 215 registration or MMMM/YYYY3. 217 + All registrations may be renewed by the applicant for 218 further 12 month periods, ending on MMMM/YYYY3. 220 + According to the 3+3 year experimentation plan, defined 221 in [I-D.ietf-lisp-eid-block], all registrations MUST end 222 by MMMM/YYYY3, unless the IETF community decides to grant 223 a permanent LISP EID address block. In the latter case, 224 registrations following the present document policy MUST 225 end by MMMM/YYYY6 and a new policy (to be decided - see 226 Section 7) will apply afterwards. 228 4. Experiment Description 230 (a) Experiment and Deployment Description 232 (b) Interoperability with existing LISP deployments 234 (c) Interoperability with Legacy Internet 236 5. Reverse DNS Servers (Optional) 238 (a) Name server name: 240 (b) Name server address: 242 (c) Name server name: 244 (d) Name server address: 246 (Repeat if necessary) 248 7. Policy Validity Period 250 Policy outlined in the present document is tied to the existence of 251 the experimental LISP EID block requested in 252 [I-D.ietf-lisp-eid-block] and valid until MMMM/YYYY3. 254 If the IETF decides to transform the block in a permanent allocation, 255 the LISP EID block reserved usage period will be extended for three 256 years (until MMMM/YYYY6) so as to give time to the IETF to define, 257 following the policies outlined in [RFC5226], the final size of the 258 EID block and create a transition plan, while the policy in the 259 present document will still apply. 261 Note that, as stated in [I-D.ietf-lisp-eid-block], the transition of 262 the EID block into a permanent allocation has the potential to pose 263 policy issues (as recognized in [RFC2860], section 4.3) and hence 264 discussion with the IANA, the RIR communities, and the IETF community 265 will be necessary to determine appropriate policy for permanent EID 266 prefix management, which will be effective after MMMM/YYYY6. 268 [RFC Editor: please replace MMMM and all its occurrences in the 269 document with the month of publication of [I-D.ietf-lisp-eid-block] 270 as RFC.] 272 [RFC Editor: please replace YYYY0 and all its occurrences in the 273 document with the year of publication of [I-D.ietf-lisp-eid-block] as 274 RFC.] 276 [RFC Editor: please replace YYYY3 and all its occurrences in the 277 document with the year of publication of [I-D.ietf-lisp-eid-block] as 278 RFC plus 3 years, e.g., if published in 2016 then put 2019.] 280 [RFC Editor: please replace YYYY6 and all its occurrences in the 281 document with the year of publication of [I-D.ietf-lisp-eid-block] as 282 RFC plus 6 years, e.g., if published in 2016 then put 2022.] 284 8. Security Considerations 286 This document does not introduce new security threats in the LISP 287 architecture nor in the Legacy Internet architecture. 289 For accountability reasons and in line with the security 290 considerations in [RFC7020], each registration request MUST contain 291 accurate information on the requesting entity (company, institution, 292 individual, etc.) and valid and accurate contact information of a 293 referral person (see Section 6). 295 9. IANA Considerations 297 IANA allocated the following IPv6 address block for experimental use 298 as LISP EID prefix [I-D.ietf-lisp-eid-block]: 300 o Address Block: 2001:5::/32 302 o Name: EID Space for LISP 304 o RFC: [I-D.ietf-lisp-eid-block] 306 o Further Details at: http://www.iana.org/assignments/ 307 iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml 309 In order to grant requesting organisations and individuals exclusive 310 use of EID prefixes out of such reserved block (limited to the 311 duration of the LISP experiment as outlined in Section 7) there is an 312 operational requirement for an EID registration service. 314 Provided that the policies and requirements outlined in Section 4, 315 Section 5, and Section 6 are respected, EID prefix registration is 316 accorded based on a "First Come First Served" basis. 318 There is no hard limit in the number of registrations an organization 319 or individual can submit as long as information described in 320 Section 6 is provided, in particular point 4: "Experiment 321 Description". 323 For the duration defined in [I-D.ietf-lisp-eid-block] RIPE NCC will 324 manage the the LISP EID prefix as described herein. Therefore, this 325 document has no IANA actions. 327 10. Procedures to be followed by RIPE NCC 329 RIPE NCC will provide the registration service following the EID 330 Prefix Registration Policy (Section 4) and the EID Prefix 331 Registration Requirements (Section 5) provided in this document. The 332 request form provided by RIPE NCC will include at least the 333 information from the template in Section 6. RIPE NCC will make 334 publicly available all received requests. While this document does 335 not suggests any minimum allocation size, RIPE NCC is allowed to 336 introduce such minimum size for management purposes. 338 11. Acknowledgments 340 Thanks to A. Retana, J. Arko, P. Yee, A. de la Haye, A. Cima, A 341 Pawlik, J. Curran, A. Severin, B. Haberman, T. Manderson, D. Lewis, 342 D. Farinacci, M. Binderberger, D. Saucez, E. Lear, for their helpful 343 comments. 345 The work of Luigi Iannone has been partially supported by the ANR-13- 346 INFR-0009 LISP-Lab Project (www.lisp-lab.org) and the EIT KIC ICT- 347 Labs SOFNETS Project. 349 12. References 351 12.1. Normative References 353 [I-D.ietf-lisp-eid-block] 354 Iannone, L., Lewis, D., Meyer, D., and V. Fuller, "LISP 355 EID Block", draft-ietf-lisp-eid-block-13 (work in 356 progress), February 2016. 358 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 359 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 360 RFC2119, March 1997, 361 . 363 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 364 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 365 DOI 10.17487/RFC5226, May 2008, 366 . 368 12.2. Informative References 370 [I-D.ietf-lisp-introduction] 371 Cabellos-Aparicio, A. and D. Saucez, "An Architectural 372 Introduction to the Locator/ID Separation Protocol 373 (LISP)", draft-ietf-lisp-introduction-13 (work in 374 progress), April 2015. 376 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 377 Understanding Concerning the Technical Work of the 378 Internet Assigned Numbers Authority", RFC 2860, 379 DOI 10.17487/RFC2860, June 2000, 380 . 382 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 383 Locator/ID Separation Protocol (LISP)", RFC 6830, 384 DOI 10.17487/RFC6830, January 2013, 385 . 387 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 388 Locator/ID Separation Protocol (LISP) for Multicast 389 Environments", RFC 6831, DOI 10.17487/RFC6831, 390 January 2013, . 392 [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 393 "Interworking between Locator/ID Separation Protocol 394 (LISP) and Non-LISP Sites", RFC 6832, DOI 10.17487/ 395 RFC6832, January 2013, 396 . 398 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 399 Protocol (LISP) Map-Server Interface", RFC 6833, 400 DOI 10.17487/RFC6833, January 2013, 401 . 403 [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID 404 Separation Protocol (LISP) Map-Versioning", RFC 6834, 405 DOI 10.17487/RFC6834, January 2013, 406 . 408 [RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation 409 Protocol Internet Groper (LIG)", RFC 6835, DOI 10.17487/ 410 RFC6835, January 2013, 411 . 413 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, 414 "Locator/ID Separation Protocol Alternative Logical 415 Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, 416 January 2013, . 418 [RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to 419 Routing Locator (RLOC) Database", RFC 6837, DOI 10.17487/ 420 RFC6837, January 2013, 421 . 423 [RFC7020] Housley, R., Curran, J., Huston, G., and D. Conrad, "The 424 Internet Numbers Registry System", RFC 7020, DOI 10.17487/ 425 RFC7020, August 2013, 426 . 428 [RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the 429 Registration Data Access Protocol (RDAP)", RFC 7481, 430 DOI 10.17487/RFC7481, March 2015, 431 . 433 Appendix A. Document Change Log 435 Version 07 Posted April 2016. 437 o Addressed editorial issues raised in Gen-Art review by Peter Yee. 439 o Removed "Definition of Terms" section as suggested by Peter Yee in 440 the Gen-Art review. 442 o Section "IANA Considerations" has been re-written to fix issue 443 raised by IESG, IANA, and P. Yee. 445 o Deleted bullet allowing multiple operators in the requirements 446 section. Due to the limited duration of the experiment one single 447 registration operator (RIPE) is sufficient. 449 o Modified the dates, introducing variables, so to allow RFC Editor 450 to easily update dates by publication as RFC. 452 Version 06 Posted August 2015. 454 o Fixed Authors addresses and typo in section 10. 456 Version 05 Posted July 2015. 458 o Added explicit text about RIPE NCC providing the registration 459 service during the temporary experiment. 461 Version 04 Posted December 2014. 463 o Added two clarification sentences to address the comments of E. 464 Lear and D. Saucez during WG LC. 466 Version 03 Posted October 2014. 468 o Re-worded the document so to avoid confusion on "allocation" and 469 "assignement". The document now reffers to "registration". As 470 for comments by G. Huston and M. Binderberger. 472 Version 02 Posted July 2014. 474 o Deleted the trailing paragraph of Section 4, as for discussion in 475 the mailing list. 477 o Deleted the fees policy as of suggestion of G. Huston and 478 discussion during 89th IETF. 480 o Re-phrased the availability of the registration information 481 requirement avoiding putting specific numbers (previously 482 requiring 99% up time), as of suggestion of G. Huston and 483 discussion during 89th IETF. 485 Version 01 Posted February 2014. 487 o Dropped the reverse DNS requirement as for discussion during the 488 88th IETF meeting. 490 o Dropped the minimum allocation requirement as for discussion 491 during the 88th IETF meeting. 493 o Changed Section 7 from "General Consideration" to "Policy Validity 494 Period", according to J. Curran feedback. The purpose of the 495 section is just to clearly state the period during which the 496 policy applies. 498 Version 00 Posted December 2013. 500 o Rename of draft-iannone-lisp-eid-block-mgmnt-03.txt. 502 Authors' Addresses 504 Luigi Iannone 505 Telecom ParisTech 506 France 508 Email: ggx@gigix.net 510 Roger Jorgensen 511 Bredbandsfylket Troms 512 Norway 514 Email: rogerj@gmail.com 516 David Conrad 517 Virtualized, LLC 518 USA 520 Email: drc@virtualized.org 522 Geoff Huston 523 APNIC - Asia Pacific Network Information Center 524 Australia 526 Email: gih@apnic.net