Network Working Group M. Stapp
Request for Comments: 4243 R. Johnson
Category: Standards Track T. Palaniappan
Cisco Systems, Inc.
December 2005
Network Working Group M. Stapp
Request for Comments: 4243 R. Johnson
Category: Standards Track T. Palaniappan
Cisco Systems, Inc.
December 2005
Vendor-Specific Information Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option
动态主机配置协议（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）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This memo defines a new Vendor-Specific Information suboption for the Dynamic Host Configuration Protocol's (DHCP) relay agent information option. The suboption allows a DHCP relay agent to include vendor-specific information in the DHCP messages it forwards, as configured by its administrator.
此备忘录为动态主机配置协议（DHCP）中继代理信息选项定义了一个新的供应商特定信息子选项。该子选项允许DHCP中继代理在其转发的DHCP消息中包含特定于供应商的信息（由其管理员配置）。
Table of Contents
目录
1. Introduction ....................................................2
2. Requirements Terminology ........................................2
3. The Vendor-Specific Suboption ...................................2
4. Relay Agent Behavior ............................................4
5. DHCP Server Behavior ............................................4
6. Security Considerations .........................................4
7. IANA Considerations .............................................5
8. Acknowledgements ................................................5
Normative References ...............................................5
Informative References .............................................5
1. Introduction ....................................................2
2. Requirements Terminology ........................................2
3. The Vendor-Specific Suboption ...................................2
4. Relay Agent Behavior ............................................4
5. DHCP Server Behavior ............................................4
6. Security Considerations .........................................4
7. IANA Considerations .............................................5
8. Acknowledgements ................................................5
Normative References ...............................................5
Informative References .............................................5
DHCP (RFC 2131 [2]) provides IP addresses and configuration information for IPv4 clients. It includes a relay agent capability, in which processes within the network infrastructure receive broadcast messages from clients and forward them to DHCP servers as unicast messages. In network environments like DOCSIS data-over-cable and xDSL, for example, it has proven useful for the relay agent to add information to the DHCP message before forwarding it, using the relay agent information option (RFC 3046 [3]).
DHCP（RFC 2131[2]）为IPv4客户端提供IP地址和配置信息。它包括中继代理功能，其中网络基础设施中的进程从客户端接收广播消息，并将其作为单播消息转发到DHCP服务器。例如，在网络环境（如电缆上的DOCSIS数据和xDSL）中，中继代理在转发DHCP消息之前，使用中继代理信息选项（RFC 3046[3]）将信息添加到DHCP消息中是非常有用的。
Servers that recognize the relay agent option echo it back in their replies, and some of the information that relays add may be used to help an edge device efficiently return replies to clients. The information that relays supply can also be used in the server's decision making about the addresses and configuration parameters that the client should receive.
识别中继代理选项的服务器在其答复中回显该选项，中继添加的一些信息可用于帮助边缘设备高效地将答复返回给客户端。中继提供的信息也可用于服务器关于客户端应接收的地址和配置参数的决策。
In many environments, it's desirable to associate some vendor- or provider-specific information with the clients' DHCP messages. This is often done using the relay agent information option. RFC 3046 defines Remote-ID and Circuit-ID sub-options that are used to carry such information. The values of those suboptions, however, are usually based on some network resource, such as an IP address of a network access device, an ATM Virtual Circuit identifier, or a DOCSIS cable-modem identifier. As a result, the values carried in these suboptions are dependent on the physical network configuration. The Vendor-Specific suboption allows administrators to associate other useful data with relayed DHCP messages.
在许多环境中，希望将一些特定于供应商或提供商的信息与客户端的DHCP消息相关联。这通常使用中继代理信息选项来完成。RFC 3046定义了用于携带此类信息的远程ID和电路ID子选项。然而，这些子选项的值通常基于某些网络资源，例如网络接入设备的IP地址、ATM虚拟电路标识符或DOCSIS电缆调制解调器标识符。因此，这些子选项中包含的值取决于物理网络配置。特定于供应商的子选项允许管理员将其他有用数据与中继的DHCP消息相关联。
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 RFC 2119 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释。
This memo defines a new DHCP relay agent option suboption that carries vendor-defined data. The suboption takes a form similar to the Vendor-Identifying, Vendor-Specific Option [7].
此备忘录定义了一个新的DHCP中继代理选项子选项，该选项包含供应商定义的数据。子选项的形式类似于供应商识别、供应商特定选项[7]。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Length | Enterprise Number1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | DataLen1 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
\ Suboption Data1 \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DataLen2 | Suboption Data2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Length | Enterprise Number1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | DataLen1 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
\ Suboption Data1 \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DataLen2 | Suboption Data2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Code for the suboption is 9.
子选项的代码是9。
The one-byte Length field is the length of the data carried in the suboption, in bytes. The length includes the length of the first Enterprise Number; the minimum length is 4 bytes.
单字节长度字段是子选项中携带的数据的长度，以字节为单位。长度包括第一个企业编号的长度；最小长度为4字节。
"Enterprise NumberN" is a vendor's Enterprise Number as registered with IANA [4]. It is a four-byte integer value in network byte-order.
“企业编号”是在IANA注册的供应商企业编号[4]。它是一个按网络字节顺序排列的四字节整数值。
DataLenN is the length of the data associated with the Enterprise Number.
DataLenN是与企业编号关联的数据长度。
The Suboption Data is an opaque sequence of bytes.
子选项数据是一个不透明的字节序列。
The Vendor-Specific suboption includes at least one Enterprise Number and carries opaque data defined by the organization identified by the Enterprise Number. A relay may include data associated with more than one vendor's Enterprise Number within a single instance of the Suboption.
特定于供应商的子选项包括至少一个企业编号，并包含由企业编号标识的组织定义的不透明数据。中继可以包括与子选项的单个实例中的多个供应商的企业编号相关联的数据。
Of course, the Vendor-Specific data are vendor-specific. This specification does not establish any requirements on the data in the suboption. Vendors who make use of this suboption are encouraged to document their usage in order to make interoperability possible.
当然，特定于供应商的数据是特定于供应商的。本规范未对子选项中的数据建立任何要求。鼓励使用此子选项的供应商记录其使用情况，以实现互操作性。
DHCP relay agents MAY be configured to include Vendor-Specific suboptions if they include a relay agent information option in relayed DHCP messages. The suboptions' types and data are assigned and configured through mechanisms that are outside the scope of this memo.
如果DHCP中继代理在中继DHCP消息中包含中继代理信息选项，则可以将DHCP中继代理配置为包含供应商特定的子选项。子选项的类型和数据通过本备忘录范围之外的机制进行分配和配置。
Relay implementors are encouraged to offer their administrators a means of configuring what data can be included in this suboption, and to document what they are capable of.
鼓励中继实现者向其管理员提供一种配置此子选项中可以包含哪些数据的方法，并记录他们的能力。
This suboption provides additional information to the DHCP server. The DHCP server, if it is configured to support this suboption, may use this information, in addition to other relay agent option data and other options included in the DHCP client messages, in order to assign an IP address and/or other configuration parameters to the client. There is no special additional processing for this suboption.
此子选项向DHCP服务器提供附加信息。DHCP服务器如果配置为支持此子选项，则除了DHCP客户端消息中包含的其他中继代理选项数据和其他选项外，还可以使用此信息，以便为客户端分配IP地址和/或其他配置参数。此子选项没有特殊的附加处理。
Message authentication in DHCP for intradomain use, where the out-of-band exchange of a shared secret is feasible, is defined in RFC 3118 [5]. Potential exposures to attack are discussed in section 7 of the DHCP protocol specification in RFC 2131 [2].
RFC 3118[5]中定义了DHCP中用于域内使用的消息认证，其中共享秘密的带外交换是可行的。RFC 2131[2]中DHCP协议规范的第7节讨论了潜在的攻击风险。
The DHCP relay agent option depends on a trusted relationship between the DHCP relay agent and the server, as described in section 5 of RFC 3046. Fraudulent relay agent option data could potentially lead to theft-of-service or exhaustion of limited resources (like IP addresses) by unauthorized clients. A host that tampered with relay agent data associated with another host's DHCP messages could deny service to that host, or interfere with its operation by leading the DHCP server to assign it inappropriate configuration parameters.
DHCP中继代理选项取决于DHCP中继代理和服务器之间的信任关系，如RFC 3046第5节所述。欺诈性中继代理选项数据可能导致未经授权的客户端窃取服务或耗尽有限的资源（如IP地址）。篡改与另一台主机的DHCP消息相关联的中继代理数据的主机可能会拒绝向该主机提供服务，或导致DHCP服务器为其分配不适当的配置参数，从而干扰其操作。
While the introduction of fraudulent relay agent options can be prevented by a perimeter defense that blocks these options unless the relay agent is trusted, a deeper defense using authentication for relay agent options via the Authentication Suboption [6] SHOULD be deployed as well.
虽然引入欺诈性中继代理选项可以通过周界防御来防止，除非中继代理受信任，否则周界防御会阻止这些选项，但也应部署通过身份验证子选项[6]对中继代理选项进行身份验证的更深入防御。
There are several data in a DHCP message that convey information that may identify an individual host on the network. These include the chaddr, the client-id option, and the hostname and client-fqdn options. Depending on the type of data included, the Vendor-Specific suboption may also convey information that identifies a specific host or a specific user on the network. In practice, this information isn't exposed outside the internal service-provider network, where DHCP messages are usually confined. Administrators who configure data that will be used in DHCP Vendor-Specific suboptions should be careful to use data that are appropriate for the types of networks
DHCP消息中有多个数据，这些数据传递的信息可能会标识网络上的单个主机。其中包括chaddr、客户端id选项以及主机名和客户端fqdn选项。根据所包括的数据类型，特定于供应商的子选项还可以传递标识网络上特定主机或特定用户的信息。实际上，这些信息不会暴露在内部服务提供商网络之外，因为DHCP消息通常被限制在该网络中。配置将在DHCP供应商特定子选项中使用的数据的管理员应小心使用适合网络类型的数据
they administer. If DHCP messages travel outside the service-provider's own network, or if the suboption values may become visible to other users, it may raise privacy concerns for the access provider or service provider.
他们管理。如果DHCP消息在服务提供商自己的网络之外传播，或者如果子选项值对其他用户可见，则可能会引起访问提供商或服务提供商的隐私问题。
The IANA has assigned the suboption number 9 for the Vendor-Specific Information Suboption from the DHCP Relay Agent Information Option [3] suboption number space.
IANA已从DHCP中继代理信息选项[3]子选项编号空间为供应商特定信息子选项分配了子选项编号9。
The authors are grateful to Andy Sudduth, Josh Littlefield, and Kim Kinnear for their review and comments.
作者感谢Andy Sudduth、Josh Littlefield和Kim Kinnear的评论和评论。
Normative References
规范性引用文件
[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] IANA, "Private Enterprise Numbers (http://www.iana.org/ assignments/enterprise-numbers.html)".
[4] IANA，“私营企业编号(http://www.iana.org/ 分配/企业编号.html）”。
Informative References
资料性引用
[5] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.
[5] Droms，R.和W.Arbaugh，“DHCP消息的身份验证”，RFC31182001年6月。
[6] Stapp, M. and T. Lemon, "The Authentication Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option", RFC 4030, March 2005.
[6] Stapp，M.和T.Lemon，“动态主机配置协议（DHCP）中继代理选项的身份验证子选项”，RFC 4030，2005年3月。
[7] Littlefield, J., "Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4)", RFC 3925, October 2004.
[7] Littlefield，J.，“动态主机配置协议版本4（DHCPv4）的供应商识别供应商选项”，RFC 3925，2004年10月。
Authors' Addresses
作者地址
Mark Stapp Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 USA
Mark Stapp Cisco Systems，Inc.美国马萨诸塞州Boxborough大道1414号，邮编01719
Phone: 978.936.0000 EMail: mjs@cisco.com
电话：978.936.0000电子邮件：mjs@cisco.com
Richard Johnson Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134 USA
Richard Johnson Cisco Systems，Inc.170 W.Tasman Dr.圣何塞，加利福尼亚州，美国95134
Phone: 408.526.4000 EMail: raj@cisco.com
电话：408.526.4000电子邮件：raj@cisco.com
Theyn Palaniappan Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134 USA
Theyn Palaniappan Cisco Systems，Inc.170 W.Tasman Dr.San Jose，CA 95134美国
Phone: 408.526.4000 EMail: athenmoz@cisco.com
电话：408.526.4000电子邮件：athenmoz@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
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 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。