RFC 791: IP(インターネットプロトコル)
IPヘッダの各フィールドと「ベストエフォートで運ぶだけ」という設計思想を原典から読めば、TTL・フラグメント・チェックサムがなぜその形なのか、そして信頼性がなぜ上位層の仕事なのかが腑に落ちる。
- IPは1981年のRFC 791が定めた、パケットを宛先まで運ぶだけの非信頼・非順序・ベストエフォートなプロトコル。届く保証も順番の保証も重複しない保証もあえて持たない。
- 20バイトの基本ヘッダに、宛先へ届けるための最小限——バージョン・全長・識別子とフラグメント情報・TTL・上位プロトコル番号・ヘッダチェックサム・送信元/宛先アドレス——だけを詰める。
- TTLは経由ルータごとに1減り、0で破棄される。無限ループを止める安全弁であり、信頼性や再送はTCPなど上位層に委ねる、という層の分離が設計の核心。
このRFCが決めたこと
横にスクロール
RFC 791 は、インターネットの土台である IP(バージョン4)を定義した文書です。決めたことは驚くほど禁欲的で、「あるホストから別のホストへ、データの塊(データグラム)をできるだけ届ける」——ただそれだけです。届いたことの確認も、順番どおりに並べ直すことも、重複を取り除くことも、RFC 791 はしないと明言します。これがベストエフォート型と呼ばれる所以です。
この割り切りは弱さではなく、設計思想です。ネットワークの中核(ルータ)は極力単純にし、信頼性のような複雑な仕事は両端のホストに置く。いわゆる「賢い末端・単純な中核(end-to-end 原則)」で、これによりIPは物理媒体を選ばず、上に TCP でも UDP でも載せられる薄い共通層になりました。IPがOSI参照モデルのどこに位置し、TCP/UDPとどう積み重なるかはTCP/IPやOSI 7層の可視化が土台になります。
ヘッダを精読する
IPの仕事の大半は、先頭に付く20バイト(オプション無しの場合)のヘッダに凝縮されています。主要フィールドを追うと、IPが「何を最小限とみなしたか」が見えます。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| フィールド | 役割 |
|---|---|
| Version / IHL | IPのバージョン(4)と、ヘッダ長を4バイト単位で示す。オプションが可変なので長さの明示が要る |
| Total Length | ヘッダ+データの総バイト数。16ビットなので理論最大は65535バイト |
| Identification / Flags / Fragment Offset | フラグメント分割された断片を、元のデータグラムへ復元するための識別子と位置情報 |
| Time to Live (TTL) | 残り生存ホップ数。ルータを1つ越えるごとに1減り、0になったら破棄する |
| Protocol | 中身が何か(6=TCP, 17=UDP, 1=ICMP など)。上位層への振り分けに使う |
| Header Checksum | ヘッダのみの誤り検出。TTLが変わるたびルータで再計算される |
| Source / Destination Address | 送信元と宛先の32ビットIPアドレス |
注目すべきは、チェックサムがヘッダだけを守り、データ本体は守らない点です。データの完全性は上位層(TCPの擬似ヘッダ込みチェックサムなど)に任せる、という分業がここにも現れています。
フラグメンテーションとTTL
途中の回線が一度に運べる最大サイズ(MTU)は経路ごとに違います。データグラムがMTUを超えると、RFC 791 では途中のルータが分割(フラグメント)できます。各断片は同じ Identification を持ち、Fragment Offset で元の位置を示し、More Fragments フラグで「まだ続きがある」ことを伝えます。復元は最終的な宛先ホストだけが行います——途中で組み直さないのも、中核を単純に保つためです。
分割は一見便利ですが、1断片でも失われると全体が無駄になり、再送コストが跳ね上がります。そのため現代では、送信側が経路の最小MTUを先に探る Path MTU Discovery で分割を避けるのが定石です。IPv6ではルータによる分割は廃止され、送信元だけが担います。
TTLは元々「秒数」を意図した名残ですが、実運用では経由ルータ数(ホップ数)として機能します。ルータは転送のたびにTTLを1減らし、0になったパケットを捨てて ICMP の time exceeded を返します。これがルーティングの無限ループを止める安全弁であり、traceroute がTTLを1,2,3…と増やして経路上の各ルータをあぶり出せる仕組みの土台でもあります。
つまずきやすい点
第一に、IPは「届ける努力」しかしないこと。パケットロス・順序入れ替え・重複はIPの想定内の正常動作で、それを隠すのはネットワーク上位の TCP の役目です。第二に、ヘッダチェックサムはヘッダのみで、しかもTTLが毎ホップ変わるためルータごとに再計算されます。第三に、送信元アドレスは詐称できてしまう(IPは真正性を保証しない)——これが送信元偽装やリフレクション攻撃の温床で、フィルタリングや上位の認証が別途要る理由です。
まとめ
RFC 791 の価値は、機能を足したことよりあえて足さなかったことにあります。信頼性も順序保証もセキュリティも持たず、ただ宛先へ運ぶ薄い層に徹したからこそ、IPはあらゆる媒体と上位プロトコルを束ねる「細い腰」になれました。TTLやフラグメントの挙動は、この最小主義から素直に導けます。上に載る信頼性の層はTCP/IPから辿ってください。
RFC精読の記事ガイド
RFC 791: IP(インターネットプロトコル)を実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
RFC
比較で見る軸
難易度: advanced / カテゴリ: RFC精読 / タグ数: 5
導入後に効く点
20バイトの基本ヘッダに、宛先へ届けるための最小限——バージョン・全長・識別子とフラグメント情報・TTL・上位プロトコル番号・ヘッダチェックサム・送信元/宛先アドレス——だけを詰める。
先に潰すリスク
用語だけ覚えても、設計・実装・運用でどこに効くかを確認しないと判断を誤る。
- 難易度
- advanced
- カテゴリ
- RFC精読
- タグ数
- 5
判断チェックリスト
- 自社の用途が「RFC / IP」に近いか確認する。
- 強みである「IPは1981年のRFC 791が定めた、パケットを宛先まで運ぶだけの非信頼・非順序・ベストエフォートなプロトコル。届く保証も順番の保証も重複しない保証もあえて持たない。」が本当に評価軸になるか確認する。
- 注意点の「用語だけ覚えても、設計・実装・運用でどこに効くかを確認しないと判断を誤る。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。