摘要：对IETF的组织机构和工作流程进行了介绍，梳理了与IPv6相关的RFC和Internet-Draft，介绍了业界对现有标准的支持程度和运营商基于这些标准采取的演进方式。

1  引言

　　互联网已经成为事实上的电信网络载体，IPv6作为下一代互联网协议栈将逐步取代IPv4已经成为共识。在电信领域目前的ITU-T，BBF，IEEE及IETF等几大国际标准组织中，IETF对IPv6标准化进展起到的推动作用最大。IETF虽然不是互联网的惟一标准化组织，但却是互联网基础技术和底层协议的最初创建者和维护者。本文将围绕IETF相关标准进展进行论述。

2  IETF组织结构及工作流程

　　IETF的正式文件为RFC，但RFC1796已经明确说明：不是所有RFC都是标准。而且所有的标准在提出之前都需要经过Internet-Draft阶段。很多人并不是很清楚这一点，即使是数据网络行业的从业者。为了对IETF就IPv6相关的标准和建议有个全面了解，有必要首先对IETF的工作流程和机构进行概要介绍。

　　首先，IETF（The Internet Engineering Task Force）是一个松散的、自律的、志愿的民间学术组织，由为互联网技术工程及发展做出贡献的专家自发参与和管理的国际民间机构。它汇集了与互联网架构演化和互联网稳定运作等业务相关的网络设计者、运营者和研究人员，并向所有对该行业感兴趣的人士开放，任何人都可以注册参加IETF的会议。IETF年会是一群热爱互联网技术的人的论坛，每年轮流在世界各地召开3次会议，讨论与网络运行操作、网络设备开发及软件实现相关的解决方案，以及相互探讨未来会普及的协议、标准和产品。除了每年3次、每次为期5天的面对面讨论外，IETF工作组的许多工作是通过邮件列表（Mailing List）进行的。

　　IETF的标准工作分为8个重要的研究领域，分别是应用领域、通用领域、互联网领域、操作与管理领域、实时应用和基础设施领域、路由领域、安全领域和传送领域，每个研究领域均有1~3名领域主管（Area Directors），负责本领域的日常运转。每个领域又由多个工作组（Work Group）组成，每个工作组有1~2名工作组主席主持本组的日常工作。目前，针对IPv6协议、规范、过渡和演进比较活跃的工作组主要有互联网领域的PPPext，SAVI，Softwire工作组；操作与管理领域的v6ops工作组；传送领域的Behave工作组等。

　　与互联网技术相关的任何想法和方案，理论上都有可能成为RFC，提交RFC需要经过如下几个步骤：

（1）首先作者本人明确自己研究的技术属于IETF哪个技术领域（Area），以及在这个领域中属于哪个工作组（Work Group），然后有针对性地编写、提交Internet-Draft文档。

（2）参加IETF会议，并通过邮件列表参与广泛讨论，收集、归纳大家的评论和反馈。

（3）基于反馈意见对草案进行修改和完善。

（4）重复步骤1~3若干次。

（5）如果属于个人草案，向所在领域的主管提出申请以便提交草案到IESG（互联网工程组指导组）进行审核，如果为工作组草案，则由工作组主席向领域主管提交申请。

（6）所提交的草案会得到IETF成员更广泛的审核，包括其他领域的专家，以便确保最终成为RFC的文档具备较高的质量。

（7）在IESG的要求下进行必要修改和完善（包括根据要求放弃成为标准）。

（8）等待由RFC编辑最终发布文档成为RFC。

3  RFC与Internet-Draft

　　RFC标准产生的过程是一种自下而上的过程，而不是自上而下，也就是说不是一个由主席或者由工作组负责人的一个指令，而是由下自发提出，然后在工作组里讨论，讨论了以后再交给工程指导委员会进行审查。如果想成为RFC，必须先提交Internet-Draft，这是一个必经的过程。互联网草案还可以分为工作组文档或个人文档两类，工作组文档的命名规则是“draft-ietf-”后面紧跟工作组的名称；如果是个人文档，名称为“draft-”后面紧跟作者的名字；版本都是以“nn.txt”为结尾，“00”代表第一版。

　　通常来说，IETF对Internet-Draft有一个定性的描述：Internet-Draft并不是IETF正式发布的技术规范，Internet-Draft没有正式的状态（都是意向状态），并且可能随时修改甚至因过期而废止，如果在6个月之内没有更新，草案自动废止。所以在任何情况下都不建议将Internet-Draft作为论文、报告、应标文件（Request-for-Proposal）的参考依据，厂商也不应声明他们的解决方案遵循某个Internet-Draft。

　　即使草案最终成为RFC，也需要清楚不是所有RFC都是标准这一原则。RFC文档分为几类，在IETF中采用状态（Status）来表示：标准轨迹（Standard-Track），最佳实践（Best Current Practices），信息参考（Informational），试验性（Experimental）和历史的（Historic）。根据IETF最初的想法，只有标准轨迹类型的RFC才能成为各厂家在实现相关技术时所必须遵循的标准。其中，Standard-Track又分为建议标准（Proposed Standard），草案标准（Draft Standard）和互联网标准（Internet Standard）3个阶段。截止到目前，共有123个涉及IPv6的RFC成为Proposed Standard，其中26个已经被废止，需要说明的是，废止它们的新的RFC未必是Proposed Standard，有可能是RFC的任何状态。现在仍然有效的97个Proposed Standard RFC涵盖的领域非常广泛，主要涉及移动IPv6，IPv6路由，6PE（RFC4798），IPv6组播，DHCPv6，IPv6编址及架构，IPv6 MIB，IPv6Sec，Teredo（RFC4380），6 to 4（RFC3056），ICMPv6以及IPv6在L2协议上的封装等方面。

　　无论是Draft Standard还是Proposed Standard，厂家根据设备在网络中的定位和角色提供对标准有取舍的支持，例如核心设备不一定要支持6 to 4和Teredo隧道，固网设备不一定要支持移动IPv6的属性，终端只需支持NDP，DHCP，ICMP等基本协议，而无需支持路由，6PE等。

　　如果算上BCP，Informational，Experimental等状态的RFC，截至2010年5月31日，IETF已发布了与IPv6相关的RFC 268个 ，除去已废止的49个，共有219个RFC。从图1可见，目前研究热点已经从IPv6基本路由协议，转向IPv6过渡技术，IPv6用户端设备（CPE）标准，IPv6接入认证（DHCPv6）等领域。

图1  IPv6相关RFC类别和数量

 　　IPv6过渡技术主要指针对协议转换、地址翻译、隧道封装等技术方案的RFC，相关标准包括：

（1）IPv4向IPv6过渡框架、场景定义。

（2）IPv4/v6协议翻译技术。

（3）IPv4/v6隧道相关技术。

（4）IPv6过渡地址格式定义。

（5）IPv6 DHCP相关标准定义。

（6）IPv6 DNS及DNS-ALG相关标准定义。

　　CPE方面主要指PPP认证，DHCP-PD更多考虑到路由型家庭网关应用环境；接入认证方面主要指终端地址分配方式从NDP向DHCPv6发展。

　　值得注意的是，有许多我们曾经非常熟悉的技术，例如NAT-PT（RFC2766-historic），NAT64（draft-ietf-behave-v6v4-xlate-stateful-11），Socks64（RFC3089-informational）等转换技术，以及Tunnel Broker（RFC3053-informational），ISATAP（RFC5214-informational），IPv6 Tunnel Broker with the Tunnel Setup Protocol （TSP）（RFC5572-experimental），IPv6 over L2TP（draft-kuwabara-softwire-ipv6-via-l2tpv2-00）等隧道技术，甚至包括现在非常热门的NAT444（draft-shirasaki-nat444-01），DS-Lite（draft-ietf-softwire-dual-stack-lite-04），6RD（RFC5569-informational），DNS-ALG（draft-durand-v6ops-natpt-dns-alg-issues-00），DNS64（draft-ietf-behave-dns64-09），DNS46（draft-xli-behave-dns46-for-stateless-02），IVI（draft-xli-behave-ivi-07）/DIVI（draft-xli-behave-xlate-partial-state-01），A+P（draft-ymbk-aplusp-05），PNAT（draft-huang-behave-pnat-01），SAVI（draft-ietf-savi-dhcp-03），绝大部分都不是RFC的Standard Track，很多是Informational状态（其中NAT-PT为Historic，TB with TSP为Experimental），还有更多的目前仍然处于Internet Draft阶段（其中DNS-ALG和L2TP已经过期），且这些Internet Draft的意向状态也大多为Informational（DNS64的意向状态是Standard Track）。如果严格按照IETF对Internet Draft以及非Standard Track RFC的定性，这些文档是不能成为“标准”来指导设备开发的。但实际情况并非如此，设备厂商出于商业竞争和树立行业领先地位等因素，纷纷对非Standard Track RFC甚至Internet Draft提供支持，许多草案阶段的概念已经在现有设备上实现了，例如Juniper，Gogo6已经支持DS-Lite，Juniper，华为支持IPv6 over L2TP的LNS和LAC，Gogo6已经支持TB with TSP，Veno已经支持Socks64，思科即将支持IVI和6RD，华为计划支持PNAT，NAT64和DS-Lite，国内很多中、低端交换机厂商已经支持SAVI，清华正在开发DIVI原型等。所以从以上分析，IETF RFC以及草案，无论是何种状态或意向状态，其本身都具有“标准”的内在特性和指导作用，设备厂商可以根据这些草案或RFC制定的交互协议字段细节进行源代码编写以实现文档所描述的功能。从这方面来说，很多厂商忽略了状态为Informational的RFC甚至Internet Draft不能作为标准依据的定性，仍然积极响应文档中的建议并在设备中加以实现，这也是互联网行业目前的真实现状。

4  运营商基于现有标准采取的演进方式

　　作为电信运营商，在IPv4向IPv6演进过程中，会结合当前IPv6标准进展和技术成熟度选择适合自己的过渡方式。目前，有3种主流的演进路线，分别是双栈IPv4+IPv6，4over6隧道+IPv6和IPv4+6over4隧道。在实际部署中各种过渡方案可能会重叠和交错。

　　双栈方案用于尚有一定IPv4地址可用的运营商，便于其实现IPv4业务和IPv6业务的协同发展，平滑升级。这是最经济、最稳妥的方案，实施风险较低，能够留给IPv6充足的成熟时间。针对地址紧缺的运营商，也可能采用NAT444+IPv6的双栈方案，此时需要重点解决NAT444带来的私有地址运维，LSN设备性能，LSN在城域网中的部署方式（集中或分部），对ALG支持等问题上。解决这些问题的技术非常多，在IETF相关领域和工作组中的讨论异常活跃，但由于没有涉及IPv6，本文不做论述。总之，双栈方案基本属于被动等待演进—网络运行平稳，但需要考虑IPv4私网地址规模使用存在风险。据了解，NTT是最早实现全网双栈的运营商。

　　4over6隧道+IPv6的典型方案是DS-Lite隧道。法国电信、意大利电信、美国Comcast和西班牙电信已经在网络中部署了DS-Lite，此方案适合于IPv4地址非常紧缺的运营商，以发展IPv6业务为主，尤其是IPv6接入业务，同时兼容IPv4业务。该方案直接对用户分配IPv6地址，便于用户统一管理，能够简化运维，缓解IPv4地址紧缺的压力。当前DS-Lite面临的最大问题是客户端设备不成熟，已经部署的运营商采用的是定制的CPE（如法国电信采用自己制定企业规范，委托第三方代工生产的方式），没有批量生产的商业化产品，此外DS-Lite没有认证鉴权机制，这些不足会在一定程度上制约DS-Lite方案的推广。采用纯IPv6接入可以看作主动推进演进—过渡策略，但是隧道技术是否成熟存在风险。

　　IPv4+6over4隧道的代表技术是6RD。美国的AT&T以及Comcast部署了6RD。与6RD类似的解决方案为IPv6 over L2TP，有部分运营商采用了L2TP隧道来提供IPv6用户远程覆盖。6RD和L2TP方案适用于IPv6业务发展的早期，运营商以IPv4业务为主，拥有少量的IPv6用户。其优势在于，有助于保护运营商的初期投资，减少对现网业务的影响。从IPv4过渡到IPv6一定是个渐近过程，用户需要在不中断IPv4业务的前提下逐渐培养用户使用IPv6业务的习惯。此方案的问题在于不能大规模部署用户，对IPv6的推广力度较DS-Lite方式弱。

5  结束语

　　IPv6协议栈的标准还在不断发展和完善，各种新思路、新方案层出不穷，基础的标准已经成熟和稳定，例如IPv6协议规范、路由寻址、地址体系等。但是，在地址分配方式（NDP，DHCPv6，PPPv6），6~4或4~6转换（含ALG），移动IP，6over4或4over6隧道，IPv6网络管理等领域还有大量工作要做。此外，由于互联网采用Client Server模型，最重要的参与者就是用户终端和内容平台之间的交互，软件操作系统对IPv6的支持也日益迫切。从IPv6产业链角度看，运营商采购设备负责搭建IPv6骨干网络和接入网络，相对来说易于实现，而产业链的两端——用户和ICP，才是确保IPv6具有网络生命力的根基。体现在IPv6标准方面，则需要进一步完善IPv6协议集，操作系统底层实现对IPv6的充分支持。另外，应用软件要全面基于IPv6 Socket编程，提供包括P2P，网络游戏，Web浏览等全面的IPv6应用，才是下一代互联网真正得以普及的前提。