| プロトコルスタック | |
IPv4パケット | |
| 略語 | IPv4 |
|---|---|
| 目的 | インターネットワーキングプロトコル |
| 開発者 | DARPA |
| 導入 | 1981年 |
| 影響を受けた | IPv6 |
| OSI層 | ネットワーク層 |
| RFC(複数) | 791 |
インターネット プロトコル バージョン 4 ( IPv4 ) は、スタンドアロン仕様としてのインターネット プロトコル(IP)の最初のバージョンです。これは、インターネットやその他のパケット交換ネットワークにおける標準ベースのインターネットワーキング方法のコア プロトコルの 1 つです。IPv4 は、1982 年にSATNETで、1983 年 1 月にARPANETで実稼働用に導入された最初のバージョンです。 [1]後継のインターネット プロトコル バージョン 6 (IPv6) [2]の導入が進んでいるにもかかわらず、今日でもほとんどのインターネット トラフィックのルーティングに使用されています。
IPv4は32ビットのアドレス空間を使用し、4,294,967,296(2 32)個の一意のアドレスを提供しますが、大きなブロックは特別なネットワーク目的のために予約されています。[3] [4]
歴史
以前のバージョンのTCP/IPはTCP/IPv3を介した統合仕様でした。IPv4では、インターネットプロトコルは個別の仕様になりました。[5]
インターネットプロトコルバージョン4は、IETF出版物RFC 791(1981年9月)で説明されており、1980年1月の以前の定義(RFC 760)に代わるものです。1982年3月、米国国防総省は、インターネットプロトコルスイート(TCP/IP)をすべての軍事コンピュータネットワークの標準として決定しました。[6]
目的
インターネット プロトコルは、インターネット プロトコル スイートのインターネット層でインターネットワーキングを定義し、有効にするプロトコルです。本質的には、インターネットを形成します。インターネット プロトコルは、論理アドレス指定システムを使用し、ルーティングを実行します。ルーティングとは、送信元ホストから、別のネットワーク上の目的の宛先ホストに 1 ホップ近い次のルータにパケットを転送することです。
IPv4 はコネクションレスプロトコルであり、ベスト エフォート配信モデルで動作します。配信を保証するものではなく、適切な順序付けや重複配信の回避も保証しません。データの整合性を含むこれらの側面は、伝送制御プロトコル(TCP) などの上位層トランスポート プロトコルによって対処されます。
アドレッシング

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) [7]が導入されました。これは、ビット数 (最上位から) をたとえば/24のように表現し、クラスベースのスキームは対照的にクラスフル と呼ばれました。CIDRは、アドレス空間の再分割を許可して、より小さいまたは大きいアドレス ブロックをユーザーに割り当てることができるように設計されています。CIDR によって作成された階層構造は、インターネット割り当て番号機関 (IANA) と地域インターネット レジストリ (RIR) によって管理さ れています。
特別用途アドレス
インターネット技術特別調査委員会(IETF)とIANAは、特別な目的のために予約されたさまざまなIPアドレスの一般使用を制限しています。 [4]特に、これらのアドレスはマルチキャストトラフィックに使用され、プライベートネットワーク上で無制限に使用できるアドレス空間を提供するために使用されます。
プライベートネットワーク
IPv4 で定義されている約 40 億のアドレスのうち、3 つの範囲の約 1,800 万のアドレスがプライベート ネットワーク用に予約されています。これらの範囲のパケット アドレスはパブリック インターネットではルーティングできず、すべてのパブリック ルーターによって無視されます。したがって、プライベート ホストはパブリック ネットワークと直接通信することはできませんが、この目的のためにはルーティング ゲートウェイで ネットワーク アドレス変換が必要になります。
2 つのプライベート ネットワーク (たとえば、2 つのブランチ オフィス) はパブリック インターネット経由で直接相互運用できないため、2 つのネットワークは、仮想プライベート ネットワーク(VPN) またはIP トンネルを介してインターネット経由でブリッジされる必要があります。これにより、パブリック ネットワーク経由での送信中に、プライベート アドレスを含むヘッダーを含むパケットがプロトコル レイヤーでカプセル化されます。さらに、カプセル化されたパケットは、データを保護するために、パブリック ネットワーク経由での送信時に暗号化されることがあります。
リンクローカルアドレス指定
RFC 3927 は、リンクローカル アドレス指定用の特別なアドレス ブロック 169.254.0.0/16 を定義します。これらのアドレスは、それらを使用するホストに直接接続されたリンク (ローカル ネットワーク セグメントやポイントツーポイント接続など) 上でのみ有効です。これらのアドレスはルーティングできません。プライベート アドレスと同様に、これらのアドレスはインターネットを通過するパケットの送信元または送信先にはなりません。これらのアドレスは主に、ホストが DHCP サーバーまたはその他の内部構成方法から IP アドレスを取得できない場合に、アドレス自動構成 ( Zeroconf ) に使用されます。
アドレス ブロックが予約されていた当時、アドレスの自動構成に関する標準は存在しませんでした。Microsoftは、 Automatic Private IP Addressing (APIPA)と呼ばれる実装を作成しました。これは、何百万台ものマシンに導入され、事実上の標準となりました。それから何年も経った 2005 年 5 月、IETF はRFC 3927 で「Dynamic Configuration of IPv4 Link-Local Addresses 」という正式な標準を定義しました。
ループバック
クラス A ネットワーク127.0.0.0 (クラスレス ネットワーク127.0.0.0 / 8 ) はループバック用に予約されています。送信元アドレスがこのネットワークに属する IP パケットは、ホストの外部に現れることはありません。ループバックの送信元または宛先アドレスを持つ非ループバック インターフェイスで受信されたパケットは、ドロップする必要があります。
最初と最後のサブネットアドレス
サブネットの最初のアドレスは、サブネット自体を識別するために使用されます。このアドレスでは、すべてのホストビットは0です。表現の曖昧さを避けるために、このアドレスは予約されています。[18]最後のアドレスでは、すべてのホストビットが1に設定されています。これは、サブネット上のすべてのデバイスに同時にメッセージを送信するためのローカルブロードキャストアドレスとして使用されます。サイズが/ 24以上 のネットワークでは、ブロードキャストアドレスは常に 255 で終わります。
たとえば、サブネット192.168.5.0 / 24 (サブネット マスク255.255.255.0 ) では、識別子192.168.5.0 はサブネット全体を参照するために使用されます。ネットワークのブロードキャスト アドレスは192.168.5.255です。
ただし、これは 0 または 255 で終わるすべてのアドレスがホスト アドレスとして使用できないという意味ではありません。たとえば、アドレス範囲192.168.0.0~192.168.255.255に相当する/ 16サブネット192.168.0.0 / 255.255.0.0では、ブロードキャスト アドレスは192.168.255.255です。 192.168.1.255、192.168.2.255などのアドレスは、255 で終わっていてもホストに使用できます。また、 192.168.0.0 はネットワーク識別子であり、インターフェイスに割り当てることはできません。[19] : 31 192.168.1.0、192.168.2.0などのアドレスは、0で終わっていても割り当てられることがある 。
過去には、一部のソフトウェアが1ではなく0を含む非標準のブロードキャストアドレスを使用していたため、ネットワークアドレスとブロードキャストアドレスの間に競合が発生しました。[19] : 66
/ 24より小さいネットワークでは、ブロードキャスト アドレスは必ずしも 255 で終わるわけではありません。たとえば、CIDR サブネット203.0.113.16 / 28 のブロードキャスト アドレスは203.0.113.31です。
特別なケースとして、/ 31ネットワークは2台のホストのみに対応しています。これらのネットワークは通常、ポイントツーポイント接続に使用されます。これらのネットワークにはネットワーク識別子やブロードキャストアドレスはありません。[20]
アドレス解決
インターネット上のホストは通常、名前 (例: www.example.com) で認識され、ルーティングやネットワーク インターフェイスの識別に使用される IP アドレスでは認識されません。ドメイン名を使用するには、ドメイン名をアドレスに変換する (つまり解決する) 必要があります。その逆も同様です。これは、受信者の名前を使用して電話帳で電話番号を検索するのと似ています。
アドレスとドメイン名間の変換は、他の DNS サーバーへの 名前空間のサブ委任を可能にする階層型の分散命名システムであるドメイン ネーム システム(DNS) によって実行されます。
番号なしインターフェース
番号なしポイントツーポイント(PtP)リンクはトランジットリンクとも呼ばれ、IPネットワーク番号やサブネット番号が関連付けられていないが、IPアドレスを持つリンクです。1993年に初めて導入され、[21] [22] [23] [24] QualcommのPhil Karnがオリジナルの設計者として知られています。
トランジット リンクの目的は、データグラムをルーティングする ことです。トランジット リンクは、不足している IP アドレス空間から IP アドレスを解放したり、IP の割り当てやインターフェイスの構成の管理を軽減したりするために使用されます。以前は、ポイントツーポイント リンクごとに 2 つまたは 4 つの IP アドレスを使用して、各リンクで/ 31または/ 30サブネットを専用にする必要がありました。リンクが番号付けされていない場合は、定義済みの (通常はループバック) インターフェイスから借りた単一の IP アドレスであるルータ IDが使用されます。同じルータ ID を複数のインターフェイスで使用できます。
番号なしインターフェースの欠点の 1 つは、リモート テストと管理が困難になることです。
アドレス空間の枯渇

1980年代には、利用可能なIPv4アドレスのプールが、ネットワークの当初の設計では予想されていなかった速度で枯渇していることが明らかになりました。[25]アドレス枯渇を加速させた主な市場要因には、インターネットユーザーの急増が挙げられます。インターネットユーザーは、ラップトップコンピューター、携帯情報端末(PDA)、 IPデータサービスを備えたスマートフォンなどのモバイルコンピューティングデバイスをますます使用しています。さらに、高速インターネットアクセスは常時接続デバイスに基づいていました。アドレス枯渇の脅威は、次のようないくつかの改善技術の導入を促しました。
- 小規模ISP割り当て向けのクラスレスドメイン間ルーティング(CIDR)
- 番号なしインターフェイスにより、トランジット リンク上のアドレスが不要になりました。
- ネットワーク アドレス変換(NAT) により、エンドツーエンドの原則が不要になりました。
1990 年代半ばまでに、NAT は、地域およびローカルのインターネット レジストリでの厳格な使用量ベースの割り当てポリシーとともに、ネットワーク アクセス プロバイダー システムで広く使用されるようになりました。
IANAによって管理されていたインターネットのプライマリアドレスプールは、2011年2月3日に最後の5つのブロックが5つのRIRに割り当てられた時点で枯渇した。[26] [27] APNICは、2011年4月15日に地域アドレスプールを使い果たした最初のRIRとなったが、IPv6への移行技術用に予約された少量のアドレス空間は制限付きポリシーの下で割り当てられることになっていた。[28]
アドレス枯渇に対する長期的な解決策は、1998年にインターネットプロトコルの新しいバージョンであるIPv6の仕様が定められたことだった。[29]これにより、アドレス空間が大幅に拡大されるだけでなく、インターネット全体のルート集約が改善され、エンドユーザーには最低2 64 個のホストアドレスの大規模なサブネットワーク割り当てが提供される。しかし、IPv4はIPv6と直接相互運用できないため、IPv4のみのホストはIPv6のみのホストと直接通信できない。2004年に6bone実験ネットワークの段階的廃止が始まり、2006年にIPv6の恒久的な正式な導入が開始された。[30] IPv6の導入が完了するまでには相当の時間がかかると予想されているため、[31]ホストが両方のバージョンのプロトコルを使用してインターネットに参加できるようにするには、 中間の移行技術が必要となる。
パケット構造
IPパケットはヘッダーセクションとデータセクションから構成されます。IPパケットにはデータセクションの後にデータチェックサムやその他のフッターはありません。通常、リンク層はほとんどのエラーを検出するCRCフッターを使用してIPパケットをフレームにカプセル化します。IPによって伝送される多くのトランスポート層プロトコルにも独自のエラーチェック機能があります。[32] : §6.2
ヘッダ
IPv4 パケット ヘッダーは 14 個のフィールドで構成され、そのうち 13 個は必須です。14 番目のフィールドはオプションで、オプションという適切な名前が付けられています。ヘッダー内のフィールドは、最上位バイトが最初にパックされ (ネットワーク バイト順序)、図と説明では、最上位ビットが最初に来るものとみなされます ( MSB 0 ビット番号付け)。最上位ビットは 0 に番号付けされるため、たとえばバージョン フィールドは実際には最初のバイトの最上位 4 ビットにあります。
- バージョン: 4 ビット
- IPパケットの最初のヘッダー フィールドはバージョンフィールドです。IPv4 の場合、これは常に4になります。
- インターネット ヘッダー長 (IHL): 4 ビット
- IPv4 ヘッダーは、オプションの 14 番目のフィールド (オプション)によりサイズが可変です。IHL フィールドには IPv4 ヘッダーのサイズが含まれます。このフィールドには、ヘッダー内の 32 ビット ワードの数を指定する 4 ビットがあります。このフィールドの最小値は 5 で、[33] 5 × 32 ビット = 160 ビット = 20 バイトの長さを示します。4 ビット フィールドであるため、最大値は 15 です。つまり、IPv4 ヘッダーの最大サイズは 15 × 32 ビット = 480 ビット = 60 バイトです。
- 差別化サービスコードポイント (DSCP ): 6 ビット
- もともとサービスタイプ(ToS)として定義されたこのフィールドは、差別化サービス(DiffServ)を指定します。[34]リアルタイムデータストリーミングはDSCPフィールドを利用します。例としては、インタラクティブ音声サービスに使用されるVoice over IP (VoIP)があります。
- 明示的輻輳通知 (ECN ): 2 ビット
- このフィールドにより、パケットをドロップすることなく、ネットワーク輻輳をエンドツーエンドで通知できます。[35] ECNは、両方のエンドポイントがサポートしている場合に利用できるオプション機能であり、基盤となるネットワークでもサポートされている場合に有効です。
- 全長: 16ビット
- この16 ビットフィールドは、ヘッダーとデータを含むパケット全体のサイズをバイト単位で定義します。最小サイズは 20 バイト (データなしのヘッダー)、最大サイズは 65,535 バイトです。すべてのホストは、最大 576 バイトのサイズのデータグラムを再構成できる必要がありますが、最近のホストのほとんどは、はるかに大きなパケットを処理します。リンクによってパケット サイズにさらに制限が課される場合があり、その場合はデータグラムを断片化する必要があります。IPv4 の断片化は、送信ホストまたはルーターのいずれかで実行されます。再構成は受信ホストで実行されます。
- 識別: 16ビット
- このフィールドは識別フィールドであり、主に単一のIPデータグラムのフラグメントのグループを一意に識別するために使用されます。いくつかの実験的研究では、IDフィールドを他の目的、例えば偽装された送信元アドレスを持つデータグラムを追跡するのに役立つパケット追跡情報を追加する目的などに使用することが提案されていますが、[36]現在、そのような使用は禁止されています。[37]
- フラグ: 3 ビット
- このフィールド内には 3 つのフラグが定義されています。
- 予約 (R):1ビット
- 予約済み。0に設定する必要があります。[a]
- 断片化しない (DF): 1 ビット
- このフィールドは、データグラムをフラグメント化できるかどうかを指定します。これは、フラグメントの再構成を実行するリソースを持たないホストにパケットを送信するときに使用できます。また、ホスト IP ソフトウェアによって自動的に、またはpingやtracerouteなどの診断ツールを使用して手動で、パス MTU 検出に使用することもできます。DF フラグが設定されていて、パケットをルーティングするためにフラグメント化が必要な場合は、パケットがドロップされます。
- より多くのフラグメント (MF):1ビット
- フラグメント化されていないパケットの場合、MF フラグはクリアされます。フラグメント化されたパケットの場合、最後のフラグメントを除くすべてのフラグメントに MF フラグが設定されます。最後のフラグメントにはゼロ以外のフラグメント オフセットフィールドがあるため、フラグメント化されていないパケットと区別できます。
- フラグメントオフセット: 13 ビット
- このフィールドは、元の断片化されていない IP データグラムの先頭からの特定のフラグメントのオフセットを指定します。フラグメントは 8 バイト単位で指定されるため、フラグメントの長さは常に 8 の倍数になります。ただし、最後のフラグメントは 8 より小さくなる場合があります。[39]
最初のフラグメントの断片化オフセット値は常に 0 です。このフィールドは 13 ビット幅であるため、オフセット値の範囲は 0 ~ 8191 ((2 0 – 1) ~ (2 13 – 1)) です。したがって、最大フラグメント オフセットは (2 13 – 1) × 8 = 65,528 バイトで、ヘッダー長 (65,528 + 20 = 65,548 バイト) が含まれるため、最大 IP 長の 65,535 バイトを超えるパケットの断片化がサポートされます。 - 生存時間 (TTL ): 8 ビット
- 存続時間フィールドは、ルーティング ループが発生した場合にネットワーク障害を防ぐために、データグラムの存続時間を制限します。これは秒単位で指定されますが、1 秒未満の時間間隔は 1 に切り上げられます。実際には、このフィールドはホップ カウントとして使用されます。データグラムがルーターに到着すると、ルーターは TTL フィールドを 1 減らします。TTL フィールドが 0 になると、ルーターはパケットを破棄し、通常はICMP 時間超過メッセージを送信者に送ります。
- トレースルートプログラムは、調整された TTL 値を持つメッセージを送信し、これらの ICMP 時間超過メッセージを使用して、送信元から宛先までのパケットが通過するルーターを識別します。
- プロトコル: 8ビット
- このフィールドは、IPデータグラムのデータ部分で使用されるトランスポート層プロトコルを定義します。IPプロトコル番号のリストは、インターネット割り当て番号機関(IANA)によって管理されています。[17]
- 一般的なペイロード プロトコルには次のようなものがあります。
- ヘッダーチェックサム: 16 ビット
- IPv4ヘッダー チェックサムフィールドは、ヘッダーのエラー チェックに使用されます。パケットを送信する前に、チェックサムは、ヘッダー内のすべての 16 ビット ワードの 1 の補数の合計の 16 ビット 1 の補数として計算されます。これには、計算中にゼロに設定されるヘッダー チェックサムフィールド自体が含まれます。パケットは、結果の値を含むヘッダー チェックサムとともに送信されます。パケットがルーターまたはその宛先に到着すると、ネットワーク デバイスは、ヘッダー チェックサムフィールドを含むヘッダーのチェックサム値を再計算します。結果はゼロになるはずです。異なる結果が得られた場合、デバイスはパケットを破棄します。
- パケットがルータに到着すると、ルータはヘッダーのTTLフィールドを減らします。その結果、ルータはパケットを再度送信する前に新しいヘッダー チェックサムを計算する必要があります。
- パケットのデータ部分のエラーは、カプセル化されたプロトコルによって個別に処理されます。UDPとTCP の両方に、データに適用される個別のチェックサムがあります。
- 送信元アドレス: 32 ビット
- このフィールドには、パケットの送信者のIPv4 アドレスが含まれます。これは、ネットワーク アドレス変換(NAT) によって転送中に変更される可能性があります。
- 宛先アドレス: 32ビット
- このフィールドには、パケットの宛先となるIPv4 アドレスが含まれます。NAT の影響を受ける場合もあります。
- 宛先に直接到達できる場合、パケットはARPの助けを借りて、基礎となるリンク層によって配信されます。そうでない場合、パケットはルーティングを必要とし、代わりにゲートウェイ アドレスに配信されます。
- オプション: 0 - 320 ビット、32 ビットの倍数にパディング
- オプションフィールドはあまり使用されません。一部のオプションを含むパケットは、一部のルーターによって危険とみなされ、ブロックされる可能性があります。 [40] IHLフィールドの値には、すべてのオプションと、ヘッダーに整数個の32ビットワードが含まれるようにするために必要なパディングを保持するのに十分な追加の32ビットワードが含まれている必要があります。IHLが5より大きい場合(つまり、6〜15の場合)、オプションフィールドが存在し、考慮する必要があることを意味します。オプションのリストは、オプションEOOL(オプションリストの終了、0x00)で終了できます。これは、オプションの終了がヘッダーの終了と一致しない場合にのみ必要です。
- IPオプションのほとんどには、パケットが通過する中間デバイスの数や種類に関する指定が含まれているため、IPオプションはインターネット経由の通信には使用されず、一部のIPオプションを含むIPパケットはドロップする必要があります。[41] :§3.13 これは、ネットワークトポロジやネットワークの詳細が公開される可能性があるためです。
断片化と再構築
インターネット プロトコルは、ネットワーク間のトラフィックを可能にします。この設計は、さまざまな物理的性質を持つネットワークに対応しており、リンク層で使用される基盤となる伝送技術とは無関係です。ハードウェアが異なるネットワークでは、通常、伝送速度だけでなく、最大伝送単位(MTU) も異なります。あるネットワークが、より小さな MTU を持つネットワークにデータグラムを送信する場合、データグラムが断片化されることがあります。IPv4 では、この機能はインターネット層に配置され、IPv4 ルーターで実行されるため、ホストによるこれらの問題への露出が制限されます。
対照的に、次世代のインターネット プロトコルであるIPv6では、ルーターによるフラグメンテーションが許可されず、ホストはデータグラムを送信する前にパス MTU 検出を実行する必要があります。
断片化
ルータはパケットを受信すると、宛先アドレスを調べ、使用する送信インターフェイスとそのインターフェイスの MTU を決定します。パケット サイズが MTU よりも大きく、パケットのヘッダーの Do not Fragment (DF) ビットが 0 に設定されている場合、ルータはパケットを断片化することがあります。
ルータはパケットをフラグメントに分割します。各フラグメントの最大サイズは、送信 MTU から IP ヘッダー サイズを引いたサイズです (最小 20 バイト、最大 60 バイト)。ルータは各フラグメントを独自のパケットに入れますが、各フラグメント パケットには次の変更が加えられます。
- 合計長フィールドはフラグメント サイズです。
- 最後のフラグメントを除くすべてのフラグメントに対して、より多くのフラグメント (MF) フラグが設定されます。最後のフラグメントは 0 に設定されます。
- フラグメントオフセットフィールドは、元のデータ ペイロード内のフラグメントのオフセットに基づいて設定されます。これは、8 バイト ブロック単位で測定されます。
- ヘッダーのチェックサムフィールドが再計算されます。
たとえば、MTU が 1,500 バイトでヘッダー サイズが 20 バイトの場合、フラグメント オフセットは(0、185、370、555、740 など) の倍数になります。
パケットが 1 つのルータで断片化され、その断片が別のルータでさらに断片化される可能性があります。たとえば、20 バイトの IP ヘッダーを含む 4,520 バイトのパケットが、MTU が 2,500 バイトのリンク上で 2 つのパケットに断片化されます。
合計データ サイズは保持されます: 2,480 バイト + 2,020 バイト = 4,500 バイト。オフセットはとです。
MTU が 1,500 バイトのリンクに転送されると、各フラグメントは 2 つのフラグメントに分割されます。
この場合も、データ サイズは維持されます: 1,480 + 1,000 = 2,480、1,480 + 540 = 2,020。
この場合も、More Fragmentsビットは、1 が設定されているすべてのフラグメントに対して 1 のままであり、到着する最後のフラグメントに対しては通常どおりに機能し、最後のフラグメントに対してのみ MF ビットが 0 に設定されます。そしてもちろん、識別フィールドは、再フラグメント化されたすべてのフラグメントで同じ値を保持し続けます。このように、フラグメントが再フラグメント化された場合でも、受信側は、フラグメントがすべて最初は同じパケットから開始されたことを認識します。
最後のオフセットと最後のデータ サイズは、合計データ サイズの計算に使用されます。
再組み立て
次の条件の少なくとも 1 つが当てはまる場合、受信側はパケットがフラグメントであることを認識します。
- フラグmorefragmentsが設定されており、これは最後のフラグメントを除くすべてのフラグメントに当てはまります。
- フィールドフラグメント オフセットはゼロ以外であり、これは最初のフラグメントを除くすべてのフラグメントに当てはまります。
受信側は、送信元アドレスと宛先アドレス、プロトコル ID、識別フィールドを使用して、一致するフラグメントを識別します。受信側は、フラグメント オフセットとより多くのフラグメント フラグの両方を使用して、同じ ID を持つフラグメントからデータを再構成します。受信側は、より多くのフラグメントフラグが 0 に設定されている最後のフラグメントを受信すると、最後のフラグメントのオフセットに 8 を掛け、最後のフラグメントのデータ サイズを加算することで、元のデータ ペイロードのサイズを計算できます。この例では、この計算はバイトでした。受信側がすべてのフラグメントを取得すると、オフセットに従って正しい順序でそれらを再構成して、元のデータグラムを形成できます。
補助プロトコル
IP アドレスはネットワーク ハードウェアに永続的に結び付けられているわけではなく、実際、最近のオペレーティング システムでは、ネットワーク インターフェイスが複数の IP アドレスを持つことができます。リンク上の宛先ホストに IP パケットを適切に配信するには、ホストとルーターに、ネットワーク インターフェイスのハードウェア アドレス[b]と IP アドレスを関連付ける追加のメカニズムが必要です。アドレス解決プロトコル(ARP) は、IPv4 のこの IP アドレスからハードウェア アドレスへの変換を実行します。さらに、逆相関が必要になることもよくあります。たとえば、管理者がアドレスを事前に構成していない限り、IP ホストを起動したりネットワークに接続したりするときに、その IP アドレスを決定する必要があります。このような逆相関のプロトコルには、動的ホスト構成プロトコル(DHCP)、ブートストラップ プロトコル(BOOTP)、およびまれに逆 ARPがあります。
参照
注記
参考文献
この記事は、 CC BY 4.0ライセンス (2022)
に基づいて次のソースから編集されたものです。 Michel Bakni;サンドラ・ハンボ(2022年12月9日)。 「インターネットプロトコルバージョン4(IPv4)に関する調査」(PDF)。ウィキ科学ジャーナル。土井:10.15347/WJS/2022.002。ISSN 2470-6345。OCLC 9708517136。S2CID 254665961。 ウィキデータ Q104661268。
- ^ 「BGP 分析レポート」。BGPレポート。2013年 1 月 9 日閲覧。
- ^ 「IPv6 – Google」。www.google.com 。 2022年1月28日閲覧。
- ^ 「IANA IPv4 特殊目的アドレスレジストリ」www.iana.org . 2022年1月28日閲覧。
- ^ abcdef M. Cotton、L. Vegoda、B. Haberman (2013 年 4 月)。R. Bonica (編)。特殊目的 IP アドレス レジストリ。IETF。doi : 10.17487 / RFC6890。ISSN 2070-1721。BCP 153。RFC 6890。 現在のベストプラクティス 153。RFC 4773、5156、5735、および 5736 は 廃止されました。RFC 8190 によって更新されました。
- ^ デイビス、リディア。「ヴィント・サーフ - 世界はまだ80パーセントつながっていない」ニューヨーク・タイムズ。 2024年5月10日閲覧。
- ^ 「IPv4 の簡単な歴史」IPv4 Market Group . 2020 年 8 月 19 日閲覧。
- ^ 「IP アドレスの理解: 知っておきたいことすべて」(PDF)。3Com。2001年 6 月 16 日時点のオリジナル(PDF)からアーカイブ。
- ^ abcd 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 によって更新されました。
- ^ 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。 ベスト コモン プラクティス。RFC 5735 を更新します。
- ^ S. Cheshire、B. Aboba、E. Guttman (2005 年 5 月)。IPv4 リンクローカル アドレスの動的構成。ネットワーク ワーキング グループ。doi : 10.17487 / RFC3927。RFC 3927 。 提案された標準。
- ^ abc J. Arkko; M. Cotton; L. Vegoda (2010 年 1 月) . IPv4アドレス ブロックはドキュメント用に予約されています。インターネット エンジニアリング タスク フォース。doi : 10.17487/ RFC5737。ISSN 2070-1721。RFC 5737 。 情報。RFC 1166 を 更新します。
- ^ O. Troan (2015 年 5 月). B. Carpenter (編). 6to4 リレー ルーターの Anycast プレフィックスの廃止。インターネット エンジニアリング タスク フォース。doi : 10.17487/RFC7526。BCP 196。RFC 7526。 現在のベストプラクティス。RFC 3068 および 6732 は 廃止されます。
- ^ C. Huitema (2001 年 6 月)。6to4 リレー ルータ用のエニーキャスト プレフィックス。ネットワーク ワーキング グループ。doi : 10.17487 / RFC3068。RFC 3068 。 情報提供。RFC 7526 により廃止されました。
- ^ S. Bradner、J. McQuaid (1999 年 3 月)。ネットワーク相互接続デバイスのベンチマーク方法論。ネットワーク ワーキング グループ。doi : 10.17487 / RFC2544。RFC 2544 。 情報提供。RFC 6201 およびRFC 6815 によって更新されました。
- ^ ab M. Cotton; L. Vegoda; D. Meyer (2010 年 3 月). IPv4 マルチキャスト アドレス割り当てに関する IANA ガイドライン。IETF。doi : 10.17487 / RFC5771。ISSN 2070-1721。BCP 51。RFC 5771。 現在のベストプラクティス 51。RFC 3138 および 3171 を 廃止します。RFC 2780 を更新します。
- ^ S. Venaas、R. Parekh、G . Van de Velde、T. Chown、M. Eubanks (2012 年 8 月)。 「ドキュメント用のマルチキャスト アドレス」。インターネット エンジニアリング タスク フォース。doi : 10.17487/ RFC6676。ISSN 2070-1721。RFC 6676 。 情報提供。
- ^ ab J. Reynolds編 (2002 年 1 月)。割り当てられた番号: RFC 1700 はオンライン データベースに置き換えられました。ネットワーク ワーキング グループ。doi : 10.17487/ RFC3232。RFC 3232 。 情報提供。RFC 1700 は 廃止されました。
- ^ J. Reynolds ; J. Postel (1984 年 10 月). ASSIGNED NUMBERS. ネットワークワーキンググループ. doi : 10.17487/RFC0923 . RFC 923. 廃止。RFC 943 により廃止。RFC 900を廃止。
特殊アドレス: 特定の状況では、特定のホストの識別子としてではなく、機能的な意味を持つ固定アドレスを持つことが有用です。このような使用法が必要な場合、アドレス 0 は「このネットワーク」のように「これ」を意味するものとして解釈されます。
- ^ ab R. Braden編 (1989 年 10 月)。インターネット ホストの要件 - 通信層。ネットワーク ワーキング グループ。doi : 10.17487 /RFC1122。STD 3。RFC 1122。 インターネット標準 3。RFC 1349、4379、5884、6093、6298、6633、6864、8029、9293 によって更新されました。
- ^ A. Retana、R. White、V. Fuller、D. McPherson (2000 年 12 月)。 IPv4 ポイントツーポイント リンクでの 31 ビット プレフィックスの使用。ネットワーク ワーキング グループ。doi : 10.17487 / RFC3021。RFC 3021 。 提案された標準。
- ^ Almquist, Philip; Kastenholz, Frank (1993 年 12 月)。「IP ルーターの要件に向けて」。インターネット エンジニアリング タスク フォース。
- ^ P. Almquist (1994 年 11 月). F. Kastenholz (編). IP ルーターの要件に向けて. ネットワークワーキンググループ. doi : 10.17487/RFC1716 . RFC 1716. 廃止。RFC 1812 により廃止されました。
- ^ F. Baker編 (1995 年 6 月)。IP バージョン 4 ルータの要件。ネットワーク ワーキング グループ。doi : 10.17487 / RFC1812。RFC 1812 。 提案された標準。RFC 1716 および 1009 は廃止されました。RFC 2644 および 6633 によって更新されました。
- ^ 「ip unnumbered コマンドの理解と設定」 。Cisco。2021年 11 月 25日閲覧。
- ^ 「世界でインターネットアドレスが不足」。2011年1月25日時点のオリジナルよりアーカイブ。2011年1月23日閲覧。
- ^ Smith, Lucie; Lipner, Ian (2011 年 2 月 3 日)。「IPv4 アドレス空間の空きプールが枯渇」。Number Resource Organization。2011年2 月 3 日閲覧。
- ^ ICANN、nanog メーリング リスト。「5 つの /8 が RIR に割り当てられました。割り当てられていない IPv4 ユニキャスト /8 は残っていません」。
- ^ Asia-Pacific Network Information Centre (2011年4月15日). 「APNIC IPv4アドレスプールが最終/8に到達」。2011年8月7日時点のオリジナルよりアーカイブ。2011年4月15日閲覧。
- ^ 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 により更新。
- ^ R. Fink; R. Hinden (2004 年 3 月). 6bone (IPv6 テスト アドレス割り当て) の段階的廃止。ネットワーク ワーキング グループ。doi : 10.17487 / RFC3701。RFC 3701 。 情報提供。RFC 2471 は 廃止されました。
- ^ 2016 IEEE 国際会議「社会変革のための新興技術と革新的ビジネスプラクティス (EmergiTech)」。ニュージャージー州ピスカタウェイ: モーリシャス工科大学、電気電子技術者協会。2016 年 8 月。ISBN 9781509007066. OCLC 972636788.
- ^ C. Partridge、F. Kastenholz (1994 年 12 月)。次世代 IP (IPng) を選択するための技術基準。ネットワーク ワーキング グループ。doi : 10.17487 / RFC1726。RFC 1726 。 情報提供。
- ^ 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 によって更新されました。
- ^ K. Nichols、S. Blake、F. Baker、D. Black (1998 年 12 月)。 IPv4 および IPv6 ヘッダーの Differentiated Services フィールド (DS フィールド) の定義。ネットワーク ワーキング グループ。doi : 10.17487/RFC2474。RFC 2474。 提案された標準。RFC 1455 および 1349 は廃止されました。RFC 3168、3260、および 8436 によって更新されました。
- ^ 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 によって更新。
- ^ Savage, Stefan (2000). 「IP トレースバックの実用的なネットワークサポート」ACM SIGCOMM コンピュータ通信レビュー30 ( 4): 295–306. doi : 10.1145/347057.347560 .
- ^ J. Touch (2013 年 2 月). IPv4 ID フィールドの仕様の更新。IETF。doi : 10.17487 / RFC6864。ISSN 2070-1721。RFC 6864 。 提案された標準。RFC 791、1122、および 2003 を更新します。
- ^ S. Bellovin (2003 年 4 月 1 日). IPv4 ヘッダーのセキュリティ フラグ。ネットワーク ワーキング グループ。doi : 10.17487 / RFC3514。RFC 3514 。 情報提供。 これはエイプリルフールのコメント募集です。
- ^ Bhardwaj, Rashmi (2020-06-04). 「フラグメントオフセット - IP With Ease」. ipwithease.com . 2022-11-21閲覧。
- ^ 「Cisco 非公式 FAQ」。2012 年 5 月 10 日閲覧。
- ^ F. Gont (2011 年7 月) .インターネット プロトコル バージョン 4 のセキュリティ評価。インターネット エンジニアリング タスク フォース。doi : 10.17487/ RFC6274。ISSN 2070-1721。RFC 6274 。 情報提供。
外部リンク
- インターネット番号割当機関 (IANA)
- IP、インターネット プロトコル アーカイブ済み 2011-05-14 at the Wayback Machine — IP ヘッダーの内訳、特定のオプションを含む
- C. Perkins 編 (2010 年 11 月)。IPv4 の IP モビリティ サポート、改訂版。インターネットエンジニアリングタスク フォース。doi : 10.17487/ RFC5944。ISSN 2070-1721。RFC 5944 。 提案された標準。RFC 3344 を 廃止します。
- IANA によって管理されている IPv4/8 割り当ての公式の現在の状態
