ADDRCONF Working Group                        Susan Thomson (Bellcore)

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

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

               IPv6 Stateless Address Autoconfiguration

Status of this Memo

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

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

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

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

Abstract

   This document specifies how a host autoconfigures one or more
   addresses per interface. stateless address autoconfiguration.  A host
   can form an intra-link scope a link-local address autonomously based on information local
   to the host.  A host can form an inter-link scope address in two
   ways: either semi-autonomously, autonomously, based on knowledge of subnet prefixes advertised by routers,
   or by using DHCPv6. the IPv6 version of the Dynamic Host Configuration
   Protocol(DHCPv6). All mechanisms rely on a host having a token per
   interface that
   is unique at least per subnet. link.  This document specifies how a host
   forms an intra-link scope address autonomously
   and an inter-link scope address semi-autonomously using IEEE 802
   tokens to identify each interface. addresses autonomously.  DHCPv6 is described elsewhere.

1.  INTRODUCTION

   An IPv6 host may have multiple addresses per interface. The addresses
   can autoconfigure two types have one of address: three scopes:

   1.   an intra-link scope   a link-local address,

   2.   an inter-link scope   a site-local address, and

   3.   a global address.

   An intra-link scope

   All three address is autoconfigurable in the absence of scopes can be autoconfigured.  A host can autocon-
   figure a
   router.  An inter-link scope link-local address autonomously. A host can autoconfigure a
   site-local or global address is autoconfigurable only when a router or a DHCPv6 server is
   present on the link.

   There is only one way to form an intra-link scope a link-local address. On ini-
   tialization initialization
   of an interface, a host forms such an IPv6 intra-link scope address by concatenating a predefined intra-link scope prefix
   well-known link-local prefix[1] to a token that is unique per link.  Typically, the
   The definition of the
   token is link-layer dependent. In tokens used are link-dependent.  For example,
   in the case of a host  attached to an link that uses IEEE 802 network, for example,
   addresses, the token is the IEEE 802 address of the interface.

   There are two ways to form an inter-link scope a site-local or global address. In the
   first mechanism, a host forms an IPv6 inter-link scope address by con-
   catenating a network prefix advertised in a Router
   Advertisement[IPv6-DISC-PROC,IPv6-DISC-PROC] Advertisement[2,3]
   to a token that is unique per link. The other mechanism available to hosts is to use the
   IPv6 version of  Like the Dynamic Host Configuration Protocol
   (DHCPv6)[IPv6-DHCP]. The choice of protocol to use is advertised by link-local address, the router, and this choice
   token is configurable by the system administra-
   tor.

   The first defined to be link-layer dependent.  This mechanism for
   forming an inter-link scope a site-local or global address is suit-
   able suitable for environments
   where no administrative control is desired. It is a simple, efficient simple protocol
   designed for a very specific purpose: to make stateless address configuration con-
   figuration very straightforward to use and implement.

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

   This document describes the general host address autoconfiguration
   procedure

   The choice of mechanism to use in Section 2, and how a host forms an intra-link scope
   address and forming an inter-link scope address without using DHCPv6 in Sec-
   tions 3
   is advertised by a router, if present, and 4, respectively. The DHCPv6 protocol this choice is specified else-
   where [IPv6-DHCP]. The scope of the configur-
   able by a system administrator.

   This document is limited to hosts
   attached to IEEE 802 networks. The effect of the transition scheme on
   the address autoconfiguration procedure is discussed in Section 5.

2.  PROCEDURE FOR FORMING AND MAINTAINING ADDRESSES

   A describes how a host maintains forms a list of link-local address and one
   or more site-local or global addresses per interface. At autonomously. It also speci-
   fies how a minimum, the
   list includes the intra-link scope address, which the host can determines which mechanism to use to form
   autonomously whenever an interface is initialised. If a router is
   attached to the link, the list will also include inter-link inter-
   link scope
   addresses formed either from subnet prefixes advertised in router
   advertisements address: the autonomous (stateless) approach or by making requests to DHCPv6. Inter-link scope
   addresses may also be manually configured.

2.1.  Host Configuration

   A host must maintain a list of
   Section 2 describes the following configurable variables
   per interface:

   Address

      A valid IPv6 unicast router's role in address for this interface

      Default: None

   LifeTime: autoconfiguration
   and Section 3 the host's role.

2.  ROUTER BEHAVIOR

   The length of time for which an stateless address is valid autoconfiguration mechanism relies on the
   router discovery mechanism specified in seconds.

      Default: Infinity

   An intra-link scope address and all manually configured [2,3] for forming addresses
   have their lifetimes set to infinity.

   A host may also allow the following variable to be
   with site-local or global scope.  If configured by to do so, routers
   advertise prefix information in periodic Router Advertisements.  The
   prefixes are contained in Prefix-Information extensions of a
   system administrator per interface:

   Perform_Auto_Address

      If  TRUE, Router
   Advertisement. Each Prefix-Information extension indicates whether
   the host must perform prefix can be used for autonomous address autoconfiguration process-
      ing.  Otherwise, and,
   if so, for how long the host performs no resulting address autoconfiguration
      processing at all.

      Default: TRUE

2.2.  Router Configuration

   A router must be configurable by a system administrator so is valid. Note that the
   choice
   lifetime of mechanism the address is defined separately from that of the Router
   Advertisement itself (other information is advertised in the adver-
   tisement which has different lifetime requirements).  The extension
   also explicitly indicates to hosts whether DHCPv6 is required to be
   used for host since it is possible 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 the message formats in [3].

   DISCUSSION: An alternative approach is to advertise address confi-
   guration information in a separate advertisement entirely. This would
   be somewhat cleaner since the lifetime of inter-link scope
   addresses can the advertisement would
   then be controlled. Thus, a router must allow that of the following
   variable information advertised. On the other hand, having
   two types of router advertisements would mean that prefix information
   is advertised redundantly, and 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 configured by a system administrator configurable as follows.

   For each of the IPv6 unicast addresses per interface:

   Perform_Auto_Address

      Autonomous Flag
         If and only if TRUE, the router must send an Address Prefix exten-
      sion in every Router Advertisement.

      Default: TRUE

   All router interfaces advertising a given subnet prefix on a link
   must be configured length is to advertise be advertised for
         the same purposes of autonomous address autoconfiguration
   mode to hosts.

2.3.  Host Address Autoconfiguration Procedure

   A configuration.

         Default: TRUE

   For each interface:

      Administered Flag

         If and only if TRUE, the host must perform autoconfigure other confi-
         guration information using DHCPv6. Only valid in extensions
         with the following procedure for each interface when
   booting or whenever an interface needs Autonomous Flag set to be initialised:

      When a host boots or at any time TRUE.

         Default: FALSE

      Address_Advertisement_Interval

         The time allowed between sending unsolicited Address Advertise-
         ments from 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 in the Lifetime field 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
   to advertise the same autoconfiguration mode to hosts.

2.2.  Processing

   A router MUST advertise address autoconfiguration information in a
   Prefix Information Extension of a Router Advertisement. The values of
   the Autonomous and Administered flags are advertised along with
   Address_Lifetime.  The address configuration information need not be
   advertised in each Router Advertisement. It must be sent (almost)
   periodically in a Router Advertisement at an interval of approxi-
   mately Address_Advertisement_Interval.

   Address  configuration information must also be sent in the first few
   Router Advertisements after startup or enabling of an interface (up
   to MAX_INITIAL_ADVERTISEMENTS) and in a Router Advertisement that is
   sent in response to a Router Solicitation.

   Address  configuration information may also be sent in a Router
   Advertisement due to actions taken by system management, in particu-
   lar, when the Address_Lifetime of a prefix is set to zero, e.g.
   because the link is to be renumbered. In this case, a Prefix-
   Information extension must be transmitted in 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 of 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 a router is
   attached to the link or DHCPv6 server is available, the list may also
   include site-local or global addresses formed either from subnet pre-
   fixes advertised in Router Advertisements or by making requests using
   DHCPv6. Addresses may also be manually configured. Note there may be
   multiple site-local or global addresses autoconfigured per interface.

   A host must maintain a list of the following configurable variables
   per interface:

   Address

      A valid IPv6 unicast address for this interface

      Default: None

   Prefix Length

      The length of the prefix in bits. Prefix length semantics are
      specified in [2].

   A host must also allow the following variable to be configured per
   interface:

   Perform_Auto_Config

      If and only if TRUE, the host must perform address autoconfigura-
      tion processing.

      Default: TRUE

3.2.  Host Initialization Behavior

   A host must perform the following autoconfiguration procedure when-
   ever an interface needs to be initialised:

      When a host has no address for an
      autoconfigurable interface, 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 intra-link
      scope and adds it to the list of addresses. Section 3 link-local scope.  Appendix A specifies how a host forms an intra-link scope address.

      The host must send
      that is attached to a Router Solicitation so link that inter-link scope uses IEEE 802 addresses can be formed (or verified) as soon as possible.

   When forms a solicited or unsolicited Router Advertisement is received over
   an interface, the host must perform
      link-local address.

      Before adding the following link-local address configura-
   tion processing:

      If an Address Prefix extension exists, the host forms or verifies
      its inter-link addresses autonomously as specified in Section 4.

      Otherwise, the implication is that a valid address to the host must use DHCPv6
      list of addresses for
      address autoconfiguration. If no address exists on the interface, the host must initiate a request to a DHCPv6 server to acquire a
      new address. (Verification and renewal of existing addresses SHOULD verify that
      the address is
      performed at DHCPv6-specified times.) If DHCPv6 fails indeed unique. The procedure for any rea-
      son, the host falls back to using validating an intra-link scope
      address or a is described in Section X. A host SHOULD also validate any
      manually configured inter-link scope address until a DHCPv6 server
      request is successful.

   Note that the above procedure should continue to operate when a sys-
   tem administrator decides to change the autoconfiguration mode from
   the autonomous mode (the addresses this way too.

      The host forms solicits a Router Advertisement using one or more Router
      Solicitations, if no Router Advertisements have been heard in the address) to DHCPv6, and vice
   versa.
      interface. The requirement during a changeover procedure for sending Router Solicitations is that
      specified in [2].

      If no Router Advertisement is heard after sending
      MAX_SOLICITATIONS and waiting Router_Solicitation_Interval after
      each as specified in Sending Router Solicitations in [2], the system
   administrator host
      must ensure that determine whether a DHCPv6 server is configured present and whether any
      configuration information needs to hand
   out addresses that are unique per subnet, particularly with respect be acquired.  This is to addresses that hosts configure autonomously.  To avoid problems
   during cater
      for a changeover, it is recommended that routerless topology which has a DHCP server should use
   exactly the same algorithm to form DHCPv6 server. Once a host address as that used in the
   autonomous mode, particularly when the subnet prefix used router
      is the
   same.  Otherwise, further precautionary measures will need to be
   taken to ensure correct operation.

   To support the changeover from autonomous mode added to DHCPv6 mode, DHCPv6
   should provide the ability for network, however, a host MUST use Router Adver-
      tisements to specify in a request previ-
   ously configured inter-link addresses.  A DHCPv6 server can then
   validate, deprecate or forbid determine the autoconfiguration mode in use of as
      described in the autonomously formed
   addresses.

   Changing from DHCPv6 mode to autonomous mode is somewhat tricky.
   Normal autonomous mode section on Router Advertisement Processing.

3.3.  Router Advertisement Processing

   Router Advertisement processing should support is specified in [2] and the changeover from
   DHCPv6 mode message
   format in [3].  In addition to autonomous mode assuming this processing, the above recommendation is
   followed.  DHCPv6-assigned  addresses can be validated or deprecated
   as a normal part of host MUST perform
   the following address configuration processing when a solicited or
   unsolicited Router Advertisement is received over an Address Prefix interface:

   For each Prefix-Information extension
   is heard in a the Router Advertisement. The Drop Address Prefix can be
   used to invalidate DHCPv6 addresses, if desired.

3.  FORMING AN IEEE 802 IPv6 ADDRESS

   A host forms an IEEE 802 IPv6 address for an interface Advertisement:
   (The format of the Prefix-Information extension as amended by concatenat-
   ing an 80-bit subnet prefix with this
   draft for autoconfiguration purposes is specified in Appendix C):

      The host silently ignores the 48-bit IEEE 802 address extension for the purposes of auto-
      configuration if the Perform_Auto_Config flag for the interface as follows:

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

   In is
      FALSE.

      Otherwise, the case of an intra-link scope prefix, host checks the subnet prefix autoconfiguration mode bits.

      If only the Autonomous flag is
   well-defined (TBD).

   In set in the case of an inter-link scope prefix, Prefix-Information
      extension, the subnet prefix is con-
   figurable (typically host forms or verifies a site-local or global
      address as specified below.

      If both the Autonomous and Administered flags are set in the
      Prefix-Information extension, the host forms or verifies a router).

4.  FORMING INTER-LINK SCOPE IPv6 ADDRESSES AUTONOMOUSLY

4.1.  Router Operation

4.1.1.  Sending Router Advertisements with Address Extensions

   A router may be configured to advertise site-
      local or global address configuration infor-
   mation as specified below and uses or continues
      using DHCPv6 for other autoconfiguration.

      Otherwise, the host silently ignores the extension for the pur-
      poses of autonomous autoconfiguration.

   If none of the prefixes advertised in extensions of the Router Advertisements.  Two extensions are
   defined Adver-
   tisement have the Autonomous flag set, then the host uses or contin-
   ues using DHCPv6 for address configuration: autoconfiguration.

   Note that the Address Prefix extension which
   advertises valid subnet prefixes above procedure should continue to enable hosts operate when a sys-
   tem administrator decides to form their own
   addresses autonomously, change the autoconfiguration mode from
   the autonomous mode to DHCPv6, and vice versa. The host should keep
   track of the Drop Address Prefix Extension which
   indicates current autoconfiguration mode, so that it can detect
   when there is a subnet prefix (and hence an address formed from such change.  The system administrator must ensure that,
   during a subnet prefix) changeover, a DHCPv6 server is unrouteable.

      ED'S NOTE: I configured to hand out
   addresses that are unique per link, particularly with respect to
   addresses that hosts have used two new extensions here for illustrative
      purposes. It configured autonomously and which may not
   yet be invalidated.  To avoid problems during a changeover, it is likely the case
   recommended that a DHCP server should use exactly the Address Prefix Extension
      and the Drop Prefix Extension can be supported using the Routing
      Information Extensions and Change Prefix extensions defined same algorithm
   to form a host address as that used in
      neighbor discovery, respectively.  The details of combining the
      semantics of autonomous mode when the existing extensions with that of
   prefix is the following
      extensions still need to be worked out.

4.1.2.  Address Prefix Extension Format

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Extension   |    Length     |  Reserved     |M| Prefix Size |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Subnet Prefix                              |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Extension        TBD

      Length           18

      Reserved         Must be zero

      M                When set, indicates more IPv6 parameters same. It is also important to
                       configure besides address.

                       Use ensure that a DHCPv6
   server is configured to acquire these parameters.

      Prefix Size      Length of subnet prefix in bits.

      Subnet Prefix    Valid subnet prefix for this link.

      This extension hand out addresses only to those hosts that
   it should, since, if a DHCPv6 server is found in Router Advertisements.

4.1.3.  Drop Address Prefix Extension Format

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Extension   |    Length     |  Reserved     |   Prefix Size |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Subnet Prefix                              |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Extension        TBD

      Length           18
      Reserved         Must be zero

      Prefix Size      Length of subnet prefix in bits.

      Subnet Prefix    Subnet prefix present on a link, hosts may
   request the server for this link addresses (even if the network is configured
   to be invalidated.

      This extension is found in Router Advertisements.

4.2.  Host Operation

4.2.1.  Processing autonomous mode) when Router Advertisements with Address Extensions

   On hearing a Router Advertisement on an interface, a host checks for
   an Address Prefix extension and a Drop Address Prefix extension.  A
   host processes an Address Prefix extension as described in Section
   4.2.2 below and a Drop Address Prefix extension as in Section 4.2.3.

4.2.2.  Address Prefix Extension Processing are not heard
   because the router is down.

   For each address prefix advertised on Prefix-Information extension received over an autoconfigurable autoconfigur-
   able interface, the host updates the address list of addresses as follows:

   1. follows when the
   Autonomous flag is set:

   a)   If the prefix advertised matches the prefix of an autoconfigured
        address already in the list, then set a timer to that of the
        lifetime to infinity.

   2. specified in the extension.  Note there is no timer
        associated with 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 inter-link scope address using this network
        prefix. Section 3 Appendix A specifies how to form an inter-
        link scope address. address for hosts
        that have IEEE 802 tokens. The extension is ignored if the pre-
        fix is not the right length for forming an address as specified
        in Appendix A.

        Add this address to the list with an infinite lifetime.

   3.   All other autoconfigured inter-link addresses in the list have
        their lifetimes a timer set to zero. that of the
        lifetime specified in the extension.

3.3.1.  Address Deprecation and Invalidation

   An inter-link scope address is valid for as long as until the subnet prefix
   is advertised in timer expires.

   When the appropriate extension of a Router Advertisement.
   A lifetime of infinity an address expires, an address is said to be
   deprecated.  In general, a deprecated address should no longer be
   used in new communications, but may be used in existing communica-
   tions.

   In particular, the above algorithm internetworking layer should not select a
   deprecated address as a source address in new communications. How-
   ever, a deprecated address should be allowed to indicate
   this.  An 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.

   The internetworking layer must continue to accept datagrams destined
   to a deprecated address. The transport layer 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 the subnet prefix is no longer
   advertised source address used in communications is deprecated as long
   as the Address Prefix extension of host has a valid alternative address. Also, a deprecated
   address should be removed from the Router Advertise-
   ment, but Domain Name System (DNS). This may
   be done by the host itself, given a DNS dynamic update protocol and
   sufficient authority, or it may be done on the subnet prefix has not been explicitly invalidated by host's behalf.

   The time at which a
   Drop Address Prefix extension. An address is also deprecated when a
   new Router Advertisement is not heard before address becomes invalid (removed from
   the old advertisement
   times out.  A lifetime list of zero addresses per interface) is used in dependent on the above algorithm to
   indicate that storage
   available for the address has been deprecated. list and is thus implementation-dependent.
   A host should keep a deprecated address until it is likely to be routable, although no longer in use,
   i.e. it is not
   guaranteed to be.  In the case where a subnet prefix that has been
   previously advertised no longer being used in current communications such as an
   existing TCP connection, and it is no longer advertised stored or cached in the
   Domain Name System.  After this point, a deprecated address may be
   removed from the address list.

   If Router Advertise-
   ment (this assumes that a Advertisements stop being heard and all autoconfigured
   inter-link scope addresses become deprecated, then the host is hearing Router Advertisements), must
   determine whether a
   host should prepare DHCPv6 server is available for the time when the address becomes invalid: a autoconfi-
   guration. The host should stop using follows the address same procedure as a source address described in communica-
   tions, if other addresses the
   initialisation procedure in this case.

3.4.  Detecting Duplicate IPv6 Addresses

   One of the basic assumptions of the autoconfiguration schemes out-
   lined in this document is that the host token is at least unique per
   link. Tokens are available, defined to be link-layer dependent, and should stop advertising the token is
   the link layer address to others in DNS. Also, most cases. In practice, two hosts on the
   same link may have the same link layer address because of an assign-
   ment error, in which case the resulting IPv6 addresses will not be
   unique. For this reason, it should refuse is prudent to accept new
   connections check that the addresses
   are indeed unique.  In IPv6, it is only necessary to this address. However, check that one
   of the autoconfigured addresses is unique since the address may still be same token is
   used to accept incoming datagrams form all addresses and the prefixes used to avoid breaking existing connec-
   tions.  When an address becomes deprecated because no Router Adver-
   tisements are heard (because form the router
   addresses are all unique (the autoconfiguration procedure should
   ensure this). It is down, for example), recommended that the
   host may still continue to use link-local address be the
   address checked since it is formed once and first, on initialisation.

   The procedures use General Solicitations and Advertisements specified
   in [2,3] as normal until modified below.  To validate an address, the next
   Router Advertisement is heard.

   Note that node sends a
   General Solicitation with the 'M' bit source and destination set to that of an
   the address prefix extension may indicate to be checked.  The node should specify an appropriate
   Media-Access extension.

   On receiving a General Solicitation with a source address that is the
   same as the destination address and apparently from itself, a host that it
   must use DHCPv6 respond with a General Advertisement. The General Advertisement
   is sent to acquire other IPv6 configuration
   parameters (besides the address).

4.2.3.  Drop All-Nodes Multicast Address Prefix Extension Processing

   For each address prefix advertised, with intra-link scope.
   The Media-Access extension from the host updates General Solicitation MUST NOT be
   retained.

   After sending a General Solicitation, the list node waits for a period of
   addresses as follows:

   1.
   General_Solicitation_Interval. If a General Advertisement is not
   received in response to the prefix advertised matches General Solicitation within the prefix of an address
        already in interval,
   the list, then remove address from list.

   When an address is invalidated, it should no longer considered to be used at all in
   communications since the subnet prefix validated. If a General Advertisement
   is no longer routable.

5.  TRANSITION IMPLICATIONS

   IPv4-compatible IPv6 addresses are required by IPv6 hosts for received with a source address the
   following purposes in same as the SIT scheme[IPv6-TRANS]: 1) to communicate
   off a link when address being vali-
   dated, it must cease operation on that interface and indicate an IPv6 neighboring router
   appropriate error.

   Note that this mechanism is not present on the link completely reliable, and 2) to communicate with IPv4-only hosts.

   In order so it is
   possible that dual IPv4/IPv6 hosts can communicate using IPv6 without
   the presence of an IPv6 neighboring router, such duplicate addresses will still exist. If a host should be
   able to form an IPv4-compatible IPv6 duplicate
   address autonomously. This is
   done by concatenating discovered, the well-defined IPv4-compatibility prefix host will need to
   the host's IPv4 address. (It be configured with a new
   token, or if this is not defined here how the host gets an
   IPv4 address; possible, the IPv4 address may have been manually configured or
   autoconfigured using BOOTP, DHCP[RFC1531],etc).  An IPv4-compatible IPv6 address should addresses will need to be formed on an interface if no Router Advertise-
   ment
   manually configured.

   DISCUSSION: There is heard within a reasonable timeframe.

   On hearing an IPv6 Router Advertisement, however, problem with a race condition when two (or
   more) nodes boot up at the host must carry same time. Both will send out a General
   Solicitation, receive no advertisement and assume all is well.  A fix
   may be to have a node process General Solicitations during the IPv6 address autoconfiguration procedure as normal.  In the
   case where the router advertises subnet prefixes vali-
   dation stage and flag an error if it sees  more than one General Sol-
   icitation for autoconfigura-
   tion purposes, an address it is possible to tell from in the value process of validating.

   DISCUSSION: Should the subnet
   prefix advertised what  form of address solicitations be dithered? Note that randomis-
   ing based on the token (link-layer address) only does not help if the
   token is to not unique.

4.  SECURITY CONSIDERATIONS

   To be used. completed.

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

   The subnet
   prefix advertised may contain token for an interface on an IEEE 802 link or any link that uses
   IEEE 802 addressing, such as FDDI, is the IPv4-compatibility prefix 48-bit IEEE 802 address in which
   case
   canonical format, i.e. the IPv4-compatible form Individual/Group  bit is the low-order bit
   of the address is used. Otherwise, furst byte.

   A host forms an
   IPv6-only IPv6 address must be formed to replace any IPv4-compatible per link by concatenating an 80-bit pre-
   fix with the IEEE 802 address previously formed as described in Section 3.

6.  SECURITY CONSIDERATIONS

   To 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 completed.

7. configured.

6.  APPENDIX - B: UNIQUENESS OF HOST TOKENS

   One

   As has been mentioned, one of the basic assumptions of the autoconfiguration schemes out-
   lined autoconfi-
   guration scheme outlined in this memo document is that the host token is
   at least unique per
   link. The only feasible choice for the token is the link layer
   address in most cases. In practice, two hosts on the same link link, but that tokens may
   have the same link layer address because of an assignment error, in
   which case the resulting IPv6 addresses will not always be unique. There unique,
   in practice.  A host should check that an address is
   no automatic detection of such occurrences. The unique using the
   scheme proposed in this document. Since this is not completely reli-
   able, system administrators may also use of DNS to regis-
   ter name to address mappings may help system administrators detect when such
   a problem occurs since two different hosts will register the same
   IPv6 address.

   The above problem

   Duplicate IPv6 addresses may occur as a result of non-unique tokens
   in any particular network topology.  One particular scenario deserves
   further mention though. Consider a topology consisting of two links
   with singly-homed hosts attached to each, a multi-homed host attached
   to both and no router. In this case, because no router is present,
   hosts will form intra-link link-local addresses only on all interfaces.  It is
   imperative that hosts have interface tokens that are unique across
   both links, which is links. However, this may not be true
   if a host for two reasons: the links
   may be of different types and thus the tokens used may not be unique.
   Also, the token may not be unique if it is defined to be a link layer
   address and the link-layer address is only defined to be unique per
   link as is true in some cases.  Strictly speaking, we require that
   host tokens are globally unique to ensure correct operation in these
   topologies.  In practice, link layer addresses are frequently globally glo-
   bally unique and so the uniqueness problems in this scenario should
   not be appreciably worse than in more traditional topologies as
   described above.  If two intra-link link-local scope addresses are detected to
   be the same in this scenario, there are two solutions: one is to make
   the multihomed host a router, the other is to manually configure the intra-link scope
   link-local address of an offending host.

8.  REFERENCES

   [RFC1531]
        R. Droms, "Dynamic Host Configuration Protocol", RFC 1531, Buck-
        nell University, October 1993.

   [IPv6-TRANS]
        Robert E. Gilligan and E. Nordmark, "Transition Mechanisms

7.  APPENDIX C: Prefix-Information Extension

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Extension   |    Length     |C|A|M|      0    | Prefix Size |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              Lifetime                         |  Preference   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                        Identifier                             |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Extension        As in [3]

      Length           As in [3]

      C                As in [3]

      A                Autonomous Mode

                       Form an address using prefix of advertised
                       identifier.

      M                Administered Mode

                       Use DHCPv6 to autoconfigure other information.

      Prefix Size      Number of bits of identifier defining the
                       routing prefix for this link

      Preference       As in [3]

      Identifier       One of IPv6 Hosts and Routers", Internet Draft, November 1994, <draft-
        gilligan-ipv6-trans-mech-00.txt>

   [IPv6-SPEC] unicast addresses of this interface

      This extension is found in Router Advertisements.

8.  REFERENCES

   [1]  R. Hinden, "Internet Protocol Version 6 (IPv6) Specification",
        Internet Draft, February 1994, <draft-hinden-ipng-ipv6-spec-
        00.txt>

   [IPv6-ROAD]

   [IPv6-ICMP]
        A. Conta and S. Deering, "ICMP and IGMP for IPv6", Internet
        Draft, September 1994, <draft-conta-ipv6-icmp-igmp-00.txt>

   [IPv6-DISC-FORM] March 1995, <draft-ietf-ipngwg-ipv6-addr-arch-
        01.txt>

   [2]  W. A. Simpson, "IPv6 Neighbor Discovery -- ICMP Message For-
        mats", Processing", Internet
        Draft, November 1994, <draft-simpson-ipv6-
        discov-formats-01.txt>

   [IPv6-DISC-PROC] January 1995, <draft-simpson-ipv6-discov-process-02.txt>

   [3]  W. A. Simpson, "IPv6 Neighbor Discovery -- Processing", ICMP Message For-
        mats", Internet Draft, November 1994, <draft-simpson-ipv6-discov-process-01.txt>

   [IPv6-DHCP]
        J. Bound, Y. Rekhter and S. Thomson, Internet Draft in progress. January 1995, <draft-simpson-ipv6-
        discov-formats-02.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 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