為了長遠(yuǎn)地解決IP 地址的問題，建設(shè)下一代IPv6 網(wǎng)絡(luò)，發(fā)展IPv6 信息資源，發(fā)展IPv6 用戶勢在必行。10 多年前，業(yè)內(nèi)已經(jīng)認(rèn)識到IPv4 地址枯竭問題，發(fā)明了下一代互聯(lián)網(wǎng)協(xié)議IPv6，該協(xié)議具有2128 個地址空間，從根本上解決了地址耗盡的問題。因特網(wǎng)工程任務(wù)組（IETF）最早推薦從IPv4向IPv6 過渡采用雙棧技術(shù)和隧道技術(shù)，全世界很多運(yùn)營商在不同規(guī)模上進(jìn)行了IPv6 的試驗(yàn)，若干信息提供商也提供了IPv6 的服務(wù)[1]。但截至2012年，全世界IPv6 網(wǎng)的流量平均不到IPv4 的1% 。實(shí)踐表明，升級到雙棧不僅沒有給運(yùn)營上帶來直接的收益，反而影響了用戶的體驗(yàn)。這就是為什么雙棧和隧道技術(shù)應(yīng)用10 多年，卻沒有推動完成IPv4 互聯(lián)網(wǎng)向IPv6互聯(lián)網(wǎng)過渡的原因。從根本上看，網(wǎng)絡(luò)的價值在于其用戶數(shù)。對于新建的IPv6 網(wǎng)絡(luò)，其用戶數(shù)不可能與IPv4互聯(lián)網(wǎng)上的用戶數(shù)可比，如果IPv6 的用戶不能與IPv4 的用戶互聯(lián)互通，則IPv6 網(wǎng)絡(luò)沒有任何存在的價值。因此過渡的核心問題是新建IPv6 網(wǎng)絡(luò)必須與IPv4 互聯(lián)網(wǎng)互聯(lián)互通。兩種不同協(xié)議之間的互聯(lián)互通，只能通過翻譯技術(shù)解決，但是由于IETF 在設(shè)計(jì)IPv6 協(xié)議時，沒有充分意識到與IPv4 協(xié)議兼容的重要性，具有很高的技術(shù)難度。隨著純IPv6 網(wǎng)絡(luò)建設(shè)案例的增多和研究的深入，IETF 在IPv4/IPv6 翻譯技術(shù)，特別是無狀態(tài)翻譯技術(shù)取得了突破性進(jìn)展，形成了系列RFC 標(biāo)準(zhǔn)和工作組草案，為IPv4 到IPv6 過渡提供了新的技術(shù)方案。

1 無狀態(tài)IPv4/IPv6 翻譯技術(shù)

互聯(lián)網(wǎng)的基本特性為“ 無連接”的體系結(jié)構(gòu)，路由器不需要維護(hù)狀態(tài)，IPv4/IPv6 翻譯器本身也是一個路由器，因此無狀態(tài)的IPv4/IPv6 翻譯器對于運(yùn)營商來講更具有價值。同時，無狀態(tài)IPv4/IPv6 翻譯（IVI）技術(shù)具有可擴(kuò)展性、可管理性、安全性好的特點(diǎn)，并支持雙向發(fā)起的通信。IVI 的名稱借用了羅馬數(shù)字的表示方法。在羅馬數(shù)字中IV 表示4，VI 表示6，IVI 表示IPv4 和IPv6 的互聯(lián)互通。

1.1 IPv4/IPv6 翻譯技術(shù)的應(yīng)用場景

由于IPv4 的地址空間為232，IPv6的地址空間為2128，極其懸殊，因此不加限制條件的IPv4/IPv6 翻譯器在理論上講是不可行的。在IETF 標(biāo)準(zhǔn)RFC6144 中定義了IPv4/IPv6 翻譯的8個應(yīng)用場景。翻譯器的兩邊一邊是IPv4 另一邊是IPv6。其變化之一在于哪一邊是自己控制的網(wǎng)絡(luò)，哪一邊是互聯(lián)網(wǎng)。其變化之二在于哪一邊發(fā)起通信。無狀態(tài)IPv4/IPv6 翻譯技術(shù)的應(yīng)用場景如圖1 所示[2]。場景一為IPv6 網(wǎng)絡(luò)上計(jì)算機(jī)發(fā)起對IPv4 互聯(lián)網(wǎng)上計(jì)算機(jī)的訪問，場景二為IPv4互聯(lián)網(wǎng)上計(jì)算機(jī)發(fā)起對IPv6 網(wǎng)絡(luò)上計(jì)算機(jī)的訪問。

圖1無狀態(tài)IPv4/IPv6翻譯技術(shù)的應(yīng)用

場景一和場景二意味著新建純IPv6 網(wǎng)絡(luò)，通過翻譯器XLAT 為IPv6用戶提供對IPv4 互聯(lián)網(wǎng)的通信。無狀態(tài)IPv4/IPv6 翻譯技術(shù)可以適應(yīng)于場景一和場景二，有狀態(tài)IPv4/IPv6 翻譯技術(shù)只能適應(yīng)于場景一。IPv4/IPv6 翻譯技術(shù)的核心是需要解決地址映射和協(xié)議翻譯問題。

1.2 地址映射和域名翻譯由于IPv4 和IPv6 的地址空間差距巨大，用IPv6 表示IPv4 是毫無問題的，可以通過無狀態(tài)的映射方法，映射后的IPv6 地址稱為轉(zhuǎn)換地址。用IPv4 表示IPv6 是難點(diǎn)，可以動態(tài)維護(hù)映射表，作有狀態(tài)的地址映射，或在IPv6 地址中選擇一個子空間通過無狀態(tài)的方法與IPv4 地址映射。映射后的IPv6 地址稱為可譯地址。所有這些地址映射算法均在IETF 標(biāo)準(zhǔn)RFC6052 中定義。嵌入了IPv4 地址的IPv6 地址格式如圖2 所示[3]。

圖2 嵌入了IPv4 地址的IPv6 地址格式

其中Prefix 是IPv6 網(wǎng)絡(luò)前綴，根據(jù)不同的前綴長度，嵌入IPv4 地址，并且在64 至71 位間保持為全0，以便與IPv6 地址結(jié)構(gòu)中的u-bit 兼容。

Suffix 為后綴，在基本的地址映射中為全0，預(yù)留給傳輸層端口的編碼，以便把一個IPv4 地址映射為若干IPv6 地址，達(dá)到高效地、無狀態(tài)地復(fù)用稀缺的公有IPv4 地址資源的目的。此外，RFC6052 要求轉(zhuǎn)換地址和可譯地址使用同樣的前綴（Prefix），從而可以自動獲得最優(yōu)路由。

當(dāng)純IPv6 計(jì)算機(jī)發(fā)起對IPv4 互聯(lián)網(wǎng)的訪問時，必須獲得相應(yīng)的轉(zhuǎn)換地址，這個工作由域名翻譯器DNS64根據(jù)上述映射算法完成，由RFC6147定義[4]。DNS64 是同時接入IPv4 網(wǎng)絡(luò)和IPv6 網(wǎng)絡(luò)的域名服務(wù)器（DNS），能夠把A 記錄動態(tài)翻譯成AAAA 記錄。具體步驟為純IPv6 計(jì)算機(jī)通過DNS64 查詢所需域名的AAAA 記錄，如AAAA 記錄存在，則DNS64 直接返回AAAA 記錄給純IPv6 計(jì)算機(jī)；如AAAA 記錄不存在，則DNS64 查詢域名對應(yīng)的A 記錄，并根據(jù)RFC6052 定義的映射算法，生成AAAA 記錄返回給純IPv6 計(jì)算機(jī)。無狀態(tài)的翻譯器支持IPv4 互聯(lián)網(wǎng)發(fā)起的通信，在這種情況下，需要靜態(tài)配置的DNS46，當(dāng)IPv4 互聯(lián)網(wǎng)上的用戶發(fā)起對IPv6 計(jì)算機(jī)的訪問時，DNS46 則返回對應(yīng)IPv6 計(jì)算機(jī)AAAA 對應(yīng)的A 記錄[5]。

1.3 協(xié)議翻譯

兩種不同協(xié)議棧之間的互聯(lián)互通必須解決的第二個問題是協(xié)議翻譯，所慶幸的是IPv4 和IPv6 之間協(xié)議的差距并不很大，是可譯的。具體協(xié)議翻譯算法由RFC6145 定義，包括版本號映射，IPv4 的服務(wù)類型與IPv6 的流量等級映射，IPv4 的總長與IPv6 的載荷長度映射，IPv4 的存活期與IPv6的轉(zhuǎn)發(fā)計(jì)數(shù)映射，IPv4 的傳輸層協(xié)議與IPv6 的下一個頭映射，IPv4 地址和IPv6 地址映射等[6]。IPv4 與IPv6 協(xié)議翻譯的最大難點(diǎn)是分片處理，因?yàn)镮Pv4 可以支持路由器分片或端系統(tǒng)分片，但I(xiàn)Pv6 僅支持端系統(tǒng)分片。對于IPv4 已經(jīng)分片的分組，IPv6 必須增加分片擴(kuò)展頭，以便端系統(tǒng)重組。此外，IPv4 和IPv6 網(wǎng)絡(luò)所能支持的最大傳輸單元的大?。∕TU）是不同的，同時由于IPv4 的基本頭為20 個字節(jié)，而IPv6 的基本頭為40 個字節(jié)，因此在從IPv4 到IPv6 的翻譯過程中必然遇到MTU 超出的問題。此外，IPv4 的傳輸控制協(xié)議（ICMP）和IPv6 的傳輸控制協(xié)議（ICMPv6）也有很多不同，需要分別處理。

值得指出的是，當(dāng)IPv6 網(wǎng)絡(luò)中的路由器（通常并不使用可譯地址）返回ICMPv6 分組時，翻譯器無法找到對應(yīng)的IPv4 地址，造成翻譯后的ICMP 分組的源地址不可溯源。IETF最新發(fā)布的RFC6791 定義了對這個問題的有效處理方法[7]。

RFC6145 也是有狀態(tài)IPv4/IPv6 翻譯器所依據(jù)的協(xié)議翻譯算法。有狀態(tài)IPv4/IPv6 翻譯器中的狀態(tài)維護(hù)技術(shù)由RFC6146 定義，主要規(guī)定了IPv6地址和端口到IPv4 地址和端口的動態(tài)映射表的生成、維護(hù)和銷毀算法[8]。

2 無狀態(tài)雙重翻譯/封裝技術(shù)（MAP 系列）

IPv4/IPv6 翻譯技術(shù)可以使IPv4 和IPv6 互聯(lián)互通，但仍有3 個問題需要解決。第一個問題是由于IPv4 地址耗盡問題，無狀態(tài)IPv4/IPv6 翻譯必須能夠復(fù)用公有IPv4 地址以高效使用IPv4 地址資源；第二個問題是目前有的應(yīng)用程序并沒有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），也有的應(yīng)用程序嵌入了地址的信息（如Ftp）；第三個問題是對于終端用戶往往需要分配一個64 位的前綴，而不是單個的IPv6 地址。無狀態(tài)雙重翻譯/封裝系列技術(shù)MAP-T/MAP-E 可以解決這些問題。MAP 是Mapping Address and Port 的縮寫，意指無狀態(tài)地對地址和端口進(jìn)行復(fù)用，與雙重翻譯（MAP-T）或封裝（MAP-E）技術(shù)組合，可以解決無狀態(tài)復(fù)用公有IPv4 地址的問題和上述的應(yīng)用程序問題，同時可以支持前綴分配。

MAP-T/MAP-E 目前是IETF 的工作組文檔[9-10]，其他相關(guān)的工作組文檔還有DHCPv6 擴(kuò)展[11]和部署考慮[12]。

2.1 雙重翻譯模式的應(yīng)用場景

無狀態(tài)雙重IPv4/IPv6 翻譯模式（MAP-T）的應(yīng)用場景如圖3 所示。

圖3 無狀態(tài)雙重IPv4/IPv6 翻譯模式的應(yīng)用場景

圖3 中，核心翻譯器稱為BR，對于IPv6 為路由器，對于IPv4 為可以復(fù)用IPv4 地址的IPv4/IPv6 翻譯器。第二次翻譯在家庭網(wǎng)關(guān)CE 上進(jìn)行，CE對于IPv6 為路由器，對于IPv4 為IPv4/IPv6 翻譯器，并且根據(jù)下述端口映射算法對于傳輸層的端口進(jìn)行映射。

IPv6 接入網(wǎng)部署認(rèn)證和IPv6 前綴分配設(shè)備AAA 數(shù)據(jù)庫和DHCPv6 服務(wù)器。IPv6 接入網(wǎng)上可以部署使用可譯地址的純IPv6 服務(wù)器，通過CE 或BR 的一次翻譯能夠?qū)τ谟脩舻募僆Pv4 終端和IPv4 互聯(lián)網(wǎng)上的用戶提供服務(wù)。IPv6 接入網(wǎng)的用戶設(shè)備接到家庭網(wǎng)關(guān)上，可以是純IPv4 終端設(shè)備，它通過CE 一次翻譯訪問網(wǎng)內(nèi)純IPv6 服務(wù)器的信息資源，同時它通過CE 和BR 雙重翻譯訪問IPv4 互聯(lián)網(wǎng)上的信息資源，并與其他用戶互訪。

該用戶設(shè)備還可以是IPv4/IPv6 雙棧終端設(shè)備，直接訪問網(wǎng)內(nèi)和IPv6 互聯(lián)網(wǎng)上的信息資源，并通過CE 和BR 雙重翻譯訪問IPv4 互聯(lián)網(wǎng)上的信息資源，也能與其他用戶互訪。該用戶設(shè)備也可以是純IPv6 終端設(shè)備，直接訪問網(wǎng)內(nèi)和IPv6 互聯(lián)網(wǎng)上的信息資源，通過BR 一次翻譯訪問IPv4 互聯(lián)網(wǎng)上的信息資源，并與其他用戶互訪。

2.2 封裝模式的應(yīng)用場景

封裝模式（MAP-E）的應(yīng)用場景如圖4 所示。

圖4MAP-E 的應(yīng)用場景

圖4 中，核心封裝/解封裝器稱為BR，對于IPv6 為IPv6 路由器，對于IPv4 為可以復(fù)用IPv4 地址的IPv4over IPv6 封裝/解封裝器。家庭網(wǎng)關(guān)CE 對于IPv6 為路由器，對于IPv4 為IPv4 over IPv6 封裝/解封裝器，并且根據(jù)下述端口映射算法對于傳輸層的端口進(jìn)行映射。IPv6 接入網(wǎng)部署認(rèn)證和IPv6 前綴分配設(shè)備AAA 數(shù)據(jù)庫和DHCPv6 服務(wù)器。IPv6 接入網(wǎng)的用戶設(shè)備接到家庭網(wǎng)關(guān)上，可以是純IPv4 終端設(shè)備，它通過CE 和BR 封裝/解封裝訪問IPv4 互聯(lián)網(wǎng)上的信息資源，并與其他用戶互訪；該用戶設(shè)備還可以是IPv4/IPv6 雙棧終端設(shè)備，直接訪問網(wǎng)內(nèi)和IPv6 互聯(lián)網(wǎng)上的信息資源，并過CE 和BR 封裝/解封裝訪問IPv4 互聯(lián)網(wǎng)上的信息資源，也能與其他用戶互訪。值得指出的是，封裝模式MAP-E 無法支持在IPv6 接入網(wǎng)內(nèi)部署純IPv6 服務(wù)器，也不支持可以與IPv4 互聯(lián)網(wǎng)互聯(lián)互通的純IPv6 終端設(shè)備。

2.3 端口映射

MAP 的核心技術(shù)之一是無狀態(tài)地址和端口映射算法，其思想是利用16 位的傳輸層（ 傳輸控制協(xié)議（TCP）、數(shù)據(jù)報(bào)協(xié)議（UDP））端口對于IPv4 地址進(jìn)行擴(kuò)展。不復(fù)用IPv4地址時，一個終端設(shè)備可用的并發(fā)TCP 或UDP 的端口數(shù)為65 536；如復(fù)用比為16，則一個終端可用的并發(fā)TCP 或UDP 的端口數(shù)為4 096；如復(fù)用比為128，則一個終端可用的并發(fā)TCP 或UDP 的端口數(shù)為512。根據(jù)統(tǒng)計(jì)，一個普通終端的并發(fā)TCP 或UDP的端口數(shù)為有限的，因此可以利用無狀態(tài)地址和端口映射算法高效率地復(fù)用公有IPv4 地址資源。在使用無狀態(tài)地址和端口映射算法時，需要給每一個終端定義一個端口標(biāo)識集（PSID），端口標(biāo)識集和可用端口的映射關(guān)系由擴(kuò)展的模算法來決定。

擴(kuò)展的模算法的定義為：

（1）給定PSID，該端系統(tǒng)可以使用的傳輸層端口P 為：P =R ×M ×j +M×K +i ，其中R 為復(fù)用比，M 為連續(xù)端口數(shù)，i 和j 為整數(shù)變量。

（2）給定傳輸層端口P ，該端系統(tǒng)的PSID 為：P = floor（P /M）%R ，其中floor 為只舍不入的取整算法，% 為常規(guī)定義的模運(yùn)算符。

擴(kuò)展的模算法是一個適應(yīng)性很廣的算法，即可以使持有不同PSID終端所使用的傳輸層端口在整個端口空間均勻分布，也可以按塊分布，還可以制訂每一塊包含的連續(xù)端口數(shù)量。此外，擴(kuò)展的模算法還可以支持類似與無分類地址域間路由（CIDR）類似的地址聚類，即對應(yīng)于特定的PSID，可以定義PSID 長度，對于可用端口進(jìn)行聚類使用。

通過擴(kuò)展的模算法，在給定復(fù)用比、連續(xù)端口數(shù)量和端口聚類長度的條件下，可以通過PSID 的值計(jì)算出特定終端可以使用的所有的TCP 或UDP 端口；也可以對于任意給定端口計(jì)算出對應(yīng)的PSID，實(shí)現(xiàn)端系統(tǒng)的無狀態(tài)公有IPv4 地址復(fù)用，因而可以極大地減小管理開銷，并極大地提高安全性和可溯源性。由于ICMP 和ICMPv6 沒有源和目標(biāo)端口的域，只有標(biāo)識域（ID），因此要對標(biāo)識域ID作擴(kuò)展的模算法映射。

2.4 地址格式

MAP 的地址格式是RFC6052 的擴(kuò)展，如圖5 所示。

圖5 MAP 地址格式

與RFC6052 的區(qū)別主要有：

（1）MAP 的地址格式是RFC6052當(dāng)Prefix 長度為64 的一個特例，其Prefix 里包含IPv6 Prefix、EA-bits（由IPv4 子網(wǎng)標(biāo)識和PSID 組成，用于唯一標(biāo)識不同的用戶）和Subnet-id（用于標(biāo)識一個用戶使用的大于等于/64 的IPv6 子網(wǎng)）。

（2）在MAP 中Suffix 不為0，而是嵌入了PSID。

（3）MAP 對于轉(zhuǎn)換地址和可譯地址使用不同的Prefix，以解決為終端用戶分配前綴，而不是響應(yīng)單個地址的要求。

利用EA-bits 可以為每一個家庭網(wǎng)關(guān)CE 分配唯一的Prefix，不使用EA-bits，而為每個CE 分配不同的Prefix 也可以達(dá)到同樣的目的。采用EA-bits 的好處是可以進(jìn)行地址聚類，可擴(kuò)展性好；不采用EA-bits 的好處是IPv6 前綴與IPv4 地址獨(dú)立。這兩種方法各有優(yōu)缺點(diǎn)，可以根據(jù)不同需要進(jìn)行選擇。

2.5 統(tǒng)一雙重翻譯和封裝模式的機(jī)制

無狀態(tài)雙重IPv4/IPv6 翻譯可以支持純IPv4 應(yīng)用程序（如Skype），同時對于嵌入IP 地址的應(yīng)用程序（如Ftp）也不需要IPv4/IPv6 之間的應(yīng)用層網(wǎng)關(guān)（ALG），此外雙重翻譯不需要DNS64 和DNS46。無狀態(tài)雙重翻譯可以看成是具有頭壓縮功能的、無狀態(tài)IPv4 over IPv6 的封裝技術(shù)。無狀態(tài)雙重翻譯技術(shù)（MAP-T）和無狀態(tài)封裝技術(shù)（MAP-E）采用同樣擴(kuò)展的模算法和同樣的地址格式（在封裝模式下BR 地址可以蛻化為單個地址），因此具有眾多的相似性，唯一的不同是數(shù)據(jù)流處理模式。在雙重翻譯模式（MAP-T）下數(shù)據(jù)流的處理依據(jù)為翻譯，由RFC6145 定義，在封裝模式（MAP-E）下數(shù)據(jù)流的處理為數(shù)據(jù)封裝，由RFC2473 定義[13]。

MAP-T 模式的優(yōu)點(diǎn)是可以蛻化為一次翻譯，有利于過渡到純IPv6 網(wǎng)絡(luò)，但仍然保持與IPv4 互聯(lián)網(wǎng)的互聯(lián)互通。同時，在IPv6 接入網(wǎng)內(nèi)的IPv6數(shù)據(jù)報(bào)文沒有封裝的數(shù)據(jù)結(jié)構(gòu)，可以使用IPv6 路由器上的所有網(wǎng)絡(luò)層和傳輸層的管理和控制功能，而MAP-E必須對于數(shù)據(jù)報(bào)文進(jìn)行解封裝，才能進(jìn)行管理和控制。MAP-E 模式的優(yōu)點(diǎn)是可以完全保持IPv4 報(bào)文承載的所有信息，同時不需要對傳輸層的校驗(yàn)和進(jìn)行修改。由于RFC2473 定義的封裝模式與傳輸層的TCP、UDP 均由IPv6 頭結(jié)構(gòu)的下一個頭定義，因此，只有從IPv4 到IPv6 的處理需要定義采用翻譯模式還是封裝模式，從IPv6 到IPv4 的處理可以根據(jù)下一個頭自動適應(yīng)性完成翻譯或封裝模式的選擇。因此，MAP-T 和MAP-E 可以根據(jù)需求靈活配置，其分析參見MAP 測試文檔[14]。

2.6 統(tǒng)一無狀態(tài)/用戶狀態(tài)/有狀態(tài)

無狀態(tài)是指IPv4/IPv6 地址和傳輸層端口之間的映射關(guān)系完全由算法決定，設(shè)備不需要維護(hù)映射狀態(tài)表。有狀態(tài)是指IPv4/IPv6 地址和傳輸層端口之間的映射關(guān)系根據(jù)會話的5 元組動態(tài)生成，設(shè)備需要維護(hù)動態(tài)生成的映射狀態(tài)表。用戶狀態(tài)是指IPv4/IPv6 地址和傳輸層端口之間的映射關(guān)系對于各個用戶定義，設(shè)備只需要維護(hù)用戶映射狀態(tài)表。無狀態(tài)翻譯技術(shù)不僅可以與無狀態(tài)封裝技術(shù)統(tǒng)一起來，也可以與有狀態(tài)的翻譯技術(shù)NAT64 和有狀態(tài)的隧道技術(shù)Dual-stack Lite[15] 統(tǒng)一起來。因此MAP-T/MAP-E 家庭網(wǎng)關(guān)CE，不經(jīng)任何修改就可以與有狀態(tài)翻譯器NAT64 或Dual-stack Lite 的AFTR 完成有狀態(tài)雙重翻譯或有狀態(tài)隧道的功能。由于無狀態(tài)和有狀態(tài)是兩個極端的情況，MAP-T/MAP-E 家庭網(wǎng)關(guān)CE 也可以不經(jīng)任何修改支持任何用戶狀態(tài)的場景。

3 過渡路線圖

雖然IPv4 地址已經(jīng)分配完畢，但全世界IPv6 的普及率仍然非常低。

為了保證全球互聯(lián)網(wǎng)的健康和可持續(xù)發(fā)展，必須制訂正確的過渡路線圖。10 年前IETF 制訂的“ 以雙棧為主，輔之以隧道，在沒有其他選擇時用翻譯”的策略值得反思，理由為：

（1）這一政策在過去10 余年里并沒有完成從IPv4 到IPv6 的過渡。

（2）對于中國這樣的國家，已經(jīng)沒有更多的IPv4 公有地址實(shí)施雙棧，而通過NAT44 利用私有地址實(shí)施雙棧并不能鼓勵I(lǐng)Pv6 的過渡。

隨著無狀態(tài)翻譯技術(shù)（IVI）和無狀態(tài)雙重翻譯技術(shù)（MAP）的成熟，我們建議應(yīng)建設(shè)純IPv6 網(wǎng)絡(luò)，實(shí)施“ 以翻譯技術(shù)為主，輔之以封裝，在沒有其他選擇時用雙棧”的策略。具體技術(shù)方案為：

（1）新建純IPv6 網(wǎng)絡(luò)，當(dāng)通信的對端也為IPv6 是，采用IPv6 通信。

（2）當(dāng)通信的對端為IPv4 是，優(yōu)先采用一次無狀態(tài)IPv4/IPv6 翻譯技術(shù)進(jìn)行通信。

（3）當(dāng)應(yīng)用程序不支持IPv6，或應(yīng)用程序嵌入IPv4 地址時，采用無狀態(tài)雙重IPv4/IPv6 翻譯技術(shù)進(jìn)行通信。

（4）當(dāng)需要保持IPv4 報(bào)文所有的信息，或處理傳輸層加密的報(bào)文，采用封裝技術(shù)進(jìn)行通信。

（5）在過渡的中后期，雙重翻譯將無縫地退化成一次翻譯，最終關(guān)閉一次翻譯器，進(jìn)入純IPv6 時代。

采用以上建議的過渡線路圖，可以使我們自己的網(wǎng)絡(luò)率先過渡到IPv6，并高效地利用公有IPv4 地址資源與IPv4 互聯(lián)網(wǎng)互聯(lián)互通，從而在IPv4 到IPv6 的過渡過程中保持主動。這一技術(shù)方案完全符合中國發(fā)展下一代互聯(lián)網(wǎng)的路線圖和時間表，即“ 在2011—2015 年的過渡階段，政府引導(dǎo)全社會向IPv6 過渡，IPv4 與IPv6 共存，新建網(wǎng)絡(luò)必須為IPv6 并實(shí)現(xiàn)與IPv4 的互通”。目前無狀態(tài)IPv4/IPv6 翻譯技術(shù)（IVI）已經(jīng)發(fā)布5 個IETF 的RFC 標(biāo)準(zhǔn)，MAP 技術(shù)已經(jīng)形成4 個IETF 工作組草案。IVI 技術(shù)已有思科、中興通訊、華為等設(shè)備廠家的產(chǎn)品支持，并在CNGi-CERNET2 上正常運(yùn)行2 年以上。MAP 技術(shù)已有思科等設(shè)備廠家的產(chǎn)品正式發(fā)布，得到意大利電信、日本軟銀、德國電信、美國Charter 等多家國際運(yùn)營商的支持和關(guān)注，產(chǎn)業(yè)鏈正在逐步形成。作為唯一能夠使IPv4 和IPv6 互聯(lián)互通的無狀態(tài)翻譯技術(shù)和雙重翻譯技術(shù)IVI/MAP，預(yù)計(jì)在近幾年會得到大發(fā)展。

參考文獻(xiàn)

[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.