INTERNET-DRAFT Sebastien Roy Expires August 2003 Alain Durand James Paugh Sun Microsystems, Inc. February 2003 IPv6 on by Default draft-roy-v6ops-v6onbydefault-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract The dual stack model is based on the assumption that applications can try communicating to destinations over IPv6 first and fall back to IPv4 if IPv6 doesn't work. Before turning the dual stack on by default, we need to make sure that this assumption holds even in cases where IPv6 connectivity is not perfect. This document looks at scenarios in which things can go wrong if the IPv6 dual stack is enabled by default. Roy, et al. February 24, 2003 [Page 1] INTERNET-DRAFT IPv6 on by Default February 2003 Table of Contents 1. Introduction ..................................... 2 2. No IPv6 router ................................... 2 2.1. Use Default Address Selection for IPv6 ........... 3 3. IPv6 Network of Smaller Scope .................... 3 3.1. Alleviating the Scope Problem .................... 4 4. Poor IPv6 Network Performance .................... 4 4.1. Dealing with Poor IPv6 Network Performance ....... 4 5. Security ......................................... 5 5.1. Mitigating Security Risks ........................ 5 6. Application Robustness ........................... 5 7. References ....................................... 6 8. Authors' Addresses ............................... 7 1. Introduction On dual stack IPv6 nodes, applications that support communication over IPv6 will try IPv6 first, then fall back to IPv4 if IPv6 communication fails. This behavior doesn't work well in all situations. Dual stack hosts with IPv6 enabled by default can be deployed into environments where this behavior causes unacceptable connection delays, suboptimal IP communication, or security breaches. This document breaks down some scenarios in which problems can occur. 2. No IPv6 Router Neighbor Discovery's [1] conceptual sending algorithm dictates that when sending a packet to a destination, if a host's default router list is empty, then the host assumes that the destination is on-link. For an IPv6 enabled host deployed on a network that has no IPv6 routers, the result is that link-layer address resolution must be performed on all IPv6 destinations to which the host sends packets. Applications will not receive acknowledgment of the unreachability of destinations that are not on-link until at least address resolution has failed, which is no less than three seconds (MAX_MULTICAST_SOLICIT * RETRANS_TIMER), plus any transport layer connection timeouts which could be minutes in the case of TCP. On a network that has no IPv6 routing and no IPv6 neighbors, making the assumption that every IPv6 destination is on-link will be a costly and incorrect assumption. If an application has a list of addresses associated with a destination and the first n are IPv6 addresses, then the application won't be able to successfully send a Roy, et al. February 24, 2003 [Page 2] INTERNET-DRAFT IPv6 on by Default February 2003 packet to the destination until the attempts to resolve each IPv6 address have failed and any transport timeouts have expired for each connection attempt. If IPv6 hosts don't assume that destinations are on-link as described above, then communication with destinations that are not on-link and unreachable will immediately fail. The IPv6 implementation should be able to immediately notify applications that it has no route to such IPv6 destinations, and applications won't waste time waiting for address resolution to fail. If hosts need to communicate with on-link destinations, then then they need to be explicitly configured to have on-link routes for those destinations. 2.1. Use Default Address Selection for IPv6 The Default Address Selection for IPv6 [2] destination address selection mechanism, if used by applications, would minimize the problem by placing IPv6 addresses at the end of the list of addresses returned by name lookups. The host has only generated a link-local address, so the scope of IPv6 destinations won't match any possible IPv6 source. This mitigating factor only works if applications use standard name resolution API's that implement this mechanism, and these applications try addresses in the order returned. This may not be an acceptable assumption in some cases, so it would be better to implement this mechanism, and not make the on-link assumption described in this section. 3. IPv6 Network of Smaller Scope A network that has a smaller scope of connectivity for IPv6 as it does for IPv4 could be a problem in some cases. If applications have access to name to address mapping information that is of greater scope than the connectivity to those addresses, there is obvious potential for suboptimal network performance. Hosts will attempt to communicate with IPv6 destinations that are outside the scope of the IPv6 routing, and depending on how the scope boundaries are enforced, applications may not be notified that packets are being dropped at the scope boundary. If applications aren't immediately notified of the lack of reachability to IPv6 destinations, then they aren't able to efficiently fall back to IPv4. They then have to rely on transport layer timeouts Roy, et al. February 24, 2003 [Page 3] INTERNET-DRAFT IPv6 on by Default February 2003 which can be minutes in the case of TCP. An example of such a network is an enterprise network that has both IPv4 and IPv6 routing within the enterprise and has a firewall configured to allow some IPv4 communication, but no IPv6 communication. 3.1. Alleviating the Scope Problem To allow applications to correctly fall back to IPv4 when IPv6 packets are destined beyond their allowed scope, the devices enforcing the scope boundary should send ICMP Destination Unreachable messages back to senders of such packets. 4. Poor IPv6 Network Performance By default in dual stack nodes, applications will try IPv6 destinations first. If the IPv6 connectivity to those destinations is poor while the IPv4 connectivity is better (i.e., the IPv6 traffic experiences higher latency, lower throughput, or more lost packets than IPv4 traffic), applications will still communicate over IPv6 at the expense of network performance. There is no information available to applications in this case to advise them to try another destination address. An example of such a situation is a node which obtains IPv4 connectivity natively through an ISP, but whose IPv6 connectivity is obtained through a configured tunnel whose other endpoint is topologically such that most IPv6 communication is done through triangular routes. Operational experience on the 6bone shows that IPv6 RTT's are poor in such situations. 4.1. Dealing with Poor IPv6 Network Performance Not much can be done in this case other than configure each node to prefer IPv4 destinations over IPv6. If hosts implement the Default Address Selection for IPv6 [2] policy table, IPv4 mapped addresses could be assigned higher precedence, resulting in applications trying IPv4 for communication first. This has the negative side-effect that these nodes will almost never use IPv6 unless the only address published in the DNS for a given name is IPv6., presumably because of this phenomenon. Roy, et al. February 24, 2003 [Page 4] INTERNET-DRAFT IPv6 on by Default February 2003 5. Security Enabling IPv6 on a host implies that the services on the host may be open to IPv6 communication. If the service itself is insecure and depends on security policy enforced somewhere else on the network (such as from a firewall), then there is potential for new attacks against the service. A firewall, for example, may not be enforcing the same policy for IPv4 as for IPv6 traffic. One possibility is that the firewall could have more relaxed policy for IPv6, perhaps by letting all IPv6 packets pass through, or by letting all IPv4 protocol 41 packets pass through. In this scenario, the hosts within the protected network could be subject to different attacks than for IPv4. Even if a firewall has a stricter policy or identical policy for IPv6 traffic than for IPv4 (the extreme case being that it drops all IPv6 traffic), IPv6 packets could go through the network untouched if tunneled over a transport layer. This could open the host to direct IPv6 attacks. 5.1. Mitigating Security Risks Establishing a security policy that is the same for IPv4 and IPv6 would help mitigate this risk. There is still a risk that IPv6 packets could be tunneled over a transport layer implicitly bypassing security policy. Some more complex mechanism could be implemented to apply the correct policy to such packets. This could be easy to do if tunnel endpoints are collocated with a firewall, but more difficult if internal nodes do their own IPv6 tunneling. 6. Application Robustness Enabling IPv6 on a dual stack node is only useful if applications that support IPv6 on that node properly cycle through addresses returned from name lookups and fall back to IPv4 when IPv6 communication fails. Simply cycling through the list of addresses returned from a name lookup when attempting connections works in most cases for most applications, but there are still cases where that's not enough. Applications also need to be aware that the fact that a dual stack destination's IPv6 address is published in the DNS does not imply that all services on that destination function over IPv6. One example is an application that resolves a destination name to a Roy, et al. February 24, 2003 [Page 5] INTERNET-DRAFT IPv6 on by Default February 2003 list of addresses with the intent to contact multiple services at that destination (i.e., http and IMAP). The application tries to contact the first service via the first IPv6 address in the list and succeeds. The success of the connection results in the application throwing away the list of addresses it was given by the name lookup and remembering this single IPv6 address as the usable address for the destination. The second service it tries, however, is only implemented for IPv4. The application tries to communicate to the second service using the same IPv6 address, the connection fails, and no fall back to IPv4 occurs because the application is outside of the context of cycling through the list of addresses returned from the name lookup. Applications should not assume that because a service is reachable at an IPv6 address, that other services at that destination are also reachable via that IPv6 address. 7. References [1] T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [2] R. Draves, "Default Address Selection for IPv6", draft-ietf-ipv6-default-addr-select-09.txt, August 2002. Roy, et al. February 24, 2003 [Page 6] INTERNET-DRAFT IPv6 on by Default February 2003 8. Authors' Addresses Sebastien Roy Sun Microsystems, Inc. 1 Network Drive, UBUR02-212 Burlington, MA 01801 Email: sebastien.roy@sun.com Alain Durand Sun Microsystems, Inc. 17 Network Circle, UMPK17-202 Menlo Park, CA 94025 Email: alain.durand@sun.com James Paugh Sun Microsystems, Inc. 17 Network Circle, UMPK17-202 Menlo Park, CA 94025 Email: james.paugh@sun.com Roy, et al. February 24, 2003 [Page 7]