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