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