1. 简介 (Introduction)
1. 简介 (Introduction)
[IEEE802.15.4] 标准规定 MTU 为 127 字节. 在启用安全的情况下, 对于链路吞吐量为 250 kbps 或更低的无线链路, 实际媒体访问控制 (Media Access Control, MAC) 负载约为 80 个八位字节. 6LoWPAN 适配格式 [RFC4944] 被规定用于在这类受限链路上传送 IPv6 数据报, 同时考虑无线传感器网络等应用中预期存在的有限带宽、内存或能量资源. [RFC4944] 定义了 Mesh Addressing 头部以支持子 IP 转发, 定义了 Fragmentation 头部以支持 IPv6 最小 MTU 要求 [RFC2460], 并定义了 IPv6 数据报的无状态头部压缩 (LOWPAN_HC1 和 LOWPAN_HC2), 以将相对较大的 IPv6 和 UDP 头部在最佳情况下缩减到几个字节.
对于 6LoWPAN 中 IPv6 的大多数实际用途, LOWPAN_HC1 和 LOWPAN_HC2 并不足够. LOWPAN_HC1 对链路本地单播通信最有效, 在这种通信中, IPv6 地址携带链路本地前缀和直接从 IEEE 802.15.4 地址派生的接口标识符 (Interface Identifier, IID). 在这种情况下, 两个地址都可以完全省略. 但是, 尽管链路本地地址常用于 IPv6 邻居发现 [RFC4861]、DHCPv6 [RFC3315] 或路由协议等本地协议交互, 它们通常不用于应用层数据流量, 因而这种压缩机制的实际价值有限.
当与 6LoWPAN 外部设备通信, 或者在 6LoWPAN 内发生 IP 转发的 route-over 配置中通信时, 必须使用可路由地址. 对于可路由地址, LOWPAN_HC1 要求 IPv6 源地址和目的地址都以内联方式携带前缀. 在不使用 Mesh Addressing 头部的情况下, 可路由地址的 IID 必须以内联方式携带. 但是, LOWPAN_HC1 在内联携带 IID 时要求使用 64 bit, 即使该 IID 派生自 IEEE 802.15.4 的 16 bit 短地址, 也无法缩短. 当目的地址是 IPv6 组播地址时, LOWPAN_HC1 要求以内联方式携带完整的 128 bit 地址.
因此, 本文档定义了一种编码格式 LOWPAN_IPHC, 用于基于上下文中的共享状态有效压缩唯一本地、全局和组播 IPv6 地址. 此外, 本文档还在 [RFC4944] 定义的头部压缩格式基础上引入了若干额外改进.
LOWPAN_IPHC 允许压缩一些常用 IPv6 Hop Limit 值. 如果 6LoWPAN 是 mesh-under stub, 对应用层数据流量来说, 入站 Hop Limit 为 1, 出站使用 64 等默认值通常已经足够. 此外, Hop Limit 值 255 经常用于验证通信发生在单跳范围内. 本规范支持在这些常见情况下压缩 IPv6 Hop Limit 字段, 而 LOWPAN_HC1 不支持.
本文档还定义了 LOWPAN_NHC, 这是一种用于任意下一头部的编码格式. LOWPAN_IPHC 指示后续头部是否使用 LOWPAN_NHC 编码. 如果是, 则紧随压缩 IPv6 头部之后的 bit 开始 LOWPAN_NHC 编码. 相比之下, LOWPAN_HC1 可以扩展为使用 LOWPAN_HC2 支持下一头部压缩, 但仅限 UDP、TCP 和 ICMPv6. 此外, LOWPAN_HC2 八位字节位于 LOWPAN_HC1 八位字节和未压缩 IPv6 头部字段之间. 本规范将下一头部编码 bit 移到所有 IPv6 相关 bit 之后, 从而支持适当分层的结构, 并直接支持 IPv6 扩展头部.
本文档使用 LOWPAN_NHC 定义了 UDP 压缩机制. 虽然 [RFC4944] 定义了 UDP 压缩机制, 但当上层消息完整性检查 (Message Integrity Check, MIC) 等额外上层机制使校验和压缩成为可能时, 该机制并不支持这种压缩. 本规范增加了在 6LoWPAN 上省略 UDP 校验和的能力, 从而可进一步节省两个八位字节.
此外, 本文档使用 LOWPAN_NHC 定义了 IPv6-in-IPv6 封装以及 IPv6 扩展头部的编码格式. 使用 LOWPAN_HC1 和 LOWPAN_HC2 时, 下一头部链无法被高效编码.
1.1 规范性语言 (Requirements Language)
本文档中的关键词 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 和 "OPTIONAL" 应按照 RFC 2119 [RFC2119] 中的描述进行解释.