fakelocFormats d'adresse MAC et relation EUI-64
Normalisez les formulaires de texte 48 bits courants et comprenez la transformation EUI-64 définie.
Résumé IA
Les séparateurs MAC changent de présentation, pas les octets sous-jacents. Validez les entrées de six octets avant la conversion ; distinguer l'expansion EUI-64 ordinaire de l'EUI-64 modifiée.
Plusieurs chaînes peuvent représenter les mêmes 48 bits
Les exemples incluent 00:11:22:AA:BB:CC, 00-11-22-AA-BB-CC et 0011.22AA.BBCC. Analysez exactement six octets après avoir supprimé les séparateurs pris en charge ; rejeter les caractères mixtes, supplémentaires ou non hexadécimaux.
L'ancienne recette EUI-64 IID modifiée
Pour l'ancienne recette d'identifiant d'interface IPv6 documentée dans la RFC 4291, insérez FF:FE entre le premier et les trois derniers octets d'une adresse de couche liaison de 48 bits, puis inversez le bit universel/local. Il s'agit d'une construction EUI-64 IID modifiée ; cela ne veut pas dire que la sortie est l’adresse IPv6 actuelle de l’interface.
Input 48-bit address: 00:11:22:AA:BB:CC Insert FF:FE for legacy IID: 00:11:22:FF:FE:AA:BB:CC Invert U/L bit (Modified IID): 02:11:22:FF:FE:AA:BB:CC IPv6 IID grouping: 0211:22ff:feaa:bbcc
Les IID stables modernes ne devraient pas intégrer de MAC stable par défaut
La RFC 8064 met à jour la recommandation par défaut : utilisez la RFC 7217 pour les identifiants d'interface SLAAC stables et n'intégrez pas d'adresse de couche liaison stable par défaut. Une valeur de forme EUI-64 ne peut à elle seule prouver comment un IID a été généré.
Utilisez un analyseur qui rejette toute ambiguïté
Testez chaque notation acceptée, hexadécimal minuscule, remplissage nul, longueurs non valides et exemples de multidiffusion/locale. Conservez l'entrée d'origine pour l'affichage tout en utilisant des octets normalisés à des fins de comparaison.