Summary

  • Option 108 lets an IPv6-only-capable client ask to skip an IPv4 address; the DHCP server answers only on a configured IPv6-mostly pool.
  • The draft sets no universal capability test. Operators own the device policy, the opt-out path and the failures IPv4 used to hide.

A DHCP server cannot inspect a laptop’s application inventory and certify that the user’s day will survive without IPv4. Option 108 does not try. It gives a capable client a way to say it is willing to forgo an IPv4 address, then leaves the network operator to decide where that signal should be honored.

That is the practical hinge in version 12 of the IETF’s IPv6-mostly draft, updated on 29 October and now in IESG Last Call through 12 November. The proposed network puts IPv4 and IPv6-only devices on the same segment. A client that requests Option 108 and receives it in a DHCPOFFER should not request the offered IPv4 address. A client that does not speak the option can still receive one from a pool configured for IPv6-mostly use.

The option is a signal, not a compatibility test. The draft says “IPv6-only-capable” has no strict technical definition. It describes a device that can work without native IPv4 and give the user the same experience. That might mean its applications use IPv6 and reach only IPv6 destinations; they may use NAT64 for IPv4-only destinations; or the device may run CLAT, the customer-side translator defined in RFC 6877, for older IPv4 applications. In RFC 8925, declaring an interface capable is a policy decision. Draft -12 repeats the consequence: the network does not discover readiness by watching a DHCP exchange. Someone has to decide which devices, interfaces or user groups may make that claim.

The server side is deliberately narrow. RFC 8925 says the server sends Option 108 only when the client asked for the option and the selected pool is explicitly configured as IPv6-mostly. The option’s four-byte value tells the client how many seconds to disable DHCPv4. A configured V6ONLY_WAIT timer goes in the response; absent one, the server sends zero. So the pool setting, not an optimistic client label, controls where the address disappears.

IPv4-only destinations still need a path. The draft relies on NAT64 with the prefix signaled through Router Advertisements under RFC 8781, DNS64 under RFC 6147, or both. A client that lacks application-level IPv6 support may need CLAT. If the endpoint, DNS path, translator or network attachment is wrong, the client has lost the dual-stack fallback that used to conceal the break.

That is why the rollout advice matters more than the option number. Draft -12 recommends an opt-in proof of concept, then an opt-out phase as the operator enables PREF64 signaling and Option 108. It even proposes that users may have to report a problem to opt out. That creates a useful fault signal—and makes the affected person the first-line test harness. The draft also calls ACL-based IPv4 blocking a stopgap because operators must keep device-specific intent current, especially when endpoints move.

The draft supplies no deployment count or observed failure data, so it cannot establish address savings or user experience. Its argument is architectural: a shared network can stop handing out IPv4 to clients that are prepared to live without it, while preserving IPv4 for clients that still need it. The unresolved operating question is how an operator proves that “prepared” before the help desk starts learning the answer one broken application at a time.

Sources · RFC 8925 · RFC 6877 · RFC 8781 · RFC 6147