In the world of IPv4, every network operator and security person know how to identify the host which sends 'bad' IPv4 traffic. In this blog entry, bad means launching an attack or sending malovent traffic, or violating Acceptable Use Policy or being misconfigured.
If the IPv4 address is alive (this is currently present on the network and sending traffic), then it is easy: simply browse the Address Resolution Protocol (ARP) cache of the last router towards the IP address to find the Medium Access Control (MAC) address bound to the IPv4 address then browse the Content Addressable Memory (CAM) of the switch(es) to find on which port is this MAC address: and that's it, you know where the offending IPv4 address is.
If the IPv4 address is not alive (it was active 3 days ago when the 'bad' event occurred but it is no more present or the host has changed its IP address), then it is more complex but doable. The key source of information is the Dynamic Host Configuration Protocol (DHCP) log file (or lease file) which lists which IPv4 address was leased to which MAC address based on time. Finding the DHCP leased IPv4 address at the ‘bad event’ time means that we now have to look for a MAC address. If the MAC address is connected in your network, then browsing through the same DHCP log file for the current time will give the current IPv4 address of the bad host. Else (MAC address not connected) if the host was connected by WiFi, then by looking in the RADIUS log, the operator can find the RADIUS username to identify the owner of the bad host.
Of course, there are variations of the above procedures, but, the key point is how can this map to an IPv6 world? Because there are a couple of changes in IPv6:
All the above changes make the chase more complex in the IPv6 world in some cases... Let’s start with the easiest.
Chasing a live IPv6 address in the IPv6 world is similar to the IPv4 world: find the nearest router, browser the IPv6 NDP cache (rather than the IPv4 ARP cache) to find the MAC address of the ‘bad’ IPv6 host, then look in all switches for the specific MAC address.
If the IPv6 address is no more active in the network, this becomes more complex in IPv6 even in the case where all routers send Router Advertisement (RA) messages with the M-flag which forces all DHCPv6-able hosts to use DHCPv6 and not stateless auto-configuration. Indeed, the DHCPv6 log does not contain the MAC address anymore for a specific IPv6 address but rather the DHCP Unique Identifier (DUID) which is unique per DHCPv6 host but is not always a MAC address; it can also be any number. The choice of DUID is done by the client, so, we can only hope that the majority of the DHCPv6 clients will use the MAC address as their DUID!
If the host relies on stateless auto-configuration (DHCPv6 not enabled or not implemented), there are basically two cases: the easiest is when the host uses a single permanent EUI-64 IPv6 address and the most difficult is when the host has privacy extension (known as temporary addresses under Windows).
EUI-64 addresses are easily recognizable because the address has a ‘ff:fe’ in the interface identifier part of the address. It is then trivial to extract the MAC address from the EUI-64 IPv6 address, and then to chase the MAC address in the network like in the IPv4 world.
The worst case is indeed when the IPv6 address is based on privacy extension (the least significant 64 bits are actually a random number) and when the IPv6 is no more in the network (so browsing all NDP cache is useless)... There is no way to find the bad host in this case. You may be lucky if a web server log has logged the IPv6 address with an associated user name, you may be lucky if an ACL with the ‘log-input’ keyword logged the IPv6 address with the MAC address, you may be lucky if an IPS logged MAC & IPv6 address, ... else you are out of luck!
In short, all enterprises should run a DHCPv6 server and use the M-flag on the RA messages. The AUP should also indicate that privacy extension should not be used; this is vastly a Windows issue as most Linux and Mac OS do not use privacy extension by default. Microsoft has a setting to prevent the use of privacy extension, this setting can also be deployed with a Active Directory (AD) to all hosts member of the AD domain. The commands are:
netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent
netsh interface ipv6 set privacy state=disabled store=persistent
Happy chasing of the ‘bad’ IPv6 address (if any) in your network.