Internet Engineering Task Force (IETF) M. Boucadair
Request for Comments: 8026 Orange
Category: Standards Track I. Farrer
ISSN: 2070-1721 Deutsche Telekom AG
November 2016
Internet Engineering Task Force (IETF) M. Boucadair
Request for Comments: 8026 Orange
Category: Standards Track I. Farrer
ISSN: 2070-1721 Deutsche Telekom AG
November 2016
Unified IPv4-in-IPv6 Softwire Customer Premises Equipment (CPE): A DHCPv6-Based Prioritization Mechanism
统一IPv4-in-IPv6软线客户场所设备（CPE）：一种基于DHCPv6的优先级机制
Abstract
摘要
In IPv6-only provider networks, transporting IPv4 packets encapsulated in IPv6 is a common solution to the problem of IPv4 service continuity. A number of differing functional approaches have been developed for this, each having their own specific characteristics. As these approaches share a similar functional architecture and use the same data plane mechanisms, this memo specifies a DHCPv6 option, whereby a single instance of Customer Premises Equipment (CPE) can interwork with all of the standardized and proposed approaches to providing encapsulated IPv4-in-IPv6 services by providing a prioritization mechanism.
在仅限IPv6的提供商网络中，传输封装在IPv6中的IPv4数据包是IPv4服务连续性问题的常见解决方案。为此开发了许多不同的功能方法，每种方法都有各自的特点。由于这些方法共享类似的功能体系结构并使用相同的数据平面机制，因此本备忘录指定了DHCPv6选项，其中包含一个客户场所设备（CPE）实例通过提供优先级机制，可以与所有标准化和建议的方法相互协作，以提供封装的IPv4-in-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 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 http://www.rfc-editor.org/info/rfc8026.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8026.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.1. Requirements Language . . . . . . . . . . . . . . . . 4
1.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. DHCPv6 S46 Priority Option . . . . . . . . . . . . . . . 5
1.4. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 6
1.5. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . 7
2. Operator Deployment Considerations for Deploying Multiple
Softwire Mechanisms . . . . . . . . . . . . . . . . . . . . . 7
2.1. Client Address Planning . . . . . . . . . . . . . . . . . 7
2.2. Backwards Compatability with Existing Softwire Clients . 7
3. Security Considerations . . . . . . . . . . . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
4.1. S46 Mechanisms and Their Identifying Option Codes . . . . 8
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Normative References . . . . . . . . . . . . . . . . . . 9
5.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.1. Requirements Language . . . . . . . . . . . . . . . . 4
1.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. DHCPv6 S46 Priority Option . . . . . . . . . . . . . . . 5
1.4. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 6
1.5. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . 7
2. Operator Deployment Considerations for Deploying Multiple
Softwire Mechanisms . . . . . . . . . . . . . . . . . . . . . 7
2.1. Client Address Planning . . . . . . . . . . . . . . . . . 7
2.2. Backwards Compatability with Existing Softwire Clients . 7
3. Security Considerations . . . . . . . . . . . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
4.1. S46 Mechanisms and Their Identifying Option Codes . . . . 8
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Normative References . . . . . . . . . . . . . . . . . . 9
5.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
IPv4 service continuity is one of the major technical challenges that must be considered during IPv6 migration. Over the past few years, a number of different approaches have been developed to assist with this problem (e.g., as described in [RFC6333], [RFC7596], and [RFC7597]). These approaches, referred to as "S46 mechanisms" in this document, exist in order to meet the particular deployment, scaling, addressing, and other requirements of different service providers' networks.
IPv4服务连续性是IPv6迁移期间必须考虑的主要技术挑战之一。在过去几年中，已经开发了许多不同的方法来帮助解决这个问题（例如，如[RFC6333]、[RFC7596]和[RFC7597]中所述）。这些方法在本文档中称为“S46机制”，旨在满足不同服务提供商网络的特定部署、扩展、寻址和其他要求。
A common feature shared among all of the differing modes is the integration of softwire tunnel endpoint functionality into the Customer Premises Equipment (CPE) router. Due to this inherent data plane similarity, a single CPE may be capable of supporting several different approaches. Users may also wish to configure a specific mode of operation.
所有不同模式之间共享的一个共同特征是将软线隧道端点功能集成到客户场所设备（CPE）路由器中。由于这种固有的数据平面相似性，单个CPE可能能够支持几种不同的方法。用户还可能希望配置特定的操作模式。
A service provider's network may also have more than one S46 mechanism enabled in order to support a diverse CPE population with differing client functionality, such as during a migration between mechanisms or where services require specific supporting softwire architectures.
服务提供商的网络还可以启用多个S46机制，以便支持具有不同客户端功能的不同CPE群体，例如在机制之间的迁移期间或者在服务需要特定支持软线架构的情况下。
For softwire-based services to be successfully established, it is essential that the customer's end node and the service provider's end node and provisioning systems are able to indicate their capabilities and preferred mode of operation.
为了成功建立基于软线的服务，客户的终端节点和服务提供商的终端节点以及供应系统必须能够指示其能力和首选操作模式。
A number of DHCPv6 options for the provisioning of softwires have been standardized:
许多用于供应软电线的DHCPv6选项已经标准化：
RFC 6334 Defines DHCPv6 option 64 for configuring Basic Bridging BroadBand (B4) [RFC6333] elements with the IPv6 address of the Address Family Transition Router (AFTR) [RFC6333].
RFC 6334定义了DHCPv6选项64，用于使用地址族转换路由器（AFTR）[RFC6333]的IPv6地址配置基本桥接宽带（B4）[RFC6333]元素。
RFC 7341 Defines DHCPv6 option 88 for configuring the address of a DHCPv4-over-DHCPv6 server, which can then be used by a softwire client for obtaining further configuration.
RFC 7341定义了DHCPv6选项88，用于配置DHCPv4-over-DHCPv6服务器的地址，然后软线客户端可以使用该地址来获得进一步的配置。
RFC 7598 Defines DHCPv6 options 94, 95, and 96 for provisioning Mapping of Address and Port with Encapsulation (MAP-E) [RFC7597], Mapping of Address and Port using Translation (MAP-T) [RFC7599], and Lightweight 4over6 [RFC7596] respectively.
RFC 7598定义了DHCPv6选项94、95和96，分别用于提供带有封装（MAP-E）[RFC7597]的地址和端口映射，使用转换（MAP-T）[RFC7599]的地址和端口映射，以及轻量级4over6[RFC7596]。
This document describes a DHCPv6-based prioritization method, whereby a CPE that supports several S46 mechanisms and receives configuration for more than one can prioritize which mechanism to use. The method requires no server-side logic to be implemented and only uses a simple S46 mechanism prioritization to be implemented in the CPE.
本文档描述了一种基于DHCPv6的优先级划分方法，通过该方法，支持多个S46机制并接收多个S46机制配置的CPE可以对要使用的机制进行优先级划分。该方法不需要实现服务器端逻辑，只使用一个简单的S46机制来在CPE中实现优先级。
The prioritization method as described here does not provide redundancy between S46 mechanisms for the client. That is, if the highest priority S46 mechanism that has been provisioned to the client is not available for any reason, the means for identifying this and falling back to the S46 mechanism with the next highest priority is not in the scope of this document.
这里描述的优先级划分方法不为客户端提供S46机制之间的冗余。也就是说，如果已经提供给客户端的最高优先级S46机制由于任何原因不可用，则用于识别该机制并返回到具有下一最高优先级的S46机制的装置不在本文档的范围内。
This document makes use of the following terms:
本文件使用了以下术语：
o Address Family Transition Router (AFTR): The IPv4-in-IPv6 tunnel termination point and the Network Address Translator IPv4/IPv4 (NAT44) function deployed in the operator's network [RFC6333].
o 地址族转换路由器（AFTR）：部署在运营商网络中的IPv4-in-IPv6隧道终止点和网络地址转换器IPv4/IPv4（NAT44）功能[RFC6333]。
o Border Relay (BR): A MAP-enabled router managed by the service provider at the edge of a MAP domain. A BR has at least an IPv6-enabled interface and an IPv4 interface connected to the native IPv4 network [RFC7597].
o 边界中继（BR）：由服务提供商在地图域边缘管理的支持地图的路由器。BR至少有一个启用IPv6的接口和一个连接到本机IPv4网络的IPv4接口[RFC7597]。
o Customer Premises Equipment (CPE): Denotes the equipment at the customer edge that terminates the customer end of an IPv6 transitional tunnel. In some documents (e.g., [RFC7597]), this functional entity is called the Customer Edge (CE).
o 客户场所设备（CPE）：表示在客户边缘终止IPv6过渡隧道的客户端的设备。在某些文档（例如[RFC7597]）中，此功能实体称为客户边缘（CE）。
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]中所述进行解释。
The following rationale has been adopted for this document:
本文件采用了以下基本原理：
(1) Simplified solution migration paths: Define unified CPE behavior, allowing for smooth migration between the different S46 mechanisms.
(1) 简化的解决方案迁移路径：定义统一的CPE行为，允许在不同的S46机制之间平滑迁移。
(2) Deterministic CPE coexistence behavior: Specify the behavior when several S46 mechanisms coexist in the CPE.
(2) 确定性CPE共存行为：指定多个S46机制在CPE中共存时的行为。
(3) Deterministic service provider coexistence behavior: Specify the behavior when several modes coexist in the service providers network.
(3) 确定性服务提供商共存行为：指定服务提供商网络中多种模式共存时的行为。
(4) Reusability: Maximize the reuse of existing functional blocks including tunnel endpoints, the port-restricted Network Address Port Translator IPv4/IPv4 (NAPT44), forwarding behavior, etc.
(4) 可重用性：最大限度地重用现有功能块，包括隧道端点、端口受限网络地址端口转换器IPv4/IPv4（NAPT44）、转发行为等。
(5) Solution agnostic: Adopt neutral terminology and avoid (as far as possible) overloading the document with solution-specific terms.
(5) 解决方案不可知：采用中性术语，并避免（尽可能）使用解决方案特定术语重载文档。
(6) Flexibility: Allow operators to compile CPE software only for the mode(s) necessary for their chosen deployment context(s).
(6) 灵活性：允许操作员仅为其所选部署上下文所需的模式编译CPE软件。
(7) Simplicity: Provide a model that allows operators to only implement the specific mode(s) that they require without the additional complexity of unneeded modes.
(7) 简单性：提供一个模型，允许操作员只实施他们需要的特定模式，而不需要额外的不必要模式的复杂性。
The S46 Priority Option is used to convey a priority order of IPv4 service continuity mechanisms. Figure 1 shows the format of the S46 Priority Option.
S46优先级选项用于传递IPv4服务连续性机制的优先级顺序。图1显示了S46优先级选项的格式。
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_PRIORITY | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| s46-option-code | s46-option-code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | s46-option-code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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_PRIORITY | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| s46-option-code | s46-option-code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | s46-option-code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: S46 Priority Option
图1:S46优先级选项
o option-code: OPTION_S46_PRIORITY (111)
o 选项代码：选项46优先级（111）
o option-length: >=2 and a multiple of 2, in octets.
o 选项长度：>=2和2的倍数，以八位字节为单位。
o s46-option-code: 16-bit IANA-registered option code of the DHCPv6 option that is used to identify the softwire mechanism. S46 mechanisms are prioritized in the appearance order in the S46 Priority Option.
o s46选项代码：用于识别软线机制的DHCPv6选项的16位IANA注册选项代码。S46机制在S46优先级选项中按照外观顺序进行优先级排序。
Codes in OPTION_S46_PRIORITY are processed in order; if a client receives more than one s46-option-code with a particular value, it should consider this case to be invalid. DHCP servers MAY validate the list of s46-option-code values to detect invalid values and duplicates. The option MUST contain at least one s46-option-code.
按顺序处理选项_S46_优先级中的代码；如果客户端接收到多于一个具有特定值的S46选项代码，则应该认为此情况无效。DHCP服务器可验证s46选项代码值列表，以检测无效值和重复值。该选项必须至少包含一个s46选项代码。
Clients MAY request the OPTION_S46_PRIORITY option, as defined in [RFC3315], Sections 17.1.1, 18.1.1, 18.1.3, 18.1.4, 18.1.5, and 22.7. As a convenience to the reader, we mention here that the client includes requested option codes in the Option Request Option.
客户可要求选择[RFC3315]第17.1.1、18.1.1、18.1.3、18.1.4、18.1.5和22.7节中定义的优先权选项。为了方便读者，我们在这里提到，客户机在选项请求选项中包含请求的选项代码。
Upon receipt of a DHCPv6 Advertise message from the server containing OPTION_S46_PRIORITY, the client performs the following steps:
在从服务器接收到包含选项_S46_优先级的DHCPv6播发消息后，客户端执行以下步骤：
1. Check the contents of the DHCPv6 message for options containing valid S46 mechanism configuration. A candidate list of possible S46 mechanisms is created from these option codes.
1. 检查DHCPv6消息的内容，查看包含有效S46机构配置的选项。根据这些选项代码创建可能的S46机制的候选列表。
2. Check the contents of OPTION_S46_PRIORITY for the DHCPv6 option codes contained in the included s46-option-code fields. From this, an S46 mechanism priority list is created, ordered from highest to lowest following the appearance order.
2. 检查包含在S46选项代码字段中的DHCPv6选项代码的选项_S46_优先级的内容。由此，创建S46机构优先级列表，按照外观顺序从最高到最低排序。
3. Sequentially check the priority list against the candidate list until a match is found.
3. 按顺序对照候选列表检查优先级列表，直到找到匹配项。
4. When a match is found, the client MUST configure the resulting S46 mechanism.
4. 当找到匹配项时，客户端必须配置生成的S46机制。
In the event that no match is found between the priority list and the candidate list, the client MAY proceed with configuring one or more of the provisioned S46 softwire mechanism(s). In this case, which mechanism(s) are chosen by the client is implementation specific and not defined here.
在优先级列表和候选列表之间未找到匹配的情况下，客户端可以继续配置所配置的S46软线机制中的一个或多个。在这种情况下，客户机选择的机制是特定于实现的，这里没有定义。
If an invalid OPTION_S46_PRIORITY option is received, the client MAY proceed with configuring the provisioned S46 mechanisms as if OPTION_S46_PRIORITY had not been received.
如果接收到无效的选项_S46_优先级选项，则客户端可以继续配置配置的S46机制，就好像没有接收到选项_S46_优先级一样。
If an unknown option code is received in the OPTION_S46_PRIORITY option, the client MUST skip it and continue processing other listed option codes if they exist. The initial option codes that are allowed to be included in an OPTION_S46_PRIORITY option are listed in Section 4.1.
如果在option_S46_PRIORITY（选项优先级）选项中收到未知选项代码，则客户端必须跳过该代码，并继续处理列出的其他选项代码（如果存在）。第4.1节列出了允许包含在选项46优先选项中的初始选项代码。
Sections 17.2.2 and 18.2 of [RFC3315] govern server operation in regard to option assignment. As a convenience to the reader, we mention here that the server will send a particular option code only if configured with specific values for that option code and if the client requested it.
[RFC3315]第17.2.2节和第18.2节规定了与选项分配有关的服务器操作。为了方便读者，我们在这里提到，只有在为该选项代码配置了特定值并且客户端请求时，服务器才会发送特定的选项代码。
Option OPTION_S46_PRIORITY is a singleton. Servers MUST NOT send more than one instance of the OPTION_S46_PRIORITY option.
Option_S46_优先级为单例。服务器不能发送多个选项_S46_优先级选项的实例。
2. Operator Deployment Considerations for Deploying Multiple Softwire Mechanisms
2. 部署多个软线机制的操作员部署注意事项
The following subsections describe some considerations for operators who are planning on implementing multiple softwire mechanisms in their network (e.g., during a migration between mechanisms).
以下小节描述了计划在其网络中实施多个软线机制的运营商的一些注意事项（例如，在机制之间的迁移期间）。
As an operator's available IPv4 resources are likely to be limited, it may be desirable to use a common range of IPv4 addresses across all of the active softwire mechanisms. However, this is likely to result in difficulties in routing ingress IPv4 traffic to the correct Border Relay (BR) / AFTR instance, which is actively serving a given CE. For example, a client that is configured to use MAP-E may send its traffic to the MAP-E BR; however, on the return path, the ingress IP traffic gets routed to a MAP-T BR. The resulting translated packet that gets forwarded to the MAP-E client will be dropped.
由于运营商的可用IPv4资源可能会受到限制，因此可能需要在所有活动软线机制中使用一个通用的IPv4地址范围。然而，这可能会导致难以将入口IPv4流量路由到正确的边界中继（BR）/AFTR实例，该实例正在积极地为给定CE服务。例如，配置为使用MAP-E的客户端可以将其流量发送到MAP-E BR；然而，在返回路径上，入口IP流量被路由到MAP-T BR。转发到MAP-E客户机的转换后的数据包将被丢弃。
Therefore, operators are advised to use separate IPv4 pools for each of the different mechanisms to simplify planning and IPv4 routing.
因此，建议运营商为每种不同的机制使用单独的IPv4池，以简化规划和IPv4路由。
For IPv6 planning, there is less of a constraint as the BR/AFTR elements for the different mechanisms can contain configuration for overlapping the client's IPv6 addresses, provided that one mechanism is actively serving a given client at a time. However, the IPv6 address that is used as the tunnel concentrator's endpoint (BR/AFTR address) needs to be different for each mechanism to ensure correct operation.
对于IPv6规划，约束较少，因为不同机制的BR/AFTR元素可以包含用于重叠客户端IPv6地址的配置，前提是一个机制一次主动为给定客户端提供服务。但是，对于每种机制，用作隧道集中器端点的IPv6地址（BR/AFTR地址）需要不同，以确保正确操作。
Deployed clients that can support multiple softwire mechanisms, but do not implement the prioritization mechanism described here may require additional planning. In this scenario, the CPE would request configuration for all of the supported softwire mechanisms in its DHCPv6 Option Request Option (ORO), but would not request
可以支持多个软线机制但未实现此处描述的优先级机制的已部署客户端可能需要额外的规划。在此场景中，CPE将在其DHCPv6选项请求选项（ORO）中请求配置所有受支持的软线机制，但不会请求
OPTION_S46_PRIORITY. By default, the DHCPv6 server will respond with configuration for all of the requested mechanisms, which could result in unpredictable and unwanted client configuration.
选项_S46 _优先级。默认情况下，DHCPv6服务器将响应所有请求机制的配置，这可能导致不可预测和不需要的客户端配置。
In this scenario, it may be necessary for the operator to implement logic within the DHCPv6 server to identify such clients and only provision them with configuration for a single softwire mechanism. It should be noted that this can lead to complexity and reduced scalability in the DHCPv6 server implementation due to the additional DHCPv6 message processing overhead.
在这种情况下，操作员可能需要在DHCPv6服务器内实现逻辑，以识别此类客户机，并仅为其提供单个软线机制的配置。应该注意，由于额外的DHCPv6消息处理开销，这可能导致DHCPv6服务器实现的复杂性和可伸缩性降低。
Security considerations discussed in [RFC6334] and [RFC7598] apply for this document.
[RFC6334]和[RFC7598]中讨论的安全注意事项适用于本文件。
Misbehaving intermediate nodes may alter the content of the S46 Priority Option. This may lead to setting a different IPv4 service continuity mechanism than the one initially preferred by the network side. Also, a misbehaving node may alter the content of the S46 Priority Option and other DHCPv6 options (e.g., DHCPv6 Option 64 or 90) so that the traffic is intercepted by an illegitimate node. Those attacks are not unique to the S46 Priority Option but are applicable to any DHCPv6 option that can be altered by a misbehaving intermediate node.
行为不当的中间节点可改变S46优先级选项的内容。这可能导致设置不同于网络端最初首选的IPv4服务连续性机制。此外，行为不端的节点可以改变S46优先级选项和其他DHCPv6选项（例如，DHCPv6选项64或90）的内容，以便由非法节点拦截通信量。这些攻击并非S46优先级选项所独有，但适用于任何可由行为不当的中间节点更改的DHCPv6选项。
IANA has allocated the following DHCPv6 option code:
IANA已分配以下DHCPv6选项代码：
111 OPTION_S46_PRIORITY
111选项46优先权
All values should be added to the DHCPv6 option code space defined in Section 24.3 of [RFC3315].
所有值应添加到[RFC3315]第24.3节中定义的DHCPv6选项代码空间中。
IANA has created a new registry titled "Option Codes permitted in the S46 Priority Option". This registry enumerates the set of DHCPv6 option codes that can be included in the OPTION_S46_PRIORITY option. Options may be added to this list using the IETF Review process described in Section 4.1 of [RFC5226].
IANA创建了一个名为“S46优先级选项中允许的选项代码”的新注册表。此注册表枚举可包含在选项_S46_优先级选项中的DHCPv6选项代码集。可使用[RFC5226]第4.1节所述的IETF审查过程将选项添加到此列表中。
The following table shows the option codes that are currently defined and the S46 mechanisms that they represent. The contents of this table shows the format and the initial values for the new registry. Option codes that have not been requested to be added according to the stated procedure should not be mentioned at all in the table, and
下表显示了当前定义的选项代码及其代表的S46机制。此表的内容显示了新注册表的格式和初始值。表中不应提及未根据规定程序要求添加的选项代码，以及
they should not be listed as "reserved" or "unassigned". The valid range of values for the registry is the range of DHCPv6 option codes (1-65535).
它们不应列为“保留”或“未分配”。注册表的有效值范围为DHCPv6选项代码范围（1-65535）。
+-------------+--------------------+-----------+
| Option Code | S46 Mechanism | Reference |
+-------------+--------------------+-----------+
| 64 | DS-Lite | [RFC6334] |
| 88 | DHCPv4 over DHCPv6 | [RFC7341] |
| 94 | MAP-E | [RFC7598] |
| 95 | MAP-T | [RFC7598] |
| 96 | Lightweight 4over6 | [RFC7598] |
+-------------+--------------------+-----------+
+-------------+--------------------+-----------+
| Option Code | S46 Mechanism | Reference |
+-------------+--------------------+-----------+
| 64 | DS-Lite | [RFC6334] |
| 88 | DHCPv4 over DHCPv6 | [RFC7341] |
| 94 | MAP-E | [RFC7598] |
| 95 | MAP-T | [RFC7598] |
| 96 | Lightweight 4over6 | [RFC7598] |
+-------------+--------------------+-----------+
Table 1: DHCPv6 Option to S46 Mechanism Mappings
表1:DHCPv6选项到S46机制映射
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3315]Droms，R.，Ed.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC 3315，DOI 10.17487/RFC3315，2003年7月<http://www.rfc-editor.org/info/rfc3315>.
[RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", RFC 6334, DOI 10.17487/RFC6334, August 2011, <http://www.rfc-editor.org/info/rfc6334>.
[RFC6334]Hankins，D.和T.Mrugalski，“双栈Lite的IPv6动态主机配置协议（DHCPv6）选项”，RFC 6334，DOI 10.17487/RFC6334，2011年8月<http://www.rfc-editor.org/info/rfc6334>.
[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, <http://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月<http://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, <http://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月<http://www.rfc-editor.org/info/rfc7598>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, <http://www.rfc-editor.org/info/rfc6333>.
[RFC6333]Durand，A.，Droms，R.，Woodyatt，J.，和Y.Lee，“IPv4耗尽后的双栈Lite宽带部署”，RFC 6333，DOI 10.17487/RFC6333，2011年8月<http://www.rfc-editor.org/info/rfc6333>.
[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, <http://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月<http://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, <http://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月<http://www.rfc-editor.org/info/rfc7597>.
[RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., and T. Murakami, "Mapping of Address and Port using Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 2015, <http://www.rfc-editor.org/info/rfc7599>.
[RFC7599]Li，X.，Bao，C.，Dec，W.，Ed.，Troan，O.，Matsushima，S.，和T.Murakami，“地址和端口映射使用翻译（MAP-T）”，RFC 7599，DOI 10.17487/RFC7599，2015年7月<http://www.rfc-editor.org/info/rfc7599>.
Acknowledgements
致谢
Many thanks to O. Troan, S. Barth, A. Yourtchenko, B. Volz, T. Mrugalski, J. Scudder, P. Kyzivat, F. Baker, and B. Campbell for their input and suggestions.
非常感谢O.Troan、S.Barth、A.Yourtchenko、B.Volz、T.Mrugalski、J.Scudder、P.Kyzivat、F.Baker和B.Campbell的意见和建议。
Authors' Addresses
作者地址
Mohamed Boucadair Orange Rennes France
穆罕默德·布卡代尔·奥兰治·雷恩法国
Email: mohamed.boucadair@orange.com
Email: mohamed.boucadair@orange.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