Re: Android (lack of) support for DHCPv6

[George Michaelson <ggm () algebras org>]

On Wed, Jun 10, 2015 at 2:06 PM, Lorenzo Colitti <lorenzo () colitti com>
wrote:

> On Wed, Jun 10, 2015 at 8:30 PM, Karl Auer <kauer () biplane com au> wrote:
>
> > Seems to me that N will vary depending on what you are trying to do.
>
>
> Remember, what I'm trying to do is avoid user-visible regressions while
> getting rid of NAT. Today in IPv4, tethering just works, period. No ifs, no
> buts, no requests to the network. The user turns it on, and it works.
> IPv4-only apps always work.
>
> A model where the device has to request resources from the network before
> enabling tethering, or before supporting IPv4-only apps, provides a much
> worse user experience. The user might have to wait a long time, or the
> operation might even fail.

Laudible goal. I think with mifi devices typically limiting to 8/16 I have
a sense  that a /56 (which btw, was the unit we expected to use for
mass-customer deployment edge numbering) is going to be ok.

Its inevitable that in some other N+ years, we're going to be astonished by
how many IPs are needed behind the connecting device, but a /56->/64 gap is
going to work for now.

So pragmatism drives me to say 'we probably have enough in the model we're
working on'

I say this, because whilst I personally don't like the HD ratio model, its
what we adopted as a global measure of density of use, and I think
respecting allocation practice which reflects the HD ratio model is good,
and drives us to /56 for mass-customer deployments.

(I know there are policy people who may believe /48 is where we're going to
go. I can only say thats not how I understand address allocation modelling
works in many regions, right now. I also know there are people who think a
single customer can be a /128. I don't agree with that either)

-G