Internet Engineering Task Force (IETF) W. Townsley
Request for Comments: 5969 O. Troan
Category: Standards Track Cisco
ISSN: 2070-1721 August 2010
Internet Engineering Task Force (IETF) W. Townsley
Request for Comments: 5969 O. Troan
Category: Standards Track Cisco
ISSN: 2070-1721 August 2010
IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification
IPv4基础设施上的IPv6快速部署（第6次）--协议规范
Abstract
摘要
This document specifies an automatic tunneling mechanism tailored to advance deployment of IPv6 to end users via a service provider's IPv4 network infrastructure. Key aspects include automatic IPv6 prefix delegation to sites, stateless operation, simple provisioning, and service, which is equivalent to native IPv6 at the sites that are served by the mechanism.
本文档指定了一种自动隧道机制，该机制专门用于通过服务提供商的IPv4网络基础设施向最终用户提前部署IPv6。关键方面包括自动将IPv6前缀委派给站点、无状态操作、简单资源调配和服务，这相当于该机制所服务站点上的本机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 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5969.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5969.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 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 . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. 6rd Prefix Delegation . . . . . . . . . . . . . . . . . . . . 5
5. Troubleshooting and Traceability . . . . . . . . . . . . . . . 7
6. Address Selection . . . . . . . . . . . . . . . . . . . . . . 7
7. 6rd Configuration . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Customer Edge Configuration . . . . . . . . . . . . . . . 8
7.1.1. 6rd DHCPv4 Option . . . . . . . . . . . . . . . . . . 9
7.2. Border Relay Configuration . . . . . . . . . . . . . . . . 10
8. Neighbor Unreachability Detection . . . . . . . . . . . . . . 11
9. IPv6 in IPv4 Encapsulation . . . . . . . . . . . . . . . . . . 12
9.1. Maximum Transmission Unit . . . . . . . . . . . . . . . . 13
9.2. Receiving Rules . . . . . . . . . . . . . . . . . . . . . 13
10. Transition Considerations . . . . . . . . . . . . . . . . . . 14
11. IPv6 Address Space Usage . . . . . . . . . . . . . . . . . . . 14
12. Security Considerations . . . . . . . . . . . . . . . . . . . 15
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
15.1. Normative References . . . . . . . . . . . . . . . . . . . 16
15.2. Informative References . . . . . . . . . . . . . . . . . . 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. 6rd Prefix Delegation . . . . . . . . . . . . . . . . . . . . 5
5. Troubleshooting and Traceability . . . . . . . . . . . . . . . 7
6. Address Selection . . . . . . . . . . . . . . . . . . . . . . 7
7. 6rd Configuration . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Customer Edge Configuration . . . . . . . . . . . . . . . 8
7.1.1. 6rd DHCPv4 Option . . . . . . . . . . . . . . . . . . 9
7.2. Border Relay Configuration . . . . . . . . . . . . . . . . 10
8. Neighbor Unreachability Detection . . . . . . . . . . . . . . 11
9. IPv6 in IPv4 Encapsulation . . . . . . . . . . . . . . . . . . 12
9.1. Maximum Transmission Unit . . . . . . . . . . . . . . . . 13
9.2. Receiving Rules . . . . . . . . . . . . . . . . . . . . . 13
10. Transition Considerations . . . . . . . . . . . . . . . . . . 14
11. IPv6 Address Space Usage . . . . . . . . . . . . . . . . . . . 14
12. Security Considerations . . . . . . . . . . . . . . . . . . . 15
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
15.1. Normative References . . . . . . . . . . . . . . . . . . . 16
15.2. Informative References . . . . . . . . . . . . . . . . . . 17
The original idea and the name of the mechanism (6rd) described in [RFC5569] details a successful commercial "rapid deployment" of the 6rd mechanism by a residential service provider and is recommended reading. This document describes the 6rd mechanism, which has been extended for use in more general environments. Throughout this document, the term 6to4 is used to refer to the mechanism described in [RFC3056] and 6rd is the mechanism defined herein.
[RFC5569]中描述的机制（6rd）的原始想法和名称详细说明了住宅服务提供商成功的商业“快速部署”第6rd机制，建议阅读。本文档描述了第六种机制，该机制已扩展，可用于更一般的环境。在本文件中，术语6to4用于指[RFC3056]中描述的机制，6rd是本文定义的机制。
6rd specifies a protocol mechanism to deploy IPv6 to sites via a service provider's (SP's) IPv4 network. It builds on 6to4 [RFC3056], with the key differentiator that it utilizes an SP's own IPv6 address prefix rather than a well-known prefix (2002::/16). By using the SP's IPv6 prefix, the operational domain of 6rd is limited to the SP network and is under its direct control. From the perspective of customer sites and the IPv6 Internet at large, the IPv6 service provided is equivalent to native IPv6.
6rd指定通过服务提供商（SP）的IPv4网络将IPv6部署到站点的协议机制。它建立在6to4[RFC3056]的基础上，其关键区别在于它使用SP自己的IPv6地址前缀，而不是众所周知的前缀（2002:：/16）。通过使用SP的IPv6前缀，6rd的操作域仅限于SP网络，并受其直接控制。从客户站点和整个IPv6 Internet的角度来看，提供的IPv6服务相当于本机IPv6。
The 6rd mechanism relies upon an algorithmic mapping between the IPv6 and IPv4 addresses that are assigned for use within the SP network. This mapping allows for automatic determination of IPv4 tunnel endpoints from IPv6 prefixes, allowing stateless operation of 6rd.
第六种机制依赖于分配用于SP网络的IPv6和IPv4地址之间的算法映射。此映射允许根据IPv6前缀自动确定IPv4隧道端点，从而允许第6条的无状态操作。
6rd views the IPv4 network as a link layer for IPv6 and supports an automatic tunneling abstraction similar to the Non-Broadcast Multiple Access (NBMA) [RFC2491] model.
6rd将IPv4网络视为IPv6的链路层，并支持类似于非广播多址（NBMA）[RFC2491]模型的自动隧道抽象。
A 6rd domain consists of 6rd Customer Edge (CE) routers and one or more 6rd Border Relays (BRs). IPv6 packets encapsulated by 6rd follow the IPv4 routing topology within the SP network among CEs and BRs. 6rd BRs are traversed only for IPv6 packets that are destined to or are arriving from outside the SP's 6rd domain. As 6rd is stateless, BRs may be reached using anycast for failover and resiliency (in a similar fashion to [RFC3068]).
第六域由第六客户边缘（CE）路由器和一个或多个第六边界中继（BR）组成。由6rd封装的IPv6数据包遵循CE和BR之间SP网络内的IPv4路由拓扑。第六个BRs仅针对发送到SP第六个域或从SP第六个域外部到达的IPv6数据包进行遍历。由于第6rd是无状态的，因此可以使用故障切换和恢复能力的选播（与[RFC3068]类似）来访问BRs。
On the "customer-facing" (i.e., "LAN") side of a CE, IPv6 is implemented as it would be for any native IP service delivered by the SP, and further considerations for IPv6 operation on the LAN side of the CE is out of scope for this document. On the "SP-facing" (i.e., "WAN") side of the 6rd CE, the WAN interface itself, encapsulation over Ethernet, ATM or PPP, as well as control protocols such as PPPoE, IPCP, DHCP, etc. all remain unchanged from current IPv4 operation. Although 6rd was designed primarily to support IPv6 deployment to a customer site (such as a residential home network) by an SP, it can equally be applied to an individual IPv6 host acting as a CE.
在CE的“面向客户”（即“LAN”）端，IPv6的实施方式与SP提供的任何本机IP服务相同，本文档不包括在CE的LAN端对IPv6操作的进一步考虑。在第六代CE的“面向SP”（即“WAN”）端，WAN接口本身、以太网、ATM或PPP上的封装以及PPPoE、IPCP、DHCP等控制协议与当前IPv4操作保持不变。尽管6rd主要用于支持SP将IPv6部署到客户站点（如住宅家庭网络），但它同样可以应用于充当CE的单个IPv6主机。
6rd relies on IPv4 and is designed to deliver production-quality IPv6 alongside IPv4 with as little change to IPv4 networking and operations as possible. Native IPv6 deployment within the SP network itself may continue for the SP's own purposes while delivering IPv6 service to sites supported by 6rd. Once the SP network and operations can support fully native IPv6 access and transport, 6rd may be discontinued.
6rd依赖于IPv4，旨在与IPv4一起提供高质量的IPv6，同时尽可能少地更改IPv4网络和操作。SP网络本身内的本机IPv6部署可能出于SP自身的目的而继续，同时向6rd支持的站点提供IPv6服务。一旦SP网络和操作能够完全支持本机IPv6访问和传输，第6rd可能会中断。
6rd utilizes the same encapsulation and base mechanism as 6to4 and could be viewed as a superset of 6to4 (6to4 could be achieved by setting the 6rd prefix to 2002::/16). Unlike 6to4, 6rd is for use only in an environment where a service provider closely manages the delivery of IPv6 service. 6to4 routes with the 2002::/16 prefix may exist alongside 6rd in the 6rd CE router, and doing so may offer some efficiencies when communicating directly with 6to4 routers.
6rd使用与6to4相同的封装和基本机制，可以看作6to4的超集（6to4可以通过将6rd前缀设置为2002:：/16来实现）。与6to4不同，6rd仅在服务提供商密切管理IPv6服务交付的环境中使用。带有2002:：/16前缀的6to4路由可能与6rd CE路由器中的6rd一起存在，这样做可以在直接与6to4路由器通信时提供一些效率。
The 6rd link model can be extended to support IPv6 multicast. IPv6 multicast support is left for future consideration.
第六链路模型可以扩展以支持IPv6多播。IPv6多播支持留待将来考虑。
How this mechanism should be used and other deployment and operational considerations are considered out of scope for this document.
应如何使用此机制以及其他部署和操作注意事项不在本文档的范围内。
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
6rd prefix An IPv6 prefix selected by the service provider for use by a 6rd domain. There is exactly one 6rd prefix for a given 6rd domain. An SP may deploy 6rd with a single 6rd domain or multiple 6rd domains.
第六个前缀服务提供商选择供第六个域使用的IPv6前缀。对于给定的第6个域，只有一个第6个前缀。SP可以使用单个6rd域或多个6rd域部署6rd。
6rd Customer Edge (6rd CE) A device functioning as a Customer Edge router in a 6rd deployment. In a residential broadband deployment, this type of device is sometimes referred to as a "Residential Gateway" (RG) or "Customer Premises Equipment" (CPE). A typical 6rd CE serving a residential site has one WAN side interface, one or more LAN side interfaces, and a 6rd virtual interface. A 6rd CE may also be referred to simply as a "CE" within the context of 6rd.
第六客户边缘（6rd CE）在第六次部署中用作客户边缘路由器的设备。在住宅宽带部署中，此类设备有时被称为“住宅网关”（RG）或“客户场所设备”（CPE）。为住宅站点提供服务的典型第6rd CE具有一个WAN端接口、一个或多个LAN端接口和一个第6rd虚拟接口。在第6条的上下文中，第6条CE也可以简单地称为“CE”。
6rd delegated prefix The IPv6 prefix calculated by the CE for use within the customer site by combining the 6rd prefix and the CE IPv4 address obtained via IPv4 configuration methods. This prefix can be considered logically equivalent to a DHCPv6 IPv6 delegated prefix [RFC3633].
第6rd delegated prefix第6rd prefix由CE计算的IPv6前缀，通过组合第6rd prefix和通过IPv4配置方法获得的CE IPv4地址在客户站点内使用。可以认为该前缀在逻辑上等同于DHCPv6 IPv6委派前缀[RFC3633]。
6rd domain A set of 6rd CEs and BRs connected to the same virtual 6rd link. A service provider may deploy 6rd with a single 6rd domain, or may utilize multiple 6rd domains. Each domain requires a separate 6rd prefix.
第六域连接到同一虚拟第六链路的一组第六个CE和BR。服务提供商可以使用单个6rd域部署6rd，也可以使用多个6rd域。每个域都需要一个单独的第6个前缀。
CE LAN side The functionality of a 6rd CE that serves the "Local Area Network (LAN)" or "customer-facing" side of the CE. The CE LAN side interface is fully IPv6 enabled.
CE LAN侧第六代CE的功能，服务于CE的“局域网（LAN）”或“面向客户”侧。CE LAN端接口完全支持IPv6。
CE WAN side The functionality of a 6rd CE that serves the "Wide Area Network (WAN)" or "Service Provider-facing" side of the CE. The CE WAN side is IPv4-only.
CE WAN端第六代CE的功能，服务于CE的“广域网（WAN）”或“面向服务提供商”端。CE WAN端仅为IPv4。
6rd Border Relay (BR) A 6rd-enabled router managed by the service provider at the edge of a 6rd domain. A Border Relay router has at least one of each of the following: an IPv4-enabled interface, a 6rd virtual interface acting as an endpoint for the 6rd IPv6 in IPv4 tunnel, and an IPv6 interface connected to the native IPv6 network. A 6rd BR may also be referred to simply as a "BR" within the context of 6rd.
第六边界中继（BR）由服务提供商在第六域边缘管理的第六启用路由器。边界中继路由器至少具有以下各项之一：启用IPv4的接口、充当IPv4隧道中第六个IPv6端点的第六个虚拟接口，以及连接到本机IPv6网络的IPv6接口。在第六条的上下文中，第六条业务规则也可以简称为“业务规则”。
BR IPv4 address The IPv4 address of the 6rd Border Relay for a given 6rd domain. This IPv4 address is used by the CE to send packets to a BR in order to reach IPv6 destinations outside of the 6rd domain.
BR IPv4地址给定第六个域的第六个边界中继的IPv4地址。CE使用此IPv4地址向BR发送数据包，以便到达第6个域之外的IPv6目标。
6rd virtual interface Internal multi-point tunnel interface where 6rd encapsulation and decapsulation of IPv6 packets inside IPv4 occurs. A typical CE or BR implementation requires only one 6rd virtual interface. A BR operating in multiple 6rd domains may require more than one 6rd virtual interface, but no more than one per 6rd domain.
第六虚拟接口内部多点隧道接口，在该接口中，IPv4内IPv6数据包的第六次封装和解除封装发生。典型的CE或BR实现只需要一个第6个虚拟接口。在多个第6个域中运行的BR可能需要多个第6个虚拟接口，但每个第6个域不需要多个。
CE IPv4 address The IPv4 address given to the CE as part of normal IPv4 Internet access (i.e., configured via DHCP, PPP, or otherwise). This address may be global or private [RFC1918] within the 6rd domain. This address is used by a 6rd CE to create the 6rd delegated prefix as well as to send and receive IPv4-encapsulated IPv6 packets.
CE IPv4地址作为正常IPv4 Internet访问的一部分提供给CE的IPv4地址（即，通过DHCP、PPP或其他方式配置）。此地址可以是第6个域中的全局地址或专用地址[RFC1918]。此地址由第六个CE用于创建第六个委派前缀以及发送和接收IPv4封装的IPv6数据包。
The 6rd delegated prefix for use at a customer site is created by combining the 6rd prefix and all or part of the CE IPv4 address. From these elements, the 6rd delegated prefix is automatically created by the CE for the customer site when IPv4 service is obtained. This 6rd delegated prefix is used in the same manner as a prefix obtained via DHCPv6 prefix delegation [RFC3633].
在客户站点使用的第6个委派前缀是通过将第6个前缀与全部或部分CE IPv4地址组合而创建的。从这些元素中，当获得IPv4服务时，CE将自动为客户站点创建第6个委派前缀。第6个委托前缀的使用方式与通过DHCPv6前缀委托[RFC3633]获得的前缀相同。
In 6to4, a similar operation is performed by incorporating an entire IPv4 address at a fixed location following a well-known /16 IPv6 prefix. In 6rd, the IPv6 prefix as well as the position and number of bits of the IPv4 address incorporated varies from one 6rd domain to the next. 6rd allows the SP to adjust the size of the 6rd prefix, how many bits are used by the 6rd mechanism, and how many bits are left to be delegated to customer sites. To allow for stateless address auto-configuration on the CE LAN side, a 6rd delegated prefix SHOULD be /64 or shorter.
在6to4中，类似的操作是通过在一个固定位置合并一个完整的IPv4地址，该地址位于一个众所周知的/16 IPv6前缀之后。在第六个域中，IPv6前缀以及合并的IPv4地址的位置和位数因第六个域的不同而不同。6rd允许SP调整第6rd前缀的大小、第6rd机制使用的位数以及剩余的要委托给客户站点的位数。为了允许在CE LAN端进行无状态地址自动配置，第6个委派前缀应为/64或更短。
The 6rd delegated prefix is created by concatenating the 6rd prefix and a consecutive set of bits from the CE IPv4 address in order. The length of the 6rd delegated prefix is equal to length of the 6rd prefix (n) plus the number of bits from the CE IPv4 address (o).
第6个委派前缀是通过依次连接第6个前缀和CE IPv4地址的一组连续位来创建的。第6个委派前缀的长度等于第6个前缀的长度（n）加上来自CE IPv4地址的位数（o）。
The figure shows the format of an IPv6 address (Section 2.5.4 of [RFC4291]) with a 6rd prefix and an embedded CE IPv4 address:
该图显示了具有第6个前缀和嵌入式CE IPv4地址的IPv6地址（RFC4291第2.5.4节）的格式：
| n bits | o bits | m bits | 128-n-o-m bits |
+---------------+--------------+-----------+------------------------+
| 6rd prefix | IPv4 address | subnet ID | interface ID |
+---------------+--------------+-----------+------------------------+
|<--- 6rd delegated prefix --->|
| n bits | o bits | m bits | 128-n-o-m bits |
+---------------+--------------+-----------+------------------------+
| 6rd prefix | IPv4 address | subnet ID | interface ID |
+---------------+--------------+-----------+------------------------+
|<--- 6rd delegated prefix --->|
Figure 1
图1
For example, if the 6rd prefix is /32 and 24 bits of the CE IPv4 address is used (e.g., all CE IPv4 addresses can be aggregated by a 10.0.0.0/8), then the size of the 6rd delegated prefix for each CE is automatically calculated to be /56 (32 + 24 = 56).
例如，如果第6个前缀为/32，并且使用了CE IPv4地址的24位（例如，所有CE IPv4地址可以通过10.0.0.0/8进行聚合），则每个CE的第6个委派前缀的大小将自动计算为/56（32+24=56）。
Embedding less than the full 32 bits of a CE IPv4 address is possible only when an aggregated block of IPv4 addresses is available for a given 6rd domain. This may not be practical with global IPv4 addresses, but is quite likely in a deployment where private addresses are being assigned to CEs. If private addresses overlap within a given 6rd deployment, the deployment may be divided into separate 6rd domains, likely along the same topology lines the NAT-based IPv4 deployment itself would require. In this case, each domain is addressed with a different 6rd prefix.
只有当IPv4地址的聚合块可用于给定的第6个域时，才能嵌入少于完整32位的CE IPv4地址。这可能不适用于全局IPv4地址，但很可能适用于将专用地址分配给CE的部署。如果专用地址在给定的第6个部署中重叠，则该部署可能被划分为单独的第6个域，可能与基于NAT的IPv4部署本身所需的拓扑线相同。在这种情况下，每个域都使用不同的第6个前缀进行寻址。
Each 6rd domain may use a different encoding of the embedded IPv4 address, even within the same service provider. For example, if multiple IPv4 address blocks with different levels of aggregation are used at the same service provider, the number of IPv4 bits needed to encode the 6rd delegated prefix may vary between each block. In this case, different 6rd prefixes, and hence separate 6rd domains, may be used to support the different encodings.
即使在同一个服务提供商内，每个第6个域也可能使用不同的嵌入式IPv4地址编码。例如，如果在同一服务提供商处使用具有不同聚合级别的多个IPv4地址块，则编码第6个委派前缀所需的IPv4比特数在每个块之间可能不同。在这种情况下，可以使用不同的第6个前缀，以及因此分离的第6个域来支持不同的编码。
Since 6rd delegated prefixes are selected algorithmically from an IPv4 address, changing the IPv4 address will cause a change in the IPv6 delegated prefix which would ripple through the site's network and could be disruptive. As such, it is recommended that the service provider assign CE IPv4 addresses with relatively long lifetimes.
由于第6个委派前缀是通过算法从IPv4地址中选择的，因此更改IPv4地址将导致IPv6委派前缀的更改，这将在站点网络中传播，并可能造成中断。因此，建议服务提供商为CE IPv4地址分配相对较长的生存期。
6rd IPv6 address assignment, and hence the IPv6 service itself, is tied to the IPv4 address lease; thus, the 6rd service is also tied to this in terms of authorization, accounting, etc. For example, the 6rd delegated prefix has the same lifetime as its associated IPv4 address. The prefix lifetimes advertised in Router Advertisements or used by DHCP on the CE LAN side MUST be equal to or shorter than the IPv4 address lease time. If the IPv4 lease time is not known, the lifetime of the 6rd delegated prefix SHOULD follow the defaults specified in [RFC4861].
第六个IPv6地址分配，以及IPv6服务本身，与IPv4地址租约绑定；因此，第六个服务在授权、记帐等方面也与此相关。例如，第六个委托前缀与其关联的IPv4地址具有相同的生存期。路由器播发中播发的前缀生存期或DHCP在CE LAN端使用的前缀生存期必须等于或小于IPv4地址租用时间。如果IPv4租用时间未知，则第6个委派前缀的生存期应遵循[RFC4861]中指定的默认值。
A 6rd IPv6 address and associated IPv4 address for a given customer can always be determined algorithmically by the service provider that operates the given 6rd domain. This may be useful for referencing logs and other data at a service provider that may have more robust operational tools for IPv4 than IPv6. This also allows IPv4 data path, node, and endpoint monitoring to be applicable to IPv6.
给定客户的第6个IPv6地址和相关IPv4地址始终可以由操作给定第6个域的服务提供商通过算法确定。这可能有助于在服务提供商处引用日志和其他数据，这些服务提供商可能拥有比IPv6更强大的IPv4操作工具。这还允许IPv4数据路径、节点和端点监视适用于IPv6。
The 6rd CE and BR SHOULD support the IPv6 Subnet-Router anycast address [RFC4291] for its own 6rd delegated prefix. This allows, for example, IPv6 ICMP echo messages to be sent to the 6rd virtual interface itself for additional troubleshooting of the internal operation of 6rd at a given CE or BR. In the case of the BR, the IPv4 address used to calculate the 6rd delegated prefix is the configured BR IPv4 address.
第6个CE和BR应支持IPv6子网路由器选播地址[RFC4291]作为其自己的第6个委派前缀。例如，这允许将IPv6 ICMP回显消息发送到第六虚拟接口本身，以便对给定CE或BR上的第六虚拟接口的内部操作进行额外的故障排除。对于BR，用于计算第6个委派前缀的IPv4地址是配置的BR IPv4地址。
All addresses assigned from 6rd delegated prefixes should be treated as native IPv6. No changes to the source address selection or destination address selection policy table [RFC3484] are necessary.
从第6个委派前缀分配的所有地址都应视为本机IPv6。无需更改源地址选择或目标地址选择策略表[RFC3484]。
For a given 6rd domain, the BR and CE MUST be configured with the following four 6rd elements. The configured values for these four 6rd elements are identical for all CEs and BRs within a given 6rd domain.
对于给定的第六个域，BR和CE必须配置以下四个第六个元素。这四个第6个元素的配置值对于给定第6个域中的所有CE和BR都是相同的。
IPv4MaskLen The number of high-order bits that are identical across all CE IPv4 addresses within a given 6rd domain. For example, if there are no identical bits, IPv4MaskLen is 0 and the entire CE IPv4 address is used to create the 6rd delegated prefix. If there are 8 identical bits (e.g., the Private IPv4 address range 10.0.0.0/8 is being used), IPv4MaskLen is equal to 8 and IPv4MaskLen high-order bits are stripped from the IPv4 address before constructing the corresponding 6rd delegated prefix.
IPv4MaskLen给定第6个域内所有CE IPv4地址中相同的高阶位数。例如，如果没有相同的位，IPv4MaskLen为0，整个CE IPv4地址用于创建第6个委派前缀。如果有8个相同的位（例如，正在使用专用IPv4地址范围10.0.0.0/8），则IPv4MaskLen等于8，并且在构造相应的第6个委派前缀之前，IPv4MaskLen高阶位将从IPv4地址中剥离。
6rdPrefix The 6rd IPv6 prefix for the given 6rd domain.
6rdPrefix给定第六个域的第六个IPv6前缀。
6rdPrefixLen The length of the 6rd IPv6 prefix for the given 6rd domain.
6rdPrefixLen给定第六个域的第六个IPv6前缀的长度。
6rdBRIPv4Address The IPv4 address of the 6rd Border Relay for a given 6rd domain.
6rdBRIPv4Address给定第六个域的第六个边界中继的IPv4地址。
The four 6rd elements are set to values that are the same across all CEs within a 6rd domain. The values may be configured in a variety of manners, including provisioning methods such as the Broadband Forum's "TR-69" [TR069] Residential Gateway management interface, an XML-based object retrieved after IPv4 connectivity is established, a DNS record, an SMIv2 MIB [RFC2578], PPP IPCP, or manual configuration by an administrator. This document describes how to configure the necessary parameters via a single DHCP option. A CE that allows IPv4 configuration by DHCP SHOULD implement this option. Other configuration and management methods may use the format described by this option for consistency and convenience of implementation on CEs that support multiple configuration methods.
四个第6个元素的值在第6个域中的所有CE中都是相同的。这些值可以多种方式配置，包括配置方法，例如宽带论坛的“TR-69”[TR069]住宅网关管理接口、IPv4连接建立后检索的基于XML的对象、DNS记录、SMIv2 MIB[RFC2578]、PPP IPCP或管理员手动配置。本文档介绍如何通过单个DHCP选项配置必要的参数。允许通过DHCP配置IPv4的CE应实现此选项。为了在支持多种配置方法的CE上实现的一致性和方便性，其他配置和管理方法可以使用此选项描述的格式。
The only remaining provisioning information the CE requires in order to calculate the 6rd delegated prefix and enable IPv6 connectivity is an IPv4 address for the CE. This CE IPv4 address is configured as part of obtaining IPv4 Internet access (i.e., configured via DHCP, PPP, or otherwise). This address may be global or private [RFC1918] within the 6rd domain.
CE计算第6个委派前缀并启用IPv6连接所需的唯一剩余配置信息是CE的IPv4地址。此CE IPv4地址配置为获取IPv4 Internet访问的一部分（即，通过DHCP、PPP或其他方式配置）。此地址可以是第6个域中的全局地址或专用地址[RFC1918]。
A single 6rd CE MAY be connected to more than one 6rd domain, just as any router may have more than one IPv6-enabled service provider facing interface and more than one set of associated delegated prefixes assigned by DHCPv6 prefix delegation or other means. Each
单个第6rd CE可以连接到多个第6rd域，就像任何路由器都可以具有多个支持IPv6的面向服务提供商的接口以及由DHCPv6前缀委派或其他方式分配的多组关联委派前缀一样。每个
domain a given CE operates within would require its own set of 6rd configuration elements and would generate its own 6rd delegated prefix.
给定CE在其中运行的域将需要其自己的第6个配置元素集，并将生成其自己的第6个委派前缀。
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_6RD | option-length | IPv4MaskLen | 6rdPrefixLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| 6rdPrefix |
| (16 octets) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6rdBRIPv4Address(es) |
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_6RD | option-length | IPv4MaskLen | 6rdPrefixLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| 6rdPrefix |
| (16 octets) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6rdBRIPv4Address(es) |
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2
图2
option-code OPTION_6RD (212)
选项代码选项6RD（212）
option-length The length of the DHCP option in octets (22 octets with one BR IPv4 address).
option length DHCP选项的长度，以八位字节为单位（22个八位字节，一个BR IPv4地址）。
IPv4MaskLen The number of high-order bits that are identical across all CE IPv4 addresses within a given 6rd domain. This may be any value between 0 and 32. Any value greater than 32 is invalid.
IPv4MaskLen给定第6个域内所有CE IPv4地址中相同的高阶位数。这可以是0到32之间的任何值。任何大于32的值都无效。
6rdPrefixLen The IPv6 prefix length of the SP's 6rd IPv6 prefix in number of bits. For the purpose of bounds checking by DHCP option processing, the sum of (32 - IPv4MaskLen) + 6rdPrefixLen MUST be less than or equal to 128.
6rdPrefixLen SP第六个IPv6前缀的IPv6前缀长度（以位为单位）。为了通过DHCP选项处理进行边界检查，（32-IPv4MaskLen）+6rdPrefixLen之和必须小于或等于128。
6rdBRIPv4Address One or more IPv4 addresses of the 6rd Border Relay(s) for a given 6rd domain.
6rdBRIPv4Address给定第六个域的第六个边界中继的一个或多个IPv4地址。
6rdPrefix The service provider's 6rd IPv6 prefix represented as a 16-octet IPv6 address. The bits in the prefix after the 6rdPrefixlen number of bits are reserved and MUST be initialized to zero by the sender and ignored by the receiver.
6rdPrefix服务提供商的第6rdipv6前缀，表示为16个八位组的IPv6地址。保留第6rdPrefixlen位数后前缀中的位，发送方必须将其初始化为零，接收方则忽略。
The CE MUST include a Parameter Request List Option [RFC2132] for the OPTION_6RD. Because the OPTION_6RD contains one IPv4MaskLen/ 6rdPrefixLen/6rdPrefix block, and because DHCP cannot convey more than one instance of an option, OPTION_6RD is limited to provision at most a single 6rd domain. Provisioning of a CE router connected to multiple 6rd domains is outside the scope of this protocol specification.
CE必须包括选项_6RD的参数请求列表选项[RFC2132]。由于选项_6RD包含一个IPv4MaskLen/6rdPrefixLen/6rdPrefix块，并且由于DHCP不能传递一个选项的多个实例，因此选项_6RD最多只能提供一个6RD域。提供连接到多个第6个域的CE路由器不在本协议规范的范围内。
The presence of the OPTION_6RD DHCP option is an indication of the availability of the 6rd service. By default, receipt of a valid 6rd DHCP option by a 6rd-capable CE results in configuration of the 6rd virtual interface and associated delegated prefix for use on the CE's LAN side. The CE MUST be able to configure the 6rd mechanism to be disabled, in which case the 6rd DHCP option, if received, is silently ignored.
第六个DHCP选项的存在表明第六个服务可用。默认情况下，支持第6条的CE收到有效的第6条DHCP选项后，将配置第6条虚拟接口和相关的委派前缀，以便在CE的LAN端使用。CE必须能够将第六个机制配置为禁用，在这种情况下，第六个DHCP选项（如果收到）将被静默忽略。
A detailed description of CE behavior using multiple BR IPv4 addresses is left for future consideration. In such a case, a CE MUST support at least one BR IPv4 address and MAY support more than one.
关于使用多个BR IPv4地址的CE行为的详细描述留待将来考虑。在这种情况下，CE必须支持至少一个BR IPv4地址，并且可以支持多个。
When 6rd is enabled, a typical CE router will install a default route to the BR, a black hole route for the 6rd delegated prefix, and routes for any LAN side assigned and advertised prefixes. For example, using a CE IPv4 address of 10.100.100.1, a BR IPv4 address of 10.0.0.1, an IPv4MaskLen of 8, 2001:db8::/32 as the 6rdPrefix, and one /64 prefix assigned to a LAN side interface, a typical CE routing table will look like:
当启用第6rd时，典型的CE路由器将安装到BR的默认路由、第6rd委派前缀的黑洞路由以及任何LAN端分配和公布前缀的路由。例如，使用CE IPv4地址10.100.100.1、BR IPv4地址10.0.0.1、IPV42001:db8:：/32作为6rdPrefix，以及分配给LAN端接口的一个/64前缀，典型的CE路由表如下所示：
::/0 -> 6rd-virtual-int0 via 2001:db8:0:100:: (default route)
2001:db8::/32 -> 6rd-virtual-int0 (direct connect to 6rd)
2001:db8:6464:100::/56 -> Null0 (delegated prefix null route)
2001:db8:6464:100::/64 -> Ethernet0 (LAN interface)
::/0 -> 6rd-virtual-int0 via 2001:db8:0:100:: (default route)
2001:db8::/32 -> 6rd-virtual-int0 (direct connect to 6rd)
2001:db8:6464:100::/56 -> Null0 (delegated prefix null route)
2001:db8:6464:100::/64 -> Ethernet0 (LAN interface)
The 6rd BR MUST be configured with the same 6rd elements as the 6rd CEs operating within the same domain.
第6rd BR必须配置与在同一域内运行的第6rd CE相同的第6rd元素。
For increased reliability and load balancing, the BR IPv4 address may be an anycast address shared across a given 6rd domain. As 6rd is stateless, any BR may be used at any time. If the BR IPv4 address is
为了提高可靠性和负载平衡，BR IPv4地址可以是在给定的第6个域中共享的选播地址。由于6rd是无状态的，因此任何BR都可以随时使用。如果BR IPv4地址为
anycast the relay MUST use this anycast IPv4 address as the source address in packets relayed to CEs.
选播中继必须使用此选播IPv4地址作为中继到CEs的数据包中的源地址。
Since 6rd uses provider address space, no specific routes need to be advertised externally for 6rd to operate, neither in IPv6 nor IPv4 BGP. However, if anycast is used for the 6rd IPv4 relays, the anycast addresses must be advertised in the service provider's IGP.
由于6rd使用提供商地址空间，所以无论是在IPv6还是IPv4 BGP中，6rd都不需要在外部公布特定的路由来运行。但是，如果选播用于第6个IPv4中继，则必须在服务提供商的IGP中公布选播地址。
Neighbor Unreachability Detection (NUD) for tunnels is described in Section 3.8 of [RFC4213]. In 6rd, all CEs and BRs can be considered as connected to the same virtual link and therefore neighbors to each other. This section describes how to utilize neighbor unreachability detection without negatively impacting the scalability of a 6rd deployment.
[RFC4213]第3.8节描述了隧道的邻居不可达性检测（NUD）。在第6条中，所有CEs和BRs可被视为连接到同一虚拟链路，因此彼此相邻。本节介绍如何利用邻居不可达性检测，而不会对第六次部署的可伸缩性产生负面影响。
A typical 6rd deployment may consist of a very large number of CEs within the same domain. Reachability between CEs is based on IPv4 routing, and sending NUD or any periodic packets between 6rd CE devices beyond isolated troubleshooting of the 6rd mechanism is NOT RECOMMENDED.
典型的第六次部署可能由同一域中的大量CE组成。CEs之间的可达性基于IPv4路由，不建议在第六代CE设备之间发送NUD或任何定期数据包，而不建议对第六代CE机制进行单独故障排除。
While reachability detection between a given 6rd CE and BR is not necessary for the proper operation of 6rd, in cases where a CE has alternate paths for BR reachability to choose from, it could be useful. Sending NUD messages to a BR, in particular periodic messages from a very large number of CEs, could result in overloading of the BR control message processing path, negatively affecting scalability of the 6rd deployment. Instead, a CE that needs to determine BR reachability MUST utilize a method that allows reachability detection packets to follow a typical data forwarding path without special processing by the BR. One such method is described below.
虽然给定的第6rd CE和BR之间的可达性检测对于第6rd的正常运行不是必需的，但在CE有备用路径供BR可达性选择的情况下，它可能是有用的。向BR发送NUD消息，特别是来自大量CE的定期消息，可能会导致BR控制消息处理路径过载，从而对第六次部署的可伸缩性产生负面影响。相反，需要确定BR可达性的CE必须利用一种方法，该方法允许可达性检测分组遵循典型的数据转发路径，而无需BR进行特殊处理。下面描述一种这样的方法。
1. The CE constructs a payload of any size and content to be sent to the BR (e.g., a zero-length null payload, a padded payload designed to test a certain MTU, a NUD message, etc.). The exact format of the message payload is not important as the BR will not be processing it directly.
1. CE构造任何大小和内容的有效载荷以发送给BR（例如，零长度空有效载荷、设计用于测试特定MTU的填充有效载荷、NUD消息等）。消息有效负载的确切格式并不重要，因为BR不会直接处理它。
2. The desired payload is encapsulated with the inner IPv6 and outer IPv4 headers as follows:
2. 所需的有效负载由内部IPv6和外部IPv4标头封装，如下所示：
* The IPv6 destination address is set to an address from the CE's 6rd delegated prefix that is assigned to a virtual interface on the CE.
* IPv6目标地址设置为CE第6个委派前缀中分配给CE上虚拟接口的地址。
* The IPv6 source address is set to an address from the CE's 6rd delegated prefix as well, including the same as used for the IPv6 destination address.
* IPv6源地址也设置为CE第6个委派前缀中的地址，包括用于IPv6目标地址的地址。
* The IPv4 header is then added as it normally would be for any packet destined for the BR. That is, the IPv4 destination address is that of the BR, and the source address is the CE IPv4 address.
* 然后添加IPv4报头，就像它通常用于发送给BR的任何数据包一样。也就是说，IPv4目标地址是BR的目标地址，而源地址是CE IPv4地址。
3. The CE sends the constructed packet out the interface on which BR reachability is being monitored. On successful receipt at the BR, the BR MUST decapsulate and forward the packet normally. That is, the IPv4 header is decapsulated normally, revealing the IPv6 destination as the CE, which in turn results in the packet being forwarded to that CE via the 6rd mechanism (i.e., the IPv4 destination is that of the CE that originated the packet, and the IPv4 source is that of the BR).
3. CE将构造的数据包发送到监控BR可达性的接口。BR成功接收数据包后，BR必须解除封装并正常转发数据包。也就是说，IPv4报头通常被解除封装，将IPv6目的地显示为CE，这反过来导致通过第六种机制将数据包转发到该CE（即，IPv4目的地是发起数据包的CE的目的地，IPv4源是BR的目的地）。
4. Arrival of the constructed IPv6 packet at the CE's IPv6 address completes one round trip to and from the BR, without causing the BR to process the message outside of its normal data forwarding path. The CE then processes the IPv6 packet accordingly (updating keepalive timers, metrics, etc.).
4. 构造的IPv6数据包到达CE的IPv6地址，完成往返BR的一次往返，而不会导致BR在其正常数据转发路径之外处理消息。CE然后相应地处理IPv6数据包（更新保留计时器、度量等）。
The payload may be empty or could contain values that are meaningful to the CE. Sending a proper NUD message could be convenient for some implementations (note that the BR will decrement the IPv6 hop limit). Since the BR forwards the packet as any other data packet without any processing of the payload itself, the format of the payload is left as a choice to the implementer.
有效负载可能为空，或者可能包含对CE有意义的值。发送适当的NUD消息对于某些实现可能很方便（请注意，BR将降低IPv6跃点限制）。由于BR将分组作为任何其他数据分组转发，而不对有效载荷本身进行任何处理，因此有效载荷的格式留给实现者选择。
IPv6 in IPv4 encapsulation and forwarding manipulations (e.g., handling packet markings, checksumming, etc.) is performed as specified in Section 3.5 of "Basic Transition Mechanisms for IPv6 Hosts and Routers" [RFC4213], which is the same mechanism used by 6to4 [RFC3056]. ICMPv4 errors are handled as specified in Section 3.4 of [RFC4213]. By default, the IPv6 Traffic Class field MUST be copied to the IPv4 ToS (Type of Service) field. This default behavior MAY be overridden by configuration. See [RFC2983] and [RFC3168] for further information related to IP Differentiated Services and tunneling.
IPv4中的IPv6封装和转发操作（例如，处理数据包标记、校验和等）按照“IPv6主机和路由器的基本转换机制”[RFC4213]第3.5节的规定执行，这与6to4[RFC3056]使用的机制相同。ICMPv4错误按照[RFC4213]第3.4节的规定进行处理。默认情况下，IPv6流量类别字段必须复制到IPv4 ToS（服务类型）字段。此默认行为可能会被配置覆盖。请参阅[RFC2983]和[RFC3168]了解有关IP区分服务和隧道的更多信息。
IPv6 packets from a CE are encapsulated in IPv4 packets when they leave the site via its CE WAN side interface. The CE IPv4 address MUST be configured to send and receive packets on this interface.
当来自CE的IPv6数据包通过其CE WAN端接口离开站点时，它们被封装在IPv4数据包中。CE IPv4地址必须配置为在此接口上发送和接收数据包。
The 6rd link is modeled as an NBMA link similar to other automatic IPv6 in IPv4 tunneling mechanisms like [RFC5214], with all 6rd CEs and BRs defined as off-link neighbors from one other. The link-local address of a 6rd virtual interface performing the 6rd encapsulation would, if needed, be formed as described in Section 3.7 of [RFC4213]. However, no communication using link-local addresses will occur.
第6条链路被建模为NBMA链路，类似于IPv4隧道机制（如[RFC5214]）中的其他自动IPv6，所有第6条CE和BR都定义为彼此的断开链路邻居。如果需要，执行第六次封装的第六次虚拟接口的链路本地地址将按照[RFC4213]第3.7节中的描述形成。但是，不会使用链路本地地址进行通信。
Maximum transmission unit (MTU) and fragmentation issues for IPv6 in IPv4 tunneling are discussed in detail in Section 3.2 of RFC 4213 [RFC4213]. 6rd's scope is limited to a service provider network. IPv4 Path MTU discovery MAY be used to adjust the MTU of the tunnel as described in Section 3.2.2 of RFC 4213 [RFC4213], or the 6rd Tunnel MTU might be explicitly configured.
RFC 4213[RFC4213]第3.2节详细讨论了IPv4隧道中IPv6的最大传输单元（MTU）和碎片问题。6rd的范围仅限于服务提供商网络。IPv4路径MTU发现可用于调整RFC 4213[RFC4213]第3.2.2节中所述的隧道MTU，或者可以显式配置第6隧道MTU。
The use of an anycast source address could lead to any ICMP error message generated on the path being sent to a different BR. Therefore, using dynamic tunnel MTU Section 3.2.2 of [RFC4213] is subject to IPv4 Path MTU blackholes.
使用选播源地址可能会导致在发送到其他BR的路径上生成任何ICMP错误消息。因此，使用[RFC4213]第3.2.2节中的动态隧道MTU会受到IPv4路径MTU黑洞的影响。
Multiple BRs using the same anycast source address could send fragmented packets to the same IPv6 CE at the same time. If the fragmented packets from different BRs happen to use the same fragment ID, incorrect reassembly might occur. For this reason, a BR using an anycast source address MUST set the IPv4 Don't Fragment flag.
使用相同选播源地址的多个BR可以同时向同一IPv6 CE发送碎片数据包。如果来自不同BRs的碎片数据包恰好使用相同的碎片ID，则可能会发生错误的重新组装。因此，使用选播源地址的BR必须设置IPv4不分段标志。
If the MTU is well-managed such that the IPv4 MTU on the CE WAN side interface is set so that no fragmentation occurs within the boundary of the SP, then the 6rd Tunnel MTU should be set to the known IPv4 MTU minus the size of the encapsulating IPv4 header (20 bytes). For example, if the IPv4 MTU is known to be 1500 bytes, the 6rd Tunnel MTU might be set to 1480 bytes. Absent more specific information, the 6rd Tunnel MTU SHOULD default to 1280 bytes.
如果MTU管理良好，因此CE WAN端接口上的IPv4 MTU设置为SP边界内不会出现碎片，则第6隧道MTU应设置为已知IPv4 MTU减去封装IPv4报头的大小（20字节）。例如，如果已知IPv4 MTU为1500字节，则第6隧道MTU可能设置为1480字节。如果没有更具体的信息，第6隧道MTU应默认为1280字节。
In order to prevent spoofing of IPv6 addresses, the 6rd BR and CE MUST validate the embedded IPv4 source address of the encapsulated IPv6 packet with the IPv4 source address it is encapsulated by according to the configured parameters of the 6rd domain. If the two source addresses do not match, the packet MUST be dropped and a counter incremented to indicate that a potential spoofing attack may be underway. Additionally, a CE MUST allow forwarding of packets sourced by the configured BR IPv4 address.
为了防止对IPv6地址的欺骗，第6rd BR和CE必须根据第6rd域的配置参数，使用其封装的IPv4源地址验证封装IPv6数据包的嵌入式IPv4源地址。如果两个源地址不匹配，则必须丢弃数据包，并增加一个计数器，以指示可能正在进行潜在的欺骗攻击。此外，CE必须允许转发由配置的BR IPv4地址来源的数据包。
By default, the CE router MUST drop packets received on the 6rd virtual interface (i.e., after decapsulation of IPv4) for IPv6 destinations not within its own 6rd delegated prefix.
默认情况下，CE路由器必须丢弃在第6个虚拟接口（即，在IPv4解除封装后）上接收的IPv6目的地的数据包，而这些数据包不在其自己的第6个委派前缀内。
An SP network can migrate to IPv6 at its own pace with little or no effect on customers being provided IPv6 via 6rd. When native IPv6 connectivity is available, an administrator can choose to disable 6rd.
SP网络可以按照自己的速度迁移到IPv6，而不会对通过第6条IPv6向客户提供的服务产生任何影响。当本机IPv6连接可用时，管理员可以选择禁用6rd。
The SP can choose to provision a separate IPv6 address block for native service, or reuse the 6rd prefix block itself. If the SP uses a separate address block, moving from 6rd to native IPv6 is seen as a normal IPv6 renumbering event for the customer. Renumbering may also be avoided by injecting the 6rd delegated prefix into the SP's IPv6 routing domain. Further considerations with regards to transitioning from 6rd to native IPv6 are not covered in this protocol specification.
SP可以选择为本机服务提供单独的IPv6地址块，或者重用第6个前缀块本身。如果SP使用单独的地址块，则从第6条移动到本机IPv6将被视为客户的正常IPv6重新编号事件。通过将第6个委派前缀注入SP的IPv6路由域，也可以避免重新编号。本协议规范中没有涉及从第6条过渡到本机IPv6的进一步考虑。
As 6rd uses service-provider address space, 6rd uses the normal address delegation a service provider gets from its Regional Internet Registry (RIR) and no global allocation of a single 6rd IANA-assigned address block like the 6to4 2002::/16 is needed.
由于6rd使用服务提供商地址空间，6rd使用服务提供商从其区域Internet注册表（RIR）获得的正常地址委派，并且不需要像6to4 2002:：/16这样的单个6rd IANA分配地址块的全局分配。
The service provider's prefix must be short enough to encode the unique bits of all IPv4 addresses within a given 6rd domain and still provide enough IPv6 address space to the residential site. Assuming a worst case scenario using the full 32 bits for the IPv4 address, assigning a /56 for customer sites would mean that each service provider using 6rd would require a /24 for 6rd in addition to other IPv6 addressing needs. Assuming that 6rd would be stunningly successful and taken up by almost all Autonomous System (AS) number holders (32K today), then the total address usage of 6rd would be equivalent to a /9. If the SP instead delegated /60s to sites, the service provider would require a /28, and the total global address consumption by 6rd would be equivalent to a /13. Again, this assumes that 6rd is used by all AS number holders in the IPv4 Internet today at the same time, that none have used any of 6rd's address compression techniques, and that none have moved to native IPv6 and reclaimed the 6rd space that was being used for other purposes.
服务提供商的前缀必须足够短，以便对给定第6个域中所有IPv4地址的唯一位进行编码，并且仍然为住宅站点提供足够的IPv6地址空间。假设在最坏的情况下，IPv4地址使用完整的32位，为客户站点分配a/56意味着每个使用第6rd的服务提供商除了需要其他IPv6寻址外，还需要第6rd的a/24。假设第6rd将取得惊人的成功，并被几乎所有的自治系统（AS）号码持有者（目前为32K）使用，那么第6rd的地址使用总量将相当于a/9。如果SP将/60委派给站点，则服务提供商将需要a/28，第6条的总全局地址消耗量将相当于a/13。同样，这假设今天IPv4互联网上所有人都同时使用6rd作为号码持有者，没有人使用过6rd的任何地址压缩技术，也没有人移动到本机IPv6并回收用于其他目的的6rd空间。
To alleviate concerns about address usage, 6rd allows for leaving out redundant IPv4 prefix bits in the encoding of the IPv4 address inside the 6rd IPv6 address. This is most useful where the IPv4 address space is very well aggregated. For example, to provide each customer
为了减轻对地址使用的担忧，第6rd允许在第6rd IPv6地址内的IPv4地址编码中省略多余的IPv4前缀位。这在IPv4地址空间聚合良好的情况下最有用。例如，为每个客户提供
with a /60, if a service provider has all its IPv4 customers under a /12 then only 20 bits needs to be used to encode the IPv4 address and the service provider would only need a /40 IPv6 allocation for 6rd. If private address space is used, then a 10/8 would require a /36. If multiple 10/8 domains are used, then up to 16 could be supported within a /32.
对于a/60，如果服务提供商的所有IPv4客户都在a/12下，则只需使用20位对IPv4地址进行编码，并且服务提供商只需为第6次分配a/40 IPv6。如果使用专用地址空间，则10/8将需要a/36。如果使用多个10/8域，则a/32中最多可支持16个域。
If a service provider has a non-aggregatable IPv4 space and requiring the use of the full 32-bit IPv4 address in the encoding of the 6rd IPv6 address, the 6rd prefix MUST be no longer than /32 in order to offer a 6rd delegated prefix of at least /64.
如果服务提供商具有不可聚合的IPv4空间，并且在编码第六个IPv6地址时需要使用完整的32位IPv4地址，则第六个前缀必须不超过/32，以便提供至少/64的第六个委派前缀。
The 6rd address block can be reclaimed when all users of it have transitioned to native IPv6 service. This may require renumbering of customer sites and use of additional address space during the transition period.
当第6个地址块的所有用户都转换到本机IPv6服务时，可以回收该地址块。这可能需要对客户站点重新编号，并在过渡期间使用额外的地址空间。
A 6to4 relay router as specified in [RFC3056] can be used as an open relay. It can be used to relay IPv6 traffic and as a traffic anonymizer. By restricting the 6rd domain to within a provider network, a CE only needs to accept packets from a single or small set of known 6rd BR IPv4 addresses. As such, many of the threats against 6to4 as described in [RFC3964] do not apply.
[RFC3056]中规定的6to4中继路由器可用作开放式中继。它可以用来中继IPv6流量，也可以作为流量匿名器。通过将第6个域限制在提供商网络内，CE只需要接受来自单个或一小组已知第6个BR IPv4地址的数据包。因此，[RFC3964]中描述的许多针对6to4的威胁不适用。
When applying the receiving rules in Section 9.2, IPv6 packets are as well protected against spoofing as IPv4 packets are within an SP network.
当应用第9.2节中的接收规则时，IPv6数据包与SP网络中的IPv4数据包一样受到良好的防欺骗保护。
A malicious user that is aware of a 6rd domain and the BR IPv4 address could use this information to construct a packet that would cause a Border Relay to reflect tunneled packets outside of the domain that it is serving. If the attacker constructs the packet accordingly and can inject a packet with an IPv6 source address that looks as if it originates from within another 6rd domain, forwarding loops between 6rd domains may be created, allowing the malicious user to launch a packet amplification attack between 6rd domains [RoutingLoop].
知道第6个域和BR IPv4地址的恶意用户可能会使用此信息构造一个数据包，该数据包将导致边界中继在其所服务的域之外反映隧道传输的数据包。如果攻击者相应地构造数据包，并可以注入一个具有IPv6源地址的数据包，该数据包看起来似乎来自另一个第6个域，则可能会在第6个域之间创建转发循环，从而允许恶意用户在第6个域之间发起数据包放大攻击[RoutingLoop]。
One possible mitigation for this is to simply not allow the BR IPv4 address to be reachable from outside the SP's 6rd domain. In this case, carefully constructed IPv6 packets still could be reflected off a single BR, but the looping condition will not occur. Tunneled packets with the BR IPv4 address as the source address might also be filtered to prohibit 6rd tunnels from exiting the 6rd domain.
一种可能的缓解措施是不允许从SP的第6个域之外访问BR IPv4地址。在这种情况下，精心构造的IPv6数据包仍然可以从单个BR中反映出来，但不会出现循环情况。以BR IPv4地址作为源地址的隧道数据包也可能被过滤，以禁止第6个隧道退出第6个域。
To avoid forwarding loops via other internal relays, the BR should employ outgoing and incoming IPv4 packets filters, filtering out all known relay addresses for internal 6rd BRs, ISATAP routers, or 6to4 relays, including the well-known anycast address space for 6to4.
为了避免通过其他内部中继转发环路，BR应使用传出和传入IPv4数据包过滤器，过滤掉内部第六个BR、ISATAP路由器或6to4中继的所有已知中继地址，包括众所周知的6to4选播地址空间。
Another possible mitigation to the routing loop issue is described in [V6OPS-LOOPS].
[V6OPS-LOOPS]中描述了路由环路问题的另一种可能的缓解方法。
The BR MUST install a null route [RFC4632] for its 6rd delegated prefix created based on its BR IPv4 address, with the exception of the IPv6 Subnet-Router anycast address.
BR必须为其基于BR IPv4地址创建的第6个委派前缀安装空路由[RFC4632]，IPv6子网路由器选播地址除外。
IANA assigned a new DHCP Option code point for OPTION_6RD (212) with a data length of 18 + N (OPTION_6RD with N/4 6rd BR addresses).
IANA为Option_6RD（212）分配了一个新的DHCP选项代码点，数据长度为18+N（Option_6RD有N/4个6RD BR地址）。
This RFC is based on Remi Despres' original idea described in [RFC5569] and the work done by Rani Assaf, Alexandre Cassen, and Maxime Bizon at Free Telecom. Brian Carpenter and Keith Moore documented 6to4, which all of this work is based upon. We thank Fred Templin for his review and contributions, and for sharing his experience with ISATAP. Review and encouragement have been provided by many others and in particular Chris Chase, Thomas Clausen, Wouter Cloetens, Wojciech Dec, Bruno Decraene, Remi Despres, Alain Durand, Washam Fan, Martin Gysi, David Harrington, Jerry Huang, Peter McCann, Alexey Melnikov, Dave Thaler, Eric Voit, and David Ward.
本RFC基于[RFC5569]中所述的Remi Despres的原始想法以及免费电信公司的Rani Assaf、Alexandre Cassen和Maxime Bizon所做的工作。Brian Carpenter和Keith Moore记录了6to4，这是所有这些工作的基础。我们感谢Fred Templin的评论和贡献，以及与ISATAP分享他的经验。许多其他人，特别是克里斯·蔡斯、托马斯·克劳森、沃特·克洛伊滕斯、沃伊切赫·德克、布鲁诺·德雷恩、雷米·德斯普雷斯、阿兰·杜兰德、瓦沙姆·范、马丁·吉西、大卫·哈林顿、杰瑞·黄、彼得·麦肯、阿列克西·梅尔尼科夫、戴夫·泰勒、埃里克·沃德和大卫·沃德·沃德，都给予了评论和鼓励。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，R.，Karrenberg，D.，Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[RFC2132]Alexander，S.和R.Droms，“DHCP选项和BOOTP供应商扩展”，RFC 21321997年3月。
[RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 over Non-Broadcast Multiple Access (NBMA) networks", RFC 2491, January 1999.
[RFC2491]Armitage，G.，Schulter，P.，Jork，M.，和G.Harter，“非广播多址（NBMA）网络上的IPv6”，RFC 2491，1999年1月。
[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月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168]Ramakrishnan，K.，Floyd，S.，和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，2001年9月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213]Nordmark，E.和R.Gilligan，“IPv6主机和路由器的基本转换机制”，RFC 4213，2005年10月。
[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月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 48612007年9月。
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2578]McCloghrie，K.，Ed.，Perkins，D.，Ed.，和J.Schoenwaeld，Ed.“管理信息的结构版本2（SMIv2）”，STD 58，RFC 2578，1999年4月。
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC2983]Black，D.，“差异化服务和隧道”，RFC 29832000年10月。
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001.
[RFC3068]Huitema，C.，“6to4中继路由器的选播前缀”，RFC3068，2001年6月。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484]Draves，R.，“互联网协议版本6（IPv6）的默认地址选择”，RFC 3484，2003年2月。
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
[RFC3633]Troan，O.和R.Droms，“动态主机配置协议（DHCP）版本6的IPv6前缀选项”，RFC 3633，2003年12月。
[RFC3964] Savola, P. and C. Patel, "Security Considerations for 6to4", RFC 3964, December 2004.
[RFC3964]Savola，P.和C.Patel，“6to4的安全考虑”，RFC 3964，2004年12月。
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006.
[RFC4632]Fuller，V.和T.Li，“无类域间路由（CIDR）：互联网地址分配和聚合计划”，BCP 122，RFC 4632，2006年8月。
[RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, March 2008.
[RFC5214]Templin，F.，Gleeson，T.，和D.Thaler，“站点内自动隧道寻址协议（ISATAP）”，RFC 52142008年3月。
[RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)", RFC 5569, January 2010.
[RFC5569]Despres，R.，“IPv4基础设施上的IPv6快速部署（第6次）”，RFC 5569，2010年1月。
[RoutingLoop] Nakibly and Arov, "Routing Loop Attacks using IPv6 Tunnels", August 2009, <http://www.usenix.org/event/ woot09/tech/full_papers/nakibly.pdf>.
[RoutingLoop]Nakbly和Arov，“使用IPv6隧道的路由环路攻击”，2009年8月<http://www.usenix.org/event/ woot09/tech/full_papers/nakbly.pdf>。
[TR069] "TR-069, CPE WAN Management Protocol v1.1, Version: Issue 1 Amendment 2", December 2007.
[TR069]“TR-069，CPE WAN管理协议v1.1，版本：第1期修正案2”，2007年12月。
[V6OPS-LOOPS] Nakibly, G. and F. Templin, "Routing Loop Attack using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations", Work in Progress, May 2010.
[V6OPS-LOOPS]Nakbly，G.和F.Templin，“使用IPv6自动隧道的路由环路攻击：问题陈述和建议的缓解措施”，正在进行的工作，2010年5月。
Authors' Addresses
作者地址
Mark Townsley Cisco Paris, France
马克·汤斯利，法国巴黎
EMail: mark@townsley.net
EMail: mark@townsley.net
Ole Troan Cisco Bergen, Norway
挪威卑尔根
EMail: ot@cisco.com
EMail: ot@cisco.com