设计与实现由IPv4过渡到IPv6隧道的配置方案

设计与实现由IPv4过渡到IPv6隧道的配置方案

Tushar M. Raste , D.B. Kulkarni

Department of Computer Science and Engineering, Walchand College of Engineering,Sangli, India

Received 14 January 2005; received in revised form 28 June 2006; accepted 28 June 2006

摘要:

　在现有的IPv4互联网中配置IPv6网络时，IPv4到IPv6的过渡就成为一个必然的过程，在过渡期间两种协议将会在较长的时间内共存。以满足多方面的不同协议的需求，有许多种解决过渡问题的技术，隧道技术就是其中之一。隧道技术提供了一种以现有IPv4路由体系来传递IPv6数据的方法：将IPv6包作为无结构意义的数据，封装在IPv4包中，被IPv4网络传输。在本文里，我们将提出一种将IPv6包封装在IPv4包中的方案。当大部分网络转换成只涉及最小IPv4路由的IPv6网络时，此方案将会很有用处。

此种技术结合上双协议栈，便可实现IPv4与IPv6网络环境的互通以及与其他IPv4应用程序的相互作用，而无需修改和再编译，以及NAT，也不要任何代理与网关设置。

关键字：网络，Ipv4，Ipv6

1. 引言

在纯IPv6网络（Dunn，2002）中，最初的IPv6配置（Davies,2002）需要紧密成对使用IPv4地址来支持IPv4与IPV6之间的网络互连。其节点仍然需要与IPv4节点通信，但IPv4节点没有双IP层来支持IPv4与IPv6。这种机制基于IPv4到IPv6隧道的使用(Wang et al.,2001)，以便在纯IPv6网络中支撑IPv4的通信。由于IPv4全局可用的路由地址空间正成为稀缺资源，人们认为用户应在其一部分网络中配置IPv6协议，以减少对IPv4协议的需求和依赖性。在这种前提下，辅助支持本地IPv4的同时，在很大程度上也增加了IPv6复杂的网络管理（IP地址计划，路由基础设施）。因此在这种情况下建议用户只配置IPv6网络。

当在一个网络中配置隧道技术时，节点同时具有分配的IPv4和IPv6地址。当一个IPv4应用程序需要在一个IPv6节点或另一个纯IPv4节点上与另一个IPv4应用程序建立通信时，隧道技术会被配置。这允许IPv6节点与纯IPv4节点通讯，或者纯IPv4应用程序在IPv6节点上不用修改而运行。这样在一个IPv6域中，IPv4包被隐藏于IPv6包中(Bound et al., 2000)。这样在网络中就只需要管理IPv6路由计划，即简化了网络管理。

2. IPv4栈的配置

只要能在本地的IPv6通讯，就不需要隧道技术机制的支持。主机能通过不同的方法检测到是否需要隧道技术：当在IPv4的目标地址查询到DNS分解器时；当一个应用程序打开一个IPv4套接字时；或者当一个IPv4包被发送到内核并且没有界面准备转发那个包(Bound et al., 2000)时。在需要发送第一个IPv4包时，客户端会获得一个TEP的IPv6地址(Affifi and Tountain,1999)，此信息将用来配置4到6的界面。

隧道设定中重要的一步是为隧道创建一个虚拟的界面以及在IPv4节点的路由选择表中创建一个路由输入。这使得IPv4应用程序能够将IPv4包转入到隧道代码中。网滤器钩可用来探测是否需要在节点上安装这样一个隧道。

3. 网滤器钩

创建虚拟界面的需要可由网滤器钩来探测(Netfilter homopage; Chakeres)。可通过识别许多激发路由活动的事件的操作来使用网滤器。网滤器由在Linux协议栈中的不同点上的许多钩子构成。它允许用户定义的内

图1. 网滤器钩.

核模块将回收函数注册到这些钩子上。一个数据包横越钩子时，数据包会通过内核模块中用户自定义的回收方法。

网滤器结构中定义有五个钩子，见图1。在图的顶端有两个钩子，NF_IP_LOCAL_IN 和 NF_IP_LOCAL_OUT。这些钩子的对象是所有来往于局部过程的数据包。在图的底端有两个钩子，NF_IP_PRE_ROUTING NF_IP_ POST_ROUTING。它们的对象是来往于网络上其他主机的所有数据包。还有一个钩子是用于当前主机转发的数据包，NF_IP_FORWARD。假设一个本地进程为一个远程进程创建一个数据包，作为一个数据包如何横越这些钩子的例子：首先，数据包横越NF_IP_LOCAL_OUT钩子。下一步，执行一个路由选择判断看数据包是否驶往本地主机或网络中的另一个主机。数据包会被发现是为一个远程主机安排的，并通过NF_IP_POST_ROUTING钩子被传递到一个网络界面上。注册的回收函数返回下面五个值中的一个:NF_ACCEPT(接受数据包并继续数据链)，NF_DROP (丢弃数据包), NF_QUEUE(将数据包排队到用户空间中)或者NF_STOLEN (从网络中窃得的数据包)。

4.虚拟界面

从内核角度来说，一个网络界面是一个软件对象，它可以处理外流的数据包，而实际的传输机制隐藏于界面驱动中。即使大多数界面被关联到物理设备（或对于回环界面，关联到纯软件的数据循环），设计出依赖于其他界面来执行实际数据包传输的网络界面驱动是有可能的。

“虚拟”界面的想法有助于对特殊目的的数据包处理，同时避免黑客入侵内核网络子系统。这个想法可用于将数据包配置到另一个协议中。因此，创建一个隧道暗指在内核中创建一个虚拟界面，并将封装信息保留在专用数据结构中。

5. 设计

提出的设计方案是使用NF_IP_LOCAL_OUT钩子来探测是否需要隧道。当一个本地进程生成的IPv4数据包通过这个钩子，针对此钩子定义的回收函数将有以下任务：

1. 决定目的地IPv6地址。

2. 若目的地为IPv6主机，则为远程主机创建一个隧道。

3. 若目的地在纯IPv4网络中则为边界路由器创建一个隧道。边界路由器存在于IPv6和IPv4域的边界处。

4. 创建合适的路由选择表输入。

这样，回收函数有了一个外部分解器的任务(Tsuchiya et al., 2002)，即解析一个IPv4地址，也就是说进入一个IPv6地址的A记录，即AAAA记录。为此，它会生成一个对DNS服务器的DNS查询。再一次，隧道的创建可在内核空间中进行。注册的函数将执行创建虚拟界面的任务并和新创建的设备一起配置隧道数据结构。隧道参数可存储于界面的私有数据结构中。

一旦设备被创建出来，那么一个目的地路由就可与之关联，如此一来，数据包就能被转向这个界面了。传输函数就能利用储存在隧道私有数据结构中的信息，有组织地封装这些数据包（图2）。接下来回收函数就能返回NF_ACCEPT的一个判断以便数据包返回网络栈中。接着由内核作出路由判断。

一个IPv6域中的用户空间守护程序被配置用于传达在IPv4目的地建立隧道的需求，或者是边界路由器的目的地在IPv4域中。

一种新的被称为IPIP（值4）的协议被注册用于接收那些隧道数据包。注册程序涉及到一些用于处理这些隧道数据包及生成错误信息（ICMP信息）的特定函数。接收函数移除IPv6头信息并且模拟另一个接收程序，此时一个IPv4数据包被接收，虚拟界面的一些参数被调整以便IPv4数据包的接收可通过虚拟设备来模拟。

图2. 数据包的接收.

6.性能

6.1延迟时间

在性能评估中，隧道式机制传输平均延迟时间(Tsuchiya et al., 2000; Raicu and Zeadally,2003)第一。平均延迟时间是指把时间作为一个封包通过网路连接从发送者传输到接受者。测试的执行是通过Ping

4

3.5

3

IPv4

Tunneled

Latency

2.5

2

1.5

1

0.5

0

64 128

256

数据包大小

512

768

图3.延迟时间分析.

2500

Throughput

2000

IPv4

Tunneled

1500

1000

500

0

64 128

256

512

768

数据包 (字节)

图4. 吞吐量分析.

程序运行在可靠的ICMP网络层上，ping程序的功能是发送回应请求包来控制指定节点和检查回应讯息，并以此来判定特殊节点是否存活。

延迟的测量是从客户端向服务器发送64，128，258，512及768字节的数据包，服务器一旦收到数据包即立刻回送给客户端。整个过程将重复进行，周期循环1000次。

图3显示：IPv4包与隧道包延迟的比较，数据包的大小由64字节到768字节的不同。随着数据包字节的改变，总值呈现出由7%到30%的变化。总值出现于隧道包封装与DE封装的所需时间。

6.2 吞吐量

吞吐量(Tsuchiya et al.,2000; Raicu and Zeadally,2003)定义是：总的数据包传输到全部路径的单位时间。吞吐量的计算公式为T =P/L,T指吞吐量，P指千字节的数据包大小，L指找到一致的数据包大小的延迟时间。图4是对64字节到768字节的数据包大小的吞吐量的分析。

在IPv6协议栈，数据包大小始终保持在小于1440字节以避免潜在的分裂程序。最大的吞吐量达到最大的数据包大小。吞吐量一般随着数据包大小的增加而增大。总值从7%到30%的变化取决于数据包大小。总值随着数据包大小的增大而减少（图4）。

7.与其他机制的比较

本节，讲述一些关于IETF下一代过渡技术工作组的相关工作(Ngtrans) (Waddington and Chang,2002)。

双协议栈(Bound and Tountain,1999)机制是两种基本传输机制的一种，在主机与路由器中双协议栈可完全支持IPv4和IPv6。但是它不可以减少对全局路由IPv4地址的需求，以及提高IPv4与IPv6混合路由设施的网络复杂性。

应用层网关（ALG）,SOCKS64 (Kitamura et al.,2000)和TCP继电器(Kitamura et al.,2000)是可以提供在IPv4与IPv6之间通信的代理机制。在应用程序或者TCP连接层它们都可分离一个IP连接到两个封闭的连接，其中之一在IPv4网络，另一个在IPv6网络。它们共同的缺点是打破因特网点对点的原则，而此原则对电子商务以及商业通信非常的重要。ALG是一种应用程序-从属机制，它是指对不同的应用程序它应提供不同的应用程序网关组件。SOCKS64可只为包含于SOCKS客户与SOCKS服务器的网站服务。NATPT (Tsirtsis and Srisureshi,2000)来源于传统的NAT (Srisureshi and Hodrege, 1999)机制，再加上IPv4与IPv6协议的协议转换。BIS (Tsuchiya et al.,2000) 由寻址转换器模组到节点系统，与一个地址映射以及延伸到名称分解器，以次来促进转换。SIIT (Nordmark,2000)提供了一个从IPv4到IPv6灵活与无状态的转化，但是它是不完备的，因为它没有指定在IPv6网络里如何从IPv4包到IPv6包转化。这三种机制可以被认为是NAT-型机制，所以它们都含有NAT固有的缺陷。NAT-有害应用程序在不参与应用层网关的情况下不可以通过翻译盒。同时，NAT-型机制也有同样的缺陷作为网关型机制直到点对点通信而言。更进一步，任何基于NAT的解决方案都是无效与不可扩展的。

8. 结论与前景展望

概括起来我们提议的方案有下列优势：在全局网络上纯IPv6主机可以匹配于纯IPv4节点。在一个纯IPv6环境上不孤立于主机与其他的

网络，应用程序还没到达IPv6之前就可以运行在纯IPv6主机与网络上，此时网络可只配置IPv6，这里就不需要配置地址与IPv4路由。任何类型的协议/应用程序可显然地传递，不需要配置翻译器。

标准模型假设IPv6节点含有有效的IPv4与IPv6地址，在将来当节点升级为IPv6领域，这时IPv4地址只需要临时IPv4节点通信。对IPv6节点一个机制必须去探测IPv4地址。此时这个机制将需要探测核心层，追踪IPv4 API系统呼叫。所以程序需要从服务器获得IPv4地址，这个程序也许利用DHCPv6或者RPCv6，再或者利用特别设计的目标，同样地服务器需要维护全局的IPv4地址。

参考文献

Affifi, H., Tountain, L., ENST Bretagne, Methods for IPv4-IPv6 Transition. IEEE 1999.

Bound, J., Tountain, L., Affifi, H., Dupont, F., Durand, A., dual stack transition mechanism (DSTM) Internet draft (draft-ietfngtrans dstm-007.txt) 2002.

Chakeres, I.D., AODV-UCSB Implementation, University of California Santa Barbara. /http://moment.cs.ucs- b.edu/AODV/aodv.htmlS.

Davies, J., Introduction to IP version 6 Microsoft Press, February 2002. Dunn, T., The IPv6 transition. IEEE Internet Comput 2002.

Kitamura, H., Jinzaki, A., Kobayashi, S., A socks based IPv6/IPv4 gateway mechanism Internet Draft ‘‘draft-ietf-

ngtrans-socks-gateway-06.txt’’ 2000.

Netfilter homepage /http://www.netfilter.org/S.

Nordmark, E., Stateless IP/ICMP translator algorithm (SIIT). RFC2765 February 2000. Raicu, I., Zeadally, S., Evalating IPv4 to IPv6 transition mechanisms. IEEE September 2003.

Srisuresh, P., Holdrege, M., IP network 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 2000.

Tsirtsis, G., Srisuresh, P., Network address translation-protocol translation (NAT-PT). RFC2766, February

2000.

Waddington, D., Chang, F., Realizing the transition to IPv6. IEEE Comm Mag 2002.

Wang, K., Yeo, A.K., Ananda, A.L., DTTS: a transparent and scalable solution for IPv4 to IPv6 transition

Proceedings of the tenth international conference on computer communication and networks, IEEE 2001.

Journal of Network and

Computer Applications 31 (2008) 66–72

www.elsevier.com/locate/jnca

Research note

Design and implementation scheme for deploying

IPv4 over IPv6 tunnel

Tushar M. Raste , D.B. Kulkarni

Department of Computer Science and Engineering, Walchand College of Engineering,Sangli, India

Received 14 January 2005; received in revised form 28 June 2006; accepted 28 June 2006

Abstract:

IPv4 to IPv6 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 transition 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 as payload on the network. 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 networks would be converted into IPv6 networks 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 network environments without any modification and recompilation, and without NAT, nor any application proxy or gateway.

r 2007 Published by Elsevier Ltd.

Keywords: Network; Ipv4; Ipv6

1. Introduction

The initial deployment of IPv6 (Davies, 2002) will require a tightly coupled use of IPv4 addresses to support the interoperation 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 based on the use

Corresponding author. Tel.:+ 912332301327; fax: +912332300831.

E-mail addresses: tusharraste@yahoo.co.in (T.M. Raste), d_b_kulkarni@yahoo.com (D.B. Kulkarni).

1084-8045/$ - see front matter r 2007 Published by Elsevier Ltd. doi:10.1016/j.jnca.2006.06.009

of IPv4-over-IPv6 tunnels (Wang et al., 2001) to carry IPv4 traffic within 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 portion 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 is proposed, in this case, to configure the network only for IPv6.

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 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 modification. Thus IPv4 packets are hidden in the IPv6 packets on an IPv6 domain (Bound et al., 2000). This simplifies network management: only the IPv6 routing plan is managed inside the network.

2. Configuration of IPv4 stack

As long as communications can take place in native IPv6, no tunneling mechanism 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 IPv4 packet is sent to the kernel and no interface is ready to forward that packet (Bound et al., 2000). When the first IPv4 packet needs to be sent, the client obtains the IPv6 address of a TEP (Affifi and Tountain, 1999). This information is used to configure the 4over6 interface.

The important step in tunnel configuration 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 divert the IPv4 packets to the tunnel code written in the kernel. Net- filter hooks can be used to detect the need to install such a tunnel on the node.

3. Net-filter hooks

The need for virtual interface creation can be detected by using net-filter (Netfilter homopage; Chakeres) hooks. Net-filter can be used by our implementation to identify many of the events that trigger the routing action. Net-filter consists of a number of hooks at various points inside the Linux protocol stack. It allows user-defined kernel modules to register callback functions to these hooks. When a packet traverses a hook, the packet flows through the user defined callback method inside the kernel module.

There are five hooks defined in the net-filter architecture, as shown in Fig. 1 At the top of the figure there are two hooks, NF_IP_LOCAL_IN and NF_IP_LOCAL_OUT. These hooks are for all packets to and from local processes. At the bottom of the figure there are two hooks, NF_IP_PRE_ROUTING and NF_IP_POST_ROUTING. These are for all packets from and to other hosts on the network. There is also a hook for packets that are forwarded by the current host, NF_IP_FORWARD. As an example of how packets traverse these hooks, suppose a packet is created by a local process for a remote process. It first traverses the NF_IP_LOCAL_OUT hook. Next, a routing decision is performed to see if the packet is bound for the local host or another host on the network. The packet is found to be destined for a remote host, and the packet is passed through the

Fig. 1. Net-filter hooks.

NF_IP_POST_ROUTING hook and then onto a network interface. The call back function registered returns one of the five values NF_ACCEPT (accept the packet and continue the chain), NF_DROP (drop the packet), NF_QUEUE (queue the packet to user space) or NF_STOLEN (packet stolen from network stack).

4. Virtual interface

From the kernel’s point of view, a network interface is a software 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 loopback 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.

The idea of a ‘‘virtual’’ interface 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. Thus creating a tunnel implies creating a virtual interface in the kernel and maintaining the information for encapsulation in its private data structure.

5. Design

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 defined for this hook will have the following tasks:

1. Determine the destination IPv6 address.

2. If the destination is an IPv6 host, create a tunnel for the remote host.

3. If the destination is on IPv4-only network then create a tunnel for the border router. A

border router resides on the boundary between IPv6 domain and IPv4 domain.

4. Create the appropriate IPv4 routing table entry.

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 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 creating a virtual interface and configuring a tunnel data structure with the newly created device. The tunnel parameters can be stored in the private data structure of the interface.

Once the device is created then a route for the destination can 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 private 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 kernel diverting the packets to the previously created route.

A user space daemon in the IPv6 domain is deployed to communicate the need of establishing

a tunnel at the IPv4 destination, or the border router if the destination is in IPv4 domain. For reception of such tunneled packets a new protocol called IPIP protocol (value 4) is

registered with the kernel. This registration process involves specifying functions for processing 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 and the parameters for virtual interface are adjusted so that the reception of IPv4 packets is simulated through the virtual device.

6. Performance

6.1. Latency

In evaluating the performance of the tunneling-based mechanism the average transmission latency (Tsuchiya et al., 2000; Raicu and Zeadally, 2003) was measured first. The 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

Fig. 2. Packet Reception.

program run on a reliable ICMP Internet layer. The ping utility sends ICMP echo request packets to the command argument specified node and checks for a replayed message, to determine whether a particular node is alive.

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 the client. The whole process is repeated; the cycle is iterated 1000 times.

Fig. 3 shows the comparative latency for IPv4 packets and tunneled packets as the packet size is varied from 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.

6.2. Throughput

Throughput (Tsuchiya et al., 2000; Raicu and Zeadally, 2003) is defined as the amount of packet data that is transmitted over the entire path per unit time. The throughput is 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 figure plots the throughput for packet size ranging from 64 to 768 bytes.

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 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 (Fig. 4).

本文来源：https://www.2haoxitong.net/k/doc/c8d714e459eef8c75ebfb3a9.html