Leaking information by using IPv6

As I wrote before, I’m experimenting with IPv6. I have a tunnel to my ISP from my router. The router is running Linux and uses radvd to advertise my IPv6 prefix to my networks. My dmz, in which this blog is hosted, get the 2001:888:13c5:cafe::/64 prefix. The IPaddresses are then created by taking the MACaddress of a network interface and placing that behind the prefix. It’s a nice and simple autoconfiguration system. So the IPv6 address of the blog is 2001:888:13c5:cafe:20c:29ff:fe13:2b42.

What I didn’t realize when I set this up like this, is that the MACaddress is visible and possibly giving valuable information to an attacker. See for example the output of the following command:

# ipv6calc 2001:888:13c5:cafe:20c:29ff:fe13:2b42 –showinfo No input type specified, try autodetection…found type: ipv6addr No output type specified, try autodetection…found type: ipv6addr Address type: unicast, global-unicast, productive Address type has SLA: cafe Registry for address: RIPE NCC Interface identifier: 020c:29ff:fe13:2b42 EUI-48/MAC address: 00:0c:29:13:2b:42 MAC is a global unique one MAC is an unicast one OUI is: VMware, Inc.

The last line said it: I’m running the blog on VMware. This might be interesting info for an attacker, which otherwise would not have been available, or at least not this easy.

To prevent this you can just setup a manual IPaddress, which is wiser from a maintainability point of view anyway, since you don’t want to update your DNS records everytime the server gets a new NIC. But still, it shows that IPv6 has it’s own gotchas and peculiarities in the security area.