idnits 2.17.1 draft-ietf-mip6-nemo-v4traversal-05.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1311. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1290. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1296. ** 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 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 IETF Trust 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). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The mobile node negotiates the format for tunnelling payload traffic during the binding exchange. If a mobile node prefers to use the TLV-header UDP encapsulation, it sets the T flag in the binding update sent to the home agent or MAP. If the receiver of the binding update supports the TLV-header format, it SHOULD set the T flag in the binding acknowledgement message. Otherwise, the T flag is cleared. The setting of the T flag in the binding acknowledgement indicates to the mobile node that it must use the TLV-header UDP encapsulation format for all packets sent for the duration of the binding or until a new binding update is sent. Each binding update may renegotiate the tunnelling format. To avoid interoperability issues, the sender of the binding acknowledgement MUST not set the T flag unless it was set in the binding update sent from the mobile node. -- 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 847, but not defined == Missing Reference: 'IPv4 ACK' is mentioned on line 862, but not defined == Missing Reference: 'DNAv4' is mentioned on line 1006, but not defined == Unused Reference: 'IPv6' is defined on line 1213, but no explicit reference was found in the text == Unused Reference: 'KEYWORDS' is defined on line 1220, but no explicit reference was found in the text == Unused Reference: 'MIPv4' is defined on line 1227, but no explicit reference was found in the text == Unused Reference: 'SEC' is defined on line 1236, 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 (-06) exists of draft-ietf-mip6-bootstrapping-integrated-dhc-02 == 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: 10 errors (**), 0 flaws (~~), 13 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIP6 Working Group Hesham Soliman (Ed.) 3 INTERNET-DRAFT Elevate Technologies 4 Expires: January 2008 5 July, 2007 7 Mobile IPv6 support for dual stack 8 Hosts and Routers (DSMIPv6) 9 draft-ietf-mip6-nemo-v4traversal-05.txt 11 Status of this memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or cite them other than as "work in progress". 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/lid-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This document is a submission of the IETF MIP6 WG. Comments should be 34 directed to the IPv6 WG mailing list, mip6@ietf.org. 36 Abstract 38 The current Mobile IPv6 and NEMO specifications support IPv6 only. 39 This specification extends those standards to allow the registration 40 of IPv4 addresses and prefixes, respectively, and the transport of 41 both IPv4 and IPv6 packets over the tunnel to the HA. This 42 specification also allows the Mobile Node to roam over both IPv6 and 43 IPv4, including the case where Network Address Translation is present 44 on the path between the mobile node and its home agent. 46 Table of Contents 48 1. Introduction.....................................................2 49 1.1 Motivation for using Mobile IPv6 only...........................3 50 1.2 Scenarios considered by this specification...................4 51 2. Solution overview................................................5 52 2.1. Home Agent Address Discovery...................................5 53 2.2. Mobile Prefix Solicitations and Advertisements..............6 54 2.3. Binding management.............................................7 55 2.3.1 Foreign network supports IPv6.................................7 56 2.3.2 Foreign network supports IPv4 only............................8 57 2.3.2.2 Visited network supports IPv4 only (private addresses)......9 58 2.4. Route optimization............................................10 59 2.5. Dynamic IPv4 home address allocation..........................10 60 3. Extensions and modifications to Mobile IPv6.....................10 61 3.1. Binding update extensions.....................................10 62 3.1.1 IPv4 home address option.....................................10 63 3.1.2 The IPv4 Care-of Address option........................11 64 3.1.3 The Binding Update Message extensions..................12 65 3.2. Binding Acknowledgement extensions............................12 66 3.2.1 IPv4 address acknowledgement option..........................12 67 3.2.2 The NAT detection option...............................13 68 3.2.3 Extensions to the Binding Acknowledgement message......14 69 4. Protocol operation..............................................14 70 4.1. Tunnelling formats.........................................15 71 4.2. NAT detection and traversal................................16 72 4.3. NAT Keepalives.............................................18 73 4.4. Mobile node operation.........................................18 74 4.4.1 Sending packets from a visited network.................20 75 4.4.2 Movement detection in IPv4-only networks...............20 76 4.5. Home agent operations.........................................21 77 4.5.1 Sending packets to the mobile node.....................22 78 4.6. Correspondent node operations.................................23 79 5. Security considerations.........................................23 80 6. Protocol constants..............................................24 81 7. Acknowledgements................................................24 82 8. IANA considerations.............................................24 83 9. References......................................................24 84 10. Contributors...................................................25 85 Author's Address...................................................26 87 1. Introduction 89 Mobile IPv6 [MIPv6] and [NEMO] allow mobile nodes to move within the 90 Internet while maintaining reachability and ongoing sessions, using 91 an IPv6 home address or prefix. However, since IPv6 is not widely 92 deployed, it is unlikely that mobile nodes will use IPv6 addresses 93 only for their connections. It is reasonable to assume that mobile 94 nodes will, for a long time, need an IPv4 home address that can be 95 used by upper layers. It is also reasonable to assume that mobile 96 nodes will move to networks that might not support IPv6 and would 97 therefore need the capability to support an IPv4 Care-of Address. 98 Hence, this specification extends Mobile IPv6 capabilities to allow 99 dual stack mobile nodes to request that their home agent (also dual 100 stacked) tunnel IPv4/IPv6 packets addressed to their home addresses, 101 to their IPv4/IPv6 care-of address(es). 103 Using this specification, mobile nodes would only need Mobile IPv6 104 and [NEMO] to manage mobility while moving within the Internet; hence 105 eliminating the need to run two mobility management protocols 106 simultaneously. This specification provides the extensions needed in 107 order to allow Mobile IPv6 only to be used by dual sack mobile nodes. 109 This specification will also consider cases where a mobile node moves 110 into a private IPv4 network and gets configured with a private IPv4 111 Care-of Address. In those scenarios, the mobile node needs to be able 112 to traverse the IPv4 NAT in order to communicate with the Home Agent. 113 IPv4 NAT traversal for Mobile IPv6 is presented in this 114 specification. 116 In this specification, the term mobile node refers to both a mobile 117 host and mobile router unless the discussion is specific to either 118 hosts or routers. Similarly, we use the term home address to reflect 119 an address/prefix format. 121 In this specification, extensions are defined for the binding update 122 and binding acknowledgement. It should be noted that all these 123 extensions apply to cases where the mobile node communicates with a 124 Mobility Anchor Point (MAP) as defined in [HMIPv6]. The requirements 125 on the MAP are identical to those stated for the home agent, although 126 it is unlikely that NAT traversal would be needed with a MAP as it is 127 expected to be in the same address domain. 129 1.1 Motivation for using Mobile IPv6 only 131 IPv6 offers a number of improvements over today's IPv4, primarily due 132 to its large address space. Mobile IPv6 offers a number of 133 improvements over Mobile IPv4, mainly due to capabilities inherited 134 from IPv6. For instance, route optimization and Dynamic home agent 135 discovery can only be achieved with Mobile IPv6. 137 One of the advantages of the large address space provided by IPv6 is 138 that it allows mobile nodes to obtain a globally unique care-of 139 address wherever they are. Hence, there is no need for Network 140 Address Translator (NAT) traversal techniques designed for Mobile 141 IPv4. This allows Mobile IPv6 to be a significantly simpler and more 142 bandwidth efficient mobility management protocol. At the same time, 143 during the transition towards IPv6, NAT traversal for existing 144 private IPv4 networks needs to be considered. This specification 145 introduces NAT traversal for this purpose. 147 The above benefits make the case for using Mobile IPv6 only for dual 148 stack mobile nodes in order to allow for a long lasting mobility 149 solution and minimize the need to changing the mobility stack due to 150 the introduction of IPv6 within a deployed network. 152 1.2 Scenarios considered by this specification 154 In [SNRIO] several scenarios that illustrate potential 155 incompatibilities for mobile nodes using Mobile IPv6 were discussed. 156 Some of the problems associated with mobility and transition issues 157 were presented in [MIP-PB]. This specification considers a subset of 158 the scenarios in [SNRIO], which address all the problems discussed in 159 [MIP-PB]. The scenarios considered in this specification are listed 160 below. 162 All of the following scenarios assume that both the mobile node and 163 the Home Agent are IPv4 and IPv6-enabled and that only Mobile IPv6 is 164 used between the mobile node and the Home Agent. We also assume that 165 the Home Agent is always reachable through a globally unique IPv4 166 address. Finally, it's important to note that the following scenarios 167 are not mutually exclusive. 169 Scenario 1: IPv4-only foreign network 171 In this scenario, a mobile node is connected to an IPv4-only foreign 172 network. The mobile node can only configure an IPv4 Care-of Address. 174 Scenario 2: Mobile node behind a NAT 176 In this scenario, the mobile node is in a private IPv4 foreign 177 network that has a NAT device connecting it to the Internet. If the 178 Home Agent is located outside the NAT device, the mobile node will 179 need a NAT traversal mechanism to communicate with the Home Agent. 181 Scenario 3: Home Agent behind a NAT 183 In this scenario, the communication between the mobile node and the 184 Home Agent is further complicated by the fact that the Home Agent is 185 located within a private IPv4 network. However, in this scenario, we 186 assume that the Home Agent is allocated a globally unique IPv4 187 address. Such address might not be physically configured on the Home 188 Agent interface. Instead, it is associated with the Home Agent on the 189 NAT device, which allows the Home Agent to be reachable through 190 address or port mapping. 192 Scenario 4: Use Of IPv4-only applications 194 In this scenario, the mobile node may be located in an IPv4, IPv6 or 195 a dual network. However, the mobile node might be communicating with 196 an IPv4-only node. In this case, the mobile node would need a stable 197 IPv4 address for its application. The alternative to using an IPv4 198 address is the use of protocol translators; however, end-to-end 199 communication with IPv4 is preferred to the use of protocol 200 translators. 202 The mobile node may also be communicating with an IPv4-only 203 application that requires an IPv4 address. 205 The cases above illustrate the need for a stable IPv4 home address to 206 be allocated to the mobile node. This is done using an IPv4 home 207 address. Since running Mobile IPv4 and Mobile IPv6 simultaneously is 208 problematic (as illustrated in [MIP-PB]), this scenario adds a 209 requirement on Mobile IPv6 to support IPv4 home addresses. 211 2. Solution overview 213 In order to allow Mobile IPv6 to be used by dual stack mobile nodes, 214 the following needs to be done: 216 - Mobile nodes should be able to use an IPv4 and IPv6 home or care-of 217 address simultaneously and update their home agents accordingly. 219 - Mobile nodes need to be able to know the IPv4 address of the home 220 agent as well as its IPv6 address. There is no need for IPv4 prefix 221 discovery however. 223 - Mobile nodes need to be able to detect the presence of a NAT device 224 and traverse such device in order to communicate with the Home Agent 225 in a secure manner. 227 This section presents an overview of the extensions required in order 228 to allow mobile nodes to use Mobile IPv6 only for IP mobility 229 management. 231 2.1. Home Agent Address Discovery 233 Dynamic Home Agent Address Discovery (DHAAD) was defined in [MIPv6] 234 to allow mobile nodes to discover their home agents by appending a 235 well-known anycast interface identifier to their home link's prefix. 236 However, this mechanism is based on IPv6-anycast routing. If a mobile 237 node is located in an IPv4-only foreign network, it cannot rely on 238 native IPv6 routing. In this scenario, the solution for discovering 239 the home agent's IPv4 address is through the Domain Name System 240 (DNS). If the MN is attached to an IPv6-only or dual stack network, 241 it may also use procedures defined in [INTBOOT] to discover Home 242 Agent information. Note that the use of [INTBOOT] cannot give the 243 mobile node information that allows it to continue to communicate 244 with the Home Agent if, for example, the mobile node moved from an 245 IPv6-enabled network to an IPv4-only network. In such scenario, the 246 mobile node would need to discover the IPv4 address of its home agent 247 through the DNS. 249 For DNS lookup by name, the mobile node should be configured with the 250 name of the home agent. When the mobile node needs to discover a 251 home agent, it sends a DNS request with QNAME set to the configured 252 name. An example is "ha1.example.com". If a home agent has an IPv4 253 and IPv6 address, the corresponding DNS record should be configured 254 with both 'AAAA' and 'A' records. Accordingly the DNS reply will 255 contain 'AAAA' and 'A' records. 257 For DNS lookup by service, the SRV record defined in [BOOT] is 258 reused. For instance, if the service name is "mip6ha" and the 259 protocol name is "ipv6" for the SRV record, the mobile node SHOULD 260 send a DNS request with the QNAME set to "mip6ha.ipv6.example.com". 261 The response should contain the home agent's FQDN(s) and may have the 262 corresponding 'AAAA' and 'A' records enclosed as well. 264 If multiple home agents reside on the home link, each configured with 265 a public IPv4 addresses, then the operation above applies. In case 266 the home agents are behind a NAT box, there are two options, 1) 267 configure a public IPv4 address for each home agent on the NAT box, 268 2) configure one public address and make the home agents share the 269 public address. In either case, the correct DNS entries can be 270 configured. Another possible solution is to designate one home agent 271 on the home link for v4 traversal. The NAT device should associate 272 that home agent with the public IPv4 address configured on it for v4 273 traversal. In all cases above, both the 'AAAA' and 'A' records 274 returned for a particular name MUST correspond to the same physical 275 home agent; otherwise the mobile node will not be able to bind its 276 addresses correctly. 278 2.2. Mobile Prefix Solicitations and Advertisements 280 According to [MIPv6], the mobile node can send a Mobile Prefix 281 Solicitation and receive a Mobile Prefix Advertisement containing all 282 prefixes advertised on the home link. 284 A dual stack mobile node MAY send a Mobile Prefix Solicitation 285 message encapsulated in IPv4 (i.e. IPv6 in IPv4) in the case where 286 the mobile node has no access to IPv6 within the local network. 287 Securing such messages would require the mobile node to have security 288 association with the home agent, using IPsec (AH or ESP) and based on 289 the mobile node's IPv4 care-of address as described in [MIPv6]. Since 290 the mobile node needs to encapsulate all IPv6 traffic sent to the 291 home agent into IPv4 while located in an IPv4-only visited network, 292 such SA would affect all packets if the selectors were based on the 293 information in the outer header. That is, the SA selectors being the 294 protocol number (protocol is always IP in IP), as well as, source and 295 destination addresses are all common to all packets. If this effect 296 is not desired, the mobile node can base the SA on the information in 297 the inner header (i.e. using the home agent's IPv6 address, the 298 mobile node's home address and the ICMP protocol number). Such 299 security association would use transport mode ESP protection. 301 2.3. Binding management 303 A dual stack mobile node will need to update its home agent with its 304 care-of address. If a mobile node has an IPv4 and an IPv6 home 305 address it will need to create a binding cache entry for each 306 address. The format of the IP packet carrying the binding update and 307 acknowledgement messages will vary depending on whether the mobile 308 node has access to IPv6 in the visited network. There are three 309 different scenarios to consider with respect to the visited network: 311 A. The visited network has IPv6 connectivity and provides the mobile 312 node with a care-of address (in a stateful or stateless manner). 314 B. The mobile node can only configure a globally unique IPv4 address 315 in the visited network. 316 C. The mobile node can only configure a private IPv4 address in the 317 visited network. 319 2.3.1 Foreign network supports IPv6 321 In this case, the mobile node is able to configure a globally unique 322 IPv6 address. The mobile node will send a binding update to the IPv6 323 address of its home agent, as defined in [MIPv6]. The binding update 324 MAY include the IPv4 home address option introduced in this document. 325 After receiving the binding update, the home agent creates two 326 binding cache entries, one for the mobile node's IPv4 home address, 327 and another for the mobile node's IPv6 home address. Both entries 328 will point to the mobile node's IPv6 care-of address. Hence, whenever 329 a packet is addressed to the mobile node's IPv4 or IPv6 home 330 addresses, it will be tunneled in IPv6 to the mobile node's IPv6 331 care-of address included in the binding update. Effectively, the 332 mobile node establishes two different tunnels, one for its IPv4 333 traffic (IPv4 in IPv6) and one for its IPv6 traffic (IPv6 in IPv6) 334 with a single binding update. The security implications of this 335 mechanism are discussed in the security considerations section. 337 In this scenario, the only addition to [MIPv6] is the inclusion of 338 the IPv4 home address option in the binding update message. 340 After accepting the binding update and creating the corresponding 341 binding cache entries, the home agent MUST send a binding 342 acknowledgement to the mobile node as defined in [MIPv6]. In 343 addition, if the binding update included an IPv4 home address option, 344 the binding acknowledgement MUST include the IPv4 address 345 acknowledgment option as described later in this specification. This 346 option informs the mobile node whether the binding was accepted for 347 the IPv4 home address. If this option is not included in the binding 348 acknowledgement and the IPv4 home address option was included in the 349 binding update, the mobile node MUST assume that the home agent does 350 not support the IPv4 home address option and therefore SHOULD NOT 351 include the option in future binding updates to that home agent 352 address. 354 The routing header in the binding update MUST include the mobile 355 node's IPv6 home address as specified in [MIPv6]. 357 When a mobile node acquires both IPv4 and IPv6 care-of addresses at 358 foreign network, it SHOULD prioritize IPv6 care-of address for MIP6 359 binding registration. The mobile node MUST NOT register both IPv4 and 360 IPv6 care-of addresses to its home agent. 362 2.3.2 Foreign network supports IPv4 only 364 If the mobile node is in a foreign network that only supports IPv4, 365 it needs to detect whether a NAT is in its communication path to the 366 home agent. This is done while exchanging the binding update and 367 acknowledgement messages as shown later in this document. If no NAT 368 is detected between the mobile node and the home agent, the mobile 369 node assumes that it is in a foreign network that supports IPv4 370 public addresses. Otherwise, the mobile node assumes that private 371 addresses are used in the foreign network. Note that this assumption 372 is only valid for the purposes of the signaling presented in this 373 specification. A mobile node SHOULD NOT assume that its IPv4 address 374 is globally unique if a NAT device was not detected. The operations 375 of both cases are discussed below. 377 2.3.2.1 Foreign network supports IPv4 only (public addresses) 379 In this scenario the mobile node will need to tunnel IPv6 packets 380 containing the binding update to the home agent's IPv4 address. The 381 mobile node uses the IPv4 address it gets from the foreign network as 382 a source address in the outer header. The binding update will contain 383 the mobile node's IPv6 home address. However, since the care-of 384 address in this scenario is the mobile node's IPv4 address, the 385 mobile node MUST include its IPv4 care-of address in the IPv6 packet. 386 The IPv4 address is represented in the IPv4 Care-of address option 387 defined in this specification. If the mobile node had an IPv4 home 388 address, it MUST also include the IPv4 home address option described 389 in this specification. 391 After accepting the binding update, the home agent MUST create a new 392 binding cache entry for the mobile node's IPv6 home address. If an 393 IPv4 home address option were included, the home agent MUST create 394 another entry for that address. All entries MUST point to the mobile 395 node's IPv4 care-of address. Hence, all packets addressed to the 396 mobile node's home address(es) (IPv4 or IPv6) will be encapsulated in 397 an IPv4 header that includes the home agent's IPv4 address in the 398 source address field and the mobile node's IPv4 care-of address in 399 the destination address field. 401 After accepting the binding updates and creating the corresponding 402 entries, the home agent MUST send a binding acknowledgement as 403 specified in [MIPv6]. In addition, if the binding update included an 404 IPv4 home address option, the binding acknowledgement MUST include 405 the IPv4 address acknowledgment option as described later in this 406 specification. The binding update is encapsulated to the IPv4 care-of 407 address (represented as an IPv4-mapped IPv6 address in the binding 408 update). 410 2.3.2.2 Visited network supports IPv4 only (private addresses) 412 In this scenario the mobile node will need to tunnel IPv6 packets 413 containing the binding update to the home agent's IPv4 address. In 414 order to traverse the NAT device, IPv6 packets are tunneled UDP and 415 IPv4. The UDP port allocated for the home agent is TBD. 417 The mobile node uses the IPv4 address it gets from the visited 418 network as a source address in the IPv4 header. The binding update 419 will contain the mobile node's IPv6 home address. 421 After accepting the binding update, the home agent MUST create a new 422 binding cache entry for the mobile node's IPv6 home address. If an 423 IPv4 home address option were included, the home agent MUST create 424 another entry for that address. All entries MUST point to the mobile 425 node's IPv4 care-of address included in the source address of the 426 IPv6 packet and represented as an IPv4-mapped IPv6 address. In 427 addition, the tunnel used MUST indicate UDP encapsulation for NAT 428 traversal. Hence, all packets addressed to the mobile node's home 429 address(es) (IPv4 or IPv6) will be encapsulated in UDP then 430 encapsulated in an IPv4 header that includes the home agent's IPv4 431 address in the source address field and the mobile node's IPv4 care- 432 of address in the destination address field. 434 After accepting the binding updates and creating the corresponding 435 entries, the home agent MUST send a binding acknowledgement as 436 specified in [MIPv6]. In addition, if the binding update included an 437 IPv4 home address option, the binding acknowledgement MUST include 438 the IPv4 address acknowledgment option as described later in this 439 specification. The binding acknowledgement is encapsulated in UDP 440 then IPv4 with the home agent's IPv4 address in the source address 441 field and the mobile node's IPv4 care-of address in the destination 442 field. The IPv4 address in the destination field of the IP v4 packet 443 is the source address received in the IPv4 header containing the 444 binding update message. The inner IPv6 packet will contain the home 445 agent's IPv6 address as a source address and the mobile node's IPv6 446 home address in the destination address field. 448 The mobile node needs to maintain the NAT bindings for its current 449 IPv4 care-of address. This is done through sending the binding update 450 regularly to the home agent. 452 2.4. Route optimization 454 Route optimization, as specified in [MIPv6] will operate in an 455 identical manner for dual stack mobile nodes when they are located in 456 a visited network that provides IPv6 addresses to the mobile node. 457 However, when located in an IPv4-only network, route optimization 458 will not be possible due to the difficulty of performing the care-of 459 address test. Therefore, mobile nodes will need to communicate 460 through the home agent. 462 Route optimization will not be possible for IPv4 traffic. That is, 463 traffic addressed to the mobile node's IPv4 home address. This is 464 similar to using Mobile IPv4, therefore there is no reduction of 465 features resulting from using this specification. 467 2.5. Dynamic IPv4 home address allocation 469 It is possible to allow for the mobile node's IPv4 home address to be 470 allocated dynamically. This is done by including 0.0.0.0 in the IPv4 471 home address option included in the binding update. The home agent 472 SHOULD allocate an IPv4 address to the mobile node and include it in 473 the IPv4 address acknowledgement option sent to the mobile node. In 474 this case, the lifetime of the binding is bound to the minimum of the 475 lifetimes of the IPv6 binding and the lease time of the IPv4 home 476 address. 478 3. Extensions and modifications to Mobile IPv6 480 This section highlights the protocol and implementation additions 481 required to support this specification. 483 3.1. Binding update extensions 485 3.1.1 IPv4 home address option 487 This option is included in the Mobility Header including the binding 488 update message sent from the mobile node to a home agent or Mobility 489 Anchor Point. The alignment requirement for this option is 4n. 491 0 1 2 3 492 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 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Type | Length |Pref |P| Reserved | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | IPv4 home address | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 Type TBD 501 Length 6 502 Pref The length of the prefix allocated to the mobile 503 node. If only a single address is allocated, 504 this field MUST be set to 32. In the first 506 binding update requesting a prefix, the field 507 contains the prefix length requested. However, 508 in the following binding updates, this field 509 must contain the length of the prefix allocated. 511 P A flag indicating, when set, that the mobile 512 node requests a mobile network prefix. This flag 513 is only relevant for new requests, and must be 514 ignored for binding refreshes. 516 Reserved This field is reserved for future use. It MUST 517 be set to zero by the sender and ignored by the 518 receiver. 520 IPv4 home address The mobile node's IPv4 home address that should 521 be defended by the home agent. This field could 522 contain any unicast IPv4 address (public or 523 private) that was assigned to the mobile node. 524 The value 0.0.0.0 is used to request an IPv4 525 home address from the home agent. A mobile node 526 may choose to use this option to request a 527 prefix by setting the address to the All Zeroes 528 and setting the P flag. The mobile node could 529 then form an IPv4 home address based on the 530 allocated prefix. Alternatively, the mobile node 531 may use two different options, one for 532 requesting an address (Static or Dynamic) and 533 another for requesting a prefix. 535 3.1.2 The IPv4 Care-of Address option 537 This option is included in the Mobility Header including the binding 538 update message sent from the mobile node to a home agent or Mobility 539 Anchor Point. The alignment requirement for this option is 4n. 541 0 1 2 3 542 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 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | Type | Length | Reserved | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | IPv4 Care-of address | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 Type TBD 550 Length 6 552 Reserved This field is set to zero by the sender and 553 ignored by the receiver. 555 IPv4 care-of address This field contains the mobile node's IPv4 care- 556 of address. The IPv4 care-of address is used 557 when the mobile node is located in an IPv4-only 558 network. 560 3.1.3 The Binding Update Message extensions 562 This specification extends the Binding Update message with two new 563 flags. The flags are shown and described below. 565 0 1 2 3 566 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 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | Sequence # | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 |A|H|L|K|M|R|F|T| Reserved | Lifetime | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 F When set, this flag indicates a request for 574 forcing UDP encapsulation regardless of whether 575 a NAT is present on the path between the mobile 576 node and the home agent. 578 T When set, this flag indicates that the mobile 579 node requests the use of the TLV-format for 580 encapsulating IPv6 in IPv4. The TLV-format is 581 described later in this document. 583 3.2. Binding Acknowledgement extensions 585 3.2.1 IPv4 address acknowledgement option 587 This option is included in the Mobility Header including the binding 588 acknowledgement message sent from the home agent or Mobility Anchor 589 Point to the mobile node. This option indicates whether a binding 590 cache entry was created for the mobile node's IPv4 address. 591 Additionally, this option can include an IPv4 home address in the 592 case of Dynamic IPv4 home address configuration (i.e. if the 593 unspecified IPv4 address was included in the binding update). The 594 alignment requirement for this option is 4n. 596 0 1 2 3 597 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 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | Type | Length | Status | Pref | Res | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | IPv4 home address | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 Type TBD 606 Length 6 608 Status Indicates success or failure for the IPv4 home 609 address binding. Values from 0 to 127 indicate 610 success. Higher values indicate failure. The 611 following values are reserved: 612 0 Success 613 128 Failure, reason unspecified 614 129 Administratively prohibited 615 130 Incorrect IPv4 home address 616 131 Invalid IPv4 address 617 132 Dynamic IPv4 home address 618 assignment not available 619 133 Prefix allocation unauthorized 621 Pref The prefix length of the address allocated. This 622 field is only valid in case of success and MUST 623 be set to zero and ignored in case of failure. 624 This field overrides what the mobile node 625 requested (if not equal to the requested 626 length). 628 Res This field is reserved for future use. It MUST 629 be set to zero by the sender and ignored by the 630 receiver. 632 IPv4 home address The IPv4 home address that the home agent will 633 use in the binding cache entry. This could be a 634 public or private address. This field MUST 635 contain the mobile node's IPv4 home address. 636 If the address were dynamically allocated the 637 home agent will add the address to inform the 638 mobile node. Otherwise, if the address were 639 statically allocated to the mobile node, the 640 home agent will copy it from the binding update 641 message. 643 3.2.2 The NAT detection option 645 This option is sent from the home agent to the mobile node to 646 indicate whether a NAT was in the path. This option MAY also include 647 a suggested NAT binding refresh time for the mobile node. The 648 alignment requirement for this option is 4n. 650 0 1 2 3 651 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 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | Type | Length |F| Reserved | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | Refresh time | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 Type TBD 660 Length 6 662 F This flag indicates to the mobile node that UDP 663 encapsulation is required. When set, this flag 664 indicates that the mobile node MUST use UDP 665 encapsulation even if a NAT is not located 666 between the mobile node and home agent. 668 Reserved This field is reserved for future use. It MUST 669 be set to zero by the sender and ignored by the 670 receiver. 672 Refresh time A suggested time (in seconds) for the mobile 673 node to refresh the NAT binding. If set to zero, 674 it is ignored. If this field is set to the all 675 1s it means that keepalives are not needed, i.e. 676 no NAT was detected. 678 3.2.3 Extensions to the Binding Acknowledgement message 680 This specification extends the binding acknowledgement message with a 681 new flag. The new flag is shown and described below. 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 | Status |K|R|T| Reserved| 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 | Sequence # | Lifetime | 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 T This flag indicates, when set, that the sender 690 of the binding acknowledgement supports the TLV- 691 tunnel format. 693 4. Protocol operation 695 This section presents the protocol operation and processing for the 696 messages presented above. In addition, this section introduces the 697 NAT detection and traversal mechanism used by this specification. 699 4.1. Tunnelling formats 701 This speacification allows two different types of UDP-based 702 tunnelling formats to be used between the mobile node and its home 703 agent or MAP. The two formats are vanilla UDP encapsulation and TLV- 704 header UDP encapsulation. A vanilla UDP encapsulation format means 705 the following order of headers: 706 IP (v4 or v6) 707 UDP 708 IP (v4 or v6) 709 Other headers 711 When using this format the receiver would parse the version field 712 following the UDP header in order to determine whether the following 713 header is IPv4 or IPv6. The rest of the headers are processed 714 normally. The above order of headers does not take IPsec headers into 715 account as they may be placed in different parts of the packet. The 716 above format MUST be supported by all implementations of this 717 specification and MUST always be used to send the binding update 718 message. 720 A TLV-header UDP encapsulation is represented by the following order 721 of headers: 722 IP (v4 or v6) 723 UDP 724 TLV-header 725 Other headers 727 The receiver of the TLV-header UDP encapsulated packet expects the 728 TLV-header to follow UDP. The TLV header contains the type of the 729 following message and its length. Hence, the TLV header can carry 730 traffic other than IP. 732 The mobile node negotiates the format for tunnelling payload traffic 733 during the binding exchange. If a mobile node prefers to use the TLV- 734 header UDP encapsulation, it sets the T flag in the binding update 735 sent to the home agent or MAP. If the receiver of the binding update 736 supports the TLV-header format, it SHOULD set the T flag in the 737 binding acknowledgement message. Otherwise, the T flag is cleared. 738 The setting of the T flag in the binding acknowledgement indicates to 739 the mobile node that it must use the TLV-header UDP encapsulation 740 format for all packets sent for the duration of the binding or until 741 a new binding update is sent. Each binding update may renegotiate the 742 tunnelling format. To avoid interoperability issues, the sender of 743 the binding acknowledgement MUST not set the T flag unless it was set 744 in the binding update sent from the mobile node. 746 The TLV-header format is shown below. 748 0 1 2 3 749 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 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | Type | Length | Reserved | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 Type This field indicates the type of the payload 755 following this header. 757 Length This field indicates the length of the payload 758 following the header, excluding the TLV-header 759 itself. 761 Reserved This field MUST be set to zero by the sender and 762 ignored by the receiver. 764 The following values are assigned to the Type field, other values may 765 be assigned in future: 767 1 IPv4 768 2 IPv6 769 3 IPsec 770 4 GRE 772 In addition to the UDP-based tunnelling formats described above, this 773 specification allows for standard IP in IP tunnelling. This can take 774 place by tunnelling IPv4 in IPv6 or IP v6 in IPv4. However, whenever 775 a NAT a detected, the mobile node will default to UDP-based 776 encapsulation. The mobile node can request to always use UDP 777 encapsulation by setting the F flag in the binding update. If the 778 home agent does not agree to such request, it MUST reject the binding 779 update with the new Status code: 780 144 Cannot force UDP encapsulation 781 Alternatively, the home agent can force UDP encapsulation by setting 782 the F flag in the NAT detection option included in the binding 783 acknowledgement. 785 4.2. NAT detection and traversal 787 NAT detection is done when the initial binding update message is sent 788 from the mobile node to the home agent. When located in an IPv4-only 789 foreign link, the mobile node sends the binding update message 790 encapsulated in UDP and IPv4. The source address of the IPv6 packet 791 is the mobile node's IPv6 home address. The destination address is 792 the IPv6 address of the home agent. The IPv4 header contains the IPv4 793 care-of address in the source address field and the IPv4 address of 794 the home agent in the destination address field. 796 When the home agent receives the encapsulated binding update it 797 compares the IPv4 address of the source address field in the IPv4 798 header with the IPv4 address in the source address of the IPv6 799 header. If the two addresses match, no NAT device was in the path. 800 Otherwise, a NAT device was in the path and the NAT detection option 801 is included in the binding acknowledgement. The binding 802 acknowledgement, and all future packets, are then encapsulated in UDP 803 and IPv4. The source address in the IPv4 header is the IPv4 address 804 of the home agent. The destination address is the IPv4 address 805 received in the IPv4 header encapsulating the binding update (this 806 address will be different from the IPv4 care-of address when a NAT is 807 in the path). The source port in the packet is the home agent's 808 source port. The destination port is the source port received in the 809 binding update message. Note that the home agent stores the port 810 numbers and associates them with the mobile node's tunnel in order to 811 forward future packets. 813 Upon receiving the binding acknowledgement with the NAT detection 814 option, the mobile node sets the tunnel to the home agent to UDP 815 encapsulation. Hence, all future packets to the home agent are 816 tunneled in UDP and IPv4. For all tunneled IPv6 packets, the source 817 address in the IPv6 header is the mobile node's IPv6 home address and 818 the destination address is the correspondent node's IPv6 address. All 819 tunneled IPv4 packets will contain the mobile node's IPv4 home 820 address in the source address field of the inner IPv4 packet and the 821 correspondent node's IPv4 address in the destination address field. 822 The outer IPv4 header is the same whether the inner packet is IPv4 or 823 IPv6. 825 If no NAT device was detected in the path between the mobile node and 826 the home agent then IPv6 packets are tunneled in an IPv4 header, 827 unless the home agent forces UDP encapsulation using the F flag. The 828 content of the inner and outer headers are identical to the UDP 829 encapsulation case. 831 A mobile node MUST always tunnel binding updates in UDP when located 832 in an IPv4-only network. Essentially, this process allows for 833 perpetual NAT detection. Similarly, the home agent MUST encapsulate 834 binding acknowledgements in a UDP header whenever the binding update 835 is encapsulated in UDP. 837 In conclusion, the packet formats for the binding update and 838 acknowledgement messages are shown below: 840 A. Binding update received by the home agent: 842 IPv4 header (src=V4ADDR, dst=HA_V4ADDR) 843 UDP header 844 IPv6 header (src=V6HOA, dst=HAADDR) 845 ESP-header 846 Mobility header 847 BU [IPv4 HAO] 848 IPv4 CoA option 850 Where V4ADDR is either the IPv4 care-of address or the address 851 provided by the NAT device. V6HOA is the IPv6 home address of the 852 mobile node. The binding update MAY also contain the IPv4 home 853 address option IPv4 HAO. 855 B. Binding acknowledgement sent by the home agent: 856 IPv4 header (src= HA_V4ADDR, dst=V4ADDR) 857 UDP header 858 IPv6 header (src=HAADDR, dst=V6HOA) 859 Route HDR Type 2 860 V6HOA (IPv6 home address) 861 Mobility header 862 BA ([IPv4 ACK], NAT DET) 864 Where V6HOA is IPv6 home address of the mobile node. The IPv4 ACK is 865 the IPv4 address acknowledgement option, which is only included if 866 the IPv4 home address option were present in the BU. The NAT DET is 867 the NAT detection option, which MUST be present in the binding 868 acknowledgement message if the binding update was encapsulated in 869 UDP. 871 4.3. NAT Keepalives 873 If a NAT is detected, the mobile node will need to refresh the NAT 874 bindings in order to be reachable from the home agent. NAT bindings 875 can be refreshed through sending and receiving traffic encapsulated 876 in UDP. However, if the mobile node is not active, it will need to 877 periodically send a message to the home agent in order to refresh the 878 NAT binding. This can be done using the binding update message. The 879 binding update/acknowledgement pair will ensure that the NAT bindings 880 are refreshed in a reliable manner. There is no way for the mobile 881 node to know the exact time of the NAT binding. The default time 882 suggested in this specification is NATKATIMEOUT. If the home agent 883 suggests a different refresh period in the binding acknowledgement, 884 the mobile node SHOULD use the value suggested by the home agent. 886 If the refresh time in the NAT detection option in the binding 887 acknowledgement is set to the all 1s, the mobile node need not send 888 messages to refresh the NAT binding. However, the mobile node may 889 still be required to encapsulate traffic in UDP. This scenario may 890 take place when a NAT is not detected, but the home agent still 891 requires the mobile node to use UDP encapsulation. 893 It should be noted that a mobile node that does not need to be 894 reachable (i.e. only cares about the session continuity aspect of 895 Mobile IP) does not need to refresh NAT binding. In this case, the 896 mobile node would only be able to initiate communication with other 897 nodes. 899 4.4. Mobile node operation 900 In addition to the operations specified in [MIPv6] and [NEMO], this 901 specification requires mobile nodes to be able to support an IPv4 902 home address. 904 When sending an IPv6 packet containing a binding update while 905 connected to an IPv4-only access network, mobile nodes MUST ensure 906 the following: 908 - The IPv6 packet is encapsulated in the vanilla UDP encapsulation 909 format. 910 - The source address in the IPv4 header is the mobile node's IPv4 911 care-of address 912 - The destination address in the IPv4 header is the home agent's 913 IPv4 address. 914 - The source address in the IPv6 header is the mobile node's IPv6 915 home address. 916 - The IPv4 home address option MAY be included in the mobility 917 header. This option contains the IPv4 home address. If the mobile 918 node did not have a static home address it MAY include the 919 unspecified IPv4 address, which acts as a request for a dynamic 920 IPv4 home address. Alternatively, one or more IPv4 home address 921 options may be included with requests for IPv4 prefixes (i.e. with 922 the P flag set.). 923 - If the mobile node wishes to use UDP encapsulation only, it should 924 set the F flag in the binding update message. 925 - If the mobile node prefers to use the TLV-header format, it should 926 set the T flag in the binding update. 927 - The IPv6 packet MUST be authenticated as per [MIPv6], based on the 928 mobile node's IPv6 home address. 930 When sending a binding update from a visited network that supports 931 IPv6, the mobile node MUST follow the rules specified in [MIPv6]. In 932 addition, if the mobile node has an IPv4 home address or needs one, 933 it MUST include the IPv4 home address option in the mobility header. 934 If the mobile node already has a static IPv4 home address, such 935 address MUST be included in the IPv4 home address option. Otherwise, 936 if the mobile node needs a dynamic IPv4 address, it MUST include the 937 IPv4 unspecified address in the IPv4 home address option. 939 When the mobile node receives a binding acknowledgement from the home 940 agent, it follows the rules in [MIPv6] and [NEMO]. In addition, the 941 following actions MUST be made: 943 - If the status field indicated failure with error code 144, the 944 mobile node MAY resend the binding update without setting the F 945 flag. 946 - If the mobility header includes an IPv4 address acknowledgement 947 option indicating success, the mobile node should create two 948 entries in its binding update list, one for the IPv6 home address 949 and another for the IPv4 home address. 950 - If the NAT detection option were present, the mobile node 951 MUST tunnel future packets in UDP and IPv4. This MUST be indicated 952 in the binding update list. 953 - If no IPv4 address acknowledgement option were present, and an 954 IPv4 home address option was present in the binding update, the 955 mobile node MUST only create one binding update list entry for its 956 IPv6 home address. The mobile node MAY include the IPv4 home 957 address option in future binding updates. 958 - If an IPv4 address acknowledgement option were present and it 959 indicates failure for the IPv4 home address binding, the mobile 960 node MUST NOT create an entry for that address in its binding 961 update list. The mobile node MAY include the IPv4 home address 962 option in future binding updates. 963 - If the T flag was set in the binding update and the binding 964 acknowledgement included a T flag set, the mobile node MUST use the 965 TLV-header UDP encapsulation format. 967 4.4.1 Sending packets from a visited network. 969 When the mobile node is located in an IPv6-enabled network it sends 970 and receives IPv6 packets as described in [MIPv6]. IPv4 traffic is 971 encapsulated in IPv6 packets to the home agent. 973 When the mobile node is located in an IPv4 only network, it will send 974 IPv6 packets to its home agent according to the following format: 976 IPv4 header (src=V4CoA, dst=HA_V4ADDR) 977 [UDP header] 978 IPv6 header (src=V6HoA, dst=CN) 979 Upper layer protocols 981 Where the UDP header is only used if a NAT were detected between the 982 mobile node and the home agent, or if the home agent forced UDP 983 encapsulation. V4CoA is the IPv4 care-of address configured by the 984 mobile node in the visited network. 986 Similarly, IPv4 packets are sent according to the following format: 988 IPv4 header (src=V4CoA, dst=HA_V4ADDR) 989 [UDP header] 990 IPv4 header (src=V4HoA, dst=V4CN) 991 Upper layer protocols 993 Where the UDP header is only used if a NAT were detected between the 994 mobile node and the home agent, or if the home agent forced UDP 995 encapsulation. 997 If the mobile node requested, and the home agent agreed, to use the 998 TLV-header UDP encapsulation format, then the TLV-header would be 999 used after the UDP header. 1001 4.4.2 Movement detection in IPv4-only networks 1003 [MIPv6] describes movement detection mostly based on IPv6-specific 1004 triggers. Such triggers would not be available in an IPv4-only 1005 network. Hence, a mobile node located in an IPv4-only network SHOULD 1006 use [DNAv4] for guidance on movement detection mechanisms in IPv4- 1007 only networks. 1009 4.5. Home agent operations 1011 In addition to the home agent specification in [MIPv6] and [NEMO], 1012 the home agent needs to be able to process the IPv4 home address 1013 option and generate the IPv4 address acknowledgement option. Both 1014 options are included in the mobility header. Furthermore, the home 1015 agent MUST be able to detect the presence of a NAT device and 1016 indicate that in the NAT detection option included in the binding 1017 acknowledgement. 1019 A home agent must also act as a proxy for address resolution in IPv4 1020 for the registered IPv4 home addresses of mobile nodes it is serving. 1021 Moreover, the administrative domain of the home agent is responsible 1022 for advertising the routing information of registered IPv4 mobile 1023 network prefixes of the mobile nodes. 1025 In order to comply with this specification, the home agent MUST be 1026 able to find the IPv4 home address of a mobile node when given the 1027 IPv6 home address. That is, given an IPv6 home address, the home 1028 agent MUST store the corresponding IPv4 home address if a static one 1029 is present. If a dynamic address were requested by the mobile node, 1030 the home agent MUST store that address (associated with the IPv6 home 1031 address) after it's allocated to the mobile node. 1033 When the home agent receives a binding update encapsulated in UDP and 1034 containing the IPv4 home address option, it needs to follow all the 1035 steps in [MIPv6] and [NEMO]. In addition, the following checks MUST 1036 be done: 1038 - If the IPv4 care-of address in the IPv4 CoA option is not the same 1039 as the IPv4 address in the source address in the IPv4 header then 1040 a NAT was in the path. This information should be flagged for the 1041 binding acknowledgement. 1043 - If the F flag in the binding update were set, the home agent needs 1044 to determine whether it accepts forcing UDP encapsulation. If it 1045 does not, the binding acknowledgement is sent with error code 144. 1047 - If the T flag was set in the binding update, the home agent needs 1048 to determine whether it can accept the TLV-header encapsulation 1049 format. If it does, it should set the T flag in the binding 1050 acknowledgement. Otherwise, the home agent MUST NOT set the T flag 1051 in the binding acknowledgement. 1053 - If the IPv4 home address option contains a valid unicast IPv4 1054 address, the home agent MUST check that this address is allocated 1055 to the mobile node that has the IPv6 home address included in the 1056 home address option. The same MUST be done for an IPv4 prefix. 1058 - If the IPv4 home address option contained the unspecified IPv4 1059 address, the home agent SHOULD dynamically allocate an IPv4 home 1060 address to the mobile node. If none is available, the home agent 1061 MUST return error code 132 in the status field of the IPv4 address 1062 acknowledgement option. If a prefix were requested, the home agent 1063 MUST allocate a prefix with the requested length; otherwise the 1064 home agent MUST indicate failure of the operation with the 1065 appropriate error code. 1067 - If the binding update is accepted for the IPv4 home address, the 1068 home agent creates a binding cache entry for the IPv4 home 1069 address/prefix. The home agent MUST include an IPv4 acknowledgement 1070 option in the mobility header containing the binding 1071 acknowledgement. 1073 If the binding update is accepted for both IPv4 and IPv6 home 1074 addresses, the home agent creates separate binding cache entries, one 1075 for each home address. The care-of address is the one included in the 1076 binding update. If the care-of address is an IPv4 address, the home 1077 agent MUST setup a tunnel to the IPv4 care-of address of the mobile 1078 node. 1080 When sending a binding acknowledgement to the mobile node, the home 1081 agent constructs the message according to [MIPv6] and [NEMO]. Note 1082 that the routing header MUST always contain the IPv6 home address as 1083 specified in [MIPv6]. 1085 If the care-of address of the mobile node were an IPv4 address, the 1086 home agent includes the mobile node's IPv6 home address in the 1087 destination address field in the IPv6 header. If a NAT were detected, 1088 the home agent MUST then encapsulate the packet in UDP and an IPv4 1089 header. The source address is set to the home agent's IPv4 address 1090 and the destination address is set to the address received in the 1091 source address of the IPv4 header encapsulating the binding update. 1093 After creating a binding cache entry for the mobile node's home 1094 addresses, all packets sent to the mobile node's home addresses are 1095 tunneled by the home agent to the mobile node's care-of address. If a 1096 NAT were detected, packets are encapsulated in UDP and IPv4. 1097 Otherwise, if the care-of address is an IPv4 address, and no NAT were 1098 detected, packets are encapsulated in an IPv4 header. 1100 4.5.1 Sending packets to the mobile node 1102 The home agent follows the rules specified in [MIPv6] for sending 1103 IPv6 packets to mobile nodes located in IPv6 networks. When sending 1104 IPv4 packets to When mobile nodes in an IPv6 network, the home agent 1105 must encapsulate the IPv4 packets in IPv6. 1107 When sending IPv6 packets to a mobile node located in an IPv4 1108 network, the home agent must follow the format negotiated in the 1109 binding update/acknowledgement exchange. In the absence of a 1110 negotiated format, the default format that MUST be supported by all 1111 implementations is: 1113 IPv4 header (src= HA_V4ADDR, dst= V4CoA) 1114 [UDP header] 1115 IPv6 header (src=CN, dst= V6HoA) 1116 Upper layer protocols 1118 Where the UDP header is only included if a NAT were detected between 1119 the mobile node and the home agent, or if the home agent forced UDP 1120 encapsulation. 1122 When sending IPv4 packets to a mobile node located in an IPv4 1123 network, the home agent must follow the format negotiated in the 1124 binding update/acknowledgement exchange. In the absence of a 1125 negotiated format, the default format that MUST be supported by all 1126 implementations is: 1128 IPv4 header (src= HA_V4ADDR, dst= V4CoA) 1129 [UDP header] 1130 IPv4 header (src=V4CN, dst= V4HoA) 1131 Upper layer protocols 1133 Where the UDP header is only included if a NAT were detected between 1134 the mobile node and home agent, or if the home agent forced UDP 1135 encapsulation. 1137 4.6. Correspondent node operations 1139 This specification has no impact on IPv4 or IPv6 correspondent nodes. 1141 5. Security considerations 1143 This specification allows a mobile node to send one binding update 1144 for its IPv6 and IPv4 home addresses. This is a slight deviation from 1145 [MIPv6] which requires one binding update per home address. However, 1146 like [MIPv6], the IPsec security association needed to authenticate 1147 the binding update is still based on the mobile node's IPv6 home 1148 address. Therefore, in order to authorize the mobile node's IPv4 home 1149 address binding, the home agent MUST store the IPv4 address 1150 corresponding to the IPv6 address that is allocated to a mobile node. 1151 Therefore, it is sufficient for the home agent to know that the IPsec 1152 verification for the packet containing the binding update was valid 1153 provided that it knows which IPv4 home address is associated with 1154 which IPv6 home address. Hence, the security of the IPv4 home address 1155 binding is the same as the IPv6 binding. 1157 In effect, associating the mobile node's IPv4 home address with its 1158 IPv6 home address moves the authorization of the binding update for 1159 the IPv4 address to the Mobile IPv6 implementation, which infers it 1160 from the fact that mobile node has an IPv6 home address and the right 1161 credentials for sending an authentic binding update for such address. 1163 In cases where this specification is used for NAT traversal, it is 1164 important to note that it has the same UNSAF vulnerabilities 1165 associated with RFC 3519. An attacker is able to hijack the mobile 1166 node's session with the home agent if it can modify the contents of 1167 the outer IPv4 header. The contents of the header are not 1168 authenticated and there is no way for the home agent to verify their 1169 validity. Hence, a man in the middle attack where a change in the 1170 contents of the IPv4 header can cause a legitimate mobile node's 1171 traffic to be diverted to an illegitimate receiver independently of 1172 the authenticity of the binding update message. 1174 6. Protocol constants 1176 NATKATIMEOUT 110 seconds 1178 7. Acknowledgements 1180 Thanks to the following members (in alphabetical order) of the MIP6 1181 and NEMO Working Groups for their contributions, discussion, and 1182 review: Jari Arkko, Sri Gundavelli, Wassim Haddad, Conny Larsson, 1183 Ahmad Muhanna, Vidya Narayanan, Karen Neilsen and Keiichi Shima. 1185 8. IANA considerations 1187 The specification requires the following allocations from IANA: 1188 - A UDP port is needed for the NAT traversal mechanism described in 1189 section 4.1. 1190 - The IPv4 home address option described in section 3.1.1 requires an 1191 option type. This option is included in the Mobility header 1192 described in [MIPv6]. 1193 - The IPv4 address acknowledgement option described in section 3.2.1 1194 requires a new option type. This option is included in the Mobility 1195 header described in [MIPv6]. 1196 - The NAT detection option described in section 3.2.2 requires a new 1197 option type. This option is included in the Mobility header 1198 described in [MIPv6]. 1199 - The IPv4 Care-of address option described in section 3.1.2 requires 1200 an option type. This option is included in the Mobility header 1201 described in [MIPv6]. 1203 9. References 1205 [BOOT] Giaretta, G. (Ed.), Kempf J., and V. Devarapalli, " Mobile 1206 IPv6 bootstrapping in split scenario", draft-ietf-mip6- 1207 bootstrapping-split, June 2005, work in progress. 1209 [HMIPv6] Soliman, H., Castelluccia, C., ElMalki, K., and L. Bellier, 1210 "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", 1211 RFC 4140, August 2005. 1213 [IPv6] S. Deering and B. Hinden, "Internet Protocol version 6 (IPv6) 1214 specification", RFC 2460 1216 [INTBOOT] K. Chowdhury and A. Yegin, "MIP6-bootstrapping for the 1217 Integrated Scenario", draft-ietf-mip6-bootstrapping- 1218 integrated-dhc-02, Work in Progress. 1220 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 1221 Requirement Levels", BCP 14, RFC 2119, March 1997. 1223 [MIP-PB] Tsirtsis, G., and H. Soliman, "Mobility management for 1224 Dual stack mobile nodes, A Problem Statement", 1225 draft-ietf-mip6-dsmip-problem-01.txt, July 2005. 1227 [MIPv4] C. Perkins, "Mobility Support for IPv4", RFC3344 1229 [MIPv6] D. Johnson, C. Perkins and J. Arkko, "Mobility Support in 1230 IPv6", RFC 3775, June 2004. 1232 [NEMO] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 1233 "Network Mobility (NEMO) Basic Support protocol", RFC 3963, 1234 January 2005. 1236 [SEC] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 1237 Protoect Mobile IPv6 Signaling between Mobile Nodes and Home 1238 Agents", RFC 3776, June 2004. 1240 [SNRIO] Larsson, T., Gustafsson, E., and H. Levkowetz, "Use of MIPv6 1241 in IPv4 and MIPv4 in IPv6 networks", draft-larsson-v6ops- 1242 mip-scenarios-01.txt, February 2004. 1244 10. Contributors 1246 This document reflects discussions and contributions from several 1247 people including (in alphabetical order): 1249 Vijay Devarapalli 1250 E-mail: vijay.devarapalli@azairenet.com 1252 James Kempf 1253 E-mail: kempf@docomolabs-usa.com 1255 Henrik Levkowetz 1256 E-mail: henrik@levkowetz.com 1258 Pascal Thubert 1259 E-mail: pthubert@cisco.com 1261 George Tsirtsis 1262 E-mail1: G.Tsirtsis@Qualcomm.com 1263 E-mail2: tsirtsisg@yahoo.com 1265 Wakikawa Ryuji 1266 ryuji@sfc.wide.ad.jp 1268 Author's Address 1270 Hesham Soliman 1271 Elevate Technologies 1272 E-mail: Hesham@elevatemobile.com 1274 Intellectual Property Statement 1276 The IETF takes no position regarding the validity or scope of any 1277 Intellectual Property Rights or other rights that might be claimed to 1278 pertain to the implementation or use of the technology described in 1279 this document or the extent to which any license under such rights 1280 might or might not be available; nor does it represent that it has 1281 made any independent effort to identify any such rights. Information 1282 on the IETF's procedures with respect to rights in IETF Documents can 1283 be found in RFC 3667 (BCP 78) and RFC 3668 (BCP 79). 1285 Copies of IPR disclosures made to the IETF Secretariat and any 1286 assurances of licenses to be made available, or the result of an 1287 attempt made to obtain a general license or permission for the use of 1288 such proprietary rights by implementers or users of this 1289 specification can be obtained from the IETF on-line IPR repository at 1290 http://www.ietf.org/ipr. 1292 The IETF invites any interested party to bring to its attention any 1293 copyrights, patents or patent applications, or other proprietary 1294 rights that may cover technology that may be required to implement 1295 this standard. Please address the information to the IETF at ietf- 1296 ipr@ietf.org. 1298 Full Copyright Statement 1300 Copyright (C) The IETF Trust (2007). This document is subject to the 1301 rights, licenses and restrictions contained in BCP 78, and except as 1302 set forth therein, the authors retain all their rights. 1304 Disclaimer of Validity 1305 This document and the information contained herein are provided on an 1306 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1307 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1308 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1309 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1310 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1311 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1313 This Internet-Draft expires January, 2008.