idnits 2.17.1 draft-ietf-netlmm-mip-interactions-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 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 (February 23, 2009) is 5535 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'MN' is mentioned on line 276, but not defined == Missing Reference: 'RFC4830' is mentioned on line 294, but not defined == Unused Reference: 'RFC4831' is defined on line 725, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) Summary: 3 errors (**), 0 flaws (~~), 5 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 February 23, 2009 5 Expires: August 19, 2009 7 Interactions between PMIPv6 and MIPv6: scenarios and related issues 8 draft-ietf-netlmm-mip-interactions-02 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on August 19, 2009. 33 Abstract 35 The scenarios where Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6 36 (MIPv6) protocols are both deployed in a network require some 37 analysis and considerations. This document describes all identified 38 possible scenarios, which require an interaction between PMIPv6 and 39 MIPv6 and discusses all issues related to these scenarios. Solutions 40 and reccomendations to enable these scenarios are also described. 42 Requirements Language 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 45 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 46 document are to be interpreted as described in RFC 2119 [RFC2119]. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Overview of the scenarios and related issues . . . . . . . . . 4 53 3.1. Issues related to scenario A . . . . . . . . . . . . . . . 9 54 3.2. Issues related to scenario B . . . . . . . . . . . . . . . 9 55 3.3. Issues related to scenario C . . . . . . . . . . . . . . . 10 56 4. Analysis of possible solutions . . . . . . . . . . . . . . . . 12 57 4.1. Solutions related to scenario A . . . . . . . . . . . . . 12 58 4.2. Solutions related to scenario B . . . . . . . . . . . . . 13 59 4.3. Solutions related to scenario C . . . . . . . . . . . . . 13 60 4.3.1. Mobility from a PMIPv6 domain to a non-PMIPv6 61 domain . . . . . . . . . . . . . . . . . . . . . . . . 14 62 4.3.2. Mobility from a non-PMIPv6 domain to a PMIPv6 63 domain . . . . . . . . . . . . . . . . . . . . . . . . 16 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 65 6. Additional Authors . . . . . . . . . . . . . . . . . . . . . . 16 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 68 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 69 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 71 Intellectual Property and Copyright Statements . . . . . . . . . . 19 73 1. Introduction 75 Proxy Mobile IPv6 [RFC5213] is a network based IP mobility protocol 76 standardized by IETF. In some deployment scenarios this protocol 77 will be deployed together with MIPv6 [RFC3775], for example with 78 PMIPv6 as local mobility protocol and MIPv6 as global mobility 79 protocol. While the usage of a local mobility protocol should not 80 have implications of how global mobility is managed, since PMIPv6 is 81 partially based on MIPv6 signaling and data structure, some 82 considerations are needed to understand how the protocols interact 83 and how the different scenarios can be enabled. 85 Some SDOs are also investigating more complex scenarios where the 86 mobility of some nodes are handled using Proxy Mobile IPv6, while 87 other nodes use Mobile IPv6; or the mobility of a node is managed in 88 turn by a host-based and a network-based mechanism. This needs also 89 to be analyzed as a possible deployment scenario. 91 This document provides a taxonomy of all scenarios that require 92 direct interaction between MIPv6 and PMIPv6. Moreover, this document 93 presents and identifies all issues pertained to these scenarios and 94 discusses possible means and mechanisms that are recommended to 95 enable them. 97 2. Terminology 99 General mobility terminology can be found in [RFC3753]. The 100 following acronyms are used in this document: 102 MN-HoA: the home address of a mobile node in a Proxy Mobile IPv6 103 domain. 105 MN-HNP: the IPv6 prefix that is always present in the Router 106 Advertisements that the mobile node receives when it is attached 107 to any of the access links in that Proxy Mobile IPv6 domain. MN- 108 HoA always belongs to this prefix. 110 MIPv6-HoA: the Home Address the MN includes in MIPv6 binding 111 update messages. 113 MIPv6-CoA: the Care-of Address the MN includes in MIPv6 binding 114 update messages. 116 3. Overview of the scenarios and related issues 118 Several scenarios can be identified where Mobile IPv6 and Proxy 119 Mobile IPv6 are deployed in the same network. This document does not 120 only focus on scenarios where the two protocols are used by the same 121 mobile node to manage local and global mobility, but it investigates 122 also more complex scenarios where the protocols are more tightly 123 integrated or where there is a co-existence of nodes which do or do 124 not implement Mobile IPv6. 126 The following scenarios are identified: 128 o Scenario A - in this scenario Proxy Mobile IPv6 is used as a 129 network based local mobility management protocol whereas Mobile 130 IPv6 is used as a global mobility management protocol. This 131 interaction is very similar to the HMIPv6-MIPv6 interaction; 132 Mobile IPv6 is used to manage mobility among different access 133 networks, while the mobility within the access network is handled 134 by Proxy Mobile IPv6. The address managed by PMIPv6 (i.e. the MN- 135 HoA) is registered as Care-of Address by the MN at the HA. This 136 means that the HA has a binding cache entry for MIPv6-HoA that 137 points to the MN-HoA. 139 The following figure illustrates this scenario. 141 +----+ 142 | HA | MIPv6-HoA -> MN-HoA 143 +----+ 144 /\ 145 / \ 146 +-------------/----\--------------+ 147 ( / \ ) Global Mobile IPv6 148 ( / \ ) Domain 149 +----------/----------\-----------+ 150 / \ 151 +----+ +----+ 152 MN-HoA -> MAG1 |LMA1| |LMA2| 153 +----+ +----+ 154 //\\ \\ 155 +----//--\\---+ +-----\\------+ 156 ( // \\ ) ( \\ ) Local Mobility Network 157 ( // \\ ) ( \\ ) PMIPv6 domain 158 +-//--------\\+ +--------\\---+ 159 // \\ \\ 160 // \\ \\ 161 // \\ \\ 162 +----+ +----+ +----+ 163 |MAG1| |MAG2| |MAG3| 164 +----+ +----+ +----+ 165 | | | 166 [MN] 168 Figure 1 - Scenario A 170 o Scenario B - in this scenario some mobile nodes use Mobile IPv6 to 171 manage their movements while others rely on a network-based 172 mobility solution provided by the network as they don't support 173 Mobile IPv6. There may be a common mobility anchor that acts as 174 Mobile IPv6 Home Agent and Proxy Mobile IPv6 LMA, depending on the 175 type of the node as depicted in the figure. However, the LMA and 176 HA can be also separated and this has no impacts to the mobility 177 of the nodes. 179 +--------+ 180 | HA/LMA | 181 +--------+ 183 +------+ +------+ 184 | MAG1 | | MAG2 | 185 +------+ +------+ 187 +-----------+ 188 | IPv6 host | -----------------> 189 +-----------+ movement 190 +----------+ 191 | MIPv6 MN | -----------------> 192 +----------+ movement 194 Figure 2 - Scenario B 196 o Scenario C - in this scenario the mobile node is moving across 197 different access networks, some of them supporting Proxy Mobile 198 IPv6 and some others not supporting it. Therefore the mobile node 199 is roaming from an access network where the mobility is managed 200 through a network-based solution to an access network where a 201 host-based management (i.e. Mobile IPv6) is needed. This 202 scenario may have different sub-scenarios depending on the 203 relations between the Mobile IPv6 home network and the Proxy 204 Mobile IPv6 domain. The following figure illustrates an example 205 of this scenario, where the MN is moving from an access network 206 where PMIPv6 is supported (i.e. MAG functionality is supported) 207 to a network where PMIPv6 is not supported (i.e. MAG 208 functionality is not supported by the AR). This implies that the 209 home link of the MN is actually a PMIPv6 domain. In this case the 210 MIPv6-HoA is equal to the MN-HoA (i.e. the address managed by 211 PMIPv6). 213 MIPv6-HoA == MN-HoA -> MAG1 214 +------+ 215 |HA/LMA|-----------------------+ 216 +------+ | 217 //\\ | 218 +-------//--\\--------+ | 219 ( // \\ PMIPv6 ) | 220 ( // \\ domain) +--------------+ 221 +----//--------\\-----+ ( Non-PMIPv6 ) 222 // \\ ( domain ) 223 // \\ +--------------+ 224 // \\ | 225 +----+ +----+ +----+ 226 |MAG1| |MAG2| | AR | 227 +----+ +----+ +----+ 228 | | | 229 [MN] 231 Figure 3 - Scenario C 233 In the above figure the non-PMIPv6 domain can actually be also a 234 different PMIPv6 domain that handles a different MN_HoA. The 235 following figure illustrates this sub-case: the MIPv6-HoA is equal 236 to the MN_HoA; however when the MN hands over to MAG3 it gets a 237 different IP address (managed by LMA2 using PMIPv6) and registers 238 it as a MIPv6 CoA. 240 MIPv6-HoA == MN-HoA -> MAG_1 241 +-------+ 242 |HA/LMA1|-----------------------+ 243 +-------+ | 244 //\\ +----+ 245 +-------//--\\--------+ |LMA2| 246 ( // \\ home ) +----+ 247 ( // \\ PMIPv6) +------||------+ 248 ( // \\domain) ( ||visited) 249 +---//----------\\----+ ( ||PMIPv6 ) 250 // \\ ( ||domain ) 251 // \\ +------||------+ 252 +----+ +----+ +----+ 253 |MAG1| |MAG2| |MAG3| 254 +----+ +----+ +----+ 255 | | | 256 [MN] 258 (a) 260 MIPv6-HoA -> MN_CoA 261 +-------+ 262 |HA/LMA1|-----------------------+ 263 +-------+ | 264 //\\ +----+ 265 +-------//--\\--------+ |LMA2| MN_CoA -> MAG3 266 ( // \\ home ) +----+ 267 ( // \\ PMIPv6) +------||------+ 268 ( // \\domain) ( ||visited) 269 +---//----------\\----+ ( ||PMIPv6 ) 270 // \\ ( ||domain ) 271 // \\ +------||------+ 272 +----+ +----+ +----+ 273 |MAG1| |MAG2| |MAG3| 274 +----+ +----+ +----+ 275 | | | 276 [MN] 278 (b) 280 Figure 4 - Scenario C with visited PMIPv6 domain 282 Note that some of the scenarios can be combined. For instance, 283 scenario B can be combined with scenario A or scenario C. 285 The following sections describe some possible issues for each 286 scenario. Respective recommendations are described in Section 4.3. 287 The specifications considered as a baseline for the analysis are the 288 following: [RFC3775], [RFC4877] and [RFC5213]. 290 3.1. Issues related to scenario A 292 This scenarios is very similar to other hierarchical mobility 293 schemes, including a HMIPv6-MIPv6 scheme. This is the scenario 294 referenced in [RFC4830]. No issues have been identified in this 295 scenario. Note that a race condition where the MN registers the CoA 296 at the HA before the CoA is actually bound to the MAG at the LMA is 297 not possible. The reason is that per PMIPv6 specification the MAG 298 does not forward any packets sent by the MN until the PMIPv6 tunnel 299 is up, regardless the mechanism used for address allocation. 301 Section 4.1 describes one message flow in case PMIPv6 is used as a 302 local mobility protocol and MIPv6 is used as a global mobility 303 protocol. 305 3.2. Issues related to scenario B 307 In this scenario there are two types of nodes in the access network: 308 some nodes support Mobile IPv6 while some others do not. The 309 rationale behind such a scenario is that the nodes implementing 310 Mobile IPv6 manage their own mobility to achieve better performance, 311 e.g. for inter-technology handovers. Obviously, nodes that do not 312 implement MIPv6 must rely on the network to manage their mobility: 313 therefore Proxy MIPv6 is used for those nodes. 315 Based on the current PMIPv6 solution described in [RFC5213], in any 316 link of the PMIPv6 domain the MAG emulates the mobile node's home 317 link, advertising the home link prefix to the MN in a unicast Router 318 Advertisement message. This ensures that the IP address of the MN is 319 still considered valid by the MN itself. The home network prefix 320 (and any other information needed to emulate the home link) is 321 included in the mobile node's profile that is obtained by the MAG via 322 context transfer or via a policy store. 324 However, in case there are nodes that implement Mobile IPv6 and want 325 to use this protocol, the network must offer MIPv6 service to them. 326 In such case the MAG should not emulate the home link. Instead of 327 advertising the HNP, the MAG should advertise the topologically 328 correct local IP prefix, i.e. the prefix belonging to the MAG, so 329 that the MN detects an IP movement, configures a new CoA and sends a 330 MIPv6 Binding Update based on [RFC3775]. 332 3.3. Issues related to scenario C 334 This section highlights some considerations that are applicable to 335 scenario C where the LMA and HA are logically collocated and need to 336 be evaluated when selecting the technical approach to be chosen. 338 1. HoA management and lookup key in the binding cache 340 * in MIPv6 [RFC3775] the lookup key in the Binding Cache is the 341 Home Address of the MN. In particular, based on the base 342 specification [RFC3775], the MN does not include any 343 identifier, such as the MN-ID [RFC4283], in the Binding Update 344 message other than its Home Address. As described in 345 [RFC4877], the identifier of the MN is known by the Home Agent 346 after the IKEv2 exchange, but this is not used in the MIPv6 347 signaling, nor as a lookup key for the binding cache. On the 348 other hand, as specified in [RFC5213], a Proxy Binding Update 349 contains the Home Prefix of the MN, the MN-ID and does not 350 include the Home Address of the MN (since it may not be known 351 by the MAG and consequently by the HA/LMA). The lookup key in 352 the binding cache of the LMA is either the home prefix or the 353 MN-ID. This implies that lookup keys for MIPv6 and PMIPv6 354 registrations are different. Because of that, when the MN 355 moves from its home network (i.e. from the PMIPv6 domain) to 356 the foreign link, the Binding Update sent by the MN is not 357 identified by the HA as an update of the Proxy Binding Cache 358 Entry containing the home prefix of the MN, but a new binding 359 cache entry is created. Therefore PMIPv6 and MIPv6 will 360 always create two different binding cache entries in the HA/ 361 LMA which implies that the HA and LMA are logically separated. 362 How to handle the presence of the two binding cache entries 363 for the same MN is described in Section 4.3. 365 2. MIPv6 de-registration Binding Update deletes PMIPv6 binding cache 366 entry 368 * When the mobile node moves from a MIPv6 foreign network to the 369 PMIPv6 home domain, the MAG registers the mobile node at the 370 LMA by sending a Proxy Binding Update. Subsequently, the LMA 371 updates the mobile node's binding cache entry with the MAG 372 address and the MAG emulates the mobile node's home link. 373 Upon detection of the home link, the mobile node will send a 374 de-registration Binding Update to its home agent. It is 375 necessary to make sure that the de-registration of the MIPv6 376 BU does not change the PMIPv6 BCE just created by the MAG. 378 3. Race condition between Binding Update and Proxy Binding Update 379 messages (Sequence Numbers and Timestamps) 381 * MIPv6 and PMIPv6 use different mechanisms for handling re- 382 ordering of registration messages and they are sent by 383 different entities. Whereas Binding Update messages are 384 ordered by a sequence numbers and sent by the mobile node, 385 Proxy Binding Update messages are ordered by a timestamp 386 option and sent by MAGs. 388 4. Use of wrong home agent or LMA after handover 390 * This issues can arise if multiple LMAs are deployed in the 391 PMIP home domain. If the mobile node moves from a MIPv6 392 foreign network to the PMIPv6 home domain, the MAG must send 393 the Proxy Binding Update to the particular LMA that is co- 394 located with the home agent which maintains the active binding 395 cache entry of the mobile node. If a different LMA is 396 assigned to the MAG, the MN will not be on the home link but 397 will still have MIPv6 active and this may be not desirable in 398 some deployments. 400 * Similarly, if the mobile node moves from the PMIPv6 home 401 domain to a MIPv6 foreign network, the mobile node must send 402 the Binding Update to the particular home agent that is co- 403 located with the LMA which maintains the active proxy binding 404 cache entry of the mobile node. If the mobile node selects a 405 different home agent, packets addressed to the mobile node's 406 home address do not reach the mobile node. 408 5. Threat of compromised MAG 410 * In MIPv6 base specification [RFC3775] there is a strong 411 binding between the Home Address registered by the MN and the 412 Security Association used to modify the corresponding binding 413 cache entry. 415 * In PMIPv6 specification, the MAG sends proxy binding updates 416 on behalf of a mobile node to update the binding cache entry 417 that corresponds to the mobile node's home address. Since the 418 MAG sends the binding updates, PMIPv6 requires security 419 associations between each MAG and the LMA. 421 * As described in [RFC4832], in PMIPv6 the MAG compromise or 422 impersonation is an issue. RFC4832, section 2.2, describes 423 how a compromised MAG can harm the functionality of LMA, e.g. 424 manipulating LMA's routing table (or binging cache). 426 * In this mixed scenario, both host-based and network-based 427 security associations are used to update the same binding 428 cache entry at the HA/LMA (but see the first bullet of this 429 list, as the entry may not be the same). Based on this 430 consideration, the threat described in [RFC4832] is worse as 431 it affects also hosts that are using the LMA/HA as MIPv6 HA 432 and are not using PMIPv6. 434 4. Analysis of possible solutions 436 4.1. Solutions related to scenario A 438 As mentioned in Section 3.1, there are no significant issues in this 439 scenario. 441 Figures 5 and 6 show a scenario where a MN is moving from one PMIPv6 442 domain to another, based on the scenario of Figure 1. In Figure 5, 443 the MN moves from an old MAG to MAG2 in the same PMIPv6 domain: this 444 movement triggers a PBU to LMA1 and the updating of the binding cache 445 at the LMA1; there is no MIPv6 signaling as the CoA_1 registered at 446 the HA is the Home Address for the PMIPv6 session. In Figure 6, the 447 MN moves from MAG2 in the LMA1 PMIPv6 domain to MAG3 in a different 448 PMIPv6 domain: this triggers the PMIPv6 signaling and the creation of 449 a binding at the LMA2. On the other hand, the local address of the 450 MN is changed, as the LMA hss changed, and therefore the MN sends a 451 MIPv6 Binding Update to the HA with the new CoA_2. 453 +----+ +------+ +------+ +----+ 454 | MN | | MAG2 | | LMA1 | | HA | 455 +----+ +------+ +------+ +----+ 456 | | | | 457 | | | +-----------------+ 458 | | | | HoA -> CoA_1 | 459 | | | | binding present | 460 | | | +-----------------+ 461 | | | | 462 | CoA conf/confirm | PBU(CoA_1,MAG_2) | | 463 | <--------------->| ----------------->| | 464 | | +-----------------+| 465 | | | CoA_1 -> MAG_2 || 466 | | | binding updated || 467 | | +-----------------+| 468 | | PBA | | 469 | | <----------------| | 470 | | | | 471 Figure 5 - Local Mobility Message Flow 473 +----+ +------+ +------+ +----+ 474 | MN | | MAG3 | | LMA2 | | HA | 475 +----+ +------+ +------+ +----+ 477 | CoA config | PBU(CoA_2,MAG_3) | | 478 |<---------------->|------------------->| | 479 | | +-----------------+ | 480 | | | CoA_2 -> MAG_3 | | 481 | | | binding created | | 482 | | +-----------------+ | 483 | | PBA | | 484 | |<-------------------| | 485 | | | | 486 | | BU (HoA, CoA_2) | | 487 |---------------------------------------------------->| 488 | | | | 489 | | | +-----------------+ 490 | | | | HoA -> CoA_2 | 491 | | | | binding updated | 492 | | | +-----------------+ 493 | | BA | | 494 |<----------------------------------------------------| 496 Figure 6 - Global Mobility Message Flow 498 4.2. Solutions related to scenario B 500 The solution for this scenario may depend on the access network being 501 able to determine that a particular mobile node wants to use Mobile 502 IPv6. This requires a solution at the system level for the access 503 network and is out of scope of this document. Solutions that do not 504 depend on the access network are out of the scope of this document. 506 4.3. Solutions related to scenario C 508 As described in Section 3.3, in this scenario the mobile node relies 509 on Proxy Mobile IPv6 as long as it is in the Proxy Mobile IPv6 510 domain. The mobile node then uses Mobile IPv6 whenever it moves out 511 of the PMIPv6 domain which basically implies that the MIPv6 home link 512 is a PMIPv6 domain. 514 Analyzing the issues described in Section 3.3, it is clear that most 515 of them are applicable only to the case where there is a common BCE 516 for the PMIPv6 registration and the MIPv6 registration. The issue 1 517 on how the two protocols identify the BCE is valid only in case we 518 assume that a PMIPv6 message has any value for a MIPv6 BCE. Also the 519 issues 2 and 3 are not applicable in case different logical BCEs are 520 used by the LMA and the HA. For this reason, it is recommended that 521 when the MIPv6 home link is implemented as a PMIPv6 domain, the HA/ 522 LMA implementation treats the two protocol as independent. 524 More in details the following principles should be followed by the 525 HA/LMA implementation: 527 o PMIPv6 signaling does not overwrite any MIPv6 BCE. In particular, 528 when a PMIPv6 binding cache entry is created for a MN which has 529 previously created a MIPv6 BCE, the MIPv6 BCE of the UE is not 530 overwritten and a new PMIPv6 BCE is created. 532 o The downlink packets in the case where both the MIPv6 BCE and 533 PMIPv6 BCE exist are processed as follows: 535 1. The MIPv6 BCE is processed first. If the destination address 536 of the received downlink packet matches the the BCE of the HA, 537 the packet is forwarded by encapsulating it with the care-of- 538 address contained in the BCE. 540 2. If the destination address does not match the MIPv6 BCE, the 541 BCE created by PMIPv6 is applied and the packet are 542 encapsualted to the registered MAG. 544 The following subsections provide a description of the procedures 545 which will be followed by the MN and HA/LMA based on the above 546 principles. The analysis is performed in two different subsections, 547 depending if the MN moves from a PMIPv6 domain to a non-PMIPv6 domain 548 or vice versa. 550 4.3.1. Mobility from a PMIPv6 domain to a non-PMIPv6 domain 552 Let's assume the MN is attached to a PMIPv6 domain and there is a 553 valid Proxy Binding Cache entry at the LMA. Then the MN moves to a 554 different access network and starts using MIPv6 (e.g. because PMIPv6 555 is not supported). The MN needs to bootstrap MIPv6 parameters and 556 send a MIPv6 Binding Update in order to have service continuity. 557 Therefore the following steps must be performed by the UE: 559 o HA/LMA address discovery: the MN needs to discover the IP address 560 of the LMA which has a valid binding cache entry for its home 561 network prefix. This is described in Section 3.3 as issue 4. 563 o Security Association establishment: the MN needs to establish an 564 IPsec Security Association with the HA/LMA as described in 565 [RFC4877] 567 o HoA or home network prefix assignment: as part of the MIPv6 568 bootstrapping procedure the HA assigns a MIPv6 HoA to the MN. 569 This address must be the same the MN was using in the PMIPv6 570 domain. 572 Since all these steps must be performed by the MN before sending the 573 Binding Update, they have an impact on the handover latency 574 experienced by the MN. For this reason it is recommended that the MN 575 establishes the IPsec security association (and consequently is 576 provided by the HA/LMA with a MIPv6-HoA) when it is still attached to 577 the PMIPv6 domain. This implies that the mobile node has Mobile IPv6 578 stack active while in the PMIPv6 domain, but as long as it is 579 attached to the same Proxy Mobile IPv6 domain, it will appear to the 580 mobile node as if it is attached to the home link. 582 In order to establish the security association with the HA/LMA, the 583 MN needs to discover the IP address of the LMA/HA while in the PMIPv6 584 domain. This can be done either based on DNS or based on DHCPv6, as 585 described in [RFC5026] and [boot-integrated]. The network should be 586 configured so that the MN discovers or gets assigned the same HA/LMA 587 that was serving as the LMA in the PMIPv6 domain. Details of the 588 exact procedure are out of scope of this document. 590 When the MN establishes the security association, it acquires a home 591 address based on [RFC5026]. However, based on PMIPv6 operations, the 592 LMA knows only the Home Network Prefix used by the MN and does not 593 know the MN-HoA.For this reason, the MN must be configured to propose 594 MN-HoA as the home address in the IKEv2 INTERNAL_IP6_ADDRESS 595 attribute during the IKEv2 exchange with the HA/LMA. Alternatively 596 the HA/LMA can be configured to provide the entire Home Network 597 Prefix via the MIP6_HOME_LINK attribute to the MN as specified in 598 [RFC5026]; based on this Home Network Prefix the MN can configure a 599 home address. Note that the security association must be bound to 600 the MN-HoA used in the PMIPv6 domain as per [RFC4877]. Note that the 601 home network prefix is shared between the LMA and HA and this implies 602 that there is an interaction between the LMA and the HA in order to 603 assign a common home netowrk prefix when triggered by PMIPv6 and 604 MIPv6 signaling 606 When the MN hands over to an access network which does not support 607 Proxy Mobile IPv6, it sends a Binding Update to the HA. The MN may 608 set the R bit defined in NEMO specification (implicit mode) in order 609 to indicate that the entire HNP is moved to the new CoA. A MIPv6 BCE 610 is created irrespective of the existing PMIPv6 BCE. Packets matching 611 the MIPv6 BCE are sent to the CoA present in the MIPv6 BCE. The 612 PMIPv6 BCE will expire in case the MAG does not send a refresh PBU. 614 4.3.2. Mobility from a non-PMIPv6 domain to a PMIPv6 domain 616 In this section it is assumed that the MN is in a non-PMIPv6 access 617 network and it has bootstrapped MIPv6 operations based on [RFC5026]; 618 therefore there is valid binding cache for its MIPv6-HoA (or HNP in 619 case of NEMO) at the HA. Then the MN moves to a PMIPv6 domain which 620 is configured to be the home link for the MIPv6-HoA the MN has been 621 assigned. 623 In order to provide session continuity, the MAG needs to send a PBU 624 to the HA/LMA that was serving the MN. The MAG needs to discover the 625 HA/LMA; however the current version of [RFC5213] assumes that the LMA 626 is assigned to the MAG or discovered by the MAG when the MN attaches 627 to the MAG. the exact mechanism is not specified in [RFC5213]. A 628 detailed description of the necessary procedure is out of the scope 629 of this document. Note that the MAG may also rely on static 630 configuration or lower layer information provided by the MN in order 631 to select the correct HA/LMA. 633 The PBU sent by the MAG creates a PMIPv6 BCE for the MN which is 634 independent of the MIPv6 BCE. Traffic destined to the MIPv6-HoA (or 635 to the HNP in case the MN had set the flag R in the last BU) is still 636 forwarded to the CoA present in the MIPv6 BCE. When the MN wants to 637 use the HoA directly from the home link, it sends a de-registration 638 message and at that point only the PMIPv6 BCE is present. 640 5. Security Considerations 642 Scenarios A and B described in Section 3 do not introduce any 643 security considerations in addition to those described in [pmipv6- 644 draft] or [RFC3775]. 646 This document requires that the a home agent that also implements the 647 PMIPv6 LMA functionality should allow both the mobile node and the 648 authorized MAGs to modify the binding cache entries for the mobile 649 node. Note that the compromised MAG threat described in [RFC4832] 650 applies also here. 652 6. Additional Authors 654 Chowdhury, Kuntal - kchowdhury@starentnetworks.com 656 Hesham Soliman - Hesham@elevatemobile.com 657 Vijay Devarapalli - vijay.devarapalli@azairenet.com 659 Sri Gundavelli - sgundave@cisco.com 661 Kilian Weniger - Kilian.Weniger@googlemail.com 663 Genadi Velev - Genadi.Velev@eu.panasonic.com 665 Ahmad Muhanna - amuhanna@nortel.com 667 George Tsirtsis - tsirtsis@googlemail.com 669 Suresh Krishnan - suresh.krishnan@ericsson.com 671 7. Acknowledgements 673 This document is a merge of four different Internet Drafts: 674 draft-weniger-netlmm-pmipv6-mipv6-issues-00, 675 draft-devarapalli-netlmm-pmipv6-mipv6-01, 676 draft-tsirtsis-logically-separate-lmaha-01and 677 draft-giaretta-netlmm-mip-interactions-00. Thanks to the authors and 678 editors of those drafts. 680 The authors would also like ot thank Jonne Soininen and Vidya 681 Narayanan, NETLMM WG chairs, for their support. 683 8. References 685 8.1. Normative References 687 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 688 Requirement Levels", BCP 14, RFC 2119, March 1997. 690 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 691 in IPv6", RFC 3775, June 2004. 693 [RFC4832] Vogt, C. and J. Kempf, "Security Threats to Network-Based 694 Localized Mobility Management (NETLMM)", April 2007. 696 [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 697 IKEv2 and the Revised IPsec Architecture", 2005. 699 [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 700 Bootstrapping in Split Scenario", RFC 5026, October 2007. 702 [RFC5213] Gundavelli, S., "Proxy Mobile IPv6", August 2008. 704 [boot-integrated] 705 Chowdhury, K., Ed., "MIP6-bootstrapping for the Integrated 706 Scenario", 2007. 708 [draft-tsirtsis] 709 Tsirtsis, G., "Behavior of Collocated HA/LMA", April 2008, 710 draft-tsirtsis-logically-separate-lmaha-01.txt 712 [pmipv6-draft] 713 Gundavelli, S., Ed., "Proxy Mobile IPv6", 2007, 714 draft-ietf-netlmm-proxymip6-01.txt 716 8.2. Informative References 718 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 719 RFC 3753, June 2004. 721 [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 722 Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 723 (MIPv6)", RFC 4283, November 2005. 725 [RFC4831] Kempf, J., "Goals for Network-Based Localized Mobility 726 Management (NETLMM)", RFC 4831, April 2007. 728 Author's Address 730 Gerardo Giaretta (editor) 731 Qualcomm 733 Email: gerardog@qualcomm.com 735 Full Copyright Statement 737 Copyright (c) 2009 IETF Trust and the persons identified as the 738 document authors. All rights reserved. 740 This document is subject to BCP 78 and the IETF Trust's Legal 741 Provisions Relating to IETF Documents in effect on the date of 742 publication of this document (http://trustee.ietf.org/license-info). 743 Please review these documents carefully, as they describe your 744 rights and restrictions with respect to this document.