6.1.5. EID-to-RLOC UDP Map-Reply Message (EID から RLOC への UDP Map-Reply メッセージ)
6.1.5. EID-to-RLOC UDP Map-Reply Message (EID から RLOC への UDP Map-Reply メッセージ)
Map-Reply が返す EID-Prefix とそのプレフィックス長は, 要求された EID 以下です。要求された EID は Data-Probe の IP ヘッダの宛先フィールドまたは Map-Request の EID レコードから取得されます。Map-Reply の RLOC は LISP サイトのすべての ETR のグローバルにルーティング可能な IP アドレスです。各 RLOC は状態の到達可能性を伝えますが, 要求者の観点からのパスの到達可能性は伝えません。パスの到達可能性は個別にテストする必要があります。セクション 6.3 を参照してください。
Map-Reply に含まれる EID-Prefix の粒度 (プレフィックス + 長さ) は, それをトリガーした Map-Request とは異なる場合があります。例えば, Map-Request が以前の Map-Reply によって返されたプレフィックスに対するものである場合, 要求者は新しいプレフィックス情報と粒度でキャッシュを更新します。例えば, 要求者が Map-Reply 内の 1 つのより粗いプレフィックスによってカバーされる 2 つの EID-Prefix をキャッシュしている場合, より粗い EID-Prefix でエントリを置き換えます。逆に, 1 つのより粗いプレフィックスを複数のより細かいプレフィックスで置き換えることもでき, より粗いエントリを削除するのではなく, より細かいプレフィックスを追加し, ルックアップ時により細かいエントリがより粗いエントリをオーバーライドします。
ETR が重複する EID-Prefix で構成されている場合, いずれかの EID-Prefix に最適に一致する EID の Map-Request は, 1 つの Map-Reply メッセージでのみ返されなければなりません。例えば, ETR データベースマッピングエントリが次の場合:
10.0.0.0/8 10.1.0.0/16 10.1.1.0/24 10.1.2.0/24
EID 10.1.1.1 の Map-Reply のレコード数は 1 で, マッピングレコード EID-Prefix は 10.1.1.0/24 です。
EID 10.1.5.5 の Map-Reply のレコード数は 3 で, マッピングレコードは 10.1.0.0/16, 10.1.1.0/24, 10.1.2.0/24 です。
すべての重複 EID-Prefix を返す必要はなく, 要求 EID に対して一致する EID-Prefix に対してより細かいエントリのみを返します (2 番目の例で 10.1.5.5 を要求したときに 10.0.0.0/8 は返されません)。複数の EID-Prefix を返す場合, すべて同じ Time to Live を使用して同時にタイムアウトするようにすべきです。後でより細かい EID-Prefix を受信した場合, より粗いエントリが存在しても, その Map-Reply レコードの TTL を保存できます。後でより粗い EID-Prefix を受信した場合, その map-cache 有効期限は map-cache 内のより細かい EID-Prefix の最小有効期限に設定されるべきです。これにより EID-Prefix セットの整合性が保たれ, より細かいエントリを削除してより粗いエントリを保持することが回避されます。
同じ EID-Prefix に対して, Map-Reply を同じ要求ルータに毎秒 1 回を超える頻度で送信すべきではありません。スケーラビリティのため, EID アドレスを EID-Prefix に集約することが期待されます。これにより, 1 つの Map-Reply がプレフィックス範囲内の複数の EID のマッピングを満たすことができ, Map-Request が削減されます。
Map-Reply レコードは空の Locator-Set を持つことができます。Negative Map-Reply, つまり Locator-Set が空の Map-Reply は, Map-Reply を要求した ITR または PITR に送信者の特別なアクションを伝えます。主な用途: Map-Resolver が宛先が LISP サイトに属するか非 LISP サイトに属するかを示す, および未割り当て EID への Map-Request に対するソース抑制。
各 Map-Reply レコード内で, Locator-Set 内の Locator リストの順序は, Map-Reply を開始する各 ETR で同じでなければなりません。Locator-Set は IP アドレスの昇順でソートされなければならず, IPv4 locator アドレスは数値的に IPv6 locator アドレス「より小さい」です。
Map-Reply を送信する場合, 宛先アドレスは Map-Request のいずれかの ITR-RLOC フィールドからコピーされます。ETR はサポートするアドレスファミリから locator アドレスを選択できます。Data-Probe の場合, Map-Reply 宛先アドレスは応答をトリガーした Data-Probe メッセージの送信元アドレスからコピーされます。Map-Reply 送信元アドレスは, 上流サービスプロバイダの Unicast Reverse Path Forwarding (uRPF) チェックが成功するように選択されたローカル IP アドレスの 1 つです。Map-Reply 宛先ポートは Map-Request または Data-Probe の送信元ポートからコピーされ, 送信元ポートは既知の UDP ポート 4342 に設定されます。
6.1.5.1. Traffic Redirection with Coarse EID-Prefixes (粗粒度 EID-Prefix によるトラフィックリダイレクト)
ETR が誤って構成されているか侵害されている場合, Map-Reply で粗粒度の EID-Prefix を返す可能性があり, 他のサイトに割り当てられたプレフィックスをカバーし, そのトラフィックを侵害されたサイトの Locator にリダイレクトします。
解決策の主なアプローチは 2 つあります。1 つは Map-Server に ETR の代わりに Map-Reply を応答させ, 返されるのが登録済み EID-Prefix であるようにすることです。ETR と Map-Server の間は共有鍵で保護され, ETR は異常を検出しやすくなります。2 つ目は ITR と PITR に, マスク長が特定の構成されたプレフィックス長以上の EID-Prefix のみをキャッシュさせ, 任意のプレフィックス幅のアドバタイズによる損害を特定の範囲に制限することです。ただし, サイトのプレフィックス割り当てと調整する必要があります。2 つのアプローチは独立してまたは同時に使用できます。
本文書の執筆時点では, 他のアプローチがまだ研究および検討中です。