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
Depends on:
Reported: 2016-01-15 14:08 UTC by Felix Deimel
Modified: 2016-07-31 16:31 UTC (History)
4 users (show)

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


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?

Note You need to log in before you can comment on or make changes to this bug.