Re: [**EXTERNAL**] Re: the race to the bottom problem

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

On 09-Nov-20 04:07, STARK, BARBARA H wrote:
>> The first sentence is taken out of the context. I actually said:
>>
>> "- There is no race to the bottom. We are not trying to solve ISP problem by
>> allowing longer than 64bit prefixes,
>> - It is not about restricting the ISP prefix assignments to minimum one 64bit
>> prefix, by imposing 64bit SLAAC prefix limitation on the clients,
>> - Minimum of one 64bit prefix limitation should be imposed by other
>> network elements, rather than clients. Edge routers can block >64bit
>> prefixes,"
>>
>> because I believe the race to the bottom can be addressed by other network
>> elements (e.g. CE), not only clients.
>> Dusan
> 
> I agree. The "race to the bottom" argument is a 100% FUD argument. 

I don't agree. The documented "bottom" used to be /48. It was entirely
due to pressure from operators, and the short-sighted choice made by
3GPP, that it was changed to /64. There was justified fear when we published
RFC3177 in 2001; there was no room for uncertainty or doubt when we bowed to
reality and published RFC6177 in 2011. We've given enough ground on this.
Also, /64 is burned into more than 3 billion devices at this point, which
is a pretty strong commercial and operational argument.

There is no need to split /64s, when it is trivial to split /56s or /48s,
of which we have trillions to waste.

Just get 3GPP to change its /64 rule in accordance with RFC6177 and I
suspect that this entire problem will go away.

Regards
    Brian

> As such, it
> can never be disproven (or proven -- unless the opportunity were to actually exist).
> IMO, at this point in IPv6 deployment, the 64-bit "bottom" boundary is extremely 
> well established. With a few additions of requirements to CE router and BNGs,
> I think it would be easy to codify this boundary in telco network equipment.
> I suspect the cable ISPs would be willing to do the same (in their specs for similar
> network elements). Maybe 3GPP, too.
> 
> There are tremendous advantages inside LANs to being able to more fully utilize a /64
> (not the least of which is that -- as mentioned -- many ISPs are just giving out a single /64).
> We're penalizing LAN environments and end users for the sake of FUD.
> Barbara
> 
>>
>> On 2020-11-06, 5:11 PM, "Bob Hinden" <[e-mail]> wrote:
>>
>> Brian,
>>
>>> On Nov 6, 2020, at 12:09 PM, Brian E Carpenter
>> <[e-mail]> wrote:
>>>
>>> On 07-Nov-20 03:30, Mudric, Dusan wrote:
>>>> Would it help if the problem statemen clarifies that:
>>>>
>>>> - There is no race to the bottom. We are not trying to solve ISP problem
>> by allowing longer than 64bit prefixes,
>>>
>>> Unfortunately, once you push code allowing >64 subnet prefixes for SLAAC
>> into the wild, you do automatically give ISPs a path to to allocating longer
>> prefixes to customers, and all history tells us that some of them will follow
>> that path.
>>>
>>
>>> Once that code is out there, the race to the bottom is enabled.
>>
>> I fully agree.   And once it is broken, there is no going back.
>>
>> Also, I have yet to see any solution to having a mix of devices on the same
>> link that can only support 64bit IIDs and ones that can support shorter IIDs.  I
>> think there is an impossible transition problem.
>>
>> Lastly and probably the most important, I have not seen a convincing
>> argument why this is necessary.   The risk is breaking IPv6 in a fundamental
>> way.
>>
>> Bob
>>
>>
>>>
>>> Even draft-bourbaki-6man-classless-ipv6 doesn't recommend changing the
>> /64 default for SLAAC. (If it did, my name would not be on that draft.)
>>>
>>>   Brian
>>>
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> [e-mail]
>>> Administrative Requests:
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__
>> ;!!BhdT!2XzWpikEpx3h67qZpyigLfVmqPEiTRYujd4KwnCkUjuVR7K7PTHtDvK5E
>> H5q-w$
>>> --------------------------------------------------------------------
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests:
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__
>> ;!!BhdT!2XzWpikEpx3h67qZpyigLfVmqPEiTRYujd4KwnCkUjuVR7K7PTHtDvK5E
>> H5q-w$
>> --------------------------------------------------------------------