摘要

  • RFC 3442为DHCPv4定义了选项121，可以携带带有明确前缀长度的路由，修补旧静态路由选项依赖地址类别的假设。
  • 支持该选项的客户端必须安装这些路由；若它们与Router选项或选项33同时出现，客户端必须优先采用选项121。RFC也明确警告，错误的下一跳会误导流量。

地址租约听起来像一次分配：网络告诉主机可以使用哪个地址、期限多长。但主机还需要知道，发往本地链路之外的数据包该交给谁。RFC 3442把这个决定纳入DHCP配置对话：无类静态路由选项可以同时传递目的前缀和到达它所用的路由器地址。

改变源于一个不匹配。RFC 2132定义的DHCP选项33没有为每个目的地单独携带掩码。这隐含着一种旧假设：网络边界能从地址类别推算出来。无类路由打破了它：10.0.0.0/8与10.0.0.0/24是不同目的地，即使它们的开头相同。客户端必须知道前缀长度，才能确定哪些位属于这条路由。

选项121以紧凑格式表示这个范围。目的描述符先给出前缀长度，只携带有意义的地址字节，后面跟着四字节路由器地址。客户端重建目的网络，并在安装路由前把掩码以外的位清零。RFC 3442并没有把DHCP变成路由协议，也没有下发整个互联网路由表。它做的是让已经负责主机配置的DHCP服务器成为安装部分静态路由的一种渠道。

因此，一个重要选择跨越了管理边界。路由表依然留在主机上，客户端也仍按自己的规则处理配置；但路由可以从服务器配置中产生，不必逐台在设备上编辑。对于支持选项121的客户端，RFC要求安装路由，只有本地子网情况另作规定。如果选项121与较旧的Router选项或选项33同时出现，客户端必须忽略后两者。请求顺序也有意义：客户端的参数请求列表中，选项121必须排在Router和选项33之前。

兼容性不是附带考虑。没有实现选项121的客户端必须忽略它，因此RFC 3442建议管理员也发送Router选项，为旧客户端重复提供默认路由信息。这是一种过渡策略，并不证明有多少设备支持新选项，也不说明网络采用速度。标准可以规定优先级，却不能保证每个客户端都实现它。

这个机制还有明确的安全后果。RFC 3442警告说，错误的路由器地址可能造成拒绝服务，或把流量引向窥探者。风险并非选项121独有；旧Router和静态路由选项也能指向错误下一跳。选项本身不证明路由获得授权、内容正确或路径安全。即使使用DHCP消息认证，那也是另一项机制；认证发送者，并不自动证明该路由决定合理。

报文大小也影响这次交付。较长的路由列表可能超过传统DHCP报文大小，RFC 3442因此讨论更大的报文协商，并要求支持DHCP长选项拼接。在共享多条IP子网的链路上，它还规定了下一跳0.0.0.0的特殊用法，用来表示可直接到达的本地子网；若客户端的协议栈没有相应能力，则必须忽略此项。

RFC 3442的历史动作不大，却揭示了控制面的变化：当路由转向无类别前缀，地址配置也要能够表达路由范围。租约于是可能成为本地转发策略的载体。客户端仍是安装地点，DHCP管理员则成为路由选择的一方；下一跳的影响不再止于地址分配。

来源