6.1.3. EID-to-RLOC UDP Map-Request Message
6.1.3. EID-to-RLOC UDP Map-Request Message
ITR が EID のマッピングを必要とする場合, RLOC の到達可能性をテストする場合, または TTL が期限切れになる前にマッピングをリフレッシュする場合に Map-Request を送信します。最初のケースでは, Map-Request が使用する宛先 IP アドレスは, マッピングキャッシュルックアップに失敗したデータパケットの宛先アドレス (つまり宛先 EID) です。後の 2 つのケースでは, Map-Request が使用する宛先 IP アドレスは Map-Cache エントリの Locator-Set 内の RLOC アドレスの 1 つです。送信元アドレスは, Map-Request が IPv4 または IPv6 ヘッダを使用しているかに応じて, それぞれ IPv4 または IPv6 RLOC アドレスです。すべてのケースで, Map-Request メッセージの UDP 送信元ポート番号は ITR/PITR が選択した 16 ビット値であり, UDP 宛先ポート番号は既知の宛先ポート番号 4342 に設定されます。成功した Map-Reply (つまり未処理の Map-Request nonce と一致する nonce を持つ Map-Reply) は, EID-Prefix 範囲に関連付けられたキャッシュされた RLOC セットを更新します。
ITR は 1 つ以上の Map-Request ('ITR-RLOC-AFI', 'ITR-RLOC-Address') フィールドに記入しなければなりません。エンコードされたフィールドの数 (マイナス 1) は 'IRC' フィールドに入れなければなりません。ITR は, このリストにローカルに構成されたすべての Locator を含めるか, サポートする各アドレスファミリの 1 つの locator アドレスのみを提供できます。ITR が誤って ITR-RLOC アドレスを提供しない場合, Map-Replier は Map-Request をドロップしなければなりません。
ITR から Map-Resolver に送信される場合, Map-Request は UDP 宛先ポート 4342 と LISP Type 値「Encapsulated Control Message (カプセル化制御メッセージ)」に設定して LISP カプセル化することもできます。同様に, Map-Server から ETR への Map-Request も同じ方法で LISP カプセル化されます。カプセル化された Map-Request と Map-Resolver の詳細については [RFC6833] を参照してください。
Map-Request はレート制限されなければなりません。同じ EID-Prefix への Map-Request を毎秒 1 回を超える頻度で送信しないことが推奨されます。
マッピングデータベース情報を構成している ITR (つまり ETR でもある) は, これらのマッピングを Map-Request に含めることを選択できます。このような「piggybacked (ピギーバック)」マッピングデータを受け入れて検証するように構成された ETR がこのような Map-Request を受信し, map-cache にこのマッピングがない場合, 「verifying Map-Request (検証 Map-Request)」を開始できます。これは要求するマッピングの ITR に送信され, ETR は Map-Cache エントリを追加できます。ETR が「piggybacked」EID に一致する Map-Cache エントリを持ち, RLOC がそのエントリの Locator-Set 内にある場合, 元の Map-Request ソースに「verifying Map-Request」を直接送信できます。RLOC が Locator-Set 内にない場合, ETR は「verifying Map-Request」を「piggybacked」EID に送信しなければなりません。これにより,「verifying Map-Request」はマッピングデータベースシステムを介してその EID に関する権威情報源に到達することが強制され,「piggybacked」マッピングデータでの RLOC スプーフィングが防止されます。