On Wed, Jun 10, 2015 at 2:06 PM, Lorenzo Colitti <[email protected]> wrote:
> On Wed, Jun 10, 2015 at 8:30 PM, Karl Auer <[email protected]> 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
