Résumé

  • RFC 9637 réserve 3fff::/20 à la documentation IPv6 et interdit son emploi pour du trafic réel ou son annonce mondiale.
  • La ligne d’IANA décrit la destination normative du préfixe ; elle ne témoigne pas de l’état de chaque routeur, liste de bogons, tunnel ou filtre de paquets.
  • La preuve d’isolement doit relier registre, origine de l’exemple, environnement, version de politique, points d’application, observations, exceptions et résultat.

La ligne du registre est sans ambiguïté : source, destination, transférable et joignable mondialement sont à faux. Elle est aussi mondiale, visible et stable. C’est précisément pourquoi on peut lui demander plus qu’elle ne sait dire.

Le registre IANA des adresses IPv6 à usage spécial qualifie 3fff::/20 de Documentation. RFC 9637 demande que ce préfixe ne serve pas au trafic réel, ne soit pas annoncé mondialement et ne devienne pas une connectivité de production interne. Mais IANA ne configure aucun voisin BGP et ne charge aucune ACL chez un opérateur.

La vérité du registre et celle du réseau sont donc complémentaires. Confondre les deux reviendrait à prendre une règle publiée pour le journal de son exécution.

Une grande scène pour de grands exemples

RFC 3849 avait réservé 2001:db8::/32. RFC 9637 ajoute un /20 afin que la documentation représente des architectures plus vastes sans emprunter un bloc déjà attribué ni une réserve susceptible de l’être plus tard.

Le RFC cite des statistiques RIR d’août 2023 : une part notable des allocations dépassait /32 et /29 était alors très fréquent. Il s’agit du raisonnement historique ayant dimensionné la réserve, pas d’une photographie permanente du marché.

La taille nouvelle permet des exemples convaincants : régions, agrégats, filiales, clients et politiques distinctes. Cette qualité crée aussi un risque banal. Un fichier d’exemple peut ressembler à un modèle prêt à déployer. Lorsqu’il passe d’une page à un dépôt de configuration, il change de couche d’autorité sans changer d’adresse.

« Non joignable » est une propriété, pas une télémétrie

RFC 6890 organise les propriétés des registres à usage spécial. Elles donnent aux logiciels et aux opérateurs un langage commun. Elles ne prouvent pas que la version chargée est récente, que tous les équipements l’ont reçue ou qu’aucune exception n’a survécu.

Un reçu sérieux doit identifier la version de la liste, son empreinte, les politiques d’import et d’export qui l’utilisent, les filtres source et destination, leurs points d’attache et le résultat de leur installation. Il doit aussi dire où les adresses de documentation restent permises : texte, schémas, tests de parseur, données synthétiques ou simulation sans connectivité.

Le mot « bogon » n’est pas une commande. Le guide de Team Cymru donne un contexte opérationnel, mais chaque réseau garde la responsabilité de ses sources, de ses mises à jour et de ses décisions de filtrage.

Quatre contrôles, quatre questions

Empêcher l’origine d’une route n’est pas rejeter une route reçue. Rejeter une annonce n’est pas abandonner un paquet dont la source appartient au préfixe. Filtrer la source n’est pas filtrer la destination.

Ces quatre contrôles peuvent partager un ensemble de préfixes tout en vivant sur des services et des équipements différents. Un tunnel peut cacher l’adresse interne à un contrôle appliqué seulement à l’enveloppe. Une route statique peut contourner une politique BGP. Une interconnexion privée peut ne pas suivre le même traitement qu’un transit public.

RFC 3704 montre déjà que la validation de source dans un réseau multihomé implique plusieurs compromis. Affirmer « le filtre est actif » sans préciser direction, méthode, interface et exceptions ne permet pas de reproduire le résultat.

L’absence observée reste locale

Une route absente d’un collecteur pendant une fenêtre donnée est une observation utile. Elle ne devient pas pour autant la preuve qu’aucun système autonome ne l’a annoncée, qu’aucun pair privé ne l’a acceptée ou qu’un événement bref n’est pas tombé entre deux échantillons.

Un test de paquet a la même limite. Son résultat appartient à une origine, une destination, un protocole, un instant et un chemin. Plus le rapport nomme ces dimensions, plus son silence est crédible. Plus il les efface, plus il transforme une observation partielle en promesse universelle.

Il faut donc conserver les résultats négatifs sans les gonfler : collecteurs consultés, fréquence d’échantillonnage, familles de chemins, sondes, compteurs, interfaces et angles morts.

Le reçu d’isolement

Le dossier commence par la ligne IANA datée et le RFC qui l’explique. Il rattache ensuite l’adresse au document, au diagramme ou au fichier exact qui l’emploie, puis qualifie l’environnement : lecture, simulation, laboratoire fermé ou système connecté.

Viennent les politiques et leur réalisation : prévention de l’origine, import, export, filtres source et destination, versions, empreintes, points d’application, succès de chargement et dérogations. Les observations de routes et de paquets ajoutent une fenêtre et des limites. Enfin, le résultat précise si l’exemple est resté un exemple.

IANA qualifie ; l’auteur illustre ; l’opérateur configure ; le routeur applique ; l’observateur échantillonne ; l’application subit ou non l’effet. La clarté consiste à relier ces autorités sans prêter à l’une le témoignage de l’autre.

Sources