专利名称：在IPv6中用主机间隧道支持IPv4应用程序的方法
技术领域：
使用主机间隧道在纯IPv6环境中支持IPv4应用程序的方法属于互联网技术领域，尤其涉及网络过渡策略方面的技术。
背景技术：
为了解决网络规模不断扩大带来的IPv4地址空间不足问题，IETF提出了下一代互联网协议——IPv6。随着协议的不断发展和成熟，包括中国、美国、日本和欧洲在内的许多国家和地区正在积极的筹划基于IPv6的新一代网络。建立起了CNGI、6Bone等IPv6示范网络。在IPv6过渡过程中，一方面，网络基础设备需要被升级为支持IPv6；另一方面，用户主机上的应用程序也需要进行过渡。现有的大部分涉及网络的应用程序都是基于IPv4协议的，在纯IPv6环境中会因为处理IP地址时遇到的位数、格式等问题而无法正常运行。虽然随着过渡的进行，多数应用程序会逐渐升级为支持IPv6；但程序的重新开发需要一个漫长的过程，同时由于缺乏源代码、升级成本等问题，会有部分应用程序无法或不愿升级为支持IPv6。因此，在过渡的中后期，纯IPv6网络开始出现和发展的条件下，如何为已有的IPv4应用程序提供支持，是实现IPv6顺利过渡的一个重要问题。
为了解决IPv6过渡问题，保证现有的IPv4网络和应用程序实现平滑过渡，目前提出了许多方案，归纳如下●采用双栈网络技术。这是指采用可以同时支持IPv4和IPv6的设备来搭建网络的方法。由于设备可以同时支持IPv4和IPv6，可以保证IPv4程序的运行。
●采用协议翻译技术。这是在IPv4协议和IPv6协议之间进行协议翻译的方法，将IPv4的报头翻译成IPv6报头的格式。这一翻译过程可以在主机的协议栈中进行，也可以在专门的网关处进行。代表方案有NAT-PT、BIA、BIS等。
●采用特殊网关+主机与网关间隧道传输技术。这是一种在网络中设立特殊的地址服务器和边界网关的方法。当主机需要进行IPv4通信时，从地址服务器申请一个IPv4地址，并与边界网关建立起IPv4-in-IPv6的隧道。数据包通过隧道被传输给边界网关，通过网关送入IPv4网络。代表方案有DSTM等。
然而，目前这些方案都存在着不足之处●双栈网络技术的方法缺陷在于网络设备需要同时支持IPv4和IPv6，在设备开销方面较大；网络中同时使用IPv4和IPv6，对网络的管理造成了很多不便。另外，该方法的部署颗粒度很大，必须以子网级别进行部署。不适于增量部署。
●采用协议翻译技术的方法缺陷在于IPv6协议在报头格式方面与IPv4有比较大的区别，在协议翻译的过程中，可能会造成某些信息的丢失。此外，部分在主机协议栈中进行翻译的方法(包括BIA、BIS)将所有的IPv6数据包全部翻译成IPv4数据包，会影响上层IPv6应用程序的正常工作。
●采用特殊网关+主机与网关间隧道传输技术的方法的缺陷在于首先，方法中的地址服务器和网关作为整个系统的关键点，很容易受到针对性的攻击，并可能成为性能方面的瓶颈。其次，该方法需要参与通信的对方在DNS系统中具有IPv4地址的条目，当过渡进行到中后期时，纯IPv6网络环境中的用户将不具有这一条件，会导致方法的失效。
对于IPv4应用程序来说，与IPv6应用程序的主要区别就在于使用的IP地址格式不同。针对这一特点，为了让IPv4应用程序在IPv6环境中正常工作，需要为其提供格式正确的地址。本发明从这一角度出发，提出了一个通过地址协商和主机间隧道来支持纯IPv6环境中IPv4应用的方案。本方案采用虚拟地址协商和主机间隧道的思路，在双方开始通信之前，首先为彼此协商出一个临时使用的虚拟IPv4地址，提供给上层的IPv4程序。在地址协商的同时，两台主机间的IPv4-in-IPv6隧道也自动被建立起来，通信过程中的数据通过这一隧道进行传输，而不需要借助特殊的服务器和网关。通过这种方式，可以在纯IPv6网络环境中支持IPv4应用。
发明内容
本发明的目的在于提供一种基于地址协商和主机间隧道的方法，使得纯IPv6网络中的IPv4程序可以在不进行修改的情况下进行互相通信。
本发明所提供的方法思路在于在上层的IPv4应用程序进行DNS地址解析时，主机的协议栈拦截这一请求，并从DNS中解析到对方的IPv6地址。然后，使用这一地址与对方进行IPv4虚拟地址的协商，为彼此确定在这次会话中使用的IPv4地址，同时，在这一过程中，两台主机间的隧道也自动被建立起来。当地址协商完成后，IPv4虚拟地址被返回给上层应用程序，此后的数据都通过主机之间的IPv4-in-IPv6隧道进行传输。
同时，本方法还设计了独特的协议来进行地址协商。为了使地址协商可以高效的进行，需要设计合适的协议使得双方交互次数达到最低。本方法设计的协商协议中包括候选地址的生成、地址可用性判定和最终地址决定三部分。候选地址生成的功能在连接的发起端和接收端都需要进行，每次生成两个供选择的IPv4地址。地址可用性判定的功能同样需要在两端进行，用于检查对方目前的地址以及生成的候选地址是否与映射表中的表项发生冲突。最终地址决定的工作交给连接发起端进行，根据双方地址可用性判定的结果决定彼此最终使用的IPv4地址。通过这种协议，可以在通信双方之间进行高效的地址协商。
本发明的特征在于该方法使用IP地址协商的方式，在纯IPv6网络中的两台机器之间为彼此生成一个临时的虚拟IPv4地址，使上层的基于IPv4的应用程序可以在不经过任何改动的情况下保持正常工作。该过程既包括通信双方直接进行的虚拟地址协商，还包括使用两台主机之间直接建立的IPv4-in-IPv6隧道来进行数据包的传输。该方法使用了IPv4-in-IPv6隧道技术，不对上层的IPv6应用程序产生影响，不需要对网络中的其他设备进行任何改动，对DNS系统中的记录条目也没有特殊的要求。
本方法依次含有以下步骤步骤(1)，当纯IPv6网络中的一台主机A上的IPv4应用程序需要与另一台主机B上的IPv4应用程序通信时，按照一般的通信流程，调用DNS函数对B的IPv4地址进行解析；步骤(2)，该主机的协议栈经过改造部署了本方案之后，DNS请求被改变为同时对B的IPv4和IPv6地址进行解析；步骤(3)，由于B也在纯IPv6网络中，所以地址解析得到的结果是B的IPv6地址；步骤(4)，主机A开始与B进行协商，为双方生成一个临时的IPv4地址。该地址使用特殊的地址段，并被保存在一个IPv4-IPv6地址的映射表中。当地址协商结束之后，AB之间便自动建立起了一个隧道；步骤(5)，主机A的协议栈将协商得到的地址返回给上层的应用程序，应用程序使用这个地址进行通信；步骤(6)，上层应用程序发出的IPv4数据包在A的协议栈中被检查，具有上述特殊地址段内的IP地址的数据包被挑选出来，根据IP报头中的IPv4地址查找对应的IPv6地址。之后整个IPv4数据包被封装在IPv6的报头内，通过IPv4-in-IPv6隧道被发给B；步骤(7)，主机B在收到数据包后，解封装并检查IPv4-IPv6的映射关系是否正确，检查完毕之后交给上层的IPv4应用程序。
本发明所提出的在纯IPv6网络中支持IPv4应用的方案，可以广泛部署到IPv6网络中以促进网络过渡的发展。由于本方法中地址协商只需要在连接建立时进行一次，而且设计协商协议时充分考虑到了减少交互次数的因素，使得方案的执行效率很高。实验表明，即使在网络规模很大的情况，例如主机数∶可用IP地址数＝20∶1的情况下，整个地址协商过程大约在4次交互之内就可以完成。与一次TCP建连所需要的时间(3次交互)相差不大。所以本方法是完全可行的。
本发明的另一个优势是适合增量部署，即插即用。只要两台主机部署了本机制，就可以互相进行通信。可以通过在单台主机上部署方案来进行推广。同时与其他过渡策略结合起来，可以覆盖过渡期间的各种应用场景。本发明正计划在CERNET2和中国下一代网络CNGI中推广。
图1.方案整体框架说明；图2.地址协商协议具体流程；图3.系统工作流程；图4.具体实施方式
实例。
具体实施例方式
在数据传输方面，主机之间的隧道建立起来以后，按照普通的IPv4-in-IPv6标准进行封装和传输就可以了。下面我们主要介绍本发明的核心机制主机间协商IPv4地址及自动建立隧道的协议流程。如图2。图2中的协商过程如下1.主机A作为连接的发起方，生成两个与自己映射表中已有条目不冲突的IPv4地址，作为候选地址，将他们和自己目前已有的IPv4地址(如果有的话)一起发送给B。
2.主机B作为连接的接收方，收到A发来的数据后，检查A的已有地址和A生成的两个候选地址是否与B目前映射表中的条目发生冲突，记录下检查的结果。
3.主机B同样生成两个候选地址，将他们和自己目前已有的IPv4地址(如果有的话)，以及刚才的检查结果一起发送给A。
4.A收到B发来的数据后，检查B的已有地址和B生成的两个候选地址是否与A目前映射表中的条目发生冲突，记录下检查的结果。
5.A根据检查得到的结果和B检查的结果，做出最终使用的IP地址的决定。如果双方已有的地址不发生冲突，那么优先考虑使用已有的地址。如果发生冲突，那么就需要从可用的候选地址中挑出一个作为这次通信使用的新的地址。如果候选地址的个数不够，那么回到协议的开头，重新生成候选地址，进行检查和供挑选。
在本协议中，连接的发起方和接收方同时进行候选地址的生成，这样可以充分考虑到双方已有映射表中的条目，从而减小发生冲突的可能性。而地址的判定工作放在发起方进行，主要是考虑到接收方在多数情况下可能需要接收多个连接，符合负载平衡的原则。每次生成2个候选地址，也有利于协商过程更快的完成。
在图3中，我们给出了整个系统的工作流程，如下1.IPv4应用程序发出解析请求，尝试解析主机B的IPv4地址；2.主机的协议栈经过改造部署了本方案之后，DNS请求被改变为同时对B的IPv4和IPv6地址进行解析；3.由于B在纯IPv6网络中，返回的解析结果只有IPv6地址；4、5、6.地址协商机制被启动，双方协商彼此的虚拟IPv4地址；
7.协商完成之后，IPv4地址——IPv6地址的映射被保存到映射表中，主机之间的隧道自动建立起来；8、9.虚拟的IPv4地址被返回给上层应用程序；10、11、12.应用程序发出的数据包被截获，根据IPv4地址查找到对应的IPv6地址，以IPv4-in-IPv6隧道的方式被封装传输；13、14.从B返回的数据包被解封装后，传递给上层的应用程序。
在图4中，我们给出了一个具体的实例来说明本发明的
具体实施例方式如图所示，在纯IPv6网络中的两台主机分别具有IPv6地址2001::1和2002::1，上面运行的程序是IPv4应用程序。当左边的主机需要进行通信时，首先从DNS服务器处获得右边主机的IPv6地址，然后使用这个地址与对方进行IPv4地址的协商。协商的结果是左边主机虚拟地址为169.254.0.1，右侧主机为169.254.0.2。此时，双方主机的映射表中都增加了对应的两个IPv4地址到IPv6地址的映射表项，主机之间的IPv4-in-IPv6隧道也随之自动建立起来。当应用程序发出数据包时，协议栈中的模块发现数据包具有169.254.0.2的IPv4目的地址，从映射表中查得对应的IPv6地址为2002::1，于是使用这个IPv6地址进行封装和数据包传输。当数据包到达另一端时，将用于封装的IPv6报头去掉，就得到了IPv4格式的数据包，可以直接交给上层程序。这样，位于纯IPv6网络中的两个IPv4应用程序获得了相互通信的途径。因此，本发明的方法是有效的。
权利要求
1.在IPv6中用主机间隧道支持IPv4应用程序的方法，其特征在于，依次含有以下步骤步骤(1)，在IPv6的主机A和主机B的协议栈之间建立主机间协商IPv4地址及隧道的协议，该协议的执行步骤如下步骤(1.1)，以主机A作连接的发起方时，主机A要生成两个与自己映射表中已有条目不冲突的IPv4地址，作为候选地址，把候选地址和目前存在的IPv4地址发送给主机B；步骤(1.2)，以主机B作为连接的接收方，在收到主机A发来的数据后，检查这些地址是否与主机B目前映射表中的条目发生冲突，记录检查结果；步骤(1.3)，主机B同样生成两个候选地址，把所生成的地址和目前存在的IPv4地址，以及步骤(1.2)中检查的结果一起发送给A；步骤(1.4)，主机A收到主机B发来的数据后，检查B的已有地址和生成的两个候选地址是否和主机A目前映射表中的条目发生冲突，记录下检查结果；步骤(1.5)，主机A根据自己的以及主机B的两方面的检查结果，选定最终使用的不会与主机A和/或主机B检查的结果发生冲突的IPv4地址，经设定地址以后，把这个临时的IPv4地址通知主机B；步骤(1.6)，根据步骤(1.5)的结果，主机A和主机B中各自形成了一个IPv4-IPv6地址的映射表，在主机A和主机B之间便自动建立起了一个隧道；步骤(2)，使用步骤(1.6)得到的主机间隧道在IPv6中执行支持IPv4应用程序步骤(2.1)，IPv6中的主机A上的IPv4应用程序发出域名请求DNS以便与IPv6中另一个主机B上的IPv4应用程序通信；步骤(2.2)，主机A把步骤(2.1)中的域名请求DNS变更为对主机B的IPv4和IPv6地址的解析，得到主机B的IPv6的地址；步骤(2.3)，主机A和主机B进行协商，为双方生成一个临时的IPv4地址，该地址使用设定的地址段，并保存在一个IPv4-IPv6地址的映射表中，在主机A和主机B之间自动建立起一条隧道；步骤(2.4)，主机A的协议栈把步骤(2.3)经过协商得到的地址返回给上层的应用程序，以便应用程序使用这个地址进行通信；步骤(2.5)，上层应用程序发出的IPv4数据包在主机A的协议栈中被检查，挑选出具有步骤(1.5)中所述设定地址段的数据包，根据其中IP报头中的IPv4地址查找对应的IPv6地址，再把整个IPv4数据包封装在IPv6的报头内，通过步骤(2.3)中所建的隧道发送给主机B；步骤(2.6)，主机B在收到步骤(2.5)中发送来的数据之后，解封装并检查IPv4-IPv6的映射关系是否正确，检查结果是正确以后，再交给主机B上层的IPv4应用程序。
全文摘要
在IPv6中用主机间隧道支持IPv4应用程序的方法属于网络体系结构领域。本发明特征在于该方法使用IP地址协商的方式，在纯IPv6网络中的两台机器之间为彼此生成一个临时的虚拟IPv4地址，使上层的基于IPv4的应用程序可以在不经过任何改动的情况下保持正常工作。该过程既包括通信双方直接进行的虚拟地址协商，还包括使用两台主机之间直接建立的IPv4－in－IPv6隧道来进行数据包的传输。该方法能够有效支持纯IPv6网络内IPv4应用程序间的通信，性能也足以满足现有网络的要求，同时配置简单，适合增量部署，可以通过在单台主机的协议栈中部署来进行推广。
文档编号H04L29/06GK101068189SQ20071009936
公开日2007年11月7日 申请日期2007年5月18日 优先权日2007年5月18日
发明者毕军, 李星, 吴建平, 程祥斌 申请人:清华大学