Network Working Group J. Littlefield
Request for Comments: 3925 Cisco Systems, Inc.
Category: Standards Track October 2004
Network Working Group J. Littlefield
Request for Comments: 3925 Cisco Systems, Inc.
Category: Standards Track October 2004
Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4)
供应商识别动态主机配置协议版本4（DHCPv4）的供应商选项
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 (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
The Dynamic Host Configuration Protocol (DHCP) options for Vendor Class and Vendor-Specific Information can be limiting or ambiguous when a DHCP client represents multiple vendors. This document defines two new options, modeled on the IPv6 options for vendor class and vendor-specific information, that contain Enterprise Numbers to remove ambiguity.
当DHCP客户端代表多个供应商时，供应商类别和供应商特定信息的动态主机配置协议（DHCP）选项可能会受到限制或不明确。本文档定义了两个新选项，以供应商类别和供应商特定信息的IPv6选项为模型，其中包含企业编号以消除歧义。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions Used in This Document. . . . . . . . . . . . 2
2. Supporting Multiple Vendor Instances . . . . . . . . . . . . . 3
3. Vendor-Identifying Vendor Class Option . . . . . . . . . . . . 3
4. Vendor-Identifying Vendor-Specific Information Option . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . 8
8. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8
9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 9
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions Used in This Document. . . . . . . . . . . . 2
2. Supporting Multiple Vendor Instances . . . . . . . . . . . . . 3
3. Vendor-Identifying Vendor Class Option . . . . . . . . . . . . 3
4. Vendor-Identifying Vendor-Specific Information Option . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . 8
8. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8
9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 9
The DHCP protocol for IPv4, RFC 2131 [2], defines options that allow a client to indicate its vendor type (option 60), and the DHCP client and server to exchange vendor-specific information (option 43) [5]. Although there is no prohibition against passing multiple copies of these options in a single packet, doing so would introduce ambiguity of interpretation, particularly if conveying vendor-specific information for multiple vendors. The vendor identified by option 60 defines the interpretation of option 43, which itself carries no vendor identifier. Furthermore, the concatenation of multiple instances of the same option, required by RFC 2131 and specified by RFC 3396 [4], means that multiple copies of options 60 or 43 would not remain independent.
IPv4的DHCP协议RFC 2131[2]定义了允许客户端指示其供应商类型的选项（选项60），以及允许DHCP客户端和服务器交换供应商特定信息的选项（选项43）[5]。虽然没有禁止在单个数据包中传递这些选项的多个副本，但这样做会导致解释的模糊性，特别是在为多个供应商传递特定于供应商的信息时。选项60确定的供应商定义了选项43的解释，选项43本身没有供应商标识符。此外，RFC 2131要求并由RFC 3396[4]指定的同一选项的多个实例的串联意味着选项60或43的多个副本不会保持独立。
In some circumstances, an implementation may need to support multiple, independently defined forms of vendor-specific information. For example, implementations that must conform to an industry-standard use of DHCPv4, to allow interoperability in a particular technology space, may be required to support the vendor-specific options of that industry group. But the same implementation may also require support for vendor-specific options defined by the manufacturer. In particular, this is an issue for vendors of devices supporting CableLabs [9] standards, such as DOCSIS, CableHome, and PacketCable, as those standards define an industry-specific use for options 60 and 43.
在某些情况下，实现可能需要支持供应商特定信息的多种独立定义形式。例如，为了在特定技术领域实现互操作性，可能需要符合DHCPv4行业标准使用的实现来支持该行业组的特定于供应商的选项。但同样的实现也可能需要支持制造商定义的特定于供应商的选项。特别是，对于支持CableLabs[9]标准的设备供应商来说，这是一个问题，如DOCSIS、CableHome和PacketCable，因为这些标准定义了选项60和43的行业特定用途。
This document defines two new options, modeled on the IPv6 options for vendor class and vendor-specific information defined in RFC 3315 [6], that contain IANA-assigned Enterprise Numbers [3] to remove ambiguity about the interpretation of their contents. If desired, these new options can be used in addition to the current vendor class and vendor information options, whose definition is unaffected by this document.
本文档定义了两个新选项，以RFC 3315[6]中定义的供应商类别和供应商特定信息的IPv6选项为模型，其中包含IANA分配的企业编号[3]，以消除对其内容解释的歧义。如果需要，可以在当前供应商类别和供应商信息选项之外使用这些新选项，这些选项的定义不受本文档的影响。
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 BCP 14, RFC 2119 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[1]中的描述进行解释。
The options defined in this document may each contain data corresponding to more than one vendor. The data portion of each option defined here contains an enterprise number (assigned by IANA [3]), followed by an internal data length, followed by vendor-specific data. This sequence may be repeated multiple times within each option. Because the aggregate of the vendor-specific data for either option may exceed 255 octets, these options are hereby declared to be "concatenation-requiring", as defined by RFC 3396 [4]. As such, for each of the two options defined here, the aggregate of all instances of vendor-specific data is to be considered one long option. These long options can be divided into smaller options for packet encoding in conformance with RFC 3396, on whatever octet boundaries are convenient to the implementation. Dividing on the boundaries between vendor instances is not required but may be convenient for encoding or packet tracing.
本文件中定义的每个选项可能包含与多个供应商对应的数据。此处定义的每个选项的数据部分都包含一个企业编号（由IANA[3]分配），后跟一个内部数据长度，后跟特定于供应商的数据。此序列可在每个选项内重复多次。由于任一选项的供应商特定数据的总和可能超过255个八位字节，因此，根据RFC 3396[4]的定义，这些选项在此声明为“需要串联”。因此，对于此处定义的两个选项中的每一个，供应商特定数据的所有实例的集合将被视为一个长选项。这些长选项可分为更小的选项，用于符合RFC 3396的数据包编码，在任何便于实现的八位组边界上。不需要在供应商实例之间划分边界，但可能便于编码或数据包跟踪。
A DHCP client may use this option to unambiguously identify the vendor that manufactured the hardware on which the client is running, the software in use, or an industry consortium to which the vendor belongs. The information contained in the per-vendor data area of this option is contained in one or more opaque fields that may identify details of the hardware configuration.
DHCP客户端可以使用此选项明确标识制造客户端运行的硬件的供应商、正在使用的软件或供应商所属的行业联盟。此选项的每个供应商数据区域中包含的信息包含在一个或多个不透明字段中，这些字段可能标识硬件配置的详细信息。
This option may be used wherever Vendor Class Identifier (option 60) may be used, as described in RFC 2131 [2], except for DHCPNAK messages, where other options are not permitted. It is most meaningful in messages from DHCP client to DHCP server (DHCPDISCOVER, DHCPREQUEST, DHCPINFORM).
如RFC 2131[2]所述，此选项可用于任何可能使用供应商类别标识符（选项60）的地方，DHCPNAK消息除外，不允许使用其他选项。它在从DHCP客户端到DHCP服务器（DHCPDISCOVER、DHCPREQUEST、DHCPINFORM）的消息中最有意义。
The format of the V-I Vendor Class option is as follows:
V-I供应商类别选项的格式如下：
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| enterprise-number1 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data-len1 | |
+-+-+-+-+-+-+-+-+ |
/ vendor-class-data1 /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
| enterprise-number2 | ^
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| data-len2 | | optional
+-+-+-+-+-+-+-+-+ | |
/ vendor-class-data2 / |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ ... ~ V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| enterprise-number1 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data-len1 | |
+-+-+-+-+-+-+-+-+ |
/ vendor-class-data1 /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
| enterprise-number2 | ^
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| data-len2 | | optional
+-+-+-+-+-+-+-+-+ | |
/ vendor-class-data2 / |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ ... ~ V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
option-code OPTION_V-I_VENDOR_CLASS (124)
选项代码选项V-I供应商类别（124）
option-len total length of all following option data in octets
option len以下所有选项数据的总长度（以八位字节为单位）
enterprise-numberN The vendor's 32-bit Enterprise Number as registered with IANA [3]
企业编号供应商在IANA注册的32位企业编号[3]
data-lenN Length of vendor-class-data field
数据长度供应商类别数据字段的长度
vendor-class-dataN Details of the hardware configuration of the host on which the client is running, or of industry consortium compliance
供应商类数据：运行客户端的主机的硬件配置或行业联盟合规性的详细信息
This option contains information corresponding to one or more Enterprise Numbers. Multiple instances of this option may be present and MUST be concatenated in accordance with RFC 3396 [4]. An Enterprise Number SHOULD only occur once among all instances of this option. Behavior is undefined if an Enterprise Number occurs multiple times. The information for each Enterprise Number is treated independently, regardless or whether it occurs in an option with other Enterprise Numbers or in a separate option.
此选项包含与一个或多个企业编号对应的信息。此选项可能存在多个实例，必须按照RFC 3396[4]进行连接。在该选项的所有实例中，企业编号只能出现一次。如果企业编号出现多次，则行为未定义。每个企业编号的信息都是独立处理的，无论它是出现在与其他企业编号一起的选项中，还是出现在单独的选项中。
The vendor-class-data comprises a series of separate items, each of which describes some characteristic of the client's hardware configuration or capabilities. Examples of vendor-class-data instances might include the version of the operating system the client is running or the amount of memory installed on the client.
供应商类数据包括一系列单独的项目，每个项目描述客户机硬件配置或功能的一些特征。供应商类数据实例的示例可能包括客户端正在运行的操作系统版本或客户端上安装的内存量。
Each instance of the vendor-class-data is formatted as follows:
供应商类数据的每个实例的格式如下：
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data-len | |
+-+-+-+-+-+-+-+-+ opaque-data |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data-len | |
+-+-+-+-+-+-+-+-+ opaque-data |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The data-len is one octet long and specifies the length of the opaque vendor class data in network byte order.
数据len的长度为一个八位字节，以网络字节顺序指定不透明供应商类数据的长度。
DHCP clients and servers may use this option to exchange vendor-specific information. Either party may send this option, as needed. Although a typical case might be for a client to send the Vendor-Identifying Vendor Class option, to elicit a useful Vendor-Identifying Vendor-Specific Information Option, there is no requirement for such a flow.
DHCP客户端和服务器可以使用此选项交换特定于供应商的信息。任何一方均可根据需要发送此选项。虽然典型的情况可能是客户机发送供应商标识供应商类选项，以获取有用的供应商标识供应商特定信息选项，但不需要这样的流。
This option may be used in any packets where "other" options are allowed by RFC 2131 [2], specifically DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, DHCPACK, and DHCPINFORM.
此选项可用于RFC 2131[2]允许使用“其他”选项的任何数据包，特别是DHCPDISCOVER、DHCPOFFER、DHCPREQUEST、DHCPACK和DHCPINFORM。
The format of the V-I Vendor-specific Information option is as follows:
V-I供应商特定信息选项的格式如下：
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| enterprise-number1 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data-len1 | |
+-+-+-+-+-+-+-+-+ option-data1 |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
| enterprise-number2 | ^
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| data-len2 | | optional
+-+-+-+-+-+-+-+-+ option-data2 | |
/ / |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ ... ~ V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| enterprise-number1 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data-len1 | |
+-+-+-+-+-+-+-+-+ option-data1 |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
| enterprise-number2 | ^
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| data-len2 | | optional
+-+-+-+-+-+-+-+-+ option-data2 | |
/ / |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ ... ~ V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
option-code OPTION_V-I_VENDOR_OPTS (125)
选项代码选项V-I供应商选项（125）
option-len total length of all following option data in octets
option len以下所有选项数据的总长度（以八位字节为单位）
enterprise-numberN The vendor's registered 32-bit Enterprise Number as registered with IANA [3]
企业编号供应商在IANA注册的32位企业编号[3]
data-lenN Length of option-data field
数据长度选项数据字段的长度
option-dataN Vendor-specific options, described below
选项数据和供应商特定选项，如下所述
The definition of the information carried in this option is vendor specific. The vendor is indicated in the enterprise-number field. This option contains information corresponding to one or more Enterprise Numbers. Multiple instances of this option may be present and MUST be concatenated in accordance with RFC 3396 [4].
此选项中包含的信息的定义是特定于供应商的。供应商在“企业编号”字段中指明。此选项包含与一个或多个企业编号对应的信息。此选项可能存在多个实例，必须按照RFC 3396[4]进行连接。
An Enterprise Number SHOULD only occur once among all instances of this option. Behavior is undefined if an Enterprise Number occurs multiple times. The information for each Enterprise Number is treated independently, regardless or whether it occurs in an option with other Enterprise Numbers, or in a separate option.
在该选项的所有实例中，企业编号只能出现一次。如果企业编号出现多次，则行为未定义。每个企业编号的信息都是独立处理的，无论它是出现在与其他企业编号一起的选项中，还是出现在单独的选项中。
Use of vendor-specific information allows enhanced operation, utilizing additional features in a vendor's DHCP implementation. Servers not equipped to interpret the vendor-specific information sent by a client MUST ignore it. Clients that do not receive desired vendor-specific information SHOULD make an attempt to operate without it.
使用特定于供应商的信息可以增强操作，利用供应商DHCP实现中的附加功能。未配备解释客户发送的供应商特定信息的服务器必须忽略该信息。未收到所需供应商特定信息的客户应尝试在没有该信息的情况下进行操作。
The encapsulated vendor-specific option-data field MUST be encoded as a sequence of code/length/value fields of identical format to the DHCP options field. The option codes are defined by the vendor identified in the enterprise-number field and are not managed by IANA. Option codes 0 and 255 have no pre-defined interpretation or format. Each of the encapsulated options is formatted as follows:
封装的供应商特定选项数据字段必须编码为与DHCP选项字段格式相同的代码/长度/值字段序列。选项代码由企业编号字段中标识的供应商定义，不由IANA管理。选项代码0和255没有预定义的解释或格式。每个封装选项的格式如下所示：
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| subopt-code | subopt-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ sub-option-data /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| subopt-code | subopt-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ sub-option-data /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
subopt-code The code for the encapsulated option
subopt code封装选项的代码
subopt-len An unsigned integer giving the length of the option-data field in this encapsulated option in octets
subopt len一个无符号整数，给出此封装选项中选项数据字段的长度（以八位字节为单位）
sub-option-data Data area for the encapsulated option
封装选项的子选项数据区
The values for the OPTION_V-I_VENDOR_CLASS and OPTION_V-I_VENDOR_OPTS option codes have been assigned from the numbering space defined for public DHCP Options in RFC 2939 [7].
选项_V-I_VENDOR_类和选项_V-I_VENDOR_OPTS选项代码的值已从RFC 2939[7]中为公共DHCP选项定义的编号空间分配。
This document in and by itself provides no security, nor does it impact existing security. DHCP provides an authentication and message integrity mechanism, as described in RFC 3118 [8], which may be used if authenticity is required for data carried by the options defined in this document.
本文档本身不提供安全性，也不影响现有安全性。DHCP提供了一种身份验证和消息完整性机制，如RFC 3118[8]所述，如果本文档中定义的选项所携带的数据需要真实性，则可以使用该机制。
[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] IANA, "Private Enterprise Numbers", <http://www.iana.org/assignments/enterprise-numbers>.
[3] IANA，“私营企业编号”<http://www.iana.org/assignments/enterprise-numbers>.
[4] Lemon, T. and S. Cheshire, "Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, November 2002.
[4] Lemon，T.和S.Cheshire，“动态主机配置协议（DHCPv4）中的长选项编码”，RFC 3396，2002年11月。
[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., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[6] Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[7] Droms, R., "Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types", BCP 43, RFC 2939, September 2000.
[7] Droms，R.，“新DHCP选项和消息类型定义的程序和IANA指南”，BCP 43，RFC 2939，2000年9月。
[8] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.
[8] Droms，R.和W.Arbaugh，“DHCP消息的身份验证”，RFC31182001年6月。
URIs
URI
[9] <http://www.cablelabs.com/>
[9] <http://www.cablelabs.com/>
Josh Littlefield Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 USA
Josh Littlefield Cisco Systems，Inc.美国马萨诸塞州博克斯堡马萨诸塞大道1414号，邮编01719
Phone: +1 978-936-1379
EMail: joshl@cisco.com
Phone: +1 978-936-1379
EMail: joshl@cisco.com
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
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 IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关IETF文件中权利的IETF程序信息，请参见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编辑功能的资金目前由互联网协会提供。