基于IPv4 協議的互聯網是世界上最重要的信息基礎設施，但是只有232 個地址空間的IPv4 地址已經分配完畢。為了解決IPv4 地址耗盡問題，目前有兩種技術路線：采用IPv4 地址翻譯技術（NAT44）或升級到IPv6。NAT44 是IPv4 公有地址與IPv4私有地址之間的有狀態翻譯技術，已經非常成熟，但由于其破壞了端到端特性，只能支持單向發起的通信。多年以來，NAT44 在用戶接入端被廣泛使用，但在核心網絡上使用時，需要在NAT44 翻譯器上維護大量狀態。
為了長遠地解決IP 地址的問題，建設下一代IPv6 網絡，發展IPv6 信息資源，發展IPv6 用戶勢在必行。10 多年前，業內已經認識到IPv4 地址枯竭問題，發明了下一代互聯網協議IPv6，該協議具有2128 個地址空間，從根本上解決了地址耗盡的問題。因特網工程任務組（IETF）最早推薦從IPv4向IPv6 過渡采用雙棧技術和隧道技術，全世界很多運營商在不同規模上進行了IPv6 的試驗，若干信息提供商也提供了IPv6 的服務[1]。但截至2012年，全世界IPv6 網的流量平均不到IPv4 的1% 。實踐表明，升級到雙棧不僅沒有給運營上帶來直接的收益，反而影響了用戶的體驗。這就是為什么雙棧和隧道技術應用10 多年，卻沒有推動完成IPv4 互聯網向IPv6互聯網過渡的原因。從根本上看，網絡的價值在于其用戶數。對于新建的IPv6 網絡，其用戶數不可能與IPv4互聯網上的用戶數可比，如果IPv6 的用戶不能與IPv4 的用戶互聯互通，則IPv6 網絡沒有任何存在的價值。因此過渡的核心問題是新建IPv6 網絡必須與IPv4 互聯網互聯互通。兩種不同協議之間的互聯互通，只能通過翻譯技術解決，但是由于IETF 在設計IPv6 協議時，沒有充分意識到與IPv4 協議兼容的重要性，具有很高的技術難度。隨著純IPv6 網絡建設案例的增多和研究的深入，IETF 在IPv4/IPv6 翻譯技術，特別是無狀態翻譯技術取得了突破性進展，形成了系列RFC 標準和工作組草案，為IPv4 到IPv6 過渡提供了新的技術方案。
1 無狀態IPv4/IPv6 翻譯技術
互聯網的基本特性為“ 無連接”的體系結構，路由器不需要維護狀態，IPv4/IPv6 翻譯器本身也是一個路由器，因此無狀態的IPv4/IPv6 翻譯器對于運營商來講更具有價值。同時，無狀態IPv4/IPv6 翻譯（IVI）技術具有可擴展性、可管理性、安全性好的特點，并支持雙向發起的通信。IVI 的名稱借用了羅馬數字的表示方法。在羅馬數字中IV 表示4，VI 表示6，IVI 表示IPv4 和IPv6 的互聯互通。
1.1 IPv4/IPv6 翻譯技術的應用場景
由于IPv4 的地址空間為232，IPv6的地址空間為2128，極其懸殊，因此不加限制條件的IPv4/IPv6 翻譯器在理論上講是不可行的。在IETF 標準RFC6144 中定義了IPv4/IPv6 翻譯的8個應用場景。翻譯器的兩邊一邊是IPv4 另一邊是IPv6。其變化之一在于哪一邊是自己控制的網絡，哪一邊是互聯網。其變化之二在于哪一邊發起通信。無狀態IPv4/IPv6 翻譯技術的應用場景如圖1 所示[2]。場景一為IPv6 網絡上計算機發起對IPv4 互聯網上計算機的訪問，場景二為IPv4互聯網上計算機發起對IPv6 網絡上計算機的訪問。
圖1無狀態IPv4/IPv6翻譯技術的應用
場景一和場景二意味著新建純IPv6 網絡，通過翻譯器XLAT 為IPv6用戶提供對IPv4 互聯網的通信。無狀態IPv4/IPv6 翻譯技術可以適應于場景一和場景二，有狀態IPv4/IPv6 翻譯技術只能適應于場景一。IPv4/IPv6 翻譯技術的核心是需要解決地址映射和協議翻譯問題。
1.2 地址映射和域名翻譯由于IPv4 和IPv6 的地址空間差距巨大，用IPv6 表示IPv4 是毫無問題的，可以通過無狀態的映射方法，映射后的IPv6 地址稱為轉換地址。用IPv4 表示IPv6 是難點，可以動態維護映射表，作有狀態的地址映射，或在IPv6 地址中選擇一個子空間通過無狀態的方法與IPv4 地址映射。映射后的IPv6 地址稱為可譯地址。所有這些地址映射算法均在IETF 標準RFC6052 中定義。嵌入了IPv4 地址的IPv6 地址格式如圖2 所示[3]。
圖2 嵌入了IPv4 地址的IPv6 地址格式
其中Prefix 是IPv6 網絡前綴，根據不同的前綴長度，嵌入IPv4 地址，并且在64 至71 位間保持為全0，以便與IPv6 地址結構中的u-bit 兼容。
Suffix 為后綴，在基本的地址映射中為全0，預留給傳輸層端口的編碼，以便把一個IPv4 地址映射為若干IPv6 地址，達到高效地、無狀態地復用稀缺的公有IPv4 地址資源的目的。此外，RFC6052 要求轉換地址和可譯地址使用同樣的前綴（Prefix），從而可以自動獲得最優路由。
當純IPv6 計算機發起對IPv4 互聯網的訪問時，必須獲得相應的轉換地址，這個工作由域名翻譯器DNS64根據上述映射算法完成，由RFC6147定義[4]。DNS64 是同時接入IPv4 網絡和IPv6 網絡的域名服務器（DNS），能夠把A 記錄動態翻譯成AAAA 記錄。具體步驟為純IPv6 計算機通過DNS64 查詢所需域名的AAAA 記錄，如AAAA 記錄存在，則DNS64 直接返回AAAA 記錄給純IPv6 計算機；如AAAA 記錄不存在，則DNS64 查詢域名對應的A 記錄，并根據RFC6052 定義的映射算法，生成AAAA 記錄返回給純IPv6 計算機。無狀態的翻譯器支持IPv4 互聯網發起的通信，在這種情況下，需要靜態配置的DNS46，當IPv4 互聯網上的用戶發起對IPv6 計算機的訪問時，DNS46 則返回對應IPv6 計算機AAAA 對應的A 記錄[5]。
1.3 協議翻譯
兩種不同協議棧之間的互聯互通必須解決的第二個問題是協議翻譯，所慶幸的是IPv4 和IPv6 之間協議的差距并不很大，是可譯的。具體協議翻譯算法由RFC6145 定義，包括版本號映射，IPv4 的服務類型與IPv6 的流量等級映射，IPv4 的總長與IPv6 的載荷長度映射，IPv4 的存活期與IPv6的轉發計數映射，IPv4 的傳輸層協議與IPv6 的下一個頭映射，IPv4 地址和IPv6 地址映射等[6]。IPv4 與IPv6 協議翻譯的最大難點是分片處理，因為IPv4 可以支持路由器分片或端系統分片，但IPv6 僅支持端系統分片。對于IPv4 已經分片的分組，IPv6 必須增加分片擴展頭，以便端系統重組。此外，IPv4 和IPv6 網絡所能支持的最大傳輸單元的大小（MTU）是不同的，同時由于IPv4 的基本頭為20 個字節，而IPv6 的基本頭為40 個字節，因此在從IPv4 到IPv6 的翻譯過程中必然遇到MTU 超出的問題。此外，IPv4 的傳輸控制協議（ICMP）和IPv6 的傳輸控制協議（ICMPv6）也有很多不同，需要分別處理。
值得指出的是，當IPv6 網絡中的路由器（通常并不使用可譯地址）返回ICMPv6 分組時，翻譯器無法找到對應的IPv4 地址，造成翻譯后的ICMP 分組的源地址不可溯源。IETF最新發布的RFC6791 定義了對這個問題的有效處理方法[7]。
RFC6145 也是有狀態IPv4/IPv6 翻譯器所依據的協議翻譯算法。有狀態IPv4/IPv6 翻譯器中的狀態維護技術由RFC6146 定義，主要規定了IPv6地址和端口到IPv4 地址和端口的動態映射表的生成、維護和銷毀算法[8]。
2 無狀態雙重翻譯/封裝技術（MAP 系列）
IPv4/IPv6 翻譯技術可以使IPv4 和IPv6 互聯互通，但仍有3 個問題需要解決。第一個問題是由于IPv4 地址耗盡問題，無狀態IPv4/IPv6 翻譯必須能夠復用公有IPv4 地址以高效使用IPv4 地址資源；第二個問題是目前有的應用程序并沒有IPv6 的版本（如Skype" style="color: rgb(51, 51, 51); margin: 0px; padding: 0px; line-height: 20px; text-decoration: none; border-bottom-width: 1px; border-bottom-style: dotted; " target="_blank">Skype），也有的應用程序嵌入了地址的信息（如Ftp）；第三個問題是對于終端用戶往往需要分配一個64 位的前綴，而不是單個的IPv6 地址。無狀態雙重翻譯/封裝系列技術MAP-T/MAP-E 可以解決這些問題。MAP 是Mapping Address and Port 的縮寫，意指無狀態地對地址和端口進行復用，與雙重翻譯（MAP-T）或封裝（MAP-E）技術組合，可以解決無狀態復用公有IPv4 地址的問題和上述的應用程序問題，同時可以支持前綴分配。
MAP-T/MAP-E 目前是IETF 的工作組文檔[9-10]，其他相關的工作組文檔還有DHCPv6 擴展[11]和部署考慮[12]。
2.1 雙重翻譯模式的應用場景
無狀態雙重IPv4/IPv6 翻譯模式（MAP-T）的應用場景如圖3 所示。
圖3 無狀態雙重IPv4/IPv6 翻譯模式的應用場景
圖3 中，核心翻譯器稱為BR，對于IPv6 為路由器，對于IPv4 為可以復用IPv4 地址的IPv4/IPv6 翻譯器。第二次翻譯在家庭網關CE 上進行，CE對于IPv6 為路由器，對于IPv4 為IPv4/IPv6 翻譯器，并且根據下述端口映射算法對于傳輸層的端口進行映射。
IPv6 接入網部署認證和IPv6 前綴分配設備AAA 數據庫和DHCPv6 服務器。IPv6 接入網上可以部署使用可譯地址的純IPv6 服務器，通過CE 或BR 的一次翻譯能夠對于用戶的純IPv4 終端和IPv4 互聯網上的用戶提供服務。IPv6 接入網的用戶設備接到家庭網關上，可以是純IPv4 終端設備，它通過CE 一次翻譯訪問網內純IPv6 服務器的信息資源，同時它通過CE 和BR 雙重翻譯訪問IPv4 互聯網上的信息資源，并與其他用戶互訪。
該用戶設備還可以是IPv4/IPv6 雙棧終端設備，直接訪問網內和IPv6 互聯網上的信息資源，并通過CE 和BR 雙重翻譯訪問IPv4 互聯網上的信息資源，也能與其他用戶互訪。該用戶設備也可以是純IPv6 終端設備，直接訪問網內和IPv6 互聯網上的信息資源，通過BR 一次翻譯訪問IPv4 互聯網上的信息資源，并與其他用戶互訪。
2.2 封裝模式的應用場景
封裝模式（MAP-E）的應用場景如圖4 所示。
圖4MAP-E 的應用場景
圖4 中，核心封裝/解封裝器稱為BR，對于IPv6 為IPv6 路由器，對于IPv4 為可以復用IPv4 地址的IPv4over IPv6 封裝/解封裝器。家庭網關CE 對于IPv6 為路由器，對于IPv4 為IPv4 over IPv6 封裝/解封裝器，并且根據下述端口映射算法對于傳輸層的端口進行映射。IPv6 接入網部署認證和IPv6 前綴分配設備AAA 數據庫和DHCPv6 服務器。IPv6 接入網的用戶設備接到家庭網關上，可以是純IPv4 終端設備，它通過CE 和BR 封裝/解封裝訪問IPv4 互聯網上的信息資源，并與其他用戶互訪；該用戶設備還可以是IPv4/IPv6 雙棧終端設備，直接訪問網內和IPv6 互聯網上的信息資源，并過CE 和BR 封裝/解封裝訪問IPv4 互聯網上的信息資源，也能與其他用戶互訪。值得指出的是，封裝模式MAP-E 無法支持在IPv6 接入網內部署純IPv6 服務器，也不支持可以與IPv4 互聯網互聯互通的純IPv6 終端設備。
2.3 端口映射
MAP 的核心技術之一是無狀態地址和端口映射算法，其思想是利用16 位的傳輸層（ 傳輸控制協議（TCP）、數據報協議（UDP））端口對于IPv4 地址進行擴展。不復用IPv4地址時，一個終端設備可用的并發TCP 或UDP 的端口數為65 536；如復用比為16，則一個終端可用的并發TCP 或UDP 的端口數為4 096；如復用比為128，則一個終端可用的并發TCP 或UDP 的端口數為512。根據統計，一個普通終端的并發TCP 或UDP的端口數為有限的，因此可以利用無狀態地址和端口映射算法高效率地復用公有IPv4 地址資源。在使用無狀態地址和端口映射算法時，需要給每一個終端定義一個端口標識集（PSID），端口標識集和可用端口的映射關系由擴展的模算法來決定。
擴展的模算法的定義為：
（1）給定PSID，該端系統可以使用的傳輸層端口P 為：P =R ×M ×j +M×K +i ，其中R 為復用比，M 為連續端口數，i 和j 為整數變量。
（2）給定傳輸層端口P ，該端系統的PSID 為：P = floor（P /M）%R ，其中floor 為只舍不入的取整算法，% 為常規定義的模運算符。
擴展的模算法是一個適應性很廣的算法，即可以使持有不同PSID終端所使用的傳輸層端口在整個端口空間均勻分布，也可以按塊分布，還可以制訂每一塊包含的連續端口數量。此外，擴展的模算法還可以支持類似與無分類地址域間路由（CIDR）類似的地址聚類，即對應于特定的PSID，可以定義PSID 長度，對于可用端口進行聚類使用。
通過擴展的模算法，在給定復用比、連續端口數量和端口聚類長度的條件下，可以通過PSID 的值計算出特定終端可以使用的所有的TCP 或UDP 端口；也可以對于任意給定端口計算出對應的PSID，實現端系統的無狀態公有IPv4 地址復用，因而可以極大地減小管理開銷，并極大地提高安全性和可溯源性。由于ICMP 和ICMPv6 沒有源和目標端口的域，只有標識域（ID），因此要對標識域ID作擴展的模算法映射。
2.4 地址格式
MAP 的地址格式是RFC6052 的擴展，如圖5 所示。
圖5 MAP 地址格式
與RFC6052 的區別主要有：
（1）MAP 的地址格式是RFC6052當Prefix 長度為64 的一個特例，其Prefix 里包含IPv6 Prefix、EA-bits（由IPv4 子網標識和PSID 組成，用于唯一標識不同的用戶）和Subnet-id（用于標識一個用戶使用的大于等于/64 的IPv6 子網）。
（2）在MAP 中Suffix 不為0，而是嵌入了PSID。
（3）MAP 對于轉換地址和可譯地址使用不同的Prefix，以解決為終端用戶分配前綴，而不是響應單個地址的要求。
利用EA-bits 可以為每一個家庭網關CE 分配唯一的Prefix，不使用EA-bits，而為每個CE 分配不同的Prefix 也可以達到同樣的目的。采用EA-bits 的好處是可以進行地址聚類，可擴展性好；不采用EA-bits 的好處是IPv6 前綴與IPv4 地址獨立。這兩種方法各有優缺點，可以根據不同需要進行選擇。
2.5 統一雙重翻譯和封裝模式的機制
無狀態雙重IPv4/IPv6 翻譯可以支持純IPv4 應用程序（如Skype），同時對于嵌入IP 地址的應用程序（如Ftp）也不需要IPv4/IPv6 之間的應用層網關（ALG），此外雙重翻譯不需要DNS64 和DNS46。無狀態雙重翻譯可以看成是具有頭壓縮功能的、無狀態IPv4 over IPv6 的封裝技術。無狀態雙重翻譯技術（MAP-T）和無狀態封裝技術（MAP-E）采用同樣擴展的模算法和同樣的地址格式（在封裝模式下BR 地址可以蛻化為單個地址），因此具有眾多的相似性，唯一的不同是數據流處理模式。在雙重翻譯模式（MAP-T）下數據流的處理依據為翻譯，由RFC6145 定義，在封裝模式（MAP-E）下數據流的處理為數據封裝，由RFC2473 定義[13]。
MAP-T 模式的優點是可以蛻化為一次翻譯，有利于過渡到純IPv6 網絡，但仍然保持與IPv4 互聯網的互聯互通。同時，在IPv6 接入網內的IPv6數據報文沒有封裝的數據結構，可以使用IPv6 路由器上的所有網絡層和傳輸層的管理和控制功能，而MAP-E必須對于數據報文進行解封裝，才能進行管理和控制。MAP-E 模式的優點是可以完全保持IPv4 報文承載的所有信息，同時不需要對傳輸層的校驗和進行修改。由于RFC2473 定義的封裝模式與傳輸層的TCP、UDP 均由IPv6 頭結構的下一個頭定義，因此，只有從IPv4 到IPv6 的處理需要定義采用翻譯模式還是封裝模式，從IPv6 到IPv4 的處理可以根據下一個頭自動適應性完成翻譯或封裝模式的選擇。因此，MAP-T 和MAP-E 可以根據需求靈活配置，其分析參見MAP 測試文檔[14]。
2.6 統一無狀態/用戶狀態/有狀態
無狀態是指IPv4/IPv6 地址和傳輸層端口之間的映射關系完全由算法決定，設備不需要維護映射狀態表。有狀態是指IPv4/IPv6 地址和傳輸層端口之間的映射關系根據會話的5 元組動態生成，設備需要維護動態生成的映射狀態表。用戶狀態是指IPv4/IPv6 地址和傳輸層端口之間的映射關系對于各個用戶定義，設備只需要維護用戶映射狀態表。無狀態翻譯技術不僅可以與無狀態封裝技術統一起來，也可以與有狀態的翻譯技術NAT64 和有狀態的隧道技術Dual-stack Lite[15] 統一起來。因此MAP-T/MAP-E 家庭網關CE，不經任何修改就可以與有狀態翻譯器NAT64 或Dual-stack Lite 的AFTR 完成有狀態雙重翻譯或有狀態隧道的功能。由于無狀態和有狀態是兩個極端的情況，MAP-T/MAP-E 家庭網關CE 也可以不經任何修改支持任何用戶狀態的場景。
3 過渡路線圖
雖然IPv4 地址已經分配完畢，但全世界IPv6 的普及率仍然非常低。
為了保證全球互聯網的健康和可持續發展，必須制訂正確的過渡路線圖。10 年前IETF 制訂的“ 以雙棧為主，輔之以隧道，在沒有其他選擇時用翻譯”的策略值得反思，理由為：
（1）這一政策在過去10 余年里并沒有完成從IPv4 到IPv6 的過渡。
（2）對于中國這樣的國家，已經沒有更多的IPv4 公有地址實施雙棧，而通過NAT44 利用私有地址實施雙棧并不能鼓勵IPv6 的過渡。
隨著無狀態翻譯技術（IVI）和無狀態雙重翻譯技術（MAP）的成熟，我們建議應建設純IPv6 網絡，實施“ 以翻譯技術為主，輔之以封裝，在沒有其他選擇時用雙棧”的策略。具體技術方案為：
（1）新建純IPv6 網絡，當通信的對端也為IPv6 是，采用IPv6 通信。
（2）當通信的對端為IPv4 是，優先采用一次無狀態IPv4/IPv6 翻譯技術進行通信。
（3）當應用程序不支持IPv6，或應用程序嵌入IPv4 地址時，采用無狀態雙重IPv4/IPv6 翻譯技術進行通信。
（4）當需要保持IPv4 報文所有的信息，或處理傳輸層加密的報文，采用封裝技術進行通信。
（5）在過渡的中后期，雙重翻譯將無縫地退化成一次翻譯，最終關閉一次翻譯器，進入純IPv6 時代。
采用以上建議的過渡線路圖，可以使我們自己的網絡率先過渡到IPv6，并高效地利用公有IPv4 地址資源與IPv4 互聯網互聯互通，從而在IPv4 到IPv6 的過渡過程中保持主動。這一技術方案完全符合中國發展下一代互聯網的路線圖和時間表，即“ 在2011—2015 年的過渡階段，政府引導全社會向IPv6 過渡，IPv4 與IPv6 共存，新建網絡必須為IPv6 并實現與IPv4 的互通”。目前無狀態IPv4/IPv6 翻譯技術（IVI）已經發布5 個IETF 的RFC 標準，MAP 技術已經形成4 個IETF 工作組草案。IVI 技術已有思科、中興通訊、華為等設備廠家的產品支持，并在CNGi-CERNET2 上正常運行2 年以上。MAP 技術已有思科等設備廠家的產品正式發布，得到意大利電信、日本軟銀、德國電信、美國Charter 等多家國際運營商的支持和關注，產業鏈正在逐步形成。作為唯一能夠使IPv4 和IPv6 互聯互通的無狀態翻譯技術和雙重翻譯技術IVI/MAP，預計在近幾年會得到大發展。
參考文獻
[1] NORDMARK E, GILLIGAN R. Basic transition" style="color: rgb(51, 51, 51); margin: 0px; padding: 0px; line-height: 20px; text-decoration: none; border-bottom-width: 1px; border-bottom-style: dotted; " target="_blank">transition mechanisms for IPv6 hosts and routers [S].RFC 4213. 2005.
[2] BAKER F, LI X, BAO C, et al. Framework for IPv4/IPv6 Translation [S]. RF C6144. 2011.
[3] BAO C, HUITEMA C, BAGNULO M, et al.IPv6 addressing of IPv4/IPv6 translators [S]. RFC 6052. 2010.
[4] BAGNULO M, SULLIVAN A, MATTHEWS P,et al. DNS64: DNS extensions for network address translation from IPv6 clients to IPv4 servers [S]. RFC 6147. 2011.
[5] LI X, BAO C, CHEN M, et al. The CERNET IVI translation design and deployment for the IPv4/IPv6 coexistence and transition [S]. RFC 6219. 2011.
[6] LI X, BAO C, BAKER F. IP/ICMP translation algorithm [S]. RFC 6145. 2011
[7] LI X, BAO C, WING D, et al. Stateless source address mapping for ICMPv6 packets [S]. RFC 6791. 2012.
[8] BAGNULO M, MATTHEWS P, VAN BEIJNUM I. Stateful NAT64: Network address and protocol translation from IPv6 clients to IPv4 servers [S]. RFC 6146. 2011.
[9] LI X, BAO C, DEC W, et al. Mapping of address and port using translation (MAP-T) [R]. draft-ietf-softwire-map-t-00. 2012.
[10] TROAN O, DEC W, LI X, et al. Mapping of address and port with encapsulation (MAP) [R]. draft-ietf-softwire-map-02. 2012.
[11] MRUGALSKI T, TROAN O, BAO C, et al. DHCPv6 options for mapping of address and port [R]. draft-ietf-softwire-map-dhcp-01. 2012.
[12] SUN" style="color: rgb(51, 51, 51); margin: 0px; padding: 0px; line-height: 20px; text-decoration: none; border-bottom-width: 1px; border-bottom-style: dotted; " target="_blank">SUN Q, CHEN M, CHEN G, et al. Mapping of address and port (MAP) -- Deployment considerations [R]. draft-ietf-softwire-map-deployment-00. 2012.
[13] CONTA A, DEERING S. Generic packet tunneling in IPv6 specification [S]. RFC 2473. 1998.
[14] LI X, BAO C, HAN G, et al. MAP Testing Results [R]. draft-xli-softwire-map-testing-00. 2012.
[15] DURAND A, DROMS R, WOODYATT J, et al. Dual-stack lite broadband" style="color: rgb(51, 51, 51); margin: 0px; padding: 0px; line-height: 20px; text-decoration: none; border-bottom-width: 1px; border-bottom-style: dotted; " target="_blank">broadbanddeployments following IPv4 exhaustion [S] .RFC 6333.2011.