Résumé

  • Dans RFC 3344, le bit S d’une demande d’enregistrement autorisait un nœud Mobile IPv4 à solliciter le maintien de ses anciennes liaisons de mobilité en plus de la nouvelle adresse temporaire.
  • Si l’agent d’origine acceptait cette pluralité, il envoyait une copie distincte de chaque datagramme vers chaque adresse active : la réussite du nouvel enregistrement ne prouvait donc pas la disparition de l’ancien chemin.

Le mot « actuel » invite à dessiner une case unique. Une adresse d’origine aurait une adresse temporaire actuelle, remplacée à chaque déplacement. RFC 3344 oblige à renoncer à ce dessin. L’état pouvait être une liste : plusieurs adresses temporaires, plusieurs durées de vie et plusieurs tunnels portant simultanément le même trafic.

Le protocole ne cachait pas cette situation dans une exception. La demande d’enregistrement comportait un bit S, pour simultaneous bindings. Le nœud mobile le positionnait afin que l’agent d’origine conserve les liaisons précédentes. Sans cette demande, ou sans prise en charge par l’agent, la nouvelle liaison remplaçait les anciennes.

Une identité stable, plusieurs sorties

Mobile IPv4 maintenait l’adresse d’origine du nœud pendant que changeait son point d’accès au réseau. L’adresse temporaire désignait l’extrémité du tunnel : soit un agent étranger chargé de décapsuler, soit une adresse co-localisée que le nœud avait obtenue sur le réseau visité.

Ce champ restait un instrument d’acheminement. Il ne certifiait ni une position physique, ni une personne, ni la qualité d’une liaison radio. Même authentifié, l’enregistrement attestait que l’agent d’origine avait accepté un état pour une durée donnée; il n’attestait pas qu’un datagramme avait traversé le tunnel et atteint une application.

Le bit S élargissait cet état. Le texte envisageait notamment un appareil à portée de plusieurs agents étrangers. L’agent d’origine qui gérait les liaisons simultanées devait intercepter le datagramme adressé à l’adresse d’origine, en produire une copie par adresse temporaire et les encapsuler séparément. Recevoir plusieurs copies était une conséquence assumée, pas nécessairement une anomalie.

« Accepté » avait deux codes

Le code 0 signifiait que l’enregistrement était accepté. Le code 1 signifiait lui aussi qu’il était accepté, mais que les liaisons simultanées n’étaient pas prises en charge. Le registre IANA Mobile IPv4 conserve encore ces deux résultats parmi les codes de succès.

Pour un nœud qui demandait le maintien de l’ancien état, cette nuance décidait du sens de la suite. Le code 0 pouvait laisser vivre l’ancienne et la nouvelle liaison. Le code 1 validait la nouvelle inscription tout en refusant la capacité simultanée. Le code 135 appartenait à une autre catégorie : la demande était refusée parce qu’il existait trop de liaisons simultanées.

Une interface d’exploitation qui résume 0 et 1 par le même voyant vert efface donc un fait indispensable. Elle ne permet plus d’expliquer pourquoi deux copies étaient attendues, ou pourquoi une ancienne route devait au contraire avoir été remplacée. La capacité, l’admission de l’état et la livraison effective du paquet sont trois preuves différentes.

Effacer une ligne n’effaçait pas la liste

La durée de vie n’était pas globale. Une demande de durée zéro utilisant l’adresse d’origine supprimait toutes les liaisons et mettait fin au service de mobilité. La même durée zéro accompagnée d’une adresse temporaire particulière ne supprimait que cette entrée. Les autres restaient actives.

Pour une durée non nulle, l’agent ajoutait la nouvelle adresse. Si S était accepté, il conservait les entrées antérieures; sinon il les retirait. À l’expiration d’une liaison, il supprimait uniquement celle-ci et devait maintenir les autres liaisons simultanées non expirées. Aucune réponse d’enregistrement n’était émise simplement parce que le temps s’était écoulé.

Cette absence de message compte. Le silence n’établissait ni la fin de tous les chemins ni la continuité d’un agent étranger. Les listes de visiteurs pouvaient expirer naturellement. Une retransmission identique ne pouvait pas prolonger la durée au-delà de la concession initiale. Le protocole entretenait ainsi plusieurs horloges logiques, même si l’opérateur n’en affichait qu’une.

La suite a donné des noms aux chemins

Publié en août 2002, RFC 3344 remplaçait RFC 3220 dans la lignée ouverte par RFC 2002. RFC 5944 l’a remplacé en 2010 tout en conservant la faculté de maintenir plusieurs enregistrements et de copier chaque datagramme vers toutes les adresses actives. L’errata éditorial retenu et l’errata technique rejeté de RFC 3344 ne modifient pas ce mécanisme.

Dans Mobile IPv6, RFC 3775 a distingué une adresse temporaire principale et une ancienne adresse conservée comme non principale pendant une transition. RFC 5648 a ensuite introduit des identifiants de liaison pour gérer plusieurs adresses séparément. Pour Mobile IPv4, RFC 7629 a proposé des identifiants, plusieurs tunnels et des politiques par flux.

Cette évolution révèle la modestie du bit S. Il produisait une réplication générale, pas une sélection intelligente. La présence d’une ancienne entrée ne prouvait ni sa santé ni son utilité. Elle pouvait fournir une redondance, gaspiller de la capacité ou conduire vers un chemin muet. Seules des observations supplémentaires permettaient de le savoir.

L’archive correcte est donc une collection, pas la dernière ligne connue. Elle conserve la demande S, le code reçu, chaque adresse, chaque durée, chaque copie de tunnel et chaque observation de livraison. La nouveauté d’une adresse ne lui donne pas le monopole de la vérité opérationnelle.

Sources