しまねソフト研究開発センター（略称 ITOC）にいます、東です。

ITOCは2022年2月に、くにびきメッセからテクノアークへ引っ越ししました。その際、ネットワーク設計は移転先のネットワーク保守事業者へお願いし整備して頂きました。
同社にはきちんとした仕事をしてもらいましたが、運用する中でいくつか改善したい点が発生し、ネットワーク環境の再整備を行いましたので、そのあらましを公開します。

規模は小さいですし、障害対応のための2重化などは、費用対効果の検討で規模的に割に合わず一切行いません。大規模ネットワークの構築には参考になりませんが、IPv6化の検討くらいには使えるんじゃないかと思います。

目標

改善したかったのは以下の2点です。

L2分離
IPv6 デュアルスタック化

また、方針として可能な限りルーター等が持っている機能を使い、独自の機器は追加しないようにしています。理由は、独自機器が故障した場合に、メンテナンスできる人が限られるからです。アプライアンスであれば、故障した場合には同等機種を買ってきてコンフィグを入れ直せば復旧できます。
ただし後述する DNS だけは、独自に FreeBSD+Unbound でサーバーを立てています。

物理層

このクラスでは定番のヤマハルーターを軸に、2つのL2スイッチ、4つの WLAN AP を配置しています。
普通のオフィスと違い、セグメント間の通信はほとんど行わないため、L3スイッチを配置せず、ゲートウェイルーターがそれを兼ねています。

L2分離

くにびきメッセにいた時から、ゲスト用とスタッフ用のネットワーク分離していましたが、その実現には、わざわざ回線を2本引いていました。
これではさすがに無駄なので、新事務所では VLAN を使い2つに分離をしました。
しかし、マイクロセグメンテーションの考えを取り入れるため、さらに以下の4セグメントに分離することにしました。

事務用
研究開発用
ゲスト用
DMZ

上3つを VLAN で分離し、DMZ はルーターの物理ポートを使っています。
当初の館内ネットワーク保守事業者による設計では、ルーターは VLAN を使わず、L2スイッチのみ VLAN を使って分離したポートにそれぞれパッチケーブルで接続というデザインでしたが、ポートがもったいないのでルーターの LAN3 を VLAN trunk ポートにして一括して L2スイッチと接続するように変更しています。

各セグメント間は、基本的には通信は行いません。ただし以下の2つの例外があります。

事務用セグメントにはプリンター（複合機）が置かれるため、研究開発用セグメントからアクセスできる必要がある。
DMZ にはローカルに DNS サーバーを設置するので、全てのセグメントからアクセスできる必要がある。

これは、L3レベルで実現することにし、ルーターへファイアーウォールの設定を追加することで実現しました。

WLAN AP

SSID を、VLAN に対応した3つ定義しています。また、2.4G帯と5G帯で別々の SSID を定義しています。一般的に 2.4Gと5Gは同じSSIDを使う事も多いですが、ITOCではユーザー側で容易に使い分けられるということを優先し、別のSSIDとしています。
また、AP4台で同じ SSID を使っています。WLAN 管理システムは使わず、ハンドオーバーは移動局側にたよる形になりますが、今のところ不具合無くハンドオーバーもできています。

DMZ

DMZ には、ローカルに DNS サーバーを設置します。
その他、今後サーバーとなる機器が発生すれば、必要に応じて配置する計画です。

DHCPv4

IPv4 アドレス割り当ては、ヤマハルーターの DHCP サーバ機能を使って自動化します。また DHCP snooping 機能がある機器は、それを有効化しておきます。

ITOC では PC やスマートフォンはもちろんのこと、IoT 機器やヘッドマウントディスプレイなどネットワークに接続される機器が多くあるため、割り当てアドレス不足が一度発生しました。とりわけ、ゲスト回線は不特定多数の接続が行われるため、アドレス不足が顕著です。
DHCP プロトコルでは、使用しなくなった IP をリリースする手順が定められていますが、スマートフォンなどは接続されたまま物理的に離れてしまうため、リリースタイミングそのものがありません。従って、割り当てアドレス数の追加やタイムアウト値の調整によって対処します。
ヤマハルーターのデフォルトタイムアウト値は、72時間（3日間）のリース時間ですが、4時間（最大8時間）に短縮して設定します。通常、クライアントはタイムアウト時間が来る前に再リースを要求するので、これでも問題ありません。

dhcp scope 8 192.168.8.101-192.168.8.199/24 expire 4:00 maxexpire 8:00

さらには、リースアドレス数を SNMP で監視できれば良いのですが、その MIB が無さそうなので、折を見て Ruby で取得コードを書いて zabbix に突っ込んで監視しようと考えています。

DNS

DNS サーバーだけは独自に運用し、内部外部とも名前解決させています。
これは、内部機器を DNS名でアクセスするためです。今回 IPv6デュアルスタック化を考えているので、長い IPv6 アドレスを手動で入力することは現実的ではありません。
かといってルーター内蔵機能の DNS では、機能不足でした。そのため、ローカルに DNS サーバーを配置します。
また、現在は改善しているはずですが、以前はプロバイダの DNS に AAAA フィルタが入っていて、せっかく IPv6 化してもその恩恵が得られなかったので当時から DNS は独自に運用していました。

DNS サーバーは、PC engines ALIX を使い、そこへ FreeBSD をインストールして使います。FreeBSD は、標準で Unbound が付属しています。本来 Unbound はキャッシュサーバーであり権威サーバーではありませんが、ローカルなドメインを引く程度であれば十分に機能するので、これを使っています。

IPv6 デュアルスタック化

当初、館内ネットワーク保守事業者へ IPv6 の設定も併せてお願いしたのですが、担当された方は IPv6 の設計をやったことが無いとの事で、私が別のヤマハルーターで IPv6 デュアルスタックをした設定ファイルを提供し、それを参考に実施していただきました。
しかしながら、以下のようになっており、改善したいと思いました。

VLAN の 1セグメント分しか IPv6 Ready ではない。
PPPoE で接続している。

プロバイダは、OCN を使っています。現在では OCN も IPoE で接続ができますので、PPPoE を止めてよりシンプルな IPoE 接続に変更します。

デュアルスタック化目標

以下の点を、IPv4, IPv6 デュアルスタックの目標としました。

IPv4 は、PPPoE を使って接続し、ヤマハルーターの Dynamic DNS サービスを使って、外からの IPv4 接続ができるようにする。
IPv6 は、IPoE を使って接続する。
全てのサブネット (VLAN) で、IPv6 が使えるようにする。
IPv4 アドレス配布とDNS通知は、DHCP を使う。
IPv6 アドレス配布とDNS通知は、RAとDHCPv6 を使う。
IPv6 ユニークローカルアドレス (ULA) を使い、LAN内も可能な限りIPv6を使う。

資料「クライアントOSのIPv6対応状況は？（日経 XTECH）」や、「クライアントOSのIPv6実装検証から見たネットワーク運用における課題の考察（論文）によると、IPv6アドレス配布、DNSサーバ通知に関しては、RA(RDNSS) にのみ対応する機器と、DHCPv6 にのみ対応する機器、両対応の機器と対応にばらつきがあるようです。よって、両方の方式に対応しておけば問題ないだろうと考えました。
しかし後述しますが、最終的には RA のみの対応としました。

IPv6 の IPoE 接続（失敗編）

ここでは IPv6 に限定して記します。
IPv6 の網への接続を PPPoE から IPoE に変更します。現在の回線契約は「フレッツ光ネクスト（ひかり電話契約なし）」です。それ自体はヤマハルーターのメーカーサイトにあるとおり、以下の通り非常に簡単です。

ngn type lan2 ntt
ipv6 prefix 1 ra-prefix@lan2::/64
ipv6 lan2 dhcp service client ir=on

しかしここで問題になるのは RAで配布されているネットワークプレフィックスが、/64 であることです。複数のサブネットに対応するためには、/56 等のプレフィックスが必要となります。

ここで OCN サポートへ連絡し、/64より大きなネットワークが欲しいと伝えました。すると、OCNでは /56 で配布していると回答がありましたので、/56 で配布されているものとしてルーターの設定を調整します。
ところが、どうやっても /56 であるとは思えない挙動をします。たとえば、/56 であるとして、インターネット側から ICMPv6 echo パケットを投げてみるも、そもそもヤマハルーターまで到達しません。ヤマハルーター対OCN 間も RA によって接続確立されるのですが、Wiresharkで確認してみると、そのプレフィックスが /64 であることも観測できます。

仕方ないので代案を考えます。
LAN 側の /64 をさらにサブネットに分けることは、仕様上たぶんできないだろうと思いつつも、ルーターには設定できたので実験してみました。その結果、やはりクライアントが対応しておらず、だめです。
もう一つのアイデアで、 IPv6 GUA での VLAN 間通信はあきらめて、/64 のままで全ての VLAN に対応できないかやってみました。こちらは、アドレスを振ることはできるものの、ルーター内のルーティングテーブルが生成できず通信不可でした。もしできたとしても L2 と L3 のネットワークトポロジが変わるのは複雑さが増すので望ましくありません。

IPv6 の IPoE 接続（成功編）

ここで基本に立ち返り、網の仕様を確認してみます。

NTT西日本技術資料
https://www.ntt-west.co.jp/ngn/business/index.html
より、IP通信網サービスのインタフェース－フレッツシリーズ－＜光クロス、光ネクスト、光ライト編＞　
https://flets-w.com/service/next/download/tool/gijyutsu_sankou_cross_next_light.pdf
を参考に、網の仕様を調査します。

すると、レイヤ3仕様 - IPoE 方式における IPv6 アドレス情報付与方法　に、

「通常は、/64のプレフィックスを与える。ひかり電話を契約すると、/48 または、/56 のプレフィックスを与える。」（意訳）

とあります。
プロバイダである OCN は、網側の仕様を踏襲するしかないはずで、ということはひかり電話を契約すれば目的が達せられそうです。

以上の情報をもとに、もう一度 OCN サポートへ連絡をとってみました。するとこちらが上記の情報を伝える前に開口一番、「以前お伝えした /56を割り振っているというのは間違いでした」と伝えられ、ひかり電話を契約すれば良いことも確認が取れたので、こんどはNTT西日本へひかり電話契約の追加をお願いしました。

同資料によれば、ひかり電話ありの契約ではアドレス配布方法は RA ではなく DHCPv6 になるそうで、ヤマハルーターのメーカーサイトでもたしかにそのように設定が書いてあります。

ngn type lan2 ntt
ipv6 lan2 address dhcp
ipv6 lan2 dhcp service client

また、ひかり電話契約と同時にホームゲートウェイ機器が送られてきましたが、電話が目的ではないので使いませんでした。これを挟むと、設定が変わる可能性もあります。

こうしてようやく、/56 のネットワークを手に入れました。これを /64 に分割し、各 VLAN へ割り当てることで、目標である「全てのサブネット (VLAN) で IPv6 が使えるようにする」を達成できました。

ipv6 lan3/1 address dhcp-prefix@lan2::1:0:0:0:1/64
ipv6 lan3/2 address dhcp-prefix@lan2::2:0:0:0:1/64
ipv6 lan3/3 address dhcp-prefix@lan2::3:0:0:0:1/64

IPv6 アドレス配布・DNS通知は、RAとDHCPv6 を使う（失敗）

LAN 内に IPv6 アドレスを配布するためには、RA による SLACC を使います。ここまでは良いのですが、DNSアドレスを配布するには、RA+RNDSS と DHCPv6 による2種類の方法があり、先の資料によるとクライアントによって対応が分かれています。またそれぞれの方法も、以下の通り微妙に目的を達せられないような感じでした。

RA+RDNSS の場合

ルーターアドレスとDNSアドレスの2つのみの通知で、その他ドメイン名の通知などはできない。
Windows8.1 以前は未対応。

DHCPv6 の場合

ヤマハルーターに内蔵の DHCPv6 サーバ機能を使おうとした場合、DNSサーバアドレスの変更やドメイン名の変更ができない。（網から伝えられたものをパススルーするだけ？）

DNSサーバーを独自に立てたように、もっと自由度の高い DHCPv6 サーバーも独自に運用すれば問題は解決しますが、どうせ DHCPv4 も併用することが分かっているし、ここはもうあきらめて RA だけにすることにしました。

IPv6 ユニークローカルアドレス (ULA) を使い、LAN内も可能な限りIPv6を使う

LAN内の機器も IPv6 で運用することを考えると、LAN内は ULA を使うことが選択肢としてあげられるでしょう。ULA を使うと何が嬉しいのか、それはもちろん、今後また移転やプロバイダの変更もしくは都合などで、GUA のネットワークプレフィックスが変更になった場合でも、LAN 内の環境は一切影響をうけないという点です。
ITOC では、以下のように設計しました。

サーバーやプリンタなどの共用機器は、GUA と ULA の両方をもつ。
クライアント機は、GUA のみもつ。
クライアント機は、同一セグメント (VLAN) の機器とは、ULA を使って直接通信する。
クライアント機は、別セグメント (VLAN) の機器とは、ULA を使ってルーター経由で通信する。

ULA として、fdfb:2ad3:1200::/48 が生成されました。これはランダムに生成されます。
ポイントとなるのは、IPv6 なら GUA しかもたないクライアント機器が、ULA を持った機器と通信するときに、全く違ったアドレス/ネットワークプレフィックスにもかかわらず、同じセグメント上であれば直接通信することが可能であるということです。

これを実現するために、RA パケットで GUA, ULA 双方のアドレスプレフィックスを広告させます。

ipv6 nd ra-rdnss 1 fdfb:2ad3:1200:0:192:168:1:1

# VLAN1
ipv6 lan3/1 address dhcp-prefix@lan2::1:0:0:0:1/64
ipv6 lan3/1 address fdfb:2ad3:1200:1::1/64

ipv6 prefix 11 dhcp-prefix@lan2::1:0:0:0:1/64
ipv6 prefix 12 fdfb:2ad3:1200:1:/64 a_flag=off
ipv6 lan3/1 rtadv send 11 12 rdnss=1

# VLAN2
ipv6 lan3/2 address dhcp-prefix@lan2::2:0:0:0:1/64
ipv6 lan3/2 address fdfb:2ad3:1200:2::1/64

ipv6 prefix 21 dhcp-prefix@lan2::2:0:0:0:1/64
ipv6 prefix 22 fdfb:2ad3:1200:2:/64 a_flag=off
ipv6 lan3/2 rtadv send 21 22 rdnss=1
...

ULA プレフィックスを RA に含めて広告しますが、a_flag を OFF にすることで、「このプレフィックスから自アドレスは生成しないが On-Link である」ことがわかるようにクライアントに指示しています。

以下は、MacOSを接続した例です。
意図したとおり、GUA は自動的にアドレスが生成され、ULA は生成されていません。

以下のパケットキャプチャ例は、MacOSから同一セグメント上にある ULA アドレスを持った機器へ ping6 を実行したものです。

ping6 fdfb:2ad3:1200:1:192:168:1:1

ネットワークプレフィックスにあたる部分が全く異なっているにもかかわらず、ルーターにパケットが送られることなく直接ターゲットへ ICMP EchoRequest パケットが投げられています。

共有機器の IPv6 アドレス設定

プリンタなどの共有機器は、SLACC による GUA 自動付与とともに、ULA の手動付与を併用して IPv6 で運用できるようにします。ただし、これができる機器とできない機器があることが容易に想像できるので万能ではありません。できない機器は IPv4 のみで運用することにします。
ITOCにある機器類で、意図通りの設定、動作ができるか確認しました。

複合機　FUJIFILM Apeos C4570

設定可能
設定画面に入り、IPv6 デュアルスタックを有効にした上で、自動アドレス設定および手動アドレス付与の両方を設定します。

プリンター　RICOH SP C740

不可
IPv6 の設定画面はあるものの、手動アドレスの設定ができませんでした。

FreeBSDサーバ

設定可能
/etc/rc.confへ以下の通り設定します。

# /etc/rc.conf

ifconfig_em0_ipv6="inet6 accept_rtadv"
ifconfig_em0_alias0="inet6 fdfb:2ad3:1200:2:192:168:1:20/64"

これだけだと、RA の受信によりリゾルバ情報が書き換えられてしまうので、/etc/resolvconf.conf へ書き換えを防ぐ設定をします。

# /etc/resolvconf.conf

resolvconf="NO"

DNSサーバ Unbound

IPv6 ULA にクエリを投げると、GUA を fromアドレスとしてリプライを返す現象が見られ、クライアントからは DNSの詐称と見分けが付かず正常に名前解決ができない状況になりました。
unbound.conf へ、使う IPv6 アドレスを限定する設定を入れて回避します。

server:
    interface: fdfb:2ad3:1200:0:192:168:1:1
    interface: ::1

Raspberry Pi OS

設定可能
/etc/dhcpcd.conf へ、以下のとおり設定します。

static ip6_address=fdfb:2ad3:1200:0:192:168:1:2/64   # ULA

設定ファイルだけを見ると ULA しか設定されないように感じますが、実際には RA で広告したプレフィックスから GUA が自動生成されました。

ubuntu, MacOS など　（2024/02/08 追記）

こちら https://zv-louis.hatenablog.com/entry/2022/01/16/165928 の方の記事が参考になります。

まとめ

総務省などの資料によると、IPv6 デュアルスタック化は、家庭やモバイルでの普及はわりと進んでいるようです。しかしエンタープライズの現場では、なかなか普及が進んでいないようで、構築ノウハウ、運用ノウハウの蓄積もまだまだのようです。
この文書が IPv6 普及の一助になればと思います。

参考資料

プロフェッショナル IPv6 第2版小川晃通著 https://www.geekpage.jp/blog/?id=2021-12-20-1
クライアントOSのIPv6対応状況は？（日経 XTECH https://xtech.nikkei.com/atcl/nxt/mag/nnw/18/091700095/091700005/
クライアントOSのIPv6実装検証から見たネットワーク運用における課題の考察（論文） https://www.ipsj.or.jp/dp/contents/publication/36/S0904-R1701.html
IPv6対応に関するガイドライン（総務省） https://www.soumu.go.jp/menu_seisaku/ictseisaku/ipv6/index.html
IP通信網サービスのインタフェース－フレッツシリーズ－＜光クロス、光ネクスト、光ライト編＞（NTT西日本） https://flets-w.com/service/next/download/tool/gijyutsu_sankou_cross_next_light.pdf
家庭内LANでIPv6のグローバルIP(GUA)とLAN内専用の固定IP(ULA)の両方を使う https://zv-louis.hatenablog.com/entry/2022/01/16/165928

ITOCのネットワーク環境を再整備しました

目標

物理層