摘要

  • RFC 4014 允许网络接入服务器保存成功的 RADIUS Access-Accept 中有限的属性，并在稍后的 DHCP 中继消息里通过子选项 7 携带这些属性。
  • DHCP 服务器用这些信息选择配置参数；RADIUS 授权、接入中继传递和 DHCP 地址分配仍是不同环节，依赖同一管理域内的信任关系。

获准接入之后，地址还没有出现

设备刚连上无线网络，或插入办公网交换机端口。802.1X 认证通过，接入设备放行了会话。但设备要开始普通的 IP 通信，还必须完成 DHCP 配置。于是网络里出现了一个容易被忽略的时间差：授权已经作出，地址与其他参数仍待 DHCP 服务器选择。

两项服务回答的不是同一个问题。RADIUS 可以认证会话并返回相关授权属性；DHCP 根据自己的配置规则为客户端提供地址和其他参数。RFC 3580 明确指出，IEEE 802.1X 本身不提供 IP 地址分配机制。即使授权结果中含有 Framed-Pool，也只有能够参与地址分配的认证器才可能使用它。

这类分工在实际网络中很常见：身份验证由集中式 RADIUS 服务负责，地址池则由另一台 DHCP 服务器管理；位于边缘的交换机或无线接入点，也可能同时充当 DHCP 中继。中继知道哪一条接入会话刚获得授权，服务器知道自己管理哪些地址和选项。若两者无法传递必要上下文，各自就得重新推断另一方掌握的信息，或被迫把服务合并到一台设备上。

Ralph Droms 和 John Schnizlein 于 2005 年 2 月发布的 RFC 4014，为这种分工增加了一个明确的接口。接入服务器在收到成功的 RADIUS Access-Accept 后，把其中的属性暂存在本地。稍后，它中继客户端的 DHCP 消息时，可以把经筛选的属性一并送出。它连接两次交换，却没有把 RADIUS 的授权决定变成 DHCP 租约。

先有中继信息的外壳

RFC 4014 建立在更早的 RFC 3046 之上。后者定义了 DHCP Relay Agent Information 选项，通常称为 Option 82，用来携带中继比客户端更了解的信息，例如请求从哪条电路进入网络，或对应哪个远端设备。DHCP 服务器可以用这些标识选择地址或其他配置参数。

服务器还会把中继信息放回响应中，再由中继在发给客户端前移除。客户端因此不必理解运营网络内部的电路标识或远端标识。Option 82 的作用是让基础设施两端交换上下文，而不要求终端参与这套内部约定。

RFC 4014 在这个外壳里新增了代码为 7 的“RADIUS Attributes”子选项。中继可以把来自 Access-Accept 的 RADIUS 属性按原编码放入其中，供 DHCP 服务器决定采用哪组配置。中继不是租约的裁定者；它传送的是另一项控制过程产生的有限信息。

该机制并不只适用于 802.1X。RFC 4014 允许中继传递因其他原因取得的 RADIUS 属性，但要求遵循 RADIUS 语义。它对稳健互操作性的承诺也很窄：RADIUS 与 DHCP 服务应处于同一个局部管理域；不同管理域之间的全球一致性并不在保证范围内。

有限清单不是装饰

RFC 4014 对中继内容规定了边界。一条消息最多只能有一个 RADIUS Attributes 子选项。如果 User-Name 和 Framed-Pool 可用，中继必须将它们放入；其他属性则可按需加入。为避免地址分配依赖 RADIUS 服务器上其他分离的状态，标准建议把内容控制在六种属性之内：User-Name、Service-Type、Vendor-Specific、Session-Timeout、Framed-Pool 和 Framed-IPv6-Pool。

DHCP 服务器读取该子选项后，用它来选择配置参数；对于清单之外的属性，标准建议忽略。一个地址池名称可以影响策略分支，却不会强迫服务器从自己不管理的池中发放地址。授权属性提供了上下文，不取代 DHCP 服务器对地址资源和最终配置的控制。

这里还有字节数限制。子选项容量有限，RFC 4014 规定中继会截断属性以便装入，却没有给出通用的截断优先级算法。因而不能仅凭 RADIUS 返回过某个值，就假定该值完整抵达 DHCP 服务器。运营者需要观察实际中继报文，也需要理解特定实现如何处理长度边界。

更关键的状态责任落在接入服务器上。它必须把暂存的授权属性关联到正确的会话，再用于随后到达的 DHCP 请求。标准并未规定如何实现会话表，也没有替运营者决定认证重试或策略变更后怎样刷新状态。这些是由接口设计引出的运维问题，而非 RFC 4014 已经规定的行为。

信任也经过这条通道

DHCP 服务器会基于中继携带的值选择配置，因此中继与服务器之间的信任属于控制路径本身。RFC 4014 沿用 RFC 3046 所依赖的可信关系：边界设备应只接受可信中继提供的 Option 82；标准还建议使用中继选项认证或 IPsec 等更深层保护，而不是仅依靠外围过滤。

客户端通常看不到 Option 82，但不可见不等于可信。服务器必须能确认信息来自哪里、传输过程是否得到保护。若伪造或过期的属性穿过信任边界，服务器就可能进入错误的策略分支。这是基于机制作出的风险推论，不代表已有证据显示某个网络发生过此类事故。

因此，“谁决定地址”没有单一答案。RADIUS 决定会话是否授权并给出属性；中继决定传递什么上下文；DHCP 服务器据此选择配置并管理地址池。标准规定的信息通路无法独自保证中继状态正确、管理域配置一致，或服务器选中的地址符合预期。结果只能由实际运行的中继和 DHCP 服务来证明。

后续扩展保留了两条路径

2023 年的 RFC 9445 再次处理 RADIUS 属性与 DHCP 配置之间的接口。RFC 4014 原先把可携带的属性固定在一张清单中。RFC 9445 将其更新为 IANA 维护的许可属性登记表，并允许在专家审查机制下扩展。变化发生在原有子选项 7 的许可范围上。

RFC 9445 还另行定义了两种携带 DHCP 选项的 RADIUS 属性：DHCPv6-Options（245.3）和 DHCPv4-Options（245.4）。它用加密 DNS 参数说明可能的服务配置，但示例并不能证明实际部署规模。这两种新属性不是 RFC 4014 的子选项 7。当前 IANA 登记表说明哪些属性和选项已获许可，不说明运营商是否正在使用它们。

这条历史线索不是“RADIUS 接管了 DHCP”，而是如何把一项服务的授权上下文送给另一项服务，同时保留各自的控制面。服务需求变多后，许可范围可以扩展；但跨过网络边界仍要有明确的信任、配置和运行证据。

以卢恒 Note 64 的后见之明来看，RFC 4014 提供了一个最小公共接口，具体如何使用仍由局部管理域决定。Note 65 则提示，标准发布并不等于代码已经这样运行。这两份笔记是后来的分析视角，不是 RFC 4014 的历史成因或协议证据。最终要看接入服务器、DHCP 中继与服务器所运行的代码，是否把正确的上下文送达并按预期使用。

来源