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.