Internet Engineering Task Force (IETF) D. Hankins
Request for Comments: 7227 Google
BCP: 187 T. Mrugalski
Updates: 3315 M. Siodelski
Category: Best Current Practice ISC
ISSN: 2070-1721 S. Jiang
Huawei Technologies Co., Ltd.
S. Krishnan
Ericsson
May 2014
Internet Engineering Task Force (IETF) D. Hankins
Request for Comments: 7227 Google
BCP: 187 T. Mrugalski
Updates: 3315 M. Siodelski
Category: Best Current Practice ISC
ISSN: 2070-1721 S. Jiang
Huawei Technologies Co., Ltd.
S. Krishnan
Ericsson
May 2014
Guidelines for Creating New DHCPv6 Options
创建新DHCPv6选项的指南
Abstract
摘要
This document provides guidance to prospective DHCPv6 option developers to help them create option formats that are easily adoptable by existing DHCPv6 software. It also provides guidelines for expert reviewers to evaluate new registrations. This document updates RFC 3315.
本文档为潜在的DHCPv6选项开发人员提供指导，帮助他们创建现有DHCPv6软件易于采用的选项格式。它还为专家评审员评估新注册提供指导。本文件更新了RFC 3315。
Status of This Memo
关于下段备忘
This memo documents an Internet Best Current Practice.
本备忘录记录了互联网最佳实践。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关BCP的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7227.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7227.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. When to Use DHCPv6 . . . . . . . . . . . . . . . . . . . . . 5
4. General Principles . . . . . . . . . . . . . . . . . . . . . 5
5. Reusing Other Option Formats . . . . . . . . . . . . . . . . 6
5.1. Option with IPv6 Addresses . . . . . . . . . . . . . . . 7
5.2. Option with Single Flag (Boolean) . . . . . . . . . . . . 8
5.3. Option with IPv6 Prefix . . . . . . . . . . . . . . . . . 9
5.4. Option with 32-bit Integer Value . . . . . . . . . . . . 10
5.5. Option with 16-bit Integer Value . . . . . . . . . . . . 10
5.6. Option with 8-bit Integer Value . . . . . . . . . . . . . 11
5.7. Option with URI . . . . . . . . . . . . . . . . . . . . . 11
5.8. Option with Text String . . . . . . . . . . . . . . . . . 12
5.9. Option with Variable-Length Data . . . . . . . . . . . . 13
5.10. Option with DNS Wire Format Domain Name List . . . . . . 14
6. Avoid Conditional Formatting . . . . . . . . . . . . . . . . 15
7. Avoid Aliasing . . . . . . . . . . . . . . . . . . . . . . . 15
8. Choosing between an FQDN and an Address . . . . . . . . . . . 16
9. Encapsulated Options in DHCPv6 . . . . . . . . . . . . . . . 19
10. Additional States Considered Harmful . . . . . . . . . . . . 20
11. Configuration Changes Occur at Fixed Times . . . . . . . . . 21
12. Multiple Provisioning Domains . . . . . . . . . . . . . . . . 21
13. Chartering Requirements and Advice for Responsible Area
Directors . . . . . . . . . . . . . . . . . . . . . . . . . . 22
14. Considerations for Creating New Formats . . . . . . . . . . . 23
15. Option Size . . . . . . . . . . . . . . . . . . . . . . . . . 23
16. Singleton Options . . . . . . . . . . . . . . . . . . . . . . 24
17. Option Order . . . . . . . . . . . . . . . . . . . . . . . . 25
18. Relay Options . . . . . . . . . . . . . . . . . . . . . . . . 25
19. Clients Request Their Options . . . . . . . . . . . . . . . . 26
20. Transition Technologies . . . . . . . . . . . . . . . . . . . 26
21. Recommended Sections in the New Document . . . . . . . . . . 27
21.1. DHCPv6 Client Behavior Text . . . . . . . . . . . . . . 28
21.2. DHCPv6 Server Behavior Text . . . . . . . . . . . . . . 28
21.3. DHCPv6 Relay Agent Behavior Text . . . . . . . . . . . . 29
22. Should the New Document Update Existing RFCs? . . . . . . . . 29
23. Security Considerations . . . . . . . . . . . . . . . . . . . 29
24. Privacy Considerations . . . . . . . . . . . . . . . . . . . 31
25. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
26. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
26.1. Normative References . . . . . . . . . . . . . . . . . . 31
26.2. Informative References . . . . . . . . . . . . . . . . . 32
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. When to Use DHCPv6 . . . . . . . . . . . . . . . . . . . . . 5
4. General Principles . . . . . . . . . . . . . . . . . . . . . 5
5. Reusing Other Option Formats . . . . . . . . . . . . . . . . 6
5.1. Option with IPv6 Addresses . . . . . . . . . . . . . . . 7
5.2. Option with Single Flag (Boolean) . . . . . . . . . . . . 8
5.3. Option with IPv6 Prefix . . . . . . . . . . . . . . . . . 9
5.4. Option with 32-bit Integer Value . . . . . . . . . . . . 10
5.5. Option with 16-bit Integer Value . . . . . . . . . . . . 10
5.6. Option with 8-bit Integer Value . . . . . . . . . . . . . 11
5.7. Option with URI . . . . . . . . . . . . . . . . . . . . . 11
5.8. Option with Text String . . . . . . . . . . . . . . . . . 12
5.9. Option with Variable-Length Data . . . . . . . . . . . . 13
5.10. Option with DNS Wire Format Domain Name List . . . . . . 14
6. Avoid Conditional Formatting . . . . . . . . . . . . . . . . 15
7. Avoid Aliasing . . . . . . . . . . . . . . . . . . . . . . . 15
8. Choosing between an FQDN and an Address . . . . . . . . . . . 16
9. Encapsulated Options in DHCPv6 . . . . . . . . . . . . . . . 19
10. Additional States Considered Harmful . . . . . . . . . . . . 20
11. Configuration Changes Occur at Fixed Times . . . . . . . . . 21
12. Multiple Provisioning Domains . . . . . . . . . . . . . . . . 21
13. Chartering Requirements and Advice for Responsible Area
Directors . . . . . . . . . . . . . . . . . . . . . . . . . . 22
14. Considerations for Creating New Formats . . . . . . . . . . . 23
15. Option Size . . . . . . . . . . . . . . . . . . . . . . . . . 23
16. Singleton Options . . . . . . . . . . . . . . . . . . . . . . 24
17. Option Order . . . . . . . . . . . . . . . . . . . . . . . . 25
18. Relay Options . . . . . . . . . . . . . . . . . . . . . . . . 25
19. Clients Request Their Options . . . . . . . . . . . . . . . . 26
20. Transition Technologies . . . . . . . . . . . . . . . . . . . 26
21. Recommended Sections in the New Document . . . . . . . . . . 27
21.1. DHCPv6 Client Behavior Text . . . . . . . . . . . . . . 28
21.2. DHCPv6 Server Behavior Text . . . . . . . . . . . . . . 28
21.3. DHCPv6 Relay Agent Behavior Text . . . . . . . . . . . . 29
22. Should the New Document Update Existing RFCs? . . . . . . . . 29
23. Security Considerations . . . . . . . . . . . . . . . . . . . 29
24. Privacy Considerations . . . . . . . . . . . . . . . . . . . 31
25. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
26. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
26.1. Normative References . . . . . . . . . . . . . . . . . . 31
26.2. Informative References . . . . . . . . . . . . . . . . . 32
Most protocol developers ask themselves if a protocol will work, or work efficiently. These are important questions, but another less frequently considered question is whether the proposed protocol presents itself needless barriers to adoption by deployed software.
大多数协议开发人员都会问自己，协议是否有效。这些都是重要的问题，但另一个不常被考虑的问题是，提议的协议是否会给部署的软件的采用带来不必要的障碍。
DHCPv6 [RFC3315] software implementors are not merely faced with the task of handling a given option's format on the wire. The option must fit into every stage of the system's process, starting with the user interface used to enter the configuration up to the machine interfaces where configuration is ultimately consumed.
DHCPv6[RFC3315]软件实现者不仅仅面临在线处理给定选项格式的任务。该选项必须适合系统流程的每个阶段，从用于输入配置的用户界面开始，直到最终使用配置的机器界面。
Another frequently overlooked aspect of rapid adoption is whether the option requires operators to be intimately familiar with the option's internal format in order to use it. Most DHCPv6 software provides a facility for handling unknown options at the time of publication. The handling of such options usually needs to be manually configured by the operator. But, if doing so requires extensive reading (more than can be covered in a simple FAQ, for example), it inhibits adoption.
快速采用的另一个经常被忽视的方面是，该选项是否需要操作员非常熟悉该选项的内部格式才能使用它。大多数DHCPv6软件在发布时都提供了处理未知选项的功能。此类选项的处理通常需要由操作员手动配置。但是，如果这样做需要大量阅读（例如，一个简单的常见问题解答中无法涵盖的内容），那么它会阻止采用。
So, although a given solution would work, and might even be space, time, or aesthetically optimal, a given option is presented with a series of ever-worsening challenges to be adopted:
因此，尽管给定的解决方案可行，甚至可能在空间、时间或美学上都是最优的，但给定的方案面临着一系列不断恶化的挑战：
o If it doesn't fit neatly into existing configuration files.
o 如果它不适合现有的配置文件。
o If it requires source code changes to be adopted and, hence, upgrades of deployed software.
o 如果需要对源代码进行更改，从而需要升级已部署的软件。
o If it does not share its deployment fate in a general manner with other options, standing alone in requiring code changes or reworking configuration file syntaxes.
o 如果它不以一般方式与其他选项共享其部署命运，则需要单独更改代码或修改配置文件语法。
o If the option would work well in the particular deployment environment the proponents currently envision, but it has equally valid uses in some other environment where the proposed option format would fail or would produce inconsistent results.
o 如果该选项在倡议者目前设想的特定部署环境中运行良好，但在某些其他环境中也同样有效，在这些环境中，建议的选项格式将失败或产生不一致的结果。
There are many things DHCPv6 option creators can do to avoid the pitfalls in this list entirely, or failing that, to make software implementors' lives easier and improve its chances for widespread adoption.
DHCPv6选项创建者可以做很多事情来完全避免这个列表中的陷阱，或者如果没有做到这一点，可以使软件实现者的生活更加轻松，并提高其被广泛采用的机会。
This document is envisaged as a help for protocol developers that define new options and for expert reviewers that review submitted proposals.
本文件旨在帮助定义新选项的协议开发人员和审查提交提案的专家评审员。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Principally, DHCPv6 carries configuration parameters for its clients. Any knob, dial, slider, or checkbox on the client system, such as "my domain name servers", "my hostname", or even "my shutdown temperature", are candidates for being configured by DHCPv6.
DHCPv6主要为其客户机提供配置参数。客户机系统上的任何旋钮、拨号盘、滑块或复选框，例如“我的域名服务器”、“我的主机名”，甚至“我的关机温度”，都可以由DHCPv6进行配置。
The presence of such a knob isn't enough, because DHCPv6 also presents the extension of an administrative domain -- the operator of the network to which the client is currently attached. Someone runs not only the local switching network infrastructure to which the client is directly (or wirelessly) attached but the various methods of accessing the external Internet via local assist services that the network must also provide (such as domain name servers or routers). This means that, even if a configuration parameter can be potentially delivered by DHCPv6, it is necessary to evaluate whether it is reasonable for this parameter to be under the control of the administrator of whatever network a client is attached to at any given time.
这种旋钮的存在是不够的，因为DHCPv6还提供了管理域的扩展——客户端当前连接到的网络的运营商。有人不仅运行客户端直接（或无线）连接的本地交换网络基础设施，还运行通过网络必须提供的本地辅助服务（如域名服务器或路由器）访问外部互联网的各种方法。这意味着，即使配置参数可能由DHCPv6交付，也有必要评估在任何给定时间由客户端连接到的任何网络的管理员控制该参数是否合理。
Note that the client is not required to configure any of these values received via DHCPv6 (e.g., due to having these values locally configured by its own administrator). But, it needs to be noted that overriding DHCPv6-provided values may cause the client to be denied certain services in the network to which it has attached. The possibility of having a higher level of control over client node configuration is one of the reasons that DHCPv6 is preferred in enterprise networks.
注意，客户机不需要配置通过DHCPv6接收的任何这些值（例如，由于这些值由其自己的管理员在本地配置）。但是，需要注意的是，覆盖DHCPv6提供的值可能会导致客户端在其所连接的网络中拒绝某些服务。对客户端节点配置具有更高级别控制的可能性是企业网络中首选DHCPv6的原因之一。
The primary guiding principle to follow in order to enhance an option's adoptability is reuse. The option should be created in such a way that does not require any new or special case software to support. If old software that is currently deployed and in the field can adopt the option through supplied configuration facilities, then it's fairly certain that new software can formally adopt it easily.
为了提高选项的可采纳性，需要遵循的主要指导原则是重用。该选项应以不需要任何新的或特殊情况软件支持的方式创建。如果当前部署和现场的旧软件可以通过提供的配置设施采用该选项，那么新软件可以很容易地正式采用该选项是相当确定的。
There are at least two classes of DHCPv6 options: simple options, which are provided explicitly to carry data from one side of the DHCPv6 exchange to the other (such as name servers, domain names, or time servers), and a protocol class of options, which require special
至少有两类DHCPv6选项：简单选项（明确提供用于将数据从DHCPv6交换的一端传送到另一端（例如名称服务器、域名或时间服务器））和协议类选项（需要特殊的
processing on the part of the DHCPv6 software or are used during special processing (such as the Fully Qualified Domain Name (FQDN) option [RFC4704]), and so forth; these options carry data that is the result of a routine in some DHCPv6 software.
DHCPv6软件部分的处理或在特殊处理期间使用的处理（例如完全限定域名（FQDN）选项[RFC4704]），等等；这些选项携带的数据是某些DHCPv6软件中例行程序的结果。
The guidelines laid out here should be applied in a relaxed manner for the protocol class of options. Wherever a special case code is already required to adopt the DHCPv6 option, it is substantially more reasonable to format the option in a less generic fashion, if there are measurable benefits to doing so.
此处列出的指南应以宽松的方式应用于协议类选项。如果采用DHCPv6选项已经需要特殊情况代码，那么以不太通用的方式设置选项的格式就更为合理，如果这样做有可测量的好处的话。
The easiest approach to manufacturing trivially deployable DHCPv6 options is to assemble the option out of whatever common fragments fit, possibly allowing a group of data elements to repeat to fill the remaining space (if present) and thus provide multiple values. Place all fixed-size values at the start of the option and any variable -/indeterminate-sized values at the tail end of the option.
制造可轻松部署的DHCPv6选项的最简单方法是使用任何合适的公共片段组装选项，可能允许一组数据元素重复以填充剩余空间（如果存在），从而提供多个值。将所有固定大小的值放在选项的开头，将所有可变/不确定大小的值放在选项的结尾。
This means that implementations will likely be able to reuse code paths designed to support the other options.
这意味着实现可能能够重用设计用于支持其他选项的代码路径。
There is a trade-off between the adoptability of previously defined option formats and the advantages that new or specialized formats can provide. In general, it is usually preferable to reuse previously used option formats.
在以前定义的期权格式的可采用性和新的或专门的格式可以提供的优势之间存在权衡。通常，最好重用以前使用的选项格式。
However, it isn't very practical to consider the bulk of DHCPv6 options already allocated and to consider which of those solve a similar problem. So, the following list of common option format data elements is provided as shorthand. Please note that it is not complete in terms of exampling every option format ever devised.
然而，考虑已经分配的大部分DHCPv6选项并考虑其中的哪一个解决类似问题是不太实际的。因此，以下通用选项格式数据元素列表作为简写提供。请注意，在举例说明曾经设计的每个选项格式方面，它并不完整。
If more complex options are needed, those basic formats mentioned here may be considered as primitives (or 'fragment types') that can be used to build more complex formats. It should be noted that it is often easier to implement two options with trivial formats than one option with a more complex format. That is not an unconditional requirement though. In some cases, splitting one complex option into two or more simple options introduces inter-option dependencies that should be avoided. In such a case, it is usually better to keep one complex option.
如果需要更复杂的选项，这里提到的那些基本格式可以被视为原语（或“片段类型”），可以用来构建更复杂的格式。应该注意的是，使用普通格式实现两个选项通常比使用更复杂格式实现一个选项更容易。但这并不是一个无条件的要求。在某些情况下，将一个复杂选项拆分为两个或多个简单选项会引入应避免的选项间依赖关系。在这种情况下，通常最好保留一个复杂的选项。
This option format is used to carry one or many IPv6 addresses. In some cases, the number of allowed addresses is limited (e.g., to one):
此选项格式用于承载一个或多个IPv6地址。在某些情况下，允许的地址数量是有限的（例如，一个）：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ipv6-address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ipv6-address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ipv6-address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ipv6-address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Option with IPv6 Addresses
图1：具有IPv6地址的选项
Examples of use:
使用示例：
o DHCPv6 Server Unicast Address [RFC3315] (a single address only)
o DHCPv6服务器单播地址[RFC3315]（仅限单个地址）
o Session Initiation Protocol (SIP) Servers IPv6 Address List [RFC3319]
o 会话启动协议（SIP）服务器IPv6地址列表[RFC3319]
o DNS Recursive Name Servers [RFC3646]
o DNS递归名称服务器[RFC3646]
o Network Information Service (NIS) Servers [RFC3898]
o 网络信息服务（NIS）服务器[RFC3898]
o Simple Network Time Protocol (SNTP) Servers [RFC4075]
o 简单网络时间协议（SNTP）服务器[RFC4075]
o Broadcast and Multicast Service Controller IPv6 Address Option for DHCPv6 [RFC4280]
o DHCPv6[RFC4280]的广播和多播服务控制器IPv6地址选项
o Mobile IPv6 (MIPv6) Home Agent Address [RFC6610] (a single address only)
o 移动IPv6（MIPv6）归属代理地址[RFC6610]（仅限单个地址）
o Network Time Protocol (NTP) Server Address [RFC5908] (a single address only)
o 网络时间协议（NTP）服务器地址[RFC5908]（仅限单个地址）
o NTP Multicast Address [RFC5908] (a single address only)
o NTP多播地址[RFC5908]（仅限单个地址）
Sometimes, it is useful to convey a single flag that can take either on or off values. Instead of specifying an option with 1 bit of usable data and 7 bits of padding, it is better to define an option without any content. It is the presence or absence of the option that conveys the value. This approach has the additional benefit of the absent option designating the default; that is, the administrator has to take explicit actions to deploy the opposite of the default value.
有时，传递一个可以接受on或off值的单一标志非常有用。与其指定一个包含1位可用数据和7位填充的选项，不如定义一个没有任何内容的选项。是期权的存在或不存在传达了价值。这种方法还有另外一个好处，即指定违约的缺席期权；也就是说，管理员必须采取与默认值相反的显式操作来部署。
The absence of the option represents the default value, and the presence of the option represents the other value, but that does not necessarily mean that absence is "off" (or "false") and presence is "on" (or "true"). That is, if it's desired that the default value for a bistable option is "true"/"on", then the presence of that option would turn it off (make it false). If the option presence signifies an off/false state, that should be reflected in the option name, e.g., OPTION_DISABLE_FOO.
不存在该选项表示默认值，存在该选项表示另一个值，但这并不一定意味着不存在是“关闭”（或“假”）而存在是“打开”（或“真”）。也就是说，如果希望双稳态选项的默认值为“true”/“on”，则该选项的存在会将其关闭（使其为false）。如果选项的存在表示关闭/错误状态，则应反映在选项名称中，例如，选项\u禁用\u FOO。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Option for Conveying Boolean
图2：用于传输布尔值的选项
Examples of use:
使用示例：
o DHCPv6 Rapid Commit [RFC3315]
o DHCPv6快速提交[RFC3315]
Sometimes, there is a need to convey an IPv6 prefix. The information to be carried by such an option includes the 128-bit IPv6 prefix together with a length of this prefix taking values from 0 to 128. Using the simplest approach, the option could convey this data in two fixed-length fields: one carrying the prefix length and another carrying the prefix. However, in many cases, /64 or shorter prefixes are used. This implies that the large part of the prefix data carried by the option would have its bits set to 0 and would be unused. In order to avoid carrying unused data, it is recommended to store the prefix in the variable-length data field. The appropriate option format is defined as follows:
有时，需要传递IPv6前缀。该选项携带的信息包括128位IPv6前缀以及该前缀的长度，取值范围为0到128。使用最简单的方法，该选项可以在两个固定长度的字段中传输此数据：一个带有前缀长度，另一个带有前缀。但是，在许多情况下，使用/64或更短的前缀。这意味着该选项携带的大部分前缀数据将其位设置为0，并且未使用。为了避免携带未使用的数据，建议将前缀存储在可变长度数据字段中。适当的选项格式定义如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| prefix6len | ipv6-prefix |
+-+-+-+-+-+-+-+-+ (variable length) |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| prefix6len | ipv6-prefix |
+-+-+-+-+-+-+-+-+ (variable length) |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Option with IPv6 Prefix
图3：带有IPv6前缀的选项
option-length is set to 1 + length of the IPv6 prefix.
选项长度设置为IPv6前缀的1+长度。
prefix6len is 1 octet long and specifies the length in bits of the IPv6 prefix. Typically allowed values are 0 to 128.
prefix6len的长度为1个八位字节，并以位为单位指定IPv6前缀的长度。通常允许的值为0到128。
The ipv6-prefix field is a variable-length field that specifies the IPv6 prefix. The length is (prefix6len + 7) / 8. This field is padded with 0 bits up to the nearest octet boundary when prefix6len is not divisible by 8.
ipv6前缀字段是指定ipv6前缀的可变长度字段。长度为（prefix6len+7）/8。当prefix6len不能被8整除时，此字段用0位填充到最近的八位字节边界。
Examples of use:
使用示例：
o Default Mapping Rule [MAP]
o 默认映射规则[映射]
For example, the prefix 2001:db8::/60 would be encoded with an option-length of 9, prefix6-len would be set to 60, and the ipv6-prefix would be 8 octets and would contain octets 20 01 0d b8 00 00 00 00.
例如，前缀2001:db8:：/60将使用选项长度9进行编码，prefix6 len将设置为60，ipv6前缀将为8个八位字节，并包含八位字节20 01 0d b8 00。
It should be noted that the IAPREFIX option defined by [RFC3633] uses a full-length 16-octet prefix field. The concern about option length was not well understood at the time of its publication.
应该注意的是，[RFC3633]定义的IAPREFIX选项使用全长16八位字节前缀字段。关于期权长度的担忧在其出版时没有得到很好的理解。
This option format can be used to carry a 32-bit signed or unsigned integer value:
此选项格式可用于携带32位有符号或无符号整数值：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit-integer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit-integer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Option with 32-bit Integer Value
图4：具有32位整数值的选项
Examples of use:
使用示例：
o Information Refresh Time [RFC4242]
o 信息刷新时间[RFC4242]
This option format can be used to carry 16-bit signed or unsigned integer values:
此选项格式可用于携带16位有符号或无符号整数值：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 16-bit-integer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 16-bit-integer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Option with 16-bit Integer Value
图5：具有16位整数值的选项
Examples of use:
使用示例：
o Elapsed Time [RFC3315]
o 运行时间[RFC3315]
This option format can be used to carry 8-bit integer values:
此选项格式可用于携带8位整数值：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8-bit-integer |
+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8-bit-integer |
+-+-+-+-+-+-+-+-+
Figure 6: Option with 8-bit Integer Value
图6：具有8位整数值的选项
Examples of use:
使用示例：
o DHCPv6 Preference [RFC3315]
o DHCPv6首选项[RFC3315]
A Uniform Resource Identifier (URI) [RFC3986] is a compact sequence of characters that identifies an abstract or physical resource. The term "Uniform Resource Locator" (URL) refers to the subset of URIs that, in addition to identifying a resource, provide a means of locating the resource by describing its primary access mechanism (e.g., its network "location"). This option format can be used to carry a single URI:
统一资源标识符（URI）[RFC3986]是一个紧凑的字符序列，用于标识抽象资源或物理资源。术语“统一资源定位器”（URL）是指URI的子集，其除了标识资源之外，还通过描述其主要访问机制（例如，其网络“位置”）提供定位资源的方法。此选项格式可用于携带单个URI：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. URI (variable length) .
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. URI (variable length) .
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Option with URI
图7：带有URI的选项
Examples of use:
使用示例：
o Boot File URL [RFC5970]
o 启动文件URL[RFC5970]
An alternate encoding to support multiple URIs is available. An option must be defined to use either the single URI format above or the multiple URI format below depending on whether a single URI is always sufficient or if multiple URIs are possible.
可以使用支持多个URI的替代编码。必须定义一个选项来使用上面的单个URI格式或下面的多个URI格式，这取决于单个URI是否总是足够，或者是否可以使用多个URI。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. uri-data .
. . . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. uri-data .
. . . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Option with Multiple URIs
图8：具有多个URI的选项
Each instance of the uri-data is formatted as follows:
uri数据的每个实例的格式如下：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
| uri-len | URI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
| uri-len | URI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
The uri-len is 2 octets long and specifies the length of the URI data. Although the URI format in theory supports up to 64 KB of data, in practice, large chunks of data may be problematic. See Section 15 for details.
uri len的长度为2个八位字节，并指定uri数据的长度。虽然URI格式在理论上支持高达64KB的数据，但在实践中，大块数据可能会有问题。详情见第15节。
A text string is a sequence of characters that have no semantics. The encoding of the text string MUST be specified. Unless otherwise specified, all text strings in newly defined options are expected to be Unicode strings that are encoded using UTF-8 [RFC3629] in Net-Unicode form [RFC5198]. Please note that all strings containing only 7-bit ASCII characters are also valid UTF-8 Net-Unicode strings.
文本字符串是没有语义的字符序列。必须指定文本字符串的编码。除非另有规定，新定义的选项中的所有文本字符串都应为Unicode字符串，这些字符串使用净Unicode格式[RFC5198]的UTF-8[RFC3629]进行编码。请注意，所有仅包含7位ASCII字符的字符串也是有效的UTF-8净Unicode字符串。
If a data format has semantics other than just being text, it is not a string; e.g., an FQDN is not a string, and a URI is also not a string because they have different semantics. A string must not include any terminator (such as a null byte). The null byte is treated as any other character and does not have any special meaning. This option format can be used to carry a text string:
如果数据格式的语义不仅仅是文本，它不是字符串；e、 例如，FQDN不是字符串，URI也不是字符串，因为它们具有不同的语义。字符串不得包含任何终止符（如空字节）。空字节被视为任何其他字符，没有任何特殊含义。此选项格式可用于携带文本字符串：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. String .
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. String .
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Option with Text String
图9：带有文本字符串的选项
Examples of use:
使用示例：
o Timezone Options for DHCPv6 [RFC4833]
o DHCPv6的时区选项[RFC4833]
An alternate encoding to support multiple text strings is available. An option must be defined to use either the single text string format above or the multiple text string format below, depending on whether a single text string is always sufficient or if multiple text strings are possible.
支持多个文本字符串的替代编码可用。必须定义一个选项，以使用上面的单个文本字符串格式或下面的多个文本字符串格式，这取决于单个文本字符串是否始终足够或是否可以使用多个文本字符串。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. text-data .
. . . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. text-data .
. . . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Option with Multiple Text Strings
图10：具有多个文本字符串的选项
Each instance of the text-data is formatted as follows:
文本数据的每个实例的格式如下：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
| text-len | String |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
| text-len | String |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
The text-len is 2 octets long and specifies the length of the string.
文本len的长度为2个八位字节，并指定字符串的长度。
This option can be used to carry variable-length data of any kind. Internal representation of carried data is option specific. Whenever this format is used by the new option being defined, the data encoding should be documented.
此选项可用于携带任何类型的可变长度数据。携带数据的内部表示是特定于选项的。当定义的新选项使用此格式时，应记录数据编码。
This option format provides a lot of flexibility to pass data of almost any kind. Though, whenever possible, it is highly recommended to use more specialized options, with field types better matching carried data types.
此选项格式为传递几乎任何类型的数据提供了很大的灵活性。不过，只要有可能，强烈建议使用更专门的选项，字段类型可以更好地匹配所携带的数据类型。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. variable-length data .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. variable-length data .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Option with Variable-Length Data
图11：具有可变长度数据的选项
Examples of use:
使用示例：
o Client Identifier [RFC3315]
o 客户端标识符[RFC3315]
o Server Identifier [RFC3315]
o 服务器标识符[RFC3315]
This option is used to carry 'domain search' lists or any host or domain name. It uses the same format as described in Section 5.9 but with the special data encoding, as described in Section 8 of [RFC3315]. This data encoding supports carrying multiple instances of hosts or domain names in a single option by terminating each instance with the byte value of 0.
此选项用于携带“域搜索”列表或任何主机或域名。它使用与第5.9节所述相同的格式，但具有特殊数据编码，如[RFC3315]第8节所述。此数据编码通过以字节值0终止每个实例，支持在单个选项中承载主机或域名的多个实例。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DNS Wire Format Domain Name List |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DNS Wire Format Domain Name List |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Option with DNS Wire Format Domain Name List
图12：带有DNS Wire格式域名列表的选项
Examples of use:
使用示例：
o SIP Servers Domain Name List [RFC3319] (many domains)
o SIP服务器域名列表[RFC3319]（多个域）
o NIS Domain Name [RFC3898] (many domains)
o NIS域名[RFC3898]（多个域）
o Location-to-Service Translation (LoST) Server Domain Name [RFC5223]
o 位置到服务转换（丢失）服务器域名[RFC5223]
o Location Information Server (LIS) Domain Name [RFC5986]
o 位置信息服务器（LIS）域名[RFC5986]
o Dual-Stack Lite (DS-Lite) Address Family Transition Router (AFTR) Location [RFC6334] (a single FQDN)
o 双栈Lite（DS Lite）地址系列转换路由器（AFTR）位置[RFC6334]（单个FQDN）
o Home Network Identifier [RFC6610] (a single FQDN)
o 家庭网络标识符[RFC6610]（单个FQDN）
o Home Agent FQDN [RFC6610] (a single FQDN)
o 归属代理FQDN[RFC6610]（单个FQDN）
Placing an octet at the start of the option that informs the software how to process the remaining octets of the option may appear simple to the casual observer. But, the only conditional formatting methods that are in widespread use today are 'protocol' class options. Therefore, conditional formatting requires new code to be written and complicates future interoperability should new conditional formats be added; existing code has to ignore conditional formats that it does not support.
在选项开始处放置一个八位字节，通知软件如何处理选项的剩余八位字节，对于临时观察者来说可能很简单。但是，目前广泛使用的唯一条件格式方法是“协议”类选项。因此，条件格式要求编写新代码，如果添加新的条件格式，则会使未来的互操作性变得复杂；现有代码必须忽略它不支持的条件格式。
Options are said to be aliases of each other if they provide input to the same configuration parameter. A commonly proposed example is to configure the location of some new service ("my foo server") using a binary IP address, a domain name field, and a URL. This kind of aliasing is undesirable and is not recommended.
如果选项为同一配置参数提供输入，则称它们为彼此的别名。一个常见的示例是使用二进制IP地址、域名字段和URL配置一些新服务（“my foo server”）的位置。这种别名是不可取的，不建议使用。
In this case, where three different formats are supposed, it more than triples the work of the software involved, requiring support for not merely one format but support to produce and digest all three. Furthermore, code development and testing must cover all possible combinations of defined formats. Since clients cannot predict what values the server will provide, they must request all formats. So, in the case where the server is configured with all formats, DHCPv6 message bandwidth is wasted on option contents that are redundant. Also, the DHCPv6 option number space is wasted, as three new option codes are required rather than one.
在这种情况下，如果假设有三种不同的格式，那么所涉及的软件工作将增加三倍多，不仅需要支持一种格式，还需要支持生成和消化所有三种格式。此外，代码开发和测试必须涵盖定义格式的所有可能组合。由于客户端无法预测服务器将提供什么值，因此必须请求所有格式。因此，在服务器配置为所有格式的情况下，DHCPv6消息带宽浪费在冗余的选项内容上。此外，DHCPv6选项编号空间被浪费，因为需要三个新选项代码，而不是一个。
It also becomes unclear which types of values are mandatory and how configuring some of the options may influence the others. For example, if an operator configures the URL only, should the server synthesize a domain name and an IP address?
还不清楚哪些类型的值是强制性的，以及配置某些选项如何影响其他选项。例如，如果操作员仅配置URL，服务器是否应合成域名和IP地址？
A single configuration value on a host is probably presented to the operator (or other software on the machine) in a single field or channel. If that channel has a natural format, then any alternative formats merely make more work for intervening software in providing conversions.
主机上的单个配置值可能在单个字段或通道中呈现给操作员（或机器上的其他软件）。如果该频道有一种自然格式，那么任何替代格式都只会使介入软件在提供转换时做更多的工作。
So, the best advice is to choose the one method that best fulfills the requirements for simplicity (such as with an IP address and a port pair), late binding (such as with DNS), or completeness (such as with a URL).
因此，最好的建议是选择一种最能满足简单性（如IP地址和端口对）、后期绑定（如DNS）或完整性（如URL）要求的方法。
Some parameters may be specified as an FQDN or an address. In most cases, one or the other should be used. This section discusses pros and cons of each approach and is intended to help make an informed decision in that regard. It is strongly discouraged to define both option types at the same time (see Section 7), unless there is sufficient motivation to do so.
某些参数可以指定为FQDN或地址。在大多数情况下，应使用其中一种。本节讨论每种方法的优缺点，旨在帮助在这方面做出明智的决定。强烈反对同时定义两种选项类型（见第7节），除非有足够的动机这样做。
There is no single recommendation that works for every case. It very much depends on the nature of the parameter being configured. For parameters that are network specific or represent certain aspects of network infrastructure, like available mobility services, in most cases addresses are a more usable choice. For parameters that can be considered an application-specific configuration, like SIP servers, it is usually better to use an FQDN.
没有一条建议适用于所有情况。这在很大程度上取决于所配置参数的性质。对于特定于网络或代表网络基础设施某些方面的参数，如可用的移动服务，在大多数情况下，地址是一个更有用的选择。对于可以被视为特定于应用程序的配置的参数，如SIP服务器，通常最好使用FQDN。
Applications are often better suited to deal with FQDN failures than with address failures. Most operating systems provide a way to retry an FQDN resolution if the previous attempt fails. That type of error recovery is supported by a great number of applications. On the other hand, there is typically no API available for applications to reconfigure over DHCP to get a new address value if the one received is no longer appropriate. This problem may be usually addressed by providing a list of addresses rather than just a single one. That, on the other hand, requires a defined procedure on how multiple addresses should be used (all at once, round robin, try first and fail over to the next if it fails, etc.).
应用程序通常比地址故障更适合处理FQDN故障。大多数操作系统都提供了一种在前一次尝试失败时重试FQDN解析的方法。许多应用程序都支持这种类型的错误恢复。另一方面，如果接收到的地址值不再合适，则通常没有API可供应用程序通过DHCP重新配置以获取新地址值。这个问题通常可以通过提供一个地址列表而不仅仅是一个地址列表来解决。另一方面，这需要一个关于如何使用多个地址的定义过程（一次使用，循环，先尝试，如果失败，则故障转移到下一个，等等）。
An FQDN provides a higher level of indirection and ambiguity. In many cases, that may be considered a benefit, but it can be considered a flaw in others. For example, one operator suggested that the same name be resolved to different addresses, depending on the point of attachment of the host doing the resolution. This is one way to provide localized addressing. However, in order to do this, it is necessary to violate the DNS convention that a query on a particular name should always return the same answer (aside from the
FQDN提供了更高级别的间接性和模糊性。在许多情况下，这可能被认为是一种好处，但也可能被认为是其他方面的缺陷。例如，一位操作员建议将相同的名称解析为不同的地址，具体取决于执行解析的主机的连接点。这是提供本地化寻址的一种方法。但是，为了做到这一点，有必要违反DNS约定，即对特定名称的查询应始终返回相同的答案（除了
ordering of IP addresses in the response, which is supposed to be varied by the name server). This same locality of reference for configuration information can be achieved directly using DHCP, since the DHCP server must know the network topology in order to provide IP address or prefix configuration.
响应中IP地址的顺序，应根据名称（服务器）进行更改。由于DHCP服务器必须知道网络拓扑才能提供IP地址或前缀配置，因此可以直接使用DHCP实现配置信息的相同参考位置。
The other type of ambiguity is related to multiple provisioning domains (see Section 12). The stub resolver on the DHCP client cannot at present be assumed to make the DNS query for a DHCP-supplied FQDN on the same interface on which it received its DHCP configuration and may, therefore, get a different answer from the DNS than was intended.
另一种类型的歧义与多个供应域有关（参见第12节）。目前无法假设DHCP客户端上的存根解析器在接收DHCP配置的同一接口上对DHCP提供的FQDN进行DNS查询，因此可能从DNS获得与预期不同的答案。
This is particularly a problem when the normal expected use of the option makes sense with a private DNS zone(s), as might be the case on an enterprise network. It may also be the case that the client has an explicit DNS server configured and may, therefore, never query the enterprise network's internal DNS server.
当正常预期使用该选项对专用DNS区域有意义时，这尤其是一个问题，在企业网络上可能就是这样。也可能是客户端配置了显式DNS服务器，因此可能永远不会查询企业网络的内部DNS服务器。
An FQDN does require a resolution into an actual address. This implies the question as to when the FQDN resolution should be conducted. There are a couple of possible answers: a) by the server, when it is started, b) by the server, when it is about to send an option, c) by the client, immediately after receiving an option, and d) by the client, when the content of the option is actually consumed. For a), b), and possibly c), the option should really convey an address, not an FQDN. The only real incentive to use an FQDN is case d). It is the only case that allows possible changes in the DNS to be picked up by clients.
FQDN确实需要解析为实际地址。这意味着应在何时进行FQDN解析的问题。有两种可能的答案：a）由服务器启动，b）由服务器发送，当服务器即将发送选项时，c）由客户端在收到选项后立即发送，以及d）由客户端发送，当选项的内容实际被消费时。对于a）、b）和可能的c），该选项应该真正传递一个地址，而不是FQDN。使用FQDN的唯一真正动机是案例d）。这是唯一允许客户端获取DNS中可能的更改的情况。
If the parameter is expected to be used by constrained devices (low power, battery operated, and low capabilities) or in very lossy networks, it may be appealing to drop the requirement of performing the DNS resolution and use addresses. Another example of a constrained device is a network-booted device, where despite the fact that the node itself is very capable once it's booted, the boot prom is quite constrained.
如果该参数预计将由受限制的设备（低功率、电池供电和低容量）或在非常有损的网络中使用，则可能需要放弃执行DNS解析和使用地址的要求。受约束设备的另一个示例是网络引导设备，尽管节点本身在引导后非常有能力，但引导prom受到很大的约束。
Another aspect that should be considered is time required for the clients to notice any configuration changes. Consider a case where a server configures service A using an address and service B using an FQDN. When an administrator decides to update the configuration, he or she can update the DHCP server configuration to change both services. If the clients do not support reconfigure (which is an optional feature of RFC 3315 but in some environments, e.g., cable modems, is mandatory), the configuration will be updated on the clients after the T1 timer elapses. Depending on the nature of the change (is it a new server added to a cluster of already operating
应该考虑的另一个方面是客户端需要时间来注意任何配置更改。考虑服务器使用FQDN使用地址和服务B配置服务A的情况。当管理员决定更新配置时，他或她可以更新DHCP服务器配置以更改这两个服务。如果客户端不支持重新配置（这是RFC 3315的可选功能，但在某些环境中，如电缆调制解调器，是强制性的），则在T1定时器过期后，客户端上的配置将更新。根据更改的性质（是否将新服务器添加到已运行的服务器集群中
servers or a new server that replaces the only available server that crashed?), this may be an issue. On the other hand, updating service B may be achieved with a DNS record update. That information may be cached by caching DNS servers for up to Time to Live (TTL). Depending on the values of T1 and TTL, one update may be faster than another. Furthermore, depending on the nature of the change (planned modification or unexpected failure), T1 or TTL may be lowered before the change to speed up new configuration adoption.
服务器或替换崩溃的唯一可用服务器的新服务器？），这可能是一个问题。另一方面，可以通过DNS记录更新来实现更新服务B。该信息可以通过缓存DNS服务器来缓存最长生存时间（TTL）。根据T1和TTL的值，一个更新可能比另一个更新快。此外，根据变更的性质（计划的修改或意外故障），T1或TTL可在变更前降低，以加快新配置的采用。
Simply speaking, protocol designers don't know what the TTL or the T1 time will be, so they can't make assumptions about whether a DHCP option will be refreshed more quickly based on T1 or TTL.
简单地说，协议设计者不知道TTL或T1时间是什么，因此他们无法假设DHCP选项是否会基于T1或TTL更快地刷新。
Addresses have the benefit of being easier to implement and handle by the DHCP software. An address option is simpler to use, has validation that is trivial (multiple of 16 constitutes a valid option), is explicit, and does not allow any ambiguity. It is faster (does not require extra round-trip time), so it is more efficient, which can be especially important for energy-restricted devices. It also does not require that the client implements a DNS resolution.
地址的优点是更容易通过DHCP软件实现和处理。地址选项使用起来更简单，验证很简单（16的倍数构成有效选项），是显式的，并且不允许任何歧义。它速度更快（不需要额外的往返时间），因此效率更高，这对于能量受限的设备尤为重要。它也不要求客户端实现DNS解析。
An FQDN imposes a number of additional failure modes and issues that should be dealt with:
FQDN带来了许多应处理的其他故障模式和问题：
1. The client must have knowledge about available DNS servers. That typically means that option DNS_SERVERS [RFC3646] is mandatory. This should be mentioned in the document that defines the new option. It is possible that the server will return the FQDN option but not the DNS server's option. There should be a brief discussion about it;
1. 客户端必须了解可用的DNS服务器。这通常意味着必须选择DNS_服务器[RFC3646]。这应该在定义新选项的文档中提及。服务器可能会返回FQDN选项，但不会返回DNS服务器的选项。应该有一个简短的讨论；
2. The DNS may not be reachable;
2. DNS可能无法访问；
3. The DNS may be available but may not have appropriate information (e.g., no AAAA records for the specified FQDN);
3. DNS可能可用，但可能没有适当的信息（例如，指定FQDN没有AAAA记录）；
4. The address family must be specified (A, AAAA, or any); the information being configured may require a specific address family (e.g., IPv6), but there may be a DNS record only of another type (e.g., A only with an IPv4 address).
4. 必须指定地址系列（A、AAAA或任何）；正在配置的信息可能需要特定的地址系列（例如，IPv6），但可能只有另一种类型的DNS记录（例如，只有IPv4地址的DNS记录）。
5. What should the client do if there are multiple records available (use only the first one, use all, use one and switch to the second if the first fails for whatever reason, etc.). This may be an issue if there is an expectation that the parameter being configured will need exactly one address;
5. 如果有多条记录可用，客户端应该怎么做（仅使用第一条记录、使用全部记录、使用一条记录，如果第一条记录因任何原因失败，则切换到第二条记录，等等）。如果预期正在配置的参数将只需要一个地址，则这可能是一个问题；
6. Multihomed devices may be connected to different administrative domains with each domain providing different information in the DNS (e.g., an enterprise network exposing private domains). The client may send DNS queries to a different DNS server; and
6. 多宿设备可以连接到不同的管理域，每个域在DNS中提供不同的信息（例如，公开私有域的企业网络）。客户端可以向不同的DNS服务器发送DNS查询；和
7. It should be mentioned if Internationalized Domain Names are allowed. If they are, DNS option encoding should be specified.
7. 应该提到的是，是否允许使用国际化域名。如果是，则应指定DNS选项编码。
Address options that are used with overly long T1 (renew timer) values have some characteristics of hard-coded values. That is strongly discouraged. See [RFC4085] for an in-depth discussion. If the option may appear in Information-request, its lifetime should be controlled using the information refresh time option [RFC4242].
Address options that are used with overly long T1 (renew timer) values have some characteristics of hard-coded values. That is strongly discouraged. See [RFC4085] for an in-depth discussion. If the option may appear in Information-request, its lifetime should be controlled using the information refresh time option [RFC4242].translate error, please retry
One specific case that makes the choice between an address and an FQDN not obvious is a DNS Security (DNSSEC) bootstrap scenario. DNSSEC validation imposes a requirement for clock sync (to the accuracy reasonably required to consider signature inception and expiry times). This often implies usage of NTP configuration.
使地址和FQDN之间的选择不明显的一个特定情况是DNS安全（DNSSEC）引导方案。DNSSEC验证对时钟同步提出了要求（对于考虑签名起始和失效时间的合理要求的准确性）。这通常意味着使用NTP配置。
However, if NTP is provided as an FQDN, there is no way to validate its DNSSEC signature. This is a somewhat weak argument though, as providing an NTP server as an address is also not verifiable using DNSSEC. If the trustworthiness of the configuration provided by the DHCP server is in question, DHCPv6 offers mechanisms that allow server authentication.
但是，如果NTP作为FQDN提供，则无法验证其DNSSEC签名。不过，这是一个较弱的论点，因为提供NTP服务器作为地址也无法使用DNSSEC进行验证。如果DHCP服务器提供的配置的可信度有问题，DHCPv6提供了允许服务器身份验证的机制。
Most options are conveyed in a DHCPv6 message directly. Although there is no codified normative language for such options, they are often referred to as top-level options. Many options may include other options. Such inner options are often referred to as encapsulated or nested options. Those options are sometimes called sub-options, but this term actually means something else and, therefore, should never be used to describe encapsulated options. It is recommended to use the term "encapsulated" as this terminology is used in [RFC3315]. The difference between encapsulated and sub-options is that the former uses normal DHCPv6 option numbers, while the latter uses option number space specific to a given parent option. It should be noted that, contrary to DHCPv4, there is no shortage of option numbers; therefore, almost all options share a common option space. For example, option type 1 meant different things in DHCPv4, depending if it was located in the top level or inside of the Relay Agent Information option. There is no such ambiguity in DHCPv6 (with the exception of [RFC5908], which SHOULD NOT be used as a template for future DHCP option definitions).
大多数选项直接在DHCPv6消息中传递。尽管这些选项没有成文的规范性语言，但它们通常被称为顶级选项。许多选项可能包括其他选项。此类内部选项通常称为封装或嵌套选项。这些选项有时被称为子选项，但这个术语实际上意味着其他东西，因此，永远不应该用来描述封装的选项。建议使用术语“封装”，因为[RFC3315]中使用了该术语。封装选项和子选项之间的区别在于前者使用普通的DHCPv6选项编号，而后者使用特定于给定父选项的选项编号空间。应注意的是，与DHCPv4相反，不缺少选项编号；因此，几乎所有期权共享一个共同的期权空间。例如，选项类型1在DHCPv4中表示不同的内容，这取决于它是位于顶层还是中继代理信息选项内部。DHCPv6中没有这种模糊性（除了[RFC5908]，它不应该用作将来DHCP选项定义的模板）。
From the implementation perspective, it is easier to implement encapsulated options rather than sub-options, as the implementors do not have to deal with separate option spaces and can use the same buffer parser in several places throughout the code.
从实现的角度来看，实现封装的选项比实现子选项更容易，因为实现者不必处理单独的选项空间，并且可以在整个代码的多个位置使用相同的缓冲区解析器。
Such encapsulation is not limited to one level. There is at least one defined option that is encapsulated twice: Identity Association for Prefix Delegation (IA_PD), as defined in Section 9 of [RFC3633], conveys the Identity Association (IA) Prefix (IAPREFIX), as defined in Section 10 of [RFC3633]. Such a delegated prefix may contain an excluded prefix range that is represented by the PD_EXCLUDE option that is conveyed as encapsulated inside IAPREFIX (PD_EXCLUDE is defined in [RFC6603]). It seems awkward to refer to such options as sub-sub-option or doubly encapsulated option; therefore, the "encapsulated option" term is typically used, regardless of the nesting level.
这种封装不限于一个级别。至少有一个已定义的选项被封装两次：[RFC3633]第9节中定义的前缀委派标识关联（IA_PD），传递[RFC3633]第10节中定义的标识关联（IA）前缀（IAPREFIX）。这样的委托前缀可以包含被排除的前缀范围，该范围由PD_EXCLUDE选项表示，该选项作为封装在IAPREFIX中的方式传送（PD_EXCLUDE在[RFC6603]中定义）。将此类期权称为子-子期权或双重封装期权似乎有些尴尬；因此，不管嵌套级别如何，通常使用“封装选项”术语。
When defining a DHCP-based configuration mechanism for a protocol that requires something more complex than a single option, it may be tempting to group configuration values using sub-options. That should preferably be avoided, as it increases complexity of the parser. It is much easier, faster, and less error prone to parse a large number of options on a single (top-level) scope than to parse options on several scopes. The use of sub-options should be avoided as much as possible, but it is better to use sub-options rather than conditional formatting.
当为需要比单个选项更复杂的内容的协议定义基于DHCP的配置机制时，可能会尝试使用子选项对配置值进行分组。最好避免这种情况，因为它增加了解析器的复杂性。与在多个作用域上解析选项相比，在单个（顶级）作用域上解析大量选项更容易、更快、更不容易出错。应尽可能避免使用子选项，但最好使用子选项而不是条件格式。
It should be noted that currently there is no clear way defined for requesting sub-options. Most known implementations are simply using the top-level Option Request Option (ORO) for requesting both top-level and encapsulated options.
应该注意的是，目前没有明确的方式定义请求子选项。大多数已知的实现只是使用顶级选项请求选项（ORO）来请求顶级和封装选项。
DHCP is designed for provisioning clients. Less experienced protocol designers often assume that it is easy to define an option that will convey a different parameter for each client in a network. Such problems arose during designs of the Mapping of Address and Port (MAP) [MAP] and IPv4 Residual Deployment (4rd) [SOLUTION-4rd]. While it would be easier for provisioned clients to get ready to use per-client option values, such a requirement puts exceedingly large loads on the server side. The new extensions may introduce new implementation complexity and additional database state on the server. Alternatives should be considered, if possible. As an example, [MAP] was designed in a way that all clients are provisioned with the same set of MAP options, and each provisioned client uses its unique address and delegated prefix to generate client-specific
DHCP是为配置客户端而设计的。经验较少的协议设计人员通常认为，定义一个选项很容易，该选项将为网络中的每个客户端传递不同的参数。在地址和端口映射（MAP）[MAP]和IPv4剩余部署（4rd）[SOLUTION-4rd]的设计过程中出现了这样的问题。虽然配置的客户机可以更容易地准备使用每个客户机选项值，但这样的要求会给服务器端带来非常大的负载。新的扩展可能会在服务器上引入新的实现复杂性和额外的数据库状态。如有可能，应考虑替代方案。例如，[MAP]的设计方式是为所有客户机提供相同的MAP选项集，每个提供的客户机使用其唯一的地址和委托前缀生成特定于客户机的
information. Such a solution does not introduce any additional state for the server and, therefore, scales better.
信息这样的解决方案不会为服务器引入任何附加状态，因此可以更好地扩展。
It also should be noted that contrary to DHCPv4, DHCPv6 keeps several timers for renewals. Each IA_NA (addresses) and IA_PD (prefixes) contains T1 and T2 timers that designate time after which the client will initiate renewal. Those timers apply only to their associated IA containers. Refreshing other parameters should be initiated after a time specified in the information refresh time option (defined in [RFC4242]), carried in the Reply message, and returned in response to the Information-request message. Introducing additional timers make deployment unnecessarily complex and SHOULD be avoided.
还应注意的是，与DHCPv4相反，DHCPv6保留多个计时器用于续订。每个IA_-NA（地址）和IA_-PD（前缀）都包含T1和T2计时器，它们指定客户端启动续订的时间。这些计时器仅适用于其关联的IA容器。刷新其他参数应在信息刷新时间选项（在[RFC4242]中定义）中指定的时间后启动，并在回复消息中携带，并响应信息请求消息返回。引入额外的计时器会使部署变得不必要的复杂，应该避免。
In general, DHCPv6 clients only refresh configuration data from the DHCP server when the T1 timer expires. Although there is a Reconfigure mechanism that allows a DHCP server to request that clients initiate reconfiguration, support for this mechanism is optional and cannot be relied upon.
通常，DHCPv6客户端仅在T1计时器过期时从DHCP服务器刷新配置数据。尽管存在允许DHCP服务器请求客户端启动重新配置的重新配置机制，但对该机制的支持是可选的，不能依赖。
Even when DHCP clients refresh their configuration information, not all consumers of DHCP-sourced configuration data notice these changes. For instance, if a server is started using parameters received in an early DHCP transaction, but does not check for updates from DHCP, it may well continue to use the same parameter indefinitely. There are a few operating systems that take care of reconfiguring services when the client moves to a new network (e.g., based on mechanisms like [RFC4436], [RFC4957], or [RFC6059]), but it's worth bearing in mind that a renew may not always result in the client taking up new configuration information that it receives.
即使DHCP客户端刷新其配置信息，并非所有DHCP源配置数据的使用者都会注意到这些更改。例如，如果服务器使用早期DHCP事务中接收的参数启动，但没有检查来自DHCP的更新，那么它很可能会无限期地继续使用相同的参数。当客户端移动到新网络时，有一些操作系统负责重新配置服务（例如，基于[RFC4436]、[RFC4957]或[RFC6059]等机制），但值得注意的是，续订可能并不总是导致客户端接收新的配置信息。
In light of the above, when designing an option you should take into consideration the fact that your option may hold stale data that will only be updated at an arbitrary time in the future.
鉴于上述情况，在设计选项时，您应该考虑到这样一个事实，即您的选项可能包含过时的数据，这些数据将来只能在任意时间更新。
In some cases, there could be more than one DHCPv6 server on a link, with each providing a different set of parameters. One notable example of such a case is a home network with a connection to two independent ISPs.
在某些情况下，链路上可能有多个DHCPv6服务器，每个服务器都提供一组不同的参数。这种情况的一个显著例子是连接到两个独立ISP的家庭网络。
The DHCPv6 specification does not provide clear advice on how to handle multiple provisioning sources. Although [RFC3315] states that a client that receives more than one Advertise message may respond to one or more of them, such capability has not been observed in existing implementations. Existing clients will pick one server and
DHCPv6规范没有提供关于如何处理多个供应源的明确建议。尽管[RFC3315]指出，接收多条播发消息的客户机可以响应其中一条或多条消息，但在现有实现中尚未观察到这种能力。现有客户机将选择一台服务器，然后
will continue the configuration process with that server, ignoring all other servers.
将继续该服务器的配置过程，忽略所有其他服务器。
In addition, a node that acts as a DHCPv6 client may be connected to more than one physical network. In most cases, it will operate a separate DHCP client state machine on each interface and acquire different, possibly conflicting, information through each. This information will not be acquired in any synchronized way.
此外，充当DHCPv6客户端的节点可以连接到多个物理网络。在大多数情况下，它将在每个接口上操作一个单独的DHCP客户端状态机，并通过每个接口获取不同的、可能冲突的信息。不会以任何同步方式获取此信息。
Existing nodes cannot be assumed to systematically segregate configuration information on the basis of its source; as a result, it is quite possible that a node may receive an FQDN on one network interface but do the DNS resolution on a different network interface, using different DNS servers. As a consequence, DNS resolution done by the DHCP server is more likely to behave predictably than DNS resolution done on a multi-interface or multihomed client.
不能假设现有节点根据其源系统地隔离配置信息；因此，节点很可能在一个网络接口上接收FQDN，但在不同的网络接口上使用不同的DNS服务器执行DNS解析。因此，由DHCP服务器执行的DNS解析比在多接口或多主机客户端上执行的DNS解析更有可能表现出可预测性。
This is a generic DHCP issue and should not be dealt within each option separately. This issue is better dealt with using a protocol-level solution, and fixing this problem should not be attempted on a per-option basis. Work is ongoing in the IETF to provide a systematic solution to this problem.
这是一个通用的DHCP问题，不应在每个选项中单独处理。使用协议级别的解决方案可以更好地解决此问题，并且不应在每个选项的基础上尝试解决此问题。IETF正在为这个问题提供系统的解决方案。
Adding a simple DHCP option is straightforward and generally something that any working group (WG) can do, perhaps with some help from designated DHCP experts. However, when new fragment types need to be devised, this requires the attention of DHCP experts and should not be done in a WG that doesn't have a quorum of such experts. This is true whether the new fragment type has the same structure as an existing fragment type but with different semantics, or the new format has a new structure.
添加一个简单的DHCP选项很简单，通常任何工作组（WG）都可以这样做，可能需要指定DHCP专家的帮助。然而，当需要设计新的片段类型时，这需要DHCP专家的注意，并且不应该在没有法定人数的工作组中进行。无论新片段类型与现有片段类型具有相同的结构，但语义不同，还是新格式具有新结构，都是如此。
Responsible Area Directors for WGs that wish to add a work item to a WG charter to define a new DHCP option should get clarity from the WG as to whether the new option will require a new fragment type or new semantics, or whether it is a simple DHCP option that fits existing definitions.
希望向工作组章程中添加工作项以定义新DHCP选项的工作组负责人应向工作组了解新选项是否需要新的片段类型或新语义，或者是否是符合现有定义的简单DHCP选项。
If a WG needs a new fragment type, it is preferable to see if another WG exists whose members already have sufficient expertise to evaluate the new work. If such a working group is available, the work should be chartered in that working group instead. If there is no other WG with DHCP expertise that can define the new fragment type, the responsible AD should seek help from known DHCP experts within the IETF to provide advice and frequent early review as the original WG defines the new fragment type.
如果一个工作组需要一个新的片段类型，最好看看是否存在另一个工作组，其成员已经有足够的专业知识来评估新的工作。如果有这样一个工作组，则应将工作特许给该工作组。如果没有其他具有DHCP专业知识的工作组可以定义新的片段类型，则负责的AD应寻求IETF内已知DHCP专家的帮助，以便在原始工作组定义新片段类型时提供建议和频繁的早期审查。
In either case, the new option should be defined in a separate document, and the work should focus on defining a new format that generalizes well and can be reused, rather than a single-use fragment type. The WG that needs the new fragment type can define their new option referencing the new fragment type document, and the work can generally be done in parallel, avoiding unnecessary delays. Having the definition in its own document will foster reuse of the new fragment type.
在这两种情况下，新选项都应该在单独的文档中定义，工作重点应该是定义一种新的格式，该格式具有良好的通用性，并且可以重用，而不是单一使用片段类型。需要新片段类型的工作组可以定义引用新片段类型文档的新选项，工作通常可以并行完成，避免不必要的延迟。在自己的文档中定义将促进新片段类型的重用。
The responsible AD should work with all relevant WG Chairs and DHCP experts to ensure that the new fragment type document has in fact been carefully reviewed by the experts and appears satisfactory.
负责的AD应与所有相关工作组主席和DHCP专家合作，以确保新的片段类型文件事实上已由专家仔细审查，并且看起来令人满意。
Responsible Area Directors for WGs that are considering defining options that actually update DHCP, as opposed to simple options, should go through a process similar to that described above when trying to determine where to do the work. Under no circumstances should a WG be given a charter deliverable to define a new DHCP option, and then on the basis of that charter item actually make updates to DHCP.
与简单选项相反，正在考虑定义实际更新DHCP的选项的工作组负责区域主管，在尝试确定在何处执行工作时，应经历与上述类似的过程。在任何情况下，都不应向工作组提供可交付的许可证，以定义新的DHCP选项，然后根据该许可证项目实际更新DHCP。
When defining new options, one specific consideration to evaluate is whether or not options of a similar format would need to have multiple or single values encoded (whatever differs from the current option) and how that might be accomplished in a similar format.
在定义新选项时，需要评估的一个具体考虑事项是，类似格式的选项是否需要编码多个或单个值（与当前选项不同的内容），以及如何在类似格式中实现。
When defining a new option, it is best to synthesize the option format using fragment types already in use. However, in some cases, there may be no fragment type that accomplishes the intended purpose.
定义新选项时，最好使用已使用的片段类型合成选项格式。但是，在某些情况下，可能没有实现预期目的的片段类型。
The matter of size considerations and option order are further discussed in Sections 15 and 17.
第15节和第17节将进一步讨论尺寸考虑事项和选择顺序。
DHCPv6 [RFC3315] allows for packet sizes up to 64 KB. First, through its use of link-local addresses, it avoids many of the deployment problems that plague DHCPv4 and is actually a UDP over the IPv6-based protocol (compared to DHCPv4, which is mostly UDP over IPv4 but with layer-2 hacks). Second, RFC 3315 explicitly refers readers to Section 5 of [RFC2460], which describes an MTU of 1280 octets and a minimum fragment reassembly of 1500 octets. It's feasible to suggest that DHCPv6 is capable of having larger options deployed over it, and at least no common upper limit is yet known to have been encoded by its implementors. It is not really possible to describe a fixed
DHCPv6[RFC3315]允许最大为64 KB的数据包大小。首先，通过使用链路本地地址，它避免了困扰DHCPv4的许多部署问题，实际上是基于IPv6的UDP协议（与DHCPv4相比，DHCPv4主要是IPv4上的UDP协议，但存在第2层攻击）。其次，RFC 3315明确地向读者介绍了[RFC2460]的第5节，该节描述了1280个八位字节的MTU和1500个八位字节的最小片段重组。建议DHCPv6能够在其上部署更大的选项是可行的，至少目前还不知道其实现者对公共上限进行了编码。实际上不可能描述一个固定的
limit that cleanly divides workable option sizes from those that are too big.
将可用选项大小与过大选项大小清晰区分开来的限制。
It is advantageous to prefer option formats that contain the desired information in the smallest form factor that satisfies the requirements. Common sense still applies here. It is better to split distinct values into separate octets rather than propose overly complex bit-shifting operations to save several bits (or even an octet or two) that would be padded to the next octet boundary anyway.
优选以满足要求的最小形状因子包含所需信息的选项格式是有利的。常识在这里仍然适用。最好将不同的值分割成单独的八位字节，而不是提出过于复杂的位移位操作来保存几个位（甚至一个或两个八位字节），这些位无论如何都会填充到下一个八位字节边界。
DHCPv6 does allow for multiple instances of a given option, and they are treated as distinct values following the defined format; however, this feature is generally preferred to be restricted to protocol class features (such as the IA_* series of options). In such cases, it is better to define an option as an array if it is possible. It is recommended to clarify (with normative language) whether a given DHCPv6 option may appear once or multiple times. The default assumption is only once.
DHCPv6允许给定选项的多个实例，并且按照定义的格式将它们视为不同的值；但是，此功能通常最好仅限于协议类功能（如IA_*系列选项）。在这种情况下，如果可能，最好将选项定义为数组。建议澄清（使用规范性语言）给定的DHCPv6选项是否会出现一次或多次。默认假设只有一次。
In general, if a lot of data needs to be configured (for example, some option lengths are quite large), DHCPv6 may not be the best choice to deliver such configuration information and SHOULD simply be used to deliver a URI that specifies where to obtain the actual configuration information.
通常，如果需要配置大量数据（例如，某些选项长度相当大），DHCPv6可能不是传递此类配置信息的最佳选择，而应该仅用于传递指定从何处获取实际配置信息的URI。
Although [RFC3315] states that each option type MAY appear more than once, the original idea was that multiple instances are reserved for stateful options, like IA_NA or IA_PD. For most other options, it is usually expected that they will appear once at most. Such options are called singleton options. Sadly, RFCs have often failed to clearly specify whether or not a given option can appear more than once.
尽管[RFC3315]指出每个选项类型可能出现不止一次，但最初的想法是为有状态选项保留多个实例，如IA_NA或IA_PD。对于大多数其他选项，通常期望它们最多出现一次。这些选项称为单例选项。遗憾的是，RFC常常无法明确指定给定选项是否可以多次出现。
Documents that define new options SHOULD state whether or not these options are singletons. Unless otherwise specified, newly defined options are considered to be singletons. If multiple instances are allowed, the document MUST explain how to use them. Care should be taken not to assume that they will be processed in the order they appear in the message. See Section 17 for more details.
定义新选项的文档应说明这些选项是否为单例。除非另有规定，新定义的选项将被视为单例。如果允许多个实例，文档必须解释如何使用它们。应注意不要假设它们将按照它们在消息中出现的顺序进行处理。详见第17节。
When deciding whether single or multiple option instances are allowed in a message, take into consideration how the content of the option will be used. Depending on the service being configured, it may or may not make sense to have multiple values configured. If multiple values make sense, it is better to explicitly allow that by using an option format that allows multiple values within one option instance.
在决定消息中是否允许使用单个或多个选项实例时，请考虑如何使用选项的内容。根据配置的服务，配置多个值可能有意义，也可能没有意义。如果多个值有意义，最好使用允许在一个选项实例中使用多个值的选项格式来显式允许。
Allowing multiple option instances often leads to confusion. Consider the following example. Basic DS-Lite architecture assumes that the B4 element (DHCPv6 client) will receive the AFTR option and establish a single tunnel to the configured tunnel termination point (AFTR). During the standardization process of [RFC6334], there was a discussion whether multiple instances of the DS-Lite tunnel option should be allowed. This created an unfounded expectation that the clients receiving multiple instances of the option will somehow know when one tunnel endpoint goes offline and do some sort of failover between other values provided in other instances of the AFTR option. Others assumed that if there are multiple options, the client will somehow do load balancing between the provided tunnel endpoints. Neither failover nor load balancing was defined for the DS-Lite architecture, so it caused confusion. It was eventually decided to allow only one instance of the AFTR option.
允许多个选项实例通常会导致混淆。考虑下面的例子。基本DS Lite体系结构假设B4元素（DHCPv6客户端）将接收AFTR选项，并建立一个到已配置隧道终止点（AFTR）的隧道。在[RFC6334]的标准化过程中，讨论了是否应允许DS Lite隧道选项的多个实例。这造成了一种毫无根据的期望，即接收多个选项实例的客户端将不知何故知道一个隧道端点何时脱机，并在AFTR选项的其他实例中提供的其他值之间执行某种故障切换。其他人认为，如果有多个选项，客户端将以某种方式在提供的隧道端点之间进行负载平衡。DS Lite体系结构既没有定义故障转移也没有定义负载平衡，因此造成了混乱。最终决定只允许AFTR选项的一个实例。
Option order, either the order among many DHCPv6 options or the order of multiple instances of the same option, SHOULD NOT be significant. New documents MUST NOT assume any specific option processing order.
选项顺序，无论是多个DHCPv6选项之间的顺序，还是同一选项的多个实例的顺序，都不应该很重要。新文档不得采用任何特定的选项处理顺序。
As there is no explicit order for multiple instances of the same option, an option definition SHOULD instead restrict ordering by using a single option that contains ordered fields.
由于同一选项的多个实例没有明确的顺序，因此选项定义应该使用包含有序字段的单个选项来限制顺序。
As [RFC3315] does not impose option order, some implementations use hash tables to store received options (which is a conformant behavior). Depending on the hash implementation, the processing order is almost always different then the order in which the options appeared in the packet on the wire.
由于[RFC3315]没有强加选项顺序，一些实现使用哈希表存储收到的选项（这是一种一致的行为）。根据散列实现的不同，处理顺序几乎总是不同于选项在数据包中出现的顺序。
In DHCPv4, all relay options are organized as sub-options within the DHCP Relay Agent Information option [RFC3046]. And, an independent number space called "DHCP Relay Agent Sub-options" is maintained by IANA. Different from DHCPv4, in DHCPv6, relay options are defined in the same way as client/server options, and they also use the same option number space as client/server options. Future DHCPv6 relay options MUST be allocated from this single DHCPv6 option number space.
在DHCPv4中，所有中继选项都组织为DHCP中继代理信息选项[RFC3046]中的子选项。IANA维护一个称为“DHCP中继代理子选项”的独立数字空间。与DHCPv4不同，在DHCPv6中，中继选项的定义方式与客户机/服务器选项相同，并且它们也使用与客户机/服务器选项相同的选项编号空间。未来的DHCPv6中继选项必须从该DHCPv6选项编号空间分配。
For example, the Relay-Supplied Options option [RFC6422] may also contain some DHCPv6 options as permitted, such as the Extensible Authentication Protocol (EAP) Re-authentication Protocol (ERP) Local Domain Name DHCPv6 Option [RFC6440].
例如，中继提供的选项[RFC6422]还可能包含一些允许的DHCPv6选项，例如可扩展身份验证协议（EAP）重新身份验证协议（ERP）本地域名DHCPv6选项[RFC6440]。
The DHCPv6 Option Request Option (OPTION_ORO) [RFC3315] is an option that serves two purposes -- to inform the server what options the client supports and what options the client is willing to consume.
DHCPv6选项请求选项（Option_ORO）[RFC3315]是一个用于两个目的的选项——通知服务器客户端支持哪些选项以及客户端愿意使用哪些选项。
For some options, such as the options required for the functioning of DHCPv6 itself, it doesn't make sense to require that they be explicitly requested using the Option Request Option. In all other cases, it is prudent to assume that any new option must be present on the relevant option request list if the client desires to receive it.
对于某些选项，例如DHCPv6本身运行所需的选项，要求使用选项请求选项显式请求它们是没有意义的。在所有其他情况下，如果客户希望接收任何新的期权，则谨慎地假设任何新的期权必须出现在相关的期权请求列表上。
It is tempting to add text that requires the client to include a new option in the Option Request Option list, similar to this text: "Clients MUST place the foo option code on the Option Request Option list, clients MAY include option foo in their packets as hints for the server as values the desire, and servers MUST include option foo when the client requests it (and the server has been so configured)". Such text is discouraged as there are several issues with it. First, it assumes that client implementation that supports a given option will always want to use it. This is not true. The second and more important reason is that such text essentially duplicates the mechanism already defined in [RFC3315]. It is better to simply refer to the existing mechanism rather than define it again. See Section 21 for proposed examples on how to do that.
添加要求客户端在选项请求选项列表中包含新选项的文本很有诱惑力，类似于以下文本：“客户端必须将foo选项代码放在选项请求选项列表上，客户端可以在其数据包中包含选项foo作为服务器的提示，作为所需的值，并且当客户端请求选项foo时，服务器必须包含选项foo（并且服务器已如此配置）“。不鼓励这样的案文，因为它有几个问题。首先，它假设支持给定选项的客户机实现总是希望使用它。事实并非如此。第二个也是更重要的原因是，此类文本实质上重复了[RFC3315]中已经定义的机制。最好只是参考现有的机制，而不是重新定义它。关于如何实现这一点的建议示例，请参见第21节。
Creators of DHCPv6 options cannot assume special ordering of options either as they appear in the Option Request Option or as they appear within the packet. Although it is reasonable to expect that options will be processed in the order they appear in ORO, server software is not required to sort DHCPv6 options into the same order in Reply messages.
DHCPv6选项的创建者不能假定选项在选项请求选项中或在数据包中出现时的特殊顺序。虽然可以合理地预期选项将按照它们在ORO中出现的顺序进行处理，但不需要服务器软件将DHCPv6选项按回复消息中的相同顺序进行排序。
It should also be noted that options values are not required to be aligned within the DHCP packet; even the option code and option length may appear on odd-byte boundaries.
还应注意，选项值不需要在DHCP数据包内对齐；即使选项代码和选项长度也可能出现在奇数字节边界上。
The transition from IPv4 to IPv6 is progressing. Many transition technologies are proposed to speed it up. As a natural consequence, there are also DHCP options proposed to provision those proposals. The inevitable question is whether the required parameters should be delivered over DHCPv4 or DHCPv6. Authors often don't give much thought about it and simply pick DHCPv6 without realizing the consequences. IPv6 is expected to stay with us for many decades, and so is DHCPv6. There is no mechanism available to deprecate an option in DHCPv6, so any options defined will stay with us as long as the
从IPv4到IPv6的过渡正在进行中。许多过渡技术被提出来加速它。自然的结果是，还提出了一些方案来提供这些建议。不可避免的问题是，所需参数是否应通过DHCPv4或DHCPv6交付。作者通常不怎么考虑它，只是选择了DHCPv6而没有意识到其后果。IPv6预计将伴随我们几十年，DHCPv6也是如此。DHCPv6中没有任何机制可用于否决选项，因此只要
DHCPv6 protocol itself lasts. It seems likely that such options defined to transition from IPv4 will outlive IPv4 by many decades. From that perspective, it is better to implement provisioning of the transition technologies in DHCPv4, which will be obsoleted together with IPv4.
DHCPv6协议本身是持久的。看起来，这些定义为从IPv4过渡的选项可能比IPv4寿命长几十年。从这个角度来看，最好在DHCPv4中实现过渡技术的供应，它将和IPv4一起被淘汰。
When the network infrastructure becomes IPv6 only, the support for IPv4-only nodes may still be needed. In such a scenario, a mechanism for providing IPv4 configuration information over IPv6-only networks may be needed. See [IPv4-CONFIG] for further details.
当网络基础设施变为仅限IPv6时，可能仍然需要对仅限IPv4的节点的支持。在这种情况下，可能需要一种通过仅IPv6网络提供IPv4配置信息的机制。有关更多详细信息，请参阅[IPv4配置]。
There are three major entities in DHCPv6: server, relay agent, and client. It is very helpful for implementors to include separate sections that describe operation for those three major entities. Even when a given entity does not participate, it is useful to have a very short section stating that it must not send a given option and must ignore it when received.
DHCPv6中有三个主要实体：服务器、中继代理和客户端。对于实现者来说，包含描述这三个主要实体的操作的单独部分是非常有帮助的。即使给定的实体没有参与，也应该有一个很短的部分说明它不能发送给定的选项，并且在收到时必须忽略它。
There is also a separate entity called the "requestor", which is a special client-like type that participates in the leasequery protocol [RFC5007] [RFC5460]. A similar section for the requestor is not required, unless the new option has anything to do with the requestor (or it is likely that the reader may think that is has). It should be noted that while in the majority of deployments the requestor is co-located with the relay agent, those are two separate entities from the protocol perspective, and they may be used separately. There are stand-alone requestor implementations available.
还有一个称为“请求者”的单独实体，它是一种特殊的类似于客户端的类型，参与租赁协议[RFC5007][RFC5460]。除非新选项与请求者有任何关系（或者读者可能会认为这与请求者有关），否则请求者不需要类似的部分。应该注意的是，虽然在大多数部署中，请求者与中继代理位于同一位置，但从协议的角度来看，它们是两个独立的实体，可以单独使用。有一些独立的请求者实现可用。
The following sections include proposed text for such sections. That text is not required to appear, but it is appropriate in most cases. Additional or modified text specific to a given option is often required.
以下章节包括此类章节的拟议文本。该文本不需要显示，但在大多数情况下是合适的。通常需要特定于给定选项的附加或修改文本。
Although the requestor is a somewhat uncommon functionality, its existence should be noted, especially when allowing or disallowing options to appear in certain messages or to be sent by certain entities. Additional message types may appear in the future, besides types defined in [RFC3315]. Therefore, authors are encouraged to familiarize themselves with a list of currently defined DHCPv6 messages available on the IANA website [IANA].
尽管请求者是一种不常见的功能，但应该注意它的存在，特别是在允许或不允许选项出现在某些消息中或由某些实体发送时。除[RFC3315]中定义的类型外，将来可能还会出现其他消息类型。因此，鼓励作者熟悉IANA网站[IANA]上当前定义的DHCPv6消息列表。
Typically, new options are requested by clients and assigned by the server, so there is no specific relay behavior. Nevertheless, it is good to include a section for relay agent behavior and simply state
通常，新选项由客户端请求并由服务器分配，因此没有特定的中继行为。尽管如此，最好包含一个关于中继代理行为和简单状态的部分
that there are no additional requirements for relays. The same applies for client behavior if the options are to be exchanged between the relay and server.
对继电器没有额外要求。如果要在中继和服务器之间交换选项，则同样适用于客户端行为。
Sections that contain option definitions MUST include a formal verification procedure. Often it is very simple, e.g., an option that conveys an IPv6 address must be exactly 16-bytes long, but sometimes the rules are more complex. It is recommended to refer to existing documents (e.g., Section 8 of RFC 3315 for domain name encoding) rather than trying to repeat such rules.
包含选项定义的章节必须包括正式的验证程序。通常它非常简单，例如，传送IPv6地址的选项必须正好有16字节长，但有时规则更复杂。建议参考现有文件（例如，RFC 3315第8节中的域名编码），而不是试图重复此类规则。
Clients MAY request option foo, as defined in [RFC3315], Sections 17.1.1, 18.1.1, 18.1.3, 18.1.4, 18.1.5, and 22.7. As a convenience to the reader, we mention here that the client includes requested option codes in the Option Request Option.
客户可根据[RFC3315]第17.1.1、18.1.1、18.1.3、18.1.4、18.1.5和22.7节的规定要求选择foo。为了方便读者，我们在这里提到，客户机在选项请求选项中包含请求的选项代码。
Optional text (if the client's hints make sense): The client also MAY include option foo in its Solicit, Request, Renew, Rebind, and Information-request messages as a hint for the server regarding preferred option values.
可选文本（如果客户机的提示有意义）：客户机还可以在其请求、请求、续订、重新绑定和信息请求消息中包含选项foo，作为服务器关于首选选项值的提示。
Optional text (if the option contains an FQDN): If the client requests an option that conveys an FQDN, it is expected that the contents of that option will be resolved using DNS. Hence, the following text may be useful: Clients that request option foo SHOULD also request option OPTION_DNS_SERVERS as specified in [RFC3646].
可选文本（如果该选项包含FQDN）：如果客户端请求传递FQDN的选项，则该选项的内容将使用DNS解析。因此，以下文本可能有用：请求选项foo的客户机还应请求[RFC3646]中指定的选项\u DNS\u服务器。
Clients MUST discard option foo if it is invalid (i.e., it did not pass the validation steps defined in Section X.Y).
如果选项foo无效（即未通过第X.Y节中定义的验证步骤），则客户端必须放弃该选项。
Optional text (if option foo in expected to be exchanged between relays and servers): Option foo is exchanged between relays and servers only. Clients are not aware of the usage of option foo. Clients MUST ignore received option foo.
可选文本（如果预期中的选项foo在继电器和服务器之间交换）：选项foo仅在继电器和服务器之间交换。客户端不知道选项foo的用法。客户端必须忽略收到的选项foo。
Sections 17.2.2 and 18.2 of [RFC3315] govern server operation in regards to option assignment. As a convenience to the reader, we mention here that the server will send option foo only if configured with specific values for foo and if the client requested it.
[RFC3315]第17.2.2节和第18.2节规定了与选项分配有关的服务器操作。为了方便读者，我们在这里提到，只有在为foo配置了特定值并且客户端请求时，服务器才会发送选项foo。
Optional text: Option foo is a singleton. Servers MUST NOT send more than one instance of the foo option.
可选文本：选项foo是一个单例。服务器不能发送多个foo选项实例。
Optional text (if the server is never supposed to receive option foo): Servers MUST ignore the incoming foo option.
可选文本（如果服务器不应该接收选项foo）：服务器必须忽略传入的foo选项。
It's never appropriate for a relay agent to add options to a message heading toward the client, and relay agents don't actually construct Relay-reply messages anyway.
中继代理向指向客户端的消息添加选项是不合适的，而且中继代理实际上并不构造中继回复消息。
Optional text (if the foo option is exchanged between the clients and server or between requestors and servers): there are no additional requirements for relays.
可选文本（如果在客户端和服务器之间或在请求者和服务器之间交换foo选项）：对于中继没有额外的要求。
Optional text (if relays are expected to insert or consume option foo): Relay agents MAY include option foo in a Relay-forward message when forwarding packets from clients to the servers.
可选文本（如果预期中继插入或使用选项foo）：中继代理在将数据包从客户端转发到服务器时，可能会在中继转发消息中包含选项foo。
Authors often ask themselves whether their proposal updates existing RFCs, especially RFC 3315. In April 2013, there were about 80 options defined. Had all documents that defined them also updated RFC 3315, comprehension of such a document set would be extremely difficult. It should be noted that "extends" and "updates" are two very different verbs. If a new document defines a new option that clients request and servers provide, it merely extends current standards, so "updates RFC 3315" is not required in the new document header. On the other hand, if a new document replaces or modifies existing behavior and includes clarifications or other corrections, it should be noted that it updates the other document. For example, [RFC6644] clearly updates [RFC3315] as it replaces existing text with new text.
作者经常问自己，他们的提案是否更新了现有的RFC，尤其是RFC 3315。2013年4月，定义了大约80个选项。如果定义它们的所有文档也更新了RFC 3315，那么理解这样一个文档集将非常困难。应该注意的是，“扩展”和“更新”是两个非常不同的动词。如果新文档定义了客户机请求和服务器提供的新选项，那么它只是扩展了当前标准，因此新文档标题中不需要“更新RFC 3315”。另一方面，如果新文档替换或修改了现有行为，并包含澄清或其他更正，则应注意它会更新其他文档。例如，[RFC6644]在用新文本替换现有文本时会清楚地更新[RFC3315]。
If in doubt, authors should try to determine whether an implementor reading the base RFC alone (without reading the new document) would be able to properly implement the software. If the base RFC is sufficient, then the new document probably does not update the base RFC. On the other hand, if reading your new document is necessary to properly implement the base RFC, then the new document most likely updates the base RFC.
如果有疑问，作者应尝试确定仅阅读基本RFC（而不阅读新文档）的实现者是否能够正确地实现软件。如果基本RFC足够，那么新文档可能不会更新基本RFC。另一方面，如果需要阅读新文档才能正确实现基本RFC，那么新文档很可能会更新基本RFC。
DHCPv6 does have an authentication mechanism [RFC3315] that makes it possible for DHCPv6 software to discriminate between authentic endpoints and man-in-the-middle. Other authentication mechanisms may optionally be deployed. Sadly, as of 2014, the authentication in DHCPv6 is rarely used, and support for it is not common in existing
DHCPv6确实有一种身份验证机制[RFC3315]，使DHCPv6软件能够区分真实端点和中间人。可以选择部署其他身份验证机制。遗憾的是，截至2014年，DHCPv6中的身份验证很少使用，对它的支持在现有系统中并不常见
implementations. Some specific deployment types make it mandatory (or parts thereof, e.g., DOCSIS3.0-compatible cable modems require reconfigure-key support), so in certain cases, specific authentication aspects can be relied upon. That is not true in the generic case, though.
实现。某些特定的部署类型使其成为强制性的（或其部分，例如，DOCSIS3.0兼容的电缆调制解调器需要重新配置密钥支持），因此在某些情况下，可以依赖特定的身份验证方面。不过，在一般情况下并非如此。
So, while creating a new option, it is prudent to assume that the DHCPv6 packet contents are always transmitted in the clear, and actual production use of the software will probably be vulnerable at least to man-in-the-middle attacks from within the network, even where the network itself is protected from external attacks by firewalls. In particular, some DHCPv6 message exchanges are transmitted to multicast addresses that are likely broadcast anyway.
因此，在创建新选项时，谨慎地假设DHCPv6数据包内容始终以清晰的方式传输，并且软件的实际生产使用可能至少容易受到来自网络内部的中间人攻击，即使网络本身受到防火墙的外部攻击的保护。特别是，一些DHCPv6消息交换被传输到可能无论如何都要广播的多播地址。
If an option is of a specific fixed length, it is useful to remind the implementor of the option data's full length. This is easily done by declaring the specific value of the 'length' tag of the option. This helps to gently remind implementors to validate the option length before digesting them into likewise fixed-length regions of memory or stack.
如果某个选项具有特定的固定长度，则提醒实施者该选项数据的完整长度非常有用。这可以通过声明选项的“length”标记的特定值轻松完成。这有助于温和地提醒实现者在将选项长度分解为同样固定长度的内存或堆栈区域之前验证选项长度。
If an option may be of variable size (such as having indeterminate length fields, such as domain names or text strings), it is advisable to explicitly remind the implementor to be aware of the potential for long options. Either define a reasonable upper limit (and suggest validating it) or explicitly remind the implementor that an option may be exceptionally long (to be prepared to handle errors rather than truncate values).
如果一个选项可能大小可变（例如具有不确定长度的字段，例如域名或文本字符串），建议明确提醒实现者注意长选项的可能性。要么定义一个合理的上限（并建议对其进行验证），要么明确提醒实现者一个选项可能非常长（准备好处理错误而不是截断值）。
For some option contents, out-of-bound values may be used to breach security. An IP address field might be made to carry a loopback address or local multicast address, and depending on the protocol, this may lead to undesirable results. A domain name field may be filled with contrived contents that exceed the limitations placed upon domain name formatting; as this value is possibly delivered to "internal configuration" records of the system, it may be implicitly trusted without being validated.
对于某些选项内容，可能会使用越界值来破坏安全性。IP地址字段可能携带环回地址或本地多播地址，根据协议的不同，这可能导致不希望的结果。域名字段可能会填充超出域名格式限制的人为内容；由于该值可能会传递给系统的“内部配置”记录，因此可能会在未经验证的情况下隐式信任该值。
Authors of documents defining new DHCP options are, therefore, strongly advised to explicitly define validation measures that recipients of such options are required to do before processing such options. However, validation measures already defined by RFC 3315 or other specifications referenced by the new option document are redundant and can introduce errors, so authors are equally strongly advised to refer to the base specification for any such validation language rather than copying it into the new specification.
因此，强烈建议定义新DHCP选项的文档的作者明确定义验证措施，此类选项的接收者在处理此类选项之前必须执行这些措施。然而，RFC 3315或新选项文件引用的其他规范已经定义的验证措施是多余的，可能会引入错误，因此强烈建议作者参考任何此类验证语言的基本规范，而不是将其复制到新规范中。
See also Section 24.
另见第24节。
As discussed in Section 23, the DHCPv6 packets are typically transmitted in the clear, so they are susceptible to eavesdropping. This should be considered when defining options that may convey personally identifying information (PII) or any other type of sensitive data.
如第23节中所讨论的，DHCPv6分组通常以明文形式传输，因此它们容易被窃听。在定义可能传递个人识别信息（PII）或任何其他类型敏感数据的选项时，应考虑这一点。
If the transmission of sensitive or confidential content is required, it is still possible to secure communication between relay agents and servers. Relay agents and servers communicating with relay agents must support the use of IPsec Encapsulating Security Payload (ESP) with encryption in transport mode, according to Section 3.1.1 of [RFC4303] and Section 21.1 of [RFC3315]. Sadly, this requirement is almost universally ignored in real deployments. Even if the communication path between the relay agents and server is secured, the path between the clients and relay agents or server is not.
如果需要传输敏感或机密内容，仍然可以保护中继代理和服务器之间的通信。根据[RFC4303]第3.1.1节和[RFC3315]第21.1节的规定，与中继代理通信的中继代理和服务器必须支持在传输模式下使用带加密的IPsec封装安全有效负载（ESP）。遗憾的是，这一要求在实际部署中几乎被普遍忽视。即使中继代理和服务器之间的通信路径是安全的，客户端和中继代理或服务器之间的路径也是不安全的。
Unless underlying transmission technology provides a secure transmission channel, the DHCPv6 options SHOULD NOT include PII or other sensitive information. If there are special circumstances that warrant sending such information over unsecured DHCPv6, the dangers MUST be clearly discussed in the security considerations.
除非基础传输技术提供安全传输通道，否则DHCPv6选项不应包括PII或其他敏感信息。如果有特殊情况需要通过不安全的DHCPv6发送此类信息，则必须在安全注意事项中明确讨论这些危险。
The authors would like to thank Simon Perreault, Bernie Volz, Ted Lemon, Bud Millwood, Ralph Droms, Barry Leiba, Benoit Claise, Brian Haberman, Richard Barnes, Stephen Farrell, and Stewart Bryant for their comments.
作者要感谢西蒙·佩雷尔特、伯尼·沃尔兹、特德·莱蒙、巴德·米尔伍德、拉尔夫·德罗姆斯、巴里·莱巴、贝诺特·克莱斯、布赖恩·哈伯曼、理查德·巴恩斯、斯蒂芬·法雷尔和斯图尔特·布莱恩特的评论。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315]Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[IANA] IANA, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", <http://www.iana.org/assignments/dhcpv6-parameters/>.
[IANA]IANA，“IPv6动态主机配置协议（DHCPv6）”<http://www.iana.org/assignments/dhcpv6-parameters/>.
[IPv4-CONFIG] Rajtar, B. and I. Farrer, "Provisioning IPv4 Configuration Over IPv6 Only Networks", Work in Progress, February 2014.
[IPv4配置]Rajtar，B.和I.Farrer，“仅在IPv6网络上提供IPv4配置”，正在进行的工作，2014年2月。
[MAP] Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec, W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for configuration of Softwire Address and Port Mapped Clients", Work in Progress, March 2014.
[地图]Mrugalski，T.，Troan，O.，Farrer，I.，Perreault，S.，Dec，W.，Bao，C.，Yeh，L.，和X.Deng，“用于配置软线地址和端口映射客户端的DHCPv6选项”，正在进行的工作，2014年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.
[RFC3046]Patrick，M.，“DHCP中继代理信息选项”，RFC3046，2001年1月。
[RFC3319] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers", RFC 3319, July 2003.
[RFC3319]Schulzrinne，H.和B.Volz，“会话启动协议（SIP）服务器的动态主机配置协议（DHCPv6）选项”，RFC 3319，2003年7月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
[RFC3633]Troan，O.和R.Droms，“动态主机配置协议（DHCP）版本6的IPv6前缀选项”，RFC 3633，2003年12月。
[RFC3646] Droms, R., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003.
[RFC3646]Droms，R.，“IPv6动态主机配置协议（DHCPv6）的DNS配置选项”，RFC 36462003年12月。
[RFC3898] Kalusivalingam, V., "Network Information Service (NIS) Configuration Options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3898, October 2004.
[RFC3898]Kalusialingam，V.，“IPv6（DHCPv6）动态主机配置协议的网络信息服务（NIS）配置选项”，RFC 3898，2004年10月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC4075] Kalusivalingam, V., "Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6", RFC 4075, May 2005.
[RFC4075]Kalusialingam，V.，“DHCPv6的简单网络时间协议（SNTP）配置选项”，RFC 4075，2005年5月。
[RFC4085] Plonka, D., "Embedding Globally-Routable Internet Addresses Considered Harmful", BCP 105, RFC 4085, June 2005.
[RFC4085]Plonka，D.，“嵌入被认为有害的全球可路由互联网地址”，BCP 105，RFC 4085，2005年6月。
[RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 4242, November 2005.
[RFC4242]Venaas，S.，Chown，T.，和B.Volz，“IPv6动态主机配置协议（DHCPv6）的信息刷新时间选项”，RFC 4242，2005年11月。
[RFC4280] Chowdhury, K., Yegani, P., and L. Madour, "Dynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast Control Servers", RFC 4280, November 2005.
[RFC4280]Chowdhury，K.，Yegani，P.，和L.Madour，“广播和多播控制服务器的动态主机配置协议（DHCP）选项”，RFC 4280，2005年11月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006.
[RFC4436]Aboba，B.，Carlson，J.，和S.Cheshire，“检测IPv4中的网络连接（DNAv4）”，RFC 44362006年3月。
[RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option", RFC 4704, October 2006.
[RFC4704]Volz，B.，“IPv6（DHCPv6）客户端完全限定域名（FQDN）选项的动态主机配置协议”，RFC 4704，2006年10月。
[RFC4833] Lear, E. and P. Eggert, "Timezone Options for DHCP", RFC 4833, April 2007.
[RFC4833]Lear，E.和P.Eggert，“DHCP的时区选项”，RFC 4833，2007年4月。
[RFC4957] Krishnan, S., Montavont, N., Njedjou, E., Veerepalli, S., and A. Yegin, "Link-Layer Event Notifications for Detecting Network Attachments", RFC 4957, August 2007.
[RFC4957]Krishnan，S.，Montavont，N.，Njedjou，E.，Veerepalli，S.，和A.Yegin，“用于检测网络附件的链路层事件通知”，RFC 4957，2007年8月。
[RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, "DHCPv6 Leasequery", RFC 5007, September 2007.
[RFC5007]Brzowski，J.，Kinnear，K.，Volz，B.，和S.Zeng，“DHCPv6租赁”，RFC 5007，2007年9月。
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, March 2008.
[RFC5198]Klensin，J.和M.Padlipsky，“网络交换的Unicode格式”，RFC 51982008年3月。
[RFC5223] Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering Location-to-Service Translation (LoST) Servers Using the Dynamic Host Configuration Protocol (DHCP)", RFC 5223, August 2008.
[RFC5223]Schulzrinne，H.，Polk，J.，和H.Tschofenig，“使用动态主机配置协议（DHCP）发现位置到服务转换（丢失）服务器”，RFC 52232008年8月。
[RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, February 2009.
[RFC5460]Stapp，M.，“DHCPv6散装租赁”，RFC 54602009年2月。
[RFC5908] Gayraud, R. and B. Lourdelet, "Network Time Protocol (NTP) Server Option for DHCPv6", RFC 5908, June 2010.
[RFC5908]Gayraud，R.和B.Lourdelet，“DHCPv6的网络时间协议（NTP）服务器选项”，RFC 5908，2010年6月。
[RFC5970] Huth, T., Freimann, J., Zimmer, V., and D. Thaler, "DHCPv6 Options for Network Boot", RFC 5970, September 2010.
[RFC5970]Huth，T.，Freimann，J.，Zimmer，V.，和D.Thaler，“网络引导的DHCPv6选项”，RFC 59702010年9月。
[RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local Location Information Server (LIS)", RFC 5986, September 2010.
[RFC5986]Thomson，M.和J.Winterbottom，“发现本地位置信息服务器（LIS）”，RFC 59862010年9月。
[RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for Detecting Network Attachment in IPv6", RFC 6059, November 2010.
[RFC6059]Krishnan，S.和G.Daley，“IPv6中检测网络连接的简单程序”，RFC 60592010年11月。
[RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", RFC 6334, August 2011.
[RFC6334]Hankins，D.和T.Mrugalski，“双栈Lite的IPv6动态主机配置协议（DHCPv6）选项”，RFC 63342011年8月。
[RFC6422] Lemon, T. and Q. Wu, "Relay-Supplied DHCP Options", RFC 6422, December 2011.
[RFC6422]Lemon，T.和Q.Wu，“继电器提供的DHCP选项”，RFC 6422，2011年12月。
[RFC6440] Zorn, G., Wu, Q., and Y. Wang, "The EAP Re-authentication Protocol (ERP) Local Domain Name DHCPv6 Option", RFC 6440, December 2011.
[RFC6440]Zorn，G.，Wu，Q.，和Y.Wang，“EAP重新认证协议（ERP）本地域名DHCPv6选项”，RFC 64402011年12月。
[RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, "Prefix Exclude Option for DHCPv6-based Prefix Delegation", RFC 6603, May 2012.
[RFC6603]Korhonen，J.，Savolainen，T.，Krishnan，S.，和O.Troan，“基于DHCPv6的前缀委托的前缀排除选项”，RFC 6603，2012年5月。
[RFC6610] Jang, H., Yegin, A., Chowdhury, K., Choi, J., and T. Lemon, "DHCP Options for Home Information Discovery in Mobile IPv6 (MIPv6)", RFC 6610, May 2012.
[RFC6610]Jang，H.，Yegin，A.，Chowdhury，K.，Choi，J.，和T.Lemon，“移动IPv6中家庭信息发现的DHCP选项（MIPv6）”，RFC 66102012年5月。
[RFC6644] Evans, D., Droms, R., and S. Jiang, "Rebind Capability in DHCPv6 Reconfigure Messages", RFC 6644, July 2012.
[RFC6644]Evans，D.，Droms，R.，和S.Jiang，“DHCPv6重新配置消息中的重新绑定能力”，RFC 66442012年7月。
[SOLUTION-4rd] Despres, R., Jiang, S., Penno, R., Lee, Y., Chen, G., and M. Chen, "IPv4 Residual Deployment via IPv6 - a Stateless Solution (4rd)", Work in Progress, October 2013.
[SOLUTION-4rd]Despres，R.，Jiang，S.，Penno，R.，Lee，Y.，Chen，G.，和M.Chen，“通过IPv6的IPv4剩余部署-无状态解决方案（4rd）”，正在进行的工作，2013年10月。
Authors' Addresses
作者地址
David W. Hankins Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 USA
David W.Hankins Google，Inc.美国加利福尼亚州山景大道1600号圆形剧场，邮编94043
EMail: dhankins@google.com
EMail: dhankins@google.com
Tomek Mrugalski Internet Systems Consortium, Inc. 950 Charter Street Redwood City, CA 94063 USA
美国加利福尼亚州红木市Charter Street 950号托梅克·姆鲁加尔斯基互联网系统联合公司，邮编94063
Phone: +1-650-423-1345
EMail: tomasz.mrugalski@gmail.com
Phone: +1-650-423-1345
EMail: tomasz.mrugalski@gmail.com
Marcin Siodelski Internet Systems Consortium, Inc. 950 Charter Street Redwood City, CA 94063 USA
Marcin Siodelski Internet Systems Consortium，Inc.美国加利福尼亚州红木市查特街950号，邮编94063
Phone: +1-650-423-1431
EMail: msiodelski@gmail.com
Phone: +1-650-423-1431
EMail: msiodelski@gmail.com
Sheng Jiang Huawei Technologies Co., Ltd. Q14, Huawei Campus, No. 156 Beiqing Road Hai-Dian District, Beijing, 100095 P.R. China
盛江华为技术有限公司中国北京市海淀区北青路156号华为校区Q14，邮编：100095
EMail: jiangsheng@huawei.com
EMail: jiangsheng@huawei.com
Suresh Krishnan Ericsson 8400 Blvd Decarie Town of Mount Royal, Quebec Canada
Suresh Krishnan Ericsson加拿大魁北克皇家山Decarie镇8400大道
EMail: suresh.krishnan@ericsson.com
EMail: suresh.krishnan@ericsson.com