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

On Sat, 7 Nov 2020, 19:34 Gyan Mishra, <hayabusagsm@gmail.com> wrote:

>
>
> On Fri, Nov 6, 2020 at 3:09 PM Brian E Carpenter <
> brian.e.carpenter@gmail.com> 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.

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
>> ipv6@ietf.org
>> 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 *Silver Spring, MD
>
>