RFC 2462 (rfc2462) - Page 3 of 25


IPv6 Stateless Address Autoconfiguration



Alternative Format: Original Text Document

< Previous
Next >


RFC 2462        IPv6 Stateless Address Autoconfiguration   December 1998


   In the stateful autoconfiguration model, hosts obtain interface
   addresses and/or configuration information and parameters from a
   server.  Servers maintain a database that keeps track of which
   addresses have been assigned to which hosts. The stateful
   autoconfiguration protocol allows hosts to obtain addresses, other
   configuration information or both from a server.  Stateless and
   stateful autoconfiguration complement each other. For example, a host
   can use stateless autoconfiguration to configure its own addresses,
   but use stateful autoconfiguration to obtain other information.
   Stateful autoconfiguration for IPv6 is the subject of future work
   [DHCPv6].

   The stateless approach is used when a site is not particularly
   concerned with the exact addresses hosts use, so long as they are
   unique and properly routable. The stateful approach is used when a
   site requires tighter control over exact address assignments.  Both
   stateful and stateless address autoconfiguration may be used
   simultaneously.  The site administrator specifies which type of
   autoconfiguration to use through the setting of appropriate fields in
   Router Advertisement messages [DISCOVERY].

   IPv6 addresses are leased to an interface for a fixed (possibly
   infinite) length of time. Each address has an associated lifetime
   that indicates how long the address is bound to an interface. When a
   lifetime expires, the binding (and address) become invalid and the
   address may be reassigned to another interface elsewhere in the
   Internet. To handle the expiration of address bindings gracefully, an
   address goes through two distinct phases while assigned to an
   interface. Initially, an address is "preferred", meaning that its use
   in arbitrary communication is unrestricted. Later, an address becomes
   "deprecated" in anticipation that its current interface binding will
   become invalid. While in a deprecated state, the use of an address is
   discouraged, but not strictly forbidden.  New communication (e.g.,
   the opening of a new TCP connection) should use a preferred address
   when possible.  A deprecated address should be used only by
   applications that have been using it and would have difficulty
   switching to another address without a service disruption.

   To insure that all configured addresses are likely to be unique on a
   given link, nodes run a "duplicate address detection" algorithm on
   addresses before assigning them to an interface.  The Duplicate
   Address Detection algorithm is performed on all addresses,
   independent of whether they are obtained via stateless or stateful
   autoconfiguration. This document defines the Duplicate Address
   Detection algorithm.






Thomson & Narten            Standards Track


< Previous
Next >


Web Standards & Support:

Link to and support eLook.org Powered by LoadedWeb Web Hosting
Valid XHTML 1.0! Valid CSS! eLook.org FireFox Extensions