Résumé

  • RFC 917 n’était pas une norme : il rapportait que Stanford exploitait des sous-réseaux IP depuis le début de 1982, avec environ 330 hôtes et 18 sous-réseaux en 1984.
  • Stanford fit correspondre ses sous-réseaux aux numéros de réseau Pup existants ; RFC 917 proposa ensuite un champ de largeur choisie par réseau, avant la procédure hôte de RFC 950 en 1985.

Une norme semble parfois inaugurer la pratique qu’elle décrit. RFC 917 raconte une chronologie moins nette. À Stanford, le sous-réseautage IP fonctionnait déjà avant que Jeffrey Mogul ne publie, en octobre 1984, sa proposition pour une méthode commune. Le document demande des commentaires et des améliorations ; il ne se présente pas comme une norme. Il situe le début de l’usage IP à Stanford au début de 1982.

Ce réseau n’était pas neuf. Depuis 1979, Stanford exploitait Pup sur plusieurs réseaux expérimentaux Ethernet. À l’arrivée d’IP, l’université choisit un numéro de sous-réseau de huit bits. Chaque sous-réseau IP reprenait le numéro Pup de son Ethernet, et le numéro d’hôte Pup, lui aussi codé sur huit bits, occupait le champ hôte IP. Une nouvelle couche d’adressage s’est ainsi raccordée à des repères déjà employés localement.

Les passerelles ont conservé une partie de cette continuité. Celles qui ne comprenaient que Pup acheminaient les datagrammes IP selon les tables Pup, sans modifier le champ Time-to-Live d’IP. Les hôtes multiconnectés jouant le rôle de passerelle, eux, ajustaient ce champ. Mogul indique qu’aucune boucle de transfert due à ce choix n’avait alors été observée à Stanford. Ce constat décrit une installation précise ; il ne justifie pas d’ignorer le TTL dans d’autres réseaux.

Le relevé de 1984 compte environ 330 hôtes, 18 sous-réseaux et un nombre similaire de passerelles. Le même processus maintenait les tables Pup puis les traduisait en numéros de sous-réseau IP. Quand Stanford ajouta des Ethernets à 10 Mbit/s, les passerelles adoptèrent un mécanisme fondé sur ARP qui permit de garder des hôtes non modifiés. Le réseau évoluait sans reconstruire toute sa base installée.

Le cas du MIT répondait à une autre contrainte. À une époque où les numéros de réseau n’étaient pas encore classés, attribuer un numéro IP distinct à chacun de ses liens aurait consommé une grande partie de l’espace disponible. Le MIT conserva un numéro de réseau et divisa les 24 bits restants en trois octets : sous-réseau, zéro obligatoire, puis hôte. L’octet de sous-réseau correspondait à celui de CHAOS. Les échanges de routes dynamiques envisagés ne furent pas mis en œuvre ; des tables statiques subsistèrent. Les redirections ICMP vers l’hôte limitaient les changements nécessaires dans les logiciels hôtes.

RFC 917 compare quatre façons de coder le sous-réseau. Sa proposition retient une largeur variable, mais constante dans chaque réseau : une organisation peut choisir combien de bits locaux consacrer aux sous-réseaux. Les schémas auto-encodés auraient permis de déduire la structure en lisant l’adresse, mais ils risquaient d’interférer avec des numéros d’hôte existants et de réduire l’espace local. Ce choix n’était pas entièrement global : chaque réseau conservait une marge sur son organisation interne.

Il fallait encore que les hôtes connaissent la largeur retenue. Pour les postes sans disque, RFC 917 propose des messages ICMP « Address Format Request » et « Address Format Reply » ; un fichier de configuration restait possible. Sans réponse de passerelle, un hôte pouvait démarrer avec une largeur nulle, puis se corriger lorsqu’une passerelle annonçait la valeur réelle. Ces messages ne doivent pas être confondus avec les messages Address Mask de RFC 950.

RFC 940 formule ensuite le problème d’interopérabilité : des hôtes de fournisseurs différents risquaient de ne pas s’accorder sur l’accès direct ou le passage par une passerelle. En août 1985, RFC 950, qui se dit fondée sur RFC 917, recommande une procédure commune pour les hôtes. Elle décrit moins complètement les échanges entre passerelles. La séquence documentée est donc pratique locale, proposition, puis standardisation partielle du contrat côté hôte.

La Note 64 de Heng Lu fournit ici une grille de lecture : un minimum de règles communes peut laisser aux organisations le choix de leur structure interne. C’est une interprétation éditoriale, pas une preuve des intentions de Mogul, de Stanford, du MIT ou de Postel.