idnits 2.17.1 draft-mccann-mobileip-ipv6mipv4-03.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 137: '... The mobile node MUST include the IPv6...' RFC 2119 keyword, line 138: '...xtension, and it MUST appear prior to ...' RFC 2119 keyword, line 141: '...ic IPv6 home address it MAY be encoded...' RFC 2119 keyword, line 142: '...n. Alternatively, the mobile node MAY...' RFC 2119 keyword, line 145: '...ntifier. The MN MAY request that both...' (13 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 219 has weird spacing: '...ply for broad...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'Braden89' is defined on line 355, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2461 (ref. 'Narten98a') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2434 (ref. 'Narten98b') (Obsoleted by RFC 5226) -- No information found for draft-ietf-mobileip-rfc2002bis - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Perkins01' Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile IP Pat R. Calhoun 3 INTERNET DRAFT Black Storm Networks 4 draft-mccann-mobileip-ipv6mipv4-03.txt Paal E. Engelstad 5 Telenor R&D 6 Tom Hiller 7 Peter J. McCann 8 Lucent Technologies 9 October, 2002 11 IPv6 over Mobile IPv4 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026 [Bradner96]. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any 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 1. Abstract 36 This document specifies a Mobile IPv4 extension that may be used by 37 dual stack mobile nodes to obtain IPv6 service with the use of a 38 Mobile IPv4 registration. This extension allows for immediate 39 deployment of IPv6 on dual stack mobile devices, without the need 40 for a full IPv6 infrastructure. It is believed that providing IPv6 41 services to mobile devices in the short term will spur the growth of 42 IPv6 networks. 44 This extension makes use of the existing Mobile IPv4 security model, 45 including the interface to the AAA infrastructure, but does not 46 provide the route optimization capabilities included in the Mobile 47 IPv6 protocol. Further, this specification requires that the mobile 48 node and Home Agent have dual IPv4 and IPv6 stacks. There are no 49 changes to the FA nor does it need to be dual stack. 51 2. Introduction 53 To allow for the incremental deployment of IPv6, it will be 54 necessary to support mobile IPv6 nodes that connect to IPv4-only 55 networks. This document defines a Mobile IPv4 extension that may be 56 used by mobile nodes to request IPv6 service from Mobile IPv4 Home 57 Agents, even when visiting Foreign Agents (or access routers) that 58 implement only IPv4. When a mobile node requests IPv6 service, and 59 the Home Agent is capable of providing such service, IPv6 packets 60 destined for the mobile are encapsulated within an IPv4 header 61 between the mobile node and Home Agent. IPv6 packets are then 62 decapsulated within the mobile node. Similarly, the mobile node 63 encapsulates IPv6 packets within an IPv4 header that is destined for 64 the Home Agent. 66 AAAF ----------- AAAH 67 / \ 68 / IPv6 over \ 69 MN - IPv4 - FA ----- IPv4 ------- HA ---- IPv6 70 link Internet Island 72 Figure 1. A deployment scenario for IPv6 over MobileIPv4. 74 Figure 1 depicts an example deployment scenario for IPv6-over- 75 MobileIPv4. We assume that the MN and FA are separated by exactly 76 one link-layer hop. Here the MN registers with the FA using a 77 Mobile IPv4 Registration Request including a skippable IPv6 Address 78 Extension (defined below), an NAI, and a Challenge-Response. The 79 registration is validated through the use of a AAA infrastructure 80 and sent to the HA. While the extension defined here does not 81 strictly depend upon the use of AAA, we expect this to be a useful 82 deployment case. We assume the HA is located on a link where the 83 MN's home IPv4 address resides, and that it owns a range of IPv6 84 addresses for use by MNs. Upon processing the IPv6 Address 85 Extension, the HA assigns an IPv6 address to the MN and begins to 86 serve as an IPv6 router for the MN. 88 When the HA receives an IPv6 packet addressed to the MN, it first 89 encapsulates the packet in an IPv4 packet, using the MN home address 90 as the destination address and the HA address as the source address. 91 The HA then forwards the encapsulated packet to the MN using its 92 Mobile IPv4 mobility binding; for FA-located COA, the packet is sent 93 to the FA over an IPv4 tunnel, where it is decapsulated. The FA then 94 delivers the packet to the MN, and the MN itself performs the last 95 stage of decapsulation, delivering the IPv6 packet to upper layers. 96 For co-located COA, the MN itself performs both decapsulations. 98 When the MN sends an IPv6 packet using this mechanism, it 99 encapsulates the IPv6 packet in an IPv4 header destined to the Home 100 Agent. When using FA-located COA and reverse tunneling, the packet 101 is delivered to the FA which encapsulates it again and routes it 102 towards the HA. When using co-located COA and reverse tunneling, the 103 MN performs the second layer of encapsulation itself and routes the 104 resulting packet towards the HA. Finally, when reverse tunneling is 105 not in use, the MN may send the singly-encapsulated packet directly 106 to the HA. 108 Note that the IPv4 address assigned to the MN may be private to the 109 Home Agent [Montenegro01], which reduces the demand for public IPv4 110 addresses. 112 The advantages of this proposal include: 114 - It allows mobile devices to support IPv6 in the near term. 115 - It allows mobiles that belong to an IPv6 network to receive 116 service on an IPv4 network, which is believed to be critical 117 since only some geographical areas will be deploying IPv6 118 networks. 119 - It does not affect the FA nor require any link-layer support 120 for IPv6 on the visited link. 121 - It allows dual stack mobile devices to benefit from existing 122 Mobile IPv4 deployments. 123 - It supports dynamic IPv6 home address allocation. 124 - It can alleviate the demand for public IPv4 addresses while 125 supporting globally routable IPv6 addresses. 127 This specification is intended to allow dual stack mobile nodes to 128 receive IPv6 services while mobile, and does require that the Home 129 Agent in the network also be dual stack. This specification is not 130 intended to replace the Mobile IPv6 protocol, which does not have 131 such restrictions and at the same time provides route optimization 132 capabilities. 134 3. Mobile Node Considerations 136 A mobile node may request IPv6 service using a Mobile IPv4 137 Registration Request. The mobile node MUST include the IPv6 Address 138 Extension, and it MUST appear prior to any authentication extensions 139 in the registration request. 141 If the Mobile Node has a static IPv6 home address it MAY be encoded 142 in the IPv6 Address Extension. Alternatively, the mobile node MAY 143 request that an IPv6 home address be dynamically assigned to it by 144 setting the high order 64 bits to zero, and the low order 64 bits to 145 a unique interface identifier. The MN MAY request that both the 146 prefix and interface identifier be dynamically assigned to it by 147 setting the entire 128-bit IPv6 Address to zero. 149 If the low-order 64 bits are derived from an EUI-48 or EUI-64 150 number, the 'u' bit (Internet bit 6) MUST be set to 1. Otherwise 151 this bit MUST be set to 0. 153 A successful registration reply that does not include an IPv6 154 Address extension implies that the Home Agent was not willing or 155 capable of providing IPv6 service. In this case the mobile node has 156 the option of either using the IPv4 service, or initiating a 157 registration request with a lifetime of zero (0) to inform the Home 158 Agent that it does not wish to make use of the registered mobility 159 binding. 161 Upon receipt of a successful registration reply that does include 162 the IPv6 Address Extension, the MN configures a local IPv6 interface 163 for IPv6-over-MobileIPv4 operation with the negotiated IPv6 address. 164 When sending IPv6 packets on this interface, the MN MUST encapsulate 165 them in an IPv4 header using the HA address as the destination and 166 the MN address as the source. Depending on the type of Mobile IPv4 167 registration, the MN either delivers that packet to the FA (FA- 168 located COA), encapsulates the packet a second time and routes it to 169 the HA (co-located COA with reverse tunneling), or routes the packet 170 directly to the HA (co-located COA with no reverse tunneling). When 171 receiving packets from the HA, the MN decapsulates packet once for 172 FA-located COA or twice for co-located COA. If the result is an IPv6 173 packet with the negotiated destination address, it is delivered to 174 the upper layers from the IPv6-over-MobileIPv4 interface. 176 4. Home Agent Considerations 178 Home Agents that support the IPv6 Address Extension MUST be 179 configured with at least one unique IPv6 subnet prefix. Upon receipt 180 of a registration request with the IPv6 Address Extension, the Home 181 Agent uses the following algorithm in the formation of the IPv6 home 182 address: 184 1. If the most significant 64 bits of the address matches one of 185 the prefixes configured on the Home Agent, the requested prefix 186 is used. Otherwise, the HA chooses one of its configured 187 prefixes. 189 2. If the least significant 64 bits of the address are set to a 190 non-zero value, and the value forms an interface identifier 191 that is unique to the prefix chosen in step 1, the value 192 requested is used. Otherwise (the least 64 bits were set to 193 zero or were not unique to the prefix), the Home Agent 194 allocates an interface identifier unique to the prefix. The 195 interface identifier is concatenated with the prefix chosen in 196 step 1 to form the complete IPv6 home address. 198 If the Registration Request was successfully processed, the IPv6 199 home address constructed using the above algorithm is inserted in 200 the Registration Reply's IPv6 Address extension. If the requested 201 Mobile IP lifetime is greater than the remaining lifetime of the 202 address prefix given in the response, the HA MUST reduce the 203 lifetime to the remaining prefix lifetime. 205 The HA behaves as a first-hop IPv6 router for the mobile node, NOT 206 as a Mobile IPv6 Home Agent. In particular, when a packet for the 207 MN's IPv6 address arrives on the home network, it will be delivered 208 to the HA by the next upstream router due to IPv6 routing 209 mechanisms. The HA MUST encapsulate it in a packet addressed to the 210 MN's home address. The result will be encapsulated again, according 211 to the negotiated Mobile IPv4 encapsulation format. The HA performs 212 usual IPv4 layer 3 forwarding procedures on that packet. In the 213 opposite direction, the HA MUST decapsulate packets arriving from 214 the MN. Such packets will be singly- or doubly-encapsulated, 215 depending on the placement of the care-of address (co-located or FA- 216 located) and the use of reverse tunneling. The HA then performs 217 usual layer 3 forwarding on the resulting IPv6 packet. 219 Identical encapsulation rules apply for broadcast or multicast 220 packets. The HA should only forward broadcast traffic if the 'B' 221 bit was set in the registration request, and it should only forward 222 multicast traffic if the MN explicitly requested to join a group via 223 IGMP messages. Link-local and site-local addresses also are subject 224 to the same handling. Here the scope of the IPv6 link is the IPv4 225 tunnel between the HA and MN. 227 5. Foreign Agent Considerations 229 The operation of the Foreign Agent is not affected by this 230 specification. The IPv6 Address Extension is skippable, which means 231 that it need not be parsed or understood by the FA. Of course, if 232 there is a security association in place between the FA and any 233 other mobility entities, the FA's authentication extensions must 234 cover the IPv6 Address Extension as it would any other extension 235 that appeared in the same place in the Registration Request or 236 Reply. 238 6. Neighbor Discovery 240 The MN and HA MAY exchange Neighbor Discovery [Narten98a] messages 241 if desired, but they must observe the above rules when sending IPv6 242 all-nodes or all-routers multicast packets. 244 The use of Neighbor Discovery is optional because the IPv6 Address 245 Extension provides a mechanism for establishing a unique MN 246 interface identifier and network prefix in the same round-trip as 247 Mobile IPv4 registration. 249 7. IPv6 Address Extension 251 The IPv6 Address extension is used by a mobile node to communicate 252 its desire to receive IPv6 packets from the Home Agent. The mobile 253 node MAY request that a home address be dynamically assigned, using 254 the procedures described in section 3. The format of the extension 255 is as follows: 257 0 1 2 3 258 0 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 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Type | Length | Binding Type | (reserved) | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | | 263 + + 264 | IPv6 Address | 265 + + 266 | | 267 + + 268 | | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 Figure 2: The IPv6 Address Extension 273 Type 274 TBD (skippable) 276 Length 277 The length field MUST contain 18. 279 Binding Type 280 The Binding Type field is provided for future compatibility 281 with other v4/v6 inter-working mechanisms that may also use 282 the IPv6 Address Extension. This document uses the value 283 zero: 285 0 - IPv6 over MobileIPv4 287 MNs and HAs that comply with this specification MUST set the 288 Binding Type field to zero. Future specifications may define 289 additional values. 291 IPv6 Address 292 When the Binding Type field is set to zero, the IPv6 Address 293 field contains the mobile node's IPv6 home address. The 294 mobile node MAY set the most significant 64 bits to zero to 295 request that a prefix be dynamically assigned. The mobile 296 node MAY also set the least 64 bits to zero to request that an 297 interface identifier be dynamically assigned. 299 8. Security Considerations 301 The IPv6 Address Extension outlined in this document is a Mobile IP 302 extension and should be protected by appropriate Mobile IP 303 Authentication Extensions, as outlined in the base Mobile IP 304 specification [Perkins01]. 306 This specification couples IPv6 address assignment, including prefix 307 discovery and interface identifier selection, to the Mobile IPv4 308 registration process. While this creates a dependency that might be 309 avoided if generic IPv6 neighbor discovery procedures were used 310 through a tunnel established by other means, there is a benefit from 311 covering the address assignment process with the same security 312 associations used for Mobile IPv4. The HA can create a secure 313 binding between the MN's IPv4 address, its NAI (if present in the 314 Registration Request), and its IPv6 address. Because the HA will be 315 redirecting IPv6 packets to the given IPv4 address, it is important 316 for this binding to be secure. 318 Note that this document does not address other security threats to 319 the IPv6 over IPv4 tunnel, and in particular such traffic may be 320 vulnerable to eavesdropping or packet injection attacks. However, 321 these attacks are no more severe than those that are possible with 322 ordinary reverse tunneling for Mobile IPv4 traffic [Montenegro01], 323 and can be remedied with the same techniques. For example, it may 324 be necessary to use IP Security between the HA and the v4 tunnel 325 endpoint. However, not all deployment environments will require 326 such a level of security. 328 The use of Neighbor Discovery procedures, given as optional in 329 Section 6, may introduce additional security considerations if they 330 result in new packets being redirected to mobile nodes. These 331 messages are ordinarily not protected by security associations. 333 9. IANA Considerations 335 The IPv6 Address extension defined in Section 8 is a Mobile IP 336 registration extension as defined in the base Mobile IP 337 specification [Perkins01]. The IANA should assign a value from the 338 skippable (128-255) range. 340 The Binding Type field of the IPv6 Address Extension is a new name 341 space that must be managed by IANA. This document reserves the 342 value zero. Following the policies outlined in RFC 2434 343 [Narten98b], future assignments should be made after consultation 344 with a Designated Expert. 346 10. Acknowledgements 348 Thanks to Paul Francis for pointing out the double encapsulation 349 idea to avoid impact on the FA, and to Mark Lipford of SprintPCS and 350 Bryan Cook of Verizon Wireless for valuable feedback and 351 encouragement. 353 11. References 355 [Braden89] Braden, R. (ed.), "Requirements for Internet Hosts -- 356 Communication Layers," RFC 1122, October 1989. 358 [Bradner96] Bradner, S., "The Internet Standards Process, 359 Revision 3," RFC 2026, October 1996. 361 [Montenegro01] Montenegro, G., editor, "Reverse Tunneling for Mobile 362 IP, revised," RFC 3024, January 2001. 364 [Narten98a] Narten, T., Nordmark, E., and Simpson, W., "Neighbor 365 Discovery for IP Version 6 (IPv6)," RFC 2461, 366 December 1998. 368 [Narten98b] Narten, T., Alvestrand, H., "Guidelines for Writing 369 an IANA Considerations Section in RFCs," RFC 2434, 370 October 1998. 372 [Perkins01] Perkins, C., "IP Mobility Support for IPv4, revised," 373 draft-ietf-mobileip-rfc2002bis-08.txt, September 374 2001. Work In Progress. 376 12. Authors' Addresses 378 Peter J. McCann 379 Lucent Technologies 380 Rm 2Z-305 381 263 Shuman Blvd 382 Naperville, IL 60566-7050 383 USA 385 Phone: +1 630 713 9359 386 FAX: +1 630 713 1921 387 E-mail: mccap@lucent.com 389 Pat R. Calhoun 390 Black Storm Networks 391 110 Nortech Parkway 392 San Jose, CA 95134 393 USA 395 Phone: +1 408 941 0500 396 E-mail: pcalhoun@bstormnetworks.com 398 Tom Hiller 399 Lucent Technologies 400 Rm 2F-218 401 263 Shuman Blvd 402 Naperville, IL 60566-7050 403 USA 405 Phone: +1 630 979 7673 406 FAX: +1 630 979 7673 407 E-mail: tom.hiller@lucent.com 409 Paal E. Engelstad 410 Telenor R&D, Palo Alto 411 399 Sherman Ave, Suite 12 412 Palo Alto, CA 94306-1863 413 USA 415 Phone: +1 650 714 7538 416 E-mail: paal@telenorisv.com 418 Intellectual Property Statement 420 At the time of submission the authors are not aware of any 421 intellectual property rights that pertain to the implementation or 422 use of the technology described in this document. However, this 423 does not preclude the possibility that Lucent Technologies, Inc. or 424 other entities may have such rights. The patent licensing policy of 425 Lucent Technologies, Inc. is on file with the IETF Secretariat. 427 The IETF takes no position regarding the validity or scope of any 428 intellectual property or other rights that might be claimed to 429 pertain to the implementation or use of the technology described in 430 this document or the extent to which any license under such rights 431 might or might not be available; neither does it represent that it 432 has made any effort to identify any such rights. Information on the 433 IETF's procedures with respect to rights in standards-track and 434 standards-related documentation can be found in BCP-11. Copies of 435 claims of rights made available for publication and any assurances 436 of licenses to be made available, or the result of an attempt made 437 to obtain a general license or permission for the use of such 438 proprietary rights by implementers or users of this specification 439 can be obtained from the IETF Secretariat. 441 The IETF invites any interested party to bring to its attention any 442 copyrights, patents or patent applications, or other proprietary 443 rights that may cover technology that may be required to practice 444 this standard. Please address the information to the IETF Executive 445 Director. 447 Full Copyright Statement 449 Copyright (C) The Internet Society (2001). All Rights Reserved. This 450 document and translations of it may be copied and furnished to 451 others, and derivative works that comment on or otherwise explain it 452 or assist in its implementation may be prepared, copied, published 453 and distributed, in whole or in part, without restriction of any 454 kind, provided that the above copyright notice and this paragraph 455 are included on all such copies and derivative works. However, this 456 document itself may not be modified in any way, such as by removing 457 the copyright notice or references to the Internet Society or other 458 Internet organizations, except as needed for the purpose of 459 developing Internet standards in which case the procedures for 460 copyrights defined in the Internet Standards process must be 461 followed, or as required to translate it into languages other than 462 English. 464 The limited permissions granted above are perpetual and will not be 465 revoked by the Internet Society or its successors or assigns. 467 This document and the information contained herein is provided on an 468 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 469 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 470 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 471 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 472 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.