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

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

ADDRCONF Working Group                        Susan Thomson (Bellcore)
INTERNET-DRAFT                                            July 7, 1995
<draft-ietf-addrconf-ipv6-auto-03.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

   This document specifies how a node configures a link-local address
   per interface, and how a host configures a list of global or site-
   local addresses per interface, without any manual configuration.
   Stateless address autoconfiguration is only one mechanism available
   to hosts; stateful address configuration is also available.  While
   stateful address configuration is outside the scope of this document,
   it is specified how hosts determine which configuration method must
   be used.  The document also specifies a protocol for detecting
   whether an address is a duplicate when it is initially configured.





Expires January 7, 1995                                         [Page 1]


INTERNET-DRAFT     Stateless Address Configuration            July 1995


1.  INTRODUCTION


   In IPv6, a host has two mechanisms available to form a global or
   site-local address that require no manual configuration: the state-
   less method and the stateful method.  In the stateless method, no
   external state is maintained for the purpose of indicating to a host
   the list of addresses to use for an interface. Rather, a host forms a
   list of  addresses algorithmically by concatenating each of the net-
   work prefixes of the attached link to an interface token unique per
   link.  The interface token is defined to be link-dependent and may be
   the hardware address, for example.  In contrast, state is maintained
   in the stateful address configuration, typically in 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, e.g. plug-
   and-play environments.  In contrast, 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, e.g.  corporate networks.

   Any node can use stateless address autoconfiguration to form a link-
   local address per interface.  A host can use either stateless or
   stateful autoconfiguration (or both) to configure global or site-
   local addresses for an interface. The choice of mechanism for confi-
   guring global or site-local addresses is itself configurable, and
   requires no manual configuration per host.

   One of the basic assumptions of stateless autoconfiguration is that
   the token used to form addresses per interface is at least unique per
   link. However, whatever the type of tokens used, interface tokens are
   not guaranteed to always be unique in practice because of errors in
   assignment. Thus, it is possible that IPv6 addresses formed using
   stateless autoconfiguration are not unique among all nodes on a link.
   Since duplicate IPv6 addresses are very difficult to track down when
   they occur, this document also specifies a procedure for detecting
   duplicate addresses.  Note that the algorithm does not only apply to
   addresses autoconfigured using the stateless mode. It should be used
   to verify the uniqueness of any address, for example, addresses con-
   figured using the stateful mode or manually configured addresses.




Expires January 7, 1995                                         [Page 2]


INTERNET-DRAFT     Stateless Address Configuration            July 1995


   This document describes how a node configures a link-local address
   per interface using stateless address autoconfiguration, and how a
   host configures global or site-local unicast addresses per interface
   using stateless address autoconfiguration.  Stateful address autocon-
   figuration is outside the scope of this document.  However, the docu-
   ment does specify how a host determines whether to use the stateless
   mechanism or the stateful mechanism for configuring global or site-
   local addresses.

   The document also describes the algorithm used by a node to detect if
   an address is a duplicate when initially configured.





































Expires January 7, 1995                                         [Page 3]


INTERNET-DRAFT     Stateless Address Configuration            July 1995


2.  TERMINOLOGY



   node        - a device that implements IPv6.

   router      - a node that forwards IPv6 packets not explicitly
                 addressed to itself.

   host        - any node that is not a router.

   upper layer - a protocol layer immediately above IPv6.  Examples are
                 transport protocols such as TCP and UDP, control
                 protocols such as ICMP, routing protocols such as OSPF,
                 and internet or lower-layer protocols being "tunneled"
                 over (i.e., encapsulated in) IPv6 such as IPX,
                 AppleTalk, or IPv6 itself.

   link        - a communication facility or medium over which nodes can
                 communicate at the link layer, i.e., the layer
                 immediately below IPv6.  Examples are Ethernets (simple
                 or bridged); PPP links; X.25, Frame Relay, or ATM
                 networks; and internet (or higher) layer "tunnels",
                 such as tunnels over IPv4 or IPv6 itself.

   neighbors   - nodes attached to the same link.

   interface   - a node's attachment to a link.

   packet      - an IPv6 header plus payload.

   link MTU    - the maximum transmission unit, i.e., maximum packet
                 size in octets, that can be conveyed in one piece over
                 a link.

   target      - a node about which address resolution information is
                 sought, or a node which is the new first-hop when being
                 redirected.

   address     - an IPv6-layer identifier for an interface or a set of
                 interfaces.

   unicast address
               - an identifier for a single interface. A packet sent
                 to a unicast address is delivered to the interface



Expires January 7, 1995                                         [Page 4]


INTERNET-DRAFT     Stateless Address Configuration            July 1995


                 identified by that address.

   anycast address
               - an identifier for a set of interfaces (typically
                 belonging to different nodes).  A packet sent to an
                 anycast address is delivered to one of the interfaces
                 identified by that address (the "nearest" one,
                 according to the routing protocols' measure of
                 distance).

   multicast address
               - an identifier for a set of interfaces (typically
                 belonging to different nodes). A packet sent to a
                 multicast address is delivered to all interfaces
                 identified by that address.

   link-layer address
               - a link-layer identifier for an interface.  Examples are
                 IEEE 802 addresses for Ethernet links, E.164 addresses
                 for ISDN links.

   link-local address
               - an address with a scope that is limited to
                 the locally attached link.

   site-local address
               - an address with a scope that is limited to the
                 local site.

   global address
               - an address with unlimited scope.


   communication
               - any packet exchange between nodes that requires
                 or recommends that the address of each node used in the
                 exchange remain the same for the duration of the
                 packet exchange. Examples are a TCP connection or a
                 UDP request-response.

   deprecation lifetime
              - indicates the time at which an address should no
                longer be used as a source address in new
                communications. The deprecation lifetime must be
                less than or equal to the invalidation lifetime



Expires January 7, 1995                                         [Page 5]


INTERNET-DRAFT     Stateless Address Configuration            July 1995


                of the address.

   invalidation lifetime
               - indicates the time at which an address no longer
                 identifies an interface or set of interfaces.
                 The invalidation lifetime must be greater than
                 or equal to the deprecation lifetime of the address.

   valid address
               - an address whose deprecation lifetime has not yet
                 expired.

   deprecated address
               - an address whose deprecation lifetime has expired,
                 but whose invalidation lifetime has not.

   invalid address
              - an address whose invalidation lifetime has
                expired.

   interface token
              - a link-dependent identifier for an interface that is
                (at least) unique per link. An example is an IEEE 802
                address.




2.1.  Requirements



   Throughout this document, the words that are used to define the sig-
   nificance of the particular requirements are capitalized.  These
   words are:

   MUST
        This word or the adjective "REQUIRED" means that the item is an
        absolute requirement of this specification.

   MUST NOT
        This phrase means the item is an absolute prohibition of this
        specification.

   SHOULD



Expires January 7, 1995                                         [Page 6]


INTERNET-DRAFT     Stateless Address Configuration            July 1995


        This word or the adjective "RECOMMENDED" means that there may
        exist valid reasons in particular circumstances to ignore this
        item, but the full impliciations should be understood and the
        case carefully weighed before choosing a different course.

   SHOULD NOT
        This phrase means that there may exist valid reasons in particu-
        lar circumstances when the listed behavior is acceptable or even
        useful, but the full implications should be understood and the
        case carefully weighted before implementing any behavior
        described with this label.

   MAY
        This word or the adjective "OPTIONAL" means that this item is
        truly optional.  One vendor may choose to include the item
        because a particular marketplace requires it or because it
        enhances the product, for example, another vendor may omit the
        same item.






























Expires January 7, 1995                                         [Page 7]


INTERNET-DRAFT     Stateless Address Configuration            July 1995


3.  CONCEPTUAL MODEL OF HOST BEHAVIOR


   Conceptually, a host maintains three data structures: a list of
   addresses per interface and two flags.  One flag, called the "address
   mode" flag, indicates whether the stateful protocol is to be used for
   address configuration (possibly in addition to the stateless proto-
   col). The other flag, called the "other configuration mode" flag,
   indicates whether the stateful protocol is to be used for configura-
   tion of other information besides addresses.

   The address list always includes at least one address, the host's
   link-local address, which is an address that can only be used in com-
   munications between nodes attached to the link. In addition, the
   address list includes any global or site-local addresses that have
   been manually or automatically configured.

   Note that stateless address autoconfiguration applies only to the
   formation of unicast addresses. A node may, however, have anycast and
   multicast addresses associated with an interface. In particular, a
   host must join the all-nodes multicast address on any multicast
   interface, and the solicited-node multicast address corresponding to
   each unicast address on any multicast interface.



3.1.  Address Configuration





3.1.1.  Link-Local Address


   On initialization of an interface, a host must form a link-local
   address by concatenating a well-known link-local prefix[1] to an
   interface 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 the
   48-bit IEEE 802 link-layer address of the interface.  Tokens for a
   specific link are defined in link-specific IPv6 documents and are
   outside the scope of this document.

   Note that a host is able to autoconfigure a link-local address



Expires January 7, 1995                                         [Page 8]


INTERNET-DRAFT     Stateless Address Configuration            July 1995


   completely autonomously. In particular, a host can form a link-local
   address without a router present on the link.




3.1.2.  Global/Site-Local Address


   A host forms a new global/site-local address whenever a new prefix is
   advertised by a router and stateless address configuration is
   enabled.  The address is formed by concatenating the network prefix
   to the interface token that is unique per link in the same way as a
   link-local address described above.

   The mechanism used to advertise network prefixes for the purposes of
   address configuration is the same as that used in Neighbor Discovery
   for the purposes of prefix discovery.  A router advertises prefix
   information periodically and a host uses this information to config-
   ure and reconfigure addresses.



3.2.  Address Reconfiguration


   One of the goals of IPv6 address autoconfiguration is not only to be
   able to autoconfigure a list of addresses on initialization of an
   interface, but to be able to change the address list dynamically.
   Note that the link-local address never changes (except possibly on
   interface re-initialization). Host addresses may need to change for a
   number of reasons. For example, if the address assignment scheme is
   provider-based, hosts may need to change addresses when hosts change
   provider. Hosts may also need to change addresses when they are
   disconnected from one link and connected to another. Reconfiguration
   must not only allow a host to acquire a new address, but must also
   allow hosts to time-out an old address.

   Current networking protocols have not been designed to maintain
   existing communications during an address change. For example, a TCP
   connection will no longer work if one of the hosts changes its
   address in the middle of a connection. Even in a UDP exchange, a host
   is expected to be able to identify itself using the same address for
   the length of the exchange.




Expires January 7, 1995                                         [Page 9]


INTERNET-DRAFT     Stateless Address Configuration            July 1995


   To minimise disruption caused by an address change, an address is
   configured with two lifetimes : a deprecation lifetime and an invali-
   dation lifetime. The deprecation lifetime must be less than or equal
   to the invalidation lifetime. Before expiry of the deprecation life-
   time, the address is valid and may be used as the source and destina-
   tion in any communications. At and after expiry of the deprecation
   lifetime, but before the invalidation lifetime has expired, the
   address is considered to be deprecated. A deprecated address can
   still be used as the source and destination in packets legitimately,
   but the deprecated address should not be used as a source address in
   new communications if other valid addresses exist and these addresses
   have sufficient scope.  If no valid addresses of sufficient scope
   exist, then the deprecated address should still be used.  (Note that
   there will always be at least one valid address in the address list,
   the link-local address (see below), but this address is only useful
   for communications on the local link, and thus cannot be used in
   place of a deprecated address for non-local link communications).

   An address becomes invalid when the invalidation lifetime expires.
   Such an address must not be used as a source address in outgoing com-
   munications or accepted as a destination address in incoming communi-
   cations. An invalid address is removed from the address list of the
   interface.

   Note that the deprecation lifetimes and invalidation lifetimes of the
   link-local address are set to infinity. Thus, the link-local address
   is  never deprecated.

   The intention of the two lifetimes per address is to allow system
   administrators to specify a graceful transition period during
   renumbering. The purpose of the deprecation time is to indicate to
   the host to start using another (presumably longer lasting) address
   in new communications to minimise the risk of breaking communications
   when the old one times out. A system administrator should set the
   deprecation period long enough so that most, if not all, communica-
   tions have switched over to using the new address by the time the old
   one becomes invalid. The length of the deprecation period will be
   environment-dependent as it depends on the expected length of commun-
   ications.

   The fact that addresses have a deprecation lifetime does not need to
   affect the implementation of applications, i.e.  an application is
   not expected to react when an address it is using becomes deprecated.
   The purpose of the deprecation lifetime is to help applications or
   networking software to select a sufficiently long-lasting source



Expires January 7, 1995                                        [Page 10]


INTERNET-DRAFT     Stateless Address Configuration            July 1995


   address at the beginning of a new communication. The IP layer is
   expected to provide a means for upper layers or applications to
   select the most appropriate source address given a particular desti-
   nation.  An application may choose to select the source address
   itself before starting a new communication or may leave the address
   unspecified, in which case the upper networking layers will use the
   mechanism provided by the IP layer to choose a suitable address on
   the application's behalf.








































Expires January 7, 1995                                        [Page 11]


INTERNET-DRAFT     Stateless Address Configuration            July 1995


4.  ROUTER SPECIFICATION


   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 option of a Router
   Advertisement. Prefix Information includes

   1.   the prefix itself

   2.   the prefix length

   3.   a flag indicating whether the prefix is to be used for prefix
        discovery[2].

   4.   a flag indicating whether the prefix is to be used for stateless
        address autoconfiguration

   5.   the deprecation lifetime of the prefix in seconds for the pur-
        pose of address deprecation

   6    the invalidation lifetime of the prefix for the purpose of
        address invalidation. This field is also used by prefix
        discovery[2].


   Router Advertisement processing is specified completely in [2] along
   with the message formats and configuration variables.

















Expires January 7, 1995                                        [Page 12]


INTERNET-DRAFT     Stateless Address Configuration            July 1995


5.  HOST SPECIFICATION


   This section specifies host address autoconfiguration behavior on
   receiving a Router Advertisement.




5.1.  Host Configuration Variables


   A host SHOULD allow the following variable to be configured per mul-
   ticast interface:


   Perform_Addr_Config

      If set, the host MUST use either stateless or stateful mechanisms
      to configure global or site-local addresses and to acquire other
      configuration information as specified in this document.

      Default: TRUE


   An interface that has the Perform_Addr_Config flag set is called an
   "autoconfigurable interface".



5.2.  Message Validation


   A host MUST silently discard any Router Advertisement that does not
   specify the validity checks as specified in [2]. An advertisement
   that passes these validity checks is called a valid advertisement.



5.3.  Router Advertisement Processing


   To receive a Router Advertisement, a host joins the all-nodes multi-
   cast address over all multicast-capable interfaces.




Expires January 7, 1995                                        [Page 13]


INTERNET-DRAFT     Stateless Address Configuration            July 1995


   A host performs the following address configuration processing when a
   valid solicited or unsolicited Router Advertisement is received over
   an autoconfigurable interface:

   For each valid Router Advertisement:


      The host stores the current value of the Address Mode and then
      sets the Address Mode to the value of the Managed flag (M bit).
      If the new value is set, the host MUST use stateful address confi-
      guration to configure and maintain a list of site-local or global
      addresses per interface.

      Note that this does not mean that the stateful protocol is neces-
      sarily invoked each time a Router Advertisement arrives with the M
      bit set.  The host uses the flag only to indicate whether the
      stateful protocol is to be used to configure addresses. The state-
      ful protocol is enabled as soon as the Address Mode changes from
      FALSE to TRUE. The protocol is disabled as soon as the flag
      changes from TRUE to FALSE.  The actual times at which the proto-
      col is invoked, for example, to request a list of addresses or
      renew a list of addresses, are specified by the protocol itself.

      The host stores the current value of the Other Configuration flag
      and then sets the Other Configuration Mode flag to that in the
      Router Advertisement (O bit).  If the new value is set, the host
      MUST use stateful autoconfiguration to acquire other configuration
      information besides the address.

      The above disclaimer applies here as well. The O bit indicates
      whether the host must use the stateful mode to acquire other con-
      figuration information. The stateful protocol is enabled for this
      purpose as soon as the Other Configuration Mode changes from FALSE
      to TRUE. The protocol is disabled as soon as the mode changes from
      TRUE to FALSE.  The mode does not indicate the timing of frequency
      of acquiring that information. This is defined by the stateful
      protocol itself.


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



      -    If the prefix advertised matches the prefix of an



Expires January 7, 1995                                        [Page 14]


INTERNET-DRAFT     Stateless Address Configuration            July 1995


           autoconfigured address already in the list, then set the
           deprecation timer to that of the deprecation lifetime speci-
           fied in the extension and the invalidation timer to that of
           the invalidation lifetime.

           Note that this processing MUST NOT be applied to the link-
           local address. That is, if the well-known link-local prefix
           is advertised for some reason (probably a configuration
           error), then the prefix should be ignored and a system
           management error logged.


      -    If the prefix advertised does not match the prefix of an
           address already in the list, then form an address using this
           network prefix and the interface token. Definitions of the
           interface token to be used on a specific link are documented
           elsewhere.

           If the prefix advertised is too short or too long to form a
           128-bit address, given the interface token, the prefix is
           ignored and an error is logged.


           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: The address list should be variable-length. Hosts
           should be able to store the link-local address as well as all
           addresses configured using both the stateless and stateful
           modes. If the implementation cannot store all addresses, the
           host should log a system management error.


      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.) If the deprecation lifetime is
      infinity, the address is never deprecated. Similarly, if the
      invalidation lifetime is infinity, the address is never invali-
      dated. The value of infinity is defined in [2].

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



Expires January 7, 1995                                        [Page 15]


INTERNET-DRAFT     Stateless Address Configuration            July 1995


      communications and is accepted as a destination address in all
      incoming communications.

      When the deprecation lifetime of an address expires, the address
      SHOULD continue to be used as a source address if it is in use in
      existing communications, but SHOULD NOT be used in new communica-
      tions if a valid address is available and it has sufficient scope.
      The IP layer MUST continue to accept datagrams destined to a
      deprecated address since a deprecated address is still defined to
      identify the interface.

      An address remains deprecated until its invalidation timer expires
      at which point the address becomes invalid and is removed from the
      address list. 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 since the
      address is defined to no longer identify the interface.

      On initialisation of an interface, if a host determines that there
      are no IPv6 routers on a link, a host MUST attempt to use stateful
      autoconfiguration to acquire addresses and other configuration
      information.  This is needed to support networks with no IPv6
      routers.  The host determines 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]. 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 it is possible for hosts to get address information
      using both stateless and stateful protocols since both may be
      enabled at the same time. Even if only stateless address autocon-
      figuration mode is enabled, it is still possible for hosts to get
      information from multiple sources since multiple routers may be
      advertising prefix information. The rules for handling this is as
      follows: hosts accept the union of all information received using
      the stateless and stateful protocols. If different sources config-
      ure the same address, then the address is updated with the most
      recently advertised lifetime.

      It is also possible for hosts to contain address information from
      different sources, when changing from one mechanism to the other,
      i.e.  when changing from stateless mode to stateful mode, and vice



Expires January 7, 1995                                        [Page 16]


INTERNET-DRAFT     Stateless Address Configuration            July 1995


      versa. In this case, the rules are no different from above. If the
      newly enabled mode is configured to hand out different addresses
      than the mode just disabled, then the host contains the union of
      addresses from both sources until the addresses configured using
      the old protocol timeout.  If both the old and new modes are con-
      figured to hand out the same address, then the address is updated
      with the most recently advertised lifetime. NOTE: The above
      assumes that the stateless and stateful modes have the same life-
      time semantics.







































Expires January 7, 1995                                        [Page 17]


INTERNET-DRAFT     Stateless Address Configuration            July 1995


6.  NODE SPECIFICATION


   This section specifies the rules for forming a link-local address. It
   also specifies the protocol to be used for duplicate address detec-
   tion.



6.1.  Forming a Link-Local Address


   A node MUST have a link-local address.  A node forms a link-local
   address whenever an interface is initialised.  The method for forming
   a link-local address is link-dependent and is outside the scope of
   this document.

   An interface may be initialised or become autoconfigurable after any
   of the following events:

   -    The interface is initialized at system startup time.

   -    The interface is reinitialized after a temporary interface
        failure or after being temporarily disabled by system manage-
        ment.

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


   The link-local address is highly likely to need to be one of the
   first events in the interface initialisation process. Clearly, it
   must be formed before any duplicate detection processing is performed
   for this address (Section 6.2).  In hosts, a link-local address is
   also required before a  sends out a Router Solicitation, assuming the
   node chooses to do this[2]. This is because a solicitation is only
   sent if an advertisement has not yet been heard (and hence no non-
   link local address can be formed), and the unspecified address cannot
   be used as a source address in a Router Solicitation.

6.2.  Detecting Duplicate Addresses


   The procedure to detect a duplicate address MUST be enabled by
   default in nodes and SHOULD be used.



Expires January 7, 1995                                        [Page 18]


INTERNET-DRAFT     Stateless Address Configuration            July 1995


   In principle, the duplicate address detection procedure is applied to
   each new address configured for an interface, whether it be manually
   configured or configured automatically using either the stateless or
   stateful mode. However, if the addresses belonging to an interface
   are formed using the same interface token (as is the case in state-
   less autoconfiguration and may be the case in other forms of confi-
   guration), then it is only necessary to check that one of the
   addresses is unique on the link.  In the stateless mechanism, it is
   recommended that the link-local address be the address checked for
   two reasons. First, it makes the implementation simpler, since the
   link-local address is guaranteed to always exist in all nodes,
   whereas global and site-local addresses are not. Second, in hosts,
   there will be less delay in performing duplicate address detection.
   Address validation can be done as soon as a link-local address is
   formed (this can be done immediately on initialisation of an inter-
   face), whereas checking a global or site-local address involves wait-
   ing until a host hears a Router Advertisement containing address pre-
   fixes, and there is the possibility that no advertisement will be
   heard at all.


   The procedure for duplicate address detection uses Neighbor Solicita-
   tion and Advertisement messages specified in [2] to validate an
   address as specified below.  Note that before carrying out this pro-
   cedure, a node joins the all-nodes multicast address.  Also, this
   mechanism is not completely reliable, and so it is possible that
   duplicate addresses will still exist. If a duplicate address is
   discovered after carrying out this procedure, the node will need to
   be configured with a new token, or if this is not possible, the IPv6
   addresses will need to be manually configured.



6.2.1.  Soliciting Node Behavior



   An address is checked for uniqueness only once, when the address is
   initially configured.

   Once the address is configured, the node sends a Neighbor Solicita-
   tion 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 (as it will be ignored by the



Expires January 7, 1995                                        [Page 19]


INTERNET-DRAFT     Stateless Address Configuration            July 1995


   destination node[2]).  Loopback of the Neighbor Solicitation MUST NOT
   be disabled.

   NOTE: If the Neighbor Solicitation is the first message to be sent
   from an interface on interface initialisation, the node should delay
   a random amount of time between 0 and MAX_INITIALIZATION_DELAY
   seconds before sending the solicitation.  This serves to alleviate
   congestion when many nodes 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 node is trying to solicit for the same address at
   the same time. (It is recommended that nodes include some unique
   value in the seed used to initialise their pseudo-random number gen-
   erators. Note that using only the node token as a unique value is not
   sufficient to avoid race conditions since the token cannot be relied
   upon to be unique. Although the randomization range is specified 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.)


   If after sending a solicitation, no Neighbor Advertisement is
   received from the target, the node SHOULD retransmit the solicitation
   at most every DUPL_ADDR_RETRANS_TIMER seconds until either an adver-
   tisement 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 in the time it
   takes to send and wait for MAX_DUPL_ADDR_RETRANS solicitations, it
   must disable that interface and log a system management error.  If no
   such advertisement is received within the time specified, the address
   is considered to be valid.




6.2.2.  Solicited Node Behavior


   A node is in the process of validating an address when a Neighbor
   Solicitation has been sent for the address and no Neighbor Advertise-
   ment advertising that address has been received in the time it takes
   to send out MAX_DUPL_ADDR_RETRANS solicitations and wait for an
   advertisement (DUPL_ADDR_IGNORE_TIMER seconds).

   A node must follow special rules when it receives a Neighbor Solici-
   tation for an address that it is in the process of validating. This



Expires January 7, 1995                                        [Page 20]


INTERNET-DRAFT     Stateless Address Configuration            July 1995


   is done to help avoid the race condition where more than one node is
   attempting to validate the address at the same time, i.e. each node
   sends out a Neighbor Solicitation and waits to hear a Neighbor Adver-
   tisement for the address, but no node actually sends an advertisement
   since the address has not yet been validated.

   The special rules are as follows: When a node is in the process of
   validating an address and receives a Neighbor Solicitation for that
   address, it MUST NOT send any advertisement in response to a solici-
   tation for that address.  Rather, the node silently discards the sol-
   icitation unless the source address is the unspecified address.  In
   the latter case, the first such solicitation received is noted, but
   otherwise silently discarded (see NOTE below). Any subsequent such
   solicitations cause the node to disable the interface and log a sys-
   tem management error.

   NOTE: The above behavior is required because nodes send out Neighbor
   Solicitations for their own address  with loopback enabled. Thus, a
   node will always receive at least one solicitation for its own
   address.  However, there is no way for the node to determine, in gen-
   eral, whether the solicitation comes from itself or another node
   since the source of the packet is the unspecified address. Hence, the
   above rules specify that a duplicate address is detected only if the
   node receives more than one solicitation for the address.

   Once a node has validated its address, it responds to a Neighbor Sol-
   icitation with a Neighbor Advertisement as specified in [2].




6.2.3.  Constants


   MAX_INITIALIZATION_DELAY            3 seconds
   DUPL_ADDR_RETRANS_TIMER             3 seconds
   MAX_DUPL_ADDR_RETRANS               1 transmission











Expires January 7, 1995                                        [Page 21]


INTERNET-DRAFT     Stateless Address Configuration            July 1995


7.  SECURITY CONSIDERATIONS


   To be completed.












































Expires January 7, 1995                                        [Page 22]


INTERNET-DRAFT     Stateless Address Configuration            July 1995


8.  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, E. Nordmark and W. A. Simpson, "IPv6 Neighbor
        Discovery", Internet Draft, July 1995, <draft-ietf-ipngwg-
        discovery-01.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 January 7, 1995                                        [Page 23]


INTERNET-DRAFT     Stateless Address Configuration            July 1995


















































Expires January 7, 1995                                        [Page 24]


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