Re: [v6ops] v6ops-host-addr-availability: A Little Pushback

["STARK, BARBARA H" <[e-mail]>]

> > 1. Privacy. Changing tracking requirements from needing to track a
> > /128 to only needing to track a /64 does not provide for any sort of
> > improved privacy against tracking. We need to stop perpetuating this myth.
> > draft-ietf-dhc-dhcp-privacy already describes how to provide a single
> > address that doesn't give away the MAC address. Other than not giving
> > away the MAC, there is no privacy benefit I can see to more easily
> > allowing tracking systems to track at the /64 instead of the /128.
> 
> I interpret the words in the draft differently: the point is that instead of
> storing 8*128 bits of bindings on the access router one can store 1*64 bits.
> (and yes you need to store the bindings if you want to have the secure
> access today).

Exactly my point. The same invasion-of-privacy tracking can be done at /64 instead of /128, thereby making such tracking easier. Making invasion of privacy easier should not be listed as a benefit. But I could see "Easier Tracking" being listed as a benefit.

> > 3. Tethering and translation (like 464XLAT) tend to be really specific
> > to wireless networks. These are the most compelling benefits listed,
> > but they don't apply to enterprise and wireline.
> 
> I personally had discussions with multiple large-ish enterprises interested in
> the 464XLAT or derived tech in their wired networks.

In my response to Tore, I acknowledged that I should have said 464XLAT only makes sense in IPv6-only networks. But I also still don't see these enterprise networks expecting to run 464XLAT in all end hosts and make the entire enterprise network IPv6-only. I see them wanting to put the 464XLAT at the edge. This draft is listing 464XLAT in end hosts as a reason why all networks should give all end hosts IPv6 prefixes.

> > >From a wireless perspective, I don't really see this as being what
> > >would
> > convince a wireless operator to deploy PD. The case I try to make is
> > that
> 
> IPv6 in 3GPP environments allocate /64 per UE today.

Really? I'd heard that was true of some deployments. I hadn't heard that it was true of all. If it is true of all, then I'm very curious why Apple and Google feel the need for this draft. BTW, the link you provided was describing a 3GPP standard. The idea that everything described in the standard is implemented and deployed in all 3GPP wireless networks that have enabled some degree of IPv6 support is not true. There's quite a big difference between what gets written in 3GPP standards and what ends up being deployed and enabled.

> I've been told that the SP WiFi architecture best practice is to also allocate
> dedicated per-UE prefix on converged WiFi as well.

Interesting. I'll have to try that out next time I'm in range of a attwifi hotspot.
 
> > wireless is more and more being used in the same manner as wireline:
> > to support an entire LAN of networked devices behind a CE router
> > (usually with a USB-connected wireless device). In many places,
> > operators are saying that wireless is the deployment model for getting
> > "broadband access" to rural areas. If this use case is going to be
> > fully supported with IPv6, then PD has to be supplied. Of course, with
> > wireless networks being able to easily recognize the type of device
> > used and the user, the network operator will always have the ability
> > to selectively offer the PD to only certain users
> 
> Every time I mention per-user tweaks with any SP in any context, they make
> a lemon face.

There's a rather famous case of a wireless provider who only allowed Facetime to be used by subscribers with "Share" data plans and not "individual" data plans. That same provider is also known to specify which UEs get IPv6 addresses and which don't. Some providers are known to implement bandwidth limitations on heavy-usage subscribers. Perhaps there are some providers who do not implement any UE-based or subscriber / subscribed-plan based policies. But there are many who do. Of course I don't consider these policies to be "per-user tweaks". I would characterize them as policies that impact individual users on the basis of their UE, usage, and subscribed data plan; they may be implemented throughout a network or only in certain regions or markets of a network. And where I live, they're incredibly common.
Barbara