UniFiでv6プラス固定IPを終端する実装記録

はじめに — なぜこの記事を書くのか

Ubiquiti の UniFi は近年、日本の IPoE 環境への対応を着実に進めています。UniFi Network 9.4（UniFi OS 4.4 以降が前提）では、MAP-E 方式の IPv4 over IPv6 が日本向けの 2 サービス — v6プラス（JPIX） と OCN バーチャルコネクト（NTTドコモビジネス） — でネイティブサポートされ、UI でサービスを選ぶだけで動くようになりました。DS-Lite（transix など）も以前から対応済みです。

ところが、「v6プラス固定IPサービス」だけは話が別です。

動的な v6プラス（MAP-E）と違い、固定IPサービスは IPIP6 トンネル（IPv4 over IPv6）で固定 IPv4 を払い出す方式です。プランにより払い出し個数が異なり、IP1 なら 1 個、IP8 なら /29 ブロック（8 個）といった具合ですが、いずれのプランも UniFi の UI にこの方式の設定項目は存在しません。BR（Border Relay）アドレス・インターフェースID（IID）・更新通知先といった契約固有値を手動で設定する必要があり、ヤマハ RTX や NEC IX には公式の設定例がありますが、UniFi では手当てが要ります（2026年8月時点、最新リリースノートを確認しても固定IP向け MAP-E の追加はありません）。

弊社ではこの役割を従来 NEC UNIVERGE IX シリーズが担っていましたが、拠点のネットワークを UniFi へ統一（ゲートウェイ・スイッチ・AP・カメラ・入退室のフルスタック運用）するにあたり、UniFi Cloud Gateway Fiber（UCG-Fiber）で JPNE の v6プラス固定IPを終端する必要が出てきました。本記事はその実装記録です。日本語の一次情報がほぼ存在しない領域のため、設計判断の理由と、運用で踏んだ落とし穴まで含めて残します。

先に結論：UniFi 純正の DS-Lite 機能に「乗っかる」形でスクリプト補正する方式（本記事では「DS-Lite 乗っ取り型」と呼びます）で、実運用レベルで安定動作しています。検証環境は UCG-Fiber（UniFi OS 5.1.26 系）／フレッツ光ネクスト → 光クロス／JPNE の v6プラス固定IPサービスです。

v6プラス固定IPの仕組み

v6プラス固定IPサービスの構成要素は、ISP からの登録通知書に記載されます。おおむね次の通りです。

IID の埋め込み規則は、複数の実装報告から確認できます。たとえば固定IPv4が 203.0.113.42（各オクテットを 16 進で cb 00 71 2a）なら、IID は 00cb:0071:2a00:0000 になります。通知書の値と、この計算値が一致するはずです。

ルーター側の仕事は「WAN の IPv6 プレフィックス＋IID」をローカル端点、BR を対向として IPIP6 トンネルを張り、固定IPv4 /32 をトンネルに割り当てて SNAT すること。IX なら ipv6 interface-identifier と tunnel destination、RTX なら tunnel encapsulation ipip で組む、あの構成です。

UniFi の公式対応状況（2026年時点）

まず「スクリプトなしで済む範囲」を正確に押さえます。

なお OCN バーチャルコネクトの「固定IP1」については、MAP-E 方式のため UI の設定手順は動的と同じと考えられますが、弊社では未検証です（後述の「未解決の論点」も参照）。スクリプトが必要になるのは、あくまで JPNE の v6プラス固定IP のケースです。

先行事例（OSS）— ベースにした実装

車輪の再発明はしていません。国内で公開されている先行実装を精読した上で設計しました。

NadjaSenpai / unifi-v6plus-static-ip（自前トンネル方式）

• 解説記事：https://nadja.jp/posts/unifi-v6plus-static-ip/
• リポジトリ：https://github.com/NadjaSenpai/unifi-v6plus-static-ip

UniFi OS ゲートウェイ（UDM/UDR）上で v6プラス固定IPを動かす、おそらく国内初の公開実装です。設計の要点は次の通り。

• UI の WAN は DHCPv4 + DHCPv6 にしておき、MAP-E/v6プラスには設定しない（UniFi が競合する ip6tnl1 トンネルと table 201 のポリシールーティングを生成してしまうため）
• スクリプトが自前で v6plus0 トンネルを張り、固定IPv4 /32 を割当・SNAT・MSS クランプ
• ネイティブ IPv6 を壊さないため、トンネルローカルの IPv6 は WAN に /128 で追加する
• UDR/UDM では systemd ユニットを /etc/systemd/system/ に実ファイルとして置く必要がある（シンボリックリンクは不可）

作者検証は UDR7。README にも明記がありますが、UniFi OS/Network のアップデートでインターフェース名や iptables チェーンが変わり得るため自己責任前提です。

弊社ではこの実装を土台に、自前でトンネルを張るのではなく、UniFi 純正の DS-Lite 機能に作らせたトンネルを事後補正するという別方式を採りました。次章で詳述します。

採用した方式：DS-Lite 乗っ取り型

弊社が実装したパッケージ（社内名 v6plus-ucg）の設計はこうです。

基本思想

UniFi UI で WAN を DS-Lite モードに設定し、AFTR アドレスに JPNE の BR アドレスを手動入力します。すると UniFi は（AFTR だと思い込んで）BR 宛の IPIP6 トンネル ip6tnl1 を純正機能として生成します。ここにスクリプトで 3 点だけ手を入れます。

1. トンネルのローカル端点を「WAN プレフィックス + JPNE 登録 IID」の IPv6 アドレスへ差し替え
2. トンネルの IPv4 アドレスを DS-Lite 規定の 192.0.0.2 → 固定IPv4 /32 へ差し替え
3. SNAT を固定IPv4 へ向ける

トンネルの生成・ルーティング・UI 連携・死活監視はすべて UniFi 純正の管理下に残るため、自前トンネル方式で問題になりがちな「UI のファイアウォールやポート転送が効かない」「Internet Down 表示が消えない」といった副作用の大半を、構造的に回避できます。乗っ取るのは端点とアドレスだけ、という最小介入の設計です。

補足として、BR からの戻りパケットを着信させるため、WAN インターフェースにローカル端点の IPv6 を /128 で付与します（/64 で付けるとソースアドレス選択が狂うため /128 が正解）。

JPNE 固有の追加実装：enabler の更新通知

JPNE の固定IPは、http://fcs.enabler.ne.jp/update への更新通知を定期的に送らないと割当が維持されません（IX では ddns profile として実装されている、あの挙動です）。弊社実装では 10 分間隔の systemd タイマーで同等の周期実行を行い、HTTP 200 かつ本文に失敗語（badauth 等）が無ければ成功、として監視しています。認証情報は環境ファイル（パーミッション 600）に分離し、スクリプト本体・ログには一切出しません。

パッケージ構成

/data/v6plus/                 # /data は UniFi OS の永続領域（FW更新でも残る）
├── config/
│   ├── v6plus.env            # WAN_IF / 固定IPv4 / BR / IID / MTU / MSS など
│   └── update.env            # enabler 更新の認証情報（chmod 600）
├── scripts/
│   ├── v6plus-fixedip.sh     # 本体：apply / status / off
│   ├── v6plus-lib.sh         # 共通ライブラリ（判定ロジックを一元化）
│   ├── v6plus-watch.sh       # watchdog（ポーリング・保険）
│   ├── v6plus-trigger.sh     # watchdog（netlink イベント駆動・主役）
│   ├── v6plus-wait-wan.sh    # 起動時の WAN 準備待ち
│   ├── v6plus-update.sh      # enabler 更新通知
│   └── v6plus-diag.sh        # 読み取り専用の総合診断
└── systemd/                  # 各 .service / .timer

systemd ユニットは /etc/systemd/system/ へ実ファイルとしてコピーします（前述の通りシンボリックリンクは不可）。

最大のハマりどころ：UniFi が設定を「戻す」問題

このプロジェクトで最も時間を溶かしたのが、**UniFi が定期的にトンネル IPv4 を 192.0.0.2 に巻き戻す（revert する）**問題でした。巻き戻ると BR への通信が全ロスし、一瞬 WAN が落ちます。原因の切り分けに一番苦労したので、詳しく残します。

なぜ戻るのか

192.0.0.2/29 は、UniFi が DS-Lite WAN に機械的に振る静的アドレス（RFC 6333 の B4 アドレス）です。これは設定ファイルに焼き込まれており、コントローラが設定を再生成するたびに復活します。DS-Lite に固定IPを持たせる UI フィールドが無い以上、これは構造的な制約で、乗っ取り＋watchdog は対症療法です。

そして厄介なことに、設定を保存するたびに必ず再生成が走る状態になっていました。ログを追うと、24 時間で config-migrate が走った回数と Apply new configuration の回数が完全に一対一で対応します。

根本原因は、コントローラとファームウェアのスキーマ世代ズレでした。コントローラ側が旧世代（v1 相当）のスキーマで設定を書き出すのに対し、ファーム側のバリデータは新世代（v2）を要求します。具体的には、ファイアウォールルールの log キーが boolean で保存されているのに、バリデータは object を要求するため、保存のたびにマイグレーションが発火します。しかもマイグレーション結果は一時領域にしか書かれず、永続側は旧形式で書き続けられるため、次の保存でまた元に戻る——という無限ループでした。

この不整合の大半はコントローラが内部生成するゾーン間の jump ルールで、UI のポリシー一覧には現れず編集手段がありません。つまり GUI では直せない、Ubiquiti 側のスキーマ生成の不具合であり、根治はアップデート待ちという結論です。ユーザー側でできるのは、巻き戻りを素早く検知して自動で戻す仕組みを持つことだけでした。

watchdog は 2 段構え

そこで、SNAT・トンネル補正の消失を監視して自動再適用する watchdog を実装しました。ポイントは 2 系統を併用していることです。

• ポーリング型（保険）：数秒間隔でトンネル存在・固定IP付与・SNAT の有無を確認し、連続で異常なら再適用。取りこぼしが無い代わりに、復旧まで最大で数秒かかります。
• イベント駆動型（主役）：ip -o monitor address でカーネルの netlink アドレスイベントを直接購読し、トンネル IPv4 の変化を検知したら即座に再適用。実測 1.1〜1.2 秒で復旧します。

当初はコントローラのログを監視するイベント駆動を試しましたが、そのログが実イベントから 3〜4 秒遅れて出るため、ポーリングに毎回先を越されて機能していませんでした。netlink 直結に変えて初めて、イベント駆動が主役として効くようになりました。

なお、イベント駆動型には限界があります。アドレス変化を伴わない revert（SNAT だけ消える、トンネル端点だけ戻される、WAN プレフィックスだけ変わる等）は netlink のアドレスイベントが出ないため検知できません。これはポーリング型が拾います。イベント駆動があるからとポーリングを止めてはいけない——これは実運用で得た教訓です。

復旧時間は、対策を重ねるごとに次のように短縮できました。

MTU / MSS の確定値

IPIP6 トンネルでは MTU/MSS の調整を誤ると「一部サイトだけ遅い・繋がらない」「アップロードが失敗する」といった分かりにくい障害になります。実測の結論はシンプルでした。

• トンネル MTU = 1460 / MSS = 1420（両方向）。IPoE（v6プラス/DS-Lite/MAP-E）の業界標準（1500 − IPv6 ヘッダ 40 = 1460、1460 − 40 = 1420）で、UniFi の自動値とも一致します。
• UniFi の UI「MSS クランピング」設定は DS-Lite トンネルには効きません（対象デバイスが別のため）。トンネルの MSS はスクリプト側で固定値を設定します。UI 側は Auto のまま触らないのが正解です。

余談ですが、「海外動画のシークが遅い」といった症状は MTU ではなく CDN までの RTT（海外ノードは 100ms 級）が原因のことが多く、ここを MTU でいじろうとすると泥沼にはまります。

光ネクスト／光クロス、2 つのパターン

弊社では当初フレッツ光ネクストで構築し、後日**フレッツ光クロス（クロスパス経由）**へ移行しました。方式（DS-Lite 乗っ取り）と契約値は不変で、変わるのは IPv6 配布の粒度だけです。ここは回線種別で正解設定が異なる、フレッツ×UniFi 最大の落とし穴なので両方残します。

光クロスで VLAN 別に /64 を配る手順

1. WAN：IPv4 = DS-Lite（BR 手動）、IPv6 = DHCPv6・PD サイズ 56。網から /56 を受領できることを確認
2. 各ネットワーク：IPv6 = プレフィックス委任、委任元 = WAN、割り当て = SLAAC、RA = 有効
3. 検証：固定IP の生存に加え、各 VLAN から ping6 と curl -6 が通る（＝IPv6 経路が生きている）ことを確認

光ネクストの「/64 単一」では業務用 VLAN に正規の IPv6 を配れませんが、光クロスの /56 ＋ VLAN 別 PD なら各 VLAN が自前の /64 を持つ正しいデュアルスタックを組めます。回線を太くする以上に、IPv6 の設計をまともにできることが光クロス移行の実利でした。

導入フェーズと「合格基準」

実導入はフェーズゲート方式で進めました。特にフェーズ1の合格基準の理解が重要です。

フェーズ1：UI 設定のみ（スクリプト未適用）

1. UniFi Network → Settings → Internet → 対象 WAN
2. IPv6 は DHCPv6（光クロスなら PD サイズ 56）／光ネクストなら単一ネットワーク
3. IPv4 Connection：IPv4 over IPv6 → DS-Lite
4. Gateway/AFTR Address：Auto を外し、JPNE の BR アドレスを手動入力
5. SSH を有効化。UI の MSS クランピングは触らない

重要：この時点で IPv4 が通らないのは正常です。 JPNE の BR は DS-Lite の AFTR ではないため、送信元 192.0.0.2 のパケットは破棄されます。フェーズ1の合格基準は「トンネルが生成され、BR に IPv6 で疎通があること」であり、UI 上の "Internet Down" 表示はこの段階では無視して構いません。ここで「動かない」と判断して切り戻すのが、一番もったいない失敗です。

フェーズ2：診断と環境固定

読み取り専用の診断スクリプトで、実機の WAN インターフェース名・生成されたトンネル名を確認して環境ファイルに固定します。弊社の UCG-Fiber では WAN が eth4 でしたが、機種・OS バージョンで変わり得るため決め打ち禁止です。

フェーズ3：適用と検証

apply 後、curl -4 https://api.ipify.org で出口が契約の固定IPv4 になっていること、curl -6 でネイティブ IPv6 が生きていることの両方を確認します。外部（モバイル回線）からのポート転送疎通、WAN 再接続後の固定IP維持まで見て完了です。

起動直後の窓に注意

再起動直後は WAN のグローバル IPv6 付与が完了するまで apply が失敗します。弊社環境では、起動から WAN 準備完了まで実測で約 8 分かかったこともありました。固定の sleep で待つのではなく、WAN プレフィックスが確定するまでポーリングで待つ設計にし、systemd 側のタイムアウトも十分に長く取る必要があります。

切り戻し方針

どの段階でも「UCG を外して旧ルーターを戻す」だけで復旧します（移行元のコンフィグは無変更のため）。スクリプト起因の異常なら、off を実行してから UI で WAN 設定を一度変更（再プロビジョン）すれば純正状態に戻ります。

切り戻し手段を先に確保してから触る——これは方式に関わらず鉄則です。なお、watchdog を複数系統に増やしたら、切り戻し手順（停止対象のユニット）にもれなく含めること。片方だけ止めても、もう片方が数秒で設定を打ち消してしまいます。

まだ答えを持っていない論点：ONU 交換とプレフィックス変更通知

最後に未解決の論点を一つ。OCN バーチャルコネクトの固定IP1 を UniFi のネイティブ機能で使う場合の話です。

OCN の固定IP1 には、WAN 側 IPv6 プレフィックスが変わった際（典型例は ONU 交換）に、OCN のアドレス管理システムへプレフィックス変更通知を送る仕組みがあります。ヤマハ・NEC のルーターはこれを内蔵機能で自動処理しており、実際、ヤマハ RTX の事例で「ONU 交換後に固定IPv4 が変わってしまった」というプレフィックス再バインド起因のトラブルも報告されています。

UniFi の MAP-E 実装がこの通知メカニズムを持つかは、公式ドキュメントに記載がなく未確認です。通常運用では顕在化せず、ONU 故障交換という数年に一度のイベントで初めて踏む類の穴なので、検証報告も見当たりません。弊社では、WAN の再接続・再起動を意図的に行って固定IP が維持されるかを確認する実機検証を予定しています。結果は続報として公開します。同様の検証をされた方がいれば、ぜひ情報交換させてください。

まとめ

「UniFi は日本の回線で使えるのか」という問いへの答えは、2026 年現在「ほぼ使える。ただし JPNE の固定IPだけは手を動かす必要があり、その方法は確立できる」です。しかも一度確立してしまえば、ゲートウェイ・スイッチ・AP・カメラ・入退室までを 1 つの管理画面で運用できる UniFi の利点を、日本の固定IP 環境でもそのまま享受できます。

謝辞

本実装は NadjaSenpai 氏の unifi-v6plus-static-ip（および解説記事 nadja.jp）の知見の上に成り立っています。日本語での貴重な一次情報に感謝します。

免責

• 本記事の手法は Ubiquiti 非公式です。UniFi OS / Network のアップデートでインターフェース名・ファイアウォールチェーン・挙動が変わる可能性があります
• 記事中の IP アドレス等はすべて例示用（ドキュメント用アドレス）に置き換えています。必ずご自身の ISP 割当値を使用してください
• 更新通知 URL 等の認証情報は、絶対に Git・チャット・ドキュメントに平文で残さないでください

弊社では、UniFi × 日本回線の設計・構築・移行支援を承っています。JPNE の固定IP、閉域 VPN との併用、Meraki / Cisco からの移行など、フレッツ系回線特有の要件を含む案件も、営業を介さず現役のエンジニアが直接ご相談を伺います。お問い合わせはこちらから、お気軽にご相談ください。現地調査・お見積りは無料です。

関連記事

• UniFiで自社オフィスをフルスタック構築した実践レポート
• UniFi vs YAMAHA・Cisco｜インフラ屋の正直比較