中国已经启动CNGI项目,着手建设IPv6网络。针对从IPv4向IPv6过渡,本文讨论了互联网工程任务组定义的双堆栈方法和几种网络隧道(tunneling)及转换(translation)技术。这些技术可以最大程度地保证网络基础组件和应用程序向下一代网络协议过渡的平滑性。
未来两年IPv6的部署将会有显著增加。然而在十年之内行业整个过渡到下一代协议并不会全部完成,2003年至2005年将代表IPv6实施钟形曲线的上升段。因此迫切需要系统设计人员和程序员开始着手使他们的产品实现从IPv4向IPv6过渡。
IPv6已经开始进入某些基础架构组件。微软、Sun、惠普康柏、IBM、Linux供应商、苹果和其他公司正在推出支持IPv6的操作系统。此外,今年推出的微软Windows 2003 Server中的文件共享和打印共享应用程序、来自微软的对等游戏以及Sun Solaris应用程序都支持IPv6。显然,业界正逐步从早期接受阶段进入到商业实施阶段。
与其它任何核心网络基础设备的过渡一样,为IPv6的很多协议组件制定规范是一个详细而长期的过程。现在,经过十几年的开发,IPv6协议日趋成熟和稳定。在制定基础协议的同时,互联网工程任务组(IETF)还定义了很多用于过渡的工具,这些工具允许双协议共存,并且目前正在开发面向部署和操作共享IPv4/IPv6网络的指南。
机会与挑战
相比IPv4,IPv6的128位寻址空间提供了很多新的应用和网络服务商机。通过消除了转换专有IP地址和公共IP地址的必要,扩展的寻址空间还简化了IPv6应用程序和网络设备用户的网络操作。不过,转换过程对客户而言通常太复杂而难以配置与管理。
IPv6地址是IPv4的四倍,而IPv6报头(header)只有IPv4的两倍,压缩比IPv4更有效率。这对系统设计人员而言是好消息,在构建应用程序和网络设备以便在速度有限的网络链路上运行时,系统开销不会成正比的增加。
在短期内,通信系统设计人员将经常进行选择以使这两种协议和平共处。这是因为很多客户和用户需要原有的IPv4基础架构和应用程序以便与更新的网络组件实现互操作。有时,对于新功能无需与原有网络组件进行通信的情况,构建只支持IPv6协议的产品是合适的做法。
要创建支持IPv6的应用程序,主机操作系统必须支持IPv6。系统设计人员应明白,如今IPv6能力可以在分离的IPv4和IPv6协议堆栈或在集成的IPv4/IPv6堆栈中实现,这根据主机操作系统而定。例如,Windows XP和2003 Server包含分离的并行堆栈,而最新版本的FreeBSD Unix、惠普的True64 Unix、Linux和Sun Solaris则支持集成的堆栈。
为了最大程度地保证从IPv4过渡到IPv6的平滑,IETF的下一代过渡(Next-Generation Transition,NGTRANS)工作组已经开发了很多工具,这些工具使设计人员和开发人员可以开始将网络基础组件和应用程序或两者都移到新的协议。主要的过渡工具称为双堆栈,使两种协议可以同时运行。其他工具包含几种网络隧道(tunneling)技术选项和转换(translation)。
这些选项的主要宗旨是消除应用程序与网络基础设备之间部署的依赖性。
双堆栈方法
双堆栈方法很可能应用得最多。简而言之,这种方法在部分网络或整个网络中同时运行IPv4和IPv6。网络组件可以继续与只支持IPv4的设备进行通信(参见图1),但具有IPv6的新功能。
双堆栈可比喻为在一条已经存在了数十年的老双车道公路旁修建一条八车道高速公路。通过添加新的传输能力以便与已经存在的能力并行运行,而不会造成任何损害,可以避免中断。经过一段时间,“车辆”(分组数据)可以从一个基础设施移动到另一个基础设施上,直到处于经济上的考虑,不再继续保有旧的双车道公路(IPv4基础设施)。
就额外的CPU和内存消耗而言,运行两个路由和通信基础设施备确实会占用额外的费用。针对双堆栈环境的产品设计人员必须时刻牢记资源需求问题。但是,提供足够的CPU和内存以同时运行两种协议的回报是消费者会接受操作上简单的设备。
几种隧道技术选项
需要澄清隧道与封包(encapsulation)的区别。业界已经确定了隧道和封包的术语区别。隧道应用于第3层(路由层)及以上,而封包应用于Layer 2(链路层)。但是,在架构上两种机制是一样的:它们涉及在一类分组数据中“封包”另一类分组数据以使传输数据流穿过不同的网络基础设施。
目前存在几种隧道技术,但是每种均允许网络实施者通过在另一个网络“之上”运行一个网络来削弱应用程序与网络基础设备之间的依赖性。隧道技术可单独使用,也可与双堆栈一起使用。无论使用何种隧道方法,至少要求在网络中有一对双堆栈节点。
IPv6-over-IPv4 隧道:最常见的隧道实施方法可能是在IPv4网络地址报头中封包IPv6数据包,很多网络实施者会从IPv6数据包开始,并且保留IPv4网络基础设施的主体(参见图2)。
但是,视情形而定,可能出现相反的情况:网络主体要转向IPv6,保留少数原有的IPv4节点。在此情况下,IPv4-over-IPv6隧道技术更为合适。为了适应用户的这种规划要求,系统设计人员将希望在网络极边缘处的智能设备中提供IPv6支持,例如在用户设备和应用程序中。
跨越多个IPv4“云团”的IPv6域连接(6至4):这种机制针对隔离站点之间的部署,使一个IPv6路由器可以用单个IPv4地址自动为数据包建立隧道穿过IPv4网络,以创建一个IPv6前缀。
站内自动隧道寻址协议(ISATAP):ISATAP针对校园部署应用,并且允许不与IPv6路由器共享物理链路的双堆栈节点可自动将数据包穿过IPv4发送到IPv6下一跃点(hop)地址。
Teredo:此选项在IPv4上以用户数据报协议(UDP)封包IPv6。其目标是越过IPv4网络地址转换(NAT)。UDP传输协议在NAT中建立一个“洞”以允许建立隧道。此工具特别适合要求极高简化程度的用户应用程序的开发,例如多人游戏。
多协议标签交换(MPLS)骨干上的IPv6:类似于IPv6-over-IPv4隧道技术,此工具允许单独的IPv6域通过一个MPLS骨干相互通信。对设计人员而言,造成的影响就是在服务供应商网络的边界建立供应商边缘(PE)路由器。这些设备必须识别IPv6地址和格式,并将相应的MPLS标签加在新的地址格式上以实现在MPLS骨干中的正确交换。
协议和格式转换
此“最后一招”过渡工具将一组IP协议和格式转换为另外的协议和格式。IETF建议只有绝对必要时才进行转换,大多数情况下,其效能并不比IPv4网络地址转换更好。
不推荐经常使用转换的原因是转换会引起升级问题并导致应用更加复杂。同时,在某些设备只支持IPv6而某些设备只支持IPv4的网络中,且要保留功能岛继续有效,转换工具特别重要。举例来说,如果新的便携式设备只支持IPv6,但是打印机等共享设备尚未升级,则需要转换以便它们能够互操作(参见图3)。
有几种版本的转换器,这些转换器工作于不同的层。具体而言,这些转换器包含API转换器、传输层转换器和IP数据包转换器。IP数据包转换器可以是状态性的(stateful)或无状态的(stateless),视被转换的会话性质而定。
如上所述,用即插即用转换屏蔽复杂性是IPv6的设计宗旨。理想情况下,采用所描述的工具,任何设备均应可插入网络并且通过极少的配置开始发送数据包。
子网服务:在IPv4环境中,服务供应商提供增强服务的能力仅限于面向拥有技术精湛IT和网络工作人员的商业客户。这是由与配置和管理有限地址空间或NAT处理相关的一系列挑战造成的。
服务指配(provisioning)
IPv6使此类服务无需客户提供太多信息,开发人员需要在服务供应商及客户设备中包含几个特性。例如,网络服务供应商的前端设备路由器必须能够进行以下操作:
* 使用动态主机控制协议第6版(DHCPv6)向客户分配网络前缀,该协议目前还是IETF草案；
* 安装这些前缀的路由。
在另一端,客户网络必须能够进行以下操作:
* 获取前缀；
* 向下游设备宣布前缀；
* 安装默认路由。
地址保密:移动用户将发现非常有价值的就是RFC 3041定义的保密地址功能。由于IPv6网络中的接口支持多个IP地址,用户设备可以在一段时间内在访问的子网中使用不同的接口标识符。这极大地削弱了所连节点配置与那些特定设备连接的子网的能力；换言之,它使移动设备的可跟踪能力下降。客户不能接触到此能力的配置基础。
从设计观点而言,IPv6节点在相邻缓存中将有多个入口,这需要更多的内存。
其它考虑因素
如上节所述,IPv4网络中的典型接口只被分配一个地址,但是在IPv6中必须支持多个地址。这给系统设计人员的任务增加了一些复杂性,但也极大地简化了设备的操作特性。
设计人员应记住的另一些事情就是:IPv4可在一个时钟周期内从一个32位总线上传送32位地址,而要在具有64位总线的系统中传送128位IPv6地址则需要两个时钟周期。
每个子网有大量的地址空间,无需不断调整池的大小以满足当前的需要,从而减少了网络实施人员的操作复杂性。例如,酒店和无线热点在他们的DHCP池中将不会出现空间不足的情况,而现在如果大量设备竞争临时地址,就会这出这种情况。
路由协议考虑因素:边界网关协议第4版(Border Gateway Protocol Version 4)和中间系统对中间系统(Intermediate System-to-Intermediate System)在一个共用实例中支持两个版本的IP协议。但是,开放最短路径优先协议(OSPF)第2版和第3版以“夜间行船”模式运行,在此模式中,各个设备独立运行且互不相知。因此,在OSPF网络中,设计人员应考虑到每一个事件将导致路由设备运行两次计算而不是一次。这意味着路由收敛时间极有可能增加,除非添加额外的CPU资源。
作者:Tony Hain
技术负责人
Email:thain@
思科系统公司先进架构组
京公网安备 11011202001138号
