RFC 2462

IPv6 Stateless Address Autoconfiguration

📅 published December 1998, from ietf

IPv6 Stateless Address Autoconfiguration 🦋

Okay bestie, here's the title block tea ☕. This is RFC 2462, written by S. Thomson (Bellcore) and T. Narten (IBM) in December 1998 🎀. It's on the Standards Track and comes from the Network Working Group 🧚. It obsoletes RFC 1971 💅.

Status of this Memo ✨

So this doc is an Internet standards track protocol for the Internet community 💖. It also asks people to share discussion and suggestions for improvements 🫶. If you want to know where it stands in the standardization process, check the current edition of "Internet Official Protocol Standards" (STD 1) 📚. And distribution of this memo is unlimited, so share it with everyone 🌈.

Copyright (C) The Internet Society (1998). All Rights Reserved. 💜

Abstract 🦋

Okay so this doc is all about the steps a host takes to decide how to autoconfigure its interfaces in IP version 6 🔥. The autoconfig process includes making a link-local address and checking that it's unique on a link 🔗. It also covers figuring out what info should get autoconfigured (addresses, other info, or both) 🧩. And if it's addresses, whether they come from the stateless mechanism, the stateful mechanism, or both 💅. The doc 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 details of autoconfiguration using the stateful protocol live somewhere else 🧚.

Table of Contents 🌸

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

1. INTRODUCTION ✨

Okay so the intro repeats the abstract's core idea, just in a different outfit 💅. This doc spells out how a host decides to autoconfigure its IPv6 interfaces 🎀. That covers making a link-local address and making sure it's unique on the link 🔗. It also covers choosing what gets autoconfigured (addresses, other info, or both) 🧩. And for addresses, it's stateless, stateful, or both 💖. The doc defines how to generate a link-local address, how to generate site-local and global addresses through stateless autoconfig, and the Duplicate Address Detection procedure ✨. The stateful details are specified elsewhere 🙈.

IPv6 has both a stateful and a stateless autoconfig mechanism 🦋. Stateless autoconfig is giving low-maintenance 💅. Hosts don't need any manual config, routers need minimal config (if any), and you don't need extra servers 🫶. The stateless mechanism lets a host make its own addresses from a mix of local info and info that routers advertise 🧚. Routers advertise prefixes that identify the subnet(s) on a link 🌈. Hosts make an "interface identifier" that uniquely identifies an interface on a subnet 🔥. Then you combine the two to get an address 💜. If there are no routers, a host can only make link-local addresses 🙈. But link-local addresses are still enough for nodes on the same link to talk to each other 🍓.

In the stateful model, hosts get interface addresses and/or config info and parameters from a server 🎀. Servers keep a database tracking which addresses went to which hosts 📚. The stateful protocol lets hosts get addresses, other config info, or both from a server ✨. Stateless and stateful are besties and complement each other 🫶. For example, a host can use stateless autoconfig for its own addresses, then use stateful autoconfig to get other info 💅. Stateful autoconfig for IPv6 is future work, see [DHCPv6] 🔮.

Stateless is used when a site doesn't care much about the exact addresses hosts use, as long as they're unique and properly routable 🦋. Stateful is used when a site needs tighter control over exact address assignments 🔒. Both can be used at the same time 💖. 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 (possibly infinite) amount of time 🕰️. Each address has a lifetime that says how long it stays bound to an interface ⏳. When a lifetime expires, the binding (and the address) becomes invalid, and the address may be reassigned to another interface somewhere else on the Internet 🌍. To handle expiring bindings gracefully, an address goes through two phases while it's assigned to an interface 🦋. First it's "preferred", meaning it can be used for arbitrary communication with no restrictions 💖. Later it becomes "deprecated", because its binding is about to become invalid 🥀. While deprecated, using the address is discouraged, but it's not strictly forbidden 🙈. New communication (like opening a new TCP connection) should use a preferred address when possible ✨. A deprecated address should only be used by applications that already use it and would have trouble switching to another address without a service disruption 🫠.

To make sure configured addresses are likely unique on a given link, nodes run a "duplicate address detection" algorithm on addresses before assigning them to an interface 🔍. This algorithm runs on all addresses, whether they come from stateless or stateful autoconfig 💅. This document defines the Duplicate Address Detection algorithm 🎀.

The autoconfig process in this doc only applies to hosts, not routers 🧚. Since host autoconfig uses info that routers advertise, routers have to be configured some other way 🛠️. Still, routers are expected to generate link-local addresses using the mechanism described here 🌸. Routers are also expected to pass the Duplicate Address Detection procedure on all addresses before assigning them to an interface 👑.

Section 2 has the terminology definitions used throughout the doc 📖. Section 3 covers the design goals behind the current autoconfig procedure 🎯. Section 4 gives an overview of the protocol 🦋, and Section 5 goes into the full details 💖.

2. TERMINOLOGY ✨

okay so before we get into the good stuff, we need to agree on what words mean 🤓 these terms show up everywhere in the rest of the doc, so bookmark this section bestie 🔖

  • IP - Internet Protocol Version 6 💖 IPv4 only gets mentioned when it's needed to avoid confusion.
  • node - any device that implements IP 🌸
  • router - a node that forwards IP packets that aren't addressed to itself 🦋
  • host - any node that isn't a router 🎀
  • upper layer - the protocol layer sitting right above IP ✨ think transport protocols like TCP and UDP, control protocols like ICMP, routing protocols like OSPF, and also the stuff that gets "tunneled" inside IP (wrapped up in it), like IPX, AppleTalk, or even IP itself 🫶
  • link - the communication facility or medium 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, plus higher-layer "tunnels" like ones running over IPv4 or IPv6 itself 🧚
  • interface - a node's attachment to a link 🔌
  • packet - an IP header plus its payload 📦
  • address - an IP-layer identifier for one interface or a group of interfaces 💜
  • unicast address - an identifier for a single interface 💅 a packet sent to a unicast address gets delivered to the interface that address belongs to
  • multicast address - an identifier for a set of interfaces, usually sitting on different nodes 👑 a packet sent to a multicast address gets delivered to every interface with that address
  • anycast address - an identifier for a set of interfaces, usually on different nodes 🔥 a packet sent to an anycast address gets delivered to just one of them, the "nearest" one according to the routing protocol's idea of distance. see [ADDR-ARCH] for more 👀
  • solicited-node multicast address - a multicast address that Neighbor Solicitation messages get sent to 🧁 the way to compute it is in [DISCOVERY]
  • link-layer address - a link-layer identifier for an interface 🍓 examples are IEEE 802 addresses for Ethernet links and E.164 addresses for ISDN links
  • link-local address - an address with link-only scope, meaning it can reach neighbors attached to the same link and nothing beyond that 🏡 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 where each node's address has to stay the same for the whole exchange ✨ a TCP connection or a UDP request-response are both good examples
  • tentative address - an address whose uniqueness on a link is still being checked before it gets assigned to an interface 🦋 it's not really considered assigned yet. an interface throws away packets addressed to a tentative address, but it still accepts the Neighbor Discovery packets for Duplicate Address Detection of that address 🙈
  • preferred address - an address assigned to an interface that upper layer protocols can use with zero restrictions 💖 preferred addresses can be used as the source (or destination) address of packets sent from (or to) that interface
  • deprecated address - an address assigned to an interface whose use is discouraged but not banned 🥀 it should basically stop being picked as a source address for new conversations, but packets to and from it still get delivered just fine. it can keep being used as a source in conversations where switching to a preferred address would cause real trouble for a particular upper-layer activity (like an existing TCP connection) 😭
  • valid address - either a preferred or a deprecated address ✅ a valid address can show up as the source or destination of a packet, and the internet routing system is expected to deliver packets sent to it to the intended recipients 🚚
  • invalid address - an address that isn't assigned to any interface 💀 a valid address turns invalid once its valid lifetime runs out. invalid addresses should not show up as the destination or source of a packet. if they're the destination, routing can't deliver the packet, and if they're the source, the recipient can't reply 🙅‍♀️
  • preferred lifetime - how long a valid address stays preferred, which is the time until it gets deprecated ⏳ once the preferred lifetime expires, the address becomes deprecated
  • valid lifetime - how long an address stays in the valid state, which is the time until it becomes invalid ⌛ the valid lifetime has to be greater then or equal to the preferred lifetime. once it expires, the address becomes invalid
  • interface identifier - a link-dependent identifier for an interface that's unique per link (at least) [ADDR-ARCH] 🎀 stateless address autoconfiguration combines an interface identifier with a prefix to make an address. from autoconfiguration's point of view, an interface identifier is just a bit string of known length. the exact length and how it's made is defined in a separate link-type specific document covering how IP gets transmitted over a particular link type (like [IPv6-ETHER]). in lots of cases the identifier is the same as the interface's link-layer address 💅

2.1. Requirements

the keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL 🫶 when they show up in this document, they get read the way [KEYWORDS] describes ✨

3. DESIGN GOALS 🌸

okay now for the why 💭 stateless autoconfiguration was designed with these goals in mind:

  • manual setup of each machine before it touches the network shouldn't be required 🙌 so there needs to be a way for a host to get or make unique addresses for each of its interfaces. address autoconfiguration assumes each interface can provide a unique identifier (an "interface identifier") 🪪 in the simplest case, that's just the interface's link-layer address, and an interface identifier can be combined with a prefix to form an address
  • small sites with a bunch of machines on one link shouldn't need a stateful server or router just to talk to each other 🧚 that's the plug-and-play magic of link-local addresses. they have a well-known prefix identifying the one shared link the nodes attach to, and a host forms its link-local address by tacking its interface identifier onto that prefix 🔌
  • big sites with lots of networks and routers shouldn't need a stateful address configuration server either 🏙️ to make site-local or global addresses, hosts have to figure out the prefixes for the subnets they're attached to, and routers handle that by sending periodic Router Advertisements with options listing the active prefixes on the link 📡
  • address configuration should make renumbering a site's machines smooth 🦋 imagine a site switching to a new network service provider and wanting to renumber everything. renumbering works through leasing addresses to interfaces and letting an interface hold multiple addresses at once 🔄 lease lifetimes are how a site phases out old prefixes, and having multiple addresses gives a transition period where the new address and the one being phased out both work at the same time 🌈
  • system admins need to be able to say whether stateless autoconfiguration, stateful autoconfiguration, or both should be used 👑 Router Advertisements include flags that tell a host which mechanisms it should use 💜

4. PROTOCOL OVERVIEW 🦋

okay so this section is the big-picture tour of what happens when an interface autoconfigures itself 💅 Autoconfiguration only happens on multicast-capable links, and it kicks off when a multicast-capable interface gets enabled, like during system startup 🌸 Nodes (hosts and routers) start by generating a link-local address for the interface. A link-local address is just the interface's identifier stuck onto the well-known link-local prefix. Easy 🎀

Before that link-local address can actually be assigned and used, though, a node has to check that this "tentative" address isn't already taken by someone else on the link 👀 It sends a Neighbor Solicitation with the tentative address as the target. If another node is already using that address, it replies with a Neighbor Advertisement saying so. If another node is trying to grab the same address at the same time, it sends a Neighbor Solicitation for the target too. How many times the Neighbor Solicitation gets (re)sent, and the delay between solicitations, is link-specific and can be set by system management 🧚

If a node finds that its tentative link-local address isn't unique, autoconfiguration stops and the interface needs manual configuration 😭 To make recovery less painful, it should be possible for an admin to supply an alternate interface identifier that overrides the default. Then autoconfiguration can run again using that new (presumably unique) identifier ✨ Otherwise, link-local and other addresses will need to be configured manually.

Once a node figures out its tentative link-local address is unique, it assigns it to the interface. Now the node has IP-level connectivity with its neighboring nodes 🫶 The remaining autoconfiguration steps are performed only by hosts. Router (auto)configuration is beyond the scope of this document 💜

The next phase is getting a Router Advertisement, or figuring out that no routers are present. If routers are present, they send Router Advertisements that specify 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 for what kind of stateful autoconfiguration (if any) should happen. 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 additional information, excluding addresses.

Router Advertisements also contain zero or more Prefix Information options. These hold information that stateless address autoconfiguration uses to generate site-local and global addresses. 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 autoconfiguration at the same time 🌈 One Prefix Information option field, the "autonomous address-configuration flag", indicates whether the option even applies to stateless autoconfiguration. If it does, additional option fields hold a subnet prefix together with lifetime values that say how long addresses created from that prefix stay preferred and valid.

Because routers keep generating Router Advertisements, hosts will keep receiving new ones. Hosts process each advertisement as described above, adding to and refreshing the information from earlier advertisements 💖

For safety, all addresses must be tested for uniqueness before they're assigned to an interface. For addresses created through stateless autoconfiguration, though, uniqueness is determined mainly by the portion of the address formed from the interface identifier. So if a node has already verified the uniqueness of a link-local address, extra addresses created from the same interface identifier don't need to be tested individually. In contrast, addresses obtained manually or via stateful address autoconfiguration should be tested individually. For sites that think the overhead of Duplicate Address Detection outweighs its benefits, it can be turned off through 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) in parallel with waiting for a Router Advertisement. A router may delay responding to a Router Solicitation for a few seconds, so if the two steps were done serially, the total autoconfiguration time could be a lot longer ⏳

4.1. Site Renumbering

Address leasing helps with site renumbering by providing a way to time out addresses assigned to interfaces in hosts 💅 Right now, upper layer protocols like 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, addresses generally have to stay the same during a packet exchange.

Dividing valid addresses into preferred and deprecated categories tells upper layers that a valid address may become invalid soon. Future communication using that address will fail if its valid lifetime expires before the communication ends ⏳ To avoid that, higher layers should use a preferred address (assuming one of sufficient scope exists) to make it more likely the address stays valid for the whole communication. It's up to system administrators to set appropriate prefix lifetimes so failed communication is minimized when renumbering happens. The deprecation period should be long enough that most, if not all, communications are 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 select the most appropriate source address for a given destination and possibly other constraints 🎀 An application may pick the source address itself before starting a new communication, or leave it unspecified. In that case, the upper networking layers use the mechanism the IP layer provides 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 is performed on a per-interface basis on multicast-capable interfaces. For multihomed hosts, autoconfiguration is performed independently on each interface. It 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 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 means Duplicate Address Detection isn't performed on tentative addresses. A value of one means a single transmission with no follow-up retransmissions.
    • Default: 1, but it 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 presence of the variable RetransTimer as defined in [DISCOVERY]. For autoconfiguration purposes, RetransTimer specifies the delay between consecutive Neighbor Solicitation transmissions performed during Duplicate Address Detection (if DupAddrDetectTransmits is greater than 1). It also specifies the time a node waits after sending the last Neighbor Solicitation before ending the Duplicate Address Detection process 🧚

A host maintains a number of data structures and flags related to autoconfiguration. Here we present conceptual variables and show how they're used to perform autoconfiguration. The specific variables are used for demonstration purposes only. An implementation isn't required to have them, as long as its external behavior is 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 is to be obtained using the stateful autoconfiguration mechanism. It starts out in a FALSE state.
    • In addition, when the value of ManagedFlag is TRUE, the value of OtherConfigFlag is implicitly TRUE as well. It is not a valid configuration for a host to use stateful address autoconfiguration to request addresses only, without also accepting other configuration information 🫶

A host also maintains a list of addresses together with their corresponding lifetimes. The address list contains both autoconfigured addresses and those configured manually 🍓

okay so a node forms a link-local address every single time an interface becomes enabled 💖 These are the moments that count:

  • 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.
  • The interface becomes enabled by system management after having been administratively disabled.

the recipe is giving simple ✨ A link-local address is made by prepending the well-known link-local prefix FE80::0 [ADDR-ARCH] (at the appropriate length) to the interface identifier. If the interface identifier is N bits long, it replaces the right-most N zero bits of the link-local prefix. But if the interface identifier is more than 118 bits long, autoconfiguration fails and you need manual configuration 🙈 Also, interface identifiers will typically be 64 bits long and based on EUI-64 identifiers as described in [ADDR-ARCH] 🫶

and the lifetime is literally iconic: a link-local address has an infinite preferred and valid lifetime, so it is never timed out ♾️👑

5.4. Duplicate Address Detection 🔍

so Duplicate Address Detection (DAD, bestie) runs on unicast addresses before they get assigned to an interface whose DupAddrDetectTransmits variable is greater than zero 💅 DAD MUST take place on all unicast addresses, no matter if they came from stateful, stateless or manual configuration, with these exceptions:

  • Duplicate Address Detection MUST NOT be performed on anycast addresses.
  • Each individual unicast address SHOULD be tested for uniqueness. However, when stateless address autoconfiguration is used, address uniqueness is determined solely by the interface identifier, assuming that subnet prefixes are assigned correctly (i.e., if all of an interface's addresses are generated from the same identifier, either all addresses or none of them will be duplicates). Thus, for a set of addresses formed from the same interface identifier, it is sufficient to check that the link-local address generated from the identifier is unique on the link. In such cases, the link-local address MUST be tested for uniqueness, and if no duplicate address is detected, an implementation MAY choose to skip Duplicate Address Detection for additional addresses derived from the same interface identifier.

the detection procedure uses Neighbor Solicitation and Advertisement messages, as described below 🦋 If a duplicate is found, the address cannot be assigned to the interface. If the address came from an interface identifier, you either need to assign a new identifier to the interface, or manually configure all of the IP addresses for it 😭 Also, the method for detecting duplicates is not completely reliable, so duplicates can still exist (for example, if the link got partitioned while DAD was running) 💀

an address going through DAD is called tentative until the procedure completes successfully ✨ A tentative address is not considered "assigned to an interface" in the traditional sense. The interface MUST accept Neighbor Solicitation and Advertisement messages that have the tentative address in the Target Address field, but it processes those packets differently from packets whose Target Address matches an address assigned to the interface. Other packets addressed to the tentative address should be silently discarded 🙈

it's also important that DAD happens before the address gets assigned, to stop multiple nodes from using the same address at once 🔥 If a node starts using an address in parallel with DAD, and another node is already using it, the node doing DAD will erroneously process traffic meant for the other node. That can lead to nasty stuff like resetting open TCP connections 💀

the next subsections describe the specific tests a node runs to check an address's uniqueness 🌈 An address counts as unique if none of the tests show a duplicate within RetransTimer milliseconds after the node has sent DupAddrDetectTransmits Neighbor Solicitations. Once it's 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 doesn't pass the validity checks specified in [DISCOVERY] 🫶 A solicitation that passes those 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 receives 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 time detect each other's presence 👯‍♀️

to check an address, a node sends DupAddrDetectTransmits Neighbor Solicitations, each one 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 (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 can help avoid race conditions when more than one node is trying to solicit the same address at once 🍓 To make DAD 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

when a valid Neighbor Solicitation arrives on an interface, what the node does depends on whether the target address is tentative 👀 If the target address is not tentative (meaning it's 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 sender is doing address resolution on the target, so the solicitation should be silently ignored. Otherwise, processing goes 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 it's from another node, the tentative address is a duplicate and should not be used (by either node). If it's from the node itself (because the node loops back multicast packets), then it does not indicate a duplicate address 💅

Implementor's Note: many interfaces give upper layers a way to selectively enable and disable the looping back of multicast packets. The details of how that facility is implemented may stop Duplicate Address Detection from working correctly. See the Appendix for further discussion. 🙈

these tests identify when a tentative address is not unique:

  • If a Neighbor Solicitation for a tentative address is received before the node has sent one, the tentative address is a duplicate. This happens when two nodes run Duplicate Address Detection at the same time but transmit their initial solicitations at different times (for example, by picking different random delay values before sending an initial solicitation) 🌸
  • If the actual number of Neighbor Solicitations received is more than the number expected based on the loopback semantics (for example, the interface does not loop back packets, yet one or more solicitations were 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

when a valid Neighbor Advertisement arrives on an interface, the node's 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

if a tentative address is determined to be a duplicate (as described above), it 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, 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 identifier to a prefix of the 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 one quickly, 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 get 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 the 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 (the kind defined in [DISCOVERY]), it copies the advertisement's M bit into ManagedFlag 💅. If ManagedFlag flips from FALSE to TRUE, and the host isn't already running the stateful address autoconfiguration protocol, the host should kick that protocol off and ask for both address information and other information 🦋. If ManagedFlag flips from TRUE to FALSE, the host should keep running stateful autoconfiguration anyway. That change does nothing 🙈. If the flag stays the same, nothing special happens. Bestie, the big rule is that a host MUST NOT reinvoke stateful address configuration if it's already in the stateful protocol because of an earlier advertisement 😭.

The O flag works the same way ✨. The host copies the O flag into OtherConfigFlag. If that flips from FALSE to TRUE, the host should invoke the stateful protocol and ask for information, but it leaves out addresses when ManagedFlag is FALSE 🌸. If OtherConfigFlag flips from TRUE to FALSE, the host keeps running stateful autoconfiguration, so again no effect. If nothing changes, nothing special happens. And yep, same vibe: a host MUST NOT reinvoke stateful configuration if it's already participating because of an earlier advertisement 💀.

Next, the host goes through every Prefix-Information option in the Router Advertisement 👑:

  • a) If the Autonomous flag isn't set, the host silently ignores that Prefix Information option 🙃.
  • b) If the prefix is the link-local prefix, the host silently ignores that Prefix Information option 🌈.
  • c) If the preferred lifetime is greater than the valid lifetime, the host silently ignores that Prefix Information option. A node MAY wish to log a system management error in this case 📝.
  • d) If the advertised prefix doesn't match a prefix of an address already in the list, and the Valid Lifetime isn't 0, the host forms a new address (and adds it to the list) by sticking the advertised prefix together with the link's interface identifier 🧩:
   |            128 - N bits               |       N bits           |
   +---------------------------------------+------------------------+
   |            link prefix                |  interface identifier  |
   +----------------------------------------------------------------+

If the prefix length plus the interface identifier length doesn't add up to 128 bits, the Prefix Information option MUST be ignored. An implementation MAY wish to log a system management error here too 🚨. It's the system administrator's job to make sure the prefix lengths in Router Advertisements match the interface identifier lengths for that link type 🧑‍💻. Heads up, interface identifiers are usually 64 bits long and based on EUI-64 identifiers, as described in [ADDR-ARCH] 🎀.

If the address forms successfully, the host adds it to the list of addresses on the interface and sets its preferred and valid lifetime values from the Prefix Information option 💖.

  • e) If the advertised prefix matches the prefix of an autoconfigured address (one got through stateless or stateful autoconfiguration) already on the interface, what happens next depends on the Valid Lifetime in the new advertisement and the Lifetime on the existing address (we're calling that one StoredLifetime for the rest of this) 👀:
    • 1) If the received Lifetime is greater than 2 hours or greater than StoredLifetime, the host updates the stored Lifetime of that address 🥰.
    • 2) If StoredLifetime is less than or equal to 2 hours and the received Lifetime is less than or equal to StoredLifetime, the host ignores the prefix. The exception is if the Router Advertisement this option came from was authenticated (for example, via IPSec [RFC2402]). If it was authenticated, StoredLifetime should be set to the Lifetime in the received option 🔐.
    • 3) Otherwise, the host resets the stored Lifetime on that address to two hours ⏰.

These rules are there to stop a specific denial of service attack 🛡️. In that attack, a bogus advertisement carries prefixes with really tiny Valid Lifetimes. Without these rules, one unauthenticated advertisement with bogus short-lived Prefix Information options could make every address on a node expire early, which is so not it 😱. These rules make sure legitimate advertisements (which get sent periodically) "cancel" the short lifetimes before they actually take effect 🫶.

5.5.4. Address Lifetime Expiry ⏳

A preferred address turns deprecated when its preferred lifetime runs out 🍂. A deprecated address SHOULD keep being used as a source address in conversations that already exist, but it SHOULD NOT be used in new communications when an alternate (non-deprecated) address with enough scope is available 🌷. IP and higher layers (like TCP and UDP) MUST keep accepting datagrams sent to a deprecated address, since it's still a valid address on the interface 💌. An implementation MAY stop any new communication from using a deprecated address, but system management MUST be able to turn that off, and the facility MUST be disabled by default 🎛️.

An address (and its link to the 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 🧁

Hosts can get address information from both stateless and stateful protocols, since both might be turned on at the same time 🍭. It's also possible that other configuration values, like MTU size and hop limit, get learned from both Router Advertisements and the stateful autoconfiguration protocol 📡. If the same configuration info comes from more than one source, the value should be consistent. It's not treated as a fatal error if info from different sources doesn't match, though 🫠. Hosts accept the union of everything they learn through the stateless and stateful protocols 🤝. And if inconsistent info shows up from different sources, the most recently obtained values always win over anything learned earlier ⭐.

6. SECURITY CONSIDERATIONS 🔐

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 😳. Yes, that means unauthorized users can connect and use the network, but the threat is inherently part of the Internet architecture 🌐. Any node with a physical attachment to a network can generate an address (using a variety of ad hoc techniques) that gives it connectivity 🫣.

Using Duplicate Address Detection opens the door to denial of service attacks 🚧. Any node can respond to Neighbor Solicitations for a tentative address, which makes the other node reject that address as a duplicate 😤. This attack is similar to other attacks that spoof Neighbor Discovery messages, and it can be addressed by requiring that Neighbor Discovery packets be authenticated [RFC2402] 🛡️✨.

7. References 📚

  • [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. 🔑
  • [IPv6-ETHER] Crawford, M., "A Method for the Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998. 🧵
  • [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🔤
  • [RFC1112] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989. 📣
  • [ADDR-ARCH] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 2373, July 1998. 🏠
  • [DHCPv6] Bound, J. and C. Perkins, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", Work in Progress. 🚧
  • [DISCOVERY] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. 🔎

8. Acknowledgements 🫶

The authors want to thank the members of both the IPNG and ADDRCONF working groups for their input 🙌. Special shoutouts to Jim Bound, Steve Deering, Richard Draves, and Erik Nordmark 🌟. Thanks also to John Gilmore for flagging the "0 Lifetime Prefix Advertisement" denial of service attack vulnerability. This document includes changes that address that vulnerability 💜.

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@raleigh.ibm.com

9. APPENDIX A: LOOPBACK SUPPRESSION & DUPLICATE ADDRESS DETECTION 🔥

Okay bestie, this one is the loopback mystery arc 🕵️‍♀️ Whether a multicast solicitation is just your own boomerang coming back or a real packet from another node is implementation-dependent, so each implementation gets to sort that out for itself. Ngl it's giving chaos.

The problem case looks like this: two interfaces on the same link have the same identifier and link-layer address, and they both send packets with identical contents at roughly the same time 😭. An example is Neighbor Solicitations for a tentative address during Duplicate Address Detection. A receiver gets both packets, but it can't tell which one was looped back and which one came from the other node just by comparing contents, since they're identical. In this particular case, you don't actually need to know which packet was the boomerang. If you receive more solicitations than were sent, the tentative address is a duplicate 💅. But it's not always this straightforward, periodt.

The IPv4 multicast spec [RFC1112] recommends that the service interface give upper-layer protocols a way to inhibit local delivery of packets sent to a multicast group the sending host belongs to. Some apps know there won't be any other group members on the same host, so suppressing loopback spares them from receiving and tossing out the packets they sent themselves 🙈. A straightforward way to do this is to disable loopback at the hardware level (if the hardware supports it), with packets looped back by software when someone asks for it. On interfaces where the hardware suppresses loopbacks itself, a node running Duplicate Address Detection just counts the Neighbor Solicitations it receives for a tentative address and compares that number with 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 matches the receiving interface's. The catch is that this also throws out every packet sent by another node using that same link-layer address 💀. So Duplicate Address Detection will fail on interfaces that filter this way:

  • If a node performing Duplicate Address Detection discards received packets with the same source link-layer address as the receiving interface, it will also discard packets from other nodes using that link-layer address. That includes the 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 with 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 that same link-layer address. As a result, Duplicate Address Detection fails and the other node ends up configuring a non-unique address 😩. Since it's generally impossible to know when another node is doing 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 use the same link-layer address, an implementation needs a solid understanding of the interface's multicast loopback semantics. It also can't just discard received packets because their source link-layer address matches the interface's own ✨

10. APPENDIX B: CHANGES SINCE RFC 1971 🦋

Here's the glow-up list of what changed since RFC 1971 💖

  • Switched the document to the term "interface identifier" instead of "interface token," so it lines up with the other IPv6 documents 🧚
  • Clarified the definition of a deprecated address to make it crystal clear that it's totally fine to keep sending to or from deprecated addresses 🫶
  • Reworded Section 5.4 for clarity. There's no substantive change here, just a cleaner read 🌸
  • Added rules to Section 5.5.3 (Router Advertisement processing) to deal with a potential denial-of-service attack when prefixes get advertised with very short Lifetimes 🔥
  • Clarified the wording in Section 5.5.4 so it's obvious that all upper layer protocols must process (that is, send and receive) packets sent to deprecated addresses 👑

Copyright (C) The Internet Society (1998). All Rights Reserved. 🎀

Okay, the legal bit, but make it cute ✨ You can copy and share this document and translations of it with others. You can also write derivative works that comment on or explain it or help implement it, and publish and distribute those too, in whole or in part, with no restrictions at all. The only catch is that the copyright notice and this paragraph have to stay on all copies and derivative works. This document itself can't be modified in any way (like removing the copyright notice or the references to the Internet Society or other Internet organizations). The exceptions are when it's needed to develop Internet standards, in which case the Internet Standards process copyright procedures must be followed, or when it's translated into languages other than English. 🦋

The permissions above are perpetual, and the Internet Society or its successors or assigns will not revoke them 💜

The disclaimer, verbatim because it's serious business:

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
📦 where this page comes from