6.1.5. EID-to-RLOC UDP Map-Reply Message (Message UDP Map-Reply EID vers RLOC)
6.1.5. EID-to-RLOC UDP Map-Reply Message (Message UDP Map-Reply EID vers RLOC)
L'EID-Prefix retourné dans un Map-Reply et sa longueur de préfixe sont inférieurs ou égaux à l'EID demandé. L'EID demandé provient du champ de destination de l'en-tête IP d'un Data-Probe ou de l'enregistrement EID d'un Map-Request. Les RLOCs dans le Map-Reply sont les adresses IP globalement routables de tous les ETRs du site LISP. Chaque RLOC transmet la joignabilité de l'état mais ne transmet pas la joignabilité du chemin du point de vue du demandeur; la joignabilité du chemin doit être déterminée séparément, voir la section 6.3.
La granularité de l'EID-Prefix (préfixe + longueur) contenue dans un Map-Reply peut différer du Map-Request qui l'a déclenché. Par exemple, lorsqu'un Map-Request est effectué pour un préfixe retourné dans un Map-Reply précédent, le demandeur met à jour son cache avec la nouvelle information de préfixe et la granularité. Par exemple, lorsqu'un demandeur a deux entrées EID-Prefix en cache qui sont couvertes par un préfixe plus grossier dans le Map-Reply, il remplace les entrées par le EID-Prefix plus grossier. Inversement, un préfixe plus grossier peut également être remplacé par plusieurs préfixes plus fins, mais au lieu de supprimer l'entrée plus grossière, les préfixes plus fins sont ajoutés et lors de la recherche, les entrées plus fines remplacent l'entrée plus grossière.
Lorsqu'un ETR est configuré avec des EID-Prefixes qui se chevauchent, un Map-Request pour un EID qui correspond le mieux à l'un des EID-Prefixes DOIT être retourné dans un seul message Map-Reply. Par exemple, si les entrées de mappage de base de données de l'ETR sont:
10.0.0.0/8 10.1.0.0/16 10.1.1.0/24 10.1.2.0/24
Un Map-Reply pour l'EID 10.1.1.1 aurait un Record Count de 1, où l'enregistrement de mappage EID-Prefix serait 10.1.1.0/24.
Un Map-Reply pour l'EID 10.1.5.5 aurait un Record Count de 3, où les enregistrements de mappage seraient 10.1.0.0/16, 10.1.1.0/24 et 10.1.2.0/24.
Tous les EID-Prefixes qui se chevauchent n'ont pas besoin d'être retournés, seules les entrées plus fines par rapport à l'EID-Prefix correspondant à l'EID demandé sont retournées (dans le deuxième exemple, 10.0.0.0/8 n'a pas été retourné lors de la demande pour 10.1.5.5). Lorsque plusieurs EID-Prefixes sont retournés, tous DEVRAIENT utiliser le même Time to Live afin qu'ils expirent en même temps. Lorsqu'un EID-Prefix plus fin est reçu ultérieurement, l'enregistrement Map-Reply de son TTL peut être stocké même s'il existe une entrée plus grossière. Lorsqu'un EID-Prefix plus grossier est reçu ultérieurement, son temps d'expiration de map-cache DEVRAIT être défini sur le temps d'expiration minimum de tous les EID-Prefixes plus fins dans le map-cache pour maintenir l'intégrité de l'ensemble EID-Prefix et éviter de supprimer les entrées plus fines tout en conservant l'entrée plus grossière.
Les Map-Replies DEVRAIENT être envoyés pour le même EID-Prefix au plus une fois par seconde au même routeur demandeur. Pour l'évolutivité, il est attendu que les adresses EID soient agrégées dans des EID-Prefixes afin qu'un seul Map-Reply puisse satisfaire un mappage pour plusieurs EIDs dans la plage de préfixe, réduisant ainsi les Map-Requests.
Un enregistrement Map-Reply peut avoir un Locator-Set vide. Un Map-Reply négatif est un Map-Reply avec un Locator-Set vide qui transmet des actions spéciales à l'ITR ou PITR qui demande le Map-Reply de l'expéditeur. Les utilisations principales incluent: un Map-Resolver indiquant si la destination appartient à un site LISP ou à un site non-LISP, et la suppression de source pour les Map-Requests vers des EIDs non attribués.
Dans chaque enregistrement Map-Reply, l'ordre de la liste des localisateurs dans le Locator-Set DOIT être le même pour chaque ETR qui initie un Map-Reply. Le Locator-Set DOIT être trié en ordre croissant d'adresse IP, où les adresses de localisateur IPv4 sont numériquement "inférieures" aux adresses de localisateur IPv6.
Lors de l'envoi d'un Map-Reply, l'adresse de destination est copiée de l'un des champs ITR-RLOC du Map-Request. L'ETR peut choisir une adresse de localisateur parmi la famille d'adresses qu'il prend en charge. Pour un Data-Probe, l'adresse de destination du Map-Reply est copiée de l'adresse source du message Data-Probe qui a déclenché la réponse. L'adresse source du Map-Reply est l'une des adresses IP locales choisies de manière à ce que la vérification Unicast Reverse Path Forwarding (uRPF) du fournisseur de services en amont réussisse. Le port de destination du Map-Reply est copié du port source du Map-Request ou du Data-Probe, et le port source est défini sur le port UDP bien connu 4342.
6.1.5.1. Traffic Redirection with Coarse EID-Prefixes (Redirection du trafic avec des EID-Prefixes grossiers)
Lorsqu'un ETR est mal configuré ou compromis, il peut retourner un EID-Prefix grossier dans un Map-Reply qui couvre les préfixes attribués à d'autres sites, redirigeant leur trafic vers les localisateurs du site compromis.
Deux approches de solution sont principalement envisagées. La première consiste à faire en sorte que le Map-Server réponde aux Map-Replies au nom de l'ETR, de sorte que ce qui est retourné soient les EID-Prefixes enregistrés; la protection entre l'ETR et le Map-Server utilisant une clé partagée facilite la détection des anomalies de l'ETR. La seconde consiste à faire en sorte que les ITRs et PITRs ne mettent en cache que les EID-Prefixes dont la longueur de masque est supérieure ou égale à une longueur de préfixe configurée, limitant les dommages de l'annonce de largeurs de préfixe arbitraires à une plage spécifique, mais nécessitant une coordination avec l'attribution des préfixes de site. Les deux approches peuvent être utilisées indépendamment ou simultanément.
Au moment de la rédaction, d'autres solutions sont encore à l'étude et à la considération.