Re: the race to the bottom problem

[Alexandre Petrescu <[e-mail]>]

I have been reminded in private about 'race to the bottom'.

In the Variable SLAAC solution draft we do touch on the problem:

> The "race to the bottom problem" - is the problem where allowing 
> prefixes longer than 64 to be used in SLAAC will lead to 65, 66 and 
> so on, up to 127 and 128 allocations.  At that point the bottom
> would be reached and thus impossible to extend the network further.

A solution is then proposed in section 8 titled "Greater than 64 bit
prefix usage by ISPs is strictly prohibited".  And there we propose a
new bit - bit 'S'.

Maybe it is better to move the problem description into the Variable
SLAAC Problem Statement draft.

Alex

Le 05/11/2020 à 17:49, Alexandre Petrescu a écrit :
> 
> Le 04/11/2020 à 09:45, [e-mail] a écrit :
>> Gyan,
>> 
>>> Are there any of the problems/use-cases that cannot be solved by
>>>  assigning a shorter prefix than /64 to the end-user networks?
>>> 
>>> Gyan> The issue here with 4G providers to be able to force 
>>> providers to go with a shorter prefix is impossible and similar 
>>> to the issue we see with the v6ops flash renumbering issue and 
>>> even in light of BCOP RIPE-690 that broadband operator’s PD 
>>> allocations is /64 and not /56 as recommended in BCOP and due to
>>>  the impact of flash renumbering events we are now changing the 
>>> VL PL to short timers to age our the stale prefix during a 
>>> renumbering event.  So the standard on 4G and as it is the same 
>>> standard for 5G handsets allocation, a /64, and 4G and even 5G 
>>> operators for mobile handset provisioning do not plan to make it
>>>  a shorter prefix.  So either customers end up suffering with 
>>> flash renumbering events or you update the standard. Same issue 
>>> we are faced with here with wireless providers and forcing them 
>>> to dole out shorter prefix.
>> I don't understand the coupling you make between the 64 bit 
>> boundary and flash renumbering.
>> 
>>> Fixed 5G replacement for broadband I mentioned, not to be 
>>> confused with 5G mobile handset, would follow BCOP RIPE-690 and I
>>> believe will go in with larger allocation like a /56 or larger.
>>> So the fixed 5G network slicing how it comes into play as a value
>>> proposition and massive benefit to customers, is it can now have
>>> the front haul 5G to tower and back haul tower to core now be
>>> provisioned to the fixed 5G with a normal BAU slice template for
>>> normal traffic and at the same time separate slices for special
>>> Enhanced VPN over SRv6 core SR-TE steered with dedicated
>>> resources and traffic  isolation and special QoS prioritization
>>> for applications such as IOT, E911 emergency services, or
>>> utilities etc.
>>> 
>>> https://www.internetsociety.org/blog/2017/10/ipv6-prefix-assignment-bcop-published-ripe-690/
>>>
>>>
>>> 
>>> 
>> OK, so the problem is: "How do you connect an end-user network with
>> multiple links to a provider who only allocates a /64 to the 
>> site.".
>> 
>> There is a conundrum here. A reason for the 64-bit boundary is that
>> it forces the provider to give at least a /64. That design decision
>> seems to have had the intended effect. You don't see any providers
>> assigning less address space than the /64.
>> 
>> If we were to relax that limitation, then there is a fear that 
>> providers will start assigning fewer addresses to end-users. Down 
>> to a single address like we see in IPv4.
>> 
>> The conundrum then is: How do we ensure providers allocate at least
>> a /64 of address space to end-users, and at the same time allow
>> end-users to extend a network with only a /64 assigned to it.
> 
> 
> I want to not forget to If there is a future version of this draft 
> then I want to make sure to add the problem of "Race to the Bottom" 
> in the Variable SLAAC Problem Statement draft.
> 
> We could also try to answer how one could make sure the providers 
> allocates _at least_ a /64 to an end user.  I think there is an RFC 
> for that, that we might cite.  And a RIPE note too.
> 
> Alex
> 
>> 
>> Answer that and we can make progress.
>> 
>> Best regards, Ole