idnits 2.17.1 draft-ietf-lisp-eid-block-mgmnt-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 24, 2014) is 3444 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-13) exists of draft-ietf-lisp-eid-block-09 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-12) exists of draft-ietf-weirds-rdap-sec-06 -- 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: April 27, 2015 Bredbandsfylket Troms 6 D. Conrad 7 Virtualized, LLC 8 G. Huston 9 APNIC - Asia Pacific Network Information Center 10 October 24, 2014 12 LISP EID Block Management Guidelines 13 draft-ietf-lisp-eid-block-mgmnt-03.txt 15 Abstract 17 This document proposes a framework for the management of the LISP EID 18 Prefix. The framework described relies on hierarchical distribution 19 of the address space, granting temporary usage of sub-prefixes of 20 such space to requesting organizations. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 27, 2015. 39 Copyright Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 2 57 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 59 4. EID Prefix Registration Policy . . . . . . . . . . . . . . . 3 60 5. EID Prefixes Registration Requirements . . . . . . . . . . . 4 61 6. EID Prefix Request Template . . . . . . . . . . . . . . . . . 4 62 7. Policy Validity Period . . . . . . . . . . . . . . . . . . . 6 63 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 65 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 11.1. Normative References . . . . . . . . . . . . . . . . . . 7 68 11.2. Informative References . . . . . . . . . . . . . . . . . 7 69 Appendix A. LISP Terms . . . . . . . . . . . . . . . . . . . . . 8 70 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 11 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 73 1. Requirements Notation 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in [RFC2119]. 79 2. Introduction 81 The Locator/ID Separation Protocol (LISP - [RFC6830]) and related 82 mechanisms ([RFC6831], [RFC6832], [RFC6833], [RFC6834], [RFC6835], 83 [RFC6836], [RFC6837]) separates the IP addressing space into two 84 logical spaces, the End-point IDentifier (EID) space and the Routing 85 LOCator (RLOC) space. The first space is used to identify 86 communication end-points, while the second is used to locate EIDs in 87 the Internet routing infrastructure topology. 89 The document [I-D.ietf-lisp-eid-block] requested an IPv6 address 90 block reservation exclusively for use as EID prefixes in the LISP 91 experiment. The rationale, intent, size, and usage of the EID 92 address block are described in [I-D.ietf-lisp-eid-block]. 94 This document proposes a management framework for the registration of 95 EID prefixes from that block, allowing the requesting organisation 96 exclusive use of those EID prefixes limited to the duration of the 97 LISP experiment. 99 3. Definition of Terms 101 This document does not introduce any new terms related to the set of 102 LISP Specifications ( [RFC6830], [RFC6831], [RFC6832], [RFC6833], 103 [RFC6834], [RFC6835], [RFC6836], [RFC6837]). To help the reading of 104 this document the terminology introduced by LISP is summarized in 105 Appendix A. 107 4. EID Prefix Registration Policy 109 The request registration of EID prefixes MUST be done under the 110 following policies: 112 1. EID prefixes are made available in the reserved space on a 113 temporary basis and for experimental uses. The requester of an 114 experimental prefix MUST provide a short description of the 115 intended use or experiment that will be carried out (see 116 Section 6). If the prefix will be used for activities not 117 documented in the original description, the renewal of the 118 registration may be denied. 120 2. EID prefix registrations SHOULD be renewed on a regular basis to 121 ensure their use by active participants in the experiment. The 122 registration period is proposed to be 12 months. Registration 123 renewal SHOULD NOT cause a change in the registered EID prefix. 124 The conditions of registration renewal should no different to the 125 conditions of registration. 127 3. When an EID prefix registration is removed from the registry, 128 then the reuse of the EID prefix in a subsequent registration on 129 behalf of a different end user should be avoided where possible. 130 If the considerations of overall usage of the EID block prefix 131 requires reuse of a previously registered EID prefix, then a 132 minimum delay of at least one week between removal and subsequent 133 registration SHOULD be applied by the registry operator. 135 4. All registrations of EID prefixes cease at the time of the 136 expiration of the reserved experimental LISP EID Block. The 137 further disposition of these prefixes and the associated registry 138 entries is to be specified in the announcement of the cessation 139 of this experiment. 141 5. EID Prefixes Registration Requirements 143 All EID prefix registrations MUST respect the following requirements: 145 1. All EID prefix registrations MUST use a globally unique EID 146 prefix. 148 2. If there is more than one registry operator, all operators MUST 149 use the same registry management policies and practices. 151 3. The EID Prefix registration information as specified in 152 Section 6, MUST be collected upon initial registration and 153 renewal, and made publicly available though interfaces allowing 154 both retrieval of specific registration details (search) and 155 enumeration of the entire registry contents (e.g., 156 [I-D.ietf-weirds-rdap-sec], whois, http, or similar access 157 methods). 159 4. The registry operator MUST permit the delegation of EID prefixes 160 in the reverse DNS space to holders of registered EID prefixes. 162 5. 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 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 2. Contact Person (Mandatory) 191 (a) Name 193 (b) Address 195 (c) Phone 197 (d) Fax (optional) 199 (e) Email 201 3. EID Prefix Request (Mandatory) 203 (a) Prefix Size 205 (b) Prefix Size Rationale 207 (c) Lease Period 209 + Note Well: All EID Prefix registrations will be valid until 210 the earlier date of 12 months from the date of registration 211 or 31 December 2017. 213 + All registrations may be renewed by the applicant for 214 further 12 month periods, ending on 31 December 2017. 216 + According to the 3+3 year experimentation plan, defined in 217 [I-D.ietf-lisp-eid-block], all registrations MUST end by 31 218 December 2017, unless the IETF community decides to grant a 219 permanent LISP EID address block. In the latter case, 220 registrations following the present document policy MUST end 221 by 31 December 2020 and a new policy (to be decided - see 222 Section 7) will apply starting 1 January 2021. 224 4. Experiment Description 226 (a) Experiment and Deployment Description 228 (b) Interoperability with existing LISP deployments 230 (c) Interoperability with Legacy Internet 232 5. Reverse DNS Servers (Optional) 234 (a) Name server name: 236 (b) Name server address: 238 (c) Name server name: 240 (d) Name server address: 242 (Repeat if necessary) 244 7. Policy Validity Period 246 Policy outlined in the present document is tied to the existence of 247 the experimental LISP EID block requested in 248 [I-D.ietf-lisp-eid-block] and valid until 31 December 2017. 250 If the IETF decides to transform the block in a permanent allocation, 251 the LISP EID block reserved usage period will be extended for three 252 years (until 31 December 2020) so to give time to the IETF to define, 253 following the policies outlined in [RFC5226], the final size of the 254 EID block and create a transition plan, while the policy in the 255 present document will still apply. 257 Note that, as stated in [I-D.ietf-lisp-eid-block], the transition of 258 the EID block into a permanent allocation, has the potential to pose 259 policy issues (as recognized in [RFC2860], section 4.3) and hence 260 discussion with the IANA, the RIR communities, and the IETF community 261 will be necessary to determine appropriate policy for permanent EID 262 prefix management, which will be effective starting 1 January 2021. 264 8. Security Considerations 266 This document does not introduce new security threats in the LISP 267 architecture nor in the Legacy Internet architecture. 269 For accountability reasons, and in line with the security 270 considerations in [RFC7020], each registration request MUST contain 271 accurate information on the requesting entity (company, institution, 272 individual, etc.) and valid and accurate contact information of a 273 referral person (see Section 6). 275 9. Acknowledgments 277 Thanks to J. Curran, A. Severin, B. Haberman, T. Manderson, D. 278 Lewis, D. Farinacci, M. Binderberger, for their helpful comments. 280 The work of Luigi Iannone has been partially supported by the ANR- 281 13-INFR-0009 LISP-Lab Project (www.lisp-lab.org) and the EIT KIC ICT- 282 Labs SOFNETS Project. 284 10. IANA Considerations 286 This document provides only management guidelines for the reserved 287 LISP EID prefix requested in [I-D.ietf-lisp-eid-block]. 289 There is an operational requirement for an EID registration service 290 that ensures uniqueness of EIDs according to the requirements 291 described in Section 5. Furthermore, there is an operational 292 requirement for EID registration service that allows a lookup of the 293 contact information of the entity that registered the EID. 295 IANA is to ensure both of these services are provided in a globally 296 uniform fashion for the duration of the experiment. 298 11. References 300 11.1. Normative References 302 [I-D.ietf-lisp-eid-block] 303 Iannone, L., Lewis, D., Meyer, D., and V. Fuller, "LISP 304 EID Block", draft-ietf-lisp-eid-block-09 (work in 305 progress), July 2014. 307 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 308 Requirement Levels", BCP 14, RFC 2119, March 1997. 310 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 311 (CIDR): The Internet Address Assignment and Aggregation 312 Plan", BCP 122, RFC 4632, August 2006. 314 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 315 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 316 May 2008. 318 11.2. Informative References 320 [I-D.ietf-weirds-rdap-sec] 321 Hollenbeck, S. and N. Kong, "Security Services for the 322 Registration Data Access Protocol", draft-ietf-weirds- 323 rdap-sec-06 (work in progress), February 2014. 325 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 326 Understanding Concerning the Technical Work of the 327 Internet Assigned Numbers Authority", RFC 2860, June 2000. 329 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 330 Locator/ID Separation Protocol (LISP)", RFC 6830, January 331 2013. 333 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 334 Locator/ID Separation Protocol (LISP) for Multicast 335 Environments", RFC 6831, January 2013. 337 [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 338 "Interworking between Locator/ID Separation Protocol 339 (LISP) and Non-LISP Sites", RFC 6832, January 2013. 341 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 342 Protocol (LISP) Map-Server Interface", RFC 6833, January 343 2013. 345 [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID 346 Separation Protocol (LISP) Map-Versioning", RFC 6834, 347 January 2013. 349 [RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation 350 Protocol Internet Groper (LIG)", RFC 6835, January 2013. 352 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, 353 "Locator/ID Separation Protocol Alternative Logical 354 Topology (LISP+ALT)", RFC 6836, January 2013. 356 [RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to 357 Routing Locator (RLOC) Database", RFC 6837, January 2013. 359 [RFC7020] Housley, R., Curran, J., Huston, G., and D. Conrad, "The 360 Internet Numbers Registry System", RFC 7020, August 2013. 362 Appendix A. LISP Terms 364 LISP operates on two name spaces and introduces several new network 365 elements. This section provides high-level definitions of the LISP 366 name spaces and network elements and as such, it must not be 367 considered as an authoritative source. The reference to the 368 authoritative document for each term is included in every term 369 description. 371 Legacy Internet: The portion of the Internet that does not run LISP 372 and does not participate in LISP+ALT or any other mapping system. 374 LISP site: A LISP site is a set of routers in an edge network that 375 are under a single technical administration. LISP routers that 376 reside in the edge network are the demarcation points to separate 377 the edge network from the core network. See [RFC6830] for more 378 details. 380 Endpoint ID (EID): An EID is a 32-bit (for IPv4) or 128-bit (for 381 IPv6) value used in the source and destination address fields of 382 the first (most inner) LISP header of a packet. A packet that is 383 emitted by a system contains EIDs in its headers and LISP headers 384 are prepended only when the packet reaches an Ingress Tunnel 385 Router (ITR) on the data path to the destination EID. The source 386 EID is obtained via existing mechanisms used to set a host's 387 "local" IP address. An EID is allocated to a host from an EID- 388 prefix block associated with the site where the host is located. 389 See [RFC6830] for more details. 391 EID-prefix: A power-of-two block of EIDs that are allocated to a 392 site by an address allocation authority. See [RFC6830] for more 393 details. 395 EID-Prefix Aggregate: A set of EID-prefixes said to be aggregatable 396 in the [RFC4632] sense. That is, an EID-Prefix aggregate is 397 defined to be a single contiguous power-of-two EID-prefix block. 398 A prefix and a length characterize such a block. See [RFC6830] 399 for more details. 401 Routing LOCator (RLOC): A RLOC is an IPv4 or IPv6 address of an 402 egress tunnel router (ETR). A RLOC is the output of an EID-to- 403 RLOC mapping lookup. An EID maps to one or more RLOCs. 404 Typically, RLOCs are numbered from topologically aggregatable 405 blocks that are assigned to a site at each point to which it 406 attaches to the global Internet; where the topology is defined by 407 the connectivity of provider networks, RLOCs can be thought of as 408 Provider Aggregatable (PA) addresses. See [RFC6830] for more 409 details. 411 EID-to-RLOC Mapping: A binding between an EID-Prefix and the RLOC- 412 set that can be used to reach the EID-Prefix. The general term 413 "mapping" always refers to an EID-to-RLOC mapping. See [RFC6830] 414 for more details. 416 Ingress Tunnel Router (ITR): An Ingress Tunnel Router (ITR) is a 417 router that accepts receives IP packets from site end-systems on 418 one side and sends LISP-encapsulated IP packets toward the 419 Internet on the other side. The router treats the "inner" IP 420 destination address as an EID and performs an EID-to-RLOC mapping 421 lookup. The router then prepends an "outer" IP header with one of 422 its globally routable RLOCs in the source address field and the 423 result of the mapping lookup in the destination address field. 424 See [RFC6830] for more details. 426 Egress Tunnel Router (ETR): An Egress Tunnel Router (ETR) receives 427 LISP-encapsulated IP packets from the Internet on one side and 428 sends decapsulated IP packets to site end-systems on the other 429 side. An ETR router accepts an IP packet where the destination 430 address in the "outer" IP header is one of its own RLOCs. The 431 router strips the "outer" header and forwards the packet based on 432 the next IP header found. See [RFC6830] for more details. 434 Proxy ITR (PITR): A Proxy-ITR (PITR) acts like an ITR but does so on 435 behalf of non-LISP sites which send packets to destinations at 436 LISP sites. See [RFC6832] for more details. 438 Proxy ETR (PETR): A Proxy-ETR (PETR) acts like an ETR but does so on 439 behalf of LISP sites which send packets to destinations at non- 440 LISP sites. See [RFC6832] for more details. 442 Map Server (MS): A network infrastructure component that learns EID- 443 to-RLOC mapping entries from an authoritative source (typically an 444 ETR). A Map Server publishes these mappings in the distributed 445 mapping system. See [RFC6833] for more details. 447 Map Resolver (MR): A network infrastructure component that accepts 448 LISP Encapsulated Map-Requests, typically from an ITR, quickly 449 determines whether or not the destination IP address is part of 450 the EID namespace; if it is not, a Negative Map-Reply is 451 immediately returned. Otherwise, the Map Resolver finds the 452 appropriate EID-to-RLOC mapping by consulting the distributed 453 mapping database system. See [RFC6833] for more details. 455 The LISP Alternative Logical Topology (ALT): The virtual overlay 456 network made up of tunnels between LISP+ALT Routers. The Border 457 Gateway Protocol (BGP) runs between ALT Routers and is used to 458 carry reachability information for EID-prefixes. The ALT provides 459 a way to forward Map-Requests toward the ETR that "owns" an EID- 460 prefix. See [RFC6836] for more details. 462 ALT Router: The device on which runs the ALT. The ALT is a static 463 network built using tunnels between ALT Routers. These routers 464 are deployed in a roughly-hierarchical mesh in which routers at 465 each level in the topology are responsible for aggregating EID- 466 Prefixes learned from those logically "below" them and advertising 467 summary prefixes to those logically "above" them. Prefix learning 468 and propagation between ALT Routers is done using BGP. When an 469 ALT Router receives an ALT Datagram, it looks up the destination 470 EID in its forwarding table (composed of EID-Prefix routes it 471 learned from neighboring ALT Routers) and forwards it to the 472 logical next-hop on the overlay network. The primary function of 473 LISP+ALT routers is to provide a lightweight forwarding 474 infrastructure for LISP control-plane messages (Map-Request and 475 Map-Reply), and to transport data packets when the packet has the 476 same destination address in both the inner (encapsulating) 477 destination and outer destination addresses ((i.e., a Data Probe 478 packet). See [RFC6830] for more details. 480 Appendix B. Document Change Log 482 Version 03 Posted October 2014. 484 o Re-worded the document so to avoid confusion on "allocation" and 485 "assignement". The document now reffers to "registration". As 486 for comments by G. Huston and M. Binderberger. 488 Version 02 Posted July 2014. 490 o Deleted the trailing paragraph of Section 4, as for discussion in 491 the mailing list. 493 o Deleted the fees policy as of suggestion of G. Huston and 494 discussion during 89th IETF. 496 o Re-phrased the availability of the registration information 497 requirement avoiding putting specific numbers (previously 498 requiring 99% up time), as of suggestion of G. Huston and 499 discussion during 89th IETF. 501 Version 01 Posted February 2014. 503 o Dropped the reverse DNS requirement as for discussion during the 504 88th IETF meeting. 506 o Dropped the minimum allocation requirement as for discussion 507 during the 88th IETF meeting. 509 o Changed Section 7 from "General Consideration" to "Policy Validity 510 Period", according to J. Curran feedback. The purpose of the 511 section is just to clearly state the period during which the 512 policy applies. 514 Version 00 Posted December 2013. 516 o Rename of draft-iannone-lisp-eid-block-mgmnt-03.txt. 518 Authors' Addresses 520 Luigi Iannone 521 Telecom ParisTech 523 Email: ggx@gigix.net 524 Roger Jorgensen 525 Bredbandsfylket Troms 527 Email: rogerj@gmail.com 529 David Conrad 530 Virtualized, LLC 532 Email: drc@virtualized.org 534 Geoff Huston 535 APNIC - Asia Pacific Network Information Center 537 Email: gih@apnic.net