idnits 2.17.1 draft-ietf-mext-nemo-v4traversal-01.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1521. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1492. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1499. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1505. 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 == Line 1295 has weird spacing: '...ception of au...' == Line 1297 has weird spacing: '...ibed in secti...' == Line 1305 has weird spacing: '...e agent to dy...' == Line 1308 has weird spacing: '...ter the mobil...' == Line 1318 has weird spacing: '...le that diffe...' == (2 more instances...) -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 857, but not defined == Missing Reference: 'IPv4 ACK' is mentioned on line 871, but not defined == Missing Reference: 'TLV-header' is mentioned on line 1006, but not defined == Missing Reference: 'RFC3667' is mentioned on line 1401, but not defined ** Obsolete undefined reference: RFC 3667 (Obsoleted by RFC 3978) ** Obsolete normative reference: RFC 3775 (ref. 'MIPv6') (Obsoleted by RFC 6275) == Outdated reference: A later version (-06) exists of draft-ietf-mip6-bootstrapping-integrated-dhc-02 -- Obsolete informational reference (is this intentional?): RFC 3344 (ref. 'MIPv4') (Obsoleted by RFC 5944) Summary: 3 errors (**), 0 flaws (~~), 12 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MEXT Working Group Hesham Soliman (Ed.) 3 INTERNET-DRAFT Elevate Technologies 4 Intended status: Standards Track 5 Expires: August 2008 6 February, 2008 8 Mobile IPv6 support for dual stack 9 Hosts and Routers (DSMIPv6) 10 draft-ietf-mext-nemo-v4traversal-01.txt 12 Status of this memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 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. Introduction.....................................................3 48 1.1 Motivation for using Mobile IPv6 only...........................3 49 1.2 Scenarios considered by this specification...................4 50 1.3 Terminology.................................................5 51 2. Solution overview................................................5 52 2.1. Home Agent Address Discovery...................................6 53 2.2. Mobile Prefix Solicitations and Advertisements..............7 54 2.3. Binding management.............................................7 55 2.3.1 Foreign network supports IPv6.................................7 56 2.3.2 Foreign network supports IPv4 only............................8 57 2.3.2.2 Visited network supports IPv4 only (private addresses)......9 58 2.4. Route optimization............................................10 59 2.5. Dynamic IPv4 home address allocation..........................10 60 3. Extensions and modifications to Mobile IPv6.....................10 61 3.1. Binding update extensions.....................................11 62 3.1.1 IPv4 home address option.....................................11 63 3.1.2 The IPv4 Care-of Address option........................12 64 3.1.3 The Binding Update Message extensions..................12 65 3.2. Binding Acknowledgement extensions............................13 66 3.2.1 IPv4 address acknowledgement option..........................13 67 3.2.2 The NAT detection option...............................14 68 3.2.3 Extensions to the Binding Acknowledgement message......15 69 4. Protocol operation..............................................15 70 4.1. Tunnelling formats.........................................15 71 4.2. NAT detection and traversal................................17 72 4.3. NAT Keepalives.............................................18 73 4.4. Mobile node operation.........................................19 74 4.4.1 Sending packets from a visited network.................20 75 4.4.2 Movement detection in IPv4-only networks...............21 76 4.5. Home agent operations.........................................21 77 4.5.1 Sending packets to the mobile node.....................23 78 4.6. Correspondent node operations.................................24 79 5. Security considerations.........................................24 80 5.1 Handover interactions for IPsec and IKE.....................25 81 6. Protocol constants..............................................28 82 7. Acknowledgements................................................28 83 8. IANA considerations.............................................28 84 9. References......................................................29 85 10. Contributors...................................................30 86 Author's Address...................................................30 88 1. Introduction 90 Mobile IPv6 [MIPv6] and [NEMO] allow mobile nodes to move within the 91 Internet while maintaining reachability and ongoing sessions, using 92 an IPv6 home address or prefix. However, since IPv6 is not widely 93 deployed, it is unlikely that mobile nodes will use IPv6 addresses 94 only for their connections. It is reasonable to assume that mobile 95 nodes will, for a long time, need an IPv4 home address that can be 96 used by upper layers. It is also reasonable to assume that mobile 97 nodes will move to networks that might not support IPv6 and would 98 therefore need the capability to support an IPv4 Care-of Address. 99 Hence, this specification extends Mobile IPv6 capabilities to allow 100 dual stack mobile nodes to request that their home agent (also dual 101 stacked) tunnel IPv4/IPv6 packets addressed to their home addresses, 102 as well as IPv4/IPv6 care-of address(es). 104 Using this specification, mobile nodes would only need Mobile IPv6 105 and [NEMO] to manage mobility while moving within the Internet; hence 106 eliminating the need to run two mobility management protocols 107 simultaneously. This specification provides the extensions needed in 108 order to allow IPv6 mobility only to be used by dual stack mobile 109 nodes. 111 This specification will also consider cases where a mobile node moves 112 into a private IPv4 network and gets configured with a private IPv4 113 Care-of Address. In these scenarios, the mobile node needs to be able 114 to traverse the IPv4 NAT in order to communicate with the home agent. 115 IPv4 NAT traversal for Mobile IPv6 is presented in this 116 specification. 118 In this specification, the term mobile node refers to both a mobile 119 host and mobile router unless the discussion is specific to either 120 hosts or routers. Similarly, we use the term home address to reflect 121 an address/prefix format. 123 In this specification, extensions are defined for the binding update 124 and binding acknowledgement. It should be noted that all these 125 extensions apply to cases where the mobile node communicates with a 126 Mobility Anchor Point (MAP) as defined in [HMIPv6]. The requirements 127 on the MAP are identical to those stated for the home agent, although 128 it is unlikely that NAT traversal would be needed with a MAP as it is 129 expected to be in the same address domain. 131 1.1 Motivation for using Mobile IPv6 only 133 IPv6 offers a number of improvements over today's IPv4, primarily due 134 to its large address space. Mobile IPv6 offers a number of 135 improvements over Mobile IPv4 [MIPv4], mainly due to capabilities 136 inherited from IPv6. For instance, route optimization and dynamic 137 home agent discovery can only be achieved with Mobile IPv6. 139 One of the advantages of the large address space provided by IPv6 is 140 that it allows mobile nodes to obtain a globally unique care-of 141 address wherever they are. Hence, there is no need for Network 142 Address Translator (NAT) traversal techniques designed for Mobile 143 IPv4. This allows Mobile IPv6 to be a significantly simpler and more 144 bandwidth efficient mobility management protocol. At the same time, 145 during the transition towards IPv6, NAT traversal for existing 146 private IPv4 networks needs to be considered. This specification 147 introduces NAT traversal for this purpose. 149 The above benefits make the case for using Mobile IPv6 only for dual 150 stack mobile nodes in order to allow for a long lasting mobility 151 solution and minimize the need to changing the mobility stack due to 152 the introduction of IPv6 within a deployed network. 154 1.2 Scenarios considered by this specification 156 In [SNRIO] several scenarios that illustrate potential 157 incompatibilities for mobile nodes using Mobile IPv6 were discussed. 158 Some of the problems associated with mobility and transition issues 159 were presented in [MIP-PB]. This specification considers a subset of 160 the scenarios in [SNRIO], which address all the problems discussed in 161 [MIP-PB]. The scenarios considered in this specification are listed 162 below. 164 All of the following scenarios assume that both the mobile node and 165 the home agent are IPv4 and IPv6-enabled and that only Mobile IPv6 is 166 used between the mobile node and the home agent. We also assume that 167 the home agent is always reachable through a globally unique IPv4 168 address. Finally, it's important to note that the following scenarios 169 are not mutually exclusive. 171 Scenario 1: IPv4-only foreign network 173 In this scenario, a mobile node is connected to an IPv4-only foreign 174 network. The mobile node can only configure an IPv4 Care-of Address. 176 Scenario 2: Mobile node behind a NAT 178 In this scenario, the mobile node is in a private IPv4 foreign 179 network that has a NAT device connecting it to the Internet. If the 180 home agent is located outside the NAT device, the mobile node will 181 need a NAT traversal mechanism to communicate with the home agent. 183 Scenario 3: Home Agent behind a NAT 185 In this scenario, the communication between the mobile node and the 186 home agent is further complicated by the fact that the home agent is 187 located within a private IPv4 network. However, in this scenario, we 188 assume that the home agent is allocated a globally unique IPv4 189 address. The address might not be physically configured on the home 190 agent interface. Instead, it is associated with the home agent on the 191 NAT device, which allows the home agent to be reachable through 192 address or port mapping. 194 Scenario 4: Use Of IPv4-only applications 196 In this scenario, the mobile node may be located in an IPv4, IPv6 or 197 a dual network. However, the mobile node might be communicating with 198 an IPv4-only node. In this case, the mobile node would need a stable 199 IPv4 address for its application. The alternative to using an IPv4 200 address is the use of protocol translators; however, end-to-end 201 communication with IPv4 is preferred to the use of protocol 202 translators. 204 The mobile node may also be communicating with an IPv4-only 205 application that requires an IPv4 address. 207 The cases above illustrate the need for the allocation of a stable 208 IPv4 home address to the mobile node. This is done using an IPv4 home 209 address. Since running Mobile IPv4 and Mobile IPv6 simultaneously is 210 problematic (as illustrated in [MIP-PB]), this scenario adds a 211 requirement on Mobile IPv6 to support IPv4 home addresses. 213 1.3 Terminology 215 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 216 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 217 document are to be interpreted as described in [KEYWORDS]. 219 2. Solution overview 221 In order to allow Mobile IPv6 to be used by dual stack mobile nodes, 222 the following needs to be done: 224 - Mobile nodes should be able to use an IPv4 and IPv6 home or care-of 225 address simultaneously and update their home agents accordingly. 227 - Mobile nodes need to be able to know the IPv4 address of the home 228 agent as well as its IPv6 address. There is no need for IPv4 prefix 229 discovery however. 231 - Mobile nodes need to be able to detect the presence of a NAT device 232 and traverse it in order to communicate with the home agent. 234 This section presents an overview of the extensions required in order 235 to allow mobile nodes to use Mobile IPv6 only for IP mobility 236 management. 238 2.1. Home Agent Address Discovery 240 Dynamic home agent Address Discovery (DHAAD) was defined in [MIPv6] 241 to allow mobile nodes to discover their home agents by appending a 242 well-known anycast interface identifier to their home link's prefix. 243 However, this mechanism is based on IPv6-anycast routing. If a mobile 244 node is located in an IPv4-only foreign network, it cannot rely on 245 native IPv6 routing. In this scenario, the solution for discovering 246 the home agent's IPv4 address is through the Domain Name System 247 (DNS). If the MN is attached to an IPv6-only or dual stack network, 248 it may also use procedures defined in [INTBOOT] to discover home 249 agent information. Note that the use of [INTBOOT] cannot give the 250 mobile node information that allows it to continue to communicate 251 with the home agent if, for example, the mobile node moved from an 252 IPv6-enabled network to an IPv4-only network. In this scenario, the 253 mobile node would need to discover the IPv4 address of its home agent 254 through the DNS. 256 For DNS lookup by name, the mobile node should be configured with the 257 name of the home agent. When the mobile node needs to discover a 258 home agent, it sends a DNS request with QNAME set to the configured 259 name. An example is "ha1.example.com". If a home agent has an IPv4 260 and IPv6 address, the corresponding DNS record should be configured 261 with both 'AAAA' and 'A' records. Accordingly, the DNS reply will 262 contain 'AAAA' and 'A' records. 264 For DNS lookup by service, the SRV record defined in [BOOT] is 265 reused. For instance, if the service name is "mip6" and the protocol 266 name is "ipv6" in the SRV record, the mobile node SHOULD send a DNS 267 request with the QNAME set to "_mip6ha._ipv6.example.com". The 268 response should contain the home agent's FQDN(s) and may include the 269 corresponding 'AAAA' and 'A' records as well. 271 If multiple home agents reside on the home link, each configured with 272 a public IPv4 address, then the operation above applies. In case the 273 home agents are behind a NAT box, there are two options, 1) configure 274 a public IPv4 address for each home agent on the NAT box, 2) 275 configure one public address and make the home agents share the 276 public address. In either case, the correct DNS entries can be 277 configured. Another possible solution is to designate one home agent 278 on the home link for IPv4 traversal. The NAT device should associate 279 that home agent with the public IPv4 address configured on it for v4 280 traversal. In all cases above, both the 'AAAA' and 'A' records 281 returned for a particular name MUST correspond to the same physical 282 home agent; otherwise the mobile node will not be able to bind its 283 addresses correctly. 285 2.2. Mobile Prefix Solicitations and Advertisements 287 According to [MIPv6], the mobile node can send a Mobile Prefix 288 Solicitation and receive a Mobile Prefix Advertisement containing all 289 prefixes advertised on the home link. 291 A dual stack mobile node MAY send a Mobile Prefix Solicitation 292 message encapsulated in IPv4 (i.e., IPv6 in IPv4) in the case where 293 the mobile node has no access to IPv6 within the local network. 294 Securing these messages requires the mobile node to have a security 295 association with the home agent, using IPsec (AH or ESP) and based on 296 the mobile node's IPv4 care-of address as described in [MIPv6]. Since 297 the mobile node needs to encapsulate all IPv6 traffic sent to the 298 home agent into IPv4 while located in an IPv4-only visited network, 299 this SA would match all packets if the selectors were based on the 300 information in the outer header. That is, the SA selectors being the 301 protocol number (protocol is always IP in IP), as well as, source and 302 destination addresses are all common to all packets. If this effect 303 is not desired, the mobile node can base the SA on the information in 304 the inner header (i.e., using the home agent's IPv6 address, the 305 mobile node's home address and the ICMP protocol number). This 306 security association would use transport mode ESP protection. 308 2.3. Binding management 310 A dual stack mobile node will need to update its home agent with its 311 care-of address. If a mobile node has an IPv4 and an IPv6 home 312 address, it will need to create a binding cache entry for each 313 address. The format of the IP packet carrying the binding update and 314 acknowledgement messages will vary depending on whether the mobile 315 node has access to IPv6 in the visited network. There are three 316 different scenarios to consider with respect to the visited network: 318 A. The visited network has IPv6 connectivity and provides the mobile 319 node with a care-of address (in a stateful or stateless manner). 321 B. The mobile node can only configure a globally unique IPv4 address 322 in the visited network. 323 C. The mobile node can only configure a private IPv4 address in the 324 visited network. 326 2.3.1 Foreign network supports IPv6 328 In this case, the mobile node is able to configure a globally unique 329 IPv6 address. The mobile node will send a binding update to the IPv6 330 address of its home agent, as defined in [MIPv6]. The binding update 331 MAY include the IPv4 home address option introduced in this document. 332 After receiving the binding update, the home agent creates two 333 binding cache entries, one for the mobile node's IPv4 home address, 334 and another for the mobile node's IPv6 home address. Both entries 335 will point to the mobile node's IPv6 care-of address. Hence, whenever 336 a packet is addressed to the mobile node's IPv4 or IPv6 home 337 addresses, the home agent will tunnel it in IPv6 to the mobile node's 338 IPv6 care-of address included in the binding update. Effectively, the 339 mobile node establishes two different tunnels, one for its IPv4 340 traffic (IPv4 in IPv6) and one for its IPv6 traffic (IPv6 in IPv6) 341 with a single binding update. The security implications of this 342 mechanism are discussed in the security considerations section. 344 In this scenario, the only addition to [MIPv6] is the inclusion of 345 the IPv4 home address option in the binding update message. 347 After accepting the binding update and creating the corresponding 348 binding cache entries, the home agent MUST send a binding 349 acknowledgement to the mobile node as defined in [MIPv6]. In 350 addition, if the binding update included an IPv4 home address option, 351 the binding acknowledgement MUST include the IPv4 address 352 acknowledgment option as described later in this specification. This 353 option informs the mobile node whether the binding was accepted for 354 the IPv4 home address. If this option is not included in the binding 355 acknowledgement and the IPv4 home address option was included in the 356 binding update, the mobile node MUST assume that the home agent does 357 not support the IPv4 home address option and therefore SHOULD NOT 358 include the option in future binding updates to that home agent 359 address. 361 When a mobile node acquires both IPv4 and IPv6 care-of addresses at 362 foreign network, it SHOULD prioritize IPv6 care-of address for MIP6 363 binding registration. The mobile node MUST NOT register both IPv4 and 364 IPv6 care-of addresses to its home agent. 366 2.3.2 Foreign network supports IPv4 only 368 If the mobile node is in a foreign network that only supports IPv4, 369 it needs to detect whether a NAT is in its communication path to the 370 home agent. This is done while exchanging the binding update and 371 acknowledgement messages as shown later in this document. If no NAT 372 is detected between the mobile node and the home agent, the mobile 373 node assumes that it is in a foreign network that supports IPv4 374 public addresses. Otherwise, the mobile node assumes that private 375 addresses are used in the foreign network. Note that this assumption 376 is only valid for the purposes of the signaling presented in this 377 specification. A mobile node SHOULD NOT assume that its IPv4 address 378 is globally unique if a NAT device was not detected. The operations 379 of both cases are discussed below. 381 2.3.2.1 Foreign network supports IPv4 only (public addresses) 383 In this scenario the mobile node will need to tunnel IPv6 packets 384 containing the binding update to the home agent's IPv4 address. The 385 mobile node uses the IPv4 address it gets from the foreign network as 386 a source address in the outer header. The binding update will contain 387 the mobile node's IPv6 home address. However, since the care-of 388 address in this scenario is the mobile node's IPv4 address, the 389 mobile node MUST include its IPv4 care-of address in the IPv6 packet. 390 The IPv4 address is represented in the IPv4 Care-of address option 391 defined in this specification. If the mobile node had an IPv4 home 392 address, it MUST also include the IPv4 home address option described 393 in this specification. 395 After accepting the binding update, the home agent MUST create a new 396 binding cache entry for the mobile node's IPv6 home address. If an 397 IPv4 home address option were included, the home agent MUST create 398 another entry for that address. All entries MUST point to the mobile 399 node's IPv4 care-of address. Hence, all packets addressed to the 400 mobile node's home address(es) (IPv4 or IPv6) will be encapsulated in 401 an IPv4 header that includes the home agent's IPv4 address in the 402 source address field and the mobile node's IPv4 care-of address in 403 the destination address field. 405 After accepting the binding updates and creating the corresponding 406 entries, the home agent MUST send a binding acknowledgement as 407 specified in [MIPv6]. In addition, if the binding update included an 408 IPv4 home address option, the binding acknowledgement MUST include 409 the IPv4 address acknowledgment option as described later in this 410 specification. The binding acknowledgement is encapsulated to the 411 IPv4 care-of address, which was included in the source address field 412 of the IPv4 header encapsulating the binding update. 414 2.3.2.2 Visited network supports IPv4 only (private addresses) 416 In this scenario the mobile node will need to tunnel IPv6 packets 417 containing the binding update to the home agent's IPv4 address. In 418 order to traverse the NAT device, IPv6 packets are tunneled UDP and 419 IPv4. The UDP port allocated for the home agent is TBA. 421 The mobile node uses the IPv4 address it gets from the visited 422 network as a source address in the IPv4 header. The binding update 423 will contain the mobile node's IPv6 home address. 425 After accepting the binding update, the home agent MUST create a new 426 binding cache entry for the mobile node's IPv6 home address. If an 427 IPv4 home address option were included, the home agent MUST create 428 another entry for that address. All entries MUST point to the mobile 429 node's IPv4 care-of address included in the source address of the 430 IPv4 header that encapsulated the binding update message. In 431 addition, the tunnel used MUST indicate UDP encapsulation for NAT 432 traversal. Hence, all packets addressed to the mobile node's home 433 address(es) (IPv4 or IPv6) will be encapsulated in UDP then 434 encapsulated in an IPv4 header that includes the home agent's IPv4 435 address in the source address field and the mobile node's IPv4 care- 436 of address in the destination address field. 438 After accepting the binding updates and creating the corresponding 439 entries, the home agent MUST send a binding acknowledgement as 440 specified in [MIPv6]. In addition, if the binding update included an 441 IPv4 home address option, the binding acknowledgement MUST include 442 the IPv4 address acknowledgment option as described later in this 443 specification. The binding acknowledgement is encapsulated in UDP 444 then IPv4 with the home agent's IPv4 address in the source address 445 field and the mobile node's IPv4 care-of address in the destination 446 field. The IPv4 address in the destination field of the IPv4 packet 447 is the source address received in the IPv4 header containing the 448 binding update message. The inner IPv6 packet will contain the home 449 agent's IPv6 address as a source address and the mobile node's IPv6 450 home address in the destination address field. 452 The mobile node needs to maintain the NAT bindings for its current 453 IPv4 care-of address. This is done through sending the binding update 454 regularly to the home agent. 456 2.4. Route optimization 458 Route optimization, as specified in [MIPv6] will operate in an 459 identical manner for dual stack mobile nodes when they are located in 460 a visited network that provides IPv6 addresses to the mobile node. 461 However, when located in an IPv4-only network, route optimization 462 will not be possible due to the difficulty of performing the care-of 463 address test. Therefore, mobile nodes will need to communicate 464 through the home agent. 466 Route optimization will not be possible for IPv4 traffic. That is, 467 traffic addressed to the mobile node's IPv4 home address. This is 468 similar to using Mobile IPv4, therefore there is no reduction of 469 features resulting from using this specification. 471 2.5. Dynamic IPv4 home address allocation 473 It is possible to allow for the mobile node's IPv4 home address to be 474 allocated dynamically. This is done by including 0.0.0.0 in the IPv4 475 home address option included in the binding update. The home agent 476 SHOULD allocate an IPv4 address to the mobile node and include it in 477 the IPv4 address acknowledgement option sent to the mobile node. In 478 this case, the lifetime of the binding is bound to the minimum of the 479 lifetimes of the IPv6 binding and the lease time of the IPv4 home 480 address. 482 3. Extensions and modifications to Mobile IPv6 484 This section highlights the protocol and implementation additions 485 required to support this specification. 487 3.1. Binding update extensions 489 3.1.1 IPv4 home address option 491 This option is included in the Mobility Header including the binding 492 update message sent from the mobile node to a home agent or Mobility 493 Anchor Point. The alignment requirement for this option is 4n. 495 0 1 2 3 496 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 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | Type | Length |Prefix-len |P| Reserved | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | IPv4 home address | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 Type TBD 505 Length 6 507 Prefix-len The length of the prefix allocated to the mobile 508 node. If only a single address is allocated, 509 this field MUST be set to 32. In the first 510 binding update requesting a prefix, the field 511 contains the prefix length requested. However, 512 in the following binding updates, this field 513 must contain the length of the prefix allocated. 514 A value of zero is invalid and MUST be 515 considered an error. 517 P A flag indicating, when set, that the mobile 518 node requests a mobile network prefix. This flag 519 is only relevant for new requests, and must be 520 ignored for binding refreshes. 522 Reserved This field is reserved for future use. It MUST 523 be set to zero by the sender and ignored by the 524 receiver. 526 IPv4 home address The mobile node's IPv4 home address that should 527 be defended by the home agent. This field could 528 contain any unicast IPv4 address (public or 529 private) that was assigned to the mobile node. 530 The value 0.0.0.0 is used to request an IPv4 531 home address from the home agent. A mobile node 532 may choose to use this option to request a 533 prefix by setting the address to the All Zeroes 534 and setting the P flag. The mobile node could 535 then form an IPv4 home address based on the 536 allocated prefix. Alternatively, the mobile node 537 may use two different options, one for 538 requesting an address (Static or Dynamic) and 539 another for requesting a prefix. 541 3.1.2 The IPv4 Care-of Address option 543 This option is included in the Mobility Header including the binding 544 update message sent from the mobile node to a home agent or Mobility 545 Anchor Point. The alignment requirement for this option is 4n. 547 0 1 2 3 548 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 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | Type | Length | Reserved | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | IPv4 Care-of address | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 Type TBD 557 Length 6 559 Reserved This field is set to zero by the sender and 560 ignored by the receiver. 562 IPv4 care-of address This field contains the mobile node's IPv4 care- 563 of address. The IPv4 care-of address is used 564 when the mobile node is located in an IPv4-only 565 network. 567 3.1.3 The Binding Update Message extensions 569 This specification extends the Binding Update message with two new 570 flags. The flags are shown and described below. 572 0 1 2 3 573 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 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | Sequence # | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 |A|H|L|K|M|R|F|T| Reserved | Lifetime | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 F When set, this flag indicates a request for 581 forcing UDP encapsulation regardless of whether 582 a NAT is present on the path between the mobile 583 node and the home agent. 585 T When set, this flag indicates that the mobile 586 node requests the use of the TLV-format for 587 encapsulating IPv6 in IPv4. The TLV-format is 588 described later in this document. 590 3.2. Binding Acknowledgement extensions 592 3.2.1 IPv4 address acknowledgement option 594 This option is included in the Mobility Header including the binding 595 acknowledgement message sent from the home agent or Mobility Anchor 596 Point to the mobile node. This option indicates whether a binding 597 cache entry was created for the mobile node's IPv4 address. 598 Additionally, this option can include an IPv4 home address in the 599 case of Dynamic IPv4 home address configuration (i.e., if the 600 unspecified IPv4 address was included in the binding update). The 601 alignment requirement for this option is 4n. 603 0 1 2 3 604 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 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | Type | Length | Status |Pref-len |Res| 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | IPv4 home address | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 Type TBD 613 Length 6 615 Status Indicates success or failure for the IPv4 home 616 address binding. Values from 0 to 127 indicate 617 success. Higher values indicate failure. The 618 following values are reserved: 619 0 Success 620 128 Failure, reason unspecified 621 129 Administratively prohibited 622 130 Incorrect IPv4 home address 623 131 Invalid IPv4 address 624 132 Dynamic IPv4 home address 625 assignment not available 626 133 Prefix allocation unauthorized 628 Pref-len The prefix length of the address allocated. This 629 field is only valid in case of success and MUST 630 be set to zero and ignored in case of failure. 631 This field overrides what the mobile node 632 requested (if not equal to the requested 633 length). 635 Res This field is reserved for future use. It MUST 636 be set to zero by the sender and ignored by the 637 receiver. 639 IPv4 home address The IPv4 home address that the home agent will 640 use in the binding cache entry. This could be a 641 public or private address. This field MUST 642 contain the mobile node's IPv4 home address. 643 If the address were dynamically allocated the 644 home agent will add the address to inform the 645 mobile node. Otherwise, if the address were 646 statically allocated to the mobile node, the 647 home agent will copy it from the binding update 648 message. 650 3.2.2 The NAT detection option 652 This option is sent from the home agent to the mobile node to 653 indicate whether a NAT was in the path. This option MAY also include 654 a suggested NAT binding refresh time for the mobile node. The 655 alignment requirement for this option is 4n. If a NAT is detected, 656 this option MUST be sent by the home agent. 658 0 1 2 3 659 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 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | Type | Length |F| Reserved | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | Refresh time | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 Type TBD 668 Length 6 670 F This flag indicates to the mobile node that UDP 671 encapsulation is required. When set, this flag 672 indicates that the mobile node MUST use UDP 673 encapsulation even if a NAT is not located 674 between the mobile node and home agent. 676 Reserved This field is reserved for future use. It MUST 677 be set to zero by the sender and ignored by the 678 receiver. 680 Refresh time A suggested time (in seconds) for the mobile 681 node to refresh the NAT binding. If set to zero, 682 it is ignored. If this field is set to the all 683 1s it means that keepalives are not needed, 684 i.e., 685 no NAT was detected. 687 3.2.3 Extensions to the Binding Acknowledgement message 689 This specification extends the binding acknowledgement message with a 690 new flag. The new flag is shown and described below. 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | Status |K|R|T| Reserved| 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 | Sequence # | Lifetime | 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 T This flag indicates, when set, that the sender 699 of the binding acknowledgement supports the TLV- 700 tunnel format. 702 4. Protocol operation 704 This section presents the protocol operation and processing for the 705 messages presented above. In addition, this section introduces the 706 NAT detection and traversal mechanism used by this specification. 708 4.1. Tunnelling formats 710 This speacification allows two different types of UDP-based 711 tunnelling formats to be used between the mobile node and its home 712 agent or MAP. The two formats are vanilla UDP encapsulation and TLV- 713 header UDP encapsulation. A vanilla UDP encapsulation format means 714 the following order of headers: 715 IPv4 716 UDP 717 IP (v4 or v6) 718 Other headers 720 When using this format the receiver would parse the version field 721 following the UDP header in order to determine whether the following 722 header is IPv4 or IPv6. The rest of the headers are processed 723 normally. The above order of headers does not take IPsec headers into 724 account as they may be placed in different parts of the packet. The 725 above format MUST be supported by all implementations of this 726 specification and MUST always be used to send the binding update 727 message. 729 A TLV-header UDP encapsulation is represented by the following order 730 of headers: 731 IP (v4 or v6) 732 UDP 733 TLV-header 734 Other headers 736 The receiver of the TLV-header UDP encapsulated packet expects the 737 TLV-header to follow UDP. The TLV header contains the type of the 738 following message and its length. Hence, the TLV header can carry 739 traffic other than IP. 741 The mobile node negotiates the format for tunnelling payload traffic 742 during the binding exchange. If a mobile node prefers to use the TLV- 743 header UDP encapsulation, it sets the T flag in the binding update 744 sent to the home agent or MAP. If the receiver of the binding update 745 supports the TLV-header format, it SHOULD set the T flag in the 746 binding acknowledgement message. Otherwise, the T flag is cleared. 747 The setting of the T flag in the binding acknowledgement indicates to 748 the mobile node that it must use the TLV-header UDP encapsulation 749 format for all packets sent for the duration of the binding or until 750 a new binding update is sent. Each binding update may renegotiate the 751 tunnelling format. To avoid interoperability issues, the sender of 752 the binding acknowledgement MUST NOT set the T flag unless it was set 753 in the binding update sent from the mobile node. 755 The TLV-header format is shown below. 757 0 1 2 3 758 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 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 | Type | Length | Reserved | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 Type This field indicates the type of the payload 764 following this header. 766 Length This field indicates the length of the payload 767 following the header, excluding the TLV-header 768 itself. 770 Reserved This field MUST be set to zero by the sender and 771 ignored by the receiver. 773 The following values are assigned to the Type field, other values may 774 be assigned in future: 776 1 IPv4 777 2 IPv6 778 3 IPsec 779 4 GRE 781 In addition to the UDP-based tunnelling formats described above, this 782 specification allows for standard IP in IP tunnelling. This can take 783 place by tunnelling IPv4 in IPv6 or IPv6 in IPv4. However, whenever a 784 NAT a detected, the mobile node will default to UDP-based 785 encapsulation. The mobile node can request to always use UDP 786 encapsulation by setting the F flag in the binding update. If the 787 home agent does not agree to the request, it MUST reject the binding 788 update with the new Status code: 790 144 Cannot force UDP encapsulation 791 Alternatively, the home agent can force UDP encapsulation by setting 792 the F flag in the NAT detection option included in the binding 793 acknowledgement. 795 4.2. NAT detection and traversal 797 NAT detection is done when the initial binding update message is sent 798 from the mobile node to the home agent. When located in an IPv4-only 799 foreign link, the mobile node sends the binding update message 800 encapsulated in UDP and IPv4. The source address of the IPv6 packet 801 is the mobile node's IPv6 home address. The destination address is 802 the IPv6 address of the home agent. The IPv4 header contains the IPv4 803 care-of address in the source address field and the IPv4 address of 804 the home agent in the destination address field. 806 When the home agent receives the encapsulated binding update it 807 compares the IPv4 address of the source address field in the IPv4 808 header with the IPv4 address included in the IPv4 care-of address 809 option. If the two addresses match, no NAT device was in the path. 810 Otherwise, a NAT device was in the path and the NAT detection option 811 is included in the binding acknowledgement. The binding 812 acknowledgement, and all future packets, are then encapsulated in UDP 813 and IPv4. The source address in the IPv4 header is the IPv4 address 814 of the home agent. The destination address is the IPv4 address 815 received in the IPv4 header encapsulating the binding update (this 816 address will be different from the IPv4 care-of address when a NAT is 817 in the path). The source port in the packet is the home agent's 818 source port. The destination port is the source port received in the 819 binding update message. Note that the home agent stores the port 820 numbers and associates them with the mobile node's tunnel in order to 821 forward future packets. 823 Upon receiving the binding acknowledgement with the NAT detection 824 option, the mobile node sets the tunnel to the home agent to UDP 825 encapsulation. Hence, all future packets to the home agent are 826 tunneled in UDP and IPv4. For all tunneled IPv6 packets, the source 827 address in the IPv6 header is the mobile node's IPv6 home address and 828 the destination address is the correspondent node's IPv6 address. All 829 tunneled IPv4 packets will contain the mobile node's IPv4 home 830 address in the source address field of the inner IPv4 packet and the 831 correspondent node's IPv4 address in the destination address field. 832 The outer IPv4 header is the same whether the inner packet is IPv4 or 833 IPv6. 835 If no NAT device was detected in the path between the mobile node and 836 the home agent then IPv6 packets are tunneled in an IPv4 header, 837 unless the home agent forces UDP encapsulation using the F flag. The 838 content of the inner and outer headers are identical to the UDP 839 encapsulation case. 841 A mobile node MUST always tunnel binding updates in UDP when located 842 in an IPv4-only network. Essentially, this process allows for 843 perpetual NAT detection. Similarly, the home agent MUST encapsulate 844 binding acknowledgements in a UDP header whenever the binding update 845 is encapsulated in UDP. 847 In conclusion, the packet formats for the binding update and 848 acknowledgement messages are shown below: 850 A. Binding update received by the home agent: 852 IPv4 header (src=V4ADDR, dst=HA_V4ADDR) 853 UDP header 854 IPv6 header (src=V6HOA, dst=HAADDR) 855 ESP-header 856 Mobility header 857 BU [IPv4 HAO] 858 IPv4 CoA option 860 Where V4ADDR is either the IPv4 care-of address or the address 861 provided by the NAT device. V6HOA is the IPv6 home address of the 862 mobile node. The binding update MAY also contain the IPv4 home 863 address option IPv4 HAO. 865 B. Binding acknowledgement sent by the home agent: 866 IPv4 header (src= HA_V4ADDR, dst=V4ADDR) 867 UDP header 868 IPv6 header (src=HAADDR, dst=V6HOA) 869 ESP-header 870 Mobility header 871 BA ([IPv4 ACK], NAT DET) 873 Where V6HOA is IPv6 home address of the mobile node. The IPv4 ACK is 874 the IPv4 address acknowledgement option, which is only included if 875 the IPv4 home address option were present in the BU. The NAT DET is 876 the NAT detection option, which MUST be present in the binding 877 acknowledgement message if the binding update was encapsulated in 878 UDP. 880 4.3. NAT Keepalives 882 If a NAT is detected, the mobile node will need to refresh the NAT 883 bindings in order to be reachable from the home agent. NAT bindings 884 can be refreshed through sending and receiving traffic encapsulated 885 in UDP. However, if the mobile node is not active, it will need to 886 periodically send a message to the home agent in order to refresh the 887 NAT binding. This can be done using the binding update message. The 888 binding update/acknowledgement pair will ensure that the NAT bindings 889 are refreshed in a reliable manner. There is no way for the mobile 890 node to know the exact time of the NAT binding. The default time 891 suggested in this specification is NATKATIMEOUT. If the home agent 892 suggests a different refresh period in the binding acknowledgement, 893 the mobile node SHOULD use the value suggested by the home agent. 895 If the refresh time in the NAT detection option in the binding 896 acknowledgement is set to the all 1s, the mobile node need not send 897 messages to refresh the NAT binding. However, the mobile node may 898 still be required to encapsulate traffic in UDP. This scenario may 899 take place when a NAT is not detected, but the home agent still 900 requires the mobile node to use UDP encapsulation. 902 It should be noted that a mobile node that does not need to be 903 reachable (i.e., only cares about the session continuity aspect of 904 Mobile IP) does not need to refresh NAT binding. In this case, the 905 mobile node would only be able to initiate communication with other 906 nodes. However, this is likely to imply that the mobile node will 907 need to send a binding update before initiating communication after a 908 long idle period as it is likely to be assigned a different port and 909 IPv4 address when it initiates communication. Hence, an 910 implementation may choose, for the sake of simplicity, to always 911 maintain the NAT bindings even when it does not need reachability. 913 4.4. Mobile node operation 915 In addition to the operations specified in [MIPv6] and [NEMO], this 916 specification requires mobile nodes to be able to support an IPv4 917 home address. 919 When sending an IPv6 packet containing a binding update while 920 connected to an IPv4-only access network, mobile nodes MUST ensure 921 the following: 923 - The IPv6 packet is encapsulated in the vanilla UDP encapsulation 924 format. 925 - The source address in the IPv4 header is the mobile node's IPv4 926 care-of address 927 - The destination address in the IPv4 header is the home agent's 928 IPv4 address. 929 - The source address in the IPv6 header is the mobile node's IPv6 930 home address. 931 - The IPv4 home address option MAY be included in the mobility 932 header. This option contains the IPv4 home address. If the mobile 933 node did not have a static home address it MAY include the 934 unspecified IPv4 address, which acts as a request for a dynamic 935 IPv4 home address. Alternatively, one or more IPv4 home address 936 options may be included with requests for IPv4 prefixes (i.e., with 937 the P flag set.). 938 - If the mobile node wishes to use UDP encapsulation only, it should 939 set the F flag in the binding update message. 940 - If the mobile node prefers to use the TLV-header format, it should 941 set the T flag in the binding update. 942 - The IPv6 packet MUST be authenticated as per [MIPv6], based on the 943 mobile node's IPv6 home address. 945 When sending a binding update from a visited network that supports 946 IPv6, the mobile node MUST follow the rules specified in [MIPv6]. In 947 addition, if the mobile node has an IPv4 home address or needs one, 948 it MUST include the IPv4 home address option in the mobility header. 949 If the mobile node already has a static IPv4 home address, this 950 address MUST be included in the IPv4 home address option. Otherwise, 951 if the mobile node needs a dynamic IPv4 address, it MUST include the 952 IPv4 0.0.0.0 address in the IPv4 home address option. 954 When the mobile node receives a binding acknowledgement from the home 955 agent, it follows the rules in [MIPv6] and [NEMO]. In addition, the 956 following actions MUST be made: 958 - If the status field indicated failure with error code 144, the 959 mobile node MAY resend the binding update without setting the F 960 flag. 961 - If the mobility header includes an IPv4 address acknowledgement 962 option indicating success, the mobile node should create two 963 entries in its binding update list, one for the IPv6 home address 964 and another for the IPv4 home address. 965 - If the NAT detection option were present, the mobile node 966 MUST tunnel future packets in UDP and IPv4. This MUST be indicated 967 in the binding update list. 968 - If no IPv4 address acknowledgement option were present, and an 969 IPv4 home address option was present in the binding update, the 970 mobile node MUST only create one binding update list entry for its 971 IPv6 home address. The mobile node MAY include the IPv4 home 972 address option in future binding updates. 973 - If an IPv4 address acknowledgement option were present and it 974 indicates failure for the IPv4 home address binding, the mobile 975 node MUST NOT create an entry for that address in its binding 976 update list. The mobile node MAY include the IPv4 home address 977 option in future binding updates. 978 - If the T flag was set in the binding update and the binding 979 acknowledgement included the T flag set, the mobile node MUST use 980 the TLV-header UDP encapsulation format. 982 4.4.1 Sending packets from a visited network. 984 When the mobile node is located in an IPv6-enabled network it sends 985 and receives IPv6 packets as described in [MIPv6]. IPv4 traffic is 986 encapsulated in IPv6 packets to the home agent. 988 When the mobile node is located in an IPv4 only network, it will send 989 IPv6 packets to its home agent according to the following format: 991 IPv4 header (src=V4CoA, dst=HA_V4ADDR) 992 [UDP header] 993 [TLV-header] 994 IPv6 header (src=V6HoA, dst=CN) 995 Upper layer protocols 997 Where the UDP header is only used if a NAT were detected between the 998 mobile node and the home agent, or if the home agent forced UDP 999 encapsulation. V4CoA is the IPv4 care-of address configured by the 1000 mobile node in the visited network. 1002 Similarly, IPv4 packets are sent according to the following format: 1004 IPv4 header (src=V4CoA, dst=HA_V4ADDR) 1005 [UDP header] 1006 [TLV-header] 1007 IPv4 header (src=V4HoA, dst=V4CN) 1008 Upper layer protocols 1010 Where the UDP header is only used if a NAT were detected between the 1011 mobile node and the home agent, or if the home agent forced UDP 1012 encapsulation. 1014 If the mobile node and the home agent negotiated the use of the TLV- 1015 header UDP encapsulation format, then the TLV-header would be used 1016 after the UDP header. 1018 4.4.2 Movement detection in IPv4-only networks 1020 [MIPv6] describes movement detection mostly based on IPv6-specific 1021 triggers. These triggers would not be available in an IPv4-only 1022 network. Hence, a mobile node located in an IPv4-only network SHOULD 1023 use [DNAv4] for guidance on movement detection mechanisms in IPv4- 1024 only networks. 1026 4.5. Home agent operations 1028 In addition to the home agent specification in [MIPv6] and [NEMO], 1029 the home agent needs to be able to process the IPv4 home address 1030 option and generate the IPv4 address acknowledgement option. Both 1031 options are included in the mobility header. Furthermore, the home 1032 agent MUST be able to detect the presence of a NAT device and 1033 indicate that in the NAT detection option included in the binding 1034 acknowledgement. 1036 A home agent must also act as a proxy for address resolution in IPv4 1037 for the registered IPv4 home addresses of mobile nodes it is serving. 1038 Moreover, the administrative domain of the home agent is responsible 1039 for advertising the routing information of registered IPv4 mobile 1040 network prefixes of the mobile nodes. 1042 In order to comply with this specification, the home agent MUST be 1043 able to find the IPv4 home address of a mobile node when given the 1044 IPv6 home address. That is, given an IPv6 home address, the home 1045 agent MUST store the corresponding IPv4 home address if a static one 1046 is present. If a dynamic address were requested by the mobile node, 1047 the home agent MUST store that address (associated with the IPv6 home 1048 address) after it's allocated to the mobile node. 1050 When the home agent receives a binding update encapsulated in UDP and 1051 containing the IPv4 home address option, it needs to follow all the 1052 steps in [MIPv6] and [NEMO]. In addition, the following checks MUST 1053 be done: 1055 - If the IPv4 care-of address in the IPv4 CoA option is not the same 1056 as the IPv4 address in the source address in the IPv4 header then 1057 a NAT was in the path. This information should be flagged for the 1058 binding acknowledgement. 1060 - If the F flag in the binding update were set, the home agent needs 1061 to determine whether it accepts forcing UDP encapsulation. If it 1062 does not, the binding acknowledgement is sent with error code 144. 1064 UDP encapsulation MUST NOT be used when the mobile node is located 1065 in an IPv6-enabled link. 1067 - If the T flag was set in the binding update, the home agent needs 1068 to determine whether it can accept the TLV-header encapsulation 1069 format. If it does, it should set the T flag in the binding 1070 acknowledgement. Otherwise, the home agent MUST NOT set the T flag 1071 in the binding acknowledgement. 1073 - If the IPv4 home address option contains a valid unicast IPv4 1074 address, the home agent MUST check that this address is allocated 1075 to the mobile node that has the IPv6 home address included in the 1076 home address option. The same MUST be done for an IPv4 prefix. 1078 - If the IPv4 home address option contained the unspecified IPv4 1079 address, the home agent SHOULD dynamically allocate an IPv4 home 1080 address to the mobile node. If none is available, the home agent 1081 MUST return error code 132 in the status field of the IPv4 address 1082 acknowledgement option. If a prefix were requested, the home agent 1083 MUST allocate a prefix with the requested length; otherwise the 1084 home agent MUST indicate failure of the operation with the 1085 appropriate error code. 1087 - If the binding update is accepted for the IPv4 home address, the 1088 home agent creates a binding cache entry for the IPv4 home 1089 address/prefix. The home agent MUST include an IPv4 acknowledgement 1090 option in the mobility header containing the binding 1091 acknowledgement. 1093 If the binding update is accepted for both IPv4 and IPv6 home 1094 addresses, the home agent creates separate binding cache entries, one 1095 for each home address. The care-of address is the one included in the 1096 binding update. If the care-of address is an IPv4 address, the home 1097 agent MUST setup a tunnel to the IPv4 care-of address of the mobile 1098 node. 1100 When sending a binding acknowledgement to the mobile node, the home 1101 agent constructs the message according to [MIPv6] and [NEMO]. Note 1102 that the routing header MUST always contain the IPv6 home address as 1103 specified in [MIPv6]. 1105 If the care-of address of the mobile node were an IPv4 address, the 1106 home agent includes the mobile node's IPv6 home address in the 1107 destination address field in the IPv6 header. If a NAT were detected, 1108 the home agent MUST then encapsulate the packet in UDP and an IPv4 1109 header. The source address is set to the home agent's IPv4 address 1110 and the destination address is set to the address received in the 1111 source address of the IPv4 header encapsulating the binding update. 1113 After creating a binding cache entry for the mobile node's home 1114 addresses, all packets sent to the mobile node's home addresses are 1115 tunneled by the home agent to the mobile node's care-of address. If a 1116 NAT were detected, packets are encapsulated in UDP and IPv4. 1117 Otherwise, if the care-of address is an IPv4 address, and no NAT were 1118 detected, packets are encapsulated in an IPv4 header unless UDP 1119 encapsulation is forced by the home agent. 1121 4.5.1 Sending packets to the mobile node 1123 The home agent follows the rules specified in [MIPv6] for sending 1124 IPv6 packets to mobile nodes located in IPv6 networks. When sending 1125 IPv4 packets to When mobile nodes in an IPv6 network, the home agent 1126 must encapsulate the IPv4 packets in IPv6. 1128 When sending IPv6 packets to a mobile node located in an IPv4 1129 network, the home agent must follow the format negotiated in the 1130 binding update/acknowledgement exchange. In the absence of a 1131 negotiated format, the default format that MUST be supported by all 1132 implementations is: 1134 IPv4 header (src= HA_V4ADDR, dst= V4ADDR) 1135 [UDP header] 1136 IPv6 header (src=CN, dst= V6HoA) 1137 Upper layer protocols 1139 Where the UDP header is only included if a NAT were detected between 1140 the mobile node and the home agent, or if the home agent forced UDP 1141 encapsulation. V4ADDR is the IPv4 address received in the source 1142 address field of the IPv4 packet containing the binding update. 1144 When sending IPv4 packets to a mobile node located in an IPv4 1145 network, the home agent must follow the format negotiated in the 1146 binding update/acknowledgement exchange. In the absence of a 1147 negotiated format, the default format that MUST be supported by all 1148 implementations is: 1150 IPv4 header (src= HA_V4ADDR, dst= V4ADDR) 1151 [UDP header] 1152 IPv4 header (src=V4CN, dst= V4HoA) 1153 Upper layer protocols 1155 Where the UDP header is only included if a NAT were detected between 1156 the mobile node and home agent, or if the home agent forced UDP 1157 encapsulation. 1159 4.6. Correspondent node operations 1161 This specification has no impact on IPv4 or IPv6 correspondent nodes. 1163 5. Security considerations 1165 This specification allows a mobile node to send one binding update 1166 for its IPv6 and IPv4 home addresses. This is a slight deviation from 1167 [MIPv6] which requires one binding update per home address. However, 1168 like [MIPv6], the IPsec security association needed to authenticate 1169 the binding update is still based on the mobile node's IPv6 home 1170 address. Therefore, in order to authorize the mobile node's IPv4 home 1171 address binding, the home agent MUST store the IPv4 address 1172 corresponding to the IPv6 address that is allocated to a mobile node. 1173 Therefore, it is sufficient for the home agent to know that the IPsec 1174 verification for the packet containing the binding update was valid 1175 provided that it knows which IPv4 home address is associated with 1176 which IPv6 home address. Hence, the security of the IPv4 home address 1177 binding is the same as the IPv6 binding. 1179 In effect, associating the mobile node's IPv4 home address with its 1180 IPv6 home address moves the authorization of the binding update for 1181 the IPv4 address to the Mobile IPv6 implementation, which infers it 1182 from the fact that mobile node has an IPv6 home address and the right 1183 credentials for sending an authentic binding update for the IPv6 1184 address. 1186 In cases where this specification is used for NAT traversal, it is 1187 important to note that it has the same vulnerabilities associated 1188 with RFC 3519 [TRAV]. An attacker is able to hijack the mobile node's 1189 session with the home agent if it can modify the contents of the 1190 outer IPv4 header. The contents of the header are not authenticated 1191 and there is no way for the home agent to verify their validity. 1192 Hence, a man in the middle attack where a change in the contents of 1193 the IPv4 header can cause a legitimate mobile node's traffic to be 1194 diverted to an illegitimate receiver independently of the 1195 authenticity of the binding update message. 1197 In this specification, the binding update message MUST be protected 1198 using ESP transport mode. When the mobile node is located in an IPv4- 1199 only network, the binding update message is encapsulated in UDP as 1200 described earlier. However, UDP MUST NOT be used to encapsulate the 1201 binding update message when the mobile node is located in an IPv6- 1202 enabled network. If protection of payload traffic is needed when the 1203 mobile node is located in an IPv4-only network, encapsulation is done 1204 using tunnel mode ESP over port 4500 as described in [TUNSEC]. When 1205 negotiating the security association with the home agent, while 1206 located in an IPv4-only network, if the mobile node and home agent 1207 support the use of port 4500, the mobile node MUST establish the 1208 security association over port 4500, regardless of the presence of a 1209 NAT. This is done to avoid the switching between ports 500 and 4500 1210 and the potential traffic disruption resulting from this switch. 1212 When located in an IPv4-only network, the mobile node MUST NOT 1213 negotiate a security association that uses the following tunnel 1214 formats: IPv4/IP(v4 or v6) and IPv4/ESP/IP(v4 or v6). These formats 1215 will not work in the presence of a NAT. There is no restriction on 1216 the tunnel format when the mobile node is located in an IPv6-enabled 1217 network. 1219 Handovers within private IPv4 networks or from IPv6 to IPv4 networks 1220 will have impacts on the security association between the mobile node 1221 and the home agent. The following section presents the expected 1222 behaviour of the mobile node and home agent in those situations. 1224 5.1 Handover interactions for IPsec and IKE 1226 After the mobile node detects movement it configures a new care-of 1227 address. If the mobile node is in an IPv4-only network, it removes 1228 binding update list entries for correspondent nodes since route 1229 optimisation cannot be supported. This may cause inbound packet 1230 losses as remote correspondent node are unaware of such movement. To 1231 avoid confusion in the correspondent node, the mobile node SHOULD 1232 deregister its binding with each correspondent node by sending a 1233 deregistration binding update. The deregistration binding update 1234 message is tunnelled to the home agent and onto the correspondent 1235 node. This is done after the mobile node updates the home agent with 1236 its new location as discussed below. 1238 The mobile node sends the binding update message to the home agent. 1239 If the mobile node is in an IPv6-enabled network, the binding update 1240 is sent without IPv4/UDP encapsulation. If the mobile node is in an 1241 IPv4-only network, then after IPsec processing of the BU message, it 1242 encapsulates the BU in UDP/IPv4 as discussed in sections 4.2 and 4.4. 1243 In order to be able to send the binding update while in an IPv4-only 1244 network, the mobile node needs to use the new IPv4 care-of address in 1245 the outer header, which is different from the care-of address used in 1246 the existing tunnel. This should be done without permanently updating 1247 the tunnel within the mobile node's implementation in order to allow 1248 the mobile node to receive packets on the old care-of address until 1249 the binding acknowledgement is received. The method used to achieve 1250 this effect is implementation dependent and is outside the scope of 1251 this specification. This implies that the IP forwarding function 1252 (which selects the interface or tunnel through which a packet is 1253 sent) is not based solely on the destination address: some IPv6 1254 packets destined to the home agent are sent via the existing tunnel, 1255 while BUs are sent using the new care-of address. Since BUs are 1256 protected by IPsec, the forwarding function cannot necessarily 1257 determine the correct treatment from the packet headers. Thus, the 1258 DSMIPv6 implementation has to attach additional information to BUs, 1259 and this information has to be preserved after IPsec processing and 1260 made available to the forwarding function, or additional DSMIP 1261 processing added to the forwarding function. Depending on the mobile 1262 node's implementation, meeting this requirement may require changes 1263 to the IPsec implementation. 1265 Upon receiving the binding update message encapsulated in UDP/IPv4, 1266 the home agent processes it as follows. In order to allow the DSMIPv6 1267 implementation in the home agent to detect the presence of a NAT on 1268 the path to the mobile node, it needs to compare the outer IPv4 1269 source address with the IPv4 address in the IPv4 care-of address 1270 option. This implies that the information in the outer header will be 1271 preserved after IPsec processing and made available to the DSMIPv6 1272 implementation in the home agent. Depending on the home agent's 1273 implementation, meeting this requirement may require changes to the 1274 IPsec implementation. 1276 The home agent updates its tunnel mode security association to 1277 include the mobile node's care-of address as the remote tunnel header 1278 address, and 4500 as the port number. If the mobile node were located 1279 in a private IPv4 network the address and port number are likely to 1280 be wrong as the NAT would likely allocate a different address and 1281 port number to traffic encapsulated in IPsec tunnels or to IKE 1282 messages; the mobile node provides the correct information in a 1283 separate exchange as described below. When the mobile node is located 1284 in a private IPv4 network (which is detected as described above), the 1285 new address and port number are allocated by the NAT. The home agent 1286 will also enable or disable UDP encapsulation for outgoing ESP 1287 packets for the purpose of NAT traversal. 1289 If the Key Management Mobility Capability (K) bit was set in the 1290 binding update, and the home agent supports this feature, the home 1291 agent updates its IKE security associations to include the mobile 1292 node's care-of address as the peer address and 4500 as the port 1293 number. The home agent may also need to change NAT traversal fields 1294 in the IKE_SA to enable the dyanmic update of the IP address and port 1295 number based on the reception of authenticated IKE messages, or 1296 authenticated packets using tunnel mode ESP. The dynamic updates are 1297 described in section 2.23 of RFC 4306. As described above, when the 1298 mobile node is located in a private IPv4 network, the address and 1299 port number used for IPsec and IKE traffic is not yet known by the 1300 home agent at this point. 1302 The mobile node updates the IKE SA in one of two ways. If the K flag 1303 was set in the binding acknowledgement message, the mobile node 1304 SHOULD send an empty informational message, which results in the IKE 1305 module in the home agent to dynamically update the SA information. 1306 The IKE implementation in the home agent is REQUIRED to support this 1307 feature. Alternatively, the IKE SA should be re-negotiated. Note that 1308 updating the IKE SA MUST take place after the mobile node has sent 1309 the binding update and received the acknowledgement from the home 1310 agent. 1312 It is important to note that if the mobile node is located behind a 1313 NAT, its IPv4 care-of address seen by the DSMIPv6 module in the home 1314 agent upon receiving the binding update will differ from the IPv4 1315 care-of address seen by the IKE module and the care-of address used 1316 for forwarding IPsec tunnel mode traffic. This is due to the fact 1317 that the NAT will probably allocate a different IP address and port 1318 number to each traffic stream. Hence, it is probable that different 1319 modules in the home agent will have a different care-of address that 1320 should be used for encapsulating traffic to the mobile node. 1322 After successfully processing the binding update, the home agent 1323 sends the binding acknowledgement to the mobile node's care-of 1324 address as received in the outer header of the packet containing the 1325 binding update. Note that if the BU was rejected, the BAck is sent to 1326 the same address where the BU was received from. This may require 1327 special treatment in IP forwarding and/or IPsec processing which 1328 resembles sending of BUs in the mobile node (described above). 1330 Upon receiving the binding acknowledgement the mobile node updates 1331 its local tunnel mode Security Association information to include the 1332 tunnel header IP source address, which is the the home agent's 1333 address and the tunnel header IP destination, which is the mobile 1334 node's care-of address. The mobile node may also need to enable or 1335 disable UDP encapsulation for outgoing ESP packets for the purpose 1336 of NAT traversal and the sending of keep alives. 1338 The mobile node MAY use [MOBIKE] to update its IKE SA with the home 1339 agent. Using MOBIKE requires negotiating this capability with the 1340 home agent when establishing the SA. In this case, the mobile node 1341 and the home agent MUST NOT update their IPsec SAs locally as this 1342 step is performed by MOBIKE. Furthermore, the use of MOBIKE allows 1343 the mobile node to update the SA independently of the binding update 1344 exchange. Hence, there is no need for the mobile node to wait for a 1345 binding acknowledgement before performing MOBIKE. The use of MOBIKE 1346 is OPTIONAL in this specification. 1348 6. Protocol constants 1350 NATKATIMEOUT 110 seconds 1352 7. Acknowledgements 1354 Thanks to the following members (in alphabetical order) of the MIP6 1355 and NEMO Working Groups for their contributions, discussion, and 1356 review: Jari Arkko, Sri Gundavelli, Wassim Haddad, Conny Larsson, 1357 Acee Lindem, Ahmad Muhanna, Vidya Narayanan, Karen Nielsen and 1358 Keiichi Shima. Thanks to Karen Nielsen, Pasi Eronen and Christian 1359 Kaas-Petersen for raising the issue of IKEv2 interactions and 1360 proposing the solution included in this document. 1362 8. IANA considerations 1364 The specification requires the following allocations from IANA: 1365 - A UDP port is needed for the NAT traversal mechanism described in 1366 section 4.1. 1367 - The IPv4 home address option described in section 3.1.1 requires an 1368 option type. This option is included in the Mobility header 1369 described in [MIPv6]. 1370 - The IPv4 address acknowledgement option described in section 3.2.1 1371 requires a new option type. This option is included in the Mobility 1372 header described in [MIPv6]. 1373 - The NAT detection option described in section 3.2.2 requires a new 1374 option type. This option is included in the Mobility header 1375 described in [MIPv6]. 1376 - The IPv4 Care-of address option described in section 3.1.2 requires 1377 an option type. This option is included in the Mobility header 1378 described in [MIPv6]. 1380 This specification introduces a new TLV-header to be used with UDP 1381 encapsulation. The Types of the TLV-header should be allocated by 1382 IANA under a new registry: "DSMIPv6 TLV-header Types". 1384 The Status field in the IPv4 home address option should be allocated 1385 by IANA under the new registry: "DSMIPv6 IPv4 home address option 1386 status codes". 1388 The TLV-header types and status field values are allocated using the 1389 following procedure: 1391 1. The IANA should allocate and permanently register new TLV-header 1392 types and Status field values from IETF RFC publication. This is for 1393 all RFC types including standards track, informational, and 1394 experimental status that originate from the IETF and have been 1395 approved by the IESG for 1396 publication. 1398 2. Requests for new option type value assignments from outside the 1399 IETF are only made through the publication of an IETF document, per 1400 1) above. Note also that documents published as "RFC Editor 1401 contributions" [RFC3667] are not considered to be IETF documents. 1403 9. References 1405 NORMATIVE 1407 [DNAv4] Aboba, B., Carlsson, J., and S. Cheshire, "Detecting Network 1408 Attachment for IPv4 (DNAv4)", RFC 4436, March 2006. 1410 [MIPv6] D. Johnson, Perkins, C. and J. Arkko, "Mobility Support in 1411 IPv6", RFC 3775, June 2004. 1413 [NEMO] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 1414 "Network Mobility (NEMO) Basic Support protocol", RFC 3963, 1415 January 2005. 1417 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 1418 Requirement Levels", BCP 14, RFC 2119, March 1997. 1420 [TUNSEC] Huttunen, A., Swander, B., Volpe, V., DiBurro, L. and M. 1421 Stenberg, "UDP Encapsulation for IPsec ESP Packets", RFC 1422 3948, January 2005. 1424 INFORMATIVE 1426 [BOOT] Giaretta, G. (Ed.), Kempf J., and V. Devarapalli, " Mobile 1427 IPv6 bootstrapping in split scenario", RFC 5026, October 2007. 1429 [HMIPv6] Soliman, H., Castelluccia, C., ElMalki, K., and L. Bellier, 1430 "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", 1431 Draftietf-mipshop-4140bis-04 November 2007. 1433 [INTBOOT] K. Chowdhury and A. Yegin, "MIP6-bootstrapping for the 1434 Integrated Scenario", draft-ietf-mip6-bootstrapping- 1435 integrated-dhc-02, Work in Progress. 1437 [MIP-PB] Tsirtsis, G., and H. Soliman, "Mobility management for 1438 Dual stack mobile nodes, A Problem Statement", 1439 RFC 4977, August 2007. 1441 [MIPv4] C. Perkins, "Mobility Support for IPv4", RFC3344 1443 [MOBIKE] P. Eronen,"IKEv2 Mobility and Multihoming Protocol (MOBIKE)" 1444 , RFC 4555, June 2006. 1446 [SNRIO] Larsson, T., Gustafsson, E., and H. Levkowetz, "Use of MIPv6 1447 in IPv4 and MIPv4 in IPv6 networks", draft-larsson-v6ops- 1448 mip-scenarios-01.txt, February 2004. 1450 [TRAV] H. Levkowetz and S. Vaarala, "Mobile IP Traversal for Network 1451 Address Translation (NAT) Devices", RFC 3519, April 2003. 1453 10. Contributors 1455 This document reflects discussions and contributions from several 1456 people including (in alphabetical order): 1458 Vijay Devarapalli 1459 E-mail: vijay.devarapalli@azairenet.com 1461 James Kempf 1462 E-mail: kempf@docomolabs-usa.com 1464 Henrik Levkowetz 1465 E-mail: henrik@levkowetz.com 1467 Pascal Thubert 1468 E-mail: pthubert@cisco.com 1470 George Tsirtsis 1471 E-mail1: G.Tsirtsis@Qualcomm.com 1472 E-mail2: tsirtsisg@yahoo.com 1474 Wakikawa Ryuji 1475 ryuji@sfc.wide.ad.jp 1477 Author's Address 1479 Hesham Soliman 1480 Elevate Technologies 1481 E-mail: Hesham@elevatemobile.com 1483 Intellectual Property Statement 1485 The IETF takes no position regarding the validity or scope of any 1486 Intellectual Property Rights or other rights that might be claimed to 1487 pertain to the implementation or use of the technology described in 1488 this document or the extent to which any license under such rights 1489 might or might not be available; nor does it represent that it has 1490 made any independent effort to identify any such rights. Information 1491 on the procedures with respect to rights in RFC documents can be 1492 found in BCP 78 and BCP 79. 1494 Copies of IPR disclosures made to the IETF Secretariat and any 1495 assurances of licenses to be made available, or the result of an 1496 attempt made to obtain a general license or permission for the use of 1497 such proprietary rights by implementers or users of this 1498 specification can be obtained from the IETF on-line IPR repository at 1499 http://www.ietf.org/ipr. 1501 The IETF invites any interested party to bring to its attention any 1502 copyrights, patents or patent applications, or other proprietary 1503 rights that may cover technology that may be required to implement 1504 this standard. Please address the information to the IETF at 1505 ietf-ipr@ietf.org. 1507 Full Copyright Statement 1509 Copyright (C) The IETF Trust (2008). This document is subject to the 1510 rights, licenses and restrictions contained in BCP 78, and except as 1511 set forth therein, the authors retain all their rights. 1513 Disclaimer of Validity 1515 This document and the information contained herein are provided on an 1516 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1517 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1518 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1519 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1520 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1521 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1523 This Internet-Draft expires August, 2008.