IPv6パケット
IPv6パケットは、IPv6ネットワークのインターネットプロトコルによって交換される最小メッセージエンティティーである。
これらのパケットはアドレッシング、ルーティング、ユーザデータからなるペイロード、のための制御情報で構成されている。IPv6パケット内の制御情報は、必須の「固定ヘッダ」と任意の「拡張ヘッダ」に分かれる。IPv6パケットのペイロードは、通常はデータグラムもしくはより上位層のトランスポート層プロトコルのセグメントが入るが、インターネット層（ICMPv6など）やデータリンク層（OSPFなど）のデータであっても良い。
通常IPv6パケットはIPv4パケットと同じく下位層であるデータリンク層プロトコル（イーサネットなど）を介して送信される。ただし互換性の問題を解消するため、上位層のトンネリングプロトコルを介して送信されることもある（IPv6 over IPv4のようなIPv6移行技術を使用したIPv4パケットなど）。
IPv6では、ルーターはIPv6パケットを断片化（IPフラグメンテーションを参照）せず、送信元ノードのみが断片化を行う（IPv4ではヘッダ内のフラグによって禁止されていないパケットであれば、途中のルータでも断片化をすることがある）。送信元ノードがIPv6フラグメント拡張ヘッダと共に断片化したパケットを送信することにより、宛先ノードはそのパケットを再構築することができる[1]。最小MTUである1280オクテットよりも大きいMTUを利用するために、ホストは経路MTU探索を実行することを「強く推奨」されている[1]。
2017年7月から、IANAが様々なIPv6ヘッダで使用されるすべてのIPv6パラメータの登録者となっている。
固定ヘッダ
[編集]IPv6パケットの固定ヘッダは40オクテット（320ビット）の固定長で構成されている[1]。以下にヘッダフォーマットを示す。
固定ヘッダフォーマット オフセット オクテット 0 1 2 3 オクテット ビット 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 0 0 バージョン トラフィッククラス フローラベル 4 32 ペイロード長 次ヘッダ ホップ制限 8 64 送信元アドレス 12 96 16 128 20 160 24 192 宛先アドレス 28 224 32 256 36 288
- バージョン（4ビット）
- IPバージョン。6（二進数では0110）が必ず入る。
- トラフィッククラス（6+2ビット）
- このフィールドはQoSに関連する二つの値を持つ。上位6ビットはDiffServ(DS)フィールドで、パケットを分類するために使われる[2][3]。現在、すべての標準的なDSフィールドは「0」ビットで終わる。2連続の「1」ビットで終わるDSフィールドはローカル・実験的使用が予定されている[4]。
- 残りの下位2ビットは明示的輻輳通知(Explicit Congestion Notification, ECN)に使われる[5]。優先値は複数の範囲に細分される。送信元ノードが輻輳制御を提供するトラフィックと、輻輳制御なしのトラフィックである。
- フローラベル（20ビット）
- 元々はリアルタイムアプリケーションサービスを提供するために作られ[1]、QoSに近い目的を持ったフィールド。0ではない値を入れると、対応するルーターやスイッチは同じフローラベル・送信元アドレス・宛先アドレスを持つパケットを同じ経路で転送するため[6][7]、パケットが並べ替えられることを防ぐことができる。
- ペイロード長 （16ビット）
- オクテット単位で指定された、すべての拡張ヘッダを含むペイロードのサイズ。ただしホップバイホップ拡張ヘッダがジャンボペイロードオプションを持つときは0が入る[8]。
- 次ヘッダ（8ビット）
- 次ヘッダのタイプを指定する。拡張ヘッダが使われない場合、上位層であるトランスポート層プロトコルを指定する。このフィールドはIPv4のプロトコルフィールドと同じ機能を持つため、この値はIPv4のプロトコル番号と共有されている（詳細はプロトコル番号一覧）。
- ホップ制限（8ビット）
- IPv4のtime to live(TTL)とほぼ同等。この値はルーターを通過するたびに1ずつ減っていき、0になるとパケットは破棄される。ただし宛先ノードはホップ制限が0になっても通常通りパケットを処理する。
- 送信元アドレス（128ビット）
- 送信元ノードのIPv6アドレス。
- 宛先アドレス(128 bits)
- 宛先ノードのIPv6アドレス。
パフォーマンス向上のため、また現在のデータリンク層技術及びトランスポート層・アプリケーション層プロトコルは十分な誤り検出能力を持っていると見込んで[9]、このヘッダは誤り検出用のチェックサムを持たない。
拡張ヘッダ
[編集]拡張ヘッダは任意のインターネット層の情報を持ち、固定ヘッダと上位層プロトコルヘッダの間に位置する[1]。次ヘッダフィールドを使用しヘッダは数珠つなぎになっている。固定ヘッダの次ヘッダフィールドは最初の拡張ヘッダのタイプを示し、最後の拡張ヘッダの次ヘッダフィールドはペイロードに含まれる上位層プロトコルのタイプを示す。
全ての拡張ヘッダのサイズは8オクテットの倍数であり、いくつかの拡張ヘッダはこの条件を満たすためパディング（意味を持たないデータ）を含むことがある。
複数の拡張ヘッダが定義されていて[1]、将来さらに新しい拡張ヘッダが定義される可能性がある。パケットの経路上にあるすべての中間ノードが処理する必要のあるホップバイホップ拡張ヘッダを除き、拡張ヘッダは宛先ノードでしかチェック・処理されない。下に定義された拡張ヘッダは固定ヘッダに続く優先的な並びにリストされている。すべての拡張ヘッダは任意であり、かつ一回しか使われない（ただし2回使うことができる宛先オプションを除く）ことに注意されたし。
もしノードがある拡張ヘッダを認識できないときには、ノードはパケットを破棄しパラメーター異常(ICMPv6 type4, code1)メッセージを送信する[1]。固定ヘッダ以外のヘッダで次ヘッダの値が0のときも同様である。
拡張ヘッダ タイプ 説明 ホップバイホップオプション 0 経路上にあるすべてのデバイスでチェックされる必要のあるオプション。 宛先オプション（ルーティングヘッダの前） 60 パケットの宛先でしかチェックされる必要のないオプション。 ルーティング 43 データグラムの経路を指定するためのメソッド（Mobile IPv6で使われる）。 フラグメント 44 データグラムの断片化についての情報が含む。 認証ヘッダ(AH) 51 パケットのほとんどの部分の信ぴょう性を検証するために使われる情報を含む。 カプセル化セキュリティーペイロード(ESP) 50 安全な通信のための暗号化されたデータを持つ。 宛先オプション（上位層プロトコルヘッダの前） 60 パケットの宛先でしか検査される必要のないオプション。 Mobility（currently without upper-layer header） 135 Mobile IPv6で使用されるパラメーター。 Host Identity Protocol (HIP) 139 Host Identity Protocol version 2 (HIPv2)で使用される[10]。 Shim6 Protocol 140 Shim6で使用される。[11] 予約 253 実験とテストに使用される[12][4]。 予約 254 実験とテストに使用される[12][4]。
次ヘッダフィールドが59（次ヘッダなし）のとき、上位層プロトコルを含めそのヘッダに続くヘッダはないことを示す。つまりそのヘッダの視点からすると、ペイロードは含まれずIPv6パケットはそのすぐ後に終了するように見える[1]。しかしながら固定ヘッド内で指定されたペイロード長がパケット内のすべての拡張ヘッダの大きさよりも大きければ、データはペイロードとして含まれることができる。ホストはこのデータを無視するが、変更されないままルーターを通過することができる。
ホップバイホップオプションと宛先オプション
[編集]ホップバイホップオプション拡張ヘッダは送信元・宛先ノードを含む経路上にあるすべてのノードによってチェックされる必要がある。一方宛先オプション拡張ヘッダは宛先ノードのみによってチェックされる必要がある。これらの拡張ヘッダは最低でも8オクテットである必要がある。オプションがそれに収まりきらない場合、すべてのオプションが収まるまで8オクテットのブロック（オプションとパディングを含む）がヘッダに繰り返し追加される。
ホップバイホップオプションと宛先オプション拡張ヘッダフォーマット オフセット オクテット 0 1 2 3 オクテット ビット 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 0 0 次ヘッダ 拡張ヘッダ長 オプションとパディング 4 32 オプションとパディング 8 64 オプションとパディング（任意）... 12 96
- 次ヘッダ（8ビット）
- 次ヘッダのタイプを指定する。
- 拡張ヘッダ長（8ビット）
- 最初の8オクテットを含まない、8オクテット単位で表されたこのヘッダのサイズ。
- オプション（可変）
- 1つ以上のオプションと、オプションを整頓するため・ヘッダ長を8オクテットの倍数にするためのパディングを含む。オプションはTLVフォーマット。
ルーティング
[編集]ルーティング拡張ヘッダは、パケットが宛先ノードに到達する前に経由する必要がある中間ノードを1つ以上指定するために使われる。このヘッダは最低でも8オクテットである必要がある。もしタイプ指定データが4オクテットに収まりきらない場合、すべてのタイプ指定データが収まるまで8オクテットのブロックがヘッダに繰り返し追加される[1]。
ルーティング拡張ヘッダフォーマット オフセット オクテット 0 1 2 3 オクテット ビット 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 0 0 次ヘッダ 拡張ヘッダ長 ルーティングタイプ 残りセグメント 4 32 タイプ指定データ 8 64 タイプ指定データ（任意）... 12 96
- 次ヘッダ （8ビット）
- 次ヘッダのタイプを示す。
- 拡張ヘッダ長（8ビット）
- 最初の8オクテットを含まない、8オクテット単位で表されたこのヘッダのサイズ。
- ルーティングタイプ（8ビット）
- IANAによって割り当てられた0から255までの値[13]。
タイプ 状態 コメント 0 非推奨 ルーティングヘッダタイプ0はシンプルだが効果的[14]なDoS攻撃が行えるという事実から、このヘッダは2007年から非推奨であり[15]、ホストとルーターはこのヘッダを無視しなければいけない。 1 非推奨 DARPAによって立ち上げられたNimrod[16]プロジェクトに使われる。2009年から非推奨。 2 許可 タイプ0の制限バージョンで、Mobile IPv6（移動ノード(MN)のホームアドレス(HoA)を持つことができる）に使われる。 3 許可 低パワー・非可逆ネットワーク向けのRPLソースルートヘッダ[17]。 253 個人的使用 テスト用に使われ、実際の実装ではない。RFC3692-style Experiment 1[12] 254 個人的使用 テスト用に使われ、実際の実装ではない。RFC3692-style Experiment 2[12]
- 残りセグメント（8ビット）
- 宛先ノードに到達する前に経由しなければいけない残りのノード数。
- タイプ指定データ （可変）
- このタイプのルーティングヘッダに属するデータ。
フラグメント
[編集]経路MTUよりも大きいパケットを送信するとき、送信元ノードはパケットを断片化（フラグメント）する。フラグメント拡張ヘッダは元のパケットを再構築するために必要な情報を持つ[1]。
フラグメント拡張ヘッダフォーマット オフセット オクテット 0 1 2 3 オクテット ビット 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 0 0 次ヘッダ 予約 フラグメントオフセット 予約 M 4 32 識別値
- 次ヘッダ （8ビット）
- 次ヘッダのタイプを示す。
- 予約（8ビット/2ビット）
- 0に固定されている。
- フラグメントオフセット（13ビット）
- 元のパケットの断片化可能な部分の開始部に関連した、8オクテット単位のオフセット。
- Mフラグ（1ビット）
- 1はさらに断片が続くことを意味し、0はこれが最後の断片であることを意味する。
- 識別値（32ビット）
- 送信元ノードによって生成されるパケット識別番号。元のパケットの再構築に必要。
認証ヘッダ(AH)とカプセル化セキュリティーペイロード(ESP)
[編集]認証ヘッダ(AH)とカプセル化セキュリティ―ペイロード(ESP)はIPsecの一部で、IPv6でもIPv4と同様に使用される[18][19]。
ペイロード
[編集]固定もしくは任意のIPv6ヘッダの後にはTCPセグメントやUDPデータグラムなどのトランスポート層のデータが入ったペイロードが続く。最後のIPv6ヘッダの次ヘッダフィールドはそのパケットにどのタイプのペイロードが含まれているかを示す。
標準ペイロード長
[編集]IPv6のペイロード長フィールドは16ビットのサイズで、ペイロードのサイズを65,535オクテットまで指定することができる。パケットの断片化を防ぐため、ホストは経路MTU探索（送信元から宛先までのMTUを算出する）を行ってペイロード長を決める。ほとんどのデータリンク層プロトコルのMTUは65,535オクテットよりかなり小さい。
ジャンボグラム
[編集]IPv6のオプショナルな機能として、ホップバイホップ拡張ヘッダのジャンボペイロードオプション[8]を利用して約4GB(232−1 = 4,294,967,295オクテット)までのペイロードをもつIPv6パケットを送信できる。そのようなペイロードを持つパケットはジャンボグラムと呼ばれる。なお、一般的に使われるトランスポート層プロトコルであるTCPとUDPはどちらも16ビットまでしか表せないフィールド（データ長及び緊急ポインタ）を持つことに注意が必要である。
フラグメンテーション（断片化）
[編集]IPv4と違い、IPv6ルーターはIPv6パケットを断片化（フラグメント）しない。IPv4でフラグメント禁止ビットが設定されているときのように、宛先ノードとの接続でのMTUを超えるサイズのパケットは廃棄され、その状態がパケット過大(ICMPv6 type 2)メッセージとして送信元ノードに伝えられる[1]。
送信するパケットの最大サイズを定めるため、IPv6の端末ノードは経路MTU探索を行うことが求められていて、上位層プロトコルはそれに従ってペイロードサイズを制限することが求められている。しかし上位層プロトコルがそれを行うことができない場合、送信元ノードがフラグメント拡張ヘッダを使いIPv6パケットのエンドツーエンドでの断片化を行う。IPv6のデータを転送するすべてのデータリンク層は、IPv6フラグメンテーションを呼び出さずに1280バイトのIPパケットを配送する能力を持っていなければいけない。
断片化
[編集]元のパケットの断片（フラグメント）を含むパケットは2つの部分からなる。元のパケット断片化不能な部分（すべての断片において共通）、そしてフラグメントオフセットによって識別される元のパケットの断片化可能な部分である。最初の断片のフラグメントオフセットは0である[1]。
パケットの断片化不能な部分は元のパケットの固定ヘッダと（存在すれば）いくつかの拡張ヘッダで構成されている。「いくつかの拡張ヘッダ」とは、ルーティング拡張ヘッダまでのすべての拡張ヘッダ、もしくはホップバイホップ拡張ヘッダのことである。それらの拡張ヘッダがない場合、断片化不可能な部分は単に固定ヘッダのみである。
断片化不能な部分の最後のヘッダの次ヘッダフィールドは、フラグメント拡張ヘッダが続くことを示すため44がセットされる。フラグメント拡張ヘッダの後には、 元のパケットの残りの断片が続く。
最初の断片（たち）は（存在すれば）拡張ヘッダを保持し、その後残りのペイロードが続く。最後の断片を除き、それぞれの断片の長さは8オクテットの倍数である。
またフラグが0になっている最後のパケットを除き、すべてのフラグメント拡張ヘッダのMフラグは1（まだ断片が続くことを示す）になっている。
再構築
[編集]宛先ノードはすべての断片を集め、それらを正しいオフセットに配置し、パケットのフラグメント拡張ヘッダを廃棄することで元のパケットを再構築する。宛先ノードが正しく再配置するため、断片を含むパケットは順序正しく到達する必要がない。
もし断片を含む最初のパケットが到達してから60秒以内にすべての断片が到達しない場合、再構築は放棄されすべての断片は破棄される。この理由で再構築が放棄された場合、もし最初の断片（固定ヘッダを含む）が到達していたら、ICMPv6 type 3, code 1 時間切れ メッセージが断片化パケットを作成したノードに返される。
宛先ホストは再構築後に1500バイト以内となるような断片化したIPデータグラムはベストエフォートで再構築しなければならない。ホストは断片化したデータグラムを1500バイトより大きく再構築することが許可されているが、同時に再構築後のパケットが1500バイトを超えることが明らかになった時点ですべてのデータグラムを暗黙のうちに破棄することが許可されている。したがって宛先ノードがそのような大きいデータグラムを再構築できるという確証がない限り、送信元ノードは再構築後のサイズが1500バイトより大きくなるような断片化したIPデータグラムを送ることは避けるべきである。
セキュリティー
[編集]断片化はネットワークセキュリティー制御を逃れるために使うことができると調査が示している。その結果、今ではIPv6パケットの最初の断片がIPv6ヘッダチェーンすべてを含むことが要求されていて[20]、そのような異常なパケットの断片化は禁止されている。さらに、ルーターアドバータイズメント(RA)ガード回避の調査の結果[21]、断片化を近隣探索とともに使用することは非推奨となり、断片化をセキュア近隣探索(SEND)とともに使用することは推奨されなくなった[22]。
出典・脚注
[編集]- ^ a b c d e f g h i j k l Deering, S.; Hinden, R. (December 1998). Internet Protocol, version 6 (IPv6) Specification. IETF. RFC 2460.
- ^ K. Nickols; S. Blake; F. Baker; D. Black (December 1998). Definition of the Differentiated Service Field (DS Field) in the IPv4 and IPv6 Headers (英語). doi:10.17487/RFC2474. RFC 2474。
- ^ D. Grossman (April 2002). New Terminology and Clarifications for DiffServ (英語). doi:10.17487/RFC3260. RFC 3260。
- ^ a b c B. Fenner (November 2006). Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers (英語). Network Working Group. doi:10.17487/RFC4727. RFC 4727。
- ^ K. Ramakrishnan; S. Floyd; D. Black (September 2001). The Addition of Explicit Congestion Notification (ECN) to IP (英語). doi:10.17487/RFC3168. RFC 3168。
- ^ B. Wijnen (September 2003). Textual Conventions for IPv6 Flow Label (英語). doi:10.17487/RFC3595. RFC 3595。
- ^ S. Amante; B. Carpenter; S. Jiang; J. Rajahalme (November 2011). IPv6 Flow Label Specification (英語). doi:10.17487/RFC6437. RFC 6437。
- ^ a b D. Borman; S. Deering; R. Hinden (August 1999). IPv6 Jumbograms (英語). doi:10.17487/RFC2675. RFC 2675。
- ^ C. Partridge; F. Kastenholz (December 1994). Technical Criteria for Choosing IP The Next Generation (IPng) (英語). sec. 6.2. doi:10.17487/RFC1726. RFC 1726。
- ^ T. Heer; P. Jokela; T. Henderson (April 2015). R. Moskowitz (ed.). Host Identity Protocol Version 2 (HIPv2) (英語). Internet Engineering Task Force (IETF). doi:10.17487/RFC7401. ISSN 2070-1721. RFC 7401。
- ^ E. Nordmark; M. Bagnulo (June 2009). Shim6: Level 3 Multihoming Shim Protocol for IPv6 (英語). Networking Working Group. doi:10.17487/RFC5533. RFC 5533。
- ^ a b c d T. Narten (January 2004). Assigning Experimental and Testing Numbers Considered Useful (英語). Network Working Group. doi:10.17487/RFC3692. RFC 3692。 BCP 82. Updates RFC 2434.
- ^ “Internet Protocol Version 6 (IPv6) Parameters: Routing Types”. IANA. 2017年11月17日閲覧。
- ^ Philippe Biondi, Arnoud Ebalard (April 2007). “IPv6 Routing Header Security”. EADS. 3 December 2010閲覧。 “Type 0: the evil mechanism...”
- ^ J. Abley; P. Savola; G. Neville-Neil (December 2007). Deprecation of Type 0 Routing Headers in IPv6 (英語). doi:10.17487/RFC5095. RFC 5095。
- ^ I. Castineyra; N. Chiappa; M. Steenstrup (August 1996). The Nimrod Routing Architecture (英語). doi:10.17487/RFC1992. RFC 1992。
- ^ J. Hui; JP. Vasseur; D. Culler; V. Manral (March 2012). An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL) (英語). Internet Engineering Task Force (IETF). doi:10.17487/RFC6554. RFC 6554。
- ^ S. Kent (December 2005). IP Authentication Header (英語). doi:10.17487/RFC4302. RFC 4302。
- ^ S. Kent (December 2005). IP Encapsulating Security Payload (英語). doi:10.17487/RFC4302. RFC 4302。
- ^ F. Gont; V. Manral; R. Bonica (January 2014). Implications of Oversized IPv6 Header Chains (英語). doi:10.17487/RFC7112. RFC 7112。
- ^ F. Gont (February 2014). Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard) (英語). doi:10.17487/RFC7113. RFC 7113。
- ^ F. Gont (August 2013). Security Implications of IPv6 Fragmentation with IPv6 Neighbor Discovery (英語). doi:10.17487/RFC6980. RFC 6980。
| 一般 | |
|---|---|
| 経緯 |
|
| IPv4 to IPv6 トピックス | |
| 関連プロトコル |
|
 カテゴリ | |
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.
