idnits 2.17.1 draft-ietf-v6ops-v6onbydefault-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 16 longer pages, the longest (page 14) being 71 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 17 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 271: '... [HOSTREQS] document, in section 4.2.3.9., states that TCP MUST NOT...' RFC 2119 keyword, line 275: '...ute failed), and SHOULD abort connecti...' RFC 2119 keyword, line 329: '... In section 4.2.4.1, [HOSTREQS] states that there MUST be a mechanism...' RFC 2119 keyword, line 351: '... As noted in [HOSTREQS] section 4.1.3.3, UDP implementations MUST pass...' 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 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.) -- The document date (May 7, 2004) is 7287 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3484 (ref. 'ADDRSEL') (Obsoleted by RFC 6724) -- Possible downref: Non-RFC (?) normative reference: ref. 'APPTRANS' ** Obsolete normative reference: RFC 2461 (ref. 'ND') (Obsoleted by RFC 4861) -- Possible downref: Non-RFC (?) normative reference: ref. 'ONLINK' -- Obsolete informational reference (is this intentional?): RFC 2462 (ref. 'AUTOCONF') (Obsoleted by RFC 4862) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. Roy 2 Internet-Draft A. Durand 3 Expires: November 5, 2004 J. Paugh 4 Sun Microsystems, Inc. 5 May 7, 2004 7 Issues with Dual Stack IPv6 on by Default 8 draft-ietf-v6ops-v6onbydefault-02.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on November 5, 2004. 32 Copyright Notice 34 Copyright (C) The Internet Society (2004). All Rights Reserved. 36 Abstract 38 This document discusses problems that can occur when dual stack nodes 39 that have IPv6 enabled by default are deployed in IPv4 or mixed IPv4 40 and IPv6 environments. The problems include application connection 41 delays, poor connectivity, and network insecurity. The purpose of 42 this memo is to raise awareness of these problems so that they can be 43 fixed or worked around, not to try to specify whether IPv6 should be 44 enabled by default or not. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. No IPv6 Router . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2.1 Problems with Default Address Selection for IPv6 . . . . . 3 51 2.2 Neighbor Discovery's On-Link Assumption Considered 52 Harmful . . . . . . . . . . . . . . . . . . . . . . . . . 5 53 2.3 Transport Protocol Robustness . . . . . . . . . . . . . . 6 54 2.3.1 TCP Implications . . . . . . . . . . . . . . . . . . . 6 55 2.3.2 UDP Implications . . . . . . . . . . . . . . . . . . . 8 56 2.3.3 SCTP Implications . . . . . . . . . . . . . . . . . . 8 57 3. Other Problematic Scenarios . . . . . . . . . . . . . . . . . 9 58 3.1 IPv6 Network of Smaller Scope . . . . . . . . . . . . . . 9 59 3.1.1 Alleviating the Scope Problem . . . . . . . . . . . . 10 60 3.2 Poor IPv6 Network Performance . . . . . . . . . . . . . . 10 61 3.2.1 Dealing with Poor IPv6 Network Performance . . . . . . 10 62 3.3 Security . . . . . . . . . . . . . . . . . . . . . . . . . 11 63 3.3.1 Mitigating Security Risks . . . . . . . . . . . . . . 11 64 4. Application Robustness . . . . . . . . . . . . . . . . . . . . 12 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 66 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 12 68 6.2 Informative References . . . . . . . . . . . . . . . . . . . 13 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 70 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 71 B. Changes from draft-ietf-v6ops-v6onbydefault-01 . . . . . . . . 14 72 C. Changes from draft-ietf-v6ops-v6onbydefault-00 . . . . . . . . 14 73 Intellectual Property and Copyright Statements . . . . . . . . 16 75 1. Introduction 77 This document specifically addresses operating system implementations 78 that implement the dual stack IPv6 model, and would ship with IPv6 79 enabled by default. It addresses the case where such systems are 80 installed and placed in IPv4-only or mixed IPv4 and IPv6 81 environments, and documents potential problems that users on such 82 systems could experience if the IPv6 connectivity is non-existent or 83 sub-optimal. The purpose of this document is not to try to specify 84 whether IPv6 should be enabled by default or not, but to raise 85 awareness of the potential issues involved. 87 This memo begins in Section 2 by examining problems within IPv6 88 implementations that defeat the destination address selection 89 mechanism defined in [ADDRSEL] and contribute to poor IPv6 90 connectivity. Starting with Section 3 it then examines other issues 91 that network software engineers and network and systems 92 administrators should be aware of when deploying dual stack systems 93 with IPv6 enabled. 95 2. No IPv6 Router 97 Consider a scenario in which a dual stack system has IPv6 enabled and 98 is placed on a link with no IPv6 routers. The system is using IPv6 99 Stateless Address Autoconfiguration [AUTOCONF], so it only has a 100 link-local IPv6 address configured. It also has a single IPv4 101 address that happens to be a private address as defined in 102 [PRIVADDR]. 104 An application on this system is trying to communicate with a 105 destination whose name resolves to public and global IPv4 and IPv6 106 addresses. The application uses an address resolution API that 107 implements the destination address selection mechanism described in 108 Default Address Selection for IPv6 [ADDRSEL]. The application will 109 attempt to connect to each address, in the order they were returned, 110 until one succeeds. Since the system has no off-link IPv6 routes, 111 the optimal scenario would be if the IPv4 addresses returned were 112 ordered before the IPv6 addresses. The following sections describe 113 what things can go wrong with this scenario. 115 2.1 Problems with Default Address Selection for IPv6 117 The Default Address Selection for IPv6 [ADDRSEL] destination address 118 selection mechanism could save the application a few useless 119 connection attempts by placing the IPv4 addresses in front of the 120 IPv6 addresses. This would be desired since all IPv6 destinations in 121 this scenario are unreachable (there's no route to them), and the 122 system's only IPv6 source address is inadequate to communicate with 123 off-link destinations even if it did have an off-link route. 125 Let's examine how the destination address selection mechanism behaves 126 in the face of this scenario when given one IPv4 destination and one 127 IPv6 destination. 129 The first rule, "Avoid unusable destinations", would prefer the IPv4 130 destination over the IPv6 destination, but only if the IPv6 131 destination were determined to be unreachable. The unreachability 132 determination for a destination as it pertains to this rule is an 133 implementation detail. One implementable method is to do a simple 134 forwarding table lookup on the destination, and to deem the 135 destination as reachable if the lookup succeeds. The Neighbor 136 Discovery on-link assumption mentioned in Section 2.2 makes this 137 method somewhat irrelevant, however, as an implementation of the 138 assumption could simply be to insert an IPv6 default on-link route 139 into the system's forwarding table when the default router list is 140 empty. The side-effect is that the rule would always determine that 141 all IPv6 destinations are reachable. Therefore, this rule will not 142 necessarily prefer one destination over the other. 144 The second rule, "Prefer matching scope", could prefer the IPv4 145 destination over the IPv6 destination, but only if the IPv4 146 destination's scope matches the scope of the system's IPv4 source 147 address. Since [ADDRSEL] considers private addresses (as defined in 148 [PRIVADDR]) of site-local scope, then this rule will not prefer 149 either destination over the other. The link-local IPv6 source 150 doesn't match the global IPv6 destination, and the "site-local" IPv4 151 source doesn't match the global IPv4 destination. The tie-breaking 152 rule in this case is rule 6, "Prefer higher precedence". Since IPv6 153 destinations are of higher precedence than IPv4 destinations in the 154 default policy table, the IPv6 destination will be preferred. 156 The solution in this case could be to add a new rule after rule 2 157 (rule 2.5) that avoids non-link-local IPv6 destinations whose 158 selected source addresses are link-local. Of course, if the host is 159 manually assigned a global IPv6 source address, then rule 2 will 160 automatically prefer the IPv6 destination, and there is no fix other 161 than to make sure rule 1 considers IPv6 destinations unreachable in 162 this scenario. 164 Fixing the destination address selection mechanism by adding such a 165 rule is only a mitigating factor if applications use standard name 166 resolution API's that implement this mechanism, and these 167 applications try addresses in the order returned. This may not be an 168 acceptable assumption in some cases, as there are applications that 169 use hard coded addresses and address search orders and/or literal 170 addresses passed in from the user. 172 For example, one such application is the DNS resolver. In this case, 173 a configuration file usually contains a list of literal addresses to 174 be used as DNS name servers. The resolver client tries these servers 175 in the order that they appear in the file, bypassing address 176 selection rules. 178 Such applications will obviously be subject to whatever connection 179 delays are associated with attempting a connection to an unreachable 180 destination. This is discussed in more detail in the next few 181 sections. 183 2.2 Neighbor Discovery's On-Link Assumption Considered Harmful 185 Let's assume that the application described in Section 2 is 186 attempting a connection to an IPv6 address first, either because the 187 destination address selection mechanism described in Section 2.1 188 returned the addresses in that order, or because the application 189 isn't trying the addresses in the order returned. Regardless, the 190 user expects that the application will quickly connect to the 191 destination. It is therefore important that the system quickly 192 determine that the IPv6 destination is unreachable so that the 193 application can try the IPv4 destination. 195 Neighbor Discovery's [ND] conceptual sending algorithm states that 196 when sending a packet to a destination, if a host's default router 197 list is empty, then the host assumes that the destination is on-link. 198 This issue is described in detail in [ONLINK]. In summary, this 199 assumption makes the unreachability detection of off-link nodes in 200 the absence of a default router a lengthy operation. This is due to 201 the cost of attempting Neighbor Discovery link-layer address 202 resolution for each destination, and potential transport layer costs 203 associated with connection timeouts. The transport layer issues are 204 discussed later in Section 2.3. 206 On a network that has no IPv6 routing and no IPv6 neighbors, making 207 the assumption that every IPv6 destination is on-link will be costly 208 and incorrect. If an application has a list of addresses associated 209 with a destination and the first 15 are IPv6 addresses, then the 210 application won't be able to successfully send a packet to the 211 destination until the attempts to resolve each IPv6 address have 212 failed. This could take 45 seconds (MAX_MULTICAST_SOLICIT * 213 RETRANS_TIMER * 15). This could be compounded by any transport 214 timeouts associated with each connection attempt, bringing the 215 timeouts to even dozens of minutes. 217 If IPv6 hosts don't assume that destinations are on-link as described 218 above, then communication with destinations that are not on-link and 219 unreachable should immediately fail. The IPv6 implementation should 220 be able to immediately notify applications or the transport layer 221 that it has no route to such IPv6 destinations, so that applications 222 won't waste time waiting for address resolution to fail. 224 If hosts need to communicate with on-link destinations in the absence 225 of default routers, then then they need to be explicitly configured 226 to have on-link routes for those destinations. 228 2.3 Transport Protocol Robustness 230 Making the same set of assumptions as Section 2.2, regardless of how 231 long the network layer takes to determine that the IPv6 destination 232 is unreachable, the delay associated with a connection attempt to an 233 unreachable destination can be compounded by the transport layer. 234 When the unreachability of a destination is obviated by the reception 235 of an ICMPv6 destination unreachable message, the transport layer 236 should make it possible for the application or API to deal with this. 237 It could fail the connection attempt, pass ICMPv6 errors up to the 238 application, or pass them up to an API that is handling this for the 239 application, etc. 241 Such messages would be received in the cases mentioned in Section 2 242 in which a node has no default routers and NUD fails for destinations 243 assumed to be on-link, and when firewalls or other systems that 244 enforce scope boundaries send such ICMPv6 errors as described in 245 Section 3.1 and Section 3.3. 247 For cases when packets to a destination are essentially black-holed 248 and no ICMPv6 errors are generated, there is very little additional 249 remedy other than the existing timer mechanisms inside transport 250 layers and applications. The following transport layer implication 251 discussions deal with the former case, in which ICMPv6 errors are 252 received. 254 2.3.1 TCP Implications 256 In the case of a socket application attempting a connection via TCP, 257 it would be unreasonable for the application to block even after the 258 system has received notification that the destination address is 259 unreachable via an ICMPv6 Destination Unreachable message. 261 Following are some ways of solving TCP related delays associated with 262 destination unreachability when ICMPv6 errors are generated. 264 2.3.1.1 TCP Connection Termination 266 One solution for TCP is to abort connections in SYN-SENT or 267 SYN-RECEIVED state when it receives an ICMPv6 Destination Unreachable 268 message. 270 It should be noted that the Requirements for Internet Hosts 271 [HOSTREQS] document, in section 4.2.3.9., states that TCP MUST NOT 272 abort connections when receiving ICMP Destination Unreachable 273 messages that indicate "soft errors", where soft errors are defined 274 as ICMP codes 0 (network unreachable), 1 (host unreachable), and 5 275 (source route failed), and SHOULD abort connections upon receiving 276 the other codes (which are considered "hard errors"). ICMPv6 didn't 277 exist when that document was written, but one could extrapolate the 278 concept of soft errors to ICMPv6 Type 1 codes 0 (no route to 279 destination) and 3 (address unreachable), and hard errors to the 280 other codes. Thus, it could be argued that a TCP implementation that 281 behaves as suggested in this section is in conflict with [HOSTREQS]. 283 When [HOSTREQS] was written, most applications would mostly only try 284 one address when establishing communication with a destination. Not 285 aborting a connection was a sane thing to do if re-trying a single 286 address was a better alternative over quitting the application 287 altogether. With IPv6, and especially on dual stack systems, 288 destinations are often assigned multiple addresses (at least one IPv4 289 and one IPv6 address), and applications iterate through destination 290 addresses when attempting connections. 292 Since soft errors conditions are those that would cause an 293 application to continue iterating to another address, TCP could 294 simply not make the distinction between ICMPv6 soft errors and hard 295 errors when in SYN-SENT or SYN-RECEIVED state. It would abort a 296 connection in those states when receiving any ICMPv6 Destination 297 Unreachable message. When in any other state, TCP would behave as 298 described in [HOSTREQS]. 300 Many TCP implementations already behave this way, but others do not. 301 This should be noted as a best current practice in this case. 303 A tangential method of handling the problem in this way would be for 304 applications to somehow notify the TCP layer of their preference in 305 the matter. An application could notify TCP that it should abort a 306 connection upon receipt of particular ICMPv6 errors. Similarly, it 307 could notify TCP that it should not abort a connection. This would 308 allow existing TCP implementations to maintain their status quo at 309 the expense of increased application complexity. 311 Drawbacks do exist for this TCP behavior. One drawback involves a 312 transient problem existing at the network layer that could cause all 313 destinations to be unreachable for a temporary length of time. In 314 such a situation, the application could quickly cycle through the 315 destinations and return an error, when it could have let TCP retry a 316 destination a few seconds later when the transient problem could have 317 been mitigated. 319 Another drawback is related to the insecurity of ICMP messages. 320 Reacting to "soft errors" in all TCP connection states would have 321 significant security implications, as it would be possible for anyone 322 to reset established sessions, even without IP spoofing. However, 323 this document only proposes reacting to such errors in SYN-SENT or 324 SYN-RECEIVED states. These states are very short-lived, so the 325 window of exposure is very short and the threat is negligible. 327 2.3.1.2 Asynchronous Application Notification 329 In section 4.2.4.1, [HOSTREQS] states that there MUST be a mechanism 330 for reporting soft TCP error conditions to the application. Such a 331 mechanism (assuming one is implemented) could be used by applications 332 to cycle through destination addresses. 334 2.3.1.3 Higher Level API 336 Regardless of which solution is used, an API that handles connection 337 attempts to a destination in a transparent way could remove the 338 complexity from applications and handle this scenario gracefully. The 339 API could contain the intelligence required to resolve the hostname, 340 try each destination address, etc. 342 Such an API would also help to build applications that are protocol 343 independent, and would reduce the impact on applications when 344 transport layer behavior changes. 346 The drawback of this approach is the need to change applications to 347 use the API. 349 2.3.2 UDP Implications 351 As noted in [HOSTREQS] section 4.1.3.3, UDP implementations MUST pass 352 to the application layer all ICMP error messages that it receives 353 from the IP layer, granted that the socket used is connected. As a 354 result, proper handling destination unreachability by UDP 355 applications is the responsibility of the applications themselves. 357 A higher level API as mentioned in Section 2.3.1.3 could remove the 358 complexity from applications in this case as well. 360 2.3.3 SCTP Implications 362 According to [SCTPIMP], SCTP ignores all ICMPv6 destination 363 unreachable messages that do not indicate that the SCTP protocol 364 itself is unreachable. The existing SCTP specifications do not 365 suggest any action on the part of the implementation on reception of 366 a "soft error". 368 Unlike TCP, SCTP itself is multihomed and allows a user to specify a 369 list of addresses to connect to. Upon reception of a Destination 370 Unreachable Message during connection setup SCTP should attempt to 371 retransmit the Initiation message to one of its alternate addresses 372 and put the address that encountered the "soft error" into the 373 unreachable state. This will prevent use of the address after the 374 association is set-up until SCTP's heartbeat mechanism finds the 375 address to be reachable. 377 In some cases the application may not have provided a list of 378 addresses. In these cases it may be beneficial for SCTP, at a 379 minimum, to mark the address as unreachable so that the application 380 can acquire a notification through its application interface. In 381 such a case the application could then either take action upon the 382 address notification by aborting the connection attempt or allow 383 SCTP's normal timer mechanism to continue retransmitting the INIT 384 message to the peer's address. 386 There is work in progress to specify adding the support for handling 387 soft errors to the SCTP specification. 389 3. Other Problematic Scenarios 391 This section describes problems that could arise for a dual stack 392 system with IPv6 enabled when placed on a network with IPv6 393 connectivity. 395 3.1 IPv6 Network of Smaller Scope 397 A network that has a smaller scope of connectivity for IPv6 as it 398 does for IPv4 could be a problem in some cases. If applications have 399 access to name to address mapping information that is of greater 400 scope than the connectivity to those addresses, there is obvious 401 potential for suboptimal network performance. Hosts will attempt to 402 communicate with IPv6 destinations that are outside the scope of the 403 IPv6 routing, and depending on how the scope boundaries are enforced, 404 applications may not be notified that packets are being dropped at 405 the scope boundary. 407 If applications aren't immediately notified of the lack of 408 reachability to IPv6 destinations, then they aren't able to 409 efficiently fall back to IPv4. They then have to rely on transport 410 layer timeouts which can be minutes in the case of TCP. 412 An example of such a network is an enterprise network that has both 413 IPv4 and IPv6 routing within the enterprise and has a firewall 414 configured to allow some IPv4 communication, but no IPv6 415 communication. 417 3.1.1 Alleviating the Scope Problem 419 To allow applications to correctly fall back to IPv4 when IPv6 420 packets are destined beyond their allowed scope, the devices 421 enforcing the scope boundary must send ICMPv6 Destination Unreachable 422 messages back to senders of such packets. The sender's transport 423 layer should act on these errors as described in Section 2.3. 425 3.2 Poor IPv6 Network Performance 427 Most applications on dual stack nodes will try IPv6 destinations 428 first by default due to the Default Address Selection mechanism 429 described in [ADDRSEL]. If the IPv6 connectivity to those 430 destinations is poor while the IPv4 connectivity is better (i.e., the 431 IPv6 traffic experiences higher latency, lower throughput, or more 432 lost packets than IPv4 traffic), applications will still communicate 433 over IPv6 at the expense of network performance. There is no 434 information available to applications in this case to advise them to 435 try another destination address. 437 An example of such a situation is a node which obtains IPv4 438 connectivity natively through an ISP, but whose IPv6 connectivity is 439 obtained through a configured tunnel whose other endpoint is 440 topologically such that most IPv6 communication is done through 441 triangular IPv4 paths. Operational experience on the 6bone shows 442 that IPv6 RTT's are poor in such situations. 444 3.2.1 Dealing with Poor IPv6 Network Performance 446 There are few options from the end node's perspective. One is to 447 configure each node to prefer IPv4 destinations over IPv6. If hosts 448 implement the Default Address Selection for IPv6 [ADDRSEL] policy 449 table, IPv4 mapped addresses could be assigned higher precedence, 450 resulting in applications trying IPv4 for communication first. This 451 has the negative side-effect that these nodes will almost never use 452 IPv6 unless the only address published in the DNS for a given name is 453 IPv6, presumably because of this phenomenon. 455 Disabling IPv6 on the end nodes is another solution. The idea would 456 be that enabling IPv6 on dual stack nodes is a manual process that 457 would be done when the administrator knows that IPv6 connectivity is 458 adequate. 460 3.3 Security 462 Enabling IPv6 on a host implies that the services on the host may be 463 open to IPv6 communication. If the service itself is insecure and 464 depends on a security policy enforced somewhere else on the network 465 (such as in a firewall), then there is potential for new attacks 466 against the service. 468 A firewall may not be enforcing the same policy for IPv4 as for IPv6 469 traffic, which could be due to misconfiguration of the firewall. One 470 possibility is that the firewall could have more relaxed policy for 471 IPv6, perhaps by letting all IPv6 packets pass through, or by letting 472 all IPv4 protocol 41 packets pass through. In this scenario, the 473 dual stack hosts within the protected network could be subject to 474 different attacks than for IPv4. 476 Even if a firewall has a stricter policy or identical policy for IPv6 477 traffic than for IPv4 (the extreme case being that it drops all IPv6 478 traffic), IPv6 packets could go through the network untouched if 479 tunneled over a transport layer. This could open the host to direct 480 IPv6 attacks. It should be noted that IPv4 packets can also be 481 tunneled, so this is not a new security concern for IPv6. Firewalls 482 must be deliberately and properly configured. 484 A similar problem could exist for virtual private network (VPN) 485 software. A VPN could protect all IPv4 packets but transmit all 486 others onto the local subnet unprotected. At least one widely used 487 VPN behaves this way. This is problematic on a dual stack host that 488 has IPv6 enabled on its local network. It establishes its VPN link 489 and attempts to communicate with destinations that resolve to both 490 IPv4 and IPv6 addresses. The destination address selection mechanism 491 prefers the IPv6 destination so the application sends packets to an 492 IPv6 address. The VPN doesn't know about IPv6, so instead of 493 protecting the packets and sending them to the remote end of the VPN, 494 it passes such packets in the clear to the local network. 496 This is problematic for a number of reasons. The first is that if 497 the node has a default IPv6 route, the packets will be forwarded 498 off-link to an unknown destination. Another is if no legitimate 499 router is on-link and the node makes the on-link assumption discussed 500 in Section 2.2, the packets will simply be sent onto the local link 501 to be potentially viewed by a node spoofing the destination. A third 502 is if a rogue IPv6 router exists on-link. In that case the malicious 503 node will simply be sent all IPv6 packets in the clear. 505 3.3.1 Mitigating Security Risks 507 The security policy implemented in firewalls, VPN software, or other 508 devices, must take a stance whether it applies equally to both IPv4 509 and IPv6 traffic. It is probably desirable for the policy to apply 510 equally to both IPv4 and IPv6, but the most important thing is to be 511 aware of the potential problem, and to make the policy clear to the 512 administrator and user. 514 There is still a risk that IPv6 packets could be tunneled over a 515 transport layer such as UDP, implicitly bypassing the security 516 policy. Some more complex mechanisms could be implemented to apply 517 the correct policy to such packets. This could be easy to do if 518 tunnel endpoints are co-located with a firewall, but more difficult 519 if internal nodes do their own IPv6 tunneling. 521 4. Application Robustness 523 Enabling IPv6 on a dual stack node is only useful if applications 524 that support IPv6 on that node properly cycle through addresses 525 returned from name lookups and fall back to IPv4 when IPv6 526 communication fails. Simply cycling through the list of addresses 527 returned from a name lookup when attempting connections works in most 528 cases for most applications, but there are still cases where that's 529 not enough. Applications also need to be aware that the fact that a 530 dual stack destination's IPv6 address is published in the DNS does 531 not necessarily imply that all services on that destination function 532 over IPv6. This problem, along with a thorough discussion of IPv6 533 application transition guidelines, is discussed in [APPTRANS]. 535 5. Security Considerations 537 This document raises security concerns in Section 3.3. They are 538 summarized below: 540 o Firewalls need to be configured properly to have deliberate 541 security policies for IPv6 packets, including IPv6 packets 542 encapsulated in other layers. 544 o Implementations of virtual private networks need to have a 545 deliberate IPv6 security policy that doesn't allow packets to 546 accidentally appear in the clear when they were intended to be 547 sent securely over the VPN. 549 6. References 551 6.1 Normative References 553 [ADDRSEL] Draves, R., "Default Address Selection for Internet 554 Protocol version 6 (IPv6)", RFC 3484, February 2003. 556 [APPTRANS] 557 Hong, Y-G., Hagino, J., Savola, P. and M. Castro, 558 "Application Aspects of IPv6 Transition", March 2004. 560 draft-ietf-v6ops-application-transition-02 562 [ND] Narten, T., Nordmark, E. and W. Simpson, "Neighbor 563 Discovery for IP Version 6 (IPv6)", RFC 2461, December 564 1998. 566 [ONLINK] Roy, S., Durand, A. and J. Paugh, "IPv6 Neighbor Discovery 567 On-Link Assumption Considered Harmful", October 2003. 569 draft-ietf-v6ops-onlinkassumption-02 571 6.2 Informative References 573 [AUTOCONF] 574 Thomson, S. and T. Narten, "IPv6 Stateless Address 575 Autoconfiguration", RFC 2462, December 1998. 577 [HOSTREQS] 578 Braden, R., "Requirements for Internet Hosts -- 579 Communication Layers", STD 3, RFC 1122, October 1989. 581 [PRIVADDR] 582 Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. 583 and E. Lear, "Address Allocation for Private Internets", 584 BCP 5, RFC 1918, February 1996. 586 [SCTPIMP] Stewart, R., Arias-Rodriguez, I., Poon, K., Caro, A. and 587 M. Tuexen, "", November 2003. 589 draft-ietf-tsvwg-sctpimpguide-10 591 Authors' Addresses 593 Sebastien Roy 594 Sun Microsystems, Inc. 595 1 Network Drive 596 UBUR02-212 597 Burlington, MA 01801 599 EMail: sebastien.roy@sun.com 600 Alain Durand 601 Sun Microsystems, Inc. 602 17 Network Circle 603 UMPK17-202 604 Menlo Park, CA 94025 606 EMail: alain.durand@sun.com 608 James Paugh 609 Sun Microsystems, Inc. 610 17 Network Circle 611 UMPK17-202 612 Menlo Park, CA 94025 614 EMail: james.paugh@sun.com 616 Appendix A. Acknowledgments 618 The authors gratefully acknowledge the contributions of Jim Bound, 619 Fernando Gont, Tony Hain, Tim Hartrick, Mika Liljeberg, Erik 620 Nordmark, Kacheong Poon, Pekka Savola, Randall Stewart, and Ronald 621 van der Pol. 623 Appendix B. Changes from draft-ietf-v6ops-v6onbydefault-01 625 o Added specificity to the DNS resolver problem in Section 2.1. 627 o Added a few paragraphs in Section 2.3.1.1 describing potential 628 drawbacks to TCP aborting connections ins SYN-SENT or SYN-RECEIVED 629 state. 631 o Added Section 2.3.1.3 describing how a higher level API could be 632 used to manage connections. 634 o Expanded Section 2.3.3 to describe desired SCTP behavior when 635 encountering soft errors. 637 o Added a summary of security concerns to Section 5. 639 o Miscellaneous editorial changes. 641 Appendix C. Changes from draft-ietf-v6ops-v6onbydefault-00 643 o Clarified in the abstract and introduction that the document is 644 meant to raise awareness, and not to specify whether IPv6 should 645 be enabled by default or not. 647 o Shortened Section 2.2 and made reference to [ONLINK]. 649 o Added clarification in Section 2.3 about packets that are lost 650 without ICMPv6 notification. 652 o Section 2.3 now has subsections for TCP, UDP, and SCTP. 654 o Removed text in Section 2.3.1.1 suggesting that hosts usually were 655 only assigned one address when [HOSTREQS] was written. 657 o Added text in Section 2.3.1.1 suggesting a method for applications 658 to advise TCP of their preference for ICMPv6 handling. 660 o Added Section 2.3.1.2. 662 o Added Section 2.3.2. 664 o Added Section 2.3.3. 666 o Strengthened wording in Section 3.1.1 to suggest that devices 667 enforcing scope boundaries must send ICMPv6 Destination 668 Unreachable messages. 670 o Clarified that the VPN problem described in Section 3.3 is due to 671 a combination of the VPN software and either the on-link 672 assumption and/or a "bad guy". 674 o Shortened Section 4 and made reference to [APPTRANS]. 676 o Miscellaneous editorial changes. 678 Intellectual Property Statement 680 The IETF takes no position regarding the validity or scope of any 681 intellectual property or other rights that might be claimed to 682 pertain to the implementation or use of the technology described in 683 this document or the extent to which any license under such rights 684 might or might not be available; neither does it represent that it 685 has made any effort to identify any such rights. Information on the 686 IETF's procedures with respect to rights in standards-track and 687 standards-related documentation can be found in BCP-11. Copies of 688 claims of rights made available for publication and any assurances of 689 licenses to be made available, or the result of an attempt made to 690 obtain a general license or permission for the use of such 691 proprietary rights by implementors or users of this specification can 692 be obtained from the IETF Secretariat. 694 The IETF invites any interested party to bring to its attention any 695 copyrights, patents or patent applications, or other proprietary 696 rights which may cover technology that may be required to practice 697 this standard. Please address the information to the IETF Executive 698 Director. 700 Full Copyright Statement 702 Copyright (C) The Internet Society (2004). All Rights Reserved. 704 This document and translations of it may be copied and furnished to 705 others, and derivative works that comment on or otherwise explain it 706 or assist in its implementation may be prepared, copied, published 707 and distributed, in whole or in part, without restriction of any 708 kind, provided that the above copyright notice and this paragraph are 709 included on all such copies and derivative works. However, this 710 document itself may not be modified in any way, such as by removing 711 the copyright notice or references to the Internet Society or other 712 Internet organizations, except as needed for the purpose of 713 developing Internet standards in which case the procedures for 714 copyrights defined in the Internet Standards process must be 715 followed, or as required to translate it into languages other than 716 English. 718 The limited permissions granted above are perpetual and will not be 719 revoked by the Internet Society or its successors or assignees. 721 This document and the information contained herein is provided on an 722 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 723 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 724 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 725 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 726 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 728 Acknowledgment 730 Funding for the RFC Editor function is currently provided by the 731 Internet Society.