要約

  • RFC 4957 はリンク層通知をネットワーク接続検出の入力と位置づけ、IP やサービスの完了結果とは扱わない。
  • 接続点の変更は同一サブネット内でも起こり、IP 設定の変更は新しいリンクイベントなしでも起こり得る。

「link up」は結論のように響く。無線の関連付けが終わり、Wi-Fi 端末がアクセスポイントに接続し、あるいは Ethernet がフレームを送れるようになった。しかし障害ダッシュボードでそれを「サービス復旧」と言い換えると、観測した事実を越えてしまう。RFC 4957 の役割は、その飛躍を止めることにある。

Suresh Krishnan らが編集したこの Informational RFC は、端末が接続点を変えた際にアクセス技術が IP 層へ渡せる情報を整理する。その情報は適切な設定を速く調べるためのものだ。利用可能なアドレス、動作するデフォルトゲートウェイ、利用可能なアプリケーションを証明するものではない。

新しいリンク層接続は、たとえばルータ要請を送って追加の手掛かりを探す契機になり得る。RFC は、リンク層通知だけではネットワーク接続検出に必要な入力をすべて満たさないと述べる。広告されたプレフィックス、デフォルトゲートウェイの到達性、その他の IP 証拠がなお必要である。これは状態機械を始動する信号であり、終状態ではない。

Wi-Fi ローミングは分かりやすい例だ。端末は一つのアクセスポイントから別のものへ移っても、同じ IP サブネットに留まれる。すべての関連付けを IP 再設定と解釈すれば、不要な処理と誤った計測が生じる。逆もある。IPv6 のリナンバリングは、新しいリンクアップ通知なしに IP 層の変更を必要とし得る。

RFC は、インターフェースは準備できているがネットワーク内でデータがまだ遮断され得る場合の、非決定的なリンクアップも認める。その後に決定的な通知が来ても、それが表すのは実装が定義したリンク層状態である。SLAAC や DHCP の完了、ポリシーによる許可、DNS 解決、遠隔サービスの応答、利用者が結果を見た事実は証明しない。

運用者にとってこれは証拠設計の問題である。link_up はインターフェース、接続点、時刻、技術的文脈を持つ有用なローカル観測になり得る。だが online と改称したり、アプリケーション復旧として数えたり、単独でチケットを閉じたりしてはならない。そうした名称は信号が観測していない事実を主張する。

必要なのは証拠の階段である。リンクイベント、アドレスとプレフィックスの状態、ゲートウェイ探査、リゾルバ結果、認証済みサービス応答、利用者に見える確認。各段階には別の観測者、障害領域、説明責任がある。分散した当事者の一方が、他方の結果を根拠なく代弁してはならない。

RFC 4957 の教訓は限定的だからこそ有用だ。リンクイベントはリンクイベントについての証拠である。価値は次の検査を起動することにあり、経路、サービス、顧客体験の受領証として扱われるときに境界を越える。

出典