fakelocMAC-Adressformate und die EUI-64-Beziehung
Normalisieren Sie gängige 48-Bit-Textformen und verstehen Sie die definierte EUI-64-Transformation.
KI-Zusammenfassung
MAC-Trennzeichen ändern die Anzeige, nicht die Bytes; Validieren Sie die Sechs-Byte-Eingabe und unterscheiden Sie Standard von modifiziertem EUI-64.
Mehrere Zeichenfolgen können dieselben 48 Bit darstellen
Beispiele hierfür sind 00:11:22:AA:BB:CC, 00-11-22-AA-BB-CC und 0011.22AA.BBCC. Analysieren Sie genau sechs Oktette, nachdem die unterstützten Trennzeichen entfernt wurden. Lehnt gemischte, zusätzliche oder nicht hexadezimale Zeichen ab.
Das alte modifizierte EUI-64-IID-Rezept
Fügen Sie für das in RFC 4291 dokumentierte Rezept für die Legacy-IPv6-Schnittstellenkennung FF:FE zwischen den ersten und letzten drei Oktetten einer 48-Bit-Link-Layer-Adresse ein und invertieren Sie dann das universelle/lokale Bit. Dies ist eine modifizierte EUI-64 IID-Konstruktion; Es wird nicht behauptet, dass die Ausgabe die aktuelle IPv6-Adresse der Schnittstelle ist.
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
Moderne stabile IIDs sollten standardmäßig keinen stabilen MAC einbetten
RFC 8064 aktualisiert die Standardempfehlung: Verwenden Sie RFC 7217 für stabile SLAAC-Schnittstellenkennungen und betten Sie standardmäßig keine stabile Link-Layer-Adresse ein. Ein EUI-64-förmiger Wert allein kann nicht beweisen, wie eine IID generiert wurde.
Verwenden Sie einen Parser, der Mehrdeutigkeiten ablehnt
Testen Sie jede akzeptierte Notation, Kleinbuchstaben-Hexadezimalschrift, Nullauffüllung, ungültige Längen und Multicast-/lokale Beispiele. Behalten Sie die ursprüngliche Eingabe für die Anzeige bei und verwenden Sie normalisierte Bytes zum Vergleich.