draft-ietf-addrconf-ipv6-auto-06.txt   draft-ietf-addrconf-ipv6-auto-07.txt 
ADDRCONF Working Group Susan Thomson, Bellcore ADDRCONF Working Group Susan Thomson, Bellcore
INTERNET-DRAFT Thomas Narten, IBM INTERNET-DRAFT Thomas Narten, IBM
<draft-ietf-addrconf-ipv6-auto-06.txt> November 15, 1995 <draft-ietf-addrconf-ipv6-auto-07.txt> December 13, 1995
IPv6 Stateless 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 This document is a submission to the ADDRCONF Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted Internet Engineering Task Force (IETF). Comments should be submitted
to the addrconf@cisco.com mailing list. 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.
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
This Internet Draft expires May 15, 1996. This Internet Draft expires June 13, 1996.
Abstract Abstract
This document specifies the steps a host takes in deciding how to This document specifies the steps a host takes in deciding how to
autoconfigure its interfaces in IP version 6. The autoconfiguration autoconfigure its interfaces in IP version 6. The autoconfiguration
process includes creating a link-local address and verifying its process includes creating a link-local address and verifying its
uniqueness on a link, determining what information should be uniqueness on a link, determining what information should be
autoconfigured (addresses, other information, or both), and in the autoconfigured (addresses, other information, or both), and in the
case of addresses, whether they should be obtained through the case of addresses, whether they should be obtained through the
stateless mechanism, the stateful mechanism, or both. This document stateless mechanism, the stateful mechanism, or both. This document
skipping to change at page 3, line 29 skipping to change at page 3, line 29
5. PROTOCOL SPECIFICATION................................... 13 5. PROTOCOL SPECIFICATION................................... 13
5.1. Node Configuration Variables........................ 13 5.1. Node Configuration Variables........................ 13
5.2. Autoconfiguration-Related Variables................. 14 5.2. Autoconfiguration-Related Variables................. 14
5.3. Creation of Link-Local Addresses.................... 14 5.3. Creation of Link-Local Addresses.................... 14
5.4. Duplicate Address Detection......................... 15 5.4. Duplicate Address Detection......................... 15
5.4.1. Message Validation............................. 16 5.4.1. Message Validation............................. 16
5.4.2. Sending Neighbor Solicitation Messages......... 16 5.4.2. Sending Neighbor Solicitation Messages......... 16
5.4.3. Receiving Neighbor Solicitation Messages....... 17 5.4.3. Receiving Neighbor Solicitation Messages....... 17
5.4.4. Receiving Neighbor Advertisement Messages...... 18 5.4.4. Receiving Neighbor Advertisement Messages...... 18
5.4.5. When Duplicate Address Detection Fails......... 18 5.4.5. When Duplicate Address Detection Fails......... 18
5.5. Creation of Global- and Site-Local Addresses........ 18 5.5. Creation of Global and Site-Local Addresses......... 18
5.5.1. Soliciting Router Advertisements............... 18 5.5.1. Soliciting Router Advertisements............... 18
5.5.2. Absence of Router Advertisements............... 19 5.5.2. Absence of Router Advertisements............... 19
5.5.3. Router Advertisement Processing................ 19 5.5.3. Router Advertisement Processing................ 19
5.5.4. Address Lifetime Expiry........................ 20 5.5.4. Address Lifetime Expiry........................ 20
5.6. Configuration Consistency........................... 21 5.6. Configuration Consistency........................... 21
OPEN ISSUES/TODO............................................. 21
SECURITY CONSIDERATIONS...................................... 21 SECURITY CONSIDERATIONS...................................... 21
REFERENCES................................................... 22 REFERENCES................................................... 22
AUTHORS' ADDRESSES........................................... 22 AUTHORS' ADDRESSES........................................... 22
APPENDIX: LOOPBACK SUPPRESSION & DUPLICATE ADDRESS DETECTION. 23 APPENDIX: LOOPBACK SUPPRESSION & DUPLICATE ADDRESS DETECTION. 23
CHANGES SINCE PREVIOUS DOCUMENT.............................. 24
1. INTRODUCTION 1. INTRODUCTION
This document specifies the steps a host takes in deciding how to This document specifies the steps a host takes in deciding how to
autoconfigure its interfaces in IP version 6. The autoconfiguration autoconfigure its interfaces in IP version 6. The autoconfiguration
process includes creating a link-local address and verifying its process includes creating a link-local address and verifying its
uniqueness on a link, determining what information should be uniqueness on a link, determining what information should be
autoconfigured (addresses, other information, or both), and in the case autoconfigured (addresses, other information, or both), and in the case
of addresses, whether they should be obtained through the stateless of addresses, whether they should be obtained through the stateless
mechanism, the stateful mechanism, or both. This document defines the mechanism, the stateful mechanism, or both. This document defines the
process for generating a link-local address, the process for generating process for generating a link-local address, the process for generating
skipping to change at page 11, line 6 skipping to change at page 11, line 6
not already in use by another node on the link. Specifically, it sends a not already in use by another node on the link. Specifically, it sends a
Neighbor Solicitation message containing the tentative address as the Neighbor Solicitation message containing the tentative address as the
target. If another node is already using that address, it will return a target. If another node is already using that address, it will return a
Neighbor Advertisement saying so. If another node is also attempting to Neighbor Advertisement saying so. If another node is also attempting to
use the same address, it will send a Neighbor Solicitation for the use the same address, it will send a Neighbor Solicitation for the
target as well. The exact number of times the Neighbor Solicitation is target as well. The exact number of times the Neighbor Solicitation is
(re)transmitted and the delay time between consecutive solicitations is (re)transmitted and the delay time between consecutive solicitations is
link-specific and may be set by system management. link-specific and may be set by system management.
If a node determines that its tentative link-local address is not If a node determines that its tentative link-local address is not
unique, autoconfiguration stops and manual configuration of the machine unique, autoconfiguration stops and manual configuration of the
is required. To simplify recovery in this case, it should be possible interface is required. To simplify recovery in this case, it should be
for an administrator to supply an alternate interface token that possible for an administrator to supply an alternate interface token
overrides the default token in such a way that the autoconfiguration that overrides the default token in such a way that the
mechanism can then be applied using the new (presumably unique) autoconfiguration mechanism can then be applied using the new
interface token. Alternatively, link-local and other addresses will (presumably unique) interface token. Alternatively, link-local and
need to be configured manually. other addresses will need to be configured manually.
Once a node ascertains that its tentative link-local address is unique, Once a node ascertains that its tentative link-local address is unique,
it assigns it to the interface. At this point, the node has IP-level it assigns it to the interface. At this point, the node has IP-level
connectivity with neighboring nodes. The remaining autoconfiguration connectivity with neighboring nodes. The remaining autoconfiguration
steps are performed only by hosts; the (auto)configuration of routers is steps are performed only by hosts; the (auto)configuration of routers is
beyond the scope of this document. beyond the scope of this document.
The next phase of autoconfiguration involves obtaining a Router The next phase of autoconfiguration involves obtaining a Router
Advertisement or determining that no routers are present. If routers are Advertisement or determining that no routers are present. If routers are
present, they will send Router Advertisements that specify what sort of present, they will send Router Advertisements that specify what sort of
skipping to change at page 12, line 32 skipping to change at page 12, line 32
To speed the autoconfiguration process, a host may generate its link- To speed the autoconfiguration process, a host may generate its link-
local address (and verify its uniqueness) in parallel with waiting for a local address (and verify its uniqueness) in parallel with waiting for a
Router Advertisement. Because a router may delay responding to a Router Router Advertisement. Because a router may delay responding to a Router
Solicitation for a few seconds, the total time needed to complete Solicitation for a few seconds, the total time needed to complete
autoconfiguration can be significantly longer if the two steps are done autoconfiguration can be significantly longer if the two steps are done
serially. serially.
4.1. Site Renumbering 4.1. Site Renumbering
Address leasing facilitates site renumbering by providing a mechanism to Address leasing facilitates site renumbering by providing a mechanism to
time-out addresses in hosts. At present, upper layer protocols such as time-out addresses assigned to interfaces in hosts. At present, upper
TCP provide no support for changing endpoint addresses while a layer protocols such as TCP provide no support for changing end-point
connection is open. If an end-point address becomes invalid, existing addresses while a connection is open. If an end-point address becomes
connections break and all communication to the invalid address fails. invalid, existing connections break and all communication to the invalid
Even when applications use UDP as a transport protocol, addresses must address fails. Even when applications use UDP as a transport protocol,
generally remain the same during a packet exchange. addresses must generally remain the same during a packet exchange.
Dividing valid addresses into preferred and deprecated categories Dividing valid addresses into preferred and deprecated categories
provides a way of indicating to upper layers that a valid address may provides a way of indicating to upper layers that a valid address may
become invalid shortly and that future communication using the address become invalid shortly and that future communication using the address
will fail, should the address's valid lifetime expire before will fail, should the address's valid lifetime expire before
communication ends. To avoid this scenario, higher layers should use a communication ends. To avoid this scenario, higher layers should use a
preferred address (assuming one of sufficient scope exists) to increase preferred address (assuming one of sufficient scope exists) to increase
the likelihood that an address will remain valid for the duration of the the likelihood that an address will remain valid for the duration of the
communication. It is up to system administrators to set appropriate communication. It is up to system administrators to set appropriate
prefix lifetimes in order to minimize the impact of failed communication prefix lifetimes in order to minimize the impact of failed communication
skipping to change at page 14, line 21 skipping to change at page 14, line 21
autoconfiguration. In the following, we present conceptual variables and autoconfiguration. In the following, we present conceptual variables and
show how they are used to perform autoconfiguration. The specific show how they are used to perform autoconfiguration. The specific
variables are used for demonstration purposes only, and an variables are used for demonstration purposes only, and an
implementation is not required to have them, so long as its external implementation is not required to have them, so long as its external
behavior is consistent with that described in this document. behavior is consistent with that described in this document.
Beyond the formation of a link-local address and using Duplicate Address Beyond the formation of a link-local address and using Duplicate Address
Detection, how routers (auto)configure their interfaces is beyond the Detection, how routers (auto)configure their interfaces is beyond the
scope of this document. scope of this document.
ManagedFlag Copied from the Managed field of the most recently Hosts maintain the following variables on a per-interface basis:
ManagedFlag Copied from the M flag field (i.e., the "managed
address configuration" flag) of the most recently
received Router Advertisement message. The flag received Router Advertisement message. The flag
indicates whether or not addresses are to be indicates whether or not addresses are to be
configured using the stateful autoconfiguration configured using the stateful autoconfiguration
mechanism. It starts out in a FALSE state. mechanism. It starts out in a FALSE state.
OtherConfigFlag Copied from the Other field of the most recently OtherConfigFlag Copied from the O flag field (i.e., the "other
stateful configuration" flag) of the most recently
received Router Advertisement message. The flag received Router Advertisement message. The flag
indicates whether or not information other than indicates whether or not information other than
addresses are to be obtained using the stateful addresses are to be obtained using the stateful
autoconfiguration mechanism. It starts out in a autoconfiguration mechanism. It starts out in a
FALSE state. FALSE state.
A host also maintains a list of addresses together with their A host also maintains a list of addresses together with their
corresponding lifetimes. The address list contains both autoconfigured corresponding lifetimes. The address list contains both autoconfigured
addresses and those configured manually. addresses and those configured manually.
skipping to change at page 15, line 33 skipping to change at page 15, line 36
unicast addresses, regardless of whether they are obtained through unicast addresses, regardless of whether they are obtained through
stateful, stateless or manual configuration. (Duplicate Address stateful, stateless or manual configuration. (Duplicate Address
Detection MUST NOT be performed on anycast addresses.) Each individual Detection MUST NOT be performed on anycast addresses.) Each individual
unicast address SHOULD be tested for uniqueness. However, when stateless unicast address SHOULD be tested for uniqueness. However, when stateless
address autoconfiguration is used, address uniqueness is determined address autoconfiguration is used, address uniqueness is determined
solely by the interface token, assuming that subnet prefixes are solely by the interface token, assuming that subnet prefixes are
assigned correctly (i.e., if all of an interface's addresses are assigned correctly (i.e., if all of an interface's addresses are
generated from the same token, either all addresses or none of them will generated from the same token, either all addresses or none of them will
be duplicates). Thus, for a set of addresses formed from the same be duplicates). Thus, for a set of addresses formed from the same
interface token, it is sufficient to check that the link-local address interface token, it is sufficient to check that the link-local address
generated from the token is unique on the link. In such cases, the link- generated from the token is unique on the link. In such cases, the
local address MUST be tested for uniqueness before any of the other link-local address MUST be tested for uniqueness before any of the other
addresses can be assigned to an interface. addresses formed from the token can be assigned to an interface.
The procedure for detecting duplicate addresses uses Neighbor The procedure for detecting duplicate addresses uses Neighbor
Solicitation and Advertisement messages as described below. If a Solicitation and Advertisement messages as described below. If a
duplicate address is discovered during the procedure, the address cannot duplicate address is discovered during the procedure, the address cannot
be assigned to the interface. If the address is derived from an be assigned to the interface. If the address is derived from an
interface token, a new token will need to be assigned to the interface, interface token, a new token will need to be assigned to the interface,
or all IP addresses for the interface will need to be manually or all IP addresses for the interface will need to be manually
configured. Note that the method for detecting duplicates is not configured. Note that the method for detecting duplicates is not
completely reliable, and it is possible that duplicate addresses will completely reliable, and it is possible that duplicate addresses will
still exist (e.g., if the link was partitioned while Duplicate Address still exist (e.g., if the link was partitioned while Duplicate Address
skipping to change at page 17, line 21 skipping to change at page 17, line 25
Duplicate Address Detection algorithm, an interface MUST receive and Duplicate Address Detection algorithm, an interface MUST receive and
process datagrams sent to the all-nodes multicast address or solicited- process datagrams sent to the all-nodes multicast address or solicited-
node multicast address of the tentative address while delaying node multicast address of the tentative address while delaying
transmission of the initial Neighbor Solicitation. transmission of the initial Neighbor Solicitation.
5.4.3. Receiving Neighbor Solicitation Messages 5.4.3. Receiving Neighbor Solicitation Messages
On receipt of a valid Neighbor Solicitation message on an interface, On receipt of a valid Neighbor Solicitation message on an interface,
node behavior depends on whether the target address is tentative or not. node behavior depends on whether the target address is tentative or not.
If the target address is not tentative (i.e., it is assigned to the If the target address is not tentative (i.e., it is assigned to the
receiving interface), the solicitation is processed in the normal way receiving interface), the solicitation is processed as described in
[DISCOVERY]. If the target address is tentative, and the source address [DISCOVERY]. If the target address is tentative, and the source address
is a unicast address, the solicitation's sender is performing address is a unicast address, the solicitation's sender is performing address
resolution on the target; the solicitation should be silently ignored. resolution on the target; the solicitation should be silently ignored.
Otherwise, processing takes place as described below. In all cases, a Otherwise, processing takes place as described below. In all cases, a
node MUST NOT respond to a Neighbor Solicitation for a tentative node MUST NOT respond to a Neighbor Solicitation for a tentative
address. address.
If the source address of the Neighbor Solicitation is the unspecified If the source address of the Neighbor Solicitation is the unspecified
address, the solicitation is from a node performing Duplicate Address address, the solicitation is from a node performing Duplicate Address
Detection. If the solicitation is from another node, the tentative Detection. If the solicitation is from another node, the tentative
skipping to change at page 18, line 20 skipping to change at page 18, line 25
was received), the tentative address is a duplicate. This condition was received), the tentative address is a duplicate. This condition
occurs when two nodes run Duplicate Address Detection occurs when two nodes run Duplicate Address Detection
simultaneously and transmit solicitations at roughly the same time. simultaneously and transmit solicitations at roughly the same time.
5.4.4. Receiving Neighbor Advertisement Messages 5.4.4. Receiving Neighbor Advertisement Messages
On receipt of a valid Neighbor Advertisement message on an interface, On receipt of a valid Neighbor Advertisement message on an interface,
node behavior depends on whether the target address is tentative or node behavior depends on whether the target address is tentative or
matches a unicast or anycast address assigned to the interface. If the matches a unicast or anycast address assigned to the interface. If the
target address is assigned to the receiving interface, the solicitation target address is assigned to the receiving interface, the solicitation
is processed in the normal way [DISCOVERY]. If the target address is is processed as described in [DISCOVERY]. If the target address is
tentative, the tentative address is not unique. tentative, the tentative address is not unique.
5.4.5. When Duplicate Address Detection Fails 5.4.5. When Duplicate Address Detection Fails
A tentative address that is determined to be a duplicate as described A tentative address that is determined to be a duplicate as described
above, MUST NOT be assigned to an interface and the node SHOULD log a above, MUST NOT be assigned to an interface and the node SHOULD log a
system management error. If the address is a link-local address formed system management error. If the address is a link-local address formed
from an interface token, the interface SHOULD be disabled. from an interface token, the interface SHOULD be disabled.
5.5. Creation of Global- and Site-Local Addresses 5.5. Creation of Global and Site-Local Addresses
Global- and site-local addresses are formed by appending an interface Global and site-local addresses are formed by appending an interface
token to a prefix of appropriate length. Prefixes are obtained from token to a prefix of appropriate length. Prefixes are obtained from
Prefix Information options contained in Router Advertisements. Creation Prefix Information options contained in Router Advertisements. Creation
of global and site-local addresses and configuration of other parameters of global and site-local addresses and configuration of other parameters
as described in this section SHOULD be locally configurable. However, as described in this section SHOULD be locally configurable. However,
this processing MUST be enabled by default. the processing described below MUST be enabled by default.
5.5.1. Soliciting Router Advertisements 5.5.1. Soliciting Router Advertisements
Router Advertisements are sent periodically to the all-nodes multicast Router Advertisements are sent periodically to the all-nodes multicast
address. To obtain an advertisement quickly, a host sends out Router address. To obtain an advertisement quickly, a host sends out Router
Solicitations as described in [DISCOVERY]. Solicitations as described in [DISCOVERY].
5.5.2. Absence of Router Advertisements 5.5.2. Absence of Router Advertisements
If a link has no routers, a host MUST attempt to use stateful If a link has no routers, a host MUST attempt to use stateful
autoconfiguration to obtain addresses and other configuration autoconfiguration to obtain addresses and other configuration
information. An implementation MAY provide a way to disable the information. An implementation MAY provide a way to disable the
invocation of stateful autoconfiguration in this case, but the default invocation of stateful autoconfiguration in this case, but the default
SHOULD be enabled. From the perspective of autoconfiguration, a link SHOULD be enabled. From the perspective of autoconfiguration, a link
has no routers if no Router Advertisements are received after having has no routers if no Router Advertisements are received after having
sent a small number of Router Solicitations as described in [DISCOVERY]. sent a small number of Router Solicitations as described in [DISCOVERY].
5.5.3. Router Advertisement Processing 5.5.3. Router Advertisement Processing
On receipt of a valid Router Advertisement (as defined in [DISCOVERY]), On receipt of a valid Router Advertisement (as defined in [DISCOVERY]),
a host copies the value of the advertisement's Managed bit into a host copies the value of the advertisement's M bit into ManagedFlag.
ManagedFlag. If the value of ManagedFlag changes from FALSE to TRUE, the If the value of ManagedFlag changes from FALSE to TRUE, the host should
host should invoke the stateful address autoconfiguration protocol, invoke the stateful address autoconfiguration protocol, requesting
requesting address information. If the value of the ManagedFlag changes address information. If the value of the ManagedFlag changes from TRUE
from TRUE to FALSE, the host should terminate the stateful address to FALSE, the host should terminate the stateful address
autoconfiguration protocol (i.e., stop requesting addresses and ignore autoconfiguration protocol (i.e., stop requesting addresses and ignore
subsequent responses to in-progress transactions). If the value of the subsequent responses to in-progress transactions). If the value of the
flag stays unchanged, no special action takes place. In particular, a flag stays unchanged, no special action takes place. In particular, a
host MUST NOT reinvoke stateful address configuration if it is already host MUST NOT reinvoke stateful address configuration if it is already
participating in the stateful protocol as a result of an earlier participating in the stateful protocol as a result of an earlier
advertisement. advertisement.
An advertisement's Other bit is processed in an analogous manner. A host An advertisement's O flag field is processed in an analogous manner. A
copies the value of the Other bit into OtherConfigFlag. If the value of host copies the value of the O flag into OtherConfigFlag. If the value
OtherConfigFlag changes from FALSE to TRUE, the host should invoke the of OtherConfigFlag changes from FALSE to TRUE, the host should invoke
stateful autoconfiguration protocol, requesting information (excluding the stateful autoconfiguration protocol, requesting information
addresses). If the value of the OtherConfigFlag changes from TRUE to (excluding addresses). If the value of the OtherConfigFlag changes from
FALSE, any activity related to stateful autoconfiguration for parameters TRUE to FALSE, any activity related to stateful autoconfiguration for
other than addresses should be halted. If the value of the flag stays parameters other than addresses should be halted. If the value of the
unchanged, no special action takes place. In particular, a host MUST NOT flag stays unchanged, no special action takes place. In particular, a
reinvoke stateful configuration if it is already participating in the host MUST NOT reinvoke stateful configuration if it is already
stateful protocol as a result of an earlier advertisement. participating in the stateful protocol as a result of an earlier
advertisement.
For each Prefix-Information option in the Router Advertisement: For each Prefix-Information option in the Router Advertisement:
a) If the Autonomous flag is not set, silently ignore the Prefix a) If the Autonomous flag is not set, silently ignore the Prefix
Information option. Information option.
b) If the prefix is the link-local prefix, silently ignore the Prefix b) If the prefix is the link-local prefix, silently ignore the Prefix
Information option. Information option.
c) If the preferred lifetime is greater than the valid lifetime, c) If the preferred lifetime is greater than the valid lifetime,
silently ignore the Prefix Information option. A node MAY wish to silently ignore the Prefix Information option. A node MAY wish to
log a system management error in this case. log a system management error in this case.
d) If the advertised prefix matches the prefix of an autoconfigured d) If the advertised prefix matches the prefix of an autoconfigured
address in the list of addresses associated with the interface, set address (i.e., obtained via stateless or stateful address
the preferred timer to that of the option's preferred lifetime, and autoconfiguration) in the list of addresses associated with the
set the valid lifetime to that of the option's valid lifetime. interface, set the preferred timer to that of the option's preferred
lifetime, and set the valid lifetime to that of the option's valid
lifetime.
e) If the prefix advertised does not match the prefix of an address e) If the prefix advertised does not match the prefix of an address
already in the list, then form an address (and add it to the list) already in the list, then form an address (and add it to the list)
by appending the interface token to the prefix as follows: by appending the interface token to the prefix as follows:
| 128 - N bits | N bits | | 128 - N bits | N bits |
+---------------------------------------+------------------------+ +---------------------------------------+------------------------+
| link prefix | interface token | | link prefix | interface token |
+----------------------------------------------------------------+ +----------------------------------------------------------------+
skipping to change at page 20, line 30 skipping to change at page 20, line 33
equal 128 bits, the Prefix Information option MUST be ignored. An equal 128 bits, the Prefix Information option MUST be ignored. An
implementation MAY wish to log a system management error in this implementation MAY wish to log a system management error in this
case. It is the responsibility of the system administrator to insure case. It is the responsibility of the system administrator to insure
that the lengths of prefixes contained in Router Advertisements are that the lengths of prefixes contained in Router Advertisements are
consistent with the length of interface tokens for that link type. consistent with the length of interface tokens for that link type.
In those cases where a site requires the use of longer prefixes than In those cases where a site requires the use of longer prefixes than
can be accommodated by the interface token, stateful can be accommodated by the interface token, stateful
autoconfiguration can be used. autoconfiguration can be used.
If an address is formed successfully, the host adds it to If an address is formed successfully, the host adds it to the list
AddressList, initializing its preferred and valid lifetime values of addresses assigned to the interface, initializing its preferred
from the Prefix Information option. and valid lifetime values from the Prefix Information option.
5.5.4. Address Lifetime Expiry 5.5.4. Address Lifetime Expiry
A preferred address becomes deprecated when its preferred lifetime A preferred address becomes deprecated when its preferred lifetime
expires. A deprecated address SHOULD continue to be used as a source expires. A deprecated address SHOULD continue to be used as a source
address in existing communications, but SHOULD NOT be used in new address in existing communications, but SHOULD NOT be used in new
communications if an alternate (non-deprecated) address is available and communications if an alternate (non-deprecated) address is available and
has sufficient scope. The IP layer MUST continue to accept datagrams has sufficient scope. The IP layer MUST continue to accept datagrams
destined to a deprecated address since a deprecated address is still a destined to a deprecated address since a deprecated address is still a
valid address for the interface. An implementation MAY prevent any new valid address for the interface. An implementation MAY prevent any new
skipping to change at page 21, line 26 skipping to change at page 21, line 30
parameters such as MTU size and hop limit will be learned from both parameters such as MTU size and hop limit will be learned from both
Router Advertisements and the stateful autoconfiguration protocol. If Router Advertisements and the stateful autoconfiguration protocol. If
the same configuration information is provided by multiple sources, the the same configuration information is provided by multiple sources, the
value of this information should be consistent. However, it is not value of this information should be consistent. However, it is not
considered a fatal error if information received from multiple sources considered a fatal error if information received from multiple sources
is inconsistent. Hosts accept the union of all information received via is inconsistent. Hosts accept the union of all information received via
the stateless and stateful protocols. If inconsistent information is the stateless and stateful protocols. If inconsistent information is
learned from different sources, the most recently obtained values always learned from different sources, the most recently obtained values always
have precedence over information learned earlier. have precedence over information learned earlier.
OPEN ISSUES/TODO
o figure out how to do appendices in nroff
o add wording that indicates that addrconf is required to be turned on
by default?
o Add wording suggesting DAD and waiting for RAs be done in parallel.
SECURITY CONSIDERATIONS SECURITY CONSIDERATIONS
Stateless address autoconfiguration allows a host to connect to a Stateless address autoconfiguration allows a host to connect to a
network, configure an address and start communicating with other nodes network, configure an address and start communicating with other nodes
without ever registering or authenticating itself with the local site. without ever registering or authenticating itself with the local site.
Although this allows unauthorized users to connect to and use a network, Although this allows unauthorized users to connect to and use a network,
the threat is inherently present in the Internet architecture. Any node the threat is inherently present in the Internet architecture. Any node
with a physical attachment to a network can generate an address (using a with a physical attachment to a network can generate an address (using a
variety of ad hoc techniques) that provides connectivity. variety of ad hoc techniques) that provides connectivity.
skipping to change at page 22, line 4 skipping to change at page 21, line 43
network, configure an address and start communicating with other nodes network, configure an address and start communicating with other nodes
without ever registering or authenticating itself with the local site. without ever registering or authenticating itself with the local site.
Although this allows unauthorized users to connect to and use a network, Although this allows unauthorized users to connect to and use a network,
the threat is inherently present in the Internet architecture. Any node the threat is inherently present in the Internet architecture. Any node
with a physical attachment to a network can generate an address (using a with a physical attachment to a network can generate an address (using a
variety of ad hoc techniques) that provides connectivity. variety of ad hoc techniques) that provides connectivity.
The use of Duplicate Address Detection opens up the possibility of The use of Duplicate Address Detection opens up the possibility of
denial of service attacks. Any node can respond to Neighbor denial of service attacks. Any node can respond to Neighbor
Solicitations for a tentative address, causing the other node to reject Solicitations for a tentative address, causing the other node to reject
the address as a duplicate. This attack is similar to other attacks the address as a duplicate. This attack is similar to other attacks
involving the spoofing of Neighbor Discovery messages and can be involving the spoofing of Neighbor Discovery messages and can be
addressed by requiring that Neighbor Discovery packets be authenticated addressed by requiring that Neighbor Discovery packets be authenticated
[RFC1826]. [RFC1826].
REFERENCES REFERENCES
[RFC1826] [RFC1826] R. Atkinson. "IP Authentication Header", RFC 1826, August
R. Atkinson. "IP Authentication Header", RFC 1826, August 1995. 1995.
[IPv6-ETHER] [IPv6-ETHER] M. Crawford. "A Method for the Transmission of IPv6 Packets
M. Crawford. "A Method for the Transmission of IPv6 Packets over over Ethernet Networks", Internet Draft.
Ethernet Networks", Internet Draft.
[RFC1112] [RFC1112] S. Deering, "Host Extensions for IP Multicasting", RFC 1112,
S. Deering, "Host Extensions for IP Multicasting", RFC 1112,
August, 1989. August, 1989.
[ADDR-ARCH] [ADDR-ARCH] R. Hinden and S. Deering, "Internet Protocol Version (IPv6)
R. Hinden and S. Deering, "Internet Protocol Version (IPv6) Addressing Architecture", Internet Draft, May 1995, draft-
Addressing Architecture", Internet Draft, May 1995, draft-ietf- ietf-ipngwg-addr-arch-03.txt
ipngwg-addr-arch-03.txt
[DHCPv6] [DHCPv6] Internet Draft, Work in Progress.
Internet Draft, Work in Progress.
[DISCOVERY] [DISCOVERY] T. Narten, E. Nordmark and W. A. Simpson, "Neighbor
T. Narten, E. Nordmark and W. A. Simpson, "Neighbor Discovery Discovery for IP Version 6 (IPv6)", Internet Draft, September
for IP Version 6 (IPv6)", Internet Draft, September 1995, 1995, <draft-ietf-ipngwg-discovery-02.txt>
<draft-ietf-ipngwg-discovery-02.txt>
Acknowledgements Acknowledgements
The authors would like to thank the members of both the IPNG and The authors would like to thank the members of both the IPNG and
ADDRCONF working groups for their input. In particular, thanks to Jim ADDRCONF working groups for their input. In particular, thanks to Jim
Bound, Steve Deering, and Erik Nordmark. Bound, Steve Deering, and Erik Nordmark.
AUTHORS' ADDRESSES AUTHORS' ADDRESSES
Susan Thomson Thomas Narten Susan Thomson Thomas Narten
Bellcore IBM Corporation Bellcore IBM Corporation
445 South Street P.O. Box 12195 445 South Street P.O. Box 12195
Morristown, NJ 07960 Research Triangle Park, NC 27709-2195 Morristown, NJ 07960 Research Triangle Park, NC 27709-2195
USA USA USA USA
phone: +1 201-829-4514 phone: +1 919 254 7798 phone: +1 201-829-4514 phone: +1 919 254 7798
email: set@thumper.bellcore.com email: narten@vnet.ibm.com email: set@thumper.bellcore.com email: narten@vnet.ibm.com
APPENDIX: LOOPBACK SUPPRESSION & DUPLICATE ADDRESS DETECTION APPENDIX: LOOPBACK SUPPRESSION & DUPLICATE ADDRESS DETECTION
Determining whether a multicast solicitation was looped back to the Determining whether a received multicast solicitation was looped back to
sender or actually came from another node is implementation-dependent. the sender or actually came from another node is implementation-
A problematic case occurs when two interfaces attached to the same link dependent. A problematic case occurs when two interfaces attached to
happen to have the same token and link-layer address, and they both send the same link happen to have the same token and link-layer address, and
out packets with identical contents at roughly the same time (e.g., they both send out packets with identical contents at roughly the same
Neighbor Solicitations for a tentative address as part of Duplicate time (e.g., Neighbor Solicitations for a tentative address as part of
Address Detection messages). Although a receiver will receive both Duplicate Address Detection messages). Although a receiver will receive
packets, it cannot determine which packet was looped back and which both packets, it cannot determine which packet was looped back and which
packet came from the other node by simply comparing packet contents packet came from the other node by simply comparing packet contents
(i.e., the contents are identical). In this particular case, it is not (i.e., the contents are identical). In this particular case, it is not
necessary to know precisely which packet was looped back and which was necessary to know precisely which packet was looped back and which was
sent by another node; if one receives more solicitations than were sent, sent by another node; if one receives more solicitations than were sent,
the tentative address is a duplicate. However, the situation may not the tentative address is a duplicate. However, the situation may not
always be this straightforward. always be this straightforward.
The IPv4 multicast specification [RFC1112] recommends that the service The IPv4 multicast specification [RFC1112] recommends that the service
interface provide a way for an upper-layer protocol to inhibit local interface provide a way for an upper-layer protocol to inhibit local
delivery of packets sent to a multicast group that the sending host is a delivery of packets sent to a multicast group that the sending host is a
skipping to change at page 24, line 34 skipping to change at line 1031
Since it is generally impossible to know when another node is Since it is generally impossible to know when another node is
performing Duplicate Address Detection, this scenario can be performing Duplicate Address Detection, this scenario can be
avoided only if software suppression of loopback is permanently avoided only if software suppression of loopback is permanently
disabled. disabled.
Thus, to perform Duplicate Address Detection correctly in the case where Thus, to perform Duplicate Address Detection correctly in the case where
two interfaces are using the same link-layer address, an implementation two interfaces are using the same link-layer address, an implementation
must have a good understanding of the interface's multicast loopback must have a good understanding of the interface's multicast loopback
semantics, and the interface cannot discard received packets simply semantics, and the interface cannot discard received packets simply
because the source link-layer address is the same as the interfaces. because the source link-layer address is the same as the interfaces.
CHANGES SINCE PREVIOUS DOCUMENT
Changes since <draft-ietf-addrconf-ipv6-auto-06.txt> based on feedback
from the working group:
o minor wordsmithing
o made explicit that DAD could be turned off by system management.
o Fixed references to link-type specific where they had been written
as link-specific.
o clarified DAD should not be performed on anycast addresses
o allow an implementation to provide a switch that disables the use
of deprecated addresses for any new communications.
o Fixed two typos where "deprecation lifetime" was used rather than
"valid lifetime"
o made abstract more accurate
Changes since <draft-ietf-addrconf-ipv6-auto-04.txt> based on
feedback from the working group:
o modified DAD text re loopback suppression and added appendix
describing how DAD breaks if an interface discards all
received packets having the same source link-layer address as
the receiving interface. Added that DAD must be applied to
link-layer address for stateless.
o Numerous editorial/wordsmithing changes.
o security section added
o loosened requirement that interface be disabled if DAD fails.
Now say address shouldn't be assigned to interface. However,
if address was derived from interface token (e.g., link-layer
address), then interface should be disabled since its
effectively disabled in any case (no autoconfigured addresses
can be formed on this interface.)
o Use term "link-layer address" rather than "hardware address".
o Corrected typo in definition of link-local prefix (E8 ->
FE80).
o Removed AutoConfig variable, left as implementation issue how
user selects what type of autoconfig is desired, though
default is enabled
o Added DupAddrDetectTransmits variable specifying how many
transmissions to perform as part of DAD (defaults to 1, may be
0), and specify that ND's RetransTimer as the retransmit timer
between consecutive NSs.
o defined interface token to be a bit string.
o added text indicating that autoconfiguration only applies to
multicast-capable interfaces.
o changed name of OtherFlag variable to OtherConfigFlag
 End of changes. 30 change blocks. 
87 lines changed or deleted 75 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/