Re: [v6ops] I-D Action: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt

[Simon Hobson <[e-mail]>]

On 6 Aug 2017, at 04:21, Brian E Carpenter <[e-mail]> wrote:

> On 06/08/2017 14:19, Mark Smith wrote:
>> I give up. Do what you like, treat sand like diamonds.
> 
> I thought "Mark's exaggerating", but no, he isn't. There's a reasonable
> estimate of 5.6x10^21 grains of sand on the Earth's beaches:

Ah, that's what that's about.

> In the address space already available to IANA, we have 35x10^12 /48s (in 2000::/3)**.
> 
> That allows for 2.3x10^18 /64s (in 2000::/3).

Which is all fascinating given that ISPs generally hand out /48 or smaller - and we hear of some providing only a small number of /64s.
By the same reasoning, there's trillions of money around - so I should have no problem having a Ferrari on the drive ;-) It's not any help that there are so many addresses around if they aren't available to me.

In reality, if the ISP hands out a /48 then there are 2^80 addresses there. Now we go and constrain that (by continued insistence on "there shalt be no other allocation than /64") such that there are now only 2^16 available prefixes - but that assumes the entire /48 is available for such allocation. As I pointed out, by the time you have allowed for multiple sites, multiple networks, you might only have 2^8 prefixes - thus making the address space for tracking hosts quite small.

Now if you can make a case for a single host to have 2^64 addresses available to it then there's validity in not relaxing the /64 requirement - but I can't help thinking that that would be a hard case to make.

> If there's a problem, it's not in the area of a shortfall of /128s.
> If there's a shortfall of /64s, it's human error.

In theory yes, but meanwhile, back in the real world ...