Discovering LAN resources through IPv6 multicast

It is pretty easy to know by heart IP addresses of useful hosts inside an IPv4 LAN network. But with IPv6, It is way more difficult to memorize these addresses.

Introduction

Your computer has just been connected to a LAN network and you want to know what are the IPv6 addresses of available resources: routers, hosts, etc.

The goal is to make some introspection in the easiest way possible into an existing network. Without the possibility of changing any configuration and without the possibility of capturing traffic.

On a IPv4 network, making that kind of introspection is simple, most LAN networks have a /24 bits prefix, so only 254 addresses to check. But with IPv6, most LAN networks have a /64 bits prefix, meaning there are 18446744073709551616 addresses to check, not so simple any more.

Context

This article was written while using the following softwares:

Linux Ubuntu 20.04.1 LTS
ping from iputils s20190709

Network introspection

The best way to make this introspection is to combine the ping tool with IPv6 multicast addresses. Querying these addresses with ICMPv6 will expose existing hosts.

The two most useful multicast addresses are the all-hosts address ff02::1 and the all-router address ff02::2. These address only have a link local scope and are not forwarded by routers. Other addresses exist for various purposes

Here is the description of a simple LAN used for the tests. It contains two computers and two routers.

The ICMPv6 request are all sent from the computer with the IPv6 address fe80::4. Let’s have a look of what it looks like.

Link-local addresses of every hosts

user@computer:~$ ping -c 2 -I eth0 -6 ff02::1
ping: Warning: source address might be selected on device other than: eth0
PING ff02::1(ff02::1) from :: eth0: 56 data bytes
64 bytes from fe80::1%eth0: icmp_seq=1 ttl=64 time=0.262 ms
64 bytes from fe80::2%eth0: icmp_seq=1 ttl=64 time=0.674 ms (DUP!)
64 bytes from fe80::3%eth0: icmp_seq=1 ttl=64 time=0.683 ms (DUP!)
64 bytes from fe80::1%eth0: icmp_seq=2 ttl=64 time=0.257 ms

--- ff02::1 ping statistics ---
2 packets transmitted, 2 received, +5 duplicates, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.257/0.792/1.979/0.536 ms
user@computer:~$

The DUP! message means the ping command receives multiple answer to the same echo request. This is a normal behaviour while querying a multicast address.

And the host fe80::1 answers two times because it is the faster to answer and also because of the -c 2 argument that trigger the sending of two echo requests.

Three hosts have answers the request: fe80::1, fe80::2, and fe80::3.

Global unicast addresses of every hosts

user@computer:~$ ping -c 2 -I 2001:db8::4 -6 ff02::1%eth0
PING ff02::1%eth0(ff02::1%eth0) from 2001:db8::4 : 56 data bytes
64 bytes from 2001:db8::4: icmp_seq=1 ttl=64 time=0.026 ms
64 bytes from 2001:db8::1: icmp_seq=1 ttl=64 time=0.316 ms (DUP!)
64 bytes from 2001:db8::2: icmp_seq=1 ttl=255 time=0.425 ms (DUP!)
64 bytes from 2001:db8::3: icmp_seq=1 ttl=64 time=0.887 ms (DUP!)
64 bytes from 2001:db8::4: icmp_seq=2 ttl=64 time=0.053 ms

--- ff02::1%eth0 ping statistics ---
2 packets transmitted, 2 received, +5 duplicates, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 0.026/0.637/1.861/0.596 ms
user@computer:~$

For an unknown reason, the local host also reply to this request. The result are the same as with link-local address, except this time, the hosts have answered with their global unicast addresses.

Link-local addresses of every routers

user@computer:~$ ping -c 2 -I eth0 -6 ff02::2
ping: Warning: source address might be selected on device other than: eth0
PING ff02::2(ff02::2) from :: eth0: 56 data bytes
64 bytes from fe80::1%eth0: icmp_seq=1 ttl=64 time=0.262 ms
64 bytes from fe80::2%eth0: icmp_seq=1 ttl=64 time=0.373 ms (DUP!)
64 bytes from fe80::1%eth0: icmp_seq=2 ttl=64 time=0.328 ms

--- ff02::2 ping statistics ---
2 packets transmitted, 2 received, +2 duplicates, 0% packet loss, time 1016ms
rtt min/avg/max/mdev = 0.262/0.336/0.381/0.047 ms
user@computer:~$

In this case, only the two routers have answered with their link local addresses: fe80::1, and fe80::2.

Global unicast addresses of every routers

user@computer:~$ ping -c 2 -I 2001:db8::4 -6 ff02::2%eth0
PING ff02::2%eth0(ff02::2%eth0) from 2001:db8::4 : 56 data bytes
64 bytes from 2001:db8::1: icmp_seq=1 ttl=64 time=0.312 ms
64 bytes from 2001:db8::2: icmp_seq=1 ttl=255 time=0.471 ms (DUP!)
64 bytes from 2001:db8::1: icmp_seq=2 ttl=64 time=0.229 ms

--- ff02::2%eth0 ping statistics ---
2 packets transmitted, 2 received, +1 duplicates, 0% packet loss, time 1027ms
rtt min/avg/max/mdev = 0.229/0.337/0.471/0.100 ms
user@computer:~$

Again, only the two routers have answered, but this time with their global unicast addresses.

A bit of traffic capturing

Here is what looks like the ICMPv6 request sent to the target multicast address ff02::1.

Frame 2: 118 bytes on wire (944 bits), 118 bytes captured (944 bits) on interface eth0, id 0
Ethernet II, Src: IANA_00:53:01 (00:00:5e:00:53:01), Dst: IPv6mcast_01 (33:33:00:00:00:01)
    Destination: IPv6mcast_01 (33:33:00:00:00:01)
    Source: IANA_00:53:01 (00:00:5e:00:53:01)
    Type: IPv6 (0x86dd)
Internet Protocol Version 6, Src: fe80::4, Dst: ff02::1
    0110 .... = Version: 6
    .... 0000 0000 .... .... .... .... .... = Traffic Class: 0x00 (DSCP: CS0, ECN: Not-ECT)
    .... .... .... 0100 1010 0001 1001 0111 = Flow Label: 0x4a197
    Payload Length: 64
    Next Header: ICMPv6 (58)
    Hop Limit: 1
    Source: fe80::4
    Destination: ff02::1
Internet Control Message Protocol v6
    Type: Echo (ping) request (128)
    Code: 0
    Checksum: 0x44fb [correct]
    [Checksum Status: Good]
    Identifier: 0x02cd
    Sequence: 1
    Data (56 bytes)

It is interesting to observe that a special MAC address destination is used. This is not a broadcast address but an Ethernet multicast address reserved for the use of IPv6 multicast traffic.
The address starts with 33:33: then the four lowest bytes of the IPv6 multicast address are appended to complete the MAC address. In the case of ff02::1, it produces 33:33:00:00:00:01. With the multicast address ff02::2, it would have resulted in 33:33:00:00:00:02.

These kind of MAC address allows to identify and pre process IPv6 multicast traffic directly at the link-layer level.

Neighbor Discovery Protocol

While sending ICMPv6 echo request, even if the MAC address of remote hosts are retrieved. The Neighbor Discovery Protocol is not triggered, and the remote addresses received are not added into the NDP table.

Discovering LAN resources through IPv4 multicast

The exact same mechanism exists within IPv4. The all-hosts multicast address is 224.0.0.1 and the all-routers multicast address is 224.0.0.2.

Making such ICMPv4 echo request just does not work. On Linux, these requests are considered as unwanted broadcast and are ignored by default at reception. It seems it has been deactivated for security purpose. It is pretty strange because the IPv4 destination address and the MAC destination address (01:00:5e:00:00:01) are not broadcast addresses.

The only way to enable the multicast behaviour on IPv4 hosts is to set the kernel parameter net.ipv4.icmp_echo_ignore_broadcasts to 0.

user@computer:~$ sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=0
net.ipv4.icmp_echo_ignore_broadcasts = 0
user@computer:~$

But it also make the host answering to unwanted broadcast traffic, and open security considerations, so not really a good idea…

Conclusion

Thanks to the ping tool, multicast addresses and a bit of output cleaning, it is pretty easy to discover other hosts and their roles on a LAN network!
Just hoping that security issues won’t arise and cause these addresses to be filtered.