Skip to main content

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:

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.

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.

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.
  • 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 "optimization" is NOT RECOMMENDED, and new implementations MUST NOT do that optimization.

The procedure for detecting duplicate addresses uses Neighbor Solicitation and Advertisement messages. If a duplicate address is discovered during the procedure, the address cannot be assigned to the interface.

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. 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.

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.

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.

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 tentative, and the source address is a unicast address, the solicitation should be silently ignored. In all cases, a node MUST NOT respond to a Neighbor Solicitation for a tentative address.

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.
  • If the actual number of Neighbor Solicitations received exceeds the number expected based on the loopback semantics, the tentative address is a duplicate.

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.
  3. Otherwise, the advertisement is processed as described in [RFC4861].

5.4.5 When Duplicate Address Detection Fails​

A tentative address that is determined to be a duplicate 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, IP operation on the interface SHOULD be disabled.

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.

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​

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].

5.5.3 Router Advertisement Processing​

For each Prefix-Information option in the Router Advertisement, the node processes according to the rules specified in RFC 4862, including forming new addresses and updating lifetimes of existing addresses.

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.

An address 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. Hosts accept the union of all information received via Neighbor Discovery and DHCPv6.

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. When this technique is used, the expiration times of the preferred and valid lifetimes must be retained.

Last updated on