idnits 2.17.1 draft-devarapalli-netlmm-pmipv6-mipv6-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 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 376. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 387. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 394. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 400. 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 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 25, 2007) is 6208 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'MN' on line 225 ** Obsolete normative reference: RFC 3775 (ref. '2') (Obsoleted by RFC 6275) == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-proxymip6-00 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETLMM Working Group V. Devarapalli 3 Internet-Draft Azaire Networks 4 Intended status: Informational S. Gundavelli 5 Expires: October 27, 2007 Cisco Systems 6 K. Chowdhury 7 Starent Networks 8 A. Muhanna 9 Nortel Networks 10 April 25, 2007 12 Proxy Mobile IPv6 and Mobile IPv6 interworking 13 draft-devarapalli-netlmm-pmipv6-mipv6-01.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on October 27, 2007. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 44 Abstract 46 Proxy Mobile IPv6 is a network-based local mobility management 47 protocol developed in the IETF. Mobile IPv6 is a host-based mobility 48 management protocol that has no restrictions in terms of 49 applicability in a domain. This document captures some of the 50 scenarios where Proxy Mobile IPv6 and Mobile IPv6 are used together. 51 It also describes how the two protocols can work together. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Interworking Scenarios . . . . . . . . . . . . . . . . . . . . 3 58 3.1. Hierarchical Mobility Using Proxy Mobile IPv6 and 59 Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . . . 3 60 3.2. Transitioning between Proxy Mobile IPv6 and Mobile IPv6 . 5 61 3.3. Supporting both MIPv6 and PMIPv6 hosts in the same 62 domain . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 65 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 66 7. Normative References . . . . . . . . . . . . . . . . . . . . . 8 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 68 Intellectual Property and Copyright Statements . . . . . . . . . . 10 70 1. Introduction 72 The NETLMM WG has been working on a network-based mobility management 73 protocol, Proxy Mobile IPv6 [3]. Proxy Mobile IPv6 (PMIPv6) is based 74 on Mobile IPv6 [2] in the sense that it re-uses many concepts from 75 the Mobile IPv6 protocol (MIPv6). Most of the Home Agent 76 functionality as defined in Mobile IPv6 is re-used for Proxy Mobile 77 IPv6. There are many scenarios where Proxy Mobile IPv6 and Mobile 78 IPv6 can be used to-gether. For example, Proxy Mobile IPv6 could be 79 used as the local mobility management protocol and Mobile IPv6 as the 80 global mobility management protocol in a hierarchical manner. 82 In this document we capture three scenarios where Proxy Mobile IPv6 83 and Mobile IPv6 interworking needs to be considered. 85 1. Proxy Mobile IPv6 and Mobile IPv6 are used in a hierarchical 86 manner 87 2. Transitioning between Proxy Mobile IPv6 and Mobile IPv6 88 3. Co-existence of PMIPv6 and MIPv6 hosts in the same network 90 This document also addresses how Mobile IPv6 and Proxy Mobile IPv6 91 can be used together for the three scenarios mentioned above. 93 2. Terminology 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [1]. 99 3. Interworking Scenarios 101 3.1. Hierarchical Mobility Using Proxy Mobile IPv6 and Mobile IPv6 103 In this model, PMIPv6 and MIPv6 are used in a hierarchical manner 104 where PMIPv6 is used for local mobility and MIPv6 is used for global 105 mobility. The MN-HoA address assigned to the mobile node in the 106 Proxy Mobile IPv6 domain is used as the care-of address for Mobile 107 IPv6 registration. If the mobile node moves and attaches to an 108 access network that is not part of the proxy mobile IPv6 domain, it 109 acquires a care-of address from the access network and performs a 110 regular Mobile IPv6 registration with its home agent. When the 111 mobile node is outside the Proxy Mobile IPv6 domain, only Mobile IPv6 112 is used. 114 +----+ 115 | HA | 116 +----+ 117 /\ 118 / \ 119 +-------------/----\--------------+ 120 ( / \ ) Global Mobile IPv6 121 ( / \ ) Domain 122 +----------/----------\-----------+ 123 / \ 124 +----+ +----+ 125 |LMA1| |LMA2| 126 +----+ +----+ 127 //\\ \\ 128 +----//--\\-------------\\------+ 129 ( // \\ \\ ) Local Mobility Network 130 ( // \\ \\ ) PMIPv6 domain 131 +-//--------\\-------------\\---+ 132 // \\ \\ 133 // \\ \\ 134 // \\ \\ 135 +----+ +----+ +----+ 136 |MAG1| |MAG2| |MAG3| 137 +----+ +----+ +----+ 138 | | | 139 [MN] 141 MN obtains Mobile IPv6 HoA from HA 142 MN obtains PMIPv6 MN-HoA1 from LMA1 and PMIPv6 MN-HoA2 from LMA2 144 Figure 1: Hierarchical Mobility using Mobile IPv6 and PMIPv6 146 Using the above figure to illustrate the hierarchical use of Mobile 147 IPv6 and Proxy Mobile IPv6, when the MN is attached to MAG1, it uses 148 MN-HoA as CoA for Mobile IPv6 registration with the home agent. If 149 the MN moves and attaches to MAG2, it is still attached to the same 150 PMIPv6 domain and its PMIPv6 MN-HoA remains the same. Since there is 151 no change in care-of address, the MN does not need to update its 152 binding at the home agent. If the MN moves and attached to MAG3, it 153 is no longer in the same PMIPv6 domain. The MN acquires a new PMIPv6 154 MN-HoA2 from LMA2. Since there is now a change in the care-of 155 address, the MN updates its binding with the home agent with MN-HoA2 156 as the care-of address. 158 When the mobile node moves and attaches to a different MAG in the 159 PMIPv6 domain, the mobile node and the Mobile IPv6 home agent are not 160 aware of the movement. PMIPv6 takes care of managing the mobility 161 between different MAGs. The mobile node's movement is restricted 162 only to the LMA. If the mobile node movement results in attaching to 163 a different PMIPv6 domain, then the mobile node sees a change in its 164 care-of address and sends a binding update to its home agent. 166 There are other hierarchical scenarios possible using Proxy Mobile 167 IPv6 and Mobile IPv6, but they are addressed in this document. 169 3.2. Transitioning between Proxy Mobile IPv6 and Mobile IPv6 171 In this mode, the mobile node uses Proxy Mobile IPv6 as long as it is 172 in the Proxy Mobile IPv6 domain. It has Mobile IPv6 stack active at 173 the same time, but as long as it is attached to the same Proxy Mobile 174 IPv6 domain, it will appear as if it is attached to the home link. 175 If it attaches to an access network that is not part of the Proxy 176 Mobile IPv6 domain, it acquires a care-of address from the access 177 networks, treats the earlier home address in the Proxy Mobile IPv6 178 domain as the Mobile IPv6 home address and performs a Mobile IPv6 179 registration. The Mobile IPv6 registration is performed with the 180 same home agent that was earlier a local mobility anchor in the Proxy 181 Mobile IPv6 domain. 183 The home agent supporting the mobile node based on host-based 184 mobility management scheme, is also configured to function as a local 185 mobility anchor for supporting local mobility management. 187 When the mobile node is in its mobile IPv6 home domain, it will be 188 able to roam in that domain using its MN-HoA and with out having to 189 participate in any mobility related signaling. The domain is enabled 190 for network-based mobility and the obtained home address in the proxy 191 mobile IPv6 context (MN-HoA) is the same as its global home address 192 (MIPv6-HoA). The mobile is not required to initiate host-based 193 mobility and avoiding any IPv6 tunneling over the air in the home 194 domain. 196 When the mobile moves away from its home domain and enters another 197 domain where network-based mobility management is enabled, the mobile 198 node obtains an address from the new PMIPv6 domain, and uses that 199 address as the care-of address for Mobile IPv6 registration. The 200 earlier MN-HoA address is now treated as the MIPv6 home address 201 (MIPv6-HoA). This is similar to the scenario described in 202 Section 3.1. 204 If the mobile node moves in to a domain where network based mobility 205 is not enabled, the mobile node will configure a local address and 206 use the local address as the care-of address for Mobile IPv6 207 registration. The LMA entity for the mobile node now becomes the 208 home agent for the mobile node. 210 +------+ 211 |HA/LMA|-----------------------+ 212 +------+ | 213 //\\ | 214 +-------//--\\--------+ | 215 ( // \\ PMIPv6 ) | 216 ( // \\domain ) +--------------+ 217 +----//--------\\-----+ ( Non-PMIPv6 ) 218 // \\ ( domain ) 219 // \\ +--------------+ 220 // \\ | 221 +----+ +----+ +----+ 222 |MAG1| |MAG2| | AR | 223 +----+ +----+ +----+ 224 | | | 225 [MN] 227 MN obtains Mobile IPv6 HoA from HA 228 MIPv6 HoA = PMIPv6 MN-HoA 230 Figure 2: Transitioning between MIPv6 and PMIPv6 232 The above figure illustrates the scenario. When the MN is attached 233 to MAG1, it obtains a PMIPv6 MN-HoA which is the same as the Mobile 234 IPv6 HoA. So, when the MN is attached to MAG1, it appears to the MN 235 that it is at home. If the MN moves and attaches to MAG2, its PMIPv6 236 MN-HoA remains the same and it is still attached to the home link. 237 If the MN moves outside the PMIPv6 domain and attaches to an access 238 router that has no Proxy Mobile IPv6 support, it just configures an 239 address from the access network and uses that address as the care-of 240 address for Mobile IPv6 registration. 242 Note that in this scenario the same binding cache entry for the 243 mobile node is at times modified by the mobile node and other times 244 modified by a MAG. The home agent must ensure that only authorized 245 MAGs in addition to the mobile node are allowed to modify the binding 246 cache entry for the mobile node. 248 If the mobile node moves back to the PMIPv6 domain that corresponds 249 to its home link, it will send a de-registration binding update with 250 zero lifetime to its home agent. But at the same, the MAG the mobile 251 node is attached will send a proxy Binding Update to the LMA 252 functionality co-located with the home agent. In this case, the home 253 agent MUST send a binding acknowledgement with success status to the 254 mobile node to indicate that it is at home, but modify the binding 255 cache entry to reflect the fact that it is now a binding cache entry 256 created using PMIPv6. The home agent MUST NOT delete the binding 257 cache entry for the mobile node. 259 The bootstrapping mechanisms used to discover the LMA, the Mobile 260 IPv6 home agent and home address for the mobile node must be 261 configured such that the LMA assigned for a particular mobile node 262 can be used as a home agent and the address given to the mobile node 263 when it is attached to the PMIPv6 domain can be used as the MIPv6 264 home address when the mobile node is no longer attached to the PMIPv6 265 domain. 267 When the LMA and the HA are co-located, binding cache lookup for a 268 mobile node must use a combination of the mobile node's identifier 269 and the home address. The Binding Update from the mobile node 270 contains only the home address of the mobile node, whereas the Proxy 271 Binding Update from the MAG contains only the mobile node's 272 identifier. Therefore when transitioning between using Proxy Mobile 273 IPv6 and Mobile IPv6, the Home Agent must ensure that the mobile 274 node's binding cache entry must be looked up with both the home 275 address and identifier of the mobile node. This may require the Home 276 Agent to acquire the mobile node identifier other than from the 277 Binding Update message (for e.g., from the preceding IKEv2 exchange 278 that set up security associations for sending the Binding Update) and 279 save it as part of the binding cache entry for the mobile node. 281 Note that there is only one binding cache for the mobile node at any 282 time, irrespective of whether the mobile node is using Proxy Mobile 283 IPv6 or Mobile IPv6. 285 3.3. Supporting both MIPv6 and PMIPv6 hosts in the same domain 287 This scenario addresses a network where there is a combination of 288 Mobile IPv6 hosts and IPv6 hosts that do not implement any mobility 289 management software. The same home agent that supports hosts that 290 have the Mobile IPv6 mobile node functionality will also act as the 291 PMIPv6 LMA for hosts that rely on network-based mobility management. 292 Supporting this scenario is rather straight forward and is described 293 in the based PMIPv6 specification [3]. 295 4. Security Considerations 297 Scenarios 1 and 3 described in Section 3 do not introduce any 298 security considerations in addition to those described in [3] or [2]. 300 In Scenario 2 described in Section 3.2, the home agent has to allow 301 the authorized MAGs in a particular PMIPv6 domain to be able to 302 modify the binding cache entry for a mobile node. RFC 3775 requires 303 that only the right mobile node is allowed to modify the binding 304 cache entry for its home address. This document requires that the a 305 home agent that also implements the PMIPv6 LMA functionality should 306 allow both the mobile node and the authorized MAGs to modify the 307 binding cache entry for the mobile node. 309 5. IANA Considerations 311 This document requires no action from IANA. 313 6. Acknowledgments 315 The authors would like to thank Gerardo Giaretta and Vidya Narayanan 316 for interesting discussions on this topic. 318 7. Normative References 320 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 321 Levels", BCP 14, RFC 2119, March 1997. 323 [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 324 IPv6", RFC 3775, June 2004. 326 [3] Gundavelli, S., "Proxy Mobile IPv6", 327 draft-ietf-netlmm-proxymip6-00 (work in progress), April 2007. 329 Authors' Addresses 331 Vijay Devarapalli 332 Azaire Networks 333 3121 Jay Street 334 Santa Clara, CA 95054 335 USA 337 Email: vijay.devarapalli@azairenet.com 339 Sri Gundavelli 340 Cisco Systems 341 170 West Tasman Drive 342 San Jose, CA 95134 343 USA 345 Email: sgundave@cisco.com 346 Kuntal Chowdhury 347 Starent Networks 348 30 International Place 349 Tewksbury, MA 350 USA 352 Email: kchowdhury@starentnetworks.com 354 Ahmad Muhanna 355 Nortel Networks 356 2221 Lakeside Blvd. 357 Richardson, TX 75082 358 USA 360 Email: amuhanna@nortel.com 362 Full Copyright Statement 364 Copyright (C) The IETF Trust (2007). 366 This document is subject to the rights, licenses and restrictions 367 contained in BCP 78, and except as set forth therein, the authors 368 retain all their rights. 370 This document and the information contained herein are provided on an 371 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 372 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 373 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 374 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 375 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 376 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 378 Intellectual Property 380 The IETF takes no position regarding the validity or scope of any 381 Intellectual Property Rights or other rights that might be claimed to 382 pertain to the implementation or use of the technology described in 383 this document or the extent to which any license under such rights 384 might or might not be available; nor does it represent that it has 385 made any independent effort to identify any such rights. Information 386 on the procedures with respect to rights in RFC documents can be 387 found in BCP 78 and BCP 79. 389 Copies of IPR disclosures made to the IETF Secretariat and any 390 assurances of licenses to be made available, or the result of an 391 attempt made to obtain a general license or permission for the use of 392 such proprietary rights by implementers or users of this 393 specification can be obtained from the IETF on-line IPR repository at 394 http://www.ietf.org/ipr. 396 The IETF invites any interested party to bring to its attention any 397 copyrights, patents or patent applications, or other proprietary 398 rights that may cover technology that may be required to implement 399 this standard. Please address the information to the IETF at 400 ietf-ipr@ietf.org. 402 Acknowledgment 404 Funding for the RFC Editor function is provided by the IETF 405 Administrative Support Activity (IASA).