Résumé
- La RFC 6860 permet de garder dans OSPF la relation topologique nécessaire au calcul des chemins tout en empêchant le préfixe numérotant un réseau de transit d’être installé comme destination dans la RIB et la FIB.
- La portée de « caché » est stricte : OSPFv2 peut encore montrer des adresses dans ses LSA, un routeur ancien peut installer une route
/32, et la gestion, les Forwarding Addresses ou les liens virtuels peuvent perdre une dépendance utile.
Une absence qui ne coupe rien
Imaginons un contrôle après changement. Les voisins OSPF sont toujours en état Full. Le graphe conserve l’arête entre les deux routeurs. Le trafic de bout en bout passe par cette arête. Pourtant, le préfixe de l’interface n’est plus présent dans la RIB d’un autre routeur de la zone.
Ce n’est pas un état intermédiaire incohérent. OSPF doit connaître la connexion entre routeurs pour calculer un chemin. Il n’a pas toujours besoin de rendre le sous-réseau numérotant cette connexion joignable comme destination. La RFC 6860 donne une forme interopérable à cette différence pour les réseaux qui ne relient que des routeurs.
Dans le cas point à point d’OSPFv2, une Router-LSA contient normalement deux informations de nature différente. Le lien de type 1 décrit le voisin et sert à SPF. Le lien de type 3 décrit le sous-réseau comme réseau stub et provoque l’installation d’une route. Pour masquer le préfixe, on omet le type 3 sans supprimer le type 1. La topologie reste ; la destination disparaît.
Cette précision évite de confondre la fonction avec une mise hors service. Aucune interface n’est retirée, aucune adjacence n’est fermée, aucun coût n’est artificiellement porté au maximum. Seule l’autorité donnée au préfixe de devenir une destination routée est retirée.
Le DR doit conserver la topologie
Sur un réseau de diffusion, le Designated Router produit une Network-LSA qui énumère les routeurs attachés. Supprimer cette LSA ferait perdre au calcul topologique une information indispensable. La RFC 6860 conserve donc la LSA et emploie un masque spécial, 255.255.255.255.
Un récepteur compatible calcule la topologie normalement, puis n’installe pas la route correspondant au réseau. Le même procédé s’applique à un réseau NBMA exploité selon le modèle de diffusion. Le lien collectif demeure visible à SPF tandis que son préfixe cesse d’être une destination de la zone.
La transition n’est pas parfaitement symétrique. Un routeur plus ancien peut lire ce masque comme un /32 ordinaire et installer une route hôte vers l’adresse d’interface du DR. Un routeur mis à jour n’installe rien. La RFC considère cette exposition limitée préférable à celle de tout le sous-réseau, mais elle ne prétend pas que les RIB soient identiques.
Une preuve de déploiement doit ainsi nommer les récepteurs et leurs versions. Dire que « la LSDB contient la bonne LSA » ne suffit pas : la même LSA peut produire deux tables de routage différentes.
OSPFv3 sépare mieux adresse et graphe
OSPFv3 retire les adresses des Router-LSA et Network-LSA principales. Ces objets portent la topologie. Les Link-LSA associent des adresses à un lien dans une portée locale, et les Intra-Area-Prefix-LSA associent des préfixes à un routeur ou à un réseau.
La suppression peut dès lors laisser les objets topologiques intacts et omettre les préfixes de transit lors de la construction des Intra-Area-Prefix-LSA. Les familles d’adresses de la RFC 5838 réutilisent cette architecture dans des instances distinctes ; elles n’ont pas besoin d’un message spécial supplémentaire.
Cette séparation est plus nette, pas magique. Les Link-LSA, Router IDs, configurations et observations locales continuent d’exister. Une adresse peut rester assignée à l’interface tout en n’étant plus joignable depuis la zone. Le bon énoncé est donc localisé : tel récepteur n’a pas installé tel préfixe issu de telle instance OSPF.
Un résultat de forwarding, pas une promesse de secret
La motivation de sécurité de la RFC 6860 est de réduire le nombre de réseaux du cœur auxquels un paquet distant peut être acheminé. Même si l’adresse est connue, l’absence d’information de forwarding empêche un routeur de la zone de la traiter comme une destination ordinaire.
Ce résultat n’est ni un chiffrement ni une authentification. En OSPFv2, l’adresse d’interface peut rester dans le champ Link Data d’une Router-LSA ; l’adresse du DR peut rester Link State ID de la Network-LSA. Un routeur directement connecté dispose encore de sa route locale. Une route statique, un autre protocole ou un réseau de gestion peut rétablir une joignabilité.
Le mot « caché » doit donc toujours répondre à quatre questions : caché de quelle table, sur quel routeur, à quelle heure et pour quelle source de trafic ? Si une route alternative existe, l’absence de la route OSPF ne prouve même pas l’absence finale dans la FIB.
Le bénéfice de sécurité est crédible comme mécanisme. Son ampleur dans un réseau précis exige des mesures avant et après, des tests depuis les points d’attaque pertinents et une vérification des routes concurrentes.
L’adresse avait peut-être une seconde fonction
Une adresse dite de transit sert souvent au diagnostic, à la gestion directe ou à l’identification d’une interface. La retirer des RIB distantes peut modifier les retours de ping et de traceroute, l’accès aux équipements ou le sens d’une alarme. Le trafic de service peut continuer pendant que l’observabilité se dégrade.
La RFC nomme deux incompatibilités critiques. Une Forwarding Address non nulle dans une LSA externe ou NSSA exige une route correspondante. Une adresse située sur une interface masquée ne doit donc pas être annoncée comme Forwarding Address ; le chemin vers la destination externe peut devenir moins direct.
De même, les extrémités d’un lien virtuel OSPF doivent être joignables par un chemin intra-zone. Une adresse supprimée ne peut pas servir d’extrémité. Conserver l’arête topologique ne répare pas une fonction qui dépend expressément de la joignabilité de l’adresse.
Le contrôle préalable doit aussi rechercher les sessions interdomaines, règles de filtrage, cibles d’automatisation, collecteurs et procédures de secours. « Transit-only » est une conclusion d’inventaire, pas une propriété déduite du masque.
Le reçu qui donne un sens à la commande
Les documentations actuelles de FRRouting et de Cisco montrent des commandes de prefix suppression. Elles établissent une capacité documentée, pas son activation ni son résultat dans un réseau réel.
Un reçu exploitable joint deux séries de preuves. La première démontre la continuité : adjacence, arête topologique, calcul SPF et trafic attendu. La seconde démontre la suppression : LSA modifiée ou association de préfixe omise, absence de la route dans la RIB/FIB de chaque récepteur compatible, résultat /32 explicitement accepté sur les anciens récepteurs.
Il faut y ajouter la voie de gestion de remplacement, l’absence d’usage interdit comme Forwarding Address ou extrémité virtuelle, les tests de paquets, le propriétaire du changement et la condition de retour. Une simple baisse du nombre de routes ne distingue pas une suppression réussie d’une perte de données de contrôle.
La place exacte d’Álvaro Retana
La RFC 6860, publiée en 2013, porte les noms de Yi Yang, Álvaro Retana et Abhay Roy. Elle met à jour les spécifications de base d’OSPFv2 et OSPFv3 et remercie un groupe plus large d’inventeurs et de relecteurs. Le profil IETF de Retana décrit une carrière bien plus vaste, mais il ne lui confère pas la propriété d’OSPF, d’un code fournisseur ou d’une exploitation privée.
La co-signature documentée suffit à relier Retana à une idée opératoire forte : la topologie, l’adressage, la joignabilité et l’utilité ne sont pas un seul état. Une spécification minimale peut définir comment les séparer ; chaque opérateur garde la décision d’activer, d’exclure, de mesurer et de revenir en arrière.
Le dernier contrôle tient dans cinq lignes distinctes : le lien existe ; OSPF l’utilise ; l’interface possède une adresse ; le préfixe n’est pas installé à distance ; les fonctions nécessaires continuent. La RFC 6860 autorise des réponses différentes. La discipline consiste à ne jamais les compresser en un seul voyant vert.
Sources
- https://www.rfc-editor.org/rfc/rfc6860.html
- https://www.rfc-editor.org/rfc/rfc2328.html
- https://www.rfc-editor.org/rfc/rfc5340.html
- https://www.rfc-editor.org/rfc/rfc5838.html
- https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_ospf/configuration/15-e/iro-15-e-book/iro-ex-lsa.html
- https://www.cisco.com/c/en/us/td/docs/routers/ios-xe/ip-routing/b-ip-routing/m_iro-pref-supp-v3.html
- https://docs.frrouting.org/en/latest/ospfd.html
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance
