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