Internet Engineering Task Force (IETF) Q. Sun
Request for Comments: 7341 Y. Cui
Category: Standards Track Tsinghua University
ISSN: 2070-1721 M. Siodelski
ISC
S. Krishnan
Ericsson
I. Farrer
Deutsche Telekom AG
August 2014
Internet Engineering Task Force (IETF) Q. Sun
Request for Comments: 7341 Y. Cui
Category: Standards Track Tsinghua University
ISSN: 2070-1721 M. Siodelski
ISC
S. Krishnan
Ericsson
I. Farrer
Deutsche Telekom AG
August 2014
DHCPv4-over-DHCPv6 (DHCP 4o6) Transport
DHCPv4-over-DHCPv6（DHCP 4o6）传输
Abstract
摘要
IPv4 connectivity is still needed as networks migrate towards IPv6. Users require IPv4 configuration even if the uplink to their service provider supports IPv6 only. This document describes a mechanism for obtaining IPv4 configuration information dynamically in IPv6 networks by carrying DHCPv4 messages over DHCPv6 transport. Two new DHCPv6 messages and two new DHCPv6 options are defined for this purpose.
随着网络向IPv6迁移，仍然需要IPv4连接。即使到其服务提供商的上行链路仅支持IPv6，用户也需要IPv4配置。本文档描述了通过DHCPv6传输传输DHCPv4消息，在IPv6网络中动态获取IPv4配置信息的机制。为此定义了两条新的DHCPv6消息和两个新的DHCPv6选项。
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/rfc7341.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7341.
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 ....................................................3
2. Requirements Language ...........................................3
3. Terminology .....................................................3
4. Applicability ...................................................4
5. Architecture Overview ...........................................4
6. New DHCPv6 Messages .............................................6
6.1. Message Types ..............................................6
6.2. Message Formats ............................................6
6.3. DHCPv4-query Message Flags .................................7
6.4. DHCPv4-response Message Flags ..............................7
7. New DHCPv6 Options ..............................................7
7.1. DHCPv4 Message Option Format ...............................7
7.2. DHCP 4o6 Server Address Option Format ......................8
8. Use of the DHCPv4-query Unicast Flag ............................9
9. DHCP 4o6 Client Behavior .......................................10
10. Relay Agent Behavior ..........................................12
11. DHCP 4o6 Server Behavior ......................................12
12. Security Considerations .......................................13
13. IANA Considerations ...........................................14
14. Contributors List .............................................14
15. References ....................................................14
15.1. Normative References .....................................14
15.2. Informative References ...................................15
1. Introduction ....................................................3
2. Requirements Language ...........................................3
3. Terminology .....................................................3
4. Applicability ...................................................4
5. Architecture Overview ...........................................4
6. New DHCPv6 Messages .............................................6
6.1. Message Types ..............................................6
6.2. Message Formats ............................................6
6.3. DHCPv4-query Message Flags .................................7
6.4. DHCPv4-response Message Flags ..............................7
7. New DHCPv6 Options ..............................................7
7.1. DHCPv4 Message Option Format ...............................7
7.2. DHCP 4o6 Server Address Option Format ......................8
8. Use of the DHCPv4-query Unicast Flag ............................9
9. DHCP 4o6 Client Behavior .......................................10
10. Relay Agent Behavior ..........................................12
11. DHCP 4o6 Server Behavior ......................................12
12. Security Considerations .......................................13
13. IANA Considerations ...........................................14
14. Contributors List .............................................14
15. References ....................................................14
15.1. Normative References .....................................14
15.2. Informative References ...................................15
As the migration towards IPv6 continues, IPv6-only networks will become more prevalent. In such networks, IPv4 connectivity will continue to be provided as a service over IPv6-only networks. In addition to provisioning IPv4 addresses for clients of this service, other IPv4 configuration parameters may also be needed (e.g., addresses of IPv4-only services).
随着向IPv6迁移的继续，仅IPv6网络将变得更加普遍。在这样的网络中，IPv4连接将继续作为一种服务在仅限IPv6的网络上提供。除了为此服务的客户端提供IPv4地址外，还可能需要其他IPv4配置参数（例如，仅IPv4服务的地址）。
This document describes a transport mechanism to carry DHCPv4 messages using the DHCPv6 protocol for the dynamic provisioning of IPv4 addresses and other DHCPv4 specific configuration parameters across IPv6-only networks. It leverages the existing DHCPv4 infrastructure, e.g., failover, DNS updates, DHCP Leasequery, etc.
本文档描述了一种传输机制，该机制使用DHCPv6协议在纯IPv6网络上动态提供IPv4地址和其他DHCPv4特定配置参数来传输DHCPv4消息。它利用现有的DHCPv4基础架构，例如故障切换、DNS更新、DHCP租赁等。
When IPv6 multicast is used to transport DHCP 4o6 messages, another benefit is that the operator can gain information about the underlying IPv6 network to which the DHCP 4o6 client is connected from the DHCPv6 relay agents through which the request has passed.
当IPv6多播用于传输DHCP 4o6消息时，另一个好处是，运营商可以从请求通过的DHCPv6中继代理获取有关DHCP 4o6客户端连接到的底层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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This document makes use of the following terms:
本文件使用了以下术语：
CPE: Customer Premises Equipment (also known as Customer Provided Equipment), which provides access for devices connected to a Local Area Network (LAN), typically at the customer's site/home, to the Internet Service Provider's (ISP's) network.
CPE：客户场所设备（也称为客户提供的设备），为连接到局域网（LAN）的设备（通常在客户的站点/家中）提供访问Internet服务提供商（ISP）网络的权限。
DHCP 4o6 client (or client): A DHCP client supporting both the DHCPv6 protocol [RFC3315] as well as the DHCPv4 over DHCPv6 protocol described in this document. Such a client is capable of requesting IPv6 configuration using DHCPv6 and IPv4 configuration using DHCPv4 over DHCPv6.
DHCP 4o6客户端（或客户端）：支持DHCPv6协议[RFC3315]以及本文档中描述的DHCPv4 over DHCPv6协议的DHCP客户端。这样的客户端能够使用DHCPv6请求IPv6配置，并通过DHCPv6请求使用DHCPv4的IPv4配置。
DHCP 4o6 server (or server): A DHCP server that is capable of processing DHCPv4 packets encapsulated in the DHCPv4 Message option (defined below).
DHCP 4o6服务器（或服务器）：能够处理封装在DHCPv4消息选项（定义见下文）中的DHCPv4数据包的DHCP服务器。
DHCPv4 over DHCPv6: A protocol (described in this document) used to carry DHCPv4 messages in the payload of DHCPv6 messages.
DHCPv4 over DHCPv6：用于在DHCPv6消息的有效负载中承载DHCPv4消息的协议（在本文档中描述）。
The mechanism described in this document is not universally applicable. This is intended as a special-purpose mechanism that will be implemented on nodes that must obtain IPv4 configuration information using DHCPv4 in specific environments where native DHCPv4 is not available. Such nodes are expected to follow the advice in Section 9; nodes that do not require this functionality are expected not to implement it, or not to enable it by default. This mechanism may be enabled using an administrative control, or it may be enabled automatically in accordance with the needs of some dual-stack transition mechanism such as [LW4OVER6]. Such mechanisms are beyond the scope of this document.
本文件中描述的机制并非普遍适用。这是一种专用机制，将在必须在本机DHCPv4不可用的特定环境中使用DHCPv4获取IPv4配置信息的节点上实现。此类节点应遵循第9节中的建议；不需要此功能的节点预计不会实现此功能，或者默认情况下不会启用此功能。该机制可以使用管理控件启用，也可以根据某些双堆栈转换机制（如[LW4OVER6]）的需要自动启用。这种机制超出了本文件的范围。
The architecture described here addresses a typical use case, where a DHCP client's uplink supports IPv6 only and the Service Provider's network supports IPv6 and limited IPv4 services. In this scenario, the client can only use the IPv6 network to access IPv4 services, so IPv4 services must be configured using IPv6 as the underlying network protocol.
这里描述的体系结构解决了一个典型的用例，其中DHCP客户端的上行链路仅支持IPv6，而服务提供商的网络支持IPv6和有限的IPv4服务。在此场景中，客户端只能使用IPv6网络访问IPv4服务，因此必须使用IPv6作为基础网络协议来配置IPv4服务。
Although the purpose of this document is to address the problem of communication between the DHCPv4 client and the DHCPv4 server, the mechanism that it describes does not restrict the transported messages types to DHCPv4 only. As the DHCPv4 message is a special type of BOOTP message, BOOTP messages [RFC951] MAY also be transported using the same mechanism.
尽管本文档的目的是解决DHCPv4客户端和DHCPv4服务器之间的通信问题，但它所描述的机制并没有将传输的消息类型仅限于DHCPv4。由于DHCPv4消息是一种特殊类型的BOOTP消息，因此也可以使用相同的机制传输BOOTP消息[RFC951]。
DHCP clients may be running on CPE devices, end hosts, or any other device that supports the DHCP-client function. This document uses the CPE as an example for describing the mechanism. This does not preclude any end host, or other device requiring IPv4 configuration, from implementing DHCPv4 over DHCPv6 in the future.
DHCP客户端可以在CPE设备、终端主机或支持DHCP客户端功能的任何其他设备上运行。本文档以CPE为例来描述该机制。这并不排除任何终端主机或其他需要IPv4配置的设备将来在DHCPv6上实现DHCPv4。
This mechanism works by carrying DHCPv4 messages encapsulated within the newly defined DHCPv6 messages. The DHCPv6-relay encapsulation is used solely to deliver DHCPv4 packets to a DHCPv4-capable server, and does not allocate any IPv6 addresses nor does it provide IPv6-configuration information to the client. Figure 1, below, illustrates one possible deployment architecture of this mechanism.
该机制通过携带封装在新定义的DHCPv6消息中的DHCPv4消息来工作。DHCPv6中继封装仅用于将DHCPv4数据包传送到支持DHCPv4的服务器，不分配任何IPv6地址，也不向客户端提供IPv6配置信息。下面的图1说明了该机制的一种可能的部署架构。
The DHCP 4o6 client implements a new DHCPv6 message called DHCPv4-query, which carries a DHCPv4 message encapsulated in the new DHCPv4 Message option. The DHCPv6 message can be transmitted either via DHCPv6 Relay Agents or directly to the DHCP 4o6 server.
DHCP 4o6客户端实现一个名为DHCPv4查询的新DHCPv6消息，该消息携带封装在新DHCPv4消息选项中的DHCPv4消息。DHCPv6消息可以通过DHCPv6中继代理或直接传输到DHCP 4o6服务器。
The server replies with a new DHCPv6 message called DHCPv4-response, which carries the DHCPv4 message from the server, encapsulated in the DHCPv4 Message option.
服务器使用名为DHCPv4 response的新DHCPv6消息进行响应，该消息携带来自服务器的DHCPv4消息，封装在DHCPv4消息选项中。
_____________ _____________
/ \ / \
| | | |
+--------+-+ IPv6 +-+-----------+-+ IPv6 +-+--------+
| DHCP 4o6 | Network | DHCPv6 | Network | DHCP 4o6 |
| Client +---------+ Relay Agent +---------+ Server |
| (on CPE) | | | | |
+--------+-+ +-+-----------+-+ +-+--------+
| | | |
\_____________/ \_____________/
_____________ _____________
/ \ / \
| | | |
+--------+-+ IPv6 +-+-----------+-+ IPv6 +-+--------+
| DHCP 4o6 | Network | DHCPv6 | Network | DHCP 4o6 |
| Client +---------+ Relay Agent +---------+ Server |
| (on CPE) | | | | |
+--------+-+ +-+-----------+-+ +-+--------+
| | | |
\_____________/ \_____________/
Figure 1: Architecture Overview
图1：架构概述
Before the client can use DHCPv4 over DHCPv6, it MUST obtain the necessary IPv6 configuration. The client requests the DHCP 4o6 Server Address option from the server by sending the option code in an Option Request option as described in [RFC3315]. If the server responds with the DHCP 4o6 Server Address option, it is an indication to the client to attempt using DHCPv4 over DHCPv6 to obtain IPv4 configuration. Otherwise, the client MUST NOT use DHCPv4 over DHCPv6 to request IPv4 configuration.
在客户端可以通过DHCPv6使用DHCPv4之前，它必须获得必要的IPv6配置。客户端通过发送选项请求选项中的选项代码，从服务器请求DHCP 4o6服务器地址选项，如[RFC3315]中所述。如果服务器使用DHCP 4o6服务器地址选项进行响应，则表示客户端尝试使用DHCPv4 over DHCPv6来获取IPv4配置。否则，客户端不得通过DHCPv6使用DHCPv4来请求IPv4配置。
The client obtains the address(es) of the DHCP 4o6 server(s) from the DHCP 4o6 Server Address option and uses it (them) to communicate with the DHCP 4o6 servers as described in Section 9. If the DHCP 4o6 Server Address option contains no addresses (is empty), the client uses the well-known All_DHCP_Relay_Agents_and_Servers multicast address to communicate with the DHCP 4o6 server(s).
客户端从DHCP 4o6服务器地址选项获取DHCP 4o6服务器的地址，并使用该地址与DHCP 4o6服务器通信，如第9节所述。如果DHCP 4o6服务器地址选项不包含地址（为空），客户端将使用众所周知的所有\u DHCP\u中继\u代理\u和\u服务器多播地址与DHCP 4o6服务器通信。
Before applying for an IPv4 address via a DHCPv4-query message, the client must identify a suitable network interface for the address. Once the request is acknowledged by the server, the client can configure the address and other relevant parameters on this interface. The mechanism for determining a suitable interface is out of the scope of the document.
在通过DHCPv4查询消息申请IPv4地址之前，客户端必须为该地址标识合适的网络接口。服务器确认请求后，客户端可以在此接口上配置地址和其他相关参数。确定合适接口的机制不在本文件范围内。
Two new DHCPv6 messages carry DHCPv4 messages between the client and the server using the DHCPv6 protocol: DHCPv4-query and DHCPv4-response. This section describes the structures of these messages.
两条新的DHCPv6消息使用DHCPv6协议在客户端和服务器之间传输DHCPv4消息：DHCPv4查询和DHCPv4响应。本节介绍这些消息的结构。
DHCPV4-QUERY (20): The DHCP 4o6 client sends a DHCPv4-query message to a DHCP 4o6 server. The DHCPv4 Message option carried by this message contains a DHCPv4 message that the DHCP 4o6 client uses to request IPv4 configuration parameters from the server.
DHCPV4-QUERY（20）：DHCP 4o6客户端向DHCP 4o6服务器发送DHCPV4查询消息。此消息携带的DHCPv4消息选项包含DHCPv4消息，DHCP 4o6客户端使用该消息从服务器请求IPv4配置参数。
DHCPV4-RESPONSE (21): A DHCP 4o6 server sends a DHCPv4-response message to a DHCP 4o6 client. It contains a DHCPv4 Message option carrying a DHCPv4 message in response to a DHCPv4 message received by the server in the DHCPv4 Message option of the DHCPv4-query message.
DHCPV4-RESPONSE（21）：DHCP 4o6服务器向DHCP 4o6客户端发送DHCPV4响应消息。它包含一个DHCPv4消息选项，其中包含一条DHCPv4消息，以响应服务器在DHCPv4查询消息的DHCPv4消息选项中接收到的DHCPv4消息。
Both DHCPv6 messages defined in this document share the following format:
本文档中定义的两条DHCPv6消息共享以下格式：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type | flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. options .
. (variable) .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type | flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. options .
. (variable) .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The Format of DHCPv4-query and DHCPv4-response Messages
图2:DHCPv4查询和DHCPv4响应消息的格式
msg-type: Identifies the message type. It can be either DHCPV4-QUERY (20) or DHCPV4-RESPONSE (21) corresponding to the contained DHCPv4-query or DHCPv4-response, respectively.
消息类型：标识消息类型。它可以是DHCPV4-QUERY（20）或DHCPV4-RESPONSE（21），分别对应于所包含的DHCPV4查询或DHCPV4响应。
flags: Specifies flags providing additional information required by the server to process the DHCPv4 message encapsulated in the DHCPv4-query message, or required by the client to process a DHCPv4 message encapsulated in the DHCPv4-response message.
flags：指定提供服务器处理DHCPv4查询消息中封装的DHCPv4消息所需的附加信息，或客户端处理DHCPv4响应消息中封装的DHCPv4消息所需的附加信息的标志。
options: Options carried by the message. The DHCPv4 Message Option (described in Section 7.1) MUST be carried by the message. Only DHCPv6 options for IPv4 configuration may be included in this field. It MUST NOT contain DHCPv6 options related solely to IPv6, or IPv6-only service configuration.
选项：消息携带的选项。DHCPv4消息选项（如第7.1节所述）必须由消息携带。此字段中只能包含IPv4配置的DHCPv6选项。它不能包含仅与IPv6或仅与IPv6服务配置相关的DHCPv6选项。
The "flags" field of the DHCPv4-query is used to carry additional information that may be used by the server to process the encapsulated DHCPv4 message. Currently, only one bit of this field is used. Remaining bits are reserved for the future use. The "flags" field has the following format:
DHCPv4查询的“标志”字段用于携带服务器可能用于处理封装的DHCPv4消息的附加信息。目前，仅使用此字段的一位。剩余的位保留供将来使用。“标志”字段的格式如下：
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U| MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: DHCPv4-query Flags Format
图3:DHCPv4查询标志格式
U: Unicast flag. If set to 1, it indicates that the DHCPv4 message encapsulated within the DHCPv4-query message would be sent to a unicast address if it were sent using IPv4. If this flag is set to 0, it indicates that the DHCPv4 message would be sent to the broadcast address if it were sent using IPv4. The usage of the flag is described in detail in Section 8.
U：单播标志。如果设置为1，则表示封装在DHCPv4查询消息中的DHCPv4消息将被发送到单播地址（如果使用IPv4发送）。如果此标志设置为0，则表示如果使用IPv4发送DHCPv4消息，则会将其发送到广播地址。第8节详细描述了标志的使用。
MBZ: Bits MUST be set to zero when sending and MUST be ignored when receiving.
MBZ：发送时必须将位设置为零，接收时必须忽略位。
This document introduces no flags to be carried in the "flags" field of the DHCPv4-response message. They are all reserved for future use. The DHCP 4o6 server MUST set all bits of this field to 0 and the DHCP 4o6 client MUST ignore the content in this field.
本文档未在DHCPv4响应消息的“标志”字段中引入任何标志。它们都是留作将来使用的。DHCP 4o6服务器必须将此字段的所有位设置为0，DHCP 4o6客户端必须忽略此字段中的内容。
The DHCPv4 Message option carries a DHCPv4 message that is sent by the client or the server. Such messages exclude any IP or UDP headers.
DHCPv4消息选项携带由客户端或服务器发送的DHCPv4消息。此类消息不包括任何IP或UDP头。
The format of the DHCPv4 Message option is:
DHCPv4消息选项的格式为：
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. DHCPv4-message .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. DHCPv4-message .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: DHCPv4 Message Option Format
图4:DHCPv4消息选项格式
option-code: OPTION_DHCPV4_MSG (87).
选项代码：选项_DHCPV4_MSG（87）。
option-len: Length of the DHCPv4 message.
选项len：DHCPv4消息的长度。
DHCPv4-message: The DHCPv4 message sent by the client or the server. In a DHCPv4-query message, it contains a DHCPv4 message sent by a client. In a DHCPv4-response message, it contains a DHCPv4 message sent by a server in response to a client.
DHCPv4消息：客户端或服务器发送的DHCPv4消息。在DHCPv4查询消息中，它包含由客户端发送的DHCPv4消息。在DHCPv4响应消息中，它包含服务器为响应客户端而发送的DHCPv4消息。
The DHCP 4o6 Server Address option is sent by a server to a client requesting IPv6 configuration using DHCPv6 [RFC3315]. It carries a list of DHCP 4o6 servers' IPv6 addresses that the client should contact to obtain IPv4 configuration. This list may include multicast and unicast addresses. The client sends its requests to all unique addresses carried in this option.
DHCP 4o6服务器地址选项由服务器发送到使用DHCPv6[RFC3315]请求IPv6配置的客户端。它包含DHCP 4o6服务器的IPv6地址列表，客户端应联系这些地址以获取IPv4配置。此列表可能包括多播和单播地址。客户端将其请求发送到此选项中包含的所有唯一地址。
This option may also carry no IPv6 addresses, which instructs the client to use the All_DHCP_Relay_Agents_and_Servers multicast address as the destination address.
此选项也可能不携带IPv6地址，这指示客户端使用所有\u DHCP\u中继\u代理\u和\u服务器多播地址作为目标地址。
The presence of this option in the server's response indicates to the client that it should use DHCPv4 over DHCPv6 to obtain IPv4 configuration. If the option is absent, the client MUST NOT enable DHCPv4-over-DHCPv6 functionality.
服务器响应中存在此选项表示客户端应使用DHCPv4而不是DHCPv6来获得IPv4配置。如果缺少该选项，则客户端不得启用DHCPv4-over-DHCPv6功能。
The format of the DHCP 4o6 Server Address option is:
DHCP 4o6服务器地址选项的格式为：
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(es) .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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(es) .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: DHCP 4o6 Servers Address Option Format
图5:DHCP 4o6服务器地址选项格式
option-code: OPTION_DHCP4_O_DHCP6_SERVER (88).
选项代码：选项DHCP4\U O\U DHCP6\U服务器（88）。
option-len: Length of the IPv6 address(es) carried by the option, i.e., multiple of 16 octets. Minimal length of this option is 0.
选项len：该选项携带的IPv6地址的长度，即16个八位字节的倍数。此选项的最小长度为0。
IPv6 Address: Zero or more IPv6 addresses of the DHCP 4o6 server(s).
IPv6地址：DHCP 4o6服务器的零个或多个IPv6地址。
A DHCPv4 client conforming to [RFC2131] may send its DHCPREQUEST message to either a broadcast or unicast address depending on its state. For example, a client in the RENEWING state uses a unicast address to contact the DHCPv4 server to renew its lease. A client in the REBINDING state uses a broadcast address.
符合[RFC2131]的DHCPv4客户端可根据其状态向广播或单播地址发送其DHCPREQUEST消息。例如，处于续订状态的客户端使用单播地址与DHCPv4服务器联系以续订其租约。处于重新绑定状态的客户端使用广播地址。
In DHCPv4 over DHCPv6, IPv6 is used to deliver DHCPv4 messages to the DHCP 4o6 server. There is no relation between the outer IPv6 address and the inner DHCPv4 message. As a result, the server is unable to determine whether the received DHCPv4 messages should have been sent using broadcast or unicast in IPv4 by checking the IPv6 address.
在DHCPv4 over DHCPv6中，IPv6用于将DHCPv4消息传递到DHCP 4o6服务器。外部IPv6地址与内部DHCPv4消息之间没有关系。因此，服务器无法通过检查IPv6地址来确定接收到的DHCPv4消息是否应使用IPv4中的广播或单播发送。
In order to allow the server to determine the client's state, the Unicast flag is carried in the DHCPv4-query message. The client MUST set this flag to 1 when the DHCPv4 message would have been sent to the unicast address if using DHCPv4 over IPv4. This flag MUST be set to 0 if the DHCPv4 client would have sent the message to the broadcast address in IPv4. The choice whether a given message should be sent to a broadcast or unicast address is made based on the [RFC2131] and its extensions.
为了允许服务器确定客户机的状态，DHCPv4查询消息中带有单播标志。如果通过IPv4使用DHCPv4，则当DHCPv4消息将被发送到单播地址时，客户端必须将此标志设置为1。如果DHCPv4客户端将消息发送到IPv4中的广播地址，则此标志必须设置为0。根据[RFC2131]及其扩展，可以选择将给定消息发送到广播地址还是单播地址。
Note: The Unicast flag reflects how the DHCPv4 packet would have been sent; not how the DHCPv6 packet itself is sent.
注：单播标志反映DHCPv4数据包的发送方式；而不是DHCPv6数据包本身的发送方式。
The client MUST obtain necessary IPv6 configuration from a DHCPv6 server before using DHCPv4 over DHCPv6. The client requests the DHCP 4o6 Server Address option using the Option Request option (ORO) in every Solicit, Request, Renew, Rebind, and Information-request message. If the DHCPv6 server includes the DHCP 4o6 Server Address option in its response, it is an indication that the client can use DHCPv4 over DHCPv6 to obtain the IPv4 configuration (by sending DHCPv4 messages encapsulated in DHCPv4-query messages).
在DHCPv6上使用DHCPv4之前，客户端必须从DHCPv6服务器获得必要的IPv6配置。客户端在每个请求、请求、续订、重新绑定和信息请求消息中使用选项请求选项（ORO）请求DHCP 4o6服务器地址选项。如果DHCPv6服务器在其响应中包含DHCP 4o6服务器地址选项，则表示客户端可以通过DHCPv6使用DHCPv4来获得IPv4配置（通过发送封装在DHCPv4查询消息中的DHCPv4消息）。
The client MUST NOT use DHCPv4 over DHCPv6 to request IPv4 configuration if the DHCPv6 server does not include the DHCP 4o6 Server Address option. If the IPv6 configuration that contained the DHCP 4o6 Server Address option subsequently expires, or if the renewed IPv6 configuration does not contain the DHCP 4o6 Server Address option, the client MUST stop using DHCPv4 over DHCPv6 to request or renew IPv4 configuration. However, the client continues to request DHCP 4o6 Server Address option in the messages sent to the DHCPv6 server as long as it desires to use DHCPv4 over DHCPv6.
如果DHCPv6服务器不包括DHCP 4o6服务器地址选项，则客户端不得使用DHCPv4 over DHCPv6来请求IPv4配置。如果包含DHCP 4o6服务器地址选项的IPv6配置随后过期，或者如果续订的IPv6配置不包含DHCP 4o6服务器地址选项，则客户端必须停止使用DHCPv4 over DHCPv6来请求或续订IPv4配置。但是，只要客户端希望通过DHCPv6使用DHCPv4，它就会继续在发送到DHCPv6服务器的消息中请求DHCP 4o6服务器地址选项。
It is possible in a multihomed configuration for there to be more than one DHCPv6 configuration containing a DHCP 4o6 Server Address Option active at the same time. In this case, the configurations are treated as being independent, so that when any such configuration is active, a DHCPv4-over-DHCPv6 function may be enabled for that configuration.
在多主机配置中，可能有多个DHCPv6配置同时包含一个DHCP 4o6服务器地址选项处于活动状态。在这种情况下，配置被视为独立的，因此当任何此类配置处于活动状态时，可以为该配置启用DHCPv4-over-DHCPv6功能。
An implementation may also treat such configurations as being exclusive, such that only one is kept active at a time. In this case, the client keeps the same configuration active continuously as long as it is valid. If that configuration becomes invalid but one or more other configurations remain valid, the client activates one of the remaining valid configurations.
实现还可以将此类配置视为独占配置，以便一次只有一个配置保持活动状态。在这种情况下，只要相同的配置有效，客户机就会持续保持该配置处于活动状态。如果该配置无效，但一个或多个其他配置仍然有效，则客户端将激活剩余的有效配置之一。
Which strategy to follow is dependent on the implementation: keeping multiple configurations active at the same time may provide useful redundancy in some applications but may be needlessly complex in other cases.
遵循哪种策略取决于实现：同时保持多个配置处于活动状态可能会在某些应用程序中提供有用的冗余，但在其他情况下可能会不必要地复杂。
If the client receives the DHCP 4o6 Server Address option and DHCPv4 [RFC2131] is used on the interface over which the DHCPv6 option was received, the client MUST stop using the IPv4 configuration received using DHCPv4 on this interface. The client MAY send a DHCPRELEASE to the DHCPv4 server to relinquish an existing lease as described in Section 4.4.6 of [RFC2131]. The client MUST NOT use DHCPv4 on this interface as long as it receives DHCP 4o6 Server Address option in the messages received from the DHCPv6 server.
如果客户端接收到DHCP 4o6服务器地址选项，并且在接收到DHCPv6选项的接口上使用了DHCPv4[RFC2131]，则客户端必须停止在此接口上使用使用DHCPv4接收的IPv4配置。客户可以向DHCPv4服务器发送DHCPRELEASE，以放弃[RFC2131]第4.4.6节中所述的现有租约。只要从DHCPv6服务器接收的消息中包含DHCP 4o6服务器地址选项，客户端就不能在此接口上使用DHCPv4。
If the client receives a DHCP 4o6 Server Address option that contains no IP addresses, i.e., the option is empty, the client MUST send its requests to the All_DHCP_Relay_Agents_and_Servers multicast address. If there is a list of IP addresses in the option, the client SHOULD send requests to each unique address carried by the option.
如果客户端收到不包含IP地址的DHCP 4o6服务器地址选项，即该选项为空，则客户端必须将其请求发送到所有\u DHCP\u中继\u代理\u和\u服务器多播地址。如果该选项中有IP地址列表，则客户端应向该选项携带的每个唯一地址发送请求。
If the client obtained stateless IPv6 configuration by sending an Information-request message to the server, the client MUST follow the rules in [RFC4242] to periodically refresh the DHCPv4-over-DHCPv6 configuration (i.e., list of DHCP 4o6 servers) as well as other configuration data. The client that obtained stateful IPv6 configuration will refresh the status of DHCPv4-over-DHCPv6 function when extending a lifetime of acquired IPv6 address (Renew and Rebind messages).
如果客户端通过向服务器发送信息请求消息获得无状态IPv6配置，则客户端必须遵循[RFC4242]中的规则定期刷新DHCPv4-over-DHCPv6配置（即DHCP 4o6服务器列表）以及其他配置数据。获得有状态IPv6配置的客户端将在延长获取的IPv6地址的生存期（续订和重新绑定消息）时刷新DHCPv4-over-DHCPv6函数的状态。
The client MUST employ an IPv6 address of an appropriate scope from which to source the DHCPv4-query message. When the client sends a DHCPv4-query message to the multicast address, it MUST use a link-local address as the source address as described in [RFC3315]. When the client sends a DHCPv4-query message using unicast, the source address MUST be an address of appropriate scope, acquired in advance.
客户端必须使用适当作用域的IPv6地址，从该地址发出DHCPv4查询消息。当客户端向多播地址发送DHCPv4查询消息时，它必须使用链接本地地址作为源地址，如[RFC3315]中所述。当客户端使用单播发送DHCPv4查询消息时，源地址必须是预先获取的适当范围的地址。
The client generates a DHCPv4 message and stores it verbatim in the DHCPv4 Message option carried by the DHCPv4-query message. The client MUST put exactly one DHCPv4 Message option into a single DHCPv4-query message. The client MUST NOT request the DHCP 4o6 Server Address option in the DHCPv4-query message.
客户端生成一条DHCPv4消息，并将其逐字存储在DHCPv4查询消息携带的DHCPv4消息选项中。客户端必须将一个DHCPv4消息选项放入单个DHCPv4查询消息中。客户端不得在DHCPv4查询消息中请求DHCP 4o6服务器地址选项。
The client MUST follow the rules defined in Section 8 when setting the Unicast flag based on the DHCPv4 destination.
基于DHCPv4目的地设置单播标志时，客户端必须遵循第8节中定义的规则。
On receiving a DHCPv4-response message, the client MUST look for the DHCPv4 Message option within this message. If this option is not found, the DHCPv4-response message is discarded. If the DHCPv4 Message option is present, the client extracts the DHCPv4 message it contains and processes it as described in Section 4.4 of [RFC2131].
在接收到DHCPv4响应消息时，客户端必须在此消息中查找DHCPv4消息选项。如果未找到此选项，则丢弃DHCPv4响应消息。如果存在DHCPv4消息选项，则客户端提取其包含的DHCPv4消息，并按照[RFC2131]第4.4节中的说明进行处理。
When dealing with IPv4 configuration, the client MUST follow the normal DHCPv4 retransmission requirements and strategy as specified in Section 4.1 of [RFC2131]. There are no explicit transmission parameters associated with a DHCPv4-query message, as this is governed by the DHCPv4 "state machine" [RFC2131].
在处理IPv4配置时，客户端必须遵循[RFC2131]第4.1节中规定的正常DHCPv4重传要求和策略。没有与DHCPv4查询消息关联的显式传输参数，因为这是由DHCPv4“状态机”[RFC2131]控制的。
The client MUST implement [RFC4361] to ensure that the device correctly identifies itself. It MUST send a 'client identifier' option when using DHCPv4 over DHCPv6.
客户端必须实现[RFC4361]，以确保设备正确识别自身。在DHCPv6上使用DHCPv4时，它必须发送“客户端标识符”选项。
When a DHCPv6 relay agent receives a DHCPv4-query message, it may not recognize this message. The unknown message MUST be forwarded as described in [RFC7283].
当DHCPv6中继代理收到DHCPv4查询消息时，它可能无法识别此消息。必须按照[RFC7283]中的说明转发未知消息。
A DHCPv6 relay agent that can recognize DHCP 4o6 messages MAY allow the configuration of a separate set of destination addresses for such messages in addition to the destination addresses used for relaying the other DHCPv6 messages. To implement this function, the relay checks the received DHCPv6 message type and forwards according to the following logic:
能够识别DHCP 4o6消息的DHCPv6中继代理除了用于中继其他DHCPv6消息的目的地地址之外，还可以允许为此类消息配置单独的目的地地址集。为实现此功能，继电器检查接收到的DHCPv6消息类型，并根据以下逻辑转发：
1. If the message type is DHCPV4-QUERY, the packet is relayed to the configured DHCP 4o6 Server's address(es) in the form of a normal DHCPv6 packet (i.e., DHCPv6/UDP/IPv6).
1. 如果消息类型为DHCPV4-QUERY，则数据包将以正常DHCPv6数据包（即DHCPv6/UDP/IPv6）的形式中继到配置的DHCP 4o6服务器地址。
2. For any other DHCPv6 message type, forward according to section 20 of [RFC3315].
2. 对于任何其他DHCPv6消息类型，根据[RFC3315]第20节转发。
The above logic only allows for separate relay destinations configured on the relay agent closest to the client (single relay hop). Multiple relaying hops are not considered in the case of separate relay destinations.
上述逻辑仅允许在距离客户端最近的中继代理上配置单独的中继目的地（单中继跃点）。在单独中继目的地的情况下，不考虑多个中继跳。
When the server receives a DHCPv4-query message from a client, it searches for the DHCPv4 Message option. The server discards a packet without this option. In addition, the server MAY notify an administrator about the receipt of this malformed packet. The mechanism for this notification is out of scope for this document.
当服务器从客户端接收到DHCPv4查询消息时，它将搜索DHCPv4消息选项。服务器丢弃没有此选项的数据包。此外，服务器可能会通知管理员收到此格式错误的数据包。此通知的机制超出了本文档的范围。
If the server finds a valid DHCPv4 Message option, it extracts the original DHCPv4 message. Since the DHCPv4 message is encapsulated in the DHCPv6 message, it lacks the information that is typically used by the DHCPv4 server, implementing [RFC2131], to make address-allocation decisions, e.g., giaddr for relayed messages and IPv4 address of the interface that the server is using to communicate with a directly connected client. Therefore, the DHCP 4o6 server allocates addresses according to the policies on local address assignment determined by the server administrator. For example, if the DHCPv4-query message has been sent via a relay, the server MAY use the link-address field of the Relay-forward message as a lookup for the IPv4 subnet from which to assign a DHCPv4 address. If the DHCPv4-query message has been sent from a directly connected client,
如果服务器找到有效的DHCPv4消息选项，它将提取原始DHCPv4消息。由于DHCPv4消息封装在DHCPv6消息中，因此它缺少DHCPv4服务器通常使用的信息，实现[RFC2131]，以做出地址分配决策，例如，中继消息的giaddr和服务器用于与直接连接的客户端通信的接口的IPv4地址。因此，DHCP 4o6服务器根据服务器管理员确定的本地地址分配策略分配地址。例如，如果DHCPv4查询消息已通过中继发送，则服务器可以使用中继转发消息的链路地址字段作为IPv4子网的查找，从中分配DHCPv4地址。如果DHCPv4查询消息是从直接连接的客户端发送的，
the server MAY use the IPv6 source address of the message to determine the appropriate IPv4 subnet to use for DHCPv4 address assignment.
服务器可以使用消息的IPv6源地址来确定用于DHCPv4地址分配的适当IPv4子网。
Alternatively, the server may act as a DHCPv4 relay agent and forward the DHCPv4 packet to a "normal" DHCPv4 server. The details of such a solution have not been considered by the working group; describing that solution is out of scope of this document and is left as future work should the need for it arise.
或者，服务器可以充当DHCPv4中继代理，并将DHCPv4分组转发到“正常”DHCPv4服务器。工作组尚未审议这种解决办法的细节；描述该解决方案超出了本文件的范围，如果需要，将留作将来的工作。
The server SHOULD use the "flags" field of the DHCPv4-query message to create a response (server to client DHCPv4 message). The use of this field is described in detail in Section 8.
服务器应使用DHCPv4查询消息的“标志”字段创建响应（服务器到客户端DHCPv4消息）。第8节详细介绍了该字段的使用。
When an appropriate DHCPv4 response is created, the server places it in the payload of a DHCPv4 Message option, which it puts into the DHCPv4-response message.
创建适当的DHCPv4响应后，服务器将其放入DHCPv4消息选项的有效负载中，并将其放入DHCPv4响应消息中。
If the DHCPv4-query message was received directly by the server, the DHCPv4-response message MUST be unicast from the interface on which the original message was received.
如果服务器直接接收DHCPv4查询消息，则DHCPv4响应消息必须从接收原始消息的接口单播。
If the DHCPv4-query message was received in a Relay-forward message, the server creates a Relay-reply message with the DHCPv4-response message in the payload of a Relay Message option, and responds as described in Section 20.3 of [RFC3315].
如果在中继转发消息中接收到DHCPv4查询消息，则服务器将在中继消息选项的有效负载中使用DHCPv4响应消息创建中继回复消息，并按照[RFC3315]第20.3节中的说明进行响应。
In this specification, DHCPv4 messages are encapsulated in the newly defined option and messages. This is similar to the handling of the current relay agent messages. In order to bypass firewalls or network authentication gateways, a malicious attacker may leverage this feature to convey other messages using DHCPv6, i.e., use DHCPv6 as a form of encapsulation. However, the potential risk from this is no more severe than that with the current DHCPv4 and DHCPv6 practice.
在本规范中，DHCPv4消息封装在新定义的选项和消息中。这与当前中继代理消息的处理类似。为了绕过防火墙或网络身份验证网关，恶意攻击者可以利用此功能使用DHCPv6传递其他消息，即使用DHCPv6作为封装形式。然而，由此产生的潜在风险并不比当前DHCPv4和DHCPv6做法的风险更严重。
It is possible for a rogue server to reply with a DHCP 4o6 Server Address option containing duplicated IPv6 addresses, which could cause an amplification attack. To avoid this, the client MUST check if there are duplicate IPv6 addresses in a DHCP 4o6 Server Address option when receiving one. The client MUST ignore any but the first instance of each address.
恶意服务器可能会使用包含重复IPv6地址的DHCP 4o6服务器地址选项进行应答，这可能会导致放大攻击。为了避免这种情况，客户端在接收DHCP 4o6服务器地址选项时，必须检查该选项中是否存在重复的IPv6地址。客户端必须忽略每个地址的第一个实例以外的任何实例。
When considering whether to enable DHCPv4-over-DHCPv6, one important consideration is that when it is enabled, this gives the DHCPv6 server the ability to shut off DHCPv4 traffic, and, consequently, IPv4 traffic, on the interface that is configured to do DHCPv4-over-
在考虑是否启用DHCPv4-over-DHCPv6时，一个重要的考虑因素是，当启用DHCPv4-over-DHCPv6时，DHCPv6服务器能够在配置为执行DHCPv4-over的接口上关闭DHCPv4流量，从而关闭IPv4流量-
DHCPv6. For this reason, DHCPv4-over-DHCPv6 should only be enabled in situations where there is a clear trust relationship that eliminates this concern. For instance, a CPE device can safely enable this on its WAN interface, because it is reasonable to assume that an ISP will not accidentally configure DHCPv4 over DHCPv6 service on that link, and that it will be impractical for an attacker to set up a rogue DHCPv6 server in the ISP's network.
DHCPv6。因此，DHCPv4-over-DHCPv6仅应在存在消除此问题的明确信任关系的情况下启用。例如，CPE设备可以在其WAN接口上安全地启用此功能，因为可以合理地假设ISP不会意外地在该链路上通过DHCPv6服务配置DHCPv4，并且攻击者在ISP的网络中设置恶意DHCPv6服务器是不切实际的。
IANA has allocated two DHCPv6 option codes for use by OPTION_DHCPV4_MSG (87) and OPTION_DHCP4_O_DHCP6_SERVER (88) from the "Option Codes" table. Also, IANA has allocated two DHCPv6 message type codes for the DHCPV4-QUERY (20) and DHCPV4-RESPONSE (21) from the "Message Types" table of the "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" registry. Both tables can be found at <http://www.iana.org/assignments/dhcpv6-parameters/>.
IANA已从“选项代码”表中分配了两个DHCPv6选项代码，供option_DHCPV4_MSG（87）和option_DHCP4_O_DHCP6_服务器（88）使用。此外，IANA还从“IPv6动态主机配置协议（DHCPv6）”注册表的“消息类型”表中为DHCPV4-QUERY（20）和DHCPV4-RESPONSE（21）分配了两个DHCPv6消息类型代码。这两个表格可在<http://www.iana.org/assignments/dhcpv6-parameters/>.
Many thanks to Ted Lemon, Bernie Volz, Tomek Mrugalski, Cong Liu, and Yuchi Chen for their great contributions to the specification.
非常感谢Ted Lemon、Bernie Volz、Tomek Mrugalski、Cong Liu和Yuchi Chen为规范做出的巨大贡献。
[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月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC21311997年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月。
[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月。
[RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)", RFC 4361, February 2006.
[RFC4361]Lemon，T.和B.Sommerfeld，“动态主机配置协议第四版（DHCPv4）的节点特定客户端标识符”，RFC 4361，2006年2月。
[RFC7283] Cui, Y., Sun, Q., and T. Lemon, "Handling Unknown DHCPv6 Messages", RFC 7283, July 2014.
[RFC7283]Cui，Y.，Sun，Q.，和T.Lemon，“处理未知DHCPv6消息”，RFC 7283，2014年7月。
[LW4OVER6] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. Farrer, "Lightweight 4over6: An Extension to the DS-Lite Architecture", Work in Progress, June 2014.
[LW4OVER6]崔，Y.，孙，Q.，布卡代尔，M.，邹，T.，李，Y.，和I.Farrer，“轻量级4over6：DS Lite架构的扩展”，正在进行的工作，2014年6月。
[RFC951] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951, September 1985.
[RFC951]Croft，B.和J.Gilmore，“引导协议”，RFC9511985年9月。
Authors' Addresses
作者地址
Qi Sun Tsinghua University Beijing 100084 P.R. China
齐孙清华大学中国北京100084
Phone: +86-10-6278-5822
EMail: sunqi@csnet1.cs.tsinghua.edu.cn
Phone: +86-10-6278-5822
EMail: sunqi@csnet1.cs.tsinghua.edu.cn
Yong Cui Tsinghua University Beijing 100084 P.R. China
清华大学北京100084
Phone: +86-10-6260-3059
EMail: yong@csnet1.cs.tsinghua.edu.cn
Phone: +86-10-6260-3059
EMail: yong@csnet1.cs.tsinghua.edu.cn
Marcin Siodelski Internet Systems Consortium 950 Charter Street Redwood City, CA 94063 USA
美国加利福尼亚州红木市查特街950号Marcin Siodelski互联网系统联合会，邮编94063
EMail: msiodelski@gmail.com
EMail: msiodelski@gmail.com
Suresh Krishnan Ericsson 8400 Blvd. Decarie Town of Mount Royal, Quebec Canada
Suresh Krishnan Ericsson 8400大道。加拿大魁北克皇家山的迪克里镇
EMail: suresh.krishnan@ericsson.com
EMail: suresh.krishnan@ericsson.com
Ian Farrer Deutsche Telekom AG CTO-ATI, Landgrabenweg 151 Bonn, NRW 53227 Germany
Ian Farrer Deutsche Telekom AG CTO-ATI，德国新南威尔士州波恩市兰德格拉本韦151号，邮编53227
EMail: ian.farrer@telekom.de
EMail: ian.farrer@telekom.de