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

7. サブヘッダーの圧縮 (Compression of subheaders)

7. サブヘッダーの圧縮 (Compression of subheaders)

本節では、IPv6 基本ヘッダー、IPv6 拡張ヘッダー、IPv4 ヘッダー、UDP ヘッダー、TCP ヘッダーの各フィールドが圧縮時にどのように処理されるかを説明します。各フィールドは以下のいずれかのカテゴリに分類されます。

  • NOCHANGE(変化なし):フィールドは圧縮ヘッダーで送信され、その値はコンテキスト内の値と同じであると推断されます。推断が誤っている場合は、完全ヘッダーまたはヘッダー更新を送信して修復する必要があります。
  • INFERRED(推断):フィールドの値は他の情報(リンク層フレームの長さなど)から推断できるため、ヘッダーでは送信されません。
  • DEF(定義フィールド):そのフィールドは「定義フィールド」(第 4.1 節参照)であり、その値はパケットストリームの識別に使用されます。定義フィールドは完全ヘッダーで送信され、コンテキスト(テンプレート)に保存されます。
  • SAME(同一):NOCHANGE と同様ですが、フィールドを構成するビットがすべて同じ場合にのみ成立します。
  • DELTA(差分):圧縮ヘッダーには、そのフィールドとコンテキスト値との差が格納されます。受信側はこの差分をコンテキストの値に加算してフィールドを再構成します。
  • RANDOM(乱数):フィールドは予測不可能であるため、圧縮ヘッダーにそのまま送信されます。

IPv6 基本ヘッダーと IPv6 拡張ヘッダーの各フィールドは、本章末尾の分類表(7.1、7.11、7.12、7.13 各節の表)に従って処理されます。

7.1 IPv6 ヘッダー (IPv6 Header)

IPv6 基本ヘッダーと IPv6 拡張ヘッダーの各フィールドは、付録 A の表に従って処理されます。表の列は以下の通りです。

フィールド (Field)

IPv6 ヘッダーまたは拡張ヘッダーのフィールド名。

サイズ (Size)

フィールドのサイズ(ビット単位)。

DEF

フィールドが定義フィールド(第 4.1 節参照)の場合は Yes とマーク。

Tmpl(テンプレート)

フィールドが完全ヘッダーで送信されコンテキスト(テンプレート)に保存される場合は Yes とマーク。

C(圧縮)

フィールドが圧縮ヘッダーで送信される場合は Yes とマーク。

Tmpl & C

フィールドが完全ヘッダーと圧縮ヘッダーの両方で送信される場合は Yes とマーク。このようなフィールドはコンテキストの一部にはなりません。

推断 (Inferred)

フィールドがリンク層フレームのサイズなど他の情報から推断できるかどうかを説明。

注記 (Notes)

フィールドに関する注記。

フィールドサイズDEFTmplCTmpl & C推断注記
Version4NoYesNoNoNo定数 (6)
Traffic Class8NoYesYesNoNo変化する可能性あり
Flow Label20YesYesNoNoNo定義フィールド
Payload Length16NoNoNoNoYesフレーム長から推断
Next Header8NoYesYesNoNo変化する可能性あり
Hop Limit8NoYesYesNoNo変化する可能性あり
Source Address128YesYesNoNoNo定義フィールド
Destination Address128YesYesNoNoNo定義フィールド

7.2 IPv6 拡張ヘッダー (IPv6 Extension Headers)

どの拡張ヘッダーが存在し、それらの相対順序は、パケットストリーム内で変化しないと想定されます。変化があった場合は、完全なパケットヘッダーを送信する必要があります。IPv6 基本ヘッダーおよびすべての IPv6 拡張ヘッダー内の Next Header フィールドはすべて NOCHANGE です。

7.3 オプション (Options)

Hop-by-Hop Options ヘッダーおよび Destination Options ヘッダーの内容は、TLV(型・長さ・値)「オプション」を用いて符号化されます([IPv6] 参照)。

            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| Option Type | Opt Data Len | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -

Option Type および Opt Data Len フィールドは、与えられたパケットストリームでは固定されていると仮定されるため、NOCHANGE に分類されます。Option Data は、以下に特記がない限り RANDOM です。

パディング (Padding)

  • Pad1 オプション
            +-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+

オプション全体が NOCHANGE です。

  • PadN オプション
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| 1 | Opt Data Len | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -

すべてのフィールドが NOCHANGE です。

7.4 Hop-by-Hop Options ヘッダー [IPv6, section 4.3]

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. .
. Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Next Header          NOCHANGE
Hdr Ext Len NOCHANGE

Options TLV 符号化された値およびパディング。
上記 7.3 に従って分類される。ただし、
以下の Jumbo Payload オプションを除く。

Jumbo Payload オプション

                                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type = 0xC2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opt Data Len = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Jumbo Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

先頭 2 フィールドは NOCHANGE、Jumbo Payload Length は INFERRED。

7.5 Routing ヘッダー [IPv6, section 4.4]

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. type-specific data(ルーティングタイプ依存データ).
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Routing Header のすべてのフィールドは NOCHANGE です。

Routing Type が認識されない場合、すべてのフィールドを決定できないため、Routing Header 全体が RANDOM に分類されます。

Type 0 Routing Header では、最後のアドレスは (Segments Left > 0) の場合に DEF です。

Routing Header は完全に圧縮されます。これはモバイル IP にとって大きな利益となります。

7.6 Fragment ヘッダー [IPv6, section 4.5]

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Reserved | Fragment Off. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fragment Offset | Res | M | Identification |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

パケットの最初のフラグメントでは Fragment Offset = 0 であり、フラグメント連鎖は圧縮点に到達する前に再順序付けされている可能性があります。パケットが再順序付けされる可能性があるため、最初のフラグメントの Fragment Header を調べて Identification フィールドを決定することはできません。したがって Fragment Header のフィールドは次のように分類されます。

   Next Header          NOCHANGE
Hdr Ext Len NOCHANGE(必ず 0)
Reserved NOCHANGE
Fragment Offset NOCHANGE(必ず 0)
M (More Fragments) NOCHANGE(必ず 0)
Identification RANDOM

この分類は、Fragment Header が Next Header と Hdr Ext Len(いずれも NOCHANGE)のみに圧縮され、残りは推断される(Fragment Offset と M は必ず 0、Identification は RANDOM)ことを意味します。

第 4.1 節の任意のガイドラインに従って、フラグメントをグループ化することができます。

7.7 Destination Options ヘッダー [IPv6, section 4.6]

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. .
. Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

[IPv6] で定義されている唯一の Destination Options はパディングオプションであり、その扱いは 7.3 のとおりです。

Destination Options Header 全体は「IPv6 拡張ヘッダーの規則」(7.2)に従って処理されます。

7.8 Authentication Header (AH) [RFC-1826]

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Payload Len | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number(シーケンス番号) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Authentication Data(可変長) |
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

AH ヘッダーのすべてのフィールドは NOCHANGE ですが、Authentication Data は RANDOM です。

これは、AH ヘッダーが圧縮された後も SPI とシーケンス番号(いずれも NOCHANGE かつ圧縮ヘッダーで送信)を保持し、Authentication Data は RANDOM フィールドとしてそのまま送信されることを意味します。

7.9 Encapsulating Security Payload (ESP) [RFC-1827]

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Security Parameters Index (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number(シーケンス番号) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Data(可変長) |
. .
. Integrity Check Value (ICV) .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

このヘッダーは、それ以降のパケット部分が暗号化されることを意味します。SPI とシーケンス番号は NOCHANGE(圧縮ヘッダーで送信)ですが、ESP トンネルモードでは IP パケット全体が暗号化されるため、圧縮点は ESP ヘッダーとそれ以降の暗号化データを区別できなければなりません。

これは、IP パケットとその ESP ヘッダーを圧縮器に渡すことができるが、ESP 以降の暗号化データは圧縮されないことを意味します。

SPI 以降のすべては暗号化されているため、圧縮されません。

7.10 拡張ヘッダーの順序 (Order of Extension Headers)

IPv6 拡張ヘッダーは [IPv6] で規定された順序で現れなければなりません。圧縮器が期待される順序外の拡張ヘッダーに遭遇した場合、完全ヘッダーを送信しなければなりません。

7.11 UDP ヘッダー (UDP Header)

UDP ヘッダーの各フィールドは付録 A の表に従って処理されます。

フィールドサイズDEFTmplCTmpl & C推断注記
Source Port16YesYesNoNoNo定義フィールド
Destination Port16YesYesNoNoNo定義フィールド
Length16NoNoNoNoYesフレーム長から推断
Checksum16NoNoYesNoNoランダムに変化

UDP チェックサムは圧縮前に計算すべきです。これにより、圧縮器が UDP ペイロードまたは UDP ヘッダーのビットエラーを検出できます。チェックサムは診断とエラー検出に使用されます。リンク層が強力なエラー検出を提供しない場合、解凍後に配送される UDP パケットにエラーが含まれる可能性があります。リンク層がヘッダー圧縮モジュールに破損したパケットを渡した可能性があるためです。この場合、UDP チェックサムがこれらのエラーを捕捉します。UDP チェックサムがゼロ(すなわち使用されていない)の場合でも、圧縮ヘッダーに含まれますが、ゼロ値に最適化されるためオーバーヘッドは発生しません。

7.12 TCP ヘッダー (TCP Header)

TCP ヘッダーの圧縮は [RFC-1144] に従います。ただし、本文書で定義される TCP 圧縮ヘッダーフォーマットは [RFC-1144] のフォーマットと異なります。相違点は以下の通りです。

  • 圧縮された TCP ヘッダーの前に CID が送信されます。これにより、複数の TCP 接続を単一リンク上で多重化できます。

  • 圧縮ヘッダーに接続番号フィールドは使用されません。代わりに CID が使用されます。

  • ウィンドウフィールドは変化した場合、前の値との差としてではなく常にそのまま送信されます。これにより損失からの回復が簡略化されます。

  • TCP チェックサムを送信しない特殊ケースのエンコーディングは実行されません。代わりに、チェックサムは常にそのまま送信されます。

  • [RFC-1144] の非圧縮モードはサポートされません。圧縮器が TCP パケットを圧縮しないと決定した場合、通常の IPv4 または IPv6 パケットとして送信されます。

TCP ヘッダーの各フィールドは付録 A の表に従って処理されます。

TCP チェックサムは UDP と同じ理由(第 8 節参照)で圧縮前に計算すべきです。

第 10 節では TCP フローの損失回復を加速する 2 つのメカニズムを説明します。

フィールドサイズDEFTmplCTmpl & C推断注記
Source Port16YesYesNoNoNo定義フィールド
Destination Port16YesYesNoNoNo定義フィールド
Sequence Number32NoYesYesNoNo差分符号化
Acknowledgment Number32NoYesYesNoNo差分符号化
Data Offset4NoYesYesNoNoオプション変化時に変化
Reserved4NoYesNoNoNo通常はゼロ
Flags8NoYesYesNoNo変化する可能性あり
Window16NoYesYesNoNoそのまま送信
Checksum16NoNoYesNoNoそのまま送信
Urgent Pointer16NoYesYesNoNoほとんど使用されない
OptionsvarNoYesYesNoNoほとんど変化しない

7.13 IPv4 ヘッダー (IPv4 Header)

IPv4 ヘッダーの形式は次のとおりです。

     0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
フィールドサイズDEFTmplCTmpl & C推断注記
Version4NoYesNoNoNo定数 (4)
IHL4NoYesNoNoNo通常は定数 (5)
Type of Service8NoYesYesNoNo変化する可能性あり
Total Length16NoNoNoNoYesフレーム長から推断
Identification16NoNoYesNoNoランダムに変化
Flags3NoYesYesNoNo変化する可能性あり
Fragment Offset13NoYesYesNoNoフラグメント時に変化
Time to Live8NoYesYesNoNo変化する可能性あり
Protocol8YesYesNoNoNo定義フィールド
Header Checksum16NoNoYesNoNo各ホップで再計算
Source Address32YesYesNoNoNo定義フィールド
Destination Address32YesYesNoNoNo定義フィールド
OptionsvarNoYesYesNoNoほとんど使用されない

IPv4 ヘッダを圧縮する方法は 2 つあります。

a) IPv4 ヘッダがフラグメントのものでなく (MF フラグが設定されておらず, Fragment Offset がゼロ), かつオプションが存在しない (IHL が 5) 場合, 次のように分類されます。

       Version              NOCHANGE   (DEF)
IHL NOCHANGE (DEF, must be 5)
Type of Service NOCHANGE (might be DEF, see sect 4.1)
(see also 6 a)
Total Length INFERRED (from link-layer implementation
or encapsulating IP header)

Identification DELTA/ (If the Protocol field has the
(value corresponding to TCP)
RANDOM (otherwise)

Flags NOCHANGE (MF flag must not be set)
Fragment Offset NOCHANGE (must be zero)
Time to Live NOCHANGE (might be DEF, see sect 4.1)
Protocol NOCHANGE
Header Checksum INFERRED (calculated from other fields)
Source Address NOCHANGE (DEF)
Destination Address NOCHANGE (DEF)
Options, Padding (not present)

注記: TCP ヘッダが直後に続く場合, IPv4 ヘッダと TCP ヘッダは第 6 節に記載のとおり 1 つの単位として圧縮されなければなりません (MUST). その場合, Type of Service フィールドのビット 6 および 7 (最初のワードのビット 14 および 15) は R-flag を用いて渡すことができます (第 6 a 節を参照).

b) IPv4 ヘッダがフラグメントのものである (MF ビットが設定されている, または Fragment Offset がゼロでない) 場合, もしくはオプションが存在する (IHL > 5) 場合, すべてのフィールドは RANDOM となります (すなわち, ヘッダを圧縮する場合でも全フィールドはそのまま送信され圧縮されません). この分類により, フラグメントがトンネリングされる際にトンネルヘッダの圧縮は可能ですが, フラグメントヘッダの圧縮はできません. IPv4 ヘッダがフラグメントのものである場合, それは圧縮可能なサブヘッダ連鎖を終端します. つまり, 圧縮される最後のサブヘッダでなければなりません. IPv4 ヘッダがオプションを持つがフラグメントのものでない場合, 圧縮可能なサブヘッダ連鎖を終端しないため, 後続のサブヘッダも圧縮できます.

第 4.1 節の任意のガイドラインに従う圧縮器は, 場合 a) において Version, Source Address, Destination Address に加えて, IPv4 オプションが存在しないこと, およびこれがフラグメントでないことを用いてパケットストリームを定義します.

場合 b) では, IPv4 ヘッダがフラグメントのものであるかどうかに応じて 2 種類のパケットストリームを定義できます.

場合 b) の IPv4 ヘッダがフラグメントのものである場合, 任意のガイドラインに従う圧縮器はその事実を Version, Source Address, Destination Address と併せて用い, パケットストリームを判別します.

場合 b) の IPv4 ヘッダがフラグメントのものでない場合, それはオプションを持っているはずです. 任意のガイドラインに従う圧縮器はその事実を (ただしオプションのサイズは用いずに) Version, Source Address, Destination Address と併せて用い, パケットストリームを判別します.

7.14 Minimal Encapsulation ヘッダー [RFC-2004, section 3.1]

     0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol |S| reserved | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: (if present) Original Source Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Protocol                             NOCHANGE
Original Source Address Present (S) NOCHANGE
reserved NOCHANGE
Header Checksum INFERRED(他の値から計算)
Original Destination Address NOCHANGE
Original Source Address NOCHANGE(S=1 の場合のみ存在)

このヘッダーはモバイル IP で使用される可能性が高いです。