GRANDによるIPv6ファーストパケットギャップの解消

IPv6ネイバー探索には微妙な非対称性があります。ホストはルーターに到達する方法を知っていますが、ルーターは必ずしもホストに到達する方法を知っているわけではありません。GRANDはこの非対称性を修正するため、ホストが積極的にアドレスをアドバタイズするようにし、私はこのメカニズムをFreeBSDに実装しました。 デバイスがIPv6ネットワークに参加し、ルーター広告（Router Advertisement）を受信して新しいIPv6アドレスを設定すると、すぐにインターネットとの通信を開始します。ホストの視点からは、すべてが準備完了です。デフォルトルーターのリンク層アドレスを知っているため、インターネットに向けてパケットをすぐに送信できます。 しかし、ルーターの視点からは状況が異なる場合があります。ルーターは、ホストの新たに設定されたグローバルIPv6アドレスに到達する方法をまだ知らない可能性があります。これにより、IPv6ネイバー探索に微妙な非対称性が生じます。ホストはすでにルーターに到達できますが、ルーターはホストへのトラフィックを転送する前にネイバー探索を実行する必要があるかもしれません。 最初のIPv6パケットの問題 新しいIPv6アドレスをちょうど設定したホストを考えてみましょう。ホストはオフリンク宛てのパケットを送信します。ファーストホップルーターはそのパケットを受信し、通常通り転送します。しかし、リモートの宛先から応答が返ってくると、戻りのパケットはホストを宛先としてルーターに到着します。 ルーターはそのIPv6アドレスのエントリをネイバーキャッシュに持っていない可能性があり、パケットを転送する前にホストのリンク層アドレスを解決する必要が生じます。これにより、ネイバー探索が最初の戻りパケットのクリティカルパスに直接置かれることになります。通常はアプリケーションから見えないメカニズムであるため、これは目に見える影響を与える可能性があります。接続の最初のパケットは、アドレス解決の進行中に余分な遅延を経験したり、場合によってはドロップされたりする可能性があります。 この問題は、ホストがすでにルーターが必要とするすべての情報を持っているため、特に興味深いものです。ホストはそのIPv6アドレスを所有しており、対応するリンク層アドレスを知っていますが、ルーターはまだそれを学習していません。 ネイバー探索がこの問題を引き起こす理由 この状況において、IPv6ネイバー探索は受動的です。ノードが、使用可能なネイバーキャッシュエントリを持っていないネイバーと通信する必要がある場合、ネイバー探索要求（Neighbour Solicitation）を送信し、ネイバー広告（Neighbour Advertisement）を待つことでアドレス解決を開始します。これは確立されたネイバーにとってはうまく機能します。問題は、「アドレスが使用可能になった」から「ネットワークの残りの部分がそれに到達する方法を知っている」への移行中に現れます。したがって、ここでも、ホストはすでに自身のIPv6アドレスとリンク層アドレスを知っていますが、ファーストホップルーターはトラフィックが到着するまでホストに関する情報を持っていない可能性があります。 これがGRANDが対処するギャップです。 GRAND：受動的なネイバー探索を受動的な情報提供へ Gratuitous Neighbour Discoveryは、ルーターが最初のパケット到着時にホストを発見するのを待つのではなく、情報フローの方向を変えます。ホストは、未承諾のネイバー広告（unsolicited Neighbour Advertisement）を使用して、自身のIPv6アドレスとリンク層アドレスを積極的に通知します。 これにより、ルーターはホストへのトラフィックを転送する必要がある前に、その情報を学習できます。これがRFC 9131の背後にある中心的な考え方です。 しかし、GRANDの実装は、アドレスが出現するたびに未承諾のネイバー広告を送信するだけではありません。GRANDは、複数のアドレスの処理、anycastおよびプロキシアドレス、タイミング、重複アドレス検出など、いくつかの既存のネイバー探索ルールと相互作用します。 RFC 4861に基づいたGRANDの構築 GRANDの実装の重要な部分は、未承諾のネイバー広告がすでにネイバー探索において定義された役割を持っていることを理解することです。 RFC 4861のルール7.2.6は、ノードのリンク層アドレスの変更などのケースを含む、未承諾のネイバー広告の動作を指定しています。また、複数のアドレスに対してノードが送信できる広告の数も制限し、不要な輻輳を避けるためにそれらの広告の間隔を空けることを推奨しています。 RFC 4861のルール7.2.7および7.2.8は、anycastおよびプロキシネイバー広告の特殊なケースをカバーしています。これらの状況では、複数のノードが同じネイバー探索要求に応答できる可能性があります。それらがすべて即座に送信した場合、その目的は効果がなくなります。 これに対処するため、RFC 4861は、anycastまたはプロキシネイバー広告を送信する前にランダムな遅延を指定しています。これにより、複数の潜在的な応答者が同時に送信するのを避ける機会が得られます。 これらのタイミングルールは、ネイバー探索の全体的な設計の重要な部分です。情報を迅速に利用可能にすることは有用ですが、マルチキャストストームを作成せずにそれを行うことも同様に重要です。 私の実装では、既存のキューイングおよび遅延NAインフラストラクチャに依存するのではなく、GRAND作業の一部としてこれらの動作を追加しました。 GRANDと遅延ネイバー広告 したがって、GRANDのあまり明白でない部分の1つは、ネイバー広告のスケジューリングです。そこで、私は欠けているRFC 4861の部分を実装することにしました。 既存の実装は、これらの動作に必要なキューイングおよび遅延送信の仕組みを以前は提供していませんでした。GRANDの実装には、そのインフラストラクチャを追加し、それを使用して未承諾のネイバー広告をスケジュールすることが必要でした。 GRANDでは、新しく設定されたアドレスが未承諾のネイバー広告につながる可能性がありますが、実装はアドバタイズされているアドレスの数と各広告が送信されるべきタイミングを考慮する必要があります。IPv6では、インターフェイスは同時に数百ものアドレスを持つことがあります。 すべての広告を即座に送信すると、不要なバーストが発生する可能性があります。たとえば、電源が復旧した後のデータセンターで、多くのサーバーが同時に起動する場合を考えてみてください。そのため、実装はRFC 4861 7.2.6で説明されている遅延広告の動作と、7.2.7および7.2.8で説明されているランダム化された応答動作を追加します。 これは、複数のノードが応答できる可能性のあるanycastおよびプロキシアドレスに特に重要です。 目標は、広告が送信されるまでの時間を最小限に抑えることだけではありません。それは、高速なネイバー探索と、その探索によって生成されるマルチキャストトラフィックの量をバランスさせることです。 RFC 9131は何を変更するのか？ RFC 9131は、これらのネイバー探索メカニズムを基盤として、ファーストパケットの問題に対処します。 ホストは、新しいIPv6アドレスが使用可能になったときに、未承諾のネイバー広告を送信します。この広告には、ファーストホップルーターがネイバーエントリを構築するために必要な情報が含まれています。 しかし、メカニズムには重要な後半部分があります。元のRFC 4861の動作では、未承諾のネイバー広告を受信しても、ネイバーキャッシュエントリを持たないルーターがそれを作成するとは限りませんでした。 RFC 9131はこの動作を変更します。 ルーターが、ネイバーキャッシュエントリを持たないアドレスに対して有効な未承諾ネイバー広告を受信した場合、広告で提供された情報を使用してそれを作成できます。エントリはSTALE状態（一時的な状態）で作成されます。この詳細は、GRANDをファーストパケットの問題に役立つものにしています。 STALEが鍵となる理由 最初に、新しく学習したネイバーをSTALEとしてマークすることは、直感に反するように思えるかもしれません。なぜREACHABLE（到達可能）とマークしないのでしょうか？実際、この区別は重要です。 GRANDは、ホストがIPv6アドレスを主張しており、リンク層アドレスを提供していることをルーターに伝えます。それは必ずしも、ネイバー到達可能性検出（Neighbour Unreachability Detection）で使用される意味でのネイバーが現在到達可能であることを証明するものではありません。 STALEにより、ルーターはすでに学習した情報を使用できますが、新しいマルチキャストアドレス解決操作を必要としません。ルーターはその後、通常のネイバー探索メカニズムを使用して到達可能性を検証できます。これは、GRANDがネイバーが永続的に到達可能であることが検証されたと主張することなく、ファーストパケットのクリティカルパスからアドレス解決を削除することを意味します。 FreeBSDでのGRANDの実装 したがって、FreeBSDでのGRANDの実装には、未承諾のネイバー広告を送信するためのコードを追加する以上のことが含まれていました。