idnits 2.17.1 draft-farinacci-lisp-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1679. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1690. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1697. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1703. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 5 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: UDP Checksum: this field field MUST be transmitted as 0 and ignored on receipt by the ETR. Note, even when the UDP checksum is transmitted as 0 an intervening NAT device can recalculate the checksum and rewrite the UDP checksum field to non-zero. For performance reasons, the ETR MUST ignore the checksum and MUST not do a checksum computation. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 14, 2007) is 6002 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4423 (Obsoleted by RFC 9063) == Outdated reference: A later version (-05) exists of draft-fuller-lisp-alt-01 == Outdated reference: A later version (-01) exists of draft-jen-apt-00 == Outdated reference: A later version (-04) exists of draft-meyer-lisp-cons-03 == Outdated reference: A later version (-09) exists of draft-lear-lisp-nerd-01 == Outdated reference: A later version (-05) exists of draft-narten-radir-problem-statement-00 == Outdated reference: A later version (-10) exists of draft-ietf-mip4-rfc3344bis-05 == Outdated reference: A later version (-08) exists of draft-ietf-pim-rpf-vector-03 -- No information found for draft-handley-p2ppush-unpublished-2007726 - is the name correct? == Outdated reference: A later version (-12) exists of draft-ietf-shim6-proto-06 Summary: 5 errors (**), 0 flaws (~~), 11 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Farinacci 3 Internet-Draft V. Fuller 4 Intended status: Experimental D. Oran 5 Expires: May 17, 2008 D. Meyer 6 cisco Systems 7 November 14, 2007 9 Locator/ID Separation Protocol (LISP) 10 draft-farinacci-lisp-05.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on May 17, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This draft describes a simple, incremental, network-based protocol to 44 implement separation of Internet addresses into Endpoint Identifiers 45 (EIDs) and Routing Locators (RLOCs). This mechanism requires no 46 changes to host stacks and no major changes to existing database 47 infrastructures. The proposed protocol can be implemented in a 48 relatively small number of routers. 50 This proposal was stimulated by the problem statement effort at the 51 Amsterdam IAB Routing and Addressing Workshop (RAWS), which took 52 place in October 2006. 54 Table of Contents 56 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 57 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 8 59 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 11 60 4.1. Packet Flow Sequence . . . . . . . . . . . . . . . . . . . 12 61 5. Tunneling Details . . . . . . . . . . . . . . . . . . . . . . 15 62 5.1. LISP IPv4-in-IPv4 Header Format . . . . . . . . . . . . . 16 63 5.2. LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 17 64 5.3. Tunnel Header Field Descriptions . . . . . . . . . . . . . 18 65 6. EID-to-RLOC Mapping . . . . . . . . . . . . . . . . . . . . . 20 66 6.1. Control-Plane Packet Format . . . . . . . . . . . . . . . 20 67 6.1.1. LISP Packet Type Allocations . . . . . . . . . . . . . 22 68 6.1.2. Map-Request Message Format . . . . . . . . . . . . . . 22 69 6.1.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . 23 70 6.1.4. Map-Reply Message Format . . . . . . . . . . . . . . . 24 71 6.1.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . 26 72 6.2. Routing Locator Selection . . . . . . . . . . . . . . . . 27 73 6.3. Routing Locator Reachability . . . . . . . . . . . . . . . 28 74 7. Router Performance Considerations . . . . . . . . . . . . . . 30 75 8. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 31 76 8.1. First-hop/Last-hop Tunnel Routers . . . . . . . . . . . . 32 77 8.2. Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 32 78 8.3. ISP Provider-Edge (PE) Tunnel Routers . . . . . . . . . . 33 79 9. Mobility Considerations . . . . . . . . . . . . . . . . . . . 34 80 9.1. Site Mobility . . . . . . . . . . . . . . . . . . . . . . 34 81 9.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 34 82 9.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 34 83 9.4. Fast Network Mobility . . . . . . . . . . . . . . . . . . 36 84 10. Multicast Considerations . . . . . . . . . . . . . . . . . . . 37 85 11. Security Considerations . . . . . . . . . . . . . . . . . . . 38 86 12. Prototype Plans and Status . . . . . . . . . . . . . . . . . . 39 87 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 88 13.1. Normative References . . . . . . . . . . . . . . . . . . . 41 89 13.2. Informative References . . . . . . . . . . . . . . . . . . 41 90 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 44 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 92 Intellectual Property and Copyright Statements . . . . . . . . . . 46 94 1. Requirements Notation 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in [RFC2119]. 100 2. Introduction 102 Many years of discussion about the current IP routing and addressing 103 architecture have noted that its use of a single numbering space (the 104 "IP address") for both host transport session identification and 105 network routing creates scaling issues (see [CHIAPPA] and [RFC1498]). 106 A number of scaling benefits would be realized by separating the 107 current IP address into separate spaces for Endpoint Identifiers 108 (EIDs) and Routing Locators (RLOCs); among them are: 110 1. Reduction of routing table size in the "default-free zone" (DFZ). 111 Use of a separate numbering space for RLOCs will allow them to be 112 assigned topologically (in today's Internet, RLOCs would be 113 assigned by providers at client network attachment points), 114 greatly improving aggregation and reducing the number of 115 globally-visible, routable prefixes. 117 2. Easing of renumbering burden when clients change providers. 118 Because host EIDs are numbered from a separate, non-provider- 119 assigned and non-topologically-bound space, they do not need to 120 be renumbered when a client site changes its attachment points to 121 the network. 123 3. Traffic engineering capabilities that can be performed by network 124 elements and do not depend on injecting additional state into the 125 routing system. This will fall out of the mechanism that is used 126 to implement the EID/RLOC split (see Section 4). 128 4. Mobility without address changing. Existing mobility mechanisms 129 will be able to work in a locator/ID separation scenario. It 130 will be possible for a host (or a collection of hosts) to move to 131 a different point in the network topology either retaining its 132 home-based address or acquiring a new address based on the new 133 network location. A new network location could be a physically 134 different point in the network topology or the same physical 135 point of the topology with a different provider. 137 This draft describes protocol mechanisms to achieve the desired 138 functional separation. For flexibility, the document decouples the 139 mechanism used for forwarding packets from that used to determine EID 140 to RLOC mappings. This work is in response to and intended to 141 address the problem statement that came out of the RAWS effort 142 [RFC4984]. 144 The Routing and Addressing problem statement can be found in [RADIR]. 146 This draft focuses on a router-based solution. Building the solution 147 into the network should facilitate incremental deployment of the 148 technology on the Internet. Note that while the detailed protocol 149 specification and examples in this document assume IP version 4 150 (IPv4), there is nothing in the design that precludes use of the same 151 techniques and mechanisms for IPv6. It should be possible for IPv4 152 packets to use IPv6 RLOCs and for IPv6 EIDs to be mapped to IPv4 153 RLOCs. 155 Related work on host-based solutions is described in Shim6 [SHIM6] 156 and HIP [RFC4423]. Related work on other router-based solutons is 157 described in GSE [GSE]. This draft attempts to not compete or 158 overlap with such solutions and the proposed protocol changes are 159 expected to complement a host-based mechanism when Traffic 160 Engineering functionality is desired. 162 Some of the design goals of this proposal include: 164 1. Minimize required changes to Internet infrastructure. 166 2. Require no hardware or software changes to end-systems (hosts). 168 3. Be incrementally deployable. 170 4. Require no router hardware changes. 172 5. Minimize router software changes. 174 6. Avoid or minimize packet loss when EID-to-RLOC mappings need to 175 be performed. 177 There are 4 variants of LISP, which differ along a spectrum of strong 178 to weak dependence on the topological nature and possible need for 179 routability of EIDs. The variants are: 181 LISP 1: where EIDs are routable through the RLOC topology for 182 bootstrapping EID-to-RLOC mappings. [LISP1] 184 LISP 1.5: where EIDs are routable for bootstrapping EID-to-RLOC 185 mappings; such routing is via a separate topology. 187 LISP 2: where EIDS are not routable and EID-to-RLOC mappings are 188 implemented within the DNS. [LISP2] 190 LISP 3: where non-routable EIDs are used as lookup keys for a new 191 EID-to-RLOC mapping database. Use of Distributed Hash Tables 192 [DHTs] to implement such a database would be an area to explore. 193 Other examples of new mapping database services are [CONS], [ALT], 194 [RPMD], [NERD], and [APT]. 196 This document will focus on LISP 1 and LISP 1.5, both of which rely 197 on a router-based distributed cache and database for EID-to-RLOC 198 mappings. The LISP 2 and LISP 3 mechanisms, which require separate 199 EID-to-RLOC infrastructure, will be documented in additional drafts. 201 3. Definition of Terms 203 Provider Independent (PI) Addresses: an address block assigned from 204 a pool that is not associated with any service provider and is 205 therefore not topologically-aggregatable in the routing system. 207 Provider Assigned (PA) Addresses: a block of IP addresses that are 208 assigned to a site by each service provider to which a site 209 connects. Typically, each block is sub-block of a service 210 provider CIDR block and is aggregated into the larger block before 211 being advertised into the global Internet. Traditionally, IP 212 multihoming has been implemented by each multi-homed site 213 acquiring its own, globally-visible prefix. LISP uses only 214 topologically-assigned and aggregatable address blocks for RLOCs, 215 eliminating this demonstrably non-scalable practice. 217 Routing Locator (RLOC): the IPv4 or IPv6 address of an egress 218 tunnel router (ETR). It is the output of a EID-to-RLOC mapping 219 lookup. An EID maps to one or more RLOCs. Typically, RLOCs are 220 numbered from topologically-aggregatable blocks that are assigned 221 to a site at each point to which it attaches to the global 222 Internet; where the topology is defined by the connectivity of 223 provider networks, RLOCs can be thought of as PA addresses. 224 Multiple RLOCs can be assigned to the same ETR device or to 225 multiple ETR devices at a site. 227 Endpoint ID (EID): a 32- or 128-bit value used in the source and 228 destination address fields of the first (most inner) LISP header 229 of a packet. The host obtains a destination EID the same way it 230 obtains an destination address today, for example through a DNS 231 lookup or SIP exchange. The source EID is obtained via existing 232 mechanisms used to set a hosts "local" IP address. An EID is 233 allocated to a host from an EID-prefix block associated with the 234 site the host is attached to. An EID can be used by a host to 235 refer to other hosts. LISP uses PI blocks for EIDs; such EIDs 236 MUST NOT be used as LISP RLOCs. Note that EID blocks may be 237 assigned in a hierarchical manner, independent of the network 238 topology, to facilitate scaling of the mapping database. In 239 addition, an EID block assigned to a site may have site-local 240 structure (subnetting) for routing within the site; this structure 241 is not visible to the global routing system. 243 EID-prefix: A power-of-2 block of EIDs which are allocated to a 244 site by an address allocation authority. EID-prefixes are 245 associated with a set of RLOC addresses which make up a "database 246 mapping". EID-prefix allocations can be broken up into smaller 247 blocks when an RLOC set is to be associated with the smaller EID- 248 prefix. 250 End-system: is an IPv4 or IPv6 device that originates packets with 251 a single IPv4 or IPv6 header. The end-system supplies an EID 252 value for the destination address field of the IP header when 253 communicating globally (i.e. outside of it's routing domain). An 254 end-system can be a host computer, a switch or router device, or 255 any network appliance. An iPhone. 257 Ingress Tunnel Router (ITR): a router which accepts an IP packet 258 with a single IP header (more precisely, an IP packet that does 259 not contain a LISP header). The router treats this "inner" IP 260 destination address as an EID and performs an EID-to-RLOC mapping 261 lookup. The router then prepends an "outer" IP header with one of 262 its globally-routable RLOCs in the source address field and the 263 result of the mapping lookup in the destination address field. 264 Note that this destination RLOC may be an intermediate, proxy 265 device that has better knowledge of the EID-to-RLOC mapping 266 closest to the destination EID. In general, an ITR receives IP 267 packets from site end-systems on one side and sends LISP- 268 encapsulated IP packets toward the Internet on the other side. 270 Specifically, when a service provider prepends a LISP header for 271 Traffic Engineering purposes, the router that does this is also 272 regarded as an ITR. The outer RLOC the ISP ITR uses can be based 273 on the outer destination address (the originating ITR's supplied 274 RLOC) or the inner destination address (the originating hosts 275 supplied EID). 277 TE-ITR: is an ITR that is deployed in a service provider network 278 that prepends an additional LISP header for Traffic Engineering 279 purposes. 281 Egress Tunnel Router (ETR): a router that accepts an IP packet 282 where destination address in the "outer" IP header is one of its 283 own RLOCs. The router strips the "outer" header and forwards the 284 packet based on the next IP header found. In general, an ETR 285 receives LISP-encapsulated IP packets from the Internet on one 286 side and sends decapsulated IP packets to site end-systems on the 287 other side. ETR functionality does not have to be limited to a 288 router device. A server host can be the endpoint of a LISP tunnel 289 as well. 291 TE-ETR: is an ETR that is deployed in a service provider network 292 that strips an outer LISP header for Traffic Engineering purposes. 294 xTR: is a reference to an ITR or ETR when direction of data flow is 295 not part of the context description. xTR refers to the router that 296 is the tunnel endpoint. Used synonymously with the term "Tunnel 297 Router". For example, "An xTR can be located at the Customer Edge 298 (CE) router", meaning both ITR and ETR functionality is at the CE 299 router. 301 EID-to-RLOC Cache: a short-lived, on-demand database in an ITR that 302 stores, tracks, and is responsible for timing-out and otherwise 303 validating EID-to-RLOC mappings. This cache is distinct from the 304 "database", the cache is dynamic, local, and relatively small 305 while and the database is distributed, relatively static, and much 306 global in scope. 308 EID-to-RLOC Database: a globally, distributed database that 309 contains all known EID-prefix to RLOC mappings. Each potential 310 ETR typically contains a small piece of the database: the EID-to- 311 RLOC mappings for the EID prefixes "behind" the router. These map 312 to one of the router's own, globally-visible, IP addresses. 314 Recursive Tunneling: when a packet has more than one LISP IP 315 header. Additional layers of tunneling may be employed to 316 implement traffic engineering or other re-routing as needed. When 317 this is done, an additional "outer" LISP header is added and the 318 original RLOCs are preserved in the "inner" header. 320 Reencapsulating Tunnels: when a packet has no more than one LISP IP 321 header (two IP headers total) and when it needs to be diverted to 322 new RLOC, an ETR can decapsulate the packet (remove the LISP 323 header) and prepend a new tunnel header, with new RLOC, on to the 324 packet. Doing this allows a packet to be re-routed by the re- 325 encapsulating router without adding the overhead of additional 326 tunnel headers. 328 LISP Header: a term used in this document to refer to the outer 329 IPv4 or IPv6 header, a UDP header, and a LISP header, an ITR 330 prepends or an ETR strips. 332 Address Family Indicator (AFI): a term used to describe an address 333 encoding in a packet. An address family currently pertains to an 334 IPv4 or IPv6 address. See [AFI] for details. 336 Negative Mapping Entry: also known as a negative cache entry, is an 337 EID-to-RLOC entry where an EID-prefix is advertised or stored with 338 no RLOCs. That is, the locator-set for the EID-to-RLOC entry is 339 empty or has an encoded locator count of 0. This type of entry 340 could be used to describe a prefix from a non-LISP site, which is 341 explicitly not in the mapping database. 343 4. Basic Overview 345 One key concept of LISP is that end-systems (hosts) operate the same 346 way they do today. The IP addresses that hosts use for tracking 347 sockets, connections, and for sending and receiving packets do not 348 change. In LISP terminology, these IP addresses are called Endpoint 349 Identifiers (EIDs). 351 Routers continue to forward packets based on IP destination 352 addresses. These addresses are referred to as Routing Locators 353 (RLOCs). Most routers along a path between two hosts will not 354 change; they continue to perform routing/forwarding lookups on 355 addresses (RLOCs) in the IP header. 357 This design introduces "Tunnel Routers", which prepend LISP headers 358 on host-originated packets and strip them prior to final delivery to 359 their destination. The IP addresses in this "outer header" are 360 RLOCs. During end-to-end packet exchange between two Internet hosts, 361 an ITR prepends a new LISP header to each packet and an egress tunnel 362 router strips the new header. The ITR performs EID-to-RLOC lookups 363 to determine the routing path to the the ETR, which has the RLOC as 364 one of its IP addresses. 366 Some basic rules governing LISP are: 368 o End-systems (hosts) only know about EIDs. 370 o EIDs are always IP addresses assigned to hosts. 372 o Routers mostly deal with Routing Locator addresses. See details 373 later in Section 4.1 to clarify what is meant by "mostly". 375 o RLOCs are always IP addresses assigned to routers; preferably, 376 topologically-oriented addresses from provider CIDR blocks. 378 o Routers can use their RLOCs as EIDs but can also be assigned EIDs 379 when performing host functions. Those EIDs MUST NOT be used as 380 RLOCs. When EIDs are used the routeability of them is scoped to 381 within the site. A hybrid use of this, for example is when a 382 router runs the BGP protocol where iBGP peerings may use EIDs and 383 eBGP peerings may use RLOCs. 385 o EIDs are not expected to be usable for global end-to-end 386 communication in the absence of an EID-to-RLOC mapping operation. 387 They are expected to be used locally for intra-site communication. 389 o EID prefixes are likely to be hierarchically assigned in a manner 390 which is optimized for administrative convenience and to 391 facilitate scaling of the EID-to-RLOC mapping database. The 392 hierarchy is based on a address alocation hierarchy which is not 393 dependent on the network toplogy. 395 o EIDs may also be structured (subnetted) in a manner suitable for 396 local routing within an autonomous system. 398 An additional LISP header may be pre-pended to packets by a transit 399 router (i.e. TE-ITR) when re-routing of the end-to-end path for a 400 packet is desired. An obvious instance of this would be an ISP 401 router that needs to perform traffic engineering for packets in flow 402 through its network. In such a situation, termed Recursive 403 Tunneling, an ISP transit acts as an additional ingress tunnel router 404 and the RLOC it uses for the new prepended header would be either an 405 TE-ETR within the ISP (along intra-ISP traffic engineered path) or in 406 an TE-ETR within another ISP (an inter-ISP traffic engineered path, 407 where an agreement to build such a path exists). 409 Tunnel Routers can be placed fairly flexibly in a multi-AS topology. 410 For example, the ITR for a particular end-to-end packet exchange 411 might be the first-hop or default router within a site for the source 412 host. Similarly, the egress tunnel router might be the last-hop 413 router directly-connected to the destination host. Another example, 414 perhaps for a VPN service out-sourced to an ISP by a site, the ITR 415 could be the site's border router at the service provider attachment 416 point. Mixing and matching of site-operated, ISP-operated, and other 417 tunnel routers is allowed for maximum flexibility. See Section 8 for 418 more details. 420 4.1. Packet Flow Sequence 422 This section provides an example of the unicast packet flow with the 423 following parameters: 425 o Source host "host1.abc.com" is sending a packet to 426 "host2.xyz.com". 428 o Each site is multi-homed, so each tunnel router has an address 429 (RLOC) assigned from each of the site's attached service provider 430 address blocks. 432 o The ITR and ETR are directly connected to the source and 433 destination, respectively. 435 Client host1.abc.com wants to communicate with server host2.xyz.com: 437 1. host1.abc.com wants to open a TCP connection to host2.xyz.com. 438 It does a DNS lookup on host2.xyz.com. An A/AAAA record is 439 returned. This address is used as the destination EID and the 440 locally-assigned address of host1.abc.com is used as the source 441 EID. An IP/IPv6 packet is built using the EIDs in the IP/IPv6 442 header and sent to the default router. 444 2. The default router is configured as an ITR. It prepends a LISP 445 header to the packet, with one of its RLOCs as the source IP/IPv6 446 address and uses the destination EID from the original packet 447 header as the destination IP/IPv6 address. Subsequent packets 448 continue to behave the same way until a mapping is learned. 450 3. In LISP 1, the packet is routed through the Internet as it is 451 today. In LISP 1.5, the packet is routed on a different topology 452 which may have EID prefixes distributed and advertised in an 453 aggregatable fashion. In either case, the packet arrives at the 454 ETR. The router is configured to "punt" the packet to the 455 router's control-plane processor. See Section 7 for more 456 details. 458 4. The LISP header is stripped so that the packet can be forwarded 459 by the router control-plane. The router looks up the destination 460 EID in the router's EID-to-RLOC database (not the cache, but the 461 configured data structure of RLOCs). An EID-to-RLOC Map-Reply 462 message is originated by the egress router and is addressed to 463 the source RLOC from the LISP header of the original packet (this 464 is the ITR). The source RLOC in the IP header of the UDP message 465 is one of the ETR's RLOCs (one of the RLOCs that is embedded in 466 the UDP payload). 468 5. The ITR receives the UDP message, parses the message (to check 469 for format validity) and stores the EID-to-RLOC information from 470 the packet. This information is put in the ITR's EID-to-RLOC 471 mapping cache (this is the on-demand cache, the cache where 472 entries time out due to inactivity). 474 6. Subsequent packets from host1.abc.com to host2.xyz.com will have 475 a LISP header prepended with the RLOCs learned from the ETR. 477 7. The egress tunnel receives these packets directly (since the 478 destination address is one of its assigned IP addresses), strips 479 the LISP header and delivers the packets to the attached 480 destination host. 482 In order to eliminate the need for a mapping lookup in the reverse 483 direction, the ETR gleans RLOC information from the LISP header. 484 Both ITR and the ETR may also influence the decision the other makes 485 in selecting an RLOC. See Section 6 for more details. 487 5. Tunneling Details 489 This section describes the LISP Data Message which defines the 490 tunneling header used to encapsulate IPv4 and IPv6 packets which 491 contain EID addresses. Even though the following formats illustrate 492 IPv4-in-IPv4 and IPv6-in-IPv6 encapsulations, the other 2 493 combinations are supported as well. 495 Since additional tunnel headers are prepended, the packet becomes 496 larger and in theory can exceed the MTU of any link traversed from 497 the ITR to the ETR. It is recommended, in IPv4 that packets do not 498 get fragmented as they are encapsulated by the ITR. Instead, the 499 packet is dropped and an ICMP Too Big message is returned to the 500 source. 502 In practice, this is not really a problem. Hosts typically do not 503 originate IP packets larger than 1500 bytes. And second, an informal 504 survey of ISPs has been taken where nearly all ISP link MTUs are 505 either 4470 bytes or support Ethernet jumbo frames of 9180 bytes. 506 Therefore, we don't anticipate any problems with prepending 507 additional headers. 509 5.1. LISP IPv4-in-IPv4 Header Format 511 0 1 2 3 512 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 / |Version| IHL |Type of Service| Total Length | 515 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 / | Identification |Flags| Fragment Offset | 517 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 OH | Time to Live | Protocol = 17 | Header Checksum | 519 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 \ | Source Routing Locator | 521 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 \ | Destination Routing Locator | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 / | Source Port = xxxx | Dest Port = 4341 | 525 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 \ | UDP Length | UDP Checksum | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 / | Locator Reach Bits | 529 LISP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 \ | Nonce | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 / |Version| IHL |Type of Service| Total Length | 533 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 / | Identification |Flags| Fragment Offset | 535 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 IH | Time to Live | Protocol | Header Checksum | 537 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 \ | Source EID | 539 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 \ | Destination EID | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 5.2. LISP IPv6-in-IPv6 Header Format 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 / |Version| Traffic Class | Flow Label | 547 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 / | Payload Length | Next Header=17| Hop Limit | 549 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | | 551 O + + 552 u | | 553 t + Source Routing Locator + 554 e | | 555 r + + 556 | | 557 H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 d | | 559 r + + 560 | | 561 \ + Destination Routing Locator + 562 \ | | 563 \ + + 564 \ | | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 / | Source Port = xxxx | Dest Port = 4341 | 567 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 \ | UDP Length | UDP Checksum | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 / | Locator Reach Bits | 571 LISP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 \ | Nonce | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 / |Version| Traffic Class | Flow Label | 575 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 / | Payload Length | Next Header | Hop Limit | 577 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | | 579 I + + 580 n | | 581 n + Source EID + 582 e | | 583 r + + 584 | | 585 H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 d | | 587 r + + 588 | | 590 \ + Destination EID + 591 \ | | 592 \ + + 593 \ | | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 5.3. Tunnel Header Field Descriptions 598 IH Header: is the inner header, preserved from the datagram received 599 from the originating host. The source and destination IP 600 addresses are EIDs. 602 OH Header: is the outer header prepended by an ITR. The address 603 fields contain RLOCs obtained from the ingress router's EID-to- 604 RLOC cache. The IP protocol number is "UDP (17)" from [RFC0768]. 606 UDP Header: contains a random source port allocated by the ITR when 607 encapsulating a packet. The destination port MUST be set to the 608 well-known IANA assigned port value 4341. 610 UDP Checksum: this field field MUST be transmitted as 0 and ignored 611 on receipt by the ETR. Note, even when the UDP checksum is 612 transmitted as 0 an intervening NAT device can recalculate the 613 checksum and rewrite the UDP checksum field to non-zero. For 614 performance reasons, the ETR MUST ignore the checksum and MUST not 615 do a checksum computation. 617 UDP Length: for an IPv4 encapsulated packet, the inner header Total 618 Length plus the UDP and LISP header lengths are used. For an IPv6 619 encapsulated packet, the inner header Payload Length plus the size 620 of the IPv6 header (40 bytes) plus the size of the UDP and LISP 621 headers are used. The UDP header length is 8 bytes. The LISP 622 header length is 8 bytes. 624 LISP Locator Reach Bits: in the LISP header are set by an ITR to 625 indicate to an ETR the reachability of the Locators in the source 626 site. Each RLOC in a Map-Reply is assigned an ordinal value from 627 0 to n-1 (when there are n RLOCs in a mapping entry). The Locator 628 Reach Bits are numbered from 0 to n-1 from the right significant 629 bit of the 32-bit field. When a bit is set to 1, the ITR is 630 indicating to the ETR the RLOC associated with the bit ordinal is 631 reachable. See Section 6.3 for details on how an ITR can 632 determine other ITRs at the site are reachable. When a site has 633 multiple EID-prefixes which result in multiple mappings (where 634 each could have a different locator-set), the Locator Reach Bits 635 setting in an encapsulated packet MUST reflect the mapping for the 636 EID-prefix that the inner-header source EID address matches. 638 LISP Nonce: is a 32-bit value that is randomly generated by an ITR. 639 It is used to test route-returnability when an ETR echos back the 640 nonce in a Map-Reply message. 642 When doing Recursive Tunneling: 644 o The OH header Time to Live field (or Hop Limit field, in case of 645 IPv6) MUST be copied from the IH header Time to Live field. 647 o The OH header Type of Service field (or the Traffic Class field, 648 in the case of IPv6) SHOULD be copied from the IH header Type of 649 Service field. 651 When doing Re-encapsulated Tunneling: 653 o The new OH header Time to Live field SHOULD be copied from the 654 stripped OH header Time to Live field. 656 o The new OH header Type of Service field SHOULD be copied from the 657 stripped OH header Type of Service field. 659 Copying the TTL serves two purposes. First it preserves the distance 660 the host intended the packet to travel. And more importantly, it 661 provides for suppression of looping packets in the event there is a 662 loop of concatenated tunnels due to misconfiguration. 664 6. EID-to-RLOC Mapping 666 6.1. Control-Plane Packet Format 668 When LISP 1 or LISP 1.5 are used, new UDP packet types encode the 669 EID-to-RLOC mappings: 671 0 1 2 3 672 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 |Version| IHL |Type of Service| Total Length | 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 | Identification |Flags| Fragment Offset | 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 | Time to Live | Protocol = 17 | Header Checksum | 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 | Source Routing Locator | 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 | Destination Routing Locator | 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 / | Source Port | Dest Port | 685 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 \ | UDP Length | UDP Checksum | 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 | | 689 | LISP Message | 690 | | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 |Version| Traffic Class | Flow Label | 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | Payload Length | Next Header=17| Hop Limit | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | | 699 + + 700 | | 701 + Source Routing Locator + 702 | | 703 + + 704 | | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 | | 707 + + 708 | | 709 + Destination Routing Locator + 710 | | 711 + + 712 | | 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 / | Source Port | Dest Port | 715 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 \ | UDP Length | UDP Checksum | 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 | | 719 | LISP Message | 720 | | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 The LISP UDP-based messages are the Map-Request and Map-Reply 724 messages. When a UDP Map-Request is sent, the UDP source port is 725 chosen by the sender and the destination UDP port number is set to 726 4342. When a UDP Map-Reply is sent, the source UDP port number is 727 set to 4342 and the destination UDP port number is copied from the 728 source port of either the Map-Request of the invoking data packet. 730 The UDP Length field will reflect the length of the UDP header and 731 the LISP Message payload. 733 The UDP Checksum is computed and set to non-zero for Map-Request and 734 Map-Reply messages. It MUST be checked on receipt and if the 735 checksum fails, the packet MUST be dropped. 737 LISP-CONS [CONS] and LISP-ALT [ALT] use TCP to send LISP control 738 messages. The format of control messages includes the UDP header so 739 the checksum and length fields can be used to protect and delimit 740 message boundaries. 742 This main LISP specification is the authoritative source for message 743 format definitions for the Map-Request and Map-Reply messages. 745 6.1.1. LISP Packet Type Allocations 747 This section will be the authoritative source for allocating LISP 748 Type values. Current alloactions are: 750 Reserved: 0 b'0000' 751 LISP Map-Request: 1 b'0001' 752 LISP Map-Reply: 2 b'0010' 753 LISP-CONS Open Message: 8 b'1000' 754 LISP-CONS Push-Add Message: 9 b'1001' 755 LISP-CONS Push-Delete Message: 10 b'1010' 756 LISP-CONS Uneachable Message: 11 b'1011' 758 6.1.2. Map-Request Message Format 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 | Locator Reach Bits | 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 | Nonce | 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 |Type=1 |Rsvd |A| Record Cnt | ITR-AFI | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 | Originating ITR RLOC Address | 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 Rec -> | EID mask-len | EID-AFI | EID-prefix ... | 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 | Mapping Protocol Data | 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 Packet field descriptions: 776 Locator Reach Bits: Refer to Section 5.3. 778 Nonce: A 4-byte random value created by the sender of the Map- 779 Request. 781 Type: 1 (Map-Request) 783 Rsvd: Set to 0 on transmission and ignored on receipt. 785 A: This is an authoritative bit, which is set to 0 for UDP-based Map- 786 Requests sent by an ITR. See other control-specific documents 787 [CONS] [ALT] for TCP-based Map-Requests. 789 Record Cnt: The number of records in this request message. A record 790 comprises of what is labeled 'Rec" above and occurs the number of 791 times equal to Record count. 793 ITR-AFI: Address family of the "Originating ITR RLOC Address" field. 795 Originating ITR RLOC Address: Set to 0 for UDP-based messages. See 796 [CONS] [ALT] for TCP-based Map-Requests. 798 EID mask-len: Mask length for EID prefix. 800 EID-AFI: Address family of EID-prefix according to [RFC2434] 802 EID-prefix: 4 bytes if an IPv4 address-family, 16 bytes if an IPv6 803 address-family. 805 Mapping Protocol Data: See [CONS] or [ALT] for details. 807 6.1.3. EID-to-RLOC UDP Map-Request Message 809 A Map-Request contains one or more EIDs encoded in prefix format with 810 a Locator count of 0. The EID-prefix MUST NOT be more specific than 811 a cache entry stored from a previously-received Map-Reply. 813 A Map-Request is sent from an ITR when it wants to test an RLOC for 814 reachability. This is performed by using the RLOC as the destination 815 address for Map-Request message with a randomly allocated source UDP 816 port number and the well-known destination port number 4342. A 817 successful Map-Reply updates the cached set of RLOCs associated with 818 the EID prefix range. 820 Map-Requests MUST be rate-limited. It is recommended that a Map- 821 Request for the same EID-prefix be sent no more than once per second. 823 6.1.4. Map-Reply Message Format 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 | Locator Reach Bits | 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 | Nonce | 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 |Type=2 | Reserved | Record Count | 831 +----> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 | | Record TTL | 833 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 | | Locator Count | EID mask-len |A| Reserved | 835 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 R | ITR-AFI | EID-AFI | 837 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 c | Originating ITR RLOC Address | 839 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 r | EID-prefix | 841 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 | /| Priority | Weight | Unused |R| Loc-AFI | 843 | Loc +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 | \| Locator | 845 +---> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | Mapping Protocol Data | 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 Packet field descriptions: 851 Locator Reach Bits: Refer to Section 5.3. When there are multiple 852 records in the Map-Reply message, this field is set to 0 and the 853 R-bit for each Locator record within each mapping record is used 854 to determine the locator reachability. 856 Nonce: A 4-byte value set in a data probe packet or a Map-Request 857 that is echoed here in the Map-Reply. 859 Type: 2 (Map-Reply) 861 Reserved: Set to 0 on transmission and ignored on receipt. 863 Record Count: The number of records in this reply message. A record 864 comprises of what is labeled 'Record' above and occurs the number 865 of times equal to Record count. 867 Record TTL: The time in minutes the recipient of the Map-Reply will 868 store the mapping. If the TTL is 0, the entry should be removed 869 from the cache immediately. If the value is 0xffffffff, the 870 recipient can decide locally how long to store the mapping. 872 Locator Count: The number of Locator entries. A locator entry 873 comprises what is labeled above as 'Loc'. 875 EID mask-len: Mask length for EID prefix. 877 A: The Authoritative bit, when sent by a UDP-based message is always 878 set by the ETR. See [CONS] [ALT] for TCP-based Map-Replies. 880 ITR-AFI: Address family of the "Originating ITR RLOC Address" field. 882 EID-AFI: Address family of EID-prefix according to [RFC2434]. 884 Originating ITR RLOC Address: Set to 0 for UDP-based messages. See 885 [CONS] [ALT] for TCP-based Map-Replies. 887 EID-prefix: 4 bytes if an IPv4 address-family, 16 bytes if an IPv6 888 address-family. 890 Priority: each RLOC is assigned a priority. Lower values are more 891 preferable. When multiple RLOCs have the same priority, they are 892 used in a load-split fashion. A value of 255 means the RLOC MUST 893 NOT be used. 895 Weight: when priorities are the same for multiple RLOCs, the weight 896 indicates how to balance traffic between them. Weight is encoded 897 as a percentage of total packets that match the mapping entry. If 898 a non-zero weight value is used for any RLOC, then all RLOCs must 899 use a non-zero weight value and then the sum of all weight values 900 MUST equal 100. What did the 3rd grader say after Steve Jobs gave 901 an iPhone demo to the class? If a zero value is used for any RLOC 902 weight, then all weights MUST be zero and the receiver of the Map- 903 Reply will decide how to load-split traffic. 905 R: when this bit is set, the locator is known to be reachable from 906 the Map-Reply sender's perspective. When there is a single 907 mapping record in the message, the R-bit for each locator must 908 have a consistent setting with the bitfield setting of the 'Loc 909 Reach Bits' field in the early part of the header. When there are 910 multiple mapping records in the message, the 'Loc Reach Bits' 911 field is set to 0. 913 Locator: an IPv4 or IPv6 address (as encoded by the 'Loc-AFI' field) 914 assigned to an ETR or router acting as a proxy replier for the 915 EID-prefix. Note that the destination RLOC address MAY be an 916 anycast address if the tunnel egress point may be via more than 917 one physical device. A source RLOC can be an anycast address as 918 well. The source or destination RLOC MUST NOT be the broadcast 919 address (255.255.255.255 or any subnet broadcast address known to 920 the router), and MUST NOT be a link-local multicast address. The 921 source RLOC MUST NOT be a multicast address. The destination RLOC 922 SHOULD be a multicast address if it is being mapped from a 923 multicast destination EID. 925 Mapping Protocol Data: See [CONS] or [ALT] for details. 927 6.1.5. EID-to-RLOC UDP Map-Reply Message 929 When a data packet triggers a Map-Reply to be sent, the RLOCs 930 associated with the EID-prefix matched by the EID in the original 931 packet destination IP address field will be returned. The RLOCs in 932 the Map-Reply are the globally-routable IP addresses of the ETR but 933 are not necessarily reachable; separate testing of reachability is 934 required. 936 Note that a Map-Reply may contain different EID-prefix granularity 937 (prefix + length) than the Map-Request which triggers it. This might 938 occur if a Map-Request were for a prefix that had been returned by an 939 earlier Map-Reply. In such a case, the requester updates its cache 940 with the new prefix information and granularity. For example, a 941 requester with two cached EID-prefixes that are covered by a Map- 942 Reply containing one, less-specific prefix, replaces the entry with 943 the less-specific EID-prefix. Note that the reverse, replacement of 944 one less-specific prefix with multiple more-specific prefixes, can 945 also occur but not by removing the less-specific prefix rather by 946 adding the more-specific prefixes which during a lookup will override 947 the less-specific prefix. 949 Replies SHOULD be sent for an EID-prefix no more often than once per 950 second to the same requesting router. For scalability, it is 951 expected that aggregation of EID addresses into EID-prefixes will 952 allow one Map-Reply to satisfy a mapping for the EID addresses in the 953 prefix range thereby reducing the number of Map-Request messages. 955 The addresses for a Data message or Map-Request message are swapped 956 and used for sending the Map-Reply. The UDP source and destination 957 ports are swapped as well. That is, the source port in the UDP 958 header for the Map-Reply is set to the well-known UDP port number 959 4342. 961 6.2. Routing Locator Selection 963 Both client-side and server-side may need control over the selection 964 of RLOCs for conversations between them. This control is achieved by 965 manipulating the Priority and Weight fields in EID-to-RLOC Map-Reply 966 messages. Alternatively, RLOC information may be gleaned from 967 received tunneled packets or EID-to-RLOC Map-Request messages. 969 The following enumerates different scenarios for choosing RLOCs and 970 the controls that are available: 972 o Server-side returns one RLOC. Client-side can only use one RLOC. 973 Server-side has complete control of the selection. 975 o Server-side returns a list of RLOC where a subset of the list has 976 the same best priority. Client can only use the subset list 977 according to the weighting assigned by the server-side. In this 978 case, the server-side controls both the subset list and load- 979 splitting across its members. The client-side can use RLOCs 980 outside of the subset list if it determines that the subset list 981 is unreachable (unless RLOCs are set to a Priority of 255). Some 982 sharing of control exists: the server-side determines the 983 destination RLOC list and load distribution while the client-side 984 has the option of using alternatives to this list if RLOCs in the 985 list are unreachable. 987 o Server-side sets weight of 0 for the RLOC subset list. In this 988 case, the client-side can choose how the traffic load is spread 989 across the subset list. Control is shared by the server-side 990 determining the list and the client determining load distribution. 991 Again, the client can use alternative RLOCs if the server-provided 992 list of RLOCs are unreachable. 994 o Either side (more likely on the server-side ETR) decides not to 995 send an Map-Request. For example, if the server-side ETR does not 996 send Map-Requests, it gleans RLOCs from the client-side ITR, 997 giving the client-side ITR responsibility for bidirectional RLOC 998 reachability and preferability. Server-side ETR gleaning of the 999 client-side ITR RLOC is done by caching the inner header source 1000 EID and the outer header source RLOC of received packets. The 1001 client-side ITR controls how traffic is returned and can alternate 1002 using an outer header source RLOC, which then can be added to the 1003 list the server-side ETR uses to return traffic. Since no 1004 Priority or Weights are provided using this method, the server- 1005 side ETR must assume each client-side ITR RLOC uses the same best 1006 Priority with a Weight of zero. In addition, since EID-prefix 1007 encoding cannot be conveyed in data packets, the EID-to-RLOC cache 1008 on tunnel routers can grow to be very large. 1010 RLOCs that appear in EID-to-RLOC Map-Reply messages are considered 1011 reachable. The Map-Reply and the database mapping service does not 1012 provide any reachability status for Locators. This is done outside 1013 of the mapping service. See next section for details. 1015 6.3. Routing Locator Reachability 1017 There are 4 methods for determining when a Locator is either 1018 reachable or has become unreachable: 1020 1. Locator reachability is determined by an ETR by examining the 1021 Loc-Reach-Bits from a LISP header of a Data Message which is 1022 provided by an ITR when an ITR encapsulates data. 1024 2. Locator unreachability is determined by an ITR by receiving ICMP 1025 Network or Host Unreachable messages. 1027 3. ETR unreachability is determined when a host sends an ICMP Port 1028 Unreachable message. 1030 4. Locator reachability is determined by receiving a Map-Reply 1031 message from a ETR's Locator address in response to a previously 1032 sent Map-Request. 1034 When determining Locator reachability by examining the Loc-Reach-Bits 1035 from the LISP Data Message, an ETR will receive up to date status 1036 from the ITR closest to the Locators at the source site. The ITRs at 1037 the source site can determine reachability when running their IGP at 1038 the site. When the ITRs are deployed on CE routers, typically a 1039 default route is injected into the site's IGP from each of the ITRs. 1040 If an ITR goes down, the CE-PE link goes down, or the PE router goes 1041 down, the CE router withdraws the default route. This allows the 1042 other ITRs at the site to determine one of the Locators has gone 1043 unreachable. 1045 The Locators listed in a Map-Reply are numbered with ordinals 0 to 1046 n-1. The Loc-Reach-Bits in a LISP Data Message are numbered from 0 1047 to n-1 starting with the least signfiicant bit numbered as 0. So, 1048 for example, if the ITR with locator listed as the 3rd Locator 1049 position in the Map-Reply goes down, all other ITRs at the site will 1050 have the 3rd bit from the right cleared (the bit that corresponds to 1051 ordinal 2). 1053 When an ETR decapsulates a packet, it will look for a change in the 1054 Loc-Reach-Bits value. When a bit goes from 1 to 0, the ETR will 1055 refrain from encapsulating packets to the Locator that has just gone 1056 unreachable. It can start using the Locator again when the bit that 1057 corresponds to the Locator goes from 0 to 1. 1059 When ITRs at the site are not deployed in CE routers, the IGP can 1060 still be used to determine the reachability of Locators provided they 1061 are injected a stub links into the IGP. This is typically done when 1062 a /32 address is configured on a loopback interface. 1064 When ITRs receive ICMP Network or Host Unreachable messages as a 1065 method to determine unreachability, they will refrain from using 1066 Locators which are described in Locator lists of Map-Replies. 1067 However, using this approach is unreliable because many network 1068 operators turn off generation of ICMP Unreachable messages. 1070 Optionally, an ITR can send a Map-Request to a Locator and if a Map- 1071 Reply is returned, reachability of the Locator has been achieved. 1072 Obviously, sending such probes increases the number of control 1073 messages originated by tunnel routers for active flows, so Locators 1074 are assumed to be reachable when they are advertised. 1076 This assumption does create a dependency: Locator unreachability is 1077 detected by the receipt of ICMP Host Unreachable messages. When an 1078 Locator has been determined unreachable, it is not used for active 1079 traffic; this is the same as if it were listed in a Map-Reply with 1080 priority 255. 1082 The ITR can later test the reachability of the unreachable Locator by 1083 sending periodic Requests. Both Requests and Replies MUST be rate- 1084 limited. Locator reachability testing is never done with data 1085 packets since that increases the risk of packet loss for end-to-end 1086 sessions. 1088 7. Router Performance Considerations 1090 LISP is designed to be very hardware-based forwarding friendly. By 1091 doing tunnel header prepending [RFC1955] and stripping instead of re- 1092 writing addresses, existing hardware could support the forwarding 1093 model with little or no modification. Where modifications are 1094 required, they should be limited to re-programming existing hardware 1095 rather than requiring expensive design changes to hard-coded 1096 algorithms in silicon. 1098 A few implementation techniques can be used to incrementally 1099 implement LISP: 1101 o When a tunnel encapsulated packet is received by an ETR, the outer 1102 destination address may not be the address of the router. This 1103 makes it challenging for the control-plane to get packets from the 1104 hardware. This may be mitigated by creating special FIB entries 1105 for the EID-prefixes of EIDs served by the ETR (those for which 1106 the router provides an RLOC translation). These FIB entries are 1107 marked with a flag indicating that control-plane processing should 1108 be performed. The forwarding logic of testing for particular IP 1109 protocol number value is not necessary. No changes to existing, 1110 deployed hardware should be needed to support this. 1112 o On an ITR, prepending a new IP header is as simple as adding more 1113 bytes to a MAC rewrite string and prepending the string as part of 1114 the outgoing encapsulation procedure. Many routers that support 1115 GRE tunneling [RFC2784] or 6to4 tunneling [RFC3056] can already 1116 support this action. 1118 o When a received packet's outer destination address contains an EID 1119 which is not intended to be forwarded on the routable topology 1120 (i.e. LISP 1.5), the source address of a data packet or the 1121 router interface with which the source is associated (the 1122 interface from which it was received) can be associated with a VRF 1123 (Virtual Routing/Forwarding), in which a different (i.e. non- 1124 congruent) topology can be used to find EID-to-RLOC mappings. 1126 8. Deployment Scenarios 1128 This section will explore how and where ITRs and ETRs can be deployed 1129 and will discuss the pros and cons of each deployment scenario. 1130 There are two basic deployment tradeoffs to consider: centralized 1131 versus distributed caches and flat, recursive, or re-encapsulating 1132 tunneling. 1134 When deciding on centralized versus distributed caching, the 1135 following issues should be considered: 1137 o Are the tunnel routers spread out so that the caches are spread 1138 across all the memories of each router? 1140 o Should management "touch points" be minimized by choosing few 1141 tunnel routers, just enough for redundancy? 1143 o In general, using more ITRs doesn't increase management load, 1144 since caches are built and stored dynamically. On the other hand, 1145 more ETRs does require more management since EID-prefix-to-RLOC 1146 mappings need to be explicitly configured. 1148 When deciding on flat, recursive, or re-encapsulation tunneling, the 1149 following issues should be considered: 1151 o Flat tunneling implements a single tunnel between source site and 1152 destination site. This generally offers better paths between 1153 sources and destinations with a single tunnel path. 1155 o Recursive tunneling is when tunneled traffic is again further 1156 encapsulated in another tunnel, either to implement VPNs or to 1157 perform Traffic Engineering. When doing VPN-based tunneling, the 1158 site has some control since the site is prepending a new tunnel 1159 header. In the case of TE-based tunneling, the site may have 1160 control if it is prepending a new tunnel header, but if the site's 1161 ISP is doing the TE, then the site has no control. Recursive 1162 tunneling generally will result in suboptimal paths but at the 1163 benefit of steering traffic to resource available parts of the 1164 network. 1166 o The technique of re-encapsulation ensures that packets only 1167 require one tunnel header. So if a packet needs to be rerouted, 1168 it is first decapsulated by the ETR and then re-encapsulated with 1169 a new tunnel header using a new RLOC. 1171 The next sub-sections will describe where tunnel routers can reside 1172 in the network. 1174 8.1. First-hop/Last-hop Tunnel Routers 1176 By locating tunnel routers close to hosts, the EID-prefix set is at 1177 the granularity of an IP subnet. So at the expense of more EID- 1178 prefix-to-RLOC sets for the site, the caches in each tunnel router 1179 can remain relatively small. But caches always depend on the number 1180 of non-aggregated EID destination flows active through these tunnel 1181 routers. 1183 With more tunnel routers doing encapsulation, the increase in control 1184 traffic grows as well: since the EID-granularity is greater, more 1185 Map-Requests and replies are traveling between more routers. 1187 The advantage of placing the caches and databases at these stub 1188 routers is that the products deployed in this part of the network 1189 have better price-memory ratios then their core router counterparts. 1190 Memory is typically less expensive in these devices and fewer routes 1191 are stored (only IGP routes). These devices tend to have excess 1192 capacity, both for forwarding and routing state. 1194 LISP functionality can also be deployed in edge switches. These 1195 devices generally have layer-2 ports facing hosts and layer-3 ports 1196 facing the Internet. Spare capacity is also often available in these 1197 devices as well. 1199 8.2. Border/Edge Tunnel Routers 1201 Using customer-edge (CE) routers for tunnel endpoints allows the EID 1202 space associated with a site to be reachable via a small set of RLOCs 1203 assigned to the CE routers for that site. 1205 This offers the opposite benefit of the first-hop/last-hop tunnel 1206 router scenario: the number of mapping entries and network management 1207 touch points are reduced, allowing better scaling. 1209 One disadvantage is that less of the network's resources are used to 1210 reach host endpoints thereby centralizing the point-of-failure domain 1211 and creating network choke points at the CE router. 1213 Note that more than one CE router at a site can be configured with 1214 the same IP address. In this case an RLOC is an anycast address. 1215 This allows resilency between the CE routers. That is, if a CE 1216 router fails, traffic is automatically routed to the other routers 1217 using the same anycast address. However, this comes with the 1218 disadvantage where the site cannot control the entrance point when 1219 the anycast route is advertised out from all border routers. 1221 8.3. ISP Provider-Edge (PE) Tunnel Routers 1223 Use of ISP PE routers as tunnel endpoint routers gives an ISP control 1224 over the location of the egress tunnel endpoints. That is, the ISP 1225 can decide if the tunnel endpoints are in the destination site (in 1226 either CE routers or last-hop routers within a site) or at other PE 1227 edges. The advantage of this case is that two or more tunnel headers 1228 can be avoided. By having the PE be the first router on the path to 1229 encapsulate, it can choose a TE path first, and the ETR can 1230 decapsulate and re-encapsulate for a tunnel to the destination end 1231 site. 1233 An obvious disadvantage is that the end site has no control over 1234 where its packets flow or the RLOCs used. 1236 As mentioned in earlier sections a combination of these scenarios is 1237 possible at the expense of extra packet header overhead, if both site 1238 and provider want control, then recursive or re-encapsulating tunnels 1239 are used. 1241 9. Mobility Considerations 1243 There are several kinds of mobility of which only some might be of 1244 concern to LISP. Essentially they are as follows. 1246 9.1. Site Mobility 1248 A site wishes to change its attachment points to the Internet, and 1249 its LISP Tunnel Routers will have new RLOCs when it changes upstream 1250 providers. Changes in EID-RLOC mappings for sites are expected to be 1251 handled by configuration, outside of the LISP protocol. 1253 9.2. Slow Endpoint Mobility 1255 An individual endpoint wishes to move, but is not concerned about 1256 maintaining session continuity. Renumbering is involved. LISP can 1257 help with the issues surrounding renumbering [RFC4192] [LISA96] by 1258 decoupling the address space used by a site from the address spaces 1259 used by its ISPs. [RFC4984] 1261 9.3. Fast Endpoint Mobility 1263 Fast endpoint mobility occurs when an endpoint moves relatively 1264 rapidly, changing its IP layer network attachment point. Maintenance 1265 of session continuity is a goal. This is where the Mobile IPv4 1266 [RFC3344bis] and Mobile IPv6 [RFC3775] [RFC4866] mechanisms are used, 1267 and primarily where interactions with LISP need to be explored. 1269 The problem is that as an endpoint moves, it may require changes to 1270 the mapping between its EID and a set of RLOCs for its new network 1271 location. When this is added to the overhead of mobile IP binding 1272 updates, some packets might be delayed or dropped. 1274 In IPv4 mobility, when an endpoint is away from home, packets to it 1275 are encapsulated and forwarded via a home agent which resides in the 1276 home area the endpoint's address belongs to. The home agent will 1277 encapsulate and forward packets either directly to the endpoint or to 1278 a foreign agent which resides where the endpoint has moved to. 1279 Packets from the endpoint may be sent directly to the correspondent 1280 node, may be sent via the foreign agent, or may be reverse-tunneled 1281 back to the home agent for delivery to the mobile node. As the 1282 mobile node's EID or available RLOC changes, LISP EID-to-RLOC 1283 mappings are required for communication between the mobile node and 1284 the home agent, whether via foreign agent or not. As a mobile 1285 endpoint changes networks, up to three LISP mapping changes may be 1286 required: 1288 o The mobile node moves from an old location to a new visited 1289 network location and notifies its home agent that it has done so. 1290 The Mobile IPv4 control packets the mobile node sends pass through 1291 one of the new visited network's ITRs, which needs a EID-RLOC 1292 mapping for the home agent. 1294 o The home agent might not have the EID-RLOC mappings for the mobile 1295 node's "care-of" address or its foreign agent in the new visited 1296 network, in which case it will need to acquire them. 1298 o When packets are sent directly to the correspondent node, it may 1299 be that no traffic has been sent from the new visited network to 1300 the correspondent node's network, and the new visited network's 1301 ITR will need to obtain an EID-RLOC mapping for the correspondent 1302 node's site. 1304 In addition, if the IPv4 endpoint is sending packets from the new 1305 visited network using its original EID, then LISP will need to 1306 perform a route-returnability check on the new EID-RLOC mapping for 1307 that EID. 1309 In IPv6 mobility, packets can flow directly between the mobile node 1310 and the correspondent node in either direction. The mobile node uses 1311 its "care-of" address (EID). In this case, the route-returnability 1312 check would not be needed but one more LISP mapping lookup may be 1313 required instead: 1315 o As above, three mapping changes may be needed for the mobile node 1316 to communicate with its home agent and to send packets to the 1317 correspondent node. 1319 o In addition, another mapping will be needed in the correspondent 1320 node's ITR, in order for the correspondent node to send packets to 1321 the mobile node's "care-of" address (EID) at the new network 1322 location. 1324 When both endpoints are mobile the number of potential mapping 1325 lookups increase accordingly. 1327 As a mobile node moves we not only have mobility state changes in the 1328 mobile node, correspondent node, and home agent, we also have state 1329 changes in the ITRs and ETRs for at least some EID-prefixes. 1331 The goal is to support rapid adapation, with little delay or packet 1332 loss for the entire system. We can add heuristics to LISP to reduce 1333 the number of mapping changes required and to reduce the delay per 1334 mapping change. We can also modify IP mobility to require fewer 1335 mapping changes. In order to increase overall system performance, we 1336 may need to reduce the optimization of one area in order to place 1337 fewer demands on another. 1339 In LISP, one possibility is to "glean" information. When a packet 1340 arrives, the ETR could examine the EID-RLOC mapping and use that 1341 mapping for all outgoing traffic to that EID. It can do this after 1342 performing a route-returnability check, to ensure that the new 1343 network location does have a internal route to that endpoint. 1344 However, this does not cover the case where an ITR (the node assigned 1345 the RLOC) at the mobile-node location has been compromised. 1347 Mobile IP packet exchange is designed for an environment in which all 1348 routing information is disseminated before packets can be forwarded. 1349 In order to allow the Internet to grow to support expected future 1350 use, we are moving to an environment where some information may have 1351 to be obtained after packets are in flight. Modifications to IP 1352 mobility should be considered in order to optimize the behavior of 1353 the overall system. Anything which decreases the number of new EID- 1354 RLOC mappings needed when a node moves, or maintains the validity of 1355 an EID-RLOC mapping for a longer time, is useful. 1357 9.4. Fast Network Mobility 1359 In addition to endpoints, a network can be mobile, possibly changing 1360 xTRs. A "network" can be as small as a single router and as large as 1361 a whole site. This is different from site mobility in that it is 1362 fast and possibly short-lived, but different from endpoint mobility 1363 in that a whole prefix is changing RLOCs. However, the mechanisms 1364 are the same and there is no new overhead in LISP. A map request for 1365 any endpoint will return a binding for the entire mobile prefix. 1367 If mobile networks become a more common occurrence, it may be useful 1368 to revisit the design of the mapping service and allow for dynamic 1369 updates of the database. 1371 The issue of interactions between mobility and LISP needs to be 1372 explored further. Specific improvements to the entire system will 1373 depend on the details of mapping mechanisms. Mapping mechanisms 1374 should be evaluated on how well they support session continuity for 1375 mobile nodes. 1377 10. Multicast Considerations 1379 A multicast group address, as defined in the original Internet 1380 architecture is an identifier of a grouping of topologically 1381 independent receiver host locations. The address encoding itself 1382 does not determine the location of the receiver(s). The multicast 1383 routing protocol, and the network-based state the protocol creates, 1384 determines where the receivers are located. 1386 In the context of LISP, a multicast group address is both an EID and 1387 a Routing Locator. Therefore, no specific semantic or action needs 1388 to be taken for a destination address, as it would appear in an IP 1389 header. Therefore, a group address that appears in an inner IP 1390 header built by a source host will be used as the destination EID. 1391 And the outer IP header (the destination Routing Locator address), 1392 prepended by a LISP router, will use the same group address as the 1393 destination Routing Locator. 1395 Having said that, only the source EID and source Routing Locator 1396 needs to be dealt with. Therefore, an ITR merely needs to put its 1397 own IP address in the source Routing Locator field when prepending 1398 the outer IP header. This source Routing Locator address, like any 1399 other Routing Locator address MUST be globally routable. 1401 Therefore, an EID-to-RLOC mapping does not need to be performed by an 1402 ITR when a received data packet is a multicast data packet or when 1403 processing a source-specific Join (either by IGMPv3 or PIM). But the 1404 source Routing Locator is decided by the multicast routing protocol 1405 in a receiver site. That is, an EID to Routing Locator translation 1406 is done at control-time. 1408 Another approach is to have the ITR not encapsulate a multicast 1409 packet and allow the the host built packet to flow into the core even 1410 if the source address is allocated out of the EID namespace. If the 1411 RPF-Vector TLV [RPFV] is used by PIM in the core, then core routers 1412 can RPF to the ITR (the Locator address which is injected into core 1413 routing) rather than the host source address (the EID address which 1414 is not injected into core routing). 1416 11. Security Considerations 1418 We believe that most of the security mechanisms will be part of the 1419 mapping database service when using control-plane procedures for 1420 obtaining EID-to-RLOC mappings. For data-plane triggered mappings, 1421 as described in this specification, protection is provided against 1422 ETR spoofing by using Return- Routeability mechanisms evidenced by 1423 the use of a 6-byte Nonce field in the LISP encapsulation header. 1424 The nonce, coupled with the ITR accepting only solicited Map-Replies 1425 goes a long way towards providing decent authentication. 1427 LISP does not rely on a PKI infrastructure or a more heavy weight 1428 authentication system. These systems challenge the scalability of 1429 LISP which was a primary design goal. 1431 DoS attack prevention will depend on implementations rate-limiting of 1432 Map-Requests and Map-Replies to the control-plane as well as rate- 1433 limiting the number of data triggered Map-Replies. 1435 12. Prototype Plans and Status 1437 The operator community has requested that the IETF take a practical 1438 approach to solving the scaling problems associated with global 1439 routing state growth. This document offers a simple solution which 1440 is intended for use in a pilot program to gain experience in working 1441 on this problem. 1443 The authors hope that publishing this specification will allow the 1444 rapid implementation of multiple vendor prototypes and deployment on 1445 a small scale. Doing this will help the community: 1447 o Decide whether a new EID-to-RLOC mapping database infrastructure 1448 is needed or if a simple, UDP-based, data-triggered approach is 1449 flexible and robust enough. 1451 o Experiment with provider-independent assignment of EIDs while at 1452 the same time decreasing the size of DFZ routing tables through 1453 the use of topologically-aligned, provider-based RLOCs. 1455 o Determine whether multiple levels of tunneling can be used by ISPs 1456 to achieve their Traffic Engineering goals while simultaneously 1457 removing the more specific routes currently injected into the 1458 global routing system for this purpose. 1460 o Experiment with mobility to determine if both acceptable 1461 convergence and session survivability properties can be scalably 1462 implemented to support both individual device roaming and site 1463 service provider changes. 1465 Here are a rough set of milestones: 1467 1. Stabilize packet formats and this draft by Fall 2007 IETF. 1469 2. Complete implementation of this specification and at least one 1470 mapping database protocol to be reported on at Fall 2007 IETF. 1472 3. Start pilot deployment after fall IETF. Report on pilot 1473 deployment at Spring 2008 IETF. 1475 4. Achieve multi-vendor/platform interoperability by Spring 2008 1476 IETF. 1478 5. Continue prototyping other database lookup schemes, be it DNS, 1479 DHTs, CONS, ALT, NERD, or other mechanisms by Fall 2007 IETF. 1481 As of this writing the following accomplishments have been achieved: 1483 1. A unit tested software switching implementation has been 1484 completed for both IPv4 and IPv6 encapsulations for LISP 1 and 1485 LISP 1.5 [ALT] functionality. The implementation supports 1486 locator reachability and mobility features. 1488 2. Dave Meyer, Vince Fuller, Darrel Lewis, and Greg Shepherd 1489 continue to test the implementation. 1491 3. A server implementation of NERD has been completed by Eliot Lear. 1493 4. An implementation of LISP-CONS is under way. 1495 Please contact authors if interested in doing an implementation and 1496 want to interoperability test with our implementation. 1498 13. References 1500 13.1. Normative References 1502 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1503 August 1980. 1505 [RFC1498] Saltzer, J., "On the Naming and Binding of Network 1506 Destinations", RFC 1498, August 1993. 1508 [RFC1955] Hinden, R., "New Scheme for Internet Routing and 1509 Addressing (ENCAPS) for IPNG", RFC 1955, June 1996. 1511 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1512 Requirement Levels", BCP 14, RFC 2119, March 1997. 1514 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1515 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1516 October 1998. 1518 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 1519 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 1520 March 2000. 1522 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1523 via IPv4 Clouds", RFC 3056, February 2001. 1525 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1526 in IPv6", RFC 3775, June 2004. 1528 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 1529 (HIP) Architecture", RFC 4423, May 2006. 1531 [RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route 1532 Optimization for Mobile IPv6", RFC 4866, May 2007. 1534 [RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB 1535 Workshop on Routing and Addressing", RFC 4984, 1536 September 2007. 1538 13.2. Informative References 1540 [AFI] IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY 1541 NUMBERS http://www.iana.org/numbers.html, February 2007. 1543 [ALT] Farinacci, D., Fuller, V., and D. Meyer, "LISP Alternative 1544 Topology (LISP-ALT)", draft-fuller-lisp-alt-01.txt (work 1545 in progress), November 2007. 1547 [APT] Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and 1548 L. Zhang, "APT: A Practical Transit Mapping Service", 1549 draft-jen-apt-00.txt (work in progress), July 2007. 1551 [CHIAPPA] Chiappa, J., "Endpoints and Endpoint names: A Proposed 1552 Enhancement to the Internet Architecture", Internet- 1553 Draft http://www.chiappa.net/~jnc/tech/endpoints.txt, 1554 1999. 1556 [CONS] Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A 1557 Content distribution Overlay Network Service for LISP", 1558 draft-meyer-lisp-cons-03.txt (work in progress), 1559 November 2007. 1561 [DHTs] Ratnasamy, S., Shenker, S., and I. Stoica, "Routing 1562 Algorithms for DHTs: Some Open Questions", PDF 1563 file http://www.cs.rice.edu/Conferences/IPTPS02/174.pdf. 1565 [GSE] "GSE - An Alternate Addressing Architecture for IPv6", 1566 draft-ietf-ipngwg-gseaddr-00.txt (work in progress), 1997. 1568 [LISA96] Lear, E., Katinsky, J., Coffin, J., and D. Tharp, 1569 "Renumbering: Threat or Menace?", Usenix , September 1996. 1571 [LISP1] Farinacci, D., Oran, D., Fuller, V., and J. Schiller, 1572 "Locator/ID Separation Protocol (LISP1) [Routable ID 1573 Version]", 1574 Slide-set http://www.dinof.net/~dino/ietf/lisp1.ppt, 1575 October 2006. 1577 [LISP2] Farinacci, D., Oran, D., Fuller, V., and J. Schiller, 1578 "Locator/ID Separation Protocol (LISP2) [DNS-based 1579 Version]", 1580 Slide-set http://www.dinof.net/~dino/ietf/lisp2.ppt, 1581 November 2006. 1583 [NERD] Lear, E., "NERD: A Not-so-novel EID to RLOC Database", 1584 draft-lear-lisp-nerd-01.txt (work in progress), June 2007. 1586 [RADIR] Narten, T., "Routing and Addresssing Problem Statement", 1587 draft-narten-radir-problem-statement-00.txt (work in 1588 progress), July 2007. 1590 [RFC3344bis] 1591 Perkins, C., "IP Mobility Support for IPv4, revised", 1592 draft-ietf-mip4-rfc3344bis-05 (work in progress), 1593 July 2007. 1595 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 1596 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 1597 September 2005. 1599 [RPFV] Wijnands, IJ., Boers, A., and E. Rosen, "The RPF Vector 1600 TLV", draft-ietf-pim-rpf-vector-03.txt (work in progress), 1601 October 2006. 1603 [RPMD] Handley, M., Huici, F., and A. Greenhalgh, "RPMD: Protocol 1604 for Routing Protocol Meta-data Dissemination", 1605 draft-handley-p2ppush-unpublished-2007726.txt (work in 1606 progress), July 2007. 1608 [SHIM6] Nordmark, E. and M. Bagnulo, "Level 3 multihoming shim 1609 protocol", draft-ietf-shim6-proto-06.txt (work in 1610 progress), October 2006. 1612 Appendix A. Acknowledgments 1614 The authors would like to gratefully acknowledge many people who have 1615 contributed discussion and ideas to the making of this proposal. 1616 They include Jason Schiller, Lixia Zhang, Dorian Kim, Peter 1617 Schoenmaker, Darrel Lewis, Vijay Gill, Geoff Huston, David Conrad, 1618 Mark Handley, Ron Bonica, Ted Seely, Mark Townsley, Chris Morrow, 1619 Brian Weis, Dave McGrew, Peter Lothberg, Dave Thaler, Eliot Lear, 1620 Shane Amante, Ved Kafle, Olivier Bonaventure, Luigi Iannone, Robin 1621 Whittle, Brian Carpenter, Joel Halpern, Roger Jorgensen, John 1622 Zwiebel, Ran Atkinson, and Stig Venaas. 1624 In particular, we would like to thank Dave Meyer for his clever 1625 suggestion for the name "LISP". ;-) 1627 A special thanks goes to Scott Brim for gathering and analyzing the 1628 mobility requirements and contribuing text for the beginnings of a 1629 simple, robust, and complementary mechanism. 1631 Authors' Addresses 1633 Dino Farinacci 1634 cisco Systems 1635 Tasman Drive 1636 San Jose, CA 95134 1637 USA 1639 Email: dino@cisco.com 1641 Vince Fuller 1642 cisco Systems 1643 Tasman Drive 1644 San Jose, CA 95134 1645 USA 1647 Email: vaf@cisco.com 1649 Dave Oran 1650 cisco Systems 1651 7 Ladyslipper Lane 1652 Acton, MA 1653 USA 1655 Email: oran@cisco.com 1657 Dave Meyer 1658 cisco Systems 1659 170 Tasman Drive 1660 San Jose, CA 1661 USA 1663 Email: dmm@cisco.com 1665 Full Copyright Statement 1667 Copyright (C) The IETF Trust (2007). 1669 This document is subject to the rights, licenses and restrictions 1670 contained in BCP 78, and except as set forth therein, the authors 1671 retain all their rights. 1673 This document and the information contained herein are provided on an 1674 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1675 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1676 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1677 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1678 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1679 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1681 Intellectual Property 1683 The IETF takes no position regarding the validity or scope of any 1684 Intellectual Property Rights or other rights that might be claimed to 1685 pertain to the implementation or use of the technology described in 1686 this document or the extent to which any license under such rights 1687 might or might not be available; nor does it represent that it has 1688 made any independent effort to identify any such rights. Information 1689 on the procedures with respect to rights in RFC documents can be 1690 found in BCP 78 and BCP 79. 1692 Copies of IPR disclosures made to the IETF Secretariat and any 1693 assurances of licenses to be made available, or the result of an 1694 attempt made to obtain a general license or permission for the use of 1695 such proprietary rights by implementers or users of this 1696 specification can be obtained from the IETF on-line IPR repository at 1697 http://www.ietf.org/ipr. 1699 The IETF invites any interested party to bring to its attention any 1700 copyrights, patents or patent applications, or other proprietary 1701 rights that may cover technology that may be required to implement 1702 this standard. Please address the information to the IETF at 1703 ietf-ipr@ietf.org. 1705 Acknowledgment 1707 Funding for the RFC Editor function is provided by the IETF 1708 Administrative Support Activity (IASA).