idnits 2.17.1 draft-ietf-mip6-nemo-v4traversal-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 28. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1016. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 995. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1001. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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) == Missing Reference: 'IPv4 HAO' is mentioned on line 665, but not defined == Missing Reference: 'IPv4 ACK' is mentioned on line 679, but not defined == Unused Reference: 'IPv6' is defined on line 894, but no explicit reference was found in the text == Unused Reference: 'KEYWORDS' is defined on line 897, but no explicit reference was found in the text == Unused Reference: 'MIPv4' is defined on line 904, but no explicit reference was found in the text == Unused Reference: 'SEC' is defined on line 913, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4140 (ref. 'HMIPv6') (Obsoleted by RFC 5380) ** Obsolete normative reference: RFC 2460 (ref. 'IPv6') (Obsoleted by RFC 8200) == Outdated reference: A later version (-03) exists of draft-ietf-mip6-dsmip-problem-01 ** Downref: Normative reference to an Informational draft: draft-ietf-mip6-dsmip-problem (ref. 'MIP-PB') ** Obsolete normative reference: RFC 3344 (ref. 'MIPv4') (Obsoleted by RFC 5944) ** Obsolete normative reference: RFC 3775 (ref. 'MIPv6') (Obsoleted by RFC 6275) -- Possible downref: Normative reference to a draft: ref. 'SNRIO' Summary: 12 errors (**), 0 flaws (~~), 11 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIP6 Working Group Hesham Soliman 3 INTERNET-DRAFT George Tsirtsis 4 Expires: April 2006 Flarion 5 Vijay Deverapalli 6 Nokia 7 James Kempf 8 Docomo Labs 9 Henrik Levkowetz 11 Ericsson 12 Pascal Thubert 13 Cisco 14 Ryuji Wakikawa 16 Keio University 17 October, 2005 19 Dual Stack Mobile IPv6 (DSMIPv6) 20 for Hosts and Routers 21 draft-ietf-mip6-nemo-v4traversal-00.txt 23 Status of this memo 25 By submitting this Internet-Draft, each author represents that any 26 applicable patent or other IPR claims of which he or she is aware 27 have been or will be disclosed, and any of which he or she becomes 28 aware will be disclosed, in accordance with Section 6 of BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that other 32 groups may also distribute working documents as Internet-Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or cite them other than as "work in progress". 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/lid-abstracts.txt 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 45 This document is a submission of the IETF MIP6 WG. Comments should be 46 directed to the IPv6 WG mailing list, mip6@ietf.org. 48 Abstract 50 The current Mobile IPv6 and NEMO specification support only IPv6. 52 Hence, this specification extends those standards to allow the 53 registration of IPv4 addresses and prefixes, respectively, and the 54 transport of both IPv4 and IPv6 packets over the tunnel to the HA. 55 This specification allows also the Mobile Node to roam over both IPv6 56 and IPv4, including the case where Network Address Translation is 57 present on the path. 59 Table of Contents 61 1. Introduction.....................................................2 62 1.1 Motivation for using Mobile IPv6 only...........................3 63 1.2 Scenarios considered by this specification...................4 64 2. Solution overview................................................5 65 2.1. Home Agent Address Discovery...................................5 66 2.2. Mobile Prefix Solicitations and Advertisements..............6 67 2.3. Binding management.............................................6 68 2.3.1 Foreign network supports IPv6.................................7 69 2.3.2 Foreign network supports IPv4 only............................7 70 2.3.2.1 Visited network supports IPv4 only (private addresses)......8 71 2.4. Route optimization.............................................9 72 2.5. Dynamic IPv4 home address allocation..........................10 73 3. Extensions and modifications to Mobile IPv6.....................10 74 3.1. Binding update extensions.....................................10 75 3.1.1 IPv4 home address option.....................................10 76 3.2. Binding acknowledgement extensions............................11 77 3.2.1 IPv4 address acknowledgement option..........................11 78 3.2.2 The NAT detection option...............................12 79 4. Protocol operation..............................................12 80 4.1. NAT detection and traversal................................13 81 4.2. Mobile node operation.........................................14 82 4.3. Home agent operations.........................................16 83 4.4. Correspondent node operations.................................17 84 5. Security considerations.........................................17 85 6. Protocol constants..............................................18 86 7. Acknowledgements................................................18 87 8. IANA considerations.............................................18 88 9. References......................................................18 89 Authors' Addresses.................................................19 91 1. Introduction 93 Mobile IPv6 [MIPv6] and [NEMO] allow mobile nodes to move within the 94 Internet while maintaining reachability and ongoing sessions, using 95 an IPv6 home address or prefix. However, since IPv6 is not widely 96 deployed, it is unlikely that mobile nodes will use IPv6 addresses 97 only for their connections. It is reasonable to assume that mobile 98 nodes will, for a long time, need an IPv4 home address that can be 99 used by upper layers. It is also reasonable to assume that mobile 100 nodes will move to networks that might not support IPv6 and would 101 therefore need an IPv4 Care-of Address. The current Mobile IPv6 102 specification and [NEMO] do not allow mobile nodes to use an IPv4 103 home address or prefix, respectively. Hence, this specification 104 extends Mobile IPv6 capabilities to allow dual stack mobile nodes to 105 request that their home agent (also dual stacked) tunnel IPv4/IPv6 106 packets addressed to their home addresses, to their IPv4/IPv6 care-of 107 address(es). 109 Using this specification, mobile nodes would only need Mobile IPv6 110 and [NEMO] to manage mobility while moving within the Internet. This 111 specification provides the extensions needed in order to allow Mobile 112 IPv6 only to be used by dual sack mobile nodes. 114 This specification will also consider cases where a mobile node moves 115 into a private IPv4 network and gets configured with a private IPv4 116 Care-of Address. In those scenarios, the mobile node needs to be able 117 to traverse the NAT in order to communicate with the Home Agent. NAT 118 traversal for Mobile IPv6 is presented in this specification. 120 In this specification, the term mobile node refers to both a mobile 121 host and mobile router unless the discussion is specific to either 122 hosts or routers. Similarly, we use the term home address to reflect 123 an address/prefix format. 125 In this specification, extensions are defined for the binding update 126 and binding acknowledgement. It should be noted that all these 127 extensions apply to cases where the mobile node communicates with a 128 Mobility Anchor Point (MAP) as defined in [HMIPv6]. The requirements 129 on the MAP are identical to those stated for the home agent, although 130 it is unlikely that NAT traversal would be needed with a MAP as it is 131 expected to be in the same address domain. 133 1.1 Motivation for using Mobile IPv6 only 135 IPv6 offers a number of improvements over today's IPv4, primarily due 136 to its large address space. Mobile IPv6 offers a number of 137 improvements over Mobile IPv4, mainly due to capabilities inherited 138 from IPv6. For instance, route optimization and Dynamic home agent 139 discovery can only be achieved with Mobile IPv6. 141 One of the advantages of the large address space provided by IPv6 is 142 that it allows mobile nodes to obtain a globally unique care-of 143 address wherever they are. Hence, there is no need for Network 144 Address Translator (NAT) traversal techniques designed for Mobile 145 IPv4. This allows Mobile IPv6 to be a significantly simpler and more 146 bandwidth efficient mobility management protocol. At the same time, 147 during the transition towards IPv6, NAT traversal for existing 148 private IPv4 networks needs to be considered. This specification 149 introduces NAT traversal for this purpose. 151 All of the above benefits make the case for using Mobile IPv6 only 152 for dual stack mobile nodes in order to allow for a long lasting 153 mobility solution and minimize the need to changing the mobility 154 stack due to the introduction of IPv6 within a deployed network. 156 1.2 Scenarios considered by this specification 158 In [SNRIO] several scenarios that illustrate potential 159 incompatibilities for mobile nodes using Mobile IPv6 were discussed. 160 Some of the problems associated with mobility and transition issues 161 were presented in [MIP-PB]. This specification considers a subset of 162 the scenarios in [SNRIO], which address all the problems discussed in 163 [MIP-PB]. The scenarios considered in this specification are listed 164 below. 166 All of the following scenarios assume that both the mobile node and 167 the Home Agent are IPv4 and IPv6-enabled and that only Mobile IPv6 is 168 used between the mobile node and the Home Agent. We also assume that 169 the Home Agent is always reachable through a globally unique IPv4 170 address. Finally, it's important to note that the following scenarios 171 are not mutually exclusive. 173 Scenario 1: IPv4-only foreign network 175 In this scenario, a mobile node is connected to an IPv4-only foreign 176 network. The mobile node can only configure an IPv4 Care-of Address. 178 Scenario 2: Mobile node behind a NAT: 180 In this scenario, the mobile node is in a private IPv4 foreign 181 network that has a NAT device connecting it to the Internet. If the 182 Home Agent is located outside the NAT device, the mobile node will 183 need a NAT traversal mechanism to communicate with the Home Agent. 185 Scenario 3: Home Agent behind a NAT: 187 In this scenario, the communication between the mobile node and the 188 Home Agent is further complicated by the fact that the Home Agent is 189 located within a private IPv4 network. However, in this scenario, we 190 assume that the Home Agent is allocated a globally unique IPv4 191 address. Such address might not be physically configured on the Home 192 Agent interface. Instead, it is associated with the Home Agent on the 193 NAT device, which allows the Home Agent to be reachable through 194 address or port mapping. 196 Scenario 4: Use Of IPv4-only applications 198 In this scenario, the mobile node may be located in an IPv4, IPv6 or 199 a dual network. However, the mobile node might be communicating with 200 an IPv4-only node. In this case, the mobile node would need a stable 201 IPv4 address for its application. The alternative to using an IPv4 202 address is the use of protocol translators; however, end-to-end 203 communication with IPv4 is preferred to the use of protocol 204 translators. 206 The mobile node may also be communicating with an IPv4-only 207 application that requires an IPv4 address. 209 The cases above illustrate the need for a stable IPv4 home address to 210 be allocated to the mobile node. This is done using an IPv4 home 211 address. Since running Mobile IPv4 and Mobile IPv6 simultaneously is 212 problematic (as illustrated in [MIP-PB]), this scenario adds a 213 requirement on Mobile IPv6 to support IPv4 home addresses. 215 2. Solution overview 217 In order to allow Mobile IPv6 to be used by dual stack mobile nodes, 218 the following needs to be done: 220 - Mobile nodes should be able to use an IPv4 and IPv6 home or care-of 221 address simultaneously and update their home agents accordingly. 223 - Mobile nodes need to be able to know the IPv4 address of the home 224 agent as well as its IPv6 address. There is no need for IPv4 prefix 225 discovery however. 227 - Mobile nodes need to be able to detect the presence of a NAT device 228 and traverse such device in order to communicate with the Home Agent 229 in a secure manner. 231 This section presents an overview of the extensions required in order 232 to allow mobile nodes to use Mobile IPv6 only for IP mobility 233 management. 235 2.1. Home Agent Address Discovery 237 Dynamic Home Agent Address Discovery (DHAAD) was defined in [MIPv6] 238 to allow mobile nodes to discover their home agents by appending a 239 well-known anycast interface identifier to their home link's prefix. 240 However, this mechanism is based on IPv6-anycast routing. If a mobile 241 node is located in an IPv4-only foreign network, it cannot rely on 242 native IPv6 routing. 244 The preferred solution for discovering the home agent's IPv4 address 245 is through the Domain Name System (DNS). For DNS lookup by name, the 246 mobile node should be configured with the name of the home agent. 247 When the mobile node needs to discover a home agent, it sends a DNS 248 request with QNAME set to the configured name. An example is 249 "ha1.example.com". If a home agent has an IPv4 and IPv6 address, the 250 corresponding DNS record should be configured with both 'AAAA' and 251 'A' records. Accordingly the DNS reply will contain 'AAAA' and 'A' 252 records. 254 For DNS lookup by service, the SRV record defined in [BOOT] is 255 reused. For instance, if the service name is "mip6ha" and the 256 protocol name is "ipv6" for the SRV record, the mobile node SHOULD 257 send a DNS request with the QNAME set to "mip6ha.ipv6.example.com". 258 The response should contain the home agent's FQDN(s) and may have the 259 corresponding 'AAAA' and 'A' records enclosed as well. 261 If multiple home agents reside on the home link, each configured with 262 a public IPv4 addresses, then the operation above applies. In case 263 the home agents are behind a NAT box, there are two options, 1) 264 configure a public IPv4 address for each home agent on the NAT box, 265 2) configure one public address and make the home agents share the 266 public address. In either case, the correct DNS entries can be 267 configured. Another possible solution is to designate one home agent 268 on the home link for v4 traversal. The NAT device should associate 269 that home agent with the public IPv4 address configured on it for v4 270 traversal. In all cases above, both the 'AAAA' and 'A' records 271 returned for a particular name MUST correspond to the same physical 272 home agent; otherwise the mobile node will not be able to bind its 273 addresses correctly. 275 2.2. Mobile Prefix Solicitations and Advertisements 277 According to [MIPv6], the mobile node can send a Mobile Prefix 278 Solicitation and receive a Mobile Prefix Advertisement containing all 279 prefixes advertised on the home link. 281 A dual stack mobile node MAY send a Mobile Prefix Solicitation 282 message encapsulated in IPv4 (i.e. IPv6 in IPv4) in the case where 283 the mobile node has no access to IPv6 within the local network. 284 Securing such messages would require the mobile node to have security 285 association with the home agent, using IPsec (AH or ESP) and based on 286 the mobile node's IPv4 care-of address as described in [MIPv6]. Since 287 the mobile node needs to encapsulate all IPv6 traffic sent to the 288 home agent into IPv4, while located in an IPv4-only visited network, 289 such SA would affect all packets if the selectors were based on the 290 information in the outer header. That is, the SA selectors being the 291 protocol number (protocol is always IP in IP), as well as, source and 292 destination addresses are all common to all packets. If this effect 293 is not desired, the mobile node can base the SA on the information in 294 the inner header (i.e. using the home agent's IPv6 address, the 295 mobile node's home address and the ICMP protocol number). Such 296 security association would use transport mode ESP protection. 298 2.3. Binding management 300 A dual stack mobile node will need to update its home agent with its 301 care-of address. If a mobile node has an IPv4 and an IPv6 home 302 address it will need to create a binding cache entry for each 303 address. The format of the IP packet carrying the binding update and 304 acknowledgement messages will vary depending on whether the mobile 305 node has access to IPv6 in the visited network. There are three 306 different scenarios to consider with respect to the visited network: 308 A. The visited network has IPv6 connectivity and provides the mobile 309 node with a care-of address (in a stateful or stateless manner). 311 B. The mobile node can only configure a globally unique IPv4 address 312 in the visited network. 313 C. The mobile node can only configure a private IPv4 address in the 314 visited network. 316 2.3.1 Foreign network supports IPv6 318 In this case, the mobile node is able to configure a globally unique 319 IPv6 address. The mobile node will send a binding update to the IPv6 320 address of its home agent, as defined in [MIPv6]. The binding update 321 MAY include the IPv4 home address option introduced in this document. 322 After receiving the binding update, the home agent creates two 323 binding cache entries, one for the mobile node's IPv4 home address, 324 and another for the mobile node's IPv6 home address. Both entries 325 will point to the mobile node's IPv6 care-of address. Hence, whenever 326 a packet is addressed to the mobile node's IPv4 or IPv6 home 327 addresses, it will be tunneled in IPv6 to the mobile node's IPv6 328 care-of address included in the binding update. Effectively, the 329 mobile node establishes two different tunnels, one for its IPv4 330 traffic (IPv4 in IPv6) and one for its IPv6 traffic (IPv6 in IPv6) 331 with a single binding update. The security implications of this 332 mechanism are discussed in the security considerations section. 334 In this scenario, the only addition to [MIPv6] is the inclusion of 335 the IPv4 home address option in the binding update message. 337 After accepting the binding update and creating the corresponding 338 binding cache entries, the home agent MUST send a binding 339 acknowledgement to the mobile node as defined in [MIPv6]. In 340 addition, if the binding update included an IPv4 home address option, 341 the binding acknowledgement MUST include the IPv4 address 342 acknowledgment option as described later in this specification. This 343 option informs the mobile node whether the binding was accepted for 344 the IPv4 home address. If this option is not included in the binding 345 acknowledgement and the IPv4 home address option was included in the 346 binding update, the mobile node MUST assume that the home agent does 347 not support the IPv4 home address option and therefore SHOULD NOT 348 include the option in future binding updates to that home agent 349 address. 351 The routing header in the binding update MUST include the mobile 352 node's IPv6 home address as specified in [MIPv6]. 354 2.3.2 Foreign network supports IPv4 only 355 If the mobile node is in a foreign network that only supports IPv4, 356 it needs to first detect whether a NAT is in its communication path 357 to the home agent. This is done using the NAT detection mechanism 358 presented later in this document. If no NAT is detected between the 359 mobile node and the home agent, the mobile node assumes that it is in 360 a foreign network that supports IPv4 public addresses. Otherwise, the 361 mobile node assumes that private addresses are used in the foreign 362 network. Note that this assumption is only valid for the purposes of 363 the signaling presented in this specification. A mobile node SHOULD 364 NOT assume that its IPv4 address is globally unique if a NAT device 365 was not detected. The operations of both cases are discussed below. 367 2.3.2.2 Foreign network supports IPv4 only (public addresses) 369 In this scenario the mobile node will need to tunnel IPv6 packets 370 containing the binding update to the home agent's IPv4 address. The 371 mobile node uses the IPv4 address it gets from the foreign network as 372 a source address in the outer header. The binding update will contain 373 the mobile node's IPv6 home address in the home address option. 374 However, since the care-of address in this scenario is the mobile 375 node's IPv4 address, the mobile node MUST include its IPv4 care-of 376 address in the IPv6 packet. The IPv4 address is represented in an 377 IPv4-mapped IPv6 address and is included in the source address field 378 of the IPv6 header. 380 If the mobile node had an IPv4 home address, it MUST also include the 381 IPv4 home address option described in this specification. 383 After accepting the binding update, the home agent MUST create a new 384 binding cache entry for the mobile node's IPv6 home address. If an 385 IPv4 home address option were included, the home agent MUST create 386 another entry for that address. All entries MUST point to the mobile 387 node's IPv4 care-of address. Hence, all packets addressed to the 388 mobile node's home address(es) (IPv4 or IPv6) will be encapsulated in 389 an IPv4 header that includes the home agent's IPv4 address in the 390 source address field and the mobile node's IPv4 care-of address in 391 the destination address field. 393 After accepting the binding updates and creating the corresponding 394 entries, the home agent MUST send a binding acknowledgement as 395 specified in [MIPv6]. In addition, if the binding update included an 396 IPv4 home address option, the binding acknowledgement MUST include 397 the IPv4 address acknowledgment option as described later in this 398 specification. The binding update is encapsulated to the IPv4 care-of 399 address (represented as an IPv4-mapped IPv6 address in the binding 400 update). 402 2.3.2.1 Visited network supports IPv4 only (private addresses) 404 In this scenario the mobile node will need to tunnel IPv6 packets 405 containing the binding update to the home agent's IPv4 address. In 406 order to traverse the NAT device, IPv6 packets are tunneled UDP and 407 IPv4. The UDP port used to send the IPv6 packet is TBD. 409 The mobile node uses the IPv4 address it gets from the visited 410 network as a source address in the IPv4 header. The binding update 411 will contain the mobile node's IPv6 home address in the home address 412 option. The content of the IPv6 packet is identical to the public 413 address scenario described above. 415 After accepting the binding update, the home agent MUST create a new 416 binding cache entry for the mobile node's IPv6 home address. If an 417 IPv4 home address option were included, the home agent MUST create 418 another entry for that address. All entries MUST point to the mobile 419 node's IPv4 care-of address included in the source address of the 420 IPv6 packet and represented as an IPv4-mapped IPv6 address. In 421 addition, the tunnel used MUST indicate UDP encapsulation for NAT 422 traversal. Hence, all packets addressed to the mobile node's home 423 address(es) (IPv4 or IPv6) will be encapsulated in UDP then 424 encapsulated an IPv4 header that includes the home agent's IPv4 425 address in the source address field and the mobile node's IPv4 care- 426 of address in the destination address field. 428 After accepting the binding updates and creating the corresponding 429 entries, the home agent MUST send a binding acknowledgement as 430 specified in [MIPv6]. In addition, if the binding update included an 431 IPv4 home address option, the binding acknowledgement MUST include 432 the IPv4 address acknowledgment option as described later in this 433 specification. The binding update is encapsulated in UDP then IPv4 434 with the home agent's IPv4 address in the source address field and 435 the mobile node's IPv4 care-of address in the destination field. The 436 inner IPv6 packet will contain the home agent's IPv6 address as a 437 source address and the mobile node's IPv4 care-of address in the 438 destination address field. The latter is represented as an IPv4- 439 mapped IPv6 address. 441 The mobile node needs to maintain the NAT bindings for its current 442 IPv4 care-of address. This is done through sending the binding update 443 regularly to the home agent. 445 2.4. Route optimization 447 Route optimization, as specified in [MIPv6] will operate in an 448 identical manner for dual stack mobile nodes when they are located in 449 a visited network that provides IPv6 addresses to the mobile node. 450 However, when located in an IPv4-only network, route optimization 451 will not be possible due to the difficulty of performing the care-of 452 address test. Therefore, mobile nodes will need to communicate 453 through the home agent. 455 Route optimization will not be possible for IPv4 traffic. That is, 456 traffic addressed to the mobile node's IPv4 home address. This is 457 similar to using Mobile IPv4, therefore there is no reduction of 458 features resulting from using this specification. 460 2.5. Dynamic IPv4 home address allocation 462 It is possible to allow for the mobile node's IPv4 home address to be 463 allocated dynamically. This is done by including 0.0.0.0 in the IPv4 464 home address option included in the binding update. The home agent 465 SHOULD allocate an IPv4 address to the mobile node and include it in 466 the IPv4 address acknowledgement option sent to the mobile node. In 467 this case, the lifetime of the binding is bound to the minimum of the 468 lifetimes of the IPv6 binding and the lease time of the IPv4 home 469 address. 471 3. Extensions and modifications to Mobile IPv6 473 This section highlights the protocol and implementation additions 474 required to support this specification. 476 3.1. Binding update extensions 478 3.1.1 IPv4 home address option 480 This option is included in the Mobility Header including the binding 481 update message sent from the mobile node to a home agent or Mobility 482 Anchor Point. 484 0 1 2 3 485 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 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | Type | Length | Pref | Res | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | IPv4 home address | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 Type TBD 494 Length 1 496 Pref The length of the prefix associated with the 497 home address. If only a single address is 498 needed/allowed, this field MUST be set to 32. 499 Otherwise, this field includes the IPv4 prefix 500 Length. 501 Res This field is reserved for future use. It MUST 502 be set to zero by the sender and ignored by the 503 receiver. 504 IPv4 home address The mobile node's IPv4 home address that should 505 be defended by the home agent. This field could 506 contain any unicast IPv4 address (public or 507 private) that was assigned to the mobile node. 508 The value 0.0.0.0 is used to request an IPv4 509 home address from the home agent. A prefix can 510 be requested if the unspecified address is used 511 and the requested prefix length is included in 512 the Pref field. 514 3.2. Binding acknowledgement extensions 516 3.2.1 IPv4 address acknowledgement option 518 This option is included in the Mobility Header including the binding 519 acknowledgement message sent from the home agent or Mobility Anchor 520 Point to the mobile node. This option indicates whether a binding 521 cache entry was created for the mobile node's IPv4 address. 522 Additionally, this option can include an IPv4 home address in case 523 the mobile node was not configured with one (i.e. if the unspecified 524 IPv4 address was included in the binding update). 526 0 1 2 3 527 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 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | Type | Length | Status | Pref | Res | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | IPv4 home address | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 Type TBD 536 Length 1 538 Status Indicates success or failure for the IPv4 home 539 address binding. Values from 0 to 127 indicate 540 success. Higher values indicate failure. The 541 following values are reserved: 542 0 Success 543 128 Failure, reason unspecified 544 129 Administratively prohibited 545 130 Incorrect IPv4 home address 546 131 Invalid IPv4 address 547 132 Dynamic IPv4 home address 548 assignment not available 550 Pref The prefix length of the address allocated. This 552 field is only valid in case of success and MUST 553 be ignored in case of failure. This field 554 overrides what the mobile node requested (i.e. 555 if not equal to the requested length). 557 Res This field is reserved for future use. It MUST 558 be set to zero by the sender and ignored by the 559 receiver. 561 IPv4 home address The IPv4 home address that the home agent will 562 use in the binding cache entry. This could be a 563 public or private address. This field MUST 564 contain the mobile node's IPv4 address. 565 If the address were dynamically allocated the 566 home agent will add the address to inform the 567 mobile node. Otherwise, if the address were 568 statically allocated to the mobile node, the 569 home agent will copy it from the binding update 570 message. 572 3.2.2 The NAT detection option 574 This option is sent from the home agent to the mobile node to 575 indicate whether a NAT was in the path. This option MAY also include 576 a suggested NAT binding refresh time for the mobile node. 578 0 1 2 3 579 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 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | Type | Length | Reserved | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | Refresh time | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 Type TBD 588 Length 1 590 Reserved This field is reserved for future use. It MUST 591 be set to zero by the sender and ignored by the 592 receiver. 594 Refresh time A suggested time (in seconds) for the mobile 595 node to refresh the NAT binding. If set to zero, 596 be ignored. 598 4. Protocol operation 600 This section presents the protocol operation and processing for the 601 messages presented above. In addition, this section introduces the 602 NAT detection and traversal mechanism used by this specification. 604 4.1. NAT detection and traversal 606 NAT detection is done when the initial binding update message is sent 607 from the mobile node to the home agent. When located in an IPv4-only 608 foreign link, the mobile node sends the binding update message is 609 sent encapsulated in UDP and IPv4. The source address of the IPv6 610 packet is the mobile node's IPv4 care-of address represented in IPv4- 611 mapped IPv6 format. The destination address is the IPv6 address of 612 the home agent. The IPv4 header contains the IPv4 care-of address in 613 the source address field and the IPv4 address of the home agent in 614 the destination address field. 616 When the home agent receives the encapsulated binding update it 617 compares the IPv4 address in the source address field in the IPv4 618 header with the IPv4 address in the source address of the IPv6 619 header. If the two addresses match, no NAT device was in the path. 620 Otherwise, a NAT device was in the path and the NAT detection option 621 is included in the binding acknowledgement. The binding 622 acknowledgement, and all future packets are then encapsulated in UDP 623 and IPv4. The source address in the IPv4 header is the IPv4 address 624 of the home agent. The destination address is the IPv4 address 625 received in the IPv4 header encapsulating the binding update (this 626 address will be different from the IPv4 care-of address if a NAT were 627 present in the path). 629 Upon receiving the binding acknowledgement with the NAT detection 630 option, the mobile node sets the tunnel to the home agent to UDP 631 encapsulation. Hence, all future packets to the home agent are 632 tunneled in UDP and IPv4. For all tunneled IPv6 packets, the source 633 address in the IPv6 header is the mobile node's IPv6 home address and 634 the destination address is the correspondent node's IPv6 address. All 635 tunneled IPv4 packets will contain the mobile node's IPv4 address in 636 the source address field of the inner IPv4 packet and the 637 correspondent node's IPv4 address in the destination address field. 638 The outer IPv4 header is the same whether the inner packet is IPv4 or 639 IPv6. 641 If no NAT device was detected in the path between the mobile node and 642 the home agent then IPv6 packets are tunneled in an IPv4 header. The 643 content of the inner and outer headers are identical to the UDP 644 encapsulation case. 646 Note that a mobile node MAY always tunnel binding updates in UDP when 647 located in an IPv4-only network. Essentially, this process allows for 648 perpetual NAT detection. Alternatively, the mobile node MAY only send 649 the first binding update in UDP and then remove the UDP header in 650 future binding updates if a NAT were not detected to reduce 651 overheads. This decision is left to the implementer's discretion. The 652 home agent MUST be able to receive both types of encapsulation. 654 In conclusion, the packet formats for the binding update and 655 acknowledgement messages are shown below: 657 A. Binding update received by the home agent: 659 IPv4 header (src=V4ADDR, dst=HAADDR) 660 UDP header 661 IPv6 header (src=V4CoA, dst=HAADDR) 662 DST-OPT 663 HAO (IPv6 home address) 664 Mobility header 665 BU [IPv4 HAO] 667 Where V4ADDR is either the IPv4 care-of address or the address 668 provided by the NAT device. V4COA is the IPv4 care-of address of the 669 mobile node. HAO is the home address option and BU is the binding 670 update, which MAY contain the IPv4 home address option. 672 B. Binding acknowledgement sent by the home agent: 673 IPv4 header (src=V4ADDR, dst=HAADDR) 674 [UDP header] (If V4ADDR != V4CoA) 675 IPv6 header (src=V4CoA, dst=HAADDR) 676 Route HRD Type 2 677 HOA (IPv6 home address) 678 Mobility header 679 BA ([IPv4 ACK], NAT DET) 681 Where HOA is IPv6 home address of the mobile node. The IPv4 ACK is 682 the IPv4 address acknowledgement option, which is only included if 683 the IPv4 home address option were present in the BU. The NAT DET is 684 the NAT detection option, which MUST be present in the binding 685 acknowledgement message if the binding update was encapsulated in 686 UDP. 688 4.2. Mobile node operation 690 In addition to the operations specified in [MIPv6] and [NEMO], this 691 specification requires mobile nodes to be able to support an IPv4 692 home address. The IPv4 home address is never sent in the IPv4-mapped 693 IPv6 address format. This is primarily done to save bandwidth. 694 However, to simplify the mobile node's implementation, they may store 695 the IPv4 home address in the binding update list, using the IPv4- 696 mapped IPv6 format. 698 When sending an IPv6 packet containing a binding update while 699 connected to an IPv4-only access network, mobile nodes MUST ensure 700 the following: 702 - The IPv6 packet is encapsulated in UDP and an IPv4 packet. 703 - The source address in the IPv4 header is the mobile node's IPv4 704 care-of address 705 - The destination address in the IPv4 header is the home agent's 706 IPv4 address. 707 - The source address in the IPv6 header is the mobile node's IPv4- 708 mapped IPv6 address. That is, the same IPv4 address in the outer 709 header is placed in the IPv6 header using the mapped address 710 format. 711 - The home address option contains the IPv6 home address as 712 specified in [MIPv6]. 713 - The IPv4 home address option MAY be included in the mobility 714 header. This option contains the IPv4 home address. If the mobile 715 node did not have a static home address it MAY include the 716 unspecified IPv4 address, which acts as a request for a dynamic 717 IPv4 home address. 718 - The IPv6 packet MUST be authenticated as per [MIPv6], based on the 719 mobile node's IPv6 home address. 721 When sending a binding update from a visited network that supports 722 IPv6, the mobile node MUST follow the rules specified in [MIPv6]. In 723 addition, if the mobile node has an IPv4 home address or needs one, 724 it should include the IPv4 home address option in the mobility 725 header. If the mobile node already has a static IPv4 home address, 726 such address MUST be included in the IPv4 home address option. 727 Otherwise, if the mobile node needs a dynamic IPv4 address, it should 728 include the IPv4 unspecified address in the IPv4 home address option. 730 When the mobile node receives a binding acknowledgement from the home 731 agent, it should follow the rules in [MIPv6] and [NEMO]. In addition, 732 the following actions MUST be made: 734 - If the mobility header includes and IPv4 address acknowledgement 735 option indicating success, the mobile node should create two 736 entries in its binding update list, one for the IPv6 home address 737 and another for the IPv4 home address. 738 - If the NAT detection option were present, the mobile node 739 MUST tunnel future packets in UDP and IPv4. This MUST be indicated 740 in the binding update list. 741 - If no IPv4 address acknowledgement option were present, and an 742 IPv4 home address option was present in the binding update, the 743 mobile node MUST only create one binding update list entry for its 744 IPv6 home address. The mobile node MAY include the IPv4 home 745 address option in future binding updates. 746 - If an IPv4 address acknowledgement option were present and it 747 indicates failure for the IPv4 home address binding, the mobile 748 node MUST NOT create an entry for that address in its binding 749 update list. The mobile node MAY include the IPv4 home address 750 option in future binding updates. 752 Note that a mobile node complying with this specification MUST 753 configure an IPv4-mapped IPv6 address on its interface in the visited 754 network. This is needed in order to allow the mobile node to receive 755 binding acknowledgements from its home agent while located in an 756 IPv4-only network. 758 4.3. Home agent operations 760 In addition to the home agent specification in [MIPv6] and [NEMO], 761 the home agent needs to be able to process the IPv4 home address 762 option and generate the IPv4 address acknowledgement option. Both 763 options are included in the mobility header. Furthermore, the home 764 agent MUST be able to detect the presence of a NAT device and 765 indicate that in the NAT detection option included in the binding 766 acknowledgement. 768 In order to comply with this specification, the home agent MUST be 769 able to find the IPv4 home address of a mobile node when given the 770 IPv6 home address. That is, given an IPv6 home address, the home 771 agent MUST store the corresponding IPv4 home address if a static one 772 is present. If a dynamic address were requested by the mobile node, 773 the home agent MUST store that address (associated with the IPv6 home 774 address) after it's allocated to the mobile node. 776 When the home agent receives a binding update encapsulated in UDP and 777 containing the IPv4 home address option, it needs to follow all the 778 steps in [MIPv6] and [NEMO], in addition, the following checks MUST 779 be done: 781 - If the IPv4 care-of address in the IPv6 header is not the same as 782 the IPv4 address in the source address in the IPv4 header then a 783 NAT was in the path. This information should be flagged for the 784 binding acknowledgement. 786 - If the IPv4 home address option contains a valid unicast IPv4 787 address, the home agent MUST check that this address is allocated 788 to the mobile node that has the IPv6 home address included in the 789 home address option. The same MUST be done for an IPv4 prefix. 791 - If the IPv4 home address option contained the unspecified IPv4 792 address, the home agent SHOULD dynamically allocate an IPv4 home 793 address to the mobile node. If none is available, the home agent 794 MUST return an appropriate error code in the status field of the 795 IPv4 address acknowledgement option. If a prefix were requested, 796 the home agent MUST allocate a prefix with the requested length; 797 otherwise the home agent MUST indicate failure of the operation 798 with the appropriate error code. 800 - If the binding update is accepted for the IPv4 home address, the 801 home agent MUST create a binding cache entry for the IPv4 home 802 address/prefix. If a single IPv4 home address were requested, it 803 MAY be stored in the IPv4-mapped IPv6 address format. The home 804 agent MUST include an IPv4 acknowledgement option in the mobility 805 header containing the binding acknowledgement. 807 If the binding update is accepted for both IPv4 and IPv6 home 808 addresses, the home agent MUST create two separate binding cache 809 entries, one for each home address. The care-of address is the one 810 included in the binding update. If the care-of address is an IPv4- 811 mapped IPv6 address, the home agent MUST setup a tunnel to the IPv4 812 care-of address of the mobile node. 814 When sending a binding acknowledgement to the mobile node, the home 815 agent would construct the message according to [MIPv6] and [NEMO]. 816 Note that the routing header MUST always contain the IPv6 home 817 address as specified in [MIPv6]. 819 If the care-of address of the mobile node were an IPv4 address, the 820 home agent MUST include this address in the destination address in 821 the IPv6 header using the IPv4-mapped IPv6 format. If a NAT were 822 detected, the home agent MUST then encapsulate the packet in UDP and 823 an IPv4 header. The source address is set to the home agent's IPv4 824 address and the destination address is set to the address received in 825 the source address of the IPv4 header encapsulating the binding 826 update. 828 After creating a binding cache entry for the mobile node's home 829 addresses. All packets sent to the mobile node's home addresses are 830 tunneled by the home agent to the mobile node's care-of address. If a 831 NAT were detected, packets are encapsulated in UDP and IPv4. 832 Otherwise, if the care-of address is an IPv4 address, and no NAT were 833 detected, packets are encapsulated in an IPv4 header. 835 4.4. Correspondent node operations 837 This specification has no impact on IPv4 or IPv6 correspondent nodes. 839 5. Security considerations 841 This specification allows a mobile node to send one binding update 842 for its IPv6 and IPv4 home addresses. This is a slight deviation from 843 [MIPv6] which requires one binding update per home address. However, 844 like [MIPv6], the IPsec security association needed to authenticate 845 the binding update is still based on the mobile node's IPv6 home 846 address. Therefore, in order to authorize the mobile node's IPv4 home 847 address binding, the home agent MUST store the IPv4 address 848 corresponding to the IPv6 address that is allocated to a mobile node. 849 Therefore, it is sufficient for the home agent to know that the IPsec 850 verification for the packet containing the binding update was valid 851 provided that it knows which IPv4 home address is associated with 852 which IPv6 home address. Hence, the security of the IPv4 home address 853 binding is the same as the IPv6 binding. 855 In effect, associating the mobile node's IPv4 home address with its 856 IPv6 home address moves the authorization of the binding update for 857 the IPv4 address to the Mobile IPv6 implementation, which infers it 858 from the fact that mobile node has an IPv6 home address and the right 859 credentials for sending an authentic binding update for such address. 861 6. Protocol constants 863 NATKATIMEOUT 30 seconds 865 7. Acknowledgements 867 TBD 869 8. IANA considerations 871 The specification requires the following allocations from IANA: 872 - A UDP port is needed for the NAT traversal mechanism described in 873 section 4.1. 874 - The IPv4 home address option described in section 3.1.1 requires an 875 option type. This option is included in the Mobility header 876 described in [MIPv6]. 877 - The IPv4 address acknowledgement option described in section 3.2.1 878 requires a new option type. This option is included in the Mobility 879 header described in [MIPv6]. 880 - The NAT detection option described in section 3.2.2 requires a new 881 option type. This option is included in the Mobility header 882 described in [MIPv6]. 884 9. References 886 [BOOT] Giaretta, G. (Ed.), Kempf J., and V. Devarapalli, " Mobile 887 IPv6 bootstrapping in split scenario", draft-ietf-mip6- 888 bootstrapping-split, June 2005, work in progress. 890 [HMIPv6] Soliman, H., Castelluccia, C., ElMalki, K., and L. Bellier, 891 "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", 892 RFC 4140, August 2005. 894 [IPv6] S. Deering and B. Hinden, "Internet Protocol version 6 (IPv6) 895 specification", RFC 2460 897 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 898 Requirement Levels", BCP 14, RFC 2119, March 1997. 900 [MIP-PB] Tsirtsis, G., and H. Soliman, "Mobility management for 901 Dual stack mobile nodes, A Problem Statement", 902 draft-ietf-mip6-dsmip-problem-01.txt, July 2005. 904 [MIPv4] C. Perkins, "Mobility Support for IPv4", RFC3344 906 [MIPv6] D. Johnson, C. Perkins and J. Arkko, "Mobility Support in 907 IPv6", RFC 3775, June 2004. 909 [NEMO] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 910 " Network Mobility (NEMO) Basic Support protocol", RFC 3963, 911 January 2005. 913 [SEC] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 914 Protoect Mobile IPv6 Signaling between Mobile Nodes and Home 915 Agents", RFC 3776, June 2004. 917 [SNRIO] Larsson, T., Gustafsson, E., and H. Levkowetz, "Use of MIPv6 918 in IPv4 and MIPv4 in IPv6 networks", draft-larsson-v6ops- 919 mip-scenarios-01.txt, February 2004. 921 Authors' Addresses 923 Hesham Soliman 924 Flarion Technologies 925 Phone: +1 908 997 9775 926 E-mail: H.Soliman@Flarion.com 928 George Tsirtsis 929 Flarion Technologies 930 Phone: +1 908 947 7059 931 E-mail1: G.Tsirtsis@Flarion.com 932 E-mail2: tsirtsisg@yahoo.com 934 Vijay Devarapalli 935 313 Fairchild Drive 936 Mountain View, CA 94043 937 E-mail: vijay.devarapalli@nokia.com 939 DoCoMo Labs USA 940 181 Metro Drive 941 Suite 300 942 San Jose, CA 943 95110 944 E-mail: kempf@docomolabs-usa.com 946 Henrik Levkowetz 947 Ericsson Research 948 Torshamsgatan 23 949 S-164 80 Stockholm 950 SWEDEN 951 Phone: +46 7 08 32 16 08 952 E-mail: henrik@levkowetz.com 954 Pascal Thubert 955 Cisco Systems 956 Village d'Entreprises Green Side 957 400, Avenue de Roumanille 958 Batiment T3 959 Biot - Sophia Antipolis 960 06410 961 FRANCE 962 Phone: +33 4 97 23 26 34 963 E-mail: pthubert@cisco.com 965 Wakikawa Ryuji 966 Keio University 967 Department of Environmental Information, 968 Keio University. 969 5322 Endo 970 Fujisawa, 971 Kanagawa 252-8520 972 Japan 974 Phone: +81-466-49-1100 975 Fax: +81-466-49-1395 976 E-mailryuji@sfc.wide.ad.jp 977 Web: http://www.wakikawa.org/ 979 Intellectual Property Statement 981 The IETF takes no position regarding the validity or scope of any 982 Intellectual Property Rights or other rights that might be claimed to 983 pertain to the implementation or use of the technology described in 984 this document or the extent to which any license under such rights 985 might or might not be available; nor does it represent that it has 986 made any independent effort to identify any such rights. Information 987 on the IETF's procedures with respect to rights in IETF Documents can 988 be found in RFC 3667 (BCP 78) and RFC 3668 (BCP 79). 990 Copies of IPR disclosures made to the IETF Secretariat and any 991 assurances of licenses to be made available, or the result of an 992 attempt made to obtain a general license or permission for the use of 993 such proprietary rights by implementers or users of this 994 specification can be obtained from the IETF on-line IPR repository at 995 http://www.ietf.org/ipr. 997 The IETF invites any interested party to bring to its attention any 998 copyrights, patents or patent applications, or other proprietary 999 rights that may cover technology that may be required to implement 1000 this standard. Please address the information to the IETF at ietf- 1001 ipr@ietf.org. 1003 Full Copyright Statement 1004 Copyright (C) The Internet Society (2005). This document is subject 1005 to the rights, licenses and restrictions contained in BCP 78, and 1006 except as set forth therein, the authors retain all their rights. 1008 Disclaimer of Validity 1010 This document and the information contained herein are provided on an 1011 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1012 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1013 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1014 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1015 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1016 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1018 This Internet-Draft expires April, 2006.