Summary

  • IPv6 temporary addresses reduce one form of linkability by giving new outbound sessions an identifier with a bounded preferred lifetime; a successor can be ready before the older address is deprecated.
  • Deprecation is not deletion. An address may continue carrying established communications until its longer valid lifetime ends, while another preferred address is chosen for new work.
  • Rotation supplies neither anonymity, encryption nor authentication. Prefixes, stable addresses, accounts, cookies, logs, traffic patterns and on-link observation can still connect activity.

An IPv6 interface can hold several truths at once. A stable address may still be present. One temporary address is preferred for a new outbound connection. A successor is being prepared before that preferred period ends. The older address then becomes deprecated: the host should stop choosing it for new communications, yet an existing TCP connection can continue to use it. Only when the valid lifetime expires does the address become invalid and leave the usable set.

That overlap is the mechanism. The privacy gain does not arrive in a dramatic instant when a host throws away an identity. It comes from a sequence of ordinary state changes that narrows the time during which one visible interface identifier can link separate transactions.

The identifier that travelled too well

The original problem was unusually clear. Stateless address autoconfiguration could combine a network prefix with an interface identifier derived from a globally unique hardware identifier. When a laptop moved between networks, the prefix changed but the interface identifier could remain recognisable. An observer who saw addresses in several places could therefore have evidence that the transactions came from the same node.

RFC 3041, published in January 2001, answered by adding global-scope addresses built from interface identifiers that changed over time. These temporary addresses were intended for initiating outgoing sessions. They were used for a limited period, deprecated, and replaced. The older address could continue with a connection already under way, but it was not supposed to begin the next one.

The design was not a ban on stable addressing. It added another source address and depended on source-address selection to make that temporary address useful. Randomness without selection would merely create an extra address that applications might never choose. Selection without expiry would create another long-lived identifier. Privacy depended on both decisions working together.

RFC 4941 replaced RFC 3041 in September 2007. It kept the same basic lifecycle while changing controls around it. Duplicate Address Detection was to run for every temporary address, not merely the first generated from an interface identifier. Users gained a per-prefix enable or disable control. Implementations could use different interface identifiers across different prefixes, and the generation method was no longer tied to MD5. Yet RFC 4941 still recommended that temporary-address use be disabled by default, and its suggested maximum valid lifetime remained one week.

RFC 8981, published in February 2021, is the current specification and the third decision in the history. It removed the recommendation to disable the mechanism by default. It required temporary addresses on a host to have statistically different interface identifiers, including across different prefixes. It calculated a new desynchronisation value for each temporary address rather than establishing one rhythm at system start. It also reduced the default maximum valid lifetime from seven days to two, while retaining a one-day default preferred lifetime.

Those changes were not cosmetic. Reusing one temporary interface identifier across prefixes could itself join observations that ought to remain separate. A fixed regeneration rhythm could make transitions predictable. A week of validity left a larger population of old addresses on a host. RFC 8981 treated lifecycle diversity, cross-prefix separation and the size of the overlap as parts of the same privacy design.

Two clocks, not one disappearance

RFC 4862 supplies the grammar that makes the design intelligible. The preferred lifetime is the period in which use of an address is unrestricted. When it expires, the address becomes deprecated. The valid lifetime is longer or equal; when that second clock expires, the address becomes invalid.

A deprecated address is still a valid address. Packets sent to it continue to be processed. It may remain the source for an established communication when changing the endpoint would cause disruption. It should not normally be selected to initiate a new communication if a suitable non-deprecated address is available. An invalid address is different: it is no longer assigned to the interface and must not be used as a source or recognised as a destination.

The distinction protects continuity as well as privacy. If deprecation immediately killed every flow, identifier rotation would impose failure on long-running connections. If validity and preference ended at the same instant, the next address might not be ready. RFC 8981 therefore tells a host to begin regeneration REGEN_ADVANCE before deprecation, leaving enough time for generation and Duplicate Address Detection. In the normal case there is only one non-deprecated temporary address for a prefix and interface, apart from this transient preparation period. Older deprecated addresses can remain while the upper layers finish using them.

The published defaults describe a policy starting point, not a measurement of every device. RFC 8981 gives a one-day TEMP_PREFERRED_LIFETIME and a two-day TEMP_VALID_LIFETIME, both user-adjustable. The actual lifetime is also limited by the advertised prefix lifetime. A per-address DESYNC_FACTOR shortens the preferred period by a random amount, preventing hosts from turning over addresses in one easily predicted cadence.

The host also has to recognise a meaningful change of place. When an interface attaches to a different link, RFC 8981 requires its existing temporary addresses to be removed and new ones generated for that link. Different randomized identifiers then accompany the different links. An implementation may distinguish a genuine link change from a simple down-and-up event, avoiding needless regeneration when the network did not actually change.

What expiration protects

An IPv6 address is visible by design. A peer needs it to reply, an on-path system sees it in the packet header, and a service may store it in a log. If the interface-identifier portion remains constant for months or years, it becomes a convenient join key. A collector can group transactions that otherwise look unrelated. A mobile device may carry that join key from one network prefix to another.

Temporary addressing replaces that easy, long-lived join with several shorter intervals. New outbound sessions tend to acquire the currently preferred temporary address. Later sessions tend to use its successor. Collecting and coordinating observations by interface identifier becomes more expensive because the key expires and the host does not expose the same one forever. An address learned through an active exchange is also useful as a reachability target for less time.

The claim must stay at that scale. Rotation reduces address-based linkability; it does not prove that two observations are unrelated. The prefix can remain constant and may identify a household or a very small network. A stable address can remain configured and visible in other traffic. A DNS name can connect several addresses. A website can use a cookie or an authenticated account. A peer can join its own session records. An on-link observer, including the default router, can watch the host use both the old and the new address. An on-path observer can compare packet sizes and timing even when payloads are encrypted.

Temporary addresses do not encrypt anything. The IPv6 source and destination remain in clear packet headers. They do not authenticate the device, the user or the party at the other end. They do not make a host anonymous, and they do not revoke information already disclosed. If the user signs in to a service, that service can associate the session and its temporary address with the authenticated account. The mechanism is a limit on one identifier's lifetime, not a substitute for transport security, identity protection or application privacy.

RFC 8981 does not even require that a stable address always coexist with a temporary one. It permits an implementation to configure both or to use temporary addresses only. That flexibility is another reason not to infer a host's full address state from one packet. Seeing a temporary-looking address does not establish what other addresses exist; seeing it change does not establish why it changed.

The operational bill

The same change that frustrates a casual join makes operations harder. Address-indexed logs can make one device look like several. Packet traces may no longer reveal whether repeated faults belong to one host or a group. Security devices can mistake rapid regeneration for source-address forgery. More simultaneous addresses consume neighbour-cache and multicast-group capacity. Applications that expect several sessions to retain one source address may behave badly when selection changes or when an old address eventually becomes invalid.

The answer is not to restore a permanent identifier everywhere. It is to make observations explicit about time and scope. An operator investigating an incident needs the source address with a timestamp, the prefix and link context, and where appropriate the transport flow or authenticated application record. A preferred address observed at noon is evidence for that communication, not a durable asset name. A deprecated address still carrying a connection is not evidence that rotation failed. An old address becoming invalid is not evidence that the connection was safely migrated.

Control is divided. The router advertises prefix lifetimes. The host implements generation, deprecation and invalidation. Administrators can enable or disable temporary addresses globally or for selected prefixes. Applications and system defaults influence whether a temporary or stable address is selected. Services and networks retain their own observations. No participant receives a universal view merely because the standard defines the clocks.

The lasting historical change was therefore modest and consequential. IPv6 privacy extensions did not hide the address. They made one component of it perishable, arranged a successor before preference ended, and left enough overlap for real communications to finish. Protection came not from pretending the identifier had disappeared, but from deciding that it should no longer be the default key for the next connection.

Sources