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

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

2、 </p><p>　　姓 名： </p><p>　　學(xué) 號： </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>　　設(shè)計(jì)與實(shí)

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)絡(luò)時(shí)，IPv4到

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

7、lt;/p><p>　　此種技術(shù)結(jié)合上雙協(xié)議棧，便可實(shí)現(xiàn)IPv4與IPv6網(wǎng)絡(luò)環(huán)境的互通以及與其他IPv4應(yīng)用程序的相互作用，而無需修改和再編譯，以及NAT，也不要任何代理與網(wǎng)關(guān)設(shè)置。</p><p>　　關(guān)鍵字：網(wǎng)絡(luò)，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)絡(luò)（Dunn，2002）中，最初的IPv6配置（Davies,2002）需要緊密成對使用IPv4地址來支持IPv4與IPV6之間的網(wǎng)絡(luò)互連。其節(jié)點(diǎn)仍然需要與IPv4節(jié)點(diǎn)通信，但I(xiàn)Pv4節(jié)點(diǎn)沒有雙IP層來支持IPv4與IPv6。這種機(jī)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

24、000; Raicu and Zeadally,2003)第一。平均延遲時(shí)間是指把時(shí)間作為一個(gè)封包通過網(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.延遲時(shí)間分析

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>　　程序運(yùn)行在可靠的ICMP網(wǎng)絡(luò)層上，ping程序的功能是發(fā)送回應(yīng)請求包來控制指定節(jié)點(diǎn)和檢查回應(yīng)訊息，并以此來判定特殊節(jié)點(diǎn)是否存活。</p><p>　　延遲的測量是從客戶端向服務(wù)器發(fā)送64，128，258，512及768字節(jié)的數(shù)據(jù)包，服務(wù)器一旦收到數(shù)據(jù)包即立刻回送給客戶端。整個(gè)過程將重復(fù)進(jìn)行，周期循環(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封裝的所需時(shí)間。</p><p><b>　　6.2 吞吐量</b></p><p>　　吞吐量(Tsuchiya et al.,2000; Raicu and Zeadally,2003)定義是：總的

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

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

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

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

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

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

39、升級為IPv6領(lǐng)域，這時(shí)IPv4地址只需要臨時(shí)IPv4節(jié)點(diǎn)通信。對IPv6節(jié)點(diǎn)一個(gè)機(jī)制必須去探測IPv4地址。此時(shí)這個(gè)機(jī)制將需要探測核心層，追蹤IPv4 API系統(tǒng)呼叫。所以程序需要從服務(wù)器獲得IPv4地址，這個(gè)程序也許利用DHCPv6或者RPCv6，再或者利用特別設(shè)計(jì)的目標(biāo)，同樣地服務(wù)器需要維護(hù)全局的IPv4地址。</p><p><b>　　參考文獻(xiàn)</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<