c# - Is IP address on the same subnet as the local machine (with IPv6 support)

Question

Does anyone have some code that will determine if an IP address (IPv4 or IPv6) is on the same subnet as the machine running the application? I've seen numerous examples of code that does this with IPv4 but I can't find any that support IPv6.

EDIT:

I'm unsure if I'm understanding all the differences between v4 and v6 so here's a bit more to my question. I have an application that serves both internet clients and intranet clients, that is to say there are clients that are on the same physical network as the server. So sometimes there are routers between the client and sometimes there aren't. With IPv4 I can determine this by checking the client IP address against the server IP address and the subnet so if my server's IP and subnet mask are respectively:

192.168.123.15 255.255.255.0

And the server receives a client request from 192.168.123.100 I know that there is no router standing between the client and server. However, if the server receives a client request from 192.168.1.100 or perhaps 67.7.23.4 I know that there is a router standing between those clients and the server. In .Net I can gather the client and server IP addresses (both v4 and v6) but I cannot find the IPv6 subnet mask.

Is there a way to gather this info in .Net or is there some difference between IPv4 and IPv6 that I'm misunderstanding?

EDIT x2:

I posted this on the MS connect site to see if it's something they're working on or if there's a reason they haven't added an IPv6Mask property to the UnicastIPAddressInformation class.

https://connect.microsoft.com/VisualStudio/feedback/details/643031/unicastipaddressinformation-class-has-no-ipv6mask-property

I also posted the same question on the MSDN forums around the same time. 1800+ views and not a single reply. Guess I'm not the only one who's curious about this.

http://social.msdn.microsoft.com/Forums/en-US/netfxnetcom/thread/dd30e161-9be5-4d70-97c0-22e2756ce953

Answer 1

It doesn't look like the framework has a way to do this. The most accurate way would be to do a route lookup, but I don't see a good way to do that in C#. (Under Linux, I'd do /sbin/ip -6 route get <ipv6-addr> and see which route gets returned.) You'd have to find a native call to do this in Windows; I don't see a command line application.

The best way might be to parse the output of netsh interface ipv6 show route verbose. You could look for any non-/128 prefixes and do a longest prefix match on those. (well, if you hit a /128, that's an address assigned to the box)

You could also check the neighbor table. (netsh interface ipv6 show neighbors), but that might not contain the entry you're looking for if you haven't talked to that host recently.

Other potential issues you'll need to consider:

• Link-local addresses (fe80::/10) (and multicast, loopback, and unspecified - everything in the table)
• The fact that in IPv6, an assigned address does not imply an on-link prefix. The prefix table is separate. It's not clear how to test for this under Windows, but netsh interface ipv6 show siteprefixes might help. It looks like Windows might actually treat this more like IPv4 than the standard expects.

Edit: It sounds like checking the neighbor table will be the path of least resistance for you to do this; if you're accepting a connection from the intranet and then turning around and checking the neighbor table, you can be reasonably assured that if the neighbor is local, it will exist in the table. If you check the neighbor table, BE CAREFUL to only look at the neighbor table for LAN interfaces. (The ISATAP interface, installed by default on many Windows system, exposes the entire IPv4 internet as a link-local "subnet".)

Again, IPv6 addresses have no concept of a "netmask", since the on-link prefix table is separate from address assignment. However, if you have a server sitting somewhere you can be probably 99% certain that it is on a /64. (though you'd have to be careful; if it itself was a tunnel endpoint, sometimes I've seen longer prefixes assigned for 6in4 tunnels) So a quick and dirty algorithm would be:

• Ignore all addresses where the first 64 bits are 0 (local loopback)
• Ignore all addresses matching ff00::/8 (multicast)
• If the address matches fe80::/10, it is interface local. Be careful with this, because if you have an ISATAP interface enabled, "link-local" means "automatic tunnel to the entire IPv4 internet"! (not good.) So it might be best to not trust link-local addresses unless you are certain they are coming from a LAN interface. (they can't be routed)
• (Now the complicated part) Determine if the address is a neighbor. (neighbor lookup) The hack-and-slash solution is to check all the IPv6 addresses configured on the system (autoconfigured via stateless address autoconfiguration, DHCPv6, or static, if you can determine it) and check the first 64 bits. On a server (assuming no funky tunnels are configured with non-/64 prefixes) this will be a bug in rare cases, since - again - you can't be sure if the address is really on-link unless you check the on-link prefix table. (which Windows doesn't have a concept of; it seems to be stored in the route table.) Most network devices that can be configured to send out router advertisements on an Ethernet interface will always advertise a /64 prefix. If you can check that the packet came in on a LAN interface, it will be even less likely that this will be a bug.

Edit 2

I have written some code to parse the IPv6 route table and posted it here. It doesn't solve the hard problems posed in this question yet, but it's a step in the right direction.