メインコンテンツまでスキップ

RFC 4944 - IEEE 802.15.4ネットワーク上のIPv6パケットの伝送

  • ステータス: Proposed Standard
  • 発行日: September 2007
  • ストリーム: IETF
  • エラッタ: エラッタなし

概要 (Abstract)​

本文書は、IEEE 802.15.4ネットワーク上でIPv6パケット (IPv6 Packets) を伝送するためのフレーム形式 (Frame Format)、およびこれらのネットワーク上でIPv6リンクローカルアドレス (Link-Local Addresses) とステートレス自動設定アドレス (Stateless Autoconfiguration) を形成する方法を記述します。追加の仕様には、共有コンテキストを使用したシンプルなヘッダー圧縮スキーム (Header Compression)、およびIEEE 802.15.4メッシュネットワーク (Mesh Networks) におけるパケット配信の規定が含まれます。

目次 (Contents)​

付録 (Appendices)​

関連リソース​

1. Introduction (はじめに)​

IEEE 802.15.4標準 [[ieee802.15.4]] は、低消費電力パーソナルエリアネットワーク (Low-Power Personal Area Networks) を対象としています。本文書は、IEEE 802.15.4ネットワーク上でIPv6 [[RFC2460]] パケットを伝送するためのフレーム形式 (Frame Format)、およびこれらのネットワーク上でIPv6リンクローカルアドレス (Link-Local Addresses) とステートレス自動設定アドレス (Statelessly Autoconfigured Addresses) を形成する方法を定義します。IPv6が要求するパケットサイズは、IEEE 802.15.4の最大フレームサイズよりはるかに大きいため、適応層 (Adaptation Layer) が定義されています。本文書はまた、IEEE 802.15.4ネットワーク上でIPv6を実用的にするために必要なヘッダー圧縮 (Header Compression) メカニズム、およびIEEE 802.15.4メッシュネットワーク (Meshes) におけるパケット配信に必要な規定を定義します。ただし、メッシュルーティングの完全な仕様（使用される特定のプロトコル、近隣探索との相互作用など）は、本文書の範囲外です。

1.1. Requirements Notation (要件表記法)​

本文書におけるキーワード「MUST」（しなければならない）、「MUST NOT」（してはならない）、「REQUIRED」（必須である）、「SHALL」（しなければならない）、「SHALL NOT」（してはならない）、「SHOULD」（すべきである）、「SHOULD NOT」（すべきでない）、「RECOMMENDED」（推奨される）、「MAY」（してもよい）、および「OPTIONAL」（任意である）は、[[RFC2119]] に記載されているように解釈されるものとします。

1.2. Terms Used (用語)​

  • AES: Advanced Encryption Scheme (高度暗号化方式)
  • CSMA/CA: Carrier Sense Multiple Access / Collision Avoidance (キャリア検知多重アクセス/衝突回避)
  • FFD: Full Function Device (フル機能デバイス)
  • GTS: Guaranteed Time Service (保証時間サービス)
  • MTU: Maximum Transmission Unit (最大伝送単位)
  • MAC: Media Access Control (媒体アクセス制御)
  • PAN: Personal Area Network (パーソナルエリアネットワーク)
  • RFD: Reduced Function Device (縮小機能デバイス)

2. IEEE 802.15.4 Mode for IP (IP用IEEE 802.15.4モード)​

IEEE 802.15.4は、ビーコンフレーム (Beacon Frame)、MACコマンドフレーム (MAC Command Frame)、確認応答フレーム (Acknowledgment Frame)、およびデータフレーム (Data Frame) の4種類のフレームタイプを定義しています。IPv6パケットはデータフレーム上で伝送されなければなりません (MUST)。データフレームは、オプションで確認応答を要求できます。[[RFC3819]] の推奨に従い、IPv6パケットは、リンク層の回復を支援するために、確認応答を要求するフレーム内で伝送されるべきです (SHOULD)。

IEEE 802.15.4ネットワークは、ビーコンレスモード (Beaconless Mode) またはビーコン有効モード (Beacon-Enabled Mode) [[ieee802.15.4]] で動作できます。後者は、デバイスがコーディネーター (Coordinator) と呼ばれるビーコンによって同期されるオプションのモードです。これにより、スーパーフレーム (Superframes) の使用が可能になり、その中で競合のない保証時間サービス (Guaranteed Time Service, GTS) を実装できます。本文書は、IEEEネットワークがビーコン有効モードで動作することを要求しません。ビーコンレスネットワークでは、データフレーム（IPv6パケットを運ぶフレームを含む）は、スロットなしCSMA/CAの競合ベースチャネルアクセス方式によって送信されます。

ビーコンレスネットワークでは、ビーコンは同期には使用されません。しかし、それらは、関連付けおよび関連付け解除イベントを支援するために、リンク層デバイス発見に有用です。本文書は、これらの機能を支援するためにビーコンを設定することを推奨します。さらに、これらのイベントはネットワーク接続性の検出を支援するためにIPv6層で利用可能であるべきです (SHOULD)。これは、本文書の執筆時点でIETFが取り組んでいる問題です。

この仕様では、フレーム内で送信元アドレスまたは宛先アドレス（または両方）を省略できます。本文書で定義されているメカニズムは、IEEE 802.15.4フレームヘッダー内に送信元アドレスと宛先アドレスの両方が含まれることを要求します。送信元または宛先のPAN IDフィールドも含めることができます。

3. Addressing Modes (アドレッシングモード)​

IEEE 802.15.4は、いくつかのアドレッシングモードを定義しています。IEEE 64ビット拡張アドレス (Extended Address) または（関連付けイベント後に）PAN [[ieee802.15.4]] 内で一意の16ビットアドレスの使用を許可します。本文書は、64ビット拡張アドレスと16ビット短アドレス (Short Address) の両方をサポートします。6LoWPANでの使用のため、本文書は、16ビット短アドレスの形式に対して（IEEE 802.15.4によって課されるもの以外の）追加の制約を課します（第12節を参照）。短アドレスは本質的に一時的なものであり、注意が必要です。PANコーディネーター機能によって関連付けイベント中に割り当てられるため、それらの有効性と一意性は、その関連付けの存続期間によって制限されます。これは、関連付けの有効期限またはPANコーディネーターで発生する予期しないイベントによって短縮される可能性があります。この集中型割り当てとPANコーディネーターの単一障害点によるスケーラビリティの問題のため、デプロイ担当者は、短アドレスに基づいてそのようなネットワークを拡張するためのトレードオフ（および必要なメカニズムの実装）を慎重に検討すべきです (SHOULD)。もちろん、IEEE 64ビット拡張アドレスはこれらの欠点の影響を受けない可能性がありますが、ルーティング、発見、構成などの残りのスケーラビリティ問題は依然として存在します。

本文書は、1つのPANが特定のIPv6リンクにマッピングされると想定しています。これは、共有ネットワークがリンク層サブネット [[RFC3819]] ブロードキャストをサポートするという推奨事項に準拠しています。厳密に言えば、IPv6には、ブロードキャストではなくマルチキャストが存在します。ただし、IEEE 802.15.4はマルチキャストをネイティブにサポートしていません。したがって、IPv6レベルのマルチキャストパケットは、IEEE 802.15.4ネットワーク内でリンク層ブロードキャストフレームとして伝送されなければなりません (MUST)。これは、ブロードキャストフレームが関連するリンクの特定のPAN内のデバイスによってのみ注目されるような方法で行われなければなりません (MUST)。[[ieee802.15.4]] のセクション7.5.6.2によれば、これは次の方法で達成されます。

  1. フレームには宛先PAN識別子が含まれ、これは関連するリンクのPAN IDと一致しなければなりません (MUST)。

  2. フレームには短い宛先アドレスが含まれ、これはブロードキャストアドレス (0xffff) と一致しなければなりません (MUST)。

さらに、第9節のIPv6マルチキャストアドレスマッピングサポートは、メッシュ構成でのみ使用されなければなりません (MUST)。そのような機能の完全な仕様は、本文書の範囲外です。

通常、ホストは [[RFC4861]] に従ってルーター広告を介してIPv6プレフィックスを学習します。

4. Maximum Transmission Unit (最大伝送単位)​

IEEE 802.15.4上のIPv6パケットの最大伝送単位 (Maximum Transmission Unit, MTU) サイズは1280オクテットです。ただし、完全なIPv6パケットは単一のIEEE 802.15.4フレームに収まりません。802.15.4プロトコルデータユニット (Protocol Data Unit, PDU) のサイズは、オーバーヘッド (Overhead) [[ieee802.15.4]] の存在により変動します。最大物理層パケットサイズ127オクテット (aMaxPHYPacketSize) と最大フレームオーバーヘッド25 (aMaxFrameOverhead) から始めると、メディアアクセス制御層 (MAC) の最大フレームサイズは102オクテットです。リンク層セキュリティはさらなるオーバーヘッドをもたらし、最悪の場合（AES-CCM-128の場合は21オクテットのオーバーヘッド、AES-CCM-32およびAES-CCM-64の場合はそれぞれ9および13）、利用可能なのは81オクテットのみです。これは明らかにIPv6パケットの最小サイズである1280オクテットをはるかに下回っており、IPv6仕様 [[RFC2460]] のセクション5によれば、IPの下層でフラグメンテーションと再構成の適応層 (Adaptation Layer) が提供されなければなりません (MUST)。そのような層は、以下の第5節で定義されています。

さらに、IPv6ヘッダーは40オクテットの長さであるため、上位層プロトコル（UDP など）には41オクテットしか残されません。後者はヘッダーに8オクテットを使用するため、アプリケーションデータには33オクテットしか残されません。さらに、上記のように、フラグメンテーションと再構成層が必要であり、これはさらにオクテットを使用します。

上記の考慮事項は、次の2つの観察につながります。

  1. IPv6の最小MTU要件に準拠するために、適応層が提供されなければなりません (MUST)。ただし、(a) ほとんどのIEEE 802.15.4アプリケーションはそのような大きなパケットを使用しないこと、および (b) 小さなアプリケーションペイロードと適切なヘッダー圧縮を組み合わせると、単一のIEEE 802.15.4フレームに収まるパケットが生成されることが予想されます。この適応層の理論的根拠は、IPv6仕様に準拠するためだけでなく、一部のアプリケーション交換（たとえば、構成またはプロビジョニング）が、少量のフラグメンテーションを必要とする可能性が非常に高いパケットサイズを生成するためでもあります。

  2. 上記の空間計算は最悪の場合を示していますが、ヘッダー圧縮がほぼ避けられない魅力を持っていることを示しています。ほとんど（すべてではないにしても）のIP over IEEE 802.15.4アプリケーションがヘッダー圧縮を使用すると予想されるため、以下の第10節で定義されています。

5. LoWPAN Adaptation Layer and Frame Format (LoWPAN適応層とフレーム形式)​

本節で定義されるカプセル化形式（以下「LoWPANカプセル化」と呼びます）は、IEEE 802.15.4 MACプロトコルデータユニット (Protocol Data Unit, PDU) 内のペイロードです。LoWPANペイロード（たとえば、IPv6パケット）は、このカプセル化ヘッダーの直後に続きます。

IEEE 802.15.4を介して伝送されるすべてのLoWPANカプセル化データグラム (Datagrams) には、カプセル化ヘッダースタック (Encapsulation Header Stack) がプレフィックスとして付けられます。ヘッダースタック内の各ヘッダーには、ヘッダータイプ (Header Type) が含まれ、その後にゼロ個以上のヘッダーフィールドが続きます。IPv6ヘッダーでは、スタックには次の順序で、アドレッシング (Addressing)、ホップバイホップオプション (Hop-by-Hop Options)、ルーティング (Routing)、フラグメンテーション (Fragmentation)、宛先オプション (Destination Options)、最後にペイロードが含まれます [[RFC2460]]。LoWPANヘッダーでは、同様のヘッダーシーケンスは、メッシュ (L2) アドレッシング、ホップバイホップオプション（L2ブロードキャスト/マルチキャストを含む）、フラグメンテーション、最後にペイロードです。

典型的なヘッダースタックの例:

LoWPANカプセル化されたIPv6データグラム:

+---------------+-------------+---------+
| IPv6 Dispatch | IPv6 Header | Payload |
+---------------+-------------+---------+

LoWPANカプセル化されたLOWPAN_HC1圧縮IPv6データグラム:

+--------------+------------+---------+
| HC1 Dispatch | HC1 Header | Payload |
+--------------+------------+---------+

メッシュアドレッシングが必要な場合:

+-----------+-------------+--------------+------------+---------+
| Mesh Type | Mesh Header | HC1 Dispatch | HC1 Header | Payload |
+-----------+-------------+--------------+------------+---------+

フラグメンテーションが必要な場合:

+-----------+-------------+--------------+------------+---------+
| Frag Type | Frag Header | HC1 Dispatch | HC1 Header | Payload |
+-----------+-------------+--------------+------------+---------+

メッシュアドレッシングとフラグメンテーションの両方が必要な場合:

+-------+-------+-------+-------+---------+---------+---------+
| M Typ | M Hdr | F Typ | F Hdr | HC1 Dsp | HC1 Hdr | Payload |
+-------+-------+-------+-------+---------+---------+---------+

同じパケットで複数のLoWPANヘッダーが使用される場合、それらは次の順序で出現しなければなりません (MUST): メッシュアドレッシングヘッダー、ブロードキャストヘッダー、フラグメンテーションヘッダー。

5.1. Dispatch Type and Header (ディスパッチタイプとヘッダー)​

ディスパッチタイプは、最初の2ビットが "01" で定義されます。ディスパッチタイプとヘッダーは次のとおりです:

 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|0 1| Dispatch  |  type-specific header
+-+-+-+-+-+-+-+-+
  • Dispatch: 6ビットセレクター。ディスパッチヘッダーの直後に続くヘッダータイプを識別します。
  • type-specific header: ディスパッチヘッダーによって決定されるヘッダー。

ディスパッチ値のビットパターン:

PatternHeader Type
00 xxxxxxNALP - LoWPANフレームではない
01 000001IPv6 - 未圧縮のIPv6アドレス
01 000010LOWPAN_HC1 - LOWPAN_HC1圧縮IPv6
01 000011reserved - 将来の使用のために予約
...reserved - 将来の使用のために予約
01 001111reserved - 将来の使用のために予約
01 010000LOWPAN_BC0 - LOWPAN_BC0ブロードキャスト
01 010001reserved - 将来の使用のために予約
...reserved - 将来の使用のために予約
01 111110reserved - 将来の使用のために予約
01 111111ESC - 追加のディスパッチバイトが続く
10 xxxxxxMESH - メッシュヘッダー
11 000xxxFRAG1 - フラグメンテーションヘッダー（最初）
11 001000reserved - 将来の使用のために予約
...reserved - 将来の使用のために予約
11 011111reserved - 将来の使用のために予約
11 100xxxFRAGN - フラグメンテーションヘッダー（後続）
11 101000reserved - 将来の使用のために予約
...reserved - 将来の使用のために予約
11 111111reserved - 将来の使用のために予約
  • NALP: 後続のビットがLoWPANカプセル化の一部ではないことを指定します。ディスパッチ値 00xxxxxx に遭遇したLoWPANノードは、そのパケットを破棄しなければなりません (SHALL)。
  • IPv6: 後続のヘッダーが未圧縮のIPv6ヘッダー [[RFC2460]] であることを指定します。
  • LOWPAN_HC1: 後続のヘッダーがLOWPAN_HC1圧縮IPv6ヘッダーであることを指定します。
  • LOWPAN_BC0: 後続のヘッダーがメッシュブロードキャスト/マルチキャストサポート用のLOWPAN_BC0ヘッダーであることを指定します。
  • ESC: 後続のヘッダーがディスパッチ値用の単一8ビットフィールドであることを指定します。127より大きいディスパッチ値をサポートできます。

5.2. Mesh Addressing Type and Header (メッシュアドレッシングタイプとヘッダー)​

メッシュタイプは、最初のビットが1、2番目のビットが0で定義されます。メッシュタイプとヘッダーは次のとおりです:

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0|V|F|HopsLft| originator address, final address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

フィールド定義:

  • V: この1ビットフィールドは、発信者 (Originator)（または「Very first」）アドレスがIEEE拡張64ビットアドレス (EUI-64) の場合は0、短い16ビットアドレスの場合は1でなければなりません (SHALL)。
  • F: この1ビットフィールドは、最終宛先アドレス (Final Destination Address) がIEEE拡張64ビットアドレス (EUI-64) の場合は0、短い16ビットアドレスの場合は1でなければなりません (SHALL)。
  • Hops Left (残りホップ数): この4ビットフィールドは、各転送ノードがこのパケットを次のホップに送信する前にデクリメントされなければなりません (SHALL)。残りホップ数が0にデクリメントされた場合、パケットはもう転送されません。値0xFは予約されており、直後に8ビット深度の残りホップ数フィールド (Deep Hops Left) があることを示し、送信元ノードが14ホップを超えるホップ制限を指定できるようにします。
  • Originator Address (発信者アドレス): これは発信者のリンク層アドレスです。
  • Final Destination Address (最終宛先アドレス): これは最終宛先のリンク層アドレスです。

注意: 'V' および 'F' ビットは、16ビットアドレスと64ビットアドレスの混合使用を許可します。これは少なくともメッシュ層「ブロードキャスト」を許可するのに有用です。802.15.4ブロードキャストアドレスは16ビット短アドレスとして定義されているためです。

メッシュネットワークでのフレーム配信に関するさらなる議論は、第11節にあります。

5.3. Fragmentation Type and Header (フラグメンテーションタイプとヘッダー)​

ペイロード全体（たとえば、IPv6）データグラムが単一の802.15.4フレームに収まる場合、フラグメント化されず、LoWPANカプセル化にはフラグメンテーションヘッダーを含めるべきではありません (SHOULD NOT)。データグラムが単一のIEEE 802.15.4フレームに収まらない場合、リンクフラグメント (Link Fragments) に分解されなければなりません (SHALL)。フラグメントオフセットは8オクテットの倍数のみを表すことができるため、データグラムのすべてのリンクフラグメント（最後のものを除く）は、8オクテット長の倍数でなければなりません (MUST)。最初のリンクフラグメントには、以下に定義する最初のフラグメンテーションヘッダーが含まれなければなりません (SHALL)。

最初のフラグメント:

 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          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2番目以降のリンクフラグメント（最後を含む）には、次の形式に準拠したフラグメンテーションヘッダーが含まれなければなりません (SHALL)。

後続のフラグメント:

 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|
+-+-+-+-+-+-+-+-+

フィールド定義:

  • datagram_size (データグラムサイズ): この11ビットフィールドは、リンク層フラグメンテーション前（ただしIP層フラグメンテーション後）のIPパケット全体のサイズをエンコードします。datagram_size の値は、IPパケットのすべてのリンク層フラグメントで同じでなければなりません (SHALL)。IPv6の場合、これはパケットのIPv6ヘッダー [[RFC2460]] のペイロード長 (Payload Length) 値より40オクテット多くなければなりません (SHALL)（未圧縮IPv6ヘッダーのサイズ）。

  • datagram_tag (データグラムタグ): datagram_tag の値は、ペイロード（たとえば、IPv6）データグラムのすべてのリンクフラグメントで同じでなければなりません (SHALL)。送信者は、連続するフラグメント化されたデータグラムに対して datagram_tag をインクリメントしなければなりません (SHALL)。datagram_tag のインクリメント値は、65535から0に折り返さなければなりません (SHALL)。このフィールドは16ビット長で、その初期値は未定義です。

  • datagram_offset (データグラムオフセット): このフィールドは2番目以降のリンクフラグメントにのみ存在し、ペイロードデータグラムの先頭に対するフラグメントのオフセットを8オクテット単位で指定しなければなりません (SHALL)。データグラムの最初のオクテット（たとえば、IPv6ヘッダーの開始）のオフセットは0です。最初のリンクフラグメントの datagram_offset の暗黙値は0です。このフィールドは8ビット長です。

リンクフラグメントの受信者は、(1) 送信者の802.15.4送信元アドレス（メッシュアドレッシングフィールドが存在する場合は発信者アドレス）、(2) 宛先の802.15.4アドレス（メッシュアドレッシングフィールドが存在する場合は最終宛先アドレス）、(3) datagram_size、および (4) datagram_tag を使用して、特定のデータグラムに属するすべてのリンクフラグメントを識別しなければなりません (SHALL)。

リンクフラグメントを受信すると、受信者は datagram_size のサイズの元の未フラグメント化パケットの構築を開始します。datagram_offset フィールドを使用して、元の未フラグメント化パケット内の個々のフラグメントの位置を決定します。たとえば、データペイロード（カプセル化ヘッダーを除く）をデータグラム再構成バッファの datagram_offset で指定された位置に配置できます。再構成バッファのサイズは datagram_size によって決定されなければなりません (SHALL)。

IEEE 802.15.4解除関連イベントが検出されると、フラグメント受信者は、部分的に再構成されたすべてのペイロードデータグラムのすべてのリンクフラグメントを破棄しなければならず (MUST)、フラグメント送信者は、まだ送信されていない部分的に送信されたペイロード（たとえば、IPv6）データグラムのすべてのリンクフラグメントを破棄しなければなりません (MUST)。同様に、ノードが特定の datagram_tag を持つフラグメントを最初に受信したとき、再構成タイマーを開始します。このタイマーが期限切れになったときに、パケット全体がまだ再構成されていない場合、既存のフラグメントを破棄しなければならず (MUST)、再構成状態をクリアしなければなりません (MUST)。再構成タイムアウトは最大60秒に設定しなければなりません (MUST)（これは、IPv6再構成プロセス [[RFC2460]] のタイムアウトでもあります）。

6. Stateless Address Autoconfiguration (ステートレスアドレス自動設定)​

本節では、IPv6インターフェース識別子 (Interface Identifier) を取得する方法を定義します。

IEEE 802.15.4インターフェースのインターフェース識別子 [[RFC4291]] は、IEEE 802.15.4デバイスに割り当てられたEUI-64識別子 [[EUI64]] に基づくことができます。この場合、インターフェース識別子は、「IPv6 over Ethernet」仕様 [[RFC2464]] に従ってEUI-64から形成されます。

すべての802.15.4デバイスにはIEEE EUI-64アドレスがありますが、16ビット短アドレスも存在する場合があります（第3節および第12節）。これらの場合、「疑似48ビットアドレス」は次のように形成されます。まず、左端の32ビットは、16個のゼロビットを16ビットPAN IDに連結することによって形成されます（または、PAN IDが不明な場合は、16個のゼロビットを使用できます）。これにより、次のような32ビットフィールドが生成されます:

16_bit_PAN:16_zero_bits

次に、この32ビットが16ビット短アドレスと連結されます。これにより、次のような48ビットアドレスが生成されます:

32_bits_as_specified_previously:16_bit_short_address

インターフェース識別子は、「IPv6 over Ethernet」仕様 [[RFC2464]] に従って、この48ビットアドレスから形成されます。ただし、結果のインターフェース識別子では、「ユニバーサル/ローカル」(U/L) ビットは0に設定されなければならず (SHALL)、これがグローバルに一意な値ではないという事実に準拠します。いずれのアドレス形式でも、全ゼロアドレスの使用は禁止されています (MUST NOT)。

インターフェース識別子を導出するために、異なるMACアドレスを手動で設定するか、ソフトウェアで設定できます。そのようなMACアドレスが使用される場合、そのグローバル一意性プロパティは、U/Lビットの値に反映されるべきです (SHOULD)。

IEEE 802.15.4インターフェースのステートレス自動設定 [[RFC4862]] に使用されるIPv6アドレスプレフィックスは、64ビットの長さを持たなければなりません (MUST)。

9. Multicast Address Mapping (マルチキャストアドレスマッピング)​

本節の機能は、メッシュネットワークをサポートするLoWPANでのみ使用されなければなりません (MUST)。マルチキャスト宛先アドレス (DST) を持つIPv6パケットは、DST[1]からDST[16]までの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]     |
                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

ここで、DST[15]*は、オクテットDST[15]の最後の5ビット、つまりDST[15]のビット3-7を指します。最初の3ビットパターン「100」は、マルチキャストアドレスの16ビットアドレス形式（第12節）に従います。

これにより、6LoWPANネットワークでマルチキャストをサポートできますが、そのようなサポートの完全な仕様は本文書の範囲外です。例示的なメカニズムには、フラッディング (Flooding)、制御されたフラッディング、PANコーディネーターへのユニキャストなどが含まれます。これは、さまざまなメッシュルーティングメカニズムによって指定されることが期待されます。

10. Header Compression (ヘッダー圧縮)​

ヘッダー圧縮に関しては、公開されている標準化作業と進行中の標準化作業が多数あります。しかし、IPv6 over IEEE 802.15.4のヘッダー圧縮には異なる制約があり、以下のように要約されます:

  • 既存の作業は、任意の2つのデバイス間に多数のフロー (Flows) が存在することを想定しています。ここでは、非常にシンプルで低コンテキスト (Low-Context) のヘッダー圧縮スタイルを想定します。これはフローとは独立して機能しますが（複数ある可能性があります）、特定のフローに固有のコンテキストは使用しません。したがって、圧縮する各フローに対して個別のコンテキストを構築するスキームが達成できるほどの圧縮を実現することはできません。

  • 非常に限られたパケットサイズを考えると、レイヤー2とレイヤー3の圧縮を統合することが非常に望ましいですが、これは従来行われていませんでした（ただし、現在はROHC (RObust Header Compression, ロバストヘッダー圧縮) ワーキンググループによって変化しています）。

  • IEEE 802.15.4デバイスはマルチホップネットワーク (Multi-Hop Networks) に展開されることが予想されます。ただし、メッシュネットワークにおけるヘッダー圧縮は、圧縮器と解凍器が互いに直接かつ排他的に通信する通常のポイントツーポイントリンクシナリオとは異なります。IEEE 802.15.4ネットワークでは、デバイスが最小限の事前コンテキスト構築で、任意の隣接ノードを介してヘッダー圧縮されたパケットを送信できることが非常に望ましいです。

ヘッダー圧縮に必要な新しいパケット形式は、第5節で定義された基本パケット形式を異なるディスパッチ値 (Dispatch Values) を使用して再利用します。

ヘッダー圧縮は、オクテット境界に整列しない可能性があります。ハードウェアは通常、オクテット未満の単位でデータを送信できないため、パディング (Padding) を使用する必要があります。パディングは次のように行われます: まず、連続する圧縮ヘッダーシーケンス全体をレイアウトします（本文書ではIPv6およびUDPヘッダー圧縮スキームのみを定義していますが、他のスキームは他の場所で定義できます）。次に、必要に応じてゼロビットを追加してオクテット境界に整列させます。これにより、ヘッダー圧縮によって生じる潜在的な不整合が相殺されるため、後続のフィールド（たとえば、非圧縮ヘッダーまたはデータペイロード）はオクテット境界から始まり、通常どおり続きます。

10.1. Encoding of IPv6 Header Fields (IPv6ヘッダーフィールドのエンコーディング)​

同じ6LoWPANネットワークに参加することにより、デバイスは何らかの状態を共有します。これにより、圧縮コンテキスト状態を明示的に構築することなくヘッダーを圧縮できます。したがって、6LoWPANヘッダー圧縮はフロー状態を保持しません。代わりに、リンク全体に関連する情報に依存します。以下のIPv6ヘッダー値は6LoWPANネットワーク上で一般的であると予想されるため、HC1ヘッダーは最初から効率的に圧縮するように構築されています:

  • Version (バージョン) はIPv6
  • IPv6送信元アドレスと宛先アドレスは両方ともリンクローカル (Link Local)
  • 送信元または宛先アドレスのIPv6インターフェース識別子（下位64ビット）は、レイヤー2の送信元アドレスと宛先アドレスから推測できます（もちろん、これは基礎となる802.15.4 MACアドレスから派生したインターフェース識別子にのみ可能です）
  • パケット長は、レイヤー2（IEEE 802.15.4 PPDUの「Frame Length」）またはフラグメンテーションヘッダーの「datagram_size」フィールド（存在する場合）から推測できます
  • Traffic ClassとFlow Labelは両方ともゼロ
  • Next HeaderはUDP、ICMP、またはTCP

IPv6ヘッダーで常に完全に伝送する必要がある唯一のフィールドは、Hop Limit（ホップ制限、8ビット）です。パケットがこの一般的なケースとどの程度一致するかに応じて、さまざまなフィールドが圧縮できない場合があり、したがって「インライン」(In-Line) で伝送する必要があります（第10.3.1節）。この一般的なIPv6ヘッダー（上記のとおり）は、40オクテットではなく2オクテット（HC1エンコーディングに1オクテット、Hop Limitに1オクテット）に圧縮できます。

このようなパケットは、LOWPAN_HC1形式で圧縮できます。LOWPAN_HC1のディスパッチ値を使用し、その後にLOWPAN_HC1ヘッダー「HC1エンコーディング」フィールド（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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | HC1 encoding  |     Non-Compressed fields follow...
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

「HC1エンコーディング」によってエンコードされるアドレスフィールドは次のように解釈されます:

  • PI: Prefix carried in-line (プレフィックスをインラインで伝送)
  • PC: Prefix compressed (プレフィックス圧縮、リンクローカルプレフィックスを想定)
  • II: Interface identifier carried in-line (インターフェース識別子をインラインで伝送)
  • IC: Interface identifier elided (インターフェース識別子省略、対応するリンク層アドレスから派生可能)

HC1エンコーディング（ビット0からビット7）:

IPv6送信元アドレス（ビット0および1）:

  • 00: PI, II
  • 01: PI, IC
  • 10: PC, II
  • 11: PC, IC

IPv6宛先アドレス（ビット2および3）:

  • 00: PI, II
  • 01: PI, IC
  • 10: PC, II
  • 11: PC, IC

Traffic ClassとFlow Label（ビット4）:

  • 0: 非圧縮; 完全な8ビットTraffic Classと20ビットFlow Labelを送信
  • 1: Traffic ClassとFlow Labelはゼロ

Next Header（ビット5および6）:

  • 00: 非圧縮; 完全な8ビットを送信
  • 01: UDP
  • 10: ICMP
  • 11: TCP

HC2エンコーディング（ビット7）:

  • 0: これ以上のヘッダー圧縮ビットはありません
  • 1: HC1エンコーディングの直後に、HC2エンコーディング形式に従ってさらにヘッダー圧縮ビットが続きます。ビット5および6が、どのHC2エンコーディング（たとえば、UDP、ICMP、またはTCPエンコーディング）が適用されるかを決定します。

10.2. Encoding of UDP Header Fields (UDPヘッダーフィールドのエンコーディング)​

LOWPAN_HC1のビット5および6により、IPv6ヘッダーのNext Headerフィールド（UDP、TCP、およびICMP用）を圧縮できます。これらのプロトコルヘッダーのそれぞれをさらに圧縮することも可能です。本節では、UDPヘッダー自体を圧縮する方法について説明します。本節のHC2エンコーディングはHC_UDPエンコーディングであり、HC1のビット5および6がIPv6ヘッダーの後に続くプロトコルがUDPであることを示す場合にのみ適用されます。

HC_UDPエンコーディングにより、UDPヘッダーの次のフィールドを圧縮できます: 送信元ポート (Source Port)、宛先ポート (Destination Port)、および長さ (Length)。UDPヘッダーのチェックサム (Checksum) フィールドは圧縮されないため、完全に伝送されます。以下に定義するスキームにより、UDPヘッダーを元の8オクテットではなく4オクテットに圧縮できます。

他の場所で利用可能な情報からその値を推測できる唯一のUDPヘッダーフィールドはLengthです。他のフィールドは、完全または部分圧縮形式でインラインで伝送する必要があります（第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...
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

UDPの「HC_UDPエンコーディング」（ビット0からビット7）:

UDP送信元ポート（ビット0）:

  • 0: 非圧縮、インラインで伝送
  • 1: 4ビットに圧縮。実際の16ビット送信元ポートは次の計算によって取得されます: P + short_port値。Pの値は数値61616（0xF0B0）です。short_portは4ビット値として表され、インラインで伝送されます

UDP宛先ポート（ビット1）:

  • 0: 非圧縮、インラインで伝送
  • 1: 4ビットに圧縮。実際の16ビット宛先ポートは次の計算によって取得されます: P + short_port値。Pの値は数値61616（0xF0B0）です。short_portは4ビット値として表され、インラインで伝送されます

Length（ビット2）:

  • 0: 非圧縮、インラインで伝送
  • 1: 圧縮、長さはIPv6ヘッダー長情報から計算されます。UDP長さフィールドの値は、IPv6ヘッダーのPayload Lengthから、IPv6ヘッダーとUDPヘッダーの間に存在する拡張ヘッダーの長さを引いた値に等しくなります

予約済み（ビット3からビット7）

10.3. Non-Compressed Fields (非圧縮フィールド)​

10.3.1. Non-Compressed IPv6 Fields (非圧縮IPv6フィールド)​

このスキームにより、IPv6ヘッダーをさまざまな程度に圧縮できます。したがって、完全な（標準的な）IPv6ヘッダーの代わりに、非圧縮フィールドのみを送信する必要があります。後続のヘッダー（元のIPv6ヘッダーのNext Headerフィールドによって指定）は、IPv6非圧縮フィールドの直後に続きます。

常に存在しなければならない (MUST) 非圧縮IPv6フィールドは、Hop Limit（8ビット）です。このフィールドは、常にエンコーディングフィールド（たとえば、図9に示されている「HC1エンコーディング」、将来の他のエンコーディングフィールドを含む可能性があります）の直後に続かなければなりません (MUST)。他の非圧縮フィールドは、「HC1エンコーディング」によって暗示される正確な順序でHop Limitの後に続かなければなりません (MUST)（第10.1節で示されているとおり）: 送信元アドレスプレフィックス（64ビット）および/またはインターフェース識別子（64ビット）、宛先アドレスプレフィックス（64ビット）および/またはインターフェース識別子（64ビット）、Traffic Class（8ビット）、Flow Label（20ビット）、およびNext Header（8ビット）。実際の次のヘッダー（たとえば、UDP、TCP、ICMPなど）は、非圧縮フィールドの後に続きます。

10.3.2. Non-Compressed and Partially Compressed UDP Fields (非圧縮および部分圧縮UDPフィールド)​

このスキームにより、UDPヘッダーをさまざまな程度に圧縮できます。したがって、完全な（標準的な）UDPヘッダーの代わりに、非圧縮または部分圧縮フィールドのみを送信する必要があります。

UDPヘッダーの非圧縮または部分圧縮フィールドは、常にIPv6ヘッダーとその関連するインラインフィールドの直後に続かなければなりません (MUST)。存在するUDPヘッダーインラインフィールドは、通常のUDPヘッダー [[RFC0768]] で対応するフィールドが出現するのと同じ順序で出現しなければなりません (MUST)。たとえば、送信元ポート、宛先ポート、長さ、チェックサムです。送信元ポートまたは宛先ポートが「short_port」表記（圧縮されたUDPヘッダーで示されているとおり）を採用している場合、インラインポート番号は16ビットではなく4ビットを占めます。

802.15.4ネットワークは通常メッシュルーティングを使用することが予想されますが、IEEE 802.15.4-2003仕様 [[ieee802.15.4]] はそのような機能を定義していません。この文脈では、フル機能デバイス (Full Function Device, FFD) がアドホックまたはメッシュルーティングプロトコルを実行して、ルーティングテーブルを設定します（本文書の範囲外）。このようなメッシュシナリオでは、2つのデバイスが通信するために直接到達可能である必要はありません。これらのデバイスでは、送信者は「発信者」(Originator) と呼ばれ、受信者は「最終宛先」(Final Destination) と呼ばれます。発信者デバイスは、他の中間デバイスを転送者として使用して、パケットを最終宛先に転送できます。ユニキャストを使用してこのようなフレーム配信を実現するには、ホップバイホップの送信元アドレスと宛先アドレスに加えて、発信者と最終宛先のリンク層アドレスを含める必要があります。

本節では、指定された目標「最終宛先」リンク層アドレスを持つメッシュネットワークでレイヤー2フレームの配信を実現する方法を定義します。

メッシュ配信は、他のLoWPANカプセル化ヘッダー（第5節）、非フラグメント化およびフラグメント化ヘッダー、完全なIPv6ヘッダー、または第10節または他の場所で定義されたその他の圧縮IPv6ヘッダーの前にメッシュアドレッシングヘッダーを含めることによって有効にされます。

ノードがデフォルトのメッシュ転送者を使用してパケットを送信したい場合（つまり、宛先に直接到達できないため）、発信者のリンク層アドレスを自分自身に設定し、最終宛先のリンク層アドレスをパケットの最終宛先に設定したメッシュアドレッシングヘッダーを含めなければなりません (MUST)。802.15.4ヘッダーの送信元アドレスを自分自身のリンク層アドレスに設定し、転送者のリンク層アドレスを802.15.4ヘッダーの宛先アドレスフィールドに配置します。最後に、パケットを送信します。

同様に、ノードがメッシュアドレッシングヘッダーを持つフレームを受信した場合、メッシュアドレッシングヘッダーの「最終宛先」フィールドを調べて真の宛先を判断しなければなりません (MUST)。ノード自体が最終宛先である場合、通常の送信としてパケットを消費します。最終宛先でない場合、デバイスは「残りホップ数」(Hops Left) フィールドをデクリメントし、結果がゼロであればパケットを破棄します。それ以外の場合、ノードはリンク層ルーティングテーブルに問い合わせて、最終宛先に到達するための次のホップを決定し、そのアドレスを802.15.4ヘッダーの宛先アドレスフィールドに配置します。最後に、ノードは802.15.4ヘッダーの送信元アドレスを自分自身のリンク層アドレスに変更し、パケットを送信します。

ノードがメッシュルーティングプロトコルに参加して転送者になる必要がありますが、メッシュ転送を使用するだけであればそのような要件はありません。「フル機能デバイス」(FFD) のみが、メッシュネットワークにルーターとして参加することが期待されます。「縮小機能デバイス」(RFD) は、FFDを発見し、IPホストが通常デフォルトルーターを使用してすべてのオフリンクトラフィックを転送するのと同様の方法で、すべての転送にFFDを使用することに自分自身を制限します。メッシュ送信を使用するRFDの場合、「転送者」は常に適切なFFDです。

11.1. LoWPAN Broadcast (LoWPANブロードキャスト)​

追加のメッシュルーティング機能は、メッシュヘッダーの直後に続くルーティングヘッダーを使用してエンコードされます。特に、ブロードキャストヘッダーは、LOWPAN_BC0ディスパッチとシーケンス番号フィールドで構成されます。シーケンス番号は、重複パケットを検出（および抑制することが望ましい）するために使用されます。

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|1|LOWPAN_BC0 |Sequence Number|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

フィールド定義:

  • Sequence Number (シーケンス番号): この8ビットフィールドは、発信者が新しいメッシュブロードキャストまたはマルチキャストパケットを送信するたびにインクリメントされなければなりません (SHALL)。このフィールドを処理する方法の完全な仕様は、本文書の範囲外です。

このようなメッシュ層ブロードキャストのさらなる意味、たとえば、それが制御されたフラッディングメカニズムにマッピングされるかどうか、またはトポロジー発見における役割などは、本文書の範囲外です。

ソースルーティングの指定など、追加のメッシュルーティング機能は、ヘッダースタック内のフラグメンテーションまたはアドレッシングヘッダーの前に配置される追加のルーティングヘッダーを定義することによって表現できます。そのようなメッシュルーティング機能の完全な仕様は、本文書の範囲外です。

12. IANA Considerations (IANAに関する考慮事項)​

本文書は、以下に説明する2つの新しいIANAレジストリを作成します。これらのレジストリでの将来の割り当ては、「Specification Required」[[RFC2434]] ポリシーに従ってIANAによって調整されます。このポリシーにより、他の（IETF以外の）組織が割り当てを取得しやすくなることが期待されます。

本文書は、第5節のヘッダー定義に示されているディスパッチタイプフィールドに対して新しいIANAレジストリを作成します。本文書は、IPv6、LOWPAN_HC1ヘッダー圧縮、BC0ブロードキャスト、および2つのエスケープモード（NALPはLoWPANフレームではないことを示し、ESCは追加のディスパッチバイトを許可します）の値を定義します。本文書は、このフィールドを8ビット長と定義します。値00xxxxxxは予約されており未使用であるため、合計192の異なる値が可能で、これで十分です。HC1以外のヘッダー圧縮形式が定義された場合、または追加のTCP、ICMP HC2形式が定義された場合、これらはLOWPAN_HC1の後の予約済みディスパッチ値を使用することが予想されます。追加のメッシュ送信形式が定義された場合、これらはLOWPAN_BC0の後の予約済み値を使用します。

本文書は、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      |
                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

このレジストリには、[[ieee802.15.4]] で定義されているアドレス0xffff（現在チャネルをリッスンしているすべてのデバイスが受け入れる16ビットブロードキャストアドレス）および0xfffeを含めなければなりません (MUST)。さらに、6LoWPANネットワークでは、16ビット短アドレスはこの形式（ビットフィールドは0から7の順序を示し、「x」は未指定のビット値のプレースホルダーです）に従わなければなりません (MUST):

  • 範囲1, 0xxxxxxxxxxxxxxx: 16ビットアドレスがユニキャストアドレスの場合、最初のビット（ビット0）はゼロでなければなりません (SHALL)。これにより、実際のアドレスに15ビットが残ります。

  • 範囲2, 100xxxxxxxxxxxxx: 16ビットアドレスがマルチキャストアドレス（第9節参照）の場合、ビット0、1、および2はこのパターンに従わなければなりません (SHALL)。これにより、実際のマルチキャストアドレスに13ビットが残ります。

  • 範囲3, 101xxxxxxxxxxxxx: ビット0、1、および2のこのパターンは予約されています。今後の割り当ては、上記のポリシーに従わなければなりません (SHALL)。

  • 範囲4, 110xxxxxxxxxxxxx: ビット0、1、および2のこのパターンは予約されています。今後の割り当ては、上記のポリシーに従わなければなりません (SHALL)。

  • 範囲5, 111xxxxxxxxxxxxx: ビット0、1、および2のこのパターンは予約されています。今後の割り当ては、上記のポリシーに従わなければなりません (SHALL)。

13. Security Considerations (セキュリティに関する考慮事項)​

EUI-64 MACアドレスからインターフェース識別子を導出する方法は、可能な限りグローバルに一意であることを維持することを目的としています。ただし、偶発的または偽造による重複を防ぐことはできません。

IEEE 802.15.4リンクにおける近隣探索 (Neighbor Discovery) は、[[RFC3756]] で詳述されている脅威に対して脆弱である可能性があります。メッシュルーティングはIEEE 802.15.4ネットワークで一般的であることが予想されます。これは、[[KW03]] のアドホックルーティングによる追加の脅威を意味します。IEEE 802.15.4は、いくつかのリンク層セキュリティ機能を提供します。ユーザーは、可能で実用的な場合は常に、これらの規定を利用することを強く推奨します。これにより、上記の脅威が軽減されます。

かなりの数のIEEE 802.15.4デバイスは、常にPAN内（つまり、IPv6用語ではリンク内）で通信することが予想されます。コストと電力消費の考慮事項に対応し、IEEE 802.15.4の「縮小機能デバイス」(RFD) モデルと一貫性を保つために、これらのデバイスは通常、最小限の機能セットを実装します。したがって、このようなデバイスのセキュリティは、IEEE 802.15.4がリンク層で定義するメカニズムに大きく依存する可能性があります。ただし、後者はIEEE 802.15.4フレームの認証または暗号化のための高度暗号化標準 (Advanced Encryption Standard, AES) モードのみを定義し、特に鍵管理（おそらくグループ指向）を指定していません。実際の展開で対処する必要がある他の問題は、セキュリティの構成と管理に関連しています。このような完全な全体像は本文書の範囲外ですが、IEEE 802.15.4ネットワークの展開では、これらの要因を考慮に入れなければなりません (MUST)。もちろん、一部のIEEE 802.15.4デバイス（いわゆる「フル機能デバイス」または「FFD」）は、コーディネーションまたは集約機能を実装することも予想されます。これらのデバイスは、オフリンクのIPv6ピアと定期的に通信する可能性があります（より一般的なオンリンク交換に加えて）。このようなIPv6デバイスは、エンドツーエンド通信を保護するために一般的なメカニズム（たとえば、IPsec、TLSなど）を使用することが予想されます。

14. Acknowledgements (謝辞)​

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にも感謝します。