Date de publication du RFC : Décembre 2020
Auteur(s) du RFC : CJ. Bernardos (UC3M), A. Mourad (InterDigital)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF dhc
Première rédaction de cet article le 2 décembre 2020
Les adresses MAC sur 48
bits, normalisées par l'IEEE, ont un bit qui indique si
l'adresse découle d'un plan mondial et est donc globalement unique,
ou bien si elle a été allouée via une méthode locale. Plus
récemment, l'IEEE a découpé l'espace local en quatre quadrants, pouvant avoir
des poltiques différentes. Depuis qu'on peut allouer ces adresses
MAC locales par DHCP (RFC 8947), il serait intéressant de choisir son
quadrant. C'est ce que permet la nouvelle option DHCP
QUAD
normalisée dans ce nouveau RFC.
Tout·e étudiant·e en réseaux informatiques a appris le découpage des adresses MAC de 48 bits via le bit U/L (Universal/Local). Les adresses avec ce bit à 1 sont gérées localement (et donc pas forcément uniques au niveau mondial). En 2017, l'IEEE a ajouté un nouveau concept, le SLAP (Structured Local Address Plan). L'espace des adresses locales est découpé en quadrants, identifiés par deux bits (troisième et quatrième position dans l'adresse) :
De son côté, l'IETF a, dans le RFC 8947, normalisé une option de DHCPv6 qui permet d'obtenir des adresses MAC par DHCP.
Or, dans certains cas, une machine pourrait vouloir choisir le quadrant dans lequel son adresse MAC se situe. Le RFC cite l'exemple d'objets connectés qui voudraient une adresse dans le quadrant ELI (Extended Local Identifier) pour avoir l'identifiant du fabricant au début de l'adresse, sans pour autant que le fabricant ne soit obligé d'allouer à la fabrication une adresse unique à chaque objet. Par contre, des systèmes qui changeraient leur adresse MAC pour éviter la traçabilité préféreraient sans doute un adresse dans le quadrant AAI (Administratively Assigned Identifier). L'annexe A du RFC est très intéressante de ce point de vue, décrivant plusieurs scénarios et les raisons du choix de tel ou tel quadrant.
Notre nouveau RFC ajoute donc une option au protocole DHCP
que normalisait le RFC 8415. Elle se nomme
QUAD
et repose sur l'option
LLADDR
du RFC 8947. Le
client met cette option QUAD
dans la requête
DHCP, pour indiquer son quadrant favori. Le serveur ne l'utilise pas
dans la réponse. Soit il est d'accord pour allouer une adresse MAC
dans ce quadrant et il le fait, soit il propose une autre
adresse. (Rappelez-vous qu'en DHCP, le client propose, et le serveur
décide.) Le client regarde l'adresse renvoyée et sait ainsi si sa
préférence pour un quadrant particulier a été satisfaite ou pas.
La section 4 décrit les détails de l'option
QUAD
. Elle permet d'exprimer une liste de
quadrants, avec des préférences associées. L'option est désormais
enregistrée
à l'IANA (code 140).
Pour l'instant, je ne connais pas de mise en œuvre de ce RFC que ce soit côté client ou serveur.
Version PDF de cette page (mais vous pouvez aussi imprimer depuis votre navigateur, il y a une feuille de style prévue pour cela)
Source XML de cette page (cette page est distribuée sous les termes de la licence GFDL)