[要約] RFC 6282は、IEEE 802.15.4ベースのネットワーク上でのIPv6データグラムの圧縮形式に関する仕様です。このRFCの目的は、ネットワークの帯域幅を節約し、無線ネットワーク上でのIPv6通信の効率を向上させることです。
Internet Engineering Task Force (IETF) J. Hui, Ed.
Request for Comments: 6282 Arch Rock Corporation
Updates: 4944 P. Thubert
Category: Standards Track Cisco
ISSN: 2070-1721 September 2011
Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks
IEEE 802.15.4ベースのネットワークを介したIPv6データグラムの圧縮形式
Abstract
概要
This document updates RFC 4944, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks". This document specifies an IPv6 header compression format for IPv6 packet delivery in Low Power Wireless Personal Area Networks (6LoWPANs). The compression format relies on shared context to allow compression of arbitrary prefixes. How the information is maintained in that shared context is out of scope. This document specifies compression of multicast addresses and a framework for compressing next headers. UDP header compression is specified within this framework.
このドキュメントは、RFC 4944、「IEEE 802.15.4ネットワークを介したIPv6パケットの送信」を更新します。このドキュメントは、低電力ワイヤレスパーソナルエリアネットワーク（6lowpans）でのIPv6パケット配信用のIPv6ヘッダー圧縮形式を指定します。圧縮形式は、共有コンテキストに依存して、任意のプレフィックスの圧縮を可能にします。その共有コンテキストで情報がどのように維持されるかは、範囲外です。このドキュメントは、マルチキャストアドレスの圧縮と、次のヘッダーを圧縮するためのフレームワークを指定します。UDPヘッダー圧縮は、このフレームワーク内で指定されています。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6282.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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]標準は、127バイトのMTUを指定し、250 kbps以下のリンクスループットを備えたワイヤレスリンクで、セキュリティを有効にして実際のメディアアクセス制御（MAC）ペイロードの約80オクテットを生成します。6lowpan適応形式[RFC4944]は、ワイヤレスセンサーネットワークなどのアプリケーションで予想される限られた帯域幅、メモリ、またはエネルギーリソースを考慮して、このような制約されたリンクにIPv6データグラムを運ぶように指定されました。[RFC4944]は、サブIP転送をサポートするメッシュアドレス指定ヘッダー、IPv6最小MTU要件[RFC2460]をサポートするフラグメンテーションヘッダー、およびIPv6データグラム（LowPAN_HC1およびLOWPAN_HC2）のステートレスヘッダー圧縮をサポートするフラグメンテーションヘッダーを定義し、比較的大規模なIPV6およびUDPヘッラーを減らします。（最良の場合）いくつかのバイトにまで。
LOWPAN_HC1 and LOWPAN_HC2 are insufficient for most practical uses of IPv6 in 6LoWPANs. LOWPAN_HC1 is most effective for link-local unicast communication, where IPv6 addresses carry the link-local prefix and an Interface Identifier (IID) directly derived from IEEE 802.15.4 addresses. In this case, both addresses may be completely elided. However, though link-local addresses are commonly used for local protocol interactions such as IPv6 Neighbor Discovery [RFC4861], DHCPv6 [RFC3315], or routing protocols, they are usually not used for application-layer data traffic, so the actual value of this compression mechanism is limited.
LowPAN_HC1とLowPAN_HC2は、6LowpansのIPv6のほとんどの実際の使用には不十分です。LowPAN_HC1は、IPv6アドレスがIEEE 802.15.4アドレスから直接導出されたインターフェイス識別子（IID）を運ぶリンクローカルユニキャスト通信に最も効果的です。この場合、両方のアドレスが完全に除外される場合があります。ただし、Link-Localアドレスは一般にIPv6 Neighbor Discovery [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の外部のデバイスと通信する場合、または6lowpan内でIP転送が行われるルートオーバー構成で、ルーティング可能なアドレスを使用する必要があります。ルーティング可能なアドレスの場合、LowPAN_HC1には、プレフィックスをインラインにするためにIPv6ソースと宛先アドレスの両方が必要です。メッシュアドレス指定ヘッダーが使用されていない場合、ルーティング可能なアドレスのIIDをインラインで運ぶ必要があります。ただし、LowPAN_HC1は、IIDにインラインを運ぶ場合、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のホップ制限値を使用して、シングルホップで通信が発生することを確認するためによく使用されます。この仕様により、これらの一般的なケースではIPv6ホップリミットフィールドの圧縮が可能になりますが、LowPAN_HC1はそうではありません。
This document also defines LOWPAN_NHC, an encoding format for arbitrary next headers. LOWPAN_IPHC indicates whether the following header is encoded using LOWPAN_NHC. If so, the bits immediately following the compressed IPv6 header start the LOWPAN_NHC encoding. In contrast, LOWPAN_HC1 could be extended to support compression of next headers using LOWPAN_HC2, but only for UDP, TCP, and ICMPv6. Furthermore, the LOWPAN_HC2 octet sits between the LOWPAN_HC1 octet and uncompressed IPv6 header fields. This specification moves the next header encoding bits to follow all IPv6-related bits, allowing for a properly layered structure and direct support for IPv6 extension headers.
このドキュメントは、任意の次のヘッダーのエンコード形式であるLowPan_NHCも定義します。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）などの追加の上層メカニズムによって可能になった場合、チェックサム圧縮を可能にしません。この仕様により、6lowpanでUDPチェックサムを排除する機能が追加されており、さらに2オクテットをさらに節約できます。
Also, using LOWPAN_NHC, this document defines encoding formats for IPv6-in-IPv6 encapsulation as well as IPv6 Extension Headers. With LOWPAN_HC1 and LOWPAN_HC2, chains of next headers cannot be encoded efficiently.
また、LowPAN_NHCを使用して、このドキュメントでは、IPv6-in-IPV6カプセル化のエンコード形式とIPv6拡張ヘッダーを定義しています。LowPAN_HC1およびLowPAN_HC2では、次のヘッダーのチェーンを効率的にエンコードすることはできません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "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 registered (Section 5) in the future. It is out of scope of this document how a compressor learns that a decompressor has additional capabilities.
このドキュメントで更新された[RFC4944]の準拠の実装は、このドキュメントの規定を利用する受信したパケットを適切に処理できる必要があります。準拠した実装は、将来登録される可能性がある（セクション5）追加のLowPAN_NHCタイプ（セクション4）を実装する場合があります。このドキュメントの範囲外であり、コンプレッサーが減圧器に追加の機能があることをどのように学習しますか。
Section 5.3 of [RFC4944] also defines how to fragment compressed IPv6 datagrams that do not fit within a single link frame. Section 5.3 of [RFC4944] defines the fragment header's datagram_size and datagram_offset values as the size and offset of the IPv6 datagram before compression. As a result, all fragment payload outside the first fragment must carry their respective portions of the IPv6 datagram before compression. This document does not change that requirement. When using the fragmentation mechanism described in Section 5.3 of [RFC4944], any header that cannot fit within the first fragment MUST NOT be compressed.
[RFC4944]のセクション5.3は、単一のリンクフレームに適合しない圧縮されたIPv6データグラムをフラグメントする方法も定義しています。[RFC4944]のセクション5.3は、圧縮前のIPv6データグラムのサイズとオフセットとして、フラグメントヘッダーのDatagram_sizeおよびdatagram_offset値を定義します。その結果、最初のフラグメントの外側のすべてのフラグメントペイロードは、圧縮前にIPv6データグラムのそれぞれの部分を運ぶ必要があります。このドキュメントは、その要件を変更しません。[RFC4944]のセクション5.3で説明されている断片化メカニズムを使用する場合、最初のフラグメントに収まることができないヘッダーを圧縮してはなりません。
The header compression format defined in this document preempts the ESC dispatch value defined in Section 5.1 of [RFC4944]. Instead, the value of 01 000000 is reserved as a replacement value for ESC, to be finally assigned with the first assignment of extension bytes.
このドキュメントで定義されているヘッダー圧縮形式は、[RFC4944]のセクション5.1で定義されているESC派遣値を先取りします。代わりに、01 000000の値は、ESCの代替値として予約され、最終的に拡張バイトの最初の割り当てで割り当てられます。
In this section, we define the LOWPAN_IPHC encoding format for compressing the IPv6 header. To enable effective compression, LOWPAN_IPHC relies on information pertaining to the entire 6LoWPAN. LOWPAN_IPHC assumes the following will be the common case for 6LoWPAN communication: Version is 6; Traffic Class and Flow Label are both zero; Payload Length can be inferred from lower layers from either the 6LoWPAN Fragmentation header or the IEEE 802.15.4 header; Hop Limit will be set to a well-known value by the source; addresses assigned to 6LoWPAN interfaces will be formed using the link-local prefix or a small set of routable prefixes assigned to the entire 6LoWPAN; addresses assigned to 6LoWPAN interfaces are formed with an IID derived directly from either the 64-bit extended or the 16-bit short IEEE 802.15.4 addresses.
このセクションでは、IPv6ヘッダーを圧縮するためのLowPAN_IPHCエンコード形式を定義します。効果的な圧縮を可能にするために、LowPAN_IPHCは6Lowpan全体に関連する情報に依存しています。lowpan_iphcは、以下が6lowpan通信の一般的なケースになると想定しています。バージョンは6です。トラフィッククラスとフローラベルは両方ともゼロです。ペイロードの長さは、6lowpan断片化ヘッダーまたはIEEE 802.15.4ヘッダーのいずれかの下層から推測できます。ホップ制限は、ソースによってよく知られている値に設定されます。6lowpanインターフェイスに割り当てられたアドレスは、リンクローカルプレフィックスまたは6lowpan全体に割り当てられたルーティング可能なプレフィックスの小さなセットを使用して形成されます。6Lowpanインターフェイスに割り当てられたアドレスは、64ビットの拡張または16ビットの短いIEEE 802.15.4アドレスから直接導出されたIIDで形成されます。
+-------------------------------------+----------------------------
| Dispatch + LOWPAN_IPHC (2-3 octets) | In-line IPv6 Header Fields
+-------------------------------------+----------------------------
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エンコーディングは13ビットを利用しており、そのうち5つはディスパッチタイプの右端のビットから取られています。エンコードは、追加のコンテキストをサポートするために別のオクテットによって拡張される場合があります。図1に示すように、非圧縮IPv6ヘッダーフィールドからの情報は、LowPAN_IPHCエンコードに従って行われます。最良の場合、LowPAN_IPHCはIPv6ヘッダーを2オクテット（ディスパッチオクテットとLowPAN_IPHCエンコーディング）にリンクで圧縮できます。 - ローカルコミュニケーション。
When routing over multiple IP hops, LOWPAN_IPHC can compress the IPv6 header down to 7 octets (1-octet dispatch, 1-octet LOWPAN_IPHC, 1-octet Hop Limit, 2-octet Source Address, and 2-octet Destination Address). The Hop Limit may not be compressed because it needs to decremented at each hop and may take any value. Stateful address compression must be applied to the source and destination IPv6 addresses because they do not statelessly match the source and destination link-layer addresses on intermediate hops.
複数のIPホップにルーティングすると、LowPAN_IPHCはIPv6ヘッダーを7オクテット（1-OCTET Dispatch、1-OCTET LowPAN_IPHC、1-OCTET HOP LIMIT、2-OCTET SOURCEアドレス、2-OCTET Destinationアドレス）に圧縮できます。ホップ制限は、各ホップで減少する必要があり、あらゆる価値を取る必要があるため圧縮されない場合があります。ステートフルなアドレス圧縮は、中間ホップのソースおよび宛先リンク層アドレスをステートレレスに一致させないため、ソースおよび宛先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：トラフィッククラス、フローラベル：[RFC3168]で指定されているように、8ビットIPv6トラフィッククラスフィールドは2つのフィールドに分割されます。
00: ECN + DSCP + 4-bit Pad + Flow Label (4 bytes)
01: ECN + 2-bit Pad + Flow Label (3 bytes), DSCP is elided.
01：ECN 2ビットパッドフローラベル（3バイト）、DSCPが排除されます。
10: ECN + DSCP (1 byte), Flow Label is elided.
10：ECN DSCP（1バイト）、フローラベルが削除されます。
11: Traffic Class and Flow Label are elided.
11：トラフィッククラスとフローラベルが削除されます。
NH: Next Header:
NH：次のヘッダー：
0: Full 8 bits for Next Header are carried in-line.
0：次のヘッダーのフル8ビットは、インラインで運ばれます。
1: The Next Header field is compressed and the next header is encoded using LOWPAN_NHC, which is discussed in Section 4.1.
1：次のヘッダーフィールドは圧縮され、次のヘッダーはlowPAN_NHCを使用してエンコードされます。これについてはセクション4.1で説明します。
HLIM: Hop Limit:
hlim：ホップ制限：
00: The Hop Limit field is carried in-line.
00：ホップリミットフィールドはインラインで運ばれます。
01: The Hop Limit field is compressed and the hop limit is 1.
01：ホップ制限フィールドが圧縮され、ホップ制限は1です。
10: The Hop Limit field is compressed and the hop limit is 64.
10：ホップ制限フィールドが圧縮され、ホップ制限は64です。
11: The Hop Limit field is compressed and the hop limit is 255.
11：ホップ制限フィールドが圧縮され、ホップ制限は255です。
CID: Context Identifier Extension:
CID：コンテキスト識別子拡張機能：
0: No additional 8-bit Context Identifier Extension is used. If context-based compression is specified in either Source Address Compression (SAC) or Destination Address Compression (DAC), context 0 is used.
0：追加の8ビットコンテキスト識別子拡張は使用されません。コンテキストベースの圧縮が、ソースアドレス圧縮（SAC）または宛先アドレス圧縮（DAC）のいずれかで指定されている場合、コンテキスト0が使用されます。
1: An additional 8-bit Context Identifier Extension field immediately follows the Destination Address Mode (DAM) field.
1：追加の8ビットコンテキスト識別子拡張フィールドは、宛先アドレスモード（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ビットの値は、ゼロでパッド入りのリンクローカルプレフィックスです。次の64ビットは0000：00ff：fe00：xxxxです。ここで、xxxxは16ビットがインラインで運ばれます。
11: 0 bits. The address is fully elided. The first 64 bits of the address are the link-local prefix padded with zeros. The remaining 64 bits are computed from the encapsulating header (e.g., 802.15.4 or IPv6 source address) as specified in Section 3.2.2.
11：0ビット。アドレスは完全に除外されています。アドレスの最初の64ビットは、ゼロでパディングされたリンクローカルプレフィックスです。残りの64ビットは、セクション3.2.2で指定されているように、カプセル化ヘッダー（802.15.4またはIPv6ソースアドレスなど）から計算されます。
If SAC=1:
SAC = 1の場合：
00: The UNSPECIFIED address, ::
00：不特定のアドレス、::
01: 64 bits. The address is derived using context information and the 64 bits carried in-line. Bits covered by context information are always used. Any IID bits not covered by context information are taken directly from the corresponding bits carried in-line. Any remaining bits are zero.
01：64ビット。アドレスは、コンテキスト情報を使用して導出され、64ビットはインラインで運ばれます。コンテキスト情報でカバーされているビットは常に使用されます。コンテキスト情報でカバーされていないIIDビットは、対応するビットから直接取得されます。残りのビットはゼロです。
10: 16 bits. The address is derived using context information and the 16 bits carried in-line. Bits covered by context information are always used. Any IID bits not covered by context information are taken directly from their corresponding bits in the 16-bit to IID mapping given by 0000:00ff:fe00:XXXX, where XXXX are the 16 bits carried in-line. Any remaining bits are zero.
10：16ビット。アドレスは、コンテキスト情報を使用して導出され、16ビットはインラインで運ばれます。コンテキスト情報でカバーされているビットは常に使用されます。コンテキスト情報でカバーされていないIIDビットは、16ビットからIIDへのマッピングの対応するビットから0000：00FF：FE00：XXXXで直接取得されます。XXXXは16ビットがインラインで運ばれます。残りのビットはゼロです。
11: 0 bits. The address is fully elided and is derived using context information and the encapsulating header (e.g., 802.15.4 or IPv6 source address). Bits covered by context information are always used. Any IID bits not covered by context information are computed from the encapsulating header as specified in Section 3.2.2. Any remaining bits are zero.
11：0ビット。アドレスは完全に除外され、コンテキスト情報とカプセル化ヘッダー（802.15.4またはIPv6ソースアドレスなど）を使用して導出されます。コンテキスト情報でカバーされているビットは常に使用されます。コンテキスト情報でカバーされていない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:
ダム：宛先アドレスモード：
If M=0 and DAC=0 This case matches SAC=0 but for the destination address:
M = 0およびDAC = 0の場合、このケースはSAC = 0と一致しますが、宛先アドレスの場合：
00: 128 bits. The full address is carried in-line.
00：128ビット。完全なアドレスはインラインで運ばれます。
01: 64 bits. The first 64-bits of the address are elided. The value of those bits is the link-local prefix padded with zeros. The remaining 64 bits are carried in-line.
01：64ビット。アドレスの最初の64ビットは省略されています。これらのビットの値は、ゼロでパディングされたリンクローカルプレフィックスです。残りの64ビットは、インラインで運ばれます。
10: 16 bits. The first 112 bits of the address are elided. The value of the first 64 bits is the link-local prefix padded with zeros. The following 64 bits are 0000:00ff: fe00:XXXX, where XXXX are the 16 bits carried in-line.
10：16ビット。アドレスの最初の112ビットは省略されています。最初の64ビットの値は、ゼロでパッド入りのリンクローカルプレフィックスです。次の64ビットは0000：00ff：fe00：xxxxです。ここで、xxxxは16ビットがインラインで運ばれます。
11: 0 bits. The address is fully elided. The first 64 bits of the address are the link-local prefix padded with zeros. The remaining 64 bits are computed from the encapsulating header (e.g., 802.15.4 or IPv6 destination address) as specified in Section 3.2.2.
11：0ビット。アドレスは完全に除外されています。アドレスの最初の64ビットは、ゼロでパディングされたリンクローカルプレフィックスです。残りの64ビットは、セクション3.2.2で指定されているように、カプセル化ヘッダー（802.15.4またはIPv6宛先アドレスなど）から計算されます。
If M=0 and DAC=1:
m = 0およびdac = 1の場合：
00: Reserved.
00：予約済み。
01: 64 bits. The address is derived using context information and the 64 bits carried in-line. Bits covered by context information are always used. Any IID bits not covered by context information are taken directly from the corresponding bits carried in-line. Any remaining bits are zero.
01：64ビット。アドレスは、コンテキスト情報を使用して導出され、64ビットはインラインで運ばれます。コンテキスト情報でカバーされているビットは常に使用されます。コンテキスト情報でカバーされていないIIDビットは、対応するビットから直接取得されます。残りのビットはゼロです。
10: 16 bits. The address is derived using context information and the 16 bits carried in-line. Bits covered by context information are always used. Any IID bits not covered by context information are taken directly from their corresponding bits in the 16-bit to IID mapping given by 0000:00ff:fe00:XXXX, where XXXX are the 16 bits carried in-line. Any remaining bits are zero.
10：16ビット。アドレスは、コンテキスト情報を使用して導出され、16ビットはインラインで運ばれます。コンテキスト情報でカバーされているビットは常に使用されます。コンテキスト情報でカバーされていないIIDビットは、16ビットからIIDへのマッピングの対応するビットから0000：00FF：FE00：XXXXで直接取得されます。XXXXは16ビットがインラインで運ばれます。残りのビットはゼロです。
11: 0 bits. The address is fully elided and is derived using context information and the encapsulating header (e.g. 802.15.4 or IPv6 destination address). Bits covered by context information are always used. Any IID bits not covered by context information are computed from the encapsulating header as specified in Section 3.2.2. Any remaining bits are zero.
11：0ビット。アドレスは完全に除外され、コンテキスト情報とカプセル化ヘッダー（802.15.4またはIPv6宛先アドレスなど）を使用して導出されます。コンテキスト情報でカバーされているビットは常に使用されます。コンテキスト情報でカバーされていない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ビット。アドレスはFFXX :: 00XX：xxxxフォームを採用します。
11: 8 bits. The address takes the form ff02::00XX.
11：8ビット。アドレスは、FF02 :: 00XXのフォームを取得します。
If M=1 and DAC=1:
M = 1およびDAC = 1の場合：
00: 48 bits. This format is designed to match Unicast-Prefix-based IPv6 Multicast Addresses as defined in [RFC3306] and [RFC3956]. The multicast address takes the form ffXX:XXLL: PPPP:PPPP:PPPP:PPPP:XXXX:XXXX. where the X are the nibbles that are carried in-line, in the order in which they appear in this format. P denotes nibbles used to encode the prefix itself. L denotes nibbles used to encode the prefix length. The prefix information P and L is taken from the specified context.
00：48ビット。この形式は、[RFC3306]および[RFC3956]で定義されているUnicast-PrefixベースのIPv6マルチキャストアドレスと一致するように設計されています。マルチキャストアドレスは、FFXX：xxll：pppp：pppp：pppp：pppp：xxxx：xxxx形式を採用します。Xは、この形式に表示される順序で、インラインで運ばれるニブルです。pは、プレフィックス自体をエンコードするために使用されるニブルを示します。Lは、プレフィックスの長さをエンコードするために使用されるニブルを示します。プレフィックス情報PとLは、指定されたコンテキストから取得されます。
01: reserved
01：予約済み
10: reserved
10：予約済み
11: reserved
11：予約済み
This specification expects that a conceptual context is shared between the node that compresses a packet and the node(s) that needs to expand it. How the contexts are shared and maintained is out of scope. What information is contained within a context information is out of scope. Actions in response to unknown and/or invalid contexts are out of scope. The specification enables a node to use up to 16 contexts. The context used to encode the source address does not have to be the same as the context used to encode the destination address.
この仕様は、概念的コンテキストがパケットを圧縮するノードと拡張する必要があるノード間で共有されることを期待しています。コンテキストがどのように共有され、維持されるかは範囲外です。コンテキスト情報に含まれる情報は範囲外です。不明および/または無効なコンテキストに応じたアクションは範囲外です。この仕様により、ノードは最大16のコンテキストを使用できます。ソースアドレスをエンコードするために使用されるコンテキストは、宛先アドレスをエンコードするために使用されるコンテキストと同じである必要はありません。
If the CID field is set to '1' in the LOWPAN_IPHC encoding, then an additional octet extends the LOWPAN_IPHC encoding following the DAM bits but before the IPv6 header fields that are carried in-line. The additional octet identifies the pair of contexts to be used when the IPv6 source and/or destination address is compressed. The context identifier is 4 bits for each address, supporting up to 16 contexts. Context 0 is the default context. The encoding is shown in Figure 3.
LowPAN_IPHCエンコードでCIDフィールドが「1」に設定されている場合、追加のオクテットは、ダムビットに続くが、インラインで運ばれるIPv6ヘッダーフィールドの前にローパン_IPHCエンコードを拡張します。追加のオクテットは、IPv6ソースおよび/または宛先アドレスが圧縮されているときに使用するコンテキストのペアを識別します。コンテキスト識別子は、アドレスごとに4ビットで、最大16のコンテキストをサポートしています。コンテキスト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ビットに圧縮される場合があります。6lowpanフラグメンテーションヘッダーまたはIEEE 802.15.4ヘッダーを使用して、IPv6ペイロード長さフィールドは、常に下層から排除および推測する必要があります。
The Traffic Class field in the IPv6 header comprises 6 bits of Diffserv extension [RFC2474] and 2 bits of Explicit Congestion Notification (ECN) [RFC3168]. The TF field in the LOWPAN_IPHC encoding indicates whether the Traffic Class and Flow Label are carried in-line in the compressed IPv6 header. When Flow Label is included while the Traffic Class is compressed, an additional 4 bits are included to maintain byte alignment. Two of the 4 bits contain the ECN bits from the Traffic Class field.
IPv6ヘッダーのトラフィッククラスフィールドは、6ビットのdiffserv拡張[RFC2474]と2ビットの明示的なうっ血通知（ECN）[RFC3168]で構成されています。LowPAN_IPHCエンコーディングのTFフィールドは、トラフィッククラスとフローラベルが圧縮IPv6ヘッダーにインラインで運ばれているかどうかを示します。トラフィッククラスが圧縮されている間にフローラベルが含まれている場合、バイトアライメントを維持するために追加の4ビットが含まれています。4ビットのうち2つには、トラフィッククラスフィールドからの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
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
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|ECN| DSCP |
+-+-+-+-+-+-+-+-+
Figure 6: TF = 10: Traffic Class carried in-line
LOWPAN_IPHC elides the IIDs of source or destination addresses when SAM = 3 or DAM = 3, respectively. In this mode, the IID is derived from the encapsulating header. When the encapsulating header carries IPv6 addresses, bits for the source and destination addresses are copied from the source and destination addresses of the encapsulating IPv6 header.
LowPAN_IPHCは、それぞれSAM = 3またはDAM = 3の場合、ソースまたは宛先アドレスのIIDを排除します。このモードでは、IIDはカプセル化ヘッダーに由来します。カプセル化ヘッダーがIPv6アドレスを運ぶと、ソースアドレスと宛先アドレスのビットが、カプセル化するIPv6ヘッダーのソースおよび宛先アドレスからコピーされます。
The remainder of this section defines the mapping from IEEE 802.15.4 [IEEE802.15.4] link-layer addresses to IIDs for both short and extended IEEE 802.15.4 addresses. IID bits not covered by the context information MAY be elided if they match the link-layer address mapping and MUST NOT be elided if they do not.
このセクションの残りの部分では、IEEE 802.15.4 [IEEE802.15.4]のマッピングを、短いIIEEおよび拡張IEEE 802.15.4アドレスの両方でIIDにリンク層アドレスを定義します。コンテキスト情報でカバーされていないIIDビットは、リンクレイヤーアドレスマッピングと一致する場合、削除され、そうでない場合は排除してはなりません。
An extended IEEE 802.15.4 address takes the form of an IEEE EUI-64 address. Generating an IID from an extended address is identical to that defined in Appendix A of [RFC4291]. The only change needed to transform an IEEE EUI-64 identifier to an interface identifier is to invert the universal/local bit.
拡張されたIEEE 802.15.4アドレスは、IEEE EUI-64アドレスの形をとります。拡張アドレスからIIDを生成することは、[RFC4291]の付録Aで定義されているものと同じです。IEEE EUI-64識別子をインターフェイス識別子に変換するために必要な唯一の変更は、ユニバーサル/ローカルビットを反転することです。
A short IEEE 802.15.4 address is 16 bits in length. Short addresses are mapped into the restricted space of IEEE EUI-64 addresses by setting the middle 16 bits to 0xfffe, the bottom 16 bits to the short address, and all other bits to zero. As a result, an IID generated from a short address has the form:
短いIEEE 802.15.4アドレスの長さは16ビットです。短いアドレスは、中央の16ビットを0xfffeに設定することにより、IEEE EUI-64アドレスの制限スペースにマッピングされ、下部16ビットを短いアドレスに、その他すべてのビットからゼロに設定します。その結果、短いアドレスから生成されたIIDには次の形式があります。
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ビットまで圧縮される場合があります。この形式は、Solicited-Nodeマルチキャストアドレス（FF02 :: 1：FFXX：XXXX）の圧縮と、マルチキャストグループ識別子の上部ビットがゼロであるIPv6マルチキャストアドレスの圧縮をサポートします。8ビット圧縮フォームは、マルチキャストグループ識別子の最も重要なビットのみを運ぶだけです。48ビットおよび32ビットの圧縮フォームは、マルチキャストグループ識別子の最も重要なビットに加えて、マルチキャストスコープとフラグをインラインに搭載しています。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Scope | Group Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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)
LOWPAN_IPHC supports stateful compression of multicast addresses when M = 1 and DAC = 1. This document currently defines DAM = 00: context-based compression of Unicast-Prefix-based IPv6 Multicast Addresses [RFC3306][RFC3956]. In particular, the Prefix Length and Network Prefix can be taken from a context. As a result, LOWPAN_IPHC can compress a Unicast-Prefix-based IPv6 Multicast Address down to 6 octets by only carrying the 4-bit Flags, 4-bit Scope, 8-bit Rendezvous Point Interface ID (RIID), and 32-bit Group Identifier in-line.
LowPAN_IPHCは、M = 1およびDAC = 1の場合、マルチキャストアドレスのステートフル圧縮をサポートします。このドキュメントは現在、DAM = 00：Unicast-PrefixベースのIPv6マルチキャストアドレス[RFC3306] [RFC3956]のコンテキストベースの圧縮を定義しています。特に、接頭辞の長さとネットワークプレフィックスは、コンテキストから取得できます。その結果、LowPAN_IPHCは、4ビットフラグ、4ビットスコープ、8ビットランデブーポイントインターフェイスID（RIID）、および32ビットグループのみを運ぶだけで、ユニキャスト-PrefixベースのIPv6マルチキャストアドレスを6オクテットまで圧縮できます。識別子インライン。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Scope | Rsvd / RIID | Group Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: DAM = 00. Unicast-Prefix-based IPv6 Multicast Address Compression
図10：dam = 00。ユニキャスト-PrefixベースのIPv6マルチキャストアドレス圧縮
Note that the Reserved field MUST carry the reserved bits from the multicast address format as described in [RFC3306]. When a Rendezvous Point is encoded in the multicast address as described in [RFC3956], the Reserved field carries the RIID bits in-line.
[RFC3306]で説明されているように、予約済みフィールドはマルチキャストアドレス形式から予約ビットを運ぶ必要があることに注意してください。[RFC3956]で説明されているように、ランデブーポイントがマルチキャストアドレスにエンコードされると、予約済みフィールドにはRIIDビットがインラインになります。
LOWPAN_IPHC elides the IPv6 Next Header field when the NH bit is set to 1. This also indicates the use of 6LoWPAN next header compression, LOWPAN_NHC. The value of IPv6 Next Header is recovered from the first bits in the LOWPAN_NHC encoding. The following bits are specific to the IPv6 Next Header value. Figure 11 shows the structure of an IPv6 datagram compressed using LOWPAN_IPHC and LOWPAN_NHC.
lowPAN_IPHCは、NHビットが1に設定されている場合、IPv6次のヘッダーフィールドを排除します。これは、6lowpan Nextヘッダー圧縮、LowPAN_NHCの使用も示しています。IPv6次のヘッダーの値は、LowPAN_NHCエンコーディングの最初のビットから回収されます。次のビットは、IPv6次のヘッダー値に固有です。図11は、LowPAN_IPHCとLowPAN_NHCを使用して圧縮されたIPv6データグラムの構造を示しています。
+-------------+-------------+-------------+-----------------+--------
| LOWPAN_IPHC | In-line | LOWPAN_NHC | In-line Next | Payload
| Encoding | IP Fields | Encoding | Header Fields |
+-------------+-------------+-------------+-----------------+--------
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圧縮ヘッダーの直後の可変長ビットパターンによって識別されます。次のヘッダー圧縮形式を定義する場合、使用するビットの数は、その形式を使用する頻度が認識されていることによって決定される必要があります。ただし、ビット数と残りのエンコードビットの数は、Octetの整合を尊重する必要があります。次のビットは、次のヘッダー圧縮形式に固有です。このドキュメントでは、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エンコーディングは、単一のLowPAN_NHCオクテットに続いてIPv6拡張ヘッダーで構成されています。LowPAN_NHCオクテットの形式を図13に示します。最初の7ビットは、LowPAN_NHCオクテットの直後のIPv6拡張ヘッダーの識別子として機能します。残りのビットは、次のヘッダーがLowPAN_NHCエンコードを利用しているかどうかを示します。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 | 1 | 1 | 0 | EID |NH |
+---+---+---+---+---+---+---+---+
Figure 13: IPv6 Extension Header Encoding
図13：IPv6拡張ヘッダーエンコーディング
EID: IPv6 Extension Header ID:
EID：IPv6拡張ヘッダーID：
0: IPv6 Hop-by-Hop Options Header [RFC2460]
0：IPv6ホップバイホップオプションヘッダー[RFC2460]
1: IPv6 Routing Header [RFC2460]
1：IPv6ルーティングヘッダー[RFC2460]
2: IPv6 Fragment Header [RFC2460]
2：IPv6フラグメントヘッダー[RFC2460]
3: IPv6 Destination Options Header [RFC2460]
3：IPv6宛先オプションヘッダー[RFC2460]
4: IPv6 Mobility Header [RFC6275]
4：IPv6モビリティヘッダー[RFC6275]
5: Reserved
5：予約済み
6: Reserved
6：予約済み
7: IPv6 Header
7：IPv6ヘッダー
NH: Next Header:
NH：次のヘッダー：
0: Full 8 bits for Next Header are carried in-line.
0：次のヘッダーのフル8ビットは、インラインで運ばれます。
1: The Next Header field is elided and the next header is encoded using LOWPAN_NHC, which is discussed in Section 4.1.
1：次のヘッダーフィールドが削除され、次のヘッダーはlowPAN_NHCを使用してエンコードされます。これについてはセクション4.1で説明します。
For the most part, the IPv6 Extension Header is carried unmodified in the bytes immediately following the LOWPAN_NHC octet, with two important exceptions: Length field and Next Header field.
ほとんどの場合、IPv6拡張ヘッダーは、LowPAN_NHCオクテットの直後のバイトで変更されていません。長さフィールドと次のヘッダーフィールドの2つの重要な例外を除きます。
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.
IPv6エクステンションヘッダーに含まれる次のヘッダーフィールドは、NHビットがOctetをエンコードするLowPAN_NHCに設定されると排除されます。そうすることで、LowPAN_NHCは、非エンコードされていないIPv6拡張ヘッダーよりもオーバーヘッドを使用することはできません。
The Length field contained in a compressed IPv6 Extension Header indicates the number of octets that pertain to the (compressed) extension header following the Length field. Note that this changes the Length field definition in [RFC2460] from indicating the header size in 8-octet units, not including the first 8 octets. Changing the Length field to be in units of octets removes wasteful internal fragmentation.
圧縮されたIPv6拡張ヘッダーに含まれる長さフィールドは、長さフィールドに続く（圧縮）拡張ヘッダーに関係するオクテットの数を示します。これにより、[RFC2460]の長さフィールド定義は、最初の8オクテットを含まない8オクテット単位のヘッダーサイズを示すことから変更されることに注意してください。長さフィールドをオクテットの単位に変更すると、無駄な内部断片化が削除されます。
IPv6 Hop-by-Hop and Destination Options Headers may use a trailing Pad1 or PadN to achieve 8-octet alignment. When there is a single trailing Pad1 or PadN option of 7 octets or less and the containing header is a multiple of 8 octets, the trailing Pad1 or PadN option MAY be elided by the compressor. A decompressor MUST ensure that the containing header is padded out to a multiple of 8 octets in length, using a Pad1 or PadN option if necessary. Note that Pad1 and PadN options that appear in locations other than the end MUST be carried in-line as they are used to align subsequent options.
IPv6ホップバイホップおよび宛先オプションヘッダーは、トレーリングPAD1またはPADNを使用して8-OCTETアライメントを実現できます。7オクテット以下の単一の末尾のPAD1またはPADNオプションがあり、含まれるヘッダーが8オクテットの倍数である場合、トレーリングPAD1またはPADNオプションはコンプレッサーによって除外される場合があります。減圧装置は、必要に応じてPAD1またはPADNオプションを使用して、含まれるヘッダーが長さ8オクテットの倍数にパッドで塗装されていることを確認する必要があります。端以外の場所に表示されるPAD1およびPADNオプションは、後続のオプションを調整するために使用されるため、インラインで携帯する必要があることに注意してください。
Note that specifying units in octets means that LOWPAN_NHC MUST NOT be used to encode IPv6 Extension Headers that have more than 255 octets following the Length field after compression.
オクテットのユニットの指定は、圧縮後に長さフィールドに続いて255を超えるオクテットを持つIPv6拡張ヘッダーをエンコードするためにLowPAN_NHCを使用してはならないことを意味することに注意してください。
When the identified next header is an IPv6 Header (EID=7), the NH bit of the LOWPAN_NHC encoding is unused and MUST be set to zero. The following bytes MUST be encoded using LOWPAN_IPHC as defined in Section 3.
識別された次のヘッダーがIPv6ヘッダー（EID = 7）である場合、LowPAN_NHCエンコードのNHビットは未使用であり、ゼロに設定する必要があります。セクション3で定義されているように、LowPAN_IPHCを使用して、次のバイトをエンコードする必要があります。
This document defines a compression format for UDP headers using LOWPAN_NHC. The UDP compression format is shown in Figure 14. Bits 0 through 4 represent the NHC ID and '11110' indicates the specific UDP header compression encoding defined in this section.
このドキュメントでは、LowPAN_NHCを使用してUDPヘッダーの圧縮形式を定義しています。UDP圧縮形式を図14に示します。ビット0〜4はNHC IDを表し、「11110」はこのセクションで定義されている特定のUDPヘッダー圧縮エンコードを示します。
This specification allows a particular range of ports number (0xf0b0 to 0xf0bf) to be compressed down to 4 bits. This is a stateless compression that is inherited from [RFC4944], as opposed to a new stateful compression.
この仕様により、特定の範囲のポート番号（0xf0b0〜0xf0bf）を4ビットまで圧縮できます。これは、新しいステートフルな圧縮とは対照的に、[RFC4944]から継承されるステートレス圧縮です。
The range of ports compressible down to 4 bits is not in a reserved range. A network stack implementation that is designed to communicate over a 6LoWPAN should avoid using those ports as dynamic ports whenever possible.
4ビットまで圧縮可能なポートの範囲は、予約範囲にありません。6lowpanで通信するように設計されたネットワークスタックの実装は、可能な限り動的ポートとしてそれらのポートを使用することを避ける必要があります。
Considering that this represents only 16 contiguous ports, it can be expected that many incompatible applications will use the same value of port numbers for their own end-to-end needs. Thus, a port number in the (0xf0b0 to 0xf0bf) range provides very little information about the application at the remote end.
これが16の連続したポートのみを表していることを考慮すると、多くの互換性のないアプリケーションが、独自のエンドツーエンドのニーズに同じ値のポート番号を使用することが予想されます。したがって、（0xf0b0〜0xf0bf）範囲のポート番号は、リモートエンドでのアプリケーションに関する情報をほとんど提供しません。
The overloading of the 0xf0bX ports increases the risk of getting the wrong type of payload and misinterpreting the content compared to ports that are reserved at IANA. As a result, it is recommended that the use of those ports be associated with a mechanism such as a Transport Layer Security (TLS) [RFC5246] Message Integrity Check (MIC) that makes sure that the content is what is expected and is checked.
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チェックサムを排除する場合があります。コンプレッサーは、そのような許可を受け取っていない限り、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を介して既存のフィールドプロトコルをトンネリングすることにより、ワイヤレス擬似フィールドバスとして展開されます。Tunneled Protocol Data Unit（PDU）が独自のアドレス指定、セキュリティ、および整合性チェック（例えば、UDPカプセル化を介したセキュリティペイロードトンネルモード[RFC4303]またはIPカプセル化のIPSEC）を所有している場合、トンネルメカニズムは、UDPチェックスムを節約するためにUDPチェックを緩和することを許可する可能性があります。カプセル化オーバーヘッド。
Message Integrity Check: In this case, either IPsec Authentication Header [RFC4302] or some other form of integrity check in the UDP payload that covers at least the same information as the UDP checksum (pseudo-header, data) and has at least the same strength.
メッセージの整合性チェック：この場合、IPSEC認証ヘッダー[RFC4302]またはUDPチェックサム（Pseudo-Header、データ）と少なくとも同じ情報をカバーし、少なくとも同じ情報をカバーする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パケットが意図しない目的地に配信される場合があります。
A compressor MUST verify the UDP Checksum before it is elided and MUST ensure that the additional integrity check is in place before verifying and eliding the checksum. If verification of the UDP Checksum fails, the compressor MUST drop the packet.
コンプレッサーは、UDPチェックサムを排除する前に検証する必要があり、チェックサムを検証および排除する前に、追加の整合性チェックが整っていることを確認する必要があります。UDPチェックサムの検証が失敗した場合、コンプレッサーはパケットをドロップする必要があります。
A decompressor that expands a 6LoWPAN packet with the C bit set MUST compute the UDP Checksum on behalf of the source node and place that value in the restored UDP header as specified in the incumbent standards [RFC0768], [RFC2460]. The decompressor MUST unambiguously determine that an additional integrity check was put in place by the compressor and verify the integrity check and SHOULD do so after restoring the UDP Checksum. If the decompressor cannot unambiguously determine the presence of an integrity check or verification fails, the decompressor MUST drop the packet.
Cビットセットで6lowpanパケットを拡張する減圧装置は、ソースノードに代わってUDPチェックサムを計算し、現職基準[RFC0768]、[RFC2460]で指定された復元されたUDPヘッダーにその値を配置する必要があります。減圧器は、コンプレッサーによって追加の整合性チェックが導入されたことを明確に判断し、整合性チェックを検証する必要があり、UDPチェックサムを復元した後にそうする必要があります。減圧装置が整合性チェックの存在または検証の存在を明確に決定できない場合、減圧器はパケットをドロップする必要があります。
The recommended ordering of computing and verifying the UDP Checksum and additional integrity check ensures that data is never stored unprotected in memory. In practice, functionality separation between layers may preclude the recommended ordering. However, implementors should take special note and understand the risks when dealing with unprotected data covered by the pseudo-header.
コンピューティングの推奨される順序とUDPチェックサムと追加の整合性チェックの検証により、データがメモリに保護されていないことが保存されないようにします。実際には、レイヤー間の機能分離は、推奨される順序を排除する可能性があります。ただし、実装者は特別なメモを取り、擬似ヘッダーがカバーする保護されていないデータを扱う際にリスクを理解する必要があります。
To allow intermediate nodes to compress the UDP Checksum, a forwarding node MAY infer upper-layer authorization for an incoming packet if it has the C bit set and it can unambiguously determine that an integrity check covering the same data as the UDP Checksum was in place while the UDP Checksum was elided. A forwarding node MUST NOT infer authorization if it cannot unambiguously determine the presence of and verify an integrity check while the UDP Checksum was elided.
中間ノードがUDPチェックサムを圧縮できるようにするために、転送ノードは、Cビットセットがある場合、着信パケットの上層層許可を推測し、UDPチェックサムと同じデータをカバーする整合性チェックが存在することを明確に判断できます。UDPチェックサムが排除されました。転送ノードは、UDPチェックサムが削除されている間に整合性チェックの存在を明確に決定し、検証できない場合、認可を推測してはなりません。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 | 1 | 1 | 1 | 0 | C | P |
+---+---+---+---+---+---+---+---+
Figure 14: UDP Header Encoding
図14：UDPヘッダーエンコーディング
C: Checksum:
C：チェックサム：
0: All 16 bits of Checksum are carried in-line.
0：16ビットのチェックサムは、インラインで運ばれます。
1: All 16 bits of Checksum are elided. The Checksum is recovered by recomputing it on the 6LoWPAN termination point.
1：16ビットのチェックサムはすべて省略されています。チェックサムは、6Lowpan終了ポイントで再計算することにより回収されます。
P: Ports:
P：ポート：
00: All 16 bits for both Source Port and Destination Port are carried in-line.
00：ソースポートと宛先ポートの両方の16ビットはすべて、インラインで運ばれます。
01: All 16 bits for Source Port are carried in-line. First 8 bits of Destination Port is 0xf0 and elided. The remaining 8 bits of Destination Port are carried in-line.
01：ソースポート用の16ビットすべてがインラインで運ばれます。宛先ポートの最初の8ビットは0xf0で除外されています。残りの8ビットの宛先ポートは、インラインで運ばれます。
10: First 8 bits of Source Port are 0xf0 and elided. The remaining 8 bits of Source Port are carried in-line. All 16 bits for Destination Port are carried in-line.
10：最初の8ビットのソースポートは0xf0で除外されています。残りの8ビットのソースポートは、インラインで運ばれます。宛先ポート用の16ビットはすべて、インラインで運ばれます。
11: First 12 bits of both Source Port and Destination Port are 0xf0b and elided. The remaining 4 bits for each are carried in-line.
11：ソースポートと宛先ポートの両方の最初の12ビットは0xF0Bで除外されています。それぞれの残りの4ビットは、インラインで運ばれます。
Fields carried in-line (in part or in whole) appear in the same order as they do in the UDP header format [RFC0768]. The UDP Length field MUST always be elided and is inferred from lower layers using the 6LoWPAN Fragmentation header or the IEEE 802.15.4 header.
インラインで運ばれるフィールド（一部または全体）は、UDPヘッダー形式[RFC0768]で行うのと同じ順序で表示されます。UDPの長さフィールドは常に排除する必要があり、6lowpanフラグメンテーションヘッダーまたはIEEE 802.15.4ヘッダーを使用して下層から推測されます。
This document defines a new IPv6 header compression format for 6LoWPAN. The document allocates the following 32 Dispatch type field values for LOWPAN_IPHC:
このドキュメントでは、6lowpan用の新しいIPv6ヘッダー圧縮形式を定義しています。このドキュメントでは、LowPAN_IPHCの次の32ディスパッチタイプフィールド値を割り当てます。
01 100000 through 01 111111
01 100000から01 111111
This assignment preempts the assignment of 01 111111 for ESC [RFC4944]; this preemption is possible because extension bytes that would enable the use of ESC have not been allocated yet. Instead, the value:
この割り当ては、ESC [RFC4944]の01 111111の割り当てを先取りします。ESCの使用を可能にする拡張バイトがまだ割り当てられていないため、この先制は可能です。代わりに、値：
01 000000
01 000000
is reserved as a replacement value for ESC, to be finally assigned with the first assignment of extension bytes.
ESCの交換値として予約されており、最終的に拡張バイトの最初の割り当てで割り当てられます。
This document also creates a new IANA registry for the LOWPAN_NHC header type, with the following initial content:
このドキュメントでは、以下の初期コンテンツを使用して、LowPAN_NHCヘッダータイプの新しいIANAレジストリも作成します。
00000000 to 11011111: (unassigned)
1110000N: IPv6 Hop-by-Hop Options Header [RFC6282]
1110001N: IPv6 Routing Header [RFC6282]
1110010N: IPv6 Fragment Header [RFC6282]
1110011N: IPv6 Destination Options Header [RFC6282]
1110100N: IPv6 Mobility Header [RFC6282]
1110111N: IPv6 Header [RFC6282]
11110CPP: UDP Header [RFC6282]
11111000 to 11111110: (unassigned)
Capital letters in bit positions represent class-specific bit assignments. N indicates whether or not additional LOWPAN_NHC encodings follow, as defined in Section 4.2. CPP represents variables specific to UDP header compression defined in Section 4.3.
ビットポジションの大文字は、クラス固有のビット割り当てを表します。nは、セクション4.2で定義されているように、追加のLowPAN_NHCエンコーディングが続くかどうかを示します。CPPは、セクション4.3で定義されたUDPヘッダー圧縮に固有の変数を表します。
The policy for this registry [RFC5226] is IETF Review. In this process, new values SHOULD be assigned in a way that preserves the NHC ID abstraction of Section 4 (i.e., k one-bits followed by one zero-bit identify the general class of NHC, followed by class-specific bit assignments).
このレジストリ[RFC5226]のポリシーはIETFレビューです。このプロセスでは、セクション4のNHC ID抽象化を保持するように新しい値を割り当てる必要があります（つまり、Kワンビットに続いて1つのゼロビットがNHCの一般クラスを識別し、その後クラス固有のビット割り当てを識別します）。
The definition of LOWPAN_IPHC permits the compression of header information on communication that could take place in its absence, albeit in a less efficient form. It recognizes that a IEEE 802.15.4 PAN may have associated with it a number of prefixes through shared context. How the shared context is assigned and managed is beyond the scope of this document.
LowPAN_IPHCの定義により、あまり効率的ではありませんが、その不在で発生する可能性のある通信に関するヘッダー情報の圧縮が可能になります。IEEE 802.15.4 PANが共有コンテキストを介して多くのプレフィックスを関連付けている可能性があることを認識しています。共有コンテキストの割り当ておよび管理方法は、このドキュメントの範囲を超えています。
The overloading of the 0xf0bX ports increases the risk of getting the wrong type of payload and misinterpreting the content compared to ports that reserved at IANA. It is thus recommended that the use of 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.
ジュリエン・アベイユ、ロバート・アシミティ、ドミニク・バーセル、カルステン・ボーマン、ロバート・クラギー、スティーブン・ドーソン・ハガティ、マチルデ・ダービー、エリック・ノードマーク、クリストス・ポリゾワ、ジョセフ・レディ、靴チ・サケーン、ザッハ・シェルビー、ダリオ・テデスイ、ジェイ・ウェルブ・ウェルブのために有用な設計の考慮と実装フィードバック。David Black、Lars Eggert、およびCarsten Bormannに、UDP圧縮に関するセキュリティ問題を埋めることに貢献してくれたことに感謝します。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768] POSTEL、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、1980年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「Internet Protocol、Version 6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「IPv4およびIPv6ヘッダーの差別化されたサービスフィールド（DSフィールド）の定義」、RFC 2474、1998年12月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168] Ramakrishnan、K.、Floyd、S。、およびD. Black、「IPへの明示的な混雑通知（ECN）の追加」、RFC 3168、2001年9月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレス指定アーキテクチャ」、RFC 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] Montenegro、G.、Kushalnagar、N.、Hui、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] Perkins、C.、ed。、Johnson、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 Computer Society、「IEEEStd。802.15.4-2006」、2006年10月。
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, August 2002.
[RFC3306] Haberman、B。およびD. Thaler、「Unicast-Prefixベースの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.、R.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6の動的ホスト構成プロトコル」、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. Haberman、「IPv6マルチキャストアドレスにRendezvous Point（RP）アドレスを埋め込む」、RFC 3956、2004年11月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302] Kent、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロードのカプセル化（ESP）」、RFC 4303、2005年12月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「IPバージョン6（IPv6）の近隣発見」、RFC 4861、2007年9月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（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 2nd St. Ste。410カリフォルニア州サンフランシスコ94107 USA
Phone: +415 692 0828
EMail: jhui@archrock.com
Pascal Thubert Cisco Systems Village d'Entreprises Green Side 400, Avenue de Roumanille Batiment T3 Biot - Sophia Antipolis 06410 FRANCE
Pascal Thubert Cisco Systems Village D'Entreprises Green Side 400、Avenue de Roumanille Batiment T3 Biot -Sophia Antipolis 06410 France
Phone: +33 4 97 23 26 34
EMail: pthubert@cisco.com