idnits 2.17.1 draft-ietf-mext-nemo-v4traversal-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1872. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1883. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1890. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1896. 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 (July 14, 2008) is 5736 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 1596, but not defined == Missing Reference: 'IPv4 ACK' is mentioned on line 1633, but not defined == Missing Reference: 'CERTREQ' is mentioned on line 1514, but not defined == Missing Reference: 'N' is mentioned on line 1645, but not defined == Missing Reference: 'KEi' is mentioned on line 1645, but not defined == Missing Reference: 'KEr' is mentioned on line 1649, but not defined ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) -- 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 4140 (Obsoleted by RFC 5380) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 10 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 July 14, 2008 5 Expires: January 15, 2009 7 Mobile IPv6 Support for Dual Stack Hosts and Routers 8 draft-ietf-mext-nemo-v4traversal-05.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 January 15, 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 . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . 10 55 3.3.1. Foreign Network Supports IPv6 . . . . . . . . . . . . 10 56 3.3.2. Foreign Network Supports IPv4 Only . . . . . . . . . . 11 57 3.4. Route Optimization . . . . . . . . . . . . . . . . . . . . 13 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 . . . . . . . 22 71 5.2. NAT Detection . . . . . . . . . . . . . . . . . . . . . . 23 72 5.3. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . . 25 73 5.4. Mobile Node Operation . . . . . . . . . . . . . . . . . . 25 74 5.4.1. Sending Packets from a Visited Network . . . . . . . . 27 75 5.4.2. Movement Detection in IPv4-only Networks . . . . . . . 28 76 5.5. Home agent operation . . . . . . . . . . . . . . . . . . . 28 77 5.5.1. Sending Packets to the Mobile Node . . . . . . . . . . 30 78 5.6. Correspondent Node Operation . . . . . . . . . . . . . . . 31 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 32 80 6.1. Handover Interactions for IPsec and IKE . . . . . . . . . 33 81 6.2. IKE negotiation messages between the mobile node and 82 Home Agent . . . . . . . . . . . . . . . . . . . . . . . . 35 83 6.2.1. IKEv2 Operation for Securing DSMIPv6 Signaling . . . . 36 84 6.2.2. IKEv2 Operation for Securing Data over IPv4 . . . . . 38 85 7. Protocol Constants . . . . . . . . . . . . . . . . . . . . . . 41 86 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42 87 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 88 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 89 10.1. Normative References . . . . . . . . . . . . . . . . . . . 44 90 10.2. Informative . . . . . . . . . . . . . . . . . . . . . . . 44 91 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 46 92 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 47 93 Intellectual Property and Copyright Statements . . . . . . . . . . 48 95 1. Requirements notation 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC2119]. 101 2. Introduction 103 Mobile IPv6 [RFC3775] and [RFC3963] allow mobile nodes to move within 104 the Internet while maintaining reachability and ongoing sessions, 105 using an IPv6 home address or prefix. However, since IPv6 is not 106 widely deployed, it is unlikely that mobile nodes will use IPv6 107 addresses only for their connections. It is reasonable to assume 108 that mobile nodes will, for a long time, need an IPv4 home address 109 that can be used by upper layers. It is also reasonable to assume 110 that mobile nodes will move to networks that might not support IPv6 111 and would therefore need the capability to support an IPv4 Care-of 112 Address. Hence, this specification extends Mobile IPv6 capabilities 113 to allow dual stack mobile nodes to request that their home agent 114 (also dual stacked) tunnel IPv4/IPv6 packets addressed to their home 115 addresses, as well as IPv4/IPv6 care-of address(es). 117 Using this specification, mobile nodes would only need Mobile IPv6 118 and [RFC3963] to manage mobility while moving within the Internet; 119 hence eliminating the need to run two mobility management protocols 120 simultaneously. This specification provides the extensions needed in 121 order to allow IPv6 mobility only to be used by dual stack mobile 122 nodes. 124 This specification will also consider cases where a mobile node moves 125 into a private IPv4 network and gets configured with a private IPv4 126 Care-of Address. In these scenarios, the mobile node needs to be 127 able to traverse the IPv4 NAT in order to communicate with the home 128 agent. IPv4 NAT traversal for Mobile IPv6 is presented in this 129 specification. 131 In this specification, the term mobile node refers to both a mobile 132 host and mobile router unless the discussion is specific to either 133 hosts or routers. Similarly, we use the term home address to reflect 134 an address/prefix format. 136 In this specification, extensions are defined for the binding update 137 and binding acknowledgement. It should be noted that all these 138 extensions apply to cases where the mobile node communicates with a 139 Mobility Anchor Point (MAP) as defined in [RFC4140]. The 140 requirements on the MAP are identical to those stated for the home 141 agent, although it is unlikely that NAT traversal would be needed 142 with a MAP as it is expected to be in the same address domain. 144 2.1. Motivation for Using Mobile IPv6 Only 146 IPv6 offers a number of improvements over today's IPv4, primarily due 147 to its large address space. Mobile IPv6 offers a number of 148 improvements over Mobile IPv4 [RFC3344], mainly due to capabilities 149 inherited from IPv6. For instance, route optimization and dynamic 150 home agent discovery can only be achieved with Mobile IPv6. 152 One of the advantages of the large address space provided by IPv6 is 153 that it allows mobile nodes to obtain a globally unique care-of 154 address wherever they are. Hence, there is no need for Network 155 Address Translator (NAT) traversal techniques designed for Mobile 156 IPv4. This allows Mobile IPv6 to be a significantly simpler and more 157 bandwidth efficient mobility management protocol. At the same time, 158 during the transition towards IPv6, NAT traversal for existing 159 private IPv4 networks needs to be considered. This specification 160 introduces NAT traversal for this purpose. 162 The above benefits make the case for using Mobile IPv6 only for dual 163 stack mobile nodes in order to allow for a long lasting mobility 164 solution and minimize the need to changing the mobility stack due to 165 the introduction of IPv6 within a deployed network. 167 2.2. Scenarios Considered by This Specification 169 There are several scenarios that illustrate potential 170 incompatibilities for mobile nodes using Mobile IPv6. Some of the 171 problems associated with mobility and transition issues were 172 presented in [RFC4977]. This specification considers the scenarios 173 that address all the problems discussed in [RFC4977]. The scenarios 174 considered in this specification are listed below. 176 All of the following scenarios assume that both the mobile node and 177 the home agent are IPv4 and IPv6-enabled and that only Mobile IPv6 is 178 used between the mobile node and the home agent. We also assume that 179 the home agent is always reachable through a globally unique IPv4 180 address. Finally, it's important to note that the following 181 scenarios are not mutually exclusive. 183 Scenario 1: IPv4-only foreign network 185 In this scenario, a mobile node is connected to an IPv4-only foreign 186 network. The mobile node can only configure an IPv4 Care-of Address. 188 Scenario 2: Mobile node behind a NAT 190 In this scenario, the mobile node is in a private IPv4 foreign 191 network that has a NAT device connecting it to the Internet. If the 192 home agent is located outside the NAT device, the mobile node will 193 need a NAT traversal mechanism to communicate with the home agent. 195 Scenario 3: Home Agent behind a NAT 196 In this scenario, the communication between the mobile node and the 197 home agent is further complicated by the fact that the home agent is 198 located within a private IPv4 network. However, in this scenario, we 199 assume that the home agent is allocated a globally unique IPv4 200 address. The address might not be physically configured on the home 201 agent interface. Instead, it is associated with the home agent on 202 the NAT device, which allows the home agent to be reachable through 203 address or port mapping. 205 Scenario 4: Use Of IPv4-only applications 207 In this scenario, the mobile node may be located in an IPv4, IPv6 or 208 a dual network. However, the mobile node might be communicating with 209 an IPv4-only node. In this case, the mobile node would need a stable 210 IPv4 address for its application. The alternative to using an IPv4 211 address is the use of protocol translators; however, end-to-end 212 communication with IPv4 is preferred to the use of protocol 213 translators. 215 The mobile node may also be communicating with an IPv4-only 216 application that requires an IPv4 address. 218 The cases above illustrate the need for the allocation of a stable 219 IPv4 home address to the mobile node. This is done using an IPv4 220 home address. Since running Mobile IPv4 and Mobile IPv6 221 simultaneously is problematic (as illustrated in [RFC4977]), this 222 scenario adds a requirement on Mobile IPv6 to support IPv4 home 223 addresses. 225 3. Solution Overview 227 In order to allow Mobile IPv6 to be used by dual stack mobile nodes, 228 the following needs to be done: 230 o Mobile nodes should be able to use an IPv4 and IPv6 home or 231 care-of address simultaneously and update their home agents 232 accordingly. 234 o Mobile nodes need to be able to know the IPv4 address of the home 235 agent as well as its IPv6 address. There is no need for IPv4 236 prefix discovery however. 238 o Mobile nodes need to be able to detect the presence of a NAT 239 device and traverse it in order to communicate with the home 240 agent. 242 This section presents an overview of the extensions required in order 243 to allow mobile nodes to use Mobile IPv6 only for IP mobility 244 management 246 3.1. Home Agent Address Discovery 248 Dynamic home agent Address Discovery (DHAAD) was defined in [RFC3775] 249 to allow mobile nodes to discover their home agents by appending a 250 well-known anycast interface identifier to their home link's prefix. 251 However, this mechanism is based on IPv6-anycast routing. If a 252 mobile node is located in an IPv4-only foreign network, it cannot 253 rely on native IPv6 routing. In this scenario, the solution for 254 discovering the home agent's IPv4 address is through the Domain Name 255 System (DNS). If the MN is attached to an IPv6-only or dual stack 256 network, it may also use procedures defined in 257 [I-D.ietf-mip6-bootstrapping-integrated-dhc] to discover home agent 258 information. Note that the use of 259 [I-D.ietf-mip6-bootstrapping-integrated-dhc] cannot give the mobile 260 node information that allows it to continue to communicate with the 261 home agent if, for example, the mobile node moved from an IPv6- 262 enabled network to an IPv4-only network. In this scenario, the 263 mobile node would need to discover the IPv4 address of its home agent 264 through the DNS. 266 For DNS lookup by name, the mobile node should be configured with the 267 name of the home agent. When the mobile node needs to discover a 268 home agent, it sends a DNS request with QNAME set to the configured 269 name. An example is "ha1.example.com". If a home agent has an IPv4 270 and IPv6 address, the corresponding DNS record should be configured 271 with both 'AAAA' and 'A' records. Accordingly, the DNS reply will 272 contain 'AAAA' and 'A' records. 274 For DNS lookup by service, the SRV record defined in [RFC5026] is 275 reused. For instance, if the service name is "mip6" and the protocol 276 name is "ipv6" in the SRV record, the mobile node SHOULD send a DNS 277 request with the QNAME set to "_mip6._ipv6.example.com". The 278 response should contain the home agent's FQDN(s) and may include the 279 corresponding 'AAAA' and 'A' records as well. 281 If multiple home agents reside on the home link, each configured with 282 a public IPv4 address, then the operation above applies. In case the 283 home agents are behind a NAT box, there are two options, 1) configure 284 a public IPv4 address for each home agent on the NAT box, 2) 285 configure one public address and make the home agents share the 286 public address. In either case, the correct DNS entries can be 287 configured. Another possible solution is to designate one home agent 288 on the home link for IPv4 traversal. The NAT device should associate 289 that home agent with the public IPv4 address configured on it for v4 290 traversal. In all cases above, both the 'AAAA' and 'A' records 291 returned for a particular name MUST correspond to the same physical 292 home agent; otherwise the mobile node will not be able to bind its 293 addresses correctly. 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. The security implications of this 354 mechanism are discussed in the security considerations section. 356 In this scenario, the only addition to [RFC3775] is the inclusion of 357 the IPv4 home address option in the binding update message. 359 After accepting the binding update and creating the corresponding 360 binding cache entries, the home agent MUST send a binding 361 acknowledgement to the mobile node as defined in [RFC3775]. In 362 addition, if the binding update included an IPv4 home address option, 363 the binding acknowledgement MUST include the IPv4 address 364 acknowledgment option as described later in this specification. This 365 option informs the mobile node whether the binding was accepted for 366 the IPv4 home address. If this option is not included in the binding 367 acknowledgement and the IPv4 home address option was included in the 368 binding update, the mobile node MUST assume that the home agent does 369 not support the IPv4 home address option and therefore SHOULD NOT 370 include the option in future binding updates to that home agent 371 address. 373 When a mobile node acquires both IPv4 and IPv6 care-of addresses at 374 the foreign network, it SHOULD prioritize the IPv6 care-of address 375 for MIP6 its binding registration. The mobile node MUST NOT register 376 both IPv4 and IPv6 care-of addresses to its home agent. 378 3.3.2. Foreign Network Supports IPv4 Only 380 If the mobile node is in a foreign network that only supports IPv4, 381 it needs to detect whether a NAT is in its communication path to the 382 home agent. This is done while exchanging the binding update and 383 acknowledgement messages as shown later in this document. If no NAT 384 is detected between the mobile node and the home agent, the mobile 385 node assumes that it is in a foreign network that supports IPv4 386 public addresses. Otherwise, the mobile node assumes that private 387 addresses are used in the foreign network. Note that this assumption 388 is only valid for the purposes of the signaling presented in this 389 specification. A mobile node SHOULD NOT assume that its IPv4 address 390 is globally unique if a NAT device was not detected. The operations 391 of both cases are discussed below. 393 3.3.2.1. Foreign Network Supports IPv4 Only (Public Addresses) 395 In this scenario the mobile node will need to tunnel IPv6 packets 396 containing the binding update to the home agent's IPv4 address. The 397 mobile node uses the IPv4 address it gets from the foreign network as 398 a source address in the outer header. The binding update will 399 contain the mobile node's IPv6 home address. However, since the 400 care-of address in this scenario is the mobile node's IPv4 address, 401 the mobile node MUST include its IPv4 care-of address in the IPv6 402 packet. The IPv4 address is represented in the IPv4 Care-of address 403 option defined in this specification. If the mobile node had an IPv4 404 home address, it MUST also include the IPv4 home address option 405 described in this specification. 407 After accepting the binding update, the home agent MUST create a new 408 binding cache entry for the mobile node's IPv6 home address. If an 409 IPv4 home address option were included, the home agent MUST create 410 another entry for that address. All entries MUST point to the mobile 411 node's IPv4 care-of address. Hence, all packets addressed to the 412 mobile node's home address(es) (IPv4 or IPv6) will be encapsulated in 413 an IPv4 header that includes the home agent's IPv4 address in the 414 source address field and the mobile node's IPv4 care-of address in 415 the destination address field. 417 After accepting the binding updates and creating the corresponding 418 entries, the home agent MUST send a binding acknowledgement as 419 specified in [RFC3775]. In addition, if the binding update included 420 an IPv4 home address option, the binding acknowledgement MUST include 421 the IPv4 address acknowledgment option as described later in this 422 specification. The binding acknowledgement is encapsulated to the 423 IPv4 care-of address, which was included in the source address field 424 of the IPv4 header encapsulating the binding update. 426 3.3.2.2. Foreign Network Supports IPv4 Only (Private Addresses) 428 In this scenario the mobile node will need to tunnel IPv6 packets 429 containing the binding update to the home agent's IPv4 address. In 430 order to traverse the NAT device, IPv6 packets are tunneled using UDP 431 and IPv4. The UDP port allocated for the home agent is TBD_DSMIPv6. 433 The mobile node uses the IPv4 address it gets from the visited 434 network as a source address in the IPv4 header. The binding update 435 will contain the mobile node's IPv6 home address. 437 After accepting the binding update, the home agent MUST create a new 438 binding cache entry for the mobile node's IPv6 home address. If an 439 IPv4 home address option were included, the home agent MUST create 440 another entry for that address. All entries MUST point to the mobile 441 node's IPv4 care-of address included in the source address of the 442 IPv4 header that encapsulated the binding update message. In 443 addition, the tunnel used MUST indicate UDP encapsulation for NAT 444 traversal. Hence, all packets addressed to the mobile node's home 445 address(es) (IPv4 or IPv6) will be encapsulated in UDP then 446 encapsulated in an IPv4 header that includes the home agent's IPv4 447 address in the source address field and the mobile node's IPv4 care- 448 of address in the destination address field. 450 After accepting the binding updates and creating the corresponding 451 entries, the home agent MUST send a binding acknowledgement as 452 specified in [RFC3775]. In addition, if the binding update included 453 an IPv4 home address option, the binding acknowledgement MUST include 454 the IPv4 address acknowledgment option as described later in this 455 specification. The binding acknowledgement is encapsulated in UDP 456 then IPv4 with the home agent's IPv4 address in the source address 457 field and the mobile node's IPv4 care-of address in the destination 458 field. The IPv4 address in the destination field of the IPv4 packet 459 is the source address received in the IPv4 header containing the 460 binding update message. The inner IPv6 packet will contain the home 461 agent's IPv6 address as a source address and the mobile node's IPv6 462 home address in the destination address field. 464 The mobile node needs to maintain the NAT bindings for its current 465 IPv4 care-of address. This is done through sending the binding 466 update regularly to the home agent. 468 3.4. Route Optimization 470 Route optimization, as specified in [RFC3775] will operate in an 471 identical manner for dual stack mobile nodes when they are located in 472 a visited network that provides IPv6 addresses to the mobile node. 473 However, when located in an IPv4-only network, route optimization 474 will not be possible due to the difficulty of performing the care-of 475 address test. Therefore, mobile nodes will need to communicate 476 through the home agent. 478 Route optimization will not be possible for IPv4 traffic. That is, 479 traffic addressed to the mobile node's IPv4 home address. This is 480 similar to using Mobile IPv4, therefore there is no reduction of 481 features resulting from using this specification. 483 3.5. Dynamic IPv4 Home Address Allocation 485 It is possible to allow for the mobile node's IPv4 home address to be 486 allocated dynamically. This is done by including 0.0.0.0 in the IPv4 487 home address option included in the binding update. The home agent 488 SHOULD allocate an IPv4 address to the mobile node and include it in 489 the IPv4 address acknowledgement option sent to the mobile node. In 490 this case, the lifetime of the binding is bound to the minimum of the 491 lifetimes of the IPv6 binding and the lease time of the IPv4 home 492 address. 494 4. Extensions And Modifications To Mobile IPv6 496 This section highlights the protocol and implementation additions 497 required to support this specification. 499 4.1. Binding Update Extensions 501 4.1.1. IPv4 Home Address Option 503 This option is included in the Mobility Header including the binding 504 update message sent from the mobile node to a home agent or Mobility 505 Anchor Point. The alignment requirement for this option is 4n. 507 0 1 2 3 508 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 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | Type | Length |Prefix-len |P| Reserved | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | IPv4 home address | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 Figure 1: IPv4 Home Address Option 517 Type 519 TBD 521 Length 523 6 525 Prefix-len 527 The length of the prefix allocated to the mobile node. If only a 528 single address is allocated, this field MUST be set to 32. In the 529 first binding update requesting a prefix, the field contains the 530 prefix length requested. However, in the following binding 531 updates, this field must contain the length of the prefix 532 allocated. A value of zero is invalid and MUST be considered an 533 error. 535 P 537 A flag indicating, when set, that the mobile node requests a 538 mobile network prefix. This flag is only relevant for new 539 requests, and must be ignored for binding refreshes. 541 Reserved 543 This field is reserved for future use. It MUST be set to zero by 544 the sender and ignored by the receiver. 546 IPv4 Home Address 548 The mobile node's IPv4 home address that should be defended by the 549 home agent. This field could contain any unicast IPv4 address 550 (public or private) that was assigned to the mobile node. The 551 value 0.0.0.0 is used to request an IPv4 home address from the 552 home agent. A mobile node may choose to use this option to 553 request a prefix by setting the address to the All Zeroes and 554 setting the P flag. The mobile node could then form an IPv4 home 555 address based on the allocated prefix. Alternatively, the mobile 556 node may use two different options, one for requesting an address 557 (Static or Dynamic) and another for requesting a prefix. 559 4.1.2. The IPv4 Care-of Address Option 561 This option is included in the Mobility Header including the binding 562 update message sent from the mobile node to a home agent or Mobility 563 Anchor Point. The alignment requirement for this option is 4n. 565 0 1 2 3 566 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | Type | Length | Reserved | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | IPv4 Care-of address | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 Figure 2: The IPv4 CoA Option 575 Type 577 TBD 579 Length 581 6 583 Reserved 585 This field is set to zero by the sender and ignored by the 586 receiver. 588 IPv4 Care-of Address 590 This field contains the mobile node's IPv4 care- of address. The 591 IPv4 care-of address is used when the mobile node is located in an 592 IPv4-only network. 594 4.1.3. The Binding Update Message Extensions 596 This specification extends the Binding Update message with two new 597 flags. The flags are shown and described below. 599 0 1 2 3 600 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | Sequence # | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 |A|H|L|K|M|R|F|T| Reserved | Lifetime | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 Figure 3: Binding Update message 609 F 611 When set, this flag indicates a request for forcing UDP 612 encapsulation regardless of whether a NAT is present on the path 613 between the mobile node and the home agent. 615 T 617 When set, this flag indicates that the mobile node requests the 618 use of the TLV-format for encapsulating IPv6 in IPv4. The TLV- 619 format is described later in this document. 621 4.2. Binding Acknowledgement Extensions 623 4.2.1. IPv4 Address Acknowledgement Option 625 This option is included in the Mobility Header including the binding 626 acknowledgement message sent from the home agent or Mobility Anchor 627 Point to the mobile node. This option indicates whether a binding 628 cache entry was created for the mobile node's IPv4 address. 629 Additionally, this option can include an IPv4 home address in the 630 case of Dynamic IPv4 home address configuration (i.e., if the 631 unspecified IPv4 address was included in the binding update). The 632 alignment requirement for this option is 4n. 634 0 1 2 3 635 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 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | Type | Length | Status |Pref-len |Res| 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | IPv4 home address | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 Figure 4: IPv4 Address Acknowledgement Option 644 Type 646 TBD 648 Length 650 6 652 Status 654 Indicates success or failure for the IPv4 home address binding. 655 Values from 0 to 127 indicate success. Higher values indicate 656 failure. 658 Pref-len 660 The prefix length of the address allocated. This field is only 661 valid in case of success and MUST be set to zero and ignored in 662 case of failure. This field overrides what the mobile node 663 requested (if not equal to the requested length). 665 Res 667 This field is reserved for future use. It MUST be set to zero by 668 the sender and ignored by the receiver 670 IPv4 Home Address 672 The IPv4 home address that the home agent will use in the binding 673 cache entry. This could be a public or private address. This 674 field MUST contain the mobile node's IPv4 home address. If the 675 address were dynamically allocated the home agent will add the 676 address to inform the mobile node. Otherwise, if the address were 677 statically allocated to the mobile node, the home agent will copy 678 it from the binding update message. 680 The following values are allocated for the Status field: 682 o 0 Success 684 o 128 Failure, reason unspecified 686 o 129 Administratively prohibited 688 o 130 Incorrect IPv4 home address 690 o 131 Invalid IPv4 address 692 o 132 Dynamic IPv4 home address assignment not available 694 o 133 Prefix allocation unauthorized 696 4.2.2. The NAT Detection Option 698 This option is sent from the home agent to the mobile node to 699 indicate whether a NAT was in the path. This option MAY also include 700 a suggested NAT binding refresh time for the mobile node. The 701 alignment requirement for this option is 4n. If a NAT is detected, 702 this option MUST be sent by the home agent. 704 0 1 2 3 705 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 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | Type | Length |F| Reserved | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | Refresh time | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 Figure 5: The NAT Detection Option 714 Type 716 TBD 718 Length 720 6 722 F 724 This flag indicates to the mobile node that UDP encapsulation is 725 required. When set, this flag indicates that the mobile node MUST 726 use UDP encapsulation even if a NAT is not located between the 727 mobile node and home agent. 729 Reserved 731 This field is reserved for future use. It MUST be set to zero by 732 the sender and ignored by the receiver. 734 Refresh Time 736 A suggested time (in seconds) for the mobile node to refresh the 737 NAT binding. If set to zero, it is ignored. If this field is set 738 to all 1s it means that keepalives are not needed, i.e., no NAT 739 was detected. 741 4.2.3. Extensions to the Binding Acknowledgement Message 743 This specification extends the binding acknowledgement message with a 744 new flag. The new flag is shown and described below. 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 | Status |K|R|T| Reserved| 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | Sequence # | Lifetime | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 Figure 6: Binding Acknowledgement message 754 T 756 This flag indicates, when set, that the sender of the binding 757 acknowledgement supports the TLV- tunnel format. 759 5. Protocol operation 761 This section presents the protocol operation and processing for the 762 messages presented above. In addition, this section introduces the 763 NAT detection and traversal mechanism used by this specification. 765 5.1. Tunelling Formats 767 This specification allows the mobile node to use various tunnelling 768 formats depending on its location and the visited network's 769 capabilities. The mobile node can tunnel IPv6 in IPv4, IPv4 in IPv6 770 or use UDP encapsulation to tunnel IPv6 in IPv4. Naturally, this 771 specification also supports tunnelling IPv6 in IPv6. 773 This specification allows UDP-based tunnelling to be used between the 774 mobile node and its home agent or MAP using either vanilla UDP 775 encapsulation or TLV-header UDP encapsulation. A vanilla UDP 776 encapsulation format means the following order of headers: 778 IPv4 780 UDP 782 IP (v4 or v6) 784 Other headers 786 When using this format the receiver would parse the version field 787 following the UDP header in order to determine whether the following 788 header is IPv4 or IPv6. The rest of the headers are processed 789 normally. The above order of headers does not take IPsec headers 790 into account as they may be placed in different parts of the packet. 791 The above format MUST be supported by all implementations of this 792 specification and MUST always be used to send the binding update 793 message. 795 Vanilla UDP Tunnelling can also encapsulate an ESP header as shown 796 below. 798 IPv4 800 UDP 802 ESP 804 IP (v4 or v6) 805 Other headers 807 The negotiation of the secure tunnel format described above is 808 discussed in Section 6.2. The receiver of a vanilla UDP tunnel 809 detects whether an ESP header is present or not based on the UDP port 810 used. 812 TLV-header UDP encapsulation is represented by the following order of 813 headers: 815 IP (v4 or v6) 817 UDP 819 TLV-header 821 Other headers 823 The use of the TLV-header is negotiated during the binding update/ 824 acknowledgement exchange. If the TLV-header is agreed upon, the 825 receiver of the TLV-header UDP encapsulated packet expects the TLV 826 header to follow UDP. The TLV header contains the type of the 827 following message and its length. The Type field MUST NOT be 828 assigned the values 4 or 6 to make sure that the receiver can tell 829 the difference between the Type field and the IP version field in a 830 packet that contains an IP header after UDP. Hence, the TLV header 831 can carry traffic other than IP. 833 The mobile node negotiates the format for tunnelling payload traffic 834 during the binding exchange. If a mobile node prefers to use the 835 TLV- header UDP encapsulation, it sets the T flag in the binding 836 update sent to the home agent or MAP. If the receiver of the binding 837 update supports the TLV-header format, it SHOULD set the T flag in 838 the binding acknowledgement message. Otherwise, the T flag is 839 cleared. The setting of the T flag in the binding acknowledgement 840 indicates to the mobile node that it must use the TLV-header UDP 841 encapsulation format for all packets sent for the duration of the 842 binding or until a new binding update is sent. Each binding update 843 may renegotiate the tunnelling format. To avoid interoperability 844 issues, the sender of the binding acknowledgement MUST NOT set the T 845 flag unless it was set in the binding update sent from the mobile 846 node. 848 The TLV-header format is shown below. 850 0 1 2 3 851 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 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 | Type | Length | Reserved | 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 Figure 7: TLV-header format 858 Type 860 This field indicates the type of the payload following this 861 header. 863 Length 865 This field indicates the length of the payload following the 866 header, excluding the TLV-header itself. 868 Reserved 870 This field MUST be set to zero by the sender and ignored by the 871 receiver. 873 The following value is assigned to the Type field, other values may 874 be assigned in the future: 876 1 GRE 878 In addition to UDP-based tunnelling, this specification allows for 879 standard IP in IP tunnelling as defined in [RFC2473] and [RFC4213]. 880 This can take place by tunnelling IPv4 in IPv6 or IPv6 in IPv4. 881 However, whenever a NAT is detected, the mobile node will default to 882 UDP-based encapsulation. The mobile node can request to always use 883 UDP encapsulation by setting the F flag in the binding update. If 884 the home agent does not agree to the request, it MUST reject the 885 binding update with the new Status code: 887 144 Cannot force UDP encapsulation 889 Alternatively, the home agent can force UDP encapsulation by setting 890 the F flag in the NAT detection option included in the binding 891 acknowledgement. 893 5.1.1. tunnelling Impacts on Transport and MTU 895 Changing the tunnel format may occur due to movement of the mobile 896 node from one network to another. This can have impacts on the link 897 and path MTU, which may affect the amount of bandwidth available to 898 the applications. It is recommended that the mobile node use PLMTUD 899 as specified in [RFC4459]. 901 To accommodate traffic that uses Explicit Congestion Notification 902 (ECN), it is RECOMMENDED that the ECN information is copied between 903 the inner and outer header as defined in [RFC3168]. 905 5.2. NAT Detection 907 NAT detection is done when the initial binding update message is sent 908 from the mobile node to the home agent. When located in an IPv4-only 909 foreign link, the mobile node sends the binding update message 910 encapsulated in UDP and IPv4. The source address of the IPv6 packet 911 is the mobile node's IPv6 home address. The destination address is 912 the IPv6 address of the home agent. The IPv4 header contains the 913 IPv4 care-of address in the source address field and the IPv4 address 914 of the home agent in the destination address field. 916 When the home agent receives the encapsulated binding update, it 917 compares the IPv4 address of the source address field in the IPv4 918 header with the IPv4 address included in the IPv4 care-of address 919 option. If the two addresses match, no NAT device was in the path. 920 Otherwise, a NAT device was in the path and the NAT detection option 921 is included in the binding acknowledgement. The binding 922 acknowledgement, and all future packets, are then encapsulated in UDP 923 and IPv4. The source address in the IPv4 header is the IPv4 address 924 of the home agent. The destination address is the IPv4 address 925 received in the IPv4 header encapsulating the binding update (this 926 address will be different from the IPv4 care-of address when a NAT is 927 in the path). The source port in the packet is the home agent's 928 source port. The destination port is the source port received in the 929 binding update message. Note that the home agent stores the port 930 numbers and associates them with the mobile node's tunnel in order to 931 forward future packets. 933 Upon receiving the binding acknowledgement with the NAT detection 934 option, the mobile node sets the tunnel to the home agent to UDP 935 encapsulation. Hence, all future packets to the home agent are 936 tunneled in UDP and IPv4. For all tunneled IPv6 packets, the source 937 address in the IPv6 header is the mobile node's IPv6 home address and 938 the destination address is the correspondent node's IPv6 address. 939 All tunneled IPv4 packets will contain the mobile node's IPv4 home 940 address in the source address field of the inner IPv4 packet and the 941 correspondent node's IPv4 address in the destination address field. 942 The outer IPv4 header is the same whether the inner packet is IPv4 or 943 IPv6. 945 If no NAT device was detected in the path between the mobile node and 946 the home agent then IPv6 packets are tunneled in an IPv4 header, 947 unless the home agent forces UDP encapsulation using the F flag. The 948 content of the inner and outer headers are identical to the UDP 949 encapsulation case. 951 A mobile node MUST always tunnel binding updates in UDP when located 952 in an IPv4-only network. Essentially, this process allows for 953 perpetual NAT detection. Similarly, the home agent MUST encapsulate 954 binding acknowledgements in a UDP header whenever the binding update 955 is encapsulated in UDP. 957 In conclusion, the packet formats for the binding update and 958 acknowledgement messages are shown below: 960 Binding update received by the home agent: 962 IPv4 header (src=V4ADDR, dst=HA_V4ADDR) 964 UDP header 966 IPv6 header (src=V6HOA, dst=HAADDR) 968 ESP Header 970 Mobility header 972 BU [IPv4 HAO] 974 IPv4 CoA option 976 Where V4ADDR is either the IPv4 care-of address or the address 977 provided by the NAT device. V6HOA is the IPv6 home address of the 978 mobile node. The binding update MAY also contain the IPv4 home 979 address option IPv4 HAO. 981 Binding acknowledgement sent by the home agent: 983 IPv4 header (src= HA_V4ADDR, dst=V4ADDR) 985 UDP Header 987 IPv6 header (src=HAADDR, dst=V6HOA) 989 ESP Header 991 Mobility Header 992 BA ([IPv4 ACK], NAT DET) 994 Where V6HOA is IPv6 home address of the mobile node. The IPv4 ACK is 995 the IPv4 address acknowledgement option, which is only included if 996 the IPv4 home address option were present in the BU. The NAT DET is 997 the NAT detection option, which MUST be present in the binding 998 acknowledgement message if the binding update was encapsulated in 999 UDP. 1001 5.3. NAT Keepalives 1003 If a NAT is detected, the mobile node will need to refresh the NAT 1004 bindings in order to be reachable from the home agent. NAT bindings 1005 can be refreshed through sending and receiving traffic encapsulated 1006 in UDP. However, if the mobile node is not active, it will need to 1007 periodically send a message to the home agent in order to refresh the 1008 NAT binding. This can be done using the binding update message. The 1009 binding update/acknowledgement pair will ensure that the NAT bindings 1010 are refreshed in a reliable manner. There is no way for the mobile 1011 node to know the exact time of the NAT binding. The default time 1012 suggested in this specification is NATKATIMEOUT. If the home agent 1013 suggests a different refresh period in the binding acknowledgement, 1014 the mobile node SHOULD use the value suggested by the home agent. 1016 If the refresh time in the NAT detection option in the binding 1017 acknowledgement is set to all 1s, the mobile node need not send 1018 messages to refresh the NAT binding. However, the mobile node may 1019 still be required to encapsulate traffic in UDP. This scenario may 1020 take place when a NAT is not detected, but the home agent still 1021 requires the mobile node to use UDP encapsulation. 1023 It should be noted that a mobile node that does not need to be 1024 reachable (i.e., only cares about the session continuity aspect of 1025 Mobile IP) does not need to refresh the NAT binding. In this case, 1026 the mobile node would only be able to initiate communication with 1027 other nodes. However, this is likely to imply that the mobile node 1028 will need to send a binding update before initiating communication 1029 after a long idle period as it is likely to be assigned a different 1030 port and IPv4 address when it initiates communication. Hence, an 1031 implementation may choose, for the sake of simplicity, to always 1032 maintain the NAT bindings even when it does not need reachability. 1034 5.4. Mobile Node Operation 1036 In addition to the operations specified in [RFC3775] and [RFC3963], 1037 this specification requires mobile nodes to be able to support an 1038 IPv4 home address. 1040 When sending an IPv6 packet containing a binding update while 1041 connected to an IPv4-only access network, mobile nodes MUST ensure 1042 the following: 1044 o The IPv6 packet is encapsulated in the vanilla UDP encapsulation 1045 format. 1047 o The source address in the IPv4 header is the mobile node's IPv4 1048 care-of address. 1050 o The destination address in the IPv4 header is the home agent's 1051 IPv4 address. 1053 o The source address in the IPv6 header is the mobile node's IPv6 1054 home address. 1056 o The IPv4 home address option MAY be included in the mobility 1057 header. This option contains the IPv4 home address. If the 1058 mobile node did not have a static home address it MAY include the 1059 unspecified IPv4 address, which acts as a request for a dynamic 1060 IPv4 home address. Alternatively, one or more IPv4 home address 1061 options may be included with requests for IPv4 prefixes (i.e., 1062 with the P flag set). 1064 o If the mobile node wishes to use UDP encapsulation only, it should 1065 set the F flag in the binding update message. 1067 o If the mobile node prefers to use the TLV-header format, it should 1068 set the T flag in the binding update. 1070 o The IPv6 packet MUST be authenticated as per [RFC3775], based on 1071 the mobile node's IPv6 home address. 1073 When sending a binding update from a visited network that supports 1074 IPv6, the mobile node MUST follow the rules specified in [RFC3775]. 1075 In addition, if the mobile node has an IPv4 home address or needs 1076 one, it MUST include the IPv4 home address option in the mobility 1077 header. If the mobile node already has a static IPv4 home address, 1078 this address MUST be included in the IPv4 home address option. 1079 Otherwise, if the mobile node needs a dynamic IPv4 address, it MUST 1080 include the IPv4 0.0.0.0 address in the IPv4 home address option. 1082 When the mobile node receives a binding acknowledgement from the home 1083 agent, it follows the rules in [RFC3775] and [RFC3963]. In addition, 1084 the following actions MUST be made: 1086 o If the status field indicated failure with error code 144, the 1087 mobile node MAY resend the binding update without setting the F 1088 flag. 1090 o If the mobility header includes an IPv4 address acknowledgement 1091 option indicating success, the mobile node should create two 1092 entries in its binding update list, one for the IPv6 home address 1093 and another for the IPv4 home address. 1095 o If the NAT detection option were present, the mobile node MUST 1096 tunnel future packets in UDP and IPv4. This MUST be indicated in 1097 the binding update list. 1099 o If no IPv4 address acknowledgement option were present, and an 1100 IPv4 home address option was present in the binding update, the 1101 mobile node MUST only create one binding update list entry for its 1102 IPv6 home address. The mobile node MAY include the IPv4 home 1103 address option in future binding updates. 1105 o If an IPv4 address acknowledgement option were present and it 1106 indicates failure for the IPv4 home address binding, the mobile 1107 node MUST NOT create an entry for that address in its binding 1108 update list. The mobile node MAY include the IPv4 home address 1109 option in future binding updates. 1111 o If the T flag was set in the binding update and the binding 1112 acknowledgement included the T flag set, the mobile node MUST use 1113 the TLV-header UDP encapsulation format. 1115 5.4.1. Sending Packets from a Visited Network 1117 When the mobile node is located in an IPv6-enabled network it sends 1118 and receives IPv6 packets as described in [RFC3775]. IPv4 traffic is 1119 encapsulated in IPv6 packets to the home agent. 1121 When the mobile node is located in an IPv4 only network, it will send 1122 IPv6 packets to its home agent according to the following format: 1124 IPv4 header (src=V4CoA, dst=HA_V4ADDR) 1126 [UDP Header] 1128 [TLV Header] 1130 IPv6 header (src=V6HoA, dst=CN) 1132 Upper Layer protocols 1134 Here the UDP header is only used if a NAT has been detected between 1135 the mobile node and the home agent, or if the home agent forced UDP 1136 encapsulation. V4CoA is the IPv4 care-of address configured by the 1137 mobile node in the visited network. 1139 Similarly, IPv4 packets are sent according to the following format: 1141 IPv4 header (src=V4CoA, dst=HA_V4ADDR) 1143 [UDP Header] 1145 [TLV Header] 1147 IPv4 header (src=V4HoA, dst=V4CN) 1149 Upper Layer protocols 1151 Here the UDP header is only used if a NAT has been detected between 1152 the mobile node and the home agent, or if the home agent forced UDP 1153 encapsulation. 1155 If the mobile node and the home agent negotiated the use of the TLV- 1156 header UDP encapsulation format, then the TLV-header would be used 1157 after the UDP header. 1159 5.4.2. Movement Detection in IPv4-only Networks 1161 [RFC3775] describes movement detection mostly based on IPv6-specific 1162 triggers and Neighbor Discovery [RFC4861] information. These 1163 triggers are not available in an IPv4-only network. Hence, a mobile 1164 node located in an IPv4-only network SHOULD use [RFC4436] for 1165 guidance on movement detection mechanisms in IPv4-only networks. 1167 5.5. Home agent operation 1169 In addition to the home agent specification in [RFC3775] and 1170 [RFC3963], the home agent needs to be able to process the IPv4 home 1171 address option and generate the IPv4 address acknowledgement option. 1172 Both options are included in the mobility header. Furthermore, the 1173 home agent MUST be able to detect the presence of a NAT device and 1174 indicate that in the NAT detection option included in the binding 1175 acknowledgement. 1177 A home agent must also act as a proxy for address resolution in IPv4 1178 for the registered IPv4 home addresses of mobile nodes it is serving. 1179 Moreover, the administrative domain of the home agent is responsible 1180 for advertising the routing information of registered IPv4 mobile 1181 network prefixes of the mobile nodes. 1183 In order to comply with this specification, the home agent MUST be 1184 able to find the IPv4 home address of a mobile node when given the 1185 IPv6 home address. That is, given an IPv6 home address, the home 1186 agent MUST store the corresponding IPv4 home address if a static one 1187 is present. If a dynamic address were requested by the mobile node, 1188 the home agent MUST store that address (associated with the IPv6 home 1189 address) after it's allocated to the mobile node. 1191 When the home agent receives a binding update encapsulated in UDP and 1192 containing the IPv4 home address option, it needs to follow all the 1193 steps in [RFC3775] and [RFC3963]. In addition, the following checks 1194 MUST be done: 1196 o If the IPv4 care-of address in the IPv4 CoA option is not the same 1197 as the IPv4 address in the source address in the IPv4 header then 1198 a NAT was in the path. This information should be flagged for the 1199 binding acknowledgement. 1201 o If the F flag in the binding update were set, the home agent needs 1202 to determine whether it accepts forcing UDP encapsulation. If it 1203 does not, the binding acknowledgement is sent with error code 144. 1204 UDP encapsulation MUST NOT be used when the mobile node is located 1205 in an IPv6-enabled link. 1207 o If the T flag was set in the binding update, the home agent needs 1208 to determine whether it can accept the TLV-header encapsulation 1209 format. If it does, it should set the T flag in the binding 1210 acknowledgement. Otherwise, the home agent MUST NOT set the T 1211 flag in the binding acknowledgement. 1213 o If the IPv4 home address option contains a valid unicast IPv4 1214 address, the home agent MUST check that this address is allocated 1215 to the mobile node that has the IPv6 home address included in the 1216 home address option. The same MUST be done for an IPv4 prefix. 1218 o If the IPv4 home address option contained the unspecified IPv4 1219 address, the home agent SHOULD dynamically allocate an IPv4 home 1220 address to the mobile node. If none is available, the home agent 1221 MUST return error code 132 in the status field of the IPv4 address 1222 acknowledgement option. If a prefix were requested, the home 1223 agent MUST allocate a prefix with the requested length; if that 1224 allocation was not possible, the home agent MUST indicate failure 1225 of the operation with the appropriate error code. 1227 o If the binding update is accepted for the IPv4 home address, the 1228 home agent creates a binding cache entry for the IPv4 home 1229 address/prefix. The home agent MUST include an IPv4 1230 acknowledgement option in the mobility header containing the 1231 binding acknowledgement. 1233 o If the binding update is accepted for both IPv4 and IPv6 home 1234 addresses, the home agent creates separate binding cache entries, 1235 one for each home address. The care-of address is the one 1236 included in the binding update. If the care-of address is an IPv4 1237 address, the home agent MUST setup a tunnel to the IPv4 care-of 1238 address of the mobile node. 1240 When sending a binding acknowledgement to the mobile node, the home 1241 agent constructs the message according to [RFC3775] and [RFC3963]. 1242 Note that the routing header MUST always contain the IPv6 home 1243 address as specified in [RFC3775]. 1245 If the care-of address of the mobile node were an IPv4 address, the 1246 home agent includes the mobile node's IPv6 home address in the 1247 destination address field in the IPv6 header. If a NAT were 1248 detected, the home agent MUST then encapsulate the packet in UDP and 1249 an IPv4 header. The source address is set to the home agent's IPv4 1250 address and the destination address is set to the address received in 1251 the source address of the IPv4 header encapsulating the binding 1252 update. 1254 After creating a binding cache entry for the mobile node's home 1255 addresses, all packets sent to the mobile node's home addresses are 1256 tunneled by the home agent to the mobile node's care-of address. If 1257 a NAT were detected, packets are encapsulated in UDP and IPv4. 1258 Otherwise, if the care-of address is an IPv4 address, and no NAT were 1259 detected, packets are encapsulated in an IPv4 header unless UDP 1260 encapsulation is forced by the home agent. 1262 5.5.1. Sending Packets to the Mobile Node 1264 The home agent follows the rules specified in [RFC3775] for sending 1265 IPv6 packets to mobile nodes located in IPv6 networks. When sending 1266 IPv4 packets to mobile nodes in an IPv6 network, the home agent must 1267 encapsulate the IPv4 packets in IPv6. 1269 When sending IPv6 packets to a mobile node located in an IPv4 1270 network, the home agent must follow the format negotiated in the 1271 binding update/acknowledgement exchange. In the absence of a 1272 negotiated format, the default format that MUST be supported by all 1273 implementations is: 1275 IPv4 header (src= HA_V4ADDR, dst= V4ADDR) 1277 UDP Header 1278 IPv6 header (src=CN, dst= V6HoA) 1280 Upper layer protocols 1282 Where the UDP header is only included if a NAT were detected between 1283 the mobile node and the home agent, or if the home agent forced UDP 1284 encapsulation. V4ADDR is the IPv4 address received in the source 1285 address field of the IPv4 packet containing the binding update. 1287 When sending IPv4 packets to a mobile node located in an IPv4 1288 network, the home agent must follow the format negotiated in the 1289 binding update/acknowledgement exchange. In the absence of a 1290 negotiated format, the default format that MUST be supported by all 1291 implementations is: 1293 IPv4 header (src= HA_V4ADDR, dst= V4ADDR) 1295 [UDP Header] 1297 IPv4 header (src=V4CN, dst= V4HoA) 1299 Upper layer protocols 1301 Where the UDP header is only included if a NAT were detected between 1302 the mobile node and home agent, or if the home agent forced UDP 1303 encapsulation. 1305 5.6. Correspondent Node Operation 1307 This specification has no impact on IPv4 or IPv6 correspondent nodes. 1309 6. Security Considerations 1311 This specification allows a mobile node to send one binding update 1312 for its IPv6 and IPv4 home addresses. This is a slight deviation 1313 from [RFC3775] which requires one binding update per home address. 1314 However, like [RFC3775], the IPsec security association needed to 1315 authenticate the binding update is still based on the mobile node's 1316 IPv6 home address. Therefore, in order to authorize the mobile 1317 node's IPv4 home address binding, the home agent MUST store the IPv4 1318 address corresponding to the IPv6 address that is allocated to a 1319 mobile node. Therefore, it is sufficient for the home agent to know 1320 that the IPsec verification for the packet containing the binding 1321 update was valid provided that it knows which IPv4 home address is 1322 associated with which IPv6 home address. Hence, the security of the 1323 IPv4 home address binding is the same as the IPv6 binding. 1325 In effect, associating the mobile node's IPv4 home address with its 1326 IPv6 home address moves the authorization of the binding update for 1327 the IPv4 address to the Mobile IPv6 implementation, which infers it 1328 from the fact that the mobile node has an IPv6 home address and the 1329 right credentials for sending an authentic binding update for the 1330 IPv6 address. 1332 In cases where this specification is used for NAT traversal, it is 1333 important to note that it has the same vulnerabilities associated 1334 with [RFC3519]. An attacker is able to hijack the mobile node's 1335 session with the home agent if it can modify the contents of the 1336 outer IPv4 header. The contents of the header are not authenticated 1337 and there is no way for the home agent to verify their validity. 1338 Hence, a man in the middle attack where a change in the contents of 1339 the IPv4 header can cause a legitimate mobile node's traffic to be 1340 diverted to an illegitimate receiver independently of the 1341 authenticity of the binding update message. 1343 In this specification, the binding update message MUST be protected 1344 using ESP transport mode. When the mobile node is located in an 1345 IPv4-only network, the binding update message is encapsulated in UDP 1346 as described earlier. However, UDP MUST NOT be used to encapsulate 1347 the binding update message when the mobile node is located in an 1348 IPv6-enabled network. If protection of payload traffic is needed 1349 when the mobile node is located in an IPv4-only network, 1350 encapsulation is done using tunnel mode ESP over port 4500 as 1351 described in [RFC3948]. During the IKE negotiation with the home 1352 agent, if the mobile node and home agent support the use of port 1353 4500, the mobile node MUST establish the security association over 1354 port 4500, regardless of the presence of a NAT. This is done to 1355 avoid the switching between ports 500 and 4500 and the potential 1356 traffic disruption resulting from this switch. 1358 Handovers within private IPv4 networks or from IPv6 to IPv4 networks 1359 will have impacts on the security association between the mobile node 1360 and the home agent. The following section presents the expected 1361 behaviour of the mobile node and home agent in those situations. The 1362 details of the IKE negotiations and messages are illustrated in 1363 Section 6.2 1365 6.1. Handover Interactions for IPsec and IKE 1367 After the mobile node detects movement it configures a new care-of 1368 address. If the mobile node is in an IPv4-only network, it removes 1369 binding update list entries for correspondent nodes since route 1370 optimisation cannot be supported. This may cause inbound packet 1371 losses as remote correspondent node are unaware of such movement. To 1372 avoid confusion in the correspondent node, the mobile node SHOULD 1373 deregister its binding with each correspondent node by sending a 1374 deregistration binding update. The deregistration binding update 1375 message is tunnelled to the home agent and onto the correspondent 1376 node. This is done after the mobile node updates the home agent with 1377 its new location as discussed below. 1379 The mobile node sends the binding update message to the home agent. 1380 If the mobile node is in an IPv6-enabled network, the binding update 1381 is sent without IPv4/UDP encapsulation. If the mobile node is in an 1382 IPv4-only network, then after IPsec processing of the BU message, it 1383 encapsulates the BU in UDP/IPv4 as discussed in sections 5.2 and 5.4. 1384 In order to be able to send the binding update while in an IPv4-only 1385 network, the mobile node needs to use the new IPv4 care-of address in 1386 the outer header, which is different from the care-of address used in 1387 the existing tunnel. This should be done without permanently 1388 updating the tunnel within the mobile node's implementation in order 1389 to allow the mobile node to receive packets on the old care-of 1390 address until the binding acknowledgement is received. The method 1391 used to achieve this effect is implementation dependent and is 1392 outside the scope of this specification. This implies that the IP 1393 forwarding function (which selects the interface or tunnel through 1394 which a packet is sent) is not based solely on the destination 1395 address: some IPv6 packets destined to the home agent are sent via 1396 the existing tunnel, while BUs are sent using the new care-of 1397 address. Since BUs are protected by IPsec, the forwarding function 1398 cannot necessarily determine the correct treatment from the packet 1399 headers. Thus, the DSMIPv6 implementation has to attach additional 1400 information to BUs, and this information has to be preserved after 1401 IPsec processing and made available to the forwarding function, or 1402 additional DSMIP processing added to the forwarding function. 1403 Depending on the mobile node's implementation, meeting this 1404 requirement may require changes to the IPsec implementation. 1406 Upon receiving the binding update message encapsulated in UDP/IPv4, 1407 the home agent processes it as follows. In order to allow the 1408 DSMIPv6 implementation in the home agent to detect the presence of a 1409 NAT on the path to the mobile node, it needs to compare the outer 1410 IPv4 source address with the IPv4 address in the IPv4 care-of address 1411 option. This implies that the information in the outer header will 1412 be preserved after IPsec processing and made available to the DSMIPv6 1413 implementation in the home agent. Depending on the home agent's 1414 implementation, meeting this requirement may require changes to the 1415 IPsec implementation. 1417 The home agent updates its tunnel mode security association to 1418 include the mobile node's care-of address as the remote tunnel header 1419 address, and 4500 as the port number. The IPv4 address and port 1420 number are likely to be wrong; the mobile node provides the correct 1421 information in a separate exchange as described below. When the 1422 mobile node is located in a private IPv4 network (which is detected 1423 as described above), the new address and port number are allocated by 1424 the NAT. The home agent will also enable or disable UDP 1425 encapsulation for outgoing ESP packets for the purpose of NAT 1426 traversal. 1428 If the Key Management Mobility Capability (K) bit was set in the 1429 binding update, and the home agent supports this feature, the home 1430 agent updates its IKE security associations to include the mobile 1431 node's care-of address as the peer address and 4500 as the port 1432 number. The home agent may also need to change NAT traversal fields 1433 in the IKE_SA to enable the dynamic update of the IP address and port 1434 number based on the reception of authenticated IKE messages, or 1435 authenticated packets using tunnel mode ESP. The dynamic updates are 1436 described in section 2.23 of RFC 4306. As described above, when the 1437 mobile node is located in a private IPv4 network, the address and 1438 port number used for IPsec and IKE traffic is not yet known by the 1439 home agent at this point. 1441 The mobile node updates the IKE SA in one of two ways. If the K flag 1442 was set in the binding acknowledgement message, the mobile node 1443 SHOULD send an empty informational message, which results in the IKE 1444 module in the home agent to dynamically update the SA information. 1445 The IKE implementation in the home agent is REQUIRED to support this 1446 feature. Alternatively, the IKE SA should be re-negotiated. Note 1447 that updating the IKE SA MUST take place after the mobile node has 1448 sent the binding update and received the acknowledgement from the 1449 home agent. 1451 It is important to note that the mobile node's IPv4 care-of address 1452 seen by the DSMIPv6 module in the home agent upon receiving the 1453 binding update may differ from the IPv4 care-of address seen by the 1454 IKE module and the care-of address used for forwarding IPsec tunnel 1455 mode traffic. Hence, it is probable that different modules in the 1456 home agent will have a different care-of address that should be used 1457 for encapsulating traffic to the mobile node. 1459 After successfully processing the binding update, the home agent 1460 sends the binding acknowledgement to the mobile node's care-of 1461 address as received in the outer header of the packet containing the 1462 binding update. Note that if the BU was rejected, the BAck is sent 1463 to the same address where the BU was received from. This may require 1464 special treatment in IP forwarding and/or IPsec processing which 1465 resembles sending of BUs in the mobile node (described above). 1467 Upon receiving the binding acknowledgement, the mobile node updates 1468 its local tunnel mode Security Association information to include the 1469 tunnel header IP source address, which is the mobile node's address 1470 and the tunnel header IP destination, which is the home agent's 1471 address. The mobile node may also need to enable or disable UDP 1472 encapsulation for outgoing ESP packets for the purpose of NAT 1473 traversal and the sending of keep alives. 1475 The mobile node MAY use [RFC4555] to update its IKE SA with the home 1476 agent. Using MOBIKE requires negotiating this capability with the 1477 home agent when establishing the SA. In this case, the mobile node 1478 and the home agent MUST NOT update their IPsec SAs locally as this 1479 step is performed by MOBIKE. Furthermore, the use of MOBIKE allows 1480 the mobile node to update the SA independently of the binding update 1481 exchange. Hence, there is no need for the mobile node to wait for a 1482 binding acknowledgement before performing MOBIKE. The use of MOBIKE 1483 is OPTIONAL in this specification. 1485 6.2. IKE negotiation messages between the mobile node and Home Agent 1487 This specification defines a number of possible data encapsulation 1488 formats depending on the mobile node's connectivity to the visited 1489 network. When connected to an IPv6-enabled network, the tunnelling 1490 formats are clear. However, when connected to an IPv4-only network, 1491 care should be taken when negotiating the IKE association and the 1492 consequential tunnelling formats used for secure and insecure 1493 traffic. This section illustrates the IKE message exchange between 1494 the mobile node and home agent when the mobile node is located in an 1495 IPv4-only network. Two different IKE negotiations are considered: 1497 o IKEv2 operation for securing DSMIPv6 Signaling. 1499 o IKEv2 operation for securing Data over IPv4 1501 6.2.1. IKEv2 Operation for Securing DSMIPv6 Signaling 1503 A mobile node connected to an IPv4-only network SHOULD follow the 1504 procedures described below in order to establish an SA for the 1505 protection of binding update and binding acknowledgement messages. 1507 Mobile Node Home Agent 1508 ----------- ---------- 1509 IPv4(source_addr=V4ADDR, dest_addr=HAADDR) 1510 UDP (500, 500) HDR, SAi1, KEi, Ni 1511 NAT-D, NAT-D --> 1513 <- IPv4(source_addr=HAADDR, dest_addr=V4ADDR) 1514 UDP(500,X) HDR, SAr1, KEr, Nr, [CERTREQ] 1515 NAT-D, NAT-D 1517 IPv4(source_addr=V4ADDR, dest_addr=HAADDR) 1518 UDP (4500,4500) HDR, SK 1519 {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, N(USE_TRANSPORT_MODE), 1520 SAi2, TSi, TSr} 1521 --> 1523 <-- IPv4(source_addr=HAADDR, dest_addr=V4ADDR) 1524 UDP (4500,Y) HDR, SK 1525 {IDr, [CERT,] AUTH, N(USE_TRANSPORT_MODE), 1526 SAr2, TSi, TSr} 1528 The corresponding SPD entries are shown below. 1530 Mobile node SPD-S: 1532 IF local_address = home_address_1 & 1534 remote_address = home_agent_1 & 1536 proto = MH & local_mh_type = BU & remote_mh_type = BAck Then use 1537 SA ESP transport mode 1539 Initiate using IDi = user_1 to address home_agent_1 1541 Home Agent SPD-S: 1543 IF local_address = home_agent_1 & 1545 remote_address = home_address_1 & 1546 proto = MH & local_mh_type = BAck & remote_mh_type = BU Then use 1547 SA ESP transport mode 1549 where home_address_1 is the mobile node's registered IPv6 home 1550 address and home_agent_1 is the IP address of the home agent 1552 The above should result in BU/BA messages with the following BU 1553 received by the home agent. 1555 IPv4 header (src=V4ADDR, dst=HA_V4ADDR) 1557 UDP header (sport=Z, dport=DSMIPv6) 1559 IPv6 header (src=V6HOA, dst=HAADDR) 1561 ESP Header in Transport Mode 1563 Mobility header 1565 BU [IPv4 HAO] 1567 IPv4 CoA option 1569 (+ other as needed) 1571 At the home agent, following UDP de-capsulation, the binding update 1572 is delivered to the IPsec module as shown below: 1574 IPv6 header (src=V6HOA, dst=HAADDR) 1576 ESP Header in Transport Mode 1578 Mobility header 1580 BU [IPv4 HAO] 1582 IPv4 CoA option 1584 (+other as needed) 1586 In addition, V4ADDR and the sport (Z) need to be passed with the 1587 packet to ensure correct processing. 1589 Following IPsec processing, the binding update is delivered to the 1590 DSMIPv6 home agent module as follows: 1592 IPv6 header (src=V6HOA, dst=HAADDR) 1594 Mobility Header 1596 BU [IPv4 HAO] 1598 IPv4 CoA option 1600 (+other as needed) 1602 In addition, V4ADDR and the sport (Z) need to be passed with the 1603 packet to ensure correct processing. 1605 The binding acknowledgement sent by the home agent module to the 1606 IPsec module is as follows: 1608 IPv6 header (src=HAADDR, dst=V6HOA) 1610 Mobility Header 1612 BA ([IPv4 ACK], NAT DET) 1614 (+ other as needed) 1616 In addition, V4ADDR, the sport from the BU (Z), and an indication 1617 that vanilla UDP encapsulation must be used, need to be passed with 1618 the packet to ensure correct processing. 1620 The binding acknowledgement sent by the home agent to the mobile node 1621 is as follows: 1623 IPv4 header (src= HA_V4ADDR, dst=V4ADDR) 1625 UDP Header (sport=DSMIPv6, dport=Z) 1627 IPv6 header (src=HAADDR, dst=V6HOA) 1629 ESP Header in Transport Mode 1631 Mobility Header 1633 BA ([IPv4 ACK], NAT DET) 1635 6.2.2. IKEv2 Operation for Securing Data over IPv4 1637 To secure data traffic when the mobile node is located in an IPv4- 1638 only network, the mobile node MUST establish a child_SA for that 1639 purpose. The procedure is as follows: 1641 Mobile Node Home Agent 1642 ----------- ---------- 1643 IPv4(source_addr=V4ADDR, dest_addr=HAADDR) 1644 UDP (4500,4500) < non-ESP Marker > HDR, SK 1645 {[N], SA, Ni, [KEi], TSi, TSr} --> 1647 <--IPv4(source_addr=HAADDR, dest_addr=V4ADDR) 1648 UDP (4500,Y) < non-ESP Marker > HDR, SK 1649 SA, Nr, [KEr], TSi, TSr} 1651 If no NAT is detected, the encapsulation used will be: 1653 IPv4 (source_addr=v4CoA, dest_addr=HAAddr) 1655 ESP 1657 IP (source_addr=HoA, set_addr=CNAddr) 1659 Upper_layer_HDR 1661 where IP=IPv4 or IPv6 and HoA=v4HoA or v6HoA 1663 If a NAT were detected, the encapsulation used will be: 1665 IPv4 (source_addr=v4Addr, dest_addr=HAAddr) 1667 UDP (sport=Y, dport=4500) 1669 ESP 1671 IP (source_addr=HoA, set_addr=CNAddr) 1673 Upper_layer_HDR 1675 Where v4CoA may be the external IPv4 address of the NAT, IP is either 1676 an IPv4 or IPv6 header and HoA is either the IPv4 or the IPv6 HoA. 1677 The above format shows the packet as seen by the home agent. 1679 The SPD, whether a NAT were detected or not, is set as follows. Note 1680 that this rule is designed to match all data from the MN to nodes 1681 other than the home agent. This is done so that this rule does not 1682 overlap with the earlier rule securing BU/BA signaling between the MN 1683 and the HA. 1685 Mobile Node SPD-S: 1687 IF local_address = home_address & 1689 remote_address != home_agent & 1691 proto=any, then use SA ESP tunnel mode 1693 Initiate using IDi = user_1 to address home_agent_1 1695 home agent SPD-S: 1697 IF local_address != home_agent & 1699 remote_address = home_address & 1701 proto=any, then use SA ESP tunnel mode 1703 Where home_address is the MN's registered IPv6 or IPv4 home address 1704 and home_agent is the IPv6 or the IPv4 address of the home agent. 1706 7. Protocol Constants 1708 NATKATIMEOUT 110 seconds 1710 8. Acknowledgements 1712 Thanks to the following members (in alphabetical order) of the MIP6 1713 and NEMO Working Groups for their contributions, discussion, and 1714 review: Jari Arkko, Sri Gundavelli, Wassim Haddad, Conny Larsson, 1715 Acee Lindem, Ahmad Muhanna, Vidya Narayanan, Karen Nielsen and 1716 Keiichi Shima. Thanks to Karen Nielsen, Pasi Eronen and Christian 1717 Kaas-Petersen for raising the issue of IKEv2 interactions and 1718 proposing the solution included in this document. 1720 9. IANA Considerations 1722 The specification requires the following allocations from IANA: 1724 A UDP port is needed for the NAT traversal mechanism described in 1725 section 4.1. 1727 The IPv4 home address option described in section 3.1.1 requires 1728 an option type. This option is included in the Mobility header 1729 described in [RFC3775]. 1731 The IPv4 address acknowledgement option described in section 3.2.1 1732 requires a new option type. This option is included in the 1733 Mobility header described in [RFC3775]. 1735 The NAT detection option described in section 3.2.2 requires a new 1736 option type. This option is included in the Mobility header 1737 described in [RFC3775]. 1739 The IPv4 Care-of address option described in section 3.1.2 1740 requires an option type. This option is included in the Mobility 1741 header described in [RFC3775]. 1743 This specification introduces a new TLV-header to be used with UDP 1744 encapsulation. The Types of the TLV-header should be allocated by 1745 IANA under a new registry: "DSMIPv6 TLV-header Types". 1747 The Status field in the IPv4 home address option should be allocated 1748 by IANA under the new registry: "DSMIPv6 IPv4 home address option 1749 status codes". 1751 The TLV-header types and status field values are allocated using the 1752 following procedure: 1754 1. The IANA should allocate and permanently register new TLV-header 1755 types and Status field values from IETF RFC publication. This is 1756 for all RFC types including standards track, informational, and 1757 experimental status that originate from the IETF and have been 1758 approved by the IESG for publication. 1760 2. Requests for new option type value assignments from outside the 1761 IETF are only made through the publication of an IETF document, 1762 per 1) above. Note also that documents published as "RFC Editor 1763 contributions" [RFC3978] are not considered to be IETF documents. 1765 10. References 1767 10.1. Normative References 1769 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1770 Requirement Levels", BCP 14, RFC 2119, March 1997. 1772 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1773 IPv6 Specification", RFC 2473, December 1998. 1775 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1776 in IPv6", RFC 3775, June 2004. 1778 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1779 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1780 RFC 3948, January 2005. 1782 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 1783 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 1784 RFC 3963, January 2005. 1786 [RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting 1787 Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006. 1789 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1790 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1791 September 2007. 1793 10.2. Informative 1795 [I-D.ietf-mip6-bootstrapping-integrated-dhc] 1796 Chowdhury, K. and A. Yegin, "MIP6-bootstrapping for the 1797 Integrated Scenario", 1798 draft-ietf-mip6-bootstrapping-integrated-dhc-06 (work in 1799 progress), April 2008. 1801 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1802 of Explicit Congestion Notification (ECN) to IP", 1803 RFC 3168, September 2001. 1805 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 1806 August 2002. 1808 [RFC3519] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of 1809 Network Address Translation (NAT) Devices", RFC 3519, 1810 April 2003. 1812 [RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78, 1813 RFC 3978, March 2005. 1815 [RFC4140] Soliman, H., Castelluccia, C., El Malki, K., and L. 1816 Bellier, "Hierarchical Mobile IPv6 Mobility Management 1817 (HMIPv6)", RFC 4140, August 2005. 1819 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1820 for IPv6 Hosts and Routers", RFC 4213, October 2005. 1822 [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the- 1823 Network Tunneling", RFC 4459, April 2006. 1825 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 1826 (MOBIKE)", RFC 4555, June 2006. 1828 [RFC4977] Tsirtsis, G. and H. Soliman, "Problem Statement: Dual 1829 Stack Mobility", RFC 4977, August 2007. 1831 [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 1832 Bootstrapping in Split Scenario", RFC 5026, October 2007. 1834 Appendix A. Contributors 1836 This document reflects discussions and contributions from several 1837 people including (in alphabetical order): 1839 Vijay Devarapalli: vijay.devarapalli@azairenet.com 1841 James Kempf: kempf@docomolabs-usa.com 1843 Henrik Levkowetz: henrik@levkowetz.com 1845 Pascal Thubert: pthubert@cisco.com 1847 George Tsirtsis: G.Tsirtsis@Qualcomm.com 1849 Wakikawa Ryuji: ryuji@sfc.wide.ad.jp 1851 Author's Address 1853 Hesham Soliman (editor) 1854 Elevate Technologies 1856 Email: hesham@elevatemobile.com 1858 Full Copyright Statement 1860 Copyright (C) The IETF Trust (2008). 1862 This document is subject to the rights, licenses and restrictions 1863 contained in BCP 78, and except as set forth therein, the authors 1864 retain all their rights. 1866 This document and the information contained herein are provided on an 1867 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1868 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1869 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1870 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1871 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1872 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1874 Intellectual Property 1876 The IETF takes no position regarding the validity or scope of any 1877 Intellectual Property Rights or other rights that might be claimed to 1878 pertain to the implementation or use of the technology described in 1879 this document or the extent to which any license under such rights 1880 might or might not be available; nor does it represent that it has 1881 made any independent effort to identify any such rights. Information 1882 on the procedures with respect to rights in RFC documents can be 1883 found in BCP 78 and BCP 79. 1885 Copies of IPR disclosures made to the IETF Secretariat and any 1886 assurances of licenses to be made available, or the result of an 1887 attempt made to obtain a general license or permission for the use of 1888 such proprietary rights by implementers or users of this 1889 specification can be obtained from the IETF on-line IPR repository at 1890 http://www.ietf.org/ipr. 1892 The IETF invites any interested party to bring to its attention any 1893 copyrights, patents or patent applications, or other proprietary 1894 rights that may cover technology that may be required to implement 1895 this standard. Please address the information to the IETF at 1896 ietf-ipr@ietf.org.