IPv4

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ
インターネットプロトコルバージョン4
プロトコルスタック
IPv4パケット-en.svg
IPv4パケット
目的インターネットワーキングプロトコル
開発者DARPA
序章1981 ; 41年前 (1981
OSI層ネットワーク層
RFC(s)RFC 791

インターネットプロトコルバージョン4IPv4)は、インターネットプロトコル(IP)の4番目のバージョンです。これは、インターネットやその他のパケット交換ネットワークにおける標準ベースのインターネットワーキング方式のコアプロトコルの1つです。IPv4は、1982年にSATNETで、1983年1月にARPANETで本番環境に導入された最初のバージョンでした。現在でも、インターネットプロトコルバージョン6(IPv6)の継続的な導入[3]でもほとんどのインターネットトラフィックのルーティングに使用されています。]その後継者。

IPv4は、 4,294,967,296(2 32 )個の一意のアドレスを提供する32ビットアドレス空間を使用しますが、大きなブロックは特別なネットワーク目的のために予約されています。[4] [5]

歴史

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

目的

インターネットプロトコルは、インターネットプロトコルスイートのインターネット層でのインターネットワーキングを定義および有効化するプロトコルです。本質的に、それはインターネットを形成します。論理アドレス指定システムを使用し、ルーティングを実行します。ルーティングとは、送信元ホストから、別のネットワーク上の目的の宛先ホストに1ホップ近い次のルーターにパケットを転送することです。

IPv4はコネクションレス型プロトコルであり、ベストエフォート型の配信モデルで動作します。これは、配信を保証したり、適切なシーケンスや重複配信の回避を保証したりするものではありません。データの整合性を含むこれらの側面は、伝送制御プロトコル(TCP) などの上位層のトランスポートプロトコルによって対処されます。

アドレス指定

クワッドドットのIPv4アドレス表現のバイナリ値への分解

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

IPv4は、プライベートネットワーク(約1800万アドレス)およびマルチキャストアドレス(約2億7000万アドレス)用に特別なアドレスブロックを予約します。

アドレス表現

IPv4アドレスは、32ビット整数値を表す任意の表記で表すことができます。ほとんどの場合、ドット10進表記で記述されます。ドット10進表記は、アドレスの4つのオクテットが10進数で個別に表現され、ピリオドで区切られています。

たとえば、クワッドドットのIPアドレス192.0.2.235は、32ビットの10進数3221226219を表し、16進形式では0xC00002EBです。

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は将来のアプリケーション用に予約されています。

既存のクラスフルネットワークをサブネットに分割することは、 RFC950 の発行とともに1985年に始まりましたこの分割は、1987年のRFC 1109での可変長サブネットマスク(VLSM)の導入により、より柔軟になりました。1993年、この作業に基づいて、RFC 1517はクラスレスドメイン間ルーティング(CIDR)[7]を導入 しました。たとえば、ビット数(最上位から)/ 24であり、クラスベースのスキームはクラスフルと呼ばれていました  、対照的に。CIDRは、任意のアドレススペースの再パーティション化を許可するように設計されているため、アドレスのより小さなブロックまたはより大きなブロックをユーザーに割り当てることができます。CIDRによって作成された階層構造は、Internet Assigned Numbers Authority(IANA)および地域インターネットレジストリ(RIR)によって管理されます。各RIRは、IPアドレスの割り当てに関する情報を提供 する公的に検索可能なWHOISデータベースを維持しています。

専用アドレス

Internet Engineering Task Force(IETF)とIANAは、特別な目的のためにさまざまな予約済みIPアドレスを一般的に使用することを制限してます[8]特に、これらのアドレスは、マルチキャストトラフィックに使用され、プライベートネットワークで無制限に使用するためのアドレス空間を提供します。

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

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

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


予約済みのプライベートIPv4ネットワーク範囲[10]
名前 CIDRブロック アドレス範囲 アドレスの数 クラスフルな説明
24ビットブロック 10.0.0.0/8 10.0.0.0 – 10.255.255.255 16 777 216 シングルクラスA。
20ビットブロック 172.16.0.0/12 172.16.0.0 – 172.31.255.255 1 048 576 16個のクラスBブロックの連続範囲。
16ビットブロック 192.168.0.0/16 192.168.0.0 – 192.168.255.255 65 536 256クラスCブロックの連続範囲。

2つのプライベートネットワーク(たとえば、2つのブランチオフィス)は、パブリックインターネットを介して直接相互運用できないため、2つのネットワークは、仮想プライベートネットワーク(VPN)またはIPトンネル介してインターネット間でブリッジする必要があります。パブリックネットワークを介した送信中のプロトコルレイヤー内のプライベートアドレス。さらに、カプセル化されたパケットは、データを保護するためにパブリックネットワークを介して送信するために暗号化される場合があります。

リンクローカルアドレス指定

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

アドレスブロックが予約されたとき、アドレス自動構成の標準は存在しませんでした。Microsoftは、自動プライベートIPアドレッシング(APIPA)と呼ばれる実装を作成しました。これは、数百万台のマシンに導入され、事実上の標準になりました。何年も後の2005年5月、IETFはRFC 3927で、IPv4リンクローカルアドレスの動的構成というタイトルの正式な標準を定義しました。

ループバック

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

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

サブネットの最初のアドレスは、サブネット自体を識別するために使用されます。このアドレスでは、すべてのホストビットは0です。表現のあいまいさを避けるために、このアドレスは予約されています。[21]最後のアドレスでは、すべてのホストビットが1に設定されています。これは、サブネット上のすべてのデバイスに同時にメッセージを送信するためのローカルブロードキャストアドレスとして使用されます。サイズ/ 24以上のネットワークの場合、ブロードキャストアドレスは常に255で終わります。

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

バイナリ形式 ドット10記法
ネットワークスペース 11000000.10101000.00000101.00000000 192.168.5.0
ブロードキャストアドレス 11000000.10101000.00000101.11111111 192.168.5.255
赤で、IPアドレスのホスト部分が示されています。他の部分はネットワークプレフィックスです。ホストは反転されますが(論理NOT)、ネットワークプレフィックスはそのまま残ります。

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

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

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

バイナリ形式 ドット10記法
ネットワークスペース 11001011.00000000.01110001.00010000 203.0.113.16
ブロードキャストアドレス 11001011.00000000.01110001.00011111 203.0.113.31
赤で、IPアドレスのホスト部分が示されています。他の部分はネットワークプレフィックスです。ホストは反転されますが(論理NOT)、ネットワークプレフィックスはそのまま残ります。

特別な場合として、/ 31ネットワークには2つのホストの容量しかありません。これらのネットワークは通常、ポイントツーポイント接続に使用されます。これらのネットワークには、ネットワーク識別子やブロードキャストアドレスはありません。[24]

アドレス解決

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

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

アンナンバードインターフェース

アンナンバードポイントツーポイント(PtP)リンクは、トランジットリンクとも呼ばれ、IPネットワークまたはサブネット番号が関連付けられていないが、IPアドレスが設定されているリンクです。1993年に最初に導入されました。[25] [26] [27] [28] [29]トランジットリンクの唯一の目的は、データグラムをルーティング することです。

アンナンバードリンクは、IPアドレス空間が不足している場合にIPアドレスを解放するため、またはIPの割り当てとインターフェイスの構成の管理を減らすために使用されます。以前のすべてのリンクは、ポイントツーポイントリンクごとに2〜4個のIPアドレスを使用する専用の/ 30または/ 31サブネットにする必要があります。リンクに番号が付けられていない場合、router-idが使用されます。router-idは、定義された(通常はループバック)インターフェイスから借用したIPアドレス/ 32です。同じrouter-idを複数のインターフェイスで使用できます。

アンナンバードインターフェイスの欠点の1つは、リモートテストと管理を行うのが難しいことです。

QualcommのPhilKarnは、オリジナルデザイナーとしての功績があります。

アドレス空間の枯渇

1980年代以降、利用可能なIPv4アドレスのプールが、ネットワークの元の設計では当初予想されていなかった速度で枯渇していることは明らかでした。[30]アドレスの枯渇を加速させた主な市場の力には、急速に増加するインターネットユーザーが含まれ、ラップトップコンピューター、携帯情報端末(PDA)、IPデータサービスを備えたスマートフォンなどのモバイルコンピューティングデバイスをますます使用するようになりました。さらに、高速インターネットアクセスは常時接続のデバイスに基づいていました。疲労の脅威は、次のような多くの修復技術の導入を動機付けました。

1990年代半ばまでに、ネットワークアクセスプロバイダーシステムでのネットワークアドレス変換(NAT)の普及、および地域およびローカルインターネットレジストリでの厳密な使用量ベースの割り当てポリシー。


IANAによって維持されているインターネットのプライマリアドレスプールは、最後の5つのブロックが5つのRIR に割り当てられた2011年2月3日に使い果たされました[31] [32] APNICは、制限付きポリシーの下で割り当てられるIPv6への移行テクノロジ用に予約された少量のアドレス空間を除いて、2011年4月15日に地域プールを使い果たした最初のRIRでした。[33]

枯渇に対処するための長期的な解決策は、インターネットプロトコルの新しいバージョンであるIPv6の1998年の仕様でした。[34]これにより、アドレススペースが大幅に増加しますが、インターネット全体のルート集約が改善され、エンドユーザーに最低264のホストアドレスの大規模なサブネットワーク割り当てが提供れます。ただし、IPv4はIPv6と直接相互運用できないため、IPv4のみのホストはIPv6のみのホストと直接通信できません。2004年に開始された6bone実験ネットワークの段階的廃止に伴い、 IPv6の永続的な正式な展開が2006年に開始されました。 [35] IPv6展開の完了にはかなりの時間がかかると予想されます[36]。そのため、ホストが両方のバージョンのプロトコルを使用してインターネットに参加できるようにするには 、中間移行テクノロジが必要です。

パケット構造

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

ヘッダー

IPv4パケットヘッダーは14個のフィールドで構成され、そのうち13個が必須です。14番目のフィールドはオプションであり、適切な名前が付けられています:options。ヘッダーのフィールドには、最上位バイトが最初にパックされ(ビッグエンディアン)、図と説明では、最上位ビットが最初に来ると見なされます(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 バージョン IHL DSCP ECN 全長
4 32 身元 フラグ フラグメントオフセット
8 64 有効期間 プロトコル ヘッダーチェックサム
12 96 送信元IPアドレス
16 128 宛先IPアドレス
20 160 オプション(IHL> 5の場合)
56 448
バージョン
IPパケットの最初のヘッダーフィールドは、4ビットバージョンフィールドです。IPv4の場合、これは常に4に等しくなります。
インターネットヘッダー長(IHL)
オプションの14番目のフィールド(オプション)により、IPv4ヘッダーのサイズは可変です。IHLフィールドにはIPv4ヘッダーのサイズが含まれ、ヘッダー内の32ビットワードの数を指定する4ビットがあります。このフィールドの最小値は5 [38]で、5×32ビット= 160ビット= 20バイトの長さを示します。4ビットフィールドとして、最大値は15です。これは、IPv4ヘッダーの最大サイズが15×32ビット= 480ビット= 60バイトであることを意味します。
差別化サービスコードポイントDSCP
もともとはタイプオブサービス(ToS)として定義されていましたが、このフィールドはRFC 2474に従って差別化サービス(DiffServ)を指定します。 [a]リアルタイムデータストリーミングはDSCPフィールドを利用します。例として、インタラクティブな音声サービスに使用されるVoice over IP(VoIP)があります。
明示的輻輳通知ECN
このフィールドはRFC3168で定義されており、パケットをドロップすることなくネットワーク輻輳をエンドツーエンドで通知できます。ECNは、両方のエンドポイントがECNをサポートしている場合に使用できるオプション機能であり、基盤となるネットワークでもサポートされている場合に有効です。
全長
この16ビットフィールドは、ヘッダーとデータを含むパケットサイズ全体をバイト単位で定義します。最小サイズは20バイト(データなしのヘッダー)で、最大サイズは65,535バイトです。すべてのホストは、最大576バイトのサイズのデータ​​グラムを再構築できる必要がありますが、最近のほとんどのホストは、はるかに大きなパケットを処理します。リンクはパケットサイズにさらに制限を課す場合があります。その場合、データグラムは断片化する必要があります。IPv4での断片化は、送信側ホストまたはルーターのいずれかで実行されます。再組み立ては、受信側ホストで実行されます。
身元
このフィールドは識別フィールドであり、主に単一のIPデータグラムのフラグメントのグループを一意に識別するために使用されます。いくつかの実験的研究では、スプーフィングされた送信元アドレスでデータグラムをトレースするのに役立つパケットトレース情報を追加するなど、他の目的でIDフィールドを使用することが提案されていますが[39]、RFC6864ではそのような使用は禁止されています。
フラグ
3ビットフィールドが続き、フラグメントを制御または識別するために使用されます。それらは(順番に、最も重要なものから最も重要でないものへ):
  • ビット0:予約済み。ゼロでなければなりません。[b]
  • ビット1:断片化しない(DF)
  • ビット2:その他のフラグメント(MF)
DFフラグが設定されていて、パケットをルーティングするためにフラグメンテーションが必要な場合、パケットはドロップされます。これは、フラグメントの再構成を実行するためのリソースがないホストにパケットを送信するときに使用できます。また、ホストIPソフトウェアによって自動的に、またはpingtracerouteなどの診断ツールを使用して手動でパスMTU検出に使用することもできます
フラグメント化されていないパケットの場合、MFフラグはクリアされます。フラグメント化されたパケットの場合、最後を除くすべてのフラグメントにMFフラグが設定されます。最後のフラグメントにはゼロ以外のフラグメントオフセットフィールドがあり、フラグメント化されていないパケットと区別されます。
フラグメントオフセット
このフィールドは、元のフラグメント化されていないIPデータグラムの先頭を基準にした特定のフラグメントのオフセットを8バイトブロック単位で指定します。最初のフラグメントのオフセットはゼロです。13ビットフィールドでは、(2 13  – 1)×8 = 65,528バイトの最大オフセットが可能です。これには、ヘッダー長(65,528 + 20 = 65,548バイト)が含まれ、最大IP長の65,535バイトを超えるパケットの断片化がサポートされます。
存続時間(TTL)
8ビットの存続時間フィールドは、ルーティングループが発生した場合のネットワーク障害を防ぐために、データグラムの存続期間を制限します秒単位で指定されますが、1秒未満の時間間隔は1に切り上げられます。実際には、フィールドはホップカウントとして使用されます。データグラムがルーターに到着すると、ルーターはTTLフィールドを1つ減らします。TTLフィールドがゼロに達すると、ルータはパケットを破棄し、通常、ICMPタイム超過メッセージを送信者に送信します。
プログラムtracerouteは、調整されたTTL値でメッセージを送信し、これらのICMPタイム超過メッセージを使用して、送信元から宛先までパケットが通過したルーターを識別します。
プロトコル
このフィールドは、IPデータグラムのデータ部分で使用されるプロトコルを定義します。IANAは、RFC790の指示に従ってIPプロトコル番号のリストを維持しています。
ヘッダーチェックサム
16ビットのIPv4ヘッダーチェックサムフィールドは、ヘッダーのエラーチェックに使用されます。パケットがルーターに到着すると、ルーターはヘッダーのチェックサムを計算し、それをチェックサムフィールドと比較します。値が一致しない場合、ルーターはパケットを破棄します。データフィールドのエラーは、カプセル化されたプロトコルで処理する必要があります。UDPTCPの両方に、データに適用される個別のチェックサムがあります。
パケットがルーターに到着すると、ルーターはヘッダーのTTLフィールドを減らします。したがって、ルータは新しいヘッダーチェックサムを計算する必要があります。
送信元アドレス
このフィールドは、パケットの送信者のIPv4アドレスです。このアドレスは、ネットワークアドレス変換デバイスによって転送中に変更される可能性があることに注意してください。
宛先アドレス
このフィールドは、パケットの受信者のIPv4アドレスです。送信元アドレスと同様に、これはネットワークアドレス変換デバイスによって転送中に変更される場合があります。
オプション
オプションフィールドはあまり使用されません一部のオプションを含むパケットは 、一部のルーターによって危険であると見なされ、ブロックされる場合があります。[40] IHLフィールドの値には、すべてのオプションを保持するのに十分な追加の32ビットワードと、ヘッダーに整数個の32ビットワードが含まれるようにするために必要なパディングが含まれている必要があることに注意してください。IHLが5より大きい場合(つまり、6から15の場合)、オプションフィールドが存在するため、考慮する必要があることを意味します。オプションのリストは、EOOL(オプションリストの終わり、0x00)オプションで終了する場合があります。これは、オプションの終わりがヘッダーの終わりと一致しない場合にのみ必要です。ヘッダーに配置できる可能なオプションは次のとおりです。
分野 サイズ(ビット) 説明
コピー 1 オプションをフラグメント化されたパケットのすべてのフラグメントにコピーする必要がある場合は、1に設定します。
オプションクラス 2 一般的なオプションのカテゴリ。0は制御オプション用で、2はデバッグと測定用です。1と3は予約されています。
オプション番号 5 オプションを指定します。
オプションの長さ 8 オプション全体(このフィールドを含む)のサイズを示します。このフィールドは、単純なオプションには存在しない場合があります。
オプションデータ 変数 オプション固有のデータ。このフィールドは、単純なオプションには存在しない場合があります。
次の表は、IPv4で定義されているオプションを示しています。オプションタイプ列は、上記で定義されたコピー、オプションクラス、およびオプション番号ビットから派生します。[41]
オプションタイプ(10進数/ 16進数) オプション名 説明
0 / 0x00 EOOL オプションリストの終わり
1 / 0x01 NOP 操作なし
2 / 0x02 SEC セキュリティ(廃止)
7 / 0x07 RR ルートを記録する
10 / 0x0A ZSU 実験的測定
11 / 0x0B MTUP MTUプローブ
12 / 0x0C MTUR MTU返信
15 / 0x0F エンコード エンコード
25 / 0x19 QS クイックスタート
30 / 0x1E EXP RFC3692スタイルの実験
68 / 0x44 TS タイムスタンプ
82 / 0x52 TR Traceroute
94 / 0x5E EXP RFC3692スタイルの実験
130 / 0x82 SEC セキュリティ(RIPSO)
131 / 0x83 LSR 緩いソースルート
133 / 0x85 E-SEC 拡張セキュリティ(RIPSO)
134 / 0x86 CIPSO 商用IPセキュリティオプション
136 / 0x88 SID ストリームID
137 / 0x89 SSR 厳密なソースルート
142 / 0x8E ビザ 実験的アクセス制御
144 / 0x90 IMITD IMIトラフィック記述子
145 / 0x91 EIP 拡張インターネットプロトコル
147 / 0x93 ADDEXT アドレス拡張
148 / 0x94 RTRALT ルーターアラート
149 / 0x95 SDB 選択的ダイレクトブロードキャスト
151 / 0x97 DPS 動的パケット状態
152 / 0x98 UMP アップストリームマルチキャストパケット。
158 / 0x9E EXP RFC3692スタイルの実験
205 / 0xCD フィン 実験的なフロー制御
222 / 0xDE EXP RFC3692スタイルの実験

データ

パケットペイロードはチェックサムに含まれていません。その内容は、プロトコルヘッダーフィールドの値に基づいて解釈されます。

IPプロトコル番号のリストには、ペイロードプロトコルタイプの完全なリストが含まれています。一般的なペイロードプロトコルには、次のものがあります。

プロトコル番号 プロトコル名 略語
1 インターネット制御メッセージプロトコル ICMP
2 インターネットグループ管理プロトコル IGMP
6 伝送制御プロトコル TCP
17 ユーザーデータグラムプロトコル UDP
41 IPv6カプセル化 ENCAP
89 最短パスを最初に開く OSPF
132 ストリーム制御伝送プロトコル SCTP

断片化と再構築

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

対照的に、次世代のインターネットプロトコルであるIPv6では、ルーターが断片化を実行することはできません。ホストは、データグラムを送信する前に パスMTUディスカバリーを実行する必要があります。

断片化

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

ルーターはパケットをフラグメントに分割します。各フラグメントの最大サイズは、発信MTUからIPヘッダーサイズを引いたものです(最小20バイト、最大60バイト)。ルータは各フラグメントを独自のパケットに入れます。各フラグメントパケットには次の変更があります。

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

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

あるルーターでパケットが断片化され、別のルーターで断片がさらに断片化される可能性があります。たとえば、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バイト。オフセットは

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フィールドは、すべての再フラグメント化されたフラグメントで同じ値を持ち続けます。このようにして、フラグメントが再フラグメント化された場合でも、受信者は、フラグメントが最初はすべて同じパケットから開始されたことを認識します。

最後のオフセットと最後のデータサイズは、合計データサイズを計算するために使用されます。

再組み立て

次の条件の少なくとも1つが当てはまる場合、受信者はパケットがフラグメントであることを認識します。

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

受信者は、送信元アドレスと宛先アドレス、プロトコルID、および識別フィールドを使用して、一致するフラグメントを識別します。レシーバーは、フラグメントオフセットとより多くのフラグメントフラグの両方を使用して、同じIDを持つフラグメントからデータを再構成します。受信者は、より多くのフラグメントフラグが0に設定されている最後のフラグメントを受信すると、最後のフラグメントのオフセットに8を掛け、最後のフラグメントのデータサイズを加算することにより、元のデータペイロードのサイズを計算できます。与えられた例では、この計算はバイト。受信機にすべてのフラグメントがある場合、それらはオフセットに従って正しい順序で再構成され、元のデータグラムを形成できます。

支援プロトコル

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

も参照してください

メモ

  1. ^ RFC3168およびRFC3260 によって更新されまし 
  2. ^ エイプリルフールのジョークとして、RFC3514で「悪意ビット

参考文献

  1. ^ W. Richard Stevens、 TCP / IP Illustrated、Volume 1:The Protocols、Addison Wesley、1994、ISBN0-201-63346-9。
  2. ^ 「BGP分析レポート」2013年1月9日取得
  3. ^ 「IPv6–Google」www.google.com 2022-01-28を取得
  4. ^ 「IANAIPv4専用アドレスレジストリ」www.iana.org 2022-01-28を取得
  5. ^ 「RFC5735-特別な用途のIPv4アドレス」datatracker.ietf.org 2022-01-28を取得
  6. ^ 「IPv4の簡単な歴史」IPv4マーケットグループ2020年8月19日取得
  7. ^ 「IPアドレッシングを理解する:あなたが知りたいと思ったことすべて」(PDF)3Com。2001年6月16日にオリジナル(PDF)からアーカイブされました。
  8. ^ 綿、M。; Vegoda、L。(2010年1月)。特殊用途のIPv4アドレス土井10.17487 / RFC5735RFC5735_
  9. ^ a b c dM 。コットン; L.ベゴダ; R.ボニカ; B.ハーバーマン(2013年4月)。特殊用途のIPアドレスレジストリインターネットエンジニアリングタスクフォース土井10.17487 / RFC6890BCP153。RFC6890 _ _ RFC8190 によって更新されまし
  10. ^ a b c d Y. Rekhter; B.モスコウィッツ; D.カレンバーグ; GJ de Groot; E.リア(1996年2月)。プライベートインターネットのアドレス割り当てネットワークワーキンググループ。土井10.17487 / RFC1918BCP 5. RFC1918 RFC6761 によって更新されまし
  11. ^ J。ワイル; V.クアルシン; C.ドンリー; C. Liljenstolpe; M.エイジンガー(2012年4月)。IANA-共有アドレス空間用に予約されたIPv4プレフィックスインターネットエンジニアリングタスクフォース(IETF)。土井10.17487 / RFC6598ISSN2070-1721_ BCP153。RFC6598 _ _ 
  12. ^ S。チェシャー; B.アボバ; E.ガットマン(2005年5月)。IPv4リンクローカルアドレスの動的構成ネットワークワーキンググループ。土井10.17487 / RFC3927RFC3927_
  13. ^ a b c J. Arkko; M.コットン; L.ベゴダ(2010年1月)。ドキュメント用に予約されたIPv4アドレスブロックインターネットエンジニアリングタスクフォース土井10.17487 / RFC5737ISSN2070-1721_ RFC5737_ 
  14. ^ O. Troan(2015年5月)。B.カーペンター(編)。6to4リレールーターのエニーキャストプレフィックスの非推奨インターネットエンジニアリングタスクフォース土井10.17487 / RFC7526BCP196。RFC7526 _ _
  15. ^ C. Huitema(2001年6月)。6to4リレールーターのエニーキャストプレフィックスネットワークワーキンググループ。土井10.17487 / RFC3068RFC3068_ RFC7526 で廃止されました。
  16. ^ S。ブラッドナー; J. McQuaid(1999年3月)。ネットワーク相互接続デバイスのベンチマーク方法ネットワークワーキンググループ。土井10.17487 / RFC2544RFC2544_ 更新者  RFC6201 およびRFC6815
  17. ^ a bM 。コットン; L.ベゴダ; D.マイヤー(2010年3月)。IPv4マルチキャストアドレス割り当てに関するIANAガイドラインインターネットエンジニアリングタスクフォース土井10.17487 / RFC5771BCP51。RFC5771 _ _
  18. ^ S. Venaas; R.パレク; G.ヴァンデベルデ; T. Chown; M.ユーバンクス(2012年8月)。ドキュメントのマルチキャストアドレスインターネットエンジニアリングタスクフォース土井10.17487 / RFC6676RFC6676_
  19. ^ J.レイノルズ編 (2002年1月)。割り当てられた番号:RFC1700はオンラインデータベースに置き換えられましたネットワークワーキンググループ。土井10.17487 / RFC3232RFC3232_ RFC1700を廃止します 
  20. ^ ジェフリーモーグル(1984年10月)。インターネットデータグラムのブロードキャストネットワークワーキンググループ。土井10.17487 / RFC0919RFC919_
  21. ^ 「RFC923」IETF1984年6月2019年11月15日取得特別なアドレス:特定のコンテキストでは、特定のホストの識別子としてではなく、機能的に重要な固定アドレスを使用すると便利です。このような使用法が必要な場合、アドレス0は、「このネットワーク」のように「これ」を意味すると解釈されます。
  22. ^ ロバートブレーデン(1989年10月)。「インターネットホストの要件–通信レイヤー」IETFp。31. RFC1122_ 
  23. ^ ロバートブレーデン(1989年10月)。「インターネットホストの要件–通信レイヤー」IETFp。66. RFC1122_ 
  24. ^ RFC 3021 
  25. ^ Almquist、Philip; カステンホルツ、フランク(1994年11月)。「IPルーターの要件に向けて」 {{cite journal}}引用ジャーナルには|journal=ヘルプ)が必要です
  26. ^ RFC 1916 
  27. ^ RFC 1716 
  28. ^ RFC 1812 
  29. ^ 「ipunnumberedコマンドの理解と構成」シスコ2021-11-25を取得
  30. ^ 「世界」インターネットアドレスが不足している"。2011年1月25日にオリジナルからアーカイブされまし。 2011年1月23日に取得されまし
  31. ^ スミス、ルーシー; リプナー、イアン(2011年2月3日)。「IPv4アドレス空間の空きプールが枯渇しました」Number ResourceOrganization 2011年2月3日取得
  32. ^ ICANN、nanogメーリングリスト。「RIRに割り当てられた5つの/ 8–未割り当てのIPv4ユニキャスト/ 8は残っていません」
  33. ^ アジア太平洋ネットワーク情報センター(2011年4月15日)。「APNICIPv4アドレスプールが最終/ 8に到達しました」2011年8月7日にオリジナルからアーカイブされました2011年4月15日取得
  34. ^ ヒンデン、ボブ; Deering、Steve E.(1998年12月)。「インターネットプロトコル、バージョン6(IPv6)仕様」tools.ietf.org 2019年12月13日取得
  35. ^ Fink、R。; HInden、R。(2004年3月)。6bone(IPv6テストアドレス割り当て)段階的廃止土井10.17487 / RFC3701RFC3701_
  36. ^ 2016 IEEE International Conference on Emerging Technologies and Innovative Business Practices for the Transformation of Societies(EmergiTech):日付、2016年8月3-6日工科大学、モーリシャス、電気電子学会。ニュージャージー州ピスカタウェイ。2016年。ISBN 9781509007066OCLC972636788 _{{cite book}}:CS1 maint:その他(リンク
  37. ^ パートリッジ、C。; Kastenholz、F。(1994年12月)。「6.2IPヘッダーチェックサム」IPを選択するための技術的基準次世代(IPng)p。26.秒 6.2。土井10.17487 / RFC1726RFC1726_
  38. ^ ポステル、J。インターネットプロトコル土井10.17487 / RFC0791RFC791_
  39. ^ サベージ、ステファン(2000)。「IPトレースバックの実用的なネットワークサポート」ACMSIGCOMMコンピューターコミュニケーションレビュー30(4):295–306。土井10.1145 /347057.347560 2010年9月6日取得
  40. ^ 「シスコの非公式FAQ」2012年5月10日取得
  41. ^ 「インターネットプロトコルバージョン4(IPv4)パラメータ」

外部リンク