ADDRCONF Working Group                        Susan Thomson (Bellcore)

<draft-ietf-addrconf-ipv6-auto-03.txt> Thomson,  Bellcore
INTERNET-DRAFT                                      Thomas Narten, IBM
<draft-ietf-addrconf-ipv6-auto-04.txt>                 October 4, 1995

                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 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,, or

   Distribution of this memo is unlimited.

   This Internet Draft expires April 4, 1996.


   This document specifies how a node configures a link-local address
   per interface, and how hosts autoconfigure addresses for their
   interfaces in IP version 6. In particular, the document describes the
   steps a host configures a list of global or site-
   local addresses per interface, without any manual configuration.
   Stateless takes in determining whether address autoconfiguration is only one mechanism available
   should be used, and if so, whether to hosts; use the stateful address configuration is mechanism, the
   stateless mechanism or both. This document also available.  While
   stateful specifies stateless
   address configuration is outside autoconfiguration, and how nodes verify the scope uniqueness of this document, an
   address before assigning it to an interface.  Stateful address
   autoconfiguration is specified elsewhere.


   Status of this Memo.......................................    1

   1.  INTRODUCTION..........................................    3

   2.  TERMINOLOGY...........................................    4
      2.1.  Requirements.....................................    7

   3.  DESIGN GOALS..........................................    8

   4.  PROTOCOL OVERVIEW.....................................    9
      4.1.  Site Renumbering.................................   10

   5.  PROTOCOL SPECIFICATION................................   11
      5.1.  Host Configuration Variables.....................   11
      5.2.  Autoconfiguration-Related Variables..............   12
      5.3.  Creation of Link-Local Addresses.................   12
      5.4.  Verifying The Uniqueness Of An Address...........   13
         5.4.1.  Message Validation..........................   14
         5.4.2.  Sending Neighbor Solicitation Messages......   14
         5.4.3.  Receiving Neighbor Solicitation and Advertisement Messages   15
      5.5.  Creation of Global- and Site-Local Addresses.....   16
         5.5.1.  Sending Router Solicitations................   16
         5.5.2.  Absence of Router Advertisements............   16
         5.5.3.  Router Advertisement Processing.............   16
         5.5.4.  Address Lifetime Expiry.....................   18
      5.6.  Configuration Consistency........................   18

   6.  OPEN ISSUES/TODO......................................   19

   7.  SECURITY CONSIDERATIONS...............................   20

   8.  REFERENCES............................................   20

   AUTHORS' ADDRESSES........................................   20


This document specifies how hosts determine which configuration method must
   be used. autoconfigure their interfaces in IP
version 6. The autoconfiguration process includes determining what
information should be autoconfigured (addresses, other information, or
both), and in the case of addresses, whether they should be obtained
through the stateless mechanism, the stateless mechanism, or both.  This
document also specifies a protocol for detecting
   whether an stateless address autoconfiguration.  Stateful
address autoconfiguration is specified elsewhere.

IPv6 defines both a duplicate when it is initially configured.


   In IPv6, a host has two mechanisms available to form a global or
   site-local stateful and stateless address that require autoconfiguration
mechanism. Stateless autoconfiguration requires no manual configuration: the state-
   less method configuration
of hosts, minimal (if any) configuration of routers, and the stateful method.  In the stateless method, no
   external state is maintained for the purpose of indicating to additional
servers.  The stateless mechanism allows a host
   the list of addresses to use for an interface. Rather, a host forms generate its own
addresses using a
   list combination of  addresses algorithmically locally available information and
information advertised by concatenating each of the net-
   work routers. Routers advertise prefixes of that
identify the attached link to subnet(s) associated with a link, while hosts generate an
"interface token" that uniquely identifies an interface token unique per
   link.  The interface token on a subnet. An
address is defined to be link-dependent and may be formed by combining the hardware address, two. In the absence of routers, a
host can only generate link-local addresses. However, link-local
addresses are sufficient for example. allowing communication among nodes attached
to the same link.

In contrast, state is maintained
   in the stateful address configuration, typically in autoconfiguration model, hosts obtain interface
addresses from a server. For
   example, the IPv6 Dynamic Host Configuration Protocol is an example  Servers maintain a database that keeps track
of stateful address autoconfiguration.

   Stateless autoconfiguration is designed to make address configuration
   very simple which addresses have been assigned 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. which hosts. In contrast, addition to
addresses, stateful address servers can also supply configuration
   is designed to support flexible address assignment and is suitable
   for more sophisticated topologies information
and for environments where system
   administrative control is desired, e.g.  corporate networks.

   Any node can use stateless address parameters to a host.  The stateful autoconfiguration mechanism
allows hosts to form obtain addresses, other configuration information or
both from a server.  Stateless and stateful autoconfiguration complement
each other. For example, 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 its own addresses, but use stateful autoconfiguration to
obtain other information. Stateful autoconfiguration is itself configurable, and
   requires no manual configuration per host.

   One of the basic assumptions of described in

The stateless autoconfiguration approach is that
   the token used to form addresses per interface when a site is at least unique per
   link. However, whatever not particularly concerned
with the type of tokens used, interface tokens exact addresses hosts use, so long as they are
   not guaranteed to always be unique in practice because of errors in
   assignment. Thus, it and
properly routable. The stateful approach is possible that IPv6 addresses formed using used when a site requires
tighter control over exact address assignments.  Both stateful and
stateless address autoconfiguration are not unique among all nodes on a link.
   Since duplicate 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 very difficult leased to track down when
   they occur, this document also specifies a procedure an interface for detecting
   duplicate addresses.  Note a fixed (possibly
infinite) length of time. Each address has an associated lifetime that
indicates how long the algorithm does not only apply address is bound to
   addresses autoconfigured using an interface. When a lifetime
expires, the stateless mode. It should binding (and address) becomes invalid and the address may

be used reassigned to verify another interface elsewhere in the uniqueness of any address, for example, addresses con-
   figured using Internet. To handle
the stateful mode or manually configured addresses.

   This document describes how a node configures a link-local address
   per interface using stateless expiration of address autoconfiguration, and how a
   host configures global or site-local unicast addresses per interface
   using stateless bindings gracefully, an address autoconfiguration.  Stateful goes through
two distinct phases while assigned to an interface. Initially, an
address autocon-
   figuration is outside "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 scope use of this document.  However, address is discouraged, but not strictly
forbidden.  New communication (e.g., the docu-
   ment does specify how opening of a host determines whether new TCP
connection) gives preference to using a non-deprecated address, with use
of the stateless
   mechanism or the stateful mechanism for configuring global or site-
   local addresses.

   The document also describes the algorithm used by a node deprecated address restricted to detect if applications that have been
using the deprecated address already and would have difficulty switching
to another address without a service disruption.

Finally, this document describes the algorithm a node employs to verify
that an address it is about to assign to an interface is unique on the
link. The "duplicate address detection" algorithm is used before an
address is actually used, independent of whether the address was
obtained via stateless or stateful autoconfiguration.

The autoconfiguration process specified in this document applies only to
hosts and not routers. Since host autoconfiguration uses information
advertised by routers, routers will need to be configured by some other
means. However, it is possible for routers to use the mechanism
described in this document for generating a link-local address. All
nodes (not only hosts) should use the duplicate when initially configured. address detection

Section 2 provides definitions for terminology used throughout this
document. Section 3 describes the design goals that lead to the current
autoconfiguration procedure. Section 4 provides an overview of the
protocol, while Section 5 describes the protocol in detail.


   IP          - Internet Protocol Version 6.  The terms IPv4 and IPv6
                 are used only in contexts where necessary to avoid

   node        - a device that implements IPv6. IP.

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

   host        - any node that is not a router.

   upper layer - a protocol layer immediately above IPv6. IP.  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 IP such as IPX, AppleTalk,
                 or IPv6 IP itself.

   link        - a communication facility or medium over which nodes can
                 communicate at the link layer, i.e., the layer
                 immediately below IPv6. IP.  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.

   autoconfigurable interface
               - an interface that has been configured by system
                 management to perform autoconfiguration.

   packet      - an IPv6 IP 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

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

   unicast address
               - an identifier for a single interface. A packet sent to
                 a unicast address is delivered to the interface
                 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

   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.


   solicited-node multicast address
               - a multicast address to which Neighbor Solicitation
                 messages are sent. The algorithm for computing the
                 address is given in [DISCOVERY].

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

   link-local address
               - an address with a having link-only scope that is limited can be used to
                 the locally
                 reach neighboring nodes attached to the same link.  All
                 interfaces have a link-local unicast address.

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

   global address
               - an address with unlimited scope.

               - 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 request-

   tentative address
               - indicates the time at which an address should no
                longer be used as whose uniqueness on a source link is being
                 verified, prior to its assignment to an interface.  A
                 tentative address in new
                communications. The deprecation lifetime must be
                less than or equal is not considered assigned to an
                 interface in the invalidation lifetime
                of usual sense. An interface discards
                 received packets addressed to a tentative address, but
                 accepts Neighbor Discover packets related to duplicate
                 address detection for the tentative address.

   invalidation lifetime

   preferred address
               - indicates the time at which an address no longer
                 identifies assigned to an interface whose use by upper
                 layer protocols is unrestricted. Preferred addresses
                 may be used as the source or set destination address of interfaces.
                 The invalidation lifetime must be greater than
                 packets sent from or equal to the deprecation lifetime of the address.

   valid interface.

   deprecated address
               - an An address assigned to an interface whose deprecation lifetime has use is
                 discouraged, but not yet
                 expired. forbidden.  A deprecated address
               - an
                 should no longer be used as a source address whose deprecation lifetime has expired, in new
                 communications, but whose invalidation lifetime has not.

   invalid packets sent to deprecated address
                 are delivered as expected.  A deprecated address may
                 continue to be used as a source address in
                 communications where switching to a preferred address
                 causes hardship to a specific upper-layer activity
                 (e.g., an existing TCP connection).

   valid address whose invalidation lifetime has

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

2.1.  Requirements

   Throughout this document, the words that A valid address may
                 appear as the source or destination address of a
                 packet, and the internet routing system is expected to
                 be able to deliver packets sent to a valid address.

   invalid address
               - an address that is not assigned to any interface. A
                 valid address becomes invalid when its deprecation
                 lifetime expires.  Invalid addresses should not appear
                 as the   destination or source address of a packet. In
                 the former case, the internet routing system will be
                 unable to deliver the packet, in the later case the
                 recipient of the packet will be unable to respond to

   preferred lifetime
               - the length of time that a valid address is preferred.
                 When the preferred lifetime expires, the address
                 becomes deprecated.

   valid lifetime
               - the length of time an address remains in the valid
                 state. The valid lifetime must be greater then or equal
                 to the preferred lifetime.  When the valid lifetime
                 expires, the address becomes invalid.

   interface token
               - a link-dependent identifier for an interface that is
                 (at least) unique per link. Stateless address
                 autoconfiguration combines an interface token with a
                 prefix to form an address. An IEEE 802 hardware address
                 is an example of a possible interface token. The manner
                 in which an interface token is created and its length
                 is link-specific, and is described in the specification
                 for the particular link type (e.g., [IPv6-ETHER]).

2.1.  Requirements

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

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

     This phrase means the item is an absolute prohibition of this

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

     This phrase means that there may exist valid reasons in particu-
        lar particular
     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.

     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.


   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  DESIGN GOALS

Stateless autoconfiguration is to be used for
   address configuration (possibly designed with the following goals in addition

   o Manual configuration of individual machines before connecting them
     to the stateless proto-
   col). The other flag, called the "other configuration mode" flag,
   indicates whether the stateful protocol network should not be required. Consequently, a mechanism is
     needed that allows a host to be used obtain or create unique addresses for configura-
     each of other information besides addresses.

   The address list always includes at least one address, its interfaces. Address autoconfiguration assumes that each
     interface can provide a unique identifier for that interface (e.g.,
     an "interface token").  In the host's
   link-local address, which is simplest case, an address that interface token
     consists of the link's hardware address. An interface token can only be used in com-
   munications between nodes
     combined with a prefix to form an address.

   o Small sites consisting of a set of machines attached to a single
     link should not require the link. In addition, the
   address list includes any global or site-local addresses that have
   been manually presence of a stateful server or automatically configured.

   Note that stateless address autoconfiguration applies only to router
     as a prerequisite for communicating.  Plug-and-play communication
     is achieved through the
   formation use of unicast link-local addresses. A node may, however, have anycast and
   multicast  Link-local
     addresses associated with an interface. In particular, have a
   host must join the all-nodes multicast address on any multicast
   interface, and well-known prefix that identifies the solicited-node multicast address corresponding (single)
     shared link to
   each unicast address on any multicast interface.

3.1.  Address Configuration

3.1.1.  Link-Local Address

   On initialization of an interface, which a set of nodes attach. A host must form forms a link-local link-
     local address by concatenating a well-known the link-local prefix[1] to an prefix with its
     interface token that is unique per link.  The definition of the
   tokens used are link-dependent.  For example, in token.

   o A large site with multiple networks and routers should not require
     the case presence of a host
   attached stateful address configuration server. To enable
     hosts to a link that uses IEEE 802 generate site-local or global addresses, Router
     Advertisements, which are generated by routers, include options
     that list the token is the
   48-bit IEEE 802 link-layer address set of the interface.  Tokens for active prefixes on a
   specific link are defined in link-specific IPv6 documents and are
   outside link.

   o Address configuration should facilitate the scope graceful renumbering of this document.

   Note that 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.

3.1.2.  Global/Site-Local Address

   A host forms site's machines. For example, a new global/site-local address whenever site may wish to renumber all of
     its nodes when it switches to a new prefix is
   advertised by a router and stateless address configuration is
   enabled.  The address network service provider.
     Renumbering is formed by concatenating achieved through the network prefix leasing of addresses to
     interfaces and the interface token that is unique per link in assignment of multiple addresses to the same way as
     interface.  Lease lifetimes provide the mechanism through which a
   link-local address described above.
     site phases out old prefixes.  The mechanism used assignment of multiple addresses
     to advertise network prefixes an interface provides for the purposes of a transition period during which both
     a new address configuration is and the same as that used in Neighbor Discovery
   for one being phased out work simultaneously.

   o System administrators need the purposes of prefix discovery.  A router advertises prefix
   information periodically and ability to specify whether stateless
     autoconfiguration, stateful autoconfiguration, or both should be
     used.  Router Advertisements include flags specifying which
     mechanisms a host uses this information to config-
   ure and reconfigure addresses.

3.2.  Address Reconfiguration

   One of should use.


This section describes the goals typical steps that take place when an
interface autoconfigures itself. Autoconfiguration of IPv6 a link-local
address autoconfiguration normally takes place when an interface is not only to be
   able to autoconfigure a list (re)initialized, e.g.
at startup.  Autoconfiguration of global and site-local addresses on initialization of and
other parameters is done periodically, starting as soon as possible
after 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 has been initialised or enabled for

A node starts the autoconfiguration process by generating a
   number of reasons. For example, if link-local
address for the interface.  Before 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 can be used, however, the
node attempts to maintain
   existing communications during an address change. For example, a TCP
   connection will no longer work if one of verify that the hosts changes its "tentative" address is not already in
use by another node on the middle of a connection. Even in link. The node sends out a UDP exchange, Neighbor
Solicitation message containing the tentative address as the target. If
another node is already using that address, it will return a host Neighbor
Advertisement saying so. If another node is expected to be able also attempting to identify itself using use the
same address address, it will send a Neighbor Solicitation for the length of the exchange.

   To minimise disruption caused by an address change, an target as
well. If a node determines that its tentative link-local address is
   configured with two lifetimes : a deprecation lifetime not
unique, autoconfiguration stops and an invali-
   dation lifetime. The deprecation lifetime must be less than or equal
   to the invalidation lifetime. Before expiry manual configuration of the deprecation life-
   time, machine
is required.

Once a node ascertains that the tentative address is valid and may be used as unique, it assigns
it to the source and destina-
   tion in any communications. interface. At and after expiry of the deprecation
   lifetime, but before this point, the invalidation lifetime node has expired, the
   address is considered to be deprecated. A deprecated address can
   still be used as IP-level connectivity
with neighboring nodes via its link-local address.

To generate site-local or global addresses, a host listens for Router
Advertisements.  To obtain an advertisement quickly, a host sends one or
more Router Solicitations to the source and destination in packets legitimately,
   but all-routers multicast group. If no
Router Advertisement is received, the deprecated host assumes that stateful address
autoconfiguration is desired and invokes an appropriate protocol.

Router Advertisements contain two flags indicating what type of stateful
autoconfiguration (if any) should not be used as a source performed. A "managed address in
   new communications if other valid addresses exist and these addresses
   have sufficient scope.  If no valid addresses
configuration" flag indicates whether hosts should use stateful
autoconfiguration to obtain addresses. An "other configuration" flag
indicates whether hosts should use stateful autoconfiguration to obtain
additional information (excluding addresses).

Router Advertisements also contain zero or more Prefix Information
options that indicate what type of sufficient scope
   exist, then the deprecated stateless address autoconfiguration
should still be used.  (Note that
   there will always done. It should be at least noted that the stateless and stateful
address autoconfiguration fields in Router Advertisements are processed
independently of one valid another, and a host may use both stateful and
stateless address autoconfiguration simultaneously.  One Prefix
Information option field, the "autonomous address-configuration flag",
indicates whether or not the option even applies to stateless
autoconfiguration.  If it does, additional option fields contain a
subnet prefix together with lifetime values indicating how long
addresses created from the prefix remain preferred and valid.

Routers advertise Router Advertisements periodically. Hosts process the
information contained in each advertisement as described above.

For safety, all addresses obtained through autoconfiguration should be
tested for uniqueness.  In the address list, case of addresses created through
stateless autoconfig, however, the link-local address (see below), but this uniqueness of an address is only useful
   for communications on
determined primarily by the local link, and thus cannot be used in
   place portion of the address formed from an
interface token.  Thus, if a deprecated node has already verified the uniqueness of
a link-local address, additional addresses created from the same
interface token need not be tested for uniqueness. In contrast, all
addresses obtained via stateful address autoconfiguration should be
tested for non-local link communications).

   An uniqueness individually. To accommodate sites that believe
the overhead of performing duplicate address becomes invalid when detection outweighs its
benefits, the invalidation lifetime expires.
   Such an use of duplicate address must not detection can be used as disabled through
the administrative setting of a source address in outgoing com-
   munications or accepted as per-interface configuration flag.

4.1.  Site Renumbering

Address leasing facilitates site renumbering by providing a destination address mechanism to
time-out addresses in incoming communi-
   cations. An invalid address is removed from hosts.  At present, the TCP/IP protocol suite
provides no support for changing endpoint addresses while a TCP
connection is open. If an end-point address list of changes, existing
connections break and all communication to the

   Note that old address fails.  Even
when applications use UDP as a transport protocol, addresses must
generally remain the deprecation lifetimes same during a packet exchange.

Distinguishing valid addresses into preferred and invalidation lifetimes deprecated categories
provides a way of indicating to upper layers that a valid address may

become invalid shortly, and future communication using the
   link-local address are set will
fail, should the address's deprecation lifetime expire before
communication ends.  To avoid this scenario, higher layers should use a
preferred address (assuming one of sufficient scope exists) to infinity. Thus, increase
the link-local likelihood that an address
   is  never deprecated.

   The intention will remain valid for the duration of the two lifetimes per address
communication.  It is up 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 set appropriate
prefix lifetimes in new communications order to minimise minimize the risk impact of breaking communications failed communication
when the old one times out. A system administrator should set the renumbering takes place.  The deprecation period should be long
enough so that most, if not all, communica-
   tions have switched over to communications are using the new address by
at 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-

   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
   address at the beginning of a new communication. invalid.

The IP layer is expected to provide a means for upper layers or applications (including
applications) to select the most appropriate source address given a
particular desti-
   nation. destination and possibly other constraints.  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.


   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

   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

Detailed address deprecation

   6    the invalidation lifetime of the prefix for selection rules are beyond the purpose scope of
        address invalidation. This field is also used by prefix

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


   This section specifies host address

Address autoconfiguration behavior is performed on
   receiving a Router Advertisement. per-interface basis.  For
multihomed hosts, address autoconfiguration is performed independently
on each interface.

5.1.  Host Configuration Variables

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


     AutoConfig     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 autoconfigures itself following the
                    procedure described 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.

   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).

     DuplAddrDetect If the new value is set, the host node 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 duplicate detection
                    procedure (Section 5.4) to FALSE.  The actual times at which the proto-
      col is invoked, for example, verify addresses are
                    unique before assigning them to request an interface.

                    Default: TRUE

5.2.  Autoconfiguration-Related Variables

A host maintains a list number of addresses or
      renew a list data structures and flags:

     ManagedFlag    Copied from the Managed field of addresses, are specified by the protocol itself. most recently
                    received Router Advertisement message. The host stores flag
                    starts out in a FALSE state.

     OtherFlag      Copied from the current value Other field of the Other Configuration most recently
                    received Router Advertisement message.  The flag
                    starts out in a FALSE state.

     AddressList    List of addresses together with their associated
                    lifetimes. Addresses on the list can be obtained
                    through stateless or stateful address
                    autoconfiguration, or some other external mechanism.
                    AddressList initially contains no entries.

The values of these variables and then sets flags changes over time as the Other Configuration Mode
lifetimes of prefixes (and addresses) expire, new prefixes are learned,

If system management changes an interface's AutoConfig flag from TRUE to that in the
      Router Advertisement (O bit).  If
FALSE, the new value is set, the host of ManagedFlag and OtherFlag MUST use stateful autoconfiguration be set to acquire other configuration
      information besides the address.

      The above disclaimer applies here FALSE, with
any in-progress autoconfiguration activities interrupted as well. The O bit indicates
      whether the described
below in Section 5.5.3.

5.3.  Creation of Link-Local Addresses

A host must use forms a link-local address whenever an interface is initialized
and the stateful mode to acquire other con-
      figuration information. The stateful protocol AutoConfig flag is enabled for this
      purpose as soon as TRUE. (Note that the Other Configuration Mode changes AutoConfig flag may be
set independently of interface initialization. If the link-local address
has not yet been created when the AutoConfig is changed from FALSE to TRUE.
TRUE, it is created at this time.) An interface is initialized after the
following events:

   - The protocol interface is initialized at system startup time.

   - The interface is reinitialized after a temporary interface failure
     or after being temporarily disabled as soon as the mode changes from
      TRUE to FALSE. by system management.

   - The mode does not indicate the timing of frequency
      of acquiring that information. This interface attaches to a link for the first time.

A link-local address is defined formed by prepending the stateful
      protocol itself.

   For each Prefix-Information extension in the Router Advertisement
   that has well-known link-local
prefix E8::0 [ADDR-ARCH] (of appropriate length) to the Autonomous flag set:

      - interface token.

If the prefix advertised matches the prefix interface token has a length of an
           autoconfigured address already in N bits, the list, then set interface token
replaces the
           deprecation timer to that right-most N zero bits of the deprecation lifetime speci-
           fied in link-local prefix.  If the extension
interface token is more than 118 bits in length, autoconfiguration fails
and manual configuration is required.

A link-local address has an infinite preferred and valid lifetime; it is
never timed out.

5.4.  Verifying The Uniqueness Of An Address

Duplicate address detection is performed on an interface only if the invalidation timer
DuplAddrDetect configuration variable is set to that of
           the invalidation lifetime.

           Note that this processing MUST NOT be TRUE.

Duplicate address detection is 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 once after an
address using this
           network prefix and the interface token. Definitions of the
           interface token is created, but before assigning it to be used on a specific link are documented

           If an interface, regardless
of whether the prefix advertised address is too short obtained through stateful, stateless or too long to form a
           128-bit address, given manual
configuration.  All addresses SHOULD be tested for uniqueness. However,
when stateless address autoconfiguration is used, address uniqueness is
determined solely by the interface token, the prefix is
           ignored and assuming that subnet prefixes
are assigned correctly (i.e., if all of an error is logged.

           Add this address to interface's addresses are
generated from the list with same token, either all addresses or none of them will
be duplicates). Thus, for a set of addresses formed from the deprecation timer set same
interface token, it is sufficient to check that one of the deprecation lifetime  and addresses is
unique on the invalidation
           timer to that link. In such cases, one of the invalidation lifetime.

           Note: The address list should those addresses MUST be variable-length. Hosts
verified before any of the addresses can be able assigned to store an interface.
Normally, the link-local address as well as all
           addresses configured using both would be tested, since it is the stateless first
address to be formed.

The procedure for detecting duplicate addresses makes use of Neighbor
Solicitation and stateful
           modes. Advertisement messages as described below. If the implementation cannot store all addresses, the
           host should log a system management error.

      Note that if the deprecation lifetime is zero, the
duplicate address with
      that prefix is immediately deprecated. Similarly, if discovered during the invalida-
      tion lifetime is zero, procedure, the address with that prefix is immediately
      made invalid. (The invalidation lifetime is defined interface will
need to be no less
      than the deprecation lifetime.) If manually configured with a new token, or all IP addresses for
the deprecation lifetime is
      infinity, interface will need to be manually configured.  Note that the address method
for detecting duplicates is never deprecated. Similarly, if the
      invalidation lifetime not completely reliable, and it is infinity, possible
that duplicate addresses will still exist.

An address on which the duplicate address detection procedure is never invali-
      dated. The value of infinity is defined in [2].

      An address applied
is valid said to be tentative until the deprecation timer expires. procedure has been completed
successfully.  A valid
      address can be used as a source tentative address is not considered "assigned to an
interface" in all outgoing
      communications the traditional sense. That is, the interface must accept
Neighbor Solicitation and is accepted as a destination Advertisement messages containing the
tentative address in all
      incoming communications.

      When the deprecation lifetime of Target Address field, but processes such
packets differently from those whose Target Address matches an address expires,
assigned to the interface. Other packets addressed to the tentative
      SHOULD continue to should be used as a source silently discarded.

It should also be noted that duplicate address if it is in use in
      existing communications, but SHOULD NOT detection will nearly

always need to be used in new communica-
      tions if a valid performed before an address is available and it has sufficient scope.
      The IP layer MUST continue assigned to accept datagrams destined an
interface to a
      deprecated address since a deprecated avoid problems that directly result from multiple nodes
using the same addresses. If address resolution is still defined to
      identify the interface.

      An done in parallel with
duplicate address remains deprecated until its invalidation timer expires
      at which point detection, and the address becomes invalid and is removed from subsequently determined
to be in use by another node, the node performing duplicate address list. An invalid
detection may send packets containing the tentative address can no longer be used that
interfere with the proper functioning of the other nodes, especially the
one already using the address.

5.4.1.  Message Validation

A node MUST silently discard any Neighbor Solicitation or Neighbor
Advertisement that does not specify the validity checks as  a
      source address specified in outgoing communications and
[DISCOVERY]. A solicitation that passes these validity checks is not recognised as called
a valid destination solicitation or valid advertisement.

5.4.2.  Sending Neighbor Solicitation Messages

Before sending a Neighbor Solicitation, an interface MUST join the all-
nodes multicast address in incoming communications since and the solicited-node multicast address is defined of the
tentative address.  The former insures that the node receives Neighbor
Advertisements from other nodes already using the address; the latter
insures that two nodes attempting to no longer identify use the interface.

      On initialisation of same address simultaneously
detect each other's presence.

To check an interface, if address, a host determines that there
      are no IPv6 routers on node sends a link, Neighbor Solicitation with a host MUST attempt Target
Address set to use stateful
      autoconfiguration the address being checked. The source of the solicitation
is set to acquire addresses the unspecified address and other configuration
      information.  This the destination is needed set to support networks with no IPv6
      routers.  The host determines that there are no routers on the
solicited-node multicast address of the target address.

If the Neighbor Solicitation is the first message to be sent from an
interface after startup if no Router Advertisements are heard in interface (re)initialization, the node should delay the
message by a random amount of time that it would take to send MAX_ROUTER_SOLICITATIONs between 0 and wait
      for a response[2]. If a router comes
MAX_RTR_SOLICITATION_DELAY as specified in [DISCOVERY].  This serves to
alleviate congestion when many nodes start up on the link at the same
time, such as after a power failure, and Router
      Advertisements begin may help to be received, a host MUST start avoid race
conditions when more than one node is trying to use
      Router Advertisements in solicit for the normal way, and, in particular, use
      advertisements to determine whether stateless or stateful same
      configuration at the same time.

There should be in use.

      Note that a way for a node to determine whether a sending
interface loops back packets sent to a multicast address. Otherwise it is
will not be possible for hosts a node to get address information
      using both stateless determine whether a solicitation
received on an interface is from itself or from another node with a
duplicate address. This issue is discussed in more detail below.

5.4.3.  Receiving Neighbor Solicitation and stateful protocols since both may be
      enabled at Advertisement Messages

On receipt of a valid Neighbor Solicitation message on an interface,
node behavior depends on whether the same time. Even if only stateless target address is tentative or not.
If the target 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 not tentative, the union of all information received using solicitation is processed in
the stateless and stateful protocols. normal way [DISCOVERY]. If different sources config-
      ure the same address, then target address is tentative,
processing takes place as follows. There are two cases to consider.

If the source address of the solicitation is updated with not the most
      recently advertised lifetime.

      It unspecified
address, a node is also possible for hosts to contain performing address information from
      different sources, when changing from one mechanism to resolution on the other,
      i.e.  when changing from stateless mode to stateful mode, and vice
      versa. In this case, address.  The
node receiving the rules are no different from above. If solicitation should silently discard the
      newly enabled mode is configured message and
MUST NOT return a response. Responding to hand out different addresses
      than address resolution requests
for a tentative address risks polluting the mode just disabled, then Neighbor Caches of other
nodes should the host contains address already be in use by another node.

If the union source address of
      addresses from both sources until the addresses configured using Neighbor Solicitation is the old protocol timeout.  If both unspecified
address, the old and new modes solicitation is from a node performing duplicate address
detection. There are con-
      figured two cases to hand out consider. First, the same address, then solicitation may
have been sent by the receiving node (e.g., the packet was looped back).
Alternatively, another node (with the same hardware address and/or
interface token) is updated
      with also attempting to use the most recently advertised lifetime. NOTE: The above
      assumes that address. In the stateless first
case, the solicitation should be ignored. In the second case, the
tentative address is a duplicate and stateful modes should not be used (by either

Determining whether a multicast solicitation was looped back to the
sender or actually came from another node is implementation-dependent.
If two interfaces happen to have the same life-
      time semantics.


   This section specifies hardware link address, one
cannot distinguish the rules for forming a link-local address. It
   also specifies two cases by comparing the protocol to be used for duplicate address detec-

6.1.  Forming a Link-Local Address

   A node MUST packet contents.
Instead, the implementation must have a link-local address.  A node forms good understanding of the
interface's multicast loopback semantics. In particular:

   - If a link-local Neighbor Solicitation for a tentative address whenever an interface is initialised.  The method for forming received
     prior to having sent a link-local Neighbor Solicitation, the tentative address
     is link-dependent a duplicate.

   - If a Neighbor Solicitation has been sent, and an identical one is outside
     received, the scope of
   this document.

   An interface may be initialised or become autoconfigurable after any
   of tentative address is a duplicate if the following events:

   -    The interface is initialized at system startup time.
     does not loopback multicast packets.

   -    The interface In all cases, if more Neighbor Solicitation for the tentative
     address are received than have been sent, the tentative address is reinitialized after
     a temporary duplicate.

If a Neighbor Advertisement containing the tentative address is received
while performing duplicate address detection, the node MUST disable that
        failure or after being temporarily disabled by and log a system manage-

   -    The node management error.  If no such advertisement
is received within the time specified, the address is re-attached no longer

considered to be tentative and can be assigned to the interface.

If a link after being detached for some

   The link-local duplicate address is highly likely to need detected, the node does not respond to be one of the
   first events in
solicitation. Instead, it disables the interface initialisation process. Clearly, it
   must be formed before any duplicate detection processing is performed
   for this address (Section 6.2).  In hosts, and logs a link-local address is
   also required before system
management error.

5.5.  Creation of Global- and Site-Local Addresses

5.5.1.  Sending Router Solicitations

Router Advertisements are sent periodically to the all-nodes multicast
address. To obtain an advertisement quickly, a host sends out a Router Solicitation, assuming the
   node chooses to do this[2]. This is because
Solicitations as described in [DISCOVERY].

5.5.2.  Absence of Router Advertisements

If a solicitation is only
   sent if an advertisement link has not yet been heard (and hence no non- routers, a host MUST use stateful autoconfiguration to
obtain addresses and other configuration information.  From the
perspective of autoconfiguration, a link local address has no routers if no Router
Advertisements are being received.  Router Advertisements can be formed), and absent
in two scenarios:

   - From the unspecified address cannot
   be used time autoconfiguration was last initiated, no Router
     Advertisements have been received at all, after having sent Router
     Solicitations as a source address described in a [DISCOVERY].

   - At least one Router Solicitation.

6.2.  Detecting Duplicate Addresses

   The procedure Advertisement was received, but enough time has
     elapsed since receipt of the last advertisement that a new one
     should have been received. Autoconfiguration does not attempt to
     detect this situation.

When a duplicate address MUST be enabled by
   default in nodes host determines that no routers are present on a link, it sets
the value of ManagedFlag and SHOULD be used.

   In principle, OtherFlag to TRUE, initiating stateful
autoconfiguration as described in Section 5.5.3 (if necessary).  If a
router subsequently begins sending Router Advertisements, the duplicate address detection procedure rules in
Section 5.5.3 insure that hosts process them in the proper way.

5.5.3.  Router Advertisement Processing

Autoconfiguration silently ignores Router Advertisement messages
received on interfaces in which the AutoConfig flag is applied set to
   each new address configured for an interface, whether it be manually
   configured or configured automatically using either FALSE.

On receipt of a valid Router Advertisement (as defined in [DISCOVERY]),
a host copies the stateless or
   stateful mode. However, if value of the addresses belonging advertisement's Managed bit into

ManagedFlag. If the value of ManagedFlag changes from FALSE to an interface
   are formed using TRUE, the same interface token (as is
host should invoke the stateful address autoconfiguration protocol.  If
the value of the case in state-
   less ManagedFlag changes from TRUE to FALSE, any activity
related to stateful address autoconfiguration and may should be halted. If the case in other forms
value of confi-
   guration), then the flag stays unchanged, no special action takes place. In
particular, a host MUST NOT reinvoke stateful address configuration if
it is only necessary to check that one of already participating in the
   addresses stateful protocol as a result of an
earlier advertisement.

An advertisement's Other bit is unique on processed in an analogous manner. A host
copies the link.  In value of the stateless mechanism, it is
   recommended that Other bit into OtherFlag. If the link-local address be value of
OtherFlag changes from FALSE to TRUE, the address checked for
   two reasons. First, it makes host should invoke the implementation simpler, since
stateful autoconfiguration protocol.  If the
   link-local address is guaranteed value of the OtherFlag
changes from TRUE to always exist in all nodes,
   whereas global and site-local FALSE, any activity related to stateful
autoconfiguration for parameters other than 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 should be done immediately on initialisation halted.
If the value of an inter-
   face), whereas checking a global or site-local address involves wait-
   ing until the flag stays unchanged, no special action takes place.
In particular, a host hears a Router Advertisement containing address pre-
   fixes, and there MUST NOT reinvoke stateful configuration if it 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
already participating in [2] to validate an
   address the stateful protocol as specified below.  Note that before carrying out this pro-
   cedure, a node joins result of an earlier

For each Prefix-Information option in 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, Router Advertisement:

 a) If the node will need to
   be configured with a new token, or if this Autonomous flag is not possible, set, silently ignore the IPv6
   addresses will need to be manually configured.

6.2.1.  Soliciting Node Behavior

   An address is checked for uniqueness only once, when Prefix.

 b) If the address prefix is
   initially configured.

   Once the address link-local prefix, silently ignore the Prefix
    Information Option.

 c) If the preferred lifetime is configured, greater than the valid lifetime,
    silently ignore the Prefix Information Option. A node sends a Neighbor Solicita-
   tion with MAY wish to
    log a target address containing system management error in this case.

 d) If the address to be validated.
   The source is set to prefix advertised matches the unspecified prefix of an autoconfigured
    address and already in the destination is list, then set the preferred timer to that of
    the solicited-node multicast address.  The Source Link Layer
   Address extension SHOULD NOT be sent (as it will be ignored by option's preferred lifetime, and set the
   destination node[2]).  Loopback valid lifetime to that
    of the Neighbor Solicitation MUST NOT
   be disabled.

   NOTE: option's valid lifetime.

 e) If the Neighbor Solicitation is prefix advertised does not match the first message to be sent
   from prefix of an interface on interface initialisation, address
    already in the node should delay
   a random amount of time between 0 and MAX_INITIALIZATION_DELAY
   seconds before sending list, then form an address by appending the solicitation.  This serves interface
    token to alleviate
   congestion when many nodes start up on the prefix as follows:

    |            128 - N bits               |       N bits           |
    |            link at prefix                |   interface token      |

    If the same time,
   such as after a power failure, sum of the prefix length and helps interface token length does not
    equal 128 bits, the Prefix Information option MUST be ignored. An
    implementation MAY wish to avoid race conditions
   when more than one node log a system management error in this
    case. It is trying the responsibility of the system administrator to solicit insure
    that the lengths of prefixes contained in Router Advertisements are
    consistent with the length of interface tokens for that link type.

    In those cases where a site requires the same address at use of longer prefixes than
    can be accommodated by the same time. (It interface token, stateful
    autoconfiguration can be used.

    If an address is recommended that nodes include some unique
   value in formed successfully, the seed used host adds it to initialise their pseudo-random number gen-
   erators. Note that using only
    AddressList, initializing its preferred and valid lifetime values
    from the node token Prefix Information option.

5.5.4.  Address Lifetime Expiry

A preferred address becomes deprecated when its preferred lifetime
expires.  A deprecated address SHOULD continue to be used as a unique value source
address in existing communications, but SHOULD NOT be used in new
communications if a current (non-deprecated) address is not available and it
has sufficient scope.  The IP layer MUST continue to avoid race conditions since the token cannot be relied
   upon accept datagrams
destined to be unique. Although the randomization range a deprecated address since a deprecated address is specified in
   units of seconds, still a
valid address for the actual randomly-chosen value should not interface.

An address becomes invalid when its valid lifetime expires.  An invalid
address MUST NOT be used as a source address in
   units of whole seconds, but rather in units of outgoing communications
and MUST NOT be recognized as a valid destination address for the highest available
   timer resolution.)

   If after sending
interface in incoming communications.

Note that if a solicitation, no Neighbor Advertisement Prefix Information option is received from the target, the node SHOULD retransmit with a preferred
lifetime of zero, the solicitation
   at most every DUPL_ADDR_RETRANS_TIMER seconds until either an adver-
   tisement address with that prefix is received or immediately
deprecated. Similarly, if the solicitation has been retransmitted
   MAX_DUPL_ADDR_RETRANS times. If an advertisement advertised valid lifetime is received zero, the
address with a
   target that prefix immediately becomes invalid.

5.6.  Configuration Consistency

It is possible for hosts to obtain address information using both
stateless and stateful protocols since both may be enabled at 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
time.  It is also possible that interface the values of other configuration
parameters such as MTU size and log hop limit are advertised both by a system management error.
router[DISCOVERY] and the stateful protocol.  If no
   such advertisement the same configuration
information is received within provided using multiple sources, then the time specified, value of this
information should be consistent. However, it is not an error if the address
information is considered detected to be valid.

6.2.2.  Solicited Node Behavior

   A node is in inconsistent: hosts accept the process union of validating an address when a Neighbor
   Solicitation has been sent for the address and no Neighbor Advertise-
   ment advertising that address has been
all information received in using the time it takes
   to send out MAX_DUPL_ADDR_RETRANS solicitations stateless 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 stateful protocols. If

different sources configure the process of validating. This
   is done to help avoid same information, then the race condition where more than parameters
are updated with the most recently advertised values.


  o Is duplicate address detection strong enough (we only send one node NS).
     Constants OK?

  o is
   attempting to validate configurability of DuplAddrDetect good enough? Note that:

       - One can't assume that all nodes are on the address net at the same any one time, i.e.
          so performing DAD just once or twice does not guarantee that
          there won't be collisions later.

       - Turning DuplAddrDetect on/off is difficult in practice. It is a
          per-host (interface) flag, which means it must be turned off
          in each node
   sends out machine. If this is don't by setting a Neighbor Solicitation kernel flag and waits to hear a Neighbor Adver-
   tisement for the address, but no node actually sends an advertisement
          then having everyone boot the address has same kernel, DAD will be turned
          off for all nodes, not yet been validated.

   The special rules just a few.

       - it might be nice to turn DuplAddrDetect on/off via RAs, but
          that means nodes will delay creating link-local addresses
          until they've received an RA or concluded that no routers are as follows: When a node
          present. This is in likely to delay the process of
   validating an address and receives a Neighbor Solicitation for that longer than
          performing DAD. (Ouch.)

       - perhaps allow RSs to be sent out with unspecified source
          address, it MUST NOT send any advertisement in response order to a solici-
   tation for that address.  Rather, the node silently discards the sol-
   icitation unless the solicited RAs with at "do/don't perform

  o Possible Neighbor Discovery Changes

       -Should we allow RSs to be sent out with unspecified 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 to allow DAD and the node RSs to disable be sent in parallel,
          rather than sequentially. This would reduce the interface and log impact of DAD

       Need to specify that a sys-
   tem management error.

   NOTE: The above behavior Router Solicitation is required because nodes send sent 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 when
          AutoConfig flag changes from FALSE to TRUE.

  o what is no way for the node correct language to determine, use in gen-
   eral, whether the solicitation comes from itself or another node
   since the source talking about an "MAC
     address" used as an interface token. Should we use "hardware
     address"?  "MAC" address? Something else?

  o ensure use of the packet is the unspecified address. Hence, the
   above rules specify that a "node" vs. "host" is right; autoconfig really applies
     to only hosts, but duplicate address is detected only if the
   node receives detection wants to be more than one solicitation for the address.

   Once a node has validated its address, it responds
     general. Also, link-local address can apply 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 all nodes, not only


   To be completed.



        M. Crawford. "A Method for the Transmission of IPv6 Packets over
        Ethernet Networks", Internet Draft.

        R. Hinden and S. Deering, "Internet Protocol Version (IPv6)
        Addressing Architecture", Internet Draft, May 1995, draft-ietf-


        T. Narten, E. Nordmark and W. A. Simpson, "IPv6 Neighbor
        Discovery", "Neighbor Discovery
        for IP Version 6 (IPv6)", Internet Draft, July September 1995, <draft-ietf-ipngwg-


The author authors 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 Erik Nordmark.


Susan Thomson                    Thomas Narten
Bellcore                         IBM Corporation
445 South Street                 P.O. Box 12195
Morristown, NJ 07960

   Phone:             Research Triangle Park, NC 27709-2195
USA                              USA

phone: +1 201-829-4514
   Email:           phone: +1 919 254 7798
email:  email: