DHCP子选项：Server Identifier Override

关于本备忘录

本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参阅当前版本的“互联网官方协议标准”（STD 1）。这份备忘录的分发是无限的。

摘要

本备忘录定义了DHCP中继信息选项的新子选项，该选项允许DHCP中继为DHCP服务器插入的服务器标识符选项指定新值。这允许DHCP中继充当实际的DHCP服务器，使得RENEW DHCPREQUEST请求可以到达中继，而不是直接到达服务器。这使中继有机会包括中继代理选项和适当的子选项，即使在DHCP RENEW消息上也是如此。

1、 简介

在许多情况下，涉及DHCP中继代理，它可以很容易地将中继代理信息选项[3]和适当的子选项插入DHCPDISCOVER消息中。但是，一旦授予租约，处于更新状态的客户端发送的未来DHCPREQUEST消息将直接发送到DHCP服务器，如服务器标识符选项中所指定的。在这种情况下，中继可能看不到这些DHCPREQUEST消息（取决于网络拓扑），因此无法在DHCPREQUEST消息中插入中继代理信息选项。

此DHCP中继代理子选项“Server Identifier Override”允许中继代理告诉DHCP服务器要在“服务器标识符”选项中放入什么值[5]。使用此选项，中继代理可以强制处于RENEWING状态的主机向中继代理发送DHCPREQUEST消息，而不是直接向服务器发送。然后，中继代理有机会插入带有适当子选项的中继代理信息选项，并将DHCPREQUEST中继到实际服务器。以这种方式，DHCP服务器在续订时将被提供与初始DHCPDISCOVER消息中所提供的相同的中继代理信息（例如电路ID、远程ID、设备类别等）。

简而言之，这个新的子选项允许DHCPv4中继以与DHCPv6中继[7]当前相同的方式工作。

2、 惯例

本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、”应该“、”不应“、”推荐“、”可能“和”可选“应按[1]中所述进行解释。

3、 术语

本文档使用RFC 2131[2]第1.5节中定义的DHCP术语，但术语“DHCP中继代理”代替“BOOTP中继代理”除外。

本文件中使用的其他术语：

*RENEW DHCPREQUEST-由处于RENEWING状态的客户端发送的DHCPREQUEST消息

4.服务器标识符覆盖子选项定义

子选项的格式为：

图1

选项长度（n）为4。八位字节“a1”到“a4”指定DHCP服务器在回复时必须插入到服务器标识符选项中的值。

实现此中继代理信息子选项的DHCP服务器必须使用此值（如果从客户端接收的DHCP消息中存在此值）作为插入相应响应中的服务器标识符选项的值。DHCP服务器还必须在子选项中记录地址，以便在从DHCP中继代理接收到下一条DHCP消息之前，在给DHCP客户端的后续消息中使用。

如果DHCP服务器不理解/不能实现此中继信息子选项，它将忽略该子选项，因此它将在服务器标识符选项中插入自己适当的接口地址。在这种情况下，DHCP中继将不会从客户端接收RENEW DHCPREQUEST消息。将DHCP中继代理配置为使用此子选项时，中继代理的管理员应考虑消息将中继到的DHCP服务器是否正确理解此子选项。

当为DHCPREQUEST消息提供服务时，DHCP服务器通常会查看“服务器标识符”选项，以验证指定的地址是否是与DHCP服务器关联的地址之一，如果DHCPREQUEST与配置的DHCP服务器接口地址不匹配，则无提示地忽略它。但是，如果DHCPREQUEST消息包含“服务器标识符覆盖”子选项，则应在该子选项中的地址和“服务器标识符”选项之间进行比较。如果“Server Identifier Override”子选项和“Server Identifier”选项都指定了相同的地址，则服务器应接受DHCPREQUEST消息进行处理，无论“服务器标识符选项”是否与DHCP服务器接口匹配。

DHCP中继代理在中继消息时应该填写giaddr字段，就像通常一样。

在DHCP中继代理被配置为将消息转发到多个服务器的情况下，DHCP中继代理应该将所有DHCP消息转发到所有服务器。这也适用于RENEW DHCPREQUEST消息。其目的是DHCP中继代理不需要维护有关DHCP租约的状态信息。

实现此子选项的DHCP中继代理还应实现并使用DHCPv4中继代理标志子选项[4]，以指定DHCP中继代理是以广播还是单播的形式接收原始消息。接收到包含服务器标识符覆盖子选项的消息的DHCP服务器可以在处理该消息时使用该附加信息。

请注意，如果DHCP客户端无法访问DHCP中继代理或失去对DHCP服务器的网络访问，则可能无法正确处理来自DHCP客户端的进一步RENEW DHCPREQUEST消息，并且DHCP客户端的租约可能超时。

5、 安全注意事项

[6]中定义了用于域内使用的DHCP中的消息身份验证，其中共享密钥的带外交换是可行的。[2]中DHCP协议规范的第7节讨论了潜在的攻击风险。

DHCP中继代理信息选项取决于DHCP中继代理和DHCP服务器之间的信任关系，如RFC 3046第5节所述。虽然除非DHCP中继代理是可信的，否则可以通过阻止这些选项的外围防御来防止引入欺骗性的DHCP中继代理信息选项，但也应该部署使用DHCP中继代理的信息选项[8]的身份验证子选项的更深层次防御。

如果在DHCP客户端和DHCP服务器之间插入了恶意DHCP中继代理，它可以使用此子选项将客户端重定向到自己。这将允许这样的系统稍后拒绝RENEW DHCPREQUEST，从而迫使客户端停止使用其分配的地址。它还可以允许流氓中继更改、插入或删除DHCPACK消息中的DHCP选项，并将租约延长到服务器允许的范围之外。DHCP身份验证[6]和/或DHCP中继代理信息选项身份验证[8]将解决这种情况。（请注意，与往常一样，缺少DHCP身份验证将允许流氓DHCP中继代理在未检测到的情况下更改DHCPOFFER和DHCPACK消息中的“Server Identifier Override”选项。此威胁对于“Server Identifier Override”子选项来说并不新鲜。）

本文档没有添加任何尚未存在的新漏洞，除非DHCP身份验证已经到位，并且DHCP客户端需要使用它。建议使用此选项时应部署DHCP身份验证和DHCP中继代理选项身份验证，或者应提供保护，防止在客户端和服务器之间插入恶意DHCP中继代理。

此中继子选项本身并不是为了提供任何额外的安全优势。

6、 IANA注意事项

IANA已从DHCP中继代理信息选项[3]子选项编号空间为服务器标识符覆盖子选项分配了子选项编号（11）。

7、 知识产权和版权

IETF已被告知与本文件中包含的部分或全部规范有关的知识产权要求。有关更多信息，请参阅在线权利要求列表。

8、 参考文献

8.1、 规范性引用文件

[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.[3] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.[4] Kinnear, K., Normoyle, M., and M. Stapp, "The Dynamic Host Configuration Protocol Version 4 (DHCPv4) Relay Agent Flags Suboption", RFC 5010, September 2007.

8.2、 参考资料

[5] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.[6] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.[7] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.[8] Stapp, M. and T. Lemon, "The Authentication Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option", RFC 4030, March 2005.

完整版权声明

版权所有（C）IETF Trust（2008）。

本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。

本文件和此处包含的信息是在“原样”的基础上提供的，贡献者、他/她代表或赞助的组织（如有）、互联网协会、IETF信托和互联网工程任务组不承担任何明示或暗示的保证，包括但不限于任何保证，即使用此处的信息不会侵犯任何权利，或任何隐含的适销性或适用于特定目的的保证。

知识产权

IETF对可能声称与本文件中所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能可用或不可用的程度，不持任何立场；它也不代表它已作出任何独立努力来确定任何此类权利。关于RFC文档中的权限的过程的信息可以在BCP78和BCP79中找到。

向IETF秘书处披露的知识产权的副本和任何许可证的保证，或本规范的实施者或用户试图获得一般许可证或使用此类专有权利的许可的结果，可从IETF在线知识产权库获取，网址为http://www.ietf.org/ipr.

IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或可能涵盖实施本标准所需技术的其他专有权利。请将信息发送至IETF，网址为ietf-ipr@ietf.org.