✨

IPアドレス・ICMPの深掘り学習_02_IPプロトコルとパケット構造の詳細

2025/10/30に公開

 IPプロトコルとパケット構造の詳細
 📌 この文書で学べることIPパケットの構成要素（ヘッダ・ペイロード）
IPv4ヘッダの全フィールドの詳細解説
ECN（明示的輻輳通知）の仕組みとメリット
IPフラグメンテーション（パケット分割）の詳細
パディングの役割と仕組み
IPv6ヘッダの構造と進化点
IPv4とIPv6の設計思想の違い
このメモはIPアドレス・ICMPの深掘り学習_01_IPアドレスの基礎と構造の続きとなります。

 1. IPパケットの概要
 1.1 IPパケットの構成IPパケットの構成：

インターネット通信の基礎であるIPパケットは、以下の2つの部分で構成されています。

IPヘッダー: 「送り状」に相当し、送信元/宛先アドレス、プロトコル番号、TTL等の制御情報を含む

IPペイロード: 実際のデータ（TCPセグメント、UDPデータグラム、ICMPメッセージ等）
IPの標準化：
IPは1981年に発行された RFC 791「INTERNET PROTOCOL」 で標準化
イーサネットヘッダーのタイプコードでは 「0x0800」 と定義

 2. IPv4ヘッダのフォーマット
 2.1 ヘッダ構造IPv4ヘッダは 通常20バイトの固定長部分 と、オプションの可変長部分 から構成されます。

 ヘッダ構造図 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|バージョン |  IHL  |      ToS      |          全長（パケット長さ） |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           識別子              |フラグ |   フラグメントオフセット  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      TTL      |  プロトコル   |       ヘッダチェックサム      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       送信元IPアドレス                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       宛先IPアドレス                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    オプション（可変長）                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 2.2 主要フィールドの詳細解説
 1. バージョン (Version / 4ビット)
役割: IPのバージョン番号を示す

IPv4の値: 4 (バイナリ: 0100)

IPv6の値: 6 (バイナリ: 0110)

用途: ルーターがIPv4/IPv6を判別して適切に処理

 2. IHL (Internet Header Length / 4ビット)
役割: IPヘッダの長さを「4バイト単位」で示す

通常の値: 5 (20バイト ÷ 4バイト = 5)

最大値: 15 (60バイト = 固定20バイト + オプション40バイト)

計算例: オプション8バイトを含む場合 → 28バイト ÷ 4 = 7

 3. ToS (Type of Service / 8ビット)
役割: パケットの優先度や品質要求（低遅延、高スループット等）を指定

構成: DSCP (6ビット) + ECN (2ビット)

DSCP (Differentiated Services Code Point) : 優先制御と帯域制御

ECN (Explicit Congestion Notification) : 輻輳通知

|         DSCP (6ビット)         |   ECN (2ビット)   |
+--------------------------------+-------------------+
ECNの基本的な仕組み ：
ECN（明示的輻輳通知）は、ネットワークの輻輳をパケットドロップなしで通知する仕組みです。
ECNコードポイント（末尾2ビット） ：

00 (Not-ECT): ECN非対応

01, 10 (ECT): ECN対応の通信

11 (CE): 輻輳経験済み
動作概要 ：
送信元がECT (01/10) をセットして送信
ルーターがバッファ溢れそうになるとパケットを破棄せず、ECNフィールドをCE (11) に書き換え
受信側がCEマークを検知し、TCPのACKでECEフラグを使って送信元に通知
送信元が輻輳を検知し、パケットロスなしで送信量を抑制
メリット : パケットロス回避、低遅延、スループット向上により、VoIPやビデオ会議などリアルタイム通信に効果的

 4. 全長 (Total Length / 16ビット)
役割: IPヘッダ + データ部分の合計長をバイト単位で示す

最大値: 65,535バイト

イーサネットMTU: 通常1500バイト (16進数: 0x05DC)

例: MTU上限までデータが入っている場合、パケット長は1500 (0x05DC)

 5. 識別子 (Identification / 16ビット)
役割: フラグメント化されたパケットのグループIDとして機能

用途: 分割された断片が元々同じパケットであることを識別

重要性: パケット分割時、すべての断片は同じ識別子を持つ（詳細は2.4節）

 6. フラグ (Flags / 3ビット) & フラグメントオフセット (Fragment Offset / 13ビット)
役割: パケットのフラグメンテーション（分割）制御
フラグの種類：


フラグ
意味
説明


DF (Don't Fragment)
分割禁止

1の場合、パケット分割を許可しない

MF (More Fragments)
後続断片あり

1の場合、さらに断片が続くことを示す

フラグメントオフセット：
分割パケットの元データ内での位置を示す（8バイト単位）
例: オフセット185 = 1480バイト目から開始 (185 × 8 = 1480)
アプリケーション設計での考慮点：

アプリケーションによっては処理遅延を考慮して、DFビットを「1」に

セット（フラグメンテーション禁止）し、上位層でデータサイズを調整するケースもあります。

 7. TTL (Time to Live / 8ビット)
役割: パケットの生存時間（実際は経由可能なルーター数）を示す

動作: ルーター通過ごとに1減少、0になると破棄され送信元にICMP「時間超過」メッセージを送信

目的: パケットが無限にループするのを防ぐ
OSごとのデフォルトTTL値：


OS / 機器の種類
デフォルトTTL値


Windows
128

Linux / macOS / Android
64

Cisco IOS
255

Juniper JUNOS
64

Solaris
255

実践的活用：pingによるOSの推測
pingコマンドの応答TTLから、リモートホストのOSを推測できます。
例: 応答TTL=52の場合
Linuxのデフォルト64から推測: 64 - 52 = 12ホップ経由
相手OSはLinux/macOSの可能性が高い
注意: あくまで推測であり、管理者がTTLを変更している場合やネットワーク機器がTTLを書き換える場合もあります。

 8. プロトコル (Protocol / 8ビット)
役割: IPペイロードに格納されているプロトコルを示す

用途: 受信側がデータ部をどう処理すべきかを判断
主要なプロトコル番号：


番号
プロトコル
用途


1
ICMP
ping、traceroute等の診断ツール

6
TCP
Web (HTTP/HTTPS)、メール (SMTP)、SSH等

17
UDP
DNS、動画ストリーミング、VoIP等


 9. ヘッダチェックサム (Header Checksum / 16ビット)
役割: IPヘッダ部分のエラー検出

計算方法: RFC 1071で定義（1の補数計算）

対象: ヘッダのみ（データ部は含まない）

動作: 輸送途中にヘッダが破損した場合、チェックサムが不一致となりパケットは破棄

 10. 送信元IPアドレス (Source IP Address / 32ビット)
役割: パケット送信元のIPアドレス

形式: xxx.xxx.xxx.xxx (各オクテット0〜255)

 11. 宛先IPアドレス (Destination IP Address / 32ビット)
役割: パケット宛先のIPアドレス

形式: xxx.xxx.xxx.xxx (各オクテット0〜255)

 12. オプション (Options / 可変長)
役割: 通信経路の記録、セキュリティレベルの指定等の追加機能

使用頻度: 現代では稀（ほとんど使用されない）

パディング: オプション使用時、ヘッダ全体を4バイトの倍数に調整するため、必要に応じてNOP (No-Operation) や EOL (End of Option List) を追加

 2.3 ECN（明示的輻輳通知）の詳細
 ECNとはECN (Explicit Congestion Notification) は、「明示的な輻輳（ふくそう）通知」と訳され、ネットワークの輻輳をパケットドロップなしで通知する仕組みです。

 従来の問題点：パケットドロップによる輻輳検知従来の方法：

輻輳の発生: ルーターのバッファに大量のパケットが到着

バッファの溢れ: バッファ満杯時に新しいパケットをドロップ（破棄）

輻輳の検知: 送信側がACK未着で推測

送信量の抑制: 輻輳ウィンドウを小さくして送信ペースを落とす
問題点：
実際にパケットロスが発生しないと輻輳を検知できない
再送による遅延とスループット低下

 ECNの動作フロー詳細ECNが機能するには、送信元・受信元・経路上のルーターすべてがECN対応である必要があります。
【事前交渉】通信開始時
送信元と受信元は、TCPの接続確立時（SYN/ACK）にECN対応を確認
【送信】ECN対応をマーキング
送信元は、ECNフィールドに 01 または 10 (ECT) を設定
「このパケットはECN対応通信の一部」という印
【ルーター】輻輳の検知とマーキング
ルーターのバッファが閾値に達し「溢れそう」と判断
ECTマーク付きパケットをドロップせず、ECNフィールドを 11 (CE) に書き換えて転送
【受信元】輻輳マーキングの検知と通知
CE (11) マーク付きパケットを受信
次のACKパケットのTCPヘッダのECEフラグ (ECN-Echo) をオンにして送信元に通知
【送信元】輻輳の検知と送信量抑制
ECEフラグ付きACKを受信
パケットを失わずに輻輳を明確に検知
輻輳ウィンドウを小さくして送信ペースを落とす

 2.4 IPフラグメンテーションの詳細
 なぜフラグメンテーションが必要かインターネットは、イーサネット、光ファイバー、Wi-Fi等、様々なネットワークが接続されて成り立っています。それぞれのネットワークには、一度に転送できるパケットの最大サイズMTU (Maximum Transmission Unit) が定められています。
例: 一般的なイーサネットのMTU = 1500バイト
異なるMTUのネットワーク間でパケットを転送する際、大きなパケットを小さな断片に分割する必要があり、この処理がIPフラグメンテーションです。
シナリオ例：

MTU 4000バイトのネットワーク → MTU 1500バイトのイーサネット

→ 3000バイトのパケットをそのまま通過させることができない

 フラグメンテーションで活躍する3つのヘッダフィールド
識別子 (Identification): グループID

フラグ (Flags): 最後の断片かどうか

フラグメントオフセット (Fragment Offset): 順番と位置

 フラグメンテーションの具体例【シナリオ】

送信元が2920バイトのデータを送信。IPヘッダが20バイトなので、全長2940バイトのIPパケットが作成される。このパケットがMTU 1500バイトのルーターを通過する。
① 元の大きなパケット


フィールド
値


識別子

12345 (ユニークな番号)

フラグ
DF=0 (分割許可), MF=0 (分割されていない)

オフセット
0

全長
2940

② ルーターによる分割処理
【1つ目の断片パケット】


フィールド
値
説明


識別子
12345
元のパケットの識別子をコピー

フラグ
MF=1
まだ後に続く断片があることを示す

オフセット
0
元のデータの先頭から始まる

全長
1500
MTUの最大サイズ

データ部分
1480バイト
元のデータの先頭から (1500 - ヘッダ20)

【2つ目の断片パケット】


フィールド
値
説明


識別子
12345
元のパケットの識別子をコピー

フラグ
MF=0
これが最後の断片

オフセット
185
元のデータの1480バイト目から (1480 ÷ 8 = 185)

全長
1460
残りのデータ1440バイト + ヘッダ20バイト

データ部分
1440バイト
元のデータの1481バイト目から最後まで


 受信側での再構築（リアセンブル）受信側は、バラバラになった断片パケットを以下の手順で再構築します。
識別子フィールドを確認
「識別子が12345のパケットが来た。これらは元々1つのパケットだったグループだ」と判断
同じIDを持つパケットを収集
フラグメントオフセットフィールドを確認
「オフセットが0のパケットは先頭」
「オフセットが185のパケットはその次」
パズルのピースを正しい順序に並べ替え
フラグ (MFビット) を確認
MF=0のパケットを見つけ、「これがこのグループの最後の断片」と判断
再構築
識別子12345のグループの断片がすべて揃ったら、オフセット順に連結
元の2940バイトのIPパケットを復元

 フラグメンテーションのまとめ

フィールド
役割
重要性


識別子
グループID
「どの断片とどの断片を組み合わせるか」を判断

オフセット
順番と位置
グループ内での正しい順序で組み立て

MFフラグ
最後の断片か
すべての断片を収集し終えたことを確認

識別子がなければ、同時に複数のパケットが分割されて届いた場合、どの断片がどのパケットのものか分からなくなり、大混乱に陥ります。

 3. IPv6ヘッダの詳細
 3.1 IPv6ヘッダの進化IPv6ヘッダは、IPv4の問題点を解決するためによりシンプルで効率的な構造 に再設計されました。
最大の違い：
IPv4: 可変長ヘッダ（20〜60バイト）
IPv6: 常に40バイトの固定長
これにより、ルーターは非常に高速にヘッダを処理できるようになりました。

 3.2 IPv6ヘッダ構造図 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|バージョン |トラフィッククラス |          フローラベル         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         ペイロード長          |  次のヘッダ   |  ホップリミット |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                       送信元IPアドレス (128ビット)              |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                       宛先IPアドレス (128ビット)                |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 3.3 IPv6ヘッダフィールド解説
 1. バージョン (Version / 4ビット)
値: 6 (バイナリ: 0110)

用途: ネットワーク機器がIPv6パケットと判断

 2. トラフィッククラス (Traffic Class / 8ビット)
役割: IPv4のToSフィールドに相当し、パケットの優先度を制御

 3. フローラベル (Flow Label / 20ビット)
役割: IPv6で新たに追加された機能

用途: 一連の通信（フロー）に同じラベルを付けることで、ルーターが個々のパケットを見ずにフロー単位で高速に転送処理（QoS制御等）を実行

 4. ペイロード長 (Payload Length / 16ビット)
役割: IPv4の「全長」とは異なり、IPv6ヘッダ自身を含まない、後続のデータ部分（ペイロード）の長さを示す

 5. 次のヘッダ (Next Header / 8ビット)
役割: IPv4の「プロトコル」フィールドに相当。基本ヘッダの次に来るヘッダの種類を示す

値: 6 (TCP), 17 (UDP), 58 (ICMPv6) 等

拡張性: IPv6では「拡張ヘッダ」という仕組みがあり、このフィールドを使って認証や暗号化等の追加機能を柔軟に連結可能

 6. ホップリミット (Hop Limit / 8ビット)
役割: IPv4のTTLと同じ。ルーター通過ごとに1減少、0になるとパケットは破棄

名称変更: 役割をより正確に表すように変更

 7. 送信元/宛先IPアドレス (Source/Destination Address / 各128ビット)
IPv4からの拡張: 32ビット → 128ビット

アドレス数: 事実上無限に近い数のアドレスが利用可能

ヘッダ内の割合: 40バイトのうち32バイトをアドレスが占める

 3.4 IPv4から廃止されたフィールドIPv6ヘッダがシンプルになった理由を理解するため、IPv4から何がなくなったのかを確認します。


IPv4フィールド
IPv6での扱い
理由


IHL (ヘッダ長)
廃止
ヘッダが40バイトの固定長のため不要

識別子、フラグ、オフセット
廃止
パケット分割は途中のルーターでは行わず、送信元のみが実施。必要な場合は拡張ヘッダで対応

ヘッダチェックサム
廃止
ルーターがTTL書き換えごとにチェックサムを再計算する処理は大きな負荷。TCP/UDPがデータ全体のチェックサムを持っているため、信頼性を上位層に委譲し、処理を大幅に高速化


 3.5 IPv6の利点まとめ
固定長ヘッダ: ルーターの処理高速化

シンプルな構造: 不要なフィールドを廃止

拡張ヘッダ: 柔軟な機能追加が可能

膨大なアドレス空間: 事実上無限のアドレス

効率的な処理: チェックサム計算の廃止等による最適化

 4. まとめ
 IPv4パケット構造の重要ポイントIPパケット構成
IPヘッダ（20バイト固定 + オプション可変）+ IPペイロード
送り状の役割を果たすヘッダに制御情報を格納
重要なヘッダフィールド

TTL: パケットのループ防止、OS推測に活用可能

プロトコル番号: 上位層プロトコルの識別（TCP/UDP/ICMP）

識別子: フラグメンテーション時のグループID

ECN: 輻輳通知を効率化（パケットロスなし）
ECNの革新性
パケットドロップなしで輻輳検知
低遅延・高スループットを実現
リアルタイム通信に最適
フラグメンテーション
MTU違いのネットワーク間で必要
識別子・オフセット・MFフラグで管理
受信側で元のパケットに再構築
パディング
オプション使用時のみ必要
ヘッダ長を4バイトの倍数に調整
NOP/EOLで実現

 IPv6の設計思想シンプルで高速
固定長40バイトヘッダ
不要なフィールドを廃止
ルーターの処理負荷を大幅削減
拡張性
拡張ヘッダで柔軟に機能追加
基本ヘッダは常に同じ構造
膨大なアドレス空間
128ビットアドレス（IPv4の2^96倍）
アドレス枯渇の根本的解決

 参考資料『マスタリングTCP/IP 入門編』
著者: 井上 直也, 村山 公保, 竹下 隆史, 荒井 透, 苅田 幸雄
出版社: オーム社
発行年: 2019年
『ネットワーク技術の教科書』
著者: 長谷 和幸
出版社: アイテック
発行年：2022年
『体験しながら学ぶネットワーク技術入門』
著者：みやた　ひろし
出版社：SBクリエイティブ
発行年：2024/1/13
RFC 791（Internet Protocol）
RFC 1918（Address Allocation for Private Internets）
RFC 4632（Classless Inter-domain Routing - CIDR）

フラグ	意味	説明
DF (Don't Fragment)	分割禁止	`1`の場合、パケット分割を許可しない
MF (More Fragments)	後続断片あり	`1`の場合、さらに断片が続くことを示す

OS / 機器の種類	デフォルトTTL値
Windows	128
Linux / macOS / Android	64
Cisco IOS	255
Juniper JUNOS	64
Solaris	255

番号	プロトコル	用途
`1`	ICMP	ping、traceroute等の診断ツール
`6`	TCP	Web (HTTP/HTTPS)、メール (SMTP)、SSH等
`17`	UDP	DNS、動画ストリーミング、VoIP等

フィールド	値
識別子	`12345` (ユニークな番号)
フラグ	DF=0 (分割許可), MF=0 (分割されていない)
オフセット	`0`
全長	`2940`

フィールド	値	説明
識別子	`12345`	元のパケットの識別子をコピー
フラグ	MF=1	まだ後に続く断片があることを示す
オフセット	`0`	元のデータの先頭から始まる
全長	`1500`	MTUの最大サイズ
データ部分	1480バイト	元のデータの先頭から (1500 - ヘッダ20)

フィールド	役割	重要性
識別子	グループID	「どの断片とどの断片を組み合わせるか」を判断
オフセット	順番と位置	グループ内での正しい順序で組み立て
MFフラグ	最後の断片か	すべての断片を収集し終えたことを確認

IPv4フィールド	IPv6での扱い	理由
IHL (ヘッダ長)	廃止	ヘッダが40バイトの固定長のため不要
識別子、フラグ、オフセット	廃止	パケット分割は途中のルーターでは行わず、送信元のみが実施。必要な場合は拡張ヘッダで対応
ヘッダチェックサム	廃止	ルーターがTTL書き換えごとにチェックサムを再計算する処理は大きな負荷。TCP/UDPがデータ全体のチェックサムを持っているため、信頼性を上位層に委譲し、処理を大幅に高速化

IPプロトコルとパケット構造の詳細

📌 この文書で学べること

1. IPパケットの概要

1.1 IPパケットの構成

2. IPv4ヘッダのフォーマット

2.1 ヘッダ構造

ヘッダ構造図

2.2 主要フィールドの詳細解説

1. バージョン (Version / 4ビット)

2. IHL (Internet Header Length / 4ビット)

3. ToS (Type of Service / 8ビット)

4. 全長 (Total Length / 16ビット)

5. 識別子 (Identification / 16ビット)

6. フラグ (Flags / 3ビット) & フラグメントオフセット (Fragment Offset / 13ビット)

7. TTL (Time to Live / 8ビット)

8. プロトコル (Protocol / 8ビット)

9. ヘッダチェックサム (Header Checksum / 16ビット)

10. 送信元IPアドレス (Source IP Address / 32ビット)

11. 宛先IPアドレス (Destination IP Address / 32ビット)

12. オプション (Options / 可変長)

2.3 ECN（明示的輻輳通知）の詳細

ECNとは

従来の問題点：パケットドロップによる輻輳検知

ECNの動作フロー詳細

2.4 IPフラグメンテーションの詳細

なぜフラグメンテーションが必要か

フラグメンテーションで活躍する3つのヘッダフィールド

フラグメンテーションの具体例

受信側での再構築（リアセンブル）

フラグメンテーションのまとめ

3. IPv6ヘッダの詳細

3.1 IPv6ヘッダの進化

3.2 IPv6ヘッダ構造図

3.3 IPv6ヘッダフィールド解説

1. バージョン (Version / 4ビット)

2. トラフィッククラス (Traffic Class / 8ビット)

3. フローラベル (Flow Label / 20ビット)

4. ペイロード長 (Payload Length / 16ビット)

5. 次のヘッダ (Next Header / 8ビット)

6. ホップリミット (Hop Limit / 8ビット)

7. 送信元/宛先IPアドレス (Source/Destination Address / 各128ビット)

3.4 IPv4から廃止されたフィールド

3.5 IPv6の利点まとめ

4. まとめ

IPv4パケット構造の重要ポイント

IPv6の設計思想

参考資料

Discussion