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