PNAT——面向移动互联网的双重翻译过渡技术
开篇：润墨网以专业的文秘视角，为您筛选了一篇PNAT——面向移动互联网的双重翻译过渡技术范文，如需获取更多写作素材，在线客服老师一对一协助。欢迎您的阅读与分享！
摘要：基于中国移动提出的双重翻译过渡技术——pnat，对解析层面的3种双重翻译技术：BIH、464xlat、4rd的特点以及各技术间的共存互补关系进行了深入探讨。双重翻译技术能使得现阶段网络中基于IPv4的用户和应用无需修改就能运行在IPv6网络里，从而提高内容提供商、业务提供商对IPv6的支持力度；双重翻译技术能使得业务流量被主动引导到IPv6网中，从而促进网络运营设施在短时间过渡到IPv6。
关键词： IPv6过渡技术；翻译；BIH技术；464xlat技术
Abstract： In this paper， we propose a double-translation transition technology called PNAT. We describe three kinds of double-translation technologies at the analytic level— BIH， 464xlat and 4rd— and the way in which they complement each other. Double-translation allows numerous IPv4 applications to be supported in IPv6 networks without any modifications being needed. It allows content and service providers to be supported on IPv6 networks. Traffic can be steered to IPv6， which allows prompt transitioning from IPv4 to IPv6.
Key words： IPv6 transition technology； translation； BIH technology； 464xlat technology
随着IPv6运营实践日益广泛，取得的经验证明IPv6新技术部署需要对现有IPv4应用以及用户有良好的后向兼容性，否则IPv6部署将会受到过渡初期业务、应用的桎梏。比如目前主流应用，Skype等即时通信软件都不支持IPv6；APP Store上已有超过50万余种的应用，升级这些应用来支持IPv6更是步履维艰。面对现状，一种应用/用户无感知、透明的IPv6过渡技术可从根本上克服IPv6应用的问题，从而吸引产业链等众多环节来加速IPv6部署进程。两次网络地址翻译（PNAT）技术正是在这种背景下由中国移动提出的旨在进行IPv6快速部署的一种过渡技术。
1 IPv6推动难点和PNAT
过渡理念
IPv6技术最大优势是用来解决网络运营商所面临的IPv4地址紧缺的问题。除此之外，IPv6并没有比IPv4带来更明显的优势。虽然IPv4的设计基于20世纪70年代中期的技术水平，但目前互联网取得的巨大成功已经证明了IPv4的设计是非常成功的。IPv6的设计一方面最大限度地保留了IPv4的诸多优点，另一方面试图在服务质量、安全和移动性上进行突破。但实践证明IPv6相比IPv4并没有本质提升。缺乏杀手级应用的IPv6并不能带来新的商业模式，因此IPv6部署缺乏强有力的推动力。
此外，发展IPv6涉及到产业链的多个环节，改造难度大。由于IPv4地址和IPv6地址格式有很大的不同，端到端系统（包括终端、接入网、承载网、业务网、应用、网管等）都需要做出调整和升级。这其中涉及到通信产业链的各个层面、各个环节，是一个系统级的统筹工程。终端和业务应用始终是IPv6推动过程中的薄弱环节。终端系统和芯片发展的滞后使IPv6无法真正落实到实际用户；大量业务不支持IPv6又导致网络过渡过程因缺乏内容源而滞缓。在这种环境下要发展IPv6、加速IPv6过渡进程需要在IPv6过渡理念上进行突破。
网络问题终究要靠网络运营商自身来解决。发挥网络运营商对网络部署把控的天然优势，利用网络新技术可主动加速IPv6过渡进程。采用接入IPv6化的思路，能够对产业链其他环节起到带动、示范作用，最终实现IPv6在各个层面的突破和成熟。随着运营商定制手机、家庭网关等用户侧设备的增加，将为PNAT过渡策略营造了良好的发展环境。
具体而言，采用PNAT的过渡理念包括两个方面：其一，使得现阶段网络中IPv4应用程序和用户透明运行在IPv6网络里，降低推动内容提供商、业务提供商支持IPv6的阻力；其二，将业务流量引导到IPv6网中，这种流量引导会促进网络运营在短时间过渡到IPv6。
基于以上考虑，PNAT提出了用户侧翻译联合网络侧翻译的双重翻译架构和部署理念。首先，采用翻译技术保证了数据传输的效率，相比隧道过渡技术，不引入额外的传输负荷，适合移动网应用和部署；其次，用户侧翻译使得用户终端可以在IPv6单栈接入情况下，兼容所有IPv4业务，从而使IPv6用户得到在IPv4网络中同样丰富的业务选择和体验；最后，网络侧NAT64翻译又使得IPv4业务源在IPv6过渡早期能够快速提供IPv6接入服务，实现了IPv4、IPv6的自由互通。
2 基于双重翻译的技术方案
PNAT是联合用户侧翻译和网络侧翻译的“两次翻译”方案，也是中国移动在IETF首次提出的一种IPv6过渡理念[1]。为了推广该项技术，PNAT力争走自主知识产权和国际标准化并重的道路。在过去的3年中，PNAT技术在IETF和3GPP开展了一系列标准化工作，目前已取得一定进展，形成了较为完善的方案体系。
2.1 BIH方案
BIH[2]是一种基于主机IPv4/IPv6有状态翻译技术，这种机制可以支持IPv4的应用程序和IPv6业务间的互通，从而在IPv6的环境中全面实现对IPv4应用兼容。BIH功能模块如图1所示。
BIH主机翻译模块包括两种模式：Socket应用编程接口（API）翻译和包头翻译。Socket翻译主要是在Socket API层面对IPv4和IPv6的Socket进行翻译。包头翻译则是在IPv4传输控制协议/网间协议（TCP/IP）协议栈生成IPv4报文后再对包头进行翻译。这两种工作模式的区别主要在于进行主机翻译的位置不同。Socket翻译在协议栈与应用程序的接口层面进行翻译，BIH执行在API接口层；在包头翻译方式中，BIH执行在网络层时，IPv4包被拦截并转换成IPv6，并使用RFC6145[3]定义的算法来完成IP转换。在具体实施中可根据不同的功能要求，分别选择包头和Socket翻译方式。
除了翻译功能外，BIH还具备域名服务器（DNS）解析扩展功能，负责将应用程序发出的DNS解析请求转换成为A/AAAA两个请求，并根据网络DNS回复类型来构建主机映射表项，配合翻译功能最终完成IPv4-IPv6翻译。
BIH实现了移动终端上有状态的NAT46翻译，目前在IETF进行了标准化，已正式为RFC6535。当网络不进行DNSsec部署时，终端可以通过DNS64获得远端IPv4业务的合成IPv6回复，联合网络侧有状态NAT64/DNS64执行两次有状态翻译功能。
2.2 464xlat方案
464xlat[4]方案实现了IPv6网络中中国移动产品——MIFI终端的接入，即移动终端作为无线路由器来支持多个IPv4用户接入，将IPv4数据包翻译成为IPv6在网络上发送。464xlat的部署场景如图2所示。
464xlat分为了用户侧翻译（CLAT）和网络侧翻译（PLAT）两部分。CLAT部署基于RFC6145的无状态NAT46翻译过程，PLAT采用标准的有状态NAT64[5]技术。
464xlat的CLAT功能可以部署于MIFI，也可以安装于移动终端充当无线路由器功能。在功能部署上，464xlat能够实现众多IPv4终端的接入，无感知地将IPv4用户数据迁移到IPv6网络中。为了实现以上通信过程，在464xlat CLAT包括无线路由网关功能、地址翻译器、NAT44、DNS等。
464xlat具体实施过程中无线路由网关通过Wi-Fi信号向下为多个终端提供接入服务，完成IPv4私有地址的分配和上传数据的接收处理。所连接终端将以CLAT地址为默认网关和DNS服务器。CLAT上的DNS功能将截获IPv4主机发出的DNS解析请求，并实现该解析请求在IPv6网中DNS服务器的查询，从而能够避免对DNS数据包的两次翻译。464xlat中由于业务仍处于IPv4，因此相应的IPv4 DNS回复将通过CLAT DNS后返回各IPv4主机。IPv4用户获得DNS回复后将发起IPv4业务数据请求，464xlat CLAT将对接收的IPv4数据包执行无状态NAT46翻译，完成业务流在IPv6网络中的传递，配合网络侧NAT64功能来实现和远端IPv4业务的互通。
464xlat也可以联合BIH来完成IPv4用户向IPv6业务访问，通过IPv6接入网络为IPv4用户提供完整的IPv4/IPv6业务访问能力。
2.3 4rd方案
4rd[6]技术采用和464xlat相同的两次翻译网络架构，力求保证在两次翻译过程中信息零损失。联合网络无状态NAT64翻译处理，4rd实现了两次无状态的IPv4/IPv6翻译。
4rd借鉴了A+P的思想，在多个用户间共享一个IPv4地址，不同用户仅使用规定的端口号来进行通信。这种地址共享技术既能够满足NAT64无状态翻译中IPv6嵌入公有IPv4地址的要求，又能够在公有地址紧缺条件下，保证两次无状态翻译的进行。4rd具备如下特点：
（1）网络侧无状态翻译
4rd中用户侧的无状态NAT46翻译需要根据网络预先下发配置参数以及的IPv6前缀来实施无状态算法，通过计算得到共享IPv4地址信息。数据转发时，翻译模块也需要根据共享IPv4地址和端口信息来还原对应的IPv6信息，从而无需在用户侧构建翻译映射表即可完成IPv4到IPv6的转换。这种两次无状态翻译技术能够有助于克服网络侧单点失效问题，并能够降低冗余备份、Log处理等功能实施的复杂性。
（2）两次翻译过程中信息无丢失
为了保证对IPv4数据包中DF标志位、生存时间（TTL）、服务类型（TOS）等字段的无损传输，4rd提出了扩展IPv6分片头ID字段思想，能够保证经过两次翻译处理后，IPv4数据包头中各字段信息的无损还原。
（3）网络翻译功能简化
4rd提出设置校验和中立比特位来避免网络侧网关翻译过程中校验和的重新计算。这样考虑不仅降低了网关处理负荷，而且有利于网关对新型传输协议的扩展支持。此外，4rd也提出设置V比特的标识位，使得数据包更易于被网络管理设备识别和监管。
2.4 3种双重翻译技术的互补与共存
根据网络设备能力以及部署要求，以上3种双重翻译解决方案可以共存互补，实现IPv4用户无感知的IPv6过渡体验。
基于双重翻译的方案体系如图3所示。双重翻译架构下，网络侧部署NAT64网关，根据翻译设备的不同部署形式，终端侧可以采用相应翻译方案来进行配合。具体来讲，将出现如下3种情况。
（1）网络侧同时部署有状态NAT64和DNS64设备时，经过DNS64处理，IPv4通信对端将通过IPv6域名形式来表示。终端侧采用BIH翻译功能来实现IPv4/IPv6互通。
（2）网络侧仅部署有状态NAT64设备时，IPv4通信对端仍呈现IPv4域名形式。则翻译方案采用464xlat，在终端侧执行无状态的IPv4-IPv6翻译过程。
（3）网络侧仅部署无状态NAT64设备时，则采用4rd两次翻译方案，实现内嵌IPv4共有地址在多个终端间的共享复用。
各种技术在相应场景下的功能实施应用范围如表1所示。
3 PNAT产品化和开源开放
经过多年的技术发展和积累，PNAT不仅在标准化方面取得了收获，而且也成功实现了从理念创新向产品落地的稳步发展[7-17]。BIH模块功能已被成功移植到移动终端、家庭网关、桌面操作系统软件等三大类、多平台的各项产品中，并逐步走向现网试点和应用。
T-mobile USA公司也针对464xlat技术推出了手机终端软件插件，实施了3G现网测试及试点，避免了双栈3G终端在发起双倍PDP激活时，增加网络侧设备投入的问题，取得了良好的效果。
PNAT产品化也在走开源、开放的道路，BIH源代码于2011年正式宣布开源，并贡献给了国际开源社区——Linux Foundation，开源渠道的拓展将更加扩大PNAT/BIH产品应用的受众面，代码成熟度也将在无数开源开发者共同努力下进一步提升。
下一步PNAT会将继续推进各类原型的产品化，真正地进入市场应用。同时还将拓展PNAT产品使用的新场景，比如LTE阶段，用户就可以利用高速无线上行速率方便使用MIFI应用，利用一个LTE的IPv6终端，带动用户多个终端设备过渡到IPv6时代。
4 PNAT技术展望
PNAT克服了IPv4业务升级改造难、产业推动阻力大、网络运营复杂等问题，结合了移动互联网大力发展的趋势和移动用户永远在线的需求，开辟了一条移动网络向IPv6过渡的创新之路，并以此来推动IPv6技术在全世界范围内的部署和应用。PNAT技术推广将致力以下几个方面。
（1）引导流量向IPv6网络迁移，从而提前IPv6网络部署、加速IPv6过渡。随着PNAT部署扩大，网络中IPv6流量将得以增长，IPv6影响将得以扩大。这种积极因素将带动整条IPv6产业链的发展和成熟。
（2）实现真正IPv6网络的部署。在IPv6单栈网络环境下，将支持众多IPv4应用，做到IPv6过渡对IPv4应用的无感知。
（3）借鉴移动网络2G到3G成功演进经验，确保网络平滑过渡。IPv6过渡应该学习移动网络从2G到3G的平滑升级以及2G/3G共存理念。从2G到3G升级看IPv4到Pv6演进，网络将是IPv4和IPv6两种技术长期共存的网络，因此应在发展IPv6的同时兼容IPv4，以保障和提高用户在IPv6网络中的业务体验。
（4）PNAT也是TD-SCDMA 3G网络部署IPv6单栈的一个很好的选择。目前双栈部署实践中，终端需要同时支持两套协议栈（也就是IPv4和IPv6）处理，这在终端实现复杂度和能耗方面往往不是最优的，而且网络侧也需要相应提供两套运维系统，因此IPv6单栈在这种考虑下是比较好的部署选择。PNAT能很好满足IPv6单栈网络中兼容众多IPv4应用的需求，是一个合适的选择。
参考文献
[1] HUANG B， DENG H. Prefix NAT： Host based IPv6 translation [S]. draft-huang-pnat-host-ipv6-00. 2009.
[2] HUANG B， DENG H， SAVOLAINEN T. Dual-stack hosts using "bump-in-the-host" （BIH） [S]. RFC 6535. 2012.
[3] LI X， BAKER F， BAO C. IP/ICMP translation algorithm [S]. RFC 6145. 2011.
[4] MAWATARI M， KAWASHIMA M， BYRNE C. 464XLAT： Combination of stateful and stateless translation [R]. draft-ietf-v6ops-464xlat-08. 2012.
[5] MATTHEWS P， BEIJNUM I， BAGNULO M. Stateful NAT64： Network address and protocol translation from IPv6 clients to IPv4 servers [S]. RFC 6146. 2011.
[6] DESPRES R， PENNO R， LEE Y， et al. IPv4 residual deployment via IPv6 -- A stateless solution （4rd） [R]. draft-ietf-softwire-4rd-03. 2012.
[7] ARKKO J， BAKER F. Guidelines for using IPv6 transition mechanisms during IPv6 deployment [S]. RFC 6180. 2011.
[8] DURAND A， DROMS R， LEE Y， et al. Dual-stack lite broadband deployments following IPv4 exhaustion [S]. RFC 6333. 2011.
[9] DESPRES R. IPv6 rapid deployment on IPv4 infrastructures （6rd） [S]. RFC 5569. 2010.
[10] TSIRTSIS G. Network address translation -- Protocol translation （NAT-PT） [S]. RFC 2766. 2000.
[11] MATTHEWS P， SULLIVAN A， BEIJNUM I， et al. DNS64： DNS extensions for network address translation from IPv6 clients to IPv4 servers [S]. RFC 6147. 2011.
[12] IANA Considerations and IETF protocol usage for IEEE 802 parameters [S]. RFC 5342. 2008.
[13] BOUCADAIR M， MATSUSHIMA S， LEE Y， et al. Motivations for Carrier-side stateless IPv4 over IPv6 migration solutions [R]. [2012-12-22]. draft-ietf-softwire-stateless-4v6-motivation-04. 2012.
[14] BUSH R. The address plus port （A+P） approach to the IPv4 address shortage [S]. RFC 6346. 2011.
[15] BAKER F， BLACK D， NICHOLS K， et al. Definition of the differentiated services field （DS field） in the IPv4 and IPv6 headers [S]. RFC 2474. 1998.
[16] RAMAKRISHNAN K， FLOYD S， BLACK D. The addition of explicit congestion notification （ECN） to IP [S]. RFC 3168. 2001.
[17] BAO C， HUITEMA C， BAGNULO， et al. IPv6 addressing of IPv4/IPv6 translators [S]. RFC 6052. 2010.
作者简介
陈刚，北京邮电大学博士毕业；工作于中国移动研究院，从事IPv6、移动网络管理、IP承载网络技术等方面的研发工作；已发表学术论文20余篇；作为3GPP的报告人主持3GPP规范10篇。
邓辉，清华大学博士毕业；工作于中国移动研究院，从事移动互联网基础设施演进相关的研发工作；已发表学术论文40余篇。
段晓东，中国移动研究院网络技术研究所所长，从事IP承载网络、下一代互联网、数据业务管理及移动互联网的研发工作。