Expiration du bail à minuit, les routes à l’aube

Résumé

L’expiration du contrat, le retrait des routes et le nettoyage opérationnel sont des événements distincts. Un bail peut être légalement terminé tandis que les annonces BGP restent visibles, les filtres amont autorisent encore l’ancienne origine, les ROA la valident toujours, le DNS inversé nomme encore l’ancien opérateur et les systèmes des clients dépendent toujours des adresses.
Le plan de sortie devrait être convenu à l’activation et non inventé durant la dernière semaine. Il nécessite les préfixes exacts, les fuseaux horaires, les délais de préavis, les jalons de migration des clients, les propriétaires des routes et autorisations, les contacts amont, les règles d’urgence, les sources de preuves et une définition claire de l’achèvement.
Une période de grâce est un temps de migration contrôlé, pas un renouvellement gratuit. Pendant la grâce, le preneur devrait cesser d’ajouter des clients, réduire le trafic, préserver ses obligations de sécurité et rendre compte des progrès. Le bailleur ne devrait conserver que l’autorité nécessaire au retrait sécurisé et maintenir une échéance finale stricte.
La migration des clients précède le nettoyage destructif. Les listes blanches externes, les API, les pairs VPN, les systèmes de messagerie, les partenaires de paiement et les contrôles de sécurité peuvent faire d’une adresse une partie de l’identité métier. Une période de double fonctionnement peut être nécessaire pour que les clients puissent migrer avant que l’ancienne route ne disparaisse.
Les fournisseurs de transit doivent supprimer l’autorisation à la frontière directe. Le preneur retire l’annonce; le fournisseur amont supprime les filtres client et l’acceptation de route; le bailleur retire ensuite les autorisations RPKI et IRR résiduelles. Supprimer un ROA seul ne garantit pas l’arrêt de la propagation de la route.
Les enregistrements DNS inversé, RDAP ou Whois, RPKI, IRR et de réputation ne changent pas de manière synchronisée. Chacun doit avoir un propriétaire désigné, une méthode d’observation et un enregistrement des exceptions. Une ligne de registre modifiée ne prouve pas que le routage, la délégation et la réputation sont propres.
La réutilisation doit suivre le risque, pas le rituel. Un préfixe qui a servi un accès d’entreprise stable peut nécessiter peu de temps de refroidissement; un bloc quittant un proxy, un usage de courrier en masse ou abusif peut nécessiter une observation et une remédiation plus longues. L’objectif est une réutilisation rapide et défendable après un nettoyage vérifié, pas une quarantaine permanente.

Minuit est un horodatage juridique, pas une instruction réseau

À 23 h 59, un préfixe loué peut transporter des sessions clients, des API, des tunnels VPN, du courrier, du trafic web et de la surveillance. À 00 h 00, l’accord indique que le droit de l’utiliser prend fin. Rien dans BGP ne lit cette phrase.

Les routeurs du preneur continuent d’annoncer ce que leur configuration leur ordonne d’annoncer. Les filtres client du fournisseur amont continuent d’accepter les paires préfixe-origine pour lesquelles ils ont été construits. Les réseaux distants continuent de sélectionner les chemins selon leurs politiques. Les parties utilisatrices de RPKI continuent de traiter les données publiées qu’elles peuvent récupérer. Les résolveurs récursifs continuent de suivre les délégations de DNS inversé. Les systèmes de réputation continuent d’associer les observations passées et actuelles aux adresses.

Il ne s’agit pas d’un défaut d’un protocole particulier. Il s’agit d’une erreur de catégorie dans le contrat. On demande à une échéance commerciale d’exécuter des actes techniques qui relèvent de plusieurs opérateurs indépendants.

L’erreur inverse est de supposer que, parce que la route persiste à l’aube, le bail s’est silencieusement renouvelé. La propagation continue peut être un maintien non autorisé, une convergence retardée, un filtre amont laissé en place, une session de secours oubliée ou une migration de clients que les parties ont expressément autorisée pour une courte période. La visibilité BGP prouve le routage observé, pas un nouveau contrat.

Une conception sûre donne aux différents moments des noms différents. L’expiration commerciale met fin au droit d’ajouter de nouvelles dépendances et fixe la frontière économique. La migration des services déplace les clients et le trafic. Le retrait des routes met fin à l’annonce de l’ancienne origine. Le nettoyage des autorisations retire l’ancienne origine de RPKI et de l’IRR. Le nettoyage de l’enregistrement et de la délégation corrige les contacts RDAP et le DNS inversé. L’aptitude à la réutilisation marque le moment où le bailleur peut placer le préfixe ailleurs de manière responsable.

Ces moments devraient être proches, mais ils n’ont pas besoin d’être identiques. Les forcer en une seconde peut créer une panne évitable. Les laisser dériver sans arrêt brutal peut créer une utilisation non autorisée et des conflits avec le preneur suivant. La gouvernance est la discipline qui consiste à contrôler l’intervalle.

L’aube du titre est donc un avertissement contre le déni et la panique. Les routes après minuit ne prouvent pas que la location ne peut pas fonctionner. Elles prouvent que la sortie du bail doit être conçue comme une transition plutôt que racontée comme une date.

Définir l’achèvement avant que quiconque n’annonce le préfixe

Le meilleur moment pour négocier une sortie est avant que le premier client ne soit placé sur les adresses. À ce stade, aucune des parties n’est piégée par des dépendances existantes et toutes deux peuvent évaluer le travail honnêtement.

Le bail devrait être assorti d’un calendrier de sortie pour chaque CIDR exact. Il identifie les AS d’origine actuels et autorisés, chaque fournisseur amont censé les transporter, les éventuels préfixes plus spécifiques autorisés, les dispositions RPKI, les mainteneurs IRR concernés, l’opérateur de DNS inversé, les contacts d’enregistrement, le contact abuse et les utilisations connues sensibles à la réputation. Le calendrier donne aussi le fuseau horaire et l’horloge de référence pour chaque échéance. « Minuit » est ambigu dans un service mondial.

L’achèvement doit être un ensemble de conditions observables. Au minimum: l’ancienne origine a retiré tous les préfixes loués; les fournisseurs amont directs ne les acceptent plus de l’ancien preneur; les anciens ROA et objets de route sont supprimés ou remplacés; le DNS inversé ne délègue plus à un ancien opérateur non coopératif; les contacts publics ne redirigent pas incorrectement les rapports d’abus ou de routage; le trafic client est tombé au niveau résiduel convenu; et aucune annonce non approuvée ne reste visible pendant la période d’observation.

Certaines conditions peuvent ne pas s’appliquer. Un bail peut n’avoir jamais modifié l’enregistrement du titulaire direct. Un preneur peut avoir utilisé le service de DNS inversé du bailleur. Un fournisseur amont peut ne pas utiliser d’IRR. L’important n’est pas de cocher aveuglément chaque case mais de consigner pourquoi une couche n’a besoin d’aucune modification.

Le calendrier devrait mentionner les preuves. Un ticket routeur ou fournisseur peut prouver un retrait soumis. Un collecteur de routes indépendant peut montrer si la route reste visible de ses pairs. Un validateur RPKI peut montrer les données validées actuelles. Des requêtes DNS peuvent montrer les serveurs de noms faisant autorité et des réponses PTR représentatives. RDAP peut montrer les données d’enregistrement actuelles. Les vérifications de réputation peuvent montrer les listages connus. Chaque source répond à une question différente et chacune a ses limites.

Les parties devraient convenir de qui peut déclarer l’achèvement. Le preneur devrait fournir ses preuves de clôture. Le bailleur devrait vérifier l’état public et ses propres références. Le fournisseur amont devrait confirmer la suppression des filtres. Si un acteur est absent, l’accord devrait prévoir une méthode alternative et une escalade. Un courriel auto-certifié disant « toutes les routes sont supprimées » est trop faible pour une réutilisation immédiate.

Concevoir la sortie dès l’entrée a un autre avantage: cela révèle si la durée du bail est réaliste. Un bail de trente jours peut être bon marché en capacité mais inadapté à un service dont les clients ont besoin de soixante jours pour modifier les règles de pare-feu. La durée de l’adresse et la charge de migration doivent relever de la même décision commerciale.

Les parties fonctionnent sur des horloges différentes

Le bailleur voit la disponibilité du portefeuille et la date à laquelle le préfixe devrait revenir pour maintenance ou réutilisation. Le preneur voit les engagements clients et les fenêtres de changement réseau. Le fournisseur amont voit les files de tickets, la génération de filtres et la convergence des routes. Les clients voient seulement si leur service fonctionne encore.

Ces horloges créent des conflits prévisibles. Le bailleur a peut-être promis le bloc à un successeur à compter du premier jour du mois suivant. Le preneur peut avoir un client entreprise dont la prochaine fenêtre de pare-feu approuvée est une semaine plus tard. Le fournisseur de transit peut exiger un délai pour modifier les filtres de préfixe. Un service de réputation peut exiger des preuves et une observation avant de mettre à jour un listage.

La réponse est un plan rétrograde à partir du retrait final. L’avis aux clients commence d’abord. Les adresses et routes de remplacement deviennent disponibles. Les parties externes mettent à jour les listes blanches et le DNS. Le trafic est mesuré sur les anciens et nouveaux chemins. Les filtres amont pour le remplacement sont testés. Ce n’est qu’ensuite que l’ancienne route entre dans une période de drainage, suivie du retrait et de la suppression de l’autorité résiduelle.

Le bailleur a besoin de visibilité sur les jalons, pas d’accès aux secrets des clients. Des rapports hebdomadaires puis quotidiens peuvent indiquer le pourcentage de trafic déplacé, le nombre de dépendances non résolues, l’heure prévue de la route finale et toute demande de grâce. Le preneur ne devrait pas attendre la dernière heure pour révéler que la moitié de ses clients ne peuvent pas migrer.

Le fournisseur amont a aussi besoin d’un préavis précoce. Un ticket transit ouvert à 23 h 55 crée une incertitude inutile quant à savoir si la route a été délibérément conservée ou simplement oubliée. L’expiration connue peut être placée sur le calendrier du fournisseur, avec une personne nommée autorisée à supprimer les filtres même si le preneur ne répond plus.

Ces responsabilités ne sont pas parfaitement symétriques. Le preneur contrôle la migration des clients et son routeur. Le bailleur contrôle l’allocation du portefeuille et souvent le ROA. Le fournisseur amont contrôle l’acceptation directe des routes. Chacun devrait garantir les actes qu’il peut accomplir et coopérer sur les actes qu’il ne peut pas.

Le temps devrait être mesuré à partir des accusés de réception aussi bien que des demandes. Si un bailleur dit au preneur de se retirer mais que le fournisseur amont n’accuse jamais réception d’une demande de suppression de filtre, le risque n’est pas résolu. Si le preneur dit avoir envoyé un avis client mais ne peut montrer ni la livraison ni la réponse pour les clients critiques, la confiance dans la migration reste faible.

Le contrat utile n’est pas celui qui a le plus de dates. C’est celui qui relie chaque date à un acteur responsable, un acte observable et une conséquence si l’acte est en retard.

Inventorier les dépendances, pas seulement les adresses

Un préfixe peut sembler inactif dans une liste d’actifs tout en restant profondément intégré dans les systèmes d’autres personnes. Une sortie sûre commence par un inventaire des dépendances.

Les éléments évidents sont les sessions BGP, les AS d’origine, les fournisseurs de transit, les objets de route, les ROA et les zones inverses. Les éléments moins évidents dictent souvent le calendrier de migration: listes blanches clients, règles des fournisseurs de paiement, partenaires API, pairs VPN, points de terminaison SFTP, centres d’opérations de sécurité, hypothèses de validation de certificats, géolocalisation, identité du serveur de messagerie, sondes de surveillance, exceptions de limitation de débit et références contractuelles à des adresses fixes.

La note de Lu Heng surl’identité réseau et la continuité clientdécrit directement ce point. Dès que des banques, des fournisseurs, des partenaires et des équipes de sécurité reconnaissent une adresse, la modifier devient un événement de continuité d’activité plutôt qu’un simple échange de capacité. Cette idée s’applique même lorsque l’adresse est louée. En fait, une durée limitée rend plus urgente la nécessité de classer les dépendances d’identité.

Le preneur devrait classer chaque dépendance par propriétaire, délai de changement, impact en cas d’échec et preuve d’achèvement. Un site web exposé aux clients derrière un répartiteur de charge peut migrer facilement. Une banque qui n’accepte le trafic que depuis un /29 fixe peut exiger une approbation formelle. Un service de messagerie peut techniquement migrer en une heure mais nécessiter une montée en puissance prudente de la réputation. Un pair VPN dans une organisation fortement réglementée peut avoir une fenêtre de changement par mois.

L’inventaire devrait également identifier les utilisateurs cachés en aval. Un revendeur peut avoir attribué des adresses à des clients. Un fournisseur de sécurité gérée peut annoncer un préfixe plus spécifique pendant une atténuation. Une session de transit de secours peut être silencieuse mais capable de ré-annoncer le bloc. Le DNS inversé peut être délégué à un serveur de noms géré par un client. Aucun de ces éléments ne devrait être déduit uniquement du schéma de réseau principal.

Les observations externes aident à tester l’exhaustivité. L’historique de routage peut révéler des origines ou des préfixes plus spécifiques que la liste actuelle omet. Le DNS inversé peut exposer des conventions de nommage actives. Les tickets d’abus peuvent identifier des services en aval. Ces observations sont des incitations à la vérification, pas une preuve de la relation juridique.

Le bailleur n’a pas besoin du nom de chaque client pour protéger son préfixe. Il a besoin d’être sûr que les dépendances ont été comptabilisées et que les migrations à haut risque progressent. Les calendriers confidentiels peuvent rester chez le preneur ou un examinateur convenu, tandis que les jalons agrégés soutiennent la planification du bailleur.

Sans cet inventaire, les périodes de grâce deviennent des conjectures. Avec lui, les parties peuvent distinguer un besoin réel de continuité d’un retard causé par une mauvaise préparation.

Les préavis doivent devenir progressivement plus précis

Un seul rappel trente jours avant l’expiration n’est pas un plan de sortie. Les préavis doivent se resserrer à mesure que l’incertitude diminue.

Un préavis initial plusieurs mois à l’avance peut confirmer si le bail sera renouvelé, prendra fin ou changera de taille. Il demande au preneur de valider l’inventaire des préfixes, d’identifier la capacité de remplacement et de lister les dépendances clients à long délai. Il donne au bailleur le temps d’éviter de promettre le même préfixe à un nouvel utilisateur avant que la sortie ne soit réalisable.

Un deuxième préavis peut confirmer les routes de remplacement, les contacts amont, les propriétaires des modifications RPKI et IRR, la destination du DNS inversé et le trafic résiduel attendu. À ce stade, toute demande de grâce contractuelle doit être motivée et limitée. « Les clients ont besoin de plus de temps » ne suffit pas; la demande doit identifier combien de dépendances subsistent, les dates disponibles et les restrictions qui s’appliqueront pendant la prolongation.

Dans la dernière semaine, le préavis devient opérationnel. Il indique la fenêtre de changement, les anciennes et nouvelles origines, la séquence de drainage du trafic, les tickets des fournisseurs directs, le pont de contact et les conditions d’arrêt. Si une dépendance critique échoue, les parties savent qui peut suspendre le retrait et pour combien de temps.

Le dernier jour, les préavis ne devraient pas introduire de nouveaux faits. Ils devraient confirmer l’état de préparation. Le preneur rend compte du trafic et de l’état des clients. Le fournisseur amont confirme les actions sur les filtres. Le bailleur confirme le calendrier des modifications de ROA, IRR et DNS inversé. Tout le monde utilise la même référence UTC même si l’accord commercial désigne un fuseau horaire local.

Après le retrait, les préavis deviennent des preuves. L’ancien preneur confirme les modifications de routeur et de session. Le fournisseur amont confirme que le préfixe n’est plus accepté de ce client. Le bailleur rapporte l’état BGP et RPKI observé. Toute visibilité restante est assignée à une enquête plutôt que traitée comme une accusation.

Les préavis nécessitent des destinataires authentifiés. Un contact de facturation peut ne pas atteindre l’équipe réseau. Un contact technique peut ne pas avoir l’autorité pour prolonger le bail. Les adresses de rôle devraient être appuyées par des personnes nommées et des contacts hors bande. Les parties devraient les tester pendant la durée du bail, et non découvrir des courriels rejetés pendant la résiliation.

Un préavis progressif protège les deux parties. Il empêche un bailleur de créer une surprise à minuit et empêche un preneur d’utiliser la surprise comme motif de maintien indéfini. Il transforme l’expiration d’une menace unique en une séquence d’engagements de plus en plus vérifiables.

Une période de grâce est une descente contrôlée

La grâce est souvent décrite comme de la générosité du bailleur ou une faiblesse dans l’application. Il est préférable de la comprendre comme un intervalle de contrôle des risques.

Pendant la grâce, la durée commerciale a été soit brièvement prolongée, soit les parties ont accordé des droits de maintien limités pour la migration. L’accord devrait être explicite sur ce point. Le paiement, la responsabilité, les obligations en matière d’abus et l’autorité de routage doivent rester définis. L’ambiguïté peut amener le preneur à utiliser les adresses sans protection claire et le bailleur à accepter le risque sans compensation.

Le preneur devrait entrer dans un mode restreint. Aucun nouveau client ne devrait être placé sur le préfixe. Aucune nouvelle origine ni préfixe plus spécifique ne devrait être ajouté sauf si nécessaire pour terminer la migration en toute sécurité. Le trafic devrait diminuer conformément aux jalons. Les communications avec les clients et les blocages non résolus devraient être signalés. La sécurité et la réponse aux abus doivent se poursuivre à plein régime; un service qui expire n’est pas un service abandonné.

Le bailleur devrait préserver l’autorisation minimale nécessaire à une sortie ordonnée. Il ne devrait pas révoquer le seul ROA valide tant que le trafic convenu subsiste, mais il ne devrait pas non plus élargir l’autorité ni laisser l’intervalle de grâce se renouveler automatiquement. Une heure de fin d’autorisation stricte reste nécessaire.

Le fournisseur amont peut aider en marquant la date finale de suppression des filtres, en surveillant la baisse du trafic et en refusant les ajouts en dehors de l’ensemble de préfixes existant. Si le preneur ne respecte pas les jalons, les parties peuvent raccourcir la grâce restante ou exiger un plan de migration plus intensif. Si une fenêtre de changement critique d’un tiers est documentée, elles peuvent prolonger de façon limitée plutôt que d’improviser un renouvellement complet.

La grâce peut avoir un prix plus élevé parce qu’elle bloque la prochaine utilisation du bailleur et nécessite un soutien continu. Ce prix devrait être convenu à l’avance plutôt qu’utilisé comme levier punitif pendant une crise. Un tarif de maintien journalier ou hebdomadaire pré-fixé crée une option connue sans rendre le retard gratuit.

Il doit également y avoir une exception d’urgence. Un abus actif, une fraude, une route compromise ou une ordonnance judiciaire peut rendre la poursuite du service dangereuse. Même alors, les parties devraient se coordonner avec le fournisseur amont direct car la suppression du ROA seule peut ne pas arrêter la route. La résiliation d’urgence modifie la séquence et le préavis; elle n’élimine pas la nécessité de vérifier le retrait.

La descente contrôlée n’est pas une descente sans fin. Une date finale, un trafic en baisse, une autorité limitée et des progrès observables distinguent une grâce sûre d’une occupation sans consentement.

Déplacer les clients avant de supprimer l’ancien chemin

Le principe central de continuité est « établir avant de rompre »: mettre en place et tester le remplacement avant de retirer le chemin dont dépendent les clients.

RFC 6198décrit les exigences d’arrêt progressif pour la maintenance planifiée des sessions BGP. Son objectif est de permettre aux chemins alternatifs de devenir disponibles avant que l’ancien chemin ne disparaisse, réduisant la perte de paquets pendant la convergence.RFC 8326normalise la communauté GRACEFUL_SHUTDOWN et les procédures qui peuvent abaisser la préférence avant un arrêt délibéré de session. Une sortie de bail est plus large que la maintenance de routeur, mais le principe opérationnel est pertinent: un changement planifié doit orienter le trafic vers une alternative prête avant de supprimer la route existante.

Le remplacement peut être un préfixe loué différent, un espace transféré, des adresses attribuées par le fournisseur ou une plage appartenant au client. Il doit être routé, filtré et surveillé avant que les clients ne soient invités à l’utiliser. Le DNS direct peut exposer à la fois les anciennes et nouvelles destinations pendant une transition où l’application prend en charge cette conception. Les répartiteurs de charge, la NAT, les proxys ou les passerelles applicatives peuvent permettre un service parallèle. La méthode dépend du service; le principe est une atteignabilité superposée avec une fin claire.

Les clients devraient recevoir plus qu’un nouveau CIDR. Ils ont besoin de la date d’activation, de la date de retrait de l’ancienne adresse, des modifications requises de liste blanche ou de VPN, d’un point de test, d’un contact de retour arrière et d’une méthode de confirmation. Les clients à forte dépendance peuvent nécessiter des tests bilatéraux.

Les mesures de trafic devraient montrer une baisse sur l’ancien préfixe. Un trafic nul n’est pas toujours atteignable car les scanners, les caches DNS obsolètes et les clients abandonnés peuvent persister. Les parties devraient distinguer le trafic client significatif du bruit de fond. Un seuil peut être fixé pour le retrait final, avec des exceptions nommées qui basculeront en mode fermé après l’échéance.

Les utilisations sensibles de messagerie et de sécurité peuvent nécessiter une gestion particulière. Une nouvelle adresse IP d’envoi peut avoir peu d’historique positif, tandis que l’ancienne adresse peut rester dans les listes blanches des partenaires. Une migration progressive avec un volume réduit peut être plus sûre qu’un basculement brusque. C’est une décision de service, pas une raison pour conserver l’ancien bail indéfiniment.

L’approche « établir avant de rompre » s’applique également aux dépendances administratives. Les nouveaux ROA et filtres amont devraient être prêts pour le remplacement. Le DNS inversé devrait résoudre correctement. Les contacts d’abus devraient être pourvus. Le remplacement n’est pas prêt simplement parce qu’un ping réussit.

Le bailleur ne devrait pas dicter la conception de l’application du preneur, mais il a droit à la preuve que la migration est réelle. La tendance du trafic, le nombre de clients finalisés et les tests réussis de la route de remplacement fournissent cette preuve sans exposer chaque détail commercial.

Retirer à l’origine et fermer la porte directe

Lorsque le seuil de migration est atteint, le preneur devrait retirer le préfixe de chaque ancienne origine. Les fournisseurs amont directs devraient alors fermer l’autorisation client qui permettait ces annonces.

La spécification de base de BGP, laRFC 4271, fournit le mécanisme par lequel les routes sont annoncées et retirées. En pratique, un préfixe loué peut être présent via plusieurs sessions, routeurs ou fournisseurs. Supprimer une annonce principale ne suffit pas si une sauvegarde subsiste. L’inventaire de sortie doit couvrir toutes les origines et sessions.

La confirmation du fournisseur amont est essentielle car l’ancien client peut devenir injoignable ou mal configurer un routeur ultérieurement. Supprimer le préfixe accepté du filtre client empêche une nouvelle annonce à la frontière contractuelle la plus proche. Cela donne également au bailleur une preuve plus solide que d’attendre de voir si l’ancienne route réapparaît globalement.

Lesactions MANRS pour les opérateurs de réseauimposent aux réseaux de garantir l’exactitude de leurs propres annonces et de celles de leurs clients, et de maintenir des contacts joignables. Leguide de mise en œuvre détaillé de MANRSmet l’accent sur une communication opérationnelle précise et des informations de routage vérifiables. La sortie de bail est une application directe de ces normes: le fournisseur amont connaît la relation client et peut supprimer l’autorisation lorsqu’elle prend fin.

L’observation devrait commencer immédiatement mais rester prudente. LeRIPE Routing Information Servicerecueille des données BGP de pairs via des collecteurs de routes distribués. L’historique de routage de RIPEstatpeut montrer les origines observées et la visibilité au fil du temps. Ce sont des vues indépendantes précieuses, mais aucun collecteur ne voit tous les chemins locaux ou privés.

Si la route reste visible, déterminez la source. Il peut s’agir d’un deuxième fournisseur amont, d’un préfixe plus spécifique, d’une observation obsolète, d’un chemin de serveur de routes ou d’une continuation non autorisée. Contactez le réseau d’origine et le fournisseur direct via des canaux connus. Ne supposez pas que supprimer plus d’enregistrements résoudra une route qui est toujours acceptée à sa source.

Le résultat souhaité est la convergence des preuves: confirmation du preneur, fermeture des filtres amont et disparition de plusieurs observations indépendantes. Aucune source unique n’est concluante à elle seule, mais ensemble, elles rendent la réutilisation plus sûre.

Le RPKI doit suivre le plan de route, pas le remplacer

Le nettoyage RPKI est nécessaire car un ancien preneur ne devrait pas rester autorisé cryptographiquement après la fin du droit de router. Son calendrier doit suivre le plan de retrait.

Avant que l’ancienne route ne soit retirée, le bailleur devrait confirmer que toute origine de remplacement a les ROA dont elle a besoin. Pendant une période de drainage convenue, l’ancienne origine peut rester autorisée afin que le trafic ne devienne pas RPKI Invalide pendant que les clients migrent. Une fois la route retirée et le fournisseur amont direct ayant fermé son filtre, l’ancien ROA devrait être supprimé ou modifié sans délai inutile.

L’ordre est important. Supprimez trop tôt et les réseaux appliquant la validation d’origine peuvent rejeter le trafic avant que le service ne soit prêt à se terminer. Supprimez trop tard et l’ancienne origine conserve une autorisation signée qui peut faire paraître valide au niveau de l’origine une annonce continue ou renouvelée.

Un ROA n’est pas un interrupteur. LaRFC 9582le définit comme une autorisation pour un AS d’annoncer des préfixes spécifiés. Si le ROA disparaît, la route peut devenir Non trouvée plutôt qu’Invalide, selon les autorisations de couverture. Même une route Invalide peut encore se propager via des réseaux dont les politiques ne la rejettent pas. Le retrait direct et le filtrage amont restent primordiaux.

Le bailleur devrait inspecter les chevauchements et les longueurs maximales. Un ROA agrégé peut continuer à couvrir l’ancienne route. Un ROA contenant plusieurs préfixes peut nécessiter une modification plutôt qu’une suppression totale. Dans le RPKI délégué, un certificat subordonné peut nécessiter une révocation seulement après avoir confirmé qu’il ne contient aucun bail continu. Les frontières de certification conçues autour des frontières client rendent la sortie beaucoup plus sûre.

La validation publique devrait être vérifiée après le changement. Le bailleur devrait enregistrer ce que montrent les validateurs indépendants et quand. Différentes parties utilisatrices récupèrent et traitent les données publiées à leur propre rythme, donc une action réussie sur un portail ne prouve pas une suppression instantanée universelle.

Lespratiques de transfert 2025 d’ARINsont écrites pour les transferts de ressources, pas pour les baux, mais l’avertissement opérationnel est instructif. ARIN dit aux organisations source et destinataire de coordonner les ROA, les objets IRR et le DNS inversé plutôt que de supposer que ces couches suivent automatiquement un événement d’enregistrement. Une sortie de bail a le même problème de coordination sans changement formel de titulaire pour forcer l’attention.

L’enregistrement d’achèvement devrait indiquer l’ancienne origine, les préfixes concernés, l’heure de suppression, l’état validé observé et toute autorisation résiduelle délibérée. « RPKI nettoyé » est trop vague pour un portefeuille pouvant contenir des clients qui se chevauchent.

Les enregistrements IRR et les filtres amont nécessitent une clôture distincte

Les objets de route IRR peuvent décrire quel AS d’origine est associé à un préfixe et peuvent alimenter les filtres d’opérateurs. Ils ne sont pas automatiquement identiques à un ROA, même lorsque des outils peuvent créer des enregistrements correspondants.

Ladocumentation ROA d’ARINexplique que son gestionnaire automatique IRR peut créer des objets de route correspondants mais permet également de gérer les objets IRR indépendamment. Supprimer un ROA peut laisser un objet IRR si l’utilisateur le souhaite, et supprimer un objet IRR ne modifie pas le ROA correspondant. Leguide de l’API IRR d’ARINdocumente de même les opérations distinctes de création, mise à jour et suppression des objets de route.

Cette indépendance est utile pendant la migration mais dangereuse à la sortie. Un bailleur peut supprimer le ROA et supposer que l’ancienne autorisation de route a disparu tandis qu’un fournisseur amont continue de construire un filtre à partir d’un objet IRR obsolète. Un autre fournisseur amont peut utiliser uniquement le RPKI. Un troisième peut combiner les données avec des enregistrements clients manuels. Le même préfixe peut donc rencontrer différentes décisions d’acceptation.

L’inventaire de sortie devrait répertorier chaque objet route et route6 connu, le mainteneur, l’IRR source et l’origine. La partie ayant autorité pour supprimer chaque objet doit être identifiée avant la résiliation. Les données répliquées peuvent persister après le changement de l’objet faisant autorité, donc les vérifications devraient distinguer la source des copies.

Le fournisseur amont direct devrait divulguer quelles informations ont créé son filtre et confirmer que l’entrée client elle-même a été supprimée. Attendre une reconstruction automatisée peut être acceptable si le moment est connu et surveillé. Une exception manuelle devrait être supprimée explicitement.

Le bailleur devrait également éviter de créer un faux nouvel enregistrement avant que le successeur ne soit prêt. Publier l’origine du preneur suivant trop tôt peut autoriser ou filtrer une route qui ne devrait pas encore exister. La préparation peut avoir lieu dans une fenêtre de changement contrôlée, mais l’activation et la clôture de l’ancienne route devraient être séquencées.

Le nettoyage IRR n’est pas spectaculaire, c’est pourquoi il est souvent omis. Pourtant, un objet de route obsolète est une déclaration durable que d’autres réseaux peuvent encore utiliser. Une location sûre exige que les déclarations d’autorité prennent fin lorsque l’autorité prend fin, que ces déclarations soient cryptographiques, contractuelles ou basées sur les registres.

Le DNS inversé fait partie de l’identité opérationnelle

Le DNS inversé survit souvent à la route parce que sa défaillance est moins visible qu’une panne BGP. Cela ne le rend pas inoffensif.

Leguide de délégation inverse de RIPE NCCexplique que le DNS inversé mappe les adresses sur des noms viain-addr.arpapour IPv4 et que les serveurs de noms délégués sont représentés dans des objets de domaine gérés par le registre. Les applications, les systèmes de messagerie, les journaux et les intervenants en incident peuvent s’appuyer sur ces noms.

Avant la sortie, identifiez qui exploite les serveurs inverses faisant autorité et qui peut modifier la délégation. Si le preneur les gère, le bailleur a besoin d’une destination pour la zone post-bail: ses propres serveurs, un service temporaire neutre ou les serveurs du prochain opérateur lorsqu’ils sont prêts. Le service de réception devrait être configuré avant le changement de délégation.

Le contenu exige de l’attention. Les enregistrements PTR nommant les hôtes de messagerie, les points de terminaison VPN ou les clients de l’ancien preneur ne devraient pas persister dans l’utilisation suivante. Ils peuvent induire en erreur la réponse aux incidents et interférer avec la politique de messagerie. Pourtant, supprimer toute la zone trop tôt peut casser un service actif pendant la migration. Comme pour le routage, l’état de préparation précède le nettoyage destructif.

Les valeurs TTL devraient être examinées à l’avance. Les réduire peu avant le changement peut réduire les réponses obsolètes, mais seulement si cela est fait suffisamment tôt pour que les valeurs précédentes expirent. Les parties devraient tester la délégation et des réponses PTR représentatives depuis l’extérieur de leur propre réseau après le basculement.

Les sous-délégations créent une autre couche. Un preneur peut avoir délégué des portions d’une zone inverse à des clients. Ces clients ont besoin d’un préavis et d’une date finale. Le bailleur devrait savoir si l’arbre de délégation contient des zones enfants avant de déclarer le préfixe propre.

Le successeur ne devrait pas hériter accidentellement des anciens noms. Une position inverse neutre, vide ou générique, peut être plus sûre pendant un court intervalle de préparation que de publier immédiatement des noms pour la prochaine utilisation. Le choix approprié dépend des exigences de messagerie, des clients et du service.

Le DNS inversé prouve pourquoi une ligne Whois ou RDAP modifiée ne suffit pas. L’enregistrement du titulaire peut rester stable tout au long d’un bail tandis que la dénomination opérationnelle change deux fois. Une sortie sûre suit l’autorité réellement utilisée, pas seulement l’enregistrement public le plus visible.

Le transfert de contacts RDAP doit refléter honnêtement les rôles

RDAP est un moyen structuré de récupérer les informations d’enregistrement. Il devrait aider les opérateurs à trouver la bonne partie, mais on ne peut pas lui demander de divulguer une relation qui n’a jamais été enregistrée.

LaRFC 9083définit les réponses JSON et les structures de données communes utilisées par RDAP, y compris les entités, les rôles, les avis, les événements et les liens. La mise en œuvre du RIR et les pratiques de confidentialité déterminent quels contacts apparaissent pour une ressource particulière. Un bail peut laisser le bailleur comme titulaire direct tout en confiant la responsabilité technique ou d’abus au preneur via une réattribution, une réallocation ou des enregistrements séparés lorsque cela est pris en charge.

À la sortie, mettez à jour uniquement ce qui a réellement changé. Si le contact technique ou d’abus du preneur apparaît publiquement, supprimez-le ou remplacez-le lorsque la responsabilité prend fin. Si le bailleur est resté le seul contact visible, confirmez que ses services d’abus et de routage peuvent traiter les rapports après le départ du preneur. N’insérez pas l’opérateur suivant avant qu’il n’ait accepté la fonction.

L’exactitude des contacts est importante pendant la période d’observation. Les réseaux peuvent voir une route persistante et utiliser RDAP ou Whois pour trouver de l’aide. Si l’enregistrement pointe uniquement vers un employé parti, la remédiation ralentit. Leprogramme d’opérateurs de réseau MANRSconsidère les informations de contact actuelles et accessibles mondialement comme une obligation de base de résilience du routage pour cette raison.

Les parties devraient conserver les preuves historiques en privé même après le changement des contacts publics. Le bailleur peut avoir besoin de transmettre un rapport d’abus concernant un comportement pendant le bail à l’ancien preneur. L’ancien preneur peut avoir besoin de montrer qu’un incident ultérieur s’est produit après le retrait. Les périodes de conservation et les obligations de confidentialité devraient être spécifiées.

La sortie RDAP a également des limites d’interprétation. Une réponse actuelle n’est pas un historique complet de chaque bail, route ou contact. Un événement de dernière modification ne prouve pas l’heure exacte à laquelle une route s’est arrêtée. Les noms d’entité peuvent refléter la structure d’enregistrement plutôt que le fonctionnement quotidien. L’enregistrement de sortie devrait utiliser RDAP comme une couche, pas comme un certificat de propreté complet.

L’objectif public est simple: une personne répondant à un problème de route, d’abus ou de DNS inversé devrait atteindre un acteur qui a actuellement le pouvoir et le devoir d’aider.

Le nettoyage de la réputation nécessite un enregistrement avant-après

La réputation d’une adresse n’est pas un score public unique. Les fournisseurs de messagerie, les sociétés de sécurité, les systèmes de fraude, les services de géolocalisation et les réseaux privés observent des comportements différents et mettent à jour à des vitesses différentes.

Le bail devrait commencer par une référence datée et se terminer par une autre. Pour chaque /24 ou unité opérationnelle plus petite lorsque les outils le permettent, enregistrez l’état connu des listes de blocage, l’utilisation de la messagerie, les cas d’abus, l’exposition aux proxys ou à l’hébergement, la géolocalisation et toute restriction spécifique au service divulguée par le preneur. La comparaison ne révélera pas tous les modèles privés, mais elle crée un point de départ factuel pour les litiges et la réutilisation.

Levérificateur de réputation IP et domaine de Spamhausen est un exemple public. Songuide de dépannageexplique qu’un listage peut affecter la livraison des courriels et que la remédiation peut dépendre de la correction du comportement, du PTR et de l’identité de messagerie avant de demander le retrait. Ses directives XBL notent également que différents réseaux peuvent synchroniser les retraits à des vitesses différentes. C’est pourquoi un résultat propre dans un outil à un moment donné ne peut pas certifier une réputation universelle.

Le preneur devrait clore les cas d’abus actifs, arrêter les services clients, supprimer les systèmes compromis et fournir les preuves nécessaires à un délistage légitime. Le bailleur ne devrait pas déposer une fausse demande de retrait tant que la cause est active, ni traiter chaque listage historique comme une contamination permanente. L’utilisateur suivant devrait recevoir l’historique connu et toute réserve restante appropriée à la transaction.

Le temps de refroidissement devrait être basé sur le risque. Un préfixe d’entreprise stable utilisé pour VPN sans messagerie et sans historique d’abus significatif peut être prêt peu de temps après le nettoyage du routage et de l’identité. Un préfixe utilisé pour des proxys ouverts, du courrier à haut volume ou des clients d’hébergement changeant rapidement peut nécessiter une observation plus longue, des tests plus stricts et une réutilisation progressive. Une quarantaine fixe de trente jours pour chaque bloc gaspille une capacité rare sans nécessairement traiter la cause.

La remédiation de la réputation interagit également avec le DNS inversé et RDAP. Une demande de délistage peut exiger la partie contrôlant le bloc ou le service d’abus du FAI. Des contacts obsolètes peuvent empêcher l’ancien ou le nouvel opérateur de prouver son autorité. Un PTR nommant l’ancien hôte de messagerie peut compromettre la configuration du successeur.

Le bailleur et le preneur devraient répartir les coûts en fonction de la cause et de la divulgation. Les problèmes préexistants documentés appartiennent à la référence d’entrée. Les dommages créés pendant le bail peuvent justifier une réserve de nettoyage, une retenue ou un remboursement. Les scores privés inconnus restent une limitation qu’aucune des parties ne peut éliminer complètement.

L’objectif n’est pas de promettre un préfixe parfaitement propre. C’est de laisser un préfixe documenté dont le risque de réputation restant est suffisamment connu pour être évalué et géré.

Expiration programmée, violation et urgence sont des sorties différentes

Une seule séquence de sortie ne peut pas convenir à toutes les raisons de résiliation.

L’expiration programmée est le cas le plus facile. Le préavis est long, la capacité de remplacement peut être préparée, les clients peuvent migrer, le trafic peut s’écouler et chaque couche administrative peut être réconciliée. Le contrat devrait en faire la situation par défaut plutôt que de compter sur des renouvellements informels répétés.

Le non-renouvellement après un désaccord commercial permet encore une planification si le préavis est donné à temps. Les parties peuvent ne pas s’apprécier, mais aucune n’a intérêt à créer des pannes pour des tiers ou des routes contestées. Une option de grâce limitée peut isoler la migration du désaccord.

La résiliation pour non-paiement nécessite une période de régularisation proportionnée au service et aux préavis antérieurs. Le bailleur ne devrait pas être contraint de financer une utilisation indéfinie, mais la suppression immédiate du ROA peut ne pas arrêter la route et peut nuire aux clients avant de garantir le paiement. Une coordination directe avec le fournisseur amont et une date de retrait stricte sont plus fiables.

Un abus actif ou une compromission de sécurité peut exiger une action plus rapide. La route concernée peut devoir être filtrée, un client déconnecté, des identifiants désactivés ou un ROA corrigé. Le fournisseur direct et les contacts d’incident devraient agir ensemble. « Urgence » devrait être définie par des preuves et l’impact, et non utilisée comme étiquette pour chaque violation.

L’insolvabilité ou la disparition est encore différente. Le preneur peut ne plus avoir de personnel capable de se retirer. L’accord avec le fournisseur amont et le contrôle des filtres deviennent critiques. Le bailleur peut devoir contacter directement les fournisseurs de réseau, préserver les preuves et chercher un recours juridique. Le calendrier d’entrée devrait autoriser le fournisseur amont à accepter une instruction de clôture du bailleur après une preuve définie et des tentatives infructueuses de joindre le preneur.

Un tribunal ou un régulateur peut ordonner une action qui outrepasse la séquence ordinaire. Les parties devraient conserver l’ordre, identifier exactement quels préfixes et actes il couvre, et éviter de l’étendre par interprétation. Le nettoyage technique nécessite encore une vérification après la mise en conformité.

Différentes sorties peuvent partager un principe: utiliser l’action la plus étroite qui arrête le risque pertinent tout en préservant les clients non liés lorsque c’est possible. Une facture contestée n’est pas une route compromise. Une route compromise n’est pas une excuse pour une saisie indéfinie du portefeuille. La précision protège la location à la fois des abus et des réactions excessives.

La réutilisation nécessite un test d’acceptation

La fin de l’ancien bail n’est pas automatiquement le début d’une nouvelle utilisation sûre. Le bailleur a besoin d’un test d’acceptation avant de remettre le préfixe à un successeur.

Premièrement, confirmez l’absence de route ou la visibilité approuvée du successeur à partir de plusieurs observations sur la période convenue. Vérifiez les agrégats et les préfixes plus spécifiques. Confirmez que l’ancien fournisseur amont a supprimé l’autorisation client. Enquêtez sur toute origine résiduelle plutôt que de supposer qu’elle est inoffensive.

Deuxièmement, réconciliez les autorisations. L’ancienne origine ne devrait pas rester dans des ROA actifs ou des objets de route IRR faisant autorité. Tout certificat délégué devrait être fermé ou contraint correctement. L’autorisation du successeur ne devrait apparaître que lorsque sa route est prête.

Troisièmement, testez le DNS inversé et les contacts. Les serveurs de noms faisant autorité doivent répondre comme prévu, les anciennes sous-délégations devraient avoir disparu et les enregistrements PTR représentatifs ne devraient pas identifier l’ancien opérateur. RDAP ou Whois devrait orienter les rapporteurs d’incidents vers une partie responsable actuelle.

Quatrièmement, évaluez la réputation. Réexécutez les mêmes vérifications publiques utilisées à l’entrée et enregistrez les cas non résolus, le décalage de géolocalisation et les restrictions de messagerie. Le test devrait indiquer l’incertitude plutôt que de convertir une visibilité partielle en garantie.

Cinquièmement, vérifiez les résidus clients et applicatifs connus du bailleur. Un trafic entrant inattendu peut révéler des dépendances obsolètes, mais les observations de paquets doivent être traitées de manière légale et minimale. L’objectif est de détecter un maintien matériel, pas d’inspecter les communications des anciens clients.

Le résultat de l’acceptation peut être vert, conditionnel ou bloqué. Vert signifie que les couches connues sont réconciliées et que l’incertitude restante est ordinaire. Conditionnel signifie que la réutilisation est possible pour un usage limité qui ne dépend pas de la couche non résolue; par exemple, une infrastructure sans messagerie peut tolérer un problème de réputation spécifique à la messagerie. Bloqué signifie qu’une ancienne route active, une délégation non résolue ou un abus continu grave rend la nouvelle attribution dangereuse.

L’acceptation devrait produire un enregistrement de transfert compact: préfixe, origine antérieure, heure de retrait, fenêtre d’observation, état RPKI et IRR, état DNS, état des contacts, conclusions sur la réputation, exceptions et approbateur. Cet enregistrement aide le successeur à distinguer les conditions héritées de sa propre exploitation ultérieure.

Le test ne doit pas devenir un nouveau gardien pour chaque modèle économique. C’est un contrôle qualité du vendeur pour une ressource opérationnelle rare. Une réutilisation rapide et une réutilisation prudente sont compatibles lorsque les preuves sont recueillies en continu plutôt qu’après l’échéance.

Les incitations devraient récompenser un retour propre

Les baux se terminent mieux quand l’économie rend le nettoyage précieux avant que le conflit ne commence.

Un dépôt de garantie ou une retenue sur le paiement final peut être lié à des conditions de retour mesurables: retrait des routes, clôture amont, réconciliation ROA et IRR, transfert du DNS inversé, correction des contacts et remise de l’enregistrement de sortie. Le montant devrait refléter le coût probable du nettoyage, et non servir de pénalité cachée.

Le preneur peut obtenir une libération plus rapide en se préparant tôt et en fournissant des preuves complètes. Si le bailleur retarde son propre acte de ROA ou de DNS inversé, le preneur ne devrait pas perdre la retenue à cause de ce retard. Chaque condition doit correspondre à l’acteur qui la contrôle.

Une grâce pré-tarifée crée une autre incitation utile. Le preneur connaît le coût du temps de migration supplémentaire, et le bailleur peut tarifer la réutilisation retardée. L’échec d’un jalon peut augmenter les rapports ou raccourcir l’option. Un retour anticipé réussi peut réduire la charge finale.

Le bailleur devrait éviter de réserver le préfixe de manière si serrée qu’un quelconque retard de convergence ordinaire crée une rupture avec le successeur. Un court intervalle de préparation peut être intégré dans le portefeuille. Le preneur suivant bénéficie également de recevoir un bloc plus propre avec un état documenté.

Les fournisseurs de transit peuvent améliorer le marché en proposant des engagements standard d’intégration et de clôture de préfixe. Des délais publiés, des exigences de preuves et des contacts d’urgence réduisent les exceptions de dernière minute. Les fournisseurs contrôlent déjà le point d’acceptation le plus proche; traiter la clôture comme un service plutôt qu’une faveur informelle rend la responsabilité plus claire.

Les réserves de réputation devraient être basées sur des preuves. Un bailleur ne devrait pas retenir de l’argent simplement parce qu’un score public a changé après le bail si le changement n’est pas lié ou préexistant. Un preneur ne devrait pas nier sa responsabilité pour un abus actif documenté pendant son utilisation. Des instantanés d’entrée et de sortie réduisent la dispute.

Ces mécanismes soutiennent la location plutôt que de la supprimer. Un marché devient plus liquide lorsque les entités savent que les ressources peuvent revenir à temps, les clients peuvent migrer sans surprise et le prochain utilisateur n’héritera pas de débris opérationnels non tarifés.

La discussion de Lu Heng sur lalocation IPv4 géréesouligne que l’opérabilité se poursuit après la transaction visible. La sortie propre est l’autre moitié de cette proposition. La valeur de la location gérée n’est pas seulement d’obtenir une route; c’est de pouvoir en terminer une sans perdre le contrôle des clients, des identifiants ou de la prochaine utilisation du préfixe.

Un reçu de sortie sûr est plus fort qu’une ligne Whois modifiée

L’erreur persistante est de traiter l’enregistrement du titulaire public comme preuve que tout le reste a changé. Dans de nombreux baux, le titulaire ne change jamais, donc Whois ou RDAP peut sembler identique avant, pendant et après l’utilisation opérationnelle. Même lorsque les contacts changent, la route, le ROA, l’IRR, la zone inverse et la réputation peuvent raconter des histoires différentes.

Un reçu de sortie sûr associe ces histoires sans prétendre qu’elles forment un seul système. Il enregistre la fin commerciale, la fenêtre de migration, l’heure de la route finale, la clôture du fournisseur direct, le nettoyage des autorisations, le nettoyage des délégations, la position des contacts, l’état de la réputation et les limites d’observation. Il nomme les exceptions non résolues.

Le reçu est utile à chaque partie. Le bailleur peut réutiliser ou relouer avec des preuves. L’ancien preneur peut montrer quand sa responsabilité a pris fin. Le fournisseur amont peut clore proprement une autorisation client. Le successeur peut comprendre les conditions héritées. Un enquêteur peut distinguer les données obsolètes de l’utilisation actuelle.

Aucun reçu ne peut prouver que chaque routeur sur Internet a oublié la route ou que chaque modèle de réputation privé a été mis à jour. C’est pourquoi les sources d’observation et leurs limites importent. Les collecteurs de routes ont des pairs limités. Les caches se rafraîchissent à des moments différents. Les listes blanches privées peuvent persister. Un enregistrement solide indique ce qui a été testé, quand et d’où.

La norme devrait rester proportionnée. Un petit bail stable avec un seul fournisseur amont et sans délégation inverse nécessite moins de travail qu’un bloc d’hébergement multi-fournisseurs avec des sous-délégations clients et une utilisation de messagerie. Les couches requises sont les mêmes; la profondeur suit le risque.

Surtout, le reçu ne devrait pas devenir une excuse pour bloquer le retour pour toujours. Si l’ancienne route a disparu, l’autorisation directe est fermée, les autorisations sont réconciliées et les risques d’identité connus sont documentés, l’incertitude ordinaire peut être tarifée. La rareté rend le temps d’inactivité inutile coûteux.

Un retour sûr n’est donc ni un nettoyage instantané ni une quarantaine indéfinie. C’est une décision raisonnée fondée sur des preuves convergentes.

La location fonctionne quand la sortie fait partie du produit

La location IPv4 résout un problème réel. Les opérateurs ont besoin d’adresses sans toujours acheter un bloc permanent; les titulaires peuvent mettre une capacité inutilisée au travail; les clients peuvent lancer des services malgré la rareté. Plaider pour une sortie sûre n’est pas plaider contre ce marché.

C’est plaider contre l’idée qu’une date de fin privée se propage automatiquement à travers le routage mondial et ses enregistrements de soutien. Le marché devient fragile lorsque l’activation est gérée avec soin mais que la résiliation est laissée à un courriel final.

Un bail mature commence par le calendrier de sortie. Il inventorie les dépendances, donne un préavis significatif, tarife la grâce, prépare le service de remplacement, déplace les clients, draine le trafic, retire chaque origine, ferme les filtres amont directs, supprime les autorités RPKI et IRR obsolètes, transfère le DNS inversé, corrige les contacts, enregistre la réputation et teste l’état de préparation pour la réutilisation.

Chaque acteur a un devoir clair. Le preneur migre les clients et se retire. Le fournisseur amont ferme l’acceptation. Le bailleur gère les autorisations résiduelles et la prochaine utilisation. Les registres et services publics reflètent les changements dans leur domaine réel. Les preuves circulent entre eux.

La séquence protège à la fois la continuité et la révocation. Les clients ne sont pas déconnectés simplement pour prouver qu’une date de contrat est réelle. Les anciens preneurs ne conservent pas une autorisation de routage indéfinie simplement parce que des clients dépendaient autrefois des adresses. Les bailleurs n’héritent pas de dommages de réputation inexpliqués. Les successeurs ne découvrent pas d’autorités obsolètes après le lancement.

À minuit, le droit légal peut prendre fin. À l’aube, l’ancienne route devrait soit avoir disparu, soit n’être présente que dans le cadre d’une période de migration documentée, en déclin et limitée dans le temps. Peu après, les enregistrements publics et opérationnels devraient converger vers la nouvelle réalité.

Ce n’est pas une tolérance pour le routage non autorisé. C’est ainsi que l’autorisation est retirée de manière suffisamment sûre pour être définitive.