6Lowpan报头压缩

IPv6 的地址分为两部分，前 64bit 为网络前缀，后 64bit 为接口标识。网络前缀的表示方式类似于 IPv4 中的 CIDR （ClasslessInterDomain Routing）无类域间路由地址的表示方式，IPv6 节点地址中指出了前缀长度，该长度在斜杠之后用一数值表示。例如 2002:241:f000::/48 表示前缀为 48 位的地址空间，剩下的 80 位可分配给网络中的主机，这样一共具有 2 的 80 次方个地址。IPv6 中接口标识部分也为 64 位，并非是为了在一个子网上支持 2 的 64 次方台主机，而是为了便于与 48 位的 MAC 地址进行映射，并为了方便今后与 IEEE1394（FireWire 火线）和 EUI-64（未来局域网所使用的 64 位的 MAC 地址）进行映射做好准备。

在现阶段，为了将IEEE802 地址映射为 IEEE EUI-64 地址，使用的方法是在IEEE802 地址扩展 ID 之前插入 16 位的1111111111111110（0xFFFE）。

 

 

6lowpan中地址映射

即802.15.4中长地址和短地址映射为ipv6地址

所有的802.15.4设备都有一个IEEE EUI－64地址，但16位短地址（节3和节12）也同样是可能的。对于前者可以按照以太网上的ipv6进行处理；对于后者：一个“假的48位地址”的产生过程如下。首先，左32位由16位0和16位PAN ID（作为选择，如果不知道PANID，就用16位0）组成。这样产生的32位域如下所示：

16位PAN ID

16位0

然后，这个32位后面连接的是16位短地址。这样产生的48位地址如下所示：

16位PAN ID

16位0

16位短地址

由这个48位地址产生的接口标识符如同“以太网上的IPv6”说明[RFC2464]一样。然而，在合成的接口标识符里，为了符合这个不是全局唯一值这个事实，“全局/本地”（U/L）位应该设置为0。对于这两种地址格式，不可以使用全0的地址。

另一个由人工或软件设置的MAC地址可以用来成生接口标识符。如果使用了这个MAC地址，它的全局唯一性应该体现在U/L位的值上。

在IEEE802.15.4接口上用于无状态自动配置[RFC4862]的IPv6地址前缀长度必须是64位的。

 

RFC4944的更新文档RFC6282中给出了关于短地址的一种新的映射方法

一个 IEEE802.15.4 短地址是 16 位长的。 短地址映射到了 IEEE EUI-64 的限制空间里，中间16 位是 0xfffe，后 16 位是短地址，其余的都是0。因此，从一个短地址中生成的 IID 如下形式：

0000：00ff：fe00：XXXX

其中 XXXX 是短地址。全局/本地位是 0 表示这是本地的。这个映射对于非EUI-64 标识符的与[RFC4291]附录 A是不一样的。使用限制空间保证了从无限制的 IEEE EUI-64 地址生成的 IIDs 不会产生重叠。同样，在 IID 中间包含 0xfffe 也避免了与其他本地的IIDs 产生重叠。

这种从IEEE  802.15.4 短地址到 64 位的 IIDs 的映射也同样用于重建IID 的不包含上下文信息的其他部分。

 

2.2.3 HC1 和 HC2 报头压缩编码（rfc4944）

首先介绍 IPv6 报头的 HC1 压缩编码。

当 Dispatch 的值为 11 000010 时，表示接下来的字段是HC1 压缩控制报头,用来压缩 IPv6 的报头，下面表示的是 HC1 压缩控制报头结构：

从图中可以看到，HC1 由 HC1 编码域（8 位）和非压缩域组成。编码域仅仅用一个字节的大小就完成了对 IPv6 基本报头中的压缩编或指示。本文首先分析一种能最大程度压缩报头的情况，这种情况需要同时具备以下几个条件：（这只是最大程度，也有其他情况）

（1）版本是 IPv6；

（2）IPv6 的源地址和目的地址都属于本地链路，即网络前缀是 FE80::/64；（一般为本地链路，也会使用其他地址）

（3）源地址和目的地址的接口标识符（均为 64bit）可以从802.15.4MAC 层地址推算出来；

（4）数据包长度可以从 802.15.4 的 PPDU 的帧长度或者从分片控制报头的datagram_size 中推算出来；

（5）Traffic Class 和 Flow Label都是 0；

（6）Next Header 是 UDP，ICMP 或者 TCP；

在 IPv6 中报头中唯一不能被压缩的字段是跳数限制（Hop Limit），它需要在非压缩域中完整传输。

其他假设的情况，如果与上述情况越接近，则 IPv6 报头能被压缩的程度也越大。首先对 IPv6 地址的 HC1 编码压缩进行分析，前缀（Prefix）部分就有在链路（in-line）上传输和压缩后（Compressed）传输这两种方式；接口标识部分也有两种编码方式，一种即直接在链路上传输，另一种则直接删去（elided）（可以用 MAC 层的地址推导出来）。

IPv6 中除了地址可以被 HC1 压缩外，还有其他字段也可以被HC1 压缩，接下来按照 HC1 编码字段的格式对各个部分进行介绍：

（1）IPv6 源地址 （第 0 位和第 1 位）

00：网络前缀和接口标识都链路上传输；（既然前缀是固定的本地链路，为什么不能默认省略）（因为这只是最大程度，也有其他情况）

01：网络前缀在链路上传输，接口标识直接删掉；

10：网络前缀压缩后传输（也即删掉），接口标识在链路上传输；

11：网络前缀压缩后传输，接口标识直接删掉。

（2）IPv6 目的地址 （第 2 位和第 3 位）

00：网络前缀和接口标识都链路上传输；

01：网络前缀在链路上传输，接口标识直接删掉；

10：网络前缀压缩后传输，接口标识在链路上传输；

11：网络前缀压缩后传输，接口标识直接删掉。

（3）V_T_F整合字段（包括版本号、数据流类和流标号）（第 4 位）

0：数据流类和流标号都不压缩，直接在链路上传输；

1：数据流类和流标号均默认为 0。

（4）下一首部 （第 5 位和第 6 位）

00：直接将下一首部的完整字段在链路上予以传输；

01：上层使用的是 UDP 协议，下一首部为 UDP报头；

10：上层使用的是 ICMP 协议，下一首部为ICMP 报头；

11：上层使用的是 TCP 协议，下一首部为 TCP报头。

（5）HC2 编码指示 （bit 7）

0：对上层的协议不再使用 HC2 压缩编码；

1：根据 HC1 编码字段的下一首部（第 5 位和第 6 位）的值，对上层相应协议进行相应的 HC2 压缩。

考虑到使用和不使用HC2 编码压缩的两种情况，也就有两种 HC 编码格式，一种在图2-16 已经予以给出，在 HC1 编码字段后紧接的是未压缩域；另一种则同时使用了 HC1 和 HC2 编码压缩，在这种 HC 编码格式中，HC2 编码字段位于HC1 编码字段之后、未压缩域之前。另外即使在未压缩域中，IPv6 的未压缩字段也有个前后排列顺序，如下所示：

01 跳数限制 Hop Limit （8 bits）

02 源地址网络前缀 Source Address Prefix （64 bits）

03 源地址接口标识符 Interface Identifier （64 bits）

04 目的地址网络前缀 Destination Address Prefix （64 bits）

05 目的地址接口标识符 Interface Identifier （64 bits）

06 版本号 Version （4 bits）

07 数据流类 Traffic Class （8 bits）

08 流标号 Flow Label （20 bits）

09 下一首部 Next Header （8 bits）

在上述可以进行最大化压缩的情况下，IPv6 基本报头的终端源/目的地址、V_T_F 代表的字段以及下一首部都被压缩到 HC1 编码字段中，该字段大小只有一个字节，而跳数限制字段（1 个字节大小）无法被压缩，只能在未压缩域中传输，因此整个 IPv6 基本报头的 40 个字节可以被压缩到 2 个字节。

在 IPv6 的基础上，传输层使用的协议如果是 UDP 或者 IMCP 或者 TCP，HC1的下一首部字段的值会予以指定，并且可以根据系统需求来确定是否使用 HC2 压缩编码对传输层数据报头进行压缩。由于本系统在传输层使用的是 UDP 报文，这里将主要分析 UDP 报头的 HC2 压缩编码。

在 UDP 数据报头中可以被 HC2 编码压缩的部分是源/目的端口地址及报文长度，校验和字段是无法被压缩的，下图是 UDP 的数据报文格式，也就是说只有前三个字段可以被压缩。

与 HCl 类似地，HC2 压缩控制报头的结构也由两部分组成，即 HC_UDP 编码域和链路传输域：

其中 HC_UDP 的编码域也是 8 位长度，下面按各位的编码顺序介绍每一位的编码含义：

（1）UDP 源端口号 （第 0 位）

0：直接将源端口号在链路上传输，不进行压缩；

1：将源端口号压缩到只有 4 位长度短端口号。使用公式“P+短端口号=16 位端口号”来计算得到实际的源端口号，其中 P 值为 61616（0xF0B0）。这样在只需要在链路上传输 4 位的短端口号即可。

该方法允许对一些特别的端口号（0xf0b0~0xf0bf）压缩到 4 位；

（2）UDP 目的端口号 （第 1 位）

0：直接将目的端口号在链路上传输，不进行压缩；

1：将目的端口号压缩到只有 4 位长度短端口号，压缩方式同上。

（3）报文长度 （第 2 位）

0：直接将报文长度在链路上传输，不进行压缩；

1：不传输，直接根据 IPv6 报头计算得到，计算公式为“IPv6 报头中载荷长度值-IPv6 扩展报头长度=UDP 报文长度”。（而IPV6报头中数据包长度若被压缩，可是通过ppdu得到的）

（4）保留字段（第 3 至 7 位）

在 HC_UDP 编码域之后便是链路传输域，该域传输的即是 UDP 报头中未被压缩的字段的值或经过压缩后的短端口号，这些值紧跟在 HC_UDP 编码域之后传输，整个 HC2 编码出现在 IPv6 头部及其相关字段之后。另外，与 HC1 未压缩域类似，UDP 报头中未被压缩的字段在HC2 的链路传输域中出现的排列顺序也有一定要求，如下所示：

01 UDP 源端口号 Source port（4 或 16 bits）

02 UDP 目的端口号 Destination port（4 或 16 bits）

03 长度 Length（16bist）

04 校验和 Checksum（16bist）

对上述分析进行一个总结，当源/目的端口号采用 4 位短端口号在链路上进行传输且报文长度是由计算得到的时候，原本 8 字节长度的 UDP 报头，被压缩到只有 4 字节，其中一字节 HC_UDP 编码域，一字节是源/目的短端口号，另两字节是未被压缩的校验和字段。

 

更新后的报头压缩LOWPAN_IPHC和LOWPAN_NHC（RFC6282）

详见文档