IPv4

Internet Protocol version 4︵インターネットプロトコルバージョン4︶、IPv4︵アイピーブイ4︶は、Internet Protocolの一種で、OSI参照モデルにおいてネットワーク層に位置付けられる通信プロトコルである。主に、転送の単位であるパケットの経路選択と、その断片化と再構築が規定されている。TCP/IPの基本機能として、インターネットをはじめ、世界中広く用いられている。

パケット[編集]

IPパケットの先頭には必ずIPヘッダが付加され、それにより経路選択などのIPの機能が実現されている。IPヘッダは12のフィールドと拡張情報︵オプション︶から成り立っている。拡張情報を含まないIPヘッダ長は20オクテットである。以下にパケット形式図とそれぞれの領域の役割などを記す。

**パケット形式図**
0	4	8	16	19
バージョン	ヘッダ長	サービス種別	全長
識別子			フラグ	断片位置
生存時間		プロトコル	チェックサム
送信元アドレス
宛先アドレス
拡張情報
データ

バージョン（Version）　IPのバージョンであり、IPv4の場合は4が格納される。
ヘッダ長（Internet Header Length、IHL）　IPヘッダの長さで、4オクテット単位で表される。この値によりデータの開始位置を知ることができる。通常は「5」が入る。

**サービス種別**
0	1	2	3	4	5	6	7
優先度			遅延度	転送量	信頼性	予備

●サービス種別︵Type of Service、ToS、優先順位︶　パケットが転送される際に重視するサービスを指定する。ただし、ルータの実装においてパケットごとにサービスを区別することは容易ではない。送信元が全てを重視とする設定を行う場合や、ネットワークの運用方針によっては境界に位置するルータが値を書き換える場合もある。優先度はパケットの優先度を8段階で示す。パケットの送信待ち行列を8個用いて実現する実装もある。遅延度はパケットを早く宛先へと到達させることを求める。転送量はパケットを多く宛先へと到達させることを求める。信頼性はパケットを失わず宛先へと到達させることを求める︵このような処理をQoSと呼ぶ︶。IPv6のIPv6パケットでは、サービス種別の代わりに﹁フローラベル﹂︵Flow Label︶が定義されている。 ●全長︵Total Length︶　IPヘッダを含むパケットの全長をオクテット単位で表したもの。最大は65,535オクテット。 ●識別子︵Identification、識別番号とも︶　パケットの送信元が一意な値を格納する。断片化したパケットの復元に用いられる。パケットを転送するルータがデータを分割したときにバラバラになった複数のパケットを同一のものと判断する。

**フラグ**
0	1	2
予備	禁止	継続

●フラグ︵Various Control Flags︶　断片化の制御に用いる。ビット0は予備であり常に0。ビット1は1の場合に断片化の禁止を意味する。ビット2は1の場合に断片化された後続のパケットが存在するパケットであることを意味し、0の場合は後続のパケットが存在しないことを意味する。 ●断片位置︵Fragment Offset︶　ルータなどがパケットを断片化した際に、その位置を8オクテット単位で格納する。断片化したパケットの復元に用いられる。以上の識別子、フラグ、断片位置の情報からフラグメントを行うことができる。 ●生存時間︵Time to Live、TTL︶　パケットの余命を示す値である。送信元はパケットが経由できるルータ数の上限を設定し、ルータはパケットを転送するごとに値を一つ減らし、値が0になるとパケットは破棄される。パケットがネットワーク上で無限に巡回する問題を防ぐ効果がある。TTLは8ビットのため0〜255の値をセットできる。 ●プロトコル︵Protocol︶　TCPなどの上位プロトコルを示すプロトコル番号が設定される。パケットの宛先である装置がパケットを受信すると、この値を用いて上位プロトコルを識別し、その実装へペイロードを渡す。主に使われるプロトコルには、ICMP、TCP、UDP、IPv6、EIGRP、OSPFが挙げられる。 ●チェックサム︵検査合計、Header Checksum︶　IPヘッダの誤り検査に用いられる。転送ごとに生存時間の値が変わるため、ルータはチェックサムも転送ごとに再計算する必要がある。データ部分に関してはTCPなどの上位層に任せ、IPパケットのヘッダのチェックサムの対象はヘッダ部分だけである。また、IPパケットのチェックサムフィールドは設定必須の項目なので省略できない。IPv6ではチェックサムフィールドはなくなった。 ●送信元アドレス︵Source Address︶　パケットの送信元IPアドレスが設定される。 ●宛先アドレス︵Destination Address︶　パケットの送信先IPアドレスが設定される。 ●拡張情報︵Options︶　可変長の拡張情報が32ビット単位で設定される。めったに使用されることがないが、セキュリティ、ルーズソースルーティング/ストリクトソースルーティング、レコードルート、インターネットタイムスタンプなどの情報が埋め込まれる。可変長のため0を足すパディングを必要とする。 ●データ　パケットが伝達すべきペイロードである。

アドレス[編集]

IPで用いられる32ビットのアドレスはIPアドレスと呼ばれ、IPアドレスはネットワークアドレスとホストアドレスに分けて用いられる。 RFC 791において、ネットワークアドレスとホストアドレスの境界は、IPアドレスの先頭のビット列で定められ、境界の位置によりIPアドレスはクラス︵class︶として分類された。

クラス	0	1	2	3	8	16	24
a	0	ネットワーク			ホスト
b	1	0	ネットワーク			ホスト
c	1	1	0	ネットワーク			ホスト
	1	1	1	拡張アドレスモード

しかしRFC 791の方式は、ホストアドレスの割り当て数が、クラスaでは16777215、クラスbでは65535にものぼる。これほどの膨大な数のホストを収容するネットワークは一般に存在せず、アドレスの利用に無駄を生じた。そこでRFC 950においてサブネット︵subnet︶が定められた。サブネットはホストアドレスの一部をアドレスマスク︵address mask︶を用いて分割することにより得られ、あるネットワークアドレスを与えられた組織内において、更にネットワークを分割するために用いられる。

	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
	1	0	ネットワーク														サブネット								ホスト
アドレスマスク	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1	1	0	0	0	0	0	0	0	0

RFC 1597においては、ある組織内で私的に用いられる下記のプライベートアドレスが定められた。 ●10.0.0.0〜10.255.255.255︵10.0.0.0/8︶ ●172.16.0.0〜172.31.255.255︵172.16.0.0/12︶ ●192.168.0.0〜192.168.255.255︵192.168.0.0/16︶上記のアドレス以外はグローバルアドレスとも呼ばれるようになる。

特別用途のアドレス[編集]

Internet Engineering Task Force (IETF)とInternet Assigned Numbers Authority (IANA)は、特別な用途に用いられるIPアドレスを予約し、一般の使用を制限している。

特別用途のアドレスブロック
アドレスブロック	アドレス範囲	アドレスの数	スコープ	説明
0.0.0.0/8	0.0.0.0–0.255.255.255	16777216	ソフトウェア	現在のネットワーク^[1]（送信元アドレスとしてのみ有効）
10.0.0.0/8	10.0.0.0–10.255.255.255	16777216	プライベートネットワーク	プライベートネットワーク内での通信に使用^[2]
100.64.0.0/10	100.64.0.0–100.127.255.255	4194304	プライベートネットワーク	シェアードアドレス空間（英語版）^[3]。キャリアグレードNATを使用する際に、サービスプロバイダとその加入者間で通信を行うために使用する。
127.0.0.0/8	127.0.0.0–127.255.255.255	16777216	ホスト	localhostへのループバックアドレスとして使用^[1]
169.254.0.0/16	169.254.0.0–169.254.255.255	65536	サブネット	リンクローカルアドレスとして使用^[4]。IPアドレスが指定されていない場合に、1つのリンク上の2つのホスト間の通信に使用される。
172.16.0.0/12	172.16.0.0–172.31.255.255	1048576	プライベートネットワーク	プライベートネットワーク内での通信に使用^[2]
192.0.0.0/24	192.0.0.0–192.0.0.255	256	プライベートネットワーク	IETF Protocol Assignments.^[1]
192.0.2.0/24	192.0.2.0–192.0.2.255	256	ドキュメント	ドキュメントにおける例示用(TEST-NET-1)^[5]
192.88.99.0/24	192.88.99.0–192.88.99.255	256	インターネット	予約^[6]。以前はIPv6からIPv4への中継(6to4)に使用されていた^[7]（IPv6アドレスブロック2002::/16を含む）。
192.168.0.0/16	192.168.0.0–192.168.255.255	65536	プライベートネットワーク	プライベートネットワーク内での通信に使用^[2]
198.18.0.0/15	198.18.0.0–198.19.255.255	131072	プライベートネットワーク	2つの異なるサブネット間のネットワーク間通信のベンチマークテストに使用^[8]。
198.51.100.0/24	198.51.100.0–198.51.100.255	256	ドキュメント	ドキュメントにおける例示用(TEST-NET-2)^[5]
203.0.113.0/24	203.0.113.0–203.0.113.255	256	ドキュメント	ドキュメントにおける例示用(TEST-NET-3)^[5]
224.0.0.0/4	224.0.0.0–239.255.255.255	268435456	インターネット	IPマルチキャストに使用^[9]（かつてのクラスD）。
240.0.0.0/4	240.0.0.0–255.255.255.254	268435455	インターネット	将来の使用のために予約^[10]（かつてのクラスE）。
255.255.255.255/32	255.255.255.255	1	サブネット	リミテッド・ブロードキャストの宛先アドレスとして予約^[1]^[11]

●14.0.0.0/8は、Public data networkのために予約されていたが(RFC 1700)、2008年2月に予約は解除された^[12]。 ●24.0.0.0/8は、ケーブルテレビネットワークのために予約されていたが(RFC 3330)、2010年5月現在では予約は解除されている^[12]。 ●39.0.0.0/8は、Class A Subnet Experimentとして予約されていたが(RFC 1797)、2010年5月現在では予約は解除されている^[12]。 ●128.0.0.0/16は、RFC 3330において予約されていたが、2010年5月現在では予約は解除されている^[12]。 ●191.255.0.0/16は、RFC 3330において予約されていたが、2010年5月現在では予約は解除されている^[12]。 ●223.255.255.0/24は、RFC 3330において予約されていたが、2010年5月現在では予約は解除されている^[1^2]。

経路選択[編集]

ルーティング︵routing︶とも呼ばれ、パケットを宛先へと転送する機能である。この機能はルータに集約され、多くのホストはデフォルト経路としてルータのアドレスを記述するスタイルを取ることが多い。

ネットワーク構成図

192.168.1.2

ether0

192.168.1.1

127.0.0.1
loopback

ether1

10.1.1.1

10.1.1.2

10.1.1.3

172.16/16

経路表
destination	nexthop	interface
default	192.168.1.2	ether0
192.168.1.1/32	127.0.0.1	loopback
192.168.1.2/32	192.168.1.2	ether0
10.1.1.1/32	127.0.0.1	loopback
10.1.1.2/32	10.1.1.2	ether1
10.1.1.3/32	10.1.1.3	ether1
172.16/16	10.1.1.2	ether1
10.255.255.255/32	10.1.1.1	ether1

ルータは経路表︵ルーティングテーブル、routing table︶に基づき経路選択を行う。あるネットワークの構成図とその中心に位置するルータの経路表を右に示す。図中において中心のルータは二つの送受信口を持っており、上の口はether0と名付けられアドレスは192.168.1.1が割り振られている。下の口はether1と名付けられアドレスは10.1.1.1が割り振られている。ルータ内部においてloopbackとはルータ自身を示す送受信口であり、127.0.0.1はルータ自身を現すアドレスである。表中においてdestinationは宛先、nexthopは転送先、interfaceは送信口を意味する︵アドレスの記法については﹁IPアドレス﹂を参照︶。このルータがパケットを受信した際の動作を解説する。192.168.1.1宛のパケットを受信すると、ルータは経路表の宛先を検索し、192.168.1.1/32の行を見つけ、その転送先はルータ自身であることから、自身に宛てられたパケットであることを判別する。192.168.1.2宛のパケットを受信すると、ルータは経路表を検索し、ether0から192.168.1.2に向けてパケットを送出する。10.1.1.2宛のパケットを受信すると、同様にether1から10.1.1.2に向けてパケットを送出する。 172.16.1.1宛のパケットを受信すると、ルータは最長一致する172.16/16の行を見つけ、10.1.1.2が172.16.1.1へと至る経路であると判別し、ether1から10.1.1.2に向けてパケットを送出する。 10.255.255.255宛のパケットを受信する。このアドレスはブロードキャストアドレスと呼ばれ、10/8のネットワークに接続された全ての装置を宛先とするアドレスである。ether1から10/8のネットワークに接続された全ての装置に向けてパケットを送出する。 7.7.7.7宛のパケットを受信する。このアドレスは経路表には存在しないため、defaultの行に最長一致し、ネクストホップである192.168.1.2に向かってパケットを送出する。192.168.1.2はデフォルトゲートウェイやデフォルトルートなどと呼ばれ、通常は端末から見てより中心に位置するルータが設定される。経路表の構築はルータの管理者が手動で設定する場合と、RIP、OSPFなどのルーティングプロトコルを用いて自動で設定する場合がある。前者は静的経路、後者は動的経路などとも呼ばれる。経路表はパソコンなどにも存在し、Windowsであれば﹁route print﹂、UNIX系であれば﹁netstat -r﹂または﹁ip route﹂で見ることができる。

断片化と再構築[編集]

「IPフラグメンテーション」も参照

プロトコルが転送する単位の最大長を、MTU︵最大転送単位、Max Transfer Unit︶と呼ぶ。IPパケットの最大長は65535オクテットであるが、IPパケットを伝送すべきデータリンク層のMTUは、IPの最大長と比べると短い場合が多く、例えば通常のイーサネットのMTUは1500オクテットである。 断片化︵英語‥Fragmentation、フラグメント化、フラグメンテーションとも呼ばれる^[13]^[14]︶は、IPパケットがパケットを送出する伝送路のMTUよりも長い場合に発生する。断片化を行う装置はIPパケットを伝送路のMTUに収まる長さに分割し、分割されたパケットのIPヘッダは、全長が分割された長さになり、断片位置には分割された位置が記され、最後のパケット以外は継続フラグが設定される。識別子は分割された全てのパケットに分割前のパケットのそれが写される。断片化したパケットの再構築︵英語‥Reassembly、再構成とも呼ばれる^[15]︶は、パケットの宛先である装置が行う。ある識別子を持つパケットの断片を受信した宛先は、さらに同じ識別子を持つパケットの断片を受信し、それぞれの断片位置から断片化前のパケットを再構築する。 IPヘッダのフラグの禁止ビットを設定すれば、パケットの断片化を禁止できる。この場合は断片化の代わりにICMPの宛先到達不可通知がパケットの送信元に返される。送信元はこれを利用して宛先に至る経路の最小MTUを調査することができ、そのような動作は経路MTU探索と呼ばれる。断片化は帯域やルータの負荷に無駄︵オーバーヘッド︶を生じ、スループットの低下となるため好まれない。経路MTU探索を行いMTUを調整するとよい。なお、IPv6では経路上のルータで断片化・再構築を行うことはなく、送信ホストのみで行われる。

IPv4アドレスの枯渇[編集]

詳細は「IPアドレス枯渇問題」を参照

IPv4のグローバルアドレスが枯渇してしまい、新規にIPv4のグローバルアドレスを割り当てることができなくなるため、インターネット上に公開されたIP機器を増設することが不可能になる問題である。既にIANA(Internet Assigned Numbers Authority)の管理するIPv4アドレスは2011年 2月3日に枯渇した。また、AFRINICを除くRIR(地域インターネットレジストリ)の管理するアドレスも2020年8月にはすべて枯渇した。この枯渇問題の対策として、IPv6の普及が進められている。

RFC仕様[編集]

RFC 791 - Internet Protocol
RFC 950 - Internet Standard Subnetting Procedure
RFC 1112 - Host Extensions for IP Multicasting
RFC 1518 - An Architecture for IP Address Allocation with CIDR
RFC 1519 - Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy
RFC 1597 - Address Allocation for Private Internets
RFC 1817 - CIDR and Classful Routing
RFC 2101 - IPv4 Address Behaviour Today

出典[編集]

[脚注の使い方]

(一)^ ^a ^b ^c ^dM. Cotton; L. Vegoda; R. Bonica; B. Haberman (April 2013). Special-Purpose IP Address Registries (英語). Internet Engineering Task Force. doi:10.17487/RFC6890. BCP 153. RFC 6890。 Updated by RFC 8190. (二)^ ^a ^b ^cY. Rekhter; B. Moskowitz; D. Karrenberg; G. J. de Groot; E. Lear (February 1996). Address Allocation for Private Internets (英語). Network Working Group. doi:10.17487/RFC1918. BCP 5. RFC 1918。 Updated by RFC 6761. (三)^ J. Weil; V. Kuarsingh; C. Donley; C. Liljenstolpe; M. Azinger (April 2012). IANA-Reserved IPv4 Prefix for Shared Address Space (英語). Internet Engineering Task Force (IETF). doi:10.17487/RFC6598. ISSN 2070-1721. BCP 153. RFC 6598。 (四)^ S. Cheshire; B. Aboba; E. Guttman (May 2005). Dynamic Configuration of IPv4 Link-Local Addresses (英語). Network Working Group. doi:10.17487/RFC3927. RFC 3927。 (五)^ ^a ^b ^cJ. Arkko; M. Cotton; L. Vegoda (January 2010). IPv4 Address Blocks Reserved for Documentation (英語). Internet Engineering Task Force. doi:10.17487/RFC5737. ISSN 2070-1721. RFC 5737。 (六)^ O. Troan (May 2015). B. Carpenter (ed.). Deprecating the Anycast Prefix for 6to4 Relay Routers (英語). Internet Engineering Task Force. doi:10.17487/RFC7526. BCP 196. RFC 7526。 (七)^ C. Huitema (June 2001). An Anycast Prefix for 6to4 Relay Routers (英語). Network Working Group. doi:10.17487/RFC3068. RFC 3068。 Obsoleted by RFC 7526. (八)^ S. Bradner; J. McQuaid (March 1999). Benchmarking Methodology for Network Interconnect Devices (英語). Network Working Group. doi:10.17487/RFC2544. RFC 2544。 Updated by: RFC 6201 and RFC 6815. (九)^ M. Cotton; L. Vegoda; D. Meyer (March 2010). IANA Guidelines for IPv4 Multicast Address Assignments (英語). Internet Engineering Task Force. doi:10.17487/RFC5771. BCP 51. RFC 5771。 (十)^ J. Reynolds, ed. (January 2002). Assigned Numbers: RFC 1700 is Replaced by an On-line Database (英語). Network Working Group. doi:10.17487/RFC3232. RFC 3232。 Obsoletes RFC 1700. (11)^ Jeffrey Mogul (October 1984). Broadcasting Internet Datagrams (英語). Network Working Group. doi:10.17487/RFC0919. RFC 919。 (12)^ ^a ^b ^c ^d ^e ^fRFC 5735 (13)^ “Windows および Sun のシステムでの IP MTU、TCP MSS、および PMTUD の調整”. Cisco. 2015年10月29日時点のオリジナルよりアーカイブ。2010年6月20日閲覧。 - フラグメント化と呼ばれる例。 (14)^ “TCP/IPに係る既知の脆弱性に関する調査報告書改訂第4版”. 2010年6月20日閲覧。 - フラグメンテーションと呼ばれる例。 (15)^ “@IT連載基礎から学ぶWindowsネットワークIPフラグメンテーション”. p. 3. 2010年6月20日閲覧。 - 再構成と呼ばれる例。