idnits 2.17.1 draft-ietf-lisp-eid-block-mgmnt-04.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 (December 31, 2014) is 3403 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) -- 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 (~~), 2 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: July 4, 2015 Bredbandsfylket Troms 6 D. Conrad 7 Virtualized, LLC 8 G. Huston 9 APNIC - Asia Pacific Network 10 Information Center 11 December 31, 2014 13 LISP EID Block Management Guidelines 14 draft-ietf-lisp-eid-block-mgmnt-04.txt 16 Abstract 18 This document proposes a framework for the management of the LISP EID 19 Prefix. The framework described relies on hierarchical distribution 20 of the address space, granting temporary usage of sub-prefixes of 21 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 July 4, 2015. 40 Copyright Notice 42 Copyright (c) 2014 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. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 66 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 67 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 11.1. Normative References . . . . . . . . . . . . . . . . . . 8 69 11.2. Informative References . . . . . . . . . . . . . . . . . 8 70 Appendix A. LISP Terms . . . . . . . . . . . . . . . . . . . . . 9 71 Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 12 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]) separates 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 organisation 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]). To help the reading of 105 this document the terminology introduced by LISP is summarized in 106 Appendix A. 108 4. EID Prefix Registration Policy 110 The request registration of EID prefixes MUST be done under the 111 following policies: 113 1. EID prefixes are made available in the reserved space on a 114 temporary basis and for experimental uses. The requester of an 115 experimental prefix MUST provide a short description of the 116 intended use or experiment that will be carried out (see 117 Section 6). If the prefix will be used for activities not 118 documented in the original description, the renewal of the 119 registration may be denied. 121 2. EID prefix registrations SHOULD be renewed on a regular basis to 122 ensure their use by active participants in the experiment. The 123 registration period is proposed to be 12 months. Registration 124 renewal SHOULD NOT cause a change in the registered EID prefix. 125 The conditions of registration renewal should no different to the 126 conditions of registration. 128 3. It is preferable not to reuse EID prefixes whose registration is 129 expired. When an EID prefix registration is removed from the 130 registry, then the reuse of the EID prefix in a subsequent 131 registration on behalf of a different end user should be avoided 132 where possible. If the considerations of overall usage of the 133 EID block prefix requires reuse of a previously registered EID 134 prefix, then a minimum delay of at least one week between removal 135 and subsequent registration SHOULD be applied by the registry 136 operator. 138 4. All registrations of EID prefixes cease at the time of the 139 expiration of the reserved experimental LISP EID Block. The 140 further disposition of these prefixes and the associated registry 141 entries is to be specified in the announcement of the cessation 142 of this experiment. 144 5. EID Prefixes Registration Requirements 146 All EID prefix registrations MUST respect the following requirements: 148 1. All EID prefix registrations MUST use a globally unique EID 149 prefix. 151 2. If there is more than one registry operator, all operators MUST 152 use the same registry management policies and practices. 154 3. The EID Prefix registration information as specified in 155 Section 6, MUST be collected upon initial registration and 156 renewal, and made publicly available though interfaces allowing 157 both retrieval of specific registration details (search) and 158 enumeration of the entire registry contents (e.g., 159 [I-D.ietf-weirds-rdap-sec], whois, http, or similar access 160 methods). 162 4. The registry operator MUST permit the delegation of EID prefixes 163 in the reverse DNS space to holders of registered EID prefixes. 165 5. Anyone can obtain an entry in the EID prefix registry, on the 166 understanding that the prefix so registered is for the exclusive 167 use in the LISP experimental network, and that their registration 168 details (as specified in Section 6) are openly published in the 169 EID prefix registry. 171 6. EID Prefix Request Template 173 The following is a basic request template for prefix registration so 174 to ensure a uniform process. Such a template is inspired by the IANA 175 Private Enterprise Number online request form 176 (http://pen.iana.org/pen/PenApplication.page). 178 Note that all details in this registration become part of the 179 registry, and will be published in the LISP EID Prefix Registry. 181 The EID Prefix Request template MUST at minimum contain: 183 1. Organization (In case of individuals requesting an EID prefix 184 this section can be left empty) 186 (a) Organization Name 188 (b) Organization Address 190 (c) Organization Phone 192 2. Contact Person (Mandatory) 194 (a) Name 196 (b) Address 198 (c) Phone 200 (d) Fax (optional) 202 (e) Email 204 3. EID Prefix Request (Mandatory) 206 (a) Prefix Size 208 + Expressed as an address prefix length. 210 (b) Prefix Size Rationale 212 (c) Lease Period 214 + Note Well: All EID Prefix registrations will be valid 215 until the earlier date of 12 months from the date of 216 registration or 31 December 2017. 218 + All registrations may be renewed by the applicant for 219 further 12 month periods, ending on 31 December 2017. 221 + According to the 3+3 year experimentation plan, defined 222 in [I-D.ietf-lisp-eid-block], all registrations MUST end 223 by 31 December 2017, unless the IETF community decides to 224 grant a permanent LISP EID address block. In the latter 225 case, registrations following the present document policy 226 MUST end by 31 December 2020 and a new policy (to be 227 decided - see Section 7) will apply starting 1 January 228 2021. 230 4. Experiment Description 232 (a) Experiment and Deployment Description 234 (b) Interoperability with existing LISP deployments 236 (c) Interoperability with Legacy Internet 238 5. Reverse DNS Servers (Optional) 240 (a) Name server name: 242 (b) Name server address: 244 (c) Name server name: 246 (d) Name server address: 248 (Repeat if necessary) 250 7. Policy Validity Period 252 Policy outlined in the present document is tied to the existence of 253 the experimental LISP EID block requested in 254 [I-D.ietf-lisp-eid-block] and valid until 31 December 2017. 256 If the IETF decides to transform the block in a permanent allocation, 257 the LISP EID block reserved usage period will be extended for three 258 years (until 31 December 2020) so to give time to the IETF to define, 259 following the policies outlined in [RFC5226], the final size of the 260 EID block and create a transition plan, while the policy in the 261 present document will still apply. 263 Note that, as stated in [I-D.ietf-lisp-eid-block], the transition of 264 the EID block into a permanent allocation, has the potential to pose 265 policy issues (as recognized in [RFC2860], section 4.3) and hence 266 discussion with the IANA, the RIR communities, and the IETF community 267 will be necessary to determine appropriate policy for permanent EID 268 prefix management, which will be effective starting 1 January 2021. 270 8. Security Considerations 272 This document does not introduce new security threats in the LISP 273 architecture nor in the Legacy Internet architecture. 275 For accountability reasons, and in line with the security 276 considerations in [RFC7020], each registration request MUST contain 277 accurate information on the requesting entity (company, institution, 278 individual, etc.) and valid and accurate contact information of a 279 referral person (see Section 6). 281 9. Acknowledgments 283 Thanks to J. Curran, A. Severin, B. Haberman, T. Manderson, D. Lewis, 284 D. Farinacci, M. Binderberger, D. Saucez, E. Lear, for their helpful 285 comments. 287 The work of Luigi Iannone has been partially supported by the ANR-13- 288 INFR-0009 LISP-Lab Project (www.lisp-lab.org) and the EIT KIC ICT- 289 Labs SOFNETS Project. 291 10. IANA Considerations 293 This document provides only management guidelines for the reserved 294 LISP EID prefix requested in [I-D.ietf-lisp-eid-block]. 296 There is an operational requirement for an EID registration service 297 that ensures uniqueness of EIDs according to the requirements 298 described in Section 5. Furthermore, there is an operational 299 requirement for EID registration service that allows a lookup of the 300 contact information of the entity that registered the EID. 302 IANA is to ensure both of these services are provided in a globally 303 uniform fashion for the duration of the experiment. 305 11. References 307 11.1. Normative References 309 [I-D.ietf-lisp-eid-block] 310 Iannone, L., Lewis, D., Meyer, D., and V. Fuller, "LISP 311 EID Block", draft-ietf-lisp-eid-block-09 (work in 312 progress), July 2014. 314 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 315 Requirement Levels", BCP 14, RFC 2119, March 1997. 317 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 318 (CIDR): The Internet Address Assignment and Aggregation 319 Plan", BCP 122, RFC 4632, August 2006. 321 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 322 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 323 May 2008. 325 11.2. Informative References 327 [I-D.ietf-weirds-rdap-sec] 328 Hollenbeck, S. and N. Kong, "Security Services for the 329 Registration Data Access Protocol", 330 draft-ietf-weirds-rdap-sec-12 (work in progress), 331 December 2014. 333 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 334 Understanding Concerning the Technical Work of the 335 Internet Assigned Numbers Authority", RFC 2860, June 2000. 337 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 338 Locator/ID Separation Protocol (LISP)", RFC 6830, 339 January 2013. 341 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 342 Locator/ID Separation Protocol (LISP) for Multicast 343 Environments", RFC 6831, January 2013. 345 [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 346 "Interworking between Locator/ID Separation Protocol 347 (LISP) and Non-LISP Sites", RFC 6832, January 2013. 349 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 350 Protocol (LISP) Map-Server Interface", RFC 6833, 351 January 2013. 353 [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID 354 Separation Protocol (LISP) Map-Versioning", RFC 6834, 355 January 2013. 357 [RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation 358 Protocol Internet Groper (LIG)", RFC 6835, January 2013. 360 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, 361 "Locator/ID Separation Protocol Alternative Logical 362 Topology (LISP+ALT)", RFC 6836, January 2013. 364 [RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to 365 Routing Locator (RLOC) Database", RFC 6837, January 2013. 367 [RFC7020] Housley, R., Curran, J., Huston, G., and D. Conrad, "The 368 Internet Numbers Registry System", RFC 7020, August 2013. 370 Appendix A. LISP Terms 372 LISP operates on two name spaces and introduces several new network 373 elements. This section provides high-level definitions of the LISP 374 name spaces and network elements and as such, it must not be 375 considered as an authoritative source. The reference to the 376 authoritative document for each term is included in every term 377 description. 379 Legacy Internet: The portion of the Internet that does not run LISP 380 and does not participate in LISP+ALT or any other mapping system. 382 LISP site: A LISP site is a set of routers in an edge network that 383 are under a single technical administration. LISP routers that 384 reside in the edge network are the demarcation points to separate 385 the edge network from the core network. See [RFC6830] for more 386 details. 388 Endpoint ID (EID): An EID is a 32-bit (for IPv4) or 128-bit (for 389 IPv6) value used in the source and destination address fields of 390 the first (most inner) LISP header of a packet. A packet that is 391 emitted by a system contains EIDs in its headers and LISP headers 392 are prepended only when the packet reaches an Ingress Tunnel 393 Router (ITR) on the data path to the destination EID. The source 394 EID is obtained via existing mechanisms used to set a host's 395 "local" IP address. An EID is allocated to a host from an EID- 396 prefix block associated with the site where the host is located. 397 See [RFC6830] for more details. 399 EID-prefix: A power-of-two block of EIDs that are allocated to a 400 site by an address allocation authority. See [RFC6830] for more 401 details. 403 EID-Prefix Aggregate: A set of EID-prefixes said to be aggregatable 404 in the [RFC4632] sense. That is, an EID-Prefix aggregate is 405 defined to be a single contiguous power-of-two EID-prefix block. 406 A prefix and a length characterize such a block. See [RFC6830] 407 for more details. 409 Routing LOCator (RLOC): A RLOC is an IPv4 or IPv6 address of an 410 egress tunnel router (ETR). A RLOC is the output of an EID-to- 411 RLOC mapping lookup. An EID maps to one or more RLOCs. 412 Typically, RLOCs are numbered from topologically aggregatable 413 blocks that are assigned to a site at each point to which it 414 attaches to the global Internet; where the topology is defined by 415 the connectivity of provider networks, RLOCs can be thought of as 416 Provider Aggregatable (PA) addresses. See [RFC6830] for more 417 details. 419 EID-to-RLOC Mapping: A binding between an EID-Prefix and the RLOC- 420 set that can be used to reach the EID-Prefix. The general term 421 "mapping" always refers to an EID-to-RLOC mapping. See [RFC6830] 422 for more details. 424 Ingress Tunnel Router (ITR): An Ingress Tunnel Router (ITR) is a 425 router that accepts receives IP packets from site end-systems on 426 one side and sends LISP-encapsulated IP packets toward the 427 Internet on the other side. The router treats the "inner" IP 428 destination address as an EID and performs an EID-to-RLOC mapping 429 lookup. The router then prepends an "outer" IP header with one of 430 its globally routable RLOCs in the source address field and the 431 result of the mapping lookup in the destination address field. 432 See [RFC6830] for more details. 434 Egress Tunnel Router (ETR): An Egress Tunnel Router (ETR) receives 435 LISP-encapsulated IP packets from the Internet on one side and 436 sends decapsulated IP packets to site end-systems on the other 437 side. An ETR router accepts an IP packet where the destination 438 address in the "outer" IP header is one of its own RLOCs. The 439 router strips the "outer" header and forwards the packet based on 440 the next IP header found. See [RFC6830] for more details. 442 Proxy ITR (PITR): A Proxy-ITR (PITR) acts like an ITR but does so on 443 behalf of non-LISP sites which send packets to destinations at 444 LISP sites. See [RFC6832] for more details. 446 Proxy ETR (PETR): A Proxy-ETR (PETR) acts like an ETR but does so on 447 behalf of LISP sites which send packets to destinations at non- 448 LISP sites. See [RFC6832] for more details. 450 Map Server (MS): A network infrastructure component that learns EID- 451 to-RLOC mapping entries from an authoritative source (typically an 452 ETR). A Map Server publishes these mappings in the distributed 453 mapping system. See [RFC6833] for more details. 455 Map Resolver (MR): A network infrastructure component that accepts 456 LISP Encapsulated Map-Requests, typically from an ITR, quickly 457 determines whether or not the destination IP address is part of 458 the EID namespace; if it is not, a Negative Map-Reply is 459 immediately returned. Otherwise, the Map Resolver finds the 460 appropriate EID-to-RLOC mapping by consulting the distributed 461 mapping database system. See [RFC6833] for more details. 463 The LISP Alternative Logical Topology (ALT): The virtual overlay 464 network made up of tunnels between LISP+ALT Routers. The Border 465 Gateway Protocol (BGP) runs between ALT Routers and is used to 466 carry reachability information for EID-prefixes. The ALT provides 467 a way to forward Map-Requests toward the ETR that "owns" an EID- 468 prefix. See [RFC6836] for more details. 470 ALT Router: The device on which runs the ALT. The ALT is a static 471 network built using tunnels between ALT Routers. These routers 472 are deployed in a roughly-hierarchical mesh in which routers at 473 each level in the topology are responsible for aggregating EID- 474 Prefixes learned from those logically "below" them and advertising 475 summary prefixes to those logically "above" them. Prefix learning 476 and propagation between ALT Routers is done using BGP. When an 477 ALT Router receives an ALT Datagram, it looks up the destination 478 EID in its forwarding table (composed of EID-Prefix routes it 479 learned from neighboring ALT Routers) and forwards it to the 480 logical next-hop on the overlay network. The primary function of 481 LISP+ALT routers is to provide a lightweight forwarding 482 infrastructure for LISP control-plane messages (Map-Request and 483 Map-Reply), and to transport data packets when the packet has the 484 same destination address in both the inner (encapsulating) 485 destination and outer destination addresses ((i.e., a Data Probe 486 packet). See [RFC6830] for more details. 488 Appendix B. Document Change Log 490 Version 04 Posted December 2014. 492 o Added two clarification sentences to address the comments of E. 493 Lear and D. Saucez during WG LC. 495 Version 03 Posted October 2014. 497 o Re-worded the document so to avoid confusion on "allocation" and 498 "assignement". The document now reffers to "registration". As 499 for comments by G. Huston and M. Binderberger. 501 Version 02 Posted July 2014. 503 o Deleted the trailing paragraph of Section 4, as for discussion in 504 the mailing list. 506 o Deleted the fees policy as of suggestion of G. Huston and 507 discussion during 89th IETF. 509 o Re-phrased the availability of the registration information 510 requirement avoiding putting specific numbers (previously 511 requiring 99% up time), as of suggestion of G. Huston and 512 discussion during 89th IETF. 514 Version 01 Posted February 2014. 516 o Dropped the reverse DNS requirement as for discussion during the 517 88th IETF meeting. 519 o Dropped the minimum allocation requirement as for discussion 520 during the 88th IETF meeting. 522 o Changed Section 7 from "General Consideration" to "Policy Validity 523 Period", according to J. Curran feedback. The purpose of the 524 section is just to clearly state the period during which the 525 policy applies. 527 Version 00 Posted December 2013. 529 o Rename of draft-iannone-lisp-eid-block-mgmnt-03.txt. 531 Authors' Addresses 533 Luigi Iannone 534 Telecom ParisTech 536 Email: ggx@gigix.net 538 Roger Jorgensen 539 Bredbandsfylket Troms 541 Email: rogerj@gmail.com 543 David Conrad 544 Virtualized, LLC 546 Email: drc@virtualized.org 548 Geoff Huston 549 APNIC - Asia Pacific Network Information Center 551 Email: gih@apnic.net