IPv6/IPv4 デュアルスタックのインターネット接続を OSS で作る – NAT66 以前の試行錯誤

この記事は、以前に自宅の IPv6/IPv4 デュアルスタック接続を OSS で構成しようとしたときの試行錯誤を、現在の理解で再整理したものです。

当時の主題は、IPv4 は VyOS で PPPoE/NAPT すればよい一方、IPv6 は NAT66 を前提にしづらく、ISP から届く RA / DHCPv6 / GUA をどう LAN 側へ渡すか、という問題でした。

今なら、NAT66、NPTv6、ULA + GUA 併用、DHCPv6-PD、firewall router などの選択肢をより整理して考えられます。しかし、当時は「IPv6 は NAT しない」という理想と、自宅内の複数ネットワークを守りたい現実の間で、かなり手探りでした。

当時の問題意識

自宅のインターネット回線では、IPv4 は PPPoE を終端し、内部の private IPv4 address を NAPT することで外部へ接続していました。これは一般的なブロードバンドルーターと同じ考え方です。

IPv4 NAT / NAPT は、アドレス節約だけでなく、内部アドレス空間と外部空間を分離し、外部から直接 PC に到達しにくくする境界としても機能していました。

一方、IPv6 では ISP から GUA が届き、端末が RA / SLAAC で自動構成されると、そのまま Internet へ到達できます。これは IPv6 の理想としては自然ですが、当時の私の環境では次の不安がありました。

• LAN 内の PC が Internet 側から直接見える構造になりやすい
• IPv4 のような NAT 境界をそのまま使えない
• 市販ルーターではなく VyOS と OSS で構成したかった
• ISP から届く RA / DHCPv6 を LAN 側へどう扱うかを理解したかった
• IPv4 と IPv6 の境界設計がまったく別物になることに違和感があった

当時の構成

当時は、物理 NIC が複数ある KVM ホスト上に、VyOS と Linux bridge firewall を組み合わせる構成を検討しました。

役割	内容
VyOS #1	IPv4 の PPPoE 終端と IPv4 NAPT を担当する
CentOS IPv6 bridge firewall	Internet 側と LAN 側を bridge し、RA / DHCPv6 を通しつつ、不要な inbound IPv6 を遮断する
VyOS #2	LAN 側の MAC address が VyOS #1 側へ見えすぎないようにするための分離役
KVM ホスト	複数 NIC と複数 VM を載せる基盤

図で表すより、今の観点では「IPv4 は L3/NAPT router」「IPv6 は bridge firewall」「MAC 学習の副作用を避けるための追加分離」という役割で見る方が分かりやすいです。

VyOS #1 の役割

VyOS #1 は、通常の IPv4 インターネット接続を担当していました。PPPoE を終端し、LAN 側 IPv4 address を NAPT して外部へ出す構成です。

IPv4 では、この構成が分かりやすく成立します。内部は RFC1918 の private address で自由に設計し、外部へ出るときだけ NAT / NAPT するため、内部設計が ISP 側の IPv4 address に強く依存しません。

この点は、後に IPv6 における NAT66 再考 で整理した「内部設計主権」の話につながります。

CentOS IPv6 bridge firewall の役割

IPv6 側では、当時 NAT66 を自然な選択肢として扱いづらかったため、IPv6 を bridge で LAN 側へ通しつつ、Internet 側から開始される不要な通信を firewall で遮断する構成を考えていました。

この bridge firewall では、Internet 側から届く RA や DHCPv6 を LAN 側へ通し、端末が IPv6 address や DNS 情報を取得できるようにします。一方で、Internet 側から LAN 側へ開始される一般通信は遮断します。

通す通信	理由
ICMPv6 RA / RS / NDP	IPv6 の自動設定と neighbor discovery に必要
DHCPv6	DNS などの追加情報や環境によって必要な設定を取得するため
LAN 側から開始した戻り通信	通常の outbound 通信を成立させるため

遮断したい通信	理由
Internet 側から開始される不要な inbound IPv6	LAN 内端末への直接到達を避けるため
想定外の L2/L3 制御通信	bridge 構成で責任分界が曖昧になるのを避けるため

今なら nftables で整理するのが自然ですが、当時は ip6tables と physdev module を使って bridge 上の通過通信を制御する発想でした。これは「IPv6 を routing する」のではなく、「ISP の IPv6 link を LAN 側へ延ばしつつ、firewall で守る」という考え方です。

VyOS #2 が必要だった理由

当時の構成で興味深いのは、VyOS #2 を追加していた点です。目的は、VyOS #1 が LAN 内 PC の MAC address を複数方向から学習してしまうことを避けるためでした。

bridge を使って IPv6 を透過させると、L2 の見え方が複雑になります。構成によっては、同じ LAN 内端末の MAC address が複数の NIC や bridge 経由で見え、MAC 学習や転送が不安定になる可能性があります。

VyOS #2 は、その副作用を避けるための分離点として置いていました。今見ると、これは「IPv6 を NAT せずに bridge で通す」設計が、L3 設計ではなく L2 設計の問題を引き込んでいた例だと考えられます。

この構成の良かった点

• 市販ルーターに依存せず、OSS と仮想化基盤で構成できた
• IPv4 は VyOS で分かりやすく NAPT できた
• IPv6 は RA / DHCPv6 を LAN 側へ通し、実際に dual stack で通信できた
• IPv6 の firewall、RA、DHCPv6、bridge の関係を実体験として理解できた
• IPv6 における NAT 不在の違和感を、設計問題として意識するきっかけになった

この構成の苦しかった点

• IPv6 を bridge で延ばすため、L2 の責任分界が曖昧になる
• RA / DHCPv6 / NDP を正しく通しつつ、不要な inbound を遮断する必要がある
• IPv4 は L3/NAT、IPv6 は bridge firewall となり、設計の対称性が崩れる
• MAC 学習や bridge の副作用を考える必要がある
• 構成管理や障害解析の対象が L2/L3 の両方に広がる

この苦しさは、単なる設定の難しさではありません。IPv6 を NAT なしで LAN へ素直に延ばそうとすると、内部ネットワークをどこで分離するのか、どこを境界と見なすのか、という設計問題が出てくるということです。

現在の観点で見るとどうか

現在の観点で見ると、この構成は「NAT66 / NPTv6 / ULA + GUA 併用をうまく使えなかった時代の bridge firewall 的な現実解」だったと思います。

今なら、次のような選択肢を比較して考えます。

方式	設計の性格
GUA-only routing	十分な prefix を持ち、各 L3 セグメントへ /64 を割れるなら最も素直
ULA + GUA 併用	内部正本を ULA にしつつ、外部到達は GUA で行う
NPTv6	内部 prefix と外部 prefix を 1:1 に近い形で変換する
NAT66	内部 ULA を外部 GUA へ境界変換する
Proxy	HTTP / HTTPS などをアプリケーション層で中継する
bridge firewall	上位の IPv6 link を LAN 側へ延ばし、通過通信を firewall で制御する

十分な delegated prefix があるなら、GUA-only routing や ULA + GUA 併用の方がきれいです。prefix 設計主権が弱い環境では、NPTv6、NAT66、Proxy のような境界機構も現実的な候補になります。

bridge firewall は動く構成ではありますが、L2 の複雑さを抱え込みやすいため、現在なら最後の手段に近い位置づけで考えます。

RA / DHCPv6 の理解ともつながる

この構成では、RA と DHCPv6 の扱いが重要でした。IPv6 では、RA が default router や on-link prefix を通知し、SLAAC によるアドレス生成の土台になります。DHCPv6 は DNS などの追加情報や、環境によってはアドレス管理、Prefix Delegation を担当します。

つまり、IPv6 の Internet 接続を bridge で LAN 側へ通す場合、単に TCP/UDP を通すだけでは足りません。RA、NDP、DHCPv6 を理解して通す必要があります。

この点は、IPv6 Router Advertisement と DHCPv6 の役割整理 に詳しく整理しました。

この試行錯誤から得た教訓

• IPv6 は NAT がないから簡単、という話ではない
• IPv6 では RA / NDP / DHCPv6 / firewall / prefix delegation が設計上の重要部品になる
• IPv4 NAT が提供していた境界抽象は、IPv6 でも別の形で必要になる
• bridge firewall は動くが、L2 の複雑さを引き込みやすい
• 内部ネットワークを守るには、アドレス数ではなく prefix 設計主権を考える必要がある

まとめ

当時の IPv6/IPv4 デュアルスタック構成は、IPv4 を VyOS の PPPoE/NAPT で処理し、IPv6 を bridge firewall で LAN 側へ通すという構成でした。

これは、NAT66 や NPTv6 を自然に扱えなかった時代に、OSS で IPv6 Internet 接続を成立させるための試行錯誤でした。

現在の理解では、この構成は最適解というより、IPv6 の理想と自宅ネットワークの現実がぶつかったときの過渡的な設計だったと考えています。

ただし、この試行錯誤には価値があります。IPv6 の本質的な難しさは、アドレスが足りるかどうかではなく、内部ネットワークの設計主権、境界制御、RA / DHCPv6 / NDP の扱いをどう整理するかにある、ということを体感できたからです。