idnits 2.17.1 draft-iannone-lisp-eid-block-mgmnt-01.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 (February 25, 2013) is 4076 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-03 ** 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: August 29, 2013 Bredbandsfylket Troms 6 February 25, 2013 8 LISP EID Block Management Guidelines 9 draft-iannone-lisp-eid-block-mgmnt-01.txt 11 Abstract 13 This document proposes an allocation framework for the management of 14 the LISP EID address prefix (requested in a separate document). Such 15 framework relies on hierarchical distribution of the address space to 16 RIRs (Regional Internet Registries), who will allocate on a temporary 17 basis sub-prefixes to requesting organizations. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on August 29, 2013. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . . 3 55 3. EID Block Allocation Policy . . . . . . . . . . . . . . . . . . 6 56 4. RIRs and Internet Experiments . . . . . . . . . . . . . . . . . 6 57 5. Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 59 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 60 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 62 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 65 1. Introduction 67 The Locator/ID Separation Protocol (LISP - [RFC6830]) and related 68 mechanisms ([RFC6831], [RFC6832], [RFC6833], [RFC6834], [RFC6835], 69 [RFC6836], [RFC6837]) separates the IP addressing space in two 70 logical spaces, the End-point IDentifier (EID) space and the Routing 71 LOCator (RLOC) space. The first is used to identify communication 72 end-points, while the second is used to locate them in the Internet 73 routing infrastructure topology. 75 More particularly, for IPv6, an address block has been requested to 76 IANA to be reserved for exclusive use for EID prefix allocation and 77 assignment [I-D.ietf-lisp-eid-block]. 79 This document proposes an allocation framework for the EID address 80 block based on allocation of sub parts of the block to the different 81 RIR, which in turn will grant temporary allocation to requesting 82 organizations. 84 Rationale, Intent, size, and usage of the EID address block is 85 described in [I-D.ietf-lisp-eid-block]. 87 2. Definition of Terms 89 LISP operates on two name spaces and introduces several new network 90 elements. This section provides high-level definitions of the LISP 91 name spaces and network elements and as such, it must not be 92 considered as an authoritative source. The reference to the 93 authoritative document for each term is included in every term 94 description. 96 Legacy Internet: The portion of the Internet that does not run LISP 97 and does not participate in LISP+ALT or any other mapping system. 99 LISP site: A LISP site is a set of routers in an edge network that 100 are under a single technical administration. LISP routers that 101 reside in the edge network are the demarcation points to separate 102 the edge network from the core network. See [RFC6830] for more 103 details. 105 Endpoint ID (EID): An EID is a 32-bit (for IPv4) or 128-bit (for 106 IPv6) value used in the source and destination address fields of 107 the first (most inner) LISP header of a packet. A packet that is 108 emitted by a system contains EIDs in its headers and LISP headers 109 are prepended only when the packet reaches an Ingress Tunnel 110 Router (ITR) on the data path to the destination EID. The source 111 EID is obtained via existing mechanisms used to set a host's 112 "local" IP address. An EID is allocated to a host from an EID- 113 prefix block associated with the site where the host is located. 114 See [RFC6830] for more details. 116 EID-prefix: A power-of-two block of EIDs that are allocated to a 117 site by an address allocation authority. See [RFC6830] for more 118 details. 120 EID-Prefix Aggregate: A set of EID-prefixes said to be aggregatable 121 in the [RFC4632] sense. That is, an EID-Prefix aggregate is 122 defined to be a single contiguous power-of-two EID-prefix block. 123 A prefix and a length characterize such a block. See [RFC6830] 124 for more details. 126 Routing LOCator (RLOC): A RLOC is an IPv4 or IPv6 address of an 127 egress tunnel router (ETR). A RLOC is the output of an EID-to- 128 RLOC mapping lookup. An EID maps to one or more RLOCs. 129 Typically, RLOCs are numbered from topologically aggregatable 130 blocks that are assigned to a site at each point to which it 131 attaches to the global Internet; where the topology is defined by 132 the connectivity of provider networks, RLOCs can be thought of as 133 Provider Aggregatable (PA) addresses. See [RFC6830] for more 134 details. 136 EID-to-RLOC Mapping: A binding between an EID-Prefix and the RLOC- 137 set that can be used to reach the EID-Prefix. The general term 138 "mapping" always refers to an EID-to-RLOC mapping. See [RFC6830] 139 for more details. 141 Ingress Tunnel Router (ITR): An Ingress Tunnel Router (ITR) is a 142 router that accepts receives IP packets from site end-systems on 143 one side and sends LISP-encapsulated IP packets toward the 144 Internet on the other side. The router treats the "inner" IP 145 destination address as an EID and performs an EID-to-RLOC mapping 146 lookup. The router then prepends an "outer" IP header with one of 147 its globally routable RLOCs in the source address field and the 148 result of the mapping lookup in the destination address field. 149 See [RFC6830] for more details. 151 Egress Tunnel Router (ETR): An Egress Tunnel Router (ETR) receives 152 LISP-encapsulated IP packets from the Internet on one side and 153 sends decapsulated IP packets to site end-systems on the other 154 side. An ETR router accepts an IP packet where the destination 155 address in the "outer" IP header is one of its own RLOCs. The 156 router strips the "outer" header and forwards the packet based on 157 the next IP header found. See [RFC6830] for more details. 159 Proxy ITR (PITR): A Proxy-ITR (PITR) acts like an ITR but does so on 160 behalf of non-LISP sites which send packets to destinations at 161 LISP sites. See [RFC6832] for more details. 163 Proxy ETR (PETR): A Proxy-ETR (PETR) acts like an ETR but does so on 164 behalf of LISP sites which send packets to destinations at non- 165 LISP sites. See [RFC6832] for more details. 167 Map Server (MS): A network infrastructure component that learns EID- 168 to-RLOC mapping entries from an authoritative source (typically an 169 ETR). A Map Server publishes these mappings in the distributed 170 mapping system. See [RFC6833] for more details. 172 Map Resolver (MR): A network infrastructure component that accepts 173 LISP Encapsulated Map-Requests, typically from an ITR, quickly 174 determines whether or not the destination IP address is part of 175 the EID namespace; if it is not, a Negative Map-Reply is 176 immediately returned. Otherwise, the Map Resolver finds the 177 appropriate EID-to-RLOC mapping by consulting the distributed 178 mapping database system. See [RFC6833] for more details. 180 The LISP Alternative Logical Topology (ALT): The virtual overlay 181 network made up of tunnels between LISP+ALT Routers. The Border 182 Gateway Protocol (BGP) runs between ALT Routers and is used to 183 carry reachability information for EID-prefixes. The ALT provides 184 a way to forward Map-Requests toward the ETR that "owns" an EID- 185 prefix. See [RFC6836] for more details. 187 ALT Router: The device on which runs the ALT. The ALT is a static 188 network built using tunnels between ALT Routers. These routers 189 are deployed in a roughly-hierarchical mesh in which routers at 190 each level in the topology are responsible for aggregating EID- 191 Prefixes learned from those logically "below" them and advertising 192 summary prefixes to those logically "above" them. Prefix learning 193 and propagation between ALT Routers is done using BGP. When an 194 ALT Router receives an ALT Datagram, it looks up the destination 195 EID in its forwarding table (composed of EID-Prefix routes it 196 learned from neighboring ALT Routers) and forwards it to the 197 logical next-hop on the overlay network. The primary function of 198 LISP+ALT routers is to provide a lightweight forwarding 199 infrastructure for LISP control-plane messages (Map-Request and 200 Map-Reply), and to transport data packets when the packet has the 201 same destination address in both the inner (encapsulating) 202 destination and outer destination addresses ((i.e., a Data Probe 203 packet). See [RFC6830] for more details. 205 3. EID Block Allocation Policy 207 IANA will allocate EID prefix space to the different RIR according to 208 the allocation forecast provided by the RIR. To bootstrap the 209 process it is suggested to allocate a /24 to every RIR. 211 RIRs make available EID addressing prefixes in the reserved space on 212 a temporary basis and for experimental uses. The requester of the 213 experimental prefix has to provide a short description of the 214 intended use or experiment that will be carried out. If the prefix 215 will be used for activities not documented in the original 216 description, the RIR issuing the allocation reserves the right to 217 revoke the allocation. 219 EID prefixes are allocated on a lease/license basis for a limited 220 period of time (which can be renewed). The details of the allocation 221 request and the allocated prefix will be published by RIRs according 222 to their current existing policy (e.g., public RIR database). 224 The size of the minimum allocated prefix will follow existing RIR 225 minimum allocation policy. 227 When (and if) the LISP technology will change status, not being 228 "experimental" anymore, and following the policies outlined in 229 [RFC5226], the EID block will change status as well and converted in 230 a permanent allocation. RIRs will accept request to convert existing 231 temporary allocations (without renumbering) in permanent allocation. 232 The request will respect with RIRs policy for new IPv6 address 233 allocations. New (not previously existing) allocations in the EID 234 block space will as well follow RIRs policy for normal IPv6 address 235 allocation request. 237 4. RIRs and Internet Experiments 239 The Regional Internet Registries have already policies dealing 240 Internet Experiments: 242 o RIPE NCC [RIPE]: Allocations and assignments of Internet resources 243 for Internet experiments are available. Such allocations or 244 assignments are temporary. They are intended to support 245 experimental Internet activities. 247 o AfriNIC [AfriNIC]: Allocations and assignments of Internet 248 resources for Internet experiments are available. Such 249 allocations or assignments are temporary. They are intended to 250 support experimental Internet activities. Results of experiments 251 should be made freely available to the public. 253 o ARIN [ARIN]: Allocations and assignments of Internet resources for 254 Internet experiments are available. Such allocations or 255 assignments are temporary. They are intended to support 256 experimental Internet activities. Results of experiments should 257 be made freely available to the public. 259 o APNIC [APNIC]: Allocations and assignments of Internet resources 260 for Internet experiments are available. Such allocations or 261 assignments are temporary for a duration of one year, which can be 262 extended according to the proposed experiment. They are intended 263 to support experimental Internet activities. Results of 264 experiments should be made freely available to the public. APNIC 265 reserves the right to publish archives of all experiments that 266 receive an allocation. 268 o LACNIC [LACNIC]: Allocations and assignments of Internet resources 269 for Internet experiments are available. Such allocations or 270 assignments are temporary for a duration of one year, renwable for 271 the same duration. They are intended to support experimental 272 Internet activities. Results of experiments should be made freely 273 available to the public. LACNIC reserves the right ot public 274 archives of all experiments that receive an allocation. 276 The policy proposed in Section 3 is compatible with the existing RIRs 277 policy. 279 5. Next Steps 281 The document aims at starting discussion in order to address the 282 concerns raised during the IETF Review of [I-D.ietf-lisp-eid-block], 283 more specifically the lack of guidelines about the EID Block 284 allocation and management. 286 Discussion will be started with the different RIRs to verify 287 compatibility of the proposed policy and agree on the process for EID 288 prefix allocation and managament. 290 6. Security Considerations 292 This document does not introduce new security threats in the LISP 293 architecture nor in the Legacy Internet architecture. 295 7. IANA Considerations 297 This document provides only management guidelines for the reserved 298 LISP EID prefix and does not make any direct request to IANA. 300 8. References 302 8.1. Normative References 304 [I-D.ietf-lisp-eid-block] 305 Iannone, L., Lewis, D., Meyer, D., and V. Fuller, "LISP 306 EID Block", draft-ietf-lisp-eid-block-03 (work in 307 progress), November 2012. 309 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 310 (CIDR): The Internet Address Assignment and Aggregation 311 Plan", BCP 122, RFC 4632, August 2006. 313 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 314 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 315 May 2008. 317 8.2. Informative References 319 [APNIC] APNIC, "http://www.apnic.net/policy/experimental-alloc". 321 [ARIN] ARIN, 322 "https://www.arin.net/resources/request/ 323 experimental.html". 325 [AfriNIC] AfriNIC, "https://my.afrinic.net/help/policies/ 326 afpol-tmpal200504.htm". 328 [LACNIC] LACNIC, "http://lacnic.net/en/politicas/manual10.html". 330 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 331 Locator/ID Separation Protocol (LISP)", RFC 6830, 332 January 2013. 334 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 335 Locator/ID Separation Protocol (LISP) for Multicast 336 Environments", RFC 6831, January 2013. 338 [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 339 "Interworking between Locator/ID Separation Protocol 340 (LISP) and Non-LISP Sites", RFC 6832, January 2013. 342 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 343 Protocol (LISP) Map-Server Interface", RFC 6833, 344 January 2013. 346 [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID 347 Separation Protocol (LISP) Map-Versioning", RFC 6834, 348 January 2013. 350 [RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation 351 Protocol Internet Groper (LIG)", RFC 6835, January 2013. 353 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, 354 "Locator/ID Separation Protocol Alternative Logical 355 Topology (LISP+ALT)", RFC 6836, January 2013. 357 [RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to 358 Routing Locator (RLOC) Database", RFC 6837, January 2013. 360 [RIPE] RIPE NCC, "http://www.ripe.net/ripe/docs/ripe-526". 362 Authors' Addresses 364 Luigi Iannone 365 Telecom ParisTech 367 Email: luigi.iannone@telecom-paristech.fr 369 Roger Jorgensen 370 Bredbandsfylket Troms 372 Email: rogerj@gmail.com