ADDRCONF Working Group                        Susan Thomson (Bellcore)

<draft-ietf-addrconf-ipv6-auto-01.txt>
<draft-ietf-addrconf-ipv6-auto-02.txt>

               IPv6 Stateless Address Autoconfiguration

Status of this Memo

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

   This document is an Internet Draft.  Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its Areas,
   and its Working Groups. Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months. Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a "working
   draft" or "work in progress."

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

Abstract

   This document specifies

   In IPv6, there are two types of address autoconfiguration: stateless
   address autoconfiguration.  A host
   can form a link-local autoconfiguration and stateful address autonomously based on information local
   to the host.  A configuration. In
   stateless address autoconfiguration, no state is maintained binding a
   particular host can form interface to a specific list of addresses. Rather, an inter-link scope
   address in two
   ways: either autonomously, based on prefixes advertised by routers,
   or is formed algorithmically by using concatenating the IPv6 version network prefix
   of the Dynamic Host Configuration
   Protocol(DHCPv6). All mechanisms rely on attached link to a host having a token that is unique at least per link.  Hosts
   use stateless address autoconfiguration to form a link-local unicast
   address and may use stateless address autoconfiguration to form
   global and site-local unicast addresses.  This document specifies how
   a host
   forms addresses autonomously.  DHCPv6 is described elsewhere.

1.  INTRODUCTION

   An IPv6 host may have multiple uses stateless address autoconfiguration to form a list of
   unicast addresses per interface. The addresses
   can have one of three scopes:

   1.   a link-local address,

   2.   a site-local address, and

   3.   a global address.

   All three address scopes can be autoconfigured.  A host can autocon-
   figure It also specifies how a link-local address autonomously. A host can autoconfigure a
   site-local
   determines whether to use the stateless mechanism or global the stateful
   mechanism.  Stateful address only when a router or a DHCPv6 server autoconfiguration is
   present on outside the link.

   There scope
   of this document.

1.  INTRODUCTION

   In IPv6, there are two types of address autoconfiguration: stateless
   address autoconfiguration and stateful address configuration. In
   stateless address autoconfiguration, no state is only one way maintained binding a
   particular host interface to form a link-local address. On initialization specific list of addresses. Rather, an interface, a host forms such an
   interface address is formed algorithmically by concatenating a
   well-known link-local prefix[1] the net-
   work prefix of the attached link to a host 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 an link that uses IEEE 802
   addresses, the token is the IEEE 802 address of the interface.

   There are two ways to form a site-local or global address.  In the
   first mechanism, a host forms an inter-link scope
   stateful address configuration, state is maintained, typically by con-
   catenating a network prefix advertised in a Router Advertisement[2,3]
   to a token that is unique per link.  Like the link-local address,
   server. For example, the
   token IPv6 Dynamic Host Configuration Protocol is defined
   an example of stateful address autoconfiguration.

   Stateless autoconfiguration is designed to be link-layer dependent.  This mechanism for
   forming a site-local or global 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 no system administrative control is not desired. It  In con-
   trast, stateful address configuration is a simple protocol designed for a very specific purpose: to make stateless support flexible
   address con-
   figuration very straightforward to use assignment and implement.

   The other mechanism available to hosts is to use the IPv6 version of
   the Dynamic Host Configuration Protocol (DHCPv6). DHCPv6 is a suitable for more
   complex protocol allowing sophisticated topologies
   and for very flexible address assignment under
   the control of a system administrator. This protocol typically
   requires significant environments where system management, including server and database
   configuration.

   The choice of mechanism administrative control is desired.

   A host always uses stateless address autoconfiguration to form a
   link-local address per interface.  A host may use in forming an either stateless or
   stateful autoconfiguration to configure addresses of inter-link scope address
   is advertised by a router, if present, and this choice is configur-
   able by a system administrator.
   for an interface, i.e. global or site-local addresses.

   This document describes how a host forms a link-local address and one
   or more site-local or global unicast addresses autonomously. per inter-
   face using stateless autoconfiguration.  It also speci-
   fies specifies how a host
   determines which mechanism whether to use to form an inter-
   link scope address: the autonomous (stateless) approach or DHCPv6.
   Section 2 describes stateless mechanism or the router's role in stateful
   mechanism.  Stateful address autoconfiguration
   and Section 3 is outside the host's role. scope
   of this document.

2.  ROUTER BEHAVIOR  OVERVIEW

   An IPv6 host may have multiple unicast addresses per interface[1].
   The stateless address autoconfiguration mechanism relies on the
   router discovery mechanism specified in [2,3] for forming addresses
   with can have one of three scopes: a link-local scope, a
   site-local scope, or a global scope.  If configured to do so, routers
   advertise prefix information in periodic Router Advertisements.  The
   prefixes are contained in Prefix-Information extensions  Addresses of a Router
   Advertisement. Each Prefix-Information extension indicates whether
   the prefix all three address
   scopes can be used for autonomous autoconfigured. A host is able to autoconfigure a
   link-local address autoconfiguration and,
   if so, for how long completely autonomously. In particular, a host can
   form a link-local address without a router present on the resulting link. A
   host is able to autoconfigure an inter-link scope address only when a
   router is valid. Note that present on the
   lifetime link. The scope of the inter-link address is defined separately from that of
   formed depends on the Router
   Advertisement itself (other information is prefix advertised in on the adver-
   tisement which has different lifetime requirements).  The extension
   also explicitly indicates to hosts whether DHCPv6 is required link.

   On initialization of an interface, a host forms a link-local address
   by concatenating a well-known link-local prefix[1] to be
   used since it is possible a token that system administrators would like to
   have hosts autoconfigure addresses autonomously, but also use DHCPv6
   to acquire other configuration information besides the address.

   Router Advertisement and Solicitation processing is specified in [2]
   and
   unique per link.  The definition of the message formats in [3].

   DISCUSSION: An alternative approach is to advertise address confi-
   guration information tokens used are link-
   dependent.  For example, in a separate advertisement entirely. This would
   be somewhat cleaner since the lifetime case of the advertisement would
   then be a host  attached to a link
   that of uses IEEE 802 addresses, the information advertised. On token is an IEEE 802 address asso-
   ciated with the other hand, having
   two types of router interface.

   A host forms or updates an inter-link scope address on hearing prefix
   advertisements would mean that advertised by a router. A global or site-local address
   is formed by concatenating a network prefix information to a host token that is advertised redundantly, and
   unique per link in particular, would double traffic on
   initialisation and on router solicitations.

2.1.  Router Configuration Variables

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

   For each of the IPv6 unicast addresses per interface:

      Autonomous Flag
         If and only if TRUE, the prefix length is described above.  The mechanism
   used to be advertised advertise network prefixes for the purposes of autonomous address configuration.

         Default: TRUE

   For each interface:

      Administered Flag

         If and only if TRUE, the host must autoconfigure other confi-
   guration information using DHCPv6. Only valid in extensions
         with the Autonomous Flag set to TRUE.

         Default: FALSE

      Address_Advertisement_Interval

         The time allowed between sending unsolicited Address Advertise-
         ments from is the interface, in seconds. The value must not be
         less than Maximum_Advertisement_Interval of Router Advertise-
         ments.

         Default: XX

      Address_Lifetime

         The value to be placed same as that used in Neighbor Discovery[2] for the Lifetime field
   purposes of the
         Prefix_Information extension sent from the interface in
         seconds. The value must not be less than
         Address_Advertisement_Interval. This value indicates how long
         an address formed from the prefix advertised is valid.  Only
         valid in extensions with the Autonomous flag set to TRUE.

         Default: 3 * Address_Advertisement_Interval

   All routers advertising a given prefix on a link MUST be configured discovery.  Rather than specify two separate
   mechanisms to advertise the same autoconfiguration mode prefix information, we use a single
   mechanism which requires hosts to hosts.

2.2.  Processing

   A router MUST advertise perform both prefix discovery pro-
   cessing and address autoconfiguration information in a
   Prefix Information Extension of processing on receiving a Router Advertisement. The values pre-
   fix advertisement. Note that, when prefixes are advertised, it is
   possible to indicate whether the prefixes are to be used for prefix
   discovery only, address autoconfiguration only or both.

   One of the Autonomous goals of IPv6 address autoconfiguration is not only to be
   able to autoconfigure addresses on startup, but to be able to recon-
   figure addresses dynamically. Address reconfiguration ("renumbering")
   enables hosts to acquire new addresses and Administered flags relinquish old addresses
   automatically. Old addresses may then be reused.  To enable hosts to
   renumber with minimal disruption of existing communications, prefixes
   are advertised along with
   Address_Lifetime. two lifetimes: a deprecation lifetime and an
   invalidation lifetime.  The deprecation lifetime indicates when an
   address configuration information need not be
   advertised in each Router Advertisement. It must be sent (almost)
   periodically in formed from a Router Advertisement at an interval of approxi-
   mately Address_Advertisement_Interval.

   Address  configuration information prefix must also be sent in the first few
   Router Advertisements after startup or enabling of an interface (up deprecated. A deprecated address
   may continue to MAX_INITIAL_ADVERTISEMENTS) and in be used as a Router Advertisement that is
   sent source address in response to a Router Solicitation.

   Address  configuration information may also existing
   communications, but should not be sent in used as a Router
   Advertisement due to actions taken by system management, source address in particu-
   lar, new
   communications. The invalidation lifetime indicates when the Address_Lifetime of an address
   formed from a prefix is set to zero, e.g.
   because the link is to no longer valid and may be renumbered. In this case, a Prefix-
   Information extension must reused.  Invalid
   addresses cannot be transmitted used in any communications.  By specifying two
   separate lifetimes, a Router Advertisement
   advertising the appropriate address prefix with the Autonomous Flag
   set to TRUE and Address_Lifetime set to zero.

3.  HOST ADDRESS AUTOCONFIGURATION PROCESSING

3.1.  Host Configuration Variables

   A host maintains a list can gradually phase out use of old
   addresses, while beginning to use new addresses per interface. At a minimum, the
   list includes the link-local address, which the host can form auto-
   nomously whenever an interface is initialised. If for new communica-
   tions (if any).  The deprecation and invalidation lifetimes are con-
   figurable by a router is
   attached system administrator and so the transition from old to
   new addresses may be as quick (the deprecation and invalidation life-
   times are the link same) or DHCPv6 server as slow as desired.

   One of the basic assumptions of stateless autoconfiguration is available, that
   the list may also
   include site-local or global addresses formed either from subnet pre-
   fixes advertised host token is at least unique per link.  However, in Router Advertisements or by making requests using
   DHCPv6. Addresses may also be manually configured. Note there may practice,
   host tokens are not always unique because of errors in assignment.
   Thus, it cannot be
   multiple site-local or global guaranteed that IPv6 addresses autoconfigured per interface.

   A formed from a host must maintain
   token are indeed unique among all hosts on a list of the following configurable variables
   per interface:

   Address

      A valid link. Since duplicate
   IPv6 unicast address addresses are very difficult to track down and debug, we specify
   a procedure for detecting duplicate addresses that hosts should use
   on initialising an interface. Note that this interface

      Default: None

   Prefix Length procedure is not com-
   pletely reliable, and so duplicate addresses may still exist.  The length
   procedure makes use of the prefix in bits. Prefix length semantics are
      specified Neighbor Solicitations and Advertisements[2]
   in [2].

   A a special-purpose way. Briefly, a host must also allow the following variable uses a Neighbor Solicita-
   tion to be configured per
   interface:

   Perform_Auto_Config solicit for itself.  If and only if TRUE, the it discovers that another host must perform has
   the address autoconfigura- through receiving a Neighbor Advertisement, the valida-
   tion processing.

      Default: TRUE

3.2.  Host Initialization Behavior

   A check fails and the host must perform ceases operation on that interface.
   Note that the following autoconfiguration procedure when-
   ever an interface needs to be initialised:

      When a host has no that is already using the address for an interface with
      Perform_Auto_Config flag set to TRUE, e.g. when a host boots or
      when an interface is enabled after being disabled, the host forms
      an address of link-local scope.  Appendix A specifies how (presumably leg-
   itimately) continues unharmed, although it may log a host
      that is attached message to a link that uses IEEE 802 addresses forms a
      link-local address.

      Before adding the link-local address as
   effect that it has received a valid address to the
      list of addresses solicitation for the interface, the its own address.

   This document specifies router and host SHOULD verify that
      the behavior related to stateless
   address is indeed unique. The procedure for validating an configuration and duplicate address is described detection in Section X. A host SHOULD also validate any
      manually configured addresses this way too.

      The host solicits a Router Advertisement using one or more Router
      Solicitations, if no Router Advertisements have been heard detail
   in the
      interface. sections that follow.

3.  ROUTER BEHAVIOR

   The procedure for sending Router Solicitations is stateless address autoconfiguration mechanism relies on the pre-
   fix discovery mechanism specified in [2].

      If no Router Advertisement [2] for advertising network pre-
   fixes required for the formation of addresses with site-local or glo-
   bal scope. A prefix is heard after sending
      MAX_SOLICITATIONS and waiting Router_Solicitation_Interval after
      each as specified advertised in Sending a Prefix Information extension
   of a Router Solicitations in [2], Advertisement. The Prefix Information extension includes
   the host
      must determine prefix and its length, flags indicating whether a DHCPv6 server the information
   is present to be used for prefix discovery or address configuration, and two
   lifetimes: the deprecation lifetime and the invalidation lifetime.
   The Router Advertisement itself includes flags indicating whether any
   stateful address configuration should be used by hosts and whether
   other configuration information (besides an address) needs to be acquired.  This con-
   figured.

   Router Advertisement and Solicitation processing is specified com-
   pletely in [2] along with the message formats and configuration vari-
   ables. Additional configuration variables pertinent to cater
      for a routerless topology which has a DHCPv6 server. Once a router
      is added to the network, however, a host MUST use Router Adver-
      tisements to determine the autoconfiguration mode in use as
      described in the section on Router Advertisement Processing.

3.3.  Router Advertisement Processing

   Router Advertisement processing is stateless
   address configuration are specified in [2] and the message
   format in [3]. below.

3.1.  Router Configuration Variables

   In addition to this processing, the host MUST perform the following address configuration processing when a solicited or
   unsolicited Router Advertisement is received over an interface: variables specified in [2], routers
   MUST also be configurable as follows.

   For each Prefix-Information extension in the Router Advertisement:
   (The format of the Prefix-Information extension as amended by this
   draft for autoconfiguration purposes is specified prefixes to be advertised in Appendix C):

      The host silently ignores Prefix Information
   extensions per interface:

      Autonomous Flag

         If set, the extension prefix is being advertised for the purposes of auto-
      configuration if
         stateless address configuration.

         Default: TRUE

      Deprecation Lifetime

         The value to be placed in the Perform_Auto_Config flag for Deprecation Lifetime field of
         Prefix Information extensions in Router Advertisements sent
         from the interface is
      FALSE.

      Otherwise, the host checks the autoconfiguration mode bits.

      If only the Autonomous flag is set in seconds.

      Invalidation Lifetime

         The value to be placed in the Prefix-Information
      extension, the host forms or verifies a site-local or global
      address as specified below.

      If both the Autonomous and Administered flags are set Invalidation Lifetime field of
         Prefix Information extensions in Router Advertisements sent
         from the
      Prefix-Information extension, interface in seconds. Must be no less than Deprecation
         Lifetime.

   For each advertising interface:

      Administered Flag

         If set, the host forms or verifies a site-
      local or global address as specified below and uses or continues must autoconfigure addresses using DHCPv6 for other stateful
         address autoconfiguration.

      Otherwise,

         Default: FALSE

      Other Flag

         If set, the host silently ignores the extension for must autoconfigure other configuration infor-
         mation (besides the pur-
      poses of autonomous address) using stateful autoconfiguration.

   If none

         Default: FALSE

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

4.  HOST BEHAVIOR

   Conceptually, a host maintains a list of addresses per interface.
   Entries in the list are created as a result of forming addresses from
   prefixes advertised in Prefix Information extensions of the Router Adver-
   tisement have the Autonomous flag set, then the host uses or contin-
   ues using DHCPv6 for autoconfiguration.

   Note that
   tisements.  Each entry in the above procedure should continue to operate when list has two associated timers, a sys-
   tem administrator decides
   deprecation timer and an invalidation timer, which have values set
   according to change the autoconfiguration mode lifetimes learned from the autonomous mode to DHCPv6, and vice versa. The host should keep
   track of router advertisement. In
   addition, the current autoconfiguration mode, so that it can detect
   when there address list always includes the link-local address,
   which the host forms autonomously whenever an interface is a change. initial-
   ised. The system administrator must ensure that,
   during a changeover, deprecation and invalidation lifetimes of a DHCPv6 server is configured to hand out
   addresses that link-local
   address are unique per link, particularly with respect set to
   addresses that hosts have configured autonomously infinity.

   This section specifies host address autoconfiguration behavior on
   interface initialisation and which may not
   yet be invalidated.  To avoid problems during on receiving a changeover, it is
   recommended that Router Advertisement.
   This section also specifies a DHCP server should use exactly the same algorithm host protocol for attempting to form verify
   that an address is not a duplicate.

4.1.  Host Configuration Variables

   A host address as that used in MUST allow the autonomous mode when following variable to be configured per inter-
   face:

   Perform_Auto_Config

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

      Default: TRUE

4.2.  Router Advertisement Processing

   An "autoconfigurable" interface is one on which Router Advertisements
   are received and the same. It Perform_Auto_Config flag is also important to ensure that set.

   A host MUST perform the following address configuration processing
   when a DHCPv6
   server solicited or unsolicited Router Advertisement is configured to hand out addresses only to those hosts that
   it should, since, if a DHCPv6 server received over
   an autoconfigurable interface:

   For each valid Router Advertisement:

      If the Administered flag is present on a link, hosts may
   request set, the server for host MUST use stateful auto-
      configuration to acquire a list of site-local or global addresses (even if
      per interface.

      If the network Other flag is configured set, the host MUST use stateful autoconfi-
      guration to be in autonomous mode) when Router Advertisements are not heard
   because acquire other configuration information besides the router is down.
      address.

      For each Prefix-Information extension received over an autoconfigur-
   able interface, the host updates in the address list as follows when Router Advertisement
      that has the Autonomous flag is set:

   a)

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

   b)

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

           Add this address to the list with a the deprecation timer set
           to that of the deprecation lifetime specified in the extension.

3.3.1.  Address Deprecation  and Invalidation the invalidation
           timer to that of the invalidation lifetime.

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

      An address is valid until the deprecation timer expires. A valid
      address may be used as a source address in all outgoing
      communications and MUST be accepted as a destination address in
      all incoming communications.

      When the deprecation lifetime of an address expires, an address is
      said to be deprecated.  In general, a  A deprecated address should no longer be
   used in new communications, but may SHOULD NOT be used in existing communica-
   tions.

   In particular, the internetworking layer should not select a
   deprecated address as
      a source address in new communications. How-
   ever, However, a deprecated
      address should be allowed SHOULD continue to be used as a source address if it is in
      use by the transport layer in existing communica-
   tions or it is explicitly requested by an application. communications.  The internetworking IP layer must MUST continue to
      accept datagrams destined to a deprecated address. The transport layer may Upper layers
      MAY refuse to accept new communications requests to a deprecated
      address, however.

   In addition, a host may send a Remote Redirect[2,3] to correspondents
   when

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

      Note that, when choosing a deprecated source address in outgoing communica-
      tons, a global valid address should be removed from the Domain Name System (DNS). This may
   be done by the host itself, given used in preference to a DNS dynamic update protocol and
   sufficient authority, or it may
      site-local valid address, which in turn should be done on used in prefer-
      ence to the host's behalf.

   The time at which link-local address. Similarly, a global deprecated
      address becomes invalid (removed from
   the list of addresses per interface) is dependent on the storage
   available for the address list and is thus implementation-dependent.
   A host should keep also be used in preference to a deprecated site-local depre-
      cated addresses. Note that the link-local address until it is no longer in use,
   i.e. never depre-
      cated; it is no longer being used in current communications such as an
   existing TCP connection, and it always valid. One of the implications of these rules
      is that if there are no longer stored or cached in the
   Domain Name System.  After this point, a deprecated address may be
   removed from the address list.

   If Router Advertisements stop being heard and all autoconfigured valid inter-link scope addresses, e.g. all
      global and site-local addresses become are deprecated, then the host must
   determine whether will
      default to using the link-local address as a DHCPv6 server is available source address in new
      communications.

      To limit storage space required for the address autoconfi-
   guration. The list, a host follows the same procedure as described may
      choose not to store all valid and deprecated addresses. Deprecated
      addresses that are not in the
   initialisation procedure use by existing communications should be
      discarded in this case.

3.4.  Detecting Duplicate IPv6 Addresses

   One of the basic assumptions favor of the autoconfiguration schemes out-
   lined in this document is valid addresses and deprecated addresses
      that the are in use.

      If a host token is at least unique per
   link. Tokens determines that there are defined no IPv6 routers on a link,
      either on startup or during normal processing, a host MUST attempt
      to be link-layer dependent, and the token use stateful autoconfiguration to acquire addresses or other
      configuration information if it is not already doing so. This is
      needed to support networks with no IPv6 routers. The host deter-
      mines that there are no routers on the link layer address after startup if no
      Router Advertisements are heard in most cases. In practice, two hosts on the
   same link may time that it would take to
      send MAX_ROUTER_SOLICITATIONs and wait for a response[2]. During
      normal processing, it is determined that there are no routers when
      all router advertisements have timed out.  If a router comes up on
      the same link layer and Router Advertisements begin to be received, a host
      MUST start to use Router Advertisements in the normal way, and, in
      particular, use advertisements to determine whether stateless or
      stateful address configuration should be in use. Note that if a
      host does not receive Router Advertisements because of an assign-
   ment some error, in which case the resulting IPv6 addresses
      e.g. all routers are down or there is a network partition, hosts
      will not be
   unique. For attempt to change mode from stateless (assuming this reason, it is prudent was the
      advertised mode) to check stateful and then back again when Router
      Advertisements start being heard. This means that if the addresses
   are indeed unique.  In IPv6, it stateful
      mode is only necessary available, it should be configured correctly to check that one
   of serve only
      the autoconfigured addresses is unique hosts that it should, since hosts may attempt to use it, even
      if it is not the same token intention that they do so.

      A host must behave reasonably when there is
   used to form all addresses and a change from the prefixes used
      stateless mode to form the
   addresses are all unique (the autoconfiguration procedure should
   ensure this). It is recommended that the link-local address be the
   address checked since it is formed once and first, on initialisation.

   The procedures use General Solicitations stateful mode, and Advertisements specified vice versa. This can hap-
      pen because routers advertise a new configuration mode due to a
      deliberate change by a system administrator, or because of a
      change in [2,3] as modified below.  To validate topology, e.g. an address, the node sends a
   General Solicitation with IPv6 router is connected to or removed
      from the source link.  It is possible and destination set to quite likely that of during the address to be checked.  The node should specify an appropriate
   Media-Access extension.

   On receiving a General Solicitation with
      change-over, a source address that is host will have addresses autoconfigured using both
      mechanisms. If the
   same as addresses acquired using the destination address two mechanisms are
      the same, then the new addresses should replace the old and apparently from itself, a host
   must respond with a General Advertisement. The General Advertisement
   is sent to the All-Nodes Multicast Address
      aging semantics associated with intra-link scope.
   The Media-Access extension from the General Solicitation MUST NOT new mode apply.  If the
      addresses acquired using the two mechanisms are different, then
      the old addresses should be
   retained.

   After sending a General Solicitation, aged according to the node waits for a period of
   General_Solicitation_Interval. If a General Advertisement is not
   received rules specified
      in response to the General Solicitation within old configuration mode and the new addresses should follow
      the interval, rules of the new mode.

4.3.  Host Initialisation

   A host forms a link-local address when an autoconfigurable interface
   is considered to be validated. If initialised.  Appendix A specifies how a General Advertisement host that is received with attached to
   a source address the same as the address being vali-
   dated, it must cease operation on link that interface and indicate an
   appropriate error. uses IEEE 802 addresses forms a link-local address.

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

   -    The interface is not completely initialized at system startup time.

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

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

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

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

4.4.  Detecting Duplicate IPv6 Addresses

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

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

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

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

   DISCUSSION: There is

4.4.1.  Soliciting Host Behavior

   The host first delays a problem with random amount of time between 0 and
   DUPL_ADDRESS_DELAY seconds before sending out a race condition Neighbor Solicitation
   for the address. This serves to alleviate congestion when two (or
   more) nodes boot many hosts
   start up on the link at the same time. Both will send out time, such as after a General
   Solicitation, receive no advertisement power failure,
   and assume all is well.  A fix
   may be helps to have a node process General Solicitations during the vali-
   dation stage and flag an error if it sees avoid race conditions when more than one General Sol-
   icitation host is trying
   to solicit for an the same address it at the same time. (It is recommended
   that hosts include some unique value in the process of validating.

   DISCUSSION: Should the solicitations be dithered? seed used to initialise
   their pseudo-random number generators. Note that randomis-
   ing based on using only the host
   token (link-layer address) only does as a unique value is not help if sufficient since the token cannot be
   relied upon to be unique. Although the randomization range is speci-
   fied in units of seconds, the actual randomly-chosen value should not unique.

4.  SECURITY CONSIDERATIONS

   To
   be completed.

5.  APPENDIX A: FORMING AN IPv6 ADDRESS FOR IEEE 802 LINKS in units of whole seconds, but rather in units of the highest
   available timer resolution.)

   The token for an interface on an IEEE 802 link or any link that uses
   IEEE 802 addressing, such as FDDI, node then sends a Neighbor Solicitation with a target address
   containing the address to be validated. The source is set to the 48-bit IEEE 802
   unspecified address in
   canonical format, i.e. and the Individual/Group  bit destination is set to the low-order bit solicited-node
   multicast address.  The Source Link Layer Address extension SHOULD
   NOT be sent.

   NOTE: There SHOULD be some way to inhibit local delivery of the furst byte.

   A soli-
   citation since, in general, it will not be possible for a host to
   determine whether a solicitation is from itself or from another host forms an IPv6 address per link by concatenating an 80-bit pre-
   fix
   with a duplicate address. If local delivery cannot be inhibited, then
   the IEEE 802 address as follows:

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

   In host should ignore the case first Neighbor Solicitation with an
   unspecified source address or wait for a period of
   DUPL_ADDR_IGNORE_TIMER seconds after sending a link-local prefix, Neighbor Solicitation
   before beginning to process solicitations again.

   If after sending a solicitation, no advertisement is received from
   the prefix target, the node SHOULD retransmit the solicitation every
   DUPL_ADDR_RETRANS_TIMER seconds until either an advertisement is well-defined[1].

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

6.  APPENDIX B: UNIQUENESS OF HOST TOKENS

   As
   received or the solicitation has been mentioned, one of retransmitted
   MAX_DUPL_ADDR_RETRANS times. If an advertisement is received with a
   target address the basic assumptions of same as the autoconfi-
   guration scheme outlined in this document is address being validated, it must cease
   operation on that interface and indicate an appropriate error.  If no
   such advertisement is received in response to the host token Neighbor Solicita-
   tions sent, the address is
   at least unique per link, but that tokens may not always considered to be unique,
   in practice.  A valid.

4.4.2.  Solicited Node Behavior

   When a host should check that an address is unique using in the
   scheme proposed process of validating an address, it MUST NOT
   send any advertisement in this document. Since this is not completely reli-
   able, system administrators may also use DNS response to help detect a solicitation for that
   address. Rather, all solicitations for the address are ignored,
   except when such the solicitation is from the unspecified address i.e.
   the Neighbor Solicitation message has a problem occurs since two different hosts will register target address which is the
   same
   IPv6 address.

   Duplicate IPv6 addresses may occur as the address to be validated, and a result of non-unique tokens
   in source address that is the
   unspecified address. (Note that any particular network topology.  One particular scenario deserves
   further mention though. Consider a topology consisting of two links
   with singly-homed hosts attached solicitation that is likely to each, be
   a multi-homed host attached
   to both and no router. In this case, because no router loopback solicitation should be ignored too as mentioned in the
   above section.) If a solicitation is present,
   hosts will form link-local addresses only received from the unspecified
   address, the host must cease operation on all interfaces.  It is
   imperative that hosts have interface tokens that are unique across
   both links. and indicate
   an appropriate error.

   Once a host has validated its address, it responds to a Neighbor Sol-
   icitation with a Neighbor Advertisement as specified in [2]. However, this may not be true for two reasons:
   the links
   may be processing of the solicitation is somewhat different types and thus from that in
   [2] when a solicitation is received from the tokens used may not be unique.
   Also, unspecified address.  In
   this case, the token may not be unique if it is defined to be host MUST ignore any Link Layer Address Extension in
   the solicitation and MUST NOT perform any link-layer address resolu-
   tion processing before sending a link layer Neighbor Advertisement.  The host
   sends the Neighbor Advertisement to the all-nodes multicast address and
   of the link-layer soliciting host. The target address is only defined to copied from the solici-
   tation message. The source address MUST be unique per
   link as is true in some cases.  Strictly speaking, we require that
   host tokens are globally unique set to ensure correct operation in these
   topologies.  In practice, link layer addresses are frequently glo-
   bally unique and so the uniqueness problems in this scenario should address of the
   target field.  The Target Link Layer Address extension need not be appreciably worse than in more traditional topologies as
   described above.  If two link-local scope addresses are detected to
   filled in.

4.4.3.  Constants

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

5.  SECURITY CONSIDERATIONS

   To be the same in this scenario, there are two solutions: one completed.

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

   The token for an interface on an IEEE 802 link or any link that uses
   IEEE 802 addressing, such as FDDI, is to make the multihomed host a router, 48-bit IEEE 802 address in
   canonical format, i.e. the other Individual/Group  bit is to manually configure the
   link-local address low-order bit
   of the furst byte.

   A host forms an offending host.

7.  APPENDIX C: Prefix-Information Extension

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Extension   |    Length     |C|A|M|      0    | Prefix Size |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              Lifetime                         |  Preference   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                        Identifier IPv6 address per link by concatenating an 80-bit pre-
   fix with the IEEE 802 address as follows:

      |              80 bits                  |      48 bits           |
      +---------------------------------------+------------------------+
      |              prefix                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Extension        As in [3]

      Length           As in [3]

      C                As in [3]

      A                Autonomous Mode

                       Form an    IEEE 802 address using prefix of advertised
                       identifier.

      M                Administered Mode

                       Use DHCPv6 to autoconfigure other information.

      Prefix Size      Number of bits    |
      +----------------------------------------------------------------+

   In the case of identifier defining a link-local prefix, the
                       routing prefix for this link

      Preference       As in [3]

      Identifier       One is well-defined[1].

   The prefixes of IPv6 unicast addresses other types of this interface

      This extension is found in Router Advertisements.

8. addresses need to be configured.

7.  REFERENCES

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

   [2]  W. A. Simpson, "IPv6 Neighbor Discovery -- Processing", Internet
        Draft, January 1995, <draft-simpson-ipv6-discov-process-02.txt>

   [3]  W. A. Simpson,  T. Narten and E. Nordmark, "IPv6 Neighbor Discovery -- ICMP Message For-
        mats", Discovery", Internet
        Draft, January June 1995, <draft-simpson-ipv6-
        discov-formats-02.txt> <draft-ietf-ipngwg-discovery-00.txt>

Acknowledgements

The author would like to thank the members of both the IPNG and ADDRCONF
working groups for their input. In particular, thanks to Jim Bound,
Steve Deering 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