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

[Mark Smith <[e-mail]>]

On Sat, 7 Nov 2020 at 10:35, Ca By <[e-mail]> wrote:
>
>
>
> On Fri, Nov 6, 2020 at 3:17 PM Mark Smith <[e-mail]> wrote:
>>
>>
>>
>> On Sat, 7 Nov 2020, 07:09 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.
>>
>>
>>
>> The current bottom is a single /64.
>>
>> Any provider who is only giving out a single /64 to customers who might or will need more than one /64 has already raced to the current bottom.
>>
>> A "deeper bottom" or longer default allowed prefix length will just facilitate further racing to the deeper bottom. It won't encourage giving out more than one /64 for those who might need them; it'll do the opposite.
>>
>> The pain should to be put where it is caused, onto the providers who should be giving out multiple /64s to their customers.
>>
>> Regards,
>> Mark.
>
>
> Why are the isps not giving more than one 64 ?
>
> Is it because the ietf made it hard and dhcp-pd is unworkable ,

There are multiple production residential deployments of DHCPv6-PD.

I worked on one that was deployed in 2010. I then used it for the next
8 years, and only moved away to another provider (and employer) where
it is in beta.

Telstra here in Australia have also been deploying it for a number of
years in production.

Sky in the UK have deployed PD to 5 million subscribers.

PD is very workable, and a number of people have made it work.

> especially in mobile ?
>

Why is that?

Doesn't 3GPP Release-10 specify PD support?


> Yes
>
> So what will the  ietf do? Well, we had multiple solutions that are equivalent to cutting off one’s nose to spite the face
>

What are these multiple solutions?

PD was the only solution until RFC7278, and I think that's only needed
because mobile devices have for some reason not been treated as an
ordinary portable IPv6 host, and a 3G link not being treated as just
another type of link-layer. Things would be a lot simpler if all that
existed IPv6 over 3G is a short IPv6-over-foo link-layer RFC, and the
upper layers were covered by the existing and generic IPv6 node and
host RFCs.

Regards,
Mark.


>
> CB
>>
>>
>>
>>>
>>> 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
>> --------------------------------------------------------------------