IPv6 Privacy Extensions: what they are, how they work, and what they mean for your ISP network
When IPv6 was designed in the 1990s, SLAAC (Stateless Address Autoconfiguration, RFC 4862) was the elegant solution to the autoconfiguration problem: devices derive their IPv6 address from their MAC address using the EUI-64 format. Result: no DHCP, no manual configuration, with a unique and stable address for life.
The problem nobody thought seriously about back then: an address derived from the MAC address is a unique and permanent identifier. A web server can track a user across networks, sessions, and time simply by correlating the interface identifier portion of the IPv6 address. What required cookies or fingerprinting in IPv4 was automatic and unavoidable in original IPv6.
Privacy Extensions (RFC 4941) are the standard response to that problem. Since Windows Vista adopted them as default in 2006, virtually all modern operating systems have them active by default. For users, the result is better privacy. For ISPs operating IPv6 networks, the result is additional complexity that needs to be understood to manage properly.
How SLAAC works: the root of the problem
Before understanding Privacy Extensions, it helps to understand the mechanism they replace.
In classic SLAAC with EUI-64, the device takes its 48-bit MAC address and expands it to 64 bits to create the interface identifier:
MAC: 00:1A:2B:3C:4D:5E
EUI-64: 02:1A:2B:FF:FE:3C:4D:5E
→ IPv6 address: 2803:9800:cafe:1::21a:2bff:fe3c:4d5e
Bit 7 of the MAC (the “U/L” bit) is inverted, and FF:FE is inserted in the middle. The result is an address that:
- Is globally unique (assuming unique MACs, which in practice they usually are)
- Identifies the hardware unambiguously
- Is permanent as long as the device doesn’t change its network interface
- Follows the device regardless of which network prefix it uses
An analysis of any web server’s IPv6 logs can correlate the same interface identifier appearing from different networks over time. It’s free and implicit hardware tracking.
RFC 4941: Privacy Extensions for SLAAC
RFC 4941 (updated by RFC 8981 in 2021) introduces a mechanism for generating temporary, random interface identifiers. Instead of deriving the ID from the MAC, the device generates a cryptographically random one that rotates over time.
How the device generates temporary addresses
The simplified process:
- On startup, the device generates a random 64-bit interface identifier
- Using the /64 prefix from the router (obtained via Router Advertisement), it forms a temporary address
- It verifies there’s no conflict (DAD - Duplicate Address Detection)
- It uses that temporary address as the source address for outgoing connections
- It also keeps the stable address (EUI-64 or the one derived from RFC 7217) as a fallback address
The lifecycle of temporary addresses
Privacy Extensions define several timers that control the lifetime of addresses:
| Parameter | Typical value | Description |
|---|---|---|
TEMP_VALID_LIFETIME |
7 days | How long the address is valid |
TEMP_PREFERRED_LIFETIME |
24 hours | How long it’s used as the preferred source |
REGEN_ADVANCE |
5 seconds | Lead time to generate a new address before expiry |
The practical flow: the device generates a temporary address that it actively uses for roughly 24 hours. Before it expires as “preferred,” it generates a new one. The previous address remains valid (it can receive traffic) for up to 7 days, allowing existing connections to finish normally without interruption.
Result: at any given moment, a device with Privacy Extensions may have several active IPv6 addresses simultaneously — the stable address (if it exists) plus several temporary ones in different stages of their lifecycle.
What the ISP sees from the access router
From the ISP network’s perspective, Privacy Extensions produce behavior that can be surprising if you’re not prepared:
Source address rotation: A single device changes its source address roughly every 24 hours. If a customer has 5 devices, in a week you may see dozens of distinct active addresses within their /56 or /48 prefix.
Multiple simultaneous addresses: Each device has the stable address and one or more temporary ones coexisting. A router examining a household’s traffic may see 10-20 active IPv6 addresses for 3-4 devices.
Effective duration of log entries: If an abuse incident occurs and the ISP receives a complaint 48 hours later with the source IPv6 address, correlating it to the customer requires searching real-time logs — because that address may no longer be active.
Neighbor Discovery: Devices generate NDP (Neighbor Discovery Protocol) solicitations for each new temporary address. On access networks with many customers, the volume of NDP can be significant if not properly controlled.
Operational impact for the ISP: three critical areas
1. Abuse logs and compliance
In IPv4 with CGNAT or dynamic addresses, the ISP correlates a public IP + timestamp with a customer through DHCP assignment or NAT translation logs. With native IPv6, the customer has an assigned prefix (e.g., /56 or /48) and generates their own addresses within that prefix.
To respond to an abuse complaint with a specific IPv6 address, the ISP needs to:
- Identify which customer owns the prefix containing that address (this is straightforward, same as IPv4)
- If it needs to identify the specific device within the prefix (which most regulations don’t require), it needs the NDP logs from the access router
Data retention regulations in most LATAM countries apply to the assignment of the public IP to the customer, not to internal addresses within the customer’s prefix. Identifying the customer’s /56 prefix is sufficient for almost all legal requirements.
Operational recommendation: DHCPv6-PD prefix assignment logs (or static assignment if applicable) are the relevant compliance records in IPv6. Make sure those logs have adequate retention and are searchable by timestamp.
2. Technical support
When a customer calls because they have connectivity issues, the support technician needs to identify which address they’re using. With Privacy Extensions, the customer has multiple addresses and the one in use varies by session.
Best practices for support:
- Instead of working with the customer’s specific IPv6 address, work with the assigned prefix
- Management tools that allow searching by prefix and viewing all traffic/NDP state for the prefix
- If the customer can run
ip -6 addrorifconfig, ask for the complete address list and verify prefix connectivity
3. Monitoring and anomaly detection
Detection systems based on individual IP reputation (blacklists, scoring systems) work poorly with Privacy Extensions because the address rotates before reputation accumulates significantly.
For IPv6, detections should be based on the customer’s prefix or on traffic behavior, not on the specific source address. This is actually an improvement for the customer: they can’t be miscategorized due to a previous address from another user who had that prefix.
How Privacy Extensions are configured by operating system
Windows (Vista and later)
Active by default. Windows also implements RFC 7217 to generate “stable but opaque” addresses (not MAC-based but not rotational either). To disable:
netsh interface ipv6 set privacy state=disabled
Linux / Android
Configured in /proc/sys/net/ipv6/conf/*/use_tempaddr:
- 0: disabled
- 1: generated but not preferred
- 2: generated and preferred (default on most modern distros)
# Check current state
sysctl net.ipv6.conf.all.use_tempaddr
# Enable for all interfaces (permanent via /etc/sysctl.conf)
net.ipv6.conf.all.use_tempaddr = 2
net.ipv6.conf.default.use_tempaddr = 2
macOS / iOS
Active by default since OS X 10.7. iOS also uses random MAC addresses per Wi-Fi network (MAC randomization), which adds an additional layer of opacity.
Routers and IoT devices
Variable behavior. Home routers (which use SLAAC on their WAN) typically don’t implement Privacy Extensions — they use the stable EUI-64 address on the WAN interface. IoT devices depend on the firmware.
DHCPv6 stateful as an alternative?
Some ISPs opt to assign individual IPv6 addresses to devices via DHCPv6 stateful (similar to how DHCP works in IPv4) instead of relying on SLAAC. The advantages:
- Centralized control of assignments
- Exact log of which address each device has at each moment
- Simplifies technical support
The disadvantages:
- Requires scalable DHCPv6 infrastructure
- Many IoT devices and some operating systems have incomplete or buggy DHCPv6 support
- Doesn’t eliminate the problem: many devices ignore the DHCPv6 address and still generate a SLAAC temporary address for outgoing connections
The operator community’s recommendation is that DHCPv6-PD for prefix assignment to the CPE is the correct mechanism, but address management within the customer’s prefix should be left to the device’s SLAAC — including Privacy Extensions. The ISP only needs the prefix, not the individual addresses.
Operational readiness checklist for IPv6 with Privacy Extensions
For ISPs deploying or maturing their IPv6 implementation:
- Do DHCPv6-PD (or static) prefix assignment logs have sufficient retention to meet data retention obligations?
- Do support tools allow searching by prefix, not just by address?
- Can the abuse management system respond to complaints with prefix information?
- Do access routers have NDP logging enabled if device identification is needed?
- Does the support team understand why the customer has “many IPs” in IPv6 and know how to work with that?
- Do anomaly detection systems work with prefixes rather than individual IPs?
IPv6 is the present, not the future, for any ISP that wants to operate sustainably in Latin America. Privacy Extensions are part of the ecosystem and not something that can or should be disabled — designing operations around them is the correct practice.
Are you migrating to native IPv6 or having issues with support and compliance processes on your current IPv6 network? Write to us at [email protected] — we help ISPs with the operational design of their IPv6 deployments.