将RFC 6282称为压缩格式。该摘要的工作方式非常简短：
压缩格式依赖于
共享上下文来允许压缩任意前缀。
如何在该共享上下文中维护信息超出了范围。空间。确切地说，如何管理“共享上下文”？为什么每个IPv6设备（例如我的计算机）都不使用此压缩？
#1 楼
RFC草案更好地解释了头压缩的工作原理。摘要中被描述为任意前缀的本质上是一堆信息，这些信息被假定为处于一定范围内或具有特定值。因此，不必传输那些信息。为了实现有效压缩，LOWPAN_IPHC依赖于与整个6LoWPAN有关的信息。整个6LoWPAN，分解下一句话，我们有六个信息被认为是已知的，或者值的范围很小。
版本为6；
流量类别和流量标签均为零；
可以从6LoWPAN Fragmentation报头或IEEE 802.15.4报头的较低层推断有效负载长度。
源的跳数限制将设置为众所周知的值；分配给6LoWPAN接口的
地址将使用link-local
前缀或分配给整个6LoWPAN的一小组可路由前缀形成。
分配给6LoWPAN接口的地址由直接从64位扩展或16位短的IEEE 5.4地址直接导出的IID构成。
（我要指出的是项目符号，否则请继续草案的第3节。）
这也解释了为什么您的PC等设备未使用这种压缩方式。您的PC必须能够基本处理整个世界。但是，如上所述的压缩只有在足够受约束的环境（整个6LoWPAN）而不是整个环境中使用时才真正有效。
在最佳情况下，LOWPAN_IPHC可以压缩IPv6。标头下降到两个八位字节（调度八位字节和LOWPAN_IPHC编码），并通过本地链接进行通信。如RFC草案中所述，在更严格的环境中，压缩会变得更好。仅对于本地链接，它降至两个八位位组。当然，我们希望普通的计算机和终端设备能够处理其他所有问题。但是，如果我们希望能够更改所有这些值，则该压缩将被视为已不再起作用。我们的意思与其他网络参与者认为的意思不匹配，因为压缩的价值是理所当然的。标头，以及在定义明确的小型环境中获得的时间和精力效率。