idnits 2.17.1 draft-ietf-mip6-nemo-v4traversal-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 28. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1149. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1127. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1133. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines 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 RFC 3978 Section 5.4 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 699, but not defined == Missing Reference: 'IPv4 ACK' is mentioned on line 713, but not defined == Missing Reference: 'DNAv4' is mentioned on line 852, but not defined == Unused Reference: 'IPv6' is defined on line 1029, but no explicit reference was found in the text == Unused Reference: 'KEYWORDS' is defined on line 1032, but no explicit reference was found in the text == Unused Reference: 'MIPv4' is defined on line 1039, but no explicit reference was found in the text == Unused Reference: 'SEC' is defined on line 1048, 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: 12 errors (**), 0 flaws (~~), 12 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 George Tsirtsis 4 Expires: December 2006 Qualcomm 5 Vijay Deverapalli 6 Azaire Networks 7 James Kempf 8 Docomo Labs 9 Henrik Levkowetz 11 Ericsson 12 Pascal Thubert 13 Cisco 14 Ryuji Wakikawa 16 Keio University 17 June, 2006 19 Mobile IPv6 support for dual stack 20 Hosts and Routers (DSMIPv6) 21 draft-ietf-mip6-nemo-v4traversal-02.txt 23 Status of this memo 25 By submitting this Internet-Draft, each author represents that any 26 applicable patent or other IPR claims of which he or she is aware 27 have been or will be disclosed, and any of which he or she becomes 28 aware will be disclosed, in accordance with Section 6 of BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that other 32 groups may also distribute working documents as Internet-Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or cite them other than as "work in progress". 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/lid-abstracts.txt 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 45 This document is a submission of the IETF MIP6 WG. Comments should be 46 directed to the MIP6 WG mailing list, mip6@ietf.org. 48 Abstract 50 The current Mobile IPv6 and NEMO specification support only IPv6. 52 Hence, this specification extends those standards to allow the 53 registration of IPv4 addresses and prefixes, respectively, and the 54 transport of both IPv4 and IPv6 packets over the tunnel to the HA. 55 This specification allows also the Mobile Node to roam over both IPv6 56 and IPv4, including the case where Network Address Translation is 57 present on the path. 59 Table of Contents 61 1. Introduction.....................................................2 62 1.1 Motivation for using Mobile IPv6 only...........................3 63 1.2 Scenarios considered by this specification...................4 64 2. Solution overview................................................5 65 2.1. Home Agent Address Discovery...................................5 66 2.2. Mobile Prefix Solicitations and Advertisements..............6 67 2.3. Binding management.............................................6 68 2.3.1 Foreign network supports IPv6.................................7 69 2.3.2 Foreign network supports IPv4 only............................8 70 2.3.2.1 Visited network supports IPv4 only (private addresses)......9 71 2.4. Route optimization.............................................9 72 2.5. Dynamic IPv4 home address allocation..........................10 73 3. Extensions and modifications to Mobile IPv6.....................10 74 3.1. Binding update extensions.....................................10 75 3.1.1 IPv4 home address option.....................................10 76 3.2. Binding acknowledgement extensions............................11 77 3.2.1 IPv4 address acknowledgement option..........................11 78 3.2.2 The NAT detection option...............................12 79 4. Protocol operation..............................................13 80 4.1. NAT detection and traversal................................13 81 4.2. NAT Keepalives.............................................15 82 4.3. Mobile node operation.........................................15 83 4.3.1 Sending packets from a visited network.................17 84 4.3.2 Movement detection in IPv4-only networks...............17 85 4.4. Home agent operations.........................................17 86 4.4.1 Sending packets to the mobile node.....................19 87 4.5. Correspondent node operations.................................20 88 5. Security considerations.........................................20 89 6. Protocol constants..............................................20 90 7. Acknowledgements................................................20 91 8. IANA considerations.............................................20 92 9. References......................................................21 93 Authors' Addresses.................................................21 95 1. Introduction 97 Mobile IPv6 [MIPv6] and [NEMO] allow mobile nodes to move within the 98 Internet while maintaining reachability and ongoing sessions, using 99 an IPv6 home address or prefix. However, since IPv6 is not widely 100 deployed, it is unlikely that mobile nodes will use IPv6 addresses 101 only for their connections. It is reasonable to assume that mobile 102 nodes will, for a long time, need an IPv4 home address that can be 103 used by upper layers. It is also reasonable to assume that mobile 104 nodes will move to networks that might not support IPv6 and would 105 therefore need the capability to support an IPv4 Care-of Address. 106 Hence, this specification extends Mobile IPv6 capabilities to allow 107 dual stack mobile nodes to request that their home agent (also dual 108 stacked) tunnel IPv4/IPv6 packets addressed to their home addresses, 109 to their IPv4/IPv6 care-of address(es). 111 Using this specification, mobile nodes would only need Mobile IPv6 112 and [NEMO] to manage mobility while moving within the Internet; hence 113 eliminating the need to run two mobility management protocols 114 simultaneously. This specification provides the extensions needed in 115 order to allow Mobile IPv6 only to be used by dual sack mobile nodes. 117 This specification will also consider cases where a mobile node moves 118 into a private IPv4 network and gets configured with a private IPv4 119 Care-of Address. In those scenarios, the mobile node needs to be able 120 to traverse the IPv4 NAT in order to communicate with the Home Agent. 121 IPv4 NAT traversal for Mobile IPv6 is presented in this 122 specification. 124 In this specification, the term mobile node refers to both a mobile 125 host and mobile router unless the discussion is specific to either 126 hosts or routers. Similarly, we use the term home address to reflect 127 an address/prefix format. 129 In this specification, extensions are defined for the binding update 130 and binding acknowledgement. It should be noted that all these 131 extensions apply to cases where the mobile node communicates with a 132 Mobility Anchor Point (MAP) as defined in [HMIPv6]. The requirements 133 on the MAP are identical to those stated for the home agent, although 134 it is unlikely that NAT traversal would be needed with a MAP as it is 135 expected to be in the same address domain. 137 1.1 Motivation for using Mobile IPv6 only 139 IPv6 offers a number of improvements over today's IPv4, primarily due 140 to its large address space. Mobile IPv6 offers a number of 141 improvements over Mobile IPv4, mainly due to capabilities inherited 142 from IPv6. For instance, route optimization and Dynamic home agent 143 discovery can only be achieved with Mobile IPv6. 145 One of the advantages of the large address space provided by IPv6 is 146 that it allows mobile nodes to obtain a globally unique care-of 147 address wherever they are. Hence, there is no need for Network 148 Address Translator (NAT) traversal techniques designed for Mobile 149 IPv4. This allows Mobile IPv6 to be a significantly simpler and more 150 bandwidth efficient mobility management protocol. At the same time, 151 during the transition towards IPv6, NAT traversal for existing 152 private IPv4 networks needs to be considered. This specification 153 introduces NAT traversal for this purpose. 155 The above benefits make the case for using Mobile IPv6 only for dual 156 stack mobile nodes in order to allow for a long lasting mobility 157 solution and minimize the need to changing the mobility stack due to 158 the introduction of IPv6 within a deployed network. 160 1.2 Scenarios considered by this specification 162 In [SNRIO] several scenarios that illustrate potential 163 incompatibilities for mobile nodes using Mobile IPv6 were discussed. 164 Some of the problems associated with mobility and transition issues 165 were presented in [MIP-PB]. This specification considers a subset of 166 the scenarios in [SNRIO], which address all the problems discussed in 167 [MIP-PB]. The scenarios considered in this specification are listed 168 below. 170 All of the following scenarios assume that both the mobile node and 171 the Home Agent are IPv4 and IPv6-enabled and that only Mobile IPv6 is 172 used between the mobile node and the Home Agent. We also assume that 173 the Home Agent is always reachable through a globally unique IPv4 174 address. Finally, it's important to note that the following scenarios 175 are not mutually exclusive. 177 Scenario 1: IPv4-only foreign network 179 In this scenario, a mobile node is connected to an IPv4-only foreign 180 network. The mobile node can only configure an IPv4 Care-of Address. 182 Scenario 2: Mobile node behind a NAT: 184 In this scenario, the mobile node is in a private IPv4 foreign 185 network that has a NAT device connecting it to the Internet. If the 186 Home Agent is located outside the NAT device, the mobile node will 187 need a NAT traversal mechanism to communicate with the Home Agent. 189 Scenario 3: Home Agent behind a NAT: 191 In this scenario, the communication between the mobile node and the 192 Home Agent is further complicated by the fact that the Home Agent is 193 located within a private IPv4 network. However, in this scenario, we 194 assume that the Home Agent is allocated a globally unique IPv4 195 address. Such address might not be physically configured on the Home 196 Agent interface. Instead, it is associated with the Home Agent on the 197 NAT device, which allows the Home Agent to be reachable through 198 address or port mapping. 200 Scenario 4: Use Of IPv4-only applications 202 In this scenario, the mobile node may be located in an IPv4, IPv6 or 203 a dual network. However, the mobile node might be communicating with 204 an IPv4-only node. In this case, the mobile node would need a stable 205 IPv4 address for its application. The alternative to using an IPv4 206 address is the use of protocol translators; however, end-to-end 207 communication with IPv4 is preferred to the use of protocol 208 translators. 210 The mobile node may also be communicating with an IPv4-only 211 application that requires an IPv4 address. 213 The cases above illustrate the need for a stable IPv4 home address to 214 be allocated to the mobile node. This is done using an IPv4 home 215 address. Since running Mobile IPv4 and Mobile IPv6 simultaneously is 216 problematic (as illustrated in [MIP-PB]), this scenario adds a 217 requirement on Mobile IPv6 to support IPv4 home addresses. 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 such device in order to communicate with the Home Agent 233 in a secure manner. 235 This section presents an overview of the extensions required in order 236 to allow mobile nodes to use Mobile IPv6 only for IP mobility 237 management. 239 2.1. Home Agent Address Discovery 241 Dynamic Home Agent Address Discovery (DHAAD) was defined in [MIPv6] 242 to allow mobile nodes to discover their home agents by appending a 243 well-known anycast interface identifier to their home link's prefix. 244 However, this mechanism is based on IPv6-anycast routing. If a mobile 245 node is located in an IPv4-only foreign network, it cannot rely on 246 native IPv6 routing. The preferred solution for discovering the home 247 agent's IPv4 address is through the Domain Name System (DNS). 249 For DNS lookup by name, the mobile node should be configured with the 250 name of the home agent. When the mobile node needs to discover a 251 home agent, it sends a DNS request with QNAME set to the configured 252 name. An example is "ha1.example.com". If a home agent has an IPv4 253 and IPv6 address, the corresponding DNS record should be configured 254 with both 'AAAA' and 'A' records. Accordingly the DNS reply will 255 contain 'AAAA' and 'A' records. 257 For DNS lookup by service, the SRV record defined in [BOOT] is 258 reused. For instance, if the service name is "_mip6ha" and the 259 protocol name is "_ipv6" for the SRV record, the mobile node SHOULD 260 send a DNS request with the QNAME set to "mip6ha.ipv6.example.com". 261 The response should contain the home agent's FQDN(s) and may have the 262 corresponding 'AAAA' and 'A' records enclosed as well. 264 If multiple home agents reside on the home link, each configured with 265 a public IPv4 addresses, then the operation above applies. In case 266 the home agents are behind a NAT box, there are two options, 1) 267 configure a public IPv4 address for each home agent on the NAT box, 268 2) configure one public address and make the home agents share the 269 public address. In either case, the correct DNS entries can be 270 configured. Another possible solution is to designate one home agent 271 on the home link for v4 traversal. The NAT device should associate 272 that home agent with the public IPv4 address configured on it for v4 273 traversal. In all cases above, both the 'AAAA' and 'A' records 274 returned for a particular name MUST correspond to the same physical 275 home agent; otherwise the mobile node will not be able to bind its 276 addresses correctly. 278 2.2. Mobile Prefix Solicitations and Advertisements 280 According to [MIPv6], the mobile node can send a Mobile Prefix 281 Solicitation and receive a Mobile Prefix Advertisement containing all 282 prefixes advertised on the home link. 284 A dual stack mobile node MAY send a Mobile Prefix Solicitation 285 message encapsulated in IPv4 (i.e. IPv6 in IPv4) in the case where 286 the mobile node has no access to IPv6 within the local network. 287 Securing such messages would require the mobile node to have security 288 association with the home agent, using IPsec (AH or ESP) and based on 289 the mobile node's IPv4 care-of address as described in [MIPv6]. Since 290 the mobile node needs to encapsulate all IPv6 traffic sent to the 291 home agent into IPv4 while located in an IPv4-only visited network, 292 such SA would affect all packets if the selectors were based on the 293 information in the outer header. That is, the SA selectors being the 294 protocol number (protocol is always IP in IP), as well as, source and 295 destination addresses are all common to all packets. If this effect 296 is not desired, the mobile node can base the SA on the information in 297 the inner header (i.e. using the home agent's IPv6 address, the 298 mobile node's home address and the ICMP protocol number). Such 299 security association would use transport mode ESP protection. 301 2.3. Binding management 303 A dual stack mobile node will need to update its home agent with its 304 care-of address. If a mobile node has an IPv4 and an IPv6 home 305 address it will need to create a binding cache entry for each 306 address. The format of the IP packet carrying the binding update and 307 acknowledgement messages will vary depending on whether the mobile 308 node has access to IPv6 in the visited network. There are three 309 different scenarios to consider with respect to the visited network: 311 A. The visited network has IPv6 connectivity and provides the mobile 312 node with a care-of address (in a stateful or stateless manner). 314 B. The mobile node can only configure a globally unique IPv4 address 315 in the visited network. 316 C. The mobile node can only configure a private IPv4 address in the 317 visited network. 319 2.3.1 Foreign network supports IPv6 321 In this case, the mobile node is able to configure a globally unique 322 IPv6 address. The mobile node will send a binding update to the IPv6 323 address of its home agent, as defined in [MIPv6]. The binding update 324 MAY include the IPv4 home address option introduced in this document. 325 After receiving the binding update, the home agent creates two 326 binding cache entries, one for the mobile node's IPv4 home address, 327 and another for the mobile node's IPv6 home address. Both entries 328 will point to the mobile node's IPv6 care-of address. Hence, whenever 329 a packet is addressed to the mobile node's IPv4 or IPv6 home 330 addresses, it will be tunneled in IPv6 to the mobile node's IPv6 331 care-of address included in the binding update. Effectively, the 332 mobile node establishes two different tunnels, one for its IPv4 333 traffic (IPv4 in IPv6) and one for its IPv6 traffic (IPv6 in IPv6) 334 with a single binding update. The security implications of this 335 mechanism are discussed in the security considerations section. 337 In this scenario, the only addition to [MIPv6] is the inclusion of 338 the IPv4 home address option in the binding update message. 340 After accepting the binding update and creating the corresponding 341 binding cache entries, the home agent MUST send a binding 342 acknowledgement to the mobile node as defined in [MIPv6]. In 343 addition, if the binding update included an IPv4 home address option, 344 the binding acknowledgement MUST include the IPv4 address 345 acknowledgment option as described later in this specification. This 346 option informs the mobile node whether the binding was accepted for 347 the IPv4 home address. If this option is not included in the binding 348 acknowledgement and the IPv4 home address option was included in the 349 binding update, the mobile node MUST assume that the home agent does 350 not support the IPv4 home address option and therefore SHOULD NOT 351 include the option in future binding updates to that home agent 352 address. 354 The routing header in the binding update MUST include the mobile 355 node's IPv6 home address as specified in [MIPv6]. 357 When a mobile node acquires both IPv4 and IPv6 care-of addresses at 358 foreign network, it SHOULD prioritize IPv6 care-of address for MIP6 359 binding registration. The mobile node MUST NOT register both IPv4 and 360 IPv6 care-of addresses to its home agent. 362 2.3.2 Foreign network supports IPv4 only 364 If the mobile node is in a foreign network that only supports IPv4, 365 it needs to detect whether a NAT is in its communication path to the 366 home agent. This is done while exchanging the binding update and 367 acknowledgement messages as shown later in this document. If no NAT 368 is detected between the mobile node and the home agent, the mobile 369 node assumes that it is in a foreign network that supports IPv4 370 public addresses. Otherwise, the mobile node assumes that private 371 addresses are used in the foreign network. Note that this assumption 372 is only valid for the purposes of the signaling presented in this 373 specification. A mobile node SHOULD NOT assume that its IPv4 address 374 is globally unique if a NAT device was not detected. The operations 375 of both cases are discussed below. 377 2.3.2.2 Foreign network supports IPv4 only (public addresses) 379 In this scenario the mobile node will need to tunnel IPv6 packets 380 containing the binding update to the home agent's IPv4 address. The 381 mobile node uses the IPv4 address it gets from the foreign network as 382 a source address in the outer header. The binding update will contain 383 the mobile node's IPv6 home address in the home address option. 384 However, since the care-of address in this scenario is the mobile 385 node's IPv4 address, the mobile node MUST include its IPv4 care-of 386 address in the IPv6 packet. The IPv4 address is represented in an 387 IPv4-mapped IPv6 address and is included in the source address field 388 of the IPv6 header. 390 If the mobile node had an IPv4 home address, it MUST also include the 391 IPv4 home address option described in this specification. 393 After accepting the binding update, the home agent MUST create a new 394 binding cache entry for the mobile node's IPv6 home address. If an 395 IPv4 home address option were included, the home agent MUST create 396 another entry for that address. All entries MUST point to the mobile 397 node's IPv4 care-of address. Hence, all packets addressed to the 398 mobile node's home address(es) (IPv4 or IPv6) will be encapsulated in 399 an IPv4 header that includes the home agent's IPv4 address in the 400 source address field and the mobile node's IPv4 care-of address in 401 the destination address field. 403 After accepting the binding updates and creating the corresponding 404 entries, the home agent MUST send a binding acknowledgement as 405 specified in [MIPv6]. In addition, if the binding update included an 406 IPv4 home address option, the binding acknowledgement MUST include 407 the IPv4 address acknowledgment option as described later in this 408 specification. The binding update is encapsulated to the IPv4 care-of 409 address (represented as an IPv4-mapped IPv6 address in the binding 410 update). 412 2.3.2.1 Visited network supports IPv4 only (private addresses) 414 In this scenario the mobile node will need to tunnel IPv6 packets 415 containing the binding update to the home agent's IPv4 address. In 416 order to traverse the NAT device, IPv6 packets are tunneled UDP and 417 IPv4. The UDP port used to send the IPv6 packet is TBD. 419 The mobile node uses the IPv4 address it gets from the visited 420 network as a source address in the IPv4 header. The binding update 421 will contain the mobile node's IPv6 home address in the home address 422 option. The content of the IPv6 packet is identical to the public 423 address scenario described above. 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 IPv6 packet and represented as an IPv4-mapped IPv6 address. 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 inner IPv6 packet will contain the home agent's IPv6 447 address as a source address and the mobile node's IPv4 care-of 448 address in the destination address field. The latter is represented 449 as an IPv4-mapped IPv6 address. 451 The mobile node needs to maintain the NAT bindings for its current 452 IPv4 care-of address. This is done through sending the binding update 453 regularly to the home agent. 455 2.4. Route optimization 457 Route optimization, as specified in [MIPv6] will operate in an 458 identical manner for dual stack mobile nodes when they are located in 459 a visited network that provides IPv6 addresses to the mobile node. 460 However, when located in an IPv4-only network, route optimization 461 will not be possible due to the difficulty of performing the care-of 462 address test. Therefore, mobile nodes will need to communicate 463 through the home agent. 465 Route optimization will not be possible for IPv4 traffic. That is, 466 traffic addressed to the mobile node's IPv4 home address. This is 467 similar to using Mobile IPv4, therefore there is no reduction of 468 features resulting from using this specification. 470 2.5. Dynamic IPv4 home address allocation 472 It is possible to allow for the mobile node's IPv4 home address to be 473 allocated dynamically. This is done by including 0.0.0.0 in the IPv4 474 home address option included in the binding update. The home agent 475 SHOULD allocate an IPv4 address to the mobile node and include it in 476 the IPv4 address acknowledgement option sent to the mobile node. In 477 this case, the lifetime of the binding is bound to the minimum of the 478 lifetimes of the IPv6 binding and the lease time of the IPv4 home 479 address. 481 3. Extensions and modifications to Mobile IPv6 483 This section highlights the protocol and implementation additions 484 required to support this specification. 486 3.1. Binding update extensions 488 3.1.1 IPv4 home address option 490 This option is included in the Mobility Header including the binding 491 update message sent from the mobile node to a home agent or Mobility 492 Anchor Point. 494 0 1 2 3 495 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 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | Type | Length |Pref |P|Res| 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | IPv4 home address | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 Type TBD 504 Length 1 506 Pref The length of the prefix allocated to the mobile 507 node. If only a single address is allocated, 508 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. 515 P A flag indicating, when set, that the mobile 516 node requests a mobile network prefix. This flag 517 is only relevant for new requests, and must be 518 ignored for binding refreshes. 520 Reserved This field is reserved for future use. It MUST 521 be set to zero by the sender and ignored by the 522 receiver. 524 IPv4 home address The mobile node's IPv4 home address that should 525 be defended by the home agent. This field could 526 contain any unicast IPv4 address (public or 527 private) that was assigned to the mobile node. 528 The value 0.0.0.0 is used to request an IPv4 529 home address from the home agent. A mobile node 530 may choose to use this option to request a 531 prefix by setting the address to the All Zeroes 532 and setting the P flag. The mobile node could 533 then form an IPv4 home address based on the 534 allocated prefix. Alternatively, the mobile node 535 may use two different options, one for 536 requesting an address (Static or Dynamic) and 537 another for requesting a prefix. 539 3.2. Binding acknowledgement extensions 541 3.2.1 IPv4 address acknowledgement option 543 This option is included in the Mobility Header including the binding 544 acknowledgement message sent from the home agent or Mobility Anchor 545 Point to the mobile node. This option indicates whether a binding 546 cache entry was created for the mobile node's IPv4 address. 547 Additionally, this option can include an IPv4 home address in the 548 case of Dynamic IPv4 home address configuration (i.e. if the 549 unspecified IPv4 address was included in the binding update). 551 0 1 2 3 552 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 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | Type | Length | Status | Pref | Res | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | IPv4 home address | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 Type TBD 561 Length 1 563 Status Indicates success or failure for the IPv4 home 564 address binding. Values from 0 to 127 indicate 565 success. Higher values indicate failure. The 566 following values are reserved: 567 0 Success 568 128 Failure, reason unspecified 569 129 Administratively prohibited 570 130 Incorrect IPv4 home address 571 131 Invalid IPv4 address 572 132 Dynamic IPv4 home address 573 assignment not available 574 133 Prefix allocation unauthorized 576 Pref The prefix length of the address allocated. This 577 field is only valid in case of success and MUST 578 be set to zero and ignored in case of failure. 579 This field overrides what the mobile node 580 requested (if not equal to the requested 581 length). 583 Res This field is reserved for future use. It MUST 584 be set to zero by the sender and ignored by the 585 receiver. 587 IPv4 home address The IPv4 home address that the home agent will 588 use in the binding cache entry. This could be a 589 public or private address. This field MUST 590 contain the mobile node's IPv4 home address. 591 If the address were dynamically allocated the 592 home agent will add the address to inform the 593 mobile node. Otherwise, if the address were 594 statically allocated to the mobile node, the 595 home agent will copy it from the binding update 596 message. 598 3.2.2 The NAT detection option 600 This option is sent from the home agent to the mobile node to 601 indicate whether a NAT was in the path. This option MAY also include 602 a suggested NAT binding refresh time for the mobile node. 604 0 1 2 3 605 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 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | Type | Length |F| Reserved | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | Refresh time | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 Type TBD 614 Length 1 616 F This flag indicates to the mobile node that UDP 617 encapsulation is required. When set, this flag 618 indicates that the mobile node MUST use UDP 619 encapsulation even if a NAT is not located 620 between the mobile node and home agent. 622 Reserved This field is reserved for future use. It MUST 623 be set to zero by the sender and ignored by the 624 receiver. 626 Refresh time A suggested time (in seconds) for the mobile 627 node to refresh the NAT binding. If set to zero, 628 it is ignored. If this field is set to the all 629 1s it means that keepalives are not needed, i.e. 630 no NAT was detected. 632 4. Protocol operation 634 This section presents the protocol operation and processing for the 635 messages presented above. In addition, this section introduces the 636 NAT detection and traversal mechanism used by this specification. 638 4.1. NAT detection and traversal 640 NAT detection is done when the initial binding update message is sent 641 from the mobile node to the home agent. When located in an IPv4-only 642 foreign link, the mobile node sends the binding update message 643 encapsulated in UDP and IPv4. The source address of the IPv6 packet 644 is the mobile node's IPv4 care-of address represented in IPv4-mapped 645 IPv6 format. The destination address is the IPv6 address of the home 646 agent. The IPv4 header contains the IPv4 care-of address in the 647 source address field and the IPv4 address of the home agent in the 648 destination address field. 650 When the home agent receives the encapsulated binding update it 651 compares the IPv4 address of the source address field in the IPv4 652 header with the IPv4 address in the source address of the IPv6 653 header. If the two addresses match, no NAT device was in the path. 655 Otherwise, a NAT device was in the path and the NAT detection option 656 is included in the binding acknowledgement. The binding 657 acknowledgement, and all future packets, are then encapsulated in UDP 658 and IPv4. The source address in the IPv4 header is the IPv4 address 659 of the home agent. The destination address is the IPv4 address 660 received in the IPv4 header encapsulating the binding update (this 661 address will be different from the IPv4 care-of address when a NAT is 662 in the path). 664 Upon receiving the binding acknowledgement with the NAT detection 665 option, the mobile node sets the tunnel to the home agent to UDP 666 encapsulation. Hence, all future packets to the home agent are 667 tunneled in UDP and IPv4. For all tunneled IPv6 packets, the source 668 address in the IPv6 header is the mobile node's IPv6 home address and 669 the destination address is the correspondent node's IPv6 address. All 670 tunneled IPv4 packets will contain the mobile node's IPv4 home 671 address in the source address field of the inner IPv4 packet and the 672 correspondent node's IPv4 address in the destination address field. 673 The outer IPv4 header is the same whether the inner packet is IPv4 or 674 IPv6. 676 If no NAT device was detected in the path between the mobile node and 677 the home agent then IPv6 packets are tunneled in an IPv4 header, 678 unless the home agent forces UDP encapsulation using the F flag. The 679 content of the inner and outer headers are identical to the UDP 680 encapsulation case. 682 A mobile node MUST always tunnel binding updates in UDP when located 683 in an IPv4-only network. Essentially, this process allows for 684 perpetual NAT detection. Similarly, the home agent MUST encapsulate 685 binding acknowledgements in a UDP header whenever the binding update 686 is encapsulated in UDP. 688 In conclusion, the packet formats for the binding update and 689 acknowledgement messages are shown below: 691 A. Binding update received by the home agent: 693 IPv4 header (src=V4ADDR, dst=HA_V4ADDR) 694 UDP header 695 IPv6 header (src=V4CoA, dst=HAADDR) 696 DST-OPT 697 HAO (IPv6 home address) 698 Mobility header 699 BU [IPv4 HAO] 701 Where V4ADDR is either the IPv4 care-of address or the address 702 provided by the NAT device. V4COA is the IPv4 care-of address of the 703 mobile node. HAO is the home address option and BU is the binding 704 update, which MAY contain the IPv4 home address option. 706 B. Binding acknowledgement sent by the home agent: 707 IPv4 header (src=V4ADDR, dst=HA_V4ADDR) 708 UDP header 709 IPv6 header (src=V4CoA, dst=HAADDR) 710 Route HDR Type 2 711 HOA (IPv6 home address) 712 Mobility header 713 BA ([IPv4 ACK], NAT DET) 715 Where HOA is IPv6 home address of the mobile node. The IPv4 ACK is 716 the IPv4 address acknowledgement option, which is only included if 717 the IPv4 home address option were present in the BU. The NAT DET is 718 the NAT detection option, which MUST be present in the binding 719 acknowledgement message if the binding update was encapsulated in 720 UDP. 722 4.2. NAT Keepalives 724 If a NAT is detected, the mobile node will need to refresh the NAT 725 bindings in order to be reachable from the home agent. NAT bindings 726 can be refreshed through sending and receiving traffic encapsulated 727 in UDP. However, if the mobile node is not active, it will need to 728 periodically send a message to the home agent in order to refresh the 729 NAT binding. This can be done using the binding update message. The 730 binding update/acknowledgement pair will ensure that the NAT bindings 731 are refreshed in a reliable manner. 732 There is no way for the mobile node to know the exact time of the NAT 733 binding. The default time suggested in this specification is 734 NATKATIMEOUT. If the home agent suggests a different refresh period 735 in the binding acknowledgement, the mobile node SHOULD use the value 736 suggested by the home agent. 738 If the refresh time in the NAT detection option in the binding 739 acknowledgement is set to the all 1s, the mobile node need not send 740 messages to refresh the NAT binding. However, the mobile node may 741 still be required to encapsulate traffic in UDP. This scenario may 742 take place when a NAT is not detected, but the home agent still 743 requires the mobile node to use UDP encapsulation. 745 It should be noted that a mobile node that does not need to be 746 reachable (i.e. only cares about the session continuity aspect of 747 Mobile IP) does not need to refresh NAT binding. In this case, the 748 mobile node would only be able to initiate communication with other 749 nodes. 751 4.3. Mobile node operation 753 In addition to the operations specified in [MIPv6] and [NEMO], this 754 specification requires mobile nodes to be able to support an IPv4 755 home address. The IPv4 home address is never sent in the IPv4-mapped 756 IPv6 address format. This is primarily done to save bandwidth. 758 However, to simplify the mobile node's implementation, they may store 759 the IPv4 home address in the binding update list, using the IPv4- 760 mapped IPv6 format. 762 When sending an IPv6 packet containing a binding update while 763 connected to an IPv4-only access network, mobile nodes MUST ensure 764 the following: 766 - The IPv6 packet is encapsulated in UDP and an IPv4 packet. 767 - The source address in the IPv4 header is the mobile node's IPv4 768 care-of address 769 - The destination address in the IPv4 header is the home agent's 770 IPv4 address. 771 - The source address in the IPv6 header is the mobile node's IPv4- 772 mapped IPv6 address. That is, the same IPv4 address in the outer 773 header is placed in the IPv6 header using the mapped address 774 format. 775 - The home address option contains the IPv6 home address as 776 specified in [MIPv6]. 777 - The IPv4 home address option MAY be included in the mobility 778 header. This option contains the IPv4 home address. If the mobile 779 node did not have a static home address it MAY include the 780 unspecified IPv4 address, which acts as a request for a dynamic 781 IPv4 home address. Alternatively, one or more IPv4 home address 782 options may be included with requests for IPv4 prefixes (i.e. with 783 the P flag set.). 784 - The IPv6 packet MUST be authenticated as per [MIPv6], based on the 785 mobile node's IPv6 home address. 787 When sending a binding update from a visited network that supports 788 IPv6, the mobile node MUST follow the rules specified in [MIPv6]. In 789 addition, if the mobile node has an IPv4 home address or needs one, 790 it should include the IPv4 home address option in the mobility 791 header. If the mobile node already has a static IPv4 home address, 792 such address MUST be included in the IPv4 home address option. 793 Otherwise, if the mobile node needs a dynamic IPv4 address, it should 794 include the IPv4 unspecified address in the IPv4 home address option. 796 When the mobile node receives a binding acknowledgement from the home 797 agent, it should follow the rules in [MIPv6] and [NEMO]. In addition, 798 the following actions MUST be made: 800 - If the mobility header includes an IPv4 address acknowledgement 801 option indicating success, the mobile node should create two 802 entries in its binding update list, one for the IPv6 home address 803 and another for the IPv4 home address. 804 - If the NAT detection option were present, the mobile node 805 MUST tunnel future packets in UDP and IPv4. This MUST be indicated 806 in the binding update list. 807 - If no IPv4 address acknowledgement option were present, and an 808 IPv4 home address option was present in the binding update, the 809 mobile node MUST only create one binding update list entry for its 810 IPv6 home address. The mobile node MAY include the IPv4 home 811 address option in future binding updates. 812 - If an IPv4 address acknowledgement option were present and it 813 indicates failure for the IPv4 home address binding, the mobile 814 node MUST NOT create an entry for that address in its binding 815 update list. The mobile node MAY include the IPv4 home address 816 option in future binding updates. 818 4.3.1 Sending packets from a visited network. 820 When the mobile node is located in an IPv6-enabled network it sends 821 and receives IPv6 packets as described in [MIPv6]. IPv4 traffic is 822 encapsulated in IPv6 packets to the home agent. 824 When the mobile node is located in an IPv4 only network, it will send 825 IPv6 packets to its home agent according to the following format: 827 IPv4 header (src=V4ADDR, dst=HA_V4ADDR) 828 [UDP header] 829 IPv6 header (src=V6HoA, dst=CN) 830 Upper layer protocols 832 Where the UDP header is only used if a NAT were detected between the 833 mobile node and the home agent, or if the home agent forced UDP 834 encapsulation. 836 Similarly, IPv4 packets are sent according to the following format: 838 IPv4 header (src=V4ADDR, dst=HA_V4ADDR) 839 [UDP header] 840 IPv4 header (src=V4HoA, dst=V4CN) 841 Upper layer protocols 843 Where the UDP header is only used if a NAT were detected between the 844 mobile node and the home agent, or if the home agent forced UDP 845 encapsulation. 847 4.3.2 Movement detection in IPv4-only networks 849 [MIPv6] describes movement detection mostly based on IPv6-specific 850 triggers. Such triggers would not be available in an IPv4-only 851 network. Hence, a mobile node located in an IPv4-only network SHOULD 852 use [DNAv4] for guidance on movement detection mechanisms in IPv4- 853 only networks. 855 4.4. Home agent operations 857 In addition to the home agent specification in [MIPv6] and [NEMO], 858 the home agent needs to be able to process the IPv4 home address 859 option and generate the IPv4 address acknowledgement option. Both 860 options are included in the mobility header. Furthermore, the home 861 agent MUST be able to detect the presence of a NAT device and 862 indicate that in the NAT detection option included in the binding 863 acknowledgement. 865 A home agent must also act as a proxy for address resolution in IPv4 866 for the registered IPv4 home addresses of mobile nodes it is serving. 867 Moreover, the administrative domain of the home agent is responsible 868 for advertising the routing information of registered IPv4 mobile 869 network prefixes of the mobile nodes. 871 In order to comply with this specification, the home agent MUST be 872 able to find the IPv4 home address of a mobile node when given the 873 IPv6 home address. That is, given an IPv6 home address, the home 874 agent MUST store the corresponding IPv4 home address if a static one 875 is present. If a dynamic address were requested by the mobile node, 876 the home agent MUST store that address (associated with the IPv6 home 877 address) after it's allocated to the mobile node. 879 When the home agent receives a binding update encapsulated in UDP and 880 containing the IPv4 home address option, it needs to follow all the 881 steps in [MIPv6] and [NEMO]. In addition, the following checks MUST 882 be done: 884 - If the IPv4 care-of address in the IPv6 header is not the same as 885 the IPv4 address in the source address in the IPv4 header then a 886 NAT was in the path. This information should be flagged for the 887 binding acknowledgement. 889 - If the IPv4 home address option contains a valid unicast IPv4 890 address, the home agent MUST check that this address is allocated 891 to the mobile node that has the IPv6 home address included in the 892 home address option. The same MUST be done for an IPv4 prefix. 894 - If the IPv4 home address option contained the unspecified IPv4 895 address, the home agent SHOULD dynamically allocate an IPv4 home 896 address to the mobile node. If none is available, the home agent 897 MUST return an appropriate error code in the status field of the 898 IPv4 address acknowledgement option. If a prefix were requested, 899 the home agent MUST allocate a prefix with the requested length; 900 otherwise the home agent MUST indicate failure of the operation 901 with the appropriate error code. 903 - If the binding update is accepted for the IPv4 home address, the 904 home agent MUST create a binding cache entry for the IPv4 home 905 address/prefix. If a single IPv4 home address were requested, it 906 MAY be stored in the IPv4-mapped IPv6 address format. The home 907 agent MUST include an IPv4 acknowledgement option in the mobility 908 header containing the binding acknowledgement. 910 If the binding update is accepted for both IPv4 and IPv6 home 911 addresses, the home agent MUST create two separate binding cache 912 entries, one for each home address. The care-of address is the one 913 included in the binding update. If the care-of address is an IPv4- 914 mapped IPv6 address, the home agent MUST setup a tunnel to the IPv4 915 care-of address of the mobile node. 917 When sending a binding acknowledgement to the mobile node, the home 918 agent would construct the message according to [MIPv6] and [NEMO]. 919 Note that the routing header MUST always contain the IPv6 home 920 address as specified in [MIPv6]. 922 If the care-of address of the mobile node were an IPv4 address, the 923 home agent MUST include this address in the destination address in 924 the IPv6 header using the IPv4-mapped IPv6 format. If a NAT were 925 detected, the home agent MUST then encapsulate the packet in UDP and 926 an IPv4 header. The source address is set to the home agent's IPv4 927 address and the destination address is set to the address received in 928 the source address of the IPv4 header encapsulating the binding 929 update. 931 After creating a binding cache entry for the mobile node's home 932 addresses, all packets sent to the mobile node's home addresses are 933 tunneled by the home agent to the mobile node's care-of address. If a 934 NAT were detected, packets are encapsulated in UDP and IPv4. 935 Otherwise, if the care-of address is an IPv4 address, and no NAT were 936 detected, packets are encapsulated in an IPv4 header. 938 4.4.1 Sending packets to the mobile node 940 The home agent follows the rules specified in [MIPv6] for sending 941 IPv6 packets to mobile nodes located in IPv6 networks. When sending 942 IPv4 packets to When mobile nodes in an IPv6 network, the home agent 943 must encapsulate the IPv4 packets in IPv6. 945 When sending IPv6 packets to a mobile node located in an IPv4 946 network, the home agent must follow the following format: 948 IPv4 header (src= HA_V4ADDR, dst= V4CoA) 949 [UDP header] 950 IPv6 header (src=CN, dst= V6HoA) 951 Upper layer protocols 953 Where the UDP header is only included if a NAT were detected between 954 the mobile node and the home agent, or if the home agent forced UDP 955 encapsulation. 957 When sending IPv4 packets to a mobile node located in an IPv4 958 network, the home agent must follow the following format: 960 IPv4 header (src= HA_V4ADDR, dst= V4CoA) 962 [UDP header] 963 IPv4 header (src=V4CN, dst= V4HoA) 964 Upper layer protocols 966 Where the UDP header is only included if a NAT were detected between 967 the mobile node and home agent, or if the home agent forced UDP 968 encapsulation. 970 4.5. Correspondent node operations 972 This specification has no impact on IPv4 or IPv6 correspondent nodes. 974 5. Security considerations 976 This specification allows a mobile node to send one binding update 977 for its IPv6 and IPv4 home addresses. This is a slight deviation from 978 [MIPv6] which requires one binding update per home address. However, 979 like [MIPv6], the IPsec security association needed to authenticate 980 the binding update is still based on the mobile node's IPv6 home 981 address. Therefore, in order to authorize the mobile node's IPv4 home 982 address binding, the home agent MUST store the IPv4 address 983 corresponding to the IPv6 address that is allocated to a mobile node. 984 Therefore, it is sufficient for the home agent to know that the IPsec 985 verification for the packet containing the binding update was valid 986 provided that it knows which IPv4 home address is associated with 987 which IPv6 home address. Hence, the security of the IPv4 home address 988 binding is the same as the IPv6 binding. 990 In effect, associating the mobile node's IPv4 home address with its 991 IPv6 home address moves the authorization of the binding update for 992 the IPv4 address to the Mobile IPv6 implementation, which infers it 993 from the fact that mobile node has an IPv6 home address and the right 994 credentials for sending an authentic binding update for such address. 996 6. Protocol constants 998 NATKATIMEOUT 110 seconds 1000 7. Acknowledgements 1002 Thanks to Keiichi Shima for his comments on the draft. 1004 8. IANA considerations 1006 The specification requires the following allocations from IANA: 1007 - A UDP port is needed for the NAT traversal mechanism described in 1008 section 4.1. 1009 - The IPv4 home address option described in section 3.1.1 requires an 1010 option type. This option is included in the Mobility header 1011 described in [MIPv6]. 1012 - The IPv4 address acknowledgement option described in section 3.2.1 1013 requires a new option type. This option is included in the Mobility 1014 header described in [MIPv6]. 1015 - The NAT detection option described in section 3.2.2 requires a new 1016 option type. This option is included in the Mobility header 1017 described in [MIPv6]. 1019 9. References 1021 [BOOT] Giaretta, G. (Ed.), Kempf J., and V. Devarapalli, " Mobile 1022 IPv6 bootstrapping in split scenario", draft-ietf-mip6- 1023 bootstrapping-split, June 2005, work in progress. 1025 [HMIPv6] Soliman, H., Castelluccia, C., ElMalki, K., and L. Bellier, 1026 "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", 1027 RFC 4140, August 2005. 1029 [IPv6] S. Deering and B. Hinden, "Internet Protocol version 6 (IPv6) 1030 specification", RFC 2460 1032 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 1033 Requirement Levels", BCP 14, RFC 2119, March 1997. 1035 [MIP-PB] Tsirtsis, G., and H. Soliman, "Mobility management for 1036 Dual stack mobile nodes, A Problem Statement", 1037 draft-ietf-mip6-dsmip-problem-01.txt, July 2005. 1039 [MIPv4] C. Perkins, "Mobility Support for IPv4", RFC3344 1041 [MIPv6] D. Johnson, C. Perkins and J. Arkko, "Mobility Support in 1042 IPv6", RFC 3775, June 2004. 1044 [NEMO] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, 1045 "Network Mobility (NEMO) Basic Support protocol", RFC 3963, 1046 January 2005. 1048 [SEC] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 1049 Protoect Mobile IPv6 Signaling between Mobile Nodes and Home 1050 Agents", RFC 3776, June 2004. 1052 [SNRIO] Larsson, T., Gustafsson, E., and H. Levkowetz, "Use of MIPv6 1053 in IPv4 and MIPv4 in IPv6 networks", draft-larsson-v6ops- 1054 mip-scenarios-01.txt, February 2004. 1056 Authors' Addresses 1058 Hesham Soliman 1059 Qualcomm-Flarion Technologies 1060 E-mail: Hesham@Qualcomm.com 1062 George Tsirtsis 1063 Qualcomm-Flarion Technologies 1064 Phone: +1 908 947 7059 1065 E-mail1: G.Tsirtsis@Qualcomm.com 1066 E-mail2: tsirtsisg@yahoo.com 1068 Vijay Devarapalli 1069 E-mail: vijay.devarapalli@nokia.com 1071 James Kempf 1072 DoCoMo Labs USA 1073 181 Metro Drive 1074 Suite 300 1075 San Jose, CA 1076 95110 1077 E-mail: kempf@docomolabs-usa.com 1079 Henrik Levkowetz 1080 Ericsson Research 1081 Torshamsgatan 23 1082 S-164 80 Stockholm 1083 SWEDEN 1084 Phone: +46 708 32 16 08 1085 E-mail: henrik@levkowetz.com 1087 Pascal Thubert 1088 Cisco Systems 1089 Village d'Entreprises Green Side 1090 400, Avenue de Roumanille 1091 Batiment T3 1092 Biot - Sophia Antipolis 1093 06410 1094 FRANCE 1095 Phone: +33 4 97 23 26 34 1096 E-mail: pthubert@cisco.com 1098 Wakikawa Ryuji 1099 Keio University 1100 Department of Environmental Information, 1101 Keio University. 1102 5322 Endo 1103 Fujisawa, 1104 Kanagawa 252-8520 1105 Japan 1107 Phone: +81-466-49-1100 1108 Fax: +81-466-49-1395 1109 E-mailryuji@sfc.wide.ad.jp 1110 Web: http://www.wakikawa.org/ 1112 Intellectual Property Statement 1113 The IETF takes no position regarding the validity or scope of any 1114 Intellectual Property Rights or other rights that might be claimed to 1115 pertain to the implementation or use of the technology described in 1116 this document or the extent to which any license under such rights 1117 might or might not be available; nor does it represent that it has 1118 made any independent effort to identify any such rights. Information 1119 on the IETF's procedures with respect to rights in IETF Documents can 1120 be found in RFC 3667 (BCP 78) and RFC 3668 (BCP 79). 1122 Copies of IPR disclosures made to the IETF Secretariat and any 1123 assurances of licenses to be made available, or the result of an 1124 attempt made to obtain a general license or permission for the use of 1125 such proprietary rights by implementers or users of this 1126 specification can be obtained from the IETF on-line IPR repository at 1127 http://www.ietf.org/ipr. 1129 The IETF invites any interested party to bring to its attention any 1130 copyrights, patents or patent applications, or other proprietary 1131 rights that may cover technology that may be required to implement 1132 this standard. Please address the information to the IETF at ietf- 1133 ipr@ietf.org. 1135 Full Copyright Statement 1137 Copyright (C) The Internet Society (2006). This document is subject 1138 to the rights, licenses and restrictions contained in BCP 78, and 1139 except as set forth therein, the authors retain all their rights. 1141 Disclaimer of Validity 1143 This document and the information contained herein are provided on an 1144 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1145 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1146 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1147 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1148 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1149 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1151 This Internet-Draft expires December, 2006.