要約

  • draft-ietf-snac-simple-12 はIPv6スタブネットワークを隣接インフラへ自動接続するが、アドレス性、到達性、発見可能性を別の機能として扱う。
  • 再起動や引き継ぎでは、新しいプレフィックスが現れた後も古いアドレスと経路が有効であり得る。新しいRAはアプリ継続の証明ではない。
  • 運用には、状態変化、寿命、実際に入った経路、発見結果、選択アドレス付きのトランザクションを保存する小さな継続レシートが要る。

正しい交代にも空白がある

SNACルーターは、IoTのような制約ネットワークをWi-FiやEthernetの隣接リンクへ接続する。異なるメディアを無理にブリッジせず、IPv6のアドレス、経路、DNS系の発見機能を組み合わせる。

第12版が示す目標は一枚岩ではない。スタブ側ホストが外で使えるアドレスを持つこと、インフラ側から戻る経路があること、サービスを発見できることは別々だ。利用者がボタンを押して機器が応答することは、さらに先の結果である。

STATE-SUITABLE は送信元の行動を監視する

隣接インフラリンクに接続すると、ルーターは RFC 4861 の探索を行う。適切なon-linkプレフィックスがあれば STATE-SUITABLE、なければ STATE-BEGIN-ADVERTISING に進む。

適切さには二つの時間軸がある。Router Advertisementは受信時刻から十分快、既定の STALE_RA_TIME を超えると根拠にできない。広告元ルーターの近隣到達性も別に確認し、既定で六十秒を超えたら能動的な確認が必要になる。

生きている隣接ルーターがRAだけを止める場合と、新しいRAを残してルーターが落ちる場合は異なる。プレフィックスの構文と正の寿命だけでは、提供主体が機能を続けていると判断できない。

非推奨化は重複を設計に取り込む

SNACが自分でプレフィックスを提供するとき、優先寿命と有効寿命は既定で三十分である。より望ましいプレフィックスを見つけると STATE-DEPRECATING に移り、旧プレフィックスの優先寿命をゼロにし、有効寿命を減らしていく。代替が途中で消えれば元の広告に戻れる。

この可逆性は堅牢性のために必要だが、ホストの記憶は同期されない。受信時刻も、失ったマルチキャストも、既存セッションも異なる。状態機械が整然と遷移しても、各アプリがどの送信元アドレスを使うかは分からない。

RFC 8978 は、新プレフィックスが現れて旧状態が確実に撤回されないフラッシュ・リナンバリングを扱う。同RFCの七日・三十日という一般SLAAC値と、SNAC自前プレフィックスの三十分は別物である。共通するのは、有効時間が通信可能時間を保証しない点だ。

戻ったルーターは過去の所有者ではない

二台のSNACルーターを考える。Aがon-linkプレフィックスを提供していたが停止し、Bが別のプレフィックスを提供した。Aが戻るとBの適切な広告を見て、自分の古いプレフィックスを再広告しない。

しかしホストにはA由来のアドレスが残る。Aはその宛先のパケットを受けても、もうon-linkだと考えず、デフォルトルーターへ回すか破棄し得る。草案はIoT制御が一時的に失われ、自動処理が失敗し得ると明記する。

再起動そのものが必ず番号変更を起こすわけではない。自己生成OSNRは再起動をまたいで保持すべきで、DHCPv6-PDでも同じプレフィックスが戻ることが多い。調査対象は、永続化失敗、長い不在、接続の反復、短いリース、メッシュ分断と再結合である。

ThreadのようにExtended PAN IDから同じ/64を導く方法は有効だ。それでも同じスタブを支える全ルーターが同時再起動しないという条件が残る。連続性は共有状態を保持する実装に依存する。

OSNRの引き継ぎは別の台帳を持つ

OSNRプレフィックスは RFC 9915 のDHCPv6-PDか、RFC 4193 のULAから得られる。唯一の広告者が不在でも、別のルーターは旧プレフィックスへの経路を保てる。ただし、同じOSNRを協調して維持する方法は仕様範囲外である。

期限が迫れば別ルーターが新OSNRを広告し、旧OSNRを記憶するルーターは失効までRIOを出す。既存通信を守るための重複であり、新規通信の正しい選択を証明する重複ではない。

発見成功は到達成功と両立しないことがある

RA GuardがSNACのRAを遮断してもmDNSが見える場合、サービス一覧は戻るが、インフラホストには RFC 4191 のRIOが入らずOSNR経路がない。NAT64による一方向の成功が残る場合もある。

ルーターの送信ログ、代表ホストの経路表、実アプリの結果を比較しなければならない。RFC 6762 と RFC 6763 は発見を説明するが、経路を証明しない。

遷移を後から再生できる形にする

草案は、番号変更、非推奨化、失効、提供ルーターの変更、デフォルト経路の消失と復帰を時刻付きで残すよう勧める。継続レシートにはさらに、ルーターと起動ID、プレフィックスの役割、前後状態、RA出所と鮮度、近隣確認、寿命、非推奨開始、RIO、ホスト経路、発見、実際の選択アドレスを含むアプリ結果を入れるべきだ。

共通化するのは形だけでよい。保存期間や修復権限はローカルに残す。Lu HengのMinimum Initial Specificationは比較可能性を作るためで、中央制御を増やすためではない。Reality Layersの観点でも、メッセージ、状態、経路、結果は隣接して保存し、同一視してはならない。

rev12のImplementation Statusは、OpenThread系実装とシミュレーションによる複数ルーター試験を報告している。これは有力な運用経験だが、すべての製品が同じ遷移を行う証明ではない。Running Code Primaryを満たす次の段階は、独立した二実装が同じ障害系列を処理し、同じ最終色ではなく同じ原因付き遷移を説明できることである。

時刻そのものにも境界がある。草案はNTPが使える場合は同期時刻を、使えない場合は相対的な稼働時間を記録するよう勧める。レシートは両者を混同せず、時計品質を一緒に持つべきだ。そうすれば、二台のログの順序が本当に比較できるのか、単に別々の起動時間を並べただけなのかを後から判断できる。

順序を証明できない記録は、障害原因の順序まで証明したことにはならない。

時刻の不確実性も証拠の一部として残す必要がある。

情報源

  1. SNAC第12版
  2. 改訂履歴
  3. 第12版HTML
  4. 第12版テキスト
  5. 第11版から第12版の差分
  6. RFC 4861
  7. RFC 4191
  8. RFC 4193
  9. RFC 8978
  10. RFC 6762
  11. RFC 6763
  12. RFC 7084
  13. RFC 6146
  14. RFC 7050
  15. RFC 9915
  16. Lu Heng — Minimum Initial Specification
  17. Lu Heng — On Reality Layers
  18. Lu Heng — Running Code Primary