[LINK] smartphone privacy problems

Scott Howard scott at doc.net.au
Sun Jan 30 13:42:27 AEDT 2011


On Sat, Jan 29, 2011 at 3:46 PM, Paul Brooks <pbrooks-link at layer10.com.au>wrote:

> Yes, RFC4941 Privacy Extensions for Stateless Addess Autoconficuration in
> IPv6 does
> document an alternative method of generating an interface ID, and an IPv6
> address,
> which changes over time.
>
> Note it shouldn't be the 'factory-set' option in Windows, or any other OS,
> since use
> of these extensions can break some activities. RFC4941 specifies that, if
> implemented,
> the OS must provide a way to turn the extensions off and on - unfortunately
> it doesn't
> specify what the default should be, usually such documents specify the
> default should
> be OFF, so the extended behaviour can be enabled under the control of
> someone who
> should know the implications of doing so.
>

It does state a default, which is that it "SHOULD" (in RFC terms) be
disabled by default.

That said, in the case of Windows, I think MS has got it right by turning it
on by default.  Although it's possible that RFC4941 can "break some
activities", it's fairly easy to argue that those "activities" were broken -
or at least flawed - in the first place, and that given a good
implementation of RFC4941 having it turned on (with the ability to turn it
off) is a good default.


Downsides, noted in the RFC, are that some applications may break, and
> debugging of
> problems may become more complicated. It also notes that the extensions are
> useless
> unless the device is operated inside a network which has many other devices
> - the
> extensions won't be much use in your house, for example, since your house
> will be
> allocated a network prefix, and all the autogenerated addresses will have
> the same
> network prefix, so the network prefix portion will still be enough to
> identify your
> transactions.
>

No, that's not at all the problem.

The real privacy issue with using standard auto-configured IPv6 addresses is
that part of your address - in effect a static identifier - moves around
with you with between networks.  If you are connecting to a host via your
wireless network at home, and then go to a coffee shop and connect to the
same host, then that host will know, with a fairly high degree of certainty,
that you're on the same computer - even though you'll been on a completely
different network.

How home networks may or may not work with IPv6 is still up in the air, but
it seems very likely that many ISP will NOT allocated static IPv6 ranges to
individual customers, so even for systems that never move off a single
network this can still come into play.



> One of the promises of IPv6 is that every device can have an IPv6 address
> which is
> static - with no requirement to change over time, so that it can be
> advertised and
> used by other devices to establish inbound connections to - including while
> mobile.
>

That was never one of the promises of IPv6, and even if it was it is
something that would never work on a widespread scale in the real world.
What you're describing is an extension to IPv6 known as Mobile IPv6, which
exists somewhat equally for IPv4 (eg, RFC2002).

It sounds like you might be confusing the concept of Link Local addresses
(which will remain constant, but which are only accessible on the local
network) with global addresses which do certainly change between locations,
and can even change on-the-fly (eg, if your ISP was to give you a new IP
range).

  Scott.



More information about the Link mailing list