As per Relevance of the word duplicate, we have this rfc below:
Network Working Group S.
Request for Comments: 2462
Obsoletes: 1971 T.
Category: Standards Track
December 1998
IPv6 Stateless Address
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document specifies the steps a host takes in deciding how
autoconfigure its interfaces in IP version 6. The
process includes creating a link-local address and verifying
uniqueness on a link, determining what information should
autoconfigured (addresses, other information, or both), and in
case of addresses, whether they should be obtained through
stateless mechanism, the stateful mechanism, or both. This
defines the process for generating a link-local address, the
for generating site-local and global addresses via stateless
autoconfiguration, and the Duplicate Address Detection procedure.
details of autoconfiguration using the stateful protocol
specified elsewhere
Table of
1. INTRODUCTION............................................. 2
2. TERMINOLOGY.............................................. 4
2.1. Requirements........................................ 6
3. DESIGN GOALS............................................. 7
4. PROTOCOL OVERVIEW........................................ 8
4.1. Site Renumbering.................................... 10
5. PROTOCOL SPECIFICATION................................... 10
5.1. Node Configuration Variables........................ 11
5.2. Autoconfiguration-Related Variables................. 11
5.3. Creation of Link-Local Addresses.................... 12
Thomson & Narten Standards Track [Page 1]
RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998
5.4. Duplicate Address Detection......................... 13
5.4.1. Message Validation............................. 14
5.4.2. Sending Neighbor Solicitation Messages......... 14
5.4.3. Receiving Neighbor Solicitation Messages....... 15
5.4.4. Receiving Neighbor Advertisement Messages...... 16
5.4.5. When Duplicate Address Detection Fails......... 16
5.5. Creation of Global and Site-Local Addresses......... 16
5.5.1. Soliciting Router Advertisements............... 16
5.5.2. Absence of Router Advertisements............... 17
5.5.3. Router Advertisement Processing................ 17
5.5.4. Address Lifetime Expiry........................ 19
5.6. Configuration Consistency........................... 19
6. SECURITY CONSIDERATIONS.................................. 20
7. References............................................... 20
8. Acknowledgements and Authors' Addresses.................. 21
9. APPENDIX A: LOOPBACK SUPPRESSION & DUPLICATE
DETECTION.............................................. 22
10. APPENDIX B: CHANGES SINCE RFC 1971....................... 24
11. Full Copyright Statement................................. 25
1.
This document specifies the steps a host takes in deciding how
autoconfigure its interfaces in IP version 6. The
process includes creating a link-local address and verifying
uniqueness on a link, determining what information should
autoconfigured (addresses, other information, or both), and in
case of addresses, whether they should be obtained through
stateless mechanism, the stateful mechanism, or both. This
defines the process for generating a link-local address, the
for generating site-local and global addresses via stateless
autoconfiguration, and the Duplicate Address Detection procedure.
details of autoconfiguration using the stateful protocol
specified elsewhere
IPv6 defines both a stateful and stateless address
mechanism. Stateless autoconfiguration requires no
configuration of hosts, minimal (if any) configuration of routers
and no additional servers. The stateless mechanism allows a host
generate its own addresses using a combination of locally
information and information advertised by routers. Routers
prefixes that identify the subnet(s) associated with a link,
hosts generate an "interface identifier" that uniquely identifies
interface on a subnet. An address is formed by combining the two.
the absence of routers, a host can only generate link-
addresses. However, link-local addresses are sufficient for
communication among nodes attached to the same link
Thomson & Narten Standards Track [Page 2]
RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998
In the stateful autoconfiguration model, hosts obtain
addresses and/or configuration information and parameters from
server. Servers maintain a database that keeps track of
addresses have been assigned to which hosts. The
autoconfiguration protocol allows hosts to obtain addresses,
configuration information or both from a server. Stateless
stateful autoconfiguration complement each other. For example, a
can use stateless autoconfiguration to configure its own addresses
but use stateful autoconfiguration to obtain other information
Stateful autoconfiguration for IPv6 is the subject of future
[DHCPv6].
The stateless approach is used when a site is not
concerned with the exact addresses hosts use, so long as they
unique and properly routable. The stateful approach is used when
site requires tighter control over exact address assignments.
stateful and stateless address autoconfiguration may be
simultaneously. The site administrator specifies which type
autoconfiguration to use through the setting of appropriate fields
Router Advertisement messages [DISCOVERY].
IPv6 addresses are leased to an interface for a fixed (
infinite) length of time. Each address has an associated
that indicates how long the address is bound to an interface. When
lifetime expires, the binding (and address) become invalid and
address may be reassigned to another interface elsewhere in
Internet. To handle the expiration of address bindings gracefully,
address goes through two distinct phases while assigned to
interface. Initially, an address is "preferred", meaning that its
in arbitrary communication is unrestricted. Later, an address
"deprecated" in anticipation that its current interface binding
become invalid. While in a deprecated state, the use of an address
discouraged, but not strictly forbidden. New communication (e.g.,
the opening of a new TCP connection) should use a preferred
when possible. A deprecated address should be used only
applications that have been using it and would have
switching to another address without a service disruption
To insure that all configured addresses are likely to be unique on
given link, nodes run a "duplicate address detection" algorithm
addresses before assigning them to an interface. The
Address Detection algorithm is performed on all addresses
independent of whether they are obtained via stateless or
autoconfiguration. This document defines the Duplicate
Detection algorithm
Thomson & Narten Standards Track [Page 3]
RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998
The autoconfiguration process specified in this document applies
to hosts and not routers. Since host autoconfiguration
information advertised by routers, routers will need to be
by some other means. However, it is expected that routers
generate link-local addresses using the mechanism described in
document. In addition, routers are expected to successfully pass
Duplicate Address Detection procedure described in this document
all addresses prior to assigning them to an interface
Section 2 provides definitions for terminology used throughout
document. Section 3 describes the design goals that lead to
current autoconfiguration procedure. Section 4 provides an
of the protocol, while Section 5 describes the protocol in detail
2.
IP - Internet Protocol Version 6. The terms IPv4 and are
only in contexts where necessary to avoid ambiguity
node - a device that implements IP
router - a node that forwards IP packets not explicitly addressed
itself
host - any node that is not a router
upper layer - a protocol layer immediately above IP. Examples
transport protocols such as TCP and UDP, control protocols
as ICMP, routing protocols such as OSPF, and internet or lower
layer protocols being "tunneled" over (i.e., encapsulated in)
such as IPX, AppleTalk, or IP itself
link - a communication facility or medium over which nodes
communicate at the link layer, i.e., the layer immediately
IP. Examples are Ethernets (simple or bridged); PPP links
X.25, Frame Relay, or ATM networks; and internet (or higher
layer "tunnels", such as tunnels over IPv4 or IPv6 itself
interface - a node's attachment to a link
packet - an IP header plus payload
address - an IP-layer identifier for an interface or a set
interfaces
unicast address - an identifier for a single interface. A packet
to a unicast address is delivered to the interface identified
that address
Thomson & Narten Standards Track [Page 4]
RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998
multicast address - an identifier for a set of interfaces (
belonging to different nodes). A packet sent to a
address is delivered to all interfaces identified by
address
anycast address - an identifier for a set of interfaces (
belonging to different nodes). A packet sent to an
address is delivered to one of the interfaces identified by
address (the "nearest" one, according to the routing protocol'
measure of distance). See [ADDR-ARCH].
solicited-node multicast address - a multicast address to
Neighbor Solicitation messages are sent. The algorithm
computing the address is given in [DISCOVERY].
link-layer address - a link-layer identifier for an interface
Examples include IEEE 802 addresses for Ethernet links and E.164
addresses for ISDN links
link-local address - an address having link-only scope that can
used to reach neighboring nodes attached to the same link.
interfaces have a link-local unicast address
site-local address - an address having scope that is limited to
local site
global address - an address with unlimited scope
communication - any packet exchange among nodes that requires
the address of each node used in the exchange remain the
for the duration of the packet exchange. Examples are a
connection or a UDP request- response
tentative address - an address whose uniqueness on a link is
verified, prior to its assignment to an interface. A
address is not considered assigned to an interface in the
sense. An interface discards received packets addressed to
tentative address, but accepts Neighbor Discovery
related to Duplicate Address Detection for the
address
preferred address - an address assigned to an interface whose use
upper layer protocols is unrestricted. Preferred addresses
be used as the source (or destination) address of packets
from (or to) the interface
Thomson & Narten Standards Track [Page 5]
RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998
deprecated address - An address assigned to an interface whose use
discouraged, but not forbidden. A deprecated address should
longer be used as a source address in new communications,
packets sent from or to deprecated addresses are delivered
expected. A deprecated address may continue to be used as
source address in communications where switching to a
address causes hardship to a specific upper-layer
(e.g., an existing TCP connection).
valid address - a preferred or deprecated address. A valid
may appear as the source or destination address of a packet,
the internet routing system is expected to deliver packets
to a valid address to their intended recipients
invalid address - an address that is not assigned to any interface.
valid address becomes invalid when its valid lifetime expires
Invalid addresses should not appear as the destination or
address of a packet. In the former case, the internet
system will be unable to deliver the packet, in the later
the recipient of the packet will be unable to respond to it
preferred lifetime - the length of time that a valid address
preferred (i.e., the time until deprecation). When the
lifetime expires, the address becomes deprecated
valid lifetime - the length of time an address remains in the
state (i.e., the time until invalidation). The valid
must be greater then or equal to the preferred lifetime.
the valid lifetime expires, the address becomes invalid
interface identifier - a link-dependent identifier for an
that is (at least) unique per link [ADDR-ARCH].
address autoconfiguration combines an interface identifier
a prefix to form an address. From address autoconfiguration'
perspective, an interface identifier is a bit string of
length. The exact length of an interface identifier and the
it is created is defined in a separate link-type
document that covers issues related to the transmission of
over a particular link type (e.g., [IPv6-ETHER]). In
cases, the identifier will be the same as the interface's link
layer address
2.1.
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in
document, are to be interpreted as described in [KEYWORDS].
Thomson & Narten Standards Track [Page 6]
RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998
3. DESIGN
Stateless autoconfiguration is designed with the following goals
mind
o Manual configuration of individual machines before
them to the network should not be required. Consequently,
mechanism is needed that allows a host to obtain or
unique addresses for each of its interfaces.
autoconfiguration assumes that each interface can provide
unique identifier for that interface (i.e., an "
identifier"). In the simplest case, an interface
consists of the interface's link-layer address. An
identifier can be combined with a prefix to form an address
o Small sites consisting of a set of machines attached to a
link should not require the presence of a stateful server
router as a prerequisite for communicating. Plug-and-
communication is achieved through the use of link-
addresses. Link-local addresses have a well-known prefix
identifies the (single) shared link to which a set of
attach. A host forms a link-local address by appending
interface identifier to the link-local prefix
o A large site with multiple networks and routers should
require the presence of a stateful address configuration server
In order to generate site-local or global addresses, hosts
determine the prefixes that identify the subnets to which
attach. Routers generate periodic Router Advertisements
include options listing the set of active prefixes on a link
o Address configuration should facilitate the graceful
of a site's machines. For example, a site may wish to
all of its nodes when it switches to a new network
provider. Renumbering is achieved through the leasing
addresses to interfaces and the assignment of multiple
to the same interface. Lease lifetimes provide the
through which a site phases out old prefixes. The assignment
multiple addresses to an interface provides for a
period during which both a new address and the one being
out work simultaneously
o System administrators need the ability to specify
stateless autoconfiguration, stateful autoconfiguration, or
should be used. Router Advertisements include flags
which mechanisms a host should use
Thomson & Narten Standards Track [Page 7]
RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998
4. PROTOCOL
This section provides an overview of the typical steps that
place when an interface autoconfigures itself. Autoconfiguration
performed only on multicast-capable links and begins when
multicast-capable interface is enabled, e.g., during system startup
Nodes (both hosts and routers) begin the autoconfiguration process
generating a link-local address for the interface. A link-
address is formed by appending the interface's identifier to
well-known link-local prefix
Before the link-local address can be assigned to an interface
used, however, a node must attempt to verify that this "tentative
address is not already in use by another node on the link
Specifically, it sends a Neighbor Solicitation message containing
tentative address as the target. If another node is already
that address, it will return a Neighbor Advertisement saying so.
another node is also attempting to use the same address, it will
a Neighbor Solicitation for the target as well. The exact number
times the Neighbor Solicitation is (re)transmitted and the delay
between consecutive solicitations is link-specific and may be set
system management
If a node determines that its tentative link-local address is
unique, autoconfiguration stops and manual configuration of
interface is required. To simplify recovery in this case, it
be possible for an administrator to supply an alternate
identifier that overrides the default identifier in such a way
the autoconfiguration mechanism can then be applied using the
(presumably unique) interface identifier. Alternatively, link-
and other addresses will need to be configured manually
Once a node ascertains that its tentative link-local address
unique, it assigns it to the interface. At this point, the node
IP-level connectivity with neighboring nodes. The
autoconfiguration steps are performed only by hosts;
(auto)configuration of routers is beyond the scope of this document
The next phase of autoconfiguration involves obtaining a
Advertisement or determining that no routers are present. If
are present, they will send Router Advertisements that specify
sort of autoconfiguration a host should do. If no routers
present, stateful autoconfiguration should be invoked
Routers send Router Advertisements periodically, but the
between successive advertisements will generally be longer than
host performing autoconfiguration will want to wait [DISCOVERY].
obtain an advertisement quickly, a host sends one or more
Thomson & Narten Standards Track [Page 8]
RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998
Solicitations to the all-routers multicast group.
Advertisements contain two flags indicating what type of
autoconfiguration (if any) should be performed. A "managed
configuration" flag indicates whether hosts should use
autoconfiguration to obtain addresses. An "other
configuration" flag indicates whether hosts should use
autoconfiguration to obtain additional information (
addresses).
Router Advertisements also contain zero or more Prefix
options that contain information used by stateless
autoconfiguration to generate site-local and global addresses.
should be noted that the stateless and stateful
autoconfiguration fields in Router Advertisements are
independently of one another, and a host may use both stateful
stateless address autoconfiguration simultaneously. One
Information option field, the "autonomous address-
flag", indicates whether or not the option even applies to
autoconfiguration. If it does, additional option fields contain
subnet prefix together with lifetime values indicating how
addresses created from the prefix remain preferred and valid
Because routers generate Router Advertisements periodically,
will continually receive new advertisements. Hosts process
information contained in each advertisement as described above
adding to and refreshing information received in
advertisements
For safety, all addresses must be tested for uniqueness prior
their assignment to an interface. In the case of addresses
through stateless autoconfig, however, the uniqueness of an
is determined primarily by the portion of the address formed from
interface identifier. Thus, if a node has already verified
uniqueness of a link-local address, additional addresses created
the same interface identifier need not be tested individually.
contrast, all addresses obtained manually or via stateful
autoconfiguration should be tested for uniqueness individually.
accommodate sites that believe the overhead of performing
Address Detection outweighs its benefits, the use of
Address Detection can be disabled through the administrative
of a per-interface configuration flag
To speed the autoconfiguration process, a host may generate
link-local address (and verify its uniqueness) in parallel
waiting for a Router Advertisement. Because a router may
responding to a Router Solicitation for a few seconds, the total
needed to complete autoconfiguration can be significantly longer
the two steps are done serially
Thomson & Narten Standards Track [Page 9]
RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998
4.1. Site
Address leasing facilitates site renumbering by providing a
to time-out addresses assigned to interfaces in hosts. At present
upper layer protocols such as TCP provide no support for
end-point addresses while a connection is open. If an end-
address becomes invalid, existing connections break and
communication to the invalid address fails. Even when
use UDP as a transport protocol, addresses must generally remain
same during a packet exchange
Dividing valid addresses into preferred and deprecated
provides a way of indicating to upper layers that a valid address
become invalid shortly and that future communication using
address will fail, should the address's valid lifetime expire
communication ends. To avoid this scenario, higher layers should
a preferred address (assuming one of sufficient scope exists)
increase the likelihood that an address will remain valid for
duration of the communication. It is up to system administrators
set appropriate prefix lifetimes in order to minimize the impact
failed communication when renumbering takes place. The
period should be long enough that most, if not all,
are using the new address at the time an address becomes invalid
The IP layer is expected to provide a means for upper
(including applications) to select the most appropriate
address given a particular destination and possibly
constraints. An application may choose to select the source
itself before starting a new communication or may leave the
unspecified, in which case the upper networking layers will use
mechanism provided by the IP layer to choose a suitable address
the application's behalf
Detailed address selection rules are beyond the scope of
document
5. PROTOCOL
Autoconfiguration is performed on a per-interface basis
multicast-capable interfaces. For multihomed hosts
autoconfiguration is performed independently on each interface
Autoconfiguration applies primarily to hosts, with two exceptions
Routers are expected to generate a link-local address using
procedure outlined below. In addition, routers perform
Address Detection on all addresses prior to assigning them to
interface
Thomson & Narten Standards Track [Page 10]
RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998
5.1. Node Configuration
A node MUST allow the following autoconfiguration-related variable
be configured by system management for each multicast interface
The number of consecutive Neighbor
messages sent while performing Duplicate
Detection on a tentative address. A value of
indicates that Duplicate Address Detection is
performed on tentative addresses. A value of
indicates a single transmission with no follow
retransmissions
Default: 1, but may be overridden by a link-
specific value in the document that covers
related to the transmission of IP over a
link type (e.g., [IPv6-ETHER]).
Autoconfiguration also assumes the presence of
variable RetransTimer as defined in [DISCOVERY].
For autoconfiguration purposes,
specifies the delay between consecutive
Solicitation transmissions performed
Duplicate Address Detection (
DupAddrDetectTransmits is greater than 1), as
as the time a node waits after sending the
Neighbor Solicitation before ending the
Address Detection process
5.2. Autoconfiguration-Related
A host maintains a number of data structures and flags related
autoconfiguration. In the following, we present conceptual
and show how they are used to perform autoconfiguration. The
variables are used for demonstration purposes only, and
implementation is not required to have them, so long as its
behavior is consistent with that described in this document
Beyond the formation of a link-local address and using
Address Detection, how routers (auto)configure their interfaces
beyond the scope of this document
Hosts maintain the following variables on a per-interface basis
Thomson & Narten Standards Track [Page 11]
RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998
ManagedFlag Copied from the M flag field (i.e.,
"managed address configuration" flag) of the
recently received Router Advertisement message
The flag indicates whether or not addresses
to be configured using the
autoconfiguration mechanism. It starts out in
FALSE state
OtherConfigFlag Copied from the O flag field (i.e., the "
stateful configuration" flag) of the
recently received Router Advertisement message
The flag indicates whether or not
other than addresses is to be obtained using
stateful autoconfiguration mechanism. It
out in a FALSE state
In addition, when the value of the ManagedFlag
TRUE, the value of OtherConfigFlag is
TRUE as well. It is not a valid configuration
a host to use stateful address
to request addresses only, without also
other
information
A host also maintains a list of addresses together with
corresponding lifetimes. The address list contains
autoconfigured addresses and those configured manually
5.3. Creation of Link-Local
A node forms a link-local address whenever an interface
enabled. An interface may become enabled after any of
events
- The interface is initialized at system startup time
- The interface is reinitialized after a temporary
failure or after being temporarily disabled by
management
- The interface attaches to a link for the first time
- The interface becomes enabled by system management
having been
disabled
Thomson & Narten Standards Track [Page 12]
RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998
A link-local address is formed by prepending the well-known link
local prefix FE80::0 [ADDR-ARCH] (of appropriate length) to
interface identifier. If the interface identifier has a length of
bits, the interface identifier replaces the right-most N zero bits
the link-local prefix. If the interface identifier is more than 118
bits in length, autoconfiguration fails and manual configuration
required. Note that interface identifiers will typically be 64-
long and based on EUI-64 identifiers as described in [ADDR-ARCH].
A link-local address has an infinite preferred and valid lifetime;
is never
out
5.4. Duplicate Address
Duplicate Address Detection is performed on unicast addresses
to assigning them to an interface whose
variable is greater than zero. Duplicate Address Detection MUST
place on all unicast addresses, regardless of whether they
obtained through stateful, stateless or manual configuration,
the exception of the following cases
- Duplicate Address Detection MUST NOT be performed on
addresses
- Each individual unicast address SHOULD be tested for uniqueness
However, when stateless address autoconfiguration is used
address uniqueness is determined solely by the
identifier, assuming that subnet prefixes are assigned
(i.e., if all of an interface's addresses are generated from
same identifier, either all addresses or none of them will
duplicates). Thus, for a set of addresses formed from the
interface identifier, it is sufficient to check that the link
local address generated from the identifier is unique on
link. In such cases, the link-local address MUST be tested
uniqueness, and if no duplicate address is detected,
implementation MAY choose to skip Duplicate Address
for additional addresses derived from the same
identifier
The procedure for detecting duplicate addresses uses
Solicitation and Advertisement messages as described below. If
duplicate address is discovered during the procedure, the
cannot be assigned to the interface. If the address is derived
an interface identifier, a new identifier will need to be assigned
the interface, or all IP addresses for the interface will need to
manually configured. Note that the method for detecting
is not completely reliable, and it is possible that
Thomson & Narten Standards Track [Page 13]
RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998
addresses will still exist (e.g., if the link was partitioned
Duplicate Address Detection was performed).
An address on which the duplicate Address Detection Procedure
applied is said to be tentative until the procedure has
successfully. A tentative address is not considered "assigned to
interface" in the traditional sense. That is, the interface
accept Neighbor Solicitation and Advertisement messages
the tentative address in the Target Address field, but processes
packets differently from those whose Target Address matches
address assigned to the interface. Other packets addressed to
tentative address should be silently discarded
It should also be noted that Duplicate Address Detection must
performed prior to assigning an address to an interface in order
prevent multiple nodes from using the same address simultaneously
If a node begins using an address in parallel with Duplicate
Detection, and another node is already using the address, the
performing Duplicate Address Detection will erroneously
traffic intended for the other node, resulting in such
negative consequences as the resetting of open TCP connections
The following subsections describe specific tests a node performs
verify an address's uniqueness. An address is considered unique
none of the tests indicate the presence of a duplicate address
RetransTimer milliseconds after having sent
Neighbor Solicitations. Once an address is determined to be unique
it may be assigned to an interface
5.4.1. Message
A node MUST silently discard any Neighbor Solicitation
Advertisement message that does not pass the validity
specified in [DISCOVERY]. A solicitation that passes these
checks is called a valid solicitation or valid advertisement
5.4.2. Sending Neighbor Solicitation
Before sending a Neighbor Solicitation, an interface MUST join
all-nodes multicast address and the solicited-node multicast
of the tentative address. The former insures that the node
Neighbor Advertisements from other nodes already using the address
the latter insures that two nodes attempting to use the same
simultaneously detect each other's presence
To check an address, a node sends DupAddrDetectTransmits
Solicitations, each separated by RetransTimer milliseconds.
solicitation's Target Address is set to the address being checked
Thomson & Narten Standards Track [Page 14]
RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998
the IP source is set to the unspecified address and the
destination is set to the solicited-node multicast address of
target address
If the Neighbor Solicitation is the first message to be sent from
interface after interface (re)initialization, the node should
sending the message by a random delay between 0
MAX_RTR_SOLICITATION_DELAY as specified in [DISCOVERY]. This
to alleviate congestion when many nodes start up on the link at
same time, such as after a power failure, and may help to avoid
conditions when more than one node is trying to solicit for the
address at the same time. In order to improve the robustness of
Duplicate Address Detection algorithm, an interface MUST receive
process datagrams sent to the all-nodes multicast address
solicited-node multicast address of the tentative address
delaying transmission of the initial Neighbor Solicitation
5.4.3. Receiving Neighbor Solicitation
On receipt of a valid Neighbor Solicitation message on an interface
node behavior depends on whether the target address is tentative
not. If the target address is not tentative (i.e., it is assigned
the receiving interface), the solicitation is processed as
in [DISCOVERY]. If the target address is tentative, and the
address is a unicast address, the solicitation's sender is
address resolution on the target; the solicitation should be
ignored. Otherwise, processing takes place as described below.
all cases, a node MUST NOT respond to a Neighbor Solicitation for
tentative address
If the source address of the Neighbor Solicitation is the
address, the solicitation is from a node performing Duplicate
Detection. If the solicitation is from another node, the
address is a duplicate and should not be used (by either node).
the solicitation is from the node itself (because the node loops
multicast packets), the solicitation does not indicate the
of a duplicate address
Implementor's Note: many interfaces provide a way for upper layers
selectively enable and disable the looping back of multicast packets
The details of how such a facility is implemented may
Duplicate Address Detection from working correctly. See the
for further discussion
The following tests identify conditions under which a
address is not unique
Thomson & Narten Standards Track [Page 15]
RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998
- If a Neighbor Solicitation for a tentative address
received prior to having sent one, the tentative address is
duplicate. This condition occurs when two nodes run
Address Detection simultaneously, but transmit
solicitations at different times (e.g., by selecting
random delay values before transmitting an
solicitation).
- If the actual number of Neighbor Solicitations received
the number expected based on the loopback semantics (e.g.,
interface does not loopback packet, yet one or
solicitations was received), the tentative address is
duplicate. This condition occurs when two nodes run
Address Detection simultaneously and transmit solicitations
roughly the same time
5.4.4. Receiving Neighbor Advertisement
On receipt of a valid Neighbor Advertisement message on an interface
node behavior depends on whether the target address is tentative
matches a unicast or anycast address assigned to the interface.
the target address is assigned to the receiving interface,
solicitation is processed as described in [DISCOVERY]. If the
address is tentative, the tentative address is not unique
5.4.5. When Duplicate Address Detection
A tentative address that is determined to be a duplicate as
above, MUST NOT be assigned to an interface and the node SHOULD log
system management error. If the address is a link-local
formed from an interface identifier, the interface SHOULD
disabled
5.5. Creation of Global and Site-Local
Global and site-local addresses are formed by appending an
identifier to a prefix of appropriate length. Prefixes are
from Prefix Information options contained in Router Advertisements
Creation of global and site-local addresses and configuration
other parameters as described in this section SHOULD be
configurable. However, the processing described below MUST be
by default
5.5.1. Soliciting Router
Router Advertisements are sent periodically to the all-
multicast address. To obtain an advertisement quickly, a host
out Router Solicitations as described in [DISCOVERY].
Thomson & Narten Standards Track [Page 16]
RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998
5.5.2. Absence of Router
If a link has no routers, a host MUST attempt to use
autoconfiguration to obtain addresses and other
information. An implementation MAY provide a way to disable
invocation of stateful autoconfiguration in this case, but
default SHOULD be enabled. From the perspective
autoconfiguration, a link has no routers if no Router
are received after having sent a small number of Router
as described in [DISCOVERY].
5.5.3. Router Advertisement
On receipt of a valid Router Advertisement (as defined
[DISCOVERY]), a host copies the value of the advertisement's M
into ManagedFlag. If the value of ManagedFlag changes from FALSE
TRUE, and the host is not already running the stateful
autoconfiguration protocol, the host should invoke the
address autoconfiguration protocol, requesting both
information and other information. If the value of the
changes from TRUE to FALSE, the host should continue running
stateful address autoconfiguration, i.e., the change in the value
the ManagedFlag has no effect. If the value of the flag
unchanged, no special action takes place. In particular, a host
NOT reinvoke stateful address configuration if it is
participating in the stateful protocol as a result of an
advertisement
An advertisement's O flag field is processed in an analogous manner
A host copies the value of the O flag into OtherConfigFlag. If
value of OtherConfigFlag changes from FALSE to TRUE, the host
invoke the stateful autoconfiguration protocol,
information (excluding addresses if ManagedFlag is set to FALSE).
the value of the OtherConfigFlag changes from TRUE to FALSE, the
should continue running the stateful address
protocol, i.e., the change in the value of OtherConfigFlag has
effect. If the value of the flag stays unchanged, no special
takes place. In particular, a host MUST NOT reinvoke
configuration if it is already participating in the stateful
as a result of an earlier advertisement
For each Prefix-Information option in the Router Advertisement
a) If the Autonomous flag is not set, silently ignore
Prefix
option
Thomson & Narten Standards Track [Page 17]
RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998
b) If the prefix is the link-local prefix, silently ignore
Prefix Information option
c) If the preferred lifetime is greater than the valid lifetime
silently ignore the Prefix Information option. A node MAY wish
log a system management error in this case
d) If the prefix advertised does not match the prefix of an
already in the list, and the Valid Lifetime is not 0, form
address (and add it to the list) by combining the
prefix with the link's interface identifier as follows
| 128 - N bits | N bits |
+---------------------------------------+------------------------+
| link prefix | interface identifier |
+----------------------------------------------------------------+
If the sum of the prefix length and interface identifier
does not equal 128 bits, the Prefix Information option MUST
ignored. An implementation MAY wish to log a system
error in this case. It is the responsibility of the
administrator to insure that the lengths of prefixes contained
Router Advertisements are consistent with the length of
identifiers for that link type. Note that interface
will typically be 64-bits long and based on EUI-64 identifiers
described in [ADDR-ARCH].
If an address is formed successfully, the host adds it to
list of addresses assigned to the interface, initializing
preferred and valid lifetime values from the Prefix
option
e) If the advertised prefix matches the prefix of an
address (i.e., one obtained via stateless or stateful
autoconfiguration) in the list of addresses associated with
interface, the specific action to perform depends on the
Lifetime in the received advertisement and the
associated with the previously autoconfigured address (which
call StoredLifetime in the discussion that follows):
1) If the received Lifetime is greater than 2 hours or
than StoredLifetime, update the stored Lifetime of
corresponding address
2) If the StoredLifetime is less than or equal to 2 hours and
received Lifetime is less than or equal to StoredLifetime
ignore the prefix, unless the Router Advertisement from
Thomson & Narten Standards Track [Page 18]
RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998
this Prefix Information option was obtained has
authenticated (e.g., via IPSec [RFC2402]). If the
Advertisment was authenticated, the StoredLifetime should
set to the Lifetime in the received option
3) Otherwise, reset the stored Lifetime in the
address to two hours
The above rules address a specific denial of service attack
which a bogus advertisement could contain prefixes with
small Valid Lifetimes. Without the above rules, a
unauthenticated advertisement containing bogus Prefix
options with short Lifetimes could cause all of a node'
addresses to expire prematurely. The above rules insure
legitimate advertisements (which are sent periodically)
"cancel" the short lifetimes before they actually take effect
5.5.4. Address Lifetime
A preferred address becomes deprecated when its preferred
expires. A deprecated address SHOULD continue to be used as a
address in existing communications, but SHOULD NOT be used in
communications if an alternate (non-deprecated) address is
and has sufficient scope. IP and higher layers (e.g., TCP, UDP)
continue to accept datagrams destined to a deprecated address since
deprecated address is still a valid address for the interface.
implementation MAY prevent any new communication from using
deprecated address, but system management MUST have the ability
disable such a facility, and the facility MUST be disabled
default
An address (and its association with an interface) becomes
when its valid lifetime expires. An invalid address MUST NOT be
as a source address in outgoing communications and MUST NOT
recognized as a destination on a receiving interface
5.6. Configuration
It is possible for hosts to obtain address information using
stateless and stateful protocols since both may be enabled at
same time. It is also possible that the values of
configuration parameters such as MTU size and hop limit will
learned from both Router Advertisements and the
autoconfiguration protocol. If the same configuration information
provided by multiple sources, the value of this information should
consistent. However, it is not considered a fatal error
information received from multiple sources is inconsistent.
accept the union of all information received via the stateless
Thomson & Narten Standards Track [Page 19]
RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998
stateful protocols. If inconsistent information is learned
sources, the most recently obtained values always have
over information learned earlier
6. SECURITY
Stateless address autoconfiguration allows a host to connect to
network, configure an address and start communicating with
nodes without ever registering or authenticating itself with
local site. Although this allows unauthorized users to connect
and use a network, the threat is inherently present in
Internet architecture. Any node with a physical attachment
a network can generate an address (using a variety of ad
techniques) that provides connectivity
The use of Duplicate Address Detection opens up the possibility
denial of service attacks. Any node can respond to
Solicitations for a tentative address, causing the other node
reject the address as a duplicate. This attack is similar to
attacks involving the spoofing of Neighbor Discovery messages and
be addressed by requiring that Neighbor Discovery packets
authenticated [RFC2402].
7.
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header",
RFC 2402, November 1998.
[IPv6-ETHER] Crawford, M., "A Method for the Transmission
IPv6 Packets over Ethernet Networks", RFC 2464,
December 1998.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to
Requirement Levels", BCP 14, RFC 2119,
1997.
[RFC1112] Deering, S., "Host Extensions for IP Multicasting",
5, RFC 1112,
1989.
[ADDR-ARCH] Hinden, R. and S. Deering, "Internet Protocol
(IPv6) Addressing Architecture", RFC 2373, July 1998
[DHCPv6] Bound, J. and C. Perkins, "Dynamic Host
Protocol for IPv6 (DHCPv6)", Work in Progress
Thomson & Narten Standards Track [Page 20]
RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998
[DISCOVERY] Narten, T., Nordmark, E. and W. Simpson, "
Discovery for IP Version 6 (IPv6)", RFC 2461,
1998.
8.
The authors would like to thank the members of both the IPNG
ADDRCONF working groups for their input. In particular, thanks to
Bound, Steve Deering, Richard Draves, and Erik Nordmark. Thanks
goes to John Gilmore for alerting the WG of the "0 Lifetime
Advertisement" denial of service attack vulnerability; this
incorporates changes that address this vulnerability
AUTHORS'
Susan
445 South
Morristown, NJ 07960
Phone: +1 201-829-4514
EMail: set@thumper.bellcore.
Thomas
IBM
P.O. Box 12195
Research Triangle Park, NC 27709-2195
Phone: +1 919 254 7798
EMail: narten@raleigh.ibm.
Thomson & Narten Standards Track [Page 21]
RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998
9. APPENDIX A: LOOPBACK SUPPRESSION & DUPLICATE ADDRESS
Determining whether a received multicast solicitation was looped
to the sender or actually came from another node is implementation
dependent. A problematic case occurs when two interfaces attached
the same link happen to have the same identifier and link-
address, and they both send out packets with identical contents
roughly the same time (e.g., Neighbor Solicitations for a
address as part of Duplicate Address Detection messages). Although
receiver will receive both packets, it cannot determine which
was looped back and which packet came from the other node by
comparing packet contents (i.e., the contents are identical). In
particular case, it is not necessary to know precisely which
was looped back and which was sent by another node; if one
more solicitations than were sent, the tentative address is
duplicate. However, the situation may not always be
straightforward
The IPv4 multicast specification [RFC1112] recommends that
service interface provide a way for an upper-layer protocol
inhibit local delivery of packets sent to a multicast group that
sending host is a member of. Some applications know that there
be no other group members on the same host, and suppressing
prevents them from having to receive (and discard) the packets
themselves send out. A straightforward way to implement
facility is to disable loopback at the hardware level (if
by the hardware), with packets looped back (if requested)
software. On interfaces in which the hardware itself
loopbacks, a node running Duplicate Address Detection simply
the number of Neighbor Solicitations received for a tentative
and compares them with the number expected. If there is a mismatch
the tentative address is a duplicate
In those cases where the hardware cannot suppress loopbacks, however
one possible software heuristic to filter out unwanted loopbacks
to discard any received packet whose link-layer source address is
same as the receiving interface's. Unfortunately, use of
criteria also results in the discarding of all packets sent
another node using the same link-layer address. Duplicate
Detection will fail on interfaces that filter received packets
this manner
o If a node performing Duplicate Address Detection
received packets having the same source link-layer address
the receiving interface, it will also discard packets from
nodes also using the same link-layer address, including
Advertisement and Neighbor Solicitation messages required
make Duplicate Address Detection work correctly.
Thomson & Narten Standards Track [Page 22]
RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998
particular problem can be avoided by temporarily disabling
software suppression of loopbacks while a node
Duplicate Address Detection
o If a node that is already using a particular IP address
received packets having the same link-layer source address
the interface, it will also discard Duplicate
Detection-related Neighbor Solicitation messages sent by
node also using the same link-layer address. Consequently
Duplicate Address Detection will fail, and the other node
configure a non-unique address. Since it is generally
to know when another node is performing Duplicate
Detection, this scenario can be avoided only if
suppression of loopback is permanently disabled
Thus, to perform Duplicate Address Detection correctly in the
where two interfaces are using the same link-layer address,
implementation must have a good understanding of the interface'
multicast loopback semantics, and the interface cannot
received packets simply because the source link-layer address is
same as the interfaces
Thomson & Narten Standards Track [Page 23]
RFC 2462 IPv6 Stateless Address Autoconfiguration December 1998
10. APPENDIX B: CHANGES SINCE RFC 1971
o Changed document to use term "interface identifier" rather
"interface token" for consistency with other IPv6 documents
o Clarified definition of deprecated address to make clear it is
to continue sending to or from deprecated addresses
o Reworded section 5.4 for clarity (no substantive change).
o Added rules to Section 5.5.3 Router Advertisement processing
address potential denial-of-service attack when prefixes
advertised with very short Lifetimes
o Clarified wording in Section 5.5.4 to make clear that all
layer protocols must process (i.e., send and receive) packets
to deprecated addresses
