過渡
雖然當時 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 所示)。雖然當你在控制隧道兩端時可以手動進行隧道操作,但這種方法並不實用。我們真正需要的是一種自動的隧道機制,能夠處理所有這些細節。