nanog mailing list archives

Re: end-user ipv6 deployment and concerns about privacy


From: Mark Smith <nanog () 85d5b20a518b8f6864949bd940457dc124746ddc nosense org>
Date: Thu, 19 Aug 2010 06:46:48 +0930

On Wed, 18 Aug 2010 16:18:00 +0200
Hannes Frederic Sowa <hannes () mailcolloid de> wrote:

On Wed, Aug 18, 2010 at 12:34 PM, Mark Smith wrote:
Haven't really thought about it before.

One thing to consider is that unless the preferred and valid lifetimes
of an IPv6 prefix are set to infinity, IPv6 prefixes are always dynamic
- they'll eventually expire unless they're refreshed. The preferred and
valid lifetimes for prefixes that are delegated to customers could be
something that they might be able to change via a web portal, bounded
to within what you as an ISP are happy with e.g. 1 to 30 days, rather
than the absolute range of lifetime values supported. CPE could also
potentially do the same thing with the range of subnets it has been
delegated, by phasing in and out subnets over time on it's downstream
interfaces. (The more subnets the better, so a /48 would be ideal for
this.)

Yep, I am in favour of such setups. This will stress internal name
services(eg. netbios) but would be a solvable problem, I think.

As you've mentioned, privacy addresses help. A related idea is
described in "Transient addressing for related processes: Improved
firewalling by using IPv6 and multiple addresses per host." [0], Peter
M. Gleitz and Steven M. Bellovin, which takes advantage of the 2^64
addresses in a /64, and has different applications on the same host use
different source IPv6 addresses.

Pretending to be multiple hosts, or even just one with privacy
addresses, moving around multiple subnets, on delegated prefixes that
change fairly regularly would probably mitigate quite a lot of the
privacy concerns people may have related to IPv6 addressing.

If your ipv6-geolocation-service tells you that all /48 prefixes
behind this network are just static home-user networks, why not just
ignore the lower 64 bits or even the lower 80 bits? Privacy extensions
would be no help here. 

They help because you're concerned about privacy. You didn't qualify
that you're only concerned about privacy from geolocation services, so
I described a mechanism that would provide you as much privacy as
possible, while also being automatic, and also continuing to provide
IPv6 Internet connectivity. No where was cryto mentioned either (on
both our parts), yet that is also a privacy mechanism.

As a customer, it's relatively hard to hide from geolocation services
because they use your IP address in combination with information that
you don't have control over i.e. RIR / whois data. If a customer wants
to hide from that, then they'll need to start tunnelling their traffic
to another entry/exit point on the Internet.

Much like security, privacy is relative. If you want to have
bi-directional communications with another entity, you
have to disclose your identity. How long you retain that identity is
what makes one form of privacy more private than another.
Customers who have high expectations of privacy won't trust their
ISP at the time to preserve it - because, as the cliche goes, if you
want something done properly, you need to do it yourself. So, as an
ISP, you need to think about how much privacy you can provide, can
afford to provide, and at what point it becomes irrelevant because your
customer doesn't trust you to provide it at all.

In IPv4-land I have the possibility to
reconnect and get a new unrelated ip-address every time.


They're issued by the same ISP, to they're related.

Regards,
Mark.


Current thread: