Network Working Group R. Johnson
Request for Comments: 5107 J. Jumarasamy
Category: Standards Track K. Kinnear
M. Stapp
Cisco Systems, Inc.
February 2008
Network Working Group R. Johnson
Request for Comments: 5107 J. Jumarasamy
Category: Standards Track K. Kinnear
M. Stapp
Cisco Systems, Inc.
February 2008
DHCP Server Identifier Override Suboption
DHCP服务器标识符覆盖子选项
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Abstract
摘要
This memo defines a new suboption of the DHCP relay information option that allows the DHCP relay to specify a new value for the Server Identifier option, which is inserted by the DHCP Server. This allows the DHCP relay to act as the actual DHCP server such that RENEW DHCPREQUESTs will come to the relay instead of going to the server directly. This gives the relay the opportunity to include the Relay Agent option with appropriate suboptions even on DHCP RENEW messages.
此备忘录定义了DHCP中继信息选项的新子选项，该选项允许DHCP中继为服务器标识符选项指定新值，该选项由DHCP服务器插入。这允许DHCP中继充当实际的DHCP服务器，以便续订DHCPREQUESTs将到达中继，而不是直接到达服务器。这使中继有机会包括中继代理选项和适当的子选项，即使在DHCP续订消息上也是如此。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2
4. Server Identifier Override Suboption Definition . . . . . . . . 3
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
7. Intellectual Property Rights and Copyright . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . . 5
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2
4. Server Identifier Override Suboption Definition . . . . . . . . 3
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
7. Intellectual Property Rights and Copyright . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. Normative References . . . . . . . . . . . . . . . . . . . 5
8.2. Informative References . . . . . . . . . . . . . . . . . . 5
There are many situations where a DHCP relay agent is involved, and it can easily insert a Relay Agent Information option [3] with appropriate suboptions into DHCPDISCOVER messages. Once the lease has been granted, however, future DHCPREQUEST messages sent by a client in RENEWING state are sent directly to the DHCP server, as specified in the Server Identifier option. In this case, the relay may not see these DHCPREQUEST messages (depending upon network topology) and thus cannot insert the Relay Agent Information option in the DHCPREQUEST messages.
有许多情况涉及DHCP中继代理，它可以轻松地在DHCPDISCOVER消息中插入带有适当子选项的中继代理信息选项[3]。但是，一旦授予了租约，客户端在续订状态下发送的未来DHCPREQUEST消息将直接发送到DHCP服务器，如服务器标识符选项中所指定。在这种情况下，中继可能看不到这些DHCPREQUEST消息（取决于网络拓扑），因此无法在DHCPREQUEST消息中插入中继代理信息选项。
This DHCP relay agent suboption, Server Identifier Override, allows the relay agent to tell the DHCP server what value to place into the Server Identifier option [5]. Using this, the relay agent can force a host in RENEWING state to send DHCPREQUEST messages to the relay agent instead of directly to the server. The relay agent then has the opportunity to insert the Relay Agent Information option with appropriate suboptions and relay the DHCPREQUEST to the actual server. In this fashion, the DHCP server will be provided with the same relay agent information upon renewals (such as Circuit-ID, Remote-ID, Device Class, etc.) as was provided in the initial DHCPDISCOVER message.
DHCP中继代理的子选项“服务器标识符覆盖”允许中继代理告诉DHCP服务器要将什么值放入服务器标识符选项[5]。使用此功能，中继代理可以强制处于续订状态的主机将DHCPREQUEST消息发送到中继代理，而不是直接发送到服务器。中继代理然后有机会插入中继代理信息选项和适当的子选项，并将DHCPREQUEST中继到实际服务器。以这种方式，DHCP服务器在续订时将获得与初始DHCPDISCOVER消息中提供的相同的中继代理信息（例如电路ID、远程ID、设备类等）。
In short, this new suboption allows the DHCPv4 relay to function in the same fashion as the DHCPv6 relay [7] currently does.
简而言之，这个新的子选项允许DHCPv4继电器以与DHCPv6继电器相同的方式工作[7]。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be interpreted as described in [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[1]中所述进行解释。
This document uses DHCP terminology as defined in section 1.5 of RFC 2131 [2], with the exception of the term "DHCP relay agent" replacing "BOOTP relay agent".
本文件使用RFC 2131[2]第1.5节中定义的DHCP术语，但术语“DHCP中继代理”代替“BOOTP中继代理”除外。
Other terms used in this document:
本文件中使用的其他术语：
o RENEW DHCPREQUEST - a DHCPREQUEST message sent by a client in RENEWING state
o 续订DHCPREQUEST-处于续订状态的客户端发送的DHCPREQUEST消息
The format of the suboption is:
子选项的格式为：
Code Len Overriding Server Identifier Address
+-----+-----+-----+-----+-----+-----+
| 11 | n | a1 | a2 | a3 | a4 |
+-----+-----+-----+-----+-----+-----+
Code Len Overriding Server Identifier Address
+-----+-----+-----+-----+-----+-----+
| 11 | n | a1 | a2 | a3 | a4 |
+-----+-----+-----+-----+-----+-----+
Figure 1
图1
The option length (n) is 4. The octets "a1" through "a4" specify the value that MUST be inserted into the Server Identifier option by the DHCP Server upon reply.
选项长度（n）为4。八位字节“a1”到“a4”指定DHCP服务器在应答时必须插入到服务器标识符选项中的值。
DHCP servers that implement this Relay Agent Information suboption MUST use this value, if present in a DHCP message received from a client, as the value to insert into the Server Identifier option in the corresponding response. The DHCP server must also record the address in the suboption for use in subsequent messages to the DHCP client until the next DHCP message is received from the DHCP relay agent.
实现此中继代理信息子选项的DHCP服务器必须使用此值（如果存在于从客户端接收的DHCP消息中）作为要在相应响应中插入到服务器标识符选项中的值。DHCP服务器还必须在子选项中记录地址，以便在DHCP客户端的后续消息中使用，直到从DHCP中继代理接收到下一条DHCP消息。
If a DHCP server does not understand/implement this Relay Information suboption, it will ignore the suboption, and thus it will insert its own appropriate interface address in the Server Identifier option. In this case, the DHCP Relay will not receive RENEW DHCPREQUEST messages from the client. When configuring a DHCP relay agent to use this suboption, the administrator of the relay agent should take into account whether or not the DHCP server to which the message will be relayed will correctly understand this suboption.
如果DHCP服务器不理解/实现此中继信息子选项，它将忽略该子选项，因此它将在服务器标识符选项中插入自己适当的接口地址。在这种情况下，DHCP中继将不会从客户端接收续订DHCPREQUEST消息。将DHCP中继代理配置为使用此子选项时，中继代理的管理员应考虑消息将中继到的DHCP服务器是否正确理解此子选项。
When servicing a DHCPREQUEST message, the DHCP server would normally look at the Server Identifier option for verification that the address specified there is one of the addresses associated with the DHCP server, silently ignoring the DHCPREQUEST if it does not match a configured DHCP server interface address. If the DHCPREQUEST message contains a Server Identifier Override suboption, however, comparison should be made between the address in this suboption and the Server Identifier option. If both the Server Identifier Override suboption and the Server Identifier option specify the same address, then the server should accept the DHCPREQUEST message for processing, regardless of whether or not the Server Identifier option matches a DHCP server interface.
为DHCPREQUEST消息提供服务时，DHCP服务器通常会查看服务器标识符选项，以验证指定的地址是否存在与DHCP服务器关联的其中一个地址，如果DHCPREQUEST与配置的DHCP服务器接口地址不匹配，则会自动忽略该DHCPREQUEST。但是，如果DHCPREQUEST消息包含服务器标识符覆盖子选项，则应将此子选项中的地址与服务器标识符选项进行比较。如果Server Identifier Override子选项和Server Identifier选项都指定了相同的地址，则无论Server Identifier选项是否匹配DHCP服务器接口，服务器都应接受DHCPREQUEST消息进行处理。
The DHCP relay agent should fill in the giaddr field when relaying the message, just as it normally would do.
DHCP中继代理在中继消息时应该填写giaddr字段，就像它通常所做的那样。
In a situation where the DHCP relay agent is configured to forward messages to more than one server, the DHCP relay agent SHOULD forward all DHCP messages to all servers. This applies to RENEW DHCPREQUEST messages as well. The intent is that the DHCP relay agent should not need to maintain state information about the DHCP lease.
在DHCP中继代理配置为将消息转发到多个服务器的情况下，DHCP中继代理应将所有DHCP消息转发到所有服务器。这也适用于续订DHCPREQUEST消息。其目的是DHCP中继代理不需要维护有关DHCP租约的状态信息。
DHCP relay agents implementing this suboption SHOULD also implement and use the DHCPv4 Relay Agent Flags Suboption [4] in order to specify whether the DHCP relay agent received the original message as a broadcast or unicast. The DHCP server receiving a message containing the Server Identifier Override Suboption may use this additional information in processing the message.
实现此子选项的DHCP中继代理还应实现并使用DHCPv4中继代理标志子选项[4]，以指定DHCP中继代理是以广播还是单播方式接收原始消息。接收包含服务器标识符覆盖子选项的消息的DHCP服务器可以在处理消息时使用此附加信息。
Note that if the DHCP relay agent becomes inaccessible by the DHCP client or loses network access to the DHCP server, further RENEW DHCPREQUEST messages from the DHCP client may not be properly processed and the DHCP client's lease may time out.
请注意，如果DHCP客户端无法访问DHCP中继代理或失去对DHCP服务器的网络访问，则可能无法正确处理来自DHCP客户端的进一步续订DHCPREQUEST消息，并且DHCP客户端的租约可能会超时。
Message authentication in DHCP for intradomain use where the out-of-band exchange of a shared secret is feasible is defined in [6]. Potential exposures to attack are discussed in Section 7 of the DHCP protocol specification in [2].
[6]中定义了DHCP中用于域内使用的消息身份验证，其中共享秘密的带外交换是可行的。[2]中DHCP协议规范的第7节讨论了潜在的攻击风险。
The DHCP Relay Agent Information option depends on a trusted relationship between the DHCP relay agent and the DHCP server, as described in Section 5 of RFC 3046. While the introduction of fraudulent DHCP relay agent information options can be prevented by a perimeter defense that blocks these options unless the DHCP relay agent is trusted, a deeper defense using the authentication suboption for DHCP relay agent information option [8] SHOULD be deployed as well.
DHCP中继代理信息选项取决于DHCP中继代理和DHCP服务器之间的信任关系，如RFC 3046第5节所述。虽然引入欺诈性DHCP中继代理信息选项可以通过周界防御来防止，除非DHCP中继代理受信任，否则周界防御会阻止这些选项，但也应部署使用DHCP中继代理信息选项的身份验证子选项的更深入防御[8]。
If a rogue DHCP relay agent were inserted between the DHCP client and the DHCP server, it could redirect clients to itself using this suboption. This would allow such a system to later deny RENEW DHCPREQUESTs and thus force clients to discontinue use of their allocated addresses. It could also allow the rogue relay to change, insert, or delete DHCP options in DHCPACK messages and extend leases beyond what the server has allowed. DHCP authentication [6] and/or DHCP Relay Agent Information option authentication [8] would address this case. (Note that, as is always the case, lack of DHCP authentication would allow a rogue DHCP relay agent to change the Server Identifier Override option in the DHCPOFFER and DHCPACK messages without detection. This threat is not new to the Server Identifier Override suboption.)
如果在DHCP客户端和DHCP服务器之间插入恶意DHCP中继代理，它可以使用此子选项将客户端重定向到自身。这将允许这样的系统稍后拒绝续订DHCPREQUESTs，从而迫使客户端停止使用其分配的地址。它还允许rogue中继更改、插入或删除DHCPACK消息中的DHCP选项，并将租约扩展到服务器允许的范围之外。DHCP身份验证[6]和/或DHCP中继代理信息选项身份验证[8]将解决这种情况。（请注意，与往常一样，缺少DHCP身份验证将允许恶意DHCP中继代理更改DHCPOFFERE和DHCPACK消息中的服务器标识符覆盖选项，而无需检测。对于服务器标识符覆盖子选项来说，此威胁并不新鲜。）
This document does not add any new vulnerabilities that were not already present, except in the case where DHCP authentication is already in place, and DHCP clients require its use. It is suggested that DHCP Authentication and DHCP Relay Agent Option Authentication SHOULD be deployed when this option is used, or protection should be provided against the insertion of rogue DHCP relay agents between the client and server.
本文档不会添加任何尚未存在的新漏洞，除非DHCP身份验证已经到位，并且DHCP客户端要求使用该漏洞。建议在使用此选项时部署DHCP身份验证和DHCP中继代理选项身份验证，或者提供保护，防止在客户端和服务器之间插入恶意DHCP中继代理。
This relay suboption is not intended, by itself, to provide any additional security benefits.
此中继子选项本身并不打算提供任何额外的安全优势。
IANA has assigned a suboption number (11) for the Server Identifier Override Suboption from the DHCP Relay Agent Information Option [3] suboption number space.
IANA已从DHCP中继代理信息选项[3]子选项编号空间为服务器标识符覆盖子选项分配了子选项编号（11）。
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights.
IETF已收到关于本文件所含部分或全部规范的知识产权声明。有关更多信息，请查阅在线权利主张列表。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[2] Droms，R.，“动态主机配置协议”，RFC 2131，1997年3月。
[3] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.
[3] Patrick，M.，“DHCP中继代理信息选项”，RFC 3046，2001年1月。
[4] Kinnear, K., Normoyle, M., and M. Stapp, "The Dynamic Host Configuration Protocol Version 4 (DHCPv4) Relay Agent Flags Suboption", RFC 5010, September 2007.
[4] Kinnear，K.，Normoyle，M.和M.Stapp，“动态主机配置协议版本4（DHCPv4）中继代理标志子选项”，RFC 5010，2007年9月。
[5] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[5] Alexander，S.和R.Droms，“DHCP选项和BOOTP供应商扩展”，RFC 21321997年3月。
[6] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.
[6] Droms，R.和W.Arbaugh，“DHCP消息的身份验证”，RFC31182001年6月。
[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.
[7] Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[8] Stapp, M. and T. Lemon, "The Authentication Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option", RFC 4030, March 2005.
[8] Stapp，M.和T.Lemon，“动态主机配置协议（DHCP）中继代理选项的身份验证子选项”，RFC 4030，2005年3月。
Authors' Addresses
作者地址
Richard A. Johnson Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134 US
Richard A.Johnson Cisco Systems，Inc.170 W.Tasman Dr.San Jose，CA 95134美国
Phone: +1 408 526 4000
EMail: raj@cisco.com
Phone: +1 408 526 4000
EMail: raj@cisco.com
Jay Kumarasamy Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134 US
Jay Kumarasamy Cisco Systems，Inc.170 W.Tasman Dr.圣何塞，加利福尼亚州，美国95134
Phone: +1 408 526 4000
EMail: jayk@cisco.com
Phone: +1 408 526 4000
EMail: jayk@cisco.com
Kim Kinnear Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134 US
Kim Kinnear Cisco Systems，Inc.170 W.Tasman Dr.圣何塞，加利福尼亚州，美国95134
Phone: +1 408 526 4000
EMail: kkinnear@cisco.com
Phone: +1 408 526 4000
EMail: kkinnear@cisco.com
Mark Stapp Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134 US
Mark Stapp Cisco Systems，Inc.170 W.Tasman Dr.圣何塞，加利福尼亚州，美国95134
Phone: +1 408 526 4000
EMail: mjs@cisco.com
Phone: +1 408 526 4000
EMail: mjs@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.