Cisco Systems JapanAdvent Calendar 2024

IPv6-Mostly Network を作ってみた

Last updated at 2024-12-15Posted at 2024-12-15

はじめに

この記事はシスコの有志による Cisco Systems Japan Advent Calendar 2024 の 16 日目 (シリーズ 1) として投稿しています。
シリーズ 2 では @hiokazak さんの記事が同日に公開されています。（お誕生日おめでとうございます！)

📅 これまでのカレンダーの一覧（クリックして開きます）

2017 年版: https://qiita.com/advent-calendar/2017/cisco
2018 年版: https://qiita.com/advent-calendar/2018/cisco
2019 年版: https://qiita.com/advent-calendar/2019/cisco
2020 年版 (1): https://qiita.com/advent-calendar/2020/cisco
2020 年版 (2): https://qiita.com/advent-calendar/2020/cisco2
2021 年版 (1): https://qiita.com/advent-calendar/2021/cisco
2021 年版 (2): https://qiita.com/advent-calendar/2021/cisco2
2022 年版 (1,2): https://qiita.com/advent-calendar/2022/cisco
2023 年版: https://qiita.com/advent-calendar/2023/cisco
2024 年版: https://qiita.com/advent-calendar/2024/cisco

この記事は何なのか

大規模なカンファレンスが行われる会場において IPv6-Mostly Network と呼ばれるネットワーク構成を最近耳にするようになりましたが、ご存知ですか？¹
ようは 「ほぼ」IPv6 ネットワーク ということらしい²
あまり日本語の構築事例は見つからなかった
- 本邦の「ほぼ」といえば、🦀ほぼ、これ🦀
なので自宅のシスコルータを使って構築してみた

IPv6-Mostly Network について知りたい方はこちらをクリックして下にスクロールしてください。

コンフィグ

おそらくネットワークエンジニアなら第一にコンフィグが知りたいはず

検証環境は ISR4321/K9, IOS XE 17.12.04 です。
後述しますが、少なくとも 17.11.x 以降でなければ動きません。

ip dhcp pool ipv4-dhcp-pool
 network 192.0.2.0 255.255.255.0
 default-router 192.0.2.1
 ! Cisco Umbrella - Recursive IPv4 DNS servers
 dns-server 208.67.222.222 208.67.220.220
 ! IPv6-Only Preferred Option, RFC 8925
 ! Wait time: 30 minutes = 1800 (decimal) = 0x708 (hex)
 option 108 ascii 00000708
!
ipv6 unicast-routing
!
interface GigabitEthernet0/0/0
 description *** WAN ***
 ip address dhcp
 nat64 enable
 ipv6 nd ra suppress
 ipv6 address autoconfig default
 ipv6 enable
!
interface GigabitEthernet0/0/1
 description *** LAN ***
 ip address 192.0.2.1 255.255.255.0
 nat64 enable
 ipv6 address 2001:0DB8::1/64
 ipv6 enable
 ! Discovering PREF64 in RA, RFC 8781
 ipv6 nd ra nat64-prefix 64:FF9B::/96
 ! RDNSS, RFC 8106
 ! Cisco Umbrella - Recursive IPv6 DNS servers
 ipv6 nd ra dns server 2620:119:35::35
 ipv6 nd ra dns server 2620:119:53::53
!
ipv6 access-list acl-allow-nat64
 sequence 10 permit ipv6 2001:0DB8::/64 any
!
! Stateful NAT64, RFC 6146
nat64 v4 pool nat64-pool 198.51.100.1 198.51.100.1
nat64 v6v4 list acl-allow-nat64 pool nat64-pool overload

ハマりやすいところ

Stateful NAT64 のために WAN インターフェイスに割り当てられていない IPv4 アドレス を最低ひとつ用意しなければなりません（上記の例では 198.51.100.1）
- NAT44 と違って NAT64 では interface overload は利用できず、address pool を使います
  - いわゆる ip nat inside source ... interface ... のようにして外側の IPv4 アドレスの指定を省略することができません
- （NAT64 に限った話ではありませんが）address pool に指定する IP アドレスは、ルータ上で使われている IP アドレス（例えば WAN インターフェイス）と重複することができません³
- 以上のことから、WAN 側で 2 つの IPv4 アドレスを用意して、これらがルータに到着するようにルーティングを工夫する必要があるでしょう
同じインターフェイスで NAT44 と NAT64 を動かしてはいけません ⁴
- ~~実際にやってみたら動いたけれど...~~

気づいたこと

既存の構築事例では PREF64 を RA に埋め込む RFC 8781 の実装で苦労していた様子ですが⁵、IOS XE では 17.11.1 以降でサポートされているようです ⁶

IPv6-Mostly Network とは

IPv4/IPv6 のデュアルスタックは（特に日本国内では非常に）普及していますが、これは文字通り IPv4 と IPv6 を同時に使っています。引き続き IPv4 が使われる限り、IPv6 で解決したい課題である IPv4 リソースの枯渇 には対応できません。

多くのアプリケーションが IPv4 に依存しているため IPv4 の廃止は非現実的でしたが、端末で CLAT (Customer-side translator) (RFC 6877⁷) の実装が進んだことで状況が変わりました。

CLAT は端末上で IPv4 アドレスと IPv6 アドレスをステートレスに変換します。つまり、IPv4 アドレス宛の IPv4 通信であっても、IPv6 アドレス宛に変換されて IPv6 パケットとして端末から送信されます（逆も然り）。

例えば NTT ドコモは端末への IPv4 アドレス割当を廃止し、IPv4 アドレス枯渇問題へ対応しているそうです⁸。つまり、Android や iPhone を使っているユーザは知らず知らずのうちに WAN 側（網側）のインターフェイスに IPv6 アドレスだけが割り当てられています。しかし、スマートフォンで実行されている CLAT のおかげで、IPv4 しか対応しないアプリケーションも問題なく通信することができています。

つまり、現状の端末は

IPv4-Only Endpoint: IPv4 シングルスタック
Dual-Stack Endpoint (Not IPv6-Only Capable): IPv4/IPv6 デュアルスタック
IPv6-only capable Endpoint: IPv6 シングルスタック（ただし CLAT で IPv4 通信可能）

に分類することができます。

以上を踏まえて IPv6-Mostly Networks が実現するのは、これら 3 つを全て同じ L2 ネットワークに接続させながら、「Dual-Stack Endpoint」の端末が自動的に「IPv6-only capable Endpoint」に切り替わるように促すことです。

具体的には、DHCP で IPv4 アドレスを取得しようとする端末に対して、もし端末自身が IPv6-only に対応すると判断するなら、積極的に IPv4 アドレスを捨てさせようとします。もし端末がそのように判断しないのならば、IPv4 シングルスタック、もしくはデュアルスタックであることを許容します。

以上を実現するために、IPv6-Mostly Networks ではこれらの既存技術を組み合わせています。

IPv4 ネットワーク宛の通信ができるように NAT64 を提供する (RFC 6146⁹)
端末がネットワーク内の NAT64 prefix (PREF64) に気付くように RA を使う (RFC 8781¹⁰)
CLAT を持ち IPv6 シングルスタックに対応するクライアントは IPv4 アドレスを破棄するように IPv4 DHCP Option 108 を使う (RFC 8925¹¹)

最後に

やってみて気づいたのですが、IPv6-only capable Endpoint と IPv4-Only Endpoint 間の通信はどうしたらいいんでしょうか？
- 上のコンフィグ例では IPv4 インターネット行きの NAT64 が構成されていますが、LAN 行きの NAT64 は行っていません
  - ping 8.8.8.8 はできるけれど、LAN 上のプリンタの IPv4 リテラルアドレス宛に通信できません
- LAN 内の IPv4 通信 (IPv4-only internal destinations) も NAT64 すれば解決するんですが、LAN 内で NAT することの違和感が...（個人の感想です）
ちらちら耳にする IPv6-Mostly Network を自分の手で作ってみましたが、ハマりそうなところも少なく、比較的簡単に始めることができそうです
- この記事は IPv6-Mostly Network に接続した macOS 15.1.1 (24B91) を使って Qiita サイト上で執筆しました

免責事項

本サイトおよび対応するコメントにおいて表明される意見は、投稿者本人の個人的意見であり、私の所属する組織の意見ではありません。本サイトの内容は、情報の提供のみを目的として掲載されており、私の所属する組織や他の関係者による推奨や表明を目的としたものではありません。各利用者は、本Webサイトへの掲載により、投稿、リンクその他の方法でアップロードした全ての情報の内容に対して全責任を負い、本Webサイトの利用に関するあらゆる責任から私の所属する組織を免責することに同意したものとします。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up