IPアドレッシング

IPアドレスはインターネット上の「住所」。IPv4/IPv6、サブネット、CIDR、NAT、DHCPを理解して、ネットワーク設計の基盤を固める。

この章で学ぶこと

• IPv4とIPv6の仕組みと違いを理解する
• サブネットとCIDR表記を把握する
• NATとDHCPの役割を学ぶ
• サブネット計算を実務レベルで行えるようにする
• VPCネットワーク設計のベストプラクティスを学ぶ
• IPv6移行戦略を理解する
• IPアドレスに関連するトラブルシューティングを習得する

前提知識

• OSI参照モデルとTCP/IPモデル（./01-osi-and-tcpip-model.md）
• 2進数と16進数の変換方法
• ネットワーク層（L3）の基礎概念

1. IPv4

1.1 基本構造

IPv4 アドレス:
  → 32ビット（4バイト）
  → ドット区切り10進表記: 192.168.1.100
  → 約43億個（2^32 = 4,294,967,296）→ 枯渇問題

  192   . 168   . 1     . 100
  11000000.10101000.00000001.01100100

  各オクテット: 0〜255 の範囲
  → 0.0.0.0 〜 255.255.255.255

1.2 IPアドレスのクラス（歴史的分類）

クラスフルアドレッシング（現在は使われないが知識として重要）:

クラスフルの問題点:
    Class A: 16,777,214台分 → 大きすぎて無駄
    Class C: 254台分 → 小さすぎて足りない
    → IPアドレスの大幅な無駄遣い
    → これを解決するのがCIDR（後述）

1.3 特殊なIPアドレス

特殊なアドレス:

プライベートIPアドレス（RFC 1918）:

なぜプライベートIPが必要か:
    → IPv4アドレスは約43億個（全人口に1つも配れない）
    → 社内ネットワークでは同じプライベートIPを再利用可能
    → NATを使ってグローバルIPに変換してインターネットに出る
    → 外部から直接アクセスされないため、セキュリティ上も有利

  実務での使い分け:
    10.0.0.0/8:
      → 大規模企業ネットワーク
      → AWS VPC のデフォルト推奨レンジ
      → クラウドで最も一般的

    172.16.0.0/12:
      → Docker のデフォルト（172.17.0.0/16）
      → 中規模ネットワーク

    192.168.0.0/16:
      → 家庭用ルーター（192.168.0.0/24 や 192.168.1.0/24）
      → 小規模オフィス

1.4 IPv4ヘッダーの詳細

IPv4 ヘッダー構造（20バイト〜60バイト）:

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

各フィールドの詳細:
    Version（4ビット）: 4（IPv4を示す）
    IHL（4ビット）: ヘッダー長（32ビットワード単位）
      最小: 5（= 20バイト、オプションなし）
      最大: 15（= 60バイト、オプション40バイト）

    DSCP（6ビット）: Differentiated Services Code Point
      → QoS（サービス品質）の制御に使用
      → EF（Expedited Forwarding）= 音声トラフィック優先
      → AF（Assured Forwarding）= 確実な転送
      → BE（Best Effort）= 通常のトラフィック

    ECN（2ビット）: Explicit Congestion Notification
      → ルーターがパケットを落とさずに輻輳を通知

    TTL（8ビット）: Time To Live
      → ルーターを通過するたびに1減算
      → 0になったらパケットを破棄 + ICMP Time Exceeded を返す
      → ループ防止の仕組み
      → 初期値: Linux=64, Windows=128, Cisco=255

    プロトコル（8ビット）:
      1  = ICMP
      6  = TCP
      17 = UDP
      47 = GRE
      50 = ESP（IPsec暗号化ペイロード）
      51 = AH（IPsec認証ヘッダー）
      89 = OSPF

2. サブネットとCIDR

2.1 CIDR（Classless Inter-Domain Routing）の基本

CIDR（Classless Inter-Domain Routing）:
  1993年にRFC 1519で導入
  → クラスフルアドレッシングの無駄を排除
  → 任意の位置でネットワーク部とホスト部を分割

  表記: IPアドレス/プレフィックス長
  例: 192.168.1.0/24
    → /24 = 最初の24ビットがネットワーク部
    → 残り8ビットがホスト部
    → 使用可能ホスト数: 2^8 - 2 = 254
    → -2 の理由: ネットワークアドレスとブロードキャストアドレスを除く

2.2 サブネットマスクの計算

サブネットマスクの一覧:

計算方法:
  使用可能ホスト数 = 2^(32 - プレフィックス長) - 2

  例: /24 の場合
    ホスト部: 32 - 24 = 8ビット
    ホスト数: 2^8 - 2 = 254

  例: /27 の場合
    ホスト部: 32 - 27 = 5ビット
    ホスト数: 2^5 - 2 = 30

2.3 サブネット分割の実践

問題: 192.168.10.0/24 を4つのサブネットに分割せよ

  ステップ1: 必要なビット数を計算
    4サブネット → 2^n >= 4 → n=2（2ビット借りる）
    新しいプレフィックス: /24 + 2 = /26

  ステップ2: 各サブネットの計算
    /26 → ホスト部 = 6ビット → ホスト数 = 62

    サブネット1: 192.168.10.0/26
      ネットワーク: 192.168.10.0
      最初のホスト: 192.168.10.1
      最後のホスト: 192.168.10.62
      ブロードキャスト: 192.168.10.63

    サブネット2: 192.168.10.64/26
      ネットワーク: 192.168.10.64
      最初のホスト: 192.168.10.65
      最後のホスト: 192.168.10.126
      ブロードキャスト: 192.168.10.127

    サブネット3: 192.168.10.128/26
      ネットワーク: 192.168.10.128
      最初のホスト: 192.168.10.129
      最後のホスト: 192.168.10.190
      ブロードキャスト: 192.168.10.191

    サブネット4: 192.168.10.192/26
      ネットワーク: 192.168.10.192
      最初のホスト: 192.168.10.193
      最後のホスト: 192.168.10.254
      ブロードキャスト: 192.168.10.255

VLSM（Variable Length Subnet Mask）:
  サブネットごとに異なるマスク長を使う技法

  例: 以下のネットワーク要件を 10.1.0.0/16 で実現
    部署A: 500台 → /23（510ホスト）
    部署B: 200台 → /24（254ホスト）
    部署C: 50台  → /26（62ホスト）
    部署D: 10台  → /28（14ホスト）
    P2Pリンク: 2台 → /30（2ホスト）

  大きなサブネットから順に割り当てるのがベストプラクティス:
    部署A: 10.1.0.0/23   (10.1.0.1 〜 10.1.1.254)
    部署B: 10.1.2.0/24   (10.1.2.1 〜 10.1.2.254)
    部署C: 10.1.3.0/26   (10.1.3.1 〜 10.1.3.62)
    部署D: 10.1.3.64/28  (10.1.3.65 〜 10.1.3.78)
    P2P:   10.1.3.80/30  (10.1.3.81 〜 10.1.3.82)

2.4 サブネット計算の実務ツール

# ipcalc コマンド（Linux）
$ ipcalc 192.168.1.0/24
Address:   192.168.1.0          11000000.10101000.00000001. 00000000
Netmask:   255.255.255.0 = 24   11111111.11111111.11111111. 00000000
Wildcard:  0.0.0.255            00000000.00000000.00000000. 11111111
=>
Network:   192.168.1.0/24       11000000.10101000.00000001. 00000000
HostMin:   192.168.1.1          11000000.10101000.00000001. 00000001
HostMax:   192.168.1.254        11000000.10101000.00000001. 11111110
Broadcast: 192.168.1.255        11000000.10101000.00000001. 11111111
Hosts/Net: 254                   Class C, Private Internet
 
# sipcalc コマンド（より詳細な情報）
$ sipcalc 10.0.0.0/16
-[ipv4 : 10.0.0.0/16] - 0
 
[CIDR]
Host address            - 10.0.0.0
Network address         - 10.0.0.0
Network mask            - 255.255.0.0
Broadcast address       - 10.0.255.255
Addresses in network    - 65536
Network range           - 10.0.0.0 - 10.0.255.255
Usable range            - 10.0.0.1 - 10.0.255.254

# Pythonでのサブネット計算
import ipaddress
 
# ネットワーク情報
network = ipaddress.IPv4Network('192.168.1.0/24')
print(f"ネットワーク: {network}")
print(f"ネットマスク: {network.netmask}")
print(f"ホスト数: {network.num_addresses - 2}")
print(f"ブロードキャスト: {network.broadcast_address}")
print(f"最初のホスト: {list(network.hosts())[0]}")
print(f"最後のホスト: {list(network.hosts())[-1]}")
 
# サブネット分割
print("\n/24 を /26 に分割:")
for subnet in network.subnets(prefixlen_diff=2):
    print(f"  {subnet} (ホスト数: {subnet.num_addresses - 2})")
 
# IPアドレスがサブネットに含まれるか確認
ip = ipaddress.IPv4Address('192.168.1.100')
print(f"\n{ip} は {network} に含まれる: {ip in network}")
 
# CIDRの集約（スーパーネッティング）
networks = [
    ipaddress.IPv4Network('192.168.0.0/24'),
    ipaddress.IPv4Network('192.168.1.0/24'),
    ipaddress.IPv4Network('192.168.2.0/24'),
    ipaddress.IPv4Network('192.168.3.0/24'),
]
collapsed = list(ipaddress.collapse_addresses(networks))
print(f"\n集約結果: {collapsed}")
# → [IPv4Network('192.168.0.0/22')]

3. IPv6

3.1 基本構造

IPv6 アドレス:
  → 128ビット（16バイト）
  → コロン区切り16進表記: 2001:0db8:85a3:0000:0000:8a2e:0370:7334
  → 8グループ × 16ビット = 128ビット
  → 約3.4×10^38個 → 地球上の砂粒1つ1つにIPアドレスを割り当てても余る

省略ルール:
  ルール1: 各グループの先頭の0を省略
    2001:0db8:0000:0000:0000:0000:0000:0001
    → 2001:db8:0:0:0:0:0:1

  ルール2: 連続する0のグループを :: で省略（1回のみ使用可）
    2001:db8:0:0:0:0:0:1
    → 2001:db8::1

  省略の例:
    2001:0db8:0000:0000:0000:0000:0000:0001 → 2001:db8::1
    fe80:0000:0000:0000:0000:0000:0000:0001 → fe80::1
    0000:0000:0000:0000:0000:0000:0000:0001 → ::1（ループバック）
    0000:0000:0000:0000:0000:0000:0000:0000 → ::（未指定アドレス）

3.2 IPv6アドレスの種類

マルチキャストの重要なアドレス:
  ff02::1   → 全ノード（リンクローカル）
  ff02::2   → 全ルーター（リンクローカル）
  ff02::fb  → mDNS
  ff02::1:ff00:0/104 → Solicited-Node（近隣探索用）

3.3 IPv6ヘッダー

IPv6 ヘッダー（固定40バイト）:

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

IPv4 vs IPv6 ヘッダーの比較:

IPv6の改善点:
    ① ヘッダーが固定長 → ルーターの処理が高速
    ② チェックサム廃止 → L2/L4でチェックするので不要
    ③ フラグメンテーション → 送信元でのみ行う（ルーターの負荷軽減）
    ④ 拡張ヘッダー → 必要な機能だけチェーン接続

3.4 IPv6の自動設定（SLAAC）

SLAAC（Stateless Address Autoconfiguration）:
  → DHCPサーバーなしでIPv6アドレスを自動設定
  → RFC 4862で定義

  手順:
  1. インターフェース起動時:
     → リンクローカルアドレスを生成
     → fe80:: + インターフェースID（EUI-64 or ランダム）

  2. DAD（Duplicate Address Detection）:
     → 生成したアドレスが重複していないか確認
     → Neighbor Solicitation を送信

  3. Router Solicitation（RS）を送信:
     → 「ルーターさん、プレフィックスを教えて」

  4. ルーターからRouter Advertisement（RA）を受信:
     → プレフィックス: 2001:db8:1::/64
     → デフォルトゲートウェイ
     → DNS情報（RDNSS）

  5. グローバルアドレスを生成:
     → プレフィックス + インターフェースID
     → 2001:db8:1::a1b2:c3d4:e5f6:7890

  EUI-64 vs プライバシー拡張:
    EUI-64: MACアドレスからインターフェースIDを生成
      → 00:1A:2B:3C:4D:5E → 021A:2BFF:FE3C:4D5E
      → プライバシーの問題（MACアドレスが推測可能）

    プライバシー拡張（RFC 8981）:
      → ランダムなインターフェースIDを使用
      → 定期的にアドレスを変更
      → 追跡が困難
      → 現在のOS標準（Windows, macOS, Linux）

3.5 IPv4 → IPv6 移行技術

移行技術の全体像:

  ① デュアルスタック:
     → IPv4とIPv6を同時に運用
     → 最もシンプルで推奨される方法
     → 全ての機器がIPv4/IPv6両方に対応する必要あり

     アプリケーションの接続順序（Happy Eyeballs / RFC 8305）:
       1. DNS でAレコード（IPv4）とAAAAレコード（IPv6）を同時に問い合わせ
       2. IPv6接続を先に試行（250ms先行開始）
       3. IPv6が遅ければIPv4にフォールバック
       → ユーザーに遅延を感じさせない

  ② トンネリング:
     → IPv6パケットをIPv4パケットに包んで転送
     → IPv4しかないネットワークを通過

     6in4: 手動トンネル（固定エンドポイント）
     6to4: 自動トンネル（2002::/16 使用、非推奨）
     6rd:  ISP向け自動トンネル
     Teredo: NAT越えトンネル（UDP使用）
     DS-Lite: IPv4 over IPv6（ISP向け）

  ③ NAT64/DNS64:
     → IPv6オンリー環境からIPv4サイトにアクセス
     → DNS64: AAAAレコードがないドメインに合成AAAAを返す
     → NAT64: IPv6 → IPv4 のアドレス変換

     例:
       IPv6クライアント → DNS64 → 64:ff9b::93.184.216.34
       → NAT64ゲートウェイ → 93.184.216.34（IPv4サーバー）

  ④ 464XLAT:
     → スマートフォンで広く使用
     → CLAT（クライアント側NAT46）+ PLAT（プロバイダ側NAT64）
     → IPv4アプリがIPv6ネットワーク上で動作可能

移行の現状（2025年時点）:
  Google IPv6統計: 全世界で約45%のユーザーがIPv6
  日本: 約50%以上がIPv6対応
  米国: 約50%以上がIPv6対応
  → モバイルネットワークではIPv6が主流になりつつある
  → T-Mobile, Reliance Jio はIPv6オンリー

4. NAT（Network Address Translation）

4.1 NATの基本

NAT = プライベートIPとグローバルIPの変換

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

4.2 NATの種類

① 静的NAT（Static NAT / 1対1 NAT）:
  → 1つのプライベートIP ↔ 1つのグローバルIP
  → 固定的な対応付け
  → サーバー公開時に使用

  例:
  192.168.1.10 ←→ 203.0.113.10
  192.168.1.11 ←→ 203.0.113.11

② 動的NAT（Dynamic NAT）:
  → プライベートIP → グローバルIPプールから動的に割り当て
  → グローバルIPが足りないと接続不可

③ NAPT / PAT（Network Address Port Translation / Port Address Translation）:
  → 最も一般的なNAT
  → 複数のプライベートIP → 1つのグローバルIP
  → ポート番号で識別

  NAT変換テーブル:

→ 同じ内部IPでもポートが異なれば別の変換エントリ
  → 理論上65535個の同時接続が可能（実際はもっと少ない）

④ CGN / CGNAT（Carrier-Grade NAT）:
  → ISPレベルでの大規模NAT
  → 100.64.0.0/10 を使用
  → IPv4アドレスの枯渇対策として導入
  → 問題点:
    - ログの保存が困難（誰がどのアドレスを使ったか）
    - P2P通信がさらに困難に
    - ゲームやVoIPの品質低下

4.3 NATのメリット・デメリット

メリット:
  ✓ IPv4アドレスの節約（1つのグローバルIPで多数のデバイスがインターネット接続）
  ✓ 内部ネットワークの隠蔽（外部から内部構造が見えない）
  ✓ セキュリティの向上（外部からの直接アクセスをブロック）
  ✓ 内部ネットワーク変更の自由度（ISP変更時にグローバルIPだけ変更）

デメリット:
  ✗ P2P通信が困難（NATトラバーサルが必要）
  ✗ 外部からの接続開始が不可（ポートフォワーディング/UPnP必要）
  ✗ アプリケーション層プロトコルとの相性問題
    → FTPアクティブモード（データ接続が外部→内部）
    → SIP/RTP（VoIP）
  ✗ エンドツーエンドの原則を破壊
  ✗ IPsec との相性問題（ESP暗号化でポート番号が見えない）
  ✗ ログの追跡が困難（同じグローバルIPを共有）

4.4 NATトラバーサル

NAT越えの技術:

  ① STUN（Session Traversal Utilities for NAT）:
     → 自分のパブリックIPとポートを知る
     → STUNサーバーに問い合わせ
     → WebRTCで使用

     クライアント ─→ STUNサーバー
       「私のパブリックアドレスは？」
     ← 203.0.113.1:10001

  ② TURN（Traversal Using Relays around NAT）:
     → STUNが失敗した場合のフォールバック
     → リレーサーバーを経由して通信
     → 帯域を消費するが確実

  ③ ICE（Interactive Connectivity Establishment）:
     → STUN + TURN を組み合わせた接続確立フレームワーク
     → WebRTC の標準
     → 最も効率的な経路を自動選択

  ④ UPnP（Universal Plug and Play）:
     → アプリケーションがルーターにポートフォワーディングを依頼
     → セキュリティ上の懸念あり（悪意のあるソフトが穴を開ける）

  ⑤ ポートフォワーディング:
     → ルーターの特定ポートを内部ホストに転送
     → 手動設定が必要
     → サーバー公開時の基本テクニック

  NATタイプ（RFC 3489 / RFC 5780）:
    Full Cone NAT: 最も緩い（一度マッピングされれば誰でもアクセス可能）
    Restricted Cone NAT: 内部から送信した相手のみ応答可能
    Port Restricted Cone NAT: 相手のIPとポートの両方を確認
    Symmetric NAT: 宛先ごとに異なるマッピング（最も厳しい）

4.5 AWSでのNAT

AWS VPC における NAT:

  ① NAT Gateway:
     → マネージドサービス
     → プライベートサブネットからインターネットへのアウトバウンド通信
     → 自動スケーリング、高可用性
     → 料金: 時間課金 + データ処理課金

     構成例:

② NAT Instance（EC2ベース、レガシー）:
     → EC2インスタンスでNATを実装
     → 低コストだが管理が必要
     → Source/Dest Checkを無効にする必要がある

  ルートテーブル:
    パブリックサブネット:
      0.0.0.0/0 → Internet Gateway

    プライベートサブネット:
      0.0.0.0/0 → NAT Gateway

5. DHCP

5.1 DHCPの基本動作

DHCP（Dynamic Host Configuration Protocol）:
  → IPアドレスを自動的に割り当てる
  → RFC 2131で定義
  → ポート: サーバー 67/UDP、クライアント 68/UDP

  DORA プロセス:

│                                           │
         │── ① Discover（ブロードキャスト） ──────→  │
         │   src: 0.0.0.0:68                         │
         │   dst: 255.255.255.255:67                 │
         │   「IPアドレスください」                    │
         │                                           │
         │←── ② Offer ──────────────────────────── │
         │   「192.168.1.100 を使っていいよ」        │
         │   サブネット: 255.255.255.0               │
         │   ゲートウェイ: 192.168.1.1               │
         │   DNS: 8.8.8.8                            │
         │   リース: 86400秒（24時間）               │
         │                                           │
         │── ③ Request（ブロードキャスト） ──────→   │
         │   「192.168.1.100 を使います」             │
         │   （複数DHCPサーバーがある場合の選択通知） │
         │                                           │
         │←── ④ Acknowledge ─────────────────────  │
         │   「了解。リース開始」                     │
         │                                           │

  なぜRequestもブロードキャストか:
    → 複数のDHCPサーバーが存在する場合
    → 選ばれなかったサーバーに「別のサーバーを選びました」と通知
    → 選ばれなかったサーバーはOfferしたアドレスを解放

5.2 DHCPの詳細な動作

割り当て情報（DHCPオプション）:

リース更新プロセス:
  リース期間: T（例: 24時間）

  T/2（12時間）: Renewal（更新）
    → クライアントがDHCPサーバーにユニキャストで更新要求
    → サーバーがACKを返せばリース延長

  7T/8（21時間）: Rebinding（再バインド）
    → Renewalが失敗した場合
    → ブロードキャストで任意のDHCPサーバーに要求

  T（24時間）: リース期限切れ
    → IPアドレスを解放
    → DORAプロセスをやり直し

DHCPリレーエージェント:
  問題: DHCPはブロードキャストベース → ルーターを越えない

  解決策: DHCPリレーエージェント（ip helper-address）
    → ルーターがブロードキャストを受信
    → ユニキャストでDHCPサーバーに転送
    → 異なるサブネットのDHCPサーバーを使用可能

  Cisco IOS設定例:
    interface GigabitEthernet0/1
      ip helper-address 10.0.0.5   ← DHCPサーバーのIP

5.3 DHCP設定の実務

# Linux: dhcpd.conf の設定例
# /etc/dhcp/dhcpd.conf
 
# グローバル設定
default-lease-time 86400;     # 24時間
max-lease-time 172800;        # 48時間（最大）
option domain-name "example.local";
option domain-name-servers 8.8.8.8, 8.8.4.4;
 
# サブネット定義
subnet 192.168.1.0 netmask 255.255.255.0 {
    range 192.168.1.100 192.168.1.200;  # 動的割り当て範囲
    option routers 192.168.1.1;          # デフォルトゲートウェイ
    option subnet-mask 255.255.255.0;
}
 
# 固定割り当て（MACアドレスベース）
host webserver {
    hardware ethernet 00:1A:2B:3C:4D:5E;
    fixed-address 192.168.1.10;
}
 
host dbserver {
    hardware ethernet 00:6F:7G:8H:9I:0J;
    fixed-address 192.168.1.20;
}

# DHCP関連のトラブルシューティングコマンド
 
# 現在のDHCPリース情報を確認
$ cat /var/lib/dhclient/dhclient.leases
 
# DHCPリースの解放と再取得（Linux）
$ sudo dhclient -r eth0           # リース解放
$ sudo dhclient eth0              # リース再取得
 
# Windows
> ipconfig /release               # リース解放
> ipconfig /renew                 # リース再取得
> ipconfig /all                   # 詳細情報表示
 
# macOS
$ sudo ipconfig set en0 DHCP      # DHCPリース更新
$ ipconfig getpacket en0           # DHCP情報表示

6. ルーティングの基礎

6.1 ルーティングテーブル

ルーティングテーブル = パケットの宛先に応じた転送先の一覧

  例（Linux）:
  $ ip route show
  default via 192.168.1.1 dev eth0 proto dhcp metric 100
  10.0.0.0/8 via 10.1.1.1 dev tun0
  172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
  192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.100

  各エントリの意味:
    default via 192.168.1.1:
      → デフォルトルート（他のルートに一致しない宛先はここへ）
      → 一般的にインターネットへの出口

    10.0.0.0/8 via 10.1.1.1:
      → 10.x.x.x 宛はVPNトンネル経由

    172.17.0.0/16 dev docker0:
      → Dockerコンテナへのルート

    192.168.1.0/24 dev eth0:
      → ローカルネットワーク（直接接続）

ルーティングの決定方法（ロンゲストマッチ）:
  宛先: 10.0.1.50

  ルートテーブル:
    10.0.0.0/8     → ルートA
    10.0.1.0/24    → ルートB
    10.0.1.48/28   → ルートC
    default        → ルートD

  → ルートC が選択される（最も長いプレフィックスが一致）
  → これが「ロンゲストプレフィックスマッチ」

6.2 静的ルーティングと動的ルーティング

静的ルーティング:
  → 管理者が手動でルートを設定
  → 小規模ネットワークで使用
  → 設定が簡単だが、障害時の自動切り替えなし

  設定例（Linux）:
  $ sudo ip route add 10.0.0.0/8 via 192.168.1.254
  $ sudo ip route del 10.0.0.0/8

動的ルーティング:
  → ルーティングプロトコルが自動的にルートを学習・更新
  → 大規模ネットワークで使用
  → 障害時に自動で経路変更

  主なルーティングプロトコル:

IGP: Interior Gateway Protocol（組織内）
  EGP: Exterior Gateway Protocol（組織間）
  DV:  Distance Vector（距離ベクトル型）
  LS:  Link State（リンク状態型）
  PV:  Path Vector（パスベクトル型）

6.3 BGPの基礎

BGP（Border Gateway Protocol）:
  → インターネットのルーティングを支える最重要プロトコル
  → AS（Autonomous System）間の経路交換
  → ポート179/TCP

  AS（自律システム）:
    → 単一の管理下にあるネットワークの集合
    → AS番号（ASN）で識別: AS7500（東京大学）、AS15169（Google）
    → 2バイトASN: 1〜65534
    → 4バイトASN: 65536〜4294967294

  BGPの仕組み:
    ① eBGP（External BGP）: 異なるAS間の経路交換
    ② iBGP（Internal BGP）: 同じAS内の経路共有

  実務での重要性:
    → ISP のネットワーク運用
    → マルチホーミング（複数ISPとの接続）
    → CDN のエニーキャスト（同じIPを複数拠点で広告）
    → クラウドとオンプレミスの接続（AWS Direct Connect + BGP）

  BGP障害の実例:
    2017年: Google が日本のトラフィックをインドネシア経由にする誤経路広告
    2019年: Cloudflare がBGPリークにより一部地域で到達不能に
    2021年: Facebook が自社のBGP経路を撤回し、全サービス約6時間停止
    → BGPの誤設定はインターネット全体に影響を及ぼしうる

7. VPCネットワーク設計

7.1 AWS VPC設計のベストプラクティス

VPC CIDR設計の原則:

  ① 将来の拡張を考慮
     → /16 を推奨（65,536アドレス）
     → /24 では254台で足りなくなる可能性大

  ② 他のVPC/オンプレミスとの重複を避ける
     → VPCピアリングやVPN接続時に重複するとルーティング不可
     → 事前にIPアドレス計画を作成

  ③ 予約アドレスを考慮
     → AWSは各サブネットで5つのIPアドレスを予約
       .0: ネットワークアドレス
       .1: VPCルーター
       .2: AWSが予約（DNS）
       .3: AWSが予約（将来用）
       .255: ブロードキャスト

  推奨VPC設計例:

  VPC: 10.0.0.0/16 （65,536アドレス）
  │
  ├── AZ-a
  │   ├── Public:  10.0.1.0/24   （251使用可能）
  │   ├── Private: 10.0.11.0/24  （251使用可能）
  │   └── DB:      10.0.21.0/24  （251使用可能）
  │
  ├── AZ-c
  │   ├── Public:  10.0.2.0/24   （251使用可能）
  │   ├── Private: 10.0.12.0/24  （251使用可能）
  │   └── DB:      10.0.22.0/24  （251使用可能）
  │
  └── AZ-d（将来の拡張用）
      ├── Public:  10.0.3.0/24
      ├── Private: 10.0.13.0/24
      └── DB:      10.0.23.0/24

  サブネットの役割:
    Public:  ALB, NAT Gateway, Bastion Host
    Private: ECS/EKS, Lambda, アプリケーションサーバー
    DB:      RDS, ElastiCache, データベース関連

7.2 マルチアカウント・マルチVPC設計

AWS Organization + Transit Gateway:

IPアドレス計画（重複なし）:
    10.0.0.0/16 → 共有サービス
    10.1.0.0/16 → 本番
    10.2.0.0/16 → 開発
    10.3.0.0/16 → ステージング
    10.4.0.0/16 → DR（ディザスタリカバリ）
    172.16.0.0/12 → オンプレミス

  Transit Gateway vs VPC Peering:

7.3 Kubernetesのネットワーク設計

Kubernetesでは3つのIPアドレスレンジが必要:

  ① ノードネットワーク: ノード（EC2等）のIPアドレス
     → VPCサブネットのCIDRを使用
     → 例: 10.0.0.0/16

  ② PodネットワークCIDR: Pod のIPアドレス
     → ノードネットワークとは別のレンジ
     → 例: 10.244.0.0/16（Flannel のデフォルト）
     → 各ノードに /24 が割り当てられる → 最大254 Pod/ノード

  ③ Service CIDR: Kubernetes Service のClusterIP
     → 例: 10.96.0.0/12
     → 仮想IPアドレス（kube-proxy が管理）

  AWS EKS の場合:
    VPC CNI プラグインを使用
    → Pod にVPCのIPアドレスを直接割り当て
    → 別途Pod CIDRが不要
    → VPCのIPアドレスを消費するため、サブネットは大きめに

    ノード1台あたりのPod数:
      ENI（Elastic Network Interface）の数 × ENIあたりのIPアドレス数
      例: m5.large → 3 ENI × 10 IP = 29 Pod（+1はノード自身）

    IPアドレス枯渇対策:
      → /19 サブネット（8,190アドレス）を推奨
      → prefix delegation を有効化（ENIにプレフィックスを割り当て）
      → セカンダリCIDRの追加（100.64.0.0/16等）

8. IPアドレス関連のトラブルシューティング

8.1 よくある問題と対処法

問題1: IPアドレスが取得できない

  症状: 169.254.x.x のアドレスが割り当てられる（APIPA）

  原因と対処:
    ① DHCPサーバーが起動していない
       → systemctl status dhcpd で確認
    ② DHCPサーバーに到達できない
       → スイッチ/ケーブルの問題
       → DHCPリレーエージェントの設定確認
    ③ DHCPプールが枯渇
       → リース情報を確認: cat /var/lib/dhcpd/dhcpd.leases
       → リース期間を短くする or プールを拡大

問題2: IPアドレスの重複

  症状: 通信が断続的に切れる、ARPフラッピング

  原因と対処:
    ① 静的IP設定がDHCPの範囲と重複
       → DHCPの動的範囲と静的割り当てを分離
    ② 複数DHCPサーバーが異なる設定で動作
       → 不要なDHCPサーバーを停止
    ③ VMの複製でIPアドレスが重複
       → VM複製後にIPアドレスを変更

  検出方法:
    $ arping -D -I eth0 192.168.1.100  # 重複検出
    $ arp -a | sort                      # ARPテーブルで重複MAC確認

問題3: サブネット間で通信できない

  原因と対処:
    ① ルーティングが設定されていない
       → ip route show で確認
       → 必要なルートを追加
    ② ファイアウォールでブロック
       → iptables -L -n で確認
       → Security Group（AWS）を確認
    ③ IP転送が無効
       → cat /proc/sys/net/ipv4/ip_forward
       → echo 1 > /proc/sys/net/ipv4/ip_forward

問題4: NATが正しく動作しない

  症状: プライベートIPのホストからインターネットに出られない

  原因と対処:
    ① NAT Gateway/Instanceのルートテーブル設定漏れ
       → プライベートサブネットのルートテーブルに 0.0.0.0/0 → NAT を追加
    ② Security Group の設定漏れ
       → アウトバウンドルールを確認
    ③ NAT Gateway が正しいサブネットにない
       → NAT Gateway はパブリックサブネットに配置する必要がある

8.2 ネットワーク診断コマンド集

# IPアドレスの確認
$ ip addr show                    # 全インターフェースのIP確認
$ ip addr show eth0               # 特定インターフェース
 
# ルーティングテーブル
$ ip route show                   # ルーティングテーブル表示
$ ip route get 8.8.8.8            # 特定宛先への経路確認
 
# ARP テーブル
$ ip neigh show                   # 近隣テーブル（ARP）
$ arp -a                          # ARP テーブル表示
 
# 疎通確認
$ ping -c 3 192.168.1.1          # ICMP疎通確認
$ ping6 -c 3 ::1                 # IPv6 疎通確認
 
# 経路追跡
$ traceroute 8.8.8.8             # 経路追跡（UDP）
$ traceroute -T 8.8.8.8          # 経路追跡（TCP）
$ mtr 8.8.8.8                    # 継続的な経路追跡
 
# ポート確認
$ ss -tlnp                        # TCP LISTEN ポート
$ ss -tunp                        # 全アクティブ接続
$ lsof -i :80                     # 特定ポートを使用中のプロセス
 
# DNS確認
$ dig example.com                 # DNS問い合わせ
$ nslookup example.com            # DNS問い合わせ（レガシー）
$ host example.com                # DNS問い合わせ（簡易）
 
# パケットキャプチャ
$ sudo tcpdump -i eth0 -n         # パケットキャプチャ
$ sudo tcpdump -i eth0 port 80    # 特定ポートのキャプチャ
 
# ネットワーク統計
$ netstat -s                      # プロトコル統計
$ ss -s                           # ソケット統計
$ cat /proc/net/snmp              # SNMP統計

9. IPアドレスのセキュリティ

9.1 IPスプーフィングと対策

IPスプーフィング:
  → 送信元IPアドレスを偽装する攻撃
  → DDoS攻撃の増幅に使用

  対策:
    ① BCP38 / RFC 2827（Ingress Filtering）:
       → ISPがソースアドレス検証を実施
       → 自社のIPレンジ以外のソースアドレスをブロック

    ② uRPF（unicast Reverse Path Forwarding）:
       → ルーターで受信パケットのソースアドレスを検証
       → ルーティングテーブルの逆引きで正当性確認

    ③ ACL（Access Control List）:
       → プライベートIPアドレスの外部流出をブロック
       → ボガン（未割り当てIP）のフィルタリング

9.2 IPアドレスのプライバシー

IPアドレスとプライバシー:
  → IPアドレスからおおよその地理的位置が特定可能
  → GeoIP データベース（MaxMind等）
  → ISP情報の特定

  プライバシー保護:
    ① VPN: トラフィックを暗号化し、VPNサーバーのIPで通信
    ② Tor: 複数のリレーを経由して匿名化
    ③ プロキシ: 代理サーバー経由で通信
    ④ IPv6プライバシー拡張: ランダムなインターフェースID

  IPアドレスと法規制:
    → GDPR: IPアドレスは個人情報として扱われる
    → 日本の個人情報保護法: 「個人関連情報」に該当しうる
    → ログにIPアドレスを記録する際は適切な管理が必要

9.3 IPアドレスベースのアクセス制御

IPベースのアクセス制御パターン:

① ファイアウォールACL:
  → ステートフルインスペクション
  → ソース/宛先IPとポートの組み合わせで制御

  iptables 設定例（Linux）:
  # 特定IPからのSSHのみ許可
  iptables -A INPUT -p tcp --dport 22 -s 203.0.113.10 -j ACCEPT
  iptables -A INPUT -p tcp --dport 22 -j DROP

  # 特定サブネットからのHTTPSを許可
  iptables -A INPUT -p tcp --dport 443 -s 10.0.0.0/8 -j ACCEPT

  nftables 設定例（新しいLinux）:
  nft add rule inet filter input tcp dport 22 ip saddr 203.0.113.10 accept
  nft add rule inet filter input tcp dport 22 drop

② クラウドセキュリティグループ:
  AWS Security Group:
  → ステートフル（戻りトラフィックは自動許可）
  → インバウンド/アウトバウンドルール

  設定例:

③ GeoIPフィルタリング:
  → IPアドレスから地理的位置を判定
  → 特定国からのアクセスをブロック/許可

  Nginx + GeoIP2:
  geoip2 /etc/nginx/GeoLite2-Country.mmdb {
    auto_reload 1h;
    $geoip2_data_country_code country iso_code;
  }

  server {
    if ($geoip2_data_country_code !~ ^(JP|US|GB)$) {
      return 403;
    }
  }

  注意点:
  → VPN/プロキシ使用者には効果なし
  → 正規ユーザーのブロックリスク
  → CDNを介する場合はX-Forwarded-Forヘッダーを参照

9.4 IPv6セキュリティの考慮事項

IPv6特有のセキュリティ課題:

① アドレス空間の広さによるスキャン耐性:
  → /64サブネットには2^64個のアドレス
  → 総当たりスキャンは事実上不可能
  → ただし予測可能なアドレス（::1, ::dead:beef等）は狙われる

② NDP（Neighbor Discovery Protocol）の脆弱性:
  → IPv4のARPスプーフィングに相当する攻撃
  → RA（Router Advertisement）スプーフィング
  → 偽のルーターを広告してトラフィックを乗っ取り

  対策:
  → RA Guard: スイッチでRA送信を制限
  → SEND（SEcure Neighbor Discovery）: NDPメッセージに署名

③ デュアルスタック環境のリスク:
  → IPv4ファイアウォールは設定済みだがIPv6は未設定
  → IPv6経由でファイアウォールをバイパス
  → 必ず両プロトコルのセキュリティ設定を統一する

④ IPv6拡張ヘッダーの悪用:
  → 多数の拡張ヘッダーでファイアウォールを回避
  → フラグメンテーション攻撃
  → 対策: 不要な拡張ヘッダーをフィルタリング

⑤ トンネリングのリスク:
  → 6to4, Teredo等のトンネルが意図しない経路を作成
  → 対策: 不要なトンネリングプロトコルを無効化

10. FAQ（よくある質問）

FAQ 1: IPv4アドレス枯渇問題の現状と対策は？

Q: IPv4アドレスの枯渇は本当に深刻なのか？現在の対策は？

A: IPv4アドレスは2011年にIANAで枯渇し、2019年にはRIPE NCC（欧州）で
   完全に枯渇した。しかし、以下の対策により運用は継続している。

現状:
  ・2011年2月: IANAがRIRへの割り当てを停止
  ・2015年9月: ARIN（北米）が枯渇
  ・2019年11月: RIPE NCC（欧州）が枯渇
  ・現在: 新規割り当てはほぼ不可能

主な対策:

1. NAT/NAPT:
   → プライベートIPアドレス（10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16）
     を使用し、グローバルIPを節約
   → 家庭用ルーターやファイアウォールで広く使用
   → 「1つのグローバルIP」で数百台のデバイスがインターネット接続可能

2. CGNAT（キャリアグレードNAT）:
   → ISPレベルでのNAT
   → RFC 6598の共用アドレス空間（100.64.0.0/10）を使用
   → 複数の契約者が1つのグローバルIPを共有
   → 一部のP2P通信やポート開放に問題が生じる

3. IPv6への移行:
   → 128ビットアドレス = 事実上無限（3.4×10^38個）
   → デュアルスタック運用（IPv4とIPv6を同時運用）
   → Google統計（2024年）: 約45%のトラフィックがIPv6

4. IPv4アドレスの取引市場:
   → 使われていないIPv4アドレスブロックを売買
   → 価格は1アドレスあたり30-50ドル程度
   → AWS、Microsoft等の大手が大量に購入

実務的な判断:
  ・新規システムは必ずIPv6対応を前提に設計
  ・当面はデュアルスタック運用が必須
  ・パブリッククラウド（AWS、GCP、Azure）はIPv6を積極的にサポート

FAQ 2: サブネットマスクの計算方法を教えてほしい

Q: サブネット計算を手早く行う方法は？

A: CIDR表記とビット演算の理解があれば、暗算でも可能。

基本公式:
  ホスト数 = 2^(32 - プレフィックス長) - 2
             ↑
             ネットワークアドレスとブロードキャストアドレスを引く

よく使うサブネット早見表:

  /24 → 256アドレス（254ホスト）← 最もよく使う
  /25 → 128アドレス（126ホスト）
  /26 → 64アドレス（62ホスト）
  /27 → 32アドレス（30ホスト）
  /28 → 16アドレス（14ホスト）
  /29 → 8アドレス（6ホスト）
  /30 → 4アドレス（2ホスト）← ルーター間接続で使用
  /31 → 2アドレス（RFC 3021: P2Pリンク専用）
  /32 → 1アドレス（ホストアドレス）

計算例: 192.168.1.64/26 のネットワーク情報を求める

  1. /26 = 11111111.11111111.11111111.11000000
         = 255.255.255.192

  2. ホスト部のビット数 = 32 - 26 = 6ビット
     → 2^6 = 64アドレス

  3. ネットワークアドレス:
     192.168.1.64
     （64は64の倍数なので、そのまま）

  4. ブロードキャストアドレス:
     192.168.1.64 + 63 = 192.168.1.127

  5. 利用可能なホスト範囲:
     192.168.1.65 〜 192.168.1.126
     （最初と最後を除く62個）

暗算のコツ:
  ・/24より大きい場合（/25〜/32）は第4オクテットに着目
  ・/16より大きく/24より小さい場合（/17〜/23）は第3オクテットに着目
  ・「256からサブネットマスクの値を引く」= ブロックサイズ
    例: /26 → 256 - 192 = 64 → 64個ずつのブロック

FAQ 3: プライベートIPとNATの仕組みを詳しく教えてほしい

Q: プライベートIPアドレスとNATはどのように動作するのか？

A: プライベートIPアドレスは組織内部でのみ使用され、
   インターネット上にはルーティングされない。
   NAT（Network Address Translation）がこれらをグローバルIPに変換する。

プライベートIPアドレスの範囲（RFC 1918）:

  10.0.0.0/8        → 10.0.0.0 〜 10.255.255.255
                       約1677万個（クラスA相当）
                       大規模組織、VPCで使用

  172.16.0.0/12     → 172.16.0.0 〜 172.31.255.255
                       約104万個（クラスB相当×16）
                       中規模組織で使用

  192.168.0.0/16    → 192.168.0.0 〜 192.168.255.255
                       約65,000個（クラスC相当×256）
                       家庭用ルーター、小規模組織で使用

NAT/NAPTの動作（家庭用ルーターの例）:

  内部ネットワーク:
    PC-A: 192.168.1.100
    PC-B: 192.168.1.101
    PC-C: 192.168.1.102
    ルーター内部IF: 192.168.1.1
    ルーター外部IF: 203.0.113.50（グローバルIP）

  PC-Aがgoogle.com（142.250.196.110:80）にアクセス:

    [内部] PC-A送信:
      送信元: 192.168.1.100:54321
      宛先: 142.250.196.110:80

    [ルーター] NAT変換:
      NATテーブルに記録:
        内部 192.168.1.100:54321 ←→ 外部 203.0.113.50:12345

      パケット書き換え:
        送信元: 203.0.113.50:12345 （変換後）
        宛先: 142.250.196.110:80

    [外部] Googleへ送信

    [Google] 応答:
      送信元: 142.250.196.110:80
      宛先: 203.0.113.50:12345

    [ルーター] NAT逆変換:
      NATテーブルを参照:
        203.0.113.50:12345 → 192.168.1.100:54321

      パケット書き換え:
        送信元: 142.250.196.110:80
        宛先: 192.168.1.100:54321 （変換後）

    [内部] PC-Aが受信

重要なポイント:
  ・外部からはルーターのグローバルIP（203.0.113.50）しか見えない
  ・ポート番号で内部の複数デバイスを識別（NAPT = PAT）
  ・内部から外部への通信で動的にマッピングを作成
  ・外部から内部への新規接続は不可（ポートフォワード設定が必要）

NATの利点:
  ① IPv4アドレス節約: 1つのグローバルIPで多数のデバイスが利用可能
  ② セキュリティ: 内部ネットワークの隠蔽
  ③ IPアドレス管理の簡素化: ISP変更時も内部は変更不要

NATの欠点:
  ① エンドツーエンド原則の破壊: 中間でアドレス書き換えが発生
  ② P2P通信の困難さ: 両端がNAT内部だと直接通信不可
  ③ プロトコルによっては動作しない: FTP（Active Mode）、SIP等
  ④ パフォーマンス: 変換処理のオーバーヘッド
  ⑤ トレーサビリティ: CGNATでは複数ユーザーが同一IPを共有

FAQ

Q1: このトピックを学ぶ上で最も重要なポイントは何ですか？

実践的な経験を積むことが最も重要です。理論だけでなく、実際にコードを書いて動作を確認することで理解が深まります。

Q2: 初心者がよく陥る間違いは何ですか？

基礎を飛ばして応用に進むことです。このガイドで説明している基本概念をしっかり理解してから、次のステップに進むことをお勧めします。

Q3: 実務ではどのように活用されていますか？

このトピックの知識は、日常的な開発業務で頻繁に活用されます。特にコードレビューやアーキテクチャ設計の際に重要になります。

まとめ

次に読むべきガイド

参考文献

1. RFC 791. "Internet Protocol." IETF, 1981.
2. RFC 8200. "Internet Protocol, Version 6." IETF, 2017.
3. RFC 1918. "Address Allocation for Private Internets." IETF, 1996.
4. RFC 4632. "Classless Inter-domain Routing (CIDR)." IETF, 2006.
5. RFC 2131. "Dynamic Host Configuration Protocol." IETF, 1997.
6. RFC 4862. "IPv6 Stateless Address Autoconfiguration." IETF, 2007.
7. RFC 8305. "Happy Eyeballs Version 2." IETF, 2017.
8. RFC 6598. "IANA-Reserved IPv4 Prefix for Shared Address Space." IETF, 2012.
9. RFC 5737. "IPv4 Address Blocks Reserved for Documentation." IETF, 2010.
10. Doyle, J. & Carroll, J. "Routing TCP/IP, Volume 1." 2nd Ed, Cisco Press, 2005.