idnits 2.17.1 draft-giaretta-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 763. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 774. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 781. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 787. 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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 6, 2007) is 6110 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'MN' is mentioned on line 269, but not defined == Unused Reference: 'RFC3776' is defined on line 703, but no explicit reference was found in the text == Unused Reference: 'RFC4140' is defined on line 730, but no explicit reference was found in the text == Unused Reference: 'RFC4285' is defined on line 738, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 4140 (Obsoleted by RFC 5380) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 8 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 July 6, 2007 5 Expires: January 7, 2008 7 Interactions between PMIPv6 and MIPv6: scenarios and related issues 8 draft-giaretta-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 January 7, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 The scenarios where Proxy Mobile IPv6 (PMIPv6) and Mobile IPv6 42 (MIPv6) protocols interact with each other need special 43 considerations. An analysis of all the scenarios that involve this 44 interaction is necessary in order to provide guidelines to PMIPv6 45 protocol design and applicability. This document describes all 46 identified possible scenarios, which require an interaction between 47 PMIPv6 and MIPv6 and discusses all issues related to these scenarios. 48 Solutions to enable these scenarios are also described. 50 Requirements Language 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 54 document are to be interpreted as described in RFC 2119 [RFC2119]. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Overview of the scenarios and related issues . . . . . . . . . 3 61 3.1. Issues related to scenario A . . . . . . . . . . . . . . . 8 62 3.2. Issues related to scenario B . . . . . . . . . . . . . . . 8 63 3.3. Issues related to scenario C . . . . . . . . . . . . . . . 9 64 4. Analysis of possible solutions . . . . . . . . . . . . . . . . 12 65 4.1. Solutions related to scenario A . . . . . . . . . . . . . 12 66 4.2. Solutoins related to scenario B . . . . . . . . . . . . . 13 67 4.3. Solutions related to scenario C . . . . . . . . . . . . . 13 68 5. Conclusions/Recommendations . . . . . . . . . . . . . . . . . 15 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 70 7. Additional Authors . . . . . . . . . . . . . . . . . . . . . . 16 71 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 73 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 74 9.2. Informative References . . . . . . . . . . . . . . . . . . 17 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 76 Intellectual Property and Copyright Statements . . . . . . . . . . 19 78 1. Introduction 80 The NETLMM WG is chartered to standardize a network-based protocol 81 for localized mobility management. The goals that must be fulfilled 82 by the protocol design are listed in rfc4831. Proxy Mobile IPv6 has 83 been designated as the network-based localized mobility management 84 protocol. 86 There are two main reasons why the interactions between Proxy Mobile 87 IPv6 and Mobile IPv6 need to be studied. The first reason is that 88 Mobile IPv6 is the main global mobility management protocol developed 89 in IETF; it is therefore worth investigating for example the details 90 of a hierarchical mobility scheme where Proxy Mobile IPv6 is used for 91 local mobility and Mobile IPv6 is used for global mobility. 93 The second reason is that Mobile IPv6 has been chosen by the NETLMM 94 WG mainly for reusability grounds and a MIPv6 home agent can be 95 extended to handle PMIPv6. 97 Moreover, based on these considerations, some SDOs are investigating 98 complex scenarios where the mobility of some nodes are handled using 99 Proxy Mobile IPv6, while other nodes use Mobile IPv6; or the mobility 100 of a node is managed in turn by a host-based and a network-based 101 mechanism. 103 This document provides a taxonomy of all scenarios that require 104 direct interaction between MIPv6 and PMIPv6. Moreover, this document 105 presents and identifies all known issues pertained to these scenarios 106 and discusses possible means and mechanisms that may be required to 107 enable them. . 109 2. Terminology 111 General mobility terminology can be found in [RFC3753]. 113 3. Overview of the scenarios and related issues 115 Several scenarios can be identified where Mobile IPv6 and Proxy 116 Mobile IPv6 are used. This document does not only focus on scenarios 117 where the two protocols are used by the same mobile node to manage 118 local and global mobility, but it investigates also more complex 119 scenarios where the protocols are more tightly integrated or where 120 there is a co-existence of nodes which do or do not implement Mobile 121 IPv6. 123 The following scenarios were identified: 125 o Scenario A - in this scenario Proxy Mobile IPv6 is used as a 126 network based local mobility management protocol whereas Mobile 127 IPv6 is used as a global mobility management protocol. This 128 interaction is very similar to the HMIPv6-MIPv6 interaction; 129 Mobile IPv6 is used to manage mobility among different access 130 networks, while the mobility within the access network is handled 131 by Proxy Mobile IPv6. The address managed by PMIPv6 (i.e. the 132 MN_HoA based on PMIPv6 terminology) is registered as Care-of 133 Address by the MN at the HA. This means that the HA has a binding 134 cache entry for MIPv6_HoA that points to the MN_HoA. 136 The following figure illustrates this scenario. 138 +----+ 139 | HA | MIPv6_HoA -> MN_HoA 140 +----+ 141 /\ 142 / \ 143 +-------------/----\--------------+ 144 ( / \ ) Global Mobile IPv6 145 ( / \ ) Domain 146 +----------/----------\-----------+ 147 / \ 148 +----+ +----+ 149 MN_HoA -> MAG1 |LMA1| |LMA2| 150 +----+ +----+ 151 //\\ \\ 152 +----//--\\---+ +-----\\------+ 153 ( // \\ ) ( \\ ) Local Mobility Network 154 ( // \\ ) ( \\ ) PMIPv6 domain 155 +-//--------\\+ +--------\\---+ 156 // \\ \\ 157 // \\ \\ 158 // \\ \\ 159 +----+ +----+ +----+ 160 |MAG1| |MAG2| |MAG3| 161 +----+ +----+ +----+ 162 | | | 163 [MN] 165 Figure 1 - Scenario A 167 o Scenario B - in this scenario some mobile nodes use Mobile IPv6 to 168 manage their movements while others rely on a network-based 169 mobility solution provided by the network. There is a common 170 mobility anchor that acts as Mobile IPv6 Home Agent and Proxy 171 Mobile IPv6 LMA, depending on the type of the node. 173 +--------+ 174 | HA/LMA | 175 +--------+ 177 +------+ +------+ 178 | MAG1 | | MAG2 | 179 +------+ +------+ 181 +-----------+ 182 | IPv6 host | -----------------> 183 +-----------+ movement 184 +----------+ 185 | MIPv6 MN | -----------------> 186 +----------+ movement 188 Figure 2 - Scenario B 190 o Scenario C - in this scenario the mobile node is moving across 191 different access networks, some of them supporting Proxy Mobile 192 IPv6 and some others not supporting it. Therefore the mobile node 193 is roaming from an access network where the mobility is managed 194 through a network-based solution to an access network where a 195 host-based management (i.e. Mobile IPv6) is needed. This 196 scenario may have different sub-scenarios depending on the 197 relations between the Mobile IPv6 home network and the Proxy 198 Mobile IPv6 domain. The following figure illustrates an example 199 of this scenario, where the MN is moving from an access network 200 where PMIPv6 is supported (i.e. MAG functionality is supported) 201 to a network where PMIPv6 is not supported (i.e. MAG 202 functionality is not supported by the AR). In this case the 203 MIPv6_HoA is equal to the MN_HoA (i.e. the address managed by 204 PMIPv6). 206 MIPv6_HoA == MN_HoA -> MAG1 207 +------+ 208 |HA/LMA|-----------------------+ 209 +------+ | 210 //\\ | 211 +-------//--\\--------+ | 212 ( // \\ PMIPv6 ) | 213 ( // \\ domain) +--------------+ 214 +----//--------\\-----+ ( Non-PMIPv6 ) 215 // \\ ( domain ) 216 // \\ +--------------+ 217 // \\ | 218 +----+ +----+ +----+ 219 |MAG1| |MAG2| | AR | 220 +----+ +----+ +----+ 221 | | | 222 [MN] 224 Figure 3 - Scenario C 226 In the above figure the non-PMIPv6 domain can actually be also a 227 different PMIPv6 domain that handles a different MN_HoA. The 228 following figure illustrates this sub-case: the MIPv6_HoA is equal 229 to the MN_HoA; however when the MN hands over to MAG3 it gets a 230 different IP address (managed by LMA2 using PMIPv6) and registers 231 it as a MIPv6 CoA. 233 MIPv6_HoA == MN_HoA -> MAG_1 234 +-------+ 235 |HA/LMA1|-----------------------+ 236 +-------+ | 237 //\\ +----+ 238 +-------//--\\--------+ |LMA2| 239 ( // \\ home ) +----+ 240 ( // \\ PMIPv6) +------||------+ 241 ( // \\domain) ( ||visited) 242 +---//----------\\----+ ( ||PMIPv6 ) 243 // \\ ( ||domain ) 244 // \\ +------||------+ 245 +----+ +----+ +----+ 246 |MAG1| |MAG2| |MAG3| 247 +----+ +----+ +----+ 248 | | | 249 [MN] 251 (a) 253 MIPv6_HoA -> MN_CoA 254 +-------+ 255 |HA/LMA1|-----------------------+ 256 +-------+ | 257 //\\ +----+ 258 +-------//--\\--------+ |LMA2| MN_CoA -> MAG3 259 ( // \\ home ) +----+ 260 ( // \\ PMIPv6) +------||------+ 261 ( // \\domain) ( ||visited) 262 +---//----------\\----+ ( ||PMIPv6 ) 263 // \\ ( ||domain ) 264 // \\ +------||------+ 265 +----+ +----+ +----+ 266 |MAG1| |MAG2| |MAG3| 267 +----+ +----+ +----+ 268 | | | 269 [MN] 271 (b) 273 Figure 4 - Scenario C with visited PMIPv6 domain 275 Note that some of the scenarios can be combined. For instance, 276 scenario B can be combined with scenario A or scenario C. 278 The following sections describe some possible issues for each 279 scenario. Note that the issues are described based on current 280 specification and does not assume any optimized solution for any 281 scenario. The specifications considered as a baseline for the 282 analysis are the following: [RFC3775], [RFC4877] and [pmipv6-draft]. 283 For example, the collocation of HA and LMA are considered as the 284 combination of HA according [RFC3775] and LMA according to 285 [pmipv6-draft], e.g. no combined binding caches are considered. The 286 analysis of the collocated HA and LMA would show what is the 287 preferred behaviour for this entity. The behaviour and respective 288 recommendations are described in Section 4.3. 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. In particular,a race condition where the MN registers the 296 CoA at the HA before the CoA is actually bound to the MAG at the LMA 297 is 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 will describe one flow in case PMIPv6 is used as a local 302 mobility protocol and MIPv6 is used as a global mobility protocol. 304 3.2. Issues related to scenario B 306 In this scenario there are two types of nodes in the access network: 307 some nodes support Mobile IPv6 while some others do not. The 308 rationale behind such a scenario is that the nodes implementing 309 Mobile IPv6 may prefer to manage their own mobility. Obviously, 310 nodes that do not implement MIPv6 must rely on the network to manage 311 their mobility: therefore Proxy MIPv6 is used for those nodes. 313 The issues related to this scenario may be solvable at system level 314 and may not be protocol issues. However, it is worth discussing them 315 in order to have a full picture of the peculiarities of a PMIPv6/ 316 MIPv6 scenario. 318 Based on the current PMIPv6 solution described in 319 draft-ietf-netlmm-proxymip6-00, in any link of the PMIPv6 domain the 320 MAG emulates the mobile node's home link, advertising the home link 321 prefix to the MN in a unicast Router Advertisement message. This 322 ensures that the IP address of the MN is still considered valid by 323 the MN itself. The home network prefix (and any other information 324 needed to emulate the home link) is included in the mobile node's 325 profile that is obtained by the MAG via context transfer or via a 326 policy store. 328 However, in case there are nodes that implement Mobile IPv6 and want 329 to use this protocol, the network must offer MIPv6 service to them. 330 In such case the MAG should not emulate the home link. Therefore, 331 instead advertising the HNP, the MAG should advertise the 332 topologically correct IP prefix, i.e. the prefix belonging to the 333 MAG, so that the MN detects an IP movement, configures a new CoA and 334 sends a MIPv6 Binding Update based on [RFC3775]. 336 3.3. Issues related to scenario C 338 Some possible issues are present in this scenario: 340 1. HoA management and lookup key in the binding cache 342 * in MIPv6 [RFC3775] the lookup key in the Binding Cache is the 343 Home Address of the MN. In particular, based on the base 344 specification [RFC3775], the MN does not include any 345 identifier, such as the MN-ID [RFC4283], in the Binding Update 346 message other than its Home Address. An identifier of the MN 347 is known by the Home Agent after the IKEv2 exchange, but this 348 is not used in the MIPv6 signaling, nor as a lookup key for 349 the binding cache. On the other hand, as specified in 350 [pmipv6-draft], a Proxy Binding Update contains the Home 351 Prefix of the MN, the MN-ID and may not include the Home 352 Address of the MN (since it may not be known by the MAG and 353 consequently by the HA/LMA). The lookup key in the binding 354 cache of the LMA is either the home prefix or the MN-ID. This 355 implies that lookup keys for MIPv6 and PMIPv6 registrations 356 are different. Because of that, when the MN moves from its 357 home network (i.e. from the PMIPv6 domain) to the foreign 358 link, the Binding Update sent by the MN is not identified by 359 the HA as an update of the Proxy Binding Cache Entry 360 containing the home prefix of the MN, but a new binding cache 361 entry is created. Based on these considerations, there is an 362 "unused" (proxy) binding cache entry in the Binding Cache of 363 the LMA/HA. Note that the assumption in this section is that 364 the binding caches of the LMA and the HA are different and 365 there is not any combined binding cache. The need of such a 366 combined binding cache will be discussed in Section 4.3. 368 * when the MN return back in the MIPv6 home link in MIPv6 that 369 is also a PMIPv6 domain, it has to de-registers the host-based 370 mobility binding cache entry. However in [RFC3775], de- 371 registration is recommended (but not mandatory). This implies 372 that the MN receives a Router Advertisement with the home 373 prefix, starts using its HoA directly, without tunneling 374 uplink packets but may not send a Binding Update to remove the 375 binding cache entry related to the HoA. In case the de- 376 registration BU is not sent, the PBU sent by the MAG will not 377 update the Binding Cache entry related to the HoA, but will 378 create a new proxy binding cache entry including the home 379 prefix of the MN, the MN-ID and the MAG address. This implies 380 that, in case the MN does not send a de-registration binding 381 update when returning home, the downlink packets may still be 382 tunneled to the CoA and not to the MAG. 384 2. MIPv6 de-registration Binding Update deletes PMIPv6 binding cache 385 entry 387 * When the mobile node moves from a MIPv6 foreign network to the 388 PMIPv6 home domain, the MAG registers the mobile node at the 389 LMA by sending a Proxy Binding Update. Subsequently, the LMA 390 updates the mobile node's binding cache entry with the MAG 391 address and the MAG emulates the mobile node's home link. 392 Upon detection of the home link, the mobile node will send a 393 de-registration Binding Update to its home agent. According 394 to RFC3775, the home agent would delete the binding cache 395 entry after accepting the de-registration Binding Update, 396 i.e., it would delete the proxy binding cache entry that was 397 just established by the MAG. Hence, packets arriving at the 398 LMA and destined for the mobile node would not be forwarded to 399 the mobile node anymore. 401 3. Race condition between Binding Update and Proxy Binding Update 402 messages (Sequence Numbers and Timestamps) 404 * MIPv6 and PMIPv6 use different mechanisms for handling re- 405 ordering of registration messages and they are sent by 406 different entities. Whereas Binding Update messages are 407 ordered by a sequence numbers and sent by the mobile node, 408 Proxy Binding Update messages are ordered by a timestamp 409 option and sent by MAGs. 411 * Assuming the mobile node's MAG sends a Proxy Binding Update 412 message (for refreshing the mobile node's BCE or because the 413 mobile node has just done a handover to this MAG) and shortly 414 thereafter the mobile node moves out of the PMIP home domain, 415 where it configures a new MIPv6-CoA and sends a Binding Update 416 message to its home agent. If now the Proxy Binding Update 417 message from the MAG is delayed so that it reaches the LMA 418 after the Binding Update, the binding cache entry at the LMA 419 would wrongly point to the MAG. Without further measures, 420 packets are not forwarded to the mobile node unless a new 421 Binding Update is sent by the mobile node. This may result in 422 a significant packet loss. A similar situation can occur if 423 the mobile node sends a Binding Update messsage from outside 424 the PMIP home domain and shortly thereafter enters the PMIP 425 home domain. 427 4. Use of wrong home agent or LMA after handover 429 * This issues can arise if multiple LMAs are deployed in the 430 PMIP home domain. If the mobile node moves from a MIPv6 431 foreign network to the PMIP home domain, the MAG must send the 432 Proxy Binding Update to the particular LMA that is co-located 433 with the home agent which maintains the active binding cache 434 entry of the mobile node. If a different LMA is assigned to 435 the MAG, packets addressed to the mobile node's home address 436 do not reach the mobile node anymore. 438 * Similarly, if the mobile node moves from the PMIP home domain 439 to a MIPv6 foreign network, the mobile node must send the 440 Binding Update to the particular home agent that is co-located 441 with the LMA which maintains the active proxy binding cache 442 entry of the mobile node. If the mobile node selects a 443 different home agent, packets addressed to the mobile node's 444 home address do not reach the mobile node. 446 5. Threat of compromised MAG 448 * in MIPv6 base specification [RFC3775] there is a strong 449 binding between the Home Address registered by the MN and the 450 Security Association used to modify the corresponding binding 451 cache entry. 453 * In PMIPv6 specification, the MAG sends proxy binding updates 454 on behalf of a mobile node to update the binding cache entry 455 that corresponds to the mobile node's home address. Since the 456 MAG sends the binding updates, PMIPv6 requires security 457 associations between each MAG and the LMA. 459 * As described in [RFC4832], in PMIPv6 the MAG compromise or 460 impersonation is an issue. RFC4832, section 2.2, describes 461 how a compromised MAG can harm the functionality of LMA, e.g. 462 manipulating LMA's routing table (or binging cache). 464 * in this mixed scenario, both host-based and network-based 465 security associations are used to update the same binding 466 cache entry at the HA/LMA (but see the first bullet of this 467 list, as the entry may not be the same). Based on this 468 consideration, the threat desceibed in [RFC4832] is worse as 469 it affects also hosts that are using the LMA/HA as MIPv6 HA 470 and are not using PMIPv6. 472 4. Analysis of possible solutions 474 4.1. Solutions related to scenario A 476 As mentioned in Section 3.1, there are no significant issues in this 477 scenario. 479 Figures 5 and 6 show a scenario where a MN is moving from one PMIPv6 480 domain to another, based on the scenario of Figure 1. In Figure 5, 481 the MN moves from an old MAG to MAG2 in the same PMIPv6 domain: this 482 movement triggers a PBU to LMA1 and the updating of the binding cache 483 at the LMA1; there is no MIPv6 signaling as the CoA_1 registered at 484 the HA is the Home Address for the PMIPv6 session. In Figure 6, the 485 MN moves from MAG2 in the LMA1 PMIPv6 domain to MAG3 in a different 486 PMIPv6 domain: this triggers the PMIPv6 signaling and the creation of 487 a binding at the LMA2. On the other hand, the local address of the 488 MN is changed, as the LMA hss changed, and therefore the MN sends a 489 MIPv6 Binding Update to the HA with the new CoA_2. 491 +----+ +------+ +------+ +----+ 492 | MN | | MAG2 | | LMA1 | | HA | 493 +----+ +------+ +------+ +----+ 494 | | | | 495 | | | +-----------------+ 496 | | | | HoA -> CoA_1 | 497 | | | | binding present | 498 | | | +-----------------+ 499 | | | | 500 | CoA conf/confirm | PBU(CoA_1,MAG_2) | | 501 | <--------------->| ----------------->| | 502 | | +-----------------+| 503 | | | CoA_1 -> MAG_2 || 504 | | | binding updated || 505 | | +-----------------+| 506 | | PBA | | 507 | | <----------------| | 508 | | | | 510 Figure 5 - Local Mobility Message Flow 512 +----+ +------+ +------+ +----+ 513 | MN | | MAG3 | | LMA2 | | HA | 514 +----+ +------+ +------+ +----+ 516 | CoA config | PBU(CoA_2,MAG_3) | | 517 |<---------------->|------------------->| | 518 | | +-----------------+ | 519 | | | CoA_2 -> MAG_3 | | 520 | | | binding created | | 521 | | +-----------------+ | 522 | | PBA | | 523 | |<-------------------| | 524 | | | | 525 | | BU (HoA, CoA_2) | | 526 |---------------------------------------------------->| 527 | | | | 528 | | | +-----------------+ 529 | | | | HoA -> CoA_2 | 530 | | | | binding updated | 531 | | | +-----------------+ 532 | | BA | | 533 |<----------------------------------------------------| 535 Figure 6 - Global Mobility Message Flow 537 4.2. Solutoins related to scenario B 539 The solution for this scenario may depend on the access network being 540 able to determine that a particular mobile node wants to use Mobile 541 IPv6. This would require a solution at the system level for the 542 access network and is out of scope of this document. Solutions that 543 do not depend on the access network are TBD. 545 4.3. Solutions related to scenario C 547 As described in Section 3.3, in this scenario the mobile node relies 548 on Proxy Mobile IPv6 as long as it is in the Proxy Mobile IPv6 549 domain. The mobile node then uses Mobile IPv6 whenever it moves out 550 the PMIPv6 domain. As the PMIPv6 domain emulates the home link in 551 terms of MIPv6, the MN_HoA assigned by PMIPv6 is the equal to the 552 MIPv6 home address. 554 This implies that the mobile node has Mobile IPv6 stack active while 555 in the PMIPv6 domain, but as long as it is attached to the same Proxy 556 Mobile IPv6 domain, it will appear to the mobile node as if it is 557 attached to the home link. Based on the fact that the MIPv6 is 558 active, even when connected to the PMIPv6 domain, the mobile node may 559 setup IPsec security associations required for protecting the Mobile 560 IPv6 signaling message. This allows the mobile node to minimize the 561 handover latency in a subsequent PMIPv6 to MIPv6 transition. If the 562 mobile node does this, the security association must be bound to the 563 MN_HoA used in the PMIPv6 domain as per RFC4877. 565 If the mobile node attaches to an access network that is not part of 566 the Proxy Mobile IPv6 domain, a transition to MIPv6 is needed. The 567 mobile node acquires a care-of address from the access network, 568 treats the earlier home address in the PMIPv6 domain as the MIPv6 569 home address and performs a MIPv6 registration. In order to do that, 570 if the mobile node does not know the IP address of the LMA/HA, it 571 needs to discover it and bootstrap a security association with it. 572 During this procedure the HA has to assign the same HoA used by the 573 MN in the PMIPv6 domain; however this may not be known by the LMA as 574 only the Home Network Prefix is known by the LMA. To solve this 575 issue, the LMA/HA can provide the mobile node with the home prefix as 576 specified in [boot-split]. 578 Anyway the LMA/HA needs to check the BCE when assigning the address 579 in IKEv2. It is up to the mobile node then keeping the same HoA used 580 in the PMIPv6 domain. As soon as the Security Association is 581 established, the mobile node sends the BU with (HoA, CoA) and the 582 LMA/HA must match the HoA with the MN-ID and update the respective 583 BCE accordingly. This implies a change in the BU processing if 584 compared to RFC 3775: the LMA/HA must match the HoA included in the 585 BU with the MN-ID known based on IKEv2 signalling and update the 586 respective BCE accordingly (clearing the P flag). 588 When the LMA and the HA are co-located, binding cache lookup for a 589 mobile node must use a combination of the mobile node's identifier 590 and the home address. The Binding Update from the mobile node 591 contains the home address of the mobile node, whereas the Proxy 592 Binding Update from the MAG contains only the mobile node's 593 identifier. Therefore when transitioning between using Proxy Mobile 594 IPv6 and Mobile IPv6, the Home Agent must ensure that the mobile 595 node's binding cache entry must be looked up with both the home 596 address and identifier of the mobile node. This requires the Home 597 Agent to acquire the mobile node identifier other than from the 598 Binding Update message (for e.g., from the preceding IKEv2 exchange 599 that set up security associations for sending the Binding Update) and 600 to store it as part of the binding cache entry for the mobile node. 601 Note that this requires that the MN-ID used by the mobile node during 602 the IKEv2 set-up is the same of the MN-ID used by the MAG in PMIPv6 603 signalling. 605 Note that in this scenario the same binding cache entry for the 606 mobile node is at times modified by the mobile node and other times 607 modified by a MAG. The home agent must ensure that only authorized 608 MAGs in addition to the mobile node are allowed to modify the binding 609 cache entry for the mobile node. 611 If the mobile node bootstraps from a non-PMIPv6 domain with a LMA/HA 612 and the LMA/HA does not have any entry for the MN, the LMA/HA must 613 allocate a home network prefix to the MN, even though during the 614 MIPv6 bootstrapping only a /128 Home Address is assigned. This is 615 needed in order to ensure that the PMIPv6 addressing model is 616 maintained when the MN moves back to the PMIPv6 domain. 618 When the mobile node moves to the PMIPv6 domain that corresponds to 619 its home link, it will send a de-registration binding update with 620 zero lifetime to its home agent. But at the same, the MAG the mobile 621 node is attached will send a proxy Binding Update to the LMA 622 functionality co-located with the home agent. 624 In this case, the HA/LMA MUST send a binding acknowledgment with 625 success status to the mobile node to indicate a successful de- 626 registration. In case the binding update is not valid, a binding 627 acknowledgement with the appropriate error status MUST be sent, as 628 specified in [RFC3775]. The HA/LMA must modify the binding cache 629 entry to reflect the fact that it is now a binding cache entry 630 created using PMIPv6. The home agent MUST NOT delete the binding 631 cache entry for the mobile node after receiving a de-registration BU 632 if in the binding cache there is a BCE with the P-flag set for the 633 same MN. A solution for race conditions between BU and PBU messages 634 (issue #3) is TBD. 636 Note that the bootstrapping mechanisms used to discover the LMA, the 637 Mobile IPv6 home agent and home address for the mobile node must be 638 configured such that the LMA assigned for a particular mobile node 639 can be used as a home agent and the address given to the mobile node 640 when it is attached to the PMIPv6 domain can be used as the MIPv6 641 home address when the mobile node is no longer attached to the PMIPv6 642 domain. How this is done is still TBD. 644 5. Conclusions/Recommendations 646 649 6. Security Considerations 651 Scenarios A and B described in Section 3 do not introduce any 652 security considerations in addition to those described in [pmipv6- 653 draft] or [RFC3775]. 655 In Scenario C described in Section 3.3, the home agent has to allow 656 the authorized MAGs in a particular PMIPv6 domain to be able to 657 modify the binding cache entry for a mobile node. [RFC3775] requires 658 that only the right mobile node is allowed to modify the binding 659 cache entry for its home address. This document requires that the a 660 home agent that also implements the PMIPv6 LMA functionality should 661 allow both the mobile node and the authorized MAGs to modify the 662 binding cache entry for the mobile node. Note that the compromised 663 MAG threat described in [RFC4832] applies also here; in this scenario 664 the threat is worse as it affects also hosts that are using the 665 LMA/HA as MIPv6 HA and are not using PMIPv6. 667 7. Additional Authors 669 Chowdhury, Kuntal - kchowdhury@starentnetworks.com 671 Hesham Soliman - Hesham@elevatemobile.com 673 Vijay Devarapalli - vijay.devarapalli@azairenet.com 675 Sri Gundavelli - sgundave@cisco.com 677 Kilian Weniger - Kilian.Weniger@eu.panasonic.com 679 Genadi Velev - Genadi.Velev@eu.panasonic.com 681 Ahmad Muhanna - amuhanna@nortel.com 683 8. Acknowledgements 685 This document is a merge of three different Internet Drafts: 686 draft-weniger-netlmm-pmipv6-mipv6-issues-00, 687 draft-devarapalli-netlmm-pmipv6-mipv6-01 and 688 draft-giaretta-netlmm-mip-interactions-00. Thanks to the authors and 689 editors of those drafts. 691 The authors would also like ot thank Jonne Soininen and Vidya 692 Narayanan, NETLMM WG chairs, for their support. 694 9. References 695 9.1. Normative References 697 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 698 Requirement Levels", BCP 14, RFC 2119, March 1997. 700 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 701 in IPv6", RFC 3775, June 2004. 703 [RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 704 Protect Mobile IPv6 Signaling Between Mobile Nodes and 705 Home Agents", RFC 3776, June 2004. 707 [RFC4830] Kempf, J., "Problem Statement for Network-Based Localized 708 Mobility Management (NETLMM)", April 2007. 710 [RFC4832] Vogt, C. and J. Kempf, "Security Threats to Network-Based 711 Localized Mobility Management (NETLMM)", April 2007. 713 [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 714 IKEv2 and the Revised IPsec Architecture", 2005. 716 [boot-split] 717 Giaretta, G., Ed., "MIPv6 bootstrapping in split 718 scenario", 2007. 720 [pmipv6-draft] 721 Gundavelli, S., Ed., "Proxy Mobile IPv6", 2007, . 725 9.2. Informative References 727 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 728 RFC 3753, June 2004. 730 [RFC4140] Soliman, H., Castelluccia, C., El Malki, K., and L. 731 Bellier, "Hierarchical Mobile IPv6 Mobility Management 732 (HMIPv6)", RFC 4140, August 2005. 734 [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 735 Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 736 (MIPv6)", RFC 4283, November 2005. 738 [RFC4285] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 739 Chowdhury, "Authentication Protocol for Mobile IPv6", 740 RFC 4285, January 2006. 742 Author's Address 744 Gerardo Giaretta (editor) 745 Qualcomm 747 Email: gerardog@qualcomm.com 749 Full Copyright Statement 751 Copyright (C) The IETF Trust (2007). 753 This document is subject to the rights, licenses and restrictions 754 contained in BCP 78, and except as set forth therein, the authors 755 retain all their rights. 757 This document and the information contained herein are provided on an 758 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 759 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 760 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 761 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 762 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 763 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 765 Intellectual Property 767 The IETF takes no position regarding the validity or scope of any 768 Intellectual Property Rights or other rights that might be claimed to 769 pertain to the implementation or use of the technology described in 770 this document or the extent to which any license under such rights 771 might or might not be available; nor does it represent that it has 772 made any independent effort to identify any such rights. Information 773 on the procedures with respect to rights in RFC documents can be 774 found in BCP 78 and BCP 79. 776 Copies of IPR disclosures made to the IETF Secretariat and any 777 assurances of licenses to be made available, or the result of an 778 attempt made to obtain a general license or permission for the use of 779 such proprietary rights by implementers or users of this 780 specification can be obtained from the IETF on-line IPR repository at 781 http://www.ietf.org/ipr. 783 The IETF invites any interested party to bring to its attention any 784 copyrights, patents or patent applications, or other proprietary 785 rights that may cover technology that may be required to implement 786 this standard. Please address the information to the IETF at 787 ietf-ipr@ietf.org. 789 Acknowledgment 791 Funding for the RFC Editor function is provided by the IETF 792 Administrative Support Activity (IASA).