Network Working Group T. Lemon
Request for Comments: 3396 Nominum, Inc.
Updates: 2131 S. Cheshire
Category: Standards Track Apple Computer, Inc.
November 2002
Network Working Group T. Lemon
Request for Comments: 3396 Nominum, Inc.
Updates: 2131 S. Cheshire
Category: Standards Track Apple Computer, Inc.
November 2002
Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)
在动态主机配置协议（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 (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This document specifies the processing rules for Dynamic Host Configuration Protocol (DHCPv4) options that appear multiple times in the same message. Multiple instances of the same option are generated when an option exceeds 255 octets in size (the maximum size of a single option) or when an option needs to be split apart in order to take advantage of DHCP option overloading. When multiple instances of the same option appear in the options, file and/or sname fields in a DHCP packet, the contents of these options are concatenated together to form a single option prior to processing.
本文档指定了在同一消息中多次出现的动态主机配置协议（DHCPv4）选项的处理规则。当一个选项的大小超过255个八位字节（单个选项的最大大小）或需要拆分一个选项以利用DHCP选项重载时，将生成同一选项的多个实例。当同一选项的多个实例出现在DHCP数据包中的选项、文件和/或sname字段中时，这些选项的内容将连接在一起，以在处理之前形成一个选项。
This document updates RFC 2131 [3] by clarifying the rules for option concatenation specified in section 4.1. It is expected that the reader will be familiar with this portion of RFC 2131. The text in section 4.1 that reads "Options may appear only once, unless otherwise specified in the options document." should be considered as deleted.
本文件通过澄清第4.1节中规定的选项连接规则更新了RFC 2131[3]。预计读者将熟悉RFC 2131的这一部分。第4.1节中的文本“选项只能出现一次，除非选项文件中另有规定。”应视为已删除。
The DHCP protocol [3] specifies objects called "options" that are encoded in the DHCPv4 packet to pass information between DHCP protocol agents. These options are encoded as a one-byte type code, a one-byte length, and a buffer consisting of the number of bytes specified in the length, from zero to 255.
DHCP协议[3]指定称为“选项”的对象，这些对象编码在DHCPv4数据包中，用于在DHCP协议代理之间传递信息。这些选项被编码为单字节类型代码、单字节长度和由长度中指定的字节数（从零到255）组成的缓冲区。
However, in some cases it may be useful to send options that are longer than 255 bytes. RFC 2131 [3] specifies that when more than one option with a given type code appears in the DHCP packet, all such options should be concatenated together. It does not, however, specify the order in which this concatenation should occur.
但是，在某些情况下，发送长度超过255字节的选项可能会很有用。RFC 2131[3]规定，当DHCP数据包中出现具有给定类型代码的多个选项时，所有此类选项都应连接在一起。但是，它没有指定这种连接的顺序。
We specify here the ordering that MUST be used by DHCP protocol agents when sending options with more than 255 bytes. This method also MUST be used for splitting options that are shorter than 255 bytes, if for some reason the encoding agent needs to do so. DHCP protocol agents MUST use this method whenever they receive a DHCP packet containing more than one occurrence of a certain type of option.
我们在这里指定DHCP协议代理在发送超过255字节的选项时必须使用的顺序。如果出于某种原因，编码代理需要拆分小于255字节的选项，则也必须使用此方法。DHCP协议代理在接收到包含某一类型选项的多次出现的DHCP数据包时必须使用此方法。
DHCP Throughout this document, the acronym "DHCP" is used to refer to the Dynamic Host Configuration Protocol as specified in RFC 2131 [3] and RFC 2132 [4].
DHCP在本文档中，首字母缩略词“DHCP”用于指RFC 2131[3]和RFC 2132[4]中规定的动态主机配置协议。
DHCPv4 We have used the term "DHCPv4" in the abstract for this document to distinguish between the DHCP protocol for IPv4 as defined in RFC 2131 and RFC 2132 and the DHCP protocol for IPv6, which, at the time that this document was written, was still under development.
DHCPv4我们在本文档摘要中使用了术语“DHCPv4”，以区分RFC 2131和RFC 2132中定义的IPv4 DHCP协议和IPv6 DHCP协议，在编写本文档时，后者仍在开发中。
DHCP protocol agents This refers to any device on the network that sends or receives DHCP packets - any DHCP client, server or relay agent. The nature of these devices is not important to this specification.
DHCP协议代理这是指网络上发送或接收DHCP数据包的任何设备—任何DHCP客户端、服务器或中继代理。这些设备的性质对本规范不重要。
Encoding agent The DHCP protocol agent that is composing a DHCP packet to send.
编码代理组成要发送的DHCP数据包的DHCP协议代理。
Decoding agent The DHCP protocol agent that is processing a DHCP packet it has received.
解码代理正在处理其收到的DHCP数据包的DHCP协议代理。
Options DHCP options are collections of data with type codes that indicate how the options should be used. Options can specify information that is required for the DHCP protocol, IP stack configuration parameters for the client, information allowing the client to rendezvous with DHCP servers, and so on.
选项DHCP选项是具有类型代码的数据集合，类型代码指示应如何使用这些选项。选项可以指定DHCP协议所需的信息、客户端的IP堆栈配置参数、允许客户端与DHCP服务器会合的信息，等等。
Option overload The DHCP packet format is based on the BOOTP packet format defined in RFC 951 [1]. When used by DHCP protocol agents, BOOTP packets have three fields that can contain options. These are the optional parameters field, the sname field, and the filename field. The DHCP options specification [4] defines the DHCP Overload option, which specifies which of these three fields is actually being used in any given DHCP message to store DHCP options.
选项重载DHCP数据包格式基于RFC 951[1]中定义的BOOTP数据包格式。当DHCP协议代理使用时，BOOTP数据包有三个字段，可以包含选项。这些是可选参数字段、sname字段和文件名字段。DHCP选项规范[4]定义了DHCP重载选项，该选项指定在任何给定DHCP消息中实际使用这三个字段中的哪一个来存储DHCP选项。
In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as described in BCP 14, RFC 2119 [2].
在本文件中，关键词“可能”、“必须”、“不得”、“可选”、“建议”、“应该”和“不应该”应按照BCP 14、RFC 2119[2]中的说明进行解释。
This specification applies when a DHCP agent is encoding a packet containing options, where some of those options must be broken into parts. This need can occur for two reasons. First, it can occur because the value of an option that needs to be sent is longer than 255 bytes. In this case, the encoding agent MUST follow the algorithm specified here. It can also occur because there is not sufficient space in the current output buffer to store the option, but there is space for part of the option, and there is space in another output buffer for the rest. In this case, the encoding agent MUST either use this algorithm or not send the option at all.
当DHCP代理对包含选项的数据包进行编码时，此规范适用，其中一些选项必须分解为多个部分。出现这种需要有两个原因。首先，可能是因为需要发送的选项的值长于255字节。在这种情况下，编码代理必须遵循此处指定的算法。也可能发生这种情况，因为当前输出缓冲区中没有足够的空间来存储选项，但有空间存储部分选项，而另一个输出缓冲区中有空间存储其余选项。在这种情况下，编码代理必须使用此算法或根本不发送选项。
This specification also applies in any case where a DHCP protocol agent has received a DHCP packet that contains more than one instance of an option of a given type. In this case, the agent MUST concatenate these separate instances of the same option in the way that we specify here.
本规范还适用于DHCP协议代理收到包含给定类型选项的多个实例的DHCP数据包的任何情况。在这种情况下，代理必须按照此处指定的方式连接同一选项的这些单独实例。
This option updates the Dynamic Host Configuration Protocol [3] and DHCP Options and BOOTP vendor extensions [4] documents. However, because many currently-deployed DHCP protocol agents do not implement option concatenation, DHCP protocol agents should be careful not to transmit split options unless either it will not matter if the recipient cannot correctly reassemble the options, or it is certain that the recipient implements concatenation.
此选项更新动态主机配置协议[3]和DHCP选项以及BOOTP供应商扩展[4]文档。但是，由于许多当前部署的DHCP协议代理未实现选项连接，DHCP协议代理应小心不要传输拆分选项，除非收件人无法正确重新组合选项无关紧要，或者确定收件人实现了连接。
Let us divide all DHCP options into two categories - those that, by definition, require implementation of the mechanisms defined in this document, and those that do not. We will refer to the former as concatenation-requiring options, and the latter as non-concatenation-requiring options. In order for an option to be a
让我们将所有DHCP选项分为两类——根据定义，需要实现本文档中定义的机制的选项和不需要实现的选项。我们将前者称为需要连接的选项，后者称为不需要连接的选项。为了使一个选项成为一个
concatenation-requiring option, the protocol specification that defines that option must require implementation of option splitting and option concatenation as described in this document, by specifically referencing this document.
需要连接选项，定义该选项的协议规范必须要求按照本文档中的说明，通过特别引用本文档来实现选项拆分和选项连接。
A DHCP protocol agent SHOULD NOT split an option as described in this document unless it has no choice, or it knows that its peer can properly handle split options. A peer is assumed to properly handle split options if it has provided or requested at least one concatenation-requiring option. Alternatively, the administrator of the agent generating the option can specifically configure the agent to assume that the recipient can correctly concatenate options split as described in this document.
DHCP协议代理不应按本文档所述拆分选项，除非它没有选择，或者它知道其对等方可以正确处理拆分选项。如果对等方提供或请求了至少一个需要连接的选项，则假定它能够正确处理拆分选项。或者，生成选项的代理的管理员可以专门配置代理，以假定收件人可以按照本文档中的说明正确连接拆分的选项。
Some implementors may find it easiest to only split concatenation-requiring options, and never split non-concatenation-requiring options. This is permissible. However, an implementation which supports any concatenation-requiring option MUST be capable of concatenating received options for both concatenation-requiring and non-concatenation-requiring options.
一些实现者可能会发现，只拆分需要连接的选项是最容易的，而从不拆分不需要连接的选项。这是允许的。但是，支持任何需要连接的选项的实现必须能够连接需要连接和不需要连接的选项的接收选项。
No restrictions apply to option concatenation when a DHCP agent receives a DHCP message. Any DHCP protocol agent that implements the mechanisms described in this document can assume that when it receives two options of the same type, it should concatenate them.
当DHCP代理收到DHCP消息时，选项连接不受任何限制。实现本文档中描述的机制的任何DHCP协议代理都可以假定，当它接收到相同类型的两个选项时，应该将它们连接起来。
DHCP options can be stored in the DHCP packet in three separate portions of the packet. These are the optional parameters field, the sname field, and the file field, as described in RFC 2131 [3]. This complicates the description of the option splitting mechanism because there are three separate fields into which split options may be placed.
DHCP选项可以存储在DHCP数据包的三个独立部分中。这些是可选参数字段、sname字段和文件字段，如RFC 2131[3]所述。这使得选项拆分机制的描述复杂化，因为拆分选项可以放置在三个单独的字段中。
To further complicate matters, an option that doesn't fit into one field can't overlap the boundary into another field - the encoding agent must instead break the option into two parts and store one part in each buffer.
使问题进一步复杂化的是，不适合一个字段的选项不能将边界重叠到另一个字段中——编码代理必须将该选项分成两部分，并在每个缓冲区中存储一部分。
To simplify this discussion, we will talk about an aggregate option buffer, which will be the aggregate of the three buffers. This is a logical aggregation - the buffers MUST appear in the locations in the DHCP packet described in RFC 2131 [3].
为了简化讨论，我们将讨论聚合选项缓冲区，它是三个缓冲区的聚合。这是一个逻辑聚合-缓冲区必须出现在RFC 2131[3]中描述的DHCP数据包中的位置。
The aggregate option buffer is made up of the optional parameters field, the file field, and the sname field, in that order.
聚合选项缓冲区按顺序由可选参数字段、文件字段和sname字段组成。
WARNING: This is not the physical ordering of these fields in the DHCP packet.
警告：这不是DHCP数据包中这些字段的物理顺序。
Options MUST NOT be stored in the aggregate option buffer in such a way that they cross either boundary between the three fields in the aggregate buffer.
选项在聚合选项缓冲区中的存储方式不得使其跨越聚合缓冲区中三个字段之间的任一边界。
The encoding agent is free to choose to use either or both the sname field and file field. If the encoding agent does not choose to use either or both of these two fields, then they MUST NOT be considered part of the aggregate option buffer in that case.
编码代理可以自由选择使用sname字段和文件字段中的一个或两个。如果编码代理不选择使用这两个字段中的一个或两个，则在这种情况下，它们不能被视为聚合选项缓冲区的一部分。
Encoding agents decide to split options based on the reasons we have described in the preceding section entitled "applicability".
编码代理根据我们在前一节“适用性”中描述的原因决定拆分选项。
Options can be split on any octet boundary. No split portion of an option that has been split can contain more than 255 octets. The split portions of the option MUST be stored in the aggregate option buffer in sequential order - the first split portion MUST be stored first in the aggregate option buffer, then the second portion, and so on. The encoding agent MUST NOT attempt to specify any semantic information based on how the option is split.
选项可以在任何八位组边界上拆分。已拆分的选项的拆分部分不能包含超过255个八位字节。选项的拆分部分必须按顺序存储在聚合选项缓冲区中-第一个拆分部分必须先存储在聚合选项缓冲区中，然后存储第二个部分，依此类推。编码代理不能尝试根据选项的拆分方式指定任何语义信息。
Note that because the aggregate option buffer does not represent the physical ordering of the DHCP packet, if an option were split into three parts and each part went into one of the possible option fields, the first part would go into the optional parameters field, the second part would go into the file field, and the third part would go into the sname field. This maintains consistency with section 4.1 of RFC 2131 [3].
请注意，由于聚合选项缓冲区并不表示DHCP数据包的物理顺序，因此，如果将一个选项分为三部分，并且每个部分进入一个可能的选项字段，则第一部分将进入可选参数字段，第二部分将进入文件字段，第三部分将进入sname领域。这与RFC 2131[3]第4.1节保持一致。
Each split portion of an option MUST be stored in the aggregate option buffer as if it were a normal variable-length option as described in RFC 2132 [4]. The length fields of each split portion of the option MUST add up to the total length of the option data. For any given option being split, the option code field in each split portion MUST be the same.
选项的每个分割部分必须存储在聚合选项缓冲区中，就像RFC 2132[4]中描述的普通可变长度选项一样。选项的每个分割部分的长度字段的总和必须等于选项数据的总长度。对于要拆分的任何给定选项，每个拆分部分中的选项代码字段必须相同。
When a decoding agent is scanning an incoming DHCP packet's option buffer and finds two or more options with the same option code, it MUST consider them to be split portions of an option as described in the preceding section.
当解码代理正在扫描传入的DHCP包的选项缓冲区并找到具有相同选项代码的两个或多个选项时，它必须认为它们是前面部分中描述的选项的分割部分。
In the case that a decoding agent finds a split option, it MUST treat the contents of that option as a single option, and the contents MUST be reassembled in the order that was described above under encoding agent behavior.
在解码代理发现拆分选项的情况下，它必须将该选项的内容视为单个选项，并且必须按照上述“编码代理行为”中描述的顺序重新组装内容。
The decoding agent should ensure that when the option's value is used, any alignment issues that are particular to the machine architecture on which the decoding agent is running are accounted for - there is no requirement that the encoding agent align the options in any particular way.
解码代理应确保在使用选项的值时，考虑解码代理运行的机器体系结构特有的任何对齐问题-不要求编码代理以任何特定方式对齐选项。
There is no semantic meaning to where an option is split - the encoding agent is free to split the option at any point, and the decoding agent MUST reassemble the split option parts into a single object, and MUST NOT treat each split portion of the option as a separate object.
拆分选项的位置没有语义含义-编码代理可以在任意点拆分选项，解码代理必须将拆分的选项部分重新组装为单个对象，并且不得将选项的每个拆分部分视为单独的对象。
Consider an option, Bootfile name (option code 67), with a value of "/diskless/foo". Normally, this would be encoded as a single option, as follows:
考虑一个选项，引导文件名（选项代码67），具有“/无盘/FoO”的值。通常，这将被编码为单个选项，如下所示：
+----+----+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 67 | 13 | / | d | i | s | k | l | e | s | s | / | f | o | o |
+----+----+---+---+---+---+---+---+---+---+---+---+---+---+---+
+----+----+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 67 | 13 | / | d | i | s | k | l | e | s | s | / | f | o | o |
+----+----+---+---+---+---+---+---+---+---+---+---+---+---+---+
If an encoding agent needed to split the option in order to fit it into the option buffer, it could encode it as two separate options, as follows, and store it in the aggregate option buffer in the following sequence:
如果编码代理需要拆分选项以将其放入选项缓冲区，则可以将其编码为两个单独的选项，如下所示，并按以下顺序将其存储在聚合选项缓冲区中：
+----+---+---+---+---+---+---+---+---+
| 67 | 7 | / | d | i | s | k | l | e |
+----+---+---+---+---+---+---+---+---+
+----+---+---+---+---+---+---+---+---+
| 67 | 7 | / | d | i | s | k | l | e |
+----+---+---+---+---+---+---+---+---+
+----+---+---+---+---+---+---+---+
| 67 | 6 | s | s | / | f | o | o |
+----+---+---+---+---+---+---+---+
+----+---+---+---+---+---+---+---+
| 67 | 6 | s | s | / | f | o | o |
+----+---+---+---+---+---+---+---+
This document raises no new security issues. Potential exposures to attack in the DHCP protocol are discussed in section 7 of the DHCP protocol specification [3] and in Authentication for DHCP Messages [5].
本文件没有提出新的安全问题。DHCP协议规范[3]第7节和DHCP消息的身份验证[5]中讨论了DHCP协议中可能存在的攻击风险。
Note that the authentication option itself can be split; in such cases implementations must be careful when setting the authentication field to zero (prior to generation or verification of the MAC) as it may be split across multiple options.
请注意，身份验证选项本身可以拆分；在这种情况下，实现在将身份验证字段设置为零（在生成或验证MAC之前）时必须小心，因为它可能会被分割到多个选项中。
[1] Croft, W. and J. Gilmore, "BOOTSTRAP PROTOCOL (BOOTP)", RFC 951, September 1985.
[1] Croft，W.和J.Gilmore，“引导协议（BOOTP）”，RFC 9511985年9月。
[2] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[3] Droms，R.，“动态主机配置协议”，RFC 2131，1997年3月。
[4] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[4] Alexander，S.和Droms，R.，“DHCP选项和BOOTP供应商扩展”，RFC 21321997年3月。
[5] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.
[5] Droms，R.和W.Arbaugh，“DHCP消息的身份验证”，RFC31182001年6月。
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
Ted Lemon Nominum, Inc. 2385 Bay Road Redwood City, CA 94043 USA
美国加利福尼亚州红木市海湾路2385号Ted Lemon Nominum公司，邮编94043
EMail: mellon@nominum.com
EMail: mellon@nominum.com
Stuart Cheshire Apple Computer, Inc. 1 Infinite Loop Cupertino California 95014 USA
Stuart Cheshire苹果电脑有限公司美国加利福尼亚州库珀蒂诺无限环路95014
Phone: +1 408 974 3207
EMail: rfc@stuartcheshire.org
Phone: +1 408 974 3207
EMail: rfc@stuartcheshire.org
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。