Résumé

  • RFC 2002 permettait à un nœud mobile de conserver son adresse mère tout en enregistrant une adresse temporaire auprès de son agent mère ; la liaison de mobilité avait une durée de vie restante.
  • Une réponse d’enregistrement authentifiée et positive attestait l’acceptation d’une requête précise par l’agent mère, non la position physique, la livraison de bout en bout, la confidentialité ou un déploiement général.

Dans RFC 2002, la mobilité ne faisait pas suivre l’identité au point de raccordement. Le nœud gardait l’adresse mère sous laquelle ses correspondants le connaissaient, même loin de son réseau d’origine. La livraison reposait sur un autre objet : l’adresse temporaire, point terminal d’un tunnel et indication du contexte de raccordement courant.

Cette séparation trace une frontière probatoire nette. Le protocole pouvait établir qu’un agent mère avait accepté une instruction de réacheminement limitée dans le temps. Il ne transformait pas cette instruction en certificat géographique, en preuve de présence dans un bâtiment ni en reçu pour chaque paquet.

Une identité stable, une consigne périssable

La « liaison de mobilité » associait l’adresse mère, l’adresse temporaire et la durée restante. La première persistait ; la seconde pouvait changer. Elle appartenait soit à un agent étranger du réseau visité, soit au nœud mobile lorsqu’il obtenait une adresse temporaire colocalisée.

Les annonces d’agent aidaient le nœud à déterminer s’il était chez lui ou à l’extérieur, à trouver une adresse temporaire et à détecter un déplacement. Leur minuterie n’était toutefois pas celle de l’enregistrement. La durée ICMP concernait l’annonce ; la durée Mobile IP indiquait la limite proposée pour l’enregistrement. RFC 2005 précisait en outre que la découverte d’agents n’avait pas à être authentifiée. Entendre une annonce n’était donc pas recevoir un engagement authentifié de l’agent mère.

Cet engagement passait par une requête d’enregistrement comportant durée demandée, adresse mère, agent mère, adresse temporaire, identifiant de 64 bits et extensions. L’extension obligatoire Mobile-Home Authentication protégeait les échanges entre nœud et agent mère. L’identifiant devait être repris dans la réponse et servait à la protection contre le rejeu. La méthode par horodatage était obligatoire ; les nonces constituaient une solution optionnelle.

En acceptant une requête valide, l’agent mère créait ou modifiait la liaison. Les codes de succès 0 et 1 distinguaient notamment le cas des liaisons simultanées. La durée accordée pouvait être réduite, jamais augmentée. Zéro demandait la désinscription ; 0xffff signifiait l’infini. À l’expiration d’une durée finie, l’agent supprimait la liaison sans réponse spontanée.

Une réponse positive authentifiée, lue avec l’identifiant, les adresses et la durée, prouve donc l’acceptation et l’installation d’un état correspondant. Elle ne prouve pas la localisation physique : l’adresse temporaire désigne un terminal de tunnel ou un contexte de raccordement, pas la personne, la pièce ou la juridiction qui se trouve derrière.

Accepter, acheminer et recevoir

Après création de la liaison, le correspondant continuait d’envoyer vers l’adresse mère. L’agent mère interceptait les datagrammes et les encapsulait vers l’adresse temporaire. Dans le modèle de base, le trafic sortant du nœud mobile pouvait emprunter directement le routage IP ordinaire. Les deux directions ne partageaient donc pas nécessairement le même point de contrôle.

Une liaison atteste un état de réacheminement accepté pour une période. Elle ne prouve ni l’émission par le correspondant, ni le passage dans le tunnel, ni la décapsulation, ni la consommation par l’application. Chaque événement demande sa propre observation. RFC 2005 fixait la même limite de sécurité : l’authentification couvrait l’enregistrement ; confidentialité et authentification des données applicatives relevaient d’autres protocoles.

Publié en octobre 1996 comme Proposed Standard, RFC 2002 fut accompagné par RFC 2005, qui relatait des implémentations indépendantes lors d’essais d’interopérabilité en 1995. C’est une preuve de diversité d’implémentation pour les fonctions testées, pas un recensement de déploiement. RFC 3220, RFC 3344 puis RFC 5944 ont ensuite remplacé la spécification ; le registre IANA conserve types de messages et codes de réponse. Cette continuité documentaire ne démontre aucun état opérateur particulier.

La « Minimum Initial Specification » de Lu Heng aide à lire ce choix : une couche commune étroite rend l’interopérabilité possible tout en laissant les décisions futures au niveau local. « Running-Code Primacy » impose la correction essentielle : une syntaxe publiée n’est pas un état en fonctionnement. Les règles écrites, l’état accepté et le comportement observé sont liés, mais non interchangeables.

L’apport historique de RFC 2002 fut de rendre un changement limité de joignabilité exprimable, authentifié et périssable sans modifier l’identité publique. Sa preuve la plus forte était une liaison minutée. La rigueur consiste à ne pas lui faire dire davantage.

Sources