Résumé

  • RFC 2103 séparait deux effets indépendants de la mobilité : le localisateur d’un point terminal pouvait changer, et la topologie du réseau pouvait changer. L’un pouvait survenir sans l’autre.
  • Un module d’association dynamique pouvait actualiser le couple point terminal–localisateur tant que la topologie restait stable. Lorsqu’un réseau entier bougeait, cartes et routeurs devaient aussi intervenir.

La case la plus révélatrice de la matrice de RFC 2103 paraît d’abord paradoxale : le localisateur ne change pas, mais la topologie, elle, change.

Un nœud réseau peut acquérir de nouveaux voisins tout en restant dans le même nœud englobant de Nimrod. Ses points terminaux conservent alors leurs localisateurs. Une consultation peut donc rendre une association actuelle et correcte, tandis que les paquets entrant dans la zone ont besoin d’une nouvelle description de la connectivité. L’association dit vrai ; la route calculée à partir de l’ancienne carte peut être fausse.

L’endroit précis où le module cesse de suffire

RFC 1992 séparait les identifiants de points terminaux, sans signification topologique, des localisateurs qui situaient les nœuds dans une carte hiérarchique. Un changement de fournisseur imposait donc de nouveaux localisateurs : emporter l’ancien préfixe dans une autre partie de la carte aurait aplati la hiérarchie.

RFC 2103 transforma cette séparation en modèle de mobilité. Son Dynamic Association Module, ou DAM, maintenait le lien variable entre point terminal et localisateur. Il ne s’agissait ni d’un serveur obligatoire ni d’un DNS rebaptisé, mais d’une abstraction permettant de comparer des architectures. La fonction pouvait être portée par une base de données, un représentant d’origine ou de l’état distribué dans les routeurs.

Le document distinguait quatre situations : ni le localisateur ni la topologie ne changent ; seul le localisateur change ; seule la topologie change ; les deux changent. Le récit commode du « nouveau localisateur » ne couvre entièrement que la deuxième. Dans la troisième, le DAM n’a rien à modifier, alors que la carte de Nimrod doit être révisée. Dans la quatrième, les deux côtés travaillent.

La mobilité du réseau faisait fuir l’abstraction

RFC 2103 évoquait une organisation qui déménage et des réseaux sans fil embarqués dans des trains, avions, voitures ou navires. Lorsqu’un nœud change de voisins, le graphe change. S’il sort de son nœud englobant, les localisateurs des équipements qu’il transporte peuvent changer eux aussi.

Les mécanismes ordinaires de mise à jour topologique de Nimrod étaient vraisemblablement conçus pour des changements relativement lents. Des réseaux rapides pouvaient exiger des annonces spécifiques vers les représentants de nœuds, afin que les paquets entrants suivent la nouvelle topologie. Le texte ne définissait pas cette interaction. Il consignait une exigence : la mobilité d’un réseau pouvait rapprocher le DAM du routage et des routeurs bien davantage que la mobilité d’un seul point terminal.

Une association récente ne répond donc qu’à une question : quel localisateur est lié à ce point terminal maintenant ? Elle ne prouve ni les voisins actuels du nœud, ni la diffusion d’une nouvelle carte, ni le recalcul d’une route, ni la validité de l’état de transfert.

Trois endroits où placer l’état

La première famille centralisait les associations et laissait la source consulter la base. La route pouvait être directe, mais la panne centrale effaçait l’information et l’échelle paraissait insuffisante.

La deuxième distribuait la maintenance et remappait au domicile, selon la forme de Mobile IP. La source continuait d’envoyer vers l’origine ; un représentant redirigeait vers le lieu courant. La solution évitait de modifier les sources et les routeurs ordinaires, concentrait une partie du contrôle et pouvait préserver la confidentialité du lieu. Elle créait aussi un routage triangulaire, une dépendance au représentant et un doute sur l’échelle future. RFC 2103 la qualifiait de première solution viable, non de conclusion.

La troisième plaçait de l’état dans les routeurs. Plus complexe, elle convenait mieux aux cas où la topologie changeait. Cette proximité pouvait raccourcir la réaction, mais elle faisait entrer davantage d’entités Nimrod dans le mécanisme que le DAM devait isoler.

Mobile IP restait une chaîne à observer

L’adaptation de RFC 2002 comportait découverte, enregistrement et transfert. Un hôte mobile enregistrait un agent étranger ou un localisateur transitoire auprès d’un agent d’origine. Celui-ci mémorisait la liaison, interceptait les paquets, les encapsulait et les envoyait vers l’agent étranger. Ce dernier devait encore décapsuler, trouver l’hôte dans sa liste de visiteurs et livrer.

L’enregistrement pouvait réussir sans que cette chaîne aboutisse. Le localisateur mis en cache pouvait vieillir. Si l’agent étranger ne trouvait pas l’identifiant, il jetait le paquet et renvoyait une erreur. Un détour pouvait fonctionner sans être optimal. L’authentification d’un message ne décidait pas si l’utilisateur avait le droit de rejoindre le réseau visité.

Le texte distinguait aussi mobilité hors ligne, avec rupture de session, et mobilité en ligne, avec session maintenue. Il souhaitait la seconde, sans démontrer qu’une session de transport donnée survivait. Il ne mesurait pas davantage l’échelle : un système dont le temps de réaction vaut o ne suit plus un mobile qui change de point d’attache plus vite que 1/o, mais aucun déploiement ne donnait la valeur de o.

Une proposition, pas une preuve de déploiement

La notice du RFC Editor et la fiche IETF Datatracker conservent un document Informational de février 1997. RFC 2103 précise qu’il ne s’agit pas d’une spécification de protocole. Désenregistrement, détails d’authentification, mises à jour rapides, routage prédictif et interaction DAM–routeurs restent ouverts.

L’importance historique se trouve dans cette limite. Nimrod séparait identité, lieu et routage ; RFC 2103 identifia l’instant où ces couches ne s’alignaient plus. Déplacer un terminal produisait une nouvelle association. Déplacer un réseau modifiait le graphe qui rendait cette association exploitable.

Les textes de Lu Heng sur la primauté du code exécuté, la spécification initiale minimale et les couches de réalité sont ici une grille d’analyse déclarée, non une preuve historique. Une publication décrit une interface ; la réalité n’apparaît que lorsque les implémentations mettent à jour l’état, que les routeurs l’acceptent et que le trajet est observé.

La conclusion défendable est donc étroite : une association courante prouve une association courante. Pour dire que la mobilité a fonctionné, il faut aussi conserver la version de topologie, la propagation de la mise à jour, la décision de route, l’état de transfert, l’autorisation, la session et l’arrivée.

Sources