idnits 2.17.1 draft-giaretta-netlmm-mip-interactions-00.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 942. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 953. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 960. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 966. 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 : ---------------------------------------------------------------------------- No issues found here. 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 (April 24, 2007) is 6212 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 4140 (Obsoleted by RFC 5380) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETLMM Working Group H. Soliman 3 Internet-Draft Elevate Technologies 4 Intended status: Informational G. Giaretta, Ed. 5 Expires: October 26, 2007 April 24, 2007 7 Interactions between PMIPv6 and MIPv6: scenarios and related issues 8 draft-giaretta-netlmm-mip-interactions-00 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 October 26, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 There has been a lot of discussion and analysis of how Mobile IPv6 42 and Proxy Mobile IPv6 can interact. A deeper analysis on the possible 43 scenarios and related issues is necessary in order to provide 44 guidelines to PMIPv6 protocol specification. With this purpose in 45 mind, this document describes all scenarios of possible interactions 46 between Mobile IPv6 and Proxy Mobile IPv6 and discusses a list of 47 issues related to the each scenario. 49 Requirements Language 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in RFC 2119 [RFC2119]. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Overview of the scenarios . . . . . . . . . . . . . . . . . . 4 60 4. Scenarios and related issues . . . . . . . . . . . . . . . . . 7 61 4.1. Scenario A - Hierarchical Mobility . . . . . . . . . . . . 7 62 4.2. Scenario B - Two types of nodes in the network . . . . . . 11 63 4.3. Scenario C - Movements between PMIPv6-enable and non 64 PMIPv6-enabled access networks . . . . . . . . . . . . . . 13 65 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 20 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 68 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 70 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 71 9.2. Informative References . . . . . . . . . . . . . . . . . . 22 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 73 Intellectual Property and Copyright Statements . . . . . . . . . . 23 75 1. Introduction 77 The NETLMM WG is chartered to standardize a network-based protocol 78 for localized mobility management. The goals that must be fulfilled 79 by the protocol design are listed in rfc4831. Proxy Mobile IPv6 has 80 been designated as the network-based localized mobility management 81 protocol that will be standardized by IETF. 83 There are two main reasons why the interactions between Proxy Mobile 84 IPv6 and Mobile IPv6 need to be studied. The first reason is that 85 Mobile IPv6 is the main global mobility management protocol developed 86 in IETF; it is therefore natural to investigate the details of a 87 hierarchical mobility scheme where Proxy Mobile IPv6 is used for 88 local mobility and Mobile IPv6 is used for global mobility. 90 The second reason is that Mobile IPv6 has been chosen by the NETLMM 91 WG mainly for reusability grounds: during the protocol selection 92 decision, it has been stated that Mobile IPv6 HA implementation can 93 be somehow re-used (with minimal modifications) to act as Proxy 94 Mobile IPv6 Local Mobility Anchor. 96 Moreover, based on these considerations, some SDOs are investigating 97 complex scenarios where the mobility of some nodes are handled using 98 Proxy Mobile IPv6, while other nodes manage their own movements using 99 Mobile IPv6; or the mobility of a node is managed in turn by a host- 100 based and a network-based mechanism. 102 The main purpose of this document is to provide a taxonomy of the 103 scenarios where Mobile IPv6 and Proxy Mobile IPv6 can be used 104 together. Moreover the document will also identify the issues that 105 may be present in those scenarios, identifying the requirements that 106 Proxy Mobile IPv6 and/or Mobile IPv6 must fulfill in order to enable 107 them. 109 In this document we make the assumption that a node using Mobile IPv6 110 is compliant with the Mobile IPv6 base specification [RFC3775] 111 [RFC3776] (i.e. extensions defined [RFC4283] [RFC4285] in are not 112 used). 114 Note that some issues identified in this document may be solved by 115 existing internet drafts that provide PMIPv6 solutions. However, 116 these issues are listed anyhow as the intent of this document is to 117 list the issues that some scenarios may present without going into 118 the details of the solution space. 120 This document is organized as follows: Section 3 gives an overview of 121 the scenarios, Section 4 describes in details the scenarios and list 122 the issues that must be solved in order to enable those scenarios and 123 Section 5 provides some final considerations and some suggestions on 124 the next steps in NETLMM WG. 126 2. Terminology 128 General mobility terminology can be found in [RFC3753]. Other terms 129 used in this document are defined as follows: 131 o Local Mobility Anchor (LMA) 133 Local Mobility Anchor is the home agent for the mobile node in 134 the Proxy Mobile IPv6 domain. It is the topological anchor 135 point for the mobile node's home prefix and is the entity that 136 manages the mobile node's reachability state. 138 o Mobile Access Gateway (MAG) 140 Mobile Access Gateway (MAG) is the proxy mobility agent in the 141 network which manages the mobility related signaling for a 142 mobile node that is attached to its access link. It is the 143 entity responsible for tracking the mobile node's attachment to 144 the link and for signaling the mobile node's local mobility 145 anchor. 147 o Proxy Mobile IPv6 Domain (PMIPv6-Domain) 149 It is a localized mobility management domain where the mobility 150 management of a mobile node is handled using Proxy Mobile IPv6 151 protocol as defined in this specification. 153 o Proxy Binding Update (PBU) 155 A PMIPv6 Binding Update sent by the MAG to the LMA as specified 156 in draft-ietf-netlmm-proxymip6-00. 158 3. Overview of the scenarios 160 Several scenarios can be identified where Mobile IPv6 and Proxy 161 Mobile IPv6 are used. This document will not focus only on scenarios 162 where the two protocols are used by the same mobile node to manage 163 local and global mobility, but it will also investigate also more 164 complex scenarios where the protocols are used beyond their original 165 scope or where some nodes implement Mobile IPv6 and others do not 166 implement it. 168 The following scenarios were identified: 170 o Scenario A - in this scenario Proxy Mobile IPv6 is used as a 171 network based local mobility management protocol whereas Mobile 172 IPv6 is used as a global mobility management protocol. This 173 interaction is very similar to the HMIPv6-MIPv6 interaction; 174 Mobile IPv6 is used to manage mobility among different access 175 networks, while the mobility within the access network is handled 176 by Proxy Mobile IPv6. 178 The following figure illustrates this scenario. 180 +----+ 181 | HA | 182 +----+ 184 Access Net #1 Access Net #2 185 (PMIPv6 Domain #1) (PMIPv6 Domain #2) 186 ________________ ________________ 187 / \ / \ 188 / +------+ \ / +------+ \ 189 / | LMA1 | \ / | LMA2 | \ 190 \ +------+ / \ +------+ / 191 \ / \ / 192 \________________/ \________________/ 194 +----+ 195 | MN | -----------------> 196 +----+ movement 198 Figure 1 - Scenario A 200 o Scenario B - in this scenario some mobile nodes use Mobile IPv6 to 201 manage their movements while others rely on a network-based 202 mobility solution provided by the network. There is a common 203 mobility anchor that acts as Mobile IPv6 Home Agent and Proxy 204 Mobile IPv6 LMA, depending on the type of the node. 206 +--------+ 207 | HA/LMA | 208 +--------+ 210 +------+ +------+ 211 | MAG1 | | MAG2 | 212 +------+ +------+ 214 +-----------+ 215 | IPv6 host | -----------------> 216 +-----------+ movement 217 +----------+ 218 | MIPv6 MN | -----------------> 219 +----------+ movement 221 Figure 2 - Scenario B 223 o Scenario C - in this scenario the mobile node is moving across 224 different access networks, some of them supporting Proxy Mobile 225 IPv6 and some others not supporting it. Therefore the mobile node 226 is roaming from an access network where the mobility is managed 227 through a network-based solution to an access network where a 228 host-based management (i.e. Mobile IPv6) is needed. This 229 scenario may have different sub-scenarios depending on the 230 relations between the Mobile IPv6 home network and the Proxy 231 Mobile IPv6 domain. The following figure illustrates an example 232 of this scenario, where the MN is moving from an access network 233 where PMIPv6 is supported (i.e. MAG functionality is supported) 234 to a network where PMIPv6 is not supported (i.e. MAG 235 functionality is not supported by the AR): more details are 236 described in section Section 4. 238 +--------+ 239 | HA/LMA | 240 +--------+ 242 +-----+ +----+ 243 | MAG | | AR | 244 +-----+ +----+ 246 +----------+ 247 | MIPv6 MN | -----------------> 248 +----------+ movement 250 Figure 3 - Scenario C 252 4. Scenarios and related issues 254 In this section a more comprehensive description of the identified 255 scenarios is presented. Moreover, for each scenarios the possible 256 issues are identified. Note that, as mentioned before, some of these 257 issues may be already solved in any of the PMIPv6 related internet 258 drafts; however, the intent of this document is just to highlight the 259 possible issues related to the identified scenarios, without going 260 into solution space (at least for now), in order to get a complete 261 picture of the possible interactions between PMIPv6 and MIPv6 and to 262 understand which functionalities are needed from a protocol 263 perspective. 265 4.1. Scenario A - Hierarchical Mobility 267 As described in Section 3, in this scenario PMIPv6 is used as a local 268 mobility management protocol, while Mobile IPv6 is used to manage 269 global mobility. This means that the address handled by PMIPv6 270 operations is the Care-of Address from a Mobile IPv6 perspective. 272 Figure 4 shows the details of this scenario. In figure (a) the 273 mobile node has a Home Address and a Care-of Address (CoA_1) and is 274 registered at the HA based on [RFC3775]; therefore there is a MIPv6 275 tunnel between the HA and the MN. Since the MN is attached at MAG1, 276 there is a PMIPv6 tunnel between the LMA1 and the MAG1: the address 277 managed by this tunnel is the CoA_1 of the MN. 279 +----+ 280 | HA | HoA -> CoA_1 281 +----+ 283 CoA_1 -> MAG_1 | 284 +------+ . +------+ 285 | LMA1 | | | LMA2 | 286 +------+ . +------+ 287 | 288 | 289 +------+ +------+ . 290 | MAG1 | | MAG2 | | 291 +------+ +------+ . 292 ^ | 293 | | 294 v . 295 +----+ | 296 | MN | . 297 +----+ | 298 HoA & CoA_1 . 299 | 300 . 301 PMIPv6 Domain #1 | PMIPv6 Domain #2 303 (a) 305 +----+ 306 | HA | HoA -> CoA_1 307 +----+ 309 CoA_1 -> MAG_2 | 310 +------+ . +------+ 311 | LMA1 | | | LMA2 | 312 +------+ . +------+ 313 | 314 | 315 +------+ +------+ . 316 | MAG1 | | MAG2 | | 317 +------+ +------+ . 318 ^ | 319 | | 320 v . 321 +----+ | 322 | MN | . 323 +----+ | 324 HoA & CoA_1 . 325 | 326 . 327 PMIPv6 Domain #1 | PMIPv6 Domain #2 329 (b) 331 Figure 4 - Local Mobility with PMIPv6 333 Figure 4 (b) shows the MN attached at MAG2. After the MN has moved 334 to MAG2 link, based on PMIPv6 protocol operations, MAG2 sends a Proxy 335 Binding Update to the LMA1 containing its own address and the address 336 of the MN (i.e. CoA_1). The result of this registration is that the 337 PMIPv6 tunnel is switched from MAG1 to MAG2 and therefore a tunnel 338 between LMA1 and MAG2 is created. Note that the MN has experienced a 339 movement within the PMIPv6 Domain #1: this movement has not triggered 340 any Mobile IPv6 operations, since the MN does not need to change its 341 CoA_1 based on PMIPv6 operations. 343 Figure 5 shows a global mobility scenario: the MN is moving across 344 different PMIPv6 domains: in the new link, belonging to PMIPv6 domain 345 #2, the MN configures a new CoA (i.e. CoA_2) and sends a MIPv6 346 Binding Update to the HA, updating its binding cache entry. On the 347 other hand, MAG3 sends a Proxy Binding Update to LMA2, creating a new 348 PMIPv6 binding cache entry related to CoA_2. 350 +----+ 351 | HA | HoA -> CoA_2 352 +----+ 354 | CoA_2 -> MAG_3 355 +------+ . +------+ 356 | LMA1 | | | LMA2 | 357 +------+ . +------+ 358 | 359 | 360 +------+ +------+ . +------+ 361 | MAG1 | | MAG2 | | | MAG3 | 362 +------+ +------+ . +------+ 363 | ^ 364 | | 365 . v 366 | +----+ 367 . | MN | 368 | +----+ 369 . HoA & CoA_2 370 | 371 . 372 PMIPv6 Domain #1 | PMIPv6 Domain #2 374 Figure 5 - Global Mobility with Mobile IPv6 376 This scenarios and the related sub-scenarios are very similar to any 377 other hierarchical mobility scheme, including a HMIPv6-MIPv6 scheme. 378 However, there are two main differences between the case when the 379 local mobility is handled via a network-based scheme: 381 o if a host-based protocol is used, such as HMIPv6 [RFC4140], smooth 382 transition can be achieved when handing off between two different 383 LMM domains as the MN may keep the binding at the old MAP, while 384 creating a binding with the new MAP and configuring a new Regional 385 CoA. In particular, the overlapping domains allow the MN to 386 configure more than on RCoA and manage the tunnels between them, 387 based on the mobility pattern and the MN's requirements. This is 388 surely more difficult if PMIPv6 is used, since when the MN gets a 389 new address, it will swtch using that one (i.e. the usage of 390 mutiple addresses in PMIPv6 seems more difficult than in a host- 391 based mobility solution such as HMIPv6). 393 o if a host-based protocol is used for local mobility, race 394 conditions cannot occur since the MN sends the MIPv6 Binding 395 Update only when the Regional Care-of Address has been confirmed 396 by the local anchor (e.g. MAP). This should occur also in the 397 case the local mobility is handled by the network: the CoA should 398 be confirmed to the MN only after a correct binding at the local 399 anchor (i.e. LMA) is created. However, since the address 400 allocation to the MN is not fully in the scope of PMIPv6 (i.e. 401 MN-AR interface is system-specific), it may occur that the MN 402 registers the CoA at the HA before the CoA is actually bound to 403 the location of the MN (i.e. MAG). This seems only an issue in 404 principle and it should occur very rarely, though. 406 The following figures describe the details of the message flows for 407 local and global mobility in this hierarchical scheme. 409 +----+ +------+ +------+ +----+ 410 | MN | | MAG2 | | LMA1 | | HA | 411 +----+ +------+ +------+ +----+ 413 +-----------------+ 414 | HoA -> CoA_1 | 415 | binding present | 416 +-----------------+ 418 CoA config/confirm PBU(CoA_1,MAG_2) 419 <----------------> ------------------> 420 +-----------------+ 421 | CoA_1 -> MAG_2 | 422 | binding updated | 423 +-----------------+ 424 PBA 425 <------------------ 427 Figure 6 - Local Mobility Message Flow (see Figure 4b) 429 +----+ +------+ +------+ +----+ 430 | MN | | MAG3 | | LMA2 | | HA | 431 +----+ +------+ +------+ +----+ 433 CoA config PBU(CoA_2,MAG_3) 434 <----------------> ------------------> 435 +-----------------+ 436 | CoA_2 -> MAG_3 | 437 | binding created | 438 +-----------------+ 439 PBA 440 <------------------ 442 BU (HoA, CoA_2) 443 ----------------------------------------------------> 445 +-----------------+ 446 | HoA -> CoA_1 | 447 | binding updated | 448 +-----------------+ 449 BA 450 <---------------------------------------------------- 452 Figure 7 - Global Mobility Message Flow (see Figure 5) 454 Based on the message flows of Figure 6 and Figure 7 and on the 455 analysis presented above, there is not any issue in this scenario. 456 The only possible issue is the race condition mentioned earlier but 457 we have already stated that such an event should not occur if the 458 entry in the LMA is created before the local address is confirmed to 459 the MN. 461 4.2. Scenario B - Two types of nodes in the network 463 In this scenario there are two types of nodes in the access network: 464 some nodes support Mobile IPv6 while some others do not. The 465 rationale behind such a scenario is that the nodes implementing 466 Mobile IPv6 may prefer to manage their own mobility leveraging a 467 host-based paradigm, in order for example to exploit some advantages 468 of Mobile IPv6 protocol (e.g. route optimization support, 469 confidentiality support for data packets between MN and HA). 470 Obviously, nodes that do not implement MIPv6 must rely on the network 471 to manage their mobility: therefore Proxy MIPv6 is used for those 472 nodes. 474 The issues with this scenario are related to the design of the MN-AR 475 interface, that is out of scope of current NETLMM WG charter (even 476 though there is an Informational RFC on this topic among the 477 milestones). However, it is worth discussing the possible issues 478 introduced by this scenario in order to understand whether they can 479 be solved at system level or have any impact on the choices in the 480 PMIPv6 protocol design. 482 Based on the current PMIPv6 solution described in 483 draft-ietf-netlmm-proxymip6-00, in any link of the PMIPv6 domain the 484 MAG emulates the mobile node's home link, advertising the home link 485 prefix to the MN in a unicast Router Advertisement message. This 486 ensures that the IP address of the MN is still considered valid by 487 the MN itself. The home link prefix information (and any other 488 information needed to emulate the home link) are included in the 489 mobile node's profile that is obtained by the MAG via context 490 transfer or via a policy store. 492 However, in case there are nodes that implement Mobile IPv6 and want 493 to use this protocol to manage their movements, the MAG should not 494 emulate the home link. Instead, a prefix specific of the access link 495 should be advertised so that the MN detects an IP movement, 496 configures a new CoA and sends a MIPv6 Binding Update based on 497 [RFC3775]. 499 Therefore the MAG should somehow know that a MN is using MIPv6 in 500 order to send the correct Router Advertisement. A possible solution 501 could be that this information is stored in the mobile node's 502 profile; however, this approach is affected by some issues: 504 o Mobile IPv6 support on the terminal may not be an information that 505 is available in the mobile node profile. This is because MIPv6 506 may be an additional software on a terminal, that can be installed 507 or activated at any time. Moreover, 508 draft-ietf-netlmm-proxymip6-00 does not give enough information on 509 what is the mobile node's profile and how is created (e.g. whether 510 it is linked to the user's profile, whether it is created at the 511 attach and how it is maintained). 513 o this approach implies that the access network must have a new 514 functionality, since the Access Router must check the mobile 515 node's profile even if the MN is using Mobile IPv6. This does not 516 follow the Mobile IPv6 assumption that the access network does not 517 have any role in the procedures related to the change of the IP 518 address. Moreover, if context transfer is used to make the MAG 519 aware of the mobile node's profile, a context transfer may be 520 needed also for Mobile IPv6 nodes, but it is unclear how this 521 context transfer should be triggered and performed. 523 Solutions at the system level may be possible: for example, in the 524 attach procedure to cellular networks, the mobile node usually 525 exchanges a lot of information with the network about its 526 capabilities and the support of Mobile IPv6 may be one of this 527 information. However, even in this case, the issues mentioned above 528 apply. 530 Based on the considerations in this section, there is therefore a 531 clear need to define some mechanisms in order to manage the co- 532 existence of nodes that use Mobile IPv6 and nodes that rely on Proxy 533 Mobile IPv6. 535 4.3. Scenario C - Movements between PMIPv6-enable and non PMIPv6- 536 enabled access networks 538 In this scenario the MN moves from one access network that supports 539 Proxy MIPv6 to an access network that does not support PMIPv6. 540 Therefore the mobility of the MN may be handled using Proxy MIPv6 in 541 some access network, but must be also managed by Mobile IPv6 if the 542 MN attaches to an access network that does not have any PMIPv6 543 functionality. 545 Two different sub-cases can be identified in this scenario: 547 o PMIPv6 is used to handle local mobility and the MN is moving from 548 an access network that supports PMIPv6 to an access network that 549 does not support PMIPv6, but the LMA is not co-located with the 550 HA. This means that Proxy Mobile IPv6 handles the Care-of Address 551 of the MN, and that Mobile IPv6 is always used by the MN, either 552 the MN is in an access network that supports Mobile IPv6 or it is 553 in an access network with no PMIPv6 support. This scenario is, as 554 shown in the following figure, very similar to Scenario A and 555 therefore does not imply any specific issue. 557 +----+ 558 | HA | HoA -> CoA_1 559 +----+ 561 CoA_1 (prefix) -> MAG_2 | 562 +------+ . 563 | LMA1 | | 564 +------+ . 565 | 566 | 567 +------+ +------+ . +----+ 568 | MAG1 | | MAG2 | | | AR | 569 +------+ +------+ . +----+ 570 ^ | 571 | | 572 v . 573 +----+ | 574 | MN | . 575 +----+ | 576 HoA & CoA_1 . 577 . 578 PMIPv6 Domain | 580 (a) 582 +----+ 583 | HA | HoA -> CoA_2 584 +----+ 586 | 587 +------+ . 588 | LMA1 | | 589 +------+ . 590 | 591 | 592 +------+ +------+ . +----+ 593 | MAG1 | | MAG2 | | | AR | 594 +------+ +------+ . +----+ 595 | ^ 596 | | 597 . v 598 | +----+ 599 . | MN | 600 | +----+ 601 . HoA & CoA_2 602 | 603 . 604 PMIPv6 Domain | 606 (b) 608 Figure 8 - Mobility between a PMIPv6 domain and a non-PMIPv6 domain 610 o the home subnet is a PMIPv6 domain and the MN moves from its home 611 subnet to a different link. This is the scenario where the LMA is 612 managing the same address managed by the HA; note that in this 613 case PMIPv6 manages the Mobile IPv6 HoA. The following figure 614 illustrates this scenario. 616 +--------+ 617 | HA/LMA | HoA (Home Prefix) -> MAG_1 618 +--------+ 620 | 621 +------+ . +----+ 622 | MAG1 | | | AR | 623 +------+ . +----+ 624 ^ | 625 | | 626 v . 627 +----+ | 628 | MN | . 629 +----+ | 630 HoA . 631 | 632 PMIPv6 Domain 633 (emulated 634 home link) 635 (a) 637 +--------+ 638 | HA/LMA | HoA -> CoA_1 639 +--------+ 641 | 642 +------+ . +----+ 643 | MAG1 | | | AR | 644 +------+ . +----+ 645 | ^ 646 | | 647 . v 648 | +----+ 649 . | MN | 650 | +----+ 651 . HoA & CoA_1 652 | 653 PMIPv6 Domain 654 (emulated 655 home link) 656 (b) 658 Figure 9 - Mobility between a PMIPv6 domain and a non-PMIPv6 domain 660 The scenario described in Figure 8 (a and b) is very similar to the 661 scenario A. This is because PMIPv6 is used to manage the CoA and has 662 no visibility of the HoA. Note that this applies also if LMA and HA 663 are co-located in the same box, as long as PMIPv6 is used only to 664 manage the Care-of Address mobility. For this reason, in the rest of 665 this sub-section we will concentrate on the scenario in Figure 9a and 666 9b. 668 In Figure 9a, the mobility of the MN is managed by the network 669 through Proxy Mobile IPv6: the node acting as LMA has a proxy binding 670 cache entry with the tuple (Home Prefix, MAG_1, MN_ID). The Mobile 671 Node is "at home" from a Mobile IPv6 perspective and therefore uses 672 directly its Home Address for new and existing communications. In 673 case the MN moves within the PMIPv6 domain, PMIPv6 is triggered, a 674 new MAG registers the home prefix of the MN at the LMA and the MN's 675 home prefix is advertised to the MN so that the HoA can still be 676 considered valid. Note that this implies that the PMIPv6 domain 677 coincides with the home network from a MIPv6 perspective: while the 678 MN is roaming in the PMIPv6 domain, the MN can use the Home Address 679 to exchange packets without any need of tunneling. Downlink packets 680 are tunneled to the MAG, but tunnel over the wireless link is avoided 681 in this way. 683 In Figure 9b, the MN has moved to an access network that does not 684 have any support for Proxy Mobile IPv6. In this case the MN receives 685 a Router Advertisement message containing a different IPv6 prefix 686 than its home prefix and therefore it detects a movement at the IP- 687 layer level. Based on that, the MN configures a new CoA and sends a 688 Binding Update to the HA (i.e. the LMA) with the couple (HoA, CoA). 690 Several possible issues are present in this scenario (direction of 691 movement from the PMIPv6 domain to the non-PMIPv6 access network): 693 o HoA management and lookup key in the binding cache 695 * in MIPv6 [RFC3775] the lookup key in the Binding Cache is the 696 Home Address of the MN. In particular, based on the base 697 specification [RFC3775], the MN does not include any 698 identifier, such as the MN-ID [RFC4283], in the Binding Update 699 message other than its Home Address. 701 * as specified in draft-netlmm-pmip6 [], a Proxy Binding Update 702 contains the Home Prefix of the MN, the MN-ID and may not 703 include the Home Address of the MN (since it may not be known 704 by the MAG and consequently by the HA/LMA). The lookup key in 705 the binding cache of the LMA is either the home prefix or the 706 MN-ID. 708 * this implies that lookup keys for MIPv6 and PMIPv6 709 registrations are different. Because of that, when the MN 710 moves from its home network (i.e. from the PMIPv6 domain) to 711 the foreign link, the Binding Update sent by the MN is not 712 identified by the HA as an update of the Proxy Binding Cache 713 Entry containing the home prefix of the MN, but a new binding 714 cache entry is created. 716 * based on above bullets, there is an "unused" (proxy) binding 717 cache entry in the Binding Cache of the LMA/HA. Note that, if 718 HA runs a longest-prefix-matching algorithm in order to tunnel 719 downlink packets to the MN, packets destined to the HoA are 720 anyway delivered correctly. 722 o Sequence Numbers and Timestamps 724 * in MIPv6 Sequence Numbers are used for message identification 725 and replay protection. In the latest PMIPv6 draft [], 726 timestamps are used instead since the new MAG may not know the 727 Sequence Number used in the last PBU. 729 * this implies that there are two different mechanisms for packet 730 identification and replay protection; in the case of Figure 9b, 731 the HA will receive a Binding Update from the MN that will 732 modify a proxy binding cache entry that is identified by the 733 timestamp. 735 * a specification of how the HA/LMA behaves in this case and how 736 it processes BUs/PBUs with different identification mechanisms 737 seem needed. 739 o Threat of compromised MAG 741 * in MIPv6 base specification [RFC3775] there is a strong binding 742 between the Home Address registered by the MN and the Security 743 Association used to modify the corresponding binding cache 744 entry. 746 * in PMIPv6 specification different Security Associations are 747 used to update the same entry related to a MN since a per-MAG 748 Security Association model is adopted. 750 * in this mixed scenario, both host-based and network-based 751 security associations are used to update the same binding cache 752 entry at the HA/LMA (but see the first bullet of this list, as 753 the entry may not be the same). 755 * based on this consideration, a compromised MAG can send a bogus 756 Proxy BU to the HA/LMA even when the Mobile Node is not in the 757 PMIPv6 domain, since the MAG is in the MIPv6 "home" domain. 758 This introduces third part traffic stealing and reflection 759 attacks, effectively bypassing MIPv6 security. Those two 760 attacks are not acceptable on the Internet and are avoided in 761 MIPv6. 763 * note that the same issue applies in a simple PMIPv6 scenario; 764 however, in the mixed scenario described in Figure 8, this is 765 not possible, since the MAG is managing only the CoA of the MN 766 and not the HoA. Therefore, if PMIPv6 is used to handle the 767 HoA mobility, the security of Mobile IPv6 is lowered to the 768 PMIPv6 security. This is not true if PMIPv6 is used together 769 with MIPv6 but only to handle the CoA. 771 In case the MN is returning home (i.e.moving into the PMIPv6 domain), 772 several other considerations apply: 774 o HoA management and lookup key in the binding cache 776 * in MIPv6 [RFC3775], de-registration is recommended (but not 777 mandatory). This implies that the MN receives a Router 778 Advertisement with the home prefix, starts using its HoA 779 directly, without tunneling uplink packets but may not send a 780 Binding Update to remove the binding cache entry related to the 781 HoA. 783 * based on the same considerations made in the previous case, the 784 PBU sent by the MAG will not update the Binding Cache entry 785 related to the HoA, but more probably will create a new proxy 786 binding cache entry including the home prefix of the MN, the 787 MN-ID and the MAG address. 789 * this implies that, in case the MN does not send a de- 790 registration binding update when returning home, the downlink 791 packets may still be tunneled to the CoA and not to the MAG. 793 o Race condition in the registration from MAG and de-registration of 794 the MN 796 * even though the MN sends a de-registration Binding Update, for 797 example including a MN-ID in order that PBUs and BUs update the 798 same binding cache entry (note however that this is not 799 possible based on [RFC3775]), a race condition may happen if 800 the de-registration BU sent from the MN is received by the HA 801 after the PBU sent by the MAG. In this case the BU from the MN 802 will delete the entry created/updated by the MAG and therefore 803 downlink packets will not be correctly routed to the MN. 805 o Sequence Numbers and Timestamps 807 * the same considerations done for the handover from the PMIPv6 808 domain to the non-PMIPv6 access network applies also in this 809 direction. 811 As a general issue, this scenario contradicts with the scope of 812 PMIPV6. The NETLMM WG is chartered to produce a protocol to handle 813 network-based local mobility management. In the context of MIPv6, 814 the main distinction between a local mobility management protocol and 815 a global one is that former manages the changes in a CoA within a 816 local domain and the latter manages the changes in the CoA globally. 817 While the protocol itself may allow both types of mobility management 818 with minimal change, there is a significant difference in terms of 819 the security requirements, stability of an address and the relevant 820 policies associated with such identifier. A change in the context of 821 the protocol would result in subtle violations of these issues, which 822 can introduce significant security issues that do not exist in MIPv6. 824 5. Conclusion 826 The analysis provided in this document shows that PMIPv6 can be used 827 for local mobility management when MIPv6 is used to handle global 828 mobility. No significant issues have been identified for such a 829 scenario. Note that this is the main scenario the NETLMM WG was 830 chartered for rfc4830. 832 Some issues have been identified in the two other scenarios 833 considered. Concerning scenario B (contemporary co-existence of 834 MIPv6 and non-MIPv6 nodes), a method to allow MIPv6 nodes to use 835 host-based mobility is needed: this implies that within a PMIPv6 836 domain the MAG must be able to emulate the home network for some 837 nodes and advertise link-specific prefixes for other nodes. 839 Concerning scenario C, several issues have been identified, related 840 to possible race conditions, the way the binding cache entries are 841 identified at the HA and security threats. It seems that the 842 implementation of this scenario requires some additional capabilities 843 from the MN, that cannot implement only MIPv6 base specification 844 [RFC3775]. 846 6. IANA Considerations 848 This document makes no request of IANA. 850 7. Security Considerations 852 The co-existence between PMIPv6 and MIPv6 is possible in some 853 scenarios. Essentially, such co-existence is seamless when PMIPv6 is 854 restricted to the mobility management of the CoA. However, the use 855 of PMIPv6 for managing the home address introduces a number of 856 security issues. 858 Mobile IPv6 assumes a particular trust relationship between the MN 859 and the HoA. For instance, a MN does not do a CoA test when 860 registering its home address. The assumption here is that the HoA 861 can trace a MN if it's reported as "misbehaving" (e.g. if it floods 862 other nodes by registering a fake CoA). The same assumption is not 863 necessarily true for every local HA/MAP/LMA that a mobile node 864 happens to be associated with. Therefore, if an LMA is passed the 865 MN's HoA to emulate a home link for a roaming node, there is a subtle 866 violation of the security assumptions. 868 A more significant violation of security policy can occur if a MAG is 869 compromised while managing the mobility of the home address. A 870 compromised MAG can launch off-path attacks to steal or redirect the 871 mobile node's traffic. This situation is not possible in MIPv6 872 unless an attacker can break the IPsec SA between the MN and the HA, 873 which is an unlikely scenario. 875 Hence, changing the end points for the signalling, while almost 876 seamless to the actual protocol, can cause significant unintended 877 consequences. For this reason, and others, it is strongly 878 recommended that PMIPv6 is only used to manage a local address and 879 limit any potential attacks to the scope of the local domain. 881 8. Acknowledgements 883 The authors would like to thank Vidya Narayanan, Patrick Stupar and 884 Stefano Faccin for their valuable comments. 886 9. References 888 9.1. Normative References 890 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 891 Requirement Levels", BCP 14, RFC 2119, March 1997. 893 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 894 in IPv6", RFC 3775, June 2004. 896 [RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 897 Protect Mobile IPv6 Signaling Between Mobile Nodes and 898 Home Agents", RFC 3776, June 2004. 900 9.2. Informative References 902 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 903 RFC 3753, June 2004. 905 [RFC4140] Soliman, H., Castelluccia, C., El Malki, K., and L. 906 Bellier, "Hierarchical Mobile IPv6 Mobility Management 907 (HMIPv6)", RFC 4140, August 2005. 909 [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 910 Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 911 (MIPv6)", RFC 4283, November 2005. 913 [RFC4285] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 914 Chowdhury, "Authentication Protocol for Mobile IPv6", 915 RFC 4285, January 2006. 917 Authors' Addresses 919 Hesham Soliman 920 Elevate Technologies 922 Email: Hesham@elevatemobile.com 924 Gerardo Giaretta (editor) 926 Email: gerardo.giaretta@gmail.com 928 Full Copyright Statement 930 Copyright (C) The IETF Trust (2007). 932 This document is subject to the rights, licenses and restrictions 933 contained in BCP 78, and except as set forth therein, the authors 934 retain all their rights. 936 This document and the information contained herein are provided on an 937 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 938 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 939 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 940 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 941 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 942 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 944 Intellectual Property 946 The IETF takes no position regarding the validity or scope of any 947 Intellectual Property Rights or other rights that might be claimed to 948 pertain to the implementation or use of the technology described in 949 this document or the extent to which any license under such rights 950 might or might not be available; nor does it represent that it has 951 made any independent effort to identify any such rights. Information 952 on the procedures with respect to rights in RFC documents can be 953 found in BCP 78 and BCP 79. 955 Copies of IPR disclosures made to the IETF Secretariat and any 956 assurances of licenses to be made available, or the result of an 957 attempt made to obtain a general license or permission for the use of 958 such proprietary rights by implementers or users of this 959 specification can be obtained from the IETF on-line IPR repository at 960 http://www.ietf.org/ipr. 962 The IETF invites any interested party to bring to its attention any 963 copyrights, patents or patent applications, or other proprietary 964 rights that may cover technology that may be required to implement 965 this standard. Please address the information to the IETF at 966 ietf-ipr@ietf.org. 968 Acknowledgment 970 Funding for the RFC Editor function is provided by the IETF 971 Administrative Support Activity (IASA).