test-ipv6.com 对 6to4 的看法
-
缺点
优点
-
6to4 技术能让你通过仅有 IPv4 的网络连接 IPv6 互联网。它的原理在于把 IPv6 数据包嵌入到 IPv4 数据包中，并在一些志愿者的帮助下完成传递。（相关规范见于 RFC 3056。）
在传统的 IPv4 互联网中，你的设备将数据传至你的运营商，再通过另外几个运营商到达目标网站。这种模式下排查网络故障是相当容易的，并且你的运营商有义务处理他们责任范围内的问题。网站与其运营商之间也有类似的合约。
使用非托管的（“自动”创建的或者没有指明网关信息的）6to4 连接时，这个过程就不太一样了。IPv6 信息要先装进 IPv4 数据包中⸺就像把信纸装进信封里一样。这个数据包会被传给“距离最短且可用的”网关，你的运营商可能会架设这种网关，但一般不会，更可能是志愿者为了奉献社会而设的。这个中继点会取出 IPv6 信息，然后把它转发到 IPv6 互联网上。
网站传回的流量也要经历一个类似的过程。目标网站向你自动获得的 IPv6 地址发出的答复，会被导向距其最近的 6to4 中继点。这一过程对你来说完全是不确定的，你甚至搞不清那中继点在哪儿。那个中继点会收下这个 IPv6 数据包，把它装进一个 IPv4 数据包中，再发给你的路由器。
问：这能出什么问题？主要问题包括缺乏服务等级协议与可预测性，以及缺乏判断连接是否正常的机制。
服务等级协议：6to4 中继点是由某些组织自愿设立的。它们使用 BGP 协议（互联网说“我在这！”的方式）来向全世界声明公共网关的存在，可是只有一些中继点能得到妥善管理。但只要有一条路径是离你“最近的”（BGP 网络意义下的，你无法控制），你就只能使用那个中继点。你要访问的那个网站也是一样，他们受到同等的约束，但很可能和你用的不是同一个中继点。如果出现什么问题，就算你或者网站知道问题出在哪，也没有什么好办法去解决它。
Comcast 等运营商正在其网络中部署 6to4 中继点，但即使你的运营商也这么做了，问题还是没完全解决。
一旦开启 6to4，你的电脑就会发现“哇！有 IPv6！”，于是你的浏览器就会想方设法把 IPv6 给用上（只要网站支持）。要是能成功当然很好，可要是失败了，连接就免不了要超时。而浏览器得等好一会儿才舍得放弃 IPv6，回去用 IPv4。这样一来，整个网站就会慢得像是崩溃了一样。
我能用 6to4，但“大数据包”或者 MTU 测试缓慢甚至失败。这是什么问题？使用 6to4 时，IPv6 数据包必须装进一个 IPv4 数据包中，但数据包大小是有上限的，具体限制与运营商和使用的设备有关。
因为有这个最大尺寸，IPv6 数据包必须做得小一些，好让它们能装进适合传输的 IPv4 数据包中。
可接下来，其他网络对包的大小可能有更严格的要求。这个网络可能本身就是一个隧道——运营商有时候必须这么做。问题往往就出在这里。IPv4 隧道会回复你一条信息告诉你数据包太大，但你却收不到这信息。即使你收到了，你的那些 IPv6 数据包也不知情，结果你还是不会减小数据包的大小。
对一些人来说，减小 IPv6 的 MTU 可能会有用。符合标准的最小值是 1280，如果你真想找一个适合你的值，试着在 1400 到 1480 之间取一个。但既然要改 MTU 我建议就用 1280，以免将来麻烦。
听起来你很讨厌 6to4。我讨厌它是因为它是无人管理的。6to4 基本上就是 6in4——加上 IPv4 包头的 IPv6 数据包，而托管的 6in4 服务其实可以做得很好。
test-ipv6.com 的建议是，如果你的运营商没有提供 IPv6 但你有需要，可以考虑托管的 6in4 服务。6in4 用的线路和 6to4 一样，但连接的隧道节点是确定的（而非匿名的）。市面上主要的几家提供商都能提供优质的服务和技术支持，他们也会密切关注中继点的运行状态以保证服务质量。最棒的是，双向流量走的都是同一个中继点，这意味着同一个地方完成了两个方向的转换。这些服务可以考虑：
tunnelbroker.net. 由 Hurricane Electric 运作。test-ipv6.com 的创建者已经用他们的服务两三年了，也注意过延迟的问题（大量使用交互式 SSH 从家里连接到服务器）。此服务需要一个固定的 IPv4 地址（或者相对固定的地址——你随时可以去 tunnelbroker.net 网站更新你的 IP）。另外，Tunnel Broker 是全自动的，一经注册就能立即获得隧道，并配置你的终端。