idnits 2.17.00 (12 Aug 2021) /tmp/idnits26570/draft-vidya-ip-mobility-multihoming-interactions-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1554. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1565. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1572. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1578. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 5, 2007) is 5427 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC4423' on line 547 == Unused Reference: '17' is defined on line 1489, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 1492, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 1495, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 1498, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 1502, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 1505, but no explicit reference was found in the text == Unused Reference: '23' is defined on line 1509, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-soliman-monami6-flow-binding-04 -- Possible downref: Normative reference to a draft: ref. '2' ** Obsolete normative reference: RFC 3344 (ref. '3') (Obsoleted by RFC 5944) ** Obsolete normative reference: RFC 4140 (ref. '4') (Obsoleted by RFC 5380) ** Downref: Normative reference to an Experimental RFC: RFC 4857 (ref. '5') ** Downref: Normative reference to an Experimental RFC: RFC 4881 (ref. '6') == Outdated reference: draft-ietf-hip-mm has been published as RFC 5206 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-mm (ref. '7') == Outdated reference: draft-ietf-hip-rvs has been published as RFC 5204 ** Downref: Normative reference to an Experimental draft: draft-ietf-hip-rvs (ref. '8') == Outdated reference: draft-iab-multilink-subnet-issues has been published as RFC 4903 ** Downref: Normative reference to an Informational draft: draft-iab-multilink-subnet-issues (ref. '9') == Outdated reference: draft-ietf-mip4-dsmipv4 has been published as RFC 5454 == Outdated reference: A later version (-06) exists of draft-ietf-mip6-nemo-v4traversal-04 -- Possible downref: Normative reference to a draft: ref. '11' == Outdated reference: draft-ietf-mip4-mobike-connectivity has been published as RFC 5266 == Outdated reference: A later version (-08) exists of draft-ietf-shim6-applicability-02 ** Downref: Normative reference to an Informational draft: draft-ietf-shim6-applicability (ref. '13') == Outdated reference: A later version (-03) exists of draft-singh-netlmm-protocol-02 -- Possible downref: Normative reference to a draft: ref. '15' -- Possible downref: Normative reference to a draft: ref. '16' ** Obsolete normative reference: RFC 3775 (ref. '17') (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4068 (ref. '18') (Obsoleted by RFC 5268) == Outdated reference: draft-ietf-shim6-proto has been published as RFC 5533 == Outdated reference: draft-ietf-mip4-fmipv4 has been published as RFC 4988 ** Downref: Normative reference to an Experimental draft: draft-ietf-mip4-fmipv4 (ref. '21') == Outdated reference: draft-ietf-netlmm-nohost-ps has been published as RFC 4830 ** Downref: Normative reference to an Informational draft: draft-ietf-netlmm-nohost-ps (ref. '22') == Outdated reference: draft-ietf-monami6-multiplecoa has been published as RFC 5648 Summary: 14 errors (**), 0 flaws (~~), 23 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Narayanan 3 Internet-Draft Qualcomm, Inc. 4 Expires: January 6, 2008 D. Thaler 5 Microsoft 6 M. Bagnulo 7 Huawei Lab at UC3M 8 H. Soliman 9 Elevate Technologies 10 July 5, 2007 12 IP Mobility and Multi-homing Interactions and Architectural 13 Considerations 14 draft-vidya-ip-mobility-multihoming-interactions-01 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on January 6, 2008. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2007). 45 Abstract 47 A number of protocols have been defined at the IETF to handle IP 48 mobility and multi-homing - each of the defined protocols satisfies a 49 different set of requirements - however, there is an overlap on some 50 of the requirements and features among many of these protocols. In 51 practice, a combination of the protocols are likely to be deployed in 52 a system. There are various such combinations plausible, but some 53 combinations are more realistic than others. This document analyzes 54 the overall mobility and multi-homing architecture and highlights 55 some key points to consider while deploying an architecture 56 consisting of one or more of these protocols. The protocols 57 considered in scope for this document include Mobile IPv4 (MIPv4), 58 Mobile IPv6 (MIPv6), Hierarchical Mobile IPv6 (HMIPv6), Fast Mobile 59 IPv6 (FMIPv6), Network-based Local Mobility Management (NetLMM), 60 MOBIKE, Host Identity Protocol (HIP), and Shim6. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. IP Mobility and Multi-homing - Relative Analysis . . . . . . . 7 67 4. Protocol Sub-classes . . . . . . . . . . . . . . . . . . . . . 10 68 4.1. Node-based Mobility and Multihoming . . . . . . . . . . . 10 69 4.1.1. Mobile IP . . . . . . . . . . . . . . . . . . . . . . 10 70 4.1.2. Hiearchical Mobile IP . . . . . . . . . . . . . . . . 11 71 4.1.3. Fast Mobile IP . . . . . . . . . . . . . . . . . . . . 12 72 4.1.4. MOBIKE . . . . . . . . . . . . . . . . . . . . . . . . 12 73 4.1.5. SHIM6 . . . . . . . . . . . . . . . . . . . . . . . . 12 74 4.1.6. HIP . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 4.2. Network-based Mobility . . . . . . . . . . . . . . . . . . 14 76 5. Mobility Architectures . . . . . . . . . . . . . . . . . . . . 15 77 5.1. Architectural Entities . . . . . . . . . . . . . . . . . . 15 78 5.2. Protocol Stacks . . . . . . . . . . . . . . . . . . . . . 18 79 6. Protocol Interactions, Usage Models and Architectural 80 Implications . . . . . . . . . . . . . . . . . . . . . . . . . 20 81 6.1. Multi-Level Node-based Mobility and Multihoming . . . . . 20 82 6.1.1. MIP, HMIP, and FMIP . . . . . . . . . . . . . . . . . 21 83 6.1.2. MIP and MOBIKE . . . . . . . . . . . . . . . . . . . . 25 84 6.1.3. MIP and SHIM6 . . . . . . . . . . . . . . . . . . . . 27 85 6.1.4. MIP and HIP . . . . . . . . . . . . . . . . . . . . . 27 86 6.1.5. SHIM6 and MOBIKE . . . . . . . . . . . . . . . . . . . 27 87 6.1.6. SHIM6 and HIP . . . . . . . . . . . . . . . . . . . . 27 88 6.1.7. HIP and MOBIKE . . . . . . . . . . . . . . . . . . . . 27 89 6.1.8. MIP, SHIM6 and HIP . . . . . . . . . . . . . . . . . . 27 90 6.2. Node-based and Network-based Mobility . . . . . . . . . . 28 91 6.2.1. Security Implications . . . . . . . . . . . . . . . . 29 92 6.2.2. Multihoming Implications . . . . . . . . . . . . . . . 30 93 6.2.3. Network-based mobility for non-MIP nodes . . . . . . . 32 94 6.2.4. Other Analysis . . . . . . . . . . . . . . . . . . . . 32 95 7. Security Considerations . . . . . . . . . . . . . . . . . . . 33 96 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 97 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 99 Intellectual Property and Copyright Statements . . . . . . . . . . 37 101 1. Introduction 103 Over the years, several protocols have been defined at the IETF to 104 handle changes to IP addresses of endpoints in a seamless fashion and 105 preserving communications established using a given IP address across 106 changes in the IP points of attachment. Essentially, all of the 107 proposed mechanisms provide IP address permanence at some level to 108 layers above. Some protocols go beyond support for just single- 109 interfaced endpoints and allow multi-homing and IP address permanence 110 to applications on infrastructure sites, servers, gateways, etc. 111 "Permanence" as used here is typically bound by some length of time 112 and hence is not quite permanent in the literal sense. The idea is 113 for the IP address, as observed by layers above IP, to stay constant 114 within that duration, even if the endpoint changed its IP point of 115 attachment or added an interface within that time. The existing 116 documents on these protocols provide sufficient details for the 117 individual protocol operation itself, but do not touch on 118 architectural aspects. In practice, a combination of the protocols 119 are likely to be deployed in an architecture. There are various such 120 combinations plausible, but some combinations are more realistic than 121 others. Also, various considerations come into play while defining 122 an overall architecture that encompasses IP mobility and multi- 123 homing. Often, a network may need to support a variety of such 124 protocols to satisfy the varying needs of the different nodes that 125 attach to it. Also, a given node would often support multiple such 126 protocols for various reasons. 128 This document analyzes the overall mobility architecture and 129 highlights some key points to consider while deploying an 130 architecture consisting of one or more of these protocols. The 131 protocols considered in scope for this document include Mobile IPv4 132 (MIPv4), Mobile IPv6 (MIPv6), Hierarchical Mobile IPv6 (HMIPv6), Fast 133 Mobile IPv6 (FMIPv6), Proxy Mobile IPv6 (PMIPv6), MOBIKE, Host 134 Identity Protocol (HIP), and Shim6. 136 2. Terminology 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in RFC- 2119 [1]. 142 This document follows the terminology that has been defined in the 143 normative references included in this document. In addition, the 144 following terminology is used in this draft. 146 IP Mobility 148 IP mobility refers to changes in the IP point of attachment of a 149 node. As a consequence of this change, a node may obtain a 150 different (topologically meaningful) address. The result is that 151 a mobile node or network, as it moves, may obtain different 152 topologically meaningful IP addresses that it can use for IP-based 153 communications. Some protocols allow the nodes to maintain the 154 same IP address as they move across different IP points of 155 attachment. 157 IP Mobility Protocol 159 An IP mobility protocol provides transparency to layers above IP 160 from the changes in the IP addresses resulting from IP mobility. 161 In particular, such protocols allow nodes to continue IP 162 communications independent of the current IP point of attachment 163 and to preserve established communications across any 164 corresponding IP address changes. A key element of an IP mobility 165 protocol is to detect movement and do what is needed to allow 166 communication continuity. 168 IP Multi-addressing 170 A node or a network is multi-addressed when it simultaneously has 171 multiple topologically meaningful addresses or prefixes. Note 172 that nodes and networks can be multi-addressed even if they only 173 have a single network attachment point. This is typically true 174 for IPv6 nodes for example, since interfaces can have both link- 175 local and global addresses. 177 IP Multi-homing 179 A network is multihomed when it has multiple network (not 180 necessarily physical) attachment points. From an IP perspective, 181 these multiple attachment points typically imply that the node or 182 network is also multi-addressed. There are some exceptions, 183 however, (e.g., with Provider Independent (PI) addressing), where 184 multihoming does not translate to having a meaningful address/ 185 prefix from each of the providers. Similarly, a node is 186 multihomed when it has multiple network interfaces 188 IP Multi-addressing Protocol 190 An IP multi-addressing protocol provides transparency to upper 191 layers from changes in the IP address actually used to exchange 192 packets by presenting a constant IP address. A key element of an 193 IP multi-addressing protocol is to detect the reachability status 194 of the different addresses and do what is needed to allow 195 communication continuity. 197 Node-based Mobility 199 Node-based mobility is defined as an IP mobility mechanism where 200 the mobility management signaling is performed by the node 201 requiring mobility itself. Mobile nodes include end hosts and 202 routers that may be mobile. 204 Network-based Mobility 206 Network-based mobility is defined as an IP mobility mechanism 207 where the mobility management signaling is performed by a network 208 entity on behalf of the node requiring mobility itself. 210 Local Mobility 212 For the purpose of this document, local mobility is defined as 213 mobility within a given domain. Local mobility protocols allow at 214 least one IP address of a node to remain constant within the local 215 domain. Continuity of sessions using that IP address in the local 216 domain is a goal for these protocols. The term "domain" is quite 217 loosely used to indicate a region within which it is practical to 218 expect end-to-end security associations between the mobility 219 signaling endpoints. Typically, this is limited to a single 220 administrative domain. Depending on the protocol used, this may 221 mean mobility within an access technology or may also involve 222 inter-technology handoffs. 224 Global Mobility 226 For the purpose of this document, global mobility is defined as 227 mobility within a larger geographic area. Typically, this 228 includes mobility across heterogeneous technologies and inter- 229 administrative domains. Global mobility protocols allow at least 230 one IP address of a node to remain constant across any handoffs. 231 Continuity of sessions using that IP address across handoffs is a 232 goal for these protocols. 234 Global Roaming 236 This term is used to refer to the availability of a set of 237 services to a node from anywhere, at any time. Maintenance of IP 238 address or session continuity is not a goal for this. This term 239 encompasses the cases of a node roaming world-wide and accessing a 240 set of services from anywhere. 242 Correspondent Node 244 Any entity that communicates with a mobile node is referred to as 245 a correspondent node. 247 Access Router 249 An Access Router is defined as the first hop IP router for a 250 mobile node at its point of attachment. This entity typically 251 serves as the default router for the mobile node. 253 Access Network 255 An access network is typically the edge network to which a mobile 256 node attaches. An access network typically comprises of one or 257 more physical and link layer attachment points, as well as one or 258 more access routers. 260 3. IP Mobility and Multi-homing - Relative Analysis 262 IP mobility and multi-homing are closely related in one sense and 263 somewhat different in another sense. Protocols that handle IP 264 mobility and multi-homing can be used together in a competing or 265 complementary fashion. All IP mobility protocols support basic host 266 multi-homing or multi-addressing functions. There are protocols that 267 further support site multi-homing, that can be leveraged for mobility 268 to a certain extent. A system looking at using the various available 269 components should look at the scope of each and the requirements at 270 hand to see how best to fit these together. This section provides an 271 analysis on the relative scope and requirements handled by each suite 272 of protocols. 274 ---------------- ---------------- 275 |Remote Network 1| |Remote Network 2| 276 ---------------- ---------------- 277 | | 278 | | 279 ----------------------------- --------------- 280 | |---| Home Network 1| 281 | | --------------- 282 | Backbone | --------------- 283 | |---| Home Network 2| 284 | | --------------- 285 ----------------------------- 286 | | 287 | | 288 ---------------- ---------------- 289 | Local Network 1| | Local Network 2| 290 ---------------- ---------------- 291 \ / 292 \ / 293 ------ 294 | Node | 295 ------ 297 Figure 1: End Node and Multi-Network Associations 299 Figure 1 shows a multi-network setup with local networks, remote 300 networks and home networks, all inter-connected in some fashion. The 301 main idea is that these networks can communicate via a backbone of 302 some form. There are three classes of networks illustrated here: 304 Local Networks 306 A local network is an access network to which a node is attached 307 at any given time. The node may or may not have a long term 308 association with that network. The local network often defines 309 the actual IP point of attachment of a node and may change over 310 time. 312 Home Networks 314 A home network is one with which a node has a long term 315 association (this is not to be confused with the "home network" in 316 the context of Mobile IP or related protocols). While that is 317 certainly one example of a home network, the various provider 318 networks in the SHIM6 context may also be home networks from an 319 association point of view. Networks with which a node has a VPN 320 relationship may also fall under this category. 322 Remote Networks 324 A remote network is one with which a node has no association. A 325 remote network may become a local network at some point of time. 326 A node with certain local and home networks may communicate with 327 any of the networks. For generality, everything except the local 328 and home networks may be viewed as a remote network. 330 Given all the networks, there are several mobility, multihoming, and 331 multi-addressing relations that can be drawn from here. 333 Note that the nodes within a multihomed network will be exposed to 334 multiple prefixes and they will then configure multiple global 335 topologically meaningful addresses. The result is that nodes within 336 a multihomed network are multi-addressed, as are nodes which are 337 themselves multihomed. Even if the former type of nodes access the 338 Internet through a single interface, the use of different addresses 339 implies different paths (because each address is associated to a 340 different point of attachment of the multihomed network to the 341 Internet). Both types of nodes encounter similar problems and also 342 benefit from a multi-addressing support protocol. 344 The multihoming aspects may vary due to mobility or due to network 345 unreachability. The former may cause more frequent changes in the 346 multihoming state than the latter. Also, a node may be multihomed 347 both in the local and home networks. For instance, a mobile node 348 with cellular and WLAN accesses may be associated with two ISPs or 349 with an ISP and an enterprise network. The local multihoming 350 situation may change relatively frequently based on the rate of 351 mobility of the node, while the multihoming situation with multiple 352 home networks may remain fairly stable. 354 Correspondent nodes may be located in the local, home, or remote 355 networks. While it is technically feasible for communication with 356 the correspondent node to happen using any of the IP addresses owned 357 by the node, there may be some practical considerations with respect 358 to making IP address changes known to the correspondent nodes and its 359 impact to applications in use. Using DNS updates or SIP Re-invite 360 like mechanisms, IP address changes can be made visible to the 361 correspondent nodes. For some applications, such transitions may be 362 seamless enough, while it may not be the case for some other 363 applications. 365 The alternative to DNS updates or SIP Re-invites and affecting 366 applications with IP address changes and reachability issues is to 367 provide an unchanging address to the applications and handle actual 368 IP address changes at a lower layer. This is the approach taken by 369 IP mobility and multihoming protocols, although in different ways. 371 IP mobility protocols achieve this property via tunneling mechanisms. 372 A centralized entity keeps track of the current location of the 373 mobile node, so that data can be appropriately forwarded to the node. 374 IP multihoming protocols like SHIM6 achieve this property via a shim 375 layer between the IP and transport layers that perform address 376 translation, thereby avoiding tunnels. 378 IP mobility protocols developed at the IETF thus far are scoped to 379 solve both mobility and multihoming in the context of a single home 380 network. In other words, local multihoming (attachment to multiple 381 local networks) is handled by extensions to Mobile IP, for instance. 382 Some rudimentary local multihoming is also feasible by the basic 383 Mobile IP class of protocols without extensions. This provides 384 seamlessness to the applications using the address of the end node 385 associated with one home network for communication. 387 IP multihoming protocols developed at the IETF thus far are scoped to 388 solving site multihoming in the context of one or more local and/or 389 home networks. The main difficulty that multi-addressed nodes face 390 when managing their multiple addresses, is that the reachability 391 status of the addresses may vary during the lifetime of a 392 communication (e.g. because of outages) and it may be required to use 393 a different address for continuing an established communication, 394 since the original one has become unreachable. While address 395 unavailability and additions may be caused by mobility, solving node 396 mobility is not a goal of the protocol. 398 Section 6.1.3 provides details on how IP mobility and multihoming 399 protocols can be architecturally combined. 401 4. Protocol Sub-classes 403 4.1. Node-based Mobility and Multihoming 405 4.1.1. Mobile IP 407 Mobile IP (v4 and v6) provides a mechanism by which a node can 408 maintain the same IP address as it changes its IP point of 409 attachment. This is enabled by having a Home Address which is on the 410 prefix of a Home Agent and a Care-of-Address which is the 411 topologically correct local address at the point of attachment. The 412 Home Agent maintains the mapping between the Home Address and the 413 Care-of-Address. The Mobile Node is responsible for updating the 414 binding between the Home Address and Care-of-Address at the Home 415 Agent. All packets sent to the Home Address of the mobile node will 416 be received by the Home Agent and tunneled or forwarded to the mobile 417 node at its Care-of-Address. The packets sent from the mobile node 418 may be sent directly or reverse tunneled through the Home Agent. 420 Mobile IPv4 (MIP4) additionally provides a mode of operation with a 421 Foreign Agent in the local network. The Foreign Agent makes 422 conservation of IP space possible by allowing multiple mobile nodes 423 on its link to share the same Care-of-Address. The Care-of-Address 424 in this case is the IP address of the Foreign Agent. The Mobile IP 425 tunnel in this case terminates at the Foreign Agent and the Foreign 426 Agent forwards packets to the mobile node based on the Home Address 427 in the packets. 429 Mobile IPv6 (MIP6) additionally provides the capability of route 430 optimization. Here, the mobile node may provide the Home Address- 431 Care-of-Address binding to a correspondent node (CN) so that the CN 432 sends packets directly to the Care-of-Address bypassing the Home 433 Agent. 435 Mobile routers may be supported using Network Mobility (NEMO), where, 436 in addition to a Home Address, a prefix owned by the node is also 437 bound to the Care-of-Address at the Home Agent or CN. 439 Multi-homing for the Care-of-Addresses may be supported in MIP6 using 440 extensions being defined in [2]. This allows multiple Care-of- 441 Addresses for an mobile node to be bound to a given Home Address. 442 There are extensions being proposed to use multiple Care-of-Addresses 443 simultaneously based on flow mapping information - [2], for instance. 444 One Care-of-Address is registered as a primary Care-of-Address and is 445 used by default. Multiple Care-of-Addresses are also supported in 446 MIP4 (simultaneous bindings), although data is duplicated to every 447 Care-of-Address registered [3]. 449 4.1.2. Hiearchical Mobile IP 451 Hierarchical Mobile IPv6 (HMIPv6) [4] provides a means of local 452 mobility management for mobile nodes. Essentially, it is a variant 453 of MIP6 that provides more efficient mobility within a local domain. 454 In this case, the mobile node obtains a Regional Care-of-Address 455 (RCoA) in the prefix of a Mobility Anchor Point (MAP) and a Local 456 Care-of-Address (LCoA) which is the topologically correct IP address 457 at the point of attachment. The mobile node is responsible for 458 updating the binding between the LCoA and RCoA at the MAP. HMIPv6 459 may be used independent of the use of MIP6. This results in a 460 deterministic delay for routing updates due to the MN's movement, 461 when compared to the variation in delays when relying on updating the 462 HA (which can be anywhere on the Internet). HMIPv6 also reduces the 463 number of binding updates sent as a result of movement to one. 465 A similar concept for Mobile IPv4, regional registration, has been 466 proposed [5]. In Regional Registration, a Generic Foreign Agent is 467 used in place of the MAP to hide the local mobility from the Home 468 Agent. Unlike HMIPv6, regional registration relies on the presence 469 of Mobile IP as a higher level mobility management protocol in the 470 system. 472 In general, all the extensions defined for MIP6 may be used with 473 HMIPv6 as well. Hence, NEMO and multiple Care-of-Address binding 474 would also be supported in HMIPv6. Similarly, MIP4 extensions may be 475 used with regional registration mechanisms as well. 477 4.1.3. Fast Mobile IP 479 Fast Mobile IP (v4 and v6) provides a means of local mobility 480 management at the edge for mobile nodes. FMIP is designed to provide 481 temporary mobility management across Access Routers for faster and 482 low latency handoffs. Here, a previous Care-of-Address (pCoA) is 483 bound to a new Care-of-Address (nCoA) at the previous Access Router 484 (pAR), after the mobile node has left the pAR and attached itself to 485 a new Access Router (nAR). Effectively, data is tunneled from the 486 pAR to the mobile node at its nCoA 488 FMIPv4 also supports the Foreign Agents, in keeping with MIP4. In 489 addition to FMIPv4, some low latency extensions to MIP4 have also 490 been proposed in [6]. 492 4.1.4. MOBIKE 494 MOBIKE provides mobility and multi-homing capabilities to IKEv2. 495 When IKEv2 is used to create IPsec Security Associations between a 496 node and a VPN gateway, the node may change its IP point of 497 attachment, causing a change to the IP address which was used in 498 IKEv2. Further, the node and the VPN gateway may be multi-homed with 499 multiple IP addresses. MOBIKE allows a node to update its IP address 500 on the IKE SA and correspondingly change the IPsec tunnel outer 501 addresses. Hence, a node may change IP addresses without having to 502 re-establish the IKE and IPsec SAs. Packets sent to the tunnel inner 503 address of the node are tunneled to the appropriate outer address. 505 Since IKEv2 is defined in an IP version agnostic manner, MOBIKE also 506 applies equally to IPv4 and IPv6. 508 4.1.5. SHIM6 510 In order to preserve global routing system scalability, the Site 511 Multi-homing by IPv6 Intermediation (Shim6) approach proposes that 512 multihomed sites obtain multiple globally routable prefixes, one from 513 each of their ISPs. In this configuration, each prefix assigned to a 514 multihomed site can be aggregated into the prefix of the 515 correspondent ISP, eliminating the contribution of multihomed sites 516 to the global routing table. The result is that interfaces within 517 multihomed sites will configure one address per prefix that is 518 available in the site. In this setup, each address is reachable as 519 long the corresponding path is working, so in order to preserve 520 established communications through outages, it may be necessary to 521 change the address used for exchanging packets during the lifetime of 522 the communication. This is achieved using the Shim6 protocol. 524 The Shim6 protocol provides a means by which two nodes with more than 525 one IP address pair can change the address used to exchange packets 526 during the lifetime of a communication without impacting the 527 applications. Shim6 introduces the concept of an Upper Layer 528 Identifier (ULID), and allows the IP address chosen by applications 529 to persist, while using different addresses (called locators) to 530 actually exchange packets below IP, based on their reachability 531 status. A shim sub-layer located within the IP layer, between the IP 532 endpoint sub-layer (handling fragmentation and IPSec functions among 533 others) and the IP forwarding sublayer provides this transparency. 534 The ULIDs used by Shim6 are in the form of an IPv6 address and 535 contain cryptographic information that is used to secure the binding 536 between the ULID and its locator set. The Shim6 architecture has two 537 main components. The Shim6 protocol that is used to create and 538 manage the Shim6 context between the endpoints containing ULID pair 539 and locator set information for the peers. The other component is 540 the failure detection and alternative path exploration protocol 541 (called REAP), that allows the peers to detect failures along the 542 currently used path and explore alternative locator pairs to divert 543 the communication through. 545 4.1.6. HIP 547 The Host Identity Protocol (HIP) [RFC4423] is a new architecture that 548 separates the identity and the locator functions currently performed 549 by the IP address in the Internet architecture. It does so by 550 creating a new namespace for the identity of the network layer 551 endpoints. The new identity namespace is cryptographic in nature, 552 since the Host Identities (HI) are public keys that are associated to 553 the hosts they represent. In order to be backward compatible with 554 current transport and application layers, the HIP architecture does 555 not impose the direct usage of the HI by the upper layers, but 556 provides a compact representation of the Host Identities, namely the 557 Host Identity Tag, which are 128 bits long hashes of the actual HI. 558 The result is that transport and application layer communications are 559 bound to the HI/HIT while the actual packets are routed at the IP 560 layer using routable IP addresses. The HIP sub-layer located in the 561 IP layer securely performs the translation between the host identity 562 and the routable locators. 564 The HIP architectures provides built-in security features. 565 Essentially, HIP can be seen as a key exchange protocol, through 566 which the keys associated to the the HI/HITs are negotiated prior of 567 the beginning of the communication. Actual data packets are carried 568 encapsulated with ESP protection. So, the HIP architecture naturally 569 provides the means to establish secure communication channels between 570 the peers. Moreover, since the endpoint identity space is 571 cryptographic in nature, the HIP architecture intrinsically provides 572 the means to proof identity ownership without requiring any 573 additional infrastructure. Such capability enables alternative means 574 to support mobility and multihoming, as described in [7]. 575 Essentially, mobility and multihoming support for the HIP protocol 576 relies on conveying alternative locator information in HIP signaling 577 messages called UPDATE messages. Such UPDATE messages are protected 578 using the trust acquired while the initial HIP key exchange. In 579 order to support simultaneous movement and initial contact after 580 movement, the HIP architecture relies on Rendez-Vous server defined 581 in [8]. 583 4.2. Network-based Mobility 585 Network-based mobility provides a means of mobility management for 586 nodes without involving the nodes themselves in the signaling. This 587 is done by making IP mobility transparent to the nodes. Network- 588 based Local Mobility Management (NetLMM) is essentially a concept of 589 providing local mobility using network-based mobility management 590 protocols. Here, a Mobility Access Gateway (MAG), often located at 591 the Access Router (AR), updates a Local Mobility Agent (LMA) with the 592 location of a mobile node. A mobile node acquires an IP address in 593 the NetLMM domain, which remains the same as long as the mobile node 594 remains within that domain. Hence, the changes in the IP point of 595 attachment do not cause IP address changes. 597 By definition, NetLMM allows an IP prefix to span multiple links. By 598 assigning a unique prefix for every mobile node and by employing 599 virtual point-to-point link semantics for link local behavior, it is 600 possible to avoid the issues of multi-link subnets [9] in NetLMM. 602 Also, by definition, NetLMM provides mobility for a given IP address 603 or prefix of a node. If a node is multi-addressed, mobility for each 604 address or prefix will be handled separately in the NetLMM domain. 605 While it is feasible to identify the multiple IP addresses or 606 prefixes as belonging to the same node using other identifiers, it is 607 not possible to provide transparency of such addresses to 608 correspondent nodes or applications. 610 5. Mobility Architectures 612 This section provides an overall picture of all the elements involved 613 in an overall mobility architecture. It also provides a description 614 of where the various IP mobility functions fit in the stack relative 615 to other protocols. 617 5.1. Architectural Entities 618 ====================================== 619 | Home Network | ================ 620 | ------ ----------- | | Remote Network | 621 | | CN | | HIP RVS | | | | 622 | ------ ----------- | | | 623 | ------ -------- ------- | | | 624 | | MIP | | VPN GW | | Shim6 | | | | 625 | | HA | |(Mobike)| | Node | |--------| ------ | 626 | ------ -------- ------- | | | CN | | 627 | | | ------ | 628 ====================================== | | 629 | | | 630 | | | 631 ============================================== | ------- | 632 | Local Network | | | Shim6 | | 633 | ------ | | | Node | | 634 | | CN | | | ------- | 635 | ------ | | | 636 | -------------------------------------- | | | 637 | | | | | | 638 | | ------ ------ -------- | | | | 639 | | | HMIP | |NetLMM| | VPN GW | | |----| | 640 | | | MAP | | LMA | |(Mobike)| | | | | 641 | | ------ ------ -------- | | | | 642 | | | | ================ 643 | -------------------------------------- | 644 | | | 645 | | | 646 | -------------------------------------- | 647 | | | | 648 | | ------ ------ --------- | | 649 | | |NetLMM| | MIP4 | |FMIP/HMIP| | | 650 | | | MAG | | FA | | AR | | | 651 | | ------ ------ --------- | | 652 | | Access Network | | 653 | | | | 654 | -------------------------------------- | 655 | | 656 ============================================== 657 | 658 | 659 ------ 660 | Node | 661 ------ 663 Figure 2: Architectural Entities in IP Mobility and Multi-homing 665 Figure 2 shows a potential network architecture with various 666 components of IP mobility management entities. The figure follows 667 the local, home and remote network models shown in Figure 1. As 668 shown, a part of the local network may be the edge or access network 669 to which a node attaches. The access network typically consists of 670 the first hop IP routers that nodes can attach to. The access 671 network also provides the physical point of attachment (wired or 672 wireless access with L1/L2 points of attachment such as access 673 points) for the nodes. Depending on the system, there may or may not 674 be mobility management elements in the local network. Also, 675 depending on the system, there may not be a home network at all. For 676 completeness, the figure shows the possible IP mobility management 677 entities. All the elements shown are logical elements and some of 678 them may be physically collocated in a system. 680 As shown in the figure, the Mobility Access Gateway, the Foreign 681 Agent, and the Access Router are all functions residing on the MN's 682 first hop router. The MAG is responsible for playing the role of a 683 network-based mobility client. The Foreign Agent provides MIP4 684 services and the Access Router plays a role for FMIP and HMIP. In 685 FMIP, the Access Router is responsible for assisting the MN in 686 predicting the handover, in addition to handling of edge tunnels upon 687 handoff of a node and in HMIP, the Access Router is responsible for 688 advertising the MAP in the IPv6 Router Advertisements. While all 689 these elements can technically co-exist in the same access network 690 and in the same physical box, there are some considerations that need 691 to be taken into account when these do co-exist. Such considerations 692 are outlined in Section 6. 694 When the local network supports mobility management, there may be 695 other entities such as a Mobility Anchor Point (MAP), a Local 696 Mobility Agent (LMA), a VPN gateway supporting MOBIKE, or even a Home 697 Agent present in the local network. One or more of these may serve a 698 node from a mobility management perspective. Some of these interact 699 with some of the elements in the access network to support IP 700 mobility for the end node. As in the case of the access network 701 elements, one or more of these logical functions may be present in 702 the local network and may be collocated in the same physical entity. 703 Some interactions are studied in Section 6. 705 When involved in mobility management, a home network may host a Home 706 Agent or a VPN Gateway supporting MOBIKE. Local mobility management 707 entities may be present in a home network, where the home network is 708 also a local network. Note that the sub-divisions of local, home and 709 remote network, etc. are with respect to the end node - for e.g., a 710 network that is remote for one node may be a local network for a 711 different node. 713 The end node itself may be multi-homed in a couple of different ways 714 - it may have multiple addresses from the home or local network. The 715 node may have multiple interfaces that attach to different access 716 networks within the same or different local network. Further, the 717 node may also have connectivity to multiple home networks, as 718 discussed in Section 3 - for instance, it may be served by different 719 Home Agents or VPN Gateways for access to specific services in each 720 home network. The node may use Shim6 for multi-homing - it may 721 correspond with other Shim6 nodes in other networks. Even though a 722 Shim6 node is shown separately in the home and remote networks, any 723 of the other entities may also be Shim6 capable. 725 One aspect not indicated in the figure is connectivity to the 726 "Internet" or other networks. It can be assumed that any of the 727 networks provide connectivity to the Internet. The home network can 728 also be expected to provide connectivity to other networks that offer 729 some services to the end node. 731 5.2. Protocol Stacks 733 With so many IP mobility management protocols, all potentially 734 solving slightly different problems, it is interesting to see how 735 these fit together in the stack. The following figure shows the 736 stack diagram for the protocols discussed in this document. 738 ========================================================= 739 | -------- | 740 | | IKEv2/ | ---------------- --------- | 741 | | MOBIKE | | MIP4 signaling | | NetLMM | | 742 | -------- ---------------- --------- | 743 ========================================================= 744 |------------------------------- 745 | | 746 ========================================================= | 747 | Transport Layer | | 748 | ----- ----- | | 749 | | TCP | | UDP | | | 750 | ----- ----- | | 751 ========================================================= | 752 |------------------------------| 753 | | 754 ========================================================= | 755 | IP Layer | | 756 | | | 757 | ===================================================== | | 758 | | IP endpoint sublayer | | | 759 | | | | | 760 | | ---------- ------ | | | 761 | | ---- --------- | Frag/ | | Dst. | | | | 762 | | | AH | | ESP/HIP | | Re-assly | | Opt. | | | | 763 | | ---- --------- ---------- ------ | | | 764 | ===================================================== | | 765 | | | 766 | ------- | | 767 | | Shim6 | | | 768 | ------- | | 769 | | | 770 | ----- ------ ------ ------ | | 771 | | MIP | | FMIP | | HMIP | | PMIP | | | 772 | ----- ------ ------ ------ | | 773 | | | 774 | ===================================================== | | 775 | | IP forwarding sublayer | | | 776 | | | | | 777 | ===================================================== | | 778 | | | 779 ========================================================= | 780 | 781 | 782 ------- ------- ------- ------------- | 783 | Link1 | | Link2 | ... | Linkn | |Link (Tunnel)|--- 784 ------- ------- ------- ------------- 785 Figure 3: Stack Diagram 787 Figure 3 above shows a stack diagram of how the various IP mobility 788 and multihoming components fit in a stack with respect to some other 789 layers. A node may have various link layers as indicated. The IP 790 layer is indicated in three parts. One is the IP forwarding sublayer 791 that sits right above the link layer. In many of these protocols, 792 there may be IP-in-IP tunneling. This is indicated in the figure by 793 "Link (Tunnel)" - this layer would essentially wrap around the IP 794 layer as a loopback, as shown. Typically, IP addressing is done on a 795 per-link basis. Any virtual interfaces/links are assumed to still be 796 a separate link. The Shim6 layer has two possible locations in the 797 stack - it may be above or below the "Mobile IP family" of protocols. 798 Since the Mobile IP family of protocols (MIP, FMIP, HMIP, PMIP) 799 involve mapping between two IP addresses, Shim6 can be invoked as a 800 multi-homing solution for either of those addresses. More about this 801 interaction will be described in Section 6.1.3 below. 803 The figure shows MIP generically at the IP layer and MIP4 804 specifically over the transport layer. MIP4 signaling runs over UDP, 805 while the MIP4 data tunnel is an IP-in-IP tunnel. For sake of 806 completeness, the figure shows MIP4 signaling also over UDP, for the 807 signaling portion. 809 The IPsec components (AH and ESP) may either be part of the tunnel 810 (shown as a link) or the actual IP layer above the MIP family of 811 protocols when IP-in-IP encapsulation (with reverse tunneling) is 812 used for the MIP data path. This depends on which address is used 813 for IPsec purposes. However, it should be noted that MIP6 is 814 operated with Route Optimization, the IPsec components are always 815 above the MIP components in the header. IKEv2 (and by definition, 816 MOBIKE) run over UDP. IKEv2/MOBIKE is the signaling mechanism that 817 ultimately affects the IPsec tunnel endpoints - hence, as in the case 818 of MIP4, it is only the signaling that is layered over a transport 819 protocol. 821 AH and ESP may also be used in transport or tunnel mode and hence may 822 be part of the tunnel or the regular IP layer. All of the elements 823 shown are optional elements and the existence of any of this depends 824 on the protocols used in the system. 826 6. Protocol Interactions, Usage Models and Architectural Implications 828 6.1. Multi-Level Node-based Mobility and Multihoming 830 This section is intended to discuss the various viable combinations 831 of node-based mobility and multihoming protocols and also point out 832 any problematic combinations. This is a work in progress and is 833 expected to be more detailed in later versions. 835 6.1.1. MIP, HMIP, and FMIP 837 Depending on the mobility needs of a system, one or more of these 838 protocols may be deployed. Typically, this is a two level mobility 839 management mechanism, with additional edge mobility. However, 840 multiple modes of combining FMIP and HMIP are also feasible. A few 841 different modes of using these protocols together is explained below. 842 It should be noted that it is feasible to run any of these modes with 843 just a subset of these three protocols. It should further be noted 844 that while this section focuses on the v6 versions of these 845 protocols, similar combinations are also feasible with the v4 846 versions of the same - there may be additional modes of interest with 847 MIP4, given the Foreign Agent mode of operation; however, that is 848 left for further study. Alternatively, the same result can be 849 obtained for both MIPv4 and MIPv6 using one version of MIP. This can 850 be done using Dual Stack MIP v4 or v6 as presented in [10] and [11]. 852 ---------- 853 | HA | 854 ---------- 855 / \ 856 / \ Home Network 857 -------------------------------|--------------------------------- 858 Local Network 1 / | \ Local Network 2 859 / | \ 860 --------- | ---------- 861 | MAP1 | | | MAP2 | 862 --------- | ---------- 863 /\ | /\ 864 / \ | / \ 865 / \ | / \ 866 / \ | / \ 867 / \ | / \ 868 ------ ------ | ------ ------ 869 | AR11 | ... | AR1n | | | AR21 | ... | AR2n | 870 ------ ------ | ------ ------ 871 | | 872 | | 873 ------ | 874 | MN | ----> | 875 ------ | 876 | 878 Figure 4: MIP, HMIP, and FMIP 880 Figure 4 shows an architecture with a MIP Home Agent, an HMIP MAP and 881 Access Routers that perform FMIP operation. Upon first entering the 882 network, the mobile node obtains an IP address on the prefix served 883 by an Access Router. Using the MAP advertised by the Access Router, 884 the mobile node may perform an HMIP registration, using that IP 885 address as its Local Care-of-Address (LCoA) and an IP address 886 obtained in the MAP's prefix as its Regional Care-of-Address (RCoA). 887 The mobile node may further obtain a Home Address from the Home Agent 888 and use that for mobility across MAPs. In this case, the HMIP RCoA 889 is registered as the MIP6 Care-of-Address of the mobile node. In the 890 presence of a Home Address, the mobile node would typically use this 891 address for application connectivity. However, there may be certain 892 other considerations in choosing the right address for communication. 893 More on that in Section 6.1.1.3. 895 The combination of HMIP and FMIP may also be done in a few different 896 ways. When the mobile node moves from one Access Router to another, 897 it may use FMIP for faster handoffs. FMIP may be used within a MAP 898 or across MAPs between Access Routers. It is also feasible to use 899 FMIP on the previous MAP, when the mobile node moves across MAP 900 boundaries. This would often be more efficient in such border cases 901 than setting up the FMIP session between the Access Routers. In a 902 tree topology, it may always be more efficient to allow the MAP to 903 perform FMIP services. In these cases, the "PAR (Previous Access 904 Router)" functionality of FMIP is performed by the MAP. When the 905 mobile node moves across Access Routers within a MAP, the FMIP tunnel 906 is set up with the previous and new LCoAs as the FMIP PCoA and NCoA 907 respectively. When the mobile node moves across MAPs and uses FMIP 908 on the MAP, the previous and new RCoAs are treated as the FMIP PCoA 909 and NCoA respectively. 911 The FMIP tunnel is viewed as a temporary, short-lived tunnel used to 912 help mobile nodes receive packets while waiting for the HMIP or MIP 913 registration to complete. When FMIP is not in use, such a two-level 914 mobility management mechanism leads to two IP tunnels on every data 915 packet. For the period where FMIP is also in use, every packet is 916 tunneled thrice. For a packet sent from the mobile node, this 917 tunneling results in something as shown in Figure 5. The figure 918 shows source and destination addresses of each IP header present in 919 the packet. The oringinal packet is sourced using the Home Address 920 to a correspondent node. This is first encapsulated in the Mobile IP 921 tunnel, followed by the HMIP tunnel and finally followed by the FMIP 922 tunnel. For a packet received by the mobile node from a CN, the 923 tunneling is similar in the reverse direction. 925 +---------+---------------+--------------+-------+---------- 926 | S=NCoA | S=LCoA(=PCoA) | S=CoA(=RCoA) | S=HoA | Payload 927 | D=PAR | D=MAP | D=HA | D=CN | 928 +---------+---------------+--------------+-------+---------- 930 Figure 5: Packet Tunneling with MIP, HMIP, and FMIP 932 A simple superimposition of all protocols (i.e. when the three 933 protocols are in use) would lead the mobile node to perform signaling 934 for FMIP and HMIP upon handoff within a given local network and for 935 FMIP, HMIP and MIP upon handoff across local networks. However, 936 there are other modes of integration that would not result in such 937 inefficiency. For instance, HMIP and FMIP can be combined such that 938 binding updates are only sent to the MAP, while FMIP is used to 939 anticipate the movement of the mobile node. This would eliminate the 940 tunnel between the old and new AR. 942 6.1.1.1. Security Implications 944 In this model, the mobile node is responsible for all of the 945 signaling. Each protocol requires a specific security association 946 that is tied with the address for which the binding needs to be 947 created. This ensures that the mobile node cannot redirect traffic 948 meant for some other node. When all the three protocols are in use, 949 this implies that the mobile node may share a Security Association 950 with the PAR tied to the PCoA, which is also the HMIP LCoA, a 951 Security Association with the MAP tied to the RCoA (which is also the 952 MIP Care-of-Address), and a Security Association with the Home Agent 953 tied to the Home Address. Depending on the choice of security 954 protocol used by each of these mobility management protocols, these 955 security associations may be IPsec security associations or something 956 else. However, as mentioned above the security association between 957 the MN and any AR can be eliminated in this configuration. 959 6.1.1.2. Multihoming Implications 961 The mobile node may be attached to multiple Access Routers, thereby 962 having multiple LCoAs. The mobile node may register multiple LCoAs 963 with the MAP in that case. Further, the mobile node may actually be 964 attached to multiple MAPs (if there are overlapping MAP regions as 965 described in Section 6.1.1.3), in which case, it possesses multiple 966 RCoAs. The mobile node may then use MIP to register multiple Care- 967 of-Addresses (each RCoA would be registered as a MIP Care-of-Address) 968 with the Home Agent. 970 Multihoming with connectivity to multiple Home Agents is discussed in 971 Section 6.1.3. 973 6.1.1.3. Other Analysis 975 It is important to look at system requirements before determining 976 whether all the protocols are needed. For many practical needs of 977 mobile nodes, it is possible that only a subset of these protocols 978 are needed. For instance, both FMIP and HMIP address the latency 979 involved in MIP registrations - FMIP allows reception of packets at 980 new location before the registration with the Home Agent completes. 981 HMIP ensures that the MIP registrations need not be that frequent - 982 hence, the latency really comes into play only upon crossing MAP 983 boundaries. If something like FMIP is needed for fast handoff 984 purposes anyway, HMIP may not be needed as an intermediate level of 985 mobility management. Depending on the location of the MAP and the 986 kind of interconnectivity that is present between the Access Routers, 987 it may also be the case that the latency involved in HMIP 988 registrations and FMIP tunnel setup are comparable. In such cases, 989 it may be feasible to avoid the use of FMIP in the system. 991 The use of HMIP permits a not-so-transient local address (RCoA) that 992 can be used for communication. When there is no need for a really 993 long-lived IP address, it may not be necessary to have a global 994 mobility management mechanism. This basically allows the data path 995 latency to be lower, since the MAP is meant to be geographically 996 closer to the mobile node. When Route Optimization is used for MIP, 997 this data path latency is not an issue. However, even when Route 998 Optimization is used, HMIP is useful to ensure that frequent 999 registrations with the correspondent node are not needed. 1000 Registrations with the correspondent node will need to be modified 1001 only upon handoff to a new MAP. In reality, the local network 1002 regions managed by MAPs is likely to be overlapping, in which case, 1003 make-before-break HMIP transitions can be made. This is especially 1004 feasible with HMIP, since there is no requirement on trust 1005 relationships between the Access Routers and the MAP. Once the 1006 mobile node possesses a security association with the MAP, it can 1007 register any LCoA with it. The overlapping MAP boundaries may be 1008 indicative of a geographically closer MAP, implying a MAP transition 1009 for more optimal communication. Such an overlap provides the mobile 1010 node the opportunity to bootstrap the HMIP session with the new MAP 1011 before switching the data path to it. However, this places a 1012 requirement on the mobile node to be able to handle multiple HMIP 1013 sessions simultaneously for a short period of time. It must be noted 1014 that an overlap is harder for inter-administrative domains, since 1015 even though there is no trust relationship requirement between the 1016 Access Routers and the MAPs, the Access Routers are required to 1017 advertise the presence of the MAPs to the mobile nodes. 1019 When the three protocols are all used, the mobile node has several IP 1020 addresses to choose from for communication purposes. For really 1021 long-lived connections, it is always better to use the most permanent 1022 IP address - this would be the Home Address of the mobile node. 1023 However, the mobile node may be running some latency sensitive 1024 applications that are not necessarily long-lived. Voice over IP is 1025 one such application. In those cases, tunneling all the data packets 1026 through the Home Agent may introduce unacceptable latency for the 1027 application. When Route Optimization is used, it is feasible to 1028 avoid such tunneling - however, route optimization support may not be 1029 available and it may also be considered expensive in some cases. For 1030 such cases, it would be an option to use the HMIP RCoA as the IP 1031 address for applications. Especially in situations of overlapping 1032 HMIP coverage as discussed above, the transition from one HMIP RCoA 1033 to another may be made seamlessly via SIP Re-Invite messages for the 1034 purposes of applications such as VoIP. Such a transition would be 1035 needed when the application persists while the mobile node is moving 1036 across MAP boundaries. It is also feasible to continue keeping the 1037 association with the old MAP until the end of the application, if it 1038 was going to only be short-lived. 1040 6.1.2. MIP and MOBIKE 1042 One method of combining MIP and MOBIKE is described for MIP4 in [12]. 1043 In that model, MIP is used for mobility inside a given secure 1044 network, while MOBIKE with a VPN gateway is used for mobility outside 1045 the secure network. The general goal there is to allow enterprise 1046 mobile devices to keep the same IP address while roaming in and out 1047 of the enterprise network. There are other possible combinations as 1048 well. 1050 There is the question of the usefulness of MOBIKE when MIP6 is 1051 employed. MIP6 inherently provides a means of updating the IKE 1052 endpoint IP address when the mobile node registers a new Care-of- 1053 Address for itself. This functionality is supported by indicating 1054 the need for dynamic key management in the MIP6 binding update sent 1055 by the mobile node with a new Care-of-Address. This is functionality 1056 that would be duplicated by MOBIKE if both protocols were to be used 1057 in conjunction. By using a MIP6 Home Agent as also a VPN gateway, it 1058 is then feasible to just use MIP6 for mobility and still provide 1059 protected access. However, in addition to allowing changes to the 1060 local IP address of the initiator (typically the MIP6 mobile node), 1061 MOBIKE also allows the responder (typically the MIP6 Home Agent) to 1062 be multihomed and change the IP address used in a security 1063 association - this is not functionality supported by MIP6. Hence, 1064 depending on the requirements, it may make sense to run MIP6 and 1065 MOBIKE together or not in a given system. 1067 Further, if the goal is to provide support for mobile devices roaming 1068 in and out of enterprise networks, it is likely that both protocols 1069 are needed, unless detection of protected vs. unprotected network can 1070 happen through other means. This is due to the fact that in the 1071 MIP6-only mode, the Home Agent is made reachable from inside and 1072 outside the protected network. Hence, if the policy to use IPsec for 1073 data traffic only applies when the client is outside the protected 1074 network, the client must be able to securely determine whether it is 1075 attached to the protected network or not. If not, an impersonating 1076 element in the access network will successfully cause the mobile node 1077 to send sensitive data without any protection. In the model 1078 described in [12], the Home Agent is not reachable from an external 1079 network and hence, that provides a rather secure means of ensuring 1080 that unprotected data exchange does not occur while the MN is 1081 attached to an untrusted network. 1083 Future revisions of this document will address this kind of 1084 combination in greater detail. 1086 6.1.2.1. Security Implications 1088 As in the case of multi-level node-based IP mobility management, this 1089 mechanism also requires the mobile node to possess appropriate 1090 security associations with the Home Agent and the VPN gateway 1091 performing MOBIKE. The security association for MIP must be tied to 1092 the home address, while the IPsec selectors for the security 1093 association created or modified using MOBIKE will depend on the type 1094 of protection that is intended using that SA. 1096 Additionally, the security of the internal IP addressing semantics of 1097 a protected network may be important to consider while designing a 1098 solution that requires both VPNs and mobility support. For example, 1099 the VPN gateway, in many networks, is the only reachable device from 1100 an unprotected network. If a MIP6 Home Agent was made reachable from 1101 an external network, it may be exposed to additional threats than the 1102 case where the Home Agent is "behind" the VPN gateway and only 1103 accessible from the protected network. Also, another consideration 1104 while deciding to choose between a MIP6-only with data protection and 1105 a combined MIP6-MOBIKE solution with separate VPN gateway and Home 1106 Agent, is ensuring the ability to securely detect the connectivity to 1107 an untrusted network to avoid sending unprotected sensitive data over 1108 the untrusted network. An alternative would be to always require 1109 that data be sent in a protected manner, irrespective of the location 1110 of the mobile node. However, that adds a lot of load on the Home 1111 Agent/VPN Gateway device to process a lot more protected traffic and 1112 is often unnecessary. 1114 6.1.3. MIP and SHIM6 1116 As described in Section 3, MIP and SHIM6 can either be deployed in a 1117 complementary or competing fashion. The mobile node may be multi- 1118 addressed in the local networks by virtue of either the local network 1119 being multi-homed or attaching to multiple local networks. In such 1120 cases, if MIP is employed to handle mobility, it is easier for the 1121 local multi-addressing to be handled as part of mobility. In other 1122 words, the mobile node may register multiple Care-of-Addresses tied 1123 to the same Home Address with the HA. The mobile node may then use 1124 any Care-of-Address to send or receive data. 1126 However, when the mobile node is multi-addressed with IP addresses 1127 from multiple home networks, even if MIP is used in each home 1128 network, it only ties each Home Address with one or more of the Care- 1129 of-Addresses that the mobile node possesses. So, while multiple Home 1130 Addresses can each be bound to multiple (same or different) Care-of- 1131 Addresses, MIP does not facilitate tying the Home Addresses itself 1132 together. This is due to the fact that MIP requires a central entity 1133 (Home Agent) for address mappings and each such entity can only 1134 handle IP addresses belonging to it. SHIM6 is a potential solution 1135 to handle such multihoming. Using SHIM6, both Home Addresses can be 1136 tied together by providing a common ULID to a correspondent node. 1137 Hence, the correspondent nodes may reach the mobile node via either 1138 Home Addresses, and this helps to ensure reachability even when one 1139 of the home networks is down. Some of this concept is covered in 1140 [13]. Future revisions of this document will provide more details. 1142 6.1.4. MIP and HIP 1144 TBD 1146 6.1.5. SHIM6 and MOBIKE 1148 TBD 1150 6.1.6. SHIM6 and HIP 1152 TBD 1154 6.1.7. HIP and MOBIKE 1156 TBD 1158 6.1.8. MIP, SHIM6 and HIP 1160 TBD 1162 6.2. Node-based and Network-based Mobility 1164 ---------- 1165 | HA | 1166 ---------- 1167 / \ 1168 / \ Home Network 1169 -------------------------------|--------------------------------- 1170 Local Network 1 / | \ Local Network 2 1171 / | \ 1172 --------- | ---------- 1173 | LMA1 | | | LMA2 | 1174 --------- | ---------- 1175 /\ | /\ 1176 / \ | / \ 1177 / \ | / \ 1178 / \ | / \ 1179 / \ | / \ 1180 ------- ------- | ------- ------- 1181 | MAG11 | ... | MAG1n | | | MAG21 | ... | MAG2n | 1182 ------- ------- | ------- ------- 1183 | | 1184 | | 1185 ------ | 1186 | MN | ----> | 1187 ------ | 1188 | 1190 Figure 6: MIP and NETLMM 1192 This section describes how node-based global mobility and network- 1193 based local mobility can co-exist in an architecture. Figure 6 shows 1194 an architecture that has a MIP Home Agent as part of the home network 1195 and network-based mobility entities, LMA and MAG in the local 1196 network. Network-based mobility discussions in this section apply 1197 equally to solutions described in [14], [15], and [16]. The term 1198 NetLMM is used to refer to any of these solutions in a generic 1199 manner. 1201 Figure 6 shows the architectural entities involved in the two 1202 protocols. While this is architecturally similar to the MIP/HMIP 1203 overlay described in Section 6.1.1, there are some significant 1204 differences arising due to the fact that the local mobility here 1205 happens without mobile node involvement. 1207 Conceptually, there are similarities between this model and the MIP/ 1208 HMIP overlay model. The MAP and LMA are equivalent in function and 1209 scope - the LMA keeps track of the mobility of the mobile node within 1210 the local network. However, an important difference is that local 1211 mobility is achieved here by preserving the same local address for 1212 the mobile node within the local network, as described in 1213 Section 4.2. The mobile node may register such a local address 1214 anchored at the LMA as its Care-of-Address with the Home Agent - MIP 1215 updates are then only necessary when the mobile node associates with 1216 a new LMA. 1218 As in the case of the MIP/HMIP overlay, it is feasible to have one of 1219 the local networks as the Mobile IP home network of the mobile node. 1220 In such a case, the LMA and Home Agent for a given mobile node would 1221 be collocated in that local network and the mobile node would be 1222 "home" from a MIP perspective while attached to that network. MIP 1223 operation is then only needed when the mobile node is not attached to 1224 that network. However, this model has some security implications 1225 that are worth noting and those are captured in Section 6.2.1. In 1226 addition to the security implications, this model may also lead to 1227 some race conditions which are analyzed in Section 6.2.4. 1229 As the mobile node moves within a local network, its current location 1230 will be updated at the LMA by the appropriate MAG. A separate 1231 protocol between the mobile node and the MAG may be employed to 1232 detect the attachment of an mobile node to a MAG. Alternately, some 1233 technologies may allow mobile node movement detection at the network 1234 and trigger a context transfer between MAGs to provide the necessary 1235 information to complete the new location registration. 1237 6.2.1. Security Implications 1239 The node-based mobility here is handled by the mobile node and Home 1240 Agent and the network-based mobility is handled by the MAG and LMA. 1241 The mobile node needs to possess a security association with the Home 1242 Agent tied to its Home Address for MIP operation, as is normally the 1243 case. For the NetLMM operation, there must be a Security Association 1244 between the MAG and the LMA. This security association provides the 1245 needed data origin authentication. However, it does not guarantee 1246 the attachment of the mobile node with that particular MAG. Without 1247 mobile node involvement or some authorization checks involving an 1248 entity such as a AAA server, it is not feasible to provide any 1249 guarantees about the actual presence of the mobile node at that MAG. 1250 Hence, a malfunctioning or compromised MAG would be able to redirect 1251 traffic meant for that mobile node by creating an incorrect binding 1252 at the LMA. However, such a threat can be limited in scope by 1253 ensuring that a MAG is only capable of updating bindings for 1254 addresses that are valid in that local domain. This requires 1255 appropriate prefix partitioning and verification of the address 1256 claimed by the LMA for the mobile node against the prefix it is 1257 authorized to serve. In such a case, the MAG would be unable to 1258 redirect traffic of an mobile node that is not within its local 1259 network. 1261 An additional security implication is when one of the local networks 1262 is considered to be the MIP home network, making the local address 1263 acquired by the mobile node in that network its MIP Home Address. In 1264 this case, while the mobile node is within that domain, the security 1265 risks are analogous to what has been described so far. However, it 1266 is feasible for a MAG to redirect traffic belonging to a mobile node 1267 even when the mobile node is no longer in that local network. Even 1268 if the redirection is not successful in some cases, it is capable of 1269 leading to ambiguity in mobile node's current location at the LMA/ 1270 Home Agent. This is due to the fact that the MAG and the mobile node 1271 are both authorized to perform updates corresponding to the same IP 1272 address. This would basically result in the security guarantees of 1273 MIP being affected by the use of NetLMM. Such a threat may be 1274 mitigated by requiring the LMA to reject any updates to the mobile 1275 node's local address (which is the same as the Home Address in this 1276 case) by a MAG when there is an existing binding for that address 1277 created by the mobile node. However, this leads to some undesirable 1278 inter-dependencies between the two protocols and also may lead to 1279 less than ideal mobility management, as described in Section 6.2.4. 1281 6.2.2. Multihoming Implications 1283 Unlike the HMIP case, multi-homing at the local networks level cannot 1284 be handled by the NetLMM class of solutions. For instance, the 1285 mobile node may be multihomed by virtue of attachment to two MAGs 1286 within the same LMA or under different LMAs. An IP node will obtain 1287 a distinct global IP address on each of its interfaces (physical or 1288 virtual) - hence, if the mobile node is attached to two MAGs at any 1289 given time, it will acquire separate IP addresses. 1291 NetLMM provides mobility to each IP address and by itself, has no 1292 means of tying the multiple IP addresses to the same mobile node. 1293 Hence, mobility for these IP addresses will be handled independently 1294 by default. However, certain technologies may have the capability to 1295 identify (say, via L2 mapping) that a given set of IP addresses 1296 belong to the same mobile node. In such a case, it is feasible for 1297 this to be known at the LMA. However, even so, it is not feasible 1298 for these IP addresses to be associated with any per-packet 1299 identifier. Unlike the ULID in SHIM6 or RCoA in HMIP, NetLMM does 1300 not have anything available for the mobile and correspondent nodes to 1301 use for communication. 1303 Extracting from the above, in terms of data flow, these addresses are 1304 practically independent and the ability to correlate multiple IP 1305 addresses belonging to the same mobile node at the LMA is of little 1306 use. In other words, it is unlike the case where the correspondent 1307 nodes pick one IP address of the mobile node to get the data to the 1308 LMA, with multiple possible paths available to the mobile node from 1309 there. In this case, the correspondent node and the mobile node need 1310 to pick a particular mobile node address to correspond with. Note 1311 that when MIP is used, this correspondent node may actually be the 1312 Home Agent. Hence, when the mobile node has multiple IP addresses, 1313 the decision of picking an address to correspond with is still left 1314 to the application and not handled by NetLMM. 1316 Extending this analysis to multihoming for mobile nodes with multi- 1317 radio capabilities, it is not even feasible for the network to 1318 provide any correlation between IP addresses of the mobile node, 1319 given that there is no common L2 identifier. With involvement on the 1320 mobile node's part, it may be feasible to obtain an access agnostic 1321 identity to correlate with the multiple IP addresses. However, that 1322 would be defeating one of the motivations of having network-based 1323 mobility transparent to the mobile node. 1325 It is conceivable that the same global IP address is assigned to the 1326 mobile node for multiple interfaces - however, that requires a 1327 fundamental change to the functioning of regular IP nodes. Further, 1328 it also places restrictions on the simultaneous use of such multiple 1329 interfaces. It also requires intelligence below the IP layer to pick 1330 the correct interface for different packets sent with the same IP 1331 address, which would typically not be needed. 1333 The above analysis leads to the following conclusions. 1335 o Without an out-of-band mechanism, it is not feasible for the MAG 1336 or LMA to correlate multiple IP addresses as belonging to the same 1337 mobile node. 1339 o Even with such correlation, there is no means of presenting a 1340 single IP address to applications with multiple paths over the 1341 network. Hence, applications are exposed to multiple IP addresses 1342 by default. 1344 o Providing the same global IP address to multiple interfaces would 1345 require undesirable changes to mobile nodes and places 1346 restrictions on simultaneous use of the interfaces. 1348 By this analysis, it appears that network-based mobility management 1349 is not well-suited to handle any kind of multi-homing of a mobile 1350 node. The mobile node is in the best position to determine the 1351 availability and connection capabalities of its various interfaces 1352 and hence, multi-addressing and multi-homing is best handled using 1353 node-based mobility management. 1355 6.2.3. Network-based mobility for non-MIP nodes 1357 We have analyzed the co-existence of node and network-based mobility 1358 for a given mobile node for two-level mobility management thus far. 1359 The other model is where network-based mobility is only intended for 1360 nodes that are incapable of mobility management on their own, such as 1361 legacy mobile devices. In that case, a given network must support 1362 network-based mobility for such devices and let other mobile nodes 1363 handle their own mobility. In the NetLMM class of solutions, the 1364 entire local network is made to appear as having the same IP prefix - 1365 this is achieved by advertising the same prefix to the mobile node as 1366 it moves within the local network. By virtue of such a protocol, it 1367 is not feasible to differentiate between MIP-capable and non-MIP- 1368 capable endpoints using functionality provided in the protocol 1369 itself. Such detection is only feasible via some out-of-band 1370 mechanism. In some systems, it may be feasible for the network to 1371 know the capabilities of the nodes that attach to it. If the network 1372 is aware of the capabilities, it would be feasible to present an 1373 unchanging IP address or prefix throughout the local network only to 1374 devices that need network-based mobility. 1376 6.2.4. Other Analysis 1378 This section provides additional analysis on the scenario where 1379 network-based local mobility is used on the mobile node's home 1380 network to make the entire local network appear to the mobile node as 1381 its Mobile IP home network. Section 6.2.1 describes the security 1382 implications of the model and shows that it is essential to ensure 1383 that a network-based mobility binding for the mobile node's Home 1384 Address is only accepted when there is no current binding for that 1385 address created by the mobile node itself. That will ensure that the 1386 MIP security guarantees are still available to the mobile node. 1387 However, that may lead to a less than ideal mobility solution for the 1388 mobile node. It is possible that a registration from the network 1389 node arrives at the entity serving as the LMA/Home Agent before the 1390 mobile node has a chance to de-register with the Home Agent. In that 1391 case, such a registration will be rejected until the mobile node is 1392 successfully de-registered from a MIP perspective and its binding is 1393 removed at the Home Agent. This may result in undesirable handoff 1394 latency for the mobile node, when the mobile node is moving in and 1395 out of its home network. 1397 This further introduces the need for some inter-dependency between 1398 the node and network-based mobility protocols. Specifically, the 1399 NetLMM solution must be able to detect the presence of a MIP binding 1400 for a given IP address before accepting a certain registration for an 1401 mobile node. When the NetLMM solution used is PMIP, this may be less 1402 painful - nevertheless, it is still undesirable behavior. 1404 Overall, systems evaluating such an approach must take such 1405 shortcomings into account before using it. The use of this approach 1406 allows data exchange in this extended home network without additional 1407 tunnel overhead (as MIP6 would have) between the mobile node and the 1408 Access Router. It is important to evaluate the need for this, along 1409 with the other solutions such as header compression (say, RoHC) that 1410 may be deployed in the system. RoHC, for instance handles two IP 1411 headers as easily as it does one - hence, if RoHC is needed anyway, 1412 the tradeoffs of using this approach may not be worth it. 1414 7. Security Considerations 1416 For security considerations on the protocols described in this 1417 document, please refer to the appropriate protocol documents. For 1418 the architectural combinations described here, security implications 1419 have been discussed in the corresponding sections. Future revisions 1420 of this document will have a more comprehensive security analysis. 1422 8. IANA Considerations 1424 This document has no actions for IANA. 1426 9. References 1428 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1429 Levels", BCP 14, RFC 2119, March 1997. 1431 [2] Soliman, H., "Flow Bindings in Mobile IPv6 and Nemo Basic 1432 Support", draft-soliman-monami6-flow-binding-04 (work in 1433 progress), March 2007. 1435 [3] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 1436 August 2002. 1438 [4] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier, 1439 "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", 1440 RFC 4140, August 2005. 1442 [5] Fogelstroem, E., Jonsson, A., and C. Perkins, "Mobile IPv4 1443 Regional Registration", RFC 4857, June 2007. 1445 [6] El Malki, K., "Low-Latency Handoffs in Mobile IPv4", RFC 4881, 1446 June 2007. 1448 [7] Henderson, T., "End-Host Mobility and Multihoming with the Host 1449 Identity Protocol", draft-ietf-hip-mm-05 (work in progress), 1450 March 2007. 1452 [8] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP) 1453 Rendezvous Extension", draft-ietf-hip-rvs-05 (work in 1454 progress), June 2006. 1456 [9] Thaler, D., "Multilink Subnet Issues", 1457 draft-iab-multilink-subnet-issues-03 (work in progress), 1458 January 2007. 1460 [10] Tsirtsis, G., "Dual Stack Mobile IPv4", 1461 draft-ietf-mip4-dsmipv4-02 (work in progress), May 2007. 1463 [11] Soliman, H., "Mobile IPv6 support for dual stack Hosts and 1464 Routers (DSMIPv6)", draft-ietf-mip6-nemo-v4traversal-04 (work 1465 in progress), March 2007. 1467 [12] Devarapalli, V. and P. Eronen, "Secure Connectivity and 1468 Mobility using Mobile IPv4 and MOBIKE", 1469 draft-ietf-mip4-mobike-connectivity-03 (work in progress), 1470 March 2007. 1472 [13] Bagnulo, M. and J. Abley, "Applicability Statement for the 1473 Level 3 Multihoming Shim Protocol (Shim6)", 1474 draft-ietf-shim6-applicability-02 (work in progress), 1475 October 2006. 1477 [14] Gundavelli, S., "Proxy Mobile IPv6", 1478 draft-sgundave-mip6-proxymip6-02 (work in progress), 1479 March 2007. 1481 [15] Bedekar, A., "A Protocol for Network-based Localized Mobility 1482 Management", draft-singh-netlmm-protocol-02 (work in progress), 1483 March 2007. 1485 [16] Giaretta, G., "The NetLMM Protocol", 1486 draft-giaretta-netlmm-dt-protocol-02 (work in progress), 1487 October 2006. 1489 [17] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 1490 IPv6", RFC 3775, June 2004. 1492 [18] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, 1493 July 2005. 1495 [19] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", 1496 RFC 4555, June 2006. 1498 [20] Bagnulo, M. and E. Nordmark, "Shim6: Level 3 Multihoming Shim 1499 Protocol for IPv6", draft-ietf-shim6-proto-08 (work in 1500 progress), April 2007. 1502 [21] Koodli, R. and C. Perkins, "Mobile IPv4 Fast Handovers", 1503 draft-ietf-mip4-fmipv4-07 (work in progress), May 2007. 1505 [22] Kempf, J., "Problem Statement for Network-based Localized 1506 Mobility Management", draft-ietf-netlmm-nohost-ps-05 (work in 1507 progress), September 2006. 1509 [23] Wakikawa, R., "Multiple Care-of Addresses Registration", 1510 draft-ietf-monami6-multiplecoa-02 (work in progress), 1511 March 2007. 1513 Authors' Addresses 1515 Vidya Narayanan 1516 Qualcomm, Inc. 1517 5775 Morehouse Dr 1518 San Diego, CA 1519 USA 1521 Email: vidyan@qualcomm.com 1523 Dave Thaler 1524 Microsoft 1525 One Microsoft Way 1526 Redmond, WA 1527 USA 1529 Email: dthaler@microsoft.com 1530 Marcelo Bagnulo 1531 Huawei Lab at UC3M 1533 Email: marcelo@it.uc3m.es 1535 Hesham Soliman 1536 Elevate Technologies 1538 Email: Hesham@elevatemobile.com 1540 Full Copyright Statement 1542 Copyright (C) The IETF Trust (2007). 1544 This document is subject to the rights, licenses and restrictions 1545 contained in BCP 78, and except as set forth therein, the authors 1546 retain all their rights. 1548 This document and the information contained herein are provided on an 1549 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1550 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1551 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1552 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1553 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1554 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1556 Intellectual Property 1558 The IETF takes no position regarding the validity or scope of any 1559 Intellectual Property Rights or other rights that might be claimed to 1560 pertain to the implementation or use of the technology described in 1561 this document or the extent to which any license under such rights 1562 might or might not be available; nor does it represent that it has 1563 made any independent effort to identify any such rights. Information 1564 on the procedures with respect to rights in RFC documents can be 1565 found in BCP 78 and BCP 79. 1567 Copies of IPR disclosures made to the IETF Secretariat and any 1568 assurances of licenses to be made available, or the result of an 1569 attempt made to obtain a general license or permission for the use of 1570 such proprietary rights by implementers or users of this 1571 specification can be obtained from the IETF on-line IPR repository at 1572 http://www.ietf.org/ipr. 1574 The IETF invites any interested party to bring to its attention any 1575 copyrights, patents or patent applications, or other proprietary 1576 rights that may cover technology that may be required to implement 1577 this standard. Please address the information to the IETF at 1578 ietf-ipr@ietf.org. 1580 Acknowledgment 1582 Funding for the RFC Editor function is provided by the IETF 1583 Administrative Support Activity (IASA).