INTERNET-DRAFT                                          R. Hinden/Nokia
January 4, 2002



                    IPv6 Host to Router Load Sharing

               <draft-ietf-ipv6-host-load-sharing-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].

   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.

   This internet draft expires on July 4, 2002.

Abstract

   This document defines a change to IPv6 Neighbor Discovery that IPv6
   hosts can use to load share their outgoing traffic between multiple
   default routers.
















draft-ietf-ipv6-host-load-sharing-00.txt                        [Page 1]


INTERNET-DRAFT      IPv6 Host to Router Load Sharing     January 4, 2002


1.  Introduction

   IPv6 hosts on a LAN will usually learn about default routers by
   receiving Router Advertisements sent using the IPv6 Neighbor
   Discovery protocol [ND].  If there are multiple routers the hosts
   will automatically learn about them and have multiple default routers
   to send off link traffic.

   IPv6 Neighbor Discovery protocol does not require any specific
   procedure for hosts to divide (i.e., load share) outgoing traffic
   between these routers.  This document defines procedures that IPv6
   hosts can use to load share their outgoing traffic between multiple
   default routers.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC 2119].


2. Background

   RFC2461 "Neighbor Discovery for IPv6" [ND] defines in section 6.3.6
   an algorithm for selecting default routers.  This algorithm is
   invoked during next hop determination when no destination cache entry
   exists for an off-link destination or when communication through an
   existing router is failing.  Normally a router would be selected the
   first time traffic is sent to a specific destination.   Subsequent
   traffic to the same destination would continue to use this router
   unless there was some other reason to change to a different router
   (e.g., redirect message received, etc.).

   ND further specifies that when there are multiple reachable default
   routers, an implementation may always return the same router (e.g.,
   the first in the list) or may cycle through the list of reachable
   default routers in a round robin manner.  It does not require any
   specific behavior in the case of multiple default routers.

   It is desirable when there is more than one default router that the
   hosts distribute their outgoing traffic among these routers.  This
   document changes the ND behavior to require that an implementation
   cycle through the list of default routers in a random order.










draft-ietf-ipv6-host-load-sharing-00.txt                        [Page 2]


INTERNET-DRAFT      IPv6 Host to Router Load Sharing     January 4, 2002


3. Load Sharing

   The load sharing algorithm changes the currently specified default
   router selection algorithm to cycle through the list of reachable
   default routers in random order.  This should have the effect of
   distributing outgoing traffic for new destinations among the default
   routers.  Random selection, versus round robin, is used to avoid
   synchronization in the hosts selection of a default router.

   Bullet 1) in section 6.3.6 "Default Router Selection" [ND] is
   replaced with the following:

     1) Routers that are reachable or probably reachable (i.e., in any
        state other than INCOMPLETE) SHOULD be preferred over routers
        whose reachability is unknown or suspect (i.e., in the
        INCOMPLETE state, or for which no Neighbor Cache entry exists).
        An implementation SHOULD pick routers from the default router
        list in random order while making sure it always returns a
        reachable or a probably reachable router when one is available.


4. Acknowledgments

   The author of this document would like to thank Erik Nordmark, Brian
   Haberman, Steve Deering, Aron Silverton, and Christian Huitema for
   their helpful suggestions.


5. Security Considerations

   This document requires an node to cycle through a the list of default
   routers.  There are no known security issues with this change to IPv6
   Neighbor Discovery.


6. References

   [ADD-ARH] Hinden, R., S. Deering, "IP Version 6 Addressing
             Architecture", RFC2373, July 1988.

   [ICMPv6]  Conta, A., S. Deering, "Internet Control Message Protocol
             (ICMPv6) for the Internet Protocol Version 6 (IPv6)",
             RFC2463, December 1998.

   [IPv6]    Deering, S., R. Hinden, "Internet Protocol, Version 6
             (IPv6) Specification", RFC2460, December 1998.





draft-ietf-ipv6-host-load-sharing-00.txt                        [Page 3]


INTERNET-DRAFT      IPv6 Host to Router Load Sharing     January 4, 2002


   [ND]      Narten, T., E. Nordmark, W. Simpson, "Neighbor Discovery
             for IP Version 6 (IPv6)", RFC2461, December 1998.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", RFC2119, BCP0014, March 1997.


7. Author's Address

   Robert Hinden
   Nokia
   313 Fairchild Drive
   Mountain View, CA 94043
   US

   Phone: +1 650 625-2004
   Email: hinden@iprg.nokia.com


































draft-ietf-ipv6-host-load-sharing-00.txt                        [Page 4]