2024年10月2日发(作者：艾耘)
本文翻译者：weicq2000
RFC-6343 6to4部署咨询指南
(2011年8月)
摘要
本文件就(针对IPv6 over IPv4自动隧道化的)6to4技术部署，向网络运营商提供建议。
主要是面向互联网服务提供商(ISPs)，包括还没有对IPv6提供支持的ISPs，以及内容提供商。
也包括对实现者的某些建议。建议的目的是最大程度降低用户不满，和在线帮助(help-desk)
呼叫数量。
本备忘录状态
This document is not an Internet Standards Track specification; it is published for informational
purposes.
This document is a product of the Internet Engineering Task Force (IETF). It represents the
consensus of the IETF community. It has received public review and has been approved for
publication by the Internet Engineering Steering Group (IESG). Not all documents approved by
the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata, and how to provide feedback on
it may be obtained at /info/rfc6343.
版权声明
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights
reserved.
This document is subject to BCP 78 and the IETF Trust’s Legal Provisions Relating to IETF
Documents (/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.
目录
第1章 引言
第2章 工作原理
2-1 路由器6to4
2-2 任播6to4
第3章 观察到的问题
第4章 咨询指南
4-1 供应商问题
4-2 不以任何方式支持IPv6的用户ISPs及企业网络
4-2-1 任播地址可用性
4-2-2 协议41
4-2-3 IPv4前缀问题
4-2-4 DNS问题
4-2-5 流氓路由器通告
4-2-6 IPv6部署规划
4-3 支持IPv6的用户ISPs及企业网络
4-4 传输ISPs和互联网交换点
4-5 内容提供商和他们的ISPs
第5章 由ISPs管理的隧道
第6章 安全考虑
第7章 致谢
第8章 参考文献
8-1 标准类参考文献
8-2 信息类参考文献
撰写者通讯录
第1章 引言
IPv6 over IPv4自动隧道化技术，适合这样情况，那里用户可能希望通过不支持IPv6的
网络，访问基于IPv6的服务。IPv6 over IPv4自动隧道化技术多年前就已经定义了。它被称
作6to4 [RFC-3056] [RFC-3068]，在端系统中得到广泛部署，尤其是在台式机和笔记本电脑
中。同样，大量通用型号CPE路由器支持6to4，一些CPE路由器已经将启动6to4作为默认
配置，这导致终端用户十分广泛地无意识部署6to4。
不幸的是，实践表明该方法在目前的部署中存在问题，可能导致连接失败。这些失败或
者引起反复重试造成的时间耽搁，或者使用户完全放弃试图连接到IPv6服务。在许多情况，
用户可能完全没有意识到在使用6to4；当用户咨询在线帮助时，在线帮助十之八九不能正确
诊断问题。令人无语的是，许多在线帮助简单劝告用户关闭IPv6，于是，击败了为鼓励尽
早采用IPv6所作的全部努力。
此文件的主要目标是针对这种情况，向网络运营商提供比关闭6to4更具建设性的建议。
简单描述工作原理，接着描述观察到的问题，并最终提出有针对性的建议，指出避免问题出
现的可行方法。注意，这些建议的一部分适合还不能支持IPv6的ISPs，因为他们的用户和
在线帮助总之受到很大影响。
其他建议适用于内容提供商和实现者，但是本文件不讨论超出网络运营商范围的内容，
如：
1、操作系统在IPv4和IPv6间对谁更优先，当二者都可用时[RFC-3484, REVISE]。
2、确保应用软件适当地处理连接问题[EYEBALLS-IPV6]。
3、某些内容提供商选择回避问题，除了来自通过资格预审的网络的用户外，对其他用户隐
藏他们的IPv6地址[DNSWHITE]。
参考文献[HISTORIC]建议重新分类6to4为Historic。然而，这不会搬走大量使用6to4
的现存主机和CPE。因此，本文件的建议是保留必须的。
第2章 工作原理
有两种6to4变形，这里分别称为“路由器6to4”和“任播6to4”。为了理解任播6to4，
首先必须要了解路由器6to4。
2-1 路由器6to4
路由器6to4是原始版本，在[RFC-3056]中定义。该模型假设用户站点运行本地IPv6，
但是它的ISP不提供IPv6服务。站点的边界路由器充当6to4路由器。如果边界路由器外部
全球32位IPv4地址是V4ADDR，站点自动继承IPv6前缀2002:V4ADDR::/48。(在RFC3056
中的解释有点混淆，因为该解释指已废除的“最高级别聚合(Top Level Aggregator)”术语。)
在用户站点中将使用前缀2002: V4ADDR::/48，并且代表IPv6服务。
考虑两个这类站点边界路由器，具有全球IPv4地址192.0.2.170和192.0.2.187，因此分
别继承IPv6前缀2002:c000:2aa::/48和2002:c000:2bb::/48。通过在使用协议号为41的IPv4
中封装IPv6分组，路由器们能够交换IPv6分组，并以IPv6分组各自的IPv4地址相互发送
它们。事实上，连接到IPv4网络的任何数量的6to4路由器能够采用此方法直接交换IPv6
分组。
某些6to4路由器也被配置为“中继路由器”。它们的行为如上面刚刚描述的，但是，此
外，它们得到具有正常IPv6前缀的本地IPv6连接。它们通告到2002::/16的IPv6路由。例如，
假设在192.0.2.187的6to4路由器是中继路由器，它的6to4一侧的地址是2002:c000:2bb::1。假
设具有6to4地址2002:c000:2aa::123的主机发送IPv6分组到本地IPv6目的地，例如
2001:db8:123:456::321。假设在192.0.2.170的6to4路由器使它的IPv6默认路由设置为
2002:c000:2bb::1，即，中继。分组将被交付到此中继，被封装在IPv4中。该中继将解封装分
组，并转发分组到应交付的本地IPv6。当远端主机回应时，分组(源2001:db8:123:456::321，
目的地 2002:c000:2aa::123)将发现到2002::/16的路由，因此被交付到6to4中继。处理将倒过
来，分组将被封装并被转发到在192.0.2.170的6to4路由器，完成最终的交付。
注意，此处理不要求在两个方向上使用相同中继。出境分组将被发往随便哪个被配置为
(源路由器中的)默认IPv6路由器的中继，返回的分组将被发往位于远端IPv6主机附近的随
便哪个正在通告到2002::/16路由的中继。
当然，在RFC3056中有更多细节，但这些细节中大部分内容与这里的操作问题无关。
2-2 任播6to4
路由器6to4假设将协同管理和配置6to4路由器和中继。尤其是，6to4站点们需要配置
愿意携带它们的出境流量的中继路由器，该中继路由器变成它们的默认IPv6路由器(除了
2002::/16以外)。任播6to4的目标，在[RFC-3068]中定义，是避免任何这种配置需要。其目
的是使解决方案适于小型或家庭用户，甚至这些用户仅有单个主机或简单的家庭网关而不是
边界路由器。这实现起来非常简单，定义192.88.99.1为6to4中继的默认IPv4地址，因此
2002:c058:6301::为6to4站点的默认IPv6路由器地址。
因为任播6to4隐含有用户站点的默认配置，它不要求任何特殊的用户行动。任播6to4
要求IPv4任播路由位于到中继的恰当位置，该中继位于192.88.99.1。与路由器6to4一样，
不要求返回路径通过相同中继。
第3章 观察到的问题
应当注意到，路由器6to4不是被设计为无管理的解决方案。正好相反：RFC3056包含
大量目的在于避免路由问题的操作建议。实践中，即使有遵循这些建议的路由器6to4部署
也很少。大部分部署的是任播6to4。在此情况，用户站点(或单个主机，或小型宽带网关)发
现，它没有本地IPv6连接，但是它有全球IPv4地址，并且能够解析AAAA质询。因此，
它假设它能够发送6to4分组到192.88.99.1。
根据试验，6to4看来似乎遭受了相当程度的连接失败；参阅[Aben]和[Huston-a]。在连
通大量双栈web服务器的试验中，测量了TCP连接失败率。在这些试验中，当服务器收到
TCP SYN分组并在响应中发送SYN/ACK分组时，用户连接到服务器的尝试被认为已经失
败，但是没有收到ACK分组以便完成初始化TCP三次握手。由Aben实施的试验记录，失
败率介于所有6to4连接尝试的9%到20%之间。由Huston实施的试验记录，失败率介于所
有6to4用户的9%到19%之间。在后一个试验中，进一步注意到，所有失败于使用6to4连
接的6to4用户的65%到80%能够使用IPv4成功连接，而其余用户没有做任何形式的IPv4
连接尝试，成功或失败，使用映射的IPv4地址为源地址。使用嵌入的RFC1918 IPv4地址的
无连接尝试由服务器记录。
对于这种形式的6to4连接失败，存在几个可能原因。原因之一是使用嵌入在6to4地址
中的私有IPv4地址，使得6to4隧道返回路径不能使用，其次是本地过滤器和防火墙抛弃使
用IP协议41的输入IP分组。如果前一种情况普遍存在，作这样的预期是合理的，即预期
相当大比例失败的6to4连接使用了嵌入的IPv4地址，该地址或者是从私有应用(RFC1918)
地址范围提取的，违背RFC3056，或者是从在互联网的IPv4域间路由表中没有宣布的地址
范围中提取的。在由Huston实施的实验中，没有一种情况被观察到存在有意义的数量。此
外，改变实验条件，以便使用返回的6to4隧道，该隧道或者采用双栈服务器的本地IPv4源
地址，或者采用192.88.99.1的IPv4源地址。这两种配置间，在6to4连接失败率上没有观察
到变化；然而，当从本地地址响应时，其他运营商报告了有意义的问题，这些问题是由在用
户站点的有状态防火墙引起的。假设对于返回路径，服务器使用它自己的6to4中继，在成
功的IPv4连接和失败的6to4连接间IP分组自身的唯一区别是IP协议号，对于成功的IPv4
连接协议号是6(TCP)，对于失败的6to4连接协议号是41(IPv6净荷)。从这些实验可得出结
论，6to4连接的高连接失败率的一个很可能原因是靠近端用户的本地过滤器的使用，它阻断
了协议号为41的输入分组，在某些情况，如果源地址不是192.88.99.1，有状态防火墙会使
情况更糟。
在双栈背景中，这个连接失败率事实上由，用户系统从失败中恢复并使用IPv4做一次
成功连接的能力标注。在此情况，对用户系统唯一影响是，因为用户系统在6to4连接尝试
上超时，用7到20秒时间进行IPv4连接导致的延时(参阅[EYEBALLS-IPV6])。
此试验以及进一步的分析显示，与任播6to4有关的特定运行问题包括：
1、出境黑洞
192.88.99.1不生成“目的地不可达”，但是事实上发送到那个地址(即192.88.99.1)的分
组被抛弃。这可以由路由或防火墙配置发生，或者甚至因为分组碰巧到达的中继包含
ACL(Access Control Lists, 译者)，以至于分组被抛弃。
出现这类问题，是因为用户的ISP正在接受一条到192.88.99.0/24的路由，尽管事实上
该路由不去任何有用的地方。或者用户站点或用户的ISP正在抛弃出境协议41流量，或者
上游运营商不愿意接收来自该用户ISP的输入6to4分组。后者表面上与路由器6to4设计兼
容(指RFC3056中的“不愿意中继”)。然而，通告一条到IPv4中192.88.99.0/24的路由的简
单事实，伴随着RFC3068中描述的行为，等同于通告到接受该IPv4路由的所有6to4站点
的默认IPv6路由，这违反了RFC3065的假设。
此问题对于用户的影响是他们的IPv6栈相信它有6to4连接，但是事实上所有输出的
IPv6分组被投入黑洞。此问题的流行程度很难测量，因为最终的IPv6分组绝对不能从外部
观察到。
2、入境黑洞
在此情况，发送到192.88.99.1的6to4分组被正确地交付到6to4中继，返回响应分组，
但是响应分组被入境协议41过滤器抛弃。就用户来说，结果与上一种情况相同：IPv6是黑
洞。据了解，许多企业网络是以此方式建立的。基于此情况的连接尝试可由IPv6服务器操
作者观察到，以来自2002::/16中的地址的SYN分组的形式，没有对最终SYN/ACK的响应
跟随。根据上面援引的试验，这看起来像是实践中的重要问题。
此问题较为复杂，因为存在3个变量：使用协议41过滤器的防火墙可以是无状态的或
有状态的；中继可以从它的本地IPv4地址起源它的分组，或从192.88.99.1；来自该中继的
分组可能须经IPv4入口过滤。如果协议41过滤器是无状态的，6to4绝不会成功。如果它是
有状态的，防火墙将抛弃在相同端口上，来自在出境流量中没有见过的地址的入境分组。在
此情况，如果分组源于192.88.99.1，6to4才会成功。如果中继须经入口过滤，仅来自中继本
地IPv4地址的分组能够被发送。因此，仅有3种组合能够成功：
1）没有协议41过滤器，采用使用中继本地IPv4源地址的中继。
2）没有协议41过滤器，采用使用任播IPv4源地址的中继，不采用入口过滤器。
3）存在有状态协议41防火墙，采用使用任播IPv4源地址的中继，不采用入口过滤器。
3、没有回程应答
如果没有发生出境黑洞问题，即，发出的分组到达预期的本地IPv6目的地，目标系统
将发送应答分组，到2002:c000:2aa::123(在我们上述例子中)。那么，或许成功路由到2002::/16，
或许不成功。如果没有路由到2002::/16，分组将被抛弃(有希望，采用“目的地不可达”)。
按照RFC3056，不愿意的中继“必须不向本地IPv6域通告任何2002::路由前缀”；因此，反
过来，如果通告了此前缀，该中继必须中继分组，不管分组源和目的地是什么。然而，实践
中出现的问题是某些中继拒绝(根据分组的IPv6源地址)它们应当中继的分组。
或者本地IPv6目的地没有到2002::/16的路由，或者本地IPv6目的地有到不愿意的中
继的路由，效果是相同的：所有回程IPv6分组被投入黑洞。虽然没有此问题普遍存在的直
接证据，它在实践中确实存在。
4、长往返时间(round-trip time, RTT)
如果上述3个问题没有一个适用，并且6to4主机和本地主机间双向路径事实上存在，
往返时间(RTT)可能很长并且可变，因为到两个中继的路径是没有管理的并可能很复杂。超
载的中继或许也引起RTT频繁改变。
5、PMTU失败
在今天的互联网上观察到的普通链路MTU长度是1500字节。然而，当使用6to4时，
因为存在封装首部，路径MTU小于此值。于是，6to4用户通常看见的链路MTU小于1500，
但是本地IPv6服务器看见的是1500。已经观察到，路径MTU发现(PMTUD)不总在工作，
这会导致连接失败。即使TCP SYN/ACK交换工作，具有全尺寸净荷的TCP分组或许被简
单丢弃。在某些情况，由于TCP最大段长度(TCP Maximum Segment Size, MSS)协商机制
[RFC-2923]失败，会明显恶化此问题。
这些失败是令人不安的，甚至是对于被通知的用户，因为标准的从用户到服务器的“ping”
将成功，ping产生很小的分组，成功的SYN/ACK交换能够被跟踪。同样，失败可能在某些
路径上发生，但是在其他路径上不发生，所以用户或许能够从一个站点得到网页，但是仅仅
能够ping另一个。
此外，如果路由器开启了6to4并且路由器在LAN上通告最终的前缀，但是没有也通告
较小的MTU，也会出现问题；在此情况，TCP MSS协商一定失败。
6、反向DNS失败
典型情况，采用6to4地址的主机没有反向DNS委任(delegation)。如果使用反向DNS
作为伪安全检验，检验将失败。
7、虚假地址失败
根据设计，如果可获得的V4ADDR是私有地址[RFC-1918]，6to4不工作，并且将不会
激活自己。然而，如果可获得的V4ADDR是“赝品”，即，被运营商用作私有地址的全球
地址，6to4也不工作。可举例的一种普通情况是传统无线网，它使用1.1.1.0/24(仿佛它是私
有地址)。在此情况，6to4将假设它自己被连接到全球互联网，但是一定不存在工作的返回
路径。
如果ISP正在它的用户和互联网间运行运营商级NAT(Carrier Grade NAT, CGN)，正在
把全球公共地址空间当作是私有空间使用，此失败模式也将发生。
8、有错误的6to4实现
有报告称某些6to4实现尝试甚至当可获得的IPv4地址是RFC1918地址时，也启动自
己。这直接违背RFC3056，并将一定产生与虚假地址失败相同的失败。当然，它超出ISP
的控制。
9、错误诊断困难
上述所有失败模式的存在自身产生一个问题：错误诊断非常困难，尤其是如果用户报告
的现象仅是访问网页慢，由退回IPv4前的长超时引起。向下跟踪任播路由问题和跟踪
PMTUD失败特别困难。
这些问题绝不是普遍的，因为同时有大量的任播6to4被成功应用，已经监测了上述问
题的实践影响，监测基数为尝试连接到双栈内容服务器的1%失败中的一部分[Anderson]。
这是因为少部分用户主机打算使用6to4连接，最多为上述失败模式经历者的20%。虽然这
似乎较低，它对内容提供商而言在财务上需要重视。同样，端用户遇到由返回到IPv4连接
引起的过长响应时间[EYEBALLS-IPV6]挫折后，他们很可能拨打在线帮助呼叫，造成值班
人员成本增加。
顺带说一下，存在由6to4引起的完全不同的运行问题，按照南安普顿大学Tim Chown
和James Morse的观察，在其他站点，流氓路由器通告[RFC-6104]常常传送2002::/16前缀。
这好像是由充当本地IPv6路由器或连接共享设备的设备，在错误接口上发布路由器通告
(Router Advertisement, RA)消息造成的。这样的设备，如果它获得经上行链路到互联网的IPv6
连接，应当仅在它到节点的下行链路上发布相应RA消息，目的是共享它的互联网连接。在
上行链路上发布RA消息将搅乱该链路上任何其他IPv6主机。如果显示这个错误行为的设
备上的6to4路由为默认打开，最终流氓RA消息的确将传送2002::/16前缀。
第4章 咨询指南
在任播6to4场景，涉及几类运营商，愿意或不愿意，并且如果事情搞糟大家都会受影
响。
为了避免运营问题和用户不满，每个运营商明显有动机采取适当行动，如下所述。
本文件避免形式上的规范语言，因为它非常像通用准则。每个运营商将自己做决定，在
下述准则中选择适合自己的内容。
4-1 供应商问题
虽然本文件主要关注运营商，但也存在一些6to4实现者和供应商应当采取的步骤。
1、某些路由器(包括用户驻地设备)供应商，在他们的产品中不仅支持6to4，而且默认设置
开启6to4。这不是好的做法，开启6to4应当总是由用户认真考虑后决策。上述问题中不少
仅由于非有意部署6to4引起。
2、类似，主机操作系统不应当设置任播6to4为默认；它应当总是留给用户开启。
3、当可得到的IPv4地址是RFC1918地址时，尝试激活自己的任何6to4实现是错误的，需
要被更新。
4、6to4实现应当采纳升级的IETF关于地址选择建议[RFC-3484-REVISE]。
5、6to4中继实现必须仔细遵循[RFC-4213]第3-2节，以便确保正确处理MTU问题。
6、6to4路由器或共享连接实现必须避免发布流氓RAs[RFC-6104]。此外，如果站点出于互
联网连接共享目的开启6to4，并且该站点支持[RFC-4191]，那么该站点应当设置RA路由器
优先权位为11(低优先权)。
4-2 不以任何方式支持IPv6的用户ISPs及企业网络
4-2-1 任播地址可用性
为了减少用户部署(或许无意识)任播6to4的负面影响，及随后发生的用户不满和在线帮
助呼叫，这些ISPs应当顺序检验：
1、ISP有到192.88.99.1的路由吗？(这意味着一条显示路由，或默认的上游提供者有显示路
由的知识。默认路由不计入！)
2、如果有，该路由是起作用和稳定的吗？
3、如果是，ping操作时间合理短吗？
4、如果是，该中继愿意从该ISP的IPv4前缀接收6to4流量吗？(注意，这是管理的也是技
术的问题：中继的运营商愿意接收此流量吗？)
除非对所有这些问题的回答都是“yes”，否则运营商应当考虑阻断到192.88.99.1的路
由，并生成IPv4“目的地不可达”消息。这或许导致某些6to4实现更快地退回到IPv4。然
而，对此的运行经验很少。
某些实现也执行某种形式的6to4中继资格证书。例如，主机实现(Windows)通过发送带
有Hop Limit=1的ICMPv6 echo请求到该中继，检测协议41可达性，盼望返回一个响应或
Hop Limit超过出错。如没有任何响应则表示该6to4中继不工作，所以6to4被关闭 [Savola]。
对于这样ISP的更具建设性方法是找到发送提供者，该提供者的确愿意提供出境6to4中继
服务，所以对上述每个询问的回答是肯定的。
4-2-2 协议41
这一等级的ISPs应当总是允许协议41通过他们的网络和防火墙。这不仅是6to4工作
的必要条件，而且这也允许希望使用配置的IPv6隧道服务的用户这样做。
某些运营商，尤其是企业网络，以安全为理由静默阻断协议41。独自这样做是坏的实
践，因为这将造成问题并伤害任何正在有意或无意尝试运行6to4的用户。有战略眼光的解
决方案是部署本地IPv6，进行协议41备份。短期内，通过允许某些用户使用协议41，同时
返回如上面提到的适当ICMP响应，鼓励试验。不幸的是，如果不这样做，6to4问题不能被
解决。
4-2-3 IPv4前缀问题
运营商应当绝对不使用“虚假的”地址空间，诸如针对用户的1.1.1.0/24例子，因为IPv4
耗尽意味着所有这样的地址极有可能在不远的将来被实际应用。(参阅[RFC-6269]) 不能立
即抛弃这种做法的运营商应当确保192.88.99.1生成IPv4“目的地不可达”消息。已经建议
运营商也可以在那个地址运行虚拟6to4中继，在该地址总是返回ICMPv6“目的地不可达”
消息作为6to4分组。然而，这些技术不是非常有效，因为大多数目前的端用户6to4实现将
忽略它们。
如果运营商正在提供合法的全球地址给用户(既不是RFC1918地址，也不是虚假的地址)，
并且在这个地址空间和互联网全球地址空间之间也运行运营商级NAT(大规模NAT)，那么
6to4不能正常工作。这样的运营商也应当务必返回针对6to4流量的“目的地不可达”消息。
作为替代，这样的运营商能够提供未翻译的地址空间给关注的用户。
4-2-4 DNS问题
有意使用6to4的用户可能也需要生成AAAA记录，并且运营商应当能够支持这样做，
即使DNS服务自身在IPv4上单独运行。然而，应当建议用户仔细考虑，是否他们的6to4
服务对此是充分可靠的。
从原理上说，运营商能够提供针对6to4用户的反向DNS支持[RFC-5158]，尽管这对本
地用户不是直截了当的。
4-2-5 流氓路由器通告
荒谬的是，此类运营商应当考虑是否他们需要防范流氓IPv6 RA消息[RFC-6105]，因为
这样的消息可能从力图作为6to4路由器运行的设备中出现，并扰乱任何将启动IPv6作为默
认配置的用户设备。最终，IETF源地址确认改善(Source Address Validation Improvement,
SAVI)工作组正在设计解决此问题的措施。短期内，IPv4-only运营商可以选择在他们的访问
设备中过滤掉具有IPv6
Ethertype (0x86DD)的分组；这将最终移去流氓RA分组。
4-2-6 IPv6部署规划
对所有端系统有完整管理控制的企业运营商，可以选择在那些端系统中关闭6to4，作为
他们部署IPv6整个规划的一部分。
某些IPv4运营商选择安装6to4中继，经IPv6-in-IPv4隧道连接到IPv6运营商，作为本
地IPv6部署前的第一步。他们可使用第4-4节介绍的路由准则。然而，向感兴趣的用户提
供真正的IPv6服务，即使是通过隧道，通常是更好的第一步。
4-3 支持IPv6的用户ISPs及企业网络
一旦运营商支持IPv6服务，无论是试验性质的还是正式营运的，几乎可以肯定用户将
获得比继续使用6to4更好的体验。因此，鼓励这些运营商劝说他们的用户关闭6to4，用户
们应当不生成任何6to4地址的DNS记录。
这样的运营商可以自动归属于下述两个类型(传输提供者或内容提供者)之一，第4-4节
或第4-5节介绍的准则分别适用他们。
此类运营商应当确信没有路由器被无意或默认设置为开启6to4中继。缺乏管理的6to4
中继是产生问题的根源。
此类运营商应当考虑是否他们需要采用RA(Router Advertisement) Guard解决方案
[RFC-6105]防御流氓RA消息。如果RA Guard不能得到，在某些情况下，如果每个LAN支
持至少一个合法的IPv6路由器[RFC-4191]并设置RA路由器优先权位为01(高优先权)，或
许有帮助。最终，IETF源地址确认改善(Source Address Validation Improvement, SAVI)工作
组正在设计解决此问题的措施。
4-4 传输ISPs和互联网交换点
我们假设传输ISPs有IPv6连接。为了在所有传输ISPs的用户网络上减少任播6to4的
负面影响，强烈建议这些ISPs中的每一个都运行任播6to4中继服务。这样做有附加优点，
传输ISPs将端接6to4 IPv4分组，接着能够按照他们自己的策略转发解封装的IPv6流量。
否则，他们将盲目地转发所有封装的IPv6流量到运行中继的竞争者。
虽然大多数现代互联网交换点(Internet exchange point, IXP)不提供IP层服务，出于对它
的用户利益考虑，互联网交换点可以选择运行任播6to4中继服务。如果这样，它应当遵循
本节建议。
仔细管理到这个服务的路由非常重要：
1、必须仅向用户IPv4网络(它的出境6to4分组将被接收)通告IPv4前缀192.88.99.0/24。
2、IPv6前缀2002::/16必须向本地IPv6通告。中继必须接收抵达它的、朝向2002::/16的所
有流量，所以此通告到达的范围应当仔细规划。此通告必须到达传输ISP的所有用户IPv6
网络。如果此通告到达更宽的范围，中继将为非用户提供免费搭车。
3、正如第3节第2款(入境黑洞。译者)中讨论的，当中继反过来向6to4用户发送6to4分组
时，很重要的是选择使用的IPv4源地址。最佳选择很可能是192.88.99.1，不是该中继的单
播IPv4地址， 除非入口过滤是一个问题。这将避免失败，如果用户在有状态防火墙之后。
4、中继应当能够正确响应封装在IPv4协议41中的ICMPv6 echo请求，典型采用外层目的
地地址192.88.99.1和内层目的地地址
2002:c058:6301::。
(正如前面提到，已知某些6to4
主机发送带有Hop Limit = 1的echo请求，这使这些主机在任何情况下能够快速检测到中继
是否存在，但是运营商不能依靠这个行为。)
5、在任何IPv4网络或防火墙中，必须不过滤协议41。
6、考虑一般实践，上一款内容是6to4正常工作的基础，IPv6 PMTUD必须是可能的，这意
味着在任何地方，必须不能阻断ICMPv6 [RFC-4890]。这也要求中继有足够高的ICMP出错
生成门限。对于繁忙的中继，典型的每秒100分组默认速率限制太慢了。在繁忙的中继上，
或许需要1000pps或更高。如果限制ICMPv6“分组太大”出错消息发送速率，用户将遭遇
PMTUD失败。
7、中继必须有适当的性能，并且因为负载预测十分困难，必须能够上调性能，或者更好的
做法，按需配制性能。因为中继处理是无状态的，任何多个中继间的合理负载均衡方法均可
使用。
8、当然，中继必须被直接连接到全球IPv4空间，不使用NAT。
此类运营商应当确信没有路由器被无意或默认设置为激活6to4中继。缺乏管理的6to4
中继是产生问题的根源。
4-5 内容提供商和他们的ISPs
我们假设内容提供商和他们的ISPs有IPv6连接，并且服务器是双栈的。下面内容适用
于内容服务器，但也同样适用于网站托管服务器，构成内容分发网络一部分的服务器，服务
器群前面的负载均衡，以及HTTP存储器。需要避免一种情况，那里采用任播6to4配置的
用户主机，成功发送IPv6分组到服务器，但是6to4返回路径由于上面描述的原因出现故障。
为了避免这种情况，必须有本地设置的6to4中继。建议大型内容提供商运行他们自己的中
继，ISPs在任何情况都应当这样做。从内容服务器到中继必须有2002::/16路由。如前一节
提到的，相应路由通告必须仔细考虑选取范围，因为任何到达2002::/16的流量必须被中继。
这样的中继可以完全专注于返回流量，在此情况，中继不需要响应6to4任播地址。
虽然如此，最合理的做法似乎是：确保当中继反过来发送6to4分组给6to4用户时，这
些分组应当用192.88.99.1作为它们的IPv4源地址(不是该中继的单播IPv4地址)。正如上面
提到的，这在下述情况时将避免出现问题，这种情况是：如果用户在有状态防火墙后面，而
防火墙抛弃来自在出境流量中没有看见过的地址的UDP分组。然而，上行入口过滤不能阻
断192.88.99.1(这需要进行测试)，也是必要的。
不经过仔细设计，返回路径不会尽可能短。最理想的是安排2002::/16通告范围，以便
内容提供商有到中继的短路径，并且中继应当有到ISP边界的短路径。对于发送2002::/16
通告进入BGP4应当谨慎处理；这些通告将变成流量吸铁石。如果每个ISP与它的用户---
内容提供商，一起运行中继，将不存在超过每个ISP自己的用户范围通告他们每一个的需要。
在ISP的IPv4网络或防火墙中，必须不过滤协议41。如果把中继放在内容提供商的防
火墙之外，防火墙可以过滤协议41，如果希望。
中继必须有适当的性能，并且因为负载预测十分困难，必须能够上调性能，或者更好的
做法，按需配制性能。因为中继处理是无状态的，任何多个中继间的合理负载均衡方法均可
使用。
当然，中继必须直接连接到全球IPv4空间，不使用NAT。
可选做法是在内容服务器或第一跳路由器内直接嵌入中继功能。这是直截了当的，因为
通过开启本地6to4接口，并使用该接口路由出境分组到2002::/16能够实现中继功能。(这或
许不允许使用192.88.99.1作为源地址。) 进一步的讨论参阅[Huston-b]。然而，在此情况，
协议41必须得到防火墙允许。
采用嵌入中继功能这一做法的内容提供商，在理论上，也能够接收入境6to4流量。但
这是非常不妥当的，因为，按照6to4规则，内容提供商接着也必须为其他IPv6目的地中继
流量。所以应当不可以经192.88.99.1到达内容提供商。同样，内容提供商应当一定不生成
他们的6to4地址的AAAA记录---他们的入境IPv6访问应当是本地的，并且通告6to4地址
很可能导致单播反向路径转发(uRPF) [RFC-3704]入口过滤问题。
为了避免以上描述的路径MTU问题，内容服务器也应当设置它们的IPv6 MTU为一个
安全值。根据经验，推荐1280字节(IPv6最小允许值)；同样，参阅[Huston-b]。
当然，在任何地方，ICMPv6“分组太大”必须不被阻断，或不受到速率限制[RFC-4890]。
对于6to4用户，反向DNS授权基本没有可能存在，并且对于其他IPv6用户绝不是通用的。
内容提供商(以及，事实上，所有服务提供者)不应当依靠反向DNS授权作为IPv6用户的伪
安全检验。
运营商和内容提供商应当确信，没有路由器因无意或因默认设置而作为激活的6to4中
继。缺乏管理的6to4中继是产生问题的根源。
第5章 由ISPs管理的隧道
有各种方法，诸如隧道代理[RFC-3053]，6rd[RFC-5969]，和层2隧道化协议版本2(Layer
2 Tunneling Protocol version 2, L2TPv2) hub-and-spoke [RFC-5571]，通过它们ISP能够以有管
理的方式为用户提供隧道IPv6服务，在这中间，用户将获得在基于正常供应商全球IPv6前
缀下的IPv6前缀。描述6to4的多数问题在这些场景中不会出现。然而，对于由防火墙后面
的用户使用的IPv6-in-IPv4隧道，IPv4协议41不被阻断是基础。
考虑到一般实践，IPv6 PMTUD必须是可能的，这意味着在任何地方，ICMPv6“分组
太大”必须不被阻断，或不受到速率限制[RFC-4890]。
第6章 安全考虑
在[RFC-6169]中对IPv6-in-IPv4隧道的安全问题作了一般性讨论，[TUNNEL-LOOPS]
讨论可能的恶意循环。[RFC-3964]专门讨论6to4安全。总之，隧道对许多公共安全机制产
生挑战，简单因为可疑分组潜在地被封装在无害的外层分组中。所有这些考虑适用于本文件
讨论的自动机制。然而，应当注意，如果运营商为6to4提供很好管理的服务器和中继，无
封装的IPv6分组将通过良好定义的点(这些服务器和中继的本地IPv6接口)，在这些点可以
运用安全机制。
不分青红皂白阻断协议41的建议，与减轻本文件描述的6to4问题并不是一回事。
第7章 致谢
Useful comments and contributions were made by Emile Aben, Mikael Abrahamsson, Tore
Anderson, Hermin Anggawijaya, Jack Bates, Cameron Byrne, Tim Chown, Remi Despres, Jason
Fesler, Wes George, Philip Homburg, Ray Hunter, Geoff Huston, Eric Kline, Victor Kuarsingh,
Martin Levy, David Malone, Alexey Melnikov, Martin Millnert, Keith Moore, Gabi Nakibly,
Michael Newbery, Phil Pennock, Pekka Savola, Mark Smith, Nathan Ward, James Woodyatt, and
others.
第8章 参考文献
8-1 标准类参考文献
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds",
RFC 3056, February 2001.
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June
2001.
8-2 信息类参考文献
[Aben] Aben, E., "6to4 - How Bad is it Really?", 2010,
.
[Anderson] Anderson, T., "IPv6 dual-stack client loss in Norway", 2010,
/ipv6/>.
[CGN] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida,
"Common requirements for Carrier Grade NAT (CGN)", Work in Progress,
July 2011.
[DNSWHITE] Livingood, J., "IPv6 AAAA DNS Whitelisting Implications", Work in
Progress, June 2011.
[EYEBALLS-IPV6] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Trending Towards Success
with Dual-Stack Hosts", Work in Progress, October 2010.
[HISTORIC] Troan, O., "Request to move Connection of IPv6 Domains via IPv4 Clouds
(6to4) to Historic status", Work in Progress, June 2011.
[Huston-a] Huston, G., "Flailing IPv6", 2010,
.
[Huston-b] Huston, G., "Two Simple Hints for Dual Stack Servers", 2010,
.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear,
"Address Allocation for Private Internets", BCP 5, RFC 1918, February
1996.
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923,
September 2000.
[RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 Tunnel Broker",
RFC 3053, January 2001.
[RFC3484-REVISE] Matsumoto, A., Kato, J., Fujisaki, T., and , "Update to RFC 3484
Default AddressSelection for IPv6", Work in Progress, July 2011.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP
84, RFC 3704, March 2004.
[RFC3964] Savola, P. and C. Patel, "Security Considerations for 6to4", RFC 3964,
December 2004.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific
Routes", RFC 4191, November 2005.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6
Hosts and Routers", RFC 4213, October 2005.
[RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering ICMPv6
Messages in Firewalls", RFC 4890, May 2007.
[RFC5158] Huston, G., "6to4 Reverse DNS Delegation Specification", RFC 5158,
March 2008.
[RFC5571] Storer, B., Pignataro, C., Dos Santos, M., Stevant, B., Toutain, L., and J.
Tremblay, "Softwire Hub and Spoke Deployment Framework with Layer
Two Tunneling Protocol Version 2 (L2TPv2)", RFC 5571, June 2009.
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd) – Protocol Specification", RFC 5969, August 2010.
[RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement Problem
Statement", RFC 6104, February 2011.
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. Mohacsi, "IPv6
Router Advertisement Guard", RFC 6105, February 2011.
[RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security Concerns with IP
Tunneling", RFC 6169, April 2011.
[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues
with IP Address Sharing", RFC 6269, June 2011.
[Savola] Savola, P., "Observations of IPv6 Traffic on a 6to4 Relay", ACM
SIGCOMM CCR 35 (1) 23-28, 2006.
[TUNNEL-LOOPS] Nakibly, G. and F. Templin, "Routing Loop Attack using IPv6 Automatic
Tunnels: Problem Statement and Proposed Mitigations", Work in Progress,
May 2011.
撰写者通讯录
Brian Carpenter
Department of Computer Science
University of Auckland
PB 92019
Auckland, 1142
New Zealand
EMail: ter@
2024年10月2日发(作者：艾耘)
本文翻译者：weicq2000
RFC-6343 6to4部署咨询指南
(2011年8月)
摘要
本文件就(针对IPv6 over IPv4自动隧道化的)6to4技术部署，向网络运营商提供建议。
主要是面向互联网服务提供商(ISPs)，包括还没有对IPv6提供支持的ISPs，以及内容提供商。
也包括对实现者的某些建议。建议的目的是最大程度降低用户不满，和在线帮助(help-desk)
呼叫数量。
本备忘录状态
This document is not an Internet Standards Track specification; it is published for informational
purposes.
This document is a product of the Internet Engineering Task Force (IETF). It represents the
consensus of the IETF community. It has received public review and has been approved for
publication by the Internet Engineering Steering Group (IESG). Not all documents approved by
the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata, and how to provide feedback on
it may be obtained at /info/rfc6343.
版权声明
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights
reserved.
This document is subject to BCP 78 and the IETF Trust’s Legal Provisions Relating to IETF
Documents (/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.
目录
第1章 引言
第2章 工作原理
2-1 路由器6to4
2-2 任播6to4
第3章 观察到的问题
第4章 咨询指南
4-1 供应商问题
4-2 不以任何方式支持IPv6的用户ISPs及企业网络
4-2-1 任播地址可用性
4-2-2 协议41
4-2-3 IPv4前缀问题
4-2-4 DNS问题
4-2-5 流氓路由器通告
4-2-6 IPv6部署规划
4-3 支持IPv6的用户ISPs及企业网络
4-4 传输ISPs和互联网交换点
4-5 内容提供商和他们的ISPs
第5章 由ISPs管理的隧道
第6章 安全考虑
第7章 致谢
第8章 参考文献
8-1 标准类参考文献
8-2 信息类参考文献
撰写者通讯录
第1章 引言
IPv6 over IPv4自动隧道化技术，适合这样情况，那里用户可能希望通过不支持IPv6的
网络，访问基于IPv6的服务。IPv6 over IPv4自动隧道化技术多年前就已经定义了。它被称
作6to4 [RFC-3056] [RFC-3068]，在端系统中得到广泛部署，尤其是在台式机和笔记本电脑
中。同样，大量通用型号CPE路由器支持6to4，一些CPE路由器已经将启动6to4作为默认
配置，这导致终端用户十分广泛地无意识部署6to4。
不幸的是，实践表明该方法在目前的部署中存在问题，可能导致连接失败。这些失败或
者引起反复重试造成的时间耽搁，或者使用户完全放弃试图连接到IPv6服务。在许多情况，
用户可能完全没有意识到在使用6to4；当用户咨询在线帮助时，在线帮助十之八九不能正确
诊断问题。令人无语的是，许多在线帮助简单劝告用户关闭IPv6，于是，击败了为鼓励尽
早采用IPv6所作的全部努力。
此文件的主要目标是针对这种情况，向网络运营商提供比关闭6to4更具建设性的建议。
简单描述工作原理，接着描述观察到的问题，并最终提出有针对性的建议，指出避免问题出
现的可行方法。注意，这些建议的一部分适合还不能支持IPv6的ISPs，因为他们的用户和
在线帮助总之受到很大影响。
其他建议适用于内容提供商和实现者，但是本文件不讨论超出网络运营商范围的内容，
如：
1、操作系统在IPv4和IPv6间对谁更优先，当二者都可用时[RFC-3484, REVISE]。
2、确保应用软件适当地处理连接问题[EYEBALLS-IPV6]。
3、某些内容提供商选择回避问题，除了来自通过资格预审的网络的用户外，对其他用户隐
藏他们的IPv6地址[DNSWHITE]。
参考文献[HISTORIC]建议重新分类6to4为Historic。然而，这不会搬走大量使用6to4
的现存主机和CPE。因此，本文件的建议是保留必须的。
第2章 工作原理
有两种6to4变形，这里分别称为“路由器6to4”和“任播6to4”。为了理解任播6to4，
首先必须要了解路由器6to4。
2-1 路由器6to4
路由器6to4是原始版本，在[RFC-3056]中定义。该模型假设用户站点运行本地IPv6，
但是它的ISP不提供IPv6服务。站点的边界路由器充当6to4路由器。如果边界路由器外部
全球32位IPv4地址是V4ADDR，站点自动继承IPv6前缀2002:V4ADDR::/48。(在RFC3056
中的解释有点混淆，因为该解释指已废除的“最高级别聚合(Top Level Aggregator)”术语。)
在用户站点中将使用前缀2002: V4ADDR::/48，并且代表IPv6服务。
考虑两个这类站点边界路由器，具有全球IPv4地址192.0.2.170和192.0.2.187，因此分
别继承IPv6前缀2002:c000:2aa::/48和2002:c000:2bb::/48。通过在使用协议号为41的IPv4
中封装IPv6分组，路由器们能够交换IPv6分组，并以IPv6分组各自的IPv4地址相互发送
它们。事实上，连接到IPv4网络的任何数量的6to4路由器能够采用此方法直接交换IPv6
分组。
某些6to4路由器也被配置为“中继路由器”。它们的行为如上面刚刚描述的，但是，此
外，它们得到具有正常IPv6前缀的本地IPv6连接。它们通告到2002::/16的IPv6路由。例如，
假设在192.0.2.187的6to4路由器是中继路由器，它的6to4一侧的地址是2002:c000:2bb::1。假
设具有6to4地址2002:c000:2aa::123的主机发送IPv6分组到本地IPv6目的地，例如
2001:db8:123:456::321。假设在192.0.2.170的6to4路由器使它的IPv6默认路由设置为
2002:c000:2bb::1，即，中继。分组将被交付到此中继，被封装在IPv4中。该中继将解封装分
组，并转发分组到应交付的本地IPv6。当远端主机回应时，分组(源2001:db8:123:456::321，
目的地 2002:c000:2aa::123)将发现到2002::/16的路由，因此被交付到6to4中继。处理将倒过
来，分组将被封装并被转发到在192.0.2.170的6to4路由器，完成最终的交付。
注意，此处理不要求在两个方向上使用相同中继。出境分组将被发往随便哪个被配置为
(源路由器中的)默认IPv6路由器的中继，返回的分组将被发往位于远端IPv6主机附近的随
便哪个正在通告到2002::/16路由的中继。
当然，在RFC3056中有更多细节，但这些细节中大部分内容与这里的操作问题无关。
2-2 任播6to4
路由器6to4假设将协同管理和配置6to4路由器和中继。尤其是，6to4站点们需要配置
愿意携带它们的出境流量的中继路由器，该中继路由器变成它们的默认IPv6路由器(除了
2002::/16以外)。任播6to4的目标，在[RFC-3068]中定义，是避免任何这种配置需要。其目
的是使解决方案适于小型或家庭用户，甚至这些用户仅有单个主机或简单的家庭网关而不是
边界路由器。这实现起来非常简单，定义192.88.99.1为6to4中继的默认IPv4地址，因此
2002:c058:6301::为6to4站点的默认IPv6路由器地址。
因为任播6to4隐含有用户站点的默认配置，它不要求任何特殊的用户行动。任播6to4
要求IPv4任播路由位于到中继的恰当位置，该中继位于192.88.99.1。与路由器6to4一样，
不要求返回路径通过相同中继。
第3章 观察到的问题
应当注意到，路由器6to4不是被设计为无管理的解决方案。正好相反：RFC3056包含
大量目的在于避免路由问题的操作建议。实践中，即使有遵循这些建议的路由器6to4部署
也很少。大部分部署的是任播6to4。在此情况，用户站点(或单个主机，或小型宽带网关)发
现，它没有本地IPv6连接，但是它有全球IPv4地址，并且能够解析AAAA质询。因此，
它假设它能够发送6to4分组到192.88.99.1。
根据试验，6to4看来似乎遭受了相当程度的连接失败；参阅[Aben]和[Huston-a]。在连
通大量双栈web服务器的试验中，测量了TCP连接失败率。在这些试验中，当服务器收到
TCP SYN分组并在响应中发送SYN/ACK分组时，用户连接到服务器的尝试被认为已经失
败，但是没有收到ACK分组以便完成初始化TCP三次握手。由Aben实施的试验记录，失
败率介于所有6to4连接尝试的9%到20%之间。由Huston实施的试验记录，失败率介于所
有6to4用户的9%到19%之间。在后一个试验中，进一步注意到，所有失败于使用6to4连
接的6to4用户的65%到80%能够使用IPv4成功连接，而其余用户没有做任何形式的IPv4
连接尝试，成功或失败，使用映射的IPv4地址为源地址。使用嵌入的RFC1918 IPv4地址的
无连接尝试由服务器记录。
对于这种形式的6to4连接失败，存在几个可能原因。原因之一是使用嵌入在6to4地址
中的私有IPv4地址，使得6to4隧道返回路径不能使用，其次是本地过滤器和防火墙抛弃使
用IP协议41的输入IP分组。如果前一种情况普遍存在，作这样的预期是合理的，即预期
相当大比例失败的6to4连接使用了嵌入的IPv4地址，该地址或者是从私有应用(RFC1918)
地址范围提取的，违背RFC3056，或者是从在互联网的IPv4域间路由表中没有宣布的地址
范围中提取的。在由Huston实施的实验中，没有一种情况被观察到存在有意义的数量。此
外，改变实验条件，以便使用返回的6to4隧道，该隧道或者采用双栈服务器的本地IPv4源
地址，或者采用192.88.99.1的IPv4源地址。这两种配置间，在6to4连接失败率上没有观察
到变化；然而，当从本地地址响应时，其他运营商报告了有意义的问题，这些问题是由在用
户站点的有状态防火墙引起的。假设对于返回路径，服务器使用它自己的6to4中继，在成
功的IPv4连接和失败的6to4连接间IP分组自身的唯一区别是IP协议号，对于成功的IPv4
连接协议号是6(TCP)，对于失败的6to4连接协议号是41(IPv6净荷)。从这些实验可得出结
论，6to4连接的高连接失败率的一个很可能原因是靠近端用户的本地过滤器的使用，它阻断
了协议号为41的输入分组，在某些情况，如果源地址不是192.88.99.1，有状态防火墙会使
情况更糟。
在双栈背景中，这个连接失败率事实上由，用户系统从失败中恢复并使用IPv4做一次
成功连接的能力标注。在此情况，对用户系统唯一影响是，因为用户系统在6to4连接尝试
上超时，用7到20秒时间进行IPv4连接导致的延时(参阅[EYEBALLS-IPV6])。
此试验以及进一步的分析显示，与任播6to4有关的特定运行问题包括：
1、出境黑洞
192.88.99.1不生成“目的地不可达”，但是事实上发送到那个地址(即192.88.99.1)的分
组被抛弃。这可以由路由或防火墙配置发生，或者甚至因为分组碰巧到达的中继包含
ACL(Access Control Lists, 译者)，以至于分组被抛弃。
出现这类问题，是因为用户的ISP正在接受一条到192.88.99.0/24的路由，尽管事实上
该路由不去任何有用的地方。或者用户站点或用户的ISP正在抛弃出境协议41流量，或者
上游运营商不愿意接收来自该用户ISP的输入6to4分组。后者表面上与路由器6to4设计兼
容(指RFC3056中的“不愿意中继”)。然而，通告一条到IPv4中192.88.99.0/24的路由的简
单事实，伴随着RFC3068中描述的行为，等同于通告到接受该IPv4路由的所有6to4站点
的默认IPv6路由，这违反了RFC3065的假设。
此问题对于用户的影响是他们的IPv6栈相信它有6to4连接，但是事实上所有输出的
IPv6分组被投入黑洞。此问题的流行程度很难测量，因为最终的IPv6分组绝对不能从外部
观察到。
2、入境黑洞
在此情况，发送到192.88.99.1的6to4分组被正确地交付到6to4中继，返回响应分组，
但是响应分组被入境协议41过滤器抛弃。就用户来说，结果与上一种情况相同：IPv6是黑
洞。据了解，许多企业网络是以此方式建立的。基于此情况的连接尝试可由IPv6服务器操
作者观察到，以来自2002::/16中的地址的SYN分组的形式，没有对最终SYN/ACK的响应
跟随。根据上面援引的试验，这看起来像是实践中的重要问题。
此问题较为复杂，因为存在3个变量：使用协议41过滤器的防火墙可以是无状态的或
有状态的；中继可以从它的本地IPv4地址起源它的分组，或从192.88.99.1；来自该中继的
分组可能须经IPv4入口过滤。如果协议41过滤器是无状态的，6to4绝不会成功。如果它是
有状态的，防火墙将抛弃在相同端口上，来自在出境流量中没有见过的地址的入境分组。在
此情况，如果分组源于192.88.99.1，6to4才会成功。如果中继须经入口过滤，仅来自中继本
地IPv4地址的分组能够被发送。因此，仅有3种组合能够成功：
1）没有协议41过滤器，采用使用中继本地IPv4源地址的中继。
2）没有协议41过滤器，采用使用任播IPv4源地址的中继，不采用入口过滤器。
3）存在有状态协议41防火墙，采用使用任播IPv4源地址的中继，不采用入口过滤器。
3、没有回程应答
如果没有发生出境黑洞问题，即，发出的分组到达预期的本地IPv6目的地，目标系统
将发送应答分组，到2002:c000:2aa::123(在我们上述例子中)。那么，或许成功路由到2002::/16，
或许不成功。如果没有路由到2002::/16，分组将被抛弃(有希望，采用“目的地不可达”)。
按照RFC3056，不愿意的中继“必须不向本地IPv6域通告任何2002::路由前缀”；因此，反
过来，如果通告了此前缀，该中继必须中继分组，不管分组源和目的地是什么。然而，实践
中出现的问题是某些中继拒绝(根据分组的IPv6源地址)它们应当中继的分组。
或者本地IPv6目的地没有到2002::/16的路由，或者本地IPv6目的地有到不愿意的中
继的路由，效果是相同的：所有回程IPv6分组被投入黑洞。虽然没有此问题普遍存在的直
接证据，它在实践中确实存在。
4、长往返时间(round-trip time, RTT)
如果上述3个问题没有一个适用，并且6to4主机和本地主机间双向路径事实上存在，
往返时间(RTT)可能很长并且可变，因为到两个中继的路径是没有管理的并可能很复杂。超
载的中继或许也引起RTT频繁改变。
5、PMTU失败
在今天的互联网上观察到的普通链路MTU长度是1500字节。然而，当使用6to4时，
因为存在封装首部，路径MTU小于此值。于是，6to4用户通常看见的链路MTU小于1500，
但是本地IPv6服务器看见的是1500。已经观察到，路径MTU发现(PMTUD)不总在工作，
这会导致连接失败。即使TCP SYN/ACK交换工作，具有全尺寸净荷的TCP分组或许被简
单丢弃。在某些情况，由于TCP最大段长度(TCP Maximum Segment Size, MSS)协商机制
[RFC-2923]失败，会明显恶化此问题。
这些失败是令人不安的，甚至是对于被通知的用户，因为标准的从用户到服务器的“ping”
将成功，ping产生很小的分组，成功的SYN/ACK交换能够被跟踪。同样，失败可能在某些
路径上发生，但是在其他路径上不发生，所以用户或许能够从一个站点得到网页，但是仅仅
能够ping另一个。
此外，如果路由器开启了6to4并且路由器在LAN上通告最终的前缀，但是没有也通告
较小的MTU，也会出现问题；在此情况，TCP MSS协商一定失败。
6、反向DNS失败
典型情况，采用6to4地址的主机没有反向DNS委任(delegation)。如果使用反向DNS
作为伪安全检验，检验将失败。
7、虚假地址失败
根据设计，如果可获得的V4ADDR是私有地址[RFC-1918]，6to4不工作，并且将不会
激活自己。然而，如果可获得的V4ADDR是“赝品”，即，被运营商用作私有地址的全球
地址，6to4也不工作。可举例的一种普通情况是传统无线网，它使用1.1.1.0/24(仿佛它是私
有地址)。在此情况，6to4将假设它自己被连接到全球互联网，但是一定不存在工作的返回
路径。
如果ISP正在它的用户和互联网间运行运营商级NAT(Carrier Grade NAT, CGN)，正在
把全球公共地址空间当作是私有空间使用，此失败模式也将发生。
8、有错误的6to4实现
有报告称某些6to4实现尝试甚至当可获得的IPv4地址是RFC1918地址时，也启动自
己。这直接违背RFC3056，并将一定产生与虚假地址失败相同的失败。当然，它超出ISP
的控制。
9、错误诊断困难
上述所有失败模式的存在自身产生一个问题：错误诊断非常困难，尤其是如果用户报告
的现象仅是访问网页慢，由退回IPv4前的长超时引起。向下跟踪任播路由问题和跟踪
PMTUD失败特别困难。
这些问题绝不是普遍的，因为同时有大量的任播6to4被成功应用，已经监测了上述问
题的实践影响，监测基数为尝试连接到双栈内容服务器的1%失败中的一部分[Anderson]。
这是因为少部分用户主机打算使用6to4连接，最多为上述失败模式经历者的20%。虽然这
似乎较低，它对内容提供商而言在财务上需要重视。同样，端用户遇到由返回到IPv4连接
引起的过长响应时间[EYEBALLS-IPV6]挫折后，他们很可能拨打在线帮助呼叫，造成值班
人员成本增加。
顺带说一下，存在由6to4引起的完全不同的运行问题，按照南安普顿大学Tim Chown
和James Morse的观察，在其他站点，流氓路由器通告[RFC-6104]常常传送2002::/16前缀。
这好像是由充当本地IPv6路由器或连接共享设备的设备，在错误接口上发布路由器通告
(Router Advertisement, RA)消息造成的。这样的设备，如果它获得经上行链路到互联网的IPv6
连接，应当仅在它到节点的下行链路上发布相应RA消息，目的是共享它的互联网连接。在
上行链路上发布RA消息将搅乱该链路上任何其他IPv6主机。如果显示这个错误行为的设
备上的6to4路由为默认打开，最终流氓RA消息的确将传送2002::/16前缀。
第4章 咨询指南
在任播6to4场景，涉及几类运营商，愿意或不愿意，并且如果事情搞糟大家都会受影
响。
为了避免运营问题和用户不满，每个运营商明显有动机采取适当行动，如下所述。
本文件避免形式上的规范语言，因为它非常像通用准则。每个运营商将自己做决定，在
下述准则中选择适合自己的内容。
4-1 供应商问题
虽然本文件主要关注运营商，但也存在一些6to4实现者和供应商应当采取的步骤。
1、某些路由器(包括用户驻地设备)供应商，在他们的产品中不仅支持6to4，而且默认设置
开启6to4。这不是好的做法，开启6to4应当总是由用户认真考虑后决策。上述问题中不少
仅由于非有意部署6to4引起。
2、类似，主机操作系统不应当设置任播6to4为默认；它应当总是留给用户开启。
3、当可得到的IPv4地址是RFC1918地址时，尝试激活自己的任何6to4实现是错误的，需
要被更新。
4、6to4实现应当采纳升级的IETF关于地址选择建议[RFC-3484-REVISE]。
5、6to4中继实现必须仔细遵循[RFC-4213]第3-2节，以便确保正确处理MTU问题。
6、6to4路由器或共享连接实现必须避免发布流氓RAs[RFC-6104]。此外，如果站点出于互
联网连接共享目的开启6to4，并且该站点支持[RFC-4191]，那么该站点应当设置RA路由器
优先权位为11(低优先权)。
4-2 不以任何方式支持IPv6的用户ISPs及企业网络
4-2-1 任播地址可用性
为了减少用户部署(或许无意识)任播6to4的负面影响，及随后发生的用户不满和在线帮
助呼叫，这些ISPs应当顺序检验：
1、ISP有到192.88.99.1的路由吗？(这意味着一条显示路由，或默认的上游提供者有显示路
由的知识。默认路由不计入！)
2、如果有，该路由是起作用和稳定的吗？
3、如果是，ping操作时间合理短吗？
4、如果是，该中继愿意从该ISP的IPv4前缀接收6to4流量吗？(注意，这是管理的也是技
术的问题：中继的运营商愿意接收此流量吗？)
除非对所有这些问题的回答都是“yes”，否则运营商应当考虑阻断到192.88.99.1的路
由，并生成IPv4“目的地不可达”消息。这或许导致某些6to4实现更快地退回到IPv4。然
而，对此的运行经验很少。
某些实现也执行某种形式的6to4中继资格证书。例如，主机实现(Windows)通过发送带
有Hop Limit=1的ICMPv6 echo请求到该中继，检测协议41可达性，盼望返回一个响应或
Hop Limit超过出错。如没有任何响应则表示该6to4中继不工作，所以6to4被关闭 [Savola]。
对于这样ISP的更具建设性方法是找到发送提供者，该提供者的确愿意提供出境6to4中继
服务，所以对上述每个询问的回答是肯定的。
4-2-2 协议41
这一等级的ISPs应当总是允许协议41通过他们的网络和防火墙。这不仅是6to4工作
的必要条件，而且这也允许希望使用配置的IPv6隧道服务的用户这样做。
某些运营商，尤其是企业网络，以安全为理由静默阻断协议41。独自这样做是坏的实
践，因为这将造成问题并伤害任何正在有意或无意尝试运行6to4的用户。有战略眼光的解
决方案是部署本地IPv6，进行协议41备份。短期内，通过允许某些用户使用协议41，同时
返回如上面提到的适当ICMP响应，鼓励试验。不幸的是，如果不这样做，6to4问题不能被
解决。
4-2-3 IPv4前缀问题
运营商应当绝对不使用“虚假的”地址空间，诸如针对用户的1.1.1.0/24例子，因为IPv4
耗尽意味着所有这样的地址极有可能在不远的将来被实际应用。(参阅[RFC-6269]) 不能立
即抛弃这种做法的运营商应当确保192.88.99.1生成IPv4“目的地不可达”消息。已经建议
运营商也可以在那个地址运行虚拟6to4中继，在该地址总是返回ICMPv6“目的地不可达”
消息作为6to4分组。然而，这些技术不是非常有效，因为大多数目前的端用户6to4实现将
忽略它们。
如果运营商正在提供合法的全球地址给用户(既不是RFC1918地址，也不是虚假的地址)，
并且在这个地址空间和互联网全球地址空间之间也运行运营商级NAT(大规模NAT)，那么
6to4不能正常工作。这样的运营商也应当务必返回针对6to4流量的“目的地不可达”消息。
作为替代，这样的运营商能够提供未翻译的地址空间给关注的用户。
4-2-4 DNS问题
有意使用6to4的用户可能也需要生成AAAA记录，并且运营商应当能够支持这样做，
即使DNS服务自身在IPv4上单独运行。然而，应当建议用户仔细考虑，是否他们的6to4
服务对此是充分可靠的。
从原理上说，运营商能够提供针对6to4用户的反向DNS支持[RFC-5158]，尽管这对本
地用户不是直截了当的。
4-2-5 流氓路由器通告
荒谬的是，此类运营商应当考虑是否他们需要防范流氓IPv6 RA消息[RFC-6105]，因为
这样的消息可能从力图作为6to4路由器运行的设备中出现，并扰乱任何将启动IPv6作为默
认配置的用户设备。最终，IETF源地址确认改善(Source Address Validation Improvement,
SAVI)工作组正在设计解决此问题的措施。短期内，IPv4-only运营商可以选择在他们的访问
设备中过滤掉具有IPv6
Ethertype (0x86DD)的分组；这将最终移去流氓RA分组。
4-2-6 IPv6部署规划
对所有端系统有完整管理控制的企业运营商，可以选择在那些端系统中关闭6to4，作为
他们部署IPv6整个规划的一部分。
某些IPv4运营商选择安装6to4中继，经IPv6-in-IPv4隧道连接到IPv6运营商，作为本
地IPv6部署前的第一步。他们可使用第4-4节介绍的路由准则。然而，向感兴趣的用户提
供真正的IPv6服务，即使是通过隧道，通常是更好的第一步。
4-3 支持IPv6的用户ISPs及企业网络
一旦运营商支持IPv6服务，无论是试验性质的还是正式营运的，几乎可以肯定用户将
获得比继续使用6to4更好的体验。因此，鼓励这些运营商劝说他们的用户关闭6to4，用户
们应当不生成任何6to4地址的DNS记录。
这样的运营商可以自动归属于下述两个类型(传输提供者或内容提供者)之一，第4-4节
或第4-5节介绍的准则分别适用他们。
此类运营商应当确信没有路由器被无意或默认设置为开启6to4中继。缺乏管理的6to4
中继是产生问题的根源。
此类运营商应当考虑是否他们需要采用RA(Router Advertisement) Guard解决方案
[RFC-6105]防御流氓RA消息。如果RA Guard不能得到，在某些情况下，如果每个LAN支
持至少一个合法的IPv6路由器[RFC-4191]并设置RA路由器优先权位为01(高优先权)，或
许有帮助。最终，IETF源地址确认改善(Source Address Validation Improvement, SAVI)工作
组正在设计解决此问题的措施。
4-4 传输ISPs和互联网交换点
我们假设传输ISPs有IPv6连接。为了在所有传输ISPs的用户网络上减少任播6to4的
负面影响，强烈建议这些ISPs中的每一个都运行任播6to4中继服务。这样做有附加优点，
传输ISPs将端接6to4 IPv4分组，接着能够按照他们自己的策略转发解封装的IPv6流量。
否则，他们将盲目地转发所有封装的IPv6流量到运行中继的竞争者。
虽然大多数现代互联网交换点(Internet exchange point, IXP)不提供IP层服务，出于对它
的用户利益考虑，互联网交换点可以选择运行任播6to4中继服务。如果这样，它应当遵循
本节建议。
仔细管理到这个服务的路由非常重要：
1、必须仅向用户IPv4网络(它的出境6to4分组将被接收)通告IPv4前缀192.88.99.0/24。
2、IPv6前缀2002::/16必须向本地IPv6通告。中继必须接收抵达它的、朝向2002::/16的所
有流量，所以此通告到达的范围应当仔细规划。此通告必须到达传输ISP的所有用户IPv6
网络。如果此通告到达更宽的范围，中继将为非用户提供免费搭车。
3、正如第3节第2款(入境黑洞。译者)中讨论的，当中继反过来向6to4用户发送6to4分组
时，很重要的是选择使用的IPv4源地址。最佳选择很可能是192.88.99.1，不是该中继的单
播IPv4地址， 除非入口过滤是一个问题。这将避免失败，如果用户在有状态防火墙之后。
4、中继应当能够正确响应封装在IPv4协议41中的ICMPv6 echo请求，典型采用外层目的
地地址192.88.99.1和内层目的地地址
2002:c058:6301::。
(正如前面提到，已知某些6to4
主机发送带有Hop Limit = 1的echo请求，这使这些主机在任何情况下能够快速检测到中继
是否存在，但是运营商不能依靠这个行为。)
5、在任何IPv4网络或防火墙中，必须不过滤协议41。
6、考虑一般实践，上一款内容是6to4正常工作的基础，IPv6 PMTUD必须是可能的，这意
味着在任何地方，必须不能阻断ICMPv6 [RFC-4890]。这也要求中继有足够高的ICMP出错
生成门限。对于繁忙的中继，典型的每秒100分组默认速率限制太慢了。在繁忙的中继上，
或许需要1000pps或更高。如果限制ICMPv6“分组太大”出错消息发送速率，用户将遭遇
PMTUD失败。
7、中继必须有适当的性能，并且因为负载预测十分困难，必须能够上调性能，或者更好的
做法，按需配制性能。因为中继处理是无状态的，任何多个中继间的合理负载均衡方法均可
使用。
8、当然，中继必须被直接连接到全球IPv4空间，不使用NAT。
此类运营商应当确信没有路由器被无意或默认设置为激活6to4中继。缺乏管理的6to4
中继是产生问题的根源。
4-5 内容提供商和他们的ISPs
我们假设内容提供商和他们的ISPs有IPv6连接，并且服务器是双栈的。下面内容适用
于内容服务器，但也同样适用于网站托管服务器，构成内容分发网络一部分的服务器，服务
器群前面的负载均衡，以及HTTP存储器。需要避免一种情况，那里采用任播6to4配置的
用户主机，成功发送IPv6分组到服务器，但是6to4返回路径由于上面描述的原因出现故障。
为了避免这种情况，必须有本地设置的6to4中继。建议大型内容提供商运行他们自己的中
继，ISPs在任何情况都应当这样做。从内容服务器到中继必须有2002::/16路由。如前一节
提到的，相应路由通告必须仔细考虑选取范围，因为任何到达2002::/16的流量必须被中继。
这样的中继可以完全专注于返回流量，在此情况，中继不需要响应6to4任播地址。
虽然如此，最合理的做法似乎是：确保当中继反过来发送6to4分组给6to4用户时，这
些分组应当用192.88.99.1作为它们的IPv4源地址(不是该中继的单播IPv4地址)。正如上面
提到的，这在下述情况时将避免出现问题，这种情况是：如果用户在有状态防火墙后面，而
防火墙抛弃来自在出境流量中没有看见过的地址的UDP分组。然而，上行入口过滤不能阻
断192.88.99.1(这需要进行测试)，也是必要的。
不经过仔细设计，返回路径不会尽可能短。最理想的是安排2002::/16通告范围，以便
内容提供商有到中继的短路径，并且中继应当有到ISP边界的短路径。对于发送2002::/16
通告进入BGP4应当谨慎处理；这些通告将变成流量吸铁石。如果每个ISP与它的用户---
内容提供商，一起运行中继，将不存在超过每个ISP自己的用户范围通告他们每一个的需要。
在ISP的IPv4网络或防火墙中，必须不过滤协议41。如果把中继放在内容提供商的防
火墙之外，防火墙可以过滤协议41，如果希望。
中继必须有适当的性能，并且因为负载预测十分困难，必须能够上调性能，或者更好的
做法，按需配制性能。因为中继处理是无状态的，任何多个中继间的合理负载均衡方法均可
使用。
当然，中继必须直接连接到全球IPv4空间，不使用NAT。
可选做法是在内容服务器或第一跳路由器内直接嵌入中继功能。这是直截了当的，因为
通过开启本地6to4接口，并使用该接口路由出境分组到2002::/16能够实现中继功能。(这或
许不允许使用192.88.99.1作为源地址。) 进一步的讨论参阅[Huston-b]。然而，在此情况，
协议41必须得到防火墙允许。
采用嵌入中继功能这一做法的内容提供商，在理论上，也能够接收入境6to4流量。但
这是非常不妥当的，因为，按照6to4规则，内容提供商接着也必须为其他IPv6目的地中继
流量。所以应当不可以经192.88.99.1到达内容提供商。同样，内容提供商应当一定不生成
他们的6to4地址的AAAA记录---他们的入境IPv6访问应当是本地的，并且通告6to4地址
很可能导致单播反向路径转发(uRPF) [RFC-3704]入口过滤问题。
为了避免以上描述的路径MTU问题，内容服务器也应当设置它们的IPv6 MTU为一个
安全值。根据经验，推荐1280字节(IPv6最小允许值)；同样，参阅[Huston-b]。
当然，在任何地方，ICMPv6“分组太大”必须不被阻断，或不受到速率限制[RFC-4890]。
对于6to4用户，反向DNS授权基本没有可能存在，并且对于其他IPv6用户绝不是通用的。
内容提供商(以及，事实上，所有服务提供者)不应当依靠反向DNS授权作为IPv6用户的伪
安全检验。
运营商和内容提供商应当确信，没有路由器因无意或因默认设置而作为激活的6to4中
继。缺乏管理的6to4中继是产生问题的根源。
第5章 由ISPs管理的隧道
有各种方法，诸如隧道代理[RFC-3053]，6rd[RFC-5969]，和层2隧道化协议版本2(Layer
2 Tunneling Protocol version 2, L2TPv2) hub-and-spoke [RFC-5571]，通过它们ISP能够以有管
理的方式为用户提供隧道IPv6服务，在这中间，用户将获得在基于正常供应商全球IPv6前
缀下的IPv6前缀。描述6to4的多数问题在这些场景中不会出现。然而，对于由防火墙后面
的用户使用的IPv6-in-IPv4隧道，IPv4协议41不被阻断是基础。
考虑到一般实践，IPv6 PMTUD必须是可能的，这意味着在任何地方，ICMPv6“分组
太大”必须不被阻断，或不受到速率限制[RFC-4890]。
第6章 安全考虑
在[RFC-6169]中对IPv6-in-IPv4隧道的安全问题作了一般性讨论，[TUNNEL-LOOPS]
讨论可能的恶意循环。[RFC-3964]专门讨论6to4安全。总之，隧道对许多公共安全机制产
生挑战，简单因为可疑分组潜在地被封装在无害的外层分组中。所有这些考虑适用于本文件
讨论的自动机制。然而，应当注意，如果运营商为6to4提供很好管理的服务器和中继，无
封装的IPv6分组将通过良好定义的点(这些服务器和中继的本地IPv6接口)，在这些点可以
运用安全机制。
不分青红皂白阻断协议41的建议，与减轻本文件描述的6to4问题并不是一回事。
第7章 致谢
Useful comments and contributions were made by Emile Aben, Mikael Abrahamsson, Tore
Anderson, Hermin Anggawijaya, Jack Bates, Cameron Byrne, Tim Chown, Remi Despres, Jason
Fesler, Wes George, Philip Homburg, Ray Hunter, Geoff Huston, Eric Kline, Victor Kuarsingh,
Martin Levy, David Malone, Alexey Melnikov, Martin Millnert, Keith Moore, Gabi Nakibly,
Michael Newbery, Phil Pennock, Pekka Savola, Mark Smith, Nathan Ward, James Woodyatt, and
others.
第8章 参考文献
8-1 标准类参考文献
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds",
RFC 3056, February 2001.
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June
2001.
8-2 信息类参考文献
[Aben] Aben, E., "6to4 - How Bad is it Really?", 2010,
.
[Anderson] Anderson, T., "IPv6 dual-stack client loss in Norway", 2010,
/ipv6/>.
[CGN] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida,
"Common requirements for Carrier Grade NAT (CGN)", Work in Progress,
July 2011.
[DNSWHITE] Livingood, J., "IPv6 AAAA DNS Whitelisting Implications", Work in
Progress, June 2011.
[EYEBALLS-IPV6] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Trending Towards Success
with Dual-Stack Hosts", Work in Progress, October 2010.
[HISTORIC] Troan, O., "Request to move Connection of IPv6 Domains via IPv4 Clouds
(6to4) to Historic status", Work in Progress, June 2011.
[Huston-a] Huston, G., "Flailing IPv6", 2010,
.
[Huston-b] Huston, G., "Two Simple Hints for Dual Stack Servers", 2010,
.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear,
"Address Allocation for Private Internets", BCP 5, RFC 1918, February
1996.
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923,
September 2000.
[RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 Tunnel Broker",
RFC 3053, January 2001.
[RFC3484-REVISE] Matsumoto, A., Kato, J., Fujisaki, T., and , "Update to RFC 3484
Default AddressSelection for IPv6", Work in Progress, July 2011.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP
84, RFC 3704, March 2004.
[RFC3964] Savola, P. and C. Patel, "Security Considerations for 6to4", RFC 3964,
December 2004.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific
Routes", RFC 4191, November 2005.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6
Hosts and Routers", RFC 4213, October 2005.
[RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering ICMPv6
Messages in Firewalls", RFC 4890, May 2007.
[RFC5158] Huston, G., "6to4 Reverse DNS Delegation Specification", RFC 5158,
March 2008.
[RFC5571] Storer, B., Pignataro, C., Dos Santos, M., Stevant, B., Toutain, L., and J.
Tremblay, "Softwire Hub and Spoke Deployment Framework with Layer
Two Tunneling Protocol Version 2 (L2TPv2)", RFC 5571, June 2009.
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4
Infrastructures (6rd) – Protocol Specification", RFC 5969, August 2010.
[RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement Problem
Statement", RFC 6104, February 2011.
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. Mohacsi, "IPv6
Router Advertisement Guard", RFC 6105, February 2011.
[RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security Concerns with IP
Tunneling", RFC 6169, April 2011.
[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues
with IP Address Sharing", RFC 6269, June 2011.
[Savola] Savola, P., "Observations of IPv6 Traffic on a 6to4 Relay", ACM
SIGCOMM CCR 35 (1) 23-28, 2006.
[TUNNEL-LOOPS] Nakibly, G. and F. Templin, "Routing Loop Attack using IPv6 Automatic
Tunnels: Problem Statement and Proposed Mitigations", Work in Progress,
May 2011.
撰写者通讯录
Brian Carpenter
Department of Computer Science
University of Auckland
PB 92019
Auckland, 1142
New Zealand
EMail: ter@