「auひかりいいじゃん、安定してるし、速度も出るって聞いたし」
からの「……なんでこうなるの？？？」になった人向けのメモです。
auひかりのIPv6化を諦めていた人必見です。
事の発端
docomo回線の解約に伴いdocomo光を解約
事の発端は、都心への引っ越しを機にdocomo回線をやめて、auに乗り換えたことでした。
以前から話題になっていたdocomoの“パケづまり”問題を何度も遭遇し、「これはもうあかん」と判断。モバイル側をauにしたところ、これが想像以上に改善して「やっぱり原因そこだったか」と納得、という流れです。
で、ここでひとつ問題が出ます。モバイル回線をdocomoから切ると、セットで使っていたdocomo光がうま味ゼロになるんですよね。なので固定回線側も見直し、ということになりました。
検討の結果auひかりが良いと判断
前の家ではdocomo光（＝実質フレッツ系）を使っていましたが、docomoを解約したのでこれは継続できません。
同じくフレッツ系で行くことも考えましたが、MAP-EやDS-Lite経由でIPv4を使う構成よりも、最初からグローバルIPv4が素直に振られるほうが扱いやすい。さらに、評判としても「混みにくい・速度が出やすい」という声が多かったので、ここはauひかりに乗り換えることにしました。
auひかりのクソポイント列伝
もちろん、検討段階でauひかりのHGW（ホームゲートウェイ）の評判が良くないことは最初から織り込み済みでした。
なので「HGWを素直に家庭用ルーターとして使う」のではなく、最初から“HGWはAUの都合のために置いておくもの”として扱い、その下に自前ルーターをぶら下げる前提で話を進めました。
HGWの地雷仕様
以下が現在知られている地雷仕様と対処法です。
NECルーターの持病「Atram病」
auひかりのHGWでよくあるNEC系（Aterm系）の挙動として、ちょっと凝ったトラフィックを流すと急に重くなる／反応が怪しくなるというのがあります。ここでは便宜上「Aterm病」と呼びますが、だいたいこんなパターンで出ます。
・配下の端末が多くなると、HGWがフリーズしたようになって通信不可になる。
・主原因はNATテーブルのあふれでメモリリークを起こすっぽい（セッションが多い家庭・P2P・ゲーマー・IoT多めだと踏みやすい）
・実家でもこれに当たって、YAMAHAルーターに置き換えたらピタッと止まった、という実例あり
ポイントは、HGWに“ぜんぶ”やらせると落ちやすいということです。
IPv4は2重ルーターで対処可能
IPv4については、すでにQiitaやブログにたくさん事例があるとおり、意図的に2重ルーター構成にしてしまうのが定石です。
上段：auひかりのHGW（プロバイダとの付き合いのために置いておくもの）
下段：自前ルーター（pfSense・YAMAHA・RTX・EdgeRouter・民生機どれでもOK）
という二段構成にして、下段で好きにNAT・フィルタ・DHCP・APをやる。
私もこの“よくあるやり方”に乗っかって、最初から「2重ルーターでいく」前提で計画しました。
IPv4に関して言えば、この方法でほぼ困りません。
IPv6が地獄の始まり
技術屋としては「IPv6は早く普及させたいし、どうせならネイティブで動かしたい」というのがまず頭にあります。なので今回の構成でも、IPv6を最初から有効にすることを大前提としました。
ところが「auひかり＋HGW＋2重ルーターでIPv6もちゃんとやる」という組み合わせにした瞬間、きれいに地雷を踏み抜きました。原因はほぼauひかりの仕様とHGW側のIPv6の出し方にあります。
/64固定でプレフィックス再配布不可
本来、2重ルーター環境で“下側のルーター”にもグローバルIPv6を配らせたい場合は、/60とか/56とか、複数サブネットに割れるサイズのプレフィックスをもらう必要があります。そうすれば：
・HGW：上からもらった/56を持つ
・自前ルーター：その/56の中から/64をいくつか切って、LANごとにばら撒く
というふつうの「IPv6をちゃんと配る」ができます。
が、auひかりのHGWはここを1本の/64でしか出してくれないんです。
つまり「この1本をそのままLANで使ってね」という前提で設計されている。これだと下のルーターに“また配って”と言えないので、2重ルーターでIPv6のグローバルをきれいに配ることができません。
その結果どうなるかというと、ULAを使って、そこからNPtやNAT66で外側の/64に載せ替えるしかないという、あんまりやりたくない世界に連れて行かれます。これが今回の地獄の根っこです。
RA範囲を制御できずNPt不可
「じゃあHGWが出すRAの範囲を絞って、NPtで使うアドレスと被らないようにすればいいじゃん」という発想も当然出ます。
ところが、HGW側でRAの配布範囲や内容を細かくいじることができない。停止するかしないか、くらいのざっくり制御しかない。
NPtをまともにやるには、
「ここからここまではHGWが配る」
「ここからここまでは自分がNPtのために使う」
と線引きできないといけませんが、HGWがそれをやらせてくれないので、「HGWのRAを止める」といった力技をしない限りNPtをきれいに回すのは無理です。
もちろん、自前ルーターとAU HGWの間に何も繋がなければRAを無効化し、すべてNPtのアドレスとすることも可能ですが、これも後述する理由であまりおすすめしません。
NAT66以外に実用的選択肢がない
そうなると残るのはNAT66です。
今回の自分の例では、HGWが出すRAを無効化できないため必然的にこの方式になります。
IPv6の世界観からすると「NATするな」「グローバルをそのまま配れ」が正義なのはわかっているのですが、HGWが/64を1本しかくれない・RAもいじれないという条件だと、実用的に残るのがここしかない。
つまり今回のケースでは、
・宅内ではULAを使う
・外に出るときだけHGW側の/64にNAT66で載せる
という“IPv6でやりたくなかったこと全部セット”みたいな構成になってしまいます。
AndroidなどでIPv6が優先されずIPv4でしか通信できないケースあり
さらに追い打ちで、モバイル端末や未設定のPCなどはULAが絡むIPv6環境をあまり前向きに使ってくれないことが多いです。
内部でULA＋NAT66 or NPtという構成にすると、
・IPv6アドレスはあるように見える
・でもその経路の優先度が低いので積極的に使ってくれない
という状態になり、実質IPv4でしか通信しない「IPv6にしたのに意味ないじゃん」になることが起きます。
章まとめ
要するにこの章で言いたいのは：
・HGWが/64を1本しかくれない時点で、家庭で“ちゃんとした”IPv6多段構成をやるのはほぼ詰み。
・無理にやろうとするとNAT66やNPtに落ち、そこにAndroidの優先度問題が乗って「IPv6を頑張ったのに使ってくれない」という最悪の結果になる。
だからこそ、あとで出てくる「IPv6はHGWに丸投げ、IPv4だけ自前でやる」が“現実解”になるわけです。
ヘビーユーザー向けの推奨構成
ここでは、「auひかりを使ってるけど、HGWのせいでIPv6はもう無理って思ってた人」に向けた現実解を書きます。
このやり方なら、HGWをぶっ壊さず、IPv6も捨てず、IPv4だけを自前でガッツリ管理できます。そんなにお行儀のいい構成じゃないけど、“家庭で安定して使える”という意味では一番バランスがいいです。
発想の転換：「IPv6はHGW任せ、IPv4は自前ルーターで管理」
ここまでの話をまとめるとこうなります。
・auひかりのHGWは、IPv6を"/64 1本だけLANにばら撒く前提"でできている
・そのIPv6を“さらに下のルーターで再配布する”のがほぼ無理
・無理にやるとNAT66やらNPtやら、Android優先度問題やらで地獄を見る
なので、「じゃあIPv6だけはHGWにやらせとけばよくない？」という逆張りになるわけです。
この発想にすると一気にシンプルになります。
・IPv6 … HGWがそのまま配る。自前ルーターはIPv6に手を出さない（orパススルーだけ）
・IPv4 … 自前ルーターでNAT・フィルタ・DNS・APを全部やる
「Aterm病」についても、あれはだいたいNATをHGWに集中させてるときにテーブルが詰まるので、IPv4のNATを自前ルーター側に逃がしておけば、HGW側はIPv6をばら撒いてるだけになり、そうそう破綻しなくなるわけです。
パターンA：HGWにIPv6パススルー機能がある場合
これは一番ラクで一番きれいなパターンです。HGWが“下にいるルーターにIPv6を渡してもいいよ”と言ってくれるタイプのやつですね。
やることは2つだけです。
一般的な2重ルーターの構成にする
ネットワークのつなぎ方はフツーでOKです。
UPnPを行いたい場合はauひかりのHGWのDMZを有効にします。
自前ルーターのIPv6パススルー機能を有効にする。
次に、自前ルーター側でIPv6パススルーをONにします。
これをやると、HGWが持っているIPv6をそのまま端末が受け取れるので、LAN側の端末も素直にIPv6を使えるようになります。
ポイントはここです：
・HGWは「/64を1つ配る前提」だが、それをそのまま下のルーターに“通すだけ”ならできる
・下のルーターも「配ってください」とは言わずに「受け取ってLANにそのまま流します」だけをやる
・つまり再配布はしない、あくまで“パススルー”に徹する
これで「IPv6はHGWがつないでくれてる」「IPv4は自分のルーターが守ってる」という、いちばん迷惑のかからない構成が完成します。
もし、auひかりを検討中という方は「IPv6のパススルー機能があるか」を自前ルーターを選定する際に気にすることで最小の労力でIPv6環境を構築できます。
パターンB：パススルー機能がない場合
HGW側にIPv6パススルーがない場合は、さっきのパターンAみたいに「つなぐだけで終わり」とはいきません。ちょっと気持ち悪い配線と、いくつかの“衝突を起こさないための前処理”が必要になります。とはいえ、手順を踏めばちゃんと動きます。
HGWのLAN側に、自前ルーターのLANポート、LANポートを接続
やりたいことはこうです。
★HGWのLANに「自前ルーターのWAN」と「自前ルーターのLAN」をどっちもつなぐ
文字にするとループしそうですが、ここでは自前ルーター側でL2が分かれている（WANとLANは別ブリッジになってる）ので、スパニングツリーを仕込まなくても実際にはループしません。見た目が気持ち悪いだけです。
図にするとだいたいこんな感じ。
これだけではよくわかりにくいですが、論理的にはこうなります。
ポイントは「HGWのL2に全員を乗せてIPv6だけ拾わせる」ことです。IPv4は自前ルーターが配るので混ざりません。
ポイントはHGWのLANに乗っているものは全部HGWのIPv6をそのまま受け取れるようにしておくこと。自前ルーターはIPv4のためだけに存在する、という立ち位置になります。
この場合はUPnPはやめておいたほうが良いでしょう。
HGWのIPv4のDHCPを無効にする（超重要）
この構成では、同じL2上に「HGW」と「自前ルーターのLAN」が共存することになります。ここでHGWがIPv4のDHCPをばら撒いていると、自前ルーターが配ろうとしているIPv4のDHCPとぶつかってカオスになります。
なのでここは必ず、
・HGWの「LAN側DHCPサーバー」を無効にする
・IPv6はそのままにしておく（HGWがやる）
という状態にしておきます。
「DHCPv4だけ止めて、RAは止めない」というのがキモです。
固定IPで自前ルーターとHGW間を通信可能にする
DHCPを止めたので、今度は自前ルーターのWANに固定でアドレスを振る必要があります。いわゆる“二重ルーターの間にある中間ネットワーク”を手で作る感じです。
例としてはこんな感じにしておくと分かりやすいです。
・HGW（LAN）：192.168.10.1/24
・自前ルーター（WAN）：192.168.10.2/24（固定）
・デフォルトゲートウェイ：192.168.10.1（HGW）
・DNS：HGWに登録されている上位DNSか、HGWか、好きなパブリックDNS
これで、自前ルーターはIPv4的にはちゃんと“上にHGWがいる”と認識できるようになります。
自前ルーターは、IPv6の全機能OFF、IPv4を一般的な2重ルーターの設定に
ここがこのパターンBのいちばん大事なところです。
★自前ルーター側ではIPv6に一切手を出さない。RAもしない。DHCPv6もしない。とにかくOFF。
なぜかというと、同じL2にHGWのRAが飛んでくるので、ここで自前ルーターがさらにRAを出すと、どっちのルーターがデフォルトゲートウェイか分からない状態になります。最悪、端末がIPv6だけHGWに行こうとして死ぬ、みたいなことも起こる。
なので、自前ルーターはIPv4専用機にしてしまいます。設定の目安はこんな感じ。
・IPv6：WANもLANもすべて無効
・RA：無効
・DHCPv6：無効
・IPv4：いつもの二重ルーター設定（NAT有効、LANの例：192.168.0.0/24）
こうしておけば、IPv6はHGWが配る・IPv4は自前ルーターが配るというきれいな役割分担になります。
最後にLANポートをHGWに挿す
ここまでの設定をしてから、自前ルーターのLANポートをHGWのLAN側に挿すようにします。逆順にやると、DHCPがぶつかったりして一時的に「なんかつながらない」状態を踏みやすいので注意。
この時点で端末の挙動はこうなります。
・端末のIPv6 → HGWからもらう（= auひかりの世界に直で出る）
・端末のIPv4 → 自前ルーターからもらう（= 家の中の好きなセグメントを作れる）
つまり、「IPv6だけはハブみたいにHGWから直で流れてるのに、IPv4はちゃんとNATされている」という、一見ねじれてるけど実用上はとても扱いやすい状態になるわけです。
章まとめ
IPv6はHGWに丸投げ → HGW負荷最小化
今回の肝はここです。IPv6まわりの面倒なところ（/64しか出さない、RAをいじれない）はぜんぶHGWの“縄張り”として尊重するので、HGWに無理をさせません。HGWは「auひかりの仕様どおりにIPv6を配る」だけなので、NATテーブルがパンパンになるとか、ルーターがパンクして不機嫌になるといった事故が起きにくくなります。つまりHGWを家庭用ルーターとして一番楽な働き方にしてあげる構成です。
IPv4は完全二重ルーターで安定
一方で、IPv4はきれいに自前ルーターの世界に閉じ込めます。ここは世の中に事例が山ほどある“ふつうの二重ルーター”なので、トラブルシュートもしやすいし、将来ルーターを買い替えたりしても構成を維持しやすいです。
「IPv6を捨てない」「HGWを殺さない」現実解構成
多くの人がハマるのは「HGWのIPv6が気に入らないから全部OFFにする」か「HGWを超えた本格IPv6を家庭でやろうとして地雷を踏む」かの二択になってしまうことです。この構成はその中間で、
・IPv6は捨てない（HGWが配るものは素直に使う）
・でもHGWには無理をさせない（再配布や変なRAはさせない）
というところに落ち着きます。結果として、“auひかりの仕様に逆らわないで最大限便利にする”という、いちばん現実的な落としどころになります。
我が家の実践構成：pfSenseによるリダンダンシー構成
我が家のネットワークトポロジ
我が家のネットワーク構成は以下のようになります。
どうしてこうなっているかは後で説明します。
Nuroを副回線として活用
新しく契約した賃貸に無料でついてきたNuro回線
引っ越しに伴い、部屋にはNuroの2.5G回線が惹かれておりました、これを常用する事も考えましたが下記の理由で見送っています。
Nuroは速度良いがパケロス経験あり → セカンダリ利用に最適
Nuroはガチ勢の方々なら有名な話なのですが、一時期の通信が遅いのは一定の改善をみましたが。依然パケロスが頻発する状況は続いており、メイン回線にするには少し気が引けます。しかし、せっかくあるものなのでセカンダリ利用には十分に耐えうると考え、リダンダンシー構成を構築する運びとなったわけです。
ネットワーク説明
Main-NetはULAのNAT66接続ながらもリダンダンシー構成
Main-NetはULAのIPv6、NAT66接続ながらもIPv4/IPv6両方での完全リダンダンシー構成を実現しております。
このネットワークはIPv4のみで十分な端末や、IPv4/IPv6の通信優先順位が変更できる端末を収容するネットワークです。特に特別な理由がなければ端末はこのネットワークに参加します。
AU-NET
AU-NETは今回のキモとなる「DHCPv4だけ止めて、RAは止めない」構成をかたどっています、しかしながらAU-HGWはpfSenseへDMZ登録、つまり外からのパケットがツーツーで通る環境であり、あまり安全なネットワークとは言えません。なので、AP-NETへの橋渡しを行う役割のみにとどめています。
HGWでpfSenseをDMZにする場合、HGW直下のL2は“外に近いネット”として扱ってください。なんでもつなぐと危ないです。
AP-NET、Mobile端末への通信
AU-NET経由のAP-NET、Mobile端末への通信についてはネイティブIPv6と2重ルーター（便宜上3重ルーター）の上でのIPv4通信を構成します。またAP Routerは幸いにもIPv6パススルーが使えるため、グローバルのIPv6が割り当てられます。
この構成にすることにより、IPv6はグローバルアドレスを持つことができ、なおかつIPv4はpfSenseを経由、Multi-WAN構成を組むことにより副回線としてNuroを用いることができます。もしauひかりがダウンした場合はNuroでのIPv4通信が可能です。
また、Mobile端末はMain-NetにあるNASに接続できないといけない要件があるので、それもpfSenseでルーティングを行います。この通信はIPv4のみで十分なのでIPv6では通信しないと割り切っています。
Nuro-NET
このネットワークは単にpfSenseとNuro-HGWの通信を担います。
pfSenseの接続
ハードウェア
ハードウェアはAIOPCWAのAI404というミニPCを購入し使用しています。
このハードウェアはファン付きではありますが、かなり放熱に気を使った筐体で、静音性に期待できます。
またSFP+x2と2.5Gメタルx2のインターフェースを持ち、今回のケースに最適です。
インターフェースの役割は以下のようにしました。
・WAN_AU（ix0）: auひかりHGWへ
・LAN_MAIN（ix1）: メイン機器
・WAN_NURO（igb1）: Nuro HGWへ
・LAN_AU-L2（igb0）: IPv4のみ／IPv6無効
pfSenseのパフォーマンス
発熱、騒音
発熱、騒音については無負荷時であればほぼ無音（たまにファンが極低速で回転する程度）高負荷でもほぼ無音です。
発熱に関しても上部が暖かくなる程度でとても熱いというわけではありません。どちらかというと10GのSWのほうがよっぽどアチアチになります。
通信速度およびレイテンシ
Main-NETからインターネットへの通信では以下のような結果になりました、ベスト値ではありますが、auひかり側の混雑にもよるのですが、6.28Gbps、レイテンシ5.00msを記録しております。
この速度でのpfSense側のCPU使用率は15%ほどで、単純なルーティングではまだまだ余裕がありそうな印象です。
残課題
UPnPは未設定です。
まあこれは必要になったら考える程度でいいかなと思っています。
まとめ
・auひかり自体は悪くない。 悪さしてるのはだいたいHGWの“2重ルーターを前提としていないIPv6実装”と、家庭でそれ以上をやろうとする我々の欲。
・HGWは/64を1本配る前提なので、IPv6を多段でキレイに配るのはほぼ不可能。 RAも細かくいじれないので、NPtやPDでの再配布は現実的じゃない。
・無理にIPv6を自前でやろうとするとNAT66・ULA・Android優先度問題の三重苦になる。 “IPv6にしたのにIPv4でしか通信しない”という気持ち悪い状態になる。
・発想をひっくり返して「IPv6はHGWに丸投げ」「IPv4だけ自前で管理」にすると全部丸く収まる。 これはHGWを殺さないための現実解。
・IPv4はふつうの二重ルーターでOK。 下段ルーターで好きにNAT・DHCP・DNS・APすればいい。ここは既存ノウハウが山ほどある。
・パターンA（HGWにIPv6パススルーあり）なら超簡単。 普通に二重ルーター＋自前ルーターでIPv6パススルーON、で終わる。ルーター選定時にここを見ておくと楽。
・パターンB（パススルーなし）はちょいトリッキー。 HGWのLANに自前ルーターのWANとLANを“両方”つなぎ、HGWのDHCPv4を止め、自前ルーターのIPv6を全部OFFにすることで“IPv6だけHGW直配り”を実現する。
・IPv6をHGWに任せるぐらいであればHGWの重荷にはなりにくい。 Aterm病っぽい挙動（NATテーブルあふれ）も、IPv4のNATを自前ルーターに逃がせば踏みにくくなる。
・「IPv6を捨てない」「HGWを殺さない」ので家庭向けとしてはバランスがいい。 auひかりの仕様に逆らわず最大限自由を確保する、ってところが今回のキモ。
・このあとpfSenseやNuroの冗長化を足すなら、この構成を“前提”にして組むと崩れない。 まずは“IPv6＝HGW、IPv4＝自前”を軸にすること。