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

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

ADDRCONF Working Group                       Susan Thomson (Bellcore)
INTERNET-DRAFT                                       January 31, 1995
<draft-ietf-addrconf-ipv6-auto-00.txt>



                    IPv6 Address Autoconfiguration


Status of this Memo

   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.  A host can form an intra-link scope address
   autonomously based on information local to the host.  A host can form
   an inter-link scope address in two ways: either semi-autonomously,
   based on knowledge of subnet prefixes advertised by routers, or by
   using DHCPv6. All mechanisms rely on a host having a token per
   interface that is unique at least per subnet.  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. DHCPv6 is described elsewhere.








Expires July 31, 1995                                           [Page 1]


INTERNET-DRAFT          Address Configuration              January 1995


1.  INTRODUCTION


   An IPv6 host can autoconfigure two types of address:

   1.   an intra-link scope address,

   2.   an inter-link scope address.

   An intra-link scope address is autoconfigurable in the absence of a
   router.  An inter-link scope address is autoconfigurable only when a
   router is present on the link.

   There is only one way to form an intra-link scope address. On ini-
   tialization of an interface, a host forms an IPv6 intra-link scope
   address by concatenating a predefined intra-link scope prefix to a
   token that is unique per link.  Typically, the definition of the
   token is link-layer dependent. In the case of a host attached to an
   IEEE 802 network, for example, the token is the IEEE 802 address of
   the interface.

   There are two ways to form an inter-link scope 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] to a token that is
   unique per link. The other mechanism available to hosts is to use the
   IPv6 version of the Dynamic Host Configuration Protocol
   (DHCPv6)[IPv6-DHCP]. The choice of protocol to use is advertised by
   the router, and this choice is configurable by the system administra-
   tor.

   The first mechanism for forming an inter-link scope address is suit-
   able for environments where no administrative control is desired. It
   is a simple, efficient protocol designed for a very specific purpose:
   to make stateless address configuration very straightforward to use
   and implement.  DHCPv6 is a more complex protocol allowing for very
   flexible address assignment under the control of a system administra-
   tor. This protocol typically requires significant system management,
   including server and database configuration.

   This document describes the general host address autoconfiguration
   procedure in Section 2, and how a host forms an intra-link scope
   address and an inter-link scope address without using DHCPv6 in Sec-
   tions 3 and 4, respectively. The DHCPv6 protocol is specified else-
   where [IPv6-DHCP]. The scope of the document is limited to hosts



Expires July 31, 1995                                           [Page 2]


INTERNET-DRAFT          Address Configuration              January 1995


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














































Expires July 31, 1995                                           [Page 3]


INTERNET-DRAFT          Address Configuration              January 1995


2.  PROCEDURE FOR FORMING AND MAINTAINING ADDRESSES


   A host maintains a list of addresses per interface. At a minimum, the
   list includes the intra-link scope address, which the host can form
   autonomously whenever an interface is initialised. If a router is
   attached to the link, the list will also include inter-link scope
   addresses formed either from subnet prefixes advertised in router
   advertisements 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 the following configurable variables
   per interface:


   Address

      A valid IPv6 unicast address for this interface

      Default: None


   LifeTime:

      The length of time for which an address is valid in seconds.

      Default: Infinity


   An intra-link scope address and all manually configured addresses
   have their lifetimes set to infinity.

   A host may also allow the following variable to be configured by a
   system administrator per interface:


   Perform_Auto_Address

      If  TRUE, the host must perform address autoconfiguration process-
      ing.  Otherwise, the host performs no address autoconfiguration



Expires July 31, 1995                                           [Page 4]


INTERNET-DRAFT          Address Configuration              January 1995


      processing at all.

      Default: TRUE



2.2.  Router Configuration


   A router must be configurable by a system administrator so that the
   choice of mechanism used for host configuration of inter-link scope
   addresses can be controlled. Thus, a router must allow the following
   variable to be configured by a system administrator per interface:


   Perform_Auto_Address

      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 to advertise the same address autoconfiguration
   mode to hosts.



2.3.  Host Address Autoconfiguration Procedure


   A host must perform the following procedure for each interface when
   booting or whenever an interface needs to be initialised:


      When a host boots or at any time when a host has no address for an
      autoconfigurable interface, e.g. 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 specifies
      how a host forms an intra-link scope address.


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



Expires July 31, 1995                                           [Page 5]


INTERNET-DRAFT          Address Configuration              January 1995


   When a solicited or unsolicited Router Advertisement is received over
   an interface, the host must perform the following 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 the host must use DHCPv6 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 is
      performed at DHCPv6-specified times.) If DHCPv6 fails for any rea-
      son, the host falls back to using an intra-link scope address or a
      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 host forms the address) to DHCPv6, and vice
   versa.  The requirement during a changeover is that the system
   administrator must ensure that a DHCPv6 server is configured to hand
   out addresses that are unique per subnet, particularly with respect
   to addresses that hosts configure autonomously.  To avoid problems
   during a changeover, it is recommended that a DHCP server should use
   exactly the same algorithm to form a host address as that used in the
   autonomous mode, particularly when the subnet prefix used is the
   same.  Otherwise, further precautionary measures will need to be
   taken to ensure correct operation.

   To support the changeover from autonomous mode to DHCPv6 mode, DHCPv6
   should provide the ability for a host to specify in a request previ-
   ously configured inter-link addresses.  A DHCPv6 server can then
   validate, deprecate or forbid the use of the autonomously formed
   addresses.

   Changing from DHCPv6 mode to autonomous mode is somewhat tricky.
   Normal autonomous mode processing should support the changeover from
   DHCPv6 mode to autonomous mode assuming the above recommendation is
   followed.  DHCPv6-assigned  addresses can be validated or deprecated
   as a normal part of host processing when an Address Prefix extension
   is heard in a Router Advertisement. The Drop Address Prefix can be
   used to invalidate DHCPv6 addresses, if desired.



Expires July 31, 1995                                           [Page 6]


INTERNET-DRAFT          Address Configuration              January 1995


3.  FORMING AN IEEE 802 IPv6 ADDRESS


   A host forms an IEEE 802 IPv6 address for an interface by concatenat-
   ing an 80-bit subnet prefix with the 48-bit IEEE 802 address of the
   interface as follows:



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



   In the case of an intra-link scope prefix, the subnet prefix is
   well-defined (TBD).

   In the case of an inter-link scope prefix, the subnet prefix is con-
   figurable (typically in a router).



























Expires July 31, 1995                                           [Page 7]


INTERNET-DRAFT          Address Configuration              January 1995


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 address configuration infor-
   mation in extensions of Router Advertisements.  Two extensions are
   defined for address configuration: the Address Prefix extension which
   advertises valid subnet prefixes to enable hosts to form their own
   addresses autonomously, and the Drop Address Prefix Extension which
   indicates that a subnet prefix (and hence an address formed from such
   a subnet prefix) is unrouteable.

      ED'S NOTE: I have used two new extensions here for illustrative
      purposes. It is likely the case that the Address Prefix Extension
      and the Drop Prefix Extension can be supported using the Routing
      Information Extensions and Change Prefix extensions defined in
      neighbor discovery, respectively.  The details of combining the
      semantics of the existing extensions with that of the following
      extensions still need to be worked out.




















Expires July 31, 1995                                           [Page 8]


INTERNET-DRAFT          Address Configuration              January 1995


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 to
                       configure besides address.

                       Use DHCPv6 to acquire these parameters.

      Prefix Size      Length of subnet prefix in bits.

      Subnet Prefix    Valid subnet prefix for this link.

      This extension is found in Router Advertisements.




4.1.3.  Drop Address Prefix Extension Format


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

      Extension        TBD

      Length           18



Expires July 31, 1995                                           [Page 9]


INTERNET-DRAFT          Address Configuration              January 1995


      Reserved         Must be zero

      Prefix Size      Length of subnet prefix in bits.

      Subnet Prefix    Subnet prefix for this link to be invalidated.

      This extension is found in Router Advertisements.




4.2.  Host Operation





4.2.1.  Processing 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



   For each address prefix advertised on an autoconfigurable interface,
   the host updates the list of addresses as follows:

   1.   If the prefix advertised matches the prefix of an address
        already in the list, then set the lifetime to infinity.

   2.   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 specifies how to form an inter-
        link scope address.

        Add this address to the list with an infinite lifetime.

   3.   All other autoconfigured inter-link addresses in the list have



Expires July 31, 1995                                          [Page 10]


INTERNET-DRAFT          Address Configuration              January 1995


        their lifetimes set to zero.

   An inter-link scope address is valid for as long as the subnet prefix
   is advertised in the appropriate extension of a Router Advertisement.
   A lifetime of infinity is used in the above algorithm to indicate
   this.  An address is deprecated when the subnet prefix is no longer
   advertised in the Address Prefix extension of the Router Advertise-
   ment, but the subnet prefix has not been explicitly invalidated by a
   Drop Address Prefix extension. An address is also deprecated when a
   new Router Advertisement is not heard before the old advertisement
   times out.  A lifetime of zero is used in the above algorithm to
   indicate that the address has been deprecated.

   A deprecated address is likely to be routable, although it is not
   guaranteed to be.  In the case where a subnet prefix that has been
   previously advertised is no longer advertised in a Router Advertise-
   ment (this assumes that a host is hearing Router Advertisements), a
   host should prepare for the time when the address becomes invalid: a
   host should stop using the address as a source address in communica-
   tions, if other addresses are available, and should stop advertising
   the address to others in DNS. Also, it should refuse to accept new
   connections to this address. However, the address may still be used
   to accept incoming datagrams and to avoid breaking existing connec-
   tions.  When an address becomes deprecated because no Router Adver-
   tisements are heard (because the router is down, for example), the
   host may still continue to use the address as normal until the next
   Router Advertisement is heard.

   Note that the 'M' bit of an address prefix extension may indicate to
   the host that it must use DHCPv6 to acquire other IPv6 configuration
   parameters (besides the address).



4.2.3.  Drop Address Prefix Extension Processing




   For each address prefix advertised, the host updates the list of
   addresses as follows:

   1.   If the prefix advertised matches the prefix of an address
        already in the list, then remove address from list.




Expires July 31, 1995                                          [Page 11]


INTERNET-DRAFT          Address Configuration              January 1995


   When an address is invalidated, it should no longer be used at all in
   communications since the subnet prefix is no longer routable.



5.  TRANSITION IMPLICATIONS


   IPv4-compatible IPv6 addresses are required by IPv6 hosts for the
   following purposes in the SIT scheme[IPv6-TRANS]: 1) to communicate
   off a link when an IPv6 neighboring router is not present on the link
   and 2) to communicate with IPv4-only hosts.

   In order that dual IPv4/IPv6 hosts can communicate using IPv6 without
   the presence of an IPv6 neighboring router, such a host should be
   able to form an IPv4-compatible IPv6 address autonomously. This is
   done by concatenating the well-defined IPv4-compatibility prefix to
   the host's IPv4 address. (It is not defined here how the host gets an
   IPv4 address; the IPv4 address may have been manually configured or
   autoconfigured using BOOTP, DHCP[RFC1531],etc).  An IPv4-compatible
   IPv6 address should be formed on an interface if no Router Advertise-
   ment is heard within a reasonable timeframe.

   On hearing an IPv6 Router Advertisement, however, the host must carry
   out the IPv6 address autoconfiguration procedure as normal.  In the
   case where the router advertises subnet prefixes for autoconfigura-
   tion purposes, it is possible to tell from the value of the subnet
   prefix advertised what  form of address is to be used.  The subnet
   prefix advertised may contain the IPv4-compatibility prefix in which
   case the IPv4-compatible form of the address is used. Otherwise, an
   IPv6-only address must be formed to replace any IPv4-compatible
   address previously formed as described in Section 3.



6.  SECURITY CONSIDERATIONS


   To be completed.









Expires July 31, 1995                                          [Page 12]


INTERNET-DRAFT          Address Configuration              January 1995


7.  APPENDIX - UNIQUENESS OF HOST TOKENS


   One of the basic assumptions of the autoconfiguration schemes out-
   lined in this memo 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 may
   have the same link layer address because of an assignment error, in
   which case the resulting IPv6 addresses will not be unique. There is
   no automatic detection of such occurrences. The 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 may occur 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
   addresses only on all interfaces.  It is imperative that hosts have
   interface tokens that are unique across both links, which is not true
   if a host token is defined to be a link layer address and the 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 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
   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 address of an
   offending host.
















Expires July 31, 1995                                          [Page 13]


INTERNET-DRAFT          Address Configuration              January 1995


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 for
        IPv6 Hosts and Routers", Internet Draft, November 1994, <draft-
        gilligan-ipv6-trans-mech-00.txt>

   [IPv6-SPEC]
        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]
        W. A. Simpson, "IPv6 Neighbor Discovery -- ICMP Message For-
        mats", Internet Draft, November 1994, <draft-simpson-ipv6-
        discov-formats-01.txt>

   [IPv6-DISC-PROC]
        W. A. Simpson, "IPv6 Neighbor Discovery -- Processing", Internet
        Draft, November 1994, <draft-simpson-ipv6-discov-process-01.txt>

   [IPv6-DHCP]
        J. Bound, Y. Rekhter and S. Thomson, Internet Draft in progress.


Acknowledgements


The author would like to thank the members of both the IPNG and ADDRCONF
working groups for their input.





Expires July 31, 1995                                          [Page 14]


INTERNET-DRAFT          Address Configuration              January 1995


Author's Addresses


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

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





































Expires July 31, 1995                                          [Page 15]


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