idnits 2.17.1 draft-cui-netlmm-mip-interactions-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 3 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (November 23, 2009) is 5268 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'MN' is mentioned on line 177, but not defined == Unused Reference: '1' is defined on line 367, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 382, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3344 (ref. '3') (Obsoleted by RFC 5944) ** Obsolete normative reference: RFC 3775 (ref. '5') (Obsoleted by RFC 6275) Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NETLMM Working Group Y. Cui 2 Internet Draft Y. Liu 3 Intended status: Standards Track Y. Sun 4 Expires: DEC 2010 Tsinghua University 5 D. Liu 6 H. Deng 7 China Mobile 8 November 23, 2009 10 Interactions between PMIPv6 and DSMIPv6: a scenario while HA and LMA 11 are separate deployment 12 draft-cui-netlmm-mip-interactions-00.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on May 23, 2009. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 Home Agent and Local Mobility Anchor are separately deployed is one 50 scene of the interactions between Proxy Mobile IPv6 (PMIPv6) and Dual 51 stack Mobile IPv6 (DSMIPv6). In view of this scenario this document 52 proposes two detailed solutions for a mobile node which is roaming 53 between PMIPv6 and DSMIPv6. 55 Table of Contents 57 1. Introduction.....................................................3 58 2. Requirements Terminology.........................................3 59 3. Scenario Description.............................................4 60 4. Solution One - simple interaction................................5 61 5. Solution Two - complex interaction...............................6 62 5.1. Extension of Proxy Binding Update...........................6 63 5.2. Messaging Mechanism for PMIPv6-DSMIPv6 Interactions.........7 64 5.2.1. Roaming from DSIMPv6 to PMIPv6.........................7 65 5.2.2. Roaming from PMIPv6 to DSIMPv6.........................9 66 5.3. Mobility Agent Considerations...............................9 67 5.3.1. Mobile Node Considerations.............................9 68 5.3.2. Mobility Access Gateway Considerations.................9 69 5.3.3. Local Mobile Anchor Considerations.....................9 70 6. Security Considerations..........................................9 71 7. IANA Considerations..............................................9 72 8. References......................................................10 73 8.1. Normative References.......................................10 74 8.2. Informative References.....................................10 75 9. Acknowledgments.................................................10 76 Author's Addresses.................................................10 78 1. Introduction 80 This document proposes two detailed solutions for a mobile node which 81 is roaming between PMIPv6 and DSMIPv6. In this scenario the HA and 82 LMA are separately deployed in different networks. 84 When a mobile node is roaming from DSMIPv6 domain to PMIPv6 domain, 85 in order to ensure the connectivity of MN's communications, the 86 mobile node must re-register to the HA with a new care-of-address. 87 There are two ways to resolve the problem. One way is that when the 88 MN gets the PMIPv6-HoA from the MAG, it re-registers to the HA with 89 the PMIPv6-HoA as a CoA. The other way is that the LMA will register 90 to the HA with one of its own addresses instead of the attached 91 mobile node. 93 This document also defines some option and mechanisms for use in the 94 solutions. These extensions are optional extensions, but they can 95 help to implement the interaction system. 97 2. Requirements Terminology 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 100 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 101 this document are to be interpreted as described in RFC 2119. 103 The Mobile-IP-related and Proxy-Mobile-IP-related terminology used in 104 this document are described in RFC 3344 [3] and RFC 5213 [2]. The 105 dynamics home agent assignment related terminology used in this 106 document are described in RFC 4433[4]. In addition, the following 107 terms are used: 109 DSMIPV6: dual stack mobile IPv6 111 DSMIPv6-HoA: the Home Address the MN includes in DSMIPv6 binding 112 update messages 114 PMIPv6-HoA: the Home Address assigned by the LMA, in our scenario 115 PMIPv6-HoA is equal to DSMIPv6-HoA 117 LMAA: the address of LMA 119 3. Scenario Description 121 There are three scenarios described in [6]. Scenario A is that the 122 Mobile IPv6 Home Agent (HA) and Proxy Mobile IPv6 (LMA) are separate 123 and the whole network is made up of PMIPv6 domains. Scenario B and C 124 is that the HA and LMA are merged as a common mobility anchor, and 125 the difference between the two scenarios is scenario B including only 126 PMIPv6 domain but scenario C with Non-PMIPv6 domain. However, in our 127 opinion, there should be four scenarios base on whether the HA and 128 LMA are separate or merged and whether the Non-PMIPv6 domain is 129 included. So besides the above-mentioned three scenarios, there must 130 be another scenario D which is the HA and LMA is separate and the 131 network is made up of PMIPv6 domain and Non-PMIPv6 domain. 133 We believe scenario D is more reasonable and practical. The MIPv6 134 should be deployed in the whole network and the PMIPv6 locally 135 deployed. This scenario is easy to deploy and convenient to manage. 136 Because the MAG can't be deployed everywhere, the request in scenario 137 A which the whole network is only made up of PMIPv6 domain is not 138 practical. It requires the whole network should consist of PMIPv6 139 domain and Non-PMIPv6 domain. So scenario D is reasonable and used as 140 our scenario. 142 The figure 1 illustrates our scenario. In this scenario the HA and 143 LMA are separately deployed, in other words HA and LMA are belongs 144 to different networks. The interaction is similar to HIMIPv6; DSMIPv6 145 is used as a global mobility management whereas PMIPv6 is used as 146 local mobility management. The Non-PMIPv6 domain is also included in 147 our scenario. When a mobile node is roaming in DSMIPv6 domain, it 148 uses the protocol of the DSMIPv6. The same mechanism is used when the 149 mobile node is roaming only in the PMIPv6 domain. But when the mobile 150 node is roaming from DSMIPv6 domain to PMIPv6 domain, the two 151 solutions described in this document can be used to re-register to 152 the HA. 154 +----+ 155 | HA | DSMIPv6-HoA -> LMAA 156 +----+ 157 /\ 158 / \ 159 / \ 160 / \ 161 / \ 162 / \ 163 / \ 164 / \ 165 PMIPv6-HoA -> MAG +-----+ +---------+ 166 | LMA | ( ) DSMIPv6 Network 167 +-----+ ( ) 168 || +---------+ 169 +----||-----+ | 170 PMIPv6 Domain ( || ) | 171 ( || ) | 172 +----||-----+ | 173 +-----+ +----+ 174 | MAG | | AR | 175 +-----+ +----+ 176 | | 177 [MN] 179 Figure 1 - Scenario 181 4. Solution One - simple interaction 183 This solution is much like the one proposed in [6] related to 184 scenario A. The difference between the two solutions is that the Non- 185 PMIPv6 domain is introduce into our scenario. In this simple 186 interaction solution, the mobile node is managed by DSMIPv6 protocol 187 when it is roaming only in the Non-PMIPv6 domain (DSMIPv6 domain) and 188 the same to the PMIPv6 domain. However, when the mobile node is 189 roaming from Non-PMIPv6 domain to PMIPv6 domain or from one PMIPv6 190 domain to another, the mobile node should re-register to the HA. The 191 re-register process should be performed as the figure for global 192 mobility message flow which is defined in [6]. When the mobile node 193 is roaming from PMIPv6 domain to Non-PMIPv6 domain, the message flow 194 is shown as figure 2. 196 MN RA HA(DSIMPv6) MAG LMA(PMIPv6) 198 | | | |------1-----> | 200 | | | |<-----2------ | 202 |----3---> | | | | 204 |<---4---- | | | | 206 | | | | | 208 |-----------5----------> | | | 210 |<----------6----------- | | | 212 |<---------------------> | | | 214 Figure 2: Message Flow for MN's roaming from PMIPv6 to Non-PMIPv6 216 Firstly, as the step 1 and 2 shown, the MAG will discover that the MN 217 has been gone, and it will send a PBU to revoke the binding for MN at 218 the LMA. The LMA will send a PBA to confirm the revocation. The step 219 from 3 to 6 describe the process of the re-register to HA as the 220 MIPv6[5] defines. 222 5. Solution Two - complex interaction 224 In this complex interaction solution, when a mobile node is roaming 225 from DSMIPv6 domain to PMIPv6 domain using DSMIPv6-HoA, LMA should 226 receive all the packets sent to MN and then forward them to MN via 227 MAG. When the MN attach to the MAG, the registration to HA will be 228 accomplished by the LMA instead of MN, and the care-of-address option 229 includes in the Binding Update will be filled with the LMAA. Then a 230 tunnel between the LMA and HA will be established. All the packets 231 sent to MN will be forwarded through the tunnel. 233 5.1. Extension of Proxy Binding Update 235 The HA Address Option, shown in Figure 2, contains the address of the 236 HA. This extension is used in PBU to tell LMA who is the MN's HA. It 237 MAY be an optional extension. 239 0 1 2 30 241 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Type | Length | Reserved | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | HA-Address | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 Figure 3: The HA Address Option 255 Type specifies the HA address option 257 Length Indicates the length of the extension not including 258 the type, reserved and length fields. 260 HA-Address Address of the HA. 262 5.2. Messaging Mechanism for PMIPv6-DSMIPv6 Interactions 264 This specification presents the messaging mechanism for MN's roaming 265 from DSMIPv6 domain to the PMIPv6 domain and the opposite direction. 267 5.2.1. Roaming from DSIMPv6 to PMIPv6 269 Detailed explanation of the process is best described with the help 270 of a message flow diagram and description. Figure 3 shows the process 271 of a MN roams from DSMIPv6 to PMIPv6. 273 MN HA(DSIMPv6) MAG LMA(PMIPv6) 275 |------1----->| | | 277 |<-----2------| | | 279 |---------------3------------->| | 281 | | |-------4----->| 283 | | |<------5------| 285 | | |<------------>| 287 | |<---------------6--------------| 289 | |----------------7------------->| 291 | |<----------------------------->| 293 Figure 4: Message Flow for MN's roaming from DSMIPv6 to PMIPv6 295 1. Firstly the MN sends BU and revokes the binding by setting the 296 lifetime field to 0 and by setting the care-of address equal to the 297 home address 299 2. The HA receives the binding revocation and knows that the MN has 300 left then HA will delete all the resources related to the MN. 302 3. The MN entered the PMIPv6 domain and MAY send a Router 303 Solicitation to the MAG if it does not receive any Router 304 Advertisements for certain time. 306 4. The MAG will send PBU to the LMA for MN while it detects the MN's 307 enter. 309 5. The LMA will send back a PBA once the PBU is accepted and a bi- 310 directional tunnel between MAG and LMA is also established. 312 6. At the same time the LMA will send a BU to the HA for MN and 313 register the LMAA as MN's new CoA. 315 7. The HA will send back BA if the BU is accepted and a bi- 316 directional tunnel will be established between LMA and HA. 318 5.2.2. Roaming from PMIPv6 to DSIMPv6 320 The process of a MN roams from PMIPv6 to DSMIPv6 is the same as the 321 figure 2 shown in 3.2. 323 5.3. Mobility Agent Considerations 325 The following sections describe the behavior of each mobility agent 326 in detail. 328 5.3.1. Mobile Node Considerations 330 The mobile node does not have any special behavior beyond a dual 331 stack mobile node. 333 5.3.2. Mobility Access Gateway Considerations 335 The MAG MAY get the HA address of attached MN, the method may be a 336 static way such as reading from a Strategy Document and this is out 337 the scope of this document. 339 The MAG can send the HA address to the LMA used HA Address Option 340 while registering to LMA and LMA can also reject this option. 342 5.3.3. Local Mobile Anchor Considerations 344 The LMA MUST be able to send binding update to the HA for MN. 345 The MAG may include the HA address option in the proxy binding update 346 while it Registers to the LMA for MN. A valid unicast IPv6 address 347 MUST be used as LMA address in this extension. The LMA will registers 348 to the HA for MN while it accepts the PBU from MAG, so the LMA must 349 be able to generate and send the binding update packet to the HA 350 specified by MAG. 352 6. Security Considerations 354 This specification assumes that a security configuration has been 355 preconfigured between the LMA and the MAG. The Assigned LMA 356 authenticates each Proxy Binding Update from the MAG. The MAG also 357 authenticates the Proxy Binding Apply from the Assigned LMA. 359 7. IANA Considerations 361 The HA Address Option is a new defined extension. 363 8. References 365 8.1. Normative References 367 [1] H. Soliman, Ed., "Mobile IPv6 Support for Dual Stack Hosts and 368 Routers", RFC 5555, June 2009 370 [2] K. Leung, V. Devarapalli, K. Chowdhury and B. Patil, "Proxy 371 Mobile IPv6", RFC 5213, August 2008. 373 [3] C. Perkins, Ed., "IP Mobility Support for IPv4", RFC 3344, 374 August 2002. 376 [4] M. Kulkarni, A. Patel, K. Leung, "Mobile IPv4 Dynamic Home 377 Agent (HA) Assignment", RFC 4433, March 2006. 379 [5] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 380 IPv6", RFC 3775, June 2004. 382 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 383 Requirement Levels", BCP 14, RFC 2119, March 1997. 385 8.2. Informative References 387 [6] G. Giaretta, Ed., "Interactions between PMIPv6 and MIPv6: 388 scenarios and related issues", Internet Draft, June, 2009. 390 9. Acknowledgments 392 The authors would like to thank Tianze Ma for discussions on the 393 topic. 395 This document was prepared using 2-Word-v2.0.template.dot. 397 Author's Addresses 399 Yong Cui 400 Tsinghua University 401 Tsinghua University FIT Building 4-104 402 Beijing 100084 403 P.R.China 405 Email: cuiyong@tsinghua.edu.cn 406 Yin Liu 407 Tsinghua University 408 Tsinghua University FIT Building 4-104 409 Beijing 100084 410 P.R.China 412 Email: liuyin08@gmail.com 414 Yonghao Sun 415 Tsinghua University 416 Tsinghua University FIT Building 4-103 417 Beijing 100084 418 P.R.China 420 Email: yonghaosun@gmail.com 422 Dapeng Liu 423 China Mobile research institute 424 Unit2, 28 Xuanwumenxi Ave,Xuanwu District, 425 Beijing 100053, China 427 Email: liudapeng@chinamobile.com 429 Hui Deng 430 China Mobile 431 53A,Xibianmennei Ave., 432 Xuanwu District, 433 Beijing 100053 434 China 436 Email: denghui02@gmail.com