Bug 37724 - System.Net.IPAddress and IPv6 zone indices
Summary: System.Net.IPAddress and IPv6 zone indices
Status: NEW
Alias: None
Product: Class Libraries
Classification: Mono
Component: System (show other bugs)
Version: 4.2.0 (C6)
Hardware: Macintosh Mac OS
: --- enhancement
Target Milestone: Untriaged
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2016-01-15 14:08 UTC by Felix Deimel
Modified: 2016-07-31 16:31 UTC (History)
4 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and 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 Links.

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 original description:

  • Export the original title and description: GitHub Markdown or Developer Community HTML
  • Copy the title and description into the new report. Adjust them to be up-to-date if needed.
  • Add your new information.

In special cases on GitHub you might also want the comments: GitHub Markdown with public comments

Related Links:
Status:
NEW

Description Felix Deimel 2016-01-15 14:08:41 UTC
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.
Comment 1 Marek Safar 2016-05-13 11:05:16 UTC
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
Comment 2 Felix Deimel 2016-05-13 18:14:04 UTC
Alright, just posted in the CoreFX issue tracker: https://github.com/dotnet/corefx/issues/8509
Comment 3 Felix Deimel 2016-05-18 20:59:10 UTC
Turns out this is already fixed/supported in CoreFx (https://github.com/dotnet/corefx/issues/8509). Any news about mono adopting the parsing code?