Summary

  • IPv6 renumbering is a make-before-break process, not one routing command: old and new prefixes must coexist while routes, filters, addresses, DNS and application dependencies move on different clocks.
  • Operational inference: preferred and valid address lifetimes, delegated-prefix lifetimes, resolver-configuration lifetimes, positive and negative DNS caches, source selection and long-lived sessions form one change boundary. Withdrawal should be authorized only when the slowest declared dependency is proven to have converged.
  • Rollback is an operator obligation rather than an atomic protocol feature. It must be exercised while the old prefix, reverse zone and both traffic paths remain under the operator's control.

The cutover that has already split

Consider a branch during a provider change. The new aggregate is visible upstream and the authoritative zone publishes the new AAAA record. A monitoring probe reaches the service over the new address. Yet the branch router still holds the old delegated prefix, a recursive resolver has the former answer cached, and a database session remains bound to the old address. New outbound flows avoid that address after it becomes deprecated; the established session does not magically move.

Every subsystem can report a true statement. Routing is up. DNS is changed. The client has a new address. The service is reachable. The transaction can still be unsafe because those statements describe different clocks.

RFC 4192 frames IPv6 renumbering as make-before-break. The new prefix is installed while the old prefix continues to work, the network reaches a stable dual-prefix state, use moves, and only then is the old prefix removed. The document calls its procedure a skeleton to be adapted, not a universal automation recipe. That distinction matters: the protocol supplies mechanisms, while the operator owns the change contract.

One prefix appears in many control surfaces

An IPv6 address is not confined to a route. It can appear in link-prefix plans, router interfaces, Router Advertisements, DHCPv6 leases and delegated prefixes, ingress and egress filters, ACLs, service configuration, forward and reverse DNS, allowlists, monitoring targets and application caches. RFC 6879 adds the enterprise reality of manual configuration, long-lived sessions and systems outside the direct control of the renumbering team.

This makes inventory part of the proof. A search that finds no literal is useful, but not sufficient. An address may be derived from a prefix, retained in memory, copied into a partner's filter or learned while a branch was offline. The receipt has to say which surfaces were inspected, by whom, against which change version, and what exceptions remain.

Preferred is not valid, and valid is not in use

RFC 4862 gives an autoconfigured address two clocks. When its preferred lifetime expires, the address becomes deprecated. When its valid lifetime expires, it becomes invalid. RFC 6724 tells default source-address selection to avoid deprecated addresses when a preferred alternative exists.

Deprecation therefore changes the choice for new communication. It does not prove that old sessions have drained, that a daemon has refreshed a stored peer, or that an inbound client has stopped using a cached old AAAA record. Conversely, keeping the old address valid preserves a recovery surface, but it can also hide dependencies unless traffic is measured by prefix and by flow age.

There is another limit to central control. RFC 4862's two-hour rule constrains how an unauthenticated Router Advertisement can sharply reduce a remaining valid lifetime. That security protection prevents a forged advertisement from instantly invalidating addresses. It also means that an emergency operator command cannot be assumed to behave as a universal kill switch. The runbook must reflect host behavior, not the intent shown in the controller.

The branch and the resolver run separate clocks

RFC 8415 carries preferred and valid lifetimes for DHCPv6 addresses and delegated prefixes, with renewal and rebinding behavior. A customer-edge router can therefore retain an old IA_PD while the upstream route, a SLAAC host and an authoritative zone have moved. A branch that was offline throughout the overlap may return with stale local configuration or no tested path to the new prefix.

RFC 8978 documents how stale SLAAC prefixes can persist after flash-renumbering events. RFC 9096 recommends coordinating relevant Router Advertisement lifetimes with the remaining validity of a delegated prefix. These are operational considerations, not a claim that every customer-edge implementation behaves identically.

DNS adds at least three more clocks. Record TTLs govern cached AAAA and PTR answers. Primary-to-secondary publication governs when authoritative servers agree. Resolver addresses and search lists learned through Router Advertisements have their own RDNSS and DNSSL lifetimes under RFC 8106. Renumbering the service and renumbering the resolver used to find it are different operations.

Positive answers are not the whole cache. RFC 2308 specifies negative caching. If a resolver asked for a new name or address before the record existed, it may continue to return a negative answer after publication until that cache expires. A change board that records only the lowered AAAA TTL has not bounded this failure.

RFC 4472 also notes that long-running applications can retain DNS results beyond record TTLs. That observation reinforces the need to measure application behavior; it does not establish a universal cache duration.

RFC 4861 completes the local control surface: Router Advertisements carry router and prefix information that hosts interpret over time. The operator must observe what hosts learned, not merely what the router was configured to send.

Convergence is the maximum, not the average

Operational inference: the useful model is not a single timer. It is the maximum of the unresolved route, filter, PIO, IA_PD, RDNSS, positive-cache, negative-cache, application-cache and session clocks, plus any static exception without a timer at all.

Averages conceal the branch that was offline, the resolver with a longer negative cache, the partner ACL changed through a ticket queue and the one management appliance that resolves its server only at boot. The correct denominator is every declared dependency and vantage point, not only devices that reported during the window.

That changes the meaning of a green dashboard. A route probe can prove reachability on the new prefix. A DNS query can prove one resolver's current answer. A flow export can prove observed use. None independently authorizes withdrawal. Their evidence becomes decisive only when it is joined to the same change version and exception ledger.

Sources