インターネット機器はいずれすべてIPv6経由で通信することになる。IPv6に統一できた後、IP層には技術的なトラブルや関心はあまり存在しないだろう。
課題は、IPv4とIPv6が併存するデュアルスタックを長期間サポートせざるを得ない点にある。
IPv4枯渇の公式宣言は2011年からスタートしている。モバイルインターネットは成長を続けており、新たに接続するデバイスはIPv6の比率が高まっていく。
IPv6を導入することの技術障壁は実はあまりない一方で、当面はIPv4をデフォルト設定としている機器が多く、意識して設定しないとIPv6に切り替わらない。
導入よりも移行の方がトラブルが多いため、可能なら最初からIPv6を選択したい。
アクセス網のIPv6切り替え
インターネットに接続する拠点のネットワークは、アクセス網のサービス商品選択で決まる。
日本の場合、家やオフィスと回線接続するNTTが、2011年頃から光ファイバーアクセス商品のネットワーク層をIPv6に切り替えており、該当サービスに加入した拠点がIPv6アクセスになる。
日本のブロードバンド回線は、2002年頃に
ADSLが急速に普及し、2005年頃から光ファイバーに切り替わってきた。初期から加入してきた回線では、おおむね3世代目の回線変更でIPv4からIPv6へ切り替わったのではないか。
アクセス網の典型的なトラブルは、IPv4 over IPv6トンネルの実装から来る。
IPv4とIPv6は併存していたとしても完全に独立したネットワークであるため、アクセス網がIPv6ネイティブになるとIPv4のサービスには接続できない。
IPv4 over IPv6サービスを追加することでIPv4ネットワークにアクセス可能になるが、いくつかの方式が並立しておりプロバイダ事業者ごとに採用方式が異なる。結局のところIPv4 over IPv6トンネルのうち契約している方式をサポートするルーターが必須と言える。
Wi-Fiアクセスポイントがインターネットルーター機能を備えているケースが多く、どうやら近年は消費者向けのWi-Fiルーターが幅広くIPv4 over IPv6トンネルをサポートしている。
固定回線よりもWi-Fi規格の方が更新ペースが速いため、無線インフラの技術をキャッチアップして機器をリプレースしていると、IPv6切り替えの問題には遭遇しにくいだろう。
一方、企業オフィスのネットワーク構築にはやや難がある。
ルーターがIPv4 over IPv6の一部方式をサポートしていない場合が多々あり、契約している方式と合わなければネット利用に支障が出る。プロバイダを契約する際、サービス説明にはIPv6切り替えの技術的トラブルには言及がないのだが、ルーターの機能で吸収できなければ他に実装手段がない。
IPv4 over IPv6機能は、各種ネットワーク機能の中ではかなり瑣末な機能であるため、本来は重要な選定要件には加えたくないところだ。
IPv4接続プロバイダの時代にはルーターは1台しか接続できなかったのだが、IPv6ではスイッチングハブ経由で複数のルーターを接続できることも多い。そこで今回の移行では、IPv4アクセスしないネットワークを企業向けのルータで併設する構成をとった。
アドレス設定は複数方式が併存する
IPv4時代にはIPアドレスの割当てはDHCPを用いてきた。おそらくIPv6では
DHCPv6とSLAACが併存する。
IPv6の規格はSLAACで、潤沢なアドレス空間を生かして各端末がアドレスを自ら決める。DHCPv6はルーターなどの管理機器が決めて配布する。
DHCPv6を採用したいプラットフォームは、WindowsやVoIP機器などだ。要するにLAN管理者が集中管理したい用途ではアドレスも集中的に生成して追跡したい事情がある。一方、端末が移動するモバイル機器は、単一のルーターで集中管理し切れないシーンがあるためSLAACが適している。
よって、IPv6ネットワークの管理方式は規格間の競争ではなく両方生き残るだろう。ネットワーク機器は両方式を同時にサポートできる必要がある。
ルーターを自作するのも一手
一般的な方法とは言えないものの、アクセス網に必要な機能をカバーしようと思ったら、ルーターを自作すべきかもしれないと考えている。
後述のとおり、kubernetesのIP網を整備するとルーターを作っているのとほとんど同じ工程をたどる。
また、法人ルーター機器の機能不足が目立っていることや、ARMの進歩によってハードだけはコモディティ化が進んでいることも既製品の相対的な陳腐化の要因と言える。
従来はネットワーク機器を買うことがセキュリティ確保に役立ってきたが、今は既製品のセキュリティ品質が相当疑わしいという問題も大きい。 日本のポピュラーな消費者ブランド機器はほぼソフトウェア脆弱性を抱え、またどの製品もバックドア機能を持つチップが搭載されている可能性は残る。
ネットワークの安全を確認するには、ハードがクリアであることと、ルーティングの定義セットの全容を理解した方が良い。
データセンターのIPv6切り替え
企業は、拠点だけでなくデータセンターを借りていることも多い。
上述のとおり、アクセス網をIPv6に切り替えるとIPv4サービスへのアクセスに難が出る場合がある。
IPv6切り替え時にトラブルが起きるとIPv6に技術面の問題があると受けとる人が多そうだが、じっさいにはIPv6ピア間の通信には問題はなく、IPv4サービスとの互換機能にネックがある。
データセンターでシステムを運用している企業の場合、アクセス網がIPv6なのであれば、データセンターのサービスもIPv6に切り替えるべきだ。
IPv4互換性確保には何らかのプロキシ・ソフトウェアを利用するのが手軽だろう。
プロキシは接続先がIPv4/IPv6いずれでも問題なく動作するように作られているため、内部通信をIPv6のみに置き換えることがターゲットになる。
ただし一手で変更することはできず、多くの場合、個別のサービスを１つずつIPv6に移行することになるだろう。サービスの数が増えるほど手間もかさむ。
IPv6への移行着手の前提として、IPv4/IPv6デュアルスタックをサポートする高機能なネットワークを調達できると作業しやすい。ネットワークがシングルスタックの場合には、必然的に別のインフラに移行する方式となり、切り替え範囲が広くなる。
IPv6の挙動は個別のアプリケーションにより異なるため一概には言えない。じっさいにIPv6ネットワークへのルートが存在するだけでIPv4アクセスを排除する挙動のCLIがあり、作業ペースを想定どおりに進められない可能性を感じている。
中にはIPv6では動作しないソフトウェアもあり得る。
IPv4は今後時間をかけてコストが増えていく可能性があり、また
NAT設定が事実上ロストテクノロジーになることも考えられるため、IPv6互換性のないソフトウェアを特定しておくことは継続性に関わる。
仮想ネットワーク構築には知見が必要
開発ツールにも仮想ネットワークがある場合、既存の構成はIPv4シングルスタックというケースが多い。
仮想ネットワークを用いたクラスタのデファクトはkubernetesであり、kubernetesにはすでにIPv4/IPv6デュアルスタックの実績がある。
おそらく機能面では実用上問題のないレベルと言えるが、導入するにはクラスタの再作成が必要になる。
2024年現在では、どうやらIPv6ネットワークを選択するエンジニアの割合が少ないため、最初から動作するパッケージに仕上がっておらず、適切な構成を試行錯誤する展開になりやすい。
異なる3台のハード上で同一構成のk3sを実行しているが、そのうちの1台だけIPv6の通信エラーが起きている。コンテナ間通信と外部へのリクエストのいずれもエラーになることから、おそらくCPUとホストkernelの特定の組み合わせで生じるバグなのだろう。
仮想ネットワークはOS単体のネットワーク構成よりもはるかに複雑であり、またLinuxのネットワーク実装が従来のiptablesを捨てつつある過渡期ということもあって、初回のセットアップには手間をかける必要があるだろう。
ここ10年のうちに書籍出版がすっかり衰退してしまったため体系的な情報源へのアクセスにも難がある。総合的な知見の乏しさが仇となり、IPv6ネットワーク構築のトラブルシューティングは難易度が高い。
IPv4は過去のものになった
ソフトウェアエンジニアであってもIPネットワークに関心を持つ割合は相当少ないだろう。多くのソフトウェアがより上位のプロトコルをターゲットにしているからだ。
しかし、意識することなく低レイヤでIPv4を採用しているシステムは多いはずで、10年以上使い続けるつもりならいずれIPv6に移行せざるを得ない。
日常的に操作していないプロトコルの移行は手軽とは言えないので、今から着手するプロジェクトをIPv6上に構築することは将来の手間の節約につながるだろう。
すでに構築してしまったサービスについては、IPv6移行は暗に予期されていたイベントであり、一度は対応することになるはずだ。
