Summary

  • RFC 9928 allows a DHCPv4-over-DHCPv6 Relay Agent to encapsulate and decapsulate for an IPv4-only client that is unaware of DHCP 4o6.
  • Moving that function into an intermediate node can hide the Layer-2 attachment from DHCPv6 topology discovery. The RFC recommends a back-to-back 4o6RA and LDRA, but leaves their internal interface-information exchange out of scope.
  • A successful lease proves that an allocation and return path completed. It does not, alone, prove which access port was observed, which opaque Interface-ID represented it, which server rule consumed it or whether a direct DHCPv4 path bypassed the relay.
  • A relay-custody receipt should join ingress observation, encapsulation, LDRA Interface-ID, nested relay order, allocation rule, returned configuration, delivery, bypass detection and expiry or correction.

The address works, but the port is missing

Consider an IPv4-only radio unit attached through a Layer-2 fronthaul switch. It broadcasts an ordinary DHCPv4 request and receives an address, default route and other configuration. The transaction is green. The device can send traffic. Yet the address pool or configuration may have been selected using topology evidence that no longer reaches the DHCPv6 server.

The problem begins with a useful act of compatibility. RFC 7341 defines DHCPv4 over DHCPv6, or DHCP 4o6. In its original architecture, a capable client places the DHCPv4 message inside DHCPv6 and participates directly in the IPv6 transport. A legacy IPv4-only device cannot do that.

RFC 9928, published on the IETF Standards Track in March 2026, moves the function into a relay. The 4o6RA receives the client's DHCPv4 message, creates the DHCPV4-QUERY, encapsulates the request and sends it toward a DHCP 4o6-capable server. On the return path it checks DHCPV4-RESPONSE, extracts a valid DHCPv4 message and forwards it to the requesting client.

The legacy client sees the familiar exchange. It is explicitly unaware that a different protocol carried its request across part of the network. That is the feature: old equipment gains access to a newer service without a software change. It also means the client cannot testify that the encapsulation occurred, that the intended relay path was used or that the relay's topology statement described its real attachment.

A relay path is part of the allocation input

DHCP is often presented as an address-distribution protocol. Operationally, the server may need to answer a narrower question: which configuration belongs at this point in the network? RFC 7969 explains that a relay knows where the original request arrived and can supply information that helps a server choose the appropriate address pool and parameters.

The topology grammars differ. In DHCPv4, only the first relay should set giaddr, so a multi-relay path transports only part of the topology. DHCPv6 can preserve a nested sequence. Relays contribute link-address and, where needed, Interface-ID; successive Relay-forward envelopes expose the path toward the server. The return path reverses those envelopes.

This distinction matters when the 4o6 function moves away from the client. RFC 9928 states that placing DHCP 4o6 at the edge of the IPv6 network hides the Layer-2 network from the DHCPv6 relay. A 4o6RA-only solution supplies no interface information inside the encapsulated message. The DHCP exchange can still be well formed and complete while the input needed by a topology-dependent server is absent.

The result need not be an obvious failure. A broad fallback pool may return a usable address. A default configuration may permit partial service. The visible lease proves that the server made a decision and the response came back. It does not prove that the decision used the intended physical attachment.

The LDRA restores a custody link, not a universal name

RFC 9928 recommends combining the 4o6RA with a Lightweight DHCPv6 Relay Agent in a back-to-back structure. The LDRA obtains information about the client-facing interface and adds an Interface-ID to the outgoing DHCPV4-QUERY. This lets the DHCPv6 relay path carry the missing Layer-2 observation.

RFC 6221 gives the value a disciplined meaning. An LDRA must include Interface-ID in every Relay-forward. The value identifies the interface on which the client message was received. It should remain stable for that interface across restart, and the server may use it in parameter-assignment policy.

But Interface-ID is opaque. The server should compare it exactly, not parse it as a portable description. An octet string that means “port 7 on access node A under mapping generation 42” in one system does not announce those semantics on the wire. The operational evidence therefore needs both sides: the opaque value that crossed the protocol boundary and the local mapping that explains which observed attachment produced it.

RFC 9915 requires the server to echo Interface-ID in Relay-reply. The relay uses it to choose the client-facing interface. Custody therefore runs in both directions: observation becomes an opaque token, the token sits at a particular nested relay layer, server policy may consume it, and the echoed value guides final delivery.

The unresolved seam is deliberately local

The standards describe the interoperable messages, but RFC 9928 leaves a crucial seam to implementation. The internal mechanism by which the 4o6RA gives interface information to the LDRA is out of scope. So are its format and the question of whether the information says that 4o6RA was involved.

That is not a protocol omission to be filled with invented wire fields. It is a deployment responsibility. A single device may implement both functions in one process. Another may join switch silicon, an agent and a control-plane service. Both can conform while producing very different evidence about the internal handoff.

The receipt must therefore identify the implementation boundary and mapping generation rather than pretending the RFC standardizes them. It should record what the 4o6RA observed, what it handed to the LDRA, what opaque value the LDRA emitted and how the deployment would detect a missing or stale mapping.

RFC 9928 also preserves a simple case: if the same node hosts the 4o6RA and the DHCP 4o6 server, 4o6RA alone may be enough. “Use an LDRA everywhere” would be a broader claim than the standard. The governing question is whether the server receives the topology evidence required by its allocation policy, not whether every diagram contains the same box count.

Bypass can produce a second truth

The legacy client is unaware of the mechanism, so the network must steer both broadcast and unicast DHCPv4 traffic through the 4o6RA. RFC 9928 notes that an improperly configured Layer-2 network can let the client reach a DHCPv4 server directly. The RFC treats the resulting erroneous client and server state, and possible reachability impact, as a deployment error rather than a new security concern.

For operations, the classification does not make the path harmless. The intended 4o6 exchange and the direct DHCPv4 exchange can each yield locally plausible records. One server sees the topology-bearing relay path; another sees an ordinary DHCPv4 request. The client has no protocol-level way to explain which control plane won.

A relay-custody record therefore needs negative evidence as well as positive evidence. It should show that broadcasts were intercepted, that unicast renewal traffic remained on the intended path and that a direct-server path was absent or blocked. A lease observed only at the client cannot supply that proof.

A ten-part relay-custody receipt

The proposed receipt is an editorial operating control, not an RFC 9928 message or an IETF compliance certificate.

First, preserve the observed DHCPv4 request: bounded transaction evidence, client-link observation, time and the ingress device. Second, record the physical or client-facing interface and the local mapping generation that existed at observation time. Third, name the 4o6RA, its selected upstream interface and the encapsulation event.

Fourth, capture the internal 4o6RA-to-LDRA handoff, including implementation version and whether 4o6 involvement is marked locally. Fifth, retain the LDRA's opaque Interface-ID, its stability generation and the nested Relay-forward layer where it appeared. Sixth, retain further link-address, Interface-ID and hop ordering that the allocation policy actually used.

Seventh, record the server, exact topology rule, selected address pool and returned parameters. Eighth, join the nested Relay-reply, decapsulation and delivery back to the original client-facing interface. Ninth, retain the bypass test and its result. Tenth, close the record with renewal, port move, correction, expiry or rollback, plus the point at which evidence may safely expire.

No single field proves the whole chain. A server log cannot prove physical ingress. A switch log cannot prove the allocation rule. An echoed Interface-ID cannot explain a stale local mapping. A client lease cannot prove the relay order. The receipt is useful because it keeps those claims separate and joinable.

The governance boundary is equally important. IETF defines interoperable behavior. The access operator chooses the interface mapping; the relay operator controls encapsulation and steering; the DHCP service owner controls allocation policy; the equipment owner controls the legacy device. The unaware client should not be made the fictional principal for decisions it cannot see.

Sources