idnits 2.17.00 (12 Aug 2021) /tmp/idnits2159/draft-velev-netlmm-mip-pmip-ro-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 635. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 646. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 653. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 659. 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.) ** The abstract seems to contain references ([ID-MIP-PMIP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (February 25, 2008) is 5199 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'MN' is mentioned on line 358, but not defined == Missing Reference: 'CN' is mentioned on line 358, but not defined == Missing Reference: 'MN1' is mentioned on line 414, but not defined == Missing Reference: 'MN2' is mentioned on line 415, but not defined == Unused Reference: 'RFC3776' is defined on line 569, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETLMM Working Group G. Velev 3 Internet-Draft K. Weniger 4 Intended status: Informational Panasonic 5 Expires: August 28, 2008 February 25, 2008 7 Interactions between PMIPv6 and MIPv6: Route Optimization Issues 8 draft-velev-netlmm-mip-pmip-ro-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 August 28, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 The interactions scenarios between Proxy Mobile IPv6 (PMIPv6) and 42 Mobile IPv6 (MIPv6) protocols are described in [ID-MIP-PMIP]. This 43 document analyzes these scenarios when route optimization is used. 44 The analysis results in the identification of possible issues that 45 should be considered in the design of extensions for Route 46 Optimization in PMIPv6. 48 Requirements Language 50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 51 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 52 document are to be interpreted as described in RFC 2119 [RFC2119]. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Overview of route optimization . . . . . . . . . . . . . . . . 3 59 3.1. Route optimization in MIPv6 . . . . . . . . . . . . . . . 3 60 3.2. Route optimization in PMIPv6 . . . . . . . . . . . . . . . 4 61 4. Analysis of the scenarios and possible issues . . . . . . . . 5 62 4.1. Proxy RO in scenario A . . . . . . . . . . . . . . . . . . 5 63 4.2. Proxy RO in scenario B . . . . . . . . . . . . . . . . . . 7 64 4.3. Proxy RO in scenario C . . . . . . . . . . . . . . . . . . 10 65 4.3.1. MN2 performs MN role . . . . . . . . . . . . . . . . . 10 66 4.3.2. MN2 performs CN role . . . . . . . . . . . . . . . . . 11 67 5. Summary of the issues . . . . . . . . . . . . . . . . . . . . 12 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 71 7.2. Informative References . . . . . . . . . . . . . . . . . . 14 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 73 Intellectual Property and Copyright Statements . . . . . . . . . . 15 75 1. Introduction 77 The NETLMM WG is standardizing Proxy Mobile IPv6 (PMIPv6) as the 78 protocol for network-based localized mobility management. The MIPv6- 79 PMIPv6 interactions document [ID-MIP-PMIP] captures the issues with 80 the inter-working between host-based (MIPv6) and network-based 81 (PMIPv6) mobility and identifies three main scenarios. However, the 82 document does not consider the cases when a route optimized path is 83 set up. 85 In PMIPv6 the mobile access gateway (MAG) manages the mobility- 86 related registrations with the local mobility agent (LMA) on behalf 87 of the mobile nodes (MNs) attached to it. According to the base 88 PMIPv6 specification [ID-PMIPv6] all data packets are bi- 89 directionally tunneled between MAG and LMA. In some scenarios, e.g. 90 if the communicating end nodes are located in the same PMIPv6 domain, 91 it is advantageous to route the packets directly between the MAGs to 92 which the nodes are attached. The PMIPv6 base spec does not support 93 route optimization (RO) between different MAGs, however, there are 94 individual proposals (see Section 3.2) for establishing such a route 95 optimized path. In these proposals the MNs are unaware about the 96 proxy RO set up in PMIPv6 domain between the MAGs. On the other 97 hand, in MIPv6 the MN itself performs the route optimization with a 98 CN. 100 This document provides an analysis of the scenarios and possible 101 issues when the PMIPv6 and MIPv6 route optimization procedures 102 interact. 104 2. Terminology 106 General mobility terminology can be found in [RFC3753]. Further, 107 PMIPv6-related terminology used in this document is defined in 108 [ID-PMIPv6] 110 3. Overview of route optimization 112 This section provides an overview of the route optimization 113 procedures specified for MIPv6 and the general characteristics of a 114 potential to-be-standardized route optimization procedure for PMIPv6. 116 3.1. Route optimization in MIPv6 118 MIPv6 protocol comes with a route optimization scheme that enables a 119 direct communication between MN and CN, i.e. the data packets are 120 bypassing the Home Agent. Route optimization requires the mobile 121 node to register its current binding of home address (HoA) to care- 122 of-address (CoA) at the correspondent node. The CN establishes a 123 binding cache entry and packets from the CN can be routed directly to 124 the CoA of the MN. 126 MPv6 specification [RFC3775] defines the return routability (RR) 127 procedure that authorizes the BU sent by the MN by the use of a 128 cryptographic token exchange (keygen tokens). The binding update is 129 signed by binding management key (Kbm) that is generated based on the 130 keygen tokens obtained from CN separately for the home address and 131 care-of-address. The detailed RR and RO procedures are described in 132 sections 5.2, 6.1, 9.4 and 9.5 in [RFC3775]. 134 3.2. Route optimization in PMIPv6 136 Route optimization in PMIPv6 (proxy RO) is not in the charter of the 137 NetLMM working group and is not specified in the PMIPv6 base 138 specification [ID-PMIPv6]. However, [ID-PMIPv6] describes one case 139 where the local routing at the MAG is possible. The local routing is 140 applied when the two communicating mobile nodes are attached to the 141 same MAG and the MAG's policy in coordination with LMA allows such 142 routing. In all other attachment constellations the PMIPv6 protocol 143 mandates reverse tunneling of data packets to the LMA. 145 However, interest in the area of PMIPv6 RO (henceforth called proxy 146 RO) exists from various working group members and individual 147 solutions are already available. In the following, the general 148 characteristics of possible PMIPv6 RO mechanisms are analyzed. 149 Subsequently, some individual submissions are briefly presented as 150 example solutions. 152 In general, the proxy RO can be categorized in the following cases: 154 1. Between the MN and the CN's MAG. In this case the RO is 155 initiated by the MN and the MAG is the endpoint of the route 156 optimized path. For instance, if MIPv6 RO is used, CN's MAG 157 performs the role of MIPv6 CN with respect to RO. 159 2. Between the MN's MAG and the CN. In this case the MN's MAG 160 initiates the RO with CN on behalf of the MN and the endpoint of 161 the route optimized path is MN's MAG instead of MN. For 162 instance, if MIPv6 RO is used the MAG performs the role of MIPv6 163 MN with respect to RO. 165 3. Between MAGs. In this case the MAG, to which the MN is attached, 166 initiates RO with the CN's MAG and a route optimized path between 167 both MAGs is established. For instance, if MIPv6 RO is used, the 168 MN's MAG performs the role of MIPv6 MN with respect to RO and the 169 MAG, to which the CN is attached, performs the role of MIPv6 CN. 171 Each of the above cases is analyzed in different MIPv6-PMIPv6 172 interaction scenarios in Section 4. 174 The document [PMIPv6-RO-RR] describes the applicability of Enhanced 175 Route Optimization for Mobile IPv6 specified in [RFC4866] for PMIPv6, 176 i.e. how cryptographically generated addresses (CGA) and the 177 corresponding optimized RO signalling (compared to [RFC3775]) are 178 used. The authors describe a proxy Return Routability (RR) procedure 179 performed by the MAG on behalf of the MN. The document addresses 180 cases 2 and 3 from above. 182 Another individual approach for RO in PMIPv6 is described in 183 [PMIPv6-RO-ROA]. In this approach, the exchange of RO setup messages 184 (similar to binding updates messages) between the MAGs is performed 185 either a) via the LMAs, to which the MAGs are attached, or b) 186 directly between the MAGs. In the latter case, a route optimization 187 association (ROA) between the MAGs is needed. The document addresses 188 the case 3 (i.e. MAG-MAG RO) from above. 190 A further individual solution is described in [PMIPv6-RO-IPv4] that 191 presents a more general approach and considers a combination of both 192 individual solutions presented in the previous paragraphs: either 193 performing a proxy RR between MAGs or having a Security Association 194 between MAGs for direct exchange of binding updates. 196 In general, if a mobile node attached to a MAG in PMIPv6 domain moves 197 to a new MAG, the old MAG, the new MAG and the LMA should manage the 198 transition of the RO-related state from the old to the new MAG. 199 Further the new MAG shall update the BCE in the correspondent node. 200 These procedures are outside of the scope of this document because it 201 is not specific to MIPv6-PMIPv6 interactions and should be defined in 202 a potential to-be-standardized PMIPv6 RO procedure. 204 4. Analysis of the scenarios and possible issues 206 The categorization of the MIPv6-PMIPv6 interactions with respect to 207 RO is based on scenarios A, B and C described in [ID-MIP-PMIP] in 208 order to achieve compliance between both documents. For each of the 209 scenarios the cases from Section 3.2 are applied and the resulting 210 issues are identified. 212 4.1. Proxy RO in scenario A 214 In scenario A, PMIPv6 is used as a network-based local mobility 215 management protocol within one access network, whereas MIPv6 is used 216 as a global mobility management protocol. Furthermore, HA and LMA 217 are not co-located. 219 In this scenario the MN uses MIPv6 and registers the IP address 220 obtained in the PMIPv6 domain as CoA at the HA. A bi-directional 221 tunnel is set up between the MN and HA. An additional PMIPv6 tunnel 222 is in use between MAG1 and LMA1. Figure 1 illustrates the 223 hierarchical application of MIPv6 and PMIPv6 protocols in scenario A. 224 The CN relies on the PMIPv6 for mobility management, it is attached 225 to MAG2 and anchored at LMA1, where the MN is anchored too. 227 +----+ 228 | HA | 229 +----+ 230 //\ 231 // \ 232 +------------//----\-------------+ 233 ( // \ ) Global Mobile IPv6 234 ( // \ ) Domain 235 +---------//----------\----------+ 236 // \ 237 +------+ +----+ 238 | LMA1 | |LMA2| 239 +------+ +----+ 240 ////\\ \\ 241 +----////--\\----+ +----\\------+ 242 ( //// \\ ) ( \\ ) Local Mobility Network 243 ( //// \\ ) ( \\ ) PMIPv6 domain 244 +-////--------\\-+ +-------\\---+ 245 //// \\ \\ 246 //// \\ \\ 247 //// \\ \\ 248 +----+ +----+ +----+ 249 |MAG1| |MAG2| |MAG3| 250 +----+ +----+ +----+ 251 || | | 252 [MN] [CN] 254 Figure 1 - Scenario A 256 As MIPv6 bidirectional tunnel is set up between MN and HA, the PMIP 257 entities (MAG1 and LMA1) cannot learn the address of the CN, and 258 thus, cannot perform any actions with respect to proxy RO. Even if 259 the CN is attached to the same or neighbour MAG, to which MN is 260 attached, PMIP entities are unable to discover such a situation 261 assuming that there is no explicit information between MN's HA and 262 LMA. Therefore, proxy RO initiated by MN's MAG to the CN, i.e. case 263 2 from Section 3.2, is not possible. The MAG would rather see the HA 264 as CN and establish an optimized route to the HA, which is of course 265 not desired. Proxy RO between MAG1 and MAG2 (case 3) has the same 266 problem as case 2: since a MIPv6 tunnel is set up between MN and HA, 267 MAG1 cannot discover CN's address and initiate proxy RO. 269 In contrary to cases 2 and 3, proxy RO tunnel between MN and MAG2 270 (case 1) is possible. MN initiates a MIPv6 RO with the CN and the 271 MAG2 is configured to act as proxy CN on behalf CN. The resulting 272 path in both directions (i.e. MN->CN and CN->MN) would be MN-MAG1- 273 LMA1-MAG2-CN. Such a situation is comparable to usual PMIPv6 274 routing, although MIPv6 RO IP header options are present in the data 275 packets (Routing Header Type 2 and Home Address destination option). 276 This situation reveals CN address to MAG1 and hence gives opportunity 277 for a proxy RO tunnel set up between MAG1 and MAG2. A potential to- 278 be-standardized PMIPv6 RO procedure shall consider the handling of 279 such a situation, where already MIPv6 RO is running between MN and CN 280 (or CN's MAG, i.e. MAG2). In summary, proxy PMIPv6 RO from MAG1 to 281 CN or from MAG1 to MAG2 in scenario A cannot be initiated unless MN 282 performs MIPv6 RO with CN (unless there are other means of informing 283 MAG1 of the CN address). 285 Another proxy RO constellation is possbile, in which the MAG2 286 initiates proxy RO with the MN on behalf of the CN. After such a 287 route optimized path is set up, the data packets would continue to 288 flow via the HA, i.e. the path would the same as before the proxy RO. 289 The MAG2 however cannot recognize such a constellation. Therefore it 290 is advantageous if MAG2 does not initiate proxy RO with MN. 292 Figure 1 shows a case where the CN is using only a PMIPv6 service. 293 However, a situation is possible, in which the CN (analogically to 294 MN) is also using PMIPv6 for local mobility and MIPv6 for global 295 mobility. In such a situation both end nodes (MN and CN) must 296 perform MIPv6 procedure in order to utilize a proxy RO tunnel between 297 the MAGs. The proxy RO tunnel between the MAGs can be set up before 298 the MIPv6 RO procedures are completed, however, the MAGs must know 299 the care-of-address of the corresponding node and the respective MAG 300 they are attached to. After the PMIPv6 RO is completed, the MAGs 301 create a routing state pointing the CoA of the correspondent node to 302 its respective MAG. The MAGs start to forward packets over the proxy 303 RO tunnel as soon as the end nodes start to use the CoA of the 304 correspondent node. 306 4.2. Proxy RO in scenario B 308 In scenario B some MNs use MIPv6 to manage their movements while 309 others rely on a PMIPv6 protocol provided by the network. The 310 configuration of the MAG for supporting such scenario is described in 312 [ID-MIP-PMIP] Section 6.14. [ID-MIP-PMIP] assumes that the mobility 313 anchor for MIPv6 and PMIPv6 is the same entity implementing the 314 functions of both HA and LMA (below denoted as HA/LMA). For a MN, to 315 which PMIPv6 service is offered, the HA/LMA is acting as LMA and for 316 a MN, to which MIPv6 service is offered, the HA/LMA is acting as HA. 318 Figure 2 illustrates scenario B where a MN uses MIPv6 and a CN relies 319 on PMIPv6 for mobility management. The MN utilizes MIPv6 tunnel to 320 the HA/LMA via AR whereas a PMIPv6 tunnel is set up for CN between 321 MAG2 and HA/LMA. 323 +------+ 324 |HA/LMA| 325 +------+ 326 //\\ 327 +- ---//--\\----+ 328 ( // \\ ) Mixed MIPv6 and 329 ( // \\ ) PMIPv6 mobility domain 330 +--//--------\\-+ 331 // \\ 332 // \\ 333 +----+ +----+ 334 | AR | |MAG2| 335 +----+ +----+ 336 || | 337 [MN] [CN] 339 Figure 2 - Scenario B with colocated HA and LMA 341 An additional case is possible in scenario B, where MN's HA and CN's 342 LMA are not colocated, however, they are in the same PMIPv6 mobiltiy 343 domain. Such a case is depicted on Figure 3. 345 +----+ +-----+ 346 | HA | | LMA | 347 +----+ +-----+ 348 || || 349 +--||---------- ||--+ 350 ( || || ) Mixed MIPv6 and 351 ( || || ) PMIPv6 mobility domain 352 +--||-----------||--+ 353 || || 354 +----+ +----+ 355 | AR | |MAG2| 356 +----+ +----+ 357 || | 358 [MN] [CN] 360 Figure 3 - Scenario B with separated HA and LMA 362 First, the analyses focuses on the proxy RO from MN side. For the 363 constellations in Figure 2 and Figure 3, proxy RO is possible only 364 between MN and MAG2 (case 1). The proxy RO cases 2 and 3 from 365 Section 3.2 are not possible because MN is attached to an AR. If the 366 MN initiates a MIPv6 RO with CN, MAG2 may respond as proxy on behalf 367 of the CN, which results in case 1. The RO path is set up between MN 368 and MAG2, which is the optimal route from MN to CN. Additionally, 369 MAG2 may initiate proxy RO with the MN in order to achieve route 370 optimized path in direction from CN to MN. If the RO is performed in 371 both directions, no further optimizations are needed. 373 Second, the analyses focuses on the proxy RO from CN side. This is 374 the case if MAG2 initiates proxy RO with MN. In Figure 2, the 375 resulting route optimized path would be via the MN's HA/LMA, because 376 MAG2 does not know MN's CoA. The proxy RO in such a case does not 377 lead to any path optimization and hence it is beneficial if MAG1 does 378 not initiate proxy RO with MN. In Figure 3, the resulting route 379 optimized path would be from MAG2 directly to MN's HA. In such a 380 case the proxy RO would have a small benefit, as the data path 381 doesn't run over LMA. 383 In summary, to achieve the optimal RO path in scenario B between MN 384 using MIPv6 and CN relying on PMIPv6 service in the same network 385 domain, the MN should initiate MIPv6 RO and additionally a proxy RO 386 between MN and MAG should be performed. The network can assist the 387 MN to initiate MIPv6 RO, as the network entities (most probably LMA) 388 can discover such constellation. 390 4.3. Proxy RO in scenario C 392 In scenario C a MIPv6-capable MN moves between access networks using 393 different mobility management schemes, i.e. some access networks 394 support PMIPv6 and others do not. This results in transition between 395 PMIPv6 and MIPv6 mobility management for the particular MN and 396 requires that LMA and HA functions are located in the same physical 397 entity. Scenario C is depicted in Figure 4. 399 +------+ 400 |HA/LMA|-----------------------+ 401 +------+ | 402 //\\ | 403 +-------//--\\--------+ | 404 ( // \\ PMIPv6 ) | 405 ( // \\ domain) +--------------+ 406 +----//--------\\-----+ ( Non-PMIPv6 ) 407 // \\ ( domain ) 408 // \\ +--------------+ 409 // \\ | 410 +----+ +----+ +----+ 411 |MAG1| |MAG2| | AR | 412 +----+ +----+ +----+ 413 | | | 414 [MN1] [MN2] ------> (a) | 415 (b) <------ [MN2] 417 Figure 4 - Scenario C 419 4.3.1. MN2 performs MN role 421 In order to anlyze the issues with RO in scenario C, first it is 422 assumed that MN2 has the role of MN and MN1 has the role of CN. 423 Further two transition scenarios are investigated denoted by the 424 arrows (a) and (b) in Figure 4. In transition (a) the MN2 moves from 425 MAG2 of PMIPv6 domain to an AR of non-PMIPv6 domain, whereas in 426 transition (b) the MN2 moves from AR to MAG2. At first, transition 427 (a) is analyzed. If a MN2 is attached to MAG2 and MN1 is attached to 428 MAG1, a proxy RO path can be set up according to cases 2 (MAG2->MN1) 429 and case 3 (MAG2->MAG1) from Section 3.2. Cases 1 (MN2->MAG1) is not 430 possible because the assumption is that MN2 is at the home link 431 supporting PMIPv6 service, i.e. the MN2 does not have a CoA to 432 register with the CN. In the following analysis, cases 2 and 3 are 433 investigated together because the only difference is which entity 434 (MN1 or MAG1) performs the CN role regarding RO functionality. 435 Therefore, below CN is indicated as MN1/MAG1. 437 If the MN2 moves outside the PMIP domain to an AR of a MIPv6 domain, 438 the MN2 performs MIPv6 registration with the HA/LMA. Since the MN2 439 is not aware about the proxy RO before the handover, it does not 440 necessarily initiate registration of its CoA to MN1/MAG1. It depends 441 on the MN2's MIPv6 implementation whether MIPv6 RO is performed. 442 Furthermore, there would be some delay till the MIPv6 RO path is 443 setup after the handover. The steps performed by the MAG2, after 444 detection of MN2 detachment, depend on a potential PMIPv6 RO 445 specification. If the MAG2 does not deregister the MN2 with the MN1/ 446 MAG1, MN1/MAG1 continues to send packets to MAG2 and this could lead 447 to packet loss. Therefore a potential PMIPv6 RO protocol shall take 448 care of this situation. On the other hand, if a mechanism is 449 available in MAG2 to deregister MN2 with MN1/MAG1, then the proxy RO 450 path is terminated and data packets are routed via HA/LMA. The 451 change of route optimized to non-optimized path would result in 452 increased end-to-end delay and possibly to data packets lost due to 453 transport layer time out. To avoid this situation, a future protocol 454 mechanism should allow to keep the RO path between the MN2 and MN1 455 after the MN2 moves out of the PMIPv6 domain. 457 The transition (b) from Figure 4 is observed hereby, where the MN2 is 458 first attached to a MIPv6 domain and later moves to the home link 459 that supports PMIPv6 service (home PMIPv6 domain). Case 1 460 (MN2->MAG1) from Section 3.2 is the only possible way of performing 461 proxy RO before the handover. While attached to the MIPv6 domain, a 462 proxy RO path between MN2 and MAG1 is set up, i.e. MN2 creates BCE 463 in MAG1. When the MN2 moves to the home PMIPv6 domain, it performs 464 the returning home procedure described in [RFC3775], i.e. sends 465 deregistration BU messages to HA and all CNs, to which a MIPv6 RO has 466 been set up. Thus, the MN2 deletes the BCE in MAG1 and MAG1 sends 467 data packets to MN2's HoA, i.e. to HA/LMA. Such a scenario does not 468 result in data packet loss, however, the MN-CN path after the 469 handover is not optimized. 471 In conclusion, the MN2's transition between PMIPv6 and MIPv6 mobility 472 schemes results in issues that should be considered by a future 473 protocol mechanisms. The transition from PMIPv6 to non-PMIPv6 domain 474 may result in packet loss or affect the transport layer application 475 due to increased end-to-end delay. 477 4.3.2. MN2 performs CN role 479 The MIPv6 RO procedure [RFC3775] specifies the functionality of a CN, 480 however, it does not consider mobile CN. In the following a mobile 481 CN performing PMIPv6-MIPv6 transition in scenario C is analyzed in 482 order to identify possible issues. In scenarios A and B the mobile 483 CN does not change the mobility management scheme and therefore such 484 an analysis is not needed. With respect to Figure 4, the assumption 485 now is that the MN's role is implemented in MN1 (respectively MAG1) 486 and CN's role - in MN2 (respectively MAG2). In transition (a) the 487 MN2 hands over from MAG2 to the AR. Before the handover, a proxy RO 488 tunnel exists between MAG1 and MAG2. MN2 sends data packets to MN1's 489 HoA, but the MAG2 tunnels the packets to MAG1. After the handover, 490 the MN2 performs MIPv6 registration with HA and continues to send the 491 data packets to MN1's HoA. The LMA forwards the data packets to the 492 MAG1 and they are delivered to MN1. However, in the oposit direction 493 (MN1->MN2) MAG1 would continue to keep the proxy RO path with MAG2, 494 although MN2 is no longer attached to MAG2, which would result in 495 packet loss. Such a situation should be considered by the potential 496 to-be-standardized proxy RO specification. 498 In transition (b), the MN2 hands over from AR to MAG2. Before the 499 handover, MN2 uses MIPv6 bi-directional tunneling to the home network 500 and a proxy RO tunnel has been set up between MAG1 and MN2. MN2 501 performs the role of CN, i.e. the proxy BCE in MN2 is created by 502 MAG1. Since in Figure 4 the MN2's HA is co-located with MN1's LMA, 503 the proxy RO tunnel does not bring any benefit for the data path. 504 The proxy RO tunnel would be beneficial in case that LMA and HA are 505 not co-located (similar to Figure 3). After the handover to MAG2, 506 the MN2 keeps the proxy BCE, and thus, sends the packets to MN1's CoA 507 (e.g. MAG1's IP address). The packets are encapsulated by MAG2 in a 508 PMIPv6 tunnel to LMA, an thus, the MN1-MN2 path results in an usual 509 non-optimized PMIP path. However, in the direction MN1->MN2 the 510 proxy RO state state in MAG1 is still active. MAG1 continues to 511 update the MN2's BCE because MAG1 does not learn about the MN2 512 movement. Such a situation is undesired and shall be handled by a 513 to-be-standardized proxy RO procedure. 515 To sum up the issues with mobile CN in scenario C, transition (a) may 516 lead to a situation in which the entity performing the MN's role 517 (MAG1) continues to perform proxy RO with the MAG2, although MN2 is 518 no longer attached to MAG2. Transition (b) results in the non- 519 optimal situation of tunneling data packets between MAG2 and LMA 520 although a BCE exists in MN2 for optimal route to MN1. 522 5. Summary of the issues 524 The analyses of the different scenarios of MIPv6-PMIPv6 interactions 525 with respect to RO shows a couple of issues that should be considered 526 during the design of to-be-standardized proxy RO procedure. This 527 section summarizes the main points of the above analyses: 529 o In scenarios where both end nodes are located in the same PMIP 530 domain and at least one of the end nodes uses MIPv6 for global 531 mobility (scenario A and B), MIPv6 RO procedure should be 532 performed in order to utilize a PMIPv6 RO tunnel. In some 533 constellations (scenario B, proxy RO tunnel MN-MAG2), the set up 534 of proxy RO tunnel does not lead to any improvement in the data 535 path unless the end node that uses MIPv6 does not perform MIPv6 536 RO. 538 o In scenarios where transition between MIPv6 and PMIPv6 occurs 539 (Scenario C), depending on the constellation, PMIP RO states must 540 be transfered (from MAG to MN or from MN to MAG) or updated when 541 the transition occurs. 543 o In some constellations (in scenario A) it may be advantageous for 544 MAGs to know the CoA of the corresponding end nodes in order to 545 set up a proxy RO tunnel in advance before the MIPv6 RO procedure 546 is completed. 548 6. Security Considerations 550 The current document analyzes scenarios and describes issues; it does 551 not present new protocol design. Therefore this document does not 552 introduce any security issues in addition to those described in 553 [ID-PMIPv6] or [RFC3775]. 555 7. References 557 7.1. Normative References 559 [ID-PMIPv6] 560 Gundavelli, S., Ed., "Proxy Mobile IPv6", February 2008, 561 . 563 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 564 Requirement Levels", BCP 14, RFC 2119, March 1997. 566 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 567 in IPv6", RFC 3775, June 2004. 569 [RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 570 Protect Mobile IPv6 Signaling Between Mobile Nodes and 571 Home Agents", RFC 3776, June 2004. 573 [RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route 574 Optimization for Mobile IPv6", May 2007. 576 7.2. Informative References 578 [ID-MIP-PMIP] 579 Giaretta, G., Ed., "Interactions between PMIPv6 and MIPv6: 580 scenarios and related issues", November 2007, 581 . 583 [PMIPv6-RO-IPv4] 584 Jeong, S. and R. Wakikawa, "Route Optimization for Proxy 585 Mobile IPv6", July 2007, 586 . 588 [PMIPv6-RO-ROA] 589 Liebsch, M. and A. Abeille, "Route Optimization for Proxy 590 Mobile IPv6", November 2007, 591 . 593 [PMIPv6-RO-RR] 594 Sarikaya, B., Qin, A., Huang, A., and W. Wu, "PMIPv6 Route 595 Optimization Protocol", November 2007, 596 . 598 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 599 RFC 3753, June 2004. 601 Authors' Addresses 603 Genadi Velev 604 Panasonic 605 Monzastr. 4c 606 Langen 63225 607 Gemany 609 Phone: 610 Email: genadi.velev@eu.panasonic.com 612 Kilian Weniger 613 Panasonic 614 Monzastr. 4c 615 Langen 63225 616 Gemany 618 Phone: 619 Email: kilian.weniger@eu.panasonic.com 621 Full Copyright Statement 623 Copyright (C) The IETF Trust (2008). 625 This document is subject to the rights, licenses and restrictions 626 contained in BCP 78, and except as set forth therein, the authors 627 retain all their rights. 629 This document and the information contained herein are provided on an 630 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 631 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 632 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 633 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 634 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 635 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 637 Intellectual Property 639 The IETF takes no position regarding the validity or scope of any 640 Intellectual Property Rights or other rights that might be claimed to 641 pertain to the implementation or use of the technology described in 642 this document or the extent to which any license under such rights 643 might or might not be available; nor does it represent that it has 644 made any independent effort to identify any such rights. Information 645 on the procedures with respect to rights in RFC documents can be 646 found in BCP 78 and BCP 79. 648 Copies of IPR disclosures made to the IETF Secretariat and any 649 assurances of licenses to be made available, or the result of an 650 attempt made to obtain a general license or permission for the use of 651 such proprietary rights by implementers or users of this 652 specification can be obtained from the IETF on-line IPR repository at 653 http://www.ietf.org/ipr. 655 The IETF invites any interested party to bring to its attention any 656 copyrights, patents or patent applications, or other proprietary 657 rights that may cover technology that may be required to implement 658 this standard. Please address the information to the IETF at 659 ietf-ipr@ietf.org. 661 Acknowledgment 663 Funding for the RFC Editor function is provided by the IETF 664 Administrative Support Activity (IASA).