<draft-ietf-addrconf-ipv6-auto-02.txt>
ADDRCONF Working Group                        Susan Thomson (Bellcore)

<draft-ietf-addrconf-ipv6-auto-03.txt>

               IPv6 Stateless Address Autoconfiguration

Status of this Memo

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

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

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

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

Abstract

   In IPv6, there are two types of address autoconfiguration: stateless
   address autoconfiguration and stateful address configuration. In
   stateless address autoconfiguration, no state is maintained binding a
   particular host interface to a specific list of addresses. Rather, an
   address is formed algorithmically by concatenating the network prefix
   of the attached link to

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

1.  INTRODUCTION

   In IPv6, there are a host has two types of address autoconfiguration: stateless mechanisms available to form a global or
   site-local address autoconfiguration that require no manual configuration: the state-
   less method and the stateful address configuration. method.  In the stateless address autoconfiguration, method, no
   external state is maintained binding for the purpose of indicating to a
   particular host interface
   the list of addresses to use for an interface. Rather, a host forms a specific
   list of addresses. Rather, an
   interface address is formed  addresses algorithmically by concatenating each of the net-
   work prefix prefixes of the attached link to a host an interface token unique per
   link.  The interface token is defined to be link-dependent and may be
   the hardware address, for example.  In contrast, state is maintained
   in the stateful address configuration, state is maintained, typically by in a server. For
   example, the IPv6 Dynamic Host Configuration Protocol is an example
   of stateful address autoconfiguration.

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

   A host always uses desired, e.g.  corporate networks.

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

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

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

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

2.  OVERVIEW

   An  TERMINOLOGY

   node        - a device that implements IPv6.

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

   host may have multiple unicast addresses per interface[1].
   The addresses can have one of three scopes: a link-local scope,        - any node that is not a
   site-local scope, or router.

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

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

   neighbors   - nodes attached to autoconfigure the same link.

   interface   - a
   link-local address completely autonomously. In particular, node's attachment to a host link.

   packet      - an IPv6 header plus payload.

   link MTU    - the maximum transmission unit, i.e., maximum packet
                 size in octets, that can
   form a link-local address without be conveyed in one piece over
                 a router present on the link. A
   host is able to autoconfigure an inter-link scope

   target      - a node about which address only when resolution information is
                 sought, or a
   router node which is present on the link. The scope of the inter-link new first-hop when being
                 redirected.

   address
   formed depends on the prefix advertised on the link.

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

   unicast address
               - an interface, identifier for a host forms single interface. A packet sent
                 to a link-local unicast address is delivered to the interface
                 identified by concatenating that address.

   anycast address
               - an identifier for a well-known link-local prefix[1] set of interfaces (typically
                 belonging to a token that different nodes).  A packet sent to an
                 anycast address is
   unique per link.  The definition delivered to one of the tokens used are link-
   dependent.  For example, in interfaces
                 identified by that address (the "nearest" one,
                 according to the case routing protocols' measure of
                 distance).

   multicast address
               - an identifier for a host  attached set of interfaces (typically
                 belonging to different nodes). A packet sent to a link
   that uses IEEE 802 addresses, the token
                 multicast address is delivered to all interfaces
                 identified by that address.

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

   link-local address
               - an address asso-
   ciated with the interface.

   A host forms or updates an inter-link scope address on hearing prefix
   advertisements advertised by a router. A global or site-local address scope that is formed by concatenating a network prefix limited to
                 the locally attached link.

   site-local address
               - an address with a host token scope that is
   unique per link in the same way as described above.  The mechanism
   used limited to advertise network prefixes for the purposes of
                 local site.

   global address confi-
   guration is the same as
               - an address with unlimited scope.

   communication
               - any packet exchange between nodes that requires
                 or recommends that the address of each node used in Neighbor Discovery[2] for the
   purposes of prefix discovery.  Rather than specify two separate
   mechanisms to advertise
                 exchange remain the same prefix information, we use a single
   mechanism which requires hosts to perform both prefix discovery pro-
   cessing and address autoconfiguration processing on receiving a pre-
   fix advertisement. Note that, when prefixes are advertised, it is
   possible to indicate whether the prefixes are to be used for prefix
   discovery only, address autoconfiguration only or both.

   One of the goals of IPv6 address autoconfiguration is not only to be
   able to autoconfigure addresses on startup, but to be able to recon-
   figure addresses dynamically. Address reconfiguration ("renumbering")
   enables hosts to acquire new addresses and relinquish old addresses
   automatically. Old addresses may then be reused.  To enable hosts to
   renumber with minimal disruption duration of existing communications, prefixes the
                 packet exchange. Examples are advertised with two lifetimes: a TCP connection or a
                 UDP request-response.

   deprecation lifetime and an
   invalidation lifetime.  The deprecation lifetime
              - indicates when the time at which an address formed from a prefix must be deprecated. A deprecated address
   may continue to be used as a source address in existing
   communications, but should not no
                longer be used as a source address in new
                communications. The deprecation lifetime must be
                less than or equal to the invalidation lifetime
                of the address.

   invalidation lifetime
               - indicates when the time at which an address
   formed from a prefix is no longer valid and may be reused.  Invalid
                 identifies an interface or set of interfaces.
                 The invalidation lifetime must be greater than
                 or equal to the deprecation lifetime of the address.

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

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

   invalid address
              - an address whose invalidation lifetime has
                expired.

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

2.1.  Requirements

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

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

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

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

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

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

3.  CONCEPTUAL MODEL OF HOST BEHAVIOR

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

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

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

3.1.  Address Configuration

3.1.1.  Link-Local Address

   On initialization of an interface, a host must form a link-local
   address by concatenating a well-known link-local prefix[1] to an
   interface token that is unique per link.  The definition of the
   tokens used are link-dependent.  For example, in the case of a host
   attached to a link that uses IEEE 802 addresses, the token is the
   48-bit IEEE 802 link-layer address of the interface.  Tokens for a
   specific link are defined in link-specific IPv6 documents and are
   outside the scope of this document.

   Note that a host is able to autoconfigure a link-local address
   completely autonomously. In particular, a host can form a link-local
   address without a router present on the link.

3.1.2.  Global/Site-Local Address

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

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

3.2.  Address Reconfiguration

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

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

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

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

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

   The intention of the two lifetimes per address is to allow system
   administrators to specify a graceful transition period during
   renumbering. The purpose of the deprecation time is to indicate to
   the host to start using another (presumably longer lasting) address
   in new communications to minimise the risk of breaking communications
   when the old one times out. A system administrator and so should set the transition from old
   deprecation period long enough so that most, if not all, communica-
   tions have switched over to using the new addresses may be as quick (the deprecation and invalidation life-
   times are address by the same) or as slow as desired.

   One of time the basic assumptions old
   one becomes invalid. The length of stateless autoconfiguration is that the host token is at least unique per link.  However, in practice,
   host tokens are not always unique because of errors in assignment.
   Thus, it cannot deprecation period will be guaranteed
   environment-dependent as it depends on the expected length of commun-
   ications.

   The fact that IPv6 addresses formed from a host
   token are indeed unique among all hosts on have a link. Since duplicate
   IPv6 addresses are very difficult deprecation lifetime does not need to track down and debug, we specify
   a procedure for detecting duplicate addresses that hosts should use
   on initialising
   affect the implementation of applications, i.e.  an interface. Note that this procedure application is
   not com-
   pletely reliable, and so duplicate addresses may still exist. expected to react when an address it is using becomes deprecated.
   The
   procedure makes use purpose of Neighbor Solicitations and Advertisements[2]
   in a special-purpose way. Briefly, the deprecation lifetime is to help applications or
   networking software to select a host uses sufficiently long-lasting source
   address at the beginning of a Neighbor Solicita-
   tion new communication. The IP layer is
   expected to solicit provide a means for itself.  If it discovers that another host has upper layers or applications to
   select the most appropriate source address through receiving given a Neighbor Advertisement, the valida-
   tion check fails and the host ceases operation on that interface.
   Note that the host that is already using the address (presumably leg-
   itimately) continues unharmed, although it particular desti-
   nation.  An application may log a message choose to select the
   effect that it has received a solicitation for its own address.

   This document specifies router and host behavior related to stateless source address configuration and duplicate
   itself before starting a new communication or may leave the address detection in more detail
   unspecified, in which case the sections that follow.

3. upper networking layers will use the
   mechanism provided by the IP layer to choose a suitable address on
   the application's behalf.

4.  ROUTER BEHAVIOR SPECIFICATION

   The stateless address autoconfiguration mechanism relies on the pre-
   fix discovery mechanism specified in [2] for advertising network pre-
   fixes required for the formation of addresses with site-local or glo-
   bal scope.

   A prefix is advertised in a Prefix Information extension option of a Router
   Advertisement. The Prefix Information extension includes

   1.   the prefix and its length, flags itself

   2.   the prefix length

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

   4.   a flag indicating whether the prefix is to be used for stateless
        address configuration, and two
   lifetimes: autoconfiguration

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

   6    the invalidation lifetime.
   The Router Advertisement itself includes flags indicating whether
   stateful lifetime of the prefix for the purpose of
        address configuration should be invalidation. This field is also used by hosts and whether
   other configuration information (besides an address) needs to be con-
   figured. prefix
        discovery[2].

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

5.  HOST SPECIFICATION

   This section specifies host address configuration are specified below.

3.1. autoconfiguration behavior on
   receiving a Router Advertisement.

5.1.  Host Configuration Variables

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

   For each of

   A host SHOULD allow the prefixes following variable to be advertised in Prefix Information
   extensions configured per mul-
   ticast interface:

      Autonomous Flag

   Perform_Addr_Config

      If set, the prefix is being advertised for the purposes of host MUST use either stateless address configuration. or stateful mechanisms
      to configure global or site-local addresses and to acquire other
      configuration information as specified in this document.

      Default: TRUE

      Deprecation Lifetime

   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 value to be placed in host stores the Deprecation Lifetime field current value of
         Prefix Information extensions in Router Advertisements sent
         from the interface in seconds.

      Invalidation Lifetime

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

   For each advertising interface:

      Administered Flag Managed flag (M bit).
      If set, the host must autoconfigure addresses using stateful
         address autoconfiguration.

         Default: FALSE

      Other Flag

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

         Default: FALSE

   NOTE: All routers advertising a given prefix on a link MUST set all
   of the configuration variables use stateful address confi-
      guration to the same value.

4.  HOST BEHAVIOR

   Conceptually, a host maintains configure and maintain a list of site-local or global
      addresses per interface.
   Entries in

      Note that this does not mean that the list are created as stateful protocol is neces-
      sarily invoked each time a result of forming addresses from
   prefixes advertised in Prefix Information extensions of Router Adver-
   tisements.  Each entry in the list has two associated timers, a
   deprecation timer and an invalidation timer, which have values set
   according to lifetimes learned from the router advertisement. In
   addition, Advertisement arrives with the address list always includes M
      bit set.  The host uses the link-local address,
   which flag only to indicate whether the host forms autonomously whenever an interface
      stateful protocol is initial-
   ised. to be used to configure addresses. The deprecation and invalidation lifetimes of a link-local
   address are set state-
      ful protocol is enabled as soon as the Address Mode changes from
      FALSE to infinity.

   This section specifies host address autoconfiguration behavior on
   interface initialisation and on receiving a Router Advertisement.
   This section also specifies a host TRUE. The protocol is disabled as soon as the flag
      changes from TRUE to FALSE.  The actual times at which the proto-
      col is invoked, for attempting example, to verify
   that an address is not request a duplicate.

4.1.  Host Configuration Variables

   A list of addresses or
      renew a list of addresses, are specified by the protocol itself.

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

   Perform_Auto_Config

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

      Default: TRUE

4.2.  Router Advertisement Processing

   An "autoconfigurable" interface is one on which Router Advertisements
   are received Other Configuration flag
      and then sets the Perform_Auto_Config Other Configuration Mode flag is set.

   A host MUST perform to that in the following address configuration processing
   when a solicited or unsolicited
      Router Advertisement is received over
   an autoconfigurable interface:

   For each valid Router Advertisement: (O bit).  If the Administered flag new value is set, the host
      MUST use stateful auto-
      configuration autoconfiguration to acquire a list of site-local or global addresses
      per interface.

      If other configuration
      information besides the Other flag is set, address.

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

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

      -    If the prefix advertised matches the prefix of an autoconfig-
           ured
           autoconfigured address already in the list, then set the
           deprecation timer to that of the deprecation lifetime specified speci-
           fied in the extension and the invalidation timer to that of
           the invalida-
           tion invalidation lifetime.

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

      -    If the prefix advertised does not match the prefix of an
           address already in the list, then form an address using this
           network prefix. Appendix A specifies how prefix and the interface token. Definitions of the
           interface token to form an address
           for hosts that have IEEE 802 tokens. The extension be used on a specific link are documented
           elsewhere.

           If the prefix advertised is ignored
           if too short or too long to form a
           128-bit address, given the interface token, the prefix is not valid, e.g. it is not the right length
           for forming
           ignored and an address with the given host token. error is logged.

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

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

      Note that if the deprecation lifetime is zero, the address with
      that prefix is immediately deprecated. Similarly, if the invalida-
      tion lifetime is zero, the address with that prefix is immediately
      made invalid. (The invalidation lifetime is defined to be no less
      than the deprecation lifetime.) If the deprecation lifetime is
      infinity, the address is never deprecated. Similarly, if the
      invalidation lifetime is infinity, the address is never invali-
      dated. The value of infinity is defined in [2].

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

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

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

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

      To limit storage space required for the address list, a host may
      choose not to store all valid outgoing communications and deprecated addresses. Deprecated
      addresses that are is not recognised as
      a valid destination address in use by existing incoming communications should be
      discarded in favor since the
      address is defined to no longer identify the interface.

      On initialisation of valid addresses and deprecated addresses
      that are in use.

      If an interface, if a host determines that there
      are no IPv6 routers on a link,
      either on startup or during normal processing, a host MUST attempt to use stateful
      autoconfiguration to acquire addresses or and other configuration information if it is not already doing so.
      information.  This is needed to support networks with no IPv6
      routers.  The host deter-
      mines determines that there are no routers on the
      link after startup if no Router Advertisements are heard in the
      time that it would take to send MAX_ROUTER_SOLICITATIONs and wait
      for a response[2]. 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 link and Router
      Advertisements begin to be received, a host MUST start to use
      Router Advertisements in the normal way, and, in particular, use
      advertisements to determine whether stateless or stateful address
      configuration should be in use.

      Note that if a
      host does not receive Router Advertisements because of some error,
      e.g. all routers are down or there it is a network partition, possible for hosts
      will attempt to change get address information
      using both stateless and stateful protocols since both may be
      enabled at the same time. Even if only stateless address autocon-
      figuration mode is enabled, it is still possible for hosts to get
      information from stateless (assuming multiple sources since multiple routers may be
      advertising prefix information. The rules for handling this was is as
      follows: hosts accept the
      advertised mode) to stateful union of all information received using
      the stateless and stateful protocols. If different sources config-
      ure the same address, then back again when Router
      Advertisements start being heard. This means that if the stateful
      mode address is available, it should be configured correctly to serve only updated with the most
      recently advertised lifetime.

      It is also possible for hosts that it should, since hosts may attempt to use it, even
      if it is not the intention that they do so.

      A host must behave reasonably contain address information from
      different sources, when there is a change changing from one mechanism to the other,
      i.e.  when changing from stateless mode to the stateful mode, and vice
      versa. This can hap-
      pen because routers advertise a new configuration In this case, the rules are no different from above. If the
      newly enabled mode due to a
      deliberate change by a system administrator, or because of a
      change in topology, e.g. an IPv6 router is connected configured to or removed
      from hand out different addresses
      than the link.  It is possible and quite likely that during mode just disabled, then the
      change-over, a host will have contains the union of
      addresses autoconfigured using from both
      mechanisms. If sources until the addresses acquired configured using
      the two mechanisms are
      the same, then the new addresses should replace old protocol timeout.  If both the old and the
      aging semantics associated with the new mode apply.  If the
      addresses acquired using the two mechanisms modes are different, con-
      figured to hand out the same address, then the old addresses should be aged according to address is updated
      with the rules specified
      in most recently advertised lifetime. NOTE: The above
      assumes that the old configuration mode stateless and stateful modes have the new addresses should follow same life-
      time semantics.

6.  NODE SPECIFICATION

   This section specifies the rules of for forming a link-local address. It
   also specifies the new mode.

4.3.  Host Initialisation protocol to be used for duplicate address detec-
   tion.

6.1.  Forming a Link-Local Address

   A host node MUST have a link-local address.  A node forms a link-local
   address when whenever an autoconfigurable interface is initialised.  Appendix A specifies how a host that is attached to
   a link that uses IEEE 802 addresses forms  The method for forming
   a link-local address.

   Note that an address is link-dependent and is outside the scope of
   this document.

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

   -    The interface is initialized at system startup time.

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

   -    The system changes from being a router to being a host, by hav-
        ing its IP forwarding capability turned off temporary interface
        failure or after being temporarily disabled by system manage-
        ment.

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

   -

   The link-local address is highly likely to need to be one of the
   first events in the interface has its Perform_Auto_Config flag changed from
        FALSE initialisation process. Clearly, it
   must be formed before any duplicate detection processing is performed
   for this address (Section 6.2).  In hosts, a link-local address is
   also required before a  sends out a Router Solicitation, assuming the
   node chooses to TRUE.

4.4. do this[2]. This is because a solicitation is only
   sent if an advertisement has not yet been heard (and hence no non-
   link local address can be formed), and the unspecified address cannot
   be used as a source address in a Router Solicitation.

6.2.  Detecting Duplicate IPv6 Addresses

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

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

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

4.4.1.

6.2.1.  Soliciting Host Node Behavior

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

   Once the address is configured, the node sends a Neighbor Solicita-
   tion with a target address containing the address to be validated.
   The host source is set to the unspecified address and the destination is
   set to the solicited-node multicast address.  The Source Link Layer
   Address extension SHOULD NOT be sent (as it will be ignored by the
   destination node[2]).  Loopback of the Neighbor Solicitation MUST NOT
   be disabled.

   NOTE: If the Neighbor Solicitation is the first delays message to be sent
   from an interface on interface initialisation, the node should delay
   a random amount of time between 0 and
   DUPL_ADDRESS_DELAY MAX_INITIALIZATION_DELAY
   seconds before sending out a Neighbor Solicitation
   for the address. solicitation.  This serves to alleviate
   congestion when many hosts nodes start up on the link at the same time,
   such as after a power failure, and helps to avoid race conditions
   when more than one host node is trying to solicit for the same address at
   the same time. (It is recommended that hosts nodes include some unique
   value in the seed used to initialise their pseudo-random number generators. gen-
   erators. Note that using only the host node token as a unique value is not
   sufficient to avoid race conditions since the token cannot be relied
   upon to be unique. Although the randomization range is speci-
   fied specified in
   units of seconds, the actual randomly-chosen value should not be in units of whole seconds, but rather in units of the highest
   available timer resolution.)

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

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

   If after sending a solicitation, no advertisement Neighbor Advertisement is
   received from the target, the node SHOULD retransmit the solicitation
   at most every DUPL_ADDR_RETRANS_TIMER seconds until either an advertisement adver-
   tisement is received or the solicitation has been retransmitted
   MAX_DUPL_ADDR_RETRANS times. If an advertisement is received with a
   target address the same as the address being validated, validated in the time it
   takes to send and wait for MAX_DUPL_ADDR_RETRANS solicitations, it
   must cease
   operation on disable that interface and indicate an appropriate log a system management error.  If no
   such advertisement is received in response to within the Neighbor Solicita-
   tions sent, time specified, the address
   is considered to be valid.

4.4.2.

6.2.2.  Solicited Node Behavior

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

   A node must follow special rules when it receives a Neighbor Solici-
   tation for an address that it is in the process of validating. This
   is done to help avoid the race condition where more than one node is
   attempting to validate the address at the same time, i.e. each node
   sends out a Neighbor Solicitation and waits to hear a Neighbor Adver-
   tisement for the address, but no node actually sends an advertisement
   since the address has not yet been validated.

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

   NOTE: The above behavior is required because nodes send out Neighbor
   Solicitations for their own address which  with loopback enabled. Thus, a
   node will always receive at least one solicitation for its own
   address.  However, there is no way for the
   same as the address node to be validated, and a determine, in gen-
   eral, whether the solicitation comes from itself or another node
   since the source address that of the packet is the unspecified address. (Note that any solicitation that is likely to be
   a loopback solicitation should be ignored too as mentioned in Hence, the
   above section.) If rules specify that a solicitation duplicate address is received from detected only if the unspecified
   address,
   node receives more than one solicitation for the host must cease operation on that interface and indicate
   an appropriate error. address.

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

4.4.3.

6.2.3.  Constants

   DUPL_ADDR_DELAY                     4 seconds (XX)
   DUPL_ADDR_IGNORE_TIMER              0.1

   MAX_INITIALIZATION_DELAY            3 seconds
   DUPL_ADDR_RETRANS_TIMER             4             3 seconds  (XX)
   MAX_DUPL_ADDR_RETRANS               1 transmission (XX)

5.

7.  SECURITY CONSIDERATIONS

   To be 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 the 48-bit IEEE 802 address in
   canonical format, i.e. the Individual/Group  bit is the low-order bit
   of the furst byte.

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

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

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

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

7.

8.  REFERENCES

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

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

Acknowledgements

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

Author's Addresses

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

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