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

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 22 Sep 2015 16:32:17 +0000

I read through the draft and found myself feeling that the arguments presented were rather uncompelling. So I'm going to provide some pushback.
Since the draft is presenting itself as recommendations for *all* networks, I decided to think about how I would look at it in the context of (1) a wireline broadband access service operator, (2) a wireless operator, and (3) an enterprise network operator.

Going through the list of benefits, the following struck me:
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.

2. Several of the listed benefits involve potential use by multiple processors on a host, virtual machines on a host, future applications, and identifier-locator addressing (ILA). In listing these, there was nothing that said "this is incredibly useful, but hosts are prevented from doing it (or run into a lot of complexity) if the host is restricted to a single DHCPv6-assigned IPv6 address". I didn't read that hosts would have a hard time having multiple processors or future applications in the absence of multiple addresses, and I didn't get out of the discussion that virtual machines and ILAs that require their own address are incredibly compelling and hosts and users can't live without them.

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.

>From an enterprise and wireline perspective, I'm completely unconvinced that the suggested benefits are worthy of a BCP recommendation. 

>From a wireline perspective, I also see the recommendation as useless, since I'm not aware of any wireline architectures (BBF or CableLabs) that don't do PD. The wireline operators don't need a BCP to tell them to continue doing this. Of course the reason they do PD isn't even listed as among the benefits, since they don't do this for the sake of attachment by an individual host. They do this so customers can run entire private networks behind a fully-functional CE router. But I'm not aware of any wireline operator who requires the device requesting IA-PD to be a router.

>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 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 and/or certain devices.
Barbara

---

From: Tore Anderson <[email-masked]>
Date: Wed, 23 Sep 2015 09:17:56 +0200

* "STARK, BARBARA H" <[email-masked]>

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

Wrong.

464XLAT can be used in any IPv6-only network, and the problem it solves
-- "make AF_INET sockets work on with IPv6-only external connectivity"
-- is solved equally well regardless of the technology of the external
IPv6-only link.

See RFC 6877 sections 4.1 and 5.1.

OpenWrt, which most commonly has a wired upstream, does support 464XLAT
CLAT operation.

I use 464XLAT where needed in my data centres. This is all wired
Ethernet, no wireless.

I am also considering changing several of the enterprise networks
(workstation networks and such) from using public IPv4 addresses to
using private IPv4 provided by a CLAT. This allows me to reclaim
valuable IPv4 addresses without me requiring me to introduce NAPT44 in
my network. (NAT64 is much easier to locate in a network than NAPT44 as
it does not require a default route pointing to it.)

A very similar application to a 464XLAT CLAT, but which is targeted
specifically at a wired environment like at data centre, is described
in I-D.ietf-v6ops-siit-dc-2xlat. Just like 464XLAT the functionality is
dependent on having exclusive use of a (secondary) IPv6 address. If
only a single address can be used, then this application cannot
function. For example: https://bugs.launchpad.net/neutron/+bug/1495433

Tore

---

From: Andrew 👽 Yourtchenko <[email-masked]>
Date: Wed, 23 Sep 2015 12:49:41 +0200

On 9/22/15, STARK, BARBARA H <[email-masked]> wrote:
> I read through the draft and found myself feeling that the arguments
> presented were rather uncompelling. So I'm going to provide some pushback.
> Since the draft is presenting itself as recommendations for *all* networks,
> I decided to think about how I would look at it in the context of (1) a
> wireline broadband access service operator, (2) a wireless operator, and (3)
> an enterprise network operator.
>
> 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).

This can result in being able to serve more clients on the same hardware.

>
> 2. Several of the listed benefits involve potential use by multiple
> processors on a host, virtual machines on a host, future applications, and
> identifier-locator addressing (ILA). In listing these, there was nothing
> that said "this is incredibly useful, but hosts are prevented from doing it
> (or run into a lot of complexity) if the host is restricted to a single
> DHCPv6-assigned IPv6 address". I didn't read that hosts would have a hard
> time having multiple processors or future applications in the absence of
> multiple addresses, and I didn't get out of the discussion that virtual
> machines and ILAs that require their own address are incredibly compelling
> and hosts and users can't live without them.

Section 4 talks about the complexities of allocating the addresses in
a piecemeal fashion - when I read it, the "IA_NA" is the only thing
that comes to mind because there is no other mechanism that is used to
assign individual addresses.

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

>
> >From an enterprise and wireline perspective, I'm completely unconvinced
> that the suggested benefits are worthy of a BCP recommendation.
>
> >From a wireline perspective, I also see the recommendation as useless,
> since I'm not aware of any wireline architectures (BBF or CableLabs) that
> don't do PD. The wireline operators don't need a BCP to tell them to
> continue doing this. Of course the reason they do PD isn't even listed as
> among the benefits, since they don't do this for the sake of attachment by
> an individual host. They do this so customers can run entire private
> networks behind a fully-functional CE router. But I'm not aware of any
> wireline operator who requires the device requesting IA-PD to be a router.
>
> >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.

https://books.google.com/books?id=fml06QWRJXQC&pg=PT205&lpg=PT205&dq=3GPP+specification+dedicated+prefix&source=bl&ots=kDZ1vkE3R7&sig=JhdouPCEc9DF0kCxrgUaXnDukuQ&hl=en&sa=X&ved=0CC8Q6AEwAmoVChMIiYLusvyMyAIVSfM-Ch2UaQhH#v=onepage&q=3GPP%20specification%20dedicated%20prefix&f=false

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

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

--a

> and/or certain devices.
> Barbara
>
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Sander Steffann <[email-masked]>
Date: Wed, 23 Sep 2015 13:05:54 +0200

> Every time I mention per-user tweaks with any SP in any context, they

/me makes lemon face

Cheers :)
Sander

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 23 Sep 2015 20:51:49 +0900

> tracking systems to track at the /64 instead of the /128.

Here's one privacy benefit that requires the ability to form multiple
addresses: change your privacy address as often as you want, instead of how
often the operator wants. Or, use different addresses to talk to different
sites (e.g., a web server and an advertising server). These are both useful
benefits if the network is trustworthy but the the attack is pervasive
monitoring outside the network (e.g., by a national security agency).

These aren't in the draft, but we could add them.

> and hosts and users can't live without them.

As someone who has worked on the ePDG implementation on Android devices, I
can assure you that the architecture that's used to ensure that the
baseband processor and the application processor could share an IP address
is pretty contorted - you might even say nightmarish.

And VMs do require their own addresses - no host OS I'm aware of supports
sharing an IP address with another host. The sharing has to be done by
performing NAT on the upstream.

... which is really the point here. What we're trying to say here is not
that these use cases are hard or impossible without multiple addresses.
What we're trying to say is that they exist, and that they can either be
met using multiple addresses or (in most cases) by performing NAT66 in the
host. We're recommending that we do not go to an architecture where hosts
need to implement NAT66, and thus we recommend that the network should
assign enough addresses that NAT66 is not necessary.

Also, I'm not sure exactly what you're trying to say here. Are you saying
that:

   1. You disagree that if the network assigns a single /128, hosts will
   implement and use NAT66; that they will instead reduce or disable (possibly
   user-visible) functionality.
   2. You believe that it's fine if networks assign a single /128 to a
   device, even if it means that hosts will (possibly widely) implement NAT66.
   3. Something else?

Cheers,
Lorenzo

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 23 Sep 2015 13:32:31 +0000

> > 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.
> 
> Wrong.
> 
> -- is solved equally well regardless of the technology of the external IPv6-
> only link.

Good point. OK, so I change my statement to say that translation (like 464XLAT) only applies in an IPv6-only network. I still contend that tethering is specific to "3GPP"-type-technology  wireless networks.
 
> OpenWrt, which most commonly has a wired upstream, does support
> 464XLAT CLAT operation.

I think of OpenWRT as router software. I'm not aware of any pure hosts using it.

> I use 464XLAT where needed in my data centres. This is all wired Ethernet, no
> wireless.

Do you use 464XLAT inside all the end hosts and offer IPv6-only to all hosts inside the data centers? Or do you use it at the edge, and provide IPv4 and IPv6 addresses to the hosts? The need to do translation (like 464XLAT) is listed in this draft as a justification for providing an IPv6 prefix to all end hosts inside all networks (including, presumably, inside data centers). I'm still not seeing that.
Barbara

---

From: Tore Anderson <[email-masked]>
Date: Wed, 23 Sep 2015 15:54:32 +0200

* STARK, BARBARA H

> Good point. OK, so I change my statement to say that translation
> (like 464XLAT) only applies in an IPv6-only network. I still contend
> that tethering is specific to "3GPP"-type-technology  wireless
> networks.

If you're running virtual machines on your computer, using software
such as VirtualBox, Parallels, KVM, or VMware Workstation; you are in
principle performing tethering.

> I think of OpenWRT as router software. I'm not aware of any pure

That's right. My point here was that regardless of your uplink being
something wired like Ethernet, DSL, whatever - if you're using OpenWrt
in your home gateway, you can still use 464XLAT as long as you have an
IPv6 uplink and access to a NAT64 service (there are serveral public
ones available over the Internet if you'd like to try it yourself).
I.e., cementing the point that the 464XLAT technology is not specific
to wireless ISPs.

> Do you use 464XLAT inside all the end hosts and offer IPv6-only to
> all hosts inside the data centers? Or do you use it at the edge, and
> provide IPv4 and IPv6 addresses to the hosts? The need to do
> translation (like 464XLAT) is listed in this draft as a justification
> for providing an IPv6 prefix to all end hosts inside all networks
> (including, presumably, inside data centers). I'm still not seeing
> that.

My core network provides NAT64/DNS64 service. Most of the IPv6-only
servers I have are happy with that, since it makes stuff like "git
clone https://github.com/foo/bar" work just fine. So no, far from all
of my IPv6-only servers are using 464XLAT.

However, a minority of the servers need to run software that tries to
do low-level IPv4 stuff directly and fails if it cannot - essentially
because stuff like "ping 8.8.8.8" doesn't work when the node is
IPv6-only. On those servers specifically we activate the 464XLAT CLAT
so that stuff like AF_INET sockets and "ping 8.8.8.8" starts working.
We do not need the server to have a dedicated prefix for this to work,
but it *does* need a second IPv6 address with a global scope.

Tore

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 23 Sep 2015 14:03:29 +0000

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

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

> 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

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 23 Sep 2015 14:57:35 +0000

In-line, marked with <bhs>.
Barbara

Here's one privacy benefit that requires the ability to form multiple addresses: change your privacy address as often as you want, instead of how often the operator wants. Or, use different addresses to talk to different sites (e.g., a web server and an advertising server). These are both useful benefits if the network is trustworthy but the the attack is pervasive monitoring outside the network (e.g., by a national security agency).

<bhs> Privacy addresses can help with 2 privacy functions: (1) they obscure the MAC address; (2) self-generated SLAAC privacy addresses reduce the ability to do external-to-the-local network tracking down to the /64 prefix level. When the /64  is shared among multiple devices, there can potentially be a little bit of additional privacy from tracking – but even that depends, given all the info browsers hand out to HTTP servers. When a /64 is dedicated to a device, and the /64 never changes, the benefit of privacy addresses is reduced to obscuring the MAC address. A single unchanging privacy address within the unchanging prefix provides exactly the same obscuring of the MAC address as dozens of constantly changing privacy addresses. We need to stop perpetuating this privacy myth.

<bhs> If you want to list improved tracking as a benefit (i.e., reduced privacy), I would have no problem with that. Many people would indeed see that as a benefit.

As someone who has worked on the ePDG implementation on Android devices, I can assure you that the architecture that's used to ensure that the baseband processor and the application processor could share an IP address is pretty contorted - you might even say nightmarish.

<bhs> But it’s been done? Now if you said that not using this nightmarish code would improve battery life of the devices, that would be a real benefit (from an operator perspective – who is your target audience). But if the code is done and works, then I don’t see why an operator should care how nightmarish it was for the OS implementation.

And VMs do require their own addresses - no host OS I'm aware of supports sharing an IP address with another host. The sharing has to be done by performing NAT on the upstream.

<bhs> I didn’t say VMs didn’t need their own addresses. What I said was I wasn’t convinced that all hosts needed VMs in order to do whatever it was the user wanted them to do. You haven’t provided a compelling reason why VMs are beneficial in hosts. Without that, I don’t understand why I should care whether or not  all hosts can run VMs.

... which is really the point here. What we're trying to say here is not that these use cases are hard or impossible without multiple addresses. What we're trying to say is that they exist, and that they can either be met using multiple addresses or (in most cases) by performing NAT66 in the host. We're recommending that we do not go to an architecture where hosts need to implement NAT66, and thus we recommend that the network should assign enough addresses that NAT66 is not necessary.

<bhs> NAT66 is not something that hosts inside enterprise networks need to be worried about. Yes, I can see that it’s a problem for UEs in a wireless network.

Also, I'm not sure exactly what you're trying to say here. Are you saying that:

  1.  You disagree that if the network assigns a single /128, hosts will implement and use NAT66; that they will instead reduce or disable (possibly user-visible) functionality.
  2.  You believe that it's fine if networks assign a single /128 to a device, even if it means that hosts will (possibly widely) implement NAT66.
  3.  Something else?
<bhs> I’m saying that you haven’t presented your case in a very compelling manner. The case for (the interior of) enterprise networks is non-existent. The case for wireline networks is unnecessary. I think it’s possible for you to make a compelling case for 3GPP wireless networks, but that needs work. I think it would be easier for you to make that case if you focused on that audience and that case. I also think that you would make the case better if you provided benefits worded in a way that cause the operator to care (i.e., by appealing to their self-interest). And “benefits” that are not real benefits detract from the argument because they provide an easy target for detractors to attack, and draw attention away from the real benefits.
Barbara

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 24 Sep 2015 07:48:34 +0900

On Wed, Sep 23, 2015 at 11:57 PM, STARK, BARBARA H <[email-masked]> wrote:
> <bhs> Privacy addresses can help with 2 privacy functions: (1) they
> obscure the MAC address; (2) self-generated SLAAC privacy addresses reduce
> the ability to do external-to-the-local network tracking down to the /64
> prefix level. When the /64  is shared among multiple devices, there can
> potentially be a little bit of additional privacy from tracking – but even
> that depends, given all the info browsers hand out to HTTP servers. When a
> /64 is dedicated to a device, and the /64 never changes, the benefit of
> privacy addresses is reduced to obscuring the MAC address. A single
> unchanging privacy address within the unchanging prefix provides exactly
> the same obscuring of the MAC address as dozens of constantly changing
> privacy addresses. We need to stop perpetuating this privacy myth.
>

I think what you're saying is not relevant to this discussion? "A single
unchanging privacy address" is not what I wrote above - in fact it is the
exact opposite. What I wrote was that there's a benefit to frequently
changing addresses within the same prefix, or even using different
addresses for every website.

> <bhs> But it’s been done? Now if you said that not using this nightmarish
> code would improve battery life of the devices, that would be a real
> benefit (from an operator perspective – who is your target audience). But
> if the code is done and works, then I don’t see why an operator should care
> how nightmarish it was for the OS implementation.
>

When the code is complex, everybody (users, operators, developers, ...)
suffer from a higher incidence of bugs, higher maintenance costs, and
increased development cost / development time needed to evolve the code for
new features. If you say that's not the operator's problem... well, I like
to think that some (perhaps most?) operators strive to do better for their
users than that. And anyone trying to advance the state of the Internet,
like we do here at the IETF, should be trying to ensure that standards do
not force that sort of complexity on implementations.

> <bhs> I didn’t say VMs didn’t need their own addresses. What I said was I
> wasn’t convinced that all hosts needed VMs in order to do whatever it was
> the user wanted them to do. You haven’t provided a compelling reason why
> VMs are beneficial in hosts. Without that, I don’t understand why I should
> care whether or not  all hosts can run VMs.
>

The question is not whether all hosts need to run VMs. The question is
whether some hosts need to run VMs or do other things that benefit from
multiple addresses.

> <bhs> NAT66 is not something that hosts inside enterprise networks need to
> be worried about.
>

Why? I know lots of users of my enterprise network that run VMs, run
Android / iOS emulators on their development machines, use ePDG services,
etc. With only one /128 per host, you can'd to that without NAT66.

> Yes, I can see that it’s a problem for UEs in a wireless network.
>

NAT66 is currently not a problem on 3GPP wireless networks, because when
the wireless standards organizations came to the IETF for advice when
designing IPv6 support in 3GPP (I suppose at that time it must have been
called GSM), the IETF gave them the same advice given in this draft - that
a /128 per device is not enough and that a /64 was needed.

> <bhs> I’m saying that you haven’t presented your case in a very compelling
> manner. The case for (the interior of) enterprise networks is non-existent.
>

So, to be clear - when you say "the case for enterprise networks is
non-existent", you're saying that you expect hosts inside enterprise and
educational networks (let's not forget about those, BTW) to need to run
NAT66 to support features that require multiple addresses, and that's not a
problem?

---

From: Andrew 👽 Yourtchenko <[email-masked]>
Date: Thu, 24 Sep 2015 10:35:38 +0200

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

>> interested in
> 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.
>
> 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.
>
>> allocate
>> make
> 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

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 24 Sep 2015 10:53:49 +0200

Le 23/09/2015 16:03, STARK, BARBARA H a écrit :
[...]

>>>> 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
>>
> Really? I'd heard that was true of some deployments. I hadn't heard
> that it was true of all.

It depends how much detail is mentioned.

Yes, in IPv6 cellular networks the UE sees a /64 in an RA - the Prefix
Information Option.

However, that means little about a /64 being 'allocated' to a User
Equipment (UE).  Yes, the network considers that /64 be for one
particular UE; yes, the network uses internally DHCPv6-PD to acquire
that /64.  The first-hop router requests it and then puts it in an RA
towards UE.

But no, the UE does not request it, typical smartphones do not run
DHCPv6-PD and the network does not respond to prototype UEs making
DHCPv6-PD requests.

It can also be considered that a /64 so 'allocated' to a cellular UE
allows UE to configure each single address in that prefix (as opposed to
a laptop seeing a PIO in RA on WiFi, which must DAD it first and which
may collide to other laptops hearing the same /64).  But this is so - UE
has right to each address in a /64 -  because the cellular link is still
a point-to-point link, contrary to shared WiFi - there's no one else on
that UE link.

Another detail: cellular networks running DHCPv6 to UE, along with RA,
allocate an _address_ to an UE.  That address has no prefix length
because DHCPv6-Address does not communicate prefix lengths.  In some
deployment, the first 64bits of the address allocated by DHCPv6 are
different than the PIO in the RA received at the same time.  The UE ends
up with two global addresses: one can be said to _have_ a prefixlen, the
other no.

In this setting, what one needs is DHCPv6-PrefixDelegation for UE, and
the prefixlength must be < 64.  The reasons are: (1) it allows to
tether/route cleanly more than 1 subnet (2) is future proof for 5G links
which will be presumably more shared than ptp, (3) empowers the UE (it
_requests_ a prefix first, rather than being _advertised_ a prefix).

> 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
> difference between what gets written in 3GPP standards and what ends
> up being deployed and enabled.

I agree.

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

Or maybe try Monzoon-equipped hotels, as an earlier poster pointed to.

Alex

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 24 Sep 2015 11:22:56 +0200 (CEST)

On Wed, 23 Sep 2015, STARK, BARBARA H wrote:

> 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

The need for this isn't for 3GPP networks. 3GPP networks always give /64 
per PDP context (it's in the specs, and since RAs and A=1 is used for the 
UE to learn the on-link prefix to form addresses from, it can't be 
anything else than a /64 according to the SLAAC specifications).

The problem this draft is trying to alleviate is generally enterprise Wifi 
networks where some administrators want to use DHCPv6 to allocate 
addresses.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Dan Drown <[email-masked]>
Date: Thu, 24 Sep 2015 10:52:08 -0500

Quoting Lorenzo Colitti <[email-masked]>:
> etc. With only one /128 per host, you can'd to that without NAT66.

Because I didn't know what ePDG was before this, I had to look it up.   
Below is my summary of it, anyone who understands it better, please  
feel free to correct it.

ePDG is a secure tunnel back to your cell phone operator, and wifi  
calling is one application that can run over it.  It runs on the  
baseband processor rather than the application processor of the phone.  
  There are two different operating systems running on these  
processors, and they need to share connectivity to the outside world.   
With v4, I assume this is achived with NAT44 when connected to a wifi  
AP.

Wifi calling is an application that's on millions of phones already.   
I don't know if ePDG is a popular implementation or if there are any  
competing implementations.

With v6, the design of assigning a dedicated v6 address (from a prefix  
or a pool) to the baseband processor would make sense for this  
application, as it makes the phone's internal network easier to  
understand.  The alternatives would be to do NAT66 on the application  
processor or not have v6 on the baseband processor at all.

---

From: Ca By <[email-masked]>
Date: Fri, 25 Sep 2015 11:51:52 -0700

On Thursday, September 24, 2015, Dan Drown <[email-masked]> wrote:

> Below is my summary of it, anyone who understands it better, please feel
> free to correct it.
>
> ePDG is a secure tunnel back to your cell phone operator, and wifi calling
> is one application that can run over it.  It runs on the baseband processor
> rather than the application processor of the phone.  There are two
> different operating systems running on these processors, and they need to
> share connectivity to the outside world.  With v4, I assume this is achived
> with NAT44 when connected to a wifi AP.
>
> Wifi calling is an application that's on millions of phones already.  I
> don't know if ePDG is a popular implementation or if there are any
Yes, ePDG is common implementation

CB

> With v6, the design of assigning a dedicated v6 address (from a prefix or
> a pool) to the baseband processor would make sense for this application, as
> it makes the phone's internal network easier to understand.  The
> alternatives would be to do NAT66 on the application processor or not have
> v6 on the baseband processor at all.
>