“Fun” with RFC4620 Section 6.4 and discovering IPv4 information over IPv6

As part of a request at work to figure out IPv4 addresses of devices on a network where broadcast pings don’t work, and no administrative access to the switches/routers, I took a look at solving this with IPv6. We know that you can ping6 the all-nodes multicast address, and get DUP! replies from IPv6 enabled hosts on that LAN segment. These will typically be link-local addresses, from which you can determine a MAC address. How to resolve that MAC address on a client host and not the router/switch, I was thinking reverse ARP or something, but support for that wasn’t present in my Ubuntu 13.10 kernel on the main machine I was working with. I started looking around for other options using IPv6 and found RFC4620, Section 6.4.

The gist of it is that you send an ICMPv6 Type 139 packet to an IPv6 address, asking if it has any IPv4 addresses configured either on that interface the target address is on, or any interfaces on the machine itself. And this is why this is disabled by default on hosts, and *IF* you insist on filtering ICMP6 Types, definitely make certain this is one of them. It works if you can enable it. I found a Git repo of ninfod, a userspace compiled binary, that needs to run as root for raw socket access. Compiled, ran with the flag to allow replies to Globally reachable hosts (I was testing between 2 remote sites, as my older VMs and their ping6 command didn’t support the -N flag), and gave it a test:

$ ping6 -N ipv4-all ipvsix.me
PING ipvsix.me(ipvsix.me) 56 data bytes
40 bytes from ipvsix.me:,,; ttl=63
40 bytes from ipvsix.me:,,; ttl=63
--- ipvsix.me ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms

So while this works as intended, it makes absolute sense why it needs to be disabled by default, and even potentially filtered out completely. But at least it was fun to play with IPv6 to determine IPv4 information of remote hosts.