idnits 2.17.1 draft-ietf-lisp-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 and authors 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 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 date (July 27, 2009) is 5379 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) ** 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 (-10) exists of draft-ietf-lisp-alt-01 == Outdated reference: A later version (-04) exists of draft-meyer-lisp-cons-03 == Outdated reference: A later version (-06) exists of draft-ietf-lisp-interworking-00 == Outdated reference: A later version (-02) exists of draft-farinacci-lisp-lig-01 == Outdated reference: A later version (-16) exists of draft-meyer-lisp-mn-00 == Outdated reference: A later version (-16) exists of draft-ietf-lisp-ms-01 -- No information found for draft-mathy-lisp-dht - is the name correct? == Outdated reference: A later version (-14) exists of draft-ietf-lisp-multicast-01 == Outdated reference: A later version (-09) exists of draft-lear-lisp-nerd-04 == 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 -- 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: 6 errors (**), 0 flaws (~~), 14 warnings (==), 3 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. Meyer 5 Expires: January 28, 2010 D. Lewis 6 cisco Systems 7 July 27, 2009 9 Locator/ID Separation Protocol (LISP) 10 draft-ietf-lisp-03.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 28, 2010. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 This draft describes a simple, incremental, network-based protocol to 49 implement separation of Internet addresses into Endpoint Identifiers 50 (EIDs) and Routing Locators (RLOCs). This mechanism requires no 51 changes to host stacks and no major changes to existing database 52 infrastructures. The proposed protocol can be implemented in a 53 relatively small number of routers. 55 This proposal was stimulated by the problem statement effort at the 56 Amsterdam IAB Routing and Addressing Workshop (RAWS), which took 57 place in October 2006. 59 Table of Contents 61 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 62 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 8 64 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 12 65 4.1. Packet Flow Sequence . . . . . . . . . . . . . . . . . . . 14 66 5. Tunneling Details . . . . . . . . . . . . . . . . . . . . . . 16 67 5.1. LISP IPv4-in-IPv4 Header Format . . . . . . . . . . . . . 17 68 5.2. LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 18 69 5.3. Tunnel Header Field Descriptions . . . . . . . . . . . . . 19 70 5.4. Dealing with Large Encapsulated Packets . . . . . . . . . 21 71 5.4.1. A Stateless Solution to MTU Handling . . . . . . . . . 21 72 5.4.2. A Stateful Solution to MTU Handling . . . . . . . . . 22 73 6. EID-to-RLOC Mapping . . . . . . . . . . . . . . . . . . . . . 24 74 6.1. LISP IPv4 and IPv6 Control Plane Packet Formats . . . . . 24 75 6.1.1. LISP Packet Type Allocations . . . . . . . . . . . . . 26 76 6.1.2. Map-Request Message Format . . . . . . . . . . . . . . 26 77 6.1.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . 28 78 6.1.4. Map-Reply Message Format . . . . . . . . . . . . . . . 29 79 6.1.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . 32 80 6.1.6. Map-Register Message Format . . . . . . . . . . . . . 33 81 6.2. Routing Locator Selection . . . . . . . . . . . . . . . . 34 82 6.3. Routing Locator Reachability . . . . . . . . . . . . . . . 36 83 6.3.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 38 84 6.4. Routing Locator Hashing . . . . . . . . . . . . . . . . . 39 85 6.5. Changing the Contents of EID-to-RLOC Mappings . . . . . . 40 86 6.5.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . 40 87 6.5.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . 41 88 7. Router Performance Considerations . . . . . . . . . . . . . . 43 89 8. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 44 90 8.1. First-hop/Last-hop Tunnel Routers . . . . . . . . . . . . 45 91 8.2. Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 45 92 8.3. ISP Provider-Edge (PE) Tunnel Routers . . . . . . . . . . 46 94 9. Traceroute Considerations . . . . . . . . . . . . . . . . . . 47 95 9.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . . 48 96 9.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . . 48 97 9.3. Traceroute using Mixed Locators . . . . . . . . . . . . . 48 98 10. Mobility Considerations . . . . . . . . . . . . . . . . . . . 50 99 10.1. Site Mobility . . . . . . . . . . . . . . . . . . . . . . 50 100 10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 50 101 10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 50 102 10.4. Fast Network Mobility . . . . . . . . . . . . . . . . . . 52 103 10.5. LISP Mobile Node Mobility . . . . . . . . . . . . . . . . 52 104 11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 54 105 12. Security Considerations . . . . . . . . . . . . . . . . . . . 55 106 13. Prototype Plans and Status . . . . . . . . . . . . . . . . . . 56 107 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 59 108 14.1. Normative References . . . . . . . . . . . . . . . . . . . 59 109 14.2. Informative References . . . . . . . . . . . . . . . . . . 60 110 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 63 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 64 113 1. Requirements Notation 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [RFC2119]. 119 2. Introduction 121 Many years of discussion about the current IP routing and addressing 122 architecture have noted that its use of a single numbering space (the 123 "IP address") for both host transport session identification and 124 network routing creates scaling issues (see [CHIAPPA] and [RFC1498]). 125 A number of scaling benefits would be realized by separating the 126 current IP address into separate spaces for Endpoint Identifiers 127 (EIDs) and Routing Locators (RLOCs); among them are: 129 1. Reduction of routing table size in the "default-free zone" (DFZ). 130 Use of a separate numbering space for RLOCs will allow them to be 131 assigned topologically (in today's Internet, RLOCs would be 132 assigned by providers at client network attachment points), 133 greatly improving aggregation and reducing the number of 134 globally-visible, routable prefixes. 136 2. More cost-effective multihoming for sites that connect to 137 different service providers where they can control their own 138 policies for packet flow into the site without using extra 139 routing table resources of core routers. 141 3. Easing of renumbering burden when clients change providers. 142 Because host EIDs are numbered from a separate, non-provider- 143 assigned and non-topologically-bound space, they do not need to 144 be renumbered when a client site changes its attachment points to 145 the network. 147 4. Traffic engineering capabilities that can be performed by network 148 elements and do not depend on injecting additional state into the 149 routing system. This will fall out of the mechanism that is used 150 to implement the EID/RLOC split (see Section 4). 152 5. Mobility without address changing. Existing mobility mechanisms 153 will be able to work in a locator/ID separation scenario. It 154 will be possible for a host (or a collection of hosts) to move to 155 a different point in the network topology either retaining its 156 home-based address or acquiring a new address based on the new 157 network location. A new network location could be a physically 158 different point in the network topology or the same physical 159 point of the topology with a different provider. 161 This draft describes protocol mechanisms to achieve the desired 162 functional separation. For flexibility, the mechanism used for 163 forwarding packets is decoupled from that used to determine EID to 164 RLOC mappings. This document covers the former. For the later, see 165 [CONS], [ALT], [EMACS], [RPMD], and [NERD]. This work is in response 166 to and intended to address the problem statement that came out of the 167 RAWS effort [RFC4984]. 169 The Routing and Addressing problem statement can be found in [RADIR]. 171 This draft focuses on a router-based solution. Building the solution 172 into the network will facilitate incremental deployment of the 173 technology on the Internet. Note that while the detailed protocol 174 specification and examples in this document assume IP version 4 175 (IPv4), there is nothing in the design that precludes use of the same 176 techniques and mechanisms for IPv6. It should be possible for IPv4 177 packets to use IPv6 RLOCs and for IPv6 EIDs to be mapped to IPv4 178 RLOCs. 180 Related work on host-based solutions is described in Shim6 [SHIM6] 181 and HIP [RFC4423]. Related work on a router-based solution is 182 described in [GSE]. This draft attempts to not compete or overlap 183 with such solutions and the proposed protocol changes are expected to 184 complement a host-based mechanism when Traffic Engineering 185 functionality is desired. 187 Some of the design goals of this proposal include: 189 1. Require no hardware or software changes to end-systems (hosts). 191 2. Minimize required changes to Internet infrastructure. 193 3. Be incrementally deployable. 195 4. Require no router hardware changes. 197 5. Minimize the number of routers which have to be modified. In 198 particular, most customer site routers and no core routers 199 require changes. 201 6. Minimize router software changes in those routers which are 202 affected. 204 7. Avoid or minimize packet loss when EID-to-RLOC mappings need to 205 be performed. 207 There are 4 variants of LISP, which differ along a spectrum of strong 208 to weak dependence on the topological nature and possible need for 209 routability of EIDs. The variants are: 211 LISP 1: uses EIDs that are routable through the RLOC topology for 212 bootstrapping EID-to-RLOC mappings. [LISP1] This was intended as 213 a prototyping mechanism for early protocol implementation. It is 214 now deprecated and should not be deployed. 216 LISP 1.5: uses EIDs that are routable for bootstrapping EID-to-RLOC 217 mappings; such routing is via a separate topology. 219 LISP 2: uses EIDS that are not routable and EID-to-RLOC mappings are 220 implemented within the DNS. [LISP2] 222 LISP 3: uses non-routable EIDs that are used as lookup keys for a 223 new EID-to-RLOC mapping database. Use of Distributed Hash Tables 224 [DHTs] [LISPDHT] to implement such a database would be an area to 225 explore. Other examples of new mapping database services are 226 [CONS], [ALT], [RPMD], [NERD], and [APT]. 228 This document on LISP 1.5, and LISP 3 variants, both of which rely on 229 a router-based distributed cache and database for EID-to-RLOC 230 mappings. The LISP 1.0 mechanism works but does not allow reduction 231 of routing information in the default-free-zone of the Internet. The 232 LISP 2 mechanisms are put on hold and may never come to fruition 233 since it is not architecturally pure to have routing depend on 234 directory and directory depend on routing. The LISP 3 mechanisms 235 will be documented elsewhere but may use the control-plane options 236 specified in this specification. 238 3. Definition of Terms 240 Provider Independent (PI) Addresses: an address block assigned from 241 a pool where blocks are not associated with any particular 242 location in the network (e.g. from a particular service provider), 243 and is therefore not topologically aggregatable in the routing 244 system. 246 Provider Assigned (PA) Addresses: a block of IP addresses that are 247 assigned to a site by each service provider to which a site 248 connects. Typically, each block is sub-block of a service 249 provider CIDR block and is aggregated into the larger block before 250 being advertised into the global Internet. Traditionally, IP 251 multihoming has been implemented by each multi-homed site 252 acquiring its own, globally-visible prefix. LISP uses only 253 topologically-assigned and aggregatable address blocks for RLOCs, 254 eliminating this demonstrably non-scalable practice. 256 Routing Locator (RLOC): the IPv4 or IPv6 address of an egress 257 tunnel router (ETR). It is the output of a EID-to-RLOC mapping 258 lookup. An EID maps to one or more RLOCs. Typically, RLOCs are 259 numbered from topologically-aggregatable blocks that are assigned 260 to a site at each point to which it attaches to the global 261 Internet; where the topology is defined by the connectivity of 262 provider networks, RLOCs can be thought of as PA addresses. 263 Multiple RLOCs can be assigned to the same ETR device or to 264 multiple ETR devices at a site. 266 Endpoint ID (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) value 267 used in the source and destination address fields of the first 268 (most inner) LISP header of a packet. The host obtains a 269 destination EID the same way it obtains an destination address 270 today, for example through a DNS lookup or SIP exchange. The 271 source EID is obtained via existing mechanisms used to set a 272 host's "local" IP address. An EID is allocated to a host from an 273 EID-prefix block associated with the site where the host is 274 located. An EID can be used by a host to refer to other hosts. 275 EIDs MUST NOT be used as LISP RLOCs. Note that EID blocks may be 276 assigned in a hierarchical manner, independent of the network 277 topology, to facilitate scaling of the mapping database. In 278 addition, an EID block assigned to a site may have site-local 279 structure (subnetting) for routing within the site; this structure 280 is not visible to the global routing system. When used in 281 discussions with other Locator/ID separation proposals, a LISP EID 282 will be called a "LEID". Throughout this document, any references 283 to "EID" refers to an LEID. 285 EID-prefix: A power-of-2 block of EIDs which are allocated to a 286 site by an address allocation authority. EID-prefixes are 287 associated with a set of RLOC addresses which make up a "database 288 mapping". EID-prefix allocations can be broken up into smaller 289 blocks when an RLOC set is to be associated with the smaller EID- 290 prefix. A globally routed address block (whether PI or PA) is not 291 an EID-prefix. However, a globally routed address block may be 292 removed from global routing and reused as an EID-prefix. A site 293 that receives an explicitly allocated EID-prefix may not use that 294 EID-prefix as a globally routed prefix assigned to RLOCs. 296 End-system: is an IPv4 or IPv6 device that originates packets with 297 a single IPv4 or IPv6 header. The end-system supplies an EID 298 value for the destination address field of the IP header when 299 communicating globally (i.e. outside of its routing domain). An 300 end-system can be a host computer, a switch or router device, or 301 any network appliance. 303 Ingress Tunnel Router (ITR): a router which accepts an IP packet 304 with a single IP header (more precisely, an IP packet that does 305 not contain a LISP header). The router treats this "inner" IP 306 destination address as an EID and performs an EID-to-RLOC mapping 307 lookup. The router then prepends an "outer" IP header with one of 308 its globally-routable RLOCs in the source address field and the 309 result of the mapping lookup in the destination address field. 310 Note that this destination RLOC may be an intermediate, proxy 311 device that has better knowledge of the EID-to-RLOC mapping closer 312 to the destination EID. In general, an ITR receives IP packets 313 from site end-systems on one side and sends LISP-encapsulated IP 314 packets toward the Internet on the other side. 316 Specifically, when a service provider prepends a LISP header for 317 Traffic Engineering purposes, the router that does this is also 318 regarded as an ITR. The outer RLOC the ISP ITR uses can be based 319 on the outer destination address (the originating ITR's supplied 320 RLOC) or the inner destination address (the originating hosts 321 supplied EID). 323 TE-ITR: is an ITR that is deployed in a service provider network 324 that prepends an additional LISP header for Traffic Engineering 325 purposes. 327 Egress Tunnel Router (ETR): a router that accepts an IP packet 328 where the destination address in the "outer" IP header is one of 329 its own RLOCs. The router strips the "outer" header and forwards 330 the packet based on the next IP header found. In general, an ETR 331 receives LISP-encapsulated IP packets from the Internet on one 332 side and sends decapsulated IP packets to site end-systems on the 333 other side. ETR functionality does not have to be limited to a 334 router device. A server host can be the endpoint of a LISP tunnel 335 as well. 337 TE-ETR: is an ETR that is deployed in a service provider network 338 that strips an outer LISP header for Traffic Engineering purposes. 340 xTR: is a reference to an ITR or ETR when direction of data flow is 341 not part of the context description. xTR refers to the router that 342 is the tunnel endpoint. Used synonymously with the term "Tunnel 343 Router". For example, "An xTR can be located at the Customer Edge 344 (CE) router", meaning both ITR and ETR functionality is at the CE 345 router. 347 EID-to-RLOC Cache: a short-lived, on-demand table in an ITR that 348 stores, tracks, and is responsible for timing-out and otherwise 349 validating EID-to-RLOC mappings. This cache is distinct from the 350 full "database" of EID-to-RLOC mappings, it is dynamic, local to 351 the ITR(s), and relatively small while the database is 352 distributed, relatively static, and much more global in scope. 354 EID-to-RLOC Database: a global distributed database that contains 355 all known EID-prefix to RLOC mappings. Each potential ETR 356 typically contains a small piece of the database: the EID-to-RLOC 357 mappings for the EID prefixes "behind" the router. These map to 358 one of the router's own, globally-visible, IP addresses. 360 Recursive Tunneling: when a packet has more than one LISP IP 361 header. Additional layers of tunneling may be employed to 362 implement traffic engineering or other re-routing as needed. When 363 this is done, an additional "outer" LISP header is added and the 364 original RLOCs are preserved in the "inner" header. Any 365 references to tunnels in this specification refers to dynamic 366 encapsulating tunnels and never are they staticly configured. 368 Reencapsulating Tunnels: when a packet has no more than one LISP IP 369 header (two IP headers total) and when it needs to be diverted to 370 new RLOC, an ETR can decapsulate the packet (remove the LISP 371 header) and prepend a new tunnel header, with new RLOC, on to the 372 packet. Doing this allows a packet to be re-routed by the re- 373 encapsulating router without adding the overhead of additional 374 tunnel headers. Any references to tunnels in this specification 375 refers to dynamic encapsulating tunnels and never are they 376 staticly configured. 378 LISP Header: a term used in this document to refer to the outer 379 IPv4 or IPv6 header, a UDP header, and a LISP header, an ITR 380 prepends or an ETR strips. 382 Address Family Indicator (AFI): a term used to describe an address 383 encoding in a packet. An address family currently pertains to an 384 IPv4 or IPv6 address. See [AFI] for details. 386 Negative Mapping Entry: also known as a negative cache entry, is an 387 EID-to-RLOC entry where an EID-prefix is advertised or stored with 388 no RLOCs. That is, the locator-set for the EID-to-RLOC entry is 389 empty or has an encoded locator count of 0. This type of entry 390 could be used to describe a prefix from a non-LISP site, which is 391 explicitly not in the mapping database. There are a set of well 392 defined actions that are encoded in a Negative Map-Reply. 394 Data Probe: a LISP-encapsulated data packet where the inner header 395 destination address equals the outer header destination address 396 used to trigger a Map-Reply by a decapsulating ETR. In addition, 397 the original packet is decapsulated and delivered to the 398 destination host. A Data Probe is used in some of the mapping 399 database designs to "probe" or request a Map-Reply from an ETR; in 400 other cases, Map-Requests are used. See each mapping database 401 design for details. 403 4. Basic Overview 405 One key concept of LISP is that end-systems (hosts) operate the same 406 way they do today. The IP addresses that hosts use for tracking 407 sockets, connections, and for sending and receiving packets do not 408 change. In LISP terminology, these IP addresses are called Endpoint 409 Identifiers (EIDs). 411 Routers continue to forward packets based on IP destination 412 addresses. When a packet is LISP encapsulated, these addresses are 413 referred to as Routing Locators (RLOCs). Most routers along a path 414 between two hosts will not change; they continue to perform routing/ 415 forwarding lookups on the destination addresses. For routers between 416 the source host and the ITR as well as routers from the ETR to the 417 destination host, the destination address is an EID. For the routers 418 between the ITR and the ETR, the destination address is an RLOC. 420 This design introduces "Tunnel Routers", which prepend LISP headers 421 on host-originated packets and strip them prior to final delivery to 422 their destination. The IP addresses in this "outer header" are 423 RLOCs. During end-to-end packet exchange between two Internet hosts, 424 an ITR prepends a new LISP header to each packet and an egress tunnel 425 router strips the new header. The ITR performs EID-to-RLOC lookups 426 to determine the routing path to the the ETR, which has the RLOC as 427 one of its IP addresses. 429 Some basic rules governing LISP are: 431 o End-systems (hosts) only send to addresses which are EIDs. They 432 don't know addresses are EIDs versus RLOCs but assume packets get 433 to LISP routers, which in turn, deliver packets to the destination 434 the end-system has specified. 436 o EIDs are always IP addresses assigned to hosts. 438 o LISP routers mostly deal with Routing Locator addresses. See 439 details later in Section 4.1 to clarify what is meant by "mostly". 441 o RLOCs are always IP addresses assigned to routers; preferably, 442 topologically-oriented addresses from provider CIDR blocks. 444 o When a router originates packets it may use as a source address 445 either an EID or RLOC. When acting as a host (e.g. when 446 terminating a transport session such as SSH, TELNET, or SNMP), it 447 may use an EID that is explicitly assigned for that purpose. An 448 EID that identifies the router as a host MUST NOT be used as an 449 RLOC; an EID is only routable within the scope of a site. A 450 typical BGP configuration might demonstrate this "hybrid" EID/RLOC 451 usage where a router could use its "host-like" EID to terminate 452 iBGP sessions to other routers in a site while at the same time 453 using RLOCs to terminate eBGP sessions to routers outside the 454 site. 456 o EIDs are not expected to be usable for global end-to-end 457 communication in the absence of an EID-to-RLOC mapping operation. 458 They are expected to be used locally for intra-site communication. 460 o EID prefixes are likely to be hierarchically assigned in a manner 461 which is optimized for administrative convenience and to 462 facilitate scaling of the EID-to-RLOC mapping database. The 463 hierarchy is based on a address allocation hierarchy which is not 464 dependent on the network topology. 466 o EIDs may also be structured (subnetted) in a manner suitable for 467 local routing within an autonomous system. 469 An additional LISP header may be prepended to packets by a transit 470 router (i.e. TE-ITR) when re-routing of the path for a packet is 471 desired. An obvious instance of this would be an ISP router that 472 needs to perform traffic engineering for packets in flow through its 473 network. In such a situation, termed Recursive Tunneling, an ISP 474 transit acts as an additional ingress tunnel router and the RLOC it 475 uses for the new prepended header would be either an TE-ETR within 476 the ISP (along intra-ISP traffic engineered path) or in an TE-ETR 477 within another ISP (an inter-ISP traffic engineered path, where an 478 agreement to build such a path exists). 480 This specification mandates that no more than two LISP headers get 481 prepended to a packet. This avoids excessive packet overhead as well 482 as possible encapsulation loops. It is believed two headers is 483 sufficient, where the first prepended header is used at a site for 484 Location/Identity separation and second prepended header is used 485 inside a service provider for Traffic Engineering purposes. 487 Tunnel Routers can be placed fairly flexibly in a multi-AS topology. 488 For example, the ITR for a particular end-to-end packet exchange 489 might be the first-hop or default router within a site for the source 490 host. Similarly, the egress tunnel router might be the last-hop 491 router directly-connected to the destination host. Another example, 492 perhaps for a VPN service out-sourced to an ISP by a site, the ITR 493 could be the site's border router at the service provider attachment 494 point. Mixing and matching of site-operated, ISP-operated, and other 495 tunnel routers is allowed for maximum flexibility. See Section 8 for 496 more details. 498 4.1. Packet Flow Sequence 500 This section provides an example of the unicast packet flow with the 501 following conditions: 503 o Source host "host1.abc.com" is sending a packet to 504 "host2.xyz.com", exactly what host1 would do if the site was not 505 using LISP. 507 o Each site is multi-homed, so each tunnel router has an address 508 (RLOC) assigned from the service provider address block for each 509 provider to which that particular tunnel router is attached. 511 o The ITR(s) and ETR(s) are directly connected to the source and 512 destination, respectively. 514 o Data Probes are used to solicit Map-Replies versus using Map- 515 Requests. And the Data Probes are sent on the underlying topology 516 (the LISP 1.0 variant) but could also be sent over an alternative 517 topology (the LISP 1.5 variant) as it would in [ALT]. 519 Client host1.abc.com wants to communicate with server host2.xyz.com: 521 1. host1.abc.com wants to open a TCP connection to host2.xyz.com. 522 It does a DNS lookup on host2.xyz.com. An A/AAAA record is 523 returned. This address is used as the destination EID and the 524 locally-assigned address of host1.abc.com is used as the source 525 EID. An IPv4 or IPv6 packet is built using the EIDs in the IPv4 526 or IPv6 header and sent to the default router. 528 2. The default router is configured as an ITR. The ITR must be able 529 to map the EID destination to an RLOC of the ETR at the 530 destination site. The ITR prepends a LISP header to the packet, 531 with one of its RLOCs as the source IPv4 or IPv6 address. The 532 destination EID from the original packet header is used as the 533 destination IPv4 or IPv6 in the prepended LISP header. 534 Subsequent packets, where the outer destination address is the 535 destination EID will be sent until EID-to-RLOC mapping is 536 learned. 538 3. In LISP 1, the packet is routed through the Internet as it is 539 today. In LISP 1.5, the packet is routed on a different topology 540 which may have EID prefixes distributed and advertised in an 541 aggregatable fashion. In either case, the packet arrives at the 542 ETR. The router is configured to "punt" the packet to the 543 router's processor. See Section 7 for more details. For LISP 544 2.0 and 3.0, the behavior is not fully defined yet. 546 4. The LISP header is stripped so that the packet can be forwarded 547 by the router control plane. The router looks up the destination 548 EID in the router's EID-to-RLOC database (not the cache, but the 549 configured data structure of RLOCs). An EID-to-RLOC Map-Reply 550 message is originated by the ETR and is addressed to the source 551 RLOC in the LISP header of the original packet (this is the ITR). 552 The source RLOC of the Map-Reply is one of the ETR's RLOCs. 554 5. The ITR receives the Map-Reply message, parses the message (to 555 check for format validity) and stores the mapping information 556 from the packet. This information is put in the ITR's EID-to- 557 RLOC mapping cache (this is the on-demand cache, the cache where 558 entries time out due to inactivity). 560 6. Subsequent packets from host1.abc.com to host2.xyz.com will have 561 a LISP header prepended by the ITR using the appropriate RLOC as 562 the LISP header destination address learned from the ETR. Note, 563 the packet may be sent to a different ETR than the one which 564 returned the Map-Reply due to the source site's hashing policy or 565 the destination site's locator-set policy. 567 7. The ETR receives these packets directly (since the destination 568 address is one of its assigned IP addresses), strips the LISP 569 header and forwards the packets to the attached destination host. 571 In order to eliminate the need for a mapping lookup in the reverse 572 direction, an ETR MAY create a cache entry that maps the source EID 573 (inner header source IP address) to the source RLOC (outer header 574 source IP address) in a received LISP packet. Such a cache entry is 575 termed a "gleaned" mapping and only contains a single RLOC for the 576 EID in question. More complete information about additional RLOCs 577 SHOULD be verified by sending a LISP Map-Request for that EID. Both 578 ITR and the ETR may also influence the decision the other makes in 579 selecting an RLOC. See Section 6 for more details. 581 5. Tunneling Details 583 This section describes the LISP Data Message which defines the 584 tunneling header used to encapsulate IPv4 and IPv6 packets which 585 contain EID addresses. Even though the following formats illustrate 586 IPv4-in-IPv4 and IPv6-in-IPv6 encapsulations, the other 2 587 combinations are supported as well. 589 Since additional tunnel headers are prepended, the packet becomes 590 larger and in theory can exceed the MTU of any link traversed from 591 the ITR to the ETR. It is recommended, in IPv4 that packets do not 592 get fragmented as they are encapsulated by the ITR. Instead, the 593 packet is dropped and an ICMP Too Big message is returned to the 594 source. 596 Based on informal surveys of large ISP traffic patterns, it appears 597 that most transit paths can accommodate a path MTU of at least 4470 598 bytes. The exceptions, in terms of data rate, number of hosts 599 affected, or any other metric are expected to be vanishingly small. 601 To address MTU concerns, mainly raised on the RRG mailing list, the 602 LISP deployment process will include collecting data during its pilot 603 phase to either verify or refute the assumption about minimum 604 available MTU. If the assumption proves true and transit networks 605 with links limited to 1500 byte MTUs are corner cases, it would seem 606 more cost-effective to either upgrade or modify the equipment in 607 those transit networks to support larger MTUs or to use existing 608 mechanisms for accommodating packets that are too large. 610 For this reason, there is currently no plan for LISP to add any new 611 additional, complex mechanism for implementing fragmentation and 612 reassembly in the face of limited-MTU transit links. If analysis 613 during LISP pilot deployment reveals that the assumption of 614 essentially ubiquitous, 4470+ byte transit path MTUs, is incorrect, 615 then LISP can be modified prior to protocol standardization to add 616 support for one of the proposed fragmentation and reassembly schemes. 617 Note that two simple existing schemes are detailed in Section 5.4. 619 5.1. LISP IPv4-in-IPv4 Header Format 621 0 1 2 3 622 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 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 / |Version| IHL |Type of Service| Total Length | 625 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | | Identification |Flags| Fragment Offset | 627 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 OH | Time to Live | Protocol = 17 | Header Checksum | 629 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 | | Source Routing Locator | 631 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 \ | Destination Routing Locator | 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 / | Source Port = xxxx | Dest Port = 4341 | 635 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 \ | UDP Length | UDP Checksum | 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 L / | Locator Reach Bits | 639 I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 S \ |S|E| rsvd-flags| Nonce | 641 P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 / |Version| IHL |Type of Service| Total Length | 643 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 | | Identification |Flags| Fragment Offset | 645 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 IH | Time to Live | Protocol | Header Checksum | 647 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 | | Source EID | 649 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 \ | Destination EID | 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 5.2. LISP IPv6-in-IPv6 Header Format 655 0 1 2 3 656 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 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 / |Version| Traffic Class | Flow Label | 659 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 | | Payload Length | Next Header=17| Hop Limit | 661 v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 | | 663 O + + 664 u | | 665 t + Source Routing Locator + 666 e | | 667 r + + 668 | | 669 H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 d | | 671 r + + 672 | | 673 ^ + Destination Routing Locator + 674 | | | 675 \ + + 676 \ | | 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 / | Source Port = xxxx | Dest Port = 4341 | 679 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 \ | UDP Length | UDP Checksum | 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 L / | Locator Reach Bits | 683 I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 S \ |S|E| rsvd-flags| Nonce | 685 P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 / |Version| Traffic Class | Flow Label | 687 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 / | Payload Length | Next Header | Hop Limit | 689 v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 | | 691 I + + 692 n | | 693 n + Source EID + 694 e | | 695 r + + 696 | | 697 H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 d | | 699 r + + 700 | | 701 ^ + Destination EID + 702 \ | | 703 \ + + 704 \ | | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 5.3. Tunnel Header Field Descriptions 709 IH Header: is the inner header, preserved from the datagram received 710 from the originating host. The source and destination IP 711 addresses are EIDs. 713 OH Header: is the outer header prepended by an ITR. The address 714 fields contain RLOCs obtained from the ingress router's EID-to- 715 RLOC cache. The IP protocol number is "UDP (17)" from [RFC0768]. 716 The DF bit of the Flags field is set to 0. 718 UDP Header: contains a ITR selected source port when encapsulating a 719 packet. See Section 6.4 for details on the hash algorithm used 720 select a source port based on the 5-tuple of the inner header. 721 The destination port MUST be set to the well-known IANA assigned 722 port value 4341. 724 UDP Checksum: this field MUST be transmitted as 0 and ignored on 725 receipt by the ETR. Note, even when the UDP checksum is 726 transmitted as 0 an intervening NAT device can recalculate the 727 checksum and rewrite the UDP checksum field to non-zero. For 728 performance reasons, the ETR MUST ignore the checksum and MUST not 729 do a checksum computation. 731 UDP Length: for an IPv4 encapsulated packet, the inner header Total 732 Length plus the UDP and LISP header lengths are used. For an IPv6 733 encapsulated packet, the inner header Payload Length plus the size 734 of the IPv6 header (40 bytes) plus the size of the UDP and LISP 735 headers are used. The UDP header length is 8 bytes. The LISP 736 header length is 8 bytes when no loc-reach-bit header extensions 737 are used. 739 LISP Locator Reach Bits: in the LISP header are set by an ITR to 740 indicate to an ETR the reachability of the Locators in the source 741 site. Each RLOC in a Map-Reply is assigned an ordinal value from 742 0 to n-1 (when there are n RLOCs in a mapping entry). The Locator 743 Reach Bits are numbered from 0 to n-1 from the right significant 744 bit of the 32-bit field. When a bit is set to 1, the ITR is 745 indicating to the ETR the RLOC associated with the bit ordinal is 746 reachable. See Section 6.3 for details on how an ITR can 747 determine other ITRs at the site are reachable. When a site has 748 multiple EID-prefixes which result in multiple mappings (where 749 each could have a different locator-set), the Locator Reach Bits 750 setting in an encapsulated packet MUST reflect the mapping for the 751 EID-prefix that the inner-header source EID address matches. 753 S: this is the Solicit-Map-Request (SMR) bit. See section 754 Section 6.5.2 for details. 756 E: this is the echo-nonce-request bit. See section Section 6.3.1 for 757 details. 759 rsvd-flags: this 6-bit field is reserved for future flag use. It is 760 set to 0 on transmit and ignored on receipt. 762 LISP Nonce: is a 24-bit value that is randomly generated by an ITR. 763 The nonce is also used when the E-bit is set to request the nonce 764 value to be echoed by the other side when packets are returned. 765 See section Section 6.3.1 for more details. The nonce is also 766 used when SMR-bit is set to solicit the other side to send a Map- 767 Request containing this nonce. See section Section 6.5.2 for 768 details. 770 When doing Recursive Tunneling or ITR/PTR encapsulation: 772 o The OH header Time to Live field (or Hop Limit field, in case of 773 IPv6) MUST be copied from the IH header Time to Live field. 775 o The OH header Type of Service field (or the Traffic Class field, 776 in the case of IPv6) SHOULD be copied from the IH header Type of 777 Service field (with one caveat, see below). 779 When doing Re-encapsulated Tunneling: 781 o The new OH header Time to Live field SHOULD be copied from the 782 stripped OH header Time to Live field. 784 o The new OH header Type of Service field SHOULD be copied from the 785 stripped OH header Type of Service field (with one caveat, see 786 below).. 788 Copying the TTL serves two purposes: first, it preserves the distance 789 the host intended the packet to travel; second, and more importantly, 790 it provides for suppression of looping packets in the event there is 791 a loop of concatenated tunnels due to misconfiguration. 793 The ECN field occupies bits 6 and 7 of both the IPv4 Type of Service 794 field and the IPv6 Traffic Class field [RFC3168]. The ECN field 795 requires special treatment in order to avoid discarding indications 796 of congestion [RFC3168]. ITR encapsulation MUST copy the 2-bit ECN 797 field from the inner header to the outer header. Re-encapsulation 798 MUST copy the 2-bit ECN field from the stripped outer header to the 799 new outer header. If the ECN field contains a congestion indication 800 codepoint (the value is '11', the Congestion Experienced (CE) 801 codepoint), then ETR decapsulation MUST copy the 2-bit ECN field from 802 the stripped outer header to the surviving inner header that is used 803 to forward the packet beyond the ETR. These requirements preserve 804 Congestion Experienced (CE) indications when a packet that uses ECN 805 traverses a LISP tunnel and becomes marked with a CE indication due 806 to congestion between the tunnel endpoints. 808 5.4. Dealing with Large Encapsulated Packets 810 In the event that the MTU issues mentioned above prove to be more 811 serious than expected, this section proposes 2 simple mechanisms to 812 deal with large packets. One is stateless using IP fragmentation and 813 the other is stateful using Path MTU Discovery [RFC1191]. 815 It is left to the implementor to decide if the stateless or stateful 816 mechanism should be implemented. Both or neither can be decided as 817 well since it is a local decision in the ITR regarding how to deal 818 with MTU issues. Sites can interoperate with differing mechanisms. 820 Both stateless and stateful mechanisms also apply to Reencapsulating 821 and Recursive Tunneling. So any actions reference below to an ITR 822 also apply to an TE-ITR. 824 5.4.1. A Stateless Solution to MTU Handling 826 An ITR stateless solution to handle MTU issues is described as 827 follows: 829 1. Define an architectural constant S for the maximum size of a 830 packet, in bytes, an ITR would receive from a source inside of 831 its site. 833 2. Define L to be the maximum size, in bytes, a packet of size S 834 would be after the ITR prepends the LISP header, UDP header, and 835 outer network layer header of size H. 837 3. Calculate: S + H = L. 839 When an ITR receives a packet from a site-facing interface and adds H 840 bytes worth of encapsulation to yield a packet size of L bytes, it 841 resolves the MTU issue by first splitting the original packet into 2 842 equal-sized fragments. A LISP header is then prepended to each 843 fragment. This will ensure that the new, encapsulated packets are of 844 size (S/2 + H), which is always below the effective tunnel MTU. 846 When an ETR receives encapsulated fragments, it treats them as two 847 individually encapsulated packets. It strips the LISP headers then 848 forwards each fragment to the destination host of the destination 849 site. The two fragments are reassembled at the destination host into 850 the single IP datagram that was originated by the source host. 852 This behavior is performed by the ITR when the source host originates 853 a packet with the DF field of the IP header is set to 0. When the DF 854 field of the IP header is set to 1, or the packet is an IPv6 packet 855 originated by the source host, the ITR will drop the packet when the 856 size is greater than L, and sends an ICMP Too Big message to the 857 source with a value of S, where S is (L - H). 859 When the outer header encapsulation uses an IPv4 header the DF bit is 860 always set to 0. 862 This specification recommends that L be defined as 1500. 864 5.4.2. A Stateful Solution to MTU Handling 866 An ITR stateful solution to handle MTU issues is describe as follows 867 and was first introduced in [OPENLISP]: 869 1. The ITR will keep state of the effective MTU for each locator per 870 mapping cache entry. The effective MTU is what the core network 871 can deliver along the path between ITR and ETR. 873 2. When an IPv6 encapsulated packet or an IPv4 encapsulated packet 874 with DF bit set to 0, exceeds what the core network can deliver, 875 one of the intermediate routers on the path will send an ICMP Too 876 Big message to the ITR. The ITR will parse the ICMP message to 877 determine which locator is affected by the effective MTU change 878 and then record the new effective MTU value in the mapping cache 879 entry. 881 3. When a packet is received by the ITR from a source inside of the 882 site and the size of the packet is greater than the effective MTU 883 stored with the mapping cache entry associated with the 884 destination EID the packet is for, the ITR will send an ICMP Too 885 Big message back to the source. The packet size advertised by 886 the ITR in the ICMP Too Big message is the effective MTU minus 887 the LISP encapsulation length. 889 Even though this mechanism is stateful, it has advantages over the 890 stateless IP fragmentation mechanism, by not involving the 891 destination host with reassembly of ITR fragmented packets. 893 6. EID-to-RLOC Mapping 895 6.1. LISP IPv4 and IPv6 Control Plane Packet Formats 897 The following new UDP packet types are used to retrieve EID-to-RLOC 898 mappings: 900 0 1 2 3 901 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 902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 903 |Version| IHL |Type of Service| Total Length | 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 | Identification |Flags| Fragment Offset | 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 | Time to Live | Protocol = 17 | Header Checksum | 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 | Source Routing Locator | 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 | Destination Routing Locator | 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 / | Source Port | Dest Port | 914 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 \ | UDP Length | UDP Checksum | 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 | | 918 | LISP Message | 919 | | 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 0 1 2 3 923 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 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 |Version| Traffic Class | Flow Label | 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 | Payload Length | Next Header=17| Hop Limit | 928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 | | 930 + + 931 | | 932 + Source Routing Locator + 933 | | 934 + + 935 | | 936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 937 | | 938 + + 939 | | 940 + Destination Routing Locator + 941 | | 942 + + 943 | | 944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 945 / | Source Port | Dest Port | 946 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 947 \ | UDP Length | UDP Checksum | 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 | | 950 | LISP Message | 951 | | 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 954 The LISP UDP-based messages are the Map-Request and Map-Reply 955 messages. When a UDP Map-Request is sent, the UDP source port is 956 chosen by the sender and the destination UDP port number is set to 957 4342. When a UDP Map-Reply is sent, the source UDP port number is 958 set to 4342 and the destination UDP port number is copied from the 959 source port of either the Map-Request or the invoking data packet. 961 The UDP Length field will reflect the length of the UDP header and 962 the LISP Message payload. 964 The UDP Checksum is computed and set to non-zero for Map-Request and 965 Map-Reply messages. It MUST be checked on receipt and if the 966 checksum fails, the packet MUST be dropped. 968 LISP-CONS [CONS] use TCP to send LISP control messages. The format 969 of control messages includes the UDP header so the checksum and 970 length fields can be used to protect and delimit message boundaries. 972 This main LISP specification is the authoritative source for message 973 format definitions for the Map-Request and Map-Reply messages. 975 6.1.1. LISP Packet Type Allocations 977 This section will be the authoritative source for allocating LISP 978 Type values. Current allocations are: 980 Reserved: 0 b'0000' 981 LISP Map-Request: 1 b'0001' 982 LISP Map-Reply: 2 b'0010' 983 LISP Map-Register: 3 b'0011' 984 LISP-CONS Open Message: 8 b'1000' 985 LISP-CONS Push-Add Message: 9 b'1001' 986 LISP-CONS Push-Delete Message: 10 b'1010' 987 LISP-CONS Unreachable Message 11 b'1011' 989 6.1.2. Map-Request Message Format 991 0 1 2 3 992 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 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 994 |Type=1 |A|M|P|S| Reserved | Record Count | 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 | Nonce | 997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 998 | Source-EID-AFI | ITR-AFI | 999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1000 | Source EID Address ... | 1001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1002 | Originating ITR RLOC Address ... | 1003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1004 / | Reserved | EID mask-len | EID-prefix-AFI | 1005 Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1006 \ | EID-prefix ... | 1007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1008 | Map-Reply Record ... | 1009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1010 | Mapping Protocol Data | 1011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1013 Packet field descriptions: 1015 Type: 1 (Map-Request) 1017 A: This is an authoritative bit, which is set to 0 for UDP-based Map- 1018 Requests sent by an ITR. 1020 M: When set, it indicates a Map-Reply Record segment is included in 1021 the Map-Request. 1023 P: Indicates that a Map-Request should be treated as a "piggyback" 1024 locator reachability probe. The receiver should respond with a 1025 Map-Reply with the P bit set and the nonce copied from the Map- 1026 Request. Details on this usage will be provided in a future 1027 version of this draft. 1029 S: This is the SMR bit. See Section 6.5.2 for details. 1031 Reserved: Set to 0 on transmission and ignored on receipt. 1033 Record Count: The number of records in this request message. A 1034 record is comprised of the portion of the packet is labeled 'Rec' 1035 above and occurs the number of times equal to Record count. 1037 Nonce: A 4-byte random value created by the sender of the Map- 1038 Request. This nonce will be returned in the Map-Reply. 1040 Source-EID-AFI: Address family of the "Source EID Address" field. 1042 ITR-AFI: Address family of the "Originating ITR RLOC Address" field. 1044 Source EID Address: This is the EID of the source host which 1045 originated the packet which is invoking this Map-Request. 1047 Originating ITR RLOC Address: Used to give the ETR the option of 1048 returning a Map-Reply in the address-family of this locator. 1050 EID mask-len: Mask length for EID prefix. 1052 EID-AFI: Address family of EID-prefix according to [RFC2434] 1054 EID-prefix: 4 bytes if an IPv4 address-family, 16 bytes if an IPv6 1055 address-family. When a Map-Request is sent by an ITR because a 1056 data packet is received for a destination where there is no 1057 mapping entry, the EID-prefix is set to the destination IP address 1058 of the data packet. And the 'EID mask-len' is set to 32 or 128 1059 for IPv4 or IPv6, respectively. When an xTR wants to query a site 1060 about the status of a mapping it already has cached, the EID- 1061 prefix used in the Map-Request has the same mask-length as the 1062 EID-prefix returned from the site when it sent a Map-Reply 1063 message. 1065 Map-Reply Record: When the R bit is set, this field is the size of 1066 the "Record" field in the Map-Reply format. This Map-Reply record 1067 contains the EID-to-RLOC mapping entry associated with the Source 1068 EID. This allows the ETR which will receive this Map-Request to 1069 cache the data if it chooses to do so. 1071 Mapping Protocol Data: See [CONS] or [ALT] for details. This field 1072 is optional and present when the UDP length indicates there is 1073 enough space in the packet to include it. 1075 6.1.3. EID-to-RLOC UDP Map-Request Message 1077 A Map-Request is sent from an ITR when it needs a mapping for an EID, 1078 wants to test an RLOC for reachability, or wants to refresh a mapping 1079 before TTL expiration. For the initial case, the destination IP 1080 address used for the Map-Request is the destination-EID from the 1081 packet which had a mapping cache lookup failure. For the later 2 1082 cases, the destination IP address used for the Map-Request is one of 1083 the RLOC addresses from the locator-set of the map cache entry. In 1084 all cases, the UDP source port number for the Map-Request message is 1085 a randomly allocated 16-bit value and the UDP destination port number 1086 is set to the well-known destination port number 4342. A successful 1087 Map-Reply updates the cached set of RLOCs associated with the EID 1088 prefix range. 1090 Map-Requests can also be LISP encapsulated using UDP destination port 1091 4341 when sent from an ITR to a Map-Resolver. Likewise, Map-Requests 1092 are LISP encapsulated the same way from a Map-Server to an ETR. 1093 Details on encapsulated Map-Requests and Map-Resolvers can be found 1094 in [LISP-MS]. 1096 Map-Requests MUST be rate-limited. It is recommended that a Map- 1097 Request for the same EID-prefix be sent no more than once per second. 1099 6.1.4. Map-Reply Message Format 1101 0 1 2 3 1102 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 1103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1104 |Type=2 |P| Reserved | Record Count | 1105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1106 | Nonce | 1107 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1108 | | Record TTL | 1109 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1110 R | Locator Count | EID mask-len |A| ACT | Reserved | 1111 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1112 c | Reserved | EID-AFI | 1113 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1114 r | EID-prefix | 1115 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1116 | /| Priority | Weight | M Priority | M Weight | 1117 | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1118 | o | Unused Flags |R| Loc-AFI | 1119 | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 | \| Locator | 1121 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1122 | Mapping Protocol Data | 1123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1125 Packet field descriptions: 1127 Type: 2 (Map-Reply) 1129 P: Indicates that the Map-Reply is in response to a "piggyback" 1130 locator reachability Map-Request. The nonce field should contain 1131 a copy of the nonce value from the original Map-Request. Details 1132 on this usage will be provided in a future version of this draft. 1134 Reserved: Set to 0 on transmission and ignored on receipt. 1136 Record Count: The number of records in this reply message. A record 1137 is comprised of that portion of the packet labeled 'Record' above 1138 and occurs the number of times equal to Record count. 1140 Nonce: A 4-byte value set in a Data-Probe packet or a Map-Request 1141 that is echoed here in the Map-Reply. 1143 Record TTL: The time in minutes the recipient of the Map-Reply will 1144 store the mapping. If the TTL is 0, the entry should be removed 1145 from the cache immediately. If the value is 0xffffffff, the 1146 recipient can decide locally how long to store the mapping. 1148 Locator Count: The number of Locator entries. A locator entry 1149 comprises what is labeled above as 'Loc'. The locator count can 1150 be 0 indicating there are no locators for the EID-prefix. 1152 EID mask-len: Mask length for EID prefix. 1154 A: The Authoritative bit, when sent by a UDP-based message is always 1155 set by the ETR. See [CONS] for TCP-based Map-Replies. 1157 ACT: This 3-bit field describes negative Map-Reply actions. These 1158 bits are used only when the 'Locator Count' field is set to 0. 1159 The action bits are encoded only in Map-Reply messages. The 1160 actions defined are used by an ITR or PTR when a destination EID 1161 matches a negative mapping cache entry. The current assigned 1162 values are: 1164 (0) No action: No action is being conveyed by the sender of the 1165 Map-Reply message. 1167 (1) Natively-Forward: The packet is not encapsulated or dropped 1168 but natively forwarded. 1170 (2) Drop: The packet is dropped silently. 1172 (3) Send-Map-Request: The packet invokes sending a Map-Request. 1174 EID-AFI: Address family of EID-prefix according to [RFC2434]. 1176 EID-prefix: 4 bytes if an IPv4 address-family, 16 bytes if an IPv6 1177 address-family. 1179 Priority: each RLOC is assigned a unicast priority. Lower values 1180 are more preferable. When multiple RLOCs have the same priority, 1181 they may be used in a load-split fashion. A value of 255 means 1182 the RLOC MUST NOT be used for unicast forwarding. 1184 Weight: when priorities are the same for multiple RLOCs, the weight 1185 indicates how to balance unicast traffic between them. Weight is 1186 encoded as a percentage of total unicast packets that match the 1187 mapping entry. If a non-zero weight value is used for any RLOC, 1188 then all RLOCs must use a non-zero weight value and then the sum 1189 of all weight values MUST equal 100. If a zero value is used for 1190 any RLOC weight, then all weights MUST be zero and the receiver of 1191 the Map-Reply will decide how to load-split traffic. See 1192 Section 6.4 for a suggested hash algorithm to distribute load 1193 across locators with same priority and equal weight values. When 1194 a single RLOC exists in a mapping entry, the weight value MUST be 1195 set to 100 and ignored on receipt. 1197 M Priority: each RLOC is assigned a multicast priority used by an 1198 ETR in a receiver multicast site to select an ITR in a source 1199 multicast site for building multicast distribution trees. A value 1200 of 255 means the RLOC MUST NOT be used for joining a multicast 1201 distribution tree. 1203 M Weight: when priorities are the same for multiple RLOCs, the 1204 weight indicates how to balance building multicast distribution 1205 trees across multiple ITRs. The weight is encoded as a percentage 1206 of total number of trees build to the source site identified by 1207 the EID-prefix. If a non-zero weight value is used for any RLOC, 1208 then all RLOCs must use a non-zero weight value and then the sum 1209 of all weight values MUST equal 100. If a zero value is used for 1210 any RLOC weight, then all weights MUST be zero and the receiver of 1211 the Map-Reply will decide how to distribute multicast state across 1212 ITRs. 1214 Unused Flags: set to 0 when sending and ignored on receipt. 1216 R: when this bit is set, the locator is known to be reachable from 1217 the Map-Reply sender's perspective. 1219 Locator: an IPv4 or IPv6 address (as encoded by the 'Loc-AFI' field) 1220 assigned to an ETR or router acting as a proxy replier for the 1221 EID-prefix. Note that the destination RLOC address MAY be an 1222 anycast address. A source RLOC can be an anycast address as well. 1223 The source or destination RLOC MUST NOT be the broadcast address 1224 (255.255.255.255 or any subnet broadcast address known to the 1225 router), and MUST NOT be a link-local multicast address. The 1226 source RLOC MUST NOT be a multicast address. The destination RLOC 1227 SHOULD be a multicast address if it is being mapped from a 1228 multicast destination EID. 1230 Mapping Protocol Data: See [CONS] or [ALT] for details. This field 1231 is optional and present when the UDP length indicates there is 1232 enough space in the packet to include it. 1234 6.1.5. EID-to-RLOC UDP Map-Reply Message 1236 When a Data Probe packet or a Map-Request triggers a Map-Reply to be 1237 sent, the RLOCs associated with the EID-prefix matched by the EID in 1238 the original packet destination IP address field will be returned. 1239 The RLOCs in the Map-Reply are the globally-routable IP addresses of 1240 the ETR but are not necessarily reachable; separate testing of 1241 reachability is required. 1243 Note that a Map-Reply may contain different EID-prefix granularity 1244 (prefix + length) than the Map-Request which triggers it. This might 1245 occur if a Map-Request were for a prefix that had been returned by an 1246 earlier Map-Reply. In such a case, the requester updates its cache 1247 with the new prefix information and granularity. For example, a 1248 requester with two cached EID-prefixes that are covered by a Map- 1249 Reply containing one, less-specific prefix, replaces the entry with 1250 the less-specific EID-prefix. Note that the reverse, replacement of 1251 one less-specific prefix with multiple more-specific prefixes, can 1252 also occur but not by removing the less-specific prefix rather by 1253 adding the more-specific prefixes which during a lookup will override 1254 the less-specific prefix. 1256 Replies SHOULD be sent for an EID-prefix no more often than once per 1257 second to the same requesting router. For scalability, it is 1258 expected that aggregation of EID addresses into EID-prefixes will 1259 allow one Map-Reply to satisfy a mapping for the EID addresses in the 1260 prefix range thereby reducing the number of Map-Request messages. 1262 The addresses for a encapsulated data packets or Map-Request message 1263 are swapped and used for sending the Map-Reply. The UDP source and 1264 destination ports are swapped as well. That is, the source port in 1265 the UDP header for the Map-Reply is set to the well-known UDP port 1266 number 4342. 1268 Map-Reply records can have an empty locator-set. This type of a Map- 1269 Reply is called a Negative Map-Reply. Negative Map-Replies convey 1270 special actions by the sender to the ITR or PTR which have solicited 1271 the Map-Reply. There are two primary applications for Negative Map- 1272 Replies. The first is for a Map-Resolver to instruct an ITR or PTR 1273 when a destination is for a LISP site versus a non-LISP site. And 1274 the other is to source quench Map-Requests which are sent for non- 1275 allocated EIDs. 1277 For each Map-Reply record, the list of locators in a locator-set MUST 1278 appear in the same order for each ETR that originates a Map-Reply 1279 message. The locator-set MUST be sorted in order of ascending IP 1280 address where an IPv4 locator address is considered numerically 'less 1281 than' an IPv6 locator addresss. 1283 6.1.6. Map-Register Message Format 1285 The usage details of the Map-Register message can be found in 1286 specification [LISP-MS]. This section solely defines the message 1287 format. 1289 The message is sent in a UDP with a destination UDP port 4342 and a 1290 randomly selected UDP port number. Before an IPv4 or IPv6 network 1291 layer header is prepended, an AH header is prepended to carry 1292 authentication information. The format conforms to the IPsec 1293 specification [RFC2402]. The Map-Register message will use transport 1294 mode by setting the IP protocol number field or the IPv6 next-header 1295 field to 51. 1297 The AH header from [RFC2402] is: 1299 0 1 2 3 1300 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 1301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1302 | Next Header | Payload Len | RESERVED | 1303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1304 | Security Parameters Index (SPI) | 1305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1306 | Sequence Number Field | 1307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1308 | | 1309 + Authentication Data (variable) | 1310 | | 1311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1313 The Next Header field is set to UDP. The SPI field is set to 0 1314 (since no Security Association or Key Exchange protocol is being 1315 used). The Sequence Number is a randomly chosen value by the sender. 1316 The Authentication Data is 16 bytes and holds a MD5 HMAC. 1318 The Map-Register message format is: 1320 0 1 2 3 1321 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 1322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1323 |Type=3 |P| Reserved | Record Count | 1324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1325 | Nonce | 1326 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1327 | | Record TTL | 1328 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1329 R | Locator Count | EID mask-len |A| ACT | Reserved | 1330 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1331 c | Reserved | EID-AFI | 1332 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1333 r | EID-prefix | 1334 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1335 | /| Priority | Weight | M Priority | M Weight | 1336 | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1337 | o | Unused Flags |R| Loc-AFI | 1338 | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1339 | \| Locator | 1340 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1342 Packet field descriptions: 1344 Type: 3 (Map-Register) 1346 P: Set to 1 by an ETR which sends a Map-Register message requesting 1347 for the Map-Server to proxy Map-Reply. The Map-Server will send 1348 non-authoritative Map-Replies on behalf of the ETR. Details on 1349 this usage will be provided in a future version of this draft. 1351 Reserved: Set to 0 on transmission and ignored on receipt. 1353 Record Count: The number of records in this Map-Register message. A 1354 record is comprised of that portion of the packet labeled 'Record' 1355 above and occurs the number of times equal to Record count. 1357 Nonce: The Nonce field is set to 0 in Map-Register messages. 1359 The definition of the rest of the Map-Register can be found in the 1360 Map-Reply section. 1362 6.2. Routing Locator Selection 1364 Both client-side and server-side may need control over the selection 1365 of RLOCs for conversations between them. This control is achieved by 1366 manipulating the Priority and Weight fields in EID-to-RLOC Map-Reply 1367 messages. Alternatively, RLOC information may be gleaned from 1368 received tunneled packets or EID-to-RLOC Map-Request messages. 1370 The following enumerates different scenarios for choosing RLOCs and 1371 the controls that are available: 1373 o Server-side returns one RLOC. Client-side can only use one RLOC. 1374 Server-side has complete control of the selection. 1376 o Server-side returns a list of RLOC where a subset of the list has 1377 the same best priority. Client can only use the subset list 1378 according to the weighting assigned by the server-side. In this 1379 case, the server-side controls both the subset list and load- 1380 splitting across its members. The client-side can use RLOCs 1381 outside of the subset list if it determines that the subset list 1382 is unreachable (unless RLOCs are set to a Priority of 255). Some 1383 sharing of control exists: the server-side determines the 1384 destination RLOC list and load distribution while the client-side 1385 has the option of using alternatives to this list if RLOCs in the 1386 list are unreachable. 1388 o Server-side sets weight of 0 for the RLOC subset list. In this 1389 case, the client-side can choose how the traffic load is spread 1390 across the subset list. Control is shared by the server-side 1391 determining the list and the client determining load distribution. 1392 Again, the client can use alternative RLOCs if the server-provided 1393 list of RLOCs are unreachable. 1395 o Either side (more likely on the server-side ETR) decides not to 1396 send a Map-Request. For example, if the server-side ETR does not 1397 send Map-Requests, it gleans RLOCs from the client-side ITR, 1398 giving the client-side ITR responsibility for bidirectional RLOC 1399 reachability and preferability. Server-side ETR gleaning of the 1400 client-side ITR RLOC is done by caching the inner header source 1401 EID and the outer header source RLOC of received packets. The 1402 client-side ITR controls how traffic is returned and can alternate 1403 using an outer header source RLOC, which then can be added to the 1404 list the server-side ETR uses to return traffic. Since no 1405 Priority or Weights are provided using this method, the server- 1406 side ETR must assume each client-side ITR RLOC uses the same best 1407 Priority with a Weight of zero. In addition, since EID-prefix 1408 encoding cannot be conveyed in data packets, the EID-to-RLOC cache 1409 on tunnel routers can grow to be very large. 1411 RLOCs that appear in EID-to-RLOC Map-Reply messages are considered 1412 reachable. The Map-Reply and the database mapping service does not 1413 provide any reachability status for Locators. This is done outside 1414 of the mapping service. See next section for details. 1416 6.3. Routing Locator Reachability 1418 There are 4 methods for determining when a Locator is either 1419 reachable or has become unreachable: 1421 1. Locator reachability is determined by an ETR by examining the 1422 Loc-Reach-Bits from a LISP header of a encapsulated data packet 1423 which is provided by an ITR when an ITR encapsulates data. 1425 2. Locator unreachability is determined by an ITR by receiving ICMP 1426 Network or Host Unreachable messages. 1428 3. Locator unreachability can also be determined by an BGP-enabled 1429 ITR when there is no prefix matching a Locator address from the 1430 BGP RIB. 1432 4. Locator unreachability is determined when a host sends an ICMP 1433 Port Unreachable message. This occurs when an ITR may not use 1434 any methods of interworking. one which is describe in [INTERWORK] 1435 and the encapsulated data packet is received by a host at the 1436 destination non-LISP site. 1438 5. Locator reachability is determined by receiving a Map-Reply 1439 message from a ETR's Locator address in response to a previously 1440 sent Map-Request. 1442 6. Locator reachability can also be determined by receiving packets 1443 encapsulated by the ITR assigned to the locator address. 1445 When determining Locator reachability by examining the Loc-Reach-Bits 1446 from the LISP encapsulate data packet, an ETR will receive up to date 1447 status from the ITR closest to the Locators at the source site. The 1448 ITRs at the source site can determine reachability when running their 1449 IGP at the site. When the ITRs are deployed on CE routers, typically 1450 a default route is injected into the site's IGP from each of the 1451 ITRs. If an ITR goes down, the CE-PE link goes down, or the PE 1452 router goes down, the CE router withdraws the default route. This 1453 allows the other ITRs at the site to determine one of the Locators 1454 has gone unreachable. 1456 The Locators listed in a Map-Reply are numbered with ordinals 0 to 1457 n-1. The Loc-Reach-Bits in a LISP Data Message are numbered from 0 1458 to n-1 starting with the least significant bit numbered as 0. So, 1459 for example, if the ITR with locator listed as the 3rd Locator 1460 position in the Map-Reply goes down, all other ITRs at the site will 1461 have the 3rd bit from the right cleared (the bit that corresponds to 1462 ordinal 2). 1464 When an ETR decapsulates a packet, it will look for a change in the 1465 Loc-Reach-Bits value. When a bit goes from 1 to 0, the ETR will 1466 refrain from encapsulating packets to the Locator that has just gone 1467 unreachable. It can start using the Locator again when the bit that 1468 corresponds to the Locator goes from 0 to 1. Loc-Reach-Bits are 1469 associated with a locator-set per EID-prefix. Therefore, when a 1470 locator becomes unreachable, the loc-reach-bit that corresponds to 1471 that locator's position in the list returned by the last Map-Reply 1472 will be set to zero for that particular EID-prefix. 1474 When ITRs at the site are not deployed in CE routers, the IGP can 1475 still be used to determine the reachability of Locators provided they 1476 are injected a stub links into the IGP. This is typically done when 1477 a /32 address is configured on a loopback interface. 1479 When ITRs receive ICMP Network or Host Unreachable messages as a 1480 method to determine unreachability, they will refrain from using 1481 Locators which are described in Locator lists of Map-Replies. 1482 However, using this approach is unreliable because many network 1483 operators turn off generation of ICMP Unreachable messages. 1485 If an ITR does receive an ICMP Network or Host Unreachable message, 1486 it MAY originate its own ICMP Unreachable message destined for the 1487 host that originated the data packet the ITR encapsulated. 1489 Also, BGP-enabled ITRs can unilaterally examine the BGP RIB to see if 1490 a locator address from a locator-set in a mapping entry matches a 1491 prefix. If it does not find one and BGP is running in the Default 1492 Free Zone (DFZ), it can decide to not use the locator even though the 1493 Loc-Reach-Bits indicate the locator is up. In this case, the path 1494 from the ITR to the ETR that is assigned the locator is not 1495 available. More details are in [LOC-ID-ARCH]. 1497 Optionally, an ITR can send a Map-Request to a Locator and if a Map- 1498 Reply is returned, reachability of the Locator has been determined. 1499 Obviously, sending such probes increases the number of control 1500 messages originated by tunnel routers for active flows, so Locators 1501 are assumed to be reachable when they are advertised. 1503 This assumption does create a dependency: Locator unreachability is 1504 detected by the receipt of ICMP Host Unreachable messages. When an 1505 Locator has been determined to be unreachable, it is not used for 1506 active traffic; this is the same as if it were listed in a Map-Reply 1507 with priority 255. 1509 The ITR can test the reachability of the unreachable Locator by 1510 sending periodic Requests. Both Requests and Replies MUST be rate- 1511 limited. Locator reachability testing is never done with data 1512 packets since that increases the risk of packet loss for end-to-end 1513 sessions. 1515 When an ETR decapsulates a packet, it knows that it is reachable from 1516 the encapsulating ITR because that is how the packet arrived. In 1517 most cases, the ETR can also reach the ITR but cannot assume this to 1518 be true due to the possibility of path assymetry. In the presence of 1519 unidirectional traffic flow from an ITR to an ETR, the ITR should not 1520 use the lack of return traffic as an indication that the ETR is 1521 unreachable. Instead, it must use an alternate mechanisms to 1522 determine reachability. 1524 6.3.1. Echo Nonce Algorithm 1526 When there is bidirectional data flow between a pair of locators, a 1527 simple mechanism called "nonce echoing" can be used to determine 1528 reachability between an ITR and ETR. When an ITR wants to solicit a 1529 nonce echo, it sets the E-bit and places a 24-bit nonce in the LISP 1530 header of the next encapsulated data packet. 1532 When this packet is received by the ETR, the encapsulated packet is 1533 forwarded as normal. When the ETR next sends a data packet to the 1534 ITR, it includes the nonce received earlier with the E-bit cleared. 1535 The ITR sees this "echoed nonce" and knows the path to and from the 1536 ETR is up. 1538 The ITR will set the E-bit for every packet it sends while in echo- 1539 nonce-request state. The time the ITR waits to process the echoed 1540 nonce before it determines the path is unreachable is variable and a 1541 choice left for the implementation. 1543 If the ITR is receiving packets from the ETR but does not see the 1544 nonce echoed while being in echo-nonce-request state, then the path 1545 to the ETR is unreachable. This decision may be overridden by other 1546 locator reachability algorithms. Once the ITR determines the path to 1547 the ETR is down it can switch to another locator for that EID-prefix. 1549 Note that "ITR" and "ETR" are relative terms here. Both devices must 1550 be implementing both ITR and ETR functionality for the echo nonce 1551 mechanism to operate. 1553 The ITR and ETR may both go into echo-nonce-request state at the same 1554 time. The number of packets sent or the time during which echo nonce 1555 requests are sent is an implementation specific setting. However, 1556 when an ITR is in echo-nonce-request state, it can echo the ETR's 1557 nonce in the next set of packets that it encapsulates and then 1558 subsequently, continue sending echo-nonce-request packets. 1560 This mechanism does not completely solve the forward path 1561 reachability problem as traffic may be unidirectional. That is, the 1562 ETR receiving traffic at a site may not may not be the same device as 1563 an ITR which transmits traffic from that site or the site to site 1564 traffic is unidirectional so there is no ITR returning traffic. 1566 Note that other locator reachability mechanisms are being researched 1567 and can be used to compliment or even override the Echo Nonce 1568 Algorithm. 1570 6.4. Routing Locator Hashing 1572 When an ETR provides an EID-to-RLOC mapping in a Map-Reply message to 1573 a requesting ITR, the locator-set for the EID-prefix may contain 1574 different priority values for each locator address. When more than 1575 one best priority locator exists, the ITR can decide how to load 1576 share traffic against the corresponding locators. 1578 The following hash algorithm may be used by an ITR to select a 1579 locator for a packet destined to an EID for the EID-to-RLOC mapping: 1581 1. Either a source and destination address hash can be used or the 1582 traditional 5-tuple hash which includes the source and 1583 destination addresses, source and destination TCP, UDP, or SCTP 1584 port numbers and the IP protocol number field or IPv6 next- 1585 protocol fields of a packet a host originates from within a LISP 1586 site. When a packet is not a TCP, UDP, or SCTP packet, the 1587 source and destination addresses only from the header are used to 1588 compute the hash. 1590 2. Take the hash value and divide it by the number of locators 1591 stored in the locator-set for the EID-to-RLOC mapping. 1593 3. The remainder will be yield a value of 0 to "number of locators 1594 minus 1". Use the remainder to select the locator in the 1595 locator-set. 1597 Note that when a packet is LISP encapsulated, the source port number 1598 in the outer UDP header needs to be set. Selecting a random value 1599 allows core routers which are attached to Link Aggregation Groups 1600 (LAGs) to load-split the encapsulated packets across member links of 1601 such LAGs. Otherwise, core routers would see a single flow, since 1602 packets have a source address of the ITR, for packets which are 1603 originated by different EIDs at the source site. A suggested setting 1604 for the source port number computed by an ITR is a 5-tuple hash 1605 function on the inner header, as described above. 1607 6.5. Changing the Contents of EID-to-RLOC Mappings 1609 Since the LISP architecture uses a caching scheme to retrieve and 1610 store EID-to-RLOC mappings, the only way an ITR can get a more up-to- 1611 date mapping is to re-request the mapping. However, the ITRs do not 1612 know when the mappings change and the ETRs do not keep track of who 1613 requested its mappings. For scalability reasons, we want to maintain 1614 this approach but need to provide a way for ETRs change their 1615 mappings and inform the sites that are currently communicating with 1616 the ETR site using such mappings. 1618 When a locator record is added to the end of a locator-set, it is 1619 easy to update mappings. We assume new mappings will maintain the 1620 same locator ordering as the old mapping but just have new locators 1621 appended to the end of the list. So some ITRs can have a new mapping 1622 while other ITRs have only an old mapping that is used until they 1623 time out. When an ITR has only an old mapping but detects bits set 1624 in the loc-reach-bits that correspond to locators beyond the list it 1625 has cached, it simply ignores them. 1627 When a locator record is removed from a locator-set, ITRs that have 1628 the mapping cached will not use the removed locator because the xTRs 1629 will set the loc-reach-bit to 0. So even if the locator is in the 1630 list, it will not be used. For new mapping requests, the xTRs can 1631 set the locator address to 0 as well as setting the corresponding 1632 loc-reach-bit to 0. This forces ITRs with old or new mappings to 1633 avoid using the removed locator. 1635 If many changes occur to a mapping over a long period of time, one 1636 will find empty record slots in the middle of the locator-set and new 1637 records appended to the locator-set. At some point, it would be 1638 useful to compact the locator-set so the loc-reach-bit settings can 1639 be efficiently packed. 1641 We propose here two approaches for locator-set compaction, one 1642 operational and the other a protocol mechanism. The operational 1643 approach uses a clock sweep method. The protocol approach uses the 1644 concept of Solicit-Map-Requests. 1646 6.5.1. Clock Sweep 1648 The clock sweep approach uses planning in advance and the use of 1649 count-down TTLs to time out mappings that have already been cached. 1650 The default setting for an EID-to-RLOC mapping TTL is 24 hours. So 1651 there is a 24 hour window to time out old mappings. The following 1652 clock sweep procedure is used: 1654 1. 24 hours before a mapping change is to take effect, a network 1655 administrator configures the ETRs at a site to start the clock 1656 sweep window. 1658 2. During the clock sweep window, ETRs continue to send Map-Reply 1659 messages with the current (unchanged) mapping records. The TTL 1660 for these mappings is set to 1 hour. 1662 3. 24 hours later, all previous cache entries will have timed out, 1663 and any active cache entries will time out within 1 hour. During 1664 this 1 hour window the ETRs continue to send Map-Reply messages 1665 with the current (unchanged) mapping records with the TTL set to 1666 1 minute. 1668 4. At the end of the 1 hour window, the ETRs will send Map-Reply 1669 messages with the new (changed) mapping records. So any active 1670 caches can get the new mapping contents right away if not cached, 1671 or in 1 minute if they had the mapping cached. 1673 6.5.2. Solicit-Map-Request (SMR) 1675 Soliciting a Map-Request is a selective way for xTRs, at the site 1676 where mappings change, to control the rate they receive requests for 1677 Map-Reply messages. SMRs are also used to tell remote ITRs to update 1678 the mappings they have cached. 1680 Since the xTRs don't keep track of remote ITRs that have cached their 1681 mappings, they can not tell exactly who needs the new mapping 1682 entries. So an xTR will solicit Map-Requests from sites it is 1683 currently sending encapsulated data to, and only from those sites. 1684 The xTRs can locally decide the algorithm for how often and to how 1685 many sites it sends SMR messages. 1687 An SMR message is simply a bit set in an encapsulated data packet 1688 (and a Map-Request message). When an ETR at a remote site 1689 decapsulates a data packet that has the SMR bit set, it can tell that 1690 a new Map-Request message is being solicited. Both the xTR that 1691 sends the SMR message and the site that acts on the SMR message MUST 1692 be rate-limited. 1694 The following procedure shows how a SMR exchange occurs when a site 1695 is doing locator-set compaction for an EID-to-RLOC mapping: 1697 1. When the database mappings in an ETR change, the ITRs at the site 1698 begin to set the SMR bit in packets they encapsulate to the sites 1699 they communicate with. 1701 2. A remote xTR which decapsulates a packet with the SMR bit set 1702 will schedule sending a Map-Request message to the source locator 1703 address of the encapsulated packet. The nonce in the Map-Request 1704 is copied from the nonce in the encapsulated data packet that has 1705 the SMR bit set. 1707 3. The remote xTR retransmits the Map-Request slowly until it gets a 1708 Map-Reply while continuing to use the cached mapping. 1710 4. The ETRs at the site with the changed mapping will reply to the 1711 Map-Request with a Map-Reply message provided the Map-Request 1712 nonce matches the nonce from the SMR. The Map-Reply messages 1713 SHOULD be rate limited. This is important to avoid Map-Reply 1714 implosion. 1716 5. The ETRs, at the site with the changed mapping, records the fact 1717 that the site that sent the Map-Request has received the new 1718 mapping data in the mapping cache entry for the remote site so 1719 the loc-reach-bits are reflective of the new mapping for packets 1720 going to the remote site. The ETR then stops sending packets 1721 with the SMR-bit set. 1723 For security reasons an ITR MUST NOT process unsolicited Map-Replies. 1724 The nonce MUST be carried from SMR packet, into the resultant Map- 1725 Request, and then into Map-Reply to reduce spoofing attacks. 1727 7. Router Performance Considerations 1729 LISP is designed to be very hardware-based forwarding friendly. By 1730 doing tunnel header prepending [RFC1955] and stripping instead of re- 1731 writing addresses, existing hardware can support the forwarding model 1732 with little or no modification. Where modifications are required, 1733 they should be limited to re-programming existing hardware rather 1734 than requiring expensive design changes to hard-coded algorithms in 1735 silicon. 1737 A few implementation techniques can be used to incrementally 1738 implement LISP: 1740 o When a tunnel encapsulated packet is received by an ETR, the outer 1741 destination address may not be the address of the router. This 1742 makes it challenging for the control plane to get packets from the 1743 hardware. This may be mitigated by creating special FIB entries 1744 for the EID-prefixes of EIDs served by the ETR (those for which 1745 the router provides an RLOC translation). These FIB entries are 1746 marked with a flag indicating that control plane processing should 1747 be performed. The forwarding logic of testing for particular IP 1748 protocol number value is not necessary. No changes to existing, 1749 deployed hardware should be needed to support this. 1751 o On an ITR, prepending a new IP header is as simple as adding more 1752 bytes to a MAC rewrite string and prepending the string as part of 1753 the outgoing encapsulation procedure. Many routers that support 1754 GRE tunneling [RFC2784] or 6to4 tunneling [RFC3056] can already 1755 support this action. 1757 o When a received packet's outer destination address contains an EID 1758 which is not intended to be forwarded on the routable topology 1759 (i.e. LISP 1.5), the source address of a data packet or the 1760 router interface with which the source is associated (the 1761 interface from which it was received) can be associated with a VRF 1762 (Virtual Routing/Forwarding), in which a different (i.e. non- 1763 congruent) topology can be used to find EID-to-RLOC mappings. 1765 8. Deployment Scenarios 1767 This section will explore how and where ITRs and ETRs can be deployed 1768 and will discuss the pros and cons of each deployment scenario. 1769 There are two basic deployment trade-offs to consider: centralized 1770 versus distributed caches and flat, recursive, or re-encapsulating 1771 tunneling. 1773 When deciding on centralized versus distributed caching, the 1774 following issues should be considered: 1776 o Are the tunnel routers spread out so that the caches are spread 1777 across all the memories of each router? 1779 o Should management "touch points" be minimized by choosing few 1780 tunnel routers, just enough for redundancy? 1782 o In general, using more ITRs doesn't increase management load, 1783 since caches are built and stored dynamically. On the other hand, 1784 more ETRs does require more management since EID-prefix-to-RLOC 1785 mappings need to be explicitly configured. 1787 When deciding on flat, recursive, or re-encapsulation tunneling, the 1788 following issues should be considered: 1790 o Flat tunneling implements a single tunnel between source site and 1791 destination site. This generally offers better paths between 1792 sources and destinations with a single tunnel path. 1794 o Recursive tunneling is when tunneled traffic is again further 1795 encapsulated in another tunnel, either to implement VPNs or to 1796 perform Traffic Engineering. When doing VPN-based tunneling, the 1797 site has some control since the site is prepending a new tunnel 1798 header. In the case of TE-based tunneling, the site may have 1799 control if it is prepending a new tunnel header, but if the site's 1800 ISP is doing the TE, then the site has no control. Recursive 1801 tunneling generally will result in suboptimal paths but at the 1802 benefit of steering traffic to resource available parts of the 1803 network. 1805 o The technique of re-encapsulation ensures that packets only 1806 require one tunnel header. So if a packet needs to be rerouted, 1807 it is first decapsulated by the ETR and then re-encapsulated with 1808 a new tunnel header using a new RLOC. 1810 The next sub-sections will describe where tunnel routers can reside 1811 in the network. 1813 8.1. First-hop/Last-hop Tunnel Routers 1815 By locating tunnel routers close to hosts, the EID-prefix set is at 1816 the granularity of an IP subnet. So at the expense of more EID- 1817 prefix-to-RLOC sets for the site, the caches in each tunnel router 1818 can remain relatively small. But caches always depend on the number 1819 of non-aggregated EID destination flows active through these tunnel 1820 routers. 1822 With more tunnel routers doing encapsulation, the increase in control 1823 traffic grows as well: since the EID-granularity is greater, more 1824 Map-Requests and Map-Replies are traveling between more routers. 1826 The advantage of placing the caches and databases at these stub 1827 routers is that the products deployed in this part of the network 1828 have better price-memory ratios then their core router counterparts. 1829 Memory is typically less expensive in these devices and fewer routes 1830 are stored (only IGP routes). These devices tend to have excess 1831 capacity, both for forwarding and routing state. 1833 LISP functionality can also be deployed in edge switches. These 1834 devices generally have layer-2 ports facing hosts and layer-3 ports 1835 facing the Internet. Spare capacity is also often available in these 1836 devices as well. 1838 8.2. Border/Edge Tunnel Routers 1840 Using customer-edge (CE) routers for tunnel endpoints allows the EID 1841 space associated with a site to be reachable via a small set of RLOCs 1842 assigned to the CE routers for that site. 1844 This offers the opposite benefit of the first-hop/last-hop tunnel 1845 router scenario: the number of mapping entries and network management 1846 touch points are reduced, allowing better scaling. 1848 One disadvantage is that less of the network's resources are used to 1849 reach host endpoints thereby centralizing the point-of-failure domain 1850 and creating network choke points at the CE router. 1852 Note that more than one CE router at a site can be configured with 1853 the same IP address. In this case an RLOC is an anycast address. 1854 This allows resilience between the CE routers. That is, if a CE 1855 router fails, traffic is automatically routed to the other routers 1856 using the same anycast address. However, this comes with the 1857 disadvantage where the site cannot control the entrance point when 1858 the anycast route is advertised out from all border routers. 1860 8.3. ISP Provider-Edge (PE) Tunnel Routers 1862 Use of ISP PE routers as tunnel endpoint routers gives an ISP control 1863 over the location of the egress tunnel endpoints. That is, the ISP 1864 can decide if the tunnel endpoints are in the destination site (in 1865 either CE routers or last-hop routers within a site) or at other PE 1866 edges. The advantage of this case is that two or more tunnel headers 1867 can be avoided. By having the PE be the first router on the path to 1868 encapsulate, it can choose a TE path first, and the ETR can 1869 decapsulate and re-encapsulate for a tunnel to the destination end 1870 site. 1872 An obvious disadvantage is that the end site has no control over 1873 where its packets flow or the RLOCs used. 1875 As mentioned in earlier sections a combination of these scenarios is 1876 possible at the expense of extra packet header overhead, if both site 1877 and provider want control, then recursive or re-encapsulating tunnels 1878 are used. 1880 9. Traceroute Considerations 1882 When a source host in a LISP site initiates a traceroute to a 1883 destination host in another LISP site, it is highly desirable for it 1884 to see the entire path. Since packets are encapsulated from ITR to 1885 ETR, the hop across the tunnel could be viewed as a single hop. 1886 However, LISP traceroute will provide the entire path so the user can 1887 see 3 distinct segments of the path from a source LISP host to a 1888 destination LISP host: 1890 Segment 1 (in source LISP site based on EIDs): 1892 source-host ---> first-hop ... next-hop ---> ITR 1894 Segment 2 (in the core network based on RLOCs): 1896 ITR ---> next-hop ... next-hop ---> ETR 1898 Segment 3 (in the destination LISP site based on EIDs): 1900 ETR ---> next-hop ... last-hop ---> destination-host 1902 For segment 1 of the path, ICMP Time Exceeded messages are returned 1903 in the normal matter as they are today. The ITR performs a TTL 1904 decrement and test for 0 before encapsulating. So the ITR hop is 1905 seen by the traceroute source has an EID address (the address of 1906 site-facing interface). 1908 For segment 2 of the path, ICMP Time Exceeded messages are returned 1909 to the ITR because the TTL decrement to 0 is done on the outer 1910 header, so the destination of the ICMP messages are to the ITR RLOC 1911 address, the source source RLOC address of the encapsulated 1912 traceroute packet. The ITR looks inside of the ICMP payload to 1913 inspect the traceroute source so it can return the ICMP message to 1914 the address of the traceroute client as well as retaining the core 1915 router IP address in the ICMP message. This is so the traceroute 1916 client can display the core router address (the RLOC address) in the 1917 traceroute output. The ETR returns its RLOC address and responds to 1918 the TTL decrement to 0 like the previous core routers did. 1920 For segment 3, the next-hop router downstream from the ETR will be 1921 decrementing the TTL for the packet that was encapsulated, sent into 1922 the core, decapsulated by the ETR, and forwarded because it isn't the 1923 final destination. If the TTL is decremented to 0, any router on the 1924 path to the destination of the traceroute, including the next-hop 1925 router or destination, will send an ICMP Time Exceeded message to the 1926 source EID of the traceroute client. The ICMP message will be 1927 encapsulated by the local ITR and sent back to the ETR in the 1928 originated traceroute source site, where the packet will be delivered 1929 to the host. 1931 9.1. IPv6 Traceroute 1933 IPv6 traceroute follows the procedure described above since the 1934 entire traceroute data packet is included in ICMP Time Exceeded 1935 message payload. Therefore, only the ITR needs to pay special 1936 attention for forwarding ICMP messages back to the traceroute source. 1938 9.2. IPv4 Traceroute 1940 For IPv4 traceroute, we cannot follow the above procedure since IPv4 1941 ICMP Time Exceeded messages only include the invoking IP header and 8 1942 bytes that follow the IP header. Therefore, when a core router sends 1943 an IPv4 Time Exceeded message to an ITR, all the ITR has in the ICMP 1944 payload is the encapsulated header it prepended followed by a UDP 1945 header. The original invoking IP header, and therefore the identity 1946 of the traceroute source is lost. 1948 The solution we propose to solve this problem is to cache traceroute 1949 IPv4 headers in the ITR and to match them up with corresponding IPv4 1950 Time Exceeded messages received from core routers and the ETR. The 1951 ITR will use a circular buffer for caching the IPv4 and UDP headers 1952 of traceroute packets. It will select a 16-bit number as a key to 1953 find them later when the IPv4 Time Exceeded messages are received. 1954 When an ITR encapsulates an IPv4 traceroute packet, it will use the 1955 16-bit number as the UDP source port in the encapsulating header. 1956 When the ICMP Time Exceeded message is returned to the ITR, the UDP 1957 header of the encapsulating header is present in the ICMP payload 1958 thereby allowing the ITR to find the cached headers for the 1959 traceroute source. The ITR puts the cached headers in the payload 1960 and sends the ICMP Time Exceeded message to the traceroute source 1961 retaining the source address of the original ICMP Time Exceeded 1962 message (a core router or the ETR of the site of the traceroute 1963 destination). 1965 9.3. Traceroute using Mixed Locators 1967 When either an IPv4 traceroute or IPv6 traceroute is originated and 1968 the ITR encapsulates it in the other address family header, you 1969 cannot get all 3 segments of the traceroute. Segment 2 of the 1970 traceroute can not be conveyed to the traceroute source since it is 1971 expecting addresses from intermediate hops in the same address format 1972 for the type of traceroute it originated. Therefore, in this case, 1973 segment 2 will make the tunnel look like one hop. All the ITR has to 1974 do to make this work is to not copy the inner TTL to the outer, 1975 encapsulating header's TTL when a traceroute packet is encapsulated 1976 using an RLOC from a different address family. This will cause no 1977 TTL decrement to 0 to occur in core routers between the ITR and ETR. 1979 10. Mobility Considerations 1981 There are several kinds of mobility of which only some might be of 1982 concern to LISP. Essentially they are as follows. 1984 10.1. Site Mobility 1986 A site wishes to change its attachment points to the Internet, and 1987 its LISP Tunnel Routers will have new RLOCs when it changes upstream 1988 providers. Changes in EID-RLOC mappings for sites are expected to be 1989 handled by configuration, outside of the LISP protocol. 1991 10.2. Slow Endpoint Mobility 1993 An individual endpoint wishes to move, but is not concerned about 1994 maintaining session continuity. Renumbering is involved. LISP can 1995 help with the issues surrounding renumbering [RFC4192] [LISA96] by 1996 decoupling the address space used by a site from the address spaces 1997 used by its ISPs. [RFC4984] 1999 10.3. Fast Endpoint Mobility 2001 Fast endpoint mobility occurs when an endpoint moves relatively 2002 rapidly, changing its IP layer network attachment point. Maintenance 2003 of session continuity is a goal. This is where the Mobile IPv4 2004 [RFC3344bis] and Mobile IPv6 [RFC3775] [RFC4866] mechanisms are used, 2005 and primarily where interactions with LISP need to be explored. 2007 The problem is that as an endpoint moves, it may require changes to 2008 the mapping between its EID and a set of RLOCs for its new network 2009 location. When this is added to the overhead of mobile IP binding 2010 updates, some packets might be delayed or dropped. 2012 In IPv4 mobility, when an endpoint is away from home, packets to it 2013 are encapsulated and forwarded via a home agent which resides in the 2014 home area the endpoint's address belongs to. The home agent will 2015 encapsulate and forward packets either directly to the endpoint or to 2016 a foreign agent which resides where the endpoint has moved to. 2017 Packets from the endpoint may be sent directly to the correspondent 2018 node, may be sent via the foreign agent, or may be reverse-tunneled 2019 back to the home agent for delivery to the mobile node. As the 2020 mobile node's EID or available RLOC changes, LISP EID-to-RLOC 2021 mappings are required for communication between the mobile node and 2022 the home agent, whether via foreign agent or not. As a mobile 2023 endpoint changes networks, up to three LISP mapping changes may be 2024 required: 2026 o The mobile node moves from an old location to a new visited 2027 network location and notifies its home agent that it has done so. 2028 The Mobile IPv4 control packets the mobile node sends pass through 2029 one of the new visited network's ITRs, which needs a EID-RLOC 2030 mapping for the home agent. 2032 o The home agent might not have the EID-RLOC mappings for the mobile 2033 node's "care-of" address or its foreign agent in the new visited 2034 network, in which case it will need to acquire them. 2036 o When packets are sent directly to the correspondent node, it may 2037 be that no traffic has been sent from the new visited network to 2038 the correspondent node's network, and the new visited network's 2039 ITR will need to obtain an EID-RLOC mapping for the correspondent 2040 node's site. 2042 In addition, if the IPv4 endpoint is sending packets from the new 2043 visited network using its original EID, then LISP will need to 2044 perform a route-returnability check on the new EID-RLOC mapping for 2045 that EID. 2047 In IPv6 mobility, packets can flow directly between the mobile node 2048 and the correspondent node in either direction. The mobile node uses 2049 its "care-of" address (EID). In this case, the route-returnability 2050 check would not be needed but one more LISP mapping lookup may be 2051 required instead: 2053 o As above, three mapping changes may be needed for the mobile node 2054 to communicate with its home agent and to send packets to the 2055 correspondent node. 2057 o In addition, another mapping will be needed in the correspondent 2058 node's ITR, in order for the correspondent node to send packets to 2059 the mobile node's "care-of" address (EID) at the new network 2060 location. 2062 When both endpoints are mobile the number of potential mapping 2063 lookups increases accordingly. 2065 As a mobile node moves there are not only mobility state changes in 2066 the mobile node, correspondent node, and home agent, but also state 2067 changes in the ITRs and ETRs for at least some EID-prefixes. 2069 The goal is to support rapid adaptation, with little delay or packet 2070 loss for the entire system. Heuristics can be added to LISP to 2071 reduce the number of mapping changes required and to reduce the delay 2072 per mapping change. Also IP mobility can be modified to require 2073 fewer mapping changes. In order to increase overall system 2074 performance, there may be a need to reduce the optimization of one 2075 area in order to place fewer demands on another. 2077 In LISP, one possibility is to "glean" information. When a packet 2078 arrives, the ETR could examine the EID-RLOC mapping and use that 2079 mapping for all outgoing traffic to that EID. It can do this after 2080 performing a route-returnability check, to ensure that the new 2081 network location does have a internal route to that endpoint. 2082 However, this does not cover the case where an ITR (the node assigned 2083 the RLOC) at the mobile-node location has been compromised. 2085 Mobile IP packet exchange is designed for an environment in which all 2086 routing information is disseminated before packets can be forwarded. 2087 In order to allow the Internet to grow to support expected future 2088 use, we are moving to an environment where some information may have 2089 to be obtained after packets are in flight. Modifications to IP 2090 mobility should be considered in order to optimize the behavior of 2091 the overall system. Anything which decreases the number of new EID- 2092 RLOC mappings needed when a node moves, or maintains the validity of 2093 an EID-RLOC mapping for a longer time, is useful. 2095 10.4. Fast Network Mobility 2097 In addition to endpoints, a network can be mobile, possibly changing 2098 xTRs. A "network" can be as small as a single router and as large as 2099 a whole site. This is different from site mobility in that it is 2100 fast and possibly short-lived, but different from endpoint mobility 2101 in that a whole prefix is changing RLOCs. However, the mechanisms 2102 are the same and there is no new overhead in LISP. A map request for 2103 any endpoint will return a binding for the entire mobile prefix. 2105 If mobile networks become a more common occurrence, it may be useful 2106 to revisit the design of the mapping service and allow for dynamic 2107 updates of the database. 2109 The issue of interactions between mobility and LISP needs to be 2110 explored further. Specific improvements to the entire system will 2111 depend on the details of mapping mechanisms. Mapping mechanisms 2112 should be evaluated on how well they support session continuity for 2113 mobile nodes. 2115 10.5. LISP Mobile Node Mobility 2117 An mobile device can use the LISP infrastructure to achieve mobility 2118 by implementing the LISP encapsulation and decapsulation functions 2119 and acting as a simple ITR/ETR. By doing this, such a "LISP mobile 2120 node" can use topologically-independent EID IP addresses that are not 2121 advertised into and do not impose a cost on the global routing 2122 system. These EIDs are maintained at the edges of the mapping system 2123 (in LISP Map-Servers and Map-Resolvers) and are provided on demand to 2124 only the correspondents of the LISP mobile node. 2126 Refer to the LISP Mobility Architecture specification [LISP-MN] for 2127 more details. 2129 11. Multicast Considerations 2131 A multicast group address, as defined in the original Internet 2132 architecture is an identifier of a grouping of topologically 2133 independent receiver host locations. The address encoding itself 2134 does not determine the location of the receiver(s). The multicast 2135 routing protocol, and the network-based state the protocol creates, 2136 determines where the receivers are located. 2138 In the context of LISP, a multicast group address is both an EID and 2139 a Routing Locator. Therefore, no specific semantic or action needs 2140 to be taken for a destination address, as it would appear in an IP 2141 header. Therefore, a group address that appears in an inner IP 2142 header built by a source host will be used as the destination EID. 2143 The outer IP header (the destination Routing Locator address), 2144 prepended by a LISP router, will use the same group address as the 2145 destination Routing Locator. 2147 Having said that, only the source EID and source Routing Locator 2148 needs to be dealt with. Therefore, an ITR merely needs to put its 2149 own IP address in the source Routing Locator field when prepending 2150 the outer IP header. This source Routing Locator address, like any 2151 other Routing Locator address MUST be globally routable. 2153 Therefore, an EID-to-RLOC mapping does not need to be performed by an 2154 ITR when a received data packet is a multicast data packet or when 2155 processing a source-specific Join (either by IGMPv3 or PIM). But the 2156 source Routing Locator is decided by the multicast routing protocol 2157 in a receiver site. That is, an EID to Routing Locator translation 2158 is done at control-time. 2160 Another approach is to have the ITR not encapsulate a multicast 2161 packet and allow the the host built packet to flow into the core even 2162 if the source address is allocated out of the EID namespace. If the 2163 RPF-Vector TLV [RPFV] is used by PIM in the core, then core routers 2164 can RPF to the ITR (the Locator address which is injected into core 2165 routing) rather than the host source address (the EID address which 2166 is not injected into core routing). 2168 To avoid any EID-based multicast state in the network core, the first 2169 approach is chosen for LISP-Multicast. Details for LISP-Multicast 2170 and Interworking with non-LISP sites is described in specification 2171 [MLISP]. 2173 12. Security Considerations 2175 It is believed that most of the security mechanisms will be part of 2176 the mapping database service when using control plane procedures for 2177 obtaining EID-to-RLOC mappings. For data plane triggered mappings, 2178 as described in this specification, protection is provided against 2179 ETR spoofing by using Return- Routability mechanisms evidenced by the 2180 use of a 4-byte Nonce field in the LISP encapsulation header. The 2181 nonce, coupled with the ITR accepting only solicited Map-Replies goes 2182 a long way toward providing decent authentication. 2184 LISP does not rely on a PKI infrastructure or a more heavy weight 2185 authentication system. These systems challenge the scalability of 2186 LISP which was a primary design goal. 2188 DoS attack prevention will depend on implementations rate-limiting 2189 Map-Requests and Map-Replies to the control plane as well as rate- 2190 limiting the number of data-triggered Map-Replies. 2192 To deal with map-cache exhaustion attempts in an ITR/PTR, the 2193 implementation should consider putting a maximum cap on the number of 2194 entries stored with a reserve list for special or frequently accessed 2195 sites. This should be a configuration policy control set by the 2196 network administrator who manages ITRs and PTRs. 2198 13. Prototype Plans and Status 2200 The operator community has requested that the IETF take a practical 2201 approach to solving the scaling problems associated with global 2202 routing state growth. This document offers a simple solution which 2203 is intended for use in a pilot program to gain experience in working 2204 on this problem. 2206 The authors hope that publishing this specification will allow the 2207 rapid implementation of multiple vendor prototypes and deployment on 2208 a small scale. Doing this will help the community: 2210 o Decide whether a new EID-to-RLOC mapping database infrastructure 2211 is needed or if a simple, UDP-based, data-triggered approach is 2212 flexible and robust enough. 2214 o Experiment with provider-independent assignment of EIDs while at 2215 the same time decreasing the size of DFZ routing tables through 2216 the use of topologically-aligned, provider-based RLOCs. 2218 o Determine whether multiple levels of tunneling can be used by ISPs 2219 to achieve their Traffic Engineering goals while simultaneously 2220 removing the more specific routes currently injected into the 2221 global routing system for this purpose. 2223 o Experiment with mobility to determine if both acceptable 2224 convergence and session continuity properties can be scalably 2225 implemented to support both individual device roaming and site 2226 service provider changes. 2228 Here is a rough set of milestones: 2230 1. This draft will be the draft for interoperable implementations to 2231 code against. Interoperable implementations will be ready 2232 beginning of 2009. 2234 2. Continue pilot deployment using LISP-ALT as the database mapping 2235 mechanism. 2237 3. Continue prototyping and studying other database lookup schemes, 2238 be it DNS, DHTs, CONS, ALT, NERD, or other mechanisms. 2240 4. Implement the LISP Multicast draft [MLISP]. 2242 5. Implement the LISP Mobile Node draft [LISP-MN]. 2244 6. Research more on how policy affects what gets returned in a Map- 2245 Reply from an ETR. 2247 7. Continue to experiment with mixed locator-sets to understand how 2248 LISP can help the IPv4 to IPv6 transition. 2250 8. Add more robustness to locator reachability between LISP sites. 2252 As of this writing the following accomplishments have been achieved: 2254 1. A unit- and system-tested software switching implementation has 2255 been completed on cisco NX-OS for this draft for both IPv4 and 2256 IPv6 EIDs using a mixed locator-set of IPv4 and IPv6 locators. 2258 2. A unit- and system-tested software switching implementation on 2259 cisco NX-OS has been completed for draft [ALT]. 2261 3. A unit- and system-tested software switching implementation on 2262 cisco NX-OS has been completed for draft [INTERWORK]. Support 2263 for IPv4 translation is provided and PTR support for IPv4 and 2264 IPv6 is provided. 2266 4. The cisco NX-OS implementation supports an experimental 2267 mechanism for slow mobility. 2269 5. Dave Meyer, Vince Fuller, Darrel Lewis, Greg Shepherd, and 2270 Andrew Partan continue to test all the features described above 2271 on a dual-stack infrastructure. 2273 6. Darrel Lewis and Dave Meyer have deployed both LISP translation 2274 and LISP PTR support in the pilot network. Point your browser 2275 to http://www.lisp4.net to see translation happening in action 2276 so your non-LISP site can access a web server in a LISP site. 2278 7. Soon http://www.lisp6.net will work where your IPv6 LISP site 2279 can talk to a IPv6 web server in a LISP site by using mixed 2280 address-family based locators. 2282 8. An public domain implementation of LISP is underway. See 2283 [OPENLISP] for details. 2285 9. We have deployed Map-Resolvers and Map-Servers on the LISP pilot 2286 network to gather experience with [LISP-MS]. The first layer of 2287 the architecture are the xTRs which use Map-Servers for EID- 2288 prefix registration and Map-Resolvers for EID-to-RLOC mapping 2289 resolution. The second layer are the Map-Resolvers and Map- 2290 Servers which connect to the ALT BGP peering infrastructure. 2291 And the third layer are ALT-routers which aggregate EID-prefixes 2292 and forward Map-Requests. 2294 10. A cisco IOS implementation is underway which currently supports 2295 IPv4 encapsulation and decapsulation features. 2297 11. A LISP router based LIG implementation is supported, deployed, 2298 and used daily to debug and test the LISP pilot network. See 2299 [LIG] for details. 2301 12. A Linux implementation of LIG has been made available and 2302 supported by Dave Meyer. It can be run on any Linux system 2303 which resides in either a LISP site or non-LISP site. See [LIG] 2304 for details. Public domain code can be downloaded from 2305 http://github.com/davidmeyer/lig/tree/master. 2307 13. An experimental implementation has been written for three 2308 locator reachability algorithms. One is called echo-noncing, 2309 which is documented in this specification. The other two are 2310 called TCP-counts and RLOC-probing, which will be documented in 2311 future drafts. 2313 If interested in writing a LISP implementation, testing any of the 2314 LISP implementations, or want to be part of the LISP pilot program, 2315 please contact lisp@ietf.org. 2317 14. References 2319 14.1. Normative References 2321 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2322 August 1980. 2324 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 2325 November 1990. 2327 [RFC1498] Saltzer, J., "On the Naming and Binding of Network 2328 Destinations", RFC 1498, August 1993. 2330 [RFC1955] Hinden, R., "New Scheme for Internet Routing and 2331 Addressing (ENCAPS) for IPNG", RFC 1955, June 1996. 2333 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2334 Requirement Levels", BCP 14, RFC 2119, March 1997. 2336 [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", 2337 RFC 2402, November 1998. 2339 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2340 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 2341 October 1998. 2343 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 2344 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 2345 March 2000. 2347 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 2348 via IPv4 Clouds", RFC 3056, February 2001. 2350 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 2351 of Explicit Congestion Notification (ECN) to IP", 2352 RFC 3168, September 2001. 2354 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 2355 in IPv6", RFC 3775, June 2004. 2357 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 2358 (HIP) Architecture", RFC 4423, May 2006. 2360 [RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route 2361 Optimization for Mobile IPv6", RFC 4866, May 2007. 2363 [RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB 2364 Workshop on Routing and Addressing", RFC 4984, 2365 September 2007. 2367 14.2. Informative References 2369 [AFI] IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY 2370 NUMBERS http://www.iana.org/numbers.html, Febuary 2007. 2372 [ALT] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP 2373 Alternative Topology (LISP-ALT)", 2374 draft-ietf-lisp-alt-01.txt (work in progress), May 2009. 2376 [APT] Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and 2377 L. Zhang, "APT: A Practical Transit Mapping Service", 2378 draft-jen-apt-01.txt (work in progress), November 2007. 2380 [CHIAPPA] Chiappa, J., "Endpoints and Endpoint names: A Proposed 2381 Enhancement to the Internet Architecture", Internet- 2382 Draft http://www.chiappa.net/~jnc/tech/endpoints.txt, 2383 1999. 2385 [CONS] Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A 2386 Content distribution Overlay Network Service for LISP", 2387 draft-meyer-lisp-cons-03.txt (work in progress), 2388 November 2007. 2390 [DHTs] Ratnasamy, S., Shenker, S., and I. Stoica, "Routing 2391 Algorithms for DHTs: Some Open Questions", PDF 2392 file http://www.cs.rice.edu/Conferences/IPTPS02/174.pdf. 2394 [EMACS] Brim, S., Farinacci, D., Meyer, D., and J. Curran, "EID 2395 Mappings Multicast Across Cooperating Systems for LISP", 2396 draft-curran-lisp-emacs-00.txt (work in progress), 2397 November 2007. 2399 [GSE] "GSE - An Alternate Addressing Architecture for IPv6", 2400 draft-ietf-ipngwg-gseaddr-00.txt (work in progress), 1997. 2402 [INTERWORK] 2403 Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 2404 "Interworking LISP with IPv4 and IPv6", 2405 draft-ietf-lisp-interworking-00.txt (work in progress), 2406 January 2009. 2408 [LIG] Farinacci, D. and D. Meyer, "LISP Internet Groper (LIG)", 2409 draft-farinacci-lisp-lig-01.txt (work in progress), 2410 May 2009. 2412 [LISA96] Lear, E., Katinsky, J., Coffin, J., and D. Tharp, 2413 "Renumbering: Threat or Menace?", Usenix , September 1996. 2415 [LISP-MAIN] 2416 Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 2417 "Locator/ID Separation Protocol (LISP)", 2418 draft-farinacci-lisp-12.txt (work in progress), 2419 March 2009. 2421 [LISP-MN] Farinacci, D., Fuller, V., Lewis, D., and D. Meyer, "LISP 2422 Mobility Architecture", draft-meyer-lisp-mn-00.txt (work 2423 in progress), July 2009. 2425 [LISP-MS] Farinacci, D. and V. Fuller, "LISP Map Server", 2426 draft-ietf-lisp-ms-01.txt (work in progress), May 2009. 2428 [LISP1] Farinacci, D., Oran, D., Fuller, V., and J. Schiller, 2429 "Locator/ID Separation Protocol (LISP1) [Routable ID 2430 Version]", 2431 Slide-set http://www.dinof.net/~dino/ietf/lisp1.ppt, 2432 October 2006. 2434 [LISP2] Farinacci, D., Oran, D., Fuller, V., and J. Schiller, 2435 "Locator/ID Separation Protocol (LISP2) [DNS-based 2436 Version]", 2437 Slide-set http://www.dinof.net/~dino/ietf/lisp2.ppt, 2438 November 2006. 2440 [LISPDHT] Mathy, L., Iannone, L., and O. Bonaventure, "LISP-DHT: 2441 Towards a DHT to map identifiers onto locators", 2442 draft-mathy-lisp-dht-00.txt (work in progress), 2443 February 2008. 2445 [LOC-ID-ARCH] 2446 Meyer, D. and D. Lewis, "Architectural Implications of 2447 Locator/ID Separation", 2448 draft-meyer-loc-id-implications-01.txt (work in progress), 2449 Januaryr 2009. 2451 [MLISP] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, 2452 "LISP for Multicast Environments", 2453 draft-ietf-lisp-multicast-01.txt (work in progress), 2454 May 2009. 2456 [NERD] Lear, E., "NERD: A Not-so-novel EID to RLOC Database", 2457 draft-lear-lisp-nerd-04.txt (work in progress), 2458 April 2008. 2460 [OPENLISP] 2461 Iannone, L. and O. Bonaventure, "OpenLISP Implementation 2462 Report", draft-iannone-openlisp-implementation-01.txt 2463 (work in progress), July 2008. 2465 [RADIR] Narten, T., "Routing and Addressing Problem Statement", 2466 draft-narten-radir-problem-statement-00.txt (work in 2467 progress), July 2007. 2469 [RFC3344bis] 2470 Perkins, C., "IP Mobility Support for IPv4, revised", 2471 draft-ietf-mip4-rfc3344bis-05 (work in progress), 2472 July 2007. 2474 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 2475 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 2476 September 2005. 2478 [RPFV] Wijnands, IJ., Boers, A., and E. Rosen, "The RPF Vector 2479 TLV", draft-ietf-pim-rpf-vector-08.txt (work in progress), 2480 January 2009. 2482 [RPMD] Handley, M., Huici, F., and A. Greenhalgh, "RPMD: Protocol 2483 for Routing Protocol Meta-data Dissemination", 2484 draft-handley-p2ppush-unpublished-2007726.txt (work in 2485 progress), July 2007. 2487 [SHIM6] Nordmark, E. and M. Bagnulo, "Level 3 multihoming shim 2488 protocol", draft-ietf-shim6-proto-06.txt (work in 2489 progress), October 2006. 2491 Appendix A. Acknowledgments 2493 An initial thank you goes to Dave Oran for planting the seeds for the 2494 initial ideas for LISP. His consultation continues to provide value 2495 to the LISP authors. 2497 A special and appreciative thank you goes to Noel Chiappa for 2498 providing architectural impetus over the past decades on separation 2499 of location and identity, as well as detailed review of the LISP 2500 architecture and documents, coupled with enthusiasm for making LISP a 2501 practical and incremental transition for the Internet. 2503 The authors would like to gratefully acknowledge many people who have 2504 contributed discussion and ideas to the making of this proposal. 2505 They include Scott Brim, Andrew Partan, John Zwiebel, Jason Schiller, 2506 Lixia Zhang, Dorian Kim, Peter Schoenmaker, Vijay Gill, Geoff Huston, 2507 David Conrad, Mark Handley, Ron Bonica, Ted Seely, Mark Townsley, 2508 Chris Morrow, Brian Weis, Dave McGrew, Peter Lothberg, Dave Thaler, 2509 Eliot Lear, Shane Amante, Ved Kafle, Olivier Bonaventure, Luigi 2510 Iannone, Robin Whittle, Brian Carpenter, Joel Halpern, Roger 2511 Jorgensen, Ran Atkinson, Stig Venaas, Iljitsch van Beijnum, Roland 2512 Bless, Dana Blair, Bill Lynch, Marc Woolward, Damien Saucez, Damian 2513 Lezama, Attilla De Groot, Parantap Lahiri, David Black, Roque 2514 Gagliano, and Isidor Kouvelas. 2516 In particular, we would like to thank Dave Meyer for his clever 2517 suggestion for the name "LISP". ;-) 2519 This work originated in the Routing Research Group (RRG) of the IRTF. 2520 The individual submission [LISP-MAIN] was converted into this IETF 2521 LISP working group draft. 2523 Authors' Addresses 2525 Dino Farinacci 2526 cisco Systems 2527 Tasman Drive 2528 San Jose, CA 95134 2529 USA 2531 Email: dino@cisco.com 2533 Vince Fuller 2534 cisco Systems 2535 Tasman Drive 2536 San Jose, CA 95134 2537 USA 2539 Email: vaf@cisco.com 2541 Dave Meyer 2542 cisco Systems 2543 170 Tasman Drive 2544 San Jose, CA 2545 USA 2547 Email: dmm@cisco.com 2549 Darrel Lewis 2550 cisco Systems 2551 170 Tasman Drive 2552 San Jose, CA 2553 USA 2555 Email: darlewis@cisco.com