IPv4
32ビットのIPアドレスを使ってネットワーク間のパケット配送を行う、IPのバージョン4である。パケットの先頭には最小20バイトのヘッダーを持ち、宛先やパケット長などの情報を用いて転送される。
イマシルちゃんの解説
IPv4は、データをパケットというまとまりにしてネットワーク越しに運ぶ、IPという通信プロトコルのバージョン4だよ。
機器の設定で見かける「192.168.1.10」のように、数字を四つの組に区切ったIPアドレスを使うんだ。
パケットの先頭にはヘッダーという情報欄があり、送信元や宛先のアドレスなどが入っているよ。
途中のルータはその情報を読んで、宛先へ向かう次の機器にパケットを渡していくの。
ヘッダーには大きさや転送を続けられる限度も記録されていて、回線に合わせた処理や迷子のパケットへの対処に使うんだ。
こうした共通の形式があるから、離れたネットワーク同士でもデータを受け渡せるんだよ。
この解説はわかりやすかったですか?
より深い解説
アドレスの形式と配送の単位
IPv4はIPの配送機能を具体的なアドレス形式とパケット形式で定めたものである。IPに共通するコネクションレス・ベストエフォートという性質を持ち、到着や到着順を保証しない。基本仕様はRFC 791で定義され、その後も各機能の仕様が更新されている。
アドレスは8ビットずつ四つに分け、各部分を0〜255の十進数で表してピリオドで区切る。例えば192.168.50.10/24の/24は、先頭から何ビットをネットワークの範囲の識別に使うかを示すプレフィックス長である。同じ/24に属するアドレスでも、異なるホストを表す残りの部分が異なる。
通常のユニキャストアドレスはネットワーク上のインタフェースに割り当てられる。一台の機器が複数のインタフェースやアドレスを持つこともあるため、一つのIPアドレスと一台の物理機器が常に一対一になるわけではない。アドレスの範囲やサブネットの計算はIPアドレス、サブネットマスク、CIDRで詳しく扱う。
配送先には一つの相手を指定するユニキャストのほか、同一ネットワーク内などの全体を対象とするブロードキャスト、グループを対象とするマルチキャストがある。マルチキャストはIPv6にも存在する。利用可能な配送範囲や転送にはネットワーク側の設定も関係し、対応するアドレスを書くだけで任意の相手全員に届くわけではない。
ヘッダーを構成する情報
IPv4パケットはヘッダーとデータ部から成る。データ部にはTCPやUDPのヘッダーとデータ、またはICMPメッセージなどを格納する。分割されたパケットでは元のデータ部の一部分が入る。
| フィールド | 長さ | 主な役割 |
|---|---|---|
| Version | 4ビット | IPのバージョンを示す。IPv4では値は4 |
| IHL | 4ビット | IPヘッダーの長さを示す |
| DSCP・ECN | 合計8ビット | パケットの扱いの区分と輻輳の通知に使う |
| Total Length | 16ビット | IPパケット全体の長さを示す |
| Identification | 16ビット | 同じ元パケットに属する分割片の識別に使う |
| Flags | 3ビット | 分割の可否や後続の分割片の有無を示す |
| Fragment Offset | 13ビット | 元のデータ部における分割片の位置を示す |
| TTL | 8ビット | 転送され続ける期間を制限する |
| Protocol | 8ビット | データ部で運ぶプロトコルを示す |
| Header Checksum | 16ビット | ヘッダーの誤りを検出する |
| Source Address・Destination Address | 各32ビット | 送信元と宛先を示す |
| Options・Padding | 可変長 | 追加情報と長さをそろえる詰め物を置く |
当初のType of Serviceという8ビットの領域は、DSCPの6ビットとECNの2ビットとして使われる。DSCPは機器がどのような転送の扱いをするかを区別する値であり、ECNは対応する通信で混雑を通知するための仕組みである。値を付けるだけで経路全体の帯域や遅延が保証されるわけではない。仕様はRFC 2474とRFC 3168にある。
長さの読み方
IHLはヘッダー長を4バイト単位で表す。最小値5なら20バイト、最大値15なら60バイトである。オプションを付けると長くなり、必要に応じてパディングを入れて単位にそろえる。ヘッダーの長さを固定だと思って読むと、データ部の開始位置を取り違える。
Total LengthはIPヘッダーとデータを合わせた長さをバイト単位で表す。16ビットなので形式上の最大値は65,535バイトである。この値は実際のリンクで一度に送れる上限とは別であり、イーサネットのヘッダーや末尾のFCSも含まない。各フィールドの長さと検査上の注意はRFC 6274の3節にも整理されている。
例えばIHLが5、Total Lengthが84なら、データ部は84 − 5 × 4 = 64バイトである。これは上位プロトコルのヘッダーも含む長さであり、アプリケーションのデータがそのまま64バイトあるとは限らない。
中身の種類をどこで識別するか
Protocolフィールドにはデータ部の解釈に使う番号が入る。代表例はICMPが1、TCPが6、UDPが17である。IPv4パケットにICMPメッセージが入っていることは、このフィールドで識別する。番号の割当てはIANAのProtocol Numbersで管理されている。
| 情報の場所 | 何を識別するか | 例 |
|---|---|---|
| イーサネットのEtherType | フレームに格納した上位プロトコル | IPv4は0x0800、IPv6は0x86DD |
| IPv4のProtocol | IPデータ部のプロトコル | TCPやUDPなど |
| TCP・UDPのポート番号 | 通信を受け渡すアプリケーション側の接点 | HTTPSで用いる宛先ポート443など |
この三つは別々の階層にある。IPv4とIPv6を同じイーサネットで使っても、MACアドレスの長さが変わるわけではない。EtherTypeの値が異なる。格納方法はRFC 894とRFC 2464で定義されている。
パケットが転送され続けることを防ぐ
TTLはルータがパケットを転送するときに1以上減らす値である。元の定義は秒単位の生存時間だが、通常は転送のたびに減るため、通過できるルータの数を制限する値として働く。他の宛先へ転送するパケットの値が既に0だった場合や、転送のための減算で0になる場合は破棄する。ルータ自身を宛先とする受信と、他の宛先への転送は区別する必要がある。
TTLが尽きたユニキャストパケットには通常ICMPのTime Exceededが返る。ただし通知を抑制する条件や設定があるため、必ず送信元に通知が届くとは限らない。tracerouteはこの応答を利用して経路上の機器を調べる。TTLの転送時の扱いはRFC 1812の5.3.1節に定められている。
DNSにもTTLという名前の値があるが、こちらはキャッシュに情報を保持できる時間である。パケットの転送回数を制限する値とは用途が異なる。
誤りの検査とその限界
IPv4のヘッダーチェックサムが検査する範囲はヘッダーだけであり、データ部は含まない。計算ではチェックサムの欄をゼロとしてヘッダーを16ビット単位で加算し、桁上がりを折り返す1の補数和を求める。その結果のビットを反転した値を格納する。オプションもヘッダーに含まれるので検査対象になる。
転送時にはTTLが変化するため、ルータはチェックサムも更新する。毎回ヘッダー全体を最初から加算し直す実装に限らず、変更箇所に応じた差分更新も可能である。RFC 1624はその計算を扱っている。
TCPやUDPのチェックサムは、それぞれのヘッダーとデータに加えてIPアドレスなどから成る疑似ヘッダーも対象にする。IPv4上のUDPではチェックサムを使わないことをゼロで表せるが、TCPには同じ省略規則はない。両者の検査範囲はIPv4ヘッダーの検査範囲とは異なる。TCPはRFC 9293、UDPはRFC 768を参照できる。
チェックサムは通信中の誤りの検出に使うものであり、送信者の本人確認や攻撃者による改変の防止を保証するものではない。送信元アドレスが書かれていることも、その送信者が正当である証明にはならない。
リンクに収まらないパケットの扱い
送出先リンクのMTUを超えるIPv4パケットは、許可されていれば送信元や途中のルータがフラグメンテーションによって小さなパケットへ分割できる。分割後の一つ一つのパケットをフラグメントと呼ぶ。分割片ごとにIPv4ヘッダーが付き、Identificationなどによって同じ元パケットの断片を対応付ける。この識別子の要件は後にRFC 6864で更新されており、すべてのIPv4パケットに常に一意な通し番号を付けるという意味ではない。
| 情報 | 意味 |
|---|---|
| DF | 値が1なら分割を禁止する |
| MF | 値が1なら後続の分割片があることを示す |
| Fragment Offset | 元のデータ部での位置を8バイト単位で示す |
分割片を組み立て直すのは最終的な宛先であり、途中のルータで毎回元に戻すわけではない。元のデータ部の途中で区切る位置はオフセットで表せる必要があるため、最後以外の分割片のデータ長をその単位にそろえる。最後の断片はMFが0であり、分割していないパケットもMFが0なので、オフセットと合わせて読む。
分割片が一つでも欠ければ元のデータを完全に復元できない。IPv4自身には失った断片だけを要求して送り直させる仕組みはなく、必要な回復はTCPなどの上位側で行う。分割による障害や検査の難しさはRFC 8900に整理されている。
分割を避ける送信サイズの調整
DFが1のパケットを小さいMTUのリンクへ転送できないと、ルータはパケットを捨て、通常はICMPのDestination Unreachableのコード4で分割が必要なことを通知する。この通知とMTUの情報を使って送信元がサイズを調整する方式が、IPv4のパスMTU探索である。経路全体を通れる上限は、途中の各リンクのMTUの最小値で決まる。RFC 1191がこの方式を定義している。
例えば経路全体の上限が1,200バイトで、IPv4ヘッダーとTCPヘッダーがともにオプションなしの20バイトなら、分割なしで格納できるTCPデータは1,200 − 20 − 20 = 1160バイトである。MTUはIPヘッダーを含む上限、MSSはTCPのデータ部分の上限であり、同じ値ではない。実際の送信では相手が通知したMSS、経路の上限、使用するオプションなども考慮する。
必要なICMP通知が遮断されると、大きいパケットだけ通らず通信が止まる場合がある。小さいpingの成功だけではこの問題を除外できない。途中にトンネルがある場合も、追加されるヘッダーを考慮して利用可能な大きさを確認する。
IPv6と比べるときの要点
| 項目 | IPv4 | IPv6 |
|---|---|---|
| アドレス長 | 32ビット | 128ビット |
| 基本のヘッダー長 | 20〜60バイト | 40バイト。追加情報は拡張ヘッダーに置く |
| IPヘッダー自体のチェックサム | ある | ない |
| IP層での分割を行える機器 | 送信元と条件を満たす途中のルータ | 送信元だけ |
| ブロードキャスト | ある | ない |
| マルチキャスト | ある | ある |
IPv6ではTTLに相当する情報をHop Limitと呼ぶ。Protocolに近い役割のNext Headerは直後のヘッダーの種類を示すため、TCPなどを直接指す場合も、拡張ヘッダーを指す場合もある。名前だけを置き換えてIPv4と同じ形式だと考えないことが大切である。IPv6側の規定はRFC 8200を参照できる。
IPv4ではアドレス数の制約に対応するためNATやNAPTが利用されるが、これはヘッダーの書換えなどを行う別の機能である。IPv4の形式や基本的な配送規則を理解した上で、アドレス変換やフィルタが通信に与える影響を確認する必要がある。