end-user ipv6 deployment and concerns about privacy

Hello!

As the first IPv6 deployments for end-users are in the planning stage
in Germany, I realized I have not found any BCP for handling
addressing in those scenarios. IPv6 will make it a lot easier for
static address deployments but I wonder weather this is in the best
sense for the customers. As I normally come from the technical side I
prefer static addressing. But in the world of facebook and co. I
wonder if it would be a better to let the user have the choice. A
major provider of dsl here in Germany recently blogged about this [1].
Their proposal is to serve two subnets, one being a static one while
the other one will be dynamically allocated. I have no clue how the
user would switch between these subnets (without using some kind of
command line tools).

This is not about using privacy extensions as the subnet is sufficient
for identification.

Did you reach any conclusion on this matter?

Thanks,

  Hannes

[1] http://translate.google.com/translate?js=y&prev=_t&hl=en&ie=UTF-8&layout=1&eotf=1&u=http://blog.1und1.de/2010/05/07/ipv6-totale-ueberwachung/&sl=de&tl=en

Let the user choose. Here in Sweden we've for 10 years had ISPs offering static IPv4 address (either handed out via DHCP or just plain static with no dynamics what so ever) and some users prefer that, some don't. Some sell static IP as an extra option, some don't.

For people who want to use DNS and run services, they'll most likely want a static address/subnet that doesn't change in the first place (even though it should be handed out via DHCPv6-PD for ease). If someone wants to be anonymous, there is always TOR or other anonymising services.

Personally I prefer static for both IPv4 and IPv6 and have chosen providers accordingly historically. I also recommend this to others.

What does facebook have to do with it ? Ever heard of cookies ?

MarcoH

Facebook as an example of a company whose founder stated that privacy
is old-fashioned. Cookies sit on another network-layer I am currently
not talking about. They can be removed more easily, most simply by
reinstalling your computer. The user *can* do something about cookies.

For people who want to use DNS and run services, they'll most likely want a
static address/subnet that doesn't change in the first place (even though it
should be handed out via DHCPv6-PD for ease). If someone wants to be
anonymous, there is always TOR or other anonymising services.

Tor is fairly slow using it for every days internet surfing. Why don't
have sensible defaults for most users as default. For them I don't see
a need for static prefixes.

Personally I prefer static for both IPv4 and IPv6 and have chosen providers
accordingly historically. I also recommend this to others.

On the technical side it is clear. Static is the way to go.

Yeah but given the amount of NAT and dynamic addresses around in v4 land. I think it's highly unlikely you are better of tracking v4 addresses instead of pushing cookies, especially as most 2.0 sites require a login anyway.

Groet,

MarcoH

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

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.

Regards,
Mark.

[0] http://www.cs.columbia.edu/~smb/papers/tarp.pdf

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.

hannes

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

Hannes Frederic Sowa wrote:

the other one will be dynamically allocated. I have no clue how the
user would switch between these subnets (without using some kind of
command line tools).

Web portals work fine, and honestly, it's not like you need to switch subnets, either. PPPoE/A implementations work great, as they are already designed to utilize radius backends to quickly alter static/dynamic on a session. For bridging setups, you have a variety of implementations and it becomes messier. Cisco, while maintaining RBE did away with the concept of proxy-nd, and didn't provide a mechanism for dynamically allocating the prefixes to the unnumbered interface. If you use dslam level controls, you'll most likely being using DHCPv6 TA addressing with PD on top of it, which works well. Most of which can support quick static/dynamic capabilities as it does with v4.

Jack

> Hello!
>
> As the first IPv6 deployments for end-users are in the planning stage
> in Germany, I realized I have not found any BCP for handling
> addressing in those scenarios. IPv6 will make it a lot easier for
> static address deployments but I wonder weather this is in the best
> sense for the customers. As I normally come from the technical side I
> prefer static addressing. But in the world of facebook and co. I
> wonder if it would be a better to let the user have the choice. A
> major provider of dsl here in Germany recently blogged about this [1].
> Their proposal is to serve two subnets, one being a static one while
> the other one will be dynamically allocated. I have no clue how the
> user would switch between these subnets (without using some kind of
> command line tools).
>
> This is not about using privacy extensions as the subnet is sufficient
> for identification.
>
> Did you reach any conclusion on this matter?
>

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.

In case it isn't clear, the customer would have multiple delegated IPv6
prefixes during the overlap period. New prefixes are phased in and old
ones are phased out. Over what time period the phase in / phase out
occurs is what the customer could have the ability to change.

Changing addresses will disrupt ongoing communications. While
IPv6 can't prevent that disruption, it does have mechanisms available
to handle it far more gracefully than the customer having to bounce
their PPP session to acquire new addressing. With the right parameters,
I think an ISP could make phasing in/phasing out prefixes transparent
for most cases.

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.

I tried to highlight the relationship between ipv4-address and
/48-prefixes in regard to privacy. If a provider is known for handling
out statically allocated prefixes, it should be possible to track its
clients by prefix. Sorry for picking a geolocation-service as an
example of where such information can originate from. It was
misleading.

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.

Fully hiding from geolocation services is only possible with anonymity
services, yes.

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.

But most people just don't care. My proposal is to have some kind of
sane defaults for them e.g. changing their prefix every week or in the
case of a reconnect. This would mitigate some of the many privacy
concerns in the internet a little bit. Of course all the already known
problems would still exist. And still people have to care about the
technology to reach a higher level of anonymity.

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.

Ups. Unrelated in the sense of random ip from their pool, of course.

hannes

Thanks. I will have a deeper look in the standards. This sounds like a
viable solution to me. Albeit, I wonder if there is a drive for the
big ISPs to implement such features.

Ok. Lets assume that the ISP hands out new prefixes to the clients CPE each week. The CPE then advertises these prefixes on the clients home network. For clients accessing the internet this works fine (except perhaps a glitch during the switchover).

But what about the internal communication in the customer premises? How do they connect to their NAS, media players, printers, TVs etc? Of course there is UPnP, DLNA and different other kinds of magic but I imagine that most home users actually configure IP addresses at some point.

Constantly changing prefixes will ad another layer of complexity, things will break, and customers will be upset. (and quite frankly I don't think that you would gain that much privacy anyway)

just my $.02

/Joakim

But most people just don't care. My proposal is to have some kind of
sane defaults for them e.g. changing their prefix every week or in the
case of a reconnect. This would mitigate some of the many privacy
concerns in the internet a little bit. Of course all the already known
problems would still exist. And still people have to care about the
technology to reach a higher level of anonymity.

Ok. Lets assume that the ISP hands out new prefixes to the clients CPE each week. The CPE then advertises these prefixes on the clients home network. For clients accessing the internet this works fine (except perhaps a glitch during the switchover).

But what about the internal communication in the customer premises? How do they connect to their NAS, media players, printers, TVs etc? Of course there is UPnP, DLNA and different other kinds of magic but I imagine that most home users actually configure IP addresses at some point.

You actually imagine wrong in most cases. Many do, but, not most.

Most use mDNS for such things these days, actually.

Constantly changing prefixes will ad another layer of complexity, things will break, and customers will be upset. (and quite frankly I don't think that you would gain that much privacy anyway)

I would agree. I think that customers that WANT privacy at the expense of having their prefix
change often being able to request such service might be a good value-add service you could
offer, but, I think the vast majority of customers would prefer prefix stability.

I think that the privacy implications of a stable prefix are vastly over-stated in this thread.

Owen

Joakim Aronius wrote:

But what about the internal communication in the customer premises? How do they connect to their NAS, media players, printers, TVs etc? Of course there is UPnP, DLNA and different other kinds of magic but I imagine that most home users actually configure IP addresses at some point.

The wise setup will use routed and non-routed addressing internally. This is how IPv6 was designed to handle it. Devices will be found through multicast, dynamic dns, or other means.

Jack

But most people just don't care. My proposal is to have some kind of
sane defaults for them e.g. changing their prefix every week or in the
case of a reconnect. This would mitigate some of the many privacy
concerns in the internet a little bit. Of course all the already known
problems would still exist. And still people have to care about the
technology to reach a higher level of anonymity.

Ok. Lets assume that the ISP hands out new prefixes to the clients CPE each week. The CPE then advertises these prefixes on the clients home network. For clients accessing the internet this works fine (except perhaps a glitch during the switchover).

But what about the internal communication in the customer premises? How do they connect to their NAS, media players, printers, TVs etc? Of course there is UPnP, DLNA and different other kinds of magic but I imagine that most home users actually configure IP addresses at some point.

manual configuration of ip address name mappings seems like a rather low
priority for the average home user...

I don't expect that will be a big activity in the future either, more
devices means less manual intervention not more.

Ok, ok, so that argument sucked. I guess I'm still stuck in the IPv4 mindset and have not yet grasped the full blessing of IPv6, zeroconf etc. etc.

Anyway, constantly changing prefixes for home users still seem like begging for trouble. (Could be a service though, as mentioned, but on the other hand I expect a fair number of anonymity services to arise so charging for it might be tough.)

Cheers,
/Joakim

If you still want fairly static addressing for your local network, there is always ULA.

And those addresses do not leak to the outside world.

I'm surprised no one mentioned it, maybe I missed it.

I can understand if people don't recommend them because you mentioned end-user, but it might be useful to a poweruser.

You could have your DSL- or cable-router/-modem onetime generate a ULA and have RA/DHCPv6 distribute that to the devices in the network like the addresses it gets from the provider.

>
> But most people just don't care. My proposal is to have some kind of
> sane defaults for them e.g. changing their prefix every week or in the
> case of a reconnect. This would mitigate some of the many privacy
> concerns in the internet a little bit. Of course all the already known
> problems would still exist. And still people have to care about the
> technology to reach a higher level of anonymity.

Ok. Lets assume that the ISP hands out new prefixes to the clients CPE each week. The CPE then advertises these prefixes on the clients home network. For clients accessing the internet this works fine (except perhaps a glitch during the switchover).

But what about the internal communication in the customer premises? How do they connect to their NAS, media players, printers, TVs etc? Of course there is UPnP, DLNA and different other kinds of magic but I imagine that most home users actually configure IP addresses at some point.

Constantly changing prefixes will ad another layer of complexity, things will break, and customers will be upset. (and quite frankly I don't think that you would gain that much privacy anyway)

ULA - RFC4193.

(People really need to stop thinking in IPv4 mode when discussing
IPv6 ....)