Re: [v6ops] I-D Action: draft-colitti-v6ops-host-addr-availability-01.txt

[Ted Lemon <[e-mail]>]

On Jul 28, 2015, at 12:51 PM, Lorenzo Colitti <[e-mail]> wrote:
> Well but if if you give a laptop or a device a /120, what is it going to give its downstream devices / VMs when sharing its internet connection with them? Does it have to implement a stateful DHCPv6 server and force its downstream devices/VMs to use it? At that point, the network it offered would be violating recommendations made in the draft.

So you want the device to be able to use DHCPv6-PD on the upstream, but support SLAAC on the downstream.   So this really isn’t a general mechanism: it’s for the smartphone router use case specifically.

> A /64 is better because it allows connection sharing mechanisms such as ND proxying and /64 share which also do not pose hard limits to the number of addresses a downstream device may have.

For the smartphone router case, I can see that.

> A /64 also isn't that much space: the space implications for enterprise networks are pretty much the same as what we do for IPv4 today (i.e., a large enterprise that needs all of 10/8 gets 16M endpoints) - except that the address space implications for the Internet are much better than IPv4 today because said large enterprise with 16M endpoints will only need a /40, and there are quite a lot of those.

There are 256 times as many /40s as IPv4 addresses.   That’s a _really_ small number unless you see the Internet growth curve flattening out, and your draft suggests that you don't.   The IPv6 address space looks big compared to IPv4, but it seems like everybody wants to pull bits out of it, and when you’re pulling out bits and not addresses, you can only pull out 128 of them before you’re done.