Résumé

  • RFC 5142 crée le type 12 de l’en-tête Mobility afin qu’un agent d’ancrage autorisé demande à un nœud mobile d’en acquérir un autre.
  • La décision de déclencher le déplacement reste hors protocole : maintenance et équilibrage sont des motifs possibles, non des vérités encodées dans le message.
  • Le message peut proposer une liste ordonnée d’agents alternatifs ; une liste vide impose une procédure de découverte.
  • IPsec protège l’origine et l’intégrité du message, mais ne certifie ni la capacité de la destination ni la réussite du nouveau chemin.
  • Lorsque l’expéditeur est l’agent courant, la mise à jour d’association qui supprime l’ancienne association sert d’accusé de réception.
  • Cet accusé prouve une sortie du contrôle ancien, pas une arrivée dans un service nouveau.
  • Découverte, choix, amorçage de sécurité, nouvelle association, tunnel et trafic observable forment des reçus séparés.
  • Après expiration des retransmissions, l’ancien agent ne doit pas déduire l’état du mobile et continue normalement le service jusqu’à la fin de vie de l’association.
  • Le rythme des messages doit dépendre des ressources du nouvel agent ou rester très inférieur à sa capacité d’admission ; la valeur par défaut est un message par seconde.
  • Un changement de préfixe d’origine peut modifier l’adresse d’origine et rompre les connexions existantes.
  • Même une nouvelle association acceptée reste une preuve du plan de contrôle, non une mesure de continuité applicative.
  • La gouvernance doit conserver l’ancien chemin aussi longtemps que possible et ne déclarer la migration achevée qu’après des preuves de trafic et de service.

Le silence ne raconte pas une histoire unique

Le scénario le plus instructif commence sans réponse. Un agent d’ancrage envoie un message Home Agent Switch, attend cinq secondes, recommence, puis allonge progressivement l’intervalle jusqu’à vingt secondes. Le mobile ne renvoie pas la mise à jour d’association attendue. Le système d’orchestration aimerait conclure : le mobile est parti, on peut fermer l’ancienne association.

RFC 5142 refuse cette conclusion. Après le délai maximal, si l’association existe encore, l’agent ne devrait rien inférer sur l’état du nœud. Il devrait continuer à le servir jusqu’à l’expiration normale de l’association. Le texte laisse même la possibilité de poursuivre les retransmissions à un rythme plus lent pendant une durée indéfinie.

Cette règle est une discipline de preuve. Le silence peut signifier une perte du message, une perte de la réponse, une indisponibilité du mobile, un échec de découverte, un blocage lors de l’établissement des clés, un refus par le nouvel agent ou une décision locale de ne pas avancer. Le même symptôme observable correspond à plusieurs états du monde. L’automatisation ne doit pas en choisir un par commodité.

Une instruction minimale, plusieurs décisions locales

Le message défini par RFC 5142 porte le type 12 de l’en-tête Mobility. Son rôle est étroit : demander au nœud mobile de cesser d’utiliser son agent courant et d’en acquérir un autre. La maintenance, la surcharge, l’équilibrage fonctionnel ou le renumérotage peuvent motiver cette demande. Le choix du moment et du groupe de mobiles à déplacer appartient au système d’exploitation local ; le protocole ne le prescrit pas.

L’expéditeur peut fournir des adresses IPv6 d’agents alternatifs. Les préférences Mobile IPv6 donnent l’ordre de tentative et les adresses de préférence égale sont mélangées. Si le premier agent ne peut pas assurer le service, le mobile essaie les suivants. Une liste de longueur nulle signifie qu’il doit lancer la découverte d’un agent.

Cette structure n’est ni une réservation ni une admission. Elle dit où regarder, pas ce que la destination promet. Un agent figurant en tête peut manquer de ressources, refuser l’association ou ne pas être joignable par le chemin du mobile. La liste matérialise une intention de coordination et laisse le résultat aux échanges ultérieurs.

L’option Binding Refresh Advice ajoute une échéance avant suppression de l’association courante, exprimée par unités de quatre secondes. Une échéance bien transmise ne garantit pas que la découverte, l’amorçage et l’enregistrement se termineront avant elle. Elle rend seulement le risque temporel observable.

Une enveloppe authentique ne garantit pas son objectif

Le message est protégé par la relation IPsec entre l’agent et le mobile. L’intégrité ESP est requise ; le chiffrement peut protéger la confidentialité de la liste des alternatives. L’expéditeur n’est pas nécessairement l’agent courant, à condition de posséder l’association de sécurité nécessaire. Dans ce cas, il proposera normalement sa propre adresse comme nouvelle destination.

L’authentification apporte une provenance cryptographique au message. Elle aide à répondre à « qui a envoyé ces octets protégés ? » et « ont-ils été modifiés ? ». Elle ne répond pas à « la cible a-t-elle encore de la place ? », « sa route est-elle utilisable ? », « acceptera-t-elle ce mobile ? » ou « l’application conservera-t-elle sa session ? ».

La différence n’est pas philosophique. Une politique peut sélectionner la mauvaise cohorte tout en envoyant des messages parfaitement intègres. Une cible peut être saine au moment de la décision puis saturée par les arrivées simultanées. Un mécanisme de sécurité protège l’instruction ; il ne transforme pas une prévision de ressources en état réel.

L’accusé porte deux sens incompatibles avec un compteur unique

Lorsque l’agent courant émet le changement, le mobile cesse de l’utiliser et lui adresse une Binding Update qui supprime l’ancienne association. RFC 5142 précise que cette mise à jour « agit comme » l’accusé de réception du message. L’ancien agent sait alors que son instruction a été traitée jusqu’à ce point.

Si le message vient d’un agent qui n’était pas courant, c’est la Binding Update destinée à créer une association avec cet expéditeur qui joue le rôle d’accusé. Le premier cas confirme une suppression à l’ancien bord ; le second signale une tentative d’entrée au nouveau bord. Leur donner le même statut réussi efface précisément ce que l’opérateur doit savoir.

La création peut être refusée. L’acceptation peut précéder l’installation complète du tunnel. Le tunnel peut exister sans transporter de paquets utiles. Les paquets peuvent passer tandis qu’une connexion existante échoue après un changement d’adresse. Le modèle d’état doit donc conserver au moins les événements suivants : ancienne association supprimée, nouvelle association demandée, réponse acceptée, tunnel installé, premier paquet observé, continuité applicative vérifiée.

Une Binding Acknowledgement du protocole de base donne un résultat au contrôle d’association. Elle est importante mais ne voit ni le transit complet ni l’état de l’application. Le reçu ne doit jamais revendiquer davantage que son observateur.

Le « milieu » du transfert est tout le travail

Sans liste utilisable, le mobile doit découvrir un agent. RFC 5026 sépare les éléments nécessaires au démarrage de Mobile IPv6 : adresse d’agent, adresse d’origine, informations d’autorisation et associations de sécurité IPsec. RFC 6610 et RFC 6611 fournissent des mécanismes de découverte ou de configuration. RFC 4640 présente l’amorçage comme un problème composé, et non comme un effet automatique du message de changement.

Un transfert vérifiable exige donc une chaîne : choix d’une alternative admissible ; maintien ou attribution de l’adresse d’origine ; établissement IKE/IPsec ; nouvelle Binding Update ; Binding Acknowledgement acceptable ; installation des routes et du tunnel ; observation de paquets ; contrôle de l’effet sur le service. Aucun maillon précédent ne remplace le suivant.

Le préfixe mérite une alerte spécifique. Une alternative située sur un autre préfixe d’origine peut conduire à changer l’adresse d’origine. Les connexions établies risquent alors de disparaître alors même que la nouvelle association est valide. Le RFC déconseille ce cas et privilégie, pour l’équilibrage, des agents partageant les mêmes préfixes. La continuité d’adresse est une condition d’expérience, pas une simple propriété de l’enregistrement.

La cadence de départ doit écouter la capacité d’arrivée

Un ancien agent peut produire les messages plus vite qu’un nouvel agent ne peut créer des associations, établir des sécurités et installer des tunnels. RFC 5142 demande soit une boucle de retour sur les ressources de la destination, soit une limite très inférieure au rythme d’acceptation réel. La limite maximale par défaut est d’un message par seconde.

Cette prescription révèle le bon centre de contrôle : pas le débit d’émission, mais la capacité d’admission. La mesure utile combine file d’attente IKE, refus d’association, charge de création des tunnels, échecs de découverte et premier trafic. Elle peut réduire ou arrêter le départ avant que l’ancien chemin ne soit abandonné.

Une destination peut aussi être disponible tout en offrant un chemin plus lent, plus instable ou plus sujet au réordonnancement. Le transfert réussit alors sur le plan administratif et détériore le transport. L’observation du trafic doit inclure les caractéristiques du chemin, pas seulement son existence.

Sources

  1. RFC 5142, version HTML
  2. RFC 5142, version texte
  3. Notice du RFC Editor
  4. Fiche IETF Datatracker
  5. Historique du document
  6. Recherche d’errata RFC 5142
  7. Registre IANA des paramètres de mobilité
  8. RFC 3775 : prise en charge de la mobilité IPv6
  9. RFC 6275 : prise en charge de la mobilité IPv6
  10. RFC 4301 : architecture de sécurité IP
  11. RFC 4303 : Encapsulating Security Payload
  12. RFC 4877 : Mobile IPv6 avec IKEv2 et IPsec
  13. RFC 5026 : amorçage de Mobile IPv6
  14. RFC 6611 : amorçage Mobile IPv6, scénario intégré
  15. RFC 6610 : options DHCP de découverte des informations d’origine
  16. RFC 4640 : problème de l’amorçage Mobile IPv6
  17. RFC 4192 : renumérotation des réseaux IPv6
  18. Spécification initiale minimale, décision future localisée et adoption volontaire
  19. Sur les couches de réalité et le pouvoir symbolique
  20. Primauté du code exécutable