Résumé

  • RFC 3021 ramenait de quatre à deux le nombre d’adresses consommées par une liaison IPv4 point à point numérotée en donnant une fonction d’hôte aux deux valeurs d’un /31.
  • Ce gain reposait sur une propriété du lien et sur l’accord des deux équipements ; le préfixe ne prouvait ni cette topologie, ni la compatibilité, ni la livraison.

À la fin de 2000, la pénurie d’adresses IPv4 avait déjà produit des réponses beaucoup plus vastes : discipline d’allocation, traduction d’adresses et préparation d’IPv6. RFC 3021 choisit un gisement modeste mais répétitif. Une liaison de routeur à routeur configurée en /30 occupait quatre valeurs. Deux servaient aux interfaces. La valeur dont les bits d’hôte étaient tous à zéro désignait le sous-réseau ; celle dont ils étaient tous à un correspondait à la diffusion dirigée.

Or une liaison réellement point à point n’offrait pas quatre rôles. Elle n’avait que deux participants possibles. Tout paquet émis par l’un arrivait à l’autre ; aucune population locale ne devait être sélectionnée par une adresse de diffusion. En passant à un masque de 31 bits, il ne restait qu’un bit d’hôte et donc deux valeurs. RFC 3021 exigea que toutes deux soient interprétées comme des adresses d’hôte.

Le gain était immédiat. Cinq cents liaisons consommaient mille adresses au lieu de deux mille. Le texte traduisait cette différence, dans le vocabulaire de l’époque, par l’équivalent de quatre espaces de classe C. Mais l’opération ne consistait pas à faire disparaître arbitrairement des adresses réservées. Elle modifiait leur sens dans un contexte précisément borné.

Le masque ne certifiait pas la forme du lien

Un administrateur pouvait saisir /31. Cette écriture ne transformait pas pour autant un segment partagé en liaison à deux extrémités. Elle ne garantissait pas non plus que les deux routeurs appliquaient la nouvelle règle.

La valeur haute de la paire illustre le risque. Dans la règle générale, elle ressemblait à une diffusion dirigée. Sur une interface point à point conforme à RFC 3021, elle identifiait le routeur distant. Un équipement compatible devait donc la remettre à l’interface locale lorsqu’elle lui appartenait. Un pair plus ancien pouvait conserver l’ancienne interprétation. Les configurations semblaient symétriques, tandis que les programmes attribuaient deux sens différents au même motif binaire.

RFC 3021 l’énonçait sans détour : si une seule extrémité prenait en charge les préfixes de 31 bits, la liaison pouvait ne pas fonctionner correctement. Le bénéfice comptable n’était donc acquis qu’après une preuve bilatérale.

La diffusion dirigée n’avait plus de case

Avec deux valeurs et deux hôtes, aucune adresse ne restait disponible pour la diffusion dirigée vers le lien. Cette opération devenait impossible sur le /31. La diffusion limitée demeurait la forme à employer lorsqu’un trafic de diffusion était nécessaire.

Cette suppression avait un effet de sécurité circonscrit. Les attaques par amplification de type smurf exploitaient la réplication provoquée par des diffusions dirigées. RFC 2644 avait déjà imposé leur désactivation par défaut sur les routeurs. RFC 3021 retirait ce mécanisme de chaque liaison point à point ainsi numérotée. Il ne fournissait ni authentification du voisin, ni protection du protocole de routage, ni garantie contre les autres dénis de service.

La décision restait locale. Les routeurs éloignés acheminaient le préfixe de façon classless ; le routeur directement connecté décidait que les deux destinations étaient des extrémités et non des diffusions. La syntaxe circulait dans le routage. Sa signification opérationnelle appartenait au bord du lien.

Une exception aux anciennes règles, pas leur abolition

RFC 950 avait déjà envisagé un champ d’hôte d’un seul bit, tout en rappelant que ses deux valeurs portaient traditionnellement des fonctions spéciales. RFC 1122 et RFC 1812 codifiaient les comportements des hôtes et des routeurs face aux formes tout-zéro et tout-un. RFC 3021 modifia ces exigences de manière ciblée : sur une liaison point à point en /31, les valeurs pouvaient être émises, reçues et remises comme adresses d’extrémité. Sur les autres types de liens, les règles de rejet ou de diffusion restaient en place.

Dire que l’opérateur « utilisait l’adresse réseau et l’adresse de broadcast » manque donc le geste normatif. Il ne violait pas simplement une réserve. Le standard redéfinissait les valeurs parce que la topologie supprimait les rôles qui justifiaient cette réserve.

L’expérience publiée restait une preuve bornée

Le RFC rapportait des versions bêta chez plusieurs constructeurs et des essais positifs dans au moins trois fournisseurs d’accès, avec OSPF, IS-IS, BGP et EIGRP. Ce témoignage soutenait la faisabilité en 2000. Il ne mesurait pas une adoption universelle, ne nommait pas toutes les versions et ne prouvait aucun déploiement actuel.

Une adjacence de routage prouve qu’un échange de contrôle a réussi dans un contexte donné. Elle ne suffit pas à démontrer que les outils de gestion acceptent les deux valeurs, que les filtres ne les reclassent pas, que chaque chemin local livre les paquets, ou qu’une application distante a reçu un résultat utile.

Sources

Lu Heng n’a ni rédigé ni approuvé RFC 3021. Ses textes servent ici de grilles d’analyse déclarées.