Internet Engineering Task Force (IETF) I. Farrer
Request for Comments: 8539 Deutsche Telekom AG
Updates: 7598 Q. Sun
Category: Standards Track Y. Cui
ISSN: 2070-1721 L. Sun
Tsinghua University
March 2019
Internet Engineering Task Force (IETF) I. Farrer
Request for Comments: 8539 Deutsche Telekom AG
Updates: 7598 Q. Sun
Category: Standards Track Y. Cui
ISSN: 2070-1721 L. Sun
Tsinghua University
March 2019
Softwire Provisioning Using DHCPv4 over DHCPv6
通过DHCPv6使用DHCPv4的软线资源调配
Abstract
摘要
DHCPv4 over DHCPv6 (RFC 7341) is a mechanism for dynamically configuring IPv4 for use as an over-the-top service in an IPv6-only network. Softwires are an example of such a service. For DHCPv4 over DHCPv6 (DHCP 4o6) to function with some IPv4-over-IPv6 softwire mechanisms and deployment scenarios (e.g., RFC 7596 or RFC 7597), the operator needs to know the IPv6 address that the client will use as the source of an IPv4-in-IPv6 softwire tunnel. This address, in conjunction with the client's IPv4 address, and (in some deployments) the Port Set ID are used to create a binding table entry in the operator's softwire tunnel concentrator. This memo defines a DHCPv6 option to convey IPv6 parameters for establishing the softwire tunnel and a DHCPv4 option (to be used only with DHCP 4o6) to communicate the source tunnel IPv6 address between the DHCP 4o6 client and server. It is designed to work in conjunction with the IPv4 address allocation process.
DHCPv4 over DHCPv6（RFC 7341）是一种用于动态配置IPv4的机制，以便在仅限IPv6的网络中用作over-the-top服务。软线就是这种服务的一个例子。要使DHCPv4 over DHCPv6（DHCP 4o6）与某些IPv4-over-IPv6软线机制和部署场景（例如，RFC 7596或RFC 7597）一起工作，运营商需要知道客户端将用作IPv4-in-IPv6软线隧道源的IPv6地址。此地址与客户端的IPv4地址以及（在某些部署中）端口集ID一起用于在运营商的软线隧道集中器中创建绑定表项。此备忘录定义了一个DHCPv6选项，用于传递用于建立软线隧道的IPv6参数，以及一个DHCPv4选项（仅与DHCP 4o6一起使用），用于在DHCP 4o6客户端和服务器之间传递源隧道IPv6地址。它被设计为与IPv4地址分配过程一起工作。
"DHCPv6 Options for Configuration of Softwire Address and Port-Mapped Clients" (RFC 7598) describes a deterministic DHCPv6-based mechanism for provisioning softwires. This document updates RFC 7598, allowing OPTION_S46_BR (90) to be enumerated in the DHCPv6 client's Option Request Option (ORO) request and to appear directly within subsequent messages sent by the DHCPv6 server.
“用于配置软线地址和端口映射客户端的DHCPv6选项”（RFC 7598）描述了一种用于配置软线的基于DHCPv6的确定性机制。本文档更新了RFC 7598，允许选项_S46_BR（90）在DHCPv6客户端的选项请求选项（ORO）请求中枚举，并直接出现在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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8539.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8539.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 IETF信托基金和被确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Updating RFC 7598 to Permit the Reuse of
OPTION_S46_BR (90) . . . . . . . . . . . . . . . . . . . 5
5. DHCP 4o6 IPv6/IPv4 Binding Message Flow . . . . . . . . . . . 6
6. DHCP Options . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. DHCPv6 Softwire Source Binding Prefix Hint Option . . . . 7
6.2. DHCP 4o6 Softwire Source Address Option . . . . . . . . . 8
7. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Client Initialization . . . . . . . . . . . . . . . . . . 9
7.2. Renewing or Rebinding the IPv4 Address Lease and
Softwire Source Address . . . . . . . . . . . . . . . . . 10
7.2.1. Changing the Bound IPv6 Softwire Source Address . . . 10
7.3. Releasing the IPv4 Address Lease and Softwire
Source Address . . . . . . . . . . . . . . . . . . . . . 11
7.4. OPTION_S46_BIND_IPV6_PREFIX Validation Behavior . . . . . 11
7.5. Client and Server Softwire Source Address Mismatch . . . 11
7.6. Use with Dynamic, Shared IPv4 Addresses . . . . . . . . . 12
8. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Changing the Bound IPv6 Source Address . . . . . . . . . 12
8.2. Handling Conflicts between Clients' Bound IPv6 Source
Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9.1. Client Privacy Considerations . . . . . . . . . . . . . . 14
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . 17
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Updating RFC 7598 to Permit the Reuse of
OPTION_S46_BR (90) . . . . . . . . . . . . . . . . . . . 5
5. DHCP 4o6 IPv6/IPv4 Binding Message Flow . . . . . . . . . . . 6
6. DHCP Options . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. DHCPv6 Softwire Source Binding Prefix Hint Option . . . . 7
6.2. DHCP 4o6 Softwire Source Address Option . . . . . . . . . 8
7. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Client Initialization . . . . . . . . . . . . . . . . . . 9
7.2. Renewing or Rebinding the IPv4 Address Lease and
Softwire Source Address . . . . . . . . . . . . . . . . . 10
7.2.1. Changing the Bound IPv6 Softwire Source Address . . . 10
7.3. Releasing the IPv4 Address Lease and Softwire
Source Address . . . . . . . . . . . . . . . . . . . . . 11
7.4. OPTION_S46_BIND_IPV6_PREFIX Validation Behavior . . . . . 11
7.5. Client and Server Softwire Source Address Mismatch . . . 11
7.6. Use with Dynamic, Shared IPv4 Addresses . . . . . . . . . 12
8. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Changing the Bound IPv6 Source Address . . . . . . . . . 12
8.2. Handling Conflicts between Clients' Bound IPv6 Source
Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9.1. Client Privacy Considerations . . . . . . . . . . . . . . 14
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . 17
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
Deterministic IPv4-over-IPv6 transition technologies require that elements be preconfigured with binding rules for routing traffic to clients. This places a constraint on the choice of address used as the client's softwire source address: it must use a predetermined prefix, which is usually configured on the home gateway device. [RFC7598] describes a DHCPv6-based mechanism for provisioning such deterministic softwires.
确定性IPv4-over-IPv6转换技术要求使用绑定规则预先配置元素，以便将流量路由到客户端。这对用作客户端软线源地址的地址的选择施加了限制：它必须使用预定前缀，该前缀通常在家庭网关设备上配置。[RFC7598]描述了一种基于DHCPv6的机制，用于提供此类确定性软连线。
A dynamic provisioning model, such as using DHCPv4 over DHCPv6 (DHCP 4o6) [RFC7341], allows much more flexibility in the location of the IPv4-over-IPv6 softwire source address. In this model, the IPv6 address is dynamically communicated back to the service provider, allowing the corresponding softwire configuration to be created in the border relay (BR).
动态资源调配模型，例如使用DHCPv4 over DHCPv6（DHCP 4o6）[RFC7341]，允许在IPv4 over-IPv6软线源地址的位置上具有更大的灵活性。在此模型中，IPv6地址被动态地传回服务提供商，从而允许在边界中继（BR）中创建相应的软线配置。
The DHCP 4o6 client and softwire client could be run on end devices attached to a network segment using any routable IPv6 prefix allocated to an end user, located anywhere within an arbitrary home network topology. Dynamic allocation also helps to optimize IPv4 resource usage, because only clients that are actively renewing their IPv4 lease hold on to the address.
DHCP 4o6客户端和softwire客户端可以使用分配给终端用户的任何可路由IPv6前缀在连接到网段的终端设备上运行，这些终端设备位于任意家庭网络拓扑中的任何位置。动态分配还有助于优化IPv4资源使用，因为只有主动续订IPv4租约的客户端才能保留该地址。
This document describes a mechanism for dynamically provisioning softwires created using DHCP 4o6, including provisioning the client with the address of the softwire BR and informing the service provider of a client's binding between the dynamically allocated IPv4 address and Port Set ID and the IPv6 address that the softwire initiator will use for accessing IPv4-over-IPv6 services.
本文档描述了一种使用DHCP 4o6动态配置软线的机制，包括向客户端提供软线BR的地址，并通知服务提供商动态分配的IPv4地址和端口集ID与软线启动器将用于访问IPv4-over-IPv6服务的IPv6地址之间的客户端绑定。
The mechanism operates alongside the DHCP 4o6 message flows to communicate the binding information over the IPv6-only network. The DHCP 4o6 server provides a single point in the network that holds the current client binding information. The service provider can then use this binding information to provision other functional elements, such as the BR(s).
该机制与DHCP 4o6消息流一起运行，以通过仅IPv6的网络传输绑定信息。DHCP 4o6服务器在网络中提供一个保存当前客户端绑定信息的单点。然后，服务提供者可以使用该绑定信息来提供其他功能元素，例如BR。
The mechanism described in this document is only suitable for use for provisioning softwire clients via DHCP 4o6. The options described here are only applicable within the DHCP 4o6 message-exchange process. Current softwire technologies suitable for extending to incorporate DHCP 4o6 with dynamic IPv4 address leasing include [RFC7597] and [RFC7596].
本文档中描述的机制仅适用于通过DHCP 4o6配置软线客户端。此处描述的选项仅适用于DHCP 4o6消息交换过程。当前适合扩展以将DHCP 4o6与动态IPv4地址租赁结合在一起的软线技术包括[RFC7597]和[RFC7596]。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
In order to provision a softwire, both IPv6 and IPv4 configurations need to be passed to the client. To map this to the DHCP 4o6 configuration process, the IPv6 configuration is carried in DHCPv6 options [RFC8415], carried inside the DHCPv6 message DHCPV4-RESPONSE (21) sent by the server. OPTION_S46_BR (90) is used to provision the remote IPv6 address for the softwire BR (see Section 4.1). OPTION_S46_BIND_IPV6_PREFIX (137) is optionally sent by the DHCP 4o6 server to indicate to the client a preferred IPv6 prefix for binding the received IPv4 configuration and sourcing tunnel traffic. This may be necessary if there are multiple IPv6 prefixes in use in the customer network (e.g., Unique Local Addresses (ULAs)) or if the specific IPv4-over-IPv6 transition mechanism requires the use of a particular prefix for any reason.
为了提供软线，需要将IPv6和IPv4配置都传递给客户端。为了将此映射到DHCP 4o6配置过程，IPv6配置在服务器发送的DHCPv6消息DHCPV4-RESPONSE（21）中的DHCPv6选项[RFC8415]中进行。选项_S46_BR（90）用于为软线BR提供远程IPv6地址（参见第4.1节）。选项_S46_BIND_IPV6_前缀（137）可选地由DHCP 4o6服务器发送，以向客户端指示用于绑定接收到的IPv4配置和源隧道流量的首选IPV6前缀。如果客户网络中使用多个IPv6前缀（例如，唯一本地地址（ULA）），或者如果特定的IPv4-over-IPv6转换机制出于任何原因需要使用特定前缀，则可能需要这样做。
IPv4 configuration is carried in DHCPv4 messages [RFC2131] (inside the DHCP 4o6 option OPTION_DHCPV4_MSG (87)) using the mechanism described in [RFC7341].
IPv4配置使用[RFC7341]中描述的机制在DHCPv4消息[RFC2131]（DHCP 4o6选项_DHCPv4_MSG（87）内）中进行。
In order for the client to communicate the softwire source address, a new DHCPv4 option OPTION_DHCP4O6_S46_SADDR (109) is defined in this document. This is included in DHCPREQUEST messages sent by the client and is stored by the server for the lifetime of the IPv4 address lease.
为了让客户机通信软线源地址，本文档中定义了一个新的DHCPv4选项_DHCP4O6 _S46 _SADDR（109）。这包括在客户端发送的DHCPREQUEST消息中，并由服务器在IPv4地址租约的生存期内存储。
Section 4.2 of [RFC7598] defines option OPTION_S46_BR (90) for communicating remote softwire BR IPv6 address(es) to a client, but it mandates that the option can only be used when encapsulated within one of the softwire container options: OPTION_S46_CONT_MAPE (94) or OPTION_S46_CONT_LW (96). From Section 3 of [RFC7598]:
[RFC7598]第4.2节定义了用于将远程软线BR IPv6地址通信到客户端的选项\u S46\u BR（90），但它规定该选项仅在封装在一个软线容器选项中时才能使用：选项\u S46\u CONT_MAPE（94）或选项\u S46\u CONT_LW（96）。根据[RFC7598]第3节：
Softwire46 DHCPv6 clients that receive provisioning options that are not encapsulated in container options MUST silently ignore these options.
接收未封装在容器选项中的配置选项的Softwire46 DHCPv6客户端必须以静默方式忽略这些选项。
This document updates [RFC7598], removing this restriction for OPTION_S46_BR (90), allowing it to be enumerated in the client's ORO request and appear directly within subsequent messages sent by the DHCPv6 server.
本文档更新了[RFC7598]，删除了选项_S46_BR（90）的限制，允许在客户端的ORO请求中枚举该选项，并直接显示在DHCPv6服务器发送的后续消息中。
Figure 1 shows the relevant extensions to the successful DHCP 4o6 IPv4 allocation client/server message flow for the softwire source address function. The full process, including error handling, is described in Section 7.
图1显示了softwire源地址功能的成功DHCP 4o6 IPv4分配客户端/服务器消息流的相关扩展。第7节描述了包括错误处理在内的整个过程。
In each step, the DHCPv6 portion of the message and any relevant option is shown above the arrow. The DHCP 4o6 content of the message and its relevant options are below the arrow. All the DHCPv4 messages are encapsulated in DHCPV4-QUERY (20) or DHCPV4-RESPONSE (21) messages. Where relevant, the necessary options and their contents are shown.
在每个步骤中，消息的DHCPv6部分和任何相关选项都显示在箭头上方。消息的DHCP 4o6内容及其相关选项位于箭头下方。所有DHCPv4消息都封装在DHCPv4-QUERY（20）或DHCPv4-RESPONSE（21）消息中。如果相关，将显示必要的选项及其内容。
DHCP 4o6 DHCP 4o6
Client Server
| |
| DHCPv6 - DHCPV4-QUERY message containing |
| OPTION_ORO (6) listing (90, 137) |
Step 1 |----------------------------------------------------->|
| DHCPv4 - DHCPDISCOVER message |
| |
| |
| DHCPv6 - DHCPV4-RESPONSE message containing |
| OPTION_S46_BR(90), OPTION_S46_BIND_IPV6_PREFIX(137) |
| (bind-ipv6-prefix with service provider's |
| preferred prefix) |
Step 2 |<-----------------------------------------------------|
| DHCPv4 - DHCPOFFER message |
| containing an available IPv4 address |
| |
| DHCPv6 - DHCPV4-QUERY message |
Step 3 |----------------------------------------------------->|
| DHCPv4 - DHCPREQUEST message containing the |
| requested IPv4 address and OPTION_DHCP4O6_S46_SADDR |
| (softwire-ipv6-src-address with client's bound |
| IPv6 softwire source address) |
| |
| |
| DHCPv6 - DHCPV4-RESPONSE message |
Step 4 |<-----------------------------------------------------|
| DHCPv4 - DHCPACK message containing |
| the leased IPv4 address and OPTION_DHCP4O6_S46_SADDR |
| (softwire-ipv6-src-address with client's bound |
| IPv6 softwire source address) |
| |
DHCP 4o6 DHCP 4o6
Client Server
| |
| DHCPv6 - DHCPV4-QUERY message containing |
| OPTION_ORO (6) listing (90, 137) |
Step 1 |----------------------------------------------------->|
| DHCPv4 - DHCPDISCOVER message |
| |
| |
| DHCPv6 - DHCPV4-RESPONSE message containing |
| OPTION_S46_BR(90), OPTION_S46_BIND_IPV6_PREFIX(137) |
| (bind-ipv6-prefix with service provider's |
| preferred prefix) |
Step 2 |<-----------------------------------------------------|
| DHCPv4 - DHCPOFFER message |
| containing an available IPv4 address |
| |
| DHCPv6 - DHCPV4-QUERY message |
Step 3 |----------------------------------------------------->|
| DHCPv4 - DHCPREQUEST message containing the |
| requested IPv4 address and OPTION_DHCP4O6_S46_SADDR |
| (softwire-ipv6-src-address with client's bound |
| IPv6 softwire source address) |
| |
| |
| DHCPv6 - DHCPV4-RESPONSE message |
Step 4 |<-----------------------------------------------------|
| DHCPv4 - DHCPACK message containing |
| the leased IPv4 address and OPTION_DHCP4O6_S46_SADDR |
| (softwire-ipv6-src-address with client's bound |
| IPv6 softwire source address) |
| |
Figure 1: IPv6/IPv4 Binding Message Flow
图1:IPv6/IPv4绑定消息流
Step 1 The client constructs a DHCPv6 "DHCPV4-QUERY (20)" message. This message contains two options: DHCPv6 OPTION_ORO (6) and OPTION_DHCPV4_MSG (87). OPTION_ORO lists "90" (OPTION_S46_BR) and "137" (OPTION_S46_BIND_IPV6_PREFIX). OPTION_DHCPV4_MSG contains a DHCPv4 DHCPDISCOVER message.
步骤1客户机构造一条DHCPv6“DHCPV4-QUERY（20）”消息。此消息包含两个选项：DHCPv6选项ORO（6）和选项DHCPV4选项MSG（87）。OPTION_ORO列出“90”（OPTION_S46_BR）和“137”（OPTION_S46_BIND_IPV6_前缀）。选项_DHCPV4_MSG包含一条DHCPV4 DHCPDISCOVER消息。
Step 2 The server responds with a DHCPv6 "DHCPV4-RESPONSE (21)" message. This message contains an OPTION_S46_BR (90) containing the IPv6 address of the BR for the client's softwire configuration. The message may also optionally contain OPTION_S46_BIND_IPV6_PREFIX (137). OPTION_DHCPV4_MSG contains a DHCPv4 DHCPOFFER message. The DHCPv4 message contains an available IPv4 address.
步骤2服务器用DHCPv6“DHCPV4-RESPONSE（21）”消息进行响应。此消息包含选项_S46_BR（90），其中包含用于客户端软线配置的BR的IPv6地址。该消息还可以可选地包含选项_S46_BIND_IPV6_前缀（137）。选项_DHCPV4_MSG包含一条DHCPV4 DHCPOFFER消息。DHCPv4消息包含可用的IPv4地址。
Step 3 The client sends a DHCPv6 "DHCPV4-QUERY (20)" message containing a DHCPv4 DHCPREQUEST message with the requested IPv4 address and OPTION_DHCP4O6_S46_SADDR (109) with the IPv6 address that the client will use as its softwire source address.
步骤3：客户端发送DHCPv6“DHCPV4-QUERY（20）”消息，其中包含具有请求的IPv4地址的DHCPV4 DHCPREQUEST消息和具有客户端将用作其软线源地址的IPv6地址的选项_DHCP4O6_S46_SADDR（109）。
Step 4 The server sends a DHCPv6 "DHCPV4-RESPONSE (21)" message. OPTION_DHCPV4_MSG contains a DHCPv4 DHCPACK message with the allocated IPv4 address. OPTION_DHCP4O6_S46_SADDR with the client's bound softwire source address is included.
步骤4服务器发送一条DHCPv6“DHCPV4-RESPONSE（21）”消息。选项_DHCPV4_MSG包含一条带有分配的IPv4地址的DHCPV4 DHCPACK消息。选项_DHCP4O6_S46_SADDR包含客户端绑定的软线源地址。
The format of the DHCPv6 source binding prefix hint option is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_S46_BIND_IPV6_PREFIX | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|bindprefix6-len| |
+-+-+-+-+-+-+-+-+ bind-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_S46_BIND_IPV6_PREFIX | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|bindprefix6-len| |
+-+-+-+-+-+-+-+-+ bind-ipv6-prefix .
. (variable length) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Format of OPTION_S46_BIND_IPV6_PREFIX
图2:OPTION_S46_BIND_IPV6_前缀的格式
o option-code: OPTION_S46_BIND_IPV6_PREFIX (137)
o 选项代码：选项_S46_绑定_IPV6_前缀（137）
o option-length: 1 + length of bind-ipv6-prefix, specified in bytes.
o 选项长度：1+bind-ipv6-prefix的长度，以字节为单位指定。
o bindprefix6-len: 8-bit field expressing the bit mask length of the IPv6 prefix specified in bind-ipv6-prefix. Valid values are 0 to 128.
o bindprefix6 len:8位字段，表示在bind-IPv6-prefix中指定的IPv6前缀的位掩码长度。有效值为0到128。
o bind-ipv6-prefix: The IPv6 prefix indicating the preferred prefix for the client to bind the received IPv4 configuration to. The length is (bindprefix6-len + 7) / 8. The field is padded on the right with zero bits up to the next octet boundary when bind-ipv6-prefix is not evenly divisible by 8. These padding bits are ignored by the receiver (see Section 7.4).
o bind-ipv6-prefix：表示客户端将接收到的IPv4配置绑定到的首选前缀的ipv6前缀。长度为（bindprefix6 len+7）/8。当bind-ipv6-prefix不能被8整除时，该字段在右侧填充零位，直到下一个八位字节边界。接收器忽略这些填充位（参见第7.4节）。
OPTION_S46_BIND_IPV6_PREFIX is a singleton. Servers MUST NOT send more than one instance of the OPTION_S46_BIND_IPV6_PREFIX option.
选项_S46_BIND_IPV6_前缀为单例。服务器不能发送多个选项_S46_BIND_IPV6_PREFIX选项的实例。
The format of the DHCPv4 over DHCPv6 softwire source address option is as follows:
DHCPv4 over DHCPv6软线源地址选项的格式如下：
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| option-code | option-length |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ softwire-ipv6-src-address +
. (128 bits) .
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| option-code | option-length |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+ softwire-ipv6-src-address +
. (128 bits) .
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Figure 3: Format of OPTION_DHCP4O6_S46_SADDR
图3:OPTION_DHCP4O6_S46_SADD的格式
o option-code: OPTION_DHCP4O6_S46_SADDR (109)
o 选项代码：选项DHCP4O6\U S46\U SADD（109）
o option-length: 16.
o 选项长度：16。
o softwire-ipv6-src-address: 16 bytes long; the IPv6 address that is associated (either being requested for binding or currently bound) with the client's IPv4 configuration.
o softwire-ipv6-src-address：16字节长；与客户端IPv4配置关联（正在请求绑定或当前绑定）的IPv6地址。
Note: The function of OPTION_DHCP4O6_S46_SADDR may seem similar to the DHCPv4 message's "chaddr" field or the Client Identifier (61) option in that it provides a unique lower-layer address that the server can use for identifying the client. However, as both of these are required to remain constant throughout the address lease lifetime, they cannot be used with the mechanism described in this document. This is because the client may only be able to construct the IPv6 address to use as the source address after it has received the first DHCPV4-RESPONSE message from the server containing OPTION_S46_BIND_IPV6_PREFIX.
注意：选项_DHCP4O6_S46_SADDR的功能可能类似于DHCPv4消息的“chaddr”字段或客户端标识符（61）选项，因为它提供了服务器可用于标识客户端的唯一下层地址。但是，由于这两种类型都需要在整个地址租约生命周期内保持不变，因此它们不能与本文档中描述的机制一起使用。这是因为客户端可能只能在从包含选项_S46_BIND_IPv6_前缀的服务器接收到第一条DHCPV4-RESPONSE消息后构建IPv6地址以用作源地址。
A client requiring dynamic softwire configuration first enables DHCP 4o6 configuration using the method described in Section 5 of [RFC7341]. If OPTION_DHCP4_O_DHCP6_SERVER is received in the corresponding REPLY message, the client MAY continue with the configuration process described below.
需要动态软线配置的客户端首先使用[RFC7341]第5节中描述的方法启用DHCP 4o6配置。如果在相应的回复消息中接收到选项_DHCP4_O_DHCP6_SERVER，则客户端可以继续下面描述的配置过程。
Before the dynamic softwire configuration process can commence, the client MUST be configured with a suitable IPv6 prefix to be used as the local softwire endpoint. This could be obtained using DHCPv6, Router Advertisement (RA) / Prefix Information Option (PIO), or another mechanism.
在动态软线配置过程开始之前，必须使用合适的IPv6前缀配置客户端，以用作本地软线端点。这可以通过使用DHCPv6、路由器广告（RA）/前缀信息选项（PIO）或其他机制来实现。
When constructing the initial DHCP 4o6 DHCPDISCOVER message, the client includes a DHCPv6 OPTION_ORO (6) within the options field of the DHCP-QUERY message. OPTION_ORO contains the option codes for OPTION_S46_BR (90) and OPTION_S46_BIND_IPV6_PREFIX (137).
在构造初始DHCP 4o6 DHCPDISCOVER消息时，客户端在DHCP-QUERY消息的选项字段中包含DHCPv6选项_ORO（6）。OPTION_ORO包含OPTION_S46_BR（90）和OPTION_S46_BIND_IPV6_前缀（137）的选项代码。
On receipt of the DHCP 4o6 server's reply (a DHCPV4-RESPONSE containing a DHCPOFFER message), the client checks the contents of the DHCPv4-RESPONSE for the presence of a valid OPTION_S46_BR option. If this option is not present, or does not contain at least one valid IPv6 address for a BR, then the client MUST discard the message, as without the address of the BR the client cannot configure the softwire and so has no interface to request IPv4 configuration for.
在收到DHCP 4o6服务器的回复（包含DHCPOFFER消息的DHCPV4响应）时，客户机检查DHCPV4响应的内容是否存在有效选项。如果此选项不存在，或者不包含BR的至少一个有效IPv6地址，则客户端必须丢弃该消息，因为没有BR地址，客户端无法配置软线，因此没有接口来请求IPv4配置。
The DHCPV4-RESPONSE message may also include OPTION_S46_BIND_IPV6_PREFIX, which is used by the operator to indicate a preferred prefix that the client should bind IPv4 configuration to. If received, the client first checks the option according to Section 7.4. If valid, the client uses this prefix as the "IPv6 binding prefix" and follows to the process described in Section 5.1 of [RFC7596] in order to select an active IPv6 prefix to construct the softwire. If no match is found, or the client doesn't receive OPTION_S46_BIND_IPV6_PREFIX, the client MAY select any valid IPv6 prefix (of a suitable scope) to use as the tunnel source.
DHCPV4-RESPONSE消息还可以包括选项_S46_BIND_IPV6_PREFIX，操作员使用该选项指示客户端应将IPv4配置绑定到的首选前缀。如果收到，客户首先根据第7.4节检查选项。如果有效，客户端使用此前缀作为“IPv6绑定前缀”，并遵循[RFC7596]第5.1节中描述的过程，以选择活动IPv6前缀来构建软线。如果未找到匹配项，或者客户端未收到选项_S46_BIND_IPV6_前缀，则客户端可以选择任何有效的IPV6前缀（具有适当范围）用作隧道源。
Once the client has selected a suitable prefix, it MAY either use an existing IPv6 address that is already configured on an interface or create a new address specifically for use as the softwire source address (e.g., using an Interface Identifier constructed as per Section 6 of [RFC7597]). If a new address is being created, the client MUST complete configuration of the new address, performing duplicate address detection (if required) before proceeding.
一旦客户机选择了合适的前缀，它可以使用已经在接口上配置的现有IPv6地址，或者创建专门用作软线源地址的新地址（例如，使用根据[RFC7597]第6节构造的接口标识符）。如果正在创建新地址，客户端必须完成新地址的配置，在继续之前执行重复地址检测（如果需要）。
The client then constructs a DHCPV4-QUERY message containing a DHCPv4 DHCPREQUEST message. OPTION_DHCP4O6_S46_SADDR is included in the options field of the DHCPREQUEST message with the IPv6 address of its softwire source address in the softwire-ipv6-src-address field.
然后，客户端构造一个包含DHCPV4 DHCPREQUEST消息的DHCPV4-QUERY消息。选项_DHCP4O6_S46_SADDR包含在DHCPREQUEST消息的选项字段中，其软线源地址的IPv6地址包含在softwire-IPv6-src-address字段中。
When the client receives a DHCPv4 DHCPACK message from the server, it checks the IPv6 address in OPTION_DHCP4O6_S46_SADDR against its active softwire source address. If they match, the allocation process has concluded. If there is a discrepancy, then the process described in Section 7.5 is followed.
当客户端从服务器接收到DHCPv4 DHCPACK消息时，它会根据其活动软线源地址检查选项_DHCP4O6_S46_SADDR中的IPv6地址。如果匹配，则分配过程已结束。如果存在差异，则遵循第7.5节中描述的流程。
If the client receives a DHCPv4 DHCPNAK message from the server, then the configuration process has been unsuccessful. The client then restarts the process from Step 1 of Figure 1.
如果客户端从服务器接收到DHCPv4 DHCPNAK消息，则配置过程已失败。然后，客户机从图1的步骤1重新启动流程。
7.2. Renewing or Rebinding the IPv4 Address Lease and Softwire Source Address
7.2. 续订或重新绑定IPv4地址租约和软线源地址
Whenever the client attempts to extend the lease time of the IPv4 address, OPTION_DHCP4O6_S46_SADDR with the IPv6 address of its softwire source address in the softwire-ipv6-src-address field MUST be included in the DHCPREQUEST message.
每当客户端尝试延长IPv4地址的租用时间时，选项_DHCP4O6_S46_SADDR及其softwire-IPv6-src-address字段中的softwire源地址的IPv6地址必须包含在DHCPREQUEST消息中。
Across the lifetime of the leased IPv4 address, it is possible that the client's IPv6 address will change, e.g., if there is an IPv6 renumbering event.
在租用的IPv4地址的整个生命周期内，客户端的IPv6地址可能会发生更改，例如，如果发生IPv6重新编号事件。
In this situation, the client MUST inform the server of the new address. This is done by sending a DHCPREQUEST message containing OPTION_DHCP4O6_S46_SADDR with the new IPv6 source address.
在这种情况下，客户端必须将新地址通知服务器。这是通过发送包含选项_DHCP4O6_S46_SADDR和新IPv6源地址的DHCPREQUEST消息来完成的。
When the client receives a DHCPv4 DHCPACK message from the server, it checks the IPv6 address in OPTION_DHCP4O6_S46_SADDR against its active softwire source address. If they match, the allocation process has concluded. If there is a discrepancy, then the process described in Section 7.5 is followed.
当客户端从服务器接收到DHCPv4 DHCPACK消息时，它会根据其活动软线源地址检查选项_DHCP4O6_S46_SADDR中的IPv6地址。如果匹配，则分配过程已结束。如果存在差异，则遵循第7.5节中描述的流程。
If the client receives a DHCPv4 DHCPNAK message in response from the server, then the change of the bound IPv6 softwire source address has been unsuccessful. In this case, the client MUST stop using the new IPv6 source address. The client then restarts the process from Step 1 of Figure 1.
如果客户端收到来自服务器的DHCPv4 DHCPNAK消息作为响应，则绑定IPv6软线源地址的更改已失败。在这种情况下，客户端必须停止使用新的IPv6源地址。然后，客户机从图1的步骤1重新启动流程。
When the client no longer requires the IPv4 resource, it sends a DHCPv4 DHCPRELEASE message to the server. As the options field is unused in this message type, OPTION_DHCP4O6_S46_SADDR is not included.
当客户端不再需要IPv4资源时，它会向服务器发送DHCPv4 DHCPRELEASE消息。由于此消息类型中未使用选项字段，因此不包括选项DHCP4O6_S46_SADD。
On receipt of the OPTION_S46_BIND_IPV6_PREFIX option, the client makes the following validation checks:
在收到选项_S46_BIND_IPV6_PREFIX选项后，客户端进行以下验证检查：
o The received bindprefix6-len value is not larger than 128.
o 收到的BindPrefix len值不大于128。
o The number of bytes received in the bind-ipv6-prefix field is consistent with the received bindprefix6-len value (calculated as described in Section 6.1).
o bind-ipv6-prefix字段中接收到的字节数与接收到的bindprefix6 len值一致（按第6.1节所述计算）。
If either check fails, the receiver discards the invalid option and proceeds to attempt configuration as if the option had not been received.
如果任一检查失败，接收器将丢弃无效选项，并继续尝试配置，就像未收到该选项一样。
The receiver MUST only use bits from the bind-ipv6-prefix field up to the value specified in the bindprefix6-len when performing the longest prefix match. bind-ipv6-prefix bits beyond this value MUST be ignored.
在执行最长前缀匹配时，接收器必须仅使用bind-ipv6-prefix字段中最多为bindprifix6 len中指定值的位。必须忽略超出此值的bind-ipv6-prefix位。
If the client receives a DHCPACK message with an OPTION_DHCP4O6_S46_SADDR containing an IPv6 address that differs from its active softwire source address, the client SHOULD wait for a randomized time interval and then resend the DHCPREQUEST message with the correct softwire source address. Section 4.1 of [RFC2131] describes the retransmission backoff interval process.
如果客户端接收到带有选项_DHCP4O6_S46_SADDR的DHCPACK消息，该选项包含与其活动软线源地址不同的IPv6地址，则客户端应等待随机时间间隔，然后使用正确的软线源地址重新发送DHCPREQUEST消息。[RFC2131]第4.1节描述了重传退避间隔过程。
The default minimum time for the client to attempt retransmission is 60 seconds. If, after this time has expired, the client has not received a DHCPACK message with the correct bound IPv6 address, client MAY send a DHCPRELEASE message and restart the process described in Section 7. The retry interval should be configurable and aligned with any server policy defining the minimum time interval for client address updates as described in Section 8.1.
客户端尝试重新传输的默认最短时间为60秒。如果在此时间到期后，客户端未收到具有正确绑定IPv6地址的DHCPACK消息，则客户端可以发送DHCPRELEASE消息并重新启动第7节中描述的过程。重试间隔应该是可配置的，并与任何定义客户端地址更新最小时间间隔的服务器策略保持一致，如第8.1节所述。
[RFC7618] describes a mechanism for using DHCPv4 to distribute dynamic, shared IPv4 addresses to clients. The mechanism described in this document is compatible with IPv4 address sharing and can be enabled by following the process described in Section 6 of [RFC7618].
[RFC7618]描述了一种使用DHCPv4向客户端分发动态共享IPv4地址的机制。本文档中描述的机制与IPv4地址共享兼容，可以通过遵循[RFC7618]第6节中描述的过程来启用。
Beyond the normal DHCP 4o6 functionality defined in [RFC7341], the server MUST also store the IPv6 softwire source address of the client in the leasing address database, alongside the IPv4 address and client identifier.
除了[RFC7341]中定义的正常DHCP 4o6功能外，服务器还必须在租赁地址数据库中存储客户端的IPv6软线源地址以及IPv4地址和客户端标识符。
An OPTION_DHCP4O6_S46_SADDR containing the bound softwire source address MUST be sent in every DHCPACK message sent by the server.
必须在服务器发送的每个DHCPACK消息中发送包含绑定软线源地址的选项_DHCP4O6_S46_SADDR。
The binding entry between the client's IPv6 softwire source address and the leased IPv4 address is valid as long as the IPv4 lease remains valid.
只要IPv4租约保持有效，客户端的IPv6软线源地址和租用的IPv4地址之间的绑定条目就有效。
In the event that the server receives a DHCPREQUEST message for an active IPv4 lease containing an OPTION_DHCP4O6_S46_SADDR with an IPv6 address that differs from the address that is currently stored, the server updates the stored softwire source address with the new address supplied by the client and sends a DHCPACK message containing the updated softwire source address in OPTION_DHCP4O6_S46_SADDR.
如果服务器接收到活动IPv4租约的DHCPREQUEST消息，该消息包含选项_DHCP4O6_S46_SADDR，其IPv6地址与当前存储的地址不同，服务器使用客户端提供的新地址更新存储的软线源地址，并发送包含选项_DHCP4O6_S46_SADDR中更新的软线源地址的DHCPACK消息。
The server MAY implement a policy enforcing a minimum time interval between a client updating its softwire source IPv6 address. If a client attempts to update the softwire source IPv6 address before the minimum time has expired, the server can either silently drop the client's message or send back a DHCPACK message containing the existing IPv6 address binding in OPTION_DHCP4O6_S46_SADDR. If implemented, the default minimum client source address update interval is 60 seconds.
服务器可以实现强制客户端更新其软线源IPv6地址之间的最小时间间隔的策略。如果客户端试图在最短时间到期之前更新软线源IPv6地址，则服务器可以静默删除客户端的消息，或发送回包含选项_DHCP4O6_S46_SADD中现有IPv6地址绑定的DHCPACK消息。如果实现，默认的最小客户端源地址更新间隔为60秒。
In order for traffic to be forwarded correctly, each customer edge's (CE's) softwire IPv6 source address must be unique. To ensure this, on receipt of every client DHCPREQUEST message containing OPTION_DHCP4O6_S46_SADDR, the DHCP 4o6 server MUST check the received IPv6 address against all existing CE source addresses stored for
为了正确转发流量，每个客户边缘（CE）的软线IPv6源地址必须是唯一的。为确保这一点，在收到包含选项_DHCP4O6_S46_SADDR的每个客户端DHCPREQUEST消息时，DHCP 4o6服务器必须根据存储的所有现有CE源地址检查接收到的IPv6地址
active client IPv4 leases. If there is a match for any active lease other than the lease belonging to the client sending the DHCPREQUEST, then the client's IPv6 source address MUST NOT be stored or updated.
活动客户端IPv4租约。如果与任何活动租约（属于发送DHCPREQUEST的客户端的租约除外）匹配，则不得存储或更新客户端的IPv6源地址。
Depending on where the client and server are in the address leasing lifecycle, the DHCP 4o6 server then takes the following action:
根据客户机和服务器在地址租赁生命周期中的位置，DHCP 4o6服务器将执行以下操作：
o If the DHCP 4o6 does not have a current, active IPv4 address lease for the client, then the DHCP address allocation process has not been successful. The server returns a DHCPNAK message to the client.
o 如果DHCP 4o6没有客户端的当前活动IPv4地址租约，则DHCP地址分配过程未成功。服务器向客户端返回一条DHCPNAK消息。
o If the DHCP 4o6 does have a current, active IPv4 address lease, then the source address update process (see Section 8.1) has not been successful. The DHCP 4o6 server can either silently drop the client's message or return a DHCPACK message containing the existing IPv6 address binding in OPTION_DHCP4O6_S46_SADDR.
o 如果DHCP 4o6具有当前活动的IPv4地址租约，则源地址更新过程（请参阅第8.1节）未成功。DHCP 4o6服务器可以静默地删除客户端的消息，也可以返回包含选项_DHCP4O6_S46_SADDR中现有IPv6地址绑定的DHCPACK消息。
Security considerations that are applicable to [RFC7341] are also applicable here.
适用于[RFC7341]的安全注意事项也适用于此处。
A rogue client could attempt to use the mechanism described in Section 7.2.1 to redirect IPv4 traffic intended for another client to itself. This would be performed by sending a DHCPREQUEST message for another client's active IPv4 lease containing the attacker's softwire IPv6 address in OPTION_DHCP4O6_S46_SADDR.
恶意客户端可能会尝试使用第7.2.1节中描述的机制将另一个客户端的IPv4流量重定向到自身。这将通过发送另一个客户端的活动IPv4租约的DHCPREQUEST消息来执行，该消息包含攻击者在选项_DHCP4O6_S46_SADDR中的软线IPv6地址。
For such an attack to be effective, the attacker would need to know both the client identifier and the active IPv4 address lease currently in use by another client. This could be attempted in three ways:
为了使这种攻击有效，攻击者需要知道客户端标识符和另一个客户端当前使用的活动IPv4地址租约。这可以通过三种方式进行尝试：
1. One customer learning the active IPv4 address lease and client identifier of another customer via snooping the DHCP4o6 message flow between the client and server. The mechanism described in this document is intended for use in a typical ISP network topology with a dedicated Layer 2 access network per client, meaning that snooping of another client's traffic is not possible. If the access network is a shared medium, then provisioning softwire clients using dynamic DHCP4o6 as described here is NOT RECOMMENDED.
1. 一个客户通过窥探客户机和服务器之间的DHCP4o6消息流了解另一个客户的活动IPv4地址租约和客户机标识符。本文档中描述的机制旨在用于典型的ISP网络拓扑中，每个客户端具有专用的第2层访问网络，这意味着不可能窥探另一个客户端的流量。如果接入网络是共享介质，则不建议使用此处所述的动态DHCP4o6配置软线客户端。
2. Learning the active IPv4 address lease and client identifier via snooping the DHCP4o6 message flow between the client and server in the aggregation or core ISP network. In this case, the attacker requires a level of access to the ISP's infrastructure that means they can already intercept or interfere with traffic flows to the client.
2. 通过监听聚合或核心ISP网络中客户端和服务器之间的DHCP4o6消息流，学习活动IPv4地址租约和客户端标识符。在这种情况下，攻击者需要对ISP基础设施的访问级别，这意味着他们已经可以拦截或干扰到客户端的流量。
3. An attacker attempting to brute-force guess the IPv4 lease address and client identifier tuple. The risk of this can be reduced by using a client identifier format that is not easily guessable, e.g., by using a random-based client identifier (see Section 3.5 of [RFC7844]).
3. 攻击者试图强行猜测IPv4租约地址和客户端标识符元组。通过使用不易猜测的客户标识符格式，例如使用基于随机的客户标识符（见[RFC7844]第3.5节），可以降低这种风险。
An attacker could attempt to redirect existing flows to a client unable to process the traffic. This type of attack can be prevented by implementing network ingress filtering [BCP38] in conjunction with the BR source address validation processes described in [RFC7596] Section 5.2 and [RFC7597] Section 8.1.
攻击者可以尝试将现有流重定向到无法处理流量的客户端。通过结合[RFC7596]第5.2节和[RFC7597]第8.1节中描述的BR源地址验证过程实施网络入口过滤[BCP38]，可以防止此类攻击。
A client may attempt to overload the server by sending multiple source address update messages (see Section 7.2.1) in a short time frame. This risk can be reduced by implementing a server policy enforcing a minimum time interval between client address changes, as described in Section 8.1.
客户端可能会试图在短时间内发送多个源地址更新消息（见第7.2.1节），从而使服务器过载。如第8.1节所述，通过实施服务器策略，强制客户机地址更改之间的最小时间间隔，可以降低此风险。
[RFC7844] describes anonymity profiles for DHCP clients. These considerations and recommendations are also applicable to clients implementing the mechanism described in this document. As DHCP 4o6 only uses DHCPv6 as a stateless transport for DHCPv4 messages, the "Anonymity Profile for DHCPv4" described in Section 3 is most relevant here.
[RFC7844]介绍DHCP客户端的匿名配置文件。这些注意事项和建议也适用于实施本文件所述机制的客户。由于DHCP 4o6仅将DHCPv6用作DHCPv4消息的无状态传输，因此第3节中描述的“DHCPv4匿名配置文件”在这里最为相关。
In addition to the considerations given in [RFC7844], the mechanism that the client uses for constructing the interface identifier for its IPv6 softwire source address (see Section 7.1) could result in the device being trackable across different networks and sessions, e.g., if the client's softwire Interface Identifier (IID) is immutable.
除了[RFC7844]中给出的注意事项外，客户端用于为其IPv6软线源地址构造接口标识符的机制（参见第7.1节）可能导致设备可在不同的网络和会话中跟踪，例如，如果客户端的软线接口标识符（IID）是不可变的。
This can be mitigated by constructing the softwire source IPv6 address as per Section 6 of [RFC7597]. Here, the address's IID contains only the allocated IPv4 address (and port set identifier if [RFC7618] is being used). This means no additional client information is exposed to the DHCP 4o6 server; it also means that the IID will change as the leased IPv4 address changes (e.g., between sessions when Section 3.5 of [RFC7844] is implemented).
这可以通过按照[RFC7597]第6节构造软线源IPv6地址来缓解。这里，地址的IID仅包含分配的IPv4地址（如果使用[RFC7618]，则包含端口集标识符）。这意味着不会向DHCP 4o6服务器公开其他客户端信息；这还意味着IID将随着租用IPv4地址的变化而变化（例如，在[RFC7844]第3.5节实施时，会话之间）。
IANA has assigned the OPTION_S46_BIND_IPV6_PREFIX (137) option code from the DHCPv6 "Option Codes" registry maintained at <http://www.iana.org/assignments/dhcpv6-parameters> as follows:
IANA已从维护于的DHCPv6“选项代码”注册表中分配选项\u S46\u绑定\u IPV6\u前缀（137）选项代码<http://www.iana.org/assignments/dhcpv6-parameters>详情如下:
Value: 137 Description: OPTION_S46_BIND_IPV6_PREFIX Client ORO: Yes Singleton Option: Yes Reference: RFC 8539
值：137说明：选项\u S46\u绑定\u IPV6\u前缀客户端ORO:Yes单例选项：Yes参考：RFC 8539
IANA has assigned the OPTION_DHCP4O6_S46_SADDR (109) option code from the "BOOTP Vendor Extensions and DHCP Options" registry maintained at <http://www.iana.org/assignments/bootp-dhcp-parameters> as follows:
IANA已从维护于的“BOOTP供应商扩展和DHCP选项”注册表中分配选项_DHCP4O6_S46_SADDR（109）选项代码<http://www.iana.org/assignments/bootp-dhcp-parameters>详情如下:
Tag: 109 Name: OPTION_DHCP4O6_S46_SADDR Data Length: 16 Meaning: DHCPv4 over DHCPv6 Softwire Source Address Option Reference: RFC 8539
标签：109名称：OPTION_DHCP4O6_S46_SADD数据长度：16含义：DHCPv4超过DHCPv6软线源地址选项参考：RFC 8539
IANA has updated the entry for DHCPv6 OPTION_S46_BR (90) in the "Option Codes" registry maintained at <https://www.iana.org/assignments/dhcpv6-parameters> as follows:
IANA已在“选项代码”注册表中更新DHCPv6选项_S46_BR（90）的条目，该注册表保存在<https://www.iana.org/assignments/dhcpv6-parameters>详情如下:
Old Entry:
旧条目：
Value: 90 Description: OPTION_S46_BR Client ORO: No Singleton Option: No Reference: [RFC7598]
值：90说明：选项\u S46\u BR客户端ORO:无单例选项：无参考：[RFC7598]
New Entry:
新条目：
Value: 90 Description: OPTION_S46_BR Client ORO: Yes Singleton Option: No Reference: [RFC7598], [RFC8539]
值：90说明：选项\u S46\u BR客户端ORO:是单例选项：无参考：[RFC7598]，[RFC8539]
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, <https://www.rfc-editor.org/info/rfc2131>.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC 2131，DOI 10.17487/RFC2131，1997年3月<https://www.rfc-editor.org/info/rfc2131>.
[RFC7341] Sun, Q., Cui, Y., Siodelski, M., Krishnan, S., and I. Farrer, "DHCPv4-over-DHCPv6 (DHCP 4o6) Transport", RFC 7341, DOI 10.17487/RFC7341, August 2014, <https://www.rfc-editor.org/info/rfc7341>.
[RFC7341]Sun，Q.，Cui，Y.，Siodelski，M.，Krishnan，S.，和I.Farrer，“DHCPv4-over-DHCPv6（DHCP 4o6）传输”，RFC 7341，DOI 10.17487/RFC73412014年8月<https://www.rfc-editor.org/info/rfc7341>.
[RFC7598] 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", RFC 7598, DOI 10.17487/RFC7598, July 2015, <https://www.rfc-editor.org/info/rfc7598>.
[RFC7598]Mrugalski，T.，Troan，O.，Farrer，I.，Perreault，S.，Dec，W.，Bao，C.，Yeh，L.，和X.Deng，“用于配置软线地址和端口映射客户端的DHCPv6选项”，RFC 7598，DOI 10.17487/RFC7598，2015年7月<https://www.rfc-editor.org/info/rfc7598>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 8415, DOI 10.17487/RFC8415, November 2018, <https://www.rfc-editor.org/info/rfc8415>.
[RFC8415]Mrugalski，T.，Siodelski，M.，Volz，B.，Yourtchenko，A.，Richardson，M.，Jiang，S.，Lemon，T.，和T.Winters，“IPv6动态主机配置协议（DHCPv6）”，RFC 8415，DOI 10.17487/RFC8415，2018年11月<https://www.rfc-editor.org/info/rfc8415>.
[BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000, <https://www.rfc-editor.org/info/bcp38>.
[BCP38]Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，2000年5月<https://www.rfc-editor.org/info/bcp38>.
[RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. Farrer, "Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, July 2015, <https://www.rfc-editor.org/info/rfc7596>.
[RFC7596]Cui，Y.，Sun，Q.，Boucadair，M.，Tsou，T.，Lee，Y.，和I.Farrer，“轻量级4over6：双栈精简架构的扩展”，RFC 7596，DOI 10.17487/RFC75962015年7月<https://www.rfc-editor.org/info/rfc7596>.
[RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., Murakami, T., and T. Taylor, Ed., "Mapping of Address and Port with Encapsulation (MAP-E)", RFC 7597, DOI 10.17487/RFC7597, July 2015, <https://www.rfc-editor.org/info/rfc7597>.
[RFC7597]Troan，O.，Ed.，Dec，W.，Li，X.，Bao，C.，Matsushima，S.，Murakami，T.，和T.Taylor，Ed.，“地址和端口的封装映射（MAP-E）”，RFC 7597，DOI 10.17487/RFC7597，2015年7月<https://www.rfc-editor.org/info/rfc7597>.
[RFC7618] Cui, Y., Sun, Q., Farrer, I., Lee, Y., Sun, Q., and M. Boucadair, "Dynamic Allocation of Shared IPv4 Addresses", RFC 7618, DOI 10.17487/RFC7618, August 2015, <https://www.rfc-editor.org/info/rfc7618>.
[RFC7618]Cui，Y.，Sun，Q.，Farrer，I.，Lee，Y.，Sun，Q.，和M.Boucadair，“共享IPv4地址的动态分配”，RFC 7618，DOI 10.17487/RFC7618，2015年8月<https://www.rfc-editor.org/info/rfc7618>.
[RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity Profiles for DHCP Clients", RFC 7844, DOI 10.17487/RFC7844, May 2016, <https://www.rfc-editor.org/info/rfc7844>.
[RFC7844]Huitema，C.，Mrugalski，T.，和S.Krishnan，“DHCP客户端的匿名配置文件”，RFC 7844，DOI 10.17487/RFC7844，2016年5月<https://www.rfc-editor.org/info/rfc7844>.
Acknowledgements
致谢
The authors would like to thank Ted Lemon, Lishan Li, Tatuya Jinmei, Jonas Gorski, and Razvan Becheriu for their contributions and comments.
作者要感谢Ted Lemon、Lishan Li、Tatuya Jinmei、Jonas Gorski和Razvan Becheriu的贡献和评论。
Authors' Addresses
作者地址
Ian Farrer Deutsche Telekom AG Landgrabenweg 151 Bonn, NRW 53227 Germany
伊恩·法雷尔德国电信股份有限公司，德国西北部波恩151号，邮编53227
Email: ian.farrer@telekom.de
Email: ian.farrer@telekom.de
Qi Sun Tsinghua University Beijing 100084 China
齐孙清华大学北京100084
Phone: +86-10-6278-5822
Email: sunqi.ietf@gmail.com
Phone: +86-10-6278-5822
Email: sunqi.ietf@gmail.com
Yong Cui Tsinghua University Beijing 100084 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
Linhui Sun Tsinghua University Beijing 100084 China
清华大学孙林辉中国北京100084
Phone: +86-10-6278-5822
Email: lh.sunlinh@gmail.com
Phone: +86-10-6278-5822
Email: lh.sunlinh@gmail.com