idnits 2.17.1 draft-korhonen-mif-ra-offload-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 31, 2012) is 4254 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Multiple Interfaces (Mif) J. Korhonen 3 Internet-Draft Nokia Siemens Networks 4 Intended status: Experimental T. Savolainen 5 Expires: March 4, 2013 Nokia 6 A. Ding, Ed. 7 University of Helsinki 8 August 31, 2012 10 Controlling Traffic Offloading Using Neighbor Discovery Protocol 11 draft-korhonen-mif-ra-offload-05.txt 13 Abstract 15 This specification defines an extension to IPv6 Neighbor Discovery 16 Protocol, which allows management of IPv4 traffic offloading for 17 multi-interface dual-stack capable hosts and moving IPv4 traffic away 18 from a specific interface. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on March 4, 2013. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Requirements and Terminology . . . . . . . . . . . . . . . . . 3 56 3. Problem Background . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4.1. Neighbor Discovery Offload Option . . . . . . . . . . . . 4 59 4.2. Lowering IPv4 Router Preference . . . . . . . . . . . . . 7 60 4.3. IPv4 Offloading to Default Gateway . . . . . . . . . . . . 7 61 4.4. IPv4 Offloading to Specific Routes . . . . . . . . . . . . 8 62 4.5. Offload Lifetime . . . . . . . . . . . . . . . . . . . . . 8 63 5. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 8 64 6. Host Behavior . . . . . . . . . . . . . . . . . . . . . . . . 9 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 70 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 71 Appendix A. Address Selection Approach . . . . . . . . . . . . . 11 72 A.1. Modification to Default Address Selection . . . . . . . . 11 73 A.2. Address selection examples . . . . . . . . . . . . . . . . 11 74 A.2.1. Case 1: IPv6-only cellular and IPv4-only WLAN 75 accesses . . . . . . . . . . . . . . . . . . . . . . . 11 76 A.2.2. Case 2: WLAN access with multiple prefixes . . . . . . 12 77 A.2.3. Case 3: WLAN and cellular interface with 78 cellular's IPv4 not default route . . . . . . . . . . 12 79 A.2.4. Case 4: Dual-stack cellular access . . . . . . . . . . 12 80 A.2.5. Case 5: Dual-stack cellular and single stack WLAN . . 13 81 A.2.6. Case 6: Coexistence with RFC4191 . . . . . . . . . . . 13 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 84 1. Introduction 86 This specification defines an extension to Neighbor Discovery 87 Protocol [RFC4861], which allows management of IPv4 traffic 88 offloading for multi-interface dual-stack capable hosts and moving 89 IPv4 traffic away from a specific interface. 91 The described solution is intended to be used during transition 92 towards IPv6, during which time multi-interfaced hosts are often 93 likely to have network interfaces with IPv4-only capability. A 94 common scenario where coexistence of IPv4 and IPv6 network interfaces 95 is expected to occur is when a smartphone has IPv6-enabled cellular 96 connection and IPv4-only WLAN connection active at the same time. 98 2. Requirements and Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 3. Problem Background 106 Current Internet hosts generally prefer IPv6 addresses over IPv4 107 addresses when performing source and destination address selections, 108 as is recommended in [I-D.ietf-6man-rfc3484bis]. 110 A multi-interfaced host may have IPv6 enabled on a more 'expensive' 111 interface and a 'cheaper' interface may have support only for IPv4. 112 In such a scenario it might be desirable for hosts to prefer IPv4 in 113 communication instead of IPv6. 115 The above mentioned scenario can become a problem, for example, when 116 a smartphone has simultaneously IPv6-enabled cellular connection 117 ([RFC6459]) and IPv4-only WLAN connectivity active. When connecting 118 to dual-stack capable destinations it would oftentimes be generally 119 more efficient to use WLAN network interface. Furthermore, a 120 cellular network operator may want hosts to offload traffic away from 121 the cellular network whenever hosts have alternate network accesses 122 available. 124 Similar issues can arise also when a host has multiple interfaces 125 with IPv4 connectivity. The interface that provides better 126 performance at a lower price should oftentimes be used for the 127 communication, but it may not be clear for a host which one of the 128 available interfaces it should prefer. 130 4. Solution 132 This document introduces a new Neighbor Discovery option that a 133 network can use to communicate router's willingness to act as a 134 default gateway for IPv4 traffic and IPv4 offloading information for 135 specific routes. 137 The new Neighbor Discovery option was chosen to support hosts without 138 DHCPv6 [RFC3315] and DHCPv4 Classless Static Route Option [RFC3442] 139 support and also to work on networks not utilizing DHCPv6 and DHCPv4. 141 The Neighbor Discovery option proposed in this document SHOULD be 142 phased out when IPv4 usage diminishes. 144 4.1. Neighbor Discovery Offload Option 146 This specification defines a new Neighbor Discovery [RFC4861] option 147 called Offload (Type TBD) to be used in Router Advertisements. The 148 option is illustrated in Figure 1 and Figure 2. Routers and hosts 149 implementing this specification MUST understand the Offload option. 151 0 1 2 3 152 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 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Type | Length |D| Reserved | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | IPv4 Gateway | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | GW Lifetime | Reserved | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Reserved | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Specific Route Information ... 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 165 Figure 1: Router Advertisement Offload Option 167 Type 169 TBD by IANA. 171 Length 173 8-bit unsigned integer. The length of the option (including the 174 Type and Length fields) is in units of 8 octets. The Length field 175 depends on the optional Specific Route Information. If there is 176 no Specific Route Information, the Length MUST be 2. 178 D (IPv4 Gateway Preference) 180 Indicates the willingness of the Dual-Stack capable router (which 181 originated the Router Advertisement) to serve as a gateway for the 182 IPv4 traffic. If 'D' is unset (0) then the router indicates no 183 preference as to whether it is willing to serve as a gateway for 184 IPv4 traffic. If 'D' is set (1) then the router explicitly 185 indicates it is not willing to serve as a gateway for IPv4 traffic 186 if there are other usable gateways present in the same or other 187 available interfaces. 189 Reserved 191 Unused field. It MUST be initialized to zero by the sender and 192 MUST be ignored by the receiver. 194 IPv4 Gateway 196 The address of a dual-stack router's IPv4 interface which is used 197 as the next-hop from the host's point of view for sending and 198 receiving IPv4 traffic on this link. The IPv4 address MUST belong 199 to the same interface that originated the Router Advertisement 200 containing this Offload option. 202 GW Lifetime 204 16-bit unsigned integer. The Lifetime in seconds limits the 205 validity of state changes caused by this new option. The value of 206 Lifetime in this option SHOULD be smaller than or equal to the 207 value of Router Lifetime contained in the header of the same 208 Router Advertisement[RFC4191]. 210 Specific Route Information 212 Optional information for IPv4 offloading to specific routes. The 213 format is illustrated in Figure 2. An Offload option can contain 214 multiple specific route entries. 216 Each Specific Route Information entry is in the length of 8 octets, 217 containing Route Lifetime, Route Preference, Prefix Length, and IPv4 218 Prefix. Multiple Specific Route entries can be contained within the 219 same Offload option. 221 0 1 2 3 222 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 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Route Lifetime |Prf| Resvd | Prefix Length | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | IPv4 Prefix 1 | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Route Lifetime |Prf| Resvd | Prefix Length | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | IPv4 Prefix 2 | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | More Specific Routes ... 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 235 Figure 2: Specific Route Information 237 Route Lifetime 239 16-bit unsigned integer. The length of time in seconds (relative 240 to the time the packet is sent) that the IPv4 prefix is valid for 241 route determination. The value of Route Lifetime SHOULD be 242 smaller than or equal to the value of GW Lifetime contained in the 243 same Offload option. 245 Prf (Route Preference) 247 2-bit signed integer. The preference values are encoded as 248 follows: 01 for High; 00 for Medium (default); 11 for Low; and 10 249 for Reserved which MUST NOT be sent. The Route Preference 250 indicates whether to prefer the router associated with this prefix 251 over others, when multiple identical prefixes for different 252 routers have been received. 254 Resvd (Reserved) 256 6-bit unused field. It MUST be initialized to zero by the sender 257 and MUST be ignored by the receiver. 259 Prefix Length 261 8-bit unsigned integer. The number of leading bits in the IPv4 262 Prefix field that are valid. The value ranges from 0 to 32. 264 IPv4 Prefix 266 The IPv4 Prefix field contains an IPv4 address. The Prefix Length 267 field contains the number of valid leading bits in the prefix. 268 The bits in the prefix after the prefix length (if any) are 269 reserved and MUST be initialized to zero by the sender and ignored 270 by the receiver. 272 If the router is IPv6 only, the Neighbor Discovery Offload option 273 MUST be omitted in all Router Advertisements originated by the 274 router. 276 To avoid misconfiguration of offloading operation, a single Router 277 Advertisement MUST contain only one Offload option. 279 The behavior of 'IPv4 Gateway Preference' is discussed in more detail 280 in the following sections (see Section 4.2). The usage of 'IPv4 281 Gateway' for offloading is discussed in Section 4.4 and Section 4.3. 282 The Offload option is used only in Router Advertisements. 284 4.2. Lowering IPv4 Router Preference 286 The 'D' flag bit in the Offload option indicates the willingness of a 287 Dual-Stack capable router originating the Router Advertisement to 288 serve as a gateway for IPv4 traffic. If 'D' is set (1), the router 289 indicates that it SHOULD NOT be used as a gateway for IPv4 traffic, 290 if other gateways are present in the same or other available 291 interfaces. If 'D' is unset (0), the router does not indicate any 292 preference of being or not being a gateway for IPv4 traffic. When 293 'D' is unset (0), the decision of temporarily modifying the routing 294 status is left for hosts that receive the Offload option (see 295 Section 4.3 and Section 4.4). The 'IPv4 Gateway' field in the 296 Offload option contains the IPv4 address of the Dual-Stack interface 297 that originated the Router Advertisement. The address serves as the 298 identification of the next-hop IPv4 router. 300 4.3. IPv4 Offloading to Default Gateway 302 If there is no Specific Route Information in the Offload option, the 303 default gateway for IPv4 offloading can be added, updated, or deleted 304 depending on the 'D' flag, GW Lifetime, and existing routing status 305 on the hosts. When 'D' is set (1), the existing default gateway 306 matching to the advertised one SHOULD be removed if there are other 307 usable gateways present in the same or other available interfaces. 309 When 'D' is unset (0) and there is no default gateway present for the 310 receiving interface, the advertised IPv4 Gateway with valid lifetime 311 can be added. If the advertised gateway matches to the existing one 312 on the host, depending on the advertised lifetime, the existing 313 lifetime of default gateway shall be updated to the advertised GW 314 Lifetime in Offload option or deleted if the GW Lifetime is set to 0. 315 If there is a default gateway existing on the receiving interface, 316 which does not match the advertised gateway, the advertised one 317 SHOULD be ignored. 319 4.4. IPv4 Offloading to Specific Routes 321 To enable IPv4 traffic offloading to specific routes, Specific Route 322 Information MUST be included in the same Offload option. A host 323 receiving such Router Advertisement needs to maintain status 324 including the IPv4 Gateway, IPv4 Prefix, Prefix Length, Route 325 Preference, and Route Lifetime. The Route Preference in the Offload 326 option indicates whether to prefer the IPv4 router associated with 327 this prefix over others. The Route Lifetime in the Offload option 328 determines how long the temporarily added specific route will be 329 valid. 331 When 'D' flag is unset (0) in the Offload option, the advertised 332 Specific Route Information shall be added by hosts if there is no 333 duplicated IPv4 prefix matching to the advertised IPv4 prefix and the 334 advertised Route Lifetime in Offload option is valid. If there is a 335 matching prefix, such specific route will be updated or deleted 336 according to the status of Route Lifetime and Route Preference. The 337 Route Lifetime in Offload option determines whether the route will be 338 deleted or updated depending on the existing routing status of the 339 hosts. If the advertised Route Lifetime is set to 0, any matched 340 IPv4 prefix and corresponding gateway MUST be removed. If Lifetime 341 is valid, the Route Preference further determines whether the IPv4 342 Gateway for the existing prefix, if matched, will be substituted to 343 the advertised one, or the lifetime for existing route will be 344 updated. 346 When 'D' flag is set (1) in the Offload option, any existing specific 347 routes with the next-hop router matching to the advertised IPv4 348 Gateway MUST be removed. 350 4.5. Offload Lifetime 352 The GW Lifetime in the Offload option determines the valid period of 353 temporary routing changes including IPv4 Gateway and offloading IPv4 354 traffic to specific routes. If a host receives a new Router 355 Advertisement without the Offload option, it MUST remove all existing 356 offload state information related to the router sending the Router 357 Advertisement. 359 5. Router Behavior 361 A router configuration SHOULD allow the network administrator to add 362 and configure this option into Router Advertisement messages. The 363 configuration can be selectively enabled (the Offload option is 364 included in the Router Advertisement) or disabled (the Offload option 365 is not included in the Router Advertisement). 367 6. Host Behavior 369 A multi-interface capable host SHOULD monitor the presence of the 370 Offload option in Router Advertisements received. When an Offload 371 option is received, the IPv4 Gateway Preference and offloading status 372 for this router shall be temporarily updated as described in 4.2 and 373 4.3. Depending on the presence of Specific Route Information in the 374 same Offload option, the status of offloading IPv4 traffic to 375 specific routes shall be temporarily updated as described in 4.4. 376 Hosts SHOULD refer to both GW Lifetime and Route Lifetime (if 377 present) in the Offload option to determine the valid time of routing 378 changes caused by the Router Advertisement received. 380 If the host receives a Router Advertisement without the Offload 381 option and there is an existing state created by an earlier received 382 Offload option, then the host MUST remove all IPv4 gateway 383 preferences and offloading modifications from the previous Router 384 Advertisement. The removals concern only prefixes configured from 385 the router where the router advertisement was received. 387 7. Security Considerations 389 The Offload option allows malicious hosts and routers to affect a 390 victim host's next hop and default address selection if spoofing of 391 Router Advertisements are possible on the access link. This is a 392 well-known and understood security threat [RFC3756] and can be 393 mitigated using, for example, Secure Neighbor Discovery [RFC3971]. 394 The security of utilizing the Offload option is at the equal level to 395 solution in [RFC4191]. 397 8. IANA Considerations 399 This specification defines a new Neighbor Discovery option described 400 in Section 4.1. 402 9. Acknowledgements 404 Authors would like to thank Konstantinos Pentikousis for valuable 405 suggestions. 407 10. References 409 10.1. Normative References 411 [I-D.ietf-6man-rfc3484bis] 412 Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 413 "Default Address Selection for Internet Protocol version 6 414 (IPv6)", draft-ietf-6man-rfc3484bis-06 (work in progress), 415 June 2012. 417 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 418 Requirement Levels", BCP 14, RFC 2119, March 1997. 420 [RFC3442] Lemon, T., Cheshire, S., and B. Volz, "The Classless 421 Static Route Option for Dynamic Host Configuration 422 Protocol (DHCP) version 4", RFC 3442, December 2002. 424 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 425 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 426 September 2007. 428 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 429 Address Autoconfiguration", RFC 4862, September 2007. 431 10.2. Informative References 433 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 434 and M. Carney, "Dynamic Host Configuration Protocol for 435 IPv6 (DHCPv6)", RFC 3315, July 2003. 437 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 438 Discovery (ND) Trust Models and Threats", RFC 3756, 439 May 2004. 441 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 442 Neighbor Discovery (SEND)", RFC 3971, March 2005. 444 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 445 More-Specific Routes", RFC 4191, November 2005. 447 [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., 448 Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 449 Partnership Project (3GPP) Evolved Packet System (EPS)", 450 RFC 6459, January 2012. 452 Appendix A. Address Selection Approach 454 A.1. Modification to Default Address Selection 456 The 'lower-than-IPv4 Preference' affects the Source Address Selection 457 Rule 3. The notation Lower(SA) returns true if the address SA was 458 configured from the prefixes advertised by a 'lower-than-IPv4 459 Preference' router. Lower(SA) returns false is the address SA was 460 configured from prefixes advertised by other than 'lower-than-IPv4 461 Preference' router. The notation Default(D) returns false if the 462 address D has more specific routes (i.e. other than the default 463 route). Default(D) returns true if the address D points only to a 464 default route. The modified Rule 3 would be as follows: 466 Rule 3: Avoid deprecated addresses. 468 The addresses SA and SB have the same scope. If Lower(SA) == true 469 and Default(D) == true, then mark SA temporarily as "deprecated". 470 If Lower(SB) == true and Default(D) == true, then mark SB 471 temporarily as "deprecated". If one of the two source addresses 472 is "preferred" and one of them is "deprecated" (in the [RFC4862] 473 sense), then prefer the one that is "preferred." 475 Similar modification also concerns the Destination Address Selection 476 Rule 3 when checking whether a candidate source address for a given 477 destination is deprecated. 479 A.2. Address selection examples 481 Link-local addresses are omitted in all following examples. The 482 assumption is that possible destinations have a global scope and all 483 IPv6 enabled interfaces have at least one global scope IPv6 address. 484 Therefore, the default address selection would always output global 485 scope addresses over link-local addresses. 487 A.2.1. Case 1: IPv6-only cellular and IPv4-only WLAN accesses 489 A host has obtained global IPv6 address, 2001:db8::2, on a cellular 490 interface and with it has received Neighbor Discovery option with 491 'lower-than-IPv4' preference. The host also has global IPv4 address, 492 192.0.2.2, on a WLAN interface. 494 When connecting to a dual-stack enabled destination, both 2001:db8::2 495 and 192.0.2.2 are considered as source addresses candidates. IPv4 496 address is selected, because 2001:db8::2 is considered deprecated. 497 Hence host uses WLAN for communication. 499 When connecting to IPv6-only destination, 2001:db8::2 is selected and 500 cellular network used, as there are no other IPv6 addresses 501 available. 503 A.2.2. Case 2: WLAN access with multiple prefixes 505 A host has obtained two global IPv6 addresses, one of which was from 506 a router indicating 'lower-than-IPv4' preference. For example, 2001: 507 db8:1::2 from router with 'lower-than-IPv4' preference and 508 2001:db8:2::3 from router without any special preferences. 510 When connecting to IPv6-only destination, both addresses are 511 considered as source address candidates. Source address selection 512 chooses 2001:db8:2::3 as 2001:db8:1::2 is considered deprecated 513 (Lower(2001:db8::2) == true and Default(D) == true). 515 A.2.3. Case 3: WLAN and cellular interface with cellular's IPv4 not 516 default route 518 A host has obtained IPv6 address, 2001:db8::2, and IPv4 address, 519 192.0.2.2, from cellular network. The network has indicated 'lower- 520 than-IPv4' preference for IPv6 and 'not your default router' for 521 IPv4. The host also has dual-stack WLAN access with 2001:db8:1::3 522 and 192.0.2.30 addresses. 524 When connecting to IPv4-only destination, host selects 192.0.2.30 as 525 source address because default gateway on the interface of 192.0.2.2 526 address is 'not default gateway'. WLAN is used for communication. 528 When connecting to IPv6-only destination, host selects 2001:db8:1::3 529 from WLAN interface as the 2001:db8::2 is considered deprecated 530 (Lower(2001:db8::2) == true and Default(D) == true). WLAN is used 531 for communication. 533 When connecting to dual-stack destination, host selects from the four 534 candidate addresses 2001:db8:1::3, as IPv6 is preferred in general 535 and as that address is not deprecated. WLAN is used for 536 communication. 538 A.2.4. Case 4: Dual-stack cellular access 540 A host has obtained IPv6 address, 2001:db8::2, and IPv4 address, 541 192.0.2.2, from cellular network. The network has indicated 'lower- 542 than-IPv4' preference. 544 When connecting to a dual-stack enabled destination, both addresses 545 are considered as candidate source addresses. IPv4 address is 546 chosen, because IPv6 address is considered deprecated. 548 A.2.5. Case 5: Dual-stack cellular and single stack WLAN 550 A host has obtained IPv6 address, 2001:db8::2, and IPv4 address, 551 192.0.2.2, from cellular network. The network has indicated 'lower- 552 than-IPv4' preference for IPv6 and 'not your default router' for 553 IPv4. The host also has WLAN access with 192.0.2.30 address. 555 When connecting to dual-stack destination, all three addresses are 556 considered as source address candidates. The IPv4 address from WLAN, 557 192.0.2.30, is selected as the IPv6 address, 2001:db8::2, is 558 considered deprecated and as the IPv4 default route points to WLAN. 559 Hence WLAN is used for communication. 561 A.2.6. Case 6: Coexistence with RFC4191 563 A host has obtained IPv6 address, 2001:db8:1::2/64 from cellular 564 network. The network has indicated 'lower-than-IPv4' preference for 565 IPv6 and a more specific route to 2001:db8:2::/48. The host also has 566 IPv6 WLAN access with 2001:db8:3::3/64 address. 568 When connecting to 2001:db8:2::1 the host selects 2001:db8:1::2 from 569 cellular interface as a source address, because Lower(2001:db8:1::2) 570 == true and Default(2001:db8:2::1) == false and hence the 571 2001:db8:1::2 is not considered as deprecated address even though 572 'lower-than-IPv4' preference was advertised. 574 When connecting to 2001:db8:4::1 the host selects 2001:db8:3::3 from 575 WLAN interface as a source address, because Lower(2001:db8:2::1) == 576 true and Default(2001:db8:3::3) == true) and hence 2001:db8:2::1 is 577 considered as deprecated address. 579 Authors' Addresses 581 Jouni Korhonen 582 Nokia Siemens Networks 583 Linnoitustie 6 584 FI-02600 Espoo 585 Finland 587 Email: jouni.nospam@gmail.com 588 Teemu Savolainen 589 Nokia 590 Hermiankatu 12 D 591 FI-33720 Tampere 592 Finland 594 Email: teemu.savolainen@nokia.com 596 Aaron Yi Ding (editor) 597 University of Helsinki 598 P.O. Box 68 599 FI-00014 University of Helsinki 600 Finland 602 Email: yding@cs.helsinki.fi