Summary

  • RFC 5107 lets a DHCP relay choose the IPv4 address that a supporting server places in option 54. The address steers later renewals back through the relay; it does not authenticate or physically locate the DHCP server.
  • A defensible renewal record separates override selection, relay evidence, server receipt, lease decision, client configuration and observed traffic. Equality between option 54 and suboption 11 is only one transition receipt.

The monitoring console has a field called server_identifier. Its value is the address of a relay. An analyst opens an incident and concludes that the relay granted the lease. The conclusion feels natural because the field name sounds ontological: it appears to answer which server made the decision. Under RFC 5107, however, the field may answer a narrower routing question—where should the client send its next RENEW DHCPREQUEST so that the relay can see it?

Ordinary DHCPv4 creates an awkward discontinuity for networks that depend on Relay Agent Information. A relay can add option 82 and suboptions such as Circuit-ID or Remote-ID to the initial DHCPDISCOVER. Once the lease exists, a client in RENEWING state normally unicasts its DHCPREQUEST directly to the address in the Server Identifier option. Depending on topology, that packet can bypass the relay. The server then loses the attachment evidence that shaped the original decision.

RFC 5107 inserts a controlled indirection. The relay adds Server Identifier Override suboption 11 to Relay Agent Information. Its payload is four octets: an IPv4 address selected by the relay. A supporting DHCP server must copy that address into option 54 of the corresponding reply. The client later directs renewal traffic toward that address, allowing the relay to receive the request, add current relay information and forward the packet to the actual server.

The protocol therefore makes a fact that operations systems often hide explicit: a field named Server Identifier can carry an address that is not configured on the DHCP server. It is an intentional delivery handle. The server remains the lease-decision authority; the relay remains an intermediary; option 54 points the client into the path that joins them.

The server must remember the overriding address for subsequent messages from that client until it receives another message through the relay. That requirement creates state with a lifetime and a generation. A trace should record which relay supplied the value, when the server learned it, which lease or client key it was attached to and which later message refreshed it. A database row containing only the current option-54 value cannot show how the value was obtained.

Servers that do not implement the suboption ignore it and place an appropriate local interface address in option 54. The initial exchange may still succeed. The incompatibility becomes visible later: RENEW traffic goes directly to the server, the relay does not see it, and the expected Circuit-ID or Remote-ID is absent. “Lease granted” is therefore not evidence that the relay-preserving renewal path was negotiated.

This is a compatibility boundary, not merely an option-parsing detail. Before enabling the feature, the relay operator must know whether every target server understands it. In a mixed pool, one server may return the override while another returns itself. Fleet-wide success rates can conceal the branch unless telemetry records support by server instance and the option 54 actually emitted.

A DHCP server normally checks that the Server Identifier in a DHCPREQUEST matches one of its own interface addresses. RFC 5107 changes that comparison when suboption 11 is present. The server compares option 54 with the override carried by the relay. If the two values match, it should process the request even though the address is not local to the server.

That equality has a precise meaning. It proves that two fields in the received transaction agree. It does not prove who created either field, that the relay is trusted, that the client received an authentic earlier reply or that the server owns the address. Treating option54 == override as server authentication converts a consistency check into an identity claim.

The relay should continue to set giaddr as it normally would. The override does not replace the relay address used for allocation context. Nor does it collapse Circuit-ID, Remote-ID, Device Class and other relay suboptions into one address. Each value has a different scope: client return path, relay hop, access attachment, device classification or policy input.

If a relay forwards requests to several DHCP servers, RFC 5107 recommends sending all DHCP messages—including RENEW requests—to all of them. The purpose is to avoid turning the relay into a shadow lease database. It should not have to decide which server owns the lease based on stale local state. The servers receive the evidence and apply their own lease state.

That design produces another useful boundary. “Relay received renewal” does not prove “authoritative server received renewal.” “Server received renewal” does not prove “lease extended.” A multi-server fan-out needs per-destination send receipts, per-server receive receipts and one explicit lease decision. Silence from non-owning servers is not equivalent to packet loss, and a response from one server does not prove the others were contacted.

RFC 5010 adds a companion Relay Agent Flags suboption that can tell a server whether the client message originally arrived as broadcast or unicast. RFC 5107 recommends using it with the override. Without that bit of provenance, the server sees a packet forwarded by the relay but may not know the client's original delivery mode. Reconstructing that fact from the server-facing transport is unsafe because the relay has already transformed the path.

The availability of the relay becomes part of lease continuity. If the client cannot reach the overriding address, or the relay cannot reach the server, later renewals may fail and the lease may time out. The option value may remain perfectly consistent throughout the failure. A valid Server Identifier is not a reachability probe, and a successful ARP or route lookup to the relay is not a receipt for the server-facing leg.

Operational evidence should follow the transaction as a chain. First record the client's message at a named relay ingress. Then record the selected override address, giaddr, original broadcast/unicast flag and a digest of the attached relay suboptions. On the server side, record receipt, override generation, option-54 value emitted and lease decision. On renewal, link client send, relay receipt, relay reconstruction, per-server forwarding, authoritative response, client receipt, configuration apply and first usable traffic.

Generation matters because remembered override state can be lost or replaced. A server restart may preserve the lease while losing the auxiliary return-path address. A client can retain option 54 from the prior ACK. The next renewal then presents a value the server no longer associates with the lease. Calling this “unknown server” hides the actual failure: the lease and the indirection state have diverged.

A robust event model includes an override-generation identifier and a reason for replacement or expiry. It should distinguish server_ignored_suboption, override_state_lost, option54_override_mismatch, relay_unreachable, server_path_unreachable and ack_not_received. A generic DHCP renewal failed counter cannot tell an operator whether the defect lies in feature support, stored state, the client-to-relay leg or the relay-to-server leg.

The security consequences follow directly from the indirection. Relay Agent Information relies on a trusted relationship between relay and server. A rogue relay can supply an address that redirects future renewals to itself. It can later deny those renewals, alter DHCPACK options or attempt to make a client believe a lease lasts longer than the server allowed.

RFC 5107 does not claim that suboption 11 prevents those attacks. It explicitly says the suboption alone is not intended to provide added security. DHCP message authentication and Relay Agent Information authentication are the relevant controls, alongside topology defenses that prevent untrusted devices from inserting relay information.

Authentication must also be recorded at the right hop. A server may authenticate the relay option while the client has no cryptographic proof of the server. A client may validate a DHCP message under a separate DHCP authentication arrangement while operations still need to know which relay supplied the override. One “authenticated DHCP” boolean cannot preserve these principals and protected fields.

The name Server Identifier is thus a dangerous database column without provenance. A more accurate projection exposes client_return_address, override_supplied_by_relay, actual_server_instance, relay_evidence_digest, lease_authority and authentication_receipt separately. The wire field remains option 54; the observability model refuses to inherit an ambiguity from its label.

This distinction is especially important during migrations. A load balancer, anycast address or new relay topology may preserve the same return address while changing the actual server set. Conversely, a relay address can change while the lease authority and client configuration remain intact. Identity, addressability and authority must be versioned independently if a platform is to explain either change.

The final boundary lies beyond DHCP. A DHCPACK can carry an address, mask, router and lifetime. Receipt of the ACK does not prove that the client applied them. Application does not prove that local routing, first-hop policy, upstream reachability, DNS or an application service works. The useful executive metric is not “override succeeded” but the conversion rate across each receipt: return-path selected, renewal relayed, lease decided, ACK received, configuration applied and traffic observed.

RFC 5107 is small because the mechanism is narrow. Its management consequence is large because it overturns an easy assumption: the address called a server identifier can intentionally identify an intermediary path. Good telemetry preserves that indirection rather than flattening it into a fictional server identity.

Sources