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