【正文】 吞吐量 (Tsuchiya et al.,2020。 Raicu and Zeadally,2020)定義是：總的數(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ù)包大小的吞吐量的分析。 在 IPv6 協(xié)議棧，數(shù)據(jù)包大小始終保持在小于 1440 字節(jié)以避免潛在的分裂程序。最大的吞吐量達(dá)到最大的數(shù)據(jù)包 大小。吞吐量一般隨著數(shù)據(jù)包大小的增加而增大?？傊祻?7%到 30%的變化取決于數(shù)據(jù)包大小?？傊惦S著數(shù)據(jù)包大小的增大而減少（圖 4）。 7 本節(jié)，講述一些關(guān)于 IETF 下一代過渡技術(shù)工作組的相關(guān)工作(Ngtrans) (Waddington and Chang,2020)。 雙協(xié)議棧 (Bound and Tountain,1999)機(jī)制是兩種基本傳輸機(jī)制的一種，在主機(jī)與路由器中 雙協(xié)議?？赏耆С?IPv4 和 IPv6。但是它不可以減少對全局路由 IPv4 地址的需求，以及提高 IPv4 與 IPv6 混合路由設(shè)施的網(wǎng)絡(luò)復(fù)雜性。 應(yīng)用層網(wǎng)關(guān)（ ALG） ,SOCKS64 (Kitamura et al.,2020)和 TCP繼電器 (Kitamura et al.,2020)是可以提供在 IPv4與 IPv6之間通信的代理機(jī)制。在應(yīng)用程序或者 TCP連接層它們都可分離一個(gè) IP連接到兩個(gè)封閉的連接，其中之一在 IPv4網(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,2020)來源于傳統(tǒng)的 NAT (Srisureshi and Hodrege, 1999)機(jī)制，再加上 IPv4與 IPv6協(xié)議的協(xié)議轉(zhuǎn)換。 BIS (Tsuchiya et al.,2020) 由尋址轉(zhuǎn)換器 模組到節(jié)點(diǎn)系統(tǒng)，與一個(gè)地址映射以及延伸到名稱分解器，以次來促進(jìn)轉(zhuǎn)換。 SIIT (Nordmark,2020)提供了一個(gè)從 IPv4到 IPv6靈活與無狀態(tài)的轉(zhuǎn)化，但是它是不完 備的，因?yàn)樗鼪]有指定在 IPv6網(wǎng)絡(luò)里如何從 IPv4包到 IPv6包轉(zhuǎn)化。這三種機(jī)制可以被認(rèn)為是 NAT型機(jī)制，所以它們都含有 NAT固有的缺陷。 NAT有害應(yīng)用程序在不參與應(yīng)用層網(wǎng)關(guān)的情況下不可以通過翻譯盒。同時(shí)， NAT型機(jī)制也有同樣的缺陷作為網(wǎng)關(guān)型機(jī)制直到點(diǎn)對點(diǎn)通信而言。更進(jìn)一步，任何基于 NAT的解決方案都是無效與不可擴(kuò)展的。 8. 結(jié)論與前景展望 概括起來我們提議的方案有下列優(yōu)勢：在全局網(wǎng)絡(luò)上純 IPv6 主機(jī)可以匹配于純 IPv4 節(jié)點(diǎn)。在一個(gè)純 IPv6 環(huán)境上不孤立于主機(jī)與其他的 網(wǎng)絡(luò)，應(yīng)用程序還沒 到達(dá) IPv6 之前就可以運(yùn)行在純 IPv6 主機(jī)與網(wǎng)絡(luò)上，此時(shí)網(wǎng)絡(luò)可只配置 IPv6，這里就不需要配置地址與 IPv4 路由。任何類型的協(xié)議 /應(yīng)用程序可顯然地傳遞，不需要配置翻譯器。 標(biāo)準(zhǔn)模型假設(shè) IPv6節(jié)點(diǎn)含有有效的 IPv4與 IPv6地址，在將來當(dāng)節(jié)點(diǎn)升級(jí)為 IPv6領(lǐng)域，這時(shí) IPv4地址只需要臨時(shí) IPv4節(jié)點(diǎn)通信。對 IPv6節(jié)點(diǎn)一個(gè)機(jī)制必須去探測 IPv4地址。此時(shí)這個(gè)機(jī)制將需要探測核心 8 層，追蹤 IPv4 API系統(tǒng)呼叫。所以程序需要從服務(wù)器獲得 IPv4地址，這個(gè)程序也許利用 DHCPv6或者 RPCv6，再或者利用 特別設(shè)計(jì)的目標(biāo)，同樣地服務(wù)器需要維護(hù)全局的 IPv4地址。 參考文獻(xiàn) Af??, H., Tountain, L., ENST Bretagne, Methods for IPv4IPv6 Transition. IEEE 1999. Bound, J., Tountain, L., Af??, H., Dupont, F., Durand, A., dual stack transition mechanism (DSTM) Inter draft (draftietfngtrans ) 2020. Chakeres, ., AODVUCSB Implementation, University of California Santa Barbara. / Davies, J., Introduction to IP version 6 Microsoft Press, February 2020. Dunn, T., The IPv6 transition. IEEE Inter Comput 2020. Kitamura, H., Jinzaki, A., Kobayashi, S., A socks based IPv6/IPv4 gateway mechanism Inter Draft ‘‘draftietf ’’ 2020. Net?lter homepage / Nordmark, E., Stateless IP/ICMP translator algorithm (SIIT). RFC2765 February 2020. Raicu, I., Zeadally, S., Evalating IPv4 to IPv6 transition mechanisms. IEEE September 2020. Srisuresh, P., Holdrege, M., IP work address translator (NAT) terminology and considerations. RFC2663 August 1999. Tsuchiya, K, Higuchi H., Atarashi, Y., Dual stack hosts using the bump in the stack technique, RFC2767 February 2020. Tsirtsis, G., Srisuresh, P., Network address translationprotocol translation (NATPT). RFC2766, February 2020. Waddington, D., Chang, F., Realizing the transition to IPv6. IEEE Comm Mag 2020. Wang, K., Yeo, ., Ananda, ., DTTS: a transparent and scalable solution for IPv4 to IPv6 transition Proceedings of the tenth international conference on puter munication and works, IEEE 2020. 1 Journal of Network and Computer Applications 31 (200 8) 66–72 .else Research note Design and implementation scheme for deploying IPv4 over IPv6 tunnel Tushar M. Raste , . Kulkarni Department of Computer Science and Engineering, Walchand College of Engineering,Sangli, India Received 14 January 2020。 received in revised form 28 June 2020。 accepted 28 June 2020 Abstract: IPv4 to IPv6 transition is an inevitable process when deploying IPv6 works within the present IPv4 Inter. The two protocols are expected to coexist for a number of years during the transition period. A number of transition techniques exist to address the various needs of different works. One of them is tunneling mechanism. Tunneling means encapsulation of one protocol into another one so that the encapsulated protocol is send as payload on the work. In this paper, a scheme is presented for tunneling of IPv4 packets in IPv6 packets. This scheme will be useful in the future when most of the works would be converted into IPv6 works involving minimum IPv4 routing. This technique, coupled with the dual stack approach, enables IPv4 applications to run and interact with other IPv4 applications in both IPv4 and IPv6 work environments without any modi?cation and repilation, and without NAT, nor any application proxy or gateway. r 2020 Published by Elsevier Ltd. Keywords: Network。 Ipv4。 Ipv6 1. Introduction The initial deployment of IPv6 (Davies, 2020) will require a tightly coupled use of IPv4 addresses to support the interoperation of IPv6 and IPv4 within an IPv6only Network (Dunn, 2020). Nodes will still need to municate with IPv4 nodes that do not have a dual IP layer supporting both IPv4 and IPv6. The mechanism proposed is based on t