idnits 2.17.1 draft-meyer-lisp-mn-08.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 17, 2012) is 4202 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** 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) == Outdated reference: A later version (-24) exists of draft-ietf-lisp-23 -- No information found for draft-ermagen-lisp-nat-traversal - is the name correct? Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Farinacci 3 Internet-Draft D. Lewis 4 Intended status: Informational cisco Systems 5 Expires: April 20, 2013 D. Meyer 6 1-4-5.net 7 C. White 8 Logical Elegance, LLC. 9 October 17, 2012 11 LISP Mobile Node 12 draft-meyer-lisp-mn-08 14 Abstract 16 This document describes how a lightweight version of LISP's ITR/ETR 17 functionality can be used to provide seamless mobility to a mobile 18 node. The LISP Mobile Node design described in this document uses 19 standard LISP functionality to provide scalable mobility for LISP 20 mobile nodes. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 20, 2013. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 58 3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 6 59 4. Design Requirements . . . . . . . . . . . . . . . . . . . . . 6 60 4.1. User Requirements . . . . . . . . . . . . . . . . . . . . 6 61 4.2. Network Requirements . . . . . . . . . . . . . . . . . . . 7 62 5. LISP Mobile Node Operation . . . . . . . . . . . . . . . . . . 7 63 5.1. Addressing Architecture . . . . . . . . . . . . . . . . . 8 64 5.2. Control Plane Operation . . . . . . . . . . . . . . . . . 9 65 5.3. Data Plane Operation . . . . . . . . . . . . . . . . . . . 9 66 6. Updating Remote Caches . . . . . . . . . . . . . . . . . . . . 10 67 7. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 11 68 7.1. LISP Mobile Node to a Stationary Node in a LISP Site . . . 11 69 7.1.1. Handling Unidirectional Traffic . . . . . . . . . . . 11 70 7.2. LISP Mobile Node to a Non-LISP Stationary Node . . . . . . 12 71 7.3. LISP Mobile Node to LISP Mobile Node . . . . . . . . . . . 12 72 7.3.1. One Mobile Node is Roaming . . . . . . . . . . . . . . 12 73 7.4. Non-LISP Site to a LISP Mobile Node . . . . . . . . . . . 13 74 7.5. LISP Site to LISP Mobile Node . . . . . . . . . . . . . . 13 75 8. Multicast and Mobility . . . . . . . . . . . . . . . . . . . . 14 76 9. RLOC Considerations . . . . . . . . . . . . . . . . . . . . . 15 77 9.1. Mobile Node's RLOC is an EID . . . . . . . . . . . . . . . 15 78 10. LISP Mobile Nodes behind NAT Devices . . . . . . . . . . . . . 17 79 11. Mobility Example . . . . . . . . . . . . . . . . . . . . . . . 17 80 11.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . . 17 81 11.2. Registration . . . . . . . . . . . . . . . . . . . . . . . 18 82 12. LISP Implementation in a Mobile Node . . . . . . . . . . . . . 18 83 13. Security Considerations . . . . . . . . . . . . . . . . . . . 19 84 13.1. Proxy ETR Hijacking . . . . . . . . . . . . . . . . . . . 20 85 13.2. LISP Mobile Node using an EID as its RLOC . . . . . . . . 20 86 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 87 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 88 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 89 16.1. Normative References . . . . . . . . . . . . . . . . . . . 20 90 16.2. Informative References . . . . . . . . . . . . . . . . . . 21 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 93 1. Introduction 95 The Locator/ID Separation Protocol (LISP) [LISP] specifies a design 96 and mechanism for replacing the addresses currently used in the 97 Internet with two separate name spaces: Endpoint Identifiers (EIDs), 98 used within sites, and Routing Locators (RLOCs), used by the transit 99 networks that make up the Internet infrastructure. To achieve this 100 separation, LISP defines protocol mechanisms for mapping from EIDs to 101 RLOCs. The mapping infrastructure is comprised of LISP Map-Servers 102 and Map-Resolvers [LISP-MS] and is tied together with LISP+ALT 103 [LISP-ALT]. 105 This document specifies the behavior of a new LISP network element: 106 the LISP Mobile Node. The LISP Mobile Node implements a subset of 107 the standard Ingress Tunnel Router and Egress Tunnel Router 108 functionality [LISP]. Design goals for the LISP mobility design 109 include: 111 o Allowing TCP connections to stay alive while roaming. 113 o Allowing the mobile node to communicate with other mobile nodes 114 while either or both are roaming. 116 o Allowing the mobile node to multi-home (i.e., use multiple 117 interfaces concurrently). 119 o Allowing the mobile node to be a server. That is, any mobile node 120 or stationary node can find and connect to a mobile node as a 121 server. 123 o Providing shortest path bidirectional data paths between a mobile 124 node and any other stationary or mobile node. 126 o Not requiring fine-grained routes in the core network to support 127 mobility. 129 o Not requiring a home-agent, foreign agent or other data plane 130 network elements to support mobility. Note since the LISP mobile 131 node design does not require these data plane elements, there is 132 no triangle routing of data packets as is found in Mobile IP 133 [RFC3344]. 135 o Not requiring new IPv6 extension headers to avoid triangle routing 136 [RFC3775]. 138 The LISP Mobile Node design requires the use of the LISP Map-Server 139 [LISP-ALT] and LISP Interworking [LISP-INTERWORK] technology to allow 140 a LISP mobile node to roam and to be discovered in an efficient and 141 scalable manner. The use of Map-Server technology is discussed 142 further in Section 5. 144 The protocol mechanisms described in this document apply those cases 145 in which a node's IP address changes frequently. For example, when a 146 mobile node roams, it is typically assigned a new IP address. 147 Similarly, a broadband subscriber may have its address change 148 frequently; as such, a broadband subscriber can use the LISP Mobile 149 Node mechanisms defined in this specification. 151 The remainder of this document is organized as follows: Section 2 152 defines the terms used in this document. Section 3 provides a 153 overview of salient features of the LISP Mobile Node design, and 154 Section 4 describes design requirements for a LISP Mobile Node. 155 Section 5 provides the detail of LISP Mobile Node data and control 156 plane operation, and Section 6 discusses options for updating remote 157 caches in the presence of unidirectional traffic flows. Section 7 158 specifies how the LISP Mobile Node protocol operates. Section 8 159 specifies multicast operation for LISP mobile nodes. Section 9 and 160 Section 12 outline other considerations for the LISP-MN design and 161 implementation. Finally, Section 13 outlines the security 162 considerations for a LISP mobile node. 164 2. Definition of Terms 166 This section defines the terms used in this document. 168 Stationary Node (SN): A non-mobile node who's IP address changes 169 infrequently. That is, its IP address does not change as 170 frequently as a fast roaming mobile hand-set or a broadband 171 connection and therefore the EID to RLOC mapping is relatively 172 static. 174 Endpoint ID (EID): This is the traditional LISP EID [LISP], and is 175 the address that a LISP mobile node uses as its address for 176 transport connections. A LISP mobile node never changes its EID, 177 which is typically a /32 or /128 prefix and is assigned to a 178 loopback interface. Note that the mobile node can have multiple 179 EIDs, and these EIDs can be from different address families. 181 Routing Locator (RLOC): This is the traditional LISP RLOC, and is in 182 general a routable address that can be used to reach a mobile 183 node. Note that there are cases in which an mobile node may 184 receive an address that it thinks is an RLOC (perhaps via DHCP) 185 which is either an EID or an RFC 1918 address [RFC1918]. This 186 could happen if, for example, if the mobile node roams into a LISP 187 domain or a domain behind a Network Address Translator (NAT)) See 188 Section 10 for more details. 190 Ingress Tunnel Router (ITR): An ITR is a router that accepts an IP 191 packet with a single IP header (more precisely, an IP packet that 192 does not contain a LISP header). The router treats this "inner" 193 IP destination address as an EID and performs an EID-to-RLOC 194 mapping lookup. The router then prepends an "outer" IP header 195 with one of its globally routable RLOCs in the source address 196 field and the result of the mapping lookup in the destination 197 address field. Note that this destination RLOC may be an 198 intermediate, proxy device that has better knowledge of the EID- 199 to-RLOC mapping closer to the destination EID. In general, an ITR 200 receives IP packets from site end-systems on one side and sends 201 LISP-encapsulated IP packets toward the Internet on the other 202 side. A LISP mobile node, however, when acting as an ITR LISP 203 encapsulates all packet that it originates. 205 Egress Tunnel Router (ETR): An ETR is a router that accepts an IP 206 packet where the destination address in the "outer" IP header is 207 one of its own RLOCs. The router strips the "outer" header and 208 forwards the packet based on the next IP header found. In 209 general, an ETR receives LISP-encapsulated IP packets from the 210 Internet on one side and sends decapsulated IP packets to site 211 end-systems on the other side. A LISP mobile node, when acting as 212 an ETR, decapsulates packets that are then typically processed by 213 the mobile node. 215 Proxy Ingress Tunnel Router (PITR): PITRs are used to provide 216 interconnectivity between sites that use LISP EIDs and those that 217 do not. They act as a gateway between the Legacy Internet and the 218 LISP enabled Network. A given PITR advertises one or more highly 219 aggregated EID prefixes into the public Internet and acts as the 220 ITR for traffic received from the public Internet. Proxy Ingress 221 Tunnel Routers are described in [LISP-INTERWORK]. 223 Proxy Egress Tunnel Router (PETR): An infrastructure element used to 224 decapsulate packets sent from mobile nodes to non-LISP sites. 225 Proxy Egress Tunnel Routers are described in [LISP-INTERWORK]. 227 LISP Mobile Node (LISP-MN): A LISP capable fast roaming mobile hand- 228 set. 230 Map-cache: A data structure which contains an EID-prefix, its 231 associated RLOCs, and the associated policy. Map-caches are 232 typically found in ITRs and PITRs. 234 Negative Map-Reply: A Negative Map-Reply is a Map-Reply that 235 contains a coarsely aggregated non-LISP prefix. Negative Map- 236 Replies are typically generated by Map-Resolvers, and are used to 237 inform an ITR (mobile or stationary) that a site is not a LISP 238 site. A LISP mobile node encapsulate packets to destinations 239 covered by the negative Map-Reply are encapsulated to a PETR. 241 Roaming Event: A Roaming Event occurs when there is a change in a 242 LISP mobile node's RLOC set. 244 3. Design Overview 246 The LISP-MN design described in this document uses the Map-Server/ 247 Map-Resolver service interface in conjunction with a light-weight 248 ITR/ETR implementation in the LISP-MN to provide scalable fast 249 mobility. The LISP-MN control-plane uses a Map-Server as an anchor 250 point, which provides control-plane scalability. In addition, the 251 LISP-MN data-plane takes advantage of shortest path routing and 252 therefore does not increase packet delivery latency. 254 4. Design Requirements 256 This section outlines the design requirements for a LISP-MN, and is 257 divided into User Requirements (Section 4.1) and Network Requirements 258 (Section 4.2). 260 4.1. User Requirements 262 This section describes the user-level functionality provided by a 263 LISP-MN. 265 Transport Connection Survivability: The LISP-MN design must allow a 266 LISP-MN to roam while keeping transport connections alive. 268 Simultaneous Roaming: The LISP-MN design must allow a LISP-MN to 269 talk to another LISP-MN while both are roaming. 271 Multihoming: The LISP-MN design must allow for simultaneous use of 272 multiple Internet connections by a LISP-MN. In addition, the 273 design must allow for the LISP mobile node to specify ingress 274 traffic engineering policies as documented in [LISP]. That is, 275 the LISP-MN must be able to specify both active/active and active/ 276 passive policies for ingress traffic. 278 Shortest Path Data Plane: The LISP-MN design must allow for shortest 279 path bidirectional traffic between a LISP-MN and a stationary 280 node, and between a LISP-MN and another LISP-MN (i.e., without 281 triangle routing in the data path). This provides a low-latency 282 data path between the LISP-MN and the nodes that it is 283 communicating with. 285 4.2. Network Requirements 287 This section describes the network functionality that the LISP-MN 288 design provides to a LISP-MN. 290 Routing System Scalability: The LISP-MN design must not require 291 injection of fine-grained routes into the core network. 293 Mapping System Scalability: The LISP-MN design must not require 294 additional state in the mapping system. In particular, any 295 mapping state required to support LISP mobility must BE confined 296 to the LISP-MN's Map-Server and the ITRs which are talking to the 297 LISP-MN. 299 Component Reuse: The LISP-MN design must use existing LISP 300 infrastructure components. These include map server, map 301 resolver, and interworking infrastructure components. 303 Home Agent/Foreign Agent: The LISP-MN design must not require the 304 use of home-agent or foreign-agent infrastructure components 305 [RFC3344]. 307 Readdressing: The LISP-MN design must not require TCP connections to 308 be reset when the mobile node roams. In particular, since the IP 309 address associated with a transport connection will not change as 310 the mobile node roams, TCP connections will not reset. 312 5. LISP Mobile Node Operation 314 The LISP-MN design is built from three existing LISP components: A 315 lightweight LISP implementation that runs in an LISP-MN, and the 316 existing Map-Server [LISP-MS] and Interworking [LISP-INTERWORK] 317 infrastructures. A LISP mobile node typically sends and receives 318 LISP encapsulated packets (exceptions include management protocols 319 such as DHCP). 321 The LISP-MN design makes a single mobile node look like a LISP site 322 as described in in [LISP] by implementing ITR and ETR functionality. 323 Note that one subtle difference between standard ITR behavior and 324 LISP-MN is that the LISP-MN encapsulates all non-local, non-LISP site 325 destined outgoing packets to a PETR. 327 When a LISP-MN roams onto a new network, it receives a new RLOC. 328 Since the LISP-MN is the authoritative ETR for its EID-prefix, it 329 must Map-Register it's updated RLOC set. New sessions can be 330 established as soon as the registration process completes. Sessions 331 that are encapsulating to RLOCs that did not change during the 332 roaming event are not affected by the roaming event (or subsequent 333 mapping update). However, the LISP-MN must update the ITRs and PITRs 334 that have cached a previous mapping. It does this using the 335 techniques described in Section 6. 337 5.1. Addressing Architecture 339 A LISP-MN is typically provisioned with one or more EIDs that it uses 340 for all transport connections. LISP-MN EIDs are provisioned from 341 blocks reserved from mobile nodes much the way mobile phone numbers 342 are provisioned today (such that they do not overlap with the EID 343 space of any enterprise). These EIDs can be either IPv4 or IPv6 344 addresses. For example, one EID might be for a public network while 345 another might be for a private network; in this case the "public" EID 346 will be associated with RLOCs from the public Internet, while the 347 "private" EID will be associated with private RLOCs. It is 348 anticipated that these EIDs will change infrequently if at all, since 349 the assignment of a LISP-MN's EID is envisioned to be a subscription 350 time event. The key point here is that the relatively fixed EID 351 allows the LISP-MN's transport connections to survive roaming events. 352 In particular, while the LISP-MN's EIDs are fixed during roaming 353 events, the LISP-MN's RLOC set will change. The RLOC set may be 354 comprised of both IPv4 or IPv6 addresses. 356 A LISP-MN is also provisioned with the address of a Map-Server and a 357 corresponding authentication key. Like the LISP-MN's EID, both the 358 Map-Server address and authentication key change very infrequently 359 (again, these are anticipated to be subscription time parameters). 360 Since the LISP LISP-MN's Map-Server is configured to advertise an 361 aggregated EID-prefix that covers the LISP-MN's EID, changes to the 362 LISP-MN's mapping are not propagated further into the mapping system 363 [LISP-ALT]. It is this property that provides for scalable fast 364 mobility. 366 A LISP-MN is also be provisioned with the address of a Map-Resolver. 367 A LISP-MN may also learn the address of a Map-Resolver though a 368 dynamic protocol such as DHCP [RFC2131]. 370 Finally, note that if, for some reason, a LISP-MN's EID is re- 371 provisioned, the LISP-MN's Map-Server address may also have to change 372 in order to keep LISP-MN's EID within the aggregate advertised by the 373 Map-Server (this is discussed in greater detail in Section 5.2). 375 5.2. Control Plane Operation 377 A roaming event occurs when the LISP-MN receives a new RLOC. Because 378 the new address is a new RLOC from the LISP-MN's perspective, it must 379 update its EID-to-RLOC mapping with its Map-Server; it does this 380 using the Map-Register mechanism described in [LISP]. 382 A LISP-MN may want the Map-Server to respond on its behalf for a 383 variety of reasons, including minimizing control traffic on radio 384 links and minimizing battery utilization. A LISP-MN may instruct its 385 Map-Server to proxy respond to Map-Requests by setting the Proxy-Map- 386 Reply bit in the Map-Register message [LISP]. In this case the Map- 387 Server responds with a non-authoritative Map-Reply so that an ITR or 388 PITR will know that the ETR didn't directly respond. A Map-Server 389 will proxy reply only for "registered" EID-prefixes using the 390 registered EID-prefix mask-length in proxy replies. 392 Because the LISP-MN's Map-Server is pre-configured to advertise an 393 aggregate covering the LISP-MN's EID prefix, the database mapping 394 change associated with the roaming event is confined to the Map- 395 Server and those ITRs and PITRs that may have cached the previous 396 mapping. 398 5.3. Data Plane Operation 400 A key feature of LISP-MN control-plane design is the use of the Map- 401 Server as an anchor point; this allows control of the scope to which 402 changes to the mapping system must be propagated during roaming 403 events. 405 On the other hand, the LISP-MN data-plane design does not rely on 406 additional LISP infrastructure for communication between LISP nodes 407 (mobile or stationary). Data packets take the shortest path to and 408 from the LISP-MN to other LISP nodes; as noted above, low latency 409 shortest paths in the data-plane is an important goal for the LISP-MN 410 design (and is important for delay-sensitive applications like gaming 411 and voice-over-IP). Note that a LISP-MN will need additional 412 interworking infrastructure when talking to non-LISP sites 413 [LISP-INTERWORK]; this is consistent with the design of any host at a 414 LISP site which talks to a host at a non-LISP site. 416 In general, the LISP-MN data-plane operates in the same manner as the 417 standard LISP data-plane with one exception: packets generated by a 418 LISP-MN which are not destined for the mapping system (i.e., those 419 sent to destination UDP port 4342) or the local network are LISP 420 encapsulated. Because data packets are always encapsulated to a 421 RLOC, packets travel on the shortest path from LISP-MN to another 422 LISP stationary or LISP-MN. When the LISP mobile node is sending 423 packets to a stationary or LISP-MN in a non-LISP site, it sends LISP- 424 encapsulated packets to a PETR which then decapsulates the packet and 425 forwards it to its destination. 427 6. Updating Remote Caches 429 A LISP-MN has five mechanisms it can use to cause the mappings cached 430 in remote ITRs and PITRs to be refreshed: 432 Map Versioning: If Map Versioning [LISP-VERSIONING] is used, an ETR 433 can detect if an ITR is using the most recent database mapping. 434 In particular, when mobile node's ETR decapsulates a packet and 435 detects the Destination Map-Version Number is less than the 436 current version for its mapping, in invokes the SMR procedure 437 described in [LISP]. In general, SMRs are used to fix the out of 438 sync mapping while Map-Versioning is used to detect they are out 439 of sync. [LISP-VERSIONING] provides additional details of the Map 440 Versioning process. 442 Data Driven SMRs: An ETR may elect to send SMRs to those sites it 443 has been receiving encapsulated packets from. This will occur 444 when an ITR is sending to an old RLOC (for which there is one-to- 445 one mapping between EID-to-RLOC) and the ETR may not have had a 446 chance to send an SMR the ITR. 448 Setting Small TTL on Map Replies: The ETR (or Map Server) may set a 449 small Time to Live (TTL) on its mappings when responding to Map 450 Requests. The TTL value should be chosen such that changes in 451 mappings can be detected while minimizing control traffic. In 452 this case the ITR is a SN and the ETR is the MN. 454 Piggybacking Mapping Data: If an ITR and ETR are co-located, an ITR 455 may elect to send Map-Requests with piggybacked mapping data to 456 those sites in its map cache or to which it has recently 457 encapsulated data in order to inform the remote ITRs and PITRs of 458 the change. 460 Temporary PITR Caching: The ETR can keep a cache of PITRs that have 461 sent Map-Requests to it. The cache contains the RLOCs of the 462 PITRs so later when the locator-set of a LISP-MN changes, SMR 463 messages can be sent to all RLOCs in the PITR cache. This is an 464 example of a control-plane driven SMR procedure. 466 7. Protocol Operation 468 There are five distinct connectivity cases considered by the LISP-MN 469 design. The five mobility cases are: 471 LISP Mobile Node to a Stationary Node in a LISP Site. 473 LISP Mobile Node to a Non-LISP Site. 475 LISP Mobile Node to a LISP Mobile Node. 477 Non-LISP Site to a LISP Mobile Node. 479 LISP Site to a LISP Mobile Node. 481 The remainder of this section covers these cases in detail. 483 7.1. LISP Mobile Node to a Stationary Node in a LISP Site 485 After a roaming event, a LISP-MN must immediately register its new 486 EID-to-RLOC mapping with its configured Map-Server(s). This allows 487 LISP sites sending Map-Requests to the LISP-MN to receive the current 488 mapping. In addition, remote ITRs and PITRs may have cached mappings 489 that are no longer valid. These ITRs and PITRs must be informed that 490 the mapping has changed. See Section 6 for a discussion of methods 491 for updating remote caches. 493 7.1.1. Handling Unidirectional Traffic 495 A problem may arise when traffic is flowing unidirectionally between 496 LISP sites. This can arise in communication flows between PITRs and 497 LISP sites or when a site's ITRs and ETRs are not co-located. In 498 these cases, data-plane techniques such as Map-Versioning and Data- 499 Driven SMRs can't be used to update the remote caches. 501 For example, consider the unidirectional packet flow case depicted in 502 Figure 1. In this case X is a non-LISP enabled SN (i.e., connected 503 to the Internet) and Y is a LISP MN. Data traffic from X to Y will 504 flow through a PITR. When Y changes its mapping (for example, during 505 a mobility event), the PITR must update its mapping for Y. However, 506 since data traffic from Y to X is unidirectional and does not flow 507 though the PITR, it can not rely data traffic from Y to X to signal a 508 mapping change at Y. In this case, the Y must use one or more of the 509 techniques described in Section 6 to update the PITR's cache. Note 510 that if Y has only one RLOC, then the PITR has to know when to send a 511 Map-Request based on its existing state; thus it can only rely on the 512 TTL on the existing mapping. 514 +-------------------------------------------+ 515 | | 516 | | DP 517 v DP DP MQ | 518 X -----> Internet -----> PITR ------------> Y 519 ^ LEDP | 520 | | 521 +-----------------+ 522 MR 524 DP: Data Packet 525 LEDP: LISP Encapsulated Data Packet 526 MQ: Map Request 527 MR: Map Reply 529 Figure 1: Unidirectional Packet Flow 531 7.2. LISP Mobile Node to a Non-LISP Stationary Node 533 LISP-MNs use the LISP Interworking infrastructure (specifically a 534 PETR) to reach non-LISP sites. In general, the PETR will be co- 535 located with the LISP-MN's Map-Server. This ensures that the LISP 536 packets being decapsulated are from sources that have Map-Registered 537 to the Map-Server. Note that when a LISP-MN roams it continues to 538 uses its configured PETR and Map-Server which can have the effect of 539 adding stretch to packets sent from a LISP-MN to a non-LISP 540 destination. 542 7.3. LISP Mobile Node to LISP Mobile Node 544 LISP-MN to LISP-MN communication is an instance of LISP-to-LISP 545 communication with three sub-cases: 547 o Both LISP-MNs are stationary (Section 7.1). 549 o Only one LISP-MN is roaming (Section 7.3.1). 551 o Both LISP-MNs are roaming. The case is analogous to the case 552 described in Section 7.3.1. 554 7.3.1. One Mobile Node is Roaming 556 In this case, the roaming LISP-MN can find the stationary LISP-MN by 557 sending Map-Request for its EID-prefix. After receiving a Map-Reply, 558 the roaming LISP-MN can encapsulate data packets directly to the non- 559 roaming LISP-MN node. 561 The roaming LISP-MN, on the other hand, must update its Map-Server 562 with the new mapping data as described in Section 7.1. It should 563 also use the cache management techniques described in Section 6 to 564 provide for timely updates of remote caches. Once the roaming 565 LISP-MN has updated its Map-Server, the non-roaming LISP-MN can 566 retrieve the new mapping data (if it hasn't already received an 567 updated mapping via one of the mechanisms described in Section 6) and 568 the stationary LISP-MN can encapsulate data directly to the roaming 569 LISP-MN. 571 7.4. Non-LISP Site to a LISP Mobile Node 573 When a stationary ITR is talking to a non-LISP site, it may forward 574 packets natively (unencapsulated) to the non-LISP site. This will 575 occur when the ITR has received a negative Map Reply for a prefix 576 covering the non-LISP site's address with the Natively-Forward action 577 bit set [LISP]. As a result, packets may be natively forwarded to 578 non-LISP sites by an ITR (the return path will through a PITR, 579 however, since the packet flow will be non-LISP site to LISP site). 581 A LISP-MN behaves differently when talking to non-LISP sites. In 582 particular, the LISP-MN always encapsulates packets to a PETR. The 583 PETR then decapsulates the packet and forwards it natively to its 584 destination. As in the stationary case, packets from the non-LISP 585 site host return to the LISP-MN through a PITR. Since traffic 586 forwarded through a PITR is unidirectional, a LISP-MN should use the 587 cache management techniques described in Section 7.1.1. 589 7.5. LISP Site to LISP Mobile Node 591 When a LISP-MN roams onto a new network, it needs to update the 592 caches in any ITRs that might have stale mappings. This is analogous 593 to the case in that a stationary LISP site is renumbered; in that 594 case ITRs that have cached the old mapping must be updated. This is 595 done using the techniques described in Section 6. 597 When a LISP router in a stationary site is performing both ITR and 598 ETR functions, a LISP-MN can update the stationary site's map-caches 599 using techniques described in Section 6. However, when the LISP 600 router in the stationary site is performing is only ITR 601 functionality, these techniques can not be used because the ITR is 602 not receiving data traffic from the LISP-MN. In this case, the 603 LISP-MN should use the technique described in Section 7.1.1. In 604 particular, a LISP-MN should set the TTL on the mappings in its Map- 605 Replies to be in 1-2 minute range. 607 8. Multicast and Mobility 609 Since a LISP-MN performs both ITR and ETR functionality, it should 610 also perform a lightweight version of multicast ITR/ETR functionality 611 described in [MLISP]. When a LISP-MN originates a multicast packet, 612 it will encapsulate the packet with a multicast header, where the 613 source address in the outer header is one of it's RLOC addresses and 614 the destination address in the outer header is the group address from 615 the inner header. The interfaces in which the encapsulated packet is 616 sent on is discussed below. 618 To not require PIM functionality in the LISP-MN as documented in 619 [MLISP], the LISP-MN resorts to using encapsulated IGMP for joining 620 groups and for determining which interfaces are used for packet 621 origination. When a LISP-MN joins a group, it obtains the map-cache 622 entry for the (S-EID,G) it is joining. It then builds a IGMP report 623 encoding (S-EID,G) and then LISP encapsulates it with UDP port 4341. 624 It selects an RLOC from the map-cache entry to send the encapsulated 625 IGMP Report. 627 When other LISP-MNs are joining an (S-EID,G) entry where the S-EID is 628 for a LISP-MN, the encapsulated IGMP Report will be received by the 629 LISP-MN multicast source. The LISP-MN multicast source will remember 630 the interfaces the encapsulated IGMP Report is received on and build 631 an outgoing interface list for it's own (S-EID,G) entry. If the list 632 is greater than one, then the LISP-MN is doing replication on the 633 source-based tree for which it is the root. 635 When other LISP routers are joining (S-EID,G), they are instructed to 636 send PIM encapsulated Join-Prune messages. However, to keep the 637 LISP-MN as simple as possible, the LISP-MN will not be able to 638 process encapsulated PIM Join-Prune messages. Because the map-cache 639 entry will have a MN-bit indicating the entry is for a LISP-MN, the 640 LISP router will send IGMP encapsulated IGMP Reports instead. 642 When the LISP-MN is sending a multicast packet, it can operate in two 643 modes, multicast-origination-mode or unicast-origination-mode. When 644 in multicast-origination-mode, the LISP-MN multicast-source can 645 encapsulate a multicast packet in another multicast packet, as 646 described above. When in unicast-origination-mode, the LISP-MN 647 multicast source encapsulates the multicast packet into a unicast 648 packet and sends a packet to each encapsulated IGMP Report sender. 650 These modes are provided depending on whether or not the mobile 651 node's network it is currently connected can support IP multicast. 653 9. RLOC Considerations 655 This section documents cases where the expected operation of the 656 LISP-MN design may require special treatment. 658 9.1. Mobile Node's RLOC is an EID 660 When a LISP-MN roams into a LISP site, the "RLOC" it is assigned may 661 be an address taken from the site's EID-prefix. In this case, the 662 LISP-MN will Map-Register a mapping from its statically assigned EID 663 to the "RLOC" it received from the site. This scenario creates 664 another level of indirection: the mapping from the LISP-MN's EID to a 665 site assigned EID. The mapping from the LISP-MN's EID to the site 666 assigned EID allow the LISP-MN to be reached by sending packets using 667 the mapping for the EID; packets are delivered to site's EIDs use the 668 same LISP infrastructure that all LISP hosts use to reach the site. 670 A packet egressing a LISP site destined for a LISP-MN that resides in 671 a LISP site will have three headers: an inner header that is built by 672 the host and is used by transport connections, a middle header that 673 is built by the site's ITR and is used by the destination's ETR to 674 find the current topological location of the LISP-MN, and an outer 675 header (also built by the site's ITR) that is used to forward packets 676 between the sites. 678 Consider a site A with EID-prefix 1.0.0.0/8 and RLOC A and a site B 679 with EID-prefix 2.0.0.0/8 and RLOC B. Suppose that a host S in site A 680 with EID 1.0.0.1 wants to talk to a LISP LISP-MN MN that has 681 registered a mapping from EID 240.0.0.1 to "RLOC" 2.0.0.2 (where 682 2.0.0.2 allocated from site B's EID prefix, 2.0.0.0/8 in this case). 683 This situation is depicted in Figure 2. 685 EID-prefix 1.0.0.0/8 EID-prefix 2.0.0.0/8 686 S has EID 1.0.0.1 MN has EID 240.0.0.1 687 MN has RLOC 2.0.0.2 688 -------------- -------------- 689 / \ --------------- / \ 690 | ITR-A' | / \ | ETR-B' | 691 | | | | | | 692 | S | | Internet | | MN | 693 | \ | | | | ^ | 694 | \ | | | | / | 695 | --> ITR-A | \ / | ETR-B ---- | 696 \ / --------------- \ / 697 -------------- -------------- 698 | | | ^ ^ ^ 699 | | | | | | 700 | | | outer-header: A -> B | | | 701 | | +---------------------------------------+ | | 702 | | RLOCs used to find which site MN resides | | 703 | | | | 704 | | | | 705 | | middle-header: A -> 2.0.0.2 | | 706 | +------------------------------------------------+ | 707 | RLOCs used to find topological location of MN | 708 | | 709 | | 710 | inner-header: 1.0.0.1 -> 240.0.0.1 | 711 +-----------------------------------------------------------+ 712 EIDs used for TCP connection 714 Figure 2: Mobile Node Roaming into a LISP Site 716 In this case, the inner header is used for transport connections, the 717 middle header is used to find topological location of the LISP-MN 718 (the LISP-MN Map-Registers the mapping 240.0.0.1 -> 2.0.0.2 when it 719 roams into site B), and the outer header is used to move packets 720 between sites (A and B in Figure 2). 722 In summary, when a LISP-MN roams into a LISP site and receives a new 723 address (e.g., via DHCP) that is part of the site's EID space, the 724 following sequence occurs: 726 1. The LISP-MN in the LISP site (call it Inside) registers its new 727 RLOC (which is actually part of the sites EID prefix) to its map- 728 server. Call its permanent EID E and the EID it DHCPs D. So it 729 registers a mapping that looks like E->D. 731 2. The MN which is outside (call it Outside) sends a map request for 732 inside's EID (E) and receives D (plus its policy). Outside 733 realizes that D is an EID and sends a map request for D. This 734 will return the site's RLOCs (by its ETR). Call this R. 736 3. Outside then double encapsulates the outbound packet with the 737 inner destination being D and the outer destination being R. 739 4. The packet then finds its way to R, which strips the outer header 740 and the packet is routed to D in the domain to Inside. Inside 741 decapsulates the packet to serve the inner header to the 742 application. 744 Note that both D and R could be returned to Inside in one query, so 745 as not to incur the additional RTT. 747 10. LISP Mobile Nodes behind NAT Devices 749 When a LISP-MN resides behind a NAT device, it will be allocated a 750 private RLOC address. The private RLOC address is used as the source 751 address in the outer header for LISP encapsulated packets. The NAT 752 device will translate the source address and source UDP port in the 753 LISP encapsulated packet. The NAT device will keep this translated 754 state so when packets arrive from the public side of the NAT, they 755 can be translated back to the stored state. For remote LISP ITRs, 756 PITRs, and RTRs, will need to know the translated RLOC address and 757 port so they can encapsulate to the LISP-MN traversing the NAT 758 device. 760 Procedures a LISP-MN should follow when it resides behind a NAT, will 761 follow the LISP xTRs procedures in specification [LISP-NATT]. 763 11. Mobility Example 765 This section provides an example of how the LISP-MN is integrated 766 into the base LISP Design [LISP]. 768 11.1. Provisioning 770 The LISP-MN needs to be configured with the following information: 772 An EID, assigned to its loopback address 774 A key for map-registration 775 An IP address of a Map-Resolver (this could be learned 776 dynamically) 778 An IP address of its Map-Server and Proxy ETR 780 11.2. Registration 782 After a LISP roams to a new network, it must immediately register its 783 new mapping this new RLOC (and associated priority/weight data) with 784 its Map-Server. 786 The LISP-MN may chose to set the 'proxy' bit in the map-register to 787 indicate that it desires its Map-Server to answer map-requests on its 788 behalf. 790 12. LISP Implementation in a Mobile Node 792 This section will describe a possible approach for developing a 793 lightweight LISP-MN implementation. A LISP-MN will implement a LISP 794 sub-layer inside of the IP layer of the protocol stack. The sub- 795 layer resides between the IP layer and the link-layer. 797 For outgoing unicast packets, once the header that contains EIDs is 798 built and right before an outgoing interface is chosen, a LISP header 799 is prepended to the outgoing packet. The source address is set to 800 the local RLOC address (obtained by DHCP perhaps) and the destination 801 address is set to the RLOC associated with the destination EID from 802 the IP layer. To obtain the RLOC for the EID, the LISP-MN maintains 803 a map-cache for destination sites or destination LISP-MNs to which it 804 is currently talking. The map-cache lookup is performed by doing a 805 longest match lookup on the destination address the IP layer put in 806 the first IP header. Once the new header is prepended, a route table 807 lookup is performed to find the interface in which to send the packet 808 or the default router interface is used to send the packet. 810 When the map-cache does not exist for a destination, the mobile node 811 may queue or drop the packet while it sends a Map-Request to it's 812 configured Map-Resolver. Once a Map-Reply is returned, the map-cache 813 entry stores the EID-to-RLOC state. If the RLOC state is empty in 814 the Map-Reply, the Map-Reply is known as a Negative Map-Reply in 815 which case the map-cache entry is created with a single RLOC, the 816 RLOC of the configured Map-Server for the LISP-MN. The Map-Server 817 that serves the LISP-MN also acts as a Proxy ETR (PETR) so packets 818 can get delivered to hosts in non-LISP sites to which the LISP-MN is 819 sending. 821 For incoming unicast packets, the LISP sub-layer simply decapsulates 822 the packets and delivers to the IP layer. The loc-reach-bits can be 823 processed by the LISP sub-layer. Specifically, the source EID from 824 the packet is looked up in the map-cache and if the loc-reach-bits 825 settings have changed, store the loc-reach-bits from the packet and 826 note which RLOCs for the map-cache entry should not be used. 828 In terms of the LISP-MN detecting which RLOCs from each stored map- 829 cache entry is reachable, it can use any of the Locator Reachability 830 Algorithms from [LISP]. 832 A background task that runs off a timer should be run so the LISP-MN 833 can send periodic Map-Register messages to the Map-Server. The Map- 834 Register message should also be triggered when the LISP-MN detects a 835 change in IP address for a given interface. The LISP-MN should send 836 Map-Registers to the same Map-Register out each of it's operational 837 links. This will provide for robustness on radio links with which 838 the mobile node is associated. 840 A LISP-MN receives a Map-Request when it has Map-Registered to a Map- 841 Server with the Proxy-bit set to 0. This means that the LISP-MN 842 wishes to send authoritative Map-Replies for Map-Requests that are 843 targeted at the LISP-MN. If the Proxy-bit is set when the LISP-MN 844 registers, then the Map-Server will send non-authoritative Map- 845 Replies on behalf of the LISP-MN. In this case, the Map-Server never 846 encapsulates Map-Requests to the LISP-MN. The LISP-MN can save 847 resources by not receiving Map-Requests (note that the LISP-MN will 848 receive SMRs which have the same format as Map-Requests). 850 To summarize, a LISP sub-layer should implement: 852 o Encapsulating and decapsulating data packets. 854 o Sending and receiving of Map-Request control messages. 856 o Receiving and optionally sending Map-Replies. 858 o Sending Map-Register messages periodically. 860 The key point about the LISP sub-layer is that no other components in 861 the protocol stack need changing; just the insertion of this sub- 862 layer between the IP layer and the interface layer-2 encapsulation/ 863 decapsulation layer. 865 13. Security Considerations 867 Security for the LISP-MN design builds upon the security fundamentals 868 found in LISP [LISP] for data-plane security and the LISP Map Server 870 [LISP-MS] registration security. Security issues unique to the 871 LISP-MN design are considered below. 873 13.1. Proxy ETR Hijacking 875 The Proxy ETR (or PETR) that a LISP-MN uses as its destination for 876 non-LISP traffic must use the security association used by the 877 registration process outlined in Section 5.2 and explained in detail 878 in the LISP-MS specification [LISP-MS]. These measures prevent third 879 party injection of LISP encapsulated traffic into a Proxy ETR. 880 Importantly, a PETR must not decapsulate packets from non-registered 881 RLOCs. 883 13.2. LISP Mobile Node using an EID as its RLOC 885 For LISP packets to be sent to a LISP-MN which has an EID assigned to 886 it as an RLOC as described in Section 9.1), the LISP site must allow 887 for incoming and outgoing LISP data packets. Firewalls and stateless 888 packet filtering mechanisms must be configured to allow UDP port 4341 889 and UDP port 4342 packets. 891 14. Acknowledgments 893 Albert Cabellos, Noel Chiappa, Pierre Francois, Michael Menth, Andrew 894 Partan, Chris White and John Zwiebel provided insightful comments on 895 the mobile node concept and on this document. A special thanks goes 896 to Mary Nickum for her attention to detail and effort in editing 897 early versions of this document. 899 15. IANA Considerations 901 This document creates no new requirements on IANA namespaces 902 [RFC5226]. 904 16. References 906 16.1. Normative References 908 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 909 E. Lear, "Address Allocation for Private Internets", 910 BCP 5, RFC 1918, February 1996. 912 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 913 RFC 2131, March 1997. 915 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 916 August 2002. 918 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 919 in IPv6", RFC 3775, June 2004. 921 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 922 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 923 May 2008. 925 16.2. Informative References 927 [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 928 "Locator/ID Separation Protocol (LISP)", 929 draft-ietf-lisp-23.txt (work in progress), May 2012. 931 [LISP-ALT] 932 Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP 933 Alternative Topology (LISP-ALT)", 934 draft-ietf-lisp-alt-10.txt (work in progress), 935 December 2011. 937 [LISP-INTERWORK] 938 Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 939 "Interworking LISP with IPv4 and IPv6", 940 draft-ietf-lisp-interworking-06.txt (work in progress), 941 March 2012. 943 [LISP-MS] Farinacci, D. and V. Fuller, "LISP Map Server", 944 draft-ietf-lisp-ms-16.txt (work in progress), March 2012. 946 [LISP-NATT] 947 Ermagan, V., Fariancci, D., Lewis, D., Skriver, J., and F. 948 Maino, "NAT traversal for LISP", 949 draft-ermagen-lisp-nat-traversal-02.txt (work in 950 progress), September 2012. 952 [LISP-VERSIONING] 953 Iannone, L., Saucez, D., and O. Bonaventure, "LISP Mapping 954 Versioning", draft-ietf-lisp-map-versioning-09.txt (work 955 in progress), March 2012. 957 [MLISP] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, 958 "LISP for Multicast Environments", 959 draft-ietf-lisp-multicast-14.txt (work in progress), 960 February 2012. 962 Authors' Addresses 964 Dino Farinacci 965 cisco Systems 966 Tasman Drive 967 San Jose, CA 95134 968 USA 970 Email: dino@cisco.com 972 Darrel Lewis 973 cisco Systems 974 Tasman Drive 975 San Jose, CA 95134 976 USA 978 Email: darlewis@cisco.com 980 David Meyer 981 1-4-5.net 982 USA 984 Email: dmm@1-4-5.net 986 Chris White 987 Logical Elegance, LLC. 988 San Jose, CA 95134 989 USA 991 Email: chris@logicalelegance.com