全面解读移动IPv6协议

网络 网络管理
移动IPv6协议是本文将要研究的问题。首先我们对移动IP的QoS概念要了解,之后我们对移动IPv6协议中的相关安全,切换,和头标压缩内容进行了分析。

对于互联网和通信网络的相互融合形式,我们的很多理念都发生了变化。随着互联网络迎来他的IPv6时代,通信网络方面的协议也将随之改变。那么,针对这个背景,我们提出了移动IPv6协议。在移动IP中实现QoS要比在固定IP网络中复杂的多。区分服务用于移动IP中存在以下问题:

◆区分服务比较适用于设计周全、带宽合理分配的网络,支持移动环境的网络由于其网络中的节点随时移动,因而其业务量模型比较复杂。

◆在区分服务中,不同QoS区域(如不同的ISP提供的网络)的业务等级协商(SLA)常常是静态的,移动IP的高动态环境与区分服务的静态带宽分配是相矛盾的,因此为了MN的动态带宽分配需要,必须支持动态的业务等级协商。

◆在不同QoS区域的入口处,网络的边缘路由器要对分组流进行识别,传统分组流可以通过分组头标上的五元组(源/目的IP地址、协议类型、源/目的端口号)来识别。而移动IPv6中的分组的源IP地址(MN发送的分组)或目的IP地址(MN接收的分组)是MN的转交地址,该地址是随着节点的移动作动态的变化。

为了在移动IP网络上实现区分服务,应精细设计提供移动服务的网络,动态预测移动节点对带宽的需求和接入的MN数,或采用资源预留等信令机制,更准确地预测满足移动节点QoS所需的带宽。区分服务可以选择RSVP作为信令协议,区分服务网络的边缘路由器分析RSVP报文,根据RSVP信息修改区分服务配置参数。但现有的资源预留协议的设计着眼于由静止主机构成的网络,为了支持移动环境的资源预留,还应对RSVP协议进行扩展和修改,使其支持MN的资源预留。另一种方法是定义特别的IPv6扩展头标作为资源预留信令,这样可在一个分组中综合QoS信息、地址绑定信息和IPv6数据分组,节约信令开销。对移动IPv6节点发送的分组中可根据其本地地址和流标记来识别一个数据流,但需要各边缘路由器支持移动IPv6的本地地址信宿选项。

另外,MN在越区切换时引入的分组传输延时和分组丢失也是移动IP急需解决的问题,这个问题不解决,移动Internet的QoS保证就无从谈起。

移动IPv6协议的安全问题

当网络体系结构上添加新的功能时,通常会引入新的安全隐患。对移动IPv6来说,由于节点的移动需要经常向MN的本地代理和CN发送绑定更新报文,这一特征引入了诸多的安全问题。其中最危险的潜在威胁是绑定更新报文具有对分组的重定向功能,攻击者通过冒充MN向CN发送绑定更新报文,就可以将发往MN的分组重定向到攻击者指定的地点。其次是DOS(Denial Of Service)攻击,攻击者能够阻塞未受保护链路上的所有业务量,也能够阻止MN与其他节点的通信。克服这些威胁的手段是MN与本地代理和CN之间进行身份认证,MN与接入路由器(或外地代理)之间也需要认证。

移动IPv6规定了IPSec作为MN的绑定更新报文的安全保护,但在利用IPSec通信之前收发双方需要事先建立安全关联,即决定采用哪种认证、加密算法。一般认为,MN与其本地代理很容易建立安全关联,但大多数情况下,MN与CN不存在安全关联或其他安全关系。移动通信中的无线接入特点,也使得移动用户的通信内容更易受到非法窃听和篡改,用户数据的安全可采用IPSec或上层安全协议加以保护。另外,防火墙也需要支持移动IPv6协议,因为移动IPv6节点发出的分组的源地址是MN的转交地址,它随着节点的移动而变化,防火墙如果不能识别它就不能实现正常的分组过滤。

移动IP业务的使用需要Internet提供支持移动IP的AAA服务,即移动用户的认证、授权和计费服务。当MN移动到外地网络时,MN需要对外地代理或接入设备进行认证,以确定对方的有效性,外地代理也需要对MN进行身份认证,以防止其非法攻击。授权和计费主要涉及MN在外地网络上的资源的使用权和使用情况。目前IETF已出台协议草案来支持移动IP的AAA服务(RFC 2977和draft-ietf-aaa-diameter-mobileip-08.txt)。

移动节点的越区切换

MN在越区切换时,首先需要无线链路的切换,如果新旧链路不在同一个IP子网内,还要进行IP子网切换。即使采用了路由优化技术,在无线链路切换和子网切换过程中的分组延时还相当可观的,而延时的主要部分是由链路切换完成后的端到端的移动IP注册操作引起的。在切换过程中,发给MN的分组可能被丢失。因此快速切换方案将有利于改善分组数据的业务质量。

在下一代无线通信系统中,出于对节约信道等方面的考虑,小蜂窝(micro-cell 和 pico-cell)的架构将会获得越来越多的使用,这样将会导致链路的频繁切换。链路切换常由第二层协议或硬切换完成,而跨越IP子网的切换需要第三层协议或软切换完成。根据切换时采的方法,切换可分为快速切换、平滑切换和无缝切换三种类型。快速切换即低延时切换,它常采用蜂窝组播的方式,以带宽为代价降低MN在越区切换时分组的延时;平滑切换即低丢失率切换,它采用缓存的方式降低MN在越区切换时的分组丢失;无缝切换既要降低分组的丢失率,又要降低分组的延时。#p#

蜂窝IP将蜂窝系统的快速移动通信以及平滑的链路切换特性引入到Interne。为了解决链路切换时可能产生的数据丢失问题,蜂窝移动IPv6协议中提出了外地本地代理(FHA)和蜂窝组播(CM)的机制。外地本地代理是位于外地网络的主机,它用来转发寻址到MN的分组。在地本地代理中设有MN的缓存列表,用来记录其所管理区域内的所有MN。由于MN蹬转交地址可以通过网络前缀加上其MAC地址来自动配置,当寻址到MN的分组到达外地本地代理时,通过查询外地本地代理的MN缓存列表,蜂窝组播采用向该区域内具有相同MAC地址的转交地址进行组播的方式,来保证MN在该区域的任何一个子网上都能收到数据。因此蜂窝组播机制是通过占用带宽来降低分组丢失的。当移动用户较多时,这种方法将会占用过多的带宽资源。

2001年7月出台的IETF草案“移动IPv6的快速切换"提出了增强移动IPv6节点在Internet上快速改变接入点能力的方案,以降低越区切换时的分组延时和丢失率。在该草案中,MN在将要移往新的链路之前,先启动一个切换规程,预先获取新链路上的转交地址。切换规程通过在新老接入路由器之间以及接入路由器与MN之间交换新增的报文来实现的。这种方法需要MN预先知道自己即将移动到新的链路,因此需要第二层的支持。

目前,研究移动IP快速切换的文献很多,其基本思路有三种:分组缓存、组播和基于第二移动触发的预先切换,这些方法各有其优缺点。另外,移动IP的资源预留、MN注册过程中的认证以及移动IPv6头标压缩的同步规程都将在MN的切换过程中引入延时,因此移动IP的越区切换需要更好的有效方法。

移动IPv6协议的头标压缩

在移动IPv6草案中规定,MN向CN发送分组时,IPv6分组头中的源地址为MN的转交地址,为了在分组中包含唯一标识MN的本地地址,MN发送的分组必须包含本地地址选项。而CN发给MN的分组则采用寻路头标的方式,即分组的目的地址为MN的转交地址,寻路头标中含有MN的本地地址。

由于无线链路传输速率较低、误码率较高的特性,在无线网络上传输IP分组的主要问题就是头标的开销过大。例如,一帧音频数据净荷通常只有15~32字节,而在移动IPv6环境中传输该数据需要40字节的IPv6头标,20字节的信宿选项头标或24字节的寻路头标,8字节的传输层UDP(用户数据报协议)头标和12字节的RTP(实时传输协议)头标。总共的头标开销是80(或84)字节,如果通信对端也是MN,那么分组的IP/UDP/RTP加在一起的头标开销有104字节。这不仅浪费带宽,同时还使分组因出错而被丢弃的概率增大。

事实上,在传输过程中,同一个数据流的分组的IPv6头标有很多域是相同的,例如,版本、流标记、下一个头标以及源地址、目的地址在一个小区内都是不变的。动态变化的部分只有业务量等级、中继点限制。此外,信宿选项头标和寻路头标中每个域都是静态不变的。因此,如果在无线链路上仅仅在数据流开始时发送完整的IP分组及相应的选项头标,后续的IP分组的头标域只传输变化的部分和相对于同一个流的关联识别符,就可以更加有效地利用带宽。但由于用户在不断地移动中,因此,有效的头标压缩算法和数据流压缩同步规程是该研究课题的关键所在。

移动Internet是移动通信与Internet技术的融合,它具有诱人的应用前景。移动IPv6协议为新一代Internet的无线用户提供了移动支持,但在移动越区切换、QoS、安全等方面仍不能满足实际应用的需要。目前,许多研究机构(包括移动通信的著名厂商诺基亚、爱立信等)都在研究这些关键技术,相信不久的将来,移动业务将开创Internet发展的新纪元。

责任编辑:佟健 来源: 互联网
相关推荐

2010-06-11 17:17:47

移动IPv6协议

2010-06-02 14:40:11

IPv6协议地址

2010-05-26 13:49:45

移动IPv6协议

2010-05-26 13:55:49

移动IPv6协议

2010-06-11 17:20:28

2019-06-05 15:43:34

IPV6IPV4网站

2010-05-26 14:02:02

Mobile IPv6

2010-06-01 22:46:11

IPv6路由协议

2010-06-02 15:56:54

IPv6协议标准

2010-06-01 13:52:03

IPv6协议路由协议

2010-06-07 15:14:40

移动IPv6技术

2019-01-17 18:53:33

2010-05-27 11:51:04

IPv6协议

2010-06-01 15:59:19

2010-06-21 15:18:19

IPv6协议栈

2010-06-12 14:34:52

ipv6协议

2010-05-27 11:47:38

2010-06-28 10:46:57

JBossIPv6协议

2010-06-07 16:52:38

IPv6协议地址

2019-04-03 10:28:04

点赞
收藏

51CTO技术栈公众号