Summary

  • DHCPv6 Reconfigure is an authenticated request to begin another exchange, not a command containing the new configuration. The client must have accepted the mechanism, validate the trigger, send Renew, Rebind or Information-request, receive the next Reply and apply state under its own implementation.
  • RFC 6977 allows a relay-facing Reconfigure-Reply to say Success even when the server will send Reconfigure to no listed client. Reliable operations therefore need separate evidence for request processing, client selection, trigger delivery, transaction completion, installed state and application continuity.

The positive reply arrived first

Consider an illustrative access network in which a relay has learned that one link's provisioning data changed. It identifies several client DUIDs, supplies the link address and sends a Reconfigure-Request to the DHCPv6 server. The server returns Reconfigure-Reply with Success. An operations console turns green.

No client has changed.

Some identifiers may be listed in the reply because the server has no usable client record or because those clients never agreed to receive Reconfigure. Other triggers may be waiting behind a server rate limit. A Reconfigure may already be travelling through a Relay-reply, but the client has not authenticated it. One willing client may have begun Renew while another has not received anything. Even after a Renew reaches the server, the new Reply may not yet have reached the client, and a network application may still be using old state.

The green console is not wrong if it labels the event accurately. The server processed the relay's request. It becomes dangerous only when one acknowledgement is promoted into a larger claim: all affected clients have been reconfigured.

RFC 6977 makes the distinction unusually explicit. A successful Reconfigure-Reply lists client identifiers for which the server will not send Reconfigure. Success can be returned even when Reconfigure will be sent to none of them. That rule is not a semantic defect. It prevents the relay-server acknowledgement from pretending to be a client execution receipt.

The current contract is a trigger, not a configuration package

RFC 9915 is now the base DHCPv6 specification. The IANA DHCPv6 registry cites it for the ordinary message types, including RECONFIGURE value 10. Its design gives the common wire mechanism a narrow job.

A Reconfigure message must be unicast to one client. It must carry the server identifier, the matching client identifier, an accepted authentication result and a Reconfigure Message option. That option has only three valid outcomes: ask the client to send Renew, Rebind or Information-request.

The server must not place ordinary new configuration into the Reconfigure message. It cannot use the trigger to smuggle a new address, prefix, DNS server or other parameter past the normal exchange. The client asks for what it needs in the next transaction; the server constructs a Reply under the ordinary rules; the client processes that Reply.

This is a clean minimum common rule. The protocol needs to agree on how a server can wake a willing client and which exchange the client should begin. It does not need the trigger to become a privileged side channel that dictates all future state.

The client also announces whether it accepts this mechanism. Reconfigure Accept is a zero-length option with code 20. In its absence, the default is unwilling. A server that wants later triggering must preserve the negotiated and authenticated relationship rather than assume that every DHCPv6 client is remotely mutable.

The boundary is operationally important. A fleet count of clients with leases is not a count of clients that accept Reconfigure. A count of clients that advertised acceptance is not a count with recoverable authentication keys. A count with keys is not a count reachable at the recorded unicast or relay path. A count that received a valid trigger is not a count that completed a new exchange.

Authentication narrows the sender claim

RFC 9915 mandates authentication for Reconfigure because a forged trigger can consume client resources or steer the client toward malicious configuration. The currently specified Reconfiguration Key Authentication Protocol, RKAP, gives each client a 128-bit reconfigure key in an initial Reply. A later Reconfigure contains an HMAC-MD5 computed over the message with that key.

The accepted result is useful. It binds the received trigger to the key associated with the recorded server relationship and protects the packet against undetected modification within that mechanism. It also carries replay state. For replay-detection method zero, the client requires a strictly increasing 64-bit value per server. A server that supports Reconfigure must retain that value across restart; otherwise clients can reject later valid triggers as old.

That is the authentication authority. It is not a general certificate of server virtue. It does not prove that the future Reply contains correct configuration, that the client will accept the Reply, that the application's sockets will survive the transition or that the relay selected the right affected set.

RKAP has a stated boundary of its own. The initial key is sent in plain text. An attacker able to intercept that exchange may compromise the later protection. Operators should therefore avoid reporting “authenticated DHCPv6” as one timeless state. They need the provisioning path, key epoch, server DUID, replay value and restart continuity that made this particular validation acceptable.

The message validator also enforces structure. A client discards a trigger that was not unicast to it, names the wrong client, lacks the server identifier, lacks a valid requested exchange or fails authentication. The client ignores the trigger's transaction ID. Once it begins the selected exchange, it ignores additional Reconfigure messages until that transaction completes. Duplicate control traffic does not acquire additional authority merely by arriving more often.

The relay can ask; the server still decides

Ordinary Reconfigure begins at the server. RFC 6977 adds a reasoned upstream path for a relay that knows a configuration fact changed but cannot itself command a client to start a new DHCP exchange.

The motivating case uses relay-supplied options. RFC 6422 lets a relay provide eligible configuration information to the server, which can in turn return it to a client. If that relay-side information changes after the original lease exchange, the server may not know. Reconfigure-Request lets the relay name the affected clients and link and notify the server.

The relay's message contains one or more Client Identifier options and a Link Address option. It may include relay identity, relay-supplied data and a preferred follow-on message type. For a large affected population, it splits the identifiers across requests. It may remove clients during retransmission when observation shows they no longer need action, but it must not add new clients into the same retransmission sequence.

These are real relay decisions: which source event counts as a change, which link it affects, which clients belong to the set, what evidence justifies removing one and how fast requests may be sent. None automatically binds the server.

Intermediate relays are configurable. RFC 6977 gives them an accept default for relay-originated requests unless policy says otherwise. Servers have the opposite default: reject unless configured to accept. The server silently discards a request from an unknown relay and independently determines which clients, if any, should receive Reconfigure.

That asymmetry is sound. A relay is close to access state but does not own the server's bindings, authentication material, rate budget or client-support record. The server has those records but may not see the physical or subscriber-side event. The protocol shares the minimum information needed to coordinate without pretending either component owns the whole decision.

One request can produce several incomplete truths

RFC 6977 supports multiple servers behind one relay. The relay may send a request to each and must associate each reply with the correct server. For one client, the relay may consider the request handled if at least one Reconfigure-Reply does not list that client among those excluded.

That conclusion is intentionally narrow. At least one server intends to send or has accepted responsibility for the next step. It does not prove that another server did not also act, that the client will select the intended Reply, or that two servers hold consistent configuration. The transaction ID disambiguates the relay-server conversation, not the eventual client state.

Several positive signals can therefore coexist without being interchangeable:

  1. The relay accepted a source event and selected a client-link set.
  2. The server accepted and processed the relay request.
  3. The server chose a client and emitted an authenticated Reconfigure.
  4. The client validated the trigger and emitted Renew, Rebind or Information-request.
  5. The server received that request and stopped its trigger retransmission.
  6. The server generated a new Reply.
  7. The client accepted and installed the returned state.
  8. Applications and traffic operated correctly under that state.

The server may treat receipt of the selected client request as satisfying its Reconfigure request. That is a retransmission rule, not proof of the last three events. A counter labelled “reconfigure completed” at this point should be renamed unless its definition explicitly stops at client-request receipt.

Rate limits are part of authority

Remote triggers can create coordinated load. A changed link can affect many clients; each client requires its own Reconfigure; each successful trigger creates a further exchange; each exchange may traverse relays and touch binding state.

RFC 6977 therefore requires rate limits on the relay's Reconfigure-Request traffic and the server's triggered Reconfigure traffic. Its default maximum request size is 1280 octets, so a large client population becomes several messages. RFC 9915 separately limits server retransmission attempts for each client.

Rate limiting is not an implementation afterthought. It determines which clients receive action now, which wait, how a partial failure is reported and whether a provisioning change becomes a control-plane storm. A server that sends faster than clients or relays can absorb has enlarged a narrow trigger into a denial-of-service tool.

The evidence should retain the queue, not hide it. Record clients selected, excluded, deferred, rate-limited, attempted, authenticated, responding and verified. A dashboard that shows only total Success replies removes precisely the information leadership needs to understand blast radius and lag.

Recovered state can target the wrong present

Relay-triggered reconfiguration depends on records. RFC 6977 discusses stable storage and DHCPv6 Bulk Leasequery as ways to recover state after failure. RFC 5007 supplies lease queries, and RFC 7653 supplies an active stream for near-real-time lease changes.

Those tools improve visibility. They do not turn a recovered binding into current physical truth.

A client may have moved, restarted, stopped accepting triggers or changed its reachable address. A link identifier may be stable in configuration while the access topology has changed. An active feed may be delayed or interrupted. A recovered relay can know enough to construct a syntactically valid request while still selecting stale members of the affected set.

The correct question is not whether state exists. It is which observation produced it, when, under which relay and server identities, with which ordering guarantee, and what evidence confirms the client after the attempted change.

RFC 9243's management model is useful because it exposes client, relay and server as distinct configuration surfaces. RFC 8947 is useful for the opposite reason: it notes that a small implementation may omit Reconfigure because the required authentication machinery has a cost. Capability must be observed per implementation, not inferred from protocol family.

Renumbering shows why execution evidence matters

IPv6 renumbering is one reason to expedite changed configuration. RFC 6879 treats renumbering as a staged operational problem, not a single packet event. New prefixes need introduction, overlap, routing, DNS, policy, application and withdrawal sequencing.

Reconfigure can shorten the wait before a client asks again. It cannot make every client respond, guarantee that applications bind to new addresses, remove old state safely or decide when the old path may be withdrawn.

A useful rollout therefore measures at least four populations: clients believed affected, clients selected by a server, clients that complete the exchange and clients observed using the intended state. The differences are not noise. They are the authority boundaries.

The evidence ledger

For each material operation, preserve a linked but separable record:

  • the source fact that changed, its owner, timestamp and scope;
  • relay identity, link address, relay-supplied options hash and selected client DUID hashes;
  • request transaction ID, destination server, retransmission sequence and rate-limit state;
  • server validation result, known-relay policy, excluded clients and reply status;
  • per-client trigger timestamp, route, server DUID, authentication protocol, key epoch and replay value;
  • client validation, selected Renew/Rebind/Information-request and its transaction ID;
  • Reply identity, status, assigned-address or delegated-prefix fingerprints and option-set hash;
  • client installation time, old-state retirement and implementation result;
  • application, DNS, routing and packet observations under the new state;
  • reversal condition, responsible operator and final convergence proof.

DUIDs, keys and full subscriber configuration do not belong in an unrestricted analytics surface. Use controlled identifiers and privacy-safe hashes where the operational question allows. Evidence minimisation is compatible with evidence separation.

The ledger should be causal, not ceremonial. A server log can prove what the server sent. A client log can prove what it accepted. Address-use or traffic observation can prove what ran. Each party supplies the fact it can actually know.

What the protocol does not decide

The common specification decides wire validity, opt-in signalling, authentication fields, replay handling, permitted trigger types and interoperable exchanges. Local actors retain the rest.

The relay decides which access event deserves a request and which clients it believes affected. The server decides whether to trust that relay, whether state is sufficient, which clients to trigger and how to budget load. The client decides whether it implements and negotiated the mechanism, validates the message and applies the next Reply according to its code. The operator decides rollout windows, application safeguards, evidence retention and rollback.

This is Localized Future Decision in working form. No central actor needs power over every future provisioning choice. The shared mechanism stays small; deployment authority remains with those running and observing the components.

Voluntary Adoption also remains visible. A client that omits Reconfigure Accept is not a defective DHCPv6 citizen. It remains interoperable through ordinary lifetimes and client-initiated exchanges. A small device that omits the feature has not violated the protocol. The cost is slower response to some changes, which the operator must manage honestly.

The standard should describe the trigger. Running systems decide whether it became reality.

Sources