RFC 1971

IPv6 Stateless Address Autoconfiguration

📅 published August 1996, from ietf

IPv6 Stateless Address Autoconfiguration 🦋

Okay bestie, this is RFC 1971, and it's giving foundational 💅. Here are the title block facts:

  • RFC: 1971
  • Title: IPv6 Stateless Address Autoconfiguration
  • Authors: S. Thomson (Bellcore) and T. Narten (IBM) 👑
  • Working group: Network Working Group
  • Category: Standards Track
  • Date: August 1996
  • Obsoletes / updates: nothing is listed in the header

Status of this Memo ✨

This is an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 🫶. For where it stands in standardization, check the current edition of "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈.

Abstract 💜

Okay so this doc spells out the steps a host takes to figure out how to autoconfigure its interfaces in IPv6. That whole process includes making a link-local address and checking that it's unique on the link 🔥, deciding what gets autoconfigured (addresses, other info, or both), and, for addresses, whether they come from the stateless way, the stateful way, or both 🤔.

It defines how to generate a link-local address, how to generate site-local and global addresses through stateless address autoconfiguration, and the Duplicate Address Detection procedure. The stateful details live somewhere else 🙈.

Table of Contents 🧚

1.  INTRODUCTION............................................    2
2.  TERMINOLOGY..............................................    4
   2.1.  Requirements........................................    7
3.  DESIGN GOALS.............................................    8
4.  PROTOCOL OVERVIEW........................................    9
   4.1.  Site Renumbering....................................   11
5.  PROTOCOL SPECIFICATION...................................   11
   5.1.  Node Configuration Variables........................   12
   5.2.  Autoconfiguration-Related Variables.................   12
   5.3.  Creation of Link-Local Addresses....................   13
   5.4.  Duplicate Address Detection.........................   13
      5.4.1.  Message Validation.............................   15
      5.4.2.  Sending Neighbor Solicitation Messages.........   15
      5.4.3.  Receiving Neighbor Solicitation Messages.......   15
      5.4.4.  Receiving Neighbor Advertisement Messages......   16
      5.4.5.  When Duplicate Address Detection Fails.........   16
   5.5.  Creation of Global and Site-Local Addresses.........   17
      5.5.1.  Soliciting Router Advertisements...............   17
      5.5.2.  Absence of Router Advertisements...............   17
      5.5.3.  Router Advertisement Processing................   17
      5.5.4.  Address Lifetime Expiry........................   19
   5.6.  Configuration Consistency...........................   19
SECURITY CONSIDERATIONS......................................   19
REFERENCES...................................................   20
AUTHORS' ADDRESSES...........................................   21
APPENDIX: LOOPBACK SUPPRESSION & DUPLICATE ADDRESS DETECTION.   22

1. INTRODUCTION ✨

Okay, so this doc does the same job as the abstract: it lays out how a host decides to autoconfigure its interfaces in IPv6 💖. That covers making a link-local address and verifying it's unique on the link, figuring out what should be autoconfigured, and picking stateless, stateful, or both for addresses. It also defines the link-local generation process, the stateless process for site-local and global addresses, and the Duplicate Address Detection procedure. Stateful autoconfiguration is specified elsewhere.

IPv6 has two autoconfiguration mechanisms: stateful and stateless 🦋. Stateless is the chill one. It needs no manual setup on hosts, minimal (if any) router setup, and no extra servers 😌. A host builds its own addresses from info it already has plus info routers advertise. Routers advertise prefixes that identify the subnets on a link, and each host makes an "interface token" that uniquely identifies its interface on a subnet. Stick the two together and you get an address ✨. With no routers around, a host can only make link-local addresses, but those are enough for nodes on the same link to talk to each other 🫶.

Stateful is more of a client-server situation 🖥️. Hosts get interface addresses and/or config info and parameters from a server, and the server keeps a database of which addresses went to which hosts 📒. The stateful protocol lets hosts get addresses, other config info, or both from that server. Stateless and stateful totally complement each other 💕. For example, a host can use stateless to make its own addresses but use stateful to get everything else. Stateful is described in [DHCPv6].

Stateless is the move when a site doesn't care about the exact addresses hosts end up with, as long as they're unique and properly routable 🌸. Stateful is for sites that want tighter control over exact address assignments 🎀. You can use both at once, and the site admin picks which type to use by setting the right fields in Router Advertisement messages [DISCOVERY] 🍓.

IPv6 addresses are leased to an interface for a fixed length of time, which can be infinite ♾️. Each address has a lifetime that says how long it stays bound to an interface. When that lifetime runs out, the binding and the address go invalid, and the address can be handed to another interface somewhere else on the Internet 🌍. So nothing breaks suddenly, an address goes through two phases while it's on an interface 🧁. First it's "preferred", which means it can be used for anything, no limits 💅. Later it turns "deprecated", because its binding is about to expire. A deprecated address isn't strictly forbidden, but using it is discouraged 🙈. New communication, like opening a brand-new TCP connection, should use a preferred address when it can. A deprecated address should only be used by apps that were already using it and would have a hard time switching to another address without a service disruption 😭.

To make sure every configured address is likely unique on a given link, nodes run a "duplicate address detection" algorithm on addresses before they assign them to an interface 🔍. The Duplicate Address Detection algorithm runs on all addresses, whether they came from stateless or stateful autoconfiguration. This document defines that algorithm 👑.

This autoconfiguration process only applies to hosts, not routers 🖥️. Since host autoconfiguration relies on info that routers advertise, routers have to be configured some other way. Routers are still expected to generate link-local addresses using the mechanism in this document ✨. They're also expected to pass the Duplicate Address Detection procedure on all addresses before assigning them to an interface 💜.

Section 2 defines the terminology used throughout 📚. Section 3 covers the design goals behind the current autoconfiguration procedure 🎯. Section 4 gives an overview of the protocol 🧚, and Section 5 digs into the details 🔥.

2. TERMINOLOGY ✨

okay bestie, let's lock in the vocab 💅 these are the words the whole doc uses, so we need them down cold 🔒

  • IP — Internet Protocol Version 6 🦋 The terms IPv4 and IPv6 only show up where they're needed to avoid ambiguity 🙈
  • node 🧚 — a device that implements IP.
  • router 👑 — a node that forwards IP packets that aren't explicitly addressed to itself.
  • host 🌸 — any node that isn't a router.
  • upper layer 🎀 — a protocol layer sitting immediately above IP. Examples are transport protocols like TCP and UDP, control protocols like ICMP, routing protocols like OSPF, and internet or lower-layer protocols that get "tunneled" over (i.e., encapsulated in) IP, like IPX, AppleTalk, or IP itself.
  • link 🔗 — a communication facility or medium that nodes use to talk at the link layer, which is the layer right below IP. Examples are Ethernets (simple or bridged), PPP links, X.25, Frame Relay, or ATM networks, and internet (or higher) layer "tunnels," like tunnels over IPv4 or IPv6 itself.
  • interface — a node's attachment to a link.
  • packet — an IP header plus payload.
  • address 💌 — an IP-layer identifier for an interface or a set of interfaces.
  • unicast address — an identifier for a single interface. A packet sent to a unicast address gets delivered to the interface that address identifies.
  • multicast address — an identifier for a set of interfaces (usually spread across different nodes). A packet sent to a multicast address gets delivered to all the interfaces that address identifies.
  • anycast address — an identifier for a set of interfaces (usually spread across different nodes). A packet sent to an anycast address gets delivered to just one of the interfaces that address identifies, the "nearest" one according to the routing protocol's measure of distance. See [ADDR-ARCH].
  • solicited-node multicast address — a multicast address that Neighbor Solicitation messages get sent to. The algorithm for computing the address is given in [DISCOVERY].
  • link-layer address — a link-layer identifier for an interface. Examples include IEEE 802 addresses for Ethernet links and E.164 addresses for ISDN links.
  • link-local address — an address with link-only scope, which can be used to reach neighboring nodes on the same link. Every interface has a link-local unicast address.
  • site-local address — an address whose scope is limited to the local site.
  • global address 🌍 — an address with unlimited scope.
  • communication — any packet exchange among nodes that needs the address of each node used in the exchange to stay the same for the whole exchange. Examples are a TCP connection or a UDP request-response.
  • tentative address — an address whose uniqueness on a link is being checked before it gets assigned to an interface. A tentative address doesn't count as assigned to an interface in the usual sense. An interface throws away received packets addressed to a tentative address, but it still accepts Neighbor Discovery packets related to Duplicate Address Detection for that tentative address.
  • preferred address ⭐ — an address assigned to an interface whose use by upper layer protocols is totally 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 to deprecated addresses still get delivered as expected. A deprecated address may keep being used as a source address in communications where switching to a preferred address would cause 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.
  • invalid address 💀 — an address that isn't 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 first case, the internet routing system won't be able to deliver the packet. In the latter case, the recipient of the packet won't be able to respond to it.
  • preferred lifetime ⏳ — the length of time a valid address stays preferred (i.e., the time until deprecation). When the preferred lifetime expires, the address becomes deprecated.
  • valid lifetime ⌛ — the length of time an address stays 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 token 🪪 — a link-dependent identifier for an interface that is (at least) unique per link. Stateless address autoconfiguration combines an interface token with a prefix to form an address. From the address autoconfiguration point of view, an interface token is a bit string of known length. The exact length of an interface token, and the way it gets created, is defined in a separate link-type specific document that covers issues related to transmitting IP over a particular link type (e.g., [IPv6-ETHER]). In many cases, the token will be the same as the interface's link-layer address.

2.1. Requirements

this part is giving rules 📜 throughout this doc, the words that set how strict a requirement is get capitalized. here they are:

  • MUST — This word or the adjective "REQUIRED" means that the item is an absolute requirement of this specification.
  • MUST NOT — This phrase means the item is an absolute prohibition of this specification.
  • SHOULD — This word or the adjective "RECOMMENDED" means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before choosing a different course.
  • SHOULD NOT — This phrase means that there may exist valid reasons in particular circumstances when the listed behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.
  • MAY — This word or the adjective "OPTIONAL" means that this item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because it makes the product better, while another vendor may leave the same item out.

3. DESIGN GOALS ✨

stateless autoconfiguration was built with these goals in mind 🎯

  • Manual configuration of individual machines before connecting them to the network should not be required. So we need a mechanism that lets a host get or create unique addresses for each of its interfaces. Address autoconfiguration assumes that each interface can provide a unique identifier for itself (an "interface token"). In the simplest case, an interface token is just the interface's link-layer address. An interface token can be combined with a prefix to form an address.
  • Small sites with a bunch of machines attached to a single link should not require a stateful server or router as a prerequisite for communicating. This is the plug-and-play magic ✨, and it comes from link-local addresses. Link-local addresses have a well-known prefix that identifies the (single) shared link the nodes attach to. A host forms a link-local address by appending its interface token to the link-local prefix.
  • A large site with multiple networks and routers should not require the presence of a stateful address configuration server. To generate site-local or global addresses, hosts must determine the prefixes that identify the subnets they attach to. Routers generate periodic Router Advertisements that include options listing the set of active prefixes on a link. 📡
  • Address configuration should make it easy to renumber a site's machines gracefully 🫶. For example, a site may want to renumber all of its nodes when it switches to a new network service provider. Renumbering works through leasing addresses to interfaces and assigning multiple addresses to the same interface. Lease lifetimes are how a site phases out old prefixes. Giving an interface multiple addresses creates a transition period where both the new address and the one being phased out work at the same time.
  • System administrators need to be able to specify whether stateless autoconfiguration, stateful autoconfiguration, or both should be used. Router Advertisements include flags that say which mechanisms a host should use. 🎀

4. PROTOCOL OVERVIEW ✨

Okay so this section is the glow-up montage 🎬 of what actually happens when an interface autoconfigures itself 💅. It only happens on multicast-capable links, bestie 🦋. It kicks off when a multicast-capable interface gets enabled, like during system startup 🌅. Nodes, both hosts AND routers, start by generating a link-local address for the interface 🧚‍♀️. That address is formed by appending the interface's token to the well-known link-local prefix 🎀.

Before that link-local address can actually be assigned and used, though, a node has to check that its "tentative" address isn't already taken by someone else on the link 🙈. So it sends a Neighbor Solicitation with the tentative address as the target. If another node is already using that address, it'll hit back with a Neighbor Advertisement to say so 💀. If another node is trying to claim the same address at the same time, it'll send a Neighbor Solicitation for the target too 👀. The exact number of times the Neighbor Solicitation gets (re)transmitted, and the delay between consecutive solicitations, is link-specific and may be set by system management ⚙️.

If a node figures out its tentative link-local address isn't unique, autoconfiguration stops and manual configuration of the interface is required 😭. To make recovery easier, it should be possible for an admin to supply an alternate interface token that overrides the default token. That way, autoconfiguration can be applied again using the new (presumably unique) interface token 🔄. Otherwise, link-local and other addresses will need to be configured manually 🛠️.

Once a node confirms its tentative link-local address is unique, it gets assigned to the interface 🎉. Now the node has IP-level connectivity with neighboring nodes 🫶. The remaining autoconfiguration steps are only done by hosts. Configuring routers is beyond the scope of this document, so we're leaving that alone 🙅‍♀️.

The next phase is getting a Router Advertisement, or figuring out there are no routers at all 📡. If routers are present, they send Router Advertisements that spell out what sort of autoconfiguration a host should do. If no routers are present, stateful autoconfiguration should be invoked 🧾.

Routers send Router Advertisements periodically, but the gap between them is usually longer than a host doing autoconfiguration wants to wait [DISCOVERY] ⏳. So to get one quickly, a host sends one or more Router Solicitations to the all-routers multicast group 🏃‍♀️. Router Advertisements carry two flags that tell hosts what kind of stateful autoconfiguration (if any) to do. The "managed address configuration" flag says whether hosts should use stateful autoconfiguration to get addresses. The "other stateful configuration" flag says whether hosts should use stateful autoconfiguration to get extra info, excluding addresses 📝.

Router Advertisements also contain zero or more Prefix Information options. These hold the info that stateless address autoconfiguration uses to generate site-local and global addresses 🌍. Quick heads-up: the stateless and stateful fields in Router Advertisements are processed independently of each other, and a host may use both stateful and stateless address autoconfiguration at the same time 🤹‍♀️. One Prefix Information option field, the "autonomous address-configuration flag", tells you whether or not that option even applies to stateless autoconfiguration. If it does, the extra option fields hold a subnet prefix plus lifetime values, which say how long addresses made from that prefix stay preferred and valid ⏰.

Because routers keep generating Router Advertisements, hosts keep receiving new ones 📬. Hosts process the info in each one as described above, adding to and refreshing what they got from earlier advertisements 🔁.

For safety, all addresses must be tested for uniqueness before they get assigned to an interface 🔍. With stateless autoconfig addresses, though, uniqueness is determined mainly by the part of the address that comes from the interface token. So if a node has already verified a link-local address is unique, any additional addresses made from that same interface token need not be tested individually 🧩. Addresses obtained manually or via stateful address autoconfiguration, on the other hand, should be tested for uniqueness individually. Some sites think Duplicate Address Detection costs more overhead than it's worth, so to accommodate them, it can be disabled with an administrative setting of a per-interface configuration flag 🙅‍♀️.

To speed things up, a host may generate its link-local address (and verify its uniqueness) at the same time it's waiting for a Router Advertisement 🏎️. A router may take a few seconds to respond to a Router Solicitation, so doing the two steps one after the other can make the total autoconfiguration time significantly longer 🐢.

4.1. Site Renumbering

Address leasing makes site renumbering easier by giving a way to time out addresses assigned to interfaces in hosts ⏱️. Right now, upper layer protocols such as TCP don't support changing end-point addresses while a connection is open 😤. If an end-point address becomes invalid, existing connections break and all communication to that invalid address fails 💔. Even when applications use UDP as the transport protocol, addresses must generally remain the same during a packet exchange 📦.

Splitting valid addresses into preferred and deprecated categories is a way to tell upper layers that a valid address might become invalid soon. Any future communication using that address will fail if its valid lifetime runs out before the communication ends ⌛. To avoid that drama, higher layers should use a preferred address (assuming one with sufficient scope exists) so the address is more likely to stay valid for the whole communication 💅. It's up to system administrators to set appropriate prefix lifetimes so failed communication is kept to a minimum when renumbering happens 🧑‍💻. The deprecation period should be long enough that most, if not all, communications are already using the new address by the time an address becomes invalid 🫶.

The IP layer is expected to give upper layers (including applications) a way to pick the most appropriate source address for a given destination, and possibly other constraints too 🎯. An application can choose the source address itself before it starts a new communication. Or it can leave the address unspecified, and then the upper networking layers use the IP layer's mechanism to choose a suitable address on the application's behalf 🤖.

Detailed address selection rules are beyond the scope of this document 📚.

5. PROTOCOL SPECIFICATION

Autoconfiguration happens on a per-interface basis, on multicast-capable interfaces 🧁. For multihomed hosts, it's done independently on each interface 🏠. It applies mainly to hosts, with two exceptions. Routers are expected to generate a link-local address using the procedure outlined below 🧭. Also, routers perform Duplicate Address Detection on all addresses before 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 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., [IPv6-ETHER]).

Autoconfiguration also assumes the variable RetransTimer is present, as defined in [DISCOVERY] 💫. For autoconfiguration purposes, RetransTimer sets the delay between consecutive Neighbor Solicitation transmissions during Duplicate Address Detection (if DupAddrDetectTransmits is greater than 1). It also sets how long a node waits after sending the last Neighbor Solicitation before it ends the Duplicate Address Detection process ⏳.

Hosts keep a bunch of data structures and flags for autoconfiguration 📋. We'll walk through some conceptual variables to see how they get used. These specific variables are just there for demonstration 🧠. An implementation doesn't have to have them at all, as long as its external behavior stays consistent with what's described in this document 🫧.

Beyond forming a link-local address and using Duplicate Address Detection, how routers (auto)configure their interfaces is beyond the scope of this document 🙅‍♀️.

Hosts maintain the following variables on a per-interface basis 🎀:

   ManagedFlag      Copied from the M flag field (i.e., the "managed
                    address configuration" flag) of the most recently
                    received Router Advertisement message. The flag
                    indicates whether or not addresses are to be
                    configured using the stateful autoconfiguration
                    mechanism. It starts out in a FALSE state.

   OtherConfigFlag  Copied from the O flag field (i.e., the "other
                    stateful configuration" flag) of the most recently
                    received Router Advertisement message.  The flag
                    indicates whether or not information other than
                    addresses are to be obtained using the stateful
                    autoconfiguration mechanism. It starts out in a
                    FALSE state.

A host also keeps a list of addresses, each with its corresponding lifetimes 📝✨. That address list holds both the autoconfigured addresses and the ones configured manually 💜.

Okay so a node makes its link-local address every single time an interface turns on 💖 Literally every time. An interface can come alive after any of these moments:

  • The interface gets initialized at system startup time 🌸
  • The interface gets reinitialized after a temporary interface failure, or after being temporarily disabled by system management 🔁
  • The interface attaches to a link for the very first time 🦋
  • The interface gets enabled by system management after having been administratively disabled 🧚

Here's the recipe 👩‍🍳 The well-known link-local prefix FE80::0 [ADDR-ARCH] (of appropriate length) gets the interface token stuck onto it. If the interface token is N bits long, it replaces the right-most N zero bits of the link-local prefix. But if the interface token is more than 118 bits in length, autoconfiguration fails 💀 and manual configuration is required.

A link-local address has an infinite preferred and valid lifetime, so it is never timed out ✨ It's immortal, iconic.

5.4. Duplicate Address Detection 🔍

Duplicate Address Detection MUST be performed on unicast addresses before they get assigned to an interface whose DupAddrDetectTransmits variable is greater than zero 🚨 This applies to all unicast addresses, whether they came from stateful, stateless or manual configuration.

(Duplicate Address Detection MUST NOT be performed on anycast addresses.) 🙅‍♀️ Each individual unicast address SHOULD be tested for uniqueness. Buuut when stateless address autoconfiguration is used, uniqueness is decided solely by the interface token, assuming subnet prefixes are assigned correctly (i.e., if all of an interface's addresses are generated from the same token, either all addresses or none of them will be duplicates). So for a set of addresses formed from the same interface token, it's enough to check that the link-local address generated from the token is unique on the link. In such cases, the link-local address MUST be tested for uniqueness before any of the other addresses formed from the token can be assigned to an interface 👑

The procedure uses Neighbor Solicitation and Advertisement messages, as described below. If a duplicate address is found during the procedure, the address cannot be assigned to the interface. If the address is derived from an interface token, a new token will need to be assigned to the interface, 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 going through Duplicate Address Detection 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 it processes those packets differently from ones whose Target Address matches an address assigned to the interface. Other packets addressed to the tentative address should be silently discarded.

It's also worth noting that Duplicate Address Detection must be performed prior to assigning an address to an interface, so that multiple nodes don't use the same address at once 🙅 If a node starts using an address in parallel with Duplicate Address Detection, and another node is already using that address, the node doing the detection will erroneously process traffic meant for the other node. That can have nasty results, like resetting open TCP connections 💔

The subsections below describe the specific tests a node performs to verify an address's uniqueness. An address is considered unique if none of the tests indicate a duplicate 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 [DISCOVERY]. A solicitation that passes these validity checks is called a valid solicitation or valid advertisement ✅

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 first one makes sure the node hears Neighbor Advertisements from other nodes already using the address 👂 The second one makes sure that two nodes trying to use the same address at the same moment spot each other 🫶

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 the first message sent from an interface after interface (re)initialization, the node should delay sending it by a random delay between 0 and MAX_RTR_SOLICITATION_DELAY, as specified in [DISCOVERY]. This helps ease congestion when lots of nodes start up on the link at the same time, like after a power failure, and may help avoid race conditions when more than one node is trying to solicit for the same address at the same time 🌩️ To make Duplicate Address Detection more robust, an interface MUST receive and process datagrams sent to the all-nodes multicast address or the solicited-node multicast address of the tentative address while it's delaying the initial Neighbor Solicitation 💪

5.4.3. Receiving Neighbor Solicitation Messages 📥

On receipt of a valid Neighbor Solicitation message on an interface, node behavior depends on whether the target address is tentative or not. If the target address is not tentative (i.e., it is assigned to the receiving interface), the solicitation is processed as described in [DISCOVERY]. If the target address is tentative, and the source address is a unicast address, the solicitation's sender is doing address resolution on the target, so the solicitation should be silently ignored. Otherwise, processing happens 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 coming from a node doing 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), it does not indicate the presence of a duplicate address 🪞

Implementor's Note: 🛠️ many interfaces give upper layers a way to selectively enable and disable looping back multicast packets. The details of how that facility is built can stop Duplicate Address Detection from working correctly. See the Appendix 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 prior to having sent one, the tentative address is a duplicate. This happens when two nodes run Duplicate Address Detection at the same time but send their initial solicitations at different moments (e.g., by picking different random delay values before sending 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 packets, yet one or more solicitations was received), the tentative address is a duplicate. This happens when two nodes run Duplicate Address Detection at the same time and send 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. If the target address is assigned to the receiving interface, the solicitation is processed as described in [DISCOVERY]. If the target address is tentative, the tentative address is not unique 🫣

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 token, the interface SHOULD be disabled 🔌

5.5. Creation of Global and Site-Local Addresses 🌍

Global and site-local addresses are formed by appending an interface token to a prefix of appropriate length. Prefixes come from Prefix Information options in Router Advertisements 📦 Creating global and site-local addresses, and configuring the other parameters described in this section, SHOULD be locally configurable. However, the processing described below MUST be enabled by default ✨

5.5.1. Soliciting Router Advertisements 🙋

Router Advertisements are sent periodically to the all-nodes multicast address. To get an advertisement fast, a host sends out Router Solicitations as described in [DISCOVERY] 🏃‍♀️

5.5.2. Absence of Router Advertisements 🏜️

If a link has no routers, a host MUST attempt to use stateful autoconfiguration to obtain addresses and other configuration information. An implementation MAY provide a way to disable the invocation of stateful autoconfiguration in this case, but the default SHOULD be enabled. From the perspective of autoconfiguration, a link has no routers if no Router Advertisements are received after a host has sent a small number of Router Solicitations, as described in [DISCOVERY] 🥺

5.5.3. Router Advertisement Processing ✨

okay so when a host gets a valid Router Advertisement (as defined in [DISCOVERY]) 💌, it copies the value of the M bit into ManagedFlag. If ManagedFlag flips from FALSE to TRUE, the host should invoke the stateful address autoconfiguration protocol and request address info 🙋. If it flips from TRUE to FALSE, the host should terminate the stateful address autoconfiguration protocol. That means it stops requesting addresses and ignores any responses to transactions still in progress 🛑. If the flag stays unchanged, nothing special happens 🤷‍♀️. The big rule here is that a host MUST NOT reinvoke stateful address configuration if it's already in the stateful protocol because of an earlier advertisement. no double-dipping allowed 🙅‍♀️

The O flag gets handled in a similar way 💅. The host copies the O flag into OtherConfigFlag. If that flips from FALSE to TRUE, the host should invoke the stateful autoconfiguration protocol and request information, but not addresses 📩. If it flips from TRUE to FALSE, any stateful autoconfiguration activity for parameters other than addresses should be halted 🧊. If the flag stays unchanged, no special action happens. Again, a host MUST NOT reinvoke stateful configuration if it's already participating in the stateful protocol because of an earlier advertisement 🔒

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 advertised prefix matches the prefix of an autoconfigured address (meaning one obtained via stateless or stateful address autoconfiguration) in the list of addresses on the interface, set the preferred timer to the option's preferred lifetime, and set the valid lifetime to the option's valid lifetime 💫

e) If the advertised prefix doesn't match the prefix of any address already in the list, then form an address (and add it to the list) by appending the interface token to the prefix, like this:

    |            128 - N bits               |       N bits           |
    +---------------------------------------+------------------------+
    |            link prefix                |   interface token      |
    +----------------------------------------------------------------+

If the sum of the prefix length and interface token 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. It's the system administrator's job to ensure that the lengths of prefixes in Router Advertisements are consistent with the length of interface tokens for that link type 🧑‍💼

In cases where a site needs longer prefixes than the interface token can accommodate, stateful autoconfiguration can be used 🧩

If an address is formed successfully, the host adds it to the list of addresses assigned to the interface, and initializes its preferred and valid lifetime values from the Prefix Information option 🎉

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 in new communications if an alternate (non-deprecated) address is available and has sufficient scope 🔄. The IP layer MUST continue to accept datagrams destined to a deprecated address, since a deprecated address is still a valid address for the interface 📬. An implementation MAY prevent any new communication from using a deprecated address, but system management MUST have the ability to disable such a facility 🎛️

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 🚫

Note that if a Prefix Information option is received with a preferred lifetime of zero, any addresses generated from that prefix are immediately deprecated. Similarly, if both the advertised deprecated and valid lifetimes are zero, any addresses generated from that prefix become invalid immediately ⚡

5.6. Configuration Consistency 🧩

it's totally possible for hosts to get address info from both stateless and stateful protocols, since both can be enabled at the same time 🧑‍🤝‍🧑. It's also possible that other config parameters, like MTU size and hop limit, get learned from both Router Advertisements and the stateful autoconfiguration protocol 📡. If the same config info is provided by multiple sources, the value of that info should be consistent. But it's not a fatal error if info from multiple sources is inconsistent 🤷‍♀️. Hosts accept the union of all information received via the stateless and stateful protocols. If inconsistent info is learned from different sources, the most recently obtained values always have precedence over anything learned earlier ⏰

SECURITY CONSIDERATIONS 🚨

okay this one is seriously important bestie 😭. Stateless address autoconfiguration lets a host connect to a network, configure an address, and start talking to other nodes without ever registering or authenticating itself with the local site 👀. Although this lets unauthorized users 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 Duplicate Address Detection opens up the possibility of denial of service attacks 💔. Any node can respond to Neighbor Solicitations for a tentative address, causing the other node to reject the address as a duplicate. This attack is similar to other attacks involving the spoofing of Neighbor Discovery messages, and it can be addressed by requiring that Neighbor Discovery packets be authenticated [RFC1826] 🔐

REFERENCES 📚

   [RFC1826] Atkinson, R., "IP Authentication Header", RFC 1826, August
             1995.

   [IPv6-ETHER] Crawford, M., "A Method for the Transmission of IPv6
             Packets over Ethernet Networks", RFC 1972, August 1996.

   [RFC1112] Deering, S., "Host Extensions for IP Multicasting", STD 5,
             RFC 1112, August 1989.

   [ADDR-ARCH] Hinden, R., and S. Deering, "Internet Protocol Version
             (IPv6) Addressing Architecture", RFC 1884, December 1995.

   [DHCPv6]  Work in Progress.

   [DISCOVERY] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
             Discovery for IP Version 6 (IPv6)", RFC 1970, August 1996.

Acknowledgements 🫶

the authors wanna give a huge thank you to the members of both the IPNG and ADDRCONF working groups for their input 💖. Special shoutouts to Jim Bound, Steve Deering, and Erik Nordmark 🌟

AUTHORS' ADDRESSES 🦋

   Susan Thomson
   Bellcore
   445 South Street
   Morristown, NJ 07960
   USA

   Phone: +1 201-829-4514
   EMail: set@thumper.bellcore.com


   Thomas Narten
   IBM Corporation
   P.O. Box 12195
   Research Triangle Park, NC 27709-2195
   USA

   Phone: +1 919 254 7798
   EMail: narten@vnet.ibm.com

APPENDIX: LOOPBACK SUPPRESSION & DUPLICATE ADDRESS DETECTION 🔁✨

okay so bestie, figuring out whether a multicast solicitation that just landed on you was looped back from yourself or actually came from another node is implementation-dependent 🤔. The tricky case is when two interfaces on the same link happen to have the same token and link-layer address, and they both send out packets with identical contents at roughly the same time (like Neighbor Solicitations for a tentative address during Duplicate Address Detection) 💀. The receiver gets both packets, but it can't tell which one was looped back and which came from the other node just by comparing contents, because they're identical 😭. Here's the good news though: you don't actually need to know which was which. If you receive more solicitations than were sent, the tentative address is a duplicate ✔️. The situation isn't always this straightforward tho 🙈.

The IPv4 multicast spec [RFC1112] recommends that the service interface give an upper-layer protocol a way to inhibit local delivery of packets sent to a multicast group that the sending host is a member of 🫶. Some apps know there won't be any other group members on the same host, so suppressing loopback means they don't have to receive (and toss) the packets they sent themselves 🗑️. A straightforward way to build this is to disable loopback at the hardware level (if the hardware supports it), with packets looped back (if requested) by software 🛠️. On interfaces where the hardware itself suppresses loopbacks, a node running Duplicate Address Detection simply counts the Neighbor Solicitations it received for a tentative address and compares that number to the number it expected. If there's a mismatch, the tentative address is a duplicate 🚨.

When the hardware can't suppress loopbacks, one possible software heuristic is to discard any received packet whose link-layer source address is the same as the receiving interface's 🧠. Unfortunately, that criteria also throws away every packet sent by another node using the same link-layer address 😩. Duplicate Address Detection will fail on interfaces that filter received packets this way: 💔

  • If a node performing Duplicate Address Detection discards received packets having the same source link-layer address as the receiving interface, it will also discard packets from other nodes using the same link-layer address, including Neighbor Advertisement and Neighbor Solicitation messages required to make 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 a node that is already using a particular IP address discards received packets having the same link-layer source address as the interface, it will also discard Duplicate Address Detection-related Neighbor Solicitation messages sent by another node using the same link-layer address. As a result, Duplicate Address Detection will fail, and the other node will configure a non-unique address 🙅‍♀️. Since it's generally impossible to know when another node is performing Duplicate Address Detection, this scenario can only be avoided if software suppression of loopback is permanently disabled 🔒.

So, to perform Duplicate Address Detection correctly when two interfaces are using the same link-layer address, an implementation needs a solid understanding of the interface's multicast loopback semantics 🧩. And the interface can't just discard received packets because their source link-layer address matches the interface's own, periodt 💅✨.

📦 where this page comes from