Résumé

  • La RFC 5380 confie au MAP une correspondance entre la RCoA, visible à distance, et la LCoA, qui change avec le point d’accès.
  • Le Binding Acknowledgement atteste l’acceptation de cette correspondance ; il ne démontre pas que le chemin encapsulé transporte effectivement le trafic jusqu’au service.

Le reçu est arrivé avant le service

Le scénario le plus instructif ne commence pas par une panne spectaculaire. Il commence par un message parfaitement conforme. Le mobile envoie une Binding Update locale. Le MAP authentifie l’échange, installe une association entre la Regional Care-of Address et la nouvelle adresse sur le lien, puis renvoie un Binding Acknowledgement valide. L’automate passe au vert.

Le premier paquet applicatif, lui, n’arrive pas.

Rien dans cette séquence n’oblige à conclure que la RFC a échoué. Elle oblige plutôt à nommer exactement ce qui a réussi. L’ancre a accepté un état de contrôle. Pour que le trafic suive, elle doit encore intercepter les paquets destinés à la RCoA, consulter la bonne entrée de cache, encapsuler vers la LCoA, disposer d’une route exploitable et transmettre un paquet compatible avec le MTU du tunnel. Le mobile doit le recevoir, le désencapsuler et le remettre à la couche supérieure.

Une seule réponse administrative ne couvre pas ces opérations.

La continuité reposait sur une substitution locale

HMIPv6 réduit les échanges avec le home agent et les correspondent nodes. Tant que le mobile reste dans le même domaine MAP, sa RCoA ne change pas. Seule l’association locale avec la LCoA doit être mise à jour. Pour les pairs distants, le déplacement disparaît.

Il ne disparaît pas pour l’infrastructure. Il devient une obligation locale. Le MAP est désormais chargé de rendre vraie une adresse que d’autres n’ont aucune raison de remettre en cause. La stabilité n’est donc pas une propriété autonome de la RCoA ; c’est le résultat d’un cache à jour, d’un tunnel disponible et d’une chaîne de temporisations cohérente.

La RFC impose justement une hiérarchie des durées. Le mobile devrait attendre l’accusé du MAP avant d’annoncer la RCoA ailleurs. La durée d’une association auprès du home agent ou d’un correspondent node ne doit pas dépasser celle de l’association locale. Autrement dit, la promesse extérieure ne peut pas survivre à sa condition intérieure.

Cette règle dépasse la mobilité. Toute architecture d’indirection devrait interdire à un objet public de rester « valide » plus longtemps que le mécanisme privé qui le réalise.

Une préférence n’est pas une mesure

Le choix d’un MAP se nourrit d’options reçues dans les Router Advertisements : adresse globale, préfixe, distance, préférence et durée de validité. Ces champs permettent au mobile de choisir selon une politique d’opérateur et une topologie annoncée.

La préférence n’est pas un débit mesuré. La distance n’est pas nécessairement le nombre de sauts réellement empruntés. Une durée non nulle ne constitue pas une sonde de santé. Elle dit seulement que l’annonce n’a pas déclaré l’ancre hors service.

La valeur zéro, au contraire, a une signification impérative : ce MAP ne doit plus être choisi, les associations existantes peuvent être considérées comme perdues, et le mobile doit chercher une autre ancre. S’il n’en existe aucune, il ne doit pas poursuivre en HMIPv6.

Le piège opérationnel consiste à transformer cette logique négative en preuve positive. Ne pas avoir reçu de retrait ne prouve ni la capacité de l’ancre, ni l’intégrité de son cache, ni la réussite du tunnel. Une plateforme d’observation doit garder côte à côte l’annonce de politique et les mesures du trafic, sans fabriquer l’une à partir de l’autre.

L’ancienne ancre conserve une dette

Lors d’un changement de domaine MAP, la RFC prévoit que le mobile puisse demander à l’ancienne ancre de faire suivre les paquets en transit vers la nouvelle localisation. Cette possibilité limite les pertes, mais elle ouvre une période où plusieurs états ont chacun une part de la continuité.

L’ancienne ancre possède une règle temporaire. La nouvelle possède la liaison actuelle. Le home agent et les pairs peuvent être en train d’apprendre une nouvelle RCoA. Chaque élément a son horloge. Une restriction administrative peut en outre interdire à l’ancien MAP de transférer hors de son domaine.

Pour reconstituer un incident, « handover terminé » est trop vague. Il faut savoir quand la nouvelle liaison a été acceptée, quand le premier paquet a traversé le nouveau tunnel, jusqu’à quand l’ancienne ancre a transféré, quand les associations extérieures ont changé et à quel instant l’application a retrouvé une transaction utile.

Le contrôle peut passer avec un MTU que les données ne supportent pas

La RFC 5380 attire explicitement l’attention sur l’encapsulation. Le trafic entrant et sortant passe dans un tunnel entre le mobile et le MAP. Lorsqu’un home agent intervient également, une double encapsulation peut réduire davantage la taille disponible pour les couches supérieures.

Un petit message de contrôle et son accusé peuvent donc réussir sur un chemin qui échoue pour des paquets applicatifs plus grands. Ce n’est pas la preuve d’un incident historique précis ; c’est une dépendance normative du modèle. Un exploitant qui ne mesure que le plan de contrôle ne voit pas les effets d’un mauvais calcul de MTU, d’un message Packet Too Big perdu ou d’une politique de filtrage incohérente.

La bonne unité d’observation associe l’état du binding à des paquets représentatifs. Elle ne déduit pas la capacité de transport de la seule présence d’une entrée.

La sécurité protège l’échange, pas toutes ses conséquences

Le lien entre mobile et MAP doit fournir authentification mutuelle, intégrité et protection contre le rejeu. Les mécanismes décrits autour d’IKEv2 et d’IPsec donnent une base robuste à l’acceptation du binding. Le MAP peut également refuser une LCoA qui ne correspond pas aux préfixes autorisés par l’opérateur.

Ces garanties n’élargissent pas silencieusement leur portée. Une mise à jour authentifiée n’atteste pas que le tunnel fonctionne. Une LCoA admise n’atteste pas la santé du lien radio. Un paquet protégé n’atteste pas que l’application l’a traité. Et le MAP n’a pas besoin de connaître l’adresse permanente du mobile pour exercer sa fonction locale.

La sécurité rend le reçu plus fiable ; elle ne le transforme pas en résultat de service.

Une décentralisation partielle reste une architecture d’ancrage

La RFC 7429 relit HMIPv6 comme une approche moins centralisée : un MAP local évite de remonter chaque mouvement vers une ancre lointaine. Mais l’analyse relève aussi les difficultés de découverte, sélection, déplacement de l’ancre et transfert de contexte. Multiplier les MAP réduit une concentration et augmente le nombre d’associations à maintenir.

La RFC 5380 permet au mobile d’utiliser plusieurs MAP et plusieurs RCoA pour des groupes de correspondants différents. Elle interdit toutefois d’enregistrer auprès d’un MAP une RCoA provenant d’un autre, car les encapsulations imbriquées dégraderaient l’efficacité. Une hiérarchie conforme peut encore produire un mauvais chemin.

Le progrès réel n’est donc pas l’absence d’ancre. C’est la réduction du périmètre de signalisation, contre une responsabilité locale plus forte.

Ce que la pratique doit prouver

La primauté du code en fonctionnement, telle que Heng Lu la formule, impose de distinguer l’enregistrement de son effet. La RCoA est un contrat de continuité. Le MAP, la LCoA, l’entrée de cache, l’association de sécurité, la route du tunnel et le MTU en sont l’exécution actuelle.

Une preuve exploitable doit suivre neuf reçus : découverte du MAP, décision de sélection, formation des adresses, acceptation du binding, persistance de l’état, interception et encapsulation, viabilité du chemin, traitement par le mobile, puis résultat applicatif. Aucun reçu ne doit emprunter le nom du suivant.

L’accusé était valide. Le service restait à démontrer.

Sources