Summary

  • NANOG の無線案内は、2015～2019年の保護された主回線とオープンな互換回線から、2022年以降の主回線、Legacy、IPv6-only という3系統へ変化した。2023年6月には802.1X から WPA3 共有鍵への切り替えと OWE の試行も公表された。
  • NANOG 89から97まで、3つの選択肢は繰り返し案内され、接続、無線、エッジルーティングの提供者や問い合わせ先も示された。一方で、構成、経路冗長性、接続成功率、稼働時間、障害、問い合わせ処理、撤収後の扱いは同じ粒度で公開されていない。
  • IPv6-only SSID は実機を使う試験面として意味がある。ただし、案内だけでは NAT64、DNS64、464XLAT の有無、IPv4-only 宛ての到達性、アプリケーションの成功率は分からない。
  • 必要なのは設定や生ログの全面公開ではない。会議後に、サービス時間、役割分担、SSID 別の集計値、重大障害、IPv6 到達モデル、テレメトリ保持、撤収確認を1ページで残すことである。

永久ページだけでは、当日のネットワークを復元できない

まず、資料の残り方そのものに問題がある。NANOG 93の Meeting Statsは、現地参加者702人という数字と、WPA3 の主 SSID、問い合わせ先を掲載している。ところが、当時の参加者向け Welcome メッセージには、主 SSID に加えてオープンな Legacy と IPv6-only も明記されている。

統計ページが誤っているとは限らない。恒久ページは要点だけを見せ、当日の運用案内はメーリングリストに置く設計だったのかもしれない。だが、後から恒久ページだけを見れば「公開された SSID は1つだった」と誤読できる。逆に、702人という参加者数を無線利用率の分母にすることもできない。人と端末は同じではなく、1人が複数端末を持つことも、端末がアドレスをランダム化することもある。SSID 別の接続数は掲載されていない。

このずれは、会議ネットワークを評価するときの出発点になる。NANOG は接続方法をかなり丁寧に公開してきたが、公開記録は複数の面に分散している。Welcome メールは「何を提供すると案内したか」を残す。統計ページは参加規模を残す。問い合わせ先は問題の入口を残す。しかし、どれも「実際に何が起きたか」をまとめた運用記録ではない。

恒久ページから当日の案内へ安定したリンクを張り、会議後に短い結果報告を追加する。それだけで、計画、提供、結果の3段階を混同しにくくなる。

3つの選択肢は、突然生まれたのではない

2015年1月の NANOG 63案内は、会議の無線情報を簡素化し標準化するため、保護された5 GHz、保護された2.4 GHz、オープンな Legacy を分けて示した。この時点での主題は、周波数帯と古い端末の共存だった。より適した端末を優先ネットワークへ誘導しながら、互換性の低い機器にも入口を残す設計である。

2017年2月の NANOG 69では、802.1X で保護された主 SSID と、暗号化しない Legacy の2本になった。案内は会議ネットワークを、高可用性と業界のベストプラクティスを示すためのものと説明している。2019年2月の案内にも同じ大枠が残る。

ここで言葉の強さを調整しなければならない。「高可用性を志向する」ことと、高可用性が測定されたことは違う。案内には目標値、冗長切替試験、稼働率、障害時間、端末別の成功率が付いていない。したがって、この文言は NANOG が何を目指したかの証拠にはなるが、達成の証拠にはならない。

2022年10月の NANOG 86になると、保護された主 SSID と Legacy に IPv6-only が加わる。2023年2月の NANOG 87でも、802.1X の主回線、Legacy、IPv6-only の3つが案内され、技術相談用のメールアドレスが示された。

大きな切り替えは2023年6月の NANOG 88である。主 SSID は802.1X をやめ、WPA3 の事前共有鍵へ移行したと説明された。2.4、5、6 GHz を対象とし、Legacy と IPv6-only も維持した。さらに、対応端末を暗号化する OWE の SSID も案内された。

OWE は、後の案内で定番の4本目にはなっていない。だからこそ重要だ。会議ネットワークは固定された規則ではなく、試行し、戻し、整理される運用面である。ある1回の構成を「NANOG の永久方針」として後年へ投影してはいけない。NANOG 89以降に繰り返される3本構成こそ、公開記録から確認できる継続的な選択である。

変わる提供者、変わらない接続メニュー

NANOG 89の案内は、Internet Connectivity を AT&T、Wireless を Cisco Meraki、Edge Routing を Juniper Networks として分けている。主 SSID は公開共有鍵による WPA3、Legacy は2.4/5 GHz のオープンかつ暗号化なし、IPv6-only は IPv4 ゲートウェイも DHCP サーバーもないオープンネットワークである。

NANOG 90では接続提供者が Charter Communications に変わり、Cisco Meraki と Juniper は無線とエッジの表記に残る。NANOG 91では接続が Washtenaw Fiber に変わる。NANOG 94の案内は参加者アーカイブにあり、AT&T と HPE Juniper Networks を記載する。

NANOG 95と ARIN の共同会期では、SSID 名がNANOG-ARINになった。これは共同の利用面に両組織名が出たことを示すが、ARIN がネットワーク全体を設計、所有、運用したことを示さない。NANOG 97の案内では、接続が Ziply Fiber、エッジルーティングが HPE となり、SSID 名は再び NANOG に戻る。会期中の6月の通知も同じ3つを繰り返した。

この並びから言えるのは、接続メニューのほうが提供者の組み合わせより安定しているということだ。また、NANOG が少なくとも公開表記では、接続、無線、エッジルーティングを別の役割として扱っていることも分かる。

しかし、役割名は責任分界点ではない。Connectivity という表記だけでは、物理的に独立した複数経路、フェイルオーバー、帯域保証、ホテル側の引き渡し条件は分からない。Edge Routing から、誰が設定を保持し、誰が監視し、誰が切替を承認したかは分からない。Wireless から、無線コントローラの設定者、スペクトラム調整者、障害対応者は分からない。

名前の掲載は貢献を認識するうえで有用である。ただし、貢献を全体運用や法的責任へ拡張してはならない。公開されているのは役割の見出しであって、契約や RACI 表ではない。

WPA3 の共有鍵を「個人認証」と呼ばない

会議で公開共有鍵を採用する理由は理解しやすい。多数の参加者を短時間で接続させる必要があり、パスワードは案内に掲載され、転送も保存もされる。摩擦を下げる設計である。

ここから確実に言えるのは、主 SSID が WPA3 と事前共有鍵を使うと案内されたことだけだ。参加者ごとの固有資格情報、個人単位の帰属、すべての通信に対する安全性は証明されない。別資料がなければ、詳細な WPA3 モード、クライアント分離、管理フレーム保護なども推測できない。

Legacy は「open, unencrypted」と明記されている。これも正確に読む必要がある。リンク層で暗号化されないことは分かるが、すべてのアプリケーション通信が平文だとは限らない。逆に、上位層の暗号化があるからどんな利用でも安全だとも言えない。案内は端末、アプリケーション、脅威を網羅していない。

Legacy を残すことには互換性上の合理性がある。古い機器、認証に失敗する端末、検証対象の装置が存在するかもしれない。障害切り分けのために、認証なしの接続が役立つ場合もある。一方で、その必要性を評価する数字は公開されていない。Legacy へ何台が接続し、なぜ選び、主 SSID へ戻ったかは分からない。

したがって、Legacy は「古い端末が大量に必要としている証拠」ではない。NANOG が互換性の逃げ道を用意したという公開上の約束である。その約束を将来も維持するかどうかは、利用数と失敗理由を集計して初めて判断できる。

IPv6-only が試すもの

IPv6-only は、NANOG らしい選択に見える。ネットワーク運用者の会議で、実際の端末を IPv4 のない接続面へ置けば、講演だけでは見つからない依存関係が現れる。IPv4 アドレスを直接参照するアプリケーションや、特定の名前解決に依存するソフトウェアは、デュアルスタックでは隠れていた不具合を見せるかもしれない。

それでも、SSID 名から成果を読み込むことはできない。詳細な案内が示すのは、IPv4 ゲートウェイと DHCP がないことだ。NAT64、DNS64、464XLAT、RFC 8925の IPv6-Only Preferred があるとは書いていない。リゾルバ、プレフィックス、変換容量、到達可能な宛先、アプリケーション試験も説明されない。

RFC 8925は、対応するホストが IPv4 アドレス取得を省略できる仕組みと、その際のネットワーク条件を扱う。RFC 8683は、NAT64、DNS64、464XLAT を運用者・企業ネットワークで使う際の選択を扱う。これらは NANOG の実装証拠ではない。むしろ、IPv6-only という一語だけでは到達性を定義できないことを示す比較基準である。

このため、IPv6-only SSID の存在は、利用者が選べる実運用上の試験面を NANOG が提供した証拠にはなる。IPv6 導入率、アプリケーション互換率、教育効果、参加者の勤務先での展開を示す証拠にはならない。

NANOG 93 IPv6 Clinicは、発表、ハンズオン、ホワイトボードを含む別の教育活動だった。Clinic が存在したことと、会議 SSID が動いたことは別の事実である。講習への参加は Wi-Fi の稼働を証明せず、Wi-Fi の成功は講習後の導入を証明しない。

公開すべきなのは、個別利用者ではなく設計と集計である。IPv6-only がネイティブ IPv6 だけを意図したのか、IPv4-only 宛てへの変換を意図したのか。SSID 別に定義された接続数はいくつか。主要な失敗分類は何か。予定時間内にサービスは提供されたか。この程度なら、実験面の意味を示しながら個人を追跡しない。

問い合わせ先は障害報告書ではない

複数の案内は[email protected]を示し、NANOG 97はサポート窓口へ誘導した。参加者から見れば、問題を持ち込む先が公開されていることは重要である。責任の入口がないネットワークより明確だ。

ただし、メールアドレスからは受付時間、初動目標、件数、重要度、根本原因、解決時間、終了確認が分からない。問題が届いたこと、同種の障害が集約されたこと、ネットワーク側で修正されたことも確認できない。

これは窓口の欠陥ではない。窓口と公開記録の役割が違うだけだ。窓口は当事者の問題を解決する。会後記録は、個人の内容を除いたうえで、どの種類の問題がどれだけあり、どこで制御でき、何を直したかを残す。

空欄をゼロと扱わないことも重要である。障害報告が公開されていないから障害がなかったとは言えない。テレメトリの説明がないから収集がなかったとも、逆に大量監視があったとも言えない。公開資料から確認できないことは「不明」のままにする。

1ページの会後記録

過度な透明性を避けながら結果を残すには、次の項目で足りる。

サービス時間――3つの SSID について予定開始・終了と、提供状態を示す。限定された監視しかない場合、全体稼働率のような数字を作らない。

役割分担――Internet 接続、無線、エッジルーティング、会場引き渡し、NANOG サポートの担当を示す。共同責任なら共同と書き、スポンサー名を全体運用者にしない。

SSID 別の集計――接続、リース、セッションなど、採用した単位を定義して集計する。MAC アドレスを人や参加者と呼ばず、ランダム化や再試行の影響を注記する。

IPv6 到達モデル――ネイティブ IPv6 のみか、IPv4-only 宛ての変換機構を用意したかを示す。設計の存在と全アプリケーションの成功を分ける。

重大障害――公開基準を超えた事象について、時間帯、影響面、症状、是正を簡潔に残す。個別端末の詳細は不要である。

サポート集計――ネットワーク関連の問い合わせ件数、主要分類、初動・解決時間を帯域値や中央値で示す。測っていなければ、測っていないと書く。

テレメトリと保持――関連付け、DHCP、DNS、フロー、セキュリティログの有無をカテゴリで示し、目的、アクセスできる役割、削除・匿名化時期を説明する。生データは公開しない。

撤収――一時資格情報、設定、提供者アクセス、保持ログが定めた手順で処理されたことを、責任役割とともに確認する。

この記録には、パケットキャプチャ、端末識別子、個人の閲覧・DNS 履歴、パスワード、非公開契約、攻撃に使える詳細構成を含めない。運用説明を増やすことと、監視データを増やすことは同じではない。

「そこまで公開する必要はない」という反論

最も強い反論は、会議ネットワークの規模と寿命である。NANOG は、異なるホテル、電波環境、接続業者、管理されていない多数の端末を相手に、数日間だけ使うネットワークを構築する。現場の優先順位は接続と復旧であり、毎回の出版物ではない。3つの SSID とサポート窓口を示すだけでも、一般的な会議 Wi-Fi より説明は豊富だ。

また、詳細構成や防御位置を公開すれば攻撃を助ける恐れがある。少人数の会議で細かい利用統計を出せば、個人を推測できることもある。全アラート、全チケット、全設定を求めれば、担当者の負担が増え、率直な障害記録を妨げる。

この反論は正しい。内部の制御面を公開しないことと、無責任であることは同じではない。だから提案は全面公開ではなく、NANOG 自身が参加者へ示した約束と同じ抽象度で結果を示すものに限る。

2007年の Steering Committee 議事録には、NANOG 40で予定された10G の「demonstrator」経路に問題が起きた場合、代替の Internet 経路があるかという懸念が記録されている。無線の契約担当や、XKL が会議ネットワークと接続を説明する展示を行う予定も書かれている。これは当時、冗長性、役割、デモとしての価値が議論された証拠である。現在の会議で冗長性が実装・試験された証拠ではない。

この区別こそ、短い会後記録が守るべき原則だ。計画は実績ではない。提供者名は制御権ではない。複数企業名は物理経路の独立性ではない。デモは成果ではない。

3つの責任を、3つの評価に変えない

主 SSID には、共有鍵による保護を正確に説明し、個人認証や万能の安全性へ拡張しない責任がある。Legacy には、リンク層暗号化がないことを明示し、その互換経路が今も必要かを集計で確かめる責任がある。IPv6-only には、「only」が到達性に何を意味するかを示し、利用者を公開データ化せず成功と失敗を集計する責任がある。

そして3つすべてに、役割を混同しない責任がある。AT&T、Charter Communications、Washtenaw Fiber、Ziply Fiber は異なる会議で接続提供者として現れ、Cisco Meraki、Juniper、HPE は無線またはエッジの役割で現れる。これらの表記は貢献を見えるようにするが、責任の全体像ではない。

公開記録から肯定できることは明確だ。NANOG は、保護された既定経路、オープンな互換経路、IPv6-only の試験経路を継続して利用者へ示してきた。単一のホテル SSID より選択の意味が分かり、プロトコル上の妥協を隠していない。

一方、公開資料だけでは、その約束がどの程度機能したかを判定できない。接続成功、稼働、障害、サポート、撤収の定例値がなく、IPv6-only から IPv4-only 宛てへどう到達する設計だったかも不明である。これは弱い運用の証明ではなく、公開証拠の上限である。

NANOG はネットワークそのものを公開する必要はない。利用者に選ばせた接続条件と同じ粒度で、その結果を公開すればよい。3つの SSID はすでに3つの責任を示している。残るのは、その責任が会場でどう試されたかを、短く、安全に、再確認できる形で残すことである。

Sources