CIDR表記とIPレンジの理解

CIDR表記は address/prefix の形で書かれ、prefix はネットワーク部として固定される先頭ビットの数を表します。つまり 10.0.0.0/16 では先頭16ビットがネットワークを識別し、残りの16ビットはホストのために自由に使えます。

多くの人がこれを身につけるのは、セキュリティグループが黙ってトラフィックをブロックし、その原因がプレフィックスの1桁違いだったと判明する3回目あたりの、苦い経験を通してです。この1行が、Terraformファイルに 10.0.0.0/16 をコピペするのをやめて、その意味を読み取れるようになるために必要なことのほとんどです。本記事では、そのメンタルモデル、プレフィックスから利用可能なレンジとホスト数を求める2ステップの計算、そしてWeb開発者やフルスタック開発者が実際にCIDRに出会う場面(VPCのサイジング、セキュリティグループのルール、許可リスト、コンテナネットワーク)を、接続性を静かに壊す落とし穴とあわせて解説します。

CIDR表記とは何か

CIDR(Classless Inter-Domain Routing)表記は、IPアドレスの後にスラッシュとプレフィックス長を続けてネットワークを表現するもので、プレフィックス長はネットワーク部として固定される先頭ビットの個数を表します。これは硬直的なクラスA/B/Cの仕組みを置き換えたものであり、ブロックサイズが8ビット・16ビット・24ビットの境界に縛られることなく任意のサイズを取れるようになりました。この方式は1993年に RFC 1519 で導入され、2006年に現在の標準文書である RFC 4632 に統合されました。プレフィックスはアドレス全体のビット数ではありませんが、これはよくある誤読です。192.168.129.23/17 において /17 は先頭17ビットがネットワークビットであることを意味し、ホストには15ビットが残されます。

ビットモデル: ネットワークビットとホストビット

IPv4アドレスは4つの8ビットオクテットに分割された32ビットの数値であり、/n というプレフィックスはその32ビットに1本の線を引きます。線の左側はすべて固定されたネットワーク部、右側はすべて可変のホスト部です。線を右に動かせば(プレフィックスを大きくすれば)より多くの小さなネットワークが得られ、左に動かせばより少なく大きなネットワークになります。

10.0.1.0/24 を例にとります。/24 は3番目のオクテットの直後で区切るので、先頭24ビットは固定され、最後の8ビットが自由に使えます:

00001010 . 00000000 . 00000001 . 00000000
└──────── network (24 bits) ──────┘ └ host ┘
   10          0          1        0–255

この8つのホストビットは 00000000 から 11111111 までの範囲、つまり256通りの組み合わせで、10.0.1.0 から 10.0.1.255 に対応します。区切りがどこに来るかを決めるのはプレフィックスだけです。

CIDRブロックには何台のホストが入るのか

IPv4ブロック内の利用可能なホスト数は 2^(32 − prefix) − 2 です。/24 なら254、/26 なら62、/30 なら2となります。差し引かれる2つのアドレスは、ネットワークアドレス(ホストビットがすべて 0)とブロードキャストアドレス(ホストビットがすべて 1)であり、いずれもホストに割り当てることはできません。まず総アドレス数(2^(32 − prefix))を計算し、それから2を引きます。

−2 のルールには実務上重要な例外が2つあります。/31 は利用可能アドレスが2つになります。これは RFC 3021 がポイントツーポイントリンクにおけるネットワークアドレスとブロードキャストアドレスの予約を廃止したためです。そして /32 は単一ホストルートであり、ファイアウォールや許可リストのルールで特定のIPを1つだけ指定する際に使う形式です。

実際の現場でCIDRブロックを読む

10.0.1.0/24 のようなブロックを読み解くと、ネットワークアドレスは 10.0.1.0、ブロードキャストは 10.0.1.255、利用可能なレンジは 10.0.1.1 から 10.0.1.254 です。手順は4ステップです: (1) プレフィックスから何ビットが固定かを読む、(2) 残りのホストビットをすべて 0 にしてネットワークアドレスを得る、(3) すべて 1 にしてブロードキャストを得る、(4) その間のすべてが利用可能である。

逆方向、つまりホスト数の要件からプレフィックスを決める場合は、必要数を満たす最小のブロックを選びます。30台のデバイス分の余裕が必要ですか?/27 なら利用可能数は30、/28 では14しかないので、答えは /27 です。任意のブロックはPython標準ライブラリの ipaddress モジュールで確認できます。インストールは不要です:

python3 -c "import ipaddress; n=ipaddress.ip_network('10.0.1.0/24'); print(n.network_address, n.broadcast_address, n.num_addresses)"
# 10.0.1.0 10.0.1.255 256

設定に反映させる前に、任意のブロックに対して実行して手計算を検証しましょう。

ターミナルを開きたくない場合は、OpenReplay CIDR calculator がブラウザ上で同じ展開を行ってくれます。10.0.0.0/16 のようなブロックを貼り付けると、ネットワークアドレスとブロードキャストアドレス、ネットマスクとワイルドカード、最初と最後の利用可能ホスト、そして総アドレス数を返します。IPv4とIPv6の両方に対応し、多倍長整数演算を用いているため、大きなブロックやIPv6のレンジでも正確な結果が得られます。すべてローカルで計算されるので、内部レンジがマシンの外に出ることはありません。

開発者が実際にCIDRに出会う場面

ほとんどの開発者は、ルーティングテーブルよりずっと前に、クラウドやアプリの設定でCIDRに出会います。RFC 1918 は頻繁に目にする3つのプライベートレンジ(10.0.0.0/8、172.16.0.0/12、192.168.0.0/16)を予約しています。いずれもパブリックインターネット上ではルーティングされないため、クラウドのVPCやDockerネットワークはこれらから割り当てを行います。実務で触れるものはほぼ次の4パターンに収まります:

• VPCとサブネットのサイジング。 作成時にブロックを設定し、そこからサブネットを切り出します。AWS VPCのIPv4ブロックは /16 から /28 の範囲でなければならず、各サブネットは先頭4アドレスと末尾1アドレスを予約します(2つではなく5つ)。したがってAWSでは /24 のサブネットの利用可能アドレスは254ではなく251になります。一般的な −2 は上限であって保証ではありません。
• ファイアウォールとセキュリティグループのルール。 ルールはCIDR単位でスコープされます。例えばインバウンドの5432を 10.10.1.0/24 からのみ許可するとすれば、データベース層はWeb層からのPostgresトラフィックだけを受け付け、それ以外は受け付けません。
• アプリ設定における許可リストと拒否リスト。 CORSのオリジン、WAFのルール、APIゲートウェイのソースレンジ、nginx の allow/deny ディレクティブは、いずれもCIDRブロックを受け取ります。プレフィックスが狭すぎると正当なクライアントを黙ってブロックしてしまいます。こうした実装のセッションリプレイでは、たった1つの誤ったプレフィックスに起因するブロックや失敗リクエストとして、この障害がしばしば表面化します。
• CIDR重複という落とし穴。 ピアリングやVPNで接続しようとする2つのネットワークは、重複するCIDRブロックを使ってはいけません。ホストは同じアドレスに対して2つの一意なルートを持てないからです。それぞれに重複しないRFC 1918レンジを、例えば 10.10.0.0/16 と 10.20.0.0/16 のように割り当てましょう。

覚えておく価値のある値が1つあります。IPv4の 0.0.0.0/0(およびIPv6の ::/0)はすべてのアドレスを意味します。デフォルトルートとしては有用ですが、インバウンドの許可ルールとしては自らの足を撃つ道具になります。ポート22や5432に対する 0.0.0.0/0 は、インターネット全体に対して扉を開け放つことになります。

IPv6も同じ表記を使う

IPv6は128ビットアドレスに対してまったく同じスラッシュ表記を適用し、サブネットあたりの標準サイズは /64 で、各サブネット内のホストには64ビットが残されます。ただし /64 は慣習であって規則ではないと捉えてください。普遍的な不変条件ではなく、AWSでもIPv6サブネットのネットマスクを /44 から /64 まで /4 刻みで指定できます。ビット分割のロジックはまったく同じで、アドレスが長くなるだけです。

プレフィックスをネットワークビットの個数として読み、IPv4の利用可能ホスト数には 2^(32 − prefix) − 2 を適用し、/31、/32、クラウドの予約という例外を覚え、ピアリングするネットワークは重複させないこと。これができれば、電卓に手を伸ばすことなくサブネットをサイジングしたり、ファイアウォールルールを監査したりできます。次にプルリクエストでCIDRブロックを見かけたら、その場で読み解いて、その /0 が意図されたものかを確認してみてください。

FAQ

255.255.255.0 のようなサブネットマスクと /24 のようなCIDRプレフィックスの違いは何ですか?

どちらも同じ境界を2通りの方法で表現したものです。サブネットマスクは、ネットワークビットが1、ホストビットが0となる32ビットの値であり、255.255.255.0 を2進数にすると1が24個続いた後に0が8個並びます。CIDRプレフィックス /24 は、その先頭の1のビット数を数えているだけです。255.255.255.0 は /24、255.255.255.192 は /26、255.255.255.252 は /30 に等しくなります。CIDRは同じマスクの短縮表記です。

/30 では利用可能なIPアドレスがいくつになりますか。またなぜポイントツーポイントリンクで一般的なのですか?

/30 は総数4のうち利用可能なアドレスが2つです。標準の「マイナス2」ルールにより、ネットワークアドレスとブロードキャストアドレスが依然として予約されるためです。利用可能アドレス2つは、ポイントツーポイントリンクの両端にちょうど足りる数であり、これが /30 が伝統的に選ばれてきた理由です。後にRFC 3021により /31 が同じ目的に使えるようになり、総数2のうち2つが利用可能となりました。ネットワークとブロードキャストの予約を廃止することで、アドレスを一切無駄にしません。

同一ネットワーク内で2つのサブネットのCIDRブロックが重複してもよいですか?

互いにルーティングする必要がある場合は不可です。単一のルーティングテーブル内では、重複は最長プレフィックス一致で解決されます。10.0.1.5 宛のパケットは、より広い 10.0.0.0/16 のルートではなく 10.0.1.0/24 のルートに従うため、経路が曖昧になることはありません。問題が生じるのは、独立してアドレス設計された2つのネットワークを接続する場合です。両方が 10.0.0.0/16 を使っている2つのVPC間のピアリング接続は失敗します。どちら側もそのブロックをすでにローカルにルーティングしており、相手側に到達する手段がないからです。これがVPCピアリングやサイト間VPNで重複しないレンジが必要とされる理由です。最初から各ネットワークに固有のRFC 1918ブロックを割り当てましょう。

プレフィックスの数字が小さいほどネットワークは大きくなるのですか、小さくなるのですか?

プレフィックスの数字が小さいほどネットワークは大きくなります。プレフィックスは固定されたネットワークビットを数えるので、ネットワークビットが少ないほどホストビットが多く残ります。/8 はホストビットが24個で1600万を超えるアドレスを持ち、/24 はホストビットが8個で256アドレスです。プレフィックスの数字が1つ下がるごとにブロックサイズは倍になります。/23 は /24 の2倍のアドレスを持ち、/16 は /24 の256倍を持ちます。

なぜAWSでは /24 のサブネットの利用可能アドレスが254ではなく251なのですか?

AWSは一般的な「マイナス2」ルールが想定する2つではなく、サブネットあたり5つのアドレスを予約します。AWSは各サブネットCIDRブロックの先頭4アドレスと末尾1アドレスを、ネットワークアドレス、VPCルーター、DNS、将来の利用、ブロードキャストのために確保します。そのため総数256の /24 はAWSでは利用可能251となり、一般的なネットワーク計算での254とは異なります。サブネットをぎりぎりにサイジングする前に、必ず利用中のクラウドプロバイダーの予約ルールを確認してください。