Hurricane Electric's IPv6 Tunnel Broker Forums

Advanced search  

News:

Welcome to Hurricane Electric's Tunnelbroker.net forums!

Author Topic: radvd & privacy?  (Read 8122 times)

hve

  • Newbie
  • *
  • Posts: 5
radvd & privacy?
« on: February 16, 2011, 04:04:37 AM »


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?
Logged

cholzhauer

  • Hero Member
  • *****
  • Posts: 2736
Re: radvd & privacy?
« Reply #1 on: February 16, 2011, 05:07:46 AM »

If you wanted to avoid disclosing the mac address, you'd need to switch to DHCPv6
Logged

hve

  • Newbie
  • *
  • Posts: 5
Re: radvd & privacy?
« Reply #2 on: February 16, 2011, 06:00:35 AM »

Yep.

It seems that auto configuration is mainly managed by the client itself.

I will try a dhcpv6 setup.

Thanks for your response.
Logged

cholzhauer

  • Hero Member
  • *****
  • Posts: 2736
Re: radvd & privacy?
« Reply #3 on: February 16, 2011, 06:11:57 AM »

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
Logged

hve

  • Newbie
  • *
  • Posts: 5
Re: radvd & privacy?
« Reply #4 on: February 16, 2011, 07:42:12 AM »

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.

           systctl net.ipv6.conf.all.use_tempaddr=2

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.

Thanks again
Logged

jgeorge

  • Newbie
  • *
  • Posts: 38
Re: radvd & privacy?
« Reply #5 on: February 16, 2011, 09:32:33 AM »

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:

(aa&0x02)bb:ccFF:FEdd:eeff

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.

Cheers,

Joe
Logged

packetmail

  • Newbie
  • *
  • Posts: 15
Re: radvd & privacy?
« Reply #6 on: February 16, 2011, 09:39:57 AM »

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)

Code: [Select]
#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.
Logged

cholzhauer

  • Hero Member
  • *****
  • Posts: 2736
Re: radvd & privacy?
« Reply #7 on: February 16, 2011, 09:47:23 AM »

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.
Logged

antillie

  • Full Member
  • ***
  • Posts: 104
Re: radvd & privacy?
« Reply #8 on: February 17, 2011, 12:24:33 AM »

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.
Logged

Ninho

  • Full Member
  • ***
  • Posts: 138
Re: radvd & privacy?
« Reply #9 on: February 17, 2011, 03:47:29 AM »

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" ?

Logged

hve

  • Newbie
  • *
  • Posts: 5
Re: radvd & privacy?
« Reply #10 on: February 17, 2011, 04:20:36 AM »

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 it touches on the proposed privacy extensions in Linux.

Code: [Select]
We identify issues in current IPv6 privacy extensions and
propose improvements that signi cantly enhance both the
exibility and functionality, to protect a client from being
tracked as it moves between di erent IPv6 networks. This
is achieved by generating a new interface identi er 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.

Regards
hve

« Last Edit: February 17, 2011, 04:26:00 AM by hve »
Logged

hve

  • Newbie
  • *
  • Posts: 5
Re: radvd & privacy?
« Reply #11 on: February 17, 2011, 04:37:00 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.

Regards,
hve
Logged

bombcar

  • Jr. Member
  • **
  • Posts: 55
Re: radvd & privacy?
« Reply #12 on: February 17, 2011, 06:18:58 PM »

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.
Logged

jimb

  • Hero Member
  • *****
  • Posts: 805
  • ^^^ Warped picture
Re: radvd & privacy?
« Reply #13 on: February 17, 2011, 09:27:05 PM »

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.
Logged