[導讀]針對上述問題我們研究了一種過渡機制，并針對該過渡機制設計實現(xiàn)了瀏覽器模式的IPv4客戶機對 IPv6服務器的訪問。
摘要 隨著Internet網(wǎng)絡在全球范圍內的迅速擴大，應用日益增加，IP地址即將耗盡的矛盾更加突出，同時為解決IPv4的設計缺陷，國際互聯(lián)網(wǎng)工程任務組開發(fā)了新一代Internet協(xié)議-IPv6，但由于IPv4與IPv6之間存在著很大的差異，同時存在眾多基于IPv4協(xié)議的網(wǎng)絡及應用，因此，要用新的IPv6代替舊的IPv4必然存在一個過渡時期。針對上述問題我們研究了一種過渡機制，并針對該過渡機制設計實現(xiàn)了瀏覽器模式的IPv4客戶機對 IPv6服務器的訪問。
關鍵詞 IPv4 IPv6 過渡機制 雙協(xié)議棧 代理服務 Java
前 言
如今，Internet在全球范圍內的普及應用超過了歷史上的任何一項新技術所產生的影響和帶來的變化，實踐證明，IPv4不僅是健壯的、而且是易于實現(xiàn)的，并具有很好的互操作性。這些都充分肯定了IPv4協(xié)議（IPv4 protocol）初始設計的正確性。但是隨著Internet迅速發(fā)展，接入Internet的網(wǎng)絡設備和運行在其上的應用程序急劇增加，由此帶來了 IP地址的迅速耗盡與路由表膨脹等問題，對IP地址范圍的擴大也迫在眉睫。針對IP地址的問題，IETF（Internet 工程任務組）提出了新一代網(wǎng)際互聯(lián)協(xié)議——IPv6協(xié)議（IPv6 protocol），它不但解決了IPv4的地址問題，并且改善了IP協(xié)議的性能[1,2]。而在現(xiàn)階段中，由于Internet完全是建立在IPv4的體系結構上，所有的應用程序也是按照IPv4格式書寫的。因此如何由IPv4向IPv6過渡以及由此而產生的過渡機制成為了一個新的研究熱點。針對IPv4向IPv6的過渡，我們研究了用雙協(xié)議棧來過渡的方式，遵循IPv4中的代理服務機制，嘗試實現(xiàn)了用Firefox為瀏覽器通過雙協(xié)議棧的代理服務器訪問基于IPv6的網(wǎng)頁。
1 IPv4向IPv6的過渡
1.1 過渡的必然性
隨著Internet應用范圍的擴大，發(fā)現(xiàn)IPv4有著很多不可克服的問題，必須通過新的協(xié)議來最終替代。通常，協(xié)議的過渡是很不容易的，從IPv4向 IPv6的過渡也是如此。目前由于IPv4協(xié)議已經(jīng)成功的使用了將近20年，基于IPv4的應用程序和設備已經(jīng)相當成熟和具有相當?shù)囊?guī)模，不可能一夜之間完成所有升級變更。而另一方面，IPv6的應用程序和設備還不成熟完備，這樣必然會出現(xiàn)許多孤立的IPv6網(wǎng)絡。那么如何完成從IPv4向IPv6的過渡，是發(fā)展IPv6首要解決的問題。由此在相當長時間內，IPv6節(jié)點之間的通信還要依賴于原有IPv4網(wǎng)絡的設施，同時IPv6節(jié)點也必不可少的要與 IPv4節(jié)點通信，因此過渡是不可避免的，并且過渡[3]必將是分布式的、漸進的進行。據(jù)專家的預測，過渡初期的 Internet將由少量運行 IPv6協(xié)議設備組成小的網(wǎng)絡“孤島”和大量運行 IPv4協(xié)議的設備組成的“海洋”組成。如圖1所示：
|
圖1：IPv4網(wǎng)絡海洋中的IPv6孤島 |
1.2 過渡策略的主要原則
考慮到網(wǎng)絡技術的飛速發(fā)展和現(xiàn)實世界的商業(yè)需求，在進行IPv4網(wǎng)絡向IPv6網(wǎng)絡過渡策略的設計中，如下方向性問題必須遵循，在“下一代協(xié)議建議規(guī)范”（RFC1752）中，明確定義了以下的過渡原則：
1. 過渡方式應該是逐步的和漸進的，保護IPv4網(wǎng)絡設備的投資，確保在一個相當長的歷史階段，IPv4網(wǎng)絡設備可以在過渡時期中正常地獨立使用。
2. IPv4網(wǎng)絡世界和IPv6網(wǎng)絡世界相互滲透，長期并存，這就要求IPv4和IPv6網(wǎng)絡設備彼此可以互連互通，實現(xiàn)互操作。
3. IPv4網(wǎng)絡世界向IPv6網(wǎng)絡世界過渡過程中，IPv4向IPv6升級的費用應盡可能地低，過渡技術應盡可能地簡單，以盡快地吸引廣大用戶主動的向IPv6過渡。
由于IPv4協(xié)議和IPv6協(xié)議之間不具有相關性，因此IPv4和IPv6體系結構之間還需要構建相關的過渡機制來支持二者無縫地并存。
2 過渡方案設計與實現(xiàn)
2.1 IPv4/IPv6雙協(xié)議棧代理服務器原理
借鑒傳統(tǒng)的IPv4代理服務器原理，聯(lián)想到在一臺代理服務器上安裝具有IPv4/IPv6雙協(xié)議棧，那么代理服務器就可以作為IPv4客戶端向IPv6服務器的“中轉站”，從而實現(xiàn)兩者間的間接通信。其具體實現(xiàn)原理如圖2。
|
|
|
圖2 IPv4應用程序通過代理訪問IPv6服務器 |
2.2 IPv4/IPv6過度方案設計與實現(xiàn)
本方案立足于應用最為普遍的瀏覽器技術，而直接改寫瀏覽器本身的代碼是不現(xiàn)實的，因此我們采用一種比較直接的解決方案：在雙協(xié)議棧主機的傳輸層中，借鑒傳統(tǒng)IPv4的傳輸層代理機制對IPv4和IPv6協(xié)議進行“轉換”，從而讓僅支持IPv4的應用程序無需升級就能夠“無縫”地訪問純IPv6服務。這樣我們只需對代理服務器編程，同時利用socket的獨立于網(wǎng)絡協(xié)議的特性，通過編寫程序完成對socket套接字中某些參數(shù)的修改，讓代理服務器調用系統(tǒng)的 IPv6協(xié)議棧來通信，實現(xiàn)接入IPv6。實現(xiàn)上述設計思路的關鍵就是對編寫修改完成對socket套接字中某些參數(shù)的修改并完成調用，下面是構造代理服務器過程相關代碼提煉如下：
//在給定Socket上創(chuàng)建一個代理線程。public HttpProxy(Socket s) { socket=s; start(); }
public void writeLog(int c, boolean browser) throws IOException { log.write(c); } public void writeLog(byte[] bytes,int offset, int len, boolean browser) throws IOException {for (int i=0;i<len;i++) writeLog((int)bytes[offset+i],browser);
} public String processHostName(String url, String host, int port, Socket sock) { java.text.DateFormat cal=java.text.DateFormat.getDateTimeInstance(); System.out.println(cal.format(new java.util.Date()) + " - " + url + " " + sock.getInetAddress()+"<BR>"); return host;//執(zhí)行操作的線程public void run() { Socket outbound=null;
try { socket.setSoTimeout(TIMEOUT); InputStream is=socket.getInputStream(); OutputStream os=null; …… outbound.setSoTimeout(TIMEOUT); os=outbound.getOutputStream(); os.write(line.getBytes()); os.write(' '); os.write(host0.getBytes()); os.write(' ');……
…… 和所有線程對象一樣，HttpProxy類的主要工作在run方法內完成。run方法實現(xiàn)了一個簡單的狀態(tài)機，從Web瀏覽器每次一個讀取字符，持續(xù)這個過程直至有足夠的信息找出目標Web服務器。然后，run打開一個通向該Web服務器的Socket（如果有多個代理服務器被鏈接在一起，則run方法打開一個通向鏈里面下一個代理服務器的Socket）。打開Socket之后，run先把部分的請求寫入Socket，然后調用pipe方法。pipe方法直接在兩個Socket之間以最快的速度執(zhí)行讀寫操作。完成了代理服務器程序的設計后，要使得客戶端能使用代理，還需要在客戶端的瀏覽器進行相應的設置，即在瀏覽器中配置代理服務器，這樣就完成了全部過程。
3 結論
Internet的發(fā)展趨勢將證明IPv4必將會被IPv6所替代，但其過渡過程也一定會是一個漫長的、艱難的。因此，對過渡問題的研究不僅有利于完成過渡，而且還能保障Internet網(wǎng)絡長期穩(wěn)定運行。本設計不僅能夠完成轉換同時采用較低成本模式，形成一個解決方案，系統(tǒng)測試的結果表明所采取的技術是合理的，能夠滿足實際運行需要。
參考文獻
[1]周玲，尹霞， 吳建平. 實現(xiàn)IPv4向IPv6過渡的隧道技術.計算機工程與應用，2002:156
[2]Jim Bound, L aurent Toutain. Dual Stack transition mechanism(DSTM) http://www.ietf.org/interner-drafts/draft-ietf-ngtrans-dstm-00.txt, October,1999
[3]R.Hinden . RFC2732: Format for Literal IPv6 Address in URL’s , 2002-12
下載文檔
