Internet Engineering Task Force (IETF) C. Bormann
Request for Comments: 7400 Universitaet Bremen TZI
Category: Standards Track November 2014
ISSN: 2070-1721
Internet Engineering Task Force (IETF) C. Bormann
Request for Comments: 7400 Universitaet Bremen TZI
Category: Standards Track November 2014
ISSN: 2070-1721
6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)
6LoWPAN GHC：低功耗无线个人局域网（6LoWPANs）上IPv6的通用报头压缩
Abstract
摘要
RFC 6282 defines header compression in 6LoWPAN packets (where "6LoWPAN" refers to "IPv6 over Low-Power Wireless Personal Area Network"). The present document specifies a simple addition that enables the compression of generic headers and header-like payloads, without a need to define a new header compression scheme for each such new header or header-like payload.
RFC 6282定义6LoWPAN数据包中的报头压缩（其中“6LoWPAN”指“低功率无线个人区域网络上的IPv6”）。本文档指定了一个简单的添加，它支持对通用报头和类报头有效载荷的压缩，而不需要为每个这样的新报头或类报头有效载荷定义新的报头压缩方案。
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/rfc7400.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7400.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 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 ....................................................2
1.1. The Header Compression Coupling Problem ....................2
1.2. Compression Approach .......................................3
1.3. Terminology ................................................3
1.4. Notation ...................................................4
2. 6LoWPAN-GHC .....................................................4
3. Integrating 6LoWPAN-GHC into 6LoWPAN-HC .........................6
3.1. Compressing Payloads (UDP and ICMPv6) ......................6
3.2. Compressing Extension Headers ..............................6
3.3. Indicating GHC Capability ..................................7
3.4. Using the 6CIO .............................................8
4. IANA Considerations .............................................9
5. Security Considerations ........................................10
6. References .....................................................11
6.1. Normative References ......................................11
6.2. Informative References ....................................12
Appendix A. Examples ..............................................14
Acknowledgements ..................................................24
Author's Address ..................................................24
1. Introduction ....................................................2
1.1. The Header Compression Coupling Problem ....................2
1.2. Compression Approach .......................................3
1.3. Terminology ................................................3
1.4. Notation ...................................................4
2. 6LoWPAN-GHC .....................................................4
3. Integrating 6LoWPAN-GHC into 6LoWPAN-HC .........................6
3.1. Compressing Payloads (UDP and ICMPv6) ......................6
3.2. Compressing Extension Headers ..............................6
3.3. Indicating GHC Capability ..................................7
3.4. Using the 6CIO .............................................8
4. IANA Considerations .............................................9
5. Security Considerations ........................................10
6. References .....................................................11
6.1. Normative References ......................................11
6.2. Informative References ....................................12
Appendix A. Examples ..............................................14
Acknowledgements ..................................................24
Author's Address ..................................................24
[RFC6282] defines a scheme for header compression in 6LoWPAN
[RFC4944] packets; in this document, we refer to that scheme as
6LoWPAN Header Compression, or 6LoWPAN-HC (where "6LoWPAN" refers to
"IPv6 over Low-Power Wireless Personal Area Network"). As with most
header compression schemes, a new specification is necessary for
every new kind of header that needs to be compressed. In addition,
[RFC6282] does not define an extensibility scheme like the Robust
Header Compression (ROHC) profiles defined in ROHC [RFC3095]
[RFC5795]. This leads to the difficult situation in which 6LoWPAN-HC
tended to be reopened and reexamined each time a new header receives
consideration (or an old header is changed and reconsidered) in the
6LoWPAN/roll/CoRE cluster of IETF working groups. Although [RFC6282]
was finally completed and published, the underlying problem remains
unsolved.
[RFC6282] defines a scheme for header compression in 6LoWPAN
[RFC4944] packets; in this document, we refer to that scheme as
6LoWPAN Header Compression, or 6LoWPAN-HC (where "6LoWPAN" refers to
"IPv6 over Low-Power Wireless Personal Area Network"). As with most
header compression schemes, a new specification is necessary for
every new kind of header that needs to be compressed. In addition,
[RFC6282] does not define an extensibility scheme like the Robust
Header Compression (ROHC) profiles defined in ROHC [RFC3095]
[RFC5795]. This leads to the difficult situation in which 6LoWPAN-HC
tended to be reopened and reexamined each time a new header receives
consideration (or an old header is changed and reconsidered) in the
6LoWPAN/roll/CoRE cluster of IETF working groups. Although [RFC6282]
was finally completed and published, the underlying problem remains
unsolved.
The purpose of the present contribution is to plug into [RFC6282] as is, using its Next Header Compression (NHC) concept. We add a slightly less efficient, but vastly more general, form of compression for headers of any kind and even for header-like payloads such as those exhibited by routing protocols, DHCP, etc.: Generic Header Compression (GHC). The objective is an extremely simple
本文的目的是使用[RFC6282]的下一个报头压缩（NHC）概念，按原样插入[RFC6282]。对于任何类型的报头，甚至对于路由协议、DHCP等显示的报头类有效负载，我们添加了一种效率稍低但更通用的压缩形式：通用报头压缩（GHC）。目标非常简单
specification that can be defined on a single page and implemented in a small number of lines of code, as opposed to a general data compression scheme such as that defined in [RFC1951].
与[RFC1951]中定义的一般数据压缩方案相反，可以在单个页面上定义并在少量代码行中实现的规范。
The basic approach of GHC's compression function is to define a bytecode for LZ77-style compression [LZ77]. The bytecode is a series of simple instructions for the decompressor to reconstitute the uncompressed payload. These instructions include:
GHC压缩函数的基本方法是为LZ77样式的压缩定义字节码[LZ77]。字节码是一系列简单的指令，用于解压器重构未压缩的有效负载。这些说明包括：
o appending bytes to the reconstituted payload that are literally given with the instruction in the compressed data
o 将压缩数据中的指令字面上给出的字节追加到重构的有效负载
o appending a given number of zero bytes to the reconstituted payload
o 将给定数量的零字节追加到重构的有效负载
o appending bytes to the reconstituted payload by copying a contiguous sequence from the payload being reconstituted ("backreferencing")
o 通过从正在重构的有效负载复制连续序列向重构的有效负载追加字节（“反向引用”）
o an ancillary instruction for setting up parameters for the backreferencing instruction in "decompression variables"
o 一种辅助指令，用于在“解压缩变量”中为反向引用指令设置参数
o a stop code (optional; see Section 3.2)
o 停车码（可选；见第3.2节）
The buffer for the reconstituted payload ("destination buffer") is prefixed by a predefined dictionary that can be used in the backreferencing as if it were a prefix of the payload. This predefined dictionary is built from the IPv6 addresses of the packet being reconstituted, followed by a static component, the "static dictionary".
重构有效负载的缓冲区（“目标缓冲区”）由预定义的字典作为前缀，该字典可在反向引用中使用，就像它是有效负载的前缀一样。这个预定义的字典是根据正在重构的数据包的IPv6地址构建的，后面是一个静态组件“静态字典”。
As usual, this specification defines the decompressor operation in detail but leaves the detailed operation of the compressor open to implementation. The compressor can be implemented as with a classical LZ77 compressor, or it can be a simple protocol encoder that just makes use of known compression opportunities.
通常，本规范详细定义了解压器的操作，但将压缩机的详细操作留待实施。压缩器可以像经典的LZ77压缩器一样实现，也可以是一个简单的协议编码器，只利用已知的压缩机会。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照RFC 2119[RFC2119]中的说明进行解释。
The term "byte" is used in its now-customary sense as a synonym for "octet".
术语“byte”在现在的习惯意义上被用作“octet”的同义词。
Terms from [RFC7228] are used in Section 5.
第5节使用了[RFC7228]中的术语。
This specification uses a trivial notation for code bytes and the bitfields in them, the meaning of which should be mostly obvious. More formally, the meaning of the notation is as follows:
本规范对代码字节和其中的位字段使用了一种简单的表示法，其含义应该非常明显。更正式地说，符号的含义如下：
Potential values for the code bytes themselves are expressed by templates that represent 8-bit most-significant-bit-first binary numbers (without any special prefix), where 0 stands for 0, 1 for 1, and variable segments in these code byte templates are indicated by sequences of the same letter, such as kkkkkkk or ssss, the length of which indicates the length of the variable segment in bits.
代码字节本身的潜在值由表示8位最高有效位第一位二进制数（无任何特殊前缀）的模板表示，其中0表示0，1表示1，这些代码字节模板中的变量段由相同字母的序列表示，如KKK或SSS，其长度以位表示可变段的长度。
In the notation of values derived from the code bytes, 0b is used as a prefix for expressing binary numbers in most-significant-bit-first notation (akin to the use of 0x for most-significant-digit-first hexadecimal numbers in the C programming language). Where the above-mentioned sequences of letters are then referenced in such a binary number in the text, the intention is that the value from these bitfields in the actual code byte be inserted.
在从代码字节派生的值的表示法中，0b用作表示最高有效位优先表示法中二进制数的前缀（类似于在C编程语言中使用0x表示最高有效位优先的十六进制数）。如果在文本中以这样的二进制数引用上述字母序列，则意图是插入实际代码字节中这些位字段的值。
Example: The code byte template
示例：代码字节模板
101nssss
101nssss
stands for a byte that starts (most-significant-bit-first) with the bits 1, 0, and 1, and continues with five variable bits, the first of which is referenced as "n" and the next four of which are referenced as "ssss". Based on this code byte template, a reference to
表示一个字节，该字节以位1、0和1开始（最高有效位在先），并以五个可变位继续，第一个可变位被称为“n”，接下来的四个可变位被称为“sss”。基于此代码字节模板，对
0b0ssss000
0B0SS000
means a binary number composed from a zero bit; the four bits that are in the "ssss" field (for 101nssss, the four least significant bits) in the actual byte encountered, kept in the same order; and three more zero bits.
指由零位组成的二进制数；实际遇到的字节中“ssss”字段中的四位（对于101nssss，四个最低有效位），保持相同的顺序；还有三个零位。
The format of a GHC-compressed header or payload is a simple bytecode. A compressed header consists of a sequence of pieces, each of which begins with a code byte, which may be followed by zero or more bytes as its argument. Some code bytes cause bytes to be laid out in the destination buffer, and some simply modify some decompression variables.
GHC压缩头或有效负载的格式是简单的字节码。压缩头由一系列片段组成，每个片段以一个代码字节开头，后面可能有零个或多个字节作为其参数。有些代码字节会导致字节在目标缓冲区中布局，有些代码字节只是修改一些解压缩变量。
At the start of decompressing a header or payload within an L2 packet (= fragment), the decompression variables "sa" and "na" are initialized as zero.
在开始解压缩二级数据包（=片段）内的报头或有效负载时，解压缩变量“sa”和“na”初始化为零。
The code bytes are defined as follows (Table 1):
代码字节定义如下（表1）：
+----------+---------------------------------------------+----------+
| code | Action | Argument |
| byte | | |
+----------+---------------------------------------------+----------+
| 0kkkkkkk | Append k = 0b0kkkkkkk bytes of data in the | k bytes |
| | bytecode argument (k < 96) | of data |
| | | |
| 1000nnnn | Append 0b0000nnnn+2 bytes of zeroes | |
| | | |
| 10010000 | stop code (end of compressed data; see | |
| | Section 3.2) | |
| | | |
| 101nssss | Set up extended arguments for a | |
| | backreference: sa += 0b0ssss000, | |
| | na += 0b0000n000 | |
| | | |
| 11nnnkkk | Backreference: n = na+0b00000nnn+2; | |
| | s = 0b00000kkk+sa+n; append n bytes from | |
| | previously output bytes, starting s bytes | |
| | to the left of the current output pointer; | |
| | set sa = 0, na = 0 | |
+----------+---------------------------------------------+----------+
+----------+---------------------------------------------+----------+
| code | Action | Argument |
| byte | | |
+----------+---------------------------------------------+----------+
| 0kkkkkkk | Append k = 0b0kkkkkkk bytes of data in the | k bytes |
| | bytecode argument (k < 96) | of data |
| | | |
| 1000nnnn | Append 0b0000nnnn+2 bytes of zeroes | |
| | | |
| 10010000 | stop code (end of compressed data; see | |
| | Section 3.2) | |
| | | |
| 101nssss | Set up extended arguments for a | |
| | backreference: sa += 0b0ssss000, | |
| | na += 0b0000n000 | |
| | | |
| 11nnnkkk | Backreference: n = na+0b00000nnn+2; | |
| | s = 0b00000kkk+sa+n; append n bytes from | |
| | previously output bytes, starting s bytes | |
| | to the left of the current output pointer; | |
| | set sa = 0, na = 0 | |
+----------+---------------------------------------------+----------+
Table 1: Bytecodes for Generic Header Compression
表1：通用头压缩的字节码
Note that the following bit combinations are reserved at this time:
注意，此时保留以下位组合：
o 011xxxxx
o 011xxxxx
o 1001nnnn (where 0b0000nnnn > 0)
o 1001nnnn（其中0b0000nnnn>0）
For the purposes of the backreferences, the expansion buffer is initialized with a predefined dictionary, at the end of which the reconstituted payload begins. This dictionary is composed of the source and destination IPv6 addresses of the packet being reconstituted, followed by a 16-byte static dictionary (Figure 1). These 48 dictionary bytes are therefore available for backreferencing but not copied into the final reconstituted payload.
出于反向引用的目的，扩展缓冲区使用预定义的字典进行初始化，在字典的末尾，重构的有效负载开始。该字典由正在重构的数据包的源和目标IPv6地址组成，后面是一个16字节的静态字典（图1）。因此，这48个字典字节可用于反向引用，但不会复制到最终的重构负载中。
16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00
16 fe fd 17 fe fd 00 01 00 00 00
Figure 1: The 16 Bytes of Static Dictionary (in Hex)
图1：静态字典的16字节（十六进制）
6LoWPAN-GHC plugs in as an NHC format for 6LoWPAN-HC [RFC6282].
6LoWPAN GHC作为6LoWPAN HC的NHC格式插入[RFC6282]。
By definition, GHC is generic and can be applied to different kinds of packets. Many of the examples given in Appendix A are for ICMPv6 packets; a single NHC value suffices to define an NHC format for ICMPv6 based on GHC (see below).
根据定义，GHC是通用的，可以应用于不同类型的数据包。附录A中给出的许多示例适用于ICMPv6数据包；单个NHC值足以定义基于GHC的ICMPv6的NHC格式（见下文）。
In addition, it is useful to include an NHC format for UDP, as many header-like payloads (e.g., DHCPv6, Datagram Transport Layer Security (DTLS)) are carried in UDP. [RFC6282] already defines an NHC format for UDP (11110CPP). GHC uses an analogous NHC byte formatted as shown in Figure 2. The difference to the existing UDP NHC specification is that for 11010CPP NHC bytes, the UDP payload is not supplied literally but compressed by 6LoWPAN-GHC.
此外，将NHC格式包含在UDP中也很有用，因为UDP中承载了许多类似报头的有效负载（例如，DHCPv6、数据报传输层安全性（DTL））。[RFC6282]已经为UDP（11110CPP）定义了NHC格式。GHC使用类似的NHC字节，其格式如图2所示。与现有UDP NHC规范的区别在于，对于11010CPP NHC字节，UDP有效负载不是按字面意思提供的，而是由6LoWPAN GHC压缩的。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 | 1 | 0 | 1 | 0 | C | P |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 | 1 | 0 | 1 | 0 | C | P |
+---+---+---+---+---+---+---+---+
Figure 2: NHC Byte for UDP GHC (11010CPP)
图2:UDP GHC的NHC字节（11010CPP）
To stay in the same general numbering space, we use 11011111 as the NHC byte for ICMPv6 GHC (Figure 3).
为了保持相同的通用编号空间，我们使用11011111作为ICMPv6 GHC的NHC字节（图3）。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 | 1 | 0 | 1 | 1 | 1 | 1 | 1 |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 | 1 | 0 | 1 | 1 | 1 | 1 | 1 |
+---+---+---+---+---+---+---+---+
Figure 3: NHC Byte for ICMPv6 GHC (11011111)
图3:ICMPv6 GHC（11011111）的NHC字节
Compression of specific extension headers is added in a similar way (Figure 4) (however, probably only Extension Header ID (EID) 0 to 3 [RFC6282] need to be assigned). As there is no easy way to extract the Length field from the GHC-encoded header before decoding, this would make detecting the end of the extension header somewhat complex. The easiest (and most efficient) approach is to completely elide the Length field (in the same way NHC already elides the Next Header field in certain cases) and reconstruct it only on decompression. To serve as a terminator for the extension header, the bytecode 0b10010000 has been assigned as a stop code. Note that
以类似的方式添加特定扩展头的压缩（图4）（但是，可能只需要分配扩展头ID（EID）0到3[RFC6282]）。由于在解码之前没有简单的方法从GHC编码的报头中提取长度字段，这将使检测扩展报头的结束变得有些复杂。最简单（也是最有效）的方法是完全省略长度字段（与NHC在某些情况下已经省略下一个标头字段的方式相同），并仅在解压缩时重建它。为了用作扩展标头的终止符，字节码0b10010000被指定为停止码。注意
the stop code is only needed for extension headers, not for the final payloads discussed in the previous subsection, the decompression of which is automatically stopped by the end of the packet.
停止代码仅适用于扩展头，而不适用于上一小节中讨论的最终有效负载，在数据包结束时自动停止解压缩。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 | 0 | 1 | 1 | EID |NH |
+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 | 0 | 1 | 1 | EID |NH |
+---+---+---+---+---+---+---+---+
Figure 4: NHC Byte for Extension Header GHC
图4：扩展头GHC的NHC字节
The 6LoWPAN baseline includes just [RFC4944], [RFC6282], and [RFC6775] (see [Roadmap-6LoWPAN]). To enable the use of GHC towards a neighbor, a 6LoWPAN node needs to know that the neighbor implements it. While this can also simply be administratively required, a transition strategy as well as a way to support mixed networks is required.
6LoWPAN基线仅包括[RFC4944]、[RFC6282]和[RFC6775]（参见[Roadmap-6LoWPAN]）。为了能够对邻居使用GHC，6LoWPAN节点需要知道邻居实现了它。虽然这也可能只是管理上的需要，但需要一种过渡策略以及一种支持混合网络的方法。
One way to know that a neighbor does implement GHC is receiving a packet from that neighbor with GHC in it ("implicit capability detection"). However, there needs to be a way to bootstrap this, as nobody would ever start sending packets with GHC otherwise.
了解邻居是否实现GHC的一种方法是从邻居接收包含GHC的数据包（“隐式能力检测”）。然而，需要有一种方法来引导它，否则没有人会开始用GHC发送数据包。
To minimize the impact on [RFC6775], we define a Neighbor Discovery (ND) option called the 6LoWPAN Capability Indication Option (6CIO), as illustrated in Figure 5. (For the fields marked by an underscore in Figure 5, see Section 3.4.)
为了尽量减少对[RFC6775]的影响，我们定义了一个邻居发现（ND）选项，称为6LoWPAN能力指示选项（6CIO），如图5所示。（对于图5中用下划线标记的字段，请参见第3.4节。）
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length = 1 |_____________________________|G|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|_______________________________________________________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length = 1 |_____________________________|G|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|_______________________________________________________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: 6LoWPAN Capability Indication Option (6CIO)
图5:6LoWPAN能力指示选项（6CIO）
The G bit indicates whether the node sending the option is GHC capable.
G位指示发送选项的节点是否支持GHC。
Once a node receives either an explicit or implicit indication of GHC capability from another node, it may send GHC-compressed packets to that node. Where that capability has not been recently confirmed, similar to the way Packetization Layer Path MTU Discovery (PLPMTUD)
一旦一个节点从另一个节点接收到GHC能力的显式或隐式指示，它就可以向该节点发送GHC压缩包。该功能最近未得到确认，类似于打包层路径MTU发现（PLPMTUD）的方式
[RFC4821] finds out about changes in the network, a node SHOULD make use of Neighbor Unreachability Detection (NUD) failures to switch back to basic 6LoWPAN header compression [RFC6282].
[RFC4821]了解网络中的变化，节点应利用邻居不可达性检测（NUD）故障切换回基本的6LoWPAN头压缩[RFC6282]。
The 6CIO will typically only be sent in 6LoWPAN-ND Router Solicitation (RS) packets (which cannot themselves be GHC compressed unless the host desires to limit itself to talking to GHC-capable routers). The resulting 6LoWPAN-ND Router Advertisement (RA) can then already make use of GHC and thus indicate GHC capability implicitly, which in turn allows both nodes to use GHC in the 6LoWPAN-ND Neighbor Solicitation / Neighbor Advertisement (NS/NA) exchange.
6CIO通常仅以6LoWPAN ND路由器请求（RS）数据包的形式发送（除非主机希望限制自己与支持GHC的路由器通话，否则这些数据包本身不能被GHC压缩）。由此产生的6LoWPAN ND路由器通告（RA）可以已经使用GHC，从而隐式地指示GHC能力，这反过来允许两个节点在6LoWPAN ND邻居请求/邻居通告（NS/NA）交换中使用GHC。
The 6CIO can also be used for future options that need to be negotiated between 6LoWPAN peers; an IANA registry is used to assign the flags. Bits marked by underscores in Figure 5 are unassigned and available for future assignment. They MUST be sent as zero and MUST be ignored on reception until assigned by IANA. Length values larger than 1 MUST be accepted by implementations in order to enable future extensions; the additional bits in the option are then deemed unassigned in the same way. For the purposes of the IANA registry, the bits are numbered in most-significant-bit-first order from the 16th bit of the option onward: the 16th bit is flag number 0, the 31st bit (the G bit) is flag number 15, up to the 63rd bit for flag number 47. (Additional bits may also be used by a follow-on version of this document if some bit combinations that have been left unassigned here are then used in an upward-compatible manner.)
6CIO还可用于需要在6LoWPAN同行之间协商的未来选项；IANA注册表用于分配标志。图5中用下划线标记的位是未分配的，可用于将来的分配。它们必须作为零发送，在IANA分配之前，在接收时必须忽略。为了支持将来的扩展，实现必须接受大于1的长度值；然后，该选项中的附加位以相同方式被视为未分配。出于IANA注册表的目的，从选项的第16位开始，按最高有效位的顺序对位进行编号：第16位为标志号0，第31位（G位）为标志号15，直至标志号47的第63位。（如果此处未指定的某些位组合随后以向上兼容的方式使用，则本文档的后续版本也可以使用其他位。）
Flag numbers 0 to 7 are reserved for experimental use. They MUST NOT be used for actual deployments.
标记号0到7保留供实验使用。它们不得用于实际部署。
Where the use of this option by other specifications or for experimental use is envisioned, the following items have to be kept in mind:
如果设想通过其他规范或试验使用此选项，则必须记住以下事项：
o The option can be used in any ND packet.
o 该选项可用于任何ND数据包。
o Specific bits are set in the option to indicate that a capability is present in the sender. (There may be other ways to infer this information, as is the case in this specification.) Bit combinations may be used as desired. The absence of the capability _indication_ is signaled by setting these bits to zero; this does not necessarily mean that the capability is absent.
o 在选项中设置特定位，以指示发送方中存在功能。（与本规范中的情况一样，可以有其他方法来推断该信息。）可以根据需要使用位组合。通过将这些位设置为零来表示没有能力指示；这并不一定意味着没有这种能力。
o The intention is not to modify the semantics of the specific ND packet carrying the option but to provide the general capability indication described above.
o 目的不是修改携带该选项的特定ND分组的语义，而是提供上述的一般能力指示。
o Specifications have to be designed such that receivers that do not receive or do not process such a capability indication can still interoperate (presumably without exploiting the indicated capability).
o 规范的设计必须确保未接收或未处理此类能力指示的接收器仍然可以互操作（假定不利用指示的能力）。
o The option is meant to be used sparsely, i.e., once a sender has reason to believe the capability indication has been received, there is no longer a need to continue sending it.
o 该选项用于稀疏使用，即，一旦发送方有理由相信已收到能力指示，就不再需要继续发送。
IANA has added the assignments listed in Figure 6 in the "LOWPAN_NHC Header Type" registry (under "IPv6 Low Power Personal Area Network Parameters").
IANA在“LOWPAN_NHC头类型”注册表中添加了图6中列出的分配（在“IPv6低功耗个人局域网参数”下）。
10110EEN: Extension header GHC [RFC7400]
11010CPP: UDP GHC [RFC7400]
11011111: ICMPv6 GHC [RFC7400]
10110EEN: Extension header GHC [RFC7400]
11010CPP: UDP GHC [RFC7400]
11011111: ICMPv6 GHC [RFC7400]
Figure 6: IANA Assignments for the NHC Byte
图6:NHC字节的IANA分配
IANA has allocated ND option number 36 for the "6LoWPAN Capability Indication Option (6CIO)" ND option format in the "IPv6 Neighbor Discovery Option Formats" registry [RFC4861].
IANA已为“IPv6邻居发现选项格式”注册表[RFC4861]中的“6LoWPAN能力指示选项（6CIO）”ND选项格式分配了ND选项编号36。
IANA has created a subregistry for "6LoWPAN capability Bits" under the "Internet Control Message Protocol version 6 (ICMPv6) Parameters" registry. The bits are assigned by giving their numbers as small, non-negative integers as defined in Section 3.4, in the range 0-47. The policy is "IETF Review" or "IESG Approval" [RFC5226]. The initial content of the registry is as shown in Figure 7:
IANA在“Internet控制消息协议版本6（ICMPv6）参数”注册表下为“6LoWPAN能力位”创建了一个子区。通过将其数字指定为第3.4节中定义的0-47范围内的小非负整数来分配位。政策为“IETF审查”或“IESG批准”[RFC5226]。注册表的初始内容如图7所示：
0-7: Reserved for Experimental Use [RFC7400] 8-14: Unassigned 15: GHC capable bit (G bit) [RFC7400] 16-47: Unassigned
0-7:预留供实验使用[RFC7400]8-14:未分配15:支持GHC的位（G位）[RFC7400]16-47:未分配
Figure 7: IANA Assignments for the 6LoWPAN Capability Bits
图7:6LoWPAN功能位的IANA分配
The security considerations of [RFC4944] and [RFC6282] apply. As usual in protocols with packet parsing/construction, care must be taken in implementations to avoid buffer overflows and, in particular (with respect to the backreferencing), out-of-area references during decompression.
[RFC4944]和[RFC6282]的安全注意事项适用。与具有数据包解析/构造的协议中的通常情况一样，在实现中必须注意避免缓冲区溢出，特别是（关于反向引用），在解压缩期间避免区域外引用。
One additional consideration is that an attacker may send a forged packet that makes a second node believe a third victim node is GHC capable. If it is not, this may prevent packets sent by the second node from reaching the third node (at least until robustness features such as those discussed in Section 3.3 kick in).
另一个需要考虑的问题是，攻击者可能发送伪造的数据包，使第二个节点相信第三个受害者节点具有GHC能力。如果不是，这可能会阻止第二个节点发送的数据包到达第三个节点（至少在第3.3节中讨论的健壮性特征生效之前）。
No mitigation is proposed (or known) for this attack, except that a victim node that does implement GHC is not vulnerable. However, with unsecured ND, a number of attacks with similar outcomes are already possible, so there is little incentive to make use of this additional attack. With secured ND, the 6CIO is also secured; nodes relying on secured ND therefore should use the 6CIO bidirectionally (and limit the implicit capability detection to secured ND packets carrying GHC) instead of basing their neighbor capability assumptions on receiving any kind of unprotected packet.
除了实施GHC的受害节点不易受攻击之外，没有针对该攻击提出（或已知）任何缓解措施。然而，对于不安全的ND，已经有许多具有类似结果的攻击存在，因此很少有动机使用这种额外的攻击。有了安全的ND，6CIO也就安全了；因此，依赖于安全ND的节点应双向使用6CIO（并将隐式能力检测限制为携带GHC的安全ND数据包），而不是基于接收任何类型的未保护数据包的邻居能力假设。
As with any LZ77 scheme, decompression bombs (compressed packets crafted to expand so much that the decompressor is overloaded) are a problem. An attacker cannot send a GHC decompressor into a tight loop for too long, because the MTU will be reached quickly. Some amplification of an attack from inside the compressed link is possible, though. Using a constrained node in a constrained network as a DoS attack source is usually not very useful, though, except maybe against other nodes in that constrained network. The worst case for an attack to the outside is a not-so-constrained device using a (typically not-so-constrained) edge router to attack by forwarding out of its Ethernet interface. The worst-case amplification of GHC is 17, so an MTU-size packet can be generated from a 6LoWPAN packet of 76 bytes. The 6LoWPAN network is still constrained, so the amplification at the edge router turns an entire 250 kbit/s 802.15.4 network (assuming a theoretical upper bound of 225 kbit/s throughput to a single-hop adjacent node) into a 3.8 Mbit/s attacker.
与任何LZ77方案一样，解压炸弹（经过精心设计的压缩数据包扩展得过多，以至于解压器过载）也是一个问题。攻击者无法将GHC解压器发送到紧密循环中的时间过长，因为MTU将很快到达。不过，从压缩链接内部可能会放大攻击。不过，将受约束网络中的受约束节点用作DoS攻击源通常不是很有用，除非是针对该受约束网络中的其他节点。对外部进行攻击的最坏情况是一个不受约束的设备使用一个（通常不受约束的）边缘路由器，通过从其以太网接口转发出去进行攻击。GHC的最坏情况放大为17，因此可以从76字节的6LoWPAN数据包生成MTU大小的数据包。6LoWPAN网络仍然受到限制，因此边缘路由器上的放大将整个250 kbit/s 802.15.4网络（假设单跳相邻节点的理论吞吐量上限为225 kbit/s）转化为3.8 Mbit/s攻击者。
The amplification may be more important inside the 6LoWPAN, if there is a way to obtain reflection (otherwise, the packet is likely to simply stay compressed on the way and do little damage), e.g., by pinging a node using a decompression bomb, somehow keeping that node from re-compressing the ping response (which would probably require something more complex than simple runs of zeroes, so the worst-case
如果有办法获得反射（否则，数据包可能只是在途中保持压缩状态，几乎不会造成损坏），例如，通过使用解压炸弹ping一个节点，以某种方式防止该节点重新压缩ping响应，则放大在6LoWPAN内可能更为重要（这可能需要比简单的零运行更复杂的东西，所以最坏的情况是
amplification is likely closer to 9). Or, if there are nodes that do not support GHC, those can be attacked via a router that is then forced to decompress.
放大率可能接近9）。或者，如果存在不支持GHC的节点，则可以通过路由器对其进行攻击，然后强制解压。
All these attacks are mitigated by some form of network access control.
所有这些攻击都通过某种形式的网络访问控制得以缓解。
In a 6LoWPAN stack, sensitive information will normally be protected by transport- or application-layer (or even IP-layer) security, which are all above the adaptation layer, leaving no sensitive information to compress at the GHC level. However, a 6LoWPAN deployment that entirely depends on Media Access Control (MAC) layer security may be vulnerable to attacks that exploit redundancy information disclosed by compression to recover information about secret values. The attacker would need to be in radio range to observe the compressed packets. Since compression is stateless, the attacker would need to entice the party sending the secret value to also send some value controlled (or at least usefully varying and knowable) by the attacker in (what becomes the first adaptation-layer fragment of) the same packet. This attack is fully mitigated by not exposing secret values to the adaptation layer or by not using GHC in deployments where this is done.
在6LoWPAN堆栈中，敏感信息通常会受到传输层或应用层（甚至IP层）安全性的保护，这些安全性都在适配层之上，不会在GHC级别压缩敏感信息。但是，完全依赖媒体访问控制（MAC）层安全性的6LoWPAN部署可能容易受到攻击，这些攻击利用压缩公开的冗余信息来恢复有关秘密值的信息。攻击者需要在无线电范围内观察压缩的数据包。由于压缩是无状态的，攻击者需要诱使发送秘密值的一方也在同一数据包中发送由攻击者控制（或至少有效地改变和知道）的值（成为该数据包的第一个适配层片段）。通过不向适配层公开秘密值，或在进行此操作的部署中不使用GHC，可以完全缓解此攻击。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007, <http://www.rfc-editor.org/info/rfc4861>.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 48612007年9月<http://www.rfc-editor.org/info/rfc4861>.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007, <http://www.rfc-editor.org/info/rfc4944>.
[RFC4944]黑山，G.，Kushalnagar，N.，Hui，J.，和D.Culler，“通过IEEE 802.15.4网络传输IPv6数据包”，RFC 49442007年9月<http://www.rfc-editor.org/info/rfc4944>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, September 2011, <http://www.rfc-editor.org/info/rfc6282>.
[RFC6282]Hui，J.和P.Thubert，“基于IEEE 802.15.4的网络上IPv6数据报的压缩格式”，RFC 62822011年9月<http://www.rfc-editor.org/info/rfc6282>.
[RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, November 2012, <http://www.rfc-editor.org/info/rfc6775>.
[RFC6775]Shelby，Z.，Chakrabarti，S.，Nordmark，E.，和C.Bormann，“低功耗无线个人区域网络（6LoWPANs）上IPv6邻居发现优化”，RFC 67752012年11月<http://www.rfc-editor.org/info/rfc6775>.
[ICMPv6-ND] O'Flynn, C., "ICMPv6/ND Compression for 6LoWPAN Networks", Work in Progress, draft-oflynn-6lowpan-icmphc-00, July 2010.
[ICMPv6 ND]O'Flynn，C.，“6LoWPAN网络的ICMPv6/ND压缩”，正在进行的工作，草案-oflynn-6LoWPAN-icmphc-00，2010年7月。
[LZ77] Ziv, J. and A. Lempel, "A Universal Algorithm for Sequential Data Compression", IEEE Transactions on Information Theory, Vol. 23, No. 3, pp. 337-343, May 1977.
[LZ77]Ziv，J.和A.Lempel，“顺序数据压缩的通用算法”，IEEE信息论学报，第23卷，第3期，第337-343页，1977年5月。
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996, <http://www.rfc-editor.org/info/rfc1951>.
[RFC1951]Deutsch，P.，“DEFLATE压缩数据格式规范1.3版”，RFC1951，1996年5月<http://www.rfc-editor.org/info/rfc1951>.
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001, <http://www.rfc-editor.org/info/rfc3095>.
[RFC3095]Bormann，C.，Burmeister，C.，Degermark，M.，Fukushima，H.，Hannu，H.，Jonsson，L-E.，Hakenberg，R.，Koren，T.，Le，K.，Liu，Z.，Martenson，A.，Miyazaki，A.，Svanbro，K.，Wiebke，T.，Yoshimura，T.，和H.Zheng，“鲁棒头压缩（ROHC）：框架和四个配置文件：RTP，UDP，ESP，和未压缩”，RFC 3095，2001年7月， <http://www.rfc-editor.org/info/rfc3095>.
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007, <http://www.rfc-editor.org/info/rfc4821>.
[RFC4821]Mathis，M.和J.Heffner，“打包层路径MTU发现”，RFC 48212007年3月<http://www.rfc-editor.org/info/rfc4821>.
[RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust Header Compression (ROHC) Framework", RFC 5795, March 2010, <http://www.rfc-editor.org/info/rfc5795>.
[RFC5795]Sandlund，K.，Pelletier，G.和L-E.Jonsson，“鲁棒头压缩（ROHC）框架”，RFC 57952010年3月<http://www.rfc-editor.org/info/rfc5795>.
[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, March 2012, <http://www.rfc-editor.org/info/rfc6550>.
[RFC6550]温特，T.，图伯特，P.，布兰特，A.，许，J.，凯尔西，R.，列维斯，P.，皮斯特，K.，斯特鲁克，R.，瓦塞尔，JP.，和R.亚历山大，“RPL：低功耗和有损网络的IPv6路由协议”，RFC 65502012年3月<http://www.rfc-editor.org/info/rfc6550>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, May 2014, <http://www.rfc-editor.org/info/rfc7228>.
[RFC7228]Bormann，C.，Ersue，M.和A.Keranen，“受限节点网络的术语”，RFC 7228，2014年5月<http://www.rfc-editor.org/info/rfc7228>.
[Roadmap-6LoWPAN] Bormann, C., "6LoWPAN Roadmap and Implementation Guide", Work in Progress, draft-bormann-6lo-6lowpan-roadmap-00, October 2013.
[Roadmap-6LoWPAN]Bormann，C.，“6LoWPAN路线图和实施指南”，正在进行的工作，草稿-Bormann-6lo-6LoWPAN-Roadmap-00，2013年10月。
This section demonstrates some relatively realistic examples derived from actual packet captures taken at previous interops.
本节演示了一些从以前互操作中获取的实际数据包捕获中得到的相对现实的示例。
For the Routing Protocol for Low-Power and Lossy Networks (RPL) [RFC6550], Figure 8 shows a Destination-Oriented Directed Acyclic Graph (DODAG) Information Solicitation (DIS), a quite short RPL message that obviously cannot be improved much.
对于低功耗和有损网络的路由协议（RPL）[RFC6550]，图8显示了一个面向目的地的有向无环图（DODAG）信息请求（DIS），这是一个很短的RPL消息，显然无法得到很大的改进。
IP header: 60 00 00 00 00 08 3a ff fe 80 00 00 00 00 00 00 02 1c da ff fe 00 20 24 ff 02 00 00 00 00 00 00 00 00 00 00 00 00 00 1a Payload: 9b 00 6b de 00 00 00 00 Dictionary: fe 80 00 00 00 00 00 00 02 1c da ff fe 00 20 24 ff 02 00 00 00 00 00 00 00 00 00 00 00 00 00 1a 16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00 copy: 04 9b 00 6b de 4 nulls: 82 Compressed: 04 9b 00 6b de 82 Was 8 bytes; compressed to 6 bytes, compression factor 1.33
IP头：60 00 00 00 08 3a ff fe 80 00 00 00 00 00 00 00 02 1c da ff fe 00 20 24 ff 02 00 00 00 00 00 00 01有效载荷：9b 00 6b de 00 00 00 00字典：fe 80 00 00 00 00 00 00 02 1c da ff fe 00 20 24 ff 02 00 00 00 00 00 00 00 1a 16 fe fd 17 fe fd 00 01 00 00 00 00 00 00 00 00 00拷贝：04 9b 00 6b de 4 NULL:82压缩：049B006BDE82是8字节；压缩到6字节，压缩系数为1.33
Figure 8: A Simple RPL Example
图8：一个简单的RPL示例
Figure 9 shows a RPL DODAG Information Object, a longer RPL control message that is improved a bit more. Note that the compressed output exposes an inefficiency in the simple-minded compressor used to generate it; this does not devalue the example, since constrained nodes are quite likely to make use of simple-minded compressors.
图9显示了一个RPL DODAG信息对象，这是一个更长的RPL控制消息，改进了一点。注意，压缩输出暴露了用于生成它的简单压缩机的低效性；这不会降低示例的价值，因为受约束节点很可能使用简单的压缩器。
IP header:
60 00 00 00 00 5c 3a ff fe 80 00 00 00 00 00 00
02 1c da ff fe 00 30 23 ff 02 00 00 00 00 00 00
00 00 00 00 00 00 00 1a
Payload:
9b 01 7a 5f 00 f0 01 00 88 00 00 00 20 02 0d b8
00 00 00 00 00 00 00 ff fe 00 fa ce 04 0e 00 14
09 ff 00 00 01 00 00 00 00 00 00 00 08 1e 80 20
ff ff ff ff ff ff ff ff 00 00 00 00 20 02 0d b8
00 00 00 00 00 00 00 ff fe 00 fa ce 03 0e 40 00
ff ff ff ff 20 02 0d b8 00 00 00 00
Dictionary:
fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23
ff 02 00 00 00 00 00 00 00 00 00 00 00 00 00 1a
16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00
copy: 06 9b 01 7a 5f 00 f0
ref(9): 01 00 -> ref 11nnnkkk 0 7: c7
copy: 01 88
3 nulls: 81
copy: 04 20 02 0d b8
7 nulls: 85
ref(60): ff fe 00 -> ref 101nssss 0 7/11nnnkkk 1 1: a7 c9
copy: 08 fa ce 04 0e 00 14 09 ff
ref(39): 00 00 01 00 00 -> ref 101nssss 0 4/11nnnkkk 3 2: a4 da
5 nulls: 83
copy: 06 08 1e 80 20 ff ff
ref(2): ff ff -> ref 11nnnkkk 0 0: c0
ref(4): ff ff ff ff -> ref 11nnnkkk 2 0: d0
4 nulls: 82
ref(48): 20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 fa ce
-> ref 101nssss 1 4/11nnnkkk 6 0: b4 f0
copy: 03 03 0e 40
ref(9): 00 ff -> ref 11nnnkkk 0 7: c7
ref(28): ff ff ff -> ref 101nssss 0 3/11nnnkkk 1 1: a3 c9
ref(24): 20 02 0d b8 00 00 00 00
-> ref 101nssss 0 2/11nnnkkk 6 0: a2 f0
Compressed:
06 9b 01 7a 5f 00 f0 c7 01 88 81 04 20 02 0d b8
85 a7 c9 08 fa ce 04 0e 00 14 09 ff a4 da 83 06
08 1e 80 20 ff ff c0 d0 82 b4 f0 03 03 0e 40 c7
a3 c9 a2 f0
Was 92 bytes; compressed to 52 bytes, compression factor 1.77
IP header:
60 00 00 00 00 5c 3a ff fe 80 00 00 00 00 00 00
02 1c da ff fe 00 30 23 ff 02 00 00 00 00 00 00
00 00 00 00 00 00 00 1a
Payload:
9b 01 7a 5f 00 f0 01 00 88 00 00 00 20 02 0d b8
00 00 00 00 00 00 00 ff fe 00 fa ce 04 0e 00 14
09 ff 00 00 01 00 00 00 00 00 00 00 08 1e 80 20
ff ff ff ff ff ff ff ff 00 00 00 00 20 02 0d b8
00 00 00 00 00 00 00 ff fe 00 fa ce 03 0e 40 00
ff ff ff ff 20 02 0d b8 00 00 00 00
Dictionary:
fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23
ff 02 00 00 00 00 00 00 00 00 00 00 00 00 00 1a
16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00
copy: 06 9b 01 7a 5f 00 f0
ref(9): 01 00 -> ref 11nnnkkk 0 7: c7
copy: 01 88
3 nulls: 81
copy: 04 20 02 0d b8
7 nulls: 85
ref(60): ff fe 00 -> ref 101nssss 0 7/11nnnkkk 1 1: a7 c9
copy: 08 fa ce 04 0e 00 14 09 ff
ref(39): 00 00 01 00 00 -> ref 101nssss 0 4/11nnnkkk 3 2: a4 da
5 nulls: 83
copy: 06 08 1e 80 20 ff ff
ref(2): ff ff -> ref 11nnnkkk 0 0: c0
ref(4): ff ff ff ff -> ref 11nnnkkk 2 0: d0
4 nulls: 82
ref(48): 20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 fa ce
-> ref 101nssss 1 4/11nnnkkk 6 0: b4 f0
copy: 03 03 0e 40
ref(9): 00 ff -> ref 11nnnkkk 0 7: c7
ref(28): ff ff ff -> ref 101nssss 0 3/11nnnkkk 1 1: a3 c9
ref(24): 20 02 0d b8 00 00 00 00
-> ref 101nssss 0 2/11nnnkkk 6 0: a2 f0
Compressed:
06 9b 01 7a 5f 00 f0 c7 01 88 81 04 20 02 0d b8
85 a7 c9 08 fa ce 04 0e 00 14 09 ff a4 da 83 06
08 1e 80 20 ff ff c0 d0 82 b4 f0 03 03 0e 40 c7
a3 c9 a2 f0
Was 92 bytes; compressed to 52 bytes, compression factor 1.77
Figure 9: A Longer RPL Example
图9：一个较长的RPL示例
Similarly, Figure 10 shows a RPL Destination Advertisement Object (DAO) message. One of the embedded addresses is copied right out of the pseudo-header; the other one is effectively converted from global to local by providing the prefix FE80 literally, inserting a number of nulls, and copying (some of) the Interface Identifier part again out of the pseudo-header. Note that a simple implementation would probably emit fewer nulls and copy the entire Interface Identifier; there are multiple ways to encode this 50-byte payload into 27 bytes.
类似地，图10显示了RPL目标广告对象（DAO）消息。其中一个嵌入地址直接从伪报头中复制出来；另一个有效地从全局转换为本地，方法是按字面提供前缀FE80，插入大量空值，并将接口标识符部分再次从伪报头中复制（部分）。注意，一个简单的实现可能会发出更少的空值并复制整个接口标识符；有多种方法可以将这个50字节的有效负载编码为27字节。
IP header: 60 00 00 00 00 32 3a ff 20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 33 44 20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 11 22 Payload: 9b 02 58 7d 01 80 00 f1 05 12 00 80 20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 33 44 06 14 00 80 f1 00 fe 80 00 00 00 00 00 00 00 00 00 ff fe 00 11 22 Dictionary: 20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 33 44 20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 11 22 16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00 copy: 0c 9b 02 58 7d 01 80 00 f1 05 12 00 80 ref(60): 20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 33 44 -> ref 101nssss 1 5/11nnnkkk 6 4: b5 f4 copy: 08 06 14 00 80 f1 00 fe 80 9 nulls: 87 ref(66): ff fe 00 11 22 -> ref 101nssss 0 7/11nnnkkk 3 5: a7 dd Compressed: 0c 9b 02 58 7d 01 80 00 f1 05 12 00 80 b5 f4 08 06 14 00 80 f1 00 fe 80 87 a7 dd Was 50 bytes; compressed to 27 bytes, compression factor 1.85
IP头：60 00 00 00 32 3a ff 20 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0020 02 0d b8 00 00 00 00 ff fe 00 11 22 16 fe fd 17 fe fd 00 01 00 00 00 00 00 00 00 00 00 00拷贝：0c 9b 02 58 7d 01 80 00 f1 05 12 00 00 80参考（60）：20 02 0d b8 00 00 00 00 00 ff fe 00 33 44->参考101nssss 1 5/11nnnkkk 6 4:b5 f4拷贝：08 06 14 00 80 f1 00 fe 80 9空白：87参考（66）：ff fe 00 11 22->参考101nssss 0 7/11nnnkkk 3 5:a7 dd压缩：0c 9b 02 58 7d 01 80 00 f1 05 12 00 80 b5 f4 08 06 14 00 80 f1 00 fe 80 87 a7 dd为50字节；压缩到27字节，压缩系数为1.85
Figure 10: A RPL DAO Message
图10:RPLDAO消息
Figure 11 shows the effect of compressing a simple ND neighbor solicitation.
图11显示了压缩简单ND邻居请求的效果。
IP header: 60 00 00 00 00 30 3a ff 20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 3b d3 fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23 Payload: 87 00 a7 68 00 00 00 00 fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23 01 01 3b d3 00 00 00 00 1f 02 00 00 00 00 00 06 00 1c da ff fe 00 20 24 Dictionary: 20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 3b d3 fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23 16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00 copy: 04 87 00 a7 68 4 nulls: 82 ref(40): fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23 -> ref 101nssss 1 3/11nnnkkk 6 0: b3 f0 copy: 04 01 01 3b d3 4 nulls: 82 copy: 02 1f 02 5 nulls: 83 copy: 02 06 00 ref(24): 1c da ff fe 00 -> ref 101nssss 0 2/11nnnkkk 3 3: a2 db copy: 02 20 24 Compressed: 04 87 00 a7 68 82 b3 f0 04 01 01 3b d3 82 02 1f 02 83 02 06 00 a2 db 02 20 24 Was 48 bytes; compressed to 26 bytes, compression factor 1.85
IP头：60 00 00 00 30 3a ff 20 02 0d b8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 300 300 300 300 300 300 300 300有效载荷：87 00 a7 68 00 00 00 00 00 00 fe 80 00 00 00 00 00 00 00 00 00 00 02 1c da ff 00 30 23 01 01 01 3b d3 00 00 00 00 00 00 00 00 1f 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1c da ff fe 00 20 24字典：20 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000 00 00 00 00 00 02 1c da ff fe 00 30 23 16 fe fd 17 fe fd 00 01 00 00 00 00 00 00 00 00 00 00 00拷贝：04 87 00 a7 68 4空份：82参考（40）：fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23->参考101nssss 1 3/11nnnkkk 6 0:b3 f0拷贝：04 01 3b d3 4空份：82拷贝：02 1f 02 5空份：83拷贝：02 06 00参考（24）：1c da ff fe 00->参考101nssss 0 2/11nnnkkk 3:a2 db复制：02 20 24压缩：04 87 00 a7 68 82 b3 f0 04 01 01 3b d3 82 02 1f 02 83 02 06 00 a2 db 02 20 24为48字节；压缩到26字节，压缩系数为1.85
Figure 11: An ND Neighbor Solicitation
图11:ND邻居请求
Figure 12 shows the compression of an ND neighbor advertisement.
图12显示了ND邻居广告的压缩。
IP header: 60 00 00 00 00 30 3a fe fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23 20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 3b d3 Payload: 88 00 26 6c c0 00 00 00 fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23 02 01 fa ce 00 00 00 00 1f 02 00 00 00 00 00 06 00 1c da ff fe 00 20 24 Dictionary: fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23 20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 3b d3 16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00 copy: 05 88 00 26 6c c0 3 nulls: 81 ref(56): fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23 -> ref 101nssss 1 5/11nnnkkk 6 0: b5 f0 copy: 04 02 01 fa ce 4 nulls: 82 copy: 02 1f 02 5 nulls: 83 copy: 02 06 00 ref(24): 1c da ff fe 00 -> ref 101nssss 0 2/11nnnkkk 3 3: a2 db copy: 02 20 24 Compressed: 05 88 00 26 6c c0 81 b5 f0 04 02 01 fa ce 82 02 1f 02 83 02 06 00 a2 db 02 20 24 Was 48 bytes; compressed to 27 bytes, compression factor 1.78
IP头：60 00 00 00 00 30 3a fe 80 00 00 00 00 00 00 00 02 1c da ff fe 00 30 23 20 02 0d b8 00 00 00 00 00 00 ff fe 00 3b d3有效载荷：88 00 26 6c C000 00 00 fe 80 00 00 00 00 00 00 00 00 00 02 1c da ff fe 00 30 23 02 01 fa ce 00 00 00 00 00 00 1f 02 00 00 00 00 00 00 00 00 06 1c da ff fe 00 20 24字典：fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23 20 020d b8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00：1c da ff fe 00->ref 101nssss 0 2/11nnnkkk 3:a2 db copy:02 20 24 Compressed:05 88 00 26 6c c0 81 b5 f0 04 02 01 fa ce 82 02 1f 02 83 02 06 00 a2 db 02 20 24为48字节；压缩到27字节，压缩系数1.78
Figure 12: An ND Neighbor Advertisement
图12:ND邻居广告
Figure 13 shows the compression of an ND router solicitation. Note that the relatively good compression is not caused by the many zero bytes in the link-layer address of this particular capture (which are unlikely to occur in practice): 7 of these 8 bytes are copied from the pseudo-header (the 8th byte cannot be copied, as the universal/ local bit needs to be inverted).
图13显示ND路由器请求的压缩。请注意，相对良好的压缩并不是由此特定捕获的链路层地址中的许多零字节造成的（这在实践中不太可能发生）：这8个字节中的7个是从伪报头复制的（无法复制第8个字节，因为需要反转通用/本地位）。
IP header: 60 00 00 00 00 18 3a ff fe 80 00 00 00 00 00 00 ae de 48 00 00 00 00 01 ff 02 00 00 00 00 00 00 00 00 00 00 00 00 00 02 Payload: 85 00 90 65 00 00 00 00 01 02 ac de 48 00 00 00 00 01 00 00 00 00 00 00 Dictionary: fe 80 00 00 00 00 00 00 ae de 48 00 00 00 00 01 ff 02 00 00 00 00 00 00 00 00 00 00 00 00 00 02 16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00 copy: 04 85 00 90 65 ref(11): 00 00 00 00 01 -> ref 11nnnkkk 3 6: de copy: 02 02 ac ref(50): de 48 00 00 00 00 01 -> ref 101nssss 0 5/11nnnkkk 5 3: a5 eb 6 nulls: 84 Compressed: 04 85 00 90 65 de 02 02 ac a5 eb 84 Was 24 bytes; compressed to 12 bytes, compression factor 2.00
IP头：60 00 00 00 18 3a ff fe 80 00 00 00 ae de 48 00 00 00 00 00 00 01 ff 02 00 00 00 00 00 02有效载荷：85 00 90 65 00 00 00 00 00 01 02 ac de 48 00 00 00 00 01 00 00 00 00 00字典：fe 80 00 00 00 00 00 00 ae de 48 00 00 00 00 00 01 ff 02 00 00 00 00 00 00 00 00 00 00 00 00 01 ff 02 00 00 00 00 00 00 00 00 00 02 16 fe fd 17 fe fd 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000 00 00 00 00 00拷贝：04 85 00 90 65 ref（11）：00 00 00 01->ref 11nnnkkk 3 6:反拷贝：02 02 ac ref（50）：de 48 00 00 00 00 01->ref 101nssss 0 5/11nnnkkk 5 3:a5 eb 6空值：84压缩：04 85 00 90 65 de 02 ac a5 eb 84为24字节；压缩到12字节，压缩系数为2.00
Figure 13: An ND Router Solicitation
图13:ND路由器请求
Figure 14 shows the compression of an ND router advertisement. The indefinite lifetime is compressed to four bytes by backreferencing; this could be improved (at the cost of minor additional decompressor complexity) by including some simple runlength mechanism.
图14显示ND路由器广告的压缩。通过反向引用将无限生存期压缩为四个字节；这可以通过包含一些简单的运行长度机制来改进（代价是额外的解压器复杂性较小）。
IP header:
60 00 00 00 00 60 3a ff fe 80 00 00 00 00 00 00
10 34 00 ff fe 00 11 22 fe 80 00 00 00 00 00 00
ae de 48 00 00 00 00 01
Payload:
86 00 55 c9 40 00 0f a0 1c 5a 38 17 00 00 07 d0
01 01 11 22 00 00 00 00 03 04 40 40 ff ff ff ff
ff ff ff ff 00 00 00 00 20 02 0d b8 00 00 00 00
00 00 00 00 00 00 00 00 20 02 40 10 00 00 03 e8
20 02 0d b8 00 00 00 00 21 03 00 01 00 00 00 00
20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 11 22
Dictionary:
fe 80 00 00 00 00 00 00 10 34 00 ff fe 00 11 22
fe 80 00 00 00 00 00 00 ae de 48 00 00 00 00 01
16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00
copy: 0c 86 00 55 c9 40 00 0f a0 1c 5a 38 17
2 nulls: 80
copy: 06 07 d0 01 01 11 22
4 nulls: 82
copy: 06 03 04 40 40 ff ff
ref(2): ff ff -> ref 11nnnkkk 0 0: c0
ref(4): ff ff ff ff -> ref 11nnnkkk 2 0: d0
4 nulls: 82
copy: 04 20 02 0d b8
12 nulls: 8a
copy: 04 20 02 40 10
ref(38): 00 00 03 -> ref 101nssss 0 4/11nnnkkk 1 3: a4 cb
copy: 01 e8
ref(24): 20 02 0d b8 00 00 00 00
-> ref 101nssss 0 2/11nnnkkk 6 0: a2 f0
copy: 02 21 03
ref(84): 00 01 00 00 00 00
-> ref 101nssss 0 9/11nnnkkk 4 6: a9 e6
ref(40): 20 02 0d b8 00 00 00 00 00 00 00
-> ref 101nssss 1 3/11nnnkkk 1 5: b3 cd
ref(128): ff fe 00 11 22
-> ref 101nssss 0 15/11nnnkkk 3 3: af db
Compressed:
0c 86 00 55 c9 40 00 0f a0 1c 5a 38 17 80 06 07
d0 01 01 11 22 82 06 03 04 40 40 ff ff c0 d0 82
04 20 02 0d b8 8a 04 20 02 40 10 a4 cb 01 e8 a2
f0 02 21 03 a9 e6 b3 cd af db
Was 96 bytes; compressed to 58 bytes, compression factor 1.66
IP header:
60 00 00 00 00 60 3a ff fe 80 00 00 00 00 00 00
10 34 00 ff fe 00 11 22 fe 80 00 00 00 00 00 00
ae de 48 00 00 00 00 01
Payload:
86 00 55 c9 40 00 0f a0 1c 5a 38 17 00 00 07 d0
01 01 11 22 00 00 00 00 03 04 40 40 ff ff ff ff
ff ff ff ff 00 00 00 00 20 02 0d b8 00 00 00 00
00 00 00 00 00 00 00 00 20 02 40 10 00 00 03 e8
20 02 0d b8 00 00 00 00 21 03 00 01 00 00 00 00
20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 11 22
Dictionary:
fe 80 00 00 00 00 00 00 10 34 00 ff fe 00 11 22
fe 80 00 00 00 00 00 00 ae de 48 00 00 00 00 01
16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00
copy: 0c 86 00 55 c9 40 00 0f a0 1c 5a 38 17
2 nulls: 80
copy: 06 07 d0 01 01 11 22
4 nulls: 82
copy: 06 03 04 40 40 ff ff
ref(2): ff ff -> ref 11nnnkkk 0 0: c0
ref(4): ff ff ff ff -> ref 11nnnkkk 2 0: d0
4 nulls: 82
copy: 04 20 02 0d b8
12 nulls: 8a
copy: 04 20 02 40 10
ref(38): 00 00 03 -> ref 101nssss 0 4/11nnnkkk 1 3: a4 cb
copy: 01 e8
ref(24): 20 02 0d b8 00 00 00 00
-> ref 101nssss 0 2/11nnnkkk 6 0: a2 f0
copy: 02 21 03
ref(84): 00 01 00 00 00 00
-> ref 101nssss 0 9/11nnnkkk 4 6: a9 e6
ref(40): 20 02 0d b8 00 00 00 00 00 00 00
-> ref 101nssss 1 3/11nnnkkk 1 5: b3 cd
ref(128): ff fe 00 11 22
-> ref 101nssss 0 15/11nnnkkk 3 3: af db
Compressed:
0c 86 00 55 c9 40 00 0f a0 1c 5a 38 17 80 06 07
d0 01 01 11 22 82 06 03 04 40 40 ff ff c0 d0 82
04 20 02 0d b8 8a 04 20 02 40 10 a4 cb 01 e8 a2
f0 02 21 03 a9 e6 b3 cd af db
Was 96 bytes; compressed to 58 bytes, compression factor 1.66
Figure 14: An ND Router Advertisement
图14:ND路由器广告
Figure 15 shows the compression of a DTLS application data packet with a net payload of 13 bytes of cleartext and 8 bytes of authenticator (note that the IP header is not relevant for this example and has been set to 0). This makes good use of the static dictionary and is quite effective crunching out the redundancy in the TLS_PSK_WITH_AES_128_CCM_8 header, leading to a net reduction by 15 bytes.
图15显示了DTLS应用程序数据包的压缩，净负载为13字节的明文和8字节的验证器（注意，IP报头与本例无关，已设置为0）。这很好地利用了静态字典，并且非常有效地使用_AES_128_CCM_8头消除了TLS_PSK_中的冗余，从而将净容量减少了15个字节。
IP header: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Payload: 17 fe fd 00 01 00 00 00 00 00 01 00 1d 00 01 00 00 00 00 00 01 09 b2 0e 82 c1 6e b6 96 c5 1f 36 8d 17 61 e2 b5 d4 22 d4 ed 2b Dictionary: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00 ref(13): 17 fe fd 00 01 00 00 00 00 00 01 00 -> ref 101nssss 1 0/11nnnkkk 2 1: b0 d1 copy: 01 1d ref(10): 00 01 00 00 00 00 00 01 -> ref 11nnnkkk 6 2: f2 copy: 15 09 b2 0e 82 c1 6e b6 96 c5 1f 36 8d 17 61 e2 copy: b5 d4 22 d4 ed 2b Compressed: b0 d1 01 1d f2 15 09 b2 0e 82 c1 6e b6 96 c5 1f 36 8d 17 61 e2 b5 d4 22 d4 ed 2b Was 42 bytes; compressed to 27 bytes, compression factor 1.56
IP头：00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000 00 00 00 00 16 fe fd 17 fe fd 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00->参考101nssss 1 0/11nnnkkk 2 1:b0 d1副本：01 1d参考（10）：00 01 00 00 00 01->参考11nnnkkk 6 2:f2副本：15 09 b2 0e 82 c1 6e b6 96 c5 1f 36 8d 17 61 e2副本：b5 d4 22 d4 ed 2b压缩：b0 d1 01 1d f2 15 09 b2 0e 82 c1 6e b6 96 c5 1f 36 8d 17 e2 b5 d4 22 d4 ed 2b为42字节；压缩到27字节，压缩系数为1.56
Figure 15: A DTLS Application Data Packet
图15:DTLS应用程序数据包
Figure 16 shows that the compression is slightly worse in a subsequent packet (containing 6 bytes of cleartext and 8 bytes of authenticator, yielding a net compression of 13 bytes). The total overhead does stay at a quite acceptable 8 bytes.
图16显示了压缩在随后的数据包中稍差一些（包含6字节的明文和8字节的验证器，产生了13字节的净压缩）。总开销保持在一个相当可接受的8字节。
IP header: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Payload: 17 fe fd 00 01 00 00 00 00 00 05 00 16 00 01 00 00 00 00 00 05 ae a0 15 56 67 92 4d ff 8a 24 e4 cb 35 b9 Dictionary: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00 ref(13): 17 fe fd 00 01 00 00 00 00 00 -> ref 101nssss 1 0/11nnnkkk 0 3: b0 c3 copy: 03 05 00 16 ref(10): 00 01 00 00 00 00 00 05 -> ref 11nnnkkk 6 2: f2 copy: 0e ae a0 15 56 67 92 4d ff 8a 24 e4 cb 35 b9 Compressed: b0 c3 03 05 00 16 f2 0e ae a0 15 56 67 92 4d ff 8a 24 e4 cb 35 b9 Was 35 bytes; compressed to 22 bytes, compression factor 1.59
IP头：00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 05 ae a0 15 56 67 92 4d ff 8a 24 e4 cb 35 b9字典：00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000 16 fe fd 17 fe fd 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00；压缩到22字节，压缩系数1.59
Figure 16: Another DTLS Application Data Packet
图16：另一个DTLS应用程序数据包
Figure 17 shows the compression of a DTLS handshake message, here a client hello. There is little that can be compressed about the 32 bytes of randomness. Still, the net reduction is by 14 bytes.
图17显示了DTLS握手消息的压缩，这里是客户机hello。对于32字节的随机性，几乎没有什么可以压缩的。不过，净减少了14个字节。
IP header: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Payload: 16 fe fd 00 00 00 00 00 00 00 00 00 36 01 00 00 2a 00 00 00 00 00 00 00 2a fe fd 51 52 ed 79 a4 20 c9 62 56 11 47 c9 39 ee 6c c0 a4 fe c6 89 2f 32 26 9a 16 4e 31 7e 9f 20 92 92 00 00 00 02 c0 a8 01 00 Dictionary: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00 ref(16): 16 fe fd -> ref 101nssss 0 1/11nnnkkk 1 5: a1 cd 9 nulls: 87 copy: 01 36 ref(16): 01 00 00 -> ref 101nssss 0 1/11nnnkkk 1 5: a1 cd copy: 01 2a 7 nulls: 85 copy: 23 2a fe fd 51 52 ed 79 a4 20 c9 62 56 11 47 c9 copy: 39 ee 6c c0 a4 fe c6 89 2f 32 26 9a 16 4e 31 7e copy: 9f 20 92 92 3 nulls: 81 copy: 05 02 c0 a8 01 00 Compressed: a1 cd 87 01 36 a1 cd 01 2a 85 23 2a fe fd 51 52 ed 79 a4 20 c9 62 56 11 47 c9 39 ee 6c c0 a4 fe c6 89 2f 32 26 9a 16 4e 31 7e 9f 20 92 92 81 05 02 c0 a8 01 00 Was 67 bytes; compressed to 53 bytes, compression factor 1.26
IP头：00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00字典：00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 16 fe fd 17 fe fd 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00：01 00 00->参考101nssss 0 1/11nnnkkk 1 5:a1 cd副本：01 2a 7空份：85副本：23 2a fe fd 51 52 ed 79 a4 20 c9 62 56 11 47 c9副本：39 ee 6c c0 a4 fe c6 89 2f 32 26 9a 16 4e 31 7e副本：9f 20 92 3空份：81副本：05 02 c0 a8 01 00压缩：a1 cd 87 01 36 a1 cd 01 2a 85 23 fe fd 51 52 ed 79 a4 20 c9 62 56 11 47 c9 39 ee 6c c0 a4 fe c689 2f 32 26 9a 16 4e 31 7e 9f 20 92 92 81 05 02 c0 a8 01 00为67字节；压缩到53字节，压缩系数1.26
Figure 17: A DTLS Handshake Packet (Client Hello)
图17:DTLS握手包（客户端Hello）
Acknowledgements
致谢
Colin O'Flynn has repeatedly insisted that some form of compression for ICMPv6 and ND packets might be beneficial. He actually wrote his own document, [ICMPv6-ND], which compresses better, but that document only addresses basic ICMPv6/ND and needs a much longer specification (around 17 pages of detailed specification, as compared to the single page of core specification here). This motivated the author to try something simple, yet general. Special thanks go to Colin for indicating that he indeed considers his document superseded by this one.
科林·奥弗林反复强调，对ICMPv6和ND数据包进行某种形式的压缩可能是有益的。实际上，他编写了自己的文档[ICMPv6 ND]，压缩性更好，但该文档只涉及基本的ICMPv6/ND，需要更长的规范（与这里的单页核心规范相比，详细规范大约有17页）。这促使作者尝试一些简单但通用的方法。特别感谢科林表示，他确实认为他的文件已被本文件取代。
The examples given are based on packet capture files that Colin O'Flynn, Owen Kirby, Olaf Bergmann, and others provided.
给出的示例基于Colin O'Flynn、Owen Kirby、Olaf Bergmann和其他人提供的包捕获文件。
Using these files as a corpus, the static dictionary was developed, and the bit allocations validated, based on research by Sebastian Dominik.
根据Sebastian Dominik的研究，使用这些文件作为语料库，开发了静态词典，并验证了位分配。
Erik Nordmark provided input that helped shape the 6CIO. Thomas Bjorklund proposed simplifying the predefined dictionary.
Erik Nordmark提供了帮助塑造6CIO的信息。Thomas Bjorklund建议简化预定义词典。
Yoshihiro Ohba insisted on clarifying the notation used for the definition of the bytecodes and their bitfields. Ulrich Herberg provided some additional review and suggested expanding the introductory material, and with Hannes Tschofenig and Brian Haberman he helped come up with the IANA policy for the "6LoWPAN capability bits" assignments in the 6CIO.
大叶吉弘坚持澄清字节码及其位域定义所用的符号。Ulrich Herberg提供了一些额外的评论，并建议扩展介绍性材料，与Hannes Tschofenig和Brian Haberman一起，他帮助制定了IANA政策，用于6CIO中的“6LoWPAN能力bits”任务。
The IESG reviewers Richard Barnes and Stephen Farrell contributed topics to the Security Considerations section; they and Barry Leiba, as well as GEN-ART reviewer Vijay K. Gurbani, also provided editorial improvements.
IESG评审员Richard Barnes和Stephen Farrell为安全考虑部分提供了主题；他们和Barry Leiba以及GEN-ART评论家Vijay K.Gurbani也提供了编辑改进。
Author's Address
作者地址
Carsten Bormann Universitaet Bremen TZI Postfach 330440 D-28359 Bremen Germany
德国不来梅卡斯滕·鲍曼大学邮政学院330440 D-28359
Phone: +49-421-218-63921
EMail: cabo@tzi.org
Phone: +49-421-218-63921
EMail: cabo@tzi.org