<p style="margin-left:0;text-align:justify;">由于IPv4中的包头功能字段过多,路由器查找选路的时候需要读取每一个字段,但往往很多字段都是空的,这样会导致转发效率低下。所以在IPv6中把报文的<strong>报头分为基本头和扩展头</strong><strong>2</strong><strong>部分</strong>,基本头中只包含基本的必要属性如源IP和目的IP等,扩展功能用扩展头添加在基本头的后面。</p>
讯享网
不同于IPv4报头的可变长20〜60Byte, IPv6基本头是定长40 Byte,其中包含8 个字段,相比IPv4报头,减掉了 6 个字段,新增加1个字段。如图 3‑1 IPv6基础结构所示。
图 3‑1 IPv6基础结构
- Version: 4 bit,指定 IPv6,数值=6。
- Traffic Class: 8 bit,流量类别字段的功能跟IPv4中的TOS字段类似,用来区分不同类型或优先级的IPv6数据包,该字段根据RFC2647中定义的差分服务技术,使用了 6 bit作为 DSCP,可以表示的DSCP值的范围为0〜63。关于DSCP的更多内容可参阅本书QoS章节。
- Flow Label: 20bit,用作标识同一个数据流,此字段为IPv6新增字段。由于可以标记一个流中的所有数据包,所以路由器可以利用该字段来辨别一个流,而不用处理流中每个数据包头,提高了处理效率。目前该字段的使用还在试用阶段。
- Payload Length: 16bit,数据包的有效载荷,指报头后的数据内容长度,单位是Byte,最大数值为65535,指 IPv6基本头后面的长度,包含扩展头部分。该字段和IPv4报文头部中的总长度字段不同点在于,IPv4报头中总长度字段是指报头和数据两部分的长度, 而 IPv6的有效载荷字段只是指数据部分的长度,不包括IPv6基本报头。
- Next Header: 8bit,指明跟在基本头后面是哪种扩展头或者上层协议中的协议类型。 如果只有基本报头而无扩展报头,那么该字段的值指示的是数据部分所承载的协议类型,这一点类似于IPv4报头中的协议字段,而且与IPv4的协议字段使用相同的协议值,比如 UDP为 6, TCP为 17。如表 3‑1 Next Head值列出了常用的上层协议及对应的Next Header值。
Next Header值
对应的扩展头或高层协议类型
0
逐跳选项扩展头
6
TCP
17
UDP
43
路由选择扩展头
44
分段扩展头
50
ESP扩展头
51
AH扩展头
58
ICMPv6
60
目的选项扩展头
89
OSPFv3
….
….
- Hop Limit: 8bit,功能类似于IPv4中的TTL字段,最大值为255,报文每经过一跳, 该字段值会减1,减到0后数据包被丢弃。对于IPv6来说,此时会发送一条ICMPv6超时消息,以通知数据包的源端数据已经被丢弃。
- Source Address: 128bit,数据包的源IPv6地址,必须是单播地址。
- Destination Address: 128bit,数据包的目标IPv6地址,可以是单播或组播地址。
如图 3‑2 IPv6基础报头格式显示了一份通过WireShark抓取的IPv6报文。

图 3‑2 IPv6基础报头格式
IPv4报头中包含13个字段,如图 3‑3 IPv4报头格式所示,其中红框部分为IPv6报头中被去除的字段。

图 3‑3 IPv4报头格式
由于IPv6采用头部定长40Byte设计, 所以去除了 IHL (头部长度)字段,因为IPv6的基础头部长度是固定的,因此该字段没有存在的必要;
分段功能由IPv6分段扩展头实现,所以去除了标识、FLAGS、分段偏移这3个字段,相对IPv4不管数据包有没有分片均需要处理分片相关的字段,IPv6的处理效率是相对较高的;
去除首部校验和,原因有3 个:
- 是由于数据链路层大部分都已经对数据进行了校验,保证了三层不需要再对数据包进行校验式;
- 是由于四层协议也有类似的校验功能;
- 是由于TTL值每跳都在改变,路由器要频繁进行校验和的重新计算,影响了数据包的转发效率。
IPv6扩展头是可选报头,跟在IPv6基本头后,其作用是取代IPv4报头中的选项字段,这样可以使得IPv6的基本头采用定长设计(40Byte), 并把IPv4中的部分字段如分段字段独立出来,设计为IPv6分段扩展头,这样做的好处是大大提高了中间节点对IPv6数据包的转发效率。每个IPv6数据包都可以有0 个或者多个扩展头,每个扩展头长度都是8Byte的整数倍。IPv6基本头和扩展头的Next header字段表明了紧跟在本报头后面的是什么内容,可能是另一个扩展头或者是高层协议。

IPv6的扩展头被当作IPv6静载荷的一部分,计算在IPv6基本头的Palyload Length 字段内。
如图 3‑4 IPv6报文结构示例所示。

图 3‑4 IPv6报文结构示例
目前,RFC 2460中定义了 6 个 IPv6扩展头:逐跳选项报头、目的选项报头、路由报头、分段报头、认证报头、封装安全净载报头。其中逐跳选项扩展头和目的选项扩展头的数据部分都采用类型-长度-值(TLV)的选项设计。如所示。

图 3‑5 选项格式
- Option Type: 8bit,标识类型
- 最高2 位表示当设备部识别此扩展头时的处理方法。
- 00:跳过这个选项。
- 01:丢弃数据包,不通知发送方。
- 10:丢弃数据包,不论目的地址是组播、单播或者任意播,向发送方发1个 ICMPV6的错误信息报文。
- 11:丢弃数据包,当目的地址不是组播时,向发送方发1个 ICMPv6的错误信息报文。
- 第3 位表示在选路过程中,Data部分是否可以被改变。
- 0:表示Option不能被改变。
- 1:表示Option可以被改变。
- 值得注意的是:如果存在认证扩展头,在计算数据包的校验值时,可变化Data部分需要被当成8bit的全0 处理。
- 最高2 位表示当设备部识别此扩展头时的处理方法。
- Opt Data Len: 8 bit,标识Option Data部分的长度,最大为255,单位是Byte,不包含 Option Type和 Opt Data Len部分的长度。
- Option Data:长度可变,最大为255Byte,包含选项的具体数据内容。
IPv6基础头部中 Next Header 值=0
作用:用于携带在报文发送路径上必须被每一跳路由器检查和处理的可选信息,类似 IPv4中的ROUTER ALERT选项。到目前为止,只定义了一个逐跳选项—— 巨型净荷选项。通过这个选项,允许IPv6报文的有效净荷超过65535Byte。如图 3‑6 逐跳选项扩展头格式所示。

图 3‑6 逐跳选项扩展头格式
- Next Header: 8 bit,作用同基本头的Next Header相同。
- Hdr Ext Len: 8 bit,标识Options头的长度。该长度以8Byte为单位,不包含扩展头的第一个8Byte,即如果该扩展头只有8Byte长,该字段值即为0。
- Options:可以携带不定数量采用TLV格式的选项,目前唯一定义的选项是巨型静载荷选项。使用巨型静载荷选项,要求IPv6基础头的16位净荷长度字段值必须为0 , 扩展头中的巨型净荷长度字段值不小于65535。此外还有一个限制:如果包中有分段扩展头, 就不能同时使用巨型净荷选项,因为使用巨型净荷选项时不能对包进行分段。
巨型静载荷选项的选项类型为194,如图 3‑7 巨型静载荷选项格式所示,由于整个选项扩展头只有8Byte, 所以扩展头长度为0 , 选项数据长度为4 , 表示巨型静载荷长度是32bit,所以使用巨型静载荷选项,IPv6数据包的静载荷最大可以达到2^32-1Byte。IPv6基本头不包括在内,如图 3‑8 静载荷=Byte的IPv6数据包格式所示。

图 3‑7 巨型静载荷选项格式

图 3‑8 静载荷=Byte的IPv6数据包格式
另外,在介绍具体选项之前,先介绍两个特别的选项:Pad l选项和Pad N选项。 Pad l和 Pad N选项可以用来填充,使字段符合对齐要求。Pad l的作用是插入一个填充字节,而 Pad N可以插人两个或多个填充字节。如图 3‑9 Pad I选项结构和图 3‑10 Pad N选项结构所示。
图 3‑9 Pad I选项结构
图 3‑10 Pad N选项结构
Pad l选项只有一个字节,选项类型值为0,它非常特殊,没有长度字段和填充字节。
Pad N选项包括选项类型字段(类型值为1)、长度字段(值为当前所有的填充字节数)和 0 或多个填充字节。
目前逐跳选项报头中有以下两个“有效”的选项。
超大有效载荷选项
在 IPv6中,将超过65535字节的数据报文称为巨包(Jumbo),又叫超长帧。逐跳选项报头的一个重要应用就是用于支持超长帧的转发,这就是超大有效载荷选项。
在 IPv6的基本报头中,有效载荷长度字段占有16位 ,也就是说最多能表示65535字 节。但在 MTU非常大的网络上,有可能需要发送大于65535个字节的数据报文。超大有效载荷选项可用来解决这个问题。如图 3‑11 超大有效载荷项结构所示。
图 3‑11 超大有效载荷项结构
其中各字段含义如下:
- 选项类型(Option Type): 值 为 194。
- 选项长度(Opt Data Len):值 为 4。
- 超大有效载荷长度(Jumbo Payload Length): 表示帧长度。
如果有效载荷长度超过65535字节,则 IPv6基本报头中的有效载荷长度字段的值被置 0,数据报文的真正有效载荷长度用超大有效载荷长度选项中的超大有效载荷长度字段来表示。该字段占有32位 ,最大能够表示字节(2^32-1)。
路由器告警选项
路由器告警选项被用于RSVP协议中,详见 RFC2711。其如图 3‑12 路由器告警选项所示。

图 3‑12 路由器告警选项
其中各字段含义如下。
- 选项类型(Option Type): 值为5。
- 选项长度(Opt Data Len):值为2。
- Value:表示实际信息。
IPv6基础头部中Next Header 值=43
作用:包含IPv6数据包到达目的地所要经过的中间节点,使源端可以强制数据包经过哪些节点,类似IPv4中的宽松源站选路。如所示。


图 3‑13 路由选项扩展头格式
因为Hdr Ext Len字段的单位是8Byte (64bit),所以Hdr Ext Len字段部分的数值等于需要经过的节点数*2(由于Option中携带的IPv6的地址长度为128位)。
使用路由选择扩展头时,初始状态源端主机发出的数据包目的地址并非是实际的最终目的地址,而是需要经过的第一个中间节点,其 Segments Left等于需要经过的节点数量,中间的其他路由器忽略路由选择扩展头,然后数据包到达第一个指定经过路由器才处理此路由选择扩展头。数据包的目的地址替换为指定经过的第二个中间节点,Segments Left字段值减1,以此类推,数据包到达最终目的地址。Segments Left字段为0 表示此路由器节点就是最终目的地址。
如图 3‑15 使用路由选择扩展头的数据包转发过程所示,IP1和 IP2是数据包转发过程中要求经过的节点,则源主机发送的数据包源IP是 S , 目的IP是第一个节点IP 1 ,在路由选择头中有2个IP地址,分别是需要经过的第二个节点IP2和最终目的地址D。数据包达到IP1后,数据包的目的地址被替换为IP2,同时Segment left字段减1。依次类推,数据包到达IP2时也重复上述操 作,一直到数据包到达最终目的地址D。

图 3‑15 使用路由选择扩展头的数据包转发过程
- Next Header:8 bit,作用同基本头的 Next Header。
- HdrExtLen: 8 bit,标识Options头的长度。该长度以8Byte为单位,不包含扩展头的第一个8Byte,即如果该扩展头只有8Byte长,该字段值即为0。
- Routing Type:8 bit,目前只定义了类型0 , 表示数据包需要经过的中间路由器的地址,如图 3‑14 类型为0的路由选择扩展头格式所示。
图 3‑14 类型为0的路由选择扩展头格式
- Segments Left:8bit,表示数据包到达目的地址所需要经过的中间节点的数量,最大为 255。
- type-specific data:内容由 Routing Type 决定。 Reserverd保留部分为32bit,Address[1]、Address[2]等表示数据包需要经过的中间节点。
IPv6基础头部中Next Header 值=44
作用:如果源端需要发送的数据包超过Path MTU的大小,源端在发送前需要将数据包先分段。在 IPv4中,数据包超过接口 MTU值,中间节点路由器将对数据包进行分段处理;而在IPv6中,中间路由器不能对数据包分段,如果中间路由器需要发送的报文超过本接口的MTU值,数据包将被丢弃,同时路由器会发送一个ICMPv6的错误信息报文给源端。IPv6分段扩展头如图 3‑16 IPv6分段扩展头所示。

图 3‑16 IPv6分段扩展头
- Next Header:8 bit,作用同基本头的 Next Header。
- Reserved:8 bit,保留目前未用为0。
- Fragment Offset:13bit,等同于IPv4中的分段偏移字段,以 8Byte为单位。如该值为 150,表示该报文的数据是位于原报文的1200Byte处后,类似于IPv4包头的偏移值。
- Res:2 bit,保留目前未用为0。
- M:1bit,表示后续是否还有分段,如为1表示后续还有分段报文,为 0 表示该报文是最后一个分段报文。
- Identification: 32bit,该字段等同于IPv4的标识字段,为 32位。源节点为每个被分段的IPv6包都分配一个标识符,用来唯一标识同一组分段的报文,便于接收端根据相同标识重组报文。
由于分段扩展头采用定长8Byte的设计,所以扩展头长度这一字段无任何意思,8bit 保留为0。
在 IPv4中,中间路由器对于超过接口 MTU的数据包可以进行分段处理,这样操作会降低数据包的转发效率,而且数据包在转发过程中可能被多次分段。而在IPv6中,只有源端数据包发送方才能对数据包进行分段处理,如果中间路由器转发的数据包大于MTU将被丢弃掉,并向源端发送一个ICMPv6的错误信息报文。
如图 3‑17 2000Byte的IP报文数据分段所示,假设源端要发送2000Byte的IP报文数据,分段标识为1111,MTU值为1400Byte。由于IPv6基本头定长40Byte,所以数据包的有效静载荷长度为1360(MTU-IPv6基础头,且能被8整除的第一个整数), 由于要分段,加入分段扩展头8Byte,所以有效静载荷的数据部分为1352Byte, 2000Byte的数据被分为2段,第一段的有效静载荷长度是1360,有效静载荷数据部分是1352Byte; 第二段的有效静载荷长度是656,有效静载荷数据部分为648Byte,这两段的分段标识同为 1111。

图 3‑17 2000Byte的IP报文数据分段
IPv6基础头部中Next Header 值=50
作用:提供对数据包的完整性验证和加密,ESP将需要加密保护的字段加密后放入ESP头的数据部分,ESP与AH联合使用,用来提供认证和加密。如图 3‑18 ESP扩展头的格式所示。

图 3‑18 ESP扩展头的格式
- SPI:32bit,与目的地址和AH协议组合,唯一标识本数据包的SA。
- Sequence Num:32bit,是一个单调递增的数,可用作防重放攻击。
- Payload Data:可变长,加密数据。
- Padding:填充,由于加密数据必须是4Byte的整数倍,所以有时候需要填充,内容 依据加密算法,最大为255Byte。
- Pad Length:8bit,标识Padding部分长度,0表示无填充。
- Next Header:8bit,作用同基本头的Next header。
- Authentication Data:可变长,身份验证。
IPv6基础头部中Next Header 值=51
作用:为报文提供完整性验证,在传输过程中不被改变的字段会被用作认证信息的 计算,在传输过程中可能改变的字段如Hop limit字段,作为0 处理。如果有多个扩展头, 必须置于由中间节点路由器处理的扩展头之后,以及由目的地址处理的扩展头之前。认证报头扩展头的格式如图 3‑19 认证报头扩展头的格式所示。

图 3‑19 认证报头扩展头的格式
- Next Header:8bit,作用同基本头的 Next Header。
- Payload Len:8bit,标识认证报头的总长度,单位是4Byte,最大为255。
- RESERVED:16bit,保留,填充为 0。
- SPI:32bit,与目的地址和AH协议组合,唯一标识本数据包的SA。
- Sequence Num:32bit,是一个单调递增的数,可用作防重放攻击。
- Integrity Check Value:可变长,必须是4 字节的整数倍,其内容用作完整性检查。
IPv6基础头部中Next Header 值=60
作用:取代了 IPv4中的选项字段,携带了只能由目的地址才能处理的信息。目的选项扩展头的格式如图 3‑20 目的选项扩展头的格式所示。

图 3‑20 目的选项扩展头的格式
- Next Header:8bit,作用同基本头的 Next Headero
- Hdr Ext Len:8bit,标识Options头的长度。该长度以8Byte为单位,不包含扩展头的第一个8Byte,即如果该扩展头只有8Byte长,该字段值即为0。
- Options:包含一个或多个以TLV格式编码的选项。
如果有多个扩展头,必须按照以下顺序出现:
- IPv6基本报头
- 逐跳选项扩展报头
- 目的选项扩展报头 (只有在路由选择表中指定的中间路由器才必须处理)
- 路由选择扩展报头
- 分段扩展报头
- 认证扩展报头
- 封装安全有效载荷扩展报头
- 目的选项扩展报头(指那些将被分组报文的最终目的地处理的选项)
- 上层协议数据报文
除了逐跳选项扩展头之外,其余扩展头在传输路径中不被路由器查看,这种机制保证了路由器只查看和选路相关的基本头字段,保证了转发数据的高效。每个扩展头的大小是8Byte的整数倍。除了目的地址选项扩展头最多出现两次(一次在路由选择扩展头前,一次在上层协议头部前)以外,每个扩展头应当只出现一次。
其中需要注意的是目的选项扩展头,只可能出现在两个位置:路由选路扩展头前,这时此选项头被目的节点和路由头中指定的节点处理;上层头前(任何 ESP 选项后),此时只能被目的节点处理。Mobile IPv6 中使用了目的选项头。Mobile IPv6 中新增加一种类型的目的选项头(家乡地址选项)。家乡地址选项由目的选项头携带,用于移动节点离开家乡后通知接收节点此移动节点对应的家乡地址。接收节点收到带有家乡地址选项的报文后,会把家乡地址选项中源地址(移动节点的家乡地址)和报文中源地址(移动节点的转交地址)交换,这样上层协议始终认为是在和移动节点的家乡地址在通信,实现了移动漫游功能。

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容,请联系我们,一经查实,本站将立刻删除。
如需转载请保留出处:https://51itzy.com/kjqy/197542.html