Résumé

  • Avec RFC 3963, un routeur mobile pouvait déplacer le point de rattachement de plusieurs préfixes tout en laissant les nœuds du réseau ignorer la mobilité ; l’acquittement positif portant le drapeau R attestait le traitement et le transfert par l’agent mère, pas la joignabilité individuelle.
  • Le mode explicite, le mode implicite et le routage dynamique reposaient sur des preuves différentes. L’exploitation doit donc séparer l’autorisation du préfixe, la route installée, l’état du tunnel, le test du nœud et le résultat applicatif.

Un autocar peut emporter un petit réseau : terminaux, capteurs, écrans, serveurs. À l’intérieur, rien n’oblige ces machines à changer d’adresse lorsque le véhicule quitte un accès et en rejoint un autre. Le routeur qui les relie au monde porte le déplacement pour toutes. Tel est le raccourci proposé par RFC 3963, norme publiée en janvier 2005 sous le nom de NEMO Basic Support.

Loin de son réseau d’origine, le routeur mobile obtenait une adresse temporaire, ou Care-of Address. Il envoyait à son agent mère une Binding Update portant le drapeau R. L’agent associait alors l’adresse mère du routeur à cette adresse temporaire et établissait le transfert pour les préfixes du réseau mobile. Un tunnel bidirectionnel reliait l’agent mère à la nouvelle position. Les nœuds internes gardaient leur vue locale.

Le raccourci fonctionnait parce que sa portée était soigneusement limitée. Un Binding Acknowledgement de statut zéro, avec R, autorisait le routeur mobile à considérer que la mise à jour avait été traitée et que le transfert des préfixes était en place. Il ne disait pas qu’un capteur répondait, qu’une connexion TCP avait survécu ou qu’un utilisateur avait accès à une application. Il décrivait une opération du plan de contrôle.

Un bit ne devient pas une identité

Le drapeau R demandait un traitement de routeur mobile. L’agent mère ne le renvoyait positivement qu’en réponse à une demande qui le portait. Mais ce bit n’authentifiait personne. RFC 3963 exigeait la protection IPsec de la signalisation entre le routeur mobile et l’agent mère. L’association de sécurité prouvait l’origine attendue ; le drapeau indiquait ce que cette origine demandait.

Cette séparation évite une confusion classique : transformer le contenu d’un message en pouvoir général. Pour pouvoir reconstruire la décision, il faut conserver l’adresse mère, l’adresse temporaire, le numéro de séquence, la durée de vie, les drapeaux H et R, l’association IPsec, les options de préfixe et l’acquittement exact. Aucun de ces éléments, même réuni aux autres, n’observe directement tous les appareils derrière le routeur.

RFC 3775 définissait le Mobile IPv6 contemporain pour un hôte ; RFC 6275 en a ensuite révisé le socle. RFC 3963 étendait ce mécanisme à un réseau situé derrière le point mobile. Le gain était collectif, mais la preuve restait celle d’une liaison.

Le préfixe pouvait venir de trois registres

En mode explicite, la Binding Update contenait une ou plusieurs options Mobile Network Prefix. L’agent mère pouvait les confronter à une Prefix Table indiquant les préfixes autorisés pour ce routeur. La règle était atomique : si le transfert ne pouvait être établi pour chaque préfixe annoncé, aucun ne devait être transféré et la réponse portait le statut 141. Un préfixe non autorisé entraînait le statut 142.

Ce tout-ou-rien empêchait un acquittement ambigu de masquer un réseau à moitié déplacé. En revanche, une concordance avec la table ne disait toujours rien sur l’état présent des machines utilisant les adresses de ce préfixe. Elle prouvait l’autorisation de la revendication.

En mode implicite, aucune option de préfixe n’apparaissait dans la demande. L’agent mère puisait l’information dans une configuration préalable. Sans cette information, il devait répondre 143. Deux acquittements visuellement semblables pouvaient donc s’appuyer sur des preuves différentes : des octets dans le message courant ou une donnée administrative maintenue ailleurs. L’audit doit consigner le mode, l’origine et la version de cette donnée.

Un protocole de routage dynamique dans le tunnel formait un troisième chemin. Il adaptait la connaissance des routes mais pouvait exposer la topologie interne ; le texte recommandait la confidentialité ESP pour ces échanges. Dire seulement « la route existe » efface donc une question essentielle : route statique, option explicite, configuration implicite ou annonce apprise ?

RFC 3963 relevait lui-même la limite des routes statiques. Elles réduisaient la signalisation, mais pouvaient subsister alors que le routeur mobile correspondant n’était plus joignable. Une table de routage peut être exacte quant à l’intention et fausse quant à la vie présente.

La transparence concentrait le chemin

Dans le support de base, le trafic des nœuds mobiles vers leurs correspondants passait par l’agent mère. Pour le trafic descendant, celui-ci encapsulait le paquet à destination de la Care-of Address. Le routeur vérifiait l’origine externe comme étant l’agent mère, sauf protection équivalente par IPsec en mode tunnel, puis vérifiait que la destination interne appartenait à un préfixe mobile.

Dans l’autre sens, le routeur rejetait les sources internes étrangères à ses préfixes et l’agent mère effectuait à son tour un contrôle topologique. Ce filtrage bornait les adresses utilisables. Il ne constituait ni une attestation d’appareil ni une autorisation applicative.

Le support de base ne définissait pas l’optimisation des routes pour ces préfixes. Des routeurs mobiles imbriqués pouvaient former un arbre, mais aussi empiler les tunnels. RFC 4885, RFC 4886 et RFC 4887 ont cadré la terminologie, les objectifs et les problèmes. RFC 4888 a analysé l’optimisation, et RFC 4889 son espace de solutions. Le simple transfert n’était donc pas synonyme de chemin optimal.

Les extensions ultérieures ont ajouté d’autres décisions : RFC 5488 et RFC 6276 traitent de délégation DHCPv6 de préfixes dans l’environnement NEMO ; RFC 6089 décrit les flow bindings. Ces mécanismes enrichissent la chaîne de contrôle, sans transformer l’acquittement initial en sonde universelle.

Pour la provenance historique, la notice du RFC Editor, la recherche d’errata, la fiche Datatracker et le registre IANA Mobility Parameters consignent statut, corrections signalées et valeurs attribuées. Une valeur enregistrée coordonne l’interopérabilité ; elle ne prouve ni le déploiement ni la bonne exécution locale.

Le bon journal d’exploitation ne cherche donc pas une case verte unique. Il relie la détection de mouvement, les deux adresses, le message et ses options, la provenance des préfixes, la décision atomique, l’acquittement, l’association IPsec, le tunnel, les routes créées ou retirées, les filtres, les tests par préfixe, les sondes de nœuds et les résultats de session. La mobilité devient transparente pour l’usager sans devenir opaque pour l’opérateur.

RFC 3963 a déplacé beaucoup de choses avec peu de signalisation. Sa leçon durable est de ne jamais laisser cette économie de signaux devenir une inflation de preuve.

Sources