4.4 我国过渡技术的研究进展
在IPv4时代，我国在1994年才接入互联网，比美国晚了将近30年，这也导致了美国等先接入国际互联网的国家主导了IPv4资源的分配。根据中国互联网信息中心在2011年11月测算的数据，我国网民总数已经达到5.05亿，但我国目前只有约3.3亿的IPv4地址，因此发展下一代互联网更加紧迫。“十二五”时期是我国工业转型升级的攻坚时期，信息化作为科技创新、自主创新的重要组成部分，在推进工业转型升级的过程中具有突出的作用。国务院总理温家宝在2011年12月主持召开的国务院常务会议上提出了加快发展我国下一代互联网产业。会议明确了今后一个时期我国发展下一代互联网的路线图和主要目标。2013年年底前，开展IPv6网络小规模商用试点，形成成熟的商业模式和技术演进路线；2014—2015年，开展大规模部署和商用，实现IPv4与IPv6主流业务互通。由于IPv4协议和IPv6协议的语法、语义和时序不同，不能兼容，IPv4互联网向IPv6互联网过渡已经成为世界性技术难题。
为解决过渡时期IPv4与IPv6互通互联这一技术难题，我国各大运营商、厂商和高校研究机构也在积极联合制定过渡时期的策略。中国的IPv6标准化工作在2001年全面启动，由中国通信标准化协会具体负责，其中的IP与多媒体工作委员会网络协议系统与设备工作组主要进行过渡相关标准的制定，目前已经完成和正在制定的过渡类标准有十余项，涉及与国际上隧道技术和翻译技术对应的相关行业标准等。同时，我国高校、运营商和设备制造商等积极参与过渡技术国际标准的制定，取得了一些成果。
针对IPv6过渡中存在的根本问题和现有技术方案的不足，在IPv6过渡翻译技术方面，清华大学在国际上首次提出“IVI：无状态IPv4/IPv6翻译技术”，参与IETF Behave和V6OPS工作组的工作，已提交RFC草案12项，其中5项已正式发布为RFC 6052、RFC 6144、RFC 6145、RFC 6147、RFC 6219、在IPv6过渡隧道技术方面，清华大学在国际上首次提出了“IPv4 over IPv6网状体系结构过渡技术”，推动IETF成立了专门工作组Softwire，已提交标准草案7项，其中3项已经正式发布为RFC 4925、RFC 5565、RFC 5747。并且在100所学校的校园网进行了实现。
随着我国下一代互联网发展，各大运营商的IPv4地址逐渐耗尽，IPv6过渡显得尤为重要，为满足自身的需要及在下一代互联网中抢占先机，三大电信运营企业积极向IPv6过渡。中国电信从2001年就开始了IPv6的研究和推进，在对主流过渡技术多角度对比分析的基础上，针对可运营的过渡部署需求，完善相关NAT444、DS-Lite和双栈等技术规范和设备规范要求，制定可运营、可管理的整体技术方案。推动Smart6业务迁移系统的开发与部署，实现IPv4资源与IPv6网络互通；与清华大学联合研究LAFT 4over6，现已经成为IEFT主流的新型过渡技术之一。
其中DS-Lite和双栈已经介绍过，在此不再赘述。NAT444方案是由日本NTT提出的，主要思想是分成两级NAT：CPE一级NAT44，BAS一级NAT44。从而形成了三块地址空间，即用户侧私有地址、运营商私有地址和公网地址。可以看出它是一种在运营商网络中大规模使用NAT技术的应用场景，并没有引入新的技术，因此其优点在于现有设备和技术支持较为成熟，容易实现，可以提高IPv4地址的复用率，缓解地址枯竭问题。其缺点在于运营商需要维护大量session状态，大规模NAT的引入破坏了端到端的透明性，更为重要的是该方案并不能实现IPv4与IPv6互通，只能暂时缓解IPv4地址紧缺的状态，并不能解决根本问题。
针对内容提供商升级缓慢的现状，中国电信自主研发了面向ICP网站的IPv6平滑迁移平台Smart6。该方案将协议翻译技术应用到内容提供商ICP网站侧，实现了IPv4资源和IPv6网络的互通。由于ICP网站的服务器通常部署在IDC机房中，因此Smart6的协议翻译功能部署在IDC的出口处，这样也可同时为多个ICP网站提供迁移服务。为了支持IPv6用户对IDC内部ICP网站的访问，Smart6利用协议翻译技术将IPv6的访问请求报文在IDC入口处转换成IPv4报文，从而使IPv6用户请求以IPv4形式去访问IPv4内容资源。在进入Smart6前，IPv6请求包中的源地址为用户IPv6地址，该地址通过地址映射方式转换为一个对应的私网IPv4地址，并生成新的IPv4访问请求数据包。由于用户的IPv6地址被映射为私有IPv4地址，因此该数据访问过程不占用网络运营商的公有IPv4地址资源，实现了真正意义上的IPv6数据传输。在经过地址转换后，新生成的IPv4报文在IDC内部直接去访问IPv4内容资源。Smart6平台技术实现难度较低，可快速部署和实施。在对特定ICP网站提供迁移服务时，Smart6对ICP网站自身系统并没有进行改动，大大降低了ICP网站提供IPv6服务的门槛。实现了互联网网站流量从IPv4网络向IPv6网络的迁移，带动了整个IPv6产业的发展。
LAFT 4over6是中国电信和清华大学联合提出的自主知识产权纯IPv6接入过渡技术，与天地互联、雅马哈、华为等合作实现。该技术基于现有技术的优缺点，并结合中国电信的网络业务现状提出。具备轻量级、支持IPv6灵活的地址规划及低成本的特征，符合IPv6网络演进的长期发展，可在DS-Lite/NAT444基础上平滑演进，对于现网的地址规划管理、支撑系统的改造需求一致。另外，LAFT 4over6应用于基于IPv6网络接入的场景，运营商仅为用户分配IPv6地址，并实现对现有IPv4业务应用的支持。
中国移动倡导把IP流量向IPv6牵引的理念，提出了IPv6过渡技术Prefix based NAT（PNAT），采用Bump In Host（BIH）的基于主机翻译实现方式，实现业务流量向IPv6的迁移，PNAT/BIH支持IPv4的应用程序透明地运行在IPv6网络里，同时满足IPv4和IPv6网络间自由通信的能力，并能够联合NAT64功能提升用户IPv6的业务体验。BIH继承和融合了BIS（Bump-In-the-Stack）与BIA（Bump-In-the-API），前者基于网络层IPv4数据包与IPv6数据包之间的转换，后者基于应用层Socket API函数之间的转换。主机的PNAT包括三个模块：扩展的域名解析器（Extension Name Resolver， ENR）、地址映射器（Address Mapper），对应于BIA的函数映射器（Function Mapper）和对应于BIS的翻译器（Translator）。ENR用于处理DNS查询，实现AAAA记录与A记录之间的转换，类似于DNS64实现的功能。地址映射器用于维护IPv4地址池，记录IPv6地址与IPv4地址之间的映射表。函数映射器在主机使用BIA扩展技术时负责在IPv4 Socket API函数与IPv6的Socket API函数之间转换，翻译器在主机使用BIS扩展技术时使用SIIT技术负责IPv4数据包与IPv6数据包之间的转换。
PNAT可以实现在部署IPv6的同时保证传统IPv4应用能照常通信，做到了对应用程序的透明、无感知。它满足多种通信场景，大大降低了IPv6网络的升级带来的对业务的影响和冲击。该方案已被IETF接受为工作组正式标准。
中国联通在过渡技术方面也已经开展了相关的工作，包括对IPv4向IPv6过渡机制的研究、过渡机制的验证。
除了上述三大运营商，还有很多设备生产厂商、运营商、研究机构、ICPs和ISPs等都在为IPv6过渡做努力。华为一直在积极探索IPv6演进方案，基于国内IPv4地址紧缺的情况和全球的最新进展，发布了CGN解决方案，可全面支持各种过渡技术，减少对IPv4地址的需求。此外，华为还全球首发了DS-LITE产品解决方案，为IPv6网络建设提供基础产品和方案的支持。为顺利实施IPv6过渡技术，在标准层面上也做了大量的工作，在IETF、BBF、ITU等国际标准组织的IPv6标准制定进行了大量的投入，并取得了一些的成果。中兴通讯参与了国内运营商向IPv6过渡的相关工作，在向IPv6过渡过程中，重点推进DS-Lite技术。参与了中国电信的DS-Lite应用和规范的制定和试点及中国移动在很多省份的试点工作。比威网络技术有限公司与清华大学合作研制成功我国第一台IPv6核心路由器，生产了BEOBS系列高性能IPv4/IPv6过渡网关设备，该设备支持IPv4、IPv6、IVI、NAT64和IPv4 over IPv6流量高速转发。支持目前主流的IPv4向IPv6过渡机制，可以广泛应用于IPv4网络和IPv6网络共存的网络环境中。
本章小结
2011年2月，IANA将其最后5个可用的/8 IPv4地址空间分配给了区域Internet注册机构（RIR），至此IPv4地址已经全部分配完。我国互联网的用户已超过5亿，预计在今后的三年到五年中，我国将有超过一亿新互联网用户联网，即有超过一亿的IP地址需求。移动互联网、云计算和物联网的普及和推广则需要更多的IP地址。IPv6协议的提出正是为了解决这些问题，进而取代IPv4。但是，在长期的过渡过程中，大量的IPv4应用业务仍将在较长一段时期内存在并会以缓慢的速度逐步过渡到IPv6。在这个过渡期间，IPv4和IPv6协议的不兼容性使得IPv6的用户无法直接访问IPv4网络上的资源，同时，IPv4用户也无法直接访问IPv6网络上的资源，这就给IPv6网络的进一步部署和应用带来了巨大的困难。扩展互联网地址空间，实现IPv4网络和IPv6网络之间互联互通成为IPv4向IPv6过渡方案中要解决的关键问题。
本章分析了IPv6过渡的基本问题：异构地址穿越和异构地址互联。进一步介绍了隧道技术和翻译技术的基本原理，并介绍了当前主流隧道和翻译机制。总结了这些转换机制的利与弊及每种过渡机制的应用场景。从目前看，世界各国都没有一个明确的可以有效解决过渡问题的方案，我国建设下一代互联网，解决过渡问题没有成熟经验可以借鉴，只能自主创新，寻求适应我国下一代互联网发展的解决方案。
参考文献
[1]韩宝瑜，赵峰.IPv6标准进展[J].电信网技术，2010.
[2]S.I.at University of Southern California，“Internet Protocol， DARPA Internet Program， Protocol Specification，”1981，IETF RFC 791.
[3]G.Huston，“IPv4 Address Report，”Tech.Rep， Sep.2010.[Online].Available：http：//www.potaroo.net/tools/ipv4.
[4]S.Deering and R.Hinden，“Internet Protocol， Version 6（IPv6）Specification，”1998.IETF RFC 2460.
[5]S.Thomson， T.Narten， and T.Jinmei，“IPv6 Stateless Address Autoconfiguration，”2007，IETF RFC 4862.
[6]C.Perkins， D.Johnson， and J.Arkko，“Mobility Support in IPv6，”2011，IETF RFC 6275.
[7]“IPv6 Adoption Monitor，”University of Pennsylvania， Comcastand Tsinghua University， Tech.Rep，2010.[Online].Available：http：//mnlabipv6.seas.upenn.edu/monitor.
[8]B.Carpenter and K.Moore，“Connection of IPv6 Domains via IPv4Clouds，”2001，IETF RFC 3056.
[9]B.Carpenter and C.Jung，“Transmission of IPv6 over IPv4 Domains without Explicit Tunnels，”1999，IETF RFC 2529.
[10]G.Tsirtsis and P.Srisuresh，“Network Address Translation-Protocol Translation（NAT-PT），”2000，IETF RFC 2766.
[11]E.Nordmark，“Stateless IP/ICMP Translation Algorithm（SIIT），”2000，IETF RFC 2765.
[12]K.Tsuchiya， H.Higuchi， and Y.Atarashi，“Dual Stack Hosts using the”Bump-In-the-Stack“Technique（BIS），”2000，IETF RFC 2767.
[13]S.Sen， Y.Jiny， R.A.Guerin， and K.Hosanagar，“Modeling the Dynamics of Network Technology Adoption and the Role of Converters，”IEEE/ACM Transactions on Networking， vol.18，pp.1793-1805，2010.
[14]“IETF Behave WG charter，”http：//datatracker.ietf.org/wg/behave/charter/.
[15]“IETF Softwire WG charter，”http：//datatracker.ietf.org/wg/softwire/charter/.
[16]X.Li， S.Dawkins， D.Ward， and A.Durand，“Softwire Problem Statemen，”2007，IETF RFC 4925.
[17]F.Baker， X.Li， C.Bao， and K.Yin，“Framework for IPv4/IPv6 Translation，”2011，IETF RFC 6144.
[18]X.Li， C.Bao， and F.Baker，“IP/ICMP Translation Algorithm，”2011，IETF RFC 6145.
[19]X.Li， C.Bao， M.Chen， H.Zhang， and J.Wu，“The CERNET IVI Translation Design and Deployment for the IPv4/IPv6 Coexistence and Transition，”2011，IETF RFC 6219.
[20]C.Bao， C.Huitema， M.Bagnulo， M.Boucadair， and X.Li，“IPv6Addressing of IPv4/IPv6 Translators，”2010，IETF RFC 6052.
[21]M.Bagnulo， A.Sullivan， P.Matthews， and I.van Beijnum，“DNS64：DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers，”2011，IETF RFC 6147.
[22]X.Li， C.Bao， and H.Zhang，“Address-sharing stateless double IVI，”2011，IETF draft.
[23]C.Aoun and E.Davies，“Reasons to Move the Network Address Translator-Protocol Translator（NAT-PT）to Historic Status，”2007，IETF RFC 4966.
[24]M.Bagnulo， P.Matthews， and I.van Beijnum，“Stateful NAT64：Network Address and Protocol Translation from IPv6 Clients to IPv4Servers，”2011，IETF RFC 6146.
[25]S.Lee， M.-K.Shin， Y.-J.Kim， E.Nordmark， and A.Durand，“Dual Stack Hosts Using”Bump-in-the-API（BIA），2002，IETF RFC 3338.
[26]D.Wing， S.Cheshire， M.Boucadair， R.Penno， and F.Dupont，“Port Control Protocol（PCP），”2011，IETF draft.
[27]P.Wu， Y.Cui， M.Xu， J.Wu， X.Li， C.Metz， and S.Wang.
[28]P.Wu， Y.Cui， M.Xu， J.Dong， and C.Metz，“Flexible Integrationof Tunneling and Translation for IPv6 Transition，”Networking Science， vol.1，pp.23-33，2012.
[29]C.Perkins，“IP Encapsulation within IP，”1996，IETF RFC 2003.
[30]S.Hanks， T.Li， D.Farinacci， and P.Traina，“Generic Routing Encap-sulation（GRE），”1994，IETF RFC 1701.
[31]D.Farinacci， T.Li， S.Hanks， D.Meyer， and P.Traina，“Generic Routing Encapsulation（GRE），”2000，IETF RFC 2784.
[32]J.Lau， M.Townsley， and I.Goyret，“Layer Two Tunneling Protocol-Version 3（L2TPv3），”2005，IETF RFC 3931.
[33]E.Rosen， A.Viswanathan， and R.Callon，“Multiprotocol Label Switching Architecture，”2001，IETF RFC 3031.
[34]E.Rosen， D.Tappan， G.Fedorkow， Y.Rekhter， D.Farinacci.T.Li， and A.Conta，“MPLS Label Stack Encoding，”2001，IETF RFC 3032.
[35]S.Kent and R.Atkinson，“Security Architecture for the Internet Protocol，”1998，IETF RFC 2401.
[36]Y.Cui， J.Wu， X.Li， M.Xu， and C.Metz，“The Transition to IPv6，PartII：The Softwire Mesh Framework Solution，”IEEE Internet Computing， vol.10，pp.76-80，2006.
[37]J.Wu， Y.Cui， C.Metz， and E.Rosen，“Softwire Mesh Framework，”2009，IETFRFC 5565.
[38]J.Wu， Y.Cui， X，Li.and C.Metz，“The Transition to IPv6，Part I：4over6 for the China Education and Research Network，”IEEE Internet Computing， vol.10，pp.80-85，2006.
[39]J.D.Clercq， D.Ooms， S.Prevost， and F， L.Faucheur，“Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers（6PE），”2007，IETF RFC 4798.[40]F.Templin， T.Gleeson， and D.Thaler，“Intra-Site Automatic Tunnel Addressing Protocol（ISATAP），”2008.IETF RFC 5214.
[41]B.Storer， C.Pignataro， M.D.Santos， B.Stevant， L.Toutain， and J.Tremblay，“Softwire Hub and Spoke Deployment Framework，”2009，IETF RFC 5571.
[42]R.Despres，“IPv6 Rapid Deployment on IPv4 Infrastructures（6rd），”2010，IETF RFC 5569.
[43]M.Townsley and O.Troan，“IPv6 Rapid Deployment on IPv4 Infrastructures（6rd），”2010，IETF RFC 5969.
[44]C.Huitema，“Teredo：Tunneling IPv6 over UDP through Network Address Translations （NATs），”2006，IETF RFC 4380.
[45]Durand， R.Droms， J.Woodyatt， and Y.Lee，“Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion，”2011，IETF RFC6333.
[46]Y.Cui， J.Wu， P.Wu， C.Metz， O.Vautrin， and Y.Lee，“Public IPv4 over Access IPv6 Network，”2011，IETF draft.
[47]Y.Cui， J.Wu， P.Wu， Q.Sun， C.Xie， C.Zhou， Y.Lee， and T.Zhou，“Lightweight 4over6 in access network，”2011，IETF draft.
[48]O.Troan and W.Dec and X.Li and C.Bao and Y.Zhai and S.Matsushima andT.Murakami，“Mapping of Address and Port（MAP），”2012，IETF draft.
[49]R.Despres and R.Penno and Y.Lee and G.Chen and S.Jiang，“IPv4 ResidualDeployment via IPv6-a unified Stateless Solution（4rd），”2012，IETF draft.
[50]M.Mawatari and M.Kawashima and C.Byrne，“464XLAT：Combina-tion of Stateful and Stateless Translation，”2012，IETF draft.
