要約

  • RIPE NCCの報告では、端末の86％がNAT64を使うIPv6専用の会議ネットワークに対応していた。
  • 主会場では無線AP三台の電波を止めて六台を追加した後も、小さな問題が残った。

三台の無線APで電波を止め、六台を追加する。RIPE 93の閉会報告に並んだこの現場対応は、同じ報告の「端末の86％がIPv6専用に対応」という数字の裏側にある。対応率は端末の能力を示し、無線の切り替えは運用の手間を示している。

会場ネットワークはソフィアの五つのフロアを結んだ。RIPE NCCの技術チームによると、館内の配線は正常だった。IPv6専用の端末にはIPv6アドレスだけを割り当て、IPv4宛ての通信にはNAT64を使った。86％という説明は、参加者の端末の多くがこの方式に対応していたことを示す。

問題はNAT64より手前の無線区間にあった。技術報告によると、一部のAPがIPv6 Neighbor Discoveryのsolicited-node multicastを引き続き落としていた。RFC 4861では、宛先のリンク層アドレスが分からないノードが、対象のsolicited-node multicastアドレスへNeighbor Solicitationを送って応答を待つ。このやり取りが終わると、端末の通信はNAT64へ進みIPv4向けに変換される。

チームは最近のRIPE会合でも同じ、または似た問題を見ていたという。機器の販売元は修正済みと説明したものの、アムステルダムのオフィスでも同世代のAPに症状が出た。チームはファイアウォール上でNDP fixerを動かし、落ちるマルチキャストへの対処に役立ったとMenno Schepersは説明した。主会場ではAP三台の電波を止め、別の六台を有効にした。隣の会議室とコーヒーエリアでは同じ問題は見られなかった。それでも報告には、小さな問題が残ったとある。

これは具体的な運用記録であり、サービス品質には結果の記録が要る。「86％が対応」は端末の能力を表す。Schepersは主会場のWi-Fiが「少なくとも大半の時間」適切に動いたと説明した。記録に端末数、部屋別の接続結果、NAT64の系列データはなく、これらがあれば86％の対応率が安定したサービスを示すか、図の方向が整合するか判断できる。

問答ではNAT64グラフにも疑問が出た。参加者は、入出力の線なら対称すぎるように見えると指摘した。Schepersは「少し違う」と答え、確認すると約束し、議長もチームが調べると述べた。記録にはこの質問と確認の約束が残っている。

RFC 6146のNAT64は、IPv6クライアントからIPv4サーバーへ通信する仕組みだ。無線APでの近隣探索とは経路上の別の処理である。ゲートウェイのグラフは変換済みトラフィックを示し、部屋別の接続結果は端末が最初の近隣探索を通過したかを示す。方向を明示した二本の線なら、読者はその比較を確かめられる。

チームは電波を切り替え、APを足し、暫定策を設け、利用者に不具合報告を呼びかけた。閉会レポートが示す課題は、互換性の割合だけが成果として残りやすいことにある。IPv6専用の試験を通した会場でも、ある部屋の接続には技術者の介入が必要だった。

一次資料：RIPE 93閉会プレナリーの記録 · RIPE 93技術報告セッション · RFC 4861 · RFC 6146。