end-user ipv6 deployment and concerns about privacy

Hannes Frederic Sowa hannes at mailcolloid.de
Wed Aug 18 14:18:00 UTC 2010

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. In IPv4-land I have the possibility to
reconnect and get a new unrelated ip-address every time.


More information about the NANOG mailing list