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
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.
この文書では、IEEE 802.15.4ネットワーク上でIPv6パケットの送信のためのフレームフォーマットおよび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ネットワーク、およびIEEE 802.15.4メッシュのパケット配信のために必要な規定のIPv6を実用的にするために必要なヘッダ圧縮のための機構を定義します。しかし、メッシュルーティング（使用される特定のプロトコル、近隣探索との相互作用など）の完全な仕様は、この文書の範囲外です。
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"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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
PAN：パーソナルエリアネットワーク
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.
ビーコンフレーム、MACコマンドフレーム、確認応答フレーム、及びデータフレーム：IEEE 802.15.4は、フレーム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ネットワークは有効-nonbeacon又はビーコン有効[IEEE802.15.4]のいずれかとすることができます。後者は、デバイスは、いわゆるコーディネータのビーコンによって同期された任意のモードです。これは、競合のない保証タイムサービス（GTS）が可能な内スーパーフレームを使用することができます。このドキュメントでは、IEEEネットワークは、ビーコン対応モードで実行する必要はありません。 nonbeacon対応ネットワークでは、（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.
nonbeacon対応ネットワークでは、ビーコンは、同期のために使用されていません。しかし、彼らはまだ協会と解離イベントを支援するためのリンク層デバイスの発見に役立ちます。この文書では、これらの機能を支援するようにビーコンを構成することをお勧めします。これらのイベントは、ネットワーク接続の検出を支援するための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フレームヘッダに含まれることを必要とします。送信元または宛先PAN 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ビットのPAN [IEEE802.15.4]内の固有のアドレス（関連イベントの後）のいずれかの使用を可能にします。この文書では、64ビット拡張アドレス、および16ビットの短いアドレスの両方をサポートしています。節に本質的に一過性である12ショートアドレスを指定され6LoWPANs内で使用するため、この文書では、注意の単語がである、16ビットのショートアドレスのフォーマット（IEEE 802.15.4によって課されるものを超えて）追加の制約を課します順序：彼らは関連イベント中にPANコーディネータ機能によってdoledされているので、その有効性と独自性はその協会の寿命によって制限されます。これは、関連の満了によって、または単に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.先PAN識別子がフレームに含まれ、それが問題のリンクのPAN 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オクテット9とAES-CCM-32およびAES-CCM-64のために13対、それぞれ）でのみ81オクテットを残し、さらにオーバーヘッドを課します利用可能。これは、はるか1280オクテットの最小IPv6パケットサイズより明らかであり、IPv6仕様のセクション5 [RFC2460]に合わせて、fragmentionおよび再組み立てアダプテーション層は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オクテットを残します。後者は、アプリケーション・データのための唯一の33オクテットを残すヘッダに8つのオクテットを使用します。先に指摘したように加え、さらに多くのオクテットを使用する断片化と再組み立て層が必要とされています。
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のほとんどのアプリケーションは、このような大きなパケットを使用せず、（b）は、適切なヘッダ圧縮と組み合わせて小さなアプリケーションペイロードは、単一の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）内のペイロードである（その後「LoWPANカプセル化」と呼ばれます）。 LoWPANペイロード（例えば、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の上で輸送すべてLoWPANカプセル化されたデータグラムをカプセル化ヘッダスタックによって前置されます。ヘッダ・スタック内の各ヘッダは、ゼロ以上のヘッダフィールドに続くヘッダのタイプを含みます。 IPv6は、最終的に、ホップバイホップオプション、ルーティング、フラグメンテーション、宛先オプション、およびペイロードをアドレス指定、次の順序で、スタックに含まれるであろうヘッダ内のに対し、[RFC2460]。 LoWPANヘッダに、類似のヘッダ配列はメッシュ（L2）のアドレス指定され、断片化、および最終的にペイロード（L2ブロードキャスト/マルチキャストを含む）ホップバイホップオプション。これらの例はLoWPANネットワークで使用され得る典型的なヘッダ・スタックを示します。
A LoWPAN encapsulated IPv6 datagram:
LoWPANは、IPv6データグラムをカプセル化：
+---------------+-------------+---------+
| IPv6 Dispatch | IPv6 Header | Payload |
+---------------+-------------+---------+
A LoWPAN encapsulated LOWPAN_HC1 compressed IPv6 datagram:
LoWPANはLOWPAN_HC1圧縮IPv6データグラムをカプセル化：
+--------------+------------+---------+
| HC1 Dispatch | HC1 Header | Payload |
+--------------+------------+---------+
A LoWPAN encapsulated LOWPAN_HC1 compressed IPv6 datagram that requires mesh addressing:
LoWPANは、メッシュのアドレッシングを必要とLOWPAN_HC1圧縮IPv6データグラムをカプセル化：
+-----------+-------------+--------------+------------+---------+
| Mesh Type | Mesh Header | HC1 Dispatch | HC1 Header | Payload |
+-----------+-------------+--------------+------------+---------+
A LoWPAN encapsulated LOWPAN_HC1 compressed IPv6 datagram that requires fragmentation:
断片化を必要とIPv6データグラムの圧縮LoWPANカプセル化LOWPAN_HC1：
+-----------+-------------+--------------+------------+---------+
| 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アドレッシングおよび断片化メッシュの両方が必要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メッシュブロードキャスト/マルチキャストをサポートするためにアドレッシング放送ヘッダメッシュの両方が必要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:
複数LoWPANヘッダが同じパケットで使用される場合、それらは以下の順序で出現する必要があります。
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ヘッダーなど）が有効LoWPANカプセル化ヘッダーの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.
メッシュはアドレッシング及びフラグメンテーション以外LoWPANヘッダの定義は、他のすべてのヘッダに対するディスパッチ値、追従ヘッダフィールドの定義、およびその順序の制約から成ります。ヘッダスタック構造がLoWPAN適応層上に将来の需要に対処するためのメカニズムを提供するが、それは、汎用拡張性を提供することを意図していません。この形式の文書は、明確に、小型化、および直交のヘッダスタックを使用して、ヘッダタイプの小さなセットを指定します。
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.
ディスパッチ値は、構造化されていない名前空間として扱うことができます。ほんの数シンボルは、現在のLoWPAN機能を表現するために必要とされています。いくつかの追加の節約が派遣バイトに追加機能を符号化することによって達成することができるが、これらの対策は、将来の選択肢に対処する能力を制約する傾向があります。
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：次のビットがLoWPANカプセル化の一部ではないことを指定し、そして00xxxxxxのディスパッチ値に遭遇任意LoWPANノードはパケットを廃棄しなければなりません。 LoWPANノードと共存したいその他の非LoWPANプロトコルは、このパターンはすぐ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：以下のヘッダはディスパッチ値に対して1つの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：発信元（または「非常に最初の」）アドレスは、それが短い16ビットのアドレスである場合IEEEは64ビットのアドレス（EUI-64）、または1を拡張する場合、この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：それは短い16ビットのアドレスである場合に最終的なデスティネーションアドレスは、IEEE 64ビットのアドレス（EUI-64）、または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ビットのフィールドは、その次ホップに向けて、このパケットを送信する前に、各転送ノードによってデクリメントさSHALL。ホップ左がゼロになるとパケットがそれ以上転送されません。値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フレームに収まる場合は、断片化されていないとLoWPANカプセル化は、断片化ヘッダを含むべきではありません。データグラムは、単一のIEEE 802.15.4フレーム内に収まらない場合は、リンクの断片に分割するものとします。フラグメントオフセットのみが8バイトの倍数を表現することができるように、最後のものを除いて、データグラムのためのすべてのリンク断片は長さが8バイトの倍数でなければなりません。以下に定義されるように、第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 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.
目以降のリンクフラグメント（最大と最後を含む）を以下に示すフォーマットに準拠フラグメンテーションヘッダーを含まなければなりません。
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リンク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.
注：このフィールドは、1が最初のフラグメントでそれを送信し、その後、それをElideの可能性として、すべてのパケットである必要はありません。しかし、すべてのリンクフラグメントに含めて第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（データグラムタグ）の値は、ペイロード（例えば、IPv6）のデータグラムの全てのリンク断片に対して同じでなければなりません。送信者は、連続した、断片化したデータグラムのための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：このフィールドは目以降リンク断片に存在し、ペイロードデータグラムの先頭から断片の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ソースアドレス（またはメッシュアドレッシングフィールドが存在する場合には発信元アドレス）、（2）先の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あるオリジナル非断片化パケットを構築開始します。これは、元の非断片化パケット内の個々のフラグメントの位置を決定する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のいずれかで異なるされている場合は、既に再組み立てバッファに蓄積された断片（単数または複数）は捨てられるもの。新鮮な再構築は、最も最近受信したリンクフラグメントを開始することができます。断片の重複は、802.15.4物理層プロトコルデータユニット（PPDU）パケットヘッダからカプセル化ヘッダと「フレーム長」からdatagram_offsetの組み合わせによって決定されます。
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デバイスに割り当てられEUI64識別子[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ビットPAN IDに16ゼロビットを連結することによって形成されているが（非PAN 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_previously：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インタフェースのステートレス自動設定に使用されるIPv6アドレスプレフィックス[RFC4862]は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.
プレフィックスFE80 :: / 64に、上記で定義したIEEE 802.15.4インタフェースのIPv6リンクローカルアドレス[RFC4291]は、インターフェース識別子を付加することによって形成されます。
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.
IEEE 802.15.4のリンク層アドレスにマッピングIPv6の非マルチキャストアドレスのためのアドレス解決手順は、[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つのオクテットの単位で（タイプと長さフィールドを含む）は、このオプションの長さです。 16ビットの短いアドレスを使用する場合EUI-64アドレスを使用して、または1の場合、このフィールドの値は2です。
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
IEEE 802.15.4住所：64ビットIEEE 802.15.4アドレス、または16ビットのショートアドレス（セクション9でフォーマットごとなど）、正規で
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.
ビット順。これは、インターフェイスが現在応答するアドレスです。このアドレスは、理由は、プライバシーやセキュリティ（例えば、近隣探索の）配慮のため、内蔵のインタフェース識別子を導出するために使用されるアドレスと異なる場合があります。
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:
このセクションの機能は、メッシュのみ対応LoWPANに使用しなければなりません。マルチキャスト宛先アドレス（DST）とIPv6パケットは、16個のオクテットからなるDST [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] *オクテットDSTの最後の5ビットを意味する[15]、すなわち、DST [15]内のビット3~7です。 「100」の最初の3ビットパターンは、マルチキャストアドレス（セクション12）のための16ビットアドレスフォーマットに従います。
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ネットワーク内のマルチキャストをサポートすることができますが、そのようなサポートの完全な仕様は、このドキュメントの範囲外です。例メカニズムは次のとおり等洪水、制御されたフラッディング、PANコーディネータのユニキャスト、これは、異なるメッシュルーティングメカニズムによって指定されるであろうことが予想されます。
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).
（今に起因ROHC（ロバストヘッダ圧縮）ワーキンググループへの変更が）非常に限られたパケットサイズを考えると、それはレイヤ3圧縮とレイヤ2を統合することが非常に望ましい、何かが伝統的に行われていません。
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ヘッダー値はHC1ヘッダを効率的に開始からそれらを圧縮するように構成されているので、6LoWPANネットワークに共通であることが期待される：バージョンがIPv6です。 IPv6ソースと宛先の両方のアドレスが、リンクローカルです。送信元または宛先アドレスのIPv6インタフェース識別子（ボトム64ビット）（もちろん、これは根本的な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ヘッダ「HC1エンコード」フィールド（8ビット）に続いLOWPAN_HC1のディスパッチ値を用いて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
１０： ＰＣ、 いい
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
１０： ＰＣ、 いい
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は、（例えば、UDP、ICMP、またはTCPエンコーディング）を適用可能HC2エンコーディングのかを決定します。
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は（UDP、TCP、およびICMPなど）IPv6ヘッダーの次ヘッダフィールドを圧縮することができます。これらのプロトコルヘッダのそれぞれのさらに圧縮することも可能です。このセクションでは、UDPヘッダ自体を圧縮することができる方法を説明しています。このセクションでHC2エンコーディングはHC_UDP符号化され、そしてHC1のビット5と6は、IPv6ヘッダに続くプロトコルがUDPであることを示す場合にのみ適用されます。送信元ポート、宛先ポート、および長さ：HC_UDP符号化（図10）は、UDPヘッダ内の次のフィールドを圧縮することができます。 UDPヘッダのチェックサムフィールドが圧縮されていないため、フルで運ばれます。以下に定義されるスキームは、4つのオクテットの代わりに元の8つのオクテットにUDPヘッダを圧縮することができます。
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ビットに圧縮。 P + short_port値：実際の16ビットのソースポートを計算することによって得られます。 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ビットに圧縮。 P + short_port値：実際の16ビット宛先ポートを計算することによって得られます。 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ヘッダからペイロード長、マイナスIPv6ヘッダとUDPヘッダとの間に存在する任意の拡張ヘッダーの長さに等しいです。
Reserved (bit 3 through 7)
予約（7を介してビット3）
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のディスパッチ値を含むディスパッチ・タイプによって記述されます。このディスパッチタイプは、追加のLoWPANヘッダーによって先行されてもよいです。
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ビット）です。このフィールドは、常に符号化フィールドに従わなければならない（例えば、「HC1エンコード」図9に示すように）おそらく他の将来の符号化フィールドを含みます）。ソース・アドレス・プレフィックス（64ビット）及び/又はインタフェース識別子（64ビット）、宛先アドレス：上記のように正確に同じ順序で「HC1エンコード」（セクション10.1）によって示唆されるように、他の非圧縮フィールドがホップ制限に従わなければなりませんプレフィックス（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ヘッダは、対応するフィールドは[RFC0768]、例えば、送信元ポート、宛先ポート、長さ、およびチェックサム通常UDPヘッダに現れるのと同じ順序で現れなければなりません。ソースまたは宛先ポートが（圧縮されたUDPヘッダに示されるように）「short_port」表記である場合、代わりに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は、このような機能を定義していません。このような場合には、フル機能デバイス（FFDs）は、広告ホックを実行するか（この文書の範囲外で）自分のルーティングテーブルを取り込むために、ルーティングプロトコルをメッシュ。そのようなメッシュのシナリオでは、2つのデバイスが通信するために直接到達可能性を必要としません。これらのデバイスの、送信者が「発信」として知られており、受信機は、「ファイナルデスティネーション」として知られています。発信装置は、最終的な目的地に向かってフォワーダのような他の中間デバイスを使用してもよいです。ユニキャストを使用してこのようなフレームの送達を達成するためには、ホップバイホップ送信元と宛先のほかに、発信者と最終目的地のリンク層アドレスを含む必要があります。
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.
メッシュ送達は前LoWPANカプセル化（第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.
ノードがフォワーダであると、メッシュルーティングプロトコルに参加しなければならないのに対し、このような要件は、単に、メッシュ転送を使用するために存在しません。唯一の「フル機能デバイス」（FFDs）はメッシュ内のルータとして参加することが期待されています。 「縮小機能デバイス」（RFDS）は、IPホストは通常、すべてのオフリンクトラフィックを転送するために、デフォルトのルータを使用する方法と同様の方法で、FFDsを発見し、それらのすべての転送のためにそれらを使用して自分自身を制限します。 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.
以下に述べるようにこの文書では、二つの新しいIANAレジストリを作成します。これらのレジストリの将来の割り当ては、「仕様が必要」[RFC2434]の方針の下でIANAを経由してコーディネートすることになっています。このポリシーがより簡単に割り当てを得るために、他の（非IETF）の組織を可能にすることが期待されます。
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.
この文書は、NALPを許可しないLOWPANフレームとESCを示すために、（この文書は値のIPv6、LOWPAN_HC1ヘッダ圧縮、BC0放送二つエスケープパターンを定義するセクション5のヘッダ定義で示さディスパッチタイプフィールドのための新しいIANAレジストリを作成します追加の派遣バイト）。この文書では、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ビットのショートアドレスを「X」は未指定ビット値のプレースホルダーであり、（0から7まで順にビットフィールドを参照）、この形式に従う必要があります。
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、0xxxxxxxxxxxxxxx：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：ビット0、1、および16ビットのアドレスがマルチキャストアドレスであれば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、101xxxxxxxxxxxxx：ビット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、110xxxxxxxxxxxxx：ビット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、111xxxxxxxxxxxxx：ビット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.
[RFC3756]に詳述されるようにIEEEにおける近隣探索802.15.4リンクが脅威を受けやすいかもしれません。メッシュルーティングは、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デバイスのかなりの部分が常に（すなわち、IPv6の用語で、そのリンク内の）それらのPAN内で通信することが期待されます。消費の考慮事項をコストと消費電力に応じて、および「縮小機能デバイス」（RFDS）のIEEE 802.15.4モデルに合わせて、これらのデバイスは、一般的に必要な最小限の機能セットを実装します。したがって、このようなデバイスのためのセキュリティは、IEEE 802.15.4でリンク層で定義されたメカニズムにかなり強く依存してもよいです。後者は、しかし、唯一のIEEE 802.15.4フレームの認証または暗号化のAdvanced Encryption Standard（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の作者のおかげで、この文書の一部が彼らの後にパターン化されているよう。この文書を形作る助けた有益な議論のためのジェフ・マリガンに感謝します。エリックNordmarkとの提案は、ヘッダ圧縮部のために尽力しました。また正一坂根、Samita Chakrabarti、ビパル・グプタ、カルステンボルマン、キヒョンジュキム、マリオ真央、フィル・リーバイス、マグヌスウェスター、とヤリArkkoに感謝。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[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]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[RFC2464]クロフォード、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.デアリング、 "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.、シンプソン、W.、およびH.ソリマン、 "IPバージョン6（IPv6）のための近隣探索"、RFC 4861、2007年9月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862]トムソン、S.、Narten氏、T.、およびT.神明、 "IPv6のステートレスアドレス自動設定"、RFC 4862、2007年9月。
[ieee802.15.4] IEEE Computer Society, "IEEE Std. 802.15.4-2003", October 2003.
[IEEE802.15.4] IEEEコンピュータ学会、 "IEEE規格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-BITグローバル識別子（EUI64）登録機関のためのガイドライン"、IEEEのhttp：// standards.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、クリスとワグナー、デビッド、「センサネットワークにおけるルーティングを固定：攻撃とその対策」、エルゼビアのアドホックネットワークジャーナル、センサネットワークアプリケーションとプロトコルの巻1特集は、2003年9月、2-3を発行します。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768]ポステル、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.、ケンプ、J.、およびE. Nordmarkと、 "IPv6近隣探索（ND）信頼モデルと脅威"、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]カーン、P.、ボルマン、C.、Fairhurst、G.、グロスマン、D.、ルートヴィヒ、R.、Mahdavi、J.、モンテネグロ、G.、タッチ、J.、およびL.ウッド、「アドバイスインターネットサブネットワークデザイナー」、BCP 89、RFC 3819、2004年7月のため。
Appendix A. Alternatives for Delivery of Frames in a Mesh
メッシュ内のフレームの送達のための付録A.代替
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節）での配信のために採用したメカニズムにセトリングする前に、いくつかの選択肢を検討しました。 LoWPANメッシュ内のパケットを配信するホップバイホップ送信元と宛先のリンク層アドレスに加えて、エンド・ツー・エンドの発信元アドレスと宛先アドレスを必要とします。これらは、層2として、またはレイヤ3（すなわち、IP）アドレスのいずれかとして表現することができます。後者の場合には、この文書に記載されている任意の追加ヘッダのサポートを提供する必要はないであろう（すなわち、LoWPANヘッダ自体の内で）。リンク層の宛先アドレスが送信元アドレスについても同様にIPヘッダの宛先アドレスは、（おそらく複数ホップ離れたソースから）最終宛先（IP）アドレスを指すことになるながら次ホップ先アドレスを指す、となります。データを転送しつつ、シングルホップ送信元アドレスと宛先アドレスは、各ホップで変化する（常にそれぞれ転送と「最良の」次のリンク層のホップを行うノードを指す）、送信元および宛先IPアドレスながら希望変わりません。 IPパケットが断片化されている場合、個々のフラグメントは、順序のうち任意のノードに到達できることに注意してください。 （IPヘッダーを含む）の最初の断片が何らかの理由で遅れている場合は、後続のフラグメントを受信したノードは、必要な情報を欠いていることになります。それ以上のフラグメントを転送することができる前に（最初のフラグメント内）IPヘッダを受信するまで待つことを余儀なくされるであろう。これは、中間ノード上のいくつかの追加のバッファリング要件を課しています。 IPv6の：さらに、このような仕様はLoWPANペイロードの一つのタイプのために働くだろう。一般的に、それは他のペイロードのために適合されなければならない、そしてそれ自身のエンド・ツー・エンドのアドレス指定情報を提供するためにそのペイロードを必要とするであろう。
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以下）LoWPAN層にメッシュを作成します。したがって、リンク層元および最終宛先アドレスがLoWPANヘッダ内に含まれます。これはLoWPANアダプテーション層（セクション5）に積層任意のプロトコルまたはアプリケーションのメッシュ送達を可能にします。 IPv6のため、この文書でサポートされるように、レイヤ2つのアドレスとして発信し、最終宛先を発現する別の利点は、IPv6アドレスはまた、セクション10で指定されたヘッダ圧縮に従って圧縮することができるということである、オクテットの数は、ルーティングテーブルを維持するために必要IPv6アドレス（128ビット）に比べてによる802.15.4アドレス（64ビットまたは16ビットのいずれか）の小さいサイズに縮小されます。欠点は、IPの上でアプリケーションがリンク層の宛先アドレスに、しかし、IP（レイヤ3）宛先アドレスにパケットを扱っていないということです。このように、IPアドレス与えられ、対応するリンク層アドレスを解決する必要があります。したがって、メッシュルーティング仕様は、いくつかの特別なケースでは、レイヤ3（及びその逆）で、そのアドレスからレイヤ2のデバイスのアドレスを導出することが可能かもしれないが、近隣探索の影響を明確にする必要があります。このような完全な仕様は、この文書の範囲外です。
Authors' Addresses
著者のアドレス
Gabriel Montenegro Microsoft Corporation
ガブリエルモンテネグロマイクロソフト株式会社
EMail: gabriel.montenegro@microsoft.com
メールアドレス：gabriel.montenegro@microsoft.com
Nandakishore Kushalnagar Intel Corp
なんだきしょれ くしゃｌながｒ いんてｌ こｒｐ
EMail: nandakishore.kushalnagar@intel.com
メールアドレス：nandakishore.kushalnagar@intel.com
Jonathan W. Hui Arch Rock Corp
ジョナサン・W.ホイアーチロック株式会社
EMail: jhui@archrock.com
メールアドレス：jhui@archrock.com
David E. Culler Arch Rock Corp
デイビット・E・カラーアーチロック株式会社
EMail: dculler@archrock.com
メールアドレス：dculler@archrock.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。