Résumé

  • L’IEEE Registration Authority attribue les EtherTypes et les LSAP, puis a délégué à IANA l’OUI 00-00-5E ; IANA n’agit qu’à l’intérieur de cet espace délégué.
  • Le numéro de deux octets qui suit l’OUI IANA n’est pas un EtherType. Le support extérieur, l’OUI et la valeur intérieure forment ensemble la preuve d’identité.
  • La RFC 9542 sépare la position dans la trame, le propriétaire du registre, la procédure d’attribution, la spécification et le comportement réel de l’équipement.

L’erreur n’était pas dans l’hexadécimal. Les octets avaient été lus correctement. C’est leur filiation qui avait disparu entre la capture et le compte rendu.

La séquence 88-B7-00-00-5E-00-42 contient trois décisions. L’IEEE Registration Authority a attribué 0x88B7 comme EtherType d’extension OUI. La même autorité a attribué l’OUI 00-00-5E à IANA. Enfin, dans cet espace, IANA a réservé 0x0042 pour la documentation. Dire seulement « 0042 » revient à conserver un numéro de porte tout en supprimant la rue, la ville et le cadastre.

La RFC 9542, publiée en avril 2024 comme BCP 141, remplace la RFC 7042. Elle ne crée aucun nouveau registre IANA et ne modifie aucune attribution existante. Elle clarifie surtout une architecture de délégation : une institution peut administrer un sous-espace sans devenir l’autorité de tout le champ qui le transporte.

Lire la forme avant de chercher le nom

Un EtherType est une valeur de seize bits au moins égale à 0x0600. Dans la forme Ethernet la plus simple, il suit les adresses MAC, éventuellement après des étiquettes. Son attribution relève de l’IEEE RA. Un en-tête LLC suit une autre logique : un champ de longueur précède deux LSAP de huit bits. La forme SNAP ajoute AA-AA-03, un OUI de trois octets et un numéro de protocole de deux octets.

Cette dernière valeur appartient au détenteur de l’OUI. Si l’OUI vaut 00-00-5E, le détenteur est IANA. Si les trois octets sont nuls, la valeur terminale peut représenter un EtherType déjà attribué. Les mêmes deux positions dans le dessin ne renvoient donc pas nécessairement au même registre.

L’EtherType 0x88B7 fournit encore un autre transport. Il annonce qu’un OUI et un numéro de protocole suivent. Dans 88-B7-00-00-5E-qq-qq, 0x88B7 dépend de l’IEEE et qq-qq dépend d’IANA. Aucune proximité physique ne fusionne ces mandats.

Cette lecture par couches évite une confusion fréquente dans les inventaires. Une colonne unique nommée « type » paraît commode, mais elle perd le support et le propriétaire du sous-espace. Deux systèmes peuvent stocker la même valeur 0042 tout en parlant de réalités incompatibles. Une base de données qui a supprimé l’OUI ne peut pas les départager après coup.

Le serveur du tableau ne possède pas forcément le registre

IANA publie un groupe « IANA OUI Ethernet Numbers ». Il contient les valeurs attribuées sous son propre OUI, notamment le registre des numéros SNAP et la valeur documentaire 0x0042. Dans ce contexte, IANA tient bien le registre d’attribution.

Elle publie aussi « IEEE 802 Numbers ». La rubrique EtherTypes indique explicitement que ces nombres ne sont pas attribués par IANA. Elle présente la liste comme une compilation informative et non vérifiée, puis renvoie vers l’IEEE RA. L’hébergement améliore l’accès ; il ne transfère pas la compétence.

Pour un humain, l’avertissement est visible. Pour un extracteur automatique, il est facile à perdre. Une chaîne de traitement peut aspirer les lignes, signer le fichier, comparer les versions et produire un tableau impeccable dont la colonne « autorité » est fausse. Le contrôle pertinent ne consiste pas seulement à vérifier le domaine du lien. Il faut enregistrer la déclaration de responsabilité du registre.

Cette distinction devient stratégique lorsque des règles de sécurité s’appuient sur la provenance. Un pare-feu, un analyseur ou une politique d’admission peut traiter différemment une expérimentation locale, un exemple documentaire et un protocole normalisé. Une mauvaise autorité n’est donc pas une note bibliographique ; elle peut devenir une décision d’exécution.

Les règles d’attribution dessinent la frontière

Sous l’OUI IANA, un nouveau numéro de protocole doit servir une norme IETF ou une norme liée aux travaux IETF. Le protocole doit être décrit dans un Internet-Draft ou une RFC. Il doit posséder un champ de version à position fixe, ou un marquage équivalent permettant aux versions anciennes de reconnaître les futures. L’attribution ordinaire passe par Expert Review ; 0x0000 et 0xFFFF, réservés, exigent une ratification de l’IESG.

La RFC refuse aussi le doublon : un protocole déjà doté d’un EtherType ne doit pas recevoir un nouveau numéro sous l’OUI IANA. Son EtherType peut être utilisé directement ou transporté dans SNAP derrière l’OUI nul. Cette règle protège le lien entre un identifiant et son historique d’autorisation.

Le même principe limite les adresses sous 00-00-5E. Les blocs doivent répondre à un besoin de normalisation, respecter des tailles et alignements en puissances de deux et ne pas servir à éviter l’achat d’un bloc IEEE par un fabricant d’interfaces. La délégation est un outil de coordination ciblé, pas une licence pour concurrencer le délégant.

Une valeur d’exemple n’est pas une valeur d’essai

Sous l’OUI IANA, 0x0042 sert à la documentation. Dans d’autres paramètres organisationnels à un octet, 0x42 remplit le même rôle. Ces valeurs permettent à une RFC, un manuel ou un test de documentation d’afficher des octets concrets sans empiéter sur une affectation opérationnelle.

L’IEEE réserve par ailleurs les EtherTypes 0x88B5 et 0x88B6 aux expériences locales. Ils n’appartiennent ni au même registre ni à la même politique. Employer l’expression « EtherType expérimental 0042 » fabrique une catégorie qui n’existe pas.

L’effet pratique peut être durable. Une valeur documentaire copiée dans un équipement de production crée une dépendance sans attribution. Une valeur expérimentale autorisée au-delà du domaine local peut entrer en collision avec une autre expérience. La bonne réponse est de conserver, avec le nombre, son périmètre et sa date d’effet.

Le registre ne prouve pas le paquet

Une entrée d’attribution établit qu’une autorité a réservé une valeur dans un espace donné. Elle ne prouve pas qu’un logiciel sait la décoder, qu’un équipement a émis la trame attendue, que la charge utile correspond au nom du protocole ni que l’application a obtenu le résultat prévu.

La preuve complète comporte plusieurs reçus. Les octets et leurs positions établissent la forme. L’OUI établit le sous-espace. Le registre autoritatif établit l’attribution. La procédure et la spécification établissent les conditions. La version du parseur et sa configuration établissent l’interprétation locale. La capture établit l’événement observé. Le destinataire établit l’effet.

Confondre ces niveaux donne au registre un mandat qu’il n’a jamais reçu. L’autorité d’unicité devient alors, par glissement, une prétendue certification du code en fonctionnement. La force de la RFC 9542 réside au contraire dans sa modestie : elle dit où commence et où s’arrête chaque responsabilité.

Un inventaire utilisable en situation de crise

Un inventaire robuste conserve le support extérieur, l’identifiant OUI complet, l’autorité, la source et sa date, la catégorie de politique, le document normatif, la version du décodeur et le résultat observé. Les libellés conviviaux restent utiles, mais jamais seuls.

Cette structure rend les divergences réparables. Une liste informative peut être en retard sur l’IEEE RA. Un registre IANA peut être exact tandis qu’un analyseur l’affiche comme EtherType. Un exemple peut apparaître en production. Chacun de ces cas demande une action différente ; aucun ne se résout en choisissant arbitrairement le tableau le plus accessible.

Le nombre n’était donc pas le problème. L’oubli du chemin d’autorité l’était. Lorsque 00-00-5E reste attaché à 00-42, IANA apparaît comme délégataire dans un espace précis. Lorsqu’il disparaît, deux octets peuvent être transformés en mandat universel.

Sources