fix: reject MAC addresses with mixed separators

[iCasture]

Previously, the MAC address validator would accept invalid MAC addresses that mixed different separators, such as aa:bb-cc-dd:ee:ff, but a valid MAC address should use consistent separators throughout.

This PR improves the MAC address validator by adding a check to reject MAC addresses that use mixed separators (both : and - characters).

[yozachar]

Previously, the MAC address validator would accept invalid MAC addresses that mixed different separators, such as aa:bb-cc-dd:ee:ff, but a valid MAC address should use consistent separators throughout.

This PR improves the MAC address validator by adding a check to reject MAC addresses that use mixed separators (both : and - characters).

Hi @iCasture, can you please provide a reference to where such a requirement is specified.

[iCasture]

@yozachar

According to IEEE 802-2014, two textual representations were defined:

• The Hexadecimal representation, which displays each octet as a two-digit hexadecimal number separated by hyphens (-).

• The Bit-reversed representation, which used colons (:) as separators. However, this form is only of historical interest and is no longer applicable to any active IEEE 802 standard.

Hexadecimal representation is a sequence of octet values in which the values of the 
individual octets are displayed in order from left to right, with each octet value 
represented as a 2-digit hexadecimal numeral and with the resulting pairs of hexadecimal 
digits separated by hyphens. The order of the hexadecimal digits in each pair, as well 
as the mapping between the hexadecimal digits and the bits of the octet value, is 
derived by interpreting the bits of the octet value as a binary numeral using the 
normal mathematical rules for digit significance.

Bit-reversed representation is a sequence of octet values in which the values of the
individual octets are displayed in order from left to right, with each octet value 
represented as a 2-digit hexadecimal numeral and with the resulting pairs of hexadecimal 
digits separated by colons. The order of the hexadecimal digits in each pair, as 
well as the mapping between the hexadecimal digits and the bits of the octet value, 
is derived by reversing the order of the bits in the octet value and interpreting 
the resulting bit sequence as a binary numeral using the normal mathematical rules 
for digit significance.

NOTE—The bit-reversed representation is of historical interest only and is no longer 
applicable to any active IEEE 802 standard.

RFC 7043 is explicit:

EUI48 RR Presentation Format

The Address field MUST be represented as six two-digit hexadecimal numbers separated 
by hyphens. The hexadecimal digits "A" through "F" MAY be represented in either upper 
or lower case.

In practice, people also write MAC addresses with colons instead of hyphens, and sometimes even with dots — even though the IEEE format is hyphen-separated. For example, Wikipedia: Notational conventions and Talk:MAC address: Canonical presentation format mention this usage:

Notational conventions

The standard (IEEE 802) format for printing EUI-48 addresses in human-friendly form is 
six groups of two hexadecimal digits, separated by hyphens (-) in transmission order 
(e.g. 01-23-45-67-89-AB). This form is also commonly used for EUI-64 
(e.g. 01-23-45-67-89-AB-CD-EF).[3] Other conventions include six groups of two hexadecimal 
digits separated by colons (:) (e.g. 01:23:45:67:89:AB), and three groups of four 
hexadecimal digits separated by dots (.) (e.g. 0123.4567.89AB); again in transmission order.[31]

Cisco documentation explicitly lists the three supported formats:

ACS supports the following three standard formats for representing MAC-48 addresses in human-readable form:

- Six groups of two hexadecimal digits, separated by hyphens (-) in transmission order, for example, 01-23-45-67-89-ab.

- Six groups of two separated by colons (:), for example, 01:23:45:67:89:ab.

- Three groups of four hexadecimal digits separated by dots (.), for example, 0123.4567.89ab.

Microsoft’s .NET PhysicalAddress.Parse Method likewise accepts:

The address parameter must contain a string that can only consist of numbers and letters 
as hexadecimal digits. Some examples of string formats that are acceptable are as follows:

001122334455
00-11-22-33-44-55
0011.2233.4455
00:11:22:33:44:55
F0-E1-D2-C3-B4-A5
f0-e1-d2-c3-b4-a5

Go’s net.ParseMAC function accepts the following formats:

ParseMAC parses s as an IEEE 802 MAC-48, EUI-48, EUI-64, or a 20-octet IP over InfiniBand
link-layer address using one of the following formats:

00:00:5e:00:53:01
02:00:5e:10:00:00:00:01
00:00:00:00:fe:80:00:00:00:00:00:00:02:00:5e:10:00:00:00:01
00-00-5e-00-53-01
02-00-5e-10-00-00-00-01
00-00-00-00-fe-80-00-00-00-00-00-00-02-00-5e-10-00-00-00-01
0000.5e00.5301
0200.5e10.0000.0001
0000.0000.fe80.0000.0000.0000.0200.5e10.0000.0001

So basically, the examples show that you can write a MAC address with hyphens, colons, dots, or just no separators at all — but you’ve got to pick one style and stick with it. There’s no spec or implementation that allows mixing : and - in the same string.

If we want to be more flexible, we could also support the dotted form (0011.2233.4455) or the plain hex form (001122334455). The main point is just that whichever style is supported, it should be consistent across the whole address.

Reference:

https://wiert.me/2022/07/06/hardware-mac-address-formats-which-i-need-for-wake-on-lan-ps1/#:~:text=,A5

[yozachar]

Thanks for that @iCasture !