[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07 RFC 1971

INTERNET-DRAFT                                            June 5, 1995
<draft-ietf-addrconf-ipv6-auto-02.txt>



               IPv6 Stateless Address Autoconfiguration


Status of this Memo

   This document is a submission to the ADDRCONF Working Group of the
   Internet Engineering Task Force (IETF). Comments should be submitted
   to the addrconf@cisco.com mailing list.

   This document is an Internet Draft.  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. Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a "working
   draft" or "work in progress."

   To learn the current status of any Internet Draft.  please check the
   1id-abstracts.txt listing contained in the Internet Drafts Shadow
   Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com or
   munnari.oz.au.


Abstract


   In IPv6, there are two types of address autoconfiguration: stateless
   address autoconfiguration and stateful address configuration. In
   stateless address autoconfiguration, no state is maintained binding a
   particular host interface to a specific list of addresses. Rather, an
   address is formed algorithmically by concatenating the network prefix
   of the attached link to a host token that is unique per link.  Hosts
   use stateless address autoconfiguration to form a link-local unicast
   address and may use stateless address autoconfiguration to form
   global and site-local unicast addresses.  This document specifies how
   a host uses stateless address autoconfiguration to form a list of



Expires December 5, 1995                                        [Page 1]


INTERNET-DRAFT     Stateless Address Configuration            June 1995


   unicast addresses per interface. It also specifies how a host
   determines whether to use the stateless mechanism or the stateful
   mechanism.  Stateful address autoconfiguration is outside the scope
   of this document.












































Expires December 5, 1995                                        [Page 2]


INTERNET-DRAFT     Stateless Address Configuration            June 1995


1.  INTRODUCTION


   In IPv6, there are two types of address autoconfiguration: stateless
   address autoconfiguration and stateful address configuration. In
   stateless address autoconfiguration, no state is maintained binding a
   particular host interface to a specific list of addresses. Rather, an
   interface address is formed algorithmically by concatenating the net-
   work prefix of the attached link to a host token unique per link.  In
   stateful address configuration, state is maintained, typically by a
   server. For example, the IPv6 Dynamic Host Configuration Protocol is
   an example of stateful address autoconfiguration.

   Stateless autoconfiguration is designed to make address configuration
   very simple to use and implement, and is suitable for environments
   with simple topologies, e.g. routerless networks, and for environ-
   ments where system administrative control is not desired.  In con-
   trast, stateful address configuration is designed to support flexible
   address assignment and is suitable for more sophisticated topologies
   and for environments where system administrative control is desired.

   A host always uses stateless address autoconfiguration to form a
   link-local address per interface.  A host may use either stateless or
   stateful autoconfiguration to configure addresses of inter-link scope
   for an interface, i.e. global or site-local addresses.

   This document describes how a host forms unicast addresses per inter-
   face using stateless autoconfiguration.  It also specifies how a host
   determines whether to use the stateless mechanism or the stateful
   mechanism.  Stateful address autoconfiguration is outside the scope
   of this document.

















Expires December 5, 1995                                        [Page 3]


INTERNET-DRAFT     Stateless Address Configuration            June 1995


2.  OVERVIEW



   An IPv6 host may have multiple unicast addresses per interface[1].
   The addresses can have one of three scopes: a link-local scope, a
   site-local scope, or a global scope.  Addresses of all three address
   scopes can be autoconfigured. A host is able to autoconfigure a
   link-local address completely autonomously. In particular, a host can
   form a link-local address without a router present on the link. A
   host is able to autoconfigure an inter-link scope address only when a
   router is present on the link. The scope of the inter-link address
   formed depends on the prefix advertised on the link.

   On initialization of an interface, a host forms a link-local address
   by concatenating a well-known link-local prefix[1] to a token that is
   unique per link.  The definition of the tokens used are link-
   dependent.  For example, in the case of a host  attached to a link
   that uses IEEE 802 addresses, the token is an IEEE 802 address asso-
   ciated with the interface.

   A host forms or updates an inter-link scope address on hearing prefix
   advertisements advertised by a router. A global or site-local address
   is formed by concatenating a network prefix to a host token that is
   unique per link in the same way as described above.  The mechanism
   used to advertise network prefixes for the purposes of address confi-
   guration is the same as that used in Neighbor Discovery[2] for the
   purposes of prefix discovery.  Rather than specify two separate
   mechanisms to advertise the same prefix information, we use a single
   mechanism which requires hosts to perform both prefix discovery pro-
   cessing and address autoconfiguration processing on receiving a pre-
   fix advertisement. Note that, when prefixes are advertised, it is
   possible to indicate whether the prefixes are to be used for prefix
   discovery only, address autoconfiguration only or both.

   One of the goals of IPv6 address autoconfiguration is not only to be
   able to autoconfigure addresses on startup, but to be able to recon-
   figure addresses dynamically. Address reconfiguration ("renumbering")
   enables hosts to acquire new addresses and relinquish old addresses
   automatically. Old addresses may then be reused.  To enable hosts to
   renumber with minimal disruption of existing communications, prefixes
   are advertised with two lifetimes: a deprecation lifetime and an
   invalidation lifetime.  The deprecation lifetime indicates when an
   address formed from a prefix must be deprecated. A deprecated address
   may continue to be used as a source address in existing



Expires December 5, 1995                                        [Page 4]


INTERNET-DRAFT     Stateless Address Configuration            June 1995


   communications, but should not be used as a source address in new
   communications. The invalidation lifetime indicates when an address
   formed from a prefix is no longer valid and may be reused.  Invalid
   addresses cannot be used in any communications.  By specifying two
   separate lifetimes, a host can gradually phase out use of old
   addresses, while beginning to use new addresses for new communica-
   tions (if any).  The deprecation and invalidation lifetimes are con-
   figurable by a system administrator and so the transition from old to
   new addresses may be as quick (the deprecation and invalidation life-
   times are the same) or as slow as desired.

   One of the basic assumptions of stateless autoconfiguration is that
   the host token is at least unique per link.  However, in practice,
   host tokens are not always unique because of errors in assignment.
   Thus, it cannot be guaranteed that IPv6 addresses formed from a host
   token are indeed unique among all hosts on a link. Since duplicate
   IPv6 addresses are very difficult to track down and debug, we specify
   a procedure for detecting duplicate addresses that hosts should use
   on initialising an interface. Note that this procedure is not com-
   pletely reliable, and so duplicate addresses may still exist.  The
   procedure makes use of Neighbor Solicitations and Advertisements[2]
   in a special-purpose way. Briefly, a host uses a Neighbor Solicita-
   tion to solicit for itself.  If it discovers that another host has
   the address through receiving a Neighbor Advertisement, the valida-
   tion check fails and the host ceases operation on that interface.
   Note that the host that is already using the address (presumably leg-
   itimately) continues unharmed, although it may log a message to the
   effect that it has received a solicitation for its own address.

   This document specifies router and host behavior related to stateless
   address configuration and duplicate address detection in more detail
   in the sections that follow.
















Expires December 5, 1995                                        [Page 5]


INTERNET-DRAFT     Stateless Address Configuration            June 1995


3.  ROUTER BEHAVIOR


   The stateless address autoconfiguration mechanism relies on the pre-
   fix discovery mechanism specified in [2] for advertising network pre-
   fixes required for the formation of addresses with site-local or glo-
   bal scope. A prefix is advertised in a Prefix Information extension
   of a Router Advertisement. The Prefix Information extension includes
   the prefix and its length, flags indicating whether the information
   is to be used for prefix discovery or address configuration, and two
   lifetimes: the deprecation lifetime and the invalidation lifetime.
   The Router Advertisement itself includes flags indicating whether
   stateful address configuration should be used by hosts and whether
   other configuration information (besides an address) needs to be con-
   figured.

   Router Advertisement and Solicitation processing is specified com-
   pletely in [2] along with the message formats and configuration vari-
   ables. Additional configuration variables pertinent to stateless
   address configuration are specified below.



3.1.  Router Configuration Variables


   In addition to the configuration variables specified in [2], routers
   MUST also be configurable as follows.


   For each of the prefixes to be advertised in Prefix Information
   extensions per interface:


      Autonomous Flag

         If set, the prefix is being advertised for the purposes of
         stateless address configuration.

         Default: TRUE


      Deprecation Lifetime

         The value to be placed in the Deprecation Lifetime field of



Expires December 5, 1995                                        [Page 6]


INTERNET-DRAFT     Stateless Address Configuration            June 1995


         Prefix Information extensions in Router Advertisements sent
         from the interface in seconds.


      Invalidation Lifetime

         The value to be placed in the Invalidation Lifetime field of
         Prefix Information extensions in Router Advertisements sent
         from the interface in seconds. Must be no less than Deprecation
         Lifetime.


   For each advertising interface:


      Administered Flag

         If set, the host must autoconfigure addresses using stateful
         address autoconfiguration.

         Default: FALSE



      Other Flag

         If set, the host must autoconfigure other configuration infor-
         mation (besides the address) using stateful autoconfiguration.

         Default: FALSE


   NOTE: All routers advertising a given prefix on a link MUST set all
   of the configuration variables to the same value.














Expires December 5, 1995                                        [Page 7]


INTERNET-DRAFT     Stateless Address Configuration            June 1995


4.  HOST BEHAVIOR


   Conceptually, a host maintains a list of addresses per interface.
   Entries in the list are created as a result of forming addresses from
   prefixes advertised in Prefix Information extensions of Router Adver-
   tisements.  Each entry in the list has two associated timers, a
   deprecation timer and an invalidation timer, which have values set
   according to lifetimes learned from the router advertisement. In
   addition, the address list always includes the link-local address,
   which the host forms autonomously whenever an interface is initial-
   ised. The deprecation and invalidation lifetimes of a link-local
   address are set to infinity.

   This section specifies host address autoconfiguration behavior on
   interface initialisation and on receiving a Router Advertisement.
   This section also specifies a host protocol for attempting to verify
   that an address is not a duplicate.



4.1.  Host Configuration Variables


   A host MUST allow the following variable to be configured per inter-
   face:


   Perform_Auto_Config

      If set, the host MUST perform address autoconfiguration process-
      ing.

      Default: TRUE



4.2.  Router Advertisement Processing


   An "autoconfigurable" interface is one on which Router Advertisements
   are received and the Perform_Auto_Config flag is set.

   A host MUST perform the following address configuration processing
   when a solicited or unsolicited Router Advertisement is received over



Expires December 5, 1995                                        [Page 8]


INTERNET-DRAFT     Stateless Address Configuration            June 1995


   an autoconfigurable interface:

   For each valid Router Advertisement:


      If the Administered flag is set, the host MUST use stateful auto-
      configuration to acquire a list of site-local or global addresses
      per interface.

      If the Other flag is set, the host MUST use stateful autoconfi-
      guration to acquire other configuration information besides the
      address.


      For each Prefix-Information extension in the Router Advertisement
      that has the Autonomous flag set:



      -    If the prefix advertised matches the prefix of an autoconfig-
           ured address already in the list, then set the deprecation
           timer to that of the deprecation lifetime specified in the
           extension and the invalidation timer to that of the invalida-
           tion lifetime.  Note that this processing does not apply to a
           link-local address.

      -    If the prefix advertised does not match the prefix of an
           address already in the list, then form an address using this
           network prefix. Appendix A specifies how to form an address
           for hosts that have IEEE 802 tokens. The extension is ignored
           if the prefix is not valid, e.g. it is not the right length
           for forming an address with the given host token.

           Add this address to the list with the deprecation timer set
           to that of the deprecation lifetime  and the invalidation
           timer to that of the invalidation lifetime.

      Note that if the deprecation lifetime is zero, the address with
      that prefix is immediately deprecated. Similarly, if the invalida-
      tion lifetime is zero, the address with that prefix is immediately
      made invalid. (The invalidation lifetime is defined to be no less
      than the deprecation lifetime.)

      An address is valid until the deprecation timer expires. A valid
      address may be used as a source address in all outgoing



Expires December 5, 1995                                        [Page 9]


INTERNET-DRAFT     Stateless Address Configuration            June 1995


      communications and MUST be accepted as a destination address in
      all incoming communications.

      When the deprecation lifetime of an address expires, an address is
      said to be deprecated.  A deprecated address SHOULD NOT be used as
      a source address in new communications. However, a deprecated
      address SHOULD continue to be used as a source address if it is in
      use in existing communications.  The IP layer MUST continue to
      accept datagrams destined to a deprecated address. Upper layers
      MAY refuse to accept new communications requests to a deprecated
      address, however.

      An address remains deprecated until its invalidation timer expires
      at which point the address becomes invalid. An invalid address can
      no longer be used  as  a source address in outgoing communications
      and is not recognised as a valid destination address in incoming
      communications.

      Note that, when choosing a source address in outgoing communica-
      tons, a global valid address should be used in preference to a
      site-local valid address, which in turn should be used in prefer-
      ence to the link-local address. Similarly, a global deprecated
      address should also be used in preference to a site-local depre-
      cated addresses. Note that the link-local address is never depre-
      cated; it is always valid. One of the implications of these rules
      is that if there are no valid inter-link scope addresses, e.g. all
      global and site-local addresses are deprecated, then the host will
      default to using the link-local address as a source address in new
      communications.

      To limit storage space required for the address list, a host may
      choose not to store all valid and deprecated addresses. Deprecated
      addresses that are not in use by existing communications should be
      discarded in favor of valid addresses and deprecated addresses
      that are in use.

      If a host determines that there are no IPv6 routers on a link,
      either on startup or during normal processing, a host MUST attempt
      to use stateful autoconfiguration to acquire addresses or other
      configuration information if it is not already doing so. This is
      needed to support networks with no IPv6 routers. The host deter-
      mines that there are no routers on the link after startup if no
      Router Advertisements are heard in the time that it would take to
      send MAX_ROUTER_SOLICITATIONs and wait for a response[2]. During
      normal processing, it is determined that there are no routers when



Expires December 5, 1995                                       [Page 10]


INTERNET-DRAFT     Stateless Address Configuration            June 1995


      all router advertisements have timed out.  If a router comes up on
      the link and Router Advertisements begin to be received, a host
      MUST start to use Router Advertisements in the normal way, and, in
      particular, use advertisements to determine whether stateless or
      stateful address configuration should be in use. Note that if a
      host does not receive Router Advertisements because of some error,
      e.g. all routers are down or there is a network partition, hosts
      will attempt to change mode from stateless (assuming this was the
      advertised mode) to stateful and then back again when Router
      Advertisements start being heard. This means that if the stateful
      mode is available, it should be configured correctly to serve only
      the hosts that it should, since hosts may attempt to use it, even
      if it is not the intention that they do so.

      A host must behave reasonably when there is a change from the
      stateless mode to the stateful mode, and vice versa. This can hap-
      pen because routers advertise a new configuration mode due to a
      deliberate change by a system administrator, or because of a
      change in topology, e.g. an IPv6 router is connected to or removed
      from the link.  It is possible and quite likely that during the
      change-over, a host will have addresses autoconfigured using both
      mechanisms. If the addresses acquired using the two mechanisms are
      the same, then the new addresses should replace the old and the
      aging semantics associated with the new mode apply.  If the
      addresses acquired using the two mechanisms are different, then
      the old addresses should be aged according to the rules specified
      in the old configuration mode and the new addresses should follow
      the rules of the new mode.




4.3.  Host Initialisation


   A host forms a link-local address when an autoconfigurable interface
   is initialised.  Appendix A specifies how a host that is attached to
   a link that uses IEEE 802 addresses forms a link-local address.

   Note that an interface may be initialised after any of the following
   events:

   -    The interface is initialized at system startup time.

   -    The interface is reinitialized after a temporary interface



Expires December 5, 1995                                       [Page 11]


INTERNET-DRAFT     Stateless Address Configuration            June 1995


        failure or after being temporarily disabled by system manage-
        ment.

   -    The system changes from being a router to being a host, by hav-
        ing its IP forwarding capability turned off by system manage-
        ment.

   -    The host is re-attached to a link after being detached for some
        time.

   -    The interface has its Perform_Auto_Config flag changed from
        FALSE to TRUE.




4.4.  Detecting Duplicate IPv6 Addresses


   The procedure to detect duplicate addresses MUST be implemented in
   hosts and SHOULD be used.

   In stateless address configuration, it is only necessary to check
   that one of the autoconfigured addresses is unique since the same
   token is used to form all addresses.  It is recommended that the
   link-local address be the address checked since the host always forms
   this address.

   The procedure uses Neighbor Solicitation and Advertisement messages
   specified in [2] to validate an address and is specified below.

   Note that this mechanism is not completely reliable, and so it is
   possible that duplicate addresses will still exist. If a duplicate
   address is discovered, the host will need to be configured with a new
   token, or if this is not possible, the IPv6 addresses will need to be
   manually configured.




4.4.1.  Soliciting Host Behavior


   The host first delays a random amount of time between 0 and
   DUPL_ADDRESS_DELAY seconds before sending out a Neighbor Solicitation



Expires December 5, 1995                                       [Page 12]


INTERNET-DRAFT     Stateless Address Configuration            June 1995


   for the address. This serves to alleviate congestion when many hosts
   start up on the link at the same time, such as after a power failure,
   and helps to avoid race conditions when more than one host is trying
   to solicit for the same address at the same time. (It is recommended
   that hosts include some unique value in the seed used to initialise
   their pseudo-random number generators. Note that using only the host
   token as a unique value is not sufficient since the token cannot be
   relied upon to be unique. Although the randomization range is speci-
   fied in units of seconds, the actual randomly-chosen value should not
   be in units of whole seconds, but rather in units of the highest
   available timer resolution.)

   The node then sends a Neighbor Solicitation with a target address
   containing the address to be validated. The source is set to the
   unspecified address and the destination is set to the solicited-node
   multicast address.  The Source Link Layer Address extension SHOULD
   NOT be sent.

   NOTE: There SHOULD be some way to inhibit local delivery of the soli-
   citation since, in general, it will not be possible for a host to
   determine whether a solicitation is from itself or from another host
   with a duplicate address. If local delivery cannot be inhibited, then
   the host should ignore the first Neighbor Solicitation with an
   unspecified source address or wait for a period of
   DUPL_ADDR_IGNORE_TIMER seconds after sending a Neighbor Solicitation
   before beginning to process solicitations again.


   If after sending a solicitation, no advertisement is received from
   the target, the node SHOULD retransmit the solicitation every
   DUPL_ADDR_RETRANS_TIMER seconds until either an advertisement is
   received or the solicitation has been retransmitted
   MAX_DUPL_ADDR_RETRANS times. If an advertisement is received with a
   target address the same as the address being validated, it must cease
   operation on that interface and indicate an appropriate error.  If no
   such advertisement is received in response to the Neighbor Solicita-
   tions sent, the address is considered to be valid.



4.4.2.  Solicited Node Behavior


   When a host is in the process of validating an address, it MUST NOT
   send any advertisement in response to a solicitation for that



Expires December 5, 1995                                       [Page 13]


INTERNET-DRAFT     Stateless Address Configuration            June 1995


   address. Rather, all solicitations for the address are ignored,
   except when the solicitation is from the unspecified address i.e.
   the Neighbor Solicitation message has a target address which is the
   same as the address to be validated, and a source address that is the
   unspecified address. (Note that any solicitation that is likely to be
   a loopback solicitation should be ignored too as mentioned in the
   above section.) If a solicitation is received from the unspecified
   address, the host must cease operation on that interface and indicate
   an appropriate error.

   Once a host has validated its address, it responds to a Neighbor Sol-
   icitation with a Neighbor Advertisement as specified in [2]. However,
   the processing of the solicitation is somewhat different from that in
   [2] when a solicitation is received from the unspecified address.  In
   this case, the host MUST ignore any Link Layer Address Extension in
   the solicitation and MUST NOT perform any link-layer address resolu-
   tion processing before sending a Neighbor Advertisement.  The host
   sends the Neighbor Advertisement to the all-nodes multicast address
   of the soliciting host. The target address is copied from the solici-
   tation message. The source address MUST be set to the address of the
   target field.  The Target Link Layer Address extension need not be
   filled in.





4.4.3.  Constants


   DUPL_ADDR_DELAY                     4 seconds (XX)
   DUPL_ADDR_IGNORE_TIMER              0.1 seconds
   DUPL_ADDR_RETRANS_TIMER             4 seconds  (XX)
   MAX_DUPL_ADDR_RETRANS               1 transmission (XX)





5.  SECURITY CONSIDERATIONS


   To be completed.





Expires December 5, 1995                                       [Page 14]


INTERNET-DRAFT     Stateless Address Configuration            June 1995


6.  APPENDIX A: FORMING AN IPv6 ADDRESS FOR IEEE 802 LINKS


   The token for an interface on an IEEE 802 link or any link that uses
   IEEE 802 addressing, such as FDDI, is the 48-bit IEEE 802 address in
   canonical format, i.e. the Individual/Group  bit is the low-order bit
   of the furst byte.

   A host forms an IPv6 address per link by concatenating an 80-bit pre-
   fix with the IEEE 802 address as follows:



      |              80 bits                  |      48 bits           |
      +---------------------------------------+------------------------+
      |              prefix                   |    IEEE 802 address    |
      +----------------------------------------------------------------+



   In the case of a link-local prefix, the prefix is well-defined[1].

   The prefixes of other types of addresses need to be configured.

























Expires December 5, 1995                                       [Page 15]


INTERNET-DRAFT     Stateless Address Configuration            June 1995


7.  REFERENCES



   [1]  R. Hinden and S. Deering, "Internet Protocol Version (IPv6)
        Addressing Architecture", Internet Draft, May 1995, draft-ietf-
        ipngwg-addr-arch-02.txt

   [2]  T. Narten and E. Nordmark, "IPv6 Neighbor Discovery", Internet
        Draft, June 1995, <draft-ietf-ipngwg-discovery-00.txt>


Acknowledgements


The author would like to thank the members of both the IPNG and ADDRCONF
working groups for their input. In particular, thanks to Jim Bound,
Steve Deering, Erik Nordmark and Bill Simpson.


Author's Addresses


   Susan Thomson
   Bellcore
   445 South Street
   Morristown, NJ 07960
   U.S.A.

   Phone: +1 201-829-4514
   Email: set@thumper.bellcore.com

















Expires December 5, 1995                                       [Page 16]


INTERNET-DRAFT     Stateless Address Configuration            June 1995


















































Expires December 5, 1995                                       [Page 17]


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