idnits 2.17.1 draft-lisp-eid-block-00.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 (July 2, 2011) is 4679 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-24) exists of draft-ietf-lisp-14 == Outdated reference: A later version (-10) exists of draft-ietf-lisp-alt-07 == Outdated reference: A later version (-06) exists of draft-ietf-lisp-interworking-02 == Outdated reference: A later version (-16) exists of draft-ietf-lisp-ms-09 ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Iannone 3 Internet-Draft Deutsche Telekom Laboratories 4 Intended status: Informational D. Lewis 5 Expires: January 3, 2012 D. Meyer 6 V. Fuller 7 Cisco Systems, Inc. 8 July 2, 2011 10 LISP EID Block 11 draft-lisp-eid-block-00.txt 13 Abstract 15 This is a direction to IANA to allocate a /16 IPv6 prefix for use 16 with the Locator/ID Separation Protocol (LISP). The prefix will be 17 used by sites deploying LISP as EID (Endpoint IDentifier) addressing 18 space for local intra-domain routing and global endpoint 19 identification. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 3, 2012. 38 Copyright Notice 40 Copyright (c) 2011 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . . 3 56 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Rationale and Intent . . . . . . . . . . . . . . . . . . . . . 5 59 5. Expected use . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 6. Action Plan . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 7. Routing Considerations . . . . . . . . . . . . . . . . . . . . 7 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 63 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 64 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 65 11. Normative References . . . . . . . . . . . . . . . . . . . . . 8 66 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 8 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 69 1. Requirements Notation 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in [RFC2119]. 75 2. Introduction 77 This document directs the IANA to allocate a /16 IPv6 prefix for use 78 with the Locator/ID Separation Protocol (LISP - [I-D.ietf-lisp]), 79 LISP Map Server ([I-D.ietf-lisp-ms]), LISP Alternative Topology 80 (LISP+ALT - [I-D.ietf-lisp-alt]) (or other) mapping system, and LISP 81 Interworking ([I-D.ietf-lisp-interworking]). 83 This block will be used as global Endpoint IDentifier (EID) space 84 (Section 3). 86 3. Definition of Terms 88 LISP operates on two name spaces and introduces several new network 89 elements. This section provides high-level definitions of the LISP 90 name spaces and network elements and as such, it MUST NOT be 91 considered as an authoritative source. The reference to the 92 authoritative document for each term is included in every term 93 description. 95 Legacy Internet: The portion of the Internet which does not run LISP 96 and does not participate in LISP+ALT or any other mapping system. 98 LISP site: A LISP site is a set of routers in an edge network that 99 are under a single technical administration. LISP routers that 100 reside in the edge network are the demarcation points to separate 101 the edge network from the core network. See [I-D.ietf-lisp] for 102 more details. 104 Endpoint ID (EID): An EID is a 32-bit (for IPv4) or 128-bit (for 105 IPv6) value used in the source and destination address fields of 106 the first (most inner) LISP header of a packet. A packet that is 107 emitted by a system contains EIDs in its headers and LISP headers 108 are prepended only when the packet reaches an Ingress Tunnel 109 Router (ITR) on the data path to the destination EID. The source 110 EID is obtained via existing mechanisms used to set a host's 111 "local" IP address. An EID is allocated to a host from an EID- 112 prefix block associated with the site where the host is located. 113 See [I-D.ietf-lisp] for more details. 115 EID-prefix: A power-of-two block of EIDs that are allocated to a 116 site by an address allocation authority. See [I-D.ietf-lisp] for 117 more details. 119 EID-Prefix Aggregate: A set of EID-prefixes said to be aggregatable 120 in the [RFC4632] sense. That is, an EID-Prefix aggregate is 121 defined to be a single contiguous power-of-two EID-prefix block. 122 Such a block is characterized by a prefix and a length. See 123 [I-D.ietf-lisp] for more details. 125 Routing LOCator (RLOC): A RLOC is an IPv4 or IPv6 address of an 126 egress tunnel router (ETR). A RLOC is the output of an EID-to- 127 RLOC mapping lookup. An EID maps to one or more RLOCs. 128 Typically, RLOCs are numbered from topologically aggregatable 129 blocks that are assigned to a site at each point to which it 130 attaches to the global Internet; where the topology is defined by 131 the connectivity of provider networks, RLOCs can be thought of as 132 Provider Aggregatable (PA) addresses. See [I-D.ietf-lisp] for 133 more details. 135 EID-to-RLOC Mapping: A binding between an EID-Prefix and the RLOC- 136 set that can be used to reach the EID-Prefix. The general term 137 "mapping" always refers to an EID-to-RLOC mapping. See 138 [I-D.ietf-lisp] for more details. 140 Ingress Tunnel Router (ITR): An Ingress Tunnel Router (ITR) is a 141 router that accepts receives IP packets from site end-systems on 142 one side and sends LISP-encapsulated IP packets toward the 143 Internet on the other side. The router treats the "inner" IP 144 destination address as an EID and performs an EID-to-RLOC mapping 145 lookup. The router then prepends an "outer" IP header with one of 146 its globally-routable RLOCs in the source address field and the 147 result of the mapping lookup in the destination address field. 148 See [I-D.ietf-lisp] for more details. 150 Egress Tunnel Router (ETR): An Egress Tunnel Router (ETR) receives 151 LISP-encapsulated IP packets from the Internet on one side and 152 sends decapsulated IP packets to site end-systems on the other 153 side. An ETR router accepts an IP packet where the destination 154 address in the "outer" IP header is one of its own RLOCs. The 155 router strips the "outer" header and forwards the packet based on 156 the next IP header found. See [I-D.ietf-lisp] for more details. 158 Proxy ITR (PITR): A Proxy-ITR (PITR) acts like an ITR but does so on 159 behalf of non-LISP sites which send packets to destinations at 160 LISP sites. See [I-D.ietf-lisp-interworking] for more details. 162 Proxy ETR (PETR): A Proxy-ETR (PETR) acts like an ETR but does so on 163 behalf of LISP sites which send packets to destinations at non- 164 LISP sites. See [I-D.ietf-lisp-interworking] for more details. 166 Map Server (MS): A network infrastructure component that learns EID- 167 to-RLOC mapping entries from an authoritative source (typically an 168 ETR). A Map-Server publishes these mappings in the distributed 169 mapping system. See [I-D.ietf-lisp-ms] for more details. 171 Map Resolver (MR): A network infrastructure component that accepts 172 LISP Encapsulated Map-Requests, typically from an ITR, quickly 173 determines whether or not the destination IP address is part of 174 the EID namespace; if it is not, a Negative Map-Reply is 175 immediately returned. Otherwise, the Map-Resolver finds the 176 appropriate EID-to-RLOC mapping by consulting the distributed 177 mapping database system. See [I-D.ietf-lisp-ms] for more details. 179 The LISP Alternative Logical Topology (ALT): The virtual overlay 180 network made up of tunnels between LISP+ALT Routers. The Border 181 Gateway Protocol (BGP) runs between ALT Routers and is used to 182 carry reachability information for EID-prefixes. The ALT provides 183 a way to forward Map-Requests toward the ETR that "owns" an EID- 184 prefix. See [I-D.ietf-lisp-alt] for more details. 186 ALT Router: The device on which runs the ALT. The ALT is a static 187 network built using tunnels between ALT Routers. These routers 188 are deployed in a roughly-hierarchical mesh in which routers at 189 each level in the topology are responsible for aggregating EID- 190 Prefixes learned from those logically "below" them and advertising 191 summary prefixes to those logically "above" them. Prefix learning 192 and propagation between ALT Routers is done using BGP. When an 193 ALT Router receives an ALT Datagram, it looks up the destination 194 EID in its forwarding table (composed of EID-Prefix routes it 195 learned from neighboring ALT Routers) and forwards it to the 196 logical next-hop on the overlay network. The primary function of 197 LISP+ALT routers is to provide a lightweight forwarding 198 infrastructure for LISP control-plane messages (Map-Request and 199 Map-Reply), and to transport data packets when the packet has the 200 same destination address in both the inner (encapsulating) 201 destination and outer destination addresses ((i.e., a Data Probe 202 packet). See [I-D.ietf-lisp-alt] for more details. 204 4. Rationale and Intent 206 With the current specifications, if an ITR is sending to all types of 207 destinations (i.e., non-LISP destinations, LISP destinations not in 208 the IPv6 EID Block, and LISP destinations in the IPv6 EID Block) the 209 only way to understand whether or not to encapsulate the traffic is 210 to perform a cache lookup and, in case of cache-miss, send a Map- 211 Request to the mapping system. In the meanwhile, packets can be 212 dropped. 214 By defining an IPv6 EID Block is possible to configure the router so 215 to natively forward all packets that have not a destination address 216 in the block, without performing any lookup whatsoever. This will 217 give a tighter control over the traffic in the initial experimental 218 phase, while facilitating its large-scale deployment. 220 The EID Block will be used only at configuration level, it is 221 RECOMMENDED not to hard-code in any way the IPv6 EID Block in the 222 router hardware. This allows to avoid locking out sites that may 223 want to switch to LISP while keeping their own IPv6 prefix, which is 224 not in the IPv6 EID Block. 226 5. Expected use 228 Sites planning to deploy LISP may request a prefix in the IPv6 EID 229 Block. Such prefix will be used for routing and endpoint 230 identification inside the site requesting it. Mappings related to 231 such prefix, or part of it, will be made available through the 232 mapping system in use or registered to one or more Map-Server(s). 233 Too guarantee reachability from the Legacy Internet the prefix could 234 be announced in the BGP routing infrastructure by one or more 235 PITR(s), possibly as part of a larger prefix, aggregating several 236 prefixes of several sites. 238 6. Action Plan 240 This document requests IANA to initially allocate a /16 prefix out of 241 the IPv6 addressing space for use as EID in LISP (Locator/ID 242 Separation protocol). It is suggested to IANA to temporarily avoid 243 allocating any other address block the same /12 prefix the EID /16 244 prefix belongs to. This is to accommodate future requests of EID 245 space without fragmenting the EID addressing space. This will also 246 help from an operational point of view, since it will be sufficient 247 to change the subnet mask length in existing deployments. 249 If in the future there will be need for a larger EID Block the 250 address space adjacent the EID Block could be allocate by IANA 251 according to the current policies. 253 7. Routing Considerations 255 In order to provide connectivity between the Legacy Internet and LISP 256 sites, PITRs announcing large aggregates of the IPv6 EID Block could 257 be deployed. By doing so, PITRs will attract traffic destined to 258 LISP sites in order to encapsulate and forward it toward the specific 259 destination LISP site. Routers in the Legacy Internet MUST treat 260 announcements of prefixes from the IPv6 EID Block as normal 261 announcements, applying best current practice for traffic engineering 262 and security. 264 Even in a LISP site, not all routers need to run LISP elements. In 265 particular, routers that are not at the border of the local domain, 266 used only for intra-domain routing, do not need to provide any 267 specific LISP functionality but MUST be able to route traffic using 268 addresses in the IPv6 EID Block. 270 For the above-mentioned reasons, routers that do not run any LISP 271 element, MUST NOT include any special handling code or hardware for 272 addresses in the IPv6 EID Block. In particular, it is RECOMMENDED 273 that the default router configuration does not handle such addresses 274 in any special way. Doing differently could prevent communication 275 between the Legacy Internet and LISP sites or even break local intra- 276 domain connectivity. 278 8. Security Considerations 280 This document does not introduce new security threats in the LISP 281 architecture nor in the Legacy Internet architecture. 283 9. Acknowledgments 285 Marla Azinger, Chris Morrow, Peter Schoenmaker all made insightful 286 comments on early versions of this draft. 288 10. IANA Considerations 290 This document instructs the IANA to assign a /16 IPv6 prefix for use 291 as the global LISP EID space using an hierarchical allocation as 292 outlined in [RFC2434]. During the discussion related to this 293 document, the LISP Working Group agreed in suggesting to IANA to 294 reserve adjacent addressing space for future use as EID space if 295 needs come. Following the policies outlined in [RFC2434], such space 296 will be assigned only upon IETF Consensus. This document does not 297 specify any specific value for the requested address block. 299 11. Normative References 301 [I-D.ietf-lisp] 302 Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 303 "Locator/ID Separation Protocol (LISP)", 304 draft-ietf-lisp-14 (work in progress), June 2011. 306 [I-D.ietf-lisp-alt] 307 Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP 308 Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-07 309 (work in progress), June 2011. 311 [I-D.ietf-lisp-interworking] 312 Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 313 "Interworking LISP with IPv4 and IPv6", 314 draft-ietf-lisp-interworking-02 (work in progress), 315 June 2011. 317 [I-D.ietf-lisp-ms] 318 Fuller, V. and D. Farinacci, "LISP Map Server", 319 draft-ietf-lisp-ms-09 (work in progress), June 2011. 321 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 322 Requirement Levels", BCP 14, RFC 2119, March 1997. 324 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 325 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 326 October 1998. 328 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 329 (CIDR): The Internet Address Assignment and Aggregation 330 Plan", BCP 122, RFC 4632, August 2006. 332 Appendix A. Document Change Log 334 Version 00 Posted July 2011. 336 o Updated section "IANA Considerations" 338 o Added section "Rationale and Intent" explaining why the EID block 339 allocation is useful. 341 o Added section "Expected Use" explaining how sites can request and 342 use a prefix in the IPv6 EID Block. 344 o Added section "Action Plan" suggesting IANA to avoid allocating 345 address space adjacent the allocated EID block in order to 346 accommodate future EID space requests. 348 o Added section "Routing Consideration" describing how routers not 349 running LISP deal with the requested address block. 351 o Added the present section to keep track of changes. 353 o Rename of draft-meyer-lisp-eid-block-02.txt. 355 Authors' Addresses 357 Luigi Iannone 358 Deutsche Telekom Laboratories 360 Email: luigi@net.t-labs.tu-berlin.de 362 Darrel Lewis 363 Cisco Systems, Inc. 365 Email: darlewis@cisco.com 367 David Meyer 368 Cisco Systems, Inc. 370 Email: dmm@cisco.com 372 Vince Fuller 373 Cisco Systems, Inc. 375 Email: vaf@cisco.com