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