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

[Mikael Abrahamsson <[e-mail]>]

On Mon, 7 Aug 2017, Simon Hobson wrote:

> Presumably that means another separate prefix. And when 2003:: is used, 2004:: will get allocated and so on.

We have 2000::-3fff:: to get this right. If we deem that we're now wasting 
addresses, we'll have to come up with different policy for 4000::-5fff::: 
(the next /3.

> At what point will people be suggesting that we could have avoided the 
> routing table bloat by allowing better use of the prefixes ?

Routing table bloat happens because the allocated prefixes at the higher 
level are too small, not because they're too big.

If someone spends their /29 then next time we should give them a 
significantly larger prefix to avoid routing table bloat.

RIPE at least allocates a 8 times the size of your initial allocation off 
the bat, so anyone going to them saying "I have a million customers and I 
want to give each a /48" should receive a /28 or a /27, with a /25 
reserved for growth for them (in case they did receive a /28). This is to 
avoid routing table bloat.

> AFAICS the insistence that it must be /64 per host, rather than anything else (eg /80/host or /96/host) seems to be more religion than technical requirement.

> I can see the security (through obscurity) and privacy reasons why 
> individual addresses should come from a /64 (or at least, large) prefix 
> - but I fail to see much, if any, merit in allocating 2^64 addresses to 
> a single host "because we can".

It's /64 because we can't agree on a smaller size that makes sense to 
everybody, that at the same time isn't too small. I wouldn't call it 
religion, but I would call it "healthy sceptisism about what might happen 
otherwise".

Today a non-trivial amount of ISPs hand out /64 to residential users, 
probably because they they reason that a site is a single subnet. If we 
allowed /80, what stops them handing out /80? Or /79, because, why not?

I kind of like having this hard limit, it means there is reasonable 
expectation just by looking at the address that "this is a subnet", 
without having to know the remote end addressing policy. Sure there could 
be multiple customers within that /64, but we should drive towards having 
fewer customers sharing the same /64, as opposed to the other way around.

-- 
Mikael Abrahamsson    email: [e-mail]