Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report for Bug 37724 on
GitHub or Developer Community if you have new
information to add and do not yet see a matching new report.
If the latest results still closely match this report, you can use the
In special cases on GitHub you might also want the comments:
GitHub Markdown with public comments
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?