要約

  • IPv6 の SLAAC は、アドレスを preferred、deprecated、invalid と段階的に扱う。Preferred Lifetime の終了は新規通信で避ける合図であり、Valid Lifetime の終了だけが割り当てを消す。
  • 二つの時刻の間では、新しいアドレスが次の接続を引き受け、古いアドレスが途中で端点を変えられない既存接続を支えられる。
  • 偽の Router Advertisement による即時無効化を防ぐ二時間ルールは安全策である。しかし再起動したルーターが旧prefixを忘れれば、正当な撤回も遅くなる。

消滅より先に選択が終わる

1996年の RFC 1971 は、IPv6アドレスの寿命をすでに二段階に分けていた。preferred の間は上位層が通常どおり使える。Preferred Lifetime が尽きると deprecated になり、利用は控えるべきだが禁止はされない。Valid Lifetime が尽きた時点で初めて invalid となり、送信元にも受信先にも使えなくなる。

この中間状態には上位層の事情がある。TCP接続は、開いた後に端点アドレスを交換する一般的な仕組みを持たない。新prefixが届いた瞬間に旧アドレスを消せば、まだ正常に進んでいた接続まで切れる。deprecated アドレスは新しい仕事から退きながら、すでに始めた仕事を終えるために valid のまま残る。

したがって deprecated は到達不能の別名ではない。宛先として届くpacketは受け取り、必要なら既存通信のsourceとしても使う。状態の違いは、「次に選ぶべきか」と「まだ自分のアドレスか」という二つの問いに対応する。

Prefix Information Option に二つの時計が入った

RFC 4861 の Router Advertisement は、Prefix Information Option に Preferred Lifetime と Valid Lifetime を持つ。どちらも32bitの秒数で、全bitが1なら無限を表す。preferred は valid を超えてはならない。RFC 4862 は、この順序が逆のoptionを無視するよう求める。

時間だけでSLAACが成立するわけではない。Autonomous flagが、そのprefixからアドレスを自動生成してよいことを示す。prefix、flag、二つの寿命は一つの権限記述であり、秒数だけを切り出しても作成権限にはならない。

RAは周期的に届き、hostは寿命を更新する。同じ固定値が繰り返されれば、受信のたびに期限は先へ延びる。減少する値なら、特定の終了時刻へ近づけられる。一回のRAに旧prefixがないことは撤回ではない。optionは複数packetに分かれ、packet自体も失われるからである。hostが信頼できるのは受信した値と既存timerの満了である。

Rule 3 は追い出さずに流れを変える

Preferred Lifetime が0になると、適切なpreferred sourceがあれば新規通信はそちらを使うべきである。RFC 6724 のsource address selection Rule 3は、候補の一方がdeprecatedなら、そうでない方を優先する。

これはdefault選択であって全面禁止ではない。applicationがvalidなsourceを明示すれば、その指定が尊重される場合がある。既存接続は旧アドレスを保持できる。deprecated アドレス宛てに新しいTCP SYNが届いた場合も、本来許可される接続なら、その同じアドレスからSYN-ACKを返し得る。

interfaceに旧アドレスが見えるだけでは移行失敗とは言えない。残すことが目的かもしれない。反対に、新アドレスが見えても、新規connectionが依然として旧sourceを選んでいればdrainは始まっていない。存在、状態、残り時間、実際のsource選択を分けて観測する必要がある。

ゼロのpreferredは穏やかな退役命令になる

旧prefixのPreferred Lifetimeを0、Valid Lifetimeを正の値にすれば、hostはアドレスを直ちにdeprecatedへ移すが削除しない。新しい接続は置換先へ流れ、長い接続は旧端点で終了できる。

RFC 5887 が述べる計画的renumberingも、この重複期間を利用する。新prefixを導入し、旧prefixのpreferred期間を終え、依存関係が減ってからvalid期間を閉じる。ただし、SLAACの状態だけで全体は移らない。

DNS、routing、firewall、ACL、certificate、監視設定、application内の固定値は別々に旧アドレスを持つ。hostでvalidでも上流routeが消えればpacketは戻らない。deprecatedになってもDNS recordは自動で消えない。二つの時計は各層が協調するための信号であり、分散した変更を一括commitする機能ではない。

無効化には強い証拠が要る

link上の攻撃者が偽RAを作れる状況で、数秒のValid Lifetimeをそのまま受け入れれば、hostのアドレスをまとめて消せる。RFC 4862 はこのDoSを抑えるため二時間の下限を設けた。もともとの残り時間が長い場合、認証されていない短い値は通常、二時間より早い無効化を起こせない。すでに残り二時間以下なら、さらに短くする未認証値はvalid計算で無視される。

Preferred Lifetime は同じ扱いではない。validの短縮を抑えても、preferredは受信値に更新する。理由は影響の差である。新規選択から外すことは、アドレスそのものを消すより可逆的であり、正当な管理者には速いdeprecationが必要になる。

認証されたRAなら別の判断ができる。二時間はすべての撤回に共通する待機時間ではなく、弱い証拠に破壊権限を与えすぎないためのhost側境界である。

新しいルーターは古い約束を知らない

家庭用routerが再起動し、上流から別prefixを受け取ったとする。stable storageに旧prefixがなければ、新しい情報は告知できても、どの古い情報を0で撤回すべきか分からない。hostは最後に聞いた寿命を持ち続ける。

RFC 8978 はこのflash renumberingを分析した。RFC 4861のdefault PIO値では、旧アドレスがpreferredで7日、validで30日残り得ると説明する。この数字は現行製品の普及調査ではない。撤回が失われたとき、過去の約束がどれほど長く生きるかを示す例である。

旧prefixを覚えていて両方を0にしても、未認証RAなら二時間保護に直面する。偽の死を防ぐ設計と、本当に失ったprefixをすぐ片付ける要求は同じ制御点で衝突する。

撤回は再起動とpacket lossを越える必要がある

RFC 9096 はcustomer edge routerに、以前advertiseしたprefixをstable storageへ保存し、LAN側寿命を上流leaseに合わせて抑え、古くなったprefixをpreferred・validとも0で繰り返し通知するよう勧める。

一回の通知では足りない。hostがそのRAを失う可能性があるため、routerは以前約束したValid Lifetimeを考慮した期間、撤回対象の名前を出し続ける。削除は一packetの送信完了ではなく、残存者へ届くまで続く責任である。

この後年の文書は実装率を証明しない。見えるようにしたのは、更新可能な状態を作る装置には終了対象を記録する責任がある、という前提だった。