計算機專業(yè)外文翻譯--設計與實現(xiàn)由ipv4過渡到ipv6隧道

1、<p><b>　　附錄：</b></p><p>　　畢業(yè)設計(論文)外文資料翻譯</p><p>　　院 (系)： 計算機科學與工程學院 </p><p>　　專 業(yè)： 計算機科學與技術 </p><p>　　班 級：

2、 </p><p>　　姓 名： </p><p>　　學 號： </p><p>　　外文出處: ScienceDirect </p><p>

3、;　　附 件： 1.譯文；2.原文； </p><p>　　Journal of Network and</p><p>　　Computer Applications 31 (2008) 66–72</p><p>　　www.elsevier.com/locate/jnca</p><p>　　設計與實

4、現(xiàn)由IPv4過渡到IPv6隧道</p><p><b>　　的配置方案</b></p><p>　　Tushar M. Raste , D.B. Kulkarni</p><p>　　Department of Computer Science and Engineering, Walchand College of Engineerin

5、g,Sangli, India</p><p>　　Received 14 January 2005; received in revised form 28 June 2006; accepted 28 June 2006</p><p><b>　　摘要:</b></p><p>　　在現(xiàn)有的IPv4互聯(lián)網(wǎng)中配置IPv6網(wǎng)絡時，IPv4到

6、IPv6的過渡就成為一個必然的過程，在過渡期間兩種協(xié)議將會在較長的時間內共存。以滿足多方面的不同協(xié)議的需求，有許多種解決過渡問題的技術，隧道技術就是其中之一。隧道技術提供了一種以現(xiàn)有IPv4路由體系來傳遞IPv6數(shù)據(jù)的方法：將IPv6包作為無結構意義的數(shù)據(jù)，封裝在IPv4包中，被IPv4網(wǎng)絡傳輸。在本文里，我們將提出一種將IPv6包封裝在IPv4包中的方案。當大部分網(wǎng)絡轉換成只涉及最小IPv4路由的IPv6網(wǎng)絡時，此方案將會很有用處。&

7、lt;/p><p>　　此種技術結合上雙協(xié)議棧，便可實現(xiàn)IPv4與IPv6網(wǎng)絡環(huán)境的互通以及與其他IPv4應用程序的相互作用，而無需修改和再編譯，以及NAT，也不要任何代理與網(wǎng)關設置。</p><p>　　關鍵字：網(wǎng)絡，Ipv4，Ipv6</p><p>　　Corresponding author. Tel.:+ 912332301327; fax: +912332

8、300831.</p><p>　　E-mail addresses: tusharraste@yahoo.co.in (T.M. Raste), d_b_kulkarni@yahoo.com (D.B. Kulkarni).</p><p>　　1084-8045/$ - see front matter r 2007 Published by Elsevier Ltd. doi

9、:10.1016/j.jnca.2006.06.009</p><p><b>　　1. 引言</b></p><p>　　在純IPv6網(wǎng)絡（Dunn，2002）中，最初的IPv6配置（Davies,2002）需要緊密成對使用IPv4地址來支持IPv4與IPV6之間的網(wǎng)絡互連。其節(jié)點仍然需要與IPv4節(jié)點通信，但IPv4節(jié)點沒有雙IP層來支持IPv4與IPv6。這種機

10、制基于IPv4到IPv6隧道的使用(Wang et al.,2001)，以便在純IPv6網(wǎng)絡中支撐IPv4的通信。由于IPv4全局可用的路由地址空間正成為稀缺資源，人們認為用戶應在其一部分網(wǎng)絡中配置IPv6協(xié)議，以減少對IPv4協(xié)議的需求和依賴性。在這種前提下，輔助支持本地IPv4的同時，在很大程度上也增加了IPv6復雜的網(wǎng)絡管理（IP地址計劃，路由基礎設施）。因此在這種情況下建議用戶只配置IPv6網(wǎng)絡。</p><

11、p>　　當在一個網(wǎng)絡中配置隧道技術時，節(jié)點同時具有分配的IPv4和IPv6地址。當一個IPv4應用程序需要在一個IPv6節(jié)點或另一個純IPv4節(jié)點上與另一個IPv4應用程序建立通信時，隧道技術會被配置。這允許IPv6節(jié)點與純IPv4節(jié)點通訊，或者純IPv4應用程序在IPv6節(jié)點上不用修改而運行。這樣在一個IPv6域中，IPv4包被隱藏于IPv6包中(Bound et al., 2000)。這樣在網(wǎng)絡中就只需要管理IPv6路由計劃，

12、即簡化了網(wǎng)絡管理。</p><p>　　2. IPv4棧的配置</p><p>　　只要能在本地的IPv6通訊，就不需要隧道技術機制的支持。主機能通過不同的方法檢測到是否需要隧道技術：當在IPv4的目標地址查詢到DNS分解器時；當一個應用程序打開一個IPv4套接字時；或者當一個IPv4包被發(fā)送到內核并且沒有界面準備轉發(fā)那個包(Bound et al., 2000)時。在需要發(fā)送第一個IPv

13、4包時，客戶端會獲得一個TEP的IPv6地址(Affifi and Tountain,1999)，此信息將用來配置4到6的界面。</p><p>　　隧道設定中重要的一步是為隧道創(chuàng)建一個虛擬的界面以及在IPv4節(jié)點的路由選擇表中創(chuàng)建一個路由輸入。這使得IPv4應用程序能夠將IPv4包轉入到隧道代碼中。網(wǎng)濾器鉤可用來探測是否需要在節(jié)點上安裝這樣一個隧道。</p><p><b>　

14、　3. 網(wǎng)濾器鉤</b></p><p>　　創(chuàng)建虛擬界面的需要可由網(wǎng)濾器鉤來探測(Netfilter homopage; Chakeres)?？赏ㄟ^識別許多激發(fā)路由活動的事件的操作來使用網(wǎng)濾器。網(wǎng)濾器由在Linux協(xié)議棧中的不同點上的許多鉤子構成。它允許用戶定義的內</p><p>　　圖1. 網(wǎng)濾器鉤.</p><p>　　核模塊將回收函數(shù)注冊到這

15、些鉤子上。一個數(shù)據(jù)包橫越鉤子時，數(shù)據(jù)包會通過內核模塊中用戶自定義的回收方法。</p><p>　　網(wǎng)濾器結構中定義有五個鉤子，見圖1。在圖的頂端有兩個鉤子，NF_IP_LOCAL_IN 和 NF_IP_LOCAL_OUT。這些鉤子的對象是所有來往于局部過程的數(shù)據(jù)包。在圖的底端有兩個鉤子，NF_IP_PRE_ROUTING NF_IP_ POST_ROUTING。它們的對象是來往于網(wǎng)絡上其他主機的所有數(shù)據(jù)包。還有一

16、個鉤子是用于當前主機轉發(fā)的數(shù)據(jù)包，NF_IP_FORWARD。假設一個本地進程為一個遠程進程創(chuàng)建一個數(shù)據(jù)包，作為一個數(shù)據(jù)包如何橫越這些鉤子的例子：首先，數(shù)據(jù)包橫越NF_IP_LOCAL_OUT鉤子。下一步，執(zhí)行一個路由選擇判斷看數(shù)據(jù)包是否駛往本地主機或網(wǎng)絡中的另一個主機。數(shù)據(jù)包會被發(fā)現(xiàn)是為一個遠程主機安排的，并通過NF_IP_POST_ROUTING鉤子被傳遞到一個網(wǎng)絡界面上。注冊的回收函數(shù)返回下面五個值中的一個:NF_ACCEPT(接

17、受數(shù)據(jù)包并繼續(xù)數(shù)據(jù)鏈)，NF_DROP (丟棄數(shù)據(jù)包), NF_QUEUE(將數(shù)據(jù)包排隊到用戶空間中)或者NF_STOLEN (從網(wǎng)絡中竊得的數(shù)據(jù)包)。</p><p><b>　　4.虛擬界面</b></p><p>　　從內核角度來說，一個網(wǎng)絡界面是一個軟件對象，它可以處理外流的數(shù)據(jù)包，而實際的傳輸機制隱藏于界面驅動中。即使大多數(shù)界面被關聯(lián)到物理設備（或對于回環(huán)界

18、面，關聯(lián)到純軟件的數(shù)據(jù)循環(huán)），設計出依賴于其他界面來執(zhí)行實際數(shù)據(jù)包傳輸?shù)木W(wǎng)絡界面驅動是有可能的。</p><p>　　“虛擬”界面的想法有助于對特殊目的的數(shù)據(jù)包處理，同時避免黑客入侵內核網(wǎng)絡子系統(tǒng)。這個想法可用于將數(shù)據(jù)包配置到另一個協(xié)議中。因此，創(chuàng)建一個隧道暗指在內核中創(chuàng)建一個虛擬界面，并將封裝信息保留在專用數(shù)據(jù)結構中。</p><p><b>　　5. 設計</b>

19、</p><p>　　提出的設計方案是使用NF_IP_LOCAL_OUT鉤子來探測是否需要隧道。當一個本地進程生成的IPv4數(shù)據(jù)包通過這個鉤子，針對此鉤子定義的回收函數(shù)將有以下任務：</p><p>　　決定目的地IPv6地址。</p><p>　　若目的地為IPv6主機，則為遠程主機創(chuàng)建一個隧道。</p><p>　　若目的地在純IPv4網(wǎng)

20、絡中則為邊界路由器創(chuàng)建一個隧道。邊界路由器存在于IPv6和IPv4域的邊界處。</p><p>　　創(chuàng)建合適的路由選擇表輸入。</p><p>　　這樣，回收函數(shù)有了一個外部分解器的任務(Tsuchiya et al., 2002)，即解析一個IPv4地址，也就是說進入一個IPv6地址的A記錄，即AAAA記錄。為此，它會生成一個對DNS服務器的DNS查詢。再一次，隧道的創(chuàng)建可在內核空間中進

21、行。注冊的函數(shù)將執(zhí)行創(chuàng)建虛擬界面的任務并和新創(chuàng)建的設備一起配置隧道數(shù)據(jù)結構。隧道參數(shù)可存儲于界面的私有數(shù)據(jù)結構中。</p><p>　　一旦設備被創(chuàng)建出來，那么一個目的地路由就可與之關聯(lián)，如此一來，數(shù)據(jù)包就能被轉向這個界面了。傳輸函數(shù)就能利用儲存在隧道私有數(shù)據(jù)結構中的信息，有組織地封裝這些數(shù)據(jù)包（圖2）。接下來回收函數(shù)就能返回NF_ACCEPT的一個判斷以便數(shù)據(jù)包返回網(wǎng)絡棧中。接著由內核作出路由判斷。</p

22、><p>　　一個IPv6域中的用戶空間守護程序被配置用于傳達在IPv4目的地建立隧道的需求，或者是邊界路由器的目的地在IPv4域中。</p><p>　　一種新的被稱為IPIP（值4）的協(xié)議被注冊用于接收那些隧道數(shù)據(jù)包。注冊程序涉及到一些用于處理這些隧道數(shù)據(jù)包及生成錯誤信息（ICMP信息）的特定函數(shù)。接收函數(shù)移除IPv6頭信息并且模擬另一個接收程序，此時一個IPv4數(shù)據(jù)包被接收，虛擬界面的一

23、些參數(shù)被調整以便IPv4數(shù)據(jù)包的接收可通過虛擬設備來模擬。</p><p>　　圖2. 數(shù)據(jù)包的接收.</p><p><b>　　6.性能</b></p><p><b>　　6.1延遲時間</b></p><p>　　在性能評估中，隧道式機制傳輸平均延遲時間(Tsuchiya et al., 2

24、000; Raicu and Zeadally,2003)第一。平均延遲時間是指把時間作為一個封包通過網(wǎng)路連接從發(fā)送者傳輸?shù)浇邮苷?。測試的執(zhí)行是通過Ping</p><p><b>　　4</b></p><p><b>　　3.5</b></p><p><b>　　3</b></p>

25、<p><b>　　IPv4</b></p><p><b>　　Tunneled</b></p><p><b>　　Latency</b></p><p><b>　　2.5</b></p><p><b>　　2</b&g

26、t;</p><p><b>　　1.5</b></p><p><b>　　1</b></p><p><b>　　0.5</b></p><p><b>　　0</b></p><p><b>　　64128<

27、/b></p><p><b>　　256</b></p><p><b>　　數(shù)據(jù)包大小</b></p><p><b>　　512</b></p><p><b>　　768</b></p><p>　　圖3.延遲時間分析

28、.</p><p><b>　　2500</b></p><p>　　Throughput</p><p><b>　　2000</b></p><p><b>　　IPv4</b></p><p><b>　　Tunneled</b&g

29、t;</p><p><b>　　1500</b></p><p><b>　　1000</b></p><p><b>　　500</b></p><p><b>　　0</b></p><p><b>　　64128

30、</b></p><p><b>　　256</b></p><p><b>　　512</b></p><p><b>　　768</b></p><p><b>　　數(shù)據(jù)包 (字節(jié))</b></p><p>　　圖4

31、. 吞吐量分析.</p><p>　　程序運行在可靠的ICMP網(wǎng)絡層上，ping程序的功能是發(fā)送回應請求包來控制指定節(jié)點和檢查回應訊息，并以此來判定特殊節(jié)點是否存活。</p><p>　　延遲的測量是從客戶端向服務器發(fā)送64，128，258，512及768字節(jié)的數(shù)據(jù)包，服務器一旦收到數(shù)據(jù)包即立刻回送給客戶端。整個過程將重復進行，周期循環(huán)1000次。</p><p>

32、;　　圖3顯示：IPv4包與隧道包延遲的比較，數(shù)據(jù)包的大小由64字節(jié)到768字節(jié)的不同。隨著數(shù)據(jù)包字節(jié)的改變，總值呈現(xiàn)出由7%到30%的變化?？傊党霈F(xiàn)于隧道包封裝與DE封裝的所需時間。</p><p><b>　　6.2 吞吐量</b></p><p>　　吞吐量(Tsuchiya et al.,2000; Raicu and Zeadally,2003)定義是：總的

33、數(shù)據(jù)包傳輸?shù)饺柯窂降膯挝粫r間。吞吐量的計算公式為T =P/L,T指吞吐量，P指千字節(jié)的數(shù)據(jù)包大小，L指找到一致的數(shù)據(jù)包大小的延遲時間。圖4是對64字節(jié)到768字節(jié)的數(shù)據(jù)包大小的吞吐量的分析。</p><p>　　在IPv6協(xié)議棧，數(shù)據(jù)包大小始終保持在小于1440字節(jié)以避免潛在的分裂程序。最大的吞吐量達到最大的數(shù)據(jù)包大小。吞吐量一般隨著數(shù)據(jù)包大小的增加而增大。總值從7%到30%的變化取決于數(shù)據(jù)包大小?？傊惦S著數(shù)據(jù)

34、包大小的增大而減少（圖4）。</p><p>　　7.與其他機制的比較</p><p>　　本節(jié)，講述一些關于IETF下一代過渡技術工作組的相關工作(Ngtrans) (Waddington and Chang,2002)。</p><p>　　雙協(xié)議棧(Bound and Tountain,1999)機制是兩種基本傳輸機制的一種，在主機與路由器中雙協(xié)議?？赏耆С?/p>

35、IPv4和IPv6。但是它不可以減少對全局路由IPv4地址的需求，以及提高IPv4與IPv6混合路由設施的網(wǎng)絡復雜性。 </p><p>　　應用層網(wǎng)關（ALG）,SOCKS64 (Kitamura et al.,2000)和TCP繼電器(Kitamura et al.,2000)是可以提供在IPv4與IPv6之間通信的代理機制。在應用程序或者TCP連接層它們都可分離一個IP連接到兩個封閉的連接，其中之一在I

36、Pv4網(wǎng)絡，另一個在IPv6網(wǎng)絡。它們共同的缺點是打破因特網(wǎng)點對點的原則，而此原則對電子商務以及商業(yè)通信非常的重要。ALG是一種應用程序-從屬機制，它是指對不同的應用程序它應提供不同的應用程序網(wǎng)關組件。SOCKS64可只為包含于SOCKS客戶與SOCKS服務器的網(wǎng)站服務。NATPT (Tsirtsis and Srisureshi,2000)來源于傳統(tǒng)的NAT (Srisureshi and Hodrege, 1999)機制，再加上IP

37、v4與IPv6協(xié)議的協(xié)議轉換。BIS (Tsuchiya et al.,2000) 由尋址轉換器模組到節(jié)點系統(tǒng)，與一個地址映射以及延伸到名稱分解器，以次來促進轉換。SIIT (Nordmark,2000)提供了一個從IPv4到IPv6靈活與無狀態(tài)的轉化，但是它是不完備的，因為它沒有指定在I</p><p>　　8. 結論與前景展望</p><p>　　概括起來我們提議的方案有下列優(yōu)勢：在全

38、局網(wǎng)絡上純IPv6主機可以匹配于純IPv4節(jié)點。在一個純IPv6環(huán)境上不孤立于主機與其他的</p><p>　　網(wǎng)絡，應用程序還沒到達IPv6之前就可以運行在純IPv6主機與網(wǎng)絡上，此時網(wǎng)絡可只配置IPv6，這里就不需要配置地址與IPv4路由。任何類型的協(xié)議/應用程序可顯然地傳遞，不需要配置翻譯器。</p><p>　　標準模型假設IPv6節(jié)點含有有效的IPv4與IPv6地址，在將來當節(jié)點

39、升級為IPv6領域，這時IPv4地址只需要臨時IPv4節(jié)點通信。對IPv6節(jié)點一個機制必須去探測IPv4地址。此時這個機制將需要探測核心層，追蹤IPv4 API系統(tǒng)呼叫。所以程序需要從服務器獲得IPv4地址，這個程序也許利用DHCPv6或者RPCv6，再或者利用特別設計的目標，同樣地服務器需要維護全局的IPv4地址。</p><p><b>　　參考文獻</b></p><

40、;p>　　Af??, H., Tountain, L., ENST Bretagne, Methods for IPv4-IPv6 Transition. IEEE 1999.</p><p>　　Bound, J., Tountain, L., Af??, H., Dupont, F., Durand, A., dual stack transition mechanism (DSTM) Int

41、ernet draft (draft-ietfngtrans dstm-007.txt) 2002.</p><p>　　Chakeres, I.D., AODV-UCSB Implementation, University of California Santa Barbara. /http://moment.cs.ucs- b.edu/AODV/aodv.htmlS.</p>&l

42、t;p>　　Davies, J., Introduction to IP version 6 Microsoft Press, February 2002. Dunn, T., The IPv6 transition. IEEE Internet Comput 2002.</p><p>　　Kitamura, H., Jinzaki, A., Kobayashi, S., A socks bas

43、ed IPv6/IPv4 gateway mechanism Internet Draft ‘‘draft-ietf-</p><p>　　ngtrans-socks-gateway-06.txt’’ 2000.</p><p>　　Net?lter homepage /http://www.net?lter.org/S.</p><p>　　Nordmark

44、, E., Stateless IP/ICMP translator algorithm (SIIT). RFC2765 February 2000. Raicu, I., Zeadally, S., Evalating IPv4 to IPv6 transition mechanisms. IEEE September 2003.</p><p>　　Srisuresh, P., Holdrege

45、, M., IP network address translator (NAT) terminology and considerations. RFC2663</p><p>　　August 1999.</p><p>　　Tsuchiya, K, Higuchi H., Atarashi, Y., Dual stack hosts using

46、the bump in the stack technique, RFC2767</p><p>　　February 2000.</p><p>　　Tsirtsis, G., Srisuresh, P., Network address translation-protocol translation (NAT-PT). RFC2766, Febr

47、uary</p><p><b>　　2000.</b></p><p>　　Waddington, D., Chang, F., Realizing the transition to IPv6. IEEE Comm Mag 2002.</p><p>　　Wang, K., Yeo, A.K., Ananda, A.L., D

48、TTS: a transparent and scalable solution for IPv4 to IPv6 transition</p><p>　　Proceedings of the tenth international conference on computer communication and networks, IEEE 2001.</p><p

49、>　　Journal of Network and</p><p>　　Computer Applications 31 (2008) 66–72</p><p>　　www.elsevier.com/locate/jnca</p><p>　　Research note</p><p>　　Design and impleme

50、ntation scheme for deploying</p><p>　　IPv4 over IPv6 tunnel</p><p>　　Tushar M. Raste , D.B. Kulkarni</p><p>　　Department of Computer Science and Engineering, Walchand College of

51、Engineering,Sangli, India</p><p>　　Received 14 January 2005; received in revised form 28 June 2006; accepted 28 June 2006</p><p><b>　　Abstract:</b></p><p>　　IPv4 to IPv

52、6 transition is an inevitable process when deploying IPv6 networks within the present IPv4 Internet. The two protocols are expected to coexist for a number of years during the transition period. A number of transitio

53、n techniques exist to address the various needs of different networks. One of them is tunneling mechanism. Tunneling means encapsulation of one protocol into another one so that the encapsulated protocol is send

54、 as payload on the network. In this paper, a s</p><p>　　This technique, coupled with the dual stack approach, enables IPv4 applications to run and interact with other IPv4 applications i

55、n both IPv4 and IPv6 network environments without any modi?cation and recompilation, and without NAT, nor any application proxy or gateway.</p><p>　　r 2007 Published by Elsevier Ltd.</p><

56、;p>　　Keywords: Network; Ipv4; Ipv6</p><p>　　1. Introduction</p><p>　　The initial deployment of IPv6 (Davies, 2002) will require a tightly coupled use of IPv4 addresses to support the int

57、eroperation of IPv6 and IPv4 within an IPv6-only Network (Dunn, 2002). Nodes will still need to communicate with IPv4 nodes that do not have a dual IP layer supporting both IPv4 and IPv6. The mechanism proposed is

58、based on the use</p><p>　　Corresponding author. Tel.:+ 912332301327; fax: +912332300831.</p><p>　　E-mail addresses: tusharraste@yahoo.co.in (T.M. Raste), d_b_kulkarni@yahoo.com (D.B. Kulkarni)

59、.</p><p>　　1084-8045/$ - see front matter r 2007 Published by Elsevier Ltd. doi:10.1016/j.jnca.2006.06.009</p><p>　　of IPv4-over-IPv6 tunnels (Wang et al., 2001) to carry IPv4 traf?c wit

60、hin an IPv6-only network. Since the IPv4 globally routable address space available is becoming a scarce resource, it is assumed that users will deploy IPv6 to reduce the need and reliability on IPv4 within a porti

61、on of their networks. Under this premise, supporting native IPv4 and native IPv6 simultaneously largely increases the complexity of network administration (address plan, routing infrastructure). It i</p><

62、;p>　　When tunneling is deployed in a network, the nodes have both IPv4 and IPv6 addresses allocated. When an IPv4 application needs to establish communication with another IPv4 application on IPv6 node or another

63、 IPv4 only node, tunneling is employed. This allows either IPv6 nodes to communicate with IPv4-only nodes, or IPv4-only applications to run on an IPv6 node without modi?cation. Thus IPv4 packets are hidden in the IPv

64、6 packets on an IPv6 domain (Bound et al., 2000). This simpli?es n</p><p>　　2. Con?guration of IPv4 stack</p><p>　　As long as communications can take place in native IPv6, no tunneling mec

65、hanism is required. The host can detect the need of a tunnel by different methods: when a query to the DNS resolver results in an IPv4 destination address, when an application opens an IPv4 socket, or when an

66、IPv4 packet is sent to the kernel and no interface is ready to forward that packet (Bound et al., 2000). When the ?rst IPv4 packet needs to be sent, the client obtains the IPv6 address of a TEP (A</p><

67、;p>　　The important step in tunnel con?guration is creation of a virtual interface for the tunnel and creation of a route entry in the IPv4 routing table of the node. This enables the IPv4 application to diver

68、t the IPv4 packets to the tunnel code written in the kernel. Net- ?lter hooks can be used to detect the need to install such a tunnel on the node.</p><p>　　3. Net-?lter hooks</p><p>　　The

69、need for virtual interface creation can be detected by using net-?lter (Net?lter homopage; Chakeres) hooks. Net-?lter can be used by our implementation to identify many of the events that trigger the r

70、outing action. Net-?lter consists of a number of hooks at various points inside the Linux protocol stack. It allows user-de?ned kernel modules to register callback functions to these hooks. When a packet traverse

71、s a hook, the packet ?ows through the user de?ned ca</p><p>　　There are ?ve hooks de?ned in the net-?lter architecture, as shown in Fig. 1 At the top of the ?gure there are two hooks, NF_IP_LOCAL_IN

72、and NF_IP_LOCAL_OUT. These hooks are for all packets to and from local processes. At the bottom of the ?gure there are two hooks, NF_IP_PRE_ROUTING and NF_IP_POST_ROUTING. These are for all packets from and to ot

73、her hosts on the network. There is also a hook for packets that are forwarded by the current host, NF_IP_FORWARD. As an example </p><p>　　Fig. 1. Net-?lter hooks.</p><p>　　NF_IP_POST_

74、ROUTING hook and then onto a network interface. The call back function registered returns one of the ?ve values NF_ACCEPT (accept the packet and continue the chain), NF_DROP (drop the packet), NF_QUE

75、UE (queue the packet to user space) or NF_STOLEN (packet stolen from network stack).</p><p>　　4. Virtual interface</p><p>　　From the kernel’s point of view, a network interface is a software

76、 object that can process outgoing packets, and the actual transmission mechanism remains hidden inside the interface driver. Even though most interfaces are associated to physical devices (or, for the loopbac

77、k interface, to a software-only data loop), it is possible to design network interface drivers that rely on other interfaces to perform actual packet transmission.</p><p>　　The idea of a ‘‘virtual’’ int

78、erface can be useful to implement special-purpose processing on data packets while avoiding hacking with the network subsystem of the kernel. This idea can be used in tunneling of packets inside another protocol

79、. Thus creating a tunnel implies creating a virtual interface in the kernel and maintaining the information for encapsulation in its private data structure.</p><p>　　5. Design</p><

80、;p>　　The proposed design uses the NF_IP_LOCAL_OUT hook to detect the need of a tunnel. When a local process generates IPv4 packets they pass through this hook. A call back function de?ned for this hoo

81、k will have the following tasks:</p><p>　　1. Determine the destination IPv6 address.</p><p>　　2. If the destination is an IPv6 host, create a tunnel for the remote host.</p><p>

82、　　3. If the destination is on IPv4-only network then create a tunnel for the border router. A</p><p>　　border router resides on the boundary between IPv6 domain and IPv4 domain.</p><p>　　

83、4. Create the appropriate IPv4 routing table entry.</p><p>　　The call back function thus has the job of an extension resolver (Tsuchiya et al., 2002), i.e. resolve an IPv4 address, i.e. an A record into an

84、 IPv6 address, i.e. AAAA record. Thus it will generate a DNS query to the DNS server for this purpose. Creation of the tunnel can be again done in kernel space. The function registered will carry out the task of creatin

85、g a virtual interface and con?guring a tunnel data structure with the newly created device. The tunnel parameters can be stored in th</p><p>　　Once the device is created then a route for the destination c

86、an be associated with the device so that the packets can be diverted to this interface. The transmission function can then systematically encapsulate the packets using the information stored in the tunnel’s p

87、rivate data structure (Fig. 2). The call back function after registering the device can then return a verdict of NF_ACCEPT so that the packet returns to the network stack. The routing decision is then made in the kerne&

88、lt;/p><p>　　A user space daemon in the IPv6 domain is deployed to communicate the need of establishing</p><p>　　a tunnel at the IPv4 destination, or the border router if the destination is in I

89、Pv4 domain. For reception of such tunneled packets a new protocol called IPIP protocol (value 4) is</p><p>　　registered with the kernel. This registration process involves specifying functions for process

90、ing such tunneled packets and generating error messages (ICMP messages). The receiving function then removes the IPv6 header and simulates another reception process where this time an IPv4 packet is received

91、 and the parameters for virtual interface are adjusted so that the reception of IPv4 packets is simulated through the virtual device.</p><p>　　6. Performance</p><p>　　6.1. Latency&

92、lt;/p><p>　　In evaluating the performance of the tunneling-based mechanism the average transmission latency (Tsuchiya et al., 2000; Raicu and Zeadally, 2003) was measured ?rst. The

93、average transmission latency is the time taken for a packet to be transmitted across a network connection from sender to receiver. Tests were performed using the ping</p><p>　　Fig. 2. Packet Recepti

94、on.</p><p>　　program run on a reliable ICMP Internet layer. The ping utility sends ICMP echo request packets to the command argument speci?ed node and checks for a replayed message, to determine whether

95、 a particular node is alive.</p><p>　　Latency was measured by sending packets of size 64,128,256,512 and 768 bytes from a client to a server. Upon receipt of a packet the server replays the packet back to

96、the client. The whole process is repeated; the cycle is iterated 1000 times.</p><p>　　Fig. 3 shows the comparative latency for IPv4 packets and tunneled packets as the packet size is varied from

97、64 bytes to 768 bytes. The overhead varies from 7% to 30% as the packet size is varied. The overhead occurs due to the time required for encapsulation and de-capsulation of the tunneled packets.</p><p>

98、　　6.2. Throughput</p><p>　　Throughput (Tsuchiya et al., 2000; Raicu and Zeadally, 2003) is de?ned as the amount of packet data that is transmitted over the entire path per unit time. The throughput is

99、 calculated from the formula T ¼ P/L, where T is the throughput, P is the packet size in kbits and L is the latency that corresponds to a packet of that size. The following ?gure plots the throughput for pack

100、et size ranging from 64 to 768 bytes.</p><p>　　The packet size was kept less than 1440 bytes to avoid potential fragmentation problem in the IPv6 protocol stack. The maximum throughput is reached for

101、largest packet size. The throughput generally increases with the increase in packet size. The overhead varies from 7% to 30% depending upon the packet size. The overhead decreases with increase in the packet size (Fi

102、g. 4).</p><p>　　7. Comparison with other mechanisms</p><p>　　In this section, some related works proposed under IETF Next Generation Transition</p><p>　　Working group (Ngtran

103、s) (Waddington and Chang, 2002).</p><p><b>　　4</b></p><p><b>　　3.5</b></p><p><b>　　3</b></p><p><b>　　IPv4</b></p>

104、;<p><b>　　Tunneled</b></p><p><b>　　Latency</b></p><p><b>　　2.5</b></p><p><b>　　2</b></p><p><b>　　1.5</b&

105、gt;</p><p><b>　　1</b></p><p><b>　　0.5</b></p><p><b>　　0</b></p><p><b>　　64128</b></p><p><b>　　256<

106、;/b></p><p>　　Packet Size</p><p><b>　　512</b></p><p><b>　　768</b></p><p>　　Fig. 3. Latency analysis.</p><p><b>　　2500<

107、/b></p><p>　　Throughput</p><p><b>　　2000</b></p><p><b>　　IPv4</b></p><p><b>　　Tunneled</b></p><p><b>　　1500<