大家好,欢迎来到IT知识分享网。
4.1 ICMPv6基本概念
ICMPv6消息分为两类:一类为差错消息;另一类为信息消息。
差错消息用于报告在报文转发过程中出现的错误。常见的ICMPv6的差错消息包括目标不可达(Destination Unreachable)、数据报文超长(Packet Too Big)、超时 (Time Exceeded) 和参数问题(Parameter Problem )。
信息消息提供诊断功能和附加的主机功能,比如组播侦听发现(MLD)和邻居发现。常见的 ICMPv6信息消息主要包括回送请求(Echo Request)和回送应答(Echo Reply)。
如图 4‑1 ICMPv6报文结构所示。
图 4‑1 ICMPv6报文结构
ICMPv6差错消息的8位类型字段中的最高位都为0;而ICMPv6信息消息的8 位类型字段的最髙位都为1。因此ICMPv6差错消息的类型字段有效值范围为0〜 127,而信息消息的类型字段有效值范围为128〜255。
4.2 ICMPv6差错消息
目前共有以下4 种差错消息。
目标不可达
当数据报文无法被转发到目标节点或上层协议时,路由器或目标节点发送ICMPv6目标不可达差错消息。如图 4‑2 目标不可达消息结构所示。
图 4‑2 目标不可达消息结构
在目标不可达消息中,类型(Type)字段值为1,代码(Code)字段值为0〜4 ,每一个代码 值都定义了以下具体含义。
- 0:没有到达目标的路由。
- 1:与目标的通信被管理策略禁止
- 2:超出源地址范围
- 3 : 地址不可达
- 4 : 端口不可达
- 5 : 源地址在进出策略中拒绝
- 6 : 拒绝去目的地的路由
数据报文超长
如果由于接口链路MTU小于IPv6数据报文的长度而导致数据报文无法转发,路由器就会发送数据报文超长消息。该报文被用于IPv6路径MTU发现的处理,如图 4‑3 数据报文超长消息结构所示。
图 4‑3 数据报文超长消息结构
数据报文超长消息的类型字段值为2,代码字段值为0。
超时
当路由器接收到一个跳限制(Hop Limit)字段值为1 的数据报文时,会丢弃该数据报文 并向源发送ICMPv6超时消息。如图 4‑4 超时消息结构所示。 在超时报文中,类型字段的值为3。代码字段的值为0 或 1,具体含义如所示。
图 4‑4 超时消息结构
- 0 : 在传输中超过了跳限制。
- 1:分片重组超时。
参数问题
当 IPv6报头或者扩展报头出现错误,导致数据报文不能被节点进一步处理时,节点会丢弃该数据报文并向源发送参数问题消息,指明问题的发生位置和类型。如图 4‑5 参数问题消息结构所示。
图 4‑5 参数问题消息结构
在参数问题消息中,类型字段值为4,代码字段值为0〜2,指针字段指出问题发生的位
置。其中代码字段的定义如下。
- 0:遇到错误的报头字段。
- 1 : 遇到无法识别的下一个报头(Next Header)类型。
- 2:遇到无法识别的ffv6 选项。
4.3 ICMPv6信息消息
ICMPv6信息消息有很多,这里只介绍常用的两种:回送请求和回送应答。回送请求/ 回送应答机制提供了一个简单的诊断工具来协助发现和处理各种可达性问题。
回送请求
回送请求消息用于发送到目标节点,以触发目标节点立即发回一个回送应答消息。如图 4‑6 回送请求消息结构所示。
回送请求消息的类型字段值为128,代码字段值为0。标识符和序列号字段由发送方主机设置,用于检查收到的回送应答消息与发送的回送请求消息是否匹配。
图 4‑6 回送请求消息结构
回送应答
当收到一个回送请求消息时,ICMPv6会用回送应答消息来响应。如图 4‑7 回送应答消息结构所示。
图 4‑7 回送应答消息结构
回送应答消息的类型字段值为129,代码字段值为0。标识符和序列号字段的值需与回送请求消息中的相应字段的值相同。
4.4 ICMPv6常用工具
Ping工具
Ping源于声呐定位操作,它通过发送一份ICMPv6回送请求给目标节点,并等待目标节点返回ICMPv6回送应答,来测试该目的节点是否可达。如图 4‑8 PING的过程所示显示的是一个节点执行Ping操作检查到另一节点的连通性的示意图。
图 4‑8 PING的过程
如图 4‑9 请求和应答报文所示分别是回送请求和回送应答消息,从中可以看出整个过程。
图 4‑9 请求和应答报文
Tracert
Tracert是另一个必不可少的网络诊断工具,它可以让人们看到IP 数据报文从一个节点传到另一个节点所经过的路径。如图 4‑10 Tracert工作过程所示。
图 4‑10 Tracert工作过程
下面分析一下Tracert的工作原理。
- PCA发送一个跳限制为1 的 Echo Request,其目的地址是目标节点PCB的地址。
- 处理该数据报文的第一个路由器RTA将跳限制值减去1,丢弃数据报文,并发回 一 个 Time Exceeded消息给PCA,这样 PCA就知道了路径上的第一个路由器RTA的地址。
- Tracert发送一个跳限制为2 的 Echo Request给目标节点PCB。
- 第一个路由器RTA处理完后转发给第二个路由器RTB,RTB丢弃数据报文(由于跳限制值的原因),发回一个 Time Exceeded消息,于是 PCB就得到了第二个路由器地址。
- PCA周而复始地执行类似过程,直到数据报文的,跳限制值足够以到达目的节点 PCB,PCB 返回 Echo Reply 消息给 PC A, PCA 停止发送 Echo Request。
这样,PCA就得到了到PCB的路径信息。
另需要注意tracert和traceroute区别:
- windows下的tracert和linux/BSD/router下的traceroute都用于探测数据包从源到目的经过路由的IP,但两者探测的方法却有差别。
- 默认情况下,tracert是向目的地址发出ICMP请求回显数据包,而traceroute是向目的地址的某个端口(大于30000)发送UDP数据报。两者用于探测的数据类型不同。但他们也有一个共同点:都是通过设置发送包的TTL的值从1开始、逐次增1的方法来探测。
PMTU
PMTU(Path MTU,路径最大传输单元)是在源节点和目的节点之间的路径上的任意链路所能支持的链路MTU的最小值。
在 IPv4网络中,当数据报文的长度大于链路层MTU时,中间路由器会对数据报文进行分段。这会消耗中间路由器的资源。而且在某些特殊情况下,传送路径上的中间路由器可能会对已分段的报文进行再次分段,这会造成路由器性能更加下降。
在 IPv6网络中,分段不在中间路由器上进行。当需要传送的数据报文长度比链路 MTU大时,只由源节点本身对数据报文进行分段,中间路由器不对数据报文进行再次分段。这就要求源节点在发送数据报文前能够发现整个发送路径上的所有链路的最小MTU,然后以该MTU值发送数据报文,这就是PMTU发现。
图 4‑11 PMTU发现过程示意图
如图 4‑11 PMTU发现过程示意图所示,各步骤含义如下。
- 源节点向目的节点发送一个IPv6数据报文,其长度为1500字节。
- 中间路由器RTA的链路MTU值 为 1400字节,所以它会用ICMPv6数据报文超长消息向源节点做应答,该消息会吿诉源节点“路径上的MTU值为1400字节”。
- 源节点向目的节点发送一个IPv6数据报文,其长度为1400字节。
- 中间路由器RTB的链路MTU值 为 1300字节,所以它会用ICMPv6数据报文超长消息向源节点做应答,该消息中会告诉源节点“路径上的MTU值为1300字节”。
- 源节点向目的节点发送一个IPv6数据报文,其长度为1300字节。
- 目的节点收到数据报文。此后在它们之间发送的所有数据报文都使用1300字节作为MTU值。
【实验PMTU】
如图 4‑12 PMTU实验拓扑所示,本实验用来演示在发送较大报文时,网络设备如何进行分片处理。同时,通过本实验也能看到IPv6使用类型为44的扩展报头来分片。
图 4‑12 PMTU实验拓扑
- 正常ping测试。在路由器R2的e0/0接口开启数据包捕获,如图 4‑13 在R1上ping 2001:23::3,R2上捕获的数据报文显示所示。注意,Cisco路由器默认的ping包大小是52字节,字符是从00开始的十六制编码字符,而Windows默认的ping包大小是32字节,字符是以abcd开始的23个字母(没有xyz)的重复组合。
图 4‑13 在R1上ping 2001:23::3,R2上捕获的数据报文显示
- 扩展ping测试。在R1上使用扩展ping进行测试,改变默认的ping包大小。首先查看ping包的大小范围,在R1上执行下如下命令:
R1#ping2001:23::3 size? //带size参数 <48-18024> //Datagramsize 数据包的大小是48~18024字节,这是因为IPv6数据包的封装默认占用了48个字节,所以不能比48再小。比如size为80,则真正发送的字符只有80-48=32字节
在R1上执行ping2001:23::3 size10000命令,ping包的大小是10000字节。如图 4‑14 R2上捕获的数据报文显示所示。
图 4‑14 R2上捕获的数据报文显示
从中可以看出,发送的ICMPv6回声报文被分成了7段(编号45~51),前6段的长度为固定的1510字节,最后一段是1334字节,小于1510字节。路由器回应的报文一样也被分成7段(编号52-58)。
思考:此处最后一段为什么是1334字节?
- ping过程中分段后的数据,只有最后一段中含有ICMP头部信息,其余段不含ICMP信息(IPv6和IPv4一致),另外需要注意由于IPv6不同于IPv4,每片报文均会存在IPv6的分段扩展头部信息。
- Ping 10000字节的报文,实际IPv6有效载荷数据部分为:10000字节的IP报文-40字节的IPv6头部-8字节的ICMPv6头部=9952字节;
- 前面每段的IPv6有效载荷数据部分为:1500字节-40字节-8字节后能被8整除的最大整数为1448,故前6段每段的IPv6有效载荷数据为1448字节,抓报固定长度为:1448字节的有效载荷数据+40字节的IPv6基础头部信息+8字节的分片扩展头部信息(M位置为1)+源MAC(6char)+目的MAC(6char)+帧类型(2字节)=1510字节;
- 最后一段承载的IPv6有效载荷数据部分为:9952字节-1448字节*6段=1264字节,故抓报固定长度为:1264字节的有效载荷数据+40字节的IPv6基础头部信息+8字节的分片扩展头部信息(M位置为0)+8字节的ICMPv6头部信息+源MAC(6char)+目的MAC(6char)+帧类型(2字节)=1334字节。
- 修改路由器R2的e0/1接口的IPv6MTU值,命令如下:
R2(config)#inte0/1 R2(config-if)#ipv6 mtu? //查看MTU的大小取值范围 <1280-1500>MTU(bytes) R2(config-if)#ipv6 mtu 1400 //将MTU改为1400字节
继续在R1上执行ping2001:23::3 size10000命令,如所示。
R1#ping 2001:23::3 size 10000 Type escape sequence to abort. Sending 5, 10000-byte ICMP Echos to 2001:23::3, timeout is 2 seconds: B!!!! Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/1 ms
图 4‑15 捕获的数据报文
从图中(编号154~156)可以看出,从R1发出来的数据报文分片大小没有变化,仍然是1510字节。但当分片报文从路由器R2 e0/1接口发出时,因大于MTU值而被丢弃,R2向R1返回了“PacketTooBig”的报错信息(编号157~161),并告诉R1它能接受的MTU值是1400字节(图中画圈的部分)。R1再次发出ping报文(编号163~170),每个ping报文的大小是1400−48=1352字节,10000字节大小的数据包被分成了8段。如图 4‑16 R3返回R1的报文所示(编号171-178)大小仍然是1510字节,这也说明MTU的修改只影响从本地接口发送出去的数据报文的分片大小,接收的报文不受影响。
图 4‑16 R3返回R1的报文
使用如下命令还原R2的e0/1接口的默认MTU大小:
R2(config)#inte0/1 R2(config-if)#no ipv6 mtu
继续在R1上执行ping 2001:23::3size10000命令,捕获的数据报文显示发出的ping包仍然是1414字节,并没有还原到1510字节,这是因为存在MTU缓存的缘故。在路由器R1上执行如下命令,清除MTU缓存:
R1#show ipv6 mtu MTU Since Source Address Destination Address 1400 00:14:03 2001:12::1 2001:23::3 R1#clear ipv6 mtu
继续在R1上执行ping 2001:23::3 size10000命令,此时捕获的数据报文被还原到1510字节。
思考:IPv6和IPv4固定长度是如何得到的?
IPv6默认情况下,抓包固定长度1510是怎么得到的?IPv4默认固定长度1514又是怎么得到的?
- IPv4以太网帧长度 = 7字节前导同步码+1字节帧开始定界符+6字节的目的MAC+6字节的源MAC+2字节的帧类型+1500字节(1480字节数据+20字节报头)+4字节的 FCS = 1526;
- IPv4抓包长度 = 源MAC(6char)+目的MAC(6char)+帧类型(2字节)+1480字节数据+20字节报头 = 1514;
- IPv6报文在默认1500字节MTU的网络中传输,其MTU为1500,其中IPv6头部为40字节,ICMPv6包头为8字节,然后小于等于(1500-40-8)且可以被8整除的数为1488,固分段后每片报文数据部分为1488,故IPv6抓包长度如下:其IPv6抓包长度=源MAC(6char)+目的MAC(6char)+帧类型(2字节)+1448字节数据+40字节IPv6基础头部信息+8字节分段扩展头部信息 = 1510;
- IPv4中帧类型(2字节)为0X0800,而IPv6中帧类型(2字节)为0X86dd。
免责声明:本站所有文章内容,图片,视频等均是来源于用户投稿和互联网及文摘转载整编而成,不代表本站观点,不承担相关法律责任。其著作权各归其原作者或其出版社所有。如发现本站有涉嫌抄袭侵权/违法违规的内容,侵犯到您的权益,请在线联系站长,一经查实,本站将立刻删除。 本文来自网络,若有侵权,请联系删除,如若转载,请注明出处:https://haidsoft.com/124818.html