draft-ietf-addrconf-ipv6-auto-00.txt   draft-ietf-addrconf-ipv6-auto-01.txt 
ADDRCONF Working Group Susan Thomson (Bellcore) ADDRCONF Working Group Susan Thomson (Bellcore)
<draft-ietf-addrconf-ipv6-auto-00.txt> <draft-ietf-addrconf-ipv6-auto-01.txt>
IPv6 Address Autoconfiguration IPv6 Stateless Address Autoconfiguration
Status of this Memo 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 This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts. working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet 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 Drafts as reference material or to cite them other than as a "working
draft" or "work in progress." draft" or "work in progress."
To learn the current status of any Internet Draft. please check the To learn the current status of any Internet Draft. please check the
1id-abstracts.txt listing contained in the Internet Drafts Shadow 1id-abstracts.txt listing contained in the Internet Drafts Shadow
Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com or Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com or
munnari.oz.au. munnari.oz.au.
Abstract Abstract
This document specifies how a host autoconfigures one or more This document specifies stateless address autoconfiguration. A host
addresses per interface. A host can form an intra-link scope address can form a link-local address autonomously based on information local
autonomously based on information local to the host. A host can form to the host. A host can form an inter-link scope address in two
an inter-link scope address in two ways: either semi-autonomously, ways: either autonomously, based on prefixes advertised by routers,
based on knowledge of subnet prefixes advertised by routers, or by or by using the IPv6 version of the Dynamic Host Configuration
using DHCPv6. All mechanisms rely on a host having a token per Protocol(DHCPv6). All mechanisms rely on a host having a token that
interface that is unique at least per subnet. This document is unique at least per link. This document specifies how a host
specifies how a host forms an intra-link scope address autonomously forms addresses autonomously. DHCPv6 is described elsewhere.
and an inter-link scope address semi-autonomously using IEEE 802
tokens to identify each interface. DHCPv6 is described elsewhere.
1. INTRODUCTION 1. INTRODUCTION
An IPv6 host can autoconfigure two types of address: An IPv6 host may have multiple addresses per interface. The addresses
can have one of three scopes:
1. an intra-link scope address, 1. a link-local address,
2. an inter-link scope address. 2. a site-local address, and
An intra-link scope address is autoconfigurable in the absence of a 3. a global address.
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- All three address scopes can be autoconfigured. A host can autocon-
tialization of an interface, a host forms an IPv6 intra-link scope figure a link-local address autonomously. A host can autoconfigure a
address by concatenating a predefined intra-link scope prefix to a site-local or global address only when a router or a DHCPv6 server is
token that is unique per link. Typically, the definition of the present on the link.
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 There is only one way to form a link-local address. On initialization
mechanism, a host forms an IPv6 inter-link scope address by con- of an interface, a host forms such an address by concatenating a
catenating a network prefix advertised in a Router well-known link-local prefix[1] to a token that is unique per link.
Advertisement[IPv6-DISC-PROC,IPv6-DISC-PROC] to a token that is The definition of the tokens used are link-dependent. For example,
unique per link. The other mechanism available to hosts is to use the in the case of a host attached to an link that uses IEEE 802
IPv6 version of the Dynamic Host Configuration Protocol addresses, the token is the IEEE 802 address of the interface.
(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- There are two ways to form a site-local or global address. In the
able for environments where no administrative control is desired. It first mechanism, a host forms an inter-link scope address by con-
is a simple, efficient protocol designed for a very specific purpose: catenating a network prefix advertised in a Router Advertisement[2,3]
to make stateless address configuration very straightforward to use to a token that is unique per link. Like the link-local address, the
and implement. DHCPv6 is a more complex protocol allowing for very token is defined to be link-layer dependent. This mechanism for
flexible address assignment under the control of a system administra- forming a site-local or global address is suitable for environments
tor. This protocol typically requires significant system management, where no administrative control is desired. It is a simple protocol
including server and database configuration. designed for a very specific purpose: to make stateless address con-
figuration very straightforward to use and implement.
This document describes the general host address autoconfiguration The other mechanism available to hosts is to use the IPv6 version of
procedure in Section 2, and how a host forms an intra-link scope the Dynamic Host Configuration Protocol (DHCPv6). DHCPv6 is a more
address and an inter-link scope address without using DHCPv6 in Sec- complex protocol allowing for very flexible address assignment under
tions 3 and 4, respectively. The DHCPv6 protocol is specified else- the control of a system administrator. This protocol typically
where [IPv6-DHCP]. The scope of the document is limited to hosts requires significant system management, including server and database
attached to IEEE 802 networks. The effect of the transition scheme on configuration.
the address autoconfiguration procedure is discussed in Section 5.
2. PROCEDURE FOR FORMING AND MAINTAINING ADDRESSES The choice of mechanism to use in forming an inter-link scope address
is advertised by a router, if present, and this choice is configur-
able by a system administrator.
A host maintains a list of addresses per interface. At a minimum, the This document describes how a host forms a link-local address and one
list includes the intra-link scope address, which the host can form or more site-local or global addresses autonomously. It also speci-
autonomously whenever an interface is initialised. If a router is fies how a host determines which mechanism to use to form an inter-
attached to the link, the list will also include inter-link scope link scope address: the autonomous (stateless) approach or DHCPv6.
addresses formed either from subnet prefixes advertised in router Section 2 describes the router's role in address autoconfiguration
advertisements or by making requests to DHCPv6. Inter-link scope and Section 3 the host's role.
addresses may also be manually configured.
2.1. Host Configuration 2. ROUTER BEHAVIOR
A host must maintain a list of the following configurable variables The stateless address autoconfiguration mechanism relies on the
per interface: router discovery mechanism specified in [2,3] for forming addresses
with site-local or global scope. If configured to do so, routers
advertise prefix information in periodic Router Advertisements. The
prefixes are contained in Prefix-Information extensions of a Router
Advertisement. Each Prefix-Information extension indicates whether
the prefix can be used for autonomous address autoconfiguration and,
if so, for how long the resulting address is valid. Note that the
lifetime of 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 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.
Address Router Advertisement and Solicitation processing is specified in [2]
and the message formats in [3].
A valid IPv6 unicast address for this interface 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 the advertisement would
then be that of the 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.
Default: None 2.1. Router Configuration Variables
LifeTime: In addition to the configuration variables specified in [2,3],
routers MUST also be configurable as follows.
The length of time for which an address is valid in seconds. For each of the IPv6 unicast addresses per interface:
Default: Infinity Autonomous Flag
If and only if TRUE, the prefix length is to be advertised for
the purposes of autonomous address configuration.
An intra-link scope address and all manually configured addresses Default: TRUE
have their lifetimes set to infinity.
A host may also allow the following variable to be configured by a For each interface:
system administrator per interface:
Perform_Auto_Address Administered Flag
If TRUE, the host must perform address autoconfiguration process- If and only if TRUE, the host must autoconfigure other confi-
ing. Otherwise, the host performs no address autoconfiguration guration information using DHCPv6. Only valid in extensions
processing at all. with the Autonomous Flag set to TRUE.
Default: TRUE Default: FALSE
2.2. Router Configuration Address_Advertisement_Interval
A router must be configurable by a system administrator so that the The time allowed between sending unsolicited Address Advertise-
choice of mechanism used for host configuration of inter-link scope ments from the interface, in seconds. The value must not be
addresses can be controlled. Thus, a router must allow the following less than Maximum_Advertisement_Interval of Router Advertise-
variable to be configured by a system administrator per interface: ments.
Perform_Auto_Address Default: XX
If and only if TRUE, the router must send an Address Prefix exten- Address_Lifetime
sion in every Router Advertisement.
Default: TRUE 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.
All router interfaces advertising a given subnet prefix on a link Default: 3 * Address_Advertisement_Interval
must be configured to advertise the same address autoconfiguration
mode to hosts.
2.3. Host Address Autoconfiguration Procedure All routers advertising a given prefix on a link MUST be configured
to advertise the same autoconfiguration mode to hosts.
A host must perform the following procedure for each interface when 2.2. Processing
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 A router MUST advertise address autoconfiguration information in a
autoconfigurable interface, e.g. when an interface is enabled Prefix Information Extension of a Router Advertisement. The values of
after being disabled, the host forms an address of intra-link the Autonomous and Administered flags are advertised along with
scope and adds it to the list of addresses. Section 3 specifies Address_Lifetime. The address configuration information need not be
how a host forms an intra-link scope address. advertised in each Router Advertisement. It must be sent (almost)
periodically in a Router Advertisement at an interval of approxi-
mately Address_Advertisement_Interval.
The host must send a Router Solicitation so that inter-link scope Address configuration information must also be sent in the first few
addresses can be formed (or verified) as soon as possible. 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.
When a solicited or unsolicited Router Advertisement is received over Address configuration information may also be sent in a Router
an interface, the host must perform the following address configura- Advertisement due to actions taken by system management, in particu-
tion processing: 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.
If an Address Prefix extension exists, the host forms or verifies 3. HOST ADDRESS AUTOCONFIGURATION PROCESSING
its inter-link addresses autonomously as specified in Section 4.
Otherwise, the implication is that the host must use DHCPv6 for 3.1. Host Configuration Variables
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- A host maintains a list of addresses per interface. At a minimum, the
tem administrator decides to change the autoconfiguration mode from list includes the link-local address, which the host can form auto-
the autonomous mode (the host forms the address) to DHCPv6, and vice nomously whenever an interface is initialised. If a router is
versa. The requirement during a changeover is that the system attached to the link or DHCPv6 server is available, the list may also
administrator must ensure that a DHCPv6 server is configured to hand include site-local or global addresses formed either from subnet pre-
out addresses that are unique per subnet, particularly with respect fixes advertised in Router Advertisements or by making requests using
to addresses that hosts configure autonomously. To avoid problems DHCPv6. Addresses may also be manually configured. Note there may be
during a changeover, it is recommended that a DHCP server should use multiple site-local or global addresses autoconfigured per interface.
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 A host must maintain a list of the following configurable variables
should provide the ability for a host to specify in a request previ- per interface:
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. Address
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.
3. FORMING AN IEEE 802 IPv6 ADDRESS A valid IPv6 unicast address for this interface
A host forms an IEEE 802 IPv6 address for an interface by concatenat- Default: None
ing an 80-bit subnet prefix with the 48-bit IEEE 802 address of the
interface as follows:
| 80 bits | 48 bits | Prefix Length
+---------------------------------------+------------------------+
| subnet prefix | IEEE 802 address |
+----------------------------------------------------------------+
In the case of an intra-link scope prefix, the subnet prefix is The length of the prefix in bits. Prefix length semantics are
well-defined (TBD). specified in [2].
In the case of an inter-link scope prefix, the subnet prefix is con- A host must also allow the following variable to be configured per
figurable (typically in a router). interface:
4. FORMING INTER-LINK SCOPE IPv6 ADDRESSES AUTONOMOUSLY Perform_Auto_Config
4.1. Router Operation If and only if TRUE, the host must perform address autoconfigura-
tion processing.
4.1.1. Sending Router Advertisements with Address Extensions Default: TRUE
A router may be configured to advertise address configuration infor- 3.2. Host Initialization Behavior
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 A host must perform the following autoconfiguration procedure when-
purposes. It is likely the case that the Address Prefix Extension ever an interface needs to be initialised:
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.
4.1.2. Address Prefix Extension Format When a host has no address for an interface with
Perform_Auto_Config flag set to TRUE, e.g. when a host boots or
when an interface is enabled after being disabled, the host forms
an address of link-local scope. Appendix A specifies how a host
that is attached to a link that uses IEEE 802 addresses forms a
link-local address.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Before adding the link-local address as a valid address to the
| Extension | Length | Reserved |M| Prefix Size | list of addresses for the interface, the host SHOULD verify that
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ the address is indeed unique. The procedure for validating an
| Subnet Prefix | address is described in Section X. A host SHOULD also validate any
| | manually configured addresses this way too.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Extension TBD The host solicits a Router Advertisement using one or more Router
Solicitations, if no Router Advertisements have been heard in the
interface. The procedure for sending Router Solicitations is
specified in [2].
Length 18 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 host
must determine whether a DHCPv6 server is present and whether any
configuration information needs to be acquired. This is to cater
for a routerless topology which has a DHCPv6 server. Once a router
is added to the network, however, a host MUST use Router Adver-
tisements to determine the autoconfiguration mode in use as
described in the section on Router Advertisement Processing.
Reserved Must be zero 3.3. Router Advertisement Processing
M When set, indicates more IPv6 parameters to Router Advertisement processing is specified in [2] and the message
configure besides address. format in [3]. In addition to this processing, the host MUST perform
the following address configuration processing when a solicited or
unsolicited Router Advertisement is received over an interface:
Use DHCPv6 to acquire these parameters. For each Prefix-Information extension in the Router Advertisement:
(The format of the Prefix-Information extension as amended by this
draft for autoconfiguration purposes is specified in Appendix C):
Prefix Size Length of subnet prefix in bits. The host silently ignores the extension for the purposes of auto-
configuration if the Perform_Auto_Config flag for the interface is
FALSE.
Subnet Prefix Valid subnet prefix for this link. Otherwise, the host checks the autoconfiguration mode bits.
This extension is found in Router Advertisements. If only the Autonomous flag is set in the Prefix-Information
extension, the host forms or verifies a site-local or global
address as specified below.
4.1.3. Drop Address Prefix Extension Format If both the Autonomous and Administered flags are set in the
Prefix-Information extension, the host forms or verifies a site-
local or global address as specified below and uses or continues
using DHCPv6 for other autoconfiguration.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Otherwise, the host silently ignores the extension for the pur-
| Extension | Length | Reserved | Prefix Size | poses of autonomous autoconfiguration.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subnet Prefix |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Extension TBD If none of the prefixes advertised in extensions of the Router Adver-
tisement have the Autonomous flag set, then the host uses or contin-
ues using DHCPv6 for autoconfiguration.
Length 18 Note that the above procedure should continue to operate when a sys-
Reserved Must be zero tem administrator decides to change the autoconfiguration mode from
the autonomous mode to DHCPv6, and vice versa. The host should keep
track of the current autoconfiguration mode, so that it can detect
when there is a change. The system administrator must ensure that,
during a changeover, a DHCPv6 server is configured to hand out
addresses that are unique per link, particularly with respect to
addresses that hosts have configured autonomously and which may not
yet be invalidated. 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 when the
prefix is the same. It is also important to ensure that a DHCPv6
server is configured to hand out addresses only to those hosts that
it should, since, if a DHCPv6 server is present on a link, hosts may
request the server for addresses (even if the network is configured
to be in autonomous mode) when Router Advertisements are not heard
because the router is down.
Prefix Size Length of subnet prefix in bits. For each Prefix-Information extension received over an autoconfigur-
able interface, the host updates the address list as follows when the
Autonomous flag is set:
Subnet Prefix Subnet prefix for this link to be invalidated. 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 specified in the extension. Note there is no timer
associated with a link-local address or manually configured
address.
This extension is found in Router Advertisements. b) If the prefix advertised does not match the prefix of an address
already in the list, then form an address using this network
prefix. Appendix A specifies how to form an address for hosts
that have IEEE 802 tokens. The extension is ignored if the pre-
fix is not the right length for forming an address as specified
in Appendix A.
4.2. Host Operation Add this address to the list with a timer set to that of the
lifetime specified in the extension.
4.2.1. Processing Router Advertisements with Address Extensions 3.3.1. Address Deprecation and Invalidation
On hearing a Router Advertisement on an interface, a host checks for An address is valid until the timer expires.
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 When the lifetime of 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.
For each address prefix advertised on an autoconfigurable interface, In particular, the internetworking layer should not select a
the host updates the list of addresses as follows: deprecated address as a source address in new communications. How-
ever, a deprecated address should be allowed to be used as a source
address if it is in use by the transport layer in existing communica-
tions or it is explicitly requested by an application.
1. If the prefix advertised matches the prefix of an address The internetworking layer must continue to accept datagrams destined
already in the list, then set the lifetime to infinity. to a deprecated address. The transport layer may refuse to accept new
communications requests to a deprecated address, however.
2. If the prefix advertised does not match the prefix of an address In addition, a host may send a Remote Redirect[2,3] to correspondents
already in the list, then form an inter-link scope address using when the source address used in communications is deprecated as long
this network prefix. Section 3 specifies how to form an inter- as the host has a valid alternative address. Also, a deprecated
link scope address. address should be removed from the 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 host's behalf.
Add this address to the list with an infinite lifetime. The time at which a deprecated address becomes invalid (removed from
the list of addresses per interface) is dependent on the storage
available for the address list and is thus implementation-dependent.
A host should keep a deprecated address until it is no longer in use,
i.e. it is no longer being used in current communications such as an
existing TCP connection, and it is no longer stored or cached in the
Domain Name System. After this point, a deprecated address may be
removed from the address list.
3. All other autoconfigured inter-link addresses in the list have If Router Advertisements stop being heard and all autoconfigured
their lifetimes set to zero. inter-link scope addresses become deprecated, then the host must
determine whether a DHCPv6 server is available for address autoconfi-
guration. The host follows the same procedure as described in the
initialisation procedure in this case.
An inter-link scope address is valid for as long as the subnet prefix 3.4. Detecting Duplicate IPv6 Addresses
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 One of the basic assumptions of the autoconfiguration schemes out-
guaranteed to be. In the case where a subnet prefix that has been lined in this document is that the host token is at least unique per
previously advertised is no longer advertised in a Router Advertise- link. Tokens are defined to be link-layer dependent, and the token is
ment (this assumes that a host is hearing Router Advertisements), a the link layer address in most cases. In practice, two hosts on the
host should prepare for the time when the address becomes invalid: a same link may have the same link layer address because of an assign-
host should stop using the address as a source address in communica- ment error, in which case the resulting IPv6 addresses will not be
tions, if other addresses are available, and should stop advertising unique. For this reason, it is prudent to check that the addresses
the address to others in DNS. Also, it should refuse to accept new are indeed unique. In IPv6, it is only necessary to check that one
connections to this address. However, the address may still be used of the autoconfigured addresses is unique since the same token is
to accept incoming datagrams and to avoid breaking existing connec- used to form all addresses and the prefixes used to form the
tions. When an address becomes deprecated because no Router Adver- addresses are all unique (the autoconfiguration procedure should
tisements are heard (because the router is down, for example), the ensure this). It is recommended that the link-local address be the
host may still continue to use the address as normal until the next address checked since it is formed once and first, on initialisation.
Router Advertisement is heard.
Note that the 'M' bit of an address prefix extension may indicate to The procedures use General Solicitations and Advertisements specified
the host that it must use DHCPv6 to acquire other IPv6 configuration in [2,3] as modified below. To validate an address, the node sends a
parameters (besides the address). General Solicitation with the source and destination set to that of
the address to be checked. The node should specify an appropriate
Media-Access extension.
4.2.3. Drop Address Prefix Extension Processing On receiving a General Solicitation with a source address that is the
same as the destination address and apparently from itself, a host
must respond with a General Advertisement. The General Advertisement
is sent to the All-Nodes Multicast Address with intra-link scope.
The Media-Access extension from the General Solicitation MUST NOT be
retained.
For each address prefix advertised, the host updates the list of After sending a General Solicitation, the node waits for a period of
addresses as follows: General_Solicitation_Interval. If a General Advertisement is not
received in response to the General Solicitation within the interval,
the address is considered to be validated. If a General Advertisement
is received with a source address the same as the address being vali-
dated, it must cease operation on that interface and indicate an
appropriate error.
1. If the prefix advertised matches the prefix of an address Note that this mechanism is not completely reliable, and so it is
already in the list, then remove address from list. possible that duplicate addresses will still exist. If a duplicate
address is discovered, the host will need to be configured with a new
token, or if this is not possible, the IPv6 addresses will need to be
manually configured.
When an address is invalidated, it should no longer be used at all in DISCUSSION: There is a problem with a race condition when two (or
communications since the subnet prefix is no longer routable. more) nodes boot up at the 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 vali-
dation stage and flag an error if it sees more than one General Sol-
icitation for an address it is in the process of validating.
5. TRANSITION IMPLICATIONS DISCUSSION: Should the solicitations be dithered? Note that randomis-
ing based on the token (link-layer address) only does not help if the
token is not unique.
IPv4-compatible IPv6 addresses are required by IPv6 hosts for the 4. SECURITY CONSIDERATIONS
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 To be completed.
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 5. APPENDIX A: FORMING AN IPv6 ADDRESS FOR IEEE 802 LINKS
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 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.
To be completed. A host forms an IPv6 address per link by concatenating an 80-bit pre-
fix with the IEEE 802 address as follows:
7. APPENDIX - UNIQUENESS OF HOST TOKENS | 80 bits | 48 bits |
+---------------------------------------+------------------------+
| prefix | IEEE 802 address |
+----------------------------------------------------------------+
One of the basic assumptions of the autoconfiguration schemes out- In the case of a link-local prefix, the prefix is well-defined[1].
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 The prefixes of other types of addresses need to be configured.
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.
8. REFERENCES 6. APPENDIX B: UNIQUENESS OF HOST TOKENS
[RFC1531] As has been mentioned, one of the basic assumptions of the autoconfi-
R. Droms, "Dynamic Host Configuration Protocol", RFC 1531, Buck- guration scheme outlined in this document is that the host token is
nell University, October 1993. at least unique per link, but that tokens may not always be unique,
in practice. A host should check that an address is unique using the
scheme proposed in this document. Since this is not completely reli-
able, system administrators may also use DNS to help detect when such
a problem occurs since two different hosts will register the same
IPv6 address.
[IPv6-TRANS] Duplicate IPv6 addresses may occur as a result of non-unique tokens
Robert E. Gilligan and E. Nordmark, "Transition Mechanisms for in any particular network topology. One particular scenario deserves
IPv6 Hosts and Routers", Internet Draft, November 1994, <draft- further mention though. Consider a topology consisting of two links
gilligan-ipv6-trans-mech-00.txt> 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 link-local addresses only on all interfaces. It is
imperative that hosts have interface tokens that are unique across
both links. However, this may not be true 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 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 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
link-local address of an offending host.
[IPv6-SPEC] 7. APPENDIX C: Prefix-Information Extension
R. Hinden, "Internet Protocol Version 6 (IPv6) Specification",
Internet Draft, February 1994, <draft-hinden-ipng-ipv6-spec-
00.txt>
[IPv6-ROAD] +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension | Length |C|A|M| 0 | Prefix Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime | Preference |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Identifier |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[IPv6-ICMP] Extension As in [3]
A. Conta and S. Deering, "ICMP and IGMP for IPv6", Internet
Draft, September 1994, <draft-conta-ipv6-icmp-igmp-00.txt>
[IPv6-DISC-FORM] Length As in [3]
W. A. Simpson, "IPv6 Neighbor Discovery -- ICMP Message For-
mats", Internet Draft, November 1994, <draft-simpson-ipv6-
discov-formats-01.txt>
[IPv6-DISC-PROC] C As in [3]
W. A. Simpson, "IPv6 Neighbor Discovery -- Processing", Internet
Draft, November 1994, <draft-simpson-ipv6-discov-process-01.txt>
[IPv6-DHCP] A Autonomous Mode
J. Bound, Y. Rekhter and S. Thomson, Internet Draft in progress.
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 unicast addresses of this interface
This extension is found in Router Advertisements.
8. REFERENCES
[1] R. Hinden, "Internet Protocol Version (IPv6) Specification",
Internet Draft, March 1995, <draft-ietf-ipngwg-ipv6-addr-arch-
01.txt>
[2] W. A. Simpson, "IPv6 Neighbor Discovery -- Processing", Internet
Draft, January 1995, <draft-simpson-ipv6-discov-process-02.txt>
[3] W. A. Simpson, "IPv6 Neighbor Discovery -- ICMP Message For-
mats", Internet Draft, January 1995, <draft-simpson-ipv6-
discov-formats-02.txt>
Acknowledgements Acknowledgements
The author would like to thank the members of both the IPNG and ADDRCONF The author would like to thank the members of both the IPNG and ADDRCONF
working groups for their input. working groups for their input. In particular, thanks to Jim Bound,
Steve Deering and Bill Simpson.
Author's Addresses Author's Addresses
Susan Thomson Susan Thomson
Bellcore Bellcore
445 South Street 445 South Street
Morristown, NJ 07960 Morristown, NJ 07960
U.S.A. U.S.A.
Phone: +1 201-829-4514 Phone: +1 201-829-4514
 End of changes. 105 change blocks. 
324 lines changed or deleted 404 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/