[要約] RFC 7428は、ITU-T G.9959ネットワーク上でのIPv6パケットの伝送に関する標準化された手順を提供します。このRFCの目的は、ITU-T G.9959ネットワーク上でIPv6をサポートするためのガイドラインを提供することです。
Internet Engineering Task Force (IETF) A. Brandt
Request for Comments: 7428 J. Buron
Category: Standards Track Sigma Designs
ISSN: 2070-1721 February 2015
Transmission of IPv6 Packets over ITU-T G.9959 Networks
ITU-T G.9959ネットワークを介したIPv6パケットの送信
Abstract
概要
This document describes the frame format for transmission of IPv6 packets as well as a method of forming IPv6 link-local addresses and statelessly autoconfigured IPv6 addresses on ITU-T G.9959 networks.
このドキュメントでは、IPv6パケットを送信するためのフレーム形式、およびITU-T G.9959ネットワーク上でIPv6リンクローカルアドレスとステートレスに自動構成されたIPv6アドレスを形成する方法について説明します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7428.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7428で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Terms Used .................................................3
1.2. Requirements Language ......................................4
2. G.9959 Parameters to Use for IPv6 Transport .....................5
2.1. Addressing Mode ............................................5
2.2. IPv6 Multicast Support .....................................6
2.3. G.9959 MAC PDU Size and IPv6 MTU ...........................6
2.4. Transmission Status Indications ............................7
2.5. Transmission Security ......................................7
3. 6LoWPAN Adaptation Layer and Frame Format .......................7
3.1. Dispatch Header ............................................8
4. 6LoWPAN Addressing ..............................................9
4.1. Stateless Address Autoconfiguration of Routable IPv6
Addresses ..................................................9
4.2. IPv6 Link-Local Address ...................................10
4.3. Unicast Address Mapping ...................................10
4.4. On the Use of Neighbor Discovery Technologies .............11
4.4.1. Prefix and CID Management (Route-Over) .............11
4.4.2. Prefix and CID Management (Mesh-Under) .............11
5. Header Compression .............................................12
6. Security Considerations ........................................13
7. Privacy Considerations .........................................14
8. References .....................................................14
8.1. Normative References ......................................14
8.2. Informative References ....................................16
Appendix A. G.9959 6LoWPAN Datagram Example .......................17
Acknowledgements ..................................................21
Authors' Addresses ................................................21
The ITU-T G.9959 recommendation [G.9959] targets low-power Personal Area Networks (PANs). This document defines the frame format for transmission of IPv6 [RFC2460] packets as well as the formation of IPv6 link-local addresses and statelessly autoconfigured IPv6 addresses on G.9959 networks.
ITU-T G.9959勧告[G.9959]は、低電力パーソナルエリアネットワーク（PAN）を対象としています。このドキュメントでは、IPv6 [RFC2460]パケットの送信のフレーム形式と、G.9959ネットワークでのIPv6リンクローカルアドレスとステートレスに自動構成されたIPv6アドレスの形成について定義します。
The general approach is to adapt elements of [RFC4944] to G.9959 networks. G.9959 provides a Segmentation and Reassembly (SAR) layer for transmission of datagrams larger than the G.9959 Media Access Control Protocol Data Unit (MAC PDU).
一般的なアプローチは、[RFC4944]の要素をG.9959ネットワークに適合させることです。 G.9959は、G.9959メディアアクセスコントロールプロトコルデータユニット（MAC PDU）よりも大きいデータグラムを送信するためのセグメンテーションおよび再構成（SAR）レイヤーを提供します。
[RFC6775] updates [RFC4944] by specifying IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) optimizations for IPv6 Neighbor Discovery (ND) (originally defined by [RFC4861]). This document limits the use of [RFC6775] to prefix and Context ID assignment. An Interface Identifier (IID) may be constructed from a G.9959 link-layer address, leading to a "link-layer-derived IPv6 address". If using that method, Duplicate Address Detection (DAD) is not needed. Alternatively, IPv6 addresses may be assigned centrally via DHCP, leading to a "non-link-layer-derived IPv6 address". Address registration is only needed in certain cases.
[RFC6775]は、IPv6 Neighbor Discovery（ND）（元は[RFC4861]で定義）のIPv6 over Low-Power Wireless Personal Area Network（6LoWPAN）最適化を指定して[RFC4944]を更新します。このドキュメントでは、[RFC6775]の使用を接頭辞とコンテキストIDの割り当てに制限しています。インターフェイス識別子（IID）は、G.9959リンク層アドレスから構築され、「リンク層から派生したIPv6アドレス」につながる可能性があります。その方法を使用する場合、重複アドレス検出（DAD）は必要ありません。あるいは、IPv6アドレスはDHCPを介して集中的に割り当てられ、「非リンク層派生IPv6アドレス」につながる可能性があります。アドレス登録は、特定の場合にのみ必要です。
In addition to IPv6 application communication, the frame format defined in this document may be used by IPv6 routing protocols such as the Routing Protocol for Low-Power and Lossy Networks (RPL) [RFC6550] or Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks (P2P-RPL) [RFC6997] to implement IPv6 routing over G.9959 networks.
IPv6アプリケーション通信に加えて、このドキュメントで定義されているフレーム形式は、低電力および損失の多いネットワーク（RPL）のルーティングプロトコル（RFC6550）またはポイントツーポイントルートのリアクティブディスカバリなどのIPv6ルーティングプロトコルで使用できます。低電力および損失の多いネットワーク（P2P-RPL）[RFC6997]は、G.9959ネットワーク上でIPv6ルーティングを実装します。
The encapsulation frame defined by this specification may optionally be transported via mesh routing below the 6LoWPAN layer. Mesh-under and route-over routing protocol specifications are out of scope for this document.
この仕様で定義されているカプセル化フレームは、オプションで6LoWPANレイヤーの下のメッシュルーティングを介して転送できます。メッシュアンダーおよびルートオーバールーティングプロトコルの仕様は、このドキュメントの範囲外です。
6LoWPAN: IPv6 over Low-Power Wireless Personal Area Network
6LoWPAN：低電力ワイヤレスパーソナルエリアネットワーク上のIPv6
ABR: Authoritative 6LoWPAN Border Router (Authoritative 6LBR) [RFC6775]
ABR：権威6LoWPANボーダールーター（権威6LBR）[RFC6775]
Ack: Acknowledgement
Ack：謝辞
AES: Advanced Encryption Standard
AES：Advanced Encryption Standard
CID: Context Identifier [RFC6775]
CID：コンテキスト識別子[RFC6775]
DAD: Duplicate Address Detection [RFC6775]
DAD：重複アドレス検出[RFC6775]
DHCPv6: Dynamic Host Configuration Protocol for IPv6 [RFC3315]
DHCPv6：IPv6の動的ホスト構成プロトコル[RFC3315]
EUI-64: Extended Unique Identifier [EUI64]
EUI-64：拡張一意識別子[EUI64]
G.9959: Short range narrow-band digital radiocommunication transceiver [G.9959]
G.9959：短距離狭帯域デジタル無線通信トランシーバー[G.9959]
GHC: Generic Header Compression [RFC7400]
GHC：一般的なヘッダー圧縮[RFC7400]
HomeID: G.9959 Link-Layer Network Identifier
HomeID：G.9959リンク層ネットワーク識別子
IID: Interface Identifier Link-layer-derived address: IPv6 address constructed on the basis of link-layer address information
IID：インターフェース識別子リンク層派生アドレス：リンク層アドレス情報に基づいて構築されたIPv6アドレス
MAC: Media Access Control
MAC：メディアアクセスコントロール
Mesh-under: Forwarding via mesh routing below the 6LoWPAN layer
Mesh-under：6LoWPANレイヤーの下のメッシュルーティングによる転送
MTU: Maximum Transmission Unit
MTU：最大転送単位
ND: Neighbor Discovery [RFC4861] [RFC6775]
ND：近隣探索[RFC4861] [RFC6775]
NodeID: G.9959 Link-Layer Node Identifier
NodeID：G.9959リンク層ノード識別子
Non-link-layer-derived address: IPv6 address assigned by a managed process, e.g., DHCPv6
非リンク層派生アドレス：DHCPv6などの管理対象プロセスによって割り当てられたIPv6アドレス
P2P-RPL: Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks [RFC6997]
P2P-RPL：低電力および損失の多いネットワークでのポイントツーポイントルートのリアクティブディスカバリ[RFC6997]
PAN: Personal Area Network
PAN：パーソナルエリアネットワーク
PDU: Protocol Data Unit
PDU：プロトコルデータユニット
PHY: Physical Layer
PHY：物理層
RA: Router Advertisement [RFC4861] [RFC6775]
RA：ルーターアドバタイズメント[RFC4861] [RFC6775]
Route-over: Forwarding via IP routing above the 6LoWPAN layer
ルートオーバー：6LoWPANレイヤーの上のIPルーティングを介した転送
RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks [RFC6550]
RPL：低電力および損失の多いネットワーク用のIPv6ルーティングプロトコル[RFC6550]
SAR: G.9959 Segmentation and Reassembly
SAR：G.9959セグメンテーションおよび再構成
ULA: Unique Local Address [RFC4193]
ULA：一意のローカルアドレス[RFC4193]
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
This section outlines properties applying to the PHY and MAC layers of G.9959 and how to use these for IPv6 transport.
このセクションでは、G.9959のPHY層とMAC層に適用されるプロパティと、IPv6トランスポートでこれらを使用する方法について概説します。
G.9959 defines how a unique 32-bit HomeID network identifier is assigned by a network controller and how an 8-bit NodeID host identifier is allocated to each node. NodeIDs are unique within the network identified by the HomeID. The G.9959 HomeID represents an IPv6 subnet that is identified by one or more IPv6 prefixes.
G.9959は、一意の32ビットHomeIDネットワーク識別子がネットワークコントローラーによって割り当てられる方法と、8ビットNodeIDホスト識別子が各ノードに割り当てられる方法を定義します。 NodeIDは、HomeIDによって識別されるネットワーク内で一意です。 G.9959 HomeIDは、1つ以上のIPv6プレフィックスによって識別されるIPv6サブネットを表します。
An IPv6 host MUST construct its link-local IPv6 address from the link-layer-derived IID in order to facilitate IP header compression as described in [RFC6282].
[RFC6282]で説明されているIPヘッダー圧縮を容易にするために、IPv6ホストはリンク層から派生したIIDからリンクローカルIPv6アドレスを構築する必要があります。
A node interface MAY support the M flag of the RA message for the construction of routable IPv6 addresses. A cost-optimized node implementation may save memory by skipping support for the M flag. The M flag MUST be interpreted as defined in Figure 1.
ノードインターフェースは、ルーティング可能なIPv6アドレスの構築のためにRAメッセージのMフラグをサポートする場合があります。コストが最適化されたノードの実装では、Mフラグのサポートをスキップすることでメモリを節約できます。 Mフラグは、図1で定義されているように解釈する必要があります。
+--------+--------+---------------------------------------------+
| M flag | M flag | Required node behavior |
| support| value | |
+--------+--------+---------------------------------------------+
| No |(ignore)| Node MUST use link-layer-derived addressing |
+--------+--------+---------------------------------------------+
| Yes | 0 | Node MUST use link-layer-derived addressing |
| +--------+---------------------------------------------+
| | 1 | Node MUST use DHCPv6-based addressing, and |
| | | node MUST comply fully with [RFC6775] |
+--------+--------+---------------------------------------------+
Figure 1: RA M Flag Support and Interpretation
図1：RA Mフラグのサポートと解釈
A node that uses DHCPv6-based addressing MUST comply fully with the text of [RFC6775].
DHCPv6ベースのアドレス指定を使用するノードは、[RFC6775]のテキストに完全に準拠する必要があります。
If DHCPv6-based addressing is used, the DHCPv6 client must use a DHCPv6 Unique Identifier (DUID) of type DUID-UUID, as described in [RFC6355]. The Universally Unique Identifier (UUID) used in the DUID-UUID must be generated as specified in [RFC4122], Section 4.5, starting at the third paragraph in that section (the 47-bit random number-based UUID). The DUID must be stored persistently by the node as specified in Section 3 of [RFC6355].
DHCPv6ベースのアドレス指定が使用される場合、DHCPv6クライアントは、[RFC6355]で説明されているように、タイプDUID-UUIDのDHCPv6一意識別子（DUID）を使用する必要があります。 DUID-UUIDで使用されるUniversally Unique Identifier（UUID）は、[RFC4122]のセクション4.5（47ビットの乱数ベースのUUID）の3番目の段落から始まるように生成される必要があります。 [RFC6355]のセクション3で指定されているように、DUIDはノードによって永続的に保存される必要があります。
A word of caution: since HomeIDs and NodeIDs are handed out by a network controller function during inclusion, identifier validity and uniqueness are limited by the lifetime of the network membership. This can be cut short by a mishap occurring at the network controller. Having a single point of failure at the network controller suggests that high-reliability network deployments may benefit from a redundant network controller function.
注意：HomeIDとNodeIDはインクルード中にネットワークコントローラー機能によって渡されるため、識別子の有効性と一意性はネットワークメンバーシップのライフタイムによって制限されます。これは、ネットワークコントローラーで発生した事故によって短縮できます。ネットワークコントローラーに単一障害点があることは、信頼性の高いネットワーク展開が冗長ネットワークコントローラー機能の恩恵を受ける可能性があることを示唆しています。
This warning applies to link-layer-derived addressing as well as to non-link-layer-derived addressing deployments.
この警告は、リンク層から派生したアドレス指定とリンク層から派生していないアドレス配置に適用されます。
[RFC3819] recommends that IP subnetworks support (subnet-wide) multicast. G.9959 supports direct-range IPv6 multicast, while subnet-wide multicast is not supported natively by G.9959. Subnet-wide multicast may be provided by an IP routing protocol or a mesh routing protocol operating below the 6LoWPAN layer. Routing protocol specifications are out of scope for this document.
[RFC3819]は、IPサブネットワークが（サブネット全体の）マルチキャストをサポートすることを推奨しています。 G.9959は直接範囲のIPv6マルチキャストをサポートしますが、サブネット全体のマルチキャストはG.9959でネイティブにサポートされていません。サブネット全体のマルチキャストは、6LoWPAN層の下で動作するIPルーティングプロトコルまたはメッシュルーティングプロトコルによって提供されます。ルーティングプロトコルの仕様は、このドキュメントの範囲外です。
IPv6 multicast packets MUST be carried via G.9959 broadcast.
IPv6マルチキャストパケットは、G.9959ブロードキャストを介して伝送する必要があります。
As per [G.9959], this is accomplished as follows:
[G.9959]に従って、これは次のように行われます。
1. The destination HomeID of the G.9959 MAC PDU MUST be the HomeID of the network.
1. G.9959 MAC PDUの宛先HomeIDは、ネットワークのHomeIDでなければなりません。
2. The destination NodeID of the G.9959 MAC PDU MUST be the broadcast NodeID (0xff).
2. G.9959 MAC PDUの宛先NodeIDは、ブロードキャストNodeID（0xff）である必要があります。
G.9959 broadcast MAC PDUs are only intercepted by nodes within the network identified by the HomeID.
G.9959ブロードキャストMAC PDUは、HomeIDで識別されるネットワーク内のノードによってのみ傍受されます。
IPv6 packets MUST be transmitted using G.9959 transmission profile R3 or higher.
IPv6パケットは、G.9959送信プロファイルR3以上を使用して送信する必要があります。
[RFC2460] specifies that any link that cannot convey a 1280-octet packet in one piece must provide link-specific fragmentation and reassembly at a layer below IPv6.
[RFC2460]は、1280オクテットパケットを1つのピースで伝達できないリンクは、IPv6の下のレイヤーでリンク固有の断片化と再構成を提供する必要があることを指定しています。
G.9959 provides segmentation and reassembly for payloads up to 1350 octets. IPv6 header compression [RFC6282] improves the chances that a short IPv6 packet can fit into a single G.9959 frame. Therefore, Section 3 of this document specifies that [RFC6282] MUST be supported. With the mandatory link-layer security enabled, a G.9959 R3 MAC PDU may accommodate 6LoWPAN datagrams of up to 130 octets without triggering G.9959 segmentation and reassembly. Longer 6LoWPAN datagrams will lead to the transmission of multiple G.9959 PDUs.
G.9959は、最大1350オクテットのペイロードのセグメンテーションと再構成を提供します。 IPv6ヘッダー圧縮[RFC6282]は、短いIPv6パケットが単一のG.9959フレームに収まる可能性を向上させます。したがって、このドキュメントのセクション3では、[RFC6282]をサポートする必要があると明記されています。必須のリンク層セキュリティを有効にすると、G.9959 R3 MAC PDUは、G.9959のセグメンテーションと再構成をトリガーせずに、最大130オクテットの6LoWPANデータグラムに対応できます。 6LoWPANデータグラムが長いと、複数のG.9959 PDUが送信されます。
The G.9959 MAC layer provides native acknowledgement and retransmission of MAC PDUs. The G.9959 SAR layer does the same for larger datagrams. A mesh routing layer may provide a similar feature for routed communication. An IPv6 routing stack communicating over G.9959 may utilize link-layer status indications such as delivery confirmation and Ack timeout from the MAC layer.
G.9959 MAC層は、MAC PDUのネイティブ確認応答と再送信を提供します。 G.9959 SARレイヤーは、より大きなデータグラムに対して同じことを行います。メッシュルーティングレイヤーは、ルーティングされた通信に同様の機能を提供します。 G.9959を介して通信するIPv6ルーティングスタックは、MAC層からの配信確認やAckタイムアウトなどのリンク層ステータス表示を利用できます。
Implementations claiming conformance with this document MUST enable G.9959 shared network key security.
このドキュメントへの準拠を主張する実装は、G.9959共有ネットワークキーセキュリティを有効にする必要があります。
The shared network key is intended to address security requirements in the home at the normal level of security requirements. For applications with high or very high requirements for confidentiality and/or integrity, additional application-layer security measures for end-to-end authentication and encryption may need to be applied. (The availability of the network relies on the security properties of the network key in any case.)
共有ネットワークキーは、通常のレベルのセキュリティ要件で家庭のセキュリティ要件に対処することを目的としています。機密性や整合性の要件が高い、または非常に高いアプリケーションでは、エンドツーエンドの認証と暗号化のための追加のアプリケーション層セキュリティ対策を適用する必要がある場合があります。 （ネットワークの可用性は、どのような場合でもネットワークキーのセキュリティプロパティに依存します。）
The 6LoWPAN encapsulation formats defined in this section are carried as payload in the G.9959 MAC PDU. IPv6 header compression [RFC6282] MUST be supported by implementations of this specification. Further, implementations MAY support Generic Header Compression (GHC) [RFC7400]. A node implementing [RFC7400] MUST probe its peers for GHC support before applying GHC.
このセクションで定義されている6LoWPANカプセル化形式は、G.9959 MAC PDUのペイロードとして伝送されます。 IPv6ヘッダー圧縮[RFC6282]は、この仕様の実装でサポートされている必要があります。さらに、実装はGeneric Header Compression（GHC）[RFC7400]をサポートしてもよい（MAY）。 [RFC7400]を実装するノードは、GHCを適用する前にGHCサポートについてピアをプローブしなければなりません（MUST）。
All 6LoWPAN datagrams transported over G.9959 are prefixed by a 6LoWPAN encapsulation header stack. The 6LoWPAN payload follows this encapsulation header stack. Each header in the header stack contains a header type followed by zero or more header fields. An IPv6 header stack may contain, in the following order, addressing, hop-by-hop options, routing, fragmentation, destination options, and, finally, payload [RFC2460]. The 6LoWPAN header format is structured the same way. Currently, only one payload option is defined for the G.9959 6LoWPAN header format.
G.9959を介して転送されるすべての6LoWPANデータグラムには、6LoWPANカプセル化ヘッダースタックがプレフィックスとして付加されます。 6LoWPANペイロードは、このカプセル化ヘッダースタックに従います。ヘッダースタックの各ヘッダーには、ヘッダータイプとそれに続く0個以上のヘッダーフィールドが含まれます。 IPv6ヘッダースタックには、アドレッシング、ホップバイホップオプション、ルーティング、フラグメンテーション、宛先オプション、そして最後にペイロード[RFC2460]が次の順序で含まれている場合があります。 6LoWPANヘッダー形式は同じ方法で構成されます。現在、G.9959 6LoWPANヘッダー形式に対して定義されているペイロードオプションは1つだけです。
The definition of 6LoWPAN headers consists of the dispatch value, the definition of the header fields that follow, and their ordering constraints relative to all other headers. Although the header stack structure provides a mechanism to address future demands on the 6LoWPAN adaptation layer, it is not intended to provide general-purpose extensibility.
6LoWPANヘッダーの定義は、ディスパッチ値、後続のヘッダーフィールドの定義、および他のすべてのヘッダーに関連する順序の制約で構成されます。ヘッダースタック構造は、6LoWPANアダプテーションレイヤーに対する将来の要求に対処するメカニズムを提供しますが、汎用の拡張性を提供することを意図していません。
An example of a complete G.9959 6LoWPAN datagram can be found in Appendix A.
完全なG.9959 6LoWPANデータグラムの例は、付録Aにあります。
The Dispatch Header is shown below:
ディスパッチヘッダーを以下に示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6LoWPAN CmdCls| Dispatch | Type-specific header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Dispatch Type and Header
図2：ディスパッチタイプとヘッダー
6LoWPAN CmdCls: 6LoWPAN Command Class identifier. This field MUST carry the value 0x4F [G.9959]. The value is assigned by the ITU-T and specifies that the following bits are a 6LoWPAN encapsulated datagram. 6LoWPAN protocols MUST ignore the G.9959 frame if the 6LoWPAN Command Class identifier deviates from 0x4F.
6LoWPAN CmdCls：6LoWPANコマンドクラス識別子。このフィールドは値0x4F [G.9959]を運ぶ必要があります。この値はITU-Tによって割り当てられ、次のビットが6LoWPANカプセル化データグラムであることを指定します。 6LoWPANコマンドクラス識別子が0x4Fから外れている場合、6LoWPANプロトコルはG.9959フレームを無視する必要があります。
Dispatch: Identifies the header type immediately following the Dispatch Header.
ディスパッチ：ディスパッチヘッダーの直後のヘッダータイプを識別します。
Type-specific header: A header determined by the Dispatch Header.
タイプ固有のヘッダー：Dispatchヘッダーによって決定されるヘッダー。
The dispatch value may be treated as an unstructured namespace. Only a few symbols are required to represent current 6LoWPAN functionality. Although some additional savings could be achieved by encoding additional functionality into the dispatch byte, these measures would tend to constrain the ability to address future alternatives.
ディスパッチ値は、非構造化名前空間として扱われる場合があります。現在の6LoWPAN機能を表すのに必要な記号はわずかです。追加の機能をディスパッチバイトにエンコードすることで、さらに節約できますが、これらの方法は、将来の代替策に対処する機能を制約する傾向があります。
+------------+--------------------+-----------+
| Pattern | Header Type | Reference |
+------------+--------------------+-----------+
| 01 1xxxxx | 6LoWPAN_IPHC | [RFC6282] |
+------------+--------------------+-----------+
Other IANA-assigned 6LoWPAN dispatch values do not apply to this document.
IANAが割り当てた他の6LoWPANディスパッチ値は、このドキュメントには適用されません。
Figure 3: Dispatch Values
図3：ディスパッチ値
6LoWPAN_IPHC: IPv6 Header Compression. Refer to [RFC6282].
6LoWPAN_IPHC：IPv6ヘッダー圧縮。 [RFC6282]を参照してください。
IPv6 addresses may be autoconfigured from IIDs that may again be constructed from link-layer address information to save memory in devices and to facilitate efficient IP header compression as per [RFC6282]. Link-layer-derived addresses have a static nature and may involuntarily expose private usage data on public networks. Refer to Section 7.
IPv6アドレスは、リンク層アドレス情報から再度構成できるIIDから自動的に構成され、デバイスのメモリを節約し、[RFC6282]に従って効率的なIPヘッダー圧縮を促進します。リンク層から派生したアドレスには静的な性質があり、パブリックネットワーク上のプライベート使用状況データを思わず公開する可能性があります。セクション7を参照してください。
A NodeID is mapped into an IEEE EUI-64 identifier as follows:
NodeIDは、次のようにIEEE EUI-64識別子にマップされます。
IID = 0000:00ff:fe00:YYXX
Figure 4: Constructing a Compressible IID
図4：圧縮可能なIIDの構築
where XX carries the G.9959 NodeID and YY is a 1-byte value chosen by the individual node. The default YY value MUST be zero. A node MAY use values of YY other than zero to form additional IIDs in order to instantiate multiple IPv6 interfaces. The YY value MUST be ignored when computing the corresponding NodeID (the XX value) from an IID.
ここで、XXはG.9959 NodeIDを保持し、YYは個々のノードによって選択された1バイトの値です。デフォルトのYY値はゼロでなければなりません。ノードは、複数のIPv6インターフェースをインスタンス化するために、ゼロ以外のYYの値を使用して追加のIIDを形成してもよい（MAY）。 IIDから対応するNodeID（XX値）を計算するときは、YY値を無視する必要があります。
The method of constructing IIDs from the link-layer address obviously does not support addresses assigned or constructed by other means. A node MUST NOT compute the NodeID from the IID if the first 6 bytes of the IID do not comply with the format defined in Figure 4. In that case, the address resolution mechanisms of [RFC6775] apply.
リンク層アドレスからIIDを作成する方法は、他の方法で割り当てられた、または作成されたアドレスを明らかにサポートしていません。 IIDの最初の6バイトが図4で定義されたフォーマットに準拠していない場合、ノードはIIDからNodeIDを計算してはなりません（MUST NOT）。その場合、[RFC6775]のアドレス解決メカニズムが適用されます。
The IID defined above MUST be used whether autoconfiguring a ULA IPv6 address [RFC4193] or a globally routable IPv6 address [RFC3587] in G.9959 subnets.
上記で定義されたIIDは、G.9959サブネットでULA IPv6アドレス[RFC4193]またはグローバルにルーティング可能なIPv6アドレス[RFC3587]を自動設定する場合でも使用する必要があります。
The IPv6 link-local address [RFC4291] for a G.9959 interface is formed by appending the IID defined above to the IPv6 link-local prefix fe80::/64.
G.9959インターフェイスのIPv6リンクローカルアドレス[RFC4291]は、上記で定義したIIDをIPv6リンクローカルプレフィックスfe80 :: / 64に追加することによって形成されます。
The "Universal/Local" (U/L) bit MUST be set to zero in keeping with the fact that this is not a globally unique value [EUI64].
「Universal / Local」（U / L）ビットは、これがグローバルに一意の値ではないという事実に合わせてゼロに設定する必要があります[EUI64]。
The resulting link-local address is formed as follows:
結果のリンクローカルアドレスは次のように形成されます。
10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+
|1111111010| (zeros) | Interface Identifier (IID) |
+----------+-----------------------+----------------------------+
Figure 5: IPv6 Link-Local Address
図5：IPv6リンクローカルアドレス
The address resolution procedure for mapping IPv6 unicast addresses into G.9959 link-layer addresses follows the general description in Section 7.2 of [RFC4861]. The Source/Target Link-layer Address option MUST have the following form when the link layer is G.9959.
IPv6ユニキャストアドレスをG.9959リンク層アドレスにマッピングするためのアドレス解決手順は、[RFC4861]のセクション7.2の一般的な説明に従います。リンク層がG.9959の場合、ソース/ターゲットリンク層アドレスオプションは次の形式でなければなりません。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | NodeID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding |
+- -+
| (All zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: IPv6 Unicast Address Mapping
図6：IPv6ユニキャストアドレスマッピング
Option fields:
オプションフィールド：
Type: The value 1 signifies the Source Link-layer address. The value 2 signifies the Destination Link-layer address.
タイプ：値1は、ソースリンク層アドレスを示します。値2は、宛先リンク層アドレスを示します。
Length: This is the length of this option (including the Type and Length fields) in units of 8 octets. The value of this field is always 1 for G.9959 NodeIDs.
長さ：これは、8オクテット単位のこのオプションの長さ（タイプフィールドと長さフィールドを含む）です。このフィールドの値は、G.9959 NodeIDの場合は常に1です。
NodeID: This is the G.9959 NodeID to which the actual interface currently responds. The link-layer address may change if the interface joins another network at a later time.
NodeID：これは、実際のインターフェースが現在応答しているG.9959 NodeIDです。後でインターフェイスが別のネットワークに参加すると、リンク層アドレスが変更される場合があります。
[RFC4861] specifies how IPv6 nodes may resolve link-layer addresses
from IPv6 addresses via the use of link-local IPv6 multicast.
[RFC6775] is an optimization of [RFC4861], specifically targeting
6LoWPAN networks. [RFC6775] defines how a 6LoWPAN node may register
IPv6 addresses with an authoritative border router (ABR). Mesh-under
networks MUST NOT use [RFC6775] address registration. However,
[RFC6775] address registration MUST be used if the first 6 bytes of
the IID do not comply with the format defined in Figure 4.
In route-over environments, IPv6 hosts MUST use [RFC6775] address registration. A node implementation for route-over operation MAY use [RFC6775] mechanisms for obtaining IPv6 prefixes and corresponding header compression context information [RFC6282]. [RFC6775] route-over requirements apply with no modifications.
ルートオーバー環境では、IPv6ホストは[RFC6775]アドレス登録を使用する必要があります。ルートオーバー操作のノード実装は、IPv6プレフィックスと対応するヘッダー圧縮コンテキスト情報[RFC6282]を取得するために[RFC6775]メカニズムを使用する場合があります。 [RFC6775]ルートオーバー要件は変更なしで適用されます。
An implementation for mesh-under operation MUST use [RFC6775] mechanisms for managing IPv6 prefixes and corresponding header compression context information [RFC6282]. [RFC6775] Duplicate Address Detection (DAD) MUST NOT be used, since the link-layer inclusion process of G.9959 ensures that a NodeID is unique for a given HomeID.
メッシュアンダー操作の実装は、IPv6プレフィックスと対応するヘッダー圧縮コンテキスト情報[RFC6282]を管理するために[RFC6775]メカニズムを使用する必要があります。 [RFC6775]重複アドレス検出（DAD）は使用しないでください。G.9959のリンク層包含プロセスにより、特定のHomeIDに対してNodeIDが一意になることが保証されます。
With this exception and the specific redefinition of the RA Router Lifetime value 0xFFFF (refer to Section 4.4.2.3), the text of the following subsections is in compliance with [RFC6775].
この例外とRAルーターのライフタイム値0xFFFFの特定の再定義（セクション4.4.2.3を参照）を除き、以下のサブセクションのテキストは[RFC6775]に準拠しています。
As stated by [RFC6775], an ABR is responsible for managing prefix(es). Global routable prefixes may change over time. It is RECOMMENDED that a ULA prefix is assigned to the 6LoWPAN subnet to facilitate stable site-local application associations based on IPv6 addresses. A node MAY support the M flag of the RA message. This influences the way IPv6 addresses are assigned. Refer to Section 2.1 for details.
[RFC6775]で述べられているように、ABRはプレフィックスの管理を担当します。グローバルルーティング可能なプレフィックスは、時間とともに変化する可能性があります。 IPv6アドレスに基づく安定したサイトローカルアプリケーションの関連付けを容易にするために、ULAプレフィックスを6LoWPANサブネットに割り当てることをお勧めします。ノードはRAメッセージのMフラグをサポートしてもよい（MAY）。これは、IPv6アドレスの割り当て方法に影響します。詳細については、セクション2.1を参照してください。
The 6LoWPAN Context Option (6CO) is used according to [RFC6775] in an RA to disseminate Context IDs (CIDs) to use for compressing prefixes. One or more prefixes and corresponding Context IDs MUST be assigned during initial node inclusion.
6LoWPAN Context Option（6CO）は、RAの[RFC6775]に従って、プレフィックスの圧縮に使用するコンテキストID（CID）を配布するために使用されます。最初のノードを含めるときに、1つ以上のプレフィックスと対応するコンテキストIDを割り当てる必要があります。
When updating context information, a CID may have its lifetime set to zero to obsolete it. The CID MUST NOT be reused immediately; rather, the next vacant CID should be assigned. Header compression based on CIDs MUST NOT be used for RA messages carrying context information. An expired CID and the associated prefix MUST NOT be reset but rather must be retained in receive-only mode if there is no other current need for the CID value. This will allow an ABR to detect if a sleeping node without a clock uses an expired CID, and in response, the ABR MUST return an RA with fresh context information to the originator.
コンテキスト情報を更新するとき、CIDはその寿命をゼロに設定して廃止する場合があります。 CIDをすぐに再利用してはなりません。むしろ、次の空のCIDを割り当てる必要があります。 CIDに基づくヘッダー圧縮は、コンテキスト情報を運ぶRAメッセージに使用してはなりません（MUST NOT）。期限切れのCIDと関連するプレフィックスはリセットしてはならず（MUST）、CID値に対する現在の必要性が他にない場合は、受信専用モードで保持する必要があります。これにより、ABRは、クロックのないスリープノードが期限切れのCIDを使用しているかどうかを検出でき、それに応答して、ABRは新しいコンテキスト情報を含むRAを発信者に返す必要があります。
Nodes MUST renew the prefix and CID according to the lifetime signaled by the ABR. [RFC6775] specifies that the maximum value of the RA Router Lifetime field MAY be up to 0xFFFF. This document further specifies that the value 0xFFFF MUST be interpreted as infinite lifetime. This value MUST NOT be used by ABRs. Its use is only intended for a sleeping network controller -- for instance, a battery-powered remote control being master for a small island-mode network of light modules.
ノードは、ABRによって通知された存続期間に従って、プレフィックスとCIDを更新する必要があります。 [RFC6775]は、RAルーターライフタイムフィールドの最大値が0xFFFFまでであることを指定します。このドキュメントはさらに、値0xFFFFが無限の寿命として解釈されなければならないことを指定します。この値はABRで使用してはならない（MUST NOT）。その使用は、スリープ状態のネットワークコントローラのみを対象としています。たとえば、バッテリ駆動のリモートコントロールは、ライトモジュールの小さなアイランドモードネットワークのマスターです。
IPv6 header compression [RFC6282] MUST be implemented, and GHC [RFC7400] compression for higher layers MAY be implemented. This section will simply identify substitutions that should be made when interpreting the text of [RFC6282] and [RFC7400].
IPv6ヘッダー圧縮[RFC6282]を実装しなければならず（MUST）、上位層のGHC [RFC7400]圧縮を実装してもよい（MAY）。このセクションでは、[RFC6282]と[RFC7400]のテキストを解釈するときに行う必要がある置換を簡単に特定します。
In general, the following substitutions should be made:
一般に、次の置換を行う必要があります。
o Replace "802.15.4" with "G.9959".
o 「802.15.4」を「G.9959」に置き換えます。
o Replace "802.15.4 short address" with "<Interface><G.9959 NodeID>".
o 「802.15.4ショートアドレス」を「<Interface> <G.9959 NodeID>」に置き換えます。
o Replace "802.15.4 PAN ID" with "G.9959 HomeID".
o 「802.15.4 PAN ID」を「G.9959 HomeID」に置き換えます。
When a 16-bit address is called for (i.e., an IEEE 802.15.4 "short address"), it MUST be formed by prepending an Interface label byte to the G.9959 NodeID:
16ビットアドレスが要求される場合（つまり、IEEE 802.15.4の「ショートアドレス」）、G.9959 NodeIDの前にインターフェイスラベルバイトを付加することによって形成する必要があります。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface | NodeID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A transmitting node may be sending to an IPv6 destination address that can be reconstructed from the link-layer destination address. If the Interface number is zero (the default value), all IPv6 address bytes may be elided. Likewise, the Interface number of a fully elided IPv6 address (i.e., SAM/DAM=11) may be reconstructed to the value zero by a receiving node.
送信ノードは、リンク層宛先アドレスから再構築できるIPv6宛先アドレスに送信している可能性があります。インターフェイス番号がゼロ（デフォルト値）の場合、すべてのIPv6アドレスバイトが省略される可能性があります。同様に、完全に省略されたIPv6アドレスのインターフェース番号（つまり、SAM / DAM = 11）は、受信ノードによって値0に再構築されます。
64-bit 802.15.4 address details do not apply.
64ビットの802.15.4アドレスの詳細は適用されません。
The method of derivation of Interface Identifiers from 8-bit NodeIDs preserves uniqueness within the network. However, there is no protection from duplication through forgery. Neighbor Discovery in G.9959 links may be susceptible to threats as detailed in [RFC3756]. G.9959 networks may feature mesh routing. This implies additional threats due to ad hoc routing as per [KW03]. G.9959 provides capability for link-layer security. G.9959 nodes MUST use link-layer security with a shared key. Doing so will alleviate the majority of threats stated above. A sizable portion of G.9959 devices is expected to always communicate within their PAN (i.e., within their subnet, in IPv6 terms). In response to cost and power consumption considerations, these devices will typically implement the minimum set of features necessary. Accordingly, security for such devices may rely on the mechanisms defined at the link layer by G.9959. G.9959 relies on the Advanced Encryption Standard (AES) for authentication and encryption of G.9959 frames and further employs challenge-response handshaking to prevent replay attacks.
8ビットNodeIDからインターフェース識別子を導出する方法は、ネットワーク内の一意性を維持します。ただし、偽造による複製からの保護はありません。 [RFC3756]で詳述されているように、G.9959リンクのネイバーディスカバリは脅威の影響を受ける可能性があります。 G.9959ネットワークはメッシュルーティングを備えている場合があります。これは、[KW03]によるアドホックルーティングによる追加の脅威を意味します。 G.9959は、リンク層セキュリティの機能を提供します。 G.9959ノードは、共有キーを使用したリンク層セキュリティを使用する必要があります。そうすることで、上記の脅威の大部分が緩和されます。 G.9959デバイスのかなりの部分は、常にPAN内（つまり、サブネット内、IPv6用語）で通信することが期待されています。コストと消費電力の考慮事項に応じて、これらのデバイスは通常、必要な最小限の機能セットを実装します。したがって、そのようなデバイスのセキュリティは、G.9959によってリンク層で定義されたメカニズムに依存する場合があります。 G.9959は、G.9959フレームの認証と暗号化をAdvanced Encryption Standard（AES）に依存し、チャレンジ/レスポンスハンドシェイクを使用して、リプレイアタックを防止します。
It is also expected that some G.9959 devices (e.g., billing and/or safety-critical products) will implement coordination or integration functions. These may communicate regularly with IPv6 peers outside the subnet. Such IPv6 devices are expected to secure their end-to-end communications with standard security mechanisms (e.g., IPsec, Transport Layer Security (TLS), etc.).
また、一部のG.9959デバイス（請求や安全性が重要な製品など）が調整または統合機能を実装することも期待されています。これらは、サブネット外のIPv6ピアと定期的に通信する場合があります。このようなIPv6デバイスは、標準のセキュリティメカニズム（IPsec、トランスポート層セキュリティ（TLS）など）でエンドツーエンドの通信を保護することが期待されています。
IP addresses may be used to track devices on the Internet; such devices can in turn be linked to individuals and their activities. Depending on the application and the actual use pattern, this may be undesirable. To impede tracking, globally unique and non-changing characteristics of IP addresses should be avoided, e.g., by frequently changing the global prefix and avoiding unique link-layer-derived IIDs in addresses.
IPアドレスは、インターネット上のデバイスを追跡するために使用できます。このようなデバイスは、個人とその活動にリンクできます。アプリケーションと実際の使用パターンによっては、これは望ましくない場合があります。追跡を妨げるには、IPアドレスのグローバルに一意で変化しない特性を回避する必要があります。たとえば、グローバルプレフィックスを頻繁に変更し、アドレス内の一意のリンク層から派生したIIDを回避します。
Some link layers use a 48-bit or 64-bit link-layer address that uniquely identifies the node on a global scale, regardless of global prefix changes. The risk of exposing a G.9959 device from its link-layer-derived IID is limited because of the short 8-bit link-layer address.
一部のリンク層は、グローバルプレフィックスの変更に関係なく、グローバルスケールでノードを一意に識別する48ビットまたは64ビットのリンク層アドレスを使用します。リンク層から派生したIIDからG.9959デバイスを公開するリスクは、8ビットのリンク層アドレスが短いため制限されています。
While intended for central address management, DHCPv6 address assignment also decouples the IPv6 address from the link-layer address. Addresses may be made dynamic by the use of a short DHCP lease period and an assignment policy that makes the DHCP server hand out a fresh IP address every time. For enhanced privacy, the DHCP-assigned addresses should be logged only for the duration of the lease, provided the implementation also allows logging for longer durations as per the operational policies.
DHCPv6アドレス割り当ては、集中アドレス管理を目的としていますが、リンク層アドレスからIPv6アドレスも分離します。短いDHCPリース期間と、DHCPサーバーが毎回新しいIPアドレスを渡すようにする割り当てポリシーを使用することにより、アドレスを動的にすることができます。プライバシーを強化するために、DHCPが割り当てたアドレスは、リース期間中のみログに記録する必要があります。ただし、実装により、運用ポリシーに従ってより長い期間のログも許可されます。
It should be noted that privacy and frequently changing address assignments come at a cost. Non-link-layer-derived IIDs require the use of address registration. Further, non-link-layer-derived IIDs cannot be compressed; this leads to longer datagrams and increased link-layer segmentation. Finally, frequent prefix changes necessitate more Context Identifier updates; this not only leads to increased traffic but also may affect the battery lifetime of sleeping nodes.
プライバシーと頻繁に変更されるアドレス割り当てにはコストがかかることに注意してください。非リンク層から派生したIIDでは、アドレス登録を使用する必要があります。さらに、リンク層から派生していないIIDは圧縮できません。これにより、データグラムが長くなり、リンク層のセグメンテーションが増加します。最後に、プレフィックスを頻繁に変更すると、より多くのコンテキスト識別子の更新が必要になります。これは、トラフィックの増加につながるだけでなく、スリープ状態のノードのバッテリー寿命にも影響を与える可能性があります。
[G.9959] International Telecommunication Union, "Short range narrow-band digital radiocommunication transceivers - PHY and MAC layer specifications", ITU-T Recommendation G.9959, January 2015, <http://www.itu.int/rec/T-REC-G.9959>.
[G.9959]国際電気通信連合、「短距離狭帯域デジタル無線通信トランシーバー-PHYおよびMAC層の仕様」、ITU-T勧告G.9959、2015年1月、<http://www.itu.int/rec/ T-REC-G.9959>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月、<http://www.rfc-editor.org/info/rfc2460>。
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005, <http://www.rfc-editor.org/info/rfc4122>.
[RFC4122] Leach、P.、Mealling、M。、およびR. Salz、「Universally Unique IDentifier（UUID）URN Namespace」、RFC 4122、2005年7月、<http://www.rfc-editor.org/info / rfc4122>。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005, <http://www.rfc-editor.org/info/rfc4193>.
[RFC4193] Hinden、R。およびB. Haberman、「Unique Local IPv6 Unicast Addresses」、RFC 4193、2005年10月、<http://www.rfc-editor.org/info/rfc4193>。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレッシングアーキテクチャ」、RFC 4291、2006年2月、<http://www.rfc-editor.org/info/rfc4291>。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007, <http://www.rfc-editor.org/info/rfc4861>.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「Neighbor Discovery for IP version 6（IPv6）」、RFC 4861、2007年9月、<http：//www.rfc- editor.org/info/rfc4861>。
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007, <http://www.rfc-editor.org/info/rfc4944>.
[RFC4944]モンテネグロ、G。、クシャルナガル、N。、ホイ、J。、およびD.キュラー、「IEEE 802.15.4ネットワーク上のIPv6パケットの送信」、RFC 4944、2007年9月、<http：//www.rfc -editor.org/info/rfc4944>。
[RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, September 2011, <http://www.rfc-editor.org/info/rfc6282>.
[RFC6282] Hui、J。およびP. Thubert、「IEEE 802.15.4ベースのネットワーク上のIPv6データグラムの圧縮形式」、RFC 6282、2011年9月、<http://www.rfc-editor.org/info/rfc6282 >。
[RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, August 2011, <http://www.rfc-editor.org/info/rfc6355>.
[RFC6355] Narten、T。およびJ. Johnson、「Definition of the UUID-Based DHCPv6 Unique Identifier（DUID-UUID）」、RFC 6355、2011年8月、<http://www.rfc-editor.org/info/ rfc6355>。
[RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, November 2012, <http://www.rfc-editor.org/info/rfc6775>.
[RFC6775]シェルビー、Z。、チャクラバルティ、S。、ノードマーク、E。、およびC.ボーマン、「低電力ワイヤレスパーソナルエリアネットワーク（6LoWPANs）を介したIPv6のネイバー探索最適化」、RFC 6775、2012年11月、<http ：//www.rfc-editor.org/info/rfc6775>。
[RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 7400, November 2014, <http://www.rfc-editor.org/info/rfc7400>.
[RFC7400] Bormann、C。、「6LoWPAN-GHC：Generic Header Compression over IPv6 over Low-Power Wireless Personal Area Networks（6LoWPANs）」、RFC 7400、2014年11月、<http://www.rfc-editor.org/ info / rfc7400>。
[EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64TM)", November 2012, <http://standards.ieee.org/ regauth/oui/tutorials/EUI64.html>.
[EUI64] IEEE、「64ビットグローバルID（EUI-64TM）のガイドライン」、2012年11月、<http://standards.ieee.org/ regauth / oui / tutorials / EUI64.html>。
[KW03] Karlof, C. and D. Wagner, "Secure Routing in Sensor Networks: Attacks and Countermeasures", Elsevier Ad Hoc Networks Journal, Special Issue on Sensor Network Applications and Protocols, vol. 1, issues 2-3, September 2003.
[KW03] Karlof、C。およびD. Wagner、「センサーネットワークにおける安全なルーティング：攻撃と対策」、Elsevier Ad Hoc Networks Journal、特集号「センサーネットワークアプリケーションとプロトコル、vol。 1、問題2-3、2003年9月。
[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, <http://www.rfc-editor.org/info/rfc3315>.
[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 、<http://www.rfc-editor.org/info/rfc3315>。
[RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global Unicast Address Format", RFC 3587, August 2003, <http://www.rfc-editor.org/info/rfc3587>.
[RFC3587] Hinden、R.、Deering、S。、およびE. Nordmark、「IPv6 Global Unicast Address Format」、RFC 3587、2003年8月、<http://www.rfc-editor.org/info/rfc3587>。
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004, <http://www.rfc-editor.org/info/rfc3756>.
[RFC3756] Nikander、P.、Kempf、J。、およびE. Nordmark、「IPv6 Neighbor Discovery（ND）Trust Models and Threats」、RFC 3756、2004年5月、<http://www.rfc-editor.org/ info / rfc3756>。
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, "Advice for Internet Subnetwork Designers", BCP 89, RFC 3819, July 2004, <http://www.rfc-editor.org/info/rfc3819>.
[RFC3819]カーン、P。、ボルマン、C。、フェアハースト、G。、グロスマン、D。、ルートヴィヒ、R。、マハビ、J。、モンテネグロ、G。、タッチ、J。、およびL.ウッド、「助言for Internet Subnetwork Designers」、BCP 89、RFC 3819、2004年7月、<http://www.rfc-editor.org/info/rfc3819>。
[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, March 2012, <http://www.rfc-editor.org/info/rfc6550>.
[RFC6550]冬、T.、Thubert、P.、Brandt、A.、Hui、J.、Kelsey、R.、Levis、P.、Pister、K.、Struik、R.、Vasseur、JP。、およびR 。Alexander、「RPL：低電力および損失の多いネットワーク用のIPv6ルーティングプロトコル」、RFC 6550、2012年3月、<http://www.rfc-editor.org/info/rfc6550>。
[RFC6997] Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J. Martocci, "Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks", RFC 6997, August 2013, <http://www.rfc-editor.org/info/rfc6997>.
[RFC6997] Goyal、M.、Baccelli、E.、Philipp、M.、Brandt、A。、およびJ. Martocci、「低電力および損失の多いネットワークにおけるポイントツーポイントルートのリアクティブディスカバリ」、RFC 6997、 2013年8月、<http://www.rfc-editor.org/info/rfc6997>。
This example outlines each individual bit of a sample IPv6 UDP packet arriving to a G.9959 node from a host in the Internet via a PAN border router.
この例では、PAN境界ルーターを介してインターネットのホストからG.9959ノードに到着するサンプルIPv6 UDPパケットの個々のビットの概要を示します。
In the G.9959 PAN, the complete frame has the following fields.
G.9959 PANでは、完全なフレームには次のフィールドがあります。
G.9959:
G.9959：
+------+---------+----------+---+-----+----------...
|HomeID|SrcNodeID|FrmControl|Len|SeqNo|DestNodeID|
+------+---------+----------+---+-----+----------+-...
6LoWPAN:
6LoWPAN：
...+--------------+----------------+-----------------------...
|6LoWPAN CmdCls|6LoWPAN_IPHC Hdr|Compressed IPv6 headers|
...-------------+----------------+-----------------------+-...
IPv6, TCP/UDP, App payload:
IPv6、TCP / UDP、アプリペイロード：
...+-------------------------+------------+-----------+
|Uncompressed IPv6 headers|TCP/UDP/ICMP|App payload|
...------------------------+------------+-----------+
The frame comes from the source IPv6 address 2001:0db8:ac10:ef01::ff:fe00:1206. The source prefix 2001:0db8:ac10:ef01/64 is identified by the IPHC CID = 3.
フレームは、ソースIPv6アドレス2001：0db8：ac10：ef01 :: ff：fe00：1206から送信されます。ソースプレフィックス2001：0db8：ac10：ef01 / 64は、IPHC CID = 3で識別されます。
The frame is delivered in direct range from the gateway that has source NodeID = 1. The Interface Identifier (IID) ff:fe00:1206 is recognized as a link-layer-derived address and is compressed to the 16-bit value 0x1206.
フレームは、ソースNodeID = 1のゲートウェイから直接範囲で配信されます。インターフェイス識別子（IID）ff：fe00：1206は、リンク層から派生したアドレスとして認識され、16ビット値0x1206に圧縮されます。
The frame is sent to the destination IPv6 address 2001:0db8:27ef:42ca::ff:fe00:0004. The destination prefix 2001:0db8:27ef:42ca/64 is identified by the IPHC CID = 2.
フレームは、宛先IPv6アドレス2001：0db8：27ef：42ca :: ff：fe00：0004に送信されます。宛先プレフィックス2001：0db8：27ef：42ca / 64は、IPHC CID = 2で識別されます。
The IID ff:fe00:0004 is recognized as a link-layer-derived address.
IID ff：fe00：0004は、リンク層から派生したアドレスとして認識されます。
Thanks to the link-layer-derived addressing rules, the sender knows that this is to be sent to G.9959 NodeID = 4, targeting the IPv6 interface instance number 0 (the default).
リンク層から導出されたアドレス指定ルールのおかげで、送信者は、これがG.9959 NodeID = 4に送信され、IPv6インターフェイスインスタンス番号0（デフォルト）をターゲットとすることがわかります。
To reach the 6LoWPAN stack of the G.9959 node (skipping the G.9959 header fields), the first octet must be the 6LoWPAN Command Class (0x4F).
G.9959ノードの6LoWPANスタックに到達するには（G.9959ヘッダーフィールドをスキップ）、最初のオクテットは6LoWPANコマンドクラス（0x4F）である必要があります。
0
0 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-...
| 0x4F |
+-+-+-+-+-+-+-+-+-...
The Dispatch Header bits '011' advertise a compressed IPv6 header.
ディスパッチヘッダービット「011」は、圧縮されたIPv6ヘッダーをアドバタイズします。
0 1
0 1 2 3 4 5 6 7 8 9 0
+-+-+-+-+-+-+-+-+-+-+-...
| 0x4F |0 1 1
+-+-+-+-+-+-+-+-+-+-+-+-...
The following bits encode the first IPv6 header fields:
次のビットは、最初のIPv6ヘッダーフィールドをエンコードします。
TF = '11' : Traffic Class and Flow Label are elided
NH = '1' : Next Header is elided
HLIM = '10' : Hop limit is 64
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| 0x4F |0 1 1 1 1 1 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
CID = '1' : CI data follows the DAM field
SAC = '1' : Src addr uses stateful, context-based compression
SAM = '10' : Use src CID and 16 bits for link-layer-derived addr
M = '0' : Dest addr is not a multicast addr
DAC = '1' : Dest addr uses stateful, context-based compression
DAM = '11' : Use dest CID and dest NodeID to link-layer-derived addr
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| 0x4F |0 1 1 1 1 1 1 0|1 1 1 0 0 1 1 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
Address compression context identifiers:
アドレス圧縮コンテキスト識別子：
SCI = 0x3 DCI = 0x2
SCI = 0x3 DCI = 0x2
2 3
4 5 6 7 8 9 0 1
...+-+-+-+-+-+-+-+-...
| 0x3 | 0x2 |
...+-+-+-+-+-+-+-+-...
IPv6 header fields: (skipping "version" field) (skipping "Traffic Class") (skipping "flow label") (skipping "payload length")
IPv6ヘッダーフィールド：（「バージョン」フィールドをスキップ）（「トラフィッククラス」をスキップ）（「フローラベル」をスキップ）（「ペイロード長」をスキップ）
IPv6 header address fields:
IPv6ヘッダーアドレスフィールド：
SrcIP = 0x1206 : Use SCI and 16 least significant bits of link-layer-derived address
SrcIP = 0x1206：リンク層から派生したアドレスのSCIおよび最下位16ビットを使用
(skipping DestIP ) - completely reconstructed from dest NodeID and DCI
（DestIPをスキップ）-dest NodeIDとDCIから完全に再構築
2 3 4
4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| 0x3 | 0x2 | 0x12 | 0x06 |
...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
Next Header encoding for the UDP header:
UDPヘッダーの次のヘッダーエンコーディング：
Dispatch = '11110': Next Header dispatch code for UDP header
C = '0' : 16-bit checksum carried inline
P = '00' : Both src port and dest port are carried in-line
4 5
8 9 0 1 2 3 4 5
...+-+-+-+-+-+-+-+-...
|1 1 1 1 0|0|0 0|
...+-+-+-+-+-+-+-+-...
UDP header fields:
UDPヘッダーフィールド：
src port = 0x1234 dest port = 0x5678
srcポート= 0x1234宛先ポート= 0x5678
5 6 7 8
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 2 3 4 5 6 7
...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| 0x12 | 0x34 | 0x56 | 0x78 |
...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-..
(skipping "length")
checksum = .... (actual checksum value depends on
the actual UDP payload)
1
8 9 0
8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
| (UDP checksum) |
...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
Add your own UDP payload here...
ここに独自のUDPペイロードを追加...
Acknowledgements
謝辞
Thanks to the authors of RFC 4944 and RFC 6282, and members of the IETF 6LoWPAN working group; this document borrows extensively from their work. Thanks to Erez Ben-Tovim, Erik Nordmark, Kerry Lynn, Michael Richardson, and Tommas Jess Christensen for useful comments. Thanks to Carsten Bormann for extensive feedback that improved this document significantly. Thanks to Brian Haberman for pointing out unclear details.
RFC 4944とRFC 6282の作成者、およびIETF 6LoWPANワーキンググループのメンバーに感謝します。この文書は彼らの仕事から広範囲に借りています。有用なコメントを提供してくれたErez Ben-Tovim、Erik Nordmark、Kerry Lynn、Michael Richardson、Tommas Jess Christensenに感謝します。このドキュメントを大幅に改善した広範なフィードバックを提供してくれたCarsten Bormannに感謝します。不明な点を指摘してくれたBrian Habermanに感謝します。
Authors' Addresses
著者のアドレス
Anders Brandt Sigma Designs Emdrupvej 26A, 1. Copenhagen O 2100 Denmark
Anders Brandt Sigma Designs Emdrupvej 26A、1。コペンハーゲンO 2100デンマーク
EMail: anders_brandt@sigmadesigns.com
Jakob Buron Sigma Designs Emdrupvej 26A, 1. Copenhagen O 2100 Denmark
Jakob Buron Sigma Designs Emdrupvej 26A、1。コペンハーゲンO 2100デンマーク
EMail: jakob_buron@sigmadesigns.com