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

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 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.