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]