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での議論
31- mort96
待って、これがわからない。
正しく理解していれば、従来のIPv6フローはこうだ：
* ホストがSLAACで自分のIPアドレスを設定する
* ホストがゲートウェイに、ある宛先アドレス宛のパケットを送る
* ゲートウェイがそのパケットをインターネットに転送する
* やがて、応答パケットがゲートウェイに届く
* この時点で、ゲートウェイはホストにパケットを送る方法を突き止めようと近隣探索を行う
* ゲートウェイはパケットを破棄するか、近隣探索が完了するまで転送を遅延させるかもしれない
なぜフローをこう変えられないのか：
* ホストがSLAACで自分のIPアドレスを設定する
* ホストがゲートウェイに、ある宛先アドレス宛のパケットを送る
* ゲートウェイはパケットを転送し、同時に近隣探索を開始する。なぜなら、外向きパケットを送るほぼすべてのコンピュータは、いずれ内向きパケットを受け取るからだ
* 応答パケットが届く頃には、近隣探索はおそらくすでに完了しているか、そうでなくても良いスタートを切れている
これこそ明白な解決策で、ホストの変更も新しいプロトコルも必要とせず、ルータのちょっとした調整だけで済むのではないか？普通、現実の問題に対して一見明白で単純な解決策があり、それがネットワーク標準で働く賢い人たちの誰も実装していない場合、それにはちゃんとした理由があって、解決策は見た目ほど単純ではない。つまり、私が何を見落としているんだ？
- happyPersonR
最近、こんな環境での挙動を扱ったばかりで、この話を眺めるのは面白い。その環境では：
1) SLAAC/静的IP
2) 複数のデフォルトゲートウェイがあり、BGP経由でルート（複数のデフォルトゲートウェイを含む）をインポートし、BFDを開始してどれがアクティブかを判断する
3) そして自分のアドレスをBGPで広告し始める
systemdに、これを設定できるデーモンがあればいいのに。仕組みを知らない人には馬鹿げて見えるだろうが、データセンターではなかなか面白いフローだ。
kubernetes/普通のLinuxの世界にも同等のものがあればいいのにと思うが、スケーラビリティの懸念は理解できる :)
BIRDが存在するのは知っているが、これがビルトインであればいいのに…systemdが拡張をサポートしているか見てみよう…追加できたらクールだ :)
もっと多くの人が欲しがるかもしれない。
- basilikum
興味深い話題だ。
読み始め、
文章が恐ろしく長く、実際の内容を覆い隠す無駄な言葉と無意味に並べられた単語のせいで集中を保つのが難しい、
AIの兆候に気づく。
読むのをやめ、
Pangramに貼り付け、
ほとんどAI、
テキストを下にスクロールし、
これを見つける：
> 注：著者は草稿と文章作成にAIツールを使用しました。技術的な作業、分析、結論は著者自身のものです。AI生成コンテンツに関するポリシーの詳細は、RIPE Labsへの貢献ページをご覧ください。
RIPE、もっとましなことをしてくれ。RIPEには何かしらの基準があると思っていた。基準を持たないと決めたなら、せめてAIの免責事項を冒頭に置いて、くだらないものに時間を無駄にしないようにしてほしい。失礼だ。
NDPとGRANDについて、くだらないものではなく、共有して読む価値のある記事を誰か持っていないか？