Résumé

  • RFC 3330 a réuni des blocs IPv4 dispersés et rendu visible le fait que des valeurs numériques voisines pouvaient obéir à des règles différentes pour l’hôte, la source, la destination, le transfert et les fuites.
  • Sa table de 2002 était une photographie, pas un oracle de sécurité permanent. Les RFC ultérieures et le registre IANA actuel ont transformé la classification en un ensemble d’attributs versionnés où les préfixes plus spécifiques comptent.

Une adresse identique ne donne pas les mêmes droits au paquet

Une adresse IPv4 publique peut désigner un hôte acheminé sur Internet. Pourtant, 127/8 doit reboucler dans la machine ; 10/8, 172.16/12 et 192.168/16 sont destinés aux réseaux privés ; 169.254/16 sert à la communication sur un même lien quand la configuration habituelle manque. Les préfixes de documentation servent aux exemples, tandis que 198.18/15 a été prévu pour des essais de performance. Multidiffusion et diffusion limitée obéissent encore à d’autres règles.

Cette différence ne se déduit pas du nombre de bits. Elle vient d’une décision de protocole, d’une affectation ou d’une politique de routage. Un routeur qui traite chaque valeur comme une destination Internet ordinaire peut laisser sortir une adresse de boucle locale. Un filtre qui traite toute adresse « spéciale » comme inutilisable peut bloquer un usage explicitement autorisé. Le nom de la catégorie n’est pas l’action à appliquer.

Avant RFC 3330, les descriptions de ces blocs étaient dispersées dans des RFC et des registres de paramètres. Le document les a rassemblées en un catalogue de l’IANA, tout en précisant qu’il ne décrivait pas l’espace IPv4 alloué aux opérateurs et aux utilisateurs par les RIR. Il ne remplaçait donc pas l’allocation ordinaire ; il rendait plus lisible une petite collection d’exceptions et de désignations spécialisées.

« Spécial » ne constitue pas une propriété unique

Le texte de 2002 expliquait les attentes en prose. L’expérience a ensuite montré qu’un indicateur binaire « spécial » ne suffisait pas à une implémentation ou à une enquête réseau. Une adresse peut être valide comme source mais pas comme destination ; un routeur peut la transférer entre interfaces externes sans qu’elle soit destinée à être globalement joignable ; un protocole peut exiger un traitement particulier même si les autres propriétés sont fausses.

RFC 5735 a remplacé le catalogue historique. RFC 6890 a ensuite défini des registres maintenus pour les adresses à usage spécial IPv4 et IPv6. Les entrées actuelles distinguent notamment la validité en source, la validité en destination, le caractère transférable, la joignabilité globale et la réservation par le protocole. Ces champs répondent à des questions différentes : les fusionner ferait perdre précisément l’information dont dépendent les règles de filtrage.

RFC 8190 a précisé le sens de « globally reachable ». Il s’agit d’une propriété attendue dans un modèle administratif, pas d’une garantie empirique qu’aucune annonce de route ni aucun paquet ne franchira jamais une frontière. Un observateur public qui voit un préfixe déclaré non global peut avoir détecté une fuite, un filtre défaillant, une usurpation ou un artefact de mesure. Cette observation ne modifie pas à elle seule l’entrée du registre.

Le préfixe le plus spécifique est également déterminant. Une entrée large peut contenir une réservation plus précise dont les propriétés diffèrent. Une règle qui s’arrête au premier préfixe englobant peut autoriser une source interdite ou rejeter un trafic prévu. Une décision défendable conserve l’entrée exacte qui a gagné la correspondance, les attributs consultés et la version du registre utilisée.

La table était datée parce que l’espace évoluait

RFC 3330 mentionnait des blocs dont le statut spécial se terminait ou qui redevenaient susceptibles d’une allocation normale. Le document consignait donc un moment du réseau, pas une loi intemporelle. Des préfixes autrefois réservés selon les frontières de classes historiques ont ensuite été rendus à l’espace d’allocation ; certaines affectations ont changé avec les usages et les besoins des protocoles.

Les successeurs ont poursuivi ce travail. RFC 5737 a réservé trois préfixes distincts pour la documentation, au lieu de s’en tenir au seul TEST-NET cité en 2002. RFC 3927 a détaillé le comportement des adresses IPv4 lien-local. RFC 6890 a remplacé les listes statiques par des registres révisables. Aujourd’hui, le registre spécial IPv4 de l’IANA constitue la référence opérationnelle pour ces champs ; RFC 3330 reste une source historique sur la formation du catalogue.

La date fonctionne dans les deux sens. On ne peut pas appliquer rétroactivement un attribut ajouté bien plus tard pour juger un opérateur de 2002. Inversement, une table ancienne ne suffit pas à classifier un paquet observé aujourd’hui. Un rapport d’incident sérieux doit indiquer l’heure de l’observation, la version ou la capture du registre, le préfixe exact, le sens du paquet, l’interface et les attributs qui ont motivé la décision.

Le document séparait aussi les besoins techniques d’une affectation spéciale de la politique générale d’allocation. Quand un RFC avait besoin d’un bloc pour le processus de normalisation, il devait décrire les exigences techniques — par exemple la taille ou la longueur du préfixe. L’IANA devait consulter les RIR et effectuer l’affectation à l’approche de la publication. RFC 3330 décrivait une pratique ; il ne créait ni droit universel à une réservation expérimentale ni nouvelle règle d’allocation.

Une entrée de registre ne filtre aucun paquet

Le registre exprime une intention et fournit des données à des hôtes, des routeurs, des pare-feu, des bibliothèques et des outils d’audit. Il ne met pas à jour automatiquement les équipements et ne fait pas appliquer une politique aux frontières. L’intervalle entre la propriété enregistrée et le comportement observé est un problème opérationnel à part entière.

Un paquet portant une source privée sur une interface externe peut résulter d’une usurpation, d’une mauvaise configuration ou d’un chemin encapsulé. Un logiciel peut employer une adresse de boucle locale comme convention interne. Un exemple copié peut laisser un préfixe de documentation dans la production ; une campagne de benchmark peut contaminer des métriques ordinaires. Dans chaque cas, la valeur seule ne révèle ni l’origine réelle ni l’action prise par les équipements.

Il faut conserver le sens du paquet, les interfaces d’entrée et de sortie, l’encapsulation, l’état de traduction, l’entrée de registre qui correspond au préfixe le plus long et le résultat du filtre. Une capture prouve que certains bits ont été observés à un endroit donné ; elle ne prouve pas à elle seule où le paquet a été créé. De même, « non globalement joignable » ne veut pas dire « jamais visible dans un collecteur public ».

RFC 3330 a marqué une évolution importante : l’espace IPv4 n’était plus seulement une suite d’adresses distribuées, mais un espace commun assorti d’exceptions opérationnelles documentées. Sa leçon la plus utile n’est pas la récitation de quelques préfixes célèbres. C’est la séparation entre valeur numérique, type d’affectation, règle d’exécution et observation. Confondre ces quatre reçus transforme un catalogue pratique en fausse preuve d’origine ou de joignabilité.

Sources