IPv4
この記事は査読付きジャーナル「WikiJournal of Science」（2022年）に掲載されました。掲載版を見るにはクリックしてください。
インターネットプロトコルバージョン4
プロトコルスタック
IPv4パケット
略語IPv4
目的インターネットワーキングプロトコル
開発者DARPA
はじめに1980 （1980年）
影響を受けたIPv6
OSI層ネットワーク層
RFC 760、791

インターネットプロトコルバージョン4（IPv4 ）は、スタンドアロン仕様としてのインターネットプロトコル（IP）の最初のバージョンです。インターネットやその他のパケット交換ネットワークにおける標準ベースのインターネットワーキング方式の中核プロトコルの1つです。IPv4は、 1982年にSATNETで、1983年1月にARPANETで実稼働用に導入された最初のバージョンです。後継である インターネットプロトコルバージョン6（IPv6）[ 2 ]の導入が進んでいるにもかかわらず、今日でもほとんどのインターネットトラフィックのルーティングに使用されています[ 1 ]

IPv4は32ビットのアドレス空間を使用し、4,294,967,296（2の32乗）個の一意のアドレスを提供しますが、大きなブロックは特別なネットワーク用途のために予約されています。[ 3 ] [ 4 ]この一意のアドレスの量は、グローバルインターネットのニーズを満たすには十分ではなく、 IPv6への移行中に IPv4アドレス枯渇と呼ばれる重大な問題を引き起こしています。

目的

インターネットプロトコル（「IP」）は、インターネットプロトコルスイートのインターネット層におけるインターネットワーキングを定義し、実現するプロトコルです。IPはインターネットにグローバル規模の論理アドレスシステムを提供し、送信元ホストから別のネットワーク上の宛先ホスト に1ホップ近い次のルータへのIPデータパケットのルーティングを可能にします。

IPv4はコネクションレス型プロトコルであり、ベストエフォート型の配信モデルに基づいて動作します。つまり、配信を保証するものではなく、適切な順序付けや重複配信の回避も保証しません。これらの問題は、伝送制御プロトコル（TCP）やQUICプロトコルなどの上位層トランスポートプロトコルによって解決される場合があります。

歴史

以前のバージョンのTCP/IPは、TCP/IPv3を通じて統合された仕様でした。IPv4では、インターネットプロトコルは独立した仕様になりました。[ 5 ]

インターネットプロトコルバージョン4は、IETF出版物RFC 791（1981年9月）で規定されており、1980年1月の定義（RFC 760）に取って代わりました。1982年3月、米国国防総省は、インターネットプロトコルスイート（TCP/IP）をすべての軍事コンピュータネットワークの標準として決定しました。[ 6 ]

アドレス空間枯渇

IPv4アドレス枯渇タイムライン

1980年代後半、利用可能なIPv4アドレスのプールが、ネットワークの当初の設計では想定されていなかった速度で枯渇していることが明らかになりました。[ 7 ] 1990年代以降、アドレス枯渇を加速させた主な市場要因には、インターネット利用者の急増が挙げられます。彼らは、ラップトップコンピューター、携帯情報端末（PDA）、 IPデータサービスを備えたスマートフォンなどのモバイルコンピューティングデバイスをますます利用していました。さらに、高速インターネットアクセスは常時接続デバイスに基づいていました。枯渇の脅威は、次のような多くの救済技術の導入を促しました

1990 年代半ばまでに、NAT は、地域およびローカルのインターネット レジストリでの厳格な使用量ベースの割り当てポリシーとともに、ネットワーク アクセス プロバイダー システムで広く使用されるようになりました。

IANAによって管理されていたインターネットの主要なアドレスプールは、2011年2月3日に最後の5つのブロックが5つのRIRに割り当てられた時点で枯渇した。[ 8 ] [ 9 ] APNICは、2011年4月15日に地域アドレスプールを使い果たした最初のRIRである。ただし、IPv6への移行技術のために予約された少量のアドレス空間は制限付きポリシーの下で割り当てられる予定であった。[ 10 ]

アドレス枯渇に対する長期的な解決策は、1998年にインターネットプロトコルの新しいバージョンであるIPv6の仕様が定められたことであった。[ 11 ] IPv6はアドレス空間を大幅に拡大するだけでなく、インターネット上の経路集約を改善し、エンドユーザーに最低2の64のホストアドレスの大規模なサブネット割り当てを提供する。しかし、IPv4はIPv6と直接相互運用できないため、IPv4のみのホストはIPv6のみのホストと直接通信できない。2004年に6bone実験ネットワークの段階的な廃止が始まり、IPv6の恒久的な正式な導入は2006年に開始された。[ 12 ] IPv6導入の完了にはかなり時間がかかると予想されているため、[ 13 ]ホストが両方のバージョンのプロトコルを使用してインターネットに参加できるようにするには、中間の移行技術が必要となる。

アドレス指定

4つのドットで区切られたIPv4アドレス表現を2進値に分解する

IPv4 は 32 ビットのアドレスを使用するため、アドレス空間は4,294,967,296 ( 2 32 )個のアドレス に制限されます。

IPv4 は、プライベート ネットワーク(2 24  + 2 20  + 2 16  ≈ 1,800 万アドレス) とマルチキャストアドレス (2 28  ≈ 2 億 6,800 万アドレス) 用に特別なアドレス ブロックを予約しています。

アドレス表現

IPv4アドレスは、32ビットの整数値を表す任意の表記法で表すことができます。ほとんどの場合、ドット10進表記法で記述されます。 これは、アドレスの4つのオクテットを10進数（先頭のゼロなし）で個別に表現し、ピリオドで区切ったものです

たとえば、図の 4 つのドットで区切られた IP アドレス ( 172.16.254.1 ) は、32 ビットの 10進数 2886794753 を表し、16 進形式では 0xAC10FE01 になります。

CIDR 表記は、アドレスとルーティング プレフィックスをコンパクトな形式で組み合わせたもので、アドレスの後にスラッシュ文字 (/) が続き、ルーティング プレフィックスの 先頭の連続する1ビットの数 (サブネット マスク) が続きます。

クラスフルネットワークが実践されていた時代は、他のアドレス表現が一般的に使用されていました。例えば、ループバックアドレス127.0.0.1は、ネットワークマスクが8ビット、ホスト番号が24ビットのクラスAネットワークに属するため、一般的に127.1と表記されていました。ドット表記のアドレスに4つ未満の数値が指定された場合、最後の値は、アドレスを4オクテットで埋めるのに必要なバイト数の整数として扱われました。したがって、アドレス127.65530は127.0.255.250と等しくなります。

割り当て

IPv4の当初の設計では、IPアドレスは2つの部分に分かれていました。ネットワーク識別子はアドレスの最上位オクテットであり、ホスト識別子はアドレスの残りの部分でした。後者はレストフィールドとも呼ばれていました。この構造では最大256個のネットワーク識別子が許可されていましたが、すぐに不十分であることが判明しました

この制限を克服するため、1981年に最上位アドレスオクテットが再定義され、後にクラスフルネットワークとして知られるようになったネットワーククラスが作成されました。改訂されたシステムでは5つのクラスが定義されました。クラスA、B、Cは、ネットワーク識別のためにそれぞれ異なるビット長を持ちました。アドレスの残りの部分は、これまでと同様にネットワーク内のホストを識別するために使用されました。クラスごとにフィールドのサイズが異なるため、各ネットワーククラスはホストのアドレス指定能力が異なっていました。ホストのアドレス指定用の3つのクラスに加えて、クラスDはマルチキャストアドレス指定用に定義され、クラスEは将来のアプリケーションのために予約されていました。

既存のクラスフルネットワークをサブネットに分割する作業は、1985年にRFC 950の出版によって始まりました。この分割は、1987年にRFC 1109で可変長サブネットマスク (VLSM) が導入されたことで、より柔軟になりました。1993年には、この作業に基づいて、 RFC 1517でクラスレスドメイン間ルーティング(CIDR) [ 14 ]が導入されました。これは、ビット数 (最上位から) をたとえば/24のように表現し、クラスベースのスキームに対して、クラスフルと呼ばれました。CIDR は、より小さいまたはより大きいアドレスブロックをユーザーに割り当てることができるように、アドレス空間の再分割を可能にするように設計されました。CIDR によって作成される階層構造は、インターネット割り当て番号機関(IANA) と地域インターネットレジストリ(RIR)によって管理されています。    

特別用途アドレス

インターネット技術タスクフォース（IETF）とIANAは、特別な目的のために予約された様々なIPアドレスの一般使用を制限しています。[ 4 ]特にこれらのアドレスはマルチキャストトラフィックに使用され、プライベートネットワーク上で無制限に使用できるアドレス空間を提供するために使用されます。

特別なアドレスブロック
アドレスブロック（CIDR） アドレス範囲 アドレス数 スコープ 説明
0.0.0.0/8 0.0.0.0～0.255.255.255 16 777 216ソフトウェア 現在の（ローカル、「この」）ネットワーク[ 4 ]
10.0.0.0/8 10.0.0.0～10.255.255.255 16 777 216プライベートネットワーク プライベートネットワーク内のローカル通信に使用されます[ 15 ]
100.64.0.0/10 100.64.0.0～100.127.255.255 4 194 304プライベートネットワーク キャリアグレードNATを使用する場合のサービスプロバイダとその加入者間の通信のための共有アドレス空間[ 16 ]
127.0.0.0/8 127.0.0.0～127.255.255.255 16 777 216ホスト ローカルホストへのループバックアドレスとして使用[ 4 ]
169.254.0.0/16 169.254.0.0～ 65536サブネット 単一リンク上の2つのホスト間のリンクローカルアドレス[ 17 ]に使用される。IPアドレスが指定されていない場合、通常はDHCPサーバー から取得される
172.16.0.0/12 172.16.0.0–172.31.255.255 1048576プライベートネットワーク プライベートネットワーク内のローカル通信に使用されます[ 15 ]
192.0.0.0/24 192.0.0.0～192.0.0.255 256プライベートネットワーク IETFプロトコル割り当て、DS-Lite (/29) [ 4 ]
192.0.2.0/24 192.0.2.0～192.0.2.255 256ドキュメント TEST-NET-1として割り当てられ、ドキュメントとサンプル[ 18 ]
192.88.99.0/24 192.88.99.0～192.88.99.255 256インターネット 予約済み。[ 19 ]以前はIPv6からIPv4へのリレーに使用されていました[ 20 ]（IPv6アドレスブロック2002::/16を含む）。
192.168.0.0/16 192.168.0.0～192.168.255.255 65536プライベートネットワーク プライベートネットワーク内のローカル通信に使用されます[ 15 ]
198.18.0.0/15 198.18.0.0～198.19.255.255 131 072プライベートネットワーク 2つの異なるサブネット間のネットワーク間通信のベンチマークテストに使用されます[ 21 ]
198.51.100.0/24 198.51.100.0～198.51.100.255 256ドキュメント TEST-NET-2として割り当てられており、ドキュメントとサンプルは[ 18 ]です
203.0.113.0/24 203.0.113.0～203.0.113.255 256ドキュメント TEST-NET-3として割り当てられ、ドキュメントとサンプルは[ 18 ]
224.0.0.0/4 224.0.0.0–239.255.255.255 268 435 456インターネット マルチキャストで使用[ 22 ]（旧クラスDネットワーク）
233.252.0.0/24 233.252.0.0～233.252.0.255 256ドキュメント MCAST-TEST-NETとして割り当てられ、ドキュメントと例（これは上記のマルチキャスト空間の一部です。）[ 22 ] [ 23 ]
240.0.0.0/4 240.0.0.0–255.255.255.254 268 435 455インターネット 将来の使用のために予約済み[ 24 ] (旧クラスEネットワーク)
255.255.255.255/32 255.255.255.255 1サブネット 「限定ブロードキャスト」宛先アドレス用に予約されている[ 4 ]

プライベートネットワーク

IPv4で定義されている約40億のアドレスのうち、RFC 1918で概説されているように、3つの範囲から約1800万のアドレスがプライベートネットワーク用に予約されています。これらの範囲のアドレスを持つパケットは、パブリックインターネットではルーティングできず、すべてのパブリックルーターによって無視されます。したがって、プライベートホストはパブリックネットワークと直接通信することはできず、この目的のためにルーティングゲートウェイでの ネットワークアドレス変換が必要です

予約済みのプライベートIPv4ネットワーク範囲[ 15 ]
名前CIDRブロックアドレス範囲アドレス数上品な説明
24ビットブロック10.0.0.0/810.0.0.0 – 10.255.255.25516 777 216シングルクラスA
20ビットブロック172.16.0.0/12172.16.0.0 – 172.31.255.255 104857616個のクラスBブロックの連続範囲
16ビットブロック192.168.0.0/16192.168.0.0 – 192.168.255.255 65536連続した256個のクラスCブロック

2つのプライベートネットワーク（例えば、2つの支社）は、パブリックインターネットを介して直接相互運用できないため、2つのネットワークは、仮想プライベートネットワーク（VPN）またはIPトンネルを介してインターネットを介してブリッジされる必要があります。IPトンネルは、パブリックネットワークを介した伝送中に、プライベートアドレスを含むヘッダーを含むパケットをプロトコル層でカプセル化します。さらに、カプセル化されたパケットは、データのセキュリティを確保するために、パブリックネットワークを介した伝送時に暗号化されることがあります。

RFC 3927は、リンクローカルアドレス指定用の特別なアドレスブロック169.254.0.0/16を定義しています。これらのアドレスは、それらを使用するホストに直接接続されたリンク（ローカルネットワークセグメントやポイントツーポイント接続など）上でのみ有効です。これらのアドレスはルーティングできません。プライベートアドレスと同様に、これらのアドレスはインターネットを通過するパケットの送信元または宛先になることはできません。これらのアドレスは主に、ホストがDHCPサーバーまたはその他の内部設定方法からIPアドレスを取得できない場合に、アドレス自動設定（Zeroconf） に使用されます

アドレスブロックが予約されていた当時、アドレスの自動構成に関する標準は存在しませんでした。MicrosoftはAutomatic Private IP Addressing (APIPA)と呼ばれる実装を開発し、これは数百万台のマシンに導入され、事実上の標準となりました。それから数年後の2005年5月、IETFはRFC 3927で「IPv4リンクローカルアドレスの動的構成」という正式な標準を定義しました。

ループバック

クラスAネットワーク127.0.0.0（クラスレスネットワーク127.0.0.0 / 8）はループバック用に予約されています。このネットワークに属する送信元アドレスを持つIPパケットは、ホストの外部に現れてはなりません。ループバックの送信元または宛先アドレスを持つ非ループバックインターフェースで受信されたパケットは、破棄する必要があります

最初と最後のサブネットアドレス

すべてのサブネットにおいて、すべてゼロのホストアドレスとすべて1のホストアドレスの両方が予約されています。[ 25 ] [ 26 ]すべてゼロのホストアドレスは、特定のサブネットを識別するために使用されます。すべてのホストビットが1に設定された、各サブネットの最上位アドレスは、サブネット上のすべてのデバイスに同時にメッセージを送信するためのローカルブロードキャストアドレスです。ネットワークサイズが/ 24以上の場合、ドット付き10進表記のブロードキャストアドレスは常に255で終わります。

例えば、サブネット192.168.5.0 / 24（サブネットマスク255.255.255.0）では、識別子192.168.5.0はサブネット全体を参照するために使用されます。ネットワークのブロードキャストアドレスは192.168.5.255です。

型2進形式ドット10進表記
ネットワーク空間 11000000.10101000.00000101.00000000192.168.5.0
ブロードキャストアドレス 11000000.10101000.00000101.11111111192.168.5.255
赤色で示されているのはIPアドレスのホスト部分で、もう一方の部分はネットワークプレフィックスです。ホスト部分は反転（論理否定）されますが、ネットワークプレフィックスはそのまま残ります

ただし、0 または 255 で終わるすべてのアドレスがホストアドレスとして使用できないわけではありません。例えば、/ 16サブネット192.168.0.0 / 255.255.0.0は、アドレス範囲192.168.0.0～192.168.255.255に相当しますが、ブロードキャストアドレスは192.168.255.255です。192.168.1.255、192.168.2.255などは、末尾が 255 であってもホストアドレスとして使用できます。また、192.168.0.0はネットワーク識別子であり、インターフェースに割り当てることはできません。[ 27 ] : 31 192.168.1.0、192.168.2.0などのアドレスは、0で終わっていても割り当てられることがあります。

過去には、一部のソフトウェアが1ではなく0を含む非標準のブロードキャストアドレスを使用していたため、ネットワークアドレスとブロードキャストアドレスの競合が発生しました。[ 27 ]：66

/ 24より小さいネットワークでは、ブロードキャスト アドレスは必ずしも 255 で終わるわけではありません。たとえば、CIDR サブネット203.0.113.16 / 28 のブロードキャスト アドレスは203.0.113.31です。

型2進形式ドット10進表記
ネットワーク空間 11001011.00000000.01110001.00010000203.0.113.16
ブロードキャストアドレス 11001011.00000000.01110001.00011111203.0.113.31
赤色で示されているのはIPアドレスのホスト部分で、もう一方の部分はネットワークプレフィックスです。ホスト部分は反転（論理否定）されますが、ネットワークプレフィックスはそのまま残ります

特殊なケースとして、/ 31ネットワークは2台のホストのみを収容できます。これらのネットワークは通常、ポイントツーポイント接続に使用されます。これらのネットワークには、ネットワーク識別子やブロードキャストアドレスは存在しません。[ 28 ]

アドレス解決

インターネット上のホストは通常​​、www.example.comなどの名前で知られており、ルーティングやネットワークインターフェースの識別に使用されるIPアドレスでは主に認識されません。ドメイン名を使用するには、ドメイン名をアドレスに変換（解決）する必要があり、その逆も同様です。これは、電話帳で受信者の名前を使って電話番号を調べるのに似ています

アドレスとドメイン名間の変換は、他の DNS サーバーへの 名前空間の委任を可能にする階層型の分散命名システムであるドメイン ネーム システム(DNS) によって実行されます。

番号なしインターフェース

番号なしポイントツーポイント（PtP）リンクは、トランジットリンクとも呼ばれ、IPネットワーク番号やサブネット番号が関連付けられていないものの、IPアドレスを持つリンクです。1993年に初めて導入され、[ 29 ] [ 30 ] [ 31 ] [ 32 ]クアルコムのフィル・カーンが最初の設計者として知られています。

トランジットリンクの目的は、データグラムをルーティングする ことです。トランジットリンクは、不足しているIPアドレス空間からIPアドレスを解放したり、IPアドレスの割り当てやインターフェースの設定管理を軽減したりするために使用されます。以前は、各リンクで、ポイントツーポイントリンクごとに2つまたは4つのIPアドレスを使用して、/ 31または/ 30サブネットを専用化する必要がありました。リンクがアンナンバードの場合、定義済みのインターフェース（通常はループバックインターフェース）から借りた単一のIPアドレスであるルータIDが使用されます。同じルータIDを複数のインターフェースで使用できます。

番号なしインターフェースの欠点の 1 つは、リモート テストと管理が難しくなることです。

パケット構造

IPパケットはヘッダー部とデータ部で構成されます。IPパケットには、データ部の後にデータチェックサムやその他のフッターはありません。通常、リンク層は、ほとんどのエラーを検出するCRCフッターを使用して、IPパケットをフレームにカプセル化します。IPによって伝送される多くのトランスポート層プロトコルも独自のエラーチェック機能を備えています。[ 33 ]：§6.2

IPv4パケットヘッダーは14のフィールドで構成され、そのうち13は必須です。14番目のフィールドはオプションで、その名の通りオプションです。ヘッダー内のフィールドは最上位バイトから順にパックされ（ネットワークバイトオーダー）、図と説明では最上位ビットが最初に来るものとされています（MSB 0ビット番号）。最上位ビットは0に番号付けされているため、例えばバージョンフィールドは実際には最初のバイトの最上位4ビットにあります

IPv4ヘッダーフォーマット
オフセットオクテット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)国際人道法DSCPECN全長
4 32 識別フラグフラグメントオフセット
8 64 生存時間プロトコルヘッダーチェックサム
12 96 送信元アドレス
16 128 宛先アドレス
20 160 （選択肢）（IHL > 5の場合）
⋮ ⋮
56 448
バージョン：4ビット
IPパケットの最初のヘッダーフィールドはバージョンフィールドです。IPv4の場合、これは常に4です
インターネットヘッダー長 （IHL）: 4ビット
IPv4ヘッダーのサイズは、オプションの14番目のフィールド（オプション）によって可変です。IHLフィールドにはIPv4ヘッダーのサイズが格納されます。このフィールドは4ビットで構成され、ヘッダー内の32ビットワード数を指定します。このフィールドの最小値は5（[ 34 ]）で、これは5 × 32ビット = 160ビット = 20バイトの長さを示します。4ビットフィールドであるため、最大値は15です。つまり、IPv4ヘッダーの最大サイズは15 × 32ビット = 480ビット = 60バイトです。
差別化サービスコードポイント （DSCP ): 6ビット
元々はサービスタイプ（ToS）として定義されていたこのフィールドは、差別化サービス（DiffServ）を指定します。[ 35 ]リアルタイムデータストリーミングではDSCPフィールドが使用されます。例えば、双方向音声サービスに使用されるVoice over IP （VoIP）が挙げられます。
明示的輻輳通知 （ECN ): 2ビット
このフィールドは、パケットをドロップすることなく、ネットワーク輻輳のエンドツーエンド通知を可能にします。[ 36 ] ECNは、両方のエンドポイントがサポートしている場合に利用可能なオプション機能であり、基盤となるネットワークでもサポートされている場合に有効です。
全長: 16ビット
この16ビットフィールドは、ヘッダーとデータを含むパケット全体のサイズをバイト単位で定義します。最小サイズは20バイト（データなしのヘッダー）、最大サイズは65,535バイトです。すべてのホストは最大576バイトのデータグラムを再構成できる必要がありますが、最近のホストのほとんどははるかに大きなパケットを処理できます。リンクによってパケットサイズにさらなる制限が課される場合があり、その場合はデータグラムをフラグメント化する必要があります。IPv4におけるフラグメント化は、送信ホストまたはルーターで実行されます。再構成は受信ホストで実行されます。
識別：16ビット
このフィールドは識別フィールドであり、主に単一のIPデータグラムを構成するフラグメント群を一意に識別するために使用されます。一部の実験的研究では、IDフィールドを他の目的、例えば偽装された送信元アドレスを持つデータグラムの追跡を支援するためのパケット追跡情報の追加などに使用することが提案されていますが[ 37 ]、現在ではそのような使用は禁止されています[ 38 ] 。
フラグ: 3ビット
このフィールドには 3 つのフラグが定義されています。
予約済み （R）：1ビット
予約済み。0に設定してください。[ a ]
断片化しない （DF）：1ビット
このフィールドは、データグラムがフラグメント化可能かどうかを指定します。フラグメントの再構成を実行するリソースを持たないホストにパケットを送信する場合に使用できます。また、ホストのIPソフトウェアによって自動的に、またはpingやtracerouteなどの診断ツールを使用して手動で、パスMTU検出にも使用できます。DFフラグが設定されており、パケットのルーティングにフラグメント化が必要な場合、パケットは破棄されます。
より多くのフラグメント （MF）：1ビット
フラグメント化されていないパケットの場合、MFフラグはクリアされます。フラグメント化されたパケットの場合、最後のフラグメントを除くすべてのフラグメントにMFフラグが設定されます。最後のフラグメントにはフラグメントオフセットフィールドが0以外の値を持つため、フラグメント化されていないパケットと区別できます。
フラグメントオフセット: 13ビット
このフィールドは、フラグメントされていない元の IP データグラムの先頭からの特定のフラグメントのオフセットを指定します。フラグメントは 8 バイト単位で指定されるため、フラグメント長は常に 8 の倍数になります。ただし、最後のフラグメントは 8 より小さくなる場合があります。[ 40 ]最初のフラグメントのフラグメントオフセット値は常に 0 です。このフィールドは 13 ビット幅であるため、オフセット値の範囲は 0 ～ 8191 ((20-1 )～ (213-1 )  ) です。したがって、最大フラグメントオフセットは (213-1 )  × 8 = 65,528 バイト (ヘッダー長を含む) (65,528 + 20 = 65,548 バイト) となり、最大 IP 長の 65,535 バイトを超えるパケットのフラグメント化をサポートします。
生存時間 （TTL ): 8ビット
TTLフィールドは、ルーティングループが発生した場合にネットワーク障害を防ぐため、データグラムの存続時間を制限します。これは秒単位で指定されますが、1秒未満の時間間隔は1に切り上げられます。実際には、このフィールドはホップカウントとして使用されます。データグラムがルーターに到着すると、ルーターはTTLフィールドの値を1減らします。TTLフィールドの値が0になると、ルーターはパケットを破棄し、通常は送信者にICMPのtime exceededメッセージを送信します。
トレースルートプログラムは、調整された TTL 値を持つメッセージを送信し、これらの ICMP 時間超過メッセージを使用して、送信元から宛先までのパケットが通過するルーターを識別します。
プロトコル: 8ビット
このフィールドは、IPデータグラムのデータ部分で使用されるトランスポート層プロトコルを定義します。IPプロトコル番号のリストは、インターネット割り当て番号局（IANA）によって管理されています。[ 24 ]
一般的なペイロード プロトコルには次のようなものがあります。
プロトコル番号プロトコル名略語
1インターネット制御メッセージプロトコルICMP
2インターネットグループ管理プロトコルIGMP
6伝送制御プロトコルTCP
17ユーザデータグラムプロトコルUDP
41IPv6カプセル化ENCAP
89オープン最短経路優先OSPF
132ストリーム制御伝送プロトコルSCTP
ヘッダーチェックサム：16ビット
IPv4ヘッダーチェックサムフィールドは、ヘッダーのエラーチェックに使用されます。パケットを送信する前に、ヘッダー内のすべての16ビットワードの1の補数の合計の16ビットの1の補数としてチェックサムが計算されます。これには、計算中にゼロに設定されるヘッダーチェックサムフィールド自体も含まれます。パケットは、結果の値を含むヘッダーチェックサムとともに送信されます。パケットがルーターまたは宛先に到着すると、ネットワークデバイスはヘッダーのチェックサム値を再計算し、ヘッダーチェックサムフィールドも含めます。結果はゼロになるはずです。異なる結果が得られた場合、デバイスはパケットを破棄します
パケットがルーターに到着すると、ルーターはヘッダーのTTLフィールドを減算します。その結果、ルーターはパケットを再送信する前に、新しいヘッダーチェックサムを計算する必要があります。
パケットのデータ部分におけるエラーは、カプセル化されたプロトコルによって個別に処理されます。UDPとTCPはどちらも、データに適用される個別のチェックサムを持っています。
送信元アドレス: 32ビット
このフィールドには、パケットの送信元のIPv4アドレスが含まれます。このアドレスは、ネットワークアドレス変換（NAT）によって転送中に変更される場合があります。
宛先アドレス: 32ビット
このフィールドには、パケットの宛先となるIPv4アドレスが含まれます。NATの影響を受ける場合もあります。
宛先に直接到達できる場合、パケットはARPを利用して下位のリンク層によって配送されます。そうでない場合、パケットはルーティングが必要となり、代わりにゲートウェイアドレスに配送されます。
オプション: 0 - 320 ビット、32 ビットの倍数にパディング
オプションフィールドはあまり使用されません。一部のオプションを含むパケットは、一部のルータによって危険とみなされ、ブロックされる可能性があります。 [ 41 ] IHLフィールドの値には、すべてのオプションと、ヘッダーに整数個の32ビットワードが含まれるようにするために必要なパディングを格納するのに十分な追加の32ビットワードを含める必要があります。IHLが5より大きい場合（つまり、6から15の場合）、オプションフィールドが存在し、考慮する必要があることを意味します。オプションのリストは、オプションEOOL（オプションリストの終了、0x00）で終了できます。これは、オプションの終了がヘッダーの終了と一致しない場合にのみ必要です。
ほとんどのIPオプションには、パケットが通過する中間デバイスの数や種類に関する指定が含まれているため、インターネットを介した通信にはIPオプションは使用されず、一部のIPオプションを含むIPパケットは、ネットワークトポロジやネットワークの詳細が公開される可能性があるため、削除する必要があります。[ 42 ]：§3.13

断片化と再構成

インターネットプロトコルは、ネットワーク間のトラフィックを可能にします。その設計は、物理的に多様なネットワークに対応し、リンク層で使用される基盤となる伝送技術とは独立しています。異なるハードウェアを持つネットワークは、通常、伝送速度だけでなく、最大転送単位（MTU）も異なります。あるネットワークがMTUの小さいネットワークにデータグラムを送信する場合、データグラムを断片化することがあります。IPv4では、この機能はインターネット層に配置され、IPv4ルーターで実行されるため、ホストがこれらの問題にさらされる可能性が制限されます

対照的に、次世代のインターネット プロトコルであるIPv6 では、ルータによるフラグメンテーションが許可されず、ホストはデータグラムを送信する前にパス MTU 検出を実行する必要があります。

フラグメンテーション

ルーターはパケットを受信すると、宛先アドレスを調べ、使用する送信インターフェースとそのインターフェースのMTUを決定します。パケットサイズがMTUよりも大きく、パケットヘッダーのDo Not Fragment（DF）ビットが0に設定されている場合、ルーターはパケットをフラグメント化することがあります

ルータはパケットをフラグメントに分割します。各フラグメントの最大サイズは、送信MTUからIPヘッダーサイズ（最小20バイト、最大60バイト）を差し引いた値です。ルータは各フラグメントを独自のパケットに分割し、各フラグメントパケットには以下の変更が加えられます。

  • 合計長フィールドはフラグメントのサイズです。
  • 最後のフラグメントを除くすべてのフラグメントに対して、More Fragments (MF) フラグが設定されます。最後のフラグメントは 0 に設定されます。
  • フラグメントオフセットフィールドは、元のデータペイロード内のフラグメントのオフセットに基づいて設定されます。これは8バイトブロック単位で測定されます。
  • ヘッダーチェックサムフィールドが再計算されます。

たとえば、MTU が 1,500 バイトでヘッダー サイズが 20 バイトの場合、フラグメント オフセットは(0、185、370、555、740 など) の倍数になります。 1,500−208＝185{\displaystyle {\frac {1{,}500-20}{8}}=185}

あるルーターでパケットがフラグメント化され、そのフラグメントが別のルーターでさらにフラグメント化される可能性があります。例えば、20バイトのIPヘッダーを含む4,520バイトのパケットが、MTUが2,500バイトのリンク上で2つのパケットにフラグメント化されるとします。

フラグメント サイズ（バイト）ヘッダーサイズ（バイト）データサイズ（バイト）フラグその他のフラグメントフラグメントオフセット（8バイトブロック）
1 2,500 20 2,480 1 0
2 2,040 20 2,020 0 310

合計データサイズは維持されます：2,480バイト + 2,020バイト = 4,500バイト。オフセットはとです 0{\displaystyle 0}0＋2,4808＝310{\displaystyle {\frac {0+2{,}480}{8}}=310}

MTU が 1,500 バイトのリンクに転送されると、各フラグメントは 2 つのフラグメントに分割されます。

フラグメント サイズ（バイト）ヘッダーサイズ（バイト）データサイズ（バイト）フラグその他のフラグメントフラグメントオフセット（8バイトブロック）
1 1,500 20 1,480 1 0
2 1,020 20 1,000 1 185
3 1,500 20 1,480 1 310
4 560 20 540 0 495

ここでもデータサイズは維持されます。1,480 + 1,000 = 2,480、1,480 + 540 = 2,020

この場合も、More Fragmentsビットは、1が設定されているすべてのフラグメントに対して1のままであり、到着した最後のフラグメントについては通常通り動作します。つまり、MFビットは最後のフラグメントのみに0に設定されます。そしてもちろん、Identificationフィールドは、再フラグメント化されたすべてのフラグメントで同じ値を保持し続けます。これにより、フラグメントが再フラグメント化された場合でも、受信側はそれらがすべて同じパケットから開始されたことを認識できます。

最後のオフセットと最後のデータ サイズは、合計データ サイズの計算に使用されます。 495×8＋540＝3,960＋540＝4,500{\displaystyle 495\times 8+540=3{,}960+540=4{,}500}

再構成

以下の条件の少なくとも1つが満たされている場合、受信側はパケットがフラグメントであることを認識します

  • フラグmore fragmentsが設定されており、これは最後のフラグメントを除くすべてのフラグメントに当てはまります。
  • フィールドフラグメント オフセットはゼロ以外であり、これは最初のフラグメントを除くすべてのフラグメントに当てはまります。

受信側は、送信元アドレスと宛先アドレス、プロトコルID、および識別フィールドを使用して、一致するフラグメントを識別します。受信側は、フラグメントオフセットとmorefragmentsフラグの両方を使用して、同じIDを持つフラグメントからデータを再構成します。morefragmentsフラグが0に設定されている最後のフラグメントを受信すると、受信側は最後のフラグメントのオフセットに8を掛け、最後のフラグメントのデータサイズを加算することで、元のデータペイロードのサイズを計算できます。この例では、この計算はバイト単位です。受信側がすべてのフラグメントを取得したら、オフセットに従って正しい順序で再構成し、元のデータグラムを形成できます。 495×8＋540＝4,500{\displaystyle 495\times 8+540=4{,}500}

補助プロトコル

IP アドレスはネットワーク ハードウェアに永続的に結び付けられているわけではなく、実際、最近のオペレーティング システムでは、ネットワーク インターフェイスが複数の IP アドレスを持つことができます。リンク上の宛先ホストに IP パケットを適切に配信するために、ホストとルータには、ネットワーク インターフェイスのハードウェア アドレス[ b ]と IP アドレスとの関連付けを行う追加のメカニズムが必要です。アドレス解決プロトコル(ARP) は、IPv4 に対してこの IP アドレスからハードウェア アドレスへの変換を実行します。さらに、逆相関も多くの場合必要になります。たとえば、管理者によってアドレスが事前に構成されていない限り、IP ホストを起動するかネットワークに接続すると、その IP アドレスを決定する必要があります。このような逆相関のプロトコルには、動的ホスト構成プロトコル(DHCP)、ブートストラップ プロトコル(BOOTP)、およびまれに逆 ARP などがあります。

参照

注釈

  1. ^エイプリルフールのジョークとして、RFC 3514で「 Evilビット」として提案されました[ 39 ]
  2. ^イーサネットを含むIEEE 802ネットワーク テクノロジの場合、ハードウェア アドレスはMAC アドレスです。

参考文献

この記事は、 CC BY 4.0ライセンス（2022年）に基づき、以下の情報源から改変したものです。Michel Bakni、Sandra Hanbo（2022年）。「インターネットプロトコルバージョン4 （ IPv4）に関する調査」（PDF）。WikiJournal of Science。doi：10.15347 /WJS/2022.002。ISSN 2470-6345。OCLC 9708517136。S2CID 254665961。Wikidata Q104661268    

  1. ^ 「BGP分析レポート」 . BGPレポート. 2013年1月9日閲覧。
  2. ^ 「IPv6 – Google」 . www.google.com . 2022年1月28日閲覧。
  3. ^ 「IANA IPv4特殊目的アドレスレジストリ」 . www.iana.org . 2022年1月28日閲覧。
  4. ^ a b c d e f M. Cotton; L. Vegoda; B. Haberman (2013年4月). R. Bonica (編).特殊用途IPアドレスレジストリ.インターネット技術タスクフォース. doi : 10.17487/RFC6890 . ISSN 2070-1721 . BCP 153. RFC 6890 . 現在 のベストプラクティス153。RFC 4773、5156、5735、5736は  廃止。RFC 8190により更新。​
  5. ^ Davis, Lidija (2009年2月21日). 「Vint Cerf - We Still Have 80 Percent of the World to Connect」 . The New York Times . 2024年5月10日閲覧。
  6. ^ 「IPv4の簡潔な歴史」 . IPv4 Market Group . 2020年8月19日閲覧。
  7. ^ 「世界でインターネットアドレスが不足」. 2011年1月25日時点のオリジナルよりアーカイブ。2011年1月23日閲覧。
  8. ^ Smith, Lucie; Lipner, Ian (2011年2月3日). 「IPv4アドレス空間の空きプールが枯渇」 . Number Resource Organization . 2011年2月3日閲覧。
  9. ^ ICANN、nanogメーリングリスト。「RIRに5つの/8が割り当てられました。未割り当てのIPv4ユニキャスト/8は残っていません。 」
  10. ^ Asia-Pacific Network Information Centre (2011年4月15日). 「APNIC IPv4アドレスプールが最終/8に到達」 . 2011年8月7日時点のオリジナルよりアーカイブ。2011年4月15日閲覧。
  11. ^ S. Deering ; R. Hinden (1998年12月).インターネットプロトコルバージョン6（IPv6）仕様. ネットワークワーキンググループ. doi : 10.17487/RFC2460 . RFC 2460 .廃止。RFC 8200  により廃止。RFC 1883を 廃止。RFC 5095、5722、5871、6437、6564、6935、6946、7045、7112 により更新。​​​​​​​​​​​​​
  12. ^ R. Fink; R. Hinden (2004年3月). 6bone (IPv6 Testing Address Allocation) Phase-out . Network Working Group. doi : 10.17487/RFC3701 . RFC 3701 .情報提供。RFC 2471を  廃止します。
  13. ^ 2016 IEEE 国際会議「社会変革のための新興技術と革新的なビジネスプラクティス（EmergiTech）」。ニュージャージー州ピスカタウェイ：モーリシャス工科大学、電気電子技術者協会。2016年8月。ISBN 9781509007066 OCLC  972636788
  14. ^ 「IPアドレスの理解：知りたいことすべて」（PDF） 3Com。2001年6月16日時点のオリジナル（PDF）からアーカイブ
  15. ^ a b c d Y. Rekhter、B. Moskowitz、D. Karrenberg、GJ de Groot、E. Lear (1996年2月).プライベートインターネットのアドレス割り当て. ネットワークワーキンググループ. doi : 10.17487/RFC1918 . BCP 5. RFC 1918 .現在のベストプラクティス5。RFC 1627および1597は  廃止されます。RFC 6761により更新され ます。
  16. ^ J. Weil; V. Kuarsingh; C. Donley; C. Liljenstolpe; M. Azinger (2012年4月).共有アドレス空間のためのIANA予約済みIPv4プレフィックス.インターネット技術タスクフォース. doi : 10.17487/RFC6598 . ISSN 2070-1721 . BCP 153. RFC 6598 . 現在のベストプラクティス 153。RFC 5735を  更新します。
  17. ^ S. Cheshire ; B. Aboba; E. Guttman (2005年5月). IPv4リンクローカルアドレスの動的設定. ネットワークワーキンググループ. doi : 10.17487/RFC3927 . RFC 3927 .提案された標準
  18. ^ a b c J. Arkko、M. Cotton、 L . Vegoda（2010年1月）。文書化のために予約されたIPv4アドレスブロック。インターネット技術タスクフォース。doi : 10.17487/ RFC5737。ISSN 2070-1721。RFC 5737 情報。RFC 1166 を 更新します。
  19. ^ O. Troan (2015年5月). B. Carpenter (編). 6to4リレールータにおけるエニーキャストプレフィックスの廃止.インターネット技術タスクフォース. doi : 10.17487/RFC7526 . BCP 196. RFC 7526 .現在のベストプラクティス 196。RFC 3068 および6732を 廃止します。
  20. ^ C. Huitema (2001年6月). 6to4リレールータ向けエニーキャストプレフィックス. ネットワークワーキンググループ. doi : 10.17487/RFC3068 . RFC 3068 .情報提供。RFC 7526  により廃止されました。
  21. ^ S. Bradner; J. McQuaid (1999年3月).ネットワーク相互接続デバイスのベンチマーク方法論. ネットワークワーキンググループ. doi : 10.17487/RFC2544 . RFC 2544 .情報提供。RFC 6201 およびRFC  6815 により更新。
  22. ^ a b M. Cotton; L. Vegoda; D. Meyer (2010年3月). IANAガイドライン IPv4マルチキャストアドレス割り当て. IETF . doi : 10.17487/RFC5771 . ISSN 2070-1721 . BCP 51. RFC 5771 . 現在のベストプラクティス51。RFC 3138 および3171を 廃止します。RFC 2780を 更新します。
  23. ^ S. Venaas; R. Parekh; G. Van de Velde; T. Chown; M. Eubanks (2012年8月).ドキュメント用マルチキャストアドレス.インターネット技術タスクフォース. doi : 10.17487/RFC6676 . ISSN 2070-1721 . RFC 6676 . 情報提供
  24. ^ a b J. Reynolds編（2002年1月）。割り当て番号：RFC 1700はオンラインデータベースに置き換えられました。ネットワークワーキンググループ。doi : 10.17487/ RFC3232。RFC 3232情報提供。RFC 1700を  廃止します。
  25. ^ R. Braden編 (1989年10月).インターネットホストの要件 - 通信層. ネットワークワーキンググループ. doi : 10.17487/RFC1122 . STD 3. RFC 1122 .インターネット標準3。RFC 1349、4379、5884、6093、6298、6633、6864、8029、9293により  更新。IPアドレスは、 <ホスト番号> 、<ネットワーク番号> 、 <サブネット番号>のいずれのフィールドにも0または-1の値を持つことはできません（[特別な場合]を除く）。
  26. ^ J. Reynolds ; J. Postel (1984年10月). ASSIGNED NUMBERS . ネットワークワーキンググループ. doi : 10.17487/RFC0923 . RFC 923 .廃止。RFC 943  により廃止。RFC 900 を廃止。特殊 アドレス：特定の状況では、特定のホストの識別子としてではなく、機能的な意味を持つ固定アドレスを持つことが有用な場合があります。このような使用法が必要な場合、アドレス0は「このネットワーク」のように「これ」を意味すると解釈されます。
  27. ^ a b R. Braden編 (1989年10月).インターネットホストに対する要件 - 通信層. ネットワークワーキンググループ. doi : 10.17487/RFC1122 . STD 3. RFC 1122 .インターネット標準3。RFC 1349、4379、5884、6093、6298、6633、6864、8029、9293  によって更新されました。​​​​​​​​​​
  28. ^ A. Retana; R. White; V. Fuller; D. McPherson (2000年12月). IPv4ポイントツーポイントリンクにおける31ビットプレフィックスの使用. ネットワークワーキンググループ. doi : 10.17487/RFC3021 . RFC 3021 .提案された標準
  29. ^フィリップ・アルムキスト、フランク・カステンホルツ（1993年12月）。「IPルータの要件に向けて」インターネット技術タスクフォース
  30. ^ P. Almquist (1994年11月). F. Kastenholz (編). IPルータの要件に向けて. ネットワークワーキンググループ. doi : 10.17487/RFC1716 . RFC 1716 .廃止。RFC 1812  により廃止されました。
  31. ^ F. Baker編 (1995年6月). IPバージョン4ルータの要件. ネットワークワーキンググループ. doi : 10.17487/RFC1812 . RFC 1812 .提案された標準。RFC 1716 および1009を 廃止。RFC 2644 および6633により更新。
  32. ^ 「ip unnumberedコマンドの理解と設定」 . Cisco . 2021年11月25日閲覧。
  33. ^ C. Partridge; F. Kastenholz (1994年12月). IP The Next Generation (IPng) を選択するための技術基準. ネットワークワーキンググループ. doi : 10.17487/RFC1726 . RFC 1726 .情報提供
  34. ^ J. Postel編（1981年9月）。インターネットプロトコル- DARPAインターネットプログラムプロトコル仕様。IETF。doi : 10.17487/ RFC0791。STD 5。RFC 791。IEN 128、123、111、80、54、44、41、28、26インターネット標準5。RFC 760を  廃止。RFC 1349、2474、6864 により更新。​
  35. ^ K. Nichols; S. Blake; F. Baker ; D. Black (1998年12月). IPv4およびIPv6ヘッダーにおける差別化サービスフィールド（DSフィールド）の定義. ネットワークワーキンググループ. doi : 10.17487/RFC2474 . RFC 2474 .提案された標準。RFC 1455 および1349は 廃止されます。RFC 3168、3260、8436により更新 されます。
  36. ^ K. Ramakrishnan; S. Floyd; D. Black (2001年9月). IPへの明示的輻輳通知（ECN）の追加. ネットワークワーキンググループ. doi : 10.17487/RFC3168 . RFC 3168 .提案された標準。RFC 2481を  廃止。RFC 2474、2401、793を 更新。RFC 4301、6040、8311 により更新。​
  37. ^ Savage, Stefan (2000). 「IPトレースバックのための実用的なネットワークサポート」 . ACM SIGCOMM Computer Communication Review . 30 (4): 295– 306. doi : 10.1145/347057.347560 .
  38. ^ J. Touch (2013年2月). IPv4 IDフィールドの仕様更新. Internet Engineering Task Force . doi : 10.17487/RFC6864 . ISSN 2070-1721 . RFC 6864 . 提案された標準。RFC 791、1122  、および2003を 更新します。
  39. ^ S. Bellovin (2003年4月1日). IPv4ヘッダーのセキュリティフラグ. ネットワークワーキンググループ. doi : 10.17487/RFC3514 . RFC 3514 .情報提供です。 これはエイプリルフールのコメント募集です。
  40. ^ Bhardwaj, Rashmi (2020年6月4日). 「フラグメントオフセット - IP With Ease」 . ipwithease.com . 2022年11月21日閲覧。
  41. ^ 「Cisco 非公式 FAQ」 。 2012年5月10日閲覧。
  42. ^ F. Gont (2011年7月).インターネットプロトコルバージョン4のセキュリティ評価.インターネット技術タスクフォース. doi : 10.17487/RFC6274 . ISSN 2070-1721 . RFC 6274 . 情報提供
ウィキデータには以下のプロパティがあります
「 https://en.wikipedia.org/w/index.php?title=IPv4&oldid=1334770763」より取得