IPアドレスとサブネット・CIDR・NAT 入門 - /24 の計算からプライベートアドレス、NAT越え、VPC の CIDR 設計まで

「VPC の CIDR は 10.0.0.0/16 にしてください」「Docker のネットワークが社内 LAN と被って通信できない」「/26 だと何台まで置けるんでしたっけ」。インフラの相談や設定作業では、こうした話が日常的に出てきます。ところが /24 の意味や、なぜ 192.168.x.x がインターネットに出ていかないのかを、あらためて説明しようとすると詰まる方は少なくありません。

この記事では、IPv4 アドレスの構造、サブネットマスクと CIDR、サブネット分割の計算、特殊用途アドレス、NAT/NAPT と NAT 越え、IPv6 の基本、Docker・VPC・Kubernetes での CIDR 設計までを、一次ソースである RFC と IANA・各ベンダーの公式ドキュメントを軸に整理します。JavaScript の短い関数と macOS での実行結果も載せます。トランスポート層の話は TCP と UDP の基本 で扱っているので、本記事はその1つ下、インターネット層の話です。

IPv4 アドレスは32ビットの整数

IPv4 は RFC 791（Internet Protocol、1981年9月、Internet Standard）で定義されています。RFC 791 はアドレスを「固定長の4オクテット（32ビット）」と定め、「ネットワーク番号で始まり、その後にローカルアドレス（rest フィールド）が続く」と説明しています。

私たちが普段見る 192.0.2.130 のような表記は、この32ビットを8ビットずつ4つに区切り、それぞれを10進数にしてドットでつないだもの（ドット付き10進表記）です。

192      . 0        . 2        . 130
11000000 . 00000000 . 00000010 . 10000010

32ビットなので、表現できる値は2の32乗、およそ43億個です。この上限が、後述する IPv4 枯渇・NAT・IPv6 の話すべての出発点です。

アドレスは大きく2つの部分に分かれます。

• ネットワーク部: どのネットワーク（サブネット）に属するかを表す上位ビット
• ホスト部: そのネットワーク内のどの機器かを表す下位ビット

ルータは宛先アドレスのネットワーク部だけを見て転送先を決めます。この分業があるからこそ、インターネット全体の経路表は「43億個のアドレス」ではなく「ネットワークの数」で済んでいます。

クラスフルから CIDR へ

「どこまでがネットワーク部か」の決め方は、歴史的に2段階あります。

クラスフルアドレス（RFC 791）

RFC 791 は、先頭ビットのパターンでネットワーク部の長さを固定するクラスを定義しました。

この方式は単純ですが、粒度が粗すぎました。RFC 4632 は、1992年1月に IETF が認識した問題として、(1) クラス B 空間の枯渇、(2) 経路表の肥大化、(3) IPv4 アドレス空間そのものの枯渇、の3点を挙げています。中規模組織にとってクラス C（254ホスト）は小さすぎ、クラス B（65,534ホスト）は大きすぎたのです。

CIDR（RFC 1519 から RFC 4632 へ）

そこで導入されたのが CIDR（Classless Inter-Domain Routing）です。RFC 1519（1993年9月、Proposed Standard）で標準化され、現在は RFC 4632（2006年8月、Best Current Practice）に置き換えられています。

CIDR の考え方は「クラスを捨てて、ネットワーク部の長さを明示的に書く」というものです。それが 192.0.2.0/24 の /24 で、プレフィックス長と呼びます。RFC 4632 の例では、旧クラス B の 172.16.0.0 は 172.16.0.0/16、旧クラス C の 192.168.99.0 は 192.168.99.0/24 と書けます。長さを自由に選べるので /22（1,024アドレス）のような中間サイズも作れますし、複数の /24 を1つの /22 にまとめて経路広告する経路集約も可能になりました。

サブネットマスクとプレフィックス長

プレフィックス長を32ビットのビット列で表したものがサブネットマスクです。ネットワーク部を 1、ホスト部を 0 で埋めます。/24 なら上位24ビットが 1 なので、255.255.255.0 です。

「利用可能ホスト数」が「アドレス総数から2を引いた値」になるのは、各サブネットで次の2つが予約されるためです。

• ネットワークアドレス: ホスト部がすべて 0 のアドレス。サブネットそのものを指す
• ブロードキャストアドレス: ホスト部がすべて 1 のアドレス。サブネット内の全ホスト宛て

macOS の ifconfig はサブネットマスクを16進数で表示します。執筆環境の Mac では次のように出ました。

ifconfig en0 | grep 'inet '

inet 192.168.0.10 netmask 0xffffff00 broadcast 192.168.0.255

0xffffff00 は2進数で「1が24個、0が8個」なので /24、つまり 255.255.255.0 です。ブロードキャストが 192.168.0.255 になっているのも、ホスト部8ビットをすべて 1 にした結果です。

サブネット分割の計算: AND 演算で求める

ネットワークアドレスは、IP アドレスとサブネットマスクのビット単位 ANDで求まります。198.51.100.77/26 を例に手計算してみます（198.51.100.0/24 は RFC 5737 で文書用に予約された TEST-NET-2 です）。

IP     198.51.100.77   = 11000110.00110011.01100100.01001101
マスク 255.255.255.192 = 11111111.11111111.11111111.11000000
AND    -------------------------------------------------------
                          11000110.00110011.01100100.01000000
                        = 198.51.100.64   <- ネットワークアドレス

第4オクテットだけ見れば十分です。77 は2進数で 01001101、マスクの 192 は 11000000。上位2ビットだけ残すと 01000000 = 64 になります。ここから、次が導けます。

• ネットワークアドレス: 198.51.100.64
• ブロードキャストアドレス: ホスト部6ビットをすべて 1 にして 198.51.100.127（64 + 63）
• 利用可能ホスト: 198.51.100.65 から 198.51.100.126 までの62台

/26 は /24 を4分割したものなので、198.51.100.0/24 の中には .0/26、.64/26、.128/26、.192/26 の4つのサブネットができます。「第4オクテットを64ごとに区切る」と覚えると暗算しやすくなります。なお実務では、ネットワーク・ブロードキャストの2個に加えてルータ用に1個は確実に消費され、クラウドではさらに予約が増えます（後述の AWS では1サブネットあたり5個）。

JavaScript で CIDR を計算する

同じ計算を JavaScript で書くと次のようになります。JavaScript のビット演算は結果が符号付き32ビットになるため、>>> 0 で符号なしに戻しているのがポイントです。

function ipToInt(ip) {
  return ip.split('.').reduce((acc, octet) => (acc << 8) + Number(octet), 0) >>> 0;
}
 
function intToIp(n) {
  return [n >>> 24, (n >>> 16) & 255, (n >>> 8) & 255, n & 255].join('.');
}
 
function cidrInfo(cidr) {
  const [ip, prefixStr] = cidr.split('/');
  const prefix = Number(prefixStr);
  const mask = prefix === 0 ? 0 : (0xffffffff << (32 - prefix)) >>> 0;
  const network = (ipToInt(ip) & mask) >>> 0;
  const broadcast = (network | (~mask >>> 0)) >>> 0;
  const hostBits = 32 - prefix;
  const usableHosts = hostBits <= 1 ? 0 : Math.pow(2, hostBits) - 2;
  return {
    network: intToIp(network),
    netmask: intToIp(mask),
    broadcast: intToIp(broadcast),
    firstHost: usableHosts ? intToIp(network + 1) : '-',
    lastHost: usableHosts ? intToIp(broadcast - 1) : '-',
    usableHosts,
  };
}
 
for (const c of ['192.0.2.130/24', '198.51.100.77/26', '203.0.113.9/30']) {
  console.log(c, cidrInfo(c));
}

Node.js（v18.20.8）で実行した結果です。手計算した 198.51.100.77/26 の値と一致しています。

192.0.2.130/24 {
  network: '192.0.2.0',
  netmask: '255.255.255.0',
  broadcast: '192.0.2.255',
  firstHost: '192.0.2.1',
  lastHost: '192.0.2.254',
  usableHosts: 254
}
198.51.100.77/26 {
  network: '198.51.100.64',
  netmask: '255.255.255.192',
  broadcast: '198.51.100.127',
  firstHost: '198.51.100.65',
  lastHost: '198.51.100.126',
  usableHosts: 62
}
203.0.113.9/30 {
  network: '203.0.113.8',
  netmask: '255.255.255.252',
  broadcast: '203.0.113.11',
  firstHost: '203.0.113.9',
  lastHost: '203.0.113.10',
  usableHosts: 2
}

特殊用途アドレス: プライベート・リンクローカル・CGNAT・ループバック

IPv4 には、インターネット上でルーティングされない、あるいは特定用途に予約された範囲があります。IANA は RFC 6890（Special-Purpose IP Address Registries、2013年4月、BCP）に基づき IPv4 Special-Purpose Address Registry を管理しており、主なものは次のとおりです。いずれもレジストリ上の Globally Reachable 欄は False です。

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

RFC 1918（Address Allocation for Private Internets、1996年2月、BCP）は、組織内で自由に使ってよい3つのブロック 10.0.0.0/8、172.16.0.0/12、192.168.0.0/16 を定め、それぞれを「24ビットブロック」「20ビットブロック」「16ビットブロック」と呼んでいます。インターネット上で一意ではないため、外に出るには後述の NAT が必要です。「なぜ自宅も会社も 192.168.x.x なのか」の答えがここにあります。

リンクローカル（RFC 3927）

RFC 3927（Dynamic Configuration of IPv4 Link-Local Addresses、2005年5月、Proposed Standard）は、DHCP サーバーが見つからないときなどにホストが 169.254/16 から自動でアドレスを選ぶ仕組みを定めています。ルータを越えないため、PC が 169.254.x.x になっていたら「DHCP でアドレスをもらえていない」というサインです。

共有アドレス空間（RFC 6598、CGNAT 用）

RFC 6598（IANA-Reserved IPv4 Prefix for Shared Address Space、2012年4月、BCP）は、Carrier-Grade NAT（CGN）を運用する ISP のために 100.64.0.0/10 を予約しました。RFC 6598 は「CGN 機器と加入者宅内機器（CPE）をつなぐインターフェースに番号を振るために使う」と述べ、RFC 1918 の空間とは別物だと明記しています。加入者宅の 192.168.x.x と衝突しない「二段目のプライベート空間」です。

ループバック

127.0.0.0/8 は自分自身宛ての通信に使うループバックアドレスで、レジストリでは RFC 1122 が参照元です。macOS でも ifconfig lo0 で 127.0.0.1（マスク 0xff000000、つまり /8）と IPv6 の ::1 が付いていることを確認できます。

NAT と NAPT: プライベートアドレスをインターネットに出す

NAT（Network Address Translation）は、パケットを中継しながら IP アドレスを書き換える仕組みです。用語は RFC 2663（1999年8月、Informational）、代表的な動作は RFC 3022（Traditional IP Network Address Translator、2001年1月、Informational）にまとまっており、RFC 3022 は伝統的な NAT を2種類に分けています。

• Basic NAT: IP アドレスだけを1対1で変換する。内側のホスト数ぶんのグローバルアドレスが要る
• NAPT（Network Address Port Translation）: IP アドレスに加えてTCP/UDP のポート番号（ICMP ではクエリ ID）も変換する。1つのグローバルアドレスを多数のホストで共有できる

家庭のルータやクラウドの NAT ゲートウェイがやっているのは後者の NAPT です。仕組みを図で追ってみます。ルータの外側アドレスは文書用の 203.0.113.5 とします。

ポイントは、ルータが保持するNAT テーブルです。

内側の2台が偶然同じ送信元ポート 51000 を使っても、ルータが外側ポートを 40001 と 40002 に振り分けるので区別できます。戻りのパケットは外側ポートでテーブルを引き、元の内側アドレスとポートに戻されます。

この設計には次の性質がついて回ります。

• 内側から始めた通信しか通らない: エントリは内側からの送信で作られ、外側から先に届いたパケットは捨てられる
• エントリには寿命がある: 一定時間通信がないと消える。アイドルな TCP 接続が切れる原因の1つ
• グローバル IP が節約できる: IPv4 枯渇下でインターネットが今も動いている大きな理由

「自宅サーバーに外から届かない」「P2P 通信ができない」は1つ目の性質が原因で、これがNAT 越え（NAT traversal）という問題領域を生みました。

NAT 越え: NAT の種別と STUN・TURN・ICE

NAT の振る舞いを分類する

古典的な分類は RFC 3489（STUN の初版、2003年3月）が定めた4種類です。RFC 3489 自体は RFC 5389 に置き換えられましたが、用語は今も広く使われています。

この4分類は「マッピング」と「フィルタリング」を混ぜて扱っていたため、RFC 4787（2007年2月、BCP）はこれを分離して再定義し、REQ-1 で「NAT は Endpoint-Independent Mapping でなければならない（MUST）」と要求しています。満たさない NAT（Symmetric 相当）では UDP リレーが必要になる、と同 RFC は述べています。

STUN: 自分の外側アドレスを知る

STUN（Session Traversal Utilities for NAT）は、NAT の外にあるサーバーに「私はどう見えていますか」と聞くプロトコルです。RFC 5389（2008年10月）を経て、現在は RFC 8489（2020年2月、Proposed Standard）が最新です。STUN サーバーに見えたアドレスを「reflexive transport address」と呼び、応答の XOR-MAPPED-ADDRESS 属性で返します。ただし Symmetric NAT では宛先ごとにポートが変わるため、STUN で調べたポートは相手との通信では使われません。

TURN: 中継サーバーを使う

直接つながらない場合の最終手段が TURN（Traversal Using Relays around NAT）です。RFC 5766（2010年4月）を経て、RFC 8656（2020年2月、Proposed Standard）が現行版です。クライアントは TURN サーバーに Allocate リクエストを送ってリレー用アドレスを確保し、以後の通信はサーバー経由で中継されます。確実につながる代わりに帯域とコストがかかります。

ICE: 候補を集めて試す

これらを組み合わせ、つながる経路を自動で探すのが ICE（Interactive Connectivity Establishment）、RFC 8445（2018年7月、Proposed Standard）です。各端末が次の3種類の候補（candidate）を集め、組み合わせごとに接続性チェックを行います。

• host candidate: 端末のインターフェースに付いたアドレス
• server-reflexive candidate: STUN で分かった NAT の外側アドレス
• relayed candidate: TURN サーバー上のリレーアドレス

WebRTC のビデオ通話がブラウザ同士で直接つながるのは、この ICE の仕組みによります。UDP を土台に NAT 越えを前提とする点は HTTP/3 と QUIC にも通じます。

IPv6 の基本: 128ビットと ::表記、/64

IPv4 枯渇への根本的な答えが IPv6 です。プロトコル本体は RFC 8200（2017年7月、Internet Standard）、アドレス体系は RFC 4291（2006年2月、Draft Standard）で定義されています。

表記

RFC 4291 は IPv6 アドレスを「128ビットの識別子」と定め、基本形を16ビットずつ8つの16進数をコロンで区切る x:x:x:x:x:x:x:x としています。各フィールドの先頭の0は省略でき、連続する0のグループは :: で1回だけ省略できます。RFC 4291 の例は次のとおりです。

2001:DB8:0:0:8:800:200C:417A  ->  2001:DB8::8:800:200C:417A   (ユニキャスト)
FF01:0:0:0:0:0:0:101          ->  FF01::101                    (マルチキャスト)
0:0:0:0:0:0:0:1               ->  ::1                          (ループバック)
0:0:0:0:0:0:0:0               ->  ::                           (未指定アドレス)

:: を2か所に書くと何個省略したか分からなくなるため「1回だけ」です。プレフィックス表記は IPv4 の CIDR と同じで、2001:db8::/32 のように書きます。

/64 と各種アドレス

RFC 4291 は「先頭3ビットが 000 のものを除くすべてのユニキャストアドレスで、インターフェース ID は64ビット長でなければならない」と定めています。これが IPv6 のサブネットが原則 /64 である理由です。

ULAは RFC 4193（Unique Local IPv6 Unicast Addresses、2005年10月、Proposed Standard）で定義された、RFC 1918 に相当する組織内用アドレスです。IPv4 と違い40ビットの Global ID を疑似乱数で生成するため、組織同士をつないでも衝突しにくい設計です。Docker も IPv6 を有効にしてサブネットを指定しなかった場合、この ULA から /64 を自動割り当てすると公式ドキュメントに記載しています。執筆環境の Mac でも ifconfig en0 に fe80::...%en0 prefixlen 64 のリンクローカルアドレスが付いていました。

IPv4 枯渇と IPv6 の位置づけ

JPNIC の公開情報によれば、IANA の中央在庫は 2011年2月3日に、APNIC の通常割り振り在庫は 2011年4月15日に枯渇しました。JPNIC は独自の在庫を持たず APNIC と共有しているため、通常の割り振りは同時に終了しています。以後の IPv4 は、最後の /8 からの限定的な分配や既存アドレスの移転で回っています。

IPv6 は128ビットなのでアドレス数の心配は事実上なくなりますが、IPv4 との直接の互換性はなく、両者は並行して運用されています。ISP が IPv4 側で CGNAT（前述の 100.64.0.0/10）でアドレスを共有しつつ、IPv6 をネイティブで提供する構成が一般的です。

Docker・クラウド VPC・Kubernetes での CIDR 設計

ここからは実務です。プライベートアドレスを自由に使えるからこそ、重複させない設計が重要になります。

Docker のデフォルトネットワーク

執筆環境の Docker（29.8.0）で既定の bridge ネットワークを見ると 172.17.0.0/16 でした。

docker network inspect bridge --format '{{range .IPAM.Config}}{{.Subnet}} {{.Gateway}}{{end}}'

172.17.0.0/16 172.17.0.1

Docker の公式ドキュメントは、ユーザー定義ネットワーク用のプールの組み込み既定値を、daemon.json の default-address-pools で次に相当すると説明しています。

{
  "default-address-pools": [
    { "base": "172.17.0.0/16", "size": 16 },
    { "base": "172.18.0.0/16", "size": 16 },
    { "base": "172.19.0.0/16", "size": 16 },
    { "base": "172.20.0.0/14", "size": 16 },
    { "base": "172.24.0.0/14", "size": 16 },
    { "base": "172.28.0.0/14", "size": 16 },
    { "base": "192.168.0.0/16", "size": 20 }
  ]
}

base が切り出し元、size が各ネットワークのプレフィックス長です。つまり docker network create するたびに /16 が1つ消費されます。同じドキュメントは「Docker はホストで使用中のプレフィックスを避けようとするが、環境によっては経路の衝突を防ぐために default-address-pools のカスタマイズが必要になることがある」とも述べています。社内 LAN や VPN が 172.16.0.0/12 を使っていると、まさにこの衝突が起きます。例のように 172.17.0.0/16 を size: 24 で切れば、256個のネットワークを1つの /16 に収められます。コンテナが独立したネットワークを持てる仕組みは Linux コンテナの namespace と cgroups で扱っています。

AWS VPC の CIDR 制約

AWS の公式ドキュメントによれば、VPC の IPv4 CIDR は /16（65,536アドレス）から /28（16アドレス）の範囲で指定し、サブネットも同じ範囲です。作成後にサイズは変えられず、拡張時はセカンダリ CIDR を追加します（既存 CIDR やピアリング先と重複不可）。さらに各サブネットで先頭4個と末尾1個の計5個が予約されます。10.0.0.0/24 なら .0（ネットワーク）、.1（VPC ルータ）、.2（DNS サーバー）、.3（将来用）、.255（ブロードキャスト）です。したがって /28 のサブネットは16アドレスのうち11個しか使えません。また AWS は、Cloud9 や SageMaker AI などの一部サービスが 172.17.0.0/16 を使うため、VPC にこの範囲を使わないよう注意喚起しています。Docker の既定と同じ範囲です。

/16 と /24 の切り方

一般的な設計は、VPC（または環境）ごとに /16 を1つ与え、その中をサブネットごとに /24 などで切る、というものです。たとえば 10.1.0.0/16 を本番、10.2.0.0/16 を検証とし、第3オクテットで AZ や public/private の用途を表します。大事なのは、後から VPN やピアリングでつなぐ可能性のあるネットワーク同士で CIDR が重ならないよう最初に台帳を作っておくことです。10.0.0.0/16 は教材でも最初に出てくるため、無計画に使うと他社・他部門とつなぐときにほぼ確実に衝突します。

Kubernetes の Pod CIDR

Kubernetes は Pod ごとに IP を割り当てるため、ノードとは別に Pod 用と Service 用の CIDR が必要です。公式ドキュメント（Cluster Networking）は「Kubernetes クラスタは、Pod・Service・ノードに対して重複しない IP アドレスを割り当てる必要がある」と明記しています。kubeadm では --pod-network-cidr で Pod の範囲を指定し、--service-cidr の既定値は 10.96.0.0/12 です。Pod CIDR はノードごとの小さなサブネットに分割されるため、ノードあたり /24 なら /16 で256ノードが上限になります。VPC・Pod・Service・社内 LAN・VPN の範囲を1つの台帳で管理しておくと安全です。

Linux/macOS で確認するコマンド

最後に、アドレスと経路を確認するコマンドをまとめます。

macOS（この記事で実行したもの）

アドレスは前述の ifconfig en0 で確認できます。経路表は netstat です。

netstat -rn -f inet

Destination        Gateway            Flags               Netif Expire
default            192.168.0.1        UGScg                 en0
127                127.0.0.1          UCS                   lo0
127.0.0.1          127.0.0.1          UH                    lo0
169.254            link#16            UCS                   en0      !
192.168.0          link#16            UCS                   en0      !
192.168.0.1/32     link#16            UCS                   en0      !

default 行がデフォルトゲートウェイ（192.168.0.1）で、この Mac から見た NAPT ルータです。127（ループバック）、169.254（リンクローカル）、192.168.0（自分のサブネット）が経路として載っています。

route -n get default でも同じゲートウェイと mtu 1500 が確認できました。なお ipcalc や sipcalc はこの Mac には入っていませんでした（which ipcalc で見つからず）。必要なら別途導入するか、前述の JavaScript で代用できます。

Linux（構文のみ。本記事では未実行）

Linux では iproute2 の ip コマンドが標準です。macOS には ip がないため、構文だけ示します。

ip addr show          # 各インターフェースのアドレス（CIDR 表記で表示される）
ip route show         # 経路表。default via ... が既定ゲートウェイ
ip -6 addr show       # IPv6 アドレス

サーバーに SSH で入って上記を打つ場面は多いはずです。SSH 接続の仕組みは SSH プロトコルの入門 にまとめています。

まとめ

• IPv4 アドレスは32ビット（RFC 791）。ネットワーク部とホスト部に分かれ、境界はクラスフルから CIDR（RFC 1519、現行 RFC 4632）のプレフィックス長へ移った
• ネットワークアドレスはIP AND マスク、ブロードキャストはホスト部を全部 1。利用可能ホスト数は「2のホスト部ビット数乗 − 2」
• RFC 1918、RFC 3927（169.254/16）、RFC 6598（100.64.0.0/10）、ループバック、文書用（RFC 5737）は IANA レジストリで管理される特殊用途アドレス
• NAPT（RFC 3022）は NAT テーブルでアドレスとポートを変換する。内側から始めた通信しか通らないためSTUN（RFC 8489）・TURN（RFC 8656）・ICE（RFC 8445）による NAT 越えが要る
• IPv6（RFC 8200 / 4291）は128ビット、:: は1回だけ、サブネットは原則 /64。組織内用は ULA（RFC 4193）
• Docker・AWS VPC・Kubernetes はどれも「CIDR を重複させない台帳」があるかで運用の楽さが決まる

IP アドレスの計算は一度ビットで理解すれば、あとは /24 = 256、/26 = 64 という数字の感覚で実務の大半は回ります。名前からアドレスを引く仕組みは DNS の仕組み入門、その先の TCP の流量制御は TCP 輻輳制御の入門 で扱っています。

参考リンク

• RFC 791: Internet Protocol（IETF / RFC Editor）
• RFC 950: Internet Standard Subnetting Procedure（IETF / RFC Editor）
• RFC 1519: Classless Inter-Domain Routing (CIDR)（IETF / RFC Editor）
• RFC 4632: Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan（IETF / RFC Editor）
• RFC 1918: Address Allocation for Private Internets（IETF / RFC Editor）
• RFC 3927: Dynamic Configuration of IPv4 Link-Local Addresses（IETF / RFC Editor）
• RFC 6598: IANA-Reserved IPv4 Prefix for Shared Address Space（IETF / RFC Editor）
• RFC 5737: IPv4 Address Blocks Reserved for Documentation（IETF / RFC Editor）
• RFC 6890: Special-Purpose IP Address Registries（IETF / RFC Editor）
• IANA IPv4 Special-Purpose Address Registry（IANA）
• RFC 2663: IP Network Address Translator (NAT) Terminology and Considerations（IETF / RFC Editor）
• RFC 3022: Traditional IP Network Address Translator (Traditional NAT)（IETF / RFC Editor）
• RFC 4787: NAT Behavioral Requirements for Unicast UDP（IETF / RFC Editor）
• RFC 3489: STUN - Simple Traversal of UDP Through NATs（IETF / RFC Editor）
• RFC 8489: Session Traversal Utilities for NAT (STUN)（IETF / RFC Editor）
• RFC 8656: Traversal Using Relays around NAT (TURN)（IETF / RFC Editor）
• RFC 8445: Interactive Connectivity Establishment (ICE)（IETF / RFC Editor）
• RFC 8200: Internet Protocol, Version 6 (IPv6) Specification（IETF / RFC Editor）
• RFC 4291: IP Version 6 Addressing Architecture（IETF / RFC Editor）
• RFC 4193: Unique Local IPv6 Unicast Addresses（IETF / RFC Editor）
• IPv4アドレスの在庫枯渇に関して（JPNIC）
• Networking overview - Subnet allocation（Docker Docs）
• dockerd - Daemon configuration file（Docker Docs）
• VPC CIDR blocks（AWS）
• Subnet CIDR blocks（AWS）
• Cluster Networking（Kubernetes）
• kubeadm init（Kubernetes）
• TCP と UDP の基本（当ブログ）
• DNS の仕組み入門（当ブログ）
• Linux コンテナの namespace と cgroups（当ブログ）
• HTTP/3 と QUIC（当ブログ）
• TCP 輻輳制御の入門（当ブログ）
• SSH プロトコルの入門（当ブログ）