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