要約

  • GRAND は、新しいアドレスの情報をホストからルーターへ先に送ることで、最初の返信時に必要となるアドレス解決を減らそうとする。9月4日の記事は、3月の FreeBSD の実装変更を説明したものだ。
  • 通知と遅延応答が処理基盤を共有しても、回数の上限や取り消し条件まで同じにしてよいわけではない。導入判断では、機能単体よりも両者が混在する場面を見る必要がある。

返信する側に残る空白

ホストがルーターを知っていても、ルーターがホストの新しい IPv6 グローバルアドレスに対応するリンク層アドレスを知っているとは限らない。外へ送る準備ができたことと、戻ってくるパケットをすぐ届けられることは別である。最初の返信を受けたルーターがそこで近隣探索を始めれば、通信の立ち上がりに待ち時間が生じる。

この空白を早めに埋める手段が、GRAND と呼ばれる Gratuitous Neighbor Discovery だ。Seyed Pouria Mousavizadeh Tehrani が9月4日に公開した実装解説は、FreeBSD での対応を説明している。重要なのは日付の区別である。新しいのは説明記事であり、そこで示されたコード変更は3月のものだ。9月に新製品が出たというニュースでも、広範な実環境で効果が測定されたという報告でもない。

通常の近隣探索にも、解決中のパケットを保持する仕組みがある。RFC 4861は、アドレス解決を待つ宛先について少なくとも一つのパケットを保持するよう求めている。したがって「情報がなければ最初のパケットは必ず捨てられる」と言い切るのは正しくない。GRAND の狙いは、その待ち時間や実装・負荷条件に伴う損失の可能性を減らすことにある。

通知を増やす前に、通知の仕事を限定する

RFC 9131では、ホストが新しいグローバルアドレスを設定した際、全ルーター向けマルチキャストで非要求の Neighbor Advertisement を送る手順が示されている。送信は無制限ではなく、回数を抑え、RetransTimer に基づく間隔を空ける。ルーター側にも対応する処理が必要だ。該当するキャッシュ項目がないとき、有効な通知と必要なリンク層アドレス情報を受け取ったルーターは、新しい項目を作成することが推奨され、その初期状態は STALE とされる。

これは、すでに存在する項目の扱いを全面的に変える仕様ではない。通知が届く保証もない。長期間使われずに項目が消えたり、キャッシュが消去されたりした後まで、一度の通知が効き続けるわけでもない。通常のアドレス解決は引き続き必要である。

FreeBSD の3月5日のコミットには、重複アドレス検出を終えた新しいグローバルアドレスや、リンク層アドレスの変更に伴う通知、そして待ち行列を利用した遅延処理の基盤が含まれている。履歴中の ip6.grand_count は通知回数を扱う制御点だ。ただし、この差分を読むだけで、現在使われている全リリースの既定値や設定を断定することはできない。

同じ基盤で動く、別の約束

遅らせて送るパケットは GRAND の通知だけではない。近隣探索には、複数のアドレスに関わる通知や、エニーキャスト・プロキシの応答など、送信時刻への配慮が必要な場面がある。共通の待ち行列を使えば処理をまとめられるが、まとめた後も仕事の種類を見失ってはならない。

その点を明示しているのが、3月19日に取り込まれた変更だ。変更説明は、GRAND の通知と問い合わせに対する応答を区別し、同じインターフェースアドレスの古い通知を取り消すことや、記憶領域の再利用、送信後の扱いを整理している。通知のための上限を数える際に、GRAND 以外の項目を除外する変更も確認できる。

通知を送りすぎないための上限が、別の仕事である応答まで同じ理由で制約してしまっては、改善したはずの機能が既存の動作と競合する。ここに、この実装履歴を運用上の問いとして読む意味がある。ただし、上限の一つから除外することは、応答用の資源が無限にあるという意味でも、絶対的な優先順位の保証でもない。物理的に二つの独立したキューへ分離したと読むべきでもない。

差分と説明から分かるのは設計意図と具体的な変更である。本稿ではコードをビルドしたり、競合する全実行順序を試したりしていない。GRAND による短縮時間や、本番環境での障害減少も測定していない。採用の根拠にできるのは「先に知らせると常に速い」という約束ではなく、通知と応答の共存を確かめるための、より具体的な検証項目である。