Mon blog

Les identificateurs IEEE 802 comme les adresses MAC d'Ethernet ne sont pas gérés par l'IETF et ne sont pas dans un registre IANA. C'est l'IEEE qui les distribue et en garde trace. Toutefois, certains protocoles IETF dépendent de ces identificateurs et ce RFC documente cet usage. Il décrit l'OUI (Organizationally Unique Identifier) attribué à l'IANA, le 00-00-5E, et indique à quoi il peut servir et comment. Ce nouveau RFC remplace l'ancien RFC 5342, avec quelques changements importants. Il a depuis lui-même été remplacé par le RFC 9542.

Parmi les exemples d'utilisation d'identificateurs IEEE 802, on peut citer les adresses d'IPv6 qui, en auto-configuration sans état, sont dérivées de l'adresse MAC. Ou bien les types de paquets Ethernet comme 0x0800 pour IPv4 et 0x86DD pour IPv6. Mais la plus grande partie de ce RFC est consacrée à l'OUI (Organizationally Unique Identifier) de l'IANA, et comment allouer des identificateurs commençant par cet OUI. Ce RFC en écrit certains, comme ceux réservés à la documentation. Fini de choisir des adresses Ethernet au hasard lorsqu'on rédige un cours ou un manuel sur ARP ! Normalement, depuis la publication de notre RFC, on utilise désormais des adresses prévues à cet effet, suivant les recommandations des RFC 2606 et RFC 5737.

On l'a dit, c'est l'IEEE qui tient le registre de ces identificateurs. L'IEEE est l'héritier de la société Xerox qui avait créé le registre. Tout le monde peut obtenir des valeurs dans ce registre mais l'IEEE, organisation très traditionnaliste, fait payer très cher (570 $ pour la norme Ethernet, certaines sont distribuées gratuitement), et ne publie pas la liste intégrale des enregistrements. Toutefois, les autres SDO peuvent obtenir gratuitement certaines valeurs.

Parmi ces paramètres, les OUI, identificateurs uniques d'une organisation (registre à l'IEEE). Ils sont surtout connus car ils servent à préfixer les adresses Ethernet. Dell ayant entre autres l'OUI 18-03-73 (l'IEEE publie une liste partielle, on trouve une liste dans le programme arpwatch, installée en /usr/share/arpwatch/ethercodes.dat et une autre est en ligne), une machine de ce constructeur peut avoir, par exemple, l'adresse 18-03-73-66-e5-68 sur sa carte Ethernet (notre RFC utilise le tiret comme séparateur - cf. section 1.1 - alors qu'on voit souvent le deux-points dans d'autres contextes). L'IANA, on l'a vu, a l'OUI 00-00-5E. L'IEEE ne fournit pas d'OUI pour les documentations, donc l'IANA a réservé des identificateurs sous son OUI à elle, pour cet usage.

Le gros morceau du RFC, la section 2, concerne les adresses MAC de type Ethernet, l'utilisation la plus connue du registre IEEE. Aujourd'hui, elles existent en deux formats, le classique, de 48 bits, nommé EUI-48, un format plus récent sur 64 bits, l'EUI-64, et l'IEEE est actuellement en train d'étudier la possibilité de créer un format EUI-128 sur 128 bits.

Les EUI-48, archi-connus en raison de leur rôle dans l'adressage Ethernet, Wi-Fi, etc, sont mondialement uniques. Si une machine a 38-59-f9-7d-b6-47, elle sera la seule au monde dans ce cas (sauf erreur dans les processus de fabrication des cartes réseaux). Les six octets de ces adresses se divisent en un OUI de trois octets (38-59-f9 dans l'exemple précédent, identifiant la société Foxconn alias Hon Hai) et trois octets attribués par le titulaire de l'OUI (l'IEEE n'enregistre donc pas les adresses individuelles mais seulement les OUI). À noter que, dans les trois octets initiaux, ceux de l'OUI, deux bits ont une signification spéciale. Le Group bit indique si l'adresse MAC est multicast (s'il est à 1) ou unicast. Le Local bit dit si l'adresse MAC est mondialement unique (s'il est à 0) ou si elle est gérée localement sans souci du reste du monde (si le bit est à 1). Dans les OUI attribués par l'IEEE, comme le 00-00-5E de l'IANA, le Local bit est à 0. Ainsi, avec un seul OUI, on peut fabriquer des identificateurs unicast ou multicast. De même, les identificateurs peuvent être globaux ou purement locaux (et, dans ce dernier cas, l'OUI n'a plus d'importance).

Il y a quelques plages d'adresses spéciales sous l'OUI IANA. Ainsi, en unicast, les plages de 00-00-5E-00-00-00 à 00-00-5E-00-00-FF et de 00-00-5E-00-52-00 à 00-00-5E-00-52-FF sont réservées pour de futures allocations par l'IANA, celles de 00-00-5E-00-01-00 à 00-00-5E-00-01-FF et de 00-00-5E-00-02-00 à 00-00-5E-00-02-FF pour le protocole VRRP, du RFC 5798, protocole qui nécessite que la machine change son adresse MAC. Et 00-00-5E-00-53-00 à 00-00-5E-00-53-FF est réservée pour la documentation. Vous pouvez trouver la liste complète dans le registre IANA. Si je regarde les adresses MAC des voisins de ma machine :

% ip -6 neighbor show                                
fe80::10:dbff:feff:4070 dev eth1 lladdr 00:10:db:ff:40:70 router REACHABLE

Je peux trouver le type de machine dans la liste locale des OUI :

% grep 0:10:db /usr/share/arpwatch/ethercodes.dat 
0:10:db	Juniper Networks, Inc.

Et si j'écris une documentation sur le protocole NDP, je vais mettre à la place des jolies adresses réservées pour la documentation :

% ip -6 neighbor show                                
fe80::5eff:feff:4070 dev eth1 lladdr 00:00:5e:ff:40:70 router REACHABLE

Les allocations IANA doivent correspondre à un travail de normalisation d'un protocole (décrit dans un RFC ou bien un Internet-Draft), et ne doivent pas être utilisées comme moyen d'échapper aux règles « normales » de l'IEEE. Dans la plage de 00-00-5E-00-52-00 à 00-00-5E-00-52-FF, la procédure est simplement celle d'un examen par un expert (section 4.1 du RFC 5226), et le RFC recommande un examen léger (l'espace d'adressage est large et il n'est pas nécessaire d'économiser). Dans celle de 00-00-5E-00-00-00 à 00-00-5E-00-00-FF, la procédure est un cas nouveau, non documenté dans le RFC 5226 et nommé « ratification par l'IESG ». Le concept de « ratification par l'IESG » est introduit dans ce RFC 7042 (section 5.1) pour dire « examen par un expert, puis, après son accord, passage devant l'IESG qui peut refuser ». L'annexe A de notre RFC contient les formulaires à remplir pour demander ces enregistrements.

Et pour les EUI-64 ? La section 2.2 rappelle leurs usages, comme la fabrication de la partie droite, l'« Interface Identifier », des adresses IPv6 (section 2.5.1 et annexe A du RFC 4291 et annexe A du RFC 5214), ou comme l'adressage FireWire. Attention, dans les adresses IPv6, le sens du Local bit a été inversé (0 veut dire que l'adresse est locale). En EUI-64 modifié (avec cette inversion du bit local), le préfixe IANA est 02-00-5E.

On y retrouve des plages analogues à celles des EUI-48 comme celle de 02-00-5E-10-00-00-00-00 à 02-00-5E-10-00-00-00-FF pour la documentation, avec des règles identiques.

Outre le préfixe IANA 00-00-5E, il existe deux autres préfixes utilisés dans la normalisation IETF (section 2.3), 33-33, pour du multicast IPv6 (RFC 2464), et CF pour PPP (RFC 2153). Le premier doit sa valeur à l'adresse du PARC, 3333 Coyote Hill Road, Palo Alto, Californie, où a été conçu Ethernet. Le second est officiellement fermé aux nouveaux enregistrements.

Après cette section 2 consacrée aux adresses MAC, la section 3 regroupe tous les autres paramètres IEEE utilisés par l'IETF. On y trouve notamment les types Ethernet qui, placés dans la trame Ethernet après les adresses, indique le type du protocole de niveau supérieur. Ils comportent deux octets, 0x0800 pour IPv4, 0x0806 pour ARP, 0x86DD pour IPv6, 0x22F3 pour TRILL, etc. Ils sont gérés par l'IEEE mais sont mentionnés ici (annexe B pour une liste partielle) pour compléter l'information. Un mécanisme d'extension est prévu pour utiliser des types plus longs que deux octets et c'est ainsi que 00-00-5E-00-42 est un numéro de protocole valable, réservé pour la documentation.

Les OUI sont aussi utilisés comme préfixes pour d'autres choses, par exemple les sélecteurs d'un algorithme de chiffrement dans IEEE 802.11. La section 4 décrit l'allocation de paramètres sous le préfixe IANA pour ces usages. Là encore, cela ne doit être fait que dans le cadre d'un processus de normalisation, avec spécification publiée.

Les changements depuis le RFC 5342 ne sont peut-être pas spectaculaires mais sont importants. Il y a l'ajout des adresses MAC de documentation. Mais il y a surtout la suppression de la règle (section 2.1.2 du RFC 5342) « allocation pour l'unicast et le multicast en même temps » qui devait simplifier le travail de l'IANA mais qui s'est avérée trop difficile à suivre. Désormais, on peut donc réserver séparement pour l'unicast et le multicast.

Autres changements, l'intégration des réflexions actuellement en cours sur la restructuration des registres IEEE, en raison des risques d'épuisement des identificateurs IEEE, et ajout des types d'enregistrement DNS EUI48 et EUI64 pour les adresses MAC (décrits en détail dans le RFC 7043).