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

[Gyan Mishra <[e-mail]>]

On Fri, Nov 6, 2020 at 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.


     Gyan> How is removing the archaic 64 bit boundary breaking IPV6 in a
fundamental way.

Another way to look at is that SLAAC has been broken Day 1 in a fundamental
way in that  interoperability hosts configured with static or dhcpv6 can
support any prefix length but due to the fact that SLAAC cannot support any
prefix length is has literally shackled static and dhcpv6 addressing to
only use the fixed 64 bit IID so that all the addressing methods are
 interoperable on the same subnet.

So in my mind SLAAC fixed IID has really made it difficult to change host
subnet sizing and we are stuck with /64 host subnet for any IPV6 deployment.

So in my mind SLAAC today is fundamentally broken.

To that end I can see when RFC 4291 was written we had modified EUI64 mac
based IID but once random IID came around with RFC 4941 privacy extension
and RFC 7217 stable IID the fixed SLAAC IID should have been eliminated
from the IPv6 addressing specification.

>
>
> 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://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> 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 *Silver Spring, MD