IPv6の「最初のパケット」遅延を解消するGRAND、FreeBSDに実装される
Closing the IPv6 First-Packet Gap with Grand
IPv6 Neighbour Discoveryには、ホストがルーターを先に知る一方で、ルーターはホストのアドレスをまだ学習していないという非対称性がある。このため、最初の戻りパケットでアドレス解決がクリティカルパスに入り、遅延やパケットロスが発生し得る。GRAND（RFC 9131）は、ホストが新たに利用可能になったIPv6アドレスを未承諾Neighbour Advertisementで能動的に広告し、ルーターがSTALE状態のNeighbour Cacheエントリを事前に作成できるようにする。FreeBSDへの実装では、RFC 4861の遅延送信やランダム化の仕組みを新たに追加し、マルチキャストのバーストを避けつつ初回パケットの遅延を解消した。
GRANDは、ルーターにホストがIPv6アドレスを主張していることを伝え、リンク層アドレスを提供する。しかし、Neighbour Unreachability Detectionの意味でそのネイバーが現在到達可能であることを必ずしも証明するものではない。
HNでの議論
20- mort96
待って、これがわからない。
正しく理解していれば、従来のIPv6フローはこうだ：
* ホストがSLAAC経由で自身のIPアドレスを設定する
* ホストがゲートウェイに、何らかの宛先アドレスを持つパケットを送信する
* ゲートウェイがそのパケットをインターネットに転送する
* やがて、応答パケットがゲートウェイに到着する
* この時点で、ゲートウェイはパケットをホストに送る方法を突き止めるために近隣探索を行う
* ゲートウェイはパケットを破棄するか、近隣探索が完了するまで転送を遅延させる可能性がある
なぜフローをこう変えられないのか：
* ホストがSLAAC経由で自身のIPアドレスを設定する
* ホストがゲートウェイに、何らかの宛先アドレスを持つパケットを送信する
* ゲートウェイはパケットを転送し、同時に近隣探索を開始する。なぜなら、外向きパケットを送るほぼすべてのコンピュータは、最終的に何らかの内向きパケットを受け取るからだ
* 応答パケットが到着する頃には、近隣探索はおそらくすでに完了しているか、そうでなくとも良いスタートを切っている
これは明白な解決策ではないのか？ホストの変更も新しいプロトコルも必要とせず、ルータのちょっとした調整だけで済む。普通、実際の問題に対して一見明白な単純解があり、それがネットワーキング標準に携わる賢い人たちの誰も実装していない場合、それには正当な理由があって、解決策は見た目ほど単純ではないものだ。だから、私が見落としているのは何なんだ？
- happyPersonR
最近、こんな環境での挙動を扱ったばかりで、この話を眺めるのは面白い。その環境では：
1) SLAAC/静的IP
2) 複数のデフォルトゲートウェイ、そしてBGP経由でルート（複数のデフォルトゲートウェイを含む）をインポートし、どれがアクティブかを突き止めるためにBFDを開始する
3) そしてBGP経由で自身のアドレスを広告し始める
ということが期待されていた。
これを設定できるsystemdのデーモンがあればいいのにと思う。仕組みを知らない人には馬鹿げて見えるだろうが、データセンターではなかなか興味深いフローだ。
Kubernetes/通常のLinuxの世界にも同等のものがあればいいのにと思うが、スケーラビリティの懸念は理解できる :)
BIRDが存在するのは知っているが、これが一種の組み込みであってほしい…systemdが拡張をサポートしているか見てみよう…追加できたらクールだ :)
もっと多くの人が欲しがるかもしれない。