Monitoring MAC-IPv6 Address Bindings

In the legacy IPv4 world, the DHCP server allocates IPv4 addresses and thereby stores the MAC addresses of the clients. In the IPv6 world, if SLAAC (autoconfiguration) is used, no network or security device per se stores the binding between the MAC (layer 2) and the IPv6 (layer 3) addresses from the clients. That is, a subsequent analysis of network behaviour corresponding to concrete IPv6 addresses and their client machines is not possible anymore. The mapping of “identity to IP” is not done automatically somewhere.

A simple way to overcome this issue is to install a service that captures Duplicate Address Detection (DAD) messages from all clients on the subnet in order to store the bindings of MAC and IPv6 addresses. This can be done with a small Tcpdump script on a dedicated Ethernet interface of a Linux host.

In this blog post I will present a use case for storing these bindings, the concept of the DAD messages, a Tcpdump script for doing this job, and the disadvantages and alternatives of this method.

Note that this post is one of many related to IPv6. Click here for a structured list.

My Use Case

A customer wanted to test IPv6 in order to achieve knowledge for the IT admins. We decided to activate IPv6 on the guest/BYOD Wifi. In this way, many users and clients will operate with IPv6 without touching the productive LAN. One of the first questions in this scenario was: How can we know which device had which IPv6 address at a given time? How can we trace back which device (user) has done some malicious actions when we only see many different “privacy extended” IPv6 addresses in the firewall log without any MAC addresses?

Since we had no layer 2 switches that support first-hop security services such as neighbor discovery monitor or router advertisement guard, the idea was to use a host on the local network to sniff and “search” for new IPv6 addresses and their correspondent MAC addresses.

Duplicate Address Detection

Every IPv6 node on the network that wants to register a new IPv6 address must run the duplicate address detection (DAD) method in order to find out whether this IPv6 address is already used by another IPv6 node: “Duplicate Address Detection MUST be performed on all unicast addresses prior to assigning them to an interface, regardless of whether they are obtained through stateless autoconfiguration, DHCPv6, or manual configuration, […]”, RFC 4862, Section 5.4. This ICMPv6 neighbor solicitation message is sent to the solicited-node multicast address of the target address. (Remember: There are no broadcasts anymore with IPv6.) However, since common layer 2 switches do not maintain multicast listener groups, they simply forward these messages to all switchports. That is: Our sniffing Linux host will receive all DAD messages that appear on the local network.

Duplicate Address Detection

Here is a Wireshark screenshot of a DAD message. The Ethernet frame is sent to an IPv6 multicast address (beginning with 33:33:) with a source MAC address of the IPv6 node, in this case an Apple device. The message has ICMPv6 type 135 and a “Target Address” of its tentative link-local IPv6 address (fe80::…):

DAD message in Wireshark

The Tcpdump line for the same DAD message looks like that:

Tcpdump Script and Analysis

I am dividing my method in two sections: At first, a Tcpdump runs in the background in order to store all DAD messages in a *.pcap file. For the subsequent analysis, the stored *.pcap file is read into a textfile which can then be analysed using grep, etc.

For the capturing of IPv6 packets I recommend to use a second hardware interface on the Linux host which does not participate at layer 3 at all, i.e., has no IPv6 addresses: sudo sysctl -w net.ipv6.conf.eth1.disable_ipv6=1 . That is: It is only used for the passive sniffing on the network.

Creation of the Pcap File

The DAD messages can entirely be classified since they are “Neighbor Solicitation” ICMPv6 messages of type 135 (RFC 4861) and are always sent from a source address of “::” (RFC 4862). That is, the following Tcpdump filter captures only DAD messages: ip6[40]=135 and src host :: .

I am storing the logfiles in a subfolder under /var/log: sudo mkdir /var/log/dad . The complete Tcpdump command which uses the second interface card on the host and creates a new *.pcap every day looks like that:

Grep an IPv6 Address

Since new pcap files are created after 24 hours, the program “mergecap” can be used to concatenate them to a single file. This gives a wider range for the searching of addresses. The following command merges all pcap files from the /var/log/dad/ folder into a single file:

In the next step, tcpdump is used to read out the file and to write it into a textfile. I am using it with three more options:

  • “-e” to print the link-level header on each dump line. This reveals the MAC addresses.
  • “-n” to not convert addresses (i.e., host addresses, port numbers, etc.) to names. This omits the “(oui Unknown)” strings.
  • “-tttt” to print the date (and not only the time) for each packet.

This is my example in which the “dad_2014-01-all.txt” file is created:

Here is a sample output of this textfile. Among others it shows the date and time, the source MAC address, and the target IPv6 address.

 

Now, its fairly easy to find an IPv6 address. Simply use grep such as:

This output shows the MAC address of the client and the times it sent out a DAD message, which happened a few times during the 06. and the 09. of January.

–> At this point, the mere ideas of monitoring MAC-IPv6 address bindings are complete. However, with some basic Linux tools the gathered information can be presented a bit better:

Table with Time, MAC & IPv6 Addresses

To only show the date & time, the MAC and the IPv6 address, “sed” with a few regular expressions ( sed s/regexp/replacement/ ) can be used to eliminate all other pieces of code:

This gives a kind of table which shows all MAC addresses on the network that requested an IPv6 address.

For a better structure of this table, “sort” and “uniq” can be used to sort the table based on the MAC addresses and to omit doubled entries. That is, the following table shows for each MAC address all requested IPv6 addresses, sorted by MAC address and by time:

 

Grep a MAC Address

Of course, a MAC address can be grepped in the logfile to show its corresponding IPv6 addresses, too. If it is used in conjunction with the above mentioned sed, sort, and uniq pipes, a sample output looks like that:

Disadvantages & Alternatives

The way of using Tcpdump as a network sniffer is more a proof-of-concept than a real solution for enterprises. It might fit for a guest Wifi but not for productive environments.

Disadvantages of this Method

  • Only on a single local network: Since the DAD messages are sent inside a layer 2 infrastructure (and not routed somewhere else), the Tcpdump sniffer receives only messages from the directly connected network. That is: It does not scale at all! It would require a sniffer in every subnet to completely cover the whole network.
  • Not against “real” attackers: This method only fits for normal users that might unintentionally do some malicious actions. It will not work for the capturing of MAC addresses from hackers who could omit the DAD message or simply change their hardware MAC address at all.
  • If DAD fails for the IPv6 node: Consider the really rare situation in which an IPv6 node wants to register an IPv6 address that is already used. This is no problem for the node since it generates another one. However, in the DAD logs, the DAD message for this (already used) IPv6 address appears with the MAC address of the new IPv6 node. On a subsequent analysis of the DAD logs, this IPv6 address could misleadingly point to the MAC address that did not get this address.

Alternatives

  • Switch, Switch, and again: Switch: It should be clear that countermeasures for layer 2 attacks or layer 2 monitoring at all should be deployed on the layer 2 infrastructure as well. A passively sniffing host (such as used in this PoC) will not see everything on the network but mostly “broadcast” messages. That is, the concept of first hop security in the switches is the answer for these situations. (Cisco paper here.) The switch is able to see every neighbor discovery messages from all clients directly on its switchports. Technologies such as IPv6 guard in general, RA guard, DHCPv6 snooping, NDP monitor, etc. should be used to monitor and thwart these types of threats.
  • NDPMon: The free Neighbor Discovery Protocol Monitor is a complete monitor package which can be used to find anomalies in different ICMPv6 messages such as router- and neighbor advertisements, etc. But since it runs on a host in the network (and not directly on a switch), its usefulness might be decreased, too. However, for obvious attacks and the monitoring of MAC-IPv6 address bindings, it completely fits. The following screenshot shows the neighbor table of NDPMon which I tested in my lab. This gives a nice overview of the IPv6 addresses used by different clients, even with timestamps and aggregated by MAC address:
    NDPMon Neighbors partial table
  • SLAACer: Daemon that receives IPv6 traffic from many switch mirroring SPAN ports and generates syslog/SQL messages based on Neighbor Advertisements. In the best case, it is configured to receive *any* NA messages and therefore has a *complete* view of the MAC-IPv6 address bindings on the network. Here is the project homepage.
  • ipv6mon: The SI6 Networks’ Address Monitoring Daemon listens for DAD messages, too, but also sends multicast probes to further find nodes on the net.
  • Querying the Routers Neighbor Cache: Another option is to query the routers neighbor cache since it stores all IPv6 neighbors that made connections through it. This requires certain ressources on the router. The disadvantage is, that the router doesn’t store IPv6 neighbors for connections that were established inside the local subnet.
  • DHCPv6 Server: Of course, it is not mandatory to use SLAAC at all. A stateful DHCPv6 server could be used to allocate IPv6 addresses which is then in the position to store all requesting MAC addresses. However, this would not limit the procedure of hackers that could still use static IPv6 addresses.

Conclusion

With this post, I showed the basic functionality of the duplicate address detection messages and how they can be stored to maintain a list of MAC-to-IPv6 address bindings on a layer 2 network. This solution fits for small IPv6 networks (and might train the understanding of IPv6 at all), but is not meant to be used in security-relevant enterprise environments. Dedicated intrusion detection/prevention systems (IDS/IPS) and security information and event management (SIEM) systems should be used to monitor critical networks.

More information about this idea can be found at the following two blogposts: Reliability of IPv6 DAD Message Sniffing and IPv6 Address Statistics based on DAD Messages.

Links for Further Reading

Here are a few links for further reading. Since my references for this article are always inline, I am only listing further links here:

Featured image “Skywatcher ED80” by Juraj Patekar is licensed under CC BY-NC-ND 2.0.

2 thoughts on “Monitoring MAC-IPv6 Address Bindings

Leave a Reply

Your email address will not be published. Required fields are marked *