idnits 2.17.1 draft-ietf-lisp-mn-10.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 : ---------------------------------------------------------------------------- == There are 11 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 8, 2021) is 982 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC5226' is defined on line 986, but no explicit reference was found in the text == Outdated reference: A later version (-38) exists of draft-ietf-lisp-rfc6830bis-36 == Outdated reference: A later version (-31) exists of draft-ietf-lisp-rfc6833bis-30 ** Obsolete normative reference: RFC 3344 (Obsoleted by RFC 5944) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 6834 (Obsoleted by RFC 9302) == Outdated reference: A later version (-06) exists of draft-farinacci-lisp-simple-nat-02 Summary: 4 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 lispers.net 4 Intended status: Experimental D. Lewis 5 Expires: February 9, 2022 cisco Systems 6 D. Meyer 7 1-4-5.net 8 C. White 9 Logical Elegance, LLC. 10 August 8, 2021 12 LISP Mobile Node 13 draft-ietf-lisp-mn-10 15 Abstract 17 This document describes how a lightweight version of LISP's ITR/ETR 18 functionality can be used to provide seamless mobility to a mobile 19 node. The LISP Mobile Node design described in this document uses 20 standard LISP functionality to provide scalable mobility for LISP 21 mobile nodes. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on February 9, 2022. 40 Copyright Notice 42 Copyright (c) 2021 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 59 3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 6 60 4. Design Requirements . . . . . . . . . . . . . . . . . . . . . 6 61 4.1. User Requirements . . . . . . . . . . . . . . . . . . . . 6 62 4.2. Network Requirements . . . . . . . . . . . . . . . . . . 7 63 5. LISP Mobile Node Operation . . . . . . . . . . . . . . . . . 7 64 5.1. Addressing Architecture . . . . . . . . . . . . . . . . . 8 65 5.2. Control Plane Operation . . . . . . . . . . . . . . . . . 9 66 5.3. Data Plane Operation . . . . . . . . . . . . . . . . . . 9 67 6. Updating Remote Caches . . . . . . . . . . . . . . . . . . . 10 68 7. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 11 69 7.1. LISP Mobile Node to a Stationary Node in a LISP Site . . 11 70 7.1.1. Handling Unidirectional Traffic . . . . . . . . . . . 11 71 7.2. LISP Mobile Node to a Non-LISP Stationary Node . . . . . 12 72 7.3. LISP Mobile Node to LISP Mobile Node . . . . . . . . . . 12 73 7.3.1. One Mobile Node is Roaming . . . . . . . . . . . . . 13 74 7.4. Non-LISP Site to a LISP Mobile Node . . . . . . . . . . . 13 75 7.5. LISP Site to LISP Mobile Node . . . . . . . . . . . . . . 13 76 8. Multicast and Mobility . . . . . . . . . . . . . . . . . . . 14 77 9. RLOC Considerations . . . . . . . . . . . . . . . . . . . . . 15 78 9.1. Mobile Node's RLOC is an EID . . . . . . . . . . . . . . 15 79 10. LISP Mobile Nodes behind NAT Devices . . . . . . . . . . . . 17 80 11. Mobility Example . . . . . . . . . . . . . . . . . . . . . . 17 81 11.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . 17 82 11.2. Registration . . . . . . . . . . . . . . . . . . . . . . 18 83 12. LISP Implementation in a Mobile Node . . . . . . . . . . . . 18 84 13. Security Considerations . . . . . . . . . . . . . . . . . . . 19 85 13.1. Proxy ETR Hijacking . . . . . . . . . . . . . . . . . . 20 86 13.2. LISP Mobile Node using an EID as its RLOC . . . . . . . 20 87 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 88 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 89 15.1. Normative References . . . . . . . . . . . . . . . . . . 21 90 15.2. Informative References . . . . . . . . . . . . . . . . . 22 91 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 22 92 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 23 93 B.1. Changes to draft-ietf-lisp-mn-10 . . . . . . . . . . . . 23 94 B.2. Changes to draft-ietf-lisp-mn-09 . . . . . . . . . . . . 23 95 B.3. Changes to draft-ietf-lisp-mn-08 . . . . . . . . . . . . 23 96 B.4. Changes to draft-ietf-lisp-mn-07 . . . . . . . . . . . . 23 97 B.5. Changes to draft-ietf-lisp-mn-06 . . . . . . . . . . . . 23 98 B.6. Changes to draft-ietf-lisp-mn-05 . . . . . . . . . . . . 23 99 B.7. Changes to draft-ietf-lisp-mn-04 . . . . . . . . . . . . 23 100 B.8. Changes to draft-ietf-lisp-mn-03 . . . . . . . . . . . . 24 101 B.9. Changes to draft-ietf-lisp-mn-02 . . . . . . . . . . . . 24 102 B.10. Changes to draft-ietf-lisp-mn-01 . . . . . . . . . . . . 24 103 B.11. Changes to draft-ietf-lisp-mn-00 . . . . . . . . . . . . 24 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 106 1. Introduction 108 The Locator/ID Separation Protocol (LISP) [I-D.ietf-lisp-rfc6830bis] 109 specifies a design and mechanism for replacing the addresses 110 currently used in the Internet with two separate name spaces: 111 Endpoint Identifiers (EIDs), used within sites, and Routing Locators 112 (RLOCs), used by the transit networks that make up the Internet 113 infrastructure. To achieve this separation, LISP defines protocol 114 mechanisms for mapping from EIDs to RLOCs. The mapping 115 infrastructure is comprised of LISP Map-Servers and Map-Resolvers 116 [I-D.ietf-lisp-rfc6833bis] and is tied together with LISP+ALT 117 [RFC6836]. 119 This document specifies the behavior of a new LISP network element: 120 the LISP Mobile Node. The LISP Mobile Node implements a subset of 121 the standard Ingress Tunnel Router and Egress Tunnel Router 122 functionality [I-D.ietf-lisp-rfc6830bis]. Design goals for the LISP 123 mobility design include: 125 o Allowing TCP connections to stay alive while roaming. 127 o Allowing the mobile node to communicate with other mobile nodes 128 while either or both are roaming. 130 o Allowing the mobile node to multi-home (i.e., use multiple 131 interfaces concurrently). 133 o Allowing the mobile node to be a server. That is, any mobile node 134 or stationary node can find and connect to a mobile node as a 135 server. 137 o Providing shortest path bidirectional data paths between a mobile 138 node and any other stationary or mobile node. 140 o Not requiring fine-grained routes in the core network to support 141 mobility. 143 o Not requiring a home-agent, foreign agent or other data plane 144 network elements to support mobility. Note since the LISP mobile 145 node design does not require these data plane elements, there is 146 no triangle routing of data packets as is found in Mobile IP 147 [RFC3344]. 149 o Not requiring new IPv6 extension headers to avoid triangle routing 150 [RFC3775]. 152 The LISP Mobile Node design requires the use of the LISP Map-Server 153 [RFC6836] and LISP Interworking [RFC6832] technology to allow a LISP 154 mobile node to roam and to be discovered in an efficient and scalable 155 manner. The use of Map-Server technology is discussed further in 156 Section 5. 158 The protocol mechanisms described in this document apply those cases 159 in which a node's IP address changes frequently. For example, when a 160 mobile node roams, it is typically assigned a new IP address. 161 Similarly, a broadband subscriber may have its address change 162 frequently; as such, a broadband subscriber can use the LISP Mobile 163 Node mechanisms defined in this specification. 165 The remainder of this document is organized as follows: Section 2 166 defines the terms used in this document. Section 3 provides a 167 overview of salient features of the LISP Mobile Node design, and 168 Section 4 describes design requirements for a LISP Mobile Node. 169 Section 5 provides the detail of LISP Mobile Node data and control 170 plane operation, and Section 6 discusses options for updating remote 171 caches in the presence of unidirectional traffic flows. Section 7 172 specifies how the LISP Mobile Node protocol operates. Section 8 173 specifies multicast operation for LISP mobile nodes. Section 9 and 174 Section 12 outline other considerations for the LISP-MN design and 175 implementation. Finally, Section 13 outlines the security 176 considerations for a LISP mobile node. 178 2. Definition of Terms 180 This section defines the terms used in this document. 182 Stationary Node (SN): A non-mobile node who's IP address changes 183 infrequently. That is, its IP address does not change as 184 frequently as a fast roaming mobile hand-set or a broadband 185 connection and therefore the EID to RLOC mapping is relatively 186 static. 188 Endpoint ID (EID): This is the traditional LISP EID 189 [I-D.ietf-lisp-rfc6830bis], and is the address that a LISP mobile 190 node uses as its address for transport connections. A LISP mobile 191 node never changes its EID, which is typically a /32 or /128 192 prefix and is assigned to a loopback interface. Note that the 193 mobile node can have multiple EIDs, and these EIDs can be from 194 different address families. 196 Routing Locator (RLOC): This is the traditional LISP RLOC, and is in 197 general a routable address that can be used to reach a mobile 198 node. Note that there are cases in which an mobile node may 199 receive an address that it thinks is an RLOC (perhaps via DHCP) 200 which is either an EID or an RFC 1918 address [RFC1918]. This 201 could happen if, for example, if the mobile node roams into a LISP 202 domain or a domain behind a Network Address Translator (NAT)) See 203 Section 10 for more details. 205 Ingress Tunnel Router (ITR): An ITR is a router that accepts an IP 206 packet with a single IP header (more precisely, an IP packet that 207 does not contain a LISP header). The router treats this "inner" 208 IP destination address as an EID and performs an EID-to-RLOC 209 mapping lookup. The router then prepends an "outer" IP header 210 with one of its globally routable RLOCs in the source address 211 field and the result of the mapping lookup in the destination 212 address field. Note that this destination RLOC may be an 213 intermediate, proxy device that has better knowledge of the EID- 214 to-RLOC mapping closer to the destination EID. In general, an ITR 215 receives IP packets from site end-systems on one side and sends 216 LISP-encapsulated IP packets toward the Internet on the other 217 side. A LISP mobile node, however, when acting as an ITR LISP 218 encapsulates all packet that it originates. 220 Egress Tunnel Router (ETR): An ETR is a router that accepts an IP 221 packet where the destination address in the "outer" IP header is 222 one of its own RLOCs. The router strips the "outer" header and 223 forwards the packet based on the next IP header found. In 224 general, an ETR receives LISP-encapsulated IP packets from the 225 Internet on one side and sends decapsulated IP packets to site 226 end-systems on the other side. A LISP mobile node, when acting as 227 an ETR, decapsulates packets that are then typically processed by 228 the mobile node. 230 Proxy Ingress Tunnel Router (PITR): PITRs are used to provide 231 interconnectivity between sites that use LISP EIDs and those that 232 do not. They act as a gateway between the Legacy Internet and the 233 LISP enabled Network. A given PITR advertises one or more highly 234 aggregated EID prefixes into the public Internet and acts as the 235 ITR for traffic received from the public Internet. Proxy Ingress 236 Tunnel Routers are described in [RFC6832]. 238 Proxy Egress Tunnel Router (PETR): An infrastructure element used to 239 decapsulate packets sent from mobile nodes to non-LISP sites. 240 Proxy Egress Tunnel Routers are described in [RFC6832]. 242 LISP Mobile Node (LISP-MN): A LISP capable fast roaming mobile hand- 243 set. 245 Map-cache: A data structure which contains an EID-prefix, its 246 associated RLOCs, and the associated policy. Map-caches are 247 typically found in ITRs and PITRs. 249 Negative Map-Reply: A Negative Map-Reply is a Map-Reply that 250 contains a coarsely aggregated non-LISP prefix. Negative Map- 251 Replies are typically generated by Map-Resolvers, and are used to 252 inform an ITR (mobile or stationary) that a site is not a LISP 253 site. A LISP mobile node encapsulate packets to destinations 254 covered by the negative Map-Reply are encapsulated to a PETR. 256 Roaming Event: A Roaming Event occurs when there is a change in a 257 LISP mobile node's RLOC set. 259 3. Design Overview 261 The LISP-MN design described in this document uses the Map-Server/ 262 Map-Resolver service interface in conjunction with a light-weight 263 ITR/ETR implementation in the LISP-MN to provide scalable fast 264 mobility. The LISP-MN control-plane uses a Map-Server as an anchor 265 point, which provides control-plane scalability. In addition, the 266 LISP-MN data-plane takes advantage of shortest path routing and 267 therefore does not increase packet delivery latency. 269 4. Design Requirements 271 This section outlines the design requirements for a LISP-MN, and is 272 divided into User Requirements (Section 4.1) and Network Requirements 273 (Section 4.2). 275 4.1. User Requirements 277 This section describes the user-level functionality provided by a 278 LISP-MN. 280 Transport Connection Survivability: The LISP-MN design must allow a 281 LISP-MN to roam while keeping transport connections alive. 283 Simultaneous Roaming: The LISP-MN design must allow a LISP-MN to 284 talk to another LISP-MN while both are roaming. 286 Multihoming: The LISP-MN design must allow for simultaneous use of 287 multiple Internet connections by a LISP-MN. In addition, the 288 design must allow for the LISP mobile node to specify ingress 289 traffic engineering policies as documented in 291 [I-D.ietf-lisp-rfc6830bis]. That is, the LISP-MN must be able to 292 specify both active/active and active/passive policies for ingress 293 traffic. 295 Shortest Path Data Plane: The LISP-MN design must allow for shortest 296 path bidirectional traffic between a LISP-MN and a stationary 297 node, and between a LISP-MN and another LISP-MN (i.e., without 298 triangle routing in the data path). This provides a low-latency 299 data path between the LISP-MN and the nodes that it is 300 communicating with. 302 4.2. Network Requirements 304 This section describes the network functionality that the LISP-MN 305 design provides to a LISP-MN. 307 Routing System Scalability: The LISP-MN design must not require 308 injection of fine-grained routes into the core network. 310 Mapping System Scalability: The LISP-MN design must not require 311 additional state in the mapping system. In particular, any 312 mapping state required to support LISP mobility must BE confined 313 to the LISP-MN's Map-Server and the ITRs which are talking to the 314 LISP-MN. 316 Component Reuse: The LISP-MN design must use existing LISP 317 infrastructure components. These include map server, map 318 resolver, and interworking infrastructure components. 320 Home Agent/Foreign Agent: The LISP-MN design must not require the 321 use of home-agent or foreign-agent infrastructure components 322 [RFC3344]. 324 Readdressing: The LISP-MN design must not require TCP connections to 325 be reset when the mobile node roams. In particular, since the IP 326 address associated with a transport connection will not change as 327 the mobile node roams, TCP connections will not reset. 329 5. LISP Mobile Node Operation 331 The LISP-MN design is built from three existing LISP components: A 332 lightweight LISP implementation that runs in an LISP-MN, and the 333 existing Map-Server [I-D.ietf-lisp-rfc6833bis] and Interworking 334 [RFC6832] infrastructures. A LISP mobile node typically sends and 335 receives LISP encapsulated packets (exceptions include management 336 protocols such as DHCP). 338 The LISP-MN design makes a single mobile node look like a LISP site 339 as described in in [I-D.ietf-lisp-rfc6830bis] by implementing ITR and 340 ETR functionality. Note that one subtle difference between standard 341 ITR behavior and LISP-MN is that the LISP-MN encapsulates all non- 342 local, non-LISP site destined outgoing packets to a PETR. 344 When a LISP-MN roams onto a new network, it receives a new RLOC. 345 Since the LISP-MN is the authoritative ETR for its EID-prefix, it 346 must Map-Register it's updated RLOC set. New sessions can be 347 established as soon as the registration process completes. Sessions 348 that are encapsulating to RLOCs that did not change during the 349 roaming event are not affected by the roaming event (or subsequent 350 mapping update). However, the LISP-MN must update the ITRs and PITRs 351 that have cached a previous mapping. It does this using the 352 techniques described in Section 6. 354 5.1. Addressing Architecture 356 A LISP-MN is typically provisioned with one or more EIDs that it uses 357 for all transport connections. LISP-MN EIDs are provisioned from 358 blocks reserved from mobile nodes much the way mobile phone numbers 359 are provisioned today (such that they do not overlap with the EID 360 space of any enterprise). These EIDs can be either IPv4 or IPv6 361 addresses. For example, one EID might be for a public network while 362 another might be for a private network; in this case the "public" EID 363 will be associated with RLOCs from the public Internet, while the 364 "private" EID will be associated with private RLOCs. It is 365 anticipated that these EIDs will change infrequently if at all, since 366 the assignment of a LISP-MN's EID is envisioned to be a subscription 367 time event. The key point here is that the relatively fixed EID 368 allows the LISP-MN's transport connections to survive roaming events. 369 In particular, while the LISP-MN's EIDs are fixed during roaming 370 events, the LISP-MN's RLOC set will change. The RLOC set may be 371 comprised of both IPv4 or IPv6 addresses. 373 A LISP-MN is also provisioned with the address of a Map-Server and a 374 corresponding authentication key. Like the LISP-MN's EID, both the 375 Map-Server address and authentication key change very infrequently 376 (again, these are anticipated to be subscription time parameters). 377 Since the LISP LISP-MN's Map-Server is configured to advertise an 378 aggregated EID-prefix that covers the LISP-MN's EID, changes to the 379 LISP-MN's mapping are not propagated further into the mapping system 380 [RFC6836]. It is this property that provides for scalable fast 381 mobility. 383 A LISP-MN is also be provisioned with the address of a Map-Resolver. 384 A LISP-MN may also learn the address of a Map-Resolver though a 385 dynamic protocol such as DHCP [RFC2131]. 387 Finally, note that if, for some reason, a LISP-MN's EID is re- 388 provisioned, the LISP-MN's Map-Server address may also have to change 389 in order to keep LISP-MN's EID within the aggregate advertised by the 390 Map-Server (this is discussed in greater detail in Section 5.2). 392 5.2. Control Plane Operation 394 A roaming event occurs when the LISP-MN receives a new RLOC. Because 395 the new address is a new RLOC from the LISP-MN's perspective, it must 396 update its EID-to-RLOC mapping with its Map-Server; it does this 397 using the Map-Register mechanism described in 398 [I-D.ietf-lisp-rfc6830bis]. 400 A LISP-MN may want the Map-Server to respond on its behalf for a 401 variety of reasons, including minimizing control traffic on radio 402 links and minimizing battery utilization. A LISP-MN may instruct its 403 Map-Server to proxy respond to Map-Requests by setting the Proxy-Map- 404 Reply bit in the Map-Register message [I-D.ietf-lisp-rfc6830bis]. In 405 this case the Map-Server responds with a non-authoritative Map-Reply 406 so that an ITR or PITR will know that the ETR didn't directly 407 respond. A Map-Server will proxy reply only for "registered" EID- 408 prefixes using the registered EID-prefix mask-length in proxy 409 replies. 411 Because the LISP-MN's Map-Server is pre-configured to advertise an 412 aggregate covering the LISP-MN's EID prefix, the database mapping 413 change associated with the roaming event is confined to the Map- 414 Server and those ITRs and PITRs that may have cached the previous 415 mapping. 417 5.3. Data Plane Operation 419 A key feature of LISP-MN control-plane design is the use of the Map- 420 Server as an anchor point; this allows control of the scope to which 421 changes to the mapping system must be propagated during roaming 422 events. 424 On the other hand, the LISP-MN data-plane design does not rely on 425 additional LISP infrastructure for communication between LISP nodes 426 (mobile or stationary). Data packets take the shortest path to and 427 from the LISP-MN to other LISP nodes; as noted above, low latency 428 shortest paths in the data-plane is an important goal for the LISP-MN 429 design (and is important for delay-sensitive applications like gaming 430 and voice-over-IP). Note that a LISP-MN will need additional 431 interworking infrastructure when talking to non-LISP sites [RFC6832]; 432 this is consistent with the design of any host at a LISP site which 433 talks to a host at a non-LISP site. 435 In general, the LISP-MN data-plane operates in the same manner as the 436 standard LISP data-plane with one exception: packets generated by a 437 LISP-MN which are not destined for the mapping system (i.e., those 438 sent to destination UDP port 4342) or the local network are LISP 439 encapsulated. Because data packets are always encapsulated to a 440 RLOC, packets travel on the shortest path from LISP-MN to another 441 LISP stationary or LISP-MN. When the LISP mobile node is sending 442 packets to a stationary or LISP-MN in a non-LISP site, it sends LISP- 443 encapsulated packets to a PETR which then decapsulates the packet and 444 forwards it to its destination. 446 6. Updating Remote Caches 448 A LISP-MN has five mechanisms it can use to cause the mappings cached 449 in remote ITRs and PITRs to be refreshed: 451 Map Versioning: If Map Versioning [RFC6834] is used, an ETR can 452 detect if an ITR is using the most recent database mapping. In 453 particular, when mobile node's ETR decapsulates a packet and 454 detects the Destination Map-Version Number is less than the 455 current version for its mapping, in invokes the SMR procedure 456 described in [I-D.ietf-lisp-rfc6830bis]. In general, SMRs are 457 used to fix the out of sync mapping while Map-Versioning is used 458 to detect they are out of sync. [RFC6834] provides additional 459 details of the Map Versioning process. 461 Data Driven SMRs: An ETR may elect to send SMRs to those sites it 462 has been receiving encapsulated packets from. This will occur 463 when an ITR is sending to an old RLOC (for which there is one-to- 464 one mapping between EID-to-RLOC) and the ETR may not have had a 465 chance to send an SMR the ITR. 467 Setting Small TTL on Map Replies: The ETR (or Map Server) may set a 468 small Time to Live (TTL) on its mappings when responding to Map 469 Requests. The TTL value should be chosen such that changes in 470 mappings can be detected while minimizing control traffic. In 471 this case the ITR is a SN and the ETR is the MN. 473 Piggybacking Mapping Data: If an ITR and ETR are co-located, an ITR 474 may elect to send Map-Requests with piggybacked mapping data to 475 those sites in its map cache or to which it has recently 476 encapsulated data in order to inform the remote ITRs and PITRs of 477 the change. 479 Temporary PITR Caching: The ETR can keep a cache of PITRs that have 480 sent Map-Requests to it. The cache contains the RLOCs of the 481 PITRs so later when the locator-set of a LISP-MN changes, SMR 482 messages can be sent to all RLOCs in the PITR cache. This is an 483 example of a control-plane driven SMR procedure. 485 7. Protocol Operation 487 There are five distinct connectivity cases considered by the LISP-MN 488 design. The five mobility cases are: 490 LISP Mobile Node to a Stationary Node in a LISP Site. 492 LISP Mobile Node to a Non-LISP Site. 494 LISP Mobile Node to a LISP Mobile Node. 496 Non-LISP Site to a LISP Mobile Node. 498 LISP Site to a LISP Mobile Node. 500 The remainder of this section covers these cases in detail. 502 7.1. LISP Mobile Node to a Stationary Node in a LISP Site 504 After a roaming event, a LISP-MN must immediately register its new 505 EID-to-RLOC mapping with its configured Map-Server(s). This allows 506 LISP sites sending Map-Requests to the LISP-MN to receive the current 507 mapping. In addition, remote ITRs and PITRs may have cached mappings 508 that are no longer valid. These ITRs and PITRs must be informed that 509 the mapping has changed. See Section 6 for a discussion of methods 510 for updating remote caches. 512 7.1.1. Handling Unidirectional Traffic 514 A problem may arise when traffic is flowing unidirectionally between 515 LISP sites. This can arise in communication flows between PITRs and 516 LISP sites or when a site's ITRs and ETRs are not co-located. In 517 these cases, data-plane techniques such as Map-Versioning and Data- 518 Driven SMRs can't be used to update the remote caches. 520 For example, consider the unidirectional packet flow case depicted in 521 Figure 1. In this case X is a non-LISP enabled SN (i.e., connected 522 to the Internet) and Y is a LISP MN. Data traffic from X to Y will 523 flow through a PITR. When Y changes its mapping (for example, during 524 a mobility event), the PITR must update its mapping for Y. However, 525 since data traffic from Y to X is unidirectional and does not flow 526 though the PITR, it can not rely data traffic from Y to X to signal a 527 mapping change at Y. In this case, the Y must use one or more of the 528 techniques described in Section 6 to update the PITR's cache. Note 529 that if Y has only one RLOC, then the PITR has to know when to send a 530 Map-Request based on its existing state; thus it can only rely on the 531 TTL on the existing mapping. 533 +-------------------------------------------+ 534 | | 535 | | DP 536 v DP DP MQ | 537 X -----> Internet -----> PITR ------------> Y 538 ^ LEDP | 539 | | 540 +-----------------+ 541 MR 543 DP: Data Packet 544 LEDP: LISP Encapsulated Data Packet 545 MQ: Map Request 546 MR: Map Reply 548 Figure 1: Unidirectional Packet Flow 550 7.2. LISP Mobile Node to a Non-LISP Stationary Node 552 LISP-MNs use the LISP Interworking infrastructure (specifically a 553 PETR) to reach non-LISP sites. In general, the PETR will be co- 554 located with the LISP-MN's Map-Server. This ensures that the LISP 555 packets being decapsulated are from sources that have Map-Registered 556 to the Map-Server. Note that when a LISP-MN roams it continues to 557 uses its configured PETR and Map-Server which can have the effect of 558 adding stretch to packets sent from a LISP-MN to a non-LISP 559 destination. 561 7.3. LISP Mobile Node to LISP Mobile Node 563 LISP-MN to LISP-MN communication is an instance of LISP-to-LISP 564 communication with three sub-cases: 566 o Both LISP-MNs are stationary (Section 7.1). 568 o Only one LISP-MN is roaming (Section 7.3.1). 570 o Both LISP-MNs are roaming. The case is analogous to the case 571 described in Section 7.3.1. 573 7.3.1. One Mobile Node is Roaming 575 In this case, the roaming LISP-MN can find the stationary LISP-MN by 576 sending Map-Request for its EID-prefix. After receiving a Map-Reply, 577 the roaming LISP-MN can encapsulate data packets directly to the non- 578 roaming LISP-MN node. 580 The roaming LISP-MN, on the other hand, must update its Map-Server 581 with the new mapping data as described in Section 7.1. It should 582 also use the cache management techniques described in Section 6 to 583 provide for timely updates of remote caches. Once the roaming LISP- 584 MN has updated its Map-Server, the non-roaming LISP-MN can retrieve 585 the new mapping data (if it hasn't already received an updated 586 mapping via one of the mechanisms described in Section 6) and the 587 stationary LISP-MN can encapsulate data directly to the roaming LISP- 588 MN. 590 7.4. Non-LISP Site to a LISP Mobile Node 592 When a stationary ITR is talking to a non-LISP site, it may forward 593 packets natively (unencapsulated) to the non-LISP site. This will 594 occur when the ITR has received a negative Map Reply for a prefix 595 covering the non-LISP site's address with the Natively-Forward action 596 bit set [I-D.ietf-lisp-rfc6830bis]. As a result, packets may be 597 natively forwarded to non-LISP sites by an ITR (the return path will 598 through a PITR, however, since the packet flow will be non-LISP site 599 to LISP site). 601 A LISP-MN behaves differently when talking to non-LISP sites. In 602 particular, the LISP-MN always encapsulates packets to a PETR. The 603 PETR then decapsulates the packet and forwards it natively to its 604 destination. As in the stationary case, packets from the non-LISP 605 site host return to the LISP-MN through a PITR. Since traffic 606 forwarded through a PITR is unidirectional, a LISP-MN should use the 607 cache management techniques described in Section 7.1.1. 609 7.5. LISP Site to LISP Mobile Node 611 When a LISP-MN roams onto a new network, it needs to update the 612 caches in any ITRs that might have stale mappings. This is analogous 613 to the case in that a stationary LISP site is renumbered; in that 614 case ITRs that have cached the old mapping must be updated. This is 615 done using the techniques described in Section 6. 617 When a LISP router in a stationary site is performing both ITR and 618 ETR functions, a LISP-MN can update the stationary site's map-caches 619 using techniques described in Section 6. However, when the LISP 620 router in the stationary site is performing is only ITR 621 functionality, these techniques can not be used because the ITR is 622 not receiving data traffic from the LISP-MN. In this case, the LISP- 623 MN should use the technique described in Section 7.1.1. In 624 particular, a LISP-MN should set the TTL on the mappings in its Map- 625 Replies to be in 1-2 minute range. 627 8. Multicast and Mobility 629 Since a LISP-MN performs both ITR and ETR functionality, it should 630 also perform a lightweight version of multicast ITR/ETR functionality 631 described in [RFC6831]. When a LISP-MN originates a multicast 632 packet, it will encapsulate the packet with a multicast header, where 633 the source address in the outer header is one of it's RLOC addresses 634 and the destination address in the outer header is the group address 635 from the inner header. The interfaces in which the encapsulated 636 packet is sent on is discussed below. 638 To not require PIM functionality in the LISP-MN as documented in 639 [RFC6831], the LISP-MN resorts to using encapsulated IGMP for joining 640 groups and for determining which interfaces are used for packet 641 origination. When a LISP-MN joins a group, it obtains the map-cache 642 entry for the (S-EID,G) it is joining. It then builds a IGMP report 643 encoding (S-EID,G) and then LISP encapsulates it with UDP port 4341. 644 It selects an RLOC from the map-cache entry to send the encapsulated 645 IGMP Report. 647 When other LISP-MNs are joining an (S-EID,G) entry where the S-EID is 648 for a LISP-MN, the encapsulated IGMP Report will be received by the 649 LISP-MN multicast source. The LISP-MN multicast source will remember 650 the interfaces the encapsulated IGMP Report is received on and build 651 an outgoing interface list for it's own (S-EID,G) entry. If the list 652 is greater than one, then the LISP-MN is doing replication on the 653 source-based tree for which it is the root. 655 When other LISP routers are joining (S-EID,G), they are instructed to 656 send PIM encapsulated Join-Prune messages. However, to keep the 657 LISP-MN as simple as possible, the LISP-MN will not be able to 658 process encapsulated PIM Join-Prune messages. Because the map-cache 659 entry will have a MN-bit indicating the entry is for a LISP-MN, the 660 LISP router will send IGMP encapsulated IGMP Reports instead. 662 When the LISP-MN is sending a multicast packet, it can operate in two 663 modes, multicast-origination-mode or unicast-origination-mode. When 664 in multicast-origination-mode, the LISP-MN multicast-source can 665 encapsulate a multicast packet in another multicast packet, as 666 described above. When in unicast-origination-mode, the LISP-MN 667 multicast source encapsulates the multicast packet into a unicast 668 packet and sends a packet to each encapsulated IGMP Report sender. 670 These modes are provided depending on whether or not the mobile 671 node's network it is currently connected can support IP multicast. 673 9. RLOC Considerations 675 This section documents cases where the expected operation of the 676 LISP-MN design may require special treatment. 678 9.1. Mobile Node's RLOC is an EID 680 When a LISP-MN roams into a LISP site, the "RLOC" it is assigned may 681 be an address taken from the site's EID-prefix. In this case, the 682 LISP-MN will Map-Register a mapping from its statically assigned EID 683 to the "RLOC" it received from the site. This scenario creates 684 another level of indirection: the mapping from the LISP-MN's EID to a 685 site assigned EID. The mapping from the LISP-MN's EID to the site 686 assigned EID allow the LISP-MN to be reached by sending packets using 687 the mapping for the EID; packets are delivered to site's EIDs use the 688 same LISP infrastructure that all LISP hosts use to reach the site. 690 A packet egressing a LISP site destined for a LISP-MN that resides in 691 a LISP site will have three headers: an inner header that is built by 692 the host and is used by transport connections, a middle header that 693 is built by the site's ITR and is used by the destination's ETR to 694 find the current topological location of the LISP-MN, and an outer 695 header (also built by the site's ITR) that is used to forward packets 696 between the sites. 698 Consider a site A with EID-prefix 1.0.0.0/8 and RLOC A and a site B 699 with EID-prefix 2.0.0.0/8 and RLOC B. Suppose that a host S in site 700 A with EID 1.0.0.1 wants to talk to a LISP LISP-MN MN that has 701 registered a mapping from EID 240.0.0.1 to "RLOC" 2.0.0.2 (where 702 2.0.0.2 allocated from site B's EID prefix, 2.0.0.0/8 in this case). 703 This situation is depicted in Figure 2. 705 EID-prefix 1.0.0.0/8 EID-prefix 2.0.0.0/8 706 S has EID 1.0.0.1 MN has EID 240.0.0.1 707 MN has RLOC 2.0.0.2 708 -------------- -------------- 709 / \ --------------- / \ 710 | ITR-A' | / \ | ETR-B' | 711 | | | | | | 712 | S | | Internet | | MN | 713 | \ | | | | ^ | 714 | \ | | | | / | 715 | --> ITR-A | \ / | ETR-B ---- | 716 \ / --------------- \ / 717 -------------- -------------- 718 | | | ^ ^ ^ 719 | | | | | | 720 | | | outer-header: A -> B | | | 721 | | +---------------------------------------+ | | 722 | | RLOCs used to find which site MN resides | | 723 | | | | 724 | | | | 725 | | middle-header: A -> 2.0.0.2 | | 726 | +------------------------------------------------+ | 727 | RLOCs used to find topological location of MN | 728 | | 729 | | 730 | inner-header: 1.0.0.1 -> 240.0.0.1 | 731 +-----------------------------------------------------------+ 732 EIDs used for TCP connection 734 Figure 2: Mobile Node Roaming into a LISP Site 736 In this case, the inner header is used for transport connections, the 737 middle header is used to find topological location of the LISP-MN 738 (the LISP-MN Map-Registers the mapping 240.0.0.1 -> 2.0.0.2 when it 739 roams into site B), and the outer header is used to move packets 740 between sites (A and B in Figure 2). 742 In summary, when a LISP-MN roams into a LISP site and receives a new 743 address (e.g., via DHCP) that is part of the site's EID space, the 744 following sequence occurs: 746 1. The LISP-MN in the LISP site (call it Inside) registers its new 747 RLOC (which is actually part of the sites EID prefix) to its map- 748 server. Call its permanent EID E and the EID it DHCPs D. So it 749 registers a mapping that looks like E->D. 751 2. The MN which is outside (call it Outside) sends a map request for 752 inside's EID (E) and receives D (plus its policy). Outside 753 realizes that D is an EID and sends a map request for D. This 754 will return the site's RLOCs (by its ETR). Call this R. 756 3. Outside then double encapsulates the outbound packet with the 757 inner destination being D and the outer destination being R. 759 4. The packet then finds its way to R, which strips the outer header 760 and the packet is routed to D in the domain to Inside. Inside 761 decapsulates the packet to serve the inner header to the 762 application. 764 Note that both D and R could be returned to Inside in one query, so 765 as not to incur the additional RTT. 767 10. LISP Mobile Nodes behind NAT Devices 769 When a LISP-MN resides behind a NAT device, it will be allocated a 770 private RLOC address. The private RLOC address is used as the source 771 address in the outer header for LISP encapsulated packets. The NAT 772 device will translate the source address and source UDP port in the 773 LISP encapsulated packet. The NAT device will keep this translated 774 state so when packets arrive from the public side of the NAT, they 775 can be translated back to the stored state. For remote LISP ITRs, 776 PITRs, and RTRs, will need to know the translated RLOC address and 777 port so they can encapsulate to the LISP-MN traversing the NAT 778 device. 780 Procedures a LISP-MN should follow when it resides behind a NAT, will 781 follow the LISP xTRs procedures in specification 782 [I-D.ermagan-lisp-nat-traversal]. There are LISP-MN implementations 783 that follow procedures in [I-D.farinacci-lisp-simple-nat]. 785 11. Mobility Example 787 This section provides an example of how the LISP-MN is integrated 788 into the base LISP Design [I-D.ietf-lisp-rfc6830bis]. 790 11.1. Provisioning 792 The LISP-MN needs to be configured with the following information: 794 An EID, assigned to its loopback address 796 A key for map-registration 797 An IP address of a Map-Resolver (this could be learned 798 dynamically) 800 An IP address of its Map-Server and Proxy ETR 802 11.2. Registration 804 After a LISP roams to a new network, it must immediately register its 805 new mapping this new RLOC (and associated priority/weight data) with 806 its Map-Server. 808 The LISP-MN may chose to set the 'proxy' bit in the map-register to 809 indicate that it desires its Map-Server to answer map-requests on its 810 behalf. 812 12. LISP Implementation in a Mobile Node 814 This section will describe a possible approach for developing a 815 lightweight LISP-MN implementation. A LISP-MN will implement a LISP 816 sub-layer inside of the IP layer of the protocol stack. The sub- 817 layer resides between the IP layer and the link-layer. 819 For outgoing unicast packets, once the header that contains EIDs is 820 built and right before an outgoing interface is chosen, a LISP header 821 is prepended to the outgoing packet. The source address is set to 822 the local RLOC address (obtained by DHCP perhaps) and the destination 823 address is set to the RLOC associated with the destination EID from 824 the IP layer. To obtain the RLOC for the EID, the LISP-MN maintains 825 a map-cache for destination sites or destination LISP-MNs to which it 826 is currently talking. The map-cache lookup is performed by doing a 827 longest match lookup on the destination address the IP layer put in 828 the first IP header. Once the new header is prepended, a route table 829 lookup is performed to find the interface in which to send the packet 830 or the default router interface is used to send the packet. 832 When the map-cache does not exist for a destination, the mobile node 833 may queue or drop the packet while it sends a Map-Request to it's 834 configured Map-Resolver. Once a Map-Reply is returned, the map-cache 835 entry stores the EID-to-RLOC state. If the RLOC state is empty in 836 the Map-Reply, the Map-Reply is known as a Negative Map-Reply in 837 which case the map-cache entry is created with a single RLOC, the 838 RLOC of the configured Map-Server for the LISP-MN. The Map-Server 839 that serves the LISP-MN also acts as a Proxy ETR (PETR) so packets 840 can get delivered to hosts in non-LISP sites to which the LISP-MN is 841 sending. 843 For incoming unicast packets, the LISP sub-layer simply decapsulates 844 the packets and delivers to the IP layer. The loc-reach-bits can be 845 processed by the LISP sub-layer. Specifically, the source EID from 846 the packet is looked up in the map-cache and if the loc-reach-bits 847 settings have changed, store the loc-reach-bits from the packet and 848 note which RLOCs for the map-cache entry should not be used. 850 In terms of the LISP-MN detecting which RLOCs from each stored map- 851 cache entry is reachable, it can use any of the Locator Reachability 852 Algorithms from [I-D.ietf-lisp-rfc6830bis]. 854 A background task that runs off a timer should be run so the LISP-MN 855 can send periodic Map-Register messages to the Map-Server. The Map- 856 Register message should also be triggered when the LISP-MN detects a 857 change in IP address for a given interface. The LISP-MN should send 858 Map-Registers to the same Map-Register out each of it's operational 859 links. This will provide for robustness on radio links with which 860 the mobile node is associated. 862 A LISP-MN receives a Map-Request when it has Map-Registered to a Map- 863 Server with the Proxy-bit set to 0. This means that the LISP-MN 864 wishes to send authoritative Map-Replies for Map-Requests that are 865 targeted at the LISP-MN. If the Proxy-bit is set when the LISP-MN 866 registers, then the Map-Server will send non-authoritative Map- 867 Replies on behalf of the LISP-MN. In this case, the Map-Server never 868 encapsulates Map-Requests to the LISP-MN. The LISP-MN can save 869 resources by not receiving Map-Requests (note that the LISP-MN will 870 receive SMRs which have the same format as Map-Requests). 872 To summarize, a LISP sub-layer should implement: 874 o Encapsulating and decapsulating data packets. 876 o Sending and receiving of Map-Request control messages. 878 o Receiving and optionally sending Map-Replies. 880 o Sending Map-Register messages periodically. 882 The key point about the LISP sub-layer is that no other components in 883 the protocol stack need changing; just the insertion of this sub- 884 layer between the IP layer and the interface layer-2 encapsulation/ 885 decapsulation layer. 887 13. Security Considerations 889 Security for the LISP-MN design builds upon the security fundamentals 890 found in LISP [I-D.ietf-lisp-rfc6830bis] for data-plane security and 891 the LISP Map Server [I-D.ietf-lisp-rfc6833bis] registration security. 892 Security issues unique to the LISP-MN design are considered below. 894 13.1. Proxy ETR Hijacking 896 The Proxy ETR (or PETR) that a LISP-MN uses as its destination for 897 non-LISP traffic must use the security association used by the 898 registration process outlined in Section 5.2 and explained in detail 899 in the LISP-MS specification [I-D.ietf-lisp-rfc6833bis]. These 900 measures prevent third party injection of LISP encapsulated traffic 901 into a Proxy ETR. Importantly, a PETR must not decapsulate packets 902 from non-registered RLOCs. 904 13.2. LISP Mobile Node using an EID as its RLOC 906 For LISP packets to be sent to a LISP-MN which has an EID assigned to 907 it as an RLOC as described in Section 9.1), the LISP site must allow 908 for incoming and outgoing LISP data packets. Firewalls and stateless 909 packet filtering mechanisms must be configured to allow UDP port 4341 910 and UDP port 4342 packets. 912 14. IANA Considerations 914 This document is requesting bit allocations in the Map-Request and 915 Map-Register messages. The registry is introduced in 916 [I-D.ietf-lisp-rfc6833bis] and named "LISP Bit Flags". This document 917 is adding bits to the sub-registry "Map-Request Header Bits' and 918 "Map-Register Header Bits". A LISP mobile-node will set the m-bit to 919 1 when it sends Map-Request and Map-Register messages. 921 Sub-Registry: Map-Request Header Bits: 923 0 1 2 3 924 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 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 |Type=1 |A|M|P|S|p|s|m|R| Rsvd |L|D| IRC | Record Count | 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 929 +-----------+---------------+--------------+-----------------+ 930 | Spec Name | IANA Name | Bit Position | Description | 931 +-----------+---------------+--------------+-----------------+ 932 | m | map-request-m | 10 | Mobile Node Bit | 933 +-----------+---------------+--------------+-----------------+ 935 LISP Map-Request Header Bits 937 Sub-Registry: Map-Register Header Bits: 939 0 1 2 3 940 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 |Type=3 |P|S|R| Reserved |E|T|a|m|M| Record Count | 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 945 +-----------+----------------+--------------+----------------------+ 946 | Spec Name | IANA Name | Bit Position | Description | 947 +-----------+----------------+--------------+----------------------+ 948 | m | map-register-m | 22 | LISP Mobile Node Bit | 949 +-----------+----------------+--------------+----------------------+ 951 LISP Map-Register Header Bits 953 15. References 955 15.1. Normative References 957 [I-D.ietf-lisp-rfc6830bis] 958 Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. 959 Cabellos, "The Locator/ID Separation Protocol (LISP)", 960 draft-ietf-lisp-rfc6830bis-36 (work in progress), November 961 2020. 963 [I-D.ietf-lisp-rfc6833bis] 964 Farinacci, D., Maino, F., Fuller, V., and A. Cabellos, 965 "Locator/ID Separation Protocol (LISP) Control-Plane", 966 draft-ietf-lisp-rfc6833bis-30 (work in progress), November 967 2020. 969 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 970 and E. Lear, "Address Allocation for Private Internets", 971 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 972 . 974 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 975 RFC 2131, DOI 10.17487/RFC2131, March 1997, 976 . 978 [RFC3344] Perkins, C., Ed., "IP Mobility Support for IPv4", 979 RFC 3344, DOI 10.17487/RFC3344, August 2002, 980 . 982 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 983 in IPv6", RFC 3775, DOI 10.17487/RFC3775, June 2004, 984 . 986 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 987 IANA Considerations Section in RFCs", RFC 5226, 988 DOI 10.17487/RFC5226, May 2008, 989 . 991 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 992 Locator/ID Separation Protocol (LISP) for Multicast 993 Environments", RFC 6831, DOI 10.17487/RFC6831, January 994 2013, . 996 [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 997 "Interworking between Locator/ID Separation Protocol 998 (LISP) and Non-LISP Sites", RFC 6832, 999 DOI 10.17487/RFC6832, January 2013, 1000 . 1002 [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID 1003 Separation Protocol (LISP) Map-Versioning", RFC 6834, 1004 DOI 10.17487/RFC6834, January 2013, 1005 . 1007 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, 1008 "Locator/ID Separation Protocol Alternative Logical 1009 Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, 1010 January 2013, . 1012 15.2. Informative References 1014 [I-D.ermagan-lisp-nat-traversal] 1015 Ermagan, V., Farinacci, D., Lewis, D., Maino, F., Comeras, 1016 M. P., Skriver, J., White, C., Lopez, A., and A. Cabellos, 1017 "NAT traversal for LISP", draft-ermagan-lisp-nat- 1018 traversal-19 (work in progress), May 2021. 1020 [I-D.farinacci-lisp-simple-nat] 1021 Farinacci, D., "A Simple LISP NAT-Traversal 1022 Implementation", draft-farinacci-lisp-simple-nat-02 (work 1023 in progress), May 2021. 1025 Appendix A. Acknowledgments 1027 Albert Cabellos, Noel Chiappa, Pierre Francois, Michael Menth, Andrew 1028 Partan, Chris White and John Zwiebel provided insightful comments on 1029 the mobile node concept and on this document. A special thanks goes 1030 to Mary Nickum for her attention to detail and effort in editing 1031 early versions of this document. 1033 Appendix B. Document Change Log 1035 B.1. Changes to draft-ietf-lisp-mn-10 1037 o Posted August 2021. 1039 o Update references and document timer. 1041 B.2. Changes to draft-ietf-lisp-mn-09 1043 o Posted February 2021. 1045 o Update references and document timer. 1047 B.3. Changes to draft-ietf-lisp-mn-08 1049 o Posted August 2020. 1051 o Update references and document timer. 1053 B.4. Changes to draft-ietf-lisp-mn-07 1055 o Posted March 2020. 1057 o Update references and document timer. 1059 B.5. Changes to draft-ietf-lisp-mn-06 1061 o Posted September 2019. 1063 o Update references and document timer. 1065 B.6. Changes to draft-ietf-lisp-mn-05 1067 o Posted March IETF week 2019. 1069 o Update references and document timer. 1071 B.7. Changes to draft-ietf-lisp-mn-04 1073 o Posted October 2018. 1075 o Make IANA Considerations section formatted like 1076 [I-D.ietf-lisp-rfc6833bis]. 1078 o Change all references for RFC6830 to [I-D.ietf-lisp-rfc6830bis] 1079 and for RFC6833 to [I-D.ietf-lisp-rfc6833bis]. 1081 B.8. Changes to draft-ietf-lisp-mn-03 1083 o Posted October 2018. 1085 o Request m-bit allocation in Map-Register message in IANA 1086 Considerations section. 1088 B.9. Changes to draft-ietf-lisp-mn-02 1090 o Posted April 2018. 1092 o Update document timer and references. 1094 B.10. Changes to draft-ietf-lisp-mn-01 1096 o Posted October 2017. 1098 o Update document timer and references. 1100 B.11. Changes to draft-ietf-lisp-mn-00 1102 o Posted April 2017. 1104 o Changed draft-meyer-lisp-mn-16 to working group document. 1106 Authors' Addresses 1108 Dino Farinacci 1109 lispers.net 1110 San Jose, CA 95134 1111 USA 1113 Email: farinacci@gmail.com 1115 Darrel Lewis 1116 cisco Systems 1117 Tasman Drive 1118 San Jose, CA 95134 1119 USA 1121 Email: darlewis@cisco.com 1122 David Meyer 1123 1-4-5.net 1124 USA 1126 Email: dmm@1-4-5.net 1128 Chris White 1129 Logical Elegance, LLC. 1130 San Jose, CA 95134 1131 USA 1133 Email: chris@logicalelegance.com