6.1.3. EID-to-RLOC UDP Map-Request Message
6.1.3. EID-to-RLOC UDP Map-Request Message
Ein Map-Request wird von einem ITR gesendet, wenn er ein Mapping für eine EID benötigt, einen RLOC auf Erreichbarkeit testen möchte oder ein Mapping vor Ablauf der TTL aktualisieren möchte. Im Ausgangsfall ist die für den Map-Request verwendete Ziel-IP-Adresse die Zieladresse des Datenpakets (d.h. die Ziel-EID), bei dem die Mapping-Cache-Suche fehlgeschlagen ist. In den beiden letzteren Fällen ist die für den Map-Request verwendete Ziel-IP-Adresse eine der RLOC-Adressen aus dem Locator-Set des Map-Cache-Eintrags. Die Quelladresse ist entweder eine IPv4- oder IPv6-RLOC-Adresse, abhängig davon, ob der Map-Request einen IPv4- oder IPv6-Header verwendet. In allen Fällen ist die UDP-Quellportnummer für die Map-Request-Nachricht ein vom ITR/PITR ausgewählter 16-Bit-Wert, und die UDP-Zielportnummer ist auf die bekannte Zielportnummer 4342 gesetzt. Ein erfolgreiches Map-Reply, das eine Nonce hat, die mit einer ausstehenden Map-Request-Nonce übereinstimmt, aktualisiert den zwischengespeicherten Satz von RLOCs, die mit dem EID-Prefix-Bereich verbunden sind.
Ein oder mehrere Map-Request-Felder ('ITR-RLOC-AFI', 'ITR-RLOC-Address') MÜSSEN vom ITR ausgefüllt werden. Die Anzahl der codierten Felder (minus 1) MUSS im Feld 'IRC' platziert werden. Der ITR KANN alle lokal konfigurierten Locators in dieser Liste aufnehmen oder nur eine Locator-Adresse von jeder von ihm unterstützten Adressfamilie bereitstellen. Wenn der ITR fälschlicherweise keine ITR-RLOC-Adressen bereitstellt, MUSS der Map-Replier den Map-Request verwerfen.
Map-Requests können auch LISP-gekapselt unter Verwendung des UDP-Zielports 4342 mit einem LISP-Type-Wert auf "Encapsulated Control Message (Gekapselte Kontrollnachricht)" gesetzt werden, wenn sie von einem ITR zu einem Map-Resolver gesendet werden. Ebenso werden Map-Requests auf die gleiche Weise von einem Map-Server zu einem ETR LISP-gekapselt. Details zu gekapselten Map-Requests und Map-Resolvern finden Sie in [RFC6833].
Map-Requests MÜSSEN ratenbegrenzt sein. Es wird EMPFOHLEN, dass ein Map-Request für dasselbe EID-Prefix nicht öfter als einmal pro Sekunde gesendet wird.
Ein ITR, der mit Mapping-Datenbankinformationen konfiguriert ist (d.h. er ist auch ein ETR), KANN diese Mappings optional in einem Map-Request einschließen. Wenn ein ETR, der so konfiguriert ist, dass er solche "piggybacked (huckepack)" Mapping-Daten akzeptiert und verifiziert, einen solchen Map-Request empfängt und dieses Mapping nicht im Map-Cache hat, KANN er einen "verifying Map-Request (verifizierenden Map-Request)" initiieren, der an den Mapping anfordernden ITR adressiert ist, und der ETR KANN einen Map-Cache-Eintrag hinzufügen. Wenn der ETR einen Map-Cache-Eintrag hat, der mit der "piggybacked" EID übereinstimmt, und der RLOC im Locator-Set für den Eintrag ist, dann kann er den "verifying Map-Request" direkt an die Quelle des ursprünglichen Map-Requests senden. Wenn der RLOC nicht im Locator-Set ist, dann MUSS der ETR den "verifying Map-Request" an die "piggybacked" EID senden. Dies zwingt den "verifying Map-Request", durch das Mapping-Datenbanksystem zu gehen, um die autoritative Informationsquelle über diese EID zu erreichen, und schützt vor RLOC-Spoofing in den "piggybacked" Mapping-Daten.