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

[Gyan Mishra <[e-mail]>]

On Sat, Nov 7, 2020 at 2:30 AM Brian Carpenter <[e-mail]>
wrote:

> On Sat, 7 Nov 2020, 19:34 Gyan Mishra, <[e-mail]> wrote:
>
>>
>>
>> On Fri, Nov 6, 2020 at 3: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.
>>>
>>> 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.
>>
>>
>>    Gyan> I am not sure I understand the comment of pushing >64 subnet
>> prefixes out into the wild as if by doing so we are breaking IPv6.  Also
>> can you enlighten me on the history of another instance where a similar
>> apples for apples comparison where something similar was done by ISPs?
>>
>
> Yes, it was called IPv4 and the rise of NAT was the result.
>


    Gyan> The big difference and it does not make it an accurate comparison
or analogy is that with IPv4  there  was a real fear of address space
exhaustion, which we know many many  years when broadband become  common
place.  You can’t say the same for IPV6 that address space exhaustion is
going to occur ever just given the many more bits v6 is exponentially
larger space then IPv4 and there is no publication that shows data based on
usage the IPV6 has any fear of exhaustion.

The ISPs for IPV4 were justified to do what they did to shrink the
allocation down and  created the NAT interface overload standard 1 to many
port address translation now port forwarding standard, because there was a
REAL fear of IPV4 exhaustion which has happened and we knew then what it a
reality now.

We need a real data point to make the race to the bottom a valid conclusion
that occur and not just a theoretical possibility,
.

>
> Regards
>     Brian
>     (via tiny screen & keyboard)
>
>
>
>> So once the code is there it is only in theory that the race to the
>> bottom will be used by providers once enabled.  We have a BCOP RIPE-690
>> which would still apply to broadband carriers recommendation of /56 or
>> larger and with 3GPP mobile handset a /64.
>>
>> If we have expect that operators to not follow BCOP why have a BCOP.
>>
>> Could we not have an IPv6 allocation guideline for mobile operators to
>> support a minimum allocation of /64 similar to RFC 3177 or RFC 6177.  What
>> good is an IETF protocol specification if it is not followed by operators.
>>
>> Bourbaki draft states that free BSD ships with SLAAC of any length.  That
>> is a good point duly noted by the draft.
>>
>> So in theory if router manufacturers decided they could ship code now
>> that supports any prefix length and Free BSD and their maybe other OSs out
>> there that may work.
>>
>> Bourbaki draft is actually referenced in both of our drafts and Bourbaki
>> draft clearly recommends any IID length.
>>
>> Introduction:
>>
>>    Over the history of IPv6, various classful address models have been
>>
>>    proposed, none of which has withstood the test of time.  The last
>>    remnant of IPv6 classful addressing is a rigid network interface
>>    identifier boundary at /64.  This document removes the fixed position
>>    of that boundary for interface addressing.
>>
>>
>> 5 <https://tools.ietf.org/html/draft-bourbaki-6man-classless-ipv6-05#section-5>.  Recommendations
>>
>>
>> Note that OpenBSD ships with SLAAC for lengths longer than /64.
>>
>>
>>    Nonetheless, there is no reason in theory why an IPv6 node should not
>>    operate with different interface identifier lengths on different
>>    physical interfaces.  Thus, a correct implementation of SLAAC must in
>>    fact allow for any prefix length, with the value being a parameter
>>    per interface.  For instance, the Interface Identifier length in the
>>    recommended (see [RFC8064 <https://tools.ietf.org/html/rfc8064>]) algorithm for selecting stable interface
>>    identifiers [RFC7217 <https://tools.ietf.org/html/rfc7217>] is a parameter, rather than a hard-coded value.
>>
>>
>>
>>
>>
>>>
>>>    Brian
>>>
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> [e-mail]
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>>
>> --
>>
>> <http://www.verizon.com/>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions A**rchitect *
>>
>>
>>
>> *M 301 502-134713101 Columbia Pike
>> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+Silver+Spring,+MD?entry=gmail&source=g>*Silver
>> Spring, MD
>> <https://www.google.com/maps/search/13101+Columbia+Pike%C2%A0+Silver+Spring,+MD?entry=gmail&source=g>
>>
>> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *



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