idnits 2.17.1 draft-ietf-mext-nemo-v4traversal-02.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 1852. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1863. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1870. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1876. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == Mismatching filename: the document gives the document name as 'draft-ietf-mext-nemo-v4travesrsal-02', but the file name used is 'draft-ietf-mext-nemo-v4traversal-02' 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 == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (April 29, 2008) is 5840 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: 'INTBOOT' is mentioned on line 257, but not defined == Missing Reference: 'IPv4 HAO' is mentioned on line 1578, but not defined == Missing Reference: 'IPv4 ACK' is mentioned on line 1615, but not defined == Missing Reference: 'CERTREQ' is mentioned on line 1496, but not defined == Missing Reference: 'N' is mentioned on line 1627, but not defined == Missing Reference: 'KEi' is mentioned on line 1627, but not defined == Missing Reference: 'KEr' is mentioned on line 1631, but not defined == Unused Reference: 'RFC2710' is defined on line 1754, but no explicit reference was found in the text == Unused Reference: 'RFC4861' is defined on line 1772, but no explicit reference was found in the text == Unused Reference: 'RFC4213' is defined on line 1796, but no explicit reference was found in the text == Unused Reference: 'RFC4291' is defined on line 1799, but no explicit reference was found in the text ** 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 3667 (Obsoleted by RFC 3978) -- Obsolete informational reference (is this intentional?): RFC 4140 (Obsoleted by RFC 5380) Summary: 2 errors (**), 0 flaws (~~), 14 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MEXT Working Group H. Soliman, Ed. 3 Internet-Draft Elevate Technologies 4 Intended status: Standards Track April 29, 2008 5 Expires: October 31, 2008 7 Mobile IPv6 Support for Dual Stack Hosts and Routers 8 draft-ietf-mext-nemo-v4travesrsal-02.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 October 31, 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 . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . 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). If the MN is attached to an IPv6-only or dual stack 256 network, it may also use procedures defined in [INTBOOT] to discover 257 home agent information. Note that the use of [INTBOOT] cannot give 258 the mobile node information that allows it to continue to communicate 259 with the home agent if, for example, the mobile node moved from an 260 IPv6-enabled network to an IPv4-only network. In this scenario, the 261 mobile node would need to discover the IPv4 address of its home agent 262 through the DNS. 264 For DNS lookup by name, the mobile node should be configured with the 265 name of the home agent. When the mobile node needs to discover a 266 home agent, it sends a DNS request with QNAME set to the configured 267 name. An example is "ha1.example.com". If a home agent has an IPv4 268 and IPv6 address, the corresponding DNS record should be configured 269 with both 'AAAA' and 'A' records. Accordingly, the DNS reply will 270 contain 'AAAA' and 'A' records. 272 For DNS lookup by service, the SRV record defined in [RFC5026] is 273 reused. For instance, if the service name is "mip6" and the protocol 274 name is "ipv6" in the SRV record, the mobile node SHOULD send a DNS 275 request with the QNAME set to "_mip6._ipv6.example.com". The 276 response should contain the home agent's FQDN(s) and may include the 277 corresponding 'AAAA' and 'A' records as well. 279 If multiple home agents reside on the home link, each configured with 280 a public IPv4 address, then the operation above applies. In case the 281 home agents are behind a NAT box, there are two options, 1) configure 282 a public IPv4 address for each home agent on the NAT box, 2) 283 configure one public address and make the home agents share the 284 public address. In either case, the correct DNS entries can be 285 configured. Another possible solution is to designate one home agent 286 on the home link for IPv4 traversal. The NAT device should associate 287 that home agent with the public IPv4 address configured on it for v4 288 traversal. In all cases above, both the 'AAAA' and 'A' records 289 returned for a particular name MUST correspond to the same physical 290 home agent; otherwise the mobile node will not be able to bind its 291 addresses correctly. 293 3.2. Mobile Prefix Solicitation and Advertisement 295 According to [RFC3775], the mobile node can send a Mobile Prefix 296 Solicitation and receive a Mobile Prefix Advertisement containing all 297 prefixes advertised on the home link. 299 A dual stack mobile node MAY send a Mobile Prefix Solicitation 300 message encapsulated in IPv4 (i.e., IPv6 in IPv4) in the case where 301 the mobile node has no access to IPv6 within the local network. 302 Securing these messages requires the mobile node to have a security 303 association with the home agent, using IPsec (AH or ESP) and based on 304 the mobile node's IPv4 care-of address as described in [RFC3775]. 305 Since the mobile node needs to encapsulate all IPv6 traffic sent to 306 the home agent into IPv4 while located in an IPv4-only visited 307 network, this SA would match all packets if the selectors were based 308 on the information in the outer header. That is, the SA selectors 309 being the protocol number (protocol is always IP in IP), as well as, 310 source and destination addresses are all common to all packets. If 311 this effect is not desired, the mobile node can base the SA on the 312 information in the inner header (i.e., using the home agent's IPv6 313 address, the mobile node's home address and the ICMP protocol 314 number). This security association would use transport mode ESP 315 protection. 317 3.3. Binding Management 319 A dual stack mobile node will need to update its home agent with its 320 care-of address. If a mobile node has an IPv4 and an IPv6 home 321 address, it will need to create a binding cache entry for each 322 address. The format of the IP packet carrying the binding update and 323 acknowledgement messages will vary depending on whether the mobile 324 node has access to IPv6 in the visited network. There are three 325 different scenarios to consider with respect to the visited network: 327 o The visited network has IPv6 connectivity and provides the mobile 328 node with a care-of address (in a stateful or stateless manner). 330 o The mobile node can only configure a globally unique IPv4 address 331 in the visited network. 333 o The mobile node can only configure a private IPv4 address in the 334 visited network. 336 3.3.1. Foreign Network Supports IPv6 338 In this case, the mobile node is able to configure a globally unique 339 IPv6 address. The mobile node will send a binding update to the IPv6 340 address of its home agent, as defined in [RFC3775]. The binding 341 update MAY include the IPv4 home address option introduced in this 342 document. After receiving the binding update, the home agent creates 343 two binding cache entries, one for the mobile node's IPv4 home 344 address, and another for the mobile node's IPv6 home address. Both 345 entries will point to the mobile node's IPv6 care-of address. Hence, 346 whenever a packet is addressed to the mobile node's IPv4 or IPv6 home 347 addresses, the home agent will tunnel it in IPv6 to the mobile node's 348 IPv6 care-of address included in the binding update. Effectively, 349 the mobile node establishes two different tunnels, one for its IPv4 350 traffic (IPv4 in IPv6) and one for its IPv6 traffic (IPv6 in IPv6) 351 with a single binding update. The security implications of this 352 mechanism are discussed in the security considerations section. 354 In this scenario, the only addition to [RFC3775] is the inclusion of 355 the IPv4 home address option in the binding update message. 357 After accepting the binding update and creating the corresponding 358 binding cache entries, the home agent MUST send a binding 359 acknowledgement to the mobile node as defined in [RFC3775]. In 360 addition, if the binding update included an IPv4 home address option, 361 the binding acknowledgement MUST include the IPv4 address 362 acknowledgment option as described later in this specification. This 363 option informs the mobile node whether the binding was accepted for 364 the IPv4 home address. If this option is not included in the binding 365 acknowledgement and the IPv4 home address option was included in the 366 binding update, the mobile node MUST assume that the home agent does 367 not support the IPv4 home address option and therefore SHOULD NOT 368 include the option in future binding updates to that home agent 369 address. 371 When a mobile node acquires both IPv4 and IPv6 care-of addresses at 372 foreign network, it SHOULD prioritize IPv6 care-of address for MIP6 373 binding registration. The mobile node MUST NOT register both IPv4 374 and IPv6 care-of addresses to its home agent. 376 3.3.2. Foreign Network Supports IPv4 Only 378 If the mobile node is in a foreign network that only supports IPv4, 379 it needs to detect whether a NAT is in its communication path to the 380 home agent. This is done while exchanging the binding update and 381 acknowledgement messages as shown later in this document. If no NAT 382 is detected between the mobile node and the home agent, the mobile 383 node assumes that it is in a foreign network that supports IPv4 384 public addresses. Otherwise, the mobile node assumes that private 385 addresses are used in the foreign network. Note that this assumption 386 is only valid for the purposes of the signaling presented in this 387 specification. A mobile node SHOULD NOT assume that its IPv4 address 388 is globally unique if a NAT device was not detected. The operations 389 of both cases are discussed below. 391 3.3.2.1. Foreign Network Supports IPv4 Only (Public Addresses 393 In this scenario the mobile node will need to tunnel IPv6 packets 394 containing the binding update to the home agent's IPv4 address. The 395 mobile node uses the IPv4 address it gets from the foreign network as 396 a source address in the outer header. The binding update will 397 contain the mobile node's IPv6 home address. However, since the 398 care-of address in this scenario is the mobile node's IPv4 address, 399 the mobile node MUST include its IPv4 care-of address in the IPv6 400 packet. The IPv4 address is represented in the IPv4 Care-of address 401 option defined in this specification. If the mobile node had an IPv4 402 home address, it MUST also include the IPv4 home address option 403 described in this specification. 405 After accepting the binding update, the home agent MUST create a new 406 binding cache entry for the mobile node's IPv6 home address. If an 407 IPv4 home address option were included, the home agent MUST create 408 another entry for that address. All entries MUST point to the mobile 409 node's IPv4 care-of address. Hence, all packets addressed to the 410 mobile node's home address(es) (IPv4 or IPv6) will be encapsulated in 411 an IPv4 header that includes the home agent's IPv4 address in the 412 source address field and the mobile node's IPv4 care-of address in 413 the destination address field. 415 After accepting the binding updates and creating the corresponding 416 entries, the home agent MUST send a binding acknowledgement as 417 specified in [RFC3775]. In addition, if the binding update included 418 an IPv4 home address option, the binding acknowledgement MUST include 419 the IPv4 address acknowledgment option as described later in this 420 specification. The binding acknowledgement is encapsulated to the 421 IPv4 care-of address, which was included in the source address field 422 of the IPv4 header encapsulating the binding update. 424 3.3.2.2. Foreign Network Supports IPv4 Only (Private Addresses 426 n this scenario the mobile node will need to tunnel IPv6 packets 427 containing the binding update to the home agent's IPv4 address. In 428 order to traverse the NAT device, IPv6 packets are tunneled UDP and 429 IPv4. The UDP port allocated for the home agent is TBA. 431 The mobile node uses the IPv4 address it gets from the visited 432 network as a source address in the IPv4 header. The binding update 433 will contain the mobile node's IPv6 home address. 435 After accepting the binding update, the home agent MUST create a new 436 binding cache entry for the mobile node's IPv6 home address. If an 437 IPv4 home address option were included, the home agent MUST create 438 another entry for that address. All entries MUST point to the mobile 439 node's IPv4 care-of address included in the source address of the 440 IPv4 header that encapsulated the binding update message. In 441 addition, the tunnel used MUST indicate UDP encapsulation for NAT 442 traversal. Hence, all packets addressed to the mobile node's home 443 address(es) (IPv4 or IPv6) will be encapsulated in UDP then 444 encapsulated in an IPv4 header that includes the home agent's IPv4 445 address in the source address field and the mobile node's IPv4 care- 446 of address in the destination address field. 448 After accepting the binding updates and creating the corresponding 449 entries, the home agent MUST send a binding acknowledgement as 450 specified in [RFC3775]. In addition, if the binding update included 451 an IPv4 home address option, the binding acknowledgement MUST include 452 the IPv4 address acknowledgment option as described later in this 453 specification. The binding acknowledgement is encapsulated in UDP 454 then IPv4 with the home agent's IPv4 address in the source address 455 field and the mobile node's IPv4 care-of address in the destination 456 field. The IPv4 address in the destination field of the IPv4 packet 457 is the source address received in the IPv4 header containing the 458 binding update message. The inner IPv6 packet will contain the home 459 agent's IPv6 address as a source address and the mobile node's IPv6 460 home address in the destination address field. 462 The mobile node needs to maintain the NAT bindings for its current 463 IPv4 care-of address. This is done through sending the binding 464 update regularly to the home agent. 466 3.4. Route Optimization 468 Route optimization, as specified in [RFC3775] will operate in an 469 identical manner for dual stack mobile nodes when they are located in 470 a visited network that provides IPv6 addresses to the mobile node. 471 However, when located in an IPv4-only network, route optimization 472 will not be possible due to the difficulty of performing the care-of 473 address test. Therefore, mobile nodes will need to communicate 474 through the home agent. 476 Route optimization will not be possible for IPv4 traffic. That is, 477 traffic addressed to the mobile node's IPv4 home address. This is 478 similar to using Mobile IPv4, therefore there is no reduction of 479 features resulting from using this specification. 481 3.5. Dynamic IPv4 Home Address Allocation 483 It is possible to allow for the mobile node's IPv4 home address to be 484 allocated dynamically. This is done by including 0.0.0.0 in the IPv4 485 home address option included in the binding update. The home agent 486 SHOULD allocate an IPv4 address to the mobile node and include it in 487 the IPv4 address acknowledgement option sent to the mobile node. In 488 this case, the lifetime of the binding is bound to the minimum of the 489 lifetimes of the IPv6 binding and the lease time of the IPv4 home 490 address. 492 4. Extensions And Modifications To Mobile IPv6 494 This section highlights the protocol and implementation additions 495 required to support this specification. 497 4.1. Binding Update Extensions 499 4.1.1. IPv4 Home Address Option 501 This option is included in the Mobility Header including the binding 502 update message sent from the mobile node to a home agent or Mobility 503 Anchor Point. The alignment requirement for this option is 4n. 505 0 1 2 3 506 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 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Type | Length |Prefix-len |P| Reserved | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | IPv4 home address | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 Figure 1: IPv4 Home Address Option 515 Type 517 TBD 519 Length 521 6 523 Prefix-len 525 The length of the prefix allocated to the mobile node. If only a 526 single address is allocated, this field MUST be set to 32. In the 527 first binding update requesting a prefix, the field contains the 528 prefix length requested. However, in the following binding 529 updates, this field must contain the length of the prefix 530 allocated. A value of zero is invalid and MUST be considered an 531 error. 533 P 535 A flag indicating, when set, that the mobile node requests a 536 mobile network prefix. This flag is only relevant for new 537 requests, and must be ignored for binding refreshes. 539 Reserved 541 This field is reserved for future use. It MUST be set to zero by 542 the sender and ignored by the receiver. 544 IPv4 Home Address 546 The mobile node's IPv4 home address that should be defended by the 547 home agent. This field could contain any unicast IPv4 address 548 (public or private) that was assigned to the mobile node. The 549 value 0.0.0.0 is used to request an IPv4 home address from the 550 home agent. A mobile node may choose to use this option to 551 request a prefix by setting the address to the All Zeroes and 552 setting the P flag. The mobile node could then form an IPv4 home 553 address based on the allocated prefix. Alternatively, the mobile 554 node may use two different options, one for requesting an address 555 (Static or Dynamic) and another for requesting a prefix. 557 4.1.2. The IPv4 Care-of Address Option 559 This option is included in the Mobility Header including the binding 560 update message sent from the mobile node to a home agent or Mobility 561 Anchor Point. The alignment requirement for this option is 4n. 563 0 1 2 3 564 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 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | Type | Length | Reserved | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | IPv4 Care-of address | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 Figure 2: The IPv4 CoA Option 573 Type 575 TBD 577 Length 579 6 581 Reserved 583 This field is set to zero by the sender and ignored by the 584 receiver. 586 IPv4 Care-of Address 588 This field contains the mobile node's IPv4 care- of address. The 589 IPv4 care-of address is used when the mobile node is located in an 590 IPv4-only network. 592 4.1.3. The Binding Update Message Extensions 594 This specification extends the Binding Update message with two new 595 flags. The flags are shown and described below. 597 0 1 2 3 598 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 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | Sequence # | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 |A|H|L|K|M|R|F|T| Reserved | Lifetime | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 Figure 3: Binding Update message 607 F 609 When set, this flag indicates a request for forcing UDP 610 encapsulation regardless of whether a NAT is present on the path 611 between the mobile node and the home agent. 613 T 615 When set, this flag indicates that the mobile node requests the 616 use of the TLV-format for encapsulating IPv6 in IPv4. The TLV- 617 format is described later in this document. 619 4.2. Binding Acknowledgement Extensions 621 4.2.1. IPv4 Address Acknowledgement Option 623 This option is included in the Mobility Header including the binding 624 acknowledgement message sent from the home agent or Mobility Anchor 625 Point to the mobile node. This option indicates whether a binding 626 cache entry was created for the mobile node's IPv4 address. 627 Additionally, this option can include an IPv4 home address in the 628 case of Dynamic IPv4 home address configuration (i.e., if the 629 unspecified IPv4 address was included in the binding update). The 630 alignment requirement for this option is 4n. 632 0 1 2 3 633 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 | Type | Length | Status |Pref-len |Res| 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | IPv4 home address | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 Figure 4: IPv4 Address Acknowledgement Option 642 Type 644 TBD 646 Length 648 6 650 Status 652 Indicates success or failure for the IPv4 home address binding. 653 Values from 0 to 127 indicate success. Higher values indicate 654 failure. 656 Pref-len 658 The prefix length of the address allocated. This field is only 659 valid in case of success and MUST be set to zero and ignored in 660 case of failure. This field overrides what the mobile node 661 requested (if not equal to the requested length). 663 Res 665 This field is reserved for future use. It MUST be set to zero by 666 the sender and ignored by the receiver 668 IPv4 Home Address 670 he IPv4 home address that the home agent will use in the binding 671 cache entry. This could be a public or private address. This 672 field MUST contain the mobile node's IPv4 home address. If the 673 address were dynamically allocated the home agent will add the 674 address to inform the mobile node. Otherwise, if the address were 675 statically allocated to the mobile node, the home agent will copy 676 it from the binding update message. 678 The following values are allocated for the Status field: 680 o 0 Success 682 o 128 Failure, reason unspecified 684 o 129 Administratively prohibited 686 o 130 Incorrect IPv4 home address 688 o 131 Invalid IPv4 address 690 o 132 Dynamic IPv4 home address assignment not available 692 o 133 Prefix allocation unauthorized 694 4.2.2. The NAT Detection Option 696 This option is sent from the home agent to the mobile node to 697 indicate whether a NAT was in the path. This option MAY also include 698 a suggested NAT binding refresh time for the mobile node. The 699 alignment requirement for this option is 4n. If a NAT is detected, 700 this option MUST be sent by the home agent. 702 0 1 2 3 703 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 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | Type | Length |F| Reserved | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | Refresh time | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 Figure 5: The NAT Detection Option 712 Type 714 TBD 716 Length 718 6 720 F 722 This flag indicates to the mobile node that UDP encapsulation is 723 required. When set, this flag indicates that the mobile node MUST 724 use UDP encapsulation even if a NAT is not located between the 725 mobile node and home agent. 727 Reserved 729 This field is reserved for future use. It MUST be set to zero by 730 the sender and ignored by the receiver. 732 Refresh Time 734 A suggested time (in seconds) for the mobile node to refresh the 735 NAT binding. If set to zero, it is ignored. If this field is set 736 to the all 1s it means that keepalives are not needed, i.e.,no NAT 737 was detected. 739 4.2.3. Extensions to the Binding Acknowledgement Message 741 This specification extends the binding acknowledgement message with a 742 new flag. The new flag is shown and described below. 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 | Status |K|R|T| Reserved| 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 | Sequence # | Lifetime | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 Figure 6: Binding Acknowledgement message 752 T 754 This flag indicates, when set, that the sender of the binding 755 acknowledgement supports the TLV- tunnel format. 757 5. Protocol operation 759 This section presents the protocol operation and processing for the 760 messages presented above. In addition, this section introduces the 761 NAT detection and traversal mechanism used by this specification. 763 5.1. Tunelling Formats 765 This specification allows the mobile node to use various tunnelling 766 formats depending on its location and the visited networ's 767 capabilities. The mobile node can tunnel IPv6 in IPv4, IPv4 in IPv6 768 or use UDP encapsulation to tunnel IPv6 in IPv4. Naturally, this 769 specification also supports tunnelling IPv6 in IPv6. 771 This speacification allows two different types of UDP-based 772 tunnelling formats to be used between the mobile node and its home 773 agent or MAP. The two formats are vanilla UDP encapsulation and TLV- 774 header UDP encapsulation. A vanilla UDP encapsulation format means 775 the following order of headers: 777 IPv4 779 UDP 781 IP (v4 or v6) 783 Other headers 785 When using this format the receiver would parse the version field 786 following the UDP header in order to determine whether the following 787 header is IPv4 or IPv6. The rest of the headers are processed 788 normally. The above order of headers does not take IPsec headers 789 into account as they may be placed in different parts of the packet. 790 The above format MUST be supported by all implementations of this 791 specification and MUST always be used to send the binding update 792 message. 794 A TLV-header UDP encapsulation is represented by the following order 795 of headers: 797 IP (v4 or v6) 799 UDP 801 TLV-header 803 Other headers 805 The use of the TLV header is negotiated during the binding update/ 806 acknowledgement exchange. If the TLV header is agreed upon, the 807 receiver of the TLV-header UDP encapsulated packet expects the TLV- 808 header to follow UDP. The TLV header contains the type of the 809 following message and its length. The Type field MUST NOT be 810 assigned the values 4 or 6 to make sure that the receiver can tell 811 the difference between the Type field and the IP version field in a 812 packet that contains an IP header after UDP. Hence, the TLV header 813 can carry traffic other than IP. 815 The mobile node negotiates the format for tunnelling payload traffic 816 during the binding exchange. If a mobile node prefers to use the 817 TLV- header UDP encapsulation, it sets the T flag in the binding 818 update sent to the home agent or MAP. If the receiver of the binding 819 update supports the TLV-header format, it SHOULD set the T flag in 820 the binding acknowledgement message. Otherwise, the T flag is 821 cleared. The setting of the T flag in the binding acknowledgement 822 indicates to the mobile node that it must use the TLV-header UDP 823 encapsulation format for all packets sent for the duration of the 824 binding or until a new binding update is sent. Each binding update 825 may renegotiate the tunnelling format. To avoid interoperability 826 issues, the sender of the binding acknowledgement MUST NOT set the T 827 flag unless it was set in the binding update sent from the mobile 828 node. 830 The TLV-header format is shown below. 832 0 1 2 3 833 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 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 | Type | Length | Reserved | 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 Figure 7: TLV-header format 840 Type 842 This field indicates the type of the payload following this 843 header. 845 Length 847 This field indicates the length of the payload following the 848 header, excluding the TLV-header itself. 850 Reserved 851 This field MUST be set to zero by the sender and ignored by the 852 receiver. 854 The following value is assigned to the Type field, other values may 855 be assigned in future: 857 1 GRE 859 In addition to the UDP-based tunnelling formats described above, this 860 specification allows for standard IP in IP tunnelling. This can take 861 place by tunnelling IPv4 in IPv6 or IPv6 in IPv4. However, whenever 862 a NAT a detected, the mobile node will default to UDP-based 863 encapsulation. The mobile node can request to always use UDP 864 encapsulation by setting the F flag in the binding update. If the 865 home agent does not agree to the request, it MUST reject the binding 866 update with the new Status code: 868 144 Cannot force UDP encapsulation 870 Alternatively, the home agent can force UDP encapsulation by setting 871 the F flag in the NAT detection option included in the binding 872 acknowledgement. 874 5.1.1. Tunnelling Impacts on Transport and MTU 876 Changing the tunnel format may occur due to movement of the mobile 877 node from one network to another. This can have impacts on the link 878 and path MTU, which may affect the amount of bandwidth available to 879 the applications. It is recommended that the mobile node use PLMTUD 880 as specified in [RFC4459]. 882 To accomodate traffic that uses Explicit Congestion Notification 883 (ECN), it is RECOMMENDED that the ECN information is copied between 884 the inner and outer header as defined in [RFC3168]. 886 5.2. NAT Detection 888 NAT detection is done when the initial binding update message is sent 889 from the mobile node to the home agent. When located in an IPv4-only 890 foreign link, the mobile node sends the binding update message 891 encapsulated in UDP and IPv4. The source address of the IPv6 packet 892 is the mobile node's IPv6 home address. The destination address is 893 the IPv6 address of the home agent. The IPv4 header contains the 894 IPv4 care-of address in the source address field and the IPv4 address 895 of the home agent in the destination address field. 897 When the home agent receives the encapsulated binding update it 898 compares the IPv4 address of the source address field in the IPv4 899 header with the IPv4 address included in the IPv4 care-of address 900 option. If the two addresses match, no NAT device was in the path. 901 Otherwise, a NAT device was in the path and the NAT detection option 902 is included in the binding acknowledgement. The binding 903 acknowledgement, and all future packets, are then encapsulated in UDP 904 and IPv4. The source address in the IPv4 header is the IPv4 address 905 of the home agent. The destination address is the IPv4 address 906 received in the IPv4 header encapsulating the binding update (this 907 address will be different from the IPv4 care-of address when a NAT is 908 in the path). The source port in the packet is the home agent's 909 source port. The destination port is the source port received in the 910 binding update message. Note that the home agent stores the port 911 numbers and associates them with the mobile node's tunnel in order to 912 forward future packets. 914 Upon receiving the binding acknowledgement with the NAT detection 915 option, the mobile node sets the tunnel to the home agent to UDP 916 encapsulation. Hence, all future packets to the home agent are 917 tunneled in UDP and IPv4. For all tunneled IPv6 packets, the source 918 address in the IPv6 header is the mobile node's IPv6 home address and 919 the destination address is the correspondent node's IPv6 address. 920 All tunneled IPv4 packets will contain the mobile node's IPv4 home 921 address in the source address field of the inner IPv4 packet and the 922 correspondent node's IPv4 address in the destination address field. 923 The outer IPv4 header is the same whether the inner packet is IPv4 or 924 IPv6. 926 If no NAT device was detected in the path between the mobile node and 927 the home agent then IPv6 packets are tunneled in an IPv4 header, 928 unless the home agent forces UDP encapsulation using the F flag. The 929 content of the inner and outer headers are identical to the UDP 930 encapsulation case. 932 A mobile node MUST always tunnel binding updates in UDP when located 933 in an IPv4-only network. Essentially, this process allows for 934 perpetual NAT detection. Similarly, the home agent MUST encapsulate 935 binding acknowledgements in a UDP header whenever the binding update 936 is encapsulated in UDP. 938 In conclusion, the packet formats for the binding update and 939 acknowledgement messages are shown below: 941 Binding update received by the home agent: 943 IPv4 header (src=V4ADDR, dst=HA_V4ADDR) 945 UDP header 946 IPv6 header (src=V6HOA, dst=HAADDR) 948 ESP Header 950 Mobility header 952 BU [IPv4 HAO] 954 IPv4 CoA option 956 Where V4ADDR is either the IPv4 care-of address or the address 957 provided by the NAT device. V6HOA is the IPv6 home address of the 958 mobile node. The binding update MAY also contain the IPv4 home 959 address option IPv4 HAO. 961 Binding acknowledgement sent by the home agent: 963 IPv4 header (src= HA_V4ADDR, dst=V4ADDR) 965 UDP Header 967 IPv6 header (src=HAADDR, dst=V6HOA) 969 ESP Header 971 Mobility Header 973 BA ([IPv4 ACK], NAT DET) 975 Where V6HOA is IPv6 home address of the mobile node. The IPv4 ACK is 976 the IPv4 address acknowledgement option, which is only included if 977 the IPv4 home address option were present in the BU. The NAT DET is 978 the NAT detection option, which MUST be present in the binding 979 acknowledgement message if the binding update was encapsulated in 980 UDP. 982 5.3. NAT Keepalives 984 If a NAT is detected, the mobile node will need to refresh the NAT 985 bindings in order to be reachable from the home agent. NAT bindings 986 can be refreshed through sending and receiving traffic encapsulated 987 in UDP. However, if the mobile node is not active, it will need to 988 periodically send a message to the home agent in order to refresh the 989 NAT binding. This can be done using the binding update message. The 990 binding update/acknowledgement pair will ensure that the NAT bindings 991 are refreshed in a reliable manner. There is no way for the mobile 992 node to know the exact time of the NAT binding. The default time 993 suggested in this specification is NATKATIMEOUT. If the home agent 994 suggests a different refresh period in the binding acknowledgement, 995 the mobile node SHOULD use the value suggested by the home agent. 997 If the refresh time in the NAT detection option in the binding 998 acknowledgement is set to the all 1s, the mobile node need not send 999 messages to refresh the NAT binding. However, the mobile node may 1000 still be required to encapsulate traffic in UDP. This scenario may 1001 take place when a NAT is not detected, but the home agent still 1002 requires the mobile node to use UDP encapsulation. 1004 It should be noted that a mobile node that does not need to be 1005 reachable (i.e., only cares about the session continuity aspect of 1006 Mobile IP) does not need to refresh NAT binding. In this case, the 1007 mobile node would only be able to initiate communication with other 1008 nodes. However, this is likely to imply that the mobile node will 1009 need to send a binding update before initiating communication after a 1010 long idle period as it is likely to be assigned a different port and 1011 IPv4 address when it initiates communication. Hence, an 1012 implementation may choose, for the sake of simplicity, to always 1013 maintain the NAT bindings even when it does not need reachability. 1015 5.4. Mobile Node Operation 1017 In addition to the operations specified in [RFC3775] and [RFC3963], 1018 this specification requires mobile nodes to be able to support an 1019 IPv4 home address. 1021 When sending an IPv6 packet containing a binding update while 1022 connected to an IPv4-only access network, mobile nodes MUST ensure 1023 the following: 1025 o The IPv6 packet is encapsulated in the vanilla UDP encapsulation 1026 format. 1028 o The source address in the IPv4 header is the mobile node's IPv4 1029 care-of address. 1031 o The destination address in the IPv4 header is the home agent's 1032 IPv4 address. 1034 o The source address in the IPv6 header is the mobile node's IPv6 1035 home address. 1037 o The IPv4 home address option MAY be included in the mobility 1038 header. This option contains the IPv4 home address. If the 1039 mobile node did not have a static home address it MAY include the 1040 unspecified IPv4 address, which acts as a request for a dynamic 1041 IPv4 home address. Alternatively, one or more IPv4 home address 1042 options may be included with requests for IPv4 prefixes (i.e., 1043 with the P flag set). 1045 o If the mobile node wishes to use UDP encapsulation only, it should 1046 set the F flag in the binding update message. 1048 o If the mobile node prefers to use the TLV-header format, it should 1049 set the T flag in the binding update. 1051 o The IPv6 packet MUST be authenticated as per [RFC3775], based on 1052 the mobile node's IPv6 home address. 1054 When sending a binding update from a visited network that supports 1055 IPv6, the mobile node MUST follow the rules specified in [RFC3775]. 1056 In addition, if the mobile node has an IPv4 home address or needs 1057 one, it MUST include the IPv4 home address option in the mobility 1058 header. If the mobile node already has a static IPv4 home address, 1059 this address MUST be included in the IPv4 home address option. 1060 Otherwise, if the mobile node needs a dynamic IPv4 address, it MUST 1061 include the IPv4 0.0.0.0 address in the IPv4 home address option. 1063 When the mobile node receives a binding acknowledgement from the home 1064 agent, it follows the rules in [RFC3775] and [RFC3963]. In addition, 1065 the following actions MUST be made: 1067 o If the status field indicated failure with error code 144, the 1068 mobile node MAY resend the binding update without setting the F 1069 flag. 1071 o If the mobility header includes an IPv4 address acknowledgement 1072 option indicating success, the mobile node should create two 1073 entries in its binding update list, one for the IPv6 home address 1074 and another for the IPv4 home address. 1076 o If the NAT detection option were present, the mobile node MUST 1077 tunnel future packets in UDP and IPv4. This MUST be indicated in 1078 the binding update list. 1080 o If no IPv4 address acknowledgement option were present, and an 1081 IPv4 home address option was present in the binding update, the 1082 mobile node MUST only create one binding update list entry for its 1083 IPv6 home address. The mobile node MAY include the IPv4 home 1084 address option in future binding updates. 1086 o If an IPv4 address acknowledgement option were present and it 1087 indicates failure for the IPv4 home address binding, the mobile 1088 node MUST NOT create an entry for that address in its binding 1089 update list. The mobile node MAY include the IPv4 home address 1090 option in future binding updates. 1092 o If the T flag was set in the binding update and the binding 1093 acknowledgement included the T flag set, the mobile node MUST use 1094 the TLV-header UDP encapsulation format. 1096 5.4.1. Sending Packets from a Visited Network 1098 When the mobile node is located in an IPv6-enabled network it sends 1099 and receives IPv6 packets as described in [RFC3775]. IPv4 traffic is 1100 encapsulated in IPv6 packets to the home agent. 1102 When the mobile node is located in an IPv4 only network, it will send 1103 IPv6 packets to its home agent according to the following format: 1105 IPv4 header (src=V4CoA, dst=HA_V4ADDR) 1107 [UDP Header] 1109 [TLV Header] 1111 IPv6 header (src=V6HoA, dst=CN) 1113 Upper Layer protocols 1115 Where the UDP header is only used if a NAT were detected between the 1116 mobile node and the home agent, or if the home agent forced UDP 1117 encapsulation. V4CoA is the IPv4 care-of address configured by the 1118 mobile node in the visited network. 1120 Similarly, IPv4 packets are sent according to the following format: 1122 IPv4 header (src=V4CoA, dst=HA_V4ADDR) 1124 [UDP Header] 1126 [TLV Header] 1128 IPv4 header (src=V4HoA, dst=V4CN) 1130 Upper Layer protocols 1132 Where the UDP header is only used if a NAT were detected between the 1133 mobile node and the home agent, or if the home agent forced UDP 1134 encapsulation. 1136 If the mobile node and the home agent negotiated the use of the TLV- 1137 header UDP encapsulation format, then the TLV-header would be used 1138 after the UDP header. 1140 5.4.2. Movement Detection in IPv4-only Networks 1142 [RFC3775] describes movement detection mostly based on IPv6-specific 1143 triggers. These triggers would not be available in an IPv4-only 1144 network. Hence, a mobile node located in an IPv4-only network SHOULD 1145 use [RFC4436] for guidance on movement detection mechanisms in IPv4- 1146 only networks. 1148 5.5. Home agent operation 1150 In addition to the home agent specification in [RFC3775] and 1151 [RFC3963], the home agent needs to be able to process the IPv4 home 1152 address option and generate the IPv4 address acknowledgement option. 1153 Both options are included in the mobility header. Furthermore, the 1154 home agent MUST be able to detect the presence of a NAT device and 1155 indicate that in the NAT detection option included in the binding 1156 acknowledgement. 1158 A home agent must also act as a proxy for address resolution in IPv4 1159 for the registered IPv4 home addresses of mobile nodes it is serving. 1160 Moreover, the administrative domain of the home agent is responsible 1161 for advertising the routing information of registered IPv4 mobile 1162 network prefixes of the mobile nodes. 1164 In order to comply with this specification, the home agent MUST be 1165 able to find the IPv4 home address of a mobile node when given the 1166 IPv6 home address. That is, given an IPv6 home address, the home 1167 agent MUST store the corresponding IPv4 home address if a static one 1168 is present. If a dynamic address were requested by the mobile node, 1169 the home agent MUST store that address (associated with the IPv6 home 1170 address) after it's allocated to the mobile node. 1172 When the home agent receives a binding update encapsulated in UDP and 1173 containing the IPv4 home address option, it needs to follow all the 1174 steps in [RFC3775] and [RFC3963]. In addition, the following checks 1175 MUST be done: 1177 o If the IPv4 care-of address in the IPv4 CoA option is not the same 1178 as the IPv4 address in the source address in the IPv4 header then 1179 a NAT was in the path. This information should be flagged for the 1180 binding acknowledgement. 1182 o If the F flag in the binding update were set, the home agent needs 1183 to determine whether it accepts forcing UDP encapsulation. If it 1184 does not, the binding acknowledgement is sent with error code 144. 1185 UDP encapsulation MUST NOT be used when the mobile node is located 1186 in an IPv6-enabled link. 1188 o If the T flag was set in the binding update, the home agent needs 1189 to determine whether it can accept the TLV-header encapsulation 1190 format. If it does, it should set the T flag in the binding 1191 acknowledgement. Otherwise, the home agent MUST NOT set the T 1192 flag in the binding acknowledgement. 1194 o If the IPv4 home address option contains a valid unicast IPv4 1195 address, the home agent MUST check that this address is allocated 1196 to the mobile node that has the IPv6 home address included in the 1197 home address option. The same MUST be done for an IPv4 prefix. 1199 o If the IPv4 home address option contained the unspecified IPv4 1200 address, the home agent SHOULD dynamically allocate an IPv4 home 1201 address to the mobile node. If none is available, the home agent 1202 MUST return error code 132 in the status field of the IPv4 address 1203 acknowledgement option. If a prefix were requested, the home 1204 agent MUST allocate a prefix with the requested length; otherwise 1205 the home agent MUST indicate failure of the operation with the 1206 appropriate error code. 1208 o If the binding update is accepted for the IPv4 home address, the 1209 home agent creates a binding cache entry for the IPv4 home 1210 address/prefix. The home agent MUST include an IPv4 1211 acknowledgement option in the mobility header containing the 1212 binding acknowledgement. 1214 o If the binding update is accepted for both IPv4 and IPv6 home 1215 addresses, the home agent creates separate binding cache entries, 1216 one for each home address. The care-of address is the one 1217 included in the binding update. If the care-of address is an IPv4 1218 address, the home agent MUST setup a tunnel to the IPv4 care-of 1219 address of the mobile node. 1221 When sending a binding acknowledgement to the mobile node, the home 1222 agent constructs the message according to [RFC3775] and [RFC3963]. 1223 Note that the routing header MUST always contain the IPv6 home 1224 address as specified in [RFC3775]. 1226 If the care-of address of the mobile node were an IPv4 address, the 1227 home agent includes the mobile node's IPv6 home address in the 1228 destination address field in the IPv6 header. If a NAT were 1229 detected, the home agent MUST then encapsulate the packet in UDP and 1230 an IPv4 header. The source address is set to the home agent's IPv4 1231 address and the destination address is set to the address received in 1232 the source address of the IPv4 header encapsulating the binding 1233 update. 1235 After creating a binding cache entry for the mobile node's home 1236 addresses, all packets sent to the mobile node's home addresses are 1237 tunneled by the home agent to the mobile node's care-of address. If 1238 a NAT were detected, packets are encapsulated in UDP and IPv4. 1239 Otherwise, if the care-of address is an IPv4 address, and no NAT were 1240 detected, packets are encapsulated in an IPv4 header unless UDP 1241 encapsulation is forced by the home agent. 1243 5.5.1. Sending Packets to the Mobile Node 1245 The home agent follows the rules specified in [RFC3775] for sending 1246 IPv6 packets to mobile nodes located in IPv6 networks. When sending 1247 IPv4 packets to When mobile nodes in an IPv6 network, the home agent 1248 must encapsulate the IPv4 packets in IPv6. 1250 When sending IPv6 packets to a mobile node located in an IPv4 1251 network, the home agent must follow the format negotiated in the 1252 binding update/acknowledgement exchange. In the absence of a 1253 negotiated format, the default format that MUST be supported by all 1254 implementations is: 1256 IPv4 header (src= HA_V4ADDR, dst= V4ADDR) 1258 UDP Header 1260 IPv6 header (src=CN, dst= V6HoA) 1262 Upper layer protocols 1264 Where the UDP header is only included if a NAT were detected between 1265 the mobile node and the home agent, or if the home agent forced UDP 1266 encapsulation. V4ADDR is the IPv4 address received in the source 1267 address field of the IPv4 packet containing the binding update. 1269 When sending IPv4 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] 1279 IPv4 header (src=V4CN, dst= V4HoA) 1281 Upper layer protocols 1283 Where the UDP header is only included if a NAT were detected between 1284 the mobile node and home agent, or if the home agent forced UDP 1285 encapsulation. 1287 5.6. Correspondent Node Operation 1289 This specification has no impact on IPv4 or IPv6 correspondent nodes. 1291 6. Security Considerations 1293 This specification allows a mobile node to send one binding update 1294 for its IPv6 and IPv4 home addresses. This is a slight deviation 1295 from [RFC3775] which requires one binding update per home address. 1296 However, like [RFC3775], the IPsec security association needed to 1297 authenticate the binding update is still based on the mobile node's 1298 IPv6 home address. Therefore, in order to authorize the mobile 1299 node's IPv4 home address binding, the home agent MUST store the IPv4 1300 address corresponding to the IPv6 address that is allocated to a 1301 mobile node. Therefore, it is sufficient for the home agent to know 1302 that the IPsec verification for the packet containing the binding 1303 update was valid provided that it knows which IPv4 home address is 1304 associated with which IPv6 home address. Hence, the security of the 1305 IPv4 home address binding is the same as the IPv6 binding. 1307 In effect, associating the mobile node's IPv4 home address with its 1308 IPv6 home address moves the authorization of the binding update for 1309 the IPv4 address to the Mobile IPv6 implementation, which infers it 1310 from the fact that mobile node has an IPv6 home address and the right 1311 credentials for sending an authentic binding update for the IPv6 1312 address. 1314 In cases where this specification is used for NAT traversal, it is 1315 important to note that it has the same vulnerabilities associated 1316 with [RFC3519]. An attacker is able to hijack the mobile node's 1317 session with the home agent if it can modify the contents of the 1318 outer IPv4 header. The contents of the header are not authenticated 1319 and there is no way for the home agent to verify their validity. 1320 Hence, a man in the middle attack where a change in the contents of 1321 the IPv4 header can cause a legitimate mobile node's traffic to be 1322 diverted to an illegitimate receiver independently of the 1323 authenticity of the binding update message. 1325 In this specification, the binding update message MUST be protected 1326 using ESP transport mode. When the mobile node is located in an 1327 IPv4- only network, the binding update message is encapsulated in UDP 1328 as described earlier. However, UDP MUST NOT be used to encapsulate 1329 the binding update message when the mobile node is located in an 1330 IPv6- enabled network. If protection of payload traffic is needed 1331 when the mobile node is located in an IPv4-only network, 1332 encapsulation is done using tunnel mode ESP over port 4500 as 1333 described in [RFC3948]. During the IKE negotiation with the home 1334 agent, if the mobile node and home agent support the use of port 1335 4500, the mobile node MUST establish the security association over 1336 port 4500, regardless of the presence of a NAT. This is done to 1337 avoid the switching between ports 500 and 4500 and the potential 1338 traffic disruption resulting from this switch. 1340 Handovers within private IPv4 networks or from IPv6 to IPv4 networks 1341 will have impacts on the security association between the mobile node 1342 and the home agent. The following section presents the expected 1343 behaviour of the mobile node and home agent in those situations. The 1344 details of the IKE negotiations and messages are illustrated in 1345 Section 6.2 1347 6.1. Handover Interactions for IPsec and IKE 1349 After the mobile node detects movement it configures a new care-of 1350 address. If the mobile node is in an IPv4-only network, it removes 1351 binding update list entries for correspondent nodes since route 1352 optimisation cannot be supported. This may cause inbound packet 1353 losses as remote correspondent node are unaware of such movement. To 1354 avoid confusion in the correspondent node, the mobile node SHOULD 1355 deregister its binding with each correspondent node by sending a 1356 deregistration binding update. The deregistration binding update 1357 message is tunnelled to the home agent and onto the correspondent 1358 node. This is done after the mobile node updates the home agent with 1359 its new location as discussed below. 1361 The mobile node sends the binding update message to the home agent. 1362 If the mobile node is in an IPv6-enabled network, the binding update 1363 is sent without IPv4/UDP encapsulation. If the mobile node is in an 1364 IPv4-only network, then after IPsec processing of the BU message, it 1365 encapsulates the BU in UDP/IPv4 as discussed in sections 4.2 and 4.4. 1366 In order to be able to send the binding update while in an IPv4-only 1367 network, the mobile node needs to use the new IPv4 care-of address in 1368 the outer header, which is different from the care-of address used in 1369 the existing tunnel. This should be done without permanently 1370 updating the tunnel within the mobile node's implementation in order 1371 to allow the mobile node to receive packets on the old care-of 1372 address until the binding acknowledgement is received. The method 1373 used to achieve this effect is implementation dependent and is 1374 outside the scope of this specification. This implies that the IP 1375 forwarding function (which selects the interface or tunnel through 1376 which a packet is sent) is not based solely on the destination 1377 address: some IPv6 packets destined to the home agent are sent via 1378 the existing tunnel, while BUs are sent using the new care-of 1379 address. Since BUs are protected by IPsec, the forwarding function 1380 cannot necessarily determine the correct treatment from the packet 1381 headers. Thus, the DSMIPv6 implementation has to attach additional 1382 information to BUs, and this information has to be preserved after 1383 IPsec processing and made available to the forwarding function, or 1384 additional DSMIP processing added to the forwarding function. 1385 Depending on the mobile node's implementation, meeting this 1386 requirement may require changes to the IPsec implementation. 1388 Upon receiving the binding update message encapsulated in UDP/IPv4, 1389 the home agent processes it as follows. In order to allow the 1390 DSMIPv6 implementation in the home agent to detect the presence of a 1391 NAT on the path to the mobile node, it needs to compare the outer 1392 IPv4 source address with the IPv4 address in the IPv4 care-of address 1393 option. This implies that the information in the outer header will 1394 be preserved after IPsec processing and made available to the DSMIPv6 1395 implementation in the home agent. Depending on the home agent's 1396 implementation, meeting this requirement may require changes to the 1397 IPsec implementation. 1399 The home agent updates its tunnel mode security association to 1400 include the mobile node's care-of address as the remote tunnel header 1401 address, and 4500 as the port number. The IPv4 address and port 1402 number are likely to be wrong; the mobile node provides the correct 1403 information in a separate exchange as described below. When the 1404 mobile node is located in a private IPv4 network (which is detected 1405 as described above), the new address and port number are allocated by 1406 the NAT. The home agent will also enable or disable UDP 1407 encapsulation for outgoing ESP packets for the purpose of NAT 1408 traversal. 1410 If the Key Management Mobility Capability (K) bit was set in the 1411 binding update, and the home agent supports this feature, the home 1412 agent updates its IKE security associations to include the mobile 1413 node's care-of address as the peer address and 4500 as the port 1414 number. The home agent may also need to change NAT traversal fields 1415 in the IKE_SA to enable the dyanmic update of the IP address and port 1416 number based on the reception of authenticated IKE messages, or 1417 authenticated packets using tunnel mode ESP. The dynamic updates are 1418 described in section 2.23 of RFC 4306. As described above, when the 1419 mobile node is located in a private IPv4 network, the address and 1420 port number used for IPsec and IKE traffic is not yet known by the 1421 home agent at this point. 1423 The mobile node updates the IKE SA in one of two ways. If the K flag 1424 was set in the binding acknowledgement message, the mobile node 1425 SHOULD send an empty informational message, which results in the IKE 1426 module in the home agent to dynamically update the SA information. 1427 The IKE implementation in the home agent is REQUIRED to support this 1428 feature. Alternatively, the IKE SA should be re-negotiated. Note 1429 that updating the IKE SA MUST take place after the mobile node has 1430 sent the binding update and received the acknowledgement from the 1431 home agent. 1433 It is important to note that the mobile node's IPv4 care-of address 1434 seen by the DSMIPv6 module in the home agent upon receiving the 1435 binding update may differ from the IPv4 care-of address seen by the 1436 IKE module and the care-of address used for forwarding IPsec tunnel 1437 mode traffic. Hence, it is probable that different modules in the 1438 home agent will have a different care-of address that should be used 1439 for encapsulating traffic to the mobile node. 1441 After successfully processing the binding update, the home agent 1442 sends the binding acknowledgement to the mobile node's care-of 1443 address as received in the outer header of the packet containing the 1444 binding update. Note that if the BU was rejected, the BAck is sent 1445 to the same address where the BU was received from. This may require 1446 special treatment in IP forwarding and/or IPsec processing which 1447 resembles sending of BUs in the mobile node (described above). 1449 Upon receiving the binding acknowledgement the mobile node updates 1450 its local tunnel mode Security Association information to include the 1451 tunnel header IP source address, which is the the home agent's 1452 address and the tunnel header IP destination, which is the mobile 1453 node's care-of address. The mobile node may also need to enable or 1454 disable UDP encapsulation for outgoing ESP packets for the purpose of 1455 NAT traversal and the sending of keep alives. 1457 The mobile node MAY use [RFC4555] to update its IKE SA with the home 1458 agent. Using MOBIKE requires negotiating this capability with the 1459 home agent when establishing the SA. In this case, the mobile node 1460 and the home agent MUST NOT update their IPsec SAs locally as this 1461 step is performed by MOBIKE. Furthermore, the use of MOBIKE allows 1462 the mobile node to update the SA independently of the binding update 1463 exchange. Hence, there is no need for the mobile node to wait for a 1464 binding acknowledgement before performing MOBIKE. The use of MOBIKE 1465 is OPTIONAL in this specification. 1467 6.2. IKE negotiation messages between the mobile node and Home Agent 1469 This specification defines a number of possible data encapsulation 1470 formats depending on the mobile node's connectivity to the visited 1471 network. When connected to an IPv6-enabled network, the tunnelling 1472 formats are clear. However, when connected to an IPv4-only network, 1473 care should be taken when negotiationg the IKE association and the 1474 consequential tunnelling formats used for secure and insecure 1475 traffic. This section illustrates the IKE message exchange between 1476 the mobile node and home agent when the mobile node is located in an 1477 IPv4-only network. Two different IKE negotiations are considered: 1479 o IKEv2 operation for securing DSMIPv6 Signaling. 1481 o IKEv2 operation for securing Data over IPv4 1483 6.2.1. IKEv2 Operation for Securing DSMIPv6 Signaling 1485 A mobile node connected to an IPv4-only network SHOULD follow the 1486 procedures described below in order to establish an SA for the 1487 protection of binding update and binding acknowledgement messages. 1489 Mobile Node Home Agent 1490 ----------- ---------- 1491 IPv4(source_addr=V4ADDR, dest_addr=HAADDR) 1492 UDP (500, 500) HDR, SAi1, KEi, Ni 1493 NAT-D, NAT-D --> 1495 <- IPv4(source_addr=HAADDR, dest_addr=V4ADDR) 1496 UDP(500,X) HDR, SAr1, KEr, Nr, [CERTREQ] 1497 NAT-D, NAT-D 1499 IPv4(source_addr=V4ADDR, dest_addr=HAADDR) 1500 UDP (4500,4500) HDR, SK 1501 {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, N(USE_TRANSPORT_MODE), 1502 SAi2, TSi, TSr} 1503 --> 1505 <-- IPv4(source_addr=HAADDR, dest_addr=V4ADDR) 1506 UDP (4500,Y) HDR, SK 1507 {IDr, [CERT,] AUTH, N(USE_TRANSPORT_MODE), 1508 SAr2, TSi, TSr} 1510 The corresponding SPD entries are shown below. 1512 Mobile node SPD-S: 1514 IF local_address = home_address_1 & 1516 remote_address = home_agent_1 & 1518 proto = MH & local_mh_type = BU & remote_mh_type = BAck Then use 1519 SA ESP transport mode 1521 Initiate using IDi = user_1 to address home_agent_1 1523 Home Agent SPD-S: 1525 F local_address = home_agent_1 & 1527 remote_address = home_address_1 & 1528 proto = MH & local_mh_type = BAck & remote_mh_type = BU Then use 1529 SA ESP transport mode 1531 where home_address_1 is the mobile node's registered IPv6 home 1532 address and home_agent_1 is the IP address of the home agent 1534 The above should result in BU/BA messages with the following BU 1535 received by the home agent. 1537 Pv4 header (src=V4ADDR, dst=HA_V4ADDR) 1539 UDP header (sport=Z, dport=DSMIPv6) 1541 IPv6 header (src=V6HOA, dst=HAADDR) 1543 ESP Header in Transport Mode 1545 Mobility header 1547 BU [IPv4 HAO] 1549 IPv4 CoA option 1551 (+ other as needed) 1553 At the home agent, following UDP de-capsulation, the binding update 1554 is delivered to the IPsec module as shown below: 1556 IPv6 header (src=V6HOA, dst=HAADDR) 1558 ESP Header in Transport Mode 1560 Mobility header 1562 BU [IPv4 HAO] 1564 IPv4 CoA option 1566 (+other as needed) 1568 In addition, V4ADDR and the sport (Z) need to be passed with the 1569 packet to ensure correct processing. 1571 Following IPsec processing, the binding update is delivered to the 1572 DSMIPv6 home agent module as follows: 1574 IPv6 header (src=V6HOA, dst=HAADDR) 1576 Mobility Header 1578 BU [IPv4 HAO] 1580 IPv4 CoA option 1582 (+other as needed) 1584 In addition, V4ADDR and the sport (Z) need to be passed with the 1585 packet to ensure correct processing. 1587 The binding acknowledgement sent by the home agent module to the 1588 IPsec module is as follows: 1590 IPv6 header (src=HAADDR, dst=V6HOA) 1592 Mobility Header 1594 BA ([IPv4 ACK], NAT DET) 1596 (+ other as needed) 1598 In addition, V4ADDR, the sport from the BU (Z), and aindication that 1599 vanilla UDP encapsulation must be used, need to be passed with the 1600 packet to ensure correct processing. 1602 The binding acknowledgement sent by the home agent to the mobile node 1603 is as follows: 1605 IPv4 header (src= HA_V4ADDR, dst=V4ADDR) 1607 UDP Header (sport=DSMIPv6, dport=Z) 1609 IPv6 header (src=HAADDR, dst=V6HOA) 1611 ESP Header in Transport Mode 1613 Mobility Header 1615 BA ([IPv4 ACK], NAT DET) 1617 6.2.2. IKEv2 Operation for Securing Data over IPv4 1619 To secure data traffic when the mobile node is located in an IPv4- 1620 only network, the mobile node MUST establish a child_SA for that 1621 purpose. The procedure is as follows: 1623 Mobile Node Home Agent 1624 ----------- ---------- 1625 IPv4(source_addr=V4ADDR, dest_addr=HAADDR) 1626 UDP (4500,4500) < non-ESP Marker > HDR, SK 1627 {[N], SA, Ni, [KEi], TSi, TSr} --> 1629 <--IPv4(source_addr=HAADDR, dest_addr=V4ADDR) 1630 UDP (4500,Y) < non-ESP Marker > HDR, SK 1631 SA, Nr, [KEr], TSi, TSr} 1633 If no NAT is detected, the encapsulation used will be: 1635 IPv4 (source_addr=v4CoA, dest_addr=HAAddr) 1637 ESP 1639 IP (source_addr=HoA, set_addr=CNAddr) 1641 Upper_layer_HDR 1643 where IP=IPv4 or IPv6 and HoA=v4HoA or v6HoA 1645 If a NAT were detected, the encapsulation used will be: 1647 IPv4 (source_addr=v4Addr, dest_addr=HAAddr) 1649 UDP (sport=Y, dport=4500) 1651 ESP 1653 IP (source_addr=HoA, set_addr=CNAddr) 1655 Upper_layer_HDR 1657 Where v4CoA may be the external IPv4 address of the NAT, IP is either 1658 IPv4 or IPv6 header and HoA is either the IPv4 or the IPv6 HoA. The 1659 above format shows the packet as seen by the home agent. 1661 The SPD, whether a NAT were detected or not, is set as follows. Note 1662 that this rule is designed to match all data from the MN to nodes 1663 other than the home agent. This is done so that this rule does not 1664 overlap with the earlier rule securing BU/BA signaling between the MN 1665 and the HA. 1667 Mobile Node SPD-S: 1669 IF local_address = home_address & 1671 remote_address != home_agent & 1673 proto=any, then use SA ESP tunnel mode 1675 Initiate using IDi = user_1 to address home_agent_1 1677 home agent SPD-S: 1679 IF local_address != home_agent & 1681 remote_address = home_address & 1683 proto=any, then use SA ESP tunnel mode 1685 Where home_address is the MN's registered IPv6 or IPv4 home address 1686 and home_agent is the IPv6 or the IPv4 address of the home agent. 1688 7. Protocol Constants 1690 NATKATIMEOUT 110 seconds 1692 8. Acknowledgements 1694 Thanks to the following members (in alphabetical order) of the MIP6 1695 and NEMO Working Groups for their contributions, discussion, and 1696 review: Jari Arkko, Sri Gundavelli, Wassim Haddad, Conny Larsson, 1697 Acee Lindem, Ahmad Muhanna, Vidya Narayanan, Karen Nielsen and 1698 Keiichi Shima. Thanks to Karen Nielsen, Pasi Eronen and Christian 1699 Kaas-Petersen for raising the issue of IKEv2 interactions and 1700 proposing the solution included in this document. 1702 9. IANA Considerations 1704 The specification requires the following allocations from IANA: 1706 A UDP port is needed for the NAT traversal mechanism described in 1707 section 4.1. 1709 The IPv4 home address option described in section 3.1.1 requires 1710 an option type. This option is included in the Mobility header 1711 described in [RFC3775]. 1713 The IPv4 address acknowledgement option described in section 3.2.1 1714 requires a new option type. This option is included in the 1715 Mobility header described in [RFC3775]. 1717 The NAT detection option described in section 3.2.2 requires a new 1718 option type. This option is included in the Mobility header 1719 described in [RFC3775]. 1721 The IPv4 Care-of address option described in section 3.1.2 1722 requires an option type. This option is included in the Mobility 1723 header described in [RFC3775]. 1725 This specification introduces a new TLV-header to be used with UDP 1726 encapsulation. The Types of the TLV-header should be allocated by 1727 IANA under a new registry: "DSMIPv6 TLV-header Types". 1729 The Status field in the IPv4 home address option should be allocated 1730 by IANA under the new registry: "DSMIPv6 IPv4 home address option 1731 status codes". 1733 The TLV-header types and status field values are allocated using the 1734 following procedure: 1736 1. The IANA should allocate and permanently register new TLV-header 1737 types and Status field values from IETF RFC publication. This is 1738 for all RFC types including standards track, informational, and 1739 experimental status that originate from the IETF and have been 1740 approved by the IESG for publication. 1742 2. Requests for new option type value assignments from outside the 1743 IETF are only made through the publication of an IETF document, 1744 per 1) above. Note also that documents published as "RFC Editor 1745 contributions" [RFC3667] are not considered to be IETF documents. 1747 10. References 1749 10.1. Normative References 1751 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1752 Requirement Levels", BCP 14, RFC 2119, March 1997. 1754 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 1755 Listener Discovery (MLD) for IPv6", RFC 2710, 1756 October 1999. 1758 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1759 in IPv6", RFC 3775, June 2004. 1761 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1762 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1763 RFC 3948, January 2005. 1765 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 1766 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 1767 RFC 3963, January 2005. 1769 [RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting 1770 Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006. 1772 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1773 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1774 September 2007. 1776 10.2. Informative 1778 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1779 of Explicit Congestion Notification (ECN) to IP", 1780 RFC 3168, September 2001. 1782 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 1783 August 2002. 1785 [RFC3519] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of 1786 Network Address Translation (NAT) Devices", RFC 3519, 1787 May 2003. 1789 [RFC3667] Bradner, S., "IETF Rights in Contributions", RFC 3667, 1790 February 2004. 1792 [RFC4140] Soliman, H., Castelluccia, C., El Malki, K., and L. 1793 Bellier, "Hierarchical Mobile IPv6 Mobility Management 1794 (HMIPv6)", RFC 4140, August 2005. 1796 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 1797 for IPv6 Hosts and Routers", RFC 4213, October 2005. 1799 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1800 Architecture", RFC 4291, February 2006. 1802 [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the- 1803 Network Tunneling", RFC 4459, April 2006. 1805 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 1806 (MOBIKE)", RFC 4555, June 2006. 1808 [RFC4977] Tsirtsis, G. and H. Soliman, "Problem Statement: Dual 1809 Stack Mobility", RFC 4977, August 2007. 1811 [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 1812 Bootstrapping in Split Scenario", RFC 5026, October 2007. 1814 Appendix A. Contributors 1816 This document reflects discussions and contributions from several 1817 people including (in alphabetical order): 1819 Vijay Devarapalli: vijay.devarapalli@azairenet.com 1821 James Kempf: kempf@docomolabs-usa.com 1823 Henrik Levkowetz: henrik@levkowetz.com 1825 Pascal Thubert: pthubert@cisco.com 1827 George Tsirtsis: G.Tsirtsis@Qualcomm.com 1829 Wakikawa Ryuji: ryuji@sfc.wide.ad.jp 1831 Author's Address 1833 Hesham Soliman (editor) 1834 Elevate Technologies 1836 Email: hesham@elevatemobile.com 1838 Full Copyright Statement 1840 Copyright (C) The IETF Trust (2008). 1842 This document is subject to the rights, licenses and restrictions 1843 contained in BCP 78, and except as set forth therein, the authors 1844 retain all their rights. 1846 This document and the information contained herein are provided on an 1847 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1848 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1849 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1850 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1851 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1852 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1854 Intellectual Property 1856 The IETF takes no position regarding the validity or scope of any 1857 Intellectual Property Rights or other rights that might be claimed to 1858 pertain to the implementation or use of the technology described in 1859 this document or the extent to which any license under such rights 1860 might or might not be available; nor does it represent that it has 1861 made any independent effort to identify any such rights. Information 1862 on the procedures with respect to rights in RFC documents can be 1863 found in BCP 78 and BCP 79. 1865 Copies of IPR disclosures made to the IETF Secretariat and any 1866 assurances of licenses to be made available, or the result of an 1867 attempt made to obtain a general license or permission for the use of 1868 such proprietary rights by implementers or users of this 1869 specification can be obtained from the IETF on-line IPR repository at 1870 http://www.ietf.org/ipr. 1872 The IETF invites any interested party to bring to its attention any 1873 copyrights, patents or patent applications, or other proprietary 1874 rights that may cover technology that may be required to implement 1875 this standard. Please address the information to the IETF at 1876 ietf-ipr@ietf.org.