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

[Brian E Carpenter <[e-mail]>]

On 05/08/2017 21:58, Simon Hobson wrote:
> Mark Smith <[e-mail]> wrote:
> 
>>> Is this prohibited by this document? Or is ‘/64’ mentioned in the document only an example?
>>
>> No. /64s as the subnet size as been the common edge subnet/IID
>> boundary for almost 20 years since RFC2373.
> 
>> Analysis of the 64-bit Boundary in IPv6 Addressing
>> https://tools.ietf.org/rfc/rfc7421.txt

Which says:
"The first purpose of this document is to explain the
advantages of the fixed IID length.  Its second purpose is to
analyze, in some detail, the effects of hypothetically varying the
IID length."

I suggest that everybody reads the whole RFC, which does indeed
cover those points. The historical reasons why we chose 64 are
somewhat irrelevant today.

    Brian
 
> 
> I'll make an observation that one of the primary reasons given is the now deprecated EUI64 addressing model for SLAAC.
> Also there is mention of "but there sooooo many addresses, we can't possibly run out". I don't have a crystal ball, in much the same way that all those decades ago, those designing IPv4 didn't have a crystal ball.
> 
> So it appears to me that the basis of a fixed /64 comes down to :
> 
> 1) A now deprecated addressing method requires it
> 2) Based on what we know now we can't see things ever running out
> 3) If any but /64 is used, then some things (implementations) may break.
> 
> So isn't the logical route to say that all implementations must support arbitrary prefix lengths - that avoids breakage when (and I suspect in the real world it will be when, rather than if) they meet something other than /64 ?
> Something that handles arbitrary prefix lengths can handle 64+64, the reverse isn't true if it expects 64+64 and is thrown something else.
> 
> That and removing references to fixed 64 bit boundaries where they aren't necessary. Noting that allowing plenty of space for randomisation for security by obscurity isn't a technical limitation as such - it's merely a best practice.
> 
> And finally. There has been mention in here in the past about not preventing flexibility in the future with things no-one has yet thought of. Yes the numbers are huge, but as I said, I don't have a crystal ball.
> 
> And the argument about not having to work out prefixes/masks/etc is only partly true - and assumes that no-one would ever have to work with anything but /64. It could well lead to people who CANNOT work with anything else, in the same way that many people cannot work with anything but /24 in the IPv4 world.
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>