idnits 2.17.1 draft-giaretta-netlmm-mip-interactions-02.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 807. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 818. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 825. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 831. 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 (November 15, 2007) is 6000 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'MN' is mentioned on line 289, but not defined ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) Summary: 3 errors (**), 0 flaws (~~), 2 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, 2007 5 Expires: May 18, 2008 7 Interactions between PMIPv6 and MIPv6: scenarios and related issues 8 draft-giaretta-netlmm-mip-interactions-02 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 18, 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 . . . . . . . . . 4 61 3.1. Issues related to scenario A . . . . . . . . . . . . . . . 9 62 3.2. Issues related to scenario B . . . . . . . . . . . . . . . 9 63 3.3. Issues related to scenario C . . . . . . . . . . . . . . . 10 64 4. Analysis of possible solutions . . . . . . . . . . . . . . . . 13 65 4.1. Solutions related to scenario A . . . . . . . . . . . . . 13 66 4.2. Solutoins related to scenario B . . . . . . . . . . . . . 14 67 4.3. Solutions related to scenario C . . . . . . . . . . . . . 14 68 4.3.1. Mobility from a PMIPv6 domain to a non-PMIPv6 69 domain . . . . . . . . . . . . . . . . . . . . . . . . 15 70 4.3.2. Mobility from a non-PMIPv6 domain to a PMIPv6 71 domain . . . . . . . . . . . . . . . . . . . . . . . . 16 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 73 6. Additional Authors . . . . . . . . . . . . . . . . . . . . . . 18 74 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 76 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 77 8.2. Informative References . . . . . . . . . . . . . . . . . . 19 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 79 Intellectual Property and Copyright Statements . . . . . . . . . . 20 81 1. Introduction 83 The NETLMM WG is chartered to standardize a network-based protocol 84 for localized mobility management. The goals that must be fulfilled 85 by the protocol design are listed in [RFC4831]. Proxy Mobile IPv6 86 [pmipv6-draft] has been designated as the network-based localized 87 mobility management protocol. 89 There are two main reasons why the interactions between Proxy Mobile 90 IPv6 and Mobile IPv6 need to be studied. The first reason is that 91 Mobile IPv6 is the main global mobility management protocol developed 92 in IETF; it is therefore worth investigating for example the details 93 of a hierarchical mobility scheme where Proxy Mobile IPv6 is used for 94 local mobility and Mobile IPv6 is used for global mobility. 96 The second reason is that Proxy Mobile IPv6 has been chosen by the 97 NETLMM WG mainly for reusability grounds and a MIPv6 home agent can 98 be extended to handle PMIPv6. 100 Moreover, based on these considerations, some SDOs are investigating 101 complex scenarios where the mobility of some nodes are handled using 102 Proxy Mobile IPv6, while other nodes use Mobile IPv6; or the mobility 103 of a node is managed in turn by a host-based and a network-based 104 mechanism. 106 This document provides a taxonomy of all scenarios that require 107 direct interaction between MIPv6 and PMIPv6. Moreover, this document 108 presents and identifies all known issues pertained to these scenarios 109 and discusses possible means and mechanisms that may be required to 110 enable them. 112 2. Terminology 114 General mobility terminology can be found in [RFC3753]. The 115 following acronyms are used in this document: 117 MN-HoA: the home address of a mobile node in a Proxy Mobile IPv6 118 domain. 120 MN-HNP: the IPv6 prefix that is always present in the Router 121 Advertisements that the mobile node receives when it is attached 122 to any of the access links in that Proxy Mobile IPv6 domain. MN- 123 HoA always belongs to this prefix. 125 MIPv6-HoA: the Home Address the MN includes in MIPv6 binding 126 update messages. Based on the scenario, MIPv6-HoA and MN-HoA may 127 be the same or different. 129 MIPv6-CoA: the Care-of Address the MN includes in MIPv6 binding 130 update messages. Based on the scenario, MIPv6-HoA and MN-HoA may 131 be the same or different. 133 3. Overview of the scenarios and related issues 135 Several scenarios can be identified where Mobile IPv6 and Proxy 136 Mobile IPv6 are used in the same network. This document does not 137 only focus on scenarios where the two protocols are used by the same 138 mobile node to manage local and global mobility, but it investigates 139 also more complex scenarios where the protocols are more tightly 140 integrated or where there is a co-existence of nodes which do or do 141 not implement Mobile IPv6. 143 The following scenarios were identified: 145 o Scenario A - in this scenario Proxy Mobile IPv6 is used as a 146 network based local mobility management protocol whereas Mobile 147 IPv6 is used as a global mobility management protocol. This 148 interaction is very similar to the HMIPv6-MIPv6 interaction; 149 Mobile IPv6 is used to manage mobility among different access 150 networks, while the mobility within the access network is handled 151 by Proxy Mobile IPv6. The address managed by PMIPv6 (i.e. the MN- 152 HoA based on PMIPv6 terminology) is registered as Care-of Address 153 by the MN at the HA. This means that the HA has a binding cache 154 entry for MIPv6-HoA that points to the MN-HoA. 156 The following figure illustrates this scenario. 158 +----+ 159 | HA | MIPv6-HoA -> MN-HoA 160 +----+ 161 /\ 162 / \ 163 +-------------/----\--------------+ 164 ( / \ ) Global Mobile IPv6 165 ( / \ ) Domain 166 +----------/----------\-----------+ 167 / \ 168 +----+ +----+ 169 MN-HoA -> MAG1 |LMA1| |LMA2| 170 +----+ +----+ 171 //\\ \\ 172 +----//--\\---+ +-----\\------+ 173 ( // \\ ) ( \\ ) Local Mobility Network 174 ( // \\ ) ( \\ ) PMIPv6 domain 175 +-//--------\\+ +--------\\---+ 176 // \\ \\ 177 // \\ \\ 178 // \\ \\ 179 +----+ +----+ +----+ 180 |MAG1| |MAG2| |MAG3| 181 +----+ +----+ +----+ 182 | | | 183 [MN] 185 Figure 1 - Scenario A 187 o Scenario B - in this scenario some mobile nodes use Mobile IPv6 to 188 manage their movements while others rely on a network-based 189 mobility solution provided by the network. There is a common 190 mobility anchor that acts as Mobile IPv6 Home Agent and Proxy 191 Mobile IPv6 LMA, depending on the type of the node. 193 +--------+ 194 | HA/LMA | 195 +--------+ 197 +------+ +------+ 198 | MAG1 | | MAG2 | 199 +------+ +------+ 201 +-----------+ 202 | IPv6 host | -----------------> 203 +-----------+ movement 204 +----------+ 205 | MIPv6 MN | -----------------> 206 +----------+ movement 208 Figure 2 - Scenario B 210 o Scenario C - in this scenario the mobile node is moving across 211 different access networks, some of them supporting Proxy Mobile 212 IPv6 and some others not supporting it. Therefore the mobile node 213 is roaming from an access network where the mobility is managed 214 through a network-based solution to an access network where a 215 host-based management (i.e. Mobile IPv6) is needed. This 216 scenario may have different sub-scenarios depending on the 217 relations between the Mobile IPv6 home network and the Proxy 218 Mobile IPv6 domain. The following figure illustrates an example 219 of this scenario, where the MN is moving from an access network 220 where PMIPv6 is supported (i.e. MAG functionality is supported) 221 to a network where PMIPv6 is not supported (i.e. MAG 222 functionality is not supported by the AR). In this case the 223 MIPv6-HoA is equal to the MN-HoA (i.e. the address managed by 224 PMIPv6). 226 MIPv6-HoA == MN-HoA -> MAG1 227 +------+ 228 |HA/LMA|-----------------------+ 229 +------+ | 230 //\\ | 231 +-------//--\\--------+ | 232 ( // \\ PMIPv6 ) | 233 ( // \\ domain) +--------------+ 234 +----//--------\\-----+ ( Non-PMIPv6 ) 235 // \\ ( domain ) 236 // \\ +--------------+ 237 // \\ | 238 +----+ +----+ +----+ 239 |MAG1| |MAG2| | AR | 240 +----+ +----+ +----+ 241 | | | 242 [MN] 244 Figure 3 - Scenario C 246 In the above figure the non-PMIPv6 domain can actually be also a 247 different PMIPv6 domain that handles a different MN_HoA. The 248 following figure illustrates this sub-case: the MIPv6-HoA is equal 249 to the MN_HoA; however when the MN hands over to MAG3 it gets a 250 different IP address (managed by LMA2 using PMIPv6) and registers 251 it as a MIPv6 CoA. 253 MIPv6-HoA == MN-HoA -> MAG_1 254 +-------+ 255 |HA/LMA1|-----------------------+ 256 +-------+ | 257 //\\ +----+ 258 +-------//--\\--------+ |LMA2| 259 ( // \\ home ) +----+ 260 ( // \\ PMIPv6) +------||------+ 261 ( // \\domain) ( ||visited) 262 +---//----------\\----+ ( ||PMIPv6 ) 263 // \\ ( ||domain ) 264 // \\ +------||------+ 265 +----+ +----+ +----+ 266 |MAG1| |MAG2| |MAG3| 267 +----+ +----+ +----+ 268 | | | 269 [MN] 271 (a) 273 MIPv6-HoA -> MN_CoA 274 +-------+ 275 |HA/LMA1|-----------------------+ 276 +-------+ | 277 //\\ +----+ 278 +-------//--\\--------+ |LMA2| MN_CoA -> MAG3 279 ( // \\ home ) +----+ 280 ( // \\ PMIPv6) +------||------+ 281 ( // \\domain) ( ||visited) 282 +---//----------\\----+ ( ||PMIPv6 ) 283 // \\ ( ||domain ) 284 // \\ +------||------+ 285 +----+ +----+ +----+ 286 |MAG1| |MAG2| |MAG3| 287 +----+ +----+ +----+ 288 | | | 289 [MN] 291 (b) 293 Figure 4 - Scenario C with visited PMIPv6 domain 295 Note that some of the scenarios can be combined. For instance, 296 scenario B can be combined with scenario A or scenario C. 298 The following sections describe some possible issues for each 299 scenario. Note that the issues are described based on current 300 specification and does not assume any optimized solution for any 301 scenario. The specifications considered as a baseline for the 302 analysis are the following: [RFC3775], [RFC4877] and [pmipv6-draft]. 303 For example, the collocation of HA and LMA are considered as the 304 combination of HA according [RFC3775] and LMA according to 305 [pmipv6-draft], e.g. no combined binding caches are considered. The 306 analysis of the collocated HA and LMA would show what is the 307 preferred behaviour for this entity. The behaviour and respective 308 recommendations are described in Section 4.3. 310 3.1. Issues related to scenario A 312 This scenarios is very similar to other hierarchical mobility 313 schemes, including a HMIPv6-MIPv6 scheme. This is the scenario 314 referenced in [RFC4830]. No issues have been identified in this 315 scenario. Note that a race condition where the MN registers the CoA 316 at the HA before the CoA is actually bound to the MAG at the LMA is 317 not possible. The reason is that per PMIPv6 specification the MAG 318 does not forward any packets sent by the MN until the PMIPv6 tunnel 319 is up, regardless the mechanism used for address allocation. 321 Section 4.1 describes one message flow in case PMIPv6 is used as a 322 local mobility protocol and MIPv6 is used as a global mobility 323 protocol. 325 3.2. Issues related to scenario B 327 In this scenario there are two types of nodes in the access network: 328 some nodes support Mobile IPv6 while some others do not. The 329 rationale behind such a scenario is that the nodes implementing 330 Mobile IPv6 may prefer or be configured to manage their own mobility. 331 Obviously, nodes that do not implement MIPv6 must rely on the network 332 to manage their mobility: therefore Proxy MIPv6 is used for those 333 nodes. 335 Based on the current PMIPv6 solution described in [pmipv6-draft], in 336 any link of the PMIPv6 domain the MAG emulates the mobile node's home 337 link, advertising the home link prefix to the MN in a unicast Router 338 Advertisement message. This ensures that the IP address of the MN is 339 still considered valid by the MN itself. The home network prefix 340 (and any other information needed to emulate the home link) is 341 included in the mobile node's profile that is obtained by the MAG via 342 context transfer or via a policy store. 344 However, in case there are nodes that implement Mobile IPv6 and want 345 to use this protocol, the network must offer MIPv6 service to them. 346 In such case the MAG should not emulate the home link. Instead of 347 advertising the HNP, the MAG should advertise the topologically 348 correct local IP prefix, i.e. the prefix belonging to the MAG, so 349 that the MN detects an IP movement, configures a new CoA and sends a 350 MIPv6 Binding Update based on [RFC3775]. 352 3.3. Issues related to scenario C 354 Some issues are present in this scenario: 356 1. HoA management and lookup key in the binding cache 358 * in MIPv6 [RFC3775] the lookup key in the Binding Cache is the 359 Home Address of the MN. In particular, based on the base 360 specification [RFC3775], the MN does not include any 361 identifier, such as the MN-ID [RFC4283], in the Binding Update 362 message other than its Home Address. As described in 363 [RFC4877], the identifier of the MN is known by the Home Agent 364 after the IKEv2 exchange, but this is not used in the MIPv6 365 signaling, nor as a lookup key for the binding cache. On the 366 other hand, as specified in [pmipv6-draft], a Proxy Binding 367 Update contains the Home Prefix of the MN, the MN-ID and does 368 not include the Home Address of the MN (since it may not be 369 known by the MAG and consequently by the HA/LMA). The lookup 370 key in the binding cache of the LMA is either the home prefix 371 or the MN-ID. This implies that lookup keys for MIPv6 and 372 PMIPv6 registrations are different. Because of that, when the 373 MN moves from its home network (i.e. from the PMIPv6 domain) 374 to the foreign link, the Binding Update sent by the MN is not 375 identified by the HA as an update of the Proxy Binding Cache 376 Entry containing the home prefix of the MN, but a new binding 377 cache entry is created. Based on these considerations, there 378 is an "unused" (proxy) binding cache entry in the Binding 379 Cache of the LMA/HA. Note that the assumption in this section 380 is that the binding caches of the LMA and the HA are different 381 and there is not any combined binding cache. The need of such 382 a combined binding cache will be discussed in Section 4.3. 384 * When the MN returns to the MIPv6 home link that is also a 385 PMIPv6 domain, it de-registers to remove the binding cache 386 entry it had created. However in [RFC3775], de-registration 387 is recommended (but not mandatory). This implies that the MN 388 receives a Router Advertisement with the home prefix, may 389 start using its HoA directly, without tunneling uplink packets 390 but may not send a Binding Update to remove the binding cache 391 entry related to the HoA. In case the de-registration BU is 392 not sent, the PBU sent by the MAG will not update the Binding 393 Cache entry related to the HoA, but will create a new proxy 394 binding cache entry including the home prefix of the MN, the 395 MN-ID and the MAG address. This implies that, in case the MN 396 does not send a de-registration binding update when returning 397 home, the downlink packets may still be tunneled to the CoA 398 and not to the MAG. 400 2. MIPv6 de-registration Binding Update deletes PMIPv6 binding cache 401 entry 403 * When the mobile node moves from a MIPv6 foreign network to the 404 PMIPv6 home domain, the MAG registers the mobile node at the 405 LMA by sending a Proxy Binding Update. Subsequently, the LMA 406 updates the mobile node's binding cache entry with the MAG 407 address and the MAG emulates the mobile node's home link. 408 Upon detection of the home link, the mobile node will send a 409 de-registration Binding Update to its home agent. According 410 to RFC3775, the home agent would delete the binding cache 411 entry after accepting the de-registration Binding Update, 412 i.e., it would delete the proxy binding cache entry that was 413 just established by the MAG. Hence, packets arriving at the 414 LMA and destined for the mobile node would not be forwarded to 415 the mobile node anymore. 417 3. Race condition between Binding Update and Proxy Binding Update 418 messages (Sequence Numbers and Timestamps) 420 * MIPv6 and PMIPv6 use different mechanisms for handling re- 421 ordering of registration messages and they are sent by 422 different entities. Whereas Binding Update messages are 423 ordered by a sequence numbers and sent by the mobile node, 424 Proxy Binding Update messages are ordered by a timestamp 425 option and sent by MAGs. 427 * Assuming the mobile node's MAG sends a Proxy Binding Update 428 message (for refreshing the mobile node's BCE or because the 429 mobile node has just done a handover to this MAG) and shortly 430 thereafter the mobile node moves out of the PMIP home domain, 431 where it configures a new MIPv6-CoA and sends a Binding Update 432 message to its home agent. If now the Proxy Binding Update 433 message from the MAG is delayed so that it reaches the LMA 434 after the Binding Update, the binding cache entry at the LMA 435 would wrongly point to the MAG. Without further measures, 436 packets are not forwarded to the mobile node unless a new 437 Binding Update is sent by the mobile node. This may result in 438 a significant packet loss. A similar situation can occur if 439 the mobile node sends a Binding Update messsage from outside 440 the PMIP home domain and shortly thereafter enters the PMIP 441 home domai 443 4. Use of wrong home agent or LMA after handover 445 * This issues can arise if multiple LMAs are deployed in the 446 PMIP home domain. If the mobile node moves from a MIPv6 447 foreign network to the PMIP home domain, the MAG must send the 448 Proxy Binding Update to the particular LMA that is co-located 449 with the home agent which maintains the active binding cache 450 entry of the mobile node. If a different LMA is assigned to 451 the MAG, packets addressed to the mobile node's home address 452 do not reach the mobile node anymore. 454 * Similarly, if the mobile node moves from the PMIP home domain 455 to a MIPv6 foreign network, the mobile node must send the 456 Binding Update to the particular home agent that is co-located 457 with the LMA which maintains the active proxy binding cache 458 entry of the mobile node. If the mobile node selects a 459 different home agent, packets addressed to the mobile node's 460 home address do not reach the mobile node. 462 5. Threat of compromised MAG 464 * In MIPv6 base specification [RFC3775] there is a strong 465 binding between the Home Address registered by the MN and the 466 Security Association used to modify the corresponding binding 467 cache entry. 469 * In PMIPv6 specification, the MAG sends proxy binding updates 470 on behalf of a mobile node to update the binding cache entry 471 that corresponds to the mobile node's home address. Since the 472 MAG sends the binding updates, PMIPv6 requires security 473 associations between each MAG and the LMA. 475 * As described in [RFC4832], in PMIPv6 the MAG compromise or 476 impersonation is an issue. RFC4832, section 2.2, describes 477 how a compromised MAG can harm the functionality of LMA, e.g. 478 manipulating LMA's routing table (or binging cache). 480 * In this mixed scenario, both host-based and network-based 481 security associations are used to update the same binding 482 cache entry at the HA/LMA (but see the first bullet of this 483 list, as the entry may not be the same). Based on this 484 consideration, the threat described in [RFC4832] is worse as 485 it affects also hosts that are using the LMA/HA as MIPv6 HA 486 and are not using PMIPv6 488 4. Analysis of possible solutions 490 4.1. Solutions related to scenario A 492 As mentioned in Section 3.1, there are no significant issues in this 493 scenario. 495 Figures 5 and 6 show a scenario where a MN is moving from one PMIPv6 496 domain to another, based on the scenario of Figure 1. In Figure 5, 497 the MN moves from an old MAG to MAG2 in the same PMIPv6 domain: this 498 movement triggers a PBU to LMA1 and the updating of the binding cache 499 at the LMA1; there is no MIPv6 signaling as the CoA_1 registered at 500 the HA is the Home Address for the PMIPv6 session. In Figure 6, the 501 MN moves from MAG2 in the LMA1 PMIPv6 domain to MAG3 in a different 502 PMIPv6 domain: this triggers the PMIPv6 signaling and the creation of 503 a binding at the LMA2. On the other hand, the local address of the 504 MN is changed, as the LMA hss changed, and therefore the MN sends a 505 MIPv6 Binding Update to the HA with the new CoA_2. 507 +----+ +------+ +------+ +----+ 508 | MN | | MAG2 | | LMA1 | | HA | 509 +----+ +------+ +------+ +----+ 510 | | | | 511 | | | +-----------------+ 512 | | | | HoA -> CoA_1 | 513 | | | | binding present | 514 | | | +-----------------+ 515 | | | | 516 | CoA conf/confirm | PBU(CoA_1,MAG_2) | | 517 | <--------------->| ----------------->| | 518 | | +-----------------+| 519 | | | CoA_1 -> MAG_2 || 520 | | | binding updated || 521 | | +-----------------+| 522 | | PBA | | 523 | | <----------------| | 524 | | | | 526 Figure 5 - Local Mobility Message Flow 528 +----+ +------+ +------+ +----+ 529 | MN | | MAG3 | | LMA2 | | HA | 530 +----+ +------+ +------+ +----+ 532 | CoA config | PBU(CoA_2,MAG_3) | | 533 |<---------------->|------------------->| | 534 | | +-----------------+ | 535 | | | CoA_2 -> MAG_3 | | 536 | | | binding created | | 537 | | +-----------------+ | 538 | | PBA | | 539 | |<-------------------| | 540 | | | | 541 | | BU (HoA, CoA_2) | | 542 |---------------------------------------------------->| 543 | | | | 544 | | | +-----------------+ 545 | | | | HoA -> CoA_2 | 546 | | | | binding updated | 547 | | | +-----------------+ 548 | | BA | | 549 |<----------------------------------------------------| 551 Figure 6 - Global Mobility Message Flow 553 4.2. Solutoins related to scenario B 555 The solution for this scenario may depend on the access network being 556 able to determine that a particular mobile node wants to use Mobile 557 IPv6. This would require a solution at the system level for the 558 access network and is out of scope of this document. Solutions that 559 do not depend on the access network are out of the scope of this 560 document. 562 4.3. Solutions related to scenario C 564 As described in Section 3.3, in this scenario the mobile node relies 565 on Proxy Mobile IPv6 as long as it is in the Proxy Mobile IPv6 566 domain. The mobile node then uses Mobile IPv6 whenever it moves out 567 of the PMIPv6 domain. 569 This section provides an analysis of the solutions for the issues 570 described in Section 3.3. The analysis is performed in two different 571 subsections, depending if the MN moves from a PMIPv6 domain to a non- 572 PMIPv6 domain or vice versa. 574 4.3.1. Mobility from a PMIPv6 domain to a non-PMIPv6 domain 576 Let's assume the MN is attached to a PMIPv6 domain and there is a 577 valid Proxy Binding Cache entry at the LMA. Then the MN moves to a 578 adifferent access network and starts using MIPv6 (e.g. because PMIPv6 579 is not supported). The MN needs to bootstrap MIPv6 parameters and 580 send a MIPv6 Binding Update in order to have service continuity. 581 Therefore the following steps must be performed by the UE: 583 o HA/LMA address discovery: the MN needs to discover the IP address 584 of the LMA which has a valid binding cache entry for its home 585 network prefix. This is described in Section 3.3 as issue 4. 587 o Security Association establishment: the MN needs to establish an 588 IPsec Security Association with the HA/LMA as described in 589 [RFC4877] 591 o HoA assignment: as part of the MIPv6 bootstrapping procedure the 592 HA assigns a MIPv6 HoA to the MN. This address must be the same 593 the MN was using in the PMIPv6 domain. 595 Since all these steps must be performed by the MN before sending the 596 Binding Update, they have an impact on the handover latency 597 experienced by the MN. For this reason it is recommended that the MN 598 establishes the IPsec security association (and consequently is 599 provided by the HA/LMA with a MIPv6-HoA) when it is still attached to 600 the PMIPv6 domain. This implies that the mobile node has Mobile IPv6 601 stack active while in the PMIPv6 domain, but as long as it is 602 attached to the same Proxy Mobile IPv6 domain, it will appear to the 603 mobile node as if it is attached to the home link. 605 In order to establish the security association with the HA/LMA, the 606 MN needs to discover the IP address of the LMA/HA while in the PMIPv6 607 domain. This can be done either based on DNS or based on DHCPv6, as 608 described in [RFC5026] and [boot-integrated]. The network should be 609 configured so that the MN discovers or gets assigned the same HA/LMA 610 that was serving as the LMA in the PMIPv6 domain. Details of the 611 exact procedure are out of scope of this document. 613 When the MN establishes the security association, it pacquires a home 614 address based on [RFC5026]. However, based on PMIPv6 operations, the 615 LMA knows only the Home Network Prefix used by the MN and does not 616 know the MN-HoA.For this reason, the MN must be configured to propose 617 MN-HoA as the home address in the IKEv2 INTERNAL_IP6_ADDRESS 618 attribute during the IKEv2 exchange with the HA/LMA. Note that the 619 security association must be bound to the MN-HoA used in the PMIPv6 620 domain as per [RFC4877]. 622 When the MN hands over to an access network which does not support 623 Proxy Mobile IPv6, it sends a Binding Update to the HA/LMA. The 624 LMA/HA must match the HoA with the MN-ID and update the respective 625 BCE accordingly. This is because the proxy BCE is associated to the 626 MN-ID and MN-HNP and not to the MN-HoA. Note that this implies a 627 change in the BU processing if compared to RFC 3775: the LMA/HA must 628 match the HoA included in the BU with the MN-ID known based on IKEv2 629 signalling and update the respective BCE accordingly (clearing the P 630 flag). 632 More generally, when the LMA and the HA are co-located, binding cache 633 lookup for a mobile node must use a combination of the mobile node's 634 identifier and the home address. The Binding Update from the mobile 635 node contains the home address of the mobile node, whereas the Proxy 636 Binding Update from the MAG contains only the mobile node's 637 identifier. Therefore when transitioning between using Proxy Mobile 638 IPv6 and Mobile IPv6, the Home Agent must ensure that the mobile 639 node's binding cache entry must be looked up with both the home 640 address and identifier of the mobile node. This requires the Home 641 Agent to acquire the mobile node identifier other than from the 642 Binding Update message (for e.g., from the preceding IKEv2 exchange 643 that set up security associations for sending the Binding Update) and 644 to store it as part of the binding cache entry for the mobile node. 645 Note that this requires that the MN-ID used by the mobile node during 646 the IKEv2 set-up is the same of the MN-ID used by the MAG in PMIPv6 647 signalling. This solves the issue 1 described in Section 3.3. 649 Note that in this scenario the same binding cache entry for the 650 mobile node is at times modified by the mobile node and other times 651 modified by a MAG. The home agent must ensure that only authorized 652 MAGs in addition to the mobile node are allowed to modify the binding 653 cache entry for the mobile node. This is valid, even though not 654 explicitly mentioned, also for the next subsection. 656 4.3.2. Mobility from a non-PMIPv6 domain to a PMIPv6 domain 658 In this section it is assumed that the MN is in a non-PMIPv6 access 659 network and it has bootstrapped MIPv6 operations based on [RFC5026]; 660 therefore there is valid binding cache for its MIPv6-HoA at the HA. 661 Then the MN moves to a PMIPv6 domain which is configured to be the 662 home link for the MIPv6-HoA the MN has been assigned. 664 In order to provide session continuity, the MAG needs to send a PBU 665 to the HA/LMA that was serving the MN. The MAG needs to discover the 666 HA/LMA; however the current version of [pmipv6-draft] assumes that 667 the LMA is assigned or discovered when the MN attaches to the MAG. 668 the exact mechanism is not specified in [pmipv6-draft]. A detailed 669 description of the necessary procedure is out of the scope of this 670 document. Note that the MAG may also rely on static configuration or 671 lower layer information provided by the MN in order to select the 672 correct HA/LMA. 674 The PBU sent by the MAG must update the MIPv6 BCE of the MN. However 675 this PBU contains the MN-HNP and not the MN-HoA. For this reason, in 676 order to ensure that the PMIPv6 addressing model is maintained when 677 the MN moves back to the PMIPv6 domain, a HA which acts also as LMA 678 must allocate a home network prefix to the MN, even though during the 679 MIPv6 bootstrapping only a /128 Home Address is assigned. It is 680 implementation specific if this prefix is stored on the MIPv6 BCE 681 when the MN is just using MIPv6. 683 As the MN moves to its home link, it will send a de-registration 684 binding update with zero lifetime to its home agent. This is done 685 approximately at the same time the MAG the sends a Proxy Binding 686 Update to the LMA functionality co-located with the home agent. 687 Actually the de-registration of the MN will be received by the HA/LMA 688 after the PBU from the MAG as, based on [pmipv6-draft], the MAG 689 forwards pakets only when the PMIPv6 tunnel is established. The HA/ 690 LMA MUST NOT delete the binding cache entry for the mobile node after 691 receiving a de-registration BU if in the binding cache there is a BCE 692 with the P-flag set for the same MN. This solves issue 2 described 693 in Section 3.3. 695 NOTE: A solution for race conditions between BU and PBU messages 696 (issue #3) is TBD. 698 5. Security Considerations 700 Scenarios A and B described in Section 3 do not introduce any 701 security considerations in addition to those described in [pmipv6- 702 draft] or [RFC3775]. 704 In Scenario C described in Section 3.3, the home agent has to allow 705 the authorized MAGs in a particular PMIPv6 domain to be able to 706 modify the binding cache entry for a mobile node. [RFC3775] requires 707 that only the right mobile node is allowed to modify the binding 708 cache entry for its home address. This document requires that the a 709 home agent that also implements the PMIPv6 LMA functionality should 710 allow both the mobile node and the authorized MAGs to modify the 711 binding cache entry for the mobile node. Note that the compromised 712 MAG threat described in [RFC4832] applies also here; in this scenario 713 the threat is worse as it affects also hosts that are using the 714 LMA/HA as MIPv6 HA and are not using PMIPv6. 716 6. Additional Authors 718 Chowdhury, Kuntal - kchowdhury@starentnetworks.com 720 Hesham Soliman - Hesham@elevatemobile.com 722 Vijay Devarapalli - vijay.devarapalli@azairenet.com 724 Sri Gundavelli - sgundave@cisco.com 726 Kilian Weniger - Kilian.Weniger@eu.panasonic.com 728 Genadi Velev - Genadi.Velev@eu.panasonic.com 730 Ahmad Muhanna - amuhanna@nortel.com 732 7. Acknowledgements 734 This document is a merge of three different Internet Drafts: 735 draft-weniger-netlmm-pmipv6-mipv6-issues-00, 736 draft-devarapalli-netlmm-pmipv6-mipv6-01and 737 draft-giaretta-netlmm-mip-interactions-00. Thanks to the authors and 738 editors of those drafts. 740 The authors would also like ot thank Jonne Soininen and Vidya 741 Narayanan, NETLMM WG chairs, for their support. 743 8. References 745 8.1. Normative References 747 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 748 Requirement Levels", BCP 14, RFC 2119, March 1997. 750 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 751 in IPv6", RFC 3775, June 2004. 753 [RFC4830] Kempf, J., "Problem Statement for Network-Based Localized 754 Mobility Management (NETLMM)", April 2007. 756 [RFC4832] Vogt, C. and J. Kempf, "Security Threats to Network-Based 757 Localized Mobility Management (NETLMM)", April 2007. 759 [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 760 IKEv2 and the Revised IPsec Architecture", 2005. 762 [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 763 Bootstrapping in Split Scenario", RFC 5026, October 2007. 765 [boot-integrated] 766 Chowdhury, K., Ed., "MIP6-bootstrapping for the Integrated 767 Scenario", 2007. 769 [pmipv6-draft] 770 Gundavelli, S., Ed., "Proxy Mobile IPv6", 2007, . 774 8.2. Informative References 776 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 777 RFC 3753, June 2004. 779 [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 780 Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 781 (MIPv6)", RFC 4283, November 2005. 783 [RFC4831] Kempf, J., "Goals for Network-Based Localized Mobility 784 Management (NETLMM)", RFC 4831, April 2007. 786 Author's Address 788 Gerardo Giaretta (editor) 789 Qualcomm 791 Email: gerardog@qualcomm.com 793 Full Copyright Statement 795 Copyright (C) The IETF Trust (2007). 797 This document is subject to the rights, licenses and restrictions 798 contained in BCP 78, and except as set forth therein, the authors 799 retain all their rights. 801 This document and the information contained herein are provided on an 802 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 803 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 804 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 805 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 806 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 807 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 809 Intellectual Property 811 The IETF takes no position regarding the validity or scope of any 812 Intellectual Property Rights or other rights that might be claimed to 813 pertain to the implementation or use of the technology described in 814 this document or the extent to which any license under such rights 815 might or might not be available; nor does it represent that it has 816 made any independent effort to identify any such rights. Information 817 on the procedures with respect to rights in RFC documents can be 818 found in BCP 78 and BCP 79. 820 Copies of IPR disclosures made to the IETF Secretariat and any 821 assurances of licenses to be made available, or the result of an 822 attempt made to obtain a general license or permission for the use of 823 such proprietary rights by implementers or users of this 824 specification can be obtained from the IETF on-line IPR repository at 825 http://www.ietf.org/ipr. 827 The IETF invites any interested party to bring to its attention any 828 copyrights, patents or patent applications, or other proprietary 829 rights that may cover technology that may be required to implement 830 this standard. Please address the information to the IETF at 831 ietf-ipr@ietf.org. 833 Acknowledgment 835 Funding for the RFC Editor function is provided by the IETF 836 Administrative Support Activity (IASA).