In DHCPv6, which four messages does a client exchange with a server to obtain an address, and how does Rapid Commit shorten that to two?

## Why DHCPv6 has its own exchange **DHCPv6** (the Dynamic Host Configuration Protocol for IPv6) hands IPv6 hosts addresses, delegated prefixes and other settings such as DNS servers. Its current specification is **RFC 9915**, an Internet Standard published in January 2026 that obsoletes RFC 8415. DHCPv6 is not DHCPv4 with longer addresses: the message names, ports, identifiers and transport all differ. DHCPv4 binds a client with Discover, Offer, Request and Ack sent by broadcast. DHCPv6 binds with **Solicit, Advertise, Request and Reply**, sent to a link-scoped multicast group, because IPv6 has no broadcast. ## The four messages | Step | Message (type code) | Sent by | What it means | |---|---|---|---| | 1 | `SOLICIT` (1) | client | "Is any server able to serve me?" | | 2 | `ADVERTISE` (2) | each willing server | "I can, and this is what I would give you." | | 3 | `REQUEST` (3) | client | "You, specifically: commit it." | | 4 | `REPLY` (7) | the chosen server | the committed leases and options | Inside the Solicit the client states what it wants: - a **Client Identifier** option carrying its **DUID** (DHCP Unique Identifier), which is how DHCPv6 identifies a client instead of a hardware address; - an **IA_NA** option (identity association for non-temporary addresses) for each set of addresses it wants, or an **IA_PD** option for a delegated prefix; - an **Elapsed Time** option, and an **Option Request** option naming the settings it wants, such as DNS recursive servers. The Advertise is an offer, not a commitment. RFC 9915 §18.3.2 has the server create the binding when it receives the Request. The Reply then carries each address with its **preferred** and **valid lifetimes**, plus the **T1** and **T2** times at which the client will try to extend them. ## How the client reaches servers it does not know A client starts with no server address, so it sends every message to **`ff02::1:2`**, the link-scoped group `All_DHCP_Relay_Agents_and_Servers`, on UDP port **547**. It listens for answers on UDP port **546**. Every server and relay agent on the link joins that group. When the server sits on another subnet, a relay agent on the client's link forwards the message, and the client never notices the difference. Even the Request goes to the multicast group. The client names the server it chose by copying that server's DUID into a **Server Identifier** option. Every server on the link receives the Request, but only the named one answers (RFC 9915 §14). RFC 8415 let a server invite clients to unicast later messages with a Server Unicast option. RFC 9915 obsoletes that option and the UseMulticast status code, so a conformant client always multicasts. ## Choosing among several servers Several servers may answer one Solicit. The client does not grab the first Advertise. It collects them until its first retransmission timeout expires, a little over `SOL_TIMEOUT` (1 second), and then chooses: 1. The highest value in the **Preference** option wins; an Advertise without one counts as 0. 2. Among equal preferences, the client may pick the offer that best matches what it asked for. 3. An Advertise carrying preference **255** ends the wait at once, and the client sends its Request immediately. If no Advertise arrives in that first period, the client keeps retransmitting the Solicit with roughly doubling, randomised timeouts capped by `SOL_MAX_RT` (3600 seconds by default). It then acts on the first Advertise that arrives. ## Rapid Commit: two messages instead of four A client willing to skip server selection adds the **Rapid Commit** option (option code 14, no payload) to its Solicit. A server configured to honour it commits the leases straight away and answers with a **Reply** that also carries Rapid Commit, so the exchange is just Solicit and Reply. A server not configured for it sends an ordinary Advertise, and the client carries on with the four-message exchange. The client discards any Reply to its Solicit that lacks the Rapid Commit option. The cost explains why the RFC hedges it. Each server that answers a Rapid Commit Solicit commits leases without learning whether the client used them. With two such servers on a link, the client keeps one Reply. The other server's leases stay committed and unused, and if that server updates DNS, it leaves wrong records behind. RFC 9915 §21.14 advises designing the service so that only one server answers, or giving newly assigned leases short lifetimes. ## After the first exchange The same `REPLY` message answers every later client message, each in a two-message exchange: - **Renew** at T1, sent to the server that granted the lease; - **Rebind** at T2, sent to any server, if the Renew went unanswered; - **Release** when the client is finished with a lease; - **Decline** when duplicate address detection finds an assigned address already in use; - **Confirm** when the client may have moved to another link and holds only addresses.