idnits 2.17.1 draft-ietf-mext-nemo-v4traversal-07.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2003. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2014. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2021. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2027. 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 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 (December 13, 2008) is 5611 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 1707, but not defined == Missing Reference: 'IPv4 ACK' is mentioned on line 1744, but not defined == Missing Reference: 'CERTREQ' is mentioned on line 1624, but not defined == Missing Reference: 'N' is mentioned on line 1756, but not defined == Missing Reference: 'KEi' is mentioned on line 1756, but not defined == Missing Reference: 'KEr' is mentioned on line 1760, but not defined == Unused Reference: 'RFC4306' is defined on line 1896, but no explicit reference was found in the text == Unused Reference: 'RFC4877' is defined on line 1906, but no explicit reference was found in the text == Unused Reference: 'RFC3978' is defined on line 1936, 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 5405 (Obsoleted by RFC 8085) Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 11 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 December 13, 2008 5 Expires: June 16, 2009 7 Mobile IPv6 Support for Dual Stack Hosts and Routers (DSMIPv6) 8 draft-ietf-mext-nemo-v4traversal-07.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 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 to 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/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on June 16, 2009. 35 Abstract 37 The current Mobile IPv6 and NEMO specifications support IPv6 only. 38 This specification extends those standards to allow the registration 39 of IPv4 addresses and prefixes, respectively, and the transport of 40 both IPv4 and IPv6 packets over the tunnel to the home agent. This 41 specification also allows the Mobile Node to roam over both IPv6 and 42 IPv4, including the case where Network Address Translation is present 43 on the path between the mobile node and its home agent. 45 Table of Contents 47 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 48 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 49 2.1. Motivation for Using Mobile IPv6 Only . . . . . . . . . . 6 50 2.2. Scenarios Considered by This Specification . . . . . . . . 6 51 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 8 52 3.1. Home Agent Address Discovery . . . . . . . . . . . . . . . 8 53 3.2. Mobile Prefix Solicitation and Advertisement . . . . . . . 9 54 3.3. Binding Management . . . . . . . . . . . . . . . . . . . . 9 55 3.3.1. Foreign Network Supports IPv6 . . . . . . . . . . . . 10 56 3.3.2. Foreign Network Supports IPv4 Only . . . . . . . . . . 11 57 3.4. Route Optimization . . . . . . . . . . . . . . . . . . . . 12 58 3.5. Dynamic IPv4 Home Address Allocation . . . . . . . . . . . 13 59 4. Extensions And Modifications To Mobile IPv6 . . . . . . . . . 14 60 4.1. Binding Update Extensions . . . . . . . . . . . . . . . . 14 61 4.1.1. IPv4 Home Address Option . . . . . . . . . . . . . . . 14 62 4.1.2. The IPv4 Care-of Address Option . . . . . . . . . . . 15 63 4.1.3. The Binding Update Message Extensions . . . . . . . . 16 64 4.2. Binding Acknowledgement Extensions . . . . . . . . . . . . 16 65 4.2.1. IPv4 Address Acknowledgement Option . . . . . . . . . 16 66 4.2.2. The NAT Detection Option . . . . . . . . . . . . . . . 18 67 4.2.3. Extensions to the Binding Acknowledgement Message . . 19 68 5. Protocol operation . . . . . . . . . . . . . . . . . . . . . . 20 69 5.1. Tunelling Formats . . . . . . . . . . . . . . . . . . . . 20 70 5.1.1. tunnelling Impacts on Transport and MTU . . . . . . . 23 71 5.2. NAT Detection . . . . . . . . . . . . . . . . . . . . . . 23 72 5.3. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . . 25 73 5.4. Mobile Node Operation . . . . . . . . . . . . . . . . . . 26 74 5.4.1. Selecting a Care-of address . . . . . . . . . . . . . 26 75 5.4.2. Sending Binding Updates . . . . . . . . . . . . . . . 27 76 5.4.3. Sending Packets from a Visited Network . . . . . . . . 29 77 5.4.4. Movement Detection in IPv4-only Networks . . . . . . . 30 78 5.5. Home agent operation . . . . . . . . . . . . . . . . . . . 30 79 5.5.1. Sending Packets to the Mobile Node . . . . . . . . . . 32 80 5.6. Correspondent Node Operation . . . . . . . . . . . . . . . 33 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 34 82 6.1. Handover Interactions for IPsec and IKE . . . . . . . . . 35 83 6.2. IKE negotiation messages between the mobile node and 84 Home Agent . . . . . . . . . . . . . . . . . . . . . . . . 37 85 6.2.1. IKEv2 Operation for Securing DSMIPv6 Signaling . . . . 38 86 6.2.2. IKEv2 Operation for Securing Data over IPv4 . . . . . 41 87 7. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 43 88 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44 89 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 90 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46 91 10.1. Normative References . . . . . . . . . . . . . . . . . . . 46 92 10.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 46 93 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 48 94 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 49 95 Intellectual Property and Copyright Statements . . . . . . . . . . 50 97 1. Requirements notation 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [RFC2119]. 103 2. Introduction 105 Mobile IPv6 [RFC3775] and [RFC3963] allow mobile nodes to move within 106 the Internet while maintaining reachability and ongoing sessions, 107 using an IPv6 home address or prefix. However, since IPv6 is not 108 widely deployed, it is unlikely that mobile nodes will initially use 109 IPv6 addresses only for their connections. It is reasonable to 110 assume that mobile nodes will, for a long time, need an IPv4 home 111 address that can be used by upper layers. It is also reasonable to 112 assume that mobile nodes will move to networks that might not support 113 IPv6 and would therefore need the capability to support an IPv4 114 Care-of Address. Hence, this specification extends Mobile IPv6 115 capabilities to allow dual stack mobile nodes to request that their 116 home agent (also dual stacked) tunnel IPv4/IPv6 packets addressed to 117 their home addresses, as well as IPv4/IPv6 care-of address(es). 119 Using this specification, mobile nodes would only need Mobile IPv6 120 and [RFC3963] to manage mobility while moving within the Internet; 121 hence eliminating the need to run two mobility management protocols 122 simultaneously. This specification provides the extensions needed in 123 order to allow IPv6 mobility only to be used by dual stack mobile 124 nodes. 126 This specification will also consider cases where a mobile node moves 127 into a private IPv4 network and gets configured with a private IPv4 128 Care-of Address. In these scenarios, the mobile node needs to be 129 able to traverse the IPv4 NAT in order to communicate with the home 130 agent. IPv4 NAT traversal for Mobile IPv6 is presented in this 131 specification. 133 In this specification, the term mobile node refers to both a mobile 134 host and mobile router unless the discussion is specific to either 135 hosts or routers. Similarly, we use the term home address to reflect 136 an address/prefix format. Note that both mobile host and router 137 functionality has already been defined in [RFC3775] and [RFC3963], 138 respectively. This specification does not change that already 139 defined behavior, nor does it extend the specific type of hosts and 140 router support already defined, except for two things: (i) allowing 141 the mobile node to communicate with its home agent even over IPv4 142 networks, and (ii) allowing the use of IPv4 home addresses and 143 prefixes. 145 In this specification, extensions are defined for the binding update 146 and binding acknowledgement. It should be noted that all these 147 extensions apply to cases where the mobile node communicates with a 148 Mobility Anchor Point (MAP) as defined in [RFC5380]. The 149 requirements on the MAP are identical to those stated for the home 150 agent, although it is unlikely that NAT traversal would be needed 151 with a MAP as it is expected to be in the same address domain. 153 2.1. Motivation for Using Mobile IPv6 Only 155 IPv6 offers a number of improvements over today's IPv4, primarily due 156 to its large address space. Mobile IPv6 offers a number of 157 improvements over Mobile IPv4 [RFC3344], mainly due to capabilities 158 inherited from IPv6. For instance, route optimization and dynamic 159 home agent discovery can only be achieved with Mobile IPv6. 161 One of the advantages of the large address space provided by IPv6 is 162 that it allows mobile nodes to obtain a globally unique care-of 163 address wherever they are. Hence, there is no need for Network 164 Address Translator (NAT) traversal techniques designed for Mobile 165 IPv4. This allows Mobile IPv6 to be a significantly simpler and more 166 bandwidth efficient mobility management protocol. At the same time, 167 during the transition towards IPv6, NAT traversal for existing 168 private IPv4 networks needs to be considered. This specification 169 introduces NAT traversal for this purpose. 171 The above benefits make the case for using Mobile IPv6-only for dual 172 stack mobile nodes as it allows for a long lasting mobility solution. 173 The use of Mobile IPv6 for dual stack mobility eliminates the need 174 for changing the mobility solution due to the introduction of IPv6 175 within a deployed network. 177 2.2. Scenarios Considered by This Specification 179 There are several scenarios that illustrate potential 180 incompatibilities for mobile nodes using Mobile IPv6. Some of the 181 problems associated with mobility and transition issues were 182 presented in [RFC4977]. This specification considers the scenarios 183 that address all the problems discussed in [RFC4977]. The scenarios 184 considered in this specification are listed below. 186 All of the following scenarios assume that both the mobile node and 187 the home agent are IPv4 and IPv6-enabled and that only Mobile IPv6 is 188 used between the mobile node and the home agent. We also assume that 189 the home agent is always reachable through a globally unique IPv4 190 address. Finally, it's important to note that the following 191 scenarios are not mutually exclusive. 193 Scenario 1: IPv4-only foreign network 195 In this scenario, a mobile node is connected to an IPv4-only foreign 196 network. The mobile node can only configure an IPv4 Care-of Address. 198 Scenario 2: Mobile node behind a NAT 199 In this scenario, the mobile node is in a private IPv4 foreign 200 network that has a NAT device connecting it to the Internet. If the 201 home agent is located outside the NAT device, the mobile node will 202 need a NAT traversal mechanism to communicate with the home agent. 204 Scenario 3: Home Agent behind a NAT 206 In this scenario, the communication between the mobile node and the 207 home agent is further complicated by the fact that the home agent is 208 located within a private IPv4 network. However, in this scenario, we 209 assume that the home agent is allocated a globally unique IPv4 210 address. The address might not be physically configured on the home 211 agent interface. Instead, it is associated with the home agent on 212 the NAPT device, which allows the home agent to be reachable through 213 address or port mapping. 215 Scenario 4: Use Of IPv4-only applications 217 In this scenario, the mobile node may be located in an IPv4, IPv6 or 218 a dual network. However, the mobile node might be communicating with 219 an IPv4-only node. In this case, the mobile node would need a stable 220 IPv4 address for its application. The alternative to using an IPv4 221 address is the use of protocol translators; however, end-to-end 222 communication with IPv4 is preferred to the use of protocol 223 translators. 225 The mobile node may also be communicating with an IPv4-only 226 application that requires an IPv4 address. 228 The cases above illustrate the need for the allocation of a stable 229 IPv4 home address to the mobile node. This is done using an IPv4 230 home address. Since running Mobile IPv4 and Mobile IPv6 231 simultaneously is problematic (as illustrated in [RFC4977]), this 232 scenario adds a requirement on Mobile IPv6 to support IPv4 home 233 addresses. 235 3. Solution Overview 237 In order to allow Mobile IPv6 to be used by dual stack mobile nodes, 238 the following needs to be done: 240 o Mobile nodes should be able to use an IPv4 and IPv6 home or 241 care-of address simultaneously and update their home agents 242 accordingly. 244 o Mobile nodes need to be able to know the IPv4 address of the home 245 agent as well as its IPv6 address. There is no need for IPv4 246 prefix discovery however. 248 o Mobile nodes need to be able to detect the presence of a NAT 249 device and traverse it in order to communicate with the home 250 agent. 252 This section presents an overview of the extensions required in order 253 to allow mobile nodes to use Mobile IPv6 only for IP mobility 254 management 256 3.1. Home Agent Address Discovery 258 Dynamic home agent Address Discovery (DHAAD) was defined in [RFC3775] 259 to allow mobile nodes to discover their home agents by appending a 260 well-known anycast interface identifier to their home link's prefix. 261 However, this mechanism is based on IPv6-anycast routing. If a 262 mobile node is located in an IPv4-only foreign network, it cannot 263 rely on native IPv6 routing. In this scenario, the solution for 264 discovering the home agent's IPv4 address is through the Domain Name 265 System (DNS). If the MN is attached to an IPv6-only or dual stack 266 network, it may also use procedures defined in 267 [I-D.ietf-mip6-bootstrapping-integrated-dhc] to discover home agent 268 information. Note that the use of 269 [I-D.ietf-mip6-bootstrapping-integrated-dhc] cannot give the mobile 270 node information that allows it to continue to communicate with the 271 home agent if, for example, the mobile node moved from an IPv6- 272 enabled network to an IPv4-only network. In this scenario, the 273 mobile node would need to discover the IPv4 address of its home agent 274 through the DNS. 276 For DNS lookup by name, the mobile node should be configured with the 277 name of the home agent. When the mobile node needs to discover a 278 home agent, it sends a DNS request with QNAME set to the configured 279 name. An example is "ha1.example.com". If a home agent has an IPv4 280 and IPv6 address, the corresponding DNS record should be configured 281 with both 'AAAA' and 'A' records. Accordingly, the DNS reply will 282 contain 'AAAA' and 'A' records. 284 For DNS lookup by service, the SRV record defined in [RFC5026] is 285 reused. For instance, if the service name is "mip6" and the protocol 286 name is "ipv6" in the SRV record, the mobile node SHOULD send a DNS 287 request with the QNAME set to "_mip6._ipv6.example.com". The 288 response should contain the home agent's FQDN(s) and may include the 289 corresponding 'AAAA' and 'A' records as well. 291 If multiple home agents reside on the home link, each configured with 292 a public IPv4 address, then the operation above applies. The correct 293 DNS entries can be configured accordingly. 295 3.2. Mobile Prefix Solicitation and Advertisement 297 According to [RFC3775], the mobile node can send a Mobile Prefix 298 Solicitation and receive a Mobile Prefix Advertisement containing all 299 prefixes advertised on the home link. 301 A dual stack mobile node MAY send a Mobile Prefix Solicitation 302 message encapsulated in IPv4 (i.e., IPv6 in IPv4) in the case where 303 the mobile node has no access to IPv6 within the local network. 304 Securing these messages requires the mobile node to have a security 305 association with the home agent, using IPsec (AH or ESP) and based on 306 the mobile node's IPv4 care-of address as described in [RFC3775]. 307 Since the mobile node needs to encapsulate all IPv6 traffic sent to 308 the home agent into IPv4 while located in an IPv4-only visited 309 network, this SA would match all packets if the selectors were based 310 on the information in the outer header. That is, the SA selectors 311 being the protocol number (protocol is always IP in IP), as well as, 312 source and destination addresses are all common to all packets. If 313 this effect is not desired, the mobile node can base the SA on the 314 information in the inner header (i.e., using the home agent's IPv6 315 address, the mobile node's home address and the ICMP protocol 316 number). This security association would use transport mode ESP 317 protection. 319 3.3. Binding Management 321 A dual stack mobile node will need to update its home agent with its 322 care-of address. If a mobile node has an IPv4 and an IPv6 home 323 address, it will need to create a binding cache entry for each 324 address. The format of the IP packet carrying the binding update and 325 acknowledgement messages will vary depending on whether the mobile 326 node has access to IPv6 in the visited network. There are three 327 different scenarios to consider with respect to the visited network: 329 o The visited network has IPv6 connectivity and provides the mobile 330 node with a care-of address (in a stateful or stateless manner). 332 o The mobile node can only configure a globally unique IPv4 address 333 in the visited network. 335 o The mobile node can only configure a private IPv4 address in the 336 visited network. 338 3.3.1. Foreign Network Supports IPv6 340 In this case, the mobile node is able to configure a globally unique 341 IPv6 address. The mobile node will send a binding update to the IPv6 342 address of its home agent, as defined in [RFC3775]. The binding 343 update MAY include the IPv4 home address option introduced in this 344 document. After receiving the binding update, the home agent creates 345 two binding cache entries, one for the mobile node's IPv4 home 346 address, and another for the mobile node's IPv6 home address. Both 347 entries will point to the mobile node's IPv6 care-of address. Hence, 348 whenever a packet is addressed to the mobile node's IPv4 or IPv6 home 349 addresses, the home agent will tunnel it in IPv6 to the mobile node's 350 IPv6 care-of address included in the binding update. Effectively, 351 the mobile node establishes two different tunnels, one for its IPv4 352 traffic (IPv4 in IPv6) and one for its IPv6 traffic (IPv6 in IPv6) 353 with a single binding update. 355 In this scenario, the only addition to [RFC3775] is the inclusion of 356 the IPv4 home address option in the binding update message. 358 After accepting the binding update and creating the corresponding 359 binding cache entries, the home agent MUST send a binding 360 acknowledgement to the mobile node as defined in [RFC3775]. In 361 addition, if the binding update included an IPv4 home address option, 362 the binding acknowledgement MUST include the IPv4 address 363 acknowledgment option as described later in this specification. This 364 option informs the mobile node whether the binding was accepted for 365 the IPv4 home address. If this option is not included in the binding 366 acknowledgement and the IPv4 home address option was included in the 367 binding update, the mobile node MUST assume that the home agent does 368 not support the IPv4 home address option and therefore SHOULD NOT 369 include the option in future binding updates to that home agent 370 address. 372 When a mobile node acquires both IPv4 and IPv6 care-of addresses at 373 the foreign network, it SHOULD prioritize the IPv6 care-of address 374 for its MIPv6 binding. The mobile node MUST NOT register both IPv4 375 and IPv6 care-of addresses to its home agent. 377 3.3.2. Foreign Network Supports IPv4 Only 379 If the mobile node is in a foreign network that only supports IPv4, 380 it needs to detect whether a NAT is in its communication path to the 381 home agent. This is done while exchanging the binding update and 382 acknowledgement messages as shown later in this document. NAT 383 detection is needed for the purposes of the signaling presented in 384 this specification. 386 3.3.2.1. Foreign Network Supports IPv4 Only (Public Addresses) 388 In this scenario the mobile node will need to tunnel IPv6 packets 389 containing the binding update to the home agent's IPv4 address. The 390 mobile node uses the IPv4 address it gets from the foreign network as 391 a source address in the outer header. The binding update will 392 contain the mobile node's IPv6 home address. However, since the 393 care-of address in this scenario is the mobile node's IPv4 address, 394 the mobile node MUST include its IPv4 care-of address in the IPv6 395 packet. The IPv4 address is represented in the IPv4 Care-of address 396 option defined in this specification. If the mobile node had an IPv4 397 home address, it MUST also include the IPv4 home address option 398 described in this specification. 400 After accepting the binding update, the home agent MUST create a new 401 binding cache entry for the mobile node's IPv6 home address. If an 402 IPv4 home address option were included, the home agent MUST create 403 another entry for that address. All entries MUST point to the mobile 404 node's IPv4 care-of address. Hence, all packets addressed to the 405 mobile node's home address(es) (IPv4 or IPv6) will be encapsulated in 406 an IPv4 header that includes the home agent's IPv4 address in the 407 source address field and the mobile node's IPv4 care-of address in 408 the destination address field. 410 After accepting the binding updates and creating the corresponding 411 entries, the home agent MUST send a binding acknowledgement as 412 specified in [RFC3775]. In addition, if the binding update included 413 an IPv4 home address option, the binding acknowledgement MUST include 414 the IPv4 address acknowledgment option as described later in this 415 specification. The binding acknowledgement is encapsulated to the 416 IPv4 care-of address, which was included in the source address field 417 of the IPv4 header encapsulating the binding update. 419 3.3.2.2. Foreign Network Supports IPv4 Only (Private Addresses) 421 In this scenario the mobile node will need to tunnel IPv6 packets 422 containing the binding update to the home agent's IPv4 address. In 423 order to traverse the NAT device, IPv6 packets are tunneled using UDP 424 and IPv4. The UDP port allocated for the home agent is TBD_DSMIPv6. 426 The mobile node uses the IPv4 address it gets from the visited 427 network as a source address in the IPv4 header. The binding update 428 will contain the mobile node's IPv6 home address. 430 After accepting the binding update, the home agent MUST create a new 431 binding cache entry for the mobile node's IPv6 home address. If an 432 IPv4 home address option were included, the home agent MUST create 433 another entry for that address. All entries MUST point to the mobile 434 node's IPv4 care-of address included in the source address of the 435 IPv4 header that encapsulated the binding update message. In 436 addition, the tunnel used MUST indicate UDP encapsulation for NAT 437 traversal. Hence, all packets addressed to the mobile node's home 438 address(es) (IPv4 or IPv6) will be encapsulated in UDP then 439 encapsulated in an IPv4 header that includes the home agent's IPv4 440 address in the source address field and the mobile node's IPv4 care- 441 of address in the destination address field. Note that the home 442 agent MUST store the source UDP port numbers contained in the packet 443 carrying the binding update in order to be able to forward packets to 444 the mobile node. 446 After accepting the binding updates and creating the corresponding 447 entries, the home agent MUST send a binding acknowledgement as 448 specified in [RFC3775]. In addition, if the binding update included 449 an IPv4 home address option, the binding acknowledgement MUST include 450 the IPv4 address acknowledgment option as described later in this 451 specification. The binding acknowledgement is encapsulated in UDP 452 then IPv4 with the home agent's IPv4 address in the source address 453 field and the mobile node's IPv4 care-of address in the destination 454 field. The IPv4 address in the destination field of the IPv4 packet 455 is the source address received in the IPv4 header containing the 456 binding update message. The inner IPv6 packet will contain the home 457 agent's IPv6 address as a source address and the mobile node's IPv6 458 home address in the destination address field. 460 The mobile node needs to maintain the NAT bindings for its current 461 IPv4 care-of address. This is done through sending the binding 462 update regularly to the home agent. 464 3.4. Route Optimization 466 Route optimization, as specified in [RFC3775] will operate in an 467 identical manner for dual stack mobile nodes when they are located in 468 a visited network that provides IPv6 addresses to the mobile node. 469 However, when located in an IPv4-only network, route optimization 470 will not be possible due to the difficulty of performing the care-of 471 address test. Therefore, mobile nodes will need to communicate 472 through the home agent. 474 Route optimization will not be possible for IPv4 traffic. That is, 475 traffic addressed to the mobile node's IPv4 home address. This is 476 similar to using Mobile IPv4, therefore there is no reduction of 477 features resulting from using this specification. 479 3.5. Dynamic IPv4 Home Address Allocation 481 It is possible to allow for the mobile node's IPv4 home address to be 482 allocated dynamically. This is done by including 0.0.0.0 in the IPv4 483 home address option included in the binding update. The home agent 484 SHOULD allocate an IPv4 address to the mobile node and include it in 485 the IPv4 address acknowledgement option sent to the mobile node. In 486 this case, the lifetime of the binding is bound to the minimum of the 487 lifetimes of the IPv6 binding and the lease time of the IPv4 home 488 address. 490 4. Extensions And Modifications To Mobile IPv6 492 This section highlights the protocol and implementation additions 493 required to support this specification. 495 4.1. Binding Update Extensions 497 4.1.1. IPv4 Home Address Option 499 This option is included in the Mobility Header including the binding 500 update message sent from the mobile node to a home agent or Mobility 501 Anchor Point. The alignment requirement for this option is 4n. 503 0 1 2 3 504 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 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | Type | Length |Prefix-len |P| Reserved | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | IPv4 home address | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 Figure 1: IPv4 Home Address Option 513 Type 515 TBD 517 Length 519 6 521 Prefix-len 523 The length of the prefix allocated to the mobile node. If only a 524 single address is allocated, this field MUST be set to 32. In the 525 first binding update requesting a prefix, the field contains the 526 prefix length requested. However, in the following binding 527 updates, this field must contain the length of the prefix 528 allocated. A value of zero is invalid and MUST be considered an 529 error. 531 P 533 A flag indicating, when set, that the mobile node requests a 534 mobile network prefix. This flag is only relevant for new 535 requests, and must be ignored for binding refreshes. 537 Reserved 539 This field is reserved for future use. It MUST be set to zero by 540 the sender and ignored by the receiver. 542 IPv4 Home Address 544 The mobile node's IPv4 home address that should be defended by the 545 home agent. This field could contain any unicast IPv4 address 546 (public or private) that was assigned to the mobile node. The 547 value 0.0.0.0 is used to request an IPv4 home address from the 548 home agent. A mobile node may choose to use this option to 549 request a prefix by setting the address to the All Zeroes and 550 setting the P flag. The mobile node could then form an IPv4 home 551 address based on the allocated prefix. Alternatively, the mobile 552 node may use two different options, one for requesting an address 553 (Static or Dynamic) and another for requesting a prefix. 555 4.1.2. The IPv4 Care-of Address Option 557 This option is included in the Mobility Header including the binding 558 update message sent from the mobile node to a home agent or Mobility 559 Anchor Point. The alignment requirement for this option is 4n. 561 0 1 2 3 562 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 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | Type | Length | Reserved | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | IPv4 Care-of address | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 Figure 2: The IPv4 CoA Option 571 Type 573 TBD 575 Length 577 6 579 Reserved 581 This field is set to zero by the sender and ignored by the 582 receiver. 584 IPv4 Care-of Address 586 This field contains the mobile node's IPv4 care- of address. The 587 IPv4 care-of address is used when the mobile node is located in an 588 IPv4-only network. 590 4.1.3. The Binding Update Message Extensions 592 This specification extends the Binding Update message with two new 593 flags. The flags are shown and described below. 595 0 1 2 3 596 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 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | Sequence # | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 |A|H|L|K|M|R|P|F|T| Reserved | Lifetime | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 Figure 3: Binding Update message 605 F 607 When set, this flag indicates a request for forcing UDP 608 encapsulation regardless of whether a NAT is present on the path 609 between the mobile node and the home agent. This flag may be set 610 by the mobile node if it is required to use UDP encapsulation 611 regardless of the presence of a NAT. 613 T 615 When set, this flag indicates that the mobile node requests the 616 use of the TLV-format for encapsulating IPv6 in IPv4. The TLV- 617 format is described later in this document. 619 4.2. Binding Acknowledgement Extensions 621 4.2.1. IPv4 Address Acknowledgement Option 623 This option is included in the Mobility Header including the binding 624 acknowledgement message sent from the home agent or Mobility Anchor 625 Point to the mobile node. This option indicates whether a binding 626 cache entry was created for the mobile node's IPv4 address. 627 Additionally, this option includes an IPv4 home address in the case 628 of Dynamic IPv4 home address configuration (i.e., if the unspecified 629 IPv4 address was included in the binding update). The alignment 630 requirement for this option is 4n. 632 0 1 2 3 633 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 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 | Type | Length | Status |Pref-len |Res| 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | IPv4 home address | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 Figure 4: IPv4 Address Acknowledgement Option 642 Type 644 TBD 646 Length 648 6 650 Status 652 Indicates success or failure for the IPv4 home address binding. 653 Values from 0 to 127 indicate success. Higher values indicate 654 failure. 656 Pref-len 658 The prefix length of the address allocated. This field is only 659 valid in case of success and MUST be set to zero and ignored in 660 case of failure. This field overrides what the mobile node 661 requested (if not equal to the requested length). 663 Res 665 This field is reserved for future use. It MUST be set to zero by 666 the sender and ignored by the receiver 668 IPv4 Home Address 670 The IPv4 home address that the home agent will use in the binding 671 cache entry. This could be a public or private address. This 672 field MUST contain the mobile node's IPv4 home address. If the 673 address were dynamically allocated the home agent will add the 674 address to inform the mobile node. Otherwise, if the address were 675 statically allocated to the mobile node, the home agent will copy 676 it from the binding update message. 678 The following values are allocated for the Status field: 680 o 0 Success 682 o 128 Failure, reason unspecified 684 o 129 Administratively prohibited 686 o 130 Incorrect IPv4 home address 688 o 131 Invalid IPv4 address 690 o 132 Dynamic IPv4 home address assignment not available 692 o 133 Prefix allocation unauthorized 694 4.2.2. The NAT Detection Option 696 This option is sent from the home agent to the mobile node to 697 indicate whether a NAT was in the path. This option MAY also include 698 a suggested NAT binding refresh time for the mobile node. This might 699 be usefl for scenarios where the mobile node is known to be moving 700 within the home agent's administrative domain, and therefore the NAT 701 timeout is known (through configuration) to the home agent. Section 702 3.5 of [RFC5405] discusses issues with NAT timeout in some detail. 704 The alignment requirement for this option is 4n. If a NAT is 705 detected, this option MUST be sent by the home agent. 707 0 1 2 3 708 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 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 | Type | Length |F| Reserved | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 | Refresh time | 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 Figure 5: The NAT Detection Option 717 Type 719 TBD 721 Length 723 6 725 F 726 This flag indicates to the mobile node that UDP encapsulation is 727 required. When set, this flag indicates that the mobile node MUST 728 use UDP encapsulation even if a NAT is not located between the 729 mobile node and home agent. 731 Reserved 733 This field is reserved for future use. It MUST be set to zero by 734 the sender and ignored by the receiver. 736 Refresh Time 738 A suggested time (in seconds) for the mobile node to refresh the 739 NAT binding. If set to zero, it is ignored. If this field is set 740 to all 1s it means that keepalives are not needed, i.e., no NAT 741 was detected. The home agent MUST be configured with a default 742 value for the refresh time. The recommended value is outlined in 743 Section 7 745 4.2.3. Extensions to the Binding Acknowledgement Message 747 This specification extends the binding acknowledgement message with a 748 new flag. The new flag is shown and described below. 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | Status |K|R|P|T| Res | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | Sequence # | Lifetime | 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 Figure 6: Binding Acknowledgement message 758 T 760 This flag indicates, when set, that the sender of the binding 761 acknowledgement supports the TLV- tunnel format. 763 5. Protocol operation 765 This section presents the protocol operation and processing for the 766 messages presented above. In addition, this section introduces the 767 NAT detection and traversal mechanism used by this specification. 769 5.1. Tunelling Formats 771 This specification allows the mobile node to use various tunnelling 772 formats depending on its location and the visited network's 773 capabilities. The mobile node can tunnel IPv6 in IPv4, IPv4 in IPv6 774 or use UDP encapsulation to tunnel IPv6 in IPv4. Naturally, this 775 specification also supports tunnelling IPv6 in IPv6. 777 This specification allows UDP-based tunnelling to be used between the 778 mobile node and its home agent or MAP using either vanilla UDP 779 encapsulation or TLV-header UDP encapsulation. A vanilla UDP 780 encapsulation format means the following order of headers: 782 IPv4 784 UDP 786 IP (v4 or v6) 788 Other headers 790 When using this format the receiver would parse the version field 791 following the UDP header in order to determine whether the following 792 header is IPv4 or IPv6. The rest of the headers are processed 793 normally. The above order of headers does not take IPsec headers 794 into account as they may be placed in different parts of the packet. 795 The above format MUST be supported by all implementations of this 796 specification and MUST always be used to send the binding update 797 message. 799 Vanilla UDP Tunnelling can also encapsulate an ESP header as shown 800 below. 802 IPv4 804 UDP 806 ESP 808 IP (v4 or v6) 809 Other headers 811 The negotiation of the secure tunnel format described above is 812 discussed in Section 6.2. The receiver of a vanilla UDP tunnel 813 detects whether an ESP header is present or not based on the UDP port 814 used. 816 TLV-header UDP encapsulation is represented by the following order of 817 headers: 819 IP (v4 or v6) 821 UDP 823 TLV-header 825 Other headers 827 The use of the TLV-header is negotiated during the binding update/ 828 acknowledgement exchange. If the TLV-header is agreed upon, the 829 receiver of the TLV-header UDP encapsulated packet expects the TLV 830 header to follow UDP. The TLV header contains the type of the 831 following message and its length. The Type field is limited to 832 values of 0 and 1 to make sure that the receiver can tell the 833 difference between the Type field and the IP version field in a 834 packet that contains an IP header after UDP. Hence, the TLV header 835 can carry traffic other than IP. Distinction between IP and TLV 836 encapsulation is needed because the binding update will never be sent 837 in TLV-tunnel format. 839 The mobile node negotiates the format for tunnelling payload traffic 840 during the binding exchange. If a mobile node prefers to use the 841 TLV- header UDP encapsulation, it sets the T flag in the binding 842 update sent to the home agent or MAP. If the receiver of the binding 843 update supports the TLV-header format, it SHOULD set the T flag in 844 the binding acknowledgement message. Otherwise, the T flag is 845 cleared. The setting of the T flag in the binding acknowledgement 846 indicates to the mobile node that it must use the TLV-header UDP 847 encapsulation format for all packets sent for the duration of the 848 binding or until a new binding update is sent. Each binding update 849 may renegotiate the tunnelling format. To avoid interoperability 850 issues, the sender of the binding acknowledgement MUST NOT set the T 851 flag unless it was set in the binding update sent from the mobile 852 node. 854 The TLV-header format is shown below. 856 0 1 2 3 857 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 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 | Type | Length | Reserved | 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 Figure 7: TLV-header format 864 Type 866 This field indicates the type of the payload following this 867 header. 869 Length 871 This field indicates the length of the payload following the 872 header, excluding the TLV-header itself. The use of this flag is 873 described in Section 5 875 Reserved 877 This field MUST be set to zero by the sender and ignored by the 878 receiver. 880 The following value is assigned to the Type field, other values may 881 be assigned in the future: 883 1 GRE [RFC2784] 885 In addition to UDP-based tunnelling, this specification allows for 886 standard IP in IP tunnelling as defined in [RFC2473] and [RFC4213]. 887 This can take place by tunnelling IPv4 in IPv6 or IPv6 in IPv4. 888 However, whenever a NAT is detected, the mobile node will default to 889 UDP-based encapsulation. The mobile node can request to always use 890 UDP encapsulation by setting the F flag in the binding update. If 891 the home agent does not accept the request, it MUST reject the 892 binding update with the new Status code: 894 144 Cannot force UDP encapsulation 896 Alternatively, the home agent can force UDP encapsulation by setting 897 the F flag in the NAT detection option included in the binding 898 acknowledgement. 900 5.1.1. tunnelling Impacts on Transport and MTU 902 Changing the tunnel format may occur due to movement of the mobile 903 node from one network to another. This can have impacts on the link 904 and path MTU, which may affect the amount of bandwidth available to 905 the applications. The mobile node may use PMTUD as specified in 906 [RFC4459]. 908 To accommodate traffic that uses Explicit Congestion Notification 909 (ECN), it is RECOMMENDED that the ECN and DSCP information is copied 910 between the inner and outer header as defined in [RFC3168] and 911 [RFC2983]. It is RECOMMENDED that the full-functionality option 912 defined in section 9.1.1 of [RFC3168]is used to deal with ECN. 914 Note that some impementations may not be able to use ECN over the UDP 915 tunnel. This is due to the lack of access to ECN bits in the UDP API 916 on most platforms. However, this issue can be avoided if UDP 917 encapsulation is done in the kernel. 919 Note that when using UDP encapsulation, the TTL field must be 920 decremented in the same manner as when IP in IP encapsulation is 921 used. 923 5.2. NAT Detection 925 This section deals with NAT detection for the purpose of 926 encapsulating packets between the mobile node and the home agent. 927 Mobile IPv6 uses IKEv2 to establish te IPsec security association 928 between the mobile node and the home agent. IKEv2 has its own NAT 929 detection mechanism. However, IKEv2's NAT detection is only used for 930 the purpose of setting up the IPsec SA for secure traffic. The 931 interactions between the two NAT traversal mechanisms are described 932 in Section 6 934 NAT detection is done when the initial binding update message is sent 935 from the mobile node to the home agent. When located in an IPv4-only 936 foreign link, the mobile node sends the binding update message 937 encapsulated in UDP and IPv4. The source address of the IPv6 packet 938 is the mobile node's IPv6 home address. The destination address is 939 the IPv6 address of the home agent. The IPv4 header contains the 940 IPv4 care-of address in the source address field and the IPv4 address 941 of the home agent in the destination address field. 943 When the home agent receives the encapsulated binding update, it 944 compares the IPv4 address of the source address field in the IPv4 945 header with the IPv4 address included in the IPv4 care-of address 946 option. If the two addresses match, no NAT device was in the path. 947 Otherwise, a NAT device was in the path and the NAT detection option 948 is included in the binding acknowledgement. The binding 949 acknowledgement, and all future packets, are then encapsulated in UDP 950 and IPv4. The source address in the IPv4 header is the IPv4 address 951 of the home agent. The destination address is the IPv4 address 952 received in the IPv4 header encapsulating the binding update (this 953 address will be different from the IPv4 care-of address when a NAT is 954 in the path). The source port in the packet is the home agent's 955 source port. The destination port is the source port received in the 956 binding update message. Note that the home agent stores the port 957 numbers and associates them with the mobile node's tunnel in order to 958 forward future packets. 960 Upon receiving the binding acknowledgement with the NAT detection 961 option, the mobile node sets the tunnel to the home agent to UDP 962 encapsulation. Hence, all future packets to the home agent are 963 tunneled in UDP and IPv4. For all tunneled IPv6 packets, the source 964 address in the IPv6 header is the mobile node's IPv6 home address and 965 the destination address is the correspondent node's IPv6 address. 966 All tunneled IPv4 packets will contain the mobile node's IPv4 home 967 address in the source address field of the inner IPv4 packet and the 968 correspondent node's IPv4 address in the destination address field. 969 The outer IPv4 header is the same whether the inner packet is IPv4 or 970 IPv6. 972 If no NAT device was detected in the path between the mobile node and 973 the home agent then IPv6 packets are tunneled in an IPv4 header, 974 unless the home agent forces UDP encapsulation using the F flag. The 975 content of the inner and outer headers are identical to the UDP 976 encapsulation case. 978 A mobile node MUST always tunnel binding updates in UDP when located 979 in an IPv4-only network. Essentially, this process allows for 980 perpetual NAT detection. Similarly, the home agent MUST encapsulate 981 binding acknowledgements in a UDP header whenever the binding update 982 is encapsulated in UDP. 984 In conclusion, the packet formats for the binding update and 985 acknowledgement messages are shown below: 987 Binding update received by the home agent: 989 IPv4 header (src=V4ADDR, dst=HA_V4ADDR) 991 UDP header 993 IPv6 header (src=V6HOA, dst=HAADDR) 994 ESP Header 996 Mobility header 998 BU [IPv4 HAO] 1000 IPv4 CoA option 1002 Where V4ADDR is either the IPv4 care-of address or the address 1003 provided by the NAT device. V6HOA is the IPv6 home address of the 1004 mobile node. The binding update MAY also contain the IPv4 home 1005 address option IPv4 HAO. 1007 Binding acknowledgement sent by the home agent: 1009 IPv4 header (src= HA_V4ADDR, dst=V4ADDR) 1011 UDP Header 1013 IPv6 header (src=HAADDR, dst=V6HOA) 1015 ESP Header 1017 Mobility Header 1019 BA ([IPv4 ACK], NAT DET) 1021 Where V6HOA is IPv6 home address of the mobile node. The IPv4 ACK is 1022 the IPv4 address acknowledgement option, which is only included if 1023 the IPv4 home address option were present in the BU. The NAT DET is 1024 the NAT detection option, which MUST be present in the binding 1025 acknowledgement message if the binding update was encapsulated in 1026 UDP. 1028 5.3. NAT Keepalives 1030 If a NAT is detected, the mobile node will need to refresh the NAT 1031 bindings in order to be reachable from the home agent. NAT bindings 1032 can be refreshed through sending and receiving traffic encapsulated 1033 in UDP. However, if the mobile node is not active, it will need to 1034 periodically send a message to the home agent in order to refresh the 1035 NAT binding. This can be done using the binding update message. The 1036 binding update/acknowledgement pair will ensure that the NAT bindings 1037 are refreshed in a reliable manner. There is no way for the mobile 1038 node to know the exact time of the NAT binding. The default time 1039 suggested in this specification is NATKATIMEOUT. If the home agent 1040 suggests a different refresh period in the binding acknowledgement, 1041 the mobile node SHOULD use the value suggested by the home agent. 1043 If the refresh time in the NAT detection option in the binding 1044 acknowledgement is set to all 1s, the mobile node need not send 1045 messages to refresh the NAT binding. However, the mobile node may 1046 still be required to encapsulate traffic in UDP. This scenario may 1047 take place when a NAT is not detected, but the home agent still 1048 requires the mobile node to use UDP encapsulation. 1050 It should be noted that a mobile node that does not need to be 1051 reachable (i.e., only cares about the session continuity aspect of 1052 Mobile IP) it does not need to refresh the NAT binding. In this 1053 case, the mobile node would only be able to initiate communication 1054 with other nodes. However, this is likely to imply that the mobile 1055 node will need to send a binding update before initiating 1056 communication after a long idle period as it is likely to be assigned 1057 a different port and IPv4 address by the NAT when it initiates 1058 communication. Hence, an implementation may choose, for the sake of 1059 simplicity, to always maintain the NAT bindings even when it does not 1060 need reachability. 1062 5.4. Mobile Node Operation 1064 In addition to the operations specified in [RFC3775] and [RFC3963], 1065 this specification requires mobile nodes to be able to support an 1066 IPv4 home address. This specification also requires the mobile node 1067 to choose an IPv4 or an IPv6 care-of address. We first discuss 1068 care-of address selection, then continue with binding management and 1069 transmission of normal traffic. 1071 5.4.1. Selecting a Care-of address 1073 When a mobile node is in a dual stacked visited network, it will have 1074 a choice between an IPv4 and an IPv6 care-of address. The mobile 1075 node SHOULD prefer the IPv6 care-of address and bind it to its home 1076 address(es). If a mobile node attempted to bind the IPv6 care-of 1077 address to its home address(es) and the binding update timed out, the 1078 mobile node SHOULD: 1080 o Resend the binding update using the exponential back-off algorithm 1081 described in [RFC3775]. 1083 o If after three attempts in total a binding acknowledgement was not 1084 received, the mobile node SHOULD send a new binding update using 1085 the IPv4 care-of address. The exponential backoff algorithm 1086 described in [RFC3775] should be used for re-transmission of the 1087 binding update if needed. 1089 This procedure should be used to avoid scenarios where IPv6 1090 connectivity may not be as reliable as IPv4. This may take place 1091 during early deployments of IPv6, or simply due to temporary outages 1092 affecting IPv6 routing. 1094 It is RECOMMENDED that upon movement the mobile node does not change 1095 the IP address family chosen for the previous binding update unless 1096 the mobile node is aware that it has moved to a different 1097 administrative domain where previous problems with IPv6 routing may 1098 not be present. Repeating the above procedure upon every movement 1099 can cause significant degradation of the mobile node's applications' 1100 performace due to extended periods of packet losses after handover if 1101 the routing outage is still in effect. 1103 When using an IPv4 care-of address and IP in IP encapsulation, if the 1104 mobile node implementation is made aware by upper layers of 1105 persistent packet losses , it may attempt to resend the binding 1106 update with the F flag set, requesting UDP encapsulation for all 1107 packets. This may avoid packet losses due to situations where local 1108 firewalling policies prevent the use of IP in IP encapsulation. 1110 The effect of these address selection mechanism is to allow the 1111 follwing preferences: 1113 1. IPv6 1115 2. IPv4 (using IP in IP or UDP encapsulation if a NAT is detected) 1117 3. UDP encapsulation when no NAT is detected but IP in IP is not 1118 allowed by the local domain. 1120 5.4.2. Sending Binding Updates 1122 When sending an IPv6 packet containing a binding update while 1123 connected to an IPv4-only access network, mobile nodes MUST ensure 1124 the following: 1126 o The IPv6 packet is encapsulated in the vanilla UDP encapsulation 1127 format. 1129 o The source address in the IPv4 header is the mobile node's IPv4 1130 care-of address. 1132 o The destination address in the IPv4 header is the home agent's 1133 IPv4 address. 1135 o The source address in the IPv6 header is the mobile node's IPv6 1136 home address. 1138 o The IPv4 home address option MAY be included in the mobility 1139 header. This option contains the IPv4 home address. If the 1140 mobile node did not have a static home address it MAY include the 1141 unspecified IPv4 address, which acts as a request for a dynamic 1142 IPv4 home address. Alternatively, one or more IPv4 home address 1143 options may be included with requests for IPv4 prefixes (i.e., 1144 with the P flag set). 1146 o If the mobile node wishes to use UDP encapsulation only, it should 1147 set the F flag in the binding update message. 1149 o If the mobile node prefers to use the TLV-header format, it should 1150 set the T flag in the binding update. 1152 o The IPv6 packet MUST be authenticated as per [RFC3775], based on 1153 the mobile node's IPv6 home address. 1155 When sending a binding update from a visited network that supports 1156 IPv6, the mobile node MUST follow the rules specified in [RFC3775]. 1157 In addition, if the mobile node has an IPv4 home address or needs 1158 one, it MUST include the IPv4 home address option in the mobility 1159 header. If the mobile node already has a static IPv4 home address, 1160 this address MUST be included in the IPv4 home address option. 1161 Otherwise, if the mobile node needs a dynamic IPv4 address, it MUST 1162 include the IPv4 0.0.0.0 address in the IPv4 home address option. 1164 When the mobile node receives a binding acknowledgement from the home 1165 agent, it follows the rules in [RFC3775] and [RFC3963]. In addition, 1166 the following actions MUST be made: 1168 o If the status field indicated failure with error code 144, the 1169 mobile node MAY resend the binding update without setting the F 1170 flag. 1172 o If the mobility header includes an IPv4 address acknowledgement 1173 option indicating success, the mobile node should create two 1174 entries in its binding update list, one for the IPv6 home address 1175 and another for the IPv4 home address. 1177 o If the NAT detection option were present, the mobile node MUST 1178 tunnel future packets in UDP and IPv4. This MUST be indicated in 1179 the binding update list. 1181 o If no IPv4 address acknowledgement option were present, and an 1182 IPv4 home address option was present in the binding update, the 1183 mobile node MUST only create one binding update list entry for its 1184 IPv6 home address. The mobile node MAY include the IPv4 home 1185 address option in future binding updates. 1187 o If an IPv4 address acknowledgement option were present and it 1188 indicates failure for the IPv4 home address binding, the mobile 1189 node MUST NOT create an entry for that address in its binding 1190 update list. The mobile node MAY include the IPv4 home address 1191 option in future binding updates. 1193 o If the T flag was set in the binding update and the binding 1194 acknowledgement included the T flag set, the mobile node MUST use 1195 the TLV-header UDP encapsulation format. 1197 5.4.2.1. Removing Bindings 1199 Mobile nodes will remove bindings from the home agent's binding cache 1200 whenever they move to the home link, or simply when mobility support 1201 is not needed. 1203 De-registering the IPv6 home address is described in [RFC3775]. The 1204 same mechanism applies in this specification. Mobile nodes may 1205 remove the binding for the IPv4 home address only, by sending a 1206 binding update that does not include the IPv4 home address option. 1207 Upon receiving this binding update, the home agent will replace the 1208 existing cache entries with the content of the new message. This 1209 ensures that the IPv4 home address binding is removed, while 1210 maintining an IPv6 binding. 1212 Note that the mobile node cannot remove the IPv6 home address binding 1213 while maintaining an IPv4 home address binding. 1215 A binding update message with a lifetime of zero, will remove all 1216 bindings for the mobile node. 1218 5.4.3. Sending Packets from a Visited Network 1220 When the mobile node is located in an IPv6-enabled network it sends 1221 and receives IPv6 packets as described in [RFC3775]. IPv4 traffic is 1222 encapsulated in IPv6 packets to the home agent. 1224 When the mobile node is located in an IPv4 only network, it will send 1225 IPv6 packets to its home agent according to the following format: 1227 IPv4 header (src=V4CoA, dst=HA_V4ADDR) 1229 [UDP Header] 1231 [TLV Header] 1233 IPv6 header (src=V6HoA, dst=CN) 1234 Upper Layer protocols 1236 Here the UDP header is only used if a NAT has been detected between 1237 the mobile node and the home agent, or if the home agent forced UDP 1238 encapsulation. V4CoA is the IPv4 care-of address configured by the 1239 mobile node in the visited network. 1241 Similarly, IPv4 packets are sent according to the following format: 1243 IPv4 header (src=V4CoA, dst=HA_V4ADDR) 1245 [UDP Header] 1247 [TLV Header] 1249 IPv4 header (src=V4HoA, dst=V4CN) 1251 Upper Layer protocols 1253 Here the UDP header is only used if a NAT has been detected between 1254 the mobile node and the home agent, or if the home agent forced UDP 1255 encapsulation. 1257 If the mobile node and the home agent negotiated the use of the TLV- 1258 header UDP encapsulation format, then the TLV-header would be used 1259 after the UDP header. 1261 5.4.4. Movement Detection in IPv4-only Networks 1263 [RFC3775] describes movement detection mostly based on IPv6-specific 1264 triggers and Neighbor Discovery [RFC4861] information. These 1265 triggers are not available in an IPv4-only network. Hence, a mobile 1266 node located in an IPv4-only network SHOULD use [RFC4436] for 1267 guidance on movement detection mechanisms in IPv4-only networks. 1269 The mobile node detects that it's in an IPv4-only network when the 1270 IPv6 movement detection algorithm fails to configure an IPv6 address. 1272 5.5. Home agent operation 1274 In addition to the home agent specification in [RFC3775] and 1275 [RFC3963], the home agent needs to be able to process the IPv4 home 1276 address option and generate the IPv4 address acknowledgement option. 1277 Both options are included in the mobility header. Furthermore, the 1278 home agent MUST be able to detect the presence of a NAT device and 1279 indicate that in the NAT detection option included in the binding 1280 acknowledgement. 1282 A home agent must also act as a proxy for address resolution in IPv4 1283 for the registered IPv4 home addresses of mobile nodes it is serving. 1284 Moreover, the administrative domain of the home agent is responsible 1285 for advertising the routing information of registered IPv4 mobile 1286 network prefixes of the mobile nodes. 1288 In order to comply with this specification, the home agent MUST be 1289 able to find the IPv4 home address of a mobile node when given the 1290 IPv6 home address. That is, given an IPv6 home address, the home 1291 agent MUST store the corresponding IPv4 home address if a static one 1292 is present. If a dynamic address were requested by the mobile node, 1293 the home agent MUST store that address (associated with the IPv6 home 1294 address) after it's allocated to the mobile node. 1296 When the home agent receives a binding update encapsulated in UDP and 1297 containing the IPv4 home address option, it needs to follow all the 1298 steps in [RFC3775] and [RFC3963]. In addition, the following checks 1299 MUST be done: 1301 o If the IPv4 care-of address in the IPv4 CoA option is not the same 1302 as the IPv4 address in the source address in the IPv4 header then 1303 a NAT was in the path. This information should be flagged for the 1304 binding acknowledgement. 1306 o If the F flag in the binding update were set, the home agent needs 1307 to determine whether it accepts forcing UDP encapsulation. If it 1308 does not, the binding acknowledgement is sent with error code 144. 1309 UDP encapsulation MUST NOT be used when the mobile node is located 1310 in an IPv6-enabled link. 1312 o If the T flag was set in the binding update, the home agent needs 1313 to determine whether it can accept the TLV-header encapsulation 1314 format. If it does, it should set the T flag in the binding 1315 acknowledgement. Otherwise, the home agent MUST NOT set the T 1316 flag in the binding acknowledgement. 1318 o If the IPv4 home address option contains a valid unicast IPv4 1319 address, the home agent MUST check that this address is allocated 1320 to the mobile node that has the IPv6 home address included in the 1321 home address option. The same MUST be done for an IPv4 prefix. 1323 o If the IPv4 home address option contained the unspecified IPv4 1324 address, the home agent SHOULD dynamically allocate an IPv4 home 1325 address to the mobile node. If none is available, the home agent 1326 MUST return error code 132 in the status field of the IPv4 address 1327 acknowledgement option. If a prefix were requested, the home 1328 agent SHOULD allocate a prefix with the requested length; if 1329 prefix allocation (of any length) was not possible, the home agent 1330 MUST indicate failure of the operation with the appropriate error 1331 code. 1333 o If the binding update is accepted for the IPv4 home address, the 1334 home agent creates a binding cache entry for the IPv4 home 1335 address/prefix. The home agent MUST include an IPv4 1336 acknowledgement option in the mobility header containing the 1337 binding acknowledgement. 1339 o If the binding update is accepted for both IPv4 and IPv6 home 1340 addresses, the home agent creates separate binding cache entries, 1341 one for each home address. The care-of address is the one 1342 included in the binding update. If the care-of address is an IPv4 1343 address, the home agent MUST setup a tunnel to the IPv4 care-of 1344 address of the mobile node. 1346 When sending a binding acknowledgement to the mobile node, the home 1347 agent constructs the message according to [RFC3775] and [RFC3963]. 1348 Note that the routing header MUST always contain the IPv6 home 1349 address as specified in [RFC3775]. 1351 If the care-of address of the mobile node were an IPv4 address, the 1352 home agent includes the mobile node's IPv6 home address in the 1353 destination address field in the IPv6 header. If a NAT were 1354 detected, the home agent MUST then encapsulate the packet in UDP and 1355 an IPv4 header. The source address is set to the home agent's IPv4 1356 address and the destination address is set to the address received in 1357 the source address of the IPv4 header encapsulating the binding 1358 update. 1360 After creating a binding cache entry for the mobile node's home 1361 addresses, all packets sent to the mobile node's home addresses are 1362 tunneled by the home agent to the mobile node's care-of address. If 1363 a NAT were detected, packets are encapsulated in UDP and IPv4. 1364 Otherwise, if the care-of address is an IPv4 address, and no NAT were 1365 detected, packets are encapsulated in an IPv4 header unless UDP 1366 encapsulation is forced by the home agent. 1368 5.5.1. Sending Packets to the Mobile Node 1370 The home agent follows the rules specified in [RFC3775] for sending 1371 IPv6 packets to mobile nodes located in IPv6 networks. When sending 1372 IPv4 packets to mobile nodes in an IPv6 network, the home agent must 1373 encapsulate the IPv4 packets in IPv6. 1375 When sending IPv6 packets to a mobile node located in an IPv4 1376 network, the home agent must follow the format negotiated in the 1377 binding update/acknowledgement exchange. In the absence of a 1378 negotiated format, the default format that MUST be supported by all 1379 implementations is: 1381 IPv4 header (src= HA_V4ADDR, dst= V4ADDR) 1383 UDP Header 1385 IPv6 header (src=CN, dst= V6HoA) 1387 Upper layer protocols 1389 Where the UDP header is only included if a NAT were detected between 1390 the mobile node and the home agent, or if the home agent forced UDP 1391 encapsulation. V4ADDR is the IPv4 address received in the source 1392 address field of the IPv4 packet containing the binding update. 1394 When sending IPv4 packets to a mobile node located in an IPv4 1395 network, the home agent must follow the format negotiated in the 1396 binding update/acknowledgement exchange. In the absence of a 1397 negotiated format, the default format that MUST be supported by all 1398 implementations is: 1400 IPv4 header (src= HA_V4ADDR, dst= V4ADDR) 1402 [UDP Header] 1404 IPv4 header (src=V4CN, dst= V4HoA) 1406 Upper layer protocols 1408 Where the UDP header is only included if a NAT were detected between 1409 the mobile node and home agent, or if the home agent forced UDP 1410 encapsulation. 1412 5.6. Correspondent Node Operation 1414 This specification has no impact on IPv4 or IPv6 correspondent nodes. 1416 6. Security Considerations 1418 This specification allows a mobile node to send one binding update 1419 for its IPv6 and IPv4 home addresses. This is a slight deviation 1420 from [RFC3775] which requires one binding update per home address. 1421 However, like [RFC3775], the IPsec security association needed to 1422 authenticate the binding update is still based on the mobile node's 1423 IPv6 home address. Therefore, in order to authorize the mobile 1424 node's IPv4 home address binding, the home agent MUST store the IPv4 1425 address corresponding to the IPv6 address that is allocated to a 1426 mobile node. Therefore, it is sufficient for the home agent to know 1427 that the IPsec verification for the packet containing the binding 1428 update was valid provided that it knows which IPv4 home address is 1429 associated with which IPv6 home address. Hence, the security of the 1430 IPv4 home address binding is the same as the IPv6 binding. 1432 In effect, associating the mobile node's IPv4 home address with its 1433 IPv6 home address moves the authorization of the binding update for 1434 the IPv4 address to the Mobile IPv6 implementation, which infers it 1435 from the fact that the mobile node has an IPv6 home address and the 1436 right credentials for sending an authentic binding update for the 1437 IPv6 address. 1439 This specification requires the use of IKEv2 as the default mechanism 1440 for dynamic keying. 1442 In cases where this specification is used for NAT traversal, it is 1443 important to note that it has the same vulnerabilities associated 1444 with [RFC3519]. An attacker is able to hijack the mobile node's 1445 session with the home agent if it can modify the contents of the 1446 outer IPv4 header. The contents of the header are not authenticated 1447 and there is no way for the home agent to verify their validity. 1448 Hence, a man in the middle attack where a change in the contents of 1449 the IPv4 header can cause a legitimate mobile node's traffic to be 1450 diverted to an illegitimate receiver independently of the 1451 authenticity of the binding update message. 1453 In this specification, the binding update message MUST be protected 1454 using ESP transport mode. When the mobile node is located in an 1455 IPv4-only network, the binding update message is encapsulated in UDP 1456 as described earlier. However, UDP SHOULD NOT be used to encapsulate 1457 the binding update message when the mobile node is located in an 1458 IPv6-enabled network. If protection of payload traffic is needed 1459 when the mobile node is located in an IPv4-only network, 1460 encapsulation is done using tunnel mode ESP over port 4500 as 1461 described in [RFC3948]. During the IKE negotiation with the home 1462 agent, if the mobile node and home agent support the use of port 1463 4500, the mobile node MUST establish the security association over 1464 port 4500, regardless of the presence of a NAT. This is done to 1465 avoid the switching between ports 500 and 4500 and the potential 1466 traffic disruption resulting from this switch. 1468 Handovers within private IPv4 networks or from IPv6 to IPv4 networks 1469 will have impacts on the security association between the mobile node 1470 and the home agent. The following section presents the expected 1471 behaviour of the mobile node and home agent in those situations. The 1472 details of the IKE negotiations and messages are illustrated in 1473 Section 6.2 1475 6.1. Handover Interactions for IPsec and IKE 1477 After the mobile node detects movement it configures a new care-of 1478 address. If the mobile node is in an IPv4-only network, it removes 1479 binding update list entries for correspondent nodes since route 1480 optimisation cannot be supported. This may cause inbound packet 1481 losses as remote correspondent nodes are unaware of such movement. 1482 To avoid confusion in the correspondent node, the mobile node SHOULD 1483 deregister its binding with each correspondent node by sending a 1484 deregistration binding update. The deregistration binding update 1485 message is tunnelled to the home agent and onto the correspondent 1486 node. This is done after the mobile node updates the home agent with 1487 its new location as discussed below. 1489 The mobile node sends the binding update message to the home agent. 1490 If the mobile node is in an IPv6-enabled network, the binding update 1491 is sent without IPv4/UDP encapsulation. If the mobile node is in an 1492 IPv4-only network, then after IPsec processing of the BU message, it 1493 encapsulates the BU in UDP/IPv4 as discussed in sections 5.2 and 5.4. 1494 In order to be able to send the binding update while in an IPv4-only 1495 network, the mobile node needs to use the new IPv4 care-of address in 1496 the outer header, which is different from the care-of address used in 1497 the existing tunnel. This should be done without permanently 1498 updating the tunnel within the mobile node's implementation in order 1499 to allow the mobile node to receive packets on the old care-of 1500 address until the binding acknowledgement is received. The method 1501 used to achieve this effect is implementation dependent and is 1502 outside the scope of this specification. This implies that the IP 1503 forwarding function (which selects the interface or tunnel through 1504 which a packet is sent) is not based solely on the destination 1505 address: some IPv6 packets destined to the home agent are sent via 1506 the existing tunnel, while BUs are sent using the new care-of 1507 address. Since BUs are protected by IPsec, the forwarding function 1508 cannot necessarily determine the correct treatment from the packet 1509 headers. Thus, the DSMIPv6 implementation has to attach additional 1510 information to BUs, and this information has to be preserved after 1511 IPsec processing and made available to the forwarding function, or 1512 additional DSMIP processing added to the forwarding function. 1513 Depending on the mobile node's implementation, meeting this 1514 requirement may require changes to the IPsec implementation. 1516 Upon receiving the binding update message encapsulated in UDP/IPv4, 1517 the home agent processes it as follows. In order to allow the 1518 DSMIPv6 implementation in the home agent to detect the presence of a 1519 NAT on the path to the mobile node, it needs to compare the outer 1520 IPv4 source address with the IPv4 address in the IPv4 care-of address 1521 option. This implies that the information in the outer header will 1522 be preserved after IPsec processing and made available to the DSMIPv6 1523 implementation in the home agent. Depending on the home agent's 1524 implementation, meeting this requirement may require changes to the 1525 IPsec implementation. 1527 The home agent updates its tunnel mode security association to 1528 include the mobile node's care-of address as the remote tunnel header 1529 address, and 4500 as the port number. The IPv4 address and port 1530 number are likely to be wrong; the mobile node provides the correct 1531 information in a separate exchange as described below. When the 1532 mobile node is located in a private IPv4 network (which is detected 1533 as described above), the new address and port number are allocated by 1534 the NAT. The home agent will also enable or disable UDP 1535 encapsulation for outgoing ESP packets for the purpose of NAT 1536 traversal. 1538 If the Key Management Mobility Capability (K) bit was set in the 1539 binding update, and the home agent supports this feature, the home 1540 agent updates its IKE security associations to include the mobile 1541 node's care-of address as the peer address and 4500 as the port 1542 number. The home agent may also need to change NAT traversal fields 1543 in the IKE_SA to enable the dynamic update of the IP address and port 1544 number based on the reception of authenticated IKE messages, or 1545 authenticated packets using tunnel mode ESP. The dynamic updates are 1546 described in section 2.23 of RFC 4306. As described above, when the 1547 mobile node is located in a private IPv4 network, the address and 1548 port number used for IPsec and IKE traffic is not yet known by the 1549 home agent at this point. 1551 The mobile node updates the IKE SA in one of two ways. If the K flag 1552 was set in the binding acknowledgement message, the mobile node 1553 SHOULD send an empty informational message, which results in the IKE 1554 module in the home agent to dynamically update the SA information. 1555 The IKE implementation in the home agent is REQUIRED to support this 1556 feature. Alternatively, the IKE SA should be re-negotiated. Note 1557 that updating the IKE SA MUST take place after the mobile node has 1558 sent the binding update and received the acknowledgement from the 1559 home agent. 1561 It is important to note that the mobile node's IPv4 care-of address 1562 seen by the DSMIPv6 module in the home agent upon receiving the 1563 binding update may differ from the IPv4 care-of address seen by the 1564 IKE module and the care-of address used for forwarding IPsec tunnel 1565 mode traffic. Hence, it is probable that different modules in the 1566 home agent will have a different care-of address that should be used 1567 for encapsulating traffic to the mobile node. 1569 After successfully processing the binding update, the home agent 1570 sends the binding acknowledgement to the mobile node's care-of 1571 address as received in the outer header of the packet containing the 1572 binding update. Note that if the BU was rejected, the BAck is sent 1573 to the same address where the BU was received from. This may require 1574 special treatment in IP forwarding and/or IPsec processing which 1575 resembles sending of BUs in the mobile node (described above). 1577 Upon receiving the binding acknowledgement, the mobile node updates 1578 its local tunnel mode Security Association information to include the 1579 tunnel header IP source address, which is the mobile node's address 1580 and the tunnel header IP destination, which is the home agent's 1581 address. The mobile node may also need to enable or disable UDP 1582 encapsulation for outgoing ESP packets for the purpose of NAT 1583 traversal and the sending of keep alives. 1585 The mobile node MAY use [RFC4555] to update its IKE SA with the home 1586 agent. Using MOBIKE requires negotiating this capability with the 1587 home agent when establishing the SA. In this case, the mobile node 1588 and the home agent MUST NOT update their IPsec SAs locally as this 1589 step is performed by MOBIKE. Furthermore, the use of MOBIKE allows 1590 the mobile node to update the SA independently of the binding update 1591 exchange. Hence, there is no need for the mobile node to wait for a 1592 binding acknowledgement before performing MOBIKE. The use of MOBIKE 1593 is OPTIONAL in this specification. 1595 6.2. IKE negotiation messages between the mobile node and Home Agent 1597 This specification defines a number of possible data encapsulation 1598 formats depending on the mobile node's connectivity to the visited 1599 network. When connected to an IPv6-enabled network, the tunnelling 1600 formats are clear. However, when connected to an IPv4-only network, 1601 care should be taken when negotiating the IKE association and the 1602 consequential tunnelling formats used for secure and insecure 1603 traffic. This section illustrates the IKE message exchange between 1604 the mobile node and home agent when the mobile node is located in an 1605 IPv4-only network. Two different IKE negotiations are considered: 1607 o IKEv2 operation for securing DSMIPv6 Signaling. 1609 o IKEv2 operation for securing Data over IPv4 1611 6.2.1. IKEv2 Operation for Securing DSMIPv6 Signaling 1613 A mobile node connected to an IPv4-only network SHOULD follow the 1614 procedures described below in order to establish an SA for the 1615 protection of binding update and binding acknowledgement messages. 1617 Mobile Node Home Agent 1618 ----------- ---------- 1619 IPv4(source_addr=V4ADDR, dest_addr=HAADDR) 1620 UDP (500, 500) HDR, SAi1, KEi, Ni 1621 NAT-D, NAT-D --> 1623 <- IPv4(source_addr=HAADDR, dest_addr=V4ADDR) 1624 UDP(500,X) HDR, SAr1, KEr, Nr, [CERTREQ] 1625 NAT-D, NAT-D 1627 IPv4(source_addr=V4ADDR, dest_addr=HAADDR) 1628 UDP (4500,4500) HDR, SK 1629 {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, N(USE_TRANSPORT_MODE), 1630 SAi2, TSi, TSr} 1631 --> 1633 <-- IPv4(source_addr=HAADDR, dest_addr=V4ADDR) 1634 UDP (4500,Y) HDR, SK 1635 {IDr, [CERT,] AUTH, N(USE_TRANSPORT_MODE), 1636 SAr2, TSi, TSr} 1638 The corresponding SPD entries are shown below. 1640 Mobile node SPD-S: 1642 IF local_address = home_address_1 & 1644 remote_address = home_agent_1 & 1646 proto = MH & local_mh_type = BU & remote_mh_type = BAck Then use 1647 SA ESP transport mode 1649 Initiate using IDi = user_1 to address home_agent_1 1651 Home Agent SPD-S: 1653 IF local_address = home_agent_1 & 1655 remote_address = home_address_1 & 1657 proto = MH & local_mh_type = BAck & remote_mh_type = BU Then use 1658 SA ESP transport mode 1660 where home_address_1 is the mobile node's registered IPv6 home 1661 address and home_agent_1 is the IP address of the home agent 1663 The above should result in BU/BA messages with the following BU 1664 received by the home agent. 1666 IPv4 header (src=V4ADDR, dst=HA_V4ADDR) 1668 UDP header (sport=Z, dport=DSMIPv6) 1670 IPv6 header (src=V6HOA, dst=HAADDR) 1672 ESP Header in Transport Mode 1674 Mobility header 1676 BU [IPv4 HAO] 1678 IPv4 CoA option 1680 (+ other as needed) 1682 At the home agent, following UDP de-capsulation, the binding update 1683 is delivered to the IPsec module as shown below: 1685 IPv6 header (src=V6HOA, dst=HAADDR) 1687 ESP Header in Transport Mode 1689 Mobility header 1691 BU [IPv4 HAO] 1693 IPv4 CoA option 1695 (+other as needed) 1697 In addition, V4ADDR and the sport (Z) need to be passed with the 1698 packet to ensure correct processing. 1700 Following IPsec processing, the binding update is delivered to the 1701 DSMIPv6 home agent module as follows: 1703 IPv6 header (src=V6HOA, dst=HAADDR) 1705 Mobility Header 1707 BU [IPv4 HAO] 1709 IPv4 CoA option 1711 (+other as needed) 1713 In addition, V4ADDR and the sport (Z) need to be passed with the 1714 packet to ensure correct processing. 1716 The binding acknowledgement sent by the home agent module to the 1717 IPsec module is as follows: 1719 IPv6 header (src=HAADDR, dst=V6HOA) 1721 Mobility Header 1723 BA ([IPv4 ACK], NAT DET) 1725 (+ other as needed) 1727 In addition, V4ADDR, the sport from the BU (Z), and an indication 1728 that vanilla UDP encapsulation must be used, need to be passed with 1729 the packet to ensure correct processing. 1731 The binding acknowledgement sent by the home agent to the mobile node 1732 is as follows: 1734 IPv4 header (src= HA_V4ADDR, dst=V4ADDR) 1736 UDP Header (sport=DSMIPv6, dport=Z) 1738 IPv6 header (src=HAADDR, dst=V6HOA) 1740 ESP Header in Transport Mode 1742 Mobility Header 1744 BA ([IPv4 ACK], NAT DET) 1746 6.2.2. IKEv2 Operation for Securing Data over IPv4 1748 To secure data traffic when the mobile node is located in an IPv4- 1749 only network, the mobile node MUST establish a child_SA for that 1750 purpose. The procedure is as follows: 1752 Mobile Node Home Agent 1753 ----------- ---------- 1754 IPv4(source_addr=V4ADDR, dest_addr=HAADDR) 1755 UDP (4500,4500) < non-ESP Marker > HDR, SK 1756 {[N], SA, Ni, [KEi], TSi, TSr} --> 1758 <--IPv4(source_addr=HAADDR, dest_addr=V4ADDR) 1759 UDP (4500,Y) < non-ESP Marker > HDR, SK 1760 SA, Nr, [KEr], TSi, TSr} 1762 If no NAT is detected, the encapsulation used will be: 1764 IPv4 (source_addr=v4CoA, dest_addr=HAAddr) 1766 ESP 1768 IP (source_addr=HoA, set_addr=CNAddr) 1770 Upper_layer_HDR 1772 where IP=IPv4 or IPv6 and HoA=v4HoA or v6HoA 1774 If a NAT were detected, the encapsulation used will be: 1776 IPv4 (source_addr=v4Addr, dest_addr=HAAddr) 1778 UDP (sport=Y, dport=4500) 1780 ESP 1782 IP (source_addr=HoA, set_addr=CNAddr) 1784 Upper_layer_HDR 1786 Where v4CoA may be the external IPv4 address of the NAT, IP is either 1787 an IPv4 or IPv6 header and HoA is either the IPv4 or the IPv6 HoA. 1788 The above format shows the packet as seen by the home agent. 1790 The SPD, whether a NAT were detected or not, is set as follows. Note 1791 that this rule is designed to match all data from the MN to nodes 1792 other than the home agent. This is done so that this rule does not 1793 overlap with the earlier rule securing BU/BA signaling between the MN 1794 and the HA. 1796 Mobile Node SPD-S: 1798 IF local_address = home_address & 1800 remote_address != home_agent & 1802 proto=any, then use SA ESP tunnel mode 1804 Initiate using IDi = user_1 to address home_agent_1 1806 home agent SPD-S: 1808 IF local_address != home_agent & 1810 remote_address = home_address & 1812 proto=any, then use SA ESP tunnel mode 1814 Where home_address is the MN's registered IPv6 or IPv4 home address 1815 and home_agent is the IPv6 or the IPv4 address of the home agent. 1817 7. Protocol Constants 1819 NATKATIMEOUT 110 seconds 1821 8. Acknowledgements 1823 Thanks to the following members (in alphabetical order) of the MIP6 1824 and NEMO Working Groups for their contributions, discussion, and 1825 review: Jari Arkko, Sri Gundavelli, Wassim Haddad, Conny Larsson, 1826 Acee Lindem, Ahmad Muhanna, Vidya Narayanan, Karen Nielsen and 1827 Keiichi Shima. Thanks to Karen Nielsen, Pasi Eronen and Christian 1828 Kaas-Petersen for raising the issue of IKEv2 interactions and 1829 proposing the solution included in this document. 1831 9. IANA Considerations 1833 The specification requires the following allocations from IANA: 1835 A UDP port is needed for the NAT traversal mechanism described in 1836 section 4.1. 1838 The IPv4 home address option described in section 3.1.1 requires 1839 an option type. This option is included in the Mobility header 1840 described in [RFC3775]. 1842 The IPv4 address acknowledgement option described in section 3.2.1 1843 requires a new option type. This option is included in the 1844 Mobility header described in [RFC3775]. 1846 The NAT detection option described in section 3.2.2 requires a new 1847 option type. This option is included in the Mobility header 1848 described in [RFC3775]. 1850 The IPv4 Care-of address option described in section 3.1.2 1851 requires a new option type allocation [RFC3775]. 1853 This specification introduces a new TLV-header to be used with UDP 1854 encapsulation. The Types of the TLV-header should be allocated by 1855 IANA under a new registry: "DSMIPv6 TLV-header Types". 1857 The Status field in the IPv4 home address option should be allocated 1858 by IANA under the new registry: "DSMIPv6 IPv4 home address option 1859 status codes". 1861 The TLV-header types and status field values are allocated using the 1862 following procedure: 1864 1. New TLV-header types and Status field values are allocated 1865 through IETF review. This is for all RFC types including 1866 standards track, informational, and experimental status that 1867 originate from the IETF and have been approved by the IESG for 1868 publication. 1870 2. Requests for new option type value assignments from outside the 1871 IETF are only made through the publication of an IETF document, 1872 per 1) above. Note also that documents published as "RFC Editor 1873 contributions" [RFC4844] are not considered to be IETF documents. 1875 10. References 1877 10.1. Normative References 1879 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1880 Requirement Levels", BCP 14, RFC 2119, March 1997. 1882 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1883 IPv6 Specification", RFC 2473, December 1998. 1885 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1886 in IPv6", RFC 3775, June 2004. 1888 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1889 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1890 RFC 3948, January 2005. 1892 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 1893 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 1894 RFC 3963, January 2005. 1896 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1897 RFC 4306, December 2005. 1899 [RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting 1900 Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006. 1902 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1903 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1904 September 2007. 1906 [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 1907 IKEv2 and the Revised IPsec Architecture", RFC 4877, 1908 April 2007. 1910 10.2. Informative 1912 [I-D.ietf-mip6-bootstrapping-integrated-dhc] 1913 Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the 1914 Integrated Scenario", 1915 draft-ietf-mip6-bootstrapping-integrated-dhc-06 (work in 1916 progress), April 2008. 1918 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 1919 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 1920 March 2000. 1922 [RFC2983] Black, D., "Differentiated Services and Tunnels", 1923 RFC 2983, October 2000. 1925 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1926 of Explicit Congestion Notification (ECN) to IP", 1927 RFC 3168, September 2001. 1929 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 1930 August 2002. 1932 [RFC3519] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of 1933 Network Address Translation (NAT) Devices", RFC 3519, 1934 April 2003. 1936 [RFC3978] Bradner, S., "IETF Rights in Contributions", RFC 3978, 1937 March 2005. 1939 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1940 for IPv6 Hosts and Routers", RFC 4213, October 2005. 1942 [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the- 1943 Network Tunneling", RFC 4459, April 2006. 1945 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 1946 (MOBIKE)", RFC 4555, June 2006. 1948 [RFC4844] Daigle, L. and Internet Architecture Board, "The RFC 1949 Series and RFC Editor", RFC 4844, July 2007. 1951 [RFC4977] Tsirtsis, G. and H. Soliman, "Problem Statement: Dual 1952 Stack Mobility", RFC 4977, August 2007. 1954 [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 1955 Bootstrapping in Split Scenario", RFC 5026, October 2007. 1957 [RFC5380] Soliman, H., Castelluccia, C., ElMalki, K., and L. 1958 Bellier, "Hierarchical Mobile IPv6 (HMIPv6) Mobility 1959 Management", RFC 5380, October 2008. 1961 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 1962 for Application Designers", BCP 145, RFC 5405, 1963 November 2008. 1965 Appendix A. Contributors 1967 This document reflects discussions and contributions from several 1968 people including (in alphabetical order): 1970 Vijay Devarapalli: vijay.devarapalli@azairenet.com 1972 James Kempf: kempf@docomolabs-usa.com 1974 Henrik Levkowetz: henrik@levkowetz.com 1976 Pascal Thubert: pthubert@cisco.com 1978 George Tsirtsis: G.Tsirtsis@Qualcomm.com 1980 Wakikawa Ryuji: ryuji@sfc.wide.ad.jp 1982 Author's Address 1984 Hesham Soliman (editor) 1985 Elevate Technologies 1987 Email: hesham@elevatemobile.com 1989 Full Copyright Statement 1991 Copyright (C) The IETF Trust (2008). 1993 This document is subject to the rights, licenses and restrictions 1994 contained in BCP 78, and except as set forth therein, the authors 1995 retain all their rights. 1997 This document and the information contained herein are provided on an 1998 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1999 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2000 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2001 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2002 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2003 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2005 Intellectual Property 2007 The IETF takes no position regarding the validity or scope of any 2008 Intellectual Property Rights or other rights that might be claimed to 2009 pertain to the implementation or use of the technology described in 2010 this document or the extent to which any license under such rights 2011 might or might not be available; nor does it represent that it has 2012 made any independent effort to identify any such rights. Information 2013 on the procedures with respect to rights in RFC documents can be 2014 found in BCP 78 and BCP 79. 2016 Copies of IPR disclosures made to the IETF Secretariat and any 2017 assurances of licenses to be made available, or the result of an 2018 attempt made to obtain a general license or permission for the use of 2019 such proprietary rights by implementers or users of this 2020 specification can be obtained from the IETF on-line IPR repository at 2021 http://www.ietf.org/ipr. 2023 The IETF invites any interested party to bring to its attention any 2024 copyrights, patents or patent applications, or other proprietary 2025 rights that may cover technology that may be required to implement 2026 this standard. Please address the information to the IETF at 2027 ietf-ipr@ietf.org.