From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4862.txt | 1683 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1683 insertions(+) create mode 100644 doc/rfc/rfc4862.txt (limited to 'doc/rfc/rfc4862.txt') diff --git a/doc/rfc/rfc4862.txt b/doc/rfc/rfc4862.txt new file mode 100644 index 0000000..20ce966 --- /dev/null +++ b/doc/rfc/rfc4862.txt @@ -0,0 +1,1683 @@ + + + + + + +Network Working Group S. Thomson +Request for Comments: 4862 Cisco +Obsoletes: 2462 T. Narten +Category: Standards Track IBM + T. Jinmei + Toshiba + September 2007 + + + IPv6 Stateless Address Autoconfiguration + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + This document specifies the steps a host takes in deciding how to + autoconfigure its interfaces in IP version 6. The autoconfiguration + process includes generating a link-local address, generating global + addresses via stateless address autoconfiguration, and the Duplicate + Address Detection procedure to verify the uniqueness of the addresses + on a link. + + + + + + + + + + + + + + + + + + + + + + + + +Thomson, et al. Standards Track [Page 1] + +RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7 + 3. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 + 4.1. Site Renumbering . . . . . . . . . . . . . . . . . . . . . 9 + 5. Protocol Specification . . . . . . . . . . . . . . . . . . . . 10 + 5.1. Node Configuration Variables . . . . . . . . . . . . . . . 10 + 5.2. Autoconfiguration-Related Structures . . . . . . . . . . . 11 + 5.3. Creation of Link-Local Addresses . . . . . . . . . . . . . 11 + 5.4. Duplicate Address Detection . . . . . . . . . . . . . . . 12 + 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 . . . . . . . . 17 + 5.5. Creation of Global Addresses . . . . . . . . . . . . . . . 17 + 5.5.1. Soliciting Router Advertisements . . . . . . . . . . . 18 + 5.5.2. Absence of Router Advertisements . . . . . . . . . . . 18 + 5.5.3. Router Advertisement Processing . . . . . . . . . . . 18 + 5.5.4. Address Lifetime Expiry . . . . . . . . . . . . . . . 20 + 5.6. Configuration Consistency . . . . . . . . . . . . . . . . 21 + 5.7. Retaining Configured Addresses for Stability . . . . . . . 22 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 + 8.1. Normative References . . . . . . . . . . . . . . . . . . . 23 + 8.2. Informative References . . . . . . . . . . . . . . . . . . 23 + Appendix A. Loopback Suppression and Duplicate Address + Detection . . . . . . . . . . . . . . . . . . . . . . 25 + Appendix B. Changes since RFC 1971 . . . . . . . . . . . . . . . 26 + Appendix C. Changes since RFC 2462 . . . . . . . . . . . . . . . 27 + + + + + + + + + + + + + + + + + +Thomson, et al. Standards Track [Page 2] + +RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007 + + +1. Introduction + + This document specifies the steps a host takes in deciding how to + autoconfigure its interfaces in IP version 6 (IPv6). The + autoconfiguration process includes generating a link-local address, + generating global addresses via stateless address autoconfiguration, + and the Duplicate Address Detection procedure to verify the + uniqueness of the addresses on a link. + + The IPv6 stateless autoconfiguration mechanism requires no manual + configuration of hosts, minimal (if any) configuration of routers, + and no additional servers. The stateless mechanism allows a host to + generate its own addresses using a combination of locally available + information and information advertised by routers. Routers advertise + prefixes that identify the subnet(s) associated with a link, while + hosts generate an "interface identifier" that uniquely identifies an + interface on a subnet. An address is formed by combining the two. + In the absence of routers, a host can only generate link-local + addresses. However, link-local addresses are sufficient for allowing + communication among nodes attached to the same link. + + The stateless approach is used when a site is not particularly + concerned with the exact addresses hosts use, so long as they are + unique and properly routable. On the other hand, Dynamic Host + Configuration Protocol for IPv6 (DHCPv6) [RFC3315] is used when a + site requires tighter control over exact address assignments. Both + stateless address autoconfiguration and DHCPv6 may be used + simultaneously. + + IPv6 addresses are leased to an interface for a fixed (possibly + infinite) length of time. Each address has an associated lifetime + that indicates how long the address is bound to an interface. When a + lifetime expires, the binding (and address) become invalid and the + address may be reassigned to another interface elsewhere in the + Internet. To handle the expiration of address bindings gracefully, + an address goes through two distinct phases while assigned to an + interface. Initially, an address is "preferred", meaning that its + use in arbitrary communication is unrestricted. Later, an address + becomes "deprecated" in anticipation that its current interface + binding will become invalid. While an address is in a deprecated + state, its use is discouraged, but not strictly forbidden. New + communication (e.g., the opening of a new TCP connection) should use + a preferred address when possible. A deprecated address should be + used only by applications that have been using it and would have + difficulty switching to another address without a service disruption. + + + + + + +Thomson, et al. Standards Track [Page 3] + +RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007 + + + To ensure that all configured addresses are likely to be unique on a + given link, nodes run a "duplicate address detection" algorithm on + addresses before assigning them to an interface. The Duplicate + Address Detection algorithm is performed on all addresses, + independently of whether they are obtained via stateless + autoconfiguration or DHCPv6. This document defines the Duplicate + Address Detection algorithm. + + The autoconfiguration process specified in this document applies only + to hosts and not routers. Since host autoconfiguration uses + information advertised by routers, routers will need to be configured + by some other means. However, it is expected that routers will + generate link-local addresses using the mechanism described in this + document. In addition, routers are expected to successfully pass the + Duplicate Address Detection procedure described in this document on + all addresses prior to assigning them to an interface. + + Section 2 provides definitions for terminology used throughout this + document. Section 3 describes the design goals that lead to the + current autoconfiguration procedure. Section 4 provides an overview + of the protocol, while Section 5 describes the protocol in detail. + +2. Terminology + + IP - Internet Protocol Version 6. The terms IPv4 and IPv6 are used + only in contexts where necessary to avoid ambiguity. + + node - a device that implements IP. + + router - a node that forwards IP packets not explicitly addressed to + itself. + + host - any node that is not a router. + + upper layer - a protocol layer immediately above IP. Examples are + transport protocols such as TCP and UDP, control protocols such as + ICMP, routing protocols such as OSPF, and Internet or lower-layer + protocols being "tunneled" over (i.e., encapsulated in) IP such as + IPX, AppleTalk, or IP itself. + + link - a communication facility or medium over which nodes can + communicate at the link layer, i.e., the layer immediately below + 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. 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 [RFC4861]. + + + +Thomson, et al. Standards Track [Page 4] + +RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007 + + + 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 of + interfaces. + + unicast address - an identifier for a single interface. A packet + sent to a unicast address is delivered to the interface identified + by that address. + + multicast address - an identifier for a set of interfaces (typically + belonging to different nodes). A packet sent to a multicast + address is delivered to all interfaces identified by that address. + + anycast address - an identifier for a set of interfaces (typically + belonging to different nodes). A packet sent to an anycast + address is delivered to one of the interfaces identified by that + address (the "nearest" one, according to the routing protocol's + measure of distance). See [RFC4291]. + + solicited-node multicast address - a multicast address to which + Neighbor Solicitation messages are sent. The algorithm for + computing the address is given in [RFC4291]. + + link-layer address - a link-layer identifier for an interface. + Examples include IEEE 802 addresses for Ethernet links and E.164 + addresses for Integrated Services Digital Network (ISDN) links. + + link-local address - an address having link-only scope that can be + used to reach neighboring nodes attached to the same link. All + interfaces have a link-local unicast address. + + global address - an address with unlimited scope. + + communication - any packet exchange among nodes that requires that + the address of each node used in the exchange remain the same for + the duration of the packet exchange. Examples are a TCP + connection or a UDP request-response. + + tentative address - an address whose uniqueness on a link is being + verified, prior to its assignment to an interface. A tentative + address is not considered assigned to an interface in the usual + sense. An interface discards received packets addressed to a + tentative address, but accepts Neighbor Discovery packets related + to Duplicate Address Detection for the tentative address. + + + + + +Thomson, et al. Standards Track [Page 5] + +RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007 + + + preferred address - an address assigned to an interface whose use by + upper-layer protocols is unrestricted. Preferred addresses may be + used as the source (or destination) address of packets sent from + (or to) the interface. + + deprecated address - An address assigned to an interface whose use + is discouraged, but not forbidden. A deprecated address should no + longer be used as a source address in new communications, but + packets sent from or to deprecated addresses are delivered as + expected. A deprecated address may continue to be used as a + source address in communications where switching to a preferred + address causes hardship to a specific upper-layer activity (e.g., + an existing TCP connection). + + valid address - a preferred or deprecated address. A valid address + may appear as the source or destination address of a packet, and + the Internet routing system is expected to deliver packets sent to + a valid address to their intended recipients. + + invalid address - an address that is not assigned to any interface. + A valid address becomes invalid when its valid lifetime expires. + Invalid addresses should not appear as the destination or source + address of a packet. In the former case, the Internet routing + system will be unable to deliver the packet; in the latter case, + the recipient of the packet will be unable to respond to it. + + preferred lifetime - the length of time that a valid address is + preferred (i.e., the time until deprecation). When the preferred + lifetime expires, the address becomes deprecated. + + valid lifetime - the length of time an address remains in the valid + state (i.e., the time until invalidation). The valid lifetime + must be greater than or equal to the preferred lifetime. When the + valid lifetime expires, the address becomes invalid. + + interface identifier - a link-dependent identifier for an interface + that is (at least) unique per link [RFC4291]. Stateless address + autoconfiguration combines an interface identifier with a prefix + to form an address. From address autoconfiguration's perspective, + an interface identifier is a bit string of known length. The + exact length of an interface identifier and the way it is created + is defined in a separate link-type specific document that covers + issues related to the transmission of IP over a particular link + type (e.g., [RFC2464]). Note that the address architecture + [RFC4291] also defines the length of the interface identifiers for + some set of addresses, but the two sets of definitions must be + consistent. In many cases, the identifier will be derived from + the interface's link-layer address. + + + +Thomson, et al. Standards Track [Page 6] + +RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007 + + +2.1. Requirements + + The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, + SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this + document, are to be interpreted as described in [RFC2119]. + + Note that this document intentionally limits the use of the keywords + to the protocol specification (Section 5). + +3. Design Goals + + Stateless autoconfiguration is designed with the following goals in + mind: + + o Manual configuration of individual machines before connecting them + to the network should not be required. Consequently, a mechanism + is needed that allows a host to obtain or create unique addresses + for each of its interfaces. Address autoconfiguration assumes + that each interface can provide a unique identifier for that + interface (i.e., an "interface identifier"). In the simplest + case, an interface identifier consists of the interface's link- + layer address. An interface identifier can be combined with a + prefix to form an address. + + o Small sites consisting of a set of machines attached to a single + link should not require the presence of a DHCPv6 server or router + as a prerequisite for communicating. Plug-and-play communication + is achieved through the use of link-local addresses. Link-local + addresses have a well-known prefix that identifies the (single) + shared link to which a set of nodes attach. A host forms a link- + local address by appending an interface identifier to the link- + local prefix. + + o A large site with multiple networks and routers should not require + the presence of a DHCPv6 server for address configuration. In + order to generate global addresses, hosts must determine the + prefixes that identify the subnets to which they attach. Routers + generate periodic Router Advertisements that include options + listing the set of active prefixes on a link. + + o Address configuration should facilitate the graceful renumbering + of a site's machines. For example, a site may wish to renumber + all of its nodes when it switches to a new network service + provider. Renumbering is achieved through the leasing of + addresses to interfaces and the assignment of multiple addresses + to the same interface. Lease lifetimes provide the mechanism + through which a site phases out old prefixes. The assignment of + multiple addresses to an interface provides for a transition + + + +Thomson, et al. Standards Track [Page 7] + +RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007 + + + period during which both a new address and the one being phased + out work simultaneously. + +4. Protocol Overview + + This section provides an overview of the typical steps that take + place when an interface autoconfigures itself. Autoconfiguration is + performed only on multicast-capable links and begins when a + multicast-capable interface is enabled, e.g., during system startup. + Nodes (both hosts and routers) begin the autoconfiguration process by + generating a link-local address for the interface. A link-local + address is formed by appending an identifier of the interface to the + well-known link-local prefix [RFC4291]. + + Before the link-local address can be assigned to an interface and + 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 the + tentative address as the target. If another node is already using + that address, it will return a Neighbor Advertisement saying so. If + another node is also attempting to use the same address, it will send + a Neighbor Solicitation for the target as well. The exact number of + times the Neighbor Solicitation is (re)transmitted and the delay time + between consecutive solicitations is link-specific and may be set by + system management. + + If a node determines that its tentative link-local address is not + unique, autoconfiguration stops and manual configuration of the + interface is required. To simplify recovery in this case, it should + be possible for an administrator to supply an alternate interface + identifier that overrides the default identifier in such a way that + the autoconfiguration mechanism can then be applied using the new + (presumably unique) interface identifier. Alternatively, link-local + and other addresses will need to be configured manually. + + Once a node ascertains that its tentative link-local address is + unique, it assigns the address to the interface. At this point, the + node has IP-level connectivity with neighboring nodes. The remaining + autoconfiguration steps are performed only by hosts; the + (auto)configuration of routers is beyond the scope of this document. + + The next phase of autoconfiguration involves obtaining a Router + Advertisement or determining that no routers are present. If routers + are present, they will send Router Advertisements that specify what + sort of autoconfiguration a host can do. Note that the DHCPv6 + service for address configuration may still be available even if no + routers are present. + + + + +Thomson, et al. Standards Track [Page 8] + +RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007 + + + Routers send Router Advertisements periodically, but the delay + between successive advertisements will generally be longer than a + host performing autoconfiguration will want to wait [RFC4861]. To + obtain an advertisement quickly, a host sends one or more Router + Solicitations to the all-routers multicast group. + + Router Advertisements also contain zero or more Prefix Information + options that contain information used by stateless address + autoconfiguration to generate global addresses. It should be noted + that a host may use both stateless address autoconfiguration and + DHCPv6 simultaneously. One Prefix Information option field, the + "autonomous address-configuration flag", indicates whether or not the + option even applies to stateless autoconfiguration. If it does, + additional option fields contain a subnet prefix, together with + lifetime values, indicating how long addresses created from the + prefix remain preferred and valid. + + Because routers generate Router Advertisements periodically, hosts + will continually receive new advertisements. Hosts process the + information contained in each advertisement as described above, + adding to and refreshing information received in previous + advertisements. + + By default, all addresses should be tested for uniqueness prior to + their assignment to an interface for safety. The test should + individually be performed on all addresses obtained manually, via + stateless address autoconfiguration, or via DHCPv6. To accommodate + sites that believe the overhead of performing Duplicate Address + Detection outweighs its benefits, the use of Duplicate Address + Detection can be disabled through the administrative setting of a + per-interface configuration flag. + + To speed the autoconfiguration process, a host may generate its link- + local address (and verify its uniqueness) in parallel with waiting + for a Router Advertisement. Because a router may delay responding to + a Router Solicitation for a few seconds, the total time needed to + complete autoconfiguration can be significantly longer if the two + steps are done serially. + +4.1. Site Renumbering + + Address leasing facilitates site renumbering by providing a mechanism + to time-out addresses assigned to interfaces in hosts. At present, + upper-layer protocols such as TCP provide no support for changing + end-point addresses while a connection is open. If an end-point + address becomes invalid, existing connections break and all + + + + + +Thomson, et al. Standards Track [Page 9] + +RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007 + + + communication to the invalid address fails. Even when applications + use UDP as a transport protocol, addresses must generally remain the + same during a packet exchange. + + Dividing valid addresses into preferred and deprecated categories + provides a way of indicating to upper layers that a valid address may + become invalid shortly and that future communication using the + address will fail, should the address's valid lifetime expire before + communication ends. To avoid this scenario, higher layers should use + a preferred address (assuming one of sufficient scope exists) to + increase the likelihood that an address will remain valid for the + duration of the communication. It is up to system administrators to + set appropriate prefix lifetimes in order to minimize the impact of + failed communication when renumbering takes place. The deprecation + period should be long enough that most, if not all, communications + are using the new address at the time an address becomes invalid. + + The IP layer is expected to provide a means for upper layers + (including applications) to select the most appropriate source + address given a particular destination and possibly other + constraints. An application may choose to select the source address + itself before starting a new communication or may leave the address + unspecified, in which case, the upper networking layers will use the + mechanism provided by the IP layer to choose a suitable address on + the application's behalf. + + Detailed address selection rules are beyond the scope of this + document and are described in [RFC3484]. + +5. Protocol Specification + + Autoconfiguration is performed on a per-interface basis on 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 the procedure outlined below. In + addition, routers perform Duplicate Address Detection on all + addresses prior to assigning them to an interface. + +5.1. Node Configuration Variables + + A node MUST allow the following autoconfiguration-related variable to + be configured by system management for each multicast-capable + interface: + + + + + + + +Thomson, et al. Standards Track [Page 10] + +RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007 + + + DupAddrDetectTransmits The number of consecutive Neighbor + Solicitation messages sent while performing Duplicate Address + Detection on a tentative address. A value of zero indicates that + Duplicate Address Detection is not performed on tentative + addresses. A value of one indicates a single transmission with no + follow-up retransmissions. + + Default: 1, but may be overridden by a link-type specific value in + the document that covers issues related to the transmission of IP + over a particular link type (e.g., [RFC2464]). + + Autoconfiguration also assumes the presence of the variable + RetransTimer as defined in [RFC4861]. For autoconfiguration + purposes, RetransTimer specifies the delay between consecutive + Neighbor Solicitation transmissions performed during Duplicate + Address Detection (if DupAddrDetectTransmits is greater than 1), + as well as the time a node waits after sending the last Neighbor + Solicitation before ending the Duplicate Address Detection + process. + +5.2. Autoconfiguration-Related Structures + + Beyond the formation of a link-local address and use of Duplicate + Address Detection, how routers (auto)configure their interfaces is + beyond the scope of this document. + + A host maintains a list of addresses together with their + corresponding lifetimes. The address list contains both + autoconfigured addresses and those configured manually. + +5.3. Creation of Link-Local Addresses + + A node forms a link-local address whenever an interface becomes + enabled. An interface may become enabled after any of the following + events: + + - The interface is initialized at system startup time. + + - The interface is reinitialized after a temporary interface failure + or after being temporarily disabled by system management. + + - The interface attaches to a link for the first time. This + includes the case where the attached link is dynamically changed + due to a change of the access point of wireless networks. + + + + + + + +Thomson, et al. Standards Track [Page 11] + +RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007 + + + - The interface becomes enabled by system management after having + been administratively disabled. + + A link-local address is formed by combining the well-known link-local + prefix FE80::0 [RFC4291] (of appropriate length) with an interface + identifier as follows: + + 1. The left-most 'prefix length' bits of the address are those of + the link-local prefix. + + 2. The bits in the address to the right of the link-local prefix are + set to all zeroes. + + 3. If the length of the interface identifier is N bits, the 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 [RFC4291] (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 + is never timed out. + +5.4. Duplicate Address Detection + + Duplicate Address Detection MUST be performed on all unicast + addresses prior to assigning them to an interface, regardless of + whether they are obtained through stateless autoconfiguration, + DHCPv6, or manual configuration, with the following exceptions: + + - An interface whose DupAddrDetectTransmits variable is set to zero + 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). + + - Each individual unicast address SHOULD be tested for uniqueness. + Note that there are implementations deployed that only perform + Duplicate Address Detection for the link-local address and skip + the test for the global address that uses the same interface + identifier as that of the link-local address. Whereas this + document does not invalidate such implementations, this kind of + + + +Thomson, et al. Standards Track [Page 12] + +RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007 + + + "optimization" is NOT RECOMMENDED, and new implementations MUST + NOT do that optimization. This optimization came from the + assumption that all of an interface's addresses are generated from + the same identifier. However, the assumption does actually not + stand; new types of addresses have been introduced where the + interface identifiers are not necessarily the same for all unicast + addresses on a single interface [RFC4941] [RFC3972]. Requiring + that Duplicate Address Detection be performed for all unicast + addresses will make the algorithm robust for the current and + future special interface identifiers. + + The procedure for detecting duplicate addresses uses Neighbor + Solicitation and Advertisement messages as described below. If a + duplicate address is discovered during the procedure, the address + cannot be assigned to the interface. If the address is derived from + an interface identifier, a new identifier will need to be assigned to + the interface, or all IP addresses for the interface will need to be + manually configured. Note that the method for detecting duplicates + is not completely reliable, and it is possible that duplicate + addresses will still exist (e.g., if the link was partitioned while + Duplicate Address Detection was performed). + + An address on which the Duplicate Address Detection procedure is + applied is said to be tentative until the procedure has completed + successfully. A tentative address is not considered "assigned to an + interface" in the traditional sense. That is, the interface must + accept Neighbor Solicitation and Advertisement messages containing + the tentative address in the Target Address field, but processes such + packets differently from those whose Target Address matches an + address assigned to the interface. Other packets addressed to the + tentative address should be silently discarded. Note that the "other + packets" include Neighbor Solicitation and Advertisement messages + that have the tentative (i.e., unicast) address as the IP destination + address and contain the tentative address in the Target Address + field. Such a case should not happen in normal operation, though, + since these messages are multicasted in the Duplicate Address + Detection procedure. + + It should also be noted that Duplicate Address Detection must be + performed prior to assigning an address to an interface in order to + prevent multiple nodes from using the same address simultaneously. + If a node begins using an address in parallel with Duplicate Address + Detection, and another node is already using the address, the node + performing Duplicate Address Detection will erroneously process + traffic intended for the other node, resulting in such possible + negative consequences as the resetting of open TCP connections. + + + + + +Thomson, et al. Standards Track [Page 13] + +RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007 + + + The following subsections describe specific tests a node performs to + verify an address's uniqueness. An address is considered unique if + none of the tests indicate the presence of a duplicate address within + RetransTimer milliseconds after having sent DupAddrDetectTransmits + Neighbor Solicitations. Once an address is determined to be unique, + it may be assigned to an interface. + +5.4.1. Message Validation + + A node MUST silently discard any Neighbor Solicitation or + Advertisement message that does not pass the validity checks + specified in [RFC4861]. A Neighbor Solicitation or Advertisement + message that passes these validity checks is called a valid + solicitation or valid advertisement, respectively. + +5.4.2. Sending Neighbor Solicitation Messages + + Before sending a Neighbor Solicitation, an interface MUST join the + all-nodes multicast address and the solicited-node multicast address + of the tentative address. The former ensures that the node receives + Neighbor Advertisements from other nodes already using the address; + the latter ensures that two nodes attempting to use the same address + simultaneously should detect each other's presence. + + To check an address, a node sends DupAddrDetectTransmits Neighbor + Solicitations, each separated by RetransTimer milliseconds. The + solicitation's Target Address is set to the address being checked, + the IP source is set to the unspecified address, and the IP + destination is set to the solicited-node multicast address of the + target address. + + If the Neighbor Solicitation is going to be the first message sent + from an interface after interface (re)initialization, the node SHOULD + delay joining the solicited-node multicast address by a random delay + between 0 and MAX_RTR_SOLICITATION_DELAY as specified in [RFC4861]. + This serves to alleviate congestion when many nodes start up on the + link at the same time, such as after a power failure, and may help to + avoid race conditions when more than 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 + message sent, the node SHOULD delay joining the solicited-node + multicast address by a random delay between 0 and + MAX_RTR_SOLICITATION_DELAY if the address being checked is configured + by a router advertisement message sent to a multicast address. The + delay will avoid similar congestion when multiple nodes are going to + configure addresses by receiving the same single multicast router + advertisement. + + + +Thomson, et al. Standards Track [Page 14] + +RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007 + + + Note that when a node joins a multicast address, it typically sends a + Multicast Listener Discovery (MLD) report message [RFC2710] [RFC3810] + for the multicast address. In the case of Duplicate Address + 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 messages. The congestion would + then prevent the MLD-snooping switches from working correctly and, as + a result, prevent Duplicate Address Detection from working. The + requirement to include the delay for the MLD report in this case + avoids this scenario. [RFC3590] also talks about some interaction + issues between Duplicate Address 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 + algorithm, an interface MUST receive and process datagrams sent to + the all-nodes multicast address or solicited-node multicast address + of the tentative address during the delay period. This does not + necessarily conflict with the requirement that joining the multicast + 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 + report transmission. It should be noted, however, that in some link- + layer environments, particularly with MLD-snooping switches, no + multicast reception will be available until the MLD report is sent. + +5.4.3. Receiving Neighbor Solicitation Messages + + On receipt of a valid Neighbor Solicitation message on an interface, + node behavior depends on whether or not the target address is + tentative. If the target address is not tentative (i.e., it is + assigned to the receiving interface), the solicitation is processed + as described in [RFC4861]. If the target address is tentative, and + the source address is a unicast address, the solicitation's sender is + performing address resolution on the target; the solicitation should + be silently ignored. Otherwise, processing takes place as described + below. In all cases, a node MUST NOT respond to a Neighbor + Solicitation for a tentative address. + + If the source address of the Neighbor Solicitation is the unspecified + address, the solicitation is from a node performing Duplicate Address + Detection. If the solicitation is from another node, the tentative + 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 + multicast packets), the solicitation does not indicate the presence + of a duplicate address. + + + +Thomson, et al. Standards Track [Page 15] + +RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007 + + + Implementer's Note: many interfaces provide a way for upper layers to + selectively enable and disable the looping back of multicast packets. + The details of how such a facility is implemented may prevent + Duplicate Address Detection from working correctly. See Appendix A + for further discussion. + + The following tests identify conditions under which a tentative + address is not unique: + + - If a Neighbor Solicitation for a tentative address is received + before one is sent, the tentative address is a duplicate. This + condition occurs when two nodes run Duplicate Address Detection + simultaneously, but transmit initial solicitations at different + times (e.g., by selecting different random delay values before + joining the solicited-node multicast address and transmitting an + initial solicitation). + + - If the actual number of Neighbor Solicitations received exceeds + the number expected based on the loopback semantics (e.g., the + interface does not loop back the packet, yet one or more + solicitations was received), the tentative address is a duplicate. + This condition occurs when two nodes run Duplicate Address + Detection simultaneously and transmit solicitations at roughly the + same time. + +5.4.4. Receiving Neighbor Advertisement Messages + + On receipt of a valid Neighbor Advertisement message on an interface, + node behavior depends on whether the target address is tentative or + matches a unicast or anycast address assigned to the interface: + + 1. If the target address is tentative, the tentative address is not + unique. + + 2. If the target address matches a unicast address assigned to the + receiving interface, it would possibly indicate that the address + is a duplicate but it has not been detected by the Duplicate + Address Detection procedure (recall that Duplicate Address + Detection is not completely reliable). How to handle such a case + is beyond the scope of this document. + + 3. Otherwise, the advertisement is processed as described in + [RFC4861]. + + + + + + + + +Thomson, et al. Standards Track [Page 16] + +RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007 + + +5.4.5. When Duplicate Address Detection Fails + + 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 + system management error. + + If the address is a link-local address formed from an interface + identifier based on the hardware address, which is supposed to be + uniquely assigned (e.g., EUI-64 for an Ethernet interface), IP + operation on the interface SHOULD be disabled. By disabling IP + operation, the node will then: + + - not send any IP packets from the interface, + + - silently drop any IP packets received on the interface, and + + - not forward any IP packets to the interface (when acting as a + router or processing a packet with a Routing header). + + In this case, the IP address duplication probably means duplicate + hardware addresses are in use, and trying to recover from it by + configuring another IP address will not result in a usable network. + In fact, it probably makes things worse by creating problems that are + harder to diagnose than just disabling network operation on the + interface; the user will see a partially working network where some + things work, and other things do not. + + On the other hand, if the duplicate link-local address is not formed + from an interface identifier based on the hardware address, which is + supposed to be uniquely assigned, IP operation on the interface MAY + be continued. + + Note: as specified in Section 2, "IP" means "IPv6" in the above + description. While the background rationale about hardware address + is independent of particular network protocols, its effect on other + protocols is beyond the scope of this document. + +5.5. Creation of Global Addresses + + Global addresses are formed by appending an interface identifier to a + prefix of appropriate length. Prefixes are obtained from Prefix + Information options contained in Router Advertisements. Creation of + global addresses as described in this section SHOULD be locally + configurable. However, the processing described below MUST be + enabled by default. + + + + + + +Thomson, et al. Standards Track [Page 17] + +RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007 + + +5.5.1. Soliciting Router Advertisements + + Router Advertisements are sent periodically to the all-nodes + multicast address. To obtain an advertisement quickly, a host sends + out Router Solicitations as described in [RFC4861]. + +5.5.2. Absence of Router Advertisements + + Even if a link has no routers, the DHCPv6 service to obtain addresses + may still be available, and hosts may want to use the service. From + the perspective of autoconfiguration, a link has no routers if no + Router Advertisements are received after having sent a small number + of Router Solicitations as described in [RFC4861]. + + 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. + In this case, the forwarding node's address must be manually + configured in hosts to be able to send packets off-link, since the + only mechanism to configure the default router's address + automatically is the one using Router Advertisements. + +5.5.3. Router Advertisement Processing + + For each Prefix-Information option in the Router Advertisement: + + a) If the Autonomous flag is not set, silently ignore the Prefix + Information option. + + b) If the prefix is the link-local prefix, silently ignore the + Prefix Information option. + + c) If the preferred lifetime is greater than the valid lifetime, + silently ignore the Prefix Information option. A node MAY wish to + log a system management error in this case. + + d) If the prefix advertised is not equal to the prefix of an + address configured by stateless autoconfiguration already in the + list of addresses associated with the interface (where "equal" + means the two prefix lengths are the same and the first prefix- + length bits of the prefixes are identical), and if the Valid + Lifetime is not 0, form an address (and add it to the list) by + combining the advertised prefix with an interface identifier of + the link as follows: + + | 128 - N bits | N bits | + +---------------------------------------+------------------------+ + | link prefix | interface identifier | + +----------------------------------------------------------------+ + + + +Thomson, et al. Standards Track [Page 18] + +RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007 + + + If the sum of the prefix length and interface identifier length + does not equal 128 bits, the Prefix Information option MUST be + ignored. An implementation MAY wish to log a system management + error in this case. The length of the interface identifier is + defined in a separate link-type specific document, which should + also be consistent with the address architecture [RFC4291] (see + Section 2). + + It is the responsibility of the system administrator to ensure + that the lengths of prefixes contained in Router Advertisements + are consistent with the length of interface identifiers for that + link type. It should be noted, however, that this does not mean + the advertised prefix length is meaningless. In fact, the + advertised length has non-trivial meaning for on-link + determination in [RFC4861] where the sum of the prefix length and + the interface identifier length may not be equal to 128. Thus, it + should be safe to validate the advertised prefix length here, in + order to detect and avoid a configuration error specifying an + invalid prefix length in the context of address autoconfiguration. + + Note that a future revision of the address architecture [RFC4291] + and a future link-type-specific document, which will still be + consistent with each other, could potentially allow for an + interface identifier of length other than the value defined in the + current documents. Thus, an implementation should not assume a + particular constant. Rather, it should expect any lengths of + interface identifiers. + + If an address is formed successfully and the address is not yet in + the list, the host adds it to the list of addresses assigned to + the interface, initializing its preferred and valid lifetime + values from the Prefix Information option. Note that the check + against the prefix performed at the beginning of this step cannot + always detect the address conflict in the list. It could be + possible that an address already in the list, configured either + manually or by DHCPv6, happens to be identical to the newly + created address, whereas such a case should be atypical. + + e) If the advertised prefix is equal to the prefix of an address + configured by stateless autoconfiguration in the list, the + preferred lifetime of the address is reset to the Preferred + Lifetime in the received advertisement. The specific action to + perform for the valid lifetime of the address depends on the Valid + Lifetime in the received advertisement and the remaining time to + the valid lifetime expiration of the previously autoconfigured + address. We call the remaining time "RemainingLifetime" in the + following discussion: + + + + +Thomson, et al. Standards Track [Page 19] + +RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007 + + + 1. If the received Valid Lifetime is greater than 2 hours or + greater than RemainingLifetime, set the valid lifetime of the + corresponding address to the advertised Valid Lifetime. + + 2. If RemainingLifetime is less than or equal to 2 hours, ignore + the Prefix Information option with regards to the valid + lifetime, unless the Router Advertisement from which this + option was obtained has been authenticated (e.g., via Secure + Neighbor Discovery [RFC3971]). If the Router Advertisement + was authenticated, the valid lifetime of the corresponding + address should be set to the Valid Lifetime in the received + option. + + 3. Otherwise, reset the valid lifetime of the corresponding + address to 2 hours. + + The above rules address a specific denial-of-service attack in + which a bogus advertisement could contain prefixes with very small + Valid Lifetimes. Without the above rules, a single + unauthenticated advertisement containing bogus Prefix Information + options with short Valid Lifetimes could cause all of a node's + addresses to expire prematurely. The above rules ensure that + legitimate advertisements (which are sent periodically) will + "cancel" the short Valid Lifetimes before they actually take + effect. + + Note that the preferred lifetime of the corresponding address is + always reset to the Preferred Lifetime in the received Prefix + Information option, regardless of whether the valid lifetime is + also reset or ignored. The difference comes from the fact that + the possible attack for the preferred lifetime is relatively + minor. Additionally, it is even undesirable to ignore the + preferred lifetime when a valid administrator wants to deprecate a + particular address by sending a short preferred lifetime (and the + valid lifetime is ignored by accident). + +5.5.4. Address Lifetime Expiry + + A preferred address becomes deprecated when its preferred lifetime + expires. A deprecated address SHOULD continue to be used as a source + address in existing communications, but SHOULD NOT be used to + initiate new communications if an alternate (non-deprecated) address + of sufficient scope can easily be used instead. + + Note that the feasibility of initiating new communication using a + non-deprecated address may be an application-specific decision, as + only the application may have knowledge about whether the (now) + deprecated address was (or still is) in use by the application. For + + + +Thomson, et al. Standards Track [Page 20] + +RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007 + + + example, if an application explicitly specifies that the protocol + stack use a deprecated address as a source address, the protocol + stack must accept that; the application might request it because that + IP address is used in higher-level communication and there might be a + requirement that the multiple connections in such a grouping use the + same pair of IP addresses. + + IP and higher layers (e.g., TCP, UDP) MUST continue to accept and + process datagrams destined to a deprecated address as normal since a + deprecated address is still a valid address for the interface. In + the case of TCP, this means TCP SYN segments sent to a deprecated + address are responded to using the deprecated address as a source + address in the corresponding SYN-ACK (if the connection would + otherwise be allowed). + + An implementation MAY prevent any new communication from using a + deprecated address, but system management MUST have the ability to + disable such a facility, and the facility MUST be disabled by + default. + + Other subtle cases should also be noted about source address + selection. For example, the above description does not clarify which + address should be used between a deprecated, smaller-scope address + and a non-deprecated, sufficient scope address. The details of the + address selection including this case are described in [RFC3484] and + are beyond the scope of this document. + + An address (and its association with an interface) becomes invalid + when its valid lifetime expires. An invalid address MUST NOT be used + as a source address in outgoing communications and MUST NOT be + recognized as a destination on a receiving interface. + +5.6. Configuration Consistency + + It is possible for hosts to obtain address information using both + stateless autoconfiguration and DHCPv6 since both may be enabled at + the same time. It is also possible that the values of other + configuration parameters, such as MTU size and hop limit, will be + learned from both Router Advertisements and DHCPv6. If the same + configuration information is provided by multiple sources, the value + of this information should be consistent. However, it is not + considered a fatal error if information received from multiple + sources is inconsistent. Hosts accept the union of all information + received via Neighbor Discovery and DHCPv6. + + If inconsistent information is learned from different sources, an + implementation may want to give information learned securely + precedence over information learned without protection. For + + + +Thomson, et al. Standards Track [Page 21] + +RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007 + + + instance, Section 8 of [RFC3971] discusses how to deal with + information learned through Secure Neighbor Discovery conflicting + with information learned through plain Neighbor Discovery. The same + discussion can apply to the preference between information learned + through plain Neighbor Discovery and information learned via secured + DHCPv6, and so on. + + In any case, if there is no security difference, the most recently + obtained values SHOULD have precedence over information learned + earlier. + +5.7. Retaining Configured Addresses for Stability + + An implementation that has stable storage may want to retain + addresses in the storage when the addresses were acquired using + stateless address autoconfiguration. Assuming the lifetimes used are + reasonable, this technique implies that a temporary outage (less than + the valid lifetime) of a router will never result in losing a global + address of the node even if the node were to reboot. When this + technique is used, it should also be noted that the expiration times + of the preferred and valid lifetimes must be retained, in order to + prevent the use of an address after it has become deprecated or + invalid. + + Further details on this kind of extension are beyond the scope of + this document. + +6. Security Considerations + + Stateless address autoconfiguration allows a host to connect to a + network, configure an address, and start communicating with other + nodes without ever registering or authenticating itself with the + local site. Although this allows unauthorized users to connect to + and use a network, the threat is inherently present in the Internet + architecture. Any node with a physical attachment to a network can + generate an address (using a variety of ad hoc techniques) that + provides connectivity. + + The use of stateless address autoconfiguration and Duplicate Address + Detection opens up the possibility of several denial-of-service + attacks. For example, any node can respond to Neighbor Solicitations + for a tentative address, causing the other node to reject the address + as a duplicate. A separate document [RFC3756] discusses details + about these attacks, which can be addressed with the Secure Neighbor + Discovery protocol [RFC3971]. It should also be noted that [RFC3756] + points out that the use of IP security is not always feasible + depending on network environments. + + + + +Thomson, et al. Standards Track [Page 22] + +RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007 + + +7. Acknowledgements + + Thomas Narten and Susan Thompson were the authors of RFCs 1971 and + 2462. For this revision of the RFC, Tatuya Jinmei was the sole + editor. + + The authors of RFC 2461 would like to thank the members of both the + IPNG (which is now IPV6) and ADDRCONF working groups for their input. + In particular, thanks to Jim Bound, Steve Deering, Richard Draves, + and Erik Nordmark. Thanks also goes to John Gilmore for alerting the + WG of the "0 Lifetime Prefix Advertisement" denial-of-service attack + vulnerability; this document incorporates changes that address this + vulnerability. + + A number of people have contributed to identifying issues with RFC + 2461 and to proposing resolutions to the issues as reflected in this + version of the document. In addition to those listed above, the + contributors include Jari Arkko, James Carlson, Brian E. Carpenter, + Gregory Daley, Elwyn Davies, Ralph Droms, Jun-ichiro Itojun Hagino, + Christian Huitema, Suresh Krishnan, Soohong Daniel Park, Markku + Savela, Pekka Savola, Hemant Singh, Bernie Volz, Margaret Wasserman, + and Vlad Yasevich. + +8. References + +8.1. Normative References + + [RFC2464] Crawford, M., "Transmission of IPv6 Packets over + Ethernet Networks", RFC 2464, December 1998. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 4291, February 2006. + + [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, + "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, + September 2007. + +8.2. Informative References + + [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., + and M. Carney, "Dynamic Host Configuration Protocol for + IPv6 (DHCPv6)", RFC 3315, July 2003. + + [RFC3484] Draves, R., "Default Address Selection for Internet + Protocol version 6 (IPv6)", RFC 3484, February 2003. + + + +Thomson, et al. Standards Track [Page 23] + +RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007 + + + [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy + Extensions for Stateless Address Autoconfiguration in + IPv6", RFC 4941, September 2007. + + [RFC3972] Aura, T., "Cryptographically Generated Addresses + (CGA)", RFC 3972, March 2005. + + [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast + Listener Discovery (MLD) for IPv6", RFC 2710, + October 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 Listener Discovery (MLD) Protocol", RFC 3590, + September 2003. + + [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, + "SEcure Neighbor Discovery (SEND)", RFC 3971, + March 2005. + + [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 + Neighbor Discovery (ND) Trust Models and Threats", + RFC 3756, May 2004. + + [RFC1112] Deering, S., "Host extensions for IP multicasting", + STD 5, RFC 1112, August 1989. + + [IEEE802.11] IEEE, "Wireless LAN Medium Access Control (MAC) and + Physical Layer (PHY) Specifications", ANSI/IEEE + STd 802.11, August 1999. + + + + + + + + + + + + + + + + + + + +Thomson, et al. Standards Track [Page 24] + +RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007 + + +Appendix A. Loopback Suppression and Duplicate Address Detection + + Determining whether a received multicast solicitation was looped back + to the sender or actually came from another node is implementation- + dependent. A problematic case occurs when two interfaces attached to + the same link happen to have the same identifier and link-layer + address, and they both send out packets with identical contents at + roughly the same time (e.g., Neighbor Solicitations for a tentative + address as part of Duplicate Address Detection messages). Although a + receiver will receive both packets, it cannot determine which packet + was looped back and which packet came from the other node simply by + comparing packet contents (i.e., the contents are identical). In + this particular case, it is not necessary to know precisely which + packet was looped back and which was sent by another node; if one + receives more solicitations than were sent, the tentative address is + a duplicate. However, the situation may not always be this + straightforward. + + The IPv4 multicast specification [RFC1112] recommends that the + service interface provide a way for an upper-layer protocol to + inhibit local delivery of packets sent to a multicast group that the + sending host is a member of. Some applications know that there will + be no other group members on the same host, and suppressing loopback + prevents them from having to receive (and discard) the packets they + themselves send out. A straightforward way to implement this + facility is to disable loopback at the hardware level (if supported + by the hardware), with packets looped back (if requested) by + software. On interfaces in which the hardware itself suppresses + loopbacks, a node running Duplicate Address Detection simply counts + the number of Neighbor Solicitations received for a tentative address + 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 is + to discard any received packet whose link-layer source address is the + same as the receiving interface's. There is even a link-layer + specification that requires that any such packets be discarded + [IEEE802.11]. Unfortunately, use of that criteria also results in + the discarding of all packets sent by another node using the same + link-layer address. Duplicate Address Detection will fail on + interfaces that filter received packets in this manner: + + o If a node performing Duplicate Address Detection discards received + packets that have the same source link-layer address as the + receiving interface, it will also discard packets from other nodes + that also use the same link-layer address, including Neighbor + Advertisement and Neighbor Solicitation messages required to make + + + +Thomson, et al. Standards Track [Page 25] + +RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007 + + + Duplicate Address Detection work correctly. This particular + problem can be avoided by temporarily disabling the software + suppression of loopbacks while a node performs Duplicate Address + Detection, if it is possible to disable the suppression. + + o If a node that is already using a particular IP address discards + received packets that have the same link-layer source address as + the interface, it will also discard Duplicate Address Detection- + related Neighbor Solicitation messages sent by another node that + also use the same link-layer address. Consequently, Duplicate + Address Detection will fail, and the other node will configure a + non-unique address. Since it is generally impossible to know when + another node is performing Duplicate Address Detection, this + scenario can be avoided only if software suppression of loopback + is permanently disabled. + + Thus, to perform Duplicate Address Detection correctly in the case + where two interfaces are using the same link-layer address, an + implementation must have a good understanding of the interface's + multicast loopback semantics, and the interface cannot discard + received packets simply because the source link-layer address is the + same as the interface's. It should also be noted that a link-layer + specification can conflict with the condition necessary to make + Duplicate Address Detection work. + +Appendix B. Changes since RFC 1971 + + o Changed document to use term "interface identifier" rather than + "interface token" for consistency with other IPv6 documents. + + o Clarified definition of deprecated address to make clear it is OK + to continue sending to or from deprecated addresses. + + o Added rules to Section 5.5.3 Router Advertisement processing to + address potential denial-of-service attack when prefixes are + advertised with very short Lifetimes. + + o Clarified wording in Section 5.5.4 to make clear that all upper + layer protocols must process (i.e., send and receive) packets sent + to deprecated addresses. + + + + + + + + + + + +Thomson, et al. Standards Track [Page 26] + +RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007 + + +Appendix C. Changes since RFC 2462 + + Major changes that can affect existing implementations: + + o Specified that a node performing Duplicate Address Detection delay + joining the solicited-node multicast group, not just delay sending + Neighbor Solicitations, explaining the detailed reason. + + o Added a requirement for a random delay before sending Neighbor + Solicitations for Duplicate Address Detection if the address being + checked is configured by a multicasted Router Advertisements. + + o Clarified that on failure of Duplicate Address Detection, IP + network operation should be disabled and that the rule should + apply when the hardware address is supposed to be unique. + + Major clarifications: + + o Clarified how the length of interface identifiers should be + determined, described the relationship with the prefix length + advertised in Router Advertisements, and avoided using a + particular length hard-coded in this document. + + o Clarified the processing of received neighbor advertisements while + performing Duplicate Address Detection. + + o Removed the text regarding the M and O flags, considering the + maturity of implementations and operational experiences. + ManagedFlag and OtherConfigFlag were removed accordingly. (Note + that this change does not mean the use of these flags is + deprecated.) + + o Avoided the wording of "stateful configuration", which is known to + be quite confusing, and simply used "DHCPv6" wherever appropriate. + + o Recommended to perform Duplicate Address Detection for all unicast + addresses more strongly, considering a variety of different + interface identifiers, while keeping care of existing + implementations. + + o Clarified wording in Section 5.5.4 to make clear that a deprecated + address specified by an application can be used for any + communication. + + o Clarified the prefix check described in Section 5.5.3 using more + appropriate terms and that the check is done against the prefixes + of addresses configured by stateless autoconfiguration. + + + + +Thomson, et al. Standards Track [Page 27] + +RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007 + + + o Changed the references to the IP security Authentication Header to + references to RFC 3971 (Secure Neighbor Discovery). Also revised + the Security Considerations section with a reference to RFC 3756. + + o Added a note when an implementation uses stable storage for + autoconfigured addresses. + + o Added consideration about preference between inconsistent + information sets, one from a secured source and the other learned + without protection. + + Other miscellaneous clarifications: + + o Removed references to site-local and revised wording around the + keyword. + + o Removed redundant code in denial-of-service protection in + Section 5.5.3. + + o Clarified that a unicasted Neighbor Solicitation or Advertisement + should be discarded while performing Duplicate Address Detection. + + o Noted in Section 5.3 that an interface can be considered as + becoming enabled when a wireless access point changes. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Thomson, et al. Standards Track [Page 28] + +RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007 + + +Authors' Addresses + + Susan Thomson + Cisco Systems + + EMail: sethomso@cisco.com + + + Thomas Narten + IBM Corporation + P.O. Box 12195 + Research Triangle Park, NC 27709-2195 + USA + + Phone: +1 919-254-7798 + EMail: narten@us.ibm.com + + + Tatuya Jinmei + Corporate Research & Development Center, Toshiba Corporation + 1 Komukai Toshiba-cho, Saiwai-ku + Kawasaki-shi, Kanagawa 212-8582 + Japan + + Phone: +81 44-549-2230 + EMail: jinmei@isl.rdc.toshiba.co.jp + + + + + + + + + + + + + + + + + + + + + + + + + +Thomson, et al. Standards Track [Page 29] + +RFC 4862 IPv6 Stateless Address Autoconfiguration September 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + 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 + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + + + + + + + + + + + +Thomson, et al. Standards Track [Page 30] + -- cgit v1.2.3