Network Working Group G. Montenegro
Request for Comments: 4944 Microsoft Corporation
Category: Standards Track N. Kushalnagar
Intel Corp
J. Hui
D. Culler
Arch Rock Corp
September 2007
Network Working Group G. Montenegro
Request for Comments: 4944 Microsoft Corporation
Category: Standards Track N. Kushalnagar
Intel Corp
J. Hui
D. Culler
Arch Rock Corp
September 2007
Transmission of IPv6 Packets over IEEE 802.15.4 Networks
通过IEEE 802.15.4网络传输IPv6数据包
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Abstract
摘要
This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE 802.15.4 networks. Additional specifications include a simple header compression scheme using shared context and provisions for packet delivery in IEEE 802.15.4 meshes.
本文档描述了IPv6数据包传输的帧格式以及在IEEE 802.15.4网络上形成IPv6链路本地地址和无状态自动配置地址的方法。其他规范包括使用共享上下文的简单报头压缩方案，以及IEEE 802.15.4网格中的数据包交付规定。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3
1.2. Terms Used . . . . . . . . . . . . . . . . . . . . . . . . 3
2. IEEE 802.15.4 Mode for IP . . . . . . . . . . . . . . . . . . 3
3. Addressing Modes . . . . . . . . . . . . . . . . . . . . . . . 4
4. Maximum Transmission Unit . . . . . . . . . . . . . . . . . . 5
5. LoWPAN Adaptation Layer and Frame Format . . . . . . . . . . . 6
5.1. Dispatch Type and Header . . . . . . . . . . . . . . . . . 8
5.2. Mesh Addressing Type and Header . . . . . . . . . . . . . 10
5.3. Fragmentation Type and Header . . . . . . . . . . . . . . 11
6. Stateless Address Autoconfiguration . . . . . . . . . . . . . 13
7. IPv6 Link Local Address . . . . . . . . . . . . . . . . . . . 14
8. Unicast Address Mapping . . . . . . . . . . . . . . . . . . . 14
9. Multicast Address Mapping . . . . . . . . . . . . . . . . . . 16
10. Header Compression . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Encoding of IPv6 Header Fields . . . . . . . . . . . . . . 17
10.2. Encoding of UDP Header Fields . . . . . . . . . . . . . . 19
10.3. Non-Compressed Fields . . . . . . . . . . . . . . . . . . 21
10.3.1. Non-Compressed IPv6 Fields . . . . . . . . . . . . . 21
10.3.2. Non-Compressed and Partially Compressed UDP Fields . 21
11. Frame Delivery in a Link-Layer Mesh . . . . . . . . . . . . . 21
11.1. LoWPAN Broadcast . . . . . . . . . . . . . . . . . . . . . 23
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
13. Security Considerations . . . . . . . . . . . . . . . . . . . 25
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
15.1. Normative References . . . . . . . . . . . . . . . . . . . 26
15.2. Informative References . . . . . . . . . . . . . . . . . . 26
Appendix A. Alternatives for Delivery of Frames in a Mesh . . . . 28
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3
1.2. Terms Used . . . . . . . . . . . . . . . . . . . . . . . . 3
2. IEEE 802.15.4 Mode for IP . . . . . . . . . . . . . . . . . . 3
3. Addressing Modes . . . . . . . . . . . . . . . . . . . . . . . 4
4. Maximum Transmission Unit . . . . . . . . . . . . . . . . . . 5
5. LoWPAN Adaptation Layer and Frame Format . . . . . . . . . . . 6
5.1. Dispatch Type and Header . . . . . . . . . . . . . . . . . 8
5.2. Mesh Addressing Type and Header . . . . . . . . . . . . . 10
5.3. Fragmentation Type and Header . . . . . . . . . . . . . . 11
6. Stateless Address Autoconfiguration . . . . . . . . . . . . . 13
7. IPv6 Link Local Address . . . . . . . . . . . . . . . . . . . 14
8. Unicast Address Mapping . . . . . . . . . . . . . . . . . . . 14
9. Multicast Address Mapping . . . . . . . . . . . . . . . . . . 16
10. Header Compression . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Encoding of IPv6 Header Fields . . . . . . . . . . . . . . 17
10.2. Encoding of UDP Header Fields . . . . . . . . . . . . . . 19
10.3. Non-Compressed Fields . . . . . . . . . . . . . . . . . . 21
10.3.1. Non-Compressed IPv6 Fields . . . . . . . . . . . . . 21
10.3.2. Non-Compressed and Partially Compressed UDP Fields . 21
11. Frame Delivery in a Link-Layer Mesh . . . . . . . . . . . . . 21
11.1. LoWPAN Broadcast . . . . . . . . . . . . . . . . . . . . . 23
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
13. Security Considerations . . . . . . . . . . . . . . . . . . . 25
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
15.1. Normative References . . . . . . . . . . . . . . . . . . . 26
15.2. Informative References . . . . . . . . . . . . . . . . . . 26
Appendix A. Alternatives for Delivery of Frames in a Mesh . . . . 28
The IEEE 802.15.4 standard [ieee802.15.4] targets low-power personal area networks. This document defines the frame format for transmission of IPv6 [RFC2460] packets as well as the formation of IPv6 link-local addresses and statelessly autoconfigured addresses on top of IEEE 802.15.4 networks. Since IPv6 requires support of packet sizes much larger than the largest IEEE 802.15.4 frame size, an adaptation layer is defined. This document also defines mechanisms for header compression required to make IPv6 practical on IEEE 802.15.4 networks, and the provisions required for packet delivery in IEEE 802.15.4 meshes. However, a full specification of mesh routing (the specific protocol used, the interactions with neighbor discovery, etc) is out of the scope of this document.
IEEE 802.15.4标准[ieee802.15.4]以低功耗个人区域网络为目标。本文件定义了IPv6[RFC2460]数据包传输的帧格式，以及在IEEE 802.15.4网络上形成IPv6链路本地地址和无状态自动配置地址。由于IPv6需要支持比最大IEEE 802.15.4帧大小大得多的数据包大小，因此定义了适配层。本文档还定义了使IPv6在IEEE 802.15.4网络上实用所需的报头压缩机制，以及IEEE 802.15.4网络中数据包交付所需的规定。但是，网状路由的完整规范（使用的特定协议、与邻居发现的交互等）不在本文档的范围内。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
AES: Advanced Encryption Scheme
高级加密方案
CSMA/CA: Carrier Sense Multiple Access / Collision Avoidance
CSMA/CA: Carrier Sense Multiple Access / Collision Avoidance
FFD: Full Function Device
全功能设备
GTS: Guaranteed Time Service
GTS：保证时间服务
MTU: Maximum Transmission Unit
最大传输单位
MAC: Media Access Control
媒体访问控制
PAN: Personal Area Network
个人区域网
RFD: Reduced Function Device
缩减功能装置
IEEE 802.15.4 defines four types of frames: beacon frames, MAC command frames, acknowledgement frames, and data frames. IPv6 packets MUST be carried on data frames. Data frames may optionally request that they be acknowledged. In keeping with [RFC3819], it is recommended that IPv6 packets be carried in frames for which acknowledgements are requested so as to aid link-layer recovery.
IEEE 802.15.4定义了四种类型的帧：信标帧、MAC命令帧、确认帧和数据帧。IPv6数据包必须在数据帧上承载。数据帧可以选择性地请求对其进行确认。根据[RFC3819]，建议在请求确认的帧中携带IPv6数据包，以帮助链路层恢复。
IEEE 802.15.4 networks can either be nonbeacon-enabled or beacon-enabled [ieee802.15.4]. The latter is an optional mode in which devices are synchronized by a so-called coordinator's beacons. This allows the use of superframes within which a contention-free Guaranteed Time Service (GTS) is possible. This document does not require that IEEE networks run in beacon-enabled mode. In nonbeacon-enabled networks, data frames (including those carrying IPv6 packets) are sent via the contention-based channel access method of unslotted CSMA/CA.
IEEE 802.15.4网络可以是非信标启用的网络，也可以是信标启用的网络[ieee802.15.4]。后者是一种可选模式，在此模式下，设备由所谓的协调器信标进行同步。这允许使用超帧，其中无争用保证时间服务（GTS）是可能的。本文件不要求IEEE网络在信标启用模式下运行。在非信标启用的网络中，数据帧（包括承载IPv6数据包的数据帧）通过非时隙CSMA/CA的基于竞争的信道访问方法发送。
In nonbeacon-enabled networks, beacons are not used for synchronization. However, they are still useful for link-layer device discovery to aid in association and disassociation events. This document recommends that beacons be configured so as to aid these functions. A further recommendation is for these events to be
在非信标启用的网络中，信标不用于同步。但是，它们对于链路层设备发现仍然很有用，有助于关联和解除关联事件。本文件建议配置信标，以帮助实现这些功能。另一项建议是对这些事件进行评估
available at the IPv6 layer to aid in detecting network attachment, a problem being worked on at the IETF at the time of this writing.
在IPv6层可用以帮助检测网络连接，在撰写本文时，IETF正在解决这个问题。
The specification allows for frames in which either the source or destination addresses (or both) are elided. The mechanisms defined in this document require that both source and destination addresses be included in the IEEE 802.15.4 frame header. The source or destination PAN ID fields may also be included.
该规范允许省略源地址或目标地址（或两者）的帧。本文件中定义的机制要求源地址和目标地址都包含在IEEE 802.15.4帧头中。还可以包括源或目标PAN ID字段。
IEEE 802.15.4 defines several addressing modes: it allows the use of either IEEE 64-bit extended addresses or (after an association event) 16-bit addresses unique within the PAN [ieee802.15.4]. This document supports both 64-bit extended addresses, and 16-bit short addresses. For use within 6LoWPANs, this document imposes additional constraints (beyond those imposed by IEEE 802.15.4) on the format of the 16-bit short addresses, as specified in Section 12. Short addresses being transient in nature, a word of caution is in order: since they are doled out by the PAN coordinator function during an association event, their validity and uniqueness is limited by the lifetime of that association. This can be cut short by the expiration of the association or simply by any mishap occurring to the PAN coordinator. Because of the scalability issues posed by such a centralized allocation and single point of failure at the PAN coordinator, deployers should carefully weigh the tradeoffs (and implement the necessary mechanisms) of growing such networks based on short addresses. Of course, IEEE 64-bit extended addresses may not suffer from these drawbacks, but still share the remaining scalability issues concerning routing, discovery, configuration, etc.
IEEE 802.15.4定义了几种寻址模式：它允许使用IEEE 64位扩展地址或（在关联事件后）PAN中唯一的16位地址[ieee802.15.4]。本文档支持64位扩展地址和16位短地址。对于6LoWPANs中的使用，本文件对16位短地址的格式施加了额外的限制（超出IEEE 802.15.4规定的限制），如第12节所述。短地址本质上是暂时的，需要注意：因为它们是在关联事件期间由泛协调器函数分配的，所以它们的有效性和唯一性受到该关联的生存期的限制。这可以通过协会到期或PAN协调员发生任何事故来缩短。由于这种集中式分配和PAN协调器的单点故障带来的可伸缩性问题，部署人员应该仔细权衡基于短地址扩展此类网络的权衡（并实施必要的机制）。当然，IEEE 64位扩展地址可能没有这些缺点，但仍然存在路由、发现、配置等方面的可伸缩性问题。
This document assumes that a PAN maps to a specific IPv6 link. This complies with the recommendation that shared networks support link-layer subnet [RFC3819] broadcast. Strictly speaking, it is multicast not broadcast that exists in IPv6. However, multicast is not supported natively in IEEE 802.15.4. Hence, IPv6 level multicast packets MUST be carried as link-layer broadcast frames in IEEE 802.15.4 networks. This MUST be done such that the broadcast frames are only heeded by devices within the specific PAN of the link in question. As per Section 7.5.6.2 in [ieee802.15.4], this is accomplished as follows:
本文档假定PAN映射到特定的IPv6链路。这符合共享网络支持链路层子网[RFC3819]广播的建议。严格来说，IPv6中存在的是多播而不是广播。但是，在IEEE 802.15.4中，本机不支持多播。因此，在IEEE 802.15.4网络中，IPv6级别的多播数据包必须作为链路层广播帧进行传输。必须这样做，使得广播帧仅被相关链路的特定PAN内的设备注意。根据[ieee802.15.4]中的第7.5.6.2节，这是通过以下方式实现的：
1. A destination PAN identifier is included in the frame, and it MUST match the PAN ID of the link in question.
1. 目标PAN标识符包含在帧中，它必须与相关链接的PAN ID匹配。
2. A short destination address is included in the frame, and it MUST match the broadcast address (0xffff).
2. 帧中包含一个短的目标地址，它必须与广播地址（0xffff）匹配。
Additionally, support for mapping of IPv6 multicast addresses per Section 9 MUST only be used in a mesh configuration. A full specification of such functionality is out of the scope of this document.
此外，根据第9节对IPv6多播地址映射的支持只能在网状结构配置中使用。此类功能的完整规范不在本文档范围内。
As usual, hosts learn IPv6 prefixes via router advertisements as per [RFC4861].
按照[RFC4861]，主机通常通过路由器播发学习IPv6前缀。
The MTU size for IPv6 packets over IEEE 802.15.4 is 1280 octets. However, a full IPv6 packet does not fit in an IEEE 802.15.4 frame. 802.15.4 protocol data units have different sizes depending on how much overhead is present [ieee802.15.4]. Starting from a maximum physical layer packet size of 127 octets (aMaxPHYPacketSize) and a maximum frame overhead of 25 (aMaxFrameOverhead), the resultant maximum frame size at the media access control layer is 102 octets. Link-layer security imposes further overhead, which in the maximum case (21 octets of overhead in the AES-CCM-128 case, versus 9 and 13 for AES-CCM-32 and AES-CCM-64, respectively) leaves only 81 octets available. This is obviously far below the minimum IPv6 packet size of 1280 octets, and in keeping with Section 5 of the IPv6 specification [RFC2460], a fragmention and reassembly adaptation layer must be provided at the layer below IP. Such a layer is defined below in Section 5.
IEEE 802.15.4上IPv6数据包的MTU大小为1280个八位字节。但是，完整的IPv6数据包不适合IEEE 802.15.4框架。802.15.4协议数据单元的大小取决于存在的开销[ieee802.15.4]。从最大物理层数据包大小127个八位字节（aMaxPHYPacketSize）和最大帧开销25个（amaxframeheader）开始，媒体访问控制层的最大帧大小为102个八位字节。链路层安全带来了进一步的开销，在最大情况下（AES-CCM-128的开销为21个八位字节，而AES-CCM-32和AES-CCM-64的开销分别为9和13个八位字节），只剩下81个八位字节可用。这显然远低于1280个八位字节的最小IPv6数据包大小，并且根据IPv6规范[RFC2460]第5节的规定，必须在IP下面的层提供碎片和重组适配层。该层定义见下文第5节。
Furthermore, since the IPv6 header is 40 octets long, this leaves only 41 octets for upper-layer protocols, like UDP. The latter uses 8 octets in the header which leaves only 33 octets for application data. Additionally, as pointed out above, there is a need for a fragmentation and reassembly layer, which will use even more octets.
此外，由于IPv6报头的长度为40个八位字节，因此上层协议（如UDP）只剩下41个八位字节。后者在报头中使用8个八位字节，只剩下33个八位字节用于应用程序数据。此外，如上所述，需要一个碎片和重组层，它将使用更多的八位字节。
The above considerations lead to the following two observations:
上述考虑导致以下两个观察结果：
1. The adaptation layer must be provided to comply with the IPv6 requirements of a minimum MTU. However, it is expected that (a) most applications of IEEE 802.15.4 will not use such large packets, and (b) small application payloads in conjunction with the proper header compression will produce packets that fit within a single IEEE 802.15.4 frame. The justification for this adaptation layer is not just for IPv6 compliance, as it is quite likely that the packet sizes produced by certain application exchanges (e.g., configuration or provisioning) may require a small number of fragments.
1. 必须提供适配层，以符合最低MTU的IPv6要求。然而，预计（a）IEEE 802.15.4的大多数应用程序将不会使用如此大的数据包，（b）小的应用程序有效载荷与适当的报头压缩相结合将产生适合单个IEEE 802.15.4帧的数据包。此适配层的理由不仅仅是为了符合IPv6，因为某些应用程序交换（例如，配置或供应）产生的数据包大小很可能需要少量片段。
2. Even though the above space calculation shows the worst-case scenario, it does point out the fact that header compression is compelling to the point of almost being unavoidable. Since we
2. 尽管上面的空间计算显示了最坏的情况，但它确实指出了一个事实，即头部压缩几乎不可避免。自从我们
expect that most (if not all) applications of IP over IEEE 802.15.4 will make use of header compression, it is defined below in Section 10.
预计IEEE 802.15.4上的IP的大多数（如果不是全部）应用将使用报头压缩，其定义见下文第10节。
The encapsulation formats defined in this section (subsequently referred to as the "LoWPAN encapsulation") are the payload in the IEEE 802.15.4 MAC protocol data unit (PDU). The LoWPAN payload (e.g., an IPv6 packet) follows this encapsulation header.
本节中定义的封装格式（随后称为“LoWPAN封装”）是IEEE 802.15.4 MAC协议数据单元（PDU）中的有效载荷。LoWPAN有效负载（例如，IPv6数据包）遵循此封装头。
All LoWPAN encapsulated datagrams transported over IEEE 802.15.4 are prefixed by an encapsulation header stack. Each header in the header stack contains a header type followed by zero or more header fields. Whereas in an IPv6 header the stack would contain, in the following order, addressing, hop-by-hop options, routing, fragmentation, destination options, and finally payload [RFC2460]; in a LoWPAN header, the analogous header sequence is mesh (L2) addressing, hop-by-hop options (including L2 broadcast/multicast), fragmentation, and finally payload. These examples show typical header stacks that may be used in a LoWPAN network.
通过IEEE 802.15.4传输的所有低泛封装数据报都以封装头堆栈作为前缀。标头堆栈中的每个标头都包含一个标头类型，后跟零个或多个标头字段。而在IPv6报头中，堆栈将按以下顺序包含寻址、逐跳选项、路由、分段、目的地选项以及最终有效负载[RFC2460]；在LoWPAN报头中，类似的报头序列是mesh（L2）寻址、逐跳选项（包括L2广播/多播）、分段，最后是有效负载。这些示例显示了可在低泛网络中使用的典型报头堆栈。
A LoWPAN encapsulated IPv6 datagram:
低泛封装IPv6数据报：
+---------------+-------------+---------+
| IPv6 Dispatch | IPv6 Header | Payload |
+---------------+-------------+---------+
+---------------+-------------+---------+
| IPv6 Dispatch | IPv6 Header | Payload |
+---------------+-------------+---------+
A LoWPAN encapsulated LOWPAN_HC1 compressed IPv6 datagram:
LoWPAN封装的LoWPAN_HC1压缩IPv6数据报：
+--------------+------------+---------+
| HC1 Dispatch | HC1 Header | Payload |
+--------------+------------+---------+
+--------------+------------+---------+
| HC1 Dispatch | HC1 Header | Payload |
+--------------+------------+---------+
A LoWPAN encapsulated LOWPAN_HC1 compressed IPv6 datagram that requires mesh addressing:
需要网状寻址的LoWPAN封装LoWPAN_HC1压缩IPv6数据报：
+-----------+-------------+--------------+------------+---------+
| Mesh Type | Mesh Header | HC1 Dispatch | HC1 Header | Payload |
+-----------+-------------+--------------+------------+---------+
+-----------+-------------+--------------+------------+---------+
| Mesh Type | Mesh Header | HC1 Dispatch | HC1 Header | Payload |
+-----------+-------------+--------------+------------+---------+
A LoWPAN encapsulated LOWPAN_HC1 compressed IPv6 datagram that requires fragmentation:
需要分段的LoWPAN封装LoWPAN_HC1压缩IPv6数据报：
+-----------+-------------+--------------+------------+---------+
| Frag Type | Frag Header | HC1 Dispatch | HC1 Header | Payload |
+-----------+-------------+--------------+------------+---------+
+-----------+-------------+--------------+------------+---------+
| Frag Type | Frag Header | HC1 Dispatch | HC1 Header | Payload |
+-----------+-------------+--------------+------------+---------+
A LoWPAN encapsulated LOWPAN_HC1 compressed IPv6 datagram that requires both mesh addressing and fragmentation:
LoWPAN封装的LoWPAN_HC1压缩IPv6数据报，需要网状寻址和碎片：
+-------+-------+-------+-------+---------+---------+---------+
| M Typ | M Hdr | F Typ | F Hdr | HC1 Dsp | HC1 Hdr | Payload |
+-------+-------+-------+-------+---------+---------+---------+
+-------+-------+-------+-------+---------+---------+---------+
| M Typ | M Hdr | F Typ | F Hdr | HC1 Dsp | HC1 Hdr | Payload |
+-------+-------+-------+-------+---------+---------+---------+
A LoWPAN encapsulated LOWPAN_HC1 compressed IPv6 datagram that requires both mesh addressing and a broadcast header to support mesh broadcast/multicast:
LoWPAN封装的LoWPAN_HC1压缩IPv6数据报，需要mesh寻址和广播报头来支持mesh广播/多播：
+-------+-------+-------+-------+---------+---------+---------+
| M Typ | M Hdr | B Dsp | B Hdr | HC1 Dsp | HC1 Hdr | Payload |
+-------+-------+-------+-------+---------+---------+---------+
+-------+-------+-------+-------+---------+---------+---------+
| M Typ | M Hdr | B Dsp | B Hdr | HC1 Dsp | HC1 Hdr | Payload |
+-------+-------+-------+-------+---------+---------+---------+
When more than one LoWPAN header is used in the same packet, they MUST appear in the following order:
当在同一数据包中使用多个LoWPAN报头时，它们必须按以下顺序出现：
Mesh Addressing Header
网状寻址报头
Broadcast Header
广播报头
Fragmentation Header
分段标头
All protocol datagrams (e.g., IPv6, compressed IPv6 headers, etc.) SHALL be preceded by one of the valid LoWPAN encapsulation headers, examples of which are given above. This permits uniform software treatment of datagrams without regard to the mode of their transmission.
所有协议数据报（例如，IPv6、压缩IPv6报头等）的前面应加上一个有效的低泛封装报头，上面给出了这些报头的示例。这允许对数据报进行统一的软件处理，而不考虑其传输模式。
The definition of LoWPAN headers, other than mesh addressing and fragmentation, consists of the dispatch value, the definition of the header fields that follow, and their ordering constraints relative to all other headers. Although the header stack structure provides a mechanism to address future demands on the LoWPAN adaptation layer, it is not intended to provided general purpose extensibility. This format document specifies a small set of header types using the header stack for clarity, compactness, and orthogonality.
除网格寻址和分段外，LoWPAN标头的定义包括分派值、随后标头字段的定义及其相对于所有其他标头的排序约束。尽管报头堆栈结构提供了一种机制来解决低泛适配层的未来需求，但它并不打算提供通用扩展性。为了清晰、紧凑和正交，此格式文档使用标题堆栈指定了一小组标题类型。
The dispatch type is defined by a zero bit as the first bit and a one bit as the second bit. The dispatch type and header are shown here:
分派类型由零位定义为第一位，一位定义为第二位。调度类型和标题如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1| Dispatch | type-specific header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1| Dispatch | type-specific header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Dispatch 6-bit selector. Identifies the type of header immediately following the Dispatch Header.
分派6位选择器。标识紧跟在分派标头之后的标头类型。
type-specific header A header determined by the Dispatch Header.
类型特定标头由分派标头确定的标头。
Figure 1: Dispatch Type and Header
图1：分派类型和标题
The dispatch value may be treated as an unstructured namespace. Only a few symbols are required to represent current LoWPAN functionality. Although some additional savings could be achieved by encoding additional functionality into the dispatch byte, these measures would tend to constrain the ability to address future alternatives.
分派值可以被视为非结构化命名空间。仅需要几个符号来表示当前的低泛功能。尽管通过将附加功能编码到调度字节中可以实现一些额外的节省，但这些措施往往会限制解决未来备选方案的能力。
Pattern Header Type
+------------+-----------------------------------------------+
| 00 xxxxxx | NALP - Not a LoWPAN frame |
| 01 000001 | IPv6 - Uncompressed IPv6 Addresses |
| 01 000010 | LOWPAN_HC1 - LOWPAN_HC1 compressed IPv6 |
| 01 000011 | reserved - Reserved for future use |
| ... | reserved - Reserved for future use |
| 01 001111 | reserved - Reserved for future use |
| 01 010000 | LOWPAN_BC0 - LOWPAN_BC0 broadcast |
| 01 010001 | reserved - Reserved for future use |
| ... | reserved - Reserved for future use |
| 01 111110 | reserved - Reserved for future use |
| 01 111111 | ESC - Additional Dispatch byte follows |
| 10 xxxxxx | MESH - Mesh Header |
| 11 000xxx | FRAG1 - Fragmentation Header (first) |
| 11 001000 | reserved - Reserved for future use |
| ... | reserved - Reserved for future use |
| 11 011111 | reserved - Reserved for future use |
| 11 100xxx | FRAGN - Fragmentation Header (subsequent)|
| 11 101000 | reserved - Reserved for future use |
| ... | reserved - Reserved for future use |
| 11 111111 | reserved - Reserved for future use |
+------------+-----------------------------------------------+
Pattern Header Type
+------------+-----------------------------------------------+
| 00 xxxxxx | NALP - Not a LoWPAN frame |
| 01 000001 | IPv6 - Uncompressed IPv6 Addresses |
| 01 000010 | LOWPAN_HC1 - LOWPAN_HC1 compressed IPv6 |
| 01 000011 | reserved - Reserved for future use |
| ... | reserved - Reserved for future use |
| 01 001111 | reserved - Reserved for future use |
| 01 010000 | LOWPAN_BC0 - LOWPAN_BC0 broadcast |
| 01 010001 | reserved - Reserved for future use |
| ... | reserved - Reserved for future use |
| 01 111110 | reserved - Reserved for future use |
| 01 111111 | ESC - Additional Dispatch byte follows |
| 10 xxxxxx | MESH - Mesh Header |
| 11 000xxx | FRAG1 - Fragmentation Header (first) |
| 11 001000 | reserved - Reserved for future use |
| ... | reserved - Reserved for future use |
| 11 011111 | reserved - Reserved for future use |
| 11 100xxx | FRAGN - Fragmentation Header (subsequent)|
| 11 101000 | reserved - Reserved for future use |
| ... | reserved - Reserved for future use |
| 11 111111 | reserved - Reserved for future use |
+------------+-----------------------------------------------+
Figure 2: Dispatch Value Bit Pattern
图2：分派值位模式
NALP: Specifies that the following bits are not a part of the LoWPAN encapsulation, and any LoWPAN node that encounters a dispatch value of 00xxxxxx shall discard the packet. Other non-LoWPAN protocols that wish to coexist with LoWPAN nodes should include a byte matching this pattern immediately following the 802.15.4. header.
NALP：指定以下位不是LoWPAN封装的一部分，任何遇到分派值00xxxxxx的LoWPAN节点都将丢弃该数据包。希望与LoWPAN节点共存的其他非LoWPAN协议应在802.15.4之后立即包含与此模式匹配的字节。标题。
IPv6: Specifies that the following header is an uncompressed IPv6 header [RFC2460].
IPv6：指定以下标头是未压缩的IPv6标头[RFC2460]。
LOWPAN_HC1: Specifies that the following header is a LOWPAN_HC1 compressed IPv6 header. This header format is defined in Figure 9.
LOWPAN_HC1：指定以下标头是LOWPAN_HC1压缩的IPv6标头。图9中定义了此标题格式。
LOWPAN_BC0: Specifies that the following header is a LOWPAN_BC0 header for mesh broadcast/multicast support and is described in Section 11.1.
LOWPAN_BC0：指定以下标头是网状广播/多播支持的LOWPAN_BC0标头，并在第11.1节中进行了描述。
ESC: Specifies that the following header is a single 8-bit field for the Dispatch value. It allows support for Dispatch values larger than 127.
ESC：指定以下标头是分派值的单个8位字段。它允许支持大于127的分派值。
The mesh type is defined by a one bit and zero bit as the first two bits. The mesh type and header are shown here:
网格类型由一位和零位定义为前两位。网格类型和标题如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0|V|F|HopsLft| originator address, final address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0|V|F|HopsLft| originator address, final address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Mesh Addressing Type and Header
图3：网格寻址类型和标头
Field definitions are as follows:
字段定义如下：
V: This 1-bit field SHALL be zero if the Originator (or "Very first") Address is an IEEE extended 64-bit address (EUI-64), or 1 if it is a short 16-bit addresses.
V：如果发起者（或“最早”）地址是IEEE扩展64位地址（EUI-64），则该1位字段应为零；如果是短16位地址，则该1位字段应为1。
F: This 1-bit field SHALL be zero if the Final Destination Address is an IEEE extended 64-bit address (EUI-64), or 1 if it is a short 16-bit addresses.
F：如果最终目标地址是IEEE扩展64位地址（EUI-64），则该1位字段应为零；如果是短16位地址，则该1位字段应为1。
Hops Left: This 4-bit field SHALL be decremented by each forwarding node before sending this packet towards its next hop. The packet is not forwarded any further if Hops Left is decremented to zero. The value 0xF is reserved and signifies an 8-bit Deep Hops Left field immediately following, and allows a source node to specify a hop limit greater than 14 hops.
左跳数：在向下一跳发送此数据包之前，每个转发节点都应减少此4位字段。如果剩余跳数减为零，则不会进一步转发数据包。值0xF是保留的，表示紧跟其后的8位深跳左字段，并允许源节点指定大于14跳的跳数限制。
Originator Address: This is the link-layer address of the Originator.
发起人地址：这是发起人的链接层地址。
Final Destination Address: This is the link-layer address of the Final Destination.
最终目的地地址：这是最终目的地的链路层地址。
Note that the 'V' and 'F' bits allow for a mix of 16 and 64-bit addresses. This is useful at least to allow for mesh layer "broadcast", as 802.15.4 broadcast addresses are defined as 16-bit short addresses.
请注意，“V”和“F”位允许16位和64位地址的混合。这至少在允许网状层“广播”时是有用的，因为802.15.4广播地址定义为16位短地址。
A further discussion of frame delivery within a mesh is in Section 11.
第11节进一步讨论了网格内的帧交付。
If an entire payload (e.g., IPv6) datagram fits within a single 802.15.4 frame, it is unfragmented and the LoWPAN encapsulation should not contain a fragmentation header. If the datagram does not fit within a single IEEE 802.15.4 frame, it SHALL be broken into link fragments. As the fragment offset can only express multiples of eight bytes, all link fragments for a datagram except the last one MUST be multiples of eight bytes in length. The first link fragment SHALL contain the first fragment header as defined below.
如果整个有效负载（例如，IPv6）数据报适合单个802.15.4帧，则该数据报是未分段的，且LoWPAN封装不应包含分段标头。如果数据报不适合单个IEEE 802.15.4帧，则应将其分解为链路片段。由于片段偏移量只能表示8个字节的倍数，因此数据报的所有链接片段（最后一个除外）的长度必须是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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 0 0 0| datagram_size | datagram_tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 0 0 0| datagram_size | datagram_tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: First Fragment
图4：第一个片段
The second and subsequent link fragments (up to and including the last) SHALL contain a fragmentation header that conforms to the format shown below.
第二个和后续链接片段（直到并包括最后一个）应包含符合以下格式的片段头。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 0 0| datagram_size | datagram_tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|datagram_offset|
+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 0 0| datagram_size | datagram_tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|datagram_offset|
+-+-+-+-+-+-+-+-+
Figure 5: Subsequent Fragments
图5：后续片段
datagram_size: This 11-bit field encodes the size of the entire IP packet before link-layer fragmentation (but after IP layer fragmentation). The value of datagram_size SHALL be the same for all link-layer fragments of an IP packet. For IPv6, this SHALL be 40 octets (the size of the uncompressed IPv6 header) more than the value of Payload Length in the IPv6 header [RFC2460] of the packet. Note that this packet may already be fragmented by hosts involved in the communication, i.e., this field needs to encode a maximum length of 1280 octets (the IEEE 802.15.4 link MTU, as defined in this document).
datagram_size：这个11位字段编码链路层分段之前（但在IP层分段之后）整个IP数据包的大小。对于IP数据包的所有链路层碎片，数据报大小的值应相同。对于IPv6，这应比数据包的IPv6报头[RFC2460]中的有效负载长度值多40个八位字节（未压缩IPv6报头的大小）。请注意，该数据包可能已经被通信中涉及的主机分割，即，该字段需要编码最大长度为1280个八位字节（IEEE 802.15.4链路MTU，如本文件所定义）。
NOTE: This field does not need to be in every packet, as one could send it with the first fragment and elide it subsequently. However, including it in every link fragment eases the task of reassembly in the event that a second (or subsequent) link
注意：此字段不需要出现在每个数据包中，因为可以将其与第一个片段一起发送，然后删除它。然而，将其包含在每个链接片段中可以简化在第二个（或后续）链接发生时重新组装的任务
fragment arrives before the first. In this case, the guarantee of learning the datagram_size as soon as any of the fragments arrives tells the receiver how much buffer space to set aside as it waits for the rest of the fragments. The format above trades off simplicity for efficiency.
片段在第一个之前到达。在这种情况下，在任何片段到达时立即学习数据报大小的保证告诉接收器在等待其余片段时要留出多少缓冲空间。上述格式以简单性换取效率。
datagram_tag: The value of datagram_tag (datagram tag) SHALL be the same for all link fragments of a payload (e.g., IPv6) datagram. The sender SHALL increment datagram_tag for successive, fragmented datagrams. The incremented value of datagram_tag SHALL wrap from 65535 back to zero. This field is 16 bits long, and its initial value is not defined.
数据报标签：数据报标签（数据报标签）的值对于有效载荷（如IPv6）数据报的所有链路片段应相同。发送方应增加连续、分段数据报的数据报标签。数据报标签的增量值应从65535折回到零。此字段的长度为16位，未定义其初始值。
datagram_offset: This field is present only in the second and subsequent link fragments and SHALL specify the offset, in increments of 8 octets, of the fragment from the beginning of the payload datagram. The first octet of the datagram (e.g., the start of the IPv6 header) has an offset of zero; the implicit value of datagram_offset in the first link fragment is zero. This field is 8 bits long.
数据报_偏移量：该字段仅出现在第二个和后续链路片段中，并应以8个八位字节的增量指定片段自有效负载数据报开始的偏移量。数据报的第一个八位组（例如，IPv6报头的开始）的偏移量为零；第一个链路片段中数据报_偏移量的隐式值为零。此字段的长度为8位。
The recipient of link fragments SHALL use (1) the sender's 802.15.4 source address (or the Originator Address if a Mesh Addressing field is present), (2) the destination's 802.15.4 address (or the Final Destination address if a Mesh Addressing field is present), (3) datagram_size, and (4) datagram_tag to identify all the link fragments that belong to a given datagram.
链路片段的接收者应使用（1）发送者的802.15.4源地址（或发起者地址，如果存在网状地址字段），（2）目的地的802.15.4地址（或最终目的地地址，如果存在网状地址字段），（3）数据报大小，以及（4）datagram_标记，用于标识属于给定数据报的所有链接片段。
Upon receipt of a link fragment, the recipient starts constructing the original unfragmented packet whose size is datagram_size. It uses the datagram_offset field to determine the location of the individual fragments within the original unfragmented packet. For example, it may place the data payload (except the encapsulation header) within a payload datagram reassembly buffer at the location specified by datagram_offset. The size of the reassembly buffer SHALL be determined from datagram_size.
在收到链接片段后，接收者开始构建原始的未分段数据包，其大小为数据报大小。它使用datagram_offset字段来确定原始未分段数据包中各个片段的位置。例如，它可以将数据有效负载（封装头除外）放置在有效负载数据报重组缓冲区中数据报_offset指定的位置。重新组装缓冲区的大小应根据数据报大小确定。
If a link fragment that overlaps another fragment is received, as identified above, and differs in either the size or datagram_offset of the overlapped fragment, the fragment(s) already accumulated in the reassembly buffer SHALL be discarded. A fresh reassembly may be commenced with the most recently received link fragment. Fragment overlap is determined by the combination of datagram_offset from the encapsulation header and "Frame Length" from the 802.15.4 Physical Layer Protocol Data Unit (PPDU) packet header.
如上文所述，如果接收到与另一个片段重叠的链接片段，且重叠片段的大小或数据报_偏移量不同，则应丢弃已累积在重组缓冲区中的片段。可以使用最近接收到的链路片段开始新的重新组装。片段重叠由来自封装报头的数据报_偏移量和来自802.15.4物理层协议数据单元（PPDU）报头的“帧长度”的组合确定。
Upon detection of a IEEE 802.15.4 Disassociation event, fragment recipients MUST discard all link fragments of all partially
在检测到IEEE 802.15.4解除关联事件后，片段接收者必须丢弃所有部分链路的所有链路片段
reassembled payload datagrams, and fragment senders MUST discard all not yet transmitted link fragments of all partially transmitted payload (e.g., IPv6) datagrams. Similarly, when a node first receives a fragment with a given datagram_tag, it starts a reassembly timer. When this time expires, if the entire packet has not been reassembled, the existing fragments MUST be discarded and the reassembly state MUST be flushed. The reassembly timeout MUST be set to a maximum of 60 seconds (this is also the timeout in the IPv6 reassembly procedure [RFC2460]).
重新组装的有效负载数据报和片段发送器必须丢弃所有部分传输的有效负载（如IPv6）数据报的所有尚未传输的链路片段。类似地，当节点第一次接收到带有给定数据报标签的片段时，它会启动重新组装计时器。当这个时间到期时，如果整个数据包还没有重新组装，那么必须丢弃现有的片段，并且必须刷新重新组装状态。重新组装超时必须设置为最长60秒（这也是IPv6重新组装过程[RFC2460]中的超时）。
This section defines how to obtain an IPv6 interface identifier.
本节定义如何获取IPv6接口标识符。
The Interface Identifier [RFC4291] for an IEEE 802.15.4 interface may be based on the EUI-64 identifier [EUI64] assigned to the IEEE 802.15.4 device. In this case, the Interface Identifier is formed from the EUI-64 according to the "IPv6 over Ethernet" specification [RFC2464].
IEEE 802.15.4接口的接口标识符[RFC4291]可以基于分配给IEEE 802.15.4设备的EUI-64标识符[EUI64]。在这种情况下，根据“以太网上的IPv6”规范[RFC2464]，从EUI-64形成接口标识符。
All 802.15.4 devices have an IEEE EUI-64 address, but 16-bit short addresses (Section 3 and Section 12) are also possible. In these cases, a "pseudo 48-bit address" is formed as follows. First, the left-most 32 bits are formed by concatenating 16 zero bits to the 16- bit PAN ID (alternatively, if no PAN ID is known, 16 zero bits may be used). This produces a 32-bit field as follows:
所有802.15.4设备都有IEEE EUI-64地址，但也可以使用16位短地址（第3节和第12节）。在这些情况下，“伪48位地址”形成如下。首先，最左边的32位通过将16个零位连接到16位PAN ID来形成（或者，如果不知道PAN ID，则可以使用16个零位）。这将生成一个32位字段，如下所示：
16_bit_PAN:16_zero_bits
16位平移：16位零位
Then, these 32 bits are concatenated with the 16-bit short address. This produces a 48-bit address as follows:
然后，这32位与16位短地址连接。这将产生一个48位地址，如下所示：
32_bits_as_specified_previously:16_bit_short_address
先前指定的32位地址：16位短地址
The interface identifier is formed from this 48-bit address as per the "IPv6 over Ethernet" specification [RFC2464]. However, in the resultant interface identifier, the "Universal/Local" (U/L) bit SHALL be set to zero in keeping with the fact that this is not a globally unique value. For either address format, all zero addresses MUST NOT be used.
根据“以太网上的IPv6”规范[RFC2464]，接口标识符由该48位地址构成。然而，在结果接口标识符中，“通用/本地”（U/L）位应设置为零，以符合这不是全局唯一值的事实。对于任一地址格式，都不能使用所有零地址。
A different MAC address set manually or by software MAY be used to derive the Interface Identifier. If such a MAC address is used, its global uniqueness property should be reflected in the value of the U/L bit.
可以使用手动或软件设置的不同MAC地址来导出接口标识符。如果使用这样的MAC地址，其全局唯一性属性应反映在U/L位的值中。
An IPv6 address prefix used for stateless autoconfiguration [RFC4862] of an IEEE 802.15.4 interface MUST have a length of 64 bits.
用于IEEE 802.15.4接口的无状态自动配置[RFC4862]的IPv6地址前缀的长度必须为64位。
The IPv6 link-local address [RFC4291] for an IEEE 802.15.4 interface is formed by appending the Interface Identifier, as defined above, to the prefix FE80::/64.
IEEE 802.15.4接口的IPv6链路本地地址[RFC4291]是通过在前缀FE80:：/64后面添加接口标识符形成的，如上所述。
10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+
|1111111010| (zeros) | Interface Identifier |
+----------+-----------------------+----------------------------+
10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+
|1111111010| (zeros) | Interface Identifier |
+----------+-----------------------+----------------------------+
Figure 6
图6
The address resolution procedure for mapping IPv6 non-multicast addresses into IEEE 802.15.4 link-layer addresses follows the general description in Section 7.2 of [RFC4861], unless otherwise specified.
除非另有规定，否则将IPv6非多播地址映射到IEEE 802.15.4链路层地址的地址解析过程遵循[RFC4861]第7.2节中的一般说明。
The Source/Target Link-layer Address option has the following forms when the link layer is IEEE 802.15.4 and the addresses are EUI-64 or 16-bit short addresses, respectively.
当链路层为IEEE 802.15.4且地址分别为EUI-64或16位短地址时，源/目标链路层地址选项具有以下形式。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- IEEE 802.15.4 -+
| EUI-64 |
+- -+
| |
+- Address -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- Padding -+
| |
+- (all zeros) -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- IEEE 802.15.4 -+
| EUI-64 |
+- -+
| |
+- Address -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- Padding -+
| |
+- (all zeros) -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 16-bit short Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- Padding -+
| (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 16-bit short Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- Padding -+
| (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7
图7
Option fields:
选项字段：
Type:
类型：
1: for Source Link-layer address.
1：用于源链接层地址。
2: for Target Link-layer address.
2：用于目标链路层地址。
Length: This is the length of this option (including the type and length fields) in units of 8 octets. The value of this field is 2 if using EUI-64 addresses, or 1 if using 16-bit short addresses.
长度：此选项的长度（包括类型和长度字段），以8个八位字节为单位。如果使用EUI-64地址，则该字段的值为2；如果使用16位短地址，则该字段的值为1。
IEEE 802.15.4 Address: The 64-bit IEEE 802.15.4 address, or the 16- bit short address (as per the format in Section 9), in canonical
IEEE 802.15.4地址：标准格式的64位IEEE 802.15.4地址或16位短地址（按照第9节中的格式）
bit order. This is the address the interface currently responds to. This address may be different from the built-in address used to derive the Interface Identifier, because of privacy or security (e.g., of neighbor discovery) considerations.
位顺序。这是接口当前响应的地址。由于隐私或安全（例如，邻居发现）考虑，此地址可能不同于用于派生接口标识符的内置地址。
The functionality in this section MUST only be used in a mesh-enabled LoWPAN. An IPv6 packet with a multicast destination address (DST), consisting of the sixteen octets DST[1] through DST[16], is transmitted to the following 802.15.4 16-bit multicast address:
本节中的功能只能在启用网格的LoWPAN中使用。具有多播目标地址（DST）的IPv6数据包（由16个八位字节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] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8
图8
Here, DST[15]* refers to the last 5 bits in octet DST[15], that is, bits 3-7 within DST[15]. The initial 3-bit pattern of "100" follows the 16-bit address format for multicast addresses (Section 12).
这里，DST[15]*指八位字节DST[15]中的最后5位，即DST[15]中的位3-7。最初的3位模式“100”遵循16位多播地址格式（第12节）。
This allows for multicast support within 6LoWPAN networks, but the full specification of such support is out of the scope of this document. Example mechanisms are: flooding, controlled flooding, unicasting to the PAN coordinator, etc. It is expected that this would be specified by the different mesh routing mechanisms.
这允许在6LoWPAN网络中支持多播，但此类支持的完整规范不在本文档的范围内。示例机制有：泛洪、受控泛洪、到PAN协调器的单播等。预计这将由不同的网状路由机制指定。
There is much published and in-progress standardization work on header compression. Nevertheless, header compression for IPv6 over IEEE 802.15.4 has differing constraints summarized as follows:
关于报头压缩的标准化工作已经发表了很多，并且正在进行中。然而，IEEE 802.15.4上IPv6的报头压缩有以下不同的限制：
Existing work assumes that there are many flows between any two devices. Here, we assume a very simple and low-context flavor of header compression. Whereas this works independently of flows (potentially several), it does not use any context specific to any flow. Thus, it cannot achieve as much compression as schemes that build a separate context for each flow to be compressed.
现有工作假设任意两个设备之间存在许多流。这里，我们假设一个非常简单和低上下文风格的头压缩。尽管它独立于流（可能有几个流）工作，但它不使用任何流特定的上下文。因此，它无法实现与为每个要压缩的流构建单独上下文的方案一样多的压缩。
Given the very limited packet sizes, it is highly desirable to integrate layer 2 with layer 3 compression, something traditionally not done (although now changing due to the ROHC (RObust Header Compression) working group).
由于数据包大小非常有限，因此非常希望将第2层与第3层压缩集成在一起，这是传统上没有做过的事情（尽管现在由于ROHC（鲁棒头压缩）工作组而有所改变）。
It is expected that IEEE 802.15.4 devices will be deployed in multi-hop networks. However, header compression in a mesh departs from the usual point-to-point link scenario in which the compressor and decompressor are in direct and exclusive communication with each other. In an IEEE 802.15.4 network, it is highly desirable for a device to be able to send header compressed packets via any of its neighbors, with as little preliminary context-building as possible.
预计IEEE 802.15.4设备将部署在多跳网络中。然而，网格中的报头压缩不同于通常的点到点链路场景，在这种场景中，压缩器和解压缩器彼此直接且独占地通信。在IEEE 802.15.4网络中，非常希望设备能够通过其任何邻居发送头压缩数据包，并且尽可能少地进行初步上下文构建。
Any new packet formats required by header compression reuse the basic packet formats defined in Section 5 by using different dispatch values.
报头压缩所需的任何新数据包格式通过使用不同的分派值，重用第5节中定义的基本数据包格式。
Header compression may result in alignment not falling on an octet boundary. Since hardware typically cannot transmit data in units less than an octet, padding must be used. Padding is done as follows: First, the entire series of contiguous compressed headers is laid out (this document only defines IPv6 and UDP header compression schemes, but others may be defined elsewhere). Then, zero bits SHOULD be added as appropriate to align to an octet boundary. This counteracts any potential misalignment caused by header compression, so subsequent fields (e.g., non-compressed headers or data payloads) start on an octet boundary and follow as usual.
标题压缩可能导致对齐不落在八位字节边界上。由于硬件通常不能以小于八位字节的单位传输数据，因此必须使用填充。填充按如下方式完成：首先，布置整个连续压缩头序列（本文档仅定义IPv6和UDP头压缩方案，但其他可能在其他地方定义）。然后，应酌情添加零位，以与八位字节边界对齐。这抵消了由报头压缩引起的任何潜在错位，因此后续字段（例如，未压缩的报头或数据有效负载）从八位字节边界开始，并照常进行。
By virtue of having joined the same 6LoWPAN network, devices share some state. This makes it possible to compress headers without explicitly building any compression context state. Therefore, 6LoWPAN header compression does not keep any flow state; instead, it relies on information pertaining to the entire link. The following IPv6 header values are expected to be common on 6LoWPAN networks, so the HC1 header has been constructed to efficiently compress them from the onset: Version is IPv6; both IPv6 source and destination addresses are link local; the IPv6 interface identifiers (bottom 64 bits) for the source or destination addresses can be inferred from the layer two source and destination addresses (of course, this is only possible for interface identifiers derived from an underlying 802.15.4 MAC address); the packet length can be inferred either from layer two ("Frame Length" in the IEEE 802.15.4 PPDU) or from the "datagram_size" field in the fragment header (if present); both the Traffic Class and the Flow Label are zero; and the Next Header is UDP, ICMP or TCP. The only field in the IPv6 header that always needs to be carried in full is the Hop Limit (8 bits). Depending on how closely the packet matches this common case, different fields may not be compressible thus needing to be carried "in-line" as well (Section 10.3.1). This common IPv6 header (as mentioned above) can be compressed to 2 octets (1 octet for the HC1 encoding and 1 octet
由于加入了相同的6LoWPAN网络，设备共享一些状态。这使得无需显式构建任何压缩上下文状态就可以压缩头。因此，6LoWPAN割台压缩不会保持任何流动状态；相反，它依赖于与整个链接相关的信息。以下IPv6报头值在6LoWPAN网络上很常见，因此构造HC1报头可以从一开始就有效地压缩它们：版本为IPv6；IPv6源地址和目标地址都是本地链路；源地址或目标地址的IPv6接口标识符（底部64位）可以从第二层源地址和目标地址推断出来（当然，这仅适用于从底层802.15.4 MAC地址派生的接口标识符）；分组长度可以从第二层（“IEEE 802.15.4 PPDU中的帧长度”）或者从片段报头（如果存在）中的“数据报大小”字段推断；交通等级和流量标签均为零；下一个报头是UDP、ICMP或TCP。IPv6报头中始终需要完整携带的唯一字段是跃点限制（8位）。根据数据包与这种常见情况的匹配程度，不同字段可能不可压缩，因此也需要“在线”携带（第10.3.1节）。这个公共IPv6报头（如上所述）可以压缩为2个八位字节（1个八位字节用于HC1编码，1个八位字节用于HC1编码）
for the Hop Limit), instead of 40 octets. Such a packet is compressible via the LOWPAN_HC1 format by using a Dispatch value of LOWPAN_HC1 followed by a LOWPAN_HC1 header "HC1 encoding" field (8 bits) to encode the different combinations as shown below. This header may be preceded by a fragmentation header, which may be preceded by a mesh header.
对于跃点限制），而不是40个八位字节。通过使用LOWPAN_HC1的分派值，然后使用LOWPAN_HC1报头“HC1编码”字段（8位）来编码如下所示的不同组合，这样的分组可通过LOWPAN_HC1格式压缩。此标头之前可能有碎片标头，碎片标头之前可能有网格标头。
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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: LOWPAN_HC1 (common compressed header encoding)
图9:LOWPAN_HC1（通用压缩头编码）
As can be seen below (bit 7), an HC2 encoding may follow an HC1 octet. In this case, the non-compressed fields follow the HC2 encoding field (Section 10.3).
如下文（第7位）所示，HC2编码可能跟在HC1八位组之后。在这种情况下，非压缩字段遵循HC2编码字段（第10.3节）。
The address fields encoded by "HC1 encoding" are interpreted as follows:
通过“HC1编码”编码的地址字段解释如下：
PI: Prefix carried in-line (Section 10.3.1).
PI：行内携带的前缀（第10.3.1节）。
PC: Prefix compressed (link-local prefix assumed).
PC：前缀压缩（假定为链路本地前缀）。
II: Interface identifier carried in-line (Section 10.3.1).
II：在线携带的接口标识符（第10.3.1节）。
IC: Interface identifier elided (derivable from the corresponding link-layer address). If applied to the interface identifier of either the source or destination address when routing in a mesh (Section 11), the corresponding link-layer address is that found in the "Mesh Addressing" field (Section 5.2).
IC：省略的接口标识符（可从相应的链路层地址派生）。如果在网格中路由时应用于源地址或目标地址的接口标识符（第11节），则相应的链路层地址为“网格寻址”字段中的地址（第5.2节）。
The "HC1 encoding" is shown below (starting with bit 0 and ending at bit 7):
“HC1编码”如下所示（从位0开始，在位7结束）：
IPv6 source address (bits 0 and 1):
IPv6源地址（位0和1）：
00: PI, II
00:PI，II
01: PI, IC
01:PI，IC
10: PC, II
10:PC，II
11: PC, IC
11:PC、IC
IPv6 destination address (bits 2 and 3):
IPv6目标地址（第2位和第3位）：
00: PI, II
00:PI，II
01: PI, IC
01:PI，IC
10: PC, II
10:PC，II
11: PC, IC
11:PC、IC
Traffic Class and Flow Label (bit 4):
交通等级和流量标签（第4位）：
0: not compressed; full 8 bits for Traffic Class and 20 bits for Flow Label are sent
0：未压缩；发送的流量等级为8位，流量标签为20位
1: Traffic Class and Flow Label are zero
1：交通等级和流量标签为零
Next Header (bits 5 and 6):
下一个标题（第5位和第6位）：
00: not compressed; full 8 bits are sent
00：未压缩；发送完整的8位
01: UDP
01:UDP
10: ICMP
10:ICMP
11: TCP
11:TCP
HC2 encoding(bit 7):
HC2编码（第7位）：
0: No more header compression bits
0：不再有头压缩位
1: HC1 encoding immediately followed by more header compression bits per HC2 encoding format. Bits 5 and 6 determine which of the possible HC2 encodings apply (e.g., UDP, ICMP, or TCP encodings).
1:HC1编码紧接着每个HC2编码格式有更多的报头压缩位。位5和6确定应用哪种可能的HC2编码（例如UDP、ICMP或TCP编码）。
Bits 5 and 6 of the LOWPAN_HC1 allows compressing the Next Header field in the IPv6 header (for UDP, TCP, and ICMP). Further compression of each of these protocol headers is also possible. This section explains how the UDP header itself may be compressed. The HC2 encoding in this section is the HC_UDP encoding, and it only applies if bits 5 and 6 in HC1 indicate that the protocol that follows the IPv6 header is UDP. The HC_UDP encoding (Figure 10) allows compressing the following fields in the UDP header: source port, destination port, and length. The UDP header's checksum field is not compressed and is therefore carried in full. The scheme
LOWPAN_HC1的第5位和第6位允许压缩IPv6报头中的下一个报头字段（对于UDP、TCP和ICMP）。还可以进一步压缩这些协议头中的每一个。本节解释如何压缩UDP报头本身。本节中的HC2编码是HC_UDP编码，仅当HC1中的第5位和第6位指示IPv6标头后面的协议是UDP时，该编码才适用。HC_UDP编码（图10）允许压缩UDP报头中的以下字段：源端口、目标端口和长度。UDP报头的校验和字段未被压缩，因此被完整携带。计划
defined below allows compressing the UDP header to 4 octets instead of the original 8 octets.
下面定义的允许将UDP报头压缩为4个八位字节，而不是原来的8个八位字节。
The only UDP header field whose value may be deduced from information available elsewhere is the Length. The other fields must be carried in-line either in full or in a partially compressed manner (Section 10.3.2).
唯一可以从其他地方可用的信息推断其值的UDP头字段是长度。其他字段必须以完全或部分压缩的方式在线进行（第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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: HC_UDP (UDP common compressed header encoding)
图10:HC_UDP（UDP通用压缩头编码）
The "HC_UDP encoding" for UDP is shown below (starting with bit 0 and ending at bit 7):
UDP的“HC_UDP编码”如下所示（从位0开始，在位7结束）：
UDP source port (bit 0):
UDP源端口（位0）：
0: Not compressed, carried "in-line" (Section 10.3.2)
0：未压缩，“在线”运输（第10.3.2节）
1: Compressed to 4 bits. The actual 16-bit source port is obtained by calculating: P + short_port value. The value of P is the number 61616 (0xF0B0). The short_port is expressed as a 4-bit value which is carried "in-line" (Section 10.3.2)
1：压缩到4位。实际的16位源端口通过计算：P+short_port值获得。P的值是数字61616（0xF0B0）。短_端口表示为4位值，该值“在线”携带（第10.3.2节）
UDP destination port (bit 1):
UDP目标端口（位1）：
0: Not compressed, carried "in-line" (Section 10.3.2)
0：未压缩，“在线”运输（第10.3.2节）
1: Compressed to 4 bits. The actual 16-bit destination port is obtained by calculating: P + short_port value. The value of P is the number 61616 (0xF0B0). The short_port is expressed as a 4-bit value which is carried "in-line" (Section 10.3.2)
1：压缩到4位。实际的16位目标端口是通过计算：P+short_port值获得的。P的值是数字61616（0xF0B0）。短_端口表示为4位值，该值“在线”携带（第10.3.2节）
Length (bit 2):
长度（第2位）：
0: not compressed, carried "in-line" (Section 10.3.2)
0：未压缩，“在线”运输（第10.3.2节）
1: compressed, length computed from IPv6 header length information. The value of the UDP length field is equal to the Payload Length from the IPv6 header, minus the length of any extension headers present between the IPv6 header and the UDP header.
1：压缩，根据IPv6标头长度信息计算长度。UDP长度字段的值等于IPv6标头的有效负载长度减去IPv6标头和UDP标头之间存在的任何扩展标头的长度。
Reserved (bit 3 through 7)
保留（第3位到第7位）
This scheme allows the IPv6 header to be compressed to different degrees. Hence, instead of the entire (standard) IPv6 header, only non-compressed fields need to be sent. The subsequent header (as specified by the Next Header field in the original IPv6 header) immediately follows the IPv6 non-compressed fields.
该方案允许对IPv6报头进行不同程度的压缩。因此，不需要发送整个（标准）IPv6报头，只需要发送非压缩字段。后续标头（由原始IPv6标头中的下一个标头字段指定）紧跟在IPv6非压缩字段之后。
Uncompressed IPv6 addressing is described by a dispatch type containing an IPv6 dispatch value followed by the uncompressed IPv6 header. This dispatch type may be preceded by additional LoWPAN headers.
未压缩的IPv6寻址由一个调度类型描述，该类型包含一个IPv6调度值，后跟未压缩的IPv6标头。此分派类型之前可能会有其他LoWPAN标头。
The non-compressed IPv6 field that MUST be always present is the Hop Limit (8 bits). This field MUST always follow the encoding fields (e.g., "HC1 encoding" as shown in Figure 9), perhaps including other future encoding fields). Other non-compressed fields MUST follow the Hop Limit as implied by the "HC1 encoding" in the exact same order as shown above (Section 10.1): source address prefix (64 bits) and/or interface identifier (64 bits), destination address prefix (64 bits) and/or interface identifier (64 bits), Traffic Class (8 bits), Flow Label (20 bits) and Next Header (8 bits). The actual next header (e.g., UDP, TCP, ICMP, etc) follows the non-compressed fields.
必须始终存在的非压缩IPv6字段是跃点限制（8位）。该字段必须始终位于编码字段之后（如图9所示的“HC1编码”），可能包括其他未来的编码字段）。其他非压缩字段必须遵循“HC1编码”所暗示的跃点限制，其顺序与上文所示完全相同（第10.1节）：源地址前缀（64位）和/或接口标识符（64位）、目标地址前缀（64位）和/或接口标识符（64位）、流量类别（8位）、流量标签（20位）和下一个报头（8位）。实际的下一个报头（如UDP、TCP、ICMP等）位于非压缩字段之后。
This scheme allows the UDP header to be compressed to different degrees. Hence, instead of the entire (standard) UDP header, only non-compressed or partially compressed fields need to be sent.
该方案允许对UDP报头进行不同程度的压缩。因此，不需要发送整个（标准）UDP报头，只需要发送未压缩或部分压缩的字段。
The non-compressed or partially compressed fields in the UDP header MUST always follow the IPv6 header and any of its associated in-line fields. Any UDP header in-line fields present MUST appear in the same order as the corresponding fields appear in a normal UDP header [RFC0768], e.g., source port, destination port, length, and checksum. If either the source or destination ports are in "short_port" notation (as indicated in the compressed UDP header), then instead of taking 16 bits, the inline port numbers take 4 bits.
UDP报头中的非压缩或部分压缩字段必须始终位于IPv6报头及其任何关联的内嵌字段之后。存在的任何UDP报头内联字段的显示顺序必须与正常UDP报头[RFC0768]中相应字段的显示顺序相同，例如，源端口、目标端口、长度和校验和。如果源端口或目标端口采用“short_port”表示法（如压缩UDP报头中所示），则内联端口号不采用16位，而是采用4位。
Even though 802.15.4 networks are expected to commonly use mesh routing, the IEEE 802.15.4-2003 specification [ieee802.15.4] does not define such capability. In such cases, Full Function Devices (FFDs) run an ad hoc or mesh routing protocol to populate their routing tables (outside the scope of this document). In such mesh scenarios,
尽管802.15.4网络通常使用网状路由，但IEEE 802.15.4-2003规范[ieee802.15.4]并未定义此类功能。在这种情况下，全功能设备（FFD）运行特别或网状路由协议来填充其路由表（不在本文档范围内）。在这种情况下，
two devices do not require direct reachability in order to communicate. Of these devices, the sender is known as the "Originator", and the receiver is known as the "Final Destination". An originator device may use other intermediate devices as forwarders towards the final destination. In order to achieve such frame delivery using unicast, it is necessary to include the link-layer addresses of the originator and final destinations, in addition to the hop-by-hop source and destination.
两个设备不需要直接可达性来进行通信。在这些设备中，发送方称为“发起者”，接收方称为“最终目的地”。发端设备可以使用其他中间设备作为朝向最终目的地的转发器。为了使用单播实现这样的帧交付，除了逐跳源和目的地之外，还需要包括发起者和最终目的地的链路层地址。
This section defines how to effect delivery of layer 2 frames in a mesh, given a target "Final Destination" link-layer address.
本节定义了在给定目标“最终目的地”链接层地址的情况下，如何在网格中实现第2层帧的交付。
Mesh delivery is enabled by including a Mesh Addressing header prior to any other headers of the LoWPAN encapsulation (Section 5), an unfragmented and fragmented header; a full-blown IPv6 header; or a compressed IPv6 header as per Section 10 or any others defined elsewhere.
通过在LoWPAN封装（第5节）的任何其他报头之前包含一个网格寻址报头，一个未分段和分段的报头，可以实现网格交付；完整的IPv6报头；或第10节或其他地方定义的压缩IPv6标头。
If a node wishes to use a default mesh forwarder to deliver a packet (i.e., because it does not have direct reachability to the destination), it MUST include a Mesh Addressing header with the originator's link-layer address set to its own, and the final destination's link-layer address set to the packet's ultimate destination. It sets the source address in the 802.15.4 header to its own link-layer address, and puts the forwarder's link-layer address in the 802.15.4 header's destination address field. Finally, it transmits the packet.
如果节点希望使用默认mesh转发器交付数据包（即，因为它无法直接到达目的地），则它必须包括一个mesh寻址报头，其中发起者的链路层地址设置为自己的，最终目的地的链路层地址设置为数据包的最终目的地。它将802.15.4报头中的源地址设置为自己的链路层地址，并将转发器的链路层地址放入802.15.4报头的目标地址字段中。最后，它传输数据包。
Similarly, if a node receives a frame with a Mesh Addressing header, it must look at the Mesh Addressing header's "Final Destination" field to determine the real destination. If the node is itself the final destination, it consumes the packet as per normal delivery. If it is not the final destination, the device then reduces the "Hops Left" field, and if the result is zero, discards the packet. Otherwise, the node consults its link-layer routing table, determines what the next hop towards the final destination should be, and puts that address in the destination address field of the 802.15.4 header. Finally, the node changes the source address in the 802.15.4 header to its own link-layer address and transmits the packet.
类似地，如果节点接收到具有网状寻址报头的帧，则必须查看网状寻址报头的“最终目的地”字段以确定实际目的地。如果节点本身是最终目的地，它将按照正常传递方式使用数据包。如果不是最终目的地，则设备会减少“左跳”字段，如果结果为零，则丢弃数据包。否则，节点参考其链路层路由表，确定朝向最终目的地的下一跳应该是什么，并将该地址放入802.15.4报头的目的地地址字段中。最后，节点将802.15.4报头中的源地址更改为其自己的链路层地址，并传输数据包。
Whereas a node must participate in a mesh routing protocol to be a forwarder, no such requirement exists for simply using mesh forwarding. Only "Full Function Devices" (FFDs) are expected to participate as routers in a mesh. "Reduced Function Devices" (RFDs) limit themselves to discovering FFDs and using them for all their forwarding, in a manner similar to how IP hosts typically use default routers to forward all their off-link traffic. For an RFD using mesh delivery, the "forwarder" is always the appropriate FFD.
尽管节点必须参与mesh路由协议才能成为转发器，但对于简单地使用mesh转发，不存在这样的要求。只有“全功能设备”（FFD）才能作为路由器参与网状网。“精简功能设备”（RFD）将其自身限制为发现FFD并将其用于所有转发，其方式类似于IP主机通常使用默认路由器转发其所有非链接流量的方式。对于使用网格交付的RFD，“转发器”始终是合适的FFD。
Additional mesh routing functionality is encoded using a routing header immediately following the Mesh header. In particular, a broadcast header consists of a LOWPAN_BC0 dispatch followed by a sequence number field. The sequence number is used to detect duplicate packets (and hopefully suppress them).
使用紧跟在网格标头之后的路由标头对其他网格路由功能进行编码。特别是，广播报头由LOWPAN_BC0调度和序列号字段组成。序列号用于检测重复的数据包（希望能够抑制它们）。
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|1|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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Broadcast Header
图11：广播报头
Field definitions are as follows:
字段定义如下：
Sequence Number: This 8-bit field SHALL be incremented by the originator whenever it sends a new mesh broadcast or multicast packet. Full specification of how to handle this field is out of the scope of this document.
序列号：发起者在发送新的网状广播或多播数据包时，应增加该8位字段。如何处理此字段的完整规范不在本文档的范围内。
Further implications of such mesh-layer broadcast, e.g., whether it maps to a controlled flooding mechanism or its role in, say, topology discovery, is out of the scope of this document.
此类网状层广播的进一步含义（例如，它是否映射到受控泛洪机制或其在拓扑发现中的作用）不在本文档的范围内。
Additional mesh routing capabilities, such as specifying the mesh routing protocol, source routing, and so on may be expressed by defining additional routing headers that precede the fragmentation or addressing header in the header stack. The full specification of such mesh routing capabilities are out of the scope of this document.
额外的网状路由功能，例如指定网状路由协议、源路由等，可以通过在报头堆栈中的分段或寻址报头之前定义额外的路由报头来表示。此类网状布线功能的完整规范不在本文档范围内。
This document creates two new IANA registries, as discussed below. Future assignments in these registries are to be coordinated via IANA under the policy of "Specification Required" [RFC2434]. It is expected that this policy will allow for other (non-IETF) organizations to more easily obtain assignments.
本文档创建了两个新的IANA注册中心，如下所述。这些登记处的未来分配将根据“要求规范”政策通过IANA进行协调[RFC2434]。预计该政策将允许其他（非IETF）组织更容易获得任务。
This document creates a new IANA registry for the Dispatch type field shown in the header definitions in Section 5. This document defines the values IPv6, LOWPAN_HC1 header compression, BC0 broadcast and two escape patterns (NALP to indicate not a LOWPAN frame and ESC to allow additional dispatch bytes). This document defines this field to be 8 bits long. The values 00xxxxxx being reserved and not used, allows for a total of 192 different values, which should be more than
本文档为第5节标题定义中显示的分派类型字段创建一个新的IANA注册表。本文档定义了值IPv6、LOWPAN_HC1报头压缩、BC0广播和两种转义模式（NALP表示非LOWPAN帧，ESC表示允许额外的调度字节）。本文档将此字段定义为8位长。保留且未使用的值00xxxxxx允许总共192个不同的值，这些值应大于
enough. If header compression formats in addition to HC1 are defined or if additional TCP, ICMP HC2 formats are defined, it is expected that these will use reserved dispatch values following LOWPAN_HC1. If additional mesh delivery formats are defined these will use reserved values following LOWPAN_BC0.
足够地如果定义了除HC1之外的报头压缩格式，或者定义了其他TCP、ICMP HC2格式，则预计这些格式将使用LOWPAN_HC1之后的保留调度值。如果定义了其他网格传递格式，这些格式将使用LOWPAN_BC0之后的保留值。
This document creates a new IANA registry for the 16-bit short address fields as used in 6LoWPAN packets.
本文档为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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 16-bit short Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12
图12
This registry MUST include the addresses 0xffff (16-bit broadcast address accepted by all devices currently listening to the channel) and 0xfffe as defined in [ieee802.15.4]. Additionally, within 6LoWPAN networks, 16-bit short addresses MUST follow this format (referring to bit fields in the order from 0 to 7), where "x" is a place holder for an unspecified bit value:
该注册表必须包括[ieee802.15.4]中定义的地址0xffff（当前收听频道的所有设备接受的16位广播地址）和0xfffe。此外，在6LoWPAN网络中，16位短地址必须遵循此格式（指从0到7的顺序的位字段），其中“x”是未指定位值的占位符：
Range 1, 0xxxxxxxxxxxxxxx: The first bit (bit 0) SHALL be zero if the 16-bit address is a unicast address. This leaves 15 bits for the actual address.
范围1，0xxxxxxxxxx：如果16位地址是单播地址，则第一位（位0）应为零。这将为实际地址保留15位。
Range 2, 100xxxxxxxxxxxxx: Bits 0, 1, and 2 SHALL follow this pattern if the 16-bit address is a multicast address (see Section 9). This leaves 13 bits for the actual multicast address.
范围2，100xxxxxxxx：如果16位地址是多播地址，则位0、1和2应遵循此模式（参见第9节）。这将为实际多播地址保留13位。
Range 3, 101xxxxxxxxxxxxx: This pattern for bits 0, 1, and 2 is reserved. Any future assignment shall follow the policy mentioned above.
范围3，101xxxxxxxx：位0、1和2的此模式是保留的。任何未来的派遣应遵循上述政策。
Range 4, 110xxxxxxxxxxxxx: This pattern for bits 0, 1, and 2 is reserved. Any future assignment shall follow the policy mentioned above.
范围4，110xxxxxxxx：保留位0、1和2的此模式。任何未来的派遣应遵循上述政策。
Range 5, 111xxxxxxxxxxxxx: This pattern for bits 0, 1, and 2 is reserved. Any future assignment shall follow the policy mentioned above.
范围51111xxxxxxxx：位0、1和2的此模式是保留的。任何未来的派遣应遵循上述政策。
The method of derivation of Interface Identifiers from EUI-64 MAC addresses is intended to preserve global uniqueness when possible. However, there is no protection from duplication through accident or forgery.
从EUI-64 MAC地址派生接口标识符的方法旨在尽可能保持全局唯一性。但是，由于意外或伪造，无法防止复制。
Neighbor Discovery in IEEE 802.15.4 links may be susceptible to threats as detailed in [RFC3756]. Mesh routing is expected to be common in IEEE 802.15.4 networks. This implies additional threats due to ad hoc routing as per [KW03]. IEEE 802.15.4 provides some capability for link-layer security. Users are urged to make use of such provisions if at all possible and practical. Doing so will alleviate the threats stated above.
IEEE 802.15.4链路中的邻居发现可能容易受到[RFC3756]中详述的威胁。网状路由预计在IEEE 802.15.4网络中很常见。根据[KW03]，这意味着由于临时路由而产生的额外威胁。IEEE 802.15.4为链路层安全提供了一些功能。促请用户尽可能和切实可行地利用这些规定。这样做将减轻上述威胁。
A sizeable portion of IEEE 802.15.4 devices is expected to always communicate within their PAN (i.e., within their link, in IPv6 terms). In response to cost and power consumption considerations, and in keeping with the IEEE 802.15.4 model of "Reduced Function Devices" (RFDs), these devices will typically implement the minimum set of features necessary. Accordingly, security for such devices may rely quite strongly on the mechanisms defined at the link layer by IEEE 802.15.4. The latter, however, only defines the Advanced Encryption Standard (AES) modes for authentication or encryption of IEEE 802.15.4 frames, and does not, in particular, specify key management (presumably group oriented). Other issues to address in real deployments relate to secure configuration and management. Whereas such a complete picture is out of the scope of this document, it is imperative that IEEE 802.15.4 networks be deployed with such considerations in mind. Of course, it is also expected that some IEEE 802.15.4 devices (the so-called "Full Function Devices", or "FFDs") will implement coordination or integration functions. These may communicate regularly with off-link IPv6 peers (in addition to the more common on-link exchanges). Such IPv6 devices are expected to secure their end-to-end communications with the usual mechanisms (e.g., IPsec, TLS, etc).
IEEE 802.15.4设备的相当一部分预计总是在其PAN内通信（即，在IPv6术语中，在其链路内）。为了响应成本和功耗考虑，并符合IEEE 802.15.4“精简功能设备”（RFD）模型，这些设备通常将实现所需的最小功能集。因此，此类设备的安全性可能非常强烈地依赖于IEEE 802.15.4在链路层定义的机制。然而，后者仅定义了用于认证或加密IEEE 802.15.4帧的高级加密标准（AES）模式，并且没有特别指定密钥管理（可能是面向组的）。在实际部署中要解决的其他问题与安全配置和管理有关。尽管如此完整的描述不在本文件的范围内，但在部署IEEE 802.15.4网络时必须考虑到这些因素。当然，预计一些IEEE 802.15.4设备（所谓的“全功能设备”或“FFD”）将实现协调或集成功能。它们可以定期与脱离链路的IPv6对等方通信（除了更常见的链路交换）。这类IPv6设备有望通过通常的机制（如IPsec、TLS等）保护其端到端通信的安全。
Thanks to the authors of RFC 2464 and RFC 2734, as parts of this document are patterned after theirs. Thanks to Geoff Mulligan for useful discussions which helped shape this document. Erik Nordmark's suggestions were instrumental for the header compression section. Also thanks to Shoichi Sakane, Samita Chakrabarti, Vipul Gupta, Carsten Bormann, Ki-Hyung Kim, Mario Mao, Phil Levis, Magnus Westerlund, and Jari Arkko.
感谢RFC2464和RFC2734的作者，因为本文档的部分内容是模仿他们的。感谢Geoff Mulligan进行了有益的讨论，帮助形成了本文件。埃里克·诺德马克的建议对标题压缩部分很有帮助。还要感谢坂根昭一、查克拉巴蒂、古普塔、卡斯滕·鲍曼、基亨金、毛马里奥、菲尔·列维斯、马格纳斯·韦斯特隆德和贾里·阿尔科。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[RFC2464]克劳福德，M.，“通过以太网传输IPv6数据包”，RFC2464，1998年12月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 48612007年9月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862]Thomson，S.，Narten，T.，和T.Jinmei，“IPv6无状态地址自动配置”，RFC 48622007年9月。
[ieee802.15.4] IEEE Computer Society, "IEEE Std. 802.15.4-2003", October 2003.
[ieee802.15.4]IEEE计算机协会，“IEEE标准802.15.4-2003”，2003年10月。
[EUI64] "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) REGISTRATION AUTHORITY", IEEE http:// standards.ieee.org/regauth/oui/tutorials/EUI64.html.
[EUI64]“64位全局标识符（EUI-64）注册机构指南”，IEEE http://standards.IEEE.org/regauth/oui/tutorials/EUI64.html。
[KW03] Karlof, Chris and Wagner, David, "Secure Routing in Sensor Networks: Attacks and Countermeasures", Elsevier's AdHoc Networks Journal, Special Issue on Sensor Network Applications and Protocols vol 1, issues 2-3, September 2003.
[KW03]Karlof，Chris和Wagner，David，“传感器网络中的安全路由：攻击和对策”，爱思唯尔的AdHoc Networks杂志，传感器网络应用和协议专刊，第1卷，第2-3期，2003年9月。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[RFC3756]Nikander，P.，Kempf，J.，和E.Nordmark，“IPv6邻居发现（ND）信任模型和威胁”，RFC 37562004年5月。
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, "Advice for Internet Subnetwork Designers", BCP 89, RFC 3819, July 2004.
[RFC3819]Karn，P.，Bormann，C.，Fairhurst，G.，Grossman，D.，路德维希，R.，Mahdavi，J.，黑山，G.，Touch，J.，和L.Wood，“互联网子网络设计师的建议”，BCP 89，RFC 3819，2004年7月。
Before settling on the mechanism finally adopted for delivery in a mesh (Section 11), several alternatives were considered. In addition to the hop-by-hop source and destination link-layer addresses, delivering a packet in a LoWPAN mesh requires the end-to-end originator and destination addresses. These could be expressed either as layer 2 or as layer 3 (i.e., IP ) addresses. In the latter case, there would be no need to provide any additional header support in this document (i.e., within the LoWPAN header itself). The link-layer destination address would point to the next hop destination address while the IP header destination address would point to the final destination (IP) address (possibly multiple hops away from the source), and similarly for the source addresses. Thus, while forwarding data, the single-hop source and destination addresses would change at each hop (always pointing to the node doing the forwarding and the "best" next link-layer hop, respectively), while the source and destination IP addresses would remain unchanged. Notice that if an IP packet is fragmented, the individual fragments may arrive at any node out of order. If the initial fragment (which contains the IP header) is delayed for some reason, a node that receives a subsequent fragment would lack the required information. It would be forced to wait until it receives the IP header (within the first fragment) before being able to forward the fragment any further. This imposes some additional buffering requirements on intermediate nodes. Additionally, such a specification would only work for one type of LoWPAN payload: IPv6. In general, it would have to be adapted for any other payload, and would require that payload to provide its own end-to-end addressing information.
在确定最终采用的网状交付机制（第11节）之前，考虑了几种备选方案。除了逐跳的源和目标链路层地址外，在低泛网中传送数据包还需要端到端的发起者和目标地址。这些地址可以表示为第2层或第3层（即IP）地址。在后一种情况下，无需在本文件中提供任何额外的标题支持（即，在LoWPAN标题本身内）。链路层目的地地址将指向下一跳目的地地址，而IP报头目的地地址将指向最终目的地（IP）地址（可能离源有多个跳），同样，对于源地址也是如此。因此，在转发数据时，单跳源地址和目标地址将在每个跳时改变（始终分别指向进行转发的节点和“最佳”下一链路层跳），而源和目标IP地址将保持不变。请注意，如果一个IP数据包被分割，那么各个片段可能会无序地到达任何节点。如果初始片段（包含IP头）由于某种原因延迟，则接收后续片段的节点将缺少所需信息。它将被迫等待，直到它收到IP头（在第一个片段中），然后才能进一步转发片段。这对中间节点提出了一些额外的缓冲要求。此外，这样的规范只适用于一种低泛负载：IPv6。一般来说，它必须适应任何其他有效负载，并要求该有效负载提供自己的端到端寻址信息。
On the other hand, the approach finally followed (Section 11) creates a mesh at the LoWPAN layer (below layer 3). Accordingly, the link-layer originator and final destination address are included within the LoWPAN header. This enables mesh delivery for any protocol or application layered on the LoWPAN adaptation layer (Section 5). For IPv6 as supported in this document, another advantage of expressing the originator and final destinations as layer 2 addresses is that the IPv6 addresses can be compressed as per the header compression specified in Section 10. Furthermore, the number of octets needed to maintain routing tables is reduced due to the smaller size of 802.15.4 addresses (either 64 bits or 16 bits) as compared to IPv6 addresses (128 bits). A disadvantage is that applications on top of IP do not address packets to link-layer destination addresses, but to IP (layer 3) destination addresses. Thus, given an IP address, there is a need to resolve the corresponding link-layer address. Accordingly, a mesh routing specification needs to clarify the Neighbor Discovery implications, although in some special cases, it may be possible to derive a device's address at layer 2 from its
另一方面，最终采用的方法（第11节）在LoWPAN层（第3层下方）创建网格。因此，链路层发起者和最终目的地地址包括在LoWPAN报头中。这使得网格交付能够用于低泛适配层上分层的任何协议或应用程序（第5节）。对于本文档中支持的IPv6，将发起者和最终目的地表示为第2层地址的另一个优点是，可以按照第10节中指定的头压缩来压缩IPv6地址。此外，由于802.15.4地址（64位或16位）比IPv6地址（128位）小，因此维护路由表所需的八位字节数减少。一个缺点是，位于IP之上的应用程序不将数据包寻址到链路层目标地址，而是寻址到IP（第3层）目标地址。因此，给定IP地址，需要解析相应的链路层地址。因此，网状路由规范需要澄清邻居发现的含义，尽管在一些特殊情况下，可以从其邻居发现中导出第2层的设备地址
address at layer 3 (and vice versa). Such complete specification is outside the scope of this document.
第3层的地址（反之亦然）。此类完整规范不在本文件范围内。
Authors' Addresses
作者地址
Gabriel Montenegro Microsoft Corporation
加布里埃尔黑山微软公司
EMail: gabriel.montenegro@microsoft.com
EMail: gabriel.montenegro@microsoft.com
Nandakishore Kushalnagar Intel Corp
南达基肖尔库沙尔纳加尔英特尔公司
EMail: nandakishore.kushalnagar@intel.com
EMail: nandakishore.kushalnagar@intel.com
Jonathan W. Hui Arch Rock Corp
许华健岩石公司
EMail: jhui@archrock.com
EMail: jhui@archrock.com
David E. Culler Arch Rock Corp
大卫·E·卡勒拱门摇滚公司
EMail: dculler@archrock.com
EMail: dculler@archrock.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.