idnits 2.17.1 draft-ietf-lisp-01.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 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 (May 28, 2009) is 5447 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-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 (~~), 13 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: November 29, 2009 D. Lewis 6 cisco Systems 7 May 28, 2009 9 Locator/ID Separation Protocol (LISP) 10 draft-ietf-lisp-01.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 November 29, 2009. 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 . . . . . . . . . 20 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 . . . . . . . . . . . . . . . . . . . . . 23 74 6.1. LISP IPv4 and IPv6 Control Plane Packet Formats . . . . . 23 75 6.1.1. LISP Packet Type Allocations . . . . . . . . . . . . . 25 76 6.1.2. Map-Request Message Format . . . . . . . . . . . . . . 25 77 6.1.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . 27 78 6.1.4. Map-Reply Message Format . . . . . . . . . . . . . . . 28 79 6.1.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . 31 80 6.1.6. Map-Register Message Format . . . . . . . . . . . . . 32 81 6.2. Routing Locator Selection . . . . . . . . . . . . . . . . 34 82 6.3. Routing Locator Reachability . . . . . . . . . . . . . . . 35 83 6.4. Routing Locator Hashing . . . . . . . . . . . . . . . . . 37 84 6.5. Changing the Contents of EID-to-RLOC Mappings . . . . . . 38 85 6.5.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . 39 86 6.5.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . 39 87 7. Router Performance Considerations . . . . . . . . . . . . . . 41 88 8. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 42 89 8.1. First-hop/Last-hop Tunnel Routers . . . . . . . . . . . . 43 90 8.2. Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 43 91 8.3. ISP Provider-Edge (PE) Tunnel Routers . . . . . . . . . . 44 92 9. Traceroute Considerations . . . . . . . . . . . . . . . . . . 45 93 9.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . . 46 94 9.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . . 46 95 9.3. Traceroute using Mixed Locators . . . . . . . . . . . . . 46 96 10. Mobility Considerations . . . . . . . . . . . . . . . . . . . 48 97 10.1. Site Mobility . . . . . . . . . . . . . . . . . . . . . . 48 98 10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 48 99 10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 48 100 10.4. Fast Network Mobility . . . . . . . . . . . . . . . . . . 50 101 11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 51 102 12. Security Considerations . . . . . . . . . . . . . . . . . . . 52 103 13. Prototype Plans and Status . . . . . . . . . . . . . . . . . . 53 104 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 56 105 14.1. Normative References . . . . . . . . . . . . . . . . . . . 56 106 14.2. Informative References . . . . . . . . . . . . . . . . . . 57 107 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 60 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 61 110 1. Requirements Notation 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 2. Introduction 118 Many years of discussion about the current IP routing and addressing 119 architecture have noted that its use of a single numbering space (the 120 "IP address") for both host transport session identification and 121 network routing creates scaling issues (see [CHIAPPA] and [RFC1498]). 122 A number of scaling benefits would be realized by separating the 123 current IP address into separate spaces for Endpoint Identifiers 124 (EIDs) and Routing Locators (RLOCs); among them are: 126 1. Reduction of routing table size in the "default-free zone" (DFZ). 127 Use of a separate numbering space for RLOCs will allow them to be 128 assigned topologically (in today's Internet, RLOCs would be 129 assigned by providers at client network attachment points), 130 greatly improving aggregation and reducing the number of 131 globally-visible, routable prefixes. 133 2. More cost-effective multihoming for sites that connect to 134 different service providers where they can control their own 135 policies for packet flow into the site without using extra 136 routing table resources of core routers. 138 3. Easing of renumbering burden when clients change providers. 139 Because host EIDs are numbered from a separate, non-provider- 140 assigned and non-topologically-bound space, they do not need to 141 be renumbered when a client site changes its attachment points to 142 the network. 144 4. Traffic engineering capabilities that can be performed by network 145 elements and do not depend on injecting additional state into the 146 routing system. This will fall out of the mechanism that is used 147 to implement the EID/RLOC split (see Section 4). 149 5. Mobility without address changing. Existing mobility mechanisms 150 will be able to work in a locator/ID separation scenario. It 151 will be possible for a host (or a collection of hosts) to move to 152 a different point in the network topology either retaining its 153 home-based address or acquiring a new address based on the new 154 network location. A new network location could be a physically 155 different point in the network topology or the same physical 156 point of the topology with a different provider. 158 This draft describes protocol mechanisms to achieve the desired 159 functional separation. For flexibility, the mechanism used for 160 forwarding packets is decoupled from that used to determine EID to 161 RLOC mappings. This document covers the former. For the later, see 162 [CONS], [ALT], [RPMD], and [NERD]. This work is in response to and 163 intended to address the problem statement that came out of the RAWS 164 effort [RFC4984]. 166 The Routing and Addressing problem statement can be found in [RADIR]. 168 This draft focuses on a router-based solution. Building the solution 169 into the network will facilitate incremental deployment of the 170 technology on the Internet. Note that while the detailed protocol 171 specification and examples in this document assume IP version 4 172 (IPv4), there is nothing in the design that precludes use of the same 173 techniques and mechanisms for IPv6. It should be possible for IPv4 174 packets to use IPv6 RLOCs and for IPv6 EIDs to be mapped to IPv4 175 RLOCs. 177 Related work on host-based solutions is described in Shim6 [SHIM6] 178 and HIP [RFC4423]. Related work on a router-based solution is 179 described in [GSE]. This draft attempts to not compete or overlap 180 with such solutions and the proposed protocol changes are expected to 181 complement a host-based mechanism when Traffic Engineering 182 functionality is desired. 184 Some of the design goals of this proposal include: 186 1. Require no hardware or software changes to end-systems (hosts). 188 2. Minimize required changes to Internet infrastructure. 190 3. Be incrementally deployable. 192 4. Require no router hardware changes. 194 5. Minimize the number of routers which have to be modified. In 195 particular, most customer site routers and no core routers 196 require changes. 198 6. Minimize router software changes in those routers which are 199 affected. 201 7. Avoid or minimize packet loss when EID-to-RLOC mappings need to 202 be performed. 204 There are 4 variants of LISP, which differ along a spectrum of strong 205 to weak dependence on the topological nature and possible need for 206 routability of EIDs. The variants are: 208 LISP 1: uses EIDs that are routable through the RLOC topology for 209 bootstrapping EID-to-RLOC mappings. [LISP1] This was intended as 210 a prototyping mechanism for early protocol implementation. It is 211 now deprecated and should not be deployed. 213 LISP 1.5: uses EIDs that are routable for bootstrapping EID-to-RLOC 214 mappings; such routing is via a separate topology. 216 LISP 2: uses EIDS that are not routable and EID-to-RLOC mappings are 217 implemented within the DNS. [LISP2] 219 LISP 3: uses non-routable EIDs that are used as lookup keys for a 220 new EID-to-RLOC mapping database. Use of Distributed Hash Tables 221 [DHTs] [LISPDHT] to implement such a database would be an area to 222 explore. Other examples of new mapping database services are 223 [CONS], [ALT], [RPMD], [NERD], and [APT]. 225 This document on LISP 1.5, and LISP 3 variants, both of which rely on 226 a router-based distributed cache and database for EID-to-RLOC 227 mappings. The LISP 1.0 mechanism works but does not allow reduction 228 of routing information in the default-free-zone of the Internet. The 229 LISP 2 mechanisms are put on hold and may never come to fruition 230 since it is not architecturally pure to have routing depend on 231 directory and directory depend on routing. The LISP 3 mechanisms 232 will be documented elsewhere but may use the control-plane options 233 specified in this specification. 235 3. Definition of Terms 237 Provider Independent (PI) Addresses: an address block assigned from 238 a pool where blocks are not associated with any particular 239 location in the network (e.g. from a particular service provider), 240 and is therefore not topologically aggregatable in the routing 241 system. 243 Provider Assigned (PA) Addresses: a block of IP addresses that are 244 assigned to a site by each service provider to which a site 245 connects. Typically, each block is sub-block of a service 246 provider CIDR block and is aggregated into the larger block before 247 being advertised into the global Internet. Traditionally, IP 248 multihoming has been implemented by each multi-homed site 249 acquiring its own, globally-visible prefix. LISP uses only 250 topologically-assigned and aggregatable address blocks for RLOCs, 251 eliminating this demonstrably non-scalable practice. 253 Routing Locator (RLOC): the IPv4 or IPv6 address of an egress 254 tunnel router (ETR). It is the output of a EID-to-RLOC mapping 255 lookup. An EID maps to one or more RLOCs. Typically, RLOCs are 256 numbered from topologically-aggregatable blocks that are assigned 257 to a site at each point to which it attaches to the global 258 Internet; where the topology is defined by the connectivity of 259 provider networks, RLOCs can be thought of as PA addresses. 260 Multiple RLOCs can be assigned to the same ETR device or to 261 multiple ETR devices at a site. 263 Endpoint ID (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) value 264 used in the source and destination address fields of the first 265 (most inner) LISP header of a packet. The host obtains a 266 destination EID the same way it obtains an destination address 267 today, for example through a DNS lookup or SIP exchange. The 268 source EID is obtained via existing mechanisms used to set a 269 host's "local" IP address. An EID is allocated to a host from an 270 EID-prefix block associated with the site where the host is 271 located. An EID can be used by a host to refer to other hosts. 272 EIDs MUST NOT be used as LISP RLOCs. Note that EID blocks may be 273 assigned in a hierarchical manner, independent of the network 274 topology, to facilitate scaling of the mapping database. In 275 addition, an EID block assigned to a site may have site-local 276 structure (subnetting) for routing within the site; this structure 277 is not visible to the global routing system. When used in 278 discussions with other Locator/ID separation proposals, a LISP EID 279 will be called a "LEID". Throughout this document, any references 280 to "EID" refers to an LEID. 282 EID-prefix: A power-of-2 block of EIDs which are allocated to a 283 site by an address allocation authority. EID-prefixes are 284 associated with a set of RLOC addresses which make up a "database 285 mapping". EID-prefix allocations can be broken up into smaller 286 blocks when an RLOC set is to be associated with the smaller EID- 287 prefix. A globally routed address block (whether PI or PA) is not 288 an EID-prefix. However, a globally routed address block may be 289 removed from global routing and reused as an EID-prefix. A site 290 that receives an explicitly allocated EID-prefix may not use that 291 EID-prefix as a globally routed prefix assigned to RLOCs. 293 End-system: is an IPv4 or IPv6 device that originates packets with 294 a single IPv4 or IPv6 header. The end-system supplies an EID 295 value for the destination address field of the IP header when 296 communicating globally (i.e. outside of its routing domain). An 297 end-system can be a host computer, a switch or router device, or 298 any network appliance. 300 Ingress Tunnel Router (ITR): a router which accepts an IP packet 301 with a single IP header (more precisely, an IP packet that does 302 not contain a LISP header). The router treats this "inner" IP 303 destination address as an EID and performs an EID-to-RLOC mapping 304 lookup. The router then prepends an "outer" IP header with one of 305 its globally-routable RLOCs in the source address field and the 306 result of the mapping lookup in the destination address field. 307 Note that this destination RLOC may be an intermediate, proxy 308 device that has better knowledge of the EID-to-RLOC mapping closer 309 to the destination EID. In general, an ITR receives IP packets 310 from site end-systems on one side and sends LISP-encapsulated IP 311 packets toward the Internet on the other side. 313 Specifically, when a service provider prepends a LISP header for 314 Traffic Engineering purposes, the router that does this is also 315 regarded as an ITR. The outer RLOC the ISP ITR uses can be based 316 on the outer destination address (the originating ITR's supplied 317 RLOC) or the inner destination address (the originating hosts 318 supplied EID). 320 TE-ITR: is an ITR that is deployed in a service provider network 321 that prepends an additional LISP header for Traffic Engineering 322 purposes. 324 Egress Tunnel Router (ETR): a router that accepts an IP packet 325 where the destination address in the "outer" IP header is one of 326 its own RLOCs. The router strips the "outer" header and forwards 327 the packet based on the next IP header found. In general, an ETR 328 receives LISP-encapsulated IP packets from the Internet on one 329 side and sends decapsulated IP packets to site end-systems on the 330 other side. ETR functionality does not have to be limited to a 331 router device. A server host can be the endpoint of a LISP tunnel 332 as well. 334 TE-ETR: is an ETR that is deployed in a service provider network 335 that strips an outer LISP header for Traffic Engineering purposes. 337 xTR: is a reference to an ITR or ETR when direction of data flow is 338 not part of the context description. xTR refers to the router that 339 is the tunnel endpoint. Used synonymously with the term "Tunnel 340 Router". For example, "An xTR can be located at the Customer Edge 341 (CE) router", meaning both ITR and ETR functionality is at the CE 342 router. 344 EID-to-RLOC Cache: a short-lived, on-demand table in an ITR that 345 stores, tracks, and is responsible for timing-out and otherwise 346 validating EID-to-RLOC mappings. This cache is distinct from the 347 full "database" of EID-to-RLOC mappings, it is dynamic, local to 348 the ITR(s), and relatively small while the database is 349 distributed, relatively static, and much more global in scope. 351 EID-to-RLOC Database: a global distributed database that contains 352 all known EID-prefix to RLOC mappings. Each potential ETR 353 typically contains a small piece of the database: the EID-to-RLOC 354 mappings for the EID prefixes "behind" the router. These map to 355 one of the router's own, globally-visible, IP addresses. 357 Recursive Tunneling: when a packet has more than one LISP IP 358 header. Additional layers of tunneling may be employed to 359 implement traffic engineering or other re-routing as needed. When 360 this is done, an additional "outer" LISP header is added and the 361 original RLOCs are preserved in the "inner" header. Any 362 references to tunnels in this specification refers to dynamic 363 encapsulating tunnels and never are they staticly configured. 365 Reencapsulating Tunnels: when a packet has no more than one LISP IP 366 header (two IP headers total) and when it needs to be diverted to 367 new RLOC, an ETR can decapsulate the packet (remove the LISP 368 header) and prepend a new tunnel header, with new RLOC, on to the 369 packet. Doing this allows a packet to be re-routed by the re- 370 encapsulating router without adding the overhead of additional 371 tunnel headers. Any references to tunnels in this specification 372 refers to dynamic encapsulating tunnels and never are they 373 staticly configured. 375 LISP Header: a term used in this document to refer to the outer 376 IPv4 or IPv6 header, a UDP header, and a LISP header, an ITR 377 prepends or an ETR strips. 379 Address Family Indicator (AFI): a term used to describe an address 380 encoding in a packet. An address family currently pertains to an 381 IPv4 or IPv6 address. See [AFI] for details. 383 Negative Mapping Entry: also known as a negative cache entry, is an 384 EID-to-RLOC entry where an EID-prefix is advertised or stored with 385 no RLOCs. That is, the locator-set for the EID-to-RLOC entry is 386 empty or has an encoded locator count of 0. This type of entry 387 could be used to describe a prefix from a non-LISP site, which is 388 explicitly not in the mapping database. There are a set of well 389 defined actions that are encoded in a Negative Map-Reply. 391 Data Probe: a LISP-encapsulated data packet where the inner header 392 destination address equals the outer header destination address 393 used to trigger a Map-Reply by a decapsulating ETR. In addition, 394 the original packet is decapsulated and delivered to the 395 destination host. A Data Probe is used in some of the mapping 396 database designs to "probe" or request a Map-Reply from an ETR; in 397 other cases, Map-Requests are used. See each mapping database 398 design for details. 400 4. Basic Overview 402 One key concept of LISP is that end-systems (hosts) operate the same 403 way they do today. The IP addresses that hosts use for tracking 404 sockets, connections, and for sending and receiving packets do not 405 change. In LISP terminology, these IP addresses are called Endpoint 406 Identifiers (EIDs). 408 Routers continue to forward packets based on IP destination 409 addresses. When a packet is LISP encapsulated, these addresses are 410 referred to as Routing Locators (RLOCs). Most routers along a path 411 between two hosts will not change; they continue to perform routing/ 412 forwarding lookups on the destination addresses. For routers between 413 the source host and the ITR as well as routers from the ETR to the 414 destination host, the destination address is an EID. For the routers 415 between the ITR and the ETR, the destination address is an RLOC. 417 This design introduces "Tunnel Routers", which prepend LISP headers 418 on host-originated packets and strip them prior to final delivery to 419 their destination. The IP addresses in this "outer header" are 420 RLOCs. During end-to-end packet exchange between two Internet hosts, 421 an ITR prepends a new LISP header to each packet and an egress tunnel 422 router strips the new header. The ITR performs EID-to-RLOC lookups 423 to determine the routing path to the the ETR, which has the RLOC as 424 one of its IP addresses. 426 Some basic rules governing LISP are: 428 o End-systems (hosts) only send to addresses which are EIDs. They 429 don't know addresses are EIDs versus RLOCs but assume packets get 430 to LISP routers, which in turn, deliver packets to the destination 431 the end-system has specified. 433 o EIDs are always IP addresses assigned to hosts. 435 o LISP routers mostly deal with Routing Locator addresses. See 436 details later in Section 4.1 to clarify what is meant by "mostly". 438 o RLOCs are always IP addresses assigned to routers; preferably, 439 topologically-oriented addresses from provider CIDR blocks. 441 o When a router originates packets it may use as a source address 442 either an EID or RLOC. When acting as a host (e.g. when 443 terminating a transport session such as SSH, TELNET, or SNMP), it 444 may use an EID that is explicitly assigned for that purpose. An 445 EID that identifies the router as a host MUST NOT be used as an 446 RLOC; an EID is only routable within the scope of a site. A 447 typical BGP configuration might demonstrate this "hybrid" EID/RLOC 448 usage where a router could use its "host-like" EID to terminate 449 iBGP sessions to other routers in a site while at the same time 450 using RLOCs to terminate eBGP sessions to routers outside the 451 site. 453 o EIDs are not expected to be usable for global end-to-end 454 communication in the absence of an EID-to-RLOC mapping operation. 455 They are expected to be used locally for intra-site communication. 457 o EID prefixes are likely to be hierarchically assigned in a manner 458 which is optimized for administrative convenience and to 459 facilitate scaling of the EID-to-RLOC mapping database. The 460 hierarchy is based on a address allocation hierarchy which is not 461 dependent on the network topology. 463 o EIDs may also be structured (subnetted) in a manner suitable for 464 local routing within an autonomous system. 466 An additional LISP header may be prepended to packets by a transit 467 router (i.e. TE-ITR) when re-routing of the path for a packet is 468 desired. An obvious instance of this would be an ISP router that 469 needs to perform traffic engineering for packets in flow through its 470 network. In such a situation, termed Recursive Tunneling, an ISP 471 transit acts as an additional ingress tunnel router and the RLOC it 472 uses for the new prepended header would be either an TE-ETR within 473 the ISP (along intra-ISP traffic engineered path) or in an TE-ETR 474 within another ISP (an inter-ISP traffic engineered path, where an 475 agreement to build such a path exists). 477 This specification mandates that no more than two LISP headers get 478 prepended to a packet. This avoids excessive packet overhead as well 479 as possible encapsulation loops. It is believed two headers is 480 sufficient, where the first prepended header is used at a site for 481 Location/Identity separation and second prepended header is used 482 inside a service provider for Traffic Engineering purposes. 484 Tunnel Routers can be placed fairly flexibly in a multi-AS topology. 485 For example, the ITR for a particular end-to-end packet exchange 486 might be the first-hop or default router within a site for the source 487 host. Similarly, the egress tunnel router might be the last-hop 488 router directly-connected to the destination host. Another example, 489 perhaps for a VPN service out-sourced to an ISP by a site, the ITR 490 could be the site's border router at the service provider attachment 491 point. Mixing and matching of site-operated, ISP-operated, and other 492 tunnel routers is allowed for maximum flexibility. See Section 8 for 493 more details. 495 4.1. Packet Flow Sequence 497 This section provides an example of the unicast packet flow with the 498 following conditions: 500 o Source host "host1.abc.com" is sending a packet to 501 "host2.xyz.com", exactly what host1 would do if the site was not 502 using LISP. 504 o Each site is multi-homed, so each tunnel router has an address 505 (RLOC) assigned from the service provider address block for each 506 provider to which that particular tunnel router is attached. 508 o The ITR(s) and ETR(s) are directly connected to the source and 509 destination, respectively. 511 o Data Probes are used to solicit Map-Replies versus using Map- 512 Requests. And the Data Probes are sent on the underlying topology 513 (the LISP 1.0 variant) but could also be sent over an alternative 514 topology (the LISP 1.5 variant) as it would in [ALT]. 516 Client host1.abc.com wants to communicate with server host2.xyz.com: 518 1. host1.abc.com wants to open a TCP connection to host2.xyz.com. 519 It does a DNS lookup on host2.xyz.com. An A/AAAA record is 520 returned. This address is used as the destination EID and the 521 locally-assigned address of host1.abc.com is used as the source 522 EID. An IPv4 or IPv6 packet is built using the EIDs in the IPv4 523 or IPv6 header and sent to the default router. 525 2. The default router is configured as an ITR. The ITR must be able 526 to map the EID destination to an RLOC of the ETR at the 527 destination site. The ITR prepends a LISP header to the packet, 528 with one of its RLOCs as the source IPv4 or IPv6 address. The 529 destination EID from the original packet header is used as the 530 destination IPv4 or IPv6 in the prepended LISP header. 531 Subsequent packets, where the outer destination address is the 532 destination EID will be sent until EID-to-RLOC mapping is 533 learned. 535 3. In LISP 1, the packet is routed through the Internet as it is 536 today. In LISP 1.5, the packet is routed on a different topology 537 which may have EID prefixes distributed and advertised in an 538 aggregatable fashion. In either case, the packet arrives at the 539 ETR. The router is configured to "punt" the packet to the 540 router's processor. See Section 7 for more details. For LISP 541 2.0 and 3.0, the behavior is not fully defined yet. 543 4. The LISP header is stripped so that the packet can be forwarded 544 by the router control plane. The router looks up the destination 545 EID in the router's EID-to-RLOC database (not the cache, but the 546 configured data structure of RLOCs). An EID-to-RLOC Map-Reply 547 message is originated by the ETR and is addressed to the source 548 RLOC in the LISP header of the original packet (this is the ITR). 549 The source RLOC of the Map-Reply is one of the ETR's RLOCs. 551 5. The ITR receives the Map-Reply message, parses the message (to 552 check for format validity) and stores the mapping information 553 from the packet. This information is put in the ITR's EID-to- 554 RLOC mapping cache (this is the on-demand cache, the cache where 555 entries time out due to inactivity). 557 6. Subsequent packets from host1.abc.com to host2.xyz.com will have 558 a LISP header prepended by the ITR using the appropriate RLOC as 559 the LISP header destination address learned from the ETR. Note, 560 the packet may be sent to a different ETR than the one which 561 returned the Map-Reply due to the source site's hashing policy or 562 the destination site's locator-set policy. 564 7. The ETR receives these packets directly (since the destination 565 address is one of its assigned IP addresses), strips the LISP 566 header and forwards the packets to the attached destination host. 568 In order to eliminate the need for a mapping lookup in the reverse 569 direction, an ETR MAY create a cache entry that maps the source EID 570 (inner header source IP address) to the source RLOC (outer header 571 source IP address) in a received LISP packet. Such a cache entry is 572 termed a "gleaned" mapping and only contains a single RLOC for the 573 EID in question. More complete information about additional RLOCs 574 SHOULD be verified by sending a LISP Map-Request for that EID. Both 575 ITR and the ETR may also influence the decision the other makes in 576 selecting an RLOC. See Section 6 for more details. 578 5. Tunneling Details 580 This section describes the LISP Data Message which defines the 581 tunneling header used to encapsulate IPv4 and IPv6 packets which 582 contain EID addresses. Even though the following formats illustrate 583 IPv4-in-IPv4 and IPv6-in-IPv6 encapsulations, the other 2 584 combinations are supported as well. 586 Since additional tunnel headers are prepended, the packet becomes 587 larger and in theory can exceed the MTU of any link traversed from 588 the ITR to the ETR. It is recommended, in IPv4 that packets do not 589 get fragmented as they are encapsulated by the ITR. Instead, the 590 packet is dropped and an ICMP Too Big message is returned to the 591 source. 593 Based on informal surveys of large ISP traffic patterns, it appears 594 that most transit paths can accommodate a path MTU of at least 4470 595 bytes. The exceptions, in terms of data rate, number of hosts 596 affected, or any other metric are expected to be vanishingly small. 598 To address MTU concerns, mainly raised on the RRG mailing list, the 599 LISP deployment process will include collecting data during its pilot 600 phase to either verify or refute the assumption about minimum 601 available MTU. If the assumption proves true and transit networks 602 with links limited to 1500 byte MTUs are corner cases, it would seem 603 more cost-effective to either upgrade or modify the equipment in 604 those transit networks to support larger MTUs or to use existing 605 mechanisms for accommodating packets that are too large. 607 For this reason, there is currently no plan for LISP to add any new 608 additional, complex mechanism for implementing fragmentation and 609 reassembly in the face of limited-MTU transit links. If analysis 610 during LISP pilot deployment reveals that the assumption of 611 essentially ubiquitous, 4470+ byte transit path MTUs, is incorrect, 612 then LISP can be modified prior to protocol standardization to add 613 support for one of the proposed fragmentation and reassembly schemes. 614 Note that two simple existing schemes are detailed in Section 5.4. 616 5.1. LISP IPv4-in-IPv4 Header Format 618 0 1 2 3 619 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 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 / |Version| IHL |Type of Service| Total Length | 622 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | | Identification |Flags| Fragment Offset | 624 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 OH | Time to Live | Protocol = 17 | Header Checksum | 626 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | | Source Routing Locator | 628 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 \ | Destination Routing Locator | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 / | Source Port = xxxx | Dest Port = 4341 | 632 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 \ | UDP Length | UDP Checksum | 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 L / |S| Locator Reach Bits | 636 I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 S \ | Nonce | 638 P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 / |Version| IHL |Type of Service| Total Length | 640 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | | Identification |Flags| Fragment Offset | 642 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 IH | Time to Live | Protocol | Header Checksum | 644 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | | Source EID | 646 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 \ | Destination EID | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 5.2. LISP IPv6-in-IPv6 Header Format 652 0 1 2 3 653 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 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 / |Version| Traffic Class | Flow Label | 656 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | | Payload Length | Next Header=17| Hop Limit | 658 v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | | 660 O + + 661 u | | 662 t + Source Routing Locator + 663 e | | 664 r + + 665 | | 666 H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 d | | 668 r + + 669 | | 670 ^ + Destination Routing Locator + 671 | | | 672 \ + + 673 \ | | 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 / | Source Port = xxxx | Dest Port = 4341 | 676 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 \ | UDP Length | UDP Checksum | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 L / |S| Locator Reach Bits | 680 I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 S \ | Nonce | 682 P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 / |Version| Traffic Class | Flow Label | 684 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 / | Payload Length | Next Header | Hop Limit | 686 v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | | 688 I + + 689 n | | 690 n + Source EID + 691 e | | 692 r + + 693 | | 694 H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 d | | 696 r + + 697 | | 698 ^ + Destination EID + 699 \ | | 700 \ + + 701 \ | | 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 5.3. Tunnel Header Field Descriptions 706 IH Header: is the inner header, preserved from the datagram received 707 from the originating host. The source and destination IP 708 addresses are EIDs. 710 OH Header: is the outer header prepended by an ITR. The address 711 fields contain RLOCs obtained from the ingress router's EID-to- 712 RLOC cache. The IP protocol number is "UDP (17)" from [RFC0768]. 713 The DF bit of the Flags field is set to 0. 715 UDP Header: contains a ITR selected source port when encapsulating a 716 packet. See Section 6.4 for details on the hash algorithm used 717 select a source port based on the 5-tuple of the inner header. 718 The destination port MUST be set to the well-known IANA assigned 719 port value 4341. 721 UDP Checksum: this field field MUST be transmitted as 0 and ignored 722 on receipt by the ETR. Note, even when the UDP checksum is 723 transmitted as 0 an intervening NAT device can recalculate the 724 checksum and rewrite the UDP checksum field to non-zero. For 725 performance reasons, the ETR MUST ignore the checksum and MUST not 726 do a checksum computation. 728 UDP Length: for an IPv4 encapsulated packet, the inner header Total 729 Length plus the UDP and LISP header lengths are used. For an IPv6 730 encapsulated packet, the inner header Payload Length plus the size 731 of the IPv6 header (40 bytes) plus the size of the UDP and LISP 732 headers are used. The UDP header length is 8 bytes. The LISP 733 header length is 8 bytes when no loc-reach-bit header extensions 734 are used. 736 S: this is the Solicit-Map-Request (SMR) bit. See section 737 Section 6.5.2 for details. 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 31-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 LISP Nonce: is a 32-bit value that is randomly generated by an ITR. 754 It is used to test route-returnability when xTRs exchange 755 encapsulated data packets with the SMR bit set, Data-Probe, Map- 756 Request, or Map-Reply messages. 758 When doing Recursive Tunneling: 760 o The OH header Time to Live field (or Hop Limit field, in case of 761 IPv6) MUST be copied from the IH header Time to Live field. 763 o The OH header Type of Service field (or the Traffic Class field, 764 in the case of IPv6) SHOULD be copied from the IH header Type of 765 Service field (with one caveat, see below). 767 When doing Re-encapsulated Tunneling: 769 o The new OH header Time to Live field SHOULD be copied from the 770 stripped OH header Time to Live field. 772 o The new OH header Type of Service field SHOULD be copied from the 773 stripped OH header Type of Service field (with one caveat, see 774 below).. 776 Copying the TTL serves two purposes: first, it preserves the distance 777 the host intended the packet to travel; second, and more importantly, 778 it provides for suppression of looping packets in the event there is 779 a loop of concatenated tunnels due to misconfiguration. 781 When the Type of Service code-points indicate the use of ECN 782 according to [RFC3168], the full-functionality option for simple 783 tunnels will be used when ITR encapsulating and ETR decapsulating. 784 Therefore, the Congestion Experience (CE) bit will be preserved when 785 a packet traveres a LISP tunnel. 787 5.4. Dealing with Large Encapsulated Packets 789 In the event that the MTU issues mentioned above prove to be more 790 serious than expected, this section proposes 2 simple mechanisms to 791 deal with large packets. One is stateless using IP fragmentation and 792 the other is stateful using Path MTU Discovery [RFC1191]. 794 It is left to the implementor to decide if the stateless or stateful 795 mechanism should be implemented. Both or neither can be decided as 796 well since it is a local decision in the ITR regarding how to deal 797 with MTU issues. Sites can interoperate with differing mechanisms. 799 5.4.1. A Stateless Solution to MTU Handling 801 An ITR stateless solution to handle MTU issues is described as 802 follows: 804 1. Define an architectural constant S for the maximum size of a 805 packet, in bytes, an ITR would receive from a source inside of 806 its site. 808 2. Define L to be the maximum size, in bytes, a packet of size S 809 would be after the ITR prepends the LISP header, UDP header, and 810 outer network layer header of size H. 812 3. Calculate: S + H = L. 814 When an ITR receives a packet from a site-facing interface and adds H 815 bytes worth of encapsulation to yield a packet size of L bytes, it 816 resolves the MTU issue by first splitting the original packet into 2 817 equal-sized fragments. A LISP header is then prepended to each 818 fragment. This will ensure that the new, encapsulated packets are of 819 size (S/2 + H), which is always below the effective tunnel MTU. 821 When an ETR receives encapsulated fragments, it treats them as two 822 individually encapsulated packets. It strips the LISP headers then 823 forwards each fragment to the destination host of the destination 824 site. The two fragments are reassembled at the destination host into 825 the single IP datagram that was originated by the source host. 827 This behavior is performed by the ITR when the source host originates 828 a packet with the DF field of the IP header is set to 0. When the DF 829 field of the IP header is set to 1, or the packet is an IPv6 packet 830 originated by the source host, the ITR will drop the packet when the 831 size is greater than L, and sends an ICMP Too Big message to the 832 source with a value of S, where S is (L - H). 834 When the outer header encapsulation uses an IPv4 header the DF bit is 835 always set to 0. 837 This specification recommends that L be defined as 1500. 839 5.4.2. A Stateful Solution to MTU Handling 841 An ITR stateful solution to handle MTU issues is describe as follows 842 and was first introduced in [OPENLISP]: 844 1. The ITR will keep state of the effective MTU for each locator per 845 mapping cache entry. The effective MTU is what the core network 846 can deliver along the path between ITR and ETR. 848 2. When an encapsulated packet, with DF bit always set to 0, exceeds 849 what the core network can deliver, one of the intermediate 850 routers on the path will send an ICMP Too Big message to the ITR. 851 The ITR will parse the ICMP message to determine which locator is 852 affected by the effective MTU change and then record the new 853 effective MTU value in the mapping cache entry. 855 3. When a packet is received by the ITR from a source inside of the 856 site and the size of the packet is greater than the effective MTU 857 stored with the mapping cache entry associated with the 858 destination EID the packet is for, the ITR will send an ICMP Too 859 Big message back to the source. The packet size advertised by 860 the ITR in the ICMP Too Big message is the effective MTU minus 861 the LISP encapsulation length. 863 Even though this mechanism is stateful, it has advantages over the 864 stateless IP fragmentation mechanism, by not involving the 865 destination host with reassembly of ITR fragmented packets. 867 6. EID-to-RLOC Mapping 869 6.1. LISP IPv4 and IPv6 Control Plane Packet Formats 871 The following new UDP packet types are used to retrieve EID-to-RLOC 872 mappings: 874 0 1 2 3 875 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 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 |Version| IHL |Type of Service| Total Length | 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 | Identification |Flags| Fragment Offset | 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 | Time to Live | Protocol = 17 | Header Checksum | 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 | Source Routing Locator | 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 | Destination Routing Locator | 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 / | Source Port | Dest Port | 888 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 \ | UDP Length | UDP Checksum | 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 | | 892 | LISP Message | 893 | | 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 0 1 2 3 897 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 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 |Version| Traffic Class | Flow Label | 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 | Payload Length | Next Header=17| Hop Limit | 902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 903 | | 904 + + 905 | | 906 + Source Routing Locator + 907 | | 908 + + 909 | | 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 | | 912 + + 913 | | 914 + Destination Routing Locator + 915 | | 916 + + 917 | | 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 / | Source Port | Dest Port | 920 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 \ | UDP Length | UDP Checksum | 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 | | 924 | LISP Message | 925 | | 926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 The LISP UDP-based messages are the Map-Request and Map-Reply 929 messages. When a UDP Map-Request is sent, the UDP source port is 930 chosen by the sender and the destination UDP port number is set to 931 4342. When a UDP Map-Reply is sent, the source UDP port number is 932 set to 4342 and the destination UDP port number is copied from the 933 source port of either the Map-Request or the invoking data packet. 935 The UDP Length field will reflect the length of the UDP header and 936 the LISP Message payload. 938 The UDP Checksum is computed and set to non-zero for Map-Request and 939 Map-Reply messages. It MUST be checked on receipt and if the 940 checksum fails, the packet MUST be dropped. 942 LISP-CONS [CONS] use TCP to send LISP control messages. The format 943 of control messages includes the UDP header so the checksum and 944 length fields can be used to protect and delimit message boundaries. 946 This main LISP specification is the authoritative source for message 947 format definitions for the Map-Request and Map-Reply messages. 949 6.1.1. LISP Packet Type Allocations 951 This section will be the authoritative source for allocating LISP 952 Type values. Current allocations are: 954 Reserved: 0 b'0000' 955 LISP Map-Request: 1 b'0001' 956 LISP Map-Reply: 2 b'0010' 957 LISP Map-Register: 3 b'0011' 958 LISP-CONS Open Message: 8 b'1000' 959 LISP-CONS Push-Add Message: 9 b'1001' 960 LISP-CONS Push-Delete Message: 10 b'1010' 961 LISP-CONS Unreachable Message 11 b'1011' 963 6.1.2. Map-Request Message Format 965 0 1 2 3 966 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 967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 968 |S| Locator Reach Bits | 969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 970 | Nonce | 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 972 |Type=1 |A|R| Reserved | Record Count | 973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 974 | Source-EID-AFI | ITR-AFI | 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 976 | Source EID Address ... | 977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 978 | Originating ITR RLOC Address ... | 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 980 / | Reserved | EID mask-len | EID-prefix-AFI | 981 Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 \ | EID-prefix ... | 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 | Map-Reply Record ... | 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 | Mapping Protocol Data | 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 Packet field descriptions: 991 S: This is the SMR bit. See Section 6.5.2 for details. 993 Locator Reach Bits: These bits MUST be set to 0 on transmission and 994 ignored on receipt. They cannot be used for indicating 995 reachability because the Map-Request does not have the EID-prefix 996 for the sending site so the receiver of the Map-Request cannot 997 know what mapping entry to associate the reachability with. 998 However, when Mapping Data is provided in the Map-Reply Record 999 field, and the receiver of the Map-Request is configured to accept 1000 the mapping data, the R-bit per locator entry in the EID-prefix 1001 record is used to denote reachability. 1003 Nonce: A 4-byte random value created by the sender of the Map- 1004 Request. 1006 Type: 1 (Map-Request) 1008 A: This is an authoritative bit, which is set to 0 for UDP-based Map- 1009 Requests sent by an ITR. See other control-specific documents 1010 [CONS] for TCP-based Map-Requests. 1012 R: When set, it indicates a Map-Reply Record segment is included in 1013 the Map-Request. 1015 Reserved: Set to 0 on transmission and ignored on receipt. 1017 Record Count: The number of records in this request message. A 1018 record is comprised of the portion of the packet is labeled 'Rec' 1019 above and occurs the number of times equal to Record count. 1021 Source-EID-AFI: Address family of the "Source EID Address" field. 1023 ITR-AFI: Address family of the "Originating ITR RLOC Address" field. 1025 Source EID Address: This is the EID of the source host which 1026 originated the packet which is invoking this Map-Request. 1028 Originating ITR RLOC Address: Used to give the ETR the option of 1029 returning a Map-Reply in the address-family of this locator. 1031 EID mask-len: Mask length for EID prefix. 1033 EID-AFI: Address family of EID-prefix according to [RFC2434] 1035 EID-prefix: 4 bytes if an IPv4 address-family, 16 bytes if an IPv6 1036 address-family. When a Map-Request is sent by an ITR because a 1037 data packet is received for a destination where there is no 1038 mapping entry, the EID-prefix is set to the destination IP address 1039 of the data packet. And the 'EID mask-len' is set to 32 or 128 1040 for IPv4 or IPv6, respectively. When an xTR wants to query a site 1041 about the status of a mapping it already has cached, the EID- 1042 prefix used in the Map-Request has the same mask-length as the 1043 EID-prefix returned from the site when it sent a Map-Reply 1044 message. 1046 Map-Reply Record: When the R bit is set, this field is the size of 1047 the "Record" field in the Map-Reply format. This Map-Reply record 1048 contains the EID-to-RLOC mapping entry associated with the Source 1049 EID. This allows the ETR which will receive this Map-Request to 1050 cache the data if it chooses to do so. 1052 Mapping Protocol Data: See [CONS] or [ALT] for details. This field 1053 is optional and present when the UDP length indicates there is 1054 enough space in the packet to include it. 1056 6.1.3. EID-to-RLOC UDP Map-Request Message 1058 A Map-Request is sent from an ITR when it needs a mapping for an EID, 1059 wants to test an RLOC for reachability, or wants to refresh a mapping 1060 before TTL expiration. For the initial case, the destination IP 1061 address used for the Map-Request is the destination-EID from the 1062 packet which had a mapping cache lookup failure. For the later 2 1063 cases, the destination IP address used for the Map-Request is one of 1064 the RLOC addresses from the locator-set of the map cache entry. In 1065 all cases, the UDP source port number for the Map-Request message is 1066 a randomly allocated 16-bit value and the UDP destination port number 1067 is set to the well-known destination port number 4342. A successful 1068 Map-Reply updates the cached set of RLOCs associated with the EID 1069 prefix range. 1071 Map-Requests can also be LISP encapsulated using UDP destination port 1072 4341 when sent from an ITR to a Map-Resolver. Likewise, Map-Requests 1073 are LISP encapsulated the same way from a Map-Server to an ETR. 1074 Details on encapsulated Map-Requests and Map-Resolvers can be found 1075 in [LISP-MS]. 1077 Map-Requests MUST be rate-limited. It is recommended that a Map- 1078 Request for the same EID-prefix be sent no more than once per second. 1080 6.1.4. Map-Reply Message Format 1082 0 1 2 3 1083 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 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1085 |x| Locator Reach Bits | 1086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1087 | Nonce | 1088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1089 |Type=2 | Reserved | Record Count | 1090 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1091 | | Record TTL | 1092 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1093 R | Locator Count | EID mask-len |A| ACT | Reserved | 1094 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 c | Reserved | EID-AFI | 1096 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 r | EID-prefix | 1098 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 | /| Priority | Weight | M Priority | M Weight | 1100 | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 | o | Unused Flags |R| Loc-AFI | 1102 | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1103 | \| Locator | 1104 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1105 | Mapping Protocol Data | 1106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1108 Packet field descriptions: 1110 x: Set to 0 on transmission and ignored on receipt. 1112 Locator Reach Bits: Refer to Section 5.3. This field MUST be set to 1113 0 on transmission and ignored on receipt. The locator 1114 reachability is encoded as the R-bit in each locator entry of each 1115 EID-prefix record. 1117 Nonce: A 4-byte value set in a Data-Probe packet or a Map-Request 1118 that is echoed here in the Map-Reply. 1120 Type: 2 (Map-Reply) 1121 Reserved: Set to 0 on transmission and ignored on receipt. 1123 Record Count: The number of records in this reply message. A record 1124 is comprised of that portion of the packet labeled 'Record' above 1125 and occurs the number of times equal to Record count. 1127 Record TTL: The time in minutes the recipient of the Map-Reply will 1128 store the mapping. If the TTL is 0, the entry should be removed 1129 from the cache immediately. If the value is 0xffffffff, the 1130 recipient can decide locally how long to store the mapping. 1132 Locator Count: The number of Locator entries. A locator entry 1133 comprises what is labeled above as 'Loc'. The locator count can 1134 be 0 indicating there are no locators for the EID-prefix. 1136 EID mask-len: Mask length for EID prefix. 1138 A: The Authoritative bit, when sent by a UDP-based message is always 1139 set by the ETR. See [CONS] for TCP-based Map-Replies. 1141 ACT: This 3-bit field describes negative Map-Reply actions. These 1142 bits are used only when the 'Locator Count' field is set to 0. 1143 The action bits are encoded only in Map-Reply messages. The 1144 actions defined are used by an ITR or PTR when a destination EID 1145 matches a negative mapping cache entry. The current assigned 1146 values are: 1148 (0) No action: No action is being conveyed by the sender of the 1149 Map-Reply message. 1151 (1) Natively-Forward: The packet is not encapsulated or dropped 1152 but natively forwarded. 1154 (2) Drop: The packet is dropped silently. 1156 (3) Send-Map-Request: The packet invokes sending a Map-Request. 1158 EID-AFI: Address family of EID-prefix according to [RFC2434]. 1160 EID-prefix: 4 bytes if an IPv4 address-family, 16 bytes if an IPv6 1161 address-family. 1163 Priority: each RLOC is assigned a unicast priority. Lower values 1164 are more preferable. When multiple RLOCs have the same priority, 1165 they may be used in a load-split fashion. A value of 255 means 1166 the RLOC MUST NOT be used for unicast forwarding. 1168 Weight: when priorities are the same for multiple RLOCs, the weight 1169 indicates how to balance unicast traffic between them. Weight is 1170 encoded as a percentage of total unicast packets that match the 1171 mapping entry. If a non-zero weight value is used for any RLOC, 1172 then all RLOCs must use a non-zero weight value and then the sum 1173 of all weight values MUST equal 100. If a zero value is used for 1174 any RLOC weight, then all weights MUST be zero and the receiver of 1175 the Map-Reply will decide how to load-split traffic. See 1176 Section 6.4 for a suggested hash algorithm to distribute load 1177 across locators with same priority and equal weight values. When 1178 a single RLOC exists in a mapping entry, the weight value MUST be 1179 set to 100 and ignored on receipt. 1181 M Priority: each RLOC is assigned a multicast priority used by an 1182 ETR in a receiver multicast site to select an ITR in a source 1183 multicast site for building multicast distribution trees. A value 1184 of 255 means the RLOC MUST NOT be used for joining a multicast 1185 distribution tree. 1187 M Weight: when priorities are the same for multiple RLOCs, the 1188 weight indicates how to balance building multicast distribution 1189 trees across multiple ITRs. The weight is encoded as a percentage 1190 of total number of trees build to the source site identified by 1191 the EID-prefix. If a non-zero weight value is used for any RLOC, 1192 then all RLOCs must use a non-zero weight value and then the sum 1193 of all weight values MUST equal 100. If a zero value is used for 1194 any RLOC weight, then all weights MUST be zero and the receiver of 1195 the Map-Reply will decide how to distribute multicast state across 1196 ITRs. 1198 Unused Flags: set to 0 when sending and ignored on receipt. 1200 R: when this bit is set, the locator is known to be reachable from 1201 the Map-Reply sender's perspective. When there is a single 1202 mapping record in the message, the R-bit for each locator must 1203 have a consistent setting with the bitfield setting of the 'Loc 1204 Reach Bits' field in the early part of the header. When there are 1205 multiple mapping records in the message, the 'Loc Reach Bits' 1206 field is set to 0. 1208 Locator: an IPv4 or IPv6 address (as encoded by the 'Loc-AFI' field) 1209 assigned to an ETR or router acting as a proxy replier for the 1210 EID-prefix. Note that the destination RLOC address MAY be an 1211 anycast address. A source RLOC can be an anycast address as well. 1212 The source or destination RLOC MUST NOT be the broadcast address 1213 (255.255.255.255 or any subnet broadcast address known to the 1214 router), and MUST NOT be a link-local multicast address. The 1215 source RLOC MUST NOT be a multicast address. The destination RLOC 1216 SHOULD be a multicast address if it is being mapped from a 1217 multicast destination EID. 1219 Mapping Protocol Data: See [CONS] or [ALT] for details. This field 1220 is optional and present when the UDP length indicates there is 1221 enough space in the packet to include it. 1223 6.1.5. EID-to-RLOC UDP Map-Reply Message 1225 When a Data Probe packet or a Map-Request triggers a Map-Reply to be 1226 sent, the RLOCs associated with the EID-prefix matched by the EID in 1227 the original packet destination IP address field will be returned. 1228 The RLOCs in the Map-Reply are the globally-routable IP addresses of 1229 the ETR but are not necessarily reachable; separate testing of 1230 reachability is required. 1232 Note that a Map-Reply may contain different EID-prefix granularity 1233 (prefix + length) than the Map-Request which triggers it. This might 1234 occur if a Map-Request were for a prefix that had been returned by an 1235 earlier Map-Reply. In such a case, the requester updates its cache 1236 with the new prefix information and granularity. For example, a 1237 requester with two cached EID-prefixes that are covered by a Map- 1238 Reply containing one, less-specific prefix, replaces the entry with 1239 the less-specific EID-prefix. Note that the reverse, replacement of 1240 one less-specific prefix with multiple more-specific prefixes, can 1241 also occur but not by removing the less-specific prefix rather by 1242 adding the more-specific prefixes which during a lookup will override 1243 the less-specific prefix. 1245 Replies SHOULD be sent for an EID-prefix no more often than once per 1246 second to the same requesting router. For scalability, it is 1247 expected that aggregation of EID addresses into EID-prefixes will 1248 allow one Map-Reply to satisfy a mapping for the EID addresses in the 1249 prefix range thereby reducing the number of Map-Request messages. 1251 The addresses for a encapsulated data packets or Map-Request message 1252 are swapped and used for sending the Map-Reply. The UDP source and 1253 destination ports are swapped as well. That is, the source port in 1254 the UDP header for the Map-Reply is set to the well-known UDP port 1255 number 4342. 1257 Map-Reply records can have an empty locator-set. This type of a Map- 1258 Reply is called a Negative Map-Reply. Negative Map-Replies convey 1259 special actions by the sender to the ITR or PTR which have solicited 1260 the Map-Reply. There are two primary applications for Negative Map- 1261 Replies. The first is for a Map-Resolver to instruct an ITR or PTR 1262 when a destination is for a LISP site versus a non-LISP site. And 1263 the other is to source quench Map-Requests which are sent for non- 1264 allocated EIDs. 1266 6.1.6. Map-Register Message Format 1268 The usage details of the Map-Register message can be found in 1269 specification [LISP-MS]. This section solely defines the message 1270 format. 1272 The message is sent in a UDP with a destination UDP port 4342 and a 1273 randomly selected UDP port number. Before an IPv4 or IPv6 network 1274 layer header is prepended, an AH header is prepended to carry 1275 authentication information. The format conforms to the IPsec 1276 specification [RFC2402]. The Map-Register message will use transport 1277 mode by setting the IP protocol number field or the IPv6 next-header 1278 field to 51. 1280 The AH header from [RFC2402] is: 1282 0 1 2 3 1283 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 1284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1285 | Next Header | Payload Len | RESERVED | 1286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1287 | Security Parameters Index (SPI) | 1288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1289 | Sequence Number Field | 1290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1291 | | 1292 + Authentication Data (variable) | 1293 | | 1294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1296 The Next Header field is set to UDP. The SPI field is set to 0 1297 (since no Security Association or Key Exchange protocol is being 1298 used). The Sequence Number is a randomly chosen value by the sender. 1299 The Authentication Data is 16 bytes and holds a MD5 HMAC. 1301 The Map-Register message format is: 1303 0 1 2 3 1304 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 1305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1306 |x| Locator Reach Bits | 1307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1308 | Nonce | 1309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1310 |Type=3 |P| Reserved | Record Count | 1311 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1312 | | Record TTL | 1313 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1314 R | Locator Count | EID mask-len |A| ACT | Reserved | 1315 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1316 c | Reserved | EID-AFI | 1317 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1318 r | EID-prefix | 1319 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1320 | /| Priority | Weight | M Priority | M Weight | 1321 | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1322 | o | Unused Flags |R| Loc-AFI | 1323 | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1324 | \| Locator | 1325 +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1327 Packet field descriptions: 1329 x: Set to 0 on transmission and ignored on receipt. 1331 Locator Reach Bits: Refer to Section 5.3. This field MUST be set to 1332 0 on transmission and ignored on receipt. The locator 1333 reachability is encoded as the R-bit in each locator entry of each 1334 EID-prefix record. 1336 Nonce: The Nonce field is set to 0 in Map-Register messages. 1338 Type: 3 (Map-Register) 1340 P: This is the Proxy-Map-Reply bit. When set to 1, the ETR sending a 1341 Map-Register is asking the Map-Server to send non-authoritative 1342 Map-Replies on behalf of the ETR. 1344 Reserved: Set to 0 on transmission and ignored on receipt. 1346 Record Count: The number of records in this Map-Register message. A 1347 record is comprised of that portion of the packet labeled 'Record' 1348 above and occurs the number of times equal to Record count. 1350 The definition of the rest of the Map-Register can be found in the 1351 Map-Reply section. 1353 6.2. Routing Locator Selection 1355 Both client-side and server-side may need control over the selection 1356 of RLOCs for conversations between them. This control is achieved by 1357 manipulating the Priority and Weight fields in EID-to-RLOC Map-Reply 1358 messages. Alternatively, RLOC information may be gleaned from 1359 received tunneled packets or EID-to-RLOC Map-Request messages. 1361 The following enumerates different scenarios for choosing RLOCs and 1362 the controls that are available: 1364 o Server-side returns one RLOC. Client-side can only use one RLOC. 1365 Server-side has complete control of the selection. 1367 o Server-side returns a list of RLOC where a subset of the list has 1368 the same best priority. Client can only use the subset list 1369 according to the weighting assigned by the server-side. In this 1370 case, the server-side controls both the subset list and load- 1371 splitting across its members. The client-side can use RLOCs 1372 outside of the subset list if it determines that the subset list 1373 is unreachable (unless RLOCs are set to a Priority of 255). Some 1374 sharing of control exists: the server-side determines the 1375 destination RLOC list and load distribution while the client-side 1376 has the option of using alternatives to this list if RLOCs in the 1377 list are unreachable. 1379 o Server-side sets weight of 0 for the RLOC subset list. In this 1380 case, the client-side can choose how the traffic load is spread 1381 across the subset list. Control is shared by the server-side 1382 determining the list and the client determining load distribution. 1383 Again, the client can use alternative RLOCs if the server-provided 1384 list of RLOCs are unreachable. 1386 o Either side (more likely on the server-side ETR) decides not to 1387 send a Map-Request. For example, if the server-side ETR does not 1388 send Map-Requests, it gleans RLOCs from the client-side ITR, 1389 giving the client-side ITR responsibility for bidirectional RLOC 1390 reachability and preferability. Server-side ETR gleaning of the 1391 client-side ITR RLOC is done by caching the inner header source 1392 EID and the outer header source RLOC of received packets. The 1393 client-side ITR controls how traffic is returned and can alternate 1394 using an outer header source RLOC, which then can be added to the 1395 list the server-side ETR uses to return traffic. Since no 1396 Priority or Weights are provided using this method, the server- 1397 side ETR must assume each client-side ITR RLOC uses the same best 1398 Priority with a Weight of zero. In addition, since EID-prefix 1399 encoding cannot be conveyed in data packets, the EID-to-RLOC cache 1400 on tunnel routers can grow to be very large. 1402 RLOCs that appear in EID-to-RLOC Map-Reply messages are considered 1403 reachable. The Map-Reply and the database mapping service does not 1404 provide any reachability status for Locators. This is done outside 1405 of the mapping service. See next section for details. 1407 6.3. Routing Locator Reachability 1409 There are 4 methods for determining when a Locator is either 1410 reachable or has become unreachable: 1412 1. Locator reachability is determined by an ETR by examining the 1413 Loc-Reach-Bits from a LISP header of a encapsulated data packet 1414 which is provided by an ITR when an ITR encapsulates data. 1416 2. Locator unreachability is determined by an ITR by receiving ICMP 1417 Network or Host Unreachable messages. 1419 3. Locator unreachability can also be determined by an BGP-enabled 1420 ITR when there is no prefix matching a Locator address from the 1421 BGP RIB. 1423 4. Locator unreachability is determined when a host sends an ICMP 1424 Port Unreachable message. This occurs when an ITR may not use 1425 any methods of interworking. one which is describe in [INTERWORK] 1426 and the encapsulated data packet is received by a host at the 1427 destination non-LISP site. 1429 5. Locator reachability is determined by receiving a Map-Reply 1430 message from a ETR's Locator address in response to a previously 1431 sent Map-Request. 1433 6. Locator reachability can also be determined by receiving packets 1434 encapsulated by the ITR assigned to the locator address. 1436 When determining Locator reachability by examining the Loc-Reach-Bits 1437 from the LISP encapsulate data packet, an ETR will receive up to date 1438 status from the ITR closest to the Locators at the source site. The 1439 ITRs at the source site can determine reachability when running their 1440 IGP at the site. When the ITRs are deployed on CE routers, typically 1441 a default route is injected into the site's IGP from each of the 1442 ITRs. If an ITR goes down, the CE-PE link goes down, or the PE 1443 router goes down, the CE router withdraws the default route. This 1444 allows the other ITRs at the site to determine one of the Locators 1445 has gone unreachable. 1447 The Locators listed in a Map-Reply are numbered with ordinals 0 to 1448 n-1. The Loc-Reach-Bits in a LISP Data Message are numbered from 0 1449 to n-1 starting with the least significant bit numbered as 0. So, 1450 for example, if the ITR with locator listed as the 3rd Locator 1451 position in the Map-Reply goes down, all other ITRs at the site will 1452 have the 3rd bit from the right cleared (the bit that corresponds to 1453 ordinal 2). 1455 When an ETR decapsulates a packet, it will look for a change in the 1456 Loc-Reach-Bits value. When a bit goes from 1 to 0, the ETR will 1457 refrain from encapsulating packets to the Locator that has just gone 1458 unreachable. It can start using the Locator again when the bit that 1459 corresponds to the Locator goes from 0 to 1. Loc-Reach-Bits are 1460 associated with a locator-set per EID-prefix. Therefore, when a 1461 locator becomes unreachable, the loc-reach-bit that corresponds to 1462 that locator's position in the list returned by the last Map-Reply 1463 will be set to zero for that particular EID-prefix. 1465 When ITRs at the site are not deployed in CE routers, the IGP can 1466 still be used to determine the reachability of Locators provided they 1467 are injected a stub links into the IGP. This is typically done when 1468 a /32 address is configured on a loopback interface. 1470 When ITRs receive ICMP Network or Host Unreachable messages as a 1471 method to determine unreachability, they will refrain from using 1472 Locators which are described in Locator lists of Map-Replies. 1473 However, using this approach is unreliable because many network 1474 operators turn off generation of ICMP Unreachable messages. 1476 If an ITR does receive an ICMP Network or Host Unreachable message, 1477 it MAY originate its own ICMP Unreachable message destined for the 1478 host that originated the data packet the ITR encapsulated. 1480 Also, BGP-enabled ITRs can unilaterally examine the BGP RIB to see if 1481 a locator address from a locator-set in a mapping entry matches a 1482 prefix. If it does not find one and BGP is running in the Default 1483 Free Zone (DFZ), it can decide to not use the locator even though the 1484 Loc-Reach-Bits indicate the locator is up. In this case, the path 1485 from the ITR to the ETR that is assigned the locator is not 1486 available. More details are in [LOC-ID-ARCH]. 1488 Optionally, an ITR can send a Map-Request to a Locator and if a Map- 1489 Reply is returned, reachability of the Locator has been determined. 1490 Obviously, sending such probes increases the number of control 1491 messages originated by tunnel routers for active flows, so Locators 1492 are assumed to be reachable when they are advertised. 1494 This assumption does create a dependency: Locator unreachability is 1495 detected by the receipt of ICMP Host Unreachable messages. When an 1496 Locator has been determined to be unreachable, it is not used for 1497 active traffic; this is the same as if it were listed in a Map-Reply 1498 with priority 255. 1500 The ITR can test the reachability of the unreachable Locator by 1501 sending periodic Requests. Both Requests and Replies MUST be rate- 1502 limited. Locator reachability testing is never done with data 1503 packets since that increases the risk of packet loss for end-to-end 1504 sessions. 1506 When an ETR is decapsulating packets, it can be sure that the path 1507 from the encapsulating ITR is available. The ETR can assume the path 1508 from the ETR to the ITR is also reachable. Even if there is 1509 asymmetric routing in the core, the first-hop and last-hop ASes will 1510 be the same for both directions of traffic since the locator 1511 addresses are out of the PA blocks of each. However, the assumption 1512 may not always be valid, so this mechanism should be used as a best- 1513 effort indication that a working path exists between the sites. In 1514 the event of unidirectional traffic from an ITR to an ETR, an ITR 1515 should not conclude that a locator is unreachable since it is not 1516 receiving packets, but use alternate mechanisms described above to 1517 determine reachability. 1519 6.4. Routing Locator Hashing 1521 When an ETR provides an EID-to-RLOC mapping in a Map-Reply message to 1522 a requesting ITR, the locator-set for the EID-prefix may contain 1523 different priority values for each locator address. When more than 1524 one best priority locator exists, the ITR can decide how to load 1525 share traffic against the corresponding locators. 1527 The following hash algorithm may be used by an ITR to select a 1528 locator for a packet destined to an EID for the EID-to-RLOC mapping: 1530 1. Either a source and destination address hash can be used or the 1531 traditional 5-tuple hash which includes the source and 1532 destination addresses, source and destination TCP, UDP, or SCTP 1533 port numbers and the IP protocol number field or IPv6 next- 1534 protocol fields of a packet a host originates from within a LISP 1535 site. When a packet is not a TCP, UDP, or SCTP packet, the 1536 source and destination addresses only from the header are used to 1537 compute the hash. 1539 2. Take the hash value and divide it by the number of locators 1540 stored in the locator-set for the EID-to-RLOC mapping. 1542 3. The remainder will be yield a value of 0 to "number of locators 1543 minus 1". Use the remainder to select the locator in the 1544 locator-set. 1546 Note that when a packet is LISP encapsulated, the source port number 1547 in the outer UDP header needs to be set. Selecting a random value 1548 allows core routers which are attached to Link Aggregation Groups 1549 (LAGs) to load-split the encapsulated packets across member links of 1550 such LAGs. Otherwise, core routers would see a single flow, since 1551 packets have a source address of the ITR, for packets which are 1552 originated by different EIDs at the source site. A suggested setting 1553 for the source port number computed by an ITR is a 5-tuple hash 1554 function on the inner header, as described above. 1556 6.5. Changing the Contents of EID-to-RLOC Mappings 1558 Since the LISP architecture uses a caching scheme to retrieve and 1559 store EID-to-RLOC mappings, the only way an ITR can get a more up-to- 1560 date mapping is to re-request the mapping. However, the ITRs do not 1561 know when the mappings change and the ETRs do not keep track of who 1562 requested its mappings. For scalability reasons, we want to maintain 1563 this approach but need to provide a way for ETRs change their 1564 mappings and inform the sites that are currently communicating with 1565 the ETR site using such mappings. 1567 When a locator record is added to the end of a locator-set, it is 1568 easy to update mappings. We assume new mappings will maintain the 1569 same locator ordering as the old mapping but just have new locators 1570 appended to the end of the list. So some ITRs can have a new mapping 1571 while other ITRs have only an old mapping that is used until they 1572 time out. When an ITR has only an old mapping but detects bits set 1573 in the loc-reach-bits that correspond to locators beyond the list it 1574 has cached, it simply ignores them. 1576 When a locator record is removed from a locator-set, ITRs that have 1577 the mapping cached will not use the removed locator because the xTRs 1578 will set the loc-reach-bit to 0. So even if the locator is in the 1579 list, it will not be used. For new mapping requests, the xTRs can 1580 set the locator address to 0 as well as setting the corresponding 1581 loc-reach-bit to 0. This forces ITRs with old or new mappings to 1582 avoid using the removed locator. 1584 If many changes occur to a mapping over a long period of time, one 1585 will find empty record slots in the middle of the locator-set and new 1586 records appended to the locator-set. At some point, it would be 1587 useful to compact the locator-set so the loc-reach-bit settings can 1588 be efficiently packed. 1590 We propose here two approaches for locator-set compaction, one 1591 operational and the other a protocol mechanism. The operational 1592 approach uses a clock sweep method. The protocol approach uses the 1593 concept of Solicit-Map-Requests. 1595 6.5.1. Clock Sweep 1597 The clock sweep approach uses planning in advance and the use of 1598 count-down TTLs to time out mappings that have already been cached. 1599 The default setting for an EID-to-RLOC mapping TTL is 24 hours. So 1600 there is a 24 hour window to time out old mappings. The following 1601 clock sweep procedure is used: 1603 1. 24 hours before a mapping change is to take effect, a network 1604 administrator configures the ETRs at a site to start the clock 1605 sweep window. 1607 2. During the clock sweep window, ETRs continue to send Map-Reply 1608 messages with the current (unchanged) mapping records. The TTL 1609 for these mappings is set to 1 hour. 1611 3. 24 hours later, all previous cache entries will have timed out, 1612 and any active cache entries will time out within 1 hour. During 1613 this 1 hour window the ETRs continue to send Map-Reply messages 1614 with the current (unchanged) mapping records with the TTL set to 1615 1 minute. 1617 4. At the end of the 1 hour window, the ETRs will send Map-Reply 1618 messages with the new (changed) mapping records. So any active 1619 caches can get the new mapping contents right away if not cached, 1620 or in 1 minute if they had the mapping cached. 1622 6.5.2. Solicit-Map-Request (SMR) 1624 Soliciting a Map-Request is a selective way for xTRs, at the site 1625 where mappings change, to control the rate they receive requests for 1626 Map-Reply messages. SMRs are also used to tell remote ITRs to update 1627 the mappings they have cached. 1629 Since the xTRs don't keep track of remote ITRs that have cached their 1630 mappings, they can not tell exactly who needs the new mapping 1631 entries. So an xTR will solicit Map-Requests from sites it is 1632 currently sending encapsulated data to, and only from those sites. 1633 The xTRs can locally decide the algorithm for how often and to how 1634 many sites it sends SMR messages. 1636 An SMR message is simply a bit set in an encapsulated data packet 1637 (and a Map-Request message). When an ETR at a remote site 1638 decapsulates a data packet that has the SMR bit set, it can tell that 1639 a new Map-Request message is being solicited. Both the xTR that 1640 sends the SMR message and the site that acts on the SMR message MUST 1641 be rate-limited. 1643 The following procedure shows how a SMR exchange occurs when a site 1644 is doing locator-set compaction for an EID-to-RLOC mapping: 1646 1. When the database mappings in an ETR change, the ITRs at the site 1647 begin to set the SMR bit in packets they encapsulate to the sites 1648 they communicate with. 1650 2. A remote xTR which decapsulates a packet with the SMR bit set 1651 will schedule sending a Map-Request message to the source locator 1652 address of the encapsulated packet. The nonce in the Map-Request 1653 is copied from the nonce in the encapsulated data packet that has 1654 the SMR bit set. 1656 3. The remote xTR retransmits the Map-Request slowly until it gets a 1657 Map-Reply while continuing to use the cached mapping. 1659 4. The ETRs at the site with the changed mapping will reply to the 1660 Map-Request with a Map-Reply message provided the Map-Request 1661 nonce matches the nonce from the SMR. The Map-Reply messages 1662 SHOULD be rate limited. This is important to avoid Map-Reply 1663 implosion. 1665 5. The ETRs, at the site with the changed mapping, records the fact 1666 that the site that sent the Map-Request has received the new 1667 mapping data in the mapping cache entry for the remote site so 1668 the loc-reach-bits are reflective of the new mapping for packets 1669 going to the remote site. The ETR then stops sending packets 1670 with the SMR-bit set. 1672 For security reasons an ITR MUST NOT process unsolicited Map-Replies. 1673 The nonce MUST be carried from SMR packet, into the resultant Map- 1674 Request, and then into Map-Reply to reduce spoofing attacks. 1676 7. Router Performance Considerations 1678 LISP is designed to be very hardware-based forwarding friendly. By 1679 doing tunnel header prepending [RFC1955] and stripping instead of re- 1680 writing addresses, existing hardware can support the forwarding model 1681 with little or no modification. Where modifications are required, 1682 they should be limited to re-programming existing hardware rather 1683 than requiring expensive design changes to hard-coded algorithms in 1684 silicon. 1686 A few implementation techniques can be used to incrementally 1687 implement LISP: 1689 o When a tunnel encapsulated packet is received by an ETR, the outer 1690 destination address may not be the address of the router. This 1691 makes it challenging for the control plane to get packets from the 1692 hardware. This may be mitigated by creating special FIB entries 1693 for the EID-prefixes of EIDs served by the ETR (those for which 1694 the router provides an RLOC translation). These FIB entries are 1695 marked with a flag indicating that control plane processing should 1696 be performed. The forwarding logic of testing for particular IP 1697 protocol number value is not necessary. No changes to existing, 1698 deployed hardware should be needed to support this. 1700 o On an ITR, prepending a new IP header is as simple as adding more 1701 bytes to a MAC rewrite string and prepending the string as part of 1702 the outgoing encapsulation procedure. Many routers that support 1703 GRE tunneling [RFC2784] or 6to4 tunneling [RFC3056] can already 1704 support this action. 1706 o When a received packet's outer destination address contains an EID 1707 which is not intended to be forwarded on the routable topology 1708 (i.e. LISP 1.5), the source address of a data packet or the 1709 router interface with which the source is associated (the 1710 interface from which it was received) can be associated with a VRF 1711 (Virtual Routing/Forwarding), in which a different (i.e. non- 1712 congruent) topology can be used to find EID-to-RLOC mappings. 1714 8. Deployment Scenarios 1716 This section will explore how and where ITRs and ETRs can be deployed 1717 and will discuss the pros and cons of each deployment scenario. 1718 There are two basic deployment trade-offs to consider: centralized 1719 versus distributed caches and flat, recursive, or re-encapsulating 1720 tunneling. 1722 When deciding on centralized versus distributed caching, the 1723 following issues should be considered: 1725 o Are the tunnel routers spread out so that the caches are spread 1726 across all the memories of each router? 1728 o Should management "touch points" be minimized by choosing few 1729 tunnel routers, just enough for redundancy? 1731 o In general, using more ITRs doesn't increase management load, 1732 since caches are built and stored dynamically. On the other hand, 1733 more ETRs does require more management since EID-prefix-to-RLOC 1734 mappings need to be explicitly configured. 1736 When deciding on flat, recursive, or re-encapsulation tunneling, the 1737 following issues should be considered: 1739 o Flat tunneling implements a single tunnel between source site and 1740 destination site. This generally offers better paths between 1741 sources and destinations with a single tunnel path. 1743 o Recursive tunneling is when tunneled traffic is again further 1744 encapsulated in another tunnel, either to implement VPNs or to 1745 perform Traffic Engineering. When doing VPN-based tunneling, the 1746 site has some control since the site is prepending a new tunnel 1747 header. In the case of TE-based tunneling, the site may have 1748 control if it is prepending a new tunnel header, but if the site's 1749 ISP is doing the TE, then the site has no control. Recursive 1750 tunneling generally will result in suboptimal paths but at the 1751 benefit of steering traffic to resource available parts of the 1752 network. 1754 o The technique of re-encapsulation ensures that packets only 1755 require one tunnel header. So if a packet needs to be rerouted, 1756 it is first decapsulated by the ETR and then re-encapsulated with 1757 a new tunnel header using a new RLOC. 1759 The next sub-sections will describe where tunnel routers can reside 1760 in the network. 1762 8.1. First-hop/Last-hop Tunnel Routers 1764 By locating tunnel routers close to hosts, the EID-prefix set is at 1765 the granularity of an IP subnet. So at the expense of more EID- 1766 prefix-to-RLOC sets for the site, the caches in each tunnel router 1767 can remain relatively small. But caches always depend on the number 1768 of non-aggregated EID destination flows active through these tunnel 1769 routers. 1771 With more tunnel routers doing encapsulation, the increase in control 1772 traffic grows as well: since the EID-granularity is greater, more 1773 Map-Requests and Map-Replies are traveling between more routers. 1775 The advantage of placing the caches and databases at these stub 1776 routers is that the products deployed in this part of the network 1777 have better price-memory ratios then their core router counterparts. 1778 Memory is typically less expensive in these devices and fewer routes 1779 are stored (only IGP routes). These devices tend to have excess 1780 capacity, both for forwarding and routing state. 1782 LISP functionality can also be deployed in edge switches. These 1783 devices generally have layer-2 ports facing hosts and layer-3 ports 1784 facing the Internet. Spare capacity is also often available in these 1785 devices as well. 1787 8.2. Border/Edge Tunnel Routers 1789 Using customer-edge (CE) routers for tunnel endpoints allows the EID 1790 space associated with a site to be reachable via a small set of RLOCs 1791 assigned to the CE routers for that site. 1793 This offers the opposite benefit of the first-hop/last-hop tunnel 1794 router scenario: the number of mapping entries and network management 1795 touch points are reduced, allowing better scaling. 1797 One disadvantage is that less of the network's resources are used to 1798 reach host endpoints thereby centralizing the point-of-failure domain 1799 and creating network choke points at the CE router. 1801 Note that more than one CE router at a site can be configured with 1802 the same IP address. In this case an RLOC is an anycast address. 1803 This allows resilience between the CE routers. That is, if a CE 1804 router fails, traffic is automatically routed to the other routers 1805 using the same anycast address. However, this comes with the 1806 disadvantage where the site cannot control the entrance point when 1807 the anycast route is advertised out from all border routers. 1809 8.3. ISP Provider-Edge (PE) Tunnel Routers 1811 Use of ISP PE routers as tunnel endpoint routers gives an ISP control 1812 over the location of the egress tunnel endpoints. That is, the ISP 1813 can decide if the tunnel endpoints are in the destination site (in 1814 either CE routers or last-hop routers within a site) or at other PE 1815 edges. The advantage of this case is that two or more tunnel headers 1816 can be avoided. By having the PE be the first router on the path to 1817 encapsulate, it can choose a TE path first, and the ETR can 1818 decapsulate and re-encapsulate for a tunnel to the destination end 1819 site. 1821 An obvious disadvantage is that the end site has no control over 1822 where its packets flow or the RLOCs used. 1824 As mentioned in earlier sections a combination of these scenarios is 1825 possible at the expense of extra packet header overhead, if both site 1826 and provider want control, then recursive or re-encapsulating tunnels 1827 are used. 1829 9. Traceroute Considerations 1831 When a source host in a LISP site initiates a traceroute to a 1832 destination host in another LISP site, it is highly desirable for it 1833 to see the entire path. Since packets are encapsulated from ITR to 1834 ETR, the hop across the tunnel could be viewed as a single hop. 1835 However, LISP traceroute will provide the entire path so the user can 1836 see 3 distinct segments of the path from a source LISP host to a 1837 destination LISP host: 1839 Segment 1 (in source LISP site based on EIDs): 1841 source-host ---> first-hop ... next-hop ---> ITR 1843 Segment 2 (in the core network based on RLOCs): 1845 ITR ---> next-hop ... next-hop ---> ETR 1847 Segment 3 (in the destination LISP site based on EIDs): 1849 ETR ---> next-hop ... last-hop ---> destination-host 1851 For segment 1 of the path, ICMP Time Exceeded messages are returned 1852 in the normal matter as they are today. The ITR performs a TTL 1853 decrement and test for 0 before encapsulating. So the ITR hop is 1854 seen by the traceroute source has an EID address (the address of 1855 site-facing interface). 1857 For segment 2 of the path, ICMP Time Exceeded messages are returned 1858 to the ITR because the TTL decrement to 0 is done on the outer 1859 header, so the destination of the ICMP messages are to the ITR RLOC 1860 address, the source source RLOC address of the encapsulated 1861 traceroute packet. The ITR looks inside of the ICMP payload to 1862 inspect the traceroute source so it can return the ICMP message to 1863 the address of the traceroute client as well as retaining the core 1864 router IP address in the ICMP message. This is so the traceroute 1865 client can display the core router address (the RLOC address) in the 1866 traceroute output. The ETR returns its RLOC address and responds to 1867 the TTL decrement to 0 like the previous core routers did. 1869 For segment 3, the next-hop router downstream from the ETR will be 1870 decrementing the TTL for the packet that was encapsulated, sent into 1871 the core, decapsulated by the ETR, and forwarded because it isn't the 1872 final destination. If the TTL is decremented to 0, any router on the 1873 path to the destination of the traceroute, including the next-hop 1874 router or destination, will send an ICMP Time Exceeded message to the 1875 source EID of the traceroute client. The ICMP message will be 1876 encapsulated by the local ITR and sent back to the ETR in the 1877 originated traceroute source site, where the packet will be delivered 1878 to the host. 1880 9.1. IPv6 Traceroute 1882 IPv6 traceroute follows the procedure described above since the 1883 entire traceroute data packet is included in ICMP Time Exceeded 1884 message payload. Therefore, only the ITR needs to pay special 1885 attention for forwarding ICMP messages back to the traceroute source. 1887 9.2. IPv4 Traceroute 1889 For IPv4 traceroute, we cannot follow the above procedure since IPv4 1890 ICMP Time Exceeded messages only include the invoking IP header and 8 1891 bytes that follow the IP header. Therefore, when a core router sends 1892 an IPv4 Time Exceeded message to an ITR, all the ITR has in the ICMP 1893 payload is the encapsulated header it prepended followed by a UDP 1894 header. The original invoking IP header, and therefore the identity 1895 of the traceroute source is lost. 1897 The solution we propose to solve this problem is to cache traceroute 1898 IPv4 headers in the ITR and to match them up with corresponding IPv4 1899 Time Exceeded messages received from core routers and the ETR. The 1900 ITR will use a circular buffer for caching the IPv4 and UDP headers 1901 of traceroute packets. It will select a 16-bit number as a key to 1902 find them later when the IPv4 Time Exceeded messages are received. 1903 When an ITR encapsulates an IPv4 traceroute packet, it will use the 1904 16-bit number as the UDP source port in the encapsulating header. 1905 When the ICMP Time Exceeded message is returned to the ITR, the UDP 1906 header of the encapsulating header is present in the ICMP payload 1907 thereby allowing the ITR to find the cached headers for the 1908 traceroute source. The ITR puts the cached headers in the payload 1909 and sends the ICMP Time Exceeded message to the traceroute source 1910 retaining the source address of the original ICMP Time Exceeded 1911 message (a core router or the ETR of the site of the traceroute 1912 destination). 1914 9.3. Traceroute using Mixed Locators 1916 When either an IPv4 traceroute or IPv6 traceroute is originated and 1917 the ITR encapsulates it in the other address family header, you 1918 cannot get all 3 segments of the traceroute. Segment 2 of the 1919 traceroute can not be conveyed to the traceroute source since it is 1920 expecting addresses from intermediate hops in the same address format 1921 for the type of traceroute it originated. Therefore, in this case, 1922 segment 2 will make the tunnel look like one hop. All the ITR has to 1923 do to make this work is to not copy the inner TTL to the outer, 1924 encapsulating header's TTL when a traceroute packet is encapsulated 1925 using an RLOC from a different address family. This will cause no 1926 TTL decrement to 0 to occur in core routers between the ITR and ETR. 1928 10. Mobility Considerations 1930 There are several kinds of mobility of which only some might be of 1931 concern to LISP. Essentially they are as follows. 1933 10.1. Site Mobility 1935 A site wishes to change its attachment points to the Internet, and 1936 its LISP Tunnel Routers will have new RLOCs when it changes upstream 1937 providers. Changes in EID-RLOC mappings for sites are expected to be 1938 handled by configuration, outside of the LISP protocol. 1940 10.2. Slow Endpoint Mobility 1942 An individual endpoint wishes to move, but is not concerned about 1943 maintaining session continuity. Renumbering is involved. LISP can 1944 help with the issues surrounding renumbering [RFC4192] [LISA96] by 1945 decoupling the address space used by a site from the address spaces 1946 used by its ISPs. [RFC4984] 1948 10.3. Fast Endpoint Mobility 1950 Fast endpoint mobility occurs when an endpoint moves relatively 1951 rapidly, changing its IP layer network attachment point. Maintenance 1952 of session continuity is a goal. This is where the Mobile IPv4 1953 [RFC3344bis] and Mobile IPv6 [RFC3775] [RFC4866] mechanisms are used, 1954 and primarily where interactions with LISP need to be explored. 1956 The problem is that as an endpoint moves, it may require changes to 1957 the mapping between its EID and a set of RLOCs for its new network 1958 location. When this is added to the overhead of mobile IP binding 1959 updates, some packets might be delayed or dropped. 1961 In IPv4 mobility, when an endpoint is away from home, packets to it 1962 are encapsulated and forwarded via a home agent which resides in the 1963 home area the endpoint's address belongs to. The home agent will 1964 encapsulate and forward packets either directly to the endpoint or to 1965 a foreign agent which resides where the endpoint has moved to. 1966 Packets from the endpoint may be sent directly to the correspondent 1967 node, may be sent via the foreign agent, or may be reverse-tunneled 1968 back to the home agent for delivery to the mobile node. As the 1969 mobile node's EID or available RLOC changes, LISP EID-to-RLOC 1970 mappings are required for communication between the mobile node and 1971 the home agent, whether via foreign agent or not. As a mobile 1972 endpoint changes networks, up to three LISP mapping changes may be 1973 required: 1975 o The mobile node moves from an old location to a new visited 1976 network location and notifies its home agent that it has done so. 1977 The Mobile IPv4 control packets the mobile node sends pass through 1978 one of the new visited network's ITRs, which needs a EID-RLOC 1979 mapping for the home agent. 1981 o The home agent might not have the EID-RLOC mappings for the mobile 1982 node's "care-of" address or its foreign agent in the new visited 1983 network, in which case it will need to acquire them. 1985 o When packets are sent directly to the correspondent node, it may 1986 be that no traffic has been sent from the new visited network to 1987 the correspondent node's network, and the new visited network's 1988 ITR will need to obtain an EID-RLOC mapping for the correspondent 1989 node's site. 1991 In addition, if the IPv4 endpoint is sending packets from the new 1992 visited network using its original EID, then LISP will need to 1993 perform a route-returnability check on the new EID-RLOC mapping for 1994 that EID. 1996 In IPv6 mobility, packets can flow directly between the mobile node 1997 and the correspondent node in either direction. The mobile node uses 1998 its "care-of" address (EID). In this case, the route-returnability 1999 check would not be needed but one more LISP mapping lookup may be 2000 required instead: 2002 o As above, three mapping changes may be needed for the mobile node 2003 to communicate with its home agent and to send packets to the 2004 correspondent node. 2006 o In addition, another mapping will be needed in the correspondent 2007 node's ITR, in order for the correspondent node to send packets to 2008 the mobile node's "care-of" address (EID) at the new network 2009 location. 2011 When both endpoints are mobile the number of potential mapping 2012 lookups increases accordingly. 2014 As a mobile node moves there are not only mobility state changes in 2015 the mobile node, correspondent node, and home agent, but also state 2016 changes in the ITRs and ETRs for at least some EID-prefixes. 2018 The goal is to support rapid adaptation, with little delay or packet 2019 loss for the entire system. Heuristics can be added to LISP to 2020 reduce the number of mapping changes required and to reduce the delay 2021 per mapping change. Also IP mobility can be modified to require 2022 fewer mapping changes. In order to increase overall system 2023 performance, there may be a need to reduce the optimization of one 2024 area in order to place fewer demands on another. 2026 In LISP, one possibility is to "glean" information. When a packet 2027 arrives, the ETR could examine the EID-RLOC mapping and use that 2028 mapping for all outgoing traffic to that EID. It can do this after 2029 performing a route-returnability check, to ensure that the new 2030 network location does have a internal route to that endpoint. 2031 However, this does not cover the case where an ITR (the node assigned 2032 the RLOC) at the mobile-node location has been compromised. 2034 Mobile IP packet exchange is designed for an environment in which all 2035 routing information is disseminated before packets can be forwarded. 2036 In order to allow the Internet to grow to support expected future 2037 use, we are moving to an environment where some information may have 2038 to be obtained after packets are in flight. Modifications to IP 2039 mobility should be considered in order to optimize the behavior of 2040 the overall system. Anything which decreases the number of new EID- 2041 RLOC mappings needed when a node moves, or maintains the validity of 2042 an EID-RLOC mapping for a longer time, is useful. 2044 10.4. Fast Network Mobility 2046 In addition to endpoints, a network can be mobile, possibly changing 2047 xTRs. A "network" can be as small as a single router and as large as 2048 a whole site. This is different from site mobility in that it is 2049 fast and possibly short-lived, but different from endpoint mobility 2050 in that a whole prefix is changing RLOCs. However, the mechanisms 2051 are the same and there is no new overhead in LISP. A map request for 2052 any endpoint will return a binding for the entire mobile prefix. 2054 If mobile networks become a more common occurrence, it may be useful 2055 to revisit the design of the mapping service and allow for dynamic 2056 updates of the database. 2058 The issue of interactions between mobility and LISP needs to be 2059 explored further. Specific improvements to the entire system will 2060 depend on the details of mapping mechanisms. Mapping mechanisms 2061 should be evaluated on how well they support session continuity for 2062 mobile nodes. 2064 11. Multicast Considerations 2066 A multicast group address, as defined in the original Internet 2067 architecture is an identifier of a grouping of topologically 2068 independent receiver host locations. The address encoding itself 2069 does not determine the location of the receiver(s). The multicast 2070 routing protocol, and the network-based state the protocol creates, 2071 determines where the receivers are located. 2073 In the context of LISP, a multicast group address is both an EID and 2074 a Routing Locator. Therefore, no specific semantic or action needs 2075 to be taken for a destination address, as it would appear in an IP 2076 header. Therefore, a group address that appears in an inner IP 2077 header built by a source host will be used as the destination EID. 2078 The outer IP header (the destination Routing Locator address), 2079 prepended by a LISP router, will use the same group address as the 2080 destination Routing Locator. 2082 Having said that, only the source EID and source Routing Locator 2083 needs to be dealt with. Therefore, an ITR merely needs to put its 2084 own IP address in the source Routing Locator field when prepending 2085 the outer IP header. This source Routing Locator address, like any 2086 other Routing Locator address MUST be globally routable. 2088 Therefore, an EID-to-RLOC mapping does not need to be performed by an 2089 ITR when a received data packet is a multicast data packet or when 2090 processing a source-specific Join (either by IGMPv3 or PIM). But the 2091 source Routing Locator is decided by the multicast routing protocol 2092 in a receiver site. That is, an EID to Routing Locator translation 2093 is done at control-time. 2095 Another approach is to have the ITR not encapsulate a multicast 2096 packet and allow the the host built packet to flow into the core even 2097 if the source address is allocated out of the EID namespace. If the 2098 RPF-Vector TLV [RPFV] is used by PIM in the core, then core routers 2099 can RPF to the ITR (the Locator address which is injected into core 2100 routing) rather than the host source address (the EID address which 2101 is not injected into core routing). 2103 To avoid any EID-based multicast state in the network core, the first 2104 approach is chosen for LISP-Multicast. Details for LISP-Multicast 2105 and Interworking with non-LISP sites is described in specification 2106 [MLISP]. 2108 12. Security Considerations 2110 It is believed that most of the security mechanisms will be part of 2111 the mapping database service when using control plane procedures for 2112 obtaining EID-to-RLOC mappings. For data plane triggered mappings, 2113 as described in this specification, protection is provided against 2114 ETR spoofing by using Return- Routability mechanisms evidenced by the 2115 use of a 4-byte Nonce field in the LISP encapsulation header. The 2116 nonce, coupled with the ITR accepting only solicited Map-Replies goes 2117 a long way toward providing decent authentication. 2119 LISP does not rely on a PKI infrastructure or a more heavy weight 2120 authentication system. These systems challenge the scalability of 2121 LISP which was a primary design goal. 2123 DoS attack prevention will depend on implementations rate-limiting 2124 Map-Requests and Map-Replies to the control plane as well as rate- 2125 limiting the number of data-triggered Map-Replies. 2127 To deal with map-cache exhaustion attempts in an ITR/PTR, the 2128 implementation should consider putting a maximum cap on the number of 2129 entries stored with a reserve list for special or frequently accessed 2130 sites. This should be a configuration policy control set by the 2131 network administrator who manages ITRs and PTRs. 2133 13. Prototype Plans and Status 2135 The operator community has requested that the IETF take a practical 2136 approach to solving the scaling problems associated with global 2137 routing state growth. This document offers a simple solution which 2138 is intended for use in a pilot program to gain experience in working 2139 on this problem. 2141 The authors hope that publishing this specification will allow the 2142 rapid implementation of multiple vendor prototypes and deployment on 2143 a small scale. Doing this will help the community: 2145 o Decide whether a new EID-to-RLOC mapping database infrastructure 2146 is needed or if a simple, UDP-based, data-triggered approach is 2147 flexible and robust enough. 2149 o Experiment with provider-independent assignment of EIDs while at 2150 the same time decreasing the size of DFZ routing tables through 2151 the use of topologically-aligned, provider-based RLOCs. 2153 o Determine whether multiple levels of tunneling can be used by ISPs 2154 to achieve their Traffic Engineering goals while simultaneously 2155 removing the more specific routes currently injected into the 2156 global routing system for this purpose. 2158 o Experiment with mobility to determine if both acceptable 2159 convergence and session continuity properties can be scalably 2160 implemented to support both individual device roaming and site 2161 service provider changes. 2163 Here is a rough set of milestones: 2165 1. This draft will be the draft for interoperable implementations to 2166 code against. Interoperable implementations will be ready 2167 beginning of 2009. 2169 2. Continue pilot deployment using LISP-ALT as the database mapping 2170 mechanism. 2172 3. Continue prototyping and studying other database lookup schemes, 2173 be it DNS, DHTs, CONS, ALT, NERD, or other mechanisms. 2175 4. Implement the LISP Multicast draft [MLISP]. 2177 5. Research more on how policy affects what gets returned in a Map- 2178 Reply from an ETR. 2180 6. Continue to experiment with mixed locator-sets to understand how 2181 LISP can help the IPv4 to IPv6 transition. 2183 7. Add more robustness to locator reachability between LISP sites. 2185 As of this writing the following accomplishments have been achieved: 2187 1. A unit- and system-tested software switching implementation has 2188 been completed on cisco NX-OS for this draft for both IPv4 and 2189 IPv6 EIDs using a mixed locator-set of IPv4 and IPv6 locators. 2191 2. A unit- and system-tested software switching implementation on 2192 cisco NX-OS has been completed for draft [ALT]. 2194 3. A unit- and system-tested software switching implementation on 2195 cisco NX-OS has been completed for draft [INTERWORK]. Support 2196 for IPv4 translation is provided and PTR support for IPv4 and 2197 IPv6 is provided. 2199 4. The cisco NX-OS implementation supports an experimental 2200 mechanism for slow mobility. 2202 5. Dave Meyer, Vince Fuller, Darrel Lewis, Greg Shepherd, and 2203 Andrew Partan continue to test all the features described above 2204 on a dual-stack infrastructure. 2206 6. Darrel Lewis and Dave Meyer have deployed both LISP translation 2207 and LISP PTR support in the pilot network. Point your browser 2208 to http://www.lisp4.net to see translation happening in action 2209 so your non-LISP site can access a web server in a LISP site. 2211 7. Soon http://www.lisp6.net will work where your IPv6 LISP site 2212 can talk to a IPv6 web server in a LISP site by using mixed 2213 address-family based locators. 2215 8. An public domain implementation of LISP is underway. See 2216 [OPENLISP] for details. 2218 9. We have deployed Map-Resolvers and Map-Servers on the LISP pilot 2219 network to gather experience with [LISP-MS]. The first layer of 2220 the architecture are the xTRs which use Map-Servers for EID- 2221 prefix registration and Map-Resolvers for EID-to-RLOC mapping 2222 resolution. The second layer are the Map-Resolvers and Map- 2223 Servers which connect to the ALT BGP peering infrastructure. 2224 And the third layer are ALT-routers which aggregate EID-prefixes 2225 and forward Map-Requests. 2227 10. A cisco IOS implementation is underway which currently supports 2228 IPv4 encapsulation and decapsulation features. 2230 11. A LISP router based LIG implementation is supported, deployed, 2231 and used daily to debug and test the LISP pilot network. See 2232 [LIG] for details. 2234 12. A Linux implementation of LIG has been made available and 2235 supported by Dave Meyer. It can be run on any Linux system 2236 which resides in either a LISP site or non-LISP site. See [LIG] 2237 for details. 2239 If interested in writing a LISP implementation, testing any of the 2240 LISP implementations, or want to be part of the LISP pilot program, 2241 please contact lisp@ietf.org. 2243 14. References 2245 14.1. Normative References 2247 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2248 August 1980. 2250 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 2251 November 1990. 2253 [RFC1498] Saltzer, J., "On the Naming and Binding of Network 2254 Destinations", RFC 1498, August 1993. 2256 [RFC1955] Hinden, R., "New Scheme for Internet Routing and 2257 Addressing (ENCAPS) for IPNG", RFC 1955, June 1996. 2259 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2260 Requirement Levels", BCP 14, RFC 2119, March 1997. 2262 [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", 2263 RFC 2402, November 1998. 2265 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2266 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 2267 October 1998. 2269 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 2270 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 2271 March 2000. 2273 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 2274 via IPv4 Clouds", RFC 3056, February 2001. 2276 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 2277 of Explicit Congestion Notification (ECN) to IP", 2278 RFC 3168, September 2001. 2280 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 2281 in IPv6", RFC 3775, June 2004. 2283 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 2284 (HIP) Architecture", RFC 4423, May 2006. 2286 [RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route 2287 Optimization for Mobile IPv6", RFC 4866, May 2007. 2289 [RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB 2290 Workshop on Routing and Addressing", RFC 4984, 2291 September 2007. 2293 14.2. Informative References 2295 [AFI] IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY 2296 NUMBERS http://www.iana.org/numbers.html, Febuary 2007. 2298 [ALT] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP 2299 Alternative Topology (LISP-ALT)", 2300 draft-ietf-lisp-alt-01.txt (work in progress), May 2009. 2302 [APT] Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and 2303 L. Zhang, "APT: A Practical Transit Mapping Service", 2304 draft-jen-apt-01.txt (work in progress), November 2007. 2306 [CHIAPPA] Chiappa, J., "Endpoints and Endpoint names: A Proposed 2307 Enhancement to the Internet Architecture", Internet- 2308 Draft http://www.chiappa.net/~jnc/tech/endpoints.txt, 2309 1999. 2311 [CONS] Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A 2312 Content distribution Overlay Network Service for LISP", 2313 draft-meyer-lisp-cons-03.txt (work in progress), 2314 November 2007. 2316 [DHTs] Ratnasamy, S., Shenker, S., and I. Stoica, "Routing 2317 Algorithms for DHTs: Some Open Questions", PDF 2318 file http://www.cs.rice.edu/Conferences/IPTPS02/174.pdf. 2320 [GSE] "GSE - An Alternate Addressing Architecture for IPv6", 2321 draft-ietf-ipngwg-gseaddr-00.txt (work in progress), 1997. 2323 [INTERWORK] 2324 Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 2325 "Interworking LISP with IPv4 and IPv6", 2326 draft-ietf-lisp-interworking-00.txt (work in progress), 2327 January 2009. 2329 [LIG] Farinacci, D. and D. Meyer, "LISP Internet Groper (LIG)", 2330 draft-farinacci-lisp-lig-01.txt (work in progress), 2331 May 2009. 2333 [LISA96] Lear, E., Katinsky, J., Coffin, J., and D. Tharp, 2334 "Renumbering: Threat or Menace?", Usenix , September 1996. 2336 [LISP-MAIN] 2337 Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 2338 "Locator/ID Separation Protocol (LISP)", 2339 draft-farinacci-lisp-12.txt (work in progress), 2340 March 2009. 2342 [LISP-MS] Farinacci, D. and V. Fuller, "LISP Map Server", 2343 draft-ietf-lisp-ms-01.txt (work in progress), May 2009. 2345 [LISP1] Farinacci, D., Oran, D., Fuller, V., and J. Schiller, 2346 "Locator/ID Separation Protocol (LISP1) [Routable ID 2347 Version]", 2348 Slide-set http://www.dinof.net/~dino/ietf/lisp1.ppt, 2349 October 2006. 2351 [LISP2] Farinacci, D., Oran, D., Fuller, V., and J. Schiller, 2352 "Locator/ID Separation Protocol (LISP2) [DNS-based 2353 Version]", 2354 Slide-set http://www.dinof.net/~dino/ietf/lisp2.ppt, 2355 November 2006. 2357 [LISPDHT] Mathy, L., Iannone, L., and O. Bonaventure, "LISP-DHT: 2358 Towards a DHT to map identifiers onto locators", 2359 draft-mathy-lisp-dht-00.txt (work in progress), 2360 February 2008. 2362 [LOC-ID-ARCH] 2363 Meyer, D. and D. Lewis, "Architectural Implications of 2364 Locator/ID Separation", 2365 draft-meyer-loc-id-implications-01.txt (work in progress), 2366 Januaryr 2009. 2368 [MLISP] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, 2369 "LISP for Multicast Environments", 2370 draft-ietf-lisp-multicast-01.txt (work in progress), 2371 May 2009. 2373 [NERD] Lear, E., "NERD: A Not-so-novel EID to RLOC Database", 2374 draft-lear-lisp-nerd-04.txt (work in progress), 2375 April 2008. 2377 [OPENLISP] 2378 Iannone, L. and O. Bonaventure, "OpenLISP Implementation 2379 Report", draft-iannone-openlisp-implementation-01.txt 2380 (work in progress), July 2008. 2382 [RADIR] Narten, T., "Routing and Addressing Problem Statement", 2383 draft-narten-radir-problem-statement-00.txt (work in 2384 progress), July 2007. 2386 [RFC3344bis] 2387 Perkins, C., "IP Mobility Support for IPv4, revised", 2388 draft-ietf-mip4-rfc3344bis-05 (work in progress), 2389 July 2007. 2391 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 2392 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 2393 September 2005. 2395 [RPFV] Wijnands, IJ., Boers, A., and E. Rosen, "The RPF Vector 2396 TLV", draft-ietf-pim-rpf-vector-08.txt (work in progress), 2397 January 2009. 2399 [RPMD] Handley, M., Huici, F., and A. Greenhalgh, "RPMD: Protocol 2400 for Routing Protocol Meta-data Dissemination", 2401 draft-handley-p2ppush-unpublished-2007726.txt (work in 2402 progress), July 2007. 2404 [SHIM6] Nordmark, E. and M. Bagnulo, "Level 3 multihoming shim 2405 protocol", draft-ietf-shim6-proto-06.txt (work in 2406 progress), October 2006. 2408 Appendix A. Acknowledgments 2410 An initial thank you goes to Dave Oran for planting the seeds for the 2411 initial ideas for LISP. His consultation continues to provide value 2412 to the LISP authors. 2414 A special and appreciative thank you goes to Noel Chiappa for 2415 providing architectural impetus over the past decades on separation 2416 of location and identity, as well as detailed review of the LISP 2417 architecture and documents, coupled with enthusiasm for making LISP a 2418 practical and incremental transition for the Internet. 2420 The authors would like to gratefully acknowledge many people who have 2421 contributed discussion and ideas to the making of this proposal. 2422 They include Scott Brim, Andrew Partan, John Zwiebel, Jason Schiller, 2423 Lixia Zhang, Dorian Kim, Peter Schoenmaker, Vijay Gill, Geoff Huston, 2424 David Conrad, Mark Handley, Ron Bonica, Ted Seely, Mark Townsley, 2425 Chris Morrow, Brian Weis, Dave McGrew, Peter Lothberg, Dave Thaler, 2426 Eliot Lear, Shane Amante, Ved Kafle, Olivier Bonaventure, Luigi 2427 Iannone, Robin Whittle, Brian Carpenter, Joel Halpern, Roger 2428 Jorgensen, Ran Atkinson, Stig Venaas, Iljitsch van Beijnum, Roland 2429 Bless, Dana Blair, Bill Lynch, Marc Woolward, Damien Saucez, Damian 2430 Lezama, Attilla De Groot, Parantap Lahiri, and David Black. 2432 In particular, we would like to thank Dave Meyer for his clever 2433 suggestion for the name "LISP". ;-) 2435 This work originated in the Routing Research Group (RRG) of the IRTF. 2436 The individual submission [LISP-MAIN] was converted into this IETF 2437 LISP working group draft. 2439 Authors' Addresses 2441 Dino Farinacci 2442 cisco Systems 2443 Tasman Drive 2444 San Jose, CA 95134 2445 USA 2447 Email: dino@cisco.com 2449 Vince Fuller 2450 cisco Systems 2451 Tasman Drive 2452 San Jose, CA 95134 2453 USA 2455 Email: vaf@cisco.com 2457 Dave Meyer 2458 cisco Systems 2459 170 Tasman Drive 2460 San Jose, CA 2461 USA 2463 Email: dmm@cisco.com 2465 Darrel Lewis 2466 cisco Systems 2467 170 Tasman Drive 2468 San Jose, CA 2469 USA 2471 Email: darlewis@cisco.com