Summary

  • RFC 3011 let a DHCP requester name an allocation subnet different from the network on which its packet reached the server, separating observed origin from requested resource location.
  • The server’s identical echo of option 118 was a narrow processing receipt, not proof of requester identity, pool entitlement, routability or successful use; the new discretion also widened the possible pool-exhaustion surface.

A DHCP server has to answer a question before it chooses an address: which pool should it use? In the ordinary design described by RFC 2131, topology supplied the answer. If a relay had filled giaddr, the server could use that field to locate the client’s subnet. If giaddr was zero, the receiving interface provided the clue. The packet’s path stood in for the client’s allocation context.

That shortcut was useful precisely because most requests and most leases belonged to the same visible network. But an access device could violate the assumption without violating the architecture. A remote-access server might speak to the DHCP server over a private internal subnet while allocating addresses to subscribers on one or more external networks. Those external networks might not even be IP-routable from the internal network. The request had to arrive from one place; the address had to come from another.

RFC 3011, published in November 2000, gave that mismatch a public field. Its IPv4 Subnet Selection Option carried one four-octet subnet address. The requester produced the value by taking an address on the intended subnet and masking its host bits to zero. IANA assigned the mechanism DHCP option 118, which the current BOOTP/DHCP registry still records with a length of four.

The option did not merely add another hint. When the server was configured to honor it, the selected subnet took precedence over the normal inference from giaddr or the receiving interface. The server had to choose an address on the specified subnet or on another subnet attached to the same network segment. It was forbidden to offer an address outside that boundary.

The historical change is easy to miss because it fits into six bytes of option framing. Before option 118, the server could treat observed arrival topology as the allocation selector. After option 118, the packet could carry a claim about a different allocation surface. Observation and instruction were no longer the same fact.

The motivating device held two roles at once. Toward the DHCP server, it was the requester reachable on an internal network. Toward its subscribers, it was an address manager for external networks. The protocol needed to preserve the internal return path without letting that path force selection from the internal pool. RFC 3011 therefore kept giaddr alive for communication even while option 118 displaced it for allocation.

That separation is explicit during renewal. A DHCP server may send a DHCPACK directly to the allocated address, yet the external address might not be routable from the server. Every request carrying option 118 therefore had to put in giaddr an IPv4 address on which the requester could accept DHCP packets. The rule for choosing the reply destination did not change. One field named where the reply could return; another named where the lease should be drawn.

RFC 3011 also built a small compatibility receipt. A server configured to support option 118 had to return an identical copy in any response to a client that sent it, even if the client did not ask for it in the Parameter Request List. A participating client had to discard a DHCPOFFER or DHCPACK that lacked the option.

That discard rule mattered in a mixed network. An old server would ignore the unfamiliar option, follow its ordinary pool-selection algorithm and omit option 118 from the reply. A newer server whose administrator had disabled the feature would do the same. The requester could not safely accept an address merely because it received a syntactically valid offer. Absence of the echo said that the special allocation contract was not in force.

But the echo proved only so much. It showed that the option had survived a processing path governed by RFC 3011. It did not prove who originated the request, whether that actor was entitled to consume the named pool, whether a route existed to the assigned address, whether the address was conflict-free on the external link, or whether a subscriber ever received service. The identical bytes were evidence about one protocol decision, not a compressed certificate of every downstream fact.

The security section drew the consequence sharply. At the time, DHCP itself supplied no authentication mechanism. A client able to name nonlocal subnets could attack more than its local pool. Instead of exhausting only the addresses selected by its arrival topology, it could point requests at a wider set of pools.

RFC 3011 therefore made support disabled by default. An operator had to enable it deliberately, and a server was encouraged to restrict the feature—for example, to configured client identifiers, requests from selected subnets or a bounded list of target subnets. The option standardized how to express a choice; it did not authorize every speaker to make that choice.

That distinction is central to the history. A public option number solves interoperability among implementations. It does not solve the principal-agent problem created when a requester can direct allocation outside the place from which it is observed. The server still needs local policy capable of answering a different question: which requester may influence which pool?

RFC 2132 supplied the option grammar in which code, length and value could be carried. RFC 3011 assigned meaning to one new value. The earlier grammar made the instruction parseable; the new memo made it actionable under configuration. Neither layer authenticated the instruction by itself.

Later work moved related topology claims toward the relay boundary. RFC 3046 defined Relay Agent Information, including circuit and remote identifiers that a relay could add under an operator’s trust model. RFC 3527 then defined a link-selection sub-option for a relay that needed the allocation link to differ from the address used to communicate with that relay.

RFC 3527 preserved the three-way split. The relay’s reachable address could remain in giaddr; the link-selection value could drive pool choice; the eventual assigned address belonged to the client-side link. If a packet contained both RFC 3011’s client option and RFC 3527’s relay sub-option, link selection took precedence. The rule located greater weight in the operator-controlled relay context, not in the mere fact that two four-octet values existed.

Even then, an echo was not automatically an acknowledgement. RFC 3527 told the relay not to infer processing merely from whether its sub-option appeared in a response, because Relay Agent Information could be copied as a container. Administrative knowledge that server and relay supported the same behavior remained necessary. RFC 3118 specified DHCP authentication, but the existence of an authentication option likewise did not prove that a particular deployment used it.

RFC 7969 later surveyed the larger family of DHCP topology customizations: subnet selection, link selection and virtual subnet selection. The proliferation was not evidence that topology had become irrelevant. It showed that “where did this message arrive?” could no longer carry every meaning required by access networks, relays, VPNs and separated control planes.

The durable lesson is an evidence diagram. A captured packet can establish its observed source, receiving interface, giaddr and option 118 value. A server log can establish the policy branch and pool it selected. A lease record can establish an allocation. A relay record can establish a forwarding decision. A route and neighbor observation can establish some reachability. A subscriber session and application response can establish later use. None should be silently substituted for the next.

Through Lu Heng’s running-code lens, option 118 was a minimum common mechanism. It did not force every DHCP server to redesign all operations. It changed one input—the subnet used for allocation—while leaving reply selection and unrelated DHCP behavior intact. That narrowness made implementation possible, but it also kept responsibility local: the server operator had to decide when the override was safe.

The option’s strongest idea was not that topology could be ignored. It was that a topology observation and an allocation decision are different categories. Once they diverged, the protocol had to carry both, the client needed evidence that the divergence was understood, and the operator needed policy to prevent the new freedom from becoming an extraction path across every pool.

The packet came from the internal subnet. The reply could return there. The address still belonged to an external pool. RFC 3011 made all three statements simultaneously true—and made it impossible to defend the allocation merely by pointing to where the request was seen.

Sources