idnits 2.17.1 draft-ietf-lisp-mn-03.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 (October 2, 2018) is 2032 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC5226' is defined on line 950, but no explicit reference was found in the text ** 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 6830 (Obsoleted by RFC 9300, RFC 9301) ** Obsolete normative reference: RFC 6833 (Obsoleted by RFC 9301) ** Obsolete normative reference: RFC 6834 (Obsoleted by RFC 9302) == Outdated reference: A later version (-19) exists of draft-ermagan-lisp-nat-traversal-15 Summary: 6 errors (**), 0 flaws (~~), 4 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: April 5, 2019 cisco Systems 6 D. Meyer 7 1-4-5.net 8 C. White 9 Logical Elegance, LLC. 10 October 2, 2018 12 LISP Mobile Node 13 draft-ietf-lisp-mn-03 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 April 5, 2019. 40 Copyright Notice 42 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . 22 93 B.1. Changes to draft-ietf-lisp-mn-03 . . . . . . . . . . . . 22 94 B.2. Changes to draft-ietf-lisp-mn-02 . . . . . . . . . . . . 22 95 B.3. Changes to draft-ietf-lisp-mn-01 . . . . . . . . . . . . 22 96 B.4. Changes to draft-ietf-lisp-mn-00 . . . . . . . . . . . . 23 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 100 1. Introduction 102 The Locator/ID Separation Protocol (LISP) [RFC6830] specifies a 103 design and mechanism for replacing the addresses currently used in 104 the Internet with two separate name spaces: Endpoint Identifiers 105 (EIDs), used within sites, and Routing Locators (RLOCs), used by the 106 transit networks that make up the Internet infrastructure. To 107 achieve this separation, LISP defines protocol mechanisms for mapping 108 from EIDs to RLOCs. The mapping infrastructure is comprised of LISP 109 Map-Servers and Map-Resolvers [RFC6833] and is tied together with 110 LISP+ALT [RFC6836]. 112 This document specifies the behavior of a new LISP network element: 113 the LISP Mobile Node. The LISP Mobile Node implements a subset of 114 the standard Ingress Tunnel Router and Egress Tunnel Router 115 functionality [RFC6830]. Design goals for the LISP mobility design 116 include: 118 o Allowing TCP connections to stay alive while roaming. 120 o Allowing the mobile node to communicate with other mobile nodes 121 while either or both are roaming. 123 o Allowing the mobile node to multi-home (i.e., use multiple 124 interfaces concurrently). 126 o Allowing the mobile node to be a server. That is, any mobile node 127 or stationary node can find and connect to a mobile node as a 128 server. 130 o Providing shortest path bidirectional data paths between a mobile 131 node and any other stationary or mobile node. 133 o Not requiring fine-grained routes in the core network to support 134 mobility. 136 o Not requiring a home-agent, foreign agent or other data plane 137 network elements to support mobility. Note since the LISP mobile 138 node design does not require these data plane elements, there is 139 no triangle routing of data packets as is found in Mobile IP 140 [RFC3344]. 142 o Not requiring new IPv6 extension headers to avoid triangle routing 143 [RFC3775]. 145 The LISP Mobile Node design requires the use of the LISP Map-Server 146 [RFC6836] and LISP Interworking [RFC6832] technology to allow a LISP 147 mobile node to roam and to be discovered in an efficient and scalable 148 manner. The use of Map-Server technology is discussed further in 149 Section 5. 151 The protocol mechanisms described in this document apply those cases 152 in which a node's IP address changes frequently. For example, when a 153 mobile node roams, it is typically assigned a new IP address. 154 Similarly, a broadband subscriber may have its address change 155 frequently; as such, a broadband subscriber can use the LISP Mobile 156 Node mechanisms defined in this specification. 158 The remainder of this document is organized as follows: Section 2 159 defines the terms used in this document. Section 3 provides a 160 overview of salient features of the LISP Mobile Node design, and 161 Section 4 describes design requirements for a LISP Mobile Node. 162 Section 5 provides the detail of LISP Mobile Node data and control 163 plane operation, and Section 6 discusses options for updating remote 164 caches in the presence of unidirectional traffic flows. Section 7 165 specifies how the LISP Mobile Node protocol operates. Section 8 166 specifies multicast operation for LISP mobile nodes. Section 9 and 167 Section 12 outline other considerations for the LISP-MN design and 168 implementation. Finally, Section 13 outlines the security 169 considerations for a LISP mobile node. 171 2. Definition of Terms 173 This section defines the terms used in this document. 175 Stationary Node (SN): A non-mobile node who's IP address changes 176 infrequently. That is, its IP address does not change as 177 frequently as a fast roaming mobile hand-set or a broadband 178 connection and therefore the EID to RLOC mapping is relatively 179 static. 181 Endpoint ID (EID): This is the traditional LISP EID [RFC6830], and 182 is the address that a LISP mobile node uses as its address for 183 transport connections. A LISP mobile node never changes its EID, 184 which is typically a /32 or /128 prefix and is assigned to a 185 loopback interface. Note that the mobile node can have multiple 186 EIDs, and these EIDs can be from different address families. 188 Routing Locator (RLOC): This is the traditional LISP RLOC, and is in 189 general a routable address that can be used to reach a mobile 190 node. Note that there are cases in which an mobile node may 191 receive an address that it thinks is an RLOC (perhaps via DHCP) 192 which is either an EID or an RFC 1918 address [RFC1918]. This 193 could happen if, for example, if the mobile node roams into a LISP 194 domain or a domain behind a Network Address Translator (NAT)) See 195 Section 10 for more details. 197 Ingress Tunnel Router (ITR): An ITR is a router that accepts an IP 198 packet with a single IP header (more precisely, an IP packet that 199 does not contain a LISP header). The router treats this "inner" 200 IP destination address as an EID and performs an EID-to-RLOC 201 mapping lookup. The router then prepends an "outer" IP header 202 with one of its globally routable RLOCs in the source address 203 field and the result of the mapping lookup in the destination 204 address field. Note that this destination RLOC may be an 205 intermediate, proxy device that has better knowledge of the EID- 206 to-RLOC mapping closer to the destination EID. In general, an ITR 207 receives IP packets from site end-systems on one side and sends 208 LISP-encapsulated IP packets toward the Internet on the other 209 side. A LISP mobile node, however, when acting as an ITR LISP 210 encapsulates all packet that it originates. 212 Egress Tunnel Router (ETR): An ETR is a router that accepts an IP 213 packet where the destination address in the "outer" IP header is 214 one of its own RLOCs. The router strips the "outer" header and 215 forwards the packet based on the next IP header found. In 216 general, an ETR receives LISP-encapsulated IP packets from the 217 Internet on one side and sends decapsulated IP packets to site 218 end-systems on the other side. A LISP mobile node, when acting as 219 an ETR, decapsulates packets that are then typically processed by 220 the mobile node. 222 Proxy Ingress Tunnel Router (PITR): PITRs are used to provide 223 interconnectivity between sites that use LISP EIDs and those that 224 do not. They act as a gateway between the Legacy Internet and the 225 LISP enabled Network. A given PITR advertises one or more highly 226 aggregated EID prefixes into the public Internet and acts as the 227 ITR for traffic received from the public Internet. Proxy Ingress 228 Tunnel Routers are described in [RFC6832]. 230 Proxy Egress Tunnel Router (PETR): An infrastructure element used to 231 decapsulate packets sent from mobile nodes to non-LISP sites. 232 Proxy Egress Tunnel Routers are described in [RFC6832]. 234 LISP Mobile Node (LISP-MN): A LISP capable fast roaming mobile hand- 235 set. 237 Map-cache: A data structure which contains an EID-prefix, its 238 associated RLOCs, and the associated policy. Map-caches are 239 typically found in ITRs and PITRs. 241 Negative Map-Reply: A Negative Map-Reply is a Map-Reply that 242 contains a coarsely aggregated non-LISP prefix. Negative Map- 243 Replies are typically generated by Map-Resolvers, and are used to 244 inform an ITR (mobile or stationary) that a site is not a LISP 245 site. A LISP mobile node encapsulate packets to destinations 246 covered by the negative Map-Reply are encapsulated to a PETR. 248 Roaming Event: A Roaming Event occurs when there is a change in a 249 LISP mobile node's RLOC set. 251 3. Design Overview 253 The LISP-MN design described in this document uses the Map-Server/ 254 Map-Resolver service interface in conjunction with a light-weight 255 ITR/ETR implementation in the LISP-MN to provide scalable fast 256 mobility. The LISP-MN control-plane uses a Map-Server as an anchor 257 point, which provides control-plane scalability. In addition, the 258 LISP-MN data-plane takes advantage of shortest path routing and 259 therefore does not increase packet delivery latency. 261 4. Design Requirements 263 This section outlines the design requirements for a LISP-MN, and is 264 divided into User Requirements (Section 4.1) and Network Requirements 265 (Section 4.2). 267 4.1. User Requirements 269 This section describes the user-level functionality provided by a 270 LISP-MN. 272 Transport Connection Survivability: The LISP-MN design must allow a 273 LISP-MN to roam while keeping transport connections alive. 275 Simultaneous Roaming: The LISP-MN design must allow a LISP-MN to 276 talk to another LISP-MN while both are roaming. 278 Multihoming: The LISP-MN design must allow for simultaneous use of 279 multiple Internet connections by a LISP-MN. In addition, the 280 design must allow for the LISP mobile node to specify ingress 281 traffic engineering policies as documented in [RFC6830]. That is, 282 the LISP-MN must be able to specify both active/active and active/ 283 passive policies for ingress traffic. 285 Shortest Path Data Plane: The LISP-MN design must allow for shortest 286 path bidirectional traffic between a LISP-MN and a stationary 287 node, and between a LISP-MN and another LISP-MN (i.e., without 288 triangle routing in the data path). This provides a low-latency 289 data path between the LISP-MN and the nodes that it is 290 communicating with. 292 4.2. Network Requirements 294 This section describes the network functionality that the LISP-MN 295 design provides to a LISP-MN. 297 Routing System Scalability: The LISP-MN design must not require 298 injection of fine-grained routes into the core network. 300 Mapping System Scalability: The LISP-MN design must not require 301 additional state in the mapping system. In particular, any 302 mapping state required to support LISP mobility must BE confined 303 to the LISP-MN's Map-Server and the ITRs which are talking to the 304 LISP-MN. 306 Component Reuse: The LISP-MN design must use existing LISP 307 infrastructure components. These include map server, map 308 resolver, and interworking infrastructure components. 310 Home Agent/Foreign Agent: The LISP-MN design must not require the 311 use of home-agent or foreign-agent infrastructure components 312 [RFC3344]. 314 Readdressing: The LISP-MN design must not require TCP connections to 315 be reset when the mobile node roams. In particular, since the IP 316 address associated with a transport connection will not change as 317 the mobile node roams, TCP connections will not reset. 319 5. LISP Mobile Node Operation 321 The LISP-MN design is built from three existing LISP components: A 322 lightweight LISP implementation that runs in an LISP-MN, and the 323 existing Map-Server [RFC6833] and Interworking [RFC6832] 324 infrastructures. A LISP mobile node typically sends and receives 325 LISP encapsulated packets (exceptions include management protocols 326 such as DHCP). 328 The LISP-MN design makes a single mobile node look like a LISP site 329 as described in in [RFC6830] by implementing ITR and ETR 330 functionality. Note that one subtle difference between standard ITR 331 behavior and LISP-MN is that the LISP-MN encapsulates all non-local, 332 non-LISP site destined outgoing packets to a PETR. 334 When a LISP-MN roams onto a new network, it receives a new RLOC. 335 Since the LISP-MN is the authoritative ETR for its EID-prefix, it 336 must Map-Register it's updated RLOC set. New sessions can be 337 established as soon as the registration process completes. Sessions 338 that are encapsulating to RLOCs that did not change during the 339 roaming event are not affected by the roaming event (or subsequent 340 mapping update). However, the LISP-MN must update the ITRs and PITRs 341 that have cached a previous mapping. It does this using the 342 techniques described in Section 6. 344 5.1. Addressing Architecture 346 A LISP-MN is typically provisioned with one or more EIDs that it uses 347 for all transport connections. LISP-MN EIDs are provisioned from 348 blocks reserved from mobile nodes much the way mobile phone numbers 349 are provisioned today (such that they do not overlap with the EID 350 space of any enterprise). These EIDs can be either IPv4 or IPv6 351 addresses. For example, one EID might be for a public network while 352 another might be for a private network; in this case the "public" EID 353 will be associated with RLOCs from the public Internet, while the 354 "private" EID will be associated with private RLOCs. It is 355 anticipated that these EIDs will change infrequently if at all, since 356 the assignment of a LISP-MN's EID is envisioned to be a subscription 357 time event. The key point here is that the relatively fixed EID 358 allows the LISP-MN's transport connections to survive roaming events. 359 In particular, while the LISP-MN's EIDs are fixed during roaming 360 events, the LISP-MN's RLOC set will change. The RLOC set may be 361 comprised of both IPv4 or IPv6 addresses. 363 A LISP-MN is also provisioned with the address of a Map-Server and a 364 corresponding authentication key. Like the LISP-MN's EID, both the 365 Map-Server address and authentication key change very infrequently 366 (again, these are anticipated to be subscription time parameters). 367 Since the LISP LISP-MN's Map-Server is configured to advertise an 368 aggregated EID-prefix that covers the LISP-MN's EID, changes to the 369 LISP-MN's mapping are not propagated further into the mapping system 370 [RFC6836]. It is this property that provides for scalable fast 371 mobility. 373 A LISP-MN is also be provisioned with the address of a Map-Resolver. 374 A LISP-MN may also learn the address of a Map-Resolver though a 375 dynamic protocol such as DHCP [RFC2131]. 377 Finally, note that if, for some reason, a LISP-MN's EID is re- 378 provisioned, the LISP-MN's Map-Server address may also have to change 379 in order to keep LISP-MN's EID within the aggregate advertised by the 380 Map-Server (this is discussed in greater detail in Section 5.2). 382 5.2. Control Plane Operation 384 A roaming event occurs when the LISP-MN receives a new RLOC. Because 385 the new address is a new RLOC from the LISP-MN's perspective, it must 386 update its EID-to-RLOC mapping with its Map-Server; it does this 387 using the Map-Register mechanism described in [RFC6830]. 389 A LISP-MN may want the Map-Server to respond on its behalf for a 390 variety of reasons, including minimizing control traffic on radio 391 links and minimizing battery utilization. A LISP-MN may instruct its 392 Map-Server to proxy respond to Map-Requests by setting the Proxy-Map- 393 Reply bit in the Map-Register message [RFC6830]. In this case the 394 Map-Server responds with a non-authoritative Map-Reply so that an ITR 395 or PITR will know that the ETR didn't directly respond. A Map-Server 396 will proxy reply only for "registered" EID-prefixes using the 397 registered EID-prefix mask-length in proxy replies. 399 Because the LISP-MN's Map-Server is pre-configured to advertise an 400 aggregate covering the LISP-MN's EID prefix, the database mapping 401 change associated with the roaming event is confined to the Map- 402 Server and those ITRs and PITRs that may have cached the previous 403 mapping. 405 5.3. Data Plane Operation 407 A key feature of LISP-MN control-plane design is the use of the Map- 408 Server as an anchor point; this allows control of the scope to which 409 changes to the mapping system must be propagated during roaming 410 events. 412 On the other hand, the LISP-MN data-plane design does not rely on 413 additional LISP infrastructure for communication between LISP nodes 414 (mobile or stationary). Data packets take the shortest path to and 415 from the LISP-MN to other LISP nodes; as noted above, low latency 416 shortest paths in the data-plane is an important goal for the LISP-MN 417 design (and is important for delay-sensitive applications like gaming 418 and voice-over-IP). Note that a LISP-MN will need additional 419 interworking infrastructure when talking to non-LISP sites [RFC6832]; 420 this is consistent with the design of any host at a LISP site which 421 talks to a host at a non-LISP site. 423 In general, the LISP-MN data-plane operates in the same manner as the 424 standard LISP data-plane with one exception: packets generated by a 425 LISP-MN which are not destined for the mapping system (i.e., those 426 sent to destination UDP port 4342) or the local network are LISP 427 encapsulated. Because data packets are always encapsulated to a 428 RLOC, packets travel on the shortest path from LISP-MN to another 429 LISP stationary or LISP-MN. When the LISP mobile node is sending 430 packets to a stationary or LISP-MN in a non-LISP site, it sends LISP- 431 encapsulated packets to a PETR which then decapsulates the packet and 432 forwards it to its destination. 434 6. Updating Remote Caches 436 A LISP-MN has five mechanisms it can use to cause the mappings cached 437 in remote ITRs and PITRs to be refreshed: 439 Map Versioning: If Map Versioning [RFC6834] is used, an ETR can 440 detect if an ITR is using the most recent database mapping. In 441 particular, when mobile node's ETR decapsulates a packet and 442 detects the Destination Map-Version Number is less than the 443 current version for its mapping, in invokes the SMR procedure 444 described in [RFC6830]. In general, SMRs are used to fix the out 445 of sync mapping while Map-Versioning is used to detect they are 446 out of sync. [RFC6834] provides additional details of the Map 447 Versioning process. 449 Data Driven SMRs: An ETR may elect to send SMRs to those sites it 450 has been receiving encapsulated packets from. This will occur 451 when an ITR is sending to an old RLOC (for which there is one-to- 452 one mapping between EID-to-RLOC) and the ETR may not have had a 453 chance to send an SMR the ITR. 455 Setting Small TTL on Map Replies: The ETR (or Map Server) may set a 456 small Time to Live (TTL) on its mappings when responding to Map 457 Requests. The TTL value should be chosen such that changes in 458 mappings can be detected while minimizing control traffic. In 459 this case the ITR is a SN and the ETR is the MN. 461 Piggybacking Mapping Data: If an ITR and ETR are co-located, an ITR 462 may elect to send Map-Requests with piggybacked mapping data to 463 those sites in its map cache or to which it has recently 464 encapsulated data in order to inform the remote ITRs and PITRs of 465 the change. 467 Temporary PITR Caching: The ETR can keep a cache of PITRs that have 468 sent Map-Requests to it. The cache contains the RLOCs of the 469 PITRs so later when the locator-set of a LISP-MN changes, SMR 470 messages can be sent to all RLOCs in the PITR cache. This is an 471 example of a control-plane driven SMR procedure. 473 7. Protocol Operation 475 There are five distinct connectivity cases considered by the LISP-MN 476 design. The five mobility cases are: 478 LISP Mobile Node to a Stationary Node in a LISP Site. 480 LISP Mobile Node to a Non-LISP Site. 482 LISP Mobile Node to a LISP Mobile Node. 484 Non-LISP Site to a LISP Mobile Node. 486 LISP Site to a LISP Mobile Node. 488 The remainder of this section covers these cases in detail. 490 7.1. LISP Mobile Node to a Stationary Node in a LISP Site 492 After a roaming event, a LISP-MN must immediately register its new 493 EID-to-RLOC mapping with its configured Map-Server(s). This allows 494 LISP sites sending Map-Requests to the LISP-MN to receive the current 495 mapping. In addition, remote ITRs and PITRs may have cached mappings 496 that are no longer valid. These ITRs and PITRs must be informed that 497 the mapping has changed. See Section 6 for a discussion of methods 498 for updating remote caches. 500 7.1.1. Handling Unidirectional Traffic 502 A problem may arise when traffic is flowing unidirectionally between 503 LISP sites. This can arise in communication flows between PITRs and 504 LISP sites or when a site's ITRs and ETRs are not co-located. In 505 these cases, data-plane techniques such as Map-Versioning and Data- 506 Driven SMRs can't be used to update the remote caches. 508 For example, consider the unidirectional packet flow case depicted in 509 Figure 1. In this case X is a non-LISP enabled SN (i.e., connected 510 to the Internet) and Y is a LISP MN. Data traffic from X to Y will 511 flow through a PITR. When Y changes its mapping (for example, during 512 a mobility event), the PITR must update its mapping for Y. However, 513 since data traffic from Y to X is unidirectional and does not flow 514 though the PITR, it can not rely data traffic from Y to X to signal a 515 mapping change at Y. In this case, the Y must use one or more of the 516 techniques described in Section 6 to update the PITR's cache. Note 517 that if Y has only one RLOC, then the PITR has to know when to send a 518 Map-Request based on its existing state; thus it can only rely on the 519 TTL on the existing mapping. 521 +-------------------------------------------+ 522 | | 523 | | DP 524 v DP DP MQ | 525 X -----> Internet -----> PITR ------------> Y 526 ^ LEDP | 527 | | 528 +-----------------+ 529 MR 531 DP: Data Packet 532 LEDP: LISP Encapsulated Data Packet 533 MQ: Map Request 534 MR: Map Reply 536 Figure 1: Unidirectional Packet Flow 538 7.2. LISP Mobile Node to a Non-LISP Stationary Node 540 LISP-MNs use the LISP Interworking infrastructure (specifically a 541 PETR) to reach non-LISP sites. In general, the PETR will be co- 542 located with the LISP-MN's Map-Server. This ensures that the LISP 543 packets being decapsulated are from sources that have Map-Registered 544 to the Map-Server. Note that when a LISP-MN roams it continues to 545 uses its configured PETR and Map-Server which can have the effect of 546 adding stretch to packets sent from a LISP-MN to a non-LISP 547 destination. 549 7.3. LISP Mobile Node to LISP Mobile Node 551 LISP-MN to LISP-MN communication is an instance of LISP-to-LISP 552 communication with three sub-cases: 554 o Both LISP-MNs are stationary (Section 7.1). 556 o Only one LISP-MN is roaming (Section 7.3.1). 558 o Both LISP-MNs are roaming. The case is analogous to the case 559 described in Section 7.3.1. 561 7.3.1. One Mobile Node is Roaming 563 In this case, the roaming LISP-MN can find the stationary LISP-MN by 564 sending Map-Request for its EID-prefix. After receiving a Map-Reply, 565 the roaming LISP-MN can encapsulate data packets directly to the non- 566 roaming LISP-MN node. 568 The roaming LISP-MN, on the other hand, must update its Map-Server 569 with the new mapping data as described in Section 7.1. It should 570 also use the cache management techniques described in Section 6 to 571 provide for timely updates of remote caches. Once the roaming LISP- 572 MN has updated its Map-Server, the non-roaming LISP-MN can retrieve 573 the new mapping data (if it hasn't already received an updated 574 mapping via one of the mechanisms described in Section 6) and the 575 stationary LISP-MN can encapsulate data directly to the roaming LISP- 576 MN. 578 7.4. Non-LISP Site to a LISP Mobile Node 580 When a stationary ITR is talking to a non-LISP site, it may forward 581 packets natively (unencapsulated) to the non-LISP site. This will 582 occur when the ITR has received a negative Map Reply for a prefix 583 covering the non-LISP site's address with the Natively-Forward action 584 bit set [RFC6830]. As a result, packets may be natively forwarded to 585 non-LISP sites by an ITR (the return path will through a PITR, 586 however, since the packet flow will be non-LISP site to LISP site). 588 A LISP-MN behaves differently when talking to non-LISP sites. In 589 particular, the LISP-MN always encapsulates packets to a PETR. The 590 PETR then decapsulates the packet and forwards it natively to its 591 destination. As in the stationary case, packets from the non-LISP 592 site host return to the LISP-MN through a PITR. Since traffic 593 forwarded through a PITR is unidirectional, a LISP-MN should use the 594 cache management techniques described in Section 7.1.1. 596 7.5. LISP Site to LISP Mobile Node 598 When a LISP-MN roams onto a new network, it needs to update the 599 caches in any ITRs that might have stale mappings. This is analogous 600 to the case in that a stationary LISP site is renumbered; in that 601 case ITRs that have cached the old mapping must be updated. This is 602 done using the techniques described in Section 6. 604 When a LISP router in a stationary site is performing both ITR and 605 ETR functions, a LISP-MN can update the stationary site's map-caches 606 using techniques described in Section 6. However, when the LISP 607 router in the stationary site is performing is only ITR 608 functionality, these techniques can not be used because the ITR is 609 not receiving data traffic from the LISP-MN. In this case, the LISP- 610 MN should use the technique described in Section 7.1.1. In 611 particular, a LISP-MN should set the TTL on the mappings in its Map- 612 Replies to be in 1-2 minute range. 614 8. Multicast and Mobility 616 Since a LISP-MN performs both ITR and ETR functionality, it should 617 also perform a lightweight version of multicast ITR/ETR functionality 618 described in [RFC6831]. When a LISP-MN originates a multicast 619 packet, it will encapsulate the packet with a multicast header, where 620 the source address in the outer header is one of it's RLOC addresses 621 and the destination address in the outer header is the group address 622 from the inner header. The interfaces in which the encapsulated 623 packet is sent on is discussed below. 625 To not require PIM functionality in the LISP-MN as documented in 626 [RFC6831], the LISP-MN resorts to using encapsulated IGMP for joining 627 groups and for determining which interfaces are used for packet 628 origination. When a LISP-MN joins a group, it obtains the map-cache 629 entry for the (S-EID,G) it is joining. It then builds a IGMP report 630 encoding (S-EID,G) and then LISP encapsulates it with UDP port 4341. 631 It selects an RLOC from the map-cache entry to send the encapsulated 632 IGMP Report. 634 When other LISP-MNs are joining an (S-EID,G) entry where the S-EID is 635 for a LISP-MN, the encapsulated IGMP Report will be received by the 636 LISP-MN multicast source. The LISP-MN multicast source will remember 637 the interfaces the encapsulated IGMP Report is received on and build 638 an outgoing interface list for it's own (S-EID,G) entry. If the list 639 is greater than one, then the LISP-MN is doing replication on the 640 source-based tree for which it is the root. 642 When other LISP routers are joining (S-EID,G), they are instructed to 643 send PIM encapsulated Join-Prune messages. However, to keep the 644 LISP-MN as simple as possible, the LISP-MN will not be able to 645 process encapsulated PIM Join-Prune messages. Because the map-cache 646 entry will have a MN-bit indicating the entry is for a LISP-MN, the 647 LISP router will send IGMP encapsulated IGMP Reports instead. 649 When the LISP-MN is sending a multicast packet, it can operate in two 650 modes, multicast-origination-mode or unicast-origination-mode. When 651 in multicast-origination-mode, the LISP-MN multicast-source can 652 encapsulate a multicast packet in another multicast packet, as 653 described above. When in unicast-origination-mode, the LISP-MN 654 multicast source encapsulates the multicast packet into a unicast 655 packet and sends a packet to each encapsulated IGMP Report sender. 657 These modes are provided depending on whether or not the mobile 658 node's network it is currently connected can support IP multicast. 660 9. RLOC Considerations 662 This section documents cases where the expected operation of the 663 LISP-MN design may require special treatment. 665 9.1. Mobile Node's RLOC is an EID 667 When a LISP-MN roams into a LISP site, the "RLOC" it is assigned may 668 be an address taken from the site's EID-prefix. In this case, the 669 LISP-MN will Map-Register a mapping from its statically assigned EID 670 to the "RLOC" it received from the site. This scenario creates 671 another level of indirection: the mapping from the LISP-MN's EID to a 672 site assigned EID. The mapping from the LISP-MN's EID to the site 673 assigned EID allow the LISP-MN to be reached by sending packets using 674 the mapping for the EID; packets are delivered to site's EIDs use the 675 same LISP infrastructure that all LISP hosts use to reach the site. 677 A packet egressing a LISP site destined for a LISP-MN that resides in 678 a LISP site will have three headers: an inner header that is built by 679 the host and is used by transport connections, a middle header that 680 is built by the site's ITR and is used by the destination's ETR to 681 find the current topological location of the LISP-MN, and an outer 682 header (also built by the site's ITR) that is used to forward packets 683 between the sites. 685 Consider a site A with EID-prefix 1.0.0.0/8 and RLOC A and a site B 686 with EID-prefix 2.0.0.0/8 and RLOC B. Suppose that a host S in site 687 A with EID 1.0.0.1 wants to talk to a LISP LISP-MN MN that has 688 registered a mapping from EID 240.0.0.1 to "RLOC" 2.0.0.2 (where 689 2.0.0.2 allocated from site B's EID prefix, 2.0.0.0/8 in this case). 690 This situation is depicted in Figure 2. 692 EID-prefix 1.0.0.0/8 EID-prefix 2.0.0.0/8 693 S has EID 1.0.0.1 MN has EID 240.0.0.1 694 MN has RLOC 2.0.0.2 695 -------------- -------------- 696 / \ --------------- / \ 697 | ITR-A' | / \ | ETR-B' | 698 | | | | | | 699 | S | | Internet | | MN | 700 | \ | | | | ^ | 701 | \ | | | | / | 702 | --> ITR-A | \ / | ETR-B ---- | 703 \ / --------------- \ / 704 -------------- -------------- 705 | | | ^ ^ ^ 706 | | | | | | 707 | | | outer-header: A -> B | | | 708 | | +---------------------------------------+ | | 709 | | RLOCs used to find which site MN resides | | 710 | | | | 711 | | | | 712 | | middle-header: A -> 2.0.0.2 | | 713 | +------------------------------------------------+ | 714 | RLOCs used to find topological location of MN | 715 | | 716 | | 717 | inner-header: 1.0.0.1 -> 240.0.0.1 | 718 +-----------------------------------------------------------+ 719 EIDs used for TCP connection 721 Figure 2: Mobile Node Roaming into a LISP Site 723 In this case, the inner header is used for transport connections, the 724 middle header is used to find topological location of the LISP-MN 725 (the LISP-MN Map-Registers the mapping 240.0.0.1 -> 2.0.0.2 when it 726 roams into site B), and the outer header is used to move packets 727 between sites (A and B in Figure 2). 729 In summary, when a LISP-MN roams into a LISP site and receives a new 730 address (e.g., via DHCP) that is part of the site's EID space, the 731 following sequence occurs: 733 1. The LISP-MN in the LISP site (call it Inside) registers its new 734 RLOC (which is actually part of the sites EID prefix) to its map- 735 server. Call its permanent EID E and the EID it DHCPs D. So it 736 registers a mapping that looks like E->D. 738 2. The MN which is outside (call it Outside) sends a map request for 739 inside's EID (E) and receives D (plus its policy). Outside 740 realizes that D is an EID and sends a map request for D. This 741 will return the site's RLOCs (by its ETR). Call this R. 743 3. Outside then double encapsulates the outbound packet with the 744 inner destination being D and the outer destination being R. 746 4. The packet then finds its way to R, which strips the outer header 747 and the packet is routed to D in the domain to Inside. Inside 748 decapsulates the packet to serve the inner header to the 749 application. 751 Note that both D and R could be returned to Inside in one query, so 752 as not to incur the additional RTT. 754 10. LISP Mobile Nodes behind NAT Devices 756 When a LISP-MN resides behind a NAT device, it will be allocated a 757 private RLOC address. The private RLOC address is used as the source 758 address in the outer header for LISP encapsulated packets. The NAT 759 device will translate the source address and source UDP port in the 760 LISP encapsulated packet. The NAT device will keep this translated 761 state so when packets arrive from the public side of the NAT, they 762 can be translated back to the stored state. For remote LISP ITRs, 763 PITRs, and RTRs, will need to know the translated RLOC address and 764 port so they can encapsulate to the LISP-MN traversing the NAT 765 device. 767 Procedures a LISP-MN should follow when it resides behind a NAT, will 768 follow the LISP xTRs procedures in specification 769 [I-D.ermagan-lisp-nat-traversal]. 771 11. Mobility Example 773 This section provides an example of how the LISP-MN is integrated 774 into the base LISP Design [RFC6830]. 776 11.1. Provisioning 778 The LISP-MN needs to be configured with the following information: 780 An EID, assigned to its loopback address 782 A key for map-registration 784 An IP address of a Map-Resolver (this could be learned 785 dynamically) 786 An IP address of its Map-Server and Proxy ETR 788 11.2. Registration 790 After a LISP roams to a new network, it must immediately register its 791 new mapping this new RLOC (and associated priority/weight data) with 792 its Map-Server. 794 The LISP-MN may chose to set the 'proxy' bit in the map-register to 795 indicate that it desires its Map-Server to answer map-requests on its 796 behalf. 798 12. LISP Implementation in a Mobile Node 800 This section will describe a possible approach for developing a 801 lightweight LISP-MN implementation. A LISP-MN will implement a LISP 802 sub-layer inside of the IP layer of the protocol stack. The sub- 803 layer resides between the IP layer and the link-layer. 805 For outgoing unicast packets, once the header that contains EIDs is 806 built and right before an outgoing interface is chosen, a LISP header 807 is prepended to the outgoing packet. The source address is set to 808 the local RLOC address (obtained by DHCP perhaps) and the destination 809 address is set to the RLOC associated with the destination EID from 810 the IP layer. To obtain the RLOC for the EID, the LISP-MN maintains 811 a map-cache for destination sites or destination LISP-MNs to which it 812 is currently talking. The map-cache lookup is performed by doing a 813 longest match lookup on the destination address the IP layer put in 814 the first IP header. Once the new header is prepended, a route table 815 lookup is performed to find the interface in which to send the packet 816 or the default router interface is used to send the packet. 818 When the map-cache does not exist for a destination, the mobile node 819 may queue or drop the packet while it sends a Map-Request to it's 820 configured Map-Resolver. Once a Map-Reply is returned, the map-cache 821 entry stores the EID-to-RLOC state. If the RLOC state is empty in 822 the Map-Reply, the Map-Reply is known as a Negative Map-Reply in 823 which case the map-cache entry is created with a single RLOC, the 824 RLOC of the configured Map-Server for the LISP-MN. The Map-Server 825 that serves the LISP-MN also acts as a Proxy ETR (PETR) so packets 826 can get delivered to hosts in non-LISP sites to which the LISP-MN is 827 sending. 829 For incoming unicast packets, the LISP sub-layer simply decapsulates 830 the packets and delivers to the IP layer. The loc-reach-bits can be 831 processed by the LISP sub-layer. Specifically, the source EID from 832 the packet is looked up in the map-cache and if the loc-reach-bits 833 settings have changed, store the loc-reach-bits from the packet and 834 note which RLOCs for the map-cache entry should not be used. 836 In terms of the LISP-MN detecting which RLOCs from each stored map- 837 cache entry is reachable, it can use any of the Locator Reachability 838 Algorithms from [RFC6830]. 840 A background task that runs off a timer should be run so the LISP-MN 841 can send periodic Map-Register messages to the Map-Server. The Map- 842 Register message should also be triggered when the LISP-MN detects a 843 change in IP address for a given interface. The LISP-MN should send 844 Map-Registers to the same Map-Register out each of it's operational 845 links. This will provide for robustness on radio links with which 846 the mobile node is associated. 848 A LISP-MN receives a Map-Request when it has Map-Registered to a Map- 849 Server with the Proxy-bit set to 0. This means that the LISP-MN 850 wishes to send authoritative Map-Replies for Map-Requests that are 851 targeted at the LISP-MN. If the Proxy-bit is set when the LISP-MN 852 registers, then the Map-Server will send non-authoritative Map- 853 Replies on behalf of the LISP-MN. In this case, the Map-Server never 854 encapsulates Map-Requests to the LISP-MN. The LISP-MN can save 855 resources by not receiving Map-Requests (note that the LISP-MN will 856 receive SMRs which have the same format as Map-Requests). 858 To summarize, a LISP sub-layer should implement: 860 o Encapsulating and decapsulating data packets. 862 o Sending and receiving of Map-Request control messages. 864 o Receiving and optionally sending Map-Replies. 866 o Sending Map-Register messages periodically. 868 The key point about the LISP sub-layer is that no other components in 869 the protocol stack need changing; just the insertion of this sub- 870 layer between the IP layer and the interface layer-2 encapsulation/ 871 decapsulation layer. 873 13. Security Considerations 875 Security for the LISP-MN design builds upon the security fundamentals 876 found in LISP [RFC6830] for data-plane security and the LISP Map 877 Server [RFC6833] registration security. Security issues unique to 878 the LISP-MN design are considered below. 880 13.1. Proxy ETR Hijacking 882 The Proxy ETR (or PETR) that a LISP-MN uses as its destination for 883 non-LISP traffic must use the security association used by the 884 registration process outlined in Section 5.2 and explained in detail 885 in the LISP-MS specification [RFC6833]. These measures prevent third 886 party injection of LISP encapsulated traffic into a Proxy ETR. 887 Importantly, a PETR must not decapsulate packets from non-registered 888 RLOCs. 890 13.2. LISP Mobile Node using an EID as its RLOC 892 For LISP packets to be sent to a LISP-MN which has an EID assigned to 893 it as an RLOC as described in Section 9.1), the LISP site must allow 894 for incoming and outgoing LISP data packets. Firewalls and stateless 895 packet filtering mechanisms must be configured to allow UDP port 4341 896 and UDP port 4342 packets. 898 14. IANA Considerations 900 This document is requesting bit allocations in the Map-Request and 901 Map-Register messages. 903 The first 4 octets of the Map-Request message are: 905 0 1 2 3 906 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 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 |Type=1 |A|M|P|S|p|s|m|I| Rsvd |L|D| IRC | Record Count | 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 This document requests allocation of bit position 10 labeled "m" in 912 the above diagram. The IANA name label is "map-request-m-bit". When 913 a LISP mobile-node sends a Map-Request message to the mapping system, 914 it sets the m-bit to 1. 916 The first 4 octets of the Map-Register message are: 918 0 1 2 3 919 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 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 |Type=3 |P|S|I| Reserved |E|T|a|m|M| Record Count | 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 This document requests allocation of bit position 22 labeled "m" in 925 the above diagram. The IANA name label is "map-register-m-bit". 926 When a LISP mobile-node sends a Map-Register message to the mapping 927 system, it sets the m-bit to 1. 929 15. References 931 15.1. Normative References 933 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 934 and E. Lear, "Address Allocation for Private Internets", 935 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 936 . 938 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 939 RFC 2131, DOI 10.17487/RFC2131, March 1997, 940 . 942 [RFC3344] Perkins, C., Ed., "IP Mobility Support for IPv4", 943 RFC 3344, DOI 10.17487/RFC3344, August 2002, 944 . 946 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 947 in IPv6", RFC 3775, DOI 10.17487/RFC3775, June 2004, 948 . 950 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 951 IANA Considerations Section in RFCs", RFC 5226, 952 DOI 10.17487/RFC5226, May 2008, 953 . 955 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 956 Locator/ID Separation Protocol (LISP)", RFC 6830, 957 DOI 10.17487/RFC6830, January 2013, 958 . 960 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 961 Locator/ID Separation Protocol (LISP) for Multicast 962 Environments", RFC 6831, DOI 10.17487/RFC6831, January 963 2013, . 965 [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 966 "Interworking between Locator/ID Separation Protocol 967 (LISP) and Non-LISP Sites", RFC 6832, 968 DOI 10.17487/RFC6832, January 2013, 969 . 971 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 972 Protocol (LISP) Map-Server Interface", RFC 6833, 973 DOI 10.17487/RFC6833, January 2013, 974 . 976 [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID 977 Separation Protocol (LISP) Map-Versioning", RFC 6834, 978 DOI 10.17487/RFC6834, January 2013, 979 . 981 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, 982 "Locator/ID Separation Protocol Alternative Logical 983 Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, 984 January 2013, . 986 15.2. Informative References 988 [I-D.ermagan-lisp-nat-traversal] 989 Ermagan, V., Farinacci, D., Lewis, D., Skriver, J., Maino, 990 F., and C. White, "NAT traversal for LISP", draft-ermagan- 991 lisp-nat-traversal-15 (work in progress), October 2018. 993 Appendix A. Acknowledgments 995 Albert Cabellos, Noel Chiappa, Pierre Francois, Michael Menth, Andrew 996 Partan, Chris White and John Zwiebel provided insightful comments on 997 the mobile node concept and on this document. A special thanks goes 998 to Mary Nickum for her attention to detail and effort in editing 999 early versions of this document. 1001 Appendix B. Document Change Log 1003 B.1. Changes to draft-ietf-lisp-mn-03 1005 o Posted October 2018. 1007 o Request m-bit allocation in Map-Register message in IANA 1008 Considerations section. 1010 B.2. Changes to draft-ietf-lisp-mn-02 1012 o Posted April 2018. 1014 o Update document timer and references. 1016 B.3. Changes to draft-ietf-lisp-mn-01 1018 o Posted October 2017. 1020 o Update document timer and references. 1022 B.4. Changes to draft-ietf-lisp-mn-00 1024 o Posted April 2017. 1026 o Changed draft-meyer-lisp-mn-16 to working group document. 1028 Authors' Addresses 1030 Dino Farinacci 1031 lispers.net 1032 San Jose, CA 95134 1033 USA 1035 Email: farinacci@gmail.com 1037 Darrel Lewis 1038 cisco Systems 1039 Tasman Drive 1040 San Jose, CA 95134 1041 USA 1043 Email: darlewis@cisco.com 1045 David Meyer 1046 1-4-5.net 1047 USA 1049 Email: dmm@1-4-5.net 1051 Chris White 1052 Logical Elegance, LLC. 1053 San Jose, CA 95134 1054 USA 1056 Email: chris@logicalelegance.com