Internet Engineering Task Force (IETF) D. Hankins
Request for Comments: 6334 Google
Category: Standards Track T. Mrugalski
ISSN: 2070-1721 Gdansk University of Technology
August 2011
Internet Engineering Task Force (IETF) D. Hankins
Request for Comments: 6334 Google
Category: Standards Track T. Mrugalski
ISSN: 2070-1721 Gdansk University of Technology
August 2011
Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite
双栈Lite的IPv6动态主机配置协议（DHCPv6）选项
Abstract
摘要
This document specifies a DHCPv6 option that is meant to be used by a Dual-Stack Lite Basic Bridging BroadBand (B4) element to discover the IPv6 address of its corresponding Address Family Transition Router (AFTR).
本文档指定了一个DHCPv6选项，该选项将由双栈Lite基本桥接宽带（B4）元素使用，以发现其相应地址系列转换路由器（AFTR）的IPv6地址。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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 Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见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/rfc6334.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6334.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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 ....................................................2
2. Requirements Language ...........................................2
3. The AFTR-Name DHCPv6 Option .....................................2
4. DHCPv6 Server Behavior ..........................................4
5. DHCPv6 Client Behavior ..........................................4
6. Security Considerations .........................................5
7. IANA Considerations .............................................6
8. Acknowledgements ................................................6
9. Normative References ............................................6
1. Introduction ....................................................2
2. Requirements Language ...........................................2
3. The AFTR-Name DHCPv6 Option .....................................2
4. DHCPv6 Server Behavior ..........................................4
5. DHCPv6 Client Behavior ..........................................4
6. Security Considerations .........................................5
7. IANA Considerations .............................................6
8. Acknowledgements ................................................6
9. Normative References ............................................6
Dual-Stack Lite [RFC6333] is a solution to offer both IPv4 and IPv6 connectivity to customers that are addressed only with an IPv6 prefix (no IPv4 address is assigned to the attachment device). One of its key components is an IPv4-over-IPv6 tunnel, commonly referred to as a softwire. A DS-Lite "Basic Bridging BroadBand" (B4) device will not know if the network it is attached to offers Dual-Stack Lite service, and if it did would not know the remote endpoint of the tunnel to establish a softwire.
双栈Lite[RFC6333]是一种解决方案，可为仅使用IPv6前缀寻址的客户提供IPv4和IPv6连接（未向连接设备分配IPv4地址）。其关键组件之一是IPv4-over-IPv6隧道，通常称为软线。DS Lite“基本桥接宽带”（B4）设备将不知道其连接的网络是否提供双栈Lite服务，也不知道隧道的远程端点是否可以建立软线。
To inform the B4 of the Address Family Transition Router's (AFTR) location, a DNS [RFC1035] hostname may be used. Once this information is conveyed, the presence of the configuration indicating the AFTR's location also informs a host to initiate Dual-Stack Lite (DS-Lite) service and become a softwire initiator.
为了通知B4地址族转换路由器（AFTR）的位置，可以使用DNS[RFC1035]主机名。一旦传递了该信息，指示AFTR位置的配置的存在也通知主机启动双栈Lite（DS Lite）服务并成为软线启动器。
To provide the conveyance of the configuration information, a single DHCPv6 [RFC3315] option is used, expressing the AFTR's Fully Qualified Domain Name (FQDN) to the B4 element.
为了提供配置信息的传输，使用单个DHCPv6[RFC3315]选项，将AFTR的完全限定域名（FQDN）表示为B4元素。
The details of how the B4 establishes an IPv4-in-IPv6 softwire to the AFTR are out of scope for this document.
B4如何建立到AFTR的IPv4-in-IPv6软线的详细信息不在本文档范围内。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The AFTR-Name option consists of option-code and option-len fields (as all DHCPv6 options have), and a variable-length tunnel-endpoint-name field containing a fully qualified domain name that refers to the AFTR to which the client MAY connect.
AFTR名称选项包括选项代码和选项len字段（与所有DHCPv6选项一样），以及一个可变长度的隧道端点名称字段，其中包含一个完全限定的域名，该域名引用客户端可能连接到的AFTR。
The AFTR-Name option SHOULD NOT appear in any DHCPv6 messages other than the following: Solicit, Advertise, Request, Renew, Rebind, Information-Request, and Reply.
AFTR名称选项不应出现在任何DHCPv6消息中，以下消息除外：请求、播发、请求、续订、重新绑定、信息请求和回复。
The format of the AFTR-Name option is shown in the following figure:
AFTR名称选项的格式如下图所示：
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_AFTR_NAME: 64 | option-len |
+-------------------------------+-------------------------------+
| |
| tunnel-endpoint-name (FQDN) |
| |
+---------------------------------------------------------------+
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_AFTR_NAME: 64 | option-len |
+-------------------------------+-------------------------------+
| |
| tunnel-endpoint-name (FQDN) |
| |
+---------------------------------------------------------------+
OPTION_AFTR_NAME: 64
选项名称：64
option-len: Length of the tunnel-endpoint-name field in octets.
选项len：隧道端点名称字段的长度（以八位字节为单位）。
tunnel-endpoint-name: A fully qualified domain name of the AFTR tunnel endpoint.
隧道端点名称：AFTR隧道端点的完全限定域名。
Figure 1: AFTR-Name DHCPv6 Option Format
图1:AFTR名称DHCPv6选项格式
The tunnel-endpoint-name field is formatted as required in DHCPv6 [RFC3315] Section 8 ("Representation and Use of Domain Names"). Briefly, the format described is using a single octet noting the length of one DNS label (limited to at most 63 octets), followed by the label contents. This repeats until all labels in the FQDN are exhausted, including a terminating zero-length label. Any updates to Section 8 of DHCPv6 [RFC3315] also apply to encoding of this field. An example format for this option is shown in Figure 2, which conveys the FQDN "aftr.example.com.".
隧道端点名称字段按照DHCPv6[RFC3315]第8节（“域名的表示和使用”）的要求进行格式化。简单地说，所描述的格式是使用一个八位字节记录一个DNS标签的长度（最多限制为63个八位字节），然后是标签内容。此操作将重复，直到FQDN中的所有标签（包括终止的零长度标签）都已用尽。对DHCPv6[RFC3315]第8节的任何更新也适用于该字段的编码。此选项的示例格式如图2所示，它表示FQDN“aftr.example.com.”。
+------+------+------+------+------+------+------+------+------+
| 0x04 | a | f | t | r | 0x07 | e | x | a |
+------+------+------+------+------+------+------+------+------+
| m | p | l | e | 0x03 | c | o | m | 0x00 |
+------+------+------+------+------+------+------+------+------+
+------+------+------+------+------+------+------+------+------+
| 0x04 | a | f | t | r | 0x07 | e | x | a |
+------+------+------+------+------+------+------+------+------+
| m | p | l | e | 0x03 | c | o | m | 0x00 |
+------+------+------+------+------+------+------+------+------+
Figure 2: Example tunnel-endpoint-name
图2：示例隧道端点名称
Note that in the specific case of the example tunnel-endpoint-name (Figure 2), the length of the tunnel-endpoint-name is 18 octets, and so an option-len field value of 18 would be used.
注意，在示例隧道端点名称的特定情况下（图2），隧道端点名称的长度为18个八位字节，因此将使用选项len字段值18。
The option is validated by confirming that all of the following conditions are met:
通过确认满足以下所有条件来验证该选项：
1. the option-len is greater than 3;
1. 选项len大于3；
2. the option-len is less than or equal to the remaining number of octets in the DHCPv6 packet;
2. 选项len小于或等于DHCPv6数据包中剩余的八位字节数；
3. the individual label lengths do not exceed the option length;
3. 单个标签长度不超过选项长度；
4. the tunnel-endpoint-name is of valid format as described in DHCPv6 Section 8 [RFC3315];
4. 隧道端点名称采用DHCPv6第8节[RFC3315]所述的有效格式；
5. there are no compression tags;
5. 没有压缩标签；
6. there is at least one label of nonzero length.
6. 至少有一个长度为非零的标签。
A DHCPv6 server SHOULD NOT send more than one AFTR-Name option. It SHOULD NOT permit the configuration of multiple names within one AFTR-Name option. Both of these conditions are handled as exceptions by the client, so an operator using software that does not perform these validations should be careful not to configure multiple domain names.
DHCPv6服务器不应发送多个AFTR名称选项。它不允许在一个AFTR名称选项中配置多个名称。这两种情况都由客户端作为例外情况处理，因此使用不执行这些验证的软件的操作员应小心，不要配置多个域名。
RFC 3315 Section 17.2.2 [RFC3315] describes how a DHCPv6 client and server negotiate configuration values using the Option Request option (OPTION_ORO). As a convenience to the reader, we mention here that a server will not reply with an AFTR-Name option if the client has not explicitly enumerated it on its Option Request option.
RFC 3315第17.2.2节[RFC3315]描述了DHCPv6客户机和服务器如何使用选项请求选项（选项）协商配置值。为了方便读者，我们在这里提到，如果客户机没有在其选项请求中显式地枚举AFTR名称选项，服务器将不会使用AFTR名称选项进行回复。
A client that supports the B4 functionality of DS-Lite (defined in [RFC6333]) and conforms to this specification MUST include OPTION_AFTR_NAME on its OPTION_ORO.
支持DS Lite B4功能（定义见[RFC6333]）并符合本规范的客户机必须在其选项上包含选项AFTR\U名称。
Because it requires a DNS name for address resolution, the client MAY also wish to include the OPTION_DNS_SERVERS [RFC3646] option on its OPTION_ORO.
由于地址解析需要DNS名称，客户端可能还希望在其选项\u ORO上包含选项\u DNS\u SERVERS[RFC3646]选项。
If the client receives the AFTR-Name option, it MUST verify the option contents as described in Section 3.
如果客户机收到AFTR Name选项，则必须按照第3节所述验证选项内容。
Note that in different environments, the B4 element and DHCPv6 client may be integrated, joined, or separated by a third piece of software. For the purpose of this specification, we refer to the "B4 system" when specifying implementation steps that may be processed at any stage of integration between the DHCPv6 client software and the B4 element it is configuring.
请注意，在不同的环境中，B4元素和DHCPv6客户端可以通过第三个软件集成、连接或分离。在本规范中，我们在指定可能在DHCPv6客户端软件与其配置的B4元素之间集成的任何阶段处理的实施步骤时，参考“B4系统”。
If the B4 system receives more than one AFTR-Name option, it MUST use only the first instance of that option.
如果B4系统接收到多个AFTR名称选项，则必须仅使用该选项的第一个实例。
If the AFTR-Name option contains more than one FQDN, as distinguished by the presence of multiple root labels, the B4 system MUST use only the first FQDN listed in the configuration.
如果AFTR Name选项包含多个FQDN（通过存在多个根标签来区分），则B4系统必须仅使用配置中列出的第一个FQDN。
The B4 system performs standard DNS resolution using the provided FQDN to resolve a AAAA Resource Record, as defined in [RFC3596] and STD 13 ([RFC1034], [RFC1035]).
B4系统使用提供的FQDN执行标准DNS解析，以解析[RFC3596]和STD 13（[RFC1034]、[RFC1035]）中定义的AAAA资源记录。
If any DNS response contains more than one IPv6 address, the B4 system picks only one IPv6 address and uses it as a remote tunnel endpoint for the interface being configured in the current message exchange. The B4 system MUST NOT establish more than one DS-Lite tunnel at the same time per interface. For a redundancy and high-availability discussion, see Appendix A.3 ("High Availability") of [RFC6333].
如果任何DNS响应包含多个IPv6地址，则B4系统仅选取一个IPv6地址，并将其用作当前消息交换中正在配置的接口的远程隧道端点。B4系统不得在每个接口上同时建立多个DS Lite隧道。有关冗余和高可用性的讨论，请参见[RFC6333]的附录a.3（“高可用性”）。
Note that a B4 system may have multiple network interfaces, and these interfaces may be configured differently; some may be connected to networks that call for DS-Lite, and some may be connected to networks that are using normal dual stack or other means. The B4 system should approach this specification on an interface-by-interface basis. For example, if the B4 system is attached to multiple networks that provide the AFTR-Name option, then the B4 system MUST configure a tunnel for each interface separately, as each DS-Lite tunnel provides IPv4 connectivity for each distinct interface. Means to bind an AFTR-Name and DS-Lite tunnel configuration to a given interface in a multiple-interface device are out of scope of this document.
注意，一个B4系统可能有多个网络接口，这些接口的配置可能不同；有些可能连接到调用DS Lite的网络，有些可能连接到使用普通双堆栈或其他方式的网络。B4系统应逐个接口接近本规范。例如，如果B4系统连接到提供AFTR名称选项的多个网络，则B4系统必须分别为每个接口配置一个隧道，因为每个DS Lite隧道为每个不同的接口提供IPv4连接。将AFTR名称和DS Lite隧道配置绑定到多接口设备中的给定接口的方法不在本文档的范围内。
This document does not present any new security issues, but as with all DHCPv6-derived configuration state, it is completely possible that the configuration is being delivered by a third party (Man in the Middle). As such, there is no basis for trusting the access level represented by the DS-Lite softwire connection, and DS-Lite should therefore not bypass any security mechanisms such as IP firewalls.
本文档没有提出任何新的安全问题，但与所有DHCPv6派生的配置状态一样，配置完全可能是由第三方（中间人）交付的。因此，不存在信任DS Lite软线连接所代表的访问级别的基础，因此DS Lite不应绕过任何安全机制，如IP防火墙。
[RFC3315] discusses DHCPv6-related security issues.
[RFC3315]讨论与DHCPv6相关的安全问题。
[RFC6333] discusses DS-Lite-related security issues.
[RFC6333]讨论与DS Lite相关的安全问题。
IANA has allocated a single DHCPv6 option code, 64, referencing this document, delineating OPTION_AFTR_NAME.
IANA分配了一个DHCPv6选项代码64，参考本文件，描述了选项名称。
The authors would like to thank Alain Durand, Rob Austein, Dave Thaler, Paul Selkirk, Ralph Droms, Mohamed Boucadair, Roberta Maglione, and Shawn Routhier for their valuable feedback and suggestions. The authors acknowledge significant support for this work, provided by Internet Systems Consortium, Inc.
作者要感谢阿兰·杜兰德、罗伯·奥斯汀、戴夫·泰勒、保罗·塞尔柯克、拉尔夫·德罗姆斯、穆罕默德·布卡代尔、罗伯塔·马格里奥尼和肖恩·劳希尔提供了宝贵的反馈和建议。作者感谢Internet Systems Consortium，Inc.对这项工作的大力支持。
This work has been partially supported by the Polish Ministry of Science and Higher Education under the European Regional Development Fund, Grant No. POIG.01.01.02-00-045/09-00 (Future Internet Engineering Project).
这项工作得到了波兰科学和高等教育部在欧洲区域发展基金（批准号POIG.01.01.02-00-045/09-00，未来互联网工程项目）下的部分支持。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[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., Ed., 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.，Ed.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003.
[RFC3596]Thomson，S.，Huitema，C.，Ksinant，V.，和M.Souissi，“支持IP版本6的DNS扩展”，RFC 3596，2003年10月。
[RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003.
[RFC3646]Droms，R.，Ed.“IPv6动态主机配置协议（DHCPv6）的DNS配置选项”，RFC 3646，2003年12月。
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011.
[RFC6333]Durand，A.，Droms，R.，Woodyatt，J.，和Y.Lee，“IPv4耗尽后的双栈Lite宽带部署”，RFC 63332011年8月。
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
Tomasz Mrugalski Gdansk University of Technology ul. Storczykowa 22B/12 Gdansk 80-177 Poland
格但斯克理工大学斯托奇科瓦22B/12格但斯克80-177波兰
Phone: +48 698 088 272
EMail: tomasz.mrugalski@eti.pg.gda.pl
Phone: +48 698 088 272
EMail: tomasz.mrugalski@eti.pg.gda.pl