So I have setup radvd and everything works as a breeze.
The only thing is that every client gets its mac address published in the IP.
So I was wondering is it possible to modify radvd so that each client gets a radom IP?
i.e. can radvd impose the IP on the client?
If you wanted to avoid disclosing the mac address, you'd need to switch to DHCPv6
It seems that auto configuration is mainly managed by the client itself.
I will try a dhcpv6 setup.
Thanks for your response.
Yep..that's the way RA works...you use the 48-bit MAC address to create a unique IPv6 address. Like you mentioned, configuration is a breeze, but if you don't want people being able to determine your MAC address, you'd better move to DHCP.
On the other hand though, you should be careful with DHCP. I've heard some security experts talk on the fact that you want to avoid continuous or easily guessable addressing schemes.
For example, avoid 2001:db8:1234:4567::1, 2001:db8:1234:4567::2, 2001:db8:1234:4567::3, 2001:db8:1234:4567::4 ect
and use 2001:db8:1234:4567:fge0:4512:ba85:94c2, 2001:db8:1234:4567:fge0:4512:ba85:94ce, 2001:db8:1234:4567:fge0:4512:ba85:94bc, ect
Good point choose not easily guessable number pools.
I have just experimented a bit with enabling IPv6 privacy extensions (RFC 3041) in the linux kernel of a client.
Now with autoconfiguration an interface with MAC <aa>.<bb>.<cc>.<dd>.<ee>.<ff> gets translated in:
:: 0x02 <bb> : <cc> 0xff : 0xfe <dd> : <ee> <ff>
That seems very predictable... It seems that Microsoft did a better job here... ;)
The drawback of dhcpv6 is that my clueless Mac OS-X users will probably have to install a DHCP client. I was hoping to avoid this.
That's how autoconfig boosts your 48 bit MAC to a 64 bit address.
One thing to bear in mind though is that the translation of aa:bb:cc:dd:ee:ff is actually:
The 0x02 sets bit 7 in the address to '1' to indicate it's a universal autoconfigured address (at least that's the way i understand it, see also http://en.wikipedia.org/wiki/IPv6_address#Stateless_address_autoconfiguration .
Since the first byte of a lot of MAC addresses are 0x00, it's easy to assume that it just translates to 0x02, but it actually does take into account the first byte. I have a couple of things on my network with really off the wall first bytes.
As others have indicated SLAAC will auto-configure the host section of the IPv6 address based on the client MAC. Alternatively, you can use SLAAC (radvd) with RFC 3041/4941 (http://tools.ietf.org/html/rfc3041) privacy extensions enabled that will do exactly what you want.
This is on by default with Microsoft Windows and on GNU/Linux this can be set by adjusting the follow sysctl values (usually /etc/sysctrl.conf)
#Enable IPv6 Privacy Extension (interface section randomization of IPv6 address)
net.ipv6.conf.all.use_tempaddr = 2
net.ipv6.conf.default.use_tempaddr = 2
Since this is a client-side setting there's no way to do this with radvd. I do not agree that DHCPv6 is your only solution.
Depends on your environment.
In a corporate environment, I'd argue that privacy extensions aren't really an option because they are not inserted into DNS, thus making host lookups impossible.
The idea of publishing my MAC address in my IPv6 address doesn't really bother me. I like the idea of having a static public IPv6 address on my PC. Trying to "hide" behind a random address is a bit silly, that's what firewalls are for.
Fully agreed, what's all that paranoïa about disclosing MAC addresses ? Sure, there are cases when someone might have valid reasons to hide the MAC address associated with some device (not their MAC however, people don't have MAC yet! at least I don't... ) - but the general case should be : do not care!
I think also it should be stressed more often that MAC address considered unique is a myth. Even though they should be unique per the spec, real world MAC numbers more often than not are kept in some kind of EE-PROM or even in RAM (made up on the fly) and changeable at will by a (half savvy) user.
Isn't that what you call a "red herring" ?
Well of course everyone is entitled to his opinion.
So if you re not bothered about privacy this discussion might not be for you.
I for one don't want to expose my clients. Masquerading behind a firewall seems a little to defeat the principle of IPv6.
For the others take a look at the paper in http://www.ccsl.carleton.ca/~dbarrera/files/TR-10-17.pdf (http://www.ccsl.carleton.ca/~dbarrera/files/TR-10-17.pdf) it touches on the proposed privacy extensions in Linux.
We identify issues in current IPv6 privacy extensions and
propose improvements that signicantly enhance both the
exibility and functionality, to protect a client from being
tracked as it moves between dierent IPv6 networks. This
is achieved by generating a new interface identier for each
visited network. We discuss a preliminary Linux implemen-
tation of the proposal.
So for now a randomized DHCP pool seems with infinite lifetime seems the solution. Of course if clients want to publish their IP either in DNS or otherwise that's entirely their choice. I am a little old fashioned in that respect I don't want to help the datamining companies upfront.
Quote from: packetmail on February 16, 2011, 09:39:57 AM
Alternatively, you can use SLAAC (radvd) with RFC 3041/4941 (http://tools.ietf.org/html/rfc3041) privacy extensions enabled that will do exactly what you want.
This is exactly what I tried on linux but still I get a very predictable link extension:
0x02 <bb> : <cc> 0xff : 0xfe <dd> : <ee> <ff>
Still this does not solve the MAC OS-X issue. MAC OS-X will happily serve a EUI-64 extension out-of-the-box.
Remember that privacy doesn't matter much as you can't easily change the first 64 bits of the address, which is good enough to identify you usually.
Also remember that a machine can have multiple simultaneous valid IPv6 addresses, so it can have the MAC based one for incoming connections and the private one(s) for outgoing.
Yep. Using privacy extensions, etc, IPv6 can be made to be just as private as NATed IPv4. Which is not exactly private, since they see your public IPv4 address.