Résumé

  • Un objet de route IRR indique qu'un préfixe peut être annoncé par un AS désigné au sein d'une source de registre. Il s'agit d'une déclaration utilisée pour élaborer des politiques, non d'une observation en direct du BGP, d'un certificat de ressource ou d'une déclaration concluante de titre légal.
  • La chaîne opérationnelle habituelle développe un AS ou un AS-SET, récupère les objets de route et route6 correspondants à partir de sources IRR sélectionnées, compile les préfixes résultants en un filtre et déploie ce filtre sur les sessions clients ou de peering. Un objet obsolète a de l'importance lorsqu'il survit à cette chaîne de sélection et de compilation.
  • Déplacer un réseau peut signifier changer de transit tout en conservant l'AS d'origine, changer d'origine tout en conservant le détenteur du préfixe, transférer le préfixe, passer d'une région de service RIR à une autre ou utiliser un fournisseur d'atténuation temporaire. Chaque événement exige un jugement différent quant aux objets de route qui doivent subsister.
  • Les entrées périmées persistent parce que la partie motivée pour créer un remplacement n'est souvent pas celle qui détient les anciennes informations d'identification du mainteneur. Les anciens fournisseurs ont peu d'incitations commerciales à nettoyer, le personnel et les comptes disparaissent, et les bases de données indépendantes n'ont pas de transaction commune qui retire chaque doublon.
  • Ni une discordance avec le BGP actuel ni le seul âge ne prouvent qu'un objet doit être supprimé. Les routes de secours peuvent être dormantes, les annonces prévues peuvent être préparées avant utilisation et une route observée peut elle-même être non autorisée. Les données RPKI, les enregistrements d'enregistrement, l'authentification du détenteur, les avis et les observations BGP bornées doivent être combinés.
  • La suppression peut interrompre la joignabilité lorsque les opérateurs reconstruisent automatiquement les filtres. Une migration sûre consiste à faire avant de défaire: établir la nouvelle déclaration prévue dans une source appropriée, tester comment les consommateurs désignés résolvent les conflits, notifier les parties concernées, supprimer l'autorité remplacée, vérifier les miroirs puis vérifier le déploiement du filtre.
  • Un détenteur de ressource a besoin d'un intérêt pour contester un objet de route couvrant son préfixe même lorsqu'un autre mainteneur contrôle l'entrée. Le registre doit également fournir au mainteneur répertorié un avis, une raison, un enregistrement des preuves, un chemin de révision d'urgence et une étape de suspension réversible où le risque de suppression erronée est important.
  • Une Société des ressources numériques peut définir un reçu de migration portable, des tests de qualité des sources et des devoirs réciproques pour les détenteurs, les registres et les opérateurs. Elle ne devrait pas s'auto-désigner comme une autorité de routage universelle ni prétendre que les observations sur des réseaux sélectionnés prouvent la convergence globale des filtres.

Une route peut partir alors que sa déclaration demeure

Prenons une entreprise qui a annoncé le même bloc d'adresses via un système autonome pendant des années. Elle achète un service auprès d'un autre opérateur, modifie sa conception de routage et commence à annoncer via un autre AS. Le nouveau fournisseur demande un objet de route avant d'ouvrir son filtre. L'entreprise en crée un dans un registre accepté par ce fournisseur. Le trafic bascule. L'ancien opérateur est déconnecté. Pourtant, un objet de route nommant l'ancienne origine reste sous un compte de mainteneur contrôlé par un ingénieur parti depuis longtemps, dans une base de données que l'entreprise n'utilise plus.

Rien dans BGP ne supprime automatiquement cette déclaration. BGP distribue la joignabilité; il n'envoie pas d'instruction d'annulation à chaque registre de routage lorsqu'une relation commerciale prend fin. Un nouvel objet de route ne remplace pas non plus tous les anciens objets par une règle universelle. Les paires préfixe-origine anciennes et nouvelles peuvent coexister dans différentes bases de données, ou dans la même lorsque leurs clés diffèrent. Un miroir peut renvoyer les deux.

Un constructeur de filtre peut inclure l'une, l'autre ou les deux en fonction de ses sources sélectionnées, de l'ordre des requêtes, des paramètres de suppression et de la méthode d'expansion.

Le risque qui en résulte est souvent mal compris. Un ancien objet de route ne fait pas qu'un routeur annonce une route. Il peut, en revanche, amener un système de filtrage à considérer une ancienne combinaison origine-préfixe comme éligible. Si l'ancien AS annonce le préfixe par erreur ou malveillance, un réseau dont la politique admet encore cette combinaison a une barrière de moins. Dans le sens inverse, la suppression d'un objet encore requis par un fournisseur peut entraîner le rejet de l'annonce légitime lors de la prochaine actualisation du filtre.

La persistance crée une permission résiduelle; la suppression négligente crée un risque de perte de joignabilité.

C'est pourquoi le problème est institutionnel plutôt que simplement clérical. Différentes parties contrôlent l'enregistrement du préfixe, l'AS d'origine, l'objet de route, le miroir, le générateur de filtre et les routeurs. Le déplacement du réseau modifie certaines de ces relations mais peut laisser les anciennes informations d'identification et déclarations intactes. Une migration solide doit transférer la reconnaissance opérationnelle tout au long de la chaîne tout en préservant un moyen de contester les erreurs.

L'objet de route de 1995 séparait l'attribution de l'intention de routage

L'objet de route est apparu avec un acte utile d'hygiène conceptuelle. La RFC 1786, publiée en 1995, a séparé les informations d'attribution d'espace d'adressage des informations sur une annonce de routage. Un objet de route identifiait un préfixe exact et un AS d'origine. Lorsqu'une route pouvait être annoncée par plus d'un AS, le registre pouvait contenir plusieurs objets. La conception reconnaissait un fait qui reste important: l'organisation enregistrée comme détenant ou recevant de l'espace d'adressage et l'AS injectant une route sont liés, mais ce ne sont pas le même fait.

RPSL a par la suite normalisé la représentation. La RFC 2622 a fait de la paire préfixe et origine la clé de classe. Elle décrivait également les mainteneurs, les ensembles de routes, les ensembles d'AS et les expressions de politique qui pouvaient être traités par logiciel. L'objet n'était pas conçu comme une prose pour un annuaire passif. Il était destiné à être combiné avec d'autres objets afin que les opérateurs puissent vérifier les politiques et générer des configurations. La RFC 2650 montrait le pont pratique entre le RPSL publié et la configuration de routeur spécifique au fournisseur.

Cette histoire explique à la fois la longévité et l'inadéquation du système. Les objets textuels étaient portables, publics et automatisables à une époque où la coordination interdomaine avait besoin d'un langage commun. La distribution entre les registres correspondait au caractère distribué de l'administration du réseau. Cependant, l'objet de route n'avait pas de conscience automatique d'une résiliation de contrat ultérieure, d'une fusion, d'un transfert ou d'un changement dans la table de routage en direct. Sa durabilité était un atout pour des politiques stables et un handicap pour la succession.

Le modèle précoce incluait même un attributwithdrawndans la spécification précédente. Marquer une ancienne route comme retirée pouvait préserver les informations de routage historiques sans les présenter comme actuelles. La pratique opérationnelle moderne s'est généralement centrée sur les objets route et route6 actuels, la suppression, la sélection des sources et l'historique externe. La question de gouvernance sous-jacente n'a pas disparu: qui peut déclarer qu'une intention de routage antérieure a pris fin, et comment cette décision parvient-elle à chaque consommateur qui a converti la déclaration en politique?

La réponse ne peut pas être simplement "celui qui peut encore se connecter". Les informations d'identification sont nécessaires pour la maintenance ordinaire, mais un agencement de connexions abandonné ne devrait pas figer une permission obsolète pour toujours. La réponse ne peut pas non plus être "celui qui annonce actuellement le préfixe". Le BGP observé est une preuve d'utilisation, pas une autorité auto-authentifiante. La séparation introduite en 1995 doit être maintenue pendant la migration, et non supprimée par commodité.

Un objet de route n'est ni la route ni la ressource

Trois enregistrements sont facilement confondus. Un registre de numéros enregistre l'organisation à laquelle un bloc d'adresses est attribué, assigné ou autrement enregistré selon ses règles. Un objet de route IRR enregistre un préfixe et un AS d'origine prévu dans une source de registre de routage nommée. Les collecteurs BGP observent les annonces qui sont apparues à des points d'observation particuliers. Chacun répond à une question différente.

L'enregistrement d'enregistrement peut étayer une affirmation sur qui peut gérer la ressource dans le système administratif d'un RIR. Il ne montre pas que le détenteur achemine actuellement le préfixe ou quel fournisseur il a autorisé. L'objet de route exprime l'intention de routage, mais la force de cette expression dépend des contrôles d'admission et de mise à jour de la base de données. L'observation BGP montre qu'une origine était visible, mais pas si le détenteur de la ressource y a consenti. Considérer un seul comme une preuve complète rend la migration soit dangereuse, soit impossible.

RPKI ajoute une déclaration plus forte et plus étroite. Une autorisation d'origine de route valide peut lier cryptographiquement une autorité d'adresse certifiée à un AS d'origine et aux longueurs de préfixe autorisées. Cela la rend très pertinente pour décider si un objet de route IRR entre en conflit avec l'intention actuelle du détenteur. Elle ne reproduit toujours pas toute la politique RPSL, ne prouve pas une relation commerciale et ne montre pas qu'une route est active.

Un détenteur peut préparer une ROA avant l'annonce; une route peut être NotFound parce qu'aucune ROA de couverture n'existe; et un détenteur qui se trompe peut autoriser une mauvaise origine.

La question de l'objet périmé doit donc être posée précisément. Ce n'est pas "cet objet diffère-t-il du BGP d'aujourd'hui?" C'est "cet objet continue-t-il d'exprimer une possibilité de routage actuelle et autorisée, et les consommateurs désignés doivent-ils encore le convertir en permission?" Une route de secours peut être absente de la table globale mais valide. Un fournisseur de nettoyage temporaire peut n'apparaître que lors d'une attaque. Une ancienne origine de transit peut rester visible dans un collecteur parce que le retrait n'a pas atteint tous les chemins. Une route récemment détournée peut sembler actuelle.

Les preuves doivent être comparées par fonction. L'enregistrement établit la légitimité administrative. L'authentification du détenteur établit qui demande. RPKI peut établir l'intention d'origine certifiée là où il est déployé. Les enregistrements de contrat ou de changement établissent le mouvement prévu. Les observations BGP montrent l'état opérationnel. La réponse de l'ancien mainteneur peut expliquer un enregistrement par procuration ou un service continu. Aucun registre responsable ne devrait utiliser un signal pratique comme un oracle universel de suppression.

Les filtres transforment le texte historique en permission actuelle

La force pratique de l'objet de route apparaît dans la procédure de construction de filtre d'un opérateur. Un réseau de transit peut demander à un client un nom d'AS-SET. Le logiciel développe récursivement cet ensemble en numéros d'AS, recherche les objets route et route6 dont les origines correspondent à ces AS, obtient les préfixes pertinents et émet une liste de préfixes ou un fragment de politique. L'opérateur examine ou déploie automatiquement le résultat sur la session eBGP du client. Les réseaux de peering et les serveurs de route peuvent utiliser des variantes de la même méthode.

L'utilitairebgpq4rend cette conversion explicite: il génère des listes de préfixes, des filtres de route et des listes de chemins AS à partir des données IRR, et il permet à l'appelant de spécifier les sources IRR à utiliser. Le service de requête de RADb permet également à un client de sélectionner des sources et renvoie autrement des informations collectées à partir de plusieurs registres. IRRd peut ordonner les sources par défaut, appliquer la suppression RPKI, appliquer des filtres de portée et supprimer les objets de route chevauchants de préférence inférieure. La réponse de la base de données est donc une entrée façonnée par la politique locale, et non un ensemble globalement canonique.

Un ancien objet a plusieurs effets possibles. Si un filtre est construit pour l'ancien AS d'origine, l'ancien préfixe peut rester sur la liste autorisée de cet AS. Si l'AS-SET d'un client contient toujours l'ancienne origine ou un aval obsolète, l'expansion récursive peut entraîner le préfixe dans une politique plus large. Si l'instance IRR consommatrice inclut toutes les sources miroitées sans préférence, une copie dans une base de données indépendante peut survivre après la suppression d'une copie autorisée.

Si l'opérateur n'actualise jamais sa configuration générée, même une suppression correcte peut ne pas supprimer l'ancienne permission du routeur.

L'inverse importe également. Un nouvel objet de route peut être parfaitement autorisé dans sa base de données d'origine et ne pas parvenir à un opérateur dont le miroir est en retard, dont la liste de sources choisie exclut cette base de données ou dont le travail de configuration n'a pas été exécuté. La migration n'est pas terminée à l'acceptation par le registre. L'acceptation commence une séquence de distribution, de sélection, de compilation, de révision et de déploiement.

L'unité de gouvernance pertinente est donc le filtre effectif, et non simplement l'objet stocké. Les registres devraient publier suffisamment d'informations d'état pour indiquer quand une mise à jour est entrée dans leur état autorisé et leurs services de distribution. Les opérateurs devraient enregistrer quel instantané, quelles sources, quelles options de requête et quelle expansion d'ensemble ont produit un filtre déployé. Les détenteurs devraient pouvoir demander si un fournisseur désigné a consommé un changement.

Sans ces reçus, chaque partie peut affirmer en toute honnêteté que sa propre étape a réussi alors que la route reste bloquée ou que la permission obsolète reste active.

Les incitations favorisent la création et négligent la suppression

RFC 7682 a décrit l'asymétrie clairement en 2015. Les clients ont une forte raison d'enregistrer de nouvelles informations de routage lorsqu'un fournisseur ne met pas à jour une liste de préfixes sans cela. L'incitation à supprimer les anciennes informations diminue fortement après un changement de transit, surtout lorsque le nouveau fournisseur n'applique pas la même discipline IRR. Le nouveau circuit dépend de la création; peu de factures dépendent de la suppression.

Le contrôle est également divisé. Un fournisseur peut avoir créé des objets de route pour le compte d'un client sous son propre mainteneur. Cet enregistrement par procuration était pratique pendant le service. À la résiliation, le client peut contrôler le préfixe mais pas les informations d'identification de l'objet. L'équipe réseau de l'ancien fournisseur peut considérer le nettoyage comme un travail pour un ancien client. Le gestionnaire de compte peut ne pas comprendre la conséquence de routage. L'ingénieur d'origine peut être parti.

Un mainteneur peut survivre en tant qu'identité techniquement valide après que l'organisation humaine capable d'agir par son intermédiaire soit devenue injoignable.

Les événements d'entreprise aggravent le problème. Une entreprise change de nom, fusionne, vend une division réseau ou externalise des opérations. L'enregistrement du préfixe peut être mis à jour tandis que les informations d'identification IRR restent auprès du prédécesseur ou d'un sous-traitant. Un transfert d'adresse peut donner au destinataire une légitimité dans le registre de numéros sans lui donner le mot de passe ou la clé référencée par lemnt-byd'un ancien objet de route. Un déplacement entre régions de service RIR peut changer quel IRR intégré est le mieux placé pour authentifier le détenteur de l'adresse, tandis que des objets tiers indépendants restent ailleurs.

Il n'y a pas de pénalité de marché naturelle pour chaque enregistrement obsolète. Si l'ancienne origine n'annonce jamais la route, la plupart du trafic s'écoule normalement. Une entrée périmée peut être ignorée par la génération de filtre pour la nouvelle origine et rester invisible pour le détenteur jusqu'à ce qu'un examen de sécurité, une autre migration ou une tentative de création la rencontre. La fonctionnalité d'objet périmé de RADb reflète cette ambiguïté: elle peut signaler un objet à l'aide de signaux BGP, mainteneur, RIR et autres, mais la marque elle-même ne modifie pas le comportement de requête.

Une information sans devoir assigné peut devenir un avertissement que tout le monde voit et que personne ne ferme.

Une meilleure conception des incitations attache la suppression à l'événement qui crée le changement. La résiliation du transit devrait inclure un inventaire IRR et une obligation de suppression. Le transfert de ressource devrait exposer tous les objets de route découverts avant la finalisation. Les contrats de registre et de fournisseur devraient donner au détenteur actuel une voie de contestation documentée. Les opérateurs qui consomment des données IRR devraient publier leurs pratiques de rafraîchissement et d'exception.

Le nettoyage doit faire partie intégrante de la cessation d'autorité, et non d'un entretien bénévole après la disparition de la relation commerciale.

"Le réseau a déménagé" décrit plusieurs événements différents

Migration est un mot trop large pour une seule règle de suppression. Le cas le plus simple est un changement de transit sans changement d'origine. Le détenteur conserve son ASN et annonce les mêmes préfixes via un nouveau fournisseur amont. L'objet de route peut rester entièrement correct car il lie le préfixe à l'origine inchangée du détenteur, et non à l'ancien fournisseur de transit. Ce qui doit être supprimé peut être une appartenance AS-SET obsolète ou une copie par procuration gérée par le fournisseur, et non la déclaration préfixe-origine elle-même.

Un deuxième cas change d'origine tout en conservant le même détenteur. Une entreprise peut passer d'un service d'origine fournisseur à son propre ASN, changer de réseaux gérés ou placer le contrôle d'origine auprès d'une autre société du groupe. Ici, l'ancien objet de route peut représenter une permission qui devrait expirer. Un chevauchement planifié peut être légitime pendant que les deux origines annoncent durant la transition. La suppression avant que le nouveau fournisseur n'ait reconstruit les filtres peut interrompre le service; une coexistence indéfinie laisse une autorité résiduelle.

Un troisième cas transfère la ressource d'adresse. Le nouveau détenteur enregistré peut conserver temporairement l'ancienne origine, en utiliser une nouvelle immédiatement ou désigner un réseau tiers. L'enregistrement de transfert étaye la légitimité du destinataire à gérer l'intention de routage actuelle, mais il ne révèle pas la route prévue par lui-même. Les anciens objets nécessitent un examen plutôt qu'une suppression mécanique. La même paire préfixe-origine peut rester valide sous un nouveau détenteur, mais son mainteneur et sa chaîne de contacts peuvent encore nécessiter une migration.

Un quatrième cas traverse les régions de registre. L'enregistrement de numéro autorisé et l'IRR intégré préféré peuvent être déplacés, tandis que les objets de route dans une source précédente, RADb ou un autre registre indépendant persistent. Le traitement par le RIPE NCC des objets hors région illustre l'importance de cette limite. Les objets existants ont été réétiquetésRIPE-NONAUTH, la création de nouveaux objets hors région a été arrêtée, et la politique ultérieure a utilisé des preuves RPKI conflictuelles, un avis et une période d'attente pour la suppression. Le statut de la source a changé parce que la capacité de l'institution à authentifier le préfixe a changé.

Les changements opérationnels temporaires forment un cinquième cas. L'atténuation DDoS, les lancements anycast, la reprise après sinistre et les fusions peuvent produire une seconde origine destinée à n'exister que dans des conditions déterminées. Un instantané pris pendant l'activation peut donner l'impression que l'objet temporaire est actuel; un instantané pris pendant la dormance peut le faire paraître périmé. De tels objets nécessitent un but explicite, un propriétaire et des conditions d'examen. Le temps seul est un faible substitut à une portée déclarée.

L'enregistrement de migration doit identifier quel événement s'est produit. Sinon, un registre peut supprimer un objet durable de même origine parce qu'un opérateur a changé, préserver une origine obsolète parce que le détenteur n'a pas changé, ou traiter une autorisation d'urgence temporaire comme permanente. La précision sur l'événement est la première sauvegarde contre à la fois les résidus et le nettoyage erroné.

La protection du mainteneur préserve le contrôle et peut préserver l'abandon

Les mainteneurs RPSL ont résolu un problème essentiel: les déclarations de routage publiques ne devaient pas être modifiables par quiconque ne les aime pas. RFC 2725 a distingué l'authentification de l'autorisation et a décrit commentmnt-by,mnt-routes,mnt-lower, les règles de récupération et les contrôles connexes pouvaient régir les ajouts et les modifications. En fonctionnement ordinaire, le propre mainteneur de l'objet de route autorise la modification ou la suppression. Cela protège les opérateurs contre des ingérences arbitraires.

La hiérarchie était destinée à ajouter un recours. Les mainteneurs d'espace d'adressage et d'AS pouvaient autoriser la création de route; les concepts de récupération pouvaient permettre à une autorité de ressource supérieure de récupérer des objets subordonnés;auth-overridedécrivait une récupération différée lorsqu'un mainteneur était devenu inactif. Le déploiement a toutefois varié, et la conception de dépôt distribué n'est jamais devenue une chaîne d'autorité globale uniforme. RFC 7682 a observé que des informations périmées pouvaient subsister parce que des tiers ne pouvaient pas les supprimer en toute sécurité et parce que la sémantique de dérogation risquait d'agir avant que le détenteur répertorié n'ait reçu un avis effectif.

Les contrôles actuels de la base de données RIPE montrent une réponse pratique dans une région faisant autorité. Un détenteur de ressource actuel peut supprimer de force certains objets de route bloquants via le mainteneur sur un objet d'espace d'adressage de couverture, même sans les informations d'identification propres de l'objet de route. L'autorité est limitée par la hiérarchie des ressources maintenue par le RIPE NCC. Elle permet la suppression, pas la réattribution silencieuse, et elle ne crée pas une légitimité équivalente dans chaque IRR indépendant.

Cette limitation est appropriée. Un registre au service d'un détenteur de ressource ne devrait pas revendiquer le contrôle de toutes les bases de données tierces simplement parce que l'adresse est enregistrée dans sa région. Pourtant, le détenteur ne devrait pas avoir à supplier informellement un mainteneur par procuration abandonné pour toujours. Chaque IRR a besoin d'une règle publiée expliquant quelles preuves donnent une légitimité à un détenteur actuel, quand l'enregistrement d'un autre registre est accepté, quel avis est envoyé, comment une suspension peut être contestée et qui approuve la suppression irréversible.

La protection du mainteneur n'est légitime que lorsqu'elle est associée à la succession. Une information d'identification identifie qui peut exploiter un objet en vertu des règles en vigueur; elle ne prouve pas que l'autorisation sous-jacente reste substantiellement valable pour toujours. L'institution gagne la confiance en préservant le contrôle autorisé pendant le service et en permettant la récupération fondée sur des preuves après que le contrôle a légalement changé.

La mise en miroir distribue la disponibilité et distribue également le retard

L'IRR est une fédération de bases de données plutôt qu'une table unique. Les opérateurs interrogent souvent une instance IRRd qui détient une source locale autorisée et des copies en miroir de plusieurs autres. RADb annonce une vue de requête combinée tirée de registres de tout l'IRR. Le modèle améliore la disponibilité et permet à un constructeur de filtre d'utiliser un seul point d'accès au lieu de contacter chaque registre séparément.

La mise en miroir sépare également le moment de la suppression du moment de la disparition. Une source autorisée accepte un changement. Un journal ou un instantané le rend disponible. Un miroir interroge, valide la séquence et applique la mise à jour. Un miroir en aval peut répéter le processus. Le service de filtre de l'opérateur interroge ensuite sa vue locale selon un calendrier. Le routeur reçoit un changement de configuration ultérieur. Chaque étape a sa propre horloge et ses propres modes de défaillance.

RFC 7682 a documenté les anciennes pratiques NRTM et de fichiers plats, y compris la réplication non sécurisée et des intervalles de rafraîchissement importants. Les implémentations se sont améliorées. L'IRRd actuel peut utiliser des importations, des flux NRTM, des journaux, des numéros de série et des paramètres spécifiques à la source; la conception plus récente de NRTM de RIPE fournit des instantanés versionnés et des deltas avec hachages et identité de source. Une meilleure intégrité du transport et une interrogation plus rapide réduisent l'incertitude.

Ils n'amènent pas un opérateur à sélectionner la bonne source ou à supprimer une copie maintenue indépendamment.

Un objet supprimé dans la source A peut continuer en tant qu'objet distinct dans la source B. Il ne s'agit pas nécessairement d'un décalage de miroir. Il peut avoir été soumis séparément, copié sous un autre mainteneur ou conservé en tant qu'enregistrement non autorisé. À l'inverse, un objet visible à un point d'accès de requête combiné peut être un miroir fidèle dont l'origine autorisée n'a pas encore traité une contestation. Les enquêteurs doivent distinguer la provenance du transport.

La synchronisation inter-bases de données a donc deux significations. La synchronisation technique demande si les miroirs ont appliqué le numéro de série ou l'instantané actuel d'une source. La synchronisation institutionnelle demande si chaque source qui affirme indépendamment l'autorisation remplacée a examiné les mêmes preuves de migration et a atteint un état justifié. La première peut être automatisée par des protocoles de réplication. La seconde nécessite des références communes, des avis réciproques et des décisions responsables.

Un reçu de migration devrait enregistrer les deux. Il nomme l'objet dans chaque source, l'heure de mise à jour autorisée, les observations de miroir et l'état des copies indépendantes. "Supprimé de RADb" ou "mis à jour au RIR" ne suffit pas lorsqu'une autre source sélectionnée renvoie toujours l'ancienne paire. Une équipe ne devrait pas non plus continuer à supprimer aveuglément jusqu'à ce qu'une requête combinée paraisse propre; elle doit savoir quelle institution a fait chaque assertion et en vertu de quelle autorité.

La preuve de la source doit accompagner la demande

La partie qui demande la suppression devrait présenter plus qu'une capture d'écran de la table de routage actuelle. Une demande crédible commence par la légitimité de la ressource: un détenteur actuel authentifié dans le RIR concerné, ou un délégué autorisé dont la portée est claire. Elle identifie le préfixe exact, l'ancienne origine, la nouvelle origine ou l'origine continue, chaque source et mainteneur connus, l'événement de migration et l'état effectif demandé.

Les preuves peuvent ensuite être superposées. Un enregistrement d'enregistrement actuel étaye le contrôle du préfixe en vertu des règles du RIR. Une ROA peut étayer l'intention d'origine actuelle lorsque sa couverture et sa longueur maximale correspondent effectivement à la route en question. Une déclaration signée ou authentifiée du détenteur explique si une ancienne origine est révoquée, conservée pour la sauvegarde ou autorisée jusqu'à une date de transition. Les enregistrements de résiliation ou de transfert du fournisseur peuvent corroborer l'événement sans exiger que les conditions commerciales soient rendues publiques.

Les observations BGP montrent si les anciennes et nouvelles origines sont visibles à des moments et des points d'observation donnés.

L'ancien mainteneur doit également être entendu dans la mesure du possible. Il peut montrer que l'objet couvre une route client active sous un nom d'entreprise différent, qu'un dispositif d'atténuation reste en vigueur ou que le changement d'enregistrement du demandeur est contesté. Le silence après une livraison vérifiée et un délai de réponse défini est une preuve d'absence de réponse, pas une preuve de chaque fait sous-jacent. Le décideur devrait indiquer le poids qu'il a accordé au silence.

Le niveau de preuve devrait augmenter avec la conséquence. La suppression d'un objet clairement invalide selon RPKI dans une vue de requête non autorisée est différente de l'effacement de la seule déclaration sur laquelle un fournisseur critique s'appuie. Une contestation d'urgence impliquant un détournement apparent peut justifier une suppression temporaire et un examen rapide. La suppression permanente dans le cadre d'un transfert ambigu peut nécessiter une authentification plus forte du détenteur, une approbation par deux personnes et la preuve qu'un chemin de remplacement est prêt.

Chaque décision devrait conserver un enregistrement d'audit non public: réclamations soumises, résultats de validation, avis, réponses, conflits, identité du réviseur, heure et motif. La sortie publique peut être plus étroite, exposant l'état de l'objet et une catégorie de motif sans données personnelles ni contrats sensibles. Le but n'est pas la divulgation maximale. C'est la capacité de prouver ultérieurement que l'autorité de routage résiduelle a été supprimée par une règle plutôt que par influence ou accident.

BGP est un témoin, pas un juge

Les données de routage en direct sont indispensables car un IRR existe pour décrire la politique opérationnelle. L'évaluation des objets périmés de RADb compare les paires préfixe-origine avec le BGP et complète les correspondances directes par des signaux de mainteneur, de liaison AS, de RIR et de réputation. Des travaux de mesure récents présentés via RIPE Labs comparent de même les objets de route avec les IRR autorisés, RPKI et la zone sans défaut pour identifier les conflits, la redondance et l'inactivité. De telles méthodes révèlent des modèles que l'inspection statique des registres ne peut pas révéler.

Pourtant, la visibilité BGP a de fortes limites. Les collecteurs voient des pairs sélectionnés, pas toutes les interconnexions privées. Une annonce de secours peut être intentionnellement absente. Une route plus spécifique peut n'apparaître que lors de l'ingénierie du trafic ou de l'atténuation d'attaque. L'agrégation peut donner l'impression qu'un objet de route légitime est inutilisé. Une route peut être visible parce qu'une origine non autorisée a réussi. L'absence d'observation n'est pas une preuve d'abandon, et la présence n'est pas une preuve de consentement.

Les fenêtres temporelles aident mais ne guérissent pas le problème. Un objet qui n'a pas correspondu au BGP observé pendant des années mérite un examen, surtout lorsque les contacts sont morts et qu'un détenteur actuel le conteste. Il peut encore décrire une veille froide ou un préfixe annoncé uniquement dans un domaine de routage limité. Un jeune objet peut être erroné le jour de sa création. L'heure de dernière modification mesure l'interaction avec la base de données, pas la vérité.

Le rôle utile du BGP est probatoire et borné. Une équipe de migration peut nommer des collecteurs, des looking glasses amont ou sa propre télémétrie de session; enregistrer l'origine observée avant, pendant et après la transition; et conserver les résultats contradictoires. Si l'ancienne origine disparaît partout où elle est observée tandis que la nouvelle origine et le filtre de remplacement fonctionnent, la confiance dans la suppression augmente. Si l'ancienne origine persiste, l'équipe cherche s'il s'agit de propagation, de fuite, de chevauchement intentionnel ou d'abus.

Les mesures ne devraient jamais être blanchies en un dénominateur global non étayé. Une étude portant sur des IRR et des collecteurs de routage sélectionnés peut décrire son ensemble de données, ses dates et sa méthode de classification. Elle ne peut pas montrer comment chaque opérateur privé a construit des filtres, combien d'objets dormants étaient légitimes ou combien de migrations ont causé un préjudice au client. Les décisions institutionnelles devraient utiliser les mesures comme des preuves disciplinées, et non comme une certitude décorative.

RPKI peut établir la priorité sans devenir une machine à supprimer

RPKI offre quelque chose que les objets IRR conventionnels ne peuvent généralement pas: une déclaration vérifiable cryptographiquement ancrée dans une autorité de ressource de numéros certifiée. Lorsqu'une ROA actuelle couvre un préfixe et autorise une origine tandis qu'un objet IRR nomme une origine conflictuelle, le conflit est une preuve puissante. La politique RIPE 2018-06 a utilisé cette propriété pour nettoyer les objets de route conflictuels deRIPE-NONAUTH, avec notification et une période de conflit soutenu avant la suppression.

IRRd peut également supprimer les objets de route qui sont invalides selon RPKI et peut exposer des objets pseudo-IRR dérivés de ROA aux outils de filtre existants. ARIN est allé plus loin dans une autre direction en liant la création d'objets de route IRR authentifiés aux ROA via son Auto-Manager IRR. Ces mécanismes réduisent les divergences et donnent aux opérateurs un signal d'origine plus fort sans exiger que chaque système de filtre soit remplacé d'un coup.

Mais trois précautions importent. Premièrement, NotFound n'est pas invalide. S'il n'existe pas de ROA de couverture, RPKI ne fournit aucune autorité conflictuelle. Supprimer chaque objet IRR NotFound punirait les détenteurs qui n'ont pas déployé RPKI et pourrait supprimer des données de routage légitimes. Deuxièmement, une ROA valide peut coexister avec un objet de route pour la même origine tandis que d'autres politiques RPSL restent erronées ou périmées. Troisièmement, une ROA peut contenir une erreur opérationnelle commise par le détenteur légitime. L'autorité cryptographique n'est pas l'omniscience.

La priorité nécessite également une précision au niveau de l'objet. La comparaison doit utiliser correctement la couverture du préfixe, l'origine et la longueur autorisée. Une ROA pour un agrégat avec une longueur maximale restrictive peut rendre invalide un objet de route plus spécifique même lorsque le détenteur destinait cette route plus spécifique à un événement futur. Le remède peut être de corriger la ROA, et non de supprimer l'objet IRR. L'avis permet au détenteur de distinguer un conflit de sécurité d'une erreur de configuration.

La bonne règle est qu'une déclaration cryptographique valide, actuelle et contrôlée par le détenteur mérite un poids probatoire plus élevé qu'une assertion tierce non authentifiée. Elle n'élimine pas la nécessité d'identifier l'événement, d'avertir les opérateurs concernés, de protéger la continuité et d'enregistrer le remède. Une preuve solide devrait rendre la procédure régulière plus rapide et plus exacte, pas superflue.

La suppression doit être échelonnée parce que les filtres ont une mémoire

La séquence de sécurité commence par l'inventaire. Recherchez les IRR de RIR autorisés, les registres indépendants, les services de requête combinés et les ensembles de sources utilisés par les fournisseurs connus. Enregistrez les clés préfixe-origine exactes, les mainteneurs, les contacts, les heures de création et de modification, les étiquettes de source, l'état RPKI et le BGP observé. Développez les AS-SET pertinents car une relation obsolète peut y survivre même après la correction d'un objet de route.

Définissez ensuite l'état terminal prévu. Quelles origines doivent rester autorisées? Quels préfixes et longueurs seront effectivement annoncés? Y a-t-il un chevauchement planifié, un rôle de sauvegarde ou d'atténuation? Quelle source est appropriée pour le détenteur actuel? Qui contrôle chaque objet de remplacement? Cette déclaration empêche le nettoyage de devenir une compétition pour minimiser le nombre d'enregistrements indépendamment de l'objet opérationnel.

Ensuite, faites avant de supprimer. Créez ou corrigez les objets de route prévus via des sources qui peuvent authentifier le détenteur actuel. Créez des ROA cohérentes le cas échéant. Demandez aux opérateurs de transit et de peering désignés d'exécuter un aperçu de leurs filtres générés. Confirmez que la nouvelle origine serait acceptée et que la récursion via les AS-SET produit les préfixes attendus. Un courriel d'acceptation du registre ne peut pas remplacer ce test côté consommateur.

Ce n'est qu'ensuite que les avis de suppression devraient être émis. L'ancien mainteneur, le détenteur actuel de la ressource, le contact AS-origine s'il est disponible et les fournisseurs consommateurs connus reçoivent l'objet exact, la classe de preuve, l'action proposée, la date limite de réponse et le contact d'urgence. Un objet contesté peut être suspendu des vues de requête ordinaires tout en restant récupérable pour les réviseurs, si les règles du registre soutiennent ce remède et que le risque le justifie. La suspension ne doit pas devenir silencieusement une suppression permanente.

Après la décision, chaque source autorisée ou indépendante enregistre son action sous une référence de migration commune. Les miroirs sont vérifiés par rapport aux numéros de série ou aux instantanés de la source. Les requêtes combinées sont répétées avec une sélection explicite des sources. Les opérateurs reconstruisent les filtres, examinent le delta et appliquent le rafraîchissement de route ou leur mise à jour de politique sûre équivalente. Les observations confirment que la route prévue reste acceptée et que l'origine remplacée n'est plus autorisée lors des sessions nommées.

La clôture vient en dernier. Le reçu énumère les sources non résolues, les opérateurs injoignables et toute exception persistante. Si un registre tiers refuse la suppression, le détenteur et les fournisseurs peuvent exclure ou abaisser la préférence de cette source pour le préfixe concerné, mais l'exception reste visible. Un statut vert devrait signifier une achèvement borné, et non que des preuves gênantes ont été omises.

La coordination entre bases de données nécessite un événement commun, pas une base de données centrale

Il est tentant de résoudre l'incohérence en proposant un IRR mondial unique. Cela simplifierait certaines requêtes tout en concentrant la capacité d'admettre, de supprimer et de supprimer les déclarations de routage. L'histoire des registres de routage de l'Internet reflète des différences régionales, de fournisseur et opérationnelles légitimes. La résilience peut bénéficier de multiples services de publication et de requête. L'élément manquant n'est pas nécessairement un propriétaire unique; c'est un événement de changement interopérable.

Un identifiant d'événement de migration peut lier les avis et les reçus entre les registres sans exiger qu'ils abandonnent leur autorité de décision. L'enregistrement comprend les ressources exactes, les anciennes origines et celles prévues, la méthode d'authentification du détenteur, l'état RPKI à l'appui, le type d'événement, l'intervalle effectif et les contacts. Chaque registre ajoute sa propre décision, son motif, son heure et sa voie de recours. Les miroirs transportent les données sources comme avant. Les opérateurs peuvent consommer les décisions selon la préférence déclarée.

Cet arrangement expose le désaccord au lieu de le cacher. Un IRR intégré au RIR peut accepter la demande du détenteur actuel. RADb peut avoir besoin de vérifier un objet maintenu séparément. Un autre registre peut conserver un objet parce qu'il documente une relation de secours active. Le reçu montre trois résultats et leurs preuves. Un opérateur peut alors distinguer une coexistence justifiée d'une copie abandonnée.

L'action spécifique à la source empêche également la suppression accidentelle par collision de noms. Les objets de route sont identifiés par le préfixe, l'origine et la source, pas seulement par le préfixe. Un objet dans une source peut être un miroir d'une autre ou une assertion indépendante. Un événement commun doit préserver cette provenance. Il ne devrait jamais ordonner à chaque base de données d'effacer tout le texte correspondant sans demander qui l'a accepté à l'origine et quels utilisateurs en dépendent.

La coordination devrait inclure des accusés de réception négatifs. Un registre qui n'a pas d'objet pertinent le dit. Un miroir indique le numéro de série autorisé qu'il a appliqué. Un fournisseur déclare qu'il n'utilise pas la source concernée. Ces déclarations bornées sont plus précieuses que le silence car elles réduisent la surface inconnue. Elles rendent également possible un examen post-incident lorsqu'un filtre diffère ultérieurement de l'état attendu.

Le modèle est une responsabilité fédérée: sémantique commune des preuves et des statuts, autorité locale, reçus portables et exceptions visibles. Il s'aligne sur le caractère distribué de l'IRR tout en corrigeant l'hypothèse selon laquelle les bases de données indépendantes déduiront d'une manière ou d'une autre la même migration à partir du BGP.

L'avis est un contrôle opérationnel, pas une courtoisie administrative

L'avis est parfois traité comme un retard ajouté par les avocats. Dans le nettoyage du registre de routage, il fait partie de la validation technique. Le mainteneur répertorié peut savoir pourquoi un objet apparemment obsolète subsiste. Le détenteur actuel peut découvrir une ROA conflictuelle. L'AS d'origine peut apprendre qu'une relation client n'a jamais été fermée. Un fournisseur peut identifier une dépendance de filtre qui nécessite un remplacement avant la suppression.

Un avis efficace doit atteindre plus que l'adresse intégrée dans un objet vieux de vingt ans. Le registre devrait utiliser les contactsnotifyet mainteneur de l'objet, les canaux de contact RIR actuels, le compte du détenteur enregistré et, le cas échéant, le contact opérationnel de l'AS d'origine. Les résultats de livraison devraient être enregistrés. Exposer publiquement chaque adresse est inutile; la preuve que l'institution a essayé les canaux pertinents suffit pour l'examen.

Le message doit comporter une conséquence et un remède. Il indique si l'action proposée est un avertissement, une réduction de préférence, une suppression ou une suppression; quand elle aura lieu; quelles preuves l'ont déclenchée; comment la contester; et comment obtenir un examen urgent si la joignabilité est affectée. Des demandes vagues de "mettez à jour vos enregistrements" ne créent aucune échéance responsable. La suppression immédiate sans moyen d'arrêter une erreur peut transformer l'hygiène des données en déni de service.

Les délais de réponse devraient être fondés sur le risque plutôt que cérémoniels. Un objet clairement conflictuel et non autorisé pendant un événement d'abus actif peut justifier une suppression temporaire rapide. Un objet de secours dormant mais non contredit peut justifier un examen plus long. L'institution devrait publier les facteurs, et non inventer un délai différent pour chaque demandeur influent. Toute mesure d'urgence fait l'objet d'un examen indépendant rapide.

L'avis atteint également les réseaux consommateurs. Un fournisseur de transit n'a pas besoin de preuves confidentielles, mais il a besoin de savoir qu'une entrée préfixe-origine qu'il utilise va changer et qu'un remplacement a été préparé. Les opérateurs peuvent mettre en scène les deltas de filtre, inspecter les suppressions inattendues et éviter de reconstruire au pire moment. Le coût de quelques avis précis est faible par rapport au débogage d'une route rejetée par plusieurs couches de politiques périmées.

Les droits et les recours déterminent si le nettoyage est légitime

Le détenteur actuel de la ressource a besoin d'un droit de découvrir les objets de route couvrant ses préfixes, y compris la source, le mainteneur, l'état et la voie de contestation. La découverte ne devrait pas dépendre de la connaissance de chaque nom de base de données. Les services de recherche combinés peuvent aider, mais leur couverture doit être indiquée. Un résultat manquant d'un point d'accès n'est pas une preuve qu'aucun objet n'existe ailleurs.

Le détenteur a également besoin d'un intérêt pour demander la correction ou la suppression. Ce droit ne garantit pas la suppression immédiate; il garantit que le registre authentifiera la demande, examinera les preuves, notifiera les parties concernées et rendra une décision motivée. Lorsque le mainteneur de l'objet de route est un ancien fournisseur, il ne faut pas dire au détenteur que seul l'ancien fournisseur peut s'exprimer. Le litige porte précisément sur la question de savoir si cette autorité opérationnelle déléguée a pris fin.

Le mainteneur répertorié a des droits réciproques. Il peut voir la réclamation, présenter des preuves d'une autorisation continue et faire appel d'une décision défavorable. Si les informations d'identification ont été compromises, il peut demander une suspension d'urgence. Si le détenteur actuel se trompe au sujet d'une sauvegarde ou d'un accord client, l'enregistrement peut être conservé ou modifié. Une procédure régulière protège les informations de routage exactes autant qu'elle supprime les résidus.

Les consommateurs ont besoin d'un recours différent: une exception avec une expiration. Si une décision de registre est retardée alors qu'un objet périmé crée un risque démontrable, un opérateur peut exclure l'objet ou la source pour le préfixe affecté en vertu d'une politique documentée. Si la suppression bloque le service de manière inattendue, il peut rétablir temporairement une exception examinée pendant que le détenteur et le registre réparent la déclaration autorisée. Les exceptions doivent être étroites, enregistrées et automatiquement réexaminées.

Un examen indépendant complète la structure. Un réviseur vérifie la chaîne d'autorité, les preuves, l'avis, l'effet technique et la cohérence avec les règles publiées. Il devrait être possible d'annuler une suppression erronée et de créer un nouvel objet actuel sans falsifier l'historique. Les anciennes versions peuvent rester dans l'historique protégé même lorsqu'elles disparaissent des requêtes de politique normales.

La légitimité est visible dans le recours. Une base de données qui peut accepter des objets mais n'offre aucun chemin de correction pratique demande aux opérateurs de faire confiance à la permanence sans responsabilité. Une base de données qui supprime sur demande privée sans avis leur demande de faire confiance à la discrétion. Le juste milieu crédible est la preuve, la légitimité, l'action bornée et l'examen.

Les métriques utiles mesurent la clôture, pas la taille de la base de données

Compter les objets de route est facile et souvent trompeur. Une base de données peut réduire son total en supprimant une politique dormante légitime. Elle peut se vanter d'une grande fraîcheur en touchant les horodatages sans confirmer l'autorité. Elle peut signaler peu de conflits parce que sa règle de sélection de source cache les objets de moindre préférence. Les métriques de gouvernance devraient suivre l'événement de migration et conserver le dénominateur.

Pour chaque migration participante, mesurez l'intervalle entre la demande authentifiée et l'inventaire complet; la part des objets découverts pour lesquels un mainteneur responsable était joignable; l'intervalle jusqu'à l'acceptation du remplacement; le temps jusqu'à chaque décision de source indépendante; le décalage de miroir; le temps jusqu'au rafraîchissement du filtre par l'opérateur désigné; et le nombre d'exceptions non résolues à la clôture.

Séparez les changements de transit de même origine, les changements d'origine, les transferts de ressources, les déplacements inter-régions et les services temporaires car leurs états attendus diffèrent.

Les mesures de qualité devraient également enregistrer les actions erronées. Combien de classifications comme périmées ont-elles été retirées après qu'un mainteneur a démontré une utilisation actuelle? Combien de suppressions ont-elles nécessité une restauration d'urgence? Combien de remplacements ont-ils été acceptés syntaxiquement mais omis des sources sélectionnées d'un fournisseur? Combien d'anciennes autorisations sont-elles restées après la date cible? La publication à la fois de la sur-suppression et de la sous-suppression dissuade un registre d'optimiser un seul côté.

Les statistiques au niveau de la source ont besoin de contexte. Les étiquettes d'objets périmés de RADb sont des signaux d'examen utiles, mais sa documentation indique que l'étiquette ne modifie pas les résultats de requête. Un déploiement IRRd qui supprime les objets invalides selon RPKI ou de moindre préférence mesure la visibilité effective, pas la suppression physique. Un IRR de RIR peut avoir un lien plus fort avec le détenteur de ressource qu'un registre indépendant, mais une couverture régionale plus étroite. Les comparaisons devraient indiquer ces différences de conception.

Aucune preuve sélectionnée ne fournit un dénominateur global complet des migrations d'objets de route, des filtres générés à partir d'entrées périmées, des attaques réussies rendues possibles par une autorisation résiduelle ou des pannes causées par la suppression. Les configurations privées des fournisseurs et les litiges avec les clients ne sont généralement pas observables. Les rapports devraient décrire les registres, les dates, les classes d'objets, les points d'observation BGP et les opérateurs entités effectivement étudiés.

Des bornes honnêtes n'affaiblissent pas les arguments en faveur de l'action. Elles rendent les revendications de performance utiles. Un détenteur se soucie de savoir si son propre mouvement a été clôturé à travers les sources et les fournisseurs désignés. Un opérateur se soucie de savoir si son filtre provient d'entrées actuelles et autorisées. Une communauté de registre se soucie de savoir si ses recours fonctionnent et si les erreurs sont réparées. On peut mesurer ces questions sans prétendre voir chaque routeur.

La Société des ressources numériques peut normaliser le reçu de transfert

La Société des ressources numériques plaide pour un enregistrement précis des numéros, des droits plus clairs pour les opérateurs de réseau et des limites à la discrétion administrative concentrée. Appliqués avec soin, ces principes soutiennent un rôle pratique dans la migration des IRR. La SRN peut réunir les détenteurs, les registres, les réseaux de transit et les opérateurs de logiciels pour définir un reçu portable et un vocabulaire de preuves.

Le reçu ne serait pas un objet de route et n'autoriserait pas BGP. Il enregistrerait l'événement autour des déclarations autorisées: préfixe, anciennes origines et origines prévues, type d'événement, RIR concerné, sources IRR, statut du mainteneur, authentification du détenteur, comparaison RPKI, avis, décisions de source, observations de miroir, tests de filtre, exceptions et réviseur. Des signatures ou des attestations authentifiées identifient qui a fait chaque déclaration sans prétendre qu'une seule institution les a toutes faites.

La SRN peut également publier des tests de conformité. Un registre démontre la découverte, la contestation du détenteur actuel, l'avis à l'ancien mainteneur, la suspension réversible, la journalisation des suppressions et l'état du miroir. Un fournisseur démontre la sélection explicite des sources, l'expansion reproductible des AS-SET, la mise à jour échelonnée des filtres et l'expiration des exceptions. Un fournisseur de transfert ou de réseau géré démontre que la résiliation comprend un inventaire IRR. Les résultats des tests expirent et identifient la version examinée.

Cela favoriserait la décentralisation en rendant la qualité de service portable. Les détenteurs pourraient comparer si un IRR offre une récupération crédible. Les opérateurs pourraient préférer les sources dont les contrôles d'autorité et de fraîcheur sont mesurés. Les registres pourraient se coordonner sans créer un nouveau signataire central. Les chercheurs pourraient analyser les événements terminés avec consentement et des bornes appropriées.

La SRN devrait rester consciente des preuves. Ses documents publics énoncent des positions de plaidoyer; ils ne prouvent pas le déploiement d'un service de migration IRR ou un consensus universel des membres sur les détails techniques. L'accréditation ne peut pas contraindre un RIR à supprimer un objet, garantir qu'un fournisseur actualise les filtres ou établir un titre légal sur l'espace d'adressage. La valeur de la Société résiderait dans les normes, la transparence et le soutien aux membres, et non dans la revendication d'une autorité racine qu'elle ne possède pas.

Le rôle positif le plus fort est de rendre les droits exécutoires. Un détenteur qui a déménagé devrait savoir où les anciennes déclarations subsistent, comment les contester, quelles preuves sont requises et quand chaque consommateur a changé. C'est plus concret qu'un slogan sur le contrôle et plus compatible avec un Internet distribué que de remplacer un gardien irresponsable par un autre.

La migration se termine lorsque l'ancienne permission n'atteint plus la politique

Un résultat de recherche IRR propre n'est pas l'objectif final. Le réseau prévu doit rester joignable via les origines autorisées, et l'ancienne permission doit cesser d'influencer les filtres qui importent. Cet état peut être décrit sans prétendre à une connaissance universelle.

Le détenteur actuel est authentifié. Les déclarations préfixe-origine prévues existent dans les sources appropriées et, lorsqu'elles sont utilisées, s'alignent sur les ROA valides. Les sauvegardes planifiées et les origines temporaires ont une portée explicite. Les objets remplacés ont été supprimés ou supprimés en vertu de règles publiées après avis et examen. Les copies indépendantes sont résolues ou nommées comme exceptions. Les miroirs ont appliqué les changements autorisés pertinents. Les réseaux de transit et de peering désignés ont reconstruit et déployé des filtres.

Les observations BGP aux points d'observation déclarés correspondent à l'état prévu.

Chaque clause importe. Sans authentification du détenteur, le nettoyage peut devenir un détournement par l'administration. Sans remplacement, la suppression peut bloquer le service. Sans avis, une route dormante légitime peut être effacée. Sans action source par source, les copies survivent. Sans preuve de miroir et de filtre, un changement de registre peut ne jamais atteindre les routeurs. Sans observations bornées, une revendication d'achèvement dépasse ce que quiconque a mesuré.

L'ancien objet de route n'est pas dangereux simplement parce qu'il est vieux. Il devient dangereux lorsqu'une affirmation obsolète conserve une force opérationnelle sans un responsable actuel. La suppression n'est pas non plus intrinsèquement vertueuse. Elle n'est sûre que lorsque l'institution peut expliquer pourquoi l'autorité a pris fin, comment la continuité a été protégée et quel recours existe si le jugement était erroné.

Les fondateurs de l'IRR ont conçu un moyen distribué de transformer la politique de routage déclarée en coordination. Trois décennies plus tard, cette même force rend la succession lourde de conséquences. Un texte écrit pour un arrangement commercial et technique peut être copié, mis en miroir et compilé longtemps après que l'arrangement a changé. Les réseaux évoluent plus vite que la mémoire institutionnelle à moins que la migration ne devienne un événement à part entière.

La règle de gouvernance est donc simple mais exigeante: prouver la source actuelle d'autorité, rendre la politique prévue utilisable, notifier ceux qui peuvent contredire les preuves, retirer les anciennes affirmations dans chaque source indépendante, vérifier la distribution et ne clôturer qu'après que les consommateurs désignés ont changé. Un réseau n'a pas entièrement déménagé tant que son ancienne permission vit encore dans les filtres des réseaux dont il dépend.

Sources