idnits 2.17.1 draft-ietf-lisp-rfc6830bis-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 27, 2018) is 2068 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-14) exists of draft-ietf-lisp-6834bis-00 == Outdated reference: A later version (-31) exists of draft-ietf-lisp-rfc6833bis-13 == Outdated reference: A later version (-15) exists of draft-ietf-lisp-introduction-13 == Outdated reference: A later version (-12) exists of draft-ietf-lisp-vpn-02 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). 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 Obsoletes: 6830 (if approved) D. Meyer 5 Intended status: Standards Track D. Lewis 6 Expires: February 28, 2019 Cisco Systems 7 A. Cabellos (Ed.) 8 UPC/BarcelonaTech 9 August 27, 2018 11 The Locator/ID Separation Protocol (LISP) 12 draft-ietf-lisp-rfc6830bis-16 14 Abstract 16 This document describes the Data-Plane protocol for the Locator/ID 17 Separation Protocol (LISP). LISP defines two namespaces, End-point 18 Identifiers (EIDs) that identify end-hosts and Routing Locators 19 (RLOCs) that identify network attachment points. With this, LISP 20 effectively separates control from data, and allows routers to create 21 overlay networks. LISP-capable routers exchange encapsulated packets 22 according to EID-to-RLOC mappings stored in a local Map-Cache. 24 LISP requires no change to either host protocol stacks or to underlay 25 routers and offers Traffic Engineering, multihoming and mobility, 26 among other features. 28 This document obsoletes RFC 6830. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on February 28, 2019. 47 Copyright Notice 49 Copyright (c) 2018 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 66 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 67 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . 8 68 4.1. Packet Flow Sequence . . . . . . . . . . . . . . . . . . 10 69 5. LISP Encapsulation Details . . . . . . . . . . . . . . . . . 12 70 5.1. LISP IPv4-in-IPv4 Header Format . . . . . . . . . . . . . 13 71 5.2. LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 13 72 5.3. Tunnel Header Field Descriptions . . . . . . . . . . . . 15 73 6. LISP EID-to-RLOC Map-Cache . . . . . . . . . . . . . . . . . 19 74 7. Dealing with Large Encapsulated Packets . . . . . . . . . . . 19 75 7.1. A Stateless Solution to MTU Handling . . . . . . . . . . 20 76 7.2. A Stateful Solution to MTU Handling . . . . . . . . . . . 21 77 8. Using Virtualization and Segmentation with LISP . . . . . . . 21 78 9. Routing Locator Selection . . . . . . . . . . . . . . . . . . 22 79 10. Routing Locator Reachability . . . . . . . . . . . . . . . . 24 80 10.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . . 25 81 11. EID Reachability within a LISP Site . . . . . . . . . . . . . 26 82 12. Routing Locator Hashing . . . . . . . . . . . . . . . . . . . 27 83 13. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 28 84 13.1. Database Map-Versioning . . . . . . . . . . . . . . . . 29 85 14. Multicast Considerations . . . . . . . . . . . . . . . . . . 29 86 15. Router Performance Considerations . . . . . . . . . . . . . . 30 87 16. Security Considerations . . . . . . . . . . . . . . . . . . . 31 88 17. Network Management Considerations . . . . . . . . . . . . . . 32 89 18. Changes since RFC 6830 . . . . . . . . . . . . . . . . . . . 32 90 19. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 91 19.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 32 92 20. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 93 20.1. Normative References . . . . . . . . . . . . . . . . . . 33 94 20.2. Informative References . . . . . . . . . . . . . . . . . 33 96 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 37 97 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 37 98 B.1. Changes to draft-ietf-lisp-rfc6830bis-16 . . . . . . . . 38 99 B.2. Changes to draft-ietf-lisp-rfc6830bis-15 . . . . . . . . 38 100 B.3. Changes to draft-ietf-lisp-rfc6830bis-14 . . . . . . . . 38 101 B.4. Changes to draft-ietf-lisp-rfc6830bis-13 . . . . . . . . 38 102 B.5. Changes to draft-ietf-lisp-rfc6830bis-12 . . . . . . . . 38 103 B.6. Changes to draft-ietf-lisp-rfc6830bis-11 . . . . . . . . 38 104 B.7. Changes to draft-ietf-lisp-rfc6830bis-10 . . . . . . . . 39 105 B.8. Changes to draft-ietf-lisp-rfc6830bis-09 . . . . . . . . 39 106 B.9. Changes to draft-ietf-lisp-rfc6830bis-08 . . . . . . . . 39 107 B.10. Changes to draft-ietf-lisp-rfc6830bis-07 . . . . . . . . 40 108 B.11. Changes to draft-ietf-lisp-rfc6830bis-06 . . . . . . . . 40 109 B.12. Changes to draft-ietf-lisp-rfc6830bis-05 . . . . . . . . 40 110 B.13. Changes to draft-ietf-lisp-rfc6830bis-04 . . . . . . . . 40 111 B.14. Changes to draft-ietf-lisp-rfc6830bis-03 . . . . . . . . 41 112 B.15. Changes to draft-ietf-lisp-rfc6830bis-02 . . . . . . . . 41 113 B.16. Changes to draft-ietf-lisp-rfc6830bis-01 . . . . . . . . 41 114 B.17. Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 41 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 117 1. Introduction 119 This document describes the Locator/Identifier Separation Protocol 120 (LISP). LISP is an encapsulation protocol built around the 121 fundamental idea of separating the topological location of a network 122 attachment point from the node's identity [CHIAPPA]. As a result 123 LISP creates two namespaces: Endpoint Identifiers (EIDs), that are 124 used to identify end-hosts (e.g., nodes or Virtual Machines) and 125 routable Routing Locators (RLOCs), used to identify network 126 attachment points. LISP then defines functions for mapping between 127 the two namespaces and for encapsulating traffic originated by 128 devices using non-routable EIDs for transport across a network 129 infrastructure that routes and forwards using RLOCs. LISP 130 encapsulation uses a dynamic form of tunneling where no static 131 provisioning is required or necessary. 133 LISP is an overlay protocol that separates control from Data-Plane, 134 this document specifies the Data-Plane, how LISP-capable routers 135 (Tunnel Routers) exchange packets by encapsulating them to the 136 appropriate location. Tunnel routers are equipped with a cache, 137 called Map-Cache, that contains EID-to-RLOC mappings. The Map-Cache 138 is populated using the LISP Control-Plane protocol 139 [I-D.ietf-lisp-rfc6833bis]. 141 LISP does not require changes to either host protocol stack or to 142 underlay routers. By separating the EID from the RLOC space, LISP 143 offers native Traffic Engineering, multihoming and mobility, among 144 other features. 146 Creation of LISP was initially motivated by discussions during the 147 IAB-sponsored Routing and Addressing Workshop held in Amsterdam in 148 October 2006 (see [RFC4984]). 150 This document specifies the LISP Data-Plane encapsulation and other 151 LISP forwarding node functionality while [I-D.ietf-lisp-rfc6833bis] 152 specifies the LISP control plane. LISP deployment guidelines can be 153 found in [RFC7215] and [RFC6835] describes considerations for network 154 operational management. Finally, [I-D.ietf-lisp-introduction] 155 describes the LISP architecture. 157 This document obsoletes RFC 6830. 159 2. Requirements Notation 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 163 document are to be interpreted as described in [RFC2119] and 164 [RFC8174]. 166 3. Definition of Terms 168 Address Family Identifier (AFI): AFI is a term used to describe an 169 address encoding in a packet. An address family that pertains to 170 the Data-Plane. See [AFN] and [RFC3232] for details. An AFI 171 value of 0 used in this specification indicates an unspecified 172 encoded address where the length of the address is 0 octets 173 following the 16-bit AFI value of 0. 175 Anycast Address: Anycast Address is a term used in this document to 176 refer to the same IPv4 or IPv6 address configured and used on 177 multiple systems at the same time. An EID or RLOC can be an 178 anycast address in each of their own address spaces. 180 Client-side: Client-side is a term used in this document to indicate 181 a connection initiation attempt by an end-system represented by an 182 EID. 184 Data-Probe: A Data-Probe is a LISP-encapsulated data packet where 185 the inner-header destination address equals the outer-header 186 destination address used to trigger a Map-Reply by a decapsulating 187 ETR. In addition, the original packet is decapsulated and 188 delivered to the destination host if the destination EID is in the 189 EID-Prefix range configured on the ETR. Otherwise, the packet is 190 discarded. A Data-Probe is used in some of the mapping database 191 designs to "probe" or request a Map-Reply from an ETR; in other 192 cases, Map-Requests are used. See each mapping database design 193 for details. When using Data-Probes, by sending Map-Requests on 194 the underlying routing system, EID-Prefixes must be advertised. 196 Egress Tunnel Router (ETR): An ETR is a router that accepts an IP 197 packet where the destination address in the "outer" IP header is 198 one of its own RLOCs. The router strips the "outer" header and 199 forwards the packet based on the next IP header found. In 200 general, an ETR receives LISP-encapsulated IP packets from the 201 Internet on one side and sends decapsulated IP packets to site 202 end-systems on the other side. ETR functionality does not have to 203 be limited to a router device. A server host can be the endpoint 204 of a LISP tunnel as well. 206 EID-to-RLOC Database: The EID-to-RLOC Database is a global 207 distributed database that contains all known EID-Prefix-to-RLOC 208 mappings. Each potential ETR typically contains a small piece of 209 the database: the EID-to-RLOC mappings for the EID-Prefixes 210 "behind" the router. These map to one of the router's own 211 globally visible IP addresses. Note that there MAY be transient 212 conditions when the EID-Prefix for the site and Locator-Set for 213 each EID-Prefix may not be the same on all ETRs. This has no 214 negative implications, since a partial set of Locators can be 215 used. 217 EID-to-RLOC Map-Cache: The EID-to-RLOC Map-Cache is generally 218 short-lived, on-demand table in an ITR that stores, tracks, and is 219 responsible for timing out and otherwise validating EID-to-RLOC 220 mappings. This cache is distinct from the full "database" of EID- 221 to-RLOC mappings; it is dynamic, local to the ITR(s), and 222 relatively small, while the database is distributed, relatively 223 static, and much more global in scope. 225 EID-Prefix: An EID-Prefix is a power-of-two block of EIDs that are 226 allocated to a site by an address allocation authority. EID- 227 Prefixes are associated with a set of RLOC addresses. EID-Prefix 228 allocations can be broken up into smaller blocks when an RLOC set 229 is to be associated with the larger EID-Prefix block. 231 End-System: An end-system is an IPv4 or IPv6 device that originates 232 packets with a single IPv4 or IPv6 header. The end-system 233 supplies an EID value for the destination address field of the IP 234 header when communicating globally (i.e., outside of its routing 235 domain). An end-system can be a host computer, a switch or router 236 device, or any network appliance. 238 Endpoint ID (EID): An EID is a 32-bit (for IPv4) or 128-bit (for 239 IPv6) value used in the source and destination address fields of 240 the first (most inner) LISP header of a packet. The host obtains 241 a destination EID the same way it obtains a destination address 242 today, for example, through a Domain Name System (DNS) [RFC1034] 243 lookup or Session Initiation Protocol (SIP) [RFC3261] exchange. 244 The source EID is obtained via existing mechanisms used to set a 245 host's "local" IP address. An EID used on the public Internet 246 MUST have the same properties as any other IP address used in that 247 manner; this means, among other things, that it MUST be globally 248 unique. An EID is allocated to a host from an EID-Prefix block 249 associated with the site where the host is located. An EID can be 250 used by a host to refer to other hosts. Note that EID blocks MAY 251 be assigned in a hierarchical manner, independent of the network 252 topology, to facilitate scaling of the mapping database. In 253 addition, an EID block assigned to a site MAY have site-local 254 structure (subnetting) for routing within the site; this structure 255 is not visible to the global routing system. In theory, the bit 256 string that represents an EID for one device can represent an RLOC 257 for a different device. When used in discussions with other 258 Locator/ID separation proposals, a LISP EID will be called an 259 "LEID". Throughout this document, any references to "EID" refer 260 to an LEID. 262 Ingress Tunnel Router (ITR): An ITR is a router that resides in a 263 LISP site. Packets sent by sources inside of the LISP site to 264 destinations outside of the site are candidates for encapsulation 265 by the ITR. The ITR treats the IP destination address as an EID 266 and performs an EID-to-RLOC mapping lookup. The router then 267 prepends an "outer" IP header with one of its routable RLOCs (in 268 the RLOC space) in the source address field and the result of the 269 mapping lookup in the destination address field. Note that this 270 destination RLOC MAY be an intermediate, proxy device that has 271 better knowledge of the EID-to-RLOC mapping closer to the 272 destination EID. In general, an ITR receives IP packets from site 273 end-systems on one side and sends LISP-encapsulated IP packets 274 toward the Internet on the other side. 276 Specifically, when a service provider prepends a LISP header for 277 Traffic Engineering purposes, the router that does this is also 278 regarded as an ITR. The outer RLOC the ISP ITR uses can be based 279 on the outer destination address (the originating ITR's supplied 280 RLOC) or the inner destination address (the originating host's 281 supplied EID). 283 LISP Header: LISP header is a term used in this document to refer 284 to the outer IPv4 or IPv6 header, a UDP header, and a LISP- 285 specific 8-octet header that follow the UDP header and that an ITR 286 prepends or an ETR strips. 288 LISP Router: A LISP router is a router that performs the functions 289 of any or all of the following: ITR, ETR, RTR, Proxy-ITR (PITR), 290 or Proxy-ETR (PETR). 292 LISP Site: LISP site is a set of routers in an edge network that are 293 under a single technical administration. LISP routers that reside 294 in the edge network are the demarcation points to separate the 295 edge network from the core network. 297 Locator-Status-Bits (LSBs): Locator-Status-Bits are present in the 298 LISP header. They are used by ITRs to inform ETRs about the up/ 299 down status of all ETRs at the local site. These bits are used as 300 a hint to convey up/down router status and not path reachability 301 status. The LSBs can be verified by use of one of the Locator 302 reachability algorithms described in Section 10. 304 Negative Mapping Entry: A negative mapping entry, also known as a 305 negative cache entry, is an EID-to-RLOC entry where an EID-Prefix 306 is advertised or stored with no RLOCs. That is, the Locator-Set 307 for the EID-to-RLOC entry is empty or has an encoded Locator count 308 of 0. This type of entry could be used to describe a prefix from 309 a non-LISP site, which is explicitly not in the mapping database. 310 There are a set of well-defined actions that are encoded in a 311 Negative Map-Reply. 313 Proxy-ETR (PETR): A PETR is defined and described in [RFC6832]. A 314 PETR acts like an ETR but does so on behalf of LISP sites that 315 send packets to destinations at non-LISP sites. 317 Proxy-ITR (PITR): A PITR is defined and described in [RFC6832]. A 318 PITR acts like an ITR but does so on behalf of non-LISP sites that 319 send packets to destinations at LISP sites. 321 Recursive Tunneling: Recursive Tunneling occurs when a packet has 322 more than one LISP IP header. Additional layers of tunneling MAY 323 be employed to implement Traffic Engineering or other re-routing 324 as needed. When this is done, an additional "outer" LISP header 325 is added, and the original RLOCs are preserved in the "inner" 326 header. 328 Re-Encapsulating Tunneling Router (RTR): An RTR acts like an ETR to 329 remove a LISP header, then acts as an ITR to prepend a new LISP 330 header. This is known as Re-encapsulating Tunneling. Doing this 331 allows a packet to be re-routed by the RTR without adding the 332 overhead of additional tunnel headers. When using multiple 333 mapping database systems, care must be taken to not create re- 334 encapsulation loops through misconfiguration. 336 Route-Returnability: Route-returnability is an assumption that the 337 underlying routing system will deliver packets to the destination. 338 When combined with a nonce that is provided by a sender and 339 returned by a receiver, this limits off-path data insertion. A 340 route-returnability check is verified when a message is sent with 341 a nonce, another message is returned with the same nonce, and the 342 destination of the original message appears as the source of the 343 returned message. 345 Routing Locator (RLOC): An RLOC is an IPv4 [RFC0791] or IPv6 346 [RFC8200] address of an Egress Tunnel Router (ETR). An RLOC is 347 the output of an EID-to-RLOC mapping lookup. An EID maps to zero 348 or more RLOCs. Typically, RLOCs are numbered from blocks that are 349 assigned to a site at each point to which it attaches to the 350 underlay network; where the topology is defined by the 351 connectivity of provider networks. Multiple RLOCs can be assigned 352 to the same ETR device or to multiple ETR devices at a site. 354 Server-side: Server-side is a term used in this document to indicate 355 that a connection initiation attempt is being accepted for a 356 destination EID. 358 TE-ETR: A TE-ETR is an ETR that is deployed in a service provider 359 network that strips an outer LISP header for Traffic Engineering 360 purposes. 362 TE-ITR: A TE-ITR is an ITR that is deployed in a service provider 363 network that prepends an additional LISP header for Traffic 364 Engineering purposes. 366 xTR: An xTR is a reference to an ITR or ETR when direction of data 367 flow is not part of the context description. "xTR" refers to the 368 router that is the tunnel endpoint and is used synonymously with 369 the term "Tunnel Router". For example, "An xTR can be located at 370 the Customer Edge (CE) router" indicates both ITR and ETR 371 functionality at the CE router. 373 4. Basic Overview 375 One key concept of LISP is that end-systems operate the same way they 376 do today. The IP addresses that hosts use for tracking sockets and 377 connections, and for sending and receiving packets, do not change. 378 In LISP terminology, these IP addresses are called Endpoint 379 Identifiers (EIDs). 381 Routers continue to forward packets based on IP destination 382 addresses. When a packet is LISP encapsulated, these addresses are 383 referred to as Routing Locators (RLOCs). Most routers along a path 384 between two hosts will not change; they continue to perform routing/ 385 forwarding lookups on the destination addresses. For routers between 386 the source host and the ITR as well as routers from the ETR to the 387 destination host, the destination address is an EID. For the routers 388 between the ITR and the ETR, the destination address is an RLOC. 390 Another key LISP concept is the "Tunnel Router". A Tunnel Router 391 prepends LISP headers on host-originated packets and strips them 392 prior to final delivery to their destination. The IP addresses in 393 this "outer header" are RLOCs. During end-to-end packet exchange 394 between two Internet hosts, an ITR prepends a new LISP header to each 395 packet, and an ETR strips the new header. The ITR performs EID-to- 396 RLOC lookups to determine the routing path to the ETR, which has the 397 RLOC as one of its IP addresses. 399 Some basic rules governing LISP are: 401 o End-systems only send to addresses that are EIDs. EIDs are 402 typically IP addresses assigned to hosts (other types of EID are 403 supported by LISP, see [RFC8060] for further information). End- 404 systems don't know that addresses are EIDs versus RLOCs but assume 405 that packets get to their intended destinations. In a system 406 where LISP is deployed, LISP routers intercept EID-addressed 407 packets and assist in delivering them across the network core 408 where EIDs cannot be routed. The procedure a host uses to send IP 409 packets does not change. 411 o LISP routers mostly deal with Routing Locator addresses. See 412 details in Section 4.1 to clarify what is meant by "mostly". 414 o RLOCs are always IP addresses assigned to routers, preferably 415 topologically oriented addresses from provider CIDR (Classless 416 Inter-Domain Routing) blocks. 418 o When a router originates packets, it MAY use as a source address 419 either an EID or RLOC. When acting as a host (e.g., when 420 terminating a transport session such as Secure SHell (SSH), 421 TELNET, or the Simple Network Management Protocol (SNMP)), it MAY 422 use an EID that is explicitly assigned for that purpose. An EID 423 that identifies the router as a host MUST NOT be used as an RLOC; 424 an EID is only routable within the scope of a site. A typical BGP 425 configuration might demonstrate this "hybrid" EID/RLOC usage where 426 a router could use its "host-like" EID to terminate iBGP sessions 427 to other routers in a site while at the same time using RLOCs to 428 terminate eBGP sessions to routers outside the site. 430 o Packets with EIDs in them are not expected to be delivered end-to- 431 end in the absence of an EID-to-RLOC mapping operation. They are 432 expected to be used locally for intra-site communication or to be 433 encapsulated for inter-site communication. 435 o EIDs MAY also be structured (subnetted) in a manner suitable for 436 local routing within an Autonomous System (AS). 438 An additional LISP header MAY be prepended to packets by a TE-ITR 439 when re-routing of the path for a packet is desired. A potential 440 use-case for this would be an ISP router that needs to perform 441 Traffic Engineering for packets flowing through its network. In such 442 a situation, termed "Recursive Tunneling", an ISP transit acts as an 443 additional ITR, and the RLOC it uses for the new prepended header 444 would be either a TE-ETR within the ISP (along an intra-ISP traffic 445 engineered path) or a TE-ETR within another ISP (an inter-ISP traffic 446 engineered path, where an agreement to build such a path exists). 448 In order to avoid excessive packet overhead as well as possible 449 encapsulation loops, this document recommends that a maximum of two 450 LISP headers can be prepended to a packet. For initial LISP 451 deployments, it is assumed that two headers is sufficient, where the 452 first prepended header is used at a site for Location/Identity 453 separation and the second prepended header is used inside a service 454 provider for Traffic Engineering purposes. 456 Tunnel Routers can be placed fairly flexibly in a multi-AS topology. 457 For example, the ITR for a particular end-to-end packet exchange 458 might be the first-hop or default router within a site for the source 459 host. Similarly, the ETR might be the last-hop router directly 460 connected to the destination host. Another example, perhaps for a 461 VPN service outsourced to an ISP by a site, the ITR could be the 462 site's border router at the service provider attachment point. 463 Mixing and matching of site-operated, ISP-operated, and other Tunnel 464 Routers is allowed for maximum flexibility. 466 4.1. Packet Flow Sequence 468 This section provides an example of the unicast packet flow, 469 including also Control-Plane information as specified in 470 [I-D.ietf-lisp-rfc6833bis]. The example also assumes the following 471 conditions: 473 o Source host "host1.abc.example.com" is sending a packet to 474 "host2.xyz.example.com", exactly what host1 would do if the site 475 was not using LISP. 477 o Each site is multihomed, so each Tunnel Router has an address 478 (RLOC) assigned from the service provider address block for each 479 provider to which that particular Tunnel Router is attached. 481 o The ITR(s) and ETR(s) are directly connected to the source and 482 destination, respectively, but the source and destination can be 483 located anywhere in the LISP site. 485 o A Map-Request is sent for an external destination when the 486 destination is not found in the forwarding table or matches a 487 default route. Map-Requests are sent to the mapping database 488 system by using the LISP Control-Plane protocol documented in 489 [I-D.ietf-lisp-rfc6833bis]. 491 o Map-Replies are sent on the underlying routing system topology 492 using the [I-D.ietf-lisp-rfc6833bis] Control-Plane protocol. 494 Client host1.abc.example.com wants to communicate with server 495 host2.xyz.example.com: 497 1. host1.abc.example.com wants to open a TCP connection to 498 host2.xyz.example.com. It does a DNS lookup on 499 host2.xyz.example.com. An A/AAAA record is returned. This 500 address is the destination EID. The locally assigned address of 501 host1.abc.example.com is used as the source EID. An IPv4 or IPv6 502 packet is built and forwarded through the LISP site as a normal 503 IP packet until it reaches a LISP ITR. 505 2. The LISP ITR must be able to map the destination EID to an RLOC 506 of one of the ETRs at the destination site. The specific method 507 used to do this is not described in this example. See 508 [I-D.ietf-lisp-rfc6833bis] for further information. 510 3. The ITR sends a LISP Map-Request as specified in 511 [I-D.ietf-lisp-rfc6833bis]. Map-Requests SHOULD be rate-limited. 513 4. The mapping system helps forwarding the Map-Request to the 514 corresponding ETR. When the Map-Request arrives at one of the 515 ETRs at the destination site, it will process the packet as a 516 control message. 518 5. The ETR looks at the destination EID of the Map-Request and 519 matches it against the prefixes in the ETR's configured EID-to- 520 RLOC mapping database. This is the list of EID-Prefixes the ETR 521 is supporting for the site it resides in. If there is no match, 522 the Map-Request is dropped. Otherwise, a LISP Map-Reply is 523 returned to the ITR. 525 6. The ITR receives the Map-Reply message, parses the message (to 526 check for format validity), and stores the mapping information 527 from the packet. This information is stored in the ITR's EID-to- 528 RLOC Map-Cache. Note that the Map-Cache is an on-demand cache. 529 An ITR will manage its Map-Cache in such a way that optimizes for 530 its resource constraints. 532 7. Subsequent packets from host1.abc.example.com to 533 host2.xyz.example.com will have a LISP header prepended by the 534 ITR using the appropriate RLOC as the LISP header destination 535 address learned from the ETR. Note that the packet MAY be sent 536 to a different ETR than the one that returned the Map-Reply due 537 to the source site's hashing policy or the destination site's 538 Locator-Set policy. 540 8. The ETR receives these packets directly (since the destination 541 address is one of its assigned IP addresses), checks the validity 542 of the addresses, strips the LISP header, and forwards packets to 543 the attached destination host. 545 9. In order to defer the need for a mapping lookup in the reverse 546 direction, an ETR can OPTIONALLY create a cache entry that maps 547 the source EID (inner-header source IP address) to the source 548 RLOC (outer-header source IP address) in a received LISP packet. 549 Such a cache entry is termed a "glean mapping" and only contains 550 a single RLOC for the EID in question. More complete information 551 about additional RLOCs SHOULD be verified by sending a LISP Map- 552 Request for that EID. Both the ITR and the ETR MAY also 553 influence the decision the other makes in selecting an RLOC. 555 5. LISP Encapsulation Details 557 Since additional tunnel headers are prepended, the packet becomes 558 larger and can exceed the MTU of any link traversed from the ITR to 559 the ETR. It is RECOMMENDED in IPv4 that packets do not get 560 fragmented as they are encapsulated by the ITR. Instead, the packet 561 is dropped and an ICMP Unreachable/Fragmentation-Needed message is 562 returned to the source. 564 In the case when fragmentation is needed, this specification 565 RECOMMENDS that implementations provide support for one of the 566 proposed fragmentation and reassembly schemes. Two existing schemes 567 are detailed in Section 7. 569 Since IPv4 or IPv6 addresses can be either EIDs or RLOCs, the LISP 570 architecture supports IPv4 EIDs with IPv6 RLOCs (where the inner 571 header is in IPv4 packet format and the outer header is in IPv6 572 packet format) or IPv6 EIDs with IPv4 RLOCs (where the inner header 573 is in IPv6 packet format and the outer header is in IPv4 packet 574 format). The next sub-sections illustrate packet formats for the 575 homogeneous case (IPv4-in-IPv4 and IPv6-in-IPv6), but all 4 576 combinations MUST be supported. Additional types of EIDs are defined 577 in [RFC8060]. 579 5.1. LISP IPv4-in-IPv4 Header Format 581 0 1 2 3 582 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 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 / |Version| IHL | DSCP |ECN| Total Length | 585 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | | Identification |Flags| Fragment Offset | 587 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 OH | Time to Live | Protocol = 17 | Header Checksum | 589 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | | Source Routing Locator | 591 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 \ | Destination Routing Locator | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 / | Source Port = xxxx | Dest Port = 4341 | 595 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 \ | UDP Length | UDP Checksum | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 L |N|L|E|V|I|R|K|K| Nonce/Map-Version | 599 I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 S / | Instance ID/Locator-Status-Bits | 601 P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 / |Version| IHL | DSCP |ECN| Total Length | 603 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | | Identification |Flags| Fragment Offset | 605 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 IH | Time to Live | Protocol | Header Checksum | 607 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | | Source EID | 609 \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 \ | Destination EID | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 IHL = IP-Header-Length 615 5.2. LISP IPv6-in-IPv6 Header Format 617 0 1 2 3 618 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 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 / |Version| DSCP |ECN| Flow Label | 622 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | | Payload Length | Next Header=17| Hop Limit | 624 v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | | 626 O + + 627 u | | 628 t + Source Routing Locator + 629 e | | 630 r + + 631 | | 632 H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 d | | 634 r + + 635 | | 636 ^ + Destination Routing Locator + 637 | | | 638 \ + + 639 \ | | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 / | Source Port = xxxx | Dest Port = 4341 | 642 UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 \ | UDP Length | UDP Checksum | 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 L |N|L|E|V|I|R|K|K| Nonce/Map-Version | 646 I \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 S / | Instance ID/Locator-Status-Bits | 648 P +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 / |Version| DSCP |ECN| Flow Label | 650 / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 / | Payload Length | Next Header | Hop Limit | 652 v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | | 654 I + + 655 n | | 656 n + Source EID + 657 e | | 658 r + + 659 | | 660 H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 d | | 662 r + + 663 | | 664 ^ + Destination EID + 665 \ | | 666 \ + + 667 \ | | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 670 5.3. Tunnel Header Field Descriptions 672 Inner Header (IH): The inner header is the header on the 673 datagram received from the originating host [RFC0791] [RFC8200] 674 [RFC2474]. The source and destination IP addresses are EIDs. 676 Outer Header: (OH) The outer header is a new header prepended by an 677 ITR. The address fields contain RLOCs obtained from the ingress 678 router's EID-to-RLOC Cache. The IP protocol number is "UDP (17)" 679 from [RFC0768]. The setting of the Don't Fragment (DF) bit 680 'Flags' field is according to rules listed in Sections 7.1 and 681 7.2. 683 UDP Header: The UDP header contains an ITR selected source port when 684 encapsulating a packet. See Section 12 for details on the hash 685 algorithm used to select a source port based on the 5-tuple of the 686 inner header. The destination port MUST be set to the well-known 687 IANA-assigned port value 4341. 689 UDP Checksum: The 'UDP Checksum' field SHOULD be transmitted as zero 690 by an ITR for either IPv4 [RFC0768] and IPv6 encapsulation 691 [RFC6935] [RFC6936]. When a packet with a zero UDP checksum is 692 received by an ETR, the ETR MUST accept the packet for 693 decapsulation. When an ITR transmits a non-zero value for the UDP 694 checksum, it MUST send a correctly computed value in this field. 695 When an ETR receives a packet with a non-zero UDP checksum, it MAY 696 choose to verify the checksum value. If it chooses to perform 697 such verification, and the verification fails, the packet MUST be 698 silently dropped. If the ETR chooses not to perform the 699 verification, or performs the verification successfully, the 700 packet MUST be accepted for decapsulation. The handling of UDP 701 zero checksums over IPv6 for all tunneling protocols, including 702 LISP, is subject to the applicability statement in [RFC6936]. 704 UDP Length: The 'UDP Length' field is set for an IPv4-encapsulated 705 packet to be the sum of the inner-header IPv4 Total Length plus 706 the UDP and LISP header lengths. For an IPv6-encapsulated packet, 707 the 'UDP Length' field is the sum of the inner-header IPv6 Payload 708 Length, the size of the IPv6 header (40 octets), and the size of 709 the UDP and LISP headers. 711 N: The N-bit is the nonce-present bit. When this bit is set to 1, 712 the low-order 24 bits of the first 32 bits of the LISP header 713 contain a Nonce. See Section 10.1 for details. Both N- and 714 V-bits MUST NOT be set in the same packet. If they are, a 715 decapsulating ETR MUST treat the 'Nonce/Map-Version' field as 716 having a Nonce value present. 718 L: The L-bit is the 'Locator-Status-Bits' field enabled bit. When 719 this bit is set to 1, the Locator-Status-Bits in the second 720 32 bits of the LISP header are in use. 722 x 1 x x 0 x x x 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 |N|L|E|V|I|R|K|K| Nonce/Map-Version | 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 | Locator-Status-Bits | 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 E: The E-bit is the echo-nonce-request bit. This bit MUST be ignored 730 and has no meaning when the N-bit is set to 0. When the N-bit is 731 set to 1 and this bit is set to 1, an ITR is requesting that the 732 nonce value in the 'Nonce' field be echoed back in LISP- 733 encapsulated packets when the ITR is also an ETR. See 734 Section 10.1 for details. 736 V: The V-bit is the Map-Version present bit. When this bit is set to 737 1, the N-bit MUST be 0. Refer to Section 13.1 for more details. 738 This bit indicates that the LISP header is encoded in this 739 case as: 741 0 x 0 1 x x x x 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 |N|L|E|V|I|R|K|K| Source Map-Version | Dest Map-Version | 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 | Instance ID/Locator-Status-Bits | 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 I: The I-bit is the Instance ID bit. See Section 8 for more details. 749 When this bit is set to 1, the 'Locator-Status-Bits' field is 750 reduced to 8 bits and the high-order 24 bits are used as an 751 Instance ID. If the L-bit is set to 0, then the low-order 8 bits 752 are transmitted as zero and ignored on receipt. The format of the 753 LISP header would look like this: 755 x x x x 1 x x x 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 |N|L|E|V|I|R|K|K| Nonce/Map-Version | 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 | Instance ID | LSBs | 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 R: The R-bit is a Reserved bit for future use. It MUST be set to 0 763 on transmit and MUST be ignored on receipt. 765 KK: The KK-bits are a 2-bit field used when encapsulated packets are 766 encrypted. The field is set to 00 when the packet is not 767 encrypted. See [RFC8061] for further information. 769 LISP Nonce: The LISP 'Nonce' field is a 24-bit value that is 770 randomly generated by an ITR when the N-bit is set to 1. Nonce 771 generation algorithms are an implementation matter but are 772 required to generate different nonces when sending to different 773 RLOCs. However, the same nonce can be used for a period of time 774 when encapsulating to the same ETR. The nonce is also used when 775 the E-bit is set to request the nonce value to be echoed by the 776 other side when packets are returned. When the E-bit is clear but 777 the N-bit is set, a remote ITR is either echoing a previously 778 requested echo-nonce or providing a random nonce. See 779 Section 10.1 for more details. 781 LISP Locator-Status-Bits (LSBs): When the L-bit is also set, the 782 'Locator-Status-Bits' field in the LISP header is set by an ITR to 783 indicate to an ETR the up/down status of the Locators in the 784 source site. Each RLOC in a Map-Reply is assigned an ordinal 785 value from 0 to n-1 (when there are n RLOCs in a mapping entry). 786 The Locator-Status-Bits are numbered from 0 to n-1 from the least 787 significant bit of the field. The field is 32 bits when the I-bit 788 is set to 0 and is 8 bits when the I-bit is set to 1. When a 789 Locator-Status-Bit is set to 1, the ITR is indicating to the ETR 790 that the RLOC associated with the bit ordinal has up status. See 791 Section 10 for details on how an ITR can determine the status of 792 the ETRs at the same site. When a site has multiple EID-Prefixes 793 that result in multiple mappings (where each could have a 794 different Locator-Set), the Locator-Status-Bits setting in an 795 encapsulated packet MUST reflect the mapping for the EID-Prefix 796 that the inner-header source EID address matches. If the LSB for 797 an anycast Locator is set to 1, then there is at least one RLOC 798 with that address, and the ETR is considered 'up'. 800 When doing ITR/PITR encapsulation: 802 o The outer-header 'Time to Live' field (or 'Hop Limit' field, in 803 the case of IPv6) SHOULD be copied from the inner-header 'Time to 804 Live' field. 806 o The outer-header 'Differentiated Services Code Point' (DSCP) field 807 (or the 'Traffic Class' field, in the case of IPv6) SHOULD be 808 copied from the inner-header DSCP field ('Traffic Class' field, in 809 the case of IPv6) considering the exception listed below. 811 o The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 812 of the IPv6 'Traffic Class' field) requires special treatment in 813 order to avoid discarding indications of congestion [RFC3168]. 814 ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner 815 header to the outer header. Re-encapsulation MUST copy the 2-bit 816 'ECN' field from the stripped outer header to the new outer 817 header. 819 When doing ETR/PETR decapsulation: 821 o The inner-header 'Time to Live' field (or 'Hop Limit' field, in 822 the case of IPv6) SHOULD be copied from the outer-header 'Time to 823 Live' field, when the Time to Live value of the outer header is 824 less than the Time to Live value of the inner header. Failing to 825 perform this check can cause the Time to Live of the inner header 826 to increment across encapsulation/decapsulation cycles. This 827 check is also performed when doing initial encapsulation, when a 828 packet comes to an ITR or PITR destined for a LISP site. 830 o The inner-header 'Differentiated Services Code Point' (DSCP) field 831 (or the 'Traffic Class' field, in the case of IPv6) SHOULD be 832 copied from the outer-header DSCP field ('Traffic Class' field, in 833 the case of IPv6) considering the exception listed below. 835 o The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7 836 of the IPv6 'Traffic Class' field) requires special treatment in 837 order to avoid discarding indications of congestion [RFC3168]. If 838 the 'ECN' field contains a congestion indication codepoint (the 839 value is '11', the Congestion Experienced (CE) codepoint), then 840 ETR decapsulation MUST copy the 2-bit 'ECN' field from the 841 stripped outer header to the surviving inner header that is used 842 to forward the packet beyond the ETR. These requirements preserve 843 CE indications when a packet that uses ECN traverses a LISP tunnel 844 and becomes marked with a CE indication due to congestion between 845 the tunnel endpoints. 847 Note that if an ETR/PETR is also an ITR/PITR and chooses to re- 848 encapsulate after decapsulating, the net effect of this is that the 849 new outer header will carry the same Time to Live as the old outer 850 header minus 1. 852 Copying the Time to Live (TTL) serves two purposes: first, it 853 preserves the distance the host intended the packet to travel; 854 second, and more importantly, it provides for suppression of looping 855 packets in the event there is a loop of concatenated tunnels due to 856 misconfiguration. 858 The Explicit Congestion Notification ('ECN') field occupies bits 6 859 and 7 of both the IPv4 'Type of Service' field and the IPv6 'Traffic 860 Class' field [RFC3168]. The 'ECN' field requires special treatment 861 in order to avoid discarding indications of congestion [RFC3168]. An 862 ITR/PITR encapsulation MUST copy the 2-bit 'ECN' field from the inner 863 header to the outer header. Re-encapsulation MUST copy the 2-bit 864 'ECN' field from the stripped outer header to the new outer header. 865 If the 'ECN' field contains a congestion indication codepoint (the 866 value is '11', the Congestion Experienced (CE) codepoint), then ETR/ 867 PETR decapsulation MUST copy the 2-bit 'ECN' field from the stripped 868 outer header to the surviving inner header that is used to forward 869 the packet beyond the ETR. These requirements preserve CE 870 indications when a packet that uses ECN traverses a LISP tunnel and 871 becomes marked with a CE indication due to congestion between the 872 tunnel endpoints. 874 6. LISP EID-to-RLOC Map-Cache 876 ITRs and PITRs maintain an on-demand cache, referred as LISP EID-to- 877 RLOC Map-Cache, that contains mappings from EID-prefixes to locator 878 sets. The cache is used to encapsulate packets from the EID space to 879 the corresponding RLOC network attachment point. 881 When an ITR/PITR receives a packet from inside of the LISP site to 882 destinations outside of the site a longest-prefix match lookup of the 883 EID is done to the Map-Cache. 885 When the lookup succeeds, the Locator-Set retrieved from the Map- 886 Cache is used to send the packet to the EID's topological location. 888 If the lookup fails, the ITR/PITR needs to retrieve the mapping using 889 the LISP Control-Plane protocol [I-D.ietf-lisp-rfc6833bis]. The 890 mapping is then stored in the local Map-Cache to forward subsequent 891 packets addressed to the same EID-prefix. 893 The Map-Cache is a local cache of mappings, entries are expired based 894 on the associated Time to live. In addition, entries can be updated 895 with more current information, see Section 13 for further information 896 on this. Finally, the Map-Cache also contains reachability 897 information about EIDs and RLOCs, and uses LISP reachability 898 information mechanisms to determine the reachability of RLOCs, see 899 Section 10 for the specific mechanisms. 901 7. Dealing with Large Encapsulated Packets 903 This section proposes two mechanisms to deal with packets that exceed 904 the path MTU between the ITR and ETR. 906 It is left to the implementor to decide if the stateless or stateful 907 mechanism SHOULD be implemented. Both or neither can be used, since 908 it is a local decision in the ITR regarding how to deal with MTU 909 issues, and sites can interoperate with differing mechanisms. 911 Both stateless and stateful mechanisms also apply to Re-encapsulating 912 and Recursive Tunneling, so any actions below referring to an ITR 913 also apply to a TE-ITR. 915 7.1. A Stateless Solution to MTU Handling 917 An ITR stateless solution to handle MTU issues is described as 918 follows: 920 1. Define H to be the size, in octets, of the outer header an ITR 921 prepends to a packet. This includes the UDP and LISP header 922 lengths. 924 2. Define L to be the size, in octets, of the maximum-sized packet 925 an ITR can send to an ETR without the need for the ITR or any 926 intermediate routers to fragment the packet. 928 3. Define an architectural constant S for the maximum size of a 929 packet, in octets, an ITR MUST receive from the source so the 930 effective MTU can be met. That is, L = S + H. 932 When an ITR receives a packet from a site-facing interface and adds H 933 octets worth of encapsulation to yield a packet size greater than L 934 octets (meaning the received packet size was greater than S octets 935 from the source), it resolves the MTU issue by first splitting the 936 original packet into 2 equal-sized fragments. A LISP header is then 937 prepended to each fragment. The size of the encapsulated fragments 938 is then (S/2 + H), which is less than the ITR's estimate of the path 939 MTU between the ITR and its correspondent ETR. 941 When an ETR receives encapsulated fragments, it treats them as two 942 individually encapsulated packets. It strips the LISP headers and 943 then forwards each fragment to the destination host of the 944 destination site. The two fragments are reassembled at the 945 destination host into the single IP datagram that was originated by 946 the source host. Note that reassembly can happen at the ETR if the 947 encapsulated packet was fragmented at or after the ITR. 949 This behavior is performed by the ITR when the source host originates 950 a packet with the 'DF' field of the IP header set to 0. When the 951 'DF' field of the IP header is set to 1, or the packet is an IPv6 952 packet originated by the source host, the ITR will drop the packet 953 when the size is greater than L and send an ICMP Unreachable/ 954 Fragmentation-Needed message to the source with a value of S, where S 955 is (L - H). 957 When the outer-header encapsulation uses an IPv4 header, an 958 implementation SHOULD set the DF bit to 1 so ETR fragment reassembly 959 can be avoided. An implementation MAY set the DF bit in such headers 960 to 0 if it has good reason to believe there are unresolvable path MTU 961 issues between the sending ITR and the receiving ETR. 963 This specification RECOMMENDS that L be defined as 1500. 965 7.2. A Stateful Solution to MTU Handling 967 An ITR stateful solution to handle MTU issues is described as follows 968 and was first introduced in [OPENLISP]: 970 1. The ITR will keep state of the effective MTU for each Locator per 971 Map-Cache entry. The effective MTU is what the core network can 972 deliver along the path between the ITR and ETR. 974 2. When an IPv6-encapsulated packet, or an IPv4-encapsulated packet 975 with the DF bit set to 1, exceeds what the core network can 976 deliver, one of the intermediate routers on the path will send an 977 ICMPv6 "Packet Too Big" message to the ITR. The ITR will parse 978 the ICMPv6 message to determine which Locator is affected by the 979 effective MTU change and then record the new effective MTU value 980 in the Map-Cache entry. 982 3. When a packet is received by the ITR from a source inside of the 983 site and the size of the packet is greater than the effective MTU 984 stored with the Map-Cache entry associated with the destination 985 EID the packet is for, the ITR will send an ICMPv6 "Packet Too 986 Big" message back to the source. The packet size advertised by 987 the ITR in the ICMPv6 message is the effective MTU minus the LISP 988 encapsulation length. 990 Even though this mechanism is stateful, it has advantages over the 991 stateless IP fragmentation mechanism, by not involving the 992 destination host with reassembly of ITR fragmented packets. 994 8. Using Virtualization and Segmentation with LISP 996 There are several cases where segregation is needed at the EID level. 997 For instance, this is the case for deployments containing overlapping 998 addresses, traffic isolation policies or multi-tenant virtualization. 999 For these and other scenarios where segregation is needed, Instance 1000 IDs are used. 1002 An Instance ID can be carried in a LISP-encapsulated packet. An ITR 1003 that prepends a LISP header will copy a 24-bit value used by the LISP 1004 router to uniquely identify the address space. The value is copied 1005 to the 'Instance ID' field of the LISP header, and the I-bit is set 1006 to 1. 1008 When an ETR decapsulates a packet, the Instance ID from the LISP 1009 header is used as a table identifier to locate the forwarding table 1010 to use for the inner destination EID lookup. 1012 For example, an 802.1Q VLAN tag or VPN identifier could be used as a 1013 24-bit Instance ID. See [I-D.ietf-lisp-vpn] for LISP VPN use-case 1014 details. 1016 The Instance ID that is stored in the mapping database when LISP-DDT 1017 [RFC8111] is used is 32 bits in length. That means the Control-Plane 1018 can store more instances than a given Data-Plane can use. Multiple 1019 Data-Planes can use the same 32-bit space as long as the low-order 24 1020 bits don't overlap among xTRs. 1022 9. Routing Locator Selection 1024 The Map-Cache contains the state used by ITRs and PITRs to 1025 encapsulate packets. When an ITR/PITR receives a packet from inside 1026 the LISP site to a destination outside of the site a longest-prefix 1027 match lookup of the EID is done to the Map-Cache (see Section 6). 1028 The lookup returns a single Locator-Set containing a list of RLOCs 1029 corresponding to the EID's topological location. Each RLOC in the 1030 Locator-Set is associated with a 'Priority' and 'Weight', this 1031 information is used to select the RLOC to encapsulate. 1033 The RLOC with the lowest 'Priority' is selected. An RLOC with 1034 'Priority' 255 means that MUST NOT be used for forwarding. When 1035 multiple RLOC have the same 'Priority' then the 'Weight' states how 1036 to load balance traffic among them. The value of the 'Weight' 1037 represents the relative weight of the total packets that match the 1038 maping entry. 1040 The following are different scenarios for choosing RLOCs and the 1041 controls that are available: 1043 o The server-side returns one RLOC. The client-side can only use 1044 one RLOC. The server-side has complete control of the selection. 1046 o The server-side returns a list of RLOCs where a subset of the list 1047 has the same best Priority. The client can only use the subset 1048 list according to the weighting assigned by the server-side. In 1049 this case, the server-side controls both the subset list and load- 1050 splitting across its members. The client-side can use RLOCs 1051 outside of the subset list if it determines that the subset list 1052 is unreachable (unless RLOCs are set to a Priority of 255). Some 1053 sharing of control exists: the server-side determines the 1054 destination RLOC list and load distribution while the client-side 1055 has the option of using alternatives to this list if RLOCs in the 1056 list are unreachable. 1058 o The server-side sets a Weight of zero for the RLOC subset list. 1059 In this case, the client-side can choose how the traffic load is 1060 spread across the subset list. Control is shared by the server- 1061 side determining the list and the client-side determining load 1062 distribution. Again, the client can use alternative RLOCs if the 1063 server-provided list of RLOCs is unreachable. 1065 o Either side (more likely the server-side ETR) decides not to send 1066 a Map-Request. For example, if the server-side ETR does not send 1067 Map-Requests, it gleans RLOCs from the client-side ITR, giving the 1068 client-side ITR responsibility for bidirectional RLOC reachability 1069 and preferability. Server-side ETR gleaning of the client-side 1070 ITR RLOC is done by caching the inner-header source EID and the 1071 outer-header source RLOC of received packets. The client-side ITR 1072 controls how traffic is returned and can alternate using an outer- 1073 header source RLOC, which then can be added to the list the 1074 server-side ETR uses to return traffic. Since no Priority or 1075 Weights are provided using this method, the server-side ETR MUST 1076 assume that each client-side ITR RLOC uses the same best Priority 1077 with a Weight of zero. In addition, since EID-Prefix encoding 1078 cannot be conveyed in data packets, the EID-to-RLOC Cache on 1079 Tunnel Routers can grow to be very large. 1081 Alternatively, RLOC information MAY be gleaned from received tunneled 1082 packets or EID-to-RLOC Map-Request messages. A "gleaned" Map-Cache 1083 entry, one learned from the source RLOC of a received encapsulated 1084 packet, is only stored and used for a few seconds, pending 1085 verification. Verification is performed by sending a Map-Request to 1086 the source EID (the inner-header IP source address) of the received 1087 encapsulated packet. A reply to this "verifying Map-Request" is used 1088 to fully populate the Map-Cache entry for the "gleaned" EID and is 1089 stored and used for the time indicated from the 'TTL' field of a 1090 received Map-Reply. When a verified Map-Cache entry is stored, data 1091 gleaning no longer occurs for subsequent packets that have a source 1092 EID that matches the EID-Prefix of the verified entry. This 1093 "gleaning" mechanism is OPTIONAL, refer to Section 16 for security 1094 issues regarding this mechanism. 1096 RLOCs that appear in EID-to-RLOC Map-Reply messages are assumed to be 1097 reachable when the R-bit for the Locator record is set to 1. When 1098 the R-bit is set to 0, an ITR or PITR MUST NOT encapsulate to the 1099 RLOC. Neither the information contained in a Map-Reply nor that 1100 stored in the mapping database system provides reachability 1101 information for RLOCs. Note that reachability is not part of the 1102 mapping system and is determined using one or more of the Routing 1103 Locator reachability algorithms described in the next section. 1105 10. Routing Locator Reachability 1107 Several Data-Plane mechanisms for determining RLOC reachability are 1108 currently defined. Please note that additional Control-Plane based 1109 reachability mechanisms are defined in [I-D.ietf-lisp-rfc6833bis]. 1111 1. An ETR MAY examine the Locator-Status-Bits in the LISP header of 1112 an encapsulated data packet received from an ITR. If the ETR is 1113 also acting as an ITR and has traffic to return to the original 1114 ITR site, it can use this status information to help select an 1115 RLOC. 1117 2. When an ETR receives an encapsulated packet from an ITR, the 1118 source RLOC from the outer header of the packet is likely up. 1120 3. An ITR/ETR pair can use the 'Echo-Noncing' Locator reachability 1121 algorithms described in this section. 1123 When determining Locator up/down reachability by examining the 1124 Locator-Status-Bits from the LISP-encapsulated data packet, an ETR 1125 will receive up-to-date status from an encapsulating ITR about 1126 reachability for all ETRs at the site. CE-based ITRs at the source 1127 site can determine reachability relative to each other using the site 1128 IGP as follows: 1130 o Under normal circumstances, each ITR will advertise a default 1131 route into the site IGP. 1133 o If an ITR fails or if the upstream link to its PE fails, its 1134 default route will either time out or be withdrawn. 1136 Each ITR can thus observe the presence or lack of a default route 1137 originated by the others to determine the Locator-Status-Bits it sets 1138 for them. 1140 When ITRs at the site are not deployed in CE routers, the IGP can 1141 still be used to determine the reachability of Locators, provided 1142 they are injected into the IGP. This is typically done when a /32 1143 address is configured on a loopback interface. 1145 RLOCs listed in a Map-Reply are numbered with ordinals 0 to n-1. The 1146 Locator-Status-Bits in a LISP-encapsulated packet are numbered from 0 1147 to n-1 starting with the least significant bit. For example, if an 1148 RLOC listed in the 3rd position of the Map-Reply goes down (ordinal 1149 value 2), then all ITRs at the site will clear the 3rd least 1150 significant bit (xxxx x0xx) of the 'Locator-Status-Bits' field for 1151 the packets they encapsulate. 1153 When an ETR decapsulates a packet, it will check for any change in 1154 the 'Locator-Status-Bits' field. When a bit goes from 1 to 0, the 1155 ETR, if acting also as an ITR, will refrain from encapsulating 1156 packets to an RLOC that is indicated as down. It will only resume 1157 using that RLOC if the corresponding Locator-Status-Bit returns to a 1158 value of 1. Locator-Status-Bits are associated with a Locator-Set 1159 per EID-Prefix. Therefore, when a Locator becomes unreachable, the 1160 Locator-Status-Bit that corresponds to that Locator's position in the 1161 list returned by the last Map-Reply will be set to zero for that 1162 particular EID-Prefix. Refer to Section 16 for security related 1163 issues regarding Locator-Status-Bits. 1165 When an ETR decapsulates a packet, it knows that it is reachable from 1166 the encapsulating ITR because that is how the packet arrived. In 1167 most cases, the ETR can also reach the ITR but cannot assume this to 1168 be true, due to the possibility of path asymmetry. In the presence 1169 of unidirectional traffic flow from an ITR to an ETR, the ITR SHOULD 1170 NOT use the lack of return traffic as an indication that the ETR is 1171 unreachable. Instead, it MUST use an alternate mechanism to 1172 determine reachability. 1174 10.1. Echo Nonce Algorithm 1176 When data flows bidirectionally between Locators from different 1177 sites, a Data-Plane mechanism called "nonce echoing" can be used to 1178 determine reachability between an ITR and ETR. When an ITR wants to 1179 solicit a nonce echo, it sets the N- and E-bits and places a 24-bit 1180 nonce [RFC4086] in the LISP header of the next encapsulated data 1181 packet. 1183 When this packet is received by the ETR, the encapsulated packet is 1184 forwarded as normal. When the ETR next sends a data packet to the 1185 ITR, it includes the nonce received earlier with the N-bit set and 1186 E-bit cleared. The ITR sees this "echoed nonce" and knows that the 1187 path to and from the ETR is up. 1189 The ITR will set the E-bit and N-bit for every packet it sends while 1190 in the echo-nonce-request state. The time the ITR waits to process 1191 the echoed nonce before it determines the path is unreachable is 1192 variable and is a choice left for the implementation. 1194 If the ITR is receiving packets from the ETR but does not see the 1195 nonce echoed while being in the echo-nonce-request state, then the 1196 path to the ETR is unreachable. This decision MAY be overridden by 1197 other Locator reachability algorithms. Once the ITR determines that 1198 the path to the ETR is down, it can switch to another Locator for 1199 that EID-Prefix. 1201 Note that "ITR" and "ETR" are relative terms here. Both devices MUST 1202 be implementing both ITR and ETR functionality for the echo nonce 1203 mechanism to operate. 1205 The ITR and ETR MAY both go into the echo-nonce-request state at the 1206 same time. The number of packets sent or the time during which echo 1207 nonce requests are sent is an implementation-specific setting. 1208 However, when an ITR is in the echo-nonce-request state, it can echo 1209 the ETR's nonce in the next set of packets that it encapsulates and 1210 subsequently continue sending echo-nonce-request packets. 1212 This mechanism does not completely solve the forward path 1213 reachability problem, as traffic may be unidirectional. That is, the 1214 ETR receiving traffic at a site MAY not be the same device as an ITR 1215 that transmits traffic from that site, or the site-to-site traffic is 1216 unidirectional so there is no ITR returning traffic. 1218 The echo-nonce algorithm is bilateral. That is, if one side sets the 1219 E-bit and the other side is not enabled for echo-noncing, then the 1220 echoing of the nonce does not occur and the requesting side may 1221 erroneously consider the Locator unreachable. An ITR SHOULD only set 1222 the E-bit in an encapsulated data packet when it knows the ETR is 1223 enabled for echo-noncing. This is conveyed by the E-bit in the RLOC- 1224 probe Map-Reply message. 1226 11. EID Reachability within a LISP Site 1228 A site MAY be multihomed using two or more ETRs. The hosts and 1229 infrastructure within a site will be addressed using one or more EID- 1230 Prefixes that are mapped to the RLOCs of the relevant ETRs in the 1231 mapping system. One possible failure mode is for an ETR to lose 1232 reachability to one or more of the EID-Prefixes within its own site. 1233 When this occurs when the ETR sends Map-Replies, it can clear the 1234 R-bit associated with its own Locator. And when the ETR is also an 1235 ITR, it can clear its Locator-Status-Bit in the encapsulation data 1236 header. 1238 It is recognized that there are no simple solutions to the site 1239 partitioning problem because it is hard to know which part of the 1240 EID-Prefix range is partitioned and which Locators can reach any sub- 1241 ranges of the EID-Prefixes. Note that this is not a new problem 1242 introduced by the LISP architecture. The problem exists today when a 1243 multihomed site uses BGP to advertise its reachability upstream. 1245 12. Routing Locator Hashing 1247 When an ETR provides an EID-to-RLOC mapping in a Map-Reply message 1248 that is stored in the Map-Cache of a requesting ITR, the Locator-Set 1249 for the EID-Prefix MAY contain different Priority and Weight values 1250 for each locator address. When more than one best Priority Locator 1251 exists, the ITR can decide how to load-share traffic against the 1252 corresponding Locators. 1254 The following hash algorithm MAY be used by an ITR to select a 1255 Locator for a packet destined to an EID for the EID-to-RLOC mapping: 1257 1. Either a source and destination address hash or the traditional 1258 5-tuple hash can be used. The traditional 5-tuple hash includes 1259 the source and destination addresses; source and destination TCP, 1260 UDP, or Stream Control Transmission Protocol (SCTP) port numbers; 1261 and the IP protocol number field or IPv6 next-protocol fields of 1262 a packet that a host originates from within a LISP site. When a 1263 packet is not a TCP, UDP, or SCTP packet, the source and 1264 destination addresses only from the header are used to compute 1265 the hash. 1267 2. Take the hash value and divide it by the number of Locators 1268 stored in the Locator-Set for the EID-to-RLOC mapping. 1270 3. The remainder will yield a value of 0 to "number of Locators 1271 minus 1". Use the remainder to select the Locator in the 1272 Locator-Set. 1274 Note that when a packet is LISP encapsulated, the source port number 1275 in the outer UDP header needs to be set. Selecting a hashed value 1276 allows core routers that are attached to Link Aggregation Groups 1277 (LAGs) to load-split the encapsulated packets across member links of 1278 such LAGs. Otherwise, core routers would see a single flow, since 1279 packets have a source address of the ITR, for packets that are 1280 originated by different EIDs at the source site. A suggested setting 1281 for the source port number computed by an ITR is a 5-tuple hash 1282 function on the inner header, as described above. 1284 Many core router implementations use a 5-tuple hash to decide how to 1285 balance packet load across members of a LAG. The 5-tuple hash 1286 includes the source and destination addresses of the packet and the 1287 source and destination ports when the protocol number in the packet 1288 is TCP or UDP. For this reason, UDP encoding is used for LISP 1289 encapsulation. 1291 13. Changing the Contents of EID-to-RLOC Mappings 1293 Since the LISP architecture uses a caching scheme to retrieve and 1294 store EID-to-RLOC mappings, the only way an ITR can get a more up-to- 1295 date mapping is to re-request the mapping. However, the ITRs do not 1296 know when the mappings change, and the ETRs do not keep track of 1297 which ITRs requested its mappings. For scalability reasons, it is 1298 desirable to maintain this approach but need to provide a way for 1299 ETRs to change their mappings and inform the sites that are currently 1300 communicating with the ETR site using such mappings. 1302 This section defines a Data-Plane mechanism for updating EID-to-RLOC 1303 mappings. Additionally, the Solicit-Map Request (SMR) Control-Plane 1304 updating mechanism is specified in [I-D.ietf-lisp-rfc6833bis]. 1306 When adding a new Locator record in lexicographic order to the end of 1307 a Locator-Set, it is easy to update mappings. We assume that new 1308 mappings will maintain the same Locator ordering as the old mapping 1309 but will just have new Locators appended to the end of the list. So, 1310 some ITRs can have a new mapping while other ITRs have only an old 1311 mapping that is used until they time out. When an ITR has only an 1312 old mapping but detects bits set in the Locator-Status-Bits that 1313 correspond to Locators beyond the list it has cached, it simply 1314 ignores them. However, this can only happen for locator addresses 1315 that are lexicographically greater than the locator addresses in the 1316 existing Locator-Set. 1318 When a Locator record is inserted in the middle of a Locator-Set, to 1319 maintain lexicographic order, SMR procedure 1320 [I-D.ietf-lisp-rfc6833bis] is used to inform ITRs and PITRs of the 1321 new Locator-Status-Bit mappings. 1323 When a Locator record is removed from a Locator-Set, ITRs that have 1324 the mapping cached will not use the removed Locator because the xTRs 1325 will set the Locator-Status-Bit to 0. So, even if the Locator is in 1326 the list, it will not be used. For new mapping requests, the xTRs 1327 can set the Locator AFI to 0 (indicating an unspecified address), as 1328 well as setting the corresponding Locator-Status-Bit to 0. This 1329 forces ITRs with old or new mappings to avoid using the removed 1330 Locator. 1332 If many changes occur to a mapping over a long period of time, one 1333 will find empty record slots in the middle of the Locator-Set and new 1334 records appended to the Locator-Set. At some point, it would be 1335 useful to compact the Locator-Set so the Locator-Status-Bit settings 1336 can be efficiently packed. 1338 We propose here a Data-Plane mechanism (Map-Versioning specified in 1339 [I-D.ietf-lisp-6834bis]) to update the contents of EID-to-RLOC 1340 mappings. Please note that in addition the Solicit-Map Request 1341 (specified in [I-D.ietf-lisp-rfc6833bis]) is a Control-Plane 1342 mechanisms that can be used to update EID-to-RLOC mappings. 1344 13.1. Database Map-Versioning 1346 When there is unidirectional packet flow between an ITR and ETR, and 1347 the EID-to-RLOC mappings change on the ETR, it needs to inform the 1348 ITR so encapsulation to a removed Locator can stop and can instead be 1349 started to a new Locator in the Locator-Set. 1351 An ETR, when it sends Map-Reply messages, conveys its own Map-Version 1352 Number. This is known as the Destination Map-Version Number. ITRs 1353 include the Destination Map-Version Number in packets they 1354 encapsulate to the site. When an ETR decapsulates a packet and 1355 detects that the Destination Map-Version Number is less than the 1356 current version for its mapping, the SMR procedure described in 1357 [I-D.ietf-lisp-rfc6833bis] occurs. 1359 An ITR, when it encapsulates packets to ETRs, can convey its own Map- 1360 Version Number. This is known as the Source Map-Version Number. 1361 When an ETR decapsulates a packet and detects that the Source Map- 1362 Version Number is greater than the last Map-Version Number sent in a 1363 Map-Reply from the ITR's site, the ETR will send a Map-Request to one 1364 of the ETRs for the source site. 1366 A Map-Version Number is used as a sequence number per EID-Prefix, so 1367 values that are greater are considered to be more recent. A value of 1368 0 for the Source Map-Version Number or the Destination Map-Version 1369 Number conveys no versioning information, and an ITR does no 1370 comparison with previously received Map-Version Numbers. 1372 A Map-Version Number can be included in Map-Register messages as 1373 well. This is a good way for the Map-Server to assure that all ETRs 1374 for a site registering to it will be synchronized according to Map- 1375 Version Number. 1377 See [I-D.ietf-lisp-6834bis] for a more detailed analysis and 1378 description of Database Map-Versioning. 1380 14. Multicast Considerations 1382 A multicast group address, as defined in the original Internet 1383 architecture, is an identifier of a grouping of topologically 1384 independent receiver host locations. The address encoding itself 1385 does not determine the location of the receiver(s). The multicast 1386 routing protocol, and the network-based state the protocol creates, 1387 determine where the receivers are located. 1389 In the context of LISP, a multicast group address is both an EID and 1390 a Routing Locator. Therefore, no specific semantic or action needs 1391 to be taken for a destination address, as it would appear in an IP 1392 header. Therefore, a group address that appears in an inner IP 1393 header built by a source host will be used as the destination EID. 1394 The outer IP header (the destination Routing Locator address), 1395 prepended by a LISP router, can use the same group address as the 1396 destination Routing Locator, use a multicast or unicast Routing 1397 Locator obtained from a Mapping System lookup, or use other means to 1398 determine the group address mapping. 1400 With respect to the source Routing Locator address, the ITR prepends 1401 its own IP address as the source address of the outer IP header. 1402 Just like it would if the destination EID was a unicast address. 1403 This source Routing Locator address, like any other Routing Locator 1404 address, MUST be globally routable. 1406 There are two approaches for LISP-Multicast, one that uses native 1407 multicast routing in the underlay with no support from the Mapping 1408 System and the other that uses only unicast routing in the underlay 1409 with support from the Mapping System. See [RFC6831] and [RFC8378], 1410 respectively, for details. Details for LISP-Multicast and 1411 interworking with non-LISP sites are described in [RFC6831] and 1412 [RFC6832]. 1414 15. Router Performance Considerations 1416 LISP is designed to be very "hardware-based forwarding friendly". A 1417 few implementation techniques can be used to incrementally implement 1418 LISP: 1420 o When a tunnel-encapsulated packet is received by an ETR, the outer 1421 destination address may not be the address of the router. This 1422 makes it challenging for the control plane to get packets from the 1423 hardware. This may be mitigated by creating special Forwarding 1424 Information Base (FIB) entries for the EID-Prefixes of EIDs served 1425 by the ETR (those for which the router provides an RLOC 1426 translation). These FIB entries are marked with a flag indicating 1427 that Control-Plane processing SHOULD be performed. The forwarding 1428 logic of testing for particular IP protocol number values is not 1429 necessary. There are a few proven cases where no changes to 1430 existing deployed hardware were needed to support the LISP Data- 1431 Plane. 1433 o On an ITR, prepending a new IP header consists of adding more 1434 octets to a MAC rewrite string and prepending the string as part 1435 of the outgoing encapsulation procedure. Routers that support 1436 Generic Routing Encapsulation (GRE) tunneling [RFC2784] or 6to4 1437 tunneling [RFC3056] may already support this action. 1439 o A packet's source address or interface the packet was received on 1440 can be used to select VRF (Virtual Routing/Forwarding). The VRF's 1441 routing table can be used to find EID-to-RLOC mappings. 1443 For performance issues related to Map-Cache management, see 1444 Section 16. 1446 16. Security Considerations 1448 Security considerations for LISP are discussed in [RFC7833]. 1450 A complete LISP threat analysis can be found in [RFC7835], in what 1451 follows we provide a summary. 1453 The optional mechanisms of gleaning is offered to directly obtain a 1454 mapping from the LISP encapsulated packets. Specifically, an xTR can 1455 learn the EID-to-RLOC mapping by inspecting the source RLOC and 1456 source EID of an encapsulated packet, and insert this new mapping 1457 into its Map-Cache. An off-path attacker can spoof the source EID 1458 address to divert the traffic sent to the victim's spoofed EID. If 1459 the attacker spoofs the source RLOC, it can mount a DoS attack by 1460 redirecting traffic to the spoofed victim's RLOC, potentially 1461 overloading it. 1463 The LISP Data-Plane defines several mechanisms to monitor RLOC Data- 1464 Plane reachability, in this context Locator-Status Bits, Nonce- 1465 Present and Echo-Nonce bits of the LISP encapsulation header can be 1466 manipulated by an attacker to mount a DoS attack. An off-path 1467 attacker able to spoof the RLOC of a victim's xTR can manipulate such 1468 mechanisms to declare a set of RLOCs unreachable. This can be used 1469 also, for instance, to declare only one RLOC reachable with the aim 1470 of overload it. 1472 Map-Versioning is a Data-Plane mechanism used to signal a peering xTR 1473 that a local EID-to-RLOC mapping has been updated, so that the 1474 peering xTR uses LISP Control-Plane signaling message to retrieve a 1475 fresh mapping. This can be used by an attacker to forge the map- 1476 versioning field of a LISP encapsulated header and force an excessive 1477 amount of signaling between xTRs that may overload them. 1479 Most of the attack vectors can be mitigated with careful deployment 1480 and configuration, information learned opportunistically (such as LSB 1481 or gleaning) SHOULD be verified with other reachability mechanisms. 1482 In addition, systematic rate-limitation and filtering is an effective 1483 technique to mitigate attacks that aim to overload the Control-Plane. 1485 17. Network Management Considerations 1487 Considerations for network management tools exist so the LISP 1488 protocol suite can be operationally managed. These mechanisms can be 1489 found in [RFC7052] and [RFC6835]. 1491 18. Changes since RFC 6830 1493 For implementation considerations, the following changes have been 1494 made to this document since RFC 6830 was published: 1496 o It is no longer mandated that a maximum number of 2 LISP headers 1497 be prepended to a packet. If there is a application need for more 1498 than 2 LISP headers, an implementation can support more. However, 1499 this document recommends a maximum of 2 LISP headers. 1501 o The 3 reserved flag bits in the LISP header have been allocated 1502 for [RFC8060]. The low-order 2 bits of the 3-bit field (now named 1503 the KK bits) are used as a key identifier. The 1 remaining bit is 1504 still documented as reserved. 1506 o Data-Plane gleaning for creating map-cache entries has been made 1507 optional. If any ITR implementations depend or assume the remote 1508 ETR is gleaning should not do so. This does not create any 1509 interoperability problems since the control-plane map-cache 1510 population procedures are unilateral and are the typical method 1511 for map-cache population. 1513 19. IANA Considerations 1515 This section provides guidance to the Internet Assigned Numbers 1516 Authority (IANA) regarding registration of values related to this 1517 Data-Plane LISP specification, in accordance with BCP 26 [RFC8126]. 1519 19.1. LISP UDP Port Numbers 1521 The IANA registry has allocated UDP port number 4341 for the LISP 1522 Data-Plane. IANA has updated the description for UDP port 4341 as 1523 follows: 1525 lisp-data 4341 udp LISP Data Packets 1527 20. References 1529 20.1. Normative References 1531 [I-D.ietf-lisp-6834bis] 1532 Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID 1533 Separation Protocol (LISP) Map-Versioning", draft-ietf- 1534 lisp-6834bis-00 (work in progress), July 2018. 1536 [I-D.ietf-lisp-rfc6833bis] 1537 Fuller, V., Farinacci, D., and A. Cabellos-Aparicio, 1538 "Locator/ID Separation Protocol (LISP) Control-Plane", 1539 draft-ietf-lisp-rfc6833bis-13 (work in progress), August 1540 2018. 1542 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1543 DOI 10.17487/RFC0768, August 1980, 1544 . 1546 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1547 DOI 10.17487/RFC0791, September 1981, 1548 . 1550 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1551 "Definition of the Differentiated Services Field (DS 1552 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1553 DOI 10.17487/RFC2474, December 1998, 1554 . 1556 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1557 of Explicit Congestion Notification (ECN) to IP", 1558 RFC 3168, DOI 10.17487/RFC3168, September 2001, 1559 . 1561 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1562 (IPv6) Specification", STD 86, RFC 8200, 1563 DOI 10.17487/RFC8200, July 2017, 1564 . 1566 20.2. Informative References 1568 [AFN] IANA, "Address Family Numbers", August 2016, 1569 . 1571 [CHIAPPA] Chiappa, J., "Endpoints and Endpoint names: A Proposed", 1572 1999, 1573 . 1575 [I-D.ietf-lisp-introduction] 1576 Cabellos-Aparicio, A. and D. Saucez, "An Architectural 1577 Introduction to the Locator/ID Separation Protocol 1578 (LISP)", draft-ietf-lisp-introduction-13 (work in 1579 progress), April 2015. 1581 [I-D.ietf-lisp-vpn] 1582 Moreno, V. and D. Farinacci, "LISP Virtual Private 1583 Networks (VPNs)", draft-ietf-lisp-vpn-02 (work in 1584 progress), May 2018. 1586 [OPENLISP] 1587 Iannone, L., Saucez, D., and O. Bonaventure, "OpenLISP 1588 Implementation Report", Work in Progress, July 2008. 1590 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1591 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1592 . 1594 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 1595 and E. Lear, "Address Allocation for Private Internets", 1596 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 1597 . 1599 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1600 Requirement Levels", BCP 14, RFC 2119, 1601 DOI 10.17487/RFC2119, March 1997, 1602 . 1604 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 1605 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 1606 DOI 10.17487/RFC2784, March 2000, 1607 . 1609 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1610 via IPv4 Clouds", RFC 3056, DOI 10.17487/RFC3056, February 1611 2001, . 1613 [RFC3232] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced 1614 by an On-line Database", RFC 3232, DOI 10.17487/RFC3232, 1615 January 2002, . 1617 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1618 A., Peterson, J., Sparks, R., Handley, M., and E. 1619 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1620 DOI 10.17487/RFC3261, June 2002, 1621 . 1623 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1624 "Randomness Requirements for Security", BCP 106, RFC 4086, 1625 DOI 10.17487/RFC4086, June 2005, 1626 . 1628 [RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report 1629 from the IAB Workshop on Routing and Addressing", 1630 RFC 4984, DOI 10.17487/RFC4984, September 2007, 1631 . 1633 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 1634 Locator/ID Separation Protocol (LISP) for Multicast 1635 Environments", RFC 6831, DOI 10.17487/RFC6831, January 1636 2013, . 1638 [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 1639 "Interworking between Locator/ID Separation Protocol 1640 (LISP) and Non-LISP Sites", RFC 6832, 1641 DOI 10.17487/RFC6832, January 2013, 1642 . 1644 [RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation 1645 Protocol Internet Groper (LIG)", RFC 6835, 1646 DOI 10.17487/RFC6835, January 2013, 1647 . 1649 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 1650 UDP Checksums for Tunneled Packets", RFC 6935, 1651 DOI 10.17487/RFC6935, April 2013, 1652 . 1654 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 1655 for the Use of IPv6 UDP Datagrams with Zero Checksums", 1656 RFC 6936, DOI 10.17487/RFC6936, April 2013, 1657 . 1659 [RFC7052] Schudel, G., Jain, A., and V. Moreno, "Locator/ID 1660 Separation Protocol (LISP) MIB", RFC 7052, 1661 DOI 10.17487/RFC7052, October 2013, 1662 . 1664 [RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo- 1665 Pascual, J., and D. Lewis, "Locator/Identifier Separation 1666 Protocol (LISP) Network Element Deployment 1667 Considerations", RFC 7215, DOI 10.17487/RFC7215, April 1668 2014, . 1670 [RFC7833] Howlett, J., Hartman, S., and A. Perez-Mendez, Ed., "A 1671 RADIUS Attribute, Binding, Profiles, Name Identifier 1672 Format, and Confirmation Methods for the Security 1673 Assertion Markup Language (SAML)", RFC 7833, 1674 DOI 10.17487/RFC7833, May 2016, 1675 . 1677 [RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID 1678 Separation Protocol (LISP) Threat Analysis", RFC 7835, 1679 DOI 10.17487/RFC7835, April 2016, 1680 . 1682 [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 1683 Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, 1684 February 2017, . 1686 [RFC8061] Farinacci, D. and B. Weis, "Locator/ID Separation Protocol 1687 (LISP) Data-Plane Confidentiality", RFC 8061, 1688 DOI 10.17487/RFC8061, February 2017, 1689 . 1691 [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. 1692 Smirnov, "Locator/ID Separation Protocol Delegated 1693 Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, 1694 May 2017, . 1696 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1697 Writing an IANA Considerations Section in RFCs", BCP 26, 1698 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1699 . 1701 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1702 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1703 May 2017, . 1705 [RFC8378] Moreno, V. and D. Farinacci, "Signal-Free Locator/ID 1706 Separation Protocol (LISP) Multicast", RFC 8378, 1707 DOI 10.17487/RFC8378, May 2018, 1708 . 1710 Appendix A. Acknowledgments 1712 An initial thank you goes to Dave Oran for planting the seeds for the 1713 initial ideas for LISP. His consultation continues to provide value 1714 to the LISP authors. 1716 A special and appreciative thank you goes to Noel Chiappa for 1717 providing architectural impetus over the past decades on separation 1718 of location and identity, as well as detailed reviews of the LISP 1719 architecture and documents, coupled with enthusiasm for making LISP a 1720 practical and incremental transition for the Internet. 1722 The authors would like to gratefully acknowledge many people who have 1723 contributed discussions and ideas to the making of this proposal. 1724 They include Scott Brim, Andrew Partan, John Zwiebel, Jason Schiller, 1725 Lixia Zhang, Dorian Kim, Peter Schoenmaker, Vijay Gill, Geoff Huston, 1726 David Conrad, Mark Handley, Ron Bonica, Ted Seely, Mark Townsley, 1727 Chris Morrow, Brian Weis, Dave McGrew, Peter Lothberg, Dave Thaler, 1728 Eliot Lear, Shane Amante, Ved Kafle, Olivier Bonaventure, Luigi 1729 Iannone, Robin Whittle, Brian Carpenter, Joel Halpern, Terry 1730 Manderson, Roger Jorgensen, Ran Atkinson, Stig Venaas, Iljitsch van 1731 Beijnum, Roland Bless, Dana Blair, Bill Lynch, Marc Woolward, Damien 1732 Saucez, Damian Lezama, Attilla De Groot, Parantap Lahiri, David 1733 Black, Roque Gagliano, Isidor Kouvelas, Jesper Skriver, Fred Templin, 1734 Margaret Wasserman, Sam Hartman, Michael Hofling, Pedro Marques, Jari 1735 Arkko, Gregg Schudel, Srinivas Subramanian, Amit Jain, Xu Xiaohu, 1736 Dhirendra Trivedi, Yakov Rekhter, John Scudder, John Drake, Dimitri 1737 Papadimitriou, Ross Callon, Selina Heimlich, Job Snijders, Vina 1738 Ermagan, Fabio Maino, Victor Moreno, Chris White, Clarence Filsfils, 1739 Alia Atlas, Florin Coras and Alberto Rodriguez. 1741 This work originated in the Routing Research Group (RRG) of the IRTF. 1742 An individual submission was converted into the IETF LISP working 1743 group document that became this RFC. 1745 The LISP working group would like to give a special thanks to Jari 1746 Arkko, the Internet Area AD at the time that the set of LISP 1747 documents were being prepared for IESG last call, and for his 1748 meticulous reviews and detailed commentaries on the 7 working group 1749 last call documents progressing toward standards-track RFCs. 1751 Appendix B. Document Change Log 1753 [RFC Editor: Please delete this section on publication as RFC.] 1755 B.1. Changes to draft-ietf-lisp-rfc6830bis-16 1757 o Posted late August 2018. 1759 o Distinguish the message type names between ICMP for IPv4 and ICMP 1760 for IPv6 for handling MTU issues. 1762 B.2. Changes to draft-ietf-lisp-rfc6830bis-15 1764 o Posted August 2018. 1766 o Final editorial changes before RFC submission for Proposed 1767 Standard. 1769 o Added section "Changes since RFC 6830" so implementators are 1770 informed of any changes since the last RFC publication. 1772 B.3. Changes to draft-ietf-lisp-rfc6830bis-14 1774 o Posted July 2018 IETF week. 1776 o Put obsolete of RFC 6830 in Intro section in addition to abstract. 1778 B.4. Changes to draft-ietf-lisp-rfc6830bis-13 1780 o Posted March IETF Week 2018. 1782 o Clarified that a new nonce is required per RLOC. 1784 o Removed 'Clock Sweep' section. This text must be placed in a new 1785 OAM document. 1787 o Some references changed from normative to informative 1789 B.5. Changes to draft-ietf-lisp-rfc6830bis-12 1791 o Posted July 2018. 1793 o Fixed Luigi editorial comments to ready draft for RFC status. 1795 B.6. Changes to draft-ietf-lisp-rfc6830bis-11 1797 o Posted March 2018. 1799 o Removed sections 16, 17 and 18 (Mobility, Deployment and 1800 Traceroute considerations). This text must be placed in a new OAM 1801 document. 1803 B.7. Changes to draft-ietf-lisp-rfc6830bis-10 1805 o Posted March 2018. 1807 o Updated section 'Router Locator Selection' stating that the Data- 1808 Plane MUST follow what's stored in the Map-Cache (priorities and 1809 weights). 1811 o Section 'Routing Locator Reachability': Removed bullet point 2 1812 (ICMP Network/Host Unreachable),3 (hints from BGP),4 (ICMP Port 1813 Unreachable),5 (receive a Map-Reply as a response) and RLOC 1814 probing 1816 o Removed 'Solicit-Map Request'. 1818 B.8. Changes to draft-ietf-lisp-rfc6830bis-09 1820 o Posted January 2018. 1822 o Add more details in section 5.3 about DSCP processing during 1823 encapsulation and decapsulation. 1825 o Added clarity to definitions in the Definition of Terms section 1826 from various commenters. 1828 o Removed PA and PI definitions from Definition of Terms section. 1830 o More editorial changes. 1832 o Removed 4342 from IANA section and move to RFC6833 IANA section. 1834 B.9. Changes to draft-ietf-lisp-rfc6830bis-08 1836 o Posted January 2018. 1838 o Remove references to research work for any protocol mechanisms. 1840 o Document scanned to make sure it is RFC 2119 compliant. 1842 o Made changes to reflect comments from document WG shepherd Luigi 1843 Iannone. 1845 o Ran IDNITs on the document. 1847 B.10. Changes to draft-ietf-lisp-rfc6830bis-07 1849 o Posted November 2017. 1851 o Rephrase how Instance-IDs are used and don't refer to [RFC1918] 1852 addresses. 1854 B.11. Changes to draft-ietf-lisp-rfc6830bis-06 1856 o Posted October 2017. 1858 o Put RTR definition before it is used. 1860 o Rename references that are now working group drafts. 1862 o Remove "EIDs MUST NOT be used as used by a host to refer to other 1863 hosts. Note that EID blocks MAY LISP RLOCs". 1865 o Indicate what address-family can appear in data packets. 1867 o ETRs may, rather than will, be the ones to send Map-Replies. 1869 o Recommend, rather than mandate, max encapsulation headers to 2. 1871 o Reference VPN draft when introducing Instance-ID. 1873 o Indicate that SMRs can be sent when ITR/ETR are in the same node. 1875 o Clarify when private addreses can be used. 1877 B.12. Changes to draft-ietf-lisp-rfc6830bis-05 1879 o Posted August 2017. 1881 o Make it clear that a Reencapsulating Tunnel Router is an RTR. 1883 B.13. Changes to draft-ietf-lisp-rfc6830bis-04 1885 o Posted July 2017. 1887 o Changed reference of IPv6 RFC2460 to RFC8200. 1889 o Indicate that the applicability statement for UDP zero checksums 1890 over IPv6 adheres to RFC6936. 1892 B.14. Changes to draft-ietf-lisp-rfc6830bis-03 1894 o Posted May 2017. 1896 o Move the control-plane related codepoints in the IANA 1897 Considerations section to RFC6833bis. 1899 B.15. Changes to draft-ietf-lisp-rfc6830bis-02 1901 o Posted April 2017. 1903 o Reflect some editorial comments from Damien Sausez. 1905 B.16. Changes to draft-ietf-lisp-rfc6830bis-01 1907 o Posted March 2017. 1909 o Include references to new RFCs published. 1911 o Change references from RFC6833 to RFC6833bis. 1913 o Clarified LCAF text in the IANA section. 1915 o Remove references to "experimental". 1917 B.17. Changes to draft-ietf-lisp-rfc6830bis-00 1919 o Posted December 2016. 1921 o Created working group document from draft-farinacci-lisp 1922 -rfc6830-00 individual submission. No other changes made. 1924 Authors' Addresses 1926 Dino Farinacci 1927 Cisco Systems 1928 Tasman Drive 1929 San Jose, CA 95134 1930 USA 1932 EMail: farinacci@gmail.com 1933 Vince Fuller 1934 Cisco Systems 1935 Tasman Drive 1936 San Jose, CA 95134 1937 USA 1939 EMail: vince.fuller@gmail.com 1941 Dave Meyer 1942 Cisco Systems 1943 170 Tasman Drive 1944 San Jose, CA 1945 USA 1947 EMail: dmm@1-4-5.net 1949 Darrel Lewis 1950 Cisco Systems 1951 170 Tasman Drive 1952 San Jose, CA 1953 USA 1955 EMail: darlewis@cisco.com 1957 Albert Cabellos 1958 UPC/BarcelonaTech 1959 Campus Nord, C. Jordi Girona 1-3 1960 Barcelona, Catalunya 1961 Spain 1963 EMail: acabello@ac.upc.edu