draft-ietf-ipv6-rfc2462bis-05.txt   draft-ietf-ipv6-rfc2462bis-06.txt 
IETF IPv6 Working Group S. Thomson IETF IPv6 Working Group S. Thomson
Internet-Draft Cisco Internet-Draft Cisco
Expires: February 9, 2005 T. Narten Expires: March 4, 2005 T. Narten
IBM IBM
T. Jinmei T. Jinmei
Toshiba Toshiba
August 11, 2004 September 3, 2004
IPv6 Stateless Address Autoconfiguration IPv6 Stateless Address Autoconfiguration
draft-ietf-ipv6-rfc2462bis-05.txt draft-ietf-ipv6-rfc2462bis-06.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, each author represents that any
patent or other IPR claims of which I am aware have been disclosed, applicable patent or other IPR claims of which he or she is aware
or will be disclosed, and any of which I become aware will be have been or will be disclosed, and any of which he or she becomes
disclosed, in accordance with RFC 3668. aware will be disclosed, in accordance with Section 6 of RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 9, 2005. This Internet-Draft will expire on March 4, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004).
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 can be uniqueness on a link, determining what information can be
autoconfigured (addresses, other information, or both), and in the autoconfigured (addresses, other information, or both), and in the
case of addresses, whether they can be obtained through the stateless case of addresses, whether they can be obtained through the stateless
mechanism, the stateful mechanism, or both. This document defines mechanism, the stateful mechanism, or both. This document defines
the process for generating a link-local address, the process for the process for generating a link-local address, the process for
generating global addresses via stateless address autoconfiguration, generating global addresses via stateless address autoconfiguration,
and the Duplicate Address Detection procedure. The details of and the Duplicate Address Detection procedure. The details of
autoconfiguration using the stateful protocol is specified in RFC autoconfiguration using the stateful protocol are specified in RFC
3315 and RFC 3736. 3315; an alternative way of using the stateful protocol to deliver
'other information' only is specified in RFC 3736.
Table of Contents Table of Contents
1. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. TERMINOLOGY . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. TERMINOLOGY . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . 7 2.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . 7
3. DESIGN GOALS . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. DESIGN GOALS . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. PROTOCOL OVERVIEW . . . . . . . . . . . . . . . . . . . . . . 8 4. PROTOCOL OVERVIEW . . . . . . . . . . . . . . . . . . . . . . 8
4.1 Site Renumbering . . . . . . . . . . . . . . . . . . . . . 10 4.1 Site Renumbering . . . . . . . . . . . . . . . . . . . . . 11
5. PROTOCOL SPECIFICATION . . . . . . . . . . . . . . . . . . . . 11 5. PROTOCOL SPECIFICATION . . . . . . . . . . . . . . . . . . . . 11
5.1 Node Configuration Variables . . . . . . . . . . . . . . . 11 5.1 Node Configuration Variables . . . . . . . . . . . . . . . 12
5.2 Autoconfiguration-Related Structures . . . . . . . . . . . 12 5.2 Autoconfiguration-Related Structures . . . . . . . . . . . 12
5.3 Creation of Link-Local Addresses . . . . . . . . . . . . . 12 5.3 Creation of Link-Local Addresses . . . . . . . . . . . . . 12
5.4 Duplicate Address Detection . . . . . . . . . . . . . . . 13 5.4 Duplicate Address Detection . . . . . . . . . . . . . . . 13
5.4.1 Message Validation . . . . . . . . . . . . . . . . . . 14 5.4.1 Message Validation . . . . . . . . . . . . . . . . . . 15
5.4.2 Sending Neighbor Solicitation Messages . . . . . . . . 14 5.4.2 Sending Neighbor Solicitation Messages . . . . . . . . 15
5.4.3 Receiving Neighbor Solicitation Messages . . . . . . . 16 5.4.3 Receiving Neighbor Solicitation Messages . . . . . . . 16
5.4.4 Receiving Neighbor Advertisement Messages . . . . . . 17 5.4.4 Receiving Neighbor Advertisement Messages . . . . . . 17
5.4.5 When Duplicate Address Detection Fails . . . . . . . . 17 5.4.5 When Duplicate Address Detection Fails . . . . . . . . 17
5.5 Creation of Global Addresses . . . . . . . . . . . . . . . 18 5.5 Creation of Global Addresses . . . . . . . . . . . . . . . 18
5.5.1 Soliciting Router Advertisements . . . . . . . . . . . 18 5.5.1 Soliciting Router Advertisements . . . . . . . . . . . 18
5.5.2 Absence of Router Advertisements . . . . . . . . . . . 18 5.5.2 Absence of Router Advertisements . . . . . . . . . . . 18
5.5.3 Router Advertisement Processing . . . . . . . . . . . 18 5.5.3 Router Advertisement Processing . . . . . . . . . . . 19
5.5.4 Address Lifetime Expiry . . . . . . . . . . . . . . . 20 5.5.4 Address Lifetime Expiry . . . . . . . . . . . . . . . 21
5.6 Configuration Consistency . . . . . . . . . . . . . . . . 21 5.6 Configuration Consistency . . . . . . . . . . . . . . . . 22
5.7 Retaining Configured Addresses for Stability . . . . . . . 22 5.7 Retaining Configured Addresses for Stability . . . . . . . 22
6. SECURITY CONSIDERATIONS . . . . . . . . . . . . . . . . . . . 22 6. SECURITY CONSIDERATIONS . . . . . . . . . . . . . . . . . . . 23
7. IANA CONSIDERATIONS . . . . . . . . . . . . . . . . . . . . . 23 7. IANA CONSIDERATIONS . . . . . . . . . . . . . . . . . . . . . 23
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.1 Normative References . . . . . . . . . . . . . . . . . . . . 23 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 24
9.2 Informative References . . . . . . . . . . . . . . . . . . . 23 9.2 Informative References . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
A. LOOPBACK SUPPRESSION & DUPLICATE ADDRESS DETECTION . . . . . . 25 A. LOOPBACK SUPPRESSION & DUPLICATE ADDRESS DETECTION . . . . . . 25
B. CHANGES SINCE RFC 1971 . . . . . . . . . . . . . . . . . . . . 26 B. CHANGES SINCE RFC 1971 . . . . . . . . . . . . . . . . . . . . 27
C. CHANGES SINCE RFC 2462 . . . . . . . . . . . . . . . . . . . . 27 C. CHANGES SINCE RFC 2462 . . . . . . . . . . . . . . . . . . . . 27
D. CHANGE HISTORY . . . . . . . . . . . . . . . . . . . . . . . . 28 D. CHANGE HISTORY . . . . . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . 31 Intellectual Property and Copyright Statements . . . . . . . . 31
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 (IPv6). The autoconfigure its interfaces in IP version 6 (IPv6). The
autoconfiguration process includes creating a link-local address and autoconfiguration process includes creating a link-local address and
verifying its uniqueness on a link, determining what information can verifying its uniqueness on a link, determining what information can
skipping to change at page 4, line 13 skipping to change at page 4, line 13
maintain state of each client that the server provides with the maintain state of each client that the server provides with the
configuration information. configuration information.
The stateless approach is used when a site is not particularly The stateless approach is used when a site is not particularly
concerned with the exact addresses hosts use, so long as they are concerned with the exact addresses hosts use, so long as they are
unique and properly routable. The stateful approach is used when a unique and properly routable. The stateful approach is used when a
site requires tighter control over exact address assignments. Both site requires tighter control over exact address assignments. Both
stateful and stateless address autoconfiguration may be used stateful and stateless address autoconfiguration may be used
simultaneously. The site administrator specifies which type of simultaneously. The site administrator specifies which type of
autoconfiguration is available through the setting of appropriate autoconfiguration is available through the setting of appropriate
fields in Router Advertisement messages [RFC2461]. fields in Router Advertisement messages [I-D.ietf-ipv6-2461bis].
IPv6 addresses are leased to an interface for a fixed (possibly IPv6 addresses are leased to an interface for a fixed (possibly
infinite) length of time. Each address has an associated lifetime infinite) length of time. Each address has an associated lifetime
that indicates how long the address is bound to an interface. When a that indicates how long the address is bound to an interface. When a
lifetime expires, the binding (and address) become invalid and the lifetime expires, the binding (and address) become invalid and the
address may be reassigned to another interface elsewhere in the address may be reassigned to another interface elsewhere in the
Internet. To handle the expiration of address bindings gracefully, Internet. To handle the expiration of address bindings gracefully,
an address goes through two distinct phases while assigned to an an address goes through two distinct phases while assigned to an
interface. Initially, an address is "preferred", meaning that its interface. Initially, an address is "preferred", meaning that its
use in arbitrary communication is unrestricted. Later, an address use in arbitrary communication is unrestricted. Later, an address
skipping to change at page 5, line 28 skipping to change at page 5, line 28
upper layer - a protocol layer immediately above IP. Examples are upper layer - a protocol layer immediately above IP. Examples are
transport protocols such as TCP and UDP, control protocols such as transport protocols such as TCP and UDP, control protocols such as
ICMP, routing protocols such as OSPF, and internet or lower-layer ICMP, routing protocols such as OSPF, and internet or lower-layer
protocols being "tunneled" over (i.e., encapsulated in) IP such as protocols being "tunneled" over (i.e., encapsulated in) IP such as
IPX, AppleTalk, or IP itself. IPX, AppleTalk, or IP itself.
link - a communication facility or medium over which nodes can link - a communication facility or medium over which nodes can
communicate at the link layer, i.e., the layer immediately below communicate at the link layer, i.e., the layer immediately below
IP. Examples are Ethernets (simple or bridged); PPP links; X.25, IP. Examples are Ethernets (simple or bridged); PPP links; X.25,
Frame Relay, or ATM networks; and internet (or higher) layer Frame Relay, or ATM networks; and internet (or higher) layer
"tunnels", such as tunnels over IPv4 or IPv6 itself. "tunnels", such as tunnels over IPv4 or IPv6 itself. The protocol
described in this document will be used on all types of links
unless specified otherwise in the link type specific document
describing how to operate IP on the link in line with
[I-D.ietf-ipv6-2461bis].
interface - a node's attachment to a link. interface - a node's attachment to a link.
packet - an IP header plus payload. packet - an IP header plus payload.
address - an IP-layer identifier for an interface or a set of address - an IP-layer identifier for an interface or a set of
interfaces. interfaces.
unicast address - an identifier for a single interface. A packet unicast address - an identifier for a single interface. A packet
sent to a unicast address is delivered to the interface identified sent to a unicast address is delivered to the interface identified
skipping to change at page 8, line 36 skipping to change at page 8, line 41
provider. Renumbering is achieved through the leasing of provider. Renumbering is achieved through the leasing of
addresses to interfaces and the assignment of multiple addresses addresses to interfaces and the assignment of multiple addresses
to the same interface. Lease lifetimes provide the mechanism to the same interface. Lease lifetimes provide the mechanism
through which a site phases out old prefixes. The assignment of through which a site phases out old prefixes. The assignment of
multiple addresses to an interface provides for a transition multiple addresses to an interface provides for a transition
period during which both a new address and the one being phased period during which both a new address and the one being phased
out work simultaneously. out work simultaneously.
o System administrators need the ability to specify whether o System administrators need the ability to specify whether
stateless autoconfiguration, stateful autoconfiguration, or both stateless autoconfiguration, stateful autoconfiguration, or both
are available. Router Advertisements include flags specifying are available. Router Advertisements include flags which can be
which mechanisms a host can use. used to indicate which mechanisms are available.
4. PROTOCOL OVERVIEW 4. PROTOCOL OVERVIEW
This section provides an overview of the typical steps that take This section provides an overview of the typical steps that take
place when an interface autoconfigures itself. Autoconfiguration is place when an interface autoconfigures itself. Autoconfiguration is
performed only on multicast-capable links and begins when a performed only on multicast-capable links and begins when a
multicast-capable interface is enabled, e.g., during system startup. multicast-capable interface is enabled, e.g., during system startup.
Nodes (both hosts and routers) begin the autoconfiguration process by Nodes (both hosts and routers) begin the autoconfiguration process by
generating a link-local address for the interface. A link-local generating a link-local address for the interface. A link-local
address is formed by appending the interface's identifier to the address is formed by appending the interface's identifier to the
skipping to change at page 9, line 38 skipping to change at page 9, line 43
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 Advertisement or determining that no routers are present. If routers
are present, they will send Router Advertisements that specify what are present, they will send Router Advertisements that specify what
sort of autoconfiguration a host can do. Note that stateful sort of autoconfiguration a host can do. Note that stateful
autoconfiguration may still be available even if no routers are autoconfiguration may still be available even if no routers are
present. present.
Routers send Router Advertisements periodically, but the delay Routers send Router Advertisements periodically, but the delay
between successive advertisements will generally be longer than a between successive advertisements will generally be longer than a
host performing autoconfiguration will want to wait [RFC2461]. To host performing autoconfiguration will want to wait
obtain an advertisement quickly, a host sends one or more Router [I-D.ietf-ipv6-2461bis]. To obtain an advertisement quickly, a host
Solicitations to the all-routers multicast group. Router sends one or more Router Solicitations to the all-routers multicast
Advertisements contain two flags indicating what type of stateful group. Router Advertisements contain two flags indicating what type
autoconfiguration (if any) is available. A "managed address of stateful autoconfiguration (if any) is available. A "managed
configuration (M)" flag indicates whether hosts can use stateful address configuration (M)" flag indicates whether hosts can use
autoconfiguration [RFC3315] to obtain addresses. An "other stateful stateful autoconfiguration [RFC3315] to obtain addresses. An "other
configuration (O)" flag indicates whether hosts can use stateful stateful configuration (O)" flag indicates whether hosts can use
autoconfiguration [RFC3736] to obtain additional information stateful autoconfiguration [RFC3736] to obtain additional information
(excluding addresses). (excluding addresses).
The details of how a host may use the M flag, including any use of The details of how a host may use the M flag, including any use of
the "on" and "off" transitions for this flag, to control the use of the "on" and "off" transitions for this flag, to control the use of
the stateful protocol for address assignment will be described in a the stateful protocol for address assignment will be described in a
separate document. Similarly, the details of how a host may use the separate document. Similarly, the details of how a host may use the
O flag, including any use of the "on" and "off" transitions for this O flag, including any use of the "on" and "off" transitions for this
flag, to control the use of the stateful protocol for getting other flag, to control the use of the stateful protocol for getting other
configuration information will be described in a separate document. configuration information will be described in a separate document.
However a host uses the M and O flags, and local configuration to
control autoconfiguration, the default setting will result in
received Router Advertisements being processed for stateless address
autoconfiguration.
Router Advertisements also contain zero or more Prefix Information Router Advertisements also contain zero or more Prefix Information
options that contain information used by stateless address options that contain information used by stateless address
autoconfiguration to generate global addresses. It should be noted autoconfiguration to generate global addresses. It should be noted
that the stateless and stateful address autoconfiguration fields in that the stateless and stateful address autoconfiguration fields in
Router Advertisements are processed independently of one another, and Router Advertisements are processed independently of one another, and
a host may use both stateful and stateless address autoconfiguration a host may use both stateful and stateless address autoconfiguration
simultaneously. One Prefix Information option field, the "autonomous simultaneously. One Prefix Information option field, the "autonomous
address-configuration flag", indicates whether or not the option even address-configuration flag", indicates whether or not the option even
applies to stateless autoconfiguration. If it does, additional applies to stateless autoconfiguration. If it does, additional
skipping to change at page 11, line 30 skipping to change at page 11, line 39
The IP layer is expected to provide a means for upper layers The IP layer is expected to provide a means for upper layers
(including applications) to select the most appropriate source (including applications) to select the most appropriate source
address given a particular destination and possibly other address given a particular destination and possibly other
constraints. An application may choose to select the source address constraints. An application may choose to select the source address
itself before starting a new communication or may leave the address itself before starting a new communication or may leave the address
unspecified, in which case the upper networking layers will use the unspecified, in which case the upper networking layers will use the
mechanism provided by the IP layer to choose a suitable address on mechanism provided by the IP layer to choose a suitable address on
the application's behalf. the application's behalf.
Detailed address selection rules are beyond the scope of this Detailed address selection rules are beyond the scope of this
document. document and are described in [RFC3484].
5. PROTOCOL SPECIFICATION 5. PROTOCOL SPECIFICATION
Autoconfiguration is performed on a per-interface basis on Autoconfiguration is performed on a per-interface basis on
multicast-capable interfaces. For multihomed hosts, multicast-capable interfaces. For multihomed hosts,
autoconfiguration is performed independently on each interface. autoconfiguration is performed independently on each interface.
Autoconfiguration applies primarily to hosts, with two exceptions. Autoconfiguration applies primarily to hosts, with two exceptions.
Routers are expected to generate a link-local address using the Routers are expected to generate a link-local address using the
procedure outlined below. In addition, routers perform Duplicate procedure outlined below. In addition, routers perform Duplicate
Address Detection on all addresses prior to assigning them to an Address Detection on all addresses prior to assigning them to an
interface. interface.
5.1 Node Configuration Variables 5.1 Node Configuration Variables
A node MUST allow the following autoconfiguration-related variable to A node MUST allow the following autoconfiguration-related variable to
be configured by system management for each multicast interface: be configured by system management for each multicast-capable
interface:
DupAddrDetectTransmits DupAddrDetectTransmits
The number of consecutive Neighbor Solicitation messages sent The number of consecutive Neighbor Solicitation messages sent
while performing Duplicate Address Detection on a tentative while performing Duplicate Address Detection on a tentative
address. A value of zero indicates that Duplicate Address address. A value of zero indicates that Duplicate Address
Detection is not performed on tentative addresses. A value of one Detection is not performed on tentative addresses. A value of one
indicates a single transmission with no follow up retransmissions. indicates a single transmission with no follow up retransmissions.
Default: 1, but may be overridden by a link-type specific value in Default: 1, but may be overridden by a link-type specific value in
the document that covers issues related to the transmission of IP the document that covers issues related to the transmission of IP
over a particular link type (e.g., [RFC2464]). over a particular link type (e.g., [RFC2464]).
Autoconfiguration also assumes the presence of the variable Autoconfiguration also assumes the presence of the variable
RetransTimer as defined in [RFC2461]. For autoconfiguration RetransTimer as defined in [I-D.ietf-ipv6-2461bis]. For
purposes, RetransTimer specifies the delay between consecutive autoconfiguration purposes, RetransTimer specifies the delay
Neighbor Solicitation transmissions performed during Duplicate between consecutive Neighbor Solicitation transmissions performed
Address Detection (if DupAddrDetectTransmits is greater than 1), during Duplicate Address Detection (if DupAddrDetectTransmits is
as well as the time a node waits after sending the last Neighbor greater than 1), as well as the time a node waits after sending
Solicitation before ending the Duplicate Address Detection the last Neighbor Solicitation before ending the Duplicate Address
process. Detection process.
5.2 Autoconfiguration-Related Structures 5.2 Autoconfiguration-Related Structures
Beyond the formation of a link-local address and using Duplicate Beyond the formation of a link-local address and using Duplicate
Address Detection, how routers (auto)configure their interfaces is Address Detection, how routers (auto)configure their interfaces is
beyond the scope of this document. beyond the scope of this document.
A host maintains a list of addresses together with their A host maintains a list of addresses together with their
corresponding lifetimes. The address list contains both corresponding lifetimes. The address list contains both
autoconfigured addresses and those configured manually. autoconfigured addresses and those configured manually.
skipping to change at page 12, line 47 skipping to change at page 13, line 13
- The interface is initialized at system startup time. - The interface is initialized at system startup time.
- The interface is reinitialized after a temporary interface failure - The interface is reinitialized after a temporary interface failure
or after being temporarily disabled by system management. or after being temporarily disabled by system management.
- The interface attaches to a link for the first time. - The interface attaches to a link for the first time.
- The interface becomes enabled by system management after having - The interface becomes enabled by system management after having
been administratively disabled. been administratively disabled.
A link-local address is formed by prepending the well-known link- A link-local address is formed by combining the well-known link-local
local prefix FE80::0 [RFC3513] (of appropriate length not less than prefix FE80::0 [RFC3513] (of appropriate length) with the interface
10 bits) to the interface identifier. If the interface identifier identifier as follows:
has a length of N bits, the interface identifier replaces the
right-most N zero bits of the link-local prefix. If the interface 1. The left-most 'prefix length' bits of the address are those of
identifier is more than 118 bits in length, autoconfiguration fails the link-local prefix.
and manual configuration is required. The length of the interface
identifier is defined in a separate link-type specific document, 2. The bits in the address to the right of the link-local prefix are
which should also be consistent with the address architecture set to all zeroes.
[RFC3513] (see Section 2). These documents will carefully define the
length so that link-local addresses can be autoconfigured on the 3. If the length of the interface identifier is N bits, the
link. right-most N bits of the address are replaced by the interface
identifier.
If the sum of the link-local prefix length and N is larger than 128,
autoconfiguration fails and manual configuration is required. The
length of the interface identifier is defined in a separate link-type
specific document, which should also be consistent with the address
architecture [RFC3513] (see Section 2). These documents will
carefully define the length so that link-local addresses can be
autoconfigured on the link.
A link-local address has an infinite preferred and valid lifetime; it A link-local address has an infinite preferred and valid lifetime; it
is never timed out. is never timed out.
5.4 Duplicate Address Detection 5.4 Duplicate Address Detection
Duplicate Address Detection is performed on unicast addresses prior Duplicate Address Detection MUST be performed on all unicast
to assigning them to an interface whose DupAddrDetectTransmits addresses prior to assigning them to an interface, regardless of
variable is greater than zero. Duplicate Address Detection MUST take whether they are obtained through stateful, stateless or manual
place on all unicast addresses, regardless of whether they are configuration, with the following exceptions:
obtained through stateful, stateless or manual configuration, with
the exception of the following cases:
- Duplicate Address Detection MUST NOT be performed on anycast - An interface whose DupAddrDetectTransmits variable is set to zero
addresses. does not perform Duplicate Address Detection,
- Duplicate Address Detection MUST NOT be performed on anycast
addresses (note that anycast addresses cannot syntactically be
distinguished from unicast addresses), and
- Each individual unicast address SHOULD be tested for uniqueness. - Each individual unicast address SHOULD be tested for uniqueness.
Note that there are implementations deployed that only perform Note that there are implementations deployed that only perform
Duplicate Address Detection for the link-local address and skip Duplicate Address Detection for the link-local address and skip
the test for the global address using the same interface the test for the global address using the same interface
identifier as that of the link-local address. Whereas this identifier as that of the link-local address. Whereas this
document does not invalidate such implementations, this kind of document does not invalidate such implementations, this kind of
"optimization" is NOT RECOMMENDED, and new implementations MUST "optimization" is NOT RECOMMENDED, and new implementations MUST
NOT do that optimization. This optimization came from the NOT do that optimization. This optimization came from the
assumption that all of an interface's addresses are generated from assumption that all of an interface's addresses are generated from
the same identifier. However, the assumption does actually not the same identifier. However, the assumption does actually not
skipping to change at page 14, line 43 skipping to change at page 15, line 20
verify an address's uniqueness. An address is considered unique if verify an address's uniqueness. An address is considered unique if
none of the tests indicate the presence of a duplicate address within none of the tests indicate the presence of a duplicate address within
RetransTimer milliseconds after having sent DupAddrDetectTransmits RetransTimer milliseconds after having sent DupAddrDetectTransmits
Neighbor Solicitations. Once an address is determined to be unique, Neighbor Solicitations. Once an address is determined to be unique,
it may be assigned to an interface. it may be assigned to an interface.
5.4.1 Message Validation 5.4.1 Message Validation
A node MUST silently discard any Neighbor Solicitation or A node MUST silently discard any Neighbor Solicitation or
Advertisement message that does not pass the validity checks Advertisement message that does not pass the validity checks
specified in [RFC2461]. A Neighbor Solicitation or Advertisement specified in [I-D.ietf-ipv6-2461bis]. A Neighbor Solicitation or
message that passes these validity checks is called a valid Advertisement message that passes these validity checks is called a
solicitation or valid advertisement, respectively. valid solicitation or valid advertisement, respectively.
5.4.2 Sending Neighbor Solicitation Messages 5.4.2 Sending Neighbor Solicitation Messages
Before sending a Neighbor Solicitation, an interface MUST join the Before sending a Neighbor Solicitation, an interface MUST join the
all-nodes multicast address and the solicited-node multicast address all-nodes multicast address and the solicited-node multicast address
of the tentative address. The former ensures that the node receives of the tentative address. The former ensures that the node receives
Neighbor Advertisements from other nodes already using the address; Neighbor Advertisements from other nodes already using the address;
the latter ensures that two nodes attempting to use the same address the latter ensures that two nodes attempting to use the same address
simultaneously detect each other's presence. simultaneously should detect each other's presence.
To check an address, a node sends DupAddrDetectTransmits Neighbor To check an address, a node sends DupAddrDetectTransmits Neighbor
Solicitations, each separated by RetransTimer milliseconds. The Solicitations, each separated by RetransTimer milliseconds. The
solicitation's Target Address is set to the address being checked, solicitation's Target Address is set to the address being checked,
the IP source is set to the unspecified address and the IP the IP source is set to the unspecified address and the IP
destination is set to the solicited-node multicast address of the destination is set to the solicited-node multicast address of the
target address. target address.
If the Neighbor Solicitation is going to be the first message to be If the Neighbor Solicitation is going to be the first message to be
sent from an interface after interface (re)initialization, the node sent from an interface after interface (re)initialization, the node
SHOULD delay joining the solicited-node multicast address by a random SHOULD delay joining the solicited-node multicast address by a random
delay between 0 and MAX_RTR_SOLICITATION_DELAY as specified in delay between 0 and MAX_RTR_SOLICITATION_DELAY as specified in
[RFC2461]. This serves to alleviate congestion when many nodes start [I-D.ietf-ipv6-2461bis]. This serves to alleviate congestion when
up on the link at the same time, such as after a power failure, and many nodes start up on the link at the same time, such as after a
may help to avoid race conditions when more than one node is trying power failure, and may help to avoid race conditions when more than
to solicit for the same address at the same time. one node is trying to solicit for the same address at the same time.
Even if the Neighbor Solicitation is not going to be the first Even if the Neighbor Solicitation is not going to be the first
message to be sent, the node SHOULD delay joining the solicited-node message to be sent, the node SHOULD delay joining the solicited-node
multicast address by a random delay between 0 and multicast address by a random delay between 0 and
MAX_RTR_SOLICITATION_DELAY if the address being checked is configured MAX_RTR_SOLICITATION_DELAY if the address being checked is configured
by a router advertisement message sent to a multicast address. The by a router advertisement message sent to a multicast address. The
delay will avoid similar congestion when multiple nodes are going to delay will avoid similar congestion when multiple nodes are going to
configure addresses by receiving a same single multicast router configure addresses by receiving the same single multicast router
advertisement. advertisement.
Note that the delay for joining the multicast address implicitly Note that when a node joins a multicast address, it typically sends a
means delaying transmission of the corresponding Multicast Listener Multicast Listener Discovery (MLD) report message [RFC2710][RFC3810]
Discovery (MLD) report message [RFC2710]. Since [RFC2710] does not for the multicast address. In the case of Duplicate Address
request a random delay to avoid race conditions, just delaying Detection, the MLD report message is required in order to inform
MLD-snooping switches, rather than routers, to forward multicast
packets. In the above description, the delay for joining the
multicast address thus means delaying transmission of the
corresponding MLD report message. Since the MLD specifications do
not request a random delay to avoid race conditions, just delaying
Neighbor Solicitation would cause congestion by the MLD report Neighbor Solicitation would cause congestion by the MLD report
messages. The congestion would then prevent MLD-snooping switches messages. The congestion would then prevent the MLD-snooping
from working correctly, and, as a result, prevent Duplicate Address switches from working correctly, and, as a result, prevent Duplicate
Detection from working. The requirement to include the delay for the Address Detection from working. The requirement to include the delay
MLD report in this case avoids this scenario. [RFC3590] also talks for the MLD report in this case avoids this scenario. [RFC3590] also
about some interaction issues between Duplicate Address Detection and talks about some interaction issues between Duplicate Address
MLD. Detection and MLD, and specifies which source address should be used
for the MLD report in this case.
In order to improve the robustness of the Duplicate Address Detection In order to improve the robustness of the Duplicate Address Detection
algorithm, an interface MUST receive and process datagrams sent to algorithm, an interface MUST receive and process datagrams sent to
the all-nodes multicast address or solicited-node multicast address the all-nodes multicast address or solicited-node multicast address
of the tentative address while the delaying period. This does not of the tentative address during the delay period. This does not
necessarily conflict with the requirement that joining the multicast necessarily conflict with the requirement that joining the multicast
group be delayed. In fact, in some cases it is possible for a node group be delayed. In fact, in some cases it is possible for a node
to start listening to the group during the delay period before MLD to start listening to the group during the delay period before MLD
report transmission. It should be noted, however, that in some report transmission. It should be noted, however, that in some
link-layer environments, particularly with MLD-snooping switches, no link-layer environments, particularly with MLD-snooping switches, no
multicast reception will be available until the MLD report is sent. multicast reception will be available until the MLD report is sent.
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 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 not. If the target address is not tentative (i.e., it is assigned to
the receiving interface), the solicitation is processed as described the receiving interface), the solicitation is processed as described
in [RFC2461]. If the target address is tentative, and the source in [I-D.ietf-ipv6-2461bis]. If the target address is tentative, and
address is a unicast address, the solicitation's sender is performing the source address is a unicast address, the solicitation's sender is
address resolution on the target; the solicitation should be silently performing address resolution on the target; the solicitation should
ignored. Otherwise, processing takes place as described below. In be silently ignored. Otherwise, processing takes place as described
all cases, a node MUST NOT respond to a Neighbor Solicitation for a below. In all cases, a node MUST NOT respond to a Neighbor
tentative address. Solicitation for a tentative 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
address is a duplicate and should not be used (by either node). If address is a duplicate and should not be used (by either node). If
the solicitation is from the node itself (because the node loops back the solicitation is from the node itself (because the node loops back
multicast packets), the solicitation does not indicate the presence multicast packets), the solicitation does not indicate the presence
of a duplicate address. of a duplicate address.
Implementor's Note: many interfaces provide a way for upper layers to Implementor's Note: many interfaces provide a way for upper layers to
skipping to change at page 17, line 12 skipping to change at page 17, line 44
condition occurs when two nodes run Duplicate Address Detection condition occurs when two nodes run Duplicate Address Detection
simultaneously and transmit solicitations at roughly the same simultaneously and transmit solicitations at roughly the same
time. 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 matches a unicast or anycast address assigned to the interface. If
the target address is assigned to the receiving interface, the the target address is assigned to the receiving interface, the
solicitation is processed as described in [RFC2461]. If the target solicitation is processed as described in [I-D.ietf-ipv6-2461bis].
address is tentative, the tentative address is not unique. If the target address is 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. system management error.
If the address is a link-local address formed from an interface If the address is a link-local address formed from an interface
identifier based on the hardware address which is supposed to be identifier based on the hardware address which is supposed to be
uniquely assigned (e.g., EUI-64 for an Ethernet interface), IP uniquely assigned (e.g., EUI-64 for an Ethernet interface), IP
skipping to change at page 18, line 18 skipping to change at page 18, line 47
prefix of appropriate length. Prefixes are obtained from Prefix prefix of appropriate length. Prefixes are obtained from Prefix
Information options contained in Router Advertisements. Creation of Information options contained in Router Advertisements. Creation of
global addresses and configuration of other parameters as described global addresses and configuration of other parameters as described
in this section SHOULD be locally configurable. However, the in this section SHOULD be locally configurable. However, the
processing described below MUST be enabled by default. 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 Router Advertisements are sent periodically to the all-nodes
multicast address. To obtain an advertisement quickly, a host sends multicast address. To obtain an advertisement quickly, a host sends
out Router Solicitations as described in [RFC2461]. out Router Solicitations as described in [I-D.ietf-ipv6-2461bis].
5.5.2 Absence of Router Advertisements 5.5.2 Absence of Router Advertisements
Even if a link has no routers, stateful autoconfiguration to obtain Even if a link has no routers, stateful autoconfiguration to obtain
addresses and other configuration information may still be available, addresses and other configuration information may still be available,
and hosts may want to use the mechanism. From the perspective of and hosts may want to use the mechanism. From the perspective of
autoconfiguration, a link has no routers if no Router Advertisements autoconfiguration, a link has no routers if no Router Advertisements
are received after having sent a small number of Router Solicitations are received after having sent a small number of Router Solicitations
as described in [RFC2461]. as described in [I-D.ietf-ipv6-2461bis].
Note that it is possible that there is no router on the link in this Note that it is possible that there is no router on the link in this
sense but there is a node that has the ability to forward packets. sense but there is a node that has the ability to forward packets.
In this case, the forwarding node's address must be manually In this case, the forwarding node's address must be manually
configured in hosts to be able to send packets off-link, since the configured in hosts to be able to send packets off-link, since the
only mechanism to configure the default router's address only mechanism to configure the default router's address
automatically is the one using Router Advertisements. automatically is the one using Router Advertisements.
5.5.3 Router Advertisement Processing 5.5.3 Router Advertisement Processing
skipping to change at page 19, line 32 skipping to change at page 20, line 9
defined in a separate link-type specific document, which should defined in a separate link-type specific document, which should
also be consistent with the address architecture [RFC3513] (see also be consistent with the address architecture [RFC3513] (see
Section 2). Section 2).
It is the responsibility of the system administrator to insure It is the responsibility of the system administrator to insure
that the lengths of prefixes contained in Router Advertisements that the lengths of prefixes contained in Router Advertisements
are consistent with the length of interface identifiers for that are consistent with the length of interface identifiers for that
link type. It should be noted, however, that this does not mean link type. It should be noted, however, that this does not mean
the advertised prefix length is meaningless. In fact, the the advertised prefix length is meaningless. In fact, the
advertised length has non trivial meaning for on-link advertised length has non trivial meaning for on-link
determination in [RFC2461] where the sum of the prefix length and determination in [I-D.ietf-ipv6-2461bis] where the sum of the
the interface identifier length may not be equal to 128. Thus, it prefix length and the interface identifier length may not be equal
should be safe to validate the advertised prefix length here, in to 128. Thus, it should be safe to validate the advertised prefix
order to detect and avoid a configuration error specifying an length here, in order to detect and avoid a configuration error
invalid prefix length in the context of address autoconfiguration. specifying an invalid prefix length in the context of address
autoconfiguration.
Note that a future revision of the address architecture [RFC3513] Note that a future revision of the address architecture [RFC3513]
and a future link-type specific document, which will still be and a future link-type specific document, which will still be
consistent with each other, could potentially allow for an consistent with each other, could potentially allow for an
interface identifier of length other than the value defined in the interface identifier of length other than the value defined in the
current documents. Thus, an implementation should not assume a current documents. Thus, an implementation should not assume a
particular constant. Rather, it should expect any lengths of particular constant. Rather, it should expect any lengths of
interface identifiers. interface identifiers.
If an address is formed successfully, the host adds it to the list If an address is formed successfully, the host adds it to the list
skipping to change at page 23, line 23 skipping to change at page 23, line 45
particular, thanks to Jim Bound, Steve Deering, Richard Draves, and particular, thanks to Jim Bound, Steve Deering, Richard Draves, and
Erik Nordmark. Thanks also goes to John Gilmore for alerting the WG Erik Nordmark. Thanks also goes to John Gilmore for alerting the WG
of the "0 Lifetime Prefix Advertisement" denial of service attack of the "0 Lifetime Prefix Advertisement" denial of service attack
vulnerability; this document incorporates changes that address this vulnerability; this document incorporates changes that address this
vulnerability. vulnerability.
A number of people have contributed to identifying issues on a A number of people have contributed to identifying issues on a
previous version of this document and to proposing resolutions to the previous version of this document and to proposing resolutions to the
issues, on which this version is based. In addition to those listed issues, on which this version is based. In addition to those listed
above, the contributors include Jari Arkko, Brian E Carpenter, above, the contributors include Jari Arkko, Brian E Carpenter,
Gregory Daley, Ralph Droms, Jun-ichiro itojun Hagino, Christian Gregory Daley, Elwyn Davies, Ralph Droms, Jun-ichiro itojun Hagino,
Huitema, Suresh Krishnan, Soohong Daniel Park, Markku Savela, and Christian Huitema, Suresh Krishnan, Soohong Daniel Park, Markku
Pekka Savola. Savela, and Pekka Savola.
9. References 9. References
9.1 Normative References 9.1 Normative References
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
2402, November 1998. 2402, November 1998.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998. Networks", RFC 2464, December 1998.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003. (IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor [I-D.ietf-ipv6-2461bis]
Discovery for IP Version 6 (IPv6)", RFC 2461, December Narten, T., Nordmark, E., Simpson, W. and H. Soliman,
1998. "Neighbor Discovery for IP version 6 (IPv6)",
draft-ietf-ipv6-2461bis-00 (work in progress), July 2004.
Note: this reference is expected to be published in
parallel with the referring document, both of which will
be recycled as a draft standard. Upon publication the
reference will be updated and this note will be removed.
9.2 Informative References 9.2 Informative References
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and
M. Carney, "Dynamic Host Configuration Protocol for IPv6 M. Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003. (DHCPv6)", RFC 3315, July 2003.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004. (DHCP) Service for IPv6", RFC 3736, April 2004.
skipping to change at page 24, line 23 skipping to change at page 25, line 5
January 2001. January 2001.
[I-D.ietf-send-cga] [I-D.ietf-send-cga]
Aura, T., "Cryptographically Generated Addresses (CGA)", Aura, T., "Cryptographically Generated Addresses (CGA)",
draft-ietf-send-cga-06 (work in progress), April 2004. draft-ietf-send-cga-06 (work in progress), April 2004.
[RFC2710] Deering, S., Fenner, W. and B. Haberman, "Multicast [RFC2710] Deering, S., Fenner, W. and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710, October Listener Discovery (MLD) for IPv6", RFC 2710, October
1999. 1999.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3590] Haberman, B., "Source Address Selection for the Multicast [RFC3590] Haberman, B., "Source Address Selection for the Multicast
Listener Discovery (MLD) Protocol", RFC 3590, September Listener Discovery (MLD) Protocol", RFC 3590, September
2003. 2003.
[RFC3756] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor [RFC3756] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756, May Discovery (ND) Trust Models and Threats", RFC 3756, May
2004. 2004.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, August 1989. RFC 1112, August 1989.
skipping to change at page 31, line 4 skipping to change at page 30, line 42
o Changed the reference on the algorithm of computing solicited-node o Changed the reference on the algorithm of computing solicited-node
multicast addresses to [RFC3513]. multicast addresses to [RFC3513].
o Made the intent clearer in the clarification that unicasted NS or o Made the intent clearer in the clarification that unicasted NS or
NA should be discarded during Duplicate Address Detection. NA should be discarded during Duplicate Address Detection.
Changes since draft-ietf-ipv6-rfc2462bis-03.txt are: Changes since draft-ietf-ipv6-rfc2462bis-03.txt are:
o Added an informative reference to [RFC3590]. o Added an informative reference to [RFC3590].
o Summarized major changes since RFC 2462 to prepare for o Summarized major changes since RFC 2462 to prepare for
publication. publication.
Changes since draft-ietf-ipv6-rfc2462bis-05.txt are:
o Clarified the role of RFC 3736 in the abstract.
o Clarified that the default configuration method is the one
described in this document.
o Changed the reference for the Neighbor Discovery protocol to
[I-D.ietf-ipv6-2461bis].
o Reorganized the conditions at the beginning of Section 5.4 with an
additional note to avoid confusion.
o Clarified the role of the link-local prefix in Section 5.3.
o Added a reference to RFC 3810 as well as to RFC 2710.
o Clarified the MLD issues a bit more.
o Replaced "multicast interface" with "multicast-capable interface".
o Clarified that the autoconfiguration protocol would basically be
used on all types of links in line with the Neighbor Discovery
protocol.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/