Re: the race to the bottom problem

[Gyan Mishra <[e-mail]>]

On Fri, Nov 6, 2020 at 9:27 AM Gyan Mishra <[e-mail]> wrote:

>
>
> On Fri, Nov 6, 2020 at 9:14 AM Alexandre Petrescu <
> [e-mail]> wrote:
>
>>
>>
>> Le 06/11/2020 à 11:36, Fernando Gont a écrit :
>> > On 6/11/20 07:04, Alexandre Petrescu wrote:
>> >> 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".
>> >
>> > Then we'd need an RFC for formally creating the Internet
>> > police/militia. (possibly a very bad timing for an already bad
>> > idea).
>>
>> So we need to attenuate that 'strictly prohibited' wording and improve a
>> way forward.
>
>
>      Along with updating the verbiage in the draft we can create a 3GPP
> mobile handset address allocation draft that that recommends only /64
> allocation.
>
> A RIPE BCOP may help as well for mobile operators.
> This is all a theoretical fear that operators will race to the bottom, but
> until we remove the 64 bit boundary, we don’t know for sure either way.  My
> thoughts are that large operators such as Verizon as I can influence the
> stance Verizon takes on allocation guidelines, that they will not change
> and will remain at /64.  Verizon as a major stakeholder can influence other
> operators as well on the stance. The complexity of management vlsm is
> allocation for operators is not worth the saving and what is the real
> savings.  Most operators have massive IPv6 assignments they got decades ago
> so they never have to go back to the well again for more.
>


     As mentioned on this thread m, the original IPv6 underpinnings to
fixed IID was the modified EUI64 Mac based generation schema, but now with
the recommend random IID generation for privacy RFC4941 or RFC 7217 stable
based which are both now the industry standard we have in reality been
almost there as far and elimination of the 64 bit boundary and all that is
left is updating RFC 4291 verbiage.

I think at this point the only thing holding us back is the race to the
bottom theoretical fears which I think are disconnected from reality as I
don’t think it will happen.

>
>>
>> Alex
>>
>> >
>> > Thanks,
>
>
>> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
>
>
> *M 301 502-134713101 Columbia Pike *Silver Spring, MD
>
> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD