IPv6过渡技术发展历程分析

□TELECOMMUNICATIONS NETWORK TECHNOLOGY

No.6FOCUS ON INNOVATION

1引言

而今在Google 中搜索“IPv6”这个关键词，可以找

到1730万条搜索结果。毫无疑问，自2011年2月3日

IANA （互联网号码资源顶级管理机构）宣布其可分配的IPv4地址资源全部耗尽后，全球CT （电信技术）与

IT 信息技术界已掀起了新一轮关于IPv6的建设浪潮，包括试验、试点、试商用甚至面向公众开放的正式商用。尤其在IP 地址资源和需求矛盾最为突出的中国电信集团、中国移动集团和中国联通集团或已完成或已启动和规划在多个省份开展IPv6试点。百度和腾讯公司也已发布了近两年的IPv6迁移计划。作为IPv6端到端解决方案的领导者和最佳践行者，华为公司全程参与了国内三大运营迄今为止所有的IPv6建设项目，在各类IPv6业务商用部署和各类IPv6过渡技术探索上都积累了丰富而深厚的经验。

笔者有幸参与国内运营商多个省份IPv6相关项目的支撑工作，遭遇客户最常见的问题就是“现有IPv4网络和业务向IPv6过渡的方案是否已成熟”。这个问题似乎很难答复，因为的确在今天，在IETF （互联网相关协议&技术方案权威标准组织）仍然还有很多IPv6过渡技术解决方案在排着长队等待多方评审以完成标准化形成正式的RFC 。而IPv6基础协议本身完成标准化（RFC1883-IPv6Specification ）已是16年前的事情了，为什么这么长时间过去了，IPv4向IPv6怎么过渡还没想明白呢？哪种方式更适合解决哪些问题？如何取舍、如何组合、如何排序、如何部署等？运营商对此仍然面临艰难选择。

实际上我们仔细回顾一下IPv6过渡技术发展的全景历史，并重点关注具体方案在技术设计与应用场

景上的限制，就可以理清回答上述问题的答案脉络。

2IPv6过渡技术发展的全景历史

从基本的

实现机理视角看，IPv6过渡技术通常被分为双栈（Dual

Stack ）、隧道（Tunnel ）和翻译（Translate ）3类。如果将

IPv4比作红色的承载管道，

将IPv6比作蓝色的承载管道，那么3种基本过渡方式的实现原理将如图1所示。

(1)双栈方式

指从用户侧到网络侧同时支持IPv4协议栈和

IPv6协议栈。虽然双栈不能解决IPv4地址短缺的问题，但其毕竟是实施其他两类过渡方式的基础。即无论使用隧道还是翻译，相对的网络设备或终端设备必须支持双栈。在双栈的基础上再考虑如何引入其它技术。

(2)隧道方式

是将一种协议的数据报文（包括报文头部和报文负载）封装在另一种协议的数据报文中（仅作为负载）传输。隧道是连接孤岛的有效方法，类型有很多，包括

6PE/6VPE ，IP-in-IP ，GRE ，L2TP ，6over4，4over6，6to4，ISATAP ，Teredo ，6RD 等。不同类型隧道技术用于不同应用场景。但隧道实施需两端设备良好互通，这是个很

IPv6过渡技术发展历程分析

张伟

华为技术有限公司中国区网络Marketing 部高级营销经理

摘

要回顾了业界既往16年IPv6过渡技术方案的发展历程，对比分析了主流IPv6过渡技

术方案优劣势及商用意义，最后结合国内运营商的实际需求给出了IPv6过渡路线的技术建议。

关键词IPv6IP-in-IP DualStack NAT444DS-Lite NAT64

２８··

《电信网技术》2011年6月第6期聚焦创新

大的问题，目前各厂家产品（无论网络设备—网络设备，还是网络设备—用户终端之间）隧道互通情况大多并不理想。

(3)TCP/IP层翻译技术

统称为NAT，大致分为两类：一是IPv4私有地址到公有地址间的翻译（或称为NAT44），另一类是IPv4地址（私有或公有）与IPv6地址（格式受限或不受限）间的翻译。

从上述技术（包括但不限于）完成标准化的时间看可以分成两个历史阶段：

●1996—2006年

我们称这10年为“春秋”阶段，也可以称为“昨天”。

熟悉中国历史的人都很清楚，中国在春秋初期大小诸侯国有1000余个，经历无数的战争和权谋，消灭与吞并后发展到了战国末期，则只剩下战国七雄——

—齐、楚、燕、韩、赵、魏、秦。笔者认为，IPv6过渡技术过去15年的发展历程与其十分相似。

于IPv6基础协议标准化后次年（1996年）发布的RFC1933-Transition Mechanisms for IPv6Hosts and Routers，即IPv6-in-IPv4手工配置隧道方案，是业界第一个完成标准化的IPv6过渡技术。其原理非常简单，就是把IPv6报文作为IPv4报文承载的一种特定负载（IPv4报头协Protocol字段=41），就跟IPv4承载TCP/UDP（协议字段=6/17）一样。该方案对相关IPv6和IPv4地址没有任何要求，最大局限该类隧道只能用于P-to-P场景且隧道出口必须手工配置（后来的IPv6-in-GRE隧道也有此限制）。正是这种局限，使这种古老的隧道技术一直不温不火，不如后来由微软力推的ISATAP和Teredo方案风行校园。但也正因其简单，使其经受住历史考验成为迄今惟一在跨厂家互通方面表现良好的隧道技术（另一个是6PE/6VPE）。

业界第二个完成标准化的过渡技术是两年后发布的RFC2473-Generic Packet Tunneling in IPv6Specifica-tion，很多教科书称其为4over6技术。笔者却认为称其为IPv4-in-IPv6更为合适，因为其实现机理与RFC133完全相当，把IPv4报文作为IPv6报文的一种特定负载（IPv6报头Next Header字段=04），且也对相关IPv4和IPv6地址没有任何要求。正因其简单，使其同样经受住历史考验成为了10年后（2008年）孕育的，公认最佳的接入层面过渡方案DS-Lite的实施基础。

1999年，业界第三个IPv6过渡技术是RFC2529-Transmission ofIPv6over IPv4Domains Without ExplicitTunnels正式发布，简称6over4隧道。笔者认为该方案把过渡技术研究方向引入一种歧途，那就是“必须通过特定的IPv4地址或者特定的IPv6地址”来构造隧道。此后数年基于此类思想提出的各种隧道方案，如6to4（RFC3056，2001年），ISATAP（RFC4214，2005年），Teredo（4380，2006年）等都是如此——

—看上去很理想，回避了地址受限短板，实际部署上捉襟见肘。

2006—2007年相继完成标准化的6PE （RFC4798）/6VPE（RFC4659）没有跟随这种思潮，事实上它们属于IPv6-in-MPLS VPN-in-IPv4的解决方案。6PE则将所有IPv6流量都封装到同一个VPN中，适用于没有安全要求的Internet业务过渡场景，6VPE可以实现不同客户的IPv6流量封装到不同VPN中，适用于有安全隔离要求的IPv6孤岛穿越MPLS网络互联的场景。相比IP-in-IP或IP-in-GRE方案，6PE/6VPE 可实现MP-to-MP隧道自动建立，异厂家互通性也相当不错，是全球运营商公认最佳的骨干网穿越方案。如美国AT&T和FT，TI等欧美运营商在现网均有部署。

翻译技术其实包括但不限于在TCP/IP层实施翻译的NAT。在2000—2002年这3年间，业界冒出过BIS（RFCRFC2767），SOCKS64（RFC3089），TRT （RFC3142），BIA（RFC3338）等一大堆在OSI7层模型更高层次实施的翻译技术。但这些技术无疑都要操作系统甚至IPv4基础协议本身提出修改要求，只能存活于实验室，扔到现网无法放大规模。后来大多无疾而终。对NAT的态度，前文所提的IETF（互联网协议权威标准组织）起初是非常排斥的，认为部署NAT会破坏互联网端到端透明性，IPv6才是王道。开展NAT4-to-6或NAT6-to-4的方案研究是在鼓励错误的东西，会延误IPv6的应用。故而在2000年提出框架性的看上去很美，实际上落地实施限制一箩筐的NAT-PT（RFC2766）解决方案后，在整个“春秋时期”再无所作为。

IETF技术权威们曾经认为，通过全球终端（用户）—网络—应用（业务）端到端都逐步升级到IPv4&IPv6双栈，让IPv6自然壮大，同时让IPv4自然老去，长期共存N年后可以顺利完成交接班。但市场是无情的，用户和业务提供商是有惰性的。过去10年间绝大多数企业

２９

··