要約

  • IPv6のNeighbor Unreachability Detectionが保持するのは、前向き経路を通ったパケットが隣接者のIP層に届き、処理されたという時限的な根拠である。時間が過ぎればREACHABLEはSTALEになるが、障害が観測されたことを意味しない。
  • 代替隣接者がいない場合、RFC 7048はリンク層アドレスを保持したまま、間隔を広げて確認を続けられる。転送継続は本人性、アドレスの所有、認可、アプリケーションの完了を証明しない。

運用画面でSTALEという文字を見ると、遠端の機器が古くなったか、劣化したかのように感じる。ところが、その間もパケットは同じリンク層アドレスへ送られ、正常に届くことがある。これは表示と実装の不一致ではない。状態名が指している対象を読み違えた結果である。

古くなったのは、観測者が持つ肯定的な根拠だ。アドレスの記憶、根拠の鮮度、いま転送する必要があるか、再確認を始めたかは別々の事実である。Neighbor Unreachability Detection（NUD）は、その区別を状態遷移として残す。

Erik Nordmarkは、この設計の公開記録に複数回登場する。IPv6 Neighbor Discoveryを定めるStandards TrackのRFC 4861では4人の著者の一人であり、NUDが性急に失敗を宣言する場合を修正したRFC 7048では2人の著者の先頭に記載されている。Neighbor Discoveryの信頼モデルと脅威を分析するInformationalのRFC 3756にも参加した。これはIETFの共同作業への文書化された貢献を示す。単独発明、製品の適合、運用者への指揮権を示すものではない。

到達性は片方向で、観測者に属する

RFC 4861がいう到達性は、送信側から見た限定的な主張である。前向きの一方向経路が機能し、送ったパケットが隣接者のIP層へ届いて適切に処理されたという肯定的根拠が必要になる。相手が隣接ルーターなら、ルーターとして転送していることも含む。

「サービスが健全だ」という意味ではない。戻り経路の対称性、中継する全装置の健康、機器所有者の本人性、アプリケーションによる認可、物理動作の完了は範囲外だ。特定の次ホップについて、ある時間幅の中で前向き進行が確認されたというだけである。

肯定的な確認には二つの代表的な経路がある。一つはNeighbor Solicitationに対して返った、Solicitedフラグ付きのNeighbor Advertisement。もう一つは、上位層が示す前向き進行である。

新しいTCP ACKは、直近に送ったデータが遠端のpeerへ届いたことを示し得る。その経路の最初の一歩が当該隣接者なら、ACKはその次ホップを通ったという推論を支える。新規で重複していないデータの受信も、それ以前のACKが前へ進んだことを示し得る。

ただし、推論の用途は増殖しない。TCP ACKはリンク層隣接者を認証しない。戻り経路が同じとも、利用者に権限があるとも、業務処理が確定したとも言っていない。上位層の観測を借りて、最初の一歩に関する狭い質問を更新しているにすぎない。

状態遷移は断定ではなく、問いの切り替えである

INCOMPLETEはアドレス解決中で、必要なリンク層アドレスがまだない。REACHABLEは肯定的な確認が新しい。Reachable Timeが過ぎるとSTALEになるが、アドレス自体は捨てない。強い主張だけが期限切れになる。

使われていないSTALEエントリーは、時間が過ぎただけではprobeを出さない。次のパケットがそのエントリーを必要とした時、状態はDELAYへ移り、パケットは記憶しているアドレスへ送られる。短い待ち時間の間に上位層から新しい確認が来れば、余分なNeighbor SolicitationなしでREACHABLEへ戻せる。

確認がなければPROBEへ進む。保存したリンク層アドレスにunicastのNeighbor Solicitationを送り、有効なSolicited Neighbor Advertisementが返ればREACHABLEを回復する。基本のRFC 4861では、所定回数のprobeが尽きるとエントリーを削除し、次ホップ選択またはアドレス解決をやり直す。

この流れが分けているのは、位置の記憶、証拠の鮮度、利用需要、能動的な再確認だ。last_seen一つでは足りない。何を見たのか、どちら向きだったのか、どの状態を更新できる観測だったのかが必要になる。

相手の声が聞こえても、自分の声が届いたとは限らない

未要求のNeighbor Advertisementは、リンク層アドレスの変更を知らせることがある。Router Advertisementも重要な情報を運ぶ。しかし、それらが直接示すのは、隣接者から受信側へメッセージが届いたことだ。NUDが確認したいのは逆方向である。

そのためRFC 4861は、Router AdvertisementとSolicitedフラグが立っていないNeighbor Advertisementを、到達性確認として扱ってはならないとする。居場所を知ったことは、そこへ届くことの証明ではない。相手の発言を聞いたことは、こちらの呼びかけを相手が聞いた証明ではない。

すべての広告でlast_reachable_atを更新する監視は、方向を消してしまう。前向き経路を一度も確認していないのに、未要求メッセージだけで緑表示を延命できる。記録にはメッセージ方向、Solicitedフラグ、interface、target、リンク層アドレス変更、許可された状態遷移を残すべきだ。

「隣接者に関する情報を受け取った」と「前向き到達性を確認した」は別のイベントである。

早く諦める価値は、代替先の有無で変わる

RFC 7048は、標準的な動作をおおむね1秒間隔の3回送信として説明する。別のdefault routerが実際に使えるhostなら、短時間で現在の隣接者を諦めることには価値がある。別経路へ移れるからだ。

代替がない時は、同じ時計が逆効果になる。短い無線断、sleepしているlink、遅い回復がprobe予算を超えると、キャッシュ削除後にmulticastを伴うアドレス解決が始まる。唯一妥当だったリンク層アドレスまで捨て、代わりは一つも得られない。

RFC 7048はこの条件で、概念上のUNREACHABLE状態を導入する。エントリーとリンク層アドレスを保持し、そこへパケットを送り続けることができる。Neighbor Solicitationは指数backoffで続け、やがてunicastからmulticastへ切り替える。相手のリンク層アドレスが変わっていた場合、古い宛先だけを永遠に叩いても新しい所在を発見できないからだ。

ここでUNREACHABLEは送信停止でも永久障害でもない。確認手続きで肯定的な応答を得られなかったという状態だ。利用可能な代替次ホップが現れれば、未確認エントリーがその選択を妨げてはならない。Redirect由来のエントリーは保持せず削除する場合もある。

長く待つことが常に安全なのではない。代替がなければ継続の可能性を守る。代替があればfailoverを遅らせる。状態名だけでなく、その時点で利用可能だった選択肢を記録しなければ、判断は評価できない。

REACHABLEは認証済みという意味ではない

RFC 3756は信頼境界を示す。リンク上でNeighbor Discoveryメッセージを偽造できる攻撃者は、Solicitedに見えるNeighbor Advertisementで誤った肯定的確認を作れる。キャッシュを悪意ある、または存在しないリンク層アドレスへ向け、通信を妨害できる。状態機械は仕様通りでも、入力が敵対的なことはある。

したがってREACHABLEはcredentialではない。IPv6アドレスとリンク層アドレスの対応も、機器所有者、責任組織、稼働中のsoftware、接続を許したpolicyを証明しない。link admission、暗号、asset inventory、application authorizationは別の証拠を出す。

incidentの記録はそれらを並べて結び、代用させない。NUDについてはinterface、next hop、mapping、確認源、probe列、代替候補、security context、実装versionを残す。applicationについては認証principal、認可判断、resource version、結果receiptを分けて残す。Neighbor応答で後者を埋めてはならない。

著者名も、文書の権限も、狭く読む

2026年8月30日に確認したIETF profileは、Nordmarkについて25本のRFCとInternet of Things Directorateの現役reviewer職を掲載している。これは変化し得るprofile情報である。文書の著者欄はより安定している。RFC 4861はThomas Narten、Nordmark、William Simpson、Hesham Soliman。RFC 7048はNordmarkとIgor Gashinsky。RFC 3756はeditorのPekka Nikander、James Kempf、Nordmarkを記す。

RFC 4861とRFC 7048はStandards Trackで、RFC 3756はInformationalである。この区別も、著者順も、IETF consensusも、特定製品の挙動を自動的には証明しない。動いているcodeが、受け入れた上位層hint、状態遷移、代替選択、backoff、logを示す必要がある。

RFCは比較可能な公開基準であり、現場を遠隔操作する権限ではない。この制限こそNUDの設計と響き合う。役立つmappingは保持する一方、根拠が古くなれば主張を弱める。より強い判断が必要になった時だけ、新しい証拠を求める。

古くなったのは隣接者ではない。証言である。その読み分けが、継続を許しながら確実性を捏造しないための最小条件だ。

出典