idnits 2.17.1 draft-ietf-netlmm-mip-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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 778. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 789. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 796. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 802. 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 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 (November 15, 2008) is 5641 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'MN' is mentioned on line 279, but not defined == Missing Reference: 'RFC4830' is mentioned on line 304, but not defined == Unused Reference: 'RFC4831' is defined on line 754, 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 (==), 7 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 November 15, 2008 5 Expires: May 19, 2009 7 Interactions between PMIPv6 and MIPv6: scenarios and related issues 8 draft-ietf-netlmm-mip-interactions-01 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on May 19, 2009. 35 Abstract 37 The scenarios where Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6 38 (MIPv6) protocols are both deployed in a network require some 39 analysis and considerations. This document describes all identified 40 possible scenarios, which require an interaction between PMIPv6 and 41 MIPv6 and discusses all issues related to these scenarios. Solutions 42 and reccomendations to enable these scenarios are also described. 44 Requirements Language 46 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 47 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 48 document are to be interpreted as described in RFC 2119 [RFC2119]. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Overview of the scenarios and related issues . . . . . . . . . 4 55 3.1. Issues related to scenario A . . . . . . . . . . . . . . . 9 56 3.2. Issues related to scenario B . . . . . . . . . . . . . . . 9 57 3.3. Issues related to scenario C . . . . . . . . . . . . . . . 10 58 4. Analysis of possible solutions . . . . . . . . . . . . . . . . 12 59 4.1. Solutions related to scenario A . . . . . . . . . . . . . 12 60 4.2. Solutions related to scenario B . . . . . . . . . . . . . 14 61 4.3. Solutions related to scenario C . . . . . . . . . . . . . 14 62 4.3.1. Mobility from a PMIPv6 domain to a non-PMIPv6 63 domain . . . . . . . . . . . . . . . . . . . . . . . . 15 64 4.3.2. Mobility from a non-PMIPv6 domain to a PMIPv6 65 domain . . . . . . . . . . . . . . . . . . . . . . . . 16 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 67 6. Additional Authors . . . . . . . . . . . . . . . . . . . . . . 17 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 70 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 71 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 73 Intellectual Property and Copyright Statements . . . . . . . . . . 20 75 1. Introduction 77 Proxy Mobile IPv6 [RFC5213] is the network based protocol 78 standardized by IETF. In many deployment scenarios this protocol 79 will be deployed together with MIPv6 [RFC3775], for example with 80 PMIPv6 as local mobility protocol and MIPv6 as global mobility 81 protocol. While the usage of a local mobility protocol should not 82 have implications of how global mobility is managed, since PMIPv6 is 83 partially based on MIPv6 signaling and data structure, some 84 considerations are needed to understand how the protocols interact 85 and how the different scenarios can be enabled. 87 Moreover, some SDOs are investigating complex scenarios where the 88 mobility of some nodes are handled using Proxy Mobile IPv6, while 89 other nodes use Mobile IPv6; or the mobility of a node is managed in 90 turn by a host-based and a network-based mechanism. This needs also 91 to be analyzed as a possible deployment scenario. 93 This document provides a taxonomy of all scenarios that require 94 direct interaction between MIPv6 and PMIPv6. Moreover, this document 95 presents and identifies all known issues pertained to these scenarios 96 and discusses possible means and mechanisms that are recommended to 97 enable them. 99 2. Terminology 101 General mobility terminology can be found in [RFC3753]. The 102 following acronyms are used in this document: 104 MN-HoA: the home address of a mobile node in a Proxy Mobile IPv6 105 domain. 107 MN-HNP: the IPv6 prefix that is always present in the Router 108 Advertisements that the mobile node receives when it is attached 109 to any of the access links in that Proxy Mobile IPv6 domain. MN- 110 HoA always belongs to this prefix. 112 MIPv6-HoA: the Home Address the MN includes in MIPv6 binding 113 update messages. Based on the scenario, MIPv6-HoA and MN-HoA may 114 be the same or different. 116 MIPv6-CoA: the Care-of Address the MN includes in MIPv6 binding 117 update messages. Based on the scenario, MIPv6-HoA and MN-HoA may 118 be the same or different. 120 3. Overview of the scenarios and related issues 122 Several scenarios can be identified where Mobile IPv6 and Proxy 123 Mobile IPv6 are deployed in the same network. This document does not 124 only focus on scenarios where the two protocols are used by the same 125 mobile node to manage local and global mobility, but it investigates 126 also more scenarios where the protocols are more tightly integrated 127 or where there is a co-existence of nodes which do or do not 128 implement Mobile IPv6. 130 The following scenarios are identified: 132 o Scenario A - in this scenario Proxy Mobile IPv6 is used as a 133 network based local mobility management protocol whereas Mobile 134 IPv6 is used as a global mobility management protocol. This 135 interaction is very similar to the HMIPv6-MIPv6 interaction; 136 Mobile IPv6 is used to manage mobility among different access 137 networks, while the mobility within the access network is handled 138 by Proxy Mobile IPv6. The address managed by PMIPv6 (i.e. the MN- 139 HoA based on PMIPv6 terminology) is registered as Care-of Address 140 by the MN at the HA. This means that the HA has a binding cache 141 entry for MIPv6-HoA that points to the MN-HoA. 143 The following figure illustrates this scenario. 145 +----+ 146 | HA | MIPv6-HoA -> MN-HoA 147 +----+ 148 /\ 149 / \ 150 +-------------/----\--------------+ 151 ( / \ ) Global Mobile IPv6 152 ( / \ ) Domain 153 +----------/----------\-----------+ 154 / \ 155 +----+ +----+ 156 MN-HoA -> MAG1 |LMA1| |LMA2| 157 +----+ +----+ 158 //\\ \\ 159 +----//--\\---+ +-----\\------+ 160 ( // \\ ) ( \\ ) Local Mobility Network 161 ( // \\ ) ( \\ ) PMIPv6 domain 162 +-//--------\\+ +--------\\---+ 163 // \\ \\ 164 // \\ \\ 165 // \\ \\ 166 +----+ +----+ +----+ 167 |MAG1| |MAG2| |MAG3| 168 +----+ +----+ +----+ 169 | | | 170 [MN] 172 Figure 1 - Scenario A 174 o Scenario B - in this scenario some mobile nodes use Mobile IPv6 to 175 manage their movements while others rely on a network-based 176 mobility solution provided by the network. There may be a common 177 mobility anchor that acts as Mobile IPv6 Home Agent and Proxy 178 Mobile IPv6 LMA, depending on the type of the node as depicted in 179 the figure. However, the LMA and HA can be also separated and 180 this has no impacts to the mobility of the nodes. 182 +--------+ 183 | HA/LMA | 184 +--------+ 186 +------+ +------+ 187 | MAG1 | | MAG2 | 188 +------+ +------+ 190 +-----------+ 191 | IPv6 host | -----------------> 192 +-----------+ movement 193 +----------+ 194 | MIPv6 MN | -----------------> 195 +----------+ movement 197 Figure 2 - Scenario B 199 o Scenario C - in this scenario the mobile node is moving across 200 different access networks, some of them supporting Proxy Mobile 201 IPv6 and some others not supporting it. Therefore the mobile node 202 is roaming from an access network where the mobility is managed 203 through a network-based solution to an access network where a 204 host-based management (i.e. Mobile IPv6) is needed. This 205 scenario may have different sub-scenarios depending on the 206 relations between the Mobile IPv6 home network and the Proxy 207 Mobile IPv6 domain. The following figure illustrates an example 208 of this scenario, where the MN is moving from an access network 209 where PMIPv6 is supported (i.e. MAG functionality is supported) 210 to a network where PMIPv6 is not supported (i.e. MAG 211 functionality is not supported by the AR). This implies that the 212 home link of the MN is actually a PMIPv6 domain. In this case the 213 MIPv6-HoA is equal to the MN-HoA (i.e. the address managed by 214 PMIPv6). 216 MIPv6-HoA == MN-HoA -> MAG1 217 +------+ 218 |HA/LMA|-----------------------+ 219 +------+ | 220 //\\ | 221 +-------//--\\--------+ | 222 ( // \\ PMIPv6 ) | 223 ( // \\ domain) +--------------+ 224 +----//--------\\-----+ ( Non-PMIPv6 ) 225 // \\ ( domain ) 226 // \\ +--------------+ 227 // \\ | 228 +----+ +----+ +----+ 229 |MAG1| |MAG2| | AR | 230 +----+ +----+ +----+ 231 | | | 232 [MN] 234 Figure 3 - Scenario C 236 In the above figure the non-PMIPv6 domain can actually be also a 237 different PMIPv6 domain that handles a different MN_HoA. The 238 following figure illustrates this sub-case: the MIPv6-HoA is equal 239 to the MN_HoA; however when the MN hands over to MAG3 it gets a 240 different IP address (managed by LMA2 using PMIPv6) and registers 241 it as a MIPv6 CoA. 243 MIPv6-HoA == MN-HoA -> MAG_1 244 +-------+ 245 |HA/LMA1|-----------------------+ 246 +-------+ | 247 //\\ +----+ 248 +-------//--\\--------+ |LMA2| 249 ( // \\ home ) +----+ 250 ( // \\ PMIPv6) +------||------+ 251 ( // \\domain) ( ||visited) 252 +---//----------\\----+ ( ||PMIPv6 ) 253 // \\ ( ||domain ) 254 // \\ +------||------+ 255 +----+ +----+ +----+ 256 |MAG1| |MAG2| |MAG3| 257 +----+ +----+ +----+ 258 | | | 259 [MN] 261 (a) 263 MIPv6-HoA -> MN_CoA 264 +-------+ 265 |HA/LMA1|-----------------------+ 266 +-------+ | 267 //\\ +----+ 268 +-------//--\\--------+ |LMA2| MN_CoA -> MAG3 269 ( // \\ home ) +----+ 270 ( // \\ PMIPv6) +------||------+ 271 ( // \\domain) ( ||visited) 272 +---//----------\\----+ ( ||PMIPv6 ) 273 // \\ ( ||domain ) 274 // \\ +------||------+ 275 +----+ +----+ +----+ 276 |MAG1| |MAG2| |MAG3| 277 +----+ +----+ +----+ 278 | | | 279 [MN] 281 (b) 283 Figure 4 - Scenario C with visited PMIPv6 domain 285 Note that some of the scenarios can be combined. For instance, 286 scenario B can be combined with scenario A or scenario C. 288 The following sections describe some possible issues for each 289 scenario. Note that the issues are described based on current 290 specification and does not assume any optimized solution for any 291 scenario. The specifications considered as a baseline for the 292 analysis are the following: [RFC3775], [RFC4877] and [RFC5213]. For 293 example, the collocation of HA and LMA are considered as the 294 combination of HA according [RFC3775] and LMA according to [RFC5213], 295 e.g. no combined binding caches are considered. The analysis of the 296 collocated HA and LMA would show what is the preferred behaviour for 297 this entity. The behaviour and respective recommendations are 298 described in Section 4.3. 300 3.1. Issues related to scenario A 302 This scenarios is very similar to other hierarchical mobility 303 schemes, including a HMIPv6-MIPv6 scheme. This is the scenario 304 referenced in [RFC4830]. No issues have been identified in this 305 scenario. Note that a race condition where the MN registers the CoA 306 at the HA before the CoA is actually bound to the MAG at the LMA is 307 not possible. The reason is that per PMIPv6 specification the MAG 308 does not forward any packets sent by the MN until the PMIPv6 tunnel 309 is up, regardless the mechanism used for address allocation. 311 Section 4.1 describes one message flow in case PMIPv6 is used as a 312 local mobility protocol and MIPv6 is used as a global mobility 313 protocol. 315 3.2. Issues related to scenario B 317 In this scenario there are two types of nodes in the access network: 318 some nodes support Mobile IPv6 while some others do not. The 319 rationale behind such a scenario is that the nodes implementing 320 Mobile IPv6 may prefer or be configured to manage their own mobility 321 to achieve better performance, e.g. for inter-technology handovers. 322 Obviously, nodes that do not implement MIPv6 must rely on the network 323 to manage their mobility: therefore Proxy MIPv6 is used for those 324 nodes. 326 Based on the current PMIPv6 solution described in [RFC5213], in any 327 link of the PMIPv6 domain the MAG emulates the mobile node's home 328 link, advertising the home link prefix to the MN in a unicast Router 329 Advertisement message. This ensures that the IP address of the MN is 330 still considered valid by the MN itself. The home network prefix 331 (and any other information needed to emulate the home link) is 332 included in the mobile node's profile that is obtained by the MAG via 333 context transfer or via a policy store. 335 However, in case there are nodes that implement Mobile IPv6 and want 336 to use this protocol, the network must offer MIPv6 service to them. 338 In such case the MAG should not emulate the home link. Instead of 339 advertising the HNP, the MAG should advertise the topologically 340 correct local IP prefix, i.e. the prefix belonging to the MAG, so 341 that the MN detects an IP movement, configures a new CoA and sends a 342 MIPv6 Binding Update based on [RFC3775]. 344 3.3. Issues related to scenario C 346 This section highlights some considerations that are applicable to 347 scenario C and need to be evaluated when selecting the technical 348 approach to be chosen. 350 1. HoA management and lookup key in the binding cache 352 * in MIPv6 [RFC3775] the lookup key in the Binding Cache is the 353 Home Address of the MN. In particular, based on the base 354 specification [RFC3775], the MN does not include any 355 identifier, such as the MN-ID [RFC4283], in the Binding Update 356 message other than its Home Address. As described in 357 [RFC4877], the identifier of the MN is known by the Home Agent 358 after the IKEv2 exchange, but this is not used in the MIPv6 359 signaling, nor as a lookup key for the binding cache. On the 360 other hand, as specified in [RFC5213], a Proxy Binding Update 361 contains the Home Prefix of the MN, the MN-ID and does not 362 include the Home Address of the MN (since it may not be known 363 by the MAG and consequently by the HA/LMA). The lookup key in 364 the binding cache of the LMA is either the home prefix or the 365 MN-ID. This implies that lookup keys for MIPv6 and PMIPv6 366 registrations are different. Because of that, when the MN 367 moves from its home network (i.e. from the PMIPv6 domain) to 368 the foreign link, the Binding Update sent by the MN is not 369 identified by the HA as an update of the Proxy Binding Cache 370 Entry containing the home prefix of the MN, but a new binding 371 cache entry is created. Therefore PMIPv6 and MIPv6 will 372 always create two different binding cache entries in the HA/ 373 LMA which implies that the HA and LMA are logically separated. 374 How to handle the presence of the two binding cache entries 375 for the same MN is described in Section 4.3. 377 2. MIPv6 de-registration Binding Update deletes PMIPv6 binding cache 378 entry 380 * When the mobile node moves from a MIPv6 foreign network to the 381 PMIPv6 home domain, the MAG registers the mobile node at the 382 LMA by sending a Proxy Binding Update. Subsequently, the LMA 383 updates the mobile node's binding cache entry with the MAG 384 address and the MAG emulates the mobile node's home link. 385 Upon detection of the home link, the mobile node will send a 386 de-registration Binding Update to its home agent. It is 387 necessary to make sure that the de-registration of the MIPv6 388 BU does not change the PMIPv6 BCE just created by the MAG. 390 3. Race condition between Binding Update and Proxy Binding Update 391 messages (Sequence Numbers and Timestamps) 393 * MIPv6 and PMIPv6 use different mechanisms for handling re- 394 ordering of registration messages and they are sent by 395 different entities. Whereas Binding Update messages are 396 ordered by a sequence numbers and sent by the mobile node, 397 Proxy Binding Update messages are ordered by a timestamp 398 option and sent by MAGs.Assuming the mobile node's MAG sends a 399 Proxy Binding Update message (for refreshing the mobile node's 400 BCE or because the mobile node has just done a handover to 401 this MAG) and shortly thereafter the mobile node moves out of 402 the PMIP home domain, where it configures a new MIPv6-CoA and 403 sends a Binding Update message to its home agent. If now the 404 Proxy Binding Update message from the MAG is delayed so that 405 it reaches the LMA after the Binding Update, the binding cache 406 entry at the LMA would wrongly point to the MAG. Without 407 further measures, it is not clear if packets are forwarded to 408 the mobile node or not and for this reason the behavior of the 409 HA/LMA needs to be clarified in case there are two BCEs, one 410 PMIPv6 and one MIPv6 BCE, for the same MN. 412 4. Use of wrong home agent or LMA after handover 414 * This issues can arise if multiple LMAs are deployed in the 415 PMIP home domain. If the mobile node moves from a MIPv6 416 foreign network to the PMIP home domain, the MAG must send the 417 Proxy Binding Update to the particular LMA that is co-located 418 with the home agent which maintains the active binding cache 419 entry of the mobile node. If a different LMA is assigned to 420 the MAG, the MN will not be on the home link but will still 421 have MIPv6 active and this may be not desirable in some 422 deployments. 424 * Similarly, if the mobile node moves from the PMIP home domain 425 to a MIPv6 foreign network, the mobile node must send the 426 Binding Update to the particular home agent that is co-located 427 with the LMA which maintains the active proxy binding cache 428 entry of the mobile node. If the mobile node selects a 429 different home agent, packets addressed to the mobile node's 430 home address do not reach the mobile node. 432 5. Threat of compromised MAG 434 * In MIPv6 base specification [RFC3775] there is a strong 435 binding between the Home Address registered by the MN and the 436 Security Association used to modify the corresponding binding 437 cache entry. 439 * In PMIPv6 specification, the MAG sends proxy binding updates 440 on behalf of a mobile node to update the binding cache entry 441 that corresponds to the mobile node's home address. Since the 442 MAG sends the binding updates, PMIPv6 requires security 443 associations between each MAG and the LMA. 445 * As described in [RFC4832], in PMIPv6 the MAG compromise or 446 impersonation is an issue. RFC4832, section 2.2, describes 447 how a compromised MAG can harm the functionality of LMA, e.g. 448 manipulating LMA's routing table (or binging cache). 450 * In this mixed scenario, both host-based and network-based 451 security associations are used to update the same binding 452 cache entry at the HA/LMA (but see the first bullet of this 453 list, as the entry may not be the same). Based on this 454 consideration, the threat described in [RFC4832] is worse as 455 it affects also hosts that are using the LMA/HA as MIPv6 HA 456 and are not using PMIPv6 458 4. Analysis of possible solutions 460 4.1. Solutions related to scenario A 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 MN is moving from one PMIPv6 466 domain to another, based on the scenario of Figure 1. In Figure 5, 467 the MN moves from an old MAG to MAG2 in the same PMIPv6 domain: this 468 movement triggers a PBU to LMA1 and the updating of the binding cache 469 at the LMA1; there is no MIPv6 signaling as the CoA_1 registered at 470 the HA is the Home Address for the PMIPv6 session. In Figure 6, the 471 MN moves from MAG2 in the LMA1 PMIPv6 domain to MAG3 in a different 472 PMIPv6 domain: this triggers the PMIPv6 signaling and the creation of 473 a binding at the LMA2. On the other hand, the local address of the 474 MN is changed, as the LMA hss changed, and therefore the MN sends a 475 MIPv6 Binding Update to the HA with the new CoA_2. 477 +----+ +------+ +------+ +----+ 478 | MN | | MAG2 | | LMA1 | | HA | 479 +----+ +------+ +------+ +----+ 480 | | | | 481 | | | +-----------------+ 482 | | | | HoA -> CoA_1 | 483 | | | | binding present | 484 | | | +-----------------+ 485 | | | | 486 | CoA conf/confirm | PBU(CoA_1,MAG_2) | | 487 | <--------------->| ----------------->| | 488 | | +-----------------+| 489 | | | CoA_1 -> MAG_2 || 490 | | | binding updated || 491 | | +-----------------+| 492 | | PBA | | 493 | | <----------------| | 494 | | | | 496 Figure 5 - Local Mobility Message Flow 498 +----+ +------+ +------+ +----+ 499 | MN | | MAG3 | | LMA2 | | HA | 500 +----+ +------+ +------+ +----+ 502 | CoA config | PBU(CoA_2,MAG_3) | | 503 |<---------------->|------------------->| | 504 | | +-----------------+ | 505 | | | CoA_2 -> MAG_3 | | 506 | | | binding created | | 507 | | +-----------------+ | 508 | | PBA | | 509 | |<-------------------| | 510 | | | | 511 | | BU (HoA, CoA_2) | | 512 |---------------------------------------------------->| 513 | | | | 514 | | | +-----------------+ 515 | | | | HoA -> CoA_2 | 516 | | | | binding updated | 517 | | | +-----------------+ 518 | | BA | | 519 |<----------------------------------------------------| 521 Figure 6 - Global Mobility Message Flow 523 4.2. Solutions related to scenario B 525 The solution for this scenario may depend on the access network being 526 able to determine that a particular mobile node wants to use Mobile 527 IPv6. This would require a solution at the system level for the 528 access network and is out of scope of this document. Solutions that 529 do not depend on the access network are out of the scope of this 530 document. 532 4.3. Solutions related to scenario C 534 As described in Section 3.3, in this scenario the mobile node relies 535 on Proxy Mobile IPv6 as long as it is in the Proxy Mobile IPv6 536 domain. The mobile node then uses Mobile IPv6 whenever it moves out 537 of the PMIPv6 domain which basically implies that the MIPv6 home link 538 is a PMIPv6 domain. 540 Analyzing the issues described in Section 3.3, it is clear that most 541 of them are applicable only to the case where there is a common BCE 542 for the PMIPv6 registration and the MIPv6 registration. The issue on 543 how the two protocols identify the BCE is valid only in case we 544 assume that a PMIPv6 message has any value for a MIPv6 BCE. If the 545 two different BCEs are considered completely independent, then the 546 issues described in Section 3.3 are not valid. For this reason, it 547 is recommended that when the MIPv6 home link is implemented as a 548 PMIPv6 domain, the HA/LMA implementation treats the two protocol as 549 independent. 551 More in details the following principles should be followed by the 552 HA/LMA implementation: 554 o PMIPv6 signaling does not overwrite any MIPv6 BCE. In particular, 555 when a PMIPv6 binding cache entry is created for a MN which has 556 previously created a MIPv6 BCE, the MIPv6 BCE of the UE is not 557 overwritten and a new PMIPv6 BCE is created. 559 o The downlink packets in the case where both the MIPv6 BCE and 560 PMIPv6 BCE exist are processed as follows: 562 o 564 1. 1) The MIPv6 BCE is processed first. If the destination 565 address of the received downlink packet matches the the BCE of 566 the HA, the packet is forwarded by encapsulating it with the 567 care-of-address contained in the BCE. 569 2. 2) If the destination address does not match the MIPv6 BCE, 570 the BCE created by PMIPv6 is applied and the packet are 571 encapsualted to the registered MAG. 573 The following subsections provide a description of the procedures 574 which will be followed by the MN and HA/LMA based on the above 575 principles. The analysis is performed in two different subsections, 576 depending if the MN moves from a PMIPv6 domain to a non-PMIPv6 domain 577 or vice versa. 579 4.3.1. Mobility from a PMIPv6 domain to a non-PMIPv6 domain 581 Let's assume the MN is attached to a PMIPv6 domain and there is a 582 valid Proxy Binding Cache entry at the LMA. Then the MN moves to a 583 different access network and starts using MIPv6 (e.g. because PMIPv6 584 is not supported). The MN needs to bootstrap MIPv6 parameters and 585 send a MIPv6 Binding Update in order to have service continuity. 586 Therefore the following steps must be performed by the UE: 588 o HA/LMA address discovery: the MN needs to discover the IP address 589 of the LMA which has a valid binding cache entry for its home 590 network prefix. This is described in Section 3.3 as issue 4. 592 o Security Association establishment: the MN needs to establish an 593 IPsec Security Association with the HA/LMA as described in 594 [RFC4877] 596 o HoA or home network prefix assignment: as part of the MIPv6 597 bootstrapping procedure the HA assigns a MIPv6 HoA to the MN. 598 This address must be the same the MN was using in the PMIPv6 599 domain. 601 Since all these steps must be performed by the MN before sending the 602 Binding Update, they have an impact on the handover latency 603 experienced by the MN. For this reason it is recommended that the MN 604 establishes the IPsec security association (and consequently is 605 provided by the HA/LMA with a MIPv6-HoA) when it is still attached to 606 the PMIPv6 domain. This implies that the mobile node has Mobile IPv6 607 stack active while in the PMIPv6 domain, but as long as it is 608 attached to the same Proxy Mobile IPv6 domain, it will appear to the 609 mobile node as if it is attached to the home link. 611 In order to establish the security association with the HA/LMA, the 612 MN needs to discover the IP address of the LMA/HA while in the PMIPv6 613 domain. This can be done either based on DNS or based on DHCPv6, as 614 described in [RFC5026] and [boot-integrated]. The network should be 615 configured so that the MN discovers or gets assigned the same HA/LMA 616 that was serving as the LMA in the PMIPv6 domain. Details of the 617 exact procedure are out of scope of this document. 619 When the MN establishes the security association, it acquires a home 620 address based on [RFC5026]. However, based on PMIPv6 operations, the 621 LMA knows only the Home Network Prefix used by the MN and does not 622 know the MN-HoA.For this reason, the MN must be configured to propose 623 MN-HoA as the home address in the IKEv2 INTERNAL_IP6_ADDRESS 624 attribute during the IKEv2 exchange with the HA/LMA. Alternatively 625 the HA/LMA can be configured to provide the entire Home Network 626 Prefix via the MIP6_HOME_LINK attribute to the MN as specified in 627 [RFC5026]; based on this Home Network Prefix the MN can configure a 628 home address. Note that the security association must be bound to 629 the MN-HoA used in the PMIPv6 domain as per [RFC4877]. Note that the 630 home network prefix is shared between the LMA and HA and this implies 631 that there is an interaction between the LMA and the HA in order to 632 assign a common home netowkr prefix when triggered by PMIPv6 and 633 MIPv6 signaling 635 When the MN hands over to an access network which does not support 636 Proxy Mobile IPv6, it sends a Binding Update to the HA. A MIPv6 BCE 637 is created irrespective of the existing PMIPv6 BCE. Packets matching 638 the MIPv6 BCE are sent to the CoA present in the MIPv6 BCE. The 639 PMIPv6 BCE will expire in case the MAG does not send a refresh PBU. 640 The refresh PBU is sent by the MAG in case the MN is multihomed and 641 one of the interface is still attached on the MAG link. 643 4.3.2. Mobility from a non-PMIPv6 domain to a PMIPv6 domain 645 In this section it is assumed that the MN is in a non-PMIPv6 access 646 network and it has bootstrapped MIPv6 operations based on [RFC5026]; 647 therefore there is valid binding cache for its MIPv6-HoA at the HA. 648 Then the MN moves to a PMIPv6 domain which is configured to be the 649 home link for the MIPv6-HoA the MN has been assigned. 651 In order to provide session continuity, the MAG needs to send a PBU 652 to the HA/LMA that was serving the MN. The MAG needs to discover the 653 HA/LMA; however the current version of [RFC5213] assumes that the LMA 654 is assigned or discovered when the MN attaches to the MAG. the exact 655 mechanism is not specified in [RFC5213]. A detailed description of 656 the necessary procedure is out of the scope of this document. Note 657 that the MAG may also rely on static configuration or lower layer 658 information provided by the MN in order to select the correct HA/LMA. 660 The PBU sent by the MAG creates a PMIPv6 BCE for the MN which is 661 independent of the MIPv6 BCE. Traffic destined to the MIPv6-HoA is 662 still forwarded to the CoA present in the MIPv6 BCE. When the MN 663 wants to use the HoA directly from the home link, it sends a de- 664 registration message and at that point only the PMIPv6 BCE is 665 present. 667 5. Security Considerations 669 Scenarios A and B described in Section 3 do not introduce any 670 security considerations in addition to those described in [pmipv6- 671 draft] or [RFC3775]. 673 This document requires that the a home agent that also implements the 674 PMIPv6 LMA functionality should allow both the mobile node and the 675 authorized MAGs to modify the binding cache entries for the mobile 676 node. Note that the compromised MAG threat described in [RFC4832] 677 applies also here. 679 6. Additional Authors 681 Chowdhury, Kuntal - kchowdhury@starentnetworks.com 683 Hesham Soliman - Hesham@elevatemobile.com 685 Vijay Devarapalli - vijay.devarapalli@azairenet.com 687 Sri Gundavelli - sgundave@cisco.com 689 Kilian Weniger - Kilian.Weniger@eu.panasonic.com 691 Genadi Velev - Genadi.Velev@eu.panasonic.com 693 Ahmad Muhanna - amuhanna@nortel.com 695 George Tsirtsis - tsirtsis@googlemail.com 697 Suresh Krishnan - suresh.krishnan@ericsson.com 699 7. Acknowledgements 701 This document is a merge of four different Internet Drafts: 702 draft-weniger-netlmm-pmipv6-mipv6-issues-00, 703 draft-devarapalli-netlmm-pmipv6-mipv6-01, 704 draft-tsirtsis-logically-separate-lmaha-01and 705 draft-giaretta-netlmm-mip-interactions-00. Thanks to the authors and 706 editors of those drafts. 708 The authors would also like ot thank Jonne Soininen and Vidya 709 Narayanan, NETLMM WG chairs, for their support. 711 8. References 712 8.1. Normative References 714 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 715 Requirement Levels", BCP 14, RFC 2119, March 1997. 717 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 718 in IPv6", RFC 3775, June 2004. 720 [RFC4832] Vogt, C. and J. Kempf, "Security Threats to Network-Based 721 Localized Mobility Management (NETLMM)", April 2007. 723 [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 724 IKEv2 and the Revised IPsec Architecture", 2005. 726 [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 727 Bootstrapping in Split Scenario", RFC 5026, October 2007. 729 [RFC5213] Gundavelli, S., "Proxy Mobile IPv6", August 2008. 731 [boot-integrated] 732 Chowdhury, K., Ed., "MIP6-bootstrapping for the Integrated 733 Scenario", 2007. 735 [draft-tsirtsis] 736 Tsirtsis, G., "Behavior of Collocated HA/LMA", April 2008, 737 . 740 [pmipv6-draft] 741 Gundavelli, S., Ed., "Proxy Mobile IPv6", 2007, . 745 8.2. Informative References 747 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 748 RFC 3753, June 2004. 750 [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 751 Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 752 (MIPv6)", RFC 4283, November 2005. 754 [RFC4831] Kempf, J., "Goals for Network-Based Localized Mobility 755 Management (NETLMM)", RFC 4831, April 2007. 757 Author's Address 759 Gerardo Giaretta (editor) 760 Qualcomm 762 Email: gerardog@qualcomm.com 764 Full Copyright Statement 766 Copyright (C) The IETF Trust (2008). 768 This document is subject to the rights, licenses and restrictions 769 contained in BCP 78, and except as set forth therein, the authors 770 retain all their rights. 772 This document and the information contained herein are provided on an 773 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 774 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 775 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 776 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 777 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 778 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 780 Intellectual Property 782 The IETF takes no position regarding the validity or scope of any 783 Intellectual Property Rights or other rights that might be claimed to 784 pertain to the implementation or use of the technology described in 785 this document or the extent to which any license under such rights 786 might or might not be available; nor does it represent that it has 787 made any independent effort to identify any such rights. Information 788 on the procedures with respect to rights in RFC documents can be 789 found in BCP 78 and BCP 79. 791 Copies of IPR disclosures made to the IETF Secretariat and any 792 assurances of licenses to be made available, or the result of an 793 attempt made to obtain a general license or permission for the use of 794 such proprietary rights by implementers or users of this 795 specification can be obtained from the IETF on-line IPR repository at 796 http://www.ietf.org/ipr. 798 The IETF invites any interested party to bring to its attention any 799 copyrights, patents or patent applications, or other proprietary 800 rights that may cover technology that may be required to implement 801 this standard. Please address the information to the IETF at 802 ietf-ipr@ietf.org.