Internet Engineering Task Force (IETF) J. Hui, Ed.
Request for Comments: 6282 Arch Rock Corporation
Updates: 4944 P. Thubert
Category: Standards Track Cisco
ISSN: 2070-1721 September 2011
Compression Format for IPv6 Datagrams
over IEEE 802.15.4-Based Networks
Abstract
抽象
This document updates RFC 4944, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks". This document specifies an IPv6 header compression format for IPv6 packet delivery in Low Power Wireless Personal Area Networks (6LoWPANs). The compression format relies on shared context to allow compression of arbitrary prefixes. How the information is maintained in that shared context is out of scope. This document specifies compression of multicast addresses and a framework for compressing next headers. UDP header compression is specified within this framework.
このドキュメントの更新RFC 4944、「IEEE 802.15.4ネットワークの上のIPv6パケットのトランスミッション」。この文書では、低消費電力無線パーソナルエリアネットワーク（6LoWPANs）におけるIPv6パケットの配信のためのIPv6ヘッダー圧縮形式を指定します。圧縮フォーマットは、任意のプレフィックスの圧縮を可能にする共有コンテキストに依存しています。情報がその共有コンテキスト内で維持されているどの範囲外です。この文書では、マルチキャストアドレスの圧縮と次のヘッダを圧縮するためのフレームワークを指定します。 UDPヘッダ圧縮は、このフレームワーク内で指定されています。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6282.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6282で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Requirements Language ......................................4
2. Specific Updates to RFC 4944 ....................................4
3. IPv6 Header Compression .........................................5
3.1. LOWPAN_IPHC Encoding Format ................................6
3.1.1. Base Format .........................................6
3.1.2. Context Identifier Extension .......................10
3.2. IPv6 Header Encoding ......................................11
3.2.1. Traffic Class and Flow Label Compression ...........11
3.2.2. Deriving IIDs from the Encapsulating Header ........12
3.2.3. Stateless Multicast Address Compression ............13
3.2.4. Stateful Multicast Address Compression .............14
4. IPv6 Next Header Compression ...................................15
4.1. LOWPAN_NHC Format .........................................15
4.2. IPv6 Extension Header Compression .........................15
4.3. UDP Header Compression ....................................17
4.3.1. Compressing UDP Ports ..............................17
4.3.2. Compressing UDP Checksum ...........................18
4.3.3. UDP LOWPAN_NHC Format ..............................20
5. IANA Considerations ............................................20
6. Security Considerations ........................................21
7. Acknowledgements ...............................................22
8. References .....................................................22
8.1. Normative References ......................................22
8.2. Informative References ....................................23
The [IEEE802.15.4] standard specifies an MTU of 127 bytes, yielding about 80 octets of actual Media Access Control (MAC) payload with security enabled, on a wireless link with a link throughput of 250 kbps or less. The 6LoWPAN adaptation format [RFC4944] was specified to carry IPv6 datagrams over such constrained links, taking into account limited bandwidth, memory, or energy resources that are expected in applications such as wireless sensor networks. [RFC4944] defines a Mesh Addressing header to support sub-IP forwarding, a Fragmentation header to support the IPv6 minimum MTU requirement [RFC2460], and stateless header compression for IPv6 datagrams (LOWPAN_HC1 and LOWPAN_HC2) to reduce the relatively large IPv6 and UDP headers down to (in the best case) several bytes.
【IEEE802.15.4]標準は、250 kbpsの以下のリンクスループットとの無線リンク上で、有効なセキュリティと実際のメディアアクセス制御（MAC）ペイロードの約80オクテットを得、127バイトのMTUを指定します。 6LoWPAN適応フォーマット[RFC4944]は、無線センサネットワークのような用途に期待されているアカウント制限された帯域幅、メモリ、またはエネルギー資源を考慮して、そのような拘束リンク上でIPv6データグラムを運ぶために指定されました。 [RFC4944]は、比較的大きなIPv6およびUDPヘッダーを低減するためにIPv6データグラム（LOWPAN_HC1とLOWPAN_HC2）ためのサブIP転送、IPv6の最小MTU要件[RFC2460]をサポートするために、断片化ヘッダ、およびステートレスヘッダ圧縮をサポートするために、メッシュアドレッシングヘッダを定義します（最良の場合）いくつかのバイトまで。
LOWPAN_HC1 and LOWPAN_HC2 are insufficient for most practical uses of IPv6 in 6LoWPANs. LOWPAN_HC1 is most effective for link-local unicast communication, where IPv6 addresses carry the link-local prefix and an Interface Identifier (IID) directly derived from IEEE 802.15.4 addresses. In this case, both addresses may be completely elided. However, though link-local addresses are commonly used for local protocol interactions such as IPv6 Neighbor Discovery [RFC4861], DHCPv6 [RFC3315], or routing protocols, they are usually not used for application-layer data traffic, so the actual value of this compression mechanism is limited.
LOWPAN_HC1とLOWPAN_HC2は6LoWPANsでのIPv6の最も実用的な用途には不十分です。 LOWPAN_HC1は、IPv6アドレスがリンクローカル接頭辞と直接IEEE 802.15.4アドレスから誘導インタフェース識別子（IID）を運ぶリンクローカルユニキャスト通信のための最も効果的です。この場合、両方のアドレスが完全に省略されてもよいです。リンクローカルアドレスは、一般に、IPv6の近隣探索[RFC4861]、DHCPv6の[RFC3315]、またはルーティングプロトコルとしてローカルプロトコル相互作用のために使用しているがしかし、それらは通常、アプリケーション層のデータトラフィックのために使用されるので、この実際の値がされていません圧縮機構は限られています。
Routable addresses must be used when communicating with devices external to the 6LoWPAN or in a route-over configuration where IP forwarding occurs within the 6LoWPAN. For routable addresses, LOWPAN_HC1 requires both IPv6 source and destination addresses to carry the prefix in-line. In cases where the Mesh Addressing header is not used, the IID of a routable address must be carried in-line. However, LOWPAN_HC1 requires 64 bits for the IID when carried in-line and cannot be shortened even when it is derived from the IEEE 802.15.4 16-bit short address. When the destination is an IPv6 multicast address, LOWPAN_HC1 requires the full 128-bit address to be carried in-line.
6LoWPANまたはIP転送が6LoWPAN内で発生ルート上の構成で、外部機器との通信時にルーティング可能なアドレスを使用しなければなりません。ルーティング可能なアドレスの場合、LOWPAN_HC1は、インラインプレフィックスを運ぶためのIPv6送信元と宛先の両方のアドレスが必要です。メッシュアドレッシングヘッダは使用されない場合には、ルーティング可能なアドレスのIIDは、インライン実行されなければなりません。しかし、LOWPAN_HC1はインライン行う場合IIDのために64ビットを必要とし、それはIEEE 802.15.4 16ビットのショートアドレスから導出された場合であっても短くすることができません。宛先がIPv6マルチキャストアドレスである場合、LOWPAN_HC1はインライン搬送される完全な128ビットのアドレスを必要とします。
As a result, this document defines an encoding format, LOWPAN_IPHC, for effective compression of Unique Local, Global, and multicast IPv6 Addresses based on shared state within contexts. In addition, this document also introduces a number of additional improvements over the header compression format defined in [RFC4944].
結果として、この文書は、コンテキスト内の共有状態に基づいて一意のローカル、グローバル、およびマルチキャストIPv6アドレスの有効な圧縮のために、符号化形式、LOWPAN_IPHCを定義します。また、この文書はまた、[RFC4944]で定義されたヘッダ圧縮フォーマットに対する追加の改良の数を導入します。
LOWPAN_IPHC allows for compression of some commonly used IPv6 Hop Limit values. If the 6LoWPAN is a mesh-under stub, a Hop Limit of 1 for inbound and a default value such as 64 for outbound are usually enough for application-layer data traffic. Additionally, a Hop Limit value of 255 is often used to verify that a communication occurs over a single-hop. This specification enables compression of the IPv6 Hop Limit field in those common cases, whereas LOWPAN_HC1 does not.
LOWPAN_IPHCは、いくつかの一般的に使用されるIPv6のホップ制限値を圧縮することができます。 6LoWPANがある場合は、メッシュの下スタブ、インバウンドのための1のホップ制限およびアウトバウンドのデフォルト値など64は、通常はアプリケーション層のデータトラフィックのために十分です。また、255のホップ制限値は、多くの場合、通信がシングルホップにわたって起こることを確認するために使用されます。 LOWPAN_HC1がないのに対し、この仕様は、これらの一般的なケースでのIPv6ホップリミットフィールドの圧縮を可能にします。
This document also defines LOWPAN_NHC, an encoding format for arbitrary next headers. LOWPAN_IPHC indicates whether the following header is encoded using LOWPAN_NHC. If so, the bits immediately following the compressed IPv6 header start the LOWPAN_NHC encoding. In contrast, LOWPAN_HC1 could be extended to support compression of next headers using LOWPAN_HC2, but only for UDP, TCP, and ICMPv6. Furthermore, the LOWPAN_HC2 octet sits between the LOWPAN_HC1 octet and uncompressed IPv6 header fields. This specification moves the next header encoding bits to follow all IPv6-related bits, allowing for a properly layered structure and direct support for IPv6 extension headers.
この文書はまたLOWPAN_NHC、任意の次のヘッダの符号化フォーマットを定義します。 LOWPAN_IPHCは、以下のヘッダはLOWPAN_NHCを使用して符号化されるかどうかを示します。もしそうであれば、直ちに圧縮IPv6ヘッダーの次のビットはLOWPAN_NHCエンコードを開始します。これとは対照的に、LOWPAN_HC1はなく、唯一のUDP、TCP、およびICMPv6のため、LOWPAN_HC2を使用して、次のヘッダーの圧縮をサポートするように拡張することができます。また、LOWPAN_HC2オクテットはLOWPAN_HC1オクテットと非圧縮のIPv6ヘッダフィールドの間に位置します。この仕様は、IPv6拡張ヘッダのために適切に層状構造と直接サポートを可能にする、すべてのIPv6関連のビットに追従するようにビットを符号化する次のヘッダを移動させます。
Using LOWPAN_NHC, this document defines a compression mechanism for UDP. While [RFC4944] defines a compression mechanism for UDP, that mechanism does not enable checksum compression when rendered possible by additional upper-layer mechanisms such as upper-layer Message Integrity Check (MIC). This specification adds the capability to elide the UDP checksum over the 6LoWPAN, which enables saving of a further two octets.
LOWPAN_NHCを使用して、この文書では、UDPのための圧縮機構を定義します。 [RFC4944]はUDPの圧縮機構を定義しながら、このような上位層メッセージ完全性チェック（MIC）のような追加の上層機構によって可能レンダリングするとき、その機構は、チェックサム圧縮を可能にしません。この仕様は、さらに2つのオクテットの節約を可能に6LoWPAN、上のUDPチェックサムをElideのための機能を追加します。
Also, using LOWPAN_NHC, this document defines encoding formats for IPv6-in-IPv6 encapsulation as well as IPv6 Extension Headers. With LOWPAN_HC1 and LOWPAN_HC2, chains of next headers cannot be encoded efficiently.
また、LOWPAN_NHCを使用して、この文書は、IPv6インのIPv6カプセル化ならびにIPv6拡張ヘッダの符号化フォーマットを定義します。 LOWPAN_HC1とLOWPAN_HC2では、次のヘッダーのチェーンを効率的に符号化することはできません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
This document specifies a header compression format that is intended to replace that defined in Section 10 of [RFC4944]. Implementation of Section 10 of [RFC4944] is now NOT RECOMMENDED. New implementations MAY implement decompression according to Section 10 of [RFC4944] but SHOULD NOT send packets compressed according to Section 10 of [RFC4944].
このドキュメントは[RFC4944]のセクション10で定義されていることを置き換えることを意図しているヘッダー圧縮形式を指定します。 [RFC4944]のセクション10の実装は現在推奨されていません。新しい実装は、[RFC4944]のセクション10に応じて解凍を実装するかもしれませんが、[RFC4944]のセクション10に応じて圧縮されたパケットを送信することはできません。
A compliant implementation of [RFC4944] as updated by this document MUST be able to properly process a packet received that makes use of the provisions of this document. A compliant implementation MAY implement additional LOWPAN_NHC types (Section 4) that may be
このドキュメントによって更新として、[RFC4944]の準拠した実装が正しくそれは、この文書の条項を利用して受信したパケットを処理できなければなりません。準拠した実装であってもよい追加LOWPAN_NHCタイプ（第4章）を実装してもよい（MAY）
registered (Section 5) in the future. It is out of scope of this document how a compressor learns that a decompressor has additional capabilities.
将来的に登録された（第5節）。これは、コンプレッサーがデコンプレッサが追加機能を持っていることを知る方法この文書の範囲外です。
Section 5.3 of [RFC4944] also defines how to fragment compressed IPv6 datagrams that do not fit within a single link frame. Section 5.3 of [RFC4944] defines the fragment header's datagram_size and datagram_offset values as the size and offset of the IPv6 datagram before compression. As a result, all fragment payload outside the first fragment must carry their respective portions of the IPv6 datagram before compression. This document does not change that requirement. When using the fragmentation mechanism described in Section 5.3 of [RFC4944], any header that cannot fit within the first fragment MUST NOT be compressed.
[RFC4944]の5.3節では、単一リンクフレーム内に収まらない圧縮されたIPv6データグラムを断片化する方法を定義します。 [RFC4944]のセクション5.3は、フラグメントヘッダのdatagram_sizeとdatagram_offset値サイズとして、圧縮前のIPv6データグラムのオフセットを定義します。その結果、最初のフラグメント外部全てのフラグメントペイロードは、圧縮前のIPv6データグラムのそれぞれの部分を運ばなければなりません。この文書では、その要件を変更しません。 [RFC4944]のセクション5.3に記載の断片化メカニズムを使用する場合、最初のフラグメント内に収まらない任意のヘッダを圧縮してはいけません。
The header compression format defined in this document preempts the ESC dispatch value defined in Section 5.1 of [RFC4944]. Instead, the value of 01 000000 is reserved as a replacement value for ESC, to be finally assigned with the first assignment of extension bytes.
この文書で定義されたヘッダ圧縮フォーマットは、[RFC4944]のセクション5.1で定義されたESCディスパッチ値をプリエンプト。代わりに、01 000000の値は、最終的に拡張バイトの最初の割り当てと割り当てられる、ESCの代替値として予約されています。
In this section, we define the LOWPAN_IPHC encoding format for compressing the IPv6 header. To enable effective compression, LOWPAN_IPHC relies on information pertaining to the entire 6LoWPAN. LOWPAN_IPHC assumes the following will be the common case for 6LoWPAN communication: Version is 6; Traffic Class and Flow Label are both zero; Payload Length can be inferred from lower layers from either the 6LoWPAN Fragmentation header or the IEEE 802.15.4 header; Hop Limit will be set to a well-known value by the source; addresses assigned to 6LoWPAN interfaces will be formed using the link-local prefix or a small set of routable prefixes assigned to the entire 6LoWPAN; addresses assigned to 6LoWPAN interfaces are formed with an IID derived directly from either the 64-bit extended or the 16-bit short IEEE 802.15.4 addresses.
このセクションでは、我々は、IPv6ヘッダを圧縮するためのLOWPAN_IPHC符号化フォーマットを定義します。効果的な圧縮を有効にするには、LOWPAN_IPHCは全体6LoWPANに関連する情報に依存しています。 LOWPAN_IPHC以下は6LoWPAN通信のための一般的なケースであろう前提：バージョン6です。トラフィッククラスとフローラベルは共にゼロであり、ペイロード長は、6LoWPANフラグメンテーションヘッダーまたはIEEE 802.15.4ヘッダのいずれかから下位層から推論することができます。ホップリミット源によって周知の値に設定されます。 6LoWPANインターフェースに割り当てられたアドレスがリンクローカル接頭辞または全体6LoWPANに割り当てられたルーティング可能なプレフィックスの小さなセットを用いて形成されます。 IIDは直接由来で6LoWPANインターフェースに割り当てられたアドレスが形成されているいずれかの拡張64ビットまたは16ビットのショートIEEE 802.15.4アドレス。
+-------------------------------------+----------------------------
| Dispatch + LOWPAN_IPHC (2-3 octets) | In-line IPv6 Header Fields
+-------------------------------------+----------------------------
Figure 1: LOWPAN_IPHC Header
図1：LOWPAN_IPHCヘッダー
The LOWPAN_IPHC encoding utilizes 13 bits, 5 of which are taken from the rightmost bits of the dispatch type. The encoding may be extended by another octet to support additional contexts. Any information from the uncompressed IPv6 header fields carried in-line follow the LOWPAN_IPHC encoding, as shown in Figure 1. In the best case, the LOWPAN_IPHC can compress the IPv6 header down to two octets (the dispatch octet and the LOWPAN_IPHC encoding) with link-local communication.
LOWPAN_IPHC符号化は、発信型の右端のビットから取られる5そのうち13ビットを利用します。符号化は、追加のコンテキストをサポートするために、別のオクテットによって拡張することができます。最良の場合には、図1に示すように、ライン担持非圧縮のIPv6ヘッダフィールドからの情報は、LOWPAN_IPHCエンコードに従う、LOWPAN_IPHCリンクとダウン2つのオクテット（ディスパッチオクテットとLOWPAN_IPHC符号化）にIPv6ヘッダを圧縮することができ-local通信。
When routing over multiple IP hops, LOWPAN_IPHC can compress the IPv6 header down to 7 octets (1-octet dispatch, 1-octet LOWPAN_IPHC, 1-octet Hop Limit, 2-octet Source Address, and 2-octet Destination Address). The Hop Limit may not be compressed because it needs to decremented at each hop and may take any value. Stateful address compression must be applied to the source and destination IPv6 addresses because they do not statelessly match the source and destination link-layer addresses on intermediate hops.
複数のIPホップにわたってルーティングするとき、LOWPAN_IPHCダウン7つのオクテット（1オクテットディスパッチ、1オクテットLOWPAN_IPHC、1オクテットのホップリミット、2オクテットのソースアドレス、及び2オクテットの宛先アドレス）にIPv6ヘッダを圧縮することができます。ホップ制限は、それが各ホップで減算する必要があるため、圧縮されず、任意の値をとることがあります。彼らはステートレス中間ホップの送信元と宛先のリンク層アドレスと一致しないためステートフルアドレス圧縮は、IPv6アドレス、送信元と宛先に適用されなければなりません。
This section specifies the format of the LOWPAN_IPHC encoding that describes how an IPv6 header is compressed. The encoding can be 2 octets long for the base encoding or 3 octets long when an additional context encoding is present. The IPv6 header fields that are not fully elided are placed immediately after the LOWPAN_IPHC, either in a compressed form if the field is partially elided or literally.
このセクションでは、IPv6ヘッダーが圧縮されている方法について説明LOWPAN_IPHCエンコードのフォーマットを指定します。追加のコンテキスト符号化が存在する場合の符号化は、2つの長いベース符号化のためのオクテットまたは3つのオクテット長とすることができます。フィールドの一部が省略さ文字通りまたはれている場合、完全に省略されていないIPv6ヘッダーフィールドは、いずれかの圧縮形式で、LOWPAN_IPHC直後に配置されています。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 0 | 1 | 1 | TF |NH | HLIM |CID|SAC| SAM | M |DAC| DAM |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 2: LOWPAN_IPHC base Encoding
図2：LOWPAN_IPHCベースエンコーディング
TF: Traffic Class, Flow Label: As specified in [RFC3168], the 8-bit IPv6 Traffic Class field is split into two fields: 2-bit Explicit Congestion Notification (ECN) and 6-bit Differentiated Services Code Point (DSCP).
TF：トラフィッククラス、フローラベルは、2ビットの明示的輻輳通知（ECN）と6ビットの差別化サービスコードポイント（DSCP）：[RFC3168]で指定されるように、8ビットのIPv6のトラフィッククラスフィールドは2つのフィールドに分割されます。
00: ECN + DSCP + 4-bit Pad + Flow Label (4 bytes)
00：ECN + DSCP + 4ビットのパッド+フローラベル（4バイト）
01: ECN + 2-bit Pad + Flow Label (3 bytes), DSCP is elided.
01：ECN + 2ビットのパッド+フローラベル（3バイト）、DSCPが省略されています。
10: ECN + DSCP (1 byte), Flow Label is elided.
10：ECN + DSCP（1バイト）、フローラベルが省略されています。
11: Traffic Class and Flow Label are elided.
11：トラフィッククラスとフローラベルが省略されています。
NH: Next Header:
NH：次のヘッダー：
0: Full 8 bits for Next Header are carried in-line.
0：次のヘッダーの完全な8ビットは、インラインで行われます。
1: The Next Header field is compressed and the next header is encoded using LOWPAN_NHC, which is discussed in Section 4.1.
1：次のヘッダーフィールドが圧縮され、次のヘッダは、セクション4.1で説明されLOWPAN_NHCを使用して符号化されます。
HLIM: Hop Limit:
ハリム：ホップリミット：
00: The Hop Limit field is carried in-line.
00：ホップリミットフィールドは、インラインで行われます。
01: The Hop Limit field is compressed and the hop limit is 1.
01：ホップリミットフィールドは圧縮され、ホップ限界は1です。
10: The Hop Limit field is compressed and the hop limit is 64.
10：ホップリミットフィールドは圧縮され、ホップ限界は64です。
11: The Hop Limit field is compressed and the hop limit is 255.
11：ホップ制限フィールドが圧縮され、ホップ制限は255です。
CID: Context Identifier Extension:
CID：コンテキスト識別子拡張子：
0: No additional 8-bit Context Identifier Extension is used. If context-based compression is specified in either Source Address Compression (SAC) or Destination Address Compression (DAC), context 0 is used.
0：追加の8ビット・コンテキスト識別子拡張が使用されません。コンテキストベースの圧縮がソースアドレス圧縮（SAC）または宛先アドレスのコンプレッション（DAC）のいずれかで指定されている場合、コンテキスト0が使用されています。
1: An additional 8-bit Context Identifier Extension field immediately follows the Destination Address Mode (DAM) field.
1：追加の8ビット・コンテキスト識別子Extensionフィールドは直ちに宛先アドレスモード（DAM）フィールドに続きます。
SAC: Source Address Compression
SAC：ソースアドレス圧縮
0: Source address compression uses stateless compression.
0：ソースアドレス圧縮は、ステートレス圧縮を使用しています。
1: Source address compression uses stateful, context-based compression.
1：ソースアドレス圧縮は、ステートフル、コンテキストベースの圧縮を使用しています。
SAM: Source Address Mode:
SAM：ソースアドレスモード：
If SAC=0:
SAC = 0の場合：
00: 128 bits. The full address is carried in-line.
00：128ビット。完全なアドレスは、インラインで行われます。
01: 64 bits. The first 64-bits of the address are elided. The value of those bits is the link-local prefix padded with zeros. The remaining 64 bits are carried in-line.
01：64ビット。アドレスの最初の64ビットは省略されています。これらのビットの値がゼロで埋めリンクローカル接頭辞です。残りの64ビットは、インラインで行われます。
10: 16 bits. The first 112 bits of the address are elided. The value of the first 64 bits is the link-local prefix padded with zeros. The following 64 bits are 0000:00ff: fe00:XXXX, where XXXX are the 16 bits carried in-line.
10：16ビット。アドレスの最初の112ビットは省略されています。最初の64ビットの値がゼロで埋めリンクローカル接頭辞です。 00FF：FE00：XXXX、XXXXはインライン運ば16ビットである次の64ビットは0000です。
11: 0 bits. The address is fully elided. The first 64 bits of the address are the link-local prefix padded with zeros. The remaining 64 bits are computed from the encapsulating header (e.g., 802.15.4 or IPv6 source address) as specified in Section 3.2.2.
11：0ビット。アドレスは完全に省略されています。アドレスの最初の64ビットはゼロで埋めリンクローカル接頭辞です。残りの64ビットは、セクション3.2.2で指定されるようにカプセル化ヘッダ（例えば、802.15.4またはIPv6ソースアドレス）から計算されます。
If SAC=1:
SAC = 1の場合：
00: The UNSPECIFIED address, ::
00：未指定アドレス、::
01: 64 bits. The address is derived using context information and the 64 bits carried in-line. Bits covered by context information are always used. Any IID bits not covered by context information are taken directly from the corresponding bits carried in-line. Any remaining bits are zero.
01：64ビット。アドレスは、コンテキスト情報とインラインで行わ64ビットを使用して導出されます。コンテキスト情報によってカバーされたビットが常に使用されます。コンテキスト情報によって覆われていない任意のIIDビットはインラインで行わ対応するビットから直接取得されます。任意の残りのビットはゼロです。
10: 16 bits. The address is derived using context information and the 16 bits carried in-line. Bits covered by context information are always used. Any IID bits not covered by context information are taken directly from their corresponding bits in the 16-bit to IID mapping given by 0000:00ff:fe00:XXXX, where XXXX are the 16 bits carried in-line. Any remaining bits are zero.
10：16ビット。アドレスは、コンテキスト情報とインラインで行わ16ビットを用いて導出されます。コンテキスト情報によってカバーされたビットが常に使用されます。 00FF：FE00：XXXXはインライン運ば16ビットであるXXXX、コンテキスト情報によって覆われていない任意のIIDビットは0000で与えられるIIDへのマッピング16ビットの対応するビットから直接取られます。任意の残りのビットはゼロです。
11: 0 bits. The address is fully elided and is derived using context information and the encapsulating header (e.g., 802.15.4 or IPv6 source address). Bits covered by context information are always used. Any IID bits not covered by context information are computed from the encapsulating header as specified in Section 3.2.2. Any remaining bits are zero.
11：0ビット。アドレスは、完全に省略されている、コンテキスト情報及びカプセル化ヘッダ（例えば、802.15.4またはIPv6ソースアドレス）を使用して導出されます。コンテキスト情報によってカバーされたビットが常に使用されます。コンテキスト情報によって覆われていない任意のIIDビットはセクション3.2.2で指定されるようにカプセル化ヘッダから計算されます。任意の残りのビットはゼロです。
M: Multicast Compression
M：マルチキャスト圧縮
0: Destination address is not a multicast address.
0：宛先アドレスがマルチキャストアドレスではありません。
1: Destination address is a multicast address.
1：宛先アドレスがマルチキャストアドレスです。
DAC: Destination Address Compression
DAC：宛先アドレスの圧縮
0: Destination address compression uses stateless compression.
0：デスティネーションアドレス圧縮は、ステートレス圧縮を使用しています。
1: Destination address compression uses stateful, context-based compression.
1：デスティネーションアドレス圧縮は、ステートフル、コンテキストベースの圧縮を使用しています。
DAM: Destination Address Mode:
DAM：デスティネーションアドレスモード：
If M=0 and DAC=0 This case matches SAC=0 but for the destination address:
M = 0とDAC = 0この場合は、SAC = 0と一致するが、宛先アドレスの場合：
00: 128 bits. The full address is carried in-line.
00：128ビット。完全なアドレスは、インラインで行われます。
01: 64 bits. The first 64-bits of the address are elided. The value of those bits is the link-local prefix padded with zeros. The remaining 64 bits are carried in-line.
01：64ビット。アドレスの最初の64ビットは省略されています。これらのビットの値がゼロで埋めリンクローカル接頭辞です。残りの64ビットは、インラインで行われます。
10: 16 bits. The first 112 bits of the address are elided. The value of the first 64 bits is the link-local prefix padded with zeros. The following 64 bits are 0000:00ff: fe00:XXXX, where XXXX are the 16 bits carried in-line.
10：16ビット。アドレスの最初の112ビットは省略されています。最初の64ビットの値がゼロで埋めリンクローカル接頭辞です。 00FF：FE00：XXXX、XXXXはインライン運ば16ビットである次の64ビットは0000です。
11: 0 bits. The address is fully elided. The first 64 bits of the address are the link-local prefix padded with zeros. The remaining 64 bits are computed from the encapsulating header (e.g., 802.15.4 or IPv6 destination address) as specified in Section 3.2.2.
11：0ビット。アドレスは完全に省略されています。アドレスの最初の64ビットはゼロで埋めリンクローカル接頭辞です。残りの64ビットは、セクション3.2.2で指定されるようにカプセル化ヘッダ（例えば、802.15.4またはIPv6宛先アドレス）から計算されます。
If M=0 and DAC=1:
M = 0の場合とDAC = 1：
00: Reserved.
00：予約済み。
01: 64 bits. The address is derived using context information and the 64 bits carried in-line. Bits covered by context information are always used. Any IID bits not covered by context information are taken directly from the corresponding bits carried in-line. Any remaining bits are zero.
01：64ビット。アドレスは、コンテキスト情報とインラインで行わ64ビットを使用して導出されます。コンテキスト情報によってカバーされたビットが常に使用されます。コンテキスト情報によって覆われていない任意のIIDビットはインラインで行わ対応するビットから直接取得されます。任意の残りのビットはゼロです。
10: 16 bits. The address is derived using context information and the 16 bits carried in-line. Bits covered by context information are always used. Any IID bits not covered by context information are taken directly from their corresponding bits in the 16-bit to IID mapping given by 0000:00ff:fe00:XXXX, where XXXX are the 16 bits carried in-line. Any remaining bits are zero.
10：16ビット。アドレスは、コンテキスト情報とインラインで行わ16ビットを用いて導出されます。コンテキスト情報によってカバーされたビットが常に使用されます。 00FF：FE00：XXXXはインライン運ば16ビットであるXXXX、コンテキスト情報によって覆われていない任意のIIDビットは0000で与えられるIIDへのマッピング16ビットの対応するビットから直接取られます。任意の残りのビットはゼロです。
11: 0 bits. The address is fully elided and is derived using context information and the encapsulating header (e.g. 802.15.4 or IPv6 destination address). Bits covered by context information are always used. Any IID bits not covered by context information are computed from the encapsulating header as specified in Section 3.2.2. Any remaining bits are zero.
11：0ビット。アドレスは、完全に省略されている、コンテキスト情報及びカプセル化ヘッダ（例えば802.15.4またはIPv6宛先アドレス）を使用して導出されます。コンテキスト情報によってカバーされたビットが常に使用されます。コンテキスト情報によって覆われていない任意のIIDビットはセクション3.2.2で指定されるようにカプセル化ヘッダから計算されます。任意の残りのビットはゼロです。
If M=1 and DAC=0:
M = 1の場合とDAC = 0：
00: 128 bits. The full address is carried in-line.
00：128ビット。完全なアドレスは、インラインで行われます。
01: 48 bits. The address takes the form ffXX::00XX:XXXX:XXXX.
01：48ビット。アドレスは、フォームffXXを取ります:: 00XX：XXXX：XXXX。
10: 32 bits. The address takes the form ffXX::00XX:XXXX.
10：32ビット。 XXXX：アドレスは、フォームffXX :: 00XXをとります。
11: 8 bits. The address takes the form ff02::00XX.
11：8ビット。アドレスの形式は、FF02 :: 00XXをとります。
If M=1 and DAC=1:
M = 1の場合とDAC = 1：
00: 48 bits. This format is designed to match Unicast-Prefix-based IPv6 Multicast Addresses as defined in [RFC3306] and [RFC3956]. The multicast address takes the form ffXX:XXLL: PPPP:PPPP:PPPP:PPPP:XXXX:XXXX. where the X are the nibbles that are carried in-line, in the order in which they appear in this format. P denotes nibbles used to encode the prefix itself. L denotes nibbles used to encode the prefix length. The prefix information P and L is taken from the specified context.
00：48ビット。このフォーマットは、[RFC3306]及び[RFC3956]で定義されるようにユニキャストプレフィックスベースのIPv6マルチキャストアドレスと一致するように設計されています。マルチキャストアドレスは、フォームffXXを取ります。XXLL：PPPP：PPPP：PPPP：PPPP：XXXX：XXXX。ここで、Xは、彼らがこの形式で表示されている順序で、インラインで運ばれるニブルです。 Pは、プレフィックス自体を符号化するために使用されるニブルを表します。 Lは、プレフィックス長を符号化するために使用されるニブルを表します。プレフィックス情報P及びLは、指定したコンテキストから取り出されます。
01: reserved
01：予約済み
10: reserved
10：予約済み
11: reserved
11：予約済み
This specification expects that a conceptual context is shared between the node that compresses a packet and the node(s) that needs to expand it. How the contexts are shared and maintained is out of scope. What information is contained within a context information is out of scope. Actions in response to unknown and/or invalid contexts are out of scope. The specification enables a node to use up to 16 contexts. The context used to encode the source address does not have to be the same as the context used to encode the destination address.
この仕様は、概念的なコンテキストは、パケットとそれを展開する必要があるノードを圧縮するノードとの間で共有されることを期待します。コンテキストが共有され、維持されているどの範囲外です。コンテキスト情報に含まれるどのような情報が範囲外です。不明なおよび/または無効なコンテキストに応じたアクションは適用範囲外です。仕様は、16のコンテキストまで使用するノードを可能にします。送信元アドレスを符号化するために使用されるコンテキストは、宛先アドレスを符号化するために使用されるコンテキストと同じである必要はありません。
If the CID field is set to '1' in the LOWPAN_IPHC encoding, then an additional octet extends the LOWPAN_IPHC encoding following the DAM bits but before the IPv6 header fields that are carried in-line. The additional octet identifies the pair of contexts to be used when the IPv6 source and/or destination address is compressed. The context identifier is 4 bits for each address, supporting up to 16 contexts. Context 0 is the default context. The encoding is shown in Figure 3.
CIDフィールドはLOWPAN_IPHCエンコーディングで「1」に設定されている場合、追加のオクテットは、DAMビット以下LOWPAN_IPHCエンコーディングを延びるが、インライン運ばれるIPv6ヘッダフィールドの前に。追加のオクテットは、IPv6ソースおよび/または宛先アドレスが圧縮されるときに使用するコンテキストの組を識別する。コンテキスト識別子は、16のコンテキストまでサポート、各アドレスの4ビットです。コンテキスト0デフォルトコンテキストです。符号化は、図3に示されています。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| SCI | DCI |
+---+---+---+---+---+---+---+---+
Figure 3: LOWPAN_IPHC Encoding
図3：LOWPAN_IPHCエンコーディング
SCI: Source Context Identifier. Identifies the prefix that is used when the IPv6 source address is statefully compressed.
SCI：ソースコンテキスト識別子。 IPv6送信元アドレスがステートフルに圧縮されているときに使用される接頭辞を指定します。
DCI: Destination Context Identifier. Identifies the prefix that is used when the IPv6 destination address is statefully compressed.
DCI：デスティネーションコンテキスト識別子。 IPv6宛先アドレスがステートフルに圧縮されているときに使用される接頭辞を指定します。
Fields carried in-line (in part or in whole) appear in the same order as they do in the IPv6 header format [RFC2460]. The Version field is always elided. Unicast IPv6 addresses may be compressed to 64 or 16 bits or completely elided. Multicast IPv6 addresses may be compressed to 8, 32, or 48 bits. The IPv6 Payload Length field MUST always be elided and inferred from lower layers using the 6LoWPAN Fragmentation header or the IEEE 802.15.4 header.
それらはIPv6ヘッダのフォーマット[RFC2460]にそうであるように（部分的にまたは全体的に）インライン実施フィールドが同じ順序で現れます。バージョンフィールドは常に省略されています。ユニキャストIPv6アドレスは、64ビットまたは16ビットに圧縮又は完全に省略されてもよいです。マルチキャストIPv6アドレスは、8、32、または48ビットに圧縮することができます。 IPv6のペイロード長フィールドは常に省略さと6LoWPANフラグメンテーションヘッダまたはIEEE 802.15.4ヘッダを使用して、下位層から推測されなければなりません。
The Traffic Class field in the IPv6 header comprises 6 bits of Diffserv extension [RFC2474] and 2 bits of Explicit Congestion Notification (ECN) [RFC3168]. The TF field in the LOWPAN_IPHC encoding indicates whether the Traffic Class and Flow Label are carried in-line in the compressed IPv6 header. When Flow Label is included while the Traffic Class is compressed, an additional 4 bits are included to maintain byte alignment. Two of the 4 bits contain the ECN bits from the Traffic Class field.
IPv6ヘッダーのトラフィッククラスフィールドは、Diffservの拡張の6ビット[RFC2474]と明示的輻輳通知（ECN）[RFC3168]の2ビットを含みます。 LOWPAN_IPHC符号化におけるTFフィールドは、トラフィッククラスとフローラベルは、インライン圧縮IPv6ヘッダで運ばれるかどうかを示します。トラフィッククラスが圧縮されながら、フローラベルが含まれている場合、追加の4ビットは、バイト整列を維持するために含まれます。 4ビットの二つは、トラフィッククラスフィールドからECNビットが含まれています。
To ensure that the ECN bits appear in the same location for all encodings that include them, the Traffic Class field is rotated right by 2 bits in the compressed IPv6 header. The encodings are shown below:
ECNビットがそれらを含むすべてのエンコーディングのための同じ位置に現れることを保証するために、トラフィッククラスフィールドは圧縮されたIPv6ヘッダ内の2ビット右に回転させられます。エンコーディングは以下のとおりです。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ECN| DSCP | rsv | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: TF = 00: Traffic Class and Flow Label carried in-line
図4：TF = 00：トラフィッククラスとフローラベルはインライン運ば
1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ECN|rsv| Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: TF = 01: Flow Label carried in-line
図5：TFは= 01：インライン運ばフローラベル
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|ECN| DSCP |
+-+-+-+-+-+-+-+-+
Figure 6: TF = 10: Traffic Class carried in-line
図6：TF = 10：トラフィッククラスは、インライン運ば
LOWPAN_IPHC elides the IIDs of source or destination addresses when SAM = 3 or DAM = 3, respectively. In this mode, the IID is derived from the encapsulating header. When the encapsulating header carries IPv6 addresses, bits for the source and destination addresses are copied from the source and destination addresses of the encapsulating IPv6 header.
場合SAM = 3又はDAM = 3 LOWPAN_IPHCは、それぞれ、送信元または宛先アドレスのIIDをelides。このモードでは、IIDは、カプセル化ヘッダから導出されます。カプセル化ヘッダは、IPv6アドレスを有する場合、送信元および宛先アドレスのビットは、カプセル化IPv6ヘッダの送信元アドレスと宛先アドレスからコピーされます。
The remainder of this section defines the mapping from IEEE 802.15.4 [IEEE802.15.4] link-layer addresses to IIDs for both short and extended IEEE 802.15.4 addresses. IID bits not covered by the context information MAY be elided if they match the link-layer address mapping and MUST NOT be elided if they do not.
このセクションの残りの部分は短く、拡張IEEE 802.15.4アドレスの両方のためのIIDにIEEE 802.15.4 [IEEE802.15.4]リンク層アドレスのマッピングを定義します。コンテキスト情報によってカバーされていないIIDビットは、彼らがリンク層アドレスのマッピングが一致した場合に省略されるかもしれないし、そうでない場合は省略されてはなりません。
An extended IEEE 802.15.4 address takes the form of an IEEE EUI-64 address. Generating an IID from an extended address is identical to that defined in Appendix A of [RFC4291]. The only change needed to transform an IEEE EUI-64 identifier to an interface identifier is to invert the universal/local bit.
拡張されたIEEE 802.15.4アドレスは、IEEE EUI-64アドレスの形をとります。拡張アドレスからIIDを生成する[RFC4291]の付録Aで定義されたものと同一です。インタフェース識別子にIEEE EUI-64識別子を変換するために必要な唯一の変更は、ユニバーサル/ローカルビットを反転させることです。
A short IEEE 802.15.4 address is 16 bits in length. Short addresses are mapped into the restricted space of IEEE EUI-64 addresses by setting the middle 16 bits to 0xfffe, the bottom 16 bits to the short address, and all other bits to zero. As a result, an IID generated from a short address has the form:
短いIEEE 802.15.4アドレスは、長さが16ビットです。ショートアドレスは0xFFFEというする中央16ビット、短いアドレスを下位16ビットと、ゼロに他のすべてのビットを設定することにより、IEEE EUI-64アドレスの制限された空間にマッピングされます。結果として、短いアドレスから生成されたIIDの形式を有します。
0000:00ff:fe00:XXXX
0000：00FF：FE00：XXXX
where XXXX carries the short address. The universal/local bit is zero to indicate local scope.
どこXXXXは短いアドレスを運びます。ユニバーサル/ローカルビットは、ローカルスコープを示すためにゼロです。
This mapping for non-EUI-64 identifiers differs from that presented in Appendix A of [RFC4291]. Using the restricted space ensures no overlap with IIDs generated from unrestricted IEEE EUI-64 addresses. Also, including 0xfffe in the middle of the IID helps avoid overlap with other locally managed IIDs.
非EUI-64識別子のこのマッピングは、[RFC4291]の付録Aに提示とは異なります。限られたスペースを使用すると、無制限のIEEE EUI-64アドレスから生成されたIIDとの重複を保証しません。また、IIDの真ん中に含め0xFFFEという、他のローカル管理のIIDとの重複を避けることができます。
This mapping from a short IEEE 802.15.4 address to 64-bit IIDs is also used to reconstruct any part of an IID not covered by context information.
短いIEEE 802.15.4アドレスから64ビットのIIDにこのマッピングは、コンテキスト情報によって覆われていないIIDの任意の部分を再構成するためにも使用されます。
LOWPAN_IPHC supports stateless compression of multicast addresses when M = 1 and DAC = 0. An IPv6 multicast address may be compressed down to 48, 32, or 8 bits using stateless compression. The format supports compression of the Solicited-Node Multicast Address (ff02:: 1:ffXX:XXXX) as well as any IPv6 multicast address where the upper bits of the multicast group identifier are zero. The 8-bit compressed form only carries the least-significant bits of the multicast group identifier. The 48- and 32-bit compressed forms carry the multicast scope and flags in-line, in addition to the least-significant bits of the multicast group identifier.
LOWPAN_IPHCマルチキャストアドレスのステートレス圧縮をサポートする場合、M = 1、DAC = 0アンIPv6マルチキャストアドレスは、48、32、またはステートレス圧縮を使用して8ビットまで圧縮することができます。マルチキャストグループ識別子の上位ビットがゼロであるだけでなく、任意のIPv6マルチキャストアドレスフォーマットは、要請ノードマルチキャストアドレス（XXXX：ffXX FF02 :: 1）の圧縮をサポートします。 8ビットの圧縮された形は、マルチキャストグループ識別子の最下位ビットを運びます。 48-及び32ビットの圧縮された形態は、マルチキャストグループ識別子の最下位ビットに加えて、インラインマルチキャストスコープとフラグを運びます。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Scope | Group Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: DAM = 01. 48-bit Compressed Multicast Address
(ffFS::00GG:GGGG:GGGG)
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Scope | Group Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: DAM = 10. 32-bit Compressed Multicast Address
(ffFS::00GG:GGGG)
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Group ID |
+-+-+-+-+-+-+-+-+
Figure 9: DAM = 11. 8-bit Compressed Multicast Address (ff02::GG)
図9：DAM = 11. 8ビットの圧縮マルチキャストアドレス（FF02 :: GG）
LOWPAN_IPHC supports stateful compression of multicast addresses when M = 1 and DAC = 1. This document currently defines DAM = 00: context-based compression of Unicast-Prefix-based IPv6 Multicast Addresses [RFC3306][RFC3956]. In particular, the Prefix Length and Network Prefix can be taken from a context. As a result, LOWPAN_IPHC can compress a Unicast-Prefix-based IPv6 Multicast Address down to 6 octets by only carrying the 4-bit Flags, 4-bit Scope, 8-bit Rendezvous Point Interface ID (RIID), and 32-bit Group Identifier in-line.
ユニキャストプレフィックスベースのIPv6マルチキャストアドレス[RFC3306]、[RFC3956]のコンテキスト・ベースの圧縮：M = 1、DAC = 1。この文書は、現在DAM 00 =定義するときLOWPAN_IPHCは、マルチキャストアドレスのステートフルな圧縮をサポートします。具体的には、プレフィックス長とネットワークプレフィックスは、コンテキストから取り出すことができます。結果として、LOWPAN_IPHCのみ、4ビットの範囲、8ビットのランデブーポイントインタフェースID（RIID）、及び32ビットのグループ4ビットフラグを実施することによってダウン6つのオクテットのユニキャストプレフィックスベースのIPv6マルチキャストアドレスを圧縮することができインライン型の識別子。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Scope | Rsvd / RIID | Group Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: DAM = 00. Unicast-Prefix-based IPv6 Multicast
Address Compression
Note that the Reserved field MUST carry the reserved bits from the multicast address format as described in [RFC3306]. When a Rendezvous Point is encoded in the multicast address as described in [RFC3956], the Reserved field carries the RIID bits in-line.
[RFC3306]で説明されるようReservedフィールドは、マルチキャストアドレスフォーマットから予約ビットを搬送しなければならないことに留意されたいです。 [RFC3956]に記載されているようにランデブーポイントは、マルチキャストアドレスに符号化された場合、Reservedフィールドは、インラインRIIDビットを運びます。
LOWPAN_IPHC elides the IPv6 Next Header field when the NH bit is set to 1. This also indicates the use of 6LoWPAN next header compression, LOWPAN_NHC. The value of IPv6 Next Header is recovered from the first bits in the LOWPAN_NHC encoding. The following bits are specific to the IPv6 Next Header value. Figure 11 shows the structure of an IPv6 datagram compressed using LOWPAN_IPHC and LOWPAN_NHC.
LOWPAN_IPHCはNHビットが1に設定されているときも6LoWPAN次ヘッダ圧縮、LOWPAN_NHCの使用を示しているIPv6の次ヘッダフィールドをelides。 IPv6の次のヘッダの値をLOWPAN_NHC符号化における最初のビットから回収されます。次のビットは、IPv6の次ヘッダ値に固有です。図11は、LOWPAN_IPHCとLOWPAN_NHCを使用して圧縮IPv6データグラムの構造を示しています。
+-------------+-------------+-------------+-----------------+--------
| LOWPAN_IPHC | In-line | LOWPAN_NHC | In-line Next | Payload
| Encoding | IP Fields | Encoding | Header Fields |
+-------------+-------------+-------------+-----------------+--------
Figure 11: Typical LOWPAN_IPHC/LOWPAN_NHC Header Configuration
図11：一般的なLOWPAN_IPHC / LOWPAN_NHCヘッダーの設定
Compression formats for different next headers are identified by a variable-length bit-pattern immediately following the LOWPAN_IPHC compressed header. When defining a next header compression format, the number of bits used SHOULD be determined by the perceived frequency of using that format. However, the number of bits and any remaining encoding bits SHOULD respect octet alignment. The following bits are specific to the next header compression format. This document defines a compression format for IPv6 Extension and UDP headers.
異なる次のヘッダの圧縮形式を直ちにLOWPAN_IPHC圧縮ヘッダ次の可変長ビット・パターンによって同定されます。次のヘッダ圧縮フォーマットを定義する場合、使用されるビットの数は、その形式を使用しての知覚される周波数によって決定されるべきです。しかしながら、ビット数及び任意の残りの符号化ビットは、オクテット整列を尊重すべきです。次のビットは、次のヘッダ圧縮フォーマットに特異的です。この文書は、IPv6拡張およびUDPヘッダの圧縮形式を定義します。
+----------------+---------------------------
| var-len NHC ID | compressed next header...
+----------------+---------------------------
Figure 12: LOWPAN_NHC Encoding
図12：LOWPAN_NHCエンコーディング
A necessary property of encoding headers using LOWPAN_NHC is that the immediately preceding header must be encoded using either LOWPAN_IPHC or LOWPAN_NHC. In other words, all headers encoded using the 6LoWPAN encoding format defined in this document must be contiguous. As a result, this document defines a set of LOWPAN_NHC encodings for selected IPv6 Extension Headers such that the UDP Header Compression defined in Section 4.3 may be used in the presence of those extension headers.
LOWPAN_NHCを用いた符号化ヘッダの必要性は、直前のヘッダがLOWPAN_IPHC又はLOWPAN_NHCのいずれかを使用して符号化されなければならないということです。換言すれば、本文書で定義された6LoWPAN符号化フォーマットを使用してエンコードすべてのヘッダは連続でなければなりません。結果として、この文書は、セクション4.3で定義されたUDPヘッダ圧縮は、これらの拡張ヘッダの存在下で使用することができるように選択されたIPv6拡張ヘッダのためLOWPAN_NHCエンコーディングのセットを定義します。
The LOWPAN_NHC encodings for IPv6 Extension Headers are composed of a single LOWPAN_NHC octet followed by the IPv6 Extension Header. The format of the LOWPAN_NHC octet is shown in Figure 13. The first 7 bits serve as an identifier for the IPv6 Extension Header immediately following the LOWPAN_NHC octet. The remaining bit indicates whether or not the following header utilizes LOWPAN_NHC encoding.
IPv6拡張ヘッダのためLOWPAN_NHCエンコーディングは、IPv6拡張ヘッダに続く単一LOWPAN_NHCオクテットで構成されています。 LOWPAN_NHCオクテットの形式は、最初の7ビットは直ちにLOWPAN_NHCオクテット以下のIPv6拡張ヘッダの識別子として働く図13に示されています。残りのビットは、次のヘッダはLOWPAN_NHC符号化を利用するか否かを示します。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 | 1 | 1 | 0 | EID |NH |
+---+---+---+---+---+---+---+---+
Figure 13: IPv6 Extension Header Encoding
図13：IPv6拡張ヘッダのエンコーディング
EID: IPv6 Extension Header ID:
EID：IPv6拡張ヘッダーID：
0: IPv6 Hop-by-Hop Options Header [RFC2460]
0：IPv6のホップバイホップオプションヘッダ[RFC2460]
1: IPv6 Routing Header [RFC2460]
1：IPv6ルーティングヘッダ[RFC2460]
2: IPv6 Fragment Header [RFC2460]
2：IPv6のフラグメントヘッダ[RFC2460]
3: IPv6 Destination Options Header [RFC2460]
3：IPv6宛先オプションヘッダー[RFC2460]
4: IPv6 Mobility Header [RFC6275]
4：IPv6のモビリティヘッダ[RFC6275]
5: Reserved
5：リザーブ
6: Reserved
6：予約済み
7: IPv6 Header
7：IPv6のヘッダー
NH: Next Header:
NH：次のヘッダー：
0: Full 8 bits for Next Header are carried in-line.
0：次のヘッダーの完全な8ビットは、インラインで行われます。
1: The Next Header field is elided and the next header is encoded using LOWPAN_NHC, which is discussed in Section 4.1.
1：次のヘッダーフィールドが省略され、次のヘッダは、セクション4.1で説明されLOWPAN_NHCを使用して符号化されます。
For the most part, the IPv6 Extension Header is carried unmodified in the bytes immediately following the LOWPAN_NHC octet, with two important exceptions: Length field and Next Header field.
Lengthフィールドと次ヘッダフィールド：ほとんどの部分については、IPv6拡張ヘッダーは、2つの重要な例外を除いて、すぐにLOWPAN_NHCオクテット以下のバイト単位でそのまま行われます。
The Next Header field contained in IPv6 Extension Headers is elided when the NH bit is set in the LOWPAN_NHC encoding octet. Note that doing so allows LOWPAN_NHC to utilize no more overhead than the non-encoded IPv6 Extension Header.
NHビットがLOWPAN_NHCエンコードオクテットに設定されている場合IPv6拡張ヘッダに含まれる次ヘッダフィールドが省略されています。そうすることLOWPAN_NHCが非エンコードIPv6拡張ヘッダーよりも多くのオーバーヘッドを利用しないことを可能にすることに注意してください。
The Length field contained in a compressed IPv6 Extension Header indicates the number of octets that pertain to the (compressed) extension header following the Length field. Note that this changes the Length field definition in [RFC2460] from indicating the header size in 8-octet units, not including the first 8 octets. Changing the Length field to be in units of octets removes wasteful internal fragmentation.
圧縮されたIPv6拡張ヘッダに含まれるLengthフィールドは、Lengthフィールド以下（圧縮）拡張ヘッダに関連するオクテットの数を示します。これは最初の8つのオクテットを含まない、8オクテット単位でヘッダサイズを示すから、[RFC2460]の長さフィールド定義を変更することに留意されたいです。オクテット単位であることをLengthフィールドを変更すると、無駄な内部断片を削除します。
IPv6 Hop-by-Hop and Destination Options Headers may use a trailing Pad1 or PadN to achieve 8-octet alignment. When there is a single trailing Pad1 or PadN option of 7 octets or less and the containing header is a multiple of 8 octets, the trailing Pad1 or PadN option MAY be elided by the compressor. A decompressor MUST ensure that the containing header is padded out to a multiple of 8 octets in length, using a Pad1 or PadN option if necessary. Note that Pad1 and PadN options that appear in locations other than the end MUST be carried in-line as they are used to align subsequent options.
IPv6のホップバイホップおよび宛先オプションヘッダは、8オクテット整列を達成するために、後続のパッド1又はパッドNを使用してもよいです。そこ7つのオクテット以下の単一末尾パッド1又はパッドNオプションであり、含むヘッダが8つのオクテットの倍数である場合、後続パッド1又はパッドNオプションは、圧縮機によって省略されるかもしれません。減圧装置は含むヘッダを必要に応じてパッド1又はパッドNオプションを使用して、長さが8つのオクテットの倍数にパディングされていることを確認しなければなりません。それらは、後続のオプションを整列させるために使用される端部以外の場所に表示されるパッド1およびパッドNオプションはインラインで実行されなければならないことに留意されたいです。
Note that specifying units in octets means that LOWPAN_NHC MUST NOT be used to encode IPv6 Extension Headers that have more than 255 octets following the Length field after compression.
オクテットで単位を指定すると、LOWPAN_NHCは、圧縮後の長さフィールドを、次の255個の以上のオクテットを持つIPv6拡張ヘッダーをエンコードするために使用してはならないことを意味することに注意してください。
When the identified next header is an IPv6 Header (EID=7), the NH bit of the LOWPAN_NHC encoding is unused and MUST be set to zero. The following bytes MUST be encoded using LOWPAN_IPHC as defined in Section 3.
識別された次のヘッダは、IPv6ヘッダー（EID = 7）である場合、LOWPAN_NHCエンコードのNHビットは未使用であり、ゼロに設定しなければなりません。セクション3で定義されるように、次のバイトはLOWPAN_IPHCを使用して符号化されなければなりません。
This document defines a compression format for UDP headers using LOWPAN_NHC. The UDP compression format is shown in Figure 14. Bits 0 through 4 represent the NHC ID and '11110' indicates the specific UDP header compression encoding defined in this section.
この文書では、LOWPAN_NHCを使用してUDPヘッダの圧縮形式を定義します。 UDP圧縮フォーマットは図14ビットで示されている0〜4はNHC IDを表し、「11110」は、このセクションで定義された特定のUDPヘッダ圧縮符号化を示しています。
This specification allows a particular range of ports number (0xf0b0 to 0xf0bf) to be compressed down to 4 bits. This is a stateless compression that is inherited from [RFC4944], as opposed to a new stateful compression.
この仕様は、ポート番号（0xf0bfに0xf0b0）の特定の範囲を4ビットに圧縮されることを可能にします。これは、新しいステートフル圧縮とは対照的に、[RFC4944]から継承されているステートレス圧縮です。
The range of ports compressible down to 4 bits is not in a reserved range. A network stack implementation that is designed to communicate over a 6LoWPAN should avoid using those ports as dynamic ports whenever possible.
4ビットまで圧縮可能ポートの範囲は、予約範囲内にありません。可能な限り動的ポートとしてこれらのポートの使用を避けるべきである6LoWPANを介して通信するように設計されたネットワークスタックの実装。
Considering that this represents only 16 contiguous ports, it can be expected that many incompatible applications will use the same value of port numbers for their own end-to-end needs. Thus, a port number in the (0xf0b0 to 0xf0bf) range provides very little information about the application at the remote end.
これが唯一の16の連続したポートを表していることを考えると、多くの互換性のないアプリケーションは、独自のエンド・ツー・エンドのニーズに合わせて、ポート番号の同じ値を使用することが期待できます。したがって、（0xf0bfに0xf0b0）の範囲内のポート番号はリモートエンドにアプリケーションについてほとんど情報を提供します。
The overloading of the 0xf0bX ports increases the risk of getting the wrong type of payload and misinterpreting the content compared to ports that are reserved at IANA. As a result, it is recommended that the use of those ports be associated with a mechanism such as a Transport Layer Security (TLS) [RFC5246] Message Integrity Check (MIC) that makes sure that the content is what is expected and is checked.
0xf0bXポートの過負荷は、ペイロードの間違った種類を取得し、IANAに予約されたポートに比べてコンテンツを誤って解釈するリスクを増大させます。その結果、それはこれらのポートの使用は、このようなトランスポート層セキュリティ（TLS）のようなメカニズムに関連付けすることが推奨される[RFC5246]コンテンツが期待されていると確認されたものであることを確認するメッセージ完全性チェック（MIC）。
The UDP checksum operation is mandatory with IPv6 [RFC2460] for all packets. For that reason, [RFC4944] disallows the compression of the UDP checksum.
UDPチェックサム操作は、すべてのパケットのIPv6 [RFC2460]で必須です。そのため、[RFC4944]はUDPチェックサムの圧縮を禁止します。
With this specification, a compressor in the source transport endpoint MAY elide the UDP Checksum if it is authorized by the upper layer. The compressor MUST NOT set the C bit unless it has received such authorization. Requiring upper-layer authorization ensures that the intended transport peer will have sufficient means to deal with any data corruption that occurs before reaching the destination. The upper layer MUST NOT provide the authorization unless one of the following cases is satisfied:
それは上位層によって承認された場合、本明細書で、ソース・トランスポート・エンドポイントにおける圧縮機は、UDPチェックサムをElideのMAY。それは、そのような許可を受けていない限り、コンプレッサーは、Cビットを設定してはいけません。上位層の許可を要求することは意図した輸送ピアは、宛先に到達する前に発生したすべてのデータの破損に対処するための十分な手段を持っていることが保証されます。次のいずれかの場合が満たされない限り、上位層は、認可を提供してはなりません：
Tunneling: In this case, 6LoWPAN is deployed as a wireless pseudo-fieldbus by tunneling existing field protocols over UDP. If the tunneled Protocol Data Unit (PDU) possesses its own addressing, security and integrity check (e.g., IPsec Encapsulating Security Payload tunnel mode [RFC4303] or IP over UDP encapsulation), the tunneling mechanism MAY authorize eliding the UDP checksum in order to save on the encapsulation overhead.
トンネリング：この場合には、6LoWPANは、UDP上の既存のフィールドのプロトコルをトンネリングすることによって、無線擬似フィールドバスとして展開されます。トンネル化プロトコルデータユニット（PDU）は、独自のアドレッシング、セキュリティと整合性チェック（例えば、IPsecのカプセル化セキュリティペイロードトンネルモード[RFC4303]またはIP UDPカプセル化オーバー）を所有している場合は、トンネリングメカニズムを節約するためにUDPチェックサムをeliding許可することができますカプセル化のオーバーヘッドに。
Message Integrity Check: In this case, either IPsec Authentication Header [RFC4302] or some other form of integrity check in the UDP payload that covers at least the same information as the UDP checksum (pseudo-header, data) and has at least the same strength.
メッセージ整合性チェック：この場合には、いずれかのIPsec認証ヘッダ[RFC4302]またはUDPチェックサム（疑似ヘッダ、データ）と少なくとも同一の情報をカバーし、少なくともそれを有するUDPペイロード内の整合性チェックのいくつかの他の形態を力。
To help ensure that the UDP Checksum will be properly restored when expanding a 6LoWPAN packet, an additional integrity check (e.g., a Layer 2 (L2) Message Integrity Check) MUST be used whenever transmitting link frames that carry a compressed UDP datagram that elides the checksum. Without this additional integrity check, a UDP packet may be delivered to an unintended destination since corruption in data covered by the pseudo-header can go undetected.
6LoWPANパケット、追加的な整合性チェックを拡張する際にUDPチェックサムが正しく復元されることを保証するために（例えば、レイヤ2（L2）メッセージ完全性チェック）圧縮されたUDPデータグラムを運ぶリンクフレームを送信する毎に使用しなければならないことがelidesチェックサム。疑似ヘッダでカバーデータの破損が検出されない行くことができるので、この追加的な整合性チェックがなければ、UDPパケットが意図しない宛先に配信することができます。
A compressor MUST verify the UDP Checksum before it is elided and MUST ensure that the additional integrity check is in place before verifying and eliding the checksum. If verification of the UDP Checksum fails, the compressor MUST drop the packet.
コンプレッサーは、それが省略される前に、UDPチェックサムを検証しなければならなくて、追加の整合性チェックは、チェックサムを検証し、eliding前の場所にあることを保証しなければなりません。 UDPチェックサムの検証が失敗した場合、コンプレッサーはパケットをドロップしなければなりません。
A decompressor that expands a 6LoWPAN packet with the C bit set MUST compute the UDP Checksum on behalf of the source node and place that value in the restored UDP header as specified in the incumbent standards [RFC0768], [RFC2460]. The decompressor MUST unambiguously determine that an additional integrity check was put in place by the compressor and verify the integrity check and SHOULD do so after restoring the UDP Checksum. If the decompressor cannot unambiguously determine the presence of an integrity check or verification fails, the decompressor MUST drop the packet.
現職の標準[RFC0768]で指定されるように復元されたUDPヘッダにその値をソース・ノードの代わりにUDPチェックサムを計算し、配置しなければならないCビットが設定された6LoWPANパケットを拡張デコンプレッサ、[RFC2460]。デコンプレッサは、明確に、追加の整合性チェックは、圧縮機によって所定の位置に置かれたと判断し、整合性チェックを確認し、UDPチェックサムを復元した後、そうすべきであるしなければなりません。デコンプレッサが明確に整合性チェックの有無を判断することはできませんか、検証が失敗した場合、デコンプレッサは、パケットをドロップしなければなりません。
The recommended ordering of computing and verifying the UDP Checksum and additional integrity check ensures that data is never stored unprotected in memory. In practice, functionality separation between layers may preclude the recommended ordering. However, implementors should take special note and understand the risks when dealing with unprotected data covered by the pseudo-header.
コンピューティングおよびUDPチェックサムを検証し、追加の整合性チェックの推奨順序は、データがメモリ内で保護されていない保存されないことを保証します。実際には、層の間の機能の分離が推奨秩序を妨げることがあります。しかし、実装者は、特別な注意を取り、疑似ヘッダによってカバーされ、保護されていないデータを扱う際のリスクを理解する必要があります。
To allow intermediate nodes to compress the UDP Checksum, a forwarding node MAY infer upper-layer authorization for an incoming packet if it has the C bit set and it can unambiguously determine that an integrity check covering the same data as the UDP Checksum was in place while the UDP Checksum was elided. A forwarding node MUST NOT infer authorization if it cannot unambiguously determine the presence of and verify an integrity check while the UDP Checksum was elided.
それがCビットに設定しており、それが明確にUDPチェックサムと同じデータをカバーする整合性チェックが行われていたと判断できる場合、中間ノードは、UDPチェックサムを圧縮できるようにするために、転送ノードは、着信パケットの上位層認証を推論することができます一方、UDPチェックサムは省略されました。それが明確に存在することを決定し、UDPチェックサムが省略された一方、整合性チェックを確認できない場合は転送ノードは、許可を推測してはなりません。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 | 1 | 1 | 1 | 0 | C | P |
+---+---+---+---+---+---+---+---+
Figure 14: UDP Header Encoding
図14：UDPヘッダーのエンコーディング
C: Checksum:
C：チェックサム：
0: All 16 bits of Checksum are carried in-line.
0：チェックサムのすべての16ビットは、インラインで行われます。
1: All 16 bits of Checksum are elided. The Checksum is recovered by recomputing it on the 6LoWPAN termination point.
1：チェックサムの16ビットすべてが省略されています。チェックサムは、6LoWPAN終端点でそれを再計算することによって回収されます。
P: Ports:
P：ポート：
00: All 16 bits for both Source Port and Destination Port are carried in-line.
00：送信元ポートと宛先ポートの両方のためのすべての16ビットは、インラインで実施されています。
01: All 16 bits for Source Port are carried in-line. First 8 bits of Destination Port is 0xf0 and elided. The remaining 8 bits of Destination Port are carried in-line.
01：送信元ポートのためのすべての16ビットはインライン搭載されています。宛先ポートの最初の8ビットがの0xF0と省かです。宛先ポートの残りの8ビットはインラインで行われます。
10: First 8 bits of Source Port are 0xf0 and elided. The remaining 8 bits of Source Port are carried in-line. All 16 bits for Destination Port are carried in-line.
10：送信元ポートの最初の8ビットが0xF0が省かとしています。ソースポートの残りの8ビットはインラインで行われます。宛先ポートのためのすべての16ビットは、インラインで実施されています。
11: First 12 bits of both Source Port and Destination Port are 0xf0b and elided. The remaining 4 bits for each are carried in-line.
11：送信元ポートと宛先ポートの両方の最初の12ビットが0xf0bと省かです。それぞれの残りの4ビットは、インラインで行われます。
Fields carried in-line (in part or in whole) appear in the same order as they do in the UDP header format [RFC0768]. The UDP Length field MUST always be elided and is inferred from lower layers using the 6LoWPAN Fragmentation header or the IEEE 802.15.4 header.
それらがUDPヘッダのフォーマット[RFC0768]にそうであるように（部分的にまたは全体的に）インライン実施フィールドが同じ順序で現れます。 UDP長フィールドは常に省略されなければならないと6LoWPANフラグメンテーションヘッダまたはIEEE 802.15.4ヘッダを使用して、下位層から推測されます。
This document defines a new IPv6 header compression format for 6LoWPAN. The document allocates the following 32 Dispatch type field values for LOWPAN_IPHC:
この文書では、6LoWPANのための新しいIPv6ヘッダ圧縮フォーマットを定義します。文書はLOWPAN_IPHCのため、次の32の派遣型のフィールドの値を割り当てます。
01 100000 through 01 111111
01 111111を通じて01 100000
This assignment preempts the assignment of 01 111111 for ESC [RFC4944]; this preemption is possible because extension bytes that would enable the use of ESC have not been allocated yet. Instead, the value:
この割り当ては、ESC [RFC4944] 01 111111の割り当てをプリエンプト。 ESCの使用を可能にする拡張バイトがまだ割り当てられていないため、このプリエンプションが可能です。代わりに、値：
01 000000
０１ ００００００
is reserved as a replacement value for ESC, to be finally assigned with the first assignment of extension bytes.
ESCの代替値として予約され、最終的に拡張バイトの最初の割り当てと割り当てられます。
This document also creates a new IANA registry for the LOWPAN_NHC header type, with the following initial content:
このドキュメントは、次の初期コンテンツで、LOWPAN_NHCヘッダタイプのための新しいIANAレジストリを作成します。
00000000 to 11011111: (unassigned) 1110000N: IPv6 Hop-by-Hop Options Header [RFC6282] 1110001N: IPv6 Routing Header [RFC6282] 1110010N: IPv6 Fragment Header [RFC6282] 1110011N: IPv6 Destination Options Header [RFC6282] 1110100N: IPv6 Mobility Header [RFC6282] 1110111N: IPv6 Header [RFC6282] 11110CPP: UDP Header [RFC6282] 11111000 to 11111110: (unassigned)
11011111から00000000：（未割り当て）1110000N：IPv6のホップバイホップオプションヘッダ[RFC6282] 1110001N：IPv6ルーティングヘッダ[RFC6282] 1110010N：IPv6のフラグメントヘッダ[RFC6282] 1110011N：IPv6宛先オプションヘッダ[RFC6282] 1110100N：IPv6のモビリティヘッダ[RFC6282] 1110111N：IPv6のヘッダ[RFC6282] 11110CPP：UDPヘッダ[RFC6282] 11111110から11111000：（未割り当て）
Capital letters in bit positions represent class-specific bit assignments. N indicates whether or not additional LOWPAN_NHC encodings follow, as defined in Section 4.2. CPP represents variables specific to UDP header compression defined in Section 4.3.
ビット位置での大文字は、クラス固有のビット割り当てを表します。 Nは、セクション4.2で定義されるように、追加のLOWPAN_NHCエンコーディングは、従うか否かを示します。 CPPは、セクション4.3で定義されたUDPヘッダー圧縮に固有の変数を表します。
The policy for this registry [RFC5226] is IETF Review. In this process, new values SHOULD be assigned in a way that preserves the NHC ID abstraction of Section 4 (i.e., k one-bits followed by one zero-bit identify the general class of NHC, followed by class-specific bit assignments).
このレジストリ[RFC5226]のための政策は、IETFレビューです。このプロセスでは、新しい値（すなわち、1つのゼロビットクラス固有のビット割り当てに続いて、NHCの一般的なクラスを識別することによって、続いて一kビット）第4のNHC ID抽象化を維持ように割り当てられるべきです。
The definition of LOWPAN_IPHC permits the compression of header information on communication that could take place in its absence, albeit in a less efficient form. It recognizes that a IEEE 802.15.4 PAN may have associated with it a number of prefixes through shared context. How the shared context is assigned and managed is beyond the scope of this document.
LOWPAN_IPHCの定義はあまり効率的な形式であるが、その非存在下で起こり得る通信にヘッダ情報の圧縮を可能にします。これは、IEEE 802.15.4 PANは、それに共有コンテキストを介してプレフィクスの数が関連付けられていてもよいことを認識する。共有コンテキストを割り当てて管理されている方法は、このドキュメントの範囲を超えています。
The overloading of the 0xf0bX ports increases the risk of getting the wrong type of payload and misinterpreting the content compared to ports that reserved at IANA. It is thus recommended that the use of those ports be associated with a mechanism such as a Transport Layer Security (TLS) [RFC5246] Message Integrity Check (MIC) that validates that the content is expected and checked for integrity.
0xf0bXポートの過負荷は、ペイロードの間違った種類を取得し、IANAに予約ポートに比べてコンテンツを誤って解釈するリスクを増大させます。したがって、これらのポートの使用は、このような内容を期待して整合性をチェックされていることを検証するトランスポート層セキュリティ（TLS）[RFC5246]メッセージ完全性チェック（MIC）などのメカニズムに関連付けすることをお勧めします。
Thanks to Julien Abeille, Robert Assimiti, Dominique Barthel, Carsten Bormann, Robert Cragie, Stephen Dawson-Haggerty, Mathilde Durvy, Erik Nordmark, Christos Polyzois, Joseph Reddy, Shoichi Sakane, Zach Shelby, Dario Tedeschi, Tony Viscardi, and Jay Werb for useful design consideration and implementation feedback. Special thanks to David Black, Lars Eggert, and Carsten Bormann for their contribution in closing the security issues around UDP compression.
ジュリアン・アベイユ、ロバートAssimiti、ドミニク・バーセル、カルステンボルマン、ロバートCragie、スティーブン・ドーソン・ハガティ、マチルドDurvy、エリックNordmarkと、クリストスPolyzois、ジョセフ・レディ、正一坂根、ザックシェルビー、ダリオ・テデスキ、トニーViscardi、およびジェイWerbのおかげについて便利な設計上の考慮事項と実装のフィードバック。 UDP圧縮の周りにセキュリティ上の問題を閉じるにおける彼らの貢献のためのデビッド・ブラック、ラースエッゲルト、とカルステンボルマンに感謝します。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768]ポステル、J.、 "ユーザ・データグラム・プロトコル"、STD 6、RFC 768、1980年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474]ニコルズ、K.、ブレイク、S.、ベイカー、F.、およびD.黒、 "IPv4とIPv6ヘッダーとの差別化されたサービス分野（DS分野）の定義"、RFC 2474、1998年12月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
"IPに明示的輻輳通知の添加（ECN）" [RFC3168]ラマクリシュナン、K.、フロイド、S.、およびD.ブラック、RFC 3168、2001年9月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 4291、2006年2月。
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007.
[RFC4944]モンテネグロ、G.、クシャルナガル、N.、ホイ、J.、およびD. Culler、 "IEEE 802.15.4ネットワークの上のIPv6パケットの送信"、RFC 4944、2007年9月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011.
[RFC6275]パーキンス、C.、エド。、ジョンソン、D.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 6275、2011年7月。
[IEEE802.15.4] IEEE Computer Society, "IEEE Std. 802.15.4-2006", October 2006.
[IEEE802.15.4] IEEEコンピュータ学会、 "IEEE規格802.15.4-2006"、2006年10月。
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, August 2002.
[RFC3306]ハーバーマン、B.とD.ターラー、 "ユニキャストプレフィックスベースのIPv6マルチキャストアドレス"、RFC 3306、2002年8月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] Droms、R.、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニー、 "IPv6のための動的ホスト構成プロトコル（DHCPv6）"、RFC 3315、2003年7月。
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004.
[RFC3956] Savola、P.とB.ハーバーマン、 "IPv6マルチキャストアドレスでのランデブーポイント（RP）アドレスを埋め込み"、RFC 3956、2004年11月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]ケント、S.、 "IP認証ヘッダー"、RFC 4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861] Narten氏、T.、Nordmarkと、E.、シンプソン、W.、およびH.ソリマン、 "IPバージョン6（IPv6）のための近隣探索"、RFC 4861、2007年9月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.2"、RFC 5246、2008年8月。
Authors' Addresses
著者のアドレス
Jonathan W. Hui (editor) Arch Rock Corporation 501 2nd St. Ste. 410 San Francisco, California 94107 USA
ジョナサン・W.ホイ（エディタ）アーチロック株式会社501第二セントマリー。 410サンフランシスコ、カリフォルニア94107 USA
Phone: +415 692 0828 EMail: jhui@archrock.com
電話：+415 692 0828 Eメール：jhui@archrock.com
Pascal Thubert Cisco Systems Village d'Entreprises Green Side 400, Avenue de Roumanille Batiment T3 Biot - Sophia Antipolis 06410 FRANCE
パスカルThubertシスコシステムズエンタープライズヴィレッジグリーンサイド400アベニューRoumanilleビルT3ビオ - ソフィアアンティポリス06410 FRANCE
Phone: +33 4 97 23 26 34 EMail: pthubert@cisco.com
電話：+33 4 97 23 26 34 Eメール：pthubert@cisco.com