IPv4接続なしでインターネットを使う

 (jamesmcm.github.io)
3 ポイント 投稿者 GN⁺ 2025-06-30 | 1件のコメント | WhatsAppで共有
  • 停電後、ISP側で IPv4接続だけが切れ、IPv6は生きている状況 になり、IPv4-onlyサイトへのアクセスを復旧するために、IPv4/IPv6の両方を持つHetzner VPSとWireGuardトンネルを使用した
  • 障害は CG-NAT層 でIPv4パケットが正しく変換されずにドロップされたことが原因とみられ、IPv6をサポートするGoogle・Metaのようなサービスには引き続き接続できた
  • VPSにWireGuardサーバーを置き、クライアントがVPSの IPv6アドレスをエンドポイント として使えば、IPv4トラフィックをVPS経由で流して通常のWebブラウジングを復旧できる
  • 業務用VPNとDockerは別途対応が必要で、voponoベースの ネットワーク名前空間 と unshare・/sys bind mount回避策により、その名前空間内で実行した
  • 一部のサイトだけ読み込めない症状は WireGuard MTU が大きすぎたことが原因で、IPv6最小MTUの1280に下げると即座に解決した

停電後にIPv4だけが切れた障害

  • 停電後にブレーカーを復旧したものの、GitHubや複数のWebサイトにアクセスできず、GoogleとMetaは正常に動作していた
  • ローカルマシンとルーターの診断ページで ping -6、traceroute を確認した結果、問題は IPv4サーバーへの接続 にだけあった
  • ISPは技術者の訪問が必要になる可能性があり、週末明け以降の数日かかるかもしれないとしており、業務アクセスや論文作業の都合で障害復旧を待ちにくかった
  • 既存のHetzner VPSには静的IPv4アドレスとIPv6アドレスがあり、HetznerのWebサイトはIPv6をサポートしていたため、コンソールにアクセスして設定を進められた

NATとCG-NATが生んだIPv4依存

  • IPv4アドレスは32ビットで、予約ブロックを除くと公開IPv4アドレスは約 37億個 しかなく、すべてのインターネット接続機器に直接アドレスを割り当てることはできない
  • NAT は複数の機器が1つの公開IPを共有できるようにする
    • ホームルーターは内部機器の 192.168.1.xxx のようなローカルIPを、自身の公開IPv4に変換する
    • Linuxのconntrackは、元の送信元IPとポート、変換後のポートをマッピングとして保存する
    • 応答パケットがそのポートに届くと、conntrackが宛先を元の内部IPとポートに戻す
    • Linuxでは conntrack-tools の conntrack -L で保存済みマッピングを確認できる
  • NATは暗黙のファイアウォールのように動作するため、ルーター配下のローカル機器上のサービスは、明示的な ポートフォワーディング なしでは外部からアクセスしにくい
  • ISPはIPv4不足のため、内部でもNATをもう一段適用することがあり、これを Carrier Grade NAT(CG-NAT) と呼ぶ
    • ホームルーターが複数のローカル機器をNATするのと同様に、ISPルーターは複数のホームルーターをNATする
    • ISPが持つIPv4アドレス数や割り当て方針によっては、地域単位など複数の階層で繰り返されることもある
  • 今回の障害は、CG-NAT層のどこかでIPv4パケットが正しくNATされずにドロップされ、IPv4トラフィックが完全に途絶した状態だったとみられる
  • NAT traversalの回避方法については、Tailscaleの How NAT Traversal Works が参考になる

IPv6が動き続けた理由

  • IPv6アドレスは128ビットで、予約ブロックを考慮しても約 3.4E38個 のアドレスを提供する
  • 家庭用ルーターが /64 サブネットを受け取ることは一般的で、これは 1.84E19個 のアドレスを意味する
  • IPv6ではホームルーターでNATを使わなくても、各機器がインターネット上で直接アドレスを持てる
    • ポートフォワーディングの問題は減る
    • その代わり、ルーターや各機器には、外部からの任意の新規接続を防ぐ適切なファイアウォールルールが必要になる
  • IPv6にはCG-NATが適用されていなかったため、今回の障害の影響を受けなかった
  • GitHubのように、依然としてIPv6ではアクセスできないWebサーバーもあるため、IPv6接続だけではインターネット全体をそのまま利用することはできなかった

WireGuardでIPv6上にIPv4トンネルを作る

  • 解決策は、VPSに WireGuard をインストールし、クライアントがVPSのIPv6アドレスをエンドポイントとして使う形でトンネルを構成することだった
  • トンネルが確立すると、IPv4トラフィックはVPS経由で正常に動作する
    • VPS経由になるぶん遅延は増える
    • 動作としては、自前で構成したDual-Stack Liteに近い
  • サーバーは、既存の vps2arch でArch Linuxを導入済みのHetzner VPSで、Hetznerの最新Debianイメージをベースに利用していた
  • WireGuard設定は、ArchWikiの WireGuard specific use-case: VPN server をベースに、IPv6トラフィックを追加した形だった
  • サーバー設定には次が含まれる
    • Address = 10.200.200.1/24, fd42:42:42::1/64, 2001:db8:abcd:1234::1/128
    • IPv4は iptables の MASQUERADE でフォワード
    • IPv6 ULAは ip6tables の SNAT --to-source でNAT
    • IPv4/IPv6 forwardingを有効化
    • peerは、直接IPv6 Global Unicast Addressを使う foo と、NATされたIPv6 ULAを使う bar の例に分かれる
  • wg-quick は .ini スタイル設定とは異なり PostUp と PostDown を複数回指定でき、各コマンドを順番に実行する

IPv6 NAT、SNAT、クライアント設定

  • IPv6では必ずしもNATは必要なく、HetznerのようにVPSに /64 IPv6ブロックがあるなら、peerに直接 Global Unicast Address(GUA) を与えられる
  • 直接アドレス方式を使うには、peerとインターフェースのUnique Local Address(ULA)を公開IPv6アドレスに置き換え、ip6tables MASQUERADE ルールを削除する
    • 各peerは割り当てられたIPv6アドレスでインターネットから直接アドレス指定できるようになる
    • 複数機器で独自サービスをフォワードしたい場合、この方式が適している
    • VPSのファイアウォールが受信トラフィックを正しく処理する必要がある
  • VPSのIPアドレスが静的で変わらないと確信できるなら、MASQUERADE の代わりに SNAT を使える
    • MASQUERADE は実行時にインターフェースIPを参照する
    • SNAT はアドレスを直接指定するため、やや効率的である
  • クライアント設定では、サーバーのIPv6アドレスを Endpoint = [2001:db8:abcd:1234::1]:51820 のように角括弧で囲む必要がある
  • AllowedIPs = 0.0.0.0/0, ::/0 により、IPv4/IPv6の全トラフィックをトンネルへ流す
  • 両側で起動後、通常のブラウジングは正常化し、トンネルのローカルIPv4およびIPv6アドレス経由でサーバーへ直接SSH接続もできた
  • Linuxでは、妻のマシンにもWireGuardクライアントを簡単にインストールできた

業務VPNはネットワーク名前空間で分離

  • WireGuard接続の上にそのまま業務用VPNを接続すると衝突が発生し、利用できなかった
  • vopono を使って、業務VPNと必要なアプリケーションを ネットワーク名前空間 内で実行した
  • 重要なのは、MASQUERADEルールが実際のネットワークインターフェースではなく、動作中のWireGuardインターフェース(foo または bar)へトラフィックを流すようにすることだった
  • 名前空間内のトラフィックはホストのWireGuard nftables ルールを直接意識しないが、実際にはWireGuardトンネル経由でルーティングされる
  • wg-quick は利用可能な場合、iptables より nftablesを優先 するが、Dockerの標準 iptables ルールとの衝突は避けられた
  • voponoの実行例は次のとおり
$ vopono -v exec --create-netns-only --provider None --protocol None -i bar bash
$ sudo ip netns exec vo_none_none bash
$ (inside netns) ./vpn.sh
  • /etc/netns/vo_none_none/ は ip netns exec により /etc としてマウントされるため、その名前空間専用の resolv.conf を置ける
  • IPv4 DNS解決を優先したい場合は、同じ方法で gai.conf も調整できる
    • この設定は、IPv6トンネルトラフィックの問題をデバッグしていた間に使用された
    • 例は AskUbuntuの回答 をベースにしている
  • 業務VPN接続後、内部DNSサーバーを /etc/netns/vo_none_none/resolv.conf に入れると、その後その名前空間で実行したアプリケーションは正常に動作した
  • Chromeのようなアプリケーションも一般ユーザー権限で名前空間内から実行できる
$ vopono -v exec -i bar --provider None --protocol None google-chrome-stable

Dockerを同じ名前空間で動かす

  • Dockerは、単に他のアプリケーションのようにネットワーク名前空間で実行しても動作しない
    • systemdで有効化されたDocker socketが名前空間の外で作成されているためである
    • 内部接続性が確保されない
  • 外部のDockerを停止し、名前空間内で dockerd とsocketを新たに作ろうとしても、すぐには解決しない
    • ip netns exec がmount namespaceを作成し、/sys を再マウントする
    • その結果、ホストの /sys/fs/cgroup が見えなくなる
  • この場合、次のエラーが発生することがある
Error: OCI runtime error: runc: runc create failed: no cgroup mount found in mountinfo
  • 回避策は、unshare で /sys をbind mountにし、ip netns exec が作った内部 /sys マウントを解除する方法である
    • この方法は Unix StackExchangeの投稿 をベースにしている
    • その後、mount namespace内の /sys はホスト /sys のbind mountになる
  • 例のコマンドは次のとおり
$ sudo systemctl stop docker && sudo systemctl stop docker.socket
$ sudo -E unshare -m sh -c 'mount --bind /sys /sys; exec ip netns exec vo_none_none sudo --user youruser --preserve-env bash'
$ sudo umount /sys
$ sudo dockerd --host=unix:///var/run/docker-netns.sock --data-root=/var/lib/docker-netns
$ DOCKER_OPTS="--dns=YOURDNSHERE" DOCKER_HOST=unix:///var/run/docker-netns.sock sudo --user youruser --preserve-env docker ...
  • dockerd とDockerコマンドを同じセッション内で実行すると、同じネットワーク名前空間とmount namespaceを共有する
  • DockerのDNS設定は /etc/netns/vo_none_none/docker/daemon.json に置くこともできる
  • この方法は、補助コンテナやDockerネットワークで接続するコンテナまで必要な作業には十分だったが、ブリッジなどが必要なより複雑なDocker構成では、そのままでは動作しない可能性がある

WireGuard MTU問題のデバッグ

  • 再起動後、WireGuard接続は生きているように見えたが、一部のページしか読み込めず、GitHubのようなサイトは開けなかった
  • ping、ping -6、wg show は正常で、原因特定は難しかった
  • サイズを変えたpingで確認した結果、大きなパケットが失敗していた
$ ping6 -s 1400 fd42:42:42::1
$ ping6 -s 1200 fd42:42:42::1
$ ping6 -s 800 fd42:42:42::1
  • 1400 サイズは失敗し、1200 と 800 は成功したため、MTU設定 が原因だと確認できた
  • ローカルWireGuardインターフェースのMTUを下げると、カーネルIPスタックはそれより大きいパケットを生成しなくなる
    • WireGuardのカプセル化オーバーヘッドが加わった最終UDPパケットも、経路上の小さいMTUリンクでドロップされにくくなる
  • 経路上の各ルーターは独自のMTUを持ち、最小MTUより大きいパケットはドロップされることがある
  • トンネルトラフィックはWireGuardのカプセル化により約 32バイトのオーバーヘッド が追加されるため、MTU問題がより起こりやすくなる
  • Path MTU Discoveryメッセージは途中のルーターからICMPで送られることがあるが、ファイアウォールがICMPをドロップすることが多く、自動調整が効かない場合がある
  • IPv6仕様の最小MTUは 1280 なので、IPv6上のWireGuardトンネルではこの値が常に動作するはずである

復旧後に残った運用上の選択肢

  • 構成結果には次が含まれる
    • IPv4とIPv6の両方を持つVPSにWireGuard VPNサーバーを構成
    • 直接IPv6トラフィックとNATされたIPv6トラフィックの両方をサポート
    • ネットワーク名前空間で業務VPNを実行
    • unshare 回避策でDockerを同じネットワーク名前空間内で実行
    • WireGuard MTU問題のデバッグ
  • リモートワークではインターネット接続の問題が常にリスク要因であり、今回のケースではLinuxツール群によってISPの設定復旧を待たずに回避できた
  • Hetzner VPSはWireGuardトンネルと合法的な一般利用をサポートしているが、ポートスキャン・トラフィックスプーフィング・暗号資産マイニングは許可されていない
  • AirVPN、ProtonVPN、AzireVPNのようにポートフォワーディングをサポートするVPNも、ホームサーバーのポートをISPに依存せずフォワードする代替策になりうる
  • OpenWRTルーターを使えば、ルーター側でより多くのデバッグができ、このような回避構成を各機器に個別設定せずルーターから直接WireGuardで処理することもできる

関連記事

1件のコメント

 
GN⁺ 2025-06-30
Hacker Newsの意見

  • タイトルは少し誤解を招く。正確には、VPS経由のIPv6トンネルでIPv4インターネットに接続するということで、通常は4in6とも呼ばれる
    それでも興味深いことではある。ISPから見ると、IPv4を壊したときとIPv6を壊したときでは、サポート問題の性質がかなり違う。IPv4の障害はたいてい明確な「ダウン」状態なので、ユーザーの不満は大きいが単純。一方、IPv6の障害は、部分的な障害、フォールバックによる起動の遅さ、ゲートウェイがIPv6があると信じている状況など、奇妙な形で現れる

    • 前回IPv4が死んだときは、GitHubが使えなくなって主に気づいた。最近はほとんどのコンシューマー向けWebサイトがIPv6だけでも動作する
      ただし、ルーターにIPv4のDNSサーバーしか設定していない人は完全な障害に見舞われた。Microsoftが役に立たない資産を少し片付けていたなら、いちばんの心配はルーターに付けたmDNSホスト名を思い出してログインし、IPv4が戻ったか確認する程度だったと思う
    • IPv4のロングテールは確かにあるが、自宅で最後にIPv4が切れたとき、妻はまったく気づかなかった。Google、Facebook、Apple/iCloud、そしてCloudFlareホスティングの大半がIPv6で動き続けていたからだ
    • 自分の経験とも同じ。IPv6の問題は分類して再現するのがうんざりするほど難しく、「自分のコンピューターでは動くのに」という状況が多い
    • ほとんどのISPはいまだにIPv6を完全に塞いでしまう。小規模な事業者がIPv6を一度試したあと、AAAAレコードの更新のようなことを忘れることが多く、ユーザーから見ると、お気に入りのニッチなサービスが別のネットワークでは動くのに、料金を払っているISPでは動かないように見えてしまう
      奇妙な問題で、IPv4がいつか消えることを願う以外に良い解決策があるのか分からない。Happy Eyeballsがこの問題を解決するはずだったが、問題はしばしばアプリケーション層のはるか上で現れ、アプリケーションは何でもできるため、漏れのない抽象化なしに一般的なプロトコルで解決するのは難しい。個人的には、ネットワークではIPv6を有効にし、すべてのブラウザーではIPv6 DNSを無効にするという形で妥協しているが、かなり不満がある

  • IPv6を試してみたいのにISPが提供していないなら、Hurricane Electricが何年も前からトンネルサービスを提供している
    https://tunnelbroker.net
    https://ipv6.he.net
    システムやルーターにtunデバイスを立ち上げ、トラフィックをルーティングするスクリプトもある: https://fedoraproject.org/wiki/IPv6_tunnel_via_Hurricane_Ele..., https://brandonrozek.com/blog/obtaining-ipv6-address-hurrica..., https://wiki.dd-wrt.com/wiki/index.php/IPv6_setup_Hurricane_..., https://forum.mikrotik.com/t/auto-update-script-for-hurrican..., https://docs.rockylinux.org/guides/network/hurricane_electri...

    • こうしたトンネルの厄介な注意点は、ストリーミングサービスが地域制限回避用のVPNのようにブロックするため、必要ならトンネルを切る方法を見つけておく必要があることだ
      それでもうまく動く。ルーターがHEトンネルをサポートしていなくても、RAの力でネットワーク内のすべてのデバイスにIPv6アドレスを付けられる。どのデバイスでも/64を広告すればIPv6ルーターになる。もちろん、ルーターがセキュリティ上RAをフィルタリングしていないことが前提だ。ポートフォワーディングのルールを触らずにホームネットワーク内でサービスをホストするときに非常に便利だ
    • Hurricane Electricは素晴らしいが、ISPが提供するIPv6を使う人が増えるにつれ、「一般」ユーザーはトンネルを離れ、ネットワークサービスはhe.netトンネルを悪用として扱うようになり始めた
      あまりに多くのサイトが壁を作ったり、そもそも動作を拒否したりするので、自分のネットワークの大半でIPv6の利用をやめざるを得なかった
    • 知っておくべき点は、HEトンネルは私の知る限り、ISPがグローバルIPv4を割り当ててくれる場合にだけ動作するということだ。キャリアグレードNATの背後にいるなら、残念ながら自宅にIPv6を入れるには別の解決策が必要になる
    • 満足している「顧客」だ。OpenBSDで無料の6in4トンネルを約5年間使ってきたが、特筆すべき問題はなかった
      /etc/hostname.gif0のようなOpenBSDのネットワークインターフェースファイルだけで設定している: tunnel, inet6 128 alias, !route -n add -inet6 default。この接続は、グローバルIPv4アドレスなしで意図的に構成したAWSのVPSクラスターに接続するために使っている。Jeff Bezosのような人たちがIPv4アドレス空間を積極的に収益化しているせいで、そうでなければ月額費用の大きな部分になっていただろう

  • 本当のIPv6専用環境で急いでIPv4接続が必要なら、公開DNS64+NAT64ゲートウェイを使える。リストは https://nat64.net/public-providers にある。
    通常の利用ではDNSサーバーを変えるだけでよい。DNS64はAAAAレコードがない宛先に対して、NAT64ボックスへ向かうAAAA DNSレコードを合成する: $ dig +short @2a00:1098:2c::1 AAAA github.com → 2a01:4f8:c2c:123f:64:5:141a:9cd7。NAT64はDNS64によって自分側に来たトラフィックをプロトコル変換し、NAT処理してくれる: $ curl --resolve github.com:443:[2a01:4f8:c2c:123f:64:5:141a:9cd7] [https://github.com/](<https://github.com/>;)

    • これを言いに来た。ヨーロッパでは少なくとも https://nat64.net/ 自体がかなり良い。良い経験しかない
    • Cloudflare WARPを使えばずっと速いはず。WARP経由でIPv4アドレスにも直接接続できる

  • あの神話上のIPv6専用インターネットユーザーが本当に存在するんだね :) 見事なネットワークエンジニアリングだ。
    以前、もっと一般的な逆の目的、つまりIPv4専用接続でIPv6関連の作業をするために似たものが必要だった。サーバーを完全に制御できるなら、より限定的だが速い解決策として ssh -D 1080 -N myserver を使ってSOCKS5プロキシを作り、ブラウザに設定した。システム全体にも設定できそうだが、それで元のssh接続が切れて全体が崩壊するのか気になる

  • 自分も同じ状況。2週間ずっと「チケットは開いていて、技術者がまもなく確認する」と言われるだけで、かなり苛立っている。
    IPv6が動いているので完全な障害とは見なされず、優先順位が低いのかもしれない。ドイツにはこういう場合に消費者への補償を保証する法律があるが、このケースも該当するのか近いうちに確認するつもり。このブログ記事の解決策には、複数のエンドポイントがデータセンターIPレンジを丸ごとブロックしたり、複数のCAPTCHAを要求したりする問題があり、一般的なVPNプロバイダーでも同じ。家全体のネットワークを直したかったのでルーター側で処理する必要があったが、Ubiquiti EdgeRouterのような非標準的な機器があったので、WireguardのルーティングとNATルール設定には都合がよかった。FritzBoxのような機器ではどうしたか分からない。欠点は、ルーター性能が多数の接続を処理するには不足しているため、ハードウェアオフロードに対応したIPSecへ切り替える必要があることだ

    • FritzBoxも実はVPN接続設定用GUIがかなりよくできている。FritzBox同士の接続を想定した機能だが、互換性のあるVPNなら使える。静的IPv4/IPv6ルートも設定できる。
      一番の問題は、相手側がどのIPsec暗号化構成を期待しているかを把握することになりそう。Wireguardのほうがずっと簡単かもしれないが、その場合はハードウェアアクセラレーションの問題が出る可能性がある。必要ならFritzBoxの設定ファイルをバックアップし、ダンプを編集してVPNエンドポイントを手動設定したうえで、チェックサムを再計算して取り込むこともできる。AVMにはユーザーがアクセスできない設定が多く、こうして調整可能だが、ルーターをうっかり文鎮化しないようアクセスを少し難しくしている
    • ドイツの事情は分からないが、オランダでは同じISPで固定回線とモバイルを一緒に使っていて固定回線に障害が起きた場合、障害が直るまで無料のモバイルデータを要求できる。
      ISPに聞いてみる価値のある選択肢かもしれない

  • AppleのApp Storeルールで気に入っている点の一つは、すべてのアプリがIPv6専用ネットワークで動作しなければならないという要件だ。何年も前からあるルールだ。
    開発者として初めて遭遇すると少し驚くが、ユーザーとしてはあってよかったと思う

    • アプリを使えばGithubにもIPv6でアクセスできるの？
    • ただし、それはサーバーがIPv6アドレスを持たなければならないという意味ではない

  • 同じ目に遭ったら、ssh -D 8080 user@hostname でsshプロキシをとても簡単に作れる。
    接続ができたら、ブラウザで localhost:8080 をSOCKSプロキシとして使うよう指定すればよい

    • 同じ助言をしようとしていた。一時的な問題にはずっと単純な解決策だし、プロキシが必要なときには恒久的なツールとしても使える。
      この機能を使うには sshd_config で AllowTcpForwarding が有効になっている必要がある
    • 公衆Wi-Fiを使うときはいつもこうしている。VPNにお金を払ったりVPNを信頼したりする必要なく、すべてを自分のinfomaniakサーバーへSOCKS転送している

  • IPv4を無効にするうえで行き詰まる点がある。代替検索エンジンの大半はIPv6接続を提供していないようで、Githubは最後に確認した時点でIPv6がまったくなかった
    Microsoftだから良いものを期待してはいけないし、むしろ最悪を想定すべき。最近はissuesでnoscript/basic (x)htmlまで壊した。noscript/basic (x)htmlブラウザとセルフホストのメール、mailbox@[ipv6:...] のようなIP(v6)リテラルで、今でもアカウントを作れるのかも分からない。Steamやゲームも最近確認していないが、多くのCDN/ゲームサーバー、またはかなりの部分がまだIPv4専用のように思える。メールサーバーも、多くがセルフホストのメールサーバーをブロックし、Spamhausのようなスイスやアンドラの怪しげな会社が作った粗雑で不適切なブロックリストを使っていることが多い。また、多くのネットワークアプリケーションはIPv6の利点を活用していない。たとえばWebのようなクライアント・サーバー型アプリケーションは、ISPが小さすぎるプレフィックスを割り当てない限り、セッションごとにランダム生成したIPv6アドレスを使うべきだ。モバイルIPv6 ISPはプレフィックス内で任意のIPv6/128アドレスを割り当てているようだが、端末アプリケーションが中央のオンライン名前解決なしに直接音声/ビデオ通話用の「固定」IPv6アドレスを選べるよう、安定したプレフィックス、おそらく96ビット程度を提供すべきだ。ユーザーアプリケーション間でIPv6アドレスを調整するための新しいユーザーレベルのOSサービスも必要になる。ただし、一部のベンダーや開発者がユーザーとアプリ開発者を囲い込むために押し付けてくるような、愚かな複雑さには注意が必要だ

    • 自分のミニホームラボではIPv6専用でうまく動いていたが、何かの理由でGitHubが必要になって破綻した。そこでNAT64+NAT64を立てた
      GitHub一つのためにそこまでしなければならなかったのは本当に残念だった。メールサーバーのためにいずれ必要にはなっただろうが、こんなに早くNAT64が必要になった理由としてはあまりにひどい。人々がGitHubをソフトウェア配布手段として使うことに伴う数々の欠点の一つだと思う
    • 数か月前にSpamhausと格闘しなければならなかった。どういうわけか自分のVPSのIPv6アドレスがSpamhausのブロックリストに載っていた
      なぜそうなったのかまったく分からない。そのマシンではメールを送れる機能は何も動かしておらず、私の知る限りDigital OceanはSMTPもブロックしているので、このマシンがメールを送ることは文字どおり不可能だった。Spamhausは解決にまったく役に立たず、DOも同じだった
    • 多くのCDN/ゲームサーバーがまだIPv4専用である問題のためにDNSプロキシを作った。そうしたドメインに正しいAAAAレコードを追加してくれる
      https://gitlab.com/miyurusankalpa/IPv6-dns-server
    • SteamにはIPv4が必要だと確認できる。プレイするのに認証が必要な一部のゲームも同様
    • VPSサービスのようにIPv6専用で運用すると割引が付く場合でもない限り、まだ誰もIPv4から離れることを本格的に検討していないように見える
      実際には、何らかの形でIPv4接続を持ち続ける可能性が高く、ただしその接続がCGNAT経由になる可能性はますます高まるだろう。Githubには特に腹が立つ。数週間テストして、すべてがうまく動作しているように見えたのに、またIPv4専用に戻してしまった。メールサーバーはどうせ10〜20年前の世界に生きている。メールサーバーでSSL 3.0やTLS 1.0のサポートを切ることすら、到達性の問題を覚悟しなければ難しい。Microsoft Outlookのサポートとスパムフィルターは、IPv6対応のメールサーバーを認識すらしていないように見える。ヘッダーを見ると内部的にはかなり前からIPv6を使ってきたようなのに、そうなのだ。IPv6がもっと活用されればよいのだが、一部の顧客で少しうまく動かないかもしれないという恐れが、この技術を実際に使おうとするあらゆる試みを凍り付かせているようだ。携帯キャリアで奇妙なIPの挙動を見る理由は、モバイルネットワークでIPが動作する仕組みによる可能性が高い。高速道路を走りながら通話したり高速列車に座っていたりすると、携帯電話は継続的にハンドオーバーし、IPアドレスには一定レベルの安定性が必要になる。国境を越えて外国のネットワークに切り替わっても、スタック全体は切れ目のない接続を維持しなければならない。セルラーネットワーク内部には特殊なルーティングシステムがあり、その一部はIPv6の機能をうまく活用しているが、携帯電話に「一般的な」静的グローバルユニキャストアドレスを提供するのを難しくしている。できるだけ一般的に見えるようにはしているが、有線の家庭用インターネットのような安定性を実現するのは簡単ではない

  • 職場では内部インフラへのアクセス用にIPv6専用VPNをいくつか運用している
    これまでで最大の問題は、WindowsとmacOSのクライアントがIPv6 DNSサーバーを必要とすることだ。そうでないと v6onlyhost.vpn.example.com を解決しようとすらしない。クライアントがIPv6対応ネットワーク上にいる場合もそうでない場合もあるため、VPN内でDNSサーバーを運用してクライアントに配布する必要があるが、VPN切断後にWireguardアプリが何らかの理由でDNSを元に戻せないと、さまざまな問題が起こりうる

    • ISPのIPv4専用ネットワークを使っていても、macOSはそのようなDNSサーバーなしでIPv6専用接続が可能だった
      詳細はもう覚えていないが、数年前に調べたところ、macOSはIPv6アドレスさえあればそのような形でもうまく動作した。ホストにULAアドレスを付ければよい。もちろん、ユーザーがその方法を知っていることが前提になる。VPNアプリケーションによっては、IPv6専用ネットワークに入るときにULAを追加するスクリプトを入れられるかもしれない。ただし、偽のULAを残し続けると、ユーザーがIPv6対応ネットワークへ移動したときに問題が起きる可能性がある
    • これはWindowsの問題ではない。自分もランダムなホットスポットで似た問題に遭遇したが、すべてではなかった。IPv6が無効になっているときにAAAAレコードを返さない間抜けなホットスポットのせいだと思う

  • これほど時間が経っているのに、自分の全マシンとホームラボを IPv6 に移行するために何日も頭を抱えるだけの説得力ある理由が、いまだに分からない
    何週間もかけてすべてをトラブルシュートし、ファイアウォールを再構成し、ネットワークアドレスを付け直すより、ポートフォワーディングとファイアウォールルールのほうが直感的だ。自分は何を見落としているのだろう？

    • 見落としているのは、思ったほど難しくないという点。よほど複雑なホームネットワークでなければ、IPv6 の設定は長くても一晩で済む
      自分のネットワークと ISP である Comcast の場合、ルーターで IPv6 を有効にすると ISP からプレフィックスを受け取り、それをローカルに広告し、外部からアクセス可能にしたい対象にファイアウォールルールを 1 つ追加すれば終わり
    • 見落としているものはない。企業環境では、IPv6 導入のメリットはデメリットを上回らない
      約 3500 台のデバイス、7 棟の建物、10 ギガ WAN 2 本と 4 ギガ WAN 1 本を管理し、約 26 個のグローバル IPv4 アドレスと NAT を使っている。今でも IPv6 を導入する強い理由はない。デュアルスタック構成は、目立った利点なしに不要なトラフィックと複雑さを増やすだけだ。今でも静的 IPv6 アドレスブロックの割り当てを受けるのは難しく、2 回申請したが却下された。伸びしろが少ないだけでなく、ブロックを受け取ること自体もまだ難しい。https://www.arin.net/resources/guide/ipv6/first_request/ の資格条件も、IPv4 割り当てを保有していること、すぐに IPv6 マルチホームを予定していること、1 年以内に 13 のエンドサイト、1 年以内に IPv6 アドレス 2,000 個の使用、1 年以内に /64 サブネット 200 個の使用、といったものだ
    • 今のところ大きく見落としているものはない。いつか Google や Cloudflare のような大企業が、ますます高くなる IPv4 アドレス費用にうんざりして、IPv6 にインセンティブを与えるかもしれない。たとえば IPv4 を制限し始める可能性がある
      すでに初期の動きはある。AWS は以前、使用していない IPv4 Elastic IP アドレスにだけ料金を課していたが、今では使用の有無に関係なく課金している。正直なところ、次にゲートウェイやルーターをアップグレードするときに準備しておく程度で十分で、今すぐ見落としているものはない。IPv4 と IPv6 を同時に使うこともできる。ルーターで有効にしても、IPv4 専用デバイスはそのまま問題なく動作する。1 つ注意すべき点は、IPv6 の自動検出は一時期かなりひどかったということだ。SLAAC、IPv6 自動アドレス設定、DHCPv6 がすべて存在し、もともとの自動アドレス設定は DNS サーバーを受け取ることすらサポートしていなかった。現在は SLAAC に整理されつつあるが、ISP はかなり長い間 DHCPv6 を使い続けるだろう