双栈基础上的下一代互联网过渡技术及策略

赵慧玲，陈运清，孙 琼，王 茜

（中国电信股份有限公司北京研究院 北京 100035）

1 概述

目前，IPv4地址已经呈现越来越紧缺的态势，分配机构（IANA）根据最近3年的地址使用数据，预测全球IPv4地址资源将于2011年底前后耗尽。在我国，IPv4地址短缺问题尤为严重。在这种情况下，IPv6作为下一代互联网惟一能够替代IPv4的核心协议已经得到了业界的广泛认同。IPv6地址逐渐替代即将枯竭的IPv4地址已成为互联网发展的必然趋势，也是目前互联网向下一代互联网过渡的重要历史时期。

虽然IPv6提供了巨大的地址空间，与IPv4相比，IPv6在其他方面也有很多改进，如IPv6的报头更加简洁，移动IPv6在入境过滤（ingress filtering）、三角路由、传输效率等方面也有很好的改进等。但是，IPv6协议与IPv4协议并不兼容，IPv6的报头结构、报头长度等都与IPv4有着很大的不同，业务应用对于IPv4和IPv6协议的使用方式也都有较大的区别，这些都直接导致IPv4和IPv6的业务无法实现互通等诸多问题。

IPv4和IPv6将会处于较长时间的共存期，针对共存期中如何顺利开展IPv4和IPv6的各项业务，推进IPv4向IPv6的演进过程，已经引起了业界的重视，除了目前研究相对成熟的双栈技术外，在国际标准化组织IETF中的Behave[1]、Softwire[2]等工作组也积极开展了其他相关过渡技术的讨论、制定和标准化过程。

鉴于目前相关过渡技术纷繁复杂、种类多样，本文将针对不同的应用场景，总结归纳目前的相关标准，并分析其优缺点及适用场景。

2 IPv4向IPv6过渡场景分析

IPv4向IPv6过渡场景可以从三个层面的协议类型进行描述：通信起点、网络和通信终点。

对于通信起点和通信终点而言，通常包括终端的操作系统协议类型和应用程序的协议类型。目前，常用的操作系统（如Windows 7、Vista等）都已经能够支持IPv4/IPv6双栈；支持IPv6的应用程序则既需要应用程序自身能够支持IPv6的socket调用，又需要操作系统能够提供IPv6的支持。通常支持IPv6的应用程序需要调用操作系统中与IPv6相关的系统调用（即操作系统内核必须支持IPv6），但相反，一个支持IPv6的操作系统并不意味着该操作系统中的应用程序就能够支持IPv6。目前支持IPv6的应用程序主要包括主流的浏览器（如IE、Mozilla Firefox等）、部分 FTP客户端（如 FlashFXP）、SSH客户端（如putty）、BT 软件（如 utorrent）等。此外，部分手机终端所支持的协议类型还与手机芯片所支持的协议类型指令集相关，若芯片无法支持IPv6指令集，则该手机终端也无法支持IPv6协议栈。

为了统一描述通信起点/终点的协议类型，本文以数据报文在传输至通信起点/终点边界时的类型来进行定义。若该数据包为IPv6的数据报文，则称该场景中的通信起点/终点为IPv6类型；否则，若该数据包为IPv4的数据报文，则称该场景中的通信起点/终点为IPv4类型。通常，支持双栈的应用程序（操作系统）既能发送/接收IPv4数据报文，也能发送/接收IPv6数据报文，而且目前的操作系统会优先选择IPv6作为通信的协议类型。

对于网络的协议类型而言，通常是由网络设备所支持的协议类型所决定的。对于仅支持IPv4的网络设备而言，只能传输IPv4的数据报文；对于仅支持IPv6的网络设备而言，只能传输IPv6的数据报文；对于支持IPv4和IPv6的网络设备而言，则既能传输IPv4的数据报文，又能传输IPv6的数据报文，此时网络传输协议类型为实际在网络中传输的数据报文类型。

因此，这样就可以定义IPv4和IPv6过渡、共存时期的应用场景，具体见表1。

本文暂不考虑传输网络包含多种情况的应用场景，如城域网和骨干网的网络设备协议类型不一致的情况。

这样，IPv4与IPv6共存时期就可以采用三段论的方式来进行描述了。由表1可知，IPv4与IPv6的共存期包含多种应用场景，与此相对应的过渡技术也有很多种类。其中，6-4-6、4-4-6、6-4-4和4-4-4主要应用于网络为 IPv4的情况，而4-6-4、4-6-6、6-6-4和6-6-6主要应用于网络已支持IPv6传输能力的情况。本文后续会在全面阐述IPv6过渡方案的基础上，重点讨论网络已具备IPv6传输能力的相关过渡技术。

表1 应用场景及其描述方式

3 已有过渡技术

迄今为止，已有的IPv4/IPv6过渡技术可以分为协议翻译类和隧道类，其中，IETF的Behave工作组主要研究协议翻译类的技术，而Softwire工作组则主要研究隧道类的技术。

3.1 协议翻译技术

（1）概述

IPv6过渡中的协议翻译类技术是由IPv4的NAT技术发展而来的。在IPv4的NAT技术中，为了减少IPv4公网地址的消耗，NAT协议翻译网关就为私网IPv4地址和公网IPv4地址建立起映射关系，通过端口的复用技术，从而达到一个公网地址可以由多个私网地址共享的效果。与此相对应，IPv6过渡中的协议翻译类技术就是将IPv6的数据包中的每个字段与IPv4数据包中的每个字段建立起一一映射的关系，从而在两个网络的边缘实现数据报文的转换。其应用场景如图1所示。

现有协议翻译技术已有很多不同的种类。其中，根据IPv6地址空间与IPv4地址空间映射的不同方法，可分为有状态协议翻译和无状态协议翻译。其中，有状态协议翻译（如NAT64[3]、PNAT[4]等）是通过建立映射表的方案，将任意IPv6地址与任意IPv4地址之间建立映射关系，而无状态协议翻译则是通过将IPv4地址内嵌到IPv6地址中，实现无状态地址翻译。因此，无状态协议翻译（如IVI[5]、DIVI[6]等）仅能访问具有特定格式IPv6地址的主机，而有状态协议翻译则能够访问任意地址格式的IPv6主机。

此外，根据协议翻译的位置，可以分为主机侧协议翻译、网络侧协议翻译以及主机侧和网络侧的协议翻译。主机侧协议翻译（如BIS[7]、BIA[8]等）在主机中完成翻译即可，完成端系统中应用程序协议类型与网络传输协议类型的不匹配，其应用场景为4-6-6或6-4-4；网络侧协议翻译（如 NAT64[3]、IVI[5]、Socks64[9]等）仅在网络中部署协议翻译网关即可，完成网络两侧协议类型的不匹配，其应用场景为6-6-4或4-4-6；而主机侧和网络中的两次协议翻译（如PNAT[4]）可应用于4-6-4和6-4-6的应用场景。

最后，根据协议翻译技术的协议层次，可以包括网络层协议翻译（如 NAT64[3]、PNAT[4]、IVI[5]、BIS[7]）、传输层协议翻译（如 TRT9）以及应用层协议翻译（如 BIA[8]、Socks64[10]等）。

本文在后面将介绍几个典型的协议翻译技术。

（2）典型的协议翻译技术

·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）总结

目前，协议翻译技术仍处在发展期，可用的成熟技术相对较少。下面总结协议翻译技术存在的几个关键问题。

·复杂性：由于协议翻译技术都需要单独处理每个报文的翻译，因此不可避免需要处理ALG、DNS翻译、分段等问题，实现较为复杂。此外，有状态协议翻译还需要进一步处理状态的维护、同步等各种问题，因此，实现就更为复杂。

·适用范围：协议翻译技术由于其本身的复杂性，通常部署于局部网络或中小型网络的边缘，以减小协议翻译系统的负担。

·有状态与无状态协议翻译选择：考虑到系统实现的复杂度，应尽可能使用无状态协议翻译技术。但是，由于无状态协议翻译仅能使用具有特定地址格式的地址，因此，对于运营商可控的地址部分（如用户的地址和一些自营业务的地址），可以使用无状态协议翻译中的特定格式来实现，而对于访问其他一些不可控的IPv6地址，则只能使用有状态协议翻译来辅助实现。

·ALG问题：协议翻译方案中，ALG是目前存在的最为主要的问题，维护成本高、且较难使用硬件来实现，对设备的性能要求也比较高。因此，在协议翻译器中，可考虑仅实现最为基本应用的ALG转换，对于其他复杂的转换，可以采用其他方式来实现。

3.2 隧道技术

（1）概述

隧道类技术是指将另外一个协议数据包的报头直接封装在原数据包报头前，从而可以实现在不同协议的网络上直接进行传输。其应用场景如图2所示。

在隧道类技术中，通过不同协议类型数据包的封装和解封装可以方便地实现数据包在不同协议类型网络中的传输穿越。因此，隧道方式相比协议翻译而言能够较为方便地实现原有流量的承载。

在隧道类技术中，根据其穿越的不同网络类型，又可以分为 IPv6-over-IPv4 类隧道（图 2（a））和 IPv4-over-IPv6 类隧道（图 2（b）），其中，支持 IPv6-over-IPv4的隧道类型较多，包括已经成为标准的 6to4[11]、6over4[12]、ISATAP[13]、TSP[14]、Teredo[15]、6PE[16]等 ，而支持 IPv4-over-IPv6 的隧道类型目前基本还都处于草案阶段，如DS-Lite[17]、A+P[18]、TSP[14]等。

此外，根据隧道封装的协议层次，又可以分为应用层隧道、传输层隧道（TSP）以及网络层隧道（DS-Lite、A+P等）。其中，应用层隧道的隧道报头通常包括以太头、IP头、TCP/UDP头和应用层的标识头；传输层隧道的隧道报头通常包括以太头、IP头、TCP/UDP头；而网络层隧道的隧道报头则通常包括以太头和IP头。

本文在后面将介绍几个典型的IPv4-over-IPv6隧道技术。

（2）典型的隧道技术

·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）总结

目前隧道技术（尤其是IPv4-over-IPv6）仍处在发展期。隧道技术比较适合于4-6-4和6-4-6的应用场景，实现较为简单。为了减少IP地址的消耗，隧道技术必须能够实现IP地址的复用。目前常见的IP地址复用方式通常包括基于LSN的动态地址复用以及基于端口范围（port range[19]）的静态地址复用。动态地址复用的方式需要引入运营级NAT，在不同网络边界处实现私网地址与公网地址的转换与映射，此时需保留连接的状态表。而静态地址复用的方式则通过划分端口空间使得用户能够通过不同的端口空间来区分共享同一个公网IPv4地址，可以实现网络核心侧无状态地址复用。

4 结束语

在IPv4向IPv6的过渡时期，目前可应用于IPv4与IPv6共存时期的相关过渡技术复杂多样，其中，协议翻译技术的优点在于部署简单和应用场景多样，但是其缺点在于实现的复杂度较高。与此相对应，隧道技术实现较为简单，但是其缺点在于应用场景较为单一。因此，在解决同种协议应用的访问时（如4-6-4或6-4-6的场景中）推荐使用隧道的方式来实现，而对于不同种协议的访问时（如6-6-4或4-6-6）则推荐采用协议翻译的方式。此外，由于各类过渡技术对于网络中的状态维护、地址分配管理、路由规划等都会带来不同的要求与影响，因此，在网络的实际应用中，应综合考虑各类技术对于网络部署及现网改造的影响，从而实现IPv4向IPv6的平滑过渡。

1 http://tools.ietf.org/wg/behave/

2 http://tools.ietf.org/wg/softwire/

3 BagnuloM,MatthewsP,vanBeijnum I.StatefulNAT64:network address and protocol translation from IPv6 clients to IPv4 servers.Draft-ietf-behave-v6v4-xlate-stateful-11 (work in progress),March 30,2010

4 Huang B,Deng H.Prefix NAT:host based IPv6 translation.Draft-huang-behave-pnat-01(work in progress),February 19,2010

5 Li X,Bao C,Chen M,Zhang H.The cernet IVI translation design and deployment for the IPv4/IPv6 coexistence and transition.Draft-xli-behave-ivi-07(work in progress),January 6,2010

6 Li X,Bao C,Zhang H.Address-sharing stateless double IVI.Draft-xli-behave-divi-01(work in process),October 26,2009

7 Tsuchiya K,Higuchi H,Atarashi Y.Dual stack hosts using the"Bump-In-the-Stack"technique(BIS).RFC2767,February,2000

8 Lee S,Shin M-K,Kim Y-J,et al.Dual stack hosts using"Bump-in-the-API"(BIA).RFC 3338,October,2002

9 Hagino J,Yamamoto K.An IPv6-to-IPv4 transportrelay translator.RFC3142

10 Kitamura H.A socks-based IPv6/IPv4 gateway mechanism(socks 64).RFC 3089,April,2001

11 Carpenter B,Moore K.Connection of IPv6 domains via IPv4 clouds.RFC 3056

12 Carpenter B,Jung C.Transmission of IPv6 over IPv4 domains without explicit tunnels.RFC 2529

13 Templin F,Gleeson T,Talwar M,et al.Intra-site automatic tunnel addressing protocol(ISATAP).RFC 4214

14 Blanchet M,Parent F.IPv6 tunnel broker with the tunnel setup protocol(TSP).RFC 5572

15 Huitema C.Teredo:tunneling IPv6 over UDP through network address translations(NATs).RFC 4380

16 De Clercq J,Ooms D,Prevost S,et al.Connecting IPv6 islands over IPv4 MPLS using IPv6 provider edge routers (6PE).RFC 4798

17 Boucadair M,Jacquenet C,Grimault J L,et al.Deploying dual-stack lite (DS-lite)in IPv6 network.Draft-boucadair-dsliteinterco-v4v6-03(work in process),February 24,2010

18 Bush R.The A+P approach to the IPv4 address shortage.Draftymbk-aplusp-05,October 27,2009

19 Ripke A,Quittek J,Brunner M.Dynamic port range re-assignments foraddresssharing.Draft-rqb-dynamic-port-ranges-02,March8,2010