IPv6過渡機制
| IPv6過渡機制 |
|---|
| 標準 |
| 實驗性 |
| 信息性 |
| 草稿 |
| 已棄用 |
IPv6過渡機制是指那些用來促進互聯網從原有網際協議IPv4向下一代網際協議IPv6過渡的技術。具體來說，由於IPv4和IPv6網絡是互不兼容的，這些技術的主要目的在於使得這兩個網絡中的主機能夠訪問對方網絡。
為了實現IPv6的技術指標，各方必須尋找簡單有效的過渡方案，將現有的網絡從IPv4過渡到IPv6。互聯網工程任務組（IETF）通過使用互聯網草案（I-D）和RFC這些方法來指導相關工作組，並為工作組提供討論與開發這些過渡機制的平台。RFC 4213 定義了一些基礎的IPv6過渡機制。
無狀態IP/ICMP轉換[編輯]
無狀態IP/ICMP轉換（SIIT）是在IPv6和IPv4報文頭格式之間進行轉換。SIIT方法定義一類被稱為IPv4轉換（IPv4-translated）地址的IPv6地址。這類地址的前綴為::ffff:0:0/96，也可被寫作::ffff:a.b.c.d，其中IPv4格式的地址a.b.c.d表示一個使能IPv6（IPv6-enabled）的節點。選擇這個前綴是為了生成一個為0的校驗值，以此來避免改變傳輸協議頭中的校驗值。[1]
此算法可以使IPv6主機無需擁有一個永久的IPv4地址就能與僅有IPv4的主機通信。地址分配和路由的細節並沒有在此規範中被提及。
這個規範由NGTRANS IETF工作組制訂，草案由Sun Microsystems的E. Nordmark於2000年2月作為RFC 2765發布。2011年，RFC 2765被RFC 6145代替[2]。RFC 2765的地址格式化部分被定義在RFC 6052中[3]。
隧道中間人[編輯]
隧道中間人將IPv6流量封裝在IPv4互聯網的傳輸鏈接中（通常使用6in4），在IPv4互聯網上建立起IPv6隧道以打通兩個互聯網之間的連接。這些隧道可以通過隧道設置協議（TSP）或AYIYA來管理。[5]
6rd[編輯]
6rd是一種在ISP的IPv4架構上實現快速部署IPv6服務的機制。它在IPv4與IPv6之間進行無狀態地址映射，並且在用戶節點之間自動建立相關隧道，以允許用戶根據IPv4數據包的形式傳輸IPv6數據部。
此方案在2007年末首次被大規模部署（RFC 5569 [6]）。 RFC 5969[7]詳述了此協議。
傳輸中繼翻譯[編輯]
RFC 3142 定義了 傳輸中繼翻譯（TRT）方法，是最常見的NAT-PT以及NAPT-PT形式。
假設IPv6主機將會發起鏈接，並且目的主機存在於IPv4網絡之中。發起主機上的靜態地址映射表、特殊 DNS 服務器實現或經修改的 DNS 解析器實現，會提供某個特殊形式的IPv6地址作為目的地址。TRT中的中繼（Relay）會將該特殊IPv6地址翻譯成IPv4地址，隨後發起IPv4鏈接至目的主機。這個過程中，路由器會將數據包路由至中繼上，而中繼會持續地將IPv4數據包翻譯成IPv6數據包並發送至IPv6主機（反之亦然），直到兩個主機的會話結束。[8]
NAT64[編輯]
NAT64是一種可以讓IPv6主機與IPv4服務器通信的機制。NAT64服務器需要至少一個IPv4地址和一個32位的IPv6網段（例如：64:ff9b::/96，見 RFC 6052 和 RFC 6146 ）。IPv6客戶端將希望與之通信的IPv4地址嵌入在這32位之中，並將數據包發往生成的地址。NAT64服務器則創建IPv6與IPv4地址間的NAT映射，使得它們可以彼此通信。[9]
DNS64[編輯]
DNS64是指一種專門的DNS服務器，在其處理某個域名的AAAA記錄查詢時，如果該域名僅有A記錄，那麼DNS64會使用該A記錄生成出來一項AAAA記錄。生成出來的IPv6地址前綴指向一個IPv6/IPv4的轉換器，而剩餘32位嵌入了A記錄中的IPv4地址。指向的轉換器通常是一個NAT64服務器。RFC 6147對DNS64標準進行了定義。[10]
這種過渡機制存在兩個值得注意的問題：
- 它只適合使用DNS查找遠程主機地址的場景，無法參與客戶端直接使用IPv4地址的場景。
- DNS64服務器需要返回並非域所有者所指定的記錄，因此如果執行轉換的DNS服務器不是域名所有者的服務器，DNS根的DNSSEC校驗將會失敗。
ISATAP[編輯]
ISATAP是一種IPv6過渡機制，在雙棧節點之間通過IPv4網絡傳輸IPv6數據包。
不同於6over4（較早的基於IPv4多播的類似協議），ISATAP將IPv4用作虛擬的非廣播多路訪問網絡（NBMA）的數據鏈路層，因此底層的IPv4網絡架構無需支持多播。
464XLAT[編輯]
464XLAT（RFC 6877）可以使僅有IPv6網絡上的客戶端訪問僅有IPv4的互聯網服務（例如 Skype）。[11][12]
客戶端通過SIIT轉換器將IPv4數據包轉換成IPv6，然後通過僅有IPv6的網絡將其發送到運營商的NAT64轉換器。NAT64轉換器將IPv6數據包重新轉換回IPv4，最後通過支持IPv4的網絡將其發送到僅有IPv4的服務器。SIIT轉換器（客戶端轉換器，CLAT：Customer-side translator）可以由客戶端自己實現，也可以在支持IPv4的中間設備上實現；NAT64轉換器（服務端轉換器，PLAT：Provider-side translator）必須可以同時聯繫到IPv4網絡上的服務器，以及通過CLAT聯繫到客戶端。
雙棧精簡版[編輯]
雙棧精簡版（Dual-Stack Lite，簡稱DS-Lite） 是一種使用 IPv4-over-IPv6 隧道將 IPv4 數據包發送到運營商來實現 IPv4 私網地址用戶穿越 IPv6 網絡訪問 IPv4 公網的解決方案。
支持此技術的客戶端設備 (CPE) 會將 IPv4 數據包封裝到 IPv6 數據包中，並且將數據包發送至運營商的電信級NAT (CGNAT)。CGNAT 收到數據包後，將其還原為 IPv4 數據包，在進行 NAT 處理後發送到 IPv4 互聯網。 CGNAT 通過記錄 IPv6 源地址、私有 IPv4 地址，以及 TCP 或 UDP 端口號來標識流量。
輕量 4over6 方案 （Lightweight 4over6，簡稱lw4o6） 是 DS-Lite 的一種改進方案，它將 NAT 功能從運營商端轉移到客戶端設備上（CPE），通過降低運營商需要管理的 NAT 狀態來減少運營商的開銷。[13]
v4 經 v6 路由[編輯]
IETF 在 RFC 5549 和 RFC 9229 中定義了一個只將 IPv4 地址分配給終端，而中間路由器只需分配 IPv6 地址的方法，以此降低核心網絡所需的管理量。通過這個方法，IPv4 數據包即使沒有經過封裝或者轉換的過程，也可以正常通過僅有 IPv6 地址的路由器跳轉至下一個站點。[14][15]
MAP[編輯]
MAP（Mapping of Address and Port，地址兼端口映射）是一系列由思科提出的無狀態 IPv4-IPv6-IPv4 雙重轉換技術，存在翻譯（MAP-T）和封裝（MAP-E）兩種版本。[16] 這系列技術根據A+P（Address + Port）的思路，利用了現代網絡下IPv4已然枯竭，但仍存在許多閒置 TCP/UDP 端口的這個特點，將同一個公網 IPv4 地址根據端口範圍繼續細分，並且只為任一用戶下發其中一個範圍（如端口1024-2048或8192-9216）。考慮到IPv6存在一定數量的多餘比特，MAP可以將這些比特空間用來儲存用戶被下發的端口範圍等信息，以達到ISP端無需維持NAT狀態的效果。一些運營商如意大利Sky已經開始將其推廣至大眾用戶。[17]
草案[編輯]
IETF 仍在討論或已放棄以下機制：
4rd[編輯]
IPv4 居家部署（IPv4 Residual Deployment，簡稱4rd）是一項實驗性提案，目的在用於促進跨 IPv6 網絡的 IPv4 服務居家部署。與 6rd 相似，該技術以無狀態的方式進行 IPv6 和 IPv4 地址之間的映射。它支持基於傳輸層端口對 IPv4 網絡進行擴展，是 A+P 模型的無狀態變體。雖然後來衍生出了 MAP-E 和 MAP-T 兩項基於同一理念的技術，但 4rd 至今仍屬於實驗性技術。
棄用機制[編輯]
IETF 已棄用這些機制：
NAT-PT[編輯]
RFC 2766 定義了 Network Address Translation/Protocol Translation (NAT-PT) 這項機制。由於存在許多問題，它已被 RFC 4966 淘汰並且被降級為歷史狀態。這項機制一般與某一 DNS 應用程序級網關 (DNS-ALG) 實現結合使用。
NAPT-PT[編輯]
儘管與 NAT-PT 非常相近，同樣是在 RFC 2766 中被定義的 Network Address Port Translation + Protocol Translation，在網絡地址轉換的基礎上添加了端口的轉換，以避免多個內網用戶同時使用同一個被暴露在外網的端口，導致出現安全性和程序穩定性的問題。這項機制已在 RFC 4966 中被定性為棄用機制。
參考文獻[編輯]
- ^ RFC 2765 - 無狀態IP/ICMP轉換算法(SIIT), E. Normark (February 2000)
- ^ RFC 6145 IP/ICMP Translation Algorithm
- ^ RFC 6052 - IPv6 Addressing of IPv4/IPv6 Translators
- ^ RFC 6144 - Framework for IPv4/IPv6 Translation
- ^ RFC:3053
- ^ RFC 5569 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)
- ^ RFC 5969 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification
- ^ Yamamoto, Kazu; Itoh, Jun-ichiro. An IPv6-to-IPv4 Transport Relay Translator. Internet Engineering Task Force. 2001-06 [2023-06-08]. （原始內容存檔於2023-01-28）.
- ^ RFC 6146 Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers
- ^ RFC 6147 DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers
- ^ Video: 464XLAT Live Demo at World IPv6 Congress in Paris. Internet Society. 3 April 2013 [2020-10-10]. （原始內容存檔於2017-09-13）.
- ^ 464XLAT -- A Solution for Providing IPv4 Services Over and IPv6-only Network. T-Mobile USA. [5 August 2013]. （原始內容存檔於2020-11-12）.
- ^ Cui, Y.; Sun, Q.; Boucadair, M.; Tsou, T.; Lee, Y.; Farrer, I. Lightweight 4over6: An Extension to the Dual-Stack Lite Architecture. 2015-07 [2023-02-13]. doi:10.17487/RFC7596. （原始內容存檔於2023-05-12） （英語）.
- ^ Le Faucheur, François; Rosen, Eric. Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop. May 2009. RFC 5549.
- ^ Chroboczek, Juliusz. Pv4 Routes with an IPv6 Next Hop in the Babel Routing Protocol. May 2022. RFC 9229.
- ^ Mark Townsley. Mapping Address + Port (PDF). Cisco. September 24, 2012 [2012-09-25]. （原始內容存檔 (PDF)於2022-12-29）.
- ^ Richard Patterson. IPv6-Only with MAP-T. Richard Patterson - Sky Italia and MAP-T. RIPE Open House. [2023-06-07]. （原始內容存檔於2023-02-21）.
- IPv6 in Practice, Benedikt Stockebrand (2006), ISBN 3-540-24524-3
- RFC 2767, Bump-in-the-Stack
- RFC 3338, Bump-in-the-API
- RFC 3089, Socks-based Gateway
- RFC 6219, The China Education and Research Network (CERNET) IVI Translation Design and Deployment for the IPv4/IPv6 Coexistence and Transition
| |||||||||||||||||||||||||||