IPv6和ICMPv6
时间:01-16
来源:学新网
点击:
本章介绍了IPv4的更新,描述了新的协议头中各字段及IPv6的地址空间,着重介绍了IPv6中包含的变化和新特性。IPv4拥有两个"帮助"协议: Internet控制报文协议( ICMP )和Internet组管理协议( IGMP )。主机和路由器使用这些协议来报告IP层差错及执行其他功能、诊断等。IPv6中使用的是对ICMP进行升级后的ICMP v6协议, ICMP v6中最初包含了IGMP的功能,但现在看来这些功能可能要由IGMP v2来完成。
本章第一小节描述了IPv6协议的基本框架并介绍了RFC 1883(IPv6技术规范)和其他后续标准(到1998年9月还没有分配R F C号码)中定义的IPv6头字段、选项和扩展。本章第二小节概述了RFC 1885( 用于IPv6的Internet控制报文协议( ICMP v6 )的技术规范)中定义的ICMP v6。IGMP v2在RFC 2236(Internet组管理协议第2版)中定义,并且与IPv4和IPv6均有关联。
IPv6的地址方案将在第6章中介绍,第7章对IPv6的选项和扩展头有更详细的介绍。第8章将探讨IPv6的选路。第9章将进一步讨论IPv6中的安全性和身份验证问题,第1 0章将介绍升级到IPv6对IP的上层和下层协议造成的影响。
5.1 IPv6
对IPv4的升级最早在两个R FC中进行了定义。RFC 1883中描述的是协议本身,而R F C 1 8 8 4介绍的是IPv6的地址结构。现在RFC 1884已经被RFC 2373所替代,1998年夏天I E T F批准了一个草案来替换RFC 1883。从3 2位地址到1 2 8位地址的变化代表了一个重大的转变,但如何制定和分配IPv6地址直到1998年秋天也没有定论。第6章将对于IPv6的地址有更详细的介绍。本节只介绍真正的IPv6协议中最重要的改变而不讨论地址细节。
5.1.1 变化概述
IPv6中的变化体现在以下五个重要方面:
扩展地址。
简化头格式。
增强对于扩展和选项的支持。
流标记。
身份验证和保密。
对于IP的这些改变对I A B于1991年制定的IPv6发展方向中的绝大部分都有所改进。IPv6的扩展地址意味着IP可以继续增长而无需考虑资源的匮乏,该地址结构对于提高路由效率有所帮助;对于包头的简化减少了路由器上所需的处理过程,从而提高了选路的效率;同时,改进对头扩展和选项的支持意味着可以在几乎不影响普通数据包和特殊包选路的前提下适应更多的特殊需求;流标记办法为更加高效地处理包流提供了一种机制,这种办法对于实时应用尤其有用;身份验证和保密方面的改进使得IPv6更加适用于那些要求对敏感信息和资源特别对待的商业应用。
1. 扩展地址
IPv6的地址结构中除了把3 2位地址空间扩展到了1 2 8位外,还对IP主机可能获得的不同类型地址作了一些调整。就像在第6章中将要详细介绍的一样, IPv6中取消了广播地址而代之以任意点播地址。IPv4中用于指定一个网络接口的单播地址和用于指定由一个或多个主机侦听的组播地址基本不变。
2. 简化的包头
IPv6中包括总长为4 0字节的8个字段(其中两个是源地址和目的地址)。它与IPv4包头的不同在于,IPv4中包含至少1 2个不同字段,且长度在没有选项时为2 0字节,但在包含选项时可达6 0字节。IPv6使用了固定格式的包头并减少了需要检查和处理的字段的数量,这将使得选路的效率更高。
包头的简化使得IP的某些工作方式发生了变化。一方面,所有包头长度统一,因此不再需要包头长度字段。此外,通过修改包分段的规则可以在包头中去掉一些字段。IPv6中的分段只能由源节点进行:该包所经过的中间路由器不能再进行任何分段。最后,去掉IP头校验和不会影响可靠性,这主要是因为头校验和将由更高层协议( U D P和T C P )负责。
3. 对扩展和选项支持的改进
在IPv4中可以在IP头的尾部加入选项,与此不同, IPv6中把选项加在单独的扩展头中。通过这种方法,选项头只有在必要的时候才需要检查和处理。下面和第7章将对此有更多的讨论。
为便于说明,考虑以下两种不同类型的扩展部分:分段头和选路头。IPv6中的分段只发生在源节点上,因此需要考虑分段扩展头的节点只有源节点和目的节点。源节点负责分段并创建扩展头,该扩展头将放在IPv6头和下一个高层协议头之间。目的节点接收该包并使用扩展头进行重装。所有中间节点都可以安全地忽略该分段扩展头,这样就提高了包选路的效率。
另一种选择方案中,逐跳( h o p - b y - h o p )选项扩展头要求包的路径上的每一个节点都处理该头字段。这种情况下,每个路由器必须在处理IPv6包头的同时也处理逐跳选项。第一个逐跳选项被定义用于超长IP包(巨型净荷)。包含巨型净荷的包需要受到特别对待,因为并不是所有链路都有能力处理那样长的传输单元,且路由器希望尽量避免把它们发送到不能处理的网络上。因此,这就需要在包经过的每个节点上都对选项进行检查。
4. 流
在IPv4中,对所有包大致同等对待,这意味着每个包都是由中间路由器按照自己的方式来处理的。路由器并不跟踪任意两台主机间发送的包,因此不能"记住"如何对将来的包进行处理。IPv6实现了流概念,其定义如RFC 1883中所述:
流指的是从一个特定源发向一个特定(单播或者是组播)目的地的包序列,源点希望中间路由器对这些包进行特殊处理。
路由器需要对流进行跟踪并保持一定的信息,这些信息在流中的每个包中都是不变的。这种方法使路由器可以对流中的包进行高效处理。对流中的包的处理可以与其他包不同,但无论如何,对于它们的处理更快,因为路由器无需对每个包头重新处理。下一节中将对流和流标记有更详细的讨论。
5. 身份验证和保密
RFC 1825(IP的安全性体系结构)描述了IP的安全性体系结构,包括IPv4和IPv6。它发表于在1995年8月,目前正在进行修改和更新。1998年3月发表了一个更新版Internet草案。IP安全性的基本结构仍然很坚固,且已经进行了一些显著的改变和补充。这个体系结构以及它在IPv6中如何实现,都将在第9章介绍。
IPv6使用了两种安全性扩展: IP身份验证头( A H )首先由RFC 1826(IP身份验证头)描述,而IP封装安全性净荷( E S P )首先在RFC 1827(IP封装安全性净荷( E S P ) )中描述。
报文摘要功能通过对包的安全可靠性的检查和计算来提供身份验证功能。发送方计算报文摘要并把结果插入到身份验证头中,接收方根据收到的报文摘要重新进行计算,并把计算结果与A H头中的数值进行比较。如果两个数值相等,接收方可以确认数据在传输过程中没有被改变;如果不相等,接受方可以推测出数据或者是在传输过程中遭到了破坏,或者是被某些人进行了故意的修改。
封装安全性提供机制,可以用来加密IP包的净荷,或者在加密整个IP包后以隧道方式在Internet上传输。其中的区别在于,如果只对包的净荷进行加密的话,包中的其他部分(包头)将公开传输。这意味着破译者可以由此确定发送主机和接收主机以及其他与该包相关的信息。使用E S P对IP进行隧道传输意味着对整个IP包进行加密,并由作为安全性网关操作的系统将其封装在另一IP包中。通过这种方法,被加密的IP包中的所有细节均被隐藏起来。这种技术是创建虚拟专用网( V P N )的基础,它允许各机构使用Internet作为其专用骨干网络来共享敏感信息。
5.1.2 包头结构
在IPv4中,所有包头以3 2位为单位,即基本的长度单位是4个字节。在IPv6中,包头以6 4位为单位,且包头的总长度是4 0字节。IPv6协议为对其包头定义了以下字段:
版本。长度为4位,对于IPv6,该字段必须为6。
类别。长度为8位,指明为该包提供了某种"区分服务"。RFC 1883中最初定义该字段只有4位,并命名为"优先级字段",后来该字段的名字改为"类别",在最新的IPv6 Internet草案中,称之为"业务流类别"。该字段的定义独立于IPv6,目前尚未在任何R F C中定义。该字段的默认值是全0。
流标签。长度为2 0位,用于标识属于同一业务流的包。一个节点可以同时作为多个业务流的发送源。流标签和源节点地址唯一标识了一个业务流。在RFC 1883中这个字段最初被设计为2 4位,但当类别字段的长度增加到8位后,流标签字段被迫减小长度来作补偿。
净荷长度。长度为1 6位,其中包括包净荷的字节长度,即IPv6头后的包中包含的字节数。这意味着在计算净荷长度时包含了IPv6扩展头的长度。
下一个头。这个字段指出了IPv6头后所跟的头字段中的协议类型。与IPv6协议字段类似,下一个头字段可以用来指出高层是T C P还是U D P,但它也可以用来指明IPv6扩展头的存在。
跳极限。长度为8位。每当一个节点对包进行一次转发之后,这个字段就会被减1。如果该字段达到0,这个包就将被丢弃。IPv4中有一个具有类似功能的生存期字段,但与IPv4不同,人们不愿意在IPv6中由协议定义一个关于包生存时间的上限。这意味着对过
期包进行超时判断的功能可以由高层协议完成。
源地址。长度为1 2 8位,指出了IPv6包的发送方地址。
目的地址。长度为1 2 8位,指出了IPv6包的接收方地址。这个地址可以是一个单播、组播或任意点播地址。如果使用了选路扩展头(其中定义了一个包必须经过的特殊路由),其目的地址可以是其中某一个中间节点的地址而不必是最终地址。
图5 - 1中显示了IPv6头的格式。下一节中提供了IPv6头与IPv4头字段间更加详细的比较。

5.1.3 IPv4与IPv6的比较
先回顾一下图2 - 3中定义的IPv4头。尽管这些头字段中有一些与IPv6头类似,但其中真正完全保持不变的只有第一个字段,即版本字段,因为在同一条线路上传输时,必须保证IPv4和IPv6的兼容性。下一个字段,即包头长度,则与IPv6无关,因为IPv6头是固定长度, IPv4中需要这个字段是因为它的包头可能在2 0字节到4 0字节间变化。
服务类型字段与IPv6的流类别字段相似,但TO S的位置比该字段要靠后一些,而且在具体实现中也没有广泛应用。下一个字段是数据报长度,后来发展成了IPv6中的净荷长度。IPv6的净荷长度中包含了扩展头,而IPv4数据报长度字段中则指明包含包头在内的整个数据报的长度。这样一来,在IPv4中,路由器可以通过将数据报长度减去包头长度来计算包的净荷长度,而在IPv6中则无须这种计算。
后面的三个字段是数据报I D、分段标志和分段偏移值,它们都用于IPv4数据报的分段。由于IPv6中由源结点取代中间路由器来进行分段(后面将有更多关于分段的内容),这些字段在IPv6中变得不重要,并被IPv6从包头中去掉了。
而生存期字段,正如上面所述,变成了跳极限字段。生存期字段最初表示的是一个包穿越Internet时以秒为单位的存在时间的上限。如果生存期计数值变为0,该包将被丢弃。其原因是包可能会存在于循环路由中,如果没有方法让它消失,它可能会一直选路(或者直到网络崩溃为止)。在最初的规范中要求路由器根据转发包的时间与收到包的时间的差值(以秒为单位)来减小生存期的值。在实际情况中,大部分路由器都设计为每次对该值减1,而不是计算路由器上真正的处理时间。
协议字段,如前所述,指出在IPv4包中封装的高层协议类型。各协议对应的数值在最新版本的R F C (现在是RFC 1700)中可以查到。这个字段后来发展成为IPv6中的下一个头字段,其中定义了下一个头是一个扩展头字段还是另一层的协议头。
由于如T C P和U D P等高层协议均计算头的校验和, IPv4头校验显得有些多余,因此这个字段在IPv6中已消失。对于那些真的需要对内容进行身份验证的应用, IPv6中提供了身份验证头。
IPv6中仍然保留了3 2位的IPv4源地址和目的地址,但将它们扩展为1 2 8位。而IP选项字段则已经彻底消失,取而代之的是IPv6扩展头。
5.1.4 流标签
IPv4通常被描述为无连接协议。就像任何一个包交换网络一样, IPv4设计为让每个包找到自己的路径以到达其目的地。每个包都分别处理,而结果是两个从相同数据源发往相同目的地的包可以采用完全不同的路由来穿越整个网络。这对于适应网络突发事件来说是个好办法,因为突发事件意味着任何一条路由都可能在任何时间出现故障,但只要两主机间存在某些路由则可以进行数据的交互。
但是,这种方法的效率可能不太高,尤其是当包并不是孤立的,且实际上是两个通信系统间的业务流的一部分时。进一步考虑一个包流从一台主机发往另一主机时在它所经过的路径上将发生的事情:每个中间路由器对每个包的处理将导致在链路上轻微地增加延时。对于类似文件传输或终端仿真之类的大部分传统Internet应用,延时只会带来一点不方便而已,但对于一些提供互操作的音频和视频应用而言,即使只是增加一点点延时也会显著降低服务质量。
对每个IPv4包均进行单独处理带来的另一个问题在于难以把特定的业务流指定到较低代价的链路上。例如,电子邮件的传输优先级不高,并且不是实时应用,但IPv4网络管理员却没有简单的办法来标识这些包,把它们传输到较低开销的Internet链路,并为实时应用保留较高开销的链路。
IPv6中定义的流的概念将有助于解决类似问题。IPv6头字段中的流标签把单个包作为一系列源地址和目的地址相同的包流的一部分。同一个流中的所有包具有相同的流标签。
5.1.5 业务流类别
最早有关IPv6的R F C ( 1 8 8 3 )中定义了4位优先级字段,这意味着每个包可能具备1 6个优先级中的一个。但是,经过多次讨论后这个字段的名字改为"类别",且长度也扩大到了1字节。在最新的关于RFC 1883的Internet修订草案中,名字又被改为"业务流类别"
IPv6类别字段的数值及如何正确使用还有待定义。使用IPv4服务类型字段和使用IPv6类别的实验最终必将为此带来有用的结果。使用业务流类别的目的在于允许发送业务流的源节点和转发业务流的路由器在包上加上标记,并进行除默认处理方法之外的不同处理。一般来说,在所选择的链路上,可以根据开销、带宽、延时或其他特性而对包进行特殊的处理。
虽然在IPv6的实现中很可能需要并建议高层协议为它们的数据指定一个特定的业务流等级,但这些实现中可能也允许中间路由器根据实际情况修改这个值。
5.1.6 分段
IPv6的分段只能由源节点和目的节点进行,这样就简化了包头并减少了用于选路的开销。逐跳分段被认为是一种有害的方法。首先,它在端到端的分段中将产生更多的分段。此外在传输中,一个分段的丢失将导致所有分段重传。IPv6的确可以通过其扩展头来支持分段,但是如下所述,了解IPv4分段如何工作将有助于了解IPv6中为什么要进行改变。
在IPv4中,当一个没有分段的包由于太长而无法沿着发送源到目的地的网络链路进行传输时,就需要进行包的分段。举例来说,一个源节点可以创建一个长度为1 5 0 0字节的包,并把它向Internet上的某个远端目的地发送。这个包通过源节点的本地以太网到达该节点的默认路由器。然后路由器通过其链路把数据发到Internet上,这条链路可能是到一个I S P的点到点连接。在Internet中的某处或离目的节点较近的某处,可能有条网络链路无法处理这样一大块的数据。在这种情况下,使用该网络链路的路由器将不得不把1 5 0 0字节的数据报分割成许多不超过下一个网络的最大传输单元( MTU )的分段。因此,如果假设下一个链路可以处理的包长度不能超过1280 字节的话,路由器将把最初的一个包分割为两个。第一个包的长度为1 2 6 0字节,留下的2 0字节用于IPv4头。第二段的长度就是剩余数据的长度, 2 4 0字节,另外再用2 0字节作为另一个IPv4头。
IPv4中的分段由包沿途的中间路由器根据需要进行。进行分段的路由器根据需要修改包头并在其中包含进最初的包的数据报标识,同时还将正确地设置分段标志和分段偏移值。当目的节点收到由此产生的分段包之后,该系统必须根据每个分段包的IPv4头后的分段数据重组最初的包。
在使用了分段之后,不论中间的网络是什么类型,不同类型网络上的节点都可以互操作,源节点无需了解任何有关目的节点网络的信息,同时也无需了解它们之间的网络信息。这一直被认为是一个不错的特性,由于不需要节点或路由器存储信息或记录整个Internet的结构,从而Internet可以获得很好的扩展性。但另一方面,它也为路由器带来了性能方面的问题,对IP包进行分段消耗了沿途路由器和目的地的处理能力和时间。了解IP数据报标识、计算分段偏移值、真正把数据分段以及在目的地进行重装都会带来额外的开销。
问题在于对于任何一个指定的路由器,虽然源节点能够了解链路的MTU是多大,但却没有办法事先知道整个路径的MTU。路径MTU是源节点和目的节点之间在不分段时可以沿着该路由穿越任何网络的最大包长。
然而,目前有两种方法可以减少或消除对于分段的需求。第一种方法可用在IPv4中,它使用一种叫做"路径MTU发现"的方法。通过这种方法,路由器可以向目的地发送一个包来报告该路由器上链路的MTU值。如果包到达了一条必须对其进行分段的链路,负责分段的路由器将使用ICMP回送一个报文来指出分段路由器上链路的MTU值。这种过程可以重复进行直到路由器确定路径MTU为止。(后面将有对ICMP的进一步讨论。)
另一种减少分段需求的方法是要求所有支持IP的链路必须能够处理一些合理的最小长度的包。换句话说,如果一个链路的MTU超过2 0字节,那么所有的节点都必须准备产生可观数量的分段包。另一方面,如果能够提出所有网络链路都可以适应的某个合理的长度,并把它设置为允许包长度的绝对最小值,那么就可以消灭分段。
IPv6中实际上同时使用了上面两种方法。在最初的R F C中, IPv6规定每个链路支持的MTU最小为5 7 6字节。那么这些包的净荷长度将是5 3 6字节,另外4 0字节用于IPv6头。由于RFC 1883发表于1995年,后来产生了很多关于更大的MTU的争论。在H u i t e m a提出的报告(参见《IPv6:新的IP》第2版,P r e n t i c e - H a l l )中,建议值为1997,Steve Deering则正在促使将MTU值改为1 5 0 0字节。在最新的于1997年11月发表的Internet草案中, MTU值被设为1 2 8 0字节。很明显,关注的焦点在于:倡导较短MTU的人希望那些不能支持较长MTU的网络不会被完全丢弃,而倡导较长MTU的人不希望为照顾小部分接近于废弃的网络而使得整个Internet的性能下降。
为了对较短的MTU进行一些弥补, IPv6标准中强烈推荐所有IPv6节点都支持路径MTU发现。路径MTU发现最早出现在RFC 11 9 1中,其中使用了分段标志中的"不能分段"来要求中间路由器在发现包太长时返回一个ICMP出错报文。
路径MTU发现的IPv6版本在RFC 1981(IPv6的路径MTU发现)中描述。这是对原有的R F C 11 9 1的升级,但其中加入了一些改变使之可以工作在IPv6中。其中最重要的是,由于IPv6头中不支持分段,因此也就没有"不能分段"位。正在执行路径MTU发现的节点只是简单地在自己的网络链路上向目的地发送允许的最长包。如果一条中间链路无法处理该长度的包,尝试转发路径MTU发现包的路由器将向源节点回送一个ICMP v6出错报文。然后源节点将发送另一个较小的包。这个过程将一直重复,直到不再收到ICMP v6出错报文为止,然后源节点就可以使用最新的MTU作为路径MTU。
这里需要注意,有一些实例并没有实现路径MTU发现。例如,使用最小IPv6实现来进行远程网络启动的终端只是简单地使用5 7 6字节的路径MTU。从源节点到目的节点的IPv6分段,作为一个扩展头来实现,将在下一节中讨论。
5.1.7 扩展头
IPv4选项的问题在于改变了IP头的大小,因此更像一个"特例",即需要特别的处理。路由器必须优化其性能,这意味着将为最普遍的包进行最佳性能的优化。这使得IPv4选项引发一个路由器把包含该选项的包搁置一边,等到有时间的时候再进行处理。
IPv6中实现的扩展头可以消灭或至少大量减少选项带来的对性能的冲击。通过把选项从IP头中搬到净荷中,路由器可以像转发无选项包一样来转发包含选项的包。除了规定必须由每个转发路由器进行处理的逐跳选项之外, IPv6包中的选项对于中间路由器而言是不可见的。
可用的选项
除了减少IPv6包转发时选项的影响外, IPv6规范使得对于新的扩展和选项的定义变得更加简单。在需要的时候可能还会定义其他的选项和扩展。本节仅列出已定义的扩展,而对于扩展头和选项的使用在第7章中将有更详细的讨论,安全性头将在第9章讨论。RFC 1883中为IPv6 定义了如下选项扩展:
逐跳选项头。此扩展头必须紧随在IPv6头之后。它包含包所经路径上的每个节点都必须检查的选项数据。由于它需要每个中间路由器进行处理,逐跳选项只有在绝对必要的时候才会出现。到目前为止,已经定义了两个选项:巨型净荷选项和路由器提示选项。巨型净荷选项指明包的净荷长度超过IPv6的1 6位净荷长度字段。只要包的净荷超过65 535字节(其中包括逐跳选项头),就必须包含该选项。如果节点不能转发该包,则必须回送一个ICMP v6出错报文。路由器提示选项用来通知路由器, IPv6数据报中的信息希望能够得到中间路由器的查看和处理,即使这个包是发给其他某个节点的(例如,包含带宽预留协议信息的控制数据报)。
选路头。此扩展头指明包在到达目的地途中将经过哪些节点。它包含包沿途经过的各节点的地址列表。IPv6头的最初目的地址是路由头的一系列地址中的第一个地址,而不是包的最终目的地址。此地址对应的节点接收到该包之后,对IPv6头和选路头进行处理,
并把包发送到选路头列表中的第二个地址。如此继续,直到包到达其最终目的地。
分段头。此扩展头包含一个分段偏移值、一个"更多段"标志和一个标识符字段。用于源节点对长度超出源端和目的端路径MTU的包进行分段。
目的地选项头。此扩展头代替了IPv4选项字段。目前,唯一定义的目的地选项是在需要时把选项填充为6 4位的整数倍。此扩展头可以用来携带由目的地节点检查的信息。
身份验证头( A H )。此扩展头提供了一种机制,对IPv6头、扩展头和净荷的某些部分进行加密的校验和的计算。
封装安全性净荷( E S P )头。这是最后一个扩展头,不进行加密。它指明剩余的净荷已经加密,并为已获得授权的目的节点提供足够的解密信息。
5.2 ICMPv6
IP节点需要一个特殊的协议来交换报文以了解与IP相关的情况。ICMP正好适用于这种需求。在IPv4升级到IPv6的过程中, ICMP也经历了一定的修改。ICMP v6在RFC 1885中定义。ICMP报文可以用来报告错误和信息状态,以及类似于包的Internet探询( P i n g )和跟踪路由的功能。
IGMP一开始就包含在ICMP v6规范中,并且在1997年11月发表的RFC 2236中得到更新,1998年初秋,IGMP第3版也开始了讨论。IGMP可以用来支持组播传输,它为主机提供了向本地路由器报告其属于某个组播组的方法。
ICMPv6报文
ICMP报文的产生来源于一些错误情况。例如,如果一个路由器由于某些原因不能处理一个IP包,它就可能会产生某种类型的ICMP报文,并直接回送到包的源节点,然后源节点将采取一些办法来纠正所报告的错误状态。例如,如果路由器无法处理一个IP包的原因是由于包太长而无法将其发送到网络链路上,则路由器将产生一个ICMP错误报文来指出包太长,源节点在收到该报文后可以用它来确定一个更加合适的包长度,并通过一系列新的IP包来重新发送该数据。
RFC 1885中定义了以下报文类型(没有包括该文档中定义的有关组的报文):
目的地不可达。
包太长。
超时。
参数问题。
回声请求。
回声应答。
下面将详细介绍这些报文。
1. 目的地不可达
这个报文由路由器或源主机在由于除业务流拥塞之外的原因而无法转发一个包的时候产生。这种错误报文有五个代码,包括:
0:没有到达目的地的路由。这个报文在路由器没有定义IP包的目的地路由时产生,路由器将采用默认路由来发送无法利用路由器的路由表进行转发的包。
1:与目的地的通信被管理员禁止。当被禁止的某类业务流欲到达防火墙内部的一个主机时,包过滤防火墙将产生该报文。
2:不是邻居。当使用IPv6选路扩展头并严格限定路由时,将使用这个代码。当列表中的下一个目的地与当前正执行转发的节点不能共享一个网络链路时,将会产生该报文。
3:地址不可达。这个代码指出在把高层地址解析到链路层(网络)地址时遇到了一些问题,或者在目的地网络的链路层上去往其目的地时遇到了问题。
4:端口不可达。这种情况发生在高层协议(如D P )没有侦听包目的端口的业务量,且传输层协议又没有其他办法把这个问题通知源节点时。
2. 包太长
当接收某包的路由器由于包长度大于将要转发到的链路的MTU,而无法对其进行转发时,将会产生包太长报文。该ICMP v6错误报文中有一个字段指出导致该问题的链路的MTU值。在路径MTU发现过程中这是一个有用的错误报文。
3. 超时
当路由器收到一个跳极限为1的包时,它必须在转发该包之前减小这个数值。如果在路由器减小该数值后,跳极限字段的值变为0 (或者是路由器收到一个跳限制字段为0的包),那么路由器必须丢弃该包,并向源节点发送ICMP v6超时报文。源节点在收到该报文后,可以认为最初的跳限制设置得太小(包的真实路由比源节点想象的要长),也可以认为有一个选路循环导致包无法交付。
在"跟踪路由"功能中这个报文非常有用。这个功能使得一个节点可以标识一个包在从源节点到目的节点的路径上的所有路由器。它的工作方式如下:首先,一个去往目的地的包的跳极限被设置为1。它所到达的第一个路由器将跳减少极限,并回送一个超时报文,这样一来源节点就标识了路径上的第一个路由器。然后如果该包必须经过第二个路由器的话,源节点会再发送一个跳极限为2的包,该路由器将把跳极限减小到0,并产生另一个超时报文。这将持续到包最终到达其目的地为止。同时源节点也获得了从每个中间路由器发来的超时报文。
4. 参数问题
当IPv6头或扩展头中的某些部分有问题时,路由器由于无法处理该包而会将其丢弃。路由器的实现中应该可以产生一个ICMP参数错误报文来指出问题的类型(如错误的头字段、无法识别的下一个头类型或无法识别的IPv6选项),并通过一个指针值指出在第几个字节遇到这种错误情况。
5. ICMPv6回声功能
ICMP v6中包含了一个与错误情况无关的功能。所有IPv6节点都需要支持两种报文:回声请求和回声应答。回声请求报文可以向任何一个正确的IPv6地址发送,并在其中包含一个回声请求标识符、一个顺序号和一些数据。尽管二者都是可选项,但回声请求标识符和顺序号可以用来区分对应不同请求的响应。回声请求的数据也是一个选项,并可用于诊断。
当一个IPv6节点收到一个回声请求报文后,它必须回送一个回声应答报文。在应答中包含相同的请求标识符、顺序号和在最初的请求报文中携带的数据。
ICMP回声请求/应答报文对是ping功能的基础。ping是一个重要的诊断功能,因为它提供了一种方法来决定一个特定的主机是否与其他一些主机连接在相同的网络上。
本章第一小节描述了IPv6协议的基本框架并介绍了RFC 1883(IPv6技术规范)和其他后续标准(到1998年9月还没有分配R F C号码)中定义的IPv6头字段、选项和扩展。本章第二小节概述了RFC 1885( 用于IPv6的Internet控制报文协议( ICMP v6 )的技术规范)中定义的ICMP v6。IGMP v2在RFC 2236(Internet组管理协议第2版)中定义,并且与IPv4和IPv6均有关联。
IPv6的地址方案将在第6章中介绍,第7章对IPv6的选项和扩展头有更详细的介绍。第8章将探讨IPv6的选路。第9章将进一步讨论IPv6中的安全性和身份验证问题,第1 0章将介绍升级到IPv6对IP的上层和下层协议造成的影响。
5.1 IPv6
对IPv4的升级最早在两个R FC中进行了定义。RFC 1883中描述的是协议本身,而R F C 1 8 8 4介绍的是IPv6的地址结构。现在RFC 1884已经被RFC 2373所替代,1998年夏天I E T F批准了一个草案来替换RFC 1883。从3 2位地址到1 2 8位地址的变化代表了一个重大的转变,但如何制定和分配IPv6地址直到1998年秋天也没有定论。第6章将对于IPv6的地址有更详细的介绍。本节只介绍真正的IPv6协议中最重要的改变而不讨论地址细节。
5.1.1 变化概述
IPv6中的变化体现在以下五个重要方面:
扩展地址。
简化头格式。
增强对于扩展和选项的支持。
流标记。
身份验证和保密。
对于IP的这些改变对I A B于1991年制定的IPv6发展方向中的绝大部分都有所改进。IPv6的扩展地址意味着IP可以继续增长而无需考虑资源的匮乏,该地址结构对于提高路由效率有所帮助;对于包头的简化减少了路由器上所需的处理过程,从而提高了选路的效率;同时,改进对头扩展和选项的支持意味着可以在几乎不影响普通数据包和特殊包选路的前提下适应更多的特殊需求;流标记办法为更加高效地处理包流提供了一种机制,这种办法对于实时应用尤其有用;身份验证和保密方面的改进使得IPv6更加适用于那些要求对敏感信息和资源特别对待的商业应用。
1. 扩展地址
IPv6的地址结构中除了把3 2位地址空间扩展到了1 2 8位外,还对IP主机可能获得的不同类型地址作了一些调整。就像在第6章中将要详细介绍的一样, IPv6中取消了广播地址而代之以任意点播地址。IPv4中用于指定一个网络接口的单播地址和用于指定由一个或多个主机侦听的组播地址基本不变。
2. 简化的包头
IPv6中包括总长为4 0字节的8个字段(其中两个是源地址和目的地址)。它与IPv4包头的不同在于,IPv4中包含至少1 2个不同字段,且长度在没有选项时为2 0字节,但在包含选项时可达6 0字节。IPv6使用了固定格式的包头并减少了需要检查和处理的字段的数量,这将使得选路的效率更高。
包头的简化使得IP的某些工作方式发生了变化。一方面,所有包头长度统一,因此不再需要包头长度字段。此外,通过修改包分段的规则可以在包头中去掉一些字段。IPv6中的分段只能由源节点进行:该包所经过的中间路由器不能再进行任何分段。最后,去掉IP头校验和不会影响可靠性,这主要是因为头校验和将由更高层协议( U D P和T C P )负责。
3. 对扩展和选项支持的改进
在IPv4中可以在IP头的尾部加入选项,与此不同, IPv6中把选项加在单独的扩展头中。通过这种方法,选项头只有在必要的时候才需要检查和处理。下面和第7章将对此有更多的讨论。
为便于说明,考虑以下两种不同类型的扩展部分:分段头和选路头。IPv6中的分段只发生在源节点上,因此需要考虑分段扩展头的节点只有源节点和目的节点。源节点负责分段并创建扩展头,该扩展头将放在IPv6头和下一个高层协议头之间。目的节点接收该包并使用扩展头进行重装。所有中间节点都可以安全地忽略该分段扩展头,这样就提高了包选路的效率。
另一种选择方案中,逐跳( h o p - b y - h o p )选项扩展头要求包的路径上的每一个节点都处理该头字段。这种情况下,每个路由器必须在处理IPv6包头的同时也处理逐跳选项。第一个逐跳选项被定义用于超长IP包(巨型净荷)。包含巨型净荷的包需要受到特别对待,因为并不是所有链路都有能力处理那样长的传输单元,且路由器希望尽量避免把它们发送到不能处理的网络上。因此,这就需要在包经过的每个节点上都对选项进行检查。
4. 流
在IPv4中,对所有包大致同等对待,这意味着每个包都是由中间路由器按照自己的方式来处理的。路由器并不跟踪任意两台主机间发送的包,因此不能"记住"如何对将来的包进行处理。IPv6实现了流概念,其定义如RFC 1883中所述:
流指的是从一个特定源发向一个特定(单播或者是组播)目的地的包序列,源点希望中间路由器对这些包进行特殊处理。
路由器需要对流进行跟踪并保持一定的信息,这些信息在流中的每个包中都是不变的。这种方法使路由器可以对流中的包进行高效处理。对流中的包的处理可以与其他包不同,但无论如何,对于它们的处理更快,因为路由器无需对每个包头重新处理。下一节中将对流和流标记有更详细的讨论。
5. 身份验证和保密
RFC 1825(IP的安全性体系结构)描述了IP的安全性体系结构,包括IPv4和IPv6。它发表于在1995年8月,目前正在进行修改和更新。1998年3月发表了一个更新版Internet草案。IP安全性的基本结构仍然很坚固,且已经进行了一些显著的改变和补充。这个体系结构以及它在IPv6中如何实现,都将在第9章介绍。
IPv6使用了两种安全性扩展: IP身份验证头( A H )首先由RFC 1826(IP身份验证头)描述,而IP封装安全性净荷( E S P )首先在RFC 1827(IP封装安全性净荷( E S P ) )中描述。
报文摘要功能通过对包的安全可靠性的检查和计算来提供身份验证功能。发送方计算报文摘要并把结果插入到身份验证头中,接收方根据收到的报文摘要重新进行计算,并把计算结果与A H头中的数值进行比较。如果两个数值相等,接收方可以确认数据在传输过程中没有被改变;如果不相等,接受方可以推测出数据或者是在传输过程中遭到了破坏,或者是被某些人进行了故意的修改。
封装安全性提供机制,可以用来加密IP包的净荷,或者在加密整个IP包后以隧道方式在Internet上传输。其中的区别在于,如果只对包的净荷进行加密的话,包中的其他部分(包头)将公开传输。这意味着破译者可以由此确定发送主机和接收主机以及其他与该包相关的信息。使用E S P对IP进行隧道传输意味着对整个IP包进行加密,并由作为安全性网关操作的系统将其封装在另一IP包中。通过这种方法,被加密的IP包中的所有细节均被隐藏起来。这种技术是创建虚拟专用网( V P N )的基础,它允许各机构使用Internet作为其专用骨干网络来共享敏感信息。
5.1.2 包头结构
在IPv4中,所有包头以3 2位为单位,即基本的长度单位是4个字节。在IPv6中,包头以6 4位为单位,且包头的总长度是4 0字节。IPv6协议为对其包头定义了以下字段:
版本。长度为4位,对于IPv6,该字段必须为6。
类别。长度为8位,指明为该包提供了某种"区分服务"。RFC 1883中最初定义该字段只有4位,并命名为"优先级字段",后来该字段的名字改为"类别",在最新的IPv6 Internet草案中,称之为"业务流类别"。该字段的定义独立于IPv6,目前尚未在任何R F C中定义。该字段的默认值是全0。
流标签。长度为2 0位,用于标识属于同一业务流的包。一个节点可以同时作为多个业务流的发送源。流标签和源节点地址唯一标识了一个业务流。在RFC 1883中这个字段最初被设计为2 4位,但当类别字段的长度增加到8位后,流标签字段被迫减小长度来作补偿。
净荷长度。长度为1 6位,其中包括包净荷的字节长度,即IPv6头后的包中包含的字节数。这意味着在计算净荷长度时包含了IPv6扩展头的长度。
下一个头。这个字段指出了IPv6头后所跟的头字段中的协议类型。与IPv6协议字段类似,下一个头字段可以用来指出高层是T C P还是U D P,但它也可以用来指明IPv6扩展头的存在。
跳极限。长度为8位。每当一个节点对包进行一次转发之后,这个字段就会被减1。如果该字段达到0,这个包就将被丢弃。IPv4中有一个具有类似功能的生存期字段,但与IPv4不同,人们不愿意在IPv6中由协议定义一个关于包生存时间的上限。这意味着对过
期包进行超时判断的功能可以由高层协议完成。
源地址。长度为1 2 8位,指出了IPv6包的发送方地址。
目的地址。长度为1 2 8位,指出了IPv6包的接收方地址。这个地址可以是一个单播、组播或任意点播地址。如果使用了选路扩展头(其中定义了一个包必须经过的特殊路由),其目的地址可以是其中某一个中间节点的地址而不必是最终地址。
图5 - 1中显示了IPv6头的格式。下一节中提供了IPv6头与IPv4头字段间更加详细的比较。

5.1.3 IPv4与IPv6的比较
先回顾一下图2 - 3中定义的IPv4头。尽管这些头字段中有一些与IPv6头类似,但其中真正完全保持不变的只有第一个字段,即版本字段,因为在同一条线路上传输时,必须保证IPv4和IPv6的兼容性。下一个字段,即包头长度,则与IPv6无关,因为IPv6头是固定长度, IPv4中需要这个字段是因为它的包头可能在2 0字节到4 0字节间变化。
服务类型字段与IPv6的流类别字段相似,但TO S的位置比该字段要靠后一些,而且在具体实现中也没有广泛应用。下一个字段是数据报长度,后来发展成了IPv6中的净荷长度。IPv6的净荷长度中包含了扩展头,而IPv4数据报长度字段中则指明包含包头在内的整个数据报的长度。这样一来,在IPv4中,路由器可以通过将数据报长度减去包头长度来计算包的净荷长度,而在IPv6中则无须这种计算。
后面的三个字段是数据报I D、分段标志和分段偏移值,它们都用于IPv4数据报的分段。由于IPv6中由源结点取代中间路由器来进行分段(后面将有更多关于分段的内容),这些字段在IPv6中变得不重要,并被IPv6从包头中去掉了。
而生存期字段,正如上面所述,变成了跳极限字段。生存期字段最初表示的是一个包穿越Internet时以秒为单位的存在时间的上限。如果生存期计数值变为0,该包将被丢弃。其原因是包可能会存在于循环路由中,如果没有方法让它消失,它可能会一直选路(或者直到网络崩溃为止)。在最初的规范中要求路由器根据转发包的时间与收到包的时间的差值(以秒为单位)来减小生存期的值。在实际情况中,大部分路由器都设计为每次对该值减1,而不是计算路由器上真正的处理时间。
协议字段,如前所述,指出在IPv4包中封装的高层协议类型。各协议对应的数值在最新版本的R F C (现在是RFC 1700)中可以查到。这个字段后来发展成为IPv6中的下一个头字段,其中定义了下一个头是一个扩展头字段还是另一层的协议头。
由于如T C P和U D P等高层协议均计算头的校验和, IPv4头校验显得有些多余,因此这个字段在IPv6中已消失。对于那些真的需要对内容进行身份验证的应用, IPv6中提供了身份验证头。
IPv6中仍然保留了3 2位的IPv4源地址和目的地址,但将它们扩展为1 2 8位。而IP选项字段则已经彻底消失,取而代之的是IPv6扩展头。
5.1.4 流标签
IPv4通常被描述为无连接协议。就像任何一个包交换网络一样, IPv4设计为让每个包找到自己的路径以到达其目的地。每个包都分别处理,而结果是两个从相同数据源发往相同目的地的包可以采用完全不同的路由来穿越整个网络。这对于适应网络突发事件来说是个好办法,因为突发事件意味着任何一条路由都可能在任何时间出现故障,但只要两主机间存在某些路由则可以进行数据的交互。
但是,这种方法的效率可能不太高,尤其是当包并不是孤立的,且实际上是两个通信系统间的业务流的一部分时。进一步考虑一个包流从一台主机发往另一主机时在它所经过的路径上将发生的事情:每个中间路由器对每个包的处理将导致在链路上轻微地增加延时。对于类似文件传输或终端仿真之类的大部分传统Internet应用,延时只会带来一点不方便而已,但对于一些提供互操作的音频和视频应用而言,即使只是增加一点点延时也会显著降低服务质量。
对每个IPv4包均进行单独处理带来的另一个问题在于难以把特定的业务流指定到较低代价的链路上。例如,电子邮件的传输优先级不高,并且不是实时应用,但IPv4网络管理员却没有简单的办法来标识这些包,把它们传输到较低开销的Internet链路,并为实时应用保留较高开销的链路。
IPv6中定义的流的概念将有助于解决类似问题。IPv6头字段中的流标签把单个包作为一系列源地址和目的地址相同的包流的一部分。同一个流中的所有包具有相同的流标签。
5.1.5 业务流类别
最早有关IPv6的R F C ( 1 8 8 3 )中定义了4位优先级字段,这意味着每个包可能具备1 6个优先级中的一个。但是,经过多次讨论后这个字段的名字改为"类别",且长度也扩大到了1字节。在最新的关于RFC 1883的Internet修订草案中,名字又被改为"业务流类别"
IPv6类别字段的数值及如何正确使用还有待定义。使用IPv4服务类型字段和使用IPv6类别的实验最终必将为此带来有用的结果。使用业务流类别的目的在于允许发送业务流的源节点和转发业务流的路由器在包上加上标记,并进行除默认处理方法之外的不同处理。一般来说,在所选择的链路上,可以根据开销、带宽、延时或其他特性而对包进行特殊的处理。
虽然在IPv6的实现中很可能需要并建议高层协议为它们的数据指定一个特定的业务流等级,但这些实现中可能也允许中间路由器根据实际情况修改这个值。
5.1.6 分段
IPv6的分段只能由源节点和目的节点进行,这样就简化了包头并减少了用于选路的开销。逐跳分段被认为是一种有害的方法。首先,它在端到端的分段中将产生更多的分段。此外在传输中,一个分段的丢失将导致所有分段重传。IPv6的确可以通过其扩展头来支持分段,但是如下所述,了解IPv4分段如何工作将有助于了解IPv6中为什么要进行改变。
在IPv4中,当一个没有分段的包由于太长而无法沿着发送源到目的地的网络链路进行传输时,就需要进行包的分段。举例来说,一个源节点可以创建一个长度为1 5 0 0字节的包,并把它向Internet上的某个远端目的地发送。这个包通过源节点的本地以太网到达该节点的默认路由器。然后路由器通过其链路把数据发到Internet上,这条链路可能是到一个I S P的点到点连接。在Internet中的某处或离目的节点较近的某处,可能有条网络链路无法处理这样一大块的数据。在这种情况下,使用该网络链路的路由器将不得不把1 5 0 0字节的数据报分割成许多不超过下一个网络的最大传输单元( MTU )的分段。因此,如果假设下一个链路可以处理的包长度不能超过1280 字节的话,路由器将把最初的一个包分割为两个。第一个包的长度为1 2 6 0字节,留下的2 0字节用于IPv4头。第二段的长度就是剩余数据的长度, 2 4 0字节,另外再用2 0字节作为另一个IPv4头。
IPv4中的分段由包沿途的中间路由器根据需要进行。进行分段的路由器根据需要修改包头并在其中包含进最初的包的数据报标识,同时还将正确地设置分段标志和分段偏移值。当目的节点收到由此产生的分段包之后,该系统必须根据每个分段包的IPv4头后的分段数据重组最初的包。
在使用了分段之后,不论中间的网络是什么类型,不同类型网络上的节点都可以互操作,源节点无需了解任何有关目的节点网络的信息,同时也无需了解它们之间的网络信息。这一直被认为是一个不错的特性,由于不需要节点或路由器存储信息或记录整个Internet的结构,从而Internet可以获得很好的扩展性。但另一方面,它也为路由器带来了性能方面的问题,对IP包进行分段消耗了沿途路由器和目的地的处理能力和时间。了解IP数据报标识、计算分段偏移值、真正把数据分段以及在目的地进行重装都会带来额外的开销。
问题在于对于任何一个指定的路由器,虽然源节点能够了解链路的MTU是多大,但却没有办法事先知道整个路径的MTU。路径MTU是源节点和目的节点之间在不分段时可以沿着该路由穿越任何网络的最大包长。
然而,目前有两种方法可以减少或消除对于分段的需求。第一种方法可用在IPv4中,它使用一种叫做"路径MTU发现"的方法。通过这种方法,路由器可以向目的地发送一个包来报告该路由器上链路的MTU值。如果包到达了一条必须对其进行分段的链路,负责分段的路由器将使用ICMP回送一个报文来指出分段路由器上链路的MTU值。这种过程可以重复进行直到路由器确定路径MTU为止。(后面将有对ICMP的进一步讨论。)
另一种减少分段需求的方法是要求所有支持IP的链路必须能够处理一些合理的最小长度的包。换句话说,如果一个链路的MTU超过2 0字节,那么所有的节点都必须准备产生可观数量的分段包。另一方面,如果能够提出所有网络链路都可以适应的某个合理的长度,并把它设置为允许包长度的绝对最小值,那么就可以消灭分段。
IPv6中实际上同时使用了上面两种方法。在最初的R F C中, IPv6规定每个链路支持的MTU最小为5 7 6字节。那么这些包的净荷长度将是5 3 6字节,另外4 0字节用于IPv6头。由于RFC 1883发表于1995年,后来产生了很多关于更大的MTU的争论。在H u i t e m a提出的报告(参见《IPv6:新的IP》第2版,P r e n t i c e - H a l l )中,建议值为1997,Steve Deering则正在促使将MTU值改为1 5 0 0字节。在最新的于1997年11月发表的Internet草案中, MTU值被设为1 2 8 0字节。很明显,关注的焦点在于:倡导较短MTU的人希望那些不能支持较长MTU的网络不会被完全丢弃,而倡导较长MTU的人不希望为照顾小部分接近于废弃的网络而使得整个Internet的性能下降。
为了对较短的MTU进行一些弥补, IPv6标准中强烈推荐所有IPv6节点都支持路径MTU发现。路径MTU发现最早出现在RFC 11 9 1中,其中使用了分段标志中的"不能分段"来要求中间路由器在发现包太长时返回一个ICMP出错报文。
路径MTU发现的IPv6版本在RFC 1981(IPv6的路径MTU发现)中描述。这是对原有的R F C 11 9 1的升级,但其中加入了一些改变使之可以工作在IPv6中。其中最重要的是,由于IPv6头中不支持分段,因此也就没有"不能分段"位。正在执行路径MTU发现的节点只是简单地在自己的网络链路上向目的地发送允许的最长包。如果一条中间链路无法处理该长度的包,尝试转发路径MTU发现包的路由器将向源节点回送一个ICMP v6出错报文。然后源节点将发送另一个较小的包。这个过程将一直重复,直到不再收到ICMP v6出错报文为止,然后源节点就可以使用最新的MTU作为路径MTU。
这里需要注意,有一些实例并没有实现路径MTU发现。例如,使用最小IPv6实现来进行远程网络启动的终端只是简单地使用5 7 6字节的路径MTU。从源节点到目的节点的IPv6分段,作为一个扩展头来实现,将在下一节中讨论。
5.1.7 扩展头
IPv4选项的问题在于改变了IP头的大小,因此更像一个"特例",即需要特别的处理。路由器必须优化其性能,这意味着将为最普遍的包进行最佳性能的优化。这使得IPv4选项引发一个路由器把包含该选项的包搁置一边,等到有时间的时候再进行处理。
IPv6中实现的扩展头可以消灭或至少大量减少选项带来的对性能的冲击。通过把选项从IP头中搬到净荷中,路由器可以像转发无选项包一样来转发包含选项的包。除了规定必须由每个转发路由器进行处理的逐跳选项之外, IPv6包中的选项对于中间路由器而言是不可见的。
可用的选项
除了减少IPv6包转发时选项的影响外, IPv6规范使得对于新的扩展和选项的定义变得更加简单。在需要的时候可能还会定义其他的选项和扩展。本节仅列出已定义的扩展,而对于扩展头和选项的使用在第7章中将有更详细的讨论,安全性头将在第9章讨论。RFC 1883中为IPv6 定义了如下选项扩展:
逐跳选项头。此扩展头必须紧随在IPv6头之后。它包含包所经路径上的每个节点都必须检查的选项数据。由于它需要每个中间路由器进行处理,逐跳选项只有在绝对必要的时候才会出现。到目前为止,已经定义了两个选项:巨型净荷选项和路由器提示选项。巨型净荷选项指明包的净荷长度超过IPv6的1 6位净荷长度字段。只要包的净荷超过65 535字节(其中包括逐跳选项头),就必须包含该选项。如果节点不能转发该包,则必须回送一个ICMP v6出错报文。路由器提示选项用来通知路由器, IPv6数据报中的信息希望能够得到中间路由器的查看和处理,即使这个包是发给其他某个节点的(例如,包含带宽预留协议信息的控制数据报)。
选路头。此扩展头指明包在到达目的地途中将经过哪些节点。它包含包沿途经过的各节点的地址列表。IPv6头的最初目的地址是路由头的一系列地址中的第一个地址,而不是包的最终目的地址。此地址对应的节点接收到该包之后,对IPv6头和选路头进行处理,
并把包发送到选路头列表中的第二个地址。如此继续,直到包到达其最终目的地。
分段头。此扩展头包含一个分段偏移值、一个"更多段"标志和一个标识符字段。用于源节点对长度超出源端和目的端路径MTU的包进行分段。
目的地选项头。此扩展头代替了IPv4选项字段。目前,唯一定义的目的地选项是在需要时把选项填充为6 4位的整数倍。此扩展头可以用来携带由目的地节点检查的信息。
身份验证头( A H )。此扩展头提供了一种机制,对IPv6头、扩展头和净荷的某些部分进行加密的校验和的计算。
封装安全性净荷( E S P )头。这是最后一个扩展头,不进行加密。它指明剩余的净荷已经加密,并为已获得授权的目的节点提供足够的解密信息。
5.2 ICMPv6
IP节点需要一个特殊的协议来交换报文以了解与IP相关的情况。ICMP正好适用于这种需求。在IPv4升级到IPv6的过程中, ICMP也经历了一定的修改。ICMP v6在RFC 1885中定义。ICMP报文可以用来报告错误和信息状态,以及类似于包的Internet探询( P i n g )和跟踪路由的功能。
IGMP一开始就包含在ICMP v6规范中,并且在1997年11月发表的RFC 2236中得到更新,1998年初秋,IGMP第3版也开始了讨论。IGMP可以用来支持组播传输,它为主机提供了向本地路由器报告其属于某个组播组的方法。
ICMPv6报文
ICMP报文的产生来源于一些错误情况。例如,如果一个路由器由于某些原因不能处理一个IP包,它就可能会产生某种类型的ICMP报文,并直接回送到包的源节点,然后源节点将采取一些办法来纠正所报告的错误状态。例如,如果路由器无法处理一个IP包的原因是由于包太长而无法将其发送到网络链路上,则路由器将产生一个ICMP错误报文来指出包太长,源节点在收到该报文后可以用它来确定一个更加合适的包长度,并通过一系列新的IP包来重新发送该数据。
RFC 1885中定义了以下报文类型(没有包括该文档中定义的有关组的报文):
目的地不可达。
包太长。
超时。
参数问题。
回声请求。
回声应答。
下面将详细介绍这些报文。
1. 目的地不可达
这个报文由路由器或源主机在由于除业务流拥塞之外的原因而无法转发一个包的时候产生。这种错误报文有五个代码,包括:
0:没有到达目的地的路由。这个报文在路由器没有定义IP包的目的地路由时产生,路由器将采用默认路由来发送无法利用路由器的路由表进行转发的包。
1:与目的地的通信被管理员禁止。当被禁止的某类业务流欲到达防火墙内部的一个主机时,包过滤防火墙将产生该报文。
2:不是邻居。当使用IPv6选路扩展头并严格限定路由时,将使用这个代码。当列表中的下一个目的地与当前正执行转发的节点不能共享一个网络链路时,将会产生该报文。
3:地址不可达。这个代码指出在把高层地址解析到链路层(网络)地址时遇到了一些问题,或者在目的地网络的链路层上去往其目的地时遇到了问题。
4:端口不可达。这种情况发生在高层协议(如D P )没有侦听包目的端口的业务量,且传输层协议又没有其他办法把这个问题通知源节点时。
2. 包太长
当接收某包的路由器由于包长度大于将要转发到的链路的MTU,而无法对其进行转发时,将会产生包太长报文。该ICMP v6错误报文中有一个字段指出导致该问题的链路的MTU值。在路径MTU发现过程中这是一个有用的错误报文。
3. 超时
当路由器收到一个跳极限为1的包时,它必须在转发该包之前减小这个数值。如果在路由器减小该数值后,跳极限字段的值变为0 (或者是路由器收到一个跳限制字段为0的包),那么路由器必须丢弃该包,并向源节点发送ICMP v6超时报文。源节点在收到该报文后,可以认为最初的跳限制设置得太小(包的真实路由比源节点想象的要长),也可以认为有一个选路循环导致包无法交付。
在"跟踪路由"功能中这个报文非常有用。这个功能使得一个节点可以标识一个包在从源节点到目的节点的路径上的所有路由器。它的工作方式如下:首先,一个去往目的地的包的跳极限被设置为1。它所到达的第一个路由器将跳减少极限,并回送一个超时报文,这样一来源节点就标识了路径上的第一个路由器。然后如果该包必须经过第二个路由器的话,源节点会再发送一个跳极限为2的包,该路由器将把跳极限减小到0,并产生另一个超时报文。这将持续到包最终到达其目的地为止。同时源节点也获得了从每个中间路由器发来的超时报文。
4. 参数问题
当IPv6头或扩展头中的某些部分有问题时,路由器由于无法处理该包而会将其丢弃。路由器的实现中应该可以产生一个ICMP参数错误报文来指出问题的类型(如错误的头字段、无法识别的下一个头类型或无法识别的IPv6选项),并通过一个指针值指出在第几个字节遇到这种错误情况。
5. ICMPv6回声功能
ICMP v6中包含了一个与错误情况无关的功能。所有IPv6节点都需要支持两种报文:回声请求和回声应答。回声请求报文可以向任何一个正确的IPv6地址发送,并在其中包含一个回声请求标识符、一个顺序号和一些数据。尽管二者都是可选项,但回声请求标识符和顺序号可以用来区分对应不同请求的响应。回声请求的数据也是一个选项,并可用于诊断。
当一个IPv6节点收到一个回声请求报文后,它必须回送一个回声应答报文。在应答中包含相同的请求标识符、顺序号和在最初的请求报文中携带的数据。
ICMP回声请求/应答报文对是ping功能的基础。ping是一个重要的诊断功能,因为它提供了一种方法来决定一个特定的主机是否与其他一些主机连接在相同的网络上。
- 富士通IDT搜索加速器用于下一代光网络平台(05-20)
- 28nm异构知识型处理器NLA12000以最低功耗支持IPv6(01-28)
- 移动IPv6与移动IPv4技术优势比较(01-08)
- IPv6的最新应用(01-08)
- IPv6无状态地址自动配置机制分析(01-10)
- IPv6协议隧道方法(01-16)
闂備浇顕х换鎰崲閹邦喒鍋撳顐㈠祮闁靛棗鍊块幊婊堟偨绾版ɑ鐏冮梻浣筋潐瀹曟ḿ浜稿▎鎾村仭鐟滅増甯楅悡鏇㈡煃閸濆嫬鏋ら柡鈧悧鍫涗簻闁哄倸鐏濋顓犫偓娈垮櫘閸嬪嫰鍩㈡惔銊ョ闁哄啠鍋撻柣鎾跺█濮婅櫣鎲撮崟顏囧焻闂佸憡鏌ㄧ换鎰版偩閻戣姤鏅搁柨鐕傛嫹
- 婵犲痉鏉库偓鏇㈠磹閻熸壆骞撻柟绋垮瘨濞堜粙鏌涢妷銏℃珒闁绘帒锕弻娑㈠即閵娿儳浼囬梺鍝勬閸庢娊鍩€椤掑喚娼愰柟顔肩埣瀹曟洟骞庨挊澶屽幒闂佸吋绁撮弲婊堝汲濠婂牊鐓曟い鎰剁悼缁犳捇鏌熼纰卞剶闁哄瞼鍠撻埀顒佺⊕閿氬┑顔兼喘閺岋綁骞樼憴鍕€婇梺鐟板槻椤戝銆佸鈧幃銏ゅ川婵犲嫭娈紓鍌氬€风粈渚€顢栭崨鎼晞闁告稒鐣埀顒€鍟オ浼村川椤斿吋娅濋梻浣芥硶閸o箓骞忛敓锟�
闂傚倷鑳舵灙缂佽鐗撳畷婵嗩吋婢跺﹨鎽曢梺缁樻煥閹测剝鍒婄€电硶鍋撻獮鍨姎闁瑰嘲顑夊畷婵嬪川椤撴稒顫嶉梺鍝勫暙閸婄ǹ鐡梻浣圭湽閸斿孩鎱ㄩ悽鍛婃櫖闁圭増婢樼粻锝嗙節婵犲倹鍣介柟鍐叉处缁绘盯骞嬮悙鏉戦瀺濠殿喗菧閸旀垿骞冮敓鐘虫櫖闁告洦鍓欓悵浼存⒑缁洘顫婇柛妯哄⒔缁牊寰勯幇顓犲幍缂傚倷鐒﹂敋濠殿喖娲ㄩ埀顒冾潐濞叉牠鎯岄崒鐐茬畾鐎广儱顦Λ姗€鏌涢…鎴濇灓鐎光偓濞戙垺鍊甸悷娆忓閸嬬娀鏌涙惔銏狀棆缂佽京鍋ゅ顕€宕奸悢閿嬬暠闂備浇濮ら敋妞わ富鍨堕敐鐐哄籍閸喓鍙嗗┑鐐村灦鏋悗姘緲閳规垿顢氶崨顒勫仐濡ょ姷鍋涢崯瀛樹繆閹间礁唯闁挎洍鍋撴繛鎾村姍濮婄粯绗熼崶褌绨介梺鍝ュУ閸旀瑥鐣烽悷閭︽僵闁煎摜顣介幏瑙勭節閵忥絽鐓愰柣鈩冩礈缁牏鈧綆鈧垹缍婂畷妤呭锤濮樿京绐楁俊鐐€ら崑鍕箠濮椻偓楠炲棝宕橀鑲╊槹濡炪倖鍔戦崐鏍敊韫囨柧绻嗘い鎰╁€曢。濂告煕閵娿儳浠涢悗闈涖偢楠炲洭顢欓崜褏鍘梺璇插嚱缂嶅棙绂嶉悙鐑樺仭闁跨噦鎷�...
- 婵犵數鍋為崹鍫曞箹閳哄懎鍌ㄩ柣鎰靛墻濞堜粙鏌涢妷銏℃珒闁绘帒锕弻娑㈠即閵娿儳浼囬梺鍝勬閸庢娊鍩€椤掑喚娼愰柟顔肩埣瀹曟洟骞庨挊澶屽幒闂佸吋绁撮弲婊堝汲濠婂牊鐓曟い鎰剁悼缁犳捇鏌熼纰卞剶闁哄瞼鍠撻埀顒佺⊕閿氬┑顔兼喘閺岋綁骞樼憴鍕€婇梺鐟板槻椤戝銆佸鈧幃銏ゅ川婵犲嫭娈紓鍌氬€风粈渚€顢栭崨鎼晞闁告稒鐣埀顒€鍟オ浼村川椤斿吋娅濋梻浣芥硶閸o箓骞忛敓锟�
缂傚倸鍊风欢锟犲闯閿濆洨涓嶉柡宥庡幖閻掑灚銇勯幒鎴敾閻庢熬鎷�30婵犵數濮伴崹濂稿春閺嵮呮殕缂佸顕冲☉銏╂晢闁稿本鐟ч崜銊╂⒑閸涘﹥澶勯柛銊ャ偢瀵娊濡烽埡鍌滃幈闂佸啿鎼崰姘跺绩閻楀牄浜滈柡鍌氱仢椤忣偊鏌熸搴♀枅鐎规洘绮忛ˇ顕€鏌$仦璇测偓婵嬪蓟閵娿儮妲堟俊顖欒濞堫厾绱撴担璇℃畷闁规悂绠栭崺鈧い鎺戝亞閺€浼存煕閳哄倻澧い鏂跨箳閹瑰嫰濡搁敃鈧悵浼存⒑鐟欏嫬鍔ら柟铏姉缁牊寰勯幇顓犲幈闂佸搫鍊婚崕銈呪枍閸涱喓浜滈柟鐑樻煥閺嬫稓鈧娲忛崝宀冪亽闂佺粯鍨堕敋婵炴挻鍔欏缁樼瑹閸パ傜敖闂佸摜濮靛ú鐔肩嵁閹炬椿鏁傞柛顐g箘椤︻偅淇婇锔绘殥闁煎啿鐖奸、鏃堝础閻愨晜顫嶉梺鐟扮仢閸熲晝鑺辨繝姘厵妞ゆ柨銈搁崣鍕偓娈垮枙缁瑩骞冮埄鍐╁劅闁挎繂妫崯鍛攽閳藉棗浜炲褎顨婂畷褰掑垂椤愩埄鍤ら梺褰掑亰閸犳岸鎯屽▎鎾村€甸柨婵嗙凹缁ㄤ粙鏌i悢鐑藉弰闁哄矉缍佹俊鎼佸Ψ閵夘喕绱撴俊鐐€愰弲顏嗙不閹寸偞娅忛梻浣芥硶閸o箓骞忛敓锟�...
- Agilent ADS 闂傚倷娴囧銊╂倿閿曞倹鍋¢柕澶嗘櫓閺佸棝鏌i弮鍌氬付闁哄嫨鍎抽惀顏堫敇閻愭潙顎涢梺鍝ュ仦閻擄繝骞冭ぐ鎺戠倞鐟滃秹鍩涢弮鍫熺厓閻犲洦褰冮幃鎴犵磼妤︽寧顥夐摶鏍煕閺囩偟浠涙い銉嫹
婵犵數鍋為崹鍫曞箰婵犳艾绠伴柟闂寸贰閺佸﹦鈧箍鍎遍ˇ顖滅不閹惰姤鐓曟い鎰靛墰缁夌敻鏌涢妶蹇曠暤闁哄被鍔岄埥澶娢熼崹顕呬純闂備礁鎲¢悷銉ф崲濡綍娑㈠礃椤旂⒈娼婇梺鎸庣箓妤犳悂寮總鍛婄厽闁绘柨鎽滈幊鎰版煛鐎n亜鍓⊿闂傚倷绀侀幉锟犳嚌閸撗€鍋撳鐓庢珝闁挎繄鍋ら獮鎺懳旈埀顒傜矆婢舵劖鐓熼柡鍐ㄦ祩閸ゆ瑩鏌涘Ο缁樺唉闁哄本绋戦オ浼村礃椤撶儐浼冨┑鐐存綑閸氬宕濆Δ鍐ㄥ灊婵炲棙鍨熼崑鎾绘晲鎼存繄鏁栭柣搴f嚀椤︾敻寮婚敐澶婎潊闁冲搫鍟敮銊х磽娓氣偓娴滆埖绂嶇捄铏规殾婵犻潧顑呴悡娑㈡煕鐏炲墽鐓柟鏌ョ畺濮婃椽鎮滈埡浣峰闂佸憡鏌ㄧ粔鎾Υ閹烘閱囬柡鍥╁枎閸撶懓顪冮妶鍡樺暗濠殿喚鏁婚幃楣冩焼瀹ュ棛鍘搁梺鍛婂姂閸斿酣宕洪敐鍡曠箚妞ゆ劑鍎茬涵鍫曟煃瑜滈崜姘跺礃閼姐倗纾芥慨妯块哺椤洟鏌h閹哥ù...
- HFSS闂備浇顕х€涒晠宕橀懡銈囩=婵ê宕慨顒勬煕閺囥劌鐏犻柡鍕╁劤閻ヮ亪顢橀悙鏉戭€涢梺鍝ュ仦閻擄繝骞冭ぐ鎺戠倞鐟滃秹鍩涢弮鍫熺厓閻犲洦褰冮幃鎴犵磼妤︽寧顥夐摶鏍煕閺囩偟浠涙い銉嫹
闂備浇宕垫慨宥夊礃椤垳鐥紓鍌欐祰椤斿﹪鎮為敂鍓х煓濠㈣埖鍔曠粻濠氭煙妫颁胶顦﹂柡鍛懇濮婃椽鎮烽悧鍫熷創闂佺粯顨嗛崝娆撱€佸璺虹闁兼亽鍎插▍鏍煟韫囨洖浠╂俊顐㈠椤曪綁宕稿Δ浣叉嫽闂佸壊鍋呯粙鎴︽倶鏉堛劊浜滈柡鍌涱儥濡偓濡ょ姷鍋炵敮鈥崇暦瀹勬壋鏋庣紒鍌楀◢闂傚倷鐒﹂惇褰掑礉瀹€鈧埀顒佸嚬閸撴岸骞堥妸銉㈡闁靛繆鈧櫕鐣遍梻浣藉Г閿氭い锔藉閳ь剚纰嶉悡锟犵嵁閺嶎偀鍋撳☉娅虫垿鍩涢幒妤佺厸濞达綁娼ч埀顒佺箞瀵偄顓奸崶锔藉媰闂佽姤锚椤﹂亶鎯勬惔銊︹拺闁告稑锕ラ悡娑㈡煛閸涱喚鐭掔€规洘鍨甸鍏煎緞婵犲嫷妲梻渚€娼ц墝闁哄懏绮岄々濂稿Ω瑜忕壕鍏笺亜閺嶃劎绠撻柛姘贡缁辨帡顢欓懞銉d虎閻庤娲滈崗妯侯嚕鐠鸿 鏋庨柟顖嗗吘銈呪攽閻愭潙鐏︽慨濠勭帛閹便劑鎮介崹顐f婵犮垼鍩栭崝鏇犵不閸偁浜滈柍銉﹀▕閺佺寗S...
- CST闂佽娴烽弫濠氬磻婵犲洤绐楁俊銈呭暕閻掑﹥绻濋棃娑欙紞闁哥喎鎳橀弻鏇熷緞閸績鍋撳Δ鍐煓濠电姴娲﹂崐鍨殽閻愯尙浠㈤柍褜鍓氬ú鐔煎箖閿涘嫭宕夐柕濠忕畱椤庢稑顪冮妶鍡樺暗闁哥姵鍔曢埢鎾崇暆閳ь剛妲愰幒鏂哄亾閿濆簼鎲鹃柛搴$箲閵囧嫰濡搁敂鍓х厒闂佺懓寮堕〃濠囧极閹剧粯鏅搁柨鐕傛嫹
闂傚倷绀侀幖顐λ囬婧惧亾濞戞帗娅呴崡閬嶆煙鐎涙ḿ璐╅柧蹇撳帨閸嬫捇鏁愰崒娑欑彅闂佷紮闄勭划鎾诲箖鐟欏嫭濯寸紒娑橆儏濞堟繄绱撴担浠嬪摵缂佽鐗嗛悾宄拔旈崨顓団晠鏌嶉崫鍕偓褰掑Υ閸愵喗鐓熼柣妯夸含椤︼妇鈧鍠涘▔娑㈩敊韫囨洘顐界紓宥囨寙闂傚倷绀侀幉锟犳嚌閸撗€鍋撳顐㈠祮濠碘剝娼欓鍏煎緞婵犲嫷妲烽梻浣虹帛濡線顢氳瀹曘垽骞橀鐣屽幈濠电姴锕ら崯宕団偓姘緲闇夐柛蹇曞帶婵绱掗鐣屾噮闁逞屽墾缂嶅棙绂嶉悙纰樺亾閻熼偊妯€闁哄矉缍佹慨鈧柍鍝勫暙鐢劎绱撴担浠嬪摵缂佽鐗嗛悾宄扳攽鐎n亞鍘搁梺绋挎湰閻噣骞夋ィ鍐╊棅妞ゆ劑鍨虹粊鈺呮煕鐎n亷韬柛鈹惧亾濡炪倖甯掗崐鎼佸几濞嗘挻鐓曢柕鍫濇閻矂鏌嶈閸撴岸宕樻繝姘挃闁告洦鍘介弳婊冾熆閼搁潧濮囩紒鐘茬仛閵囧嫰鍨鹃幇浣规櫖T闂備浇宕垫慨鎶芥倿閿曗偓閻e嘲顫滈埀顒勩€佸鈧畷銊︾節閸愩劌濡抽梻浣告惈閸燁偊宕愯ぐ鎺戞辈闁跨噦鎷�...
- 闂備浇顕х换鎰崲閹邦喒鍋撳顐㈠祮闁靛棗鍊垮畷濂稿即閻愬瓨袣闂備焦鍎崇换妤咁敋閺嶎厼缁╅柕濞炬櫆閻撴洟鏌嶉崫鍕灓闁衡偓閻楀牄浜滈柡鍌氱仢椤忣偊鏌熸搴♀枅鐎规洘绮忛ˇ顕€鏌″畝瀣
婵犵數鍋為崹鍫曞箰缁嬫5娲晲閸モ晝鐣堕梺閫炲苯澧摶鏍煕鐏炵偓鍎洪柟杈剧畱鍥存繝闈涘€搁幗婊冪暤娓氣偓閺屾盯骞囬鈧痪褔鏌涢弴銏㈢暫闁诡喚顢婇ˇ鏌ユ煕閵堝棛澧辨俊鍙夊姇閳规垿宕堕妸銈嗗攭婵犵數鍋涘Λ妤€霉閻戣棄鍙婇柛宀€鍋為崑锝夋煕閵夋垵鍟犻幐鍐⒑鐎圭媭鍤欓柛姘儑缁瑦寰勭€n偄顫¢梺瑙勵問閸犳岸鍩ユ径鎰拺闂傚牃鏅炵粈瀣煕閺傝法鐒搁柟顖氬暣閹晝绮甸崷顓犵厬闂備胶鎳撻顓㈠磻濞戞粎浜i梻鍌欑閹碱偊鎮у⿰鍫濆瀭闁割偅娲忛埀顒€鍊块、鏇㈡晝閳ь剟寮伴妷鈺傜厽闁哄啠鍋撻柣蹇旂缁傚秹鏁愭径瀣偓鍫曟煟閹邦剛鎽犵紒鈧崘顔藉€垫慨妯块哺閺嗩剟鏌熼搹顐€顏堬綖濠靛绀堢憸蹇浰囬鈧娲偡閹殿喕绮甸梺瑙勬倐椤ユ挾鍒掗銏犲窛闁哄鍨块弫婊冣攽椤旀枻渚涢柛鎾寸洴瀵埖绂掔€n偆鍘介梺闈浨归崕閬嶎敂瑜忕槐鎺懳旀担鐟伴瀺缂備礁顑呴ˇ顖烇綖濠靛鏁嗛柛灞剧閺嗗繒绱撴担楦挎闁告ɑ鎮傚畷鎴︽晸閿燂拷...
- 闂佽娴烽弫濠氬磻婵犲洤绐楁俊銈呭暕閻掑﹥绻濋棃娑氬闁绘帒锕弻娑㈠即閵娿儳浼囬梺鍝勬閸庤尙鎹㈠☉銏犵骇闁规惌鍘奸崜鍫曟⒑闂堚晝绋绘俊鐐扮矙閻涱喖鈻庤箛锝呮倯闂佸憡娲﹂崢楣冨煝閺囥垺鈷戠紒顖涙礃濞呭洦銇勯姀鐙呰含妞ゃ垺鐟╁畷鐔碱敇閻旈褰撮梻浣告啞閹稿棝鍩€椤掑嫬钃熼柕鍫濐槹閻撴洘鎱ㄥ鍡楀濠⒀嶉檮缁绘稒寰勫☉娆忣伓
闂備浇宕垫慨鐢稿礉閿曞倸鍌ㄦ繛宸簻缁狀垶姊洪鈧粔瀵告喆閿曞倹鐓曟い鎰Т閸旀粓鏌ら懠顒€鈻堥柡宀嬬節瀹曞爼濡搁敂鍓р枏闂備焦鐪归崐鏇犫偓姘嵆閻涱噣宕卞☉娆忎杭闂佸憡渚楅崹鎶剿囬鍓х=闁稿本鑹鹃弳鐐烘煕閵娧勬毈鐎规洝顫夐幆鏃堝Ω閵夊簺鍎遍妴鎺戭潩閿濆懍澹曟俊鐐€х徊鑺ユ櫠鎼淬劌绠い鎰剁畱閻淇婇姘儓缁炬儳娼″娲濞戞瑯妫涢梺鐓庡暱閻栧吋淇婇棃娑辨僵妞ゆ垼濮ら悘鍐⒑闂堟稓绠冲┑顔炬暬閹敻濡舵径瀣帾闂佺硶鍓濆ú姗€藝瀹勬墥搴ㄥ炊瑜濋煬顒傗偓瑙勬穿缂嶄線寮婚妸褉鍋撻敐搴″闁糕晛绉瑰娲箰鎼达絺妲堥梺鍝勭墱閸撶喎鐣烽悷鎵冲牚闁告侗鍠栭弳顐g箾鏉堝墽鍒版繝鈧潏銊х彾濠㈣埖鍔栭悡娑氣偓骞垮劚椤﹁棄螞閹寸姷纾奸柕濞垮劜閸嬨儵鏌$仦鑺ュ殗闁轰焦鎹囬弫鎾绘晸閿燂拷...
- 婵犵數濮伴崹褰掓倶閸儱鐤炬繝闈涱儏閸氬綊骞栫划瑙勵潑闁哥喎鎳橀弻鏇熺珶椤栨浜鹃梺鍝勮閸婃繈骞冩禒瀣垫晬婵ê宕。娲⒑缂佹ɑ宕勬繛澶嬫礋楠炲繒鈧綆鍣弫鍥煃閽樺顥滄繛鍫濆⒔缁辨挻鎷呴崜鎻掑壈濡炪倖鍨甸幊姗€濡撮崘銊㈠牚闁告侗鍠栭弲鎶芥⒑鐠恒劌娅愰柟鍑ゆ嫹
闂傚倷鑳舵灙缂佽鐗撳畷婵嬪箣濠典胶绱伴梺瑙勵問閸犳宕伴崱娑欑叆婵犻潧妫欓ˉ鐘绘煃瑜滈崜婵囨叏閵堝拋鍤楅柛鏇ㄥ灠閻撴盯鏌涢幇鈺佸闁汇倕娲弻锝夋偐鏉堚晛濡介悗瑙勬礃閿曘垽銆佸鈧獮鏍ㄦ媴閻熼鍝楅梻浣虹《閸撴繈宕欒ぐ鎺戠柈闁割偁鍎查悡鏇熺節婵犲倸鏆㈤悗姘嵆閺屾洟宕惰濡叉椽鏌i妷顔婚偗闁硅櫕顨婇、娑㈡晲閸涱喗鐝梻浣藉吹婵磭鎷嬮弻銉ョ劦妞ゆ巻鍋撶痪缁㈠弮瀵爼鎸婃竟婵嗙秺閺佹劙宕卞▎鎴濈缂傚倷娴囨ご鍝ユ崲閸繄鏆︽繝闈涱儏閻撴盯鏌嶈閸撴稓妲愰悙鍙傜喓鎹勯妸褎婢戞俊鐐€栭崝褔鎳欒ぐ鎺戠;闁瑰墽绮崑鍕磼鐎n厽纭跺ù婊愮秮濮婂宕掑Δ鈧禍鐐節閵忥絽鐓愰柣鈩冩礈缁牏鈧綆浜栧Σ鍫ユ煙缂併垹鐏犲ù婊堢畺濮婃椽宕ㄦ繝鍛棟缂備礁顦壕顓炍i幇閭︽晣闁绘ḿ鏁搁悡瀣⒑闁偛鑻晶鎾煙椤栨艾鏆g€规洜鍠栭、鏇㈡偐閸楃偛姣愮紓鍌氬€烽悞锕€鐣峰鈧畷鏇熺節濮樺吋鏅╅梺鍝勬川婵灚鍒婃總鍛婄厓闁靛鍎辩敮鐘电磼閹插鎮肩紒杈ㄥ笧閳ь剨缍嗘禍鍫曞磿韫囨洜纾兼俊鐐额嚙娴滐拷...
- 闂傚倷绀佺紞濠傖缚瑜旈、鏍幢濡炵粯鏁犻梺閫炲苯澧い顓炴健瀹曠懓鈽夊▎鎰絿闂備焦鎮堕崐鏇灻归悜钘夌閻庯綆鍠栫粻鏌ユ煙娴煎瓨娑ч柟顔荤窔濮婅櫣鍖栭弴鐔哥彇濡炪們鍨归敃顏堛€佸▎鎾崇妞ゆ牗纰嶉悗顒€鈹戦悙鍙夘棡闁搞劎鍠栧濠氭晸閿燂拷
闂傚倷鑳舵灙缂佽鐗撳畷婵嬪箣濠典胶绱伴梺瑙勵問閸犳鍒婃總鍛婄厾闁兼祴鏅濈粈瀣煙閻戞﹩娈旂紒鐘劦閹鏁愭惔鈥茬凹缂備降鍔嶉懝楣冣€﹂崸妤€鍨傛繛鎴炵懄閻濇牠姊洪幖鐐测偓鏇灻归悜钘夌閻庯綆鍠栫粻鏌ユ煙娴煎瓨娑ч柟顔荤窔濮婃椽宕ㄦ繝鍕厐闂佸吋妞块崹铏閹间緡鏁嬮柍褜鍓熷缁樼節閸屻倕鎮戦梺鎼炲劘閸斿秴袙閸曨垱鐓熼柣妯跨簿椤掔喖鏌涢妸褎鏆い銏$懇瀵挳鎮╅崘宸偓娑㈡⒑鐎圭姵顥夐柟铏姉缁牊寰勬繛銏℃瀹曟帒霉椤掍礁鐏╃紒顔规櫊閹筹繝濡堕崱妤佺€梻浣虹《閸撴繃绗熷Δ鍛辈闁靛鏅滈悡蹇涙煕閳╁啯绀冩い锕傤棑缁辨帒螖娴g懓鏆楅梺閫炲苯澧版い銏狅躬瀹曟椽寮借閸熷懘鎮归幁鎺戝閻庢碍鑹捐彁闁搞儯鍔岄。鎶芥煕鐎n偅灏伴柟宄版嚇瀹曨偊濡烽敂鐣岄拻婵犵數鍋為幐濠氭嚌妤e喚鏁勯柛顐犲労閺佸﹤顭跨捄鐑樻拱闁哥姴妫濋弻銊モ攽閸℃娈滈梺绋款儐閹稿骞忛崨瀛樺€绘俊顖滃帶閸ら亶姊洪懡銈呮瀾闁荤喆鍎靛畷鎰版偡閹锋棑绲借灃闁告劧绲芥禍鐐箾閹达絾鐝悗姘炬嫹...
栏目分类