IPv4向IPv6过渡技术标准综述(1)(2)

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的场景。协议翻译技术的优点在于部署简单和应用场景多样，缺点在于实现的复杂度较高。与此相对应，隧道技术实现较为简单，但是其缺点在于应用场景较为单一，且需要在用户侧和网络侧均部署相应的设备。因此，可以考虑将协议翻译和隧道技术相结合，从而可以发挥两者的优势，实现多场景的自适应选择和适配。