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