idnits 2.17.1 draft-meyer-lisp-mn-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 25 instances of too long lines in the document, the longest one being 7 characters in excess of 72. == There are 12 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 2, 2010) is 5014 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'LIG' is defined on line 871, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-lisp-lig-00 == Outdated reference: A later version (-24) exists of draft-ietf-lisp-08 == Outdated reference: A later version (-10) exists of draft-ietf-lisp-alt-04 == Outdated reference: A later version (-06) exists of draft-ietf-lisp-interworking-00 == Outdated reference: A later version (-14) exists of draft-ietf-lisp-multicast-03 == Outdated reference: A later version (-16) exists of draft-ietf-lisp-ms-05 -- No information found for draft-x-lisp-nat-traversal - is the name correct? ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3220 (Obsoleted by RFC 3344) Summary: 4 errors (**), 0 flaws (~~), 9 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 V. Fuller 4 Intended status: Informational D. Lewis 5 Expires: February 3, 2011 D. Meyer 6 Cisco Systems, Inc. 7 August 2, 2010 9 LISP Mobile Node 10 draft-meyer-lisp-mn-03.txt 12 Abstract 14 This document describes how a lightweight version of LISP's ITR/ETR 15 functionality can be used to provide seamless mobility to a mobile 16 node. The LISP Mobility Architecture uses standard LISP 17 functionality to provide scalable mobility for LISP mobile nodes. 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on February 3, 2011. 42 Copyright Notice 44 Copyright (c) 2010 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the BSD License. 57 Table of Contents 59 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 60 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 62 4. Architecture Overview . . . . . . . . . . . . . . . . . . . . 6 63 5. Design Requirements . . . . . . . . . . . . . . . . . . . . . 6 64 5.1. User Requirements . . . . . . . . . . . . . . . . . . . . 6 65 5.2. Network Requirements . . . . . . . . . . . . . . . . . . . 7 66 6. LISP Mobile Node Operation . . . . . . . . . . . . . . . . . . 7 67 6.1. Addressing Architecture . . . . . . . . . . . . . . . . . 8 68 6.2. Control Plane Operation . . . . . . . . . . . . . . . . . 8 69 6.3. Data Plane Operation . . . . . . . . . . . . . . . . . . . 9 70 7. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 10 71 7.1. LISP Mobile Node to a Stationary Node in a LISP Site . . . 10 72 7.1.1. Handling Unidirectional Traffic . . . . . . . . . . . 10 73 7.2. LISP Mobile Node to a Non-LISP Stationary Node . . . . . . 11 74 7.3. LISP Mobile Node to LISP Mobile Node . . . . . . . . . . . 12 75 7.3.1. One Mobile Node is Roaming . . . . . . . . . . . . . . 12 76 7.3.2. Both Mobile Nodes are Roaming . . . . . . . . . . . . 12 77 7.4. Non-LISP Site to a LISP Mobile Node . . . . . . . . . . . 13 78 7.5. LISP Site to LISP Mobile Node . . . . . . . . . . . . . . 13 79 8. Multicast and Mobility . . . . . . . . . . . . . . . . . . . . 13 80 9. RLOC Considerations . . . . . . . . . . . . . . . . . . . . . 14 81 9.1. Mobile Node's RLOC is not Globally Routable . . . . . . . 14 82 9.2. Mobile Node's RLOC is an EID . . . . . . . . . . . . . . . 15 83 10. Mobility Example . . . . . . . . . . . . . . . . . . . . . . . 16 84 10.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . . 17 85 10.2. Registration . . . . . . . . . . . . . . . . . . . . . . . 17 86 11. LISP Implementation in a Mobile Node . . . . . . . . . . . . . 17 87 12. Security Considerations . . . . . . . . . . . . . . . . . . . 19 88 12.1. Proxy ETR Hijacking . . . . . . . . . . . . . . . . . . . 19 89 12.2. LISP mobile node using an EID as its RLOC . . . . . . . . 19 90 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 91 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 92 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 93 15.1. Normative References . . . . . . . . . . . . . . . . . . . 20 94 15.2. Informative References . . . . . . . . . . . . . . . . . . 21 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 97 1. Requirements Notation 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [RFC2119]. 103 2. Introduction 105 The Locator/ID Separation Protocol (LISP) [LISP] specifies an 106 architecture and mechanism for replacing the addresses currently used 107 in the Internet with two separate name spaces: Endpoint Identifiers 108 (EIDs), used within sites, and Routing Locators (RLOCs), used by the 109 transit networks that make up the Internet infrastructure. To 110 achieve this separation, LISP defines protocol mechanisms for mapping 111 from EIDs to RLOCs. The currently deployed mapping infrastructure is 112 comprised of LISP Map-Servers and Map-Resolvers [LISP-MS], and is 113 tied together with LISP+ALT [LISP-ALT]. 115 This document specifies the behavior of a new LISP network element: 116 the LISP Mobile Node in which a subset of LISP functionality can be 117 implemented to provide mobile node roaming. 119 A LISP mobile node implements lightweight Ingress Tunnel Router and 120 Egress Tunnel Router functionality. Design goals for the LISP 121 mobility architecture include: 123 o Keeping TCP connections alive while roaming. 125 o Allowing the mobile node to communicate with other mobile nodes 126 while either or both are roaming. 128 o Allowing the mobile node to multi-home (i.e., use multiple 129 interfaces concurrently). 131 o Allow the mobile node to be a server. That is, any mobile node or 132 stationary node can find and connect to a mobile node as a server. 134 o Provide shortest path bidirectional data paths between a mobile 135 node and any other stationary or mobile node. 137 o Does not require fine-grained routes in the core network. 139 o Does not require home-agent or foreign agent network elements (and 140 hence no triangle routing is required in the data plane 141 [RFC3220]). 143 The LISP mobility architecture requires that the network use LISP 144 Map-Server [LISP-MS] and LISP Interworking [LISP-IW] technology to 145 allow a LISP mobile node to roam and to be discovered in an efficient 146 and scalable manner. 148 The protocol mechanisms described in this document apply those cases 149 in which a node's IP address changes frequently. For example, when a 150 mobile node roams, it is typically assigned a new IP address (i.e., 151 one of its IP address changes). Similarly, a broadband subscriber 152 may have its address change frequently; as such, a broadband 153 subscriber can use the LISP Mobile Node mechanisms defined in this 154 specification. 156 The remainder of this document is organized as follows: Section 3 157 defines the terms used in this document. Section 4 provides a 158 overview of salient features of the LISP-MN architecture, and 159 Section 5 describes design requirements for the LISP-MN architecture, 160 Section 6 provides the detail of LISP-MN data and control plane 161 operation. Section 7 specifies how the LISP-MN protocol operates. 162 Section 8 specifies multicast operation for LISP mobile nodes, and 163 Section 9 lists other considerations for the LISP-MN architecture. 164 Section 12 outlines the security considerations for a LISP mobile 165 node. Finally, Section 11 specifies the LISP implementation which 166 resides in a mobile node. 168 3. Definition of Terms 170 This section defines the terms used in this document. 172 Stationary Node (SN): A non-mobile node who's IP address remains 173 relatively unchanged. That is, its IP address does not change as 174 frequently as a fast roaming mobile hand-set or broadband 175 connection. 177 Endpoint ID (EID): This is the traditional LISP EID [LISP], and is 178 the address that a LISP mobile node uses as its address for 179 transport connections. A LISP mobile node never changes its EID, 180 which is typically a /32 or /128 prefix and is assigned to a 181 loopback interface. Note that the mobile node can have multiple 182 EIDs, and these EIDs can be from different address families. 184 Routing Locator (RLOC): This is the traditional LISP RLOC, and is a 185 routable address that can be used to reach a mobile node. 187 Ingress Tunnel Router (ITR): An ITR is a router that accepts an IP 188 packet with a single IP header (more precisely, an IP packet that 189 does not contain a LISP header). The router treats this "inner" 190 IP destination address as an EID and performs an EID-to-RLOC 191 mapping lookup. The router then prepends an "outer" IP header 192 with one of its globally routable RLOCs in the source address 193 field and the result of the mapping lookup in the destination 194 address field. Note that this destination RLOC may be an 195 intermediate, proxy device that has better knowledge of the EID- 196 to-RLOC mapping closer to the destination EID. In general, an ITR 197 receives IP packets from site end-systems on one side and sends 198 LISP-encapsulated IP packets toward the Internet on the other 199 side. A LISP mobile node, however, when acting as an ITR LISP 200 encapsulates all packet that it originates. 202 Egress Tunnel Router (ETR): An ETR is a router that accepts an IP 203 packet where the destination address in the "outer" IP header is 204 one of its own RLOCs. The router strips the "outer" header and 205 forwards the packet based on the next IP header found. In 206 general, an ETR receives LISP-encapsulated IP packets from the 207 Internet on one side and sends decapsulated IP packets to site 208 end-systems on the other side. A LISP mobile node, when acting as 209 an ETR, decapsulates packets that are then typically processed by 210 the mobile node. 212 LISP Mobile Node Architecture (LISP-MN Architecture): An 213 architecture which uses LISP to provide fast roaming for mobile 214 hand-sets. 216 LISP Mobile Node: A LISP capable fast roaming mobile hand-set. 218 Proxy ETR (PETR): An infrastructure element used to decapsulate 219 packets sent from mobile nodes non-LISP sites. Proxy ETRs are 220 described in [LISP-IW]. 222 Map-cache: A data structure which contains an EID-prefix, its 223 associated RLOCs, and the associated policy. Map-cache's are 224 typically found in ITRs and PTRs. 226 Negative Map-Reply: A Negative Map-Reply is a Map-Reply that 227 contains a coarsely aggregated non-LISP prefix. Negative Map- 228 Replies are typically generated by Map-Resolvers, and are used to 229 inform an ITR (mobile or stationary) that a site is not a LISP 230 site. A LISP mobile node encapsulate packets to destinations 231 covered by the negative Map-Reply are encapsulated to a PETR. 233 Proxy Tunnel Router (PTR): PTRs are used to provide 234 interconnectivity between sites that use LISP EIDs and those that 235 do not. They act as a gateway between the Legacy Internet and the 236 LISP enabled Network. A given PTR advertises one or more highly 237 aggregated EID prefixes into the public Internet and acts as the 238 ITR for traffic received from the public Internet. Proxy Tunnel 239 Routers are described in [LISP-IW]. 241 Roaming Event: A Roaming Event occurs when there is a change in a 242 LISP mobile node's RLOC set. 244 4. Architecture Overview 246 The LISP-MN architecture described in this document uses the Map- 247 Server/Map-Resolver service interface in conjunction with a light- 248 weight ITR/ETR implementation in the mobile node to provide scalable 249 fast mobility. The LISP-MN control-plane uses a Map-Server as an 250 anchor point, which provides control-plane scalability. In addition, 251 the LISP-MN data-plane takes advantage of shortest path routing, and 252 therefore does not increase packet delivery latency. 254 5. Design Requirements 256 This section outlines the design requirements for the LISP-MN 257 architecture, and is divided into User Requirements (Section 5.1) and 258 Network Requirements (Section 5.2). 260 5.1. User Requirements 262 This section describes the user functionality that the LISP-MN 263 architecture provides to a LISP mobile node. 265 Transport Connection Survivability: The LISP-MN architecture MUST 266 allow a LISP mobile node to roam while keeping transport 267 connections alive. 269 Simultaneous Roaming: The LISP-MN architecture MUST allow a LISP 270 mobile node to talk to another LISP mobile node while both are 271 roaming. 273 Multihoming: The LISP-MN architecture MUST allow for simultaneous 274 use of multiple Internet connections by a LISP mobile node. In 275 addition, the architecture MUST allow for the LISP mobile node to 276 specify ingress traffic engineering policies as documented in 277 [LISP]. That is, the mobile node must be able to specify both 278 active/active and active/passive policies for ingress traffic. 280 Shortest Path Data Plane: The LISP-MN architecture MUST allow for 281 shortest path bidirectional traffic between a LISP mobile node and 282 a stationary node, and between a LISP mobile node and another LISP 283 mobile node (i.e., without triangle routing in the data path). 284 This provides a low-latency data path between the LISP mobile node 285 and the nodes that it is communicating with. 287 5.2. Network Requirements 289 This section describes the network functionality that the LISP-MN 290 architecture provides to a LISP mobile node. 292 Routing System Scalability: The LISP-MN architecture MUST NOT 293 require injection of fine-grained routes into the core network. 295 Mapping System Scalability: The LISP-MN architecture MUST NOT 296 require additional state in the mapping system. In particular, 297 any mapping state required to support LISP mobility MUST BE 298 confined to the LISP mobile node's Map-Server and the ITRs which 299 are talking to the LISP mobile node. 301 Component Reuse: The LISP-MN architecture MUST use existing LISP 302 infrastructure components. 304 Home Agent/Foreign Agent: The LISP-MN architecture MUST NOT require 305 the use of home-agent or foreign-agent infrastructure components 306 [RFC3220]. 308 Readdressing: The LISP-MN architecture MUST NOT require TCP 309 connections to be reset when the mobile node roams. In 310 particular, since the IP address associated with a transport 311 connection will not change as the mobile node roams, TCP 312 connections not reset. 314 6. LISP Mobile Node Operation 316 The LISP-MN architecture is built from three existing LISP 317 components: A very lightweight implementation of LISP that runs in an 318 LISP mobile node, and the existing Map-Server [LISP-MS] and 319 Interworking [LISP-IW] infrastructures. A LISP mobile node typically 320 sends and receives LISP encapsulated packets (exceptions include 321 management protocols such as DHCP). 323 The LISP-MN architecture makes a single mobile node look like a LISP 324 site in accordance with the LISP architecture as defined in [LISP]. 325 The mobile node implements ITR and ETR functionality. All packets 326 the mobile node originates are LISP encapsulated, and all packets 327 received by a LISP mobile node will be LISP encapsulated. 329 When a mobile node roams onto a new network, it receives a new RLOC. 330 Since the mobile node is an authoritative ETR for its EID-prefix, it 331 MUST Map-Register it's updated RLOC set. As soon as the registration 332 is complete, new sessions can be established immediately. Sessions 333 that are encapsulating to RLOCs that did not change during the 334 roaming event are not by the roaming event (or subsequent mapping 335 update). Finally, the mobile node MUST update the ITRs and PTRs that 336 have cached a previous mapping. It does this using the techniques 337 described in Section 6.2. 339 6.1. Addressing Architecture 341 A LISP mobile node is typically statically provisioned with an EID 342 that it uses for all transport connections. This EID will change 343 infrequently (if at all; assignment of a LISP mobile node's EID is is 344 typically a subscription time event). The key point is that the 345 relatively fixed EID allows the LISP mobile node's transport 346 connections to survive roaming events. As usual, an EID can be 347 either an IPv4 or an IPv6 address. The LISP mobile node's RLOC set 348 changes dynamically during roaming events, and the RLOC set can 349 contain both IPv4 or IPv6 addresses. 351 A LISP mobile node is also statically provisioned with the address of 352 a Map-Server and with a corresponding authentication key. Like the 353 mobile node's EID, both the Map-Server address and authentication key 354 change very infrequently (again, these are anticipated to be 355 subscription time parameters). Since the LISP mobile node's Map- 356 Server is configured to advertise an aggregated EID-prefix that 357 covers the LISP mobile node's EID, changes to the LISP mobile node's 358 mapping are not propagated further into the mapping system. This 359 property provides for scalable fast mobility. 361 A LISP mobile node is also be provisioned with the address of a Map- 362 Resolver. A mobile node may also learn the address of a Map-Resolver 363 though a dynamic protocol such as DHCP [RFC2131]. 365 Finally, note that if, for some reason, a mobile node's EID is re- 366 provisioned, the mobile node's Map-Server address may also have to 367 change in order to keep mobile node's EID within the aggregate 368 advertised by the Map-Server (this is discussed in greater detail in 369 Section 6.2). 371 6.2. Control Plane Operation 373 A roaming event occurs when the LISP mobile node receives a new RLOC. 374 Because the new address is a new RLOC from the LISP mobile node's 375 perspective, it must update its EID-to-RLOC mapping with its Map- 376 Server; it does this using the Map-Register mechanism described in 377 [LISP]. 379 Note that a LISP mobile node may or may not respond to Map-Requests. 381 In particular, a LISP mobile node MAY instruct its Map-Server to 382 proxy respond to Map-Requests by setting the Proxy-Map-Reply bit in 383 the Map-Register message [LISP]. In this case the Map-Server 384 responds with a non-authoritative Map-Reply so that an ITR or PTR 385 will know that the ETR didn't directly respond. A mobile node may 386 want the Map-Server to respond on its behalf for a variety of 387 reasons, including minimizing control traffic on radio links and 388 minimizing battery utilization. 390 Because the mobile node's Map-Server is pre-configured to advertise 391 an aggregate covering the LISP mobile node's EID prefix, the database 392 mapping change associated with the roaming event is confined to the 393 Map-Server and those ITRs that have cached the previous mapping. The 394 LISP mobile node can cause the mappings cached in remote ITRs to be 395 refreshed by using small Time To Live (TTL) on its mappings, sending 396 Map-Requests with piggybacked mapping data, or by setting the Solicit 397 Map Request (SMR) bit in subsequent data packets. 399 If a LISP mobile node does not have a mapping for a destination it 400 wants to communicate with, it sends a Map-Request to its Map-Resolver 401 as detailed in [LISP-MS]. The mobile node respects the priority and 402 weights of the destination LISP site's mapping and as such adheres to 403 the policy of the destination site. Finally, if the destination 404 address matches a negative map-cache entry, the mobile node 405 encapsulates the matching packets to a PETR. 407 6.3. Data Plane Operation 409 A key feature of LISP-MN control-plane architecture is the use of the 410 Map-Server as an anchor point; this allows control of the scope to 411 which changes to the mapping system must be propagated during roaming 412 events. 414 The LISP-MN data-plane architecture, on the other hand, does not rely 415 on additional LISP infrastructure for communication between LISP 416 nodes (mobile or stationary). Data packets take the shortest path to 417 and from the mobile node to other LISP nodes; as noted above, low 418 latency shortest paths in the data-plane is an important goal for the 419 LISP-MN architecture (and is important for delay-sensitive 420 applications like gaming and voice-over-IP). Note that a LISP mobile 421 node will need additional interworking infrastructure when talking to 422 non-LISP sites [LISP-IW]; this is consistent with the design of any 423 host at a LISP site which talks to a host at a non-LISP site. 425 In general, the LISP mobile node data-plane operates in the same 426 manner as the standard LISP data-plane with one exception: all 427 packets generated by a LISP mobile node are LISP encapsulated. 428 Because data packets are always encapsulated to a RLOC, packets 429 travel on the shortest path from LISP mobile node to another LISP 430 stationary or mobile node. When the LISP mobile node is sending 431 packets to a stationary or mobile node in a non-LISP site, it sends 432 LISP-encapsulated packets to a PETR which then decapsulates the 433 packet and forwards it to its destination. 435 7. Protocol Operation 437 There are five distinct connectivity cases considered by the LISP-MN 438 architecture. The five mobility cases are: 440 LISP Mobile Node to a Stationary Node in a LISP Site. 442 LISP Mobile Node to a Non-LISP Site. 444 LISP Mobile Node to a LISP Mobile Node. 446 Non-LISP Site to a LISP Mobile Node. 448 LISP Site to a LISP Mobile Node. 450 The remainder of this section covers these cases in detail. 452 7.1. LISP Mobile Node to a Stationary Node in a LISP Site 454 After a roaming event, a LISP mobile node MUST immediately register 455 its EID-to-RLOC mapping with its configured Map-Server(s). This 456 allows LISP sites sending Map-Requests to the LISP mobile node to 457 receive the current mapping. 459 On the other hand, ITRs and PTRs which may have cached previous 460 mappings must be informed that the mapping has changed. A LISP 461 mobile node MAY use the SMR bit on data packets it is sending to LISP 462 sites, or it MAY send a Map-Request with Map-Data to update active 463 ITRs to effect this update. 465 7.1.1. Handling Unidirectional Traffic 467 A problem may arise when traffic is flowing unidirectionally between 468 sites. In this case, data-plane techniques such as setting the SMR 469 bit to update the mappings can't be used. 471 For example, consider the "square routing" packet flow case depicted 472 in Figure 1. In this case, a host X with site border routers A and B 473 wants to send packets to a host Y with site border routers C and D. 474 Suppose that X has a default route pointing at A, and that A forwards 475 traffic for Y to C (which then forwards it on it on to Y). Y also 476 has a default route that points at D, which forwards traffic destined 477 for X to B. In this scenario, routers A, B, C, and D see only 478 unidirectional traffic between hosts X and Y. 480 If X is a LISP mobile node and B is a ITR (or PTR), the mobile node 481 can't use the data-plane techniques described in Section 7.1 to 482 update the PTR's mapping because the mobile node forwards neither 483 data nor control traffic to the PTR. Thus the ITR's map-cache entry 484 for the mobile node will have to have its TTL expire before it can 485 learn a new mapping for the mobile node. As a result, LISP mobile 486 SHOULD set the TTL on the mappings in its Map-Replies to be in the 487 1-2 minute range. 489 Source Destination 490 Site Core Site 491 \ / 492 \ / 493 +----> A | --------------> | C ------+ 494 | | | | 495 X | | Y 496 ^ | | | 497 +----- B | <-------------- | D <-----+ 498 / \ 499 / \ 501 Figure 1: Square Routing Packet Flow 503 7.2. LISP Mobile Node to a Non-LISP Stationary Node 505 LISP mobile nodes use the LISP Interworking infrastructure 506 (specifically a PETR) to reach non-LISP sites. In general, the PETR 507 will be co-located with the LISP mobile node's Map-Server. This 508 ensures that the LISP packets being decapsulated are from sources 509 that have Map-Registered to the Map-Server. A LISP mobile node MAY 510 install a default map-cache entry that points at a PETR for use with 511 negative Map-Replies. 513 When a LISP mobile node roams, it continues to uses its configured 514 PETR and Map-Server. This may add stretch to packets sent from a 515 LISP mobile node to a non-LISP destination. 517 7.3. LISP Mobile Node to LISP Mobile Node 519 LISP mobile node to LISP mobile node communication is an instance of 520 LISP-to-LISP communication with three sub-cases: 522 o Both LISP mobile nodes are stationary. This is covered in 523 Section 7.1. 525 o Only one LISP mobile node is roaming. This is covered in 526 Section 7.3.1. 528 o Both LISP mobile nodes are roaming. This is covered in 529 Section 7.3.2 531 7.3.1. One Mobile Node is Roaming 533 In this case, the roaming mobile mode can find the stationary mobile 534 node by sending Map-Request for its EID-prefix. After receiving a 535 Map-Reply, the roaming node can encapsulate data packets directly to 536 the non-roaming mobile node node. 538 The roaming mobile node, on the other hand, MUST update its Map- 539 Server with the new mapping data as described in Section 7.1. It MAY 540 also use the cache management techniques described in Section 7.1 to 541 provide for timely updates of remote ITR caches. Once the roaming 542 mobile node has updated its Map-Server, the non-roaming mobile node 543 can retrieve the new mapping data (if it hasn't already received an 544 updated mapping via one of the mechanisms described in Section 7.1) 545 and the stationary mobile node can encapsulate data directly to the 546 roaming mobile node. 548 7.3.2. Both Mobile Nodes are Roaming 550 When both mobile nodes are roaming, they both will both receive new 551 RLOCs, and as a result both need register their new mappings to their 552 Map Servers. However, because both mobile node's map-cache entries 553 contain old RLOCs, neither can update the other using the data-plane 554 techniques described in Section 7.1. 556 A mobile node can, however, force itself to issue Map-Requests by 557 clearing its map-cache. These Map-Requests MAY contain the updated 558 mapping information for the mobile node. Hence a LISP mobile node 559 MUST clear its map-cache whenever it roams onto a new network (i.e., 560 receives a new RLOC). This will cause the mobile node to issue a new 561 Map-Request the next time it sends a data packet to the other mobile 562 node. The Map-Request will follow the mapping infrastructure to the 563 new location of the correspondent mobile node. 565 7.4. Non-LISP Site to a LISP Mobile Node 567 Hosts in non-LISP sites talk to other LISP hosts, whether mobile or 568 stationary, using the PTR infrastructure. Because LISP mobile nodes 569 always encapsulate packets, though subtle the behave differently than 570 as described in [LISP-IW]. In particular, stationary ITRs do not 571 encapsulate packets to a non-LISP host while LISP mobile node do. A 572 PETR is required to decapsulated those packets that are destined from 573 the LISP mobile node to a non-LISP host. Packets from the non-LISP 574 site host return to the mobile node through a PTR, which non-LISP 575 encapsulates packets to the mobile node. Inasmuch as all traffic 576 forwarded through a PTR is unidirectional traffic, a mobile node 577 should use the technique described in Section 7.1.1. In particular, 578 a LISP mobile node SHOULD set the TTL on the mappings in its Map- 579 Replies to be in 1-2 minute range. 581 7.5. LISP Site to LISP Mobile Node 583 When a mobile node roams onto a new network, it needs to update the 584 caches in any ITRs that might have stale mappings. This is analogous 585 to the case in that a stationary LISP site is renumbered; in that 586 case ITRs that have cached the old mapping must be updated. This is 587 done using the techniques described in Section 7.1. 589 When a LISP router in a stationary site is performing both ITR and 590 ETR functions, a mobile node can update the stationary site's map- 591 caches using techniques described in Section 7.1. However, when the 592 LISP router in the stationary site is performing is only ITR 593 functionality, these techniques can not be used because the ITR is 594 not receiving data traffic from the mobile node. In this case, the 595 mobile node should use the technique described in Section 7.1.1. In 596 particular, a LISP mobile node SHOULD set the TTL on the mappings in 597 its Map-Replies to be in 1-2 minute range. 599 8. Multicast and Mobility 601 Inasmuch as a mobile node performs both ITR and ETR functionality, it 602 should also perform a lightweight version of multicast ITR/ETR 603 functionality described in [LISP-MCAST]. When a mobile node 604 originates a multicast packet, it will encapsulate the packet with a 605 multicast header, where the source address in the outer header is one 606 of it's RLOC addresses and the destination address in the outer 607 header is the group address from the inner header. The interfaces in 608 which the encapsulated packet is sent on is discussed below. 610 To not require PIM functionality in the LISP mobile node as 611 documented in [LISP-MCAST], the LISP mobile node resorts to using 612 encapsulated IGMP for joining groups and for determining which 613 interfaces are used for packet origination. When a LISP mobile node 614 joins a group, it obtains the map-cache entry for the (S-EID,G) it is 615 joining. It then builds a IGMP report encoding (S-EID,G) and then 616 LISP encapsulates it with UDP port 4341. It selects an RLOC from the 617 map-cache entry to send the encapsulated IGMP Report. 619 When other LISP mobile nodes are joining an (S-EID,G) entry where the 620 S-EID is for a LISP mobile node, the encapsulated IGMP Report will be 621 received by the mobile node multicast source. The mobile node 622 multicast source will remember the interfaces the encapsulated IGMP 623 Report is received on and build an outgoing interface list for it's 624 own (S-EID,G) entry. If the list is greater than one, then the 625 mobile node is doing replication on the source-based tree for which 626 it is the root. 628 When other LISP routers are joining (S-EID,G), they are instructed to 629 send PIM encapsulated Join-Prune messages. However, to keep the 630 mobile node as simple as possible, the mobile node will not be able 631 to process encapsulated PIM Join-Prune messages. Because the map- 632 cache entry will have a MN-bit indicating the entry is for a mobile 633 node, the LISP router will send IGMP encapsulated IGMP Reports 634 instead. 636 When the mobile node is sending a multicast packet, it can operate in 637 two modes, multicast-origination-mode or unicast-origination-mode. 638 When in multicast-origination-mode, the mobile node multicast-source 639 can encapsulate a multicast packet in another multicast packet, as 640 described above. When in unicast-origination-mode, the mobile node 641 multicast source encapsulates the multicast packet into a unicast 642 packet and sends a packet to each encapsulated IGMP Report sender. 644 These modes are provided depending on whether or not the mobile 645 node's network it is currently connected can support IP multicast. 647 9. RLOC Considerations 649 This section documents cases where the expected operation of the 650 LISP-MN architecture may require special treatment. 652 9.1. Mobile Node's RLOC is not Globally Routable 654 When a mobile node receives a non-globally routable IPv4 [RFC1918] or 655 IPv6 [RFC4193] address during a roaming event, it cannot advertise it 656 globally (i.e., use it as an RLOC in a Map-Reply). This is because 657 the scope of the private address is bounded by the current 658 topological location where the mobile node resides. The use of 659 private address with LISP is detailed in [LISP-NAT]. 661 9.2. Mobile Node's RLOC is an EID 663 When a LISP mobile node roams into a LISP site, the "RLOC" it is 664 assigned may be an address taken from the site's EID-prefix. In this 665 case, the mobile node will Map-Register a mapping from its statically 666 assigned EID to the "RLOC" it received from the site. This scenario 667 creates another level of indirection: the mapping from the mobile 668 node's EID to a site assigned EID. The mapping from the mobile 669 node's EID to the site assigned EID allow the mobile node to be 670 reached by sending packets using the mapping for the EID; packets are 671 delivered to site's EIDs use the same LISP infrastructure that all 672 LISP hosts use to reach the site. 674 A packet egressing a LISP site destined for a LISP mobile node that 675 resides in a LISP site will have three headers: an inner header that 676 is built by the host and is used by transport connections, a middle 677 header that is built by the site's ITR and is used by the 678 destination's ETR to find the current topological location of the 679 mobile node, and an outer header (also built by the site's ITR) that 680 is used to forward packets between the sites. 682 Consider a site A with EID-prefix 1.0.0.0/8 and RLOC A and a site B 683 with EID-prefix 2.0.0.0/8 and RLOC B. Suppose that a host S in site A 684 with EID 1.0.0.1 wants to talk to a LISP mobile node MN that has 685 registered a mapping from EID 240.0.0.1 to "RLOC" 2.0.0.2 (where 686 2.0.0.2 allocated from site B's EID prefix, 2.0.0.0/8 in this case). 687 This situation is depicted in Figure 2. 689 Site has EID-prefix 1.0.0.0/8 Site has EID-prefix 2.0.0.0/8 690 S has EID 1.0.0.1 MN has EID 240.0.0.1 691 MN has RLOC 2.0.0.2 692 -------------- -------------- 693 / \ --------------- / \ 694 | ITR-A' | / \ | ETR-B' | 695 | | | | | | 696 | S | | Internet | | MN | 697 | \ | | | | ^ | 698 | \ | | | | / | 699 | --> ITR-A | \ / | ETR-B ---- | 700 \ / --------------- \ / 701 -------------- -------------- 702 | | | ^ ^ ^ 703 | | | | | | 704 | | | outer-header: A -> B | | | 705 | | +------------------------------------------+ | | 706 | | RLOCs used to find which site MN resides | | 707 | | | | 708 | | | | 709 | | middle-header: A -> 2.0.0.2 | | 710 | +-----------------------------------------------------+ | 711 | RLOCs used to find topological location of MN | 712 | | 713 | | 714 | inner-header: 1.0.0.1 -> 240.0.0.1 | 715 +----------------------------------------------------------------+ 716 EIDs used for TCP connection 718 Figure 2: Mobile Node Roaming into a LISP Site 720 In this case, the inner header is used for transport connections, the 721 middle header is used to find topological location of the LISP mobile 722 node (the LISP mobile node Map-Registers the mapping 240.0.0.1 -> 723 2.0.0.2 when it roams into site B), and the outer header is used to 724 move packets between sites (A and B in Figure 2). 726 10. Mobility Example 728 This section provides an example of how the LISP mobile node is 729 integrated into the base LISP Architecture [LISP]. 731 10.1. Provisioning 733 The LISP mobile node needs to be configured with the following 734 information: 736 An EID, assigned to its loopback address 738 A key for map-registration 740 An IP address of a Map-Resolver (this could be learned 741 dynamically) 743 An IP address of its Map-Server and Proxy ETR 745 10.2. Registration 747 After a LISP roams to a new network, it MUST immediately register its 748 new mapping this new RLOC (and associated priority/weight data) with 749 its Map-Server. 751 The LISP mobile node MAY chose to set the 'proxy' bit in the map- 752 register to indicate that it desires its Map-Server to answer map- 753 requests on its behalf. 755 11. LISP Implementation in a Mobile Node 757 This section will describe a possible approach for developing a 758 lightweight LISP-MN implementation. A LISP mobile node will 759 implement a LISP sub-layer inside of the IP layer of the protocol 760 stack. The sub-layer resides between the IP layer and the link- 761 layer. 763 For outgoing unicast packets, once the header that contains EIDs is 764 built and right before an outgoing interface is chosen, a LISP header 765 is prepended to the outgoing packet. The source address is set to 766 the local RLOC address (obtained by DHCP perhaps) and the destination 767 address is set to the RLOC associated with the destination EID from 768 the IP layer. To obtain the RLOC for the EID, the mobile node 769 maintains a map-cache for destination sites or destination mobile 770 nodes to which it is currently talking. The map-cache lookup is 771 performed by doing a longest match lookup on the destination address 772 the IP layer put in the first IP header. Once the new header is 773 prepended, a route table lookup is performed to find the interface in 774 which to send the packet or the default router interface is used to 775 send the packet. 777 When the map-cache does not exist for a destination, the mobile node 778 may queue or drop the packet while it sends a Map-Request to it's 779 configured Map-Resolver. Once a Map-Reply is returned, the map-cache 780 entry stores the EID-to-RLOC state. If the RLOC state is empty in 781 the Map-Reply, the Map-Reply is known as a Negative Map-Reply in 782 which case the map-cache entry is created with a single RLOC, the 783 RLOC of the configured Map-Server for the mobile node. The Map- 784 Server that serves the mobile node also acts as a Proxy ETR (PETR) so 785 packets can get delivered to hosts in non-LISP sites to which the 786 mobile node is sending. 788 For incoming unicast packets, LISP sub-layer in the mobile node 789 simply decapsulates the packets and delivers to the IP layer. In 790 addition, if the SMR-bit is set in the LISP header, the mobile node 791 will schedule a timer to later send a Map-Request to the source 792 address of the received encapsulated packet. Optionally, the loc- 793 reach-bits can be processed by the LISP sub-layer. That is, the 794 source EID from the packet is looked up in the map-cache and if the 795 loc-reach-bits settings have changed, store the loc-reach-bits from 796 the packet and note which RLOCs for the map-cache entry should not be 797 used. 799 A background task that runs off a timer should be run so the mobile 800 node can send periodic Map-Register messages to the Map-Server. The 801 Map-Register message should also be triggered when the mobile node 802 detects a change in IP address for a given interface. The mobile 803 node should send Map-Registers to the same Map-Register out each of 804 it's operational links. This will provide for robustness on radio 805 links with which the mobile node is associated. 807 A mobile node receives a Map-Request when it has Map-Registered to a 808 Map-Server with the Proxy-bit set to 0. That means, the mobile node 809 wishes to send authoritative Map-Replies for Map-Requests that are 810 targeted at the mobile node. If the Proxy-bit is set in Map- 811 Registers, then the Map-Server will send non-authoritative Map- 812 Replies on behalf of the mobile node. In this case, the Map-Server 813 never encapsulates Map-Requests to the mobile node. The mobile node 814 can save resources by not receiving Map-Requests. 816 To summarize, a LISP sub-layer should implement: 818 o Encapsulating and decapsulating data packets. 820 o Sending and receiving of Map-Request control messages. 822 o Receiving and optionally sending Map-Replies. 824 o Sending Map-Register messages periodically. 826 The key point about the LISP sub-layer is that no other components in 827 the protocol stack need changing; just the insertion of this sub- 828 layer between the IP layer and the interface layer-2 encapsulation/ 829 decapsulation layer. 831 12. Security Considerations 833 Security for the LISP-MN architecture builds upon the security 834 fundamentals found in LISP [LISP] for data-plane security and the 835 LISP Map Server [LISP-MS] registration security. Security issues 836 unique to the LISP-MN architecture are considered below. 838 12.1. Proxy ETR Hijacking 840 The Proxy ETR (or PETR) that a LISP mobile node uses as its 841 destination for non-LISP traffic must use the security association 842 used by the registration process outlined in Section 6.2 and 843 explained in detail in the LISP-MS specification [LISP-MS]. These 844 measures prevent third party injection of LISP encapsulated traffic 845 into a Proxy ETR. Importantly, a PETR MUST NOT decapsulate packets 846 from non-registered RLOCs. 848 12.2. LISP mobile node using an EID as its RLOC 850 For LISP packets to be sent to a LISP mobile node which has an EID 851 assigned to it as an RLOC as described in Section 9.2), the LISP site 852 must allow for incoming and outgoing LISP data packets. Firewalls 853 and stateless packet filtering mechanisms must be configured to allow 854 UDP port 4341 and UDP port 4342 packets. 856 13. Acknowledgments 858 Noel Chiappa, Andrew Partan, and John Zwiebel provided insightful 859 comments on early versions of this document. A special thanks goes 860 to Mary Nickum for her attention to detail and effort in editing 861 early versions of this document. 863 14. IANA Considerations 865 This document creates no new requirements on IANA namespaces 866 [RFC2434]. 868 15. References 869 15.1. Normative References 871 [LIG] Farinacci, D. and D. Meyer, "LISP Internet Groper (LIG)", 872 draft-ietf-lisp-lig-00.txt (work in progress), 873 August 2010. 875 [LISP] Farinacci, D., Fuller, V., Lewis, D., and D. Meyer, 876 "Locator/ID Separation Protocol (LISP)", 877 draft-ietf-lisp-08.txt (work in progress), August 2010. 879 [LISP-ALT] 880 Farinacci, D., Fuller, V., Lewis, D., and D. Meyer, "LISP 881 Alternative Topology (LISP+ALT)", 882 draft-ietf-lisp-alt-04.txt (work in progress), April 2010. 884 [LISP-IW] Lewis, D., Farinacci, D., Fuller, V., and D. Meyer, 885 "Interworking LISP with IPv4 and IPv6", 886 draft-ietf-lisp-interworking-00.txt (work in progress), 887 May 2009. 889 [LISP-MCAST] 890 Farinacci, D., Meyer, D., Venaas, S., and J. Zwiebel, 891 "LISP for Multicast Environments", 892 draft-ietf-lisp-multicast-03.txt (work in progress), 893 April 2010. 895 [LISP-MS] Farinacci, D. and V. Fuller, "LISP MAP Server", 896 draft-ietf-lisp-ms-05.txt (work in progress), April 2010. 898 [LISP-NAT] 899 Farinacci, D., Fuller, V., Lewis, D., and D. Meyer, "NAT 900 Traversal for the Locator/ID Separation Protocol (LISP)", 901 draft-x-lisp-nat-traversal-00.txt (work in progress), 902 April 2010. 904 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 905 E. Lear, "Address Allocation for Private Internets", 906 BCP 5, RFC 1918, February 1996. 908 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 909 Requirement Levels", BCP 14, RFC 2119, March 1997. 911 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 912 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 913 October 1998. 915 [RFC3220] Perkins, C., "IP Mobility Support for IPv4", RFC 3220, 916 January 2002. 918 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 919 Addresses", RFC 4193, October 2005. 921 15.2. Informative References 923 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 924 RFC 2131, March 1997. 926 Authors' Addresses 928 Dino Farinacci 929 Cisco Systems, Inc. 930 Tasman Drive 931 San Jose, CA 95134 932 USA 934 Email: dino@cisco.com 936 Vince Fuller 937 Cisco Systems, Inc. 938 Tasman Drive 939 San Jose, CA 95134 940 USA 942 Email: vaf@cisco.com 944 Darrel Lewis 945 Cisco Systems, Inc. 946 Tasman Drive 947 San Jose, CA 95134 948 USA 950 Email: darlewis@cisco.com 952 David Meyer 953 Cisco Systems, Inc. 954 Tasman Drive 955 San Jose, CA 95134 956 USA 958 Email: dmm@1-4-5.net