dslztx
0%

IPv6报文

发表于 更新于 专题于 Disqus：

IPv6报文是一种可变长报文，由“首部”和“载荷数据”两部分组成：

  1. 首部：从Version字段到Destination Address字段为止”，长度40字节
  2. 载荷数据：IPv6报文数据，长度范围为[0字节,65535字节]

整个IPv6报文长度范围为[40字节,65535字节+40字节=65575字节]。

IPv6报文示意如下。

+--------------+--------------------+
|              |                    |
|    Header    |    Payload Data    |
|              |                    |
+--------------+--------------------+

一、首部

IPv6报文首部示意如下。

IPv6 Packet Header Format
Offsets Octet 0 1 2 3
Octet Bit 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 Version (4 bits) Traffic Class (8 bits) Flow Label (20 bits)
4 32 Payload Length (16 bits) Next Header (8 bits) Hop Limit (8 bits)
8 64 Source Address (128 bits)
12 96
16 128
20 160
24 192 Destination Address (128 bits)
28 224
32 256
36 288

1.1、Version

中文名：版本。

长度：4 bits。

含义：指明IP协议版本号，IPv6版本的话其值为0110。

1.2、Traffic Class

中文名：通信量类。

长度：8 bits。

含义：为了区分不同的IPv6报文的类别或优先级，和IPv4的区分服务（DS）字段作用相似。

1.3、Flow Label

中文名：流标号。

长度：20 bits。

含义：IPv6新支持资源预分配机制，具体是可以给流设定一个服务质量目标，然后所有属于该流的IPv6报文在所经过的实现该新机制的路由器上都会被保证提供所需的服务质量。流标号就用来标识本IPv6报文属于哪一个流，全置为0表示不属于任何一个流。实时数据（比如“音频”，“视频”等）应用流机制能够大大改善服务质量，非实时数据（比如“网页”，“电子邮件”等）没有太大必要应用流机制。

备注：“通信量类对应的区分服务机制”和“流标号对应的资源预分配机制”是可自定义IP网络服务质量的两种机制。

1.4、Payload Length

中文名：载荷数据长度。

长度：16 bits。

含义：IPv6报文除首部之外的长度（单位是“字节”，最大值为2^16-1=65535）。

1.5、Next Header

中文名：下一个首部的类型值。

长度：8 bits。

含义：详见“2.1、扩展首部”小节内容。

1.6、Hop Limit

中文名：跳数限制。

长度：8 bits。

含义：生存时间，用于限制IPv6报文在网络上的生存时间，防止IPv6报文在网络中无限循环堵塞网络。跳数限制，每经过一个路由器转发就减去1，减至0后被路由器丢弃。即IPv4报文中的“生存时间”字段，只不过这里命名更加准确。

1.7、Source Address

中文名：源IPv6地址。

长度：128 bits。

含义：源IPv6地址。

1.8、Destination Address

中文名：目的IPv6地址。

长度：128 bits。

含义：目的IPv6地址。

二、载荷数据

IPv6报文的载荷数据根据是否包含扩展首部可分为两种：

  1. 不包含扩展首部，直接就是Upper Layer Data（上层协议数据），如图1
  2. 包含扩展首部，如图2

图1

+--------------+------------------------+
|              |                        |
|    Header    |    Upper Layer Data    |
|              |                        |
+----------+---+------------------------+
               |                        |
               <-------Payload Data----->

图2

+--------------+----------------------------------+------------------------+
|              |                                  |                        |
|              |    Hop-by-Hop Options Header     |                        |
|    Header    |    Destination Options Header    |    Upper Layer Data    |  
|              |    Routing Header                |                        |
|              |    Fragment Header               |                        |
|              |    ...                           |                        |
|              |                                  |                        |
+--------------+---+------------------------------+------------------------+
               |                                                           |
               <----------------------Payload Data------------------------->

接下来介绍扩展首部。

2.1、扩展首部

扩展首部基本介绍：

  1. 现在定义了多种扩展首部，常见的如下：
    • Hop-by-Hop Options Header
    • Routing Header
    • Fragment Header
    • Destination Options Header
    • Authentication Header（AH Header）
    • Encapsulating Security Payload Header（ESP Header）
    • …
  2. 扩展首部的本质是相应协议报文的首部，可在非IPv6报文场景使用，作为相应协议报文的首部：
    • 扩展首部对应的协议报文的完整格式一般为Header + Payload Data，当然也有可能不是这个格式，比如ESP Header对应的ESP协议报文的完整格式为ESP Header + ESP Payload Data + ESP Trailer + ESP ICV，不过为了简化，本博文统一以第一种格式进行叙述
    • 首部类型值（扩展首部类型值）即相应的协议类型值[3]，IPv6报文首部和扩展首部中的Next Header字段值指明本首部/扩展首部对应的载荷数据中的协议类型值，据此可构成[IPv6报文首部] --Next Header--> [上层协议数据]或者[IPv6报文首部] --Next Header--> 扩展首部{1,} --Next Header--> [上层协议数据]链路
  3. 这里被称为“扩展首部”的唯一原因是——“在IPv6报文的使用场景中具有其特殊性”：
    • 所有的扩展首部大小都为8字节的倍数
    • 除了“Destination Options Header”，每种扩展首部只能出现一次。“Destination Options Header”最多允许出现2次：1）在“Routing Header”存在前提下，一次出现在“Routing Header”之前；2）一次出现在上层协议数据之前
    • 多个扩展首部的出现须遵从如下合法顺序
      1. Hop-by-Hop Options Header
      2. Destination Options Header
      3. Routing Header
      4. Fragment Header
      5. Authentication Header（AH Header）
      6. Encapsulating Security Payload Header（ESP Header）
      7. Destination Options Header
      8. Upper Layer Data

2.2、扩展首部详细介绍

2.2.1、Hop-by-Hop Options Header

中文名：逐跳选项首部。

首部类型：扩展首部。

首部类型值：0。

含义：承载传送路径上每个节点都必须处理的选项信息。

首部格式见下表，说明如下：

  • Next Header：下一个首部的类型值
  • Header Extension Length：扩展首部长度，以8字节为单位（即当值为11=3时，表示3*8=24个字节），另外有：1）这个长度不包括前面8个字节，即整个扩展首部长度为(1 + Header Extension Length) * 8字节；2）根据1有整个扩展首部长度字节数为8的倍数，且大于等于8字节
  • Options：扩展首部数据，由多个TLV (Type-Length-Value) Encoded Option + Padding构成
Hop-by-Hop Options Header Format
Offsets Octet 0 1 2 3
Octet Bit 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 Next Header (8 bits) Header Extension Length (8 bits)
4 32 Options (variable bits)
8 64
... ...

2.2.2、Destination Options Header

中文名：目的选项首部。

首部类型：扩展首部。

首部类型值：60。

含义：

  • 承载只需目的节点处理的选项信息
  • 如前所述可能出现在两个位置：1）路由扩展首部之前，此时该扩展首部被目的节点和路由头中指定的节点处理；2）上层协议数据之前，此时该扩展首部只能被目的节点处理

首部格式见下表（跟“2.2.1、Hop-by-Hop Options Header”一致），说明如下：

  • Next Header：下一个首部的类型值
  • Header Extension Length：扩展首部长度，以8字节为单位（即当值为11=3时，表示3*8=24个字节），另外有：1）这个长度不包括前面8个字节，即整个扩展首部长度为(1 + Header Extension Length) * 8字节；2）根据1有整个扩展首部长度字节数为8的倍数，且大于等于8字节
  • Options：扩展首部数据，由多个TLV (Type-Length-Value) Encoded Option + Padding构成
Destination Options Header Format
Offsets Octet 0 1 2 3
Octet Bit 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 Next Header (8 bits) Header Extension Length (8 bits)
4 32 Options (variable bits)
8 64
... ...

2.2.3、Routing Header

中文名：路由首部。

首部类型：扩展首部。

首部类型值：43。

含义：通过列出IPv6报文到达目的地所要经过的节点列表来提供路由选择功能。

首部格式见下表，说明如下：

  • Next Header：下一个首部的类型值
  • Header Extension Length：扩展首部长度，以8字节为单位（即当值为11=3时，表示3*8=24个字节），另外有：1）这个长度不包括前面8个字节，即整个扩展首部长度为(1 + Header Extension Length) * 8字节；2）根据1有整个扩展首部长度字节数为8的倍数，且大于等于8字节
  • Routing Type：路由类型
  • Segments Left：到达目的地还需要访问的节点数量
  • Type-Specific Data：跟具体路由类型有关的具体扩展首部数据
Routing Header Format
Offsets Octet 0 1 2 3
Octet Bit 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 Next Header (8 bits) Header Extension Length (8 bits) Routing Type (8 bits) Segments Left (8 bits)
4 32 Type-Specific Data (variable bits)
8 64
12 96
... ...

2.2.4、Fragment Header

中文名：分片首部。

首部类型：扩展首部。

首部类型值：44。

含义：对IPv6报文进行分片时，用于保存分片信息。

IPv6与IPv4的分片机制不同：

  • 在IPv4中，分片可以在发送源节点和中间路由节点进行，故发送源节点和中间路由节点只需基于“紧邻路径链路层MTU”来做是否分片决策
  • 在IPv6中，分片只能在发送源节点做，这导致发送源节点必须基于“所经过全路径最小链路层MTU”才能做是否分片决策。针对于此，IPv6中有两种解决方案：
    1. 使用“路径MTU发现（Path MTU Discovery，PMD，具体参见RFC 1191）”机制来获得“所经过全路径最小链路层MTU”
    2. 使发送报文大小不大于1280字节，因为IPv6协议规定运行IPv6的所有链路都必须能够支持最小1280字节大小的报文

首部格式见下表，说明如下（可参比《IPv4报文》中的相关内容）：

  • Next Header：下一个首部的类型值
  • Reserved：保留值，当前为全0
  • Fragment Offset：当报文不分片时，片偏移字段无实际意义；当报文分片时，片偏移字段的含义是：分片内数据相对于原报文内数据的偏移量，偏移量的具体计算公式为偏移字节数/8
  • Res：保留值，当前为全0
  • M Flag：
    • MF=1：表示后面还有分片
    • MF=0：1）在分片情形中，表示已是若干分片中最后一个；2）在未分片情形中，表示即原报文本身
  • Identification：分片标识
Fragment Header Format
Offsets Octet 0 1 2 3
Octet Bit 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 Next Header (8 bits) Reserved (8 bits) Fragment Offset (13 bits) Res (2 bits) M (1 bit)
4 32 Identification (32 bits)

2.2.5、Authentication Header（AH Header）

关于AH Header详见后续博文。

2.2.6、Encapsulating Security Payload Header（ESP Header）

关于ESP Header详见后续博文。


参考文献

[1]https://en.wikipedia.org/wiki/IPv6_packet
[2]https://datatracker.ietf.org/doc/html/rfc8200
[3]https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
[4]https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml

您的支持将鼓励我继续分享！