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

[Andrew 👽 Yourtchenko <[e-mail]>]

On 9/23/15, STARK, BARBARA H <[e-mail]> wrote:
>> > 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.

Okay, I was interpreting as the latter all the time, so maybe you have
some wording tweak in mind you could suggest to the authors...

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

I see them wanting IPv6-only access networks, besides other things.

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

I think Lorenzo has commented on this one already.

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

Sure, if the necessity requires - indeed.

But my overall position is that even if something is done frequently,
that does not make it a good idea long-term.

An overall analogy would be that this draft advocates that quitting
smoking is a best practice.

Of course there are short-term localized benefits of smoking and in
some places it's even considered cool to smoke.

--a



> Barbara
>