Summary

  • RFC 4014 let a network access server preserve a limited set of attributes from a successful RADIUS Access-Accept and carry them later in DHCP Relay Agent Information suboption 7.
  • The DHCP server used those attributes when selecting configuration; RADIUS authorization, relay transport, and DHCP address assignment remained separate jobs, bounded by a local trust relationship.

The green light came before the address

A device joins a wireless or wired network. Its access request succeeds. The switch or access point lets it through. Yet one more exchange is still needed before ordinary IP communication can begin: DHCP must supply the configuration the device will use.

That gap is easy to miss because both steps happen near the edge of the same network. But they answer different questions. RADIUS can tell a network access server whether a session is authorized and return attributes associated with that service. DHCP determines which configuration parameters to offer. In IEEE 802.1X, an Access-Accept does not itself assign an IP address. RFC 3580 says so explicitly, and notes that pool attributes are useful only when the authenticator supports address assignment.

The division was more than protocol tidiness. A campus, enterprise or access provider might centralize authentication while keeping address allocation on a separate DHCP server. The access device knew which user or session had just been admitted; the DHCP server knew which address pools and options it could offer. Without a bridge, each service would have to reconstruct the other’s context or collapse into one implementation.

RFC 4014, published in February 2005 as a Standards Track document by Ralph Droms and John Schnizlein, supplied that bridge. It did not merge RADIUS and DHCP. It let a network access server (NAS) retain attributes returned in a successful RADIUS Access-Accept, then include a bounded selection in a later DHCP message that the NAS relayed.

Option 82 was already a place for relay knowledge

The mechanism depended on an earlier decision. RFC 3046 had defined the DHCP Relay Agent Information option, commonly called Option 82, as an envelope for facts known by the relay. Its original examples were circuit and remote identifiers: where a request entered the access network and which modem or subscriber-side device it came from. A DHCP server could use that information to apply address or other parameter policies.

RFC 3046 also specified the envelope’s return path. The server echoes relay information in its reply; the relay removes it before sending the response to the client. The client does not need to understand the access network’s internal labels.

RFC 4014 added another suboption inside that envelope: code 7, “RADIUS Attributes.” The NAS could copy selected attribute octets from the Access-Accept into that field when it subsequently forwarded the client’s DHCP request. The DHCP server could then use the attributes in choosing client configuration. The relay was not making the lease decision; it was carrying evidence from one control exchange to another.

This sequencing mattered. Authentication happened first. The NAS retained the authorization result locally. The DHCP request arrived later, and the relay attached the relevant attributes. The specification does not turn that sequence into a general identity credential: it defines a specific relay-to-server path and constrains the carried data to attributes provided by the Access-Accept.

A list that marked the boundary

RFC 4014 set both a limit and a minimum. A relay could include no more than one RADIUS Attributes suboption in a message. If User-Name and Framed-Pool were available, it had to include them; other attributes were optional. To avoid making address allocation depend on unrelated state held by the RADIUS server, the relay was advised to keep to six attributes: User-Name, Service-Type, Vendor-Specific, Session-Timeout, Framed-Pool and Framed-IPv6-Pool.

The DHCP server was not told to obey every value that a relay might send. It used the suboption in selecting configuration and was expected to ignore attributes outside the named set. A pool name could help direct a request toward a particular configuration, but it did not compel the server to issue an address from a pool it did not control. Authorization context influenced selection; the DHCP server remained the allocator.

There was also a physical limit. Suboption 7 had finite room, and RFC 4014 says the relay truncates the RADIUS attributes to make them fit. The document does not prescribe a universal priority rule for what survives truncation. That makes packet size and attribute selection an implementation concern, not a safe place to infer that every returned value reached the DHCP server.

The design drew a visible line between protocols, but it created a responsibility at the relay. The NAS needed to preserve the right authorization state for the later DHCP request. Operators therefore need to know how the relay binds stored attributes to a session and what happens when authorization changes. Those are operational questions arising from the handoff, not extra rules that RFC 4014 claims to settle.

Trust crossed the same wire as context

Because the DHCP server may use relay-supplied values to choose configuration, the relay is part of the control path. RFC 4014 limits robust interoperability to a single localized administrative domain; it does not promise that independently administered RADIUS and DHCP systems will share global semantics. Its security section inherits RFC 3046’s trusted relay-to-server relationship. Perimeter filtering should admit relay information only from trusted relays, and the RFC recommends deeper protection such as relay-agent option authentication or IPsec.

The client normally never sees Option 82. That reduces exposure to the end device, but it does not make the contents self-authenticating. The server’s confidence comes from its relationship with the relay and whatever protection the domain deploys. A forged or stale value could affect a server-side policy branch if the trust checks fail. That is a plausible consequence of the architecture, not evidence that a particular network suffered such an incident.

The administrative boundary is therefore part of the protocol’s practical meaning. A standard can define the bytes and allowed attributes; it cannot by itself prove that a relay is trustworthy, that its stored state is current, or that a DHCP pool is the right one for a session. The final test remains the behavior of the running relay and DHCP server.

The later extension did not replace suboption 7

RFC 9445, published in 2023, returned to the same junction as services began to need DHCP parameters that the older frozen attribute list could not carry. It updates RFC 4014 by moving the permitted RADIUS attributes into an IANA registry, which can be extended through expert review. That is an evolution of the suboption-7 path.

RFC 9445 also defines two different RADIUS attributes for carrying DHCP options: DHCPv6-Options (245.3) and DHCPv4-Options (245.4). Its encrypted-DNS example shows how service parameters might travel from RADIUS into a DHCP procedure. These attributes are not the old RADIUS Attributes suboption and do not prove widespread use. The IANA registry now records both the permitted RFC 4014 attribute values and the DHCP options allowed inside the newer attributes. A registry entry shows what is permitted, not what operators have deployed.

This distinction is important to the history. The design did not become a single universal “RADIUS assigns IP” protocol. It remained a set of bounded handoffs: the authorization server supplies context, the relay preserves and forwards it, and DHCP applies its own configuration rules. New services prompted a controlled extension, but the trust and local-policy boundary remained.

Read through the later lens of Lu Heng’s Note 64, the mechanism resembles a minimum common envelope with subsequent choices left to a local administrative domain. Note 65 supplies a related operational test: publication of a standard is not the same as running behavior. These notes are later analytical lenses, not causes or evidence for the 2005 specification. What RFC 4014 makes visible is the practical seam: a network has not finished deciding a device’s configuration until the code that runs at its relay and DHCP server has carried the right context across that seam.

Sources