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




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.


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


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 ( 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文件的法律规定的约束(自本文件出版之日起生效。请仔细阅读这些文件,因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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
1. Introduction
1. 介绍

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.


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.


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.


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]).


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.


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 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.


How this mechanism should be used and other deployment and operational considerations are considered out of scope for this document.


2. Requirements Language
2. 需求语言

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]中所述进行解释。

3. Terminology
3. 术语

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.


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 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 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.


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数据包。

4. 6rd Prefix Delegation
4. 第六次代表团

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


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, 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.


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]中指定的默认值。

5. Troubleshooting and Traceability
5. 故障排除和可追溯性

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.


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地址。

6. Address Selection
6. 地址选择

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.


7. 6rd Configuration
7. 第六配置

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.


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 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.


6rdPrefixLen The length of the 6rd IPv6 prefix for the given 6rd domain.


6rdBRIPv4Address The IPv4 address of the 6rd Border Relay for a given 6rd domain.


7.1. Customer Edge Configuration
7.1. 客户边缘配置

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.


7.1.1. 6rd DHCPv4 Option
7.1.1. 第6个DHCPv4选项
   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


option-code OPTION_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.


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.


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.


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.


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, a BR IPv4 address of, 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)
7.2. Border Relay Configuration
7.2. 边界中继配置

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.


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中公布选播地址。

8. Neighbor Unreachability Detection
8. 邻居不可达性检测

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.


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.


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.


9. IPv6 in IPv4 Encapsulation
9. IPv4封装中的IPv6

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.


9.1. Maximum Transmission Unit
9.1. 最大传输单位

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.


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字节。

9.2. Receiving Rules
9.2. 接收规则

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.


10. Transition Considerations
10. 过渡考虑

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.


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.


11. IPv6 Address Space Usage
11. 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.


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.


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.


12. Security Considerations
12. 安全考虑

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.


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.


Another possible mitigation to the routing loop issue is described in [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子网路由器选播地址除外。

13. IANA Considerations
13. IANA考虑

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地址)。

14. Acknowledgements
14. 致谢

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分享他的经验。许多其他人,特别是克里斯·蔡斯、托马斯·克劳森、沃特·克洛伊滕斯、沃伊切赫·德克、布鲁诺·德雷恩、雷米·德斯普雷斯、阿兰·杜兰德、瓦沙姆·范、马丁·吉西、大卫·哈林顿、杰瑞·黄、彼得·麦肯、阿列克西·梅尔尼科夫、戴夫·泰勒、埃里克·沃德和大卫·沃德·沃德,都给予了评论和鼓励。

15. References
15. 工具书类
15.1. Normative References
15.1. 规范性引用文件

[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月。

15.2. Informative References
15.2. 资料性引用

[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.


[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, < woot09/tech/full_papers/nakibly.pdf>.

[RoutingLoop]Nakbly和Arov,“使用IPv6隧道的路由环路攻击”,2009年8月< 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.


Authors' Addresses


Mark Townsley Cisco Paris, France



Ole Troan Cisco Bergen, Norway