Summary

  • RFC 3736 let a node that already had an IPv6 address request other configuration through a two-message DHCPv6 Information-request/Reply exchange, without asking the server to assign an address.
  • “Stateless” meant the server need not keep dynamic per-client state for this service; optional client identification, local policy and unchanged relay behavior still mattered.

An address and a resolver are different jobs

IPv6’s stateless address autoconfiguration can give a host an address from router advertisements. That does not by itself answer every configuration question a host has. It may still need recursive DNS server addresses, SIP server information or other options. Before RFC 3736, it was easy to think of DHCP as a single bundle: ask a server for an address and receive the rest of the network configuration at the same time.

RFC 3736 separated those functions. Its client already has an address by another means—typically stateless address autoconfiguration, or manual configuration—and has at least a link-local address from which to communicate. It sends an Information-request naming desired option types in an Option Request option. The server responds with Reply carrying the configuration parameters it has selected. There is no request for an address identity association and no address assignment in this mode.

The exchange was deliberately small: Information-request, then Reply. A host could ask for DNS configuration without turning that exchange into an address lease. The same server system could serve clients asking for addresses and clients asking only for other parameters; relay agents worked as they did for stateful DHCP.

But “stateless” did not mean a server without configuration or policy. RFC 3736 says the server need not maintain dynamic state about individual clients. It also permits a Client Identifier in the request when an administrator wants to tailor a reply to a node. The server can still choose options under its configuration policy. A relay may still forward the exchange. The narrow point is that the information-only service need not create or track an address binding for each client.

That distinction matters when reading IPv6 Router Advertisement flags. RFC 4861’s Managed flag says addresses are available through DHCPv6; its Other-configuration flag signals that other DHCPv6 information is available. When the Managed flag is set, the Other flag is redundant. These are availability signals, not evidence that a host completed a DHCP exchange, installed a DNS server, or can reach it.

Removing an address lease also removed its clock

Address assignments have lifetimes that tell a client when an address is preferred, valid, or no longer usable. Other configuration information may not have such a lifetime. RFC 3736 explicitly left open when a host should send another Information-request to refresh those values—and gave no rule for refresh after moving to a new link.

RFC 4242 later supplied an Information Refresh Time option: an upper bound on how long a client should wait before requesting updated DHCPv6 information. Its rationale is revealing. With no address or prefix lease in the exchange, there may be no lifetime to tell the client when to return. RFC 8415 later consolidated DHCPv6, obsoleting RFC 3736 and RFC 4242 while retaining the two-message information-only operation.

The history is therefore not “DHCP disappeared once SLAAC made an address.” It is that address formation and the rest of host configuration were separable. Separating them reduced what the information-only server had to track, but configuration still needed source precedence, refresh, interface scope and resolver-installation behavior in the host. A Reply proves the protocol exchange returned options; by itself it does not prove the host installed them or that a DNS query succeeded.

No RFC in this record establishes how often current clients use this mode or how any named network configures it. The standards specify the mechanism and its boundaries, not deployment prevalence or service outcome.

Sources