idnits 2.17.1 draft-ietf-mip6-nemo-v4traversal-06.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 1393. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1371. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1377. ** 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack 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 851, but not defined == Missing Reference: 'IPv4 ACK' is mentioned on line 865, but not defined == Missing Reference: 'DNAv4' is mentioned on line 1010, but not defined == Unused Reference: 'IPv6' is defined on line 1277, but no explicit reference was found in the text == Unused Reference: 'KEYWORDS' is defined on line 1287, but no explicit reference was found in the text == Unused Reference: 'SEC' is defined on line 1290, but no explicit reference was found in the text == Unused Reference: 'MIPv4' is defined on line 1316, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (ref. 'IPv6') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3775 (ref. 'MIPv6') (Obsoleted by RFC 6275) == Outdated reference: A later version (-06) exists of draft-ietf-mip6-bootstrapping-integrated-dhc-02 -- Obsolete informational reference (is this intentional?): RFC 3344 (ref. 'MIPv4') (Obsoleted by RFC 5944) Summary: 6 errors (**), 0 flaws (~~), 12 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: May 2008 5 November, 2007 7 Mobile IPv6 support for dual stack 8 Hosts and Routers (DSMIPv6) 9 draft-ietf-mip6-nemo-v4traversal-06.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...............................14 68 3.2.3 Extensions to the Binding Acknowledgement message......14 69 4. Protocol operation..............................................15 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.........................................19 74 4.4.1 Sending packets from a visited network.................20 75 4.4.2 Movement detection in IPv4-only networks...............21 76 4.5. Home agent operations.........................................21 77 4.5.1 Sending packets to the mobile node.....................23 78 4.6. Correspondent node operations.................................23 79 5. Security considerations.........................................23 80 5.1 Handover interactions for IPsec and IKE.....................24 81 6. Protocol constants..............................................25 82 7. Acknowledgements................................................25 83 8. IANA considerations.............................................26 84 9. References......................................................26 85 10. Contributors...................................................27 86 Author's Address...................................................27 88 1. Introduction 90 Mobile IPv6 [MIPv6] and [NEMO] allow mobile nodes to move within the 91 Internet while maintaining reachability and ongoing sessions, using 92 an IPv6 home address or prefix. However, since IPv6 is not widely 93 deployed, it is unlikely that mobile nodes will use IPv6 addresses 94 only for their connections. It is reasonable to assume that mobile 95 nodes will, for a long time, need an IPv4 home address that can be 96 used by upper layers. It is also reasonable to assume that mobile 97 nodes will move to networks that might not support IPv6 and would 98 therefore need the capability to support an IPv4 Care-of Address. 99 Hence, this specification extends Mobile IPv6 capabilities to allow 100 dual stack mobile nodes to request that their home agent (also dual 101 stacked) tunnel IPv4/IPv6 packets addressed to their home addresses, 102 as well as IPv4/IPv6 care-of address(es). 104 Using this specification, mobile nodes would only need Mobile IPv6 105 and [NEMO] to manage mobility while moving within the Internet; hence 106 eliminating the need to run two mobility management protocols 107 simultaneously. This specification provides the extensions needed in 108 order to allow IPv6 mobility only to be used by dual stack mobile 109 nodes. 111 This specification will also consider cases where a mobile node moves 112 into a private IPv4 network and gets configured with a private IPv4 113 Care-of Address. In those scenarios, the mobile node needs to be able 114 to traverse the IPv4 NAT in order to communicate with the Home Agent. 115 IPv4 NAT traversal for Mobile IPv6 is presented in this 116 specification. 118 In this specification, the term mobile node refers to both a mobile 119 host and mobile router unless the discussion is specific to either 120 hosts or routers. Similarly, we use the term home address to reflect 121 an address/prefix format. 123 In this specification, extensions are defined for the binding update 124 and binding acknowledgement. It should be noted that all these 125 extensions apply to cases where the mobile node communicates with a 126 Mobility Anchor Point (MAP) as defined in [HMIPv6]. The requirements 127 on the MAP are identical to those stated for the home agent, although 128 it is unlikely that NAT traversal would be needed with a MAP as it is 129 expected to be in the same address domain. 131 1.1 Motivation for using Mobile IPv6 only 133 IPv6 offers a number of improvements over today's IPv4, primarily due 134 to its large address space. Mobile IPv6 offers a number of 135 improvements over Mobile IPv4, mainly due to capabilities inherited 136 from IPv6. For instance, route optimization and Dynamic home agent 137 discovery can only be achieved with Mobile IPv6. 139 One of the advantages of the large address space provided by IPv6 is 140 that it allows mobile nodes to obtain a globally unique care-of 141 address wherever they are. Hence, there is no need for Network 142 Address Translator (NAT) traversal techniques designed for Mobile 143 IPv4. This allows Mobile IPv6 to be a significantly simpler and more 144 bandwidth efficient mobility management protocol. At the same time, 145 during the transition towards IPv6, NAT traversal for existing 146 private IPv4 networks needs to be considered. This specification 147 introduces NAT traversal for this purpose. 149 The above benefits make the case for using Mobile IPv6 only for dual 150 stack mobile nodes in order to allow for a long lasting mobility 151 solution and minimize the need to changing the mobility stack due to 152 the introduction of IPv6 within a deployed network. 154 1.2 Scenarios considered by this specification 156 In [SNRIO] several scenarios that illustrate potential 157 incompatibilities for mobile nodes using Mobile IPv6 were discussed. 158 Some of the problems associated with mobility and transition issues 159 were presented in [MIP-PB]. This specification considers a subset of 160 the scenarios in [SNRIO], which address all the problems discussed in 161 [MIP-PB]. The scenarios considered in this specification are listed 162 below. 164 All of the following scenarios assume that both the mobile node and 165 the Home Agent are IPv4 and IPv6-enabled and that only Mobile IPv6 is 166 used between the mobile node and the Home Agent. We also assume that 167 the Home Agent is always reachable through a globally unique IPv4 168 address. Finally, it's important to note that the following scenarios 169 are not mutually exclusive. 171 Scenario 1: IPv4-only foreign network 173 In this scenario, a mobile node is connected to an IPv4-only foreign 174 network. The mobile node can only configure an IPv4 Care-of Address. 176 Scenario 2: Mobile node behind a NAT 178 In this scenario, the mobile node is in a private IPv4 foreign 179 network that has a NAT device connecting it to the Internet. If the 180 Home Agent is located outside the NAT device, the mobile node will 181 need a NAT traversal mechanism to communicate with the Home Agent. 183 Scenario 3: Home Agent behind a NAT 185 In this scenario, the communication between the mobile node and the 186 Home Agent is further complicated by the fact that the Home Agent is 187 located within a private IPv4 network. However, in this scenario, we 188 assume that the Home Agent is allocated a globally unique IPv4 189 address. Such address might not be physically configured on the Home 190 Agent interface. Instead, it is associated with the Home Agent on the 191 NAT device, which allows the Home Agent to be reachable through 192 address or port mapping. 194 Scenario 4: Use Of IPv4-only applications 196 In this scenario, the mobile node may be located in an IPv4, IPv6 or 197 a dual network. However, the mobile node might be communicating with 198 an IPv4-only node. In this case, the mobile node would need a stable 199 IPv4 address for its application. The alternative to using an IPv4 200 address is the use of protocol translators; however, end-to-end 201 communication with IPv4 is preferred to the use of protocol 202 translators. 204 The mobile node may also be communicating with an IPv4-only 205 application that requires an IPv4 address. 207 The cases above illustrate the need for a stable IPv4 home address to 208 be allocated to the mobile node. This is done using an IPv4 home 209 address. Since running Mobile IPv4 and Mobile IPv6 simultaneously is 210 problematic (as illustrated in [MIP-PB]), this scenario adds a 211 requirement on Mobile IPv6 to support IPv4 home addresses. 213 2. Solution overview 215 In order to allow Mobile IPv6 to be used by dual stack mobile nodes, 216 the following needs to be done: 218 - Mobile nodes should be able to use an IPv4 and IPv6 home or care-of 219 address simultaneously and update their home agents accordingly. 221 - Mobile nodes need to be able to know the IPv4 address of the home 222 agent as well as its IPv6 address. There is no need for IPv4 prefix 223 discovery however. 225 - Mobile nodes need to be able to detect the presence of a NAT device 226 and traverse such device in order to communicate with the Home Agent 227 in a secure manner. 229 This section presents an overview of the extensions required in order 230 to allow mobile nodes to use Mobile IPv6 only for IP mobility 231 management. 233 2.1. Home Agent Address Discovery 235 Dynamic Home Agent Address Discovery (DHAAD) was defined in [MIPv6] 236 to allow mobile nodes to discover their home agents by appending a 237 well-known anycast interface identifier to their home link's prefix. 238 However, this mechanism is based on IPv6-anycast routing. If a mobile 239 node is located in an IPv4-only foreign network, it cannot rely on 240 native IPv6 routing. In this scenario, the solution for discovering 241 the home agent's IPv4 address is through the Domain Name System 242 (DNS). If the MN is attached to an IPv6-only or dual stack network, 243 it may also use procedures defined in [INTBOOT] to discover Home 244 Agent information. Note that the use of [INTBOOT] cannot give the 245 mobile node information that allows it to continue to communicate 246 with the Home Agent if, for example, the mobile node moved from an 247 IPv6-enabled network to an IPv4-only network. In such scenario, the 248 mobile node would need to discover the IPv4 address of its home agent 249 through the DNS. 251 For DNS lookup by name, the mobile node should be configured with the 252 name of the home agent. When the mobile node needs to discover a 253 home agent, it sends a DNS request with QNAME set to the configured 254 name. An example is "ha1.example.com". If a home agent has an IPv4 255 and IPv6 address, the corresponding DNS record should be configured 256 with both 'AAAA' and 'A' records. Accordingly the DNS reply will 257 contain 'AAAA' and 'A' records. 259 For DNS lookup by service, the SRV record defined in [BOOT] is 260 reused. For instance, if the service name is "mip6ha" and the 261 protocol name is "ipv6" for the SRV record, the mobile node SHOULD 262 send a DNS request with the QNAME set to "mip6ha.ipv6.example.com". 263 The response should contain the home agent's FQDN(s) and may have the 264 corresponding 'AAAA' and 'A' records enclosed as well. 266 If multiple home agents reside on the home link, each configured with 267 a public IPv4 addresses, then the operation above applies. In case 268 the home agents are behind a NAT box, there are two options, 1) 269 configure a public IPv4 address for each home agent on the NAT box, 270 2) configure one public address and make the home agents share the 271 public address. In either case, the correct DNS entries can be 272 configured. Another possible solution is to designate one home agent 273 on the home link for v4 traversal. The NAT device should associate 274 that home agent with the public IPv4 address configured on it for v4 275 traversal. In all cases above, both the 'AAAA' and 'A' records 276 returned for a particular name MUST correspond to the same physical 277 home agent; otherwise the mobile node will not be able to bind its 278 addresses correctly. 280 2.2. Mobile Prefix Solicitations and Advertisements 282 According to [MIPv6], the mobile node can send a Mobile Prefix 283 Solicitation and receive a Mobile Prefix Advertisement containing all 284 prefixes advertised on the home link. 286 A dual stack mobile node MAY send a Mobile Prefix Solicitation 287 message encapsulated in IPv4 (i.e. IPv6 in IPv4) in the case where 288 the mobile node has no access to IPv6 within the local network. 289 Securing such messages would require the mobile node to have security 290 association with the home agent, using IPsec (AH or ESP) and based on 291 the mobile node's IPv4 care-of address as described in [MIPv6]. Since 292 the mobile node needs to encapsulate all IPv6 traffic sent to the 293 home agent into IPv4 while located in an IPv4-only visited network, 294 such SA would affect all packets if the selectors were based on the 295 information in the outer header. That is, the SA selectors being the 296 protocol number (protocol is always IP in IP), as well as, source and 297 destination addresses are all common to all packets. If this effect 298 is not desired, the mobile node can base the SA on the information in 299 the inner header (i.e. using the home agent's IPv6 address, the 300 mobile node's home address and the ICMP protocol number). Such 301 security association would use transport mode ESP protection. 303 2.3. Binding management 305 A dual stack mobile node will need to update its home agent with its 306 care-of address. If a mobile node has an IPv4 and an IPv6 home 307 address it will need to create a binding cache entry for each 308 address. The format of the IP packet carrying the binding update and 309 acknowledgement messages will vary depending on whether the mobile 310 node has access to IPv6 in the visited network. There are three 311 different scenarios to consider with respect to the visited network: 313 A. The visited network has IPv6 connectivity and provides the mobile 314 node with a care-of address (in a stateful or stateless manner). 316 B. The mobile node can only configure a globally unique IPv4 address 317 in the visited network. 318 C. The mobile node can only configure a private IPv4 address in the 319 visited network. 321 2.3.1 Foreign network supports IPv6 323 In this case, the mobile node is able to configure a globally unique 324 IPv6 address. The mobile node will send a binding update to the IPv6 325 address of its home agent, as defined in [MIPv6]. The binding update 326 MAY include the IPv4 home address option introduced in this document. 327 After receiving the binding update, the home agent creates two 328 binding cache entries, one for the mobile node's IPv4 home address, 329 and another for the mobile node's IPv6 home address. Both entries 330 will point to the mobile node's IPv6 care-of address. Hence, whenever 331 a packet is addressed to the mobile node's IPv4 or IPv6 home 332 addresses, it will be tunneled in IPv6 to the mobile node's IPv6 333 care-of address included in the binding update. Effectively, the 334 mobile node establishes two different tunnels, one for its IPv4 335 traffic (IPv4 in IPv6) and one for its IPv6 traffic (IPv6 in IPv6) 336 with a single binding update. The security implications of this 337 mechanism are discussed in the security considerations section. 339 In this scenario, the only addition to [MIPv6] is the inclusion of 340 the IPv4 home address option in the binding update message. 342 After accepting the binding update and creating the corresponding 343 binding cache entries, the home agent MUST send a binding 344 acknowledgement to the mobile node as defined in [MIPv6]. In 345 addition, if the binding update included an IPv4 home address option, 346 the binding acknowledgement MUST include the IPv4 address 347 acknowledgment option as described later in this specification. This 348 option informs the mobile node whether the binding was accepted for 349 the IPv4 home address. If this option is not included in the binding 350 acknowledgement and the IPv4 home address option was included in the 351 binding update, the mobile node MUST assume that the home agent does 352 not support the IPv4 home address option and therefore SHOULD NOT 353 include the option in future binding updates to that home agent 354 address. 356 The routing header in the binding update MUST include the mobile 357 node's IPv6 home address as specified in [MIPv6]. 359 When a mobile node acquires both IPv4 and IPv6 care-of addresses at 360 foreign network, it SHOULD prioritize IPv6 care-of address for MIP6 361 binding registration. The mobile node MUST NOT register both IPv4 and 362 IPv6 care-of addresses to its home agent. 364 2.3.2 Foreign network supports IPv4 only 366 If the mobile node is in a foreign network that only supports IPv4, 367 it needs to detect whether a NAT is in its communication path to the 368 home agent. This is done while exchanging the binding update and 369 acknowledgement messages as shown later in this document. If no NAT 370 is detected between the mobile node and the home agent, the mobile 371 node assumes that it is in a foreign network that supports IPv4 372 public addresses. Otherwise, the mobile node assumes that private 373 addresses are used in the foreign network. Note that this assumption 374 is only valid for the purposes of the signaling presented in this 375 specification. A mobile node SHOULD NOT assume that its IPv4 address 376 is globally unique if a NAT device was not detected. The operations 377 of both cases are discussed below. 379 2.3.2.1 Foreign network supports IPv4 only (public addresses) 381 In this scenario the mobile node will need to tunnel IPv6 packets 382 containing the binding update to the home agent's IPv4 address. The 383 mobile node uses the IPv4 address it gets from the foreign network as 384 a source address in the outer header. The binding update will contain 385 the mobile node's IPv6 home address. However, since the care-of 386 address in this scenario is the mobile node's IPv4 address, the 387 mobile node MUST include its IPv4 care-of address in the IPv6 packet. 388 The IPv4 address is represented in the IPv4 Care-of address option 389 defined in this specification. If the mobile node had an IPv4 home 390 address, it MUST also include the IPv4 home address option described 391 in this specification. 393 After accepting the binding update, the home agent MUST create a new 394 binding cache entry for the mobile node's IPv6 home address. If an 395 IPv4 home address option were included, the home agent MUST create 396 another entry for that address. All entries MUST point to the mobile 397 node's IPv4 care-of address. Hence, all packets addressed to the 398 mobile node's home address(es) (IPv4 or IPv6) will be encapsulated in 399 an IPv4 header that includes the home agent's IPv4 address in the 400 source address field and the mobile node's IPv4 care-of address in 401 the destination address field. 403 After accepting the binding updates and creating the corresponding 404 entries, the home agent MUST send a binding acknowledgement as 405 specified in [MIPv6]. In addition, if the binding update included an 406 IPv4 home address option, the binding acknowledgement MUST include 407 the IPv4 address acknowledgment option as described later in this 408 specification. The binding acknowledgement is encapsulated to the 409 IPv4 care-of address. 411 2.3.2.2 Visited network supports IPv4 only (private addresses) 413 In this scenario the mobile node will need to tunnel IPv6 packets 414 containing the binding update to the home agent's IPv4 address. In 415 order to traverse the NAT device, IPv6 packets are tunneled UDP and 416 IPv4. The UDP port allocated for the home agent is TBD. 418 The mobile node uses the IPv4 address it gets from the visited 419 network as a source address in the IPv4 header. The binding update 420 will contain the mobile node's IPv6 home address. 422 After accepting the binding update, the home agent MUST create a new 423 binding cache entry for the mobile node's IPv6 home address. If an 424 IPv4 home address option were included, the home agent MUST create 425 another entry for that address. All entries MUST point to the mobile 426 node's IPv4 care-of address included in the binding update message. 427 In 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 503 Pref The length of the prefix allocated to the mobile 504 node. If only a single address is allocated, 505 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. 510 A value of zero is invalid and MUST be 511 considered an error. 513 P A flag indicating, when set, that the mobile 514 node requests a mobile network prefix. This flag 515 is only relevant for new requests, and must be 516 ignored for binding refreshes. 518 Reserved This field is reserved for future use. It MUST 519 be set to zero by the sender and ignored by the 520 receiver. 522 IPv4 home address The mobile node's IPv4 home address that should 523 be defended by the home agent. This field could 524 contain any unicast IPv4 address (public or 525 private) that was assigned to the mobile node. 526 The value 0.0.0.0 is used to request an IPv4 527 home address from the home agent. A mobile node 528 may choose to use this option to request a 529 prefix by setting the address to the All Zeroes 530 and setting the P flag. The mobile node could 531 then form an IPv4 home address based on the 532 allocated prefix. Alternatively, the mobile node 533 may use two different options, one for 534 requesting an address (Static or Dynamic) and 535 another for requesting a prefix. 537 3.1.2 The IPv4 Care-of Address option 539 This option is included in the Mobility Header including the binding 540 update message sent from the mobile node to a home agent or Mobility 541 Anchor Point. The alignment requirement for this option is 4n. 543 0 1 2 3 544 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 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | Type | Length | Reserved | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | IPv4 Care-of address | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 Type TBD 553 Length 6 555 Reserved This field is set to zero by the sender and 556 ignored by the receiver. 558 IPv4 care-of address This field contains the mobile node's IPv4 care- 559 of address. The IPv4 care-of address is used 560 when the mobile node is located in an IPv4-only 561 network. 563 3.1.3 The Binding Update Message extensions 565 This specification extends the Binding Update message with two new 566 flags. The flags are shown and described below. 568 0 1 2 3 569 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 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Sequence # | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 |A|H|L|K|M|R|F|T| Reserved | Lifetime | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 F When set, this flag indicates a request for 577 forcing UDP encapsulation regardless of whether 578 a NAT is present on the path between the mobile 579 node and the home agent. 581 T When set, this flag indicates that the mobile 582 node requests the use of the TLV-format for 583 encapsulating IPv6 in IPv4. The TLV-format is 584 described later in this document. 586 3.2. Binding Acknowledgement extensions 588 3.2.1 IPv4 address acknowledgement option 590 This option is included in the Mobility Header including the binding 591 acknowledgement message sent from the home agent or Mobility Anchor 592 Point to the mobile node. This option indicates whether a binding 593 cache entry was created for the mobile node's IPv4 address. 594 Additionally, this option can include an IPv4 home address in the 595 case of Dynamic IPv4 home address configuration (i.e. if the 596 unspecified IPv4 address was included in the binding update). The 597 alignment requirement for this option is 4n. 599 0 1 2 3 600 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 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | Type | Length | Status | Pref | Res | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | IPv4 home address | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 Type TBD 609 Length 6 611 Status Indicates success or failure for the IPv4 home 612 address binding. Values from 0 to 127 indicate 613 success. Higher values indicate failure. The 614 following values are reserved: 615 0 Success 616 128 Failure, reason unspecified 617 129 Administratively prohibited 618 130 Incorrect IPv4 home address 619 131 Invalid IPv4 address 620 132 Dynamic IPv4 home address 621 assignment not available 622 133 Prefix allocation unauthorized 624 Pref The prefix length of the address allocated. This 625 field is only valid in case of success and MUST 626 be set to zero and ignored in case of failure. 627 This field overrides what the mobile node 628 requested (if not equal to the requested 629 length). 631 Res This field is reserved for future use. It MUST 632 be set to zero by the sender and ignored by the 633 receiver. 635 IPv4 home address The IPv4 home address that the home agent will 636 use in the binding cache entry. This could be a 637 public or private address. This field MUST 638 contain the mobile node's IPv4 home address. 639 If the address were dynamically allocated the 640 home agent will add the address to inform the 641 mobile node. Otherwise, if the address were 642 statically allocated to the mobile node, the 643 home agent will copy it from the binding update 644 message. 646 3.2.2 The NAT detection option 648 This option is sent from the home agent to the mobile node to 649 indicate whether a NAT was in the path. This option MAY also include 650 a suggested NAT binding refresh time for the mobile node. The 651 alignment requirement for this option is 4n. If a NAT is detected, 652 this option MUST be sent by the home agent. 654 0 1 2 3 655 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 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | Type | Length |F| Reserved | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | Refresh time | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 Type TBD 664 Length 6 666 F This flag indicates to the mobile node that UDP 667 encapsulation is required. When set, this flag 668 indicates that the mobile node MUST use UDP 669 encapsulation even if a NAT is not located 670 between the mobile node and home agent. 672 Reserved This field is reserved for future use. It MUST 673 be set to zero by the sender and ignored by the 674 receiver. 676 Refresh time A suggested time (in seconds) for the mobile 677 node to refresh the NAT binding. If set to zero, 678 it is ignored. If this field is set to the all 679 1s it means that keepalives are not needed, i.e. 680 no NAT was detected. 682 3.2.3 Extensions to the Binding Acknowledgement message 684 This specification extends the binding acknowledgement message with a 685 new flag. The new flag is shown and described below. 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 | Status |K|R|T| Reserved| 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 | Sequence # | Lifetime | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 T This flag indicates, when set, that the sender 694 of the binding acknowledgement supports the TLV- 695 tunnel format. 697 4. Protocol operation 699 This section presents the protocol operation and processing for the 700 messages presented above. In addition, this section introduces the 701 NAT detection and traversal mechanism used by this specification. 703 4.1. Tunnelling formats 705 This speacification allows two different types of UDP-based 706 tunnelling formats to be used between the mobile node and its home 707 agent or MAP. The two formats are vanilla UDP encapsulation and TLV- 708 header UDP encapsulation. A vanilla UDP encapsulation format means 709 the following order of headers: 710 IP (v4 or v6) 711 UDP 712 IP (v4 or v6) 713 Other headers 715 When using this format the receiver would parse the version field 716 following the UDP header in order to determine whether the following 717 header is IPv4 or IPv6. The rest of the headers are processed 718 normally. The above order of headers does not take IPsec headers into 719 account as they may be placed in different parts of the packet. The 720 above format MUST be supported by all implementations of this 721 specification and MUST always be used to send the binding update 722 message. 724 A TLV-header UDP encapsulation is represented by the following order 725 of headers: 726 IP (v4 or v6) 727 UDP 728 TLV-header 729 Other headers 731 The receiver of the TLV-header UDP encapsulated packet expects the 732 TLV-header to follow UDP. The TLV header contains the type of the 733 following message and its length. Hence, the TLV header can carry 734 traffic other than IP. 736 The mobile node negotiates the format for tunnelling payload traffic 737 during the binding exchange. If a mobile node prefers to use the TLV- 738 header UDP encapsulation, it sets the T flag in the binding update 739 sent to the home agent or MAP. If the receiver of the binding update 740 supports the TLV-header format, it SHOULD set the T flag in the 741 binding acknowledgement message. Otherwise, the T flag is cleared. 742 The setting of the T flag in the binding acknowledgement indicates to 743 the mobile node that it must use the TLV-header UDP encapsulation 744 format for all packets sent for the duration of the binding or until 745 a new binding update is sent. Each binding update may renegotiate the 746 tunnelling format. To avoid interoperability issues, the sender of 747 the binding acknowledgement MUST not set the T flag unless it was set 748 in the binding update sent from the mobile node. 750 The TLV-header format is shown below. 752 0 1 2 3 753 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 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 | Type | Length | Reserved | 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 Type This field indicates the type of the payload 759 following this header. 761 Length This field indicates the length of the payload 762 following the header, excluding the TLV-header 763 itself. 765 Reserved This field MUST be set to zero by the sender and 766 ignored by the receiver. 768 The following values are assigned to the Type field, other values may 769 be assigned in future: 771 1 IPv4 772 2 IPv6 773 3 IPsec 774 4 GRE 776 In addition to the UDP-based tunnelling formats described above, this 777 specification allows for standard IP in IP tunnelling. This can take 778 place by tunnelling IPv4 in IPv6 or IP v6 in IPv4. However, whenever 779 a NAT a detected, the mobile node will default to UDP-based 780 encapsulation. The mobile node can request to always use UDP 781 encapsulation by setting the F flag in the binding update. If the 782 home agent does not agree to such request, it MUST reject the binding 783 update with the new Status code: 784 144 Cannot force UDP encapsulation 785 Alternatively, the home agent can force UDP encapsulation by setting 786 the F flag in the NAT detection option included in the binding 787 acknowledgement. 789 4.2. NAT detection and traversal 791 NAT detection is done when the initial binding update message is sent 792 from the mobile node to the home agent. When located in an IPv4-only 793 foreign link, the mobile node sends the binding update message 794 encapsulated in UDP and IPv4. The source address of the IPv6 packet 795 is the mobile node's IPv6 home address. The destination address is 796 the IPv6 address of the home agent. The IPv4 header contains the IPv4 797 care-of address in the source address field and the IPv4 address of 798 the home agent in the destination address field. 800 When the home agent receives the encapsulated binding update it 801 compares the IPv4 address of the source address field in the IPv4 802 header with the IPv4 address in the source address of the IPv6 803 header. If the two addresses match, no NAT device was in the path. 804 Otherwise, a NAT device was in the path and the NAT detection option 805 is included in the binding acknowledgement. The binding 806 acknowledgement, and all future packets, are then encapsulated in UDP 807 and IPv4. The source address in the IPv4 header is the IPv4 address 808 of the home agent. The destination address is the IPv4 address 809 received in the IPv4 header encapsulating the binding update (this 810 address will be different from the IPv4 care-of address when a NAT is 811 in the path). The source port in the packet is the home agent's 812 source port. The destination port is the source port received in the 813 binding update message. Note that the home agent stores the port 814 numbers and associates them with the mobile node's tunnel in order to 815 forward future packets. 817 Upon receiving the binding acknowledgement with the NAT detection 818 option, the mobile node sets the tunnel to the home agent to UDP 819 encapsulation. Hence, all future packets to the home agent are 820 tunneled in UDP and IPv4. For all tunneled IPv6 packets, the source 821 address in the IPv6 header is the mobile node's IPv6 home address and 822 the destination address is the correspondent node's IPv6 address. All 823 tunneled IPv4 packets will contain the mobile node's IPv4 home 824 address in the source address field of the inner IPv4 packet and the 825 correspondent node's IPv4 address in the destination address field. 826 The outer IPv4 header is the same whether the inner packet is IPv4 or 827 IPv6. 829 If no NAT device was detected in the path between the mobile node and 830 the home agent then IPv6 packets are tunneled in an IPv4 header, 831 unless the home agent forces UDP encapsulation using the F flag. The 832 content of the inner and outer headers are identical to the UDP 833 encapsulation case. 835 A mobile node MUST always tunnel binding updates in UDP when located 836 in an IPv4-only network. Essentially, this process allows for 837 perpetual NAT detection. Similarly, the home agent MUST encapsulate 838 binding acknowledgements in a UDP header whenever the binding update 839 is encapsulated in UDP. 841 In conclusion, the packet formats for the binding update and 842 acknowledgement messages are shown below: 844 A. Binding update received by the home agent: 846 IPv4 header (src=V4ADDR, dst=HA_V4ADDR) 847 UDP header 848 IPv6 header (src=V6HOA, dst=HAADDR) 849 ESP-header 850 Mobility header 851 BU [IPv4 HAO] 852 IPv4 CoA option 854 Where V4ADDR is either the IPv4 care-of address or the address 855 provided by the NAT device. V6HOA is the IPv6 home address of the 856 mobile node. The binding update MAY also contain the IPv4 home 857 address option IPv4 HAO. 859 B. Binding acknowledgement sent by the home agent: 860 IPv4 header (src= HA_V4ADDR, dst=V4ADDR) 861 UDP header 862 IPv6 header (src=HAADDR, dst=V6HOA) 863 V6HOA (IPv6 home address) 864 Mobility header 865 BA ([IPv4 ACK], NAT DET) 867 Where V6HOA is IPv6 home address of the mobile node. The IPv4 ACK is 868 the IPv4 address acknowledgement option, which is only included if 869 the IPv4 home address option were present in the BU. The NAT DET is 870 the NAT detection option, which MUST be present in the binding 871 acknowledgement message if the binding update was encapsulated in 872 UDP. 874 4.3. NAT Keepalives 876 If a NAT is detected, the mobile node will need to refresh the NAT 877 bindings in order to be reachable from the home agent. NAT bindings 878 can be refreshed through sending and receiving traffic encapsulated 879 in UDP. However, if the mobile node is not active, it will need to 880 periodically send a message to the home agent in order to refresh the 881 NAT binding. This can be done using the binding update message. The 882 binding update/acknowledgement pair will ensure that the NAT bindings 883 are refreshed in a reliable manner. There is no way for the mobile 884 node to know the exact time of the NAT binding. The default time 885 suggested in this specification is NATKATIMEOUT. If the home agent 886 suggests a different refresh period in the binding acknowledgement, 887 the mobile node SHOULD use the value suggested by the home agent. 889 If the refresh time in the NAT detection option in the binding 890 acknowledgement is set to the all 1s, the mobile node need not send 891 messages to refresh the NAT binding. However, the mobile node may 892 still be required to encapsulate traffic in UDP. This scenario may 893 take place when a NAT is not detected, but the home agent still 894 requires the mobile node to use UDP encapsulation. 896 It should be noted that a mobile node that does not need to be 897 reachable (i.e. only cares about the session continuity aspect of 898 Mobile IP) does not need to refresh NAT binding. In this case, the 899 mobile node would only be able to initiate communication with other 900 nodes. 902 4.4. Mobile node operation 904 In addition to the operations specified in [MIPv6] and [NEMO], this 905 specification requires mobile nodes to be able to support an IPv4 906 home address. 908 When sending an IPv6 packet containing a binding update while 909 connected to an IPv4-only access network, mobile nodes MUST ensure 910 the following: 912 - The IPv6 packet is encapsulated in the vanilla UDP encapsulation 913 format. 914 - The source address in the IPv4 header is the mobile node's IPv4 915 care-of address 916 - The destination address in the IPv4 header is the home agent's 917 IPv4 address. 918 - The source address in the IPv6 header is the mobile node's IPv6 919 home address. 920 - The IPv4 home address option MAY be included in the mobility 921 header. This option contains the IPv4 home address. If the mobile 922 node did not have a static home address it MAY include the 923 unspecified IPv4 address, which acts as a request for a dynamic 924 IPv4 home address. Alternatively, one or more IPv4 home address 925 options may be included with requests for IPv4 prefixes (i.e. with 926 the P flag set.). 927 - If the mobile node wishes to use UDP encapsulation only, it should 928 set the F flag in the binding update message. 929 - If the mobile node prefers to use the TLV-header format, it should 930 set the T flag in the binding update. 931 - The IPv6 packet MUST be authenticated as per [MIPv6], based on the 932 mobile node's IPv6 home address. 934 When sending a binding update from a visited network that supports 935 IPv6, the mobile node MUST follow the rules specified in [MIPv6]. In 936 addition, if the mobile node has an IPv4 home address or needs one, 937 it MUST include the IPv4 home address option in the mobility header. 938 If the mobile node already has a static IPv4 home address, such 939 address MUST be included in the IPv4 home address option. Otherwise, 940 if the mobile node needs a dynamic IPv4 address, it MUST include the 941 IPv4 unspecified address in the IPv4 home address option. 943 When the mobile node receives a binding acknowledgement from the home 944 agent, it follows the rules in [MIPv6] and [NEMO]. In addition, the 945 following actions MUST be made: 947 - If the status field indicated failure with error code 144, the 948 mobile node MAY resend the binding update without setting the F 949 flag. 950 - If the mobility header includes an IPv4 address acknowledgement 951 option indicating success, the mobile node should create two 952 entries in its binding update list, one for the IPv6 home address 953 and another for the IPv4 home address. 954 - If the NAT detection option were present, the mobile node 955 MUST tunnel future packets in UDP and IPv4. This MUST be indicated 956 in the binding update list. 957 - If no IPv4 address acknowledgement option were present, and an 958 IPv4 home address option was present in the binding update, the 959 mobile node MUST only create one binding update list entry for its 960 IPv6 home address. The mobile node MAY include the IPv4 home 961 address option in future binding updates. 962 - If an IPv4 address acknowledgement option were present and it 963 indicates failure for the IPv4 home address binding, the mobile 964 node MUST NOT create an entry for that address in its binding 965 update list. The mobile node MAY include the IPv4 home address 966 option in future binding updates. 967 - If the T flag was set in the binding update and the binding 968 acknowledgement included a T flag set, the mobile node MUST use the 969 TLV-header UDP encapsulation format. 971 4.4.1 Sending packets from a visited network. 973 When the mobile node is located in an IPv6-enabled network it sends 974 and receives IPv6 packets as described in [MIPv6]. IPv4 traffic is 975 encapsulated in IPv6 packets to the home agent. 977 When the mobile node is located in an IPv4 only network, it will send 978 IPv6 packets to its home agent according to the following format: 980 IPv4 header (src=V4CoA, dst=HA_V4ADDR) 981 [UDP header] 982 IPv6 header (src=V6HoA, dst=CN) 983 Upper layer protocols 985 Where the UDP header is only used if a NAT were detected between the 986 mobile node and the home agent, or if the home agent forced UDP 987 encapsulation. V4CoA is the IPv4 care-of address configured by the 988 mobile node in the visited network. 990 Similarly, IPv4 packets are sent according to the following format: 992 IPv4 header (src=V4CoA, dst=HA_V4ADDR) 993 [UDP header] 994 IPv4 header (src=V4HoA, dst=V4CN) 995 Upper layer protocols 997 Where the UDP header is only used if a NAT were detected between the 998 mobile node and the home agent, or if the home agent forced UDP 999 encapsulation. 1001 If the mobile node requested, and the home agent agreed, to use the 1002 TLV-header UDP encapsulation format, then the TLV-header would be 1003 used after the UDP header. 1005 4.4.2 Movement detection in IPv4-only networks 1007 [MIPv6] describes movement detection mostly based on IPv6-specific 1008 triggers. Such triggers would not be available in an IPv4-only 1009 network. Hence, a mobile node located in an IPv4-only network SHOULD 1010 use [DNAv4] for guidance on movement detection mechanisms in IPv4- 1011 only networks. 1013 4.5. Home agent operations 1015 In addition to the home agent specification in [MIPv6] and [NEMO], 1016 the home agent needs to be able to process the IPv4 home address 1017 option and generate the IPv4 address acknowledgement option. Both 1018 options are included in the mobility header. Furthermore, the home 1019 agent MUST be able to detect the presence of a NAT device and 1020 indicate that in the NAT detection option included in the binding 1021 acknowledgement. 1023 A home agent must also act as a proxy for address resolution in IPv4 1024 for the registered IPv4 home addresses of mobile nodes it is serving. 1025 Moreover, the administrative domain of the home agent is responsible 1026 for advertising the routing information of registered IPv4 mobile 1027 network prefixes of the mobile nodes. 1029 In order to comply with this specification, the home agent MUST be 1030 able to find the IPv4 home address of a mobile node when given the 1031 IPv6 home address. That is, given an IPv6 home address, the home 1032 agent MUST store the corresponding IPv4 home address if a static one 1033 is present. If a dynamic address were requested by the mobile node, 1034 the home agent MUST store that address (associated with the IPv6 home 1035 address) after it's allocated to the mobile node. 1037 When the home agent receives a binding update encapsulated in UDP and 1038 containing the IPv4 home address option, it needs to follow all the 1039 steps in [MIPv6] and [NEMO]. In addition, the following checks MUST 1040 be done: 1042 - If the IPv4 care-of address in the IPv4 CoA option is not the same 1043 as the IPv4 address in the source address in the IPv4 header then 1044 a NAT was in the path. This information should be flagged for the 1045 binding acknowledgement. 1047 - If the F flag in the binding update were set, the home agent needs 1048 to determine whether it accepts forcing UDP encapsulation. If it 1049 does not, the binding acknowledgement is sent with error code 144. 1051 UDP encapsulation MUST NOT be used when the mobile node is located 1052 in an IPv6-enabled link. 1054 - If the T flag was set in the binding update, the home agent needs 1055 to determine whether it can accept the TLV-header encapsulation 1056 format. If it does, it should set the T flag in the binding 1057 acknowledgement. Otherwise, the home agent MUST NOT set the T flag 1058 in the binding acknowledgement. 1060 - If the IPv4 home address option contains a valid unicast IPv4 1061 address, the home agent MUST check that this address is allocated 1062 to the mobile node that has the IPv6 home address included in the 1063 home address option. The same MUST be done for an IPv4 prefix. 1065 - If the IPv4 home address option contained the unspecified IPv4 1066 address, the home agent SHOULD dynamically allocate an IPv4 home 1067 address to the mobile node. If none is available, the home agent 1068 MUST return error code 132 in the status field of the IPv4 address 1069 acknowledgement option. If a prefix were requested, the home agent 1070 MUST allocate a prefix with the requested length; otherwise the 1071 home agent MUST indicate failure of the operation with the 1072 appropriate error code. 1074 - If the binding update is accepted for the IPv4 home address, the 1075 home agent creates a binding cache entry for the IPv4 home 1076 address/prefix. The home agent MUST include an IPv4 acknowledgement 1077 option in the mobility header containing the binding 1078 acknowledgement. 1080 If the binding update is accepted for both IPv4 and IPv6 home 1081 addresses, the home agent creates separate binding cache entries, one 1082 for each home address. The care-of address is the one included in the 1083 binding update. If the care-of address is an IPv4 address, the home 1084 agent MUST setup a tunnel to the IPv4 care-of address of the mobile 1085 node. 1087 When sending a binding acknowledgement to the mobile node, the home 1088 agent constructs the message according to [MIPv6] and [NEMO]. Note 1089 that the routing header MUST always contain the IPv6 home address as 1090 specified in [MIPv6]. 1092 If the care-of address of the mobile node were an IPv4 address, the 1093 home agent includes the mobile node's IPv6 home address in the 1094 destination address field in the IPv6 header. If a NAT were detected, 1095 the home agent MUST then encapsulate the packet in UDP and an IPv4 1096 header. The source address is set to the home agent's IPv4 address 1097 and the destination address is set to the address received in the 1098 source address of the IPv4 header encapsulating the binding update. 1100 After creating a binding cache entry for the mobile node's home 1101 addresses, all packets sent to the mobile node's home addresses are 1102 tunneled by the home agent to the mobile node's care-of address. If a 1103 NAT were detected, packets are encapsulated in UDP and IPv4. 1104 Otherwise, if the care-of address is an IPv4 address, and no NAT were 1105 detected, packets are encapsulated in an IPv4 header. 1107 4.5.1 Sending packets to the mobile node 1109 The home agent follows the rules specified in [MIPv6] for sending 1110 IPv6 packets to mobile nodes located in IPv6 networks. When sending 1111 IPv4 packets to When mobile nodes in an IPv6 network, the home agent 1112 must encapsulate the IPv4 packets in IPv6. 1114 When sending IPv6 packets to a mobile node located in an IPv4 1115 network, the home agent must follow the format negotiated in the 1116 binding update/acknowledgement exchange. In the absence of a 1117 negotiated format, the default format that MUST be supported by all 1118 implementations is: 1120 IPv4 header (src= HA_V4ADDR, dst= V4ADDR) 1121 [UDP header] 1122 IPv6 header (src=CN, dst= V6HoA) 1123 Upper layer protocols 1125 Where the UDP header is only included if a NAT were detected between 1126 the mobile node and the home agent, or if the home agent forced UDP 1127 encapsulation. V4ADDR is the IPv4 address received in the source 1128 address field of the IPv4 packet containing the binding update. 1130 When sending IPv4 packets to a mobile node located in an IPv4 1131 network, the home agent must follow the format negotiated in the 1132 binding update/acknowledgement exchange. In the absence of a 1133 negotiated format, the default format that MUST be supported by all 1134 implementations is: 1136 IPv4 header (src= HA_V4ADDR, dst= V4ADDR) 1137 [UDP header] 1138 IPv4 header (src=V4CN, dst= V4HoA) 1139 Upper layer protocols 1141 Where the UDP header is only included if a NAT were detected between 1142 the mobile node and home agent, or if the home agent forced UDP 1143 encapsulation. 1145 4.6. Correspondent node operations 1147 This specification has no impact on IPv4 or IPv6 correspondent nodes. 1149 5. Security considerations 1151 This specification allows a mobile node to send one binding update 1152 for its IPv6 and IPv4 home addresses. This is a slight deviation from 1154 [MIPv6] which requires one binding update per home address. However, 1155 like [MIPv6], the IPsec security association needed to authenticate 1156 the binding update is still based on the mobile node's IPv6 home 1157 address. Therefore, in order to authorize the mobile node's IPv4 home 1158 address binding, the home agent MUST store the IPv4 address 1159 corresponding to the IPv6 address that is allocated to a mobile node. 1160 Therefore, it is sufficient for the home agent to know that the IPsec 1161 verification for the packet containing the binding update was valid 1162 provided that it knows which IPv4 home address is associated with 1163 which IPv6 home address. Hence, the security of the IPv4 home address 1164 binding is the same as the IPv6 binding. 1166 In effect, associating the mobile node's IPv4 home address with its 1167 IPv6 home address moves the authorization of the binding update for 1168 the IPv4 address to the Mobile IPv6 implementation, which infers it 1169 from the fact that mobile node has an IPv6 home address and the right 1170 credentials for sending an authentic binding update for such address. 1172 In cases where this specification is used for NAT traversal, it is 1173 important to note that it has the same UNSAF vulnerabilities 1174 associated with RFC 3519. An attacker is able to hijack the mobile 1175 node's session with the home agent if it can modify the contents of 1176 the outer IPv4 header. The contents of the header are not 1177 authenticated and there is no way for the home agent to verify their 1178 validity. Hence, a man in the middle attack where a change in the 1179 contents of the IPv4 header can cause a legitimate mobile node's 1180 traffic to be diverted to an illegitimate receiver independently of 1181 the authenticity of the binding update message. 1183 In this specification the binding update message MUST be protected 1184 using ESP transport mode. When the mobile node is located in an IPv4- 1185 only network, the binding update message is encapsulated in UDP as 1186 described earlier. However, UDP MUST NOT be used to encapsulate the 1187 binding update message when the mobile node is located in an IPv6- 1188 enabled network. If protection of payload traffic is needed when the 1189 mobile node is located in an IPv4-only network, encapsulation is done 1190 using tunnel mode ESP over port 4500 as described in [TUNSEC]. 1192 Handovers within private IPv4 networks or from IPv6 to IPv4 networks 1193 will have impacts on the security association between the mobile node 1194 and the home agent. The following section presents the expected 1195 behaviour of the mobile node and home agent in those situations. 1197 5.1 Handover interactions for IPsec and IKE 1199 After the mobile node detects movement it updates its tunnel 1200 information depending on the network capability. If the new link is 1201 IPv4-only then the mobile node updates its tunnel to UDP using the 1202 DSMIPv6 port and the local IPv4 address. Furthermore, the mobile node 1203 updates its local Security Association information to include its 1204 local IPv4 address and with the remote address being the home agent's 1205 IPv4 address. The mobile node also removes binding update list 1206 entries for correspondent nodes since route optimisation cannot be 1207 supported while the mobile node is in an IPv4-only network. This may 1208 cause inbound packet losses as remote correspondent node are unaware 1209 of such movement. Following this, the mobile node sends the binding 1210 update message to the home agent. 1212 Upon receiving the binding update message, the home agent updates it 1213 security association locally to include the mobile node's remote 1214 address as the IP address received in the outer header. When the 1215 mobile node is located in a private IPv4 network (which is detected 1216 as described above), this address is the public address allocated by 1217 the NAT. Based on the setting of the K flag in the binding update, 1218 the home agent updates its IKE security association to include the 1219 remote address as that received in the outer header of the binding 1220 update message. If the mobile node were located in a private IPv4 1221 network this address is likely to be wrong as the NAT would likely 1222 allocate a different address to the IKE messages. Hence, the mobile 1223 node MUST update the IKE SA in one of two ways as follows. The mobile 1224 node SHOULD send an empty informational message, which results in the 1225 IKE module in the home agent to dynamically update the SA 1226 information. Alternatively, the IKE SA should be re-negotiated. Note 1227 that updating the IKE SA MUST take place after the mobile node has 1228 sent the binding update and received the acknowledgement from the 1229 home agent. 1231 The mobile node MAY use [MOBIKE] to update its IKE SA with the home 1232 agent. Using MOBIKE requires negotiating this capability with the 1233 home agent when establishing the SA. In this case, the mobile node 1234 and the home agent need not update their IPsec SAs locally as this 1235 step is performed by MOBIKE. Furthermore, the use of MOBIKE allows 1236 the mobile node to update the SA independently of the binding update 1237 exchange. Hence, there is no need for the mobile node to wait for a 1238 binding acknowledgement before performing MOBIKE. The use of MOBIKE 1239 is OPTIONAL in this specification. 1241 6. Protocol constants 1243 NATKATIMEOUT 110 seconds 1245 7. Acknowledgements 1247 Thanks to the following members (in alphabetical order) of the MIP6 1248 and NEMO Working Groups for their contributions, discussion, and 1249 review: Jari Arkko, Sri Gundavelli, Wassim Haddad, Conny Larsson, 1250 Ahmad Muhanna, Vidya Narayanan, Karen Neilsen and Keiichi Shima. 1251 Thanks to Karen Neilsen, Pasi Eronen and Christian Kaas-Petersen for 1252 raising the issue of IKEv2 interactions and proposing the solution 1253 included in this document. 1255 8. IANA considerations 1257 The specification requires the following allocations from IANA: 1258 - A UDP port is needed for the NAT traversal mechanism described in 1259 section 4.1. 1260 - The IPv4 home address option described in section 3.1.1 requires an 1261 option type. This option is included in the Mobility header 1262 described in [MIPv6]. 1263 - The IPv4 address acknowledgement option described in section 3.2.1 1264 requires a new option type. This option is included in the Mobility 1265 header described in [MIPv6]. 1266 - The NAT detection option described in section 3.2.2 requires a new 1267 option type. This option is included in the Mobility header 1268 described in [MIPv6]. 1269 - The IPv4 Care-of address option described in section 3.1.2 requires 1270 an option type. This option is included in the Mobility header 1271 described in [MIPv6]. 1273 9. References 1275 NORMATIVE 1277 [IPv6] S. Deering and B. Hinden, "Internet Protocol version 6 (IPv6) 1278 specification", RFC 2460 1280 [MIPv6] D. Johnson, C. Perkins and J. Arkko, "Mobility Support in 1281 IPv6", RFC 3775, June 2004. 1283 [NEMO] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 1284 "Network Mobility (NEMO) Basic Support protocol", RFC 3963, 1285 January 2005. 1287 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 1288 Requirement Levels", BCP 14, RFC 2119, March 1997. 1290 [SEC] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 1291 Protect Mobile IPv6 Signaling between Mobile Nodes and Home 1292 Agents", RFC 3776, June 2004. 1294 [TUNSEC] Huttunen, A., Swander, B., Volpe, V., DiBurro, L. and M. 1295 Stenberg, "UPD Encapsulation for IPsec ESP Packets", RFC 1296 3948, January 2005. 1298 INFORMATIVE 1300 [BOOT] Giaretta, G. (Ed.), Kempf J., and V. Devarapalli, " Mobile 1301 IPv6 bootstrapping in split scenario", draft-ietf-mip6- 1302 bootstrapping-split, June 2005, work in progress. 1304 [HMIPv6] Soliman, H., Castelluccia, C., ElMalki, K., and L. Bellier, 1305 "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", 1306 Draftietf-mipshop-4140bis-04 November 2007. 1308 [INTBOOT] K. Chowdhury and A. Yegin, "MIP6-bootstrapping for the 1309 Integrated Scenario", draft-ietf-mip6-bootstrapping- 1310 integrated-dhc-02, Work in Progress. 1312 [MIP-PB] Tsirtsis, G., and H. Soliman, "Mobility management for 1313 Dual stack mobile nodes, A Problem Statement", 1314 RFC 4977, August 2007. 1316 [MIPv4] C. Perkins, "Mobility Support for IPv4", RFC3344 1318 [MOBIKE] P. Eronen,"IKEv2 Mobility and Multihoming Protocol (MOBIKE)" 1319 , RFC 4555, June 2006. 1321 [SNRIO] Larsson, T., Gustafsson, E., and H. Levkowetz, "Use of MIPv6 1322 in IPv4 and MIPv4 in IPv6 networks", draft-larsson-v6ops- 1323 mip-scenarios-01.txt, February 2004. 1325 10. Contributors 1327 This document reflects discussions and contributions from several 1328 people including (in alphabetical order): 1330 Vijay Devarapalli 1331 E-mail: vijay.devarapalli@azairenet.com 1333 James Kempf 1334 E-mail: kempf@docomolabs-usa.com 1336 Henrik Levkowetz 1337 E-mail: henrik@levkowetz.com 1339 Pascal Thubert 1340 E-mail: pthubert@cisco.com 1342 George Tsirtsis 1343 E-mail1: G.Tsirtsis@Qualcomm.com 1344 E-mail2: tsirtsisg@yahoo.com 1346 Wakikawa Ryuji 1347 ryuji@sfc.wide.ad.jp 1349 Author's Address 1351 Hesham Soliman 1352 Elevate Technologies 1353 E-mail: Hesham@elevatemobile.com 1355 Intellectual Property Statement 1357 The IETF takes no position regarding the validity or scope of any 1358 Intellectual Property Rights or other rights that might be claimed to 1359 pertain to the implementation or use of the technology described in 1360 this document or the extent to which any license under such rights 1361 might or might not be available; nor does it represent that it has 1362 made any independent effort to identify any such rights. Information 1363 on the IETF's procedures with respect to rights in IETF Documents can 1364 be found in RFC 3667 (BCP 78) and RFC 3668 (BCP 79). 1366 Copies of IPR disclosures made to the IETF Secretariat and any 1367 assurances of licenses to be made available, or the result of an 1368 attempt made to obtain a general license or permission for the use of 1369 such proprietary rights by implementers or users of this 1370 specification can be obtained from the IETF on-line IPR repository at 1371 http://www.ietf.org/ipr. 1373 The IETF invites any interested party to bring to its attention any 1374 copyrights, patents or patent applications, or other proprietary 1375 rights that may cover technology that may be required to implement 1376 this standard. Please address the information to the IETF at ietf- 1377 ipr@ietf.org. 1379 Full Copyright Statement 1381 Copyright (C) The IETF Trust (2007). This document is subject to the 1382 rights, licenses and restrictions contained in BCP 78, and except as 1383 set forth therein, the authors retain all their rights. 1385 Disclaimer of Validity 1387 This document and the information contained herein are provided on an 1388 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1389 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1390 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1391 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1392 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1393 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1395 This Internet-Draft expires May, 2008.