Résumé

  • En mode prédictif, l’ancien routeur peut accepter le FBU, préparer un tunnel vers le nouveau routeur et y faire tamponner des paquets avant même que le nœud mobile ait quitté son lien.
  • L’attachement, le résultat de DAD ou l’attribution d’une autre NCoA, le traitement de l’UNA, la vidange du tampon, la réception des paquets et la continuité de l’application sont des preuves distinctes.

L’avance temporelle est le produit — et le piège

Le principe de FMIPv6 n’est pas mystérieux : déplacer en amont les opérations IP qui ralentissent une mobilité. Le terminal découvre un point d’accès possible, obtient les coordonnées de son routeur, construit une adresse potentielle et demande que le trafic soit redirigé. Le chemin futur peut donc exister avant le déplacement physique.

Cette avance est précisément ce que l’optimisation vend. Elle est aussi ce qui rend un mauvais tableau de bord si crédible. Dès que le tunnel passe au vert, l’interface peut conclure « terminal déplacé ». Or RFC 5268 exclut explicitement le temps de commutation du lien de son optimisation. Le signal radio qui déclenche la prédiction et la réussite de l’attachement restent hors de son champ.

RFC 5568 a ensuite rendu RFC 5268 obsolète. Il faut le citer pour une mise en œuvre actuelle, sans perdre la leçon de contrôle : le chemin préparé est une anticipation, pas un constat de présence.

PrRtAdv répond à « où préparer », pas à « où est le terminal »

Le nœud mobile envoie éventuellement un RtSolPr à son routeur précédent avec un ou plusieurs identifiants de points d’accès. Le PrRtAdv associe ces AP-ID à des informations de routeur : adresse de couche liaison, adresse IP et préfixe de l’interface envisagée. Cela suffit à fabriquer une NCoA prospective.

Mais le mécanisme qui a désigné le point d’accès est propre à la liaison et n’est pas défini par la norme. Le terminal peut choisir une autre cellule, échouer à s’y associer ou ne pas se déplacer. L’enregistrement doit donc dire « candidat résolu lors de la génération G », jamais « terminal au NAR ».

La génération est indispensable. Deux tentatives peuvent viser le même routeur et le même préfixe. Sans identifiant de tentative, les traces de la première préparation deviennent à tort les pièces justificatives de la seconde.

FBack clôt une préparation, pas une traversée radio

Dans le scénario prédictif, le FBU part pendant que le mobile est encore relié au PAR. Il lie la PCoA à la NCoA pressentie et demande la redirection. L’option FMIPv6 Binding Authorization Data prouve au PAR que l’émetteur peut agir pour l’ancienne adresse.

Le PAR échange ensuite HI et HAck avec le NAR. Celui-ci peut accepter l’adresse, en attribuer une autre ou refuser. Un FBack reçu sur l’ancien lien indique que le traitement et le tunnel sont engagés. Il ne contient aucune preuve que la couche liaison a basculé.

Le mode réactif montre la différence de manière encore plus nette. Lorsque l’attachement a lieu avant la fin de la préparation, ou lorsqu’aucun FBack n’est arrivé avant le départ, le mobile envoie une UNA sur le nouveau lien puis émet ou réémet le FBU. Sans FBack préalable, il ignore si le PAR avait traité la première demande.

HI/HAck est également une décision entre routeurs, sous une association de sécurité établie hors de la spécification. Ce contrôle protège la préparation ; il ne transforme pas les routeurs en capteurs de présence du terminal.

« La NCoA » désigne une lignée, pas une seule valeur

L’adresse construite à partir du préfixe n’est d’abord qu’une proposition. Le NAR peut effectuer une Duplicate Address Detection, accepter la proposition ou renvoyer une autre NCoA dans HAck/FBack. Après l’arrivée, un conflit peut encore conduire à NAACK et à un nouveau FBU.

RFC 5268 estime que la probabilité de collision peut être très faible, mais refuse de la confondre avec zéro. DAD ne peut être désactivée que par une politique de déploiement explicite, par exemple lorsque la gestion des adresses rend le risque négligeable. La prédiction n’est jamais une preuve d’unicité.

Un modèle d’audit doit conserver la proposition locale, le résultat DAD ou sa dérogation, l’éventuelle adresse attribuée par le routeur, l’adresse annoncée après attachement et celle utilisée ensuite par Mobile IPv6. Écraser cette histoire dans un champ unique prive l’organisation de la capacité à retirer l’autorité d’une ancienne valeur.

L’UNA autorise la remise ; elle ne confirme pas la réception

RFC 5268 formule lui-même la limite : le tunnel seul ne garantit pas que les paquets seront reçus après l’attachement si le NAR ne peut pas détecter la présence du mobile.

Une fois le lien établi, le mobile envoie une Unsolicited Neighbor Advertisement avec le bit Override à zéro. Le NAR peut alors retirer l’entrée proxy de son cache de voisins ou faire passer une entrée incomplète à STALE, puis libérer les paquets reçus dans le tunnel et conservés dans le tampon.

L’UNA est donc une preuve située du côté de l’attachement. Elle active une transition du cache et du tampon. Elle ne certifie ni la conservation de tous les paquets, ni leur réception par la pile du terminal, ni la survie d’une session applicative.

La chaîne réversible doit nommer chaque étape : lien établi, UNA reçue, entrée voisine modifiée, tampon ouvert, paquets émis, paquets reçus, application rétablie. « Handover terminé » ne doit être qu’une projection de ces faits, jamais leur substitut.

Le tampon peut déplacer la perte

Avant l’arrivée, les paquets tunnelisés au NAR doivent être tamponnés ou ils seront perdus. En mode réactif, une perte peut aussi se produire au PAR tant que le FBU n’a pas été pris en compte. Le tampon ne supprime donc pas magiquement la fenêtre ; il la gère.

Sa vidange a sa propre physique. Une rafale trop importante peut saturer le routeur, le lien ou le mobile et provoquer congestion, gigue et nouvelles pertes. RFC 5268 propose un rythme fondé sur le débit d’arrivée initial et autorise au plus cinq paquets consécutifs avant de cadencer la suite.

Il faut mesurer séparément l’admission, la plage conservée, le débordement, le déclencheur de libération, le débit de vidange, les paquets effectivement transmis et ceux réellement consommés. Une file vide prouve seulement qu’elle a été vidée.

RFC 5568 impose d’identifier la génération du protocole

RFC 5568 ne s’est pas contenté de remplacer un numéro. Il a déplacé HI et HAck des messages ICMPv6 définis dans RFC 5268 vers des messages Mobility Header. Une implémentation actuelle ne doit pas émettre l’ancien format, même si elle peut encore l’interpréter à la réception.

Une capture portant l’étiquette « HI » reste donc ambiguë sans format et génération. RFC 5268 demeure une source historique utile pour la frontière entre préparation et présence, mais pas une autorisation de déployer son encodage obsolète.

Après l’attachement, les obligations Mobile IPv6 ordinaires ne disparaissent pas non plus. La mise en place anticipée ne remplace ni Binding Update ni Return Routability selon la norme applicable.

Le code en fonctionnement est une succession de frontières

Dans la logique de Running-Code Primacy de Lu Heng, l’objet réel n’est pas la promesse « mobilité transparente ». C’est la suite effectivement exécutée : candidat, coordonnées de routeur, adresse prospective, autorisation FBU, décision inter-routeurs, tunnel et tampon, attachement, UNA, confirmation d’adresse, vidange, binding, réception et résultat applicatif.

Les couches de réalité ne sont pas interchangeables. Une prédiction n’est pas une préparation ; une préparation n’est pas un attachement ; un attachement n’est pas une adresse unique ; une possibilité de transférer n’est pas une livraison ; une livraison n’est pas une continuité de service.

Le handover rapide fonctionne parce qu’une couche prend de l’avance sur une autre. L’abstraction ne reste fiable que si cette distance reste visible et si toute conclusion peut revenir à la génération, au mode, à la lignée d’adresse et à la dernière frontière prouvée.

Sources