IPヘッダとは？構造と役割を徹底解説

インターネットの仕組みを理解する上で、IP（Internet Protocol）は最も基盤となる技術の一つです。そして、そのIPがデータをどのように運び、どこへ届けるかを制御するための「封筒」とも言える情報が、IPヘッダです。本記事では、IPヘッダの構造、各フィールドの意味、そしてネットワークにおけるその重要な役割について、IPv4とIPv6の両方を詳細にわたって解説します。

この記事を読むことで、IPヘッダが単なるデータの飾りではなく、インターネット上のパケット通信を可能にするための不可欠な要素であることが理解できるでしょう。ネットワークエンジニアを目指す方、ネットワークの深い仕組みを知りたい方にとって、必読の内容となっています。

1. はじめに：インターネットとIPヘッダの重要性

インターネットは、世界中のコンピュータネットワークを相互に接続した巨大なネットワークです。このネットワーク上で、コンピュータ間でデータをやり取りするためには、共通のルールが必要です。そのルールの一つが、プロトコルです。

データ通信は、OSI参照モデルやTCP/IPモデルといった階層的な構造で捉えられます。IP（Internet Protocol）は、これらのモデルにおいて、データの「パケット」をネットワーク上で転送する役割を担うプロトコルであり、主にネットワーク層（OSI参照モデルの第3層）に位置します。

IPは、送信元から送信先まで、ネットワークを介してデータを配送する責任を持ちますが、その配送は「コネクションレス型」で行われます。これは、事前に通信経路を確立するのではなく、個々のパケットが独立して最適な経路を選びながら配送される方式です。郵便システムに例えるなら、電話のように事前に回線を繋ぐのではなく、手紙の宛先を見てポストに投函し、郵便局がその都度最適なルートで配送するイメージです。

このIPパケットを配送するために不可欠な情報が、IPヘッダに含まれています。IPヘッダは、配送に必要な制御情報（宛先、送信元、データの種類、サイズなど）を格納しており、データ本体（ペイロード）の前に付加されます。ちょうど、手紙を封筒に入れる際に、封筒の表面に宛先、送信元、切手などの配送に必要な情報を記載するのに似ています。

IPヘッダがなければ、IPパケットはどこから来てどこへ行くべきか、どのようなデータを含んでいるのか、ルーターやコンピュータは判断できません。つまり、インターネット上の通信は成り立たないのです。IPヘッダは、インターネットの基盤を支える「縁の下の力持ち」と言えるでしょう。

本記事では、この重要なIPヘッダについて、以下の点を掘り下げて解説します。

IPヘッダの基本的な役割
IPv4ヘッダの詳細な構造と各フィールドの意味
IPv6ヘッダの構造とIPv4からの変更点、および拡張ヘッダ
ネットワーク機器（特にルーター）によるIPヘッダの処理
IPv4とIPv6のヘッダ構造の比較

2. IPヘッダの基本的な役割

IPヘッダは、IPパケットがネットワーク上を正確かつ効率的に配送されるために、主に以下の役割を担います。

アドレッシング（宛先・送信元の指定）: IPアドレスを使用して、パケットの最終的な送信元と送信先を識別します。これは、インターネット上の無数のデバイスの中から特定のデバイスを特定するために最も重要な情報です。
ルーティング（経路選択）: パケットが次にどこへ転送されるべきかを、ルーターが判断するための情報を提供します。宛先IPアドレスに基づいて、ルーターは自身の持つ経路情報（ルーティングテーブル）を参照し、最適な出力インターフェースを決定します。
データの識別: パケットに含まれるデータが、TCP、UDP、ICMPなど、どのトランスポート層プロトコルや上位層プロトコルのデータであるかを示します。これにより、受信側のホストはパケットを受信した後、そのデータをどのプロトコルスタックに渡せば良いかを判断できます。
パケットの管理: パケットのサイズ、断片化（フラグメンテーション）に関する情報、有効期限などを管理します。これにより、ネットワークの最大転送単位（MTU）に合わせたパケットの分割・再構築や、ネットワーク内を無限にループするパケットの排除などが可能になります。
品質管理（QoS）: パケットの優先度やサービスレベルに関する情報を含めることで、ネットワーク上で特定種類のトラフィックに優先的な扱いを施す（Quality of Service – QoS）ための手がかりを提供します。

これらの役割を果たすために、IPヘッダには様々なフィールドが含まれています。次章では、まず現在も広く利用されているIPv4のヘッダ構造を詳しく見ていきましょう。

3. IPv4ヘッダの構造と各フィールドの詳細

IPv4（Internet Protocol version 4）は、インターネットの黎明期から利用されているIPのバージョンです。IPv4ヘッダは、通常20オクテット（バイト）の固定長部分と、オプションを含む可変長部分から構成されます。最小ヘッダ長は20オクテット、最大ヘッダ長は60オクテットです。

IPv4ヘッダは、32ビット幅のフィールドを並べた形で表現されることが一般的です。以下にその構造を図示し、各フィールドを詳細に解説します。

0 8 16 24 31 +-----------------------------------------------+ | Version | IHL | DSCP | ECN | Total Length| +-----------------------------------------------+ | Identification | +-----------------------------------------------+ | Flags | Fragment Offset | +-----------------------------------------------+ | Time to Live (TTL) | Protocol | Header Checksum | +-----------------------------------------------+ | Source IP Address | +-----------------------------------------------+ | Destination IP Address | +-----------------------------------------------+ | Options (if IHL > 5) | +-----------------------------------------------+ | Padding (if Options is used) | +-----------------------------------------------+ | Data (Payload) | +-----------------------------------------------+

各フィールドの意味は以下の通りです。

Version (バージョン)
- サイズ: 4ビット
- 役割: IPプロトコルのバージョンを示します。IPv4の場合、値は「4」（0100）になります。受信側は、このフィールドを見てパケットがIPv4なのかIPv6なのかなどを判断し、ヘッダの解釈方法を切り替えます。
IHL (Internet Header Length – ヘッダ長)
- サイズ: 4ビット
- 役割: IPヘッダの長さを示します。この値は、32ビットワード（4オクテット）単位で表現されます。最小値は5（オプションがない場合）、最大値は15です。
- 計算: 実際のヘッダ長（オクテット単位）は、「IHLの値 × 4オクテット」で計算されます。
  - 例: IHL = 5 の場合、ヘッダ長は 5 × 4 = 20オクテット（最小ヘッダ長）。
  - 例: IHL = 15 の場合、ヘッダ長は 15 × 4 = 60オクテット（最大ヘッダ長）。
- IHLフィールドが存在するのは、IPv4ヘッダがオプションフィールドを含むことで可変長になるためです。受信側はIHLを見て、ヘッダがどこまで続き、その後にペイロードが始まるかを判断します。
DSCP (Differentiated Services Code Point – 差分サービスコードポイント) および ECN (Explicit Congestion Notification – 明示的輻輳通知)
- サイズ: DSCP 6ビット, ECN 2ビット (合計 8ビット, 旧ToSフィールド)
- 役割: パケットのサービスタイプや優先度、ネットワークの状態（輻輳）に関する情報を示します。
  - DSCP (6ビット): ネットワーク上でパケットにどのようなサービスレベルを適用するかを指定するために使用されます。例えば、VoIP（音声通話）のようなリアルタイム性が求められるトラフィックには高い優先度を割り当てたり、ファイル転送のような優先度が低いトラフィックには帯域制限を設けたりといった制御に利用されます。特定のDSCP値は、特定の「Per-Hop Behavior (PHB)」と呼ばれるネットワーク機器での振る舞い（転送遅延、パケット損失率、帯域幅など）に関連付けられます。
  - ECN (2ビット): ネットワークの輻輳状態を送信側と受信側に通知するために使用されます。これにより、エンドホストがパケット損失を経験する前に、積極的に輻輳を回避するアクション（例: TCPのウィンドウサイズを小さくする）を取ることが可能になります。ECN対応のエンドホストとネットワーク機器の間で利用されます。
- この8ビットフィールドは、以前は「ToS (Type of Service)」フィールドと呼ばれていましたが、現在はDSCPとECNに再定義されています。
Total Length (全長)
- サイズ: 16ビット
- 役割: IPヘッダとIPペイロード（データ）を含めたIPパケット全体の長さを示します。オクテット（バイト）単位です。
- 最大値: 2^16 – 1 = 65,535 オクテット (約64KB)。IPパケットの最大サイズは65,535オクテットです。
- このフィールドにより、受信側はパケット全体のサイズを知ることができ、不完全なパケットや不正なサイズのパケットを検出できます。また、フラグメント（断片）を受信した際には、元の完全なパケットのサイズを推測する手がかりにもなります。
Identification (識別)
- サイズ: 16ビット
- 役割: オリジナルのIPパケットがフラグメント化された場合に、同じ元のパケットに属するすべてのフラグメントが同じ識別値を持つようにします。これにより、受信側ホストは、複数のフラグメントがどの元のパケットに属しているかを判断し、正しく再構築することができます。同じ送信元、送信先、プロトコルを持つパケットであっても、異なるIdentification値を持つことで区別されます。
Flags (フラグ)
- サイズ: 3ビット
- 役割: IPパケットのフラグメントに関する制御情報を示します。
- ビットの割り当て:
  - ビット0: 予約済み（常に0）
  - ビット1: DF (Don’t Fragment) フラグ。このフラグが1の場合、ルーターはこのパケットをフラグメント化してはいけないことを示します。もしパケットがMTUを超えるサイズで、フラグメント化が必要なのにDFフラグが立っている場合、ルーターはパケットを破棄し、送信元にICMPのエラーメッセージ（Destination Unreachable – Fragmentation Needed）を送信します。
  - ビット2: MF (More Fragments) フラグ。このフラグが1の場合、これは最後のフラグメントではないことを示し、このパケットの後にもまだ元のパケットのフラグメントが続くことを意味します。最後のフラグメントの場合、MFフラグは0になります。MFフラグとFragment Offsetフィールドは連携して、フラグメントの順序と完全性を管理します。
Fragment Offset (フラグメントオフセット)
- サイズ: 13ビット
- 役割: フラグメント化されたパケットにおいて、このフラグメントが元の非フラグメント化パケットのデータ部分の先頭からどれだけ離れた位置にあるかを示します。単位は8オクテット（64ビット）ワードです。
- オフセットが0の場合、それは元のパケットの最初のフラグメント（またはフラグメント化されていないパケット自身）であることを示します。例えば、オフセットが100の場合、そのフラグメントのデータは元のパケットの先頭から 100 × 8 = 800オクテット目から始まることを意味します。
- このフィールドとIdentification、Flagsフィールドを組み合わせることで、受信側ホストはバラバラに届いたフラグメントを正しい順序で並べ直し、元のパケットを再構築することができます。
Time to Live (TTL – 生存時間)
- サイズ: 8ビット
- 役割: パケットがネットワーク上を転送できる最大ホップ数（ルーターを通過できる回数）を示します。送信元のホストが初期値を設定し、パケットがルーターを通過するたびに、ルーターはこの値を1ずつ減らします。
- TTLの値が0になったパケットを受信したルーターは、そのパケットを破棄します。
- 目的: TTLの主な目的は、ネットワーク内のルーティングループによってパケットが無限に転送され続けるのを防ぐことです。TTLが0になることで、パケットは最終的に破棄され、ネットワーク資源の枯渇を防ぎます。
- パケットが破棄された場合、多くのルーターは送信元に対してICMPのエラーメッセージ（Time Exceeded）を送信します。tracerouteコマンドはこのTTLの仕組みを利用して、送信元から宛先までの経路上のルーター（ホップ）を特定します。
Protocol (プロトコル)
- サイズ: 8ビット
- 役割: IPヘッダの直後に続く上位層プロトコル（IPペイロードのタイプ）を示します。受信側ホストは、このフィールドの値を見て、パケットのペイロードをどのプロトコルスタック（TCP、UDP、ICMPなど）に引き渡せば良いかを判断します。
- よく使われるプロトコル番号の例:
  - 1: ICMP (Internet Control Message Protocol)
  - 6: TCP (Transmission Control Protocol)
  - 17: UDP (User Datagram Protocol)
  - 89: OSPF (Open Shortest Path First)
  - 132: SCTP (Stream Control Transmission Protocol)
- IANA (Internet Assigned Numbers Authority) がこれらのプロトコル番号を管理しています。
Header Checksum (ヘッダチェックサム)
- サイズ: 16ビット
- 役割: IPヘッダ部分のデータの整合性をチェックするために使用されます。ヘッダの各16ビットワードを足し合わせた合計値（1の補数和）の1の補数を計算した値が格納されます。
- ルーターはパケットを受信するたびに、ヘッダチェックサムを再計算し、受信したヘッダに格納されているチェックサム値と比較します。値が一致しない場合、ヘッダが転送中に破損したと判断し、パケットを破棄します。
- ヘッダチェックサムは、ルーターがパケットを転送する際にTTLなどのフィールドを書き換えるため、通過するルーターの全てで再計算されます。
- 注意: このチェックサムはヘッダのみを対象としており、IPペイロード（データ）の整合性はチェックしません。ペイロードの整合性チェックは通常、上位層プロトコル（例: TCPやUDPのチェックサム）によって行われます。IPv6ではこのフィールドは廃止されました。
Source IP Address (送信元IPアドレス)
- サイズ: 32ビット (4オクテット)
- 役割: パケットの送信元ホストのIPv4アドレスです。受信側ホストは、このアドレスを見て誰がパケットを送信したのかを識別します。また、送信元ホストは、自身への応答パケットの宛先としてこのアドレスを利用します。
Destination IP Address (宛先IPアドレス)
- サイズ: 32ビット (4オクテット)
- 役割: パケットの最終的な受信先ホストのIPv4アドレスです。ルーターは、このアドレスに基づいてパケットを次にどのルーターまたはネットワークに転送すべきかを判断（ルーティング）します。
Options (オプション)
- サイズ: 0〜40オクテット (IHLが5より大きい場合に存在)
- 役割: 通常のヘッダフィールドでは表現できない追加の制御情報を提供します。例としては、ソースルーティング（パケットが通過すべき特定のルーターのリストを指定）、レコードルート（パケットが通過したルーターのリストを記録）、タイムスタンプなどがあります。
- オプションフィールドは可変長であり、32ビットワードの境界に合わせるためにパディングが必要になる場合があります。
- 注意: オプションフィールドの処理はルーターに追加の負荷をかけるため、現在のインターネット上ではほとんど使用されていません。
Padding (パディング)
- サイズ: 0〜3オクテット (オプションが存在する場合)
- 役割: オプションフィールドが32ビットワードの境界で終わらない場合に、次のフィールド（通常はペイロードの先頭）が32ビット境界から始まるように、ゼロで埋めるために使用されます。これにより、ヘッダ全体が32ビットワードの倍数となり、ルーターやホストでの処理が容易になります。

IPv4ヘッダの構造は、基本的な配送機能を実現するために設計されていますが、IPアドレス空間の枯渇や、オプション処理の複雑さ、QoS機能の限界など、いくつかの課題も抱えていました。これらの課題を解決するために開発されたのがIPv6です。

4. IPv6ヘッダの構造とIPv4からの変更点

IPv6（Internet Protocol version 6）は、IPv4の後継として設計されたIPの新しいバージョンです。最大の変更点はアドレス長の大幅な拡張（32ビットから128ビットへ）ですが、ヘッダ構造もIPv4の課題を解決し、より効率的で拡張性の高い設計に変更されています。

IPv6の基本ヘッダは、固定長である40オクテット（バイト）です。IPv4のようにオプションが基本ヘッダに含まれることはありません。オプション機能は、後述する「拡張ヘッダ」として基本ヘッダとペイロードの間に挿入される形式になりました。

IPv6基本ヘッダの構造を図示し、各フィールドを詳細に解説します。

0 16 32 48 63 +-------------------+-------------------+-------------------+-------------------+ | Version (4 bits) | Traffic Class (8 bits) | Flow Label (20 bits) | +-------------------+-------------------+-------------------+-------------------+ | Payload Length (16 bits) | Next Header (8 bits) | Hop Limit (8 bits) | +---------------------------------------+-------------------+-------------------+ | | | Source IP Address (128 bits) | | | +-------------------------------------------------------------------------------+ | | | Destination IP Address (128 bits) | | | +-------------------------------------------------------------------------------+ | (Extension Headers - optional) | | +-------------------------+ | | | Extension Header 1 | | | +-------------------------+ | | | Extension Header 2 | | | +-------------------------+ | | (and so on...) | +-------------------------------------------------------------------------------+ | Data (Payload) | +-------------------------------------------------------------------------------+

各フィールドの意味は以下の通りです。IPv4との比較も交えながら解説します。

Version (バージョン)
- サイズ: 4ビット
- 役割: IPプロトコルのバージョンを示します。IPv6の場合、値は「6」（0110）になります。IPv4と同様に、受信側はこのフィールドでヘッダの解釈方法を判断します。
Traffic Class (トラフィッククラス)
- サイズ: 8ビット
- 役割: IPv4のToSフィールド（DSCP/ECN）に相当し、パケットの優先度やサービスタイプを示します。QoS制御に使用されます。IPv4と同様に、上位6ビットがDSCP、下位2ビットがECNとして利用されることが一般的です。
Flow Label (フローラベル)
- サイズ: 20ビット
- 役割: IPv6で新たに追加されたフィールドです。特定の通信フロー（送信元、送信先、アプリケーションなどで定義される一連のパケット群）を識別するために使用されます。
- 目的: ルーターは、同じフローラベルを持つパケット群に対して、送信元からの要求に応じて、特別な処理（例: QoSポリシーの適用、同一経路への固定、ステートレスなパケット処理の高速化など）を施すことができます。これにより、特にリアルタイム性が求められるストリーミングやVoIPなどのアプリケーションにおいて、より効率的で高品質な通信が実現可能になります。ルーターがパケットごとに詳細なヘッダ分析を行うことなく、フローラベルを見るだけで特定のフローに対する処理を適用できるため、処理の高速化に貢献します。
Payload Length (ペイロード長)
- サイズ: 16ビット
- 役割: IPv6基本ヘッダに続く、拡張ヘッダとIPペイロードを含めた部分全体の長さを示します。オクテット（バイト）単位です。
- 最大値: 65,535 オクテット。これはIPv4のTotal Lengthからヘッダ長を除いたペイロード部分の最大サイズと同じです。
- IPv4のTotal Lengthと異なり、基本ヘッダ自身の長さは含まれません。また、このフィールドだけでは非常に大きなペイロード（ジパケット – Jumbogram）を表現できませんが、ペイロード長が65,535を超えるパケットを扱う場合は、Hop-by-Hop Option拡張ヘッダに含まれるJumbo Payloadオプションを使用します。
Next Header (次ヘッダ)
- サイズ: 8ビット
- 役割: IPv4のProtocolフィールドに相当しますが、その機能は拡張されています。このフィールドは、IPv6基本ヘッダの直後に続くヘッダのタイプを示します。これは、上位層プロトコル（TCP, UDPなど）のヘッダである場合もあれば、後述するIPv6拡張ヘッダのタイプである場合もあります。
- IPv6では、拡張ヘッダが複数連結される可能性があるため、Next Headerフィールドはまるで鎖のようにつながっていきます。基本ヘッダのNext Headerは最初の拡張ヘッダのタイプを示し、その拡張ヘッダ自身のNext Headerフィールドが次の拡張ヘッダのタイプ、というように連鎖します。最後の拡張ヘッダのNext Headerフィールドが、最終的なペイロードである上位層プロトコル（TCPやUDPなど）のタイプを示します。
- IANAがIPv4 Protocolフィールドと同じ番号体系（ただし、IPv6拡張ヘッダ用の新しい番号が追加されています）で管理しています。
- 例:
  - 6: TCP
  - 17: UDP
  - 43: Routing Header (IPv6拡張ヘッダ)
  - 44: Fragment Header (IPv6拡張ヘッダ)
  - 58: ICMPv6 (ICMP for IPv6)
Hop Limit (ホップリミット)
- サイズ: 8ビット
- 役割: IPv4のTTLフィールドに相当します。パケットが転送できる最大ホップ数を示し、ルーターを通過するたびに1ずつ減算されます。値が0になったパケットは破棄され、ICMPv6のエラーメッセージ（Time Exceeded）が送信元に返されることがあります。
- 名称がTTLからHop Limitに変更されたのは、IPv4のTTLが本来「時間（Time）」の概念を含んでいた（ただし実際にはホップ数として使われていた）のに対し、IPv6では純粋にホップ数として機能するためです。
Source IP Address (送信元IPアドレス)
- サイズ: 128ビット (16オクテット)
- 役割: パケットの送信元ホストのIPv6アドレスです。IPv4の32ビットから大幅に拡張され、IPアドレス枯渇問題を根本的に解決します。
Destination IP Address (宛先IPアドレス)
- サイズ: 128ビット (16オクテット)
- 役割: パケットの最終的な受信先ホストのIPv6アドレスです。ルーターはこのアドレスとFlow Label、Next Headerフィールドなどを見てルーティング判断を行います。

IPv4ヘッダからの主な変更点（IPv6基本ヘッダ）:

アドレス長: 32ビットから128ビットへ大幅に拡張。
ヘッダ長: 固定長化 (40オクテット)。IPv4の最小ヘッダ長(20オクテット)より長いが、オプション処理の負担がないため、ルーターでの処理は効率化される。
Header Checksumの削除: チェックサム計算はルーターにCPU負荷をかけるため削除されました。データリンク層やトランスポート層（TCP/UDPなど）でのチェックサムに任されます。IPv6環境では、データリンク層の信頼性が向上していること、そしてTCP/UDPのチェックサムがエンドツーエンドで機能するため、IPレベルでのチェックサムは不要と判断されました。ただし、IPv6におけるTCP/UDPチェックサムの計算には、IPヘッダの一部（擬似ヘッダ）が含まれる必要があります。
Fragmentationの変更: フラグメントに関するフィールド（Identification, Flags, Fragment Offset）が基本ヘッダから削除されました。IPv6では、フラグメント化は原則として送信元ホストが行い、ルーターはフラグメント化を行いません（DFフラグ相当）。フラグメント化が必要な場合は、Fragment拡張ヘッダを使用します。再構築は受信側ホストが行います。
Optionsの扱い: オプションフィールドが基本ヘッダから削除され、IPv6拡張ヘッダとして独立しました。これにより、基本ヘッダはシンプルになり、ルーターは全てのパケットに対してオプションフィールドの有無や内容をチェックする必要がなくなりました。特定のオプションが必要な場合のみ、対応する拡張ヘッダを処理すれば良いため、処理効率が向上します。
新規フィールドの追加: Flow Labelフィールドが追加され、フローベースの効率的な処理が可能になりました。
フィールド名の変更: TTLがHop Limitに変更。ToSがTraffic Classに変更。ProtocolがNext Headerに変更。

全体として、IPv6ヘッダはIPv4に比べてシンプルかつ効率的な処理を目的として設計されています。特に固定長ヘッダと拡張ヘッダの分離は、高速なハードウェアベースのルーター処理に適しています。

IPv6拡張ヘッダ (Extension Headers)

前述の通り、IPv6ではオプション機能は基本ヘッダから分離され、「拡張ヘッダ」として実装されます。拡張ヘッダは複数連結（チェイン）することが可能で、Next Headerフィールドが次のヘッダのタイプを示します。これにより、必要な機能だけをパケットに含めることができ、基本ヘッダの処理を高速化しつつ、様々な拡張機能に対応できる柔軟性が得られます。

拡張ヘッダは、IPv6基本ヘッダのPayload Lengthフィールドで示される長さの中に含まれます。

よく利用されるIPv6拡張ヘッダの種類とその役割は以下の通りです。

Hop-by-Hop Options Header (ホップバイホップオプションヘッダ)
- Next Header値: 0
- 役割: パケットが通過する経路上の全てのノード（ルーターやホスト）によって処理される必要のあるオプションを格納します。現在定義されているオプションには、Jumbo Payload（非常に大きなペイロードを扱うためのオプション）やRouter Alert（ルーターがパケットの内容を詳細に検査する必要があることを示す）などがあります。Next Headerフィールドの値は、この拡張ヘッダの後に続くヘッダのタイプを示します。
Routing Header (ルーティングヘッダ)
- Next Header値: 43
- 役割: 送信元がパケットに通過させるべき特定のルーターのリスト（ソースルーティング）を指定するために使用されます。IPv4のLoose/Strict Source Routingオプションに相当しますが、より柔軟な形式（Type 0, Type 2など）があります。現在はセキュリティ上の懸念からType 0の使用は非推奨または禁止されています。Next Headerフィールドの値は、この拡張ヘッダの後に続くヘッダのタイプを示します。
Fragment Header (フラグメントヘッダ)
- Next Header値: 44
- 役割: IPv6パケットがフラグメント化された場合に使用されます。IPv4のIdentification, Flags, Fragment Offsetフィールドに相当する情報（元のパケットの識別値、フラグメントオフセット、Mフラグ – More Fragments）を格納します。IPv6では、ルーターによるフラグメント化は行われず、送信元ホストまたは最初のルーターの手前でフラグメント化が行われます。再構築は最終的な受信側ホストが行います。Next Headerフィールドの値は、元の非フラグメント化パケットにおいて、このフラグメント化されたペイロードの先頭に位置していたヘッダ（通常は上位層プロトコルヘッダや次の拡張ヘッダ）のタイプを示します。
Destination Options Header (宛先オプションヘッダ)
- Next Header値: 60
- 役割: パケットの最終的な受信先ホストによって処理されるオプションを格納します。IPv4のDestination Optionsに相当します。Next Headerフィールドの値は、この拡張ヘッダの後に続くヘッダのタイプを示します。
Authentication Header (AH – 認証ヘッダ)
- Next Header値: 51
- 役割: IPsec（IP Security）プロトコルスイートの一部として使用され、IPパケットの送信元認証、データの整合性チェック、リプレイ攻撃からの保護を提供します。AHはIPヘッダ（一部不変フィールドを除く）とペイロード全体の整合性を保護します。Next Headerフィールドの値は、AHの後に続くヘッダのタイプを示します。
Encapsulating Security Payload Header (ESP – カプセル化セキュリティペイロードヘッダ)
- Next Header値: 50
- 役割: IPsecの一部として使用され、データの機密性（暗号化）、認証、データの整合性、リプレイ攻撃からの保護を提供します。ESPは通常、IPヘッダの後に挿入され、ペイロード（上位層ヘッダとデータ）を暗号化します。また、認証機能も提供する場合、IPヘッダを含むパケット全体または一部の整合性を保護します。Next Headerフィールドの値は、ESPでカプセル化された元のパケットにおいて、ESPヘッダの後に位置していたヘッダのタイプを示します。

拡張ヘッダは、それぞれが独自のNext Headerフィールドを持つことで、柔軟なチェイン構造を実現しています。ルーターは、通常、Hop-by-Hop Optionsヘッダのみを処理し、それ以外の拡張ヘッダは最終的な受信側ホストが処理します。これにより、ルーターの処理負荷を軽減し、高速なパケット転送を可能にしています。

5. ネットワーク機器によるIPヘッダの処理

IPヘッダは、IPパケットがネットワーク上を旅する際に、ルーターやスイッチ、ファイアウォール、そして最終的な受信ホストによって様々な処理を受けます。特にルーターは、IPヘッダの情報を基にパケットの転送先を決定する中心的な役割を担います。

ルーターでの処理

IPパケットがルーターに到着すると、ルーターは受信したパケットのIPヘッダを読み取り、主に以下の処理を行います。

ヘッダチェック (IPv4): IPv4パケットの場合、ルーターはまずIPヘッダの整合性を確認するためにHeader Checksumを再計算し、受信値と比較します。チェックサムが一致しない場合、パケットは破損していると判断され、破棄されます。IPv6にはヘッダチェックサムがないため、このステップはありません。
バージョンチェック: ヘッダのVersionフィールドを確認し、パケットがIPv4かIPv6かを判断します。ルーターは自身が対応しているバージョンのパケットのみを処理します。
ヘッダ長チェック (IPv4): IPv4の場合、IHLフィールドを確認してヘッダの長さを判断します。Total Lengthフィールドとの整合性なども確認されます。
TTL/Hop Limitの減算: IPv4パケットの場合、TTLフィールドの値を1減らします。IPv6パケットの場合、Hop Limitフィールドの値を1減らします。
TTL/Hop Limitのチェック: 減算後のTTLまたはHop Limitの値が0になった場合、パケットは破棄されます。多くの場合、送信元に対してICMP (IPv4) または ICMPv6 (IPv6) のTime Exceededメッセージが返送されます。
宛先IPアドレスの参照: IPヘッダのDestination IP Addressフィールドを読み取ります。
ルーティングテーブル検索: 宛先IPアドレスを基に、ルーター自身の持つルーティングテーブルを検索します。ルーティングテーブルには、特定のネットワークアドレス（または特定のホストアドレス）に到達するための最適な次のホップ（次にパケットを転送すべきルーターまたはネットワーク）と、そのための出力インターフェースの情報が格納されています。
転送先インターフェースの決定: ルーティングテーブル検索の結果、パケットを次にどのネットワークインターフェースから送信すべきかが決定されます。
IPv6拡張ヘッダの処理 (特定のヘッダのみ): IPv6パケットの場合、ルーターはNext HeaderフィールドがHop-by-Hop Optionsヘッダ (値0) を示しているかを確認します。もしそうであれば、その拡張ヘッダの内容を処理します（例: Jumbo Payloadの処理）。それ以外の拡張ヘッダは、通常、ルーターは処理せずスキップし、そのまま転送します。
MTUチェックとフラグメント化 (IPv4): IPv4パケットの場合、ルーターはパケットを送信しようとしている出力インターフェースのMTU (Maximum Transmission Unit) を確認します。もしパケットサイズがMTUより大きく、かつDFフラグが立っていない場合、ルーターはパケットを小さなフラグメントに分割します。各フラグメントには新しいIPヘッダが付加され、Identification, Flags, Fragment Offsetフィールドが適切に設定されます。DFフラグが立っていてパケットサイズがMTUを超える場合は、パケットは破棄され、送信元にICMP Fragmentation Neededエラーが返されます。
ヘッダチェックサムの再計算 (IPv4): TTLフィールドの変更やオプションフィールド（もし処理した場合）の変更によりIPヘッダが変更されたため、IPv4パケットの場合、ルーターは送信前に新しいヘッダのチェックサムを再計算し、ヘッダに格納します。IPv6にはチェックサムがないため不要です。
データリンク層への引き渡し: 処理済みのIPパケット（場合によってはフラグメント化された複数パケット）は、決定された出力インターフェースに対応するデータリンク層プロトコル（例: Ethernet）に引き渡されます。データリンク層は、パケットに自身のヘッダ（例: Ethernetヘッダ）とトレーラを付加して、物理メディア上での送信に適したフレームとして整形します。

受信ホストでの処理

パケットが最終的な受信ホストに到着すると、データリンク層の処理を経てIPパケットが取り出され、IP層での処理が行われます。

IPヘッダのチェック: IPv4/IPv6のバージョン、IHL/Payload Length、Source/Destination IPアドレスなどを確認します。
宛先アドレスの確認: パケットのDestination IP Addressが自分自身のアドレスであるか、あるいは自分自身が参加しているマルチキャストグループのアドレスであるかを確認します。自分宛てでないパケットは破棄されます（ただし、ルーターとして動作している場合は転送処理に移る）。
Header Checksumの検証 (IPv4): IPv4パケットの場合、ヘッダチェックサムを再計算して検証します。不一致の場合、パケットは破棄されます。
フラグメントの再構築 (IPv4/IPv6):
- IPv4: パケットがフラグメントである場合（FlagsのMFフラグが立っているか、Fragment Offsetが0でない場合）、Identificationフィールドを見て同じ元のパケットに属する他のフラグメントが到着するのを待ちます。全てのフラグメントが揃い、Fragment OffsetとTotal Lengthの情報を使って正しい順序で並べられた後、元の完全なIPパケットが再構築されます。再構築に時間がかかりすぎたり、全てのフラグメントが揃わない場合は、フラグメントは破棄されます。
- IPv6: Fragment拡張ヘッダが存在する場合、その情報（Identification, Offset, Mフラグ）を見てフラグメントの再構築を行います。IPv6ではルーターはフラグメント化しないため、これは送信元ホストまたは最初のルーターの手前でフラグメント化されたパケットに対して行われます。
IPv6拡張ヘッダの処理: IPv6パケットの場合、基本ヘッダのNext Headerフィールドから順に拡張ヘッダを処理していきます。Hop-by-Hop Optionsヘッダ（もし存在すれば）はすでに経路上のルーターで処理されていますが、受信ホストも必要に応じて再処理します。Routing Header, Fragment Header, Destination Options Header, AH, ESPなどの拡張ヘッダは、最終的な受信ホストが処理します。Next Headerフィールドに従って次のヘッダに進み、全ての拡張ヘッダの処理が終わるまでこれを繰り返します。
Next Header/Protocolの確認: IPv6の場合、最後の拡張ヘッダまたは基本ヘッダのNext Headerフィールドを確認します。IPv4の場合、Protocolフィールドを確認します。これにより、IPヘッダ（および拡張ヘッダ）の後に続く上位層プロトコルのタイプ（TCP, UDP, ICMP, ICMPv6など）が判明します。
上位層プロトコルへの引き渡し: IPヘッダ（および拡張ヘッダ）を取り除いた残りの部分（IPペイロード）を、Next Header/Protocolフィールドで指定された上位層プロトコルスタックに引き渡します。例えば、Next Header/ProtocolがTCPを示していれば、TCPプロトコルスタックがそのデータを受け取り、さらに上のアプリケーション層へと処理を進めます。

このように、IPヘッダはパケットの転送経路上のルーターから最終的な受信ホストに至るまで、その情報が読み取られ、活用され、必要に応じて書き換えられることで、インターネット上のデータ通信が実現しています。

6. IPv4とIPv6ヘッダの比較

IPv4とIPv6のヘッダ構造を比較することで、IPv6がIPv4の課題をどのように克服しようとしているのかがより明確になります。

特徴	IPv4ヘッダ	IPv6ヘッダ	変更点・改善点
アドレス長	32ビット	128ビット	大幅なアドレス空間の拡張（IPアドレス枯渇問題の解決）
ヘッダ長	可変 (20〜60オクテット), 最小20オクテット	固定 (40オクテット)	固定長化によるルーター処理の効率化
ヘッダチェックサム	有 (16ビット), ルーターで再計算が必要	無	ルーター処理負荷軽減。信頼性向上は下位・上位層に依存。
フラグメント化	ルーターとホストの両方で行われる。ヘッダにフィールドあり。	原則ホストのみ。拡張ヘッダとして実装。	ルーター処理負荷軽減。パスMTU探索を推奨。
オプション	基本ヘッダに可変長で含まれる。ルーター処理負荷大。	拡張ヘッダとして分離。チェイン可能。ルーター処理負荷小。	基本ヘッダのシンプル化、ルーター処理効率向上、機能拡張の柔軟性向上。
QoS/サービスタイプ	ToSフィールド (8ビット), DSCP/ECNで利用	Traffic Classフィールド (8ビット), DSCP/ECNで利用	機能的には同等だが、Flow Labelとの連携でより高度なフローベースQoSが可能。
ルーティング支援	基本的なアドレスベースのルーティング	アドレスベース + Flow Labelによるフローベースルーティング	特定のフローに対する効率的な処理が可能。
名前	TTL (Time to Live)	Hop Limit	ホップ数を明示する名称に変更。機能はほぼ同じ。
次ヘッダ/プロトコル識別	Protocol (8ビット)	Next Header (8ビット)	上位層プロトコルだけでなく、拡張ヘッダも指定可能。チェイン構造の実現。
フィールド数	12 (Options/Padding除く固定部) + Options	8	固定長の基本ヘッダはシンプル化。

IPv6は、IPv4の設計から得られた教訓を基に、スケーラビリティ、パフォーマンス、拡張性を向上させることを目指しています。特に、ヘッダの固定長化、拡張ヘッダの導入、そしてフローラベルは、今後のインターネットトラフィックの増加と多様化に対応するための重要な変更点です。

7. まとめ：IPヘッダが実現するもの

本記事では、IPヘッダについて、その定義、ネットワークにおける役割、そしてIPv4およびIPv6における詳細な構造と各フィールドの意味を解説しました。

IPヘッダは、IPパケットのデータ本体（ペイロード）の前に付加される制御情報です。インターネット上でパケットを正確に送信元から送信先へ配送するために不可欠な役割を担います。
主な役割は、アドレッシング（宛先・送信元特定）、ルーティング（経路選択）、データタイプの識別、パケットの管理（サイズ、フラグメント、生存時間）、そして限定的な品質管理（QoS）です。
IPv4ヘッダは可変長（最小20オクテット）であり、バージョン、ヘッダ長、DSCP/ECN、全長、識別、フラグ、フラグメントオフセット、TTL、プロトコル、ヘッダチェックサム、送信元/宛先IPアドレス、そしてオプションフィールドから構成されます。ヘッダチェックサムやルーターによるフラグメント化は、ルーターに処理負荷をかける要因となることがありました。
IPv6ヘッダは固定長（40オクテット）であり、バージョン、トラフィッククラス、フローラベル、ペイロード長、次ヘッダ、ホップリミット、送信元/宛先IPアドレスから構成されます。アドレス長の大幅な拡張に加え、ヘッダチェックサムの廃止、フラグメント化の原則ホスト処理化、オプションの拡張ヘッダ化、フローラベルの新設など、IPv4の課題を解決し、効率性と拡張性を向上させるための設計変更がなされています。
IPv6拡張ヘッダは、基本ヘッダから分離されたオプション機能を提供する可変長のヘッダであり、複数チェイン可能です。Hop-by-Hop Optionsヘッダ以外のほとんどは最終ホストが処理するため、ルーターの負荷を軽減します。
ルーターやホストは、IPヘッダの各フィールドを読み取り、パケットの転送、エラー検出、フラグメントの再構築、上位層プロトコルへの引き渡しといった処理を行います。

IPヘッダは、インターネットという広大で複雑なネットワークにおいて、無数のパケットを目的地へ導くための「地図」であり「指示書」です。その詳細な構造と役割を理解することは、ネットワーク通信の仕組み全体を深く理解する上で非常に重要です。

IPv4からIPv6への移行は進行中であり、将来的にはIPv6がインターネットの主流となるでしょう。IPv6の新しいヘッダ構造と機能（特にフローラベルや拡張ヘッダ）は、IoTの普及や多様なアプリケーションの要求に応えるための基盤となります。

IPヘッダに関する知識は、ネットワークのトラブルシューティング、セキュリティ、そして新しいネットワーク技術の学習においても役立つ、ネットワーク技術者の基礎となるスキルと言えます。

本記事が、IPヘッダに関する理解を深める一助となれば幸いです。さらに深く学ぶためには、RFC（Request for Comments）などの原典や、ネットワークプロトコルに関する専門書を参照することをお勧めします。