Résumé

  • RFC 6666 réserve 100::/64 comme bloc IPv6 exclusivement destiné au rejet. Il peut circuler dans un système autonome et se résoudre vers une interface nulle, mais ne devrait ni être annoncé à un AS tiers ni accepté de sa part.
  • Le bloc n’est ni la route victime, ni la communauté BLACKHOLE, ni un reçu de paquet. Il faut relier autorisation, acceptation de route, résolution récursive, FIB, compteurs de rejet, confinement externe et retrait.
  • Nick Hilliard et David Freedman ont cosigné ce RFC informatif. Leur apport collectif est une clarification opérationnelle : un nom mondialement unique pour un acte strictement local, pas un service global ni une obligation de déploiement.

Une route acceptée avant d’être prouvée

Un service IPv6 subit une attaque volumétrique. Un opérateur autorisé injecte dans iBGP un /128 visant l’adresse attaquée, avec un prochain saut appartenant à 100::/64. Les routeurs de bord acceptent l’annonce ; l’automatisation déclare le blackhole actif.

Le verdict arrive trop tôt. Sur trois bords, la récursion atteint une route statique vers l’interface nulle et les paquets s’arrêtent. Sur un quatrième, cette route manque : l’objet BGP existe sans entrée de transfert exploitable. Sur un cinquième, une politique d’export laisse fuir le préfixe de rejet vers un voisin. Le plan de contrôle paraît homogène ; le plan de données produit trois réalités.

Cette scène n’est pas un incident réel. Elle sert à montrer ce que RFC 6666 rend possible et ce qu’il ne démontre jamais à lui seul.

Une adresse mondiale pour un acte local

Le RTBH de destination modifie la route de l’hôte ou du réseau attaqué afin que le trafic soit détruit avant de saturer des liens et des systèmes plus profonds. Des déploiements IPv4 utilisaient une adresse privée comme prochain saut, avec une route vers l’interface nulle sur les bords. Le procédé fonctionnait, mais empruntait un espace conçu pour un autre usage. Utiliser une adresse de documentation était encore moins défendable : une adresse d’exemple ne doit pas devenir une dépendance de production.

RFC 6666 a donc demandé un bloc IPv6 dédié. IANA inscrit 100::/64, forme normalisée de 0100::/64, comme Discard-Only Address Block. Aucune partie finale n’en reçoit d’attribution. Le registre actuel l’indique utilisable comme source et destination, transférable par des routeurs, mais non joignable mondialement.

Les colonnes ne se contredisent pas. « Forwardable » permet au mécanisme ordinaire de routage et de récursion de transporter l’adresse dans un domaine contrôlé. « Globally Reachable: False » fixe la limite extérieure. Le préfixe doit ressembler suffisamment à une adresse unicast pour servir de prochain saut ; il ne doit pas devenir une destination inter-domaines.

Le registre accomplit ici une tâche étroite. IANA coordonne une signification. IANA n’installe pas la route statique, ne choisit pas le bord d’entrée, n’autorise pas la victime, ne détruit pas le paquet et ne porte pas le coût de l’interruption légitime. L’exécution reste sous le contrôle de l’opérateur.

Trois contrôles à ne pas confondre

Le RTBH de destination et celui de source ne fournissent pas la même protection. Le premier sacrifie la joignabilité de la destination afin d’arrêter le flot à l’entrée. Le second associe un état de route à l’uRPF pour rejeter des paquets dont la source déclarée devrait se résoudre par le chemin de rejet. Une preuve du premier ne valide pas le second.

Une interface nulle et un sinkhole diffèrent aussi. L’interface nulle détruit. Le sinkhole détourne vers un système d’analyse et peut, selon l’architecture, réinjecter une partie du trafic. Les appeler indistinctement « blackhole » masque la conservation éventuelle d’éléments probants et le sort du trafic légitime.

Enfin, 100::/64 n’est pas la communauté BLACKHOLE de RFC 7999. Le bloc fournit un prochain saut récursif cohérent à l’intérieur du domaine. La communauté est un avis attaché au préfixe victime. Le voisin ne doit l’honorer que selon un accord et après avoir vérifié que l’annonceur est autorisé à annoncer ce préfixe. Sans configuration explicite, un équipement ne devrait pas détruire le trafic parce qu’il a seulement vu cette valeur.

Le reçu de communauté prouve donc l’arrivée d’un signal, pas l’installation de l’action. Inversement, un AS peut utiliser 100::/64 en interne sans demander à un tiers d’interpréter une communauté. Le premier objet porte une intention entre organisations ; le second stabilise une décision locale de transfert.

Présent dedans, absent dehors

Dans l’AS, tout ou partie de 100::/64 peut être propagé par un protocole dynamique et pointer vers une interface nulle sur certains ou tous les routeurs IPv6. Le mot « certains » est déterminant. Une architecture peut ne jeter qu’aux bords d’entrée ; une autre peut vouloir un filet interne uniforme. L’objectif de l’incident et la topologie doivent trancher.

À la frontière inter-domaines, la règle s’inverse. Le préfixe et ses sous-réseaux ne devraient ni être envoyés à des AS tiers ni être acceptés d’eux. Le trafic qui les vise ne devrait pas franchir ces frontières. Une fuite peut attirer vers le réseau déjà attaqué un volume supplémentaire. L’outil de réduction de charge devient alors un nouvel appel de charge.

L’état sain est asymétrique : résoluble là où la politique interne en a besoin, filtré partout à l’extérieur. Un unique voyant « route présente » est incapable de représenter cette double exigence.

Six reçus pour une action destructrice

Le reçu d’autorité nomme l’approbateur, le préfixe victime exact, le périmètre, le motif, l’heure de début et l’expiration. Un client ne doit pas pouvoir supprimer la route d’un tiers ; une alerte périmée ne doit pas créer un blackhole permanent.

Le reçu du plan de contrôle conserve la route de déclenchement, la communauté, le prochain saut, les routeurs destinataires et le verdict de politique. Les filtres de longueur, l’origine, la RPKI ou un attribut invalide peuvent arrêter l’action. L’acceptation reste toutefois un événement de RIB.

Le reçu de transfert montre, sur chaque entrée prévue, la résolution du préfixe victime via une adresse de 100::/64 puis vers l’interface nulle. Une route visible dans un contrôleur ou un réflecteur peut perdre la sélection, échouer en récursion ou ne jamais atteindre la FIB.

Le reçu de paquet vient des compteurs de transfert ou de rejet et de sondes propres. Il doit préciser le bord et l’instant. Un compteur nul peut signaler l’absence de trafic, le mauvais bord, une télémétrie défaillante ou une action absente ; il ne tranche pas seul.

Le reçu de confinement vérifie Adj-RIB-Out, filtres et politiques de voisins. Le silence d’un collecteur public ne prouve pas une absence universelle. L’opérateur doit conserver ses propres vues d’export.

Le reçu de reprise horodate le retrait du déclencheur, la disparition de la FIB, le retour de la route ordinaire et l’expiration de l’autorisation. Un compteur historique prouve un rejet passé, pas un état actuel.

Le dommage collatéral appartient au mécanisme

Le blackholing de destination protège l’infrastructure élargie en rendant l’adresse attaquée indisponible aux attaquants comme aux utilisateurs légitimes. Ce n’est pas un détail : c’est l’arbitrage. Un préfixe victime aussi étroit que possible réduit la perte, sans la supprimer.

Après activation, l’équipe doit donc demander ce qui a réellement été sauvé. Les liens partagés se sont-ils désengorgés ? Les services voisins du même agrégat restent-ils accessibles ? L’attaque a-t-elle changé d’adresse ? Une règle de source a-t-elle élargi par erreur le périmètre ? Dire seulement que « le trafic a baissé » est insuffisant lorsque l’outil détruit précisément du trafic.

Une contribution de précision, pas de propriété

Le profil IETF de Nick Hilliard associe son nom à six RFC. RFC 6666 a été cosigné avec David Freedman, examiné par l’IETF et publié dans la catégorie Informational. Il n’est ni une norme personnelle ni une commande universelle.

L’idée durable est plus sobre : un contrôle de production mérite son propre espace de noms, au lieu d’emprunter des adresses privées ou documentaires. Cet espace doit révéler la limite de l’action. 100::/64 est utile parce que tous peuvent comprendre son rôle et parce que personne ne devrait le prendre pour un service mondial.

Le registre rend le contrôle lisible. L’autorité explicite, les systèmes en fonctionnement et les paquets établissent le résultat.

Sources