Summary

  • IPv6 does not move an autoconfigured address directly from ordinary use to removal. Expiry of its preferred lifetime makes it deprecated; the address remains valid until a second lifetime expires.
  • The interval lets a replacement address attract new communication while existing exchanges retain an endpoint they may be unable to change without breaking.
  • A two-hour limit restrains unauthenticated attempts to shorten valid lifetime. If a rebooted router forgets the old prefix, the same caution can leave hosts waiting on a promise that no device remembers how to withdraw.

The first ending changed choice, not existence

The distinction appeared early. RFC 1971, published in 1996, described preferred, deprecated, valid and invalid address states. While preferred, an address is available to upper-layer protocols without the special discouragement attached to retirement. When Preferred Lifetime expires, it becomes deprecated. Its use is discouraged, not forbidden. Only the expiry of Valid Lifetime makes the address invalid and ends its association with the interface.

The intermediate state protects a property that the control plane cannot wish away. An open TCP connection ordinarily keeps its endpoint addresses for its lifetime. If a host deleted an old address the instant a replacement prefix appeared, it would break useful sessions merely because they began before the renumbering event. A deprecated address can therefore continue to receive packets and remain a source for existing communication where switching would impose hardship on the upper-layer activity.

Deprecation is not a softer word for unreachability. The first expiry asks whether this address should win the next assignment of work. The second asks whether it remains the host's address at all.

A router advertised two clocks in one option

RFC 4861 carries Preferred Lifetime and Valid Lifetime as separate 32-bit values in the Router Advertisement Prefix Information Option. Both are expressed in seconds relative to transmission; all one bits mean infinity. Preferred Lifetime cannot exceed Valid Lifetime. RFC 4862 tells a host to ignore a Prefix Information Option that reverses that order.

The numbers are not standalone permission. The Autonomous flag must also say that the prefix can be used for stateless address autoconfiguration. Prefix, flags and lifetimes divide the instruction into scope, authority and time. A lifetime copied without that context proves no right to form an address.

Router Advertisements refresh state periodically. A fixed advertised value can roll the horizon forward whenever another advertisement arrives. A decreasing value can lead toward a fixed withdrawal time. Omission from one advertisement is not withdrawal. Options may be spread across messages, and messages may be lost. Hosts act on information received and timers expiring, not on the ambiguous absence of one option from one packet.

Default selection redirected without expelling

Once Preferred Lifetime reaches zero, new communication should avoid the deprecated source when a suitable preferred address exists. RFC 6724 makes that distinction Rule 3 of default source address selection: avoid deprecated addresses.

The word default matters. An application may explicitly choose a source that remains valid. Existing communication may retain it. A new TCP SYN arriving at a deprecated but valid address can still receive a SYN-ACK sourced from that address when the connection would otherwise be permitted. Destination recognition does not stop when default source preference stops.

That asymmetry makes overlap useful. One interface can hold an address from the replacement prefix and another from the prefix being retired. New connections flow toward the preferred address. Old connections drain on the deprecated one. Merely finding the old address in an interface listing does not prove that migration failed. Its state, remaining lifetime and actual selection for new work are different evidence.

Zero preference began a drain rather than a deletion

An operator can advertise the old prefix with Preferred Lifetime set to zero and a still-positive Valid Lifetime. Hosts deprecate the derived address immediately but keep it assigned. The step closes the entrance to new dependency while leaving an exit for dependency that already exists.

RFC 5887 places such coexistence at the center of planned renumbering: introduce the new prefix, reduce preference for the old one, allow references and sessions to move, then finish its validity. The document also records how much remains outside the address state machine.

Routes, DNS records, firewall rules, access lists, certificates, logs and application configuration can each preserve the old value. An address can be locally valid after its return route has disappeared. Marking it deprecated does not remove a name from DNS. The two lifetimes offer a coordination primitive; they do not commit a distributed change across every system that has learned the address.

The overlap succeeds only if the replacement is genuinely usable and the old path remains usable long enough. A new preferred address with no working route is not progress. An old valid address whose provider has stopped routing is continuity only on the host's screen.

Forced death required stronger evidence than forced retirement

Ordinary Router Advertisements may be unauthenticated. If one forged message could reduce Valid Lifetime to a few seconds, an attacker on the link would gain a mass deletion control. RFC 4862 therefore bounds the effect of a short unauthenticated lifetime. When the existing remaining lifetime is long, the new value generally cannot force expiry sooner than two hours. If no more than two hours already remain, a still-shorter unauthenticated value is ignored for the valid-lifetime calculation.

Preferred Lifetime is deliberately treated differently. It is reset from the received advertisement even when the valid-lifetime reduction is restrained. The specification explains the asymmetry in terms of consequences. Making an address less attractive for new communication is a smaller attack than making it cease to exist, while a legitimate administrator needs a prompt way to deprecate an old prefix.

An authenticated advertisement can follow another branch. The rule does not prove that observed Router Advertisements were authenticated, and two hours is not a universal retirement interval. It is a host-side damage limit for a weakly evidenced invalidation.

A reboot could erase the name of the thing to withdraw

The graceful model assumes that the device announcing change still knows the old state. A customer-edge router can reboot, receive a different delegated prefix from its provider, and lose the prefix it had advertised before the reboot. It knows what to add. It no longer knows which old Prefix Information Option to send with zero lifetimes.

RFC 8978 analyzes this flash-renumbering failure. Without explicit withdrawal, hosts wait on the last timers they received. The document uses RFC 4861's default Prefix Information values to show the scale: an address can remain preferred for seven days and valid for thirty days. Those values are documented defaults, not measurements of deployed routers. They reveal how long an uncancelled promise can survive.

Even a router that remembers the old prefix and advertises both lifetimes as zero meets the two-hour protection when its message is unauthenticated. Resistance to forged invalidation and fast recovery from a genuinely dead prefix pull the same control in opposite directions.

Withdrawal had to survive loss and restart

RFC 9096 assigns customer-edge routers more memory. It recommends retaining previously advertised prefixes in stable storage, bounding LAN-side lifetimes against the remaining upstream delegation, and continuing to advertise stale prefixes with Preferred and Valid Lifetime both set to zero.

Repetition is part of the obligation. A host may miss one Router Advertisement. To reach hosts that still retain the old state, the router must keep naming the withdrawn prefix for a period related to the Valid Lifetime it previously promised. Reliable retirement is not complete when one packet leaves the interface.

The later guidance does not prove implementation or deployment. It exposes a condition beneath the early design: a system that can create and refresh time-bounded state must keep enough history to identify that state when it is time to end it. Remembering additions but forgetting withdrawals turns a graceful timer into a stale-state preservation mechanism.