How IPv6 hosts get addresses: SLAAC and DHCPv6

An IPv6 host configures itself from what routers advertise: a link-local address it checks for duplicates, global addresses it builds by stateless autoconfiguration from each prefix marked for it, and, where the network offers them, addresses, prefixes and DNS servers leased by DHCPv6. After reading, you can read the flags and lifetimes of a router advertisement, derive EUI-64, stable and temporary interface identifiers, tell stateful, stateless and prefix-delegation DHCPv6 apart, predict which source address a host uses, recognise rogue advertisements, duplicate addresses and stale prefixes, and watch each step with ip, rdisc6, tcpdump and Wireshark.

View as Markdown

An IPv6 interface seldom holds one address. (RFC) 7934 counts three or more per interface on many hosts, among them link-local, stable, privacy and Dynamic Host Configuration Protocol for IPv6 () addresses (RFC 7934, section 2). The host builds most of them itself by stateless address autoconfiguration (): "The IPv6 stateless autoconfiguration mechanism requires no manual configuration of hosts, minimal (if any) configuration of routers, and no additional servers" (RFC 4862, section 1). Routers steer it, and DHCPv6 beside it (section 1), with Router Advertisements (RAs) and their Prefix Information options (PIOs). After reading, you can follow Duplicate Address Detection (), decode an RA, derive an interface identifier (IID), tell the DHCPv6 modes apart, predict a host's source address, recognise the usual failures and watch each step with ip, rdisc6, tcpdump and Wireshark.

A link-local address that must prove it is unique

A node forms a link-local address whenever an interface becomes enabled (RFC 4862, section 5.3): on , the IID appended to fe80::/64 (RFC 2464, section 5), inside the fe80::/10 link-local type (RFC 4291, section 2.4). Routers must not forward it to other links (RFC 4291, section 2.5.6), and it never expires (RFC 4862, section 5.3).

Until checked, it is tentative: "Duplicate Address Detection MUST be performed on all unicast addresses prior to assigning them to an interface" (RFC 4862, section 5.4). The probe is a Neighbor Solicitation (NS) for the tentative address, from the unspecified address to the solicited-node group built from its low-order 24 bits (section 5.4.2; RFC 4291, section 2.7.1), one by default (RFC 4862, section 5.1), with RetransTimer at 1,000 milliseconds (RFC 4861, section 10). A reply, or another node probing for the same address, makes it a duplicate, which must not be assigned (RFC 4862, sections 5.4.3 and 5.4.5).

Modified (64-bit Extended Unique Identifier) inserts FFFE into the Media Access Control (MAC) address and complements its universal/local (U/L) bit, so 34-56-78-9A-BC-DE becomes 36-56-78-FF-FE-9A-BC-DE (RFC 2464, section 4):

MAC address                       34-56-78-9a-bc-de
complement U/L (0x34 XOR 0x02)    36-56-78-9a-bc-de
insert ff-fe after octet 3        36-56-78-ff-fe-9a-bc-de
interface identifier              3656:78ff:fe9a:bcde
link-local address                fe80::3656:78ff:fe9a:bcde
DAD probe to (low 24 bits)        ff02::1:ff9a:bcde

Reading a router advertisement

Routers multicast RAs periodically, and a host can prompt one with a Router Solicitation (RS) (RFC 4861, sections 3 and 4.1); they are Internet Control Message Protocol version 6 () types 134 and 133 (Internet Assigned Numbers Authority (IANA), ICMPv6 Parameters). Hosts accept RAs only from a link-local source with Hop Limit 255 (RFC 4861, sections 4.2 and 6.1.2), and a Router Lifetime of 0 means the sender is not a default router (section 4.2). The defaults, worked out (sections 6.2.1, 6.3.7 and 10):

MaxRtrAdvInterval          600 s
MinRtrAdvInterval          0.33 × 600 = 198 s
Router Lifetime            3 × 600 = 1,800 s
PIO Valid Lifetime         2,592,000 s = 30 days
PIO Preferred Lifetime     604,800 s = 7 days
host hearing no RA         first RS within 1 s, 3 RSs 4 s apart, 1 s more: 9 to 10 s

The flags sit in the RA header and each PIO, RFC 9762 adding P for DHCPv6 prefix delegation (DHCPv6-PD) (RFC 4861, sections 4.2, 4.6.2 and 6.2.1; RFC 9762, section 5):

Flag	Where	When set	Default
M, managed	RA header	addresses are available via DHCPv6	off
O, other	RA header	other configuration, such as DNS, is available via DHCPv6	off
L, on-link	PIO	the prefix can be used for on-link determination	on
A, autonomous	PIO	the prefix can be used for SLAAC	on
P, DHCPv6-PD Preferred	PIO	the network prefers prefix delegation to individual addresses	none in RFC 4861

M and O only signal: M that "addresses are available via Dynamic Host Configuration Protocol [DHCPv6]", O that "other configuration information is available via DHCPv6" (RFC 4861, section 4.2). RFC 4862 dropped its host rules for them without deprecating them (RFC 4862, Appendix C), and "M=0 does not prevent a node from attempting DHCPv6" (RFC 4861 errata, erratum 8055). SLAAC is decided per prefix, by A.

P asks hosts to take a delegated prefix instead of individual addresses, and "The P flag is independent of the value of the M and O flags in the RA" (RFC 9762, section 5); a client honouring it should not use SLAAC on a PIO with P and A set (section 7.1). If each device takes a /64, a /60 from an Internet service provider (), 2^4 = 16 /64s, runs out after 15 devices (section 1).

SLAAC: from prefix to address, and how lifetimes age it

RFC 4862 tests each PIO (RFC 4862, section 5.5.3): "If the Autonomous flag is not set, silently ignore the Prefix Information option"; a link-local prefix, or a preferred lifetime above the valid one, is ignored too; and "If the sum of the prefix length and interface identifier length does not equal 128 bits, the Prefix Information option MUST be ignored". Ethernet IIDs are 64 bits, so SLAAC needs a /64 (RFC 2464, section 4), as IPv6 subnetting and the /64 boundary explains. The IID is then appended (RFC 4862, section 5.5).

Past its preferred lifetime the address is deprecated, still reachable but not used for new communications; past its valid lifetime it is invalid (RFC 4862, sections 2 and 5.5.4). Each RA resets the preferred lifetime, but an unauthenticated RA cannot cut the valid lifetime below 2 hours, so one bogus RA cannot expire all of a node's addresses (section 5.5.3). An address with 30 days left that hears both lifetimes at zero is deprecated at once but valid for 2 more hours.

Choosing the interface identifier

An EUI-64 IID copies the into every address built from it, exposing the host to tracking across networks, address scanning and device-specific attacks (RFC 7217, section 1; RFC 8064, section 1). Hence: "By default, nodes SHOULD NOT employ IPv6 address generation schemes that embed a stable link-layer address in the IID" (RFC 8064, section 3). Its preferred default, RFC 7217, computes F(Prefix, Net_Iface, Network_ID, DAD_Counter, secret_key) into an IID stable within a subnet and different on every network (RFC 7217, Abstract and section 5).

Temporary addresses (RFC 8981, which obsoletes RFC 4941) add a randomised IID per prefix for communication the host starts, while the stable address takes incoming connections (RFC 8981, Abstract and section 2.2). They default to 2 days valid and 1 day preferred, minus a DESYNC_FACTOR of up to 0.4 × 86,400 = 34,560 seconds (sections 3.4 and 3.8), and an on-link observer such as the default router can still track them all (section 1.2). Linux defaults to EUI-64 (addr_gen_mode 0) and, on most devices, to no temporary addresses (use_tempaddr 0) (IP Sysctl).

The IPv6 Toolkit recovers the MAC from an EUI-64 address, fe80::211:22ff:fe33:4455 giving 00:11:22:33:44:55, whose Organizationally Unique Identifier (OUI) the OUI / MAC vendor lookup can trace to a manufacturer; the Python playground goes forward, from 00:1A:2B:3C:4D:5E to 2001:db8:cafe:1:21a:2bff:fe3c:4d5e.

DHCPv6: stateful, stateless and prefix delegation

DHCPv6 is now RFC 9915, published in January 2026 as Internet Standard 102 (STD 102); it obsoletes RFC 8415 (RFC 9915, Abstract). Clients send to ff02::1:2, the link-scoped All_DHCP_Relay_Agents_and_Servers group, and listen on UDP port 546, servers and relay agents on 547 (sections 5 and 7.2). Three modes:

Stateful: Solicit, Advertise, Request and Reply (section 5.2). An identity association for non-temporary addresses (IA_NA) holds the addresses, renewed at with their server or rebound at T2 with any (section 4.2).
Stateless: an Information-request for options such as DNS while SLAAC builds the address (section 5.1), as the O flag advertises.
Prefix delegation: an identity association for prefix delegation (IA_PD) holds prefixes (section 4.2); a delegated /48 gives a subscriber's router 2^16 = 65,536 /64s to assign one per link, never beyond the delegation's remaining lifetime (section 6.3).

DHCPv6 leaves gaps: "Addresses obtained from an IA Address option MUST NOT be used to form an implicit prefix with a length other than 128" (RFC 9915, section 18.2.10.1), and "the only mechanism to configure the default router's address automatically is the one using Router Advertisements" (RFC 4862, section 5.5.2), so managed networks still need RAs; compare the IPv4 lease lifecycle.

Where DNS servers come from

SLAAC cannot stand alone in any practical network without DNS configuration (RFC 8106, section 1). DHCPv6 carries OPTION_DNS_SERVERS (23) and OPTION_DOMAIN_LIST (24) (RFC 3646, sections 3 and 4); an RA carries the Recursive DNS Server (RDNSS) option, type 25, with a default lifetime of at least 3 × 600 = 1,800 seconds, zero withdrawing it (RFC 8106, section 5.1). Hosts must use it unless DNS is configured statically, and "the DNS information from takes precedence over that from RAs for DNS queries" (sections 1.2 and 5.3.1). Public DNS resolvers covers which ones to announce.

Picking a source address

RFC 6724 ranks candidate sources by rules including an appropriate scope (Rule 2), no deprecated addresses (Rule 3), temporary addresses (Rule 7) and the longest matching prefix (Rule 8) (RFC 6724, section 5). Rule 7 became the default with RFC 6724 (Appendix B), but implementations may reverse it, as use_tempaddr 1 does on Linux (IP Sysctl), and must let applications reverse it (RFC 6724, section 5). Its example picks the temporary 2001:db8:1::d5e3:7953:13eb:22e8 over the public 2001:db8:1::2 towards 2001:db8:1::d5e3:0:0:1 (section 10.1); ip addrlabel list prints the labels the rules use (ip-addrlabel(8)).

What goes wrong

Without RAs, a host has link-local addresses and no default route (RFC 4862, sections 1 and 5.5.2). If its three RSs are lost, RFC 7559 counts up to 30 minutes offline in the worst case and keeps hosts soliciting, backing off from 4 to 3,600 seconds (RFC 7559, sections 1 and 2); a forwarding Linux interface ignores RAs unless accept_ra is 2 (IP Sysctl). Contradictions are not fatal errors (RFC 4862, section 5.6): set M and clear A, and hosts without a DHCPv6 client stay link-local (RFC 8106, section 1.1); clear M and O, and some Customer Edge (CE) routers might not start DHCPv6-PD (RFC 9762, section 5).

Rogue RAs exploit trust: nothing in Neighbor Discovery says which neighbours may send RAs (RFC 4861, section 11.1), and "the default router address is drawn directly from the source address of the RA message" (RFC 6104, section 1). Most reported cases are accidents, such as Windows Internet Connection Sharing (ICS) turning a laptop into a 6to4 gateway (sections 2.2 and 2.3; dual-stack and translation). A rogue RA can also carry a fraudulent RDNSS address (RFC 8106, section 7.1) or the network's PIO with P set so that hosts ignore A (RFC 9762, section 10), and a rogue DHCPv6 server can hand out incorrect configuration (RFC 9915, section 22.1).

On the switches, Router Advertisement Guard () passes RAs only from the router's port, provided all traffic crosses them (RFC 6105, sections 2 to 4), and must parse the whole IPv6 header chain, since extension headers have slipped past some implementations (RFC 7113, Abstract and section 3); DHCPv6-Shield likewise discards DHCPv6 server messages except on designated switch ports (RFC 7610, section 1).

DAD is not completely reliable, and any node can answer for a tentative address to deny it (RFC 4862, sections 5.4 and 6). RFC 7527 documents a looped circuit that reflected a router's own probe, leaving DAD-failed an interface that typically serves thousands of broadband modems; its fix puts a random nonce in the probe (RFC 7527, sections 2 and 4).

Renumbering leaves stale prefixes. A CE router that reboots may obtain a new prefix by DHCPv6-PD (RFC 8978, section 1), while with default lifetimes hosts take up to 7 days to deprecate the old addresses and 30 days to remove them (section 2). RFC 9096 asks CE routers not to release the prefix on restart and caps advertised lifetimes at 2,700 seconds (45 minutes) preferred and 5,400 seconds (90 minutes) valid (RFC 9096, sections 3 and 4).

Seeing it on a real network

On Linux, ip address show filters by flag (ip-address(8)) and rdisc6 solicits RAs (rdisc6(8)):

ip -6 address show dev eth0
ip -6 address show dev eth0 tentative
ip -6 address show proto kernel_ra
ip -6 route
rdisc6 eth0
tcpdump 'icmp6 and icmp6[icmp6type] == icmp6-routeradvert'

The flags dynamic, tentative, dadfailed and temporary select SLAAC addresses, those in DAD, those that failed it and RFC 8981 ones, proto kernel_ra those installed from RAs, and each address shows valid_lft and preferred_lft (ip-address(8)); proto ra and expires mark routes from RAs (ip-route(8)). Illustrative, simplified output of the first command, for an EUI-64 host using temporary addresses:

fe80::3656:78ff:fe9a:bcde/64                                    (never expires)
2001:db8:cafe:1:3656:78ff:fe9a:bcde/64   dynamic            valid_lft 2591990  preferred_lft 604790
2001:db8:cafe:1:d5e3:7953:13eb:22e8/64   temporary dynamic  valid_lft 172790   preferred_lft 85790

rdisc6 prints M as Stateful address conf., O as Stateful other conf., each PIO's flags and times, the router lifetime and any RDNSS server, but not the PIO's P bit (ndisc6 source). This pcap-filter expression misses RAs behind extension headers, since icmp6 assumes none (pcap-filter(7)). In Wireshark, icmpv6.nd.ra.flag.m, icmpv6.nd.ra.flag.o, icmpv6.opt.prefix.flag.a and icmpv6.opt.prefix.valid_lifetime hold an RA's fields, icmpv6.opt.prefix.flag.p only in versions 4.6.0 to 4.6.9 (Wireshark, ICMPv6 fields), and dhcpv6.msgtype and dhcpv6.iaaddr.ip decode DHCPv6 (Wireshark, DHCPv6 fields). On Windows, Get-NetIPAddress -AddressFamily IPv6 reports PrefixOrigin (RouterAdvertisement, Dhcp) and SuffixOrigin (Link, Random) (Get-NetIPAddress).

The IPv6 Toolkit classifies addresses by prefix alone, so SLAAC, DHCPv6, RFC 7217 and temporary addresses under one prefix all read as global unicast; only the host, through proto kernel_ra or PrefixOrigin and SuffixOrigin, shows which path made each.

What to remember

Every interface first forms a link-local address in fe80::/64 and checks it with DAD: an NS from the unspecified address to its solicited-node group, here ff02::1:ff9a:bcde.
M and O only say what DHCPv6 offers; a PIO's A flag decides SLAAC, L on-link determination, and P (RFC 9762) asks for prefix delegation.
SLAAC ignores a PIO unless prefix length plus IID length is 128 bits, so on Ethernet only a /64 yields addresses.
Stable IIDs should follow RFC 7217, not the MAC address; RFC 8981 temporary addresses default to 2 days valid and 1 day preferred.
DHCPv6 (RFC 9915) leases addresses and prefixes, but the default router and the prefix length still come from RAs.
DNS servers arrive in the RA's RDNSS option (type 25) or DHCPv6 option 23, and DHCPv6 wins when both do.
An unauthenticated RA cannot cut a valid lifetime below 2 hours, so 7-day and 30-day defaults keep stale prefixes alive; RFC 9096 recommends 45 and 90 minutes.