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

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:

http://www.quickanddirtytips.com/education/math/how-many-grains-of-sand-are-on-earth%E2%80%99s-beaches

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).

To count the available /128s, multiply again by 18x10^18.

Or to put it another way, with only about 2430 addresses per /64 subnet,
and 2.3x10^18 subnets, we could address every grain of sand. With that
degree of sparseness, DAD will hardly blink and the grains of sand can
feel sure of their privacy, if they care to use RFC4941.

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.

   Brian

** Powers of 2 are at https://en.wikipedia.org/wiki/Power_of_two#The_0th_through_95th_powers_of_two
> 
> On 5 August 2017 at 19:58, Simon Hobson <linux@thehobsons.co.uk> wrote:
>> Mark Smith <markzzzsmith@gmail.com> 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
>>
>> 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
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> 