Summary

  • RFC 8925 defines DHCPv4 option 108, “IPv6-Only Preferred”. A capable client requests the option; a server returns it only from a configured IPv6-mostly pool; the client then forgoes the offered IPv4 address and pauses DHCPv4 for a bounded time or until a new network attachment.
  • The minimum wait is 300 seconds, while the RFC default is 1800. That clock is a rollback device, not a declaration that IPv4 has been permanently removed. A useful operational receipt must separately prove the request, the server scope, the offer, the client state, NAT64/PREF64/CLAT readiness and real application outcomes.

The offer that is meant to be refused

A normal DHCPOFFER is an invitation: here is an address, ask for it. Option 108 makes possible a stranger exchange. The client first places the option code in its Parameter Request List. It is saying that, on this interface, an IPv4 address is optional if the network can sustain IPv6-only operation. A server whose selected pool is explicitly configured as IPv6-mostly returns the option with a timer. The client should not request the address in the offer.

RFC 8925 even says that the server should place 0.0.0.0 in the offered-address field. If infrastructure cannot do that, the server may offer a real available address, but should not reserve it because the client is not expected to take it. The message travels through DHCPv4, yet its intended result is no IPv4 lease.

That inversion is useful because it preserves compatibility without asking an admission system to classify every device in advance. A device that does not request option 108 follows ordinary DHCPv4 and receives IPv4. A capable client can decline. IPv4-only, dual-stack and IPv6-only-capable endpoints can therefore remain on the same link instead of being divided among separate SSIDs or VLANs.

The mechanism is small. It does not declare which operating system is modern, which application deserves accommodation or when an institution believes the transition should finish. It coordinates one local choice between one client interface and one configured server pool. That narrowness is the source of its power—and the limit of what its packets can prove.

Five minutes is a circuit breaker

The server supplies a 32-bit V6ONLY_WAIT value. If it is below the protocol minimum, the client uses MIN_V6ONLY_WAIT: 300 seconds. The RFC’s default waiting time is 1800 seconds, not five minutes. But the minimum is operationally important because the March 2026 6MOPS Internet-Draft recommends beginning with 300 seconds when rapid rollback matters, then lengthening the interval only after the network proves reliable and DHCP load has been measured.

For the duration, the client should stop DHCPv4 configuration and may disable the IPv4 stack on the affected interface. The state ends when the timer expires or a network attachment event occurs, whichever comes first. Moving to another Wi-Fi network, reconnecting or another qualifying link event reopens the decision.

This is not a ceremonial timeout. It keeps the last-resort path close enough to recover. If IPv6-only operation exposes a hidden application dependency, an operator can stop sending option 108 and let clients return to ordinary DHCPv4 after their timers or attachment events. A 300-second starting value reduces the time between a bad decision and a fresh opportunity to obtain IPv4.

There is a cost. A large population that retries DHCPv4 every five minutes can load the DHCP infrastructure. The draft therefore treats the timer as a quantity to measure, not a moral preference for shorter or longer waits. Fast reversibility and quiet infrastructure pull in opposite directions. The correct value follows observed client count, failure rate and server capacity.

Six states, not one “IPv4 off” flag

An operator who records only that option 108 was enabled loses most of the evidence. At least six states have to remain distinct.

First is interface policy. RFC 8925 makes IPv6-only capability interface-specific. A device may have CLAT available on one interface and not another; an enterprise may declare only tested managed devices capable. The declaration is a policy decision, not a remote measurement of every installed application.

Second is the request. Did the DHCPDISCOVER or DHCPREQUEST actually contain code 108 in its Parameter Request List? A server must not treat an unrequested option as consent. The client never sends the four-byte timer itself; it asks by code.

Third is server scope. Was the selected pool explicitly configured as IPv6-mostly? The server must not return the option from an ordinary pool. A global “feature enabled” label cannot substitute for the configuration of the pool that answered this client.

Fourth is the offer. Did it contain a valid four-byte option, and what waiting value did it carry? Was 0.0.0.0 offered, or a real but unreserved address? Packet evidence can answer this without guessing from lease counts.

Fifth is client state. Did the client honor the option, decline the address and stop DHCPv4? Some implementations may behave differently around renewal, INIT-REBOOT or interface events. A server transmission is not proof of the state reached on the endpoint.

Sixth is service outcome. Could the endpoint discover the NAT64 prefix, use DNS64 or local synthesis where needed, activate CLAT for IPv4-only applications, and complete the actual tasks its user required? The absence of an IPv4 lease is not evidence that any of those paths worked.

Compressing these six rows into “IPv4 disabled” converts a testable mechanism into a slogan. Keeping them separate turns it into an operational receipt.

Translation is part of the dependency, not a footnote

RFC 8925 assumes that IPv6-only-capable hosts can reach IPv4-only destinations through NAT64. It does not negotiate a translation technology. It cannot tell a client which NAT64 prefix the network uses, prove that a translator is reachable or make an IPv4-only application use an IPv6 socket.

That is why Linkova’s related standards work matters. RFC 8781 defines a Router Advertisement option for communicating PREF64, the NAT64 prefix, to a host. RFC 9872, published as an Informational RFC in 2025, recommends this RA-based method for new deployments and retains DNS-based discovery when the RA option is unavailable or unsupported. Until a host obtains PREF64, RFC 9872 warns, IPv4-only applications and communication with IPv4-only destinations can be impaired.

464XLAT supplies another bridge. A client-side translator can present an IPv4 interface to legacy software while carrying the traffic over IPv6 toward a provider-side translator. But RFC 6877 is explicit that 464XLAT is limited IPv4 connectivity, not a one-for-one replacement for full IPv4. It does not recreate inbound IPv4 or every peer-to-peer pattern.

These boundaries matter in incident review. A client may correctly request and honor option 108 while an RA omits PREF64. PREF64 may be correct while NAT64 routing is broken. NAT64 may work while a VPN drops IPv6 extension headers. A browser may succeed through native IPv6 while an old application containing IPv4 literals fails because CLAT never activated. The option has done exactly what it promised in every one of these cases; the system around it has not.

Dual stack was hiding evidence

Dual stack is forgiving because Happy Eyeballs and similar selection behavior can route around defects. That is valuable for users, but it can make a broken IPv6 path look healthy. Remove the IPv4 address and the previously invisible failure becomes the only path available.

The current 6MOPS draft recommends staging the exposure. Signal PREF64 first. Activate option 108 on the DHCPv4 server next. Where endpoint control exists, enable the client behavior on managed devices and preserve per-device rollback. It warns that some operating systems have option 108 enabled by default and will become IPv6-only as soon as the server starts sending the option, making a supposedly small server change a subnet-wide event.

The draft is operational guidance under active IETF work, not a finished RFC. That status should make its sequencing more, not less, useful as a monitorable hypothesis. Operators can record whether the staged order reduced failures, whether the 300-second window was adequate, and which dependencies emerged. Results can improve later text; the text cannot manufacture successful deployment by publication alone.

Linkova’s IETF 118 presentation offers one deployment record. It described pilots in Google offices, expansion across locations and staged percentages, and reported reductions in DHCP use and projected address recovery. Those are attributed presentation figures from one environment, not universal benchmarks. Their durable lesson is methodological: turn on a bounded cohort, observe, enlarge the cohort and keep a path back.

A demand signal, with conditions attached

Lease reduction is economically interesting. A device that declines IPv4 leaves an address available to another endpoint. On networks assigning public IPv4 directly, that can reduce public-address consumption. On RFC 1918 networks, it may relieve private-address pressure or avoid another layer of NAT. New segments can begin with smaller IPv4 pools; existing segments may need renumbering before reclaimed space becomes useful elsewhere.

But a declined lease is conditional demand evidence. It means this interface, running this software, under this declared policy, on this network with these translation facilities, did not take an IPv4 address during this interval. It does not mean the endpoint will never need IPv4. It does not establish that all applications succeeded. It does not show whether the same device would decline on an IPv6 network lacking NAT64. And it says nothing about the market value of an address that remains necessary for the clients that did not opt out.

This is where the five-minute clock protects analysis as well as connectivity. The system is not forced to announce that IPv4 demand has ended. It can observe a temporary choice, watch what breaks and ask again. Scarcity becomes measurable at the edge instead of argued in the abstract.

The most honest metric is therefore not “percentage IPv6”. It is a small set: devices requesting option 108, valid offers returned, addresses declined, clients that later retry, failures by application class, translation-path health, fallback frequency and the amount of address space actually made reusable. The ledger should preserve both the successful refusal and the return.

Jen Linkova’s documented role

RFC 8925 names Lorenzo Colitti, Jen Linkova, Michael C. Richardson and Tomek Mrugalski as authors. RFC 8781 names Colitti and Linkova. RFC 9872 and the current 6MOPS draft again place Linkova among several authors. That record establishes sustained participation in a connected body of IPv6 operational work; it does not make her the sole inventor of option 108 or the controller of any implementation or deployment.

The distinction is more than biographical caution. Standards acquire value when independent clients and networks implement them, test them and produce interoperable behavior. Authorship explains where a mechanism was specified. Running code reveals whether its promise survived contact with real systems.

Option 108 embodies that discipline unusually well. It does not require a central body to certify that a device no longer deserves IPv4. Client and server each expose a bounded local choice. Non-participating devices keep the old behavior. Incompatible states do not become moral violations; they produce a lease, a retry, a failure or a fallback that an operator can see.

The five-minute clock is therefore not the countdown to IPv4’s disappearance. It is the time until the network has to be willing to ask the question again.

Sources