内容提要
由于IPv4地址分配殆尽，向IPv6过渡已经迫在眉睫。由于IPv4协议和IPv6协议的语法、语义和时序不同，不能兼容，IPv4互联网向IPv6互联网过渡已经成为世界性技术难题。本章分析了过渡的几种主要场景，进一步介绍了目前主要的隧道技术和翻译技术的基本原理和主要协议。
4.1 概述
4.1.1 过渡背景
在过去的20多年中，伴随着互联网的快速发展，IPv4协议[2]取得了巨大成功。当前全球IPv4用户已经超过20亿，占到人口总数的28%。然而，网络规模的急剧增长也突显出IPv4的一系列严重问题，包括地址空间不足、路由可扩展性问题等。2011年2月，IANA将其最后5个/8的IPv4地址块分配给了RIR，这也标志着全球基于IPv4协议的43亿地址资源已全部分配完毕，而研究表明，RIR在三年之内也会将地址全部分配完毕[3]。但是互联的规模仍在快速增加，特别是互联网的移动设备数量在不断增长。这些都需要新的IP地址分配，但是从现有情况来看，IPv4是不能够满足的。另外，由于IPv4地址块分离、多重连接等问题造成不能有效聚合路由，进而导致了路由器中需要维护大量的路由表项，增加了路由查找和存储的开销，这成为互联网进一步发展的瓶颈。而大范围的NAT破坏了端到端的透明性，却并不能从根本上解决IPv4地址紧缺的危机。
IPv6协议[4]的提出正是为了解决这些问题，进而取代IPv4。IPv6具有巨大的地址空间，从根本上解决了IPv4地址紧缺的问题。IPv6对报头做了简化，采用40字节的固定报头，不仅减小了报头长度，而且由于报头长度固定，路由器上的处理也更加便捷；另外，IPv6还采用了扩展报头机制，更便于协议自身的功能扩展；IPv6报头中增加了流标签字段，使用流标签功能可以更好地实现服务质量（QoS）支持。无状态地址自动配置可以支持即插即用的特征[5]，此外，IPv6具有更好的端到端特性，更好的安全性和移动性支持等特性[6]。IPv6是对IPv4的重新设计，解决了IPv4所产生的问题进而提供更好的服务，具有大幅推进互联网发展的潜力，是下一代互联网的支撑协议。
然而IPv6的设计并不兼容IPv4：IPv6不能与IPv4直接通信。本质上讲IPv6是与IPv4平行、独立的网络协议。如果IPv4想要进一步支持IPv6通信，就必须能够执行IPv6路由，而且网络设备也要支持IPv6协议。当前的IPv6应用和IPv6内容服务只占少数[7]，大量的网络资源、服务和应用仍位于IPv4网络中，因此IPv4网络仍然会长时间存在。另外，对地址的需求促进了IPv6的发展，可以预见IPv4和IPv6将会长期共存，并且将会逐渐过渡到IPv6。在此期间需要保证IPv4和IPv6的可用性，以及双栈环境下的DNS、QoS和安全等问题。总体来说，需要多种过渡机制来保证IPv4和IPv6的连通性，进而加快IPv6的过渡进程。
IPv6过渡是十多年来IETF争论的一个热点话题。大约在2000年，科研人员提出了一系列的过渡机制，包括6to4[8]、6over4[9]、NAT-PT[10]、SIIT[11]、BIS[12]等。然而这些机制并没有得到大范围的部署，而且这些机制也没有完全解决过渡问题。原因是这些机制并没有全面考虑可扩展性、寻址、部署模式和IPv4地址紧缺等因素。一些机制甚至因为上述原因而被废弃。但是这些机制确实推动了进一步的研究工作。在2004—2005年，IETF创建两个工作组——Behave和Softwire来进一步解决过渡问题，并且研究更完善的过渡机制。
4.1.2 异构网络互联问题
异构网络中互联的问题是要在IPv4和IPv6的混合网络中建立连接。一个重要的特点是连接的建立需要穿越一个或多个IPv4-IPv6边界，但是IPv4-IPv6边界并不能互操作。由于最终的目的是迁移到IPv6网络，能够互操作有利于克服IPv4存在的影响[13]。理论上讲，IPv4与IPv6互联时可能需要穿越多个网络边界，但是最终可将其归结为两个基本问题：异构网络互联。这也是研究问题的一个有效方法，因为许多更复杂的场景可以分为多个这样的基本问题，解决方案也紧紧围绕着本地寻址和路由，而且IPv4和IPv6 Internet都是有组织的，并非自由分布，这两个基本问题也是现实网络中最常见的实例。
当两个直联的网络或主机使用不同的地址族时，就会出现异构网络互联问题。为了实现IPv4网络或主机与IPv6网络或主机的通信，需要引入过渡技术。由于通信报文的源地址与目的地址采用的是不同的地址族，因此，为了实现这样的异构通信，协议转换机制是必不可少的。
IETF Behave工作组[14]致力于研究异构互联问题的解决方案，并将这些解决方案推行为行业标准。根据网络规模及通信发起方的不同，Behave工作组提出了异构互联问题中存在的8种不同的场景：IPv6网络向IPv4网络发起通信，IPv6网络向IPv4互联网发起通信，IPv6互联网向IPv4网络发起通信，IPv6互联网向IPv4互联网发起通信，IPv4网络向IPv6网络发起通信，IPv4网络向IPv6互联网发起通信，IPv4互联网向IPv6网络发起通信，IPv4互联网向IPv6互联网发起通信。
需要说明的是上述场景中的“网络”与互联网相比具有更明确、更具体的管理域，如企业级校园网、移动运营商蜂窝网络、住宅区小区网络等。不同的场景对可扩展性的要求不同，这使得在上述场景中实现异构网络互联的难点不尽相同。因此需要对上述场景分别进行考虑。除了网络间的异构互联场景外，异构互联问题还存在两种特殊的场景，即IPv4应用通过主机的IPv6连接与IPv6网络进行通信，以及IPv6应用通过主机的IPv4连接与IPv4网络进行通信。在这种情况下，主机中的TCP/IP协议栈需要提供协议转换机制，使得IPv4/IPv6应用能通过IPv6/IPv4协议进行通信。显然，该问题可以看成应用与异构网络之间的异构互联问题。
当处于IPv6/IPv4网络中的两个或更多IPv4/IPv6本地网络或主机需要进行通信时，就会出现异构穿越问题。为了实现这种穿越异构网络的通信，需要引入过渡技术。如果IPv4本地网络或主机被IPv6网络分隔，则需要使用IPv4-over-IPv6穿越机制；反之，则需要使用IPv6-over-IPv4穿越机制。
IETF Softwire工作组[15]致力于研究异构穿越问题的解决方案，并将这些解决方案推行为行业标准。Softwire工作组将异构穿越问题划分为两种典型场景：网状网络（Mesh）通信与星形网络（Hub＆Spokes）通信[16]。在网状网络通信场景中，采用相同地址族的若干网络孤岛之间的通信被使用另一种地址族的网络所分隔。在星形网络通信场景中，若干使用相同地址族的主机或子网与处于中心的本地接入点的连接被使用不同地址族的网络所分隔。前一种场景通常出现在主干网中，而后一种则通常出现在边缘网中。
由于IPv6和IPv4的不兼容性，实现异构互联和异构穿越并不容易。IPv6与IPv4地址格式长度相差96比特，这使得不可能建立IPv4地址与IPv6地址的一一映射。虽然将IPv4地址空间映射到IPv6中很容易实现，但IPv6地址空间显然不可能被完整地映射到IPv4中。
除了采用过渡技术解决上述异构网络共存问题外，另一种可选方法就是将互联网升级为同时支持IPv4和IPv6的双栈网络。任何两个节点间都能使用IPv4或IPv6进行通信；IPv4-IPv6异构互联或穿越问题将不复存在。在这种情况下，整个互联网将成为两个物理设备上统一而逻辑上分离的网络。然而，双栈互联网既不实用，也不是一种能长期采用的解决方案。由于地址空间耗尽，大规模地扩张IPv4互联网是不切实际的，并且升级全网使其同时支持IPv4和IPv6的巨大开销是不可接受的。
尽管如此，在小规模网络中采用双栈网仍然是可以接受的。实际上，由于不同协议存在不兼容性，双栈节点是实现IPv4与IPv6网络交互不可或缺的组成部分。具体而言，处于IPv4与IPv6网络边界处的双栈节点与IPv4和IPv6网络都能进行通信，进而能为IPv4和IPv6的异构交互提供支持。基于这一点，目前研究领域已经提出了两类过渡技术——翻译技术和隧道技术。
4.2 翻译技术
4.2.1 翻译技术基本原理
IPv4-IPv6翻译技术是指将IP数据包在IPv4和IPv6两种协议簇之间转换，它能够实现IPv4和IPv6的互通。其基本原理在IPvX和IPvY的语义间进行转换，将去往IPvX网络的IPvY包转换成IPvX包，将去往IPvY网络的IPvX包转换成IPvY包。翻译的基本操作包括地址映射和报文翻译，而报文翻译涉及网络层、传输层和应用层。通常情况下翻译发生在IPvX-IPvY的边界处，所以翻译器可能是地址簇边界路由器。假设IPvX网络的Host1要连接IPvY网络中的Host2，Host1在建立连接之前必须先要学到Host2的IPvX地址，然后数据包以这个地址作为目的地址发送到翻译器，翻译器将报头翻译成IPvY报头，并转发给Host2。另外，数据包的IPvY源地址（Host1的IPvY地址）是在翻译时由翻译器分配的或计算出来的。IPv4-IPv6翻译技术与当前广泛应用的IPv4 NAT是有一定相似性的，然而将翻译技术运用到大规模的网络及不对称的IPv4/IPv6地址空间上，其技术难度比IPv4 NAT大很多。
翻译技术的基本操作是对IPv4和IPv6报文的翻译，涉及网络层、传输层和应用层，包括地址转换（可能涉及端口）、相应协议字段翻译，以及必要的应用层翻译（针对应用层报文中出现IP地址和端口的情况进行转换[17]）。此外，为协调IPv4和IPv6协议本身的一些区别，保证跨协议的语义正确性，还需要特殊处理分片重组与路径MTU检测，以及ICMP协议等[18]。而在控制层面，需要维护地址转换规则，确保正确寻址，并根据地址转换规则，向两侧IPv4与IPv6网络分别发布相应的路由。按照地址转换方式的不同，网络侧的翻译技术可分为无状态翻译与有状态翻译两类。另外还有主机侧翻译，通常用于终端用户的TCP/IP协议栈。
4.2.2 无状态翻译
SIIT[11]是较早提出的无状态翻译技术，它给出了IPv4和IPv6间的无状态翻译的基本场景与IP/ICMP翻译算法，基本原理IIT基于IPv6网络内每个主机拥有IPv4地址的前提，这些主机的IPv6地址都相应按照固定IPv6前缀0：ffff：0：0：0/96+IPv4地址的形式生成，称为IPv4-translated地址，这些IPv6地址潜在的与IPv4地址相匹配。另外，IPv6地址由一个真实的IPv4地址添加另一种前缀：ffff：0：0/96的方式形成，这一类地址称为IPv4-mapped地址，这个IPv4地址代表了在IPv6网络中的一台IPv4主机。然而，SIIT并没有提出IPv6主机如何获取IPv4-translated地址，也没有指出IPv6/IPv4主机如何学习到对端的IPv4-mapped/IPv4-translated地址，地址映射规则的路由支持也没有指出。按上述两种地址映射方式，地址翻译可以通过映射算法来完成。SIIT的翻译设备在将IPv4包翻译成IPv6包时，只须将源地址、目的地址分别加上：ffff：0：0/96和0：ffff：0：0：0/96的前缀；在将IPv6包翻译成IPv4包时只需将源地址、目的地址分别去掉0：ffff：0：0：0/96和：ffff：0：0/96的前缀。
SIIT通过地址转换规则可以保持翻译器无状态维护，它对所有的数据包采取统一的处理过程。数据层面的性能也与用户的规模无关，并且能够达到预期的线速；只要异构寻址可以实现，SIIT就可以提供双向通信。SIIT可以提供传统IPv4和IPv6的双向通信，因此在一定程度上推进了IPv6的发展，而且SIIT没给网络带来新的安全问题。然而，IPv4-translated中使用固定前缀，不同的前缀由/96前缀和SIIT主机的IPv4地址的前缀组成，这些前缀可能会注入IPv6网络中的RIB（Routing Information Base）和FIB（Forwarding Information Base）中，而它们又是不可以聚合的，最终会导致严重的路由可扩展性问题。由于SIIT要求IPv6主机拥有IPv4地址，因此只适用于一定规模内的IPv6网络的情况，因此只适用于IPv6网络？IPv4网络场景和IPv6网络？IPv4互联网场景。
IVI[19]机制在继承无状态翻译的基本原理的基础上，对SIIT进行了改进，IVI采用一个网络专用的可变前缀（NSP）取代SIIT中两个/96的固定前缀，IPv4-translated地址和IPv4-mapped地址均采用“NSP+IPv4地址+后缀”[20]的形式。这样，IPv6域内无须维护两个固定前缀的路由，NSP路由与IPv6主机的编址自然耦合，前缀可聚合。而在地址分配方面，可以通过DHCPv6或SLAAC将IPv4-translated地址分配给IPv6主机。IPv6主机可以通过本地的DNS服务器DNS64[21]获得IPv4主机的IPv4-mapped地址，DNS64地址映射规则将IPv4主机的A记录转换成AAAA记录。另外，IPv6主机将它们的IPv4地址作为A记录注册到DNS服务器，这样就可以为IPv4网络侧提供地址查询记录。在路由方面，IVI的翻译设备（如IVI网关）上，须向IPv4侧发布IPv6主机占有的IPv4地址前缀的路由，向IPv6侧发布NSP的默认路由。
IVI机制是SIIT在可用性上的改进，路由可扩展和寻址的问题都得到了解决，同时也保留了SIIT的优点，包括高性能、支持双向无状态通信、推进IPv6的发展及不会造成安全问题，因而同样适用于IPv6网络？IPv4网络和IPv6网络？IPv4互联网4种场景。IVI机制本身仍需要消耗IPv6用户量级的IPv4地址，对此IVI又给出了支持IPv4地址复用[22]的扩展方案，每个IPv6主机只占用1个IPv4地址的一部分端口空间。但这种方案需要主机端或CPE端进行相应的端口映射。
4.2.3 有状态翻译
NAT-PT[10]是较早提出的一种双向有状态翻译技术。NAT-PT原理。与SIIT不同，有状态翻译并不将IPv4地址的所有权分发到每个IPv6主机，而是在翻译设备上形成地址池统一管理，而且资源的使用达到每端口的粒度，其地址数量通常也比IPv6主机数量要小得多。NAT-PT是一种比较早的有状态翻译方案，声称支持IPv6→IPv4和IPv4→IPv6。NAT-PT在将IPv4主机的地址映射到IPv6时，仍采用了SIIT和IVI的编址方式：添加IPv6前缀（：/96）并产生IPv4-mapped地址。而在将IPv6主机的地址映射到IPv4时，NAT-PT采用了类似于IPv4 NAT的有状态地址+端口动态映射的形式，更精确地说是基于实时的每流，翻译器将IPv6主机的地址+传输层ID（TCP/UDP端口或ICMP ID）与地址池中的IPv4地址+一个可用传输层ID动态绑定。为了协调两种编制方案，NAT-PT翻译器需要向IPv4网络侧宣告地址池的IPv4前缀，也需要向Ipv6网络侧宣告IPv6：/96前缀。在数据层面上，当需要将一个IPv6数据包翻译成IPv4数据包时，翻译器利用IPv6源地址和端口查找NAT绑定表，找出对应的IPv4源地址和端口（如果找不到就创建一个新的表项）；目的IPv4地址通过删除Ipv6前缀获得。当需要将IPv4数据包翻译成IPv6数据包时，翻译器给源IPv4地址添加前缀形成源IPv6地址，利用IPv4地址和端口查找NAT绑定表找出相应的IPv6目的地址和端口（如果找不到则丢弃数据包）。
NAT外侧为IPv4，内侧为IPv6，这就造成了两侧发起通信时寻址的难度不同。若IPv6发起通信访问IPv4，源端在得知目的IPv4地址后，只须添加前缀形成IPv6源地址，发出的IPv6报文就能准确到达翻译器，源地址与端口被动态映射成IPv4地址和端口，并创建NAT表项；若IPv4发起通信访问IPv6，则除非事先在NAT上创建并维持映射表项，否则源端无法获知目的IPv4地址+端口（映射后），发出的IPv4包即使到达NAT，也会因NAT上不具备匹配的表项而无法被映射到IPv6，随即将会被翻译器丢弃。NAT-PT方案中给出了借助于DNS ALG寻址的解决方法。当IPv6网络中有用户发起AAAA请求时，翻译器将这个请求转换成A请求，并且将返回的A记录映射成IPv6地址，作为解析地址返回给IPv6用户。当IPv4用户发起A请求时，翻译器将请求转换成AAAA请求后转发到DNS服务器，服务器响应后，返回AAAA记录，翻译器从AAAA响应报文中获得IPv6地址，并从IPv4地址池中取出一个IPv4地址与这个IPv6地址绑定，随后将IPv4地址作为响应地址返回给IPv4用户。在更一般的情况下，为每流做绑定就需要扩展DNS协议，使其包含端口的信息，这也是对当前DNS模式的重要改变。
NAT-PT查找绑定表的操作可能成为性能的瓶颈。在使用软件实施的情况下，数据处理的速度将与绑定表的规模成反比；而使用硬件来实现时，所需要的代价和容量将会随着绑定表规模的增加而增大。创建一条新的绑定条目产生的时延也会降低数据处理的速度。而其优点就是对IPv4地址的利用率要比无状态翻译高，支持与传统IPv4通信，这也推进了IPv6的发展。然而NAT-PT方案存在诸多问题，而且其异构地址寻址非常难[23]，因而其协议标准在制定后也被IETF重新废弃。
实际上，NAT-PT在IPv6访问IPv4这一方向上是基本可行的，于是业界对其加以改进，提出了IPv6访问IPv4的有状态翻译方案NAT64[24]。NAT64沿用了NAT-PT地址映射的基本原理，明确了IPv4主机地址映射到IPv6时使用固定前缀64：FF9B：/96。因此翻译器需要将IPv6前缀发布发到IPv6网络中，并将IPv4地址池的IPv4前缀发布到IPv4网络中。在寻址方式上，NAT64细化了DNS寻址的方法，将DNS翻译的功能从翻译器中独立出来，形成独立的DNS64设备。该设备级联在实际网络的DNS系统中，它将来自于IPv6主机的AAAA请求转换成A请求，并且将A记录添加固定前缀形成IPv6域名记录，交给IPv6主机。NAT64在数据层面上的处理流程和NAT-PT类似。
NAT64的性能和NAT-PT相似，主要的安全问题是对绑定表的DoS攻击，但是通过IPv6侧的入口过滤就可以解决这个问题。NAT64方案的适用场景包括IPv6网络→IPv4互联网、IPv6互联网→IPv4网络、IPv6网络→IPv4网络。状态维护的特性决定了它不可能适用于IPv6互联网→IPv4互联网的场景。而对IPv4访问IPv6的4种场景，现有NAT-PT的机制并不可行。
4.2.4 主机侧翻译
除了网络部分的翻译，客户端也有一些翻译机制，如BIS[12]和BIA[25]。这两种翻译机制应用的网络场景是通信发起方的主机上的IPv4应用程序需要通过IPv6网络访问对端IPv6主机。这种情况下通信发起方的主机仅支持IPv6网络接入，并且要访问的远程主机也在IPv6网络中，但应用层软件仅支持IPv4通信协议栈。所以需要在通信主机的TCP/IP协议栈中嵌入一种IPv4-IPv6翻译协议，通过模拟IPv4网络环境使应用程序对IPv6网络透明化。仅支持IPv4通信的应用程序通过此种翻译协议可以解决在纯IPv6网络环境中无法通信的问题，从而减轻软件开发者升级软件的负担。反之，IPv6应用程序通过IPv4网络访问时则不需要进行翻译。上面的场景中，可以简单使用原有IPv4应用程序。
BIS和BIA采用不同的机制来完成这一翻译过程。BIS（Bump-In-the-Stack）基于每个数据包进行翻译，而BIA（Bump-In-the-API）翻译机制是基本Socket层来处理的。它们都同时为每个远程主机维护状态化的IPv4-IPv6地址绑定表（不包括端口号）。在地址跟踪阶段通过DNS ALG来触发。任何未分配的IPv4地址都可以用来创建绑定条目并分配给BIS/BIA主机使用，因为这些IPv4地址仅在主机上生效。BIS基于该绑定表执行数据包翻译，当上层应用发起IPv4通信时，所有的IPv4数据包会被BIS重新翻译成IPv6报文，使用通信方主机的IPv6地址为源地址，并在绑定表里查找目的主机的IPv6地址。当BIS主机从网络上接收到一个IPv6数据包时，BIS会自动将其翻译成IPv4数据包，使用主机的IPv4地址作为目的地址，通过IPv6源地址在绑定表里查找源主机的IPv4地址。BIA使用绑定表进行socket翻译。支持将应用程序对IPv4 socket的调用翻译成IPv6 socket，并返回IPv6 socket值给IPv4主机。所有数据同样在IPv4 socket和IPv6 socket之间进行处理。因为仅通过socket API进行转换，所以BIA里没有IPv4数据报文。
BIS和BIA均通过软件来实现终端主机的数据包翻译。它们只负责转换主机内部的IPv4数据流，对主机的性能影响甚微。这两种翻译机制的潜在风险也仅存在于终端主机上，某些应用程序通过生成大量的DNS查询请求来耗尽IPv4地址池和绑定条目表的空间来进行DoS攻击。显然，这两种机制通过缓解上层应用的过渡来加快IPv6网络的发展。
4.2.5 翻译机制总结
翻译机制总结信息，翻译技术的固有问题包括以下几点。
（1）可扩展性不足：无状态翻译需要1：1消耗IPv4地址，而有状态翻译需要维护每流映射的状态。因此这两类技术都不适用于大规模网络。
（2）异构寻址可能需要上层应用感知：除域名寻址外，应用程序还可能采取其他寻址方式，如直接访问对端IP等。此时应用程序需理解地址映射的方式，才能正确使用翻译机制。
（3）应用层翻译问题：在应用层协议中包含IP地址或端口时，正确的语义翻译要求映射这些地址端口。而考虑到应用层协议的多样性，网络翻译设备上不可能实现实时的应用层翻译。
这些问题从根本上说，是由于翻译打破端到端特性，以及IPv4-IPv6地址空间不对称导致的。在使用翻译技术时，必须注意这些问题。当前业界的态度是承认这些问题的存在，但他们仍然想要使用这些机制，同时为减轻这些问题的影响做了许多努力。例如PCP协议[26]，为终端用户提供一个向翻译器申请地址和端口映射的方法；还有PET[27][28]，提出使用隧道转移翻译地点的思想。
当前主流的翻译机制是网络翻译，其中IVI是一种灵活的无状态翻译机制，NAT64是一种灵活的有状态翻译机制。无状态的翻译机制可以实现双向通信，但需要消耗大量的IPv4地址；有状态翻译机制可以提高IPv4地址的利用率，但是需要维护每流的状态。到目前为止，还没有IPv4→IPv6场景下的可行的有状态解决方案，也没有IPv4→IPv6 Internet场景下可行的无状态解决方案。用户侧翻译提供了一个在IPv6网络中保留IPv4-only应用的方法，无须应用程序升级。
