idnits 2.17.1 draft-ietf-mext-nemo-v4traversal-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 7, 2009) is 5497 days in the past. Is this intentional? 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 1626, but not defined == Missing Reference: 'IPv4 ACK' is mentioned on line 1663, but not defined == Missing Reference: 'CERTREQ' is mentioned on line 1543, but not defined == Missing Reference: 'N' is mentioned on line 1675, but not defined == Missing Reference: 'KEi' is mentioned on line 1675, but not defined == Missing Reference: 'KEr' is mentioned on line 1679, but not defined == Unused Reference: 'RFC2473' is defined on line 1796, but no explicit reference was found in the text == Unused Reference: 'RFC4306' is defined on line 1814, but no explicit reference was found in the text == Unused Reference: 'RFC3978' is defined on line 1852, but no explicit reference was found in the text == Unused Reference: 'RFC4213' is defined on line 1855, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 3344 (Obsoleted by RFC 5944) -- Obsolete informational reference (is this intentional?): RFC 3978 (Obsoleted by RFC 5378) -- Obsolete informational reference (is this intentional?): RFC 4844 (Obsoleted by RFC 8729) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) -- Obsolete informational reference (is this intentional?): RFC 5405 (Obsoleted by RFC 8085) Summary: 3 errors (**), 0 flaws (~~), 11 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Soliman, Ed. 3 Internet-Draft Elevate Technologies 4 Intended status: Standards Track April 7, 2009 5 Expires: October 9, 2009 7 Mobile IPv6 Support for Dual Stack Hosts and Routers 8 draft-ietf-mext-nemo-v4traversal-10.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on October 9, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 The current Mobile IPv6 and NEMO specifications support IPv6 only. 47 This specification extends those standards to allow the registration 48 of IPv4 addresses and prefixes, respectively, and the transport of 49 both IPv4 and IPv6 packets over the tunnel to the home agent. This 50 specification also allows the Mobile Node to roam over both IPv6 and 51 IPv4, including the case where Network Address Translation is present 52 on the path between the mobile node and its home agent. 54 Table of Contents 56 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 57 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 2.1. Motivation for Using Mobile IPv6 Only . . . . . . . . . . 6 59 2.2. Scenarios Considered by This Specification . . . . . . . . 6 60 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 9 61 3.1. Home Agent Address Discovery . . . . . . . . . . . . . . . 9 62 3.2. Mobile Prefix Solicitation and Advertisement . . . . . . . 10 63 3.3. Binding Management . . . . . . . . . . . . . . . . . . . . 10 64 3.3.1. Foreign Network Supports IPv6 . . . . . . . . . . . . 11 65 3.3.2. Foreign Network Supports IPv4 Only . . . . . . . . . . 11 66 3.4. Route Optimization . . . . . . . . . . . . . . . . . . . . 13 67 3.5. Dynamic IPv4 Home Address Allocation . . . . . . . . . . . 14 68 4. Extensions And Modifications To Mobile IPv6 . . . . . . . . . 15 69 4.1. Binding Update Extensions . . . . . . . . . . . . . . . . 15 70 4.1.1. IPv4 Home Address Option . . . . . . . . . . . . . . . 15 71 4.1.2. The IPv4 Care-of Address Option . . . . . . . . . . . 16 72 4.1.3. The Binding Update Message Extensions . . . . . . . . 17 73 4.2. Binding Acknowledgement Extensions . . . . . . . . . . . . 17 74 4.2.1. IPv4 Address Acknowledgement Option . . . . . . . . . 17 75 4.2.2. The NAT Detection Option . . . . . . . . . . . . . . . 19 76 5. Protocol operation . . . . . . . . . . . . . . . . . . . . . . 21 77 5.1. Tunelling Formats . . . . . . . . . . . . . . . . . . . . 21 78 5.1.1. tunnelling Impacts on Transport and MTU . . . . . . . 22 79 5.2. NAT Detection . . . . . . . . . . . . . . . . . . . . . . 22 80 5.3. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . . 24 81 5.4. Mobile Node Operation . . . . . . . . . . . . . . . . . . 25 82 5.4.1. Selecting a Care-of address . . . . . . . . . . . . . 25 83 5.4.2. Sending Binding Updates . . . . . . . . . . . . . . . 26 84 5.4.3. Sending Packets from a Visited Network . . . . . . . . 28 85 5.4.4. Movement Detection in IPv4-only Networks . . . . . . . 29 86 5.5. Home agent operation . . . . . . . . . . . . . . . . . . . 29 87 5.5.1. Sending Packets to the Mobile Node . . . . . . . . . . 31 88 5.6. Correspondent Node Operation . . . . . . . . . . . . . . . 32 89 6. Security Considerations . . . . . . . . . . . . . . . . . . . 33 90 6.1. Handover Interactions for IPsec and IKE . . . . . . . . . 34 91 6.2. IKE negotiation messages between the mobile node and 92 Home Agent . . . . . . . . . . . . . . . . . . . . . . . . 36 93 6.2.1. IKEv2 Operation for Securing DSMIPv6 Signaling . . . . 37 94 6.2.2. IKEv2 Operation for Securing Data over IPv4 . . . . . 40 95 7. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 42 96 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43 97 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 98 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45 99 10.1. Normative References . . . . . . . . . . . . . . . . . . . 45 100 10.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 46 101 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 47 102 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 48 104 1. Requirements notation 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 2. Introduction 112 Mobile IPv6 [RFC3775] and [RFC3963] allow mobile nodes to move within 113 the Internet while maintaining reachability and ongoing sessions, 114 using an IPv6 home address or prefix. However, since IPv6 is not 115 widely deployed, it is unlikely that mobile nodes will initially use 116 IPv6 addresses only for their connections. It is reasonable to 117 assume that mobile nodes will, for a long time, need an IPv4 home 118 address that can be used by upper layers. It is also reasonable to 119 assume that mobile nodes will move to networks that might not support 120 IPv6 and would therefore need the capability to support an IPv4 121 Care-of Address. Hence, this specification extends Mobile IPv6 122 capabilities to allow dual stack mobile nodes to request that their 123 home agent (also dual stacked) tunnel IPv4/IPv6 packets addressed to 124 their home addresses, as well as IPv4/IPv6 care-of address(es). 126 Using this specification, mobile nodes would only need Mobile IPv6 127 and [RFC3963] to manage mobility while moving within the Internet; 128 hence eliminating the need to run two mobility management protocols 129 simultaneously. This specification provides the extensions needed in 130 order to allow IPv6 mobility only to be used by dual stack mobile 131 nodes. 133 This specification will also consider cases where a mobile node moves 134 into a private IPv4 network and gets configured with a private IPv4 135 Care-of Address. In these scenarios, the mobile node needs to be 136 able to traverse the IPv4 NAT in order to communicate with the home 137 agent. IPv4 NAT traversal for Mobile IPv6 is presented in this 138 specification. 140 In this specification, the term mobile node refers to both a mobile 141 host and mobile router unless the discussion is specific to either 142 hosts or routers. Similarly, we use the term home address to reflect 143 an address/prefix format. Note that both mobile host and router 144 functionality has already been defined in [RFC3775] and [RFC3963], 145 respectively. This specification does not change that already 146 defined behavior, nor does it extend the specific type of hosts and 147 router support already defined, except for two things: (i) allowing 148 the mobile node to communicate with its home agent even over IPv4 149 networks, and (ii) allowing the use of IPv4 home addresses and 150 prefixes. 152 In this specification, extensions are defined for the binding update 153 and binding acknowledgement. It should be noted that all these 154 extensions apply to cases where the mobile node communicates with a 155 Mobility Anchor Point (MAP) as defined in [RFC5380]. The 156 requirements on the MAP are identical to those stated for the home 157 agent, although it is unlikely that NAT traversal would be needed 158 with a MAP as it is expected to be in the same address domain. 160 2.1. Motivation for Using Mobile IPv6 Only 162 IPv6 offers a number of improvements over today's IPv4, primarily due 163 to its large address space. Mobile IPv6 offers a number of 164 improvements over Mobile IPv4 [RFC3344], mainly due to capabilities 165 inherited from IPv6. For instance, route optimization and dynamic 166 home agent discovery can only be achieved with Mobile IPv6. 168 One of the advantages of the large address space provided by IPv6 is 169 that it allows mobile nodes to obtain a globally unique care-of 170 address wherever they are. Hence, there is no need for Network 171 Address Translator (NAT) traversal techniques designed for Mobile 172 IPv4. This allows Mobile IPv6 to be a significantly simpler and more 173 bandwidth efficient mobility management protocol. At the same time, 174 during the transition towards IPv6, NAT traversal for existing 175 private IPv4 networks needs to be considered. This specification 176 introduces NAT traversal for this purpose. 178 The above benefits make the case for using Mobile IPv6-only for dual 179 stack mobile nodes as it allows for a long lasting mobility solution. 180 The use of Mobile IPv6 for dual stack mobility eliminates the need 181 for changing the mobility solution due to the introduction of IPv6 182 within a deployed network. 184 2.2. Scenarios Considered by This Specification 186 There are several scenarios that illustrate potential 187 incompatibilities for mobile nodes using Mobile IPv6. Some of the 188 problems associated with mobility and transition issues were 189 presented in [RFC4977]. This specification considers the scenarios 190 that address all the problems discussed in [RFC4977]. The scenarios 191 considered in this specification are listed below. 193 All of the following scenarios assume that both the mobile node and 194 the home agent are IPv4 and IPv6-enabled and that only Mobile IPv6 is 195 used between the mobile node and the home agent. We also assume that 196 the home agent is always reachable through a globally unique IPv4 197 address. Finally, it's important to note that the following 198 scenarios are not mutually exclusive. 200 Scenario 1: IPv4-only foreign network 202 In this scenario, a mobile node is connected to an IPv4-only foreign 203 network. The mobile node can only configure an IPv4 Care-of Address. 205 Scenario 2: Mobile node behind a NAT 206 In this scenario, the mobile node is in a private IPv4 foreign 207 network that has a NAT device connecting it to the Internet. If the 208 home agent is located outside the NAT device, the mobile node will 209 need a NAT traversal mechanism to communicate with the home agent. 211 It should be noted that [RFC5389] highlights issues with some types 212 of NATs that act as generic ALGs and rewrite any 32-bit field 213 containing the NAT's public IP addresses. This specification will 214 not support such NATs. 216 Scenario 3: Home Agent behind a NAT 218 In this scenario, the communication between the mobile node and the 219 home agent is further complicated by the fact that the home agent is 220 located within a private IPv4 network. However, in this scenario, we 221 assume that the home agent is allocated a globally unique IPv4 222 address. The address might not be physically configured on the home 223 agent interface. Instead, it is associated with the home agent on 224 the NAPT device, which allows the home agent to be reachable through 225 address or port mapping. 227 Scenario 4: Use Of IPv4-only applications 229 In this scenario, the mobile node may be located in an IPv4, IPv6 or 230 a dual network. However, the mobile node might be communicating with 231 an IPv4-only node. In this case, the mobile node would need a stable 232 IPv4 address for its application. The alternative to using an IPv4 233 address is the use of protocol translators; however, end-to-end 234 communication with IPv4 is preferred to the use of protocol 235 translators. 237 The mobile node may also be communicating with an IPv4-only 238 application that requires an IPv4 address. 240 The cases above illustrate the need for the allocation of a stable 241 IPv4 home address to the mobile node. This is done using an IPv4 242 home address. Since running Mobile IPv4 and Mobile IPv6 243 simultaneously is problematic (as illustrated in [RFC4977]), this 244 scenario adds a requirement on Mobile IPv6 to support IPv4 home 245 addresses. 247 Scenario 5: IPv6 and IPv4-enabled networks 249 In this scenario, the mobile node should prefer the use of an IPv6 250 care-of address for either its IPv6 or IPv4 home address. Nomral IP 251 in IP tunnelling should be used in this scenario as described in 252 [RFC3775]. Under rare exceptions, where IP in IP tunnelling for IPv6 253 does not allow the mobile node to reach the home agent, the mobile 254 node follows the sending algorithm described in Section 5.4.1. UDP 255 tunnelling in IPv6 networks is proposed in this document as a last 256 resort mechanism when reachability cannot be achieved through normal 257 IP in IP tunnelling. It should not be viewed as a normal mode of 258 operation and should not be used as a first resort. 260 3. Solution Overview 262 In order to allow Mobile IPv6 to be used by dual stack mobile nodes, 263 the following needs to be done: 265 o Mobile nodes should be able to use an IPv4 and IPv6 home or 266 care-of address simultaneously and update their home agents 267 accordingly. 269 o Mobile nodes need to be able to know the IPv4 address of the home 270 agent as well as its IPv6 address. There is no need for IPv4 271 prefix discovery however. 273 o Mobile nodes need to be able to detect the presence of a NAT 274 device and traverse it in order to communicate with the home 275 agent. 277 This section presents an overview of the extensions required in order 278 to allow mobile nodes to use Mobile IPv6 only for IP mobility 279 management 281 3.1. Home Agent Address Discovery 283 Dynamic home agent Address Discovery (DHAAD) was defined in [RFC3775] 284 to allow mobile nodes to discover their home agents by appending a 285 well-known anycast interface identifier to their home link's prefix. 286 However, this mechanism is based on IPv6-anycast routing. If a 287 mobile node is located in an IPv4-only foreign network, it cannot 288 rely on native IPv6 routing. In this scenario, the solution for 289 discovering the home agent's IPv4 address is through the Domain Name 290 System (DNS). If the MN is attached to an IPv6-only or dual stack 291 network, it may also use procedures defined in 292 [I-D.ietf-mip6-bootstrapping-integrated-dhc] to discover home agent 293 information. Note that the use of 294 [I-D.ietf-mip6-bootstrapping-integrated-dhc] cannot give the mobile 295 node information that allows it to communicate with the home agent if 296 the mobile node is located in an IPv4-only network. In this 297 scenario, the mobile node needs to discover the IPv4 address of its 298 home agent through the DNS. 300 For DNS lookup by name, the mobile node should be configured with the 301 name of the home agent. When the mobile node needs to discover a 302 home agent, it sends a DNS request with QNAME set to the configured 303 name. An example is "ha1.example.com". If a home agent has an IPv4 304 and IPv6 address, the corresponding DNS record should be configured 305 with both 'AAAA' and 'A' records. Accordingly, the DNS reply will 306 contain 'AAAA' and 'A' records. 308 For DNS lookup by service, the SRV record defined in [RFC5026] is 309 reused. For instance, if the service name is "mip6" and the protocol 310 name is "ipv6" in the SRV record, the mobile node SHOULD send a DNS 311 request with the QNAME set to "_mip6._ipv6.example.com". The 312 response should contain the home agent's FQDN(s) and may include the 313 corresponding 'AAAA' and 'A' records as well. 315 If multiple home agents reside on the home link, each configured with 316 a public IPv4 address, then the operation above applies. The correct 317 DNS entries can be configured accordingly. 319 3.2. Mobile Prefix Solicitation and Advertisement 321 According to [RFC3775], the mobile node can send a Mobile Prefix 322 Solicitation and receive a Mobile Prefix Advertisement containing all 323 prefixes advertised on the home link. 325 A dual stack mobile node MAY send a Mobile Prefix Solicitation 326 message encapsulated in IPv4 (i.e., IPv6 in IPv4) in the case where 327 the mobile node has no access to IPv6 within the local network. 328 Securing these messages requires the mobile node to have a security 329 association with the home agent, using IPsec and based on the mobile 330 node's IPv4 care-of address as described in [RFC3775], and [RFC4877]. 332 [RFC3775] requires the mobile node to include the home address option 333 in the solicitation message sent to the home agent. If the mobile 334 node is located in an IPv4 network, it will not be assigned an IPv6 335 address to include in the source address. In this case, the mobile 336 node MUST use its home address in the source address field of the 337 IPv6 packet, in addition to using the home address option as expected 338 by [RFC3775]. 340 3.3. Binding Management 342 A dual stack mobile node will need to update its home agent with its 343 care-of address. If a mobile node has an IPv4 and an IPv6 home 344 address, it will need to create a binding cache entry for each 345 address. The format of the IP packet carrying the binding update and 346 acknowledgement messages will vary depending on whether the mobile 347 node has access to IPv6 in the visited network. There are three 348 different scenarios to consider with respect to the visited network: 350 o The visited network has IPv6 connectivity and provides the mobile 351 node with a care-of address (in a stateful or stateless manner). 353 o The mobile node can only configure a globally unique IPv4 address 354 in the visited network. 356 o The mobile node can only configure a private IPv4 address in the 357 visited network. 359 3.3.1. Foreign Network Supports IPv6 361 In this case, the mobile node is able to configure a globally unique 362 IPv6 address. The mobile node will send a binding update to the IPv6 363 address of its home agent, as defined in [RFC3775]. The binding 364 update MAY include the IPv4 home address option introduced in this 365 document. After receiving the binding update, the home agent creates 366 two binding cache entries, one for the mobile node's IPv4 home 367 address, and another for the mobile node's IPv6 home address. Both 368 entries will point to the mobile node's IPv6 care-of address. Hence, 369 whenever a packet is addressed to the mobile node's IPv4 or IPv6 home 370 addresses, the home agent will tunnel it in IPv6 to the mobile node's 371 IPv6 care-of address included in the binding update. Effectively, 372 the mobile node establishes two different tunnels, one for its IPv4 373 traffic (IPv4 in IPv6) and one for its IPv6 traffic (IPv6 in IPv6) 374 with a single binding update. 376 In this scenario, this document extends [RFC3775] by including the 377 IPv4 home address option in the binding update message. Furthermore, 378 if the network supports both IP v4 and IPv6, or if the mobile node is 379 experiencing problems with IP in IP tunnelling, this document 380 proposes some mitigating actions as described in Section 5.4.1 382 After accepting the binding update and creating the corresponding 383 binding cache entries, the home agent MUST send a binding 384 acknowledgement to the mobile node as defined in [RFC3775]. In 385 addition, if the binding update included an IPv4 home address option, 386 the binding acknowledgement MUST include the IPv4 address 387 acknowledgment option as described later in this specification. This 388 option informs the mobile node whether the binding was accepted for 389 the IPv4 home address. If this option is not included in the binding 390 acknowledgement and the IPv4 home address option was included in the 391 binding update, the mobile node MUST assume that the home agent does 392 not support the IPv4 home address option and therefore SHOULD NOT 393 include the option in future binding updates to that home agent 394 address. 396 When a mobile node acquires both IPv4 and IPv6 care-of addresses at 397 the foreign network, it SHOULD prioritize the IPv6 care-of address 398 for its MIPv6 binding as described in Section 5.4.1. 400 3.3.2. Foreign Network Supports IPv4 Only 402 If the mobile node is in a foreign network that only supports IPv4, 403 it needs to detect whether a NAT is in its communication path to the 404 home agent. This is done while exchanging the binding update and 405 acknowledgement messages as shown later in this document. NAT 406 detection is needed for the purposes of the signaling presented in 407 this specification. 409 3.3.2.1. Foreign Network Supports IPv4 Only (Public Addresses) 411 In this scenario the mobile node will need to tunnel IPv6 packets 412 containing the binding update to the home agent's IPv4 address. The 413 mobile node uses the IPv4 address it gets from the foreign network as 414 a source address in the outer header. The binding update will 415 contain the mobile node's IPv6 home address. However, since the 416 care-of address in this scenario is the mobile node's IPv4 address, 417 the mobile node MUST include its IPv4 care-of address in the IPv6 418 packet. The IPv4 address is represented in the IPv4 Care-of address 419 option defined in this specification. If the mobile node had an IPv4 420 home address, it MUST also include the IPv4 home address option 421 described in this specification. 423 After accepting the binding update, the home agent MUST create a new 424 binding cache entry for the mobile node's IPv6 home address. If an 425 IPv4 home address option were included, the home agent MUST create 426 another entry for that address. All entries MUST point to the mobile 427 node's IPv4 care-of address. Hence, all packets addressed to the 428 mobile node's home address(es) (IPv4 or IPv6) will be encapsulated in 429 an IPv4 header that includes the home agent's IPv4 address in the 430 source address field and the mobile node's IPv4 care-of address in 431 the destination address field. 433 After accepting the binding updates and creating the corresponding 434 entries, the home agent MUST send a binding acknowledgement as 435 specified in [RFC3775]. In addition, if the binding update included 436 an IPv4 home address option, the binding acknowledgement MUST include 437 the IPv4 address acknowledgment option as described later in this 438 specification. The binding acknowledgement is encapsulated to the 439 IPv4 care-of address, which was included in the source address field 440 of the IPv4 header encapsulating the binding update. 442 3.3.2.2. Foreign Network Supports IPv4 Only (Private Addresses) 444 In this scenario the mobile node will need to tunnel IPv6 packets 445 containing the binding update to the home agent's IPv4 address. In 446 order to traverse the NAT device, IPv6 packets are tunneled using UDP 447 and IPv4. The UDP port allocated for the home agent is TBD_DSMIPv6. 449 The mobile node uses the IPv4 address it gets from the visited 450 network as a source address in the IPv4 header. The binding update 451 will contain the mobile node's IPv6 home address. 453 After accepting the binding update, the home agent MUST create a new 454 binding cache entry for the mobile node's IPv6 home address. If an 455 IPv4 home address option were included, the home agent MUST create 456 another entry for that address. All entries MUST point to the mobile 457 node's IPv4 care-of address included in the source address of the 458 IPv4 header that encapsulated the binding update message. In 459 addition, the tunnel used MUST indicate UDP encapsulation for NAT 460 traversal. Hence, all packets addressed to the mobile node's home 461 address(es) (IPv4 or IPv6) will be encapsulated in UDP then 462 encapsulated in an IPv4 header that includes the home agent's IPv4 463 address in the source address field and the mobile node's IPv4 care- 464 of address in the destination address field. Note that the home 465 agent MUST store the source UDP port numbers contained in the packet 466 carrying the binding update in order to be able to forward packets to 467 the mobile node. 469 After accepting the binding updates and creating the corresponding 470 entries, the home agent MUST send a binding acknowledgement as 471 specified in [RFC3775]. In addition, if the binding update included 472 an IPv4 home address option, the binding acknowledgement MUST include 473 the IPv4 address acknowledgment option as described later in this 474 specification. The binding acknowledgement is encapsulated in UDP 475 then IPv4 with the home agent's IPv4 address in the source address 476 field and the mobile node's IPv4 care-of address in the destination 477 field. The IPv4 address in the destination field of the IPv4 packet 478 is the source address received in the IPv4 header containing the 479 binding update message. The inner IPv6 packet will contain the home 480 agent's IPv6 address as a source address and the mobile node's IPv6 481 home address in the destination address field. 483 The mobile node needs to maintain the NAT bindings for its current 484 IPv4 care-of address. This is done through sending the binding 485 update regularly to the home agent. 487 3.4. Route Optimization 489 Route optimization, as specified in [RFC3775] will operate in an 490 identical manner for dual stack mobile nodes when they are located in 491 a visited network that provides IPv6 addresses to the mobile node and 492 while communicating with an IPv6-enabled correspondent node. 493 However, when located in an IPv4-only network, or when using the IPv4 494 home address to communicate with an IPv4 correspondent node, route 495 optimization will not be possible due to the difficulty of performing 496 the return routability test. In this specification, UDP 497 encapsulation is only used between the mobile node and its home 498 agent. Therefore, mobile nodes will need to communicate through the 499 home agent. 501 Route optimization will not be possible for IPv4 traffic. That is, 502 traffic addressed to the mobile node's IPv4 home address. This is 503 similar to using Mobile IPv4, therefore there is no reduction of 504 features resulting from using this specification. 506 3.5. Dynamic IPv4 Home Address Allocation 508 It is possible to allow for the mobile node's IPv4 home address to be 509 allocated dynamically. This is done by including 0.0.0.0 in the IPv4 510 home address option included in the binding update. The home agent 511 SHOULD allocate an IPv4 address to the mobile node and include it in 512 the IPv4 address acknowledgement option sent to the mobile node. In 513 this case, the lifetime of the binding is bound to the minimum of the 514 lifetimes of the IPv6 binding and the lease time of the IPv4 home 515 address. 517 4. Extensions And Modifications To Mobile IPv6 519 This section highlights the protocol and implementation additions 520 required to support this specification. 522 4.1. Binding Update Extensions 524 4.1.1. IPv4 Home Address Option 526 This option is included in the Mobility Header including the binding 527 update message sent from the mobile node to a home agent or Mobility 528 Anchor Point. The alignment requirement for this option is 4n. 530 0 1 2 3 531 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 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | Type | Length |Prefix-len |P| Reserved | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | IPv4 home address | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 Figure 1: IPv4 Home Address Option 540 Type 542 TBD 544 Length 546 6 548 Prefix-len 550 The length of the prefix allocated to the mobile node. If only a 551 single address is allocated, this field MUST be set to 32. In the 552 first binding update requesting a prefix, the field contains the 553 prefix length requested. However, in the following binding 554 updates, this field must contain the length of the prefix 555 allocated. A value of zero is invalid and MUST be considered an 556 error. 558 P 560 A flag indicating, when set, that the mobile node requests a 561 mobile network prefix. This flag is only relevant for new 562 requests, and must be ignored for binding refreshes. 564 Reserved 566 This field is reserved for future use. It MUST be set to zero by 567 the sender and ignored by the receiver. 569 IPv4 Home Address 571 The mobile node's IPv4 home address that should be defended by the 572 home agent. This field could contain any unicast IPv4 address 573 (public or private) that was assigned to the mobile node. The 574 value 0.0.0.0 is used to request an IPv4 home address from the 575 home agent. A mobile node may choose to use this option to 576 request a prefix by setting the address to the All Zeroes and 577 setting the P flag. The mobile node could then form an IPv4 home 578 address based on the allocated prefix. Alternatively, the mobile 579 node may use two different options, one for requesting an address 580 (Static or Dynamic) and another for requesting a prefix. 582 4.1.2. The IPv4 Care-of Address Option 584 This option is included in the Mobility Header including the binding 585 update message sent from the mobile node to a home agent or Mobility 586 Anchor Point. The alignment requirement for this option is 4n. 588 0 1 2 3 589 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 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | Type | Length | Reserved | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | IPv4 Care-of address | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 Figure 2: The IPv4 CoA Option 598 Type 600 TBD 602 Length 604 6 606 Reserved 608 This field is set to zero by the sender and ignored by the 609 receiver. 611 IPv4 Care-of Address 613 This field contains the mobile node's IPv4 care- of address. The 614 IPv4 care-of address is used when the mobile node is located in an 615 IPv4-only network. 617 4.1.3. The Binding Update Message Extensions 619 This specification extends the Binding Update message with two new 620 flags. The flags are shown and described below. 622 0 1 2 3 623 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 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | Sequence # | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 |A|H|L|K|M|R|P|F| Reserved | Lifetime | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 Figure 3: Binding Update message 632 F 634 When set, this flag indicates a request for forcing UDP 635 encapsulation regardless of whether a NAT is present on the path 636 between the mobile node and the home agent. This flag may be set 637 by the mobile node if it is required to use UDP encapsulation 638 regardless of the presence of a NAT. This flag SHOULD NOT be set 639 when the mobile node is configured with an IPv6 care-of address; 640 with the exception for the scenario mentioned in Section 5.4.1 642 4.2. Binding Acknowledgement Extensions 644 4.2.1. IPv4 Address Acknowledgement Option 646 This option is included in the Mobility Header including the binding 647 acknowledgement message sent from the home agent or Mobility Anchor 648 Point to the mobile node. This option indicates whether a binding 649 cache entry was created for the mobile node's IPv4 address. 650 Additionally, this option includes an IPv4 home address in the case 651 of Dynamic IPv4 home address configuration (i.e., if the unspecified 652 IPv4 address was included in the binding update). The alignment 653 requirement for this option is 4n. 655 0 1 2 3 656 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 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 | Type | Length | Status |Pref-len |Res| 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 | IPv4 home address | 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 Figure 4: IPv4 Address Acknowledgement Option 665 Type 667 TBD 669 Length 671 6 673 Status 675 Indicates success or failure for the IPv4 home address binding. 676 Values from 0 to 127 indicate success. Higher values indicate 677 failure. 679 Pref-len 681 The prefix length of the address allocated. This field is only 682 valid in case of success and MUST be set to zero and ignored in 683 case of failure. This field overrides what the mobile node 684 requested (if not equal to the requested length). 686 Res 688 This field is reserved for future use. It MUST be set to zero by 689 the sender and ignored by the receiver 691 IPv4 Home Address 693 The IPv4 home address that the home agent will use in the binding 694 cache entry. This could be a public or private address. This 695 field MUST contain the mobile node's IPv4 home address. If the 696 address were dynamically allocated the home agent will add the 697 address to inform the mobile node. Otherwise, if the address were 698 statically allocated to the mobile node, the home agent will copy 699 it from the binding update message. 701 The following values are allocated for the Status field: 703 o 0 Success 705 o 128 Failure, reason unspecified 707 o 129 Administratively prohibited 709 o 130 Incorrect IPv4 home address 711 o 131 Invalid IPv4 address 713 o 132 Dynamic IPv4 home address assignment not available 715 o 133 Prefix allocation unauthorized 717 4.2.2. The NAT Detection Option 719 This option is sent from the home agent to the mobile node to 720 indicate whether a NAT was in the path. This option MAY also include 721 a suggested NAT binding refresh time for the mobile node. This might 722 be usefl for scenarios where the mobile node is known to be moving 723 within the home agent's administrative domain, and therefore the NAT 724 timeout is known (through configuration) to the home agent. Section 725 3.5 of [RFC5405] discusses issues with NAT timeout in some detail. 727 The alignment requirement for this option is 4n. If a NAT is 728 detected, this option MUST be sent by the home agent. 730 0 1 2 3 731 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 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | Type | Length |F| Reserved | 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | Refresh time | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 Figure 5: The NAT Detection Option 740 Type 742 TBD 744 Length 746 6 748 F 749 This flag indicates to the mobile node that UDP encapsulation is 750 required. When set, this flag indicates that the mobile node MUST 751 use UDP encapsulation even if a NAT is not located between the 752 mobile node and home agent. This flag SHOULD NOT be set when the 753 mobile node is assigned an IPv6 care-of address; with the 754 exception for accomodating the scenarios discussed in 755 Section 5.4.1. 757 Reserved 759 This field is reserved for future use. It MUST be set to zero by 760 the sender and ignored by the receiver. 762 Refresh Time 764 A suggested time (in seconds) for the mobile node to refresh the 765 NAT binding. If set to zero, it is ignored. If this field is set 766 to all 1s it means that keepalives are not needed, i.e., no NAT 767 was detected. The home agent MUST be configured with a default 768 value for the refresh time. The recommended value is outlined in 769 Section 7 771 5. Protocol operation 773 This section presents the protocol operation and processing for the 774 messages presented above. In addition, this section introduces the 775 NAT detection and traversal mechanism used by this specification. 777 5.1. Tunelling Formats 779 This specification allows the mobile node to use various tunnelling 780 formats depending on its location and the visited network's 781 capabilities. The mobile node can tunnel IPv6 in IPv4, IPv4 in IPv6 782 or use UDP encapsulation to tunnel IPv6 in IPv4. Naturally, this 783 specification also supports tunnelling IPv6 in IPv6. 785 This specification allows UDP-based tunnelling to be used between the 786 mobile node and its home agent or MAP. A UDP encapsulation format 787 means the following order of headers: 789 IPv4/v6 791 UDP 793 IP (v4 or v6) 795 Other headers 797 Note that the ue of UDP encapsulation for IPv6 care-of addresses 798 SHOULD NOT be done except in the circumstances highlighted in 799 Section 5.4.1. 801 When using this format the receiver would parse the version field 802 following the UDP header in order to determine whether the following 803 header is IPv4 or IPv6. The rest of the headers are processed 804 normally. The above order of headers does not take IPsec headers 805 into account as they may be placed in different parts of the packet. 806 The above format MUST be supported by all implementations of this 807 specification and MUST always be used to send the binding update 808 message. 810 UDP Tunnelling can also encapsulate an ESP header as shown below. 812 IPv4/v6 814 UDP 816 ESP 817 IP (v4 or v6) 819 Other headers 821 The negotiation of the secure tunnel format described above is 822 discussed in Section 6.2. The receiver of a UDP tunnel detects 823 whether an ESP header is present or not based on the UDP port used. 825 5.1.1. tunnelling Impacts on Transport and MTU 827 Changing the tunnel format may occur due to movement of the mobile 828 node from one network to another. This can have impacts on the link 829 and path MTU, which may affect the amount of bandwidth available to 830 the applications. The mobile node may use PMTUD as specified in 831 [RFC4459]. 833 To accommodate traffic that uses Explicit Congestion Notification 834 (ECN), it is RECOMMENDED that the ECN and DSCP information is copied 835 between the inner and outer header as defined in [RFC3168] and 836 [RFC2983]. It is RECOMMENDED that the full-functionality option 837 defined in section 9.1.1 of [RFC3168]is used to deal with ECN. 839 Note that some impementations may not be able to use ECN over the UDP 840 tunnel. This is due to the lack of access to ECN bits in the UDP API 841 on most platforms. However, this issue can be avoided if UDP 842 encapsulation is done in the kernel. 844 Note that when using UDP encapsulation, the TTL field must be 845 decremented in the same manner as when IP in IP encapsulation is 846 used. 848 5.2. NAT Detection 850 This section deals with NAT detection for the purpose of 851 encapsulating packets between the mobile node and the home agent when 852 the mobile node is present in a private IPv4 network. Mobile IPv6 853 uses IKEv2 to establish te IPsec security association between the 854 mobile node and the home agent. IKEv2 has its own NAT detection 855 mechanism. However, IKEv2's NAT detection is only used for the 856 purpose of setting up the IPsec SA for secure traffic. The 857 interactions between the two NAT traversal mechanisms are described 858 in Section 6 860 NAT detection is done when the initial binding update message is sent 861 from the mobile node to the home agent. When located in an IPv4-only 862 foreign link, the mobile node sends the binding update message 863 encapsulated in UDP and IPv4. The source address of the IPv6 packet 864 is the mobile node's IPv6 home address. The destination address is 865 the IPv6 address of the home agent. The IPv4 header contains the 866 IPv4 care-of address in the source address field and the IPv4 address 867 of the home agent in the destination address field. 869 When the home agent receives the encapsulated binding update, it 870 compares the IPv4 address of the source address field in the IPv4 871 header with the IPv4 address included in the IPv4 care-of address 872 option. If the two addresses match, no NAT device was in the path. 873 Otherwise, a NAT was in the path and the NAT detection option is 874 included in the binding acknowledgement. The binding 875 acknowledgement, and all future packets, are then encapsulated in UDP 876 and IPv4. The source address in the IPv4 header is the IPv4 address 877 of the home agent. The destination address is the IPv4 address 878 received in the IPv4 header encapsulating the binding update (this 879 address will be different from the IPv4 care-of address when a NAT is 880 in the path). The source port in the packet is the home agent's 881 source port. The destination port is the source port received in the 882 binding update message. Note that the home agent stores the port 883 numbers and associates them with the mobile node's tunnel in order to 884 forward future packets. 886 Upon receiving the binding acknowledgement with the NAT detection 887 option, the mobile node sets the tunnel to the home agent to UDP 888 encapsulation. Hence, all future packets to the home agent are 889 tunneled in UDP and IPv4. For all tunneled IPv6 packets, the source 890 address in the IPv6 header is the mobile node's IPv6 home address and 891 the destination address is the correspondent node's IPv6 address. 892 All tunneled IPv4 packets will contain the mobile node's IPv4 home 893 address in the source address field of the inner IPv4 packet and the 894 correspondent node's IPv4 address in the destination address field. 895 The outer IPv4 header is the same whether the inner packet is IPv4 or 896 IPv6. 898 If no NAT device was detected in the path between the mobile node and 899 the home agent then IPv6 packets are tunneled in an IPv4 header, 900 unless the home agent forces UDP encapsulation using the F flag. The 901 content of the inner and outer headers are identical to the UDP 902 encapsulation case. 904 A mobile node MUST always tunnel binding updates in UDP when located 905 in an IPv4-only network. Essentially, this process allows for 906 perpetual NAT detection. Similarly, the home agent MUST encapsulate 907 binding acknowledgements in a UDP header whenever the binding update 908 is encapsulated in UDP. 910 In conclusion, the packet formats for the binding update and 911 acknowledgement messages are shown below: 913 Binding update received by the home agent: 915 IPv4 header (src=V4ADDR, dst=HA_V4ADDR) 917 UDP header 919 IPv6 header (src=V6HOA, dst=HAADDR) 921 ESP Header 923 Mobility header 925 BU [IPv4 HAO] 927 IPv4 CoA option 929 Where V4ADDR is either the IPv4 care-of address or the address 930 provided by the NAT device. V6HOA is the IPv6 home address of the 931 mobile node. The binding update MAY also contain the IPv4 home 932 address option IPv4 HAO. 934 Binding acknowledgement sent by the home agent: 936 IPv4 header (src= HA_V4ADDR, dst=V4ADDR) 938 UDP Header 940 IPv6 header (src=HAADDR, dst=V6HOA) 942 ESP Header 944 Mobility Header 946 BA ([IPv4 ACK], NAT DET) 948 Where V6HOA is IPv6 home address of the mobile node. The IPv4 ACK is 949 the IPv4 address acknowledgement option, which is only included if 950 the IPv4 home address option were present in the BU. The NAT DET is 951 the NAT detection option, which MUST be present in the binding 952 acknowledgement message if the binding update was encapsulated in 953 UDP. 955 5.3. NAT Keepalives 957 If a NAT is detected, the mobile node will need to refresh the NAT 958 bindings in order to be reachable from the home agent. NAT bindings 959 can be refreshed through sending and receiving traffic encapsulated 960 in UDP. However, if the mobile node is not active, it will need to 961 periodically send a message to the home agent in order to refresh the 962 NAT binding. This can be done using the binding update message. The 963 binding update/acknowledgement pair will ensure that the NAT bindings 964 are refreshed in a reliable manner. There is no way for the mobile 965 node to know the exact time of the NAT binding. The default time 966 suggested in this specification is NATKATIMEOUT. If the home agent 967 suggests a different refresh period in the binding acknowledgement, 968 the mobile node SHOULD use the value suggested by the home agent. 970 If the refresh time in the NAT detection option in the binding 971 acknowledgement is set to all 1s, the mobile node need not send 972 messages to refresh the NAT binding. However, the mobile node may 973 still be required to encapsulate traffic in UDP. This scenario may 974 take place when a NAT is not detected, but the home agent still 975 requires the mobile node to use UDP encapsulation. 977 It should be noted that a mobile node that does not need to be 978 reachable (i.e., only cares about the session continuity aspect of 979 Mobile IP) it does not need to refresh the NAT binding. In this 980 case, the mobile node would only be able to initiate communication 981 with other nodes. However, this is likely to imply that the mobile 982 node will need to send a binding update before initiating 983 communication after a long idle period as it is likely to be assigned 984 a different port and IPv4 address by the NAT when it initiates 985 communication. Hence, an implementation may choose, for the sake of 986 simplicity, to always maintain the NAT bindings even when it does not 987 need reachability. 989 Note that keepalives are also needed by IKEv2 over UDP port 4500. 990 This is needed for IKE dead peer detection, which is not handled by 991 DSMIPv6 keepalives. 993 5.4. Mobile Node Operation 995 In addition to the operations specified in [RFC3775] and [RFC3963], 996 this specification requires mobile nodes to be able to support an 997 IPv4 home address. This specification also requires the mobile node 998 to choose an IPv4 or an IPv6 care-of address. We first discuss 999 care-of address selection, then continue with binding management and 1000 transmission of normal traffic. 1002 5.4.1. Selecting a Care-of address 1004 When a mobile node is in a dual stacked visited network, it will have 1005 a choice between an IPv4 and an IPv6 care-of address. The mobile 1006 node SHOULD prefer the IPv6 care-of address and bind it to its home 1007 address(es). If a mobile node attempted to bind the IPv6 care-of 1008 address to its home address(es) and the binding update timed out, the 1009 mobile node SHOULD: 1011 o Resend the binding update using the exponential back-off algorithm 1012 described in [RFC3775]. 1014 o If after three attempts in total a binding acknowledgement was not 1015 received, the mobile node SHOULD send a new binding update using 1016 the IPv4 care-of address. The exponential backoff algorithm 1017 described in [RFC3775] should be used for re-transmission of the 1018 binding update if needed. 1020 This procedure should be used to avoid scenarios where IPv6 1021 connectivity may not be as reliable as IPv4. This may take place 1022 during early deployments of IPv6, or simply due to temporary outages 1023 affecting IPv6 routing. 1025 It is RECOMMENDED that upon movement the mobile node does not change 1026 the IP address family chosen for the previous binding update unless 1027 the mobile node is aware that it has moved to a different 1028 administrative domain where previous problems with IPv6 routing may 1029 not be present. Repeating the above procedure upon every movement 1030 can cause significant degradation of the mobile node's applications' 1031 performace due to extended periods of packet losses after handover if 1032 the routing outage is still in effect. 1034 When using an IPv4 care-of address and IP in IP encapsulation, if the 1035 mobile node implementation is made aware by upper layers of 1036 persistent packet losses, it may attempt to resend the binding update 1037 with the F flag set, requesting UDP encapsulation for all packets. 1038 This may avoid packet losses due to situations where local 1039 firewalling policies prevent the use of IP in IP encapsulation. 1041 The effect of these address selection mechanism is to allow the 1042 follwing preferences in the absence of NAT: 1044 1. IPv6 1046 2. IPv4 (using IP in IP or UDP encapsulation if a NAT is detected) 1048 3. UDP encapsulation when IP in IP is not allowed by the local 1049 domain. 1051 5.4.2. Sending Binding Updates 1053 When sending an IPv6 packet containing a binding update while 1054 connected to an IPv4-only access network, mobile nodes MUST ensure 1055 the following: 1057 o The IPv6 packet is encapsulated in UDP. 1059 o The source address in the IPv4 header is the mobile node's IPv4 1060 care-of address. 1062 o The destination address in the IPv4 header is the home agent's 1063 IPv4 address. 1065 o The source address in the IPv6 header is the mobile node's IPv6 1066 home address. 1068 o The IPv4 home address option MAY be included in the mobility 1069 header. This option contains the IPv4 home address. If the 1070 mobile node did not have a static home address it MAY include the 1071 unspecified IPv4 address, which acts as a request for a dynamic 1072 IPv4 home address. Alternatively, one or more IPv4 home address 1073 options may be included with requests for IPv4 prefixes (i.e., 1074 with the P flag set). 1076 o If the mobile node wishes to use UDP encapsulation only, it should 1077 set the F flag in the binding update message. 1079 o The IPv6 packet MUST be authenticated as per [RFC3775], based on 1080 the mobile node's IPv6 home address. 1082 When sending a binding update from a visited network that supports 1083 IPv6, the mobile node MUST follow the rules specified in [RFC3775]. 1084 In addition, if the mobile node has an IPv4 home address or needs 1085 one, it MUST include the IPv4 home address option in the mobility 1086 header. If the mobile node already has a static IPv4 home address, 1087 this address MUST be included in the IPv4 home address option. 1088 Otherwise, if the mobile node needs a dynamic IPv4 address, it MUST 1089 include the IPv4 0.0.0.0 address in the IPv4 home address option. 1091 In addition to the rules in [RFC3775], the mobile node should follow 1092 the care-of address selection guidelines in Section 5.4.1. 1094 When the mobile node receives a binding acknowledgement from the home 1095 agent, it follows the rules in [RFC3775] and [RFC3963]. In addition, 1096 the following actions MUST be made: 1098 o If the status field indicated failure with error code 144, the 1099 mobile node MAY resend the binding update without setting the F 1100 flag. 1102 o If the mobility header includes an IPv4 address acknowledgement 1103 option indicating success, the mobile node should create two 1104 entries in its binding update list, one for the IPv6 home address 1105 and another for the IPv4 home address. 1107 o If the NAT detection option were present, the mobile node MUST 1108 tunnel future packets in UDP and IPv4. This MUST be indicated in 1109 the binding update list. 1111 o If no IPv4 address acknowledgement option were present, and an 1112 IPv4 home address option was present in the binding update, the 1113 mobile node MUST only create one binding update list entry for its 1114 IPv6 home address. The mobile node MAY include the IPv4 home 1115 address option in future binding updates. 1117 o If an IPv4 address acknowledgement option were present and it 1118 indicates failure for the IPv4 home address binding, the mobile 1119 node MUST NOT create an entry for that address in its binding 1120 update list. The mobile node MAY include the IPv4 home address 1121 option in future binding updates. 1123 5.4.2.1. Removing Bindings 1125 Mobile nodes will remove bindings from the home agent's binding cache 1126 whenever they move to the home link, or simply when mobility support 1127 is not needed. 1129 De-registering the IPv6 home address is described in [RFC3775]. The 1130 same mechanism applies in this specification. Mobile nodes may 1131 remove the binding for the IPv4 home address only, by sending a 1132 binding update that does not include the IPv4 home address option. 1133 Upon receiving this binding update, the home agent will replace the 1134 existing cache entries with the content of the new message. This 1135 ensures that the IPv4 home address binding is removed, while 1136 maintining an IPv6 binding. 1138 Note that the mobile node cannot remove the IPv6 home address binding 1139 while maintaining an IPv4 home address binding. 1141 A binding update message with a lifetime of zero, will remove all 1142 bindings for the mobile node. 1144 5.4.3. Sending Packets from a Visited Network 1146 When the mobile node is located in an IPv6-enabled network it sends 1147 and receives IPv6 packets as described in [RFC3775]. In cases where 1148 IP in IP encapsulation is not providing connectivity to the home 1149 agent, the mobile node may choose to encapsulate in UDP as suggested 1150 in Section 5.4.1. However, this encapsulation of IPv6 traffic should 1151 be used as a last resort as described. IPv4 traffic is encapsulated 1152 in IPv6 packets to the home agent. 1154 When the mobile node is located in an IPv4 only network, it will send 1155 IPv6 packets to its home agent according to the following format: 1157 IPv4 header (src=V4CoA, dst=HA_V4ADDR) 1159 [UDP Header] 1161 IPv6 header (src=V6HoA, dst=CN) 1163 Upper Layer protocols 1165 Here the UDP header is only used if a NAT has been detected between 1166 the mobile node and the home agent, or if the home agent forced UDP 1167 encapsulation. V4CoA is the IPv4 care-of address configured by the 1168 mobile node in the visited network. 1170 Similarly, IPv4 packets are sent according to the following format: 1172 IPv4 header (src=V4CoA, dst=HA_V4ADDR) 1174 [UDP Header] 1176 IPv4 header (src=V4HoA, dst=V4CN) 1178 Upper Layer protocols 1180 Here the UDP header is only used if a NAT has been detected between 1181 the mobile node and the home agent, or if the home agent forced UDP 1182 encapsulation. 1184 5.4.4. Movement Detection in IPv4-only Networks 1186 [RFC3775] describes movement detection mostly based on IPv6-specific 1187 triggers and Neighbor Discovery [RFC4861] information. These 1188 triggers are not available in an IPv4-only network. Hence, a mobile 1189 node located in an IPv4-only network SHOULD use [RFC4436] for 1190 guidance on movement detection mechanisms in IPv4-only networks. 1192 The mobile node detects that it's in an IPv4-only network when the 1193 IPv6 movement detection algorithm fails to configure an IPv6 address. 1195 5.5. Home agent operation 1197 In addition to the home agent specification in [RFC3775] and 1198 [RFC3963], the home agent needs to be able to process the IPv4 home 1199 address option and generate the IPv4 address acknowledgement option. 1200 Both options are included in the mobility header. Furthermore, the 1201 home agent MUST be able to detect the presence of a NAT device and 1202 indicate that in the NAT detection option included in the binding 1203 acknowledgement. 1205 A home agent must also act as a proxy for address resolution in IPv4 1206 for the registered IPv4 home addresses of mobile nodes it is serving. 1207 Moreover, the administrative domain of the home agent is responsible 1208 for advertising the routing information of registered IPv4 mobile 1209 network prefixes of the mobile nodes. 1211 In order to comply with this specification, the home agent MUST be 1212 able to find the IPv4 home address of a mobile node when given the 1213 IPv6 home address. That is, given an IPv6 home address, the home 1214 agent MUST store the corresponding IPv4 home address if a static one 1215 is present. If a dynamic address were requested by the mobile node, 1216 the home agent MUST store that address (associated with the IPv6 home 1217 address) after it's allocated to the mobile node. 1219 When the home agent receives a binding update encapsulated in UDP and 1220 containing the IPv4 home address option, it needs to follow all the 1221 steps in [RFC3775] and [RFC3963]. In addition, the following checks 1222 MUST be done: 1224 o If the IPv4 care-of address in the IPv4 CoA option is not the same 1225 as the IPv4 address in the source address in the IPv4 header then 1226 a NAT was in the path. This information should be flagged for the 1227 binding acknowledgement. 1229 o If the F flag in the binding update were set, the home agent needs 1230 to determine whether it accepts forcing UDP encapsulation. If it 1231 does not, the binding acknowledgement is sent with error code 144. 1232 UDP encapsulation SHOULD NOT be used when the mobile node is 1233 located in an IPv6-enabled link, with the exception of the 1234 scenarios outlined in Section 5.4.1. 1236 o If the IPv4 home address option contains a valid unicast IPv4 1237 address, the home agent MUST check that this address is allocated 1238 to the mobile node that has the IPv6 home address included in the 1239 home address option. The same MUST be done for an IPv4 prefix. 1241 o If the IPv4 home address option contained the unspecified IPv4 1242 address, the home agent SHOULD dynamically allocate an IPv4 home 1243 address to the mobile node. If none is available, the home agent 1244 MUST return error code 132 in the status field of the IPv4 address 1245 acknowledgement option. If a prefix were requested, the home 1246 agent SHOULD allocate a prefix with the requested length; if 1247 prefix allocation (of any length) was not possible, the home agent 1248 MUST indicate failure of the operation with the appropriate error 1249 code. 1251 o If the binding update is accepted for the IPv4 home address, the 1252 home agent creates a binding cache entry for the IPv4 home 1253 address/prefix. The home agent MUST include an IPv4 1254 acknowledgement option in the mobility header containing the 1255 binding acknowledgement. 1257 o If the binding update is accepted for both IPv4 and IPv6 home 1258 addresses, the home agent creates separate binding cache entries, 1259 one for each home address. The care-of address is the one 1260 included in the binding update. If the care-of address is an IPv4 1261 address, the home agent MUST setup a tunnel to the IPv4 care-of 1262 address of the mobile node. 1264 When sending a binding acknowledgement to the mobile node, the home 1265 agent constructs the message according to [RFC3775] and [RFC3963]. 1266 Note that the routing header MUST always contain the IPv6 home 1267 address as specified in [RFC3775]. 1269 If the care-of address of the mobile node were an IPv4 address, the 1270 home agent includes the mobile node's IPv6 home address in the 1271 destination address field in the IPv6 header. If a NAT were 1272 detected, the home agent MUST then encapsulate the packet in UDP and 1273 an IPv4 header. The source address is set to the home agent's IPv4 1274 address and the destination address is set to the address received in 1275 the source address of the IPv4 header encapsulating the binding 1276 update. 1278 After creating a binding cache entry for the mobile node's home 1279 addresses, all packets sent to the mobile node's home addresses are 1280 tunneled by the home agent to the mobile node's care-of address. If 1281 a NAT were detected, packets are encapsulated in UDP and IPv4. 1282 Otherwise, if the care-of address is an IPv4 address, and no NAT were 1283 detected, packets are encapsulated in an IPv4 header unless UDP 1284 encapsulation is forced by the home agent. 1286 5.5.1. Sending Packets to the Mobile Node 1288 The home agent follows the rules specified in [RFC3775] for sending 1289 IPv6 packets to mobile nodes located in IPv6 networks. When sending 1290 IPv4 packets to mobile nodes in an IPv6 network, the home agent must 1291 encapsulate the IPv4 packets in IPv6. 1293 When sending IPv6 packets to a mobile node located in an IPv4 1294 network, the home agent must follow the format negotiated in the 1295 binding update/acknowledgement exchange. In the absence of a 1296 negotiated format, the default format that MUST be supported by all 1297 implementations is: 1299 IPv4 header (src= HA_V4ADDR, dst= V4ADDR) 1301 UDP Header 1303 IPv6 header (src=CN, dst= V6HoA) 1305 Upper layer protocols 1307 Where the UDP header is only included if a NAT were detected between 1308 the mobile node and the home agent, or if the home agent forced UDP 1309 encapsulation. V4ADDR is the IPv4 address received in the source 1310 address field of the IPv4 packet containing the binding update. 1312 When sending IPv4 packets to a mobile node located in an IPv4 1313 network, the home agent must follow the format negotiated in the 1314 binding update/acknowledgement exchange. In the absence of a 1315 negotiated format, the default format that MUST be supported by all 1316 implementations is: 1318 IPv4 header (src= HA_V4ADDR, dst= V4ADDR) 1320 [UDP Header] 1322 IPv4 header (src=V4CN, dst= V4HoA) 1324 Upper layer protocols 1326 Where the UDP header is only included if a NAT were detected between 1327 the mobile node and home agent, or if the home agent forced UDP 1328 encapsulation. 1330 5.6. Correspondent Node Operation 1332 This specification has no impact on IPv4 or IPv6 correspondent nodes. 1334 6. Security Considerations 1336 This specification allows a mobile node to send one binding update 1337 for its IPv6 and IPv4 home addresses. This is a slight deviation 1338 from [RFC3775] which requires one binding update per home address. 1339 However, like [RFC3775], the IPsec security association needed to 1340 authenticate the binding update is still based on the mobile node's 1341 IPv6 home address. Therefore, in order to authorize the mobile 1342 node's IPv4 home address binding, the home agent MUST store the IPv4 1343 address corresponding to the IPv6 address that is allocated to a 1344 mobile node. Therefore, it is sufficient for the home agent to know 1345 that the IPsec verification for the packet containing the binding 1346 update was valid provided that it knows which IPv4 home address is 1347 associated with which IPv6 home address. Hence, the security of the 1348 IPv4 home address binding is the same as the IPv6 binding. 1350 In effect, associating the mobile node's IPv4 home address with its 1351 IPv6 home address moves the authorization of the binding update for 1352 the IPv4 address to the Mobile IPv6 implementation, which infers it 1353 from the fact that the mobile node has an IPv6 home address and the 1354 right credentials for sending an authentic binding update for the 1355 IPv6 address. 1357 This specification requires the use of IKEv2 as the default mechanism 1358 for dynamic keying. 1360 In cases where this specification is used for NAT traversal, it is 1361 important to note that it has the same vulnerabilities associated 1362 with [RFC3519]. An attacker is able to hijack the mobile node's 1363 session with the home agent if it can modify the contents of the 1364 outer IPv4 header. The contents of the header are not authenticated 1365 and there is no way for the home agent to verify their validity. 1366 Hence, a man in the middle attack where a change in the contents of 1367 the IPv4 header can cause a legitimate mobile node's traffic to be 1368 diverted to an illegitimate receiver independently of the 1369 authenticity of the binding update message. 1371 In this specification, the binding update message MUST be protected 1372 using ESP transport mode. When the mobile node is located in an 1373 IPv4-only network, the binding update message is encapsulated in UDP 1374 as described earlier. However, UDP SHOULD NOT be used to encapsulate 1375 the binding update message when the mobile node is located in an 1376 IPv6-enabled network. If protection of payload traffic is needed 1377 when the mobile node is located in an IPv4-only network, 1378 encapsulation is done using tunnel mode ESP over port 4500 as 1379 described in [RFC3948]. During the IKE negotiation with the home 1380 agent, if the mobile node and home agent support the use of port 1381 4500, the mobile node MUST establish the security association over 1382 port 4500, regardless of the presence of a NAT. This is done to 1383 avoid the switching between ports 500 and 4500 and the potential 1384 traffic disruption resulting from this switch. 1386 Handovers within private IPv4 networks or from IPv6 to IPv4 networks 1387 will have impacts on the security association between the mobile node 1388 and the home agent. The following section presents the expected 1389 behaviour of the mobile node and home agent in those situations. The 1390 details of the IKE negotiations and messages are illustrated in 1391 Section 6.2 1393 6.1. Handover Interactions for IPsec and IKE 1395 After the mobile node detects movement it configures a new care-of 1396 address. If the mobile node is in an IPv4-only network, it removes 1397 binding update list entries for correspondent nodes since route 1398 optimisation cannot be supported. This may cause inbound packet 1399 losses as remote correspondent nodes are unaware of such movement. 1400 To avoid confusion in the correspondent node, the mobile node SHOULD 1401 deregister its binding with each correspondent node by sending a 1402 deregistration binding update. The deregistration binding update 1403 message is tunnelled to the home agent and onto the correspondent 1404 node. This is done after the mobile node updates the home agent with 1405 its new location as discussed below. 1407 The mobile node sends the binding update message to the home agent. 1408 If the mobile node is in an IPv6-enabled network, the binding update 1409 SHOULD be sent without IPv4/UDP encapsulation, unless UDP 1410 encapsulation is needed as described in Section 5.4.1. If the mobile 1411 node is in an IPv4-only network, then after IPsec processing of the 1412 BU message, it encapsulates the BU in UDP/IPv4 as discussed in 1413 sections 5.2 and 5.4. In order to be able to send the binding update 1414 while in an IPv4-only network, the mobile node needs to use the new 1415 IPv4 care-of address in the outer header, which is different from the 1416 care-of address used in the existing tunnel. This should be done 1417 without permanently updating the tunnel within the mobile node's 1418 implementation in order to allow the mobile node to receive packets 1419 on the old care-of address until the binding acknowledgement is 1420 received. The method used to achieve this effect is implementation 1421 dependent and is outside the scope of this specification. This 1422 implies that the IP forwarding function (which selects the interface 1423 or tunnel through which a packet is sent) is not based solely on the 1424 destination address: some IPv6 packets destined to the home agent are 1425 sent via the existing tunnel, while BUs are sent using the new 1426 care-of address. Since BUs are protected by IPsec, the forwarding 1427 function cannot necessarily determine the correct treatment from the 1428 packet headers. Thus, the DSMIPv6 implementation has to attach 1429 additional information to BUs, and this information has to be 1430 preserved after IPsec processing and made available to the forwarding 1431 function, or additional DSMIP processing added to the forwarding 1432 function. Depending on the mobile node's implementation, meeting 1433 this requirement may require changes to the IPsec implementation. 1435 Upon receiving the binding update message encapsulated in UDP/IPv4, 1436 the home agent processes it as follows. In order to allow the 1437 DSMIPv6 implementation in the home agent to detect the presence of a 1438 NAT on the path to the mobile node, it needs to compare the outer 1439 IPv4 source address with the IPv4 address in the IPv4 care-of address 1440 option. This implies that the information in the outer header will 1441 be preserved after IPsec processing and made available to the DSMIPv6 1442 implementation in the home agent. Depending on the home agent's 1443 implementation, meeting this requirement may require changes to the 1444 IPsec implementation. 1446 The home agent updates its tunnel mode security association to 1447 include the mobile node's care-of address as the remote tunnel header 1448 address, and 4500 as the port number. The IPv4 address and port 1449 number are likely to be wrong; the mobile node provides the correct 1450 information in a separate exchange as described below. When the 1451 mobile node is located in a private IPv4 network (which is detected 1452 as described above), the new address and port number are allocated by 1453 the NAT. The home agent will also enable or disable UDP 1454 encapsulation for outgoing ESP packets for the purpose of NAT 1455 traversal. 1457 If the Key Management Mobility Capability (K) bit was set in the 1458 binding update, and the home agent supports this feature, the home 1459 agent updates its IKE security associations to include the mobile 1460 node's care-of address as the peer address and 4500 as the port 1461 number. The home agent may also need to change NAT traversal fields 1462 in the IKE_SA to enable the dynamic update of the IP address and port 1463 number based on the reception of authenticated IKE messages, or 1464 authenticated packets using tunnel mode ESP. The dynamic updates are 1465 described in section 2.23 of RFC 4306. As described above, when the 1466 mobile node is located in a private IPv4 network, the address and 1467 port number used for IPsec and IKE traffic is not yet known by the 1468 home agent at this point. 1470 The mobile node updates the IKE SA in one of two ways. If the K flag 1471 was set in the binding acknowledgement message, the mobile node 1472 SHOULD send an empty informational message, which results in the IKE 1473 module in the home agent to dynamically update the SA information. 1474 The IKE implementation in the home agent is REQUIRED to support this 1475 feature. Alternatively, the IKE SA should be re-negotiated. Note 1476 that updating the IKE SA MUST take place after the mobile node has 1477 sent the binding update and received the acknowledgement from the 1478 home agent. 1480 It is important to note that the mobile node's IPv4 care-of address 1481 seen by the DSMIPv6 module in the home agent upon receiving the 1482 binding update may differ from the IPv4 care-of address seen by the 1483 IKE module and the care-of address used for forwarding IPsec tunnel 1484 mode traffic. Hence, it is probable that different modules in the 1485 home agent will have a different care-of address that should be used 1486 for encapsulating traffic to the mobile node. 1488 After successfully processing the binding update, the home agent 1489 sends the binding acknowledgement to the mobile node's care-of 1490 address as received in the outer header of the packet containing the 1491 binding update. Note that if the BU was rejected, the BAck is sent 1492 to the same address where the BU was received from. This may require 1493 special treatment in IP forwarding and/or IPsec processing which 1494 resembles sending of BUs in the mobile node (described above). 1496 Upon receiving the binding acknowledgement, the mobile node updates 1497 its local tunnel mode Security Association information to include the 1498 tunnel header IP source address, which is the mobile node's address 1499 and the tunnel header IP destination, which is the home agent's 1500 address. The mobile node may also need to enable or disable UDP 1501 encapsulation for outgoing ESP packets for the purpose of NAT 1502 traversal and the sending of keep alives. 1504 The mobile node MAY use [RFC4555] to update its IKE SA with the home 1505 agent. Using MOBIKE requires negotiating this capability with the 1506 home agent when establishing the SA. In this case, the mobile node 1507 and the home agent MUST NOT update their IPsec SAs locally as this 1508 step is performed by MOBIKE. Furthermore, the use of MOBIKE allows 1509 the mobile node to update the SA independently of the binding update 1510 exchange. Hence, there is no need for the mobile node to wait for a 1511 binding acknowledgement before performing MOBIKE. The use of MOBIKE 1512 is OPTIONAL in this specification. 1514 6.2. IKE negotiation messages between the mobile node and Home Agent 1516 This specification defines a number of possible data encapsulation 1517 formats depending on the mobile node's connectivity to the visited 1518 network. When connected to an IPv6-enabled network, the tunnelling 1519 formats are clear. However, when connected to an IPv4-only network, 1520 care should be taken when negotiating the IKE association and the 1521 consequential tunnelling formats used for secure and insecure 1522 traffic. This section illustrates the IKE message exchange between 1523 the mobile node and home agent when the mobile node is located in an 1524 IPv4-only network. Two different IKE negotiations are considered: 1526 o IKEv2 operation for securing DSMIPv6 Signaling. 1528 o IKEv2 operation for securing Data over IPv4 1530 6.2.1. IKEv2 Operation for Securing DSMIPv6 Signaling 1532 A mobile node connected to an IPv4-only network SHOULD follow the 1533 procedures described below in order to establish an SA for the 1534 protection of binding update and binding acknowledgement messages. 1536 Mobile Node Home Agent 1537 ----------- ---------- 1538 IPv4(source_addr=V4ADDR, dest_addr=HAADDR) 1539 UDP (500, 500) HDR, SAi1, KEi, Ni 1540 NAT-D, NAT-D --> 1542 <- IPv4(source_addr=HAADDR, dest_addr=V4ADDR) 1543 UDP(500,X) HDR, SAr1, KEr, Nr, [CERTREQ] 1544 NAT-D, NAT-D 1546 IPv4(source_addr=V4ADDR, dest_addr=HAADDR) 1547 UDP (4500,4500) HDR, SK 1548 {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, N(USE_TRANSPORT_MODE), 1549 SAi2, TSi, TSr} 1550 --> 1552 <-- IPv4(source_addr=HAADDR, dest_addr=V4ADDR) 1553 UDP (4500,Y) HDR, SK 1554 {IDr, [CERT,] AUTH, N(USE_TRANSPORT_MODE), 1555 SAr2, TSi, TSr} 1557 The corresponding SPD entries are shown below. 1559 Mobile node SPD-S: 1561 IF local_address = home_address_1 & 1563 remote_address = home_agent_1 & 1565 proto = MH & local_mh_type = BU & remote_mh_type = BAck Then use 1566 SA ESP transport mode 1568 Initiate using IDi = user_1 to address home_agent_1 1570 Home Agent SPD-S: 1572 IF local_address = home_agent_1 & 1574 remote_address = home_address_1 & 1576 proto = MH & local_mh_type = BAck & remote_mh_type = BU Then use 1577 SA ESP transport mode 1579 where home_address_1 is the mobile node's registered IPv6 home 1580 address and home_agent_1 is the IP address of the home agent 1582 The above should result in BU/BA messages with the following BU 1583 received by the home agent. 1585 IPv4 header (src=V4ADDR, dst=HA_V4ADDR) 1587 UDP header (sport=Z, dport=DSMIPv6) 1589 IPv6 header (src=V6HOA, dst=HAADDR) 1591 ESP Header in Transport Mode 1593 Mobility header 1595 BU [IPv4 HAO] 1597 IPv4 CoA option 1599 (+ other as needed) 1601 At the home agent, following UDP de-capsulation, the binding update 1602 is delivered to the IPsec module as shown below: 1604 IPv6 header (src=V6HOA, dst=HAADDR) 1606 ESP Header in Transport Mode 1608 Mobility header 1610 BU [IPv4 HAO] 1612 IPv4 CoA option 1614 (+other as needed) 1616 In addition, V4ADDR and the sport (Z) need to be passed with the 1617 packet to ensure correct processing. 1619 Following IPsec processing, the binding update is delivered to the 1620 DSMIPv6 home agent module as follows: 1622 IPv6 header (src=V6HOA, dst=HAADDR) 1624 Mobility Header 1626 BU [IPv4 HAO] 1628 IPv4 CoA option 1630 (+other as needed) 1632 In addition, V4ADDR and the sport (Z) need to be passed with the 1633 packet to ensure correct processing. 1635 The binding acknowledgement sent by the home agent module to the 1636 IPsec module is as follows: 1638 IPv6 header (src=HAADDR, dst=V6HOA) 1640 Mobility Header 1642 BA ([IPv4 ACK], NAT DET) 1644 (+ other as needed) 1646 In addition, V4ADDR, the sport from the BU (Z), and an indication 1647 that UDP encapsulation must be used, need to be passed with the 1648 packet to ensure correct processing. 1650 The binding acknowledgement sent by the home agent to the mobile node 1651 is as follows: 1653 IPv4 header (src= HA_V4ADDR, dst=V4ADDR) 1655 UDP Header (sport=DSMIPv6, dport=Z) 1657 IPv6 header (src=HAADDR, dst=V6HOA) 1659 ESP Header in Transport Mode 1661 Mobility Header 1663 BA ([IPv4 ACK], NAT DET) 1665 6.2.2. IKEv2 Operation for Securing Data over IPv4 1667 To secure data traffic when the mobile node is located in an IPv4- 1668 only network, the mobile node MUST establish a child_SA for that 1669 purpose. The procedure is as follows: 1671 Mobile Node Home Agent 1672 ----------- ---------- 1673 IPv4(source_addr=V4ADDR, dest_addr=HAADDR) 1674 UDP (4500,4500) < non-ESP Marker > HDR, SK 1675 {[N], SA, Ni, [KEi], TSi, TSr} --> 1677 <--IPv4(source_addr=HAADDR, dest_addr=V4ADDR) 1678 UDP (4500,Y) < non-ESP Marker > HDR, SK 1679 SA, Nr, [KEr], TSi, TSr} 1681 If no NAT is detected, the encapsulation used will be: 1683 IPv4 (source_addr=v4CoA, dest_addr=HAAddr) 1685 ESP 1687 IP (source_addr=HoA, set_addr=CNAddr) 1689 Upper_layer_HDR 1691 where IP=IPv4 or IPv6 and HoA=v4HoA or v6HoA 1693 If a NAT were detected, the encapsulation used will be: 1695 IPv4 (source_addr=v4Addr, dest_addr=HAAddr) 1697 UDP (sport=Y, dport=4500) 1699 ESP 1701 IP (source_addr=HoA, set_addr=CNAddr) 1703 Upper_layer_HDR 1705 Where v4CoA may be the external IPv4 address of the NAT, IP is either 1706 an IPv4 or IPv6 header and HoA is either the IPv4 or the IPv6 HoA. 1707 The above format shows the packet as seen by the home agent. 1709 The SPD, whether a NAT were detected or not, is set as follows. Note 1710 that this rule is designed to match all data from the MN to nodes 1711 other than the home agent. This is done so that this rule does not 1712 overlap with the earlier rule securing BU/BA signaling between the MN 1713 and the HA. 1715 Mobile Node SPD-S: 1717 IF local_address = home_address & 1719 remote_address != home_agent & 1721 proto=any, then use SA ESP tunnel mode 1723 Initiate using IDi = user_1 to address home_agent_1 1725 home agent SPD-S: 1727 IF local_address != home_agent & 1729 remote_address = home_address & 1731 proto=any, then use SA ESP tunnel mode 1733 Where home_address is the MN's registered IPv6 or IPv4 home address 1734 and home_agent is the IPv6 or the IPv4 address of the home agent. 1736 7. Protocol Constants 1738 NATKATIMEOUT 110 seconds 1740 8. Acknowledgements 1742 Thanks to the following members (in alphabetical order) of the MIP6 1743 and NEMO Working Groups for their contributions, discussion, and 1744 review: Jari Arkko, Sri Gundavelli, Wassim Haddad, Conny Larsson, 1745 Acee Lindem, Ahmad Muhanna, Vidya Narayanan, Karen Nielsen and 1746 Keiichi Shima. Thanks to Karen Nielsen, Pasi Eronen and Christian 1747 Kaas-Petersen for raising the issue of IKEv2 interactions and 1748 proposing the solution included in this document. Thanks to Pasi 1749 Eronen for the many thorough reviews of this document. 1751 9. IANA Considerations 1753 The specification requires the following allocations from IANA: 1755 A UDP port is needed for the NAT traversal mechanism described in 1756 section 4.1. 1758 The IPv4 home address option described in section 3.1.1 requires 1759 an option type. This option is included in the Mobility header 1760 described in [RFC3775]. 1762 The IPv4 address acknowledgement option described in section 3.2.1 1763 requires a new option type. This option is included in the 1764 Mobility header described in [RFC3775]. 1766 The NAT detection option described in section 3.2.2 requires a new 1767 option type. This option is included in the Mobility header 1768 described in [RFC3775]. 1770 The IPv4 Care-of address option described in section 3.1.2 1771 requires a new option type allocation [RFC3775]. 1773 The Status field in the IPv4 home address option should be allocated 1774 by IANA under the new registry: "DSMIPv6 IPv4 home address option 1775 status codes". 1777 The status field values are allocated using the following procedure: 1779 1. New Status field values are allocated through IETF review. This 1780 is for all RFC types including standards track, informational, 1781 and experimental status that originate from the IETF and have 1782 been approved by the IESG for publication. 1784 2. Requests for new option type value assignments from outside the 1785 IETF are only made through the publication of an IETF document, 1786 per 1) above. Note also that documents published as "RFC Editor 1787 contributions" [RFC4844] are not considered to be IETF documents. 1789 10. References 1791 10.1. Normative References 1793 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1794 Requirement Levels", BCP 14, RFC 2119, March 1997. 1796 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1797 IPv6 Specification", RFC 2473, December 1998. 1799 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1800 of Explicit Congestion Notification (ECN) to IP", 1801 RFC 3168, September 2001. 1803 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1804 in IPv6", RFC 3775, June 2004. 1806 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1807 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1808 RFC 3948, January 2005. 1810 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 1811 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 1812 RFC 3963, January 2005. 1814 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1815 RFC 4306, December 2005. 1817 [RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting 1818 Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006. 1820 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 1821 (MOBIKE)", RFC 4555, June 2006. 1823 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1824 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1825 September 2007. 1827 [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 1828 IKEv2 and the Revised IPsec Architecture", RFC 4877, 1829 April 2007. 1831 [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 1832 Bootstrapping in Split Scenario", RFC 5026, October 2007. 1834 10.2. Informative 1836 [I-D.ietf-mip6-bootstrapping-integrated-dhc] 1837 Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the 1838 Integrated Scenario", 1839 draft-ietf-mip6-bootstrapping-integrated-dhc-06 (work in 1840 progress), April 2008. 1842 [RFC2983] Black, D., "Differentiated Services and Tunnels", 1843 RFC 2983, October 2000. 1845 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 1846 August 2002. 1848 [RFC3519] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of 1849 Network Address Translation (NAT) Devices", RFC 3519, 1850 April 2003. 1852 [RFC3978] Bradner, S., "IETF Rights in Contributions", RFC 3978, 1853 March 2005. 1855 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1856 for IPv6 Hosts and Routers", RFC 4213, October 2005. 1858 [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the- 1859 Network Tunneling", RFC 4459, April 2006. 1861 [RFC4844] Daigle, L. and Internet Architecture Board, "The RFC 1862 Series and RFC Editor", RFC 4844, July 2007. 1864 [RFC4977] Tsirtsis, G. and H. Soliman, "Problem Statement: Dual 1865 Stack Mobility", RFC 4977, August 2007. 1867 [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. 1868 Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility 1869 Management", RFC 5380, October 2008. 1871 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1872 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1873 October 2008. 1875 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 1876 for Application Designers", BCP 145, RFC 5405, 1877 November 2008. 1879 Appendix A. Contributors 1881 This document reflects discussions and contributions from several 1882 people including (in alphabetical order): 1884 Vijay Devarapalli: vijay.devarapalli@azairenet.com 1886 James Kempf: kempf@docomolabs-usa.com 1888 Henrik Levkowetz: henrik@levkowetz.com 1890 Pascal Thubert: pthubert@cisco.com 1892 George Tsirtsis: G.Tsirtsis@Qualcomm.com 1894 Wakikawa Ryuji: ryuji@sfc.wide.ad.jp 1896 Author's Address 1898 Hesham Soliman (editor) 1899 Elevate Technologies 1901 Email: hesham@elevatemobile.com