[要約] RFC 4944は、IEEE 802.15.4ネットワーク上でIPv6パケットを転送するための仕様です。このRFCの目的は、低消費電力の無線ネットワークでIPv6通信を実現するためのプロトコルを提供することです。
Network Working Group G. Montenegro
Request for Comments: 4944 Microsoft Corporation
Category: Standards Track N. Kushalnagar
Intel Corp
J. Hui
D. Culler
Arch Rock Corp
September 2007
Transmission of IPv6 Packets over IEEE 802.15.4 Networks
IEEE 802.15.4ネットワークを介したIPv6パケットの送信
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Abstract
概要
This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE 802.15.4 networks. Additional specifications include a simple header compression scheme using shared context and provisions for packet delivery in IEEE 802.15.4 meshes.
このドキュメントでは、IPv6パケットの送信のためのフレーム形式と、IEEE 802.15.4ネットワークでIPv6リンクローカルアドレスを形成する方法と、ステートレレスに自動コンフィギングされたアドレスを説明します。追加の仕様には、共有コンテキストを使用した単純なヘッダー圧縮スキームと、IEEE 802.15.4メッシュのパケット配信の規定が含まれます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3
1.2. Terms Used . . . . . . . . . . . . . . . . . . . . . . . . 3
2. IEEE 802.15.4 Mode for IP . . . . . . . . . . . . . . . . . . 3
3. Addressing Modes . . . . . . . . . . . . . . . . . . . . . . . 4
4. Maximum Transmission Unit . . . . . . . . . . . . . . . . . . 5
5. LoWPAN Adaptation Layer and Frame Format . . . . . . . . . . . 6
5.1. Dispatch Type and Header . . . . . . . . . . . . . . . . . 8
5.2. Mesh Addressing Type and Header . . . . . . . . . . . . . 10
5.3. Fragmentation Type and Header . . . . . . . . . . . . . . 11
6. Stateless Address Autoconfiguration . . . . . . . . . . . . . 13
7. IPv6 Link Local Address . . . . . . . . . . . . . . . . . . . 14
8. Unicast Address Mapping . . . . . . . . . . . . . . . . . . . 14
9. Multicast Address Mapping . . . . . . . . . . . . . . . . . . 16
10. Header Compression . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Encoding of IPv6 Header Fields . . . . . . . . . . . . . . 17
10.2. Encoding of UDP Header Fields . . . . . . . . . . . . . . 19
10.3. Non-Compressed Fields . . . . . . . . . . . . . . . . . . 21
10.3.1. Non-Compressed IPv6 Fields . . . . . . . . . . . . . 21
10.3.2. Non-Compressed and Partially Compressed UDP Fields . 21
11. Frame Delivery in a Link-Layer Mesh . . . . . . . . . . . . . 21
11.1. LoWPAN Broadcast . . . . . . . . . . . . . . . . . . . . . 23
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
13. Security Considerations . . . . . . . . . . . . . . . . . . . 25
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
15.1. Normative References . . . . . . . . . . . . . . . . . . . 26
15.2. Informative References . . . . . . . . . . . . . . . . . . 26
Appendix A. Alternatives for Delivery of Frames in a Mesh . . . . 28
The IEEE 802.15.4 standard [ieee802.15.4] targets low-power personal area networks. 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 addresses on top of IEEE 802.15.4 networks. Since IPv6 requires support of packet sizes much larger than the largest IEEE 802.15.4 frame size, an adaptation layer is defined. This document also defines mechanisms for header compression required to make IPv6 practical on IEEE 802.15.4 networks, and the provisions required for packet delivery in IEEE 802.15.4 meshes. However, a full specification of mesh routing (the specific protocol used, the interactions with neighbor discovery, etc) is out of the scope of this document.
IEEE 802.15.4標準[IEEE802.15.4]は、低電力の個人エリアネットワークをターゲットにします。このドキュメントでは、IPv6 [RFC2460]パケットの送信用のフレーム形式と、IEEE 802.15.4ネットワークの上にあるIPv6リンクローカルアドレスと、ステートレレスに自動化されたアドレスの形成を定義します。IPv6には、最大のIEEE 802.15.4フレームサイズよりもはるかに大きいパケットサイズのサポートが必要なため、適応層が定義されています。このドキュメントでは、IEEE 802.15.4ネットワークでIPv6を実用的にするために必要なヘッダー圧縮のメカニズムと、IEEE 802.15.4メッシュのパケット配信に必要な規定も定義されています。ただし、メッシュルーティングの完全な仕様（使用される特定のプロトコル、近隣発見との相互作用など）は、このドキュメントの範囲外です。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。
AES: Advanced Encryption Scheme
AES：高度な暗号化スキーム
CSMA/CA: Carrier Sense Multiple Access / Collision Avoidance
CSMA / CA：キャリアセンス複数のアクセス /衝突回避
FFD: Full Function Device
FFD：フル機能デバイス
GTS: Guaranteed Time Service
GTS：保証された時間サービス
MTU: Maximum Transmission Unit
MTU：最大送信ユニット
MAC: Media Access Control
Mac：メディアアクセス制御
PAN: Personal Area Network
パン：パーソナルエリアネットワーク
RFD: Reduced Function Device
RFD：機能デバイスの削減
IEEE 802.15.4 defines four types of frames: beacon frames, MAC command frames, acknowledgement frames, and data frames. IPv6 packets MUST be carried on data frames. Data frames may optionally request that they be acknowledged. In keeping with [RFC3819], it is recommended that IPv6 packets be carried in frames for which acknowledgements are requested so as to aid link-layer recovery.
IEEE 802.15.4は、ビーコンフレーム、Macコマンドフレーム、確認フレーム、およびデータフレームの4種類のフレームを定義しています。IPv6パケットは、データフレームに携帯する必要があります。データフレームは、オプションで確認されることを要求する場合があります。[RFC3819]に合わせて、IPv6パケットは、リンク層の回復を支援するために謝辞が要求されるフレームに携帯することをお勧めします。
IEEE 802.15.4 networks can either be nonbeacon-enabled or beacon-enabled [ieee802.15.4]. The latter is an optional mode in which devices are synchronized by a so-called coordinator's beacons. This allows the use of superframes within which a contention-free Guaranteed Time Service (GTS) is possible. This document does not require that IEEE networks run in beacon-enabled mode. In nonbeacon-enabled networks, data frames (including those carrying IPv6 packets) are sent via the contention-based channel access method of unslotted CSMA/CA.
IEEE 802.15.4ネットワークは、非ビーコン対応またはビーコン対応[IEEE802.15.4]のいずれかです。後者は、いわゆるコーディネーターのビーコンによってデバイスが同期されるオプションモードです。これにより、競合のない保証タイムサービス（GTS）が可能なスーパーフレームを使用できます。このドキュメントでは、IEEEネットワークがビーコン対応モードで実行される必要はありません。非ビーコン対応ネットワークでは、データフレーム（IPv6パケットを携帯するものを含む）が、留められていないCSMA/CAの競合ベースのチャネルアクセス方法を介して送信されます。
In nonbeacon-enabled networks, beacons are not used for synchronization. However, they are still useful for link-layer device discovery to aid in association and disassociation events. This document recommends that beacons be configured so as to aid these functions. A further recommendation is for these events to be available at the IPv6 layer to aid in detecting network attachment, a problem being worked on at the IETF at the time of this writing.
非ビーコン対応ネットワークでは、ビーコンは同期には使用されません。ただし、関連性と分離イベントを支援するために、リンク層デバイスの発見が依然として役立ちます。このドキュメントでは、これらの機能を支援するようにビーコンを構成することを推奨しています。これらのイベントがIPv6レイヤーで利用できるように、ネットワークの添付ファイルの検出を支援するためのさらなる推奨事項は、この執筆時点でIETFで取り組んでいる問題です。
The specification allows for frames in which either the source or destination addresses (or both) are elided. The mechanisms defined in this document require that both source and destination addresses be included in the IEEE 802.15.4 frame header. The source or destination PAN ID fields may also be included.
この仕様により、ソースまたは宛先アドレス（またはその両方）が削除されるフレームが可能になります。このドキュメントで定義されているメカニズムでは、ソースアドレスと宛先アドレスの両方をIEEE 802.15.4フレームヘッダーに含める必要があります。ソースまたは宛先パンIDフィールドも含めることができます。
IEEE 802.15.4 defines several addressing modes: it allows the use of either IEEE 64-bit extended addresses or (after an association event) 16-bit addresses unique within the PAN [ieee802.15.4]. This document supports both 64-bit extended addresses, and 16-bit short addresses. For use within 6LoWPANs, this document imposes additional constraints (beyond those imposed by IEEE 802.15.4) on the format of the 16-bit short addresses, as specified in Section 12. Short addresses being transient in nature, a word of caution is in order: since they are doled out by the PAN coordinator function during an association event, their validity and uniqueness is limited by the lifetime of that association. This can be cut short by the expiration of the association or simply by any mishap occurring to the PAN coordinator. Because of the scalability issues posed by such a centralized allocation and single point of failure at the PAN coordinator, deployers should carefully weigh the tradeoffs (and implement the necessary mechanisms) of growing such networks based on short addresses. Of course, IEEE 64-bit extended addresses may not suffer from these drawbacks, but still share the remaining scalability issues concerning routing, discovery, configuration, etc.
IEEE 802.15.4は、いくつかのアドレス指定モードを定義します。これにより、IEEE 64ビットの拡張アドレスまたは（関連イベントの後）パン内で一意の16ビットアドレスのいずれかを使用できます[IEEE802.15.4]。このドキュメントは、64ビットの拡張アドレスと16ビットの短いアドレスの両方をサポートしています。6lowpans内で使用するために、このドキュメントは、セクション12で指定されているように、16ビットの短いアドレスの形式に追加の制約（IEEE 802.15.4によって課されるものを超えて）を課します。注文：協会のイベント中にPANコーディネーター機能によって解放されているため、それらの有効性と独自性はその協会の寿命によって制限されます。これは、協会の満了または単にパンコーディネーターに発生する事故によって短くカットすることができます。PANコーディネーターでのこのような集中配分と単一の障害によってもたらされるスケーラビリティの問題のため、展開者は、短いアドレスに基づいてそのようなネットワークを栽培するというトレードオフ（および必要なメカニズムを実装）する（および必要なメカニズムを実装）する必要があります。もちろん、IEEE 64ビット拡張アドレスはこれらの欠点に悩まされない可能性がありますが、ルーティング、発見、構成などに関する残りのスケーラビリティの問題を共有しています。
This document assumes that a PAN maps to a specific IPv6 link. This complies with the recommendation that shared networks support link-layer subnet [RFC3819] broadcast. Strictly speaking, it is multicast not broadcast that exists in IPv6. However, multicast is not supported natively in IEEE 802.15.4. Hence, IPv6 level multicast packets MUST be carried as link-layer broadcast frames in IEEE 802.15.4 networks. This MUST be done such that the broadcast frames are only heeded by devices within the specific PAN of the link in question. As per Section 7.5.6.2 in [ieee802.15.4], this is accomplished as follows:
このドキュメントは、PANが特定のIPv6リンクをマッピングすることを前提としています。これは、共有ネットワークがリンク層サブネット[RFC3819]ブロードキャストをサポートするという推奨事項に準拠しています。厳密に言えば、IPv6に存在するのは放送されていないマルチキャストです。ただし、IEEE 802.15.4では、マルチキャストはネイティブにサポートされていません。したがって、IPv6レベルのマルチキャストパケットは、IEEE 802.15.4ネットワークのリンク層ブロードキャストフレームとして運ばれる必要があります。これは、ブロードキャストフレームに、問題のリンクの特定のPAN内のデバイスのみが注意を払うように行う必要があります。[IEEE802.15.4]のセクション7.5.6.2に従って、これは次のように達成されます。
1. A destination PAN identifier is included in the frame, and it MUST match the PAN ID of the link in question.
1. 宛先パン識別子がフレームに含まれており、問題のリンクのパンIDと一致する必要があります。
2. A short destination address is included in the frame, and it MUST match the broadcast address (0xffff).
2. 短い宛先アドレスがフレームに含まれており、ブロードキャストアドレス（0xffff）と一致する必要があります。
Additionally, support for mapping of IPv6 multicast addresses per Section 9 MUST only be used in a mesh configuration. A full specification of such functionality is out of the scope of this document.
さらに、セクション9ごとのIPv6マルチキャストアドレスのマッピングのサポートは、メッシュ構成でのみ使用する必要があります。このような機能の完全な仕様は、このドキュメントの範囲外です。
As usual, hosts learn IPv6 prefixes via router advertisements as per [RFC4861].
いつものように、ホストは[RFC4861]に従ってルーター広告を介してIPv6プレフィックスを学習します。
The MTU size for IPv6 packets over IEEE 802.15.4 is 1280 octets. However, a full IPv6 packet does not fit in an IEEE 802.15.4 frame. 802.15.4 protocol data units have different sizes depending on how much overhead is present [ieee802.15.4]. Starting from a maximum physical layer packet size of 127 octets (aMaxPHYPacketSize) and a maximum frame overhead of 25 (aMaxFrameOverhead), the resultant maximum frame size at the media access control layer is 102 octets. Link-layer security imposes further overhead, which in the maximum case (21 octets of overhead in the AES-CCM-128 case, versus 9 and 13 for AES-CCM-32 and AES-CCM-64, respectively) leaves only 81 octets available. This is obviously far below the minimum IPv6 packet size of 1280 octets, and in keeping with Section 5 of the IPv6 specification [RFC2460], a fragmention and reassembly adaptation layer must be provided at the layer below IP. Such a layer is defined below in Section 5.
IEEE 802.15.4を超えるIPv6パケットのMTUサイズは1280オクテットです。ただし、完全なIPv6パケットはIEEE 802.15.4フレームに収まりません。802.15.4プロトコルデータユニットは、オーバーヘッドの量に応じてサイズが異なります[IEEE802.15.4]。127オクテット（Amaxphypacketsize）の最大物理レイヤーパケットサイズと25の最大フレームオーバーヘッド（AmaxFrameOverhead）から始まると、メディアアクセス制御レイヤーの結果の最大フレームサイズは102オクテットです。リンク層のセキュリティはさらにオーバーヘッドを課します。これは、最大の場合（AES-CCM-128ケースのオーバーヘッド21オクテット、それぞれAES-CCM-32とAES-CCM-64の場合は9および13）が81オクテットしか残していません。利用可能。これは明らかに1280オクテットの最小IPv6パケットサイズをはるかに下回っており、IPv6仕様のセクション5 [RFC2460]に沿って、IPの下のレイヤーでフラグメントおよび再組み立て順応層を提供する必要があります。このようなレイヤーは、セクション5で以下に定義されています。
Furthermore, since the IPv6 header is 40 octets long, this leaves only 41 octets for upper-layer protocols, like UDP. The latter uses 8 octets in the header which leaves only 33 octets for application data. Additionally, as pointed out above, there is a need for a fragmentation and reassembly layer, which will use even more octets.
さらに、IPv6ヘッダーの長さは40オクテットであるため、UDPのような上層層プロトコルには41オクテットしか残りません。後者はヘッダーに8オクテットを使用し、アプリケーションデータには33オクテットしか残しません。さらに、上で指摘したように、さらに多くのオクテットを使用する断片化と再組み立て層が必要です。
The above considerations lead to the following two observations:
上記の考慮事項は、次の2つの観察結果につながります。
1. The adaptation layer must be provided to comply with the IPv6 requirements of a minimum MTU. However, it is expected that (a) most applications of IEEE 802.15.4 will not use such large packets, and (b) small application payloads in conjunction with the proper header compression will produce packets that fit within a single IEEE 802.15.4 frame. The justification for this adaptation layer is not just for IPv6 compliance, as it is quite likely that the packet sizes produced by certain application exchanges (e.g., configuration or provisioning) may require a small number of fragments.
1. 最小MTUのIPv6要件を順守するには、適応層を提供する必要があります。ただし、（a）IEEE 802.15.4のほとんどのアプリケーションはそのような大きなパケットを使用しないことが予想されます。。この適応層の正当化は、IPv6コンプライアンスだけではありません。特定のアプリケーション交換（たとえば、構成やプロビジョニング）によって生成されるパケットサイズには少数のフラグメントが必要になる可能性が高いためです。
2. Even though the above space calculation shows the worst-case scenario, it does point out the fact that header compression is compelling to the point of almost being unavoidable. Since we expect that most (if not all) applications of IP over IEEE 802.15.4 will make use of header compression, it is defined below in Section 10.
2. 上記のスペースの計算は最悪のシナリオを示していますが、ヘッダー圧縮がほとんど避けられないという点まで説得力があるという事実を指摘しています。IEEE 802.15.4を介したIPのほとんどの（すべてではないにしても）アプリケーションがヘッダー圧縮を使用すると予想されるため、セクション10で以下に定義されています。
The encapsulation formats defined in this section (subsequently referred to as the "LoWPAN encapsulation") are the payload in the IEEE 802.15.4 MAC protocol data unit (PDU). The LoWPAN payload (e.g., an IPv6 packet) follows this encapsulation header.
このセクションで定義されているカプセル化形式（次に「ローパンカプセル化」と呼ばれる）は、IEEE 802.15.4 Macプロトコルデータユニット（PDU）のペイロードです。ローパンペイロード（例：IPv6パケット）は、このカプセル化ヘッダーに従います。
All LoWPAN encapsulated datagrams transported over IEEE 802.15.4 are prefixed by an encapsulation header stack. Each header in the header stack contains a header type followed by zero or more header fields. Whereas in an IPv6 header the stack would contain, in the following order, addressing, hop-by-hop options, routing, fragmentation, destination options, and finally payload [RFC2460]; in a LoWPAN header, the analogous header sequence is mesh (L2) addressing, hop-by-hop options (including L2 broadcast/multicast), fragmentation, and finally payload. These examples show typical header stacks that may be used in a LoWPAN network.
IEEE 802.15.4を介して輸送されるすべてのローパンカプセル化されたデータグラムには、カプセル化ヘッダースタックが付いています。ヘッダースタックの各ヘッダーには、ヘッダータイプが含まれ、その後はゼロ以上のヘッダーフィールドが含まれます。一方、IPv6ヘッダーでは、スタックには、次の順序で、ホップバイホップオプション、ルーティング、フラグメンテーション、宛先オプション、最後にペイロード[RFC2460]が含まれます。ローパンヘッダーでは、類似のヘッダーシーケンスはメッシュ（L2）アドレス指定、ホップバイホップオプション（L2ブロードキャスト/マルチキャストを含む）、断片化、そして最後にペイロードです。これらの例は、ローパンネットワークで使用できる典型的なヘッダースタックを示しています。
A LoWPAN encapsulated IPv6 datagram:
ローパンカプセル化IPv6データグラム：
+---------------+-------------+---------+
| IPv6 Dispatch | IPv6 Header | Payload |
+---------------+-------------+---------+
A LoWPAN encapsulated LOWPAN_HC1 compressed IPv6 datagram:
ローパンカプセル化されたローパン_HC1圧縮IPv6データグラム：
+--------------+------------+---------+
| HC1 Dispatch | HC1 Header | Payload |
+--------------+------------+---------+
A LoWPAN encapsulated LOWPAN_HC1 compressed IPv6 datagram that requires mesh addressing:
メッシュのアドレス指定を必要とするローパンカプセル化ローパン_HC1圧縮IPv6データグラム：
+-----------+-------------+--------------+------------+---------+
| Mesh Type | Mesh Header | HC1 Dispatch | HC1 Header | Payload |
+-----------+-------------+--------------+------------+---------+
A LoWPAN encapsulated LOWPAN_HC1 compressed IPv6 datagram that requires fragmentation:
断片化を必要とするローパンカプセル化ローパン_HC1圧縮IPv6データグラム：
+-----------+-------------+--------------+------------+---------+
| Frag Type | Frag Header | HC1 Dispatch | HC1 Header | Payload |
+-----------+-------------+--------------+------------+---------+
A LoWPAN encapsulated LOWPAN_HC1 compressed IPv6 datagram that requires both mesh addressing and fragmentation:
メッシュのアドレス指定とフラグメンテーションの両方を必要とするローパンカプセル化LowPAN_HC1圧縮IPv6データグラム：
+-------+-------+-------+-------+---------+---------+---------+
| M Typ | M Hdr | F Typ | F Hdr | HC1 Dsp | HC1 Hdr | Payload |
+-------+-------+-------+-------+---------+---------+---------+
A LoWPAN encapsulated LOWPAN_HC1 compressed IPv6 datagram that requires both mesh addressing and a broadcast header to support mesh broadcast/multicast:
メッシュアドレス指定とメッシュブロードキャスト/マルチキャストをサポートするためのブロードキャストヘッダーの両方を必要とするローパンカプセル化LowPAN_HC1圧縮IPv6データグラム：
+-------+-------+-------+-------+---------+---------+---------+
| M Typ | M Hdr | B Dsp | B Hdr | HC1 Dsp | HC1 Hdr | Payload |
+-------+-------+-------+-------+---------+---------+---------+
When more than one LoWPAN header is used in the same packet, they MUST appear in the following order:
同じパケットで複数のローパンヘッダーを使用している場合、次の順序で表示する必要があります。
Mesh Addressing Header
メッシュアドレス指定ヘッダー
Broadcast Header
ブロードキャストヘッダー
Fragmentation Header
断片化ヘッダー
All protocol datagrams (e.g., IPv6, compressed IPv6 headers, etc.) SHALL be preceded by one of the valid LoWPAN encapsulation headers, examples of which are given above. This permits uniform software treatment of datagrams without regard to the mode of their transmission.
すべてのプロトコルデータグラム（例：IPv6、圧縮IPv6ヘッダーなど）の前には、有効なローパンカプセル化ヘッダーの1つがあり、その例は上記の例です。これにより、送信のモードに関係なく、データグラムの均一なソフトウェア処理が可能になります。
The definition of LoWPAN headers, other than mesh addressing and fragmentation, 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 LoWPAN adaptation layer, it is not intended to provided general purpose extensibility. This format document specifies a small set of header types using the header stack for clarity, compactness, and orthogonality.
メッシュアドレス指定と断片化以外のローパンヘッダーの定義は、ディスパッチ値、続くヘッダーフィールドの定義、および他のすべてのヘッダーに対する順序制約で構成されています。ヘッダースタック構造は、ローパン適応層の将来の要求に対処するメカニズムを提供しますが、汎用の拡張性を提供することを意図したものではありません。このフォーマットドキュメントは、ヘッダースタックを使用して、明確、コンパクトさ、および直交性を使用して、ヘッダータイプの小さなセットを指定します。
The dispatch type is defined by a zero bit as the first bit and a one bit as the second bit. The dispatch type and header are shown here:
ディスパッチタイプは、最初のビットとしてゼロビット、2番目のビットとして1ビットで定義されます。ディスパッチの種類とヘッダーはここに示されています：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1| Dispatch | type-specific header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Dispatch 6-bit selector. Identifies the type of header immediately following the Dispatch Header.
6ビットセレクターを発送します。ディスパッチヘッダーの直後のヘッダーのタイプを識別します。
type-specific header A header determined by the Dispatch Header.
タイプ固有のヘッダーディスパッチヘッダーによって決定されるヘッダー。
Figure 1: Dispatch Type and Header
図1：ディスパッチタイプとヘッダー
The dispatch value may be treated as an unstructured namespace. Only a few symbols are required to represent current LoWPAN 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.
ディスパッチ値は、構造化されていない名前空間として扱うことができます。現在のローパン機能を表すために必要なシンボルはごくわずかです。追加の機能をディスパッチバイトにエンコードすることでいくつかの追加の節約を達成できますが、これらの測定は将来の代替に対処する能力を制約する傾向があります。
Pattern Header Type
+------------+-----------------------------------------------+
| 00 xxxxxx | NALP - Not a LoWPAN frame |
| 01 000001 | IPv6 - Uncompressed IPv6 Addresses |
| 01 000010 | LOWPAN_HC1 - LOWPAN_HC1 compressed IPv6 |
| 01 000011 | reserved - Reserved for future use |
| ... | reserved - Reserved for future use |
| 01 001111 | reserved - Reserved for future use |
| 01 010000 | LOWPAN_BC0 - LOWPAN_BC0 broadcast |
| 01 010001 | reserved - Reserved for future use |
| ... | reserved - Reserved for future use |
| 01 111110 | reserved - Reserved for future use |
| 01 111111 | ESC - Additional Dispatch byte follows |
| 10 xxxxxx | MESH - Mesh Header |
| 11 000xxx | FRAG1 - Fragmentation Header (first) |
| 11 001000 | reserved - Reserved for future use |
| ... | reserved - Reserved for future use |
| 11 011111 | reserved - Reserved for future use |
| 11 100xxx | FRAGN - Fragmentation Header (subsequent)|
| 11 101000 | reserved - Reserved for future use |
| ... | reserved - Reserved for future use |
| 11 111111 | reserved - Reserved for future use |
+------------+-----------------------------------------------+
Figure 2: Dispatch Value Bit Pattern
図2：ディスパッチ値ビットパターン
NALP: Specifies that the following bits are not a part of the LoWPAN encapsulation, and any LoWPAN node that encounters a dispatch value of 00xxxxxx shall discard the packet. Other non-LoWPAN protocols that wish to coexist with LoWPAN nodes should include a byte matching this pattern immediately following the 802.15.4. header.
NALP：次のビットはローパンカプセル化の一部ではないことを指定し、00XXXXXXのディスパッチ値に遭遇するローパンノードはパケットを破棄するものとします。ローパンノードと共存したい他の非ローパンプロトコルには、802.15.4の直後にこのパターンに一致するバイトを含める必要があります。ヘッダ。
IPv6: Specifies that the following header is an uncompressed IPv6 header [RFC2460].
IPv6：次のヘッダーが非圧縮IPv6ヘッダー[RFC2460]であることを指定します。
LOWPAN_HC1: Specifies that the following header is a LOWPAN_HC1 compressed IPv6 header. This header format is defined in Figure 9.
LowPAN_HC1：次のヘッダーがLowPAN_HC1圧縮IPv6ヘッダーであることを指定します。このヘッダー形式は、図9に定義されています。
LOWPAN_BC0: Specifies that the following header is a LOWPAN_BC0 header for mesh broadcast/multicast support and is described in Section 11.1.
LowPAN_BC0：次のヘッダーがメッシュブロードキャスト/マルチキャストサポートのLowPAN_BC0ヘッダーであり、セクション11.1で説明されていることを指定します。
ESC: Specifies that the following header is a single 8-bit field for the Dispatch value. It allows support for Dispatch values larger than 127.
ESC：次のヘッダーがディスパッチ値の単一の8ビットフィールドであることを指定します。127を超えるディスパッチ値をサポートできます。
The mesh type is defined by a one bit and zero bit as the first two bits. The mesh type and header are shown here:
メッシュタイプは、最初の2ビットとして1ビット、ゼロビットで定義されます。メッシュタイプとヘッダーはここに示されています：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0|V|F|HopsLft| originator address, final address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Mesh Addressing Type and Header
図3：メッシュアドレス指定タイプとヘッダー
Field definitions are as follows:
フィールドの定義は次のとおりです。
V: This 1-bit field SHALL be zero if the Originator (or "Very first") Address is an IEEE extended 64-bit address (EUI-64), or 1 if it is a short 16-bit addresses.
V：この1ビットフィールドは、オリジネーター（または「非常に最初の」）アドレスがIEEE拡張された64ビットアドレス（EUI-64）、または短い16ビットアドレスの場合は1である場合はゼロでなければなりません。
F: This 1-bit field SHALL be zero if the Final Destination Address is an IEEE extended 64-bit address (EUI-64), or 1 if it is a short 16-bit addresses.
F：最終宛先アドレスがIEEE拡張64ビットアドレス（EUI-64）、または短い16ビットアドレスの場合は1つの場合、この1ビットフィールドはゼロでなければなりません。
Hops Left: This 4-bit field SHALL be decremented by each forwarding node before sending this packet towards its next hop. The packet is not forwarded any further if Hops Left is decremented to zero. The value 0xF is reserved and signifies an 8-bit Deep Hops Left field immediately following, and allows a source node to specify a hop limit greater than 14 hops.
左のホップ：この4ビットフィールドは、このパケットを次のホップに送信する前に、各転送ノードによって減少するものとします。ホップがゼロに減少すると、パケットはこれ以上転送されません。値0xFは予約されており、すぐに8ビットディープホップの左フィールドを意味し、ソースノードが14ホップを超えるホップ制限を指定できるようにします。
Originator Address: This is the link-layer address of the Originator.
オリジネーターアドレス：これは、オリジネーターのリンク層アドレスです。
Final Destination Address: This is the link-layer address of the Final Destination.
最終的な宛先アドレス：これは、最終目的地のリンク層アドレスです。
Note that the 'V' and 'F' bits allow for a mix of 16 and 64-bit addresses. This is useful at least to allow for mesh layer "broadcast", as 802.15.4 broadcast addresses are defined as 16-bit short addresses.
「V」および「F」ビットにより、16ビットと64ビットのアドレスが混在することに注意してください。これは、少なくともメッシュ層「ブロードキャスト」を許可するのに役立ちます。802.15.4ブロードキャストアドレスは16ビットの短いアドレスとして定義されているためです。
A further discussion of frame delivery within a mesh is in Section 11.
メッシュ内のフレーム配信のさらなる議論は、セクション11にあります。
If an entire payload (e.g., IPv6) datagram fits within a single 802.15.4 frame, it is unfragmented and the LoWPAN encapsulation should not contain a fragmentation header. If the datagram does not fit within a single IEEE 802.15.4 frame, it SHALL be broken into link fragments. As the fragment offset can only express multiples of eight bytes, all link fragments for a datagram except the last one MUST be multiples of eight bytes in length. The first link fragment SHALL contain the first fragment header as defined below.
ペイロード全体（例：IPv6）データグラムが単一の802.15.4フレーム内に適合する場合、それはフラージュされておらず、ローパンのカプセル化にはフラグメンテーションヘッダーを含めるべきではありません。データグラムが単一のIEEE 802.15.4フレーム内に収まらない場合、リンクフラグメントに分割されます。フラグメントオフセットは8バイトの倍数しか表現できないため、最後のものを除くデータグラムのすべてのリンクフラグメントは、長さ8バイトの倍数でなければなりません。最初のリンクフラグメントには、以下に定義するように最初のフラグメントヘッダーを含める必要があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 0 0 0| datagram_size | datagram_tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: First Fragment
図4：最初のフラグメント
The second and subsequent link fragments (up to and including the last) SHALL contain a fragmentation header that conforms to the format shown below.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 0 0| datagram_size | datagram_tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|datagram_offset|
+-+-+-+-+-+-+-+-+
Figure 5: Subsequent Fragments
図5：後続のフラグメント
datagram_size: This 11-bit field encodes the size of the entire IP packet before link-layer fragmentation (but after IP layer fragmentation). The value of datagram_size SHALL be the same for all link-layer fragments of an IP packet. For IPv6, this SHALL be 40 octets (the size of the uncompressed IPv6 header) more than the value of Payload Length in the IPv6 header [RFC2460] of the packet. Note that this packet may already be fragmented by hosts involved in the communication, i.e., this field needs to encode a maximum length of 1280 octets (the IEEE 802.15.4 link MTU, as defined in this document).
Datagram_size：この11ビットフィールドは、リンクレイヤーフラグメンテーションの前（ただし、IPレイヤーフラグメンテーション後）前にIPパケット全体のサイズをエンコードします。datagram_sizeの値は、IPパケットのすべてのリンク層フラグメントで同じでなければなりません。IPv6の場合、これはパケットのIPv6ヘッダー[RFC2460]のペイロード長の値よりも40オクテット（非圧縮IPv6ヘッダーのサイズ）よりも多くなければなりません。このパケットは、通信に関与するホストによって既に断片化されている可能性があることに注意してください。つまり、このフィールドは最大長さ1280オクテット（このドキュメントで定義されているIEEE 802.15.4 Link MTU）をエンコードする必要があります。
NOTE: This field does not need to be in every packet, as one could send it with the first fragment and elide it subsequently. However, including it in every link fragment eases the task of reassembly in the event that a second (or subsequent) link fragment arrives before the first. In this case, the guarantee of learning the datagram_size as soon as any of the fragments arrives tells the receiver how much buffer space to set aside as it waits for the rest of the fragments. The format above trades off simplicity for efficiency.
注：このフィールドは、すべてのパケットに含まれる必要はありません。最初のフラグメントで送信し、その後削除することができるためです。ただし、すべてのリンクフラグメントにそれを含めることで、2番目の（またはその後の）リンクフラグメントが最初のリンクフラグメントが到着した場合に、再組み立てのタスクを緩和します。この場合、フラグメントが到着するとすぐにdatagram_sizeを学習することを保証することで、残りのフラグメントを待つときに、どのくらいのバッファースペースを置くかを受信者に伝えます。上記の形式は、効率のためにシンプルさをトレードします。
datagram_tag: The value of datagram_tag (datagram tag) SHALL be the same for all link fragments of a payload (e.g., IPv6) datagram. The sender SHALL increment datagram_tag for successive, fragmented datagrams. The incremented value of datagram_tag SHALL wrap from 65535 back to zero. This field is 16 bits long, and its initial value is not defined.
datagram_tag：datagram_tag（datagramタグ）の値は、ペイロードのすべてのリンクフラグメント（例：ipv6）datagramで同じでなければなりません。送信者は、連続した断片化されたデータグラムのためにDatagram_Tagを増分するものとします。Datagram_Tagの増分値は、65535からゼロに戻ります。このフィールドは長さ16ビットで、初期値は定義されていません。
datagram_offset: This field is present only in the second and subsequent link fragments and SHALL specify the offset, in increments of 8 octets, of the fragment from the beginning of the payload datagram. The first octet of the datagram (e.g., the start of the IPv6 header) has an offset of zero; the implicit value of datagram_offset in the first link fragment is zero. This field is 8 bits long.
datagram_offset：このフィールドは、2番目と後続のリンクフラグメントにのみ存在し、ペイロードデータグラムの先頭からフラグメントの8オクテットの増分でオフセットを指定するものとします。データグラムの最初のオクテット（例：IPv6ヘッダーの開始）のオフセットはゼロです。最初のリンクフラグメントのdatagram_offsetの暗黙の値はゼロです。このフィールドの長さは8ビットです。
The recipient of link fragments SHALL use (1) the sender's 802.15.4 source address (or the Originator Address if a Mesh Addressing field is present), (2) the destination's 802.15.4 address (or the Final Destination address if a Mesh Addressing field is present), (3) datagram_size, and (4) datagram_tag to identify all the link fragments that belong to a given datagram.
リンクフラグメントの受信者は、（1）送信者の802.15.4ソースアドレス（またはメッシュアドレス指定フィールドが存在する場合はオリジネーターアドレス）を使用します。フィールドが存在します）、（3）datagram_size、および（4）datagram_tagは、特定のデータグラムに属するすべてのリンクフラグメントを識別します。
Upon receipt of a link fragment, the recipient starts constructing the original unfragmented packet whose size is datagram_size. It uses the datagram_offset field to determine the location of the individual fragments within the original unfragmented packet. For example, it may place the data payload (except the encapsulation header) within a payload datagram reassembly buffer at the location specified by datagram_offset. The size of the reassembly buffer SHALL be determined from datagram_size.
リンクフラグメントを受け取ると、受信者はサイズがdatagram_sizeである元のfragmentedパケットの構築を開始します。Datagram_Offsetフィールドを使用して、元のフラグメントされていないパケット内の個々のフラグメントの位置を決定します。たとえば、Datagram_offsetで指定された場所に、ペイロードデータグラムの再組み立てバッファー内にデータペイロード（カプセル化ヘッダーを除く）を配置する場合があります。再組み立てバッファのサイズは、datagram_sizeから決定するものとします。
If a link fragment that overlaps another fragment is received, as identified above, and differs in either the size or datagram_offset of the overlapped fragment, the fragment(s) already accumulated in the reassembly buffer SHALL be discarded. A fresh reassembly may be commenced with the most recently received link fragment. Fragment overlap is determined by the combination of datagram_offset from the encapsulation header and "Frame Length" from the 802.15.4 Physical Layer Protocol Data Unit (PPDU) packet header.
上記で識別されたように、別のフラグメントが受信され、重複したフラグメントのサイズまたはdatagram_offsetのいずれかが異なるリンクフラグメントが、再組み立てバッファーに既に蓄積されているフラグメントを破棄するものとする場合。新鮮な再組み立ては、最近受信したリンクフラグメントから開始される場合があります。フラグメントオーバーラップは、カプセル化ヘッダーのdatagram_offsetと802.15.4物理層プロトコルデータユニット（PPDU）パケットヘッダーの「フレーム長」の組み合わせによって決定されます。
Upon detection of a IEEE 802.15.4 Disassociation event, fragment recipients MUST discard all link fragments of all partially reassembled payload datagrams, and fragment senders MUST discard all not yet transmitted link fragments of all partially transmitted payload (e.g., IPv6) datagrams. Similarly, when a node first receives a fragment with a given datagram_tag, it starts a reassembly timer. When this time expires, if the entire packet has not been reassembled, the existing fragments MUST be discarded and the reassembly state MUST be flushed. The reassembly timeout MUST be set to a maximum of 60 seconds (this is also the timeout in the IPv6 reassembly procedure [RFC2460]).
IEEE 802.15.4分離イベントを検出すると、フラグメントレシピエントは、部分的に再組み込まれたすべてのペイロードデータグラムのすべてのリンクフラグメントを破棄する必要があり、フラグメント送信者は、部分的に送信されたすべてのペイロード（例えば、IPv6）データグラムのすべての送信されていないリンクフラグメントをすべて破棄する必要があります。同様に、ノードが最初に特定のdatagram_tagを使用してフラグメントを受信すると、再組み立てタイマーを開始します。この時間が期限切れになると、パケット全体が再組み立てされていない場合、既存のフラグメントを破棄し、再組み立て状態をフラッシュする必要があります。再組み立てのタイムアウトは、最大60秒に設定する必要があります（これは、IPv6再組み立て手順[RFC2460]のタイムアウトでもあります）。
This section defines how to obtain an IPv6 interface identifier.
このセクションでは、IPv6インターフェイス識別子を取得する方法を定義します。
The Interface Identifier [RFC4291] for an IEEE 802.15.4 interface may be based on the EUI-64 identifier [EUI64] assigned to the IEEE 802.15.4 device. In this case, the Interface Identifier is formed from the EUI-64 according to the "IPv6 over Ethernet" specification [RFC2464].
IEEE 802.15.4のインターフェイス識別子[RFC4291]は、IEEE 802.15.4デバイスに割り当てられたEUI-64識別子[EUI64]に基づいている場合があります。この場合、界面識別子は、「イーサネット上のIPv6」仕様[RFC2464]に従ってEUI-64から形成されます。
All 802.15.4 devices have an IEEE EUI-64 address, but 16-bit short addresses (Section 3 and Section 12) are also possible. In these cases, a "pseudo 48-bit address" is formed as follows. First, the left-most 32 bits are formed by concatenating 16 zero bits to the 16- bit PAN ID (alternatively, if no PAN ID is known, 16 zero bits may be used). This produces a 32-bit field as follows:
すべての802.15.4デバイスにはIEEE EUI-64アドレスがありますが、16ビットの短いアドレス（セクション3およびセクション12）も可能です。これらの場合、「擬似48ビットアドレス」が次のように形成されます。第一に、左の32ビットは、16ビットパンIDに16ゼロビットを連結することにより形成されます（あるいは、パンIDがわからない場合は、16ゼロビットを使用できます）。これにより、次のように32ビットフィールドが生成されます。
16_bit_PAN:16_zero_bits
16_bit_pan：16_zero_bits
Then, these 32 bits are concatenated with the 16-bit short address. This produces a 48-bit address as follows:
次に、これらの32ビットは16ビットの短いアドレスと連結されます。これにより、次のように48ビットアドレスが生成されます。
32_bits_as_specified_previously:16_bit_short_address
32_bits_as_specified_previvially：16_bit_short_address
The interface identifier is formed from this 48-bit address as per the "IPv6 over Ethernet" specification [RFC2464]. However, in the resultant interface identifier, the "Universal/Local" (U/L) bit SHALL be set to zero in keeping with the fact that this is not a globally unique value. For either address format, all zero addresses MUST NOT be used.
インターフェイス識別子は、「イーサネット上のIPv6」仕様[RFC2464]に従って、この48ビットアドレスから形成されます。ただし、結果のインターフェイス識別子では、「ユニバーサル/ローカル」（U/L）ビットは、これがグローバルに一意の値ではないという事実に合わせて、ゼロに設定するものとします。どちらのアドレス形式でも、すべてのゼロアドレスを使用してはなりません。
A different MAC address set manually or by software MAY be used to derive the Interface Identifier. If such a MAC address is used, its global uniqueness property should be reflected in the value of the U/L bit.
手動またはソフトウェアによって設定された別のMacアドレスを使用して、インターフェイス識別子を導き出すことができます。このようなMACアドレスが使用される場合、そのグローバルユニークネスプロパティは、U/Lビットの値に反映される必要があります。
An IPv6 address prefix used for stateless autoconfiguration [RFC4862] of an IEEE 802.15.4 interface MUST have a length of 64 bits.
IEEE 802.15.4インターフェイスのStateless Autoconfiguration [RFC4862]に使用されるIPv6アドレスプレフィックスは、64ビットの長さが必要です。
The IPv6 link-local address [RFC4291] for an IEEE 802.15.4 interface is formed by appending the Interface Identifier, as defined above, to the prefix FE80::/64.
IEEE 802.15.4のIPv6リンクローカルアドレス[RFC4291]は、上記のようにインターフェイス識別子を接頭辞FE80 ::/64に追加することにより形成されます。
10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+
|1111111010| (zeros) | Interface Identifier |
+----------+-----------------------+----------------------------+
Figure 6
図6
The address resolution procedure for mapping IPv6 non-multicast addresses into IEEE 802.15.4 link-layer addresses follows the general description in Section 7.2 of [RFC4861], unless otherwise specified.
IPv6以外のアドレスをIEEE 802.15.4にマッピングするアドレス解決手順は、特に指定がない限り、[RFC4861]のセクション7.2の一般的な説明に従います。
The Source/Target Link-layer Address option has the following forms when the link layer is IEEE 802.15.4 and the addresses are EUI-64 or 16-bit short addresses, respectively.
ソース/ターゲットリンクレイヤーアドレスオプションには、リンクレイヤーがIEEE 802.15.4であり、アドレスがそれぞれEUI-64または16ビットの短いアドレスの場合、次のフォームがあります。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- IEEE 802.15.4 -+
| EUI-64 |
+- -+
| |
+- Address -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- Padding -+
| |
+- (all zeros) -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 16-bit short Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- Padding -+
| (all zeros) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7
図7
Option fields:
オプションフィールド：
Type:
タイプ：
1: for Source Link-layer address.
1：ソースリンク層アドレス用。
2: for Target Link-layer address.
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 2 if using EUI-64 addresses, or 1 if using 16-bit short addresses.
長さ：これは、8オクテットの単位のこのオプション（タイプおよび長さフィールドを含む）の長さです。このフィールドの値は、EUI-64アドレスを使用する場合は2、16ビットの短いアドレスを使用する場合は1です。
IEEE 802.15.4 Address: The 64-bit IEEE 802.15.4 address, or the 16- bit short address (as per the format in Section 9), in canonical bit order. This is the address the interface currently responds to. This address may be different from the built-in address used to derive the Interface Identifier, because of privacy or security (e.g., of neighbor discovery) considerations.
IEEE 802.15.4アドレス：64ビットIEEE 802.15.4アドレス、または16-ビットの短いアドレス（セクション9の形式による）、標準的なビット順序。これは、インターフェイスが現在応答しているアドレスです。このアドレスは、プライバシーやセキュリティ（近隣発見など）の考慮事項のため、インターフェイス識別子を導出するために使用される組み込みアドレスとは異なる場合があります。
The functionality in this section MUST only be used in a mesh-enabled LoWPAN. An IPv6 packet with a multicast destination address (DST), consisting of the sixteen octets DST[1] through DST[16], is transmitted to the following 802.15.4 16-bit multicast address:
このセクションの機能は、メッシュ対応ローパンでのみ使用する必要があります。マルチキャスト宛先アドレス（DST）を備えたIPv6パケットは、16個のオクテット[1]からDST [16]で構成され、次の802.15.4 16ビットマルチキャストアドレスに送信されます。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 0|DST[15]* | DST[16] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8
図8
Here, DST[15]* refers to the last 5 bits in octet DST[15], that is, bits 3-7 within DST[15]. The initial 3-bit pattern of "100" follows the 16-bit address format for multicast addresses (Section 12).
ここでは、DST [15]*は、Octet DST [15]の最後の5ビット、つまりDST [15]内のビット3-7を指します。「100」の最初の3ビットパターンは、マルチキャストアドレスの16ビットアドレス形式に従います（セクション12）。
This allows for multicast support within 6LoWPAN networks, but the full specification of such support is out of the scope of this document. Example mechanisms are: flooding, controlled flooding, unicasting to the PAN coordinator, etc. It is expected that this would be specified by the different mesh routing mechanisms.
これにより、6lowpanネットワーク内のマルチキャストサポートが可能になりますが、このようなサポートの完全な仕様はこのドキュメントの範囲外です。メカニズムの例は次のとおりです。洪水、制御された洪水、パンコーディネーターへのユニキャストなどです。これは、さまざまなメッシュルーティングメカニズムによって指定されることが予想されます。
There is much published and in-progress standardization work on header compression. Nevertheless, header compression for IPv6 over IEEE 802.15.4 has differing constraints summarized as follows:
ヘッダー圧縮には多くの公開された進行中の標準化作業があります。それにもかかわらず、IEEE 802.15.4を介したIPv6のヘッダー圧縮には、次のように要約されたさまざまな制約があります。
Existing work assumes that there are many flows between any two devices. Here, we assume a very simple and low-context flavor of header compression. Whereas this works independently of flows (potentially several), it does not use any context specific to any flow. Thus, it cannot achieve as much compression as schemes that build a separate context for each flow to be compressed.
既存の作業は、任意の2つのデバイスの間に多くのフローがあることを前提としています。ここでは、ヘッダー圧縮の非常にシンプルで低いコンテキストフレーバーを想定しています。これはフロー（潜在的に複数）とは無関係に機能しますが、フローに固有のコンテキストは使用しません。したがって、各フローが圧縮されるための個別のコンテキストを構築するスキームほどの圧縮を達成することはできません。
Given the very limited packet sizes, it is highly desirable to integrate layer 2 with layer 3 compression, something traditionally not done (although now changing due to the ROHC (RObust Header Compression) working group).
非常に限られたパケットサイズを考えると、レイヤー2をレイヤー3圧縮と統合することが非常に望ましいです。従来は行われていません（ただし、ROHC（堅牢なヘッダー圧縮）ワーキンググループのために変化しています）。
It is expected that IEEE 802.15.4 devices will be deployed in multi-hop networks. However, header compression in a mesh departs from the usual point-to-point link scenario in which the compressor and decompressor are in direct and exclusive communication with each other. In an IEEE 802.15.4 network, it is highly desirable for a device to be able to send header compressed packets via any of its neighbors, with as little preliminary context-building as possible.
IEEE 802.15.4デバイスがマルチホップネットワークに展開されると予想されます。ただし、メッシュのヘッダー圧縮は、コンプレッサーと分解器が互いに直接的かつ排他的な通信にある通常のポイントツーポイントリンクシナリオから出発します。IEEE 802.15.4ネットワークでは、デバイスが近隣のいずれかを介してヘッダー圧縮パケットを送信できることが非常に望ましいことが非常に望ましいため、予備的なコンテキスト構築はできません。
Any new packet formats required by header compression reuse the basic packet formats defined in Section 5 by using different dispatch values.
ヘッダー圧縮で必要な新しいパケット形式は、さまざまなディスパッチ値を使用してセクション5で定義されている基本的なパケット形式を再利用します。
Header compression may result in alignment not falling on an octet boundary. Since hardware typically cannot transmit data in units less than an octet, padding must be used. Padding is done as follows: First, the entire series of contiguous compressed headers is laid out (this document only defines IPv6 and UDP header compression schemes, but others may be defined elsewhere). Then, zero bits SHOULD be added as appropriate to align to an octet boundary. This counteracts any potential misalignment caused by header compression, so subsequent fields (e.g., non-compressed headers or data payloads) start on an octet boundary and follow as usual.
ヘッダー圧縮により、アライメントがオクテットの境界に落ちない場合があります。通常、ハードウェアはオクテット以下のユニットでデータを送信することはできないため、パディングを使用する必要があります。パディングは次のように行われます。まず、一連の連続圧縮ヘッダー全体がレイアウトされます（このドキュメントはIPv6およびUDPヘッダー圧縮スキームのみを定義しますが、他の場所で定義される場合があります）。次に、オクテットの境界に合わせてゼロビットを追加する必要があります。これは、ヘッダー圧縮によって引き起こされる潜在的な不整合をカウンターするため、その後のフィールド（たとえば、圧縮されていないヘッダーまたはデータペイロードなど）がオクテットの境界で開始し、通常どおりに従います。
By virtue of having joined the same 6LoWPAN network, devices share some state. This makes it possible to compress headers without explicitly building any compression context state. Therefore, 6LoWPAN header compression does not keep any flow state; instead, it relies on information pertaining to the entire link. The following IPv6 header values are expected to be common on 6LoWPAN networks, so the HC1 header has been constructed to efficiently compress them from the onset: Version is IPv6; both IPv6 source and destination addresses are link local; the IPv6 interface identifiers (bottom 64 bits) for the source or destination addresses can be inferred from the layer two source and destination addresses (of course, this is only possible for interface identifiers derived from an underlying 802.15.4 MAC address); the packet length can be inferred either from layer two ("Frame Length" in the IEEE 802.15.4 PPDU) or from the "datagram_size" field in the fragment header (if present); both the Traffic Class and the Flow Label are zero; and the Next Header is UDP, ICMP or TCP. The only field in the IPv6 header that always needs to be carried in full is the Hop Limit (8 bits). Depending on how closely the packet matches this common case, different fields may not be compressible thus needing to be carried "in-line" as well (Section 10.3.1). This common IPv6 header (as mentioned above) can be compressed to 2 octets (1 octet for the HC1 encoding and 1 octet for the Hop Limit), instead of 40 octets. Such a packet is compressible via the LOWPAN_HC1 format by using a Dispatch value of LOWPAN_HC1 followed by a LOWPAN_HC1 header "HC1 encoding" field (8 bits) to encode the different combinations as shown below. This header may be preceded by a fragmentation header, which may be preceded by a mesh header.
同じ6lowpanネットワークに参加したことにより、デバイスは何らかの状態を共有しています。これにより、圧縮コンテキスト状態を明示的に構築せずにヘッダーを圧縮できます。したがって、6lowpanヘッダー圧縮はフロー状態を維持しません。代わりに、リンク全体に関連する情報に依存しています。次のIPv6ヘッダー値は6lowpanネットワークで一般的であると予想されるため、HC1ヘッダーは開始から効率的に圧縮するように構築されています。バージョンはIPv6です。IPv6ソースと宛先アドレスの両方がリンクローカルです。ソースまたは宛先アドレスのIPv6インターフェイス識別子（下部64ビット）は、レイヤー2ソースおよび宛先アドレスから推測できます（もちろん、これは基礎となる802.15.4 MACアドレスから派生したインターフェイス識別子でのみ可能です）。パケットの長さは、レイヤー2（IEEE 802.15.4 ppduの「フレーム長」）またはフラグメントヘッダーの「datagram_size」フィールド（存在する場合）から推測できます。トラフィッククラスとフローラベルの両方がゼロです。次のヘッダーはUDP、ICMP、またはTCPです。常に完全に運ぶ必要があるIPv6ヘッダーの唯一のフィールドは、ホップ制限（8ビット）です。パケットがこの一般的なケースとどの程度密接に一致するかに応じて、異なるフィールドが圧縮性がない場合があるため、「インライン」も運ぶ必要があります（セクション10.3.1）。この一般的なIPv6ヘッダー（上記のように）は、40オクテットではなく、2オクテット（HC1エンコーディングで1オクテット、ホップ制限が1オクテット）に圧縮できます。このようなパケットは、LowPAN_HC1のディスパッチ値を使用してLowPAN_HC1ヘッダー「HC1エンコード」フィールド（8ビット）を使用して、以下に示すように異なる組み合わせをエンコードすることにより、LowPAN_HC1形式を介して圧縮可能です。このヘッダーの前には、メッシュヘッダーが先行する場合があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HC1 encoding | Non-Compressed fields follow...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: LOWPAN_HC1 (common compressed header encoding)
図9：LowPAN_HC1（一般的な圧縮ヘッダーエンコーディング）
As can be seen below (bit 7), an HC2 encoding may follow an HC1 octet. In this case, the non-compressed fields follow the HC2 encoding field (Section 10.3).
以下に示すように（ビット7）、HC2エンコーディングはHC1オクテットに従うことがあります。この場合、非圧縮フィールドはHC2エンコーディングフィールドに従います（セクション10.3）。
The address fields encoded by "HC1 encoding" are interpreted as follows:
「HC1エンコード」によってエンコードされたアドレスフィールドは、次のように解釈されます。
PI: Prefix carried in-line (Section 10.3.1).
PI：インラインで伝達されたプレフィックス（セクション10.3.1）。
PC: Prefix compressed (link-local prefix assumed).
PC：プレフィックス圧縮（リンクローカルプレフィックスを想定）。
II: Interface identifier carried in-line (Section 10.3.1).
II：インターフェイス識別子がインラインで運ばれました（セクション10.3.1）。
IC: Interface identifier elided (derivable from the corresponding link-layer address). If applied to the interface identifier of either the source or destination address when routing in a mesh (Section 11), the corresponding link-layer address is that found in the "Mesh Addressing" field (Section 5.2).
IC：排除されたインターフェイス識別子（対応するリンク層アドレスから派生可能）。メッシュ（セクション11）でルーティングするときにソースアドレスまたは宛先アドレスのインターフェイス識別子に適用される場合、対応するリンク層アドレスは、「メッシュアドレス指定」フィールド（セクション5.2）にあるものです。
The "HC1 encoding" is shown below (starting with bit 0 and ending at bit 7):
「HC1エンコーディング」を以下に示します（ビット0から始まり、ビット7で終了します）。
IPv6 source address (bits 0 and 1):
IPv6ソースアドレス（ビット0および1）：
00: PI, II
00：pi、ii
01: PI, IC
01：PI、IC
10: PC, II
10：PC、II
11: PC, IC
11：PC、IC
IPv6 destination address (bits 2 and 3):
IPv6宛先アドレス（ビット2および3）：
00: PI, II
00：pi、ii
01: PI, IC
01：PI、IC
10: PC, II
10：PC、II
11: PC, IC
11：PC、IC
Traffic Class and Flow Label (bit 4):
トラフィッククラスとフローラベル（ビット4）：
0: not compressed; full 8 bits for Traffic Class and 20 bits for Flow Label are sent
0：圧縮されていません。トラフィッククラスのフル8ビットとフローラベルの20ビットが送信されます
1: Traffic Class and Flow Label are zero
1：トラフィッククラスとフローラベルはゼロです
Next Header (bits 5 and 6):
次のヘッダー（ビット5および6）：
00: not compressed; full 8 bits are sent
00：圧縮されていません。完全な8ビットが送信されます
01: UDP
01：UDP
10: ICMP
10：ICMP
11: TCP
11：TCP
HC2 encoding(bit 7):
HC2エンコーディング（ビット7）：
0: No more header compression bits
0：ヘッダー圧縮ビットはもうありません
1: HC1 encoding immediately followed by more header compression bits per HC2 encoding format. Bits 5 and 6 determine which of the possible HC2 encodings apply (e.g., UDP, ICMP, or TCP encodings).
1：HC1エンコーディングはすぐに、HC2エンコード形式ごとにヘッダー圧縮ビットを増やします。ビット5および6は、可能なHC2エンコーディングのどれが適用されるかを決定します（UDP、ICMP、またはTCPエンコーディングなど）。
Bits 5 and 6 of the LOWPAN_HC1 allows compressing the Next Header field in the IPv6 header (for UDP, TCP, and ICMP). Further compression of each of these protocol headers is also possible. This section explains how the UDP header itself may be compressed. The HC2 encoding in this section is the HC_UDP encoding, and it only applies if bits 5 and 6 in HC1 indicate that the protocol that follows the IPv6 header is UDP. The HC_UDP encoding (Figure 10) allows compressing the following fields in the UDP header: source port, destination port, and length. The UDP header's checksum field is not compressed and is therefore carried in full. The scheme defined below allows compressing the UDP header to 4 octets instead of the original 8 octets.
LowPAN_HC1のビット5および6により、IPv6ヘッダーの次のヘッダーフィールド（UDP、TCP、およびICMP用）を圧縮できます。これらの各プロトコルヘッダーのさらなる圧縮も可能です。このセクションでは、UDPヘッダー自体がどのように圧縮されるかについて説明します。このセクションのHC2エンコードはHC_UDPエンコーディングであり、HC1のビット5と6がIPv6ヘッダーに続くプロトコルがUDPであることを示している場合にのみ適用されます。HC_UDPエンコード（図10）により、UDPヘッダーの次のフィールドを圧縮できます：ソースポート、宛先ポート、および長さ。UDPヘッダーのチェックサムフィールドは圧縮されていないため、完全に運ばれます。以下に定義されているスキームにより、元の8オクテットの代わりにUDPヘッダーを4オクテットに圧縮することができます。
The only UDP header field whose value may be deduced from information available elsewhere is the Length. The other fields must be carried in-line either in full or in a partially compressed manner (Section 10.3.2).
他の場所で入手可能な情報から値を推測できる唯一のUDPヘッダーフィールドは長さです。他のフィールドは、完全または部分的に圧縮された方法でインラインで運ばなければなりません（セクション10.3.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|HC_UDP encoding| Fields carried in-line follow...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: HC_UDP (UDP common compressed header encoding)
図10：HC_UDP（UDP共通圧縮ヘッダーエンコーディング）
The "HC_UDP encoding" for UDP is shown below (starting with bit 0 and ending at bit 7):
UDPの「HC_UDPエンコード」を以下に示します（ビット0から始まり、ビット7で終了します）：
UDP source port (bit 0):
UDPソースポート（ビット0）：
0: Not compressed, carried "in-line" (Section 10.3.2)
0：圧縮されておらず、「インライン」を携帯しています（セクション10.3.2）
1: Compressed to 4 bits. The actual 16-bit source port is obtained by calculating: P + short_port value. The value of P is the number 61616 (0xF0B0). The short_port is expressed as a 4-bit value which is carried "in-line" (Section 10.3.2)
1：4ビットに圧縮。実際の16ビットソースポートは、計算することで取得されます。PSHORT_PORT値。pの値は数61616（0xf0b0）です。short_portは、「インライン」に運ばれる4ビット値として表されます（セクション10.3.2）
UDP destination port (bit 1):
UDP宛先ポート（ビット1）：
0: Not compressed, carried "in-line" (Section 10.3.2)
0：圧縮されておらず、「インライン」を携帯しています（セクション10.3.2）
1: Compressed to 4 bits. The actual 16-bit destination port is obtained by calculating: P + short_port value. The value of P is the number 61616 (0xF0B0). The short_port is expressed as a 4-bit value which is carried "in-line" (Section 10.3.2)
1：4ビットに圧縮。実際の16ビット宛先ポートは、計算することによって取得されます。PShort_Port値。pの値は数61616（0xf0b0）です。short_portは、「インライン」に運ばれる4ビット値として表されます（セクション10.3.2）
Length (bit 2):
長さ（ビット2）：
0: not compressed, carried "in-line" (Section 10.3.2)
0：圧縮されておらず、「インライン」を携帯しています（セクション10.3.2）
1: compressed, length computed from IPv6 header length information. The value of the UDP length field is equal to the Payload Length from the IPv6 header, minus the length of any extension headers present between the IPv6 header and the UDP header.
1：IPv6ヘッダーの長さ情報から計算された圧縮、長さ。UDP長さフィールドの値は、IPv6ヘッダーとUDPヘッダーの間に存在する拡張ヘッダーの長さを差し引いたIPv6ヘッダーからのペイロード長に等しくなります。
Reserved (bit 3 through 7)
予約済み（ビット3〜7）
This scheme allows the IPv6 header to be compressed to different degrees. Hence, instead of the entire (standard) IPv6 header, only non-compressed fields need to be sent. The subsequent header (as specified by the Next Header field in the original IPv6 header) immediately follows the IPv6 non-compressed fields.
このスキームにより、IPv6ヘッダーを異なる程度に圧縮できます。したがって、（標準の）IPv6ヘッダー全体の代わりに、圧縮されていないフィールドのみを送信する必要があります。後続のヘッダー（元のIPv6ヘッダーの次のヘッダーフィールドで指定）は、IPv6非圧縮フィールドをすぐに追跡します。
Uncompressed IPv6 addressing is described by a dispatch type containing an IPv6 dispatch value followed by the uncompressed IPv6 header. This dispatch type may be preceded by additional LoWPAN headers.
非圧縮IPv6アドレス指定は、IPv6ディスパッチ値を含むディスパッチタイプに続いて非圧縮IPv6ヘッダーによって説明されます。このディスパッチタイプには、追加のローパンヘッダーが先行する場合があります。
The non-compressed IPv6 field that MUST be always present is the Hop Limit (8 bits). This field MUST always follow the encoding fields (e.g., "HC1 encoding" as shown in Figure 9), perhaps including other future encoding fields). Other non-compressed fields MUST follow the Hop Limit as implied by the "HC1 encoding" in the exact same order as shown above (Section 10.1): source address prefix (64 bits) and/or interface identifier (64 bits), destination address prefix (64 bits) and/or interface identifier (64 bits), Traffic Class (8 bits), Flow Label (20 bits) and Next Header (8 bits). The actual next header (e.g., UDP, TCP, ICMP, etc) follows the non-compressed fields.
常に存在する必要がある非圧縮IPv6フィールドは、ホップ制限（8ビット）です。このフィールドは、おそらく他の将来のエンコードフィールドを含む、図9に示すように、エンコードフィールド（たとえば、「HC1エンコーディング」）に常に従う必要があります。他の非圧縮フィールドは、上記とまったく同じ順序で「HC1エンコーディング」が暗示するようにホップ制限に従う必要があります（セクション10.1）：ソースアドレスプレフィックス（64ビット）および/またはインターフェイス識別子（64ビット）、宛先アドレスプレフィックス（64ビット）および/またはインターフェイス識別子（64ビット）、トラフィッククラス（8ビット）、フローラベル（20ビット）、次のヘッダー（8ビット）。実際の次のヘッダー（UDP、TCP、ICMPなど）は、圧縮されていないフィールドに従います。
This scheme allows the UDP header to be compressed to different degrees. Hence, instead of the entire (standard) UDP header, only non-compressed or partially compressed fields need to be sent.
このスキームにより、UDPヘッダーを異なる程度に圧縮できます。したがって、（標準の）UDPヘッダー全体の代わりに、圧縮されていないまたは部分的に圧縮されたフィールドのみを送信する必要があります。
The non-compressed or partially compressed fields in the UDP header MUST always follow the IPv6 header and any of its associated in-line fields. Any UDP header in-line fields present MUST appear in the same order as the corresponding fields appear in a normal UDP header [RFC0768], e.g., source port, destination port, length, and checksum. If either the source or destination ports are in "short_port" notation (as indicated in the compressed UDP header), then instead of taking 16 bits, the inline port numbers take 4 bits.
UDPヘッダーの非圧縮または部分的に圧縮されたフィールドは、常にIPv6ヘッダーと、関連するインラインフィールドを常に追跡する必要があります。存在するUDPヘッダーインラインフィールドは、対応するフィールドが通常のUDPヘッダー[RFC0768]、例えばソースポート、宛先ポート、長さ、チェックサムに表示されるのと同じ順序で表示される必要があります。ソースポートまたは宛先ポートが「short_port」表記（圧縮されたUDPヘッダーに示されているように）にある場合、16ビットを撮る代わりに、インラインポート番号に4ビットがかかります。
Even though 802.15.4 networks are expected to commonly use mesh routing, the IEEE 802.15.4-2003 specification [ieee802.15.4] does not define such capability. In such cases, Full Function Devices (FFDs) run an ad hoc or mesh routing protocol to populate their routing tables (outside the scope of this document). In such mesh scenarios, two devices do not require direct reachability in order to communicate. Of these devices, the sender is known as the "Originator", and the receiver is known as the "Final Destination". An originator device may use other intermediate devices as forwarders towards the final destination. In order to achieve such frame delivery using unicast, it is necessary to include the link-layer addresses of the originator and final destinations, in addition to the hop-by-hop source and destination.
802.15.4ネットワークは一般にメッシュルーティングを使用すると予想されていますが、IEEE 802.15.4-2003仕様[IEEE802.15.4]はそのような機能を定義しません。このような場合、フルファンクションデバイス（FFD）は、アドホックまたはメッシュルーティングプロトコルを実行して、ルーティングテーブルを設定します（このドキュメントの範囲外）。このようなメッシュシナリオでは、2つのデバイスでは、通信するために直接的な到達可能性を必要としません。これらのデバイスのうち、送信者は「オリジネーター」として知られており、レシーバーは「最終目的地」として知られています。Originatorデバイスは、他の中間デバイスを最終目的地に向かって転送者として使用する場合があります。ユニキャストを使用してそのようなフレーム配信を実現するには、ホップバイホップのソースと宛先に加えて、オリジネーターと最終目的地のリンク層アドレスを含める必要があります。
This section defines how to effect delivery of layer 2 frames in a mesh, given a target "Final Destination" link-layer address.
このセクションでは、ターゲットの「最終目的地」リンク層アドレスを与えられて、メッシュ内のレイヤー2フレームの配信を与える方法を定義します。
Mesh delivery is enabled by including a Mesh Addressing header prior to any other headers of the LoWPAN encapsulation (Section 5), an unfragmented and fragmented header; a full-blown IPv6 header; or a compressed IPv6 header as per Section 10 or any others defined elsewhere.
メッシュ配信は、ローパンカプセル化の他のヘッダー（セクション5）の他のヘッダー、断片化されていない断片化されたヘッダーの前にメッシュアドレス指定ヘッダーを含めることにより有効になります。本格的なIPv6ヘッダー。または、セクション10または他の場所で定義されているその他のように圧縮されたIPv6ヘッダー。
If a node wishes to use a default mesh forwarder to deliver a packet (i.e., because it does not have direct reachability to the destination), it MUST include a Mesh Addressing header with the originator's link-layer address set to its own, and the final destination's link-layer address set to the packet's ultimate destination. It sets the source address in the 802.15.4 header to its own link-layer address, and puts the forwarder's link-layer address in the 802.15.4 header's destination address field. Finally, it transmits the packet.
ノードがデフォルトのメッシュ転送業者を使用してパケットを配信したい場合（つまり、目的地に直接到達可能性がないため）、オリジネーターのリンク層アドレスを設定したメッシュアドレス指定ヘッダーと、パケットの究極の目的地に設定された最終目的地のリンク層アドレス。802.15.4ヘッダーのソースアドレスを独自のリンクレイヤーアドレスに設定し、802.15.4ヘッダーの宛先アドレスフィールドにフォワーダーのリンク層アドレスを配置します。最後に、パケットを送信します。
Similarly, if a node receives a frame with a Mesh Addressing header, it must look at the Mesh Addressing header's "Final Destination" field to determine the real destination. If the node is itself the final destination, it consumes the packet as per normal delivery. If it is not the final destination, the device then reduces the "Hops Left" field, and if the result is zero, discards the packet. Otherwise, the node consults its link-layer routing table, determines what the next hop towards the final destination should be, and puts that address in the destination address field of the 802.15.4 header. Finally, the node changes the source address in the 802.15.4 header to its own link-layer address and transmits the packet.
同様に、ノードがメッシュアドレス指定ヘッダーを備えたフレームを受信する場合、ヘッダーの「最終目的地」フィールドにアドレス指定するメッシュを調べて、実際の宛先を決定する必要があります。ノード自体が最終宛先である場合、通常の配信に従ってパケットを消費します。最終的な宛先でない場合、デバイスは「左のホップ」フィールドを削減し、結果がゼロの場合はパケットを破棄します。それ以外の場合、ノードはリンク層ルーティングテーブルを参照し、最終目的地に向かう次のホップがどうあるべきかを決定し、802.15.4ヘッダーの宛先アドレスフィールドにそのアドレスを配置します。最後に、ノードは802.15.4ヘッダーのソースアドレスを独自のリンク層アドレスに変更し、パケットを送信します。
Whereas a node must participate in a mesh routing protocol to be a forwarder, no such requirement exists for simply using mesh forwarding. Only "Full Function Devices" (FFDs) are expected to participate as routers in a mesh. "Reduced Function Devices" (RFDs) limit themselves to discovering FFDs and using them for all their forwarding, in a manner similar to how IP hosts typically use default routers to forward all their off-link traffic. For an RFD using mesh delivery, the "forwarder" is always the appropriate FFD.
ノードはメッシュルーティングプロトコルに参加して転送者になる必要がありますが、単にメッシュ転送を使用するためのそのような要件は存在しません。「フル機能デバイス」（FFD）のみがメッシュのルーターとして関与することが予想されます。「機能デバイスの削減」（RFD）は、IPホストが通常すべてのリンクトラフィックを転送する方法と同様の方法で、FFDの発見とすべての転送にそれらを使用することに制限します。メッシュ配信を使用したRFDの場合、「フォワーダー」は常に適切なFFDです。
Additional mesh routing functionality is encoded using a routing header immediately following the Mesh header. In particular, a broadcast header consists of a LOWPAN_BC0 dispatch followed by a sequence number field. The sequence number is used to detect duplicate packets (and hopefully suppress them).
追加のメッシュルーティング機能は、メッシュヘッダーの直後にルーティングヘッダーを使用してエンコードされます。特に、ブロードキャストヘッダーは、LowPAN_BC0ディスパッチとシーケンス番号フィールドで構成されます。シーケンス番号は、重複パケットを検出するために使用されます（そして、うまくいけばそれらを抑制します）。
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|1|LOWPAN_BC0 |Sequence Number|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Broadcast Header
図11：ブロードキャストヘッダー
Field definitions are as follows:
フィールドの定義は次のとおりです。
Sequence Number: This 8-bit field SHALL be incremented by the originator whenever it sends a new mesh broadcast or multicast packet. Full specification of how to handle this field is out of the scope of this document.
シーケンス番号：この8ビットフィールドは、新しいメッシュブロードキャストまたはマルチキャストパケットを送信するたびに、オリジネーターによって増加するものとします。このフィールドの処理方法の完全な仕様は、このドキュメントの範囲外です。
Further implications of such mesh-layer broadcast, e.g., whether it maps to a controlled flooding mechanism or its role in, say, topology discovery, is out of the scope of this document.
このようなメッシュ層放送のさらなる意味、たとえば、それが制御された洪水メカニズムへのマップまたはトポロジーの発見におけるその役割は、このドキュメントの範囲外ではありません。
Additional mesh routing capabilities, such as specifying the mesh routing protocol, source routing, and so on may be expressed by defining additional routing headers that precede the fragmentation or addressing header in the header stack. The full specification of such mesh routing capabilities are out of the scope of this document.
メッシュルーティングプロトコル、ソースルーティングなどの指定などの追加のメッシュルーティング機能は、フラグメンテーションに先行する追加のルーティングヘッダーを定義したり、ヘッダースタックのヘッダーにアドレス指定することにより表現できます。このようなメッシュルーティング機能の完全な仕様は、このドキュメントの範囲外です。
This document creates two new IANA registries, as discussed below. Future assignments in these registries are to be coordinated via IANA under the policy of "Specification Required" [RFC2434]. It is expected that this policy will allow for other (non-IETF) organizations to more easily obtain assignments.
このドキュメントは、以下で説明するように、2つの新しいIANAレジストリを作成します。これらのレジストリの将来の割り当ては、「必要な仕様」の方針の下でIANAを介して調整される[RFC2434]。このポリシーにより、他の（非）組織がより簡単に割り当てを取得できるようになることが期待されています。
This document creates a new IANA registry for the Dispatch type field shown in the header definitions in Section 5. This document defines the values IPv6, LOWPAN_HC1 header compression, BC0 broadcast and two escape patterns (NALP to indicate not a LOWPAN frame and ESC to allow additional dispatch bytes). This document defines this field to be 8 bits long. The values 00xxxxxx being reserved and not used, allows for a total of 192 different values, which should be more than enough. If header compression formats in addition to HC1 are defined or if additional TCP, ICMP HC2 formats are defined, it is expected that these will use reserved dispatch values following LOWPAN_HC1. If additional mesh delivery formats are defined these will use reserved values following LOWPAN_BC0.
このドキュメントでは、セクション5のヘッダー定義に示されているディスパッチ型フィールドの新しいIANAレジストリを作成します。このドキュメントでは、IPv6、LowPAN_HC1ヘッダー圧縮、BC0ブロードキャスト、2つのエスケープパターン（ローパンフレームがないことを示すNALPとESCを許可する値を定義します。追加のディスパッチバイト）。このドキュメントでは、このフィールドが8ビットの長さであると定義しています。00XXXXXXは予約され、使用されていないため、合計192の異なる値が可能になります。HC1に加えてヘッダー圧縮形式が定義されている場合、または追加のTCP、ICMP HC2形式が定義されている場合、これらはLowPAN_HC1に続いて予約されたディスパッチ値を使用すると予想されます。追加のメッシュ配信フォーマットが定義されている場合、これらはLowPAN_BC0に続いて予約値を使用します。
This document creates a new IANA registry for the 16-bit short address fields as used in 6LoWPAN packets.
このドキュメントは、6lowpanパケットで使用される16ビットの短いアドレスフィールドの新しいIANAレジストリを作成します。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 16-bit short Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12
図12
This registry MUST include the addresses 0xffff (16-bit broadcast address accepted by all devices currently listening to the channel) and 0xfffe as defined in [ieee802.15.4]. Additionally, within 6LoWPAN networks, 16-bit short addresses MUST follow this format (referring to bit fields in the order from 0 to 7), where "x" is a place holder for an unspecified bit value:
このレジストリには、[IEEE802.15.4]で定義されているように、このレジストリには0xffff（現在チャンネルを聴いているすべてのデバイスが受け入れた16ビットブロードキャストアドレス）と0xfffeを含める必要があります。さらに、6lowpanネットワーク内では、16ビットの短いアドレスがこの形式（0から7までの順序のビットフィールドを参照）に従う必要があります。ここで、「x」は不特定のビット値の場所ホルダーです。
Range 1, 0xxxxxxxxxxxxxxx: The first bit (bit 0) SHALL be zero if the 16-bit address is a unicast address. This leaves 15 bits for the actual address.
範囲1、0xxxxxxxxxxxxxxxx：16ビットアドレスがユニキャストアドレスである場合、最初のビット（ビット0）はゼロになります。これにより、実際のアドレスに15ビットが残ります。
Range 2, 100xxxxxxxxxxxxx: Bits 0, 1, and 2 SHALL follow this pattern if the 16-bit address is a multicast address (see Section 9). This leaves 13 bits for the actual multicast address.
範囲2、100xxxxxxxxxxxxx：16ビットアドレスがマルチキャストアドレスである場合、ビット0、1、および2はこのパターンに従うものとします（セクション9を参照）。これにより、実際のマルチキャストアドレスに13ビットが残ります。
Range 3, 101xxxxxxxxxxxxx: This pattern for bits 0, 1, and 2 is reserved. Any future assignment shall follow the policy mentioned above.
範囲3、101xxxxxxxxxxxxxx：ビット0、1、および2のこのパターンは予約されています。将来の割り当ては、上記のポリシーに従うものとします。
Range 4, 110xxxxxxxxxxxxx: This pattern for bits 0, 1, and 2 is reserved. Any future assignment shall follow the policy mentioned above.
範囲4、110xxxxxxxxxxxxxx：ビット0、1、および2のこのパターンは予約されています。将来の割り当ては、上記のポリシーに従うものとします。
Range 5, 111xxxxxxxxxxxxx: This pattern for bits 0, 1, and 2 is reserved. Any future assignment shall follow the policy mentioned above.
範囲5、111xxxxxxxxxxxxxx：ビット0、1、および2のこのパターンは予約されています。将来の割り当ては、上記のポリシーに従うものとします。
The method of derivation of Interface Identifiers from EUI-64 MAC addresses is intended to preserve global uniqueness when possible. However, there is no protection from duplication through accident or forgery.
EUI-64 MACアドレスからインターフェイス識別子の導出方法は、可能な場合はグローバルな一意性を維持することを目的としています。ただし、事故や偽造による複製からの保護はありません。
Neighbor Discovery in IEEE 802.15.4 links may be susceptible to threats as detailed in [RFC3756]. Mesh routing is expected to be common in IEEE 802.15.4 networks. This implies additional threats due to ad hoc routing as per [KW03]. IEEE 802.15.4 provides some capability for link-layer security. Users are urged to make use of such provisions if at all possible and practical. Doing so will alleviate the threats stated above.
IEEE 802.15.4の近隣発見は、[RFC3756]で詳述されているように、脅威の影響を受けやすい場合があります。メッシュルーティングは、IEEE 802.15.4ネットワークで一般的であると予想されます。これは、[KW03]に従ってアドホックルーティングによる追加の脅威を意味します。IEEE 802.15.4は、リンク層セキュリティに何らかの機能を提供します。ユーザーは、可能な限り実用的であれば、そのような規定を利用することをお勧めします。そうすることで、上記の脅威が軽減されます。
A sizeable portion of IEEE 802.15.4 devices is expected to always communicate within their PAN (i.e., within their link, in IPv6 terms). In response to cost and power consumption considerations, and in keeping with the IEEE 802.15.4 model of "Reduced Function Devices" (RFDs), these devices will typically implement the minimum set of features necessary. Accordingly, security for such devices may rely quite strongly on the mechanisms defined at the link layer by IEEE 802.15.4. The latter, however, only defines the Advanced Encryption Standard (AES) modes for authentication or encryption of IEEE 802.15.4 frames, and does not, in particular, specify key management (presumably group oriented). Other issues to address in real deployments relate to secure configuration and management. Whereas such a complete picture is out of the scope of this document, it is imperative that IEEE 802.15.4 networks be deployed with such considerations in mind. Of course, it is also expected that some IEEE 802.15.4 devices (the so-called "Full Function Devices", or "FFDs") will implement coordination or integration functions. These may communicate regularly with off-link IPv6 peers (in addition to the more common on-link exchanges). Such IPv6 devices are expected to secure their end-to-end communications with the usual mechanisms (e.g., IPsec, TLS, etc).
IEEE 802.15.4デバイスのかなりの部分は、常にPAN内で（つまり、リンク内、IPv6用語で）通信することが期待されています。コストと消費電力の考慮事項に対応し、IEEE 802.15.4「還元機能デバイス」（RFDS）のモデルに沿って、これらのデバイスは通常、必要な機能の最小セットを実装します。したがって、そのようなデバイスのセキュリティは、IEEE 802.15.4によってリンクレイヤーで定義されているメカニズムに非常に強く依存する場合があります。ただし、後者は、IEEE 802.15.4フレームの認証または暗号化のための高度な暗号化標準（AES）モードのみを定義し、特にキー管理（おそらくグループ指向）を指定しません。実際の展開で対処すべきその他の問題は、安全な構成と管理に関連しています。このような完全な画像はこのドキュメントの範囲外ではありませんが、IEEE 802.15.4ネットワークを念頭に置いて展開することが不可欠です。もちろん、一部のIEEE 802.15.4デバイス（いわゆる「フル機能デバイス」または「FFDS」）が調整または統合関数を実装することも期待されています。これらは、オフリンクIPv6ピアと定期的に通信する場合があります（より一般的なオンリンク交換に加えて）。このようなIPv6デバイスは、通常のメカニズム（IPSEC、TLSなど）とのエンドツーエンド通信を保護することが期待されています。
Thanks to the authors of RFC 2464 and RFC 2734, as parts of this document are patterned after theirs. Thanks to Geoff Mulligan for useful discussions which helped shape this document. Erik Nordmark's suggestions were instrumental for the header compression section. Also thanks to Shoichi Sakane, Samita Chakrabarti, Vipul Gupta, Carsten Bormann, Ki-Hyung Kim, Mario Mao, Phil Levis, Magnus Westerlund, and Jari Arkko.
RFC 2464とRFC 2734の著者に感謝します。このドキュメントの一部は、彼らの後にパターン化されています。この文書の形成に役立つ有用な議論をしてくれたGeoff Mulliganに感謝します。Erik Nordmarkの提案は、ヘッダー圧縮セクションのために役立ちました。また、Shoichi Sakane、Samita Chakrabarti、Vipul Gupta、Carsten Bormann、Ki-Hyung Kim、Mario Mao、Phil Levis、Magnus Westerlund、Jari Arkkoにも感謝します。
[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月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[RFC2464] Crawford、M。、「イーサネットネットワーク上のIPv6パケットの送信」、RFC 2464、1998年12月。
[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月。
[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月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、2007年9月。
[ieee802.15.4] IEEE Computer Society, "IEEE Std. 802.15.4-2003", October 2003.
[IEEE802.15.4] IEEE Computer Society、「IEEEStd。802.15.4-2003」、2003年10月。
[EUI64] "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) REGISTRATION AUTHORITY", IEEE http:// standards.ieee.org/regauth/oui/tutorials/EUI64.html.
[EUI64]「64ビットグローバル識別子（EUI-64）登録局のガイドライン」、IEEE http：// stardards.ieee.org/regauth/oui/tutorials/eui64.html。
[KW03] Karlof, Chris and Wagner, David, "Secure Routing in Sensor Networks: Attacks and Countermeasures", Elsevier's AdHoc Networks Journal, Special Issue on Sensor Network Applications and Protocols vol 1, issues 2-3, September 2003.
[KW03] Karlof、Chris and Wagner、David、「センサーネットワークの安全なルーティング：攻撃と対策」、ElsevierのAdhoc Networks Journal、センサーネットワークアプリケーションおよびプロトコルVol 1に関する特別号、2003年9月2〜3号。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768] Postel、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、1980年8月。
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[RFC3756] Nikander、P.、Kempf、J。、およびE. Nordmark、「IPv6 Neighbor Discovery（ND）Trustモデルと脅威」、RFC 3756、2004年5月。
[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.
[RFC3819] Karn、P.、Bormann、C.、Fairhurst、G.、Grossman、D.、Ludwig、R.、Mahdavi、J.、Montenegro、G.、Touch、J.、およびL. Wood、「アドバイス」アドバイスインターネットサブネットワークデザイナー向け」、BCP 89、RFC 3819、2004年7月。
Before settling on the mechanism finally adopted for delivery in a mesh (Section 11), several alternatives were considered. In addition to the hop-by-hop source and destination link-layer addresses, delivering a packet in a LoWPAN mesh requires the end-to-end originator and destination addresses. These could be expressed either as layer 2 or as layer 3 (i.e., IP ) addresses. In the latter case, there would be no need to provide any additional header support in this document (i.e., within the LoWPAN header itself). The link-layer destination address would point to the next hop destination address while the IP header destination address would point to the final destination (IP) address (possibly multiple hops away from the source), and similarly for the source addresses. Thus, while forwarding data, the single-hop source and destination addresses would change at each hop (always pointing to the node doing the forwarding and the "best" next link-layer hop, respectively), while the source and destination IP addresses would remain unchanged. Notice that if an IP packet is fragmented, the individual fragments may arrive at any node out of order. If the initial fragment (which contains the IP header) is delayed for some reason, a node that receives a subsequent fragment would lack the required information. It would be forced to wait until it receives the IP header (within the first fragment) before being able to forward the fragment any further. This imposes some additional buffering requirements on intermediate nodes. Additionally, such a specification would only work for one type of LoWPAN payload: IPv6. In general, it would have to be adapted for any other payload, and would require that payload to provide its own end-to-end addressing information.
メッシュでの配信に最終的に採用されたメカニズムに落ち着く前に（セクション11）、いくつかの選択肢が考慮されました。ホップバイホップソースと宛先リンク層アドレスに加えて、ローパンメッシュにパケットを配信するには、エンドツーエンドのオリジネーターと宛先アドレスが必要です。これらは、レイヤー2またはレイヤー3（つまり、IP）アドレスとして表現できます。後者の場合、このドキュメントに追加のヘッダーサポートを提供する必要はありません（つまり、ローパンヘッダー自体内）。リンク層の宛先アドレスは次のホップ宛先アドレスを指し、IPヘッダーの宛先アドレスは最終宛先（IP）アドレス（おそらくソースから複数のホップ離れたもの）を指し、同様にソースアドレスについても指します。したがって、データの転送中、シングルホップソースと宛先アドレスは各ホップで変更されます（常に転送を行うノードと「最適」なリンク層ホップを指します）。変更されていないまま。IPパケットが断片化されている場合、個々のフラグメントが任意のノードに到達する場合があることに注意してください。何らかの理由で初期フラグメント（IPヘッダーを含む）が遅延している場合、その後のフラグメントを受信するノードには必要な情報がありません。フラグメントをさらに転送できるようにする前に、IPヘッダー（最初のフラグメント内）を受信するまで待つことを余儀なくされます。これにより、中間ノードにいくつかの追加のバッファリング要件が課されます。さらに、このような仕様は、1つのタイプのローパンペイロード、IPv6に対してのみ機能します。一般に、他のペイロードに適合する必要があり、独自のエンドツーエンドアドレス指定情報を提供するためにそのペイロードが必要です。
On the other hand, the approach finally followed (Section 11) creates a mesh at the LoWPAN layer (below layer 3). Accordingly, the link-layer originator and final destination address are included within the LoWPAN header. This enables mesh delivery for any protocol or application layered on the LoWPAN adaptation layer (Section 5). For IPv6 as supported in this document, another advantage of expressing the originator and final destinations as layer 2 addresses is that the IPv6 addresses can be compressed as per the header compression specified in Section 10. Furthermore, the number of octets needed to maintain routing tables is reduced due to the smaller size of 802.15.4 addresses (either 64 bits or 16 bits) as compared to IPv6 addresses (128 bits). A disadvantage is that applications on top of IP do not address packets to link-layer destination addresses, but to IP (layer 3) destination addresses. Thus, given an IP address, there is a need to resolve the corresponding link-layer address. Accordingly, a mesh routing specification needs to clarify the Neighbor Discovery implications, although in some special cases, it may be possible to derive a device's address at layer 2 from its address at layer 3 (and vice versa). Such complete specification is outside the scope of this document.
一方、アプローチは最終的に続きます（セクション11）は、ローパン層（レイヤー3以下）にメッシュを作成します。したがって、リンク層の発信者と最終的な宛先アドレスは、ローパンヘッダーに含まれています。これにより、ローパン適応層に階層化されたプロトコルまたはアプリケーションのメッシュ配信が可能になります（セクション5）。このドキュメントでサポートされているIPv6の場合、レイヤー2アドレスとしてオリジネーターと最終目的地を表現するもう1つの利点は、セクション10で指定されたヘッダー圧縮に従ってIPv6アドレスを圧縮できることです。さらに、ルーティングテーブルを維持するために必要なオクテットの数はIPv6アドレス（128ビット）と比較して、802.15.4のアドレス（64ビットまたは16ビット）のサイズが小さいために減少します。不利な点は、IP上のアプリケーションがリンク層の宛先アドレスへのパケットに対処するのではなく、IP（レイヤー3）の宛先アドレスに対処することです。したがって、IPアドレスが与えられた場合、対応するリンク層アドレスを解決する必要があります。したがって、メッシュルーティング仕様は、近隣の発見への影響を明確にする必要がありますが、特別な場合には、レイヤー2のレイヤー2のデバイスのアドレスをレイヤー3（およびその逆）から導き出すことが可能かもしれません。このような完全な仕様は、このドキュメントの範囲外です。
Authors' Addresses
著者のアドレス
Gabriel Montenegro Microsoft Corporation
ガブリエルモンテネグロマイクロソフトコーポレーション
EMail: gabriel.montenegro@microsoft.com
Nandakishore Kushalnagar Intel Corp
Nandakishore Kushalnagar Intel Corp
EMail: nandakishore.kushalnagar@intel.com
Jonathan W. Hui Arch Rock Corp
ジョナサン・W・アーチ・ロック・コーポレーション
EMail: jhui@archrock.com
David E. Culler Arch Rock Corp
EMail: dculler@archrock.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。