idnits 2.17.1 draft-farinacci-lisp-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1830. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1841. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1848. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1854. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 5 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: UDP Checksum: this field field MUST be transmitted as 0 and ignored on receipt by the ETR. Note, even when the UDP checksum is transmitted as 0 an intervening NAT device can recalculate the checksum and rewrite the UDP checksum field to non-zero. For performance reasons, the ETR MUST ignore the checksum and MUST not do a checksum computation. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 28, 2008) is 5835 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4423 (Obsoleted by RFC 9063) == Outdated reference: A later version (-05) exists of draft-fuller-lisp-alt-01 == Outdated reference: A later version (-01) exists of draft-jen-apt-00 == Outdated reference: A later version (-04) exists of draft-meyer-lisp-cons-03 == Outdated reference: A later version (-02) exists of draft-lewis-lisp-interworking-00 -- No information found for draft-mathy-lisp-dht - is the name correct? == Outdated reference: A later version (-01) exists of draft-farinacci-lisp-multicast-00 == Outdated reference: A later version (-09) exists of draft-lear-lisp-nerd-02 == Outdated reference: A later version (-01) exists of draft-iannone-openlisp-implementation-00 == Outdated reference: A later version (-05) exists of draft-narten-radir-problem-statement-00 == Outdated reference: A later version (-10) exists of draft-ietf-mip4-rfc3344bis-05 == Outdated reference: A later version (-08) exists of draft-ietf-pim-rpf-vector-03 -- No information found for draft-handley-p2ppush-unpublished-2007726 - is the name correct? == Outdated reference: A later version (-12) exists of draft-ietf-shim6-proto-06 Summary: 5 errors (**), 0 flaws (~~), 14 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Farinacci 3 Internet-Draft V. Fuller 4 Intended status: Experimental D. Oran 5 Expires: October 30, 2008 D. Meyer 6 cisco Systems 7 April 28, 2008 9 Locator/ID Separation Protocol (LISP) 10 draft-farinacci-lisp-07.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on October 30, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 This draft describes a simple, incremental, network-based protocol to 44 implement separation of Internet addresses into Endpoint Identifiers 45 (EIDs) and Routing Locators (RLOCs). This mechanism requires no 46 changes to host stacks and no major changes to existing database 47 infrastructures. The proposed protocol can be implemented in a 48 relatively small number of routers. 50 This proposal was stimulated by the problem statement effort at the 51 Amsterdam IAB Routing and Addressing Workshop (RAWS), which took 52 place in October 2006. 54 Table of Contents 56 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 57 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 8 59 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 12 60 4.1. Packet Flow Sequence . . . . . . . . . . . . . . . . . . . 13 61 5. Tunneling Details . . . . . . . . . . . . . . . . . . . . . . 16 62 5.1. LISP IPv4-in-IPv4 Header Format . . . . . . . . . . . . . 17 63 5.2. LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 18 64 5.3. Tunnel Header Field Descriptions . . . . . . . . . . . . . 19 65 5.4. Dealing with Large Encapsulated Packets . . . . . . . . . 20 66 6. EID-to-RLOC Mapping . . . . . . . . . . . . . . . . . . . . . 22 67 6.1. Control-Plane Packet Format . . . . . . . . . . . . . . . 22 68 6.1.1. LISP Packet Type Allocations . . . . . . . . . . . . . 24 69 6.1.2. Map-Request Message Format . . . . . . . . . . . . . . 24 70 6.1.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . 25 71 6.1.4. Map-Reply Message Format . . . . . . . . . . . . . . . 26 72 6.1.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . 28 73 6.2. Routing Locator Selection . . . . . . . . . . . . . . . . 29 74 6.3. Routing Locator Reachability . . . . . . . . . . . . . . . 30 75 7. Router Performance Considerations . . . . . . . . . . . . . . 33 76 8. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 34 77 8.1. First-hop/Last-hop Tunnel Routers . . . . . . . . . . . . 35 78 8.2. Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 35 79 8.3. ISP Provider-Edge (PE) Tunnel Routers . . . . . . . . . . 36 80 9. Mobility Considerations . . . . . . . . . . . . . . . . . . . 37 81 9.1. Site Mobility . . . . . . . . . . . . . . . . . . . . . . 37 82 9.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 37 83 9.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 37 84 9.4. Fast Network Mobility . . . . . . . . . . . . . . . . . . 39 85 10. Multicast Considerations . . . . . . . . . . . . . . . . . . . 40 86 11. Security Considerations . . . . . . . . . . . . . . . . . . . 41 87 12. Prototype Plans and Status . . . . . . . . . . . . . . . . . . 42 88 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 89 13.1. Normative References . . . . . . . . . . . . . . . . . . . 44 90 13.2. Informative References . . . . . . . . . . . . . . . . . . 44 91 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 47 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48 93 Intellectual Property and Copyright Statements . . . . . . . . . . 49 95 1. Requirements Notation 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC2119]. 101 2. Introduction 103 Many years of discussion about the current IP routing and addressing 104 architecture have noted that its use of a single numbering space (the 105 "IP address") for both host transport session identification and 106 network routing creates scaling issues (see [CHIAPPA] and [RFC1498]). 107 A number of scaling benefits would be realized by separating the 108 current IP address into separate spaces for Endpoint Identifiers 109 (EIDs) and Routing Locators (RLOCs); among them are: 111 1. Reduction of routing table size in the "default-free zone" (DFZ). 112 Use of a separate numbering space for RLOCs will allow them to be 113 assigned topologically (in today's Internet, RLOCs would be 114 assigned by providers at client network attachment points), 115 greatly improving aggregation and reducing the number of 116 globally-visible, routable prefixes. 118 2. Easing of renumbering burden when clients change providers. 119 Because host EIDs are numbered from a separate, non-provider- 120 assigned and non-topologically-bound space, they do not need to 121 be renumbered when a client site changes its attachment points to 122 the network. 124 3. Traffic engineering capabilities that can be performed by network 125 elements and do not depend on injecting additional state into the 126 routing system. This will fall out of the mechanism that is used 127 to implement the EID/RLOC split (see Section 4). 129 4. Mobility without address changing. Existing mobility mechanisms 130 will be able to work in a locator/ID separation scenario. It 131 will be possible for a host (or a collection of hosts) to move to 132 a different point in the network topology either retaining its 133 home-based address or acquiring a new address based on the new 134 network location. A new network location could be a physically 135 different point in the network topology or the same physical 136 point of the topology with a different provider. 138 This draft describes protocol mechanisms to achieve the desired 139 functional separation. For flexibility, the document decouples the 140 mechanism used for forwarding packets from that used to determine EID 141 to RLOC mappings. This work is in response to and intended to 142 address the problem statement that came out of the RAWS effort 143 [RFC4984]. 145 The Routing and Addressing problem statement can be found in [RADIR]. 147 This draft focuses on a router-based solution. Building the solution 148 into the network should facilitate incremental deployment of the 149 technology on the Internet. Note that while the detailed protocol 150 specification and examples in this document assume IP version 4 151 (IPv4), there is nothing in the design that precludes use of the same 152 techniques and mechanisms for IPv6. It should be possible for IPv4 153 packets to use IPv6 RLOCs and for IPv6 EIDs to be mapped to IPv4 154 RLOCs. 156 Related work on host-based solutions is described in Shim6 [SHIM6] 157 and HIP [RFC4423]. Related work on a router-based solution is 158 described in [GSE]. This draft attempts to not compete or overlap 159 with such solutions and the proposed protocol changes are expected to 160 complement a host-based mechanism when Traffic Engineering 161 functionality is desired. 163 Some of the design goals of this proposal include: 165 1. Minimize required changes to Internet infrastructure. 167 2. Require no hardware or software changes to end-systems (hosts). 169 3. Be incrementally deployable. 171 4. Require no router hardware changes. 173 5. Minimize router software changes. 175 6. Avoid or minimize packet loss when EID-to-RLOC mappings need to 176 be performed. 178 There are 4 variants of LISP, which differ along a spectrum of strong 179 to weak dependence on the topological nature and possible need for 180 routability of EIDs. The variants are: 182 LISP 1: uses EIDs that routable through the RLOC topology for 183 bootstrapping EID-to-RLOC mappings. [LISP1] This was intended as 184 a prototyping mechanism for early protocol implementation. It is 185 now deprecated and should not be deployed. 187 LISP 1.5: uses EIDs are routable for bootstrapping EID-to-RLOC 188 mappings; such routing is via a separate topology. 190 LISP 2: uses EIDS are not routable and EID-to-RLOC mappings are 191 implemented within the DNS. [LISP2] 193 LISP 3: uses non-routable EIDs are used as lookup keys for a new 194 EID-to-RLOC mapping database. Use of Distributed Hash Tables 195 [DHTs] [LISPDHT] to implement such a database would be an area to 196 explore. Other examples of new mapping database services are 198 [CONS], [ALT], [RPMD], [NERD], and [APT]. 200 This document will focus on LISP 1 and LISP 1.5, both of which rely 201 on a router-based distributed cache and database for EID-to-RLOC 202 mappings. The LISP 2 and LISP 3 mechanisms, which require separate 203 EID-to-RLOC infrastructure, will be documented elsewhere. 205 3. Definition of Terms 207 Provider Independent (PI) Addresses: an address block assigned from 208 a pool that is not associated with any service provider and is 209 therefore not topologically-aggregatable in the routing system. 211 Provider Assigned (PA) Addresses: a block of IP addresses that are 212 assigned to a site by each service provider to which a site 213 connects. Typically, each block is sub-block of a service 214 provider CIDR block and is aggregated into the larger block before 215 being advertised into the global Internet. Traditionally, IP 216 multihoming has been implemented by each multi-homed site 217 acquiring its own, globally-visible prefix. LISP uses only 218 topologically-assigned and aggregatable address blocks for RLOCs, 219 eliminating this demonstrably non-scalable practice. 221 Routing Locator (RLOC): the IPv4 or IPv6 address of an egress 222 tunnel router (ETR). It is the output of a EID-to-RLOC mapping 223 lookup. An EID maps to one or more RLOCs. Typically, RLOCs are 224 numbered from topologically-aggregatable blocks that are assigned 225 to a site at each point to which it attaches to the global 226 Internet; where the topology is defined by the connectivity of 227 provider networks, RLOCs can be thought of as PA addresses. 228 Multiple RLOCs can be assigned to the same ETR device or to 229 multiple ETR devices at a site. 231 Endpoint ID (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) valued 232 used in the source and destination address fields of the first 233 (most inner) LISP header of a packet. The host obtains a 234 destination EID the same way it obtains an destination address 235 today, for example through a DNS lookup or SIP exchange. The 236 source EID is obtained via existing mechanisms used to set a hosts 237 "local" IP address. An EID is allocated to a host from an EID- 238 prefix block associated with the site where the host is located. 239 An EID can be used by a host to refer to other hosts. LISP uses 240 PI blocks for EIDs; such EIDs MUST NOT be used as LISP RLOCs. 241 Note that EID blocks may be assigned in a hierarchical manner, 242 independent of the network topology, to facilitate scaling of the 243 mapping database. In addition, an EID block assigned to a site 244 may have site-local structure (subnetting) for routing within the 245 site; this structure is not visible to the global routing system. 247 EID-prefix: A power-of-2 block of EIDs which are allocated to a 248 site by an address allocation authority. EID-prefixes are 249 associated with a set of RLOC addresses which make up a "database 250 mapping". EID-prefix allocations can be broken up into smaller 251 blocks when an RLOC set is to be associated with the smaller EID- 252 prefix. 254 End-system: is an IPv4 or IPv6 device that originates packets with 255 a single IPv4 or IPv6 header. The end-system supplies an EID 256 value for the destination address field of the IP header when 257 communicating globally (i.e. outside of it's routing domain). An 258 end-system can be a host computer, a switch or router device, or 259 any network appliance. An iPhone. 261 Ingress Tunnel Router (ITR): a router which accepts an IP packet 262 with a single IP header (more precisely, an IP packet that does 263 not contain a LISP header). The router treats this "inner" IP 264 destination address as an EID and performs an EID-to-RLOC mapping 265 lookup. The router then prepends an "outer" IP header with one of 266 its globally-routable RLOCs in the source address field and the 267 result of the mapping lookup in the destination address field. 268 Note that this destination RLOC may be an intermediate, proxy 269 device that has better knowledge of the EID-to-RLOC mapping 270 closest to the destination EID. In general, an ITR receives IP 271 packets from site end-systems on one side and sends LISP- 272 encapsulated IP packets toward the Internet on the other side. 274 Specifically, when a service provider prepends a LISP header for 275 Traffic Engineering purposes, the router that does this is also 276 regarded as an ITR. The outer RLOC the ISP ITR uses can be based 277 on the outer destination address (the originating ITR's supplied 278 RLOC) or the inner destination address (the originating hosts 279 supplied EID). 281 TE-ITR: is an ITR that is deployed in a service provider network 282 that prepends an additional LISP header for Traffic Engineering 283 purposes. 285 Egress Tunnel Router (ETR): a router that accepts an IP packet 286 where destination address in the "outer" IP header is one of its 287 own RLOCs. The router strips the "outer" header and forwards the 288 packet based on the next IP header found. In general, an ETR 289 receives LISP-encapsulated IP packets from the Internet on one 290 side and sends decapsulated IP packets to site end-systems on the 291 other side. ETR functionality does not have to be limited to a 292 router device. A server host can be the endpoint of a LISP tunnel 293 as well. 295 TE-ETR: is an ETR that is deployed in a service provider network 296 that strips an outer LISP header for Traffic Engineering purposes. 298 xTR: is a reference to an ITR or ETR when direction of data flow is 299 not part of the context description. xTR refers to the router that 300 is the tunnel endpoint. Used synonymously with the term "Tunnel 301 Router". For example, "An xTR can be located at the Customer Edge 302 (CE) router", meaning both ITR and ETR functionality is at the CE 303 router. 305 EID-to-RLOC Cache: a short-lived, on-demand database in an ITR that 306 stores, tracks, and is responsible for timing-out and otherwise 307 validating EID-to-RLOC mappings. This cache is distinct from the 308 "database", the cache is dynamic, local, and relatively small 309 while and the database is distributed, relatively static, and much 310 global in scope. 312 EID-to-RLOC Database: a globally, distributed database that 313 contains all known EID-prefix to RLOC mappings. Each potential 314 ETR typically contains a small piece of the database: the EID-to- 315 RLOC mappings for the EID prefixes "behind" the router. These map 316 to one of the router's own, globally-visible, IP addresses. 318 Recursive Tunneling: when a packet has more than one LISP IP 319 header. Additional layers of tunneling may be employed to 320 implement traffic engineering or other re-routing as needed. When 321 this is done, an additional "outer" LISP header is added and the 322 original RLOCs are preserved in the "inner" header. 324 Reencapsulating Tunnels: when a packet has no more than one LISP IP 325 header (two IP headers total) and when it needs to be diverted to 326 new RLOC, an ETR can decapsulate the packet (remove the LISP 327 header) and prepend a new tunnel header, with new RLOC, on to the 328 packet. Doing this allows a packet to be re-routed by the re- 329 encapsulating router without adding the overhead of additional 330 tunnel headers. 332 LISP Header: a term used in this document to refer to the outer 333 IPv4 or IPv6 header, a UDP header, and a LISP header, an ITR 334 prepends or an ETR strips. 336 Address Family Indicator (AFI): a term used to describe an address 337 encoding in a packet. An address family currently pertains to an 338 IPv4 or IPv6 address. See [AFI] for details. 340 Negative Mapping Entry: also known as a negative cache entry, is an 341 EID-to-RLOC entry where an EID-prefix is advertised or stored with 342 no RLOCs. That is, the locator-set for the EID-to-RLOC entry is 343 empty or has an encoded locator count of 0. This type of entry 344 could be used to describe a prefix from a non-LISP site, which is 345 explicitly not in the mapping database. 347 Data Probe: any data packet originated by an end-host at one site 348 (the source), encapsulated by the source site's ITR, sent to an 349 ETR at a second site (the destination), then delivered to the 350 destination end-host. A new LISP header is added to the packet 351 with destination address in this new "outer header" copied from 352 the original destination address (now the "inner header"). on 353 receipt by the destination site's ETR, a "data triggered" Map- 354 Reply is returned to the ITR. In addition, the original packet is 355 decapsulated and delivered to the destination host. A Data Probe 356 is used in some of the mapping database designs to "probe" or 357 request a Map-Reply from an ETR; in other cases, Map-Requests are 358 used. See each mapping database design for details. 360 4. Basic Overview 362 One key concept of LISP is that end-systems (hosts) operate the same 363 way they do today. The IP addresses that hosts use for tracking 364 sockets, connections, and for sending and receiving packets do not 365 change. In LISP terminology, these IP addresses are called Endpoint 366 Identifiers (EIDs). 368 Routers continue to forward packets based on IP destination 369 addresses. These addresses are referred to as Routing Locators 370 (RLOCs). Most routers along a path between two hosts will not 371 change; they continue to perform routing/forwarding lookups on 372 addresses (RLOCs) in the IP header. 374 This design introduces "Tunnel Routers", which prepend LISP headers 375 on host-originated packets and strip them prior to final delivery to 376 their destination. The IP addresses in this "outer header" are 377 RLOCs. During end-to-end packet exchange between two Internet hosts, 378 an ITR prepends a new LISP header to each packet and an egress tunnel 379 router strips the new header. The ITR performs EID-to-RLOC lookups 380 to determine the routing path to the the ETR, which has the RLOC as 381 one of its IP addresses. 383 Some basic rules governing LISP are: 385 o End-systems (hosts) only know about EIDs. 387 o EIDs are always IP addresses assigned to hosts. 389 o LISP routers mostly deal with Routing Locator addresses. See 390 details later in Section 4.1 to clarify what is meant by "mostly". 392 o RLOCs are always IP addresses assigned to routers; preferably, 393 topologically-oriented addresses from provider CIDR blocks. 395 o When a router originates packets it may use as a source address 396 either an EID or RLOC. When acting as a host (e.g. when 397 terminating a transport session such as SSH, TELNET, or SNMP), it 398 may use an EID that is explicitly assigned for that purpose. An 399 EID that identifies the router as a host MUST NOT be used as an 400 RLOC. Keep in mind that an EID is only routable within the scope 401 of a site. A typical BGP configuration might demonstrate this 402 "hybrid" EID/RLOC usage where a router could use its "host-like" 403 EID to terminate iBGP sessions to other routers in a site while at 404 the same time using RLOCs to terminate eBGP sessions to routers 405 outside the site. 407 o EIDs are not expected to be usable for global end-to-end 408 communication in the absence of an EID-to-RLOC mapping operation. 409 They are expected to be used locally for intra-site communication. 411 o EID prefixes are likely to be hierarchically assigned in a manner 412 which is optimized for administrative convenience and to 413 facilitate scaling of the EID-to-RLOC mapping database. The 414 hierarchy is based on a address allocation hierarchy which is not 415 dependent on the network topology. 417 o EIDs may also be structured (subnetted) in a manner suitable for 418 local routing within an autonomous system. 420 An additional LISP header may be pre-pended to packets by a transit 421 router (i.e. TE-ITR) when re-routing of the end-to-end path for a 422 packet is desired. An obvious instance of this would be an ISP 423 router that needs to perform traffic engineering for packets in flow 424 through its network. In such a situation, termed Recursive 425 Tunneling, an ISP transit acts as an additional ingress tunnel router 426 and the RLOC it uses for the new prepended header would be either an 427 TE-ETR within the ISP (along intra-ISP traffic engineered path) or in 428 an TE-ETR within another ISP (an inter-ISP traffic engineered path, 429 where an agreement to build such a path exists). 431 Tunnel Routers can be placed fairly flexibly in a multi-AS topology. 432 For example, the ITR for a particular end-to-end packet exchange 433 might be the first-hop or default router within a site for the source 434 host. Similarly, the egress tunnel router might be the last-hop 435 router directly-connected to the destination host. Another example, 436 perhaps for a VPN service out-sourced to an ISP by a site, the ITR 437 could be the site's border router at the service provider attachment 438 point. Mixing and matching of site-operated, ISP-operated, and other 439 tunnel routers is allowed for maximum flexibility. See Section 8 for 440 more details. 442 4.1. Packet Flow Sequence 444 This section provides an example of the unicast packet flow with the 445 following parameters: 447 o Source host "host1.abc.com" is sending a packet to 448 "host2.xyz.com". 450 o Each site is multi-homed, so each tunnel router has an address 451 (RLOC) assigned from each of the site's attached service provider 452 address blocks. 454 o The ITR and ETR are directly connected to the source and 455 destination, respectively. 457 Client host1.abc.com wants to communicate with server host2.xyz.com: 459 1. host1.abc.com wants to open a TCP connection to host2.xyz.com. 460 It does a DNS lookup on host2.xyz.com. An A/AAAA record is 461 returned. This address is used as the destination EID and the 462 locally-assigned address of host1.abc.com is used as the source 463 EID. An IP/IPv6 packet is built using the EIDs in the IP/IPv6 464 header and sent to the default router. 466 2. The default router is configured as an ITR. It prepends a LISP 467 header to the packet, with one of its RLOCs as the source IP/IPv6 468 address and uses the destination EID from the original packet 469 header as the destination IP/IPv6 address. Subsequent packets 470 continue to behave the same way until a mapping is learned. 472 3. In LISP 1, the packet is routed through the Internet as it is 473 today. In LISP 1.5, the packet is routed on a different topology 474 which may have EID prefixes distributed and advertised in an 475 aggregatable fashion. In either case, the packet arrives at the 476 ETR. The router is configured to "punt" the packet to the 477 router's control-plane processor. See Section 7 for more 478 details. 480 4. The LISP header is stripped so that the packet can be forwarded 481 by the router control-plane. The router looks up the destination 482 EID in the router's EID-to-RLOC database (not the cache, but the 483 configured data structure of RLOCs). An EID-to-RLOC Map-Reply 484 message is originated by the egress router and is addressed to 485 the source RLOC from the LISP header of the original packet (this 486 is the ITR). The source RLOC in the IP header of the UDP message 487 is one of the ETR's RLOCs (one of the RLOCs that is embedded in 488 the UDP payload). 490 5. The ITR receives the UDP message, parses the message (to check 491 for format validity) and stores the EID-to-RLOC information from 492 the packet. This information is put in the ITR's EID-to-RLOC 493 mapping cache (this is the on-demand cache, the cache where 494 entries time out due to inactivity). 496 6. Subsequent packets from host1.abc.com to host2.xyz.com will have 497 a LISP header prepended with the RLOCs learned from the ETR. 499 7. The egress tunnel receives these packets directly (since the 500 destination address is one of its assigned IP addresses), strips 501 the LISP header and delivers the packets to the attached 502 destination host. 504 In order to eliminate the need for a mapping lookup in the reverse 505 direction, an ETR MAY create a cache entry that maps the source EID 506 (inner header source IP address) to the source RLOC (outer header 507 source IP address) in a received LISP packet. Such a cache entry is 508 termed a "gleaned" mapping and only contains a single RLOC for the 509 EID in question. More complete information about additional RLOCs 510 SHOULD be verified by sending a LISP Map-Request for that EID. Both 511 ITR and the ETR may also influence the decision the other makes in 512 selecting an RLOC. See Section 6 for more details. 514 5. Tunneling Details 516 This section describes the LISP Data Message which defines the 517 tunneling header used to encapsulate IPv4 and IPv6 packets which 518 contain EID addresses. Even though the following formats illustrate 519 IPv4-in-IPv4 and IPv6-in-IPv6 encapsulations, the other 2 520 combinations are supported as well. 522 Since additional tunnel headers are prepended, the packet becomes 523 larger and in theory can exceed the MTU of any link traversed from 524 the ITR to the ETR. It is recommended, in IPv4 that packets do not 525 get fragmented as they are encapsulated by the ITR. Instead, the 526 packet is dropped and an ICMP Too Big message is returned to the 527 source. 529 Based on informal surveys of large ISP traffic patterns, it appears 530 that most transit paths can accommodate a path MTU of at least 4470 531 bytes. The exceptions, in terms of data rate, number of hosts 532 affected, or any other metric are expected to be vanishingly small. 534 To address MTU concerns, mainly raised on the RRG mailing list, the 535 LISP deployment process will include collecting data during its pilot 536 phase to either verify or refute the assumption about minimum 537 available MTU. If the assumption proves true and transit networks 538 with links limited to 1500 byte MTUs are corner cases, it would seem 539 more cost-effective to either upgrade or modify the equipment in 540 those transit networks to support larger MTUs or to use existing 541 mechanisms for accommodating packets that are too large. 543 For this reason, there is currently no plan for LISP to add an 544 additional, complex mechanism for implementing fragmentation and 545 reassembly in the face of limited-MTU transit links. If analysis 546 during LISP pilot deployment reveals that the assumption of 547 essentially ubiquitous, 4470+ byte transit path MTUs, is incorrect, 548 then LISP can be modified prior to protocol standardization to add 549 support for one of the proposed fragmentation and reassembly schemes. 550 Note that one simple scheme is detailed in Section 5.4. 552 5.1. LISP IPv4-in-IPv4 Header Format 554 0 1 2 3 555 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 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 / |Version| IHL |Type of Service| Total Length | 558 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 / | Identification |Flags| Fragment Offset | 560 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 OH | Time to Live | Protocol = 17 | Header Checksum | 562 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 \ | Source Routing Locator | 564 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 \ | Destination Routing Locator | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 / | Source Port = xxxx | Dest Port = 4341 | 568 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 \ | UDP Length | UDP Checksum | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 / |M| Locator Reach Bits | 572 LISP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 \ | Nonce | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 / |Version| IHL |Type of Service| Total Length | 576 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 / | Identification |Flags| Fragment Offset | 578 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 IH | Time to Live | Protocol | Header Checksum | 580 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 \ | Source EID | 582 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 \ | Destination EID | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 5.2. LISP IPv6-in-IPv6 Header Format 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 / |Version| Traffic Class | Flow Label | 590 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 / | Payload Length | Next Header=17| Hop Limit | 592 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | | 594 O + + 595 u | | 596 t + Source Routing Locator + 597 e | | 598 r + + 599 | | 600 H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 d | | 602 r + + 603 | | 604 \ + Destination Routing Locator + 605 \ | | 606 \ + + 607 \ | | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 / | Source Port = xxxx | Dest Port = 4341 | 610 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 \ | UDP Length | UDP Checksum | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 / |M| Locator Reach Bits | 614 LISP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 \ | Nonce | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 / |Version| Traffic Class | Flow Label | 618 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 / | Payload Length | Next Header | Hop Limit | 620 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | | 622 I + + 623 n | | 624 n + Source EID + 625 e | | 626 r + + 627 | | 628 H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 d | | 630 r + + 631 | | 633 \ + Destination EID + 634 \ | | 635 \ + + 636 \ | | 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 5.3. Tunnel Header Field Descriptions 641 IH Header: is the inner header, preserved from the datagram received 642 from the originating host. The source and destination IP 643 addresses are EIDs. 645 OH Header: is the outer header prepended by an ITR. The address 646 fields contain RLOCs obtained from the ingress router's EID-to- 647 RLOC cache. The IP protocol number is "UDP (17)" from [RFC0768]. 649 UDP Header: contains a random source port allocated by the ITR when 650 encapsulating a packet. The destination port MUST be set to the 651 well-known IANA assigned port value 4341. 653 UDP Checksum: this field field MUST be transmitted as 0 and ignored 654 on receipt by the ETR. Note, even when the UDP checksum is 655 transmitted as 0 an intervening NAT device can recalculate the 656 checksum and rewrite the UDP checksum field to non-zero. For 657 performance reasons, the ETR MUST ignore the checksum and MUST not 658 do a checksum computation. 660 UDP Length: for an IPv4 encapsulated packet, the inner header Total 661 Length plus the UDP and LISP header lengths are used. For an IPv6 662 encapsulated packet, the inner header Payload Length plus the size 663 of the IPv6 header (40 bytes) plus the size of the UDP and LISP 664 headers are used. The UDP header length is 8 bytes. The LISP 665 header length is 8 bytes. 667 LISP Locator Reach Bits: in the LISP header are set by an ITR to 668 indicate to an ETR the reachability of the Locators in the source 669 site. Each RLOC in a Map-Reply is assigned an ordinal value from 670 0 to n-1 (when there are n RLOCs in a mapping entry). The Locator 671 Reach Bits are numbered from 0 to n-1 from the right significant 672 bit of the 32-bit field. When a bit is set to 1, the ITR is 673 indicating to the ETR the RLOC associated with the bit ordinal is 674 reachable. See Section 6.3 for details on how an ITR can 675 determine other ITRs at the site are reachable. When a site has 676 multiple EID-prefixes which result in multiple mappings (where 677 each could have a different locator-set), the Locator Reach Bits 678 setting in an encapsulated packet MUST reflect the mapping for the 679 EID-prefix that the inner-header source EID address matches. When 680 the M bit is set, an additional 32-bit locator reachability field 681 follows, which may have an M-bit set for further extension (and so 682 on). This extension mechanism allows an EID to be mapped to an 683 arbitrary number of RLOCs, subject only to the maximum number of 684 32-bit fields that can fit into the response packet. For 685 practical purposes, a future version of this specification will 686 likely set a limit on the number of these fields. 688 LISP Nonce: is a 32-bit value that is randomly generated by an ITR. 689 It is used to test route-returnability when an ETR echos back the 690 nonce in a Map-Reply message. 692 When doing Recursive Tunneling: 694 o The OH header Time to Live field (or Hop Limit field, in case of 695 IPv6) MUST be copied from the IH header Time to Live field. 697 o The OH header Type of Service field (or the Traffic Class field, 698 in the case of IPv6) SHOULD be copied from the IH header Type of 699 Service field. 701 When doing Re-encapsulated Tunneling: 703 o The new OH header Time to Live field SHOULD be copied from the 704 stripped OH header Time to Live field. 706 o The new OH header Type of Service field SHOULD be copied from the 707 stripped OH header Type of Service field. 709 Copying the TTL serves two purposes: first, it preserves the distance 710 the host intended the packet to travel; second, and more importantly, 711 it provides for suppression of looping packets in the event there is 712 a loop of concatenated tunnels due to misconfiguration. 714 5.4. Dealing with Large Encapsulated Packets 716 In the event that the MTU issues mentioned above prove to be more 717 serious than expected, this section proposes a simple and stateless 718 mechanism to deal with large packets. The mechanism is described as 719 follows: 721 1. Define an architectural constant S for the maximum size of a 722 packet, in bytes, an ITR would receive from a source inside of 723 its site. 725 2. Define L to be the maximum size, in bytes, a packet of size S 726 would be after the ITR prepends the LISP header, UDP header, and 727 outer network layer header of size H. 729 3. Calculate: S + H = L. 731 When an ITR receives a packet of size greater than L on a site-facing 732 interface and that packet needs to be encapsulated, it resolves the 733 MTU issue by first splitting the original packet into 2 equal-sized 734 fragments. A LISP header is then pre-pended to each fragment. This 735 will ensure that the new, encapsulated packets are of size (S/2 + H), 736 which is always below the effective tunnel MTU. 738 When an ETR receives encapsulated fragments, it treats them as two 739 individually encapsulated packets. It strips the LISP headers then 740 forwards each packet to the destination host of the destination site. 741 The two fragments are reassembled at the destination host into the 742 single IP datagram that was originated by the source host. 744 This behavior is performed by the ITR when the source host originates 745 a packet when the DF field of the IP header is set to 0. When the DF 746 field of the IP header is set to 1, or the packet is an IPv6 packet 747 originated by the source host, the ITR will drop the packet when the 748 size is greater than L, and sends an ICMP Too Big message to the 749 source with a value of S, where S is (L - H). 751 This specification recommends that L be defined as 1500. 753 6. EID-to-RLOC Mapping 755 6.1. Control-Plane Packet Format 757 When LISP 1 or LISP 1.5 are used, new UDP packet types encode the 758 EID-to-RLOC mappings: 760 0 1 2 3 761 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 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 |Version| IHL |Type of Service| Total Length | 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | Identification |Flags| Fragment Offset | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 | Time to Live | Protocol = 17 | Header Checksum | 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 769 | Source Routing Locator | 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 | Destination Routing Locator | 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 / | Source Port | Dest Port | 774 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 \ | UDP Length | UDP Checksum | 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 | | 778 | LISP Message | 779 | | 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 |Version| Traffic Class | Flow Label | 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 | Payload Length | Next Header=17| Hop Limit | 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 | | 788 + + 789 | | 790 + Source Routing Locator + 791 | | 792 + + 793 | | 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 | | 796 + + 797 | | 798 + Destination Routing Locator + 799 | | 800 + + 801 | | 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 / | Source Port | Dest Port | 804 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 \ | UDP Length | UDP Checksum | 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 | | 808 | LISP Message | 809 | | 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 The LISP UDP-based messages are the Map-Request and Map-Reply 813 messages. When a UDP Map-Request is sent, the UDP source port is 814 chosen by the sender and the destination UDP port number is set to 815 4342. When a UDP Map-Reply is sent, the source UDP port number is 816 set to 4342 and the destination UDP port number is copied from the 817 source port of either the Map-Request or the invoking data packet. 819 The UDP Length field will reflect the length of the UDP header and 820 the LISP Message payload. 822 The UDP Checksum is computed and set to non-zero for Map-Request and 823 Map-Reply messages. It MUST be checked on receipt and if the 824 checksum fails, the packet MUST be dropped. 826 LISP-CONS [CONS] and LISP-ALT [ALT] use TCP to send LISP control 827 messages. The format of control messages includes the UDP header so 828 the checksum and length fields can be used to protect and delimit 829 message boundaries. 831 This main LISP specification is the authoritative source for message 832 format definitions for the Map-Request and Map-Reply messages. 834 6.1.1. LISP Packet Type Allocations 836 This section will be the authoritative source for allocating LISP 837 Type values. Current allocations are: 839 Reserved: 0 b'0000' 840 LISP Map-Request: 1 b'0001' 841 LISP Map-Reply: 2 b'0010' 842 LISP-CONS Open Message: 8 b'1000' 843 LISP-CONS Push-Add Message: 9 b'1001' 844 LISP-CONS Push-Delete Message: 10 b'1010' 845 LISP-CONS Uneachable Message: 11 b'1011' 847 6.1.2. Map-Request Message Format 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 |M| Locator Reach Bits | 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 | Nonce | 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 |Type=1 |Rsvd |A| Record Cnt | ITR-AFI | 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 | Originating ITR RLOC Address | 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 Rec -> | EID mask-len | EID-AFI | EID-prefix ... | 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 | Mapping Protocol Data | 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 Packet field descriptions: 865 Locator Reach Bits: Refer to Section 5.3. 867 Nonce: A 4-byte random value created by the sender of the Map- 868 Request. 870 Type: 1 (Map-Request) 872 Rsvd: Set to 0 on transmission and ignored on receipt. 874 A: This is an authoritative bit, which is set to 0 for UDP-based Map- 875 Requests sent by an ITR. See other control-specific documents 876 [CONS] [ALT] for TCP-based Map-Requests. 878 Record Cnt: The number of records in this request message. A record 879 comprises of what is labeled 'Rec" above and occurs the number of 880 times equal to Record count. 882 ITR-AFI: Address family of the "Originating ITR RLOC Address" field. 884 Originating ITR RLOC Address: Set to 0 for UDP-based messages. See 885 [CONS] [ALT] for TCP-based Map-Requests. 887 EID mask-len: Mask length for EID prefix. 889 EID-AFI: Address family of EID-prefix according to [RFC2434] 891 EID-prefix: 4 bytes if an IPv4 address-family, 16 bytes if an IPv6 892 address-family. 894 Mapping Protocol Data: See [CONS] or [ALT] for details. 896 6.1.3. EID-to-RLOC UDP Map-Request Message 898 A Map-Request contains one or more EIDs encoded in prefix format with 899 a Locator count of 0. The EID-prefix MUST NOT be more specific than 900 a cache entry stored from a previously-received Map-Reply. 902 A Map-Request is sent from an ITR when it needs a mapping for an EID, 903 wants to test an RLOC for reachability, or wants to refresh a mapping 904 before TTL expiration. This is performed by using the RLOC as the 905 destination address for Map-Request message with a randomly allocated 906 source UDP port number and the well-known destination port number 907 4342. A successful Map-Reply updates the cached set of RLOCs 908 associated with the EID prefix range. 910 Map-Requests MUST be rate-limited. It is recommended that a Map- 911 Request for the same EID-prefix be sent no more than once per second. 913 6.1.4. Map-Reply Message Format 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 |M| Locator Reach Bits | 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 | Nonce | 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 |Type=2 | Reserved | Record Count | 921 +----> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 | | Record TTL | 923 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 | | Locator Count | EID mask-len |A| Reserved | 925 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 R | ITR-AFI | EID-AFI | 927 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 c | Originating ITR RLOC Address | 929 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 r | EID-prefix | 931 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 | /| Priority | Weight | M Priority | M Weight | 933 | / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 | Loc | Unused Flags |R| Loc-AFI | 935 | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 | \| Locator | 937 +---> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 | Mapping Protocol Data | 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 Packet field descriptions: 943 Locator Reach Bits: Refer to Section 5.3. When there are multiple 944 records in the Map-Reply message, this field is set to 0 and the 945 R-bit for each Locator record within each mapping record is used 946 to determine the locator reachability. 948 Nonce: A 4-byte value set in a data probe packet or a Map-Request 949 that is echoed here in the Map-Reply. 951 Type: 2 (Map-Reply) 953 Reserved: Set to 0 on transmission and ignored on receipt. 955 Record Count: The number of records in this reply message. A record 956 comprises of what is labeled 'Record' above and occurs the number 957 of times equal to Record count. 959 Record TTL: The time in minutes the recipient of the Map-Reply will 960 store the mapping. If the TTL is 0, the entry should be removed 961 from the cache immediately. If the value is 0xffffffff, the 962 recipient can decide locally how long to store the mapping. 964 Locator Count: The number of Locator entries. A locator entry 965 comprises what is labeled above as 'Loc'. 967 EID mask-len: Mask length for EID prefix. 969 A: The Authoritative bit, when sent by a UDP-based message is always 970 set by the ETR. See [CONS] [ALT] for TCP-based Map-Replies. 972 ITR-AFI: Address family of the "Originating ITR RLOC Address" field. 974 EID-AFI: Address family of EID-prefix according to [RFC2434]. 976 Originating ITR RLOC Address: Set to 0 for UDP-based messages. See 977 [CONS] [ALT] for TCP-based Map-Replies. 979 EID-prefix: 4 bytes if an IPv4 address-family, 16 bytes if an IPv6 980 address-family. 982 Priority: each RLOC is assigned a unicast priority. Lower values 983 are more preferable. When multiple RLOCs have the same priority, 984 they are used in a load-split fashion. A value of 255 means the 985 RLOC MUST NOT be used for unicast forwarding. 987 Weight: when priorities are the same for multiple RLOCs, the weight 988 indicates how to balance unicast traffic between them. Weight is 989 encoded as a percentage of total unicast packets that match the 990 mapping entry. If a non-zero weight value is used for any RLOC, 991 then all RLOCs must use a non-zero weight value and then the sum 992 of all weight values MUST equal 100. What did the 3rd grader say 993 after Steve Jobs gave an iPhone demo to the class? If a zero 994 value is used for any RLOC weight, then all weights MUST be zero 995 and the receiver of the Map-Reply will decide how to load-split 996 traffic. 998 M Priority: each RLOC is assigned a multicast priority used by an 999 ETR in a receiver multicast site to select an ITR in a source 1000 multicast site for building multicast distribution trees. A value 1001 of 255 means the RLOC MUST NOT be used for joining a multicast 1002 distribution tree. 1004 M Weight: when priorities are the same for multiple RLOCs, the 1005 weight indicates how to balance building multicast distribution 1006 trees across multiple ITRs. The weight is encoded as a percentage 1007 of total number of trees build to the source site identified by 1008 the EID-prefix. If a non-zero weight value is used for any RLOC, 1009 then all RLOCs must use a non-zero weight value and then the sum 1010 of all weight values MUST equal 100. If a zero value is used for 1011 any RLOC weight, then all weights MUST be zero and the receiver of 1012 the Map-Reply will decide how to distribute multicast state across 1013 ITRs. 1015 Unused Flags: set to 0 when sending and ignored on receipt. 1017 R: when this bit is set, the locator is known to be reachable from 1018 the Map-Reply sender's perspective. When there is a single 1019 mapping record in the message, the R-bit for each locator must 1020 have a consistent setting with the bitfield setting of the 'Loc 1021 Reach Bits' field in the early part of the header. When there are 1022 multiple mapping records in the message, the 'Loc Reach Bits' 1023 field is set to 0. 1025 Locator: an IPv4 or IPv6 address (as encoded by the 'Loc-AFI' field) 1026 assigned to an ETR or router acting as a proxy replier for the 1027 EID-prefix. Note that the destination RLOC address MAY be an 1028 anycast address if the tunnel egress point may be via more than 1029 one physical device. A source RLOC can be an anycast address as 1030 well. The source or destination RLOC MUST NOT be the broadcast 1031 address (255.255.255.255 or any subnet broadcast address known to 1032 the router), and MUST NOT be a link-local multicast address. The 1033 source RLOC MUST NOT be a multicast address. The destination RLOC 1034 SHOULD be a multicast address if it is being mapped from a 1035 multicast destination EID. 1037 Mapping Protocol Data: See [CONS] or [ALT] for details. 1039 6.1.5. EID-to-RLOC UDP Map-Reply Message 1041 When a Data Probe packet or a Map-Request triggers a Map-Reply to be 1042 sent, the RLOCs associated with the EID-prefix matched by the EID in 1043 the original packet destination IP address field will be returned. 1044 The RLOCs in the Map-Reply are the globally-routable IP addresses of 1045 the ETR but are not necessarily reachable; separate testing of 1046 reachability is required. 1048 Note that a Map-Reply may contain different EID-prefix granularity 1049 (prefix + length) than the Map-Request which triggers it. This might 1050 occur if a Map-Request were for a prefix that had been returned by an 1051 earlier Map-Reply. In such a case, the requester updates its cache 1052 with the new prefix information and granularity. For example, a 1053 requester with two cached EID-prefixes that are covered by a Map- 1054 Reply containing one, less-specific prefix, replaces the entry with 1055 the less-specific EID-prefix. Note that the reverse, replacement of 1056 one less-specific prefix with multiple more-specific prefixes, can 1057 also occur but not by removing the less-specific prefix rather by 1058 adding the more-specific prefixes which during a lookup will override 1059 the less-specific prefix. 1061 Replies SHOULD be sent for an EID-prefix no more often than once per 1062 second to the same requesting router. For scalability, it is 1063 expected that aggregation of EID addresses into EID-prefixes will 1064 allow one Map-Reply to satisfy a mapping for the EID addresses in the 1065 prefix range thereby reducing the number of Map-Request messages. 1067 The addresses for a Data message or Map-Request message are swapped 1068 and used for sending the Map-Reply. The UDP source and destination 1069 ports are swapped as well. That is, the source port in the UDP 1070 header for the Map-Reply is set to the well-known UDP port number 1071 4342. 1073 6.2. Routing Locator Selection 1075 Both client-side and server-side may need control over the selection 1076 of RLOCs for conversations between them. This control is achieved by 1077 manipulating the Priority and Weight fields in EID-to-RLOC Map-Reply 1078 messages. Alternatively, RLOC information may be gleaned from 1079 received tunneled packets or EID-to-RLOC Map-Request messages. 1081 The following enumerates different scenarios for choosing RLOCs and 1082 the controls that are available: 1084 o Server-side returns one RLOC. Client-side can only use one RLOC. 1085 Server-side has complete control of the selection. 1087 o Server-side returns a list of RLOC where a subset of the list has 1088 the same best priority. Client can only use the subset list 1089 according to the weighting assigned by the server-side. In this 1090 case, the server-side controls both the subset list and load- 1091 splitting across its members. The client-side can use RLOCs 1092 outside of the subset list if it determines that the subset list 1093 is unreachable (unless RLOCs are set to a Priority of 255). Some 1094 sharing of control exists: the server-side determines the 1095 destination RLOC list and load distribution while the client-side 1096 has the option of using alternatives to this list if RLOCs in the 1097 list are unreachable. 1099 o Server-side sets weight of 0 for the RLOC subset list. In this 1100 case, the client-side can choose how the traffic load is spread 1101 across the subset list. Control is shared by the server-side 1102 determining the list and the client determining load distribution. 1103 Again, the client can use alternative RLOCs if the server-provided 1104 list of RLOCs are unreachable. 1106 o Either side (more likely on the server-side ETR) decides not to 1107 send an Map-Request. For example, if the server-side ETR does not 1108 send Map-Requests, it gleans RLOCs from the client-side ITR, 1109 giving the client-side ITR responsibility for bidirectional RLOC 1110 reachability and preferability. Server-side ETR gleaning of the 1111 client-side ITR RLOC is done by caching the inner header source 1112 EID and the outer header source RLOC of received packets. The 1113 client-side ITR controls how traffic is returned and can alternate 1114 using an outer header source RLOC, which then can be added to the 1115 list the server-side ETR uses to return traffic. Since no 1116 Priority or Weights are provided using this method, the server- 1117 side ETR must assume each client-side ITR RLOC uses the same best 1118 Priority with a Weight of zero. In addition, since EID-prefix 1119 encoding cannot be conveyed in data packets, the EID-to-RLOC cache 1120 on tunnel routers can grow to be very large. 1122 RLOCs that appear in EID-to-RLOC Map-Reply messages are considered 1123 reachable. The Map-Reply and the database mapping service does not 1124 provide any reachability status for Locators. This is done outside 1125 of the mapping service. See next section for details. 1127 6.3. Routing Locator Reachability 1129 There are 4 methods for determining when a Locator is either 1130 reachable or has become unreachable: 1132 1. Locator reachability is determined by an ETR by examining the 1133 Loc-Reach-Bits from a LISP header of a Data Message which is 1134 provided by an ITR when an ITR encapsulates data. 1136 2. Locator unreachability is determined by an ITR by receiving ICMP 1137 Network or Host Unreachable messages. 1139 3. ETR unreachability is determined when a host sends an ICMP Port 1140 Unreachable message. 1142 4. Locator reachability is determined by receiving a Map-Reply 1143 message from a ETR's Locator address in response to a previously 1144 sent Map-Request. 1146 When determining Locator reachability by examining the Loc-Reach-Bits 1147 from the LISP Data Message, an ETR will receive up to date status 1148 from the ITR closest to the Locators at the source site. The ITRs at 1149 the source site can determine reachability when running their IGP at 1150 the site. When the ITRs are deployed on CE routers, typically a 1151 default route is injected into the site's IGP from each of the ITRs. 1152 If an ITR goes down, the CE-PE link goes down, or the PE router goes 1153 down, the CE router withdraws the default route. This allows the 1154 other ITRs at the site to determine one of the Locators has gone 1155 unreachable. 1157 The Locators listed in a Map-Reply are numbered with ordinals 0 to 1158 n-1. The Loc-Reach-Bits in a LISP Data Message are numbered from 0 1159 to n-1 starting with the least significant bit numbered as 0. So, 1160 for example, if the ITR with locator listed as the 3rd Locator 1161 position in the Map-Reply goes down, all other ITRs at the site will 1162 have the 3rd bit from the right cleared (the bit that corresponds to 1163 ordinal 2). 1165 When an ETR decapsulates a packet, it will look for a change in the 1166 Loc-Reach-Bits value. When a bit goes from 1 to 0, the ETR will 1167 refrain from encapsulating packets to the Locator that has just gone 1168 unreachable. It can start using the Locator again when the bit that 1169 corresponds to the Locator goes from 0 to 1. Loc-Reach-Bits are 1170 associated with a locator-set per EID-prefix. Therefore, when a 1171 locator becomes unreachable, the Loc-Reach-Bits that corresponds to 1172 that locator's posiiton in the list returned by the last Map-Reply 1173 will be set to zero. 1175 When ITRs at the site are not deployed in CE routers, the IGP can 1176 still be used to determine the reachability of Locators provided they 1177 are injected a stub links into the IGP. This is typically done when 1178 a /32 address is configured on a loopback interface. 1180 When ITRs receive ICMP Network or Host Unreachable messages as a 1181 method to determine unreachability, they will refrain from using 1182 Locators which are described in Locator lists of Map-Replies. 1183 However, using this approach is unreliable because many network 1184 operators turn off generation of ICMP Unreachable messages. 1186 Optionally, an ITR can send a Map-Request to a Locator and if a Map- 1187 Reply is returned, reachability of the Locator has been achieved. 1188 Obviously, sending such probes increases the number of control 1189 messages originated by tunnel routers for active flows, so Locators 1190 are assumed to be reachable when they are advertised. 1192 This assumption does create a dependency: Locator unreachability is 1193 detected by the receipt of ICMP Host Unreachable messages. When an 1194 Locator has been determined unreachable, it is not used for active 1195 traffic; this is the same as if it were listed in a Map-Reply with 1196 priority 255. 1198 The ITR can later test the reachability of the unreachable Locator by 1199 sending periodic Requests. Both Requests and Replies MUST be rate- 1200 limited. Locator reachability testing is never done with data 1201 packets since that increases the risk of packet loss for end-to-end 1202 sessions. 1204 7. Router Performance Considerations 1206 LISP is designed to be very hardware-based forwarding friendly. By 1207 doing tunnel header prepending [RFC1955] and stripping instead of re- 1208 writing addresses, existing hardware could support the forwarding 1209 model with little or no modification. Where modifications are 1210 required, they should be limited to re-programming existing hardware 1211 rather than requiring expensive design changes to hard-coded 1212 algorithms in silicon. 1214 A few implementation techniques can be used to incrementally 1215 implement LISP: 1217 o When a tunnel encapsulated packet is received by an ETR, the outer 1218 destination address may not be the address of the router. This 1219 makes it challenging for the control-plane to get packets from the 1220 hardware. This may be mitigated by creating special FIB entries 1221 for the EID-prefixes of EIDs served by the ETR (those for which 1222 the router provides an RLOC translation). These FIB entries are 1223 marked with a flag indicating that control-plane processing should 1224 be performed. The forwarding logic of testing for particular IP 1225 protocol number value is not necessary. No changes to existing, 1226 deployed hardware should be needed to support this. 1228 o On an ITR, prepending a new IP header is as simple as adding more 1229 bytes to a MAC rewrite string and prepending the string as part of 1230 the outgoing encapsulation procedure. Many routers that support 1231 GRE tunneling [RFC2784] or 6to4 tunneling [RFC3056] can already 1232 support this action. 1234 o When a received packet's outer destination address contains an EID 1235 which is not intended to be forwarded on the routable topology 1236 (i.e. LISP 1.5), the source address of a data packet or the 1237 router interface with which the source is associated (the 1238 interface from which it was received) can be associated with a VRF 1239 (Virtual Routing/Forwarding), in which a different (i.e. non- 1240 congruent) topology can be used to find EID-to-RLOC mappings. 1242 8. Deployment Scenarios 1244 This section will explore how and where ITRs and ETRs can be deployed 1245 and will discuss the pros and cons of each deployment scenario. 1246 There are two basic deployment trade-offs to consider: centralized 1247 versus distributed caches and flat, recursive, or re-encapsulating 1248 tunneling. 1250 When deciding on centralized versus distributed caching, the 1251 following issues should be considered: 1253 o Are the tunnel routers spread out so that the caches are spread 1254 across all the memories of each router? 1256 o Should management "touch points" be minimized by choosing few 1257 tunnel routers, just enough for redundancy? 1259 o In general, using more ITRs doesn't increase management load, 1260 since caches are built and stored dynamically. On the other hand, 1261 more ETRs does require more management since EID-prefix-to-RLOC 1262 mappings need to be explicitly configured. 1264 When deciding on flat, recursive, or re-encapsulation tunneling, the 1265 following issues should be considered: 1267 o Flat tunneling implements a single tunnel between source site and 1268 destination site. This generally offers better paths between 1269 sources and destinations with a single tunnel path. 1271 o Recursive tunneling is when tunneled traffic is again further 1272 encapsulated in another tunnel, either to implement VPNs or to 1273 perform Traffic Engineering. When doing VPN-based tunneling, the 1274 site has some control since the site is prepending a new tunnel 1275 header. In the case of TE-based tunneling, the site may have 1276 control if it is prepending a new tunnel header, but if the site's 1277 ISP is doing the TE, then the site has no control. Recursive 1278 tunneling generally will result in suboptimal paths but at the 1279 benefit of steering traffic to resource available parts of the 1280 network. 1282 o The technique of re-encapsulation ensures that packets only 1283 require one tunnel header. So if a packet needs to be rerouted, 1284 it is first decapsulated by the ETR and then re-encapsulated with 1285 a new tunnel header using a new RLOC. 1287 The next sub-sections will describe where tunnel routers can reside 1288 in the network. 1290 8.1. First-hop/Last-hop Tunnel Routers 1292 By locating tunnel routers close to hosts, the EID-prefix set is at 1293 the granularity of an IP subnet. So at the expense of more EID- 1294 prefix-to-RLOC sets for the site, the caches in each tunnel router 1295 can remain relatively small. But caches always depend on the number 1296 of non-aggregated EID destination flows active through these tunnel 1297 routers. 1299 With more tunnel routers doing encapsulation, the increase in control 1300 traffic grows as well: since the EID-granularity is greater, more 1301 Map-Requests and replies are traveling between more routers. 1303 The advantage of placing the caches and databases at these stub 1304 routers is that the products deployed in this part of the network 1305 have better price-memory ratios then their core router counterparts. 1306 Memory is typically less expensive in these devices and fewer routes 1307 are stored (only IGP routes). These devices tend to have excess 1308 capacity, both for forwarding and routing state. 1310 LISP functionality can also be deployed in edge switches. These 1311 devices generally have layer-2 ports facing hosts and layer-3 ports 1312 facing the Internet. Spare capacity is also often available in these 1313 devices as well. 1315 8.2. Border/Edge Tunnel Routers 1317 Using customer-edge (CE) routers for tunnel endpoints allows the EID 1318 space associated with a site to be reachable via a small set of RLOCs 1319 assigned to the CE routers for that site. 1321 This offers the opposite benefit of the first-hop/last-hop tunnel 1322 router scenario: the number of mapping entries and network management 1323 touch points are reduced, allowing better scaling. 1325 One disadvantage is that less of the network's resources are used to 1326 reach host endpoints thereby centralizing the point-of-failure domain 1327 and creating network choke points at the CE router. 1329 Note that more than one CE router at a site can be configured with 1330 the same IP address. In this case an RLOC is an anycast address. 1331 This allows resilience between the CE routers. That is, if a CE 1332 router fails, traffic is automatically routed to the other routers 1333 using the same anycast address. However, this comes with the 1334 disadvantage where the site cannot control the entrance point when 1335 the anycast route is advertised out from all border routers. 1337 8.3. ISP Provider-Edge (PE) Tunnel Routers 1339 Use of ISP PE routers as tunnel endpoint routers gives an ISP control 1340 over the location of the egress tunnel endpoints. That is, the ISP 1341 can decide if the tunnel endpoints are in the destination site (in 1342 either CE routers or last-hop routers within a site) or at other PE 1343 edges. The advantage of this case is that two or more tunnel headers 1344 can be avoided. By having the PE be the first router on the path to 1345 encapsulate, it can choose a TE path first, and the ETR can 1346 decapsulate and re-encapsulate for a tunnel to the destination end 1347 site. 1349 An obvious disadvantage is that the end site has no control over 1350 where its packets flow or the RLOCs used. 1352 As mentioned in earlier sections a combination of these scenarios is 1353 possible at the expense of extra packet header overhead, if both site 1354 and provider want control, then recursive or re-encapsulating tunnels 1355 are used. 1357 9. Mobility Considerations 1359 There are several kinds of mobility of which only some might be of 1360 concern to LISP. Essentially they are as follows. 1362 9.1. Site Mobility 1364 A site wishes to change its attachment points to the Internet, and 1365 its LISP Tunnel Routers will have new RLOCs when it changes upstream 1366 providers. Changes in EID-RLOC mappings for sites are expected to be 1367 handled by configuration, outside of the LISP protocol. 1369 9.2. Slow Endpoint Mobility 1371 An individual endpoint wishes to move, but is not concerned about 1372 maintaining session continuity. Renumbering is involved. LISP can 1373 help with the issues surrounding renumbering [RFC4192] [LISA96] by 1374 decoupling the address space used by a site from the address spaces 1375 used by its ISPs. [RFC4984] 1377 9.3. Fast Endpoint Mobility 1379 Fast endpoint mobility occurs when an endpoint moves relatively 1380 rapidly, changing its IP layer network attachment point. Maintenance 1381 of session continuity is a goal. This is where the Mobile IPv4 1382 [RFC3344bis] and Mobile IPv6 [RFC3775] [RFC4866] mechanisms are used, 1383 and primarily where interactions with LISP need to be explored. 1385 The problem is that as an endpoint moves, it may require changes to 1386 the mapping between its EID and a set of RLOCs for its new network 1387 location. When this is added to the overhead of mobile IP binding 1388 updates, some packets might be delayed or dropped. 1390 In IPv4 mobility, when an endpoint is away from home, packets to it 1391 are encapsulated and forwarded via a home agent which resides in the 1392 home area the endpoint's address belongs to. The home agent will 1393 encapsulate and forward packets either directly to the endpoint or to 1394 a foreign agent which resides where the endpoint has moved to. 1395 Packets from the endpoint may be sent directly to the correspondent 1396 node, may be sent via the foreign agent, or may be reverse-tunneled 1397 back to the home agent for delivery to the mobile node. As the 1398 mobile node's EID or available RLOC changes, LISP EID-to-RLOC 1399 mappings are required for communication between the mobile node and 1400 the home agent, whether via foreign agent or not. As a mobile 1401 endpoint changes networks, up to three LISP mapping changes may be 1402 required: 1404 o The mobile node moves from an old location to a new visited 1405 network location and notifies its home agent that it has done so. 1406 The Mobile IPv4 control packets the mobile node sends pass through 1407 one of the new visited network's ITRs, which needs a EID-RLOC 1408 mapping for the home agent. 1410 o The home agent might not have the EID-RLOC mappings for the mobile 1411 node's "care-of" address or its foreign agent in the new visited 1412 network, in which case it will need to acquire them. 1414 o When packets are sent directly to the correspondent node, it may 1415 be that no traffic has been sent from the new visited network to 1416 the correspondent node's network, and the new visited network's 1417 ITR will need to obtain an EID-RLOC mapping for the correspondent 1418 node's site. 1420 In addition, if the IPv4 endpoint is sending packets from the new 1421 visited network using its original EID, then LISP will need to 1422 perform a route-returnability check on the new EID-RLOC mapping for 1423 that EID. 1425 In IPv6 mobility, packets can flow directly between the mobile node 1426 and the correspondent node in either direction. The mobile node uses 1427 its "care-of" address (EID). In this case, the route-returnability 1428 check would not be needed but one more LISP mapping lookup may be 1429 required instead: 1431 o As above, three mapping changes may be needed for the mobile node 1432 to communicate with its home agent and to send packets to the 1433 correspondent node. 1435 o In addition, another mapping will be needed in the correspondent 1436 node's ITR, in order for the correspondent node to send packets to 1437 the mobile node's "care-of" address (EID) at the new network 1438 location. 1440 When both endpoints are mobile the number of potential mapping 1441 lookups increase accordingly. 1443 As a mobile node moves there are not only mobility state changes in 1444 the mobile node, correspondent node, and home agent, but also state 1445 changes in the ITRs and ETRs for at least some EID-prefixes. 1447 The goal is to support rapid adaptation, with little delay or packet 1448 loss for the entire system. Heuristics can be added to LISP to 1449 reduce the number of mapping changes required and to reduce the delay 1450 per mapping change. Also IP mobility can be modified to require 1451 fewer mapping changes. In order to increase overall system 1452 performance, there may be a need to reduce the optimization of one 1453 area in order to place fewer demands on another. 1455 In LISP, one possibility is to "glean" information. When a packet 1456 arrives, the ETR could examine the EID-RLOC mapping and use that 1457 mapping for all outgoing traffic to that EID. It can do this after 1458 performing a route-returnability check, to ensure that the new 1459 network location does have a internal route to that endpoint. 1460 However, this does not cover the case where an ITR (the node assigned 1461 the RLOC) at the mobile-node location has been compromised. 1463 Mobile IP packet exchange is designed for an environment in which all 1464 routing information is disseminated before packets can be forwarded. 1465 In order to allow the Internet to grow to support expected future 1466 use, we are moving to an environment where some information may have 1467 to be obtained after packets are in flight. Modifications to IP 1468 mobility should be considered in order to optimize the behavior of 1469 the overall system. Anything which decreases the number of new EID- 1470 RLOC mappings needed when a node moves, or maintains the validity of 1471 an EID-RLOC mapping for a longer time, is useful. 1473 9.4. Fast Network Mobility 1475 In addition to endpoints, a network can be mobile, possibly changing 1476 xTRs. A "network" can be as small as a single router and as large as 1477 a whole site. This is different from site mobility in that it is 1478 fast and possibly short-lived, but different from endpoint mobility 1479 in that a whole prefix is changing RLOCs. However, the mechanisms 1480 are the same and there is no new overhead in LISP. A map request for 1481 any endpoint will return a binding for the entire mobile prefix. 1483 If mobile networks become a more common occurrence, it may be useful 1484 to revisit the design of the mapping service and allow for dynamic 1485 updates of the database. 1487 The issue of interactions between mobility and LISP needs to be 1488 explored further. Specific improvements to the entire system will 1489 depend on the details of mapping mechanisms. Mapping mechanisms 1490 should be evaluated on how well they support session continuity for 1491 mobile nodes. 1493 10. Multicast Considerations 1495 A multicast group address, as defined in the original Internet 1496 architecture is an identifier of a grouping of topologically 1497 independent receiver host locations. The address encoding itself 1498 does not determine the location of the receiver(s). The multicast 1499 routing protocol, and the network-based state the protocol creates, 1500 determines where the receivers are located. 1502 In the context of LISP, a multicast group address is both an EID and 1503 a Routing Locator. Therefore, no specific semantic or action needs 1504 to be taken for a destination address, as it would appear in an IP 1505 header. Therefore, a group address that appears in an inner IP 1506 header built by a source host will be used as the destination EID. 1507 And the outer IP header (the destination Routing Locator address), 1508 prepended by a LISP router, will use the same group address as the 1509 destination Routing Locator. 1511 Having said that, only the source EID and source Routing Locator 1512 needs to be dealt with. Therefore, an ITR merely needs to put its 1513 own IP address in the source Routing Locator field when prepending 1514 the outer IP header. This source Routing Locator address, like any 1515 other Routing Locator address MUST be globally routable. 1517 Therefore, an EID-to-RLOC mapping does not need to be performed by an 1518 ITR when a received data packet is a multicast data packet or when 1519 processing a source-specific Join (either by IGMPv3 or PIM). But the 1520 source Routing Locator is decided by the multicast routing protocol 1521 in a receiver site. That is, an EID to Routing Locator translation 1522 is done at control-time. 1524 Another approach is to have the ITR not encapsulate a multicast 1525 packet and allow the the host built packet to flow into the core even 1526 if the source address is allocated out of the EID namespace. If the 1527 RPF-Vector TLV [RPFV] is used by PIM in the core, then core routers 1528 can RPF to the ITR (the Locator address which is injected into core 1529 routing) rather than the host source address (the EID address which 1530 is not injected into core routing). 1532 To avoid any EID-based multicast state in the network core, the first 1533 approach is chosen for LISP-Multicast. Details for LISP-Multicast 1534 and Interworking with non-LISP sites is described in specification 1535 [MLISP]. 1537 11. Security Considerations 1539 It is believed that most of the security mechanisms will be part of 1540 the mapping database service when using control-plane procedures for 1541 obtaining EID-to-RLOC mappings. For data-plane triggered mappings, 1542 as described in this specification, protection is provided against 1543 ETR spoofing by using Return- Routability mechanisms evidenced by the 1544 use of a 4-byte Nonce field in the LISP encapsulation header. The 1545 nonce, coupled with the ITR accepting only solicited Map-Replies goes 1546 a long way toward providing decent authentication. 1548 LISP does not rely on a PKI infrastructure or a more heavy weight 1549 authentication system. These systems challenge the scalability of 1550 LISP which was a primary design goal. 1552 DoS attack prevention will depend on implementations rate-limiting of 1553 Map-Requests and Map-Replies to the control-plane as well as rate- 1554 limiting the number of data triggered Map-Replies. 1556 12. Prototype Plans and Status 1558 The operator community has requested that the IETF take a practical 1559 approach to solving the scaling problems associated with global 1560 routing state growth. This document offers a simple solution which 1561 is intended for use in a pilot program to gain experience in working 1562 on this problem. 1564 The authors hope that publishing this specification will allow the 1565 rapid implementation of multiple vendor prototypes and deployment on 1566 a small scale. Doing this will help the community: 1568 o Decide whether a new EID-to-RLOC mapping database infrastructure 1569 is needed or if a simple, UDP-based, data-triggered approach is 1570 flexible and robust enough. 1572 o Experiment with provider-independent assignment of EIDs while at 1573 the same time decreasing the size of DFZ routing tables through 1574 the use of topologically-aligned, provider-based RLOCs. 1576 o Determine whether multiple levels of tunneling can be used by ISPs 1577 to achieve their Traffic Engineering goals while simultaneously 1578 removing the more specific routes currently injected into the 1579 global routing system for this purpose. 1581 o Experiment with mobility to determine if both acceptable 1582 convergence and session survivability properties can be scalably 1583 implemented to support both individual device roaming and site 1584 service provider changes. 1586 Here is a rough set of milestones: 1588 1. This draft will be the draft for interoperable implementations to 1589 code against. Interoperable implementations will be ready summer 1590 of 2008. 1592 2. Start pilot deployment summer of 2008 using LISP-ALT as the 1593 database mapping mechanism. 1595 3. Continue prototyping other database lookup schemes, be it DNS, 1596 DHTs, CONS, ALT, NERD, or other mechanisms. 1598 4. Write up a LISP Multicast Internet Draft which designs how inter- 1599 domain multicast routing works in a Locator/ID split environment. 1601 5. Research more on how policy affects what gets returned in a Map- 1602 Reply from an ETR. 1604 6. Mixed AF locator-set implementation and testing. 1606 7. Interworking draft [INTERWORK] implementation. 1608 As of this writing the following accomplishments have been achieved: 1610 1. A unit tested software switching implementation has been 1611 completed for both IPv4 and IPv6 encapsulations for LISP 1 and 1612 LISP 1.5 [ALT] functionality. The implementation supports 1613 locator reachability and mobility features. 1615 2. Dave Meyer, Vince Fuller, Darrel Lewis, and Greg Shepherd 1616 continue to test the implementation using LISP-ALT as the 1617 database mapping mechanism. 1619 3. A server implementation of NERD has been completed as well as 1620 client NERD verification code by Eliot Lear. 1622 4. An implementation of LISP-CONS is being delayed in lieu of 1623 experience gathered using LISP-ALT. 1625 5. An public domain implementation of LISP is underway. See 1626 [OPENLISP] for details. 1628 Please contact authors if interested in doing an implementation and 1629 want to interoperability test with our implementation. 1631 13. References 1633 13.1. Normative References 1635 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1636 August 1980. 1638 [RFC1498] Saltzer, J., "On the Naming and Binding of Network 1639 Destinations", RFC 1498, August 1993. 1641 [RFC1955] Hinden, R., "New Scheme for Internet Routing and 1642 Addressing (ENCAPS) for IPNG", RFC 1955, June 1996. 1644 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1645 Requirement Levels", BCP 14, RFC 2119, March 1997. 1647 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1648 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1649 October 1998. 1651 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 1652 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 1653 March 2000. 1655 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1656 via IPv4 Clouds", RFC 3056, February 2001. 1658 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1659 in IPv6", RFC 3775, June 2004. 1661 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 1662 (HIP) Architecture", RFC 4423, May 2006. 1664 [RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route 1665 Optimization for Mobile IPv6", RFC 4866, May 2007. 1667 [RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB 1668 Workshop on Routing and Addressing", RFC 4984, 1669 September 2007. 1671 13.2. Informative References 1673 [AFI] IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY 1674 NUMBERS http://www.iana.org/numbers.html, Febuary 2007. 1676 [ALT] Farinacci, D., Fuller, V., and D. Meyer, "LISP Alternative 1677 Topology (LISP-ALT)", draft-fuller-lisp-alt-01.txt (work 1678 in progress), November 2007. 1680 [APT] Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and 1681 L. Zhang, "APT: A Practical Transit Mapping Service", 1682 draft-jen-apt-00.txt (work in progress), July 2007. 1684 [CHIAPPA] Chiappa, J., "Endpoints and Endpoint names: A Proposed 1685 Enhancement to the Internet Architecture", Internet- 1686 Draft http://www.chiappa.net/~jnc/tech/endpoints.txt, 1687 1999. 1689 [CONS] Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A 1690 Content distribution Overlay Network Service for LISP", 1691 draft-meyer-lisp-cons-03.txt (work in progress), 1692 November 2007. 1694 [DHTs] Ratnasamy, S., Shenker, S., and I. Stoica, "Routing 1695 Algorithms for DHTs: Some Open Questions", PDF 1696 file http://www.cs.rice.edu/Conferences/IPTPS02/174.pdf. 1698 [GSE] "GSE - An Alternate Addressing Architecture for IPv6", 1699 draft-ietf-ipngwg-gseaddr-00.txt (work in progress), 1997. 1701 [INTERWORK] 1702 Lewis, D., Meyer, D., and D. Farinacci, "Interworking LISP 1703 with IPv4 and IPv6", draft-lewis-lisp-interworking-00.txt 1704 (work in progress), December 2007. 1706 [LISA96] Lear, E., Katinsky, J., Coffin, J., and D. Tharp, 1707 "Renumbering: Threat or Menace?", Usenix , September 1996. 1709 [LISP1] Farinacci, D., Oran, D., Fuller, V., and J. Schiller, 1710 "Locator/ID Separation Protocol (LISP1) [Routable ID 1711 Version]", 1712 Slide-set http://www.dinof.net/~dino/ietf/lisp1.ppt, 1713 October 2006. 1715 [LISP2] Farinacci, D., Oran, D., Fuller, V., and J. Schiller, 1716 "Locator/ID Separation Protocol (LISP2) [DNS-based 1717 Version]", 1718 Slide-set http://www.dinof.net/~dino/ietf/lisp2.ppt, 1719 November 2006. 1721 [LISPDHT] Mathy, L., Iannone, L., and O. Bonaventure, "LISP-DHT: 1722 Towards a DHT to map identifiers onto locators", 1723 draft-mathy-lisp-dht-00.txt (work in progress), 1724 February 2008. 1726 [MLISP] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, 1727 "LISP for Multicast Environments", 1728 draft-farinacci-lisp-multicast-00.txt (work in progress), 1729 April 2008. 1731 [NERD] Lear, E., "NERD: A Not-so-novel EID to RLOC Database", 1732 draft-lear-lisp-nerd-02.txt (work in progress), 1733 January 2008. 1735 [OPENLISP] 1736 Iannone, L. and O. Bonaventure, "OpenLISP Implementation 1737 Report", draft-iannone-openlisp-implementation-00.txt 1738 (work in progress), February 2008. 1740 [RADIR] Narten, T., "Routing and Addressing Problem Statement", 1741 draft-narten-radir-problem-statement-00.txt (work in 1742 progress), July 2007. 1744 [RFC3344bis] 1745 Perkins, C., "IP Mobility Support for IPv4, revised", 1746 draft-ietf-mip4-rfc3344bis-05 (work in progress), 1747 July 2007. 1749 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 1750 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 1751 September 2005. 1753 [RPFV] Wijnands, IJ., Boers, A., and E. Rosen, "The RPF Vector 1754 TLV", draft-ietf-pim-rpf-vector-03.txt (work in progress), 1755 October 2006. 1757 [RPMD] Handley, M., Huici, F., and A. Greenhalgh, "RPMD: Protocol 1758 for Routing Protocol Meta-data Dissemination", 1759 draft-handley-p2ppush-unpublished-2007726.txt (work in 1760 progress), July 2007. 1762 [SHIM6] Nordmark, E. and M. Bagnulo, "Level 3 multihoming shim 1763 protocol", draft-ietf-shim6-proto-06.txt (work in 1764 progress), October 2006. 1766 Appendix A. Acknowledgments 1768 The authors would like to gratefully acknowledge many people who have 1769 contributed discussion and ideas to the making of this proposal. 1770 They include Jason Schiller, Lixia Zhang, Dorian Kim, Peter 1771 Schoenmaker, Darrel Lewis, Vijay Gill, Geoff Huston, David Conrad, 1772 Mark Handley, Ron Bonica, Ted Seely, Mark Townsley, Chris Morrow, 1773 Brian Weis, Dave McGrew, Peter Lothberg, Dave Thaler, Eliot Lear, 1774 Shane Amante, Ved Kafle, Olivier Bonaventure, Luigi Iannone, Robin 1775 Whittle, Brian Carpenter, Joel Halpern, Roger Jorgensen, John 1776 Zwiebel, Ran Atkinson, Stig Venaas, Iljitsch van Beijnum, Scott Brim, 1777 Roland Bless, and Andrew Partan. 1779 In particular, we would like to thank Dave Meyer for his clever 1780 suggestion for the name "LISP". ;-) 1782 Authors' Addresses 1784 Dino Farinacci 1785 cisco Systems 1786 Tasman Drive 1787 San Jose, CA 95134 1788 USA 1790 Email: dino@cisco.com 1792 Vince Fuller 1793 cisco Systems 1794 Tasman Drive 1795 San Jose, CA 95134 1796 USA 1798 Email: vaf@cisco.com 1800 Dave Oran 1801 cisco Systems 1802 7 Ladyslipper Lane 1803 Acton, MA 1804 USA 1806 Email: oran@cisco.com 1808 Dave Meyer 1809 cisco Systems 1810 170 Tasman Drive 1811 San Jose, CA 1812 USA 1814 Email: dmm@cisco.com 1816 Full Copyright Statement 1818 Copyright (C) The IETF Trust (2008). 1820 This document is subject to the rights, licenses and restrictions 1821 contained in BCP 78, and except as set forth therein, the authors 1822 retain all their rights. 1824 This document and the information contained herein are provided on an 1825 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1826 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1827 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1828 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1829 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1830 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1832 Intellectual Property 1834 The IETF takes no position regarding the validity or scope of any 1835 Intellectual Property Rights or other rights that might be claimed to 1836 pertain to the implementation or use of the technology described in 1837 this document or the extent to which any license under such rights 1838 might or might not be available; nor does it represent that it has 1839 made any independent effort to identify any such rights. Information 1840 on the procedures with respect to rights in RFC documents can be 1841 found in BCP 78 and BCP 79. 1843 Copies of IPR disclosures made to the IETF Secretariat and any 1844 assurances of licenses to be made available, or the result of an 1845 attempt made to obtain a general license or permission for the use of 1846 such proprietary rights by implementers or users of this 1847 specification can be obtained from the IETF on-line IPR repository at 1848 http://www.ietf.org/ipr. 1850 The IETF invites any interested party to bring to its attention any 1851 copyrights, patents or patent applications, or other proprietary 1852 rights that may cover technology that may be required to implement 1853 this standard. Please address the information to the IETF at 1854 ietf-ipr@ietf.org. 1856 Acknowledgment 1858 Funding for the RFC Editor function is provided by the IETF 1859 Administrative Support Activity (IASA).