Internet Engineering Task Force (IETF) J. Hui, Ed.
Request for Comments: 6282 Arch Rock Corporation
Updates: 4944 P. Thubert
Category: Standards Track Cisco
ISSN: 2070-1721 September 2011
Internet Engineering Task Force (IETF) J. Hui, Ed.
Request for Comments: 6282 Arch Rock Corporation
Updates: 4944 P. Thubert
Category: Standards Track Cisco
ISSN: 2070-1721 September 2011
Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks
基于IEEE 802.15.4的网络上IPv6数据报的压缩格式
Abstract
摘要
This document updates RFC 4944, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks". This document specifies an IPv6 header compression format for IPv6 packet delivery in Low Power Wireless Personal Area Networks (6LoWPANs). The compression format relies on shared context to allow compression of arbitrary prefixes. How the information is maintained in that shared context is out of scope. This document specifies compression of multicast addresses and a framework for compressing next headers. UDP header compression is specified within this framework.
本文档更新了RFC 4944，“通过IEEE 802.15.4网络传输IPv6数据包”。本文档为低功率无线个人区域网络（6LoWPANs）中的IPv6数据包传送指定了IPv6报头压缩格式。压缩格式依赖于共享上下文来允许压缩任意前缀。如何在共享上下文中维护信息超出了范围。本文档指定了多播地址的压缩以及压缩下一个报头的框架。UDP报头压缩是在此框架内指定的。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6282.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6282.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Requirements Language ......................................4
2. Specific Updates to RFC 4944 ....................................4
3. IPv6 Header Compression .........................................5
3.1. LOWPAN_IPHC Encoding Format ................................6
3.1.1. Base Format .........................................6
3.1.2. Context Identifier Extension .......................10
3.2. IPv6 Header Encoding ......................................11
3.2.1. Traffic Class and Flow Label Compression ...........11
3.2.2. Deriving IIDs from the Encapsulating Header ........12
3.2.3. Stateless Multicast Address Compression ............13
3.2.4. Stateful Multicast Address Compression .............14
4. IPv6 Next Header Compression ...................................15
4.1. LOWPAN_NHC Format .........................................15
4.2. IPv6 Extension Header Compression .........................15
4.3. UDP Header Compression ....................................17
4.3.1. Compressing UDP Ports ..............................17
4.3.2. Compressing UDP Checksum ...........................18
4.3.3. UDP LOWPAN_NHC Format ..............................20
5. IANA Considerations ............................................20
6. Security Considerations ........................................21
7. Acknowledgements ...............................................22
8. References .....................................................22
8.1. Normative References ......................................22
8.2. Informative References ....................................23
1. Introduction ....................................................3
1.1. Requirements Language ......................................4
2. Specific Updates to RFC 4944 ....................................4
3. IPv6 Header Compression .........................................5
3.1. LOWPAN_IPHC Encoding Format ................................6
3.1.1. Base Format .........................................6
3.1.2. Context Identifier Extension .......................10
3.2. IPv6 Header Encoding ......................................11
3.2.1. Traffic Class and Flow Label Compression ...........11
3.2.2. Deriving IIDs from the Encapsulating Header ........12
3.2.3. Stateless Multicast Address Compression ............13
3.2.4. Stateful Multicast Address Compression .............14
4. IPv6 Next Header Compression ...................................15
4.1. LOWPAN_NHC Format .........................................15
4.2. IPv6 Extension Header Compression .........................15
4.3. UDP Header Compression ....................................17
4.3.1. Compressing UDP Ports ..............................17
4.3.2. Compressing UDP Checksum ...........................18
4.3.3. UDP LOWPAN_NHC Format ..............................20
5. IANA Considerations ............................................20
6. Security Considerations ........................................21
7. Acknowledgements ...............................................22
8. References .....................................................22
8.1. Normative References ......................................22
8.2. Informative References ....................................23
The [IEEE802.15.4] standard specifies an MTU of 127 bytes, yielding about 80 octets of actual Media Access Control (MAC) payload with security enabled, on a wireless link with a link throughput of 250 kbps or less. The 6LoWPAN adaptation format [RFC4944] was specified to carry IPv6 datagrams over such constrained links, taking into account limited bandwidth, memory, or energy resources that are expected in applications such as wireless sensor networks. [RFC4944] defines a Mesh Addressing header to support sub-IP forwarding, a Fragmentation header to support the IPv6 minimum MTU requirement [RFC2460], and stateless header compression for IPv6 datagrams (LOWPAN_HC1 and LOWPAN_HC2) to reduce the relatively large IPv6 and UDP headers down to (in the best case) several bytes.
[IEEE802.15.4]标准规定了127字节的MTU，在链路吞吐量小于等于250 kbps的无线链路上，产生大约80个八位字节的实际媒体访问控制（MAC）有效负载，并启用了安全性。考虑到无线传感器网络等应用中预期的有限带宽、内存或能量资源，指定6LoWPAN自适应格式[RFC4944]在此类受限链路上承载IPv6数据报。[RFC4944]定义了支持子IP转发的网状寻址报头、支持IPv6最低MTU要求的分段报头[RFC2460]，以及IPv6数据报（LOWPAN_HC1和LOWPAN_HC2）的无状态报头压缩，以将相对较大的IPv6和UDP报头减少到（在最佳情况下）几个字节。
LOWPAN_HC1 and LOWPAN_HC2 are insufficient for most practical uses of IPv6 in 6LoWPANs. LOWPAN_HC1 is most effective for link-local unicast communication, where IPv6 addresses carry the link-local prefix and an Interface Identifier (IID) directly derived from IEEE 802.15.4 addresses. In this case, both addresses may be completely elided. However, though link-local addresses are commonly used for local protocol interactions such as IPv6 Neighbor Discovery [RFC4861], DHCPv6 [RFC3315], or routing protocols, they are usually not used for application-layer data traffic, so the actual value of this compression mechanism is limited.
LOWPAN_HC1和LOWPAN_HC2不足以在6LoWPANs中实现IPv6的大多数实际应用。LOWPAN_HC1对于链路本地单播通信最有效，其中IPv6地址携带链路本地前缀和直接从IEEE 802.15.4地址派生的接口标识符（IID）。在这种情况下，两个地址都可以完全省略。然而，尽管链路本地地址通常用于本地协议交互，如IPv6邻居发现[RFC4861]、DHCPv6[RFC3315]或路由协议，但它们通常不用于应用层数据通信，因此这种压缩机制的实际价值是有限的。
Routable addresses must be used when communicating with devices external to the 6LoWPAN or in a route-over configuration where IP forwarding occurs within the 6LoWPAN. For routable addresses, LOWPAN_HC1 requires both IPv6 source and destination addresses to carry the prefix in-line. In cases where the Mesh Addressing header is not used, the IID of a routable address must be carried in-line. However, LOWPAN_HC1 requires 64 bits for the IID when carried in-line and cannot be shortened even when it is derived from the IEEE 802.15.4 16-bit short address. When the destination is an IPv6 multicast address, LOWPAN_HC1 requires the full 128-bit address to be carried in-line.
当与6LoWPAN外部设备通信时，或在IP转发发生在6LoWPAN内的route over配置中，必须使用可路由地址。对于可路由地址，LOWPAN_HC1要求IPv6源地址和目标地址在线携带前缀。在不使用网状寻址报头的情况下，可路由地址的IID必须在线携带。然而，LOWPAN_HC1在线路中传输时需要64位IID，即使它是从IEEE 802.15.4 16位短地址派生出来的，也不能缩短。当目标是IPv6多播地址时，LOWPAN_HC1要求在线携带完整的128位地址。
As a result, this document defines an encoding format, LOWPAN_IPHC, for effective compression of Unique Local, Global, and multicast IPv6 Addresses based on shared state within contexts. In addition, this document also introduces a number of additional improvements over the header compression format defined in [RFC4944].
因此，本文档定义了一种编码格式LOWPAN_IPHC，用于根据上下文中的共享状态有效压缩唯一的本地、全局和多播IPv6地址。此外，本文档还介绍了对[RFC4944]中定义的报头压缩格式的一些额外改进。
LOWPAN_IPHC allows for compression of some commonly used IPv6 Hop Limit values. If the 6LoWPAN is a mesh-under stub, a Hop Limit of 1 for inbound and a default value such as 64 for outbound are usually enough for application-layer data traffic. Additionally, a Hop Limit
LOWPAN_IPHC允许压缩一些常用的IPv6跃点限制值。如果6LoWPAN是存根下的网格，则入站的跃点限制为1，出站的默认值（如64）通常足以满足应用层数据流量。此外，还有一个跃点限制
value of 255 is often used to verify that a communication occurs over a single-hop. This specification enables compression of the IPv6 Hop Limit field in those common cases, whereas LOWPAN_HC1 does not.
值255通常用于验证通信是否在单跳上发生。该规范允许在这些常见情况下压缩IPv6跃点限制字段，而LOWPAN_HC1则不支持。
This document also defines LOWPAN_NHC, an encoding format for arbitrary next headers. LOWPAN_IPHC indicates whether the following header is encoded using LOWPAN_NHC. If so, the bits immediately following the compressed IPv6 header start the LOWPAN_NHC encoding. In contrast, LOWPAN_HC1 could be extended to support compression of next headers using LOWPAN_HC2, but only for UDP, TCP, and ICMPv6. Furthermore, the LOWPAN_HC2 octet sits between the LOWPAN_HC1 octet and uncompressed IPv6 header fields. This specification moves the next header encoding bits to follow all IPv6-related bits, allowing for a properly layered structure and direct support for IPv6 extension headers.
本文档还定义了LOWPAN_NHC，一种用于任意next头的编码格式。LOWPAN_IPHC指示是否使用LOWPAN_NHC对以下标头进行编码。如果是这样，紧跟在压缩IPv6报头之后的位将开始LOWPAN_NHC编码。相比之下，可以使用LOWPAN_HC2扩展LOWPAN_HC1以支持下一个报头的压缩，但仅适用于UDP、TCP和ICMPv6。此外，LOWPAN_HC2八位组位于LOWPAN_HC1八位组和未压缩IPv6报头字段之间。此规范将下一个报头编码位移动到所有IPv6相关位之后，从而允许适当的分层结构和对IPv6扩展报头的直接支持。
Using LOWPAN_NHC, this document defines a compression mechanism for UDP. While [RFC4944] defines a compression mechanism for UDP, that mechanism does not enable checksum compression when rendered possible by additional upper-layer mechanisms such as upper-layer Message Integrity Check (MIC). This specification adds the capability to elide the UDP checksum over the 6LoWPAN, which enables saving of a further two octets.
本文档使用LOWPAN_NHC定义了UDP的压缩机制。虽然[RFC4944]为UDP定义了一种压缩机制，但当附加的上层机制（如上层消息完整性检查（MIC））使校验和压缩成为可能时，该机制不会启用校验和压缩。该规范增加了通过6LoWPAN消除UDP校验和的功能，从而可以保存另外两个八位字节。
Also, using LOWPAN_NHC, this document defines encoding formats for IPv6-in-IPv6 encapsulation as well as IPv6 Extension Headers. With LOWPAN_HC1 and LOWPAN_HC2, chains of next headers cannot be encoded efficiently.
此外，本文档还使用LOWPAN_NHC定义了IPv6-in-IPv6封装的编码格式以及IPv6扩展头。使用LOWPAN_HC1和LOWPAN_HC2，无法对下一个报头的链进行有效编码。
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
This document specifies a header compression format that is intended to replace that defined in Section 10 of [RFC4944]. Implementation of Section 10 of [RFC4944] is now NOT RECOMMENDED. New implementations MAY implement decompression according to Section 10 of [RFC4944] but SHOULD NOT send packets compressed according to Section 10 of [RFC4944].
本文件规定了标题压缩格式，旨在取代[RFC4944]第10节中定义的格式。现在不建议实施[RFC4944]第10节。新实现可以根据[RFC4944]第10节实现解压缩，但不应发送根据[RFC4944]第10节压缩的数据包。
A compliant implementation of [RFC4944] as updated by this document MUST be able to properly process a packet received that makes use of the provisions of this document. A compliant implementation MAY implement additional LOWPAN_NHC types (Section 4) that may be
本文件更新的[RFC4944]合规实施必须能够正确处理使用本文件规定接收的数据包。合规实施可实施额外的LOWPAN_NHC类型（第4节），可能：
registered (Section 5) in the future. It is out of scope of this document how a compressor learns that a decompressor has additional capabilities.
将来注册（第5节）。压缩器如何得知解压器具有附加功能超出了本文档的范围。
Section 5.3 of [RFC4944] also defines how to fragment compressed IPv6 datagrams that do not fit within a single link frame. Section 5.3 of [RFC4944] defines the fragment header's datagram_size and datagram_offset values as the size and offset of the IPv6 datagram before compression. As a result, all fragment payload outside the first fragment must carry their respective portions of the IPv6 datagram before compression. This document does not change that requirement. When using the fragmentation mechanism described in Section 5.3 of [RFC4944], any header that cannot fit within the first fragment MUST NOT be compressed.
[RFC4944]第5.3节还定义了如何对不适合单个链路帧的压缩IPv6数据报进行分段。[RFC4944]第5.3节将片段头的数据报大小和数据报偏移量值定义为压缩前IPv6数据报的大小和偏移量。因此，在压缩之前，第一个片段之外的所有片段负载都必须携带各自的IPv6数据报部分。本文件不会改变该要求。当使用[RFC4944]第5.3节中所述的分段机制时，不得压缩无法放入第一个分段的任何标头。
The header compression format defined in this document preempts the ESC dispatch value defined in Section 5.1 of [RFC4944]. Instead, the value of 01 000000 is reserved as a replacement value for ESC, to be finally assigned with the first assignment of extension bytes.
本文件中定义的标题压缩格式优先于[RFC4944]第5.1节中定义的ESC调度值。相反，01 000000的值保留为ESC的替换值，最终将与扩展字节的第一次分配一起分配。
In this section, we define the LOWPAN_IPHC encoding format for compressing the IPv6 header. To enable effective compression, LOWPAN_IPHC relies on information pertaining to the entire 6LoWPAN. LOWPAN_IPHC assumes the following will be the common case for 6LoWPAN communication: Version is 6; Traffic Class and Flow Label are both zero; Payload Length can be inferred from lower layers from either the 6LoWPAN Fragmentation header or the IEEE 802.15.4 header; Hop Limit will be set to a well-known value by the source; addresses assigned to 6LoWPAN interfaces will be formed using the link-local prefix or a small set of routable prefixes assigned to the entire 6LoWPAN; addresses assigned to 6LoWPAN interfaces are formed with an IID derived directly from either the 64-bit extended or the 16-bit short IEEE 802.15.4 addresses.
在本节中，我们定义了用于压缩IPv6头的LOWPAN_IPHC编码格式。为了实现有效压缩，LOWPAN_IPHC依赖于与整个6LoWPAN相关的信息。LOWPAN_IPHC假设以下情况为6LoWPAN通信的常见情况：版本为6；交通等级和流量标签均为零；有效负载长度可以从6LoWPAN分段报头或IEEE 802.15.4报头的较低层推断；跃点限制将由源设置为已知值；分配给6LoWPAN接口的地址将使用链路本地前缀或分配给整个6LoWPAN的一小组可路由前缀形成；分配给6LoWPAN接口的地址由直接从64位扩展或16位短IEEE 802.15.4地址派生的IID构成。
+-------------------------------------+----------------------------
| Dispatch + LOWPAN_IPHC (2-3 octets) | In-line IPv6 Header Fields
+-------------------------------------+----------------------------
+-------------------------------------+----------------------------
| Dispatch + LOWPAN_IPHC (2-3 octets) | In-line IPv6 Header Fields
+-------------------------------------+----------------------------
Figure 1: LOWPAN_IPHC Header
图1:LOWPAN_IPHC头
The LOWPAN_IPHC encoding utilizes 13 bits, 5 of which are taken from the rightmost bits of the dispatch type. The encoding may be extended by another octet to support additional contexts. Any information from the uncompressed IPv6 header fields carried in-line
LOWPAN_IPHC编码使用13位，其中5位取自分派类型的最右边位。编码可以由另一个八位组扩展以支持额外的上下文。联机携带的未压缩IPv6标头字段中的任何信息
follow the LOWPAN_IPHC encoding, as shown in Figure 1. In the best case, the LOWPAN_IPHC can compress the IPv6 header down to two octets (the dispatch octet and the LOWPAN_IPHC encoding) with link-local communication.
遵循LOWPAN_IPHC编码，如图1所示。在最佳情况下，LOWPAN_IPHC可以通过链路本地通信将IPv6报头压缩为两个八位字节（调度八位字节和LOWPAN_IPHC编码）。
When routing over multiple IP hops, LOWPAN_IPHC can compress the IPv6 header down to 7 octets (1-octet dispatch, 1-octet LOWPAN_IPHC, 1-octet Hop Limit, 2-octet Source Address, and 2-octet Destination Address). The Hop Limit may not be compressed because it needs to decremented at each hop and may take any value. Stateful address compression must be applied to the source and destination IPv6 addresses because they do not statelessly match the source and destination link-layer addresses on intermediate hops.
当通过多个IP跃点进行路由时，LOWPAN_IPHC可以将IPv6报头压缩到7个八位字节（1个八位字节分派、1个八位字节LOWPAN_IPHC、1个八位字节跃点限制、2个八位字节源地址和2个八位字节目标地址）。跃点限制可能不会被压缩，因为它需要在每个跃点处递减，并且可以取任何值。有状态地址压缩必须应用于源和目标IPv6地址，因为它们不会无状态地匹配中间跃点上的源和目标链路层地址。
This section specifies the format of the LOWPAN_IPHC encoding that describes how an IPv6 header is compressed. The encoding can be 2 octets long for the base encoding or 3 octets long when an additional context encoding is present. The IPv6 header fields that are not fully elided are placed immediately after the LOWPAN_IPHC, either in a compressed form if the field is partially elided or literally.
本节指定描述如何压缩IPv6标头的LOWPAN_IPHC编码格式。对于基本编码，编码长度可以是2个八位字节，如果存在其他上下文编码，则编码长度可以是3个八位字节。未完全省略的IPv6报头字段立即放在LOWPAN_IPHC之后，如果字段部分省略，则以压缩形式或字面形式。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 0 | 1 | 1 | TF |NH | HLIM |CID|SAC| SAM | M |DAC| DAM |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 0 | 1 | 1 | TF |NH | HLIM |CID|SAC| SAM | M |DAC| DAM |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 2: LOWPAN_IPHC base Encoding
图2:LOWPAN_IPHC基本编码
TF: Traffic Class, Flow Label: As specified in [RFC3168], the 8-bit IPv6 Traffic Class field is split into two fields: 2-bit Explicit Congestion Notification (ECN) and 6-bit Differentiated Services Code Point (DSCP).
TF：流量类别，流标签：如[RFC3168]中所述，8位IPv6流量类别字段分为两个字段：2位显式拥塞通知（ECN）和6位区分服务代码点（DSCP）。
00: ECN + DSCP + 4-bit Pad + Flow Label (4 bytes)
00: ECN + DSCP + 4-bit Pad + Flow Label (4 bytes)
01: ECN + 2-bit Pad + Flow Label (3 bytes), DSCP is elided.
01:ECN+2位Pad+流量标签（3字节），省略DSCP。
10: ECN + DSCP (1 byte), Flow Label is elided.
10:ECN+DSCP（1字节），省略流标签。
11: Traffic Class and Flow Label are elided.
11：省略交通等级和流量标签。
NH: Next Header:
NH：下一个标题：
0: Full 8 bits for Next Header are carried in-line.
0：下一个标头的完整8位以行方式进行。
1: The Next Header field is compressed and the next header is encoded using LOWPAN_NHC, which is discussed in Section 4.1.
1：压缩下一个报头字段，并使用LOWPAN_NHC对下一个报头进行编码，这将在第4.1节中讨论。
HLIM: Hop Limit:
HLIM:跃点限制：
00: The Hop Limit field is carried in-line.
00：跃点限制字段以直线方式携带。
01: The Hop Limit field is compressed and the hop limit is 1.
01：跃点限制字段被压缩，跃点限制为1。
10: The Hop Limit field is compressed and the hop limit is 64.
10：跃点限制字段被压缩，跃点限制为64。
11: The Hop Limit field is compressed and the hop limit is 255.
11：跃点限制字段被压缩，跃点限制为255。
CID: Context Identifier Extension:
CID:上下文标识符扩展：
0: No additional 8-bit Context Identifier Extension is used. If context-based compression is specified in either Source Address Compression (SAC) or Destination Address Compression (DAC), context 0 is used.
0:未使用其他8位上下文标识符扩展。如果在源地址压缩（SAC）或目标地址压缩（DAC）中指定了基于上下文的压缩，则使用上下文0。
1: An additional 8-bit Context Identifier Extension field immediately follows the Destination Address Mode (DAM) field.
1：目标地址模式（DAM）字段后面紧跟着另一个8位上下文标识符扩展字段。
SAC: Source Address Compression
源地址压缩
0: Source address compression uses stateless compression.
0:源地址压缩使用无状态压缩。
1: Source address compression uses stateful, context-based compression.
1：源地址压缩使用有状态、基于上下文的压缩。
SAM: Source Address Mode:
SAM：源地址模式：
If SAC=0:
如果SAC=0：
00: 128 bits. The full address is carried in-line.
00:128位。完整的地址以行的形式进行传输。
01: 64 bits. The first 64-bits of the address are elided. The value of those bits is the link-local prefix padded with zeros. The remaining 64 bits are carried in-line.
01:64位。地址的前64位被省略。这些位的值是用零填充的链路本地前缀。其余的64位以行方式进行传输。
10: 16 bits. The first 112 bits of the address are elided. The value of the first 64 bits is the link-local prefix padded with zeros. The following 64 bits are 0000:00ff: fe00:XXXX, where XXXX are the 16 bits carried in-line.
10:16位。地址的前112位被省略。前64位的值是用零填充的链路本地前缀。以下64位为0000:00ff:fe00:XXXX，其中XXXX为16位的在线传输。
11: 0 bits. The address is fully elided. The first 64 bits of the address are the link-local prefix padded with zeros. The remaining 64 bits are computed from the encapsulating header (e.g., 802.15.4 or IPv6 source address) as specified in Section 3.2.2.
11:0位。地址完全省略了。地址的前64位是用零填充的链路本地前缀。其余64位根据第3.2.2节规定的封装头（例如802.15.4或IPv6源地址）计算。
If SAC=1:
如果SAC=1：
00: The UNSPECIFIED address, ::
00:未指定的地址，：：
01: 64 bits. The address is derived using context information and the 64 bits carried in-line. Bits covered by context information are always used. Any IID bits not covered by context information are taken directly from the corresponding bits carried in-line. Any remaining bits are zero.
01:64位。地址是使用上下文信息和行中携带的64位派生的。始终使用上下文信息覆盖的位。上下文信息中未包含的任何IID位都直接取自在线携带的相应位。任何剩余的位都是零。
10: 16 bits. The address is derived using context information and the 16 bits carried in-line. Bits covered by context information are always used. Any IID bits not covered by context information are taken directly from their corresponding bits in the 16-bit to IID mapping given by 0000:00ff:fe00:XXXX, where XXXX are the 16 bits carried in-line. Any remaining bits are zero.
10:16位。该地址是使用上下文信息和在线携带的16位导出的。始终使用上下文信息覆盖的位。上下文信息未涵盖的任何IID位都直接从0000:00ff:fe00:XXXX给出的16位到IID映射中的相应位获取，其中XXXX是在线携带的16位。任何剩余的位都是零。
11: 0 bits. The address is fully elided and is derived using context information and the encapsulating header (e.g., 802.15.4 or IPv6 source address). Bits covered by context information are always used. Any IID bits not covered by context information are computed from the encapsulating header as specified in Section 3.2.2. Any remaining bits are zero.
11:0位。地址完全省略，并使用上下文信息和封装头（例如802.15.4或IPv6源地址）导出。始终使用上下文信息覆盖的位。根据第3.2.2节的规定，上下文信息未涵盖的任何IID位都是从封装头计算出来的。任何剩余的位都是零。
M: Multicast Compression
M：多播压缩
0: Destination address is not a multicast address.
0:目标地址不是多播地址。
1: Destination address is a multicast address.
1：目标地址是多播地址。
DAC: Destination Address Compression
目的地址压缩
0: Destination address compression uses stateless compression.
0:目标地址压缩使用无状态压缩。
1: Destination address compression uses stateful, context-based compression.
1：目标地址压缩使用有状态、基于上下文的压缩。
DAM: Destination Address Mode:
DAM：目标地址模式：
If M=0 and DAC=0 This case matches SAC=0 but for the destination address:
如果M=0且DAC=0，则此情况与SAC=0匹配，但对于目标地址：
00: 128 bits. The full address is carried in-line.
00:128位。完整的地址以行的形式进行传输。
01: 64 bits. The first 64-bits of the address are elided. The value of those bits is the link-local prefix padded with zeros. The remaining 64 bits are carried in-line.
01:64位。地址的前64位被省略。这些位的值是用零填充的链路本地前缀。其余的64位以行方式进行传输。
10: 16 bits. The first 112 bits of the address are elided. The value of the first 64 bits is the link-local prefix padded with zeros. The following 64 bits are 0000:00ff: fe00:XXXX, where XXXX are the 16 bits carried in-line.
10:16位。地址的前112位被省略。前64位的值是用零填充的链路本地前缀。以下64位为0000:00ff:fe00:XXXX，其中XXXX为16位的在线传输。
11: 0 bits. The address is fully elided. The first 64 bits of the address are the link-local prefix padded with zeros. The remaining 64 bits are computed from the encapsulating header (e.g., 802.15.4 or IPv6 destination address) as specified in Section 3.2.2.
11:0位。地址完全省略了。地址的前64位是用零填充的链路本地前缀。其余64位根据第3.2.2节中规定的封装头（例如802.15.4或IPv6目标地址）计算。
If M=0 and DAC=1:
如果M=0且DAC=1：
00: Reserved.
00：预订。
01: 64 bits. The address is derived using context information and the 64 bits carried in-line. Bits covered by context information are always used. Any IID bits not covered by context information are taken directly from the corresponding bits carried in-line. Any remaining bits are zero.
01:64位。地址是使用上下文信息和行中携带的64位派生的。始终使用上下文信息覆盖的位。上下文信息中未包含的任何IID位都直接取自在线携带的相应位。任何剩余的位都是零。
10: 16 bits. The address is derived using context information and the 16 bits carried in-line. Bits covered by context information are always used. Any IID bits not covered by context information are taken directly from their corresponding bits in the 16-bit to IID mapping given by 0000:00ff:fe00:XXXX, where XXXX are the 16 bits carried in-line. Any remaining bits are zero.
10:16位。该地址是使用上下文信息和在线携带的16位导出的。始终使用上下文信息覆盖的位。上下文信息未涵盖的任何IID位都直接从0000:00ff:fe00:XXXX给出的16位到IID映射中的相应位获取，其中XXXX是在线携带的16位。任何剩余的位都是零。
11: 0 bits. The address is fully elided and is derived using context information and the encapsulating header (e.g. 802.15.4 or IPv6 destination address). Bits covered by context information are always used. Any IID bits not covered by context information are computed from the encapsulating header as specified in Section 3.2.2. Any remaining bits are zero.
11:0位。地址完全省略，并使用上下文信息和封装头（例如802.15.4或IPv6目标地址）导出。始终使用上下文信息覆盖的位。根据第3.2.2节的规定，上下文信息未涵盖的任何IID位都是从封装头计算出来的。任何剩余的位都是零。
If M=1 and DAC=0:
如果M=1且DAC=0：
00: 128 bits. The full address is carried in-line.
00:128位。完整的地址以行的形式进行传输。
01: 48 bits. The address takes the form ffXX::00XX:XXXX:XXXX.
01:48位。地址的格式为ffXX:：00XX:XXXX:XXXX。
10: 32 bits. The address takes the form ffXX::00XX:XXXX.
10:32位。地址的格式为ffXX:：00XX:XXXX。
11: 8 bits. The address takes the form ff02::00XX.
11:8位。地址的格式为ff02:：00XX。
If M=1 and DAC=1:
如果M=1且DAC=1：
00: 48 bits. This format is designed to match Unicast-Prefix-based IPv6 Multicast Addresses as defined in [RFC3306] and [RFC3956]. The multicast address takes the form ffXX:XXLL: PPPP:PPPP:PPPP:PPPP:XXXX:XXXX. where the X are the nibbles that are carried in-line, in the order in which they appear in this format. P denotes nibbles used to encode the prefix itself. L denotes nibbles used to encode the prefix length. The prefix information P and L is taken from the specified context.
00:48位。此格式旨在匹配[RFC3306]和[RFC3956]中定义的基于单播前缀的IPv6多播地址。多播地址的格式为ffXX:XXLL:PPPP:PPPP:PPPP:PPPP:XXXX:XXXX。其中，X是以该格式显示的顺序排列的半字节。P表示用于编码前缀本身的半字节。L表示用于编码前缀长度的半字节。前缀信息P和L取自指定的上下文。
01: reserved
01：保留
10: reserved
10：保留
11: reserved
11：保留
This specification expects that a conceptual context is shared between the node that compresses a packet and the node(s) that needs to expand it. How the contexts are shared and maintained is out of scope. What information is contained within a context information is out of scope. Actions in response to unknown and/or invalid contexts are out of scope. The specification enables a node to use up to 16 contexts. The context used to encode the source address does not have to be the same as the context used to encode the destination address.
此规范要求压缩数据包的节点和需要扩展数据包的节点之间共享概念上下文。如何共享和维护上下文超出了范围。上下文信息中包含的信息超出范围。响应未知和/或无效上下文的操作超出范围。该规范允许节点最多使用16个上下文。用于编码源地址的上下文不必与用于编码目标地址的上下文相同。
If the CID field is set to '1' in the LOWPAN_IPHC encoding, then an additional octet extends the LOWPAN_IPHC encoding following the DAM bits but before the IPv6 header fields that are carried in-line. The additional octet identifies the pair of contexts to be used when the IPv6 source and/or destination address is compressed. The context identifier is 4 bits for each address, supporting up to 16 contexts. Context 0 is the default context. The encoding is shown in Figure 3.
如果在LOWPAN_IPHC编码中将CID字段设置为“1”，则在DAM位之后但在IPv6头字段之前增加一个八位组来扩展LOWPAN_IPHC编码。附加的八位字节标识了压缩IPv6源地址和/或目标地址时要使用的上下文对。每个地址的上下文标识符为4位，最多支持16个上下文。上下文0是默认上下文。编码如图3所示。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| SCI | DCI |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| SCI | DCI |
+---+---+---+---+---+---+---+---+
Figure 3: LOWPAN_IPHC Encoding
图3:LOWPAN_IPHC编码
SCI: Source Context Identifier. Identifies the prefix that is used when the IPv6 source address is statefully compressed.
SCI：源上下文标识符。标识IPv6源地址被状态压缩时使用的前缀。
DCI: Destination Context Identifier. Identifies the prefix that is used when the IPv6 destination address is statefully compressed.
DCI：目标上下文标识符。标识IPv6目标地址被状态压缩时使用的前缀。
Fields carried in-line (in part or in whole) appear in the same order as they do in the IPv6 header format [RFC2460]. The Version field is always elided. Unicast IPv6 addresses may be compressed to 64 or 16 bits or completely elided. Multicast IPv6 addresses may be compressed to 8, 32, or 48 bits. The IPv6 Payload Length field MUST always be elided and inferred from lower layers using the 6LoWPAN Fragmentation header or the IEEE 802.15.4 header.
在线携带的字段（部分或全部）的显示顺序与IPv6报头格式[RFC2460]中的相同。版本字段始终被省略。单播IPv6地址可以压缩到64位或16位或完全省略。多播IPv6地址可以压缩为8、32或48位。IPv6有效负载长度字段必须始终使用6LoWPAN分段标头或IEEE 802.15.4标头从较低层删除和推断。
The Traffic Class field in the IPv6 header comprises 6 bits of Diffserv extension [RFC2474] and 2 bits of Explicit Congestion Notification (ECN) [RFC3168]. The TF field in the LOWPAN_IPHC encoding indicates whether the Traffic Class and Flow Label are carried in-line in the compressed IPv6 header. When Flow Label is included while the Traffic Class is compressed, an additional 4 bits are included to maintain byte alignment. Two of the 4 bits contain the ECN bits from the Traffic Class field.
IPv6报头中的流量类别字段包括6位Diffserv扩展[RFC2474]和2位显式拥塞通知（ECN）[RFC3168]。LOWPAN_IPHC编码中的TF字段指示在压缩的IPv6报头中是否在线携带流量类别和流量标签。当在压缩流量类的同时包含流标签时，将包含额外的4位以保持字节对齐。4位中的两位包含来自Traffic Class字段的ECN位。
To ensure that the ECN bits appear in the same location for all encodings that include them, the Traffic Class field is rotated right by 2 bits in the compressed IPv6 header. The encodings are shown below:
为了确保ECN位对于包含它们的所有编码显示在相同的位置，在压缩的IPv6报头中将Traffic Class字段向右旋转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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ECN| DSCP | rsv | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ECN| DSCP | rsv | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: TF = 00: Traffic Class and Flow Label carried in-line
Figure 4: TF = 00: Traffic Class and Flow Label carried in-line
1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ECN|rsv| Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ECN|rsv| Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: TF = 01: Flow Label carried in-line
Figure 5: TF = 01: Flow Label carried in-line
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|ECN| DSCP |
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|ECN| DSCP |
+-+-+-+-+-+-+-+-+
Figure 6: TF = 10: Traffic Class carried in-line
Figure 6: TF = 10: Traffic Class carried in-line
LOWPAN_IPHC elides the IIDs of source or destination addresses when SAM = 3 or DAM = 3, respectively. In this mode, the IID is derived from the encapsulating header. When the encapsulating header carries IPv6 addresses, bits for the source and destination addresses are copied from the source and destination addresses of the encapsulating IPv6 header.
当SAM=3或DAM=3时，LOWPAN_IPHC分别省略源地址或目标地址的IID。在此模式下，IID从封装头派生。当封装标头携带IPv6地址时，源地址和目标地址的位将从封装IPv6标头的源地址和目标地址复制。
The remainder of this section defines the mapping from IEEE 802.15.4 [IEEE802.15.4] link-layer addresses to IIDs for both short and extended IEEE 802.15.4 addresses. IID bits not covered by the context information MAY be elided if they match the link-layer address mapping and MUST NOT be elided if they do not.
本节的其余部分定义了从IEEE 802.15.4[IEEE802.15.4]链路层地址到IID的映射，适用于短地址和扩展IEEE 802.15.4地址。如果上下文信息未涵盖的IID位与链路层地址映射匹配，则可以省略这些位，如果它们不匹配，则不得省略这些位。
An extended IEEE 802.15.4 address takes the form of an IEEE EUI-64 address. Generating an IID from an extended address is identical to that defined in Appendix A of [RFC4291]. The only change needed to transform an IEEE EUI-64 identifier to an interface identifier is to invert the universal/local bit.
扩展的IEEE 802.15.4地址采用IEEE EUI-64地址的形式。从扩展地址生成IID与[RFC4291]附录A中定义的相同。将IEEE EUI-64标识符转换为接口标识符所需的唯一更改是反转通用/本地位。
A short IEEE 802.15.4 address is 16 bits in length. Short addresses are mapped into the restricted space of IEEE EUI-64 addresses by setting the middle 16 bits to 0xfffe, the bottom 16 bits to the short address, and all other bits to zero. As a result, an IID generated from a short address has the form:
短IEEE 802.15.4地址的长度为16位。通过将中间16位设置为0xfffe，将底部16位设置为短地址，将所有其他位设置为零，将短地址映射到IEEE EUI-64地址的受限空间。因此，由短地址生成的IID具有以下形式：
0000:00ff:fe00:XXXX
0000:00ff:fe00:XXXX
where XXXX carries the short address. The universal/local bit is zero to indicate local scope.
其中XXXX包含短地址。通用/本地位为零表示本地范围。
This mapping for non-EUI-64 identifiers differs from that presented in Appendix A of [RFC4291]. Using the restricted space ensures no overlap with IIDs generated from unrestricted IEEE EUI-64 addresses. Also, including 0xfffe in the middle of the IID helps avoid overlap with other locally managed IIDs.
非EUI-64标识符的映射不同于[RFC4291]附录A中给出的映射。使用受限空间可确保不与由不受限IEEE EUI-64地址生成的IID重叠。此外，在IID的中间包括0xFFFE有助于避免与其他本地管理的IID重叠。
This mapping from a short IEEE 802.15.4 address to 64-bit IIDs is also used to reconstruct any part of an IID not covered by context information.
从短IEEE 802.15.4地址到64位IID的映射也用于重建上下文信息未涵盖的IID的任何部分。
LOWPAN_IPHC supports stateless compression of multicast addresses when M = 1 and DAC = 0. An IPv6 multicast address may be compressed down to 48, 32, or 8 bits using stateless compression. The format supports compression of the Solicited-Node Multicast Address (ff02:: 1:ffXX:XXXX) as well as any IPv6 multicast address where the upper bits of the multicast group identifier are zero. The 8-bit compressed form only carries the least-significant bits of the multicast group identifier. The 48- and 32-bit compressed forms carry the multicast scope and flags in-line, in addition to the least-significant bits of the multicast group identifier.
LOWPAN_IPHC支持在M=1和DAC=0时对多播地址进行无状态压缩。可以使用无状态压缩将IPv6多播地址压缩到48、32或8位。该格式支持压缩请求的节点多播地址（ff02:：1:ffXX:XXXX）以及多播组标识符的高位为零的任何IPv6多播地址。8位压缩格式仅携带多播组标识符的最低有效位。除了多播组标识符的最低有效位外，48位和32位压缩表单还在线携带多播作用域和标志。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Scope | Group Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Scope | Group Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: DAM = 01. 48-bit Compressed Multicast Address
(ffFS::00GG:GGGG:GGGG)
Figure 7: DAM = 01. 48-bit Compressed Multicast Address
(ffFS::00GG:GGGG:GGGG)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Scope | Group Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Scope | Group Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: DAM = 10. 32-bit Compressed Multicast Address
(ffFS::00GG:GGGG)
Figure 8: DAM = 10. 32-bit Compressed Multicast Address
(ffFS::00GG:GGGG)
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Group ID |
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Group ID |
+-+-+-+-+-+-+-+-+
Figure 9: DAM = 11. 8-bit Compressed Multicast Address (ff02::GG)
Figure 9: DAM = 11. 8-bit Compressed Multicast Address (ff02::GG)
LOWPAN_IPHC supports stateful compression of multicast addresses when M = 1 and DAC = 1. This document currently defines DAM = 00: context-based compression of Unicast-Prefix-based IPv6 Multicast Addresses [RFC3306][RFC3956]. In particular, the Prefix Length and Network Prefix can be taken from a context. As a result, LOWPAN_IPHC can compress a Unicast-Prefix-based IPv6 Multicast Address down to 6 octets by only carrying the 4-bit Flags, 4-bit Scope, 8-bit Rendezvous Point Interface ID (RIID), and 32-bit Group Identifier in-line.
LOWPAN_IPHC支持在M=1和DAC=1时对多播地址进行有状态压缩。本文档当前定义DAM=00：基于单播前缀的IPv6多播地址的基于上下文的压缩[RFC3306][RFC3956]。特别地，前缀长度和网络前缀可以从上下文中获取。因此，LOWPAN_IPHC可以通过在线携带4位标志、4位作用域、8位集合点接口ID（RIID）和32位组标识符，将基于单播前缀的IPv6多播地址压缩到6个八位字节。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Scope | Rsvd / RIID | Group Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Scope | Rsvd / RIID | Group Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: DAM = 00. Unicast-Prefix-based IPv6 Multicast Address Compression
图10：大坝=00。基于单播前缀的IPv6多播地址压缩
Note that the Reserved field MUST carry the reserved bits from the multicast address format as described in [RFC3306]. When a Rendezvous Point is encoded in the multicast address as described in [RFC3956], the Reserved field carries the RIID bits in-line.
注意，保留字段必须携带[RFC3306]中所述的多播地址格式的保留位。如[RFC3956]所述，在多播地址中对集合点进行编码时，保留字段在线携带RIID位。
LOWPAN_IPHC elides the IPv6 Next Header field when the NH bit is set to 1. This also indicates the use of 6LoWPAN next header compression, LOWPAN_NHC. The value of IPv6 Next Header is recovered from the first bits in the LOWPAN_NHC encoding. The following bits are specific to the IPv6 Next Header value. Figure 11 shows the structure of an IPv6 datagram compressed using LOWPAN_IPHC and LOWPAN_NHC.
当NH位设置为1时，LOWPAN_IPHC省略IPv6下一个报头字段。这也表明使用了6LoWPAN next割台压缩、LOWPAN_NHC。IPv6下一个报头的值从LOWPAN_NHC编码中的第一位恢复。以下位特定于IPv6下一个标头值。图11显示了使用LOWPAN_IPHC和LOWPAN_NHC压缩的IPv6数据报的结构。
+-------------+-------------+-------------+-----------------+--------
| LOWPAN_IPHC | In-line | LOWPAN_NHC | In-line Next | Payload
| Encoding | IP Fields | Encoding | Header Fields |
+-------------+-------------+-------------+-----------------+--------
+-------------+-------------+-------------+-----------------+--------
| LOWPAN_IPHC | In-line | LOWPAN_NHC | In-line Next | Payload
| Encoding | IP Fields | Encoding | Header Fields |
+-------------+-------------+-------------+-----------------+--------
Figure 11: Typical LOWPAN_IPHC/LOWPAN_NHC Header Configuration
图11：典型的LOWPAN_IPHC/LOWPAN_NHC标头配置
Compression formats for different next headers are identified by a variable-length bit-pattern immediately following the LOWPAN_IPHC compressed header. When defining a next header compression format, the number of bits used SHOULD be determined by the perceived frequency of using that format. However, the number of bits and any remaining encoding bits SHOULD respect octet alignment. The following bits are specific to the next header compression format. This document defines a compression format for IPv6 Extension and UDP headers.
不同next头的压缩格式由紧跟在LOWPAN_IPHC压缩头之后的可变长度位模式标识。定义下一个报头压缩格式时，使用的位数应根据使用该格式的感知频率确定。然而，位的数量和任何剩余的编码位都应该遵循八位字节对齐。以下位特定于下一个标头压缩格式。本文档定义了IPv6扩展和UDP头的压缩格式。
+----------------+---------------------------
| var-len NHC ID | compressed next header...
+----------------+---------------------------
+----------------+---------------------------
| var-len NHC ID | compressed next header...
+----------------+---------------------------
Figure 12: LOWPAN_NHC Encoding
图12:LOWPAN_NHC编码
A necessary property of encoding headers using LOWPAN_NHC is that the immediately preceding header must be encoded using either LOWPAN_IPHC or LOWPAN_NHC. In other words, all headers encoded using the 6LoWPAN encoding format defined in this document must be contiguous. As a result, this document defines a set of LOWPAN_NHC encodings for selected IPv6 Extension Headers such that the UDP Header Compression defined in Section 4.3 may be used in the presence of those extension headers.
使用LOWPAN_NHC编码头的一个必要特性是，前面的头必须使用LOWPAN_IPHC或LOWPAN_NHC编码。换句话说，使用本文档中定义的6LoWPAN编码格式编码的所有标题必须是连续的。因此，本文档为选定的IPv6扩展头定义了一组LOWPAN_NHC编码，以便在存在这些扩展头时可以使用第4.3节中定义的UDP头压缩。
The LOWPAN_NHC encodings for IPv6 Extension Headers are composed of a single LOWPAN_NHC octet followed by the IPv6 Extension Header. The format of the LOWPAN_NHC octet is shown in Figure 13. The first 7 bits serve as an identifier for the IPv6 Extension Header immediately following the LOWPAN_NHC octet. The remaining bit indicates whether or not the following header utilizes LOWPAN_NHC encoding.
IPv6扩展头的LOWPAN_NHC编码由单个LOWPAN_NHC八位组和IPv6扩展头组成。LOWPAN_NHC八位字节的格式如图13所示。前7位用作紧跟在LOWPAN_NHC八位字节之后的IPv6扩展头的标识符。剩余位指示以下标头是否使用LOWPAN_NHC编码。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 | 1 | 1 | 0 | EID |NH |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 | 1 | 1 | 0 | EID |NH |
+---+---+---+---+---+---+---+---+
Figure 13: IPv6 Extension Header Encoding
图13:IPv6扩展头编码
EID: IPv6 Extension Header ID:
EID:IPv6扩展标头ID:
0: IPv6 Hop-by-Hop Options Header [RFC2460]
0:IPv6逐跳选项标头[RFC2460]
1: IPv6 Routing Header [RFC2460]
1:IPv6路由头[RFC2460]
2: IPv6 Fragment Header [RFC2460]
2:IPv6片段头[RFC2460]
3: IPv6 Destination Options Header [RFC2460]
3:IPv6目标选项标头[RFC2460]
4: IPv6 Mobility Header [RFC6275]
4:IPv6移动头[RFC6275]
5: Reserved
5：保留
6: Reserved
6：保留
7: IPv6 Header
7:IPv6标头
NH: Next Header:
NH：下一个标题：
0: Full 8 bits for Next Header are carried in-line.
0：下一个标头的完整8位以行方式进行。
1: The Next Header field is elided and the next header is encoded using LOWPAN_NHC, which is discussed in Section 4.1.
1：删除下一个报头字段，并使用LOWPAN_NHC对下一个报头进行编码，这将在第4.1节中讨论。
For the most part, the IPv6 Extension Header is carried unmodified in the bytes immediately following the LOWPAN_NHC octet, with two important exceptions: Length field and Next Header field.
在大多数情况下，IPv6扩展头在紧跟LOWPAN_NHC八位字节之后的字节中未经修改地传输，但有两个重要的例外：长度字段和下一个头字段。
The Next Header field contained in IPv6 Extension Headers is elided when the NH bit is set in the LOWPAN_NHC encoding octet. Note that doing so allows LOWPAN_NHC to utilize no more overhead than the non-encoded IPv6 Extension Header.
当在LOWPAN_NHC编码八位字节中设置NH位时，IPv6扩展头中包含的下一个头字段将被省略。注意，这样做允许LOWPAN_NHC利用的开销不超过非编码IPv6扩展头。
The Length field contained in a compressed IPv6 Extension Header indicates the number of octets that pertain to the (compressed) extension header following the Length field. Note that this changes the Length field definition in [RFC2460] from indicating the header size in 8-octet units, not including the first 8 octets. Changing the Length field to be in units of octets removes wasteful internal fragmentation.
压缩IPv6扩展标头中包含的长度字段表示与长度字段后面的（压缩）扩展标头相关的八位字节数。请注意，这改变了[RFC2460]中的长度字段定义，不再以8个八位字节为单位指示标头大小，不包括前8个八位字节。将长度字段更改为八位字节的单位可以消除浪费的内部碎片。
IPv6 Hop-by-Hop and Destination Options Headers may use a trailing Pad1 or PadN to achieve 8-octet alignment. When there is a single trailing Pad1 or PadN option of 7 octets or less and the containing header is a multiple of 8 octets, the trailing Pad1 or PadN option MAY be elided by the compressor. A decompressor MUST ensure that the containing header is padded out to a multiple of 8 octets in length, using a Pad1 or PadN option if necessary. Note that Pad1 and PadN options that appear in locations other than the end MUST be carried in-line as they are used to align subsequent options.
IPv6逐跳和目标选项标头可以使用尾随Pad1或PadN来实现8位字节对齐。当单个尾随Pad1或PadN选项为7个八位字节或更少，且包含的标头为8个八位字节的倍数时，压缩器可省略尾随Pad1或PadN选项。解压器必须确保将包含的头填充到8个八位字节的倍数，必要时使用Pad1或PadN选项。请注意，出现在端部以外位置的Pad1和PadN选项必须对齐，因为它们用于对齐后续选项。
Note that specifying units in octets means that LOWPAN_NHC MUST NOT be used to encode IPv6 Extension Headers that have more than 255 octets following the Length field after compression.
请注意，以八位字节指定单位意味着LOWPAN_NHC不得用于编码压缩后长度字段后面超过255个八位字节的IPv6扩展头。
When the identified next header is an IPv6 Header (EID=7), the NH bit of the LOWPAN_NHC encoding is unused and MUST be set to zero. The following bytes MUST be encoded using LOWPAN_IPHC as defined in Section 3.
当识别的下一个报头是IPv6报头（EID=7）时，LOWPAN_NHC编码的NH位未使用，必须设置为零。必须使用第3节中定义的LOWPAN_IPHC对以下字节进行编码。
This document defines a compression format for UDP headers using LOWPAN_NHC. The UDP compression format is shown in Figure 14. Bits 0 through 4 represent the NHC ID and '11110' indicates the specific UDP header compression encoding defined in this section.
本文档使用LOWPAN_NHC定义UDP报头的压缩格式。UDP压缩格式如图14所示。位0到4表示NHC ID，“11110”表示本节中定义的特定UDP报头压缩编码。
This specification allows a particular range of ports number (0xf0b0 to 0xf0bf) to be compressed down to 4 bits. This is a stateless compression that is inherited from [RFC4944], as opposed to a new stateful compression.
此规范允许将特定范围的端口号（0xf0b0到0xf0bf）压缩到4位。这是从[RFC4944]继承的无状态压缩，与新的有状态压缩相反。
The range of ports compressible down to 4 bits is not in a reserved range. A network stack implementation that is designed to communicate over a 6LoWPAN should avoid using those ports as dynamic ports whenever possible.
可压缩至4位的端口范围不在保留范围内。设计用于通过6LoWPAN进行通信的网络堆栈实现应尽可能避免将这些端口用作动态端口。
Considering that this represents only 16 contiguous ports, it can be expected that many incompatible applications will use the same value of port numbers for their own end-to-end needs. Thus, a port number in the (0xf0b0 to 0xf0bf) range provides very little information about the application at the remote end.
考虑到这只表示16个连续端口，可以预期许多不兼容的应用程序将使用相同的端口号值来满足其端到端的需求。因此，（0xf0b0到0xf0bf）范围内的端口号提供的有关远程端应用程序的信息非常少。
The overloading of the 0xf0bX ports increases the risk of getting the wrong type of payload and misinterpreting the content compared to ports that are reserved at IANA. As a result, it is recommended that the use of those ports be associated with a mechanism such as a Transport Layer Security (TLS) [RFC5246] Message Integrity Check (MIC) that makes sure that the content is what is expected and is checked.
与IANA上保留的端口相比，0xf0bX端口过载增加了获取错误类型的有效负载和误解内容的风险。因此，建议将这些端口的使用与传输层安全性（TLS）[RFC5246]消息完整性检查（MIC）等机制相关联，以确保内容符合预期并得到检查。
The UDP checksum operation is mandatory with IPv6 [RFC2460] for all packets. For that reason, [RFC4944] disallows the compression of the UDP checksum.
对于所有数据包，IPv6[RFC2460]必须执行UDP校验和操作。因此，[RFC4944]不允许对UDP校验和进行压缩。
With this specification, a compressor in the source transport endpoint MAY elide the UDP Checksum if it is authorized by the upper layer. The compressor MUST NOT set the C bit unless it has received such authorization. Requiring upper-layer authorization ensures that the intended transport peer will have sufficient means to deal with any data corruption that occurs before reaching the destination. The upper layer MUST NOT provide the authorization unless one of the following cases is satisfied:
根据此规范，源传输端点中的压缩器如果得到上层的授权，则可以省略UDP校验和。压缩机不得设置C位，除非已收到此类授权。需要上层授权可以确保预期的传输对等方将有足够的手段来处理在到达目的地之前发生的任何数据损坏。上层不得提供授权，除非满足以下情况之一：
Tunneling: In this case, 6LoWPAN is deployed as a wireless pseudo-fieldbus by tunneling existing field protocols over UDP. If the tunneled Protocol Data Unit (PDU) possesses its own addressing, security and integrity check (e.g., IPsec Encapsulating Security Payload tunnel mode [RFC4303] or IP over UDP encapsulation), the tunneling mechanism MAY authorize eliding the UDP checksum in order to save on the encapsulation overhead.
隧道：在这种情况下，6LoWPAN通过UDP隧道现有现场协议部署为无线伪现场总线。如果隧道协议数据单元（PDU）拥有自己的寻址、安全性和完整性检查（例如，IPsec封装安全有效负载隧道模式[RFC4303]或IP over UDP封装），则隧道机制可授权省略UDP校验和，以节省封装开销。
Message Integrity Check: In this case, either IPsec Authentication Header [RFC4302] or some other form of integrity check in the UDP payload that covers at least the same information as the UDP checksum (pseudo-header, data) and has at least the same strength.
消息完整性检查：在这种情况下，IPsec身份验证标头[RFC4302]或UDP有效负载中的某种其他形式的完整性检查，至少覆盖与UDP校验和（伪标头，数据）相同的信息，并且至少具有相同的强度。
To help ensure that the UDP Checksum will be properly restored when expanding a 6LoWPAN packet, an additional integrity check (e.g., a Layer 2 (L2) Message Integrity Check) MUST be used whenever transmitting link frames that carry a compressed UDP datagram that
为了帮助确保在扩展6LoWPAN数据包时正确恢复UDP校验和，在传输包含压缩UDP数据报的链路帧时，必须使用额外的完整性检查（例如，第2层（L2）消息完整性检查）
elides the checksum. Without this additional integrity check, a UDP packet may be delivered to an unintended destination since corruption in data covered by the pseudo-header can go undetected.
省略校验和。如果没有这种额外的完整性检查，UDP数据包可能会被发送到一个非预期的目的地，因为伪报头所覆盖的数据中的损坏可能不会被检测到。
A compressor MUST verify the UDP Checksum before it is elided and MUST ensure that the additional integrity check is in place before verifying and eliding the checksum. If verification of the UDP Checksum fails, the compressor MUST drop the packet.
压缩器必须在删除UDP校验和之前对其进行验证，并且必须确保在验证和删除校验和之前进行了额外的完整性检查。如果UDP校验和验证失败，压缩器必须丢弃数据包。
A decompressor that expands a 6LoWPAN packet with the C bit set MUST compute the UDP Checksum on behalf of the source node and place that value in the restored UDP header as specified in the incumbent standards [RFC0768], [RFC2460]. The decompressor MUST unambiguously determine that an additional integrity check was put in place by the compressor and verify the integrity check and SHOULD do so after restoring the UDP Checksum. If the decompressor cannot unambiguously determine the presence of an integrity check or verification fails, the decompressor MUST drop the packet.
使用C位集扩展6LoWPAN数据包的解压缩程序必须代表源节点计算UDP校验和，并按照现行标准[RFC0768]、[RFC2460]的规定将该值放入还原的UDP报头中。解压器必须明确地确定压缩器进行了额外的完整性检查，并验证完整性检查，并且应在恢复UDP校验和后进行验证。如果解压缩程序无法明确确定是否存在完整性检查或验证失败，则解压缩程序必须丢弃数据包。
The recommended ordering of computing and verifying the UDP Checksum and additional integrity check ensures that data is never stored unprotected in memory. In practice, functionality separation between layers may preclude the recommended ordering. However, implementors should take special note and understand the risks when dealing with unprotected data covered by the pseudo-header.
建议的计算和验证UDP校验和和附加完整性检查的顺序可确保数据永远不会在内存中不受保护地存储。在实践中，层之间的功能分离可能会妨碍推荐的排序。但是，实现人员应该特别注意并理解在处理伪头所包含的未受保护的数据时的风险。
To allow intermediate nodes to compress the UDP Checksum, a forwarding node MAY infer upper-layer authorization for an incoming packet if it has the C bit set and it can unambiguously determine that an integrity check covering the same data as the UDP Checksum was in place while the UDP Checksum was elided. A forwarding node MUST NOT infer authorization if it cannot unambiguously determine the presence of and verify an integrity check while the UDP Checksum was elided.
为了允许中间节点压缩UDP校验和，转发节点可以推断传入数据包的上层授权，前提是它设置了C位，并且它可以明确地确定覆盖与UDP校验和相同的数据的完整性检查已经到位，而UDP校验和被省略。如果在删除UDP校验和时，转发节点无法明确确定是否存在完整性检查并进行验证，则转发节点不得推断授权。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 | 1 | 1 | 1 | 0 | C | P |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 | 1 | 1 | 1 | 0 | C | P |
+---+---+---+---+---+---+---+---+
Figure 14: UDP Header Encoding
图14:UDP报头编码
C: Checksum:
C:校验和：
0: All 16 bits of Checksum are carried in-line.
0：所有16位校验和都以行方式进行。
1: All 16 bits of Checksum are elided. The Checksum is recovered by recomputing it on the 6LoWPAN termination point.
1：所有16位校验和都被省略。通过在6LoWPAN终止点重新计算校验和来恢复校验和。
P: Ports:
P:端口：
00: All 16 bits for both Source Port and Destination Port are carried in-line.
00：源端口和目标端口的所有16位都是在线传输的。
01: All 16 bits for Source Port are carried in-line. First 8 bits of Destination Port is 0xf0 and elided. The remaining 8 bits of Destination Port are carried in-line.
01：源端口的所有16位均以串联方式传输。目标端口的前8位为0xf0并省略。目标端口的其余8位以串联方式传输。
10: First 8 bits of Source Port are 0xf0 and elided. The remaining 8 bits of Source Port are carried in-line. All 16 bits for Destination Port are carried in-line.
10：源端口的前8位为0xf0并省略。源端口的其余8位以串联方式传输。目标端口的所有16位都是在线传输的。
11: First 12 bits of both Source Port and Destination Port are 0xf0b and elided. The remaining 4 bits for each are carried in-line.
11：源端口和目标端口的前12位均为0xf0b并省略。每一个的剩余4位是以行方式进行的。
Fields carried in-line (in part or in whole) appear in the same order as they do in the UDP header format [RFC0768]. The UDP Length field MUST always be elided and is inferred from lower layers using the 6LoWPAN Fragmentation header or the IEEE 802.15.4 header.
行中携带的字段（部分或全部）的显示顺序与UDP报头格式[RFC0768]中的相同。UDP长度字段必须始终省略，并使用6LoWPAN分段标头或IEEE 802.15.4标头从较低层推断。
This document defines a new IPv6 header compression format for 6LoWPAN. The document allocates the following 32 Dispatch type field values for LOWPAN_IPHC:
本文档为6LoWPAN定义了一种新的IPv6标头压缩格式。文档为LOWPAN_IPHC分配以下32个分派类型字段值：
01 100000 through 01 111111
01 100000至01 111111
This assignment preempts the assignment of 01 111111 for ESC [RFC4944]; this preemption is possible because extension bytes that would enable the use of ESC have not been allocated yet. Instead, the value:
此分配优先于ESC[RFC4944]的01 111111分配；这种抢占是可能的，因为尚未分配允许使用ESC的扩展字节。相反，值：
01 000000
01 000000
is reserved as a replacement value for ESC, to be finally assigned with the first assignment of extension bytes.
保留为ESC的替换值，最终将与扩展字节的第一次分配一起分配。
This document also creates a new IANA registry for the LOWPAN_NHC header type, with the following initial content:
本文档还为LOWPAN_NHC头类型创建了一个新的IANA注册表，初始内容如下：
00000000 to 11011111: (unassigned)
1110000N: IPv6 Hop-by-Hop Options Header [RFC6282]
1110001N: IPv6 Routing Header [RFC6282]
1110010N: IPv6 Fragment Header [RFC6282]
1110011N: IPv6 Destination Options Header [RFC6282]
1110100N: IPv6 Mobility Header [RFC6282]
1110111N: IPv6 Header [RFC6282]
11110CPP: UDP Header [RFC6282]
11111000 to 11111110: (unassigned)
00000000 to 11011111: (unassigned)
1110000N: IPv6 Hop-by-Hop Options Header [RFC6282]
1110001N: IPv6 Routing Header [RFC6282]
1110010N: IPv6 Fragment Header [RFC6282]
1110011N: IPv6 Destination Options Header [RFC6282]
1110100N: IPv6 Mobility Header [RFC6282]
1110111N: IPv6 Header [RFC6282]
11110CPP: UDP Header [RFC6282]
11111000 to 11111110: (unassigned)
Capital letters in bit positions represent class-specific bit assignments. N indicates whether or not additional LOWPAN_NHC encodings follow, as defined in Section 4.2. CPP represents variables specific to UDP header compression defined in Section 4.3.
位位置中的大写字母表示特定于类的位分配。N表示是否遵循第4.2节中定义的其他LOWPAN_NHC编码。CPP表示特定于第4.3节中定义的UDP报头压缩的变量。
The policy for this registry [RFC5226] is IETF Review. In this process, new values SHOULD be assigned in a way that preserves the NHC ID abstraction of Section 4 (i.e., k one-bits followed by one zero-bit identify the general class of NHC, followed by class-specific bit assignments).
此注册表[RFC5226]的策略是IETF审查。在此过程中，应以保留第4节NHC ID抽象的方式分配新值（即，k 1位后接1 0位标识NHC的一般类，然后是特定于类的位分配）。
The definition of LOWPAN_IPHC permits the compression of header information on communication that could take place in its absence, albeit in a less efficient form. It recognizes that a IEEE 802.15.4 PAN may have associated with it a number of prefixes through shared context. How the shared context is assigned and managed is beyond the scope of this document.
LOWPAN_IPHC的定义允许压缩通信上的报头信息，而这种信息可能在没有它的情况下发生，尽管是以一种效率较低的形式。它认识到IEEE 802.15.4 PAN可能通过共享上下文与多个前缀关联。如何分配和管理共享上下文超出了本文档的范围。
The overloading of the 0xf0bX ports increases the risk of getting the wrong type of payload and misinterpreting the content compared to ports that reserved at IANA. It is thus recommended that the use of
与IANA上保留的端口相比，0xf0bX端口过载会增加获取错误类型的有效负载和错误解释内容的风险。因此，建议使用
those ports be associated with a mechanism such as a Transport Layer Security (TLS) [RFC5246] Message Integrity Check (MIC) that validates that the content is expected and checked for integrity.
这些端口可以与传输层安全性（TLS）[RFC5246]消息完整性检查（MIC）等机制相关联，该机制验证内容是否符合预期并检查完整性。
Thanks to Julien Abeille, Robert Assimiti, Dominique Barthel, Carsten Bormann, Robert Cragie, Stephen Dawson-Haggerty, Mathilde Durvy, Erik Nordmark, Christos Polyzois, Joseph Reddy, Shoichi Sakane, Zach Shelby, Dario Tedeschi, Tony Viscardi, and Jay Werb for useful design consideration and implementation feedback. Special thanks to David Black, Lars Eggert, and Carsten Bormann for their contribution in closing the security issues around UDP compression.
感谢Julien Abeille、Robert Assimiti、Dominique Barthel、Carsten Bormann、Robert Cragie、Stephen Dawson Haggerty、Mathilde Durvy、Erik Nordmark、Christos Polyzois、Joseph Reddy、Shoichi Sakane、Zach Shelby、Dario Tedeschi、Tony Viscadi和Jay Werb，感谢他们提供了有用的设计考虑和实现反馈。特别感谢David Black、Lars Eggert和Carsten Bormann为解决UDP压缩的安全问题所做的贡献。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
[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月。
[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月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168]Ramakrishnan，K.，Floyd，S.，和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，2001年9月。
[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月。
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007.
[RFC4944]黑山，G.，Kushalnagar，N.，Hui，J.，和D.Culler，“通过IEEE 802.15.4网络传输IPv6数据包”，RFC 49442007年9月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011.
[RFC6275]Perkins，C.，Ed.，Johnson，D.，和J.Arkko，“IPv6中的移动支持”，RFC 62752011年7月。
[IEEE802.15.4] IEEE Computer Society, "IEEE Std. 802.15.4-2006", October 2006.
[IEEE802.15.4]IEEE计算机协会，“IEEE标准802.15.4-2006”，2006年10月。
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, August 2002.
[RFC3306]Haberman，B.和D.Thaler，“基于单播前缀的IPv6多播地址”，RFC3306，2002年8月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315]Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004.
[RFC3956]Savola，P.和B.Haberman，“将集合点（RP）地址嵌入IPv6多播地址”，RFC 3956，2004年11月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]Kent，S.，“IP认证头”，RFC43022005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[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月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
Authors' Addresses
作者地址
Jonathan W. Hui (editor) Arch Rock Corporation 501 2nd St. Ste. 410 San Francisco, California 94107 USA
许文华（编辑）圣路易斯第二街501号拱形石公司。410旧金山，加利福尼亚94107美国
Phone: +415 692 0828
EMail: jhui@archrock.com
Phone: +415 692 0828
EMail: jhui@archrock.com
Pascal Thubert Cisco Systems Village d'Entreprises Green Side 400, Avenue de Roumanille Batiment T3 Biot - Sophia Antipolis 06410 FRANCE
Pascal Thubert Cisco Systems Village d'Enterprises Green Side 400，法国索菲亚安提波利斯（Sophia Antipolis）T3 Biot巴蒂门特大道400号
Phone: +33 4 97 23 26 34
EMail: pthubert@cisco.com
Phone: +33 4 97 23 26 34
EMail: pthubert@cisco.com