GRANDによるIPv6ファーストパケットギャップの解消
Closing the IPv6 First-Packet Gap with Grand (labs.ripe.net)
要約
IPv6のネイバー探索（Neighbour Discovery）には、ホストがルーターに到達する方法を知っていても、ルーターがホストに到達する方法をまだ知らないという非対称性が存在します。これにより、接続の最初のパケットで遅延やパケットロスが発生する可能性があります。GRAND（Gratuitous Neighbour Discovery）はこの問題を解決するため、ホストが新しいIPv6アドレスを設定した際に、自身のIPv6アドレスとリンク層アドレスを積極的に通知するメカニズムを導入します。これにより、ルーターはホストへのトラフィック転送に必要な情報を事前に学習できるようになり、ファーストパケットの問題が解消されます。
全文翻訳
GRANDによるIPv6ファーストパケットギャップの解消
IPv6ネイバーディスカバリには、ホストがルーターに到達する方法を知っていても、ルーターが必ずしもホストに到達する方法を知っているわけではないという微妙な非対称性が存在します。GRANDはこの非対称性を、ホストが積極的にアドレスを通知することで修正します。私はこのメカニズムをFreeBSDに実装しました。
デバイスがIPv6ネットワークに参加し、ルーター広告を受信し、新しいIPv6アドレスを設定すると、すぐにインターネットとの通信を開始します。
ホストの視点からは、すべてが準備完了です。デフォルトルーターのリンク層アドレスを知っているため、すぐにインターネットへパケットを送信できます。
しかし、ルーターの視点からは、状況は異なる場合があります。ルーターは、ホストの新たに設定されたグローバルIPv6アドレスに到達する方法をまだ知らない可能性があります。
これにより、IPv6ネイバーディスカバリに微妙な非対称性が生じます。ホストはすでにルーターに到達できますが、ルーターはホストへのトラフィックを転送する前にネイバーディスカバリを実行する必要があるかもしれません。
最初のIPv6パケットには問題がある
新しいIPv6アドレスを設定したばかりのホストを考えてみましょう。
ホストはオフリンク宛先にパケットを送信します。ファーストホップルーターはパケットを受信し、通常どおり転送します。しかし、リモート宛先からの応答が来ると、戻りのパケットは宛先ホストとしてルーターに到着します。
ルーターはそのIPv6アドレスのエントリをネイバーキャッシュに持っていない可能性があり、パケットを転送する前にホストのリンク層アドレスを解決する必要があります。これにより、ネイバーディスカバリが最初の戻りパケットのクリティカルパスに直接置かれます。
通常はアプリケーションからは見えないメカニズムですが、これは目に見える影響を与える可能性があります。接続の最初のパケットは、追加の遅延を経験したり、アドレス解決の進行中にドロップされたりする可能性があります。
この問題は、ホストがルーターに必要なすべての情報を持っているため、特に興味深いものです。ホストは自分がIPv6アドレスを所有しており、対応するリンク層アドレスを知っていますが、ルーターはまだそれを学習していません。
なぜネイバーディスカバリがこの問題を引き起こすのか？
IPv6ネイバーディスカバリはこの状況ではリアクティブ（反応的）です。ノードが、使用可能なネイバーキャッシュエントリを持たないネイバーと通信する必要がある場合、ネイバー募集（Neighbour Solicitation）を送信し、ネイバー広告（Neighbour Advertisement）を待つことでアドレス解決を開始します。
これは確立されたネイバーにとってはうまく機能します。問題は、「アドレスが使用可能になった」から「ネットワークの残りの部分がそれに到達する方法を知っている」への移行中に現れます。したがって、ここでも、ホストはすでに自身のIPv6アドレスとリンク層アドレスを知っていますが、ファーストホップルーターはトラフィックが到着するまでホストに関する情報を持っていない可能性があります。
これがGRANDが対処するギャップです。
GRAND：リアクティブなネイバーディスカバリをプロアクティブな情報交換へ変更
Gratuitous Neighbour Discovery（意図的なネイバーディスカバリ）は、情報フローの方向を変更します。つまり、最初のパケットが到着したときにルーターがホストを発見するのを待つのではなく、ホストは意図しないネイバー広告を使用して、自身の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の実装には、意図しないネイバー広告を送信するコードを追加する以上のことが含まれていました。
既存のIPv6ネイバーディスカバリ実装は、すでにステートマシン、アドレスライフサイクル処理、重複アドレス検出、およびネイバーキャッシュ管理を提供していました。しかし、GRANDおよび関連するRFC 4861の動作に必要なキューイングおよび遅延ネイバー広告送信の仕組みは、以前は提供されていませんでした。
GRANDの実装は、そのインフラストラクチャを追加しました。
また、RFC 4861ルール7.2.7および7.2.8の関連する遅延およびランダム化された広告動作も実装しています。
これには、複数のアドレス、anycastアドレス、およびプロキシ関連の広告が不要なネイバーディスカバリトラフィックのバーストを生成しないように、広告のタイミングを処理することが含まれます。
その結果、実装はネイバーディスカバリのいくつかの動作を組み合わせています。
- 新しく使用可能になったIPv6アドレスを積極的に広告する
- リンク層アドレスの変更を処理する
- ネイバー広告のキューイングを追加する
- 複数の意図しない広告を遅延させる
- anycastおよびプロキシ応答に適切なランダム化を適用する
- 新しいスケジューリングメカニズムを既存のND状態およびタイマー処理と統合する
結果は、個別の「GRANDサブシステム」ではなく、新しいキューイングおよび送信スケジューリングサポートを備えた既存のネイバーディスカバリ実装の拡張です。
リンク層アドレスの変更の処理
GRANDは、意図しないネイバー広告の既存の用途の1つにも自然に接続されます。
RFC 4861ルール7.2.6は、リンク層アドレスの変更などの状況に対する意図しない広告を定義しています。インターフェイスのリンク層アドレスが変更され、IPv6アドレスが引き続き設定されている場合、他のノードは以前のリンク層アドレスを参照するキャッシュされた情報を持っている可能性があります。実装は、通常のネイバーディスカバリが変更を検出するのを待つのではなく、新しいマッピングを積極的に広告できます。
これは、GRANDの実装が密接に関連する2つの状況をカバーすることを意味します。
- IPv6アドレスが使用可能になる
- 既存のIPv6アドレスのリンク層マッピングが変更される
どちらの場合も、目的は同じです。ネイバーがリアクティブに発見を強制される前に、情報を利用可能にすることです。
FreeBSDへの統合中に学んだこと
この実装は、プロトコルを紙の上で実装することと、既存のネットワーキングスタックに統合することの重要な違いも浮き彫りにしました。
RFCは望ましいプロトコルの動作を記述していますが、カーネルは以前はその実装に必要なすべてのメカニズムを持っていませんでした。特に、GRANDはネイバー広告のための新しいキューイングおよび遅延送信サポートを必要としました。
したがって、GRANDを追加することは、これらのメカニズムを導入し、それらが既存のアドレスライフサイクル、DAD、ネイバーキャッシュ管理、およびネイバーディスカバリ状態処理と正しく相互作用することを確認することを意味しました。
特に、GRANDによって生成された広告は、他のネイバー広告とは異なる意味論を持っています。これは、広告がキューイング、結合、遅延、および最終的に送信される方法の変更を必要としました。
タイミング要件も、パケットをすぐに生成するよりも実装を興味深いものにしています。実装は、情報をファーストパケット問題を解決するのに十分早く利用可能にしながら、不要なバーストの作成を回避する必要があります。
ここで、RFC 4861ルール7.2.6-7.2.8の詳細が実際には重要になります。それらは単なる歴史的なプロトコルの詳細ではなく、実際のネットワーク上でプロアクティブなネイバーディスカバリがうまく機能するために必要なルールを提供します。
なぜこれが実際のIPv6デプロイメントにとって重要なのか？
ネイバーディスカバリは、すべてが正しく機能しているときはしばしば見過ごされがちであり、まさにこのような問題が見過ごされやすい理由です。プロトコルは通常十分に高速であるため、ユーザーはそれについて考えることはありません。しかし、ネイバーディスカバリは転送パス上に直接配置される可能性があり、その動作が接続の最初のパケットに影響を与える可能性があります。
IPv6ホストがアドレスを動的に設定および削除するにつれて、これはますます関連性が高まります。プライバシーアドレス、変更されるプレフィックス、モバイルデバイス、仮想マシン、コンテナ、その他の環境はすべて、インターフェイスの存続期間中にアドレスが出現および消滅する可能性があります。
GRANDにより、ネットワークはトラフィックがそのディスカバリを強制するのを待つのではなく、アドレスが利用可能になった時点で新しいアドレスについて学習できます。同時に、ネイバーディスカバリ設計から継承されたタイミングメカニズムは、プロアクティブな広告自体が不要なマルチキャストトラフィックの原因にならないようにするのに役立ちます。
GRANDとRFC 9898
GRANDは、RFCで説明されている興味深い最適化だけではありません。RFC 9898、「IPv6デプロイメントにおけるネイバーディスカバリの考慮事項」は、GRANDを、この形式のネイバーディスカバリによって引き起こされるルーター転送遅延に対処するメカニズムとして明確に特定しています。
これは、理論的なプロトコルの問題として扱うのではなく、実際のIPv6デプロイメントのコンテキストで問題を設定するため重要です。