Résumé
- La RFC 1188 a précisé l’encapsulation IP/ARP sur FDDI, le MTU IP de 4352 octets et des règles ARP capables de dialoguer avec un environnement Ethernet ponté.
- Une valeur LLC/SNAP, un EtherType, une adresse MAC ou une réponse ARP sont des faits de transport local ; ils ne prouvent ni personne, ni propriété, ni permission, ni livraison applicative.
Le même câble ne suffisait pas
La fibre FDDI pouvait être rapide, mais la vitesse ne disait pas quelle structure un récepteur devait reconnaître au-dessus du MAC. La RFC 1188, publiée en octobre 1990 par David Katz et remplaçant la RFC 1103, a formulé un accord précis pour IP et ARP. Elle reprenait la discipline d’interopérabilité de la RFC 1042 : LLC de type 1, puis SNAP, pour que le contenu d’une trame ne dépende pas d’une habitude privée du constructeur.
Les octets comptent ici parce qu’ils limitent la portée de leur propre affirmation. DSAP et SSAP à 0xAA, contrôle à 0x03, code d’organisation nul, puis identifiant de protocole : l’enveloppe désigne une grammaire pour IP ou ARP. Elle ne signe pas le paquet. Elle ne dit pas que l’adresse source appartient à une personne donnée. Elle ne donne pas au destinataire une compétence sur une autre machine et ne confirme pas qu’une application distante a traité les données.
Cette modestie est le mécanisme. Une interface doit pouvoir séparer un contenu IP d’un contenu ARP sans inventer une base d’identité. La compatibilité de liaison permet de lire le paquet au bon niveau ; toute conclusion sur l’auteur, l’autorisation ou l’effet demande des éléments qui ne vivent pas dans les huit octets LLC/SNAP.
4352 n’était pas une promesse pour le chemin entier
La RFC 1188 fixe le MTU FDDI à 4352 octets. Une trame maximale pouvait laisser environ 4470 octets après LLC/SNAP, mais le texte réserve une marge pour les variations et extensions de l’en-tête MAC ou de l’état de trame. Les passerelles doivent accepter les paquets de cette taille et les fragmenter si nécessaire. C’est une règle sur la frontière FDDI, pas une assurance sur toutes les frontières qui suivent.
Le texte garde d’ailleurs la prudence de l’Internet : un hôte ne doit pas envoyer plus que la limite générale de 576 octets sans savoir explicitement que la destination l’accepte. La RFC 1191 a ensuite consigné 4352 comme valeur FDDI dans un tableau historique de MTU de chemin. Ni le tableau ni l’interface locale ne mesurent une route réelle à un instant donné. Une capacité de premier saut, une obligation de fragmentation de passerelle et une acceptation de bout en bout restent des faits différents.
ARP trouvait un voisin, pas un titulaire
Le point le plus instructif concerne ARP. FDDI pouvait avoir des stations à 16 ou à 48 bits, mais la RFC impose les adresses de 48 bits pour IP et ARP. Pour ne pas exclure un pont Ethernet, elle demande d’émettre ARP avec le type matériel 1, d’accepter les types 1 ou 6 et de transporter les adresses en ordre canonique des bits. L’expression habituelle d’une adresse FDDI plaçait le bit Group autrement ; chaque octet devait donc être inversé dans le champ ARP.
Une telle précision ne rend pas une adresse plus souveraine. Elle évite qu’un même matériel soit mal lu quand deux conventions de liaison se rejoignent. L’entrée ARP aide un hôte à choisir une destination de trame au prochain saut local. Elle ne prouve pas une propriété, une présence physique, une route choisie, une autorisation ou la réception du datagramme par une application.
Une succession de RFC n’est pas une observation présente
La RFC 1390 a enregistré en 1993 un texte successeur devenu Internet Standard pour IP et ARP sur FDDI. Cette succession situe le document dans l’histoire des règles ; elle n’établit pas qu’une interface actuelle utilise FDDI, que la RFC 1188 était elle-même le standard courant, ni qu’un paquet réel a franchi un réseau nommé.
L’apport durable est donc une architecture de preuves. La trame porte un protocole défini. ARP porte une correspondance locale. Le MTU borne une taille de liaison. Chacun de ces faits est utile précisément parce qu’il ne prétend pas absorber identité, autorité, chemin et résultat dans le même mot de « succès ».
Sources et frontière de preuve
Les sources sont les RFC 1042, 1188, 1191 et 1390. Elles documentent des conventions, une taille historique et une succession de textes ; elles ne prouvent aucun déploiement actuel, aucune identité, aucun mandat, aucune livraison ou conséquence applicative.
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance
