跳到主要内容

RFC 4944 - 通过 IEEE 802.15.4 网络传输 IPv6 数据包 (Transmission of IPv6 Packets over IEEE 802.15.4 Networks)

  • 状态: Proposed Standard
  • 发布日期: September 2007
  • Stream: IETF
  • 勘误: 无勘误

摘要​

本文档描述了在 IEEE 802.15.4 网络上传输 IPv6 数据包 (IPv6 Packets) 所使用的帧格式 (Frame Format), 以及在这些网络上形成 IPv6 链路本地地址 (Link-Local Addresses) 和无状态自动配置地址 (Stateless Autoconfiguration) 的方法. 附加规范包括使用共享上下文的简单报头压缩方案 (Header Compression), 以及 IEEE 802.15.4 网状网络 (Mesh Networks) 中的数据包交付规定.

目录​

附录 (Appendices)​

相关资源​

1. 简介 (Introduction)​

IEEE 802.15.4 标准 [ieee802.15.4] 面向低功耗个人区域网络 (Low-Power Personal Area Networks). 本文档定义了在 IEEE 802.15.4 网络上传输 IPv6 [RFC2460] 数据包的帧格式, 以及在 IEEE 802.15.4 网络之上形成 IPv6 链路本地地址 (Link-Local Addresses) 和无状态自动配置地址 (Statelessly Autoconfigured Addresses) 的方法. 由于 IPv6 需要支持远大于 IEEE 802.15.4 最大帧大小的数据包大小, 因此定义了一个适配层 (Adaptation Layer). 本文档还定义了使 IPv6 在 IEEE 802.15.4 网络上实用所需的报文头压缩 (Header Compression) 机制, 以及在 IEEE 802.15.4 网状网络 (Meshes) 中进行数据包传递所需的规定. 然而, 完整的网状网络路由规范 (使用的特定协议,与邻居发现的交互等) 超出了本文档的范围.

1.1. 需求符号表示法 (Requirements Notation)​

本文档中的关键词 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 和 "OPTIONAL" 应按 [RFC2119] 中的描述进行解释.

1.2. 术语 (Terms Used)​

AES: Advanced Encryption Scheme (高级加密方案)

CSMA/CA: Carrier Sense Multiple Access / Collision Avoidance (载波侦听多路访问/冲突避免)

FFD: Full Function Device (全功能设备)

GTS: Guaranteed Time Service (保证时隙服务)

MTU: Maximum Transmission Unit (最大传输单元)

MAC: Media Access Control (介质访问控制)

PAN: Personal Area Network (个人区域网络)

RFD: Reduced Function Device (简化功能设备)

2. IEEE 802.15.4 Mode for IP (用于IP的IEEE 802.15.4模式)​

IEEE 802.15.4 定义了四种类型的帧: 信标帧 (Beacon Frames),MAC 命令帧 (MAC Command Frames),确认帧 (Acknowledgement Frames) 和数据帧 (Data Frames). IPv6 数据包必须 承载在数据帧上. 数据帧可以选择性地请求被确认 (Acknowledged). 与 [RFC3819] 保持一致,推荐将 IPv6 数据包承载在请求确认的帧中, 以辅助链路层恢复 (Link-Layer Recovery).

IEEE 802.15.4 网络可以是非信标使能 (Nonbeacon-Enabled) 或信标使能 (Beacon-Enabled) 的 [ieee802.15.4]. 后者是一种可选模式, 在该模式下, 设备通过所谓的协调器 (Coordinator) 的信标进行同步. 这允许使用超帧 (Superframes), 在超帧内可以实现无竞争的保证时隙服务 (Guaranteed Time Service, GTS). 本文档不要求 (NOT REQUIRE) IEEE 网络运行在信标使能模式下. 在非信标使能网络中, 数据帧 (包括承载 IPv6 数据包的帧) 通过基于竞争的非时隙 CSMA/CA 信道访问方法 (Contention-Based Channel Access Method of Unslotted CSMA/CA) 发送.

在非信标使能网络中, 信标不用于同步. 然而, 它们对于链路层设备发现 (Link-Layer Device Discovery) 仍然很有用, 以辅助关联 (Association) 和解除关联 (Disassociation) 事件. 本文档建议 (RECOMMENDS) 配置信标以辅助这些功能. 进一步的建议是使这些事件在 IPv6 层可用, 以辅助检测网络附着 (Network Attachment), 这是本文档撰写时 IETF 正在研究的问题.

该规范允许源地址或目标地址 (或两者) 被省略 (Elided) 的帧. 本文档中定义的机制要求 (REQUIRE) 在 IEEE 802.15.4 帧头 (Frame Header) 中必须包含源地址和目标地址. 源或目标 PAN ID 字段也可以被包含.

3. Addressing Modes (寻址模式)​

IEEE 802.15.4 定义了几种寻址模式 (Addressing Modes): 它允许使用 IEEE 64 位扩展地址 (64-bit Extended Addresses), 或 (在关联事件之后) PAN 内唯一的 16 位地址 [ieee802.15.4]. 本文档同时支持 64 位扩展地址和 16 位短地址 (Short Addresses).

对于在 6LoWPAN 内使用, 本文档对 16 位短地址的格式施加了额外的约束 (除了 IEEE 802.15.4 施加的约束之外), 如第 12 节所规定. 由于短地址本质上是临时的 (Transient), 需要特别注意: 由于它们是在关联事件期间由 PAN 协调器功能 (PAN Coordinator Function) 分配的, 其有效性和唯一性受到该关联生命周期的限制. 这可能因关联过期或 PAN 协调器发生任何故障而缩短. 由于这种集中式分配和 PAN 协调器处的单点故障 (Single Point of Failure) 带来的可扩展性问题, 部署者应仔细权衡基于短地址扩展此类网络的利弊 (并实施必要的机制). 当然, IEEE 64 位扩展地址可能不会遭受这些缺陷, 但仍然共享有关路由,发现,配置等方面的其余可扩展性问题.

本文档假设一个 PAN 映射到一个特定的 IPv6 链路 (IPv6 Link). 这符合共享网络应支持链路层子网 [RFC3819] 广播的建议. 严格来说, IPv6 中存在的是多播 (Multicast) 而非广播 (Broadcast). 然而, IEEE 802.15.4 本身不支持多播. 因此, IPv6 层多播数据包必须 作为链路层广播帧在 IEEE 802.15.4 网络中承载. 这必须 以这样的方式完成, 即广播帧仅被所讨论链路的特定 PAN 内的设备注意. 根据 [ieee802.15.4] 第 7.5.6.2 节, 这通过以下方式实现:

  1. 帧中必须 包含目标 PAN 标识符 (Destination PAN Identifier), 并且它必须 与所讨论链路的 PAN ID 匹配.

  2. 帧中必须 包含短目标地址 (Short Destination Address), 并且它必须 与广播地址 (0xffff) 匹配.

此外, 根据第 9 节的 IPv6 多播地址映射支持必须 仅在网状网络配置 (Mesh Configuration) 中使用. 此类功能的完整规范超出了本文档的范围.

如往常一样, 主机通过路由器通告 (Router Advertisements) 学习 IPv6 前缀, 如 [RFC4861] 所述.

4. Maximum Transmission Unit (最大传输单元)​

IEEE 802.15.4 上 IPv6 数据包的 MTU 大小为 1280 个八位字节 (Octets). 然而, 完整的 IPv6 数据包无法适应一个 IEEE 802.15.4 帧. 802.15.4 协议数据单元 (Protocol Data Units) 具有不同的大小, 取决于存在多少开销 [ieee802.15.4]. 从最大物理层数据包大小 127 个八位字节 (aMaxPHYPacketSize) 和最大帧开销 25 (aMaxFrameOverhead) 开始, 介质访问控制层 (Media Access Control Layer) 的最终最大帧大小为 102 个八位字节. 链路层安全 (Link-Layer Security) 会施加进一步的开销, 在最坏情况下 (AES-CCM-128 情况下为 21 个八位字节的开销, 而 AES-CCM-32 和 AES-CCM-64 分别为 9 和 13), 仅剩下 81 个八位字节可用. 这显然远低于 IPv6 的最小数据包大小 1280 个八位字节, 并且根据 IPv6 规范 [RFC2460] 第 5 节,必须在 IP 层之下的层提供分片和重组适配层 (Fragmentation and Reassembly Adaptation Layer). 这样的层在下面的第 5 节中定义.

此外, 由于 IPv6 报文头长度为 40 个八位字节, 这仅为上层协议 (如 UDP) 留下 41 个八位字节. 后者在报文头中使用 8 个八位字节, 这仅为应用数据 (Application Data) 留下 33 个八位字节. 此外, 如上所述, 需要一个分片和重组层, 它将使用更多的八位字节.

上述考虑导致以下两个观察结果:

1.必须提供适配层以符合 IPv6 最小 MTU 的要求. 然而, 预计 (a) IEEE 802.15.4 的大多数应用不会使用如此大的数据包, 以及 (b) 较小的应用负载 (Application Payloads) 与适当的报文头压缩 (Header Compression) 结合将产生适合单个 IEEE 802.15.4 帧的数据包. 此适配层的理由不仅仅是为了 IPv6 合规性, 因为某些应用交换 (例如, 配置或供应 (Provisioning)) 产生的数据包大小很可能需要少量分片.

  1. 即使上述空间计算显示了最坏情况, 它确实指出报文头压缩几乎是不可避免的. 由于我们预计 IP over IEEE 802.15.4 的大多数 (如果不是全部) 应用将使用报文头压缩, 因此在下面的第 10 节中对其进行了定义.

5. LoWPAN Adaptation Layer and Frame Format (LoWPAN适配层和帧格式)​

本节中定义的封装格式 (Encapsulation Formats, 后续称为 "LoWPAN 封装") 是 IEEE 802.15.4 MAC 协议数据单元 (Protocol Data Unit, PDU) 中的有效载荷. LoWPAN 有效载荷 (例如, 一个 IPv6 数据包) 紧跟在该封装报文头之后.

所有通过 IEEE 802.15.4 传输的 LoWPAN 封装数据报 (Datagrams) 都以一个封装报文头栈 (Encapsulation Header Stack) 作为前缀. 报文头栈中的每个报文头包含一个报文头类型 (Header Type), 后跟零个或多个报文头字段. 在 IPv6 报文头中, 栈将按以下顺序包含: 寻址 (Addressing),逐跳选项 (Hop-by-Hop Options),路由 (Routing),分片 (Fragmentation),目标选项 (Destination Options), 最后是有效载荷 [RFC2460]; 在 LoWPAN 报文头中, 类似的报文头序列是网状网络 (L2) 寻址,逐跳选项 (包括 L2 广播/多播),分片, 最后是有效载荷.

典型报文头栈示例:

LoWPAN 封装的 IPv6 数据报:

+---------------+-------------+---------+
| IPv6 Dispatch | IPv6 Header | Payload |
+---------------+-------------+---------+

需要网状网络寻址和分片的情况:

+-------+-------+-------+-------+---------+---------+---------+
| M Typ | M Hdr | F Typ | F Hdr | HC1 Dsp | HC1 Hdr | Payload |
+-------+-------+-------+-------+---------+---------+---------+

当在同一数据包中使用多个 LoWPAN 报文头时, 它们必须 按以下顺序出现: 网状网络寻址报文头,广播报文头,分片报文头.

5.1. Dispatch Type and Header (分派类型和报文头)​

分派类型由前两位 "01" 定义, 6比特选择器标识紧随其后的报文头类型.

分派值比特模式:

  • 00 xxxxxx - NALP: 不是 LoWPAN 帧
  • 01 000001 - IPv6: 未压缩的 IPv6 地址
  • 01 000010 - LOWPAN_HC1: HC1 压缩的 IPv6
  • 01 010000 - LOWPAN_BC0: BC0 广播
  • 01 111111 - ESC: 附加分派字节
  • 10 xxxxxx - MESH: 网状网络报文头
  • 11 000xxx - FRAG1: 首个分片报文头
  • 11 100xxx - FRAGN: 后续分片报文头

5.2. Mesh Addressing Type and Header (网状网络寻址类型和报文头)​

网状网络类型由前两位 "10" 定义:

|1 0|V|F|HopsLft| originator address, final address

字段定义:

  • V: 1比特, 0表示发起者地址为64位, 1表示16位短地址
  • F: 1比特, 0表示最终目标地址为64位, 1表示16位短地址
  • Hops Left: 4比特, 每转发一次递减, 为0时丢弃. 0xF表示后续有8比特扩展字段
  • Originator Address: 发起者的链路层地址
  • Final Destination Address: 最终目标的链路层地址

5.3. Fragmentation Type and Header (分片类型和报文头)​

如果数据报不适合单个 802.15.4 帧, 应 分解为链路分片. 除最后一个外, 所有分片必须 是8字节的倍数.

首个分片报文头 (FRAG1):

|1 1 0 0 0| datagram_size | datagram_tag |

后续分片报文头 (FRAGN):

|1 1 1 0 0| datagram_size | datagram_tag |
|datagram_offset|

字段定义:

  • datagram_size: 11比特, 编码整个IP数据包大小 (链路层分片前). 对于IPv6, 值为Payload Length + 40
  • datagram_tag: 16比特, 同一数据报的所有分片具有相同标签, 发送者为连续数据报递增此值
  • datagram_offset: 8比特, 以8字节为单位的分片偏移量, 仅出现在后续分片中

重组规则:

接收者使用以下信息识别属于同一数据报的分片:

  1. 发送者的802.15.4源地址 (或网状网络发起者地址)
  2. 目标的802.15.4地址 (或网状网络最终目标地址)
  3. datagram_size
  4. datagram_tag

重组超时必须 设置为最多60秒. 检测到解除关联事件时,必须丢弃所有部分重组的分片.

6. Stateless Address Autoconfiguration (无状态地址自动配置)​

本节定义如何获取 IPv6 接口标识符 (Interface Identifier).

IEEE 802.15.4 接口的接口标识符 [RFC4291] 可以基于分配给 IEEE 802.15.4 设备的 EUI-64 标识符 [EUI64]. 在这种情况下, 接口标识符根据 "IPv6 over Ethernet" 规范 [RFC2464] 从 EUI-64 形成.

所有 802.15.4 设备都有一个 IEEE EUI-64 地址, 但 16 位短地址 (第 3 节和第 12 节) 也是可能的. 在这些情况下, 按以下方式形成 "伪 48 位地址" (Pseudo 48-bit Address). 首先, 通过将 16 个零比特连接到 16 位 PAN ID 来形成最左边的 32 位 (或者, 如果不知道 PAN ID, 可以使用 16 个零比特). 这产生如下 32 位字段:

16_bit_PAN:16_zero_bits

然后, 将这 32 位与 16 位短地址连接. 这产生如下 48 位地址:

32_bits_as_specified_previously:16_bit_short_address

接口标识符根据 "IPv6 over Ethernet" 规范 [RFC2464] 从这个 48 位地址形成. 然而, 在结果接口标识符中, "Universal/Local" (U/L) 比特应 设置为零, 以符合这不是全局唯一值的事实. 对于任一地址格式,不得使用全零地址.

手动或通过软件设置的不同 MAC 地址可以 用于派生接口标识符. 如果使用这样的 MAC 地址, 其全局唯一性属性应该反映在 U/L 比特的值中.

用于 IEEE 802.15.4 接口的无状态自动配置 [RFC4862] 的 IPv6 地址前缀必须 长度为 64 位.

9. Multicast Address Mapping (多播地址映射)​

本节中的功能必须 仅在启用网状网络的 LoWPAN 中使用. 具有多播目标地址 (DST) 的 IPv6 数据包, 由十六个八位字节 DST[1] 到 DST[16] 组成, 被传输到以下 802.15.4 16 位多播地址:

                   0                   1
                   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  |1 0 0|DST[15]* |   DST[16]     |
                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

图 8: 多播地址映射格式

这里, DST[15]* 指的是八位字节 DST[15] 中的最后 5 位, 即 DST[15] 内的比特 3-7. 初始的 3 比特模式 "100" 遵循多播地址的 16 位地址格式 (第 12 节).

这允许在 6LoWPAN 网络内支持多播, 但此类支持的完整规范超出了本文档的范围. 示例机制包括: 泛洪 (Flooding),受控泛洪 (Controlled Flooding),单播到 PAN 协调器等. 预计这将由不同的网状网络路由机制规定.

10. 报文头压缩 (Header Compression)​

关于报文头压缩有大量已发布和正在进行的标准化工作. 然而, IPv6 over IEEE 802.15.4 的报文头压缩具有不同的约束, 总结如下:

  • 现有工作假设任意两个设备之间有许多流 (Flows). 这里, 我们假设一种非常简单和低上下文 (Low-Context) 的报文头压缩风格. 虽然这独立于流工作 (可能有多个), 但它不使用任何特定于任何流的上下文. 因此, 它无法实现为每个要压缩的流构建单独上下文的方案所能达到的压缩程度.

  • 鉴于数据包大小非常有限, 高度期望将第 2 层与第 3 层压缩集成, 这是传统上没有做的 (尽管现在由于 ROHC (RObust Header Compression, 鲁棒报文头压缩) 工作组而正在改变).

  • 预计 IEEE 802.15.4 设备将部署在多跳网络 (Multi-Hop Networks) 中. 然而, 网状网络中的报文头压缩与通常的点对点链路场景不同, 在该场景中, 压缩器和解压缩器彼此直接和独占通信. 在 IEEE 802.15.4 网络中, 高度期望设备能够通过其任何邻居发送报文头压缩的数据包, 并尽可能少地进行初步的上下文构建.

报文头压缩所需的任何新数据包格式通过使用不同的分派值 (Dispatch Values) 重用第 5 节中定义的基本数据包格式.

报文头压缩可能导致对齐不落在八位字节边界上. 由于硬件通常无法以小于八位字节的单位传输数据, 因此必须使用填充 (Padding). 填充按如下方式完成: 首先, 排列整个连续压缩报文头系列 (本文档仅定义 IPv6 和 UDP 报文头压缩方案, 但其他方案可以在其他地方定义). 然后, 根据需要添加零比特以对齐到八位字节边界. 这抵消了报文头压缩造成的任何潜在未对齐, 因此后续字段 (例如, 未压缩的报文头或数据有效载荷) 从八位字节边界开始并按常规进行.

10.1. Encoding of IPv6 Header Fields (IPv6报文头字段的编码)​

通过加入同一个 6LoWPAN 网络, 设备共享一些状态. 这使得无需显式构建任何压缩上下文状态即可压缩报文头. 因此, 6LoWPAN 报文头压缩不保留任何流状态; 相反, 它依赖于与整个链路相关的信息. 以下 IPv6 报文头值预计在 6LoWPAN 网络上很常见, 因此 HC1 报文头被构造为从一开始就有效地压缩它们:

  • Version (版本) 是 IPv6
  • IPv6 源地址和目标地址都是链路本地的 (Link Local)
  • 源或目标地址的 IPv6 接口标识符 (底部 64 位) 可以从第 2 层源和目标地址推断 (当然, 这仅对从底层 802.15.4 MAC 地址派生的接口标识符可能)
  • 数据包长度可以从第 2 层 (IEEE 802.15.4 PPDU 中的 "Frame Length") 或分片报文头中的 "datagram_size" 字段 (如果存在) 推断
  • Traffic Class 和 Flow Label 都为零
  • Next Header 是 UDP, ICMP 或 TCP

IPv6 报文头中唯一始终需要完整承载的字段是 Hop Limit (跳数限制, 8 位). 根据数据包与这种常见情况的匹配程度, 不同的字段可能无法压缩, 因此需要 "内联" (In-Line) 承载 (第 10.3.1 节). 这种常见的 IPv6 报文头 (如上所述) 可以压缩到 2 个八位字节 (1 个八位字节用于 HC1 编码, 1 个八位字节用于 Hop Limit), 而不是 40 个八位字节.

这样的数据包可以通过 LOWPAN_HC1 格式压缩, 方法是使用 LOWPAN_HC1 的分派值, 后跟 LOWPAN_HC1 报文头 "HC1 编码" 字段 (8 位) 来编码如下所示的不同组合.

                       1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | HC1 encoding  |     Non-Compressed fields follow...
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

图 9: LOWPAN_HC1 (常见压缩报文头编码)

由 "HC1 编码" 编码的地址字段解释如下:

  • PI: Prefix carried in-line (前缀内联承载)
  • PC: Prefix compressed (前缀压缩, 假定链路本地前缀)
  • II: Interface identifier carried in-line (接口标识符内联承载)
  • IC: Interface identifier elided (接口标识符省略, 可从相应的链路层地址派生)

HC1 编码 (从比特 0 到比特 7):

IPv6 源地址 (比特 0 和 1):

  • 00: PI, II
  • 01: PI, IC
  • 10: PC, II
  • 11: PC, IC

IPv6 目标地址 (比特 2 和 3):

  • 00: PI, II
  • 01: PI, IC
  • 10: PC, II
  • 11: PC, IC

Traffic Class 和 Flow Label (比特 4):

  • 0: 未压缩; 发送完整的 8 位 Traffic Class 和 20 位 Flow Label
  • 1: Traffic Class 和 Flow Label 为零

Next Header (比特 5 和 6):

  • 00: 未压缩; 发送完整的 8 位
  • 01: UDP
  • 10: ICMP
  • 11: TCP

HC2 编码 (比特 7):

  • 0: 没有更多报文头压缩比特
  • 1: HC1 编码紧接着根据 HC2 编码格式的更多报文头压缩比特. 比特 5 和 6 确定哪些可能的 HC2 编码适用 (例如, UDP, ICMP 或 TCP 编码).

10.2. Encoding of UDP Header Fields (UDP报文头字段的编码)​

LOWPAN_HC1 的比特 5 和 6 允许压缩 IPv6 报文头中的 Next Header 字段 (用于 UDP, TCP 和 ICMP). 还可以进一步压缩这些协议报文头中的每一个. 本节解释如何压缩 UDP 报文头本身. 本节中的 HC2 编码是 HC_UDP 编码, 它仅在 HC1 中的比特 5 和 6 指示 IPv6 报文头后面的协议是 UDP 时适用.

HC_UDP 编码允许压缩 UDP 报文头中的以下字段: 源端口 (Source Port), 目标端口 (Destination Port) 和长度 (Length). UDP 报文头的校验和 (Checksum) 字段不压缩, 因此完整承载. 下面定义的方案允许将 UDP 报文头压缩到 4 个八位字节, 而不是原始的 8 个八位字节.

唯一可以从其他地方可用的信息推断其值的 UDP 报文头字段是 Length. 其他字段必须完整或以部分压缩的方式内联承载 (第 10.3.2 节).

                       1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |HC_UDP encoding|     Fields carried in-line follow...
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

图 10: HC_UDP (UDP常见压缩报文头编码)

UDP 的 "HC_UDP 编码" (从比特 0 到比特 7):

UDP 源端口 (比特 0):

  • 0: 未压缩, 内联承载
  • 1: 压缩到 4 位. 实际的 16 位源端口通过计算获得: P + short_port 值. P 的值是数字 61616 (0xF0B0). short_port 表示为 4 位值, 内联承载

UDP 目标端口 (比特 1):

  • 0: 未压缩, 内联承载
  • 1: 压缩到 4 位. 实际的 16 位目标端口通过计算获得: P + short_port 值. P 的值是数字 61616 (0xF0B0). short_port 表示为 4 位值, 内联承载

Length (比特 2):

  • 0: 未压缩, 内联承载
  • 1: 压缩, 长度从 IPv6 报文头长度信息计算. UDP 长度字段的值等于 IPv6 报文头的 Payload Length, 减去 IPv6 报文头和 UDP 报文头之间存在的任何扩展报文头的长度

保留 (比特 3 到 7)

10.3. Non-Compressed Fields (未压缩字段)​

10.3.1. Non-Compressed IPv6 Fields (未压缩的IPv6字段)​

此方案允许 IPv6 报文头被压缩到不同程度. 因此, 仅需要发送未压缩的字段, 而不是整个 (标准) IPv6 报文头. 后续报文头 (由原始 IPv6 报文头中的 Next Header 字段指定) 紧接在 IPv6 未压缩字段之后.必须始终存在的未压缩 IPv6 字段是 Hop Limit (8 位). 此字段必须 始终跟随编码字段 (例如, 如图 9 所示的 "HC1 编码", 可能包括其他未来的编码字段). 其他未压缩字段必须 按照 "HC1 编码" 所暗示的顺序跟随 Hop Limit, 与上面 (第 10.1 节) 所示的顺序完全相同: 源地址前缀 (64 位) 和/或接口标识符 (64 位), 目标地址前缀 (64 位) 和/或接口标识符 (64 位), Traffic Class (8 位), Flow Label (20 位) 和 Next Header (8 位). 实际的下一个报文头 (例如, UDP, TCP, ICMP 等) 跟随未压缩字段.

10.3.2. Non-Compressed and Partially Compressed UDP Fields (未压缩和部分压缩的UDP字段)​

此方案允许 UDP 报文头被压缩到不同程度. 因此, 仅需要发送未压缩或部分压缩的字段, 而不是整个 (标准) UDP 报文头.

UDP 报文头中的未压缩或部分压缩字段必须 始终跟随 IPv6 报文头及其任何相关的内联字段. 存在的任何 UDP 报文头内联字段必须 以与正常 UDP 报文头 [RFC0768] 中相应字段出现的相同顺序出现, 例如, 源端口, 目标端口, 长度和校验和. 如果源端口或目标端口采用 "short_port" 表示法 (如压缩的 UDP 报文头所示), 则内联端口号取 4 位而不是 16 位.

尽管预计 802.15.4 网络将普遍使用网状网络路由 (Mesh Routing), 但 IEEE 802.15.4-2003 规范 [ieee802.15.4] 并未定义此类能力. 在这种情况下, 全功能设备 (Full Function Devices, FFDs) 运行自组织或网状网络路由协议来填充其路由表 (超出本文档的范围). 在这种网状网络场景中, 两个设备不需要直接可达即可通信. 在这些设备中, 发送者称为 "发起者" (Originator), 接收者称为 "最终目标" (Final Destination). 发起者设备可以使用其他中间设备作为转发器 (Forwarders) 朝向最终目标. 为了使用单播实现这种帧传递, 除了逐跳源和目标之外, 还必须包括发起者和最终目标的链路层地址.

本节定义如何在网状网络中实现第 2 层帧的传递, 给定目标 "最终目标" 链路层地址.

网状网络传递通过在 LoWPAN 封装 (第 5 节) 的任何其他报文头之前包含网状网络寻址报文头 (Mesh Addressing Header) 来实现, 包括未分片和分片报文头; 完整的 IPv6 报文头; 或根据第 10 节或其他地方定义的压缩 IPv6 报文头.

如果节点希望使用默认网状网络转发器来传递数据包 (即, 因为它没有到目标的直接可达性), 它必须 包含一个网状网络寻址报文头, 其中发起者的链路层地址设置为其自己的, 最终目标的链路层地址设置为数据包的最终目标. 它将 802.15.4 报文头中的源地址设置为其自己的链路层地址, 并将转发器的链路层地址放入 802.15.4 报文头的目标地址字段. 最后, 它传输数据包.

类似地, 如果节点接收到具有网状网络寻址报文头的帧, 它必须 查看网状网络寻址报文头的 "Final Destination" 字段以确定真实目标. 如果节点本身是最终目标, 它按照正常传递方式消费数据包. 如果它不是最终目标, 设备则减少 "Hops Left" 字段, 如果结果为零, 则丢弃数据包. 否则, 节点查询其链路层路由表, 确定朝向最终目标的下一跳应该是什么, 并将该地址放入 802.15.4 报文头的目标地址字段. 最后, 节点将 802.15.4 报文头中的源地址更改为其自己的链路层地址并传输数据包.

虽然节点必须 参与网状网络路由协议才能成为转发器, 但仅使用网状网络转发不存在此类要求. 仅 "全功能设备" (FFDs) 预计在网状网络中作为路由器参与. "简化功能设备" (Reduced Function Devices, RFDs) 将自己限制为发现 FFDs 并将它们用于所有转发, 其方式类似于 IP 主机通常使用默认路由器转发所有其链路外流量的方式. 对于使用网状网络传递的 RFD, "转发器" 始终是适当的 FFD.

11.1. LoWPAN Broadcast (LoWPAN广播)​

附加的网状网络路由功能使用紧跟网状网络报文头之后的路由报文头 (Routing Header) 进行编码. 特别是, 广播报文头由 LOWPAN_BC0 分派后跟序列号 (Sequence Number) 字段组成. 序列号用于检测重复数据包 (并希望抑制它们).

                       1
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |0|1|LOWPAN_BC0 |Sequence Number|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

图 11: 广播报文头

字段定义:

Sequence Number (序列号): 此 8 位字段应 在发起者每次发送新的网状网络广播或多播数据包时递增. 如何处理此字段的完整规范超出了本文档的范围.

此类网状网络层广播的进一步含义, 例如, 它是否映射到受控泛洪机制或其在拓扑发现中的作用, 超出了本文档的范围.

附加的网状网络路由能力, 例如指定网状网络路由协议,源路由等, 可以通过定义在报文头栈中位于分片或寻址报文头之前的附加路由报文头来表达. 此类网状网络路由能力的完整规范超出了本文档的范围.

12. IANA Considerations (IANA注意事项)​

本文档创建了两个新的 IANA 注册表, 如下所述. 这些注册表中的未来分配将根据 "Specification Required" (需要规范) [RFC2434] 的政策通过 IANA 协调. 预计此政策将允许其他 (非 IETF) 组织更容易地获得分配.

分派类型字段注册表 (Dispatch Type Field Registry)​

本文档为第 5 节中报文头定义中显示的分派类型字段 (Dispatch Type Field) 创建了一个新的 IANA 注册表. 本文档定义了 IPv6, LOWPAN_HC1 报文头压缩, BC0 广播和两个转义模式 (NALP 表示不是 LoWPAN 帧, ESC 允许附加分派字节) 的值. 本文档将此字段定义为 8 位长. 值 00xxxxxx 被保留且不使用, 允许总共 192 个不同的值, 这应该足够了. 如果定义了除 HC1 之外的报文头压缩格式, 或者如果定义了附加的 TCP, ICMP HC2 格式, 预计这些将使用 LOWPAN_HC1 之后的保留分派值. 如果定义了附加的网状网络传递格式, 这些将使用 LOWPAN_BC0 之后的保留值.

16位短地址注册表 (16-bit Short Address Registry)​

本文档为 6LoWPAN 数据包中使用的 16 位短地址字段创建了一个新的 IANA 注册表.

                   0                   1
                   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  |     16-bit short Address      |
                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

图 12: 16位短地址格式

此注册表必须 包括地址 0xffff (被当前侦听信道的所有设备接受的 16 位广播地址) 和 0xfffe, 如 [ieee802.15.4] 中定义. 此外, 在 6LoWPAN 网络内, 16 位短地址必须 遵循此格式 (按从 0 到 7 的比特字段顺序引用), 其中 "x" 是未指定比特值的占位符:

Range 1, 0xxxxxxxxxxxxxxx: 如果 16 位地址是单播地址 (Unicast Address), 第一位 (比特 0) 应 为零. 这为实际地址留下 15 位.

Range 2, 100xxxxxxxxxxxxx: 如果 16 位地址是多播地址 (Multicast Address) (参见第 9 节), 比特 0, 1 和 2 应 遵循此模式. 这为实际多播地址留下 13 位.

Range 3, 101xxxxxxxxxxxxx: 比特 0, 1 和 2 的此模式是保留的. 任何未来的分配应遵循上述政策.

Range 4, 110xxxxxxxxxxxxx: 比特 0, 1 和 2 的此模式是保留的. 任何未来的分配应遵循上述政策.

Range 5, 111xxxxxxxxxxxxx: 比特 0, 1 和 2 的此模式是保留的. 任何未来的分配应遵循上述政策.

13. Security Considerations (安全考虑)​

从 EUI-64 MAC 地址派生接口标识符 (Interface Identifiers) 的方法旨在在可能的情况下保持全局唯一性. 然而, 没有保护可以防止通过意外或伪造造成的重复.

IEEE 802.15.4 链路中的邻居发现 (Neighbor Discovery) 可能容易受到 [RFC3756] 中详述的威胁. 网状网络路由预计在 IEEE 802.15.4 网络中很常见. 这意味着根据 [KW03] 由于自组织路由而产生的附加威胁. IEEE 802.15.4 为链路层安全提供了一些能力. 如果可能和实用, 强烈建议用户使用此类规定. 这样做将减轻上述威胁.

预计相当一部分 IEEE 802.15.4 设备将始终在其 PAN 内通信 (即, 在 IPv6 术语中, 在其链路内). 为了响应成本和功耗考虑, 并与 IEEE 802.15.4 "简化功能设备" (Reduced Function Devices, RFDs) 模型保持一致, 这些设备通常将实现必要的最小功能集. 因此, 此类设备的安全性可能在很大程度上依赖于 IEEE 802.15.4 在链路层定义的机制. 然而, 后者仅定义了用于认证或加密 IEEE 802.15.4 帧的高级加密标准 (Advanced Encryption Standard, AES) 模式, 特别是没有指定密钥管理 (可能是面向组的). 在实际部署中要解决的其他问题涉及安全配置和管理. 虽然完整的情况超出了本文档的范围, 但必须在部署 IEEE 802.15.4 网络时考虑此类考虑. 当然, 还预计一些 IEEE 802.15.4 设备 (所谓的 "全功能设备" 或 "FFDs") 将实现协调或集成功能. 这些可能定期与链路外 IPv6 对等体通信 (除了更常见的链路内交换之外). 此类 IPv6 设备预计使用常用机制 (例如, IPsec, TLS 等) 保护其端到端通信.

14. 致谢 (Acknowledgements)​

感谢 RFC 2464 和 RFC 2734 的作者, 本文档中的部分内容沿用了他们的文档模式. 感谢 Geoff Mulligan 进行的有益讨论, 这些讨论帮助塑造了本文档. Erik Nordmark 的建议对报文头压缩部分的形成起到了关键作用. 同时还要感谢 Shoichi Sakane, Samita Chakrabarti, Vipul Gupta, Carsten Bormann, Ki-Hyung Kim, Mario Mao, Phil Levis, Magnus Westerlund 和 Jari Arkko.