IPv6パケット

IPv6パケットは、IPv6ネットワークのインターネットプロトコルによって交換される最小メッセージエンティティーである。

これらのパケットはアドレッシング、ルーティング、ユーザデータからなるペイロード、のための制御情報で構成されている。IPv6パケット内の制御情報は、必須の「固定ヘッダ」と任意の「拡張ヘッダ」に分かれる。IPv6パケットのペイロードは、通常はデータグラムもしくはより上位層のトランスポート層プロトコルのセグメントが入るが、インターネット層やデータリンク層のデータであっても良い。

通常IPv6パケットはIPv4パケットと同じく下位層であるデータリンク層プロトコルを介して送信される。ただし互換性の問題を解消するため、上位層のトンネリングプロトコルを介して送信されることもある。

IPv6では、ルーターはIPv6パケットを断片化せず、送信元ノードのみが断片化を行う。送信元ノードがIPv6フラグメント拡張ヘッダと共に断片化したパケットを送信することにより、宛先ノードはそのパケットを再構築することができる。最小MTUである1280オクテットよりも大きいMTUを利用するために、ホストは経路MTU探索を実行することを「強く推奨」されている。

2017年7月から、IANAが様々なIPv6ヘッダで使用されるすべてのIPv6パラメータの登録者となっている。

1. 固定ヘッダ
--------

IPv6パケットの固定ヘッダは40オクテットの固定長で構成されている。以下にヘッダフォーマットを示す。

{| class="wikitable" style="text-align: center"|+固定ヘッダフォーマット |- ! style="border-bottom:none; border-right:none;" |//オフセット// ! style="border-left:none;" |オクテット ! colspan="8" | 0 ! colspan="8" | 1 ! colspan="8" | 2 ! colspan="8" | 3 |- ! style="border-top: none" |オクテット !ビット ! style="width:2.6%;" | 0 ! style="width:2.6%;" | 1 ! style="width:2.6%;" | 2 ! style="width:2.6%;" | 3 ! style="width:2.6%;" | 4 ! style="width:2.6%;" | 5 ! style="width:2.6%;" | 6 ! style="width:2.6%;" | 7 ! style="width:2.6%;" | 8 ! style="width:2.6%;" | 9 ! style="width:2.6%;" | 10 ! style="width:2.6%;" | 11 ! style="width:2.6%;" | 12 ! style="width:2.6%;" | 13 ! style="width:2.6%;" | 14 ! style="width:2.6%;" | 15 ! style="width:2.6%;" | 16 ! style="width:2.6%;" | 17 ! style="width:2.6%;" | 18 ! style="width:2.6%;" | 19 ! style="width:2.6%;" | 20 ! style="width:2.6%;" | 21 ! style="width:2.6%;" | 22 ! style="width:2.6%;" | 23 ! style="width:2.6%;" | 24 ! style="width:2.6%;" | 25 ! style="width:2.6%;" | 26 !
style="width:2.6%;" | 27 ! style="width:2.6%;" | 28 ! style="width:2.6%;" | 29 ! style="width:2.6%;" | 30 ! style="width:2.6%;" | 31 |- ! 0 ! 0 | colspan="4" |//バージョン// | colspan="8" |//トラフィッククラス// | colspan="20" |//フローラベル// |- ! 4 ! 32 | colspan="16" |//ペイロード長// | colspan="8" |//次ヘッダ// | colspan="8" |//ホップ制限// |- ! 8 ! 64 | colspan="32" rowspan="4" |//送信元アドレス// |- ! 12 ! 96 |- ! 16 ! 128 |- ! 20 ! 160 |- ! 24 ! 192 | colspan="32" rowspan="4" |//宛先アドレス// |- ! 28 ! 224 |- ! 32 ! 256 |- ! 36 ! 288 |}

//バージョン//:IPバージョン。6が必ず入る。 //トラフィッククラス//:このフィールドはQoSに関連する二つの値を持つ。上位6ビットはDiffServフィールドで、パケットを分類するために使われる。現在、すべての標準的なDSフィールドは「0」ビットで終わる。2連続の「1」ビットで終わるDSフィールドはローカル・実験的使用が予定されている。 残りの下位2ビットは明示的輻輳通知に使われる。優先値は複数の範囲に細分される。送信元ノードが輻輳制御を提供するトラフィックと、輻輳制御なしのトラフィックである。 //フローラベル//:元々はリアルタイムアプリケーションサービスを提供するために作られ、QoSに近い目的を持ったフィールド。0ではない値を入れると、対応するルーターやスイッチは同じフローラベル・送信元アドレス・宛先アドレスを持つパケットを同じ経路で転送するため、パケットが並べ替えられることを防ぐことができる。 //ペイロード長// :オクテット単位で指定された、すべての拡張ヘッダを含むペイロードのサイズ。ただしホップバイホップ拡張ヘッダがジャンボペイロードオプションを持つときは0が入る。 //次ヘッダ//:次ヘッダのタイプを指定する。拡張ヘッダが使われない場合、上位層であるトランスポート層プロトコルを指定する。このフィールドはIPv4のプロトコルフィールドと同じ機能を持つため、この値はIPv4のプロトコル番号と共有されている。 //ホップ制限//:IPv4のtime to liveとほぼ同等。この値はルーターを通過するたびに1ずつ減っていき、0になるとパケットは破棄される。ただし宛先ノードはホップ制限が0になっても通常通りパケットを処理する。 //送信元アドレス//:送信元ノードのIPv6アドレス。 //宛先アドレス//:宛先ノードのIPv6アドレス。パフォーマンス向上のため、また現在のデータリンク層技術及びトランスポート層・アプリケーション層プロトコルは十分な誤り検出能力を持っていると見込んで、このヘッダは誤り検出用のチェックサムを持たない。

2. 拡張ヘッダ
--------

拡張ヘッダは任意のインターネット層の情報を持ち、固定ヘッダと上位層プロトコルヘッダの間に位置する。次ヘッダフィールドを使用しヘッダは数珠つなぎになっている。固定ヘッダの次ヘッダフィールドは最初の拡張ヘッダのタイプを示し、最後の拡張ヘッダの次ヘッダフィールドはペイロードに含まれる上位層プロトコルのタイプを示す。

全ての拡張ヘッダのサイズは8オクテットの倍数であり、いくつかの拡張ヘッダはこの条件を満たすためパディングを含むことがある。

複数の拡張ヘッダが定義されていて、将来さらに新しい拡張ヘッダが定義される可能性がある。パケットの経路上にあるすべての中間ノードが処理する必要のあるホップバイホップ拡張ヘッダを除き、拡張ヘッダは宛先ノードでしかチェック・処理されない。下に定義された拡張ヘッダは固定ヘッダに続く優先的な並びにリストされている。すべての拡張ヘッダは任意であり、かつ一回しか使われないことに注意されたし。

もしノードがある拡張ヘッダを認識できないときには、ノードはパケットを破棄しパラメーター異常メッセージを送信する。固定ヘッダ以外のヘッダで次ヘッダの値が0のときも同様である。

{| class="wikitable" |- ! 拡張ヘッダ !タイプ ! 説明 |- | //ホップバイホップオプション// | | 0 || 経路上にあるすべてのデバイスでチェックされる必要のあるオプション。 |- | //宛先オプション// | | 60 || パケットの宛先でしかチェックされる必要のないオプション。 |- | //ルーティング// | | 43 || データグラムの経路を指定するためのメソッド。 |- | //フラグメント// | | 44 || データグラムの断片化についての情報が含む。 |- | //認証ヘッダ// | | 51 || パケットのほとんどの部分の信ぴょう性を検証するために使われる情報を含む。 |- | //カプセル化セキュリティーペイロード// | | 50 || 安全な通信のための暗号化されたデータを持つ。 |- |//宛先オプション// | | 60 || パケットの宛先でしか検査される必要のないオプション。 |- | Mobility | | 135 ||Mobile IPv6で使用されるパラメーター。 |- | Host Identity Protocol  || 139 ||Host Identity Protocol version 2 で使用される。 |- | Shim6 Protocol || 140 ||Shim6で使用される。 |- | 予約 || 253 || 実験とテストに使用される。 |- | 予約 || 254 || 実験とテストに使用される。 |}

次ヘッダフィールドが59のとき、上位層プロトコルを含めそのヘッダに続くヘッダはないことを示す。つまりそのヘッダの視点からすると、ペイロードは含まれずIPv6パケットはそのすぐ後に終了するように見える。しかしながら固定ヘッド内で指定されたペイロード長がパケット内のすべての拡張ヘッダの大きさよりも大きければ、データはペイロードとして含まれることができる。ホストはこのデータを無視するが、変更されないままルーターを通過することができる。

2.1. ホップバイホップオプションと宛先オプション
--------------------------

ホップバイホップオプション拡張ヘッダは送信元・宛先ノードを含む経路上にあるすべてのノードによってチェックされる必要がある。一方宛先オプション拡張ヘッダは宛先ノードのみによってチェックされる必要がある。これらの拡張ヘッダは最低でも8オクテットである必要がある。オプションがそれに収まりきらない場合、すべてのオプションが収まるまで8オクテットのブロックがヘッダに繰り返し追加される。

{| class="wikitable" style="text-align: center"|+//ホップバイホップオプションと宛先オプション拡張ヘッダフォーマット// |- ! style="border-bottom:none; border-right:none;"| //オフセット// ! style="border-left:none;"| オクテット ! colspan="8" | 0 ! colspan="8" | 1 ! colspan="8" | 2 ! colspan="8" | 3 |- ! style="border-top: none" | オクテット ! ビット ! style="width:2.6%;"| 0 ! style="width:2.6%;"| 1 ! style="width:2.6%;"| 2 ! style="width:2.6%;"| 3 ! style="width:2.6%;"| 4 ! style="width:2.6%;"| 5 ! style="width:2.6%;"| 6 ! style="width:2.6%;"| 7 ! style="width:2.6%;"| 8 ! style="width:2.6%;"| 9 ! style="width:2.6%;"| 10 ! style="width:2.6%;"| 11 ! style="width:2.6%;"| 12 ! style="width:2.6%;"| 13 ! style="width:2.6%;"| 14 ! style="width:2.6%;"| 15 ! style="width:2.6%;"| 16 ! style="width:2.6%;"| 17 ! style="width:2.6%;"| 18 ! style="width:2.6%;"| 19 ! style="width:2.6%;"| 20 ! style="width:2.6%;"| 21 ! style="width:2.6%;"| 22 ! style="width:2.6%;"| 23 ! style="width:2.6%;"| 24 ! style="width:2.6%;"| 25 ! style="width:2.6%;"| 26 !
style="width:2.6%;"| 27 ! style="width:2.6%;"| 28 ! style="width:2.6%;"| 29 ! style="width:2.6%;"| 30 ! style="width:2.6%;"| 31 |- ! 0 ! 0 | colspan="8"|次ヘッダ | colspan="8"|//拡張ヘッダ長// | colspan="16"|//オプションとパディング// |- ! 4 ! 32 | colspan="32"|//オプションとパディング// |- ! 8 ! 64 | colspan="32" rowspan=2|オプションとパディング... |- ! 12 ! 96 |}

//次ヘッダ//:次ヘッダのタイプを指定する。 //拡張ヘッダ長//:最初の8オクテットを含まない、8オクテット単位で表されたこのヘッダのサイズ。 //オプション//:1つ以上のオプションと、オプションを整頓するため・ヘッダ長を8オクテットの倍数にするためのパディングを含む。オプションはTLVフォーマット。

2.2. ルーティング
-----------

ルーティング拡張ヘッダは、パケットが宛先ノードに到達する前に経由する必要がある中間ノードを1つ以上指定するために使われる。このヘッダは最低でも8オクテットである必要がある。もしタイプ指定データが4オクテットに収まりきらない場合、すべてのタイプ指定データが収まるまで8オクテットのブロックがヘッダに繰り返し追加される。

{| class="wikitable" style="text-align: center"|+//ルーティング拡張ヘッダフォーマット// |- ! style="border-bottom:none; border-right:none;"| //オフセット// ! style="border-left:none;"| オクテット ! colspan="8" | 0 ! colspan="8" | 1 ! colspan="8" | 2 ! colspan="8" | 3 |- ! style="border-top: none" | オクテット ! ビット ! style="width:2.6%;"| 0 ! style="width:2.6%;"| 1 ! style="width:2.6%;"| 2 ! style="width:2.6%;"| 3 ! style="width:2.6%;"| 4 ! style="width:2.6%;"| 5 ! style="width:2.6%;"| 6 ! style="width:2.6%;"| 7 ! style="width:2.6%;"| 8 ! style="width:2.6%;"| 9 ! style="width:2.6%;"| 10 ! style="width:2.6%;"| 11 ! style="width:2.6%;"| 12 ! style="width:2.6%;"| 13 ! style="width:2.6%;"| 14 ! style="width:2.6%;"| 15 ! style="width:2.6%;"| 16 ! style="width:2.6%;"| 17 ! style="width:2.6%;"| 18 ! style="width:2.6%;"| 19 ! style="width:2.6%;"| 20 ! style="width:2.6%;"| 21 ! style="width:2.6%;"| 22 ! style="width:2.6%;"| 23 ! style="width:2.6%;"| 24 ! style="width:2.6%;"| 25 ! style="width:2.6%;"| 26 ! style="width:2.6%;"|
27 ! style="width:2.6%;"| 28 ! style="width:2.6%;"| 29 ! style="width:2.6%;"| 30 ! style="width:2.6%;"| 31 |- ! 0 ! 0 | colspan="8"|//次ヘッダ// | colspan="8"|//拡張ヘッダ長// | colspan="8"|//ルーティングタイプ// | colspan="8"|//残りセグメント// |- ! 4 ! 32 | colspan="32"|//タイプ指定データ// |- ! 8 ! 64 | colspan="32" rowspan="2"|タイプ指定データ... |- ! 12 ! 96 |}

//次ヘッダ// :次ヘッダのタイプを示す。 //拡張ヘッダ長//:最初の8オクテットを含まない、8オクテット単位で表されたこのヘッダのサイズ。 //ルーティングタイプ//:IANAによって割り当てられた0から255までの値。{| class="wikitable" style="text-align: left"!| タイプ !| 状態 ! style='width=500px' | コメント |- | 0 | 非推奨 | ルーティングヘッダタイプ0はシンプルだが効果的なDoS攻撃が行えるという事実から、このヘッダは2007年から非推奨であり、ホストとルーターはこのヘッダを無視しなければいけない。 |- | 1 | 非推奨 |DARPAによって立ち上げられたNimrodプロジェクトに使われる。2009年から非推奨。 |- | 2 | 許可 | タイプ0の制限バージョンで、Mobile IPv6に使われる。 |- | 3 | 許可 | 低パワー・非可逆ネットワーク向けのRPLソースルートヘッダ。 |- | 253 || 個人的使用 | テスト用に使われ、実際の実装ではない。//RFC3692-style Experiment 1// |- | 254 || 個人的使用 | テスト用に使われ、実際の実装ではない。//RFC3692-style Experiment 2// |}

//残りセグメント//:宛先ノードに到達する前に経由しなければいけない残りのノード数。 //タイプ指定データ// :このタイプのルーティングヘッダに属するデータ。

2.3. フラグメント
-----------

経路MTUよりも大きいパケットを送信するとき、送信元ノードはパケットを断片化する。フラグメント拡張ヘッダは元のパケットを再構築するために必要な情報を持つ。

{| class="wikitable" style="text-align: center"|+フラグメント拡張ヘッダフォーマット |- ! style="border-bottom:none; border-right:none;"| //オフセット// ! style="border-left:none;"| オクテット ! colspan="8" | 0 ! colspan="8" | 1 ! colspan="8" | 2 ! colspan="8" | 3 |- ! style="border-top: none" | オクテット ! ビット ! style="width:2.6%;"| 0 ! style="width:2.6%;"| 1 ! style="width:2.6%;"| 2 ! style="width:2.6%;"| 3 ! style="width:2.6%;"| 4 ! style="width:2.6%;"| 5 ! style="width:2.6%;"| 6 ! style="width:2.6%;"| 7 ! style="width:2.6%;"| 8 ! style="width:2.6%;"| 9 ! style="width:2.6%;"| 10 ! style="width:2.6%;"| 11 ! style="width:2.6%;"| 12 ! style="width:2.6%;"| 13 ! style="width:2.6%;"| 14 ! style="width:2.6%;"| 15 ! style="width:2.6%;"| 16 ! style="width:2.6%;"| 17 ! style="width:2.6%;"| 18 ! style="width:2.6%;"| 19 ! style="width:2.6%;"| 20 ! style="width:2.6%;"| 21 ! style="width:2.6%;"| 22 ! style="width:2.6%;"| 23 ! style="width:2.6%;"| 24 ! style="width:2.6%;"| 25 ! style="width:2.6%;"| 26 ! style="width:2.6%;"| 27
! style="width:2.6%;"| 28 ! style="width:2.6%;"| 29 ! style="width:2.6%;"| 30 ! style="width:2.6%;"| 31 |- ! 0 ! 0 | colspan="8"|//次ヘッダ// | colspan="8"|//予約// | colspan="13"|//フラグメントオフセット// | colspan="2"|//予約// | colspan="1"|//M// |- ! 4 ! 32 | colspan="32"|//識別値// |}

//次ヘッダ// :次ヘッダのタイプを示す。 //予約//:0に固定されている。 //フラグメントオフセット//:元のパケットの断片化可能な部分の開始部に関連した、8オクテット単位のオフセット。 //Mフラグ//:1はさらに断片が続くことを意味し、0はこれが最後の断片であることを意味する。 //識別//値:送信元ノードによって生成されるパケット識別番号。元のパケットの再構築に必要。

2.4. 認証ヘッダとカプセル化セキュリティーペイロード
-------------------------------------

//認証ヘッダとカプセル化セキュリティ―ペイロード//はIPsecの一部で、IPv6でもIPv4と同様に使用される。

3. ペイロード
--------

固定もしくは任意のIPv6ヘッダの後にはTCPセグメントやUDPデータグラムなどのトランスポート層のデータが入ったペイロードが続く。最後のIPv6ヘッダの次ヘッダフィールドはそのパケットにどのタイプのペイロードが含まれているかを示す。

3.1. 標準ペイロード長
-------------

IPv6のペイロード長フィールドは16ビットのサイズで、ペイロードのサイズを65,535オクテットまで指定することができる。パケットの断片化を防ぐため、ホストは経路MTU探索を行ってペイロード長を決める。ほとんどのデータリンク層プロトコルのMTUは65,535オクテットよりかなり小さい。

3.2. ジャンボグラム
------------

IPv6のオプショナルな機能として、ホップバイホップ拡張ヘッダのジャンボペイロードオプションを利用して約4GBまでのペイロードをもつIPv6パケットを送信できる。そのようなペイロードを持つパケットはジャンボグラムと呼ばれる。なお、一般的に使われるトランスポート層プロトコルであるTCPとUDPはどちらも16ビットまでしか表せないフィールドを持つことに注意が必要である。

4. フラグメンテーション
-------------

IPv4と違い、IPv6ルーターはIPv6パケットを断片化しない。IPv4でフラグメント禁止ビットが設定されているときのように、宛先ノードとの接続でのMTUを超えるサイズのパケットは廃棄され、その状態がパケット過大メッセージとして送信元ノードに伝えられる。

送信するパケットの最大サイズを定めるため、IPv6の端末ノードは経路MTU探索を行うことが求められていて、上位層プロトコルはそれに従ってペイロードサイズを制限することが求められている。しかし上位層プロトコルがそれを行うことができない場合、送信元ノードがフラグメント拡張ヘッダを使いIPv6パケットのエンドツーエンドでの断片化を行う。IPv6のデータを転送するすべてのデータリンク層は、IPv6フラグメンテーションを呼び出さずに1280バイトのIPパケットを配送する能力を持っていなければいけない。

4.1. 断片化
--------

元のパケットの断片を含むパケットは2つの部分からなる。元のパケット断片化不能な部分、そしてフラグメントオフセットによって識別される元のパケットの断片化可能な部分である。最初の断片のフラグメントオフセットは0である。

パケットの断片化不能な部分は元のパケットの固定ヘッダといくつかの拡張ヘッダで構成されている。「いくつかの拡張ヘッダ」とは、ルーティング拡張ヘッダまでのすべての拡張ヘッダ、もしくはホップバイホップ拡張ヘッダのことである。それらの拡張ヘッダがない場合、断片化不可能な部分は単に固定ヘッダのみである。

断片化不能な部分の最後のヘッダの次ヘッダフィールドは、フラグメント拡張ヘッダが続くことを示すため44がセットされる。フラグメント拡張ヘッダの後には、 元のパケットの残りの断片が続く。

最初の断片は拡張ヘッダを保持し、その後残りのペイロードが続く。最後の断片を除き、それぞれの断片の長さは8オクテットの倍数である。

またフラグが0になっている最後のパケットを除き、すべてのフラグメント拡張ヘッダのMフラグは1になっている。

4.2. 再構築
--------

宛先ノードはすべての断片を集め、それらを正しいオフセットに配置し、パケットのフラグメント拡張ヘッダを廃棄することで元のパケットを再構築する。宛先ノードが正しく再配置するため、断片を含むパケットは順序正しく到達する必要がない。

もし断片を含む最初のパケットが到達してから60秒以内にすべての断片が到達しない場合、再構築は放棄されすべての断片は破棄される。この理由で再構築が放棄された場合、もし最初の断片が到達していたら、ICMPv6 type 3, code 1 時間切れ メッセージが断片化パケットを作成したノードに返される。

宛先ホストは再構築後に1500バイト以内となるような断片化したIPデータグラムはベストエフォートで再構築しなければならない。ホストは断片化したデータグラムを1500バイトより大きく再構築することが許可されているが、同時に再構築後のパケットが1500バイトを超えることが明らかになった時点ですべてのデータグラムを暗黙のうちに破棄することが許可されている。したがって宛先ノードがそのような大きいデータグラムを再構築できるという確証がない限り、送信元ノードは再構築後のサイズが1500バイトより大きくなるような断片化したIPデータグラムを送ることは避けるべきである。

4.3. セキュリティー
------------

断片化はネットワークセキュリティー制御を逃れるために使うことができると調査が示している。その結果、今ではIPv6パケットの最初の断片がIPv6ヘッダチェーンすべてを含むことが要求されていて、そのような異常なパケットの断片化は禁止されている。さらに、ルーターアドバータイズメントガード回避の調査の結果、断片化を近隣探索とともに使用することは非推奨となり、断片化をセキュア近隣探索とともに使用することは推奨されなくなった。

5. 出典・脚注
--------