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]
