Re: draft-bourbaki-6man-classless-ipv6-00

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

On 14/06/2017 22:12, Lorenzo Colitti wrote:
> On Wed, Jun 14, 2017 at 6:59 PM, Peter Hessler <[e-mail]> wrote:
> 
>> I'm already running non-/64 subnets on my personal networks.  I'm also
>> running non-/64 subnets on my $work networks.
>>
>> mandating /64 subnets in the _architectural specification_ is a bug,
>> period.
>>
>> IPv4 got rid of classful subnets in 1993, IPv6 can join the last century
>> as well.
>>
> 
> Brian (and everyone on this thread, really): QED.

QED indeed, if the proposition to be proved is that a rigid boundary
is not required.

> Peter, thanks for writing this email so clearly. I think we now have a
> clear example of what some operators will feel encouraged to do if we
> change "is /64" to "should be /64". With the the current state of affairs,
> such networks happen to work but are not guaranteed to interoperate, and
> host implementations are not required to work on them. If we change the
> standards to admit that subnets may be non-64 bits, there will be pressure
> on implementations to conform.

I think that portability out of the box is a much stronger argument. Peter
has chosen to hand-craft his networks. Most people (99.99%) simply unwrap
their new device, ignore the "quick start" guide, and switch it on. There
is an enormous market incentive for that to work 100% of the time, which is
an enormous incentive to stick with /64.
 
> Even if this sort of opinion were a minority opinion among network
> operators, it is the nature of networking software development that host
> implementations adapt to the lowest common denominator. Let's not do that
> here. There is no technical reason to do so.
> 
> This is exactly the sort of scarcity thinking that the 64-bit boundary is
> intended to avoid. 

Not to mention the late lamented /48 recommendation to ISPs. Again,
nobody is trying to sabotage /64 as the norm for SLAAC networks, and
nobody is trying to sabotage SLAAC as the norm for plug and play.

> Let's ensure that such limitations - which as Peter
> says, belong to the last century - stay in the last century and do not
> enter this one.

I agree. But at the same time we need to be honest in our specs. RFC4291
does not describe the deployed architecture accurately, which is why
we have to fix it if we're serious about Internet Standard status.

   Brian