Summary

  • A DHCPv6 client uses Confirm after detecting changed network information to ask whether its existing addresses are still appropriate for the current link. The request deliberately names no server, so any server with enough link knowledge may answer.
  • Success says every submitted address passes that link test. The responder ignores T1, T2, preferred lifetime and valid lifetime; the reply neither finds nor extends the original lease.
  • RFC 9915, written by Tomek Mrugalski with Bernie Volz, Michael C. Richardson, Sheng Jiang and Timothy Winters, keeps topology, lease authority and runtime validity separate. An honest operator should preserve those joins instead of displaying “confirmed” as “renewed.”

The reassuring word with a narrow jurisdiction

Imagine a laptop waking after a train leaves one station. Wi-Fi has changed, router information has changed, and the machine still holds IPv6 addresses obtained earlier. It sends a DHCPv6 Confirm. A Reply comes back with Success.

That word looks conclusive. It is not vague; it is simply answering one precise question.

RFC 9915 defines Confirm for a client that has addresses but no delegated prefixes and detects a change in network information. The client asks whether those addresses remain appropriate for the link to which it is now attached. It is not asking for an address. It is not asking for more time. It is not even asking the server that originally allocated the leases.

The request must contain the Client Identifier and the relevant identity associations with all current addresses. It must not contain a Server Identifier. A server discards a Confirm that tries to name one. This omission is an architectural fact, not a missing field: the question belongs to any server that knows the prefixes on this link.

If all addresses pass that test, the server returns Success. If any one fails, it returns NotOnLink. If the server cannot perform the test—for example, because it lacks the link's prefix information—or the client supplied no address, it must remain silent.

So the three possible evidentiary states are not “yes,” “no” and “yes by timeout.” They are:

Success: this address set is appropriate here.

NotOnLink: at least one address in this set is not appropriate here.

No Reply: this exchange produced no server verdict.

The clocks are present precisely so they can be ignored

The most important line in the exchange is almost an anti-field. RFC 9915 says the client should set T1 and T2 in its IA_NA options, and the preferred and valid lifetimes in its IA Address options, to zero because the server will ignore them.

That instruction prevents a category error. Confirm carries addresses so the responder can evaluate topology. It does not carry authoritative lease clocks for the responder to adjudicate. A server that knows which prefix belongs on a link need not possess the allocating server's binding state.

The contrast with Renew is exact. At T1, a client sends Renew to the server from which the leases were obtained. That server locates the client's binding, checks the identity association and can return new preferred and valid lifetimes, along with T1 and T2. If Renew gets no response and T2 arrives, Rebind lets the client ask any available server to extend the leases.

Confirm, Renew and Rebind therefore divide authority along two axes:

  • Confirm asks any knowledgeable server about link fit.
  • Renew asks the assigning server about continued lease time.
  • Rebind asks any available server to take responsibility for extending time after the first authority is unavailable.

The IANA registry gives them distinct message codes—4, 5 and 6—because they are different operations. The numbers guarantee common labels. They do not prove that a particular server knew the link, held the binding or returned a valid extension.

Success does not reset the hourglass

What should a client do after a successful Confirm? It may continue using the addresses. Which lifetimes apply? The last known ones.

What if no server responds before the Confirm exchange ends? RFC 9915 again says the client should continue using the leases and other configuration, using their last known lifetimes. Silence and Success can therefore produce the same immediate action—continued use—without being the same evidence.

That distinction matters during an incident. A dashboard may observe that the address remained configured after mobility and infer that confirmation succeeded. The client may simply have timed out and followed the continuity rule. Only a correlated Reply with the transaction ID, responder identity and status code distinguishes the two paths.

Neither path replenishes time. If an address had 1,800 seconds of valid lifetime remaining before the exchange, it does not emerge with a fresh 1,800 seconds merely because it is topologically suitable. The clock continues from the original lease evidence until a Renew or Rebind Reply changes it.

RFC 4862 makes the expiry semantics concrete. An address can be preferred, then deprecated, then invalid. A deprecated address remains available for existing communication but is discouraged for new connections. An invalid address must not be used as a source or accepted as a destination. Confirm does not collapse those states into “active.”

This is an unusually good example of continuity without fictional renewal. DHCPv6 lets the running client avoid unnecessary disruption when no responder can settle the topology question. It does not manufacture time that no server granted.

One Success can outweigh several refusals

The client may receive Replies from more than one server because the Confirm names none. RFC 9915 supplies an aggregation rule: if any valid Reply reports Success, the client can use the addresses and ignore Replies reporting NotOnLink. Only when it receives one or more Replies and all of them report NotOnLink does it restart server discovery.

This is not a vote. The servers may have different information because of configuration lag, relay context or administrative scope. The protocol treats one affirmative server with usable link knowledge as sufficient for continued address use. That protects continuity, but it also means an audit must retain which server supplied the decisive affirmative answer.

A global counter saying “Confirm succeeded” loses the disagreement. A useful receipt records every responder, its DUID, the relay and interface context, the address set it evaluated, the configuration revision or prefix set it used and the exact outcome. When one Success overrules two NotOnLink replies, that fact may become the first clue in a provisioning inconsistency.

The transaction is atomic over the submitted addresses. If one address is inappropriate, the server reports NotOnLink for the exchange. An operator that wants to know which address caused the result needs additional diagnostic evidence; the status alone does not name it. A green or red total is therefore less informative than the input set that produced it.

Five other facts remain outside the Reply

An address can be appropriate for a link and still fail Duplicate Address Detection. Confirm does not ask whether another node already uses it.

It can be on-link while its next-hop neighbor is unreachable. Neighbor Unreachability Detection has a different state machine and different probes.

It can be valid as a source address while an upstream route is missing or filtered. A server's prefix knowledge is not a packet-delivery receipt.

It can belong to a live lease while an application session is broken. DHCP configuration is not transport continuity.

And the original assigning server can have lost or changed its binding while a different server still knows that the address prefix fits the link. Success proves no continuity of custody between those databases.

These exclusions do not weaken Confirm. They make it composable. A small shared operation can answer one question consistently while Duplicate Address Detection, router discovery, neighbor discovery, routing telemetry and lease management retain their own evidence.

Tomek Mrugalski's work joins specification to implementation

RFC 9915 is Internet Standard STD 102. It names Tomek Mrugalski, Bernie Volz, Michael C. Richardson, Sheng Jiang and Timothy Winters. Its long acknowledgements reflect an even wider community. No one name owns DHCPv6, and authorship does not confer authority over a vendor's client or an operator's server.

Mrugalski is a useful person through whom to examine this boundary because his public record crosses both sides of the old IETF phrase. The Datatracker records a substantial body of DHCP RFC work. ISC's written staff profile describes the Dibbler implementation that grew from his graduate work and his later role in developing Kea. The profile also recounts his preference for transparent, usable solutions and open code. That is dated professional context, not proof that every implementation follows RFC 9915.

The more important contribution is the shape of the mechanism. The standard does not make every server synchronize every lease before it can answer a movement question. It asks for the minimum common verdict the present link can supply. At the same time, it refuses to let that verdict speak for lifetime authority.

Heng Lu's Minimum Initial Specification provides a useful reading: standardize the smallest fact needed for interoperability, then leave later decisions with actors that possess the relevant local context. Running-Code Primacy adds that the actual client path matters more than the name of the message. An implementation must show whether it received Success, received only NotOnLink, or timed out; those branches can look identical for a few seconds and diverge later.

The agency problem begins when reporting costs are uneven. A vendor can cheaply expose “Confirm success.” The access operator bears the cost of retaining link-prefix revisions and relay context. The lease service owns binding history. The customer bears the outage if the old clock expires. If one green metric stands in for all four records, the cheapest reporter controls the promise while someone else carries the risk.

Six receipts for the address that stayed

The first receipt records the movement trigger: interface, old and new router or link information, client state and time. Without it, a later Confirm cannot be tied to the network change it was meant to evaluate.

The second freezes the old lease before the query: assigning server DUID, IAID, address, acquisition time, T1, T2, preferred lifetime, valid lifetime and remaining seconds. This is the clock that continues unless new lease evidence arrives.

The third captures the request: client DUID, transaction ID, complete address set, interface and absence of a Server Identifier. The absence proves that the client asked a link question rather than addressing the assigning server.

The fourth captures every Reply: responder DUID, relay path, link context, status and input prefix knowledge. Silence must be recorded as exchange expiry, not synthesized as Success.

The fifth is the decision receipt. It states which aggregation rule ran: at least one Success, all received Replies NotOnLink, or no Reply. It records whether the client continued or restarted discovery.

The sixth keeps later authority separate: any Renew or Rebind, new lifetime values, deprecation and invalidation times, Duplicate Address Detection, routing and reachability observations. Those facts may confirm a healthy service, but none can be backfilled from the word Success.

The honest status is longer than a badge and shorter than a myth: “addresses judged on-link by server S at time T; original lease lifetimes unchanged.” RFC 9915 gives operators all the vocabulary needed to say exactly that.

Sources