Résumé

  • Pour L2-LinkDisconnect comme pour L2-LinkConnect, l’ACK immédiat de RFC 5184 autorise le début de l’opération ; il ne certifie ni sa fin, ni la disponibilité de l’autre chemin.
  • Une bascule sûre garde l’ancien lien jusqu’à un point de validation explicite et journalise séparément décision, commande, état L2, convergence L3 et trafic observé.

Le contrôleur reçut un ACK de déconnexion et rendit aussitôt les ressources de l’ancien accès. Quelques millisecondes plus tard, la nouvelle association n’était toujours pas utilisable. Il n’existait plus de chemin de retour, mais le journal affirmait que la bascule était terminée.

RFC 5184 dit autre chose. Pour une primitive de type 3, Request demande une opération et Confirm répond immédiatement par Ack ou Nack. L’opération commence après l’Ack. La fin du changement de lien donne lieu à un événement distinct. Supprimer cette distance revient à inventer une transaction atomique que l’interface n’offre pas.

Une grammaire de coordination, pas une transaction distribuée

Le document est expérimental et provient du groupe de recherche MobOpts. Son objectif est de faire circuler entre L2 et L3 assez d’information locale pour préparer plus tôt un handover. Il définit quatre classes : Request, Confirm, Indication et Response.

Les primitives de type 1 répondent à une lecture immédiate : état du lien ou liste des points d’attachement. Les primitives de type 2 enregistrent un abonnement, puis signalent de manière asynchrone l’apparition ou la disparition d’un PoA, la montée ou la chute du lien et le franchissement d’un seuil. Les primitives de type 3 commandent connexion ou déconnexion.

Cette structure rend visible la causalité. Confirm répond à Request. Indication signale un événement ultérieur. Response, lorsqu’elle est utilisée, acquitte l’Indication. Aucun de ces messages ne doit porter rétrospectivement le sens d’un autre.

L’ACK ne donne pas le droit de détruire le chemin de secours

L2-LinkDisconnect.confirm(Ack) signifie que la requête est valide et que le travail peut commencer. L’ancien lien peut encore transporter des trames, être en cours de désauthentification ou attendre une transition propre au pilote. Symétriquement, l’Ack de connexion ne prouve pas que le nouveau lien soit disponible.

Le scénario de RFC 5184 conserve l’ordre : L3 émet LinkConnect, L2 confirme, le handover L2 commence, puis LinkUp est indiqué lorsque ce handover se termine. L3 exécute ensuite ses propres opérations. La continuité applicative est encore un autre contrôle.

Une politique make-before-break doit donc définir son point de commit. Ce peut être une association authentifiée, une adresse validée, une route active et un échange bidirectionnel réussi. Avant ce point, la nouvelle voie est candidate ; l’ancienne reste un mécanisme de récupération. Après ce point, la libération devient justifiable.

Même LinkUp a un sens local

RFC 5184 précise que « lien connecté » dépend de la technologie. Pour son exemple IEEE 802.11, LinkUp correspond à l’association avec le point d’accès. RFC 4907 prévient que LinkUp ne garantit ni symétrie, ni faible perte, ni changement de configuration IP.

RFC 4957 montre pourquoi une traduction universelle est dangereuse. Sur Ethernet, le signal physique peut être positif alors qu’un domaine de pontage ne transmet pas encore. L’hôte ne reçoit pas nécessairement un événement indiquant que le calcul spanning tree est achevé. Une indication peut même être réémise ou retirée.

Le modèle d’exploitation doit donc conserver la définition propre à chaque technologie, pilote et version. Un même mot d’état n’est comparable que si sa frontière d’émission est comparable.

Les seuils annoncent une hypothèse, non une obligation

Condition résume bande passante disponible et qualité en cinq niveaux. Les algorithmes dépendent du matériel et du logiciel ; les niveaux d’un équipement sont indépendants de ceux d’un autre. Le RFC reconnaît que choisir avec ces métriques est sujet à erreur et ne garantit pas le meilleur lien.

Les essais ont observé des handovers en ping-pong. Un seuil mal adapté produit des indications trompeuses. L2-LinkStatusChanged peut déclencher un déplacement redondant ; la recommandation est de relire l’état et d’annuler lorsque l’accès actuel demeure préférable.

RFC 4907 formule la discipline générale : traiter l’indication comme un indice à valider, non comme un ordre. Une politique réversible peut agir vite sans donner à une mesure bruitée le pouvoir de démanteler immédiatement le dernier chemin fonctionnel.

L’attaquant peut fabriquer le début de la chaîne

Des balises forgées peuvent faire apparaître un point d’attachement malveillant et déclencher PoAFound. Le mobile peut ensuite demander une connexion vers ce point. Des signaux forts et faibles alternés peuvent faire osciller PoAFound et PoALost jusqu’au déni de service.

La primitive reste conforme : elle rapporte ce que L2 a observé. L’autorité manque ailleurs. Il faut lier découverte, authentification, identité du pilote, politique d’admission et résultat de reachability. La limitation de débit et l’amortissement réduisent le coût des observations adverses.

Mesurer chaque intervalle empêche le récit de s’effondrer

L’expérience décrite dans RFC 5184 observe zéro ou une réponse ICMP perdue avec des requêtes espacées de dix millisecondes. Ce résultat est une mesure de banc, pas une promesse de flotte. RFC 5568 rappelle d’ailleurs que l’optimisation Mobile IPv6 vise la latence des opérations IP et non le délai de commutation du lien.

Le dossier doit donc mesurer séparément trigger-vers-Request, Request-vers-Ack, Ack-vers-LinkUp, LinkUp-vers-IP-prêt et IP-prêt-vers-premier échange de service. Il conserve le PoA, les mesures brutes, les seuils, l’authentification, les routes, les paquets perdus et les actions de retour.

Le véritable objectif n’est pas d’attendre une certitude parfaite. Il est de savoir quel acteur possède l’autorité à chaque étape et quelle preuve lui permet de la transmettre. L’Ack peut lancer le travail ; seul le résultat observé peut fermer le dossier.

Sources

  1. RFC 5184 — HTML
  2. RFC 5184 — texte brut
  3. Page d’information RFC Editor
  4. Fiche IETF Datatracker
  5. Historique IETF Datatracker
  6. Références IETF Datatracker
  7. Errata de RFC 5184
  8. RFC 4907 — implications architecturales des indications de lien
  9. Page d’information de RFC 4907
  10. RFC 4957 — notifications L2 et détection d’attachement
  11. RFC 5568 — handovers rapides Mobile IPv6
  12. Page d’information de RFC 5568
  13. RFC 5944 — mobilité IPv4
  14. RFC 6275 — mobilité IPv6
  15. RFC 4140 — mobilité IPv6 hiérarchique
  16. RFC 3819 — conseils aux concepteurs de sous-réseaux
  17. RFC 4968 — analyse des modèles de lien IPv6
  18. Heng Lu — couches de réalité
  19. Heng Lu — spécification minimale et adoption volontaire
  20. Heng Lu — primauté du code en fonctionnement