6LowPAN的适配层

admin管理员组

文章数量:1531445

2024年7月25日发(作者：)

适配层

适配层是IPv6网络和IEEE 802.15.4MAC层间的一个中间层，其向上提供IPv6对IEEE

802.15.4媒介访问支持，向下则控制LowPAN网络构建、拓扑及MAC层路由。6LowPAN的基

本功能，如链路层的分片和重组、头部压缩、组播支持、网络拓扑构建和地址分配等均在适

配层实现。

1. 适配层基本功能

由于最大MTU、组播及MAC层路由等原因，IPv6不能直接运行在IEEE 802.15.4MAC层之上，

适配层将起到中间层的作用，同时提供对上下两层的支持，其主要功能如下：

 链路层的分片和重组：IPv6规定数据链路层最小MTU为1280字节，对于不支持该MTU

的链路层，协议要求必须提供对IPv6透明的链路层的分片和重组。因此，适配层需要

通过对 IP报文进行分片和重组来传输超过IEEE 802.15.4MAC层最大帧长（127字节）

的报文。

 组播支持：组播在IPv6中有非常重要的作用，IPv6特别是邻居发现协议的很多功能都

依赖于IP层组播。此外，WSN的一些应用也需要MAC层广播的功能。IEEE 802.15.4 MAC

层不支持组播，但提供有限的广播功能，适配层利用可控广播共泛的方式来在整个WSN

中传播IP组播报文。

 头部压缩：在不使用安全功能的前提下，IEEE 802.15.4 MAC层的最大payload为102

字节，而IPv6报文头部为40字节，再除去适配层和传输层(如UDP)头部，将只有50

字节左右的应用数据空间。为了满足IPv6在IEEE 802.15.4 传输的MTU，一方面可以

通过分片和重组来传输大于102字节的IPv6报文，另一方面也需要对IPv6报文进行压

缩来提高传输效率和节省节点能量。为了实现压缩，需要在适配层头部后增加一个头部

压缩编码字段，该字段将指出IPv6头部哪些可压缩字段将被压缩，例如，传输类型和

流标识符均为0时将在头部压缩编码字段被指出并且在IPv6头部中省去。除了对IPv6

头部以外，还可以对上层协议(UDP、TCP及ICMPv6)头部进行进一步压缩。

 网络拓扑构建和地址分配：IEEE 发布的标准文档IEEE Std 802.15.4-2003对802.15.4

协议物理层和MAC层做了详尽地描述，其中MAC层提供了功能丰富的各种原语，包括信

道扫描、网络维护等。但MAC层并不负责调用这些原语来形成网络拓扑并对拓扑进行维

护，因此调用原语进行拓扑维护的工作将由适配层来完成。另外，6LowPAN中每个节点

都是使用EUI-64地址标识符，但是一般的LowPAN网络节点能力非常有限，而且通常会

有大量的部署节点，若采用64-bits地址将占用大量的存储空间并增加报文长度，因此，

更适合的方案是在PAN内部采用16-bits短地址来标识一个节点，这就需要在适配层来

实现动态的16-bits短地址分配机制。

 MAC层路由：现网络拓扑构建和地址分配相同，IEEE 802.15.4标准并没有定义MAC层

的多跳路由。适配层将在地址分配方案的基础上提供两种基本的路由机制——树状路由

和网状路由。

适配层是整个6LowPAN的基础框架，6LowPAN的其它一些功能也是基于该框架实现的。整个

适配层功能模块的示意图：

IPv6网络层

头部压缩移动性

链路层的分片和重组异构网络互操作性

组播支持MAC层路由IPv6报文的转发

网络拓扑构建

和地址分配

6LowPAN其他功能

IEEE 802.15.4 MAC层

适配层功能块

2. 适配层帧格式

由于LowPAN网络有报文长度小、低带宽、低功耗的特点，为了减小报文长度，适配层帧头

部分为两种格式，即不分片和分片，分别用于数据部分小于MAC层MTU(102字节)的报文和

大于MAC层MTU的报文。当IPv6报文要在802.15.4链路上传输时，IPv6报文需要封装在

这两种格式的适配层报文中，即IPV6报文作为适配层的负载紧跟在适配层头部后面。特别

地，若”M”或“B”bit被置为1时，适配层头部后面将首先出现MB或Broadcast字段，

IPv6报文则出现在这两个字段之后。

1） 不分片报文格式

MD标志位，占1 bits，

置为1时表示后面紧随

着的是MD字段

链路分片标志，占2

bits，置00表示不分片

Broadcast标志位，占1bit,

置为1时表示后面紧随着的

是”Broadcast”字段

LFprot_typeMBrsvPayload /MD /Broadcast Hdr

协议类型号，占8bits,指

出报文的类型。其中：

1：IPv6报文

2：头部压缩编码字段

4：路由错误报文

保留位，占

4bits,全部置为0

有效载荷,或

MD字段,或

Broadcast字段

不分片头部格式的各个字段含义如下：

 LF：链路分片(Link Fragment)，占2bits。此处应为00，表示使用不分片头部格

式。

 prot_type：协议类型，占8bits。指出紧随在头部后的报文类型。1表示IPv6报

文，2表示头部压缩编码字段。4表示路由错误报文。

 M：Mesh Delivery字段标志位，占1 bit。若此位置为1，则适配层头部后紧随着

的是”Mesh Delivery”字段。

 B：Broadcast标志位，占1 bit。若此位置为1，则适配层头部后紧随着的

是”Broadcast”字段。

 rsv：保留字段，全部置为0。

2） 分片报文格式

若一个包括适配层头部在内的完整负载报文不能够在一个单独的 IEEE 802.15.4帧中传输

时，需要对负载报文进行分片，此时适配层使用分片头部格式封装数据。分片头部格式如下：

链路分片标志,占2 bits,其中:

00：不分片

01：第一分片

10：最后一分片

11：中间分片

负载报文的总长度，

占11bits,支持的最大报

文长度为2048字节

分片标识，占9 bits,同一分

片该值相同。每发送一个完

整的负载报文（而不是一个

分片）该值就加1,当值达到

511后就翻转为0

LFprot_typeMBrsvDatagram_sizeDatagram_tag

Payload/ MD/Broadcast Hdr

第一分片

报文分片偏移,占8 bits,该字

段只出现在后继分片中，指

出后续分片中的payload相对

于原负载报文头部的偏移。

LFfragment_offsetMBrsvDatagram_sizeDatagram_tag

Payload/ MD/Broadcast Hdr

后继分片

分片头部格式的各个字段含义如下：

 LF：链路分片(Link Fragment)，占2bits。当该字段不为0时，指出链路分片在整个

报文中的相对位置，其中具体定义如下表所示。

LF 链路分片位置

00

01

10

11

不分片

第一个分片

最后一个分片

中间分片

 prot_type：协议类型，占8 bits，该字段只在第一个链路分片中出现。

 M： Mesh Delivery字段标志位，占1 bit。若此位置为1，则适配层头部后紧随着的

是”Mesh Delivery”字段。若需要在Mesh拓扑中路由，每个分片中都应该有该字段。

 B：Broadcast标志位，占1 bit。若此位置为1，则适配层头部后紧随着的

是”Broadcast”。若是广播帧，每个分片中都应该有该字段。

 datagram_size：负载报文的长度，占11 bits，所以支持的最大负载报文长度为2048

字节，可以满足IPv6报文在IEEE 802.15.4上传输的1280字节MTU的要求。另外，在

每个适配层分片中都需要携带该字段，这样能够使目的节点能在收到任何一个分片后

(目的节点不一定首先收到第一个分片)确定重装后报文的大小而作一些有用的预处理，

如预先分配缓冲区或者丢弃超过本节点能处理 最大字节数的报文。

 datagram_tag：分片标识符，占9 bits，同一个负载报文的所有分片的datagram_tag

字段应该相同。每个节点都需要维护一个变更来记录当前的datagram_tag值，在节点

初始化时应该将该值初始化为一个随机值(0~511)，每发送一个完整的负载报文(而不是

一个分片)该值加1，当该值达到511后翻转为0。

 fragment_offset：报文分片偏移，8 bits。该字段只出现在第二个以及后继分片中，

指出后继分片中的payload相对于原负载报文的头部的偏移。该字段以8字节为单位，

因此分片报文的payload必须以8字节为边界对齐。另外，由于负载报文的第一个字节

偏移一定为0，所以第一个分片的fragment_offset值默认为0。

3） Mesh Delivery字段

4） 若适配层头部(分片或不分片格式)M字段为1，则Mesh Delivery字段紧随在分片或不

分片的适配层头部之后，其格式如下图所示。

源地址类型标志位,占1

bit,其中：

0：EUI-64地址

1：16-bits短地址

最终目的地址类型标志

位,占1 bit,其中：

0：EUI-64地址

1：16-bits短地址

剩余跳数，占6 bits，

每经过一个转发节点

值减1，若减小到0转

发节点丢弃该帧

源链路层地址

(MAC地址),可以

为EUI-64地址或

16-bits短地址

OFHops Left

Originator Address，

...Final Destination Address

最终目的链路层地

址(MAC地址),可以

为EUI-64地址或16-

bits短地址

Mesh Delivery字段的各个字段含义如下：

 O：源地址类型标志位, 占1 bit，指出源地址（MAC地址）字段使用的地址是EUI-64

长地址还是16-bits短地址。若此位为0表示EUI-64地址；为1表示16-bits短

地址。

 F：最终目的地址类型标志位, 占1 bit，指出最终目的地址字段使用的地址是

EUI-64长地址还是16-bits短地址。若此位为0表示EUI-64地址；为1表示16-bits

短地址。

 Hops Left：剩余跳数，占6 bits。每经过一个转发节点该值减1。若该字段值减

小到0转发节点就丢弃该帧。

 Originator Address：源链路层地址，可以为EUI-64地址，也可以为16-bits短

地址。

 Final Destination Address：最终目的链路层地址，可以为EUI-64地址，也可以

为16-bits短地址。

5） Broadcast字段

若适配层头部B字段为1，则Broadcast字段紧随在适配层头部之后，其格式如下所示。

广播源地址类型标

志位,占1 bit,其中：

0：EUI-64地址

1：16-bits短地址

广播帧序号，占8bits，

初始化时此值为随机

值。每发送一个广播帧

时就将当前值加1，当

达到255后翻转为0

广播源链路层地址

(MAC地址)，可以

为EUI-64地址或

16-bits短地址

SBroadcast RadiusSequence Number

Source Address，

广播范围，占7 bits,适

配层广播帧每经过一个

转发节点中继该值减

1，若减小到0停止转发

Broadcast字段的各个字段含义如下：

 S：广播源地址类型标志位，占1 bit。指出使用源地址是EUI-64长地址还是16-bits

短地址。若此位为0表示EUI-64地址；为1表示16-bits短地址。

 Broadcast Radius：广播范围，7 bits。适配层广播帧每经过一个转发节点中继该

字段值减1，若该字段减小到0转发节点停止继续转发该帧，但是本节点要将已经

收到的广播帧提交给上层处理。

 Sequence Number：广播帧序号，8 bits。每个节点需要维护一个变量来记录当前

的广播序号值，在节点初始化时将该值设为一个随机值(0~255)，每发送一个广播

帧时将=当前变量值填入Sequence Number字段并将该值加1，当达到255后翻转

为0。

 Source Address：广播帧源链路层地址，可以为EUI-64地址，也可以为16-bits

短地址。

3.分片和重组

当一个负载报文不能在一个单独的IEEE 802.15.4帧中传输时，需要对负载报文进行适配层

分片。此时，适配层帧使用4字节的分片头部格式而不是2字节的不分片头部格式。另外，

适配层需要维护当前的fragment_tag值并在节点初始化时将其置为一个随机值。

1) 分片

当上层下传一个超过适配层最大payload长度的报文给适配层后，适配层需要对该IP报文

分片进行发送。适配层分片的判断条件为：负载报文长度+不分片头部长+Mesh Delivery(或

Broadcast)字段长度 > IEEE 802.15.4 MAC层的最大payload长度。在使用16-bits短地

址并且不使用IEEE 802.15.4安全机制的情况下，负载报文的最大长度为95(127-25(MAC

头部)-2(不分片头部)-5（MD的长度）)字节。适配层分片的具体过程如下所示：

Payload

原始负载报文

适配层分片

01ProtocolMBSizeTag

第一片

MeshPayload Fragment

11Offset MBSizeTag

第二片

MeshPayload Fragment

10Offset MBSizeTag

第三片

MeshPayload Fragment

对于第一个分片：

 将分片头部的LF字段设置为01表示是第一个分片。

 Prot_type字段置为上层协议的类型。若是IPv6协议该字段置为1。另外，由于是

第一个分片，offset必定为0，所以在在该分片中不需要fragment_offset字段。

 用当前维护的datagram_tag值来设置datagram_tag字段；datagram_size字段填

写原始负载报文的总长度。

 若需要在Mesh网络中路由，Mesh Delivery字段应该紧随在分片头部之后并在负

载报文小分片之前。

对于后继分片：

 分片头部的LF字段设置为11或10，表示中间分片或最后一分片。

 fragment_offset 字段则设置为当前报文小分片相对于原负载报文起始字节的偏

移，需要注意的是这里的偏移是以8字节为单位的，因此每个分片的最大负载报文

小分片长度也必须是8字节边界对齐的，也就是说负载报文小分片的最大长度实际

上只有88字节。

当一个被分片报文的所有小分片都发送完成后datagram_tag加，当该值超过511后应该翻

转为0。

对于适配层广播帧，由于节点能量和资源方面的限制，对于一个较大的负载报文的多个分片

的广播给整个LowPAN网络带来严重的负担。因此，适配层可以选择禁止对需要进行适配层

广播报文(如IPv6组播报文)进行分片操作，适配层将丢弃超过其最大payload长度并且需

要进行广播的负载报文。

2) 重组

当适配层收到一个分片后，根据以下两个字段判断该分片是属于哪个负载报文的：

 源MAC地址

 适配层分片头部的datagram_tag字段

对于同一个负载报文的多个分片，适配层使用如下算法进行重组，其重组过程如下所示。

a. 如果是第一次收到某负载报文的分片，节点记录下该被分片的源MAC地址和

datagram_tag字段以供后继重组使用。需要注意的是，这里的源MAC地址应该

是适配层分片帧源发地址，若分片帧有Mesh Delivery字段的话，源MAC地址

应该是Mesh Delivery字段中的Originator Address字段。

b. 若已经收到该报文的其它分片，则根据当前分片帧的fragment_offset字段进

行重组。若发现收到的是一个重复但不重叠的分片，应该使用新收到的分片进

行替换。若本分片和前后分片有重叠，则应该丢弃当前分片，这样的目的主要

是简化处理，认为若出现这种情况一定是发送方出现了错误，不应该继续接收。

c. 若成功收到所有分片，将所有分片按offset进行重组，并将重组好的原始负

载报文递交给上层。同时，还需要删除在步骤(a)中记录源MAC地址和

datagram_tag字段信息。

Payload

原始负载报文

适配层重组

01ProtocolMBSizeTag

分片1

MeshPayload Fragment

11Offset MBSizeTag

分片2

MeshPayload Fragment

10Offset MBSizeTag

分片3

MeshPayload Fragment

重组一个分片的负载报文时需要使用一个重组队列来维护已经收到的分片以及其他一些信

息(源MAC地址和datagram_tag字段)。同时，为了避免长时间等待未达到的分片，节点还

应该在收到第一个分片后启动一个重组定时器，重组超时时间为15s，定时器超时后节点应

该删除该重组队列中的所有分片及相关信息。

3. 组播支持

IPv6组播对IPv6协议特别是邻居发现协议有非常重要的作用。此外，WSN的一些应用也需

要MAC层的广播功能。然而，IEEE 802.15.4 MAC层不支持组播仅提供有限的广播功能，这

就需要适配层利用受控广播泛洪的方式来在整个LowPAN网络中传播IPv6组播报文。

1） 适配层广播帧

6LowPAN使用适配层广播帧来封装IPv6组播报文或其它广播负载，格式如下所示。

在适配层广播帧中，适配层头部的B字段需要被置为1，并在适配层头部后添加一个

Broadcast字段。其中Broadcast字段的S标志位指出Source Address字段使用的是EUI-64

地址还是16-bits短地址，Broadcast Radius字段设置为本网络指定的最大广播跳数，

Sequence Number字段设置为节点当前的广播序号计数值，Source Address设置为本源节点

的MAC地址，负载报文将紧随在Broadcast字段之后。

2） 受控广播泛洪算法

在介绍受控广播泛洪算法之前，需要先给出6LowPAN逻辑节点的概念。运行IEEE 802.15.4

MAC协议的无线节点可以从硬件功能上分成全功能节点FFD(Full Function Device)和部分

功能节点RFD(Reduce Function Device)两类。为了从逻辑上划分各节点的不同协议行为，

在适配层上将节点分为PAN Coordinator、Common Coordinator以及End Device三类逻辑

节点。

 PANCoordinator：只能是全功能节点（FFD），在硬件上有着较为丰富的资源，可以

承担较为复杂的任务，是整个LowPAN网络的根节点。

 Common Coordinator：也只能是全功能节点(FFD),同PAN Coordinator相似，有着

较为丰富的资源，可作为PAN内部在MAC层上的路由器，为其邻居节点转发数据。

 End Device：可以使用全功能节点(FFD)也可以使用部分功能节点(RFD)，但是一

般考虑到End Device节点通常不需要太多的计算资源，因此通常从节点能耗方面

考虑采用部分功能节点(RFD)。

适配层使用的受控广播泛洪算法来发送适配层广播帧，其算法描述如下：源发节点或者中继

节点转发适配层广播帧时，应该首先检查其适配层邻居缓存，并根据邻居缓存信息处理：

（1） 若该节点的所有邻居均为PAN Coordinator或者Common Coordinator，

且均为该节点的子节点时，直接用IEEE 802.15.4 MAC层广播该适配层广播帧。

特别的，若只有一个PAN Coordinator或者Common Coordinator的邻居且其

为适配层广播帧的入口节点，不断转发适配层广播帧。

（2） 若该节点的部分邻居为End Device或者为该节点的父节点，并且不为适

配层广播帧的入口节点时，除了执行(1)中的IEEE 802.15.4 MAC层广播以外，

还要通过IEEE 802.15.4 MAC层广单播向该邻居发送该帧。

（3） 若该节点的邻居均为End Device或该节点的父节点，并且不为适配层广

播帧的入口节点时，只通过IEEE 802.15.4 MAC层单播向其每个邻居发送该帧。

下图即为使用受控广播泛洪算法时适配层广播帧在LowPAN网络中的传播过程。需

要注意的是该过程需要和广播风暴控制配合使用才能完成。

图 受控广播泛洪（1）

图 受控广播泛洪（2）

3） 广播风暴控制

6LowPAN使用受控广播泛洪算法可以大大减少需要发送的适配层广播帧数量，但是若使用

Mesh拓扑时，整个LowPAN网络拓扑中会存在大量环路。在这种存在环路的网络中，中继节

点对广播帧的重复转发将会造成严重的广播风暴。

为了避免广播风暴，每个节点需要记录已经转发过和适配层广播帧。具体做法是节点维护一

张广播记录表(BRT)，每张广播记录表中有若干个广播记录项(BRE)，每个广播记录项至少有

Source Address、Sequence Number和Broadcast Valid Time(广播有效时间，BVT)三个字

段，广播记录表的结构如下图所示。

图 广播记录表(BRT)

当节点收到一个适配层广播帧后，首先检查Broadcast字段中的Source Address：

 若是本地节点地址，直接丢弃；

 若不是本地节点，根据Broadcast字段中的Source Address和Sequence Number

来检查本节点维护的BRT：

 若在BRT中找到匹配并且BVT不为0的BRE，则认为该帧已经被本地节点收到

或者转发过，丢弃该广播帧；

 若没有找到，则认为是第一次收到该广播帧。节点需要为其新建一个BRE(源

发节点发送适配层广播帧时不需要在BRT中添加一个新的BRE)，并根据

Broadcast字段初始化BRE的Source Address和Sequence Number两个字段，

Broadcast Valid Time设置为本网络指定的广播有效时间值。同时，将

Broadcast字段中的Broadcast Radius减1，若该值减到0则停止转发，否则

使用受控广播泛洪算法继续转发该广播帧。最后，将新收到的适配层广播帧递

交给上层是。特别的，对于End Device，可以选择不对收到的广播帧进行转

发。

每个BRE中有一个Broadcast Valid Time字段，该值表示现一个适配层广播帧在网络中传

播的有效时间。协议栈定时减小该值，若该值减小到0，则认为适配层广播帧已经过期并删

除对应的BRE。若此后再收到Source Address和Sequence Number均相同的广播帧，节点

将不再认为是重复的适配层广播帧，仍然需要为其新建BRE并进行比较。

4. 头部压缩格式

由于LowPAN网络的特性，在实现IPv6在IEEE 802.15.4上的头部压缩时应当考虑最少的预

建上下文需求，也要求压缩方案尽量的简单直接。目前适配层支持3种压缩格式，分别是

LOWPAN_HC1格式，用于IPv6头部压缩；HC_UDP格式，用于UDP头部压缩;HC_ICMP压缩格

式，用于ICMPv6压缩。

在对IPv6、UDP以及ICMP进行压缩时需要使用这3种特定的压缩格式以及编码字段，同时，

适配层头部的prot_type字段应该设置为2，表示适配层头部后出现的是HC1编码字段。

1） LOWPAN_HC1格式

LOWPAN_HC1格式使用8-bits的HC1编码字段来对IPv6头部进行编码，其具体形式如下图

所示。

HC1 encodingNon-Compressed

LOWPAN_HC1

由于IPv6头部中源地址和目的地址占了很大的空间，所以需要对地址域专门进行编码。IPv6

地址由前缀和接口标识两部分组成，如果是Link-local地址的话，则前缀默认是FE80::/64

并可以在头部中省去；而对于接口标识来说，由于IID是从MAC地址生成的，所以可以从

IEEE 802.15.4MAC帧头部或者MeshDelivery字段中的源、目的地址重新组成IID，因此在

这种情况下接口标识也是可以省去的。这样，就有如下四种可能的地址字段编码方式：

PI：前缀在链路上传输(in-line)

PC：前缀被压缩(默认是link_local前缀)

II：接口标识符在链路上传输(in-line)

IC：接口标识符被压缩(从相应的链路层地址获得)

对于IPv6头部的非压缩字段，将出现在HC1，编码字段 (可能包括后继的HC2编码字段)之

后，首先是不被压缩的Hop Limit代字段，其它的未被压缩字段按HC1，编码字段中的顺序

出现。各个非压缩字段的出现顺序如下:Hop Limit(8 bits)、Source Address Prefix(64bts)

节and/or Interface Identifier(64 bits)、Destination Address Prefix(64 bits) and/or

Interface Identifier(64 bits)、Version(4 bits)、Traffic Class(8 bits)、Flow

Label(20 bits)、Next Header(8 bits)。

2） HC_UDP

HC_UDP格式使用 8 bits的HC_UDP编码字段来对UDP头部进行编码，其具体格式如下图所

示。

HC_UDP encoding

HC_UDP

Fields carried in-line

HC_UDP编码字段的具体格式如下：

 UDP Source Port(bit 0)

0:不压缩，在链路上传输；

1：压缩到4 bits。实际的16-bit源端口号使用如下方法计算出来：P+short_port。

其中P是双方预协商的一个基值，而short_port则在链路上传输的4-bit短端口号。P

是一个大于0的值，若使用该基值则Source port和Destination port均使用这个基

值P来进行压缩。

 UDP Destination Port(bit 1)

0:不压缩，在链路上传输；

1：压缩到4 bits。压缩方式同Source Port

 Length(bit 2)

0:不压缩，在链路上传输；

1：压缩，通过IPv6头部Length字段计算长度。

对于UDP头部的非压缩字段，将出现在IPv6头部及其相关字段之后，其未被压缩字段按原

UDP头部中的顺序出现。各个非压缩字段的出现顺序如下：Source port(16 bits)、

Destination port(16 bits)、Length(16 bits)、Checksum(16 bits)。

3） HC_ICMP

HC_ICMP格式使用8 bits的HC_ICMP编码字段来对ICMPv6进行编码，其具体形式如下所示：

HC_ICMP encoding

HC_ICMP

Fields carried in-line

 Type(bit 0)

 0：不压缩，在链路上传输

 1：Type字段在HC_ICMP编码字段的Compressed Type字段中指出

 Code(bit 1)

 0：不压缩，在链路上传输

 1：Code字段为0

 Reserved(bit 2)

 0：该32位被全部或部分使用，不压缩，在链路上传输

 1：ICMPv6报文头部后面的头32位是保留的，在这里被省去

 Compressed(bit 3-7)

 bit 3指出当前是错误报文还是信息报文(错误报文的最高位为0，而信息报文

的最高位为1，所以bit 3实际上对应ICMPv6头部Type字段的最高位)。bit

4到7则对应这ICMPv6 Type字段的低4位。若Type(bit 0)字段为0，bit 3

到7为全0。

对于ICMPv6的非压缩字段，将出现在IPv6头部及其相关字段之后，其未被压缩字段按原

ICMP头部中的顺序出现。各个非压缩字段的出现顺序如下：Type(8 bits)、Code(8 bits)、

Checksum(16 bits)、In-use 32 bits Field(32 bits)。

（注：可编辑下载，若有不当之处，请指正，谢谢!）

本文标签： 分片节点适配广播报文