Résumé

  • RFC 948 présentait en juin 1985 deux façons de transporter IP sur un réseau physique IEEE 802.3. La première conservait l'interprétation Ethernet du champ de type de protocole; la seconde utilisait la couche logique IEEE 802.2. Les deux pouvaient occuper le même câble sans former une conversation IP commune.
  • Ira Winston proposait d'équiper chaque hôte d'un choix statique de format, de maintenir l'ancien cadrage pendant la préparation et de basculer l'ensemble du réseau seulement quand tous seraient prêts. Une passerelle parlant les deux formats pouvait relier des groupes déjà séparés, avec une pénalité de performance que le texte jugeait importante.

Même prise, autre grammaire

RFC 948 commence par une distinction qui aurait pu coûter cher à l'opérateur pressé. Ethernet Version 2.0 et IEEE 802.3 étaient compatibles au niveau physique dans la pratique. Au niveau de la liaison, ils ne l'étaient pas. Le même emplacement dans l'en-tête valait « type de protocole » pour Ethernet et « longueur » pour 802.3. Avant de livrer IP au système, le récepteur devait comprendre de quel langage provenait l'enveloppe. Le connecteur ne pouvait pas répondre à sa place.

La première méthode de Winston préservait les installations Ethernet existantes. Sur le réseau 802.3 de 10 Mbit/s décrit, la longueur autorisée ne dépassait pas 1500. Des valeurs supérieures pouvaient recevoir un usage privé. Les types employés pour IP, ARP et les formats à queue dépassaient cette limite : on pouvait donc exploiter cet espace pour transmettre des trames de style Ethernet sur une interface physique compatible 802.3. C'était une manière de garder les anciens hôtes dans la conversation, pas une harmonisation magique des deux conventions.

La seconde méthode suivait l'en-tête logique IEEE 802.2/802.3. Le datagramme IP entrait dans une trame LLC Type 1 Unnumbered Information, avec DSAP et SSAP réglés à 96, le point d'accès attribué à IP dans le document. Si la taille minimale de la trame l'exigeait, des octets zéro complétaient la charge physique sans faire partie du datagramme IP. Le texte recommandait fortement une découverte d'adresse de type ARP. Ces mécanismes rendaient le format utilisable entre hôtes qui le partageaient. Ils n'apprenaient pas à un ancien hôte Ethernet à lire soudain l'autre en-tête.

La date du basculement était un composant technique

Dans sa conclusion, Winston décrivait le résultat d'un mélange sans détour : deux sous-réseaux incompatibles sur le même réseau local. Un hôte bilingue pourrait assurer une fonction de passerelle, mais le prix en performance serait important. Le trafic entre deux voisins physiques prendrait alors le détour d'une machine qui réinterprète leurs trames. Une vue du câblage montrerait un seul LAN; la circulation des paquets en montrerait deux.

L'auteur préférait l'encapsulation IEEE 802.2/802.3. Ses arguments étaient la reconnaissance nationale et internationale des normes IEEE et la possibilité de réutiliser la même approche sur d'autres supports IEEE 802. Mais les anciens équipements transmettaient déjà IP en Ethernet. Son plan consistait donc à donner le choix statique aux implémentations neuves et anciennes, à garder tous les hôtes en mode compatible Ethernet pendant la préparation, puis à passer ensemble à la méthode IEEE. La dernière machine incapable de choisir comptait autant que la première prête à changer.

RFC 1042, publié en 1988, montre que le détail des choix a continué à bouger. Cette spécification utilisait LLC/SNAP : DSAP et SSAP valaient 170, suivis d'un code d'organisation nul et de l'EtherType, au lieu du SAP 96 direct de RFC 948. Elle précisait aussi qu'une diffusion au niveau liaison n'atteignait que les ordinateurs utilisant le même format, même si les deux formats partageaient le câble. Lorsque le mélange était nécessaire, elle recommandait une passerelle IP entre réseaux distincts.

Le texte ultérieur confirme la frontière d'interopérabilité; il ne donne aucun journal d'une migration exécutée selon le calendrier proposé en 1985.

Une prise compatible est une promesse matérielle. La lecture commune des trames est une décision collective. RFC 948 exigeait de ne pas confondre les deux, parce que la facture d'un désaccord arrivait au trafic, à la diffusion et à la passerelle.

Sources