IP アドレスとサブネット — クラスフルから CIDR (RFC 4632) への移行、/24 の意味
DDEVELOPER
開発(更新: 2026-09-03)9 分で読める

IP アドレスとサブネット — クラスフルから CIDR (RFC 4632) への移行、/24 の意味

サーバーの設定で 192.168.1.0/24 と書くとき、この /24 が何を意味するか正確に説明できますか? 「サブネットマスク 255.255.255.0 のこと」で止まっていないでしょうか。/24 の背後には、1981 年の IPv4 誕生から 1993 年の CIDR 導入、2011 年の IANA 中央プール枯渇に至る 30 年のアドレス設計史があります。本記事では RFC 791、RFC 950、RFC 1918、RFC 4632 を一次資料に、IP アドレッシングの設計思想を整理します。

#IP アドレス#CIDR#サブネット#RFC 4632#ネットワーク

RFC 791 (1981) — IPv4 と「クラス」の誕生

RFC 791 (September 1981) で定義された IPv4 は、32 ビットのアドレス空間 (約 43 億個) を持ちます。当時はアドレスをネットワーク部ホスト部に分け、先頭ビットのパターンで 3 つのクラスに分類しました:

表が収まらない場合は、左右にスクロールできます。

クラス先頭ビット歴史的prefix先頭オクテット番号パターン数従来の最大ホスト数/NW
A0/80〜12712816,777,214
B10/16128〜19116,38465,534
C110/24192〜2232,097,152254

表の個数は先頭ビットから得られる理論上の番号パターン数です。たとえばAの0/8と127/8は特殊用途で、128個すべてが通常ネットワークへ割り当てられたわけではありません。RFC 791の 111 はextended addressingへのescapeで、後にClass D (1110, multicast, 224/4)とClass E (240/4, reserved)として整理されました。現在の割当可否は歴史的クラスではなく、IANAの登録を確認します。

この設計の問題は粒度の粗さです。500台を単一の歴史的ネットワーク番号で収めるならClass C (最大254台)では足りず、Class B (最大65,534台)が必要でした。複数のClass Cを使う選択肢は経路数や運用を増やします。Class Bを500台だけに使えば、従来のホスト番号空間の99%以上が未使用になります。

RFC 950 (1985) — サブネット手順の標準化

組織が単一のIPネットワーク番号を複数の物理ネットワークで扱えるよう、RFC 950 (August 1985) はそれ以前の提案を踏まえてサブネッティングの標準手順を文書化しました。ネットワーク内部をさらに細分化する仕組みです。

仕組みはシンプルなビット AND 演算です:

IP アドレス:    192.168.1.100  = 11000000.10101000.00000001.01100100
サブネットマスク: 255.255.255.0  = 11111111.11111111.11111111.00000000
AND 結果:       192.168.1.0    = 11000000.10101000.00000001.00000000
                                 ← ネットワーク部 (24bit) →← ホスト部 →

サブネットマスクの「1」の部分がネットワーク (+ サブネット) を、「0」の部分がホストを識別します。数学上は、同じ Class B ネットワークを 256 個の /24、または4個の /18 に分割できます。ただし RFC 950 は当時、サブネットフィールドが全0または全1の値を物理サブネットへ割り当てるべきではないとしていました。その歴史的規則で割り当て可能だったのは、それぞれ254個の /24、2個の /18 です。

ただし RFC 950 時代のサブネットは組織内部の話であり、インターネット全体のルーティングテーブルには影響しませんでした。組織は依然として Class A/B/C 単位でアドレスを取得する必要がありました。

1990 年代初頭 — Class B 枯渇危機

インターネットの急速な商業化により、1990 年代初頭に Class B アドレスの枯渇が深刻化しました。Class B は 16,384 個しかなく、大学や企業がこぞって取得した結果、残りわずかとなりました。

問題は枯渇だけではありません。各組織に 1 つの Class B が割り当てられると、ルーティングテーブルに 1 エントリが追加されます。組織数が増えるにつれ、ルーティングテーブルが爆発的に膨張し、ルーターのメモリと処理能力を圧迫しました。

RFC 1519 (1993) は、列挙した問題のうちClass Bネットワーク番号空間の枯渇とルーティングテーブル増大の2つが、1〜3年以内に重大になる可能性が高いと記述しています。両方を同時に緩和する仕組みが求められました。

CIDR (1993) — クラスに依存しない経路制御

CIDR (Classless Inter-Domain Routing)RFC 1519 (September 1993) で提案され、後に RFC 4632 (August 2006, BCP 122) で現在の標準として再整理されました。

CIDR の核心は「クラスという概念を捨てる」ことです。アドレスの先頭ビットパターンに関係なく、任意のビット位置でネットワーク/ホストの境界を設定できます:

クラスフル:  Class C = 固定 /24
CIDR:       /20, /21, /22, /23, /24, /25, /26 ... 何でも OK

 例: 10.0.0.0/20 → ネットワーク部 20 bit、ホスト部 12 bit
                    → 4,094 台のホスト (2^12 - 2)

これにより、500 台の組織には /23 (510 ホスト) を割り当て、2,000 台の組織には /21 (2,046 ホスト) を割り当てる、という柔軟な運用が可能になりました。

さらに CIDR はアドレスの集約 (aggregation) を可能にしました。たとえば、ビット境界で整列した連続16個の /24 (16 × 256 = 4,096アドレス) は、共通する先頭20bitを持つ1つの /20としてまとめられます。単に連続しているだけではなく、個数が2のべき乗で、集約先prefixの境界に整列している必要があります。

/24 が「254 台」になる理由 — 計算式

CIDR表記 /n の従来型IPv4サブネット (/0/30) で、ネットワークアドレスとブロードキャストアドレスだけを除いた数学上の個数は:

通常の使用可能ホスト数 = 2^(32 - n) - 2

「-2」はネットワークアドレス (ホスト部が全 0) とブロードキャストアドレス (ホスト部が全 1) を除外するためです。ただし /31 は RFC 3021 の Point-to-Point リンクとして両方のアドレスを使う場合があり、/32 は単一ホストを表すため、この式をそのまま適用しません。

表が収まらない場合は、左右にスクロールできます。

CIDRサブネットマスクホスト部使用可能ホスト用途例
/32255.255.255.2550 bit1 (単一アドレス)ホストルート、単一endpointの指定
/31255.255.255.2541 bit2 (RFC 3021 の条件下)ポイントツーポイントリンク
/30255.255.255.2522 bit2ポイントツーポイントリンク
/28255.255.255.2404 bit14小規模サーバーセグメント
/24255.255.255.08 bit254標準的な LAN
/16255.255.0.016 bit65,534大規模組織
/8255.0.0.024 bit約 1,677 万旧 Class A 相当

/24 が「254 台」になるのは 2^(32-24) - 2 = 256 - 2 = 254 という計算です。旧 Class C と同じ範囲ですが、CIDR では /24 はあくまで「プレフィックス長 24」であり、Class C とは無関係です。

RFC 1918 (1996) — プライベートアドレスの誕生

RFC 1918 (February 1996, BCP 5) は、インターネットに直接接続しない内部ネットワーク用に 3 つのアドレス範囲を予約しました:

表が収まらない場合は、左右にスクロールできます。

範囲CIDRアドレス数旧クラス相当
10.0.0.0 〜 10.255.255.25510.0.0.0/816,777,216Class A × 1
172.16.0.0 〜 172.31.255.255172.16.0.0/121,048,576Class B × 16
192.168.0.0 〜 192.168.255.255192.168.0.0/1665,536Class C × 256

これらは私設ネットワーク内部で使い、その境界を越えて公衆インターネットへ経路広告しない範囲です。異なる私設ネットワークは同じアドレスを再利用できます。家庭のルーターが 192.168.1.1 を使い、隣の家も同じアドレスを使えるのは、RFC 1918 のおかげです。

プライベートアドレスから公衆IPv4インターネットへ接続する際は、NAT (Network Address Translation) が広く使われます。ただしNATはプライベートアドレス自体の必須要件ではなく、プロキシやアプリケーションゲートウェイ、私設網内通信だけの構成もあります。アドレス共有はIPv4の利用継続に大きく寄与しました。

2011 年 2 月 3 日 — IANA 中央プール枯渇

2011年2月3日、IANA (Internet Assigned Numbers Authority) は通常在庫の最後の5つの /8 ブロックを世界5つの地域インターネットレジストリ (RIR) に分配し、中央の未割当プール枯渇を発表しました。

これは当時の通常在庫がなくなったことを意味し、約43億個の全アドレスが実際のホストで使用中という意味ではありません。その後にIANAへ返却されたアドレスは、別の回収済みアドレス方針でRIRへ再配分される場合があります。「枯渇」後も、次の仕組みでIPv4は運用されています:

  • RFC 1918 + NAT: 家庭・企業内部で有限のプライベート範囲をネットワークごとに再利用
  • CGNAT (Carrier-Grade NAT): ISP等の事業者網でグローバルIPv4アドレスを複数の顧客接続に共有。RFC 6598はこの用途のShared Address Spaceとして100.64.0.0/10を予約
  • IPv4 アドレス移転: RIR の方針に従い、組織間でアドレス資源を移転
  • IPv6 への移行: IPv4を延命する仕組みではなく、128ビットアドレス空間 (約 3.4 × 10^38 個) を持つ後継プロトコルへの移行

IPv6 の普及率は測定元・地域・時期で変わるため、最新値が必要な場合は各測定元の公開統計を確認してください。

特殊なアドレスブロック — 知っておくべき予約範囲

IANA IPv4 Special-Purpose Address Registry には、通常のホスト割り当てに使えない予約済みブロックが多数あります:

表が収まらない場合は、左右にスクロールできます。

ブロック用途RFC
0.0.0.0/8「このネットワーク」(起動時の自己参照)RFC 791
127.0.0.0/8ループバック (localhost)RFC 1122
169.254.0.0/16IPv4リンクローカル (同一リンク内の自動設定)RFC 3927
192.0.2.0/24文書用 (TEST-NET-1)RFC 5737
198.51.100.0/24文書用 (TEST-NET-2)RFC 5737
203.0.113.0/24文書用 (TEST-NET-3)RFC 5737
255.255.255.255/32リミテッドブロードキャストRFC 919

技術文書やブログで一般的な外部アドレスの例を示す際は、RFC 5737の 192.0.2.0/24198.51.100.0/24203.0.113.0/24 を使います。192.168.0.0/16等は私設網そのものを説明する例に適しますが、読者の実ネットワークと衝突し得ます。実在するグローバルアドレスを無断で例に使わないことが重要です。

まとめ

  • RFC 791 (1981): IPv4は32ビットで、歴史的なClass A/B/C形式を定義
  • RFC 950 (1985): サブネットマスクによる組織内分割手順を標準化 (ビットAND演算)
  • 1990 年代初頭: Class B 枯渇危機 + ルーティングテーブル爆発
  • RFC 1519 (1993) → RFC 4632 (2006): CIDRで歴史的クラスに依存しないプレフィックス長と経路集約を導入
  • /24 = プレフィックス 24 ビット = ホスト部 8 ビット = 254 台 (2^8 - 2)
  • RFC 1918 (1996): プライベートアドレス 3 範囲 (10/8, 172.16/12, 192.168/16)
  • 2011年2月3日: IANA中央プール枯渇。NAT / CGNATはIPv4共有、IPv6は後継への移行
  • 文書で外部IPの例を示すときはTEST-NET (192.0.2.0/24等) を使う

参考文献・ソース

記事作成に関する注記

本記事は AI(大規模言語モデル)を編集補助として活用して作成しています。 公開前に編集者が内容を確認していますが、事実誤認・仕様の解釈ミス・最新情報との齟齬が含まれる可能性があります。 重要な判断を行う際は、本文中の一次ソースや公式ドキュメントを必ずご自身でご確認ください。 誤りにお気づきの場合は、お問い合わせフォームよりご連絡いただけると助かります。

🔧 関連ツール

📚 関連記事