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

4.3. UDP ヘッダー圧縮

このドキュメントでは、LOWPAN_NHC を使用して UDP ヘッダーの圧縮形式を定義します。UDP 圧縮形式を図 14 に示します。ビット 0 から 4 は NHC ID を表し、'11110' はこのセクションで定義されている特定の UDP ヘッダー圧縮エンコーディングを示します。

4.3.1. UDP ポートの圧縮​

この仕様では、特定の範囲のポート番号（0xf0b0 から 0xf0bf）を 4 ビットに圧縮できます。これは、新しいステートフル圧縮ではなく、[RFC4944] から継承されたステートレス圧縮です。

4 ビットに圧縮可能なポートの範囲は、予約された範囲内ではありません。6LoWPAN 経由で通信するように設計されたネットワークスタックの実装は、可能な限りそれらのポートを動的ポートとして使用することを避けるべきです。

これが 16 個の連続したポートのみを表すことを考慮すると、多くの互換性のないアプリケーションが独自のエンドツーエンドのニーズのために同じポート番号の値を使用することが予想されます。したがって、（0xf0b0 から 0xf0bf）の範囲のポート番号は、リモートエンドのアプリケーションに関する情報をほとんど提供しません。

0xf0bX ポートのオーバーロードは、IANA で予約されているポートと比較して、間違ったタイプのペイロードを取得し、コンテンツを誤って解釈するリスクを高めます。その結果、それらのポートの使用は、コンテンツが期待どおりであり、チェックされていることを確認するトランスポート層セキュリティ（TLS）[RFC5246] メッセージ完整性チェック（MIC）などのメカニズムに関連付けることが推奨されます。

4.3.2. UDP チェックサムの圧縮​

UDP チェックサム操作は、すべてのパケットに対して IPv6 [RFC2460] で必須です。そのため、[RFC4944] は UDP チェックサムの圧縮を許可していません。

この仕様では、送信元トランスポートエンドポイントの圧縮器は、上位層によって承認されている場合、UDP チェックサムを省略してもよい（MAY）。圧縮器は、そのような承認を受けない限り、C ビットを設定してはなりません（MUST NOT）。上位層の承認を要求することで、意図されたトランスポートピアが宛先に到達する前に発生するデータ破損に対処するための十分な手段を持つことが保証されます。上位層は、次のいずれかの場合が満たされない限り、承認を提供してはなりません（MUST NOT）：

トンネリング: この場合、6LoWPAN は、UDP 経由で既存のフィールドプロトコルをトンネリングすることにより、ワイヤレス擬似フィールドバスとして展開されます。トンネリングされたプロトコルデータユニット（PDU）が独自のアドレス指定、セキュリティ、および整合性チェック（たとえば、IPsec カプセル化セキュリティペイロードトンネルモード [RFC4303] または IP over UDP カプセル化）を持っている場合、トンネリングメカニズムは、カプセル化のオーバーヘッドを節約するために UDP チェックサムの省略を承認してもよい（MAY）。

メッセージ完整性チェック: この場合、UDP ペイロード内の IPsec 認証ヘッダー [RFC4302] またはその他の形式の整合性チェックが、少なくとも UDP チェックサムと同じ情報（疑似ヘッダー、データ）をカバーし、少なくとも同じ強度を持っています。

6LoWPAN パケットを展開するときに UDP チェックサムが適切に復元されるようにするために、チェックサムを省略した圧縮 UDP データグラムを運ぶリンクフレームを送信するときは常に、追加の整合性チェック（たとえば、レイヤー 2（L2）メッセージ完整性チェック）を使用しなければなりません（MUST）。この追加の整合性チェックがないと、疑似ヘッダーでカバーされるデータの破損が検出されない可能性があるため、UDP パケットが意図しない宛先に配信される可能性があります。

圧縮器は、省略される前に UDP チェックサムを検証しなければならず（MUST）、チェックサムを検証して省略する前に追加の整合性チェックが実施されていることを確認しなければなりません（MUST）。UDP チェックサムの検証に失敗した場合、圧縮器はパケットを破棄しなければなりません（MUST）。

C ビットが設定された 6LoWPAN パケットを展開する解凍器は、ソースノードに代わって UDP チェックサムを計算し、その値を既存の標準 [RFC0768]、[RFC2460] で指定されているように復元された UDP ヘッダーに配置しなければなりません（MUST）。解凍器は、追加の整合性チェックが圧縮器によって実施されたことを明確に判断し、整合性チェックを検証しなければならず（MUST）、UDP チェックサムを復元した後にそうすべきです（SHOULD）。解凍器が整合性チェックの存在を明確に判断できない場合、または検証に失敗した場合、解凍器はパケットを破棄しなければなりません（MUST）。

UDP チェックサムと追加の整合性チェックの計算と検証の推奨順序により、データがメモリ内で保護されずに保存されることがなくなります。実際には、レイヤー間の機能分離により、推奨される順序が排除される場合があります。ただし、実装者は、疑似ヘッダーでカバーされる保護されていないデータを扱う際のリスクに特に注意し、理解する必要があります。

中間ノードが UDP チェックサムを圧縮できるようにするために、転送ノードは、C ビットが設定されており、UDP チェックサムが省略されている間に UDP チェックサムと同じデータをカバーする整合性チェックが実施されていたことを明確に判断できる場合、着信パケットの上位層承認を推測してもよい（MAY）。転送ノードは、UDP チェックサムが省略されている間に整合性チェックの存在と検証を明確に判断できない場合、承認を推測してはなりません（MUST NOT）。

4.3.3. UDP LOWPAN_NHC 形式​

                    0   1   2   3   4   5   6   7
                  +---+---+---+---+---+---+---+---+
                  | 1 | 1 | 1 | 1 | 0 | C |   P   |
                  +---+---+---+---+---+---+---+---+

                   Figure 14: UDP Header Encoding

C: チェックサム:

  • 0: チェックサムの 16 ビットすべてがインラインで伝送されます。
  • 1: チェックサムの 16 ビットすべてが省略されます。チェックサムは、6LoWPAN 終端点で再計算することによって復元されます。

P: ポート:

  • 00: 送信元ポートと宛先ポートの両方の 16 ビットすべてがインラインで伝送されます。
  • 01: 送信元ポートの 16 ビットすべてがインラインで伝送されます。宛先ポートの最初の 8 ビットは 0xf0 で省略されます。宛先ポートの残りの 8 ビットはインラインで伝送されます。
  • 10: 送信元ポートの最初の 8 ビットは 0xf0 で省略されます。送信元ポートの残りの 8 ビットはインラインで伝送されます。宛先ポートの 16 ビットすべてがインラインで伝送されます。
  • 11: 送信元ポートと宛先ポートの両方の最初の 12 ビットは 0xf0b で省略されます。それぞれの残りの 4 ビットはインラインで伝送されます。

インラインで伝送されるフィールド（一部または全部）は、UDP ヘッダー形式 [RFC0768] で表示されるのと同じ順序で表示されます。UDP 長さフィールドは常に省略しなければならず（MUST）、6LoWPAN フラグメンテーションヘッダーまたは IEEE 802.15.4 ヘッダーを使用して下位層から推測されます。

に最終更新