Independent Submission V. Kuarsingh, Ed.
Request for Comments: 6732 Rogers Communications
Category: Informational Y. Lee
ISSN: 2070-1721 Comcast
O. Vautrin
Juniper Networks
September 2012
Independent Submission V. Kuarsingh, Ed.
Request for Comments: 6732 Rogers Communications
Category: Informational Y. Lee
ISSN: 2070-1721 Comcast
O. Vautrin
Juniper Networks
September 2012
6to4 Provider Managed Tunnels
6to4提供商管理的隧道
Abstract
摘要
6to4 Provider Managed Tunnels (6to4-PMT) provide a framework that can help manage 6to4 tunnels operating in an anycast configuration. The 6to4-PMT framework is intended to serve as an option for operators to help improve the experience of 6to4 operation when conditions of the network may provide sub-optimal performance or break normal 6to4 operation. 6to4-PMT supplies a stable provider prefix and forwarding environment by utilizing existing 6to4 relays with an added function of IPv6 Prefix Translation. This operation may be particularly important in NAT444 infrastructures where a customer endpoint may be assigned a non-RFC1918 address, thus breaking the return path for anycast-based 6to4 operation. 6to4-PMT has been successfully used in a production network, implemented as open source code, and implemented by a major routing vendor.
6to4提供商管理的隧道（6to4 PMT）提供了一个框架，可以帮助管理在选播配置中运行的6to4隧道。当网络条件可能提供次优性能或破坏正常的6to4操作时，6to4 PMT框架旨在作为运营商的一个选项，以帮助改善6to4操作的体验。6to4-PMT利用现有的6to4中继提供了稳定的提供商前缀和转发环境，并增加了IPv6前缀转换功能。在NAT444基础设施中，此操作可能特别重要，在NAT444基础设施中，可以为客户端点分配非RFC1918地址，从而中断基于选播的6to4操作的返回路径。6to4pmt已成功应用于生产网络中，作为开放源代码实现，并由一家主要的路由供应商实现。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6732.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6732.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction ....................................................3
2. Motivation ......................................................3
3. 6to4 Provider Managed Tunnels ...................................5
3.1. 6to4 Provider Managed Tunnel Model .........................5
3.2. Traffic Flow ..............................................5
3.3. Prefix Translation ........................................6
3.4. Translation State .........................................7
4. Deployment Considerations and Requirements ......................7
4.1. Customer Opt-Out ...........................................7
4.2. Shared CGN Space Considerations ............................8
4.3. End-to-End Transparency ....................................8
4.4. Path MTU Discovery Considerations ..........................9
4.5. Checksum Management ........................................9
4.6. Application Layer Gateways .................................9
4.7. Routing Requirements .......................................9
4.8. Relay Deployments .........................................10
5. Security Considerations ........................................10
6. Acknowledgements ...............................................10
7. References .....................................................11
7.1. Normative References ......................................11
7.2. Informative References ....................................11
1. Introduction ....................................................3
2. Motivation ......................................................3
3. 6to4 Provider Managed Tunnels ...................................5
3.1. 6to4 Provider Managed Tunnel Model .........................5
3.2. Traffic Flow ..............................................5
3.3. Prefix Translation ........................................6
3.4. Translation State .........................................7
4. Deployment Considerations and Requirements ......................7
4.1. Customer Opt-Out ...........................................7
4.2. Shared CGN Space Considerations ............................8
4.3. End-to-End Transparency ....................................8
4.4. Path MTU Discovery Considerations ..........................9
4.5. Checksum Management ........................................9
4.6. Application Layer Gateways .................................9
4.7. Routing Requirements .......................................9
4.8. Relay Deployments .........................................10
5. Security Considerations ........................................10
6. Acknowledgements ...............................................10
7. References .....................................................11
7.1. Normative References ......................................11
7.2. Informative References ....................................11
6to4 [RFC3056] tunneling, along with the anycast operation described in [RFC3068], is widely deployed in modern Operating Systems and off-the-shelf gateways sold throughout retail and Original Equipment Manufacturer (OEM) channels. Anycast-based 6to4 [RFC3068] allows for tunneled IPv6 connectivity through IPv4 clouds without explicit configuration of a relay address. Since the overall system utilizes anycast forwarding in both directions, flow paths are difficult to determine, tend to follow separate paths in either direction, and often change based on network conditions. The return path is normally uncontrolled by the local operator and can contribute to poor performance for IPv6 and can also act as a breakage point. Many of the challenges with 6to4 are described in [RFC6343]. A specific critical use case for problematic anycast 6to4 operation is related to conditions in which the consumer endpoints are downstream from a northbound Carrier-Grade NAT (CGN) [RFC6264] function when assigned non-RFC1918 IPv4 addresses, which are not routed on interdomain links.
6to4[RFC3056]隧道以及[RFC3068]中所述的选播操作，广泛部署在现代操作系统和零售和原始设备制造商（OEM）渠道销售的现成网关中。基于选播的6to4[RFC3068]允许通过IPv4云进行隧道式IPv6连接，而无需明确配置中继地址。由于整个系统在两个方向上都使用选播转发，因此流路径很难确定，倾向于在任一方向上遵循单独的路径，并且经常根据网络条件而改变。返回路径通常不受本地运营商控制，可能导致IPv6性能低下，也可能成为断点。[RFC6343]中描述了6to4的许多挑战。有问题的选播6to4操作的一个特定关键用例与以下条件有关：当分配非RFC1918 IPv4地址时，用户端点位于北行运营商级NAT（CGN）[RFC6264]功能的下游，该地址不在域间链路上路由。
Operators that are actively deploying IPv6 networks and operate legacy IPv4 access environments may want to utilize the existing 6to4 behavior in customer site resident hardware and software as an interim option to reach the IPv6 Internet in advance of being able to offer full native IPv6. Operators may also need to address the brokenness related to 6to4 operation originating from behind a provider NAT function. 6to4-PMT offers an operator the opportunity to utilize IPv6 Prefix Translation to enable deterministic traffic flow and an unbroken path to and from the Internet for IPv6-based traffic sourced originally from these 6to4 customer endpoints.
积极部署IPv6网络并运行旧式IPv4访问环境的运营商可能希望利用客户站点驻留硬件和软件中现有的6to4行为作为临时选项，以便在能够提供完整的本机IPv6之前到达IPv6 Internet。运营商可能还需要解决与从提供者NAT函数后面发起的6to4操作相关的中断问题。6to4 PMT为运营商提供了利用IPv6前缀转换的机会，以实现确定性的流量流，并为最初来自这些6to4客户端点的基于IPv6的流量提供一条不间断的进出互联网的路径。
6to4-PMT translates the prefix portion of the IPv6 address from the 6to4-generated prefix to a provider-assigned prefix that is used to represent the source. This translation will then provide a stable forward and return path for the 6to4 traffic by allowing the existing IPv6 routing and policy environment to control the traffic. 6to4-PMT is primarily intended to be used in a stateless manner to maintain many of the elements inherent in normal 6to4 operation. Alternatively, 6to4-PMT can be used in a stateful translation mode should the operator choose this option.
6to4 PMT将IPv6地址的前缀部分从6to4生成的前缀转换为提供商分配的前缀，该前缀用于表示源。通过允许现有IPv6路由和策略环境控制流量，此转换将为6to4流量提供稳定的前向和返回路径。6to4 PMT主要用于无状态方式，以维护正常6to4操作中固有的许多元素。或者，如果操作员选择此选项，可以在有状态转换模式下使用6to4 PMT。
Many operators endeavor to deploy IPv6 as soon as possible so as to ensure uninterrupted connectivity to all Internet applications and content through the IPv4 to IPv6 transition process. The IPv6 preparations within these organizations are often faced with both financial challenges and timing issues related to deploying IPv6 to
许多运营商努力尽快部署IPv6，以确保通过IPv4到IPv6的过渡过程不间断地连接到所有互联网应用程序和内容。这些组织内部的IPv6准备工作通常面临着与将IPv6部署到服务器相关的财务挑战和时间问题
the network edge and related transition technologies. Many of the new technologies available for IPv4 to IPv6 transition will require the replacement of the organization's Customer Premises Equipment (CPE) to support technologies like IPv6 Rapid Deployment (6RD) [RFC5969], Dual-Stack Lite [RFC6333], and native dual-stack.
网络边缘及相关过渡技术。许多可用于IPv4到IPv6过渡的新技术将需要更换公司的客户场所设备（CPE），以支持IPv6快速部署（6RD）[RFC5969]、双栈Lite[RFC6333]和本机双栈等技术。
Operators face a number of challenges related to home equipment replacement. Operator-initiated replacement of this equipment will take time due to the nature of mass equipment refresh programs or may require the consumer to replace their own gear. Replacing consumer owned and operated equipment, compounded by the fact that there is also a general unawareness of what IPv6 is, also adds to the challenges faced by operators. It is also important to note that 6to4 is present in much of the equipment found in networks today that do not as of yet, or will not, support 6RD and/or native IPv6.
运营商面临许多与家用设备更换相关的挑战。由于大规模设备更新计划的性质，操作员主动更换此设备需要时间，或者可能需要消费者更换自己的齿轮。更换消费者拥有和操作的设备，再加上人们普遍不了解IPv6是什么，也增加了运营商面临的挑战。还需要注意的是，目前网络中的许多设备中都存在6to4，这些设备目前还不支持或将不支持6RD和/或本机IPv6。
Operators may still be motivated to provide a form of IPv6 connectivity to customers and would want to mitigate potential issues related to IPv6-only deployments elsewhere on the Internet. Operators also need to mitigate issues related to the fact that 6to4 operation is often on by default, and may be subject to erroneous behavior. The undesired behavior may be related to the use of non-RFC1918 addresses on CPE equipment that operate behind large operator NATs or other conditions as described in a general advisory as laid out in [RFC6343].
运营商可能仍然希望向客户提供一种形式的IPv6连接，并希望缓解与互联网上其他地方仅部署IPv6相关的潜在问题。操作员还需要缓解与以下事实相关的问题：6to4操作通常在默认情况下处于开启状态，并且可能会出现错误行为。不希望出现的行为可能与在CPE设备上使用非RFC1918地址有关，这些地址在大型运营商NAT或[RFC6343]中规定的一般咨询中所述的其他条件下运行。
6to4-PMT allows an operator to help mitigate such challenges by leveraging the existing 6to4 deployment base, while maintaining operator control of access to the IPv6 Internet. It is intended for use when better options, such as 6RD or native IPv6, are not yet viable. One of the key objectives of 6to4-PMT is to also help reverse the negative impacts of 6to4 in CGN environments. The 6to4-PMT operation can also be used immediately with the default parameters that are often enough to allow it to operate in a 6to4-PMT environment. Once native IPv6 is available to the endpoint, the 6to4-PMT operation is no longer needed and will cease to be used based on correct address selection behaviors in end hosts [RFC6724].
6to4 PMT允许运营商利用现有的6to4部署基础帮助缓解此类挑战，同时保持运营商对IPv6互联网访问的控制。它的目的是在更好的选项（如第6条或本机IPv6）尚不可行时使用。6to4 PMT的关键目标之一是帮助扭转6to4在CGN环境中的负面影响。6to4 PMT操作也可以立即与默认参数一起使用，这些参数通常足以使其在6to4 PMT环境中运行。一旦终端可以使用本机IPv6，就不再需要6to4 PMT操作，并且将根据终端主机中正确的地址选择行为停止使用[RFC6724]。
6to4-PMT thus helps operators remove the impact of 6to4 in CGN environments, deals with the fact that 6to4 is often on by default, and allows access to IPv6-only endpoints from IPv4-only addressed equipment. Additionally, it provides relief from many challenges related to mis-configurations in other networks that control return flows via foreign relays. Due to the simple nature of 6to4-PMT, it can also be implemented in a cost-effective and simple manner, allowing operators to concentrate their energy on deploying native IPv6.
因此，6to4 PMT可以帮助运营商消除6to4在CGN环境中的影响，解决6to4在默认情况下通常处于启用状态的问题，并允许从仅IPv4寻址的设备访问仅IPv6的端点。此外，它还减轻了与通过外部继电器控制回流的其他网络中的错误配置相关的许多挑战。由于6to4 PMT的简单特性，它还可以以经济高效且简单的方式实施，使运营商能够集中精力部署本机IPv6。
The 6to4 managed tunnel model behaves like a standard 6to4 service between the customer IPv6 host or gateway, and the 6to4-PMT Relay (within the provider domain). The 6to4-PMT Relay shares properties with 6RD [RFC5969] by decapsulating and forwarding encapsulated IPv6 flows within an IPv4 packet to the IPv6 Internet. The model provides an additional function that translates the source 6to4 prefix to a provider-assigned prefix that is not found in 6RD [RFC5969] or traditional 6to4 operation.
6to4托管隧道模型的行为类似于客户IPv6主机或网关与6to4 PMT中继（在提供商域内）之间的标准6to4服务。6to4 PMT中继通过解除IPv4数据包内封装的IPv6流的封装并将其转发到IPv6 Internet，与6RD[RFC5969]共享属性。该模型提供了一个附加功能，将源6to4前缀转换为在6RD[RFC5969]或传统6to4操作中找不到的提供者分配的前缀。
The 6to4-PMT Relay is intended to provide a stateless (or stateful) mapping of the 6to4 prefix to a provider supplied prefix.
6to4 PMT中继旨在提供6to4前缀到提供者提供的前缀的无状态（或有状态）映射。
| 6to4-PMT Operation |
|6to4 PMT操作|
+-----+ 6to4 Tunnel +--------+ +------+ IPv6 +----+
| CPE |-------------|6to4 BR |--| PT66 |--------- |Host|
+-----+ IPv4 +--------+ +------+ Provider +----+
Network Prefix
Unified or Separate
Functions/Platforms
+-----+ 6to4 Tunnel +--------+ +------+ IPv6 +----+
| CPE |-------------|6to4 BR |--| PT66 |--------- |Host|
+-----+ IPv4 +--------+ +------+ Provider +----+
Network Prefix
Unified or Separate
Functions/Platforms
Figure 1: 6to4-PMT Functional Model
图1:6to4 PMT功能模型
This mode of operation is seen as beneficial when compared to broken 6to4 paths and/or environments where 6to4 operation may be functional but highly degraded.
与中断的6to4路径和/或6to4操作可能正常但高度降级的环境相比，这种操作模式被视为是有益的。
Traffic in the 6to4-PMT model is intended to be controlled by the operator's IPv6 peering operations. Egress traffic is managed through outgoing routing policy, and incoming traffic is influenced by the operator-assigned prefix advertisements using normal interdormain routing functions.
6to4 PMT模型中的流量旨在由运营商的IPv6对等操作控制。出站流量通过出站路由策略进行管理，入站流量受操作员分配的前缀播发的影响，该播发使用正常的内部路由功能。
The routing model is as predictable as native IPv6 traffic and legacy IPv4-based traffic. Figure 2 provides a view of the routing topology needed to support this relay environment. The diagram references PrefixA as 2002::/16 and PrefixB as the example 2001:db8::/32.
路由模型与本机IPv6流量和传统的基于IPv4的流量一样可预测。图2提供了支持此中继环境所需的路由拓扑视图。该图将前缀引用为2002:：/16，将前缀xb引用为示例2001:db8:：/32。
| 6to4 IPv4 Path | Native IPv6 Path |
----------- ----------- -------------
/ IPv4 Net \ / IPv6 Net \ / IPv6 Internet \
+------+ +--------+ +-------+ +---------+
| CPE | PrefixA |6to4-PMT| PrefixB |Peering| |IPv6 HOST|
+------+ +--------+ +-------+ +---------+
\ / \ / \ /
---------- ------------ --------------
| 6to4 IPv4 Path | Native IPv6 Path |
----------- ----------- -------------
/ IPv4 Net \ / IPv6 Net \ / IPv6 Internet \
+------+ +--------+ +-------+ +---------+
| CPE | PrefixA |6to4-PMT| PrefixB |Peering| |IPv6 HOST|
+------+ +--------+ +-------+ +---------+
\ / \ / \ /
---------- ------------ --------------
IPv4 6to4 IPv6 Provider IPv6 Prefix Anycast Prefix Propagation
IPv4 6to4 IPv6提供程序IPv6前缀选播前缀传播
Figure 2: 6to4-PMT Flow Model
图2:6to4 PMT流量模型
Traffic between two 6to4-enabled devices would use the IPv4 path for communication according to [RFC3056] unless the local host still prefers traffic via a relay. 6to4-PMT is intended to be deployed in conjunction with the 6to4 relay function in an attempt to help simplify its deployment. The model can also provide the ability for an operator to forward both 6to4-PMT (translated) and normal 6to4 flows (untranslated) simultaneously based on configured policy.
根据[RFC3056]，两个支持6to4的设备之间的通信将使用IPv4路径进行通信，除非本地主机仍然喜欢通过中继进行通信。6to4 PMT计划与6to4中继功能一起部署，以帮助简化其部署。该模型还可以为运营商提供根据配置的策略同时转发6to4 PMT（已翻译）和正常6to4流（未翻译）的能力。
IPv6 Prefix Translation is a key part of the system as a whole. The 6to4-PMT framework is a combination of two concepts: 6to4 [RFC3056] and IPv6 Prefix Translation. IPv6 Prefix Translation, as used in 6to4-PMT, has some similarities to concepts discussed in [RFC6296]. 6to4-PMT would provide prefix translation based on specific rules configured on the translator that maps the 6to4 2002::/16 prefix to an appropriate provider assigned prefix. In most cases, a ::/32 prefix would work best in 6to4-PMT that matches common Regional Internet Registry (RIR) prefix assignments to operators.
IPv6前缀转换是整个系统的关键部分。6to4pmt框架是两个概念的组合：6to4[RFC3056]和IPv6前缀转换。在6to4 PMT中使用的IPv6前缀转换与[RFC6296]中讨论的概念有一些相似之处。6to4 PMT将根据转换器上配置的特定规则提供前缀转换，该转换器将6to4 2002:：/16前缀映射到适当的提供者分配的前缀。在大多数情况下，一个：：/32前缀在6to4 PMT中最有效，该PMT与操作员的通用区域互联网注册（RIR）前缀分配相匹配。
The provider can use any prefix mapping strategy they so choose, but the simpler the better. Simple direct bitmapping can be used, or more advanced forms of translation should the operator want to achieve higher address compression. More advanced forms of translation may require the use of stateful translation.
提供者可以使用他们选择的任何前缀映射策略，但越简单越好。如果操作员希望实现更高的地址压缩，可以使用简单的直接位映射，也可以使用更高级的转换形式。更高级的翻译形式可能需要使用有状态的翻译。
Figure 3 shows a 6to4 Prefix with a Subnet-ID of "0000" mapped to a provider-assigned, globally unique prefix (2001:db8::/32). With this simple form of translation, there is support for only one Subnet-ID per provider-assigned prefix. In characterization of deployed OSs and gateways, a Subnet-ID of "0000" is the most common default case followed by Subnet-ID "0001". Use of the Subnet-ID can be referenced in [RFC4291]. It should be noted that in normal 6to4 operation, the endpoint (network) has access to 65,536 (16-bits) Subnet IDs. In the
图3显示了子网ID为“0000”的6to4前缀，该前缀映射到提供者分配的全局唯一前缀（2001:db8:：/32）。通过这种简单的转换形式，每个提供者分配的前缀只支持一个子网ID。在已部署的OSs和网关的特征描述中，子网ID“0000”是最常见的默认情况，其次是子网ID“0001”。子网ID的使用可参考[RFC4291]。应该注意的是，在正常的6to4操作中，端点（网络）可以访问65536（16位）子网ID。在
6to4-PMT case as described above using the mapping in Figure 3, all but the one Subnet-ID used for 6to4-PMT would still operate under normal 6to4 operation.
6to4 PMT情况如上所述，使用图3中的映射，除了用于6to4 PMT的一个子网ID之外，所有子网ID都将在正常的6to4操作下运行。
Pre-Relayed Packet [Provider Access Network Side]
预中继数据包[提供商接入网侧]
0 16 32 48 64 80 96 112 128 Bits
| ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- |
2002 : 0C98 : 2C01 : 0000 : xxxx : xxxx : xxxx : xxxx
| ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- |
| | | | | |
---- ---- | | | |
| | | | | |
| ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- |
2001 : 0db8 : 0c98 : 2c01 : xxxx : xxxx : xxxx : xxxx
| ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- |
0 16 32 48 64 80 96 112 128 Bits
| ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- |
2002 : 0C98 : 2C01 : 0000 : xxxx : xxxx : xxxx : xxxx
| ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- |
| | | | | |
---- ---- | | | |
| | | | | |
| ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- |
2001 : 0db8 : 0c98 : 2c01 : xxxx : xxxx : xxxx : xxxx
| ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- |
Post-Relayed Packet [Internet Side]
中继后数据包[互联网端]
Figure 3: 6to4-PMT Prefix Mapping
图3:6to4 PMT前缀映射
It is preferred that the overall system use deterministic prefix translation mappings such that stateless operation can be implemented. This allows the provider to place N number of relays within the network without the need to manage translation state. Deterministic translation also allows a customer to employ inward services using the translated (provider prefix) address.
优选的是，整个系统使用确定性前缀转换映射，以便可以实现无状态操作。这允许提供商在网络中放置N个中继，而无需管理转换状态。确定性翻译还允许客户使用翻译后的（提供者前缀）地址使用内部服务。
If stateful operation is chosen, the operator would need to validate state and routing requirements particular to that type of deployment. The full body of considerations for this type of deployment is not within this scope of this document.
如果选择有状态操作，操作员将需要验证特定于该类型部署的状态和路由要求。此类部署的全部注意事项不在本文档的范围内。
A provider enabling this function should offer a method to allow customers to opt-out of such a service should the customer choose to maintain normal 6to4 operation irrespective of degraded performance. In cases where the customer is behind a CGN device, the customer would not be advised to opt-out and can be assisted in turning off 6to4.
启用此功能的提供商应提供一种方法，允许客户选择退出此类服务，前提是客户选择维持正常的6to4操作，而不考虑性能下降。如果客户使用CGN设备，则不会建议客户选择退出，可以帮助客户关闭6to4。
Since the 6to4-PMT system is targeted at customers who are relatively unaware of IPv6 and IPv4, and normally run network equipment with a default configuration, an opt-out strategy is recommended. This method provides 6to4-PMT operation for non-IPv6 savvy customers whose equipment may turn on 6to4 automatically and allows savvy customers to easily configure their way around the 6to4-PMT function.
由于6to4 PMT系统的目标客户相对不了解IPv6和IPv4，并且通常使用默认配置运行网络设备，因此建议采用选择退出策略。此方法为不熟悉IPv6的客户提供6to4 PMT操作，这些客户的设备可能会自动打开6to4，并允许熟悉6to4 PMT功能的客户轻松配置他们的方式。
Capable customers can also disable anycast-based 6to4 entirely and use traditional 6to4 or other tunneling mechanisms if they are so inclined. This is not considered the normal case, and most endpoints with auto-6to4 functions will be subject to 6to4-PMT operation since most users are unaware of its existence. 6to4-PMT is targeted as an option for stable IPv6 connectivity for average consumers.
有能力的客户还可以完全禁用基于选播的6to4，并使用传统的6to4或其他隧道机制（如果他们愿意的话）。这不是正常情况，大多数具有auto-6to4功能的端点都将接受6to4 PMT操作，因为大多数用户不知道它的存在。6to4 PMT的目标是为普通消费者提供稳定的IPv6连接选项。
6to4-PMT operation can also be used to mitigate a known problem with 6to4 occurring when shared address space [RFC6598] or Global Unicast Addresses (GUA) are used behind a CGN and not routed on the Internet. Non-RFC1918, yet unrouted (on interdomain links) address space would cause many deployed OSs and network equipment to potentially auto-enable 6to4 operation even without a valid return path (such as behind a CGN function). The operator's desire to use non-RFC1918 addresses, such as shared address space [RFC6598], is considered highly likely based on real world deployments.
6to4 PMT操作还可用于缓解当在CGN后面使用共享地址空间[RFC6598]或全局单播地址（GUA）且未在因特网上路由时发生的6to4的已知问题。非RFC1918但未路由（在域间链路上）的地址空间将导致许多已部署的操作系统和网络设备可能自动启用6to4操作，即使没有有效的返回路径（例如CGN函数后面）。运营商希望使用非RFC1918地址（如共享地址空间[RFC6598]）的可能性很大，这取决于实际部署情况。
Such hosts, in normal cases, would send 6to4 traffic to the IPv6 Internet via the anycast relay, which would in fact provide broken IPv6 connectivity, since the return path flow is built using an IPv4 address that is not routed or assigned to the source network. The use of 6to4-PMT would help reverse these effects by translating the 6to4 prefix to a provider-assigned prefix, masking this automatic and undesired behavior.
在正常情况下，此类主机将通过选播中继向IPv6 Internet发送6to4通信量，这实际上将提供中断的IPv6连接，因为返回路径流是使用未路由或分配给源网络的IPv4地址构建的。通过将6to4前缀转换为提供者指定的前缀，使用6to4 PMT将有助于扭转这些影响，从而掩盖这种自动和不希望出现的行为。
The 6to4-PMT mode of operation removes the traditional end-to-end transparency of 6to4. Remote hosts would connect to a 6to4-PMT-serviced host using a translated IPv6 address versus the original 6to4 address based on the 2002::/16 well-known prefix. This can be seen as a disadvantage of the 6to4-PMT system. This lack of transparency should also be contrasted with the normal operating state of 6to4 that provides connectivity that is uncontrolled and often prone to high latency. The lack of transparency is, however, a better form of operation when extreme poor performance, broken IPv6 connectivity, or no IPv6 connectivity is considered as the alternative.
6to4 PMT操作模式消除了6to4的传统端到端透明性。远程主机将使用转换后的IPv6地址连接到6to4 PMT服务主机，而不是基于2002:：/16众所周知的前缀的原始6to4地址。这可以看作是6to4 PMT系统的一个缺点。这种缺乏透明度的情况也应该与6to4的正常运行状态形成对比，6to4提供的连接不受控制，并且通常容易出现高延迟。然而，当性能极差、IPv6连接中断或没有IPv6连接被视为替代方案时，缺乏透明度是一种更好的操作形式。
The MTU will be subject to a reduced value due to standard 6to4 tunneling operation. Under normal 6to4 operation, the 6to4 service agent would send an ICMP Packet Too Big Message as part of Path MTU discovery as described in [RFC4443] and [RFC1981], respectively. In 6to4-PMT operation, the PMT Service agent should be aware of the reduced 6to4 MTU and send ICMP messages using the translated address accordingly.
由于标准6to4隧道作业，MTU的值将降低。在正常的6to4操作下，6to4服务代理将发送ICMP数据包过大消息，作为路径MTU发现的一部分，分别如[RFC4443]和[RFC1981]所述。在6to4 PMT操作中，PMT服务代理应该知道减少的6to4 MTU，并相应地使用翻译后的地址发送ICMP消息。
It is also possible to pre-constrain the MTU at the upstream router from the 6to4-PMT service agents that would then have the upstream router send the appropriate ICMP Packet Too Big Messages.
还可以从6to4 PMT服务代理预先约束上游路由器上的MTU，然后让上游路由器发送适当的ICMP数据包过大消息。
Checksum management for 6to4-PMT can be implemented in one of two ways. The first deployment model is based on the stateless 6to4-PMT operational mode. In this case, checksum modifications are made using the method described in [RFC3022], Section 4.2. The checksum is modified to match the parameters of the translated address of the source 6to4-PMT host. In the second deployment model in which stateful 6to4-PMT translation is used, the vendor can implement checksum-neutral mappings as defined in [RFC6296].
6to4 PMT的校验和管理可以通过以下两种方式之一实现。第一种部署模型基于无状态6to4 PMT操作模式。在这种情况下，使用[RFC3022]第4.2节中描述的方法进行校验和修改。修改校验和以匹配源6to4 PMT主机的转换地址的参数。在使用有状态6to4 PMT转换的第二个部署模型中，供应商可以实现[RFC6296]中定义的校验和中性映射。
Vendors can choose to deploy Application Layer Gateways (ALGs) on their platforms that perform 6to4-PMT if they so choose. No ALGs were deployed as part of the open source and vendor product deployments of 6to4-PMT. In the vendor deployment case, the same rules were used as with their NPTv6 [RFC6296] base code.
供应商可以选择在执行6to4 PMT的平台上部署应用层网关（ALG），如果他们愿意的话。在6to4 PMT的开源和供应商产品部署中，没有部署ALG。在供应商部署案例中，使用了与NPTv6[RFC6296]基本代码相同的规则。
The provider would need to advertise the well-known IP address range used for normal anycast 6to4 [RFC3068] operation within the local IPv4 routing environment. This advertisement would attract the 6to4 upstream traffic to a local relay. To control this environment and make sure all northbound traffic lands on a provider-controlled relay, the operator may filter the anycast range from being advertised from customer endpoints toward the local network (upstream propagation).
提供商需要在本地IPv4路由环境中公布用于正常选播6to4[RFC3068]操作的众所周知的IP地址范围。该广告将吸引6to4上游流量到本地中继。为了控制该环境并确保所有北行通信量都落在提供商控制的中继上，运营商可以过滤从客户端点向本地网络（上游传播）播发的选播范围。
The provider would not be able to control route advertisements inside the customer domain, but that use case is not in scope for this document. In that case, it is likely that the end network/customer understands 6to4 and is maintaining their own relay environment and
提供商将无法控制客户域内的路由广告，但该用例不在本文档的范围内。在这种情况下，终端网络/客户很可能理解6to4，并且正在维护自己的中继环境和服务
therefore would not be subject to the operators 6to4 and/or PMT operation.
因此，不会受到操作员6to4和/或PMT操作的影响。
Within their own network, the provider would also likely want to advertise the 2002::/16 range to help bridge traditional 6to4 traffic within the network (native IPv6 to 6to4-PMT-based endpoint). It would also be advised that the local 6to4-PMT operator not leak the well-known 6to4 anycast IPv4 prefix to neighboring Autonomous Systems to prevent PMT operation for neighboring networks. Policy configuration on the local 6to4-PMT Relay can also be used to disallow PMT operation should the local provider service downstream customer networks.
在他们自己的网络中，提供商可能还希望宣传2002:：/16范围，以帮助桥接网络中的传统6to4流量（基于本机IPv6到6to4 PMT的端点）。还建议本地6to4 PMT运营商不要将众所周知的6to4选播IPv4前缀泄漏给相邻的自治系统，以防止相邻网络的PMT操作。如果本地提供商为下游客户网络提供服务，本地6to4 PMT中继上的策略配置也可用于禁止PMT操作。
The 6to4-PMT function can be deployed onto existing 6to4 relays (if desired) to help minimize network complexity and cost. 6to4-PMT has already been developed on Linux-based platforms that are package add-ons to the traditional 6to4 code. The only additional considerations beyond normal 6to4 relay operation would include the need to route specific IPv6 provider prefix ranges used for 6to4-PMT operation towards peers and transit providers.
6to4 PMT功能可以部署到现有的6to4中继上（如果需要），以帮助最小化网络复杂性和成本。6to4pmt已经在基于Linux的平台上开发，这些平台是传统6to4代码的附加包。除了正常的6to4中继操作之外，唯一的额外考虑事项包括需要将用于6to4 PMT操作的特定IPv6提供商前缀范围路由到对等方和传输提供商。
6to4-PMT operation would be subject to the same security concerns as normal 6to4 operation as described in [RFC6169]. 6to4-PMT is also not plainly perceptible by external hosts, and local entities appear as native IPv6 hosts to the external hosts.
如[RFC6169]所述，6to4 PMT操作将受到与正常6to4操作相同的安全问题的影响。6to4 PMT也不能被外部主机清楚地感知到，并且本地实体在外部主机上显示为本机IPv6主机。
Thanks to the following people for their textual contributions and/or guidance on 6to4 deployment considerations: Dan Wing, Wes George, Scott Beuker, JF Tremblay, John Brzozowski, Chris Metz, and Chris Donley.
感谢以下人员对6to4部署注意事项的文字贡献和/或指导：Dan Wing、Wes George、Scott Beuker、JF Tremblay、John Brzowski、Chris Metz和Chris Donley。
Additional thanks to the following for assisting with the coding and testing of 6to4-PMT: Marc Blanchet, John Cianfarani, Tom Jefferd, Nik Lavorato, Robert Hutcheon, and Ida Leung.
另外感谢以下协助编写和测试6to4 PMT的人员：Marc Blanchet、John Cianfarani、Tom Jefferd、Nik Lavorato、Robert Hutcheon和Ida Leung。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056]Carpenter，B.和K.Moore，“通过IPv4云连接IPv6域”，RFC 3056，2001年2月。
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001.
[RFC3068]Huitema，C.，“6to4中继路由器的选播前缀”，RFC3068，2001年6月。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981]McCann，J.，Deering，S.，和J.Mogul，“IP版本6的路径MTU发现”，RFC 1981，1996年8月。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[RFC3022]Srisuresh，P.和K.Egevang，“传统IP网络地址转换器（传统NAT）”，RFC 3022，2001年1月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443]Conta，A.，Deering，S.，和M.Gupta，Ed.，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，RFC 4443，2006年3月。
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010.
[RFC5969]Townsley，W.和O.Troan，“IPv4基础设施上的IPv6快速部署（第6条）——协议规范”，RFC 5969，2010年8月。
[RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security Concerns with IP Tunneling", RFC 6169, April 2011.
[RFC6169]Krishnan，S.，Thaler，D.，和J.Hoagland，“IP隧道的安全问题”，RFC 61692011年4月。
[RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264, June 2011.
[RFC6264]Jiang，S.，Guo，D.，和B.Carpenter，“IPv6过渡的增量载波级NAT（CGN）”，RFC 62642011年6月。
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix Translation", RFC 6296, June 2011.
[RFC6296]Wasserman，M.和F.Baker，“IPv6到IPv6网络前缀转换”，RFC 62962011年6月。
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011.
[RFC6333]Durand，A.，Droms，R.，Woodyatt，J.，和Y.Lee，“IPv4耗尽后的双栈Lite宽带部署”，RFC 63332011年8月。
[RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", RFC 6343, August 2011.
[RFC6343]Carpenter，B.，“6to4部署咨询指南”，RFC 63432011年8月。
[RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address Space", BCP 153, RFC 6598, April 2012.
[RFC6598]Weil，J.，Kuarsingh，V.，Donley，C.，Liljenstolpe，C.，和M.Azinger，“IANA为共享地址空间保留IPv4前缀”，BCP 153，RFC 6598，2012年4月。
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012.
[RFC6724]Thaler，D.，Ed.，Draves，R.，Matsumoto，A.，和T.Chown，“互联网协议版本6（IPv6）的默认地址选择”，RFC 67242012年9月。
Authors' Addresses
作者地址
Victor Kuarsingh (editor) Rogers Communications 8200 Dixie Road Brampton, Ontario L6T 0C1 Canada
Victor Kuarsingh（编辑）加拿大安大略省布兰顿市迪克西路8200号罗杰斯通讯有限公司L6T 0C1
EMail: victor.kuarsingh@gmail.com
URI: http://www.rogers.com
EMail: victor.kuarsingh@gmail.com
URI: http://www.rogers.com
Yiu L. Lee Comcast One Comcast Center Philadelphia, PA 19103 U.S.A.
Yiu L.Lee Comcast美国宾夕法尼亚州费城Comcast中心1号，邮编：19103。
EMail: yiu_lee@cable.comcast.com
URI: http://www.comcast.com
EMail: yiu_lee@cable.comcast.com
URI: http://www.comcast.com
Olivier Vautrin Juniper Networks 1194 N Mathilda Avenue Sunnyvale, CA 94089 U.S.A.
美国加利福尼亚州桑尼维尔市马蒂尔达大道北1194号奥利维尔·维特林·朱尼珀网络公司，邮编94089。
EMail: olivier@juniper.net
URI: http://www.juniper.net
EMail: olivier@juniper.net
URI: http://www.juniper.net