Internet Engineering Task Force (IETF) J. Palet Martinez
Request for Comments: 8585 The IPv6 Company
Category: Informational H. M.-H. Liu
ISSN: 2070-1721 D-Link Systems, Inc.
M. Kawashima
NEC Platforms, Ltd.
May 2019
Internet Engineering Task Force (IETF) J. Palet Martinez
Request for Comments: 8585 The IPv6 Company
Category: Informational H. M.-H. Liu
ISSN: 2070-1721 D-Link Systems, Inc.
M. Kawashima
NEC Platforms, Ltd.
May 2019
Requirements for IPv6 Customer Edge Routers to Support IPv4-as-a-Service
支持IPv4即服务的IPv6客户边缘路由器的要求
Abstract
摘要
This document specifies the IPv4 service continuity requirements for IPv6 Customer Edge (CE) routers that are provided either by the service provider or by vendors who sell through the retail market.
本文档规定了由服务提供商或通过零售市场销售的供应商提供的IPv6客户边缘（CE）路由器的IPv4服务连续性要求。
Specifically, this document extends the basic requirements for IPv6 CE routers as described in RFC 7084 to allow the provisioning of IPv6 transition services for the support of IPv4-as-a-Service (IPv4aaS) by means of new transition mechanisms. The document only covers IPv4aaS, i.e., transition technologies for delivering IPv4 in IPv6-only access networks. IPv4aaS is necessary because there aren't sufficient IPv4 addresses available for every possible customer/ device. However, devices or applications in the customer Local Area Networks (LANs) may be IPv4-only or IPv6-only and still need to communicate with IPv4-only services on the Internet.
具体而言，本文档扩展了RFC 7084中所述的IPv6 CE路由器的基本要求，以允许通过新的转换机制提供IPv6转换服务以支持IPv4-as-a-Service（IPv4aaS）。本文件仅涵盖IPv4aaS，即在仅限IPv6的接入网络中提供IPv4的过渡技术。IPv4aaS是必要的，因为没有足够的IPv4地址可用于每个可能的客户/设备。但是，客户局域网（LAN）中的设备或应用程序可能仅为IPv4或IPv6，并且仍然需要与Internet上仅为IPv4的服务通信。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非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/rfc8585.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8585.
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
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. LAN-Side Configuration . . . . . . . . . . . . . . . . . 5
3.2. Transition Technologies Support for IPv4 Service
Continuity (IPv4-as-a-Service) . . . . . . . . . . . . . 5
3.2.1. 464XLAT . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.2. Dual-Stack Lite (DS-Lite) . . . . . . . . . . . . . . 8
3.2.3. Lightweight 4over6 (lw4o6) . . . . . . . . . . . . . 9
3.2.4. MAP-E . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.5. MAP-T . . . . . . . . . . . . . . . . . . . . . . . . 10
4. IPv4 Multicast Support . . . . . . . . . . . . . . . . . . . 11
5. UPnP Support . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Comparison to RFC 7084 . . . . . . . . . . . . . . . . . . . 12
7. Code Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Usage Scenarios . . . . . . . . . . . . . . . . . . 17
Appendix B. End-User Network Architecture . . . . . . . . . . . 18
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. LAN-Side Configuration . . . . . . . . . . . . . . . . . 5
3.2. Transition Technologies Support for IPv4 Service
Continuity (IPv4-as-a-Service) . . . . . . . . . . . . . 5
3.2.1. 464XLAT . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.2. Dual-Stack Lite (DS-Lite) . . . . . . . . . . . . . . 8
3.2.3. Lightweight 4over6 (lw4o6) . . . . . . . . . . . . . 9
3.2.4. MAP-E . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.5. MAP-T . . . . . . . . . . . . . . . . . . . . . . . . 10
4. IPv4 Multicast Support . . . . . . . . . . . . . . . . . . . 11
5. UPnP Support . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Comparison to RFC 7084 . . . . . . . . . . . . . . . . . . . 12
7. Code Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Usage Scenarios . . . . . . . . . . . . . . . . . . 17
Appendix B. End-User Network Architecture . . . . . . . . . . . 18
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
This document defines IPv4 service continuity features over an IPv6-only network for residential or small office routers (referred to as "IPv6 Transition CE Routers") in order to establish an industry baseline for transition features to be implemented on such routers.
本文档定义了住宅或小型办公室路由器（称为“IPv6过渡CE路由器”）在仅IPv6网络上的IPv4服务连续性功能，以便为在此类路由器上实施的过渡功能建立行业基线。
These routers rely upon requirements for IPv6 CE routers defined in [RFC7084]. The scope of this document is to ensure IPv4 service continuity support for devices in the LAN side. This ensures that remote IPv4-only services continue to be accessible, for both IPv4-only and IPv6-only applications and devices, located in the LAN side behind an IPv6 Transition CE Router connected to an IPv6-only access network. These ISP access networks are typically referred to as Wide Area Networks (WANs), even if they may be metropolitan or regional in some cases. Figure 1 presents a simplified view of this architecture.
这些路由器依赖于[RFC7084]中定义的IPv6 CE路由器的要求。本文档的范围是确保局域网端设备的IPv4服务连续性支持。这可确保仅IPv4和仅IPv6应用程序和设备的远程仅IPv4服务继续可访问，这些应用程序和设备位于连接到仅IPv6访问网络的IPv6转换CE路由器后面的LAN端。这些ISP接入网络通常被称为广域网（WAN），即使在某些情况下它们可能是城域网或区域网。图1给出了该体系结构的简化视图。
+------------+ +------------+ \
| IPv4-only | | IPv4/IPv6 | \
| Remote | | Remote | |
| Host | | Host | | Internet
+--------+---+ +---+--------+ |
| | /
| | /
+-+-----------+-+ \
| Service | \
| Provider | \
| Router | | Service
+-------+-------+ | Provider
| IPv6-only | Network
| Customer /
| Internet Connection /
| /
+------+--------+ \
| IPv6 | \
| Transition CE | \
| Router | |
+---+-------+---+ |
LAN A | | LAN B | End-User
-+----------------+- -+-----+-------------+- | Network(s)
| | | |
+---+------+ +----+-----+ +-----+----+ |
| IPv6-only| | IPv4-only| |IPv4/IPv6 | /
| Host | | Host | | Host | /
+----------+ +----------+ +----------+ /
+------------+ +------------+ \
| IPv4-only | | IPv4/IPv6 | \
| Remote | | Remote | |
| Host | | Host | | Internet
+--------+---+ +---+--------+ |
| | /
| | /
+-+-----------+-+ \
| Service | \
| Provider | \
| Router | | Service
+-------+-------+ | Provider
| IPv6-only | Network
| Customer /
| Internet Connection /
| /
+------+--------+ \
| IPv6 | \
| Transition CE | \
| Router | |
+---+-------+---+ |
LAN A | | LAN B | End-User
-+----------------+- -+-----+-------------+- | Network(s)
| | | |
+---+------+ +----+-----+ +-----+----+ |
| IPv6-only| | IPv4-only| |IPv4/IPv6 | /
| Host | | Host | | Host | /
+----------+ +----------+ +----------+ /
Figure 1: Simplified Typical IPv6-Only Access Network
图1：简化的典型仅IPv6接入网络
This document covers a set of IP transition techniques required when ISPs have, or want to have, an IPv6-only access network. This is a common situation when sufficient IPv4 addresses are no longer available for every possible customer and device, which causes IPv4 addresses to become prohibitively expensive. This, in turn, may result in service providers provisioning IPv6-only WAN access. At the same time, they need to ensure that both IPv4-only and IPv6-only devices and applications in the customer networks can still reach IPv4-only devices and applications on the Internet.
本文档介绍了当ISP拥有或希望拥有仅限IPv6的接入网络时所需的一组IP转换技术。当不再有足够的IPv4地址可用于每个可能的客户和设备时，这是一种常见的情况，这会导致IPv4地址变得非常昂贵。这反过来可能导致服务提供商提供仅限IPv6的WAN访问。同时，他们需要确保客户网络中仅IPv4和仅IPv6的设备和应用程序仍然可以访问Internet上仅IPv4的设备和应用程序。
This document specifies the IPv4 service continuity mechanisms to be supported by an IPv6 Transition CE Router and relevant provisioning or configuration information differences from [RFC7084].
本文档规定了IPv6过渡CE路由器支持的IPv4服务连续性机制以及与[RFC7084]的相关设置或配置信息差异。
This document is not a recommendation for service providers to use any specific transition mechanism.
本文档不建议服务提供商使用任何特定的转换机制。
Automatic provisioning of more complex topology than a single router with multiple LAN interfaces may be handled by means of the Home Networking Control Protocol (HNCP) [RFC7788], which is out of the scope of this document.
可通过家庭网络控制协议（HNCP）[RFC7788]处理比具有多个LAN接口的单个路由器更复杂的拓扑结构的自动供应，该协议不在本文档的范围内。
Since it is impossible to know prior to sale which transition mechanism a device will need over its lifetime, an IPv6 Transition CE Router intended for the retail market MUST support all the IPv4aaS transition mechanisms listed in this document. Service providers that specify feature sets for the IPv6 Transition CE Router may define a different set of features from those included in this document, for example, features that support only some of the transition mechanisms enumerated in this document.
由于在销售前不可能知道设备在其生命周期内需要哪种转换机制，因此用于零售市场的IPv6转换CE路由器必须支持本文档中列出的所有IPv4aaS转换机制。为IPv6转换CE路由器指定功能集的服务提供商可以定义与本文档中包含的功能集不同的功能集，例如，仅支持本文档中列举的某些转换机制的功能集。
Appendices A and B contain a complete description of the usage scenarios and end-user network architecture, respectively. These appendices, along with [RFC7084], will facilitate a clearer understanding of this document.
附录A和附录B分别包含使用场景和最终用户网络架构的完整描述。这些附录以及[RFC7084]将有助于更清楚地理解本文件。
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]所述进行解释。
This document uses the same terms as in [RFC7084], with minor clarifications.
本文件使用与[RFC7084]中相同的术语，但有一些细微的澄清。
"IPv4aaS" stands for "IPv4-as-a-Service", meaning transition technologies for delivering IPv4 in IPv6-only connectivity.
“IPv4aaS”代表“IPv4即服务”，这意味着在仅IPv6连接中提供IPv4的过渡技术。
The term "IPv6 transition Customer Edge Router with IPv4aaS" (shortened as "IPv6 Transition CE Router") is defined as an IPv6 Customer Edge Router that provides features for the delivery of IPv4 services over an IPv6-only WAN network, including IPv6-IPv4 communications.
术语“带IPv4aaS的IPv6过渡客户边缘路由器”（简称“IPv6过渡CE路由器”）定义为IPv6客户边缘路由器，该路由器提供通过仅IPv6的WAN网络（包括IPv6-IPv4通信）交付IPv4服务的功能。
The term "WAN Interface" as used in this document is defined as an IPv6 Transition CE Router attachment to an IPv6-only link used to provide connectivity to a service provider network, including link Internet-layer (or higher layers) tunnels, such as IPv4-in-IPv6 tunnels.
本文档中使用的术语“WAN接口”定义为IPv6过渡CE路由器连接到仅IPv6链路，用于提供与服务提供商网络的连接，包括链路互联网层（或更高层）隧道，如IPv4-in-IPv6隧道。
The IPv6 Transition CE Router MUST comply with [RFC7084] ("Basic Requirements for IPv6 Customer Edge Routers"). This document adds new requirements, as described in the following subsections.
IPv6转换CE路由器必须符合[RFC7084]（“IPv6客户边缘路由器的基本要求”）。本文件增加了新的要求，如下小节所述。
A new LAN requirement is added, which is, in fact, common in regular IPv6 Transition CE Routers, and is required by most of the transition mechanisms:
增加了一个新的LAN要求，这实际上在常规IPv6转换CE路由器中很常见，并且是大多数转换机制所需要的：
L-1: The IPv6 Transition CE Router MUST implement a DNS proxy as described in [RFC5625] ("DNS Proxy Implementation Guidelines").
L-1:IPv6转换CE路由器必须实现[RFC5625]（“DNS代理实现指南”）中所述的DNS代理。
3.2. Transition Technologies Support for IPv4 Service Continuity (IPv4- as-a-Service)
3.2. 过渡技术支持IPv4服务连续性（IPv4即服务）
The main target of this document is the support of IPv6-only WAN access. To enable legacy IPv4 functionality, this document also includes the support of IPv4-only devices and applications in the customer LANs, as well as IPv4-only services on the Internet. Thus, both IPv4-only and IPv6-only devices in the customer-side LANs of the IPv6 Transition CE Router are able to reach the IPv4-only services.
本文档的主要目标是支持仅限IPv6的WAN访问。为了启用传统IPv4功能，本文档还包括对客户LAN中仅IPv4设备和应用程序的支持，以及对Internet上仅IPv4服务的支持。因此，IPv6转换CE路由器的客户端LAN中的仅IPv4和仅IPv6设备都能够访问仅IPv4服务。
Note that this document only configures IPv4aaS in the IPv6 Transition CE Router itself; it does not forward such information to devices attached to the LANs. Thus, the WAN configuration and availability of native IPv4 or IPv4aaS are transparent for the devices attached to the LANs.
请注意，本文档仅在IPv6转换CE路由器本身中配置IPv4aaS；它不会将此类信息转发到连接到LAN的设备。因此，本机IPv4或IPV4A的WAN配置和可用性对于连接到LAN的设备是透明的。
This document takes no position on simultaneous operation of one or several transition mechanisms and/or native IPv4.
本文档不涉及一个或多个转换机制和/或本机IPv4的同时操作。
In order to seamlessly provide IPv4 service continuity in the customer LANs and allow automated IPv6 transition mechanism provisioning, the following general transition requirements are defined.
为了在客户LAN中无缝提供IPv4服务连续性并允许自动IPv6转换机制配置，定义了以下一般转换要求。
General transition requirements:
一般过渡要求：
TRANS-1: The IPv6 Transition CE Router MUST support the DHCPv6 S46 priority options described in [RFC8026] ("Unified IPv4-in-IPv6 Softwire Customer Premises Equipment (CPE): A DHCPv6-Based Prioritization Mechanism").
TRANS-1:IPv6转换CE路由器必须支持[RFC8026]中所述的DHCPv6 S46优先级选项（“统一IPv4-in-IPv6软线客户场所设备（CPE）：基于DHCPv6的优先级机制”）。
TRANS-2: The IPv6 Transition CE Router MUST have a GUI and either a CLI or API (or both) to manually enable/disable each of the supported transition mechanisms.
TRANS-2:IPv6转换CE路由器必须具有GUI和CLI或API（或两者兼有），才能手动启用/禁用每个受支持的转换机制。
TRANS-3: If an IPv6 Transition CE Router supports more than one LAN subnet, the IPv6 Transition CE Router MUST allow appropriate subnetting and configuration of the address space among several interfaces. In some transition mechanisms, this may require differentiating mappings/ translations on a per-interface basis.
TRANS-3：如果IPv6转换CE路由器支持多个LAN子网，则IPv6转换CE路由器必须允许在多个接口之间进行适当的子网设置和地址空间配置。在某些转换机制中，这可能需要在每个接口的基础上区分映射/转换。
In order to allow the service provider to disable all the transition mechanisms and/or choose the most convenient one, the IPv6 Transition CE Router MUST follow the following configuration steps:
为了允许服务提供商禁用所有转换机制和/或选择最方便的转换机制，IPv6转换CE路由器必须遵循以下配置步骤：
CONFIG-1: Request the relevant configuration options for each supported transition mechanisms, which MUST remain disabled at this step.
CONFIG-1：请求每个受支持的转换机制的相关配置选项，该转换机制在此步骤中必须保持禁用状态。
CONFIG-2: Following the steps in Section 1.4 of [RFC8026], MUST check for a valid match in OPTION_S46_PRIORITY, which allows enabling/disabling a transition mechanism.
配置2：按照[RFC8026]第1.4节中的步骤，必须检查选项_S46_优先级中是否存在有效匹配，该选项允许启用/禁用转换机制。
CONFIG-3: Keep disabled all the transition mechanisms if no match is found between the priority list and the candidate list, unless a NAT64 [RFC6146] prefix has been configured, in which case, 464XLAT [RFC6877] MUST be enabled.
配置3：如果在优先级列表和候选列表之间未找到匹配项，则禁用所有转换机制，除非已配置NAT64[RFC6146]前缀，在这种情况下，必须启用464XLAT[RFC6877]。
Because 464XLAT has no DHCPv6 configuration options, it can't currently be included in the OPTION_S46_PRIORITY. In the future, an update of [RFC8026] or a NAT64 DHCPv6 configuration option may enable it. Meanwhile, if an operator provides 464XLAT, it needs to ensure that OPTION_S46_PRIORITY is not sent for any other transition mechanism to the relevant customers.
由于464XLAT没有DHCPv6配置选项，因此当前无法将其包含在选项_S46_优先级中。将来，更新[RFC8026]或NAT64 DHCPv6配置选项可能会启用它。同时，如果运营商提供464XLAT，则需要确保不会将任何其他转换机制的选项_S46_优先级发送给相关客户。
The following subsections describe the requirements for supporting each one of the transition mechanisms. An IPv6 Transition CE Router intended for the retail market MUST support all of them.
以下小节描述了支持每个过渡机制的要求。面向零售市场的IPv6过渡CE路由器必须支持所有这些功能。
464XLAT [RFC6877] is a technique to provide IPv4 service over an IPv6-only access network without encapsulation. This architecture assumes a Stateful NAT64 [RFC6146] function deployed at the service provider or a third-party network.
464XLAT[RFC6877]是一种通过仅限IPv6的接入网络提供IPv4服务的技术，无需封装。此体系结构假定在服务提供商或第三方网络上部署了有状态NAT64[RFC6146]功能。
The IPv6 Transition CE Router MUST support customer-side translator (CLAT) functionality [RFC6877] if intended for the retail market. If 464XLAT is supported, it MUST be implemented according to [RFC6877]. The following IPv6 Transition CE Router requirements also apply.
如果用于零售市场，IPv6转换CE路由器必须支持客户端转换器（CLAT）功能[RFC6877]。如果支持464XLAT，则必须按照[RFC6877]执行。以下IPv6转换CE路由器要求也适用。
464XLAT requirements:
464XLAT要求：
464XLAT-1: Unless a dedicated /64 prefix has been acquired, either by using DHCPv6-PD (Dynamic Host Configuration Protocol for IPv6 Prefix Delegation) or by alternative means, the IPv6 Transition CE Router MUST perform IPv4 Network Address Translation (NAT) on IPv4 traffic translated using the CLAT.
464XLAT-1：除非通过使用DHCPv6 PD（IPv6前缀委派的动态主机配置协议）或其他方式获得了专用/64前缀，否则IPv6转换CE路由器必须对使用CLAT转换的IPv4流量执行IPv4网络地址转换（NAT）。
464XLAT-2: The IPv6 Transition CE Router SHOULD support IGD-PCP IWF [RFC6970] ("Universal Plug and Play (UPnP) Internet Gateway Device - Port Control Protocol Interworking Function (IGD-PCP IWF)").
464XLAT-2:IPv6过渡CE路由器应支持IGD-PCP IWF[RFC6970]（“通用即插即用（UPnP）互联网网关设备-端口控制协议互通功能（IGD-PCP IWF）”。
464XLAT-3: If the Port Control Protocol (PCP) [RFC6887] is implemented, the IPv6 Transition CE Router MUST also implement [RFC7291] ("DHCP Options for the Port Control Protocol (PCP)"). Following [RFC6887], if no PCP server is configured, the IPv6 Transition CE Router MAY verify if the default gateway or the NAT64 is the PCP server. The IPv6 Transition CE Router MUST use plain IPv6 mode (i.e., not IPv4-in-IPv6 encapsulation) to send PCP requests to the server.
464XLAT-3：如果实现了端口控制协议（PCP）[RFC6887]，IPv6转换CE路由器也必须实现[RFC7291]（“端口控制协议（PCP）的DHCP选项”）。[RFC6887]之后，如果未配置PCP服务器，IPv6转换CE路由器可能会验证默认网关或NAT64是否为PCP服务器。IPv6转换CE路由器必须使用纯IPv6模式（即，不是IPv4-in-IPv6封装）向服务器发送PCP请求。
464XLAT-4: The IPv6 Transition CE Router MUST implement [RFC7050] ("Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis") in order to discover the provider-side translator (PLAT) translation IPv4 and IPv6 prefix(es)/suffix(es).
464XLAT-4:IPv6转换CE路由器必须实现[RFC7050]（“发现用于IPv6地址合成的IPv6前缀”），以便发现提供方转换器（PLAT）转换IPv4和IPv6前缀/后缀。
464XLAT-5: If PCP is implemented, the IPv6 Transition CE Router MUST follow [RFC7225] ("Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol (PCP)") in order to learn the PLAT-side translation IPv4 and IPv6 prefix(es)/suffix(es) used by an upstream PCP-controlled NAT64 device.
464XLAT-5：如果实现了PCP，IPv6转换CE路由器必须遵循[RFC7225]（“使用端口控制协议（PCP）查找NAT64 IPv6前缀”），以便了解上游PCP控制的NAT64设备使用的平台端转换IPv4和IPv6前缀/后缀。
464XLAT-6: If the network provides several choices for the discovery/learning of the NAT64 prefix, the priority to use one or the other MUST follow this order: 1) [RFC7225] and 2) [RFC7050].
464XLAT-6：如果网络为NAT64前缀的发现/学习提供了多种选择，则使用其中一种前缀的优先级必须遵循以下顺序：1）[RFC7225]和2）[RFC7050]。
The NAT64 prefix could be discovered by means of the method defined in [RFC7050] only if the service provider uses DNS64 [RFC6147]. It may be the case that the service provider does not use or does not trust DNS64 [RFC6147] because the DNS configuration at the CE (or hosts behind the CE) can be modified by the customer. In that case, the service provider may opt to configure the NAT64 prefix by means of the option defined in [RFC7225]. This can also be used if the service provider uses DNS64 [RFC6147].
只有当服务提供商使用DNS64[RFC6147]时，才能通过[RFC7050]中定义的方法发现NAT64前缀。可能是服务提供商不使用或不信任DNS64[RFC6147]，因为客户可以修改CE（或CE后面的主机）上的DNS配置。在这种情况下，服务提供商可以选择通过[RFC7225]中定义的选项配置NAT64前缀。如果服务提供商使用DNS64[RFC6147]，也可以使用此选项。
DS-Lite [RFC6333] enables continued support for IPv4 services. DS-Lite enables a broadband service provider to share IPv4 addresses among customers by combining two well-known technologies: IP in IP (IPv4-in-IPv6) and Network Address Translation (NAT). It is expected that DS-Lite traffic is forwarded over the IPv6 Transition CE Router's native IPv6 WAN interface and not encapsulated in another tunnel.
DS Lite[RFC6333]支持对IPv4服务的持续支持。DS Lite通过结合两种众所周知的技术，使宽带服务提供商能够在客户之间共享IPv4地址：IP-in-IP（IPv4-in-IPv6）和网络地址转换（NAT）。预计DS Lite流量将通过IPv6 Transition CE路由器的本机IPv6 WAN接口转发，而不是封装在另一个隧道中。
The IPv6 Transition CE Router MUST implement DS-Lite B4 functionality [RFC6333] if intended for the retail market. If DS-Lite is supported, it MUST be implemented according to [RFC6333]. The following IPv6 Transition CE Router requirements also apply.
如果用于零售市场，IPv6过渡CE路由器必须实现DS Lite B4功能[RFC6333]。如果支持DS Lite，则必须按照[RFC6333]实现。以下IPv6转换CE路由器要求也适用。
DS-Lite requirements:
DS-Lite要求：
DSLITE-1: The IPv6 Transition CE Router MUST support configuration of DS-Lite via the DS-Lite DHCPv6 option [RFC6334] ("Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite"). The IPv6 Transition CE Router MAY use other mechanisms to configure DS-Lite parameters. Such mechanisms are outside the scope of this document.
DSLITE-1:IPv6转换CE路由器必须支持通过DS Lite DHCPv6选项[RFC6334]（“双栈Lite的IPv6动态主机配置协议（DHCPv6）选项”）配置DS Lite。IPv6转换CE路由器可以使用其他机制来配置DS Lite参数。这些机制不在本文件的范围之内。
DSLITE-2: The IPv6 Transition CE Router SHOULD support IGD-PCP IWF [RFC6970].
DSLITE-2:IPv6过渡CE路由器应支持IGD-PCP IWF[RFC6970]。
DSLITE-3: If PCP [RFC6887] is implemented, the IPv6 Transition CE Router SHOULD implement [RFC7291]. If PCP [RFC6887] is implemented and a PCP server is not configured, the IPv6 Transition CE Router MUST assume, by default, that the Address Family Transition Router (AFTR, commonly called "CGN" - Carrier-Grade NAT) is the PCP server. The IPv6
DSLITE-3：如果实现了PCP[RFC6887]，IPv6转换CE路由器应该实现[RFC7291]。如果实现了PCP[RFC6887]且未配置PCP服务器，则IPv6转换CE路由器在默认情况下必须假定地址系列转换路由器（AFTR，通常称为“CGN”-运营商级NAT）是PCP服务器。IPv6
Transition CE Router MUST use plain IPv6 mode (i.e., not IPv4-in-IPv6 encapsulation) to send PCP requests to the server. The term "default" above is to be interpreted as pertaining to a configuration as applied by a vendor prior to the administrator changing it for its initial activation.
转换CE路由器必须使用纯IPv6模式（即，不是IPv6中的IPv4封装）向服务器发送PCP请求。上述术语“默认”应解释为在管理员更改初始激活配置之前，供应商应用的配置。
DSLITE-4: The IPv6 Transition CE Router MUST NOT perform IPv4 Network Address Translation (NAT) on IPv4 traffic encapsulated using DS-Lite [RFC6333].
DSLITE-4:IPv6转换CE路由器不得对使用DS Lite[RFC6333]封装的IPv4流量执行IPv4网络地址转换（NAT）。
lw4o6 [RFC7596] specifies an extension to DS-Lite that moves the NAPT function from the DS-Lite tunnel concentrator to the tunnel client located in the IPv6 Transition CE Router, removing the requirement for an AFTR (CGN) function in the tunnel concentrator and reducing the amount of centralized state.
lw4o6[RFC7596]指定了DS Lite的扩展，该扩展将NAPT功能从DS Lite隧道集中器移动到位于IPv6转换CE路由器中的隧道客户端，从而消除了隧道集中器中AFTR（CGN）功能的要求，并减少了集中状态的数量。
The IPv6 Transition CE Router MUST implement lwB4 functionality [RFC7596] if intended for the retail market. If DS-Lite is implemented, lw4o6 SHOULD be implemented as well. If lw4o6 is supported, it MUST be implemented according to [RFC7596]. The following IPv6 Transition CE Router requirements also apply.
如果用于零售市场，IPv6过渡CE路由器必须实现lwB4功能[RFC7596]。如果实现了DS Lite，那么也应该实现lw4o6。如果支持lw4o6，则必须按照[RFC7596]执行。以下IPv6转换CE路由器要求也适用。
lw4o6 requirements:
lw4o6要求：
LW4O6-1: The IPv6 Transition CE Router MUST support configuration of lw4o6 via the lw4o6 DHCPv6 options [RFC7598] ("DHCPv6 Options for Configuration of Softwire Address and Port-Mapped Clients"). The IPv6 Transition CE Router MAY use other mechanisms to configure lw4o6 parameters. Such mechanisms are outside the scope of this document.
LW4O6-1:IPv6转换CE路由器必须支持通过LW4O6 DHCPv6选项[RFC7598]（“用于配置软线地址和端口映射客户端的DHCPv6选项”）配置LW4O6。IPv6转换CE路由器可以使用其他机制来配置lw4o6参数。这些机制不在本文件的范围之内。
LW4O6-2: The IPv6 Transition CE Router MUST support the DHCPv4-over-DHCPv6 (DHCP 4o6) transport described in [RFC7341] ("DHCPv4-over-DHCPv6 (DHCP 4o6) Transport").
LW4O6-2:IPv6转换CE路由器必须支持[RFC7341]中描述的DHCPv4-over-DHCPv6（DHCP 4o6）传输（“DHCPv4-over-DHCPv6（DHCP 4o6）传输”）。
LW4O6-3: The IPv6 Transition CE Router MAY support Dynamic Allocation of Shared IPv4 Addresses as described in [RFC7618] ("Dynamic Allocation of Shared IPv4 Addresses").
LW4O6-3:IPv6转换CE路由器可能支持[RFC7618]中所述的共享IPv4地址的动态分配（“共享IPv4地址的动态分配”）。
Mapping of Address and Port with Encapsulation (MAP-E) [RFC7597] is a mechanism for transporting IPv4 packets across an IPv6 network using IP encapsulation. MAP-E includes an algorithmic mechanism for mapping between IPv6 and IPv4 addresses.
地址和端口的封装映射（MAP-E）[RFC7597]是一种使用IP封装在IPv6网络上传输IPv4数据包的机制。MAP-E包括一种用于在IPv6和IPv4地址之间映射的算法机制。
The IPv6 Transition CE Router MUST support MAP-E CE functionality [RFC7597] if intended for the retail market. If MAP-E is supported, it MUST be implemented according to [RFC7597]. The following IPv6 Transition CE Router requirements also apply.
如果用于零售市场，IPv6过渡CE路由器必须支持MAP-E CE功能[RFC7597]。如果支持MAP-E，则必须按照[RFC7597]执行。以下IPv6转换CE路由器要求也适用。
MAP-E requirements:
MAP-E要求：
MAPE-1: The IPv6 Transition CE Router MUST support configuration of MAP-E via the MAP-E DHCPv6 options [RFC7598]. The IPv6 Transition CE Router MAY use other mechanisms to configure MAP-E parameters. Such mechanisms are outside the scope of this document.
MAPE-1:IPv6转换CE路由器必须支持通过MAP-E DHCPv6选项配置MAP-E[RFC7598]。IPv6转换CE路由器可以使用其他机制来配置MAP-E参数。这些机制不在本文件的范围之内。
MAPE-2: The IPv6 Transition CE Router MAY support Dynamic Allocation of Shared IPv4 Addresses as described in [RFC7618].
MAPE-2:IPv6转换CE路由器可能支持[RFC7618]中所述的共享IPv4地址的动态分配。
MAP-T [RFC7599] is a mechanism similar to MAP-E, differing from it in that MAP-T uses IPv4-IPv6 translation, instead of encapsulation, as the form of IPv6 domain transport.
MAP-T[RFC7599]是一种类似于MAP-E的机制，与之不同的是，MAP-T使用IPv4-IPv6转换而不是封装作为IPv6域传输的形式。
The IPv6 Transition CE Router MUST support MAP-T CE functionality [RFC7599] if intended for the retail market. If MAP-T is supported, it MUST be implemented according to [RFC7599]. The following IPv6 Transition CE Router requirements also apply.
如果用于零售市场，IPv6过渡CE路由器必须支持MAP-T CE功能[RFC7599]。如果支持MAP-T，则必须按照[RFC7599]实现。以下IPv6转换CE路由器要求也适用。
MAP-T requirements:
MAP-T要求：
MAPT-1: The IPv6 Transition CE Router MUST support configuration of MAP-T via the MAP-T DHCPv6 options [RFC7598]. The IPv6 Transition CE Router MAY use other mechanisms to configure MAP-T parameters. Such mechanisms are outside the scope of this document.
MAPT-1:IPv6转换CE路由器必须支持通过MAP-T DHCPv6选项配置MAP-T[RFC7598]。IPv6转换CE路由器可以使用其他机制来配置MAP-T参数。这些机制不在本文件的范围之内。
MAPT-2: The IPv6 Transition CE Router MAY support Dynamic Allocation of Shared IPv4 Addresses as described in [RFC7618].
MAPT-2:IPv6转换CE路由器可能支持[RFC7618]中所述的共享IPv4地址的动态分配。
Existing IPv4 deployments support IPv4 multicast for services such as IPTV. In the transition phase, it is expected that multicast services will still be provided using IPv4 to the customer LANs.
现有IPv4部署支持IPTV等服务的IPv4多播。在过渡阶段，预计仍将使用IPv4向客户LAN提供多播服务。
If the IPv6 Transition CE Router supports delivery of IPv4 multicast services, then it MUST support [RFC8114] ("Delivery of IPv4 Multicast Services to IPv4 Clients over an IPv6 Multicast Network") and [RFC8115] ("DHCPv6 Option for IPv4-Embedded Multicast and Unicast IPv6 Prefixes").
如果IPv6转换CE路由器支持IPv4多播服务的传递，则它必须支持[RFC8114]（“通过IPv6多播网络向IPv4客户端传递IPv4多播服务”）和[RFC8115]（“用于IPv4嵌入式多播和单播IPv6前缀的DHCPv6选项”）。
If the UPnP WANIPConnection:2 service [UPnP-WANIPC][OCF-IGD] is enabled on a CE router, but cannot be associated with an IPv4 interface established by an IPv4aaS mechanism or cannot determine which ports are available, an AddPortMapping() or AddAnyPortMapping() action MUST be rejected with error code 729 ("ConflictWithOtherMechanisms"). Port availability could be determined through PCP or access to a configured port set (if the IPv4aaS mechanism limits the available ports).
如果CE路由器上启用了UPnP WANIPConnection:2服务[UPnP WANIPC][OCF-IGD]，但无法与IPv4aaS机制建立的IPv4接口相关联，或者无法确定哪些端口可用，则必须拒绝AddPortMapping（）或AddAnyPortMapping（）操作，错误代码为729（“与其他机制冲突”）。端口可用性可以通过PCP或访问配置的端口集来确定（如果IPv4aaS机制限制可用端口）。
An AddPortMapping() request for a port that is not available MUST result in "ConflictInMappingEntry".
对不可用端口的AddPortMapping（）请求必须导致“ConflictInMapping”。
An AddAnyPortMapping() request for a port that is not available SHOULD result in a successful mapping with an alternative "NewReservedPort" value from within the configured port set range or as assigned by PCP as per Section 5.6.1 of [RFC6970].
对于不可用端口的AddAnyPortMapping（）请求应导致使用配置端口集范围内或PCP根据[RFC6970]第5.6.1节指定的替代“NewReservedPort”值成功映射。
Note that IGD:1 and its WANIPConnection:1 service have been deprecated by OCF (Open Connectivity Foundation) [OCF-IGD].
请注意，OCF（开放连接基金会）[OCF-IGD]已弃用IGD:1及其WANIConnection:1服务。
This document doesn't include support for 6rd [RFC5969] because it is an IPv6-in-IPv4 tunneling.
本文档不包括对第6rd[RFC5969]的支持，因为它是IPv4隧道中的IPv6。
Regarding DS-LITE [RFC6333], this document includes slightly different requirements related to the support of PCP [RFC6887], IGD-PCP IWF [RFC6970], and the prioritization of the transition mechanisms, including dual-stack.
关于DS-LITE[RFC6333]，本文件包括与支持PCP[RFC6887]、IGD-PCP IWF[RFC6970]和转换机制（包括双堆栈）优先级相关的略有不同的要求。
At the time of this writing, one of the apparent main issues for vendors with regard to including new functionalities, such as support for new transition mechanisms, is the lack of space in the flash (or equivalent) memory. However, it has been confirmed from existing open-source implementations (e.g., OpenWRT/LEDE, Linux, and VPP) that adding the support for the new transition mechanisms requires around 10-12 KBs because most of the code base is shared among several transition mechanisms, which are already supported by [RFC7084]. A single data plane is common to all of them, which typically means, in popular CEs already in the market [OpenWRT], the new required code is only about 0.15% of the total existing code size.
在撰写本文时，供应商在包括新功能（如支持新的转换机制）方面的一个明显的主要问题是闪存（或等效）内存中缺少空间。然而，从现有的开源实现（例如OpenWRT/LEDE、Linux和VPP）可以确认，添加对新转换机制的支持需要大约10-12 KBs，因为大多数代码库在几个转换机制之间共享，而[RFC7084]已经支持这些机制。一个数据平面对于所有这些产品都是通用的，这通常意味着，在已经上市的流行CEs[OpenWRT]中，新的所需代码仅为现有代码总量的0.15%左右。
In general, the new requirements don't have extra cost in terms of RAM memory, nor other hardware requirements such as more powerful CPUs, if compared to the cost of NAT44 code. Thus, existing hardware should be able to support all of them with minimal impact.
一般来说，与NAT44代码的成本相比，新要求在RAM内存方面没有额外成本，也没有其他硬件要求，如更强大的CPU。因此，现有硬件应该能够以最小的影响支持所有这些功能。
The other issue seems to be the cost of developing the code for those new functionalities. However, at the time of writing this document, it has been confirmed that there are several open-source versions of the required code for supporting all the new transition mechanisms, and several vendors already have implementations and provided them to ISPs. Therefore, the development cost is negligible, and only integration and testing cost may become an issue.
另一个问题似乎是为这些新功能开发代码的成本。然而，在编写本文件时，已经确认有几个开源版本的所需代码支持所有新的转换机制，并且几个供应商已经有了实现并将其提供给ISP。因此，开发成本可以忽略不计，只有集成和测试成本可能成为一个问题。
Finally, in some cases, operators supporting several transition mechanisms may need to consider training costs for staff in all the techniques for the operation and management of these mechanisms, even if the costs are not directly caused by supporting this document but because of business decisions.
最后，在某些情况下，支持多个过渡机制的运营商可能需要考虑这些机构的操作和管理的所有技术中的员工培训成本，即使成本不是由支持该文档而是由业务决策直接引起的。
The IPv6 Transition CE Router must comply with the Security Considerations in [RFC7084] as well as those for each transition mechanism implemented by the IPv6 Transition CE Router.
IPv6转换CE路由器必须符合[RFC7084]中的安全注意事项以及IPv6转换CE路由器实现的每个转换机制的安全注意事项。
As described in the Security Considerations of [RFC8026] and [RFC8415], there are generic DHCP security issues, which, in the case of this document, mean that malicious nodes may alter the priority of the transition mechanisms.
如[RFC8026]和[RFC8415]的安全注意事项所述，存在通用DHCP安全问题，在本文档中，这意味着恶意节点可能会改变转换机制的优先级。
Access network architecture for securing DHCP within the access network is out of scope for this document. Securing DHCP in the LAN is also not in scope. DHCP packets MUST NOT be forwarded between LAN and WAN interfaces of an IPv6 Transition CE Router.
用于在访问网络中保护DHCP的访问网络体系结构不在本文档的范围内。在LAN中保护DHCP也不在范围内。不得在IPv6转换CE路由器的LAN和WAN接口之间转发DHCP数据包。
This document has no IANA actions.
本文档没有IANA操作。
[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>.
[RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, <https://www.rfc-editor.org/info/rfc5625>.
[RFC5625]Bellis，R.，“DNS代理实施指南”，BCP 152，RFC 5625，DOI 10.17487/RFC5625，2009年8月<https://www.rfc-editor.org/info/rfc5625>.
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, DOI 10.17487/RFC5969, August 2010, <https://www.rfc-editor.org/info/rfc5969>.
[RFC5969]Townsley，W.和O.Troan，“IPv4基础设施上的IPv6快速部署（第6条）——协议规范”，RFC 5969，DOI 10.17487/RFC5969，2010年8月<https://www.rfc-editor.org/info/rfc5969>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, April 2011, <https://www.rfc-editor.org/info/rfc6146>.
[RFC6146]Bagnulo，M.，Matthews，P.，和I.van Beijnum，“有状态NAT64：从IPv6客户端到IPv4服务器的网络地址和协议转换”，RFC 6146，DOI 10.17487/RFC6146，2011年4月<https://www.rfc-editor.org/info/rfc6146>.
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, DOI 10.17487/RFC6147, April 2011, <https://www.rfc-editor.org/info/rfc6147>.
[RFC6147]Bagnulo，M.，Sullivan，A.，Matthews，P.，和I.van Beijnum，“DNS64：用于从IPv6客户端到IPv4服务器的网络地址转换的DNS扩展”，RFC 6147，DOI 10.17487/RFC6147，2011年4月<https://www.rfc-editor.org/info/rfc6147>.
[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, <https://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月<https://www.rfc-editor.org/info/rfc6333>.
[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, <https://www.rfc-editor.org/info/rfc6334>.
[RFC6334]Hankins，D.和T.Mrugalski，“双栈Lite的IPv6动态主机配置协议（DHCPv6）选项”，RFC 6334，DOI 10.17487/RFC6334，2011年8月<https://www.rfc-editor.org/info/rfc6334>.
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", RFC 6877, DOI 10.17487/RFC6877, April 2013, <https://www.rfc-editor.org/info/rfc6877>.
[RFC6877]Mawatari，M.，Kawashima，M.，和C.Byrne，“464XLAT：有状态和无状态翻译的组合”，RFC 6877，DOI 10.17487/RFC6877，2013年4月<https://www.rfc-editor.org/info/rfc6877>.
[RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, DOI 10.17487/RFC6887, April 2013, <https://www.rfc-editor.org/info/rfc6887>.
[RFC6887]Wing，D.，Ed.，Cheshire，S.，Boucadair，M.，Penno，R.，和P.Selkirk，“港口控制协议（PCP）”，RFC 6887，DOI 10.17487/RFC6887，2013年4月<https://www.rfc-editor.org/info/rfc6887>.
[RFC6970] Boucadair, M., Penno, R., and D. Wing, "Universal Plug and Play (UPnP) Internet Gateway Device - Port Control Protocol Interworking Function (IGD-PCP IWF)", RFC 6970, DOI 10.17487/RFC6970, July 2013, <https://www.rfc-editor.org/info/rfc6970>.
[RFC6970]Boucadair，M.，Penno，R.，和D.Wing，“通用即插即用（UPnP）互联网网关设备-端口控制协议互通功能（IGD-PCP IWF）”，RFC 6970，DOI 10.17487/RFC6970，2013年7月<https://www.rfc-editor.org/info/rfc6970>.
[RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis", RFC 7050, DOI 10.17487/RFC7050, November 2013, <https://www.rfc-editor.org/info/rfc7050>.
[RFC7050]Savolainen，T.，Korhonen，J.，和D.Wing，“用于IPv6地址合成的IPv6前缀的发现”，RFC 7050，DOI 10.17487/RFC7050，2013年11月<https://www.rfc-editor.org/info/rfc7050>.
[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic Requirements for IPv6 Customer Edge Routers", RFC 7084, DOI 10.17487/RFC7084, November 2013, <https://www.rfc-editor.org/info/rfc7084>.
[RFC7084]Singh，H.，Beebee，W.，Donley，C.，和B.Stark，“IPv6客户边缘路由器的基本要求”，RFC 7084，DOI 10.17487/RFC7084，2013年11月<https://www.rfc-editor.org/info/rfc7084>.
[RFC7225] Boucadair, M., "Discovering NAT64 IPv6 Prefixes Using the Port Control Protocol (PCP)", RFC 7225, DOI 10.17487/RFC7225, May 2014, <https://www.rfc-editor.org/info/rfc7225>.
[RFC7225]Boucadair，M.，“使用端口控制协议（PCP）发现NAT64 IPv6前缀”，RFC 7225，DOI 10.17487/RFC7225，2014年5月<https://www.rfc-editor.org/info/rfc7225>.
[RFC7291] Boucadair, M., Penno, R., and D. Wing, "DHCP Options for the Port Control Protocol (PCP)", RFC 7291, DOI 10.17487/RFC7291, July 2014, <https://www.rfc-editor.org/info/rfc7291>.
[RFC7291]Boucadair，M.，Penno，R.，和D.Wing，“端口控制协议（PCP）的DHCP选项”，RFC 7291，DOI 10.17487/RFC7291，2014年7月<https://www.rfc-editor.org/info/rfc7291>.
[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>.
[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>.
[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>.
[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, <https://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月<https://www.rfc-editor.org/info/rfc7599>.
[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>.
[RFC8026] Boucadair, M. and I. Farrer, "Unified IPv4-in-IPv6 Softwire Customer Premises Equipment (CPE): A DHCPv6-Based Prioritization Mechanism", RFC 8026, DOI 10.17487/RFC8026, November 2016, <https://www.rfc-editor.org/info/rfc8026>.
[RFC8026]Boucadair，M.和I.Farrer，“统一IPv4-in-IPv6软线客户场所设备（CPE）：基于DHCPv6的优先级机制”，RFC 8026，DOI 10.17487/RFC8026，2016年11月<https://www.rfc-editor.org/info/rfc8026>.
[RFC8114] Boucadair, M., Qin, C., Jacquenet, C., Lee, Y., and Q. Wang, "Delivery of IPv4 Multicast Services to IPv4 Clients over an IPv6 Multicast Network", RFC 8114, DOI 10.17487/RFC8114, March 2017, <https://www.rfc-editor.org/info/rfc8114>.
[RFC8114]Boucadair，M.，Qin，C.，Jacquenet，C.，Lee，Y.，和Q.Wang，“通过IPv6多播网络向IPv4客户端提供IPv4多播服务”，RFC 8114，DOI 10.17487/RFC8114，2017年3月<https://www.rfc-editor.org/info/rfc8114>.
[RFC8115] Boucadair, M., Qin, J., Tsou, T., and X. Deng, "DHCPv6 Option for IPv4-Embedded Multicast and Unicast IPv6 Prefixes", RFC 8115, DOI 10.17487/RFC8115, March 2017, <https://www.rfc-editor.org/info/rfc8115>.
[RFC8115]Boucadair，M.，Qin，J.，Tsou，T.，和X.Deng，“IPv4嵌入式多播和单播IPv6前缀的DHCPv6选项”，RFC 8115，DOI 10.17487/RFC8115，2017年3月<https://www.rfc-editor.org/info/rfc8115>.
[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>.
[IPv6Survey] Palet Martinez, J., "Best Current Operational Practice for operators: IPv6 Prefix Assignment for end-customers -- persistent vs non-persistent and what size to choose", January 2018, <https://indico.uknof.org.uk/event/41/contribution/5/ material/slides/0.pdf>.
[IPv6Survey]Palet Martinez，J.，“运营商当前最佳运营实践：终端客户的IPv6前缀分配——持久性与非持久性以及选择的规模”，2018年1月<https://indico.uknof.org.uk/event/41/contribution/5/ 材料/幻灯片/0.pdf>。
[OCF-IGD] Open Connectivity Foundation, "Internet Gateway Device (IGD) V 2.0", March 2015, <https://openconnectivity.org/developer/specifications/ upnp-resources/upnp/internet-gateway-device-igd-v-2-0>.
[OCF-IGD]开放连接基金会，“互联网网关设备（IGD）V 2”，2015年3月，<https://openconnectivity.org/developer/specifications/ upnp资源/upnp/internet-gateway-device-igd-v-2-0>。
[OpenWRT] OpenWRT, "Packages", <https://openwrt.org/packages/start>.
[OpenWRT]OpenWRT，“软件包”<https://openwrt.org/packages/start>.
[RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 2016, <https://www.rfc-editor.org/info/rfc7788>.
[RFC7788]Stenberg，M.，Barth，S.，和P.Pfister，“家庭网络控制协议”，RFC 7788，DOI 10.17487/RFC7788，2016年4月<https://www.rfc-editor.org/info/rfc7788>.
[UPnP-IGD] UPnP Forum, "InternetGatewayDevice:2 Device Template Version 1.01", December 2010, <http://upnp.org/specs/gw/ UPnP-gw-InternetGatewayDevice-v2-Device.pdf>.
[UPnP IGD]UPnP论坛，“InternetGatewayDevice:2设备模板版本1.01”，2010年12月<http://upnp.org/specs/gw/ UPnP-gw-InternetGatewayDevice-v2-Device.pdf>。
[UPnP-WANIPC] UPnP Forum, "WANIPConnection:2 Service", September 2010, <http://upnp.org/specs/gw/ UPnP-gw-WANIPConnection-v2-Service.pdf>.
[UPnP WANIPC]UPnP论坛，“WANIConnect:2服务”，2010年9月<http://upnp.org/specs/gw/ UPnP-gw-WANIPConnection-v2-Service.pdf>。
The situation of ongoing IPv6 deployment and a lack of IPv4 addresses is not happening at the same pace in every country and even within every country for every ISP. For different technical, financial, commercial/marketing, and socio-economic reasons, each network is transitioning at their own pace; the global transition timings cannot be reliably estimated.
在每个国家，甚至在每个国家的每个ISP中，正在进行的IPv6部署和缺少IPv4地址的情况并没有以相同的速度发生。由于不同的技术、财务、商业/营销和社会经济原因，每个网络都在以自己的速度过渡；无法可靠地估计全局转换时间。
Different studies (for example, [IPv6Survey]) also show that IPv6 deployment is a changing situation. In a single country, not all operators will necessarily provide IPv6 support. Consumers may also switch ISPs and use the same IPv6 Transition CE Router with either an ISP that provides IPv4-only or an ISP that provides IPv6 with IPv4aaS.
不同的研究（例如，[IPv6Survey]）也表明IPv6部署是一种不断变化的情况。在一个国家，并非所有运营商都必须提供IPv6支持。消费者还可以切换ISP，并与仅提供IPv4的ISP或提供带有IPv4aaS的IPv6的ISP使用相同的IPv6转换CE路由器。
So, to cover all those evolving situations, an IPv6 Transition CE Router is required, at least from the perspective of transition support.
因此，为了覆盖所有这些不断变化的情况，至少从过渡支持的角度来看，需要一个IPv6过渡CE路由器。
Moreover, because some services and service providers will remain IPv4-only for an undetermined period of time, IPv4 service continuity is required. Thus, there is a need for CEs to support IPv4aaS indefinitely.
此外，由于某些服务和服务提供商将只在一段不确定的时间内保留IPv4，因此需要IPv4服务连续性。因此，CEs需要无限期地支持IPv4aaS。
Based on these premises, this document ensures that the IPv6 Transition CE Router allows the continued transition from networks that today may provide access with dual-stack or IPv6-in-IPv4 (as described in [RFC7084]) to networks that provide IPv6-only access with IPv4aaS.
基于这些前提，本文件确保IPv6 Transition CE路由器允许从目前可能提供双栈或IPv6-in-IPv4访问的网络（如[RFC7084]中所述）持续过渡到仅提供IPv6访问的网络（使用IPv4aaS）。
Considering that situation and different possible usage cases, the IPv6 Transition CE Router described in this document is expected to be used in residential/household; small office, home office (SOHO); and small/medium enterprise (SME). Common usage is any kind of Internet access (web, email, streaming, online gaming, etc.), and more advanced requirements include inbound connections (IP cameras, web, DNS, email, VPN, etc.).
考虑到这种情况和不同的可能使用情况，本文件中描述的IPv6过渡CE路由器预计将用于住宅/家庭；小型办公室、家庭办公室（SOHO）；和中小型企业。常见用途是任何类型的互联网接入（web、电子邮件、流媒体、在线游戏等），更高级的要求包括入站连接（IP摄像头、web、DNS、电子邮件、VPN等）。
The above is not intended to be a comprehensive list of all the possible usage cases, just an overview. In fact, combinations of the above usages are also possible, along with situations where the same CE is used at different times in different scenarios or even with different IPv4aaSes at different service providers.
以上内容并不是所有可能的用例的综合列表，只是一个概述。事实上，上述用途的组合也是可能的，在不同的场景中，在不同的时间使用相同的CE，甚至在不同的服务提供商使用不同的IPV4aaSE。
The mechanisms for allowing inbound connections are naturally available in any IPv6 router when using IPv6 Global Unicast Addresses (GUAs), unless they are blocked by firewall rules, which may require some manual configuration.
当使用IPv6全局单播地址（GUA）时，允许入站连接的机制在任何IPv6路由器中都自然可用，除非它们被防火墙规则阻止，这可能需要一些手动配置。
However, in the case of IPv4aaS, because of the usage of private IPv4 addresses and NAT and depending on the specific transition mechanism, inbound connections typically require some degree of more complex manual configuration, such as setting up a DMZ, setting up virtual servers, or setting up port/protocol forwarding. In general, IPv4 CE Routers already provide a GUI, CLI, or API to manually configure them, or provide the possibility to set up the CE in bridge mode, so another Router behind the original CE, takes care of inbound connections. The requirements for that support are out of the scope of this document.
但是，在IPv4aaS的情况下，由于使用专用IPv4地址和NAT，并且取决于特定的转换机制，入站连接通常需要某种程度的更复杂的手动配置，例如设置DMZ、设置虚拟服务器或设置端口/协议转发。通常，IPv4 CE路由器已经提供了GUI、CLI或API来手动配置它们，或者提供了在桥接模式下设置CE的可能性，因此原始CE后面的另一个路由器负责入站连接。该支持的要求不在本文件的范围内。
Who provides the IPv6 Transition CE Router is not relevant. In most cases, the service provider is responsible for provisioning/managing, at least on the WAN side. Commonly, the user has access to configure the LAN interfaces, firewall, DMZ, and many other features. However, in many cases, the user must supply or may replace the IPv6 Transition CE Router. This underscores the importance of the IPv6 Transition CE Routers fulfilling the requirements defined in this document.
谁提供IPv6转换CE路由器与此无关。在大多数情况下，服务提供商负责供应/管理，至少在WAN端。通常，用户可以配置LAN接口、防火墙、DMZ和许多其他功能。然而，在许多情况下，用户必须提供或可能更换IPv6转换CE路由器。这强调了IPv6转换CE路由器满足本文档中定义的要求的重要性。
The IPv6 Transition CE Router described in this document is not intended for usage in other scenarios, such as large enterprises, data centers, content providers, etc. Even if the documented requirements meet their needs, they may have additional requirements, which are out of the scope of this document.
本文档中描述的IPv6 Transition CE路由器不适用于其他场景，如大型企业、数据中心、内容提供商等。即使记录的需求满足他们的需求，他们也可能有额外的需求，这超出了本文档的范围。
An end-user network will likely support both IPv4 and IPv6 (see Section 1 and Appendix A). It is not expected that end users will change their existing network topology with the introduction of IPv6. There are some differences in how IPv6 works and is provisioned; these differences have implications for the network architecture.
最终用户网络可能同时支持IPv4和IPv6（见第1节和附录A）。预计最终用户不会随着IPv6的引入而改变其现有的网络拓扑。IPv6的工作方式和配置方式存在一些差异；这些差异对网络体系结构有影响。
A typical IPv4 end-user network consists of a "plug and play" router with NAT functionality and a single link upstream, connected to the service provider network.
典型的IPv4最终用户网络由一个具有NAT功能的“即插即用”路由器和一条连接到服务提供商网络的上行链路组成。
From the perspective of an IPv4 user behind an IPv6 Transition CE Router, this doesn't change.
从IPv6转换CE路由器后面的IPv4用户的角度来看，这并没有改变。
However, while a typical IPv4 NAT deployment, by default, blocks all incoming connections and may allow opening of ports using a Universal Plug and Play Internet Gateway Device (UPnP IGD) [UPnP-IGD][OCF-IGD] or some other firewall control protocol, in the case of an IPv6-only access and IPv4aaS, that may not be feasible depending on specific transition mechanism details. PCP [RFC6887] may be an alternative solution.
然而，虽然典型的IPv4 NAT部署在默认情况下会阻止所有传入连接，并允许使用通用即插即用互联网网关设备（UPnP IGD）[UPnP IGD][OCF-IGD]或某些其他防火墙控制协议打开端口，但在仅IPv6访问和IPv4aaS的情况下，根据具体的过渡机制细节，这可能不可行。PCP[RFC6887]可能是一种替代解决方案。
Another consequence of using IPv4 private address space in the end-user network is that it provides stable addressing; that is, it doesn't change, even when you change service providers, and the addresses are always usable even when the WAN interface is down or the customer edge router has not yet been provisioned. In the case of IPv6-only access, private IPv4 addresses are also available if the IPv4aaS transition mechanism keeps running the NAT interface towards the LAN side when the WAN interface is down.
在最终用户网络中使用IPv4专用地址空间的另一个结果是，它提供了稳定的寻址；也就是说，即使您更改了服务提供商，地址也不会更改，并且即使WAN接口关闭或尚未配置客户边缘路由器，地址也始终可用。在仅IPv6访问的情况下，如果在WAN接口关闭时IPv4aaS转换机制继续向LAN侧运行NAT接口，则也可以使用专用IPv4地址。
More advanced routers support dynamic routing (which learns routes from other routers), and advanced end users can build arbitrary, complex networks using manual configuration of address prefixes combined with a dynamic routing protocol. Once again, this is true for both IPv4 and IPv6.
更高级的路由器支持动态路由（从其他路由器学习路由），高级终端用户可以通过手动配置地址前缀并结合动态路由协议来构建任意复杂的网络。同样，IPv4和IPv6都是如此。
In general, the end-user network architecture for IPv6 should provide equivalent or better capabilities and functionality than the current IPv4 architecture.
一般来说，IPv6的最终用户网络体系结构应提供与当前IPv4体系结构相同或更好的功能。
The end-user network is a stub network in the sense that is not providing transit to other external networks. However, HNCP [RFC7788] allows support for automatic provisioning of downstream routers. Figure 2 illustrates the model topology for the end-user network.
最终用户网络是一个存根网络，从某种意义上说，它不提供到其他外部网络的传输。然而，HNCP[RFC7788]允许对下游路由器的自动供应提供支持。图2说明了最终用户网络的模型拓扑。
+---------------+ \
| Service | \
| Provider | \
| Router | | Service
+-------+-------+ | Provider
| IPv6-only | Network
| Customer /
| Internet Connection /
| /
+------+--------+ \
| IPv6 | \
| Transition CE | \
| Router | |
+---+-------+---+ |
Network A | | Network B |
-+----------------+-+- -+---+-------------+- |
| | | | |
+---+------+ | +----+-----+ +-----+----+ |
| IPv6 | | | IPv4 | |IPv4/IPv6 | |
| Host | | | Host | | Host | |
+----------+ | +----------+ +----------+ | End-User
| | Network(s)
+------+--------+ |
| IPv6 | |
| Router | |
+------+--------+ |
Network C | |
-+-------------+--+- |
| | |
+---+------+ +----+-----+ |
| IPv6 | | IPv6 | /
| Host | | Host | /
+----------+ +----------+ /
+---------------+ \
| Service | \
| Provider | \
| Router | | Service
+-------+-------+ | Provider
| IPv6-only | Network
| Customer /
| Internet Connection /
| /
+------+--------+ \
| IPv6 | \
| Transition CE | \
| Router | |
+---+-------+---+ |
Network A | | Network B |
-+----------------+-+- -+---+-------------+- |
| | | | |
+---+------+ | +----+-----+ +-----+----+ |
| IPv6 | | | IPv4 | |IPv4/IPv6 | |
| Host | | | Host | | Host | |
+----------+ | +----------+ +----------+ | End-User
| | Network(s)
+------+--------+ |
| IPv6 | |
| Router | |
+------+--------+ |
Network C | |
-+-------------+--+- |
| | |
+---+------+ +----+-----+ |
| IPv6 | | IPv6 | /
| Host | | Host | /
+----------+ +----------+ /
Figure 2: Example of a Typical End-User Network
图2：典型终端用户网络示例
This architecture describes the:
该体系结构描述了：
o Basic capabilities of the IPv6 Transition CE Router
o IPv6过渡CE路由器的基本功能
o Provisioning of the WAN interface connecting to the service provider
o 提供连接到服务提供商的WAN接口
o Provisioning of the LAN interfaces
o 局域网接口的供应
The IPv6 Transition CE Router may be manually configured in an arbitrary topology with a dynamic routing protocol or HNCP [RFC7788]. Automatic provisioning and configuration are described for a single IPv6 Transition CE Router only.
IPv6转换CE路由器可以在具有动态路由协议或HNCP[RFC7788]的任意拓扑中手动配置。仅针对单个IPv6转换CE路由器描述了自动资源调配和配置。
Acknowledgements
致谢
Thanks to Mikael Abrahamsson, Fred Baker, Mohamed Boucadair, Brian Carpenter, Lorenzo Colitti, Alejandro D'Egidio, Ian Farrer, Lee Howard, Richard Patterson, Barbara Stark, Ole Troan, and James Woodyatt for their review and comments in this and/or previous draft versions of this document. Thanks also for the Last Call reviews by Dan Romascanu (OPS-DIR); Christian Huitema (SEC-DIR); Daniele Ceccarelli (RTG-DIR); Martin Stiemerling (TSV-ART); Matthew Miller (Gen-ART); and Alissa Cooper, Benjamin Kaduk, Suresh Krishnan, Ben Campbell, Spencer Dawkins, Mirja Kuhlewind, and Adam Roach (all IESG).
感谢Mikael Abrahamsson、Fred Baker、Mohamed Boucadair、Brian Carpenter、Lorenzo Coletti、Alejandro D'Egidio、Ian Farrer、Lee Howard、Richard Patterson、Barbara Stark、Ole Troan和James Woodyatt在本文件和/或之前的草稿版本中的审查和评论。还感谢Dan Romascanu（OPS-DIR）最近的电话评论；克里斯蒂安·惠特马（SEC-DIR）；达涅利·塞卡雷利（RTG-DIR）；马丁·斯蒂梅林（TSV-ART）；马修·米勒（Gen ART）；艾莉莎·库珀、本杰明·卡杜克、苏雷什·克里希南、本·坎贝尔、斯宾塞·道金斯、米莉娅·库莱温德和亚当·罗奇（均为IESG）。
Authors' Addresses
作者地址
Jordi Palet Martinez The IPv6 Company Molino de la Navata, 75 La Navata - Galapagar, Madrid 28420 Spain
Jordi Palet Martinez IPv6公司Molino de la Navata，75 la Navata-加拉帕加尔，马德里28420西班牙
Email: jordi.palet@theipv6company.com
URI: http://www.theipv6company.com/
Email: jordi.palet@theipv6company.com
URI: http://www.theipv6company.com/
Hans M.-H. Liu D-Link Systems, Inc. 17595 Mount Herrmann St. Fountain Valley, California 92708 United States of America
Hans M.-H.Liu D-Link Systems，Inc.17595加利福尼亚州赫尔曼山圣泉谷，邮编：92708
Email: hans.liu@dlinkcorp.com
URI: https://www.dlink.com/
Email: hans.liu@dlinkcorp.com
URI: https://www.dlink.com/
Masanobu Kawashima NEC Platforms, Ltd. 2-3, Kanda-Tsukasamachi Chiyoda-ku, Tokyo 101-8532 Japan
川岛正夫NEC平台有限公司，日本东京千代田町神田町2-3号，101-8532
Email: kawashimam@vx.jp.nec.com
URI: https://www.necplatforms.co.jp/en/
Email: kawashimam@vx.jp.nec.com
URI: https://www.necplatforms.co.jp/en/