我一直在阅读6LoWPAN协议（由 Thread 和其他网络协议使用），它似乎对网络非常有用，并且具有允许每个设备轻松寻址的优点。
维基百科说 6LoWPAN 使用一种报头压缩形式来减少传输大小（从而节省时间和能源）：
用于低功率无线电通信的 IP 网络的目标是需要以较低数据速率为外形尺寸非常有限的设备进行无线互联网连接的应用程序。一个例子是家庭、办公室和工厂环境中的自动化和娱乐应用。RFC6282 中标准化的报头压缩机制可用于在此类网络上提供 IPv6 数据包的报头压缩。
它引用RFC 6282作为使用的压缩格式。抽象是相当短暂的如何它的工作原理：
压缩格式依赖于共享上下文来允许压缩任意前缀。如何在该共享上下文中维护信息超出了范围。
据我所知，“共享上下文”用于省略一些标题字段并节省空间。这个“共享上下文”究竟是如何管理的，为什么不是每个 IPv6 设备（例如我的计算机）都使用这种压缩？
该RFC草案解释好一点的报头压缩是如何工作的。抽象中所描述的任意前缀本质上是一堆假设在某个范围内或具有特定值的信息。因此，不需要传输这些信息。
为了启用有效压缩，LOWPAN_IPHC 依赖于与整个 6LoWPAN 相关的信息。
这个假设适用于整个 6LoWPAN，分解下一个句子，我们有六个信息，这些信息假设是已知的或在相当小的值范围内。
- 版本为 6；
（我的要点，否则继续草案的第三部分。）
这也解释了为什么您的 PC 等设备不使用这种压缩。您的 PC 必须能够基本上处理整个世界。然而，上述压缩只有在充分受限的环境（整个 6LoWPAN）中使用时才真正有效，而不是在整个世界中使用。
在最好的情况下，LOWPAN_IPHC 可以通过本地链路通信将 IPv6 报头压缩为两个八位字节（调度八位字节和 LOWPAN_IPHC 编码）。
（仍然是草稿部分）
正如 RFC 草案中所描述的，当它处于更受限制的环境中时，压缩会变得更好。对于仅本地链接，它可以减少到两个八位字节。当然，我们希望我们常用的计算机和终端设备能够解决其他所有问题。但是，如果我们希望能够更改所有这些值，则此压缩理所当然地不再起作用。我们的意思和每个其他网络参与者认为我们的意思之间会存在不匹配，因为压缩认为值是理所当然的。
因此，压缩严重限制了 IPv6在一个非常明确的小环境中到达更小的报头和获得时间和能量效率的巨大可能性。