As per this article (https://en.wikipedia.org/wiki/IPv6_address#Link-local_addresses_and_zone_indices) the syntax of specifying IPv6 zone indices and link-local addresses depends on the platform.
On MS Windows the index is determined by the interface number while on Unix-like OS's (including OS X) the interface name (ie. en0) is used.
System.Net.IPAddress only has support for specifying the interface the MS Windows way in the form of it's "ScopeId" property which is a "long". So this causes issues on non-Windows systems and in some cases, specifically where the MS Windows notation is not supported as an alternate way of specifying the interface it renders this class completely useless.
Even worse, IPAddress.Parse succeeds in parsing an IP Address with a zone index specified as name (ie. %en0") but totally ignores/scraps the zone index resulting in a false positive.
At least on OS X (can't speak for other Unix or BSD based platforms) one can alternatively specify the zone index using the index of the interface. This is not well known or widely used though and requires finding an interface's index instead of just using it's name.
So on platforms where the number-based notation is available but not the default, IPAddress.Parse could be extended to look up the interface index using the System.Net.NetworkInformation.NetworkInterface class. On systems where this "fallback" isn't available this wouldn't work though and apart from introducing a new property and adjusting the parsing code I have no suggestion for this scenario.
We are limited by .net framework compatibility here. The only sensible solution I can think of is to report the issue to CoreFX as they will have same problem but have more power to alter .NET API
Alright, just posted in the CoreFX issue tracker: https://github.com/dotnet/corefx/issues/8509
Turns out this is already fixed/supported in CoreFx (https://github.com/dotnet/corefx/issues/8509). Any news about mono adopting the parsing code?