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

["STARK, BARBARA H" <[e-mail]>]

> The first sentence is taken out of the context. I actually said:
> 
> "- There is no race to the bottom. We are not trying to solve ISP problem by
> allowing longer than 64bit prefixes,
> - It is not about restricting the ISP prefix assignments to minimum one 64bit
> prefix, by imposing 64bit SLAAC prefix limitation on the clients,
> - Minimum of one 64bit prefix limitation should be imposed by other
> network elements, rather than clients. Edge routers can block >64bit
> prefixes,"
> 
> because I believe the race to the bottom can be addressed by other network
> elements (e.g. CE), not only clients.
> Dusan

I agree. The "race to the bottom" argument is a 100% FUD argument. As such, it
can never be disproven (or proven -- unless the opportunity were to actually exist).
IMO, at this point in IPv6 deployment, the 64-bit "bottom" boundary is extremely 
well established. With a few additions of requirements to CE router and BNGs,
I think it would be easy to codify this boundary in telco network equipment.
I suspect the cable ISPs would be willing to do the same (in their specs for similar
network elements). Maybe 3GPP, too.

There are tremendous advantages inside LANs to being able to more fully utilize a /64
(not the least of which is that -- as mentioned -- many ISPs are just giving out a single /64).
We're penalizing LAN environments and end users for the sake of FUD.
Barbara

> 
> On 2020-11-06, 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.
> 
> 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://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__
> ;!!BhdT!2XzWpikEpx3h67qZpyigLfVmqPEiTRYujd4KwnCkUjuVR7K7PTHtDvK5E
> H5q-w$
> > --------------------------------------------------------------------
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests:
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__
> ;!!BhdT!2XzWpikEpx3h67qZpyigLfVmqPEiTRYujd4KwnCkUjuVR7K7PTHtDvK5E
> H5q-w$
> --------------------------------------------------------------------