Résumé

  • Le RFC 3091 demandait à un émetteur multicast d’envoyer des décimales de PI au groupe 314.159.265.359, qui n’est pas une adresse multicast IPv4 valide.
  • Ses ports TCP et UDP emblématiques, 314159 et 220007, dépassaient eux aussi la taille de 16 bits des champs de transport : ces constantes ne pouvaient pas être utilisées telles quelles.

À première lecture, le protocole semble d’une simplicité désarmante. Un client qui ne sait pas calculer PI localement se connecte à un serveur et reçoit les décimales ; il peut aussi demander celle qui occupe un rang donné. Une troisième option diffuse des chiffres choisis aléatoirement sur un groupe multicast afin que les auditeurs recomposent progressivement une valeur cohérente. Mais ces trois formes de service ne commencent qu’une fois franchie une condition plus élémentaire : les constantes doivent pouvoir être inscrites dans les champs d’adressage du réseau.

La voie multicast rend le décalage visible. Le RFC désigne 314.159.265.359 comme groupe. En IPv4 décimal pointé, une adresse comporte quatre octets dont chacun va de 0 à 255 ; le RFC 1112 situe les groupes IPv4 entre 224.0.0.0 et 239.255.255.255. Ici, il y a cinq composantes et la première dépasse déjà 255. Ce n’est pas un groupe multicast simplement non attribué, qu’un administrateur pourrait encore enregistrer : cette chaîne ne désigne pas une adresse IPv4. Un hôte ne peut donc pas rejoindre le groupe littéralement indiqué.

Le même défaut apparaît dans les ports. Le RFC 793 réserve 16 bits aux ports source et destination TCP ; le RFC 768 fait de même pour UDP. Une valeur non signée sur 16 bits ne dépasse pas 65 535. Or le service TCP obligatoire du RFC 3091 demande le port 314159 ; son service UDP facultatif reprend cette valeur. Les services approximatifs pour 22/7 demandent le port 220007. Aucun de ces nombres ne peut être encodé dans un port TCP ou UDP. Les plages d’allocation décrites plus tard par le RFC 6335 organisent les numéros à l’intérieur de l’espace représentable ; une inscription auprès de l’IANA n’agrandit pas le champ.

Cette impossibilité est plus instructive qu’une collection de nombres évoquant PI. En TCP, le serveur devait envoyer un flux sans limite jusqu’à ce que le client ferme la connexion. En UDP, le client demandait plutôt le chiffre de rang n et recevait une réponse indexée. Le multicast supprimait la requête : un fournisseur attendait trente secondes de ne pas détecter d’autre émetteur, puis diffusait une distribution aléatoire de décimales que les clients devaient assembler avec le temps.

Le comportement décrit est différencié à chaque niveau, mais le premier geste reste impossible : atteindre une destination que le protocole de transport ou d’adressage ne sait pas représenter.

Le texte est daté du 1er avril 2001 et porte la catégorie Informational. Le Datatracker de l’IETF le classe dans le flux Independent Submission et précise qu’il n’est ni endossé par l’IETF ni doté d’un statut formel dans son processus de normalisation. Cette date, les valeurs inencodables et l’avertissement selon lequel Internet s’effondrerait bientôt sans serveur PI digne de confiance font fortement penser à une plaisanterie. Il s’agit d’une interprétation contextuelle, pas d’une preuve de l’intention privée de l’auteur.

Le fait d’archive est plus circonscrit : le RFC présente une conception sous forme de protocole, mais les destinations qu’il nomme ne tiennent pas dans les protocoles invoqués.

Un numéro RFC ne constitue pas à lui seul la preuve d’une implémentation. La notice de publication établit ce qui a été écrit et la filière par laquelle le document a paru. Elle ne montre pas qu’un hôte s’est lié au port demandé, qu’un groupe multicast existait, qu’un déploiement a réparé les constantes ou que des clients ont effectivement reconstitué PI sur un réseau. Les méthodes de calcul citées et le recours prévu aux enregistrements DNS SRV enrichissent le projet, mais ne corrigent pas les tailles de champs. Un SRV peut annoncer un port ; le transport doit encore pouvoir le porter.

Le RFC 3091 laisse ainsi une leçon modeste d’histoire de l’ingénierie Internet : un texte peut être cohérent à la lecture et échouer au passage entre un nom et sa représentation sur le fil. Un numéro peut faire écho à PI et une chaîne d’adresse lui ressembler ; cette ressemblance ne crée pas un identifiant réseau valide. Avant d’évaluer la découverte de services, l’équilibrage de charge ou la convergence des récepteurs, il faut vérifier que les bits transmis peuvent encoder la destination.

Sources