Résumé

  • Le sujet exact est AL ROOYA Co. For Communication and Internet Services LTD, représenté par l’objet répertoire BTW actuel et la chaîne titulaire RIPE pour AS211732. L’enregistrement de registre donne à l’analyse une frontière précise de l’entité et des ressources numériques. Il ne renseigne ni les produits commerciaux de la société, ni ses clients, ses systèmes privés ni ses contrats [S01][S02][S08][S13].
  • Au moment de la requête RIPEstat retenue, AS211732 annonçait et annonçait depuis lui un seul préfixe IPv4, 185.243.128.0/24. RIPEstat comptabilisait 256 adresses IPv4 annoncées, aucun préfixe IPv6 annoncé et une visibilité IPv4 large sur ses pairs collecteurs [S03][S04][S11][S12]. Ces observations établissent une empreinte de routage public, pas une disponibilité applicative, une bande passante, une latence ou une portée client.
  • La réponse RIPEstat state l’existence d’un voisin observé unique, AS42705, alors que l’objet du registre contient une politique d’import et d’export déclarée pour plus d’un ASN [S05][S08]. La politique déclarée et le routage observé relèvent de classes de preuve différentes. Cette divergence est une raison de surveiller les évolutions et de recaler les enregistrements, pas une preuve d’erreur d’un ou l’autre jeu de données.
  • La réponse BGP-state contient de nombreux chemins collecteurs vers la même origine et le même préfixe [S06]. De multiples chemins collecteurs ne signifient pas que AL ROOYA ait plusieurs fournisseurs directs. Ils indiquent la manière dont la route s’est propagée via l’internet depuis les points de vue des collecteurs qui l’ont rapportée.
  • L’historique RPKI de RIPEstat enregistrait un objet d’autorisation d’origine couvrant 256 adresses IPv4 jusqu’à la dernière date conservée, alors que la vue BGP indépendante a qualifié le préfixe visible comme RPKI valide [S09][S14]. La validation de l’origine est un contrôle utile. Elle ne prouve pas la correction de la politique de routes, ne protège pas chaque décision de chemin ni ne garantit une sécurité de bout en bout.
  • L’enregistrement public soutient une analyse opérations-technologie, car une petite empreinte de routage requiert néanmoins une supervision, une intégration, une maintenance et une gestion d’exceptions. Filtres, contacts, objets de route, autorisations, supervision, revue de changement, coordination montante et récupération ont tous un coût continu [S16][S17][S18][S19][S20].
  • Capacité, fiabilité de production et résultat client restent distincts. La capacité signifie que l’ASN et le préfixe peuvent être enregistrés et propagés. La fiabilité de production concerne une opération stable et correcte face aux changements et aux pannes. Le résultat client exige des preuves sur un service réel et une conséquence métier définie. Les sources conservées établissent la première catégorie et certains signaux de contrôle, mais pas les deux dernières.

Le terme « réseau à préfixe unique » paraît simple. Il existe une seule route visible, une seule origine et une plage d’adresses compacte. Les données publiques d’AS211732 rendent cette description particulièrement concrète. RIPEstat a signalé un seul préfixe IPv4 /24 au moment de la requête, aucun espace IPv6 annoncé, un voisin observé et une visibilité depuis presque tous les peers IPv4 rapportants dans sa réponse de statut de routage [S03][S04][S05]. La vue de préfixe a associé 185.243.128.0/24 à AS211732 et à la chaîne titulaire AL ROOYA [S11][S12].

Cette empreinte compacte n’est pas l’équivalent d’un modèle opérationnel simple. Une route peut être brève à décrire tout en dépendant d’un registre exact, d’une politique explicite, de filtres corrects, d’une autorisation d’origine maintenue, de routeurs fonctionnels, d’une coordination montante, d’une couverture de supervision et d’une reprise testée. Un nombre réduit d’objets publics peut rendre chaque objet plus critique car les alternatives sont moindres lorsqu’un élément devient obsolète, retiré ou rejeté.

La preuve publique impose aussi une limite importante. Elle ne montre ni quel service AL ROOYA vend, ni quelles applications utilisent le préfixe, ni le volume de trafic qui le traverse, ni si des clients en dépendent, ni quelle capacité est disponible, ni comment les incidents sont traités. L’annuaire BTW et les enregistrements RIPE identifient la société et la ressource numérique [S01][S02][S08][S13]. Les collecteurs de routes montrent ce qu’ils observent. Ils ne fournissent pas de schéma d’architecture privée ni de rapport de niveau de service.

Cet article traite donc AS211732 comme une surface opérationnelle visible plutôt que comme un proxy de l’entreprise entière. La question n’est pas qu’un /24 soit bon ou mauvais. La question est ce qui doit rester aligné pour qu’un petit réseau public soit fiable, quels modes de panne méritent attention, quelles preuves un opérateur ou un acheteur doit demander et jusqu’où les données de routage public soutiennent une conclusion.

Le BGP lui-même est un protocole de politique. RFC 4271 définit comment les systèmes autonomes échangent l’accessibilité et sélectionnent les routes selon des politiques locales [S16]. RFC 7454 ajoute des recommandations opérationnelles et de sécurité autour du filtrage, des sessions, des préfixes, des AS path et de la supervision [S17]. Ces standards rendent clair que la route visible sur l’internet est le résultat de décisions de contrôle répétées, pas un fait auto-entretenu.

Le modèle de coût a quatre volets récurrents. La supervision signifie qu’une personne possède la route, surveille les changements et a l’autorité pour réagir. L’intégration signifie que registre, RPKI, politique de routeurs, acceptation en amont, supervision et dépendances de service restent cohérents. La maintenance signifie que contacts, objets, logiciels, filtres et runbooks restent à jour. La gestion des exceptions signifie que l’opérateur sait identifier et résoudre un retrait, un rejet, une fuite, une autorisation périmée ou un désaccord avec un upstream.

La conclusion publique la plus solide est volontairement étroite. AL ROOYA dispose d’une empreinte IPv4 active et visible associée à AS211732. Les preuves retenues soutiennent une analyse des contrôles de routage et de la concentration opérationnelle. Elles n’établissent ni une capacité produit au-delà de cette empreinte, ni une fiabilité de production pour un service nommé, ni un résultat client.

1. Entité exacte, autorité du registre et limites de preuve

L’analyse commence par la résolution d’entité. L’objet annuaire BTW nomme AL ROOYA Co. For Communication and Internet Services LTD et l’associe à AS211732 [S01]. L’aperçu RIPEstat retourne une chaîne titulaire correspondante et signale que l’ASN était annoncé au moment de la requête [S02]. La recherche dans la base RIPE expose l’objet aut-num, la référence d’organisation, le statut, les mainteneurs, les contacts administratifs et techniques ainsi que les champs de création et de modification datés [S13].

Ces enregistrements résolvent un problème: ils identifient le titulaire du numéro-public avec assez de précision pour éviter d’écrire sur une entreprise homonyme. Ils ne résolvent pas toutes les questions d’identité légale ou commerciale. Un objet de registre internet est conçu pour soutenir l’administration et la coordination des ressources numériques. Il ne remplace ni un registre d’entreprise à jour, ni un contrat client, ni un registre fiscal, ni une description de service.

L’enregistrement aut-num porte une signification opérationnelle. Il enregistre AS211732 comme attribué, indique l’objet d’organisation AL ROOYA et publie une politique d’import et d’export déclarée pour plusieurs AS voisins [S08]. Il identifie aussi les mainteneurs et contacts responsables de l’entrée. Ces champs créent des chaînes de responsabilité pour la coordination registre et routage.

L’autorité du registre ne se confond pas avec la topologie en temps réel. Une déclaration d’import décrit une politique prévue. Un collecteur de route rapporte ce qu’il observe depuis un ensemble de pairs à un moment donné. L’un peut changer avant l’autre. Une relation peut être configurée mais inactive, conservée pour contingence, visible en dehors de l’ensemble de vues choisi ou simplement périmée. Un opérateur rigoureux recadre ces classes plutôt que de forcer une seule interprétation.

L’enregistrement public a aussi des limites temporelles. Les réponses RIPEstat incluent des instants de requête ou des intervalles d’observation. Les compteurs actuels de préfixe et de voisin sont donc des faits datés, non des propriétés intemporelles. Une route peut changer après la collecte. Une revue complète enregistre le temps d’observation, répète la requête quand la décision dépend de la fraîcheur et conserve le résultat antérieur pour rendre le changement visible.

Il n’existe aucune page commerciale de première partie dans l’ensemble conservé. Cette absence est importante car elle retire une source potentielle de revendications sur produits, support et clients. Elle ne prouve pas que la société n’a pas de site ou de service; elle signifie que cet article n’a pas de page publique conservée appuyant de telles affirmations. L’analyse ne doit pas combler ce vide par des hypothèses liées au nom de la société.

La même limite s’applique à la géographie. Le contexte organisationnel et annuaire place l’entité en Iraq, tandis que les services de trajectoire et de géolocalisation peuvent attacher des lieux aux adresses observées ou aux enregistrements réseau [S01][S15]. Ces métadonnées donnent un contexte, pas une inventaire complet des sites, des points radio, des emplacements clients ou des extrémités de route. La géolocalisation d’adresses n’est pas un inventaire d’actifs physiques.

La photographie mise en avant suit cette règle. Elle montre une vraie tour de communications mobiles photographiée à Bagdad en 2017. Elle apporte un contexte éditorial utile pour l’infrastructure des communications irakiennes. Elle ne représente pas AL ROOYA, AS211732, le préfixe visible, un upstream, un client, une installation, une zone de couverture ni un résultat de fiabilité.

Cette limite de preuve n’est pas une faiblesse de l’analyse. Elle permet de la garder techniquement utile. Les preuves de routage public peuvent répondre aux ressources visibles, aux origines, chemins, voisins, historique et contrôles choisis. Elles ne peuvent pas répondre aux applications, contrats, effectifs, trafic, niveaux de service ou résultats métier. Conserver ces couches séparées évite qu’un ASN devienne un profil entreprise inventé.

Pour un acheteur ou un partenaire, l’étape identitaire suivante serait explicite: confirmer l’entité contractante, le nom du service, l’usage prévu d’AS211732 et de 185.243.128.0/24, la partie contrôlant la politique de route, les relations montantes et les personnes autorisées à changer. L’enregistrement public fournit des identifiants de départ. L’engagement commercial et technique doit fournir l’étendue manquante.

2. Ce qu’un préfixe IPv4 actuel prouve et ne prouve pas

La réponse announced-prefixes de RIPEstat a rapporté 185.243.128.0/24 comme le préfixe visible actuel pour AS211732 durant l’intervalle conservé [S03]. La réponse routing-status a comptabilisé un préfixe IPv4 contenant 256 adresses et aucun préfixe IPv6 [S04]. Le point d’information réseau a associé le /24 à AS211732, tandis que le panorama de préfixe a rapporté la même origine et la même association de titulaire [S11][S12].

Ce sont des observations solides sur le routage public. Elles montrent que le préfixe était annoncé et vu par le système de mesure. Elles ne montrent pas que les 256 adresses soient toutes allouées à des services, accessibles depuis chaque réseau, acceptant des connexions ou portant du trafic client. La taille de l’espace d’adresses n’est pas une capacité de service.

En IPv4, un /24 a une signification opérationnelle car c’est communément la longueur la plus longue propagée dans la zone libre de défaut globale. Cette norme pratique peut rendre un /24 portable comme unité de routage, mais les sources conservées ne précisent pas comment AL ROOYA utilise les adresses ni si des routes plus spécifiques existent dans des contextes limités. Le résultat public doit être présenté comme la route globale observée, non comme l’ensemble de la planification d’adressage interne.

La visibilité large de collecteurs est aussi bornée. RIPEstat a signalé 328 pairs IPv4 RIS sur 329 observant la route à son instant de requête [S04]. C’est une preuve de visibilité étendue parmi ces peers. Ce n’est pas une preuve que chaque réseau d’accès, résolveur, chemin applicatif ou utilisateur peut rejoindre un service. Une route peut être visible quand des paquets échouent ensuite à cause de filtrage, de forwarding, de congestion, d’une configuration hôte ou d’un problème applicatif.

La distinction entre présence de route et disponibilité de service est l’un des contrôles opérationnels les plus importants. Un superviseur BGP peut signaler qu’un préfixe existe alors qu’une application est indisponible. Un superviseur applicatif peut signaler un endpoint local sain alors qu’une route externe est absente dans certaines zones. Les deux couches doivent être observées si le service métier dépend des deux.

Une seule préfixe concentre aussi le risque de changement. Un retrait accidentel peut retirer toute l’empreinte IPv4 visible. Une origine incorrecte peut créer des problèmes de validation ou de filtrage pour le /24 entier. Une erreur de route-map peut affecter toutes les adresses derrière elle. Avec de nombreux préfixes, les erreurs peuvent rester graves, mais un périmètre réduit laisse moins d’espace pour isoler un changement par unité de routage.

Cette concentration peut être un avantage. L’opérateur dispose d’un petit ensemble public à inventorier. La supervision peut valider qu’existe exactement un préfixe attendu, annoncé par exactement un ASN attendu et couvert par une autorisation attendue. Les ajouts inattendus, retraits ou changements d’origine peuvent être plus faciles à détecter que dans une table volumineuse et changeante.

Le bénéfice existe seulement si l’état attendu est explicite. Une règle de supervision qui vérifie seulement « une route existe » peut manquer une mauvaise origine ou un préfixe plus spécifique inattendu. Une règle qui vérifie le préfixe exact, l’origine, l’état de validation et le chemin est plus utile. Elle doit aussi distinguer un changement planifié d’une déviation non autorisée.

Le préfixe public est une dépendance partagée entre couches. Les reverse DNS, allowlists, géolocalisations, systèmes de réputation, contacts d’abus et configurations client peuvent référencer des adresses à l’intérieur. Un changement de propriété, de routage ou d’usage peut avoir des effets de second ordre même si le BGP reste sain. La maintenance inclut donc un inventaire des systèmes qui encodent le préfixe hors du routeur.

Aucune source conservée ne rapporte volume de trafic, utilisation maximale, perte de paquets, délai, temps de convergence de route ou marge de capacité. Il serait incorrect d’estimer ces métriques à partir de la taille du /24 ou du nombre de chemins visibles. Un acheteur doit demander des mesures propres au service et à leur méthode de collecte, plutôt que de traiter la visibilité de routage comme une référence de performance.

L’énoncé de capacité public approprié est modeste: AL ROOYA contrôle ou est associée à un ASN public qui a été observé comme origine d’un seul IPv4 /24. La question de fiabilité de production est de savoir si la route et les services associés restent corrects en fonctionnement normal, maintenance et panne. La question de résultat client dépend d’un service réel et d’un objectif défini.

3. L’économie opérationnelle d’une empreinte à préfixe unique

Un réseau public compact peut réduire certaines formes de complexité. Il existe un préfixe courant à documenter, une origine à autoriser et un petit ensemble d’assertions de routage externe à superviser. L’opérateur peut construire un modèle d’état attendu concis et détecter vite les écarts. C’est la capacité au niveau du plan de contrôle.

Ce modèle compact peut aussi rendre certains coûts fixes plus visibles. La maintenance de registre, les opérations RPKI, le logiciel de routeur, la supervision, la coordination montante, la revue sécurité et la couverture on-call ne disparaissent pas parce que le nombre de préfixes est un. Certains coûts sont presque indépendants de la taille de l’espace d’adresses. Un petit réseau peut les concentrer sur moins de services ou de clients.

La supervision est le premier coût fixe. Quelqu’un doit connaître l’état de route attendu, valider les changements, surveiller les alertes et coordonner avec des parties externes. Le rôle doit avoir assez d’autorité pour retirer une modification risquée, contacter un upstream, corriger un objet de registre et préserver les preuves. Si une seule personne détient ce savoir, le réseau a une dépendance clé-personne même si la route semble saine.

L’intégration est le deuxième coût fixe. L’objet registre, l’autorisation RPKI, la configuration du routeur, les filtres montants, les attentes de supervision, les enregistrements de gestion d’adresses et tout inventaire de service doivent décrire une réalité compatible. Un écart peut entraîner un rejet ou des alertes trompeuses. Le coût n’est pas seulement la configuration initiale; il faut maintenir chaque contrôle synchronisé après chaque changement.

La maintenance est le troisième coût fixe. Les coordonnées changent. Les rôles changent. Les clés et identifiants tournent. Les logiciels de routeurs arrivent en fin de support. Les politiques montantes évoluent. Les collecteurs de supervision évoluent. Une autorisation d’origine peut devoir être ajustée quand la politique de préfixe ou d’origine change. Un petit tableau de routage ne supprime pas ce cycle de vie.

La gestion des exceptions est le quatrième coût fixe. L’opérateur a besoin de procédures pour retrait, mauvaise origine, échec de validation, fuite de route, rejet par un upstream, instabilité de session, panne matérielle et gestion inaccessible. Chaque événement croise les limites techniques et organisationnelles. Un diagnostic correct peut exiger la comparaison entre état local, données de registre et observation collecteur + upstream.

Le modèle de coût doit intégrer ces coûts avant d’affirmer qu’une empreinte compacte est efficace. L’efficacité n’est pas l’absence de complexité sur un tableau public. Elle est la capacité à maintenir les contrôles requis avec un effort proportionné et à récupérer dans la conséquence tolérée par le service.

Un arbitrage rationnel existe. Un petit opérateur peut préférer un préfixe public unique parce qu’il correspond à sa taille réelle et réduit les ressources inutilisées. Le choix devient risqué si l’empreinte est traitée comme autosuffisante ou si les services en dépendance exigent une résilience que le modèle de routage et d’exploitation ne fournit pas.

Le coût dépend aussi de la fréquence de changement. Une route stable avec peu de changements bien revus peut être moins coûteuse à maintenir qu’un environnement dynamique. Pourtant une faible fréquence crée son propre risque: les procédures et chemins d’accès peuvent ne plus être testés. Un exercice annuel validant contacts, identifiants, filtres et reprise peut valoir plus qu’un document jamais exécuté.

L’historique public montre qu’AS211732 a originé plus d’un préfixe dans le temps, alors que la vue actuelle en contient un seul [S07]. Cela n’identifie pas la cause des changements historiques. Cela montre pourquoi l’enregistrement de l’état attendu doit être daté. Une règle basée sur un ancien préfixe peut générer du bruit, alors qu’une règle qui apprend silencieusement chaque variation peut normaliser une erreur.

Un réseau compact bien conduit doit pouvoir expliquer les coûts récurrents en termes clairs: qui possède le routage, quelles ressources sont attendues, quels upstreams sont actifs, comment l’autorisation d’origine est maintenue, que contrôle-t-on en externe et quels modes d’échec déclenchent l’escalade. Les données publiques ne répondent pas à ces questions, mais elles permettent de les rendre précises.

4. Concentration des voisins observés et supervision des chemins

La réponse neighbours de RIPEstat a signalé un seul voisin observé unique pour AS211732, AS42705, à l’instant de requête conservé [S05]. La réponse routing-status a aussi compté un voisin observé unique [S04]. C’est un signal de concentration pertinent, mais qui exige une terminologie prudente.

Un voisin observé est dérivé des routes visibles par les collecteurs. Cela ne signifie pas automatiquement une connexion physique directe, un contrat de transit commercial ou la topologie configurée complète. L’objet registre déclare des relations de politique avec plusieurs ASNs [S08]. Un enregistrement peut refléter des relations prévues ou disponibles, tandis que l’observation reflète la propagation active pendant la fenêtre choisie.

La réponse BGP-state aide à clarifier la distinction. Elle contient de nombreux chemins depuis les sources collectrices vers 185.243.128.0/24, mais les chemins convergent vers AS42705 avant d’atteindre AS211732 [S06]. Les AS antérieurs dans ces chemins font partie de la chaîne de propagation plus large. Ils ne sont pas une preuve qu’AL ROOYA a un contrat direct avec chaque ASN listé.

Du point de vue fiabilité de production, un voisin observé unique pose une question de dépendance. Si la route publique dépend réellement d’un seul chemin externe, une panne de session, de politique ou d’infrastructure à cette frontière peut affecter l’ensemble du préfixe visible. Les données conservées ne rapportent pas s’il existe une sauvegarde cachée, une alternative configurée mais inactive ou un basculement rapide. Ce sont précisément les faits qu’une revue de diligence doit demander.

La concentration n’est pas automatiquement un mauvais design. Un fournisseur unique peut réduire la charge de coordination, simplifier la politique et correspondre à des conséquences de service limitées. La décision dépend des objectifs de récupération, des performances fournisseur, de l’accès alternatif et du coût d’un second chemin. Une redondance non testée, co-localisée ou dépendante de la même chaîne amont peut ajouter du coût sans retirer le mode de panne réel.

La supervision doit donc modéliser la dépendance plutôt que de compter les liens. Des contrôles utiles incluent l’état des sessions BGP, les préfixes attendus, l’origine attendue, le next hop, les comptes de routes acceptées et annoncées, les changements de politique et l’historique de flap externe. Un contrôle séparé doit établir si le service reste joignable, car la santé du plan de contrôle seule est incomplète.

L’intégration avec l’upstream compte dans les deux sens. L’opérateur doit disposer d’une politique d’importation pour les routes reçues et d’une politique d’exportation pour les routes annoncées. RFC 7454 recommande des pratiques de filtrage explicites et une attention portée aux préfixes, AS path et communities [S17]. Un petit origine doit connaître les attentes de l’upstream, la mise à jour des filtres et la personne qui résout une route rejetée.

Le mode de panne ne se limite pas à la coupure totale. Une route peut devenir visible via un chemin non prévu, être acceptée dans certains réseaux et rejetée dans d’autres, ou porter des attributs inattendus. Une visibilité partielle peut être plus difficile à diagnostiquer qu’un retrait propre.

La gestion de changement doit inclure la coordination amont. Si l’origine, le préfixe, la longueur maximale, la politique changent, l’upstream peut exiger des mises à jour correspondantes. Une configuration locale correcte peut coexister avec un filtre externe obsolète. Le plan de maintenance doit suivre les deux côtés et vérifier la route résultante depuis l’extérieur du réseau.

Les vues indépendantes Hurricane Electric et IPinfo apportent des vérifications croisées utiles [S14][S15]. Elles peuvent révéler si un autre système public voit l’ASN et le préfixe attendus. L’accord entre sources augmente la confiance de l’observation, sans transformer les vues en garantie de disponibilité. Elles partagent des portions du même écosystème de routage public et ont leurs limites de collecte.

Un acheteur doit traduire cette concentration de voisin en question service. Quelle conséquence visible pour l’utilisateur si le chemin observé disparaît? En combien de temps un autre chemin peut-il être utilisé? Existe-t-il un autre chemin techniquement et commercialement actif? Partage-t-il les mêmes installations physiques, énergie, équipement ou dépendances amont? Quelle preuve récente d’exercice de basculement soutient la réponse? Sans ces faits, le signal de concentration demeure une question, pas un verdict.

5. RPKI, politique registre et validation d’origine

L’historique RPKI de RIPEstat pour AS211732 pour 256 adresses IPv4 jusqu’à la dernière date conservée [S09]. La vue BGP indépendante a qualifié 185.243.128.0/24 de valide RPKI [S14]. Ces observations indiquent que l’origine visible et une autorisation publique alignée au moment de la collecte.

RFC 6811 décrit la validation d’origine de préfixe BGP à partir de données de route-origin authorisation validées [S18]. Le contrôle répond à une question bornée: l’origine observée est-elle autorisée pour le préfixe et la longueur de préfixe autorisée? Il ne valide pas l’ensemble du chemin AS, de la configuration routeur, du comportement de forwarding ni de l’identité de service.

Cette frontière est opérationnellement importante. Une route valide peut quand même fuir via un chemin non prévu, être envoyée avec un attribut indésirable, être retirée par erreur ou pointer vers un service indisponible. Un statut valide doit être traité comme un contrôle requis, pas comme un feu vert global.

La RPKI induit aussi un travail de cycle de vie. L’autorisation doit être créée par le titulaire de ressource approprié, rester disponible via le dépôt de clés et être mise à jour quand l’origine ou la politique de préfixe envisagée évolue. Une autorisation périmée peut entrer en conflit avec une migration légitime. Une longueur maximale trop large peut autoriser des annonces plus spécifiques que celles que l’opérateur souhaite.

L’opérateur doit inventorier l’autorisation aux côtés de la route. L’état attendu inclut préfixe, ASN d’origine, longueur maximale, contexte émetteur et période de validité. La supervision doit détecter absence, invalidité et changements non attendus. Une migration d’origine prévue doit préparer l’autorisation avant le changement de route et retirer l’état obsolète après validation.

La politique de registre ajoute une couche distincte [S08][S13]. Elle déclare des relations d’import et d’export et identifie des mainteneurs. Ces déclarations peuvent soutenir la coordination et le filtrage, mais n’ont pas la même sémantique qu’une autorisation d’origine de route. Un modèle de contrôle complet ne traite pas la politique IRR et la RPKI comme interchangeables.

RFC 7454 recommande le filtrage de préfixe et d’AS-path comme partie des opérations BGP [S17]. La validation d’origine peut renforcer ce modèle, en particulier quand les upstream rejettent des routes invalides. La question d’intégration pratique est de savoir si chaque réseau pertinent applique une politique compatible et si l’opérateur sait comment un changement d’état de validation affectera la propagation.

La gestion d’exceptions doit intégrer les échecs de validation. La réponse n’est pas simplement de désactiver le contrôle. L’opérateur doit comparer route, autorisation, propriété du registre, changement planifié et observation amont. Il faut identifier si la route est non autorisée, l’autorisation périmée, l’origine changée légitimement ou un problème de dépôt affecte la validation.

La communication fait partie de la reprise. Les contacts techniques et administratifs actuels rendent possible le contact du titulaire de ressources pour un upstream ou un autre opérateur [S08]. La maintenance des contacts est donc un contrôle de sécurité et de fiabilité. Une autorisation correcte sur le plan technique est moins utile si personne n’est joignable pendant un incident.

Les preuves publiques ne révèlent pas le workflow interne de RPKI d’AL ROOYA, l’accès au signataire, la revue des changements, la supervision ni la politique de validation amont. Elles ne montrent que l’état externe visible enregistré par les systèmes conservés. Toute conclusion sur la maturité du processus nécessiterait une preuve directe.

La conclusion de capacité équitable est que le préfixe visible dispose d’un signal d’autorisation d’origine correspondant. La question de fiabilité de production est de savoir si ce contrôle reste correct lors des changements et si l’opérateur peut se remettre d’un état invalide. La question de résultat client dépend de savoir si ce contrôle réduit effectivement la perturbation ou le risque d’un service défini.

6. Contrôle des changements, fuites de routes et réglages plus sûrs

Les incidents de routage commencent souvent par des changements qui semblaient raisonnables localement. Une nouvelle politique est appliquée dans la mauvaise direction. Une liste de préfixes est incomplète. Une session monte avant le chargement des filtres. Un chemin de secours annonce plus qu’annoncé. Une mise à jour de registre ou d’autorisation se fait dans le mauvais ordre. Le réseau peut continuer à transférer tandis que le plan de contrôle a déjà divergé de l’état attendu.

RFC 7908 définit les fuites de route comme une propagation au-delà du périmètre prévu et classe plusieurs formes courantes [S19]. Le document est utile car il distingue une fuite d’un simple détournement d’origine. Une route peut avoir une origine correcte et voyager quand même via une relation non prévue ou en violation de politique.

Pour AS211732, l’empreinte publique compacte rend une liste de contrôle de changement précise. L’opérateur peut vérifier le préfixe exact, l’origine exacte, l’autorisation, la politique d’import et d’export déclarée, les attentes de voisins et la visibilité externe avant et après un changement. La liste doit aussi confirmer qu’aucun préfixe ou chemin inattendu n’est introduit.

RFC 8212 recommande un comportement externe BGP par défaut plus sûr: aucune route ne doit être importée ni exportée sans politique explicite [S20]. Le principe est particulièrement utile lors d’un remplacement, d’une récupération ou d’un travail d’urgence, quand les opérateurs subissent une pression de temps.

La politique explicite n’est pas suffisante si la politique est périmée. Les listes de préfixes, les filtres AS-path et les limites de maximum prefix doivent correspondre à la relation prévue. Un contrôle qui empêchait autrefois une erreur peut bloquer plus tard une migration légitime ou autoriser une nouvelle ressource jamais ajoutée au périmètre attendu.

La revue doit inclure le mode de panne créé par le changement lui-même. Si un nouveau filtre rejette l’unique préfixe actuel, toute l’empreinte visible peut disparaître. Si un changement annonce accidentellement des routes d’une autre partie, le petit origine peut devenir un vecteur de fuite. La conséquence dépend de l’acceptation en amont et du filtrage global, mais l’opérateur local reste responsable de prévenir et détecter l’erreur.

Le déploiement progressif réduit le risque. L’opérateur peut valider la syntaxe de configuration, comparer la politique générée à une source d’autorité approuvée, appliquer le changement sur une seule session quand l’architecture le permet, et observer les collecteurs externes avant de finaliser le déploiement. Un retour arrière doit rétablir l’état connu précédent au lieu d’inventer un nouvel état.

Le changement d’urgence mérite le même niveau de preuve avec un cycle plus court. Le propriétaire doit enregistrer ce qui a échoué, quels contrôles sont temporairement contournés, qui a autorisé l’exception et quand l’exception expire. Une politique large temporaire qui reste après la reprise peut devenir l’incident suivant.

Les données historiques de route fournissent un contexte de revue [S07]. Elles peuvent montrer quand les préfixes apparaissent ou disparaissent et comment la visibilité évolue. Elles ne peuvent pas identifier la cause. Une visibilité réduite peut refléter une migration planifiée, des changements de collecteurs, un comportement d’upstream ou un incident. Les records internes de changement et d’incident sont nécessaires pour interpréter.

La maintenance doit aussi couvrir logiciel et cycle de plateforme. Les implémentations BGP, systèmes d’exploitation et interfaces de gestion évoluent. Une politique peut rester logiquement correcte quand l’équipement qui l’applique arrive en fin de support ou se comporte différemment après une mise à niveau. Une validation en laboratoire ou par étape est proportionnée quand le préfixe public est une dépendance concentrée.

Le contrôle central attendu est la réconciliation de l’état attendu. Registre, autorisation, configuration routeur, acceptation amont, supervision et inventaire de service doivent converger sur la route voulue. Chaque changement met ce modèle à jour délibérément. Toute différence inexpliquée devient une exception avec un propriétaire, pas une « nouvelle normale » apprise silencieusement.

7. Supervision, gestion d’incidents et limites de mesure

RIPEstat a signalé une visibilité IPv4 large pour AS211732 et aucune visibilité IPv6 dans le résultat de routing-status conservé [S04]. Ses points de visibilité et d’état BGP exposent des observations depuis plusieurs collecteurs [S06][S10]. Ce sont des vues externes utiles, car elles peuvent révéler une propagation qu’un compteur local ne peut pas voir.

La visibilité externe n’est pas une supervision complète. Les collecteurs échantillonnent l’internet à travers des pairs et positions spécifiques. Une route peut être visible depuis eux tandis qu’un réseau utilisateur la filtre, ou être invisible à un collecteur donné alors que le service reste joignable ailleurs. L’opérateur doit combiner routes externes, test actif de route et vérifications de service.

La supervision doit séparer les couches. La première couche vérifie le routeur et l’état BGP. La deuxième vérifie le préfixe attendu, l’origine, le chemin et l’état de validation depuis l’extérieur. La troisième vérifie la portée de transport depuis les régions ou réseaux pertinents. La quatrième vérifie le service réel, s’il est défini. Les alertes doivent identifier la couche ayant échoué.

Cette séparation améliore le diagnostic. Si la route disparaît en externe mais que la session locale est active, le problème peut venir de la politique d’export, du filtrage amont ou de la propagation. Si la route est visible mais que le service est indisponible, le problème est plus loin dans la chaîne de forwarding ou applicatif. Si une seule région échoue, la cause peut être une propagation partielle ou une dépendance spécifique à un chemin.

La qualité des alertes est un coût opérationnel. Une petite empreinte peut supporter des règles précises, mais les collecteurs et les chemins évoluent. Une supervision qui alerte à chaque petite variation de chemin crée de la fatigue. Une supervision qui accepte toute origine ou tout préfixe peut manquer l’événement critique. Les seuils et la suppression de bruit doivent être revus selon les besoins de décision.

La réponse aux incidents commence par l’autorité. Quelqu’un doit pouvoir inspecter le routeur, comparer les données externes, contacter l’upstream, mettre à jour une autorisation ou un enregistrement registre et communiquer l’impact. L’accès ne doit pas dépendre d’une seule personne indisponible. Les identifiants, l’accès hors bande et les méthodes de contact doivent être vérifiés périodiquement.

Le plan de réponse devrait couvrir au moins six modes de panne. Premièrement, retrait complet de route. Deuxièmement, observation de mauvaise origine ou origine invalide. Troisièmement, visibilité partielle. Quatrièmement, voisin ou chemin inattendu. Cinquièmement, fuite de route ou export inattendu. Sixièmement, route présente mais service non joignable. Chacun exige des preuves et une escalade différentes.

La reprise doit être vérifiée de l’extérieur. Une commande locale montrant la session restaurée ne suffit pas. L’opérateur doit confirmer que le préfixe et l’origine exacts réapparaissent, que l’état de validation est attendu, que la propagation couvre suffisamment pour le service et que le service lui-même est rétabli. Le temps de chaque étape aide à distinguer la convergence routière de la reprise applicative.

La revue post-incident ne doit pas supposer que les données publiques expliquent la cause. L’historique collecteur peut montrer ce qui a changé et quand [S07][S10]. Il ne peut pas montrer pourquoi une configuration a changé, si du matériel a échoué ou quelle décision a retardé la reprise. La revue exige des logs locaux, des enregistrements de changement, la communication avec les upstreams et des preuves de service.

La communication de statut doit préserver l’incertitude. « La route est de nouveau visible » est une déclaration de plan de contrôle. Elle ne doit pas être étendue à « tous les clients sont rétablis » sans preuve de service. Une mise à jour précise peut indiquer quelle couche est rétablie, ce qui reste en validation et quand l’observation suivante est prévue.

Aucune source conservée ne rapporte un incident AL ROOYA, un temps de réponse ou une architecture de supervision. Les modes de panne ci-dessus forment un cadre de diligence dérivé des preuves de routage public et des normes opérationnelles primaires [S17][S19][S20]. Ils ne sont pas des allégations qu’un incident ait eu lieu.

8. Absence d’IPv6 et choix de cycle de vie des adresses

La réponse routing-status conservée indiquait zéro préfixe IPv6 annoncé pour AS211732 tout en signalant un seul préfixe IPv4 /24 [S04]. La réponse announced-prefixes conservait également le préfixe IPv4 comme ressource visible actuelle [S03]. C’est une observation publique datée, pas une preuve qu’AL ROOYA n’ait aucune capacité IPv6 ailleurs.

Une organisation peut utiliser un IPv6 attribué par un fournisseur, une connectivité privée ou un autre ASN sans que cet état n’apparaisse comme origine annoncée d’AS211732. À l’inverse, une allocation IPv6 peut exister sans être annoncée. La formule correcte se limite à l’origine publique observée au point de requête.

L’absence de routage public IPv4 crée des questions de cycle de vie. Un /24 contient un ensemble d’adresses fini. L’opérateur peut user de translation d’adresse, allouer de manière sélective, acquérir de l’espace additionnel ou planifier un déploiement IPv6. Les sources conservées ne montrent pas quel choix AL ROOYA a retenu.

La rareté d’adresses entraîne un coût opérationnel. L’allocation, la réclamation, la réputation, le reverse DNS, les allowlists et la gestion des abus exigent des enregistrements. Réutiliser une adresse expose un nouveau service aux hypothèses construites sur son usage précédent. Un petit stock rend l’inventaire discipliné et le nettoyage encore plus importants.

L’adoption d’IPv6 n’est pas seulement un champ d’adresses plus large. Elle ajoute une politique de routage, des règles de firewall, de supervision, des enregistrements DNS, le support applicatif, la journalisation et les procédures de support. Le dual stack peut améliorer les options de portée et réduire des tensions IPv4, mais il crée aussi deux plans qui doivent être sécurisés et observés.

Le choix doit suivre une exigence de service plutôt qu’une mesure de mode. Si des clients, des upstreams ou des plateformes requièrent IPv6, l’opérateur doit disposer d’un plan d’implémentation et de maintenance. Si le service actuel n’en a pas besoin, l’opérateur doit comprendre quand cette décision sera revue et quelles dépendances rendent une adoption ultérieure coûteuse.

Le cycle de vie logiciel et le verrouillage apparaissent à ce niveau. Les systèmes supposant des littéraux IPv4, stockant des adresses dans des champs étroits, encodant manuellement des allowlists ou sans supervision IPv6 deviennent coûteux à modifier. Plus ces hypothèses s’étendent, plus une transition réseau ultérieure atteint les applications et l’exploitation.

Les tests doivent inclure l’asymétrie de panne. Un service peut fonctionner en IPv4 et échouer en IPv6, ou inversement. Les clients peuvent privilégier une famille d’adresses et retarder un basculement. La fiabilité de production exige des preuves par famille.

L’historique d’autorisation d’origine des routes conservé pour AS211732 concerne l’espace IPv4 [S09]. Si l’IPv6 est ensuite annoncé, son enregistrement registre et son autorisation doivent être ajoutés de manière explicite. Un plan de changement doit définir préfixe, origine, filtres, acceptation amont, supervision et rollback avant annonce publique.

Le résultat client reste non défini. Une capacité IPv6 peut améliorer la compatibilité ou réduire les contraintes de gestion d’adresses, mais n’améliore pas automatiquement le résultat client. Le résultat dépend de la qualité des chemins, du support applicatif, des réseaux utilisateurs et de la maturité opérationnelle. Un cas métier doit mesurer l’effet visé et le coût de maintenance additionnel.

Pour la diligence, les questions restent bornées. L’absence d’IPv6 est-elle intentionnelle pour AS211732? Un service pertinent dépend-il d’un IPv6 fourni par un autre emplacement? Quels déclencheurs lancent le déploiement? Quels systèmes nécessiteraient une modification? Comment surveille-t-on les deux familles d’adresses? Les données publiques posent ces questions; seul l’opérateur peut y répondre.

9. Capacité, fiabilité de production et résultat client

Les données publiques soutiennent un énoncé de capacité clair. AS211732 est enregistrée au titulaire AL ROOYA et a été observée comme origine de 185.243.128.0/24 [S02][S03][S08][S12]. La route avait une visibilité large dans le résultat RIS conservé et un signal d’autorisation de route-origin correspondant [S04][S09][S14].

Cette capacité a plusieurs composants: administration des ressources numériques, origine de route, propagation en amont et enregistrement d’autorisation public. Chaque composant est observable à certains degrés. Aucun n’établit un portefeuille commercial.

La fiabilité de production pose un autre ensemble de questions. La route reste-t-elle correcte lors des changements? Les contacts sont-ils à jour? Les filtres d’import et d’export sont-ils explicites? L’autorisation est-elle maintenue? L’opérateur peut-il détecter une visibilité partielle? La reprise est-elle exercée? Le service derrière le préfixe continue-t-il de fonctionner quand le plan de contrôle change?

Les sources conservées ne peuvent répondre à ces questions pour AL ROOYA. Une observation saine à un instant donné est utile, mais la fiabilité est une distribution sur le temps et les conditions. Elle couvre maintenance, états dégradés, exceptions et reprise, pas seulement le moment échantillonné par un point de terminaison public.

Le résultat client est encore plus éloigné. Un client peut valoriser la connectivité, une route prévisible, un coût de support plus bas ou l’accès à un service particulier. Mesurer le résultat demande un service nommé, un référentiel, une période d’observation et une répartition de responsabilité. Aucune source conservée ne fournit cette preuve.

Confondre ces catégories produit des erreurs prévisibles. La visibilité de route devient « uptime ». Un voisin unique devient « faible redondance ». La validité RPKI devient « réseau sécurisé ». Un préfixe IPv4 /24 devient « petite capacité ». Aucune de ces conclusions ne découle sans preuve additionnelle.

Les catégories aident aussi un opérateur à communiquer avec rigueur. La capacité peut être documentée via registres et routes publiques. La fiabilité peut être soutenue par l’historique de surveillance, revue de changement, exercices de reprise et indicateurs de service. Le résultat client peut être soutenu par des mesures propres au déploiement. Chaque affirmation a alors une preuve adaptée à son niveau.

Le coût de supervision appartient principalement à la fiabilité. Quelqu’un surveille l’état et les exceptions. L’intégration relie les contrôles et le service. La maintenance garde le système à jour. La gestion des exceptions apparaît quand le chemin attendu échoue. Un résultat client doit être évalué après ces coûts, pas avant.

Les catégories d’analyse des pannes relient les niveaux sans les confondre. Une mauvaise origine est un mode de panne du plan de contrôle. Savoir si elle affecte un service dépend du filtrage et des chemins alternatifs. Savoir si elle impacte un client dépend du service concerné, du timing et de la reprise. La chaîne doit être observée, pas supposée.

Le modèle de preuve doit préserver l’espace négatif. Aucune page produit publique signifie pas de réclamation produit. Aucune mesure de service signifie pas de réclamation fiabilité. Aucun dossier client signifie pas de réclamation résultat. L’absence de preuve ne prouve pas une panne; elle limite ce que l’on peut énoncer de manière responsable.

Cette distinction rend l’article plus utile aux acheteurs et aux opérateurs. Elle remplace une évaluation globale par une demande de preuves concrètes. Elle offre aussi à AL ROOYA une base claire: la société est évaluée sur les faits de routage public disponibles, tandis que la performance privée reste une question de diligence ouverte plutôt qu’une conclusion inventée.

10. Plan de preuves pour l’acheteur et l’opérateur

Un acheteur envisagent un service associé à AL ROOYA doit d’abord confirmer le périmètre. Quelles entités juridiques contractent? Quel service est fourni? Le service dépend-il réellement d’AS211732 ou de 185.243.128.0/24? Quelle partie contrôle le routage, les relations montantes et la réponse aux incidents? Les identifiants d’annuaire et de registre publics offrent un point de départ [S01][S08][S13].

La deuxième étape concerne l’architecture à la frontière, pas une demande de tous les détails privés. L’acheteur a besoin de savoir quel composant dépend du préfixe public, quels chemins montants sont actifs, quelles alternatives existent, où les changements de contrôle sont effectués et comment la santé service est distinguée de la santé route.

La troisième étape est la preuve d’état attendu. L’opérateur doit documenter les préfixes exacts, les origines, l’état de validation, les voisins, les filtres et les contacts. Les observations publiques fournissent des valeurs de contrôle croisé [S03][S04][S05][S09]. L’enregistrement de l’opérateur doit expliquer toute différence.

La quatrième étape est la preuve de supervision. Un échantillon utile inclut contrôles de session BGP, préfixe et origine externes, état RPKI, supervision de portée régionale et tests spécifiques au service. Il doit aussi montrer propriétaire des alertes, seuils, suppression, escalade et preuve d’un événement récent ou d’un exercice.

La cinquième étape est le contrôle de changement. L’acheteur doit comprendre qui peut modifier la politique de route, comment la configuration est revue, comment les filtres montants sont coordonnés, comment les changements d’autorisation sont séquencés et comment la restauration est vérifiée de l’extérieur. RFC 7454 et RFC 8212 fournissent des principes opérationnels pertinents [S17][S20].

La sixième étape est la couverture de modes de panne. Retrait de route, origine invalide, propagation partielle, fuite, voisin inattendu et route présente/service indisponible doivent chacun avoir un diagnostic et un plan de reprise. RFC 7908 apporte une taxonomie de fuites qui rend la discussion plus précise [S19].

La septième étape est l’acceptation de la concentration. Si un voisin est la conception active prévue, l’acheteur doit connaître la conséquence et le chemin de reprise disponible. Si plusieurs relations sont prévues, l’opérateur doit expliquer pourquoi la vue collecteur en montre une, et fournir la preuve actuelle pour les autres. La réponse peut être bénigne, mais elle doit rester explicite.

La huitième étape concerne la maintenance. Contacts, objets de registre, autorisation d’origine, support logiciel, identifiants, accès hors bande et dépendances de supervision ont besoin de propriétaires et de dates de revue. Une route inchangée ne signifie pas que les contrôles de support restent à jour.

La neuvième étape est le cycle de vie des adresses. L’acheteur doit connaître si la contrainte IPv4, la réputation, le reverse DNS ou les allowlists impactent le service et si l’IPv6 est requis. Si l’absence d’IPv6 est volontaire, la décision doit disposer d’un déclencheur de révision au lieu de devenir une hypothèse permanente invisible.

La dixième étape est la preuve de service. Demander des indicateurs adaptés au service réel: disponibilité méthodologique, portée régionale, réponse support, temps de reprise, taux de réussite de changement et exceptions non résolues. Les vues de route [S06][S10][S14][S15] peuvent compléter ces indicateurs sans les remplacer.

La onzième étape est le résultat client. Définir la mesure métier avant déploiement. Elle peut être la portée, la réduction de coût de coordination, la vitesse de reprise ou une autre valeur service. Enregistrer la base, la période d’observation et le travail interne nécessaire pour l’atteindre. Une route techniquement correcte est une entrée, pas le résultat en soi.

La douzième étape est la sortie et la portabilité. Déterminer comment adresses, DNS, configurations, journaux, documentation et arrangements amont changent si le service cesse. Certaines ressources numériques peuvent ne pas être portables selon l’arrangement prévu. Une migration doit découvrir ces dépendances avant qu’une date de préavis ne soit donnée.

Les preuves doivent être datées et ciblées. Une observation collecteur reflète un moment et un ensemble de points de vue. Un exercice de reprise reflète une configuration. Une autorisation reflète un préfixe, une origine et un contexte de validité. Un résultat client reflète un déploiement. Utiliser un de ces éléments hors de son périmètre peut créer une certitude supérieure aux preuves.

La décision peut alors être proportionnée. Un service à faible conséquence peut accepter un chemin unique avec une supervision claire. Un service critique peut exiger une meilleure diversité de chemins, des preuves de reprise et des contrôles contractuels plus robustes. Les données publiques ne dictent pas la réponse. Elles identifient les questions techniques exactes à traiter.

Verdict

AL ROOYA dispose d’une identité entreprise actuelle avec une frontière observable et délimitée en routage internet. Les données d’annuaire, les enregistrements RIPE et les vues de routage indépendantes convergent sur AS211732 et 185.243.128.0/24 [S01][S02][S03][S12][S14]. Au point de requête conservé, l’ASN annonçait un seul préfixe IPv4 /24, n’avait pas de préfixe IPv6 visible, était largement visible par les pairs IPv4 rapportants et avait un voisin observé unique [S04][S05].

Les contrôles publics incluent un objet de registre attribué, une politique de routage déclarée et un historique d’autorisation d’origine [S08][S09][S13]. Ce sont des signaux de capacité et de gouvernance significatifs. Ils n’établissent ni le portefeuille produit d’AL ROOYA, ni la capacité, ni l’uptime, ni la convergence de route, ni la qualité du support, ni les déploiements client, ni les résultats métier.

Le risque opérationnel central n’est pas qu’un préfixe unique soit intrinsèquement insuffisant. Il est qu’une empreinte compacte concentre la conséquence tout en conservant des coûts fixes. Registre, politique, autorisation, filtres, supervision, coordination montante, logiciel, contacts et reprise doivent rester alignés. Un petit tableau public peut simplifier la supervision de l’état attendu, mais ne supprime pas la supervision, l’intégration, la maintenance ou la gestion des exceptions.

Le voisin observé unique doit être traité comme une question de diligence. Il peut refléter le chemin courant, une limite de mesure ou un design avec des alternatives inactives. Les données publiques ne justifient pas un verdict sur la résilience. Un acheteur doit demander des preuves actuelles de topologie et de reprise proportionnées à la conséquence du service.

La même discipline s’applique à la RPKI. Le signal visible d’origine valide est un contrôle utile. Il ne valide pas le chemin complet ni le service derrière. L’opérateur doit encore disposer d’une politique explicite, de prévention des fuites, d’une revue de changement, d’une observation externe et d’une réponse incident [S17][S18][S19][S20].

AL ROOYA doit donc être compris comme une entité entreprise actuelle avec une frontière observable et délimitée en routage internet. Les preuves publiques soutiennent la capacité d’annoncer et de maintenir un préfixe visible à l’instant échantillonné. La fiabilité de production et le résultat client restent des questions ouvertes, demandant des preuves directes, datées et spécifiques au service.

Sources

  1. Répertoire BTW: AL ROOYA Co. For Communication and Internet Services LTD
  2. RIPEstat: aperçu AS211732
  3. RIPEstat: préfixes annoncés AS211732
  4. RIPEstat: statut de routage AS211732
  5. RIPEstat: voisins observés AS211732
  6. RIPEstat: état BGP AS211732
  7. RIPEstat: historique de routage AS211732
  8. RIPEstat: fiche registre AS211732
  9. RIPEstat: historique RPKI AS211732
  10. RIPEstat: visibilité AS211732
  11. RIPEstat: informations réseau pour 185.243.128.0/24
  12. RIPEstat: aperçu de préfixe pour 185.243.128.0/24
  13. RIPE Database: recherche AS211732 aut-num
  14. Hurricane Electric BGP Toolkit: AS211732
  15. IPinfo: AS211732
  16. RFC 4271: A Border Gateway Protocol 4
  17. RFC 7454: BGP Operations and Security
  18. RFC 6811: BGP Prefix Origin Validation
  19. RFC 7908: Problem Definition and Classification of BGP Route Leaks
  20. RFC 8212: Default External BGP Route Propagation Behavior