Summary

  • RFC 9928 moves DHCPv4-over-DHCPv6 encapsulation from an unchangeable IPv4 client into a 4o6 Relay Agent, preserving a path to IPv4 configuration without requiring a client upgrade.
  • The substitution also moves the observation point. A valid DHCP exchange does not prove that Layer 2 interface provenance reached the server, that topology-dependent policy selected the intended configuration, or that the client became reachable.

The migration dashboard looked persuasive. A legacy endpoint had sent a DHCPv4 request. A DHCPV4-QUERY had crossed the IPv6 network. A syntactically valid response had returned through the relay. Someone summarized the sequence as “the client was provisioned correctly.”

That conclusion contained more certainty than the record.

The exchange could establish that a relay carried a request and accepted a response. It might also establish what address and options the server returned. It did not necessarily establish which physical or logical access interface originated the request, which topology record the server used, whether every possible DHCP path was forced through the same relay, whether the client accepted the state without conflict, or whether packets later crossed the configured path. The missing fact was not another protocol field. It was provenance across a substituted observation point.

RFC 9928 addresses a practical transition constraint. RFC 7341 carries DHCPv4 messages over DHCPv6 so that IPv4 configuration can be obtained across an IPv6-only network. In its original architecture, the client implements DHCP 4o6. That is impossible for some embedded or long-lived IPv4-only hosts that cannot be replaced or updated. RFC 9928 therefore moves encapsulation and decapsulation into an intermediate switch or router called a DHCPv4-over-DHCPv6 Relay Agent, or 4o6RA.

The client remains an ordinary DHCPv4 client. It does not know the relay is translating the transport. For RFC 7341 purposes, however, the 4o6RA assumes the client role. It selects the interface on which it will behave as a DHCPv6 client, locates a suitable server or relay, obtains the required IPv6 configuration and requests the DHCP 4o6 Server Address option. It then wraps the legacy request in DHCPV4-QUERY and unwraps the returned DHCPV4-RESPONSE.

This is deliberately modest protocol design. RFC 9928 adds no new message format and imposes no additional requirements on a compliant DHCP 4o6 server. A response without the DHCPv4 message option, or one that is malformed, must be discarded. A correct inner response is extracted and sent toward the requesting client only if it can actually be forwarded. These are precise, testable obligations. They make the transport interoperable without pretending to solve the entire configuration decision.

The difficult part begins where the relay stands.

DHCP configuration can depend on network topology. A server may choose addresses or other parameters using evidence about the link and interface through which a request arrived. RFC 7969 explains that IPv4 and IPv6 expose this path differently. In DHCPv4, the first relay normally sets giaddr; in a chain of relays, that can represent only part of the topology. In DHCPv6, relays can contribute link-address and Interface-ID information so that the server receives a sequence describing the path.

When the client itself performs DHCP 4o6, the DHCPv6 relay can see the interface on which the encapsulated request arrived. When 4o6 processing moves to an intermediate node at the edge of the IPv6 network, that node becomes the apparent DHCPv6 client. RFC 9928 states the consequence plainly: a 4o6RA-only design hides the Layer 2 network and breaks topology propagation because the encapsulated message provides no interface information for the hidden segment.

The standard proposes a repair, not a fiction. It recommends combining the 4o6RA with a Lightweight DHCPv6 Relay Agent from RFC 6221. Placed back to back, the LDRA can supply Interface-ID information to the outgoing query. But the internal mechanism that passes interface information between the two functions, its format, and even whether it marks 4o6RA involvement are outside RFC 9928's scope.

That boundary is the management issue. The common standard can specify what interoperable messages carry. It cannot certify the internal wiring, data lineage or operational policy of every device that implements both roles. Heng Lu's Minimum Initial Specification principle gives the right interpretation: keep the shared mechanism small enough to validate, then leave local implementation and adoption decisions with the operators who bear the consequences. The absence of a centralized answer is not a defect to be covered by a green status. It is a responsibility boundary to be documented.

The deployment has a second obligation. Because the legacy client is unaware of 4o6RA, all of its DHCPv4 broadcast and unicast messages must be steered through that relay. RFC 9928 mentions central placement or NAT for unicast traffic. If a conventional DHCPv4 server remains directly reachable in the same Layer 2 scope, messages can bypass 4o6RA. The result can be inconsistent state at the client and servers and a misconfiguration that affects reachability. The RFC classifies this as a deployment error rather than a new security property. That classification does not reduce its operational cost.

A defensible evidence bundle therefore needs more than a final DHCP response. It should preserve the client transaction identifier and request hash; the ingress port, VLAN or equivalent access-interface fact; the 4o6RA's selected DHCPv6 interface and server-address discovery; the query and response hashes; the ordered relay path, link-address and Interface-ID values; the server's policy input and chosen configuration; the relay's well-formedness and forwarding decision; the client's accepted lease and option state; any address-conflict observation; and a later route, reachability or service test. Each item answers a different question.

This separation protects both operations and accountability. The access owner can attest where the client appeared. The relay owner can attest what was encapsulated, discarded or forwarded. The DHCP service owner can attest which policy and topology evidence produced the offer. The endpoint owner can attest what state was installed. The service owner can attest what actually worked. If one person is nominally responsible for all five, the records still should not be collapsed, because faults and rollback occur at different layers.

Running-Code Primacy is useful here precisely because the code is doing real work. The relay's successful query is evidence of a relay transaction. The server's response is evidence of a server decision. The client's bound state is evidence of local configuration. A packet or service probe is evidence of an observed path or outcome. None becomes weaker when described accurately. They become misleading only when one is promoted into authority over all the others.

The right executive question is not “did DHCP succeed?” It is: which system observed which fact, which topology survived the substitution, who approved the policy that used it, and what independent observation closed the loop?

Sources