proposal: net: allow ParseMAC to handle pure base-16 numerical representation without hyphens

[steabert]

Proposal Details

The ParseMac function in https://github.com/golang/go/blob/master/src/net/mac.go says:

// 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

When reading the EUI guidelines however, it states in section "EUI Structure and Representation":

...[EUI-48/EUI-64] can be represented in the IEEE RA hexadecimal (hex) form with the octets separated by hyphens, or as a pure base-16 numerical representation without hyphens. It may also be represented as a binary number or sequence, as illustrated.

And on Wikipedia:

As typically represented, MAC addresses are recognizable as six groups of two hexadecimal digits, separated by hyphens, colons, or without a separator.

I haven't come across binary representations as the guidelines say are allowed, but it does happen (frequently enough) that the octets don't have a separator. In those cases I had to resort to a custom implementation of HardwareAddr just to deal with that case. I was not sure if this would be considered a bug (since the docs do state it should support EUI-48/EUI-64, but there does not seem to be an official required representation). However, this would slightly change the behaviour of ParseMAC in that it would accept a format without separators where it previously would return an error. So I filed this proposal instead of a bug report.

I think that extending ParseMAC to allow for a format without separators (only for the shorter formats EUI-48 and EUI-64) would at least (1) match what's stated in the documentation and (2) resolve the need for custom implementation at least for a use case that is frequent enough for me personally to care about (but of course I have no idea how common this is in general).

This would then allow the following formats in addition to those already mentioned:

//      00005e005301
//      02005e1000000001