維基百科

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]。

RFC 6144定義IPv4/IPv6轉換的框架[4]。

隧道中間人

編輯

隧道中間人將IPv6流量封裝在IPv4互聯網的傳輸連結中（通常使用6in4），在IPv4互聯網上建立起IPv6隧道以打通兩個互聯網之間的連接。這些隧道可以通過隧道設置協定（TSP）或AYIYA來管理。[5]

6rd

編輯
主條目：IPv6快速部署

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
 
NAT64 和 DNS64

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

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聯絡到客戶端。

雙棧精簡版

編輯
 
DS-Lite

雙棧精簡版（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 功能從運營商端轉移到客戶端裝置上，通過降低運營商需要管理的 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 中被定性為棄用機制。

參考文獻

編輯
  1. ^ RFC 2765 - 無狀態IP/ICMP轉換演算法(SIIT), E. Normark (February 2000)
  2. ^ RFC 6145 IP/ICMP Translation Algorithm
  3. ^ RFC 6052 - IPv6 Addressing of IPv4/IPv6 Translators
  4. ^ RFC 6144 - Framework for IPv4/IPv6 Translation
  5. ^ RFC:3053
  6. ^ RFC 5569 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)
  7. ^ RFC 5969 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification
  8. ^ Yamamoto, Kazu; Itoh, Jun-ichiro. An IPv6-to-IPv4 Transport Relay Translator. Internet Engineering Task Force. 2001-06 [2023-06-08]. （原始內容存檔於2023-01-28）. 
  9. ^ RFC 6146 Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers
  10. ^ RFC 6147 DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers
  11. ^ Video: 464XLAT Live Demo at World IPv6 Congress in Paris. Internet Society. 3 April 2013 [2020-10-10]. （原始內容存檔於2017-09-13）. 
  12. ^ 464XLAT -- A Solution for Providing IPv4 Services Over and IPv6-only Network. T-Mobile USA. [5 August 2013]. （原始內容存檔於2020-11-12）. 
  13. ^ 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） （英語）. 
  14. ^ Le Faucheur, François; Rosen, Eric. Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop. May 2009. RFC 5549. 
  15. ^ Chroboczek, Juliusz. Pv4 Routes with an IPv6 Next Hop in the Babel Routing Protocol. May 2022. RFC 9229. 
  16. ^ Mark Townsley. Mapping Address + Port (PDF). Cisco. September 24, 2012 [2012-09-25]. （原始內容存檔 (PDF)於2022-12-29）. 
  17. ^ 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
取自 "https://zh.wikipedia.org/w/index.php?title=IPv6过渡机制&oldid=84331289"