idnits 2.17.1 draft-farinacci-lisp-06.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 1791. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1802. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1809. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1815. 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 (February 27, 2008) is 5901 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 (-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 (~~), 13 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: August 30, 2008 D. Meyer 6 cisco Systems 7 February 27, 2008 9 Locator/ID Separation Protocol (LISP) 10 draft-farinacci-lisp-06.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 August 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 . . . . . . . . . . . . . . 32 76 8. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 33 77 8.1. First-hop/Last-hop Tunnel Routers . . . . . . . . . . . . 34 78 8.2. Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 34 79 8.3. ISP Provider-Edge (PE) Tunnel Routers . . . . . . . . . . 35 80 9. Mobility Considerations . . . . . . . . . . . . . . . . . . . 36 81 9.1. Site Mobility . . . . . . . . . . . . . . . . . . . . . . 36 82 9.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 36 83 9.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 36 84 9.4. Fast Network Mobility . . . . . . . . . . . . . . . . . . 38 85 10. Multicast Considerations . . . . . . . . . . . . . . . . . . . 39 86 11. Security Considerations . . . . . . . . . . . . . . . . . . . 40 87 12. Prototype Plans and Status . . . . . . . . . . . . . . . . . . 41 88 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 89 13.1. Normative References . . . . . . . . . . . . . . . . . . . 43 90 13.2. Informative References . . . . . . . . . . . . . . . . . . 43 91 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 46 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 93 Intellectual Property and Copyright Statements . . . . . . . . . . 48 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: where EIDs are routable through the RLOC topology for 183 bootstrapping EID-to-RLOC mappings. [LISP1] 185 LISP 1.5: where EIDs are routable for bootstrapping EID-to-RLOC 186 mappings; such routing is via a separate topology. 188 LISP 2: where EIDS are not routable and EID-to-RLOC mappings are 189 implemented within the DNS. [LISP2] 191 LISP 3: where non-routable EIDs are used as lookup keys for a new 192 EID-to-RLOC mapping database. Use of Distributed Hash Tables 193 [DHTs] [LISPDHT] to implement such a database would be an area to 194 explore. Other examples of new mapping database services are 195 [CONS], [ALT], [RPMD], [NERD], and [APT]. 197 This document will focus on LISP 1 and LISP 1.5, both of which rely 198 on a router-based distributed cache and database for EID-to-RLOC 199 mappings. The LISP 2 and LISP 3 mechanisms, which require separate 200 EID-to-RLOC infrastructure, will be documented elsewhere. 202 3. Definition of Terms 204 Provider Independent (PI) Addresses: an address block assigned from 205 a pool that is not associated with any service provider and is 206 therefore not topologically-aggregatable in the routing system. 208 Provider Assigned (PA) Addresses: a block of IP addresses that are 209 assigned to a site by each service provider to which a site 210 connects. Typically, each block is sub-block of a service 211 provider CIDR block and is aggregated into the larger block before 212 being advertised into the global Internet. Traditionally, IP 213 multihoming has been implemented by each multi-homed site 214 acquiring its own, globally-visible prefix. LISP uses only 215 topologically-assigned and aggregatable address blocks for RLOCs, 216 eliminating this demonstrably non-scalable practice. 218 Routing Locator (RLOC): the IPv4 or IPv6 address of an egress 219 tunnel router (ETR). It is the output of a EID-to-RLOC mapping 220 lookup. An EID maps to one or more RLOCs. Typically, RLOCs are 221 numbered from topologically-aggregatable blocks that are assigned 222 to a site at each point to which it attaches to the global 223 Internet; where the topology is defined by the connectivity of 224 provider networks, RLOCs can be thought of as PA addresses. 225 Multiple RLOCs can be assigned to the same ETR device or to 226 multiple ETR devices at a site. 228 Endpoint ID (EID): a 32- or 128-bit value used in the source and 229 destination address fields of the first (most inner) LISP header 230 of a packet. The host obtains a destination EID the same way it 231 obtains an destination address today, for example through a DNS 232 lookup or SIP exchange. The source EID is obtained via existing 233 mechanisms used to set a hosts "local" IP address. An EID is 234 allocated to a host from an EID-prefix block associated with the 235 site the host is attached to. An EID can be used by a host to 236 refer to other hosts. LISP uses PI blocks for EIDs; such EIDs 237 MUST NOT be used as LISP RLOCs. Note that EID blocks may be 238 assigned in a hierarchical manner, independent of the network 239 topology, to facilitate scaling of the mapping database. In 240 addition, an EID block assigned to a site may have site-local 241 structure (subnetting) for routing within the site; this structure 242 is not visible to the global routing system. 244 EID-prefix: A power-of-2 block of EIDs which are allocated to a 245 site by an address allocation authority. EID-prefixes are 246 associated with a set of RLOC addresses which make up a "database 247 mapping". EID-prefix allocations can be broken up into smaller 248 blocks when an RLOC set is to be associated with the smaller EID- 249 prefix. 251 End-system: is an IPv4 or IPv6 device that originates packets with 252 a single IPv4 or IPv6 header. The end-system supplies an EID 253 value for the destination address field of the IP header when 254 communicating globally (i.e. outside of it's routing domain). An 255 end-system can be a host computer, a switch or router device, or 256 any network appliance. An iPhone. 258 Ingress Tunnel Router (ITR): a router which accepts an IP packet 259 with a single IP header (more precisely, an IP packet that does 260 not contain a LISP header). The router treats this "inner" IP 261 destination address as an EID and performs an EID-to-RLOC mapping 262 lookup. The router then prepends an "outer" IP header with one of 263 its globally-routable RLOCs in the source address field and the 264 result of the mapping lookup in the destination address field. 265 Note that this destination RLOC may be an intermediate, proxy 266 device that has better knowledge of the EID-to-RLOC mapping 267 closest to the destination EID. In general, an ITR receives IP 268 packets from site end-systems on one side and sends LISP- 269 encapsulated IP packets toward the Internet on the other side. 271 Specifically, when a service provider prepends a LISP header for 272 Traffic Engineering purposes, the router that does this is also 273 regarded as an ITR. The outer RLOC the ISP ITR uses can be based 274 on the outer destination address (the originating ITR's supplied 275 RLOC) or the inner destination address (the originating hosts 276 supplied EID). 278 TE-ITR: is an ITR that is deployed in a service provider network 279 that prepends an additional LISP header for Traffic Engineering 280 purposes. 282 Egress Tunnel Router (ETR): a router that accepts an IP packet 283 where destination address in the "outer" IP header is one of its 284 own RLOCs. The router strips the "outer" header and forwards the 285 packet based on the next IP header found. In general, an ETR 286 receives LISP-encapsulated IP packets from the Internet on one 287 side and sends decapsulated IP packets to site end-systems on the 288 other side. ETR functionality does not have to be limited to a 289 router device. A server host can be the endpoint of a LISP tunnel 290 as well. 292 TE-ETR: is an ETR that is deployed in a service provider network 293 that strips an outer LISP header for Traffic Engineering purposes. 295 xTR: is a reference to an ITR or ETR when direction of data flow is 296 not part of the context description. xTR refers to the router that 297 is the tunnel endpoint. Used synonymously with the term "Tunnel 298 Router". For example, "An xTR can be located at the Customer Edge 299 (CE) router", meaning both ITR and ETR functionality is at the CE 300 router. 302 EID-to-RLOC Cache: a short-lived, on-demand database in an ITR that 303 stores, tracks, and is responsible for timing-out and otherwise 304 validating EID-to-RLOC mappings. This cache is distinct from the 305 "database", the cache is dynamic, local, and relatively small 306 while and the database is distributed, relatively static, and much 307 global in scope. 309 EID-to-RLOC Database: a globally, distributed database that 310 contains all known EID-prefix to RLOC mappings. Each potential 311 ETR typically contains a small piece of the database: the EID-to- 312 RLOC mappings for the EID prefixes "behind" the router. These map 313 to one of the router's own, globally-visible, IP addresses. 315 Recursive Tunneling: when a packet has more than one LISP IP 316 header. Additional layers of tunneling may be employed to 317 implement traffic engineering or other re-routing as needed. When 318 this is done, an additional "outer" LISP header is added and the 319 original RLOCs are preserved in the "inner" header. 321 Reencapsulating Tunnels: when a packet has no more than one LISP IP 322 header (two IP headers total) and when it needs to be diverted to 323 new RLOC, an ETR can decapsulate the packet (remove the LISP 324 header) and prepend a new tunnel header, with new RLOC, on to the 325 packet. Doing this allows a packet to be re-routed by the re- 326 encapsulating router without adding the overhead of additional 327 tunnel headers. 329 LISP Header: a term used in this document to refer to the outer 330 IPv4 or IPv6 header, a UDP header, and a LISP header, an ITR 331 prepends or an ETR strips. 333 Address Family Indicator (AFI): a term used to describe an address 334 encoding in a packet. An address family currently pertains to an 335 IPv4 or IPv6 address. See [AFI] for details. 337 Negative Mapping Entry: also known as a negative cache entry, is an 338 EID-to-RLOC entry where an EID-prefix is advertised or stored with 339 no RLOCs. That is, the locator-set for the EID-to-RLOC entry is 340 empty or has an encoded locator count of 0. This type of entry 341 could be used to describe a prefix from a non-LISP site, which is 342 explicitly not in the mapping database. 344 Data Probe: a packet originated by an end-host at one site (the 345 source), encapsulated by the source site's ITR, sent to an ETR at 346 a second site (the destination), then delivered to the destination 347 end-host. A new LISP header is added to the packet with 348 destination address in this new "outer header" copied from the 349 original destination address (now the "inner header"). on receipt 350 by the destination site's ETR, a "data triggered" Map-Reply is 351 returned to the ITR. In addition, the original packet is de- 352 encapsulated and delivered to the destination host. A Data Probe 353 is used in some of the mapping database designs to "probe" or 354 request a Map-Reply from an ETR; in other cases, Map-Requests are 355 used. See each mapping database design for details. 357 4. Basic Overview 359 One key concept of LISP is that end-systems (hosts) operate the same 360 way they do today. The IP addresses that hosts use for tracking 361 sockets, connections, and for sending and receiving packets do not 362 change. In LISP terminology, these IP addresses are called Endpoint 363 Identifiers (EIDs). 365 Routers continue to forward packets based on IP destination 366 addresses. These addresses are referred to as Routing Locators 367 (RLOCs). Most routers along a path between two hosts will not 368 change; they continue to perform routing/forwarding lookups on 369 addresses (RLOCs) in the IP header. 371 This design introduces "Tunnel Routers", which prepend LISP headers 372 on host-originated packets and strip them prior to final delivery to 373 their destination. The IP addresses in this "outer header" are 374 RLOCs. During end-to-end packet exchange between two Internet hosts, 375 an ITR prepends a new LISP header to each packet and an egress tunnel 376 router strips the new header. The ITR performs EID-to-RLOC lookups 377 to determine the routing path to the the ETR, which has the RLOC as 378 one of its IP addresses. 380 Some basic rules governing LISP are: 382 o End-systems (hosts) only know about EIDs. 384 o EIDs are always IP addresses assigned to hosts. 386 o LISP routers mostly deal with Routing Locator addresses. See 387 details later in Section 4.1 to clarify what is meant by "mostly". 389 o RLOCs are always IP addresses assigned to routers; preferably, 390 topologically-oriented addresses from provider CIDR blocks. 392 o When a router originates packets it may use as a source address 393 either an EID or RLOC. When acting as a host (e.g. when 394 terminating a transport session such as SSH, TELNET, or SNMP), it 395 may use an EID that is explicitly assigned for that purpose. An 396 EID that identifies the router as a host MUST NOT be used as an 397 RLOC. Keep in mind that an EID is only routable within the scope 398 of a site. A typical BGP configuration might demonstrate this 399 "hybrid" EID/RLOC usage where a router could use its "host-like" 400 EID to terminate iBGP sessions to other routers in a site while at 401 the same time using RLOCs to terminate eBGP sessions to routers 402 outside the site. 404 o EIDs are not expected to be usable for global end-to-end 405 communication in the absence of an EID-to-RLOC mapping operation. 406 They are expected to be used locally for intra-site communication. 408 o EID prefixes are likely to be hierarchically assigned in a manner 409 which is optimized for administrative convenience and to 410 facilitate scaling of the EID-to-RLOC mapping database. The 411 hierarchy is based on a address allocation hierarchy which is not 412 dependent on the network topology. 414 o EIDs may also be structured (subnetted) in a manner suitable for 415 local routing within an autonomous system. 417 An additional LISP header may be pre-pended to packets by a transit 418 router (i.e. TE-ITR) when re-routing of the end-to-end path for a 419 packet is desired. An obvious instance of this would be an ISP 420 router that needs to perform traffic engineering for packets in flow 421 through its network. In such a situation, termed Recursive 422 Tunneling, an ISP transit acts as an additional ingress tunnel router 423 and the RLOC it uses for the new prepended header would be either an 424 TE-ETR within the ISP (along intra-ISP traffic engineered path) or in 425 an TE-ETR within another ISP (an inter-ISP traffic engineered path, 426 where an agreement to build such a path exists). 428 Tunnel Routers can be placed fairly flexibly in a multi-AS topology. 429 For example, the ITR for a particular end-to-end packet exchange 430 might be the first-hop or default router within a site for the source 431 host. Similarly, the egress tunnel router might be the last-hop 432 router directly-connected to the destination host. Another example, 433 perhaps for a VPN service out-sourced to an ISP by a site, the ITR 434 could be the site's border router at the service provider attachment 435 point. Mixing and matching of site-operated, ISP-operated, and other 436 tunnel routers is allowed for maximum flexibility. See Section 8 for 437 more details. 439 4.1. Packet Flow Sequence 441 This section provides an example of the unicast packet flow with the 442 following parameters: 444 o Source host "host1.abc.com" is sending a packet to 445 "host2.xyz.com". 447 o Each site is multi-homed, so each tunnel router has an address 448 (RLOC) assigned from each of the site's attached service provider 449 address blocks. 451 o The ITR and ETR are directly connected to the source and 452 destination, respectively. 454 Client host1.abc.com wants to communicate with server host2.xyz.com: 456 1. host1.abc.com wants to open a TCP connection to host2.xyz.com. 457 It does a DNS lookup on host2.xyz.com. An A/AAAA record is 458 returned. This address is used as the destination EID and the 459 locally-assigned address of host1.abc.com is used as the source 460 EID. An IP/IPv6 packet is built using the EIDs in the IP/IPv6 461 header and sent to the default router. 463 2. The default router is configured as an ITR. It prepends a LISP 464 header to the packet, with one of its RLOCs as the source IP/IPv6 465 address and uses the destination EID from the original packet 466 header as the destination IP/IPv6 address. Subsequent packets 467 continue to behave the same way until a mapping is learned. 469 3. In LISP 1, the packet is routed through the Internet as it is 470 today. In LISP 1.5, the packet is routed on a different topology 471 which may have EID prefixes distributed and advertised in an 472 aggregatable fashion. In either case, the packet arrives at the 473 ETR. The router is configured to "punt" the packet to the 474 router's control-plane processor. See Section 7 for more 475 details. 477 4. The LISP header is stripped so that the packet can be forwarded 478 by the router control-plane. The router looks up the destination 479 EID in the router's EID-to-RLOC database (not the cache, but the 480 configured data structure of RLOCs). An EID-to-RLOC Map-Reply 481 message is originated by the egress router and is addressed to 482 the source RLOC from the LISP header of the original packet (this 483 is the ITR). The source RLOC in the IP header of the UDP message 484 is one of the ETR's RLOCs (one of the RLOCs that is embedded in 485 the UDP payload). 487 5. The ITR receives the UDP message, parses the message (to check 488 for format validity) and stores the EID-to-RLOC information from 489 the packet. This information is put in the ITR's EID-to-RLOC 490 mapping cache (this is the on-demand cache, the cache where 491 entries time out due to inactivity). 493 6. Subsequent packets from host1.abc.com to host2.xyz.com will have 494 a LISP header prepended with the RLOCs learned from the ETR. 496 7. The egress tunnel receives these packets directly (since the 497 destination address is one of its assigned IP addresses), strips 498 the LISP header and delivers the packets to the attached 499 destination host. 501 In order to eliminate the need for a mapping lookup in the reverse 502 direction, an ETR MAY create a cache entry that maps the source EID 503 (inner header source IP address) to the source RLOC (outer header 504 source IP address) in a received LISP packet. Such a cache entry is 505 termed a "gleaned" mapping and only contains a single RLOC for the 506 EID in question. More complete information about additional RLOCs 507 SHOULD be verified by sending a LISP Map-Request for that EID. Both 508 ITR and the ETR may also influence the decision the other makes in 509 selecting an RLOC. See Section 6 for more details. 511 5. Tunneling Details 513 This section describes the LISP Data Message which defines the 514 tunneling header used to encapsulate IPv4 and IPv6 packets which 515 contain EID addresses. Even though the following formats illustrate 516 IPv4-in-IPv4 and IPv6-in-IPv6 encapsulations, the other 2 517 combinations are supported as well. 519 Since additional tunnel headers are prepended, the packet becomes 520 larger and in theory can exceed the MTU of any link traversed from 521 the ITR to the ETR. It is recommended, in IPv4 that packets do not 522 get fragmented as they are encapsulated by the ITR. Instead, the 523 packet is dropped and an ICMP Too Big message is returned to the 524 source. 526 Based on informal surveys of large ISP traffic patterns, it appears 527 that most transit paths can accommodate a path MTU of at least 4470 528 bytes. The exceptions, in terms of data rate, number of hosts 529 affected, or any other metric are expected to be vanishingly small. 531 To address MTU concerns, mainly raised on the RRG mailing list, the 532 LISP deployment process will include collecting data during its pilot 533 phase to either verify or refute the assumption about minimum 534 available MTU. If the assumption proves true and transit networks 535 with links limited to 1500 byte MTUs are corner cases, it would seem 536 more cost-effective to either upgrade or modify the equipment in 537 those transit networks to support larger MTUs or to use existing 538 mechanisms for accommodating packets that are too large. 540 For this reason, there is currently no plan for LISP to add an 541 additional, complex mechanism for implementing fragmentation and 542 reassembly in the face of limited-MTU transit links. If analysis 543 during LISP pilot deployment reveals that the assumption of 544 essentially ubiquitous, 4470+ byte transit path MTUs, is incorrect, 545 then LISP can be modified prior to protocol standardization to add 546 support for one of the proposed fragmentation and reassembly schemes. 547 Note that one simple scheme is detailed in Section 5.4. 549 5.1. LISP IPv4-in-IPv4 Header Format 551 0 1 2 3 552 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 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 / |Version| IHL |Type of Service| Total Length | 555 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 / | Identification |Flags| Fragment Offset | 557 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 OH | Time to Live | Protocol = 17 | Header Checksum | 559 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 \ | Source Routing Locator | 561 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 \ | Destination Routing Locator | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 / | Source Port = xxxx | Dest Port = 4341 | 565 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 \ | UDP Length | UDP Checksum | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 / |M| Locator Reach Bits | 569 LISP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 \ | Nonce | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 / |Version| IHL |Type of Service| Total Length | 573 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 / | Identification |Flags| Fragment Offset | 575 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 IH | Time to Live | Protocol | Header Checksum | 577 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 \ | Source EID | 579 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 \ | Destination EID | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 5.2. LISP IPv6-in-IPv6 Header Format 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 / |Version| Traffic Class | Flow Label | 587 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 / | Payload Length | Next Header=17| Hop Limit | 589 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | | 591 O + + 592 u | | 593 t + Source Routing Locator + 594 e | | 595 r + + 596 | | 597 H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 d | | 599 r + + 600 | | 601 \ + Destination Routing Locator + 602 \ | | 603 \ + + 604 \ | | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 / | Source Port = xxxx | Dest Port = 4341 | 607 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 \ | UDP Length | UDP Checksum | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 / |M| Locator Reach Bits | 611 LISP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 \ | Nonce | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 / |Version| Traffic Class | Flow Label | 615 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 / | Payload Length | Next Header | Hop Limit | 617 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | | 619 I + + 620 n | | 621 n + Source EID + 622 e | | 623 r + + 624 | | 625 H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 d | | 627 r + + 628 | | 630 \ + Destination EID + 631 \ | | 632 \ + + 633 \ | | 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 5.3. Tunnel Header Field Descriptions 638 IH Header: is the inner header, preserved from the datagram received 639 from the originating host. The source and destination IP 640 addresses are EIDs. 642 OH Header: is the outer header prepended by an ITR. The address 643 fields contain RLOCs obtained from the ingress router's EID-to- 644 RLOC cache. The IP protocol number is "UDP (17)" from [RFC0768]. 646 UDP Header: contains a random source port allocated by the ITR when 647 encapsulating a packet. The destination port MUST be set to the 648 well-known IANA assigned port value 4341. 650 UDP Checksum: this field field MUST be transmitted as 0 and ignored 651 on receipt by the ETR. Note, even when the UDP checksum is 652 transmitted as 0 an intervening NAT device can recalculate the 653 checksum and rewrite the UDP checksum field to non-zero. For 654 performance reasons, the ETR MUST ignore the checksum and MUST not 655 do a checksum computation. 657 UDP Length: for an IPv4 encapsulated packet, the inner header Total 658 Length plus the UDP and LISP header lengths are used. For an IPv6 659 encapsulated packet, the inner header Payload Length plus the size 660 of the IPv6 header (40 bytes) plus the size of the UDP and LISP 661 headers are used. The UDP header length is 8 bytes. The LISP 662 header length is 8 bytes. 664 LISP Locator Reach Bits: in the LISP header are set by an ITR to 665 indicate to an ETR the reachability of the Locators in the source 666 site. Each RLOC in a Map-Reply is assigned an ordinal value from 667 0 to n-1 (when there are n RLOCs in a mapping entry). The Locator 668 Reach Bits are numbered from 0 to n-1 from the right significant 669 bit of the 32-bit field. When a bit is set to 1, the ITR is 670 indicating to the ETR the RLOC associated with the bit ordinal is 671 reachable. See Section 6.3 for details on how an ITR can 672 determine other ITRs at the site are reachable. When a site has 673 multiple EID-prefixes which result in multiple mappings (where 674 each could have a different locator-set), the Locator Reach Bits 675 setting in an encapsulated packet MUST reflect the mapping for the 676 EID-prefix that the inner-header source EID address matches. When 677 the M bit is set, an additional 32-bit locator reachability field 678 follows, which may have an M-bit set for further extension (and so 679 on). This extension mechanism allows an EID to be mapped to an 680 arbitrary number of RLOCs, subject only to the maximum number of 681 32-bit fields that can fit into the response packet. For 682 practical purposes, a future version of this specification will 683 likely set a limit on the number of these fields. 685 LISP Nonce: is a 32-bit value that is randomly generated by an ITR. 686 It is used to test route-returnability when an ETR echos back the 687 nonce in a Map-Reply message. 689 When doing Recursive Tunneling: 691 o The OH header Time to Live field (or Hop Limit field, in case of 692 IPv6) MUST be copied from the IH header Time to Live field. 694 o The OH header Type of Service field (or the Traffic Class field, 695 in the case of IPv6) SHOULD be copied from the IH header Type of 696 Service field. 698 When doing Re-encapsulated Tunneling: 700 o The new OH header Time to Live field SHOULD be copied from the 701 stripped OH header Time to Live field. 703 o The new OH header Type of Service field SHOULD be copied from the 704 stripped OH header Type of Service field. 706 Copying the TTL serves two purposes: first, it preserves the distance 707 the host intended the packet to travel; second, and more importantly, 708 it provides for suppression of looping packets in the event there is 709 a loop of concatenated tunnels due to misconfiguration. 711 5.4. Dealing with Large Encapsulated Packets 713 In the event that the MTU issues mentioned above prove to be more 714 serious than expected, this section proposes a simple and stateless 715 mechanism to deal with large packets. The mechanism is described as 716 follows: 718 1. Define an architectural constant S for the maximum size of a 719 packet, in bytes, an ITR would receive from a source inside of 720 its site. 722 2. Define L to be the maximum size, in bytes, a packet of size S 723 would be after the ITR prepends the LISP header, UDP header, and 724 outer network layer header of size H. 726 3. Calculate: S + H = L. 728 When an ITR receives a packet of size greater than L on a site-facing 729 interface and that packet needs to be encapsulated, it resolves the 730 MTU issue by first splitting the original packet into 2 equal-sized 731 fragments. A LISP header is then pre-pended to each fragment. This 732 will ensure that the new, encapsulated packets are of size (S/2 + H), 733 which is always below the effective tunnel MTU. 735 When an ETR receives encapsulated fragments, it treats them as two 736 individually encapsulated packets. It strips the LISP headers then 737 forwards each packet to the destination host of the destination site. 738 The two fragments are reassembled at the destination host into the 739 single IP datagram that was originated by the source host. 741 This behavior is performed by the ITR when the source host originates 742 a packet when the DF field of the IP header is set to 0. When the DF 743 field of the IP header is set to 1, or the packet is an IPv6 packet 744 originated by the source host, the ITR will drop the packet when the 745 size is greater than L, and sends an ICMP Too Big message to the 746 source with a value of S, where S is (L - H). 748 This specification recommends that L be defined as 1500. 750 6. EID-to-RLOC Mapping 752 6.1. Control-Plane Packet Format 754 When LISP 1 or LISP 1.5 are used, new UDP packet types encode the 755 EID-to-RLOC mappings: 757 0 1 2 3 758 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 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 |Version| IHL |Type of Service| Total Length | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | Identification |Flags| Fragment Offset | 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 | Time to Live | Protocol = 17 | Header Checksum | 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 | Source Routing Locator | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 | Destination Routing Locator | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 / | Source Port | Dest Port | 771 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 \ | UDP Length | UDP Checksum | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 | | 775 | LISP Message | 776 | | 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 |Version| Traffic Class | Flow Label | 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 | Payload Length | Next Header=17| Hop Limit | 783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 784 | | 785 + + 786 | | 787 + Source Routing Locator + 788 | | 789 + + 790 | | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | | 793 + + 794 | | 795 + Destination Routing Locator + 796 | | 797 + + 798 | | 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 / | Source Port | Dest Port | 801 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 \ | UDP Length | UDP Checksum | 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 | | 805 | LISP Message | 806 | | 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 The LISP UDP-based messages are the Map-Request and Map-Reply 810 messages. When a UDP Map-Request is sent, the UDP source port is 811 chosen by the sender and the destination UDP port number is set to 812 4342. When a UDP Map-Reply is sent, the source UDP port number is 813 set to 4342 and the destination UDP port number is copied from the 814 source port of either the Map-Request of the invoking data packet. 816 The UDP Length field will reflect the length of the UDP header and 817 the LISP Message payload. 819 The UDP Checksum is computed and set to non-zero for Map-Request and 820 Map-Reply messages. It MUST be checked on receipt and if the 821 checksum fails, the packet MUST be dropped. 823 LISP-CONS [CONS] and LISP-ALT [ALT] use TCP to send LISP control 824 messages. The format of control messages includes the UDP header so 825 the checksum and length fields can be used to protect and delimit 826 message boundaries. 828 This main LISP specification is the authoritative source for message 829 format definitions for the Map-Request and Map-Reply messages. 831 6.1.1. LISP Packet Type Allocations 833 This section will be the authoritative source for allocating LISP 834 Type values. Current allocations are: 836 Reserved: 0 b'0000' 837 LISP Map-Request: 1 b'0001' 838 LISP Map-Reply: 2 b'0010' 839 LISP-CONS Open Message: 8 b'1000' 840 LISP-CONS Push-Add Message: 9 b'1001' 841 LISP-CONS Push-Delete Message: 10 b'1010' 842 LISP-CONS Uneachable Message: 11 b'1011' 844 6.1.2. Map-Request Message Format 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 |M| Locator Reach Bits | 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 | Nonce | 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 |Type=1 |Rsvd |A| Record Cnt | ITR-AFI | 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 | Originating ITR RLOC Address | 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 Rec -> | EID mask-len | EID-AFI | EID-prefix ... | 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 | Mapping Protocol Data | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 Packet field descriptions: 862 Locator Reach Bits: Refer to Section 5.3. 864 Nonce: A 4-byte random value created by the sender of the Map- 865 Request. 867 Type: 1 (Map-Request) 869 Rsvd: Set to 0 on transmission and ignored on receipt. 871 A: This is an authoritative bit, which is set to 0 for UDP-based Map- 872 Requests sent by an ITR. See other control-specific documents 873 [CONS] [ALT] for TCP-based Map-Requests. 875 Record Cnt: The number of records in this request message. A record 876 comprises of what is labeled 'Rec" above and occurs the number of 877 times equal to Record count. 879 ITR-AFI: Address family of the "Originating ITR RLOC Address" field. 881 Originating ITR RLOC Address: Set to 0 for UDP-based messages. See 882 [CONS] [ALT] for TCP-based Map-Requests. 884 EID mask-len: Mask length for EID prefix. 886 EID-AFI: Address family of EID-prefix according to [RFC2434] 888 EID-prefix: 4 bytes if an IPv4 address-family, 16 bytes if an IPv6 889 address-family. 891 Mapping Protocol Data: See [CONS] or [ALT] for details. 893 6.1.3. EID-to-RLOC UDP Map-Request Message 895 A Map-Request contains one or more EIDs encoded in prefix format with 896 a Locator count of 0. The EID-prefix MUST NOT be more specific than 897 a cache entry stored from a previously-received Map-Reply. 899 A Map-Request is sent from an ITR when it needs a mapping for an EID, 900 wants to test an RLOC for reachability, or wants to refresh a mapping 901 before TTL expiration. This is performed by using the RLOC as the 902 destination address for Map-Request message with a randomly allocated 903 source UDP port number and the well-known destination port number 904 4342. A successful Map-Reply updates the cached set of RLOCs 905 associated with the EID prefix range. 907 Map-Requests MUST be rate-limited. It is recommended that a Map- 908 Request for the same EID-prefix be sent no more than once per second. 910 6.1.4. Map-Reply Message Format 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 |M| Locator Reach Bits | 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 | Nonce | 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 |Type=2 | Reserved | Record Count | 918 +----> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 | | Record TTL | 920 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 | | Locator Count | EID mask-len |A| Reserved | 922 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 R | ITR-AFI | EID-AFI | 924 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 925 c | Originating ITR RLOC Address | 926 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 927 r | EID-prefix | 928 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 | /| Priority | Weight |R| Loc-AFI | 930 | Loc +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 931 | \| Locator | 932 +---> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 933 | Mapping Protocol Data | 934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 Packet field descriptions: 938 Locator Reach Bits: Refer to Section 5.3. When there are multiple 939 records in the Map-Reply message, this field is set to 0 and the 940 R-bit for each Locator record within each mapping record is used 941 to determine the locator reachability. 943 Nonce: A 4-byte value set in a data probe packet or a Map-Request 944 that is echoed here in the Map-Reply. 946 Type: 2 (Map-Reply) 948 Reserved: Set to 0 on transmission and ignored on receipt. 950 Record Count: The number of records in this reply message. A record 951 comprises of what is labeled 'Record' above and occurs the number 952 of times equal to Record count. 954 Record TTL: The time in minutes the recipient of the Map-Reply will 955 store the mapping. If the TTL is 0, the entry should be removed 956 from the cache immediately. If the value is 0xffffffff, the 957 recipient can decide locally how long to store the mapping. 959 Locator Count: The number of Locator entries. A locator entry 960 comprises what is labeled above as 'Loc'. 962 EID mask-len: Mask length for EID prefix. 964 A: The Authoritative bit, when sent by a UDP-based message is always 965 set by the ETR. See [CONS] [ALT] for TCP-based Map-Replies. 967 ITR-AFI: Address family of the "Originating ITR RLOC Address" field. 969 EID-AFI: Address family of EID-prefix according to [RFC2434]. 971 Originating ITR RLOC Address: Set to 0 for UDP-based messages. See 972 [CONS] [ALT] for TCP-based Map-Replies. 974 EID-prefix: 4 bytes if an IPv4 address-family, 16 bytes if an IPv6 975 address-family. 977 Priority: each RLOC is assigned a priority. Lower values are more 978 preferable. When multiple RLOCs have the same priority, they are 979 used in a load-split fashion. A value of 255 means the RLOC MUST 980 NOT be used. 982 Weight: when priorities are the same for multiple RLOCs, the weight 983 indicates how to balance traffic between them. Weight is encoded 984 as a percentage of total packets that match the mapping entry. If 985 a non-zero weight value is used for any RLOC, then all RLOCs must 986 use a non-zero weight value and then the sum of all weight values 987 MUST equal 100. What did the 3rd grader say after Steve Jobs gave 988 an iPhone demo to the class? If a zero value is used for any RLOC 989 weight, then all weights MUST be zero and the receiver of the Map- 990 Reply will decide how to load-split traffic. 992 R: when this bit is set, the locator is known to be reachable from 993 the Map-Reply sender's perspective. When there is a single 994 mapping record in the message, the R-bit for each locator must 995 have a consistent setting with the bitfield setting of the 'Loc 996 Reach Bits' field in the early part of the header. When there are 997 multiple mapping records in the message, the 'Loc Reach Bits' 998 field is set to 0. 1000 Locator: an IPv4 or IPv6 address (as encoded by the 'Loc-AFI' field) 1001 assigned to an ETR or router acting as a proxy replier for the 1002 EID-prefix. Note that the destination RLOC address MAY be an 1003 anycast address if the tunnel egress point may be via more than 1004 one physical device. A source RLOC can be an anycast address as 1005 well. The source or destination RLOC MUST NOT be the broadcast 1006 address (255.255.255.255 or any subnet broadcast address known to 1007 the router), and MUST NOT be a link-local multicast address. The 1008 source RLOC MUST NOT be a multicast address. The destination RLOC 1009 SHOULD be a multicast address if it is being mapped from a 1010 multicast destination EID. 1012 Mapping Protocol Data: See [CONS] or [ALT] for details. 1014 6.1.5. EID-to-RLOC UDP Map-Reply Message 1016 When a Data Probe packet or a Map-Request triggers a Map-Reply to be 1017 sent, the RLOCs associated with the EID-prefix matched by the EID in 1018 the original packet destination IP address field will be returned. 1019 The RLOCs in the Map-Reply are the globally-routable IP addresses of 1020 the ETR but are not necessarily reachable; separate testing of 1021 reachability is required. 1023 Note that a Map-Reply may contain different EID-prefix granularity 1024 (prefix + length) than the Map-Request which triggers it. This might 1025 occur if a Map-Request were for a prefix that had been returned by an 1026 earlier Map-Reply. In such a case, the requester updates its cache 1027 with the new prefix information and granularity. For example, a 1028 requester with two cached EID-prefixes that are covered by a Map- 1029 Reply containing one, less-specific prefix, replaces the entry with 1030 the less-specific EID-prefix. Note that the reverse, replacement of 1031 one less-specific prefix with multiple more-specific prefixes, can 1032 also occur but not by removing the less-specific prefix rather by 1033 adding the more-specific prefixes which during a lookup will override 1034 the less-specific prefix. 1036 Replies SHOULD be sent for an EID-prefix no more often than once per 1037 second to the same requesting router. For scalability, it is 1038 expected that aggregation of EID addresses into EID-prefixes will 1039 allow one Map-Reply to satisfy a mapping for the EID addresses in the 1040 prefix range thereby reducing the number of Map-Request messages. 1042 The addresses for a Data message or Map-Request message are swapped 1043 and used for sending the Map-Reply. The UDP source and destination 1044 ports are swapped as well. That is, the source port in the UDP 1045 header for the Map-Reply is set to the well-known UDP port number 1046 4342. 1048 6.2. Routing Locator Selection 1050 Both client-side and server-side may need control over the selection 1051 of RLOCs for conversations between them. This control is achieved by 1052 manipulating the Priority and Weight fields in EID-to-RLOC Map-Reply 1053 messages. Alternatively, RLOC information may be gleaned from 1054 received tunneled packets or EID-to-RLOC Map-Request messages. 1056 The following enumerates different scenarios for choosing RLOCs and 1057 the controls that are available: 1059 o Server-side returns one RLOC. Client-side can only use one RLOC. 1060 Server-side has complete control of the selection. 1062 o Server-side returns a list of RLOC where a subset of the list has 1063 the same best priority. Client can only use the subset list 1064 according to the weighting assigned by the server-side. In this 1065 case, the server-side controls both the subset list and load- 1066 splitting across its members. The client-side can use RLOCs 1067 outside of the subset list if it determines that the subset list 1068 is unreachable (unless RLOCs are set to a Priority of 255). Some 1069 sharing of control exists: the server-side determines the 1070 destination RLOC list and load distribution while the client-side 1071 has the option of using alternatives to this list if RLOCs in the 1072 list are unreachable. 1074 o Server-side sets weight of 0 for the RLOC subset list. In this 1075 case, the client-side can choose how the traffic load is spread 1076 across the subset list. Control is shared by the server-side 1077 determining the list and the client determining load distribution. 1078 Again, the client can use alternative RLOCs if the server-provided 1079 list of RLOCs are unreachable. 1081 o Either side (more likely on the server-side ETR) decides not to 1082 send an Map-Request. For example, if the server-side ETR does not 1083 send Map-Requests, it gleans RLOCs from the client-side ITR, 1084 giving the client-side ITR responsibility for bidirectional RLOC 1085 reachability and preferability. Server-side ETR gleaning of the 1086 client-side ITR RLOC is done by caching the inner header source 1087 EID and the outer header source RLOC of received packets. The 1088 client-side ITR controls how traffic is returned and can alternate 1089 using an outer header source RLOC, which then can be added to the 1090 list the server-side ETR uses to return traffic. Since no 1091 Priority or Weights are provided using this method, the server- 1092 side ETR must assume each client-side ITR RLOC uses the same best 1093 Priority with a Weight of zero. In addition, since EID-prefix 1094 encoding cannot be conveyed in data packets, the EID-to-RLOC cache 1095 on tunnel routers can grow to be very large. 1097 RLOCs that appear in EID-to-RLOC Map-Reply messages are considered 1098 reachable. The Map-Reply and the database mapping service does not 1099 provide any reachability status for Locators. This is done outside 1100 of the mapping service. See next section for details. 1102 6.3. Routing Locator Reachability 1104 There are 4 methods for determining when a Locator is either 1105 reachable or has become unreachable: 1107 1. Locator reachability is determined by an ETR by examining the 1108 Loc-Reach-Bits from a LISP header of a Data Message which is 1109 provided by an ITR when an ITR encapsulates data. 1111 2. Locator unreachability is determined by an ITR by receiving ICMP 1112 Network or Host Unreachable messages. 1114 3. ETR unreachability is determined when a host sends an ICMP Port 1115 Unreachable message. 1117 4. Locator reachability is determined by receiving a Map-Reply 1118 message from a ETR's Locator address in response to a previously 1119 sent Map-Request. 1121 When determining Locator reachability by examining the Loc-Reach-Bits 1122 from the LISP Data Message, an ETR will receive up to date status 1123 from the ITR closest to the Locators at the source site. The ITRs at 1124 the source site can determine reachability when running their IGP at 1125 the site. When the ITRs are deployed on CE routers, typically a 1126 default route is injected into the site's IGP from each of the ITRs. 1127 If an ITR goes down, the CE-PE link goes down, or the PE router goes 1128 down, the CE router withdraws the default route. This allows the 1129 other ITRs at the site to determine one of the Locators has gone 1130 unreachable. 1132 The Locators listed in a Map-Reply are numbered with ordinals 0 to 1133 n-1. The Loc-Reach-Bits in a LISP Data Message are numbered from 0 1134 to n-1 starting with the least significant bit numbered as 0. So, 1135 for example, if the ITR with locator listed as the 3rd Locator 1136 position in the Map-Reply goes down, all other ITRs at the site will 1137 have the 3rd bit from the right cleared (the bit that corresponds to 1138 ordinal 2). 1140 When an ETR decapsulates a packet, it will look for a change in the 1141 Loc-Reach-Bits value. When a bit goes from 1 to 0, the ETR will 1142 refrain from encapsulating packets to the Locator that has just gone 1143 unreachable. It can start using the Locator again when the bit that 1144 corresponds to the Locator goes from 0 to 1. 1146 When ITRs at the site are not deployed in CE routers, the IGP can 1147 still be used to determine the reachability of Locators provided they 1148 are injected a stub links into the IGP. This is typically done when 1149 a /32 address is configured on a loopback interface. 1151 When ITRs receive ICMP Network or Host Unreachable messages as a 1152 method to determine unreachability, they will refrain from using 1153 Locators which are described in Locator lists of Map-Replies. 1154 However, using this approach is unreliable because many network 1155 operators turn off generation of ICMP Unreachable messages. 1157 Optionally, an ITR can send a Map-Request to a Locator and if a Map- 1158 Reply is returned, reachability of the Locator has been achieved. 1159 Obviously, sending such probes increases the number of control 1160 messages originated by tunnel routers for active flows, so Locators 1161 are assumed to be reachable when they are advertised. 1163 This assumption does create a dependency: Locator unreachability is 1164 detected by the receipt of ICMP Host Unreachable messages. When an 1165 Locator has been determined unreachable, it is not used for active 1166 traffic; this is the same as if it were listed in a Map-Reply with 1167 priority 255. 1169 The ITR can later test the reachability of the unreachable Locator by 1170 sending periodic Requests. Both Requests and Replies MUST be rate- 1171 limited. Locator reachability testing is never done with data 1172 packets since that increases the risk of packet loss for end-to-end 1173 sessions. 1175 7. Router Performance Considerations 1177 LISP is designed to be very hardware-based forwarding friendly. By 1178 doing tunnel header prepending [RFC1955] and stripping instead of re- 1179 writing addresses, existing hardware could support the forwarding 1180 model with little or no modification. Where modifications are 1181 required, they should be limited to re-programming existing hardware 1182 rather than requiring expensive design changes to hard-coded 1183 algorithms in silicon. 1185 A few implementation techniques can be used to incrementally 1186 implement LISP: 1188 o When a tunnel encapsulated packet is received by an ETR, the outer 1189 destination address may not be the address of the router. This 1190 makes it challenging for the control-plane to get packets from the 1191 hardware. This may be mitigated by creating special FIB entries 1192 for the EID-prefixes of EIDs served by the ETR (those for which 1193 the router provides an RLOC translation). These FIB entries are 1194 marked with a flag indicating that control-plane processing should 1195 be performed. The forwarding logic of testing for particular IP 1196 protocol number value is not necessary. No changes to existing, 1197 deployed hardware should be needed to support this. 1199 o On an ITR, prepending a new IP header is as simple as adding more 1200 bytes to a MAC rewrite string and prepending the string as part of 1201 the outgoing encapsulation procedure. Many routers that support 1202 GRE tunneling [RFC2784] or 6to4 tunneling [RFC3056] can already 1203 support this action. 1205 o When a received packet's outer destination address contains an EID 1206 which is not intended to be forwarded on the routable topology 1207 (i.e. LISP 1.5), the source address of a data packet or the 1208 router interface with which the source is associated (the 1209 interface from which it was received) can be associated with a VRF 1210 (Virtual Routing/Forwarding), in which a different (i.e. non- 1211 congruent) topology can be used to find EID-to-RLOC mappings. 1213 8. Deployment Scenarios 1215 This section will explore how and where ITRs and ETRs can be deployed 1216 and will discuss the pros and cons of each deployment scenario. 1217 There are two basic deployment trade-offs to consider: centralized 1218 versus distributed caches and flat, recursive, or re-encapsulating 1219 tunneling. 1221 When deciding on centralized versus distributed caching, the 1222 following issues should be considered: 1224 o Are the tunnel routers spread out so that the caches are spread 1225 across all the memories of each router? 1227 o Should management "touch points" be minimized by choosing few 1228 tunnel routers, just enough for redundancy? 1230 o In general, using more ITRs doesn't increase management load, 1231 since caches are built and stored dynamically. On the other hand, 1232 more ETRs does require more management since EID-prefix-to-RLOC 1233 mappings need to be explicitly configured. 1235 When deciding on flat, recursive, or re-encapsulation tunneling, the 1236 following issues should be considered: 1238 o Flat tunneling implements a single tunnel between source site and 1239 destination site. This generally offers better paths between 1240 sources and destinations with a single tunnel path. 1242 o Recursive tunneling is when tunneled traffic is again further 1243 encapsulated in another tunnel, either to implement VPNs or to 1244 perform Traffic Engineering. When doing VPN-based tunneling, the 1245 site has some control since the site is prepending a new tunnel 1246 header. In the case of TE-based tunneling, the site may have 1247 control if it is prepending a new tunnel header, but if the site's 1248 ISP is doing the TE, then the site has no control. Recursive 1249 tunneling generally will result in suboptimal paths but at the 1250 benefit of steering traffic to resource available parts of the 1251 network. 1253 o The technique of re-encapsulation ensures that packets only 1254 require one tunnel header. So if a packet needs to be rerouted, 1255 it is first decapsulated by the ETR and then re-encapsulated with 1256 a new tunnel header using a new RLOC. 1258 The next sub-sections will describe where tunnel routers can reside 1259 in the network. 1261 8.1. First-hop/Last-hop Tunnel Routers 1263 By locating tunnel routers close to hosts, the EID-prefix set is at 1264 the granularity of an IP subnet. So at the expense of more EID- 1265 prefix-to-RLOC sets for the site, the caches in each tunnel router 1266 can remain relatively small. But caches always depend on the number 1267 of non-aggregated EID destination flows active through these tunnel 1268 routers. 1270 With more tunnel routers doing encapsulation, the increase in control 1271 traffic grows as well: since the EID-granularity is greater, more 1272 Map-Requests and replies are traveling between more routers. 1274 The advantage of placing the caches and databases at these stub 1275 routers is that the products deployed in this part of the network 1276 have better price-memory ratios then their core router counterparts. 1277 Memory is typically less expensive in these devices and fewer routes 1278 are stored (only IGP routes). These devices tend to have excess 1279 capacity, both for forwarding and routing state. 1281 LISP functionality can also be deployed in edge switches. These 1282 devices generally have layer-2 ports facing hosts and layer-3 ports 1283 facing the Internet. Spare capacity is also often available in these 1284 devices as well. 1286 8.2. Border/Edge Tunnel Routers 1288 Using customer-edge (CE) routers for tunnel endpoints allows the EID 1289 space associated with a site to be reachable via a small set of RLOCs 1290 assigned to the CE routers for that site. 1292 This offers the opposite benefit of the first-hop/last-hop tunnel 1293 router scenario: the number of mapping entries and network management 1294 touch points are reduced, allowing better scaling. 1296 One disadvantage is that less of the network's resources are used to 1297 reach host endpoints thereby centralizing the point-of-failure domain 1298 and creating network choke points at the CE router. 1300 Note that more than one CE router at a site can be configured with 1301 the same IP address. In this case an RLOC is an anycast address. 1302 This allows resilience between the CE routers. That is, if a CE 1303 router fails, traffic is automatically routed to the other routers 1304 using the same anycast address. However, this comes with the 1305 disadvantage where the site cannot control the entrance point when 1306 the anycast route is advertised out from all border routers. 1308 8.3. ISP Provider-Edge (PE) Tunnel Routers 1310 Use of ISP PE routers as tunnel endpoint routers gives an ISP control 1311 over the location of the egress tunnel endpoints. That is, the ISP 1312 can decide if the tunnel endpoints are in the destination site (in 1313 either CE routers or last-hop routers within a site) or at other PE 1314 edges. The advantage of this case is that two or more tunnel headers 1315 can be avoided. By having the PE be the first router on the path to 1316 encapsulate, it can choose a TE path first, and the ETR can 1317 decapsulate and re-encapsulate for a tunnel to the destination end 1318 site. 1320 An obvious disadvantage is that the end site has no control over 1321 where its packets flow or the RLOCs used. 1323 As mentioned in earlier sections a combination of these scenarios is 1324 possible at the expense of extra packet header overhead, if both site 1325 and provider want control, then recursive or re-encapsulating tunnels 1326 are used. 1328 9. Mobility Considerations 1330 There are several kinds of mobility of which only some might be of 1331 concern to LISP. Essentially they are as follows. 1333 9.1. Site Mobility 1335 A site wishes to change its attachment points to the Internet, and 1336 its LISP Tunnel Routers will have new RLOCs when it changes upstream 1337 providers. Changes in EID-RLOC mappings for sites are expected to be 1338 handled by configuration, outside of the LISP protocol. 1340 9.2. Slow Endpoint Mobility 1342 An individual endpoint wishes to move, but is not concerned about 1343 maintaining session continuity. Renumbering is involved. LISP can 1344 help with the issues surrounding renumbering [RFC4192] [LISA96] by 1345 decoupling the address space used by a site from the address spaces 1346 used by its ISPs. [RFC4984] 1348 9.3. Fast Endpoint Mobility 1350 Fast endpoint mobility occurs when an endpoint moves relatively 1351 rapidly, changing its IP layer network attachment point. Maintenance 1352 of session continuity is a goal. This is where the Mobile IPv4 1353 [RFC3344bis] and Mobile IPv6 [RFC3775] [RFC4866] mechanisms are used, 1354 and primarily where interactions with LISP need to be explored. 1356 The problem is that as an endpoint moves, it may require changes to 1357 the mapping between its EID and a set of RLOCs for its new network 1358 location. When this is added to the overhead of mobile IP binding 1359 updates, some packets might be delayed or dropped. 1361 In IPv4 mobility, when an endpoint is away from home, packets to it 1362 are encapsulated and forwarded via a home agent which resides in the 1363 home area the endpoint's address belongs to. The home agent will 1364 encapsulate and forward packets either directly to the endpoint or to 1365 a foreign agent which resides where the endpoint has moved to. 1366 Packets from the endpoint may be sent directly to the correspondent 1367 node, may be sent via the foreign agent, or may be reverse-tunneled 1368 back to the home agent for delivery to the mobile node. As the 1369 mobile node's EID or available RLOC changes, LISP EID-to-RLOC 1370 mappings are required for communication between the mobile node and 1371 the home agent, whether via foreign agent or not. As a mobile 1372 endpoint changes networks, up to three LISP mapping changes may be 1373 required: 1375 o The mobile node moves from an old location to a new visited 1376 network location and notifies its home agent that it has done so. 1377 The Mobile IPv4 control packets the mobile node sends pass through 1378 one of the new visited network's ITRs, which needs a EID-RLOC 1379 mapping for the home agent. 1381 o The home agent might not have the EID-RLOC mappings for the mobile 1382 node's "care-of" address or its foreign agent in the new visited 1383 network, in which case it will need to acquire them. 1385 o When packets are sent directly to the correspondent node, it may 1386 be that no traffic has been sent from the new visited network to 1387 the correspondent node's network, and the new visited network's 1388 ITR will need to obtain an EID-RLOC mapping for the correspondent 1389 node's site. 1391 In addition, if the IPv4 endpoint is sending packets from the new 1392 visited network using its original EID, then LISP will need to 1393 perform a route-returnability check on the new EID-RLOC mapping for 1394 that EID. 1396 In IPv6 mobility, packets can flow directly between the mobile node 1397 and the correspondent node in either direction. The mobile node uses 1398 its "care-of" address (EID). In this case, the route-returnability 1399 check would not be needed but one more LISP mapping lookup may be 1400 required instead: 1402 o As above, three mapping changes may be needed for the mobile node 1403 to communicate with its home agent and to send packets to the 1404 correspondent node. 1406 o In addition, another mapping will be needed in the correspondent 1407 node's ITR, in order for the correspondent node to send packets to 1408 the mobile node's "care-of" address (EID) at the new network 1409 location. 1411 When both endpoints are mobile the number of potential mapping 1412 lookups increase accordingly. 1414 As a mobile node moves there are not only mobility state changes in 1415 the mobile node, correspondent node, and home agent, but also state 1416 changes in the ITRs and ETRs for at least some EID-prefixes. 1418 The goal is to support rapid adaptation, with little delay or packet 1419 loss for the entire system. Heuristics can be added to LISP to 1420 reduce the number of mapping changes required and to reduce the delay 1421 per mapping change. Also IP mobility can be modified to require 1422 fewer mapping changes. In order to increase overall system 1423 performance, there may be a need to reduce the optimization of one 1424 area in order to place fewer demands on another. 1426 In LISP, one possibility is to "glean" information. When a packet 1427 arrives, the ETR could examine the EID-RLOC mapping and use that 1428 mapping for all outgoing traffic to that EID. It can do this after 1429 performing a route-returnability check, to ensure that the new 1430 network location does have a internal route to that endpoint. 1431 However, this does not cover the case where an ITR (the node assigned 1432 the RLOC) at the mobile-node location has been compromised. 1434 Mobile IP packet exchange is designed for an environment in which all 1435 routing information is disseminated before packets can be forwarded. 1436 In order to allow the Internet to grow to support expected future 1437 use, we are moving to an environment where some information may have 1438 to be obtained after packets are in flight. Modifications to IP 1439 mobility should be considered in order to optimize the behavior of 1440 the overall system. Anything which decreases the number of new EID- 1441 RLOC mappings needed when a node moves, or maintains the validity of 1442 an EID-RLOC mapping for a longer time, is useful. 1444 9.4. Fast Network Mobility 1446 In addition to endpoints, a network can be mobile, possibly changing 1447 xTRs. A "network" can be as small as a single router and as large as 1448 a whole site. This is different from site mobility in that it is 1449 fast and possibly short-lived, but different from endpoint mobility 1450 in that a whole prefix is changing RLOCs. However, the mechanisms 1451 are the same and there is no new overhead in LISP. A map request for 1452 any endpoint will return a binding for the entire mobile prefix. 1454 If mobile networks become a more common occurrence, it may be useful 1455 to revisit the design of the mapping service and allow for dynamic 1456 updates of the database. 1458 The issue of interactions between mobility and LISP needs to be 1459 explored further. Specific improvements to the entire system will 1460 depend on the details of mapping mechanisms. Mapping mechanisms 1461 should be evaluated on how well they support session continuity for 1462 mobile nodes. 1464 10. Multicast Considerations 1466 A multicast group address, as defined in the original Internet 1467 architecture is an identifier of a grouping of topologically 1468 independent receiver host locations. The address encoding itself 1469 does not determine the location of the receiver(s). The multicast 1470 routing protocol, and the network-based state the protocol creates, 1471 determines where the receivers are located. 1473 In the context of LISP, a multicast group address is both an EID and 1474 a Routing Locator. Therefore, no specific semantic or action needs 1475 to be taken for a destination address, as it would appear in an IP 1476 header. Therefore, a group address that appears in an inner IP 1477 header built by a source host will be used as the destination EID. 1478 And the outer IP header (the destination Routing Locator address), 1479 prepended by a LISP router, will use the same group address as the 1480 destination Routing Locator. 1482 Having said that, only the source EID and source Routing Locator 1483 needs to be dealt with. Therefore, an ITR merely needs to put its 1484 own IP address in the source Routing Locator field when prepending 1485 the outer IP header. This source Routing Locator address, like any 1486 other Routing Locator address MUST be globally routable. 1488 Therefore, an EID-to-RLOC mapping does not need to be performed by an 1489 ITR when a received data packet is a multicast data packet or when 1490 processing a source-specific Join (either by IGMPv3 or PIM). But the 1491 source Routing Locator is decided by the multicast routing protocol 1492 in a receiver site. That is, an EID to Routing Locator translation 1493 is done at control-time. 1495 Another approach is to have the ITR not encapsulate a multicast 1496 packet and allow the the host built packet to flow into the core even 1497 if the source address is allocated out of the EID namespace. If the 1498 RPF-Vector TLV [RPFV] is used by PIM in the core, then core routers 1499 can RPF to the ITR (the Locator address which is injected into core 1500 routing) rather than the host source address (the EID address which 1501 is not injected into core routing). 1503 11. Security Considerations 1505 It is believed that most of the security mechanisms will be part of 1506 the mapping database service when using control-plane procedures for 1507 obtaining EID-to-RLOC mappings. For data-plane triggered mappings, 1508 as described in this specification, protection is provided against 1509 ETR spoofing by using Return- Routability mechanisms evidenced by the 1510 use of a 4-byte Nonce field in the LISP encapsulation header. The 1511 nonce, coupled with the ITR accepting only solicited Map-Replies goes 1512 a long way toward providing decent authentication. 1514 LISP does not rely on a PKI infrastructure or a more heavy weight 1515 authentication system. These systems challenge the scalability of 1516 LISP which was a primary design goal. 1518 DoS attack prevention will depend on implementations rate-limiting of 1519 Map-Requests and Map-Replies to the control-plane as well as rate- 1520 limiting the number of data triggered Map-Replies. 1522 12. Prototype Plans and Status 1524 The operator community has requested that the IETF take a practical 1525 approach to solving the scaling problems associated with global 1526 routing state growth. This document offers a simple solution which 1527 is intended for use in a pilot program to gain experience in working 1528 on this problem. 1530 The authors hope that publishing this specification will allow the 1531 rapid implementation of multiple vendor prototypes and deployment on 1532 a small scale. Doing this will help the community: 1534 o Decide whether a new EID-to-RLOC mapping database infrastructure 1535 is needed or if a simple, UDP-based, data-triggered approach is 1536 flexible and robust enough. 1538 o Experiment with provider-independent assignment of EIDs while at 1539 the same time decreasing the size of DFZ routing tables through 1540 the use of topologically-aligned, provider-based RLOCs. 1542 o Determine whether multiple levels of tunneling can be used by ISPs 1543 to achieve their Traffic Engineering goals while simultaneously 1544 removing the more specific routes currently injected into the 1545 global routing system for this purpose. 1547 o Experiment with mobility to determine if both acceptable 1548 convergence and session survivability properties can be scalably 1549 implemented to support both individual device roaming and site 1550 service provider changes. 1552 Here is a rough set of milestones: 1554 1. This draft will be the draft for interoperable implementations to 1555 code against. Interoperable implementations will be ready summer 1556 of 2008. 1558 2. Start pilot deployment summer of 2008 using LISP-ALT as the 1559 database mapping mechanism. 1561 3. Continue prototyping other database lookup schemes, be it DNS, 1562 DHTs, CONS, ALT, NERD, or other mechanisms. 1564 4. Write up a LISP Multicast Internet Draft which designs how inter- 1565 domain multicast routing works in a Locator/ID split environment. 1567 5. Research more on how policy affects what gets returned in a Map- 1568 Reply from an ETR. 1570 6. Mixed AF locator-set implementation and testing. 1572 7. Interworking draft [INTERWORK] implementation. 1574 As of this writing the following accomplishments have been achieved: 1576 1. A unit tested software switching implementation has been 1577 completed for both IPv4 and IPv6 encapsulations for LISP 1 and 1578 LISP 1.5 [ALT] functionality. The implementation supports 1579 locator reachability and mobility features. 1581 2. Dave Meyer, Vince Fuller, Darrel Lewis, and Greg Shepherd 1582 continue to test the implementation using LISP-ALT as the 1583 database mapping mechanism. 1585 3. A server implementation of NERD has been completed as well as 1586 client NERD verification code by Eliot Lear. 1588 4. An implementation of LISP-CONS is being delayed in lieu of 1589 experience gathered using LISP-ALT. 1591 5. An public domain implementation of LISP is underway. See 1592 [OPENLISP] for details. 1594 Please contact authors if interested in doing an implementation and 1595 want to interoperability test with our implementation. 1597 13. References 1599 13.1. Normative References 1601 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1602 August 1980. 1604 [RFC1498] Saltzer, J., "On the Naming and Binding of Network 1605 Destinations", RFC 1498, August 1993. 1607 [RFC1955] Hinden, R., "New Scheme for Internet Routing and 1608 Addressing (ENCAPS) for IPNG", RFC 1955, June 1996. 1610 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1611 Requirement Levels", BCP 14, RFC 2119, March 1997. 1613 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1614 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1615 October 1998. 1617 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 1618 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 1619 March 2000. 1621 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1622 via IPv4 Clouds", RFC 3056, February 2001. 1624 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1625 in IPv6", RFC 3775, June 2004. 1627 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 1628 (HIP) Architecture", RFC 4423, May 2006. 1630 [RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route 1631 Optimization for Mobile IPv6", RFC 4866, May 2007. 1633 [RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB 1634 Workshop on Routing and Addressing", RFC 4984, 1635 September 2007. 1637 13.2. Informative References 1639 [AFI] IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY 1640 NUMBERS http://www.iana.org/numbers.html, Febuary 2007. 1642 [ALT] Farinacci, D., Fuller, V., and D. Meyer, "LISP Alternative 1643 Topology (LISP-ALT)", draft-fuller-lisp-alt-01.txt (work 1644 in progress), November 2007. 1646 [APT] Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and 1647 L. Zhang, "APT: A Practical Transit Mapping Service", 1648 draft-jen-apt-00.txt (work in progress), July 2007. 1650 [CHIAPPA] Chiappa, J., "Endpoints and Endpoint names: A Proposed 1651 Enhancement to the Internet Architecture", Internet- 1652 Draft http://www.chiappa.net/~jnc/tech/endpoints.txt, 1653 1999. 1655 [CONS] Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A 1656 Content distribution Overlay Network Service for LISP", 1657 draft-meyer-lisp-cons-03.txt (work in progress), 1658 November 2007. 1660 [DHTs] Ratnasamy, S., Shenker, S., and I. Stoica, "Routing 1661 Algorithms for DHTs: Some Open Questions", PDF 1662 file http://www.cs.rice.edu/Conferences/IPTPS02/174.pdf. 1664 [GSE] "GSE - An Alternate Addressing Architecture for IPv6", 1665 draft-ietf-ipngwg-gseaddr-00.txt (work in progress), 1997. 1667 [INTERWORK] 1668 Lewis, D., Meyer, D., and D. Farinacci, "Interworking LISP 1669 with IPv4 and IPv6", draft-lewis-lisp-interworking-00.txt 1670 (work in progress), December 2007. 1672 [LISA96] Lear, E., Katinsky, J., Coffin, J., and D. Tharp, 1673 "Renumbering: Threat or Menace?", Usenix , September 1996. 1675 [LISP1] Farinacci, D., Oran, D., Fuller, V., and J. Schiller, 1676 "Locator/ID Separation Protocol (LISP1) [Routable ID 1677 Version]", 1678 Slide-set http://www.dinof.net/~dino/ietf/lisp1.ppt, 1679 October 2006. 1681 [LISP2] Farinacci, D., Oran, D., Fuller, V., and J. Schiller, 1682 "Locator/ID Separation Protocol (LISP2) [DNS-based 1683 Version]", 1684 Slide-set http://www.dinof.net/~dino/ietf/lisp2.ppt, 1685 November 2006. 1687 [LISPDHT] Mathy, L., Iannone, L., and O. Bonaventure, "LISP-DHT: 1688 Towards a DHT to map identifiers onto locators", 1689 draft-mathy-lisp-dht-00.txt (work in progress), 1690 February 2008. 1692 [NERD] Lear, E., "NERD: A Not-so-novel EID to RLOC Database", 1693 draft-lear-lisp-nerd-02.txt (work in progress), 1694 January 2008. 1696 [OPENLISP] 1697 Iannone, L. and O. Bonaventure, "OpenLISP Implementation 1698 Report", draft-iannone-openlisp-implementation-00.txt 1699 (work in progress), February 2008. 1701 [RADIR] Narten, T., "Routing and Addressing Problem Statement", 1702 draft-narten-radir-problem-statement-00.txt (work in 1703 progress), July 2007. 1705 [RFC3344bis] 1706 Perkins, C., "IP Mobility Support for IPv4, revised", 1707 draft-ietf-mip4-rfc3344bis-05 (work in progress), 1708 July 2007. 1710 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 1711 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 1712 September 2005. 1714 [RPFV] Wijnands, IJ., Boers, A., and E. Rosen, "The RPF Vector 1715 TLV", draft-ietf-pim-rpf-vector-03.txt (work in progress), 1716 October 2006. 1718 [RPMD] Handley, M., Huici, F., and A. Greenhalgh, "RPMD: Protocol 1719 for Routing Protocol Meta-data Dissemination", 1720 draft-handley-p2ppush-unpublished-2007726.txt (work in 1721 progress), July 2007. 1723 [SHIM6] Nordmark, E. and M. Bagnulo, "Level 3 multihoming shim 1724 protocol", draft-ietf-shim6-proto-06.txt (work in 1725 progress), October 2006. 1727 Appendix A. Acknowledgments 1729 The authors would like to gratefully acknowledge many people who have 1730 contributed discussion and ideas to the making of this proposal. 1731 They include Jason Schiller, Lixia Zhang, Dorian Kim, Peter 1732 Schoenmaker, Darrel Lewis, Vijay Gill, Geoff Huston, David Conrad, 1733 Mark Handley, Ron Bonica, Ted Seely, Mark Townsley, Chris Morrow, 1734 Brian Weis, Dave McGrew, Peter Lothberg, Dave Thaler, Eliot Lear, 1735 Shane Amante, Ved Kafle, Olivier Bonaventure, Luigi Iannone, Robin 1736 Whittle, Brian Carpenter, Joel Halpern, Roger Jorgensen, John 1737 Zwiebel, Ran Atkinson, Stig Venaas, Iljitsch van Beijnum, and Scott 1738 Brim. 1740 In particular, we would like to thank Dave Meyer for his clever 1741 suggestion for the name "LISP". ;-) 1743 Authors' Addresses 1745 Dino Farinacci 1746 cisco Systems 1747 Tasman Drive 1748 San Jose, CA 95134 1749 USA 1751 Email: dino@cisco.com 1753 Vince Fuller 1754 cisco Systems 1755 Tasman Drive 1756 San Jose, CA 95134 1757 USA 1759 Email: vaf@cisco.com 1761 Dave Oran 1762 cisco Systems 1763 7 Ladyslipper Lane 1764 Acton, MA 1765 USA 1767 Email: oran@cisco.com 1769 Dave Meyer 1770 cisco Systems 1771 170 Tasman Drive 1772 San Jose, CA 1773 USA 1775 Email: dmm@cisco.com 1777 Full Copyright Statement 1779 Copyright (C) The IETF Trust (2008). 1781 This document is subject to the rights, licenses and restrictions 1782 contained in BCP 78, and except as set forth therein, the authors 1783 retain all their rights. 1785 This document and the information contained herein are provided on an 1786 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1787 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1788 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1789 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1790 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1791 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1793 Intellectual Property 1795 The IETF takes no position regarding the validity or scope of any 1796 Intellectual Property Rights or other rights that might be claimed to 1797 pertain to the implementation or use of the technology described in 1798 this document or the extent to which any license under such rights 1799 might or might not be available; nor does it represent that it has 1800 made any independent effort to identify any such rights. Information 1801 on the procedures with respect to rights in RFC documents can be 1802 found in BCP 78 and BCP 79. 1804 Copies of IPR disclosures made to the IETF Secretariat and any 1805 assurances of licenses to be made available, or the result of an 1806 attempt made to obtain a general license or permission for the use of 1807 such proprietary rights by implementers or users of this 1808 specification can be obtained from the IETF on-line IPR repository at 1809 http://www.ietf.org/ipr. 1811 The IETF invites any interested party to bring to its attention any 1812 copyrights, patents or patent applications, or other proprietary 1813 rights that may cover technology that may be required to implement 1814 this standard. Please address the information to the IETF at 1815 ietf-ipr@ietf.org. 1817 Acknowledgment 1819 Funding for the RFC Editor function is provided by the IETF 1820 Administrative Support Activity (IASA).