[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01

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]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/