过渡
虽然当时 IPv6 的设计引起了很多关注,但对于网络从 IPv4 向 IPv6 的过渡问题,却没有引起同样的重视。
当时有一种天真的想法,认为既然 IPv4 被广泛采用,IPv6 也会自然而然地流行起来,因此不需要过多考虑过渡过程。最初的设想是,网络、设备和应用程序将同时支持 IPv4 和 IPv6,形成“双栈”(dual stack)环境,然后逐步淘汰 IPv4 的支持。
然而,这个计划中出现了很多问题,最严重的可能是资源分配问题。互联网当时发展非常迅速,大家大部分精力都花在应对日益增长的需求上。更多的用户、更大的容量、更强的服务器、更多的内容和服务、更快的响应、更好的安全性和防御——这些都与一个共同的主题相关:规模化。我们要么集中资源满足规模化的需求,要么致力于部署 IPv6。之前采取的短期和中期措施已经缓解了地址枯竭的紧迫性,所以在优先级上,扩展互联网的规模比 IPv6 过渡更重要。在 1995 年到 2005 年这十年间,IPv6 几乎被业界忽视了。IPv4 地址仍然可用,而无类别域间路由(CIDR)的采用以及更为保守的地址分配策略将 IPv4 地址耗尽的预期推迟了几十年。当时有更多紧迫的操作和政策问题需要行业关注。
然而,这只是暂时的喘息。到 2000 年代中期,随着 iPhone 等智能设备的推出,规模化问题以全新的方式加速。突然间,这不仅仅是数千万或数亿家庭和企业的问题,而是转变为数十亿个人及其设备的规模化挑战,同时还加入了“移动性”的因素。智能设备的生产规模迅速攀升,每年的出货量达到数亿台。这正是 IPv6 被视为必要的原因,但此时我们并没有做好部署 IPv6 的准备。相反,我们加速消耗剩余的 IPv4 地址,并用 IPv4 支持了首批大规模移动服务。当时在移动领域,“双栈”甚至都不是一个可行的选择。由于 3G 基础设施的经济限制,在 3G 平台上部署双栈是不现实的,因此首批移动服务主要依赖 IPv4 和网络地址转换(NAT)。
与此同时,互联网的去中心化特性阻碍了 IPv6 的过渡。如果没有主机支持 IPv6,开发支持 IPv6 的应用程序又有何意义?如果没有互联网服务提供商(ISP)提供 IPv6 支持,主机添加 IPv6 功能又有何用?如果没有主机和应用程序支持 IPv6,ISP 又为何要部署 IPv6?因此,在 IPv6 的过渡过程中,什么也没发生。
打破这种互相依赖僵局的最早尝试来自操作系统开发者,他们将全功能的 IPv6 网络栈集成到不同版本的 Linux、Windows 和 Mac OS 中,iOS 和 Android 的移动网络栈也加入了 IPv6 支持。
然而,即使这样,也不足以推动 IPv6 过渡进入关键阶段。有人认为,这种情况甚至使 IPv6 的过渡更加困难,延缓了数年。问题在于,支持 IPv6 的主机开始希望使用 IPv6,但这些主机就像“IPv6 孤岛”,孤立在 IPv4的“海洋”中。于是,过渡的重点转向了通过 IPv4 网络隧道传输 IPv6 数据包(如图 4 所示)。虽然当你在控制隧道两端时可以手动进行隧道操作,但这种方法并不实用。我们真正需要的是一种自动的隧道机制,能够处理所有这些细节。