Runtime: PhysicalAddress.Parse should be case-insensitive and support new formats

[iSazonov]

Split from dotnet/runtime#26188 See triage conclusion https://github.com/dotnet/corefx/issues/29740#issuecomment-537243912

1. System.Net.NetworkInformation.PhysicalAddress.Parse() method currently support only following formats:

00-11-22-33-44-55

Really we can find that more formats is used by verdors and humans:

00:11:22:33:44:55
0011:2233:4455

1. Also docs says that the Parse() method only support upper-case letters as hexadecimal digits but some application and humans can type macs in lower-case - it will be not so big overhead to make the method _case-insensitive_.

[scalablecory]

This seems relatively straightforward if you'd like to submit a PR.

[eugenesmlv]

Hi! Is this still up for grabs? I would like to pick this issue as my first contribution.

[mvalenta]

I actually have code changes ready to submit to a PR that handles colon based formats and lowercase letters. @scalablecory should period based formats ("MMM.MMM.SSS.SSS", metioned in the linked lifewire site) also be handled?

[scalablecory]

Do you have data on where these other formats are used and how common they are? I know that 00-11-22-33-44-55 is the only format defined by the standard. 001122334455 is used in some parts of Windows, and 00:11:22:33:44:55 is used in ifconfig on Linux. Where do the others come from?

[am11]

I do not have usage data but period-separated MAC address format is recognized by Cisco.

[iSazonov]

@scalablecory Yes, you also could look how Cisco format MACs. We can not ignore formats from the dominant networking vendor. Also HP, see https://techhub.hpe.com/eginfolib/networking/docs/switches/RA/15-18/5998-8151_ra_2620_asg/content/ch03s07.html

[mvalenta]

@iSazonov I looked around for some Cisco MAC formats and could only find "0011.2233.4455" formats. I didn't see anything for format "001.122.334.455". Not saying that format isn't used _at all_, but if it is, it doesn't seem to be used by Cisco from what I can tell.

I did find a comment about Huawei firewalls having another separate format "ab12-cd34-ef56", and an FAQ page seems to confirm this.

While these may be considered edge cases, I have separate branches with working code to accomodate each of these cases separately on my fork, so I can submit a PR for whatever is preferred.

References:

1. https://www.cisco.com/c/m/en_us/techdoc/dc/reference/cli/n5k/commands/show-mac-address-table.html
2. https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus6000/sw/layer2/6x/b_6k_Layer2_Config_6x/b_6k_Layer2_Config_602N12_chapter_01010.pdf
3. https://community.cisco.com/t5/policy-and-access/mac-address-format-question/td-p/846665
4. https://community.spiceworks.com/topic/932330-mac-address-format-what-s-the-standard-why-don-t-vendors-stick-to-it
5. https://forum.huawei.com/enterprise/en/corpus-2804.html

[iSazonov]

I think Cisco and Linux format should be supported "out of box". For others we could consider new overload with explicit format provider parameter.

[scalablecory]

Thanks for doing research!

I'm borderline fine supporting Cisco's format given their ubiquity. @dotnet/ncl any strong opinions?

[wfurt]

We can add cisco when .Net runs on that gear @scalablecory . I think compat with Linux and OSX would be nice. Be able to parse logs or use values by given OS would be nice.

[scalablecory]

@wfurt maybe some day :)

Does OSX use one of the formats defined above?

[wfurt]

Yes it does @scalablecory

2p0: flags=8843 mtu 2304
ether 0e:85:90:d0:00:f4
media: autoselect
status: inactive

also the list of possible L2 types is very small. (unlike Linux)

[mvalenta]

@wfurt

We can add cisco when .Net runs on that gear @scalablecory . I think compat with Linux and OSX would be nice. Be able to parse logs or use values by given OS would be nice.

The pull request dotnet/corefx#41696 that I put in supports the 0011.2233.4455 Cisco format. If you think I should remove that support, please let me know.

Personal opinion, I would think that support for that format would be fine, even if .NET doesn't explicitly run on Cisco gear, as you might need to interact with some Cisco gear via .NET. I'm okay with not supporting it though

[scalablecory]

@mvalenta: please remove the Cisco format; it may be more appropriate in a separate "network admin" Nuget library. If the ask for it gets large enough later, we can reconsider.

[iSazonov]

My initial request come from PowerShell experience. PowerShell is for _management_. That includes scenarios parsing logs of different vendors. Taking in account that Cisco is dominate it would be very amazing ignore Cisco format. But my request is not about AI, automatic recognizing MAC formats. I'd expect that the API will implements IFormatProvider so that users get universal API. Usually users know incoming data format and can explicitly specify it.

[karelz]

@iSazonov it is not clear to me what you're proposing or even what you agree with or disagree. Can you please clarify?

[iSazonov]

Sorry, before I only made the report and don't think about implementation.

Looking current implementation I wonder about the design and that Core makes auto recognition. I see it bring some problems (with performance too).
I am not API designer and only can guess that we need something like:
```c#
enum MACFormat
{
Auto = 0, // I am not sure that this should be
Windows,
Linux,
Cisco, // Why not?
Custom = 255
}

public static PhysicalAddress Parse(string address, MACFormat format)

public static PhysicalAddress Parse(string address, IFormatProvider provider)

```

[wfurt]

I don't think we have to remove Cisco @mvalenta. It just feels we don't have to support every possible format routers do. It certainly feels it is not worth of new APIs