统一的IPv4/IPv6翻译与封装过渡技术——IVI/MAP—T/MAP—E

摘要：采用无状态翻译技术和双重翻译/封装技术IVI/MAP-T/MAP-E定义IPv4/IPv6地址的映射算法和协议翻译/封装算法，在保持互联网地址端对端的特性的基础上，使IPv4和IPv6互联互通，支持由IPv4和IPv6双向发起的访问。无状态翻译技术和双重翻译/封装技术有着不可替代的综合优势，是IPv4/IPv6过渡的必经之路。

关键词： 无状态翻译；地址映射；协议翻译

Abstract： Stateless translation and stateless double translation/encapsulation technologies （IVI/MAP-T/MAP-E） define the address mapping and protocol translation/encapsulation algorithms between IPv4 and IPv6. IVI/MAP-T/MAP-E technologies maintain end-to-end address transparency between IPv4 and IPv6 and support communication between IPv4-only and IPv6-only end systems. IPv4/IPv6 translation is a critical technique for IPv4/IPv6 transition.

Key words： stateless translation； address mapping； protocol translation

基于IPv4协议的互联网是世界上最重要的信息基础设施，但是只有232个地址空间的IPv4地址已经分配完毕。为了解决IPv4地址耗尽问题，目前有两种技术路线：采用IPv4地址翻译技术（NAT44）或升级到IPv6。NAT44是IPv4公有地址与IPv4私有地址之间的有状态翻译技术，已经非常成熟，但由于其破坏了端到端特性，只能支持单向发起的通信。多年以来，NAT44在用户接入端被广泛使用，但在核心网络上使用时，需要在NAT44翻译器上维护大量状态。为了长远地解决IP地址的问题，建设下一代IPv6网络，发展IPv6信息资源，发展IPv6用户势在必行。10多年前，业内已经认识到IPv4地址枯竭问题，发明了下一代互联网协议IPv6，该协议具有2128个地址空间，从根本上解决了地址耗尽的问题。因特网工程任务组（IETF）最早推荐从IPv4向IPv6过渡采用双栈技术和隧道技术，全世界很多运营商在不同规模上进行了IPv6的试验，若干信息提供商也提供了IPv6的服务[1]。但截至2012年，全世界IPv6网的流量平均不到IPv4的1%。实践表明，升级到双栈不仅没有给运营上带来直接的收益，反而影响了用户的体验。这就是为什么双栈和隧道技术应用10多年，却没有推动完成IPv4互联网向IPv6互联网过渡的原因。从根本上看，网络的价值在于其用户数。对于新建的IPv6网络，其用户数不可能与IPv4互联网上的用户数可比，如果IPv6的用户不能与IPv4的用户互联互通，则IPv6网络没有任何存在的价值。因此过渡的核心问题是新建IPv6网络必须与IPv4互联网互联互通。两种不同协议之间的互联互通，只能通过翻译技术解决，但是由于IETF在设计IPv6协议时，没有充分意识到与IPv4协议兼容的重要性，具有很高的技术难度。随着纯IPv6网络建设案例的增多和研究的深入，IETF在IPv4/IPv6翻译技术，特别是无状态翻译技术取得了突破性进展，形成了系列RFC标准和工作组草案，为IPv4到IPv6过渡提供了新的技术方案。

1 无状态IPv4/IPv6翻译技术

互联网的基本特性为“无连接”的体系结构，路由器不需要维护状态，IPv4/IPv6翻译器本身也是一个路由器，因此无状态的IPv4/IPv6翻译器对于运营商来讲更具有价值。同时，无状态IPv4/IPv6翻译（IVI）技术具有可扩展性、可管理性、安全性好的特点，并支持双向发起的通信。IVI的名称借用了罗马数字的表示方法。在罗马数字中IV表示4，VI表示6，IVI表示IPv4和IPv6的互联互通。

1.1 IPv4/IPv6翻译技术的应用场景

由于IPv4的地址空间为232，IPv6的地址空间为2128，极其悬殊，因此不加限制条件的IPv4/IPv6翻译器在理论上讲是不可行的。在IETF标准RFC6144中定义了IPv4/IPv6翻译的8个应用场景。翻译器的两边一边是IPv4另一边是IPv6。其变化之一在于哪一边是自己控制的网络，哪一边是互联网。其变化之二在于哪一边发起通信。无状态IPv4/IPv6翻译技术的应用场景如图1所示[2]。场景一为IPv6网络上计算机发起对IPv4互联网上计算机的访问，场景二为IPv4互联网上计算机发起对IPv6网络上计算机的访问。

场景一和场景二意味着新建纯IPv6网络，通过翻译器XLAT为IPv6用户提供对IPv4互联网的通信。无状态IPv4/IPv6翻译技术可以适应于场景一和场景二，有状态IPv4/IPv6翻译技术只能适应于场景一。IPv4/IPv6翻译技术的核心是需要解决地址映射和协议翻译问题。

1.2 地址映射和域名翻译

由于IPv4和IPv6的地址空间差距巨大，用IPv6表示IPv4是毫无问题的，可以通过无状态的映射方法，映射后的IPv6地址称为转换地址。用IPv4表示IPv6是难点，可以动态维护映射表，作有状态的地址映射，或在IPv6地址中选择一个子空间通过无状态的方法与IPv4地址映射。映射后的IPv6地址称为可译地址。所有这些地址映射算法均在IETF标准RFC6052中定义。嵌入了IPv4地址的IPv6地址格式如图2所示[3]。

其中Prefix是IPv6网络前缀，根据不同的前缀长度，嵌入IPv4地址，并且在64至71位间保持为全0，以便与IPv6地址结构中的u-bit兼容。Suffix为后缀，在基本的地址映射中为全0，预留给传输层端口的编码，以便把一个IPv4地址映射为若干IPv6地址，达到高效地、无状态地复用稀缺的公有IPv4地址资源的目的。此外，RFC6052要求转换地址和可译地址使用同样的前缀（Prefix），从而可以自动获得最优路由。

当纯IPv6计算机发起对IPv4互联网的访问时，必须获得相应的转换地址，这个工作由域名翻译器DNS64根据上述映射算法完成，由RFC6147定义[4]。DNS64是同时接入IPv4网络和IPv6网络的域名服务器（DNS），能够把A记录动态翻译成AAAA记录。具体步骤为纯IPv6计算机通过DNS64查询所需域名的AAAA记录，如AAAA记录存在，则DNS64直接返回AAAA记录给纯IPv6计算机；如AAAA记录不存在，则DNS64查询域名对应的A记录，并根据RFC6052定义的映射算法，生成AAAA记录返回给纯IPv6计算机。无状态的翻译器支持IPv4互联网发起的通信，在这种情况下，需要静态配置的DNS46，当IPv4互联网上的用户发起对IPv6计算机的访问时，DNS46则返回对应IPv6计算机AAAA对应的A记录[5]。

1.3 协议翻译

两种不同协议栈之间的互联互通必须解决的第二个问题是协议翻译，所庆幸的是IPv4和IPv6之间协议的差距并不很大，是可译的。具体协议翻译算法由RFC6145定义，包括版本号映射，IPv4的服务类型与IPv6的流量等级映射，IPv4的总长与IPv6的载荷长度映射，IPv4的存活期与IPv6的转发计数映射，IPv4的传输层协议与IPv6的下一个头映射，IPv4地址和IPv6地址映射等[6]。IPv4与IPv6协议翻译的最大难点是分片处理，因为IPv4可以支持路由器分片或端系统分片，但IPv6仅支持端系统分片。对于IPv4已经分片的分组，IPv6必须增加分片扩展头，以便端系统重组。此外，IPv4和IPv6网络所能支持的最大传输单元的大小（MTU）是不同的，同时由于IPv4的基本头为20个字节，而IPv6的基本头为40个字节，因此在从IPv4到IPv6的翻译过程中必然遇到MTU超出的问题。此外，IPv4的传输控制协议（ICMP）和IPv6的传输控制协议（ICMPv6）也有很多不同，需要分别处理。

值得指出的是，当IPv6网络中的路由器（通常并不使用可译地址）返回ICMPv6分组时，翻译器无法找到对应的IPv4地址，造成翻译后的ICMP分组的源地址不可溯源。IETF最新的RFC6791定义了对这个问题的有效处理方法[7]。

RFC6145也是有状态IPv4/IPv6翻译器所依据的协议翻译算法。有状态IPv4/IPv6翻译器中的状态维护技术由RFC6146定义，主要规定了IPv6地址和端口到IPv4地址和端口的动态映射表的生成、维护和销毁算法[8]。

2 无状态双重翻译/封装

技术（MAP系列）

IPv4/IPv6翻译技术可以使IPv4和IPv6互联互通，但仍有3个问题需要解决。第一个问题是由于IPv4地址耗尽问题，无状态IPv4/IPv6翻译必须能够复用公有IPv4地址以高效使用IPv4地址资源；第二个问题是目前有的应用程序并没有IPv6的版本（如Skype），也有的应用程序嵌入了地址的信息（如Ftp）；第三个问题是对于终端用户往往需要分配一个64位的前缀，而不是单个的IPv6地址。无状态双重翻译/封装系列技术MAP-T/MAP-E可以解决这些问题。MAP是Mapping Address and Port的缩写，意指无状态地对地址和端口进行复用，与双重翻译（MAP-T）或封装（MAP-E）技术组合，可以解决无状态复用公有IPv4地址的问题和上述的应用程序问题，同时可以支持前缀分配。MAP-T/MAP-E目前是IETF的工作组文档[9-10]，其他相关的工作组文档还有DHCPv6扩展[11]和部署考虑[12]。

2.1 双重翻译模式的应用场景

无状态双重IPv4/IPv6翻译模式（MAP-T）的应用场景如图3所示。

图3中，核心翻译器称为BR，对于IPv6为路由器，对于IPv4为可以复用IPv4地址的IPv4/IPv6翻译器。第二次翻译在家庭网关CE上进行，CE对于IPv6为路由器，对于IPv4为IPv4/IPv6翻译器，并且根据下述端口映射算法对于传输层的端口进行映射。IPv6接入网部署认证和IPv6前缀分配设备AAA数据库和DHCPv6服务器。IPv6接入网上可以部署使用可译地址的纯IPv6服务器，通过CE或BR的一次翻译能够对于用户的纯IPv4终端和IPv4互联网上的用户提供服务。IPv6接入网的用户设备接到家庭网关上，可以是纯IPv4终端设备，它通过CE一次翻译访问网内纯IPv6服务器的信息资源，同时它通过CE和BR双重翻译访问IPv4互联网上的信息资源，并与其他用户互访。该用户设备还可以是IPv4/IPv6双栈终端设备，直接访问网内和IPv6互联网上的信息资源，并通过CE和BR双重翻译访问IPv4互联网上的信息资源，也能与其他用户互访。该用户设备也可以是纯IPv6终端设备，直接访问网内和IPv6互联网上的信息资源，通过BR一次翻译访问IPv4互联网上的信息资源，并与其他用户互访。

2.2 封装模式的应用场景

封装模式（MAP-E）的应用场景如图4所示。

图4中，核心封装/解封装器称为BR，对于IPv6为IPv6路由器，对于IPv4为可以复用IPv4地址的IPv4 over IPv6封装/解封装器。家庭网关CE对于IPv6为路由器，对于IPv4为IPv4 over IPv6封装/解封装器，并且根据下述端口映射算法对于传输层的端口进行映射。IPv6接入网部署认证和IPv6前缀分配设备AAA数据库和DHCPv6服务器。IPv6接入网的用户设备接到家庭网关上，可以是纯IPv4终端设备，它通过CE和BR封装/解封装访问IPv4互联网上的信息资源，并与其他用户互访；该用户设备还可以是IPv4/IPv6双栈终端设备，直接访问网内和IPv6互联网上的信息资源，并过CE和BR封装/解封装访问IPv4互联网上的信息资源，也能与其他用户互访。值得指出的是，封装模式MAP-E无法支持在IPv6接入网内部署纯IPv6服务器，也不支持可以与IPv4互联网互联互通的纯IPv6终端设备。

2.3 端口映射

MAP的核心技术之一是无状态地址和端口映射算法，其思想是利用16位的传输层（传输控制协议（TCP）、数据报协议（UDP））端口对于IPv4地址进行扩展。不复用IPv4地址时，一个终端设备可用的并发TCP或UDP的端口数为65 536；如复用比为16，则一个终端可用的并发TCP或UDP的端口数为4 096；如复用比为128，则一个终端可用的并发TCP或UDP的端口数为512。根据统计，一个普通终端的并发TCP或UDP的端口数为有限的，因此可以利用无状态地址和端口映射算法高效率地复用公有IPv4地址资源。在使用无状态地址和端口映射算法时，需要给每一个终端定义一个端口标识集（PSID），端口标识集和可用端口的映射关系由扩展的模算法来决定。

扩展的模算法的定义为：

（1）给定PSID，该端系统可以使用的传输层端口P为：P =R×M×j +M×K+i，其中R为复用比，M为连续端口数，i和j为整数变量。

（2）给定传输层端口P，该端系统的PSID为：P = floor（P /M）%R，其中floor为只舍不入的取整算法，%为常规定义的模运算符。

扩展的模算法是一个适应性很广的算法，即可以使持有不同PSID终端所使用的传输层端口在整个端口空间均匀分布，也可以按块分布，还可以制订每一块包含的连续端口数量。此外，扩展的模算法还可以支持类似与无分类地址域间路由（CIDR）类似的地址聚类，即对应于特定的PSID，可以定义PSID长度，对于可用端口进行聚类使用。

通过扩展的模算法，在给定复用比、连续端口数量和端口聚类长度的条件下，可以通过PSID的值计算出特定终端可以使用的所有的TCP或UDP端口；也可以对于任意给定端口计算出对应的PSID，实现端系统的无状态公有IPv4地址复用，因而可以极大地减小管理开销，并极大地提高安全性和可溯源性。由于ICMP和ICMPv6没有源和目标端口的域，只有标识域（ID），因此要对标识域ID作扩展的模算法映射。

2.4 地址格式

MAP的地址格式是RFC6052的扩展，如图5所示。

与RFC6052的区别主要有：

（1）MAP的地址格式是RFC6052当Prefix长度为64的一个特例，其Prefix里包含IPv6 Prefix、EA-bits（由IPv4子网标识和PSID组成，用于唯一标识不同的用户）和Subnet-id（用于标识一个用户使用的大于等于/64的IPv6子网）。

（2）在MAP中Suffix不为0，而是嵌入了PSID。

（3）MAP对于转换地址和可译地址使用不同的Prefix，以解决为终端用户分配前缀，而不是响应单个地址的要求。

利用EA-bits可以为每一个家庭网关CE分配唯一的Prefix，不使用EA-bits，而为每个CE分配不同的Prefix也可以达到同样的目的。采用EA-bits的好处是可以进行地址聚类，可扩展性好；不采用EA-bits的好处是IPv6前缀与IPv4地址独立。这两种方法各有优缺点，可以根据不同需要进行选择。

2.5 统一双重翻译和封装模式的机制

无状态双重IPv4/IPv6翻译可以支持纯IPv4应用程序（如Skype），同时对于嵌入IP地址的应用程序（如Ftp）也不需要IPv4/IPv6之间的应用层网关（ALG），此外双重翻译不需要DNS64和DNS46。无状态双重翻译可以看成是具有头压缩功能的、无状态IPv4 over IPv6的封装技术。无状态双重翻译技术（MAP-T）和无状态封装技术（MAP-E）采用同样扩展的模算法和同样的地址格式（在封装模式下BR地址可以蜕化为单个地址），因此具有众多的相似性，唯一的不同是数据流处理模式。在双重翻译模式（MAP-T）下数据流的处理依据为翻译，由RFC6145定义，在封装模式（MAP-E）下数据流的处理为数据封装，由RFC2473定义[13]。

MAP-T模式的优点是可以蜕化为一次翻译，有利于过渡到纯IPv6网络，但仍然保持与IPv4互联网的互联互通。同时，在IPv6接入网内的IPv6数据报文没有封装的数据结构，可以使用IPv6路由器上的所有网络层和传输层的管理和控制功能，而MAP-E必须对于数据报文进行解封装，才能进行管理和控制。MAP-E模式的优点是可以完全保持IPv4报文承载的所有信息，同时不需要对传输层的校验和进行修改。由于RFC2473定义的封装模式与传输层的TCP、UDP均由IPv6头结构的下一个头定义，因此，只有从IPv4到IPv6的处理需要定义采用翻译模式还是封装模式，从IPv6到IPv4的处理可以根据下一个头自动适应性完成翻译或封装模式的选择。因此，MAP-T和MAP-E可以根据需求灵活配置，其分析参见MAP测试文档[14]。

2.6 统一无状态/用户状态/有状态

无状态是指IPv4/IPv6地址和传输层端口之间的映射关系完全由算法决定，设备不需要维护映射状态表。有状态是指IPv4/IPv6地址和传输层端口之间的映射关系根据会话的5元组动态生成，设备需要维护动态生成的映射状态表。用户状态是指IPv4/IPv6地址和传输层端口之间的映射关系对于各个用户定义，设备只需要维护用户映射状态表。无状态翻译技术不仅可以与无状态封装技术统一起来，也可以与有状态的翻译技术NAT64和有状态的隧道技术Dual-stack Lite[15]统一起来。因此MAP-T/MAP-E家庭网关CE，不经任何修改就可以与有状态翻译器NAT64或Dual-stack Lite的AFTR完成有状态双重翻译或有状态隧道的功能。由于无状态和有状态是两个极端的情况，MAP-T/MAP-E家庭网关CE也可以不经任何修改支持任何用户状态的场景。

3 过渡路线图

虽然IPv4地址已经分配完毕，但全世界IPv6的普及率仍然非常低。为了保证全球互联网的健康和可持续发展，必须制订正确的过渡路线图。10年前IETF制订的“以双栈为主，辅之以隧道，在没有其他选择时用翻译”的策略值得反思，理由为：

（1）这一政策在过去10余年里并没有完成从IPv4到IPv6的过渡。

（2）对于中国这样的国家，已经没有更多的IPv4公有地址实施双栈，而通过NAT44利用私有地址实施双栈并不能鼓励IPv6的过渡。

随着无状态翻译技术（IVI）和无状态双重翻译技术（MAP）的成熟，我们建议应建设纯IPv6网络，实施“以翻译技术为主，辅之以封装，在没有其他选择时用双栈”的策略。具体技术方案为：

（1）新建纯IPv6网络，当通信的对端也为IPv6是，采用IPv6通信。

（2）当通信的对端为IPv4是，优先采用一次无状态IPv4/IPv6翻译技术进行通信。

（3）当应用程序不支持IPv6，或应用程序嵌入IPv4地址时，采用无状态双重IPv4/IPv6翻译技术进行通信。

（4）当需要保持IPv4报文所有的信息，或处理传输层加密的报文，采用封装技术进行通信。

（5）在过渡的中后期，双重翻译将无缝地退化成一次翻译，最终关闭一次翻译器，进入纯IPv6时代。

采用以上建议的过渡线路图，可以使我们自己的网络率先过渡到IPv6，并高效地利用公有IPv4地址资源与IPv4互联网互联互通，从而在IPv4到IPv6的过渡过程中保持主动。这一技术方案完全符合中国发展下一代互联网的路线图和时间表，即“在2011—2015年的过渡阶段，政府引导全社会向IPv6过渡，IPv4与IPv6共存，新建网络必须为IPv6并实现与IPv4的互通”。目前无状态IPv4/IPv6翻译技术（IVI）已经5个IETF的RFC标准，MAP技术已经形成4个IETF工作组草案。IVI技术已有思科、中兴通讯、华为等设备厂家的产品支持，并在CNGi-CERNET2上正常运行2年以上。MAP技术已有思科等设备厂家的产品正式，得到意大利电信、日本软银、德国电信、美国Charter等多家国际运营商的支持和关注，产业链正在逐步形成。作为唯一能够使IPv4和IPv6互联互通的无状态翻译技术和双重翻译技术IVI/MAP，预计在近几年会得到大发展。

参考文献

[1] NORDMARK E， GILLIGAN R. Basic transition mechanisms for IPv6 hosts and routers [S]. RFC 4213. 2005.

[2] BAKER F， LI X， BAO C， et al. Framework for IPv4/IPv6 Translation [S]. RF C6144. 2011.

[3] BAO C， HUITEMA C， BAGNULO M， et al. IPv6 addressing of IPv4/IPv6 translators [S]. RFC 6052. 2010.

[4] BAGNULO M， SULLIVAN A， MATTHEWS P， et al. DNS64： DNS extensions for network address translation from IPv6 clients to IPv4 servers [S]. RFC 6147. 2011.

[5] LI X， BAO C， CHEN M， et al. The CERNET IVI translation design and deployment for the IPv4/IPv6 coexistence and transition [S]. RFC 6219. 2011.

[6] LI X， BAO C， BAKER F. IP/ICMP translation algorithm [S]. RFC 6145. 2011

[7] LI X， BAO C， WING D， et al. Stateless source address mapping for ICMPv6 packets [S]. RFC 6791. 2012.

[8] BAGNULO M， MATTHEWS P， VAN BEIJNUM I. Stateful NAT64： Network address and protocol translation from IPv6 clients to IPv4 servers [S]. RFC 6146. 2011.

[9] LI X， BAO C， DEC W， et al. Mapping of address and port using translation （MAP-T） [R]. draft-ietf-softwire-map-t-00. 2012.

[10] TROAN O， DEC W， LI X， et al. Mapping of address and port with encapsulation （MAP） [R]. draft-ietf-softwire-map-02. 2012.

[11] MRUGALSKI T， TROAN O， BAO C， et al. DHCPv6 options for mapping of address and port [R]. draft-ietf-softwire-map-dhcp-01. 2012.

[12] SUN Q， CHEN M， CHEN G， et al. Mapping of address and port （MAP） -- Deployment considerations [R]. draft-ietf-softwire-map-deployment-00. 2012.

[13] CONTA A， DEERING S. Generic packet tunneling in IPv6 specification [S]. RFC 2473. 1998.

[14] LI X， BAO C， HAN G， et al. MAP Testing Results [R]. draft-xli-softwire-map-testing-00. 2012.

[15] DURAND A， DROMS R， WOODYATT J， et al. Dual-stack lite broadband deployments following IPv4 exhaustion [S] .RFC 6333. 2011.