為了長(zhǎng)遠(yuǎn)地解決IP 地址的問題，建設(shè)下一代IPv6 網(wǎng)絡(luò),，發(fā)展IPv6 信息資源,，發(fā)展IPv6 用戶勢(shì)在必行。10 多年前,，業(yè)內(nèi)已經(jīng)認(rèn)識(shí)到IPv4 地址枯竭問題,，發(fā)明了下一代互聯(lián)網(wǎng)協(xié)議IPv6，該協(xié)議具有2128 個(gè)地址空間,，從根本上解決了地址耗盡的問題,。因特網(wǎng)工程任務(wù)組（IETF）最早推薦從IPv4向IPv6 過渡采用雙棧技術(shù)和隧道技術(shù)，全世界很多運(yùn)營(yíng)商在不同規(guī)模上進(jìn)行了IPv6 的試驗(yàn),，若干信息提供商也提供了IPv6 的服務(wù)[1],。但截至2012年，全世界IPv6 網(wǎng)的流量平均不到IPv4 的1% ,。實(shí)踐表明,，升級(jí)到雙棧不僅沒有給運(yùn)營(yíng)上帶來直接的收益，反而影響了用戶的體驗(yàn),。這就是為什么雙棧和隧道技術(shù)應(yīng)用10 多年,，卻沒有推動(dòng)完成IPv4 互聯(lián)網(wǎng)向IPv6互聯(lián)網(wǎng)過渡的原因。從根本上看,，網(wǎng)絡(luò)的價(jià)值在于其用戶數(shù),。對(duì)于新建的IPv6 網(wǎng)絡(luò)，其用戶數(shù)不可能與IPv4互聯(lián)網(wǎng)上的用戶數(shù)可比,，如果IPv6 的用戶不能與IPv4 的用戶互聯(lián)互通,，則IPv6 網(wǎng)絡(luò)沒有任何存在的價(jià)值,。因此過渡的核心問題是新建IPv6 網(wǎng)絡(luò)必須與IPv4 互聯(lián)網(wǎng)互聯(lián)互通。兩種不同協(xié)議之間的互聯(lián)互通,，只能通過翻譯技術(shù)解決,，但是由于IETF 在設(shè)計(jì)IPv6 協(xié)議時(shí)，沒有充分意識(shí)到與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 翻譯器本身也是一個(gè)路由器,，因此無狀態(tài)的IPv4/IPv6 翻譯器對(duì)于運(yùn)營(yíng)商來講更具有價(jià)值,。同時(shí)，無狀態(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)用場(chǎng)景

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

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

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

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

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

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

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

當(dāng)純IPv6 計(jì)算機(jī)發(fā)起對(duì)IPv4 互聯(lián)網(wǎng)的訪問時(shí)，必須獲得相應(yīng)的轉(zhuǎn)換地址,，這個(gè)工作由域名翻譯器DNS64根據(jù)上述映射算法完成,，由RFC6147定義[4]。DNS64 是同時(shí)接入IPv4 網(wǎng)絡(luò)和IPv6 網(wǎng)絡(luò)的域名服務(wù)器（DNS）,，能夠把A 記錄動(dòng)態(tài)翻譯成AAAA 記錄,。具體步驟為純IPv6 計(jì)算機(jī)通過DNS64 查詢所需域名的AAAA 記錄，如AAAA 記錄存在,，則DNS64 直接返回AAAA 記錄給純IPv6 計(jì)算機(jī),；如AAAA 記錄不存在，則DNS64 查詢域名對(duì)應(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ā)起對(duì)IPv6 計(jì)算機(jī)的訪問時(shí)，DNS46 則返回對(duì)應(yīng)IPv6 計(jì)算機(jī)AAAA 對(duì)應(yīng)的A 記錄[5],。

1.3 協(xié)議翻譯

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

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

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

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

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

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

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

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

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

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

IPv6 接入網(wǎng)部署認(rèn)證和IPv6 前綴分配設(shè)備AAA 數(shù)據(jù)庫(kù)和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ù)器的信息資源，同時(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)上的信息資源,，也能與其他用戶互訪,。該用戶設(shè)備也可以是純IPv6 終端設(shè)備，直接訪問網(wǎng)內(nèi)和IPv6 互聯(lián)網(wǎng)上的信息資源,，通過BR 一次翻譯訪問IPv4 互聯(lián)網(wǎng)上的信息資源,，并與其他用戶互訪。

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

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

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

圖4 中,，核心封裝/解封裝器稱為BR，對(duì)于IPv6 為IPv6 路由器,，對(duì)于IPv4 為可以復(fù)用IPv4 地址的IPv4over IPv6 封裝/解封裝器,。家庭網(wǎng)關(guān)CE 對(duì)于IPv6 為路由器，對(duì)于IPv4 為IPv4 over IPv6 封裝/解封裝器,，并且根據(jù)下述端口映射算法對(duì)于傳輸層的端口進(jìn)行映射,。IPv6 接入網(wǎng)部署認(rèn)證和IPv6 前綴分配設(shè)備AAA 數(shù)據(jù)庫(kù)和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））端口對(duì)于IPv4 地址進(jìn)行擴(kuò)展,。不復(fù)用IPv4地址時(shí)，一個(gè)終端設(shè)備可用的并發(fā)TCP 或UDP 的端口數(shù)為65 536,；如復(fù)用比為16,，則一個(gè)終端可用的并發(fā)TCP 或UDP 的端口數(shù)為4 096；如復(fù)用比為128,，則一個(gè)終端可用的并發(fā)TCP 或UDP 的端口數(shù)為512,。根據(jù)統(tǒng)計(jì)，一個(gè)普通終端的并發(fā)TCP 或UDP的端口數(shù)為有限的,，因此可以利用無狀態(tài)地址和端口映射算法高效率地復(fù)用公有IPv4 地址資源,。在使用無狀態(tài)地址和端口映射算法時(shí)，需要給每一個(gè)終端定義一個(gè)端口標(biāo)識(shí)集（PSID）,，端口標(biāo)識(shí)集和可用端口的映射關(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ò)展的模算法是一個(gè)適應(yīng)性很廣的算法,，即可以使持有不同PSID終端所使用的傳輸層端口在整個(gè)端口空間均勻分布，也可以按塊分布,，還可以制訂每一塊包含的連續(xù)端口數(shù)量,。此外，擴(kuò)展的模算法還可以支持類似與無分類地址域間路由（CIDR）類似的地址聚類,，即對(duì)應(yīng)于特定的PSID,，可以定義PSID 長(zhǎng)度，對(duì)于可用端口進(jìn)行聚類使用,。

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

2.4 地址格式

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

圖5 MAP 地址格式

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

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

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

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

利用EA-bits 可以為每一個(gè)家庭網(wǎng)關(guān)CE 分配唯一的Prefix，不使用EA-bits,，而為每個(gè)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）,，同時(shí)對(duì)于嵌入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 地址可以蛻化為單個(gè)地址）,，因此具有眾多的相似性,，唯一的不同是數(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)互通,。同時(shí),，在IPv6 接入網(wǎng)內(nèi)的IPv6數(shù)據(jù)報(bào)文沒有封裝的數(shù)據(jù)結(jié)構(gòu)，可以使用IPv6 路由器上的所有網(wǎng)絡(luò)層和傳輸層的管理和控制功能,，而MAP-E必須對(duì)于數(shù)據(jù)報(bào)文進(jìn)行解封裝,，才能進(jìn)行管理和控制。MAP-E 模式的優(yōu)點(diǎn)是可以完全保持IPv4 報(bào)文承載的所有信息,，同時(shí)不需要對(duì)傳輸層的校驗(yàn)和進(jìn)行修改,。由于RFC2473 定義的封裝模式與傳輸層的TCP、UDP 均由IPv6 頭結(jié)構(gòu)的下一個(gè)頭定義,，因此,，只有從IPv4 到IPv6 的處理需要定義采用翻譯模式還是封裝模式，從IPv6 到IPv4 的處理可以根據(jù)下一個(gè)頭自動(dòng)適應(yīng)性完成翻譯或封裝模式的選擇,。因此,，MAP-T 和MAP-E 可以根據(jù)需求靈活配置，其分析參見MAP 測(cè)試文檔[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ù)會(huì)話的5 元組動(dòng)態(tài)生成，設(shè)備需要維護(hù)動(dòng)態(tài)生成的映射狀態(tài)表,。用戶狀態(tài)是指IPv4/IPv6 地址和傳輸層端口之間的映射關(guān)系對(duì)于各個(gè)用戶定義,，設(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)是兩個(gè)極端的情況,，MAP-T/MAP-E 家庭網(wǎng)關(guān)CE 也可以不經(jīng)任何修改支持任何用戶狀態(tài)的場(chǎng)景。

3 過渡路線圖

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

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

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

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

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

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

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

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

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

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

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