end-user ipv6 deployment and concerns about privacy

Mark Smith nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org
Wed Aug 18 21:16:48 UTC 2010

On Wed, 18 Aug 2010 16:18:00 +0200
Hannes Frederic Sowa <hannes at 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.


More information about the NANOG mailing list