摘要：随着IPv4地址即将耗尽，IPv4向IPv6过渡已成为必经之路，IPv4与IPv6将在很长时间内处于共存期。如何实现IPv4与IPv6共存期的应用互访和平滑演进是实现IPv4向IPv6成功过渡的基础。本文重点介绍了IPv4向IPv6过渡共存期可能存在的应用场景，并着重介绍了协议翻译技术、隧道类技术以及地址复用技术，并分析了不同技术的优缺点和适用情况。,1 引言,目前，IPv4地址已经呈现越来越紧缺的态势，据分配机构（IANA）根据最近3年的地址使用数据，预测全球IPv4地址资源将于2011年底前后耗尽。而在我国，IPv4地址短缺问题尤为严重。在此情况下，IPv6作为下一代互联网是惟一能够替代IPv4的核心协议并得到业界的广泛认同。IPv6地址逐渐替代即将枯竭的IPv4地址已成为互联网发展的必然趋势，也是目前互联网向下一代互联网过渡的重要历史时期。,虽然IPv6提供了巨大的地址空间，与IPv4相比，IPv6在其它方面也有很多改进。但是，IPv6协议与IPv4协议并不兼容，IPv6的报头结构、报头长度等都与IPv4有着很大的不同，IPv4和IPv6将会长期共存。针对共存期中如何顺利开展IPv4和IPv6的各项业务，推进IPv4向IPv6的演进过程，已经引起业界的广泛重视。除了目前研究相对成熟的双栈技术外，在国际标准化组织IETF中的Behave和Softwire等工作组也积极开展了其他相关过渡技术的讨论、制定和标准化过程。,鉴于目前相关过渡技术纷繁复杂、种类多样，本文将针对不同的应用场景，总结归纳目前的相关标准，并分析其优缺点及适用场景。,2 IPv4向IPv6过渡场景分析,在今后一段时间内，IPv4和IPv6将长期共存，这种共存的趋势将会随着IPv4地址的进一步消耗逐渐过渡为以IPv6为主导的情形。目前，随着IPv4地址紧缺所导致的IPv4和IPv6的过渡共存场景主要包括以下几个方面：,（1）IPv4 NAT（Network Address Translator）及NAT444,IPv4的NAT解决方案是暂时缓解IPv4地址消耗的有效途径，已被广泛使用。NAT可以使用端口复用，这样一个用户（或一个单位、部门）获得的惟一一个公网IP地址可以由多个用户使用。,在IPv4 NAT的基础上，随着IPv4地址的进一步紧缺，用户的公网地址也无法得到的情况下，运营商网络也开始使用私用地址，这样NAT的位置就由用户终端设备（Customer Premises Equipment，CPE）侧移到了接入汇聚处，因此就出现了双层NAT（见图1）。在该方案增加了系统的复杂性，限制了较多应用的部署与开展，具有可扩展性、安全性、端对端可靠性的问题。,图1 双NAT过渡场景,（2）纯IPv6接入初期,随着IPv4地址消耗殆尽，此时用户已无法得到IPv4地址，这时便出现了纯IPv6接入的应用场景，即用户接入的网络是纯IPv6，而不支持IPv4。由于在此阶段仍然存在着大量的IPv4应用与服务，因此IPv4与IPv6的共存阶段具有以下两个长尾特征：,●操作系统的长尾特征。虽然目前的主流操作系统（Windows XP，Vista，Linux等）都已经能够支持IPv6，但对纯IPv6的支持还不够。例如，XP尚不能在纯IPv6环境中处理DNS请求。此外，一些IPv4的应用无法很快升级到IPv6，一些电子设备目前也只能支持IPv4。因此，这就要求在纯IPv6的接入环境中仍然能够使用IPv4的应用以及IPv4的操作系统。,●服务与内容的长尾特征。目前IPv6的服务还比较少，这就要求在纯IPv6的介入环境中仍然能够保持IPv4服务的连通性。,在本阶段，IPv4与IPv6的共存机制包括已广泛使用的IPv4 NAT（CGN，双层NAT），IPv4应用与服务以及IPv6应用与服务（见图2）。IPv6过渡初期的一个重要目标就是保持IPv4的后项兼容性，使用户仍然能够将IPv4的应用接入纯IPv6网络中，这样才能够实现IPv6的顺利过渡。,图2 纯IPv6接入过渡初期场景,（3）纯IPv6接入中期,在纯IPv6的接入中期，随着IPv6的进一步发展，操作系统以及应用程序对IPv6的支持都有了较好的提升，因此用户开始较多地转向使用纯IPv6的应用，用户端出现了较多的纯IPv6的主机，而非双栈或纯IPv4的主机（见图3）。在该阶段，IPv6的服务还较为有限，大量IPv4的服务依然存在，因此用户需要通过IPv6的应用来访问IPv4的服务。,图3 纯IPv6接入过渡中期景,（4）IPv6普及发展阶段,在IPv6已较为普及，用户及网络侧都已经基本升级到纯IPv6的环境时，此时还存在少量位于NAT后的IPv4服务。这个阶段需要解决的问题是，在纯IPv6的环境中访问少量位于NAT后的IPv4服务（见图4）。,图4 IPv6普及发展阶段,综上所述，纯IPv6接入场景是向IPv6过渡非常重要的应用场景。尤其在IPv6的过渡初期，需要解决的主要问题在于保持IPv4的后向兼容性，使用户能够在IPv6的接入环境中无缝使用IPv4的应用与服务。,3 已有过渡技术,迄今为止，已有的IPv4/v6过渡技术可以分为协议翻译类和隧道类。其中，IETF的Behave工作组主要研究协议翻译类的技术，而Softwire工作组则主要研究隧道类的技术。,3.1 协议翻译类,（1）技术原理,IPv6过渡中的协议翻译类技术是由IPv4的NAT技术发展而来的。在IPv4的NAT技术中，为了减少IPv4公网地址的消耗，NAT协议翻译网关为私网IPv4地址和公网IPv4地址建立起映射关系，通过端口的复用技术，从而达到一个公网地址可以由多个私网地址共享的效果。,与此相对应，IPv6过渡中的协议翻译类技术就是将IPv6数据包中的每个字段与IPv4数据包中的每个字段建立起一一映射的关系，从而在两个网络的边缘实现数据报文的转换。其应用场景参见图5。,图5 协议翻译机制的应用场景,在这里，通信双方的主机需要明确本机在另一个网络中的对应地址。在上例中需明确以下两组地址：,●PCA：主机IPv6地址与转换的IPv4地址。,●PCB：主机IPv4地址与映射的IPv6地址。,由于IPv4地址空间远远小于IPv6的地址空间，因此位于IPv4网络中的主机可以通过加上IPv6前缀即可实现IPv4地址与IPv6地址的一一映射，但为了确定IPv6网络中主机的IPv4地址则较为困难。由于IPv6的地址空间远大于IPv4的地址空间，因此只能通过缩小IPv6地址空间的方法与IPv4地址建立映射关系，或者通过建立映射表的方法与IPv4地址建立映射关系。,（2）技术分类,根据IPv6地址空间与IPv4地址空间映射的不同方法，可以将协议翻译类技术分为有状态协议翻译和无状态协议翻译。其中，有状态协议翻译是通过建立映射表的方案，将任意IPv6地址与任意IPv4地址之间建立映射关系，而无状态协议翻译则是通过将IPv4地址内嵌到IPv6地址中，实现无状态地址翻译。因此，无状态协议翻译仅能访问具有特定格式IPv6地址的主机，而有状态协议翻译则能够访问任意地址格式的IPv6主机。,现有协议翻译技术已有很多不同的种类。其中，根据IPv6地址空间与IPv4地址空间映射的不同方法，可分为有状态协议翻译和无状态协议翻译。其中，有状态协议翻译（如NAT64，PNAT等）是通过建立映射表的方案，将任意IPv6地址与任意IPv4地址之间建立映射关系，而无状态协议翻译则是通过将IPv4地址内嵌到IPv6地址中，实现无状态地址翻译。因此，无状态协议翻译（如IVI，DIVI等）仅能访问具有特定格式IPv6地址的主机，而有状态协议翻译则能够访问任意地址格式的IPv6主机。,此外，根据协议翻译的位置，可以分为主机侧协议翻译、网络侧协议翻译以及主机侧和网络侧的协议翻译。主机侧协议翻译（如BIS，BIA等）在主机中完成翻译即可，完成端系统中应用程序协议类型与网络传输协议类型的不匹配，其应用场景为4-6-6或6-4-4；网络侧协议翻译（如NAT64，IVI，Socks64等）仅在网络中部署协议翻译网关即可，完成网络两侧协议类型的不匹配，其应用场景为6-6-4或4-4-6；而主机侧和网络中的两次协议翻译（如PNAT）可应用于4-6-4和6-4-6的应用场景。,最后，根据协议翻译技术的协议层次，可以包括网络层协议翻译（如NAT64，PNAT，IVI，BIS）、传输层协议翻译（如TRT）以及应用层协议翻译（如BIA，Socks64等）。,（3）典型的协议翻译技术,●NAT64,NAT64是有状态的协议翻译技术，在网关中记录了“IPv4地址＋端口”与IPv6地址的映射表会话状态，是网络层的协议翻译技术，其应用场景为6-6-4。NAT64的提出实际是用于替代NAT-PT的，NAT64仅允许IPv6主动发起的连接，并通过将DNS-ALG的功能与NAT64网关的功能相分离，从而可以避免NAT-PT中一些与DNS-ALG相关的缺陷。,NAT64能够支持纯IPv6主机与纯IPv4主机的直接通信，接入网络可以为纯IPv6网络，无需更改主机侧设备，并且其IPv6地址格式不受限。由于NAT64是一个有状态的协议翻译机制，因此具有一定的可扩展性问题和状态同步问题，且需要处理ALG的相关问题。,●IVI,IVI是无状态协议翻译技术。其中，1:1的IVI方式仅将IPv4地址内嵌到IPv6地址中，因此会消耗过多的IPv4公网地址，此时协议翻译网关仅需在网络侧部署即可；而1:N的IVI则通过将IPv4的地址和端口范围同时内嵌到IPv6地址中，从而实现1:N的地址复用，此时的协议翻译网络需要在用户侧和网络侧同时部署，用户侧仅实现端口的有状态映射，而网络侧则可以实现无状态地址映射。,IVI能够实现网络核心无状态处理，报文转发高效，实现简单。由于IVI中需要将IPv4地址内嵌到IPv6中，因此IPv6地址格式比较受限，在1:1的IVI中会消耗过多的IPv4地址，而在1:N的IVI中则又需要在用户侧有一定的更改，并且也需要处理ALG的相关问题。,3.2 隧道类,（1）技术原理,隧道类技术是指将另外一个协议数据包的报头直接封装在原数据包报头前，从而可以实现在不同协议的网络上直接进行传输。其应用场景参见图6。,图6 隧道转换实现原理,在隧道类技术中，通过不同协议类型数据包的封装和解封装可以方便的实现数据包在不同协议类型网络中的传输穿越。因此，隧道方式能够较为方便地实现原有流量的承载。,（2）技术分类,●在隧道类技术中，根据其穿越的不同网络类型，又可以分为IPv6 over IPv4类隧道（图6左侧）和IPv4 over IPv6类隧道（图6右侧）。其中，支持IPv6 over IPv4的隧道类型较多，包括已经成为标准的6 to 4，6 over 4，ISATAP，TSP，Teredo，6PE等，而支持IPv4 over IPv6的隧道类型目前基本还都处于草案阶段，如DS-Lite，A+P，TSP等。,●根据隧道封装的协议层次，又可以分为应用层隧道、传输层隧道（TSP）以及网络层隧道（DS-Lite，A+P等）。其中，应用层隧道的隧道报头通常包括以太头，IP头，TCP/UDP头和应用层的标识头；传输层隧道的隧道报头通常包括以太头，IP头，TCP/UDP头；而网络层隧道的隧道报头则通常包括以太头和IP头。,●针对隧道方式所应用的不同网络结构，又可以将隧道分为星型隧道和网状型隧道。其中，星型隧道通常有一个集中控制器与多个客户端建立一对一隧道，通常这类隧道可以应用到接入网中，需具备NAT穿越的功能，并且能够AAA认证、用户管理等；而网状型隧道则不需要核心集中控制器来建立隧道，此时隧道的断点具有自动发现、自动建立的功能，这类隧道通常可应用于骨干网中。两种隧道的拓扑参见图7。,图7 隧道转换实现原理,由于在本文中主要考虑接入网的IPv6过渡方案，因此主要考虑星型网络下的隧道技术。,（3）典型的隧道技术,●DS-Lite,DS-Lite是一个网络层的IPv4 over IPv6的隧道，通过将IPv4流量封装在IPv6隧道中进行传输，接入网络为IPv6单栈，可以使用IPv6地址对数据报文进行惟一标识，并且避免了CPE侧的NAT转换。DS-Lite仅在AFTR侧做一次NAT转换，对IPv6地址无格式限制。,DS-Lite隧道方式取消了用户CPE侧的NAT转换，从而实现了网络中仅保留一次NAT转换，简化了IPv4地址的分配与管理，终端用户可使用任意IPv4私网地址。该隧道建立的过程无需进行协商，且接入网络可以仅为纯IPv6单栈。但DS-Lite也存在一定的局限性，例如DS-Lite必须对用户侧的CPE做一定的更改，在AFTR网关上需维护大量的NAT表项，具有一定的可扩展性问题和状态的同步问题，并且无法支持由通信对端发起的连接。,●A+P,A+P也是一个网络层IPv4 over IPv6的隧道，采用端口静态划分的方式复用IPv4地址，将网络核心侧的NAT转移到CPE侧，从而实现网络核心侧无状态的数据转发。在A+P中，将IPv4地址和端口范围内嵌到IPv6地址中，IPv6地址格式受限，且有特定前缀。,A+P的方案可实现网络核心无状态转换，并且可以复用IPv4地址。隧道可自动建立，无协商过程。但是其缺点在于一方面CPE需进行一定的升级，并且IPv6地址格式有一定的限制。,●TSP,TSP是基于隧道代理（Tunnel Broker）的一种信令协议，通过在两个端点间进行参数协商建立隧道，包括IPv4 over IPv6和IPv6 over IPv4两种类型，隧道的层次也可以通过协商确定，包括网络层和传输层UDP隧道。此时的IPv6地址为任意格式的地址，IPv4地址为公网地址。因此，若需要使用IPv4私有地址，则还需要额外增加NAT设备。,3.3 地址复用技术,地址共享机制可以分为两种类型，一种是采用IPv4私网地址进行地址共享（如CGN，DS-Lite等解决方案），此时需要引入运营级NAT，在不同网络边界处实现私网地址与公网地址的转换与映射；另一类则是采用公网IPv4地址进行地址共享，这类方案避免了运营级NAT转换，通过划分端口空间使得用户能够通过不同的端口空间来区分共享同一个公网IPv4地址，可以实现网络核心侧无状态地址复用。,4 结束语,协议翻译技术和隧道技术为两种可应用于不同场景的过渡技术，两个技术比较参见表1。,表1 协议翻译和隧道技术总结,由表1可见，目前协议翻译技术比较适用于IPv6?àIPv4和IPv4?àIPv6的场景，而隧道技术则比较适用于IPv4?àIPv4和IPv6?àIPv6的场景。协议翻译技术的优点在于部署简单和应用场景多样，缺点在于实现的复杂度较高。与此相对应，隧道技术实现较为简单，但是其缺点在于应用场景较为单一，且需要在用户侧和网络侧均部署相应的设备。因此，可以考虑将协议翻译和隧道技术相结合，从而可以发挥两者的优势，实现多场景的自适应选择和适配。
0