摘要：SOCKS協(xié)議是可用的功能最強大、應用最靈活、安全性較高的代理協(xié)議，基于SOCKS的IPv4向IPv6過渡技術已經成為一種不錯的選擇。首先討論了直接在雙棧主機上實現IPv4和IPv6的地址轉換的BIA技術，然后討論了通過一個雙棧網關來進行IPv4和IPv6的地址轉換的SOCKS64技術，最后對這兩種技術進行了比較分析。
關鍵詞：IPv4，IPv6，SOCKS，BIA，SOCKS64
一、概述
由于IPv6與IPv4相比具有諸多的優(yōu)越性，IPv6代替IPv4已經成為網絡發(fā)展的必然趨勢。然而現有IPv4網絡是如此的龐大，以至于短時間之內不可能將它全部廢除。因此，需要尋找一種合適的過渡技術來解決這一難題。由于無狀態(tài)IP/互聯(lián)網控制消息協(xié)議翻譯算法（SIIT）、網絡地址翻譯-協(xié)議轉換器（NAT-PT）和棧內凸塊（BIS）等過渡技術都存在著這樣那樣的缺點，隧道技術又不能解決IPv6節(jié)點與IPv4節(jié)點之間相互通信的問題，而在網絡中應用代理服務既可以充分利用IP地址資源，又能夠保證網絡安全，尤其是全能代理協(xié)議SOCKS，它可以完成網頁瀏覽、文件傳輸和遠程登陸等所有工作的代理，是可用的功能最強大、應用最靈活、安全性較高的代理，因而基于具有強大功能的SOCKS代理的IPv4向IPv6過渡技術已經成為一種不錯的選擇。基于SOCKS的過渡技術分為兩種。一種是API內凸塊(BIA)技術，這種技術直接在雙棧主機上實現IPv4和IPv6的地址轉換；另一種是SOCKS64技術，這種技術是通過一個雙棧網關來進行IPv4和IPv6的地址轉換。
二、BIA技術
BIA技術在雙棧主機的Socket API模塊與TCP/IP模塊之間加入一個API翻譯器(如圖1所示)。API翻譯器包含三個模塊：域名解析器，地址映射器和函數映射器。其中，域名解析器負責對IPv4應用程序的請求域名返回一個正確的應答，地址映射器在主機內部維護一張IPv4與IPv6地址對的表格（分配的IPv4地址來自IPv4地址池中，采用未使用的IPv4地址，如 0.0.0.1 ~ 0.0.0.255），函數映射器負責在IPv4的Socket API函數與IPv6的Socket API函數間相互翻譯。
圖1 采用BIA機制的雙棧主機的結構模型
RFC3338中描述了采用BIA機制的雙棧主機與IPv6主機之間相互通信的過程。其中雙棧主機Dual Stack向IPv6主機Host6發(fā)起通信的過程如下：
·當雙棧主機Dual Stack上的IPv4應用向它的域名服務器（DNS）發(fā)送查詢目的主機的地址請求時，域名解析器攔截了這個請求，并產生一個新的查詢請求轉發(fā)給DNS來解析A和AAAA兩種記錄。
·DNS解析出Host6的AAAA記錄后，將它返回給域名解析器。
·域名解析器要求地址映射器為IPv6地址分配一個IPv4地址。
·地址映射器在IPv4地址池中選擇一個未用的保留地址，在映射表中注冊后返回給域名解析器。
·域名解析器為分配的IPv4地址產生一條A記錄，返回給IPv4應用程序。
·IPv4應用程序調用IPv4的Socket API函數，函數映射器對調用命令進行攔截，判斷其是否來自于IPv6的應用。若不是，跳過翻譯程序；否則，函數映射器向地址映射器請求該IPv4地址對應的IPv6地址，地址映射器從映射表中查找后將結果返回。函數映射器使用收到的這個AAAA型地址調用Host6上相應的IPv6 socket API函數。
·當函數映射器接收到Host6上IPv6 socket API函數的應答后，向地址映射器請求與Host6對應的IPv4地址。然后，函數映射器利用此IPv4地址繼續(xù)完成socket API函數的調用。
由IPv6主機Host6發(fā)起到雙棧主機Dual Stack的通信過程相對簡單一些。Host6通過它的DNS解析Dual Stack的AAAA記錄，然后向Dual Stack發(fā)送一個IPv6的數據包。為了通過調用IPv4的API函數和IPv4應用通信，函數映射器檢測到IPv6數據包到達Dual Stack后，向地址映射器發(fā)送一個IPv4地址請求，并用返回的IPv4地址發(fā)起一個IPv4的Socket API調用。然后，函數映射器再向地址映射器請求與該IPv4地址對應的原來的IPv6地址，按照這個地址對Host6答復。 三、SOCKS64技術
SOCKS64技術是原有SOCKS協(xié)議(IETF RFC1928)的擴展，相當于IP層的代理，其原理如圖2所示。它增加了兩個新的功能部件*Socks Lib*和*Gateway*。*Socks Lib*是在客戶機一端引入的，它位于應用層和Socket層之間，可以替代應用程序的Socket API和DNS域名解析API。在*Socks Lib*中有一個DNS域名解析代表，它在源節(jié)點（客戶機C）全權代表到中繼服務器（網關G）的域名解析行為。*Gateway*是安裝在IPv6和IPv4雙棧網關上的一個增強型的SOCKS服務器，可以完成客戶機C（IPvX）和目的端D之間的任何協(xié)議組合類型的中繼。當*Socks Lib*調用中繼時，由父*Gateway*來產生出一個*Gateway*進程（線程）來負責中繼連接。
圖2 采用SOCKS64技術的網絡通信原理
在SOCKS5中規(guī)定，IPv4地址、IPv6地址和域名的全限定域名（FQDN）信息可以用在SOCKS協(xié)議格式的地址類型(ATYP)域。SOCKS64技術就是利用這一點，通過DNS域名解析代表將FQDN信息用在ATYP域中從客戶機C傳到網關G來指出目的地D的位置。為此，SOCKS64技術也和BIA技術一樣使用了IPv4中未使用的保留地址（稱之為偽IP地址），并在*Socks Lib*（客戶機C處）中引入一個映射表來管理偽IP地址和FQDN之間的映射。
客戶機C[IPvX]使用SOCKS64技術通過雙棧網關G[IPvX|IPvY]與目的主機D[IPvY]通信的過程如下：
·源節(jié)點（客戶機C）上的應用盡力通過調用DNS域名解析函數來獲得目的節(jié)點（目的地D）的IP地址信息。這時，目的地D的邏輯主機名（即FQDN）信息被作為被調用的API的一個參數傳遞給應用的*Socks Lib*。
·FQDN信息被注冊到*Socks Lib*中的一個映射表內。*Socks Lib*選擇一個偽IP地址回復給應用。
·應用利用收到的偽IP地址信息組織一個socket，并將socket用作API的一個參數來調用socket API啟動通信。
·由于*Socks Lib*已經取代了這些socket API，真正的socket函數將不再調用，而是先檢查socket的IP地址信息。如果該地址是偽IP地址，則從映射表中獲取與該偽IP地址相匹配的登記過的FQDN信息。通過使用與調用的socket API相匹配的SOCKS命令（例如與connect()對應的CONNECT命令），FQDN信息被傳送到中繼服務器（網關G）上的*Gateway*。
·*Gateway*通過接收到的FQDN信息調用真正的DNS域名解析API從一個DNS服務器處獲得一個真IP地址，并利用真IP地址信息創(chuàng)建一個socket。*Gateway*再將socket用作API的一個參數來調用socket API與目的地D通信。
四、技術比較分析
雖然BIA與SOCKS64都是為了使IPv4能夠順利過渡到IPv6的技術，都是基于SOCKS的技術，都是采用雙棧主機思想，都需要使用偽IP地址，但是它們的出發(fā)點卻各有側重，也各有優(yōu)缺點。
1．適用性
BIA與SOCKS64都可以使IPv4應用在不作任何修改的情況下與IPv6主機通信。BIA技術提供的是具有IPv4和IPv6協(xié)議的雙棧主機直接與IPv6主機通信的解決方案，SOCKS64技術是提供了IPv4主機通過雙棧網關與IPv6主機通信的解決方案。
2. 預留IP地址的使用
BIA與SOCKS64都使用預留IP地址。雖然BIA技術中的地址池可以在節(jié)點中以不同的粒度來實現，然而如果大量的IPv4應用和IPv6的主機通信時，可能耗盡可用地址，導致IPv4應用不能和IPv6的主機通信，所以需要對地址池內的地址進行有效管理。SOCKS64技術由于主要使用FQDN信息、通過DNS域名解析代表 在*Socks Lib*處負責域名管理工作，偽地址必須被作為臨時值來處理，所以不需要為地址映射預留很大的地址空間，也不需要復雜的地址申請和垃圾收集機制。
3．對應用的支持
BIA與SOCKS64的初衷都是不需要修改IPv4應用而與IPv6主機通信。但是它們對應用的支持都不能達到盡善盡美。對于BIA來說，由于需要轉換嵌在應用層協(xié)議中的IP地址（例如FTP），所以這種機制可能不適用于那些其負載中包含地址的新應用。BIA僅支持單播通信，如果要支持組播通信，還需要在函數映射模塊中增加新的功能。BIA只是從語義上將IPv4 Socket API函數轉換成相應的IPv6 Socket API函數，如果在API函數中轉換內嵌于應用層協(xié)議的IP地址，其實現有賴于操作系統(tǒng)。由于IPv6的API具有新的高級參數，轉換帶有這種參數的IPv6 API是很困難的，因此接收到的帶有高級參數的IPv6數據包會被丟棄。對于SOCKS64來說，雖然它是直接繼承SOCKS機制的技術，但是在使用時仍有一定的問題。SOCKSv5協(xié)議由三個命令（CONNECT、BIND和UDP ASSOCIATE）組成，所有這三個命令在SOCKS64中都能使用。其中，主要的命令也是使用最頻繁的命令CONNECT沒有明確的弱點，可以不加考慮地隨意使用它。而BIND命令基本上是為支持FTP類型應用的反向通道聚合而設計的，所以通常的BIND命令的使用可能會導致一些問題。UDP ASSOCIATE命令基本上是為簡單UDP應用（如archie）而設計的，所以在支持同時使用TCP和UDP的一大類應用時通用性還不夠。另外，如果有些應用使用了非常靈活的、特別的方式創(chuàng)建連接，SOCKS64技術就無能為力了。
4．DNS查詢結果與另一端應用程序版本不匹配問題
對于BIA，若正在使用的服務器端應用不支持IPv6，但是它又運行在一臺支持其他IPv6服務的主機上，而且這臺主機還在DNS中以AAAA型記錄出現，在DNS的查詢結果和服務器應用的版本之間就出現了不匹配的情況。這時，使用BIA的IPv4客戶端應用可能連接不到這個服務器端應用上。解決方法是嘗試所有在DNS中列出的地址，而不應只嘗試一次即宣告失敗。但是對于UDP socket，即便可能，BIA也很難發(fā)現可工作的IP地址，因此應用必須重復嘗試各種可能的地址，直到發(fā)現一個可用地址為止。另一種避免這種問題的方法是僅當通信對端的A型記錄不存在時，BIA才發(fā)生作用。這樣，一臺采用BIA的雙棧主機上的應用到另一臺雙棧主機的數據流只使用IPv4協(xié)議。對于SOCKS64則不存在這個問題。
5．安全性
對于BIA，由于它采用了API翻譯器，很難實現端到端的安全性，而且傳輸層和應用層的安全也同樣無法實現。但是，由于翻譯機制發(fā)生在socket API層，采用BIA機制運行IPv4應用的主機和其他IPv6主機通信時，可以利用網絡層的安全策略(如IPsec)。另外，由于預留IP地址的使用，有地址耗盡的可能，這就使得使用這種機制的主機易于遭到拒絕服務攻擊。對于SOCKS64，由于它是直接建立在SOCKSv5協(xié)議基礎上的，其安全方面的特點與SOCKSv5相一致。它同樣不提供從原始源節(jié)點到最終目的節(jié)點的整體端到端的安全保證。但是由于它建立了應用層兩個“分開的”連接的中繼，所以端到端的安全就由這兩個被中繼的鏈接來提供保證。
五、結語
基于SOCKS的IPv4向IPv6過渡技術主要有BIA與SOCKS64兩種，它們都采用雙棧主機和IPv4預留地址思想，使IPv4應用在不作任何修改的情況下與IPv6主機通信。BIA技術提供的是具有IPv4和IPv6協(xié)議的雙棧主機直接與IPv6主機通信的解決方案，SOCKS64技術是提供了IPv4主機通過雙棧網關與IPv6主機通信的解決方案。也正由于它們是兩種不同的解決方案，才使得它們分別具有各自的優(yōu)點和缺點。在實際應用時，可以根據具體情況確定采用哪種技術，并根據需要對它們加以改進。
來源：酷網學院
