Résumé

  • RFC 1900 a fait de la renumérotation un problème de dépendances : un fournisseur pouvait attribuer un nouveau préfixe, sans pour autant découvrir les adresses recopiées dans les configurations, les applications, les licences et les systèmes d’un tiers.
  • Le DNS diminuait cette dispersion en retardant l’association entre nom et adresse jusqu’à l’usage. Il ne prouvait ni l’expiration des caches, ni une nouvelle résolution par l’application, ni la mise à jour des ACL, du DNS inverse ou des domaines administratifs extérieurs.
  • De RFC 2071 à RFC 7010, les guides ont élargi l’inventaire aux routeurs, à DHCP, aux outils de gestion, aux associations de sécurité, aux journaux et aux données éparses. La fin d’une migration est donc une conclusion composée, jamais le simple constat qu’un nouveau numéro existe.

Le numéro officiel n’était que le début du travail

RFC 1900 est un document informationnel de l’IAB publié en février 1996, et non une norme imposant une procédure. Il partait de changements banals : déplacer une machine vers un autre sous-réseau, scinder un segment saturé ou revoir le plan d’adressage d’une organisation. Mais son motif le plus structurant venait de la croissance de l’Internet.

L’agrégation CIDR permettait à un fournisseur d’annoncer un grand bloc plutôt qu’une multitude de routes clientes. Une organisation numérotée dans ce bloc bénéficiait de cette économie. En changeant de fournisseur, elle risquait toutefois de devoir changer ses propres adresses afin que l’ancienne portion n’ajoute pas durablement une route plus spécifique au système mondial. Sans renumérotation, RFC 1900 envisageait une connectivité limitée, un coût supplémentaire lié au maintien de l’information de routage, ou les deux.

La décision pouvait être centralisée ; ses conséquences ne l’étaient pas. Le fournisseur savait quel préfixe il attribuait. L’équipe réseau connaissait ses interfaces et une partie de ses routes. Mais aucun de ces acteurs ne possédait nécessairement la liste des fichiers où un administrateur avait écrit une adresse, des outils qui l’utilisaient comme cible de supervision ou des partenaires qui l’avaient transformée en règle d’autorisation.

Le mot « renumérotation » compressait donc plusieurs autorités. Il y avait l’autorité de fournir le nouveau préfixe, celle de modifier un routeur, celle d’éditer une zone DNS, celle de changer une application et celle d’accepter la nouvelle origine chez un tiers. Faire tenir ces opérations dans un seul verbe ne les réunissait pas sous un seul contrôle.

Le DNS localisait le changement sans effacer la mémoire

La réponse architecturale de RFC 1900 consistait à préserver la différence entre nom et adresse. L’espace des noms DNS était indépendant de l’espace d’adressage. Un nom suivait plus volontiers la fonction ou l’appartenance d’une machine ; une adresse décrivait son emplacement dans une structure de routage. Employer un nom permettait de retarder l’association avec l’adresse jusqu’au moment de la connexion.

Cette indirection changeait l’économie de la migration. Au lieu de corriger le même nombre dans cent fichiers, l’opérateur pouvait modifier un enregistrement faisant autorité. RFC 1900 recommandait donc les FQDN dans les configurations, déconseillait le codage en dur des adresses et demandait d’éviter les listes parallèles de correspondance entre noms et numéros. Lorsqu’un logiciel ancien n’acceptait qu’une adresse, il proposait de produire automatiquement son fichier depuis une source exprimée en noms.

Mais « localiser » ne voulait pas dire « terminer ». Le serveur faisant autorité pouvait publier la nouvelle valeur ; un résolveur pouvait encore servir l’ancienne jusqu’à l’échéance du TTL. Une application pouvait résoudre le nom au démarrage, puis garder l’adresse au-delà de cette échéance. Le DNS inverse pouvait dépendre du fournisseur. Un pare-feu construit à partir du DNS pouvait conserver sa propre copie. Une zone située dans un autre domaine administratif exigeait une relation de confiance et une action distincte.

Même RFC 1900 n’a pas présenté le DNS comme une baguette magique. Des noms et des adresses tous deux dynamiques exigeaient une mise à jour DNS très réactive. La mise à jour authentifiée restait un chantier. DHCP, la découverte des routeurs et la localisation des services formaient un outillage à développer et à déployer, pas un résultat déjà acquis partout.

Le cas des licences liées à l’adresse révélait une frontière plus dure. Le fournisseur de réseau pouvait rendre l’ancienne adresse inutilisable, mais il ne pouvait pas modifier la logique commerciale d’un éditeur. Le détenteur de la licence pouvait avoir respecté toutes les étapes réseau et perdre néanmoins l’accès au logiciel. RFC 1900 déconseillait fortement cette pratique parce qu’elle convertissait un localisateur technique en verrou d’identité.

L’inventaire s’est agrandi plus vite que l’automatisation

RFC 2071 a donné des noms aux dépendances : postes, imprimantes, serveurs, terminaux et routeurs, mais aussi adresses de serveurs DNS, stations SNMP et listes de contrôle d’accès. Une période de grâce pouvait maintenir en parallèle les anciennes et les nouvelles adresses. Elle donnait du temps ; elle n’indiquait pas où chercher.

RFC 2072 a transformé la préparation en discipline d’exploitation. Les numéros apparaissaient dans les routes par défaut et statiques, les protocoles internes, BGP, les tunnels, les filtres, la gestion, les annuaires, la comptabilité et les fonctions de sécurité. Ce catalogue montrait qu’une migration n’était pas une modification atomique. Elle traversait des équipes et des outils qui ne partageaient ni la même base de données ni le même calendrier.

Avec IPv6, RFC 4192 a décrit une transition sans « jour J » : installer le nouveau préfixe, faire fonctionner les deux, déplacer l’usage, puis retirer l’ancien. Le DNS devait suivre les changements d’interface, avec des TTL adaptés à la propagation. Cette période de coexistence permettait d’observer la migration. Elle ne prouvait pas que tous les consommateurs avaient parlé pendant la fenêtre.

Un équipement utilisé une fois par mois pouvait rester silencieux. Une règle de secours ne s’activait qu’après une panne. Un partenaire pouvait ne consulter son allowlist qu’au prochain incident. RFC 4192 demandait du temps ou une vérification spéciale pour les appareils occasionnels, et reconnaissait les difficultés de l’automatisation DNS entre domaines et du DNS inverse. Une dépendance muette était précisément celle que le succès apparent risquait de cacher.

« Encore » résumait quatorze années de progrès incomplet

En 2010, RFC 5887 a repris le titre sous la forme Renumbering Still Needs Work. Les mécanismes avaient progressé. DHCP était largement disponible, IPv6 pouvait superposer des préfixes et les outils de gestion savaient régénérer certaines configurations. Le problème de connaissance restait entier.

Avec une gestion d’actifs solide, une organisation pouvait modifier une base, produire ses tables DHCP et sa zone DNS, réduire temporairement les durées et coordonner la bascule. Avec un inventaire faible, elle éditait à la main et attendait que baux et caches cessent de propager l’ancien état. Une seule machine configurée manuellement pouvait rendre l’automatisation complète très improbable. Dans un système embarqué, l’adresse pouvait résider en mémoire morte ou être réglée par des commutateurs physiques.

La couche applicative échappait encore davantage au regard. RFC 5887 rappelait qu’une étude avait trouvé des dépendances explicites aux adresses dans 34 des 257 RFC applicatifs Standards Track ou expérimentaux examinés. Ce chiffre ne mesure pas tous les logiciels. Il soulignait au contraire la limite de l’examen documentaire : une spécification ne révèle pas forcément qu’une implémentation propriétaire met l’adresse en cache indéfiniment.

Des URL, cookies, proxys ou licences pouvaient contenir le littéral. Les interfaces de programmation par sockets exposaient l’objet de couche réseau sans fournir sa durée de validité. Certains logiciels répétaient la résolution ou essayaient plusieurs adresses ; d’autres ne le faisaient pas. La sécurité produisait même un conflit légitime : le « DNS pinning » pouvait refuser des changements d’adresse pour contrer une attaque, au prix d’une renumérotation moins fluide.

RFC 6879 a recommandé les FQDN, la découverte de services, les valeurs paramétrées et la mise à jour systématique du DNS direct et inverse. RFC 7010 a distingué la gestion des préfixes, la reconfiguration des nœuds, la correction des entrées dépendantes et la coordination de l’événement. Il constatait toujours l’absence d’un mécanisme unique capable de mettre à jour tous les sous-systèmes et toutes les bases externes.

Son exemple des journaux est révélateur. Un collecteur peut prendre l’adresse source d’un message pour l’identité du routeur. Après la migration, il croit voir apparaître un nouvel appareil si personne ne lui transmet la relation entre ancien et nouveau numéro. Le réseau a changé de localisateur ; l’outil de gestion a changé d’objet. Les deux systèmes ont exécuté leur logique sans partager la même notion d’identité.

Il faut prouver chaque frontière séparément

Une attribution prouve qu’un nouveau préfixe est disponible. Une configuration d’interface prouve qu’un système porte une nouvelle adresse. Une route observée prouve un état du plan de contrôle. Un enregistrement DNS prouve une association publiée. Une recherche dans les dépôts prouve qu’aucun littéral correspondant n’a été trouvé dans le périmètre inspecté. Un test applicatif prouve une transaction donnée, à un moment et depuis un chemin donnés.

La conclusion « la renumérotation est terminée » exige de relier ces preuves sans les confondre. L’inventaire doit nommer le propriétaire de chaque référence, la méthode de mise à jour, le comportement de cache, la durée d’observation et les systèmes silencieux volontairement exercés. Les domaines externes doivent confirmer leur propre action ; l’équipe interne ne peut pas la déduire de son changement DNS.

Le coût de cette preuve ne transforme pas automatiquement une adresse dépendante d’un fournisseur en droit permanent. Il révèle néanmoins la réalité de la sortie. Celui qui peut ordonner le changement ne contrôle pas forcément les applications, les partenaires et les vendeurs qui ont utilisé le numéro comme identité. La portabilité formelle d’une relation n’est pas encore la portabilité opérationnelle du service.

La leçon de RFC 1900 tient dans cet écart. L’Internet pouvait attribuer un nouveau nombre. Il devait encore apprendre à découvrir tout ce que l’ancien avait convaincu.

Sources