idnits 2.17.1 draft-ietf-netlmm-mip-interactions-07.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 is 1 instance of too long lines in the document, the longest one being 9 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 28, 2010) is 4922 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'MN' is mentioned on line 284, but not defined == Unused Reference: 'RFC3963' is defined on line 739, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4140 (Obsoleted by RFC 5380) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETLMM Working Group G. Giaretta, Ed. 3 Internet-Draft Qualcomm 4 Intended status: Informational October 28, 2010 5 Expires: May 1, 2011 7 Interactions between PMIPv6 and MIPv6: scenarios and related issues 8 draft-ietf-netlmm-mip-interactions-07 10 Abstract 12 The use of Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6 (MIPv6) in the 13 same network requires some care. This document discusses scenarios 14 where such mixed usage is appropriate and points out the need for 15 interaction between the two mechanisms. Solutions and 16 recommendations to enable these scenarios are also described. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in RFC 2119 [RFC2119]. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on May 1, 2011. 41 Copyright Notice 43 Copyright (c) 2010 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 This document may contain material from IETF Documents or IETF 57 Contributions published or made publicly available before November 58 10, 2008. The person(s) controlling the copyright in some of this 59 material may not have granted the IETF Trust the right to allow 60 modifications of such material outside the IETF Standards Process. 61 Without obtaining an adequate license from the person(s) controlling 62 the copyright in such materials, this document may not be modified 63 outside the IETF Standards Process, and derivative works of it may 64 not be created outside the IETF Standards Process, except to format 65 it for publication as an RFC or to translate it into languages other 66 than English. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 3. Overview of the scenarios and related issues . . . . . . . . . 5 73 3.1. Issues related to scenario A.1 . . . . . . . . . . . . . . 9 74 3.2. Issues related to scenario A.2 . . . . . . . . . . . . . . 9 75 3.3. Issues related to scenario B . . . . . . . . . . . . . . . 11 76 4. Analysis of possible solutions . . . . . . . . . . . . . . . . 12 77 4.1. Solutions related to scenario A.1 . . . . . . . . . . . . 12 78 4.2. Solutions related to scenario A.2 . . . . . . . . . . . . 14 79 4.2.1. Mobility from a PMIPv6 domain to a non-PMIPv6 80 domain . . . . . . . . . . . . . . . . . . . . . . . . 15 81 4.2.2. Mobility from a non-PMIPv6 domain to a PMIPv6 82 domain . . . . . . . . . . . . . . . . . . . . . . . . 16 83 4.3. Solutions related to scenario B . . . . . . . . . . . . . 17 84 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 85 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 17 86 7. Additional Authors . . . . . . . . . . . . . . . . . . . . . . 17 87 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 88 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 89 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 90 9.2. Informative References . . . . . . . . . . . . . . . . . . 19 91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 93 1. Introduction 95 Proxy Mobile IPv6 (PMIPv6) [RFC5213] is a network based IP mobility 96 protocol standardized by IETF. In some deployment scenarios this 97 protocol will be deployed together with Mobile IPv6 (MIPv6) 98 [RFC3775], for example with PMIPv6 as local mobility protocol and 99 MIPv6 as global mobility protocol. While the usage of a local 100 mobility protocol should not have implications of how global mobility 101 is managed, since PMIPv6 is partially based on MIPv6 signaling and 102 data structure, some considerations are needed to understand how the 103 protocols interact and how the different scenarios can be enabled. 105 Some standardization fora are also investigating more complex 106 scenarios where the mobility of some nodes is handled using Proxy 107 Mobile IPv6, while other nodes use Mobile IPv6; or the mobility of a 108 node is managed in turn by a host-based and a network-based 109 mechanism. This needs also to be analyzed as a possible deployment 110 scenario. 112 This document provides a taxonomy of the most common scenarios that 113 require direct interaction between MIPv6 and PMIPv6. The list is not 114 meant to be exhaustive. Moreover, this document presents and 115 identifies most of the issues pertained to these scenarios and 116 discusses possible means and mechanisms that are recommended to 117 enable them. 119 2. Terminology 121 General mobility terminology can be found in [RFC3753]. The 122 following acronyms are used in this document: 124 o AR (Access Router): first hop router. 126 o BCE (Binding Cache Entry): an entry of the MIPv6 or PMIPv6 Binding 127 Cache. 129 o LMA (Local Mobility Anchor): the PMIPv6 mobility anchor as 130 specified in [RFC5213] 132 o MAG (Mobility Access Gateway): the PMIPv6 client as specified in 133 [RFC5213] 135 o MN-HoA: the home address of a mobile node in a PMIPv6 domain. 137 o MN-HNP: the IPv6 prefix that is always present in the Router 138 Advertisements that the mobile node receives when it is attached 139 to any of the access links in that PMIPv6 domain. MN-HoA always 140 belongs to this prefix. 142 o MIPv6-HoA: the Home Address the MN includes in MIPv6 binding 143 update messages. 145 o MIPv6-CoA: the Care-of Address the MN includes in MIPv6 binding 146 update messages. 148 3. Overview of the scenarios and related issues 150 Several scenarios can be identified where MIPv6 and PMIPv6 are 151 deployed in the same network. This document not only focuses on 152 scenarios where the two protocols are used by the same mobile node to 153 manage local and global mobility, but also investigates more complex 154 scenarios where the protocols are more tightly integrated or where 155 there is a co-existence of nodes which do or do not implement MIPv6. 157 In particular the scenario space can be split into hierarchical 158 deployments and alternative deployments of Mobile IP (MIP) and Proxy 159 Mobile IP (PMIP). Hierarchical deployments are scenarios where the 160 two mobility protocols are used in the same network in a hierarchical 161 manner for global and local mobility management. Alternative 162 deployments are scenarios where only one of the two protocols is used 163 for mobility management of a given mobile node. 165 The following hierarchical scenarios are identified: 167 Scenario A.1 - in this scenario PMIPv6 is used as a network based 168 local mobility management protocol whereas MIPv6 is used as a global 169 mobility management protocol. This interaction is very similar to 170 the HMIPv6-MIPv6 interaction [RFC4140]; MIPv6 is used to manage 171 mobility among different access networks, while the mobility within 172 the access network is handled by PMIPv6. The address managed by 173 PMIPv6 (i.e. the MN-HoA) is registered as Care-of Address by the MN 174 at the HA. This means that the HA has a binding cache entry for 175 MIPv6-HoA that points to the MN-HoA. 177 The following figure illustrates this scenario. 178 +----+ 179 | HA | MIPv6-HoA -> MN-HoA 180 +----+ 181 /\ 182 / \ 183 +-------------/----\--------------+ 184 ( / \ ) Global Mobile IPv6 185 ( / \ ) Domain 186 +----------/----------\-----------+ 187 / \ 188 +----+ +----+ 189 MN-HoA -> MAG1 |LMA1| |LMA2| 190 +----+ +----+ 191 //\\ \\ 192 +----//--\\---+ +-----\\------+ 193 ( // \\ ) ( \\ ) Local Mobility Network 194 ( // \\ ) ( \\ ) PMIPv6 domain 195 +-//--------\\+ +--------\\---+ 196 // \\ \\ 197 // \\ \\ 198 // \\ \\ 199 +----+ +----+ +----+ 200 |MAG1| |MAG2| |MAG3| 201 +----+ +----+ +----+ 202 | | | 203 [MN] 205 Figure 1 - Scenario A.1 207 Scenario A.2 - in this scenario the mobile node is moving across 208 different access networks, some of them supporting PMIPv6 and some 209 others not supporting it. Therefore the mobile node is roaming from 210 an access network where the mobility is managed through a network- 211 based solution to an access network where a host-based management 212 (i.e. Mobile IPv6) is needed. This scenario may have different sub- 213 scenarios depending on the relations between the MIPv6 home network 214 and the PMIPv6 domain. The following figure illustrates an example 215 of this scenario, where the MN is moving from an access network where 216 PMIPv6 is supported (i.e. MAG functionality is supported) to a 217 network where PMIPv6 is not supported (i.e. MAG functionality is not 218 supported by the AR). This implies that the home link of the MN is 219 actually a PMIPv6 domain. In this case the MIPv6-HoA is equal to the 220 MN-HoA (i.e. the address managed by PMIPv6). 222 MIPv6-HoA == MN-HoA -> MAG1 223 +------+ 224 |HA/LMA|-----------------------+ 225 +------+ | 226 //\\ | 227 +-------//--\\--------+ | 228 ( // \\ PMIPv6 ) | 229 ( // \\ domain) +--------------+ 230 +----//--------\\-----+ ( Non-PMIPv6 ) 231 // \\ ( domain ) 232 // \\ +--------------+ 233 // \\ | 234 +----+ +----+ +----+ 235 |MAG1| |MAG2| | AR | 236 +----+ +----+ +----+ 237 | | | 238 [MN] 240 Figure 2 - Scenario A.2 241 In the scenario illustrated in Figure 2 the non-PMIPv6 domain can 242 actually be also a different PMIPv6 domain that handles a different 243 MN_HoA. The following figure illustrates this sub-case: the MIPv6- 244 HoA is equal to the MN_HoA; however when the MN hands over to MAG3 it 245 gets a different IP address (managed by LMA2 using PMIPv6) and 246 registers it as a MIPv6 CoA. 248 MIPv6-HoA == MN-HoA -> MAG_1 249 +-------+ 250 |HA/LMA1|-----------------------+ 251 +-------+ | 252 //\\ +----+ 253 +-------//--\\--------+ |LMA2| 254 ( // \\ home ) +----+ 255 ( // \\ PMIPv6) +------||------+ 256 ( // \\domain) ( ||visited) 257 +---//----------\\----+ ( ||PMIPv6 ) 258 // \\ ( ||domain ) 259 // \\ +------||------+ 260 +----+ +----+ +----+ 261 |MAG1| |MAG2| |MAG3| 262 +----+ +----+ +----+ 263 | | | 264 [MN] 266 (a) 268 MIPv6-HoA -> MN_CoA 269 +-------+ 270 |HA/LMA1|-----------------------+ 271 +-------+ | 272 //\\ +----+ 273 +-------//--\\--------+ |LMA2| MN_CoA -> MAG3 274 ( // \\ home ) +----+ 275 ( // \\ PMIPv6) +------||------+ 276 ( // \\domain) ( ||visited) 277 +---//----------\\----+ ( ||PMIPv6 ) 278 // \\ ( ||domain ) 279 // \\ +------||------+ 280 +----+ +----+ +----+ 281 |MAG1| |MAG2| |MAG3| 282 +----+ +----+ +----+ 283 | | | 284 [MN] 286 (b) 288 Figure 3 - Scenario A.2 with visited PMIPv6 domain 290 The following alternative deployment has been identified: 292 Scenario B - in this scenario some mobile nodes use MIPv6 to manage 293 their movements while others rely on a network-based mobility 294 solution provided by the network as they don't support Mobile IPv6. 296 There may be a common mobility anchor that acts as MIPv6 Home Agent 297 and PMIPv6 LMA, depending on the type of the node as depicted in the 298 figure. However, the LMA and HA can also be separated and this has 299 no impacts to the mobility of the nodes. 300 +--------+ 301 | HA/LMA | 302 +--------+ 304 +------+ +------+ 305 | MAG1 | | MAG2 | 306 +------+ +------+ 308 +-----------+ 309 | IPv6 host | -----------------> 310 +-----------+ movement 311 +----------+ 312 | MIPv6 MN | -----------------> 313 +----------+ movement 315 Figure 4 - Scenario B 317 Note that some of the scenarios can be combined. For instance, 318 scenario B can be combined with scenario A.1 or scenario A.2. 320 The following sections describe some possible issues for each 321 scenario. Respective recommendations are described in Section 4.3. 322 The specifications considered as a baseline for the analysis are the 323 following: [RFC3775], [RFC4877] and [RFC5213]. 325 3.1. Issues related to scenario A.1 327 This scenario is very similar to other hierarchical mobility schemes, 328 including a HMIPv6-MIPv6 scheme. No issues have been identified in 329 this scenario. Note that a race condition where the MN registers the 330 CoA at the HA before the CoA is actually bound to the MAG at the LMA 331 is not possible. The reason is that per PMIPv6 specification the MAG 332 does not forward any packets sent by the MN until the PMIPv6 tunnel 333 is up, regardless the mechanism used for address allocation. 335 Section 4.1 describes one message flow in case PMIPv6 is used as a 336 local mobility protocol and MIPv6 is used as a global mobility 337 protocol. 339 3.2. Issues related to scenario A.2 341 This section highlights some considerations that are applicable to 342 scenario A.2. 344 1. HoA management and lookup key in the binding cache 346 * In MIPv6 [RFC3775] the lookup key in the Binding Cache is the 347 Home Address of the MN. In particular, the base specification 348 [RFC3775] doesn't require the MN to include any identifier, 349 such as the MN-ID [RFC4283], in the Binding Update message 350 other than its Home Address. As described in [RFC4877], the 351 identifier of the MN is known by the Home Agent after the 352 IKEv2 exchange, but this is not used in the MIPv6 signaling, 353 nor as a lookup key for the binding cache. On the other hand, 354 as specified in [RFC5213], a Proxy Binding Update contains the 355 Home Prefix of the MN, the MN-ID and does not include the Home 356 Address of the MN (since it may not be known by the MAG and 357 consequently by the HA/LMA). The lookup key in the binding 358 cache of the LMA is either the home prefix or the MN-ID. This 359 implies that lookup keys for MIPv6 and PMIPv6 registrations 360 are different. Because of that, when the MN moves from its 361 home network (i.e. from the PMIPv6 domain) to the foreign 362 link, the Binding Update sent by the MN is not identified by 363 the HA as an update of the Proxy Binding Cache Entry 364 containing the home prefix of the MN, but a new binding cache 365 entry is created. Therefore PMIPv6 and MIPv6 will always 366 create two different binding cache entries in the HA/LMA which 367 implies that the HA and LMA are logically separated. How to 368 handle the presence of the two binding cache entries for the 369 same MN is described in Section 4.2. 371 2. MIPv6 de-registration Binding Update deletes PMIPv6 binding cache 372 entry 374 * When the mobile node moves from a MIPv6 foreign network to the 375 PMIPv6 home domain, the MAG registers the mobile node at the 376 LMA by sending a Proxy Binding Update. Subsequently, the LMA 377 updates the mobile node's binding cache entry with the MAG 378 address and the MAG emulates the mobile node's home link. 379 Upon detection of the home link, the mobile node will send a 380 de-registration Binding Update to its home agent. It is 381 necessary to make sure that the de-registration of the MIPv6 382 BU does not change the PMIPv6 binding cache entry just created 383 by the MAG. 385 3. Race condition between Binding Update and Proxy Binding Update 386 messages (Sequence Numbers and Timestamps) 388 * MIPv6 and PMIPv6 use different mechanisms for handling re- 389 ordering of registration messages and they are sent by 390 different entities. In MIPv6, Binding Update messages that 391 are sent by the mobile node to the home agent are ordered by 392 the sequence numbers. The other side, in PMIP, Proxy Binding 393 Update messages that are sent by the MAG to the LMA are 394 ordered by a timestamp option. When the mobile node moves 395 from one access where Mobile IP is used to another access when 396 Proxy Mobile IP is used, delay in the mobility signaling sent 397 may imply adverse situations. For example if the mobile node 398 sends a Mobile IP binding update from access A before moving 399 to access B and this binding update gets delayed (e.g. a 400 refresh binding update), the binding update may reach the 401 combined LMA/HA after the proxy binding update sent by the 402 MAG, re-directing packets to access A even after the mobile 403 has moved to access B. 405 4. Threat of compromised MAG 407 * In MIPv6 base specification [RFC3775] there is a strong 408 binding between the Home Address registered by the mobile node 409 and the Security Association used to modify the corresponding 410 binding cache entry. 412 * In PMIPv6 specification, the MAG sends proxy binding updates 413 on behalf of a mobile node to update the binding cache entry 414 that corresponds to the mobile node's home address. Since the 415 MAG sends the binding updates, PMIPv6 requires security 416 associations between each MAG and the LMA. 418 * As described in [RFC4832], in PMIPv6 the MAG compromise or 419 impersonation is an issue. RFC4832, section 2.2, describes 420 how a compromised MAG can harm the functionality of LMA, e.g. 421 manipulating LMA's routing table (or binding cache). 423 * In this mixed scenario, both host-based and network-based 424 security associations are used to update the same binding 425 cache entry at the HA/LMA (but see the first bullet of this 426 list, as the entry may not be the same). Based on this 427 consideration, the threat described in [RFC4832] is worse as 428 it affects also hosts that are using the LMA/HA as MIPv6 HA 429 and are not using PMIPv6 431 3.3. Issues related to scenario B 433 In this scenario there are two types of nodes in the access network: 434 some nodes support MIPv6 while some others do not. The rationale 435 behind such a scenario is that the nodes implementing MIPv6 manage 436 their own mobility to achieve better performance, e.g. for inter- 437 technology handovers. Obviously, nodes that do not implement MIPv6 438 must rely on the network to manage their mobility: therefore Proxy 439 MIPv6 is used for those nodes. 441 Based on the current PMIPv6 solution described in [RFC5213], in any 442 link of the PMIPv6 domain the MAG emulates the mobile node's home 443 link, advertising the home link prefix to the MN in a unicast Router 444 Advertisement message. This ensures that the IP address of the MN is 445 still considered valid by the MN itself. The home network prefix 446 (and any other information needed to emulate the home link) is 447 included in the mobile node's profile that is obtained by the MAG via 448 context transfer or via a policy store. 450 However, in case there are nodes that implement MIPv6 and want to use 451 this protocol, the network must offer MIPv6 service to them. In such 452 case the MAG should not emulate the home link. Instead of 453 advertising the MN-HNP, the MAG should advertise the topologically 454 correct local IP prefix, i.e. the prefix belonging to the MAG, so 455 that the MN detects an IP movement, configures a new CoA and sends a 456 MIPv6 Binding Update based on [RFC3775]. 458 4. Analysis of possible solutions 460 4.1. Solutions related to scenario A.1 462 As mentioned in Section 3.1, there are no significant issues in this 463 scenario. 465 Figures 5 and 6 show a scenario where a mobile node is moving from 466 one PMIPv6 domain to another, based on the scenario of Figure 1. In 467 Figure 5, the mobile node moves from an old MAG to MAG2 in the same 468 PMIPv6 domain: this movement triggers a PBU to LMA1 and the updating 469 of the binding cache at the LMA1; there is no MIPv6 signaling as the 470 CoA_1 registered at the HA is the Home Address for the PMIPv6 471 session. In Figure 6, the mobile node moves from MAG2 in the LMA1 472 PMIPv6 domain to MAG3 in a different PMIPv6 domain: this triggers the 473 PMIPv6 signaling and the creation of a binding at the LMA2. On the 474 other hand, the local address of the mobile node is changed, as the 475 LMA has changed, and therefore the mobile node sends a MIPv6 Binding 476 Update to the HA with the new CoA_2. 478 +----+ +------+ +------+ +----+ 479 | MN | | MAG2 | | LMA1 | | HA | 480 +----+ +------+ +------+ +----+ 481 | | | | 482 | | | +-----------------+ 483 | | | | HoA -> CoA_1 | 484 | | | | binding present | 485 | | | +-----------------+ 486 | | | | 487 | CoA conf/confirm | PBU(CoA_1,MAG_2) | | 488 | <--------------->| ----------------->| | 489 | | +-----------------+| 490 | | | CoA_1 -> MAG_2 || 491 | | | binding updated || 492 | | +-----------------+| 493 | | PBA | | 494 | | <----------------| | 495 | | | | 497 Figure 5 - Local Mobility Message Flow 499 +----+ +------+ +------+ +----+ 500 | MN | | MAG3 | | LMA2 | | HA | 501 +----+ +------+ +------+ +----+ 503 | CoA config | PBU(CoA_2,MAG_3) | | 504 |<---------------->|------------------->| | 505 | | +-----------------+ | 506 | | | CoA_2 -> MAG_3 | | 507 | | | binding created | | 508 | | +-----------------+ | 509 | | PBA | | 510 | |<-------------------| | 511 | | | | 512 | | BU (HoA, CoA_2) | | 513 |---------------------------------------------------->| 514 | | | | 515 | | | +-----------------+ 516 | | | | HoA -> CoA_2 | 517 | | | | binding updated | 518 | | | +-----------------+ 519 | | BA | | 520 |<----------------------------------------------------| 522 Figure 6 - Global Mobility Message Flow 524 4.2. Solutions related to scenario A.2 526 As described in Section 3.2, in this scenario the mobile node relies 527 on PMIPv6 as long as it is in the PMIPv6 domain. The mobile node 528 then uses MIPv6 whenever it moves out of the PMIPv6 domain which 529 basically implies that the MIPv6 home link is a PMIPv6 domain. 531 Analyzing the issues described in Section 3.2, it is clear that most 532 of them are applicable only to the case where there is a common 533 binding cache entry for the PMIPv6 registration and the MIPv6 534 registration. The issue 1 on how the two protocols identify the 535 binding cache entry is valid only in case we assume that a PMIPv6 536 message has any value for a MIPv6 BCE. Also the issues 2 and 3 are 537 not applicable in case different logical BCEs are used by the LMA and 538 the HA. For this reason, it is recommended that when the MIPv6 home 539 link is implemented as a PMIPv6 domain, the HA/LMA implementation 540 treats the two protocol as independent. 542 More in details the following principles should be followed by the 543 HA/LMA implementation: 545 o PMIPv6 signaling does not overwrite any MIPv6 BCE. In particular, 546 when a PMIPv6 binding cache entry is created for a mobile node 547 which has previously created a MIPv6 BCE, the MIPv6 binding cache 548 entry of the MN is not overwritten and a new PMIPv6 binding cache 549 entry is created. 551 o The downlink packets in the case where both the MIPv6 binding 552 cache entry and PMIPv6 binding cache entry exist are processed as 553 follows: 555 1. The MIPv6 binding cache entry is processed first. If the 556 destination address of the received downlink packet matches 557 the the binding cache entry of the HA, the packet is forwarded 558 by encapsulating it with the care-of-address contained in the 559 BCE. 561 2. If the destination address does not match the MIPv6 BCE, the 562 binding cache entry created by PMIPv6 is applied and the 563 packet are encapsualted to the registered MAG. 565 The following subsections provide a description of the procedures 566 which will be followed by the mobile node and HA/LMA based on the 567 above principles. The analysis is performed in two different 568 subsections, depending if the mobile node moves from a PMIPv6 domain 569 to a non-PMIPv6 domain or vice versa. 571 4.2.1. Mobility from a PMIPv6 domain to a non-PMIPv6 domain 573 Let's assume the mobile node is attached to a PMIPv6 domain and there 574 is a valid Proxy Binding Cache entry at the LMA. Then the mobile 575 node moves to a different access network and starts using MIPv6 (e.g. 576 because PMIPv6 is not supported). The mobile node needs to bootstrap 577 MIPv6 parameters and send a MIPv6 Binding Update in order to have 578 service continuity. Therefore the following steps must be performed 579 by the UE: 581 o HA/LMA address discovery: the mobile node needs to discover the IP 582 address of the LMA which has a valid binding cache entry for its 583 home network prefix. This is described in Section 3.2 as issue 4. 585 o Security Association establishment: the mobile node needs to 586 establish an IPsec Security Association with the HA/LMA as 587 described in [RFC4877] 589 o HoA or home network prefix assignment: as part of the MIPv6 590 bootstrapping procedure the HA assigns a MIPv6 HoA to the MN. 591 This address must be the same the mobile node was using in the 592 PMIPv6 domain. 594 Since all these steps must be performed by the mobile node before 595 sending the Binding Update, they have an impact on the handover 596 latency experienced by the MN. For this reason it is recommended 597 that the mobile node establishes the IPsec security association (and 598 consequently is provided by the HA/LMA with a MIPv6-HoA) when it is 599 initialized. This implies that the mobile node has MIPv6 stack 600 active while in the PMIPv6 domain, but as long as it is attached to 601 the same PMIPv6 domain, it will appear to the mobile node as if it is 602 attached to the home link. 604 In order to establish the security association with the HA/LMA, the 605 mobile node needs to discover the IP address of the LMA/HA while in 606 the PMIPv6 domain. This can be done either based on DNS or based on 607 DHCPv6, as described in [RFC5026] and [boot-integrated]. The network 608 should be configured so that the mobile node discovers or gets 609 assigned the same HA/LMA that was serving as the LMA in the PMIPv6 610 domain. Details of the exact procedure are out of scope of this 611 document. 613 When the mobile node establishes the security association, it 614 acquires a home address based on [RFC5026]. However, based on PMIPv6 615 operations, the LMA knows only the Home Network Prefix used by the 616 mobile node and does not know the MN-HoA.For this reason, the mobile 617 node must be configured to propose MN-HoA as the home address in the 618 IKEv2 INTERNAL_IP6_ADDRESS attribute during the IKEv2 exchange with 619 the HA/LMA. Alternatively the HA/LMA can be configured to provide 620 the entire Home Network Prefix via the MIP6_HOME_LINK attribute to 621 the mobile node as specified in [RFC5026]; based on this Home Network 622 Prefix the mobile node can configure a home address. Note that the 623 security association must be bound to the MN-HoA used in the PMIPv6 624 domain as per [RFC4877]. Note that the home network prefix is shared 625 between the LMA and HA and this implies that there is an interaction 626 between the LMA and the HA in order to assign a common home network 627 prefix when triggered by PMIPv6 and MIPv6 signaling 629 When the mobile node hands over to an access network which does not 630 support Proxy Mobile IPv6, it sends a Binding Update to the HA. The 631 mobile node may set the R bit defined in NEMO specification (implicit 632 mode) [RFC3963]in order to indicate that the entire HNP is moved to 633 the new CoA. A MIPv6 binding cache entry is created irrespective of 634 the existing PMIPv6 BCE. Packets matching the MIPv6 binding cache 635 entry are sent to the CoA present in the MIPv6 BCE. The PMIPv6 636 binding cache entry will expire in case the MAG does not send a 637 refresh PBU. 639 4.2.2. Mobility from a non-PMIPv6 domain to a PMIPv6 domain 641 In this section it is assumed that the mobile node is in a non-PMIPv6 642 access network and it has bootstrapped MIPv6 operations based on 643 [RFC5026]; therefore there is valid binding cache for its MIPv6-HoA 644 (or HNP in case of NEMO) at the HA. Then the mobile node moves to a 645 PMIPv6 domain which is configured to be the home link for the MIPv6- 646 HoA the mobile node has been assigned. 648 In order to provide session continuity, the MAG needs to send a PBU 649 to the HA/LMA that was serving the MN. The MAG needs to discover the 650 HA/LMA; however the current version of [RFC5213] assumes that the LMA 651 is assigned to the MAG or discovered by the MAG when the mobile node 652 attaches to the MAG. the exact mechanism is not specified in 653 [RFC5213]. A detailed description of the necessary procedure is out 654 of the scope of this document. Note that the MAG may also rely on 655 static configuration or lower layer information provided by the 656 mobile node in order to select the correct HA/LMA. 658 The PBU sent by the MAG creates a PMIPv6 binding cache entry for the 659 mobile node which is independent of the MIPv6 BCE. Traffic destined 660 to the MIPv6-HoA (or to the HNP in case the mobile node had set the 661 flag R in the last BU) is still forwarded to the CoA present in the 662 MIPv6 BCE. When the mobile node wants to use the HoA directly from 663 the home link, it sends a de-registration message and at that point 664 only the PMIPv6 binding cache entry is present. 666 4.3. Solutions related to scenario B 668 The solution for this scenario depends on the access network being 669 able to determine that a particular mobile node wants to use Mobile 670 IPv6. This requires a solution at the system level for the access 671 network and may require knowledge of the detailed configuration and 672 software capabilities of every mobile node in the system. These 673 issues are out of scope of this document 675 5. Security Considerations 677 Scenario A.1 does not introduce any new security issues in addition 678 to those described in [RFC5213] or [RFC3775]. 680 For scenario A.2, this document requires that the a home agent that 681 also implements the PMIPv6 LMA functionality should allow both the 682 mobile node and the authorized MAGs to modify the binding cache 683 entries for the mobile node. Note that the compromised MAG threat 684 described in [RFC4832] applies also here in a more severe form as 685 explained in Section 3.2. Scenario B relies on the secure 686 identification of mobile nodes and their capabilities so that the 687 right service can be provided for the right mobile nodes. For 688 instance, a malicious mobile node should not get the home address of 689 some other node assigned to it, and a mobile node that desires to 690 employ its own mobility management should be able to do so. The 691 ability to identify nodes is already a requirement in [RFC5213], but 692 scenario B adds a requirement on identification of node capabilities. 694 6. IANA considerations 696 This document has no IANA actions. 698 7. Additional Authors 700 Chowdhury, Kuntal - kchowdhury@starentnetworks.com 702 Hesham Soliman - Hesham@elevatemobile.com 704 Vijay Devarapalli - vijay.devarapalli@azairenet.com 706 Sri Gundavelli - sgundave@cisco.com 708 Kilian Weniger - Kilian.Weniger@googlemail.com 710 Genadi Velev - Genadi.Velev@eu.panasonic.com 711 Ahmad Muhanna - amuhanna@nortel.com 713 George Tsirtsis - tsirtsis@googlemail.com 715 Suresh Krishnan - suresh.krishnan@ericsson.com 717 8. Acknowledgements 719 This document is a merge of four different Internet Drafts: 720 draft-weniger-netlmm-pmipv6-mipv6-issues-00, 721 draft-devarapalli-netlmm-pmipv6-mipv6-01, 722 draft-tsirtsis-logically-separate-lmaha-01and 723 draft-giaretta-netlmm-mip-interactions-00. Thanks to the authors and 724 editors of those drafts. 726 The authors would also like to thank Jonne Soininen and Vidya 727 Narayanan, NETLMM WG chairs, for their support. 729 9. References 731 9.1. Normative References 733 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 734 Requirement Levels", BCP 14, RFC 2119, March 1997. 736 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 737 in IPv6", RFC 3775, June 2004. 739 [RFC3963] Devarapalli, V., "Network Mobility (NEMO) Basic Support 740 Protocol", January 2005, 741 . 743 [RFC4140] Soliman, H., "Hierarchical Mobile IPv6 Mobility Management 744 (HMIPv6)", August 2005, 745 . 747 [RFC4832] Vogt, C. and J. Kempf, "Security Threats to Network-Based 748 Localized Mobility Management (NETLMM)", April 2007. 750 [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 751 IKEv2 and the Revised IPsec Architecture", 2005. 753 [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 754 Bootstrapping in Split Scenario", RFC 5026, October 2007. 756 [RFC5213] Gundavelli, S., "Proxy Mobile IPv6", August 2008. 758 [boot-integrated] 759 Chowdhury, K., Ed., "MIP6-bootstrapping for the Integrated 760 Scenario", 2007. 762 9.2. Informative References 764 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 765 RFC 3753, June 2004. 767 [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 768 Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 769 (MIPv6)", RFC 4283, November 2005. 771 Author's Address 773 Gerardo Giaretta (editor) 774 Qualcomm 776 Email: gerardog@qualcomm.com