[要約] RFC 7400は、6LoWPANsでのIPv6のための汎用ヘッダ圧縮（GHC）に関する規格です。このRFCの目的は、低消費電力のワイヤレス個人エリアネットワークでのIPv6通信の効率を向上させることです。
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：低電力ワイヤレスパーソナルエリアネットワーク（6LoWPAN）を介した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 over Low-Power Wireless Personal Area Network」を指します）。このドキュメントでは、新しいヘッダーまたはヘッダーのようなペイロードごとに新しいヘッダー圧縮スキームを定義する必要なく、一般的なヘッダーおよびヘッダーのようなペイロードの圧縮を可能にする単純な追加を指定します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
[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 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].
現在の貢献の目的は、そのNext Header Compression（NHC）コンセプトを使用して、そのまま[RFC6282]にプラグインすることです。少し効率的ではありませんが、非常に一般的な、あらゆる種類のヘッダーの圧縮形式を追加します。ルーティングプロトコルやDHCPなどが示すようなヘッダーのようなペイロードの場合も同様です。一般的なヘッダー圧縮（GHC）。目的は、[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].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの "は、RFC 2119 [RFC2119]で説明されているように解釈されます。
The term "byte" is used in its now-customary sense as a synonym for "octet".
「バイト」という用語は、今では慣習的な意味で「オクテット」の同義語として使用されています。
Terms from [RFC7228] are used in Section 5.
[RFC7228]の用語は、セクション5で使用されています。
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を表し、これらのコードバイトテンプレートの変数セグメントを表します。は、kkkkkkkやssssなどの同じ文字のシーケンスで示され、その長さは可変セグメントの長さをビットで示します。
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は最上位ビット優先表記で2進数を表現するための接頭辞として使用されます（Cで最上位桁優先の16進数に0xを使用するのと同様）プログラミング言語）。次に、上記の文字列がテキスト内のそのような2進数で参照される場合、実際のコードバイトのこれらのビットフィールドからの値が挿入されることが意図されています。
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で始まり（最上位ビットが最初）、5つの変数ビットで始まるバイトを表します。最初のビットは「n」として参照され、次の4つは参照されます「ssss」として。このコードバイトテンプレートに基づいて、
0b0ssss000
0b0ssss000
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.
ゼロビットから構成される2進数を意味します。同じ順序で保持される、検出された実際のバイトの「sssss」フィールドにある4つのビット（101nssssの場合、4つの最下位ビット）。さらに3つのゼロビット。
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圧縮ヘッダーまたはペイロードの形式は、単純なバイトコードです。圧縮されたヘッダーは、一連の断片で構成され、各断片はコードバイトで始まり、その後に引数として0個以上のバイトが続く場合があります。一部のコードバイトは、バイトを宛先バッファーに配置するものもあれば、単にいくつかの解凍変数を変更するものもあります。
At the start of decompressing a header or payload within an L2 packet (= fragment), the decompression variables "sa" and "na" are initialized as zero.
L2パケット（=フラグメント）内のヘッダーまたはペイロードの圧縮解除の開始時に、圧縮解除変数「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 | |
+----------+---------------------------------------------+----------+
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 inシルバー17 inシルバー01 00 00 00 00 00 01 00 00
Figure 1: The 16 Bytes of Static Dictionary (in Hex)
図1：16バイトの静的辞書（16進数）
6LoWPAN-GHC plugs in as an NHC format for 6LoWPAN-HC [RFC6282].
6LoWPAN-GHCは、6LoWPAN-HC [RFC6282]のNHC形式としてプラグインします。
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パケット用です。 GHCに基づいてICMPv6のNHC形式を定義するには、単一の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.
また、UDPにはヘッダーのようなペイロード（DHCPv6、データグラムトランスポート層セキュリティ（DTLS）など）が多数含まれているため、UDPにNHC形式を含めると便利です。 [RFC6282]はすでにUDP（11110CPP）のNHC形式を定義しています。 GHCは、図2に示すようにフォーマットされた類似のNHCバイトを使用します。既存のUDP NHC仕様との違いは、11010CPP NHCバイトの場合、UDPペイロードは文字どおりではなく、6LoWPAN-GHCによって圧縮されることです。
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).
同じ一般的な番号付けスペースに留まるために、ICMPv6 GHCのNHCバイトとして11011111を使用します（図3）。
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のNHCバイト（11011111）
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 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.
特定の拡張ヘッダーの圧縮も同様の方法で追加されます（図4）（ただし、拡張ヘッダーID（EID）0〜3 [RFC6282]のみを割り当てる必要がある可能性があります）。デコードする前にGHCエンコードされたヘッダーからLengthフィールドを抽出する簡単な方法がないので、これは拡張ヘッダーの終わりを検出することを幾分複雑にするでしょう。最も簡単な（そして最も効率的な）アプローチは、Lengthフィールドを完全に省略し（特定のケースでNHCが次のヘッダーフィールドをすでに除外しているのと同じ方法で）、解凍時にのみ再構築することです。拡張ヘッダーのターミネーターとして機能するために、バイトコード0b10010000がストップコードとして割り当てられています。停止コードは拡張ヘッダーにのみ必要であり、前のサブセクションで説明した最終ペイロードでは必要ないことに注意してください。その解凍はパケットの終わりで自動的に停止されます。
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ノードがネイバーがGHCを実装していることを認識する必要があります。これは単に管理上必要な場合もありますが、移行戦略と混合ネットワークをサポートする方法が必要です。
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を実装していることを確認する1つの方法は、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]への影響を最小限に抑えるため、図5に示すように、6LoWPAN機能表示オプション（6CIO）と呼ばれる近隣探索（ND）オプションを定義します（図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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|_______________________________________________________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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圧縮パケットをそのノードに送信できます。その機能が最近確認されていない場合、Packetization Layer Path MTU Discovery（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]に切り替える必要があります（SHOULD）。
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の下線でマークされたビットは割り当てられておらず、将来の割り当てに使用できます。それらは0として送信されなければならず、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ヘッダータイプ」レジストリ（「IPv6低電力パーソナルエリアネットワークパラメーター」の下）の図6にリストされている割り当てを追加しました。
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は、「インターネット制御メッセージプロトコルバージョン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).
もう1つの考慮事項は、攻撃者が偽造パケットを送信して、2番目のノードに3番目の犠牲ノードがGHC対応であると信じ込ませる可能性があることです。そうでない場合、これにより、2番目のノードから送信されたパケットが3番目のノードに到達できなくなる可能性があります（少なくともセクション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スキームと同様に、解凍爆弾（圧縮器が過負荷になるほど拡大するように作成された圧縮パケット）が問題です。攻撃者は、MTUにすぐに到達するため、GHCデコンプレッサを長い間タイトループに送ることはできません。ただし、圧縮されたリンク内からの攻撃を増幅することは可能です。ただし、制約付きネットワーク内の制約付きノードを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 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.
反射を取得する方法がある場合は、6LoWPAN内で増幅がより重要になる可能性があります（そうしないと、パケットが途中で圧縮されたままになり、ほとんどダメージを与えない可能性があります）。そのノードがping応答を再圧縮しないようにします（これは、単純なゼロの実行よりも複雑なものが必要になるため、最悪の場合の増幅はおそらく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、「Neighbor Discovery for IP version 6（IPv6）」、RFC 4861、2007年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。、クシャルナガル、N。、ホイ、J。、およびD.キュラー、「IEEE 802.15.4ネットワーク上のIPv6パケットの送信」、RFC 4944、2007年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、「RFCで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 6282、2011年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]シェルビー、Z。、チャクラバルティ、S。、ノードマーク、E。、およびC.ボーマン、「低電力ワイヤレスパーソナルエリアネットワーク（6LoWPAN）を介したIPv6のネイバー探索最適化」、RFC 6775、2012年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。、「ICMPv6 / ND Compression for 6LoWPAN Networks」、Work in Progress、draft-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 Transactions on Information Theory、Vol。 23、No。3、pp。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 Compressed Data Format Specification version 1.3」、RFC 1951、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。、福島、H.、Hannu、H.、Jonsson、LE。、Hakenberg、R.、Koren、T.、Le、K.、Liu、 Z.、Martensson、A。、宮崎、A.、Svanbro、K.、Wiebke、T。、吉村、T。、およびH. Zheng、「RObust Header Compression（ROHC）：Framework and 4 profiles：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、「Packetization Layer Path MTU Discovery」、RFC 4821、2007年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。ジョンソン、「RObustヘッダー圧縮（ROHC）フレームワーク」、RFC 5795、2010年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.、Thubert、P.、Brandt、A.、Hui、J.、Kelsey、R.、Levis、P.、Pister、K.、Struik、R.、Vasseur、JP、およびR 。Alexander、「RPL：低電力および損失の多いネットワーク用のIPv6ルーティングプロトコル」、RFC 6550、2012年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.、and A. Keranen、 "Terminology for Constrained-Node Networks"、RFC 7228、May 2014、<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 Roadmap and Implementation Guide」、Work in Progress、draft-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）を示しています。
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 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ペイロード：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 00 00 00 00 00 00 1a 16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00コピー：04 9b 00 6b de 4ヌル：82圧縮：04 9b 00 6b de 82 Was 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
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 Destination Advertisement Object（DAO）メッセージを示しています。埋め込まれたアドレスの1つは、疑似ヘッダーから直接コピーされます。もう1つは、接頭辞FE80を文字どおりに指定し、多数のnullを挿入し、インターフェース識別子部分（の一部）を疑似ヘッダーから再度コピーすることにより、グローバルからローカルに効果的に変換されます。単純な実装では、nullが少なくなり、インターフェイス識別子全体がコピーされることに注意してください。この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 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ペイロード：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辞書：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圧縮：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：RPL DAOメッセージ
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 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ペイロード：87 00 a7 68 00 00 00 00 fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23 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辞書：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 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 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ペイロード：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 00 1f 02 00 00 00 00 00 06 00 1c da ff fe 00 20 24辞書：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コピー：02 1f 02 5 nulls：83コピー：02 06 00 ref（24）：1c da ff fe 00-> ref 101nssss 0 2 / 11nnnkkk 3 3：a2 dbコピー：02 20 24圧縮：05 88 00 26 6c c0 81 b5 f0 04 02 01面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 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ペイロード：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; 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ルーター通知の圧縮を示しています。無期限のライフタイムは、後方参照によって4バイトに圧縮されます。これは、いくつかの単純なランレングスメカニズムを含めることによって（デコンプレッサの追加の複雑さを少し犠牲にして）改善することができます。
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は、13バイトのクリアテキストと8バイトのオーセンティケーターのネットペイロードを持つDTLSアプリケーションデータパケットの圧縮を示しています（IPヘッダーはこの例には関係なく、0に設定されています）。これは静的ディクショナリをうまく利用し、TLS_PSK_WITH_AES_128_CCM_8ヘッダーの冗長性を非常に効果的に処理することで、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ペイロード：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辞書：00 00 00 00 00 00 00 00 00 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コピー：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 61 e2 b5 d4 22 d4 ed 2b Was 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ペイロード：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辞書：00 00 00 00 00 00 00 00 00 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コピー：03 05 00 16 ref（10）：00 01 00 00 00 00 00 05-> ref 11nnnkkk 6 2：f2コピー：0e ae a0 15 56 67 92 4d ff 8a 24 e4 cb 35 b9圧縮：b0 c3 03 05 00 16 f2 0e ae a0 15 56 67 92 4d ff 8a 24 e4 cb 35 b9 35バイトでした。 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ハンドシェイクメッセージの圧縮を示しています。 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ペイロード：16 fe fd 00 00 00 00 00 00 00 00 00 36 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辞書：00 00 00 00 00 00 00 00 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コピー：9f 20 92 92 3ヌル：81コピー：05 02 c0 a8 01 00圧縮：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バイト; 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.
Colin O'Flynnは、ICMPv6とNDパケットの何らかの形式の圧縮が有益であるかもしれないと繰り返し主張しました。彼は実際に独自のドキュメント[ICMPv6-ND]を書いており、圧縮率は高くなっていますが、そのドキュメントは基本的なICMPv6 / NDのみを扱っており、はるかに長い仕様が必要です（ここに記載されているコア仕様の1ページに比べて、約17ページの詳細仕様） ）。これが著者に、シンプルでありながら一般的な何かを試す動機を与えました。 Colinがこのドキュメントに取って代わったドキュメントを実際に検討していることを示してくれたColinに特に感謝します。
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.
これらのファイルをコーパスとして使用して、静的辞書が開発され、ビット割り当てが検証されました。これは、セバスチャンドミニクによる研究に基づいています。
Erik Nordmark provided input that helped shape the 6CIO. Thomas Bjorklund proposed simplifying the predefined dictionary.
エリックノードマークは、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と共に、6CIOの「6LoWPAN機能ビット」割り当てに関するIANAポリシーの策定を支援しました。
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
カルステンボルマンブレーメン大学TZI PO Box 330440 D-28359ブレーメンドイツ
Phone: +49-421-218-63921
EMail: cabo@tzi.org