統(tǒng)一的IPv4/IPv6翻譯與封裝過(guò)渡技術(shù)——IVI/MAP—T/MAP—E

摘要：采用無(wú)狀態(tài)翻譯技術(shù)和雙重翻譯/封裝技術(shù)IVI/MAP-T/MAP-E定義IPv4/IPv6地址的映射算法和協(xié)議翻譯/封裝算法，在保持互聯(lián)網(wǎng)地址端對(duì)端的特性的基礎(chǔ)上，使IPv4和IPv6互聯(lián)互通，支持由IPv4和IPv6雙向發(fā)起的訪問(wèn)。無(wú)狀態(tài)翻譯技術(shù)和雙重翻譯/封裝技術(shù)有著不可替代的綜合優(yōu)勢(shì)，是IPv4/IPv6過(guò)渡的必經(jīng)之路。

關(guān)鍵詞： 無(wú)狀態(tài)翻譯；地址映射；協(xié)議翻譯

Abstract： Stateless translation and stateless double translation/encapsulation technologies （IVI/MAP-T/MAP-E） define the address mapping and protocol translation/encapsulation algorithms between IPv4 and IPv6. IVI/MAP-T/MAP-E technologies maintain end-to-end address transparency between IPv4 and IPv6 and support communication between IPv4-only and IPv6-only end systems. IPv4/IPv6 translation is a critical technique for IPv4/IPv6 transition.

Key words： stateless translation； address mapping； protocol translation

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

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

互聯(lián)網(wǎng)的基本特性為“無(wú)連接”的體系結(jié)構(gòu)，路由器不需要維護(hù)狀態(tài)，IPv4/IPv6翻譯器本身也是一個(gè)路由器，因此無(wú)狀態(tài)的IPv4/IPv6翻譯器對(duì)于運(yùn)營(yíng)商來(lái)講更具有價(jià)值。同時(shí)，無(wú)狀態(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ā)起通信。無(wú)狀態(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ī)的訪問(wèn)，場(chǎng)景二為IPv4互聯(lián)網(wǎng)上計(jì)算機(jī)發(fā)起對(duì)IPv6網(wǎng)絡(luò)上計(jì)算機(jī)的訪問(wèn)。

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

1.2 地址映射和域名翻譯

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

其中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á)到高效地、無(wú)狀態(tài)地復(fù)用稀缺的公有IPv4地址資源的目的。此外，RFC6052要求轉(zhuǎn)換地址和可譯地址使用同樣的前綴（Prefix），從而可以自動(dòng)獲得最優(yōu)路由。

當(dāng)純IPv6計(jì)算機(jī)發(fā)起對(duì)IPv4互聯(lián)網(wǎng)的訪問(wèn)時(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ī)通過(guò)DNS64查詢所需域名的AAAA記錄，如AAAA記錄存在，則DNS64直接返回AAAA記錄給純IPv6計(jì)算機(jī)；如AAAA記錄不存在，則DNS64查詢域名對(duì)應(yīng)的A記錄，并根據(jù)RFC6052定義的映射算法，生成AAAA記錄返回給純IPv6計(jì)算機(jī)。無(wú)狀態(tài)的翻譯器支持IPv4互聯(lián)網(wǎng)發(fā)起的通信，在這種情況下，需要靜態(tài)配置的DNS46，當(dāng)IPv4互聯(lián)網(wǎng)上的用戶發(fā)起對(duì)IPv6計(jì)算機(jī)的訪問(wèn)時(shí)，DNS46則返回對(duì)應(yīng)IPv6計(jì)算機(jī)AAAA對(duì)應(yīng)的A記錄[5]。

1.3 協(xié)議翻譯

兩種不同協(xié)議棧之間的互聯(lián)互通必須解決的第二個(gè)問(wèn)題是協(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的翻譯過(guò)程中必然遇到MTU超出的問(wèn)題。此外，IPv4的傳輸控制協(xié)議（ICMP）和IPv6的傳輸控制協(xié)議（ICMPv6）也有很多不同，需要分別處理。

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

技術(shù)（MAP系列）

IPv4/IPv6翻譯技術(shù)可以使IPv4和IPv6互聯(lián)互通，但仍有3個(gè)問(wèn)題需要解決。第一個(gè)問(wèn)題是由于IPv4地址耗盡問(wèn)題，無(wú)狀態(tài)IPv4/IPv6翻譯必須能夠復(fù)用公有IPv4地址以高效使用IPv4地址資源；第二個(gè)問(wèn)題是目前有的應(yīng)用程序并沒(méi)有IPv6的版本（如Skype），也有的應(yīng)用程序嵌入了地址的信息（如Ftp）；第三個(gè)問(wèn)題是對(duì)于終端用戶往往需要分配一個(gè)64位的前綴，而不是單個(gè)的IPv6地址。無(wú)狀態(tài)雙重翻譯/封裝系列技術(shù)MAP-T/MAP-E可以解決這些問(wèn)題。MAP是Mapping Address and Port的縮寫，意指無(wú)狀態(tài)地對(duì)地址和端口進(jìn)行復(fù)用，與雙重翻譯（MAP-T）或封裝（MAP-E）技術(shù)組合，可以解決無(wú)狀態(tài)復(fù)用公有IPv4地址的問(wèn)題和上述的應(yīng)用程序問(wèn)題，同時(shí)可以支持前綴分配。MAP-T/MAP-E目前是IETF的工作組文檔[9-10]，其他相關(guān)的工作組文檔還有DHCPv6擴(kuò)展[11]和部署考慮[12]。

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

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

圖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ù)器，通過(guò)CE或BR的一次翻譯能夠?qū)τ谟脩舻募僆Pv4終端和IPv4互聯(lián)網(wǎng)上的用戶提供服務(wù)。IPv6接入網(wǎng)的用戶設(shè)備接到家庭網(wǎng)關(guān)上，可以是純IPv4終端設(shè)備，它通過(guò)CE一次翻譯訪問(wèn)網(wǎng)內(nèi)純IPv6服務(wù)器的信息資源，同時(shí)它通過(guò)CE和BR雙重翻譯訪問(wèn)IPv4互聯(lián)網(wǎng)上的信息資源，并與其他用戶互訪。該用戶設(shè)備還可以是IPv4/IPv6雙棧終端設(shè)備，直接訪問(wèn)網(wǎng)內(nèi)和IPv6互聯(lián)網(wǎng)上的信息資源，并通過(guò)CE和BR雙重翻譯訪問(wèn)IPv4互聯(lián)網(wǎng)上的信息資源，也能與其他用戶互訪。該用戶設(shè)備也可以是純IPv6終端設(shè)備，直接訪問(wèn)網(wǎng)內(nèi)和IPv6互聯(lián)網(wǎng)上的信息資源，通過(guò)BR一次翻譯訪問(wèn)IPv4互聯(lián)網(wǎng)上的信息資源，并與其他用戶互訪。

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

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

圖4中，核心封裝/解封裝器稱為BR，對(duì)于IPv6為IPv6路由器，對(duì)于IPv4為可以復(fù)用IPv4地址的IPv4 over 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è)備，它通過(guò)CE和BR封裝/解封裝訪問(wèn)IPv4互聯(lián)網(wǎng)上的信息資源，并與其他用戶互訪；該用戶設(shè)備還可以是IPv4/IPv6雙棧終端設(shè)備，直接訪問(wèn)網(wǎng)內(nèi)和IPv6互聯(lián)網(wǎng)上的信息資源，并過(guò)CE和BR封裝/解封裝訪問(wèn)IPv4互聯(lián)網(wǎng)上的信息資源，也能與其他用戶互訪。值得指出的是，封裝模式MAP-E無(wú)法支持在IPv6接入網(wǎng)內(nèi)部署純IPv6服務(wù)器，也不支持可以與IPv4互聯(lián)網(wǎng)互聯(lián)互通的純IPv6終端設(shè)備。

2.3 端口映射

MAP的核心技術(shù)之一是無(wú)狀態(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ù)為有限的，因此可以利用無(wú)狀態(tài)地址和端口映射算法高效率地復(fù)用公有IPv4地址資源。在使用無(wú)狀態(tài)地址和端口映射算法時(shí)，需要給每一個(gè)終端定義一個(gè)端口標(biāo)識(shí)集（PSID），端口標(biāo)識(shí)集和可用端口的映射關(guān)系由擴(kuò)展的模算法來(lái)決定。

擴(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ò)展的模算法還可以支持類似與無(wú)分類地址域間路由（CIDR）類似的地址聚類，即對(duì)應(yīng)于特定的PSID，可以定義PSID長(zhǎng)度，對(duì)于可用端口進(jìn)行聚類使用。

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

2.4 地址格式

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

與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ī)制

無(wú)狀態(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。無(wú)狀態(tài)雙重翻譯可以看成是具有頭壓縮功能的、無(wú)狀態(tài)IPv4 over IPv6的封裝技術(shù)。無(wú)狀態(tài)雙重翻譯技術(shù)（MAP-T）和無(wú)狀態(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)是可以蛻化為一次翻譯，有利于過(guò)渡到純IPv6網(wǎng)絡(luò)，但仍然保持與IPv4互聯(lián)網(wǎng)的互聯(lián)互通。同時(shí)，在IPv6接入網(wǎng)內(nèi)的IPv6數(shù)據(jù)報(bào)文沒(méi)有封裝的數(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ù)需求靈活配置，其分析參見(jiàn)MAP測(cè)試文檔[14]。

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

無(wú)狀態(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)表。無(wú)狀態(tài)翻譯技術(shù)不僅可以與無(wú)狀態(tài)封裝技術(shù)統(tǒng)一起來(lái)，也可以與有狀態(tài)的翻譯技術(shù)NAT64和有狀態(tài)的隧道技術(shù)Dual-stack Lite[15]統(tǒng)一起來(lái)。因此MAP-T/MAP-E家庭網(wǎng)關(guān)CE，不經(jīng)任何修改就可以與有狀態(tài)翻譯器NAT64或Dual-stack Lite的AFTR完成有狀態(tài)雙重翻譯或有狀態(tài)隧道的功能。由于無(wú)狀態(tài)和有狀態(tài)是兩個(gè)極端的情況，MAP-T/MAP-E家庭網(wǎng)關(guān)CE也可以不經(jīng)任何修改支持任何用戶狀態(tài)的場(chǎng)景。

3 過(guò)渡路線圖

雖然IPv4地址已經(jīng)分配完畢，但全世界IPv6的普及率仍然非常低。為了保證全球互聯(lián)網(wǎng)的健康和可持續(xù)發(fā)展，必須制訂正確的過(guò)渡路線圖。10年前IETF制訂的“以雙棧為主，輔之以隧道，在沒(méi)有其他選擇時(shí)用翻譯”的策略值得反思，理由為：

（1）這一政策在過(guò)去10余年里并沒(méi)有完成從IPv4到IPv6的過(guò)渡。

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

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

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

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

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

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

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

采用以上建議的過(guò)渡線路圖，可以使我們自己的網(wǎng)絡(luò)率先過(guò)渡到IPv6，并高效地利用公有IPv4地址資源與IPv4互聯(lián)網(wǎng)互聯(lián)互通，從而在IPv4到IPv6的過(guò)渡過(guò)程中保持主動(dòng)。這一技術(shù)方案完全符合中國(guó)發(fā)展下一代互聯(lián)網(wǎng)的路線圖和時(shí)間表，即“在2011—2015年的過(guò)渡階段，政府引導(dǎo)全社會(huì)向IPv6過(guò)渡，IPv4與IPv6共存，新建網(wǎng)絡(luò)必須為IPv6并實(shí)現(xiàn)與IPv4的互通”。目前無(wú)狀態(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)互通的無(wú)狀態(tài)翻譯技術(shù)和雙重翻譯技術(shù)IVI/MAP，預(yù)計(jì)在近幾年會(huì)得到大發(fā)展。

參考文獻(xiàn)

[1] NORDMARK E， GILLIGAN R. Basic 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 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 deployments following IPv4 exhaustion [S] .RFC 6333. 2011.