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

[Simon Hobson <[e-mail]>]

Mark Smith <[e-mail]> wrote:

> That's why I think simple universal sizes/boundaries like /48 per site
> and /64 for subnets/64 bit IIDs are better. They reduce the cost of
> handling - the cost of humans becoming involved to be parsimonious
> with addresses and numbers of /64 prefixes increases the handling cost
> of IPv6 addresses. They reduce costs in other places too - having a
> single, common and generic IID size rather than a per link-specific
> IID size means development and implementation of IPv6-over-foo
> specifications is cheaper, because there does not have to be any per
> link-specific IID size related effort.

Why do you think there will be any development cost saving - UNLESS you specifically rule out flexibility to handle unforeseen (or even foreseen) usage cases ?

So, lets assume we run with the "there will be no network with other than a /64 prefix" option. Devs can ignore any need to store or handle prefix lengths - very very marginal saving in dev time (lets face it, this code already exists to handle 32 bit numbers).
So what happens when someone does have a need to handle (say) a /65 because of some reason that's out of their control - perhaps all they get from upstream is a single /64 and they need to divide it. Answer - they can't, because for a very small saving up front, that flexibility has been ruled out.

I'm not saying that /64 can't or shouldn't be the default, but given all the comments about "not blocking future innovation" it seems a bit contrary to then insist on causing known problems for a marginal (and questionable) saving on development. AFAICS, there is agreement that there isn't actually any technical reason for HAVING to use a /64 anywhere (other than LL which is a special case anyway), and the only remaining technical reason is the now deprecated method of forming SLAAC addresses.

So is there ANY valid technical reason why implementations should not be required to handle arbitrary prefix lengths, since if you can handle any length, then you can easily handle 64 - but if you hardcode in 64 (probably by coding differently) then handling any other length may become impossible.
Or put another way, do you want to be one of those people who in 10, 20, ... years time are the target of "WTF were they thinking of ?" comments when/if there emerges a good case for a different prefix length and it can't be done because there's too much hardcoded /64 built into the system ?


BTW - the sand analogy breaks down once you consider that it too is limited. There may be more grains of sand on the beaches than we can count, but I can't just pop down to the beach and dig up a trailer load to build my new garage with without getting into trouble with the law ! The price soon starts adding up once you are buying it from the builders merchant.