idnits 2.17.1 draft-ietf-mip6-nemo-v4traversal-04.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1108. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1086. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1092. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 685, but not defined == Missing Reference: 'IPv4 ACK' is mentioned on line 699, but not defined == Missing Reference: 'DNAv4' is mentioned on line 838, but not defined == Unused Reference: 'IPv6' is defined on line 1014, but no explicit reference was found in the text == Unused Reference: 'KEYWORDS' is defined on line 1017, but no explicit reference was found in the text == Unused Reference: 'MIPv4' is defined on line 1024, but no explicit reference was found in the text == Unused Reference: 'SEC' is defined on line 1033, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4140 (ref. 'HMIPv6') (Obsoleted by RFC 5380) ** Obsolete normative reference: RFC 2460 (ref. 'IPv6') (Obsoleted by RFC 8200) == Outdated reference: A later version (-03) exists of draft-ietf-mip6-dsmip-problem-01 ** Downref: Normative reference to an Informational draft: draft-ietf-mip6-dsmip-problem (ref. 'MIP-PB') ** Obsolete normative reference: RFC 3344 (ref. 'MIPv4') (Obsoleted by RFC 5944) ** Obsolete normative reference: RFC 3775 (ref. 'MIPv6') (Obsoleted by RFC 6275) -- Possible downref: Normative reference to a draft: ref. 'SNRIO' Summary: 10 errors (**), 0 flaws (~~), 11 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIP6 Working Group Hesham Soliman (Ed.) 3 INTERNET-DRAFT Elevate Technologies 4 Expires: September 2007 5 March, 2007 7 Mobile IPv6 support for dual stack 8 Hosts and Routers (DSMIPv6) 9 draft-ietf-mip6-nemo-v4traversal-04.txt 11 Status of this memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-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 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/lid-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 This document is a submission of the IETF MIP6 WG. Comments should be 34 directed to the IPv6 WG mailing list, mip6@ietf.org. 36 Abstract 38 The current Mobile IPv6 and NEMO specification support only IPv6. 39 Hence, this specification extends those standards to allow the 40 registration of IPv4 addresses and prefixes, respectively, and the 41 transport of both IPv4 and IPv6 packets over the tunnel to the HA. 42 This specification allows also the Mobile Node to roam over both IPv6 43 and IPv4, including the case where Network Address Translation is 44 present on the path. 46 Table of Contents 48 1. Introduction.....................................................2 49 1.1 Motivation for using Mobile IPv6 only...........................3 50 1.2 Scenarios considered by this specification...................4 51 2. Solution overview................................................5 52 2.1. Home Agent Address Discovery...................................5 53 2.2. Mobile Prefix Solicitations and Advertisements..............6 54 2.3. Binding management.............................................6 55 2.3.1 Foreign network supports IPv6.................................7 56 2.3.2 Foreign network supports IPv4 only............................7 57 2.3.2.1 Visited network supports IPv4 only (private addresses)......8 58 2.4. Route optimization.............................................9 59 2.5. Dynamic IPv4 home address allocation..........................10 60 3. Extensions and modifications to Mobile IPv6.....................10 61 3.1. Binding update extensions.....................................10 62 3.1.1 IPv4 home address option.....................................10 63 3.2. Binding acknowledgement extensions............................11 64 3.2.1 IPv4 address acknowledgement option..........................11 65 3.2.2 The NAT detection option...............................12 66 4. Protocol operation..............................................13 67 4.1. NAT detection and traversal................................13 68 4.2. NAT Keepalives.............................................15 69 4.3. Mobile node operation.........................................15 70 4.3.1 Sending packets from a visited network.................17 71 4.3.2 Movement detection in IPv4-only networks...............17 72 4.4. Home agent operations.........................................17 73 4.4.1 Sending packets to the mobile node.....................19 74 4.5. Correspondent node operations.................................20 75 5. Security considerations.........................................20 76 6. Protocol constants..............................................20 77 7. Acknowledgements................................................20 78 8. IANA considerations.............................................20 79 9. References......................................................21 80 Authors' Addresses.................................................21 82 1. Introduction 84 Mobile IPv6 [MIPv6] and [NEMO] allow mobile nodes to move within the 85 Internet while maintaining reachability and ongoing sessions, using 86 an IPv6 home address or prefix. However, since IPv6 is not widely 87 deployed, it is unlikely that mobile nodes will use IPv6 addresses 88 only for their connections. It is reasonable to assume that mobile 89 nodes will, for a long time, need an IPv4 home address that can be 90 used by upper layers. It is also reasonable to assume that mobile 91 nodes will move to networks that might not support IPv6 and would 92 therefore need the capability to support an IPv4 Care-of Address. 93 Hence, this specification extends Mobile IPv6 capabilities to allow 94 dual stack mobile nodes to request that their home agent (also dual 95 stacked) tunnel IPv4/IPv6 packets addressed to their home addresses, 96 to their IPv4/IPv6 care-of address(es). 98 Using this specification, mobile nodes would only need Mobile IPv6 99 and [NEMO] to manage mobility while moving within the Internet; hence 100 eliminating the need to run two mobility management protocols 101 simultaneously. This specification provides the extensions needed in 102 order to allow Mobile IPv6 only to be used by dual sack mobile nodes. 104 This specification will also consider cases where a mobile node moves 105 into a private IPv4 network and gets configured with a private IPv4 106 Care-of Address. In those scenarios, the mobile node needs to be able 107 to traverse the IPv4 NAT in order to communicate with the Home Agent. 108 IPv4 NAT traversal for Mobile IPv6 is presented in this 109 specification. 111 In this specification, the term mobile node refers to both a mobile 112 host and mobile router unless the discussion is specific to either 113 hosts or routers. Similarly, we use the term home address to reflect 114 an address/prefix format. 116 In this specification, extensions are defined for the binding update 117 and binding acknowledgement. It should be noted that all these 118 extensions apply to cases where the mobile node communicates with a 119 Mobility Anchor Point (MAP) as defined in [HMIPv6]. The requirements 120 on the MAP are identical to those stated for the home agent, although 121 it is unlikely that NAT traversal would be needed with a MAP as it is 122 expected to be in the same address domain. 124 1.1 Motivation for using Mobile IPv6 only 126 IPv6 offers a number of improvements over today's IPv4, primarily due 127 to its large address space. Mobile IPv6 offers a number of 128 improvements over Mobile IPv4, mainly due to capabilities inherited 129 from IPv6. For instance, route optimization and Dynamic home agent 130 discovery can only be achieved with Mobile IPv6. 132 One of the advantages of the large address space provided by IPv6 is 133 that it allows mobile nodes to obtain a globally unique care-of 134 address wherever they are. Hence, there is no need for Network 135 Address Translator (NAT) traversal techniques designed for Mobile 136 IPv4. This allows Mobile IPv6 to be a significantly simpler and more 137 bandwidth efficient mobility management protocol. At the same time, 138 during the transition towards IPv6, NAT traversal for existing 139 private IPv4 networks needs to be considered. This specification 140 introduces NAT traversal for this purpose. 142 The above benefits make the case for using Mobile IPv6 only for dual 143 stack mobile nodes in order to allow for a long lasting mobility 144 solution and minimize the need to changing the mobility stack due to 145 the introduction of IPv6 within a deployed network. 147 1.2 Scenarios considered by this specification 149 In [SNRIO] several scenarios that illustrate potential 150 incompatibilities for mobile nodes using Mobile IPv6 were discussed. 151 Some of the problems associated with mobility and transition issues 152 were presented in [MIP-PB]. This specification considers a subset of 153 the scenarios in [SNRIO], which address all the problems discussed in 154 [MIP-PB]. The scenarios considered in this specification are listed 155 below. 157 All of the following scenarios assume that both the mobile node and 158 the Home Agent are IPv4 and IPv6-enabled and that only Mobile IPv6 is 159 used between the mobile node and the Home Agent. We also assume that 160 the Home Agent is always reachable through a globally unique IPv4 161 address. Finally, it's important to note that the following scenarios 162 are not mutually exclusive. 164 Scenario 1: IPv4-only foreign network 166 In this scenario, a mobile node is connected to an IPv4-only foreign 167 network. The mobile node can only configure an IPv4 Care-of Address. 169 Scenario 2: Mobile node behind a NAT: 171 In this scenario, the mobile node is in a private IPv4 foreign 172 network that has a NAT device connecting it to the Internet. If the 173 Home Agent is located outside the NAT device, the mobile node will 174 need a NAT traversal mechanism to communicate with the Home Agent. 176 Scenario 3: Home Agent behind a NAT: 178 In this scenario, the communication between the mobile node and the 179 Home Agent is further complicated by the fact that the Home Agent is 180 located within a private IPv4 network. However, in this scenario, we 181 assume that the Home Agent is allocated a globally unique IPv4 182 address. Such address might not be physically configured on the Home 183 Agent interface. Instead, it is associated with the Home Agent on the 184 NAT device, which allows the Home Agent to be reachable through 185 address or port mapping. 187 Scenario 4: Use Of IPv4-only applications 189 In this scenario, the mobile node may be located in an IPv4, IPv6 or 190 a dual network. However, the mobile node might be communicating with 191 an IPv4-only node. In this case, the mobile node would need a stable 192 IPv4 address for its application. The alternative to using an IPv4 193 address is the use of protocol translators; however, end-to-end 194 communication with IPv4 is preferred to the use of protocol 195 translators. 197 The mobile node may also be communicating with an IPv4-only 198 application that requires an IPv4 address. 200 The cases above illustrate the need for a stable IPv4 home address to 201 be allocated to the mobile node. This is done using an IPv4 home 202 address. Since running Mobile IPv4 and Mobile IPv6 simultaneously is 203 problematic (as illustrated in [MIP-PB]), this scenario adds a 204 requirement on Mobile IPv6 to support IPv4 home addresses. 206 2. Solution overview 208 In order to allow Mobile IPv6 to be used by dual stack mobile nodes, 209 the following needs to be done: 211 - Mobile nodes should be able to use an IPv4 and IPv6 home or care-of 212 address simultaneously and update their home agents accordingly. 214 - Mobile nodes need to be able to know the IPv4 address of the home 215 agent as well as its IPv6 address. There is no need for IPv4 prefix 216 discovery however. 218 - Mobile nodes need to be able to detect the presence of a NAT device 219 and traverse such device in order to communicate with the Home Agent 220 in a secure manner. 222 This section presents an overview of the extensions required in order 223 to allow mobile nodes to use Mobile IPv6 only for IP mobility 224 management. 226 2.1. Home Agent Address Discovery 228 Dynamic Home Agent Address Discovery (DHAAD) was defined in [MIPv6] 229 to allow mobile nodes to discover their home agents by appending a 230 well-known anycast interface identifier to their home link's prefix. 231 However, this mechanism is based on IPv6-anycast routing. If a mobile 232 node is located in an IPv4-only foreign network, it cannot rely on 233 native IPv6 routing. The preferred solution for discovering the home 234 agent's IPv4 address is through the Domain Name System (DNS). 236 For DNS lookup by name, the mobile node should be configured with the 237 name of the home agent. When the mobile node needs to discover a 238 home agent, it sends a DNS request with QNAME set to the configured 239 name. An example is "ha1.example.com". If a home agent has an IPv4 240 and IPv6 address, the corresponding DNS record should be configured 241 with both 'AAAA' and 'A' records. Accordingly the DNS reply will 242 contain 'AAAA' and 'A' records. 244 For DNS lookup by service, the SRV record defined in [BOOT] is 245 reused. For instance, if the service name is "_mip6ha" and the 246 protocol name is "_ipv6" for the SRV record, the mobile node SHOULD 247 send a DNS request with the QNAME set to "mip6ha.ipv6.example.com". 249 The response should contain the home agent's FQDN(s) and may have the 250 corresponding 'AAAA' and 'A' records enclosed as well. 252 If multiple home agents reside on the home link, each configured with 253 a public IPv4 addresses, then the operation above applies. In case 254 the home agents are behind a NAT box, there are two options, 1) 255 configure a public IPv4 address for each home agent on the NAT box, 256 2) configure one public address and make the home agents share the 257 public address. In either case, the correct DNS entries can be 258 configured. Another possible solution is to designate one home agent 259 on the home link for v4 traversal. The NAT device should associate 260 that home agent with the public IPv4 address configured on it for v4 261 traversal. In all cases above, both the 'AAAA' and 'A' records 262 returned for a particular name MUST correspond to the same physical 263 home agent; otherwise the mobile node will not be able to bind its 264 addresses correctly. 266 2.2. Mobile Prefix Solicitations and Advertisements 268 According to [MIPv6], the mobile node can send a Mobile Prefix 269 Solicitation and receive a Mobile Prefix Advertisement containing all 270 prefixes advertised on the home link. 272 A dual stack mobile node MAY send a Mobile Prefix Solicitation 273 message encapsulated in IPv4 (i.e. IPv6 in IPv4) in the case where 274 the mobile node has no access to IPv6 within the local network. 275 Securing such messages would require the mobile node to have security 276 association with the home agent, using IPsec (AH or ESP) and based on 277 the mobile node's IPv4 care-of address as described in [MIPv6]. Since 278 the mobile node needs to encapsulate all IPv6 traffic sent to the 279 home agent into IPv4 while located in an IPv4-only visited network, 280 such SA would affect all packets if the selectors were based on the 281 information in the outer header. That is, the SA selectors being the 282 protocol number (protocol is always IP in IP), as well as, source and 283 destination addresses are all common to all packets. If this effect 284 is not desired, the mobile node can base the SA on the information in 285 the inner header (i.e. using the home agent's IPv6 address, the 286 mobile node's home address and the ICMP protocol number). Such 287 security association would use transport mode ESP protection. 289 2.3. Binding management 291 A dual stack mobile node will need to update its home agent with its 292 care-of address. If a mobile node has an IPv4 and an IPv6 home 293 address it will need to create a binding cache entry for each 294 address. The format of the IP packet carrying the binding update and 295 acknowledgement messages will vary depending on whether the mobile 296 node has access to IPv6 in the visited network. There are three 297 different scenarios to consider with respect to the visited network: 299 A. The visited network has IPv6 connectivity and provides the mobile 300 node with a care-of address (in a stateful or stateless manner). 302 B. The mobile node can only configure a globally unique IPv4 address 303 in the visited network. 304 C. The mobile node can only configure a private IPv4 address in the 305 visited network. 307 2.3.1 Foreign network supports IPv6 309 In this case, the mobile node is able to configure a globally unique 310 IPv6 address. The mobile node will send a binding update to the IPv6 311 address of its home agent, as defined in [MIPv6]. The binding update 312 MAY include the IPv4 home address option introduced in this document. 313 After receiving the binding update, the home agent creates two 314 binding cache entries, one for the mobile node's IPv4 home address, 315 and another for the mobile node's IPv6 home address. Both entries 316 will point to the mobile node's IPv6 care-of address. Hence, whenever 317 a packet is addressed to the mobile node's IPv4 or IPv6 home 318 addresses, it will be tunneled in IPv6 to the mobile node's IPv6 319 care-of address included in the binding update. Effectively, the 320 mobile node establishes two different tunnels, one for its IPv4 321 traffic (IPv4 in IPv6) and one for its IPv6 traffic (IPv6 in IPv6) 322 with a single binding update. The security implications of this 323 mechanism are discussed in the security considerations section. 325 In this scenario, the only addition to [MIPv6] is the inclusion of 326 the IPv4 home address option in the binding update message. 328 After accepting the binding update and creating the corresponding 329 binding cache entries, the home agent MUST send a binding 330 acknowledgement to the mobile node as defined in [MIPv6]. In 331 addition, if the binding update included an IPv4 home address option, 332 the binding acknowledgement MUST include the IPv4 address 333 acknowledgment option as described later in this specification. This 334 option informs the mobile node whether the binding was accepted for 335 the IPv4 home address. If this option is not included in the binding 336 acknowledgement and the IPv4 home address option was included in the 337 binding update, the mobile node MUST assume that the home agent does 338 not support the IPv4 home address option and therefore SHOULD NOT 339 include the option in future binding updates to that home agent 340 address. 342 The routing header in the binding update MUST include the mobile 343 node's IPv6 home address as specified in [MIPv6]. 345 When a mobile node acquires both IPv4 and IPv6 care-of addresses at 346 foreign network, it SHOULD prioritize IPv6 care-of address for MIP6 347 binding registration. The mobile node MUST NOT register both IPv4 and 348 IPv6 care-of addresses to its home agent. 350 2.3.2 Foreign network supports IPv4 only 351 If the mobile node is in a foreign network that only supports IPv4, 352 it needs to detect whether a NAT is in its communication path to the 353 home agent. This is done while exchanging the binding update and 354 acknowledgement messages as shown later in this document. If no NAT 355 is detected between the mobile node and the home agent, the mobile 356 node assumes that it is in a foreign network that supports IPv4 357 public addresses. Otherwise, the mobile node assumes that private 358 addresses are used in the foreign network. Note that this assumption 359 is only valid for the purposes of the signaling presented in this 360 specification. A mobile node SHOULD NOT assume that its IPv4 address 361 is globally unique if a NAT device was not detected. The operations 362 of both cases are discussed below. 364 2.3.2.2 Foreign network supports IPv4 only (public addresses) 366 In this scenario the mobile node will need to tunnel IPv6 packets 367 containing the binding update to the home agent's IPv4 address. The 368 mobile node uses the IPv4 address it gets from the foreign network as 369 a source address in the outer header. The binding update will contain 370 the mobile node's IPv6 home address in the home address option. 371 However, since the care-of address in this scenario is the mobile 372 node's IPv4 address, the mobile node MUST include its IPv4 care-of 373 address in the IPv6 packet. The IPv4 address is represented in an 374 IPv4-mapped IPv6 address and is included in the source address field 375 of the IPv6 header. 377 If the mobile node had an IPv4 home address, it MUST also include the 378 IPv4 home address option described in this specification. 380 After accepting the binding update, the home agent MUST create a new 381 binding cache entry for the mobile node's IPv6 home address. If an 382 IPv4 home address option were included, the home agent MUST create 383 another entry for that address. All entries MUST point to the mobile 384 node's IPv4 care-of address. Hence, all packets addressed to the 385 mobile node's home address(es) (IPv4 or IPv6) will be encapsulated in 386 an IPv4 header that includes the home agent's IPv4 address in the 387 source address field and the mobile node's IPv4 care-of address in 388 the destination address field. 390 After accepting the binding updates and creating the corresponding 391 entries, the home agent MUST send a binding acknowledgement as 392 specified in [MIPv6]. In addition, if the binding update included an 393 IPv4 home address option, the binding acknowledgement MUST include 394 the IPv4 address acknowledgment option as described later in this 395 specification. The binding update is encapsulated to the IPv4 care-of 396 address (represented as an IPv4-mapped IPv6 address in the binding 397 update). 399 2.3.2.1 Visited network supports IPv4 only (private addresses) 400 In this scenario the mobile node will need to tunnel IPv6 packets 401 containing the binding update to the home agent's IPv4 address. In 402 order to traverse the NAT device, IPv6 packets are tunneled UDP and 403 IPv4. The UDP port used to send the IPv6 packet is TBD. 405 The mobile node uses the IPv4 address it gets from the visited 406 network as a source address in the IPv4 header. The binding update 407 will contain the mobile node's IPv6 home address in the home address 408 option. The content of the IPv6 packet is identical to the public 409 address scenario described above. 411 After accepting the binding update, the home agent MUST create a new 412 binding cache entry for the mobile node's IPv6 home address. If an 413 IPv4 home address option were included, the home agent MUST create 414 another entry for that address. All entries MUST point to the mobile 415 node's IPv4 care-of address included in the source address of the 416 IPv6 packet and represented as an IPv4-mapped IPv6 address. In 417 addition, the tunnel used MUST indicate UDP encapsulation for NAT 418 traversal. Hence, all packets addressed to the mobile node's home 419 address(es) (IPv4 or IPv6) will be encapsulated in UDP then 420 encapsulated in an IPv4 header that includes the home agent's IPv4 421 address in the source address field and the mobile node's IPv4 care- 422 of address in the destination address field. 424 After accepting the binding updates and creating the corresponding 425 entries, the home agent MUST send a binding acknowledgement as 426 specified in [MIPv6]. In addition, if the binding update included an 427 IPv4 home address option, the binding acknowledgement MUST include 428 the IPv4 address acknowledgment option as described later in this 429 specification. The binding acknowledgement is encapsulated in UDP 430 then IPv4 with the home agent's IPv4 address in the source address 431 field and the mobile node's IPv4 care-of address in the destination 432 field. The inner IPv6 packet will contain the home agent's IPv6 433 address as a source address and the mobile node's IPv4 care-of 434 address in the destination address field. The latter is represented 435 as an IPv4-mapped IPv6 address. 437 The mobile node needs to maintain the NAT bindings for its current 438 IPv4 care-of address. This is done through sending the binding update 439 regularly to the home agent. 441 2.4. Route optimization 443 Route optimization, as specified in [MIPv6] will operate in an 444 identical manner for dual stack mobile nodes when they are located in 445 a visited network that provides IPv6 addresses to the mobile node. 446 However, when located in an IPv4-only network, route optimization 447 will not be possible due to the difficulty of performing the care-of 448 address test. Therefore, mobile nodes will need to communicate 449 through the home agent. 451 Route optimization will not be possible for IPv4 traffic. That is, 452 traffic addressed to the mobile node's IPv4 home address. This is 453 similar to using Mobile IPv4, therefore there is no reduction of 454 features resulting from using this specification. 456 2.5. Dynamic IPv4 home address allocation 458 It is possible to allow for the mobile node's IPv4 home address to be 459 allocated dynamically. This is done by including 0.0.0.0 in the IPv4 460 home address option included in the binding update. The home agent 461 SHOULD allocate an IPv4 address to the mobile node and include it in 462 the IPv4 address acknowledgement option sent to the mobile node. In 463 this case, the lifetime of the binding is bound to the minimum of the 464 lifetimes of the IPv6 binding and the lease time of the IPv4 home 465 address. 467 3. Extensions and modifications to Mobile IPv6 469 This section highlights the protocol and implementation additions 470 required to support this specification. 472 3.1. Binding update extensions 474 3.1.1 IPv4 home address option 476 This option is included in the Mobility Header including the binding 477 update message sent from the mobile node to a home agent or Mobility 478 Anchor Point. The alignment requirement for this option is 4n. 480 0 1 2 3 481 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 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Type | Length |Pref |P| Reserved | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | IPv4 home address | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 Type TBD 490 Length 6 492 Pref The length of the prefix allocated to the mobile 493 node. If only a single address is allocated, 494 this field MUST be set to 32. In the first 496 binding update requesting a prefix, the field 497 contains the prefix length requested. However, 498 in the following binding updates, this field 499 must contain the length of the prefix allocated. 501 P A flag indicating, when set, that the mobile 502 node requests a mobile network prefix. This flag 503 is only relevant for new requests, and must be 504 ignored for binding refreshes. 506 Reserved This field is reserved for future use. It MUST 507 be set to zero by the sender and ignored by the 508 receiver. 510 IPv4 home address The mobile node's IPv4 home address that should 511 be defended by the home agent. This field could 512 contain any unicast IPv4 address (public or 513 private) that was assigned to the mobile node. 514 The value 0.0.0.0 is used to request an IPv4 515 home address from the home agent. A mobile node 516 may choose to use this option to request a 517 prefix by setting the address to the All Zeroes 518 and setting the P flag. The mobile node could 519 then form an IPv4 home address based on the 520 allocated prefix. Alternatively, the mobile node 521 may use two different options, one for 522 requesting an address (Static or Dynamic) and 523 another for requesting a prefix. 525 3.2. Binding acknowledgement extensions 527 3.2.1 IPv4 address acknowledgement option 529 This option is included in the Mobility Header including the binding 530 acknowledgement message sent from the home agent or Mobility Anchor 531 Point to the mobile node. This option indicates whether a binding 532 cache entry was created for the mobile node's IPv4 address. 533 Additionally, this option can include an IPv4 home address in the 534 case of Dynamic IPv4 home address configuration (i.e. if the 535 unspecified IPv4 address was included in the binding update). The 536 alignment requirement for this option is 4n. 538 0 1 2 3 539 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 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | Type | Length | Status | Pref | Res | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | IPv4 home address | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 Type TBD 548 Length 6 550 Status Indicates success or failure for the IPv4 home 551 address binding. Values from 0 to 127 indicate 552 success. Higher values indicate failure. The 553 following values are reserved: 554 0 Success 555 128 Failure, reason unspecified 556 129 Administratively prohibited 557 130 Incorrect IPv4 home address 558 131 Invalid IPv4 address 559 132 Dynamic IPv4 home address 560 assignment not available 561 133 Prefix allocation unauthorized 563 Pref The prefix length of the address allocated. This 564 field is only valid in case of success and MUST 565 be set to zero and ignored in case of failure. 566 This field overrides what the mobile node 567 requested (if not equal to the requested 568 length). 570 Res This field is reserved for future use. It MUST 571 be set to zero by the sender and ignored by the 572 receiver. 574 IPv4 home address The IPv4 home address that the home agent will 575 use in the binding cache entry. This could be a 576 public or private address. This field MUST 577 contain the mobile node's IPv4 home address. 578 If the address were dynamically allocated the 579 home agent will add the address to inform the 580 mobile node. Otherwise, if the address were 581 statically allocated to the mobile node, the 582 home agent will copy it from the binding update 583 message. 585 3.2.2 The NAT detection option 587 This option is sent from the home agent to the mobile node to 588 indicate whether a NAT was in the path. This option MAY also include 589 a suggested NAT binding refresh time for the mobile node. The 590 alignment requirement for this option is 4n. 592 0 1 2 3 593 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 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | Type | Length |F| Reserved | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | Refresh time | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 Type TBD 601 Length 6 603 F This flag indicates to the mobile node that UDP 604 encapsulation is required. When set, this flag 605 indicates that the mobile node MUST use UDP 606 encapsulation even if a NAT is not located 607 between the mobile node and home agent. 609 Reserved This field is reserved for future use. It MUST 610 be set to zero by the sender and ignored by the 611 receiver. 613 Refresh time A suggested time (in seconds) for the mobile 614 node to refresh the NAT binding. If set to zero, 615 it is ignored. If this field is set to the all 616 1s it means that keepalives are not needed, i.e. 617 no NAT was detected. 619 4. Protocol operation 621 This section presents the protocol operation and processing for the 622 messages presented above. In addition, this section introduces the 623 NAT detection and traversal mechanism used by this specification. 625 4.1. NAT detection and traversal 627 NAT detection is done when the initial binding update message is sent 628 from the mobile node to the home agent. When located in an IPv4-only 629 foreign link, the mobile node sends the binding update message 630 encapsulated in UDP and IPv4. The source address of the IPv6 packet 631 is the mobile node's IPv4 care-of address represented in IPv4-mapped 632 IPv6 format. The destination address is the IPv6 address of the home 633 agent. The IPv4 header contains the IPv4 care-of address in the 634 source address field and the IPv4 address of the home agent in the 635 destination address field. 637 When the home agent receives the encapsulated binding update it 638 compares the IPv4 address of the source address field in the IPv4 639 header with the IPv4 address in the source address of the IPv6 640 header. If the two addresses match, no NAT device was in the path. 641 Otherwise, a NAT device was in the path and the NAT detection option 642 is included in the binding acknowledgement. The binding 643 acknowledgement, and all future packets, are then encapsulated in UDP 644 and IPv4. The source address in the IPv4 header is the IPv4 address 645 of the home agent. The destination address is the IPv4 address 646 received in the IPv4 header encapsulating the binding update (this 647 address will be different from the IPv4 care-of address when a NAT is 648 in the path). 650 Upon receiving the binding acknowledgement with the NAT detection 651 option, the mobile node sets the tunnel to the home agent to UDP 652 encapsulation. Hence, all future packets to the home agent are 653 tunneled in UDP and IPv4. For all tunneled IPv6 packets, the source 654 address in the IPv6 header is the mobile node's IPv6 home address and 655 the destination address is the correspondent node's IPv6 address. All 656 tunneled IPv4 packets will contain the mobile node's IPv4 home 657 address in the source address field of the inner IPv4 packet and the 658 correspondent node's IPv4 address in the destination address field. 659 The outer IPv4 header is the same whether the inner packet is IPv4 or 660 IPv6. 662 If no NAT device was detected in the path between the mobile node and 663 the home agent then IPv6 packets are tunneled in an IPv4 header, 664 unless the home agent forces UDP encapsulation using the F flag. The 665 content of the inner and outer headers are identical to the UDP 666 encapsulation case. 668 A mobile node MUST always tunnel binding updates in UDP when located 669 in an IPv4-only network. Essentially, this process allows for 670 perpetual NAT detection. Similarly, the home agent MUST encapsulate 671 binding acknowledgements in a UDP header whenever the binding update 672 is encapsulated in UDP. 674 In conclusion, the packet formats for the binding update and 675 acknowledgement messages are shown below: 677 A. Binding update received by the home agent: 679 IPv4 header (src=V4ADDR, dst=HA_V4ADDR) 680 UDP header 681 IPv6 header (src=V4CoA, dst=HAADDR) 682 DST-OPT 683 HAO (IPv6 home address) 684 Mobility header 685 BU [IPv4 HAO] 687 Where V4ADDR is either the IPv4 care-of address or the address 688 provided by the NAT device. V4COA is the IPv4 care-of address of the 689 mobile node. HAO is the home address option and BU is the binding 690 update, which MAY contain the IPv4 home address option. 692 B. Binding acknowledgement sent by the home agent: 693 IPv4 header (src=V4ADDR, dst=HA_V4ADDR) 694 UDP header 695 IPv6 header (src=V4CoA, dst=HAADDR) 696 Route HDR Type 2 697 HOA (IPv6 home address) 698 Mobility header 699 BA ([IPv4 ACK], NAT DET) 701 Where HOA is IPv6 home address of the mobile node. The IPv4 ACK is 702 the IPv4 address acknowledgement option, which is only included if 703 the IPv4 home address option were present in the BU. The NAT DET is 704 the NAT detection option, which MUST be present in the binding 705 acknowledgement message if the binding update was encapsulated in 706 UDP. 708 4.2. NAT Keepalives 710 If a NAT is detected, the mobile node will need to refresh the NAT 711 bindings in order to be reachable from the home agent. NAT bindings 712 can be refreshed through sending and receiving traffic encapsulated 713 in UDP. However, if the mobile node is not active, it will need to 714 periodically send a message to the home agent in order to refresh the 715 NAT binding. This can be done using the binding update message. The 716 binding update/acknowledgement pair will ensure that the NAT bindings 717 are refreshed in a reliable manner. 718 There is no way for the mobile node to know the exact time of the NAT 719 binding. The default time suggested in this specification is 720 NATKATIMEOUT. If the home agent suggests a different refresh period 721 in the binding acknowledgement, the mobile node SHOULD use the value 722 suggested by the home agent. 724 If the refresh time in the NAT detection option in the binding 725 acknowledgement is set to the all 1s, the mobile node need not send 726 messages to refresh the NAT binding. However, the mobile node may 727 still be required to encapsulate traffic in UDP. This scenario may 728 take place when a NAT is not detected, but the home agent still 729 requires the mobile node to use UDP encapsulation. 731 It should be noted that a mobile node that does not need to be 732 reachable (i.e. only cares about the session continuity aspect of 733 Mobile IP) does not need to refresh NAT binding. In this case, the 734 mobile node would only be able to initiate communication with other 735 nodes. 737 4.3. Mobile node operation 739 In addition to the operations specified in [MIPv6] and [NEMO], this 740 specification requires mobile nodes to be able to support an IPv4 741 home address. The IPv4 home address is never sent in the IPv4-mapped 742 IPv6 address format. This is primarily done to save bandwidth. 743 However, to simplify the mobile node's implementation, they may store 744 the IPv4 home address in the binding update list, using the IPv4- 745 mapped IPv6 format. 747 When sending an IPv6 packet containing a binding update while 748 connected to an IPv4-only access network, mobile nodes MUST ensure 749 the following: 751 - The IPv6 packet is encapsulated in UDP and an IPv4 packet. 753 - The source address in the IPv4 header is the mobile node's IPv4 754 care-of address 755 - The destination address in the IPv4 header is the home agent's 756 IPv4 address. 757 - The source address in the IPv6 header is the mobile node's IPv4- 758 mapped IPv6 address. That is, the same IPv4 address in the outer 759 header is placed in the IPv6 header using the mapped address 760 format. 761 - The home address option contains the IPv6 home address as 762 specified in [MIPv6]. 763 - The IPv4 home address option MAY be included in the mobility 764 header. This option contains the IPv4 home address. If the mobile 765 node did not have a static home address it MAY include the 766 unspecified IPv4 address, which acts as a request for a dynamic 767 IPv4 home address. Alternatively, one or more IPv4 home address 768 options may be included with requests for IPv4 prefixes (i.e. with 769 the P flag set.). 770 - The IPv6 packet MUST be authenticated as per [MIPv6], based on the 771 mobile node's IPv6 home address. 773 When sending a binding update from a visited network that supports 774 IPv6, the mobile node MUST follow the rules specified in [MIPv6]. In 775 addition, if the mobile node has an IPv4 home address or needs one, 776 it should include the IPv4 home address option in the mobility 777 header. If the mobile node already has a static IPv4 home address, 778 such address MUST be included in the IPv4 home address option. 779 Otherwise, if the mobile node needs a dynamic IPv4 address, it should 780 include the IPv4 unspecified address in the IPv4 home address option. 782 When the mobile node receives a binding acknowledgement from the home 783 agent, it should follow the rules in [MIPv6] and [NEMO]. In addition, 784 the following actions MUST be made: 786 - If the mobility header includes an IPv4 address acknowledgement 787 option indicating success, the mobile node should create two 788 entries in its binding update list, one for the IPv6 home address 789 and another for the IPv4 home address. 790 - If the NAT detection option were present, the mobile node 791 MUST tunnel future packets in UDP and IPv4. This MUST be indicated 792 in the binding update list. 793 - If no IPv4 address acknowledgement option were present, and an 794 IPv4 home address option was present in the binding update, the 795 mobile node MUST only create one binding update list entry for its 796 IPv6 home address. The mobile node MAY include the IPv4 home 797 address option in future binding updates. 798 - If an IPv4 address acknowledgement option were present and it 799 indicates failure for the IPv4 home address binding, the mobile 800 node MUST NOT create an entry for that address in its binding 801 update list. The mobile node MAY include the IPv4 home address 802 option in future binding updates. 804 4.3.1 Sending packets from a visited network. 806 When the mobile node is located in an IPv6-enabled network it sends 807 and receives IPv6 packets as described in [MIPv6]. IPv4 traffic is 808 encapsulated in IPv6 packets to the home agent. 810 When the mobile node is located in an IPv4 only network, it will send 811 IPv6 packets to its home agent according to the following format: 813 IPv4 header (src=V4ADDR, dst=HA_V4ADDR) 814 [UDP header] 815 IPv6 header (src=V6HoA, dst=CN) 816 Upper layer protocols 818 Where the UDP header is only used if a NAT were detected between the 819 mobile node and the home agent, or if the home agent forced UDP 820 encapsulation. 822 Similarly, IPv4 packets are sent according to the following format: 824 IPv4 header (src=V4ADDR, dst=HA_V4ADDR) 825 [UDP header] 826 IPv4 header (src=V4HoA, dst=V4CN) 827 Upper layer protocols 829 Where the UDP header is only used if a NAT were detected between the 830 mobile node and the home agent, or if the home agent forced UDP 831 encapsulation. 833 4.3.2 Movement detection in IPv4-only networks 835 [MIPv6] describes movement detection mostly based on IPv6-specific 836 triggers. Such triggers would not be available in an IPv4-only 837 network. Hence, a mobile node located in an IPv4-only network SHOULD 838 use [DNAv4] for guidance on movement detection mechanisms in IPv4- 839 only networks. 841 4.4. Home agent operations 843 In addition to the home agent specification in [MIPv6] and [NEMO], 844 the home agent needs to be able to process the IPv4 home address 845 option and generate the IPv4 address acknowledgement option. Both 846 options are included in the mobility header. Furthermore, the home 847 agent MUST be able to detect the presence of a NAT device and 848 indicate that in the NAT detection option included in the binding 849 acknowledgement. 851 A home agent must also act as a proxy for address resolution in IPv4 852 for the registered IPv4 home addresses of mobile nodes it is serving. 853 Moreover, the administrative domain of the home agent is responsible 854 for advertising the routing information of registered IPv4 mobile 855 network prefixes of the mobile nodes. 857 In order to comply with this specification, the home agent MUST be 858 able to find the IPv4 home address of a mobile node when given the 859 IPv6 home address. That is, given an IPv6 home address, the home 860 agent MUST store the corresponding IPv4 home address if a static one 861 is present. If a dynamic address were requested by the mobile node, 862 the home agent MUST store that address (associated with the IPv6 home 863 address) after it's allocated to the mobile node. 865 When the home agent receives a binding update encapsulated in UDP and 866 containing the IPv4 home address option, it needs to follow all the 867 steps in [MIPv6] and [NEMO]. In addition, the following checks MUST 868 be done: 870 - If the IPv4 care-of address in the IPv6 header is not the same as 871 the IPv4 address in the source address in the IPv4 header then a 872 NAT was in the path. This information should be flagged for the 873 binding acknowledgement. 875 - If the IPv4 home address option contains a valid unicast IPv4 876 address, the home agent MUST check that this address is allocated 877 to the mobile node that has the IPv6 home address included in the 878 home address option. The same MUST be done for an IPv4 prefix. 880 - If the IPv4 home address option contained the unspecified IPv4 881 address, the home agent SHOULD dynamically allocate an IPv4 home 882 address to the mobile node. If none is available, the home agent 883 MUST return an appropriate error code in the status field of the 884 IPv4 address acknowledgement option. If a prefix were requested, 885 the home agent MUST allocate a prefix with the requested length; 886 otherwise the home agent MUST indicate failure of the operation 887 with the appropriate error code. 889 - If the binding update is accepted for the IPv4 home address, the 890 home agent creates a binding cache entry for the IPv4 home 891 address/prefix. If a single IPv4 home address were requested, it 892 MAY be stored in the IPv4-mapped IPv6 address format. The home 893 agent MUST include an IPv4 acknowledgement option in the mobility 894 header containing the binding acknowledgement. 896 If the binding update is accepted for both IPv4 and IPv6 home 897 addresses, the home agent creates separate binding cache entries, one 898 for each home address. The care-of address is the one included in the 899 binding update. If the care-of address is an IPv4-mapped IPv6 900 address, the home agent MUST setup a tunnel to the IPv4 care-of 901 address of the mobile node. 903 When sending a binding acknowledgement to the mobile node, the home 904 agent would construct the message according to [MIPv6] and [NEMO]. 905 Note that the routing header MUST always contain the IPv6 home 906 address as specified in [MIPv6]. 908 If the care-of address of the mobile node were an IPv4 address, the 909 home agent MUST include this address in the destination address in 910 the IPv6 header using the IPv4-mapped IPv6 format. If a NAT were 911 detected, the home agent MUST then encapsulate the packet in UDP and 912 an IPv4 header. The source address is set to the home agent's IPv4 913 address and the destination address is set to the address received in 914 the source address of the IPv4 header encapsulating the binding 915 update. 917 After creating a binding cache entry for the mobile node's home 918 addresses, all packets sent to the mobile node's home addresses are 919 tunneled by the home agent to the mobile node's care-of address. If a 920 NAT were detected, packets are encapsulated in UDP and IPv4. 921 Otherwise, if the care-of address is an IPv4 address, and no NAT were 922 detected, packets are encapsulated in an IPv4 header. 924 4.4.1 Sending packets to the mobile node 926 The home agent follows the rules specified in [MIPv6] for sending 927 IPv6 packets to mobile nodes located in IPv6 networks. When sending 928 IPv4 packets to When mobile nodes in an IPv6 network, the home agent 929 must encapsulate the IPv4 packets in IPv6. 931 When sending IPv6 packets to a mobile node located in an IPv4 932 network, the home agent must follow the following format: 934 IPv4 header (src= HA_V4ADDR, dst= V4CoA) 935 [UDP header] 936 IPv6 header (src=CN, dst= V6HoA) 937 Upper layer protocols 939 Where the UDP header is only included if a NAT were detected between 940 the mobile node and the home agent, or if the home agent forced UDP 941 encapsulation. 943 When sending IPv4 packets to a mobile node located in an IPv4 944 network, the home agent must follow the following format: 946 IPv4 header (src= HA_V4ADDR, dst= V4CoA) 947 [UDP header] 948 IPv4 header (src=V4CN, dst= V4HoA) 949 Upper layer protocols 951 Where the UDP header is only included if a NAT were detected between 952 the mobile node and home agent, or if the home agent forced UDP 953 encapsulation. 955 4.5. Correspondent node operations 957 This specification has no impact on IPv4 or IPv6 correspondent nodes. 959 5. Security considerations 961 This specification allows a mobile node to send one binding update 962 for its IPv6 and IPv4 home addresses. This is a slight deviation from 963 [MIPv6] which requires one binding update per home address. However, 964 like [MIPv6], the IPsec security association needed to authenticate 965 the binding update is still based on the mobile node's IPv6 home 966 address. Therefore, in order to authorize the mobile node's IPv4 home 967 address binding, the home agent MUST store the IPv4 address 968 corresponding to the IPv6 address that is allocated to a mobile node. 969 Therefore, it is sufficient for the home agent to know that the IPsec 970 verification for the packet containing the binding update was valid 971 provided that it knows which IPv4 home address is associated with 972 which IPv6 home address. Hence, the security of the IPv4 home address 973 binding is the same as the IPv6 binding. 975 In effect, associating the mobile node's IPv4 home address with its 976 IPv6 home address moves the authorization of the binding update for 977 the IPv4 address to the Mobile IPv6 implementation, which infers it 978 from the fact that mobile node has an IPv6 home address and the right 979 credentials for sending an authentic binding update for such address. 981 6. Protocol constants 983 NATKATIMEOUT 110 seconds 985 7. Acknowledgements 987 Thanks to Keiichi Shima for his comments on the draft. 989 8. IANA considerations 991 The specification requires the following allocations from IANA: 992 - A UDP port is needed for the NAT traversal mechanism described in 993 section 4.1. 994 - The IPv4 home address option described in section 3.1.1 requires an 995 option type. This option is included in the Mobility header 996 described in [MIPv6]. 997 - The IPv4 address acknowledgement option described in section 3.2.1 998 requires a new option type. This option is included in the Mobility 999 header described in [MIPv6]. 1000 - The NAT detection option described in section 3.2.2 requires a new 1001 option type. This option is included in the Mobility header 1002 described in [MIPv6]. 1004 9. References 1006 [BOOT] Giaretta, G. (Ed.), Kempf J., and V. Devarapalli, " Mobile 1007 IPv6 bootstrapping in split scenario", draft-ietf-mip6- 1008 bootstrapping-split, June 2005, work in progress. 1010 [HMIPv6] Soliman, H., Castelluccia, C., ElMalki, K., and L. Bellier, 1011 "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", 1012 RFC 4140, August 2005. 1014 [IPv6] S. Deering and B. Hinden, "Internet Protocol version 6 (IPv6) 1015 specification", RFC 2460 1017 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 1018 Requirement Levels", BCP 14, RFC 2119, March 1997. 1020 [MIP-PB] Tsirtsis, G., and H. Soliman, "Mobility management for 1021 Dual stack mobile nodes, A Problem Statement", 1022 draft-ietf-mip6-dsmip-problem-01.txt, July 2005. 1024 [MIPv4] C. Perkins, "Mobility Support for IPv4", RFC3344 1026 [MIPv6] D. Johnson, C. Perkins and J. Arkko, "Mobility Support in 1027 IPv6", RFC 3775, June 2004. 1029 [NEMO] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 1030 "Network Mobility (NEMO) Basic Support protocol", RFC 3963, 1031 January 2005. 1033 [SEC] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 1034 Protoect Mobile IPv6 Signaling between Mobile Nodes and Home 1035 Agents", RFC 3776, June 2004. 1037 [SNRIO] Larsson, T., Gustafsson, E., and H. Levkowetz, "Use of MIPv6 1038 in IPv4 and MIPv4 in IPv6 networks", draft-larsson-v6ops- 1039 mip-scenarios-01.txt, February 2004. 1041 10. Contributors 1043 This document reflects discussions and contributions from several 1044 people (in alphabetical order): 1046 Vijay Devarapalli 1047 E-mail: vijay.devarapalli@azairenet.com 1049 James Kempf 1050 E-mail: kempf@docomolabs-usa.com 1051 Henrik Levkowetz 1052 E-mail: henrik@levkowetz.com 1054 Pascal Thubert 1055 E-mail: pthubert@cisco.com 1057 George Tsirtsis 1058 E-mail1: G.Tsirtsis@Qualcomm.com 1059 E-mail2: tsirtsisg@yahoo.com 1061 Wakikawa Ryuji 1062 ryuji@sfc.wide.ad.jp 1064 Author's Address 1066 Hesham Soliman 1067 Elevate Technologies 1068 E-mail: Hesham@elevatemobile.com 1070 Intellectual Property Statement 1072 The IETF takes no position regarding the validity or scope of any 1073 Intellectual Property Rights or other rights that might be claimed to 1074 pertain to the implementation or use of the technology described in 1075 this document or the extent to which any license under such rights 1076 might or might not be available; nor does it represent that it has 1077 made any independent effort to identify any such rights. Information 1078 on the IETF's procedures with respect to rights in IETF Documents can 1079 be found in RFC 3667 (BCP 78) and RFC 3668 (BCP 79). 1081 Copies of IPR disclosures made to the IETF Secretariat and any 1082 assurances of licenses to be made available, or the result of an 1083 attempt made to obtain a general license or permission for the use of 1084 such proprietary rights by implementers or users of this 1085 specification can be obtained from the IETF on-line IPR repository at 1086 http://www.ietf.org/ipr. 1088 The IETF invites any interested party to bring to its attention any 1089 copyrights, patents or patent applications, or other proprietary 1090 rights that may cover technology that may be required to implement 1091 this standard. Please address the information to the IETF at ietf- 1092 ipr@ietf.org. 1094 Full Copyright Statement 1096 Copyright (C) The IETF Trust (2007). This document is subject to the 1097 rights, licenses and restrictions contained in BCP 78, and except as 1098 set forth therein, the authors retain all their rights. 1100 Disclaimer of Validity 1102 This document and the information contained herein are provided on an 1103 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1104 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1105 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1106 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1107 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1108 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1110 This Internet-Draft expires September, 2007.