ITインフラストラクチャ技術ガイド

第3章：L3ネットワークの設計原理

インターネットの基盤となるIPプロトコルは、今日の形に偶然到達したわけではない。クラスフルアドレッシングからCIDRへの移行、IPv4からIPv6への長期にわたる移行プロセス、ルーティングプロトコルの進化。これらの変遷は、スケーラビリティという根本的な課題への挑戦の歴史である。

さらに、NATという「一時的な解決策」が、現代のネットワークアーキテクチャに与えた影響は計り知れない。技術的には望ましくないとされながらも、なぜNATは広く普及し、今なお重要な役割を果たしているのか。この矛盾を理解することで、技術選択における現実的な判断基準が見えてくる。

3.1 IPアドレス体系の設計制約

クラスフルからCIDRへの必然的進化

IPアドレスの初期設計であるクラスフルアドレッシングは、1980年代のネットワーク規模を前提としていた。しかし、インターネットの急速な拡大により、この設計の限界が明らかになった。CIDR（Classless Inter-Domain Routing）への移行は、単なる技術的改良ではなく、アドレス空間の枯渇という実存的危機への対応だった。

クラスフルアドレッシングの設計思想

クラス別のアドレス配分は、当時のネットワーク組織を反映していた：

クラスA: /8  - 大企業・政府機関（126ネットワーク、各1677万ホスト）
クラスB: /16 - 中規模組織（16,384ネットワーク、各65,534ホスト）
クラスC: /24 - 小規模組織（2,097,152ネットワーク、各254ホスト）

この分類は、組織規模の明確な階層を前提としていた。しかし、実際のネットワーク需要は、この予想を大きく上回った。

アドレス浪費の構造的問題

最も深刻だったのは、クラスBアドレスの浪費である：

  • 実際の需要：多くの組織が必要とするのは数百から数千のホスト
  • クラスCの制約：254ホストでは不足
  • クラスBの過剰：65,534ホストは過大
  • 結果：クラスBアドレスの大量浪費と急速な枯渇

CIDRによる柔軟な分割

CIDRは、ネットワーク部の長さを任意に設定できる可変長サブネットマスクを導入した：

従来：192.168.1.0/24（固定）
CIDR：192.168.1.0/25（128ホスト）
      192.168.1.128/25（128ホスト）

これにより：

  • 効率的な利用：実際の需要に応じたアドレス配分
  • 階層的集約：ルーティングテーブルサイズの抑制
  • 柔軟な成長：将来の拡張を考慮した設計

IPv4枯渇とIPv6移行の現実的判断

IPv4アドレスの枯渇は、理論的な問題ではなく現実の制約となった。2011年のIANA在庫枯渇、各地域での段階的な枯渇。しかし、IPv6への移行は予想よりもはるかに緩慢に進んでいる。この現実を理解することが、現代のネットワーク設計には不可欠である。

IPv4枯渇のタイムライン

2011年：IANA中央在庫枯渇
2012年：RIPE NCC（ヨーロッパ）最終/8配布開始
2014年：APNIC（アジア太平洋）最終/8配布開始
2015年：ARIN（北米）枯渇
2017年：LACNIC（中南米）枯渇
2019年：RIPE NCC最後の通常配布完了（/22配布制限開始、現在は待機リストによる小規模配布のみ継続）

IPv6移行の障壁

技術的には優秀なIPv6の普及が遅れる理由：

  1. デュアルスタック運用の複雑性
    • IPv4とIPv6の両方を維持する必要
    • 監視、セキュリティ、トラブルシューティングの複雑化
    • 運用コストの増大
  2. エコシステムの不完全性
    • 一部のアプリケーションやサービスがIPv4専用
    • CDNやホスティングサービスのIPv6対応状況
    • 古い機器のIPv6非対応
  3. NATによる延命
    • CGN（Carrier Grade NAT）による一時的な解決
    • IPv4アドレス共有技術の発達
    • IPv6移行の緊急性の低下

現実的な移行戦略

段階的移行アプローチ：

フェーズ1：デュアルスタック環境の構築
- 新規システムからIPv6対応
- IPv4との互換性維持
- 運用ノウハウの蓄積

フェーズ2：IPv6優先運用
- 内部通信のIPv6化
- 外部向けサービスのIPv6提供
- IPv4は必要最小限に

フェーズ3：IPv4依存の解消
- レガシーシステムの更新
- IPv4専用サービスの段階的廃止

組織別の判断基準

組織タイプ IPv6優先度 判断要因
ISP・キャリア 高 アドレス枯渇の直接的影響
大企業 中 将来の拡張性とコンプライアンス
中小企業 低 NATによる当面の回避可能性
政府機関 高 標準準拠と長期的戦略

3.2 サブネット設計の最適化理論

アドレス効率とルーティング効率のトレードオフ

サブネット設計は、アドレス空間の効率的利用とルーティングの最適化という、相反する要求のバランスを取る作業である。細かく分割すれば無駄は減るが、ルーティングテーブルは膨大になる。逆に大きなサブネットは、未使用アドレスの浪費を招く。

アドレス効率重視のアプローチ

実際の使用予測に基づく最小限の割り当て：

例：部門別アドレス設計
営業部（50台）： 192.168.1.0/26  （62台分）
技術部（120台）：192.168.1.64/25 （126台分）
管理部（20台）： 192.168.1.192/27（30台分）

利点：

  • アドレス浪費の最小化
  • 詳細なアクセス制御の実現
  • セキュリティの向上

問題：

  • ルーティングエントリの増大
  • 管理の複雑化
  • 将来の拡張困難

ルーティング効率重視のアプローチ

集約可能な大きなサブネットでの設計：

例：フロア別アドレス設計
1階：192.168.1.0/24   （254台分）
2階：192.168.2.0/24   （254台分）
3階：192.168.3.0/24   （254台分）

集約：192.168.0.0/22 として広告

利点：

  • ルーティングテーブルの簡素化
  • 集約による効率化
  • 拡張の容易性

問題：

  • アドレス使用率の低下
  • セキュリティ境界の不明確さ
  • 無駄なブロードキャストトラフィック

可変長サブネットマスク（VLSM）の実践的設計

VLSMは、単一のネットワークアドレス空間内で、異なるサブネットマスク長を使用する技術である。これにより、各サブネットの実際の需要に応じた効率的なアドレス配分が可能となる。

VLSM設計の原則

  1. 大きなサブネットから小さなサブネットへ 
    192.168.1.0/24 を分割する例：
   
ステップ1：大きな需要から配分
サーバー群：192.168.1.0/25   （126台）
   
ステップ2：残りを中程度の需要に
開発部：    192.168.1.128/26  （62台）
   
ステップ3：残りを小さな需要に
管理者：    192.168.1.192/27  （30台）
ゲスト：    192.168.1.224/27  （30台）
  2. 将来の拡張を考慮した余裕
    • 現在の需要の150-200%で設計
    • 成長予測に基づく段階的拡張計画
    • 予備アドレス空間の確保
  3. 管理境界との整合 
    組織構造に対応したアドレス体系：
   
192.168.0.0/16   - 全社
└─ 192.168.1.0/24  - 東京本社
   ├─ 192.168.1.0/25   - サーバー
   ├─ 192.168.1.128/26 - 営業部
   └─ 192.168.1.192/26 - 管理部
└─ 192.168.2.0/24  - 大阪支社

実践的な設計手順

  1. 要件の収集
    • 現在のホスト数
    • 3-5年後の予測
    • セキュリティ要件
    • 管理境界
  2. アドレス空間の計算 
    def calculate_subnet_size(hosts_needed):
    # 必要なホスト数から最適なサブネットサイズを計算
    required_addresses = hosts_needed + 2  # ネットワーク・ブロードキャスト
    subnet_bits = 0
    while (2 ** subnet_bits) < required_addresses:
        subnet_bits += 1
    return 32 - subnet_bits  # プレフィックス長
   
# 使用例
営業部_hosts = 45
営業部_subnet = calculate_subnet_size(45)  # /26 (62ホスト)
  3. 集約可能性の検証
    • 上位階層での集約ルール確認
    • ルーティングプロトコルとの整合性
    • 将来の集約計画との調整

3.3 スタティックルーティングの適用範囲

管理コストと安定性のバランス

スタティックルーティングは、最もシンプルなルーティング手法である。設定が容易で、動作が予測可能であり、オーバーヘッドが最小限である。しかし、ネットワークの規模や動的な変化に対する適応性には限界がある。適切な適用範囲を理解することが、効果的なネットワーク設計の鍵となる。

スタティックルーティングの特性

利点：

  • 予測可能性：経路が固定され、動作が確実
  • 低オーバーヘッド：プロトコル処理が不要
  • セキュリティ：意図しない経路変更の回避
  • シンプルさ：理解と管理が容易

制約：

  • 手動管理：経路変更時の手作業
  • 障害時の非適応性：自動的な迂回路への切り替え不可
  • 拡張性の限界：エントリ数の増大による管理困難

管理コストの定量化

スタティックルート管理の工数見積もり：

小規模ネットワーク（ルート数 < 20）：
- 初期設定：2-4時間
- 月次メンテナンス：1-2時間
- 障害対応：平均30分/件

中規模ネットワーク（ルート数 20-100）：
- 初期設定：1-2日
- 月次メンテナンス：4-8時間
- 障害対応：平均1-2時間/件

小規模環境での最適な適用パターン

スタティックルーティングが最も効果を発揮するのは、構造が比較的単純で、変更頻度の低いネットワーク環境である。

適用パターン1：ハブ・スポーク構成

本社
 │
 ├─ 支社A
 ├─ 支社B
 └─ 支社C

本社ルーター設定：
ip route 192.168.10.0 255.255.255.0 支社A_WAN_IP
ip route 192.168.20.0 255.255.255.0 支社B_WAN_IP
ip route 192.168.30.0 255.255.255.0 支社C_WAN_IP

各支社ルーター設定：
ip route 0.0.0.0 0.0.0.0 本社_WAN_IP  # デフォルトルート

このパターンの特徴：

  • 各支社間の通信は本社経由
  • 管理の集中化
  • 障害の影響範囲が明確

適用パターン2：デュアルホーム構成

ISP-A ─┐    ┌─ インターネット
        │    │
       ルーターA
        │    │
       内部NW
        │    │
       ルーターB
        │    │
ISP-B ─┘    └─ インターネット

プライマリ経路（ISP-A優先）：
ip route 0.0.0.0 0.0.0.0 ISP-A_GW_IP 10
ip route 0.0.0.0 0.0.0.0 ISP-B_GW_IP 20  # バックアップ

適用パターン3：セグメント間接続

DMZ（192.168.100.0/24）
 │
ファイアウォール
 │
内部NW（192.168.1.0/24）

ファイアウォール設定：
# 内部からDMZへの経路は自動（直接接続）
# DMZから内部への通信は制限
# 特定の管理通信のみ許可
ip route 192.168.1.10 255.255.255.255 内部管理サーバー_IP

運用上の工夫

  1. 標準化された命名規則 
    ルート名：[目的地]_via_[次ホップ]
例：OSAKA_BRANCH_via_MPLS_GW
  2. 変更管理プロセス
    • 変更前の経路表保存
    • テスト手順の標準化
    • ロールバック手順の準備
  3. 監視の重要性
    • 経路の到達性確認
    • 代替経路の定期テスト
    • パフォーマンス監視

3.4 ダイナミックルーティングの選択基準

OSPF：エリア設計とLSDBサイズの管理

OSPF（Open Shortest Path First）は、リンクステート型ルーティングプロトコルの代表例である。全てのルーターが同一のトポロジー情報（LSDB：Link State Database）を持ち、最短経路を計算する。しかし、ネットワーク規模の拡大に伴い、LSDBサイズの管理が重要な課題となる。

OSPFの基本動作とスケーラビリティ課題

OSPFでは、各ルーターが以下の情報を管理する：

  • LSA（Link State Advertisement）：リンク状態情報
  • LSDB：全LSAの集合
  • SPFアルゴリズム：最短経路計算

問題は、ネットワーク規模とLSDBサイズが比例関係にあることである：

ネットワーク規模とLSDBサイズの関係：
- 10ルーター：約50-100 LSA
- 50ルーター：約250-500 LSA  
- 100ルーター：約500-1000 LSA
- 500ルーター：約2500-5000 LSA

LSDBサイズの増大による影響：

  • メモリ使用量の増加
  • SPF計算時間の延長
  • コンバージェンス時間の遅延
  • CPU負荷の増大

エリア設計による階層化

OSPFエリアは、LSDBサイズを制御するための階層化メカニズムである：

エリア0（バックボーン）
├─ エリア1（営業部門）
├─ エリア2（技術部門） 
└─ エリア3（製造部門）

エリア境界の設計指針

  1. 地理的境界との整合
    • 物理的な場所との対応
    • WAN回線での分離
    • 管理組織との整合
  2. トラフィックフローの考慮 
    良い例：部門内通信が多い構成
エリア1内通信：80%
エリア間通信：20%
   
悪い例：エリア間通信が多い構成
エリア1内通信：30%
エリア間通信：70%
  3. エリアサイズの目安
    • エリア内ルーター数：50台以下
    • LSAエントリ数：500個以下
    • SPF計算時間：100ms以下

LSDBサイズ最適化技術

  1. LSAフィルタリング 
    area 1 range 192.168.1.0 255.255.255.0 not-advertise
# エリア1の詳細経路を他エリアに広告しない
  2. スタブエリアの活用 
    area 2 stub
# 外部LSAを受信せず、デフォルトルートで代替
  3. 経路集約 
    area 1 range 192.168.0.0 255.255.252.0
# /24の複数エリアを/22として集約広告

BGP：ポリシー制御とスケーラビリティ

BGP（Border Gateway Protocol）は、自律システム（AS）間のルーティングを制御するプロトコルである。技術的な最短経路よりも、政策的・経済的な判断基準でのルーティング制御を重視する。

BGPの設計思想

BGPは「到達可能性」の情報交換プロトコルであり、「最適性」は二次的である：

  • ポリシーベース：技術的最適性より政策を優先
  • 安定性重視：頻繁な経路変更を抑制
  • スケーラビリティ：インターネット規模への対応

BGP属性による経路制御

BGPでは複数の属性により経路選択を制御する：

経路選択アルゴリズム（優先順）：
1. Weight（Cisco独自）
2. Local Preference（AS内優先度）
3. Locally Originated（自AS発生）
4. AS Path Length（経由AS数）
5. Origin（経路の発生源）
6. MED（Multi-Exit Discriminator）
7. eBGP < iBGP
8. IGPコスト
9. BGP Router ID

実践的なポリシー設計例

  1. プロバイダー選択制御 
    # プライマリISP優先設定
router bgp 65001
neighbor 203.0.113.1 remote-as 65002  # ISP-A
neighbor 203.0.113.1 weight 100
   
neighbor 198.51.100.1 remote-as 65003  # ISP-B  
neighbor 198.51.100.1 weight 50      # バックアップ
  2. トラフィックエンジニアリング 
    # 特定宛先の経路制御
ip prefix-list CUSTOMER_ROUTES permit 192.0.2.0/24
   
route-map OUTBOUND_POLICY permit 10
match ip address prefix-list CUSTOMER_ROUTES
set local-preference 200

スケーラビリティ対策

  1. 経路集約 
    # 複数の経路を集約して広告
network 192.168.0.0 mask 255.255.252.0
# 192.168.0.0/24, 192.168.1.0/24, 192.168.2.0/24, 192.168.3.0/24
# を 192.168.0.0/22 として集約
  2. BGPコミュニティ 
    # 経路にメタ情報を付与
route-map SET_COMMUNITY permit 10
set community 65001:100  # 顧客経路
set community 65001:200  # 内部経路
  3. Route Reflector 
    # iBGPのフルメッシュを回避
router bgp 65001
bgp cluster-id 1
neighbor 10.0.0.2 route-reflector-client
neighbor 10.0.0.3 route-reflector-client

使い分けの明確な判断基準

プロトコル選択マトリクス

要件 スタティック OSPF BGP
ネットワーク規模 <50ルーター 50-500ルーター 500+ルーター
変更頻度 低 中 高
管理者スキル 初級 中級 上級
収束時間 手動 秒-分 分-時間
ポリシー制御 限定的 中程度 高度
運用コスト 低 中 高

具体的な選択指針

  1. 小規模・安定環境：スタティック
    • 支社・支店ネットワーク
    • 変更頻度が月1回以下
    • 単純なトポロジー
  2. 中規模・動的環境：OSPF
    • 企業内ネットワーク
    • 冗長化されたトポロジー
    • 定期的な変更が発生
  3. 大規模・ポリシー重視：BGP
    • ISP・キャリアネットワーク
    • 複数AS間の接続
    • 詳細なトラフィック制御が必要

組み合わせでの運用

実際のネットワークでは、複数のプロトコルを組み合わせて使用する：

典型的な企業ネットワーク：
- 内部LAN：OSPF（自動経路学習）
- WAN接続：スタティック（安定性重視）
- インターネット接続：BGP（プロバイダーとの接続）
- データセンター：OSPF + BGP（ハイブリッド）

3.5 NAT/NAPTの功罪と設計への影響

ステートフル性がもたらすボトルネック

NAT（Network Address Translation）とNAPT（Network Address Port Translation）は、IPv4アドレス枯渇への対症療法として開発された。しかし、この「一時的な解決策」は、現代のネットワークアーキテクチャに根本的な影響を与えている。

NATの基本動作とステート管理

NATデバイスは、内部と外部のアドレス変換テーブルを維持する：

NATテーブルの例：
内部IP:Port    外部IP:Port    宛先IP:Port     状態
192.168.1.10:1234 → 203.0.113.1:5678 → 198.51.100.1:80  ESTABLISHED
192.168.1.11:1235 → 203.0.113.1:5679 → 198.51.100.2:443 ESTABLISHED

このステート管理により、NATは以下の制約を抱える：

  1. メモリ使用量の増大 
    1セッションあたり：約100-200バイト
100万セッション：約100-200MB
  2. 処理能力の限界
    • セッション確立レート：数万-数十万/秒
    • テーブル検索のオーバーヘッド
    • セッション削除のタイミング制御
  3. 単一障害点化
    • NATデバイスの障害で全通信停止
    • セッション情報の同期困難
    • スケールアウトの制約

パフォーマンスへの影響

NAT処理のオーバーヘッド：
- アドレス変換：1-5μs/パケット
- セッション作成：100-500μs/セッション
- テーブル検索：0.1-1μs/パケット

スループット制限：
- 小規模NAT：1-10Gbps
- 中規模NAT：10-40Gbps  
- 大規模NAT：40-100Gbps

NAT traversalとアプリケーション設計

NATの存在は、アプリケーション設計に大きな制約を課す。特に、ピアツーピア通信やリアルタイム通信では、複雑な回避技術が必要となる。

NAT traversalの技術分類

  1. Application Layer Gateway（ALG）
    • NATデバイスがアプリケーション層を解析
    • FTP、SIP、H.323等の特定プロトコルに対応
    • プロトコル固有の実装が必要
  2. STUN（Session Traversal Utilities for NAT） ``` STUN動作フロー：
    1. クライアント → STUNサーバー：自身の外部アドレス問い合わせ
    2. STUNサーバー → クライアント：外部IP:Port通知
    3. クライアント：外部アドレスを相手に通知
    4. 直接通信開始 ```
  3. TURN（Traversal Using Relays around NAT） ``` TURN動作フロー：
    1. クライアントA → TURNサーバー：リレー要求
    2. TURNサーバー：リレーアドレス割り当て
    3. クライアントB → TURNサーバー：リレー経由でAに送信
    4. TURNサーバー → クライアントA：データ転送 ```
  4. ICE（Interactive Connectivity Establishment）
    • STUN、TURN、直接接続を組み合わせ
    • 最適な通信経路を自動選択
    • WebRTC等で標準採用

アプリケーション設計への影響

  1. サーバー・クライアント型の優位
    • クライアントから発信する通信が容易
    • サーバーは固定IPで外部公開
    • NAT制約を回避できる設計
  2. プッシュ通知の必要性 
    従来（NAT前）：
サーバー → クライアント：直接接続
   
現在（NAT後）：
サーバー → プッシュサービス → クライアント
  3. 接続維持メカニズム
    • Keep-alive機能の実装
    • セッション切断の検出と再接続
    • 長時間接続の維持困難

現代的な解決アプローチ

  1. クラウドサービスの活用
    • 中継サーバーによる間接通信
    • WebSocketやSSE等のHTTPベース通信
    • CDNを活用したエッジ処理
  2. IPv6による根本解決
    • エンドツーエンド通信の復活
    • NAT traversalの不要化
    • しかし普及には時間を要する

まとめ

L3ネットワーク技術の発展は、スケーラビリティと現実的制約の間での絶え間ない調整の歴史である。IPv4アドレス枯渇という制約から生まれたCIDRやNAT、IPv6という根本的解決策の緩慢な普及、ルーティングプロトコルの進化。

これらの技術選択において一貫しているのは、理論的最適性よりも実装可能性と運用性を重視する姿勢である。NATは技術的には望ましくないが、現実的な解決策として広く受け入れられた。IPv6は技術的には優秀だが、移行コストの高さから普及が遅れている。

現代のネットワーク設計においては、この「現実と理想のギャップ」を理解し、段階的な移行戦略を立案することが重要である。技術的完璧性を追求するのではなく、現在の制約条件下で最善の選択を行い、将来の発展に備える柔軟性を確保する。これがL3ネットワーク設計の本質的な思想である。

次章では、IPネットワークの上位層である名前解決システムの設計と実装を探る。DNSの分散データベースとしての本質、セキュリティ課題への対応、そして現代的なサービス発見手法までを詳細に解析する。

Edit this page on GitHub