idnits 2.17.1 draft-ietf-mext-nemo-v4traversal-03.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 1840. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1851. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1858. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1864. 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 (May 25, 2008) is 5814 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 1570, but not defined == Missing Reference: 'IPv4 ACK' is mentioned on line 1607, but not defined == Missing Reference: 'CERTREQ' is mentioned on line 1488, but not defined == Missing Reference: 'N' is mentioned on line 1619, but not defined == Missing Reference: 'KEi' is mentioned on line 1619, but not defined == Missing Reference: 'KEr' is mentioned on line 1623, 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 May 25, 2008 5 Expires: November 26, 2008 7 Mobile IPv6 Support for Dual Stack Hosts and Routers 8 draft-ietf-mext-nemo-v4traversal-03.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 November 26, 2008. 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 . . . . . . . . . . . . . . . . . . . . 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. Vanilla and TLV-header UDP Tunelling Formats . . . . . . . 20 70 5.1.1. Tunnelling Impacts on Transport and MTU . . . . . . . 22 71 5.2. NAT Detection . . . . . . . . . . . . . . . . . . . . . . 22 72 5.3. NAT Keepalives . . . . . . . . . . . . . . . . . . . . . . 24 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. 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). 257 For DNS lookup by name, the mobile node should be configured with the 258 name of the home agent. When the mobile node needs to discover a 259 home agent, it sends a DNS request with QNAME set to the configured 260 name. An example is "ha1.example.com". If a home agent has an IPv4 261 and IPv6 address, the corresponding DNS record should be configured 262 with both 'AAAA' and 'A' records. Accordingly, the DNS reply will 263 contain 'AAAA' and 'A' records. 265 For DNS lookup by service, the SRV record defined in [RFC5026] is 266 reused. For instance, if the service name is "mip6" and the protocol 267 name is "ipv6" in the SRV record, the mobile node SHOULD send a DNS 268 request with the QNAME set to "_mip6._ipv6.example.com". The 269 response should contain the home agent's FQDN(s) and may include the 270 corresponding 'AAAA' and 'A' records as well. 272 If multiple home agents reside on the home link, each configured with 273 a public IPv4 address, then the operation above applies. In case the 274 home agents are behind a NAT box, there are two options, 1) configure 275 a public IPv4 address for each home agent on the NAT box, 2) 276 configure one public address and make the home agents share the 277 public address. In either case, the correct DNS entries can be 278 configured. Another possible solution is to designate one home agent 279 on the home link for IPv4 traversal. The NAT device should associate 280 that home agent with the public IPv4 address configured on it for v4 281 traversal. In all cases above, both the 'AAAA' and 'A' records 282 returned for a particular name MUST correspond to the same physical 283 home agent; otherwise the mobile node will not be able to bind its 284 addresses correctly. 286 3.2. Mobile Prefix Solicitation and Advertisement 288 According to [RFC3775], the mobile node can send a Mobile Prefix 289 Solicitation and receive a Mobile Prefix Advertisement containing all 290 prefixes advertised on the home link. 292 A dual stack mobile node MAY send a Mobile Prefix Solicitation 293 message encapsulated in IPv4 (i.e., IPv6 in IPv4) in the case where 294 the mobile node has no access to IPv6 within the local network. 295 Securing these messages requires the mobile node to have a security 296 association with the home agent, using IPsec (AH or ESP) and based on 297 the mobile node's IPv4 care-of address as described in [RFC3775]. 298 Since the mobile node needs to encapsulate all IPv6 traffic sent to 299 the home agent into IPv4 while located in an IPv4-only visited 300 network, this SA would match all packets if the selectors were based 301 on the information in the outer header. That is, the SA selectors 302 being the protocol number (protocol is always IP in IP), as well as, 303 source and destination addresses are all common to all packets. If 304 this effect is not desired, the mobile node can base the SA on the 305 information in the inner header (i.e., using the home agent's IPv6 306 address, the mobile node's home address and the ICMP protocol 307 number). This security association would use transport mode ESP 308 protection. 310 3.3. Binding Management 312 A dual stack mobile node will need to update its home agent with its 313 care-of address. If a mobile node has an IPv4 and an IPv6 home 314 address, it will need to create a binding cache entry for each 315 address. The format of the IP packet carrying the binding update and 316 acknowledgement messages will vary depending on whether the mobile 317 node has access to IPv6 in the visited network. There are three 318 different scenarios to consider with respect to the visited network: 320 o The visited network has IPv6 connectivity and provides the mobile 321 node with a care-of address (in a stateful or stateless manner). 323 o The mobile node can only configure a globally unique IPv4 address 324 in the visited network. 326 o The mobile node can only configure a private IPv4 address in the 327 visited network. 329 3.3.1. Foreign Network Supports IPv6 331 In this case, the mobile node is able to configure a globally unique 332 IPv6 address. The mobile node will send a binding update to the IPv6 333 address of its home agent, as defined in [RFC3775]. The binding 334 update MAY include the IPv4 home address option introduced in this 335 document. After receiving the binding update, the home agent creates 336 two binding cache entries, one for the mobile node's IPv4 home 337 address, and another for the mobile node's IPv6 home address. Both 338 entries will point to the mobile node's IPv6 care-of address. Hence, 339 whenever a packet is addressed to the mobile node's IPv4 or IPv6 home 340 addresses, the home agent will tunnel it in IPv6 to the mobile node's 341 IPv6 care-of address included in the binding update. Effectively, 342 the mobile node establishes two different tunnels, one for its IPv4 343 traffic (IPv4 in IPv6) and one for its IPv6 traffic (IPv6 in IPv6) 344 with a single binding update. The security implications of this 345 mechanism are discussed in the security considerations section. 347 In this scenario, the only addition to [RFC3775] is the inclusion of 348 the IPv4 home address option in the binding update message. 350 After accepting the binding update and creating the corresponding 351 binding cache entries, the home agent MUST send a binding 352 acknowledgement to the mobile node as defined in [RFC3775]. In 353 addition, if the binding update included an IPv4 home address option, 354 the binding acknowledgement MUST include the IPv4 address 355 acknowledgment option as described later in this specification. This 356 option informs the mobile node whether the binding was accepted for 357 the IPv4 home address. If this option is not included in the binding 358 acknowledgement and the IPv4 home address option was included in the 359 binding update, the mobile node MUST assume that the home agent does 360 not support the IPv4 home address option and therefore SHOULD NOT 361 include the option in future binding updates to that home agent 362 address. 364 When a mobile node acquires both IPv4 and IPv6 care-of addresses at 365 foreign network, it SHOULD prioritize IPv6 care-of address for MIP6 366 binding registration. The mobile node MUST NOT register both IPv4 367 and IPv6 care-of addresses to its home agent. 369 3.3.2. Foreign Network Supports IPv4 Only 371 If the mobile node is in a foreign network that only supports IPv4, 372 it needs to detect whether a NAT is in its communication path to the 373 home agent. This is done while exchanging the binding update and 374 acknowledgement messages as shown later in this document. If no NAT 375 is detected between the mobile node and the home agent, the mobile 376 node assumes that it is in a foreign network that supports IPv4 377 public addresses. Otherwise, the mobile node assumes that private 378 addresses are used in the foreign network. Note that this assumption 379 is only valid for the purposes of the signaling presented in this 380 specification. A mobile node SHOULD NOT assume that its IPv4 address 381 is globally unique if a NAT device was not detected. The operations 382 of both cases are discussed below. 384 3.3.2.1. Foreign Network Supports IPv4 Only (Public Addresses 386 In this scenario the mobile node will need to tunnel IPv6 packets 387 containing the binding update to the home agent's IPv4 address. The 388 mobile node uses the IPv4 address it gets from the foreign network as 389 a source address in the outer header. The binding update will 390 contain the mobile node's IPv6 home address. However, since the 391 care-of address in this scenario is the mobile node's IPv4 address, 392 the mobile node MUST include its IPv4 care-of address in the IPv6 393 packet. The IPv4 address is represented in the IPv4 Care-of address 394 option defined in this specification. If the mobile node had an IPv4 395 home address, it MUST also include the IPv4 home address option 396 described in this specification. 398 After accepting the binding update, the home agent MUST create a new 399 binding cache entry for the mobile node's IPv6 home address. If an 400 IPv4 home address option were included, the home agent MUST create 401 another entry for that address. All entries MUST point to the mobile 402 node's IPv4 care-of address. Hence, all packets addressed to the 403 mobile node's home address(es) (IPv4 or IPv6) will be encapsulated in 404 an IPv4 header that includes the home agent's IPv4 address in the 405 source address field and the mobile node's IPv4 care-of address in 406 the destination address field. 408 After accepting the binding updates and creating the corresponding 409 entries, the home agent MUST send a binding acknowledgement as 410 specified in [RFC3775]. In addition, if the binding update included 411 an IPv4 home address option, the binding acknowledgement MUST include 412 the IPv4 address acknowledgment option as described later in this 413 specification. The binding acknowledgement is encapsulated to the 414 IPv4 care-of address, which was included in the source address field 415 of the IPv4 header encapsulating the binding update. 417 3.3.2.2. Foreign Network Supports IPv4 Only (Private Addresses 419 n this scenario the mobile node will need to tunnel IPv6 packets 420 containing the binding update to the home agent's IPv4 address. In 421 order to traverse the NAT device, IPv6 packets are tunneled UDP and 422 IPv4. The UDP port allocated for the home agent is TBA. 424 The mobile node uses the IPv4 address it gets from the visited 425 network as a source address in the IPv4 header. The binding update 426 will contain the mobile node's IPv6 home address. 428 After accepting the binding update, the home agent MUST create a new 429 binding cache entry for the mobile node's IPv6 home address. If an 430 IPv4 home address option were included, the home agent MUST create 431 another entry for that address. All entries MUST point to the mobile 432 node's IPv4 care-of address included in the source address of the 433 IPv4 header that encapsulated the binding update message. In 434 addition, the tunnel used MUST indicate UDP encapsulation for NAT 435 traversal. Hence, all packets addressed to the mobile node's home 436 address(es) (IPv4 or IPv6) will be encapsulated in UDP then 437 encapsulated in an IPv4 header that includes the home agent's IPv4 438 address in the source address field and the mobile node's IPv4 care- 439 of address in the destination address field. 441 After accepting the binding updates and creating the corresponding 442 entries, the home agent MUST send a binding acknowledgement as 443 specified in [RFC3775]. In addition, if the binding update included 444 an IPv4 home address option, the binding acknowledgement MUST include 445 the IPv4 address acknowledgment option as described later in this 446 specification. The binding acknowledgement is encapsulated in UDP 447 then IPv4 with the home agent's IPv4 address in the source address 448 field and the mobile node's IPv4 care-of address in the destination 449 field. The IPv4 address in the destination field of the IPv4 packet 450 is the source address received in the IPv4 header containing the 451 binding update message. The inner IPv6 packet will contain the home 452 agent's IPv6 address as a source address and the mobile node's IPv6 453 home address in the destination address field. 455 The mobile node needs to maintain the NAT bindings for its current 456 IPv4 care-of address. This is done through sending the binding 457 update regularly to the home agent. 459 3.4. Route Optimization 461 Route optimization, as specified in [RFC3775] will operate in an 462 identical manner for dual stack mobile nodes when they are located in 463 a visited network that provides IPv6 addresses to the mobile node. 464 However, when located in an IPv4-only network, route optimization 465 will not be possible due to the difficulty of performing the care-of 466 address test. Therefore, mobile nodes will need to communicate 467 through the home agent. 469 Route optimization will not be possible for IPv4 traffic. That is, 470 traffic addressed to the mobile node's IPv4 home address. This is 471 similar to using Mobile IPv4, therefore there is no reduction of 472 features resulting from using this specification. 474 3.5. Dynamic IPv4 Home Address Allocation 476 It is possible to allow for the mobile node's IPv4 home address to be 477 allocated dynamically. This is done by including 0.0.0.0 in the IPv4 478 home address option included in the binding update. The home agent 479 SHOULD allocate an IPv4 address to the mobile node and include it in 480 the IPv4 address acknowledgement option sent to the mobile node. In 481 this case, the lifetime of the binding is bound to the minimum of the 482 lifetimes of the IPv6 binding and the lease time of the IPv4 home 483 address. 485 4. Extensions And Modifications To Mobile IPv6 487 This section highlights the protocol and implementation additions 488 required to support this specification. 490 4.1. Binding Update Extensions 492 4.1.1. IPv4 Home Address Option 494 This option is included in the Mobility Header including the binding 495 update message sent from the mobile node to a home agent or Mobility 496 Anchor Point. The alignment requirement for this option is 4n. 498 0 1 2 3 499 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 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | Type | Length |Prefix-len |P| Reserved | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | IPv4 home address | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 Figure 1: IPv4 Home Address Option 508 Type 510 TBD 512 Length 514 6 516 Prefix-len 518 The length of the prefix allocated to the mobile node. If only a 519 single address is allocated, this field MUST be set to 32. In the 520 first binding update requesting a prefix, the field contains the 521 prefix length requested. However, in the following binding 522 updates, this field must contain the length of the prefix 523 allocated. A value of zero is invalid and MUST be considered an 524 error. 526 P 528 A flag indicating, when set, that the mobile node requests a 529 mobile network prefix. This flag is only relevant for new 530 requests, and must be ignored for binding refreshes. 532 Reserved 534 This field is reserved for future use. It MUST be set to zero by 535 the sender and ignored by the receiver. 537 IPv4 Home Address 539 The mobile node's IPv4 home address that should be defended by the 540 home agent. This field could contain any unicast IPv4 address 541 (public or private) that was assigned to the mobile node. The 542 value 0.0.0.0 is used to request an IPv4 home address from the 543 home agent. A mobile node may choose to use this option to 544 request a prefix by setting the address to the All Zeroes and 545 setting the P flag. The mobile node could then form an IPv4 home 546 address based on the allocated prefix. Alternatively, the mobile 547 node may use two different options, one for requesting an address 548 (Static or Dynamic) and another for requesting a prefix. 550 4.1.2. The IPv4 Care-of Address Option 552 This option is included in the Mobility Header including the binding 553 update message sent from the mobile node to a home agent or Mobility 554 Anchor Point. The alignment requirement for this option is 4n. 556 0 1 2 3 557 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 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | Type | Length | Reserved | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | IPv4 Care-of address | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 Figure 2: The IPv4 CoA Option 566 Type 568 TBD 570 Length 572 6 574 Reserved 576 This field is set to zero by the sender and ignored by the 577 receiver. 579 IPv4 Care-of Address 581 This field contains the mobile node's IPv4 care- of address. The 582 IPv4 care-of address is used when the mobile node is located in an 583 IPv4-only network. 585 4.1.3. The Binding Update Message Extensions 587 This specification extends the Binding Update message with two new 588 flags. The flags are shown and described below. 590 0 1 2 3 591 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 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | Sequence # | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 |A|H|L|K|M|R|F|T| Reserved | Lifetime | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 Figure 3: Binding Update message 600 F 602 When set, this flag indicates a request for forcing UDP 603 encapsulation regardless of whether a NAT is present on the path 604 between the mobile node and the home agent. 606 T 608 When set, this flag indicates that the mobile node requests the 609 use of the TLV-format for encapsulating IPv6 in IPv4. The TLV- 610 format is described later in this document. 612 4.2. Binding Acknowledgement Extensions 614 4.2.1. IPv4 Address Acknowledgement Option 616 This option is included in the Mobility Header including the binding 617 acknowledgement message sent from the home agent or Mobility Anchor 618 Point to the mobile node. This option indicates whether a binding 619 cache entry was created for the mobile node's IPv4 address. 620 Additionally, this option can include an IPv4 home address in the 621 case of Dynamic IPv4 home address configuration (i.e., if the 622 unspecified IPv4 address was included in the binding update). The 623 alignment requirement for this option is 4n. 625 0 1 2 3 626 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 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | Type | Length | Status |Pref-len |Res| 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 | IPv4 home address | 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 Figure 4: IPv4 Address Acknowledgement Option 635 Type 637 TBD 639 Length 641 6 643 Status 645 Indicates success or failure for the IPv4 home address binding. 646 Values from 0 to 127 indicate success. Higher values indicate 647 failure. 649 Pref-len 651 The prefix length of the address allocated. This field is only 652 valid in case of success and MUST be set to zero and ignored in 653 case of failure. This field overrides what the mobile node 654 requested (if not equal to the requested length). 656 Res 658 This field is reserved for future use. It MUST be set to zero by 659 the sender and ignored by the receiver 661 IPv4 Home Address 663 he IPv4 home address that the home agent will use in the binding 664 cache entry. This could be a public or private address. This 665 field MUST contain the mobile node's IPv4 home address. If the 666 address were dynamically allocated the home agent will add the 667 address to inform the mobile node. Otherwise, if the address were 668 statically allocated to the mobile node, the home agent will copy 669 it from the binding update message. 671 The following values are allocated for the Status field: 673 o 0 Success 675 o 128 Failure, reason unspecified 677 o 129 Administratively prohibited 679 o 130 Incorrect IPv4 home address 681 o 131 Invalid IPv4 address 683 o 132 Dynamic IPv4 home address assignment not available 685 o 133 Prefix allocation unauthorized 687 4.2.2. The NAT Detection Option 689 This option is sent from the home agent to the mobile node to 690 indicate whether a NAT was in the path. This option MAY also include 691 a suggested NAT binding refresh time for the mobile node. The 692 alignment requirement for this option is 4n. If a NAT is detected, 693 this option MUST be sent by the home agent. 695 0 1 2 3 696 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 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | Type | Length |F| Reserved | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | Refresh time | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 Figure 5: The NAT Detection Option 705 Type 707 TBD 709 Length 711 6 713 F 715 This flag indicates to the mobile node that UDP encapsulation is 716 required. When set, this flag indicates that the mobile node MUST 717 use UDP encapsulation even if a NAT is not located between the 718 mobile node and home agent. 720 Reserved 722 This field is reserved for future use. It MUST be set to zero by 723 the sender and ignored by the receiver. 725 Refresh Time 727 A suggested time (in seconds) for the mobile node to refresh the 728 NAT binding. If set to zero, it is ignored. If this field is set 729 to the all 1s it means that keepalives are not needed, i.e.,no NAT 730 was detected. 732 4.2.3. Extensions to the Binding Acknowledgement Message 734 This specification extends the binding acknowledgement message with a 735 new flag. The new flag is shown and described below. 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | Status |K|R|T| Reserved| 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | Sequence # | Lifetime | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 Figure 6: Binding Acknowledgement message 745 T 747 This flag indicates, when set, that the sender of the binding 748 acknowledgement supports the TLV- tunnel format. 750 5. Protocol operation 752 This section presents the protocol operation and processing for the 753 messages presented above. In addition, this section introduces the 754 NAT detection and traversal mechanism used by this specification. 756 5.1. Vanilla and TLV-header UDP Tunelling Formats 758 This specification allows the mobile node to use various tunnelling 759 formats depending on its location and the visited networ's 760 capabilities. The mobile node can tunnel IPv6 in IPv4, IPv4 in IPv6 761 or use UDP encapsulation to tunnel IPv6 in IPv4. Naturally, this 762 specification also supports tunnelling IPv6 in IPv6. 764 This speacification allows UDP-based tunnelling to be used between 765 the mobile node and its home agent or MAP using either vanilla UDP 766 encapsulation or TLV- header UDP encapsulation. A vanilla UDP 767 encapsulation format means the following order of headers: 769 IPv4 771 UDP 773 IP (v4 or v6) 775 Other headers 777 When using this format the receiver would parse the version field 778 following the UDP header in order to determine whether the following 779 header is IPv4 or IPv6. The rest of the headers are processed 780 normally. The above order of headers does not take IPsec headers 781 into account as they may be placed in different parts of the packet. 782 The above format MUST be supported by all implementations of this 783 specification and MUST always be used to send the binding update 784 message. 786 A TLV-header UDP encapsulation is represented by the following order 787 of headers: 789 IP (v4 or v6) 791 UDP 793 TLV-header 795 Other headers 797 The use of the TLV header is negotiated during the binding update/ 798 acknowledgement exchange. If the TLV header is agreed upon, the 799 receiver of the TLV-header UDP encapsulated packet expects the TLV- 800 header to follow UDP. The TLV header contains the type of the 801 following message and its length. The Type field MUST NOT be 802 assigned the values 4 or 6 to make sure that the receiver can tell 803 the difference between the Type field and the IP version field in a 804 packet that contains an IP header after UDP. Hence, the TLV header 805 can carry traffic other than IP. 807 The mobile node negotiates the format for tunnelling payload traffic 808 during the binding exchange. If a mobile node prefers to use the 809 TLV- header UDP encapsulation, it sets the T flag in the binding 810 update sent to the home agent or MAP. If the receiver of the binding 811 update supports the TLV-header format, it SHOULD set the T flag in 812 the binding acknowledgement message. Otherwise, the T flag is 813 cleared. The setting of the T flag in the binding acknowledgement 814 indicates to the mobile node that it must use the TLV-header UDP 815 encapsulation format for all packets sent for the duration of the 816 binding or until a new binding update is sent. Each binding update 817 may renegotiate the tunnelling format. To avoid interoperability 818 issues, the sender of the binding acknowledgement MUST NOT set the T 819 flag unless it was set in the binding update sent from the mobile 820 node. 822 The TLV-header format is shown below. 824 0 1 2 3 825 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 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 | Type | Length | Reserved | 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 Figure 7: TLV-header format 832 Type 834 This field indicates the type of the payload following this 835 header. 837 Length 839 This field indicates the length of the payload following the 840 header, excluding the TLV-header itself. 842 Reserved 843 This field MUST be set to zero by the sender and ignored by the 844 receiver. 846 The following value is assigned to the Type field, other values may 847 be assigned in future: 849 1 GRE 851 In addition to UDP-based tunnelling, this specification allows for 852 standard IP in IP tunnelling as defined in [RFC2473] and [RFC4213]. 853 This can take place by tunnelling IPv4 in IPv6 or IPv6 in IPv4. 854 However, whenever a NAT is detected, the mobile node will default to 855 UDP-based encapsulation. The mobile node can request to always use 856 UDP encapsulation by setting the F flag in the binding update. If 857 the home agent does not agree to the request, it MUST reject the 858 binding update with the new Status code: 860 144 Cannot force UDP encapsulation 862 Alternatively, the home agent can force UDP encapsulation by setting 863 the F flag in the NAT detection option included in the binding 864 acknowledgement. 866 5.1.1. Tunnelling Impacts on Transport and MTU 868 Changing the tunnel format may occur due to movement of the mobile 869 node from one network to another. This can have impacts on the link 870 and path MTU, which may affect the amount of bandwidth available to 871 the applications. It is recommended that the mobile node use PLMTUD 872 as specified in [RFC4459]. 874 To accomodate traffic that uses Explicit Congestion Notification 875 (ECN), it is RECOMMENDED that the ECN information is copied between 876 the inner and outer header as defined in [RFC3168]. 878 5.2. NAT Detection 880 NAT detection is done when the initial binding update message is sent 881 from the mobile node to the home agent. When located in an IPv4-only 882 foreign link, the mobile node sends the binding update message 883 encapsulated in UDP and IPv4. The source address of the IPv6 packet 884 is the mobile node's IPv6 home address. The destination address is 885 the IPv6 address of the home agent. The IPv4 header contains the 886 IPv4 care-of address in the source address field and the IPv4 address 887 of the home agent in the destination address field. 889 When the home agent receives the encapsulated binding update it 890 compares the IPv4 address of the source address field in the IPv4 891 header with the IPv4 address included in the IPv4 care-of address 892 option. If the two addresses match, no NAT device was in the path. 893 Otherwise, a NAT device was in the path and the NAT detection option 894 is included in the binding acknowledgement. The binding 895 acknowledgement, and all future packets, are then encapsulated in UDP 896 and IPv4. The source address in the IPv4 header is the IPv4 address 897 of the home agent. The destination address is the IPv4 address 898 received in the IPv4 header encapsulating the binding update (this 899 address will be different from the IPv4 care-of address when a NAT is 900 in the path). The source port in the packet is the home agent's 901 source port. The destination port is the source port received in the 902 binding update message. Note that the home agent stores the port 903 numbers and associates them with the mobile node's tunnel in order to 904 forward future packets. 906 Upon receiving the binding acknowledgement with the NAT detection 907 option, the mobile node sets the tunnel to the home agent to UDP 908 encapsulation. Hence, all future packets to the home agent are 909 tunneled in UDP and IPv4. For all tunneled IPv6 packets, the source 910 address in the IPv6 header is the mobile node's IPv6 home address and 911 the destination address is the correspondent node's IPv6 address. 912 All tunneled IPv4 packets will contain the mobile node's IPv4 home 913 address in the source address field of the inner IPv4 packet and the 914 correspondent node's IPv4 address in the destination address field. 915 The outer IPv4 header is the same whether the inner packet is IPv4 or 916 IPv6. 918 If no NAT device was detected in the path between the mobile node and 919 the home agent then IPv6 packets are tunneled in an IPv4 header, 920 unless the home agent forces UDP encapsulation using the F flag. The 921 content of the inner and outer headers are identical to the UDP 922 encapsulation case. 924 A mobile node MUST always tunnel binding updates in UDP when located 925 in an IPv4-only network. Essentially, this process allows for 926 perpetual NAT detection. Similarly, the home agent MUST encapsulate 927 binding acknowledgements in a UDP header whenever the binding update 928 is encapsulated in UDP. 930 In conclusion, the packet formats for the binding update and 931 acknowledgement messages are shown below: 933 Binding update received by the home agent: 935 IPv4 header (src=V4ADDR, dst=HA_V4ADDR) 937 UDP header 938 IPv6 header (src=V6HOA, dst=HAADDR) 940 ESP Header 942 Mobility header 944 BU [IPv4 HAO] 946 IPv4 CoA option 948 Where V4ADDR is either the IPv4 care-of address or the address 949 provided by the NAT device. V6HOA is the IPv6 home address of the 950 mobile node. The binding update MAY also contain the IPv4 home 951 address option IPv4 HAO. 953 Binding acknowledgement sent by the home agent: 955 IPv4 header (src= HA_V4ADDR, dst=V4ADDR) 957 UDP Header 959 IPv6 header (src=HAADDR, dst=V6HOA) 961 ESP Header 963 Mobility Header 965 BA ([IPv4 ACK], NAT DET) 967 Where V6HOA is IPv6 home address of the mobile node. The IPv4 ACK is 968 the IPv4 address acknowledgement option, which is only included if 969 the IPv4 home address option were present in the BU. The NAT DET is 970 the NAT detection option, which MUST be present in the binding 971 acknowledgement message if the binding update was encapsulated in 972 UDP. 974 5.3. NAT Keepalives 976 If a NAT is detected, the mobile node will need to refresh the NAT 977 bindings in order to be reachable from the home agent. NAT bindings 978 can be refreshed through sending and receiving traffic encapsulated 979 in UDP. However, if the mobile node is not active, it will need to 980 periodically send a message to the home agent in order to refresh the 981 NAT binding. This can be done using the binding update message. The 982 binding update/acknowledgement pair will ensure that the NAT bindings 983 are refreshed in a reliable manner. There is no way for the mobile 984 node to know the exact time of the NAT binding. The default time 985 suggested in this specification is NATKATIMEOUT. If the home agent 986 suggests a different refresh period in the binding acknowledgement, 987 the mobile node SHOULD use the value suggested by the home agent. 989 If the refresh time in the NAT detection option in the binding 990 acknowledgement is set to the all 1s, the mobile node need not send 991 messages to refresh the NAT binding. However, the mobile node may 992 still be required to encapsulate traffic in UDP. This scenario may 993 take place when a NAT is not detected, but the home agent still 994 requires the mobile node to use UDP encapsulation. 996 It should be noted that a mobile node that does not need to be 997 reachable (i.e., only cares about the session continuity aspect of 998 Mobile IP) does not need to refresh NAT binding. In this case, the 999 mobile node would only be able to initiate communication with other 1000 nodes. However, this is likely to imply that the mobile node will 1001 need to send a binding update before initiating communication after a 1002 long idle period as it is likely to be assigned a different port and 1003 IPv4 address when it initiates communication. Hence, an 1004 implementation may choose, for the sake of simplicity, to always 1005 maintain the NAT bindings even when it does not need reachability. 1007 5.4. Mobile Node Operation 1009 In addition to the operations specified in [RFC3775] and [RFC3963], 1010 this specification requires mobile nodes to be able to support an 1011 IPv4 home address. 1013 When sending an IPv6 packet containing a binding update while 1014 connected to an IPv4-only access network, mobile nodes MUST ensure 1015 the following: 1017 o The IPv6 packet is encapsulated in the vanilla UDP encapsulation 1018 format. 1020 o The source address in the IPv4 header is the mobile node's IPv4 1021 care-of address. 1023 o The destination address in the IPv4 header is the home agent's 1024 IPv4 address. 1026 o The source address in the IPv6 header is the mobile node's IPv6 1027 home address. 1029 o The IPv4 home address option MAY be included in the mobility 1030 header. This option contains the IPv4 home address. If the 1031 mobile node did not have a static home address it MAY include the 1032 unspecified IPv4 address, which acts as a request for a dynamic 1033 IPv4 home address. Alternatively, one or more IPv4 home address 1034 options may be included with requests for IPv4 prefixes (i.e., 1035 with the P flag set). 1037 o If the mobile node wishes to use UDP encapsulation only, it should 1038 set the F flag in the binding update message. 1040 o If the mobile node prefers to use the TLV-header format, it should 1041 set the T flag in the binding update. 1043 o The IPv6 packet MUST be authenticated as per [RFC3775], based on 1044 the mobile node's IPv6 home address. 1046 When sending a binding update from a visited network that supports 1047 IPv6, the mobile node MUST follow the rules specified in [RFC3775]. 1048 In addition, if the mobile node has an IPv4 home address or needs 1049 one, it MUST include the IPv4 home address option in the mobility 1050 header. If the mobile node already has a static IPv4 home address, 1051 this address MUST be included in the IPv4 home address option. 1052 Otherwise, if the mobile node needs a dynamic IPv4 address, it MUST 1053 include the IPv4 0.0.0.0 address in the IPv4 home address option. 1055 When the mobile node receives a binding acknowledgement from the home 1056 agent, it follows the rules in [RFC3775] and [RFC3963]. In addition, 1057 the following actions MUST be made: 1059 o If the status field indicated failure with error code 144, the 1060 mobile node MAY resend the binding update without setting the F 1061 flag. 1063 o If the mobility header includes an IPv4 address acknowledgement 1064 option indicating success, the mobile node should create two 1065 entries in its binding update list, one for the IPv6 home address 1066 and another for the IPv4 home address. 1068 o If the NAT detection option were present, the mobile node MUST 1069 tunnel future packets in UDP and IPv4. This MUST be indicated in 1070 the binding update list. 1072 o If no IPv4 address acknowledgement option were present, and an 1073 IPv4 home address option was present in the binding update, the 1074 mobile node MUST only create one binding update list entry for its 1075 IPv6 home address. The mobile node MAY include the IPv4 home 1076 address option in future binding updates. 1078 o If an IPv4 address acknowledgement option were present and it 1079 indicates failure for the IPv4 home address binding, the mobile 1080 node MUST NOT create an entry for that address in its binding 1081 update list. The mobile node MAY include the IPv4 home address 1082 option in future binding updates. 1084 o If the T flag was set in the binding update and the binding 1085 acknowledgement included the T flag set, the mobile node MUST use 1086 the TLV-header UDP encapsulation format. 1088 5.4.1. Sending Packets from a Visited Network 1090 When the mobile node is located in an IPv6-enabled network it sends 1091 and receives IPv6 packets as described in [RFC3775]. IPv4 traffic is 1092 encapsulated in IPv6 packets to the home agent. 1094 When the mobile node is located in an IPv4 only network, it will send 1095 IPv6 packets to its home agent according to the following format: 1097 IPv4 header (src=V4CoA, dst=HA_V4ADDR) 1099 [UDP Header] 1101 [TLV Header] 1103 IPv6 header (src=V6HoA, dst=CN) 1105 Upper Layer protocols 1107 Where the UDP header is only used if a NAT were detected between the 1108 mobile node and the home agent, or if the home agent forced UDP 1109 encapsulation. V4CoA is the IPv4 care-of address configured by the 1110 mobile node in the visited network. 1112 Similarly, IPv4 packets are sent according to the following format: 1114 IPv4 header (src=V4CoA, dst=HA_V4ADDR) 1116 [UDP Header] 1118 [TLV Header] 1120 IPv4 header (src=V4HoA, dst=V4CN) 1122 Upper Layer protocols 1124 Where the UDP header is only used if a NAT were detected between the 1125 mobile node and the home agent, or if the home agent forced UDP 1126 encapsulation. 1128 If the mobile node and the home agent negotiated the use of the TLV- 1129 header UDP encapsulation format, then the TLV-header would be used 1130 after the UDP header. 1132 5.4.2. Movement Detection in IPv4-only Networks 1134 [RFC3775] describes movement detection mostly based on IPv6-specific 1135 triggers and Neighbor Discovery [RFC4861] information. These 1136 triggers would not be available in an IPv4-only network. Hence, a 1137 mobile node located in an IPv4-only network SHOULD use [RFC4436] for 1138 guidance on movement detection mechanisms in IPv4-only networks. 1140 5.5. Home agent operation 1142 In addition to the home agent specification in [RFC3775] and 1143 [RFC3963], the home agent needs to be able to process the IPv4 home 1144 address option and generate the IPv4 address acknowledgement option. 1145 Both options are included in the mobility header. Furthermore, the 1146 home agent MUST be able to detect the presence of a NAT device and 1147 indicate that in the NAT detection option included in the binding 1148 acknowledgement. 1150 A home agent must also act as a proxy for address resolution in IPv4 1151 for the registered IPv4 home addresses of mobile nodes it is serving. 1152 Moreover, the administrative domain of the home agent is responsible 1153 for advertising the routing information of registered IPv4 mobile 1154 network prefixes of the mobile nodes. 1156 In order to comply with this specification, the home agent MUST be 1157 able to find the IPv4 home address of a mobile node when given the 1158 IPv6 home address. That is, given an IPv6 home address, the home 1159 agent MUST store the corresponding IPv4 home address if a static one 1160 is present. If a dynamic address were requested by the mobile node, 1161 the home agent MUST store that address (associated with the IPv6 home 1162 address) after it's allocated to the mobile node. 1164 When the home agent receives a binding update encapsulated in UDP and 1165 containing the IPv4 home address option, it needs to follow all the 1166 steps in [RFC3775] and [RFC3963]. In addition, the following checks 1167 MUST be done: 1169 o If the IPv4 care-of address in the IPv4 CoA option is not the same 1170 as the IPv4 address in the source address in the IPv4 header then 1171 a NAT was in the path. This information should be flagged for the 1172 binding acknowledgement. 1174 o If the F flag in the binding update were set, the home agent needs 1175 to determine whether it accepts forcing UDP encapsulation. If it 1176 does not, the binding acknowledgement is sent with error code 144. 1177 UDP encapsulation MUST NOT be used when the mobile node is located 1178 in an IPv6-enabled link. 1180 o If the T flag was set in the binding update, the home agent needs 1181 to determine whether it can accept the TLV-header encapsulation 1182 format. If it does, it should set the T flag in the binding 1183 acknowledgement. Otherwise, the home agent MUST NOT set the T 1184 flag in the binding acknowledgement. 1186 o If the IPv4 home address option contains a valid unicast IPv4 1187 address, the home agent MUST check that this address is allocated 1188 to the mobile node that has the IPv6 home address included in the 1189 home address option. The same MUST be done for an IPv4 prefix. 1191 o If the IPv4 home address option contained the unspecified IPv4 1192 address, the home agent SHOULD dynamically allocate an IPv4 home 1193 address to the mobile node. If none is available, the home agent 1194 MUST return error code 132 in the status field of the IPv4 address 1195 acknowledgement option. If a prefix were requested, the home 1196 agent MUST allocate a prefix with the requested length; otherwise 1197 the home agent MUST indicate failure of the operation with the 1198 appropriate error code. 1200 o If the binding update is accepted for the IPv4 home address, the 1201 home agent creates a binding cache entry for the IPv4 home 1202 address/prefix. The home agent MUST include an IPv4 1203 acknowledgement option in the mobility header containing the 1204 binding acknowledgement. 1206 o If the binding update is accepted for both IPv4 and IPv6 home 1207 addresses, the home agent creates separate binding cache entries, 1208 one for each home address. The care-of address is the one 1209 included in the binding update. If the care-of address is an IPv4 1210 address, the home agent MUST setup a tunnel to the IPv4 care-of 1211 address of the mobile node. 1213 When sending a binding acknowledgement to the mobile node, the home 1214 agent constructs the message according to [RFC3775] and [RFC3963]. 1215 Note that the routing header MUST always contain the IPv6 home 1216 address as specified in [RFC3775]. 1218 If the care-of address of the mobile node were an IPv4 address, the 1219 home agent includes the mobile node's IPv6 home address in the 1220 destination address field in the IPv6 header. If a NAT were 1221 detected, the home agent MUST then encapsulate the packet in UDP and 1222 an IPv4 header. The source address is set to the home agent's IPv4 1223 address and the destination address is set to the address received in 1224 the source address of the IPv4 header encapsulating the binding 1225 update. 1227 After creating a binding cache entry for the mobile node's home 1228 addresses, all packets sent to the mobile node's home addresses are 1229 tunneled by the home agent to the mobile node's care-of address. If 1230 a NAT were detected, packets are encapsulated in UDP and IPv4. 1231 Otherwise, if the care-of address is an IPv4 address, and no NAT were 1232 detected, packets are encapsulated in an IPv4 header unless UDP 1233 encapsulation is forced by the home agent. 1235 5.5.1. Sending Packets to the Mobile Node 1237 The home agent follows the rules specified in [RFC3775] for sending 1238 IPv6 packets to mobile nodes located in IPv6 networks. When sending 1239 IPv4 packets to When mobile nodes in an IPv6 network, the home agent 1240 must encapsulate the IPv4 packets in IPv6. 1242 When sending IPv6 packets to a mobile node located in an IPv4 1243 network, the home agent must follow the format negotiated in the 1244 binding update/acknowledgement exchange. In the absence of a 1245 negotiated format, the default format that MUST be supported by all 1246 implementations is: 1248 IPv4 header (src= HA_V4ADDR, dst= V4ADDR) 1250 UDP Header 1252 IPv6 header (src=CN, dst= V6HoA) 1254 Upper layer protocols 1256 Where the UDP header is only included if a NAT were detected between 1257 the mobile node and the home agent, or if the home agent forced UDP 1258 encapsulation. V4ADDR is the IPv4 address received in the source 1259 address field of the IPv4 packet containing the binding update. 1261 When sending IPv4 packets to a mobile node located in an IPv4 1262 network, the home agent must follow the format negotiated in the 1263 binding update/acknowledgement exchange. In the absence of a 1264 negotiated format, the default format that MUST be supported by all 1265 implementations is: 1267 IPv4 header (src= HA_V4ADDR, dst= V4ADDR) 1269 [UDP Header] 1271 IPv4 header (src=V4CN, dst= V4HoA) 1273 Upper layer protocols 1275 Where the UDP header is only included if a NAT were detected between 1276 the mobile node and home agent, or if the home agent forced UDP 1277 encapsulation. 1279 5.6. Correspondent Node Operation 1281 This specification has no impact on IPv4 or IPv6 correspondent nodes. 1283 6. Security Considerations 1285 This specification allows a mobile node to send one binding update 1286 for its IPv6 and IPv4 home addresses. This is a slight deviation 1287 from [RFC3775] which requires one binding update per home address. 1288 However, like [RFC3775], the IPsec security association needed to 1289 authenticate the binding update is still based on the mobile node's 1290 IPv6 home address. Therefore, in order to authorize the mobile 1291 node's IPv4 home address binding, the home agent MUST store the IPv4 1292 address corresponding to the IPv6 address that is allocated to a 1293 mobile node. Therefore, it is sufficient for the home agent to know 1294 that the IPsec verification for the packet containing the binding 1295 update was valid provided that it knows which IPv4 home address is 1296 associated with which IPv6 home address. Hence, the security of the 1297 IPv4 home address binding is the same as the IPv6 binding. 1299 In effect, associating the mobile node's IPv4 home address with its 1300 IPv6 home address moves the authorization of the binding update for 1301 the IPv4 address to the Mobile IPv6 implementation, which infers it 1302 from the fact that mobile node has an IPv6 home address and the right 1303 credentials for sending an authentic binding update for the IPv6 1304 address. 1306 In cases where this specification is used for NAT traversal, it is 1307 important to note that it has the same vulnerabilities associated 1308 with [RFC3519]. An attacker is able to hijack the mobile node's 1309 session with the home agent if it can modify the contents of the 1310 outer IPv4 header. The contents of the header are not authenticated 1311 and there is no way for the home agent to verify their validity. 1312 Hence, a man in the middle attack where a change in the contents of 1313 the IPv4 header can cause a legitimate mobile node's traffic to be 1314 diverted to an illegitimate receiver independently of the 1315 authenticity of the binding update message. 1317 In this specification, the binding update message MUST be protected 1318 using ESP transport mode. When the mobile node is located in an 1319 IPv4- only network, the binding update message is encapsulated in UDP 1320 as described earlier. However, UDP MUST NOT be used to encapsulate 1321 the binding update message when the mobile node is located in an 1322 IPv6- enabled network. If protection of payload traffic is needed 1323 when the mobile node is located in an IPv4-only network, 1324 encapsulation is done using tunnel mode ESP over port 4500 as 1325 described in [RFC3948]. During the IKE negotiation with the home 1326 agent, if the mobile node and home agent support the use of port 1327 4500, the mobile node MUST establish the security association over 1328 port 4500, regardless of the presence of a NAT. This is done to 1329 avoid the switching between ports 500 and 4500 and the potential 1330 traffic disruption resulting from this switch. 1332 Handovers within private IPv4 networks or from IPv6 to IPv4 networks 1333 will have impacts on the security association between the mobile node 1334 and the home agent. The following section presents the expected 1335 behaviour of the mobile node and home agent in those situations. The 1336 details of the IKE negotiations and messages are illustrated in 1337 Section 6.2 1339 6.1. Handover Interactions for IPsec and IKE 1341 After the mobile node detects movement it configures a new care-of 1342 address. If the mobile node is in an IPv4-only network, it removes 1343 binding update list entries for correspondent nodes since route 1344 optimisation cannot be supported. This may cause inbound packet 1345 losses as remote correspondent node are unaware of such movement. To 1346 avoid confusion in the correspondent node, the mobile node SHOULD 1347 deregister its binding with each correspondent node by sending a 1348 deregistration binding update. The deregistration binding update 1349 message is tunnelled to the home agent and onto the correspondent 1350 node. This is done after the mobile node updates the home agent with 1351 its new location as discussed below. 1353 The mobile node sends the binding update message to the home agent. 1354 If the mobile node is in an IPv6-enabled network, the binding update 1355 is sent without IPv4/UDP encapsulation. If the mobile node is in an 1356 IPv4-only network, then after IPsec processing of the BU message, it 1357 encapsulates the BU in UDP/IPv4 as discussed in sections 5.2 and 5.4. 1358 In order to be able to send the binding update while in an IPv4-only 1359 network, the mobile node needs to use the new IPv4 care-of address in 1360 the outer header, which is different from the care-of address used in 1361 the existing tunnel. This should be done without permanently 1362 updating the tunnel within the mobile node's implementation in order 1363 to allow the mobile node to receive packets on the old care-of 1364 address until the binding acknowledgement is received. The method 1365 used to achieve this effect is implementation dependent and is 1366 outside the scope of this specification. This implies that the IP 1367 forwarding function (which selects the interface or tunnel through 1368 which a packet is sent) is not based solely on the destination 1369 address: some IPv6 packets destined to the home agent are sent via 1370 the existing tunnel, while BUs are sent using the new care-of 1371 address. Since BUs are protected by IPsec, the forwarding function 1372 cannot necessarily determine the correct treatment from the packet 1373 headers. Thus, the DSMIPv6 implementation has to attach additional 1374 information to BUs, and this information has to be preserved after 1375 IPsec processing and made available to the forwarding function, or 1376 additional DSMIP processing added to the forwarding function. 1377 Depending on the mobile node's implementation, meeting this 1378 requirement may require changes to the IPsec implementation. 1380 Upon receiving the binding update message encapsulated in UDP/IPv4, 1381 the home agent processes it as follows. In order to allow the 1382 DSMIPv6 implementation in the home agent to detect the presence of a 1383 NAT on the path to the mobile node, it needs to compare the outer 1384 IPv4 source address with the IPv4 address in the IPv4 care-of address 1385 option. This implies that the information in the outer header will 1386 be preserved after IPsec processing and made available to the DSMIPv6 1387 implementation in the home agent. Depending on the home agent's 1388 implementation, meeting this requirement may require changes to the 1389 IPsec implementation. 1391 The home agent updates its tunnel mode security association to 1392 include the mobile node's care-of address as the remote tunnel header 1393 address, and 4500 as the port number. The IPv4 address and port 1394 number are likely to be wrong; the mobile node provides the correct 1395 information in a separate exchange as described below. When the 1396 mobile node is located in a private IPv4 network (which is detected 1397 as described above), the new address and port number are allocated by 1398 the NAT. The home agent will also enable or disable UDP 1399 encapsulation for outgoing ESP packets for the purpose of NAT 1400 traversal. 1402 If the Key Management Mobility Capability (K) bit was set in the 1403 binding update, and the home agent supports this feature, the home 1404 agent updates its IKE security associations to include the mobile 1405 node's care-of address as the peer address and 4500 as the port 1406 number. The home agent may also need to change NAT traversal fields 1407 in the IKE_SA to enable the dyanmic update of the IP address and port 1408 number based on the reception of authenticated IKE messages, or 1409 authenticated packets using tunnel mode ESP. The dynamic updates are 1410 described in section 2.23 of RFC 4306. As described above, when the 1411 mobile node is located in a private IPv4 network, the address and 1412 port number used for IPsec and IKE traffic is not yet known by the 1413 home agent at this point. 1415 The mobile node updates the IKE SA in one of two ways. If the K flag 1416 was set in the binding acknowledgement message, the mobile node 1417 SHOULD send an empty informational message, which results in the IKE 1418 module in the home agent to dynamically update the SA information. 1419 The IKE implementation in the home agent is REQUIRED to support this 1420 feature. Alternatively, the IKE SA should be re-negotiated. Note 1421 that updating the IKE SA MUST take place after the mobile node has 1422 sent the binding update and received the acknowledgement from the 1423 home agent. 1425 It is important to note that the mobile node's IPv4 care-of address 1426 seen by the DSMIPv6 module in the home agent upon receiving the 1427 binding update may differ from the IPv4 care-of address seen by the 1428 IKE module and the care-of address used for forwarding IPsec tunnel 1429 mode traffic. Hence, it is probable that different modules in the 1430 home agent will have a different care-of address that should be used 1431 for encapsulating traffic to the mobile node. 1433 After successfully processing the binding update, the home agent 1434 sends the binding acknowledgement to the mobile node's care-of 1435 address as received in the outer header of the packet containing the 1436 binding update. Note that if the BU was rejected, the BAck is sent 1437 to the same address where the BU was received from. This may require 1438 special treatment in IP forwarding and/or IPsec processing which 1439 resembles sending of BUs in the mobile node (described above). 1441 Upon receiving the binding acknowledgement, the mobile node updates 1442 its local tunnel mode Security Association information to include the 1443 tunnel header IP source address, which is the the mobile node's 1444 address and the tunnel header IP destination, which is the home 1445 agent's address. The mobile node may also need to enable or disable 1446 UDP encapsulation for outgoing ESP packets for the purpose of NAT 1447 traversal and the sending of keep alives. 1449 The mobile node MAY use [RFC4555] to update its IKE SA with the home 1450 agent. Using MOBIKE requires negotiating this capability with the 1451 home agent when establishing the SA. In this case, the mobile node 1452 and the home agent MUST NOT update their IPsec SAs locally as this 1453 step is performed by MOBIKE. Furthermore, the use of MOBIKE allows 1454 the mobile node to update the SA independently of the binding update 1455 exchange. Hence, there is no need for the mobile node to wait for a 1456 binding acknowledgement before performing MOBIKE. The use of MOBIKE 1457 is OPTIONAL in this specification. 1459 6.2. IKE negotiation messages between the mobile node and Home Agent 1461 This specification defines a number of possible data encapsulation 1462 formats depending on the mobile node's connectivity to the visited 1463 network. When connected to an IPv6-enabled network, the tunnelling 1464 formats are clear. However, when connected to an IPv4-only network, 1465 care should be taken when negotiationg the IKE association and the 1466 consequential tunnelling formats used for secure and insecure 1467 traffic. This section illustrates the IKE message exchange between 1468 the mobile node and home agent when the mobile node is located in an 1469 IPv4-only network. Two different IKE negotiations are considered: 1471 o IKEv2 operation for securing DSMIPv6 Signaling. 1473 o IKEv2 operation for securing Data over IPv4 1475 6.2.1. IKEv2 Operation for Securing DSMIPv6 Signaling 1477 A mobile node connected to an IPv4-only network SHOULD follow the 1478 procedures described below in order to establish an SA for the 1479 protection of binding update and binding acknowledgement messages. 1481 Mobile Node Home Agent 1482 ----------- ---------- 1483 IPv4(source_addr=V4ADDR, dest_addr=HAADDR) 1484 UDP (500, 500) HDR, SAi1, KEi, Ni 1485 NAT-D, NAT-D --> 1487 <- IPv4(source_addr=HAADDR, dest_addr=V4ADDR) 1488 UDP(500,X) HDR, SAr1, KEr, Nr, [CERTREQ] 1489 NAT-D, NAT-D 1491 IPv4(source_addr=V4ADDR, dest_addr=HAADDR) 1492 UDP (4500,4500) HDR, SK 1493 {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, N(USE_TRANSPORT_MODE), 1494 SAi2, TSi, TSr} 1495 --> 1497 <-- IPv4(source_addr=HAADDR, dest_addr=V4ADDR) 1498 UDP (4500,Y) HDR, SK 1499 {IDr, [CERT,] AUTH, N(USE_TRANSPORT_MODE), 1500 SAr2, TSi, TSr} 1502 The corresponding SPD entries are shown below. 1504 Mobile node SPD-S: 1506 IF local_address = home_address_1 & 1508 remote_address = home_agent_1 & 1510 proto = MH & local_mh_type = BU & remote_mh_type = BAck Then use 1511 SA ESP transport mode 1513 Initiate using IDi = user_1 to address home_agent_1 1515 Home Agent SPD-S: 1517 F local_address = home_agent_1 & 1519 remote_address = home_address_1 & 1520 proto = MH & local_mh_type = BAck & remote_mh_type = BU Then use 1521 SA ESP transport mode 1523 where home_address_1 is the mobile node's registered IPv6 home 1524 address and home_agent_1 is the IP address of the home agent 1526 The above should result in BU/BA messages with the following BU 1527 received by the home agent. 1529 Pv4 header (src=V4ADDR, dst=HA_V4ADDR) 1531 UDP header (sport=Z, dport=DSMIPv6) 1533 IPv6 header (src=V6HOA, dst=HAADDR) 1535 ESP Header in Transport Mode 1537 Mobility header 1539 BU [IPv4 HAO] 1541 IPv4 CoA option 1543 (+ other as needed) 1545 At the home agent, following UDP de-capsulation, the binding update 1546 is delivered to the IPsec module as shown below: 1548 IPv6 header (src=V6HOA, dst=HAADDR) 1550 ESP Header in Transport Mode 1552 Mobility header 1554 BU [IPv4 HAO] 1556 IPv4 CoA option 1558 (+other as needed) 1560 In addition, V4ADDR and the sport (Z) need to be passed with the 1561 packet to ensure correct processing. 1563 Following IPsec processing, the binding update is delivered to the 1564 DSMIPv6 home agent module as follows: 1566 IPv6 header (src=V6HOA, dst=HAADDR) 1568 Mobility Header 1570 BU [IPv4 HAO] 1572 IPv4 CoA option 1574 (+other as needed) 1576 In addition, V4ADDR and the sport (Z) need to be passed with the 1577 packet to ensure correct processing. 1579 The binding acknowledgement sent by the home agent module to the 1580 IPsec module is as follows: 1582 IPv6 header (src=HAADDR, dst=V6HOA) 1584 Mobility Header 1586 BA ([IPv4 ACK], NAT DET) 1588 (+ other as needed) 1590 In addition, V4ADDR, the sport from the BU (Z), and aindication that 1591 vanilla UDP encapsulation must be used, need to be passed with the 1592 packet to ensure correct processing. 1594 The binding acknowledgement sent by the home agent to the mobile node 1595 is as follows: 1597 IPv4 header (src= HA_V4ADDR, dst=V4ADDR) 1599 UDP Header (sport=DSMIPv6, dport=Z) 1601 IPv6 header (src=HAADDR, dst=V6HOA) 1603 ESP Header in Transport Mode 1605 Mobility Header 1607 BA ([IPv4 ACK], NAT DET) 1609 6.2.2. IKEv2 Operation for Securing Data over IPv4 1611 To secure data traffic when the mobile node is located in an IPv4- 1612 only network, the mobile node MUST establish a child_SA for that 1613 purpose. The procedure is as follows: 1615 Mobile Node Home Agent 1616 ----------- ---------- 1617 IPv4(source_addr=V4ADDR, dest_addr=HAADDR) 1618 UDP (4500,4500) < non-ESP Marker > HDR, SK 1619 {[N], SA, Ni, [KEi], TSi, TSr} --> 1621 <--IPv4(source_addr=HAADDR, dest_addr=V4ADDR) 1622 UDP (4500,Y) < non-ESP Marker > HDR, SK 1623 SA, Nr, [KEr], TSi, TSr} 1625 If no NAT is detected, the encapsulation used will be: 1627 IPv4 (source_addr=v4CoA, dest_addr=HAAddr) 1629 ESP 1631 IP (source_addr=HoA, set_addr=CNAddr) 1633 Upper_layer_HDR 1635 where IP=IPv4 or IPv6 and HoA=v4HoA or v6HoA 1637 If a NAT were detected, the encapsulation used will be: 1639 IPv4 (source_addr=v4Addr, dest_addr=HAAddr) 1641 UDP (sport=Y, dport=4500) 1643 ESP 1645 IP (source_addr=HoA, set_addr=CNAddr) 1647 Upper_layer_HDR 1649 Where v4CoA may be the external IPv4 address of the NAT, IP is either 1650 IPv4 or IPv6 header and HoA is either the IPv4 or the IPv6 HoA. The 1651 above format shows the packet as seen by the home agent. 1653 The SPD, whether a NAT were detected or not, is set as follows. Note 1654 that this rule is designed to match all data from the MN to nodes 1655 other than the home agent. This is done so that this rule does not 1656 overlap with the earlier rule securing BU/BA signaling between the MN 1657 and the HA. 1659 Mobile Node SPD-S: 1661 IF local_address = home_address & 1663 remote_address != home_agent & 1665 proto=any, then use SA ESP tunnel mode 1667 Initiate using IDi = user_1 to address home_agent_1 1669 home agent SPD-S: 1671 IF local_address != home_agent & 1673 remote_address = home_address & 1675 proto=any, then use SA ESP tunnel mode 1677 Where home_address is the MN's registered IPv6 or IPv4 home address 1678 and home_agent is the IPv6 or the IPv4 address of the home agent. 1680 7. Protocol Constants 1682 NATKATIMEOUT 110 seconds 1684 8. Acknowledgements 1686 Thanks to the following members (in alphabetical order) of the MIP6 1687 and NEMO Working Groups for their contributions, discussion, and 1688 review: Jari Arkko, Sri Gundavelli, Wassim Haddad, Conny Larsson, 1689 Acee Lindem, Ahmad Muhanna, Vidya Narayanan, Karen Nielsen and 1690 Keiichi Shima. Thanks to Karen Nielsen, Pasi Eronen and Christian 1691 Kaas-Petersen for raising the issue of IKEv2 interactions and 1692 proposing the solution included in this document. 1694 9. IANA Considerations 1696 The specification requires the following allocations from IANA: 1698 A UDP port is needed for the NAT traversal mechanism described in 1699 section 4.1. 1701 The IPv4 home address option described in section 3.1.1 requires 1702 an option type. This option is included in the Mobility header 1703 described in [RFC3775]. 1705 The IPv4 address acknowledgement option described in section 3.2.1 1706 requires a new option type. This option is included in the 1707 Mobility header described in [RFC3775]. 1709 The NAT detection option described in section 3.2.2 requires a new 1710 option type. This option is included in the Mobility header 1711 described in [RFC3775]. 1713 The IPv4 Care-of address option described in section 3.1.2 1714 requires an option type. This option is included in the Mobility 1715 header described in [RFC3775]. 1717 This specification introduces a new TLV-header to be used with UDP 1718 encapsulation. The Types of the TLV-header should be allocated by 1719 IANA under a new registry: "DSMIPv6 TLV-header Types". 1721 The Status field in the IPv4 home address option should be allocated 1722 by IANA under the new registry: "DSMIPv6 IPv4 home address option 1723 status codes". 1725 The TLV-header types and status field values are allocated using the 1726 following procedure: 1728 1. The IANA should allocate and permanently register new TLV-header 1729 types and Status field values from IETF RFC publication. This is 1730 for all RFC types including standards track, informational, and 1731 experimental status that originate from the IETF and have been 1732 approved by the IESG for publication. 1734 2. Requests for new option type value assignments from outside the 1735 IETF are only made through the publication of an IETF document, 1736 per 1) above. Note also that documents published as "RFC Editor 1737 contributions" [RFC3978] are not considered to be IETF documents. 1739 10. References 1741 10.1. Normative References 1743 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1744 Requirement Levels", BCP 14, RFC 2119, March 1997. 1746 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1747 IPv6 Specification", RFC 2473, December 1998. 1749 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1750 in IPv6", RFC 3775, June 2004. 1752 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1753 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1754 RFC 3948, January 2005. 1756 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 1757 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 1758 RFC 3963, January 2005. 1760 [RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting 1761 Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006. 1763 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1764 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1765 September 2007. 1767 10.2. Informative 1769 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1770 of Explicit Congestion Notification (ECN) to IP", 1771 RFC 3168, September 2001. 1773 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 1774 August 2002. 1776 [RFC3519] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of 1777 Network Address Translation (NAT) Devices", RFC 3519, 1778 April 2003. 1780 [RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78, 1781 RFC 3978, March 2005. 1783 [RFC4140] Soliman, H., Castelluccia, C., El Malki, K., and L. 1784 Bellier, "Hierarchical Mobile IPv6 Mobility Management 1785 (HMIPv6)", RFC 4140, August 2005. 1787 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1788 for IPv6 Hosts and Routers", RFC 4213, October 2005. 1790 [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the- 1791 Network Tunneling", RFC 4459, April 2006. 1793 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 1794 (MOBIKE)", RFC 4555, June 2006. 1796 [RFC4977] Tsirtsis, G. and H. Soliman, "Problem Statement: Dual 1797 Stack Mobility", RFC 4977, August 2007. 1799 [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 1800 Bootstrapping in Split Scenario", RFC 5026, October 2007. 1802 Appendix A. Contributors 1804 This document reflects discussions and contributions from several 1805 people including (in alphabetical order): 1807 Vijay Devarapalli: vijay.devarapalli@azairenet.com 1809 James Kempf: kempf@docomolabs-usa.com 1811 Henrik Levkowetz: henrik@levkowetz.com 1813 Pascal Thubert: pthubert@cisco.com 1815 George Tsirtsis: G.Tsirtsis@Qualcomm.com 1817 Wakikawa Ryuji: ryuji@sfc.wide.ad.jp 1819 Author's Address 1821 Hesham Soliman (editor) 1822 Elevate Technologies 1824 Email: hesham@elevatemobile.com 1826 Full Copyright Statement 1828 Copyright (C) The IETF Trust (2008). 1830 This document is subject to the rights, licenses and restrictions 1831 contained in BCP 78, and except as set forth therein, the authors 1832 retain all their rights. 1834 This document and the information contained herein are provided on an 1835 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1836 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1837 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1838 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1839 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1840 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1842 Intellectual Property 1844 The IETF takes no position regarding the validity or scope of any 1845 Intellectual Property Rights or other rights that might be claimed to 1846 pertain to the implementation or use of the technology described in 1847 this document or the extent to which any license under such rights 1848 might or might not be available; nor does it represent that it has 1849 made any independent effort to identify any such rights. Information 1850 on the procedures with respect to rights in RFC documents can be 1851 found in BCP 78 and BCP 79. 1853 Copies of IPR disclosures made to the IETF Secretariat and any 1854 assurances of licenses to be made available, or the result of an 1855 attempt made to obtain a general license or permission for the use of 1856 such proprietary rights by implementers or users of this 1857 specification can be obtained from the IETF on-line IPR repository at 1858 http://www.ietf.org/ipr. 1860 The IETF invites any interested party to bring to its attention any 1861 copyrights, patents or patent applications, or other proprietary 1862 rights that may cover technology that may be required to implement 1863 this standard. Please address the information to the IETF at 1864 ietf-ipr@ietf.org.