6.1.3. EID-to-RLOC UDP Map-Request Message
6.1.3. EID-to-RLOC UDP Map-Request Message
Un Map-Request est envoyé lorsqu'un ITR a besoin d'un mappage pour un EID, souhaite tester la joignabilité d'un RLOC ou souhaite actualiser un mappage avant l'expiration du TTL. Pour le cas initial, l'adresse IP de destination utilisée pour le Map-Request est l'adresse de destination du paquet pour laquelle la recherche dans le cache de mappages a échoué (c'est-à-dire l'EID de destination). Pour les deux derniers cas, l'adresse IP de destination utilisée pour le Map-Request est l'une des adresses RLOC du Locator-Set de l'entrée Map-Cache. L'adresse source est une adresse RLOC IPv4 ou IPv6, selon que le Map-Request utilise un en-tête IPv4 ou IPv6. Dans tous les cas, le numéro de port source UDP du message Map-Request est une valeur de 16 bits choisie par l'ITR/PITR et le numéro de port UDP de destination est défini sur le numéro de port de destination bien connu 4342. Un Map-Reply réussi (c'est-à-dire un Map-Reply avec un nonce correspondant au nonce d'un Map-Request en attente) mettra à jour l'ensemble de RLOCs mis en cache associés à la plage EID-Prefix.
Un ITR DOIT remplir un ou plusieurs champs ('ITR-RLOC-AFI', 'ITR-RLOC-Address') du Map-Request. Le nombre de champs encodés (moins 1) DOIT être placé dans le champ 'IRC'. Un ITR peut inclure tous ses localisateurs configurés localement dans cette liste ou ne fournir qu'une seule adresse de localisateur pour chaque famille d'adresses qu'il prend en charge. Si un ITR omet par erreur de fournir une adresse ITR-RLOC, le Map-Replier DOIT abandonner le Map-Request.
Un Map-Request peut également être encapsulé LISP lors de son envoi d'un ITR à un Map-Resolver en utilisant le port UDP de destination 4342 avec la valeur de type LISP définie sur "Encapsulated Control Message". De même, un Map-Request est encapsulé LISP de la même manière lorsqu'il est envoyé d'un Map-Server à un ETR. Voir [RFC6833] pour plus de détails sur l'encapsulation des Map-Requests et des Map-Resolvers.
Les Map-Requests DOIVENT être limités en débit. Il est RECOMMANDÉ de ne pas envoyer de Map-Request pour le même EID-Prefix plus d'une fois par seconde.
Un ITR qui est configuré avec des informations de base de données de mappages (c'est-à-dire qu'il est aussi un ETR) peut choisir d'inclure ces mappages dans un Map-Request. Lorsqu'un ETR qui est configuré pour accepter et vérifier de telles données de mappage "piggybacked (transportées)" reçoit un tel Map-Request et n'a pas ce mappage dans son map-cache, il peut initier un "verifying Map-Request (Map-Request de vérification)" qui est envoyé à l'ITR qui a demandé le mappage, et l'ETR peut ajouter une entrée Map-Cache. Si l'ETR a une entrée Map-Cache qui correspond à l'EID "piggybacked" et que le RLOC est dans le Locator-Set de cette entrée, alors il peut envoyer le "verifying Map-Request" directement à la source du Map-Request d'origine. Si le RLOC n'est pas dans le Locator-Set, alors l'ETR DOIT envoyer le "verifying Map-Request" à l'EID "piggybacked". Cela force le "verifying Map-Request" à passer par le système de base de données de mappages pour atteindre la source d'information faisant autorité sur cet EID, empêchant ainsi l'usurpation de RLOC dans les données de mappage "piggybacked".