蔡廣平 鐘煒

摘要：闡述了幾種重要的基于翻譯的過渡技術(shù)，分析了其工作原理、技術(shù)特點(diǎn)、主要應(yīng)用場景以及各技術(shù)的優(yōu)缺點(diǎn)，同時探討了實際部署基于翻譯的IPv6過渡技術(shù)應(yīng)考慮的相關(guān)問題?；诜g的IPv6過渡技術(shù)可以延長IPv4使用期限，實現(xiàn)IPv6和IPv4互聯(lián)互通，能夠最大限度地保護(hù)投資者利益，確保網(wǎng)絡(luò)平滑演進(jìn)與過渡。選擇何種過渡方案涉及很多因素，需根據(jù)網(wǎng)絡(luò)特點(diǎn)等具體情況，選擇適合的過渡技術(shù)。

關(guān)鍵詞：IPv6過渡； 翻譯技術(shù)； 應(yīng)用場景

Abstract： In this paper， we describe several important IPv6 transition technologies based on translation. We describe the working principle， technical characteristics， and advantages and limitations of each technique. We also discuss typical scenarios in which these techniques might be used. IPv6 transition technologies based on translation extend the lifetime of the IPv4 network and allow communication between IPv4 and IPv6. They protect network to the greatest possible extent， and ensure the smooth transition from IPv4 to IPv6. When choosing IPv6 transition technologies， many factors need to be taken into account. Transition technologies must be selected according to the networks individual characteristics.

Key words： IPv6 transition； translation technology； application scenarios

由于IPv4地址耗盡，2011年以來中國IPv4地址數(shù)量幾乎沒有新增，而三網(wǎng)融合、云計算和移動互聯(lián)網(wǎng)又需要大量的IP地址。通過發(fā)展IPv6來解決這一問題，業(yè)界早已達(dá)成共識，但是IPv6地址和IPv4地址并不兼容，運(yùn)營商網(wǎng)絡(luò)、業(yè)務(wù)平臺、終端以及內(nèi)容提供商網(wǎng)絡(luò)都無法在短期內(nèi)全面支持IPv6，并且運(yùn)營商網(wǎng)絡(luò)基礎(chǔ)不同，不同區(qū)域面臨的問題不盡相同，因此如何經(jīng)濟(jì)、高效、平滑地過渡到IPv6是目前所面臨的難題。IPv6過渡技術(shù)方案眾多，但歸結(jié)起來主要有三大類：雙棧、隧道、翻譯。在向IPv6網(wǎng)絡(luò)演進(jìn)初期，內(nèi)容提供商和應(yīng)用服務(wù)仍然以IPv4為主，如果新增用戶只采用IPv6地址，基于雙棧和隧道的過渡技術(shù)則不能解決IPv6用戶訪問IPv4 因特網(wǎng)的問題；若為新增用戶分配雙棧地址，又無法解決IPv4地址耗盡的問題；此外，由于全網(wǎng)均為雙棧僅為理論方案，因此在整個網(wǎng)絡(luò)向IPv6演進(jìn)過程中，通過隧道或雙棧技術(shù)均無法實現(xiàn)IPv4和IPv6網(wǎng)絡(luò)的互訪互通，而基于翻譯的過渡技術(shù)可以解決此類關(guān)鍵問題。文章結(jié)合IPv6過渡技術(shù)開發(fā)與測試實際，探討基于翻譯的IPv6過渡關(guān)鍵技術(shù)，并分析各自特點(diǎn)，給出了典型部署，以及實際部署中應(yīng)考慮的相關(guān)問題。

1 NAT444

NAT44是IPv4-IPv4的網(wǎng)絡(luò)地址轉(zhuǎn)換（NAT）技術(shù)，早在1994年已被提出（RFC1931）。當(dāng)時NAT提出的背景是：在某一段時間內(nèi)，一個局域網(wǎng)內(nèi)只有少部分主機(jī)需要訪問外部網(wǎng)絡(luò)，大部分主機(jī)只需要訪問域內(nèi)網(wǎng)絡(luò)，甚至有些主機(jī)從不訪問外部網(wǎng)絡(luò)。因此，在該局域網(wǎng)內(nèi)可使用互聯(lián)網(wǎng)數(shù)字分配機(jī)構(gòu)（IANA）預(yù)留的局部地址（RFC1918），此類地址在不同的局域網(wǎng)內(nèi)可以重復(fù)使用。當(dāng)域內(nèi)某些主機(jī)需要訪問外部網(wǎng)絡(luò)時，通過NAT將局部地址轉(zhuǎn)換為全球唯一的全局地址，局域網(wǎng)只需要少量的全局地址。這些全局地址在不同的時刻可由域內(nèi)不同的主機(jī)占用，極大地減少了對全局地址的占用，達(dá)到節(jié)省IPv4地址的目的。NAT44應(yīng)用已非常普遍，是各類小型家用路由器的基本功能之一。

NAT444是指部署在運(yùn)營商網(wǎng)絡(luò)內(nèi)的NAT44設(shè)備，網(wǎng)絡(luò)模型如圖1所示。因特網(wǎng)服務(wù)提供商（ISP）網(wǎng)絡(luò)和用戶網(wǎng)絡(luò)均為IPv4網(wǎng)絡(luò)，服務(wù)提供商將IANA預(yù)留的局部地址分為兩類：用戶級局部地址和運(yùn)營級局部地址。在用戶終端設(shè)備（CPE）和運(yùn)營級設(shè)備各作一次NAT44，在用戶級將用戶級局部地址翻譯為運(yùn)營級局部地址，在運(yùn)營級再將運(yùn)營級局部地址翻譯為全局公有地址。由于作了兩次NAT，因此把運(yùn)營級NAT44稱之為NAT444，也稱為電信級NAT（CGN）或大規(guī)模NAT（LSN）。NAT444設(shè)備具有大容量、高性能的特點(diǎn)，可滿足高速數(shù)據(jù)吞吐需求；其機(jī)間或板間采用1：1或1：N安全備份，滿足電信級設(shè)備高可靠性要求；地址規(guī)劃與分配方式靈活多樣，用戶地址與端口號可預(yù)分配，與網(wǎng)管系統(tǒng)、AAA服務(wù)器、日志管理等配套可解決因引入NAT對用戶溯源、用戶行為分析等運(yùn)維管理造成的影響。

NAT444主要優(yōu)點(diǎn)為：

·NAT444實現(xiàn)了運(yùn)營級IPv4地址復(fù)用與共享，可有效解決IPv4地址枯竭問題。

·用戶網(wǎng)絡(luò)和運(yùn)營商接入網(wǎng)絡(luò)都可以保持現(xiàn)有IPv4網(wǎng)絡(luò)不變，只需在匯聚層或核心層增加NAT444設(shè)備即可，無需進(jìn)行大規(guī)模設(shè)備替換，投資成本低、投資風(fēng)險低。

·用戶和運(yùn)營商網(wǎng)絡(luò)都為IPv4單棧，NAT444技術(shù)方案成熟，運(yùn)維成本低。

·部署方式靈活，還可方便地和其他IPv6過渡技術(shù)配合使用，如IPv6快速部署（6RD）或雙棧。

因此NAT444不但適用于IPv6過渡初期，也可作為中長期演進(jìn)方案。圖2給出了NAT444和6RD配合使用模型。圖3為NAT44和雙棧配合使用模型。

NAT444主要不足為：

·并未正真引入IPv6網(wǎng)絡(luò)，在過渡后期還需要進(jìn)行設(shè)備更替。

·NAT破壞了IP網(wǎng)絡(luò)端對端通信的特點(diǎn)，對一些應(yīng)用協(xié)議處理比較復(fù)雜。

·需對網(wǎng)管系統(tǒng)、行為分析系統(tǒng)等運(yùn)維系統(tǒng)進(jìn)行升級。

2 DS-LITE

雙棧指的是IPv4和IPv6協(xié)議棧，如果網(wǎng)絡(luò)節(jié)點(diǎn)支持雙棧，則該節(jié)點(diǎn)既可以處理IPv4分組，又可以處理IPv6分組。雙棧是理論上較完美的IPv6過渡方案，但實際中一方面全網(wǎng)雙棧是不現(xiàn)實的；另一方面對于新建網(wǎng)絡(luò)，若采用雙棧需同時占用IPv4和IPv6地址，并不能解決IPv4地址短缺的問題，若采用IPv6單棧，演進(jìn)早期IPv6用戶無法訪問內(nèi)容豐富的IPv4內(nèi)容提供商網(wǎng)絡(luò)。輕量級雙棧（DS-LITE），旨在解決IPv4主機(jī)穿越運(yùn)營商的純IPv6網(wǎng)絡(luò)（如接入網(wǎng)、匯聚網(wǎng)）訪問IPv4內(nèi)容提供商網(wǎng)絡(luò)，以及通過IPv4-IPv4 NAT實現(xiàn)運(yùn)營級IPv4地址復(fù)用，以解決IPv4地址匱乏問題[1]。

DS-LITE網(wǎng)絡(luò)模型如圖4所示，其中ISP 網(wǎng)絡(luò)為純IPv6網(wǎng)絡(luò)，用戶網(wǎng)絡(luò)中可能只有IPv4主機(jī)，也可能存在IPv6主機(jī)或雙棧主機(jī)（當(dāng)雙棧主機(jī)用IPv6地址訪問網(wǎng)絡(luò)時可視為IPv6主機(jī)；反之可視為IPv4主機(jī)），為IPv4主機(jī)分配局部地址，對于IPv6主機(jī)地址分配和訪問IPv6網(wǎng)絡(luò)按照IPv6協(xié)議進(jìn)行轉(zhuǎn)發(fā)與處理。B4（基于橋接的寬帶網(wǎng)關(guān)）和地址族過渡路由器（AFTR）是DS-LITE的兩個主要模塊，都支持雙棧。

B4是DS-LITE用戶接入模塊，存在于CPE或者直接駐留在終端設(shè)備中（如在無線應(yīng)用場景中，無線終端不經(jīng)CPE而直接接入ISP網(wǎng)絡(luò)），主要完成如下幾方面的功能：

·隧道建立，隧道封裝/解封裝

B4設(shè)備與AFTR之間建立多點(diǎn)對點(diǎn)的IPv4-in-IPv6（4in6）隧道，通過手動配置或DHCPv6等方式，B4可以獲取AFTR地址。對于來自IPv4主機(jī)的IPv4報文，B4完成隧道封裝；對于來自AFTR的4in6報文，B4完成隧道解封裝。

·分片和重組

封裝4in6隧道后報文長度可能會超過最大傳輸單元（MTU），通過路徑MTU發(fā)現(xiàn)協(xié)議（RFC1191）并不能可靠地解決這一問題。一種解決方法是增大B4與AFTR間鏈路的MTU值，另一種方法是采用分片與重組。B4需支持分片與重組，對于來自用戶的報文，封裝隧道后進(jìn)行分片；對來自AFTR的4in6分片報文，在隧道解封裝前進(jìn)行重組。

·DNS代理

運(yùn)營商為B4僅分配IPv6地址，B4通過DHCPv6只能獲取到域名系統(tǒng)（DNS）服務(wù)器的IPv6地址，而不能獲取到IPv4地址，因此B4需要支持DNS代理，實現(xiàn)基于IPv4的DNS相關(guān)服務(wù)。

AFTR是ISP網(wǎng)絡(luò)中4in6隧道的匯聚點(diǎn)，主要可以完成如下幾方面的功能：

·隧道建立，隧道封裝/解封裝

AFTR與B4建立點(diǎn)對多點(diǎn)的IPv4-in-IPv6隧道，AFTR完成來自B4隧道報文的解封裝以及發(fā)往B4的IPv4報文的隧道封裝。

·分片和重組

與B4類似，AFTR需對來自B4的4in6分片報文先重組再解封裝；對發(fā)往B4的報文，封裝隧道后若超過MTU，需要進(jìn)行分片。

·NAT44轉(zhuǎn)換

這是AFTR的主要功能，將IPv4局部地址轉(zhuǎn)換為IPv4全局地址，其轉(zhuǎn)換原理、轉(zhuǎn)換方式等與NAT44相同。但與NAT44不同的是：B4的IPv6地址（Softwire ID）也是NAT映射關(guān)系生成的主要因素之一，不同的B4下可以使用完全相同的IPv4局部地址。因此當(dāng)兩個相同的IPv4局部地址所屬的Softwire ID不同時，所生成的NAT會話不同[2]。

DS-LITE 作為向IPv6演進(jìn)的主要方案之一，主要優(yōu)點(diǎn)為：

·剝離了ISP網(wǎng)絡(luò)、用戶網(wǎng)絡(luò)、因特網(wǎng)之間的耦合，ISP網(wǎng)絡(luò)發(fā)展IPv6網(wǎng)絡(luò)不受用戶網(wǎng)絡(luò)和因特網(wǎng)的影響，可獨(dú)立地直接演進(jìn)到純IPv6網(wǎng)絡(luò)。

·為IPv4主機(jī)分配局部地址，不同B4下IPv4地址可完全相同，能夠有效解決IPv4地址短缺問題。

·用戶可以自主地決定是否采用IPv6網(wǎng)絡(luò)，并且當(dāng)用戶過渡到IPv6時，對ISP網(wǎng)絡(luò)無額外要求。

·對于IPv6用戶直接按照IPv6協(xié)議處理，并且可以獲得更好的用戶體驗。

·4in6隧道可以在任意節(jié)點(diǎn)終結(jié)，AFTR部署靈活。

DS-LITE主要不足為：

·CPE等用戶接入設(shè)備需要更新升級，增加成本。

·因在AFTR需要做NAT44轉(zhuǎn)換，因此DS-LITE會繼承NAT44的一些不足。

·不能解決IPv6主機(jī)訪問IPv4網(wǎng)絡(luò)的問題。

3 NAT64

由于向IPv6網(wǎng)絡(luò)演進(jìn)初期因特網(wǎng)仍然以IPv4為主，因此存在IPv6用戶無法訪問內(nèi)容豐富的IPv4因特網(wǎng)問題。早在2000年因特網(wǎng)工程任務(wù)組（IETF）就提出IPv6-IPv4協(xié)議轉(zhuǎn)換的附帶協(xié)議轉(zhuǎn)換器的網(wǎng)絡(luò)地址轉(zhuǎn)換器（NAT-PT）技術(shù)（RFC2766），以解決這一問題。然而由于NAT-PT在實際應(yīng)用中存在如與DNS耦合太緊等諸多缺陷，IETF于2007年廢棄了NAT-PT（RFC4966），不再推薦使用，為此IEFT又推出了NAT64[2]。

NAT64是一種IPv6-IPv4間的AFT，是一種有狀態(tài)的網(wǎng)絡(luò)地址和協(xié)議轉(zhuǎn)換技術(shù)，因此NAT64又稱為Stateful NAT64或Stateful AFT[3]。

NAT64模型如圖5所示，IPv6客戶端和IPv4 服務(wù)器分別位于純IPv6、純IPv4網(wǎng)絡(luò)中。NAT64 至少有一個接口與IPv6網(wǎng)絡(luò)相接，一個接口與IPv4網(wǎng)絡(luò)相接，且支持雙棧。DNS64是將域名解析的A（32 bits IPv4地址）查詢記錄翻譯成AAAA（128 bits IPv6地址）查詢記錄，供IPv6客戶端使用，其中由A到AAAA的地址翻譯格式由RFC6205規(guī)定。

NAT64和DNS64配合，可實現(xiàn)IPv6 客戶端訪問IPv4 服務(wù)器，具體流程為：

（1）IPv6 客戶端向DNS64發(fā)起某WWW地址（不妨稱為X）的AAAA域名查詢請求。

（2）DNS64查詢本地域名系統(tǒng)，若X對應(yīng)的AAAA存在，則向IPv6 客戶端返回AAAA；若本地域名系統(tǒng)不存在，DNS64發(fā)起X的A域名查詢請求，獲得A域名后將A記錄轉(zhuǎn)換為AAAA記錄，然后將AAAA記錄返回給IPv6 主機(jī)。

（3）IPv6 客戶端獲得IPv4服務(wù)器對應(yīng)的AAAA后，向IPv4 服務(wù)器發(fā)起建鏈請求，該建鏈報文的SIPv6為IPv6 客戶端的IPv6地址，DIPv6為AAAA記錄對應(yīng)的IPv6地址，在IPv6網(wǎng)絡(luò)內(nèi)該報文必須路由到NAT64。

（4）NAT64對建鏈報文進(jìn)行IPv6-IPv4轉(zhuǎn)轉(zhuǎn)，其中DIPv4是從IPv6報文的DIPv6中通過約定格式解析獲?。≧FC6205），SIPv4是按既定的NAT64規(guī)則從NAT64 IP池中獲取一個IPv4公網(wǎng)地址，此外也可對源端口號等作相應(yīng)的轉(zhuǎn)換。

（5）IPv4 服務(wù)器響應(yīng)IPv6 客戶端的請求。

（6）NAT64對來自IPv4 服務(wù)器的報文通過查詢IPv6-IPv4轉(zhuǎn)換狀態(tài)（NAT64會話）進(jìn)行IPv4-IPv6轉(zhuǎn)換，將IPv4報文轉(zhuǎn)換為IPv6報文；若NAT64未查詢IPv6-IPv4轉(zhuǎn)換狀態(tài)，則丟棄報文。

由上述過程可見，對于IPv6 客戶端和IPv4 服務(wù)器感知不到NAT64是否存在以及報文是否作了NAT64，對于IPv6 客戶端訪問IPv4 服務(wù)器的方式與訪問位于純IPv6網(wǎng)絡(luò)的IPv6 服務(wù)器的方式完全一樣，因此NAT64對客戶端和服務(wù)器端都不可見。

一般情況下，在NAT64的應(yīng)用場景中需IPv6主機(jī)首先向IPv4主機(jī)發(fā)起通信，如圖6所示。但通過設(shè)定NAT64靜態(tài)映射規(guī)則等方式，也可實現(xiàn)IPv4主機(jī)首先向IPv6主機(jī)發(fā)起通信[4-5]。

NAT64主要優(yōu)點(diǎn)為：

·IPv6用戶可以訪問內(nèi)容豐富的IPv4 因特網(wǎng)，實現(xiàn)IPv6和IPv4網(wǎng)絡(luò)的互通互訪。

·可以為新增用戶直接分配IPv6地址，無需占用已枯竭的IPv4地址，網(wǎng)絡(luò)業(yè)務(wù)發(fā)展不受限于IPv4地址的枯竭。

·IPv6用戶可直接訪問純IPv6的網(wǎng)絡(luò)服務(wù)和應(yīng)用。

·運(yùn)營商網(wǎng)絡(luò)可以只支持IPv6單棧，無需支持IPv4。

·通常只能由IPv6主機(jī)發(fā)起通信，安全性高。

NAT64主要不足為：

·運(yùn)營商需要升級DNS，以支持A記錄與AAAA記錄間的翻譯。

·NAT64同NAT44一樣為有狀態(tài)翻譯，因此同樣會存在因翻譯帶來的不足。

4 IVI

IVI是另一種基于翻譯的過渡技術(shù)，羅馬數(shù)字用IV表示4，用VI表示6，因此用IVI表示IPv6-IPv4翻譯，或IPv4/IPv6融合與互聯(lián)互通。IVI同NAT64一樣，是IPv6和IPv4協(xié)議族間的轉(zhuǎn)換，但由于IVI通過事先設(shè)定的算法來實現(xiàn)IPv6-IPv4轉(zhuǎn)換，無需在轉(zhuǎn)換設(shè)備上維護(hù)IPv6-IPv4的映射關(guān)系，是種無狀態(tài)的翻譯技術(shù)，因此IVI也稱為無狀態(tài)地址族轉(zhuǎn)換（Stateless AFT）或被稱為無狀態(tài)NAT64（Stateless NAT64）[6]。

IVI的基本思想是：將IPv6主機(jī)地址在IPv4網(wǎng)絡(luò)中映射的IPv4地址內(nèi)嵌在IPv6主機(jī)的IPv6地址中，IVI通過對IPv6主機(jī)的IPv6地址解析，就可以直接獲取到與之對應(yīng)的IPv4地址，即IPv6主機(jī)地址必須是可以翻譯出IPv4地址的IPv6地址，因此運(yùn)營商需為IPv6 主機(jī)分配特殊的IPv6地址，可通過手動配置或DHCPv6動態(tài)分配。IPv4主機(jī)在IPv6網(wǎng)絡(luò)中映射的IPv6地址必須包含IPv4主機(jī)地址，即必須是由IPv4主機(jī)地址轉(zhuǎn)換得到的IPv6地址，通常由IVI DNS完成IPv4主機(jī)地址到IPv6地址的轉(zhuǎn)換，IVI DNS工作原理與DNS64相同，完成A記錄和AAAA記錄的相互轉(zhuǎn)換。IPv6主機(jī)地址格式、IPv4主機(jī)映射成的IPv6地址格式均由RFC6205規(guī)定，這兩類地址的前綴必須使用運(yùn)營商的路由前綴。

IVI主要應(yīng)用場景如圖7所示，它支持IPv6本地網(wǎng)絡(luò)（IPv6 Network）訪問IPv4因特網(wǎng)（IPv4 Internet）、IPv4因特網(wǎng)訪問IPv6本地網(wǎng)絡(luò)、IPv6本地網(wǎng)絡(luò)訪問IPv4本地網(wǎng)絡(luò)、IPv4本地網(wǎng)絡(luò)訪問IPv6本地網(wǎng)絡(luò)。但對于IPv4本地網(wǎng)絡(luò)與IPv6本地網(wǎng)絡(luò)的互訪，通常需二者為同一運(yùn)營商所管理。IVI支持IPv6主機(jī)發(fā)起的通信，也支持從IPv4主機(jī)發(fā)起的通信。

IVI的主要優(yōu)點(diǎn)為：

·運(yùn)營商可直接部署純IPv6網(wǎng)絡(luò)，有利于IPv6發(fā)展。

·可實現(xiàn)IPv6網(wǎng)絡(luò)與IPv4網(wǎng)絡(luò)的互通互訪問。

·IVI為無狀態(tài)翻譯，IPv6和IPv4主機(jī)都可以首先發(fā)起通信。

·通常只需翻譯IP層，無需修改傳輸層，實現(xiàn)簡單效率高，例如安全備份無需相互同步狀態(tài)等。

·部署性價比高于NAT64。

IVI主要不足為：

·IPv6主機(jī)地址與IPv4地址的映射為1：1（在其他文獻(xiàn)中有IVI通過端口復(fù)用等方式實現(xiàn)1：N，但實現(xiàn)比較復(fù)雜并未出現(xiàn)在RFC6219），IVI并不能解決IPv4地址枯竭問題。

·運(yùn)營商需要升級DNS，以支持A記錄與AAAA記錄的翻譯。

·盡管為IVI為無狀態(tài)，但仍需ALG支持某些應(yīng)用協(xié)議。

·安全性不及NAT64。

5 基于翻譯的過渡技術(shù)部署

CGN（在此將NAT444、DS-LITE、NAT64、IVI等基于翻譯的過渡技術(shù)都稱為CGN）設(shè)備形態(tài)按照與既有設(shè)備的關(guān)系可分為獨(dú)立式和插卡式兩類，獨(dú)立式是指CGN設(shè)備與現(xiàn)有設(shè)備（如寬帶遠(yuǎn)程接入服務(wù)器（BRAS）或核心路由器（CR）等相互獨(dú)立，以旁掛于現(xiàn)有設(shè)備的方式部署；插卡式指現(xiàn)有設(shè)備提供空閑插槽，CGN設(shè)備以板卡形式與現(xiàn)有設(shè)備融合部署。按照部署層面不同，CGN部署分為集中式部署和分布式部署，集中式指CGN設(shè)備部署在網(wǎng)絡(luò)流量出口，如城域網(wǎng)核心層或移動分組域承載CE層；分布式指CGN設(shè)備部署在業(yè)務(wù)控制層，如BRAS。表1列出CGN設(shè)備的4種典型部署。

下面以NAT444部署為例，說明CGN部署對現(xiàn)網(wǎng)的影響，網(wǎng)絡(luò)拓?fù)淙鐖D8所示。NAT444部署在城域網(wǎng)業(yè)務(wù)控制層，其中寬帶用戶接入BRAS節(jié)點(diǎn)采用插卡分布式部署，大客戶業(yè)務(wù)路由器（SR）節(jié)點(diǎn)采用獨(dú)立分布式部署，提供大流量的NAT轉(zhuǎn)換，并與AAA服務(wù)器、日志服務(wù)器等配套系統(tǒng)一起解決用戶溯源、單點(diǎn)認(rèn)證、行為分析等問題，實現(xiàn)運(yùn)營級NAT 服務(wù)。

對于SR旁掛NAT444獨(dú)立部署，用戶上行流經(jīng)SR通過策略路由把需要NAT的流導(dǎo)入NAT444獨(dú)立設(shè)備，并作NAT后再次返回SR經(jīng)CR接入骨干網(wǎng)；然后再返回下行流通過路由引導(dǎo)到NAT444。此外，該場景中插卡式和獨(dú)立式部署都采用1：1安全備份，獨(dú)立設(shè)備采用機(jī)間備份、插卡式采用板間備份，當(dāng)主設(shè)備M出現(xiàn)故障，自動切換到備設(shè)備S。

AAA服務(wù)器從網(wǎng)管系統(tǒng)接收用戶地址映射關(guān)系信息，存儲在本地并維護(hù)各NAT444的用戶映射關(guān)系。網(wǎng)管系統(tǒng)對NAT444統(tǒng)一管理，如統(tǒng)一生成用戶地址映射關(guān)系表以及地址池，端口塊大小等參數(shù)信息，通過簡單網(wǎng)絡(luò)管理協(xié)議（SNMP）等協(xié)議下發(fā)配置信息到NAT444設(shè)備或AAA服務(wù)器。NAT444生成NAT日志，如每生成或老化一條NAT映射規(guī)則時則會產(chǎn)生一條日志信息，并及時上傳給日志服務(wù)器。日志服務(wù)器管理NAT日志信息，對日志信息分析統(tǒng)計，提供管理接口，響應(yīng)用戶查詢?nèi)罩拘畔ⅰ？梢娨隢AT需要對現(xiàn)網(wǎng)AAA服務(wù)器、網(wǎng)管系統(tǒng)等配套設(shè)備進(jìn)行升級。此外，實際部署還需考慮安全管理、故障管理、性能需求以及機(jī)箱、線纜、環(huán)境等要素。

6 結(jié)束語

由于IPv4地址資源枯竭，過渡到IPv6 是網(wǎng)絡(luò)發(fā)展的必然趨勢。但是運(yùn)營商網(wǎng)絡(luò)、業(yè)務(wù)平臺、終端以及內(nèi)容提供商網(wǎng)絡(luò)都無法短期內(nèi)全面支持IPv6，因此向IPv6過渡是長期的過程。基于翻譯的IPv6過渡技術(shù)可以延長IPv4使用期限、實現(xiàn)IPv6和IPv4互聯(lián)互通，最大限度地保護(hù)投資者利益，確保網(wǎng)絡(luò)平滑演進(jìn)與過渡。此外，選擇何種過渡方案涉及很多因素，需根據(jù)網(wǎng)絡(luò)特點(diǎn)等具體情況，選擇適合的過渡技術(shù)。

參考文獻(xiàn)

[1] DURAND A， DROMS R， WOODYATT J. Dual-stack lite broadband deployments following IPv4 exhaustion[S] .IETF RFC 6333 .2011.

[2] 劉騰飛，秦雅娟，王利利. 代理移動IPv6下子網(wǎng)移動方案的實現(xiàn)與分析[J].重慶郵電學(xué)院學(xué)報（自然科學(xué)版）， 2013 （3）：372-378.

[3] BAGNULO M， MATTHEWS P，VAN BEIJNUM I. Stateful NAT64： Network address and protocol translation from IPv6 clients to IPv4 servers[S]. IETF RFC 6146.2011.

[4] 吳大鵬. IPv6的發(fā)展與現(xiàn)狀[J]. 數(shù)字通信，2010（2）：16-19.

[5] 陳建軍， 邱偉， 黃孟俊， 趙宏鐘， 付強(qiáng). 基于距離單元篩選的擴(kuò)展目標(biāo)檢測新方法[J].雷達(dá)科學(xué)與技術(shù)， 2012（3）：294-300.

[6] LI X， BAO C，BAKER F. IP/ICMP translation algorithm[S]. IETF RFC 6145.2011.