陳慶

（四川大學計算機學院，成都 610065）

NAT64機制的應用兼容性研究

陳慶

（四川大學計算機學院，成都 610065）

0　引言

2011年初，全球地址分配機構（ICANN）宣布IPv4地址分配完畢，同年4月15日，亞太互聯(lián)網信息中心（APNIC）的IPv4地址耗盡［1］，對于IPv6的部署已經勢在必行。然而全球網絡由IPv4全部過渡到IPv6是一個龐大而復雜的工程，為了促進IPv6的部署，學術界提出了IPv4向IPv6過渡的多種技術方案，總體上可概括為三種：雙棧、翻譯、隧道［2］。NAT64［3］/DNS64［4］是翻譯方案中一種非常重要和可行的方案，它針對的是IPv6主機訪問IPv4網絡的場景。因為在過渡階段，需要保證新部署的IPv6用戶可以訪問到以IPv4協(xié)議運行的服務器上的資源。

因為網絡終端用戶對網絡的使用主要集中在應用層上，所以在運營商部署NAT64/DNS64方案時，應用協(xié)議能否在過渡環(huán)境中正常工作——即應用兼容情況，將成為其關注的一個重要方面。本論文選取5個主流的NAT64開源實現(xiàn)，使用常用的多個應用協(xié)議對其進行兼容性測試。在構建應用場景的過程中，使用虛擬軟件組網的方式模擬了NAT64/DNS64下的等效應用場景，成功地對15個應用協(xié)議（涵蓋了網頁瀏覽、郵件收發(fā)等用戶常用應用和推送系統(tǒng)日志、校準系統(tǒng)時間這些系統(tǒng)常用應用，在第四部分會進行詳細討論）進行了兼容性測試，測試結果表明主流的5個NAT64開源實現(xiàn)對大部分的應用協(xié)議支持良好，而對Bittorrent協(xié)議和FTP協(xié)議的active模式不支持，驗證了 Sándor Répás［5］等人的研究。

1　NAT64/DNS64運作過程

一次典型的NAT64/DNS64訪問過程如圖1所示，分為兩個階段：DNS64階段和NAT64階段。

●DNS64階段：IPv6主機訪問域名為“ipv4.test. scu”的服務器，先向DNS64服務器請求該域名對應的IPv6地址。隨后DNS64服務器在IPv6網絡中查詢域名對應的AAAA記錄，沒有發(fā)現(xiàn)相應記錄，于是向IPv4網絡中的DNS服務器請求該域名對應的A記錄.在A記錄返回后，DNS64服務器將該A記錄和WKP（Well Known Prefix，64:ff9b::/96）或者NSP（Network-Specific Prefix）拼接后得到一個IPv6地址，將該地址作為DNS查詢的結果返回給IPv6主機。

●NAT64階段：IPv6主機使用DNS64返回的地址作為目的地址，發(fā)起TCP連接請求.在經過NAT64路由器時，如果NAT64路由器采用無狀態(tài)方案，則按照RFC6145［6］描述的算法將IPv6報文翻譯為IPv4報文；如果NAT64路由器采用有狀態(tài)方案，則按照RFC6146 ［3］描述的報文翻譯算法進行報文翻譯，如圖1中IPv6地址2001:aaaa::2被映射為地址池中一個地址——192.100.10.10，端口a被映射為b，然后從NAT64路由器的IPv4接口將翻譯后的報文轉發(fā)出去.IPv4服務器接收到TCP連接請求，回應TCP ACK，該報文在NAT64路由器按照相應的報文翻譯算法進行反向的報文翻譯，從IPv6接口出去后被IPv6主機接收到。這是NAT64下一次TCP交互的過程。

圖1　NAT64/DNS64機制應用場景

2　NAT64主流開源實現(xiàn)

Ecdysis［7］是有狀態(tài)的NAT64項目，其IPv6地址與IPv4地址是N:1的關系，所以需要NAT64設備跟蹤會話并且改寫傳輸層端口。Ecdysis集成了NAT64和DNS64，其DNS64功能基于開源實現(xiàn)ubound和Bind。Ecdysis目前主要有兩個分支，一個是作為Linux下的內核模塊，在本文中稱為Ecdysis under Linux，其要求內核版本為2.6.31+，最近更新時間為2014.4.22.另一個則是可集成到OpenBSD系統(tǒng)的Packet Filter中，最近更新時間為2012.2.26，從OpenBSD 5.1版本開始，Ecdysis被官方集成到了OpenBSD系統(tǒng)中。

TAYGA［8］是一個無狀態(tài)的NAT64實現(xiàn)，平臺為Linux。在無狀態(tài)方案中，IPv6地址與IPv4地址是1:1的關系，NAT64設備無需跟蹤會話和改寫傳輸層端口.為了高效地復用公網IPv4地址，可以再進行一次NAT44報文翻譯，這樣就相當于一個有狀態(tài)的NAT64。另外，當使用WKP作為NAT64前綴時，TAYGA將丟棄以＜WKP+私網IPv4地址＞作為目的IPv6地址的報文，這符合RFC6052［9］的規(guī)定。最近更新時間為2010.12.12，版本為0.9.2。

WrapSix［10］是一個有狀態(tài)的NAT64實現(xiàn)，平臺為Linux.為了獲得更好的性能，其被設計為一個NAT64報文翻譯服務器，即軟件只會在一個接口上進行操作，因此它需要和一個路由器聯(lián)合工作，由Wrapsix負責報文的翻譯，而路由器負責報文的轉發(fā)。最近更新時間為2013.7.25，版本為0.2.0。

JOOL［11］項目同樣是有狀態(tài)NAT64實現(xiàn)，平臺為Linux。JOOL提供兩個模塊，一個是運行于核心態(tài)的翻譯模塊，提供報文翻譯功能，另一個是運行于用戶態(tài)的配置管理模塊，提供命令行工具進行配置和查看。JOOL的工作方式比較靈活，既可以操作兩個接口，也可以僅操作一個接口。本文完成時，JOOL的最近更新時間為2015.4.14，版本為3.3.2。

3　應用協(xié)議選擇

網絡用戶最常做的行為包括：瀏覽網頁（HTTP、HTTPS），收發(fā)郵件 （SMTP、POP3、IMAP），遠程登錄（TELNET、SSH），拷貝文件（SCP、FTP、BT），連接遠程桌面（RDP），通過VPN上網（OPENVPN），在網絡上共享文件 （CIFS）。系統(tǒng)常用行為包括：推送系統(tǒng)日志（SYSLOG），校準系統(tǒng)時間（NTP）。綜合以上情形，得到常用的15個應用協(xié)議，具體信息如表2所示。

表1　NAT64開源實現(xiàn)

表2　選擇的應用協(xié)議

4　應用協(xié)議兼容性分析

NAT64機制對網絡層和傳輸層 （主要是TCP和UDP）提供了很好的支持，當應用層協(xié)議嚴格遵守分層原則，不在自己的層中嵌入網絡層和傳輸層的內容（如IP、端口）時，根據NAT64機制的運作原理，理論上該應用協(xié)議是能夠正常運行的，也即可以被NAT64兼容。所選的15個應用協(xié)議，除去HTTP、HTTPS、FTP Active模式、BT，理論上都是可以被NAT64完全兼容的。

對于HTTP/HTTPS，當IPv6端發(fā)起訪問時一定是通過域名或者IPv6地址訪問。使用域名的情況下，可以通過DNS64來獲得可譯的IPv6地址，也可以直接通過可譯的IPv6地址訪問網頁。但是在訪問的的網頁內容中可能會存在基于字面IPv4地址的跳轉，這時僅靠NAT64機制是無法處理的。

FTP Active需要IPv4服務器端主動發(fā)起數(shù)據連接，且在發(fā)起數(shù)據連接前，IPv6端會告知IPv4端自身的IPv6地址和監(jiān)聽的端口，NAT64不會處理這個報文中的IPv6地址，最后IPv4端收到的將是IPv6地址叫上對方監(jiān)聽的端口，導致IPv4端無法繼續(xù)處理。

而BT協(xié)議在獲取的資源記錄peers list中壓縮了網絡層的IPv4地址，到達IPv6端時，純IPv6端面對IPv4地址將無法處理。

下面將通過一系列的實驗來實際測試應用協(xié)議的兼容性。

5　NAT64測試環(huán)境配置和測試流程

5.1虛擬組網方法

由于本文中定義的應用兼容性測試的特殊性，并不需要像性能測試一樣搭建復雜和具備一定規(guī)模的網絡環(huán)境，可以將應用場景簡化為一個等價的較小的模型，以此搭建測試環(huán)境。本文借助于虛擬機軟件和公網上的服務，搭建了測試環(huán)境。

NAT64實現(xiàn) （PF運行于OpenBSD上）運行于ubuntu12.04上。DNS64采用totd，運行于Ubuntu12.04上。測試中服務器采用 CentOS6.2，客戶端采用Debian7.2。

虛擬網絡采用VMware WorkStation 9組建，組網原理如圖2所示.所有使用VMnet1虛擬網卡的主機都可以看做連接到一個VMnet1 Switch上，只要各主機的網絡地址處于同一個局域網，就可以相互通信。使用VMnet2網卡組網與使用VMnet1網卡相同。而使用VMnet8虛擬網卡除了連接到VMnet8 Switch外，還會連接到一個虛擬的NAT44路由器，虛擬機經過該路由器就可以實現(xiàn)和宿主機共享一個IP地址，訪問外網。使用虛擬組網方式的優(yōu)勢在于在實驗過程中可以快速地調整實驗網絡，適用于本文中眾多的應用測試場景。

圖2　VMware Workstation 9的組網原理

另外，由于 WrapSix的設計目標是作為一個NAT64服務器，程序只能操作一個接口，故采用一個路由器和WrapSix服務器組合使其對外表現(xiàn)為一個完整的NAT64路由器，組合方式如圖3所示。

圖3　WrapSix和路由器的組合

5.2邏輯拓撲測試

由于應用層的測試大多涉及到一些復雜的客戶端軟件，并不容易采用自動化測試的方式實現(xiàn)，故此處采用手工進行測試和判斷應用兼容性情況。對于HTTP、HTTPS、SMTP、POP3、IMAP、NTP、BITTORRENT、TELNET、SSH、SCP、SYSLOG、RDP、CIFS、FTP協(xié)議的測試，使用圖4所示拓撲。圖5的拓撲用來測試OPENVPN協(xié)議。

圖4　多種應用協(xié)議的測試拓撲

5.3測試流程

在測試過程中，先選擇Ecdysis under Linux，按照圖4搭建網絡拓撲環(huán)境，然后在Linux環(huán)境下依次配置HTTP、HTTPS、SMTP、POP3、IMAP、NTP、BITTORRENT、TELNET、SSH、SCP、SYSLOG、RDP、CIFS、FTP協(xié)議的應用環(huán)境并進行測試，完畢后按照圖5搭建OPENVPN應用測試環(huán)境，對OPENVPN進行測試。在Ecdysis測試完畢后，依次對PF of OpenBSD、TAYGA、Wrapsix和JOOL按照Ecdysis的流程進行應用協(xié)議測試，具體流程如圖6所示.在手動測試的過程中，通過觀察客戶端程序的表現(xiàn)來判斷該次應用測試是否通過。

在測試的過程中，需要對應用協(xié)議運行時具體的交互過程進行監(jiān)控，以VMnet1、VMnet8和VMnet2為網絡交互過程的觀察點，在測試的過程中使用wire-shark對觀察點進行抓包，以進行報文級別的分析。

圖5　OPENVPN協(xié)議的測試拓撲

圖6　應用協(xié)議測試流程圖

6　測試結果及分析

采用手工的方式對應用協(xié)議在五個NAT64實現(xiàn)下的兼容情況進行測試并根據觀察結果進行判斷，（表示在手工測試過程中該應用協(xié)議被判斷為運行正常，（則表示該應用協(xié)議被判斷為運行異常，如表3所示（Ecdysis代表 Ecdysis under Linux，PF代表 PF of OpenBSD）。

實際測試結果與理論分析所得結論一致.所選應用協(xié)議中大部分都可以正常運行，包括瀏覽網頁（網頁內容中無基于字面IP地址跳轉）、收發(fā)郵件、文件傳輸?shù)?這意味著使用NAT64機制時，IPv6用戶基本上能夠正常地使用IPv4網絡上的應用服務。失敗的應用協(xié)議有兩個：FTP active、Bittorrent。在所有五個開源實現(xiàn)的測試過程中，失敗的情形是一樣的。

通過wireshark抓包可以發(fā)現(xiàn)，在FTP active模式下，IPv6端發(fā)送的EPRT命令中嵌入了自身的IPv6地址，而該地址將順利到達IPv4端，導致該模式失敗。

在Bittorrent的測試過程中，用wireshark抓包發(fā)現(xiàn)，IPv6端的Bittorrent和IPv4端的tracker成功建立了tcp連接，并從tracker獲取了資源記錄peers list，但是peers list卻是以字面IPv4地址壓縮而成，在IPv6環(huán)境下的Bittorrent Client無法使用這個地址，從而無法進入下一步的握手階段。

對于FTP active存在的問題，可以考慮部署ALG 在IPv4側，該ALG可以將應用層的EPRT命令“EPRT |2|＜IPv6 address＞|＜tcp port1＞|”翻譯為“PORT h1，h2，h3，h4，p1，p2”，即將客戶端的IPv6地址替換為有狀態(tài)翻譯下的IPv4地址，tcp port1映射到NAT64設備的 tcp port2（p1*256+p2）上，同時有狀態(tài)的NAT64設備上也要增加一個相應的映射條目。而無狀態(tài)的NAT64下僅需要替換IPv6地址，tcp port1無需映射到tcp port2，只需要滿足port1=p1*256+p2的關系。這樣IPv4 FTP服務器可以識別翻譯過后的PORT命令，NAT64設備也可以正確地翻譯這一數(shù)據連接上的來往報文.

對于Bittorrent協(xié)議，可以考慮一種部署在IPv6側的ALG，在返回的Tracker response中將IPv4地址的peers list替換為IPv6地址的peers6 list，具體做法是將peers替換為peers6，將6字節(jié)的IPv4地址/端口字段擴展為18字節(jié)的IPv6地址/端口字段 （加上預定義的IPv6前綴，如WKP），同時需要重新計算peers6 list的總字節(jié)數(shù)以及tcp的校驗和。在進行地址擴展的過程中，由于 IPv6報文的載荷是有限的，當 Tracker response中返回的peers過多時，如果把每個IPv4地址都擴展為IPv6地址，可能導致IPv6報文載荷超過上限，這樣就需要適當?shù)貋G棄掉一部分的peers，使得IPv6報文載荷不超過上限。

7　結語

本文提出了NAT64的應用兼容性問題，選取了具有代表性的15個應用協(xié)議，從理論上分析了其兼容情況，引入了主流的5個NAT64開源實現(xiàn)，給出了組建NAT64/DNS64應用環(huán)境的虛擬組網方法，并將其應用于5個開源實現(xiàn)的測試中，得到了應用兼容性測試結果.對測試結果進行分析，發(fā)現(xiàn)NAT64機制對大部分常用的應用協(xié)議支持良好，驗證了NAT64/DNS64過渡方案的可行性。同時分析了不支持的Bittorrent協(xié)議和FTP協(xié)議active模式，并討論了其解決方案。

表3　應用協(xié)議測試結果

當然本論文對NAT64機制的研究還不夠，下一步將對這些開源實現(xiàn)在高負載下的性能進行測試研究，以比較其性能的優(yōu)劣，為網絡運營商提供進一步的參考。

［1］Huston G.IPv4 Address Report［EB/OL］.（2015-04-20）.［2015-04-20］.http://www.potaroo.net/tools/ipv4.

［2］Arkko J，Baker F.RFC 6180:Guidelines for Using IPv6 Transition Mechanisms During IPv6 Deployment［EB/OL］.（2011-05-27）. ［2015-04-20］.http://tools.ietf.org/html/rfc6180.

［3］Bagnulo M，Matthews P，Beijnum I van RFC 6146:Stateful NAT64:Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers［EB/OL］.（2011-04-27）.［2015-04-20］.http://tools.ietf.org/html/rfc6146.

［4］Bagnulo M，Sullivan A，Matthews P，et al.RFC 6147:DNS64:DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers［EB/OL］.（2011-04-27）.［2015-04-20］.http://tools.ietf.org/html/rfc6147.

［5］Répás S，Hajas T，Lencse G.Application Compatibility of the NAT64 IPv6 Transition Technology［C］.Conference:37th International Conference on Telecommunications and Signal Processing（TSP）.Berlin，Germany，2014.

［6］Li X，Bao C，Baker F.RFC 6145:IP/ICMP Translation Algorithm［EB/OL］.（2011-04-27）.［2015-04-20］.http://tools.ietf.org/html/ rfc6145.

［7］Perreault S，Dionne J，Blanchet M.Ecdysis:Open-Source DNS64 and NAT64［EB/OL］.（2010-06-03）.［2015-04-20］.http://www.viagenie.ca/publications/2010-06-03-terena-nat64.pdf.

［8］Lutchansky N.TAYGA，Simple，No-fuss NAT64 for Linux［EB/OL］.（2010-11）.［2015-04-20］.http://www.litech.org/tayga.

［9］Bao C，Huitema C，Bagnulo M，et al.RFC 6052:IPv6 Addressing of IPv4/IPv6 Translators［EB/OL］.（2010-10-28）.［2015-04-20］.http: //tools.ietf.org/html/rfc6052.

［10］Xhire.WrapSix-the Fastest Software NAT64［EB/OL］.（2008）.［2015-04-20］.http://www.wrapsix.org/.

［11］Jool SIIT&NAT64［EB/OL］.（2012）.［2015-04-20］.http://www.jool.mx/index.html.

Application Compatibility；NAT64 Mechanism；Open-Source Implementation；IPv6 Transition

Research on the Application Compatibility of NAT64 Mechanism

CHEN Qing
（College of Computer Science，Sichuan University，Chengdu 610065）

1007-1423（2015）36-0011-07

10.3969/j.issn.1007-1423.2015.36.003

陳慶（1988-），男，四川江安人，碩士研究生，在校學生，研究方向為網絡與信息安全

2015-11-06

2015-11-13

提出并研究NAT64機制的應用協(xié)議兼容性問題——即在使用NAT64/DNS64的網絡中，常用的應用協(xié)議能否正常工作。由于網絡終端用戶對網絡的使用主要集中在應用層，因此實際部署NAT64/DNS64方案時應用協(xié)議兼容性將是網絡運營商考量的一個重要方面。選取了5個主流的NAT64開源實現(xiàn)和多個常用應用協(xié)議，從理論上分析其兼容性，然后采用虛擬組網的方式搭建測試環(huán)境，進行應用協(xié)議的兼容性測試，并對測試失敗的應用協(xié)議進行分析，討論其解決方案。

應用兼容性；NAT64機制；開源實現(xiàn)；IPv6過渡中

Tests five open source NAT64 implementations for their application compatibility which means if common application protocols can work normally.Because the operations of Internet users are mainly on the application level，the application compatibility will be crucial when ISP deploys NAT64/DNS64 mechanism.The virtual testing environments of five NAT64 implementations will be setup with VMware Workstation 9.For the test results，provides an analysis to discuss the application compatibility of the NAT64 implementations.For failed cases tested，provides solutions.