Summary

  • RFC 3315 let a DHCPv6 client ask to replace the usual Solicit–Advertise–Request–Reply sequence with Solicit–Reply, but a server could honor that request only under its own configuration and policy.
  • Because a Rapid Commit server committed the assignment before sending its Reply, more than one server—or a reply that never reached the client—could leave an allocation recorded but not used. Fewer messages changed the timing and risk of commitment, not merely latency.

The familiar four-message exchange contains a small but consequential pause. A client sends Solicit; available servers answer with Advertise; the client chooses one and sends Request; that server confirms in Reply. The interval between discovery and confirmation lets the client select among offers before the final assignment. RFC 3315, published as a Standards Track specification in July 2003, made a shorter route possible—but did not make it the default.

For the two-message route, a client placed the zero-length Rapid Commit option in Solicit. That option was an invitation: the client was prepared to receive an immediate Reply. It was not an instruction to every server. A server still checked its administrative policy and whether it was configured to commit assignments on this path. If not, it could ignore the option and continue with Advertise, leaving the client able to use the ordinary selection exchange. When a server did accept, it committed the address and other requested resources before transmitting Reply.

That order created the bargain. A client receiving a valid Rapid Commit Reply could use the configuration without sending Request. But the server did not receive a later confirmation that the client had actually received that Reply. The specification therefore called out a case that a packet-count explanation can miss: if several servers answer one Rapid Commit Solicit, each can commit an assignment, while the client uses leases from only one. The others may remain committed without being used. A Reply lost in transit creates a related gap between server-side commitment and what the client can act on.

The normal four-message path and the fast path thus distribute uncertainty differently. With Advertise and Request, the client makes a visible selection before the chosen server creates its final assignment. With Rapid Commit, the server advances the commitment point; that can remove a round trip, but it also means more than one responder may spend address-pool capacity before learning which answer, if any, the client received and used. This is not evidence that address collisions occurred, nor that every additional reservation is harmful. It is a protocol-defined possibility that matters to how a service is arranged.

RFC 3315 says deployments using Solicit–Reply would typically arrange for only one server to answer, and suggests relatively short lifetimes as another way to reduce unused assignments. Those are design mitigations, not guarantees of a single-server topology or shared state. The fast path is most legible when the service deliberately controls responder selection; where several servers can independently answer, the operator has to account for the possibility that each commits.

Two years later, RFC 4039 brought a Rapid Commit option to DHCPv4. Its rationale names environments with frequent movement between network attachment points, where configuring clients quickly can matter. It also explains the four-message exchange’s redundancy benefit: offers can remain provisional while a client chooses, instead of multiple servers making final allocations. This is a useful comparison, not proof that RFC 4039 caused broad deployment or that mobile clients universally used the option.

Later DHCPv6 specifications retained this distinction. RFC 8415 consolidated the protocol in 2018; RFC 9915, published in 2026, now replaces it and still describes Rapid Commit as a client-requested exchange that a server may decline. The lasting lesson is not that speed is unsafe. It is that a shorter exchange shifts a decision boundary: when does the server commit, which responders may commit, and what evidence tells each side the client actually obtained and used the resource? A message saved is also a confirmation step removed.

Sources: RFC 3315, RFC 4039, RFC 8415, and RFC 9915.