Re: the race to the bottom problem

[Alexandre Petrescu <[e-mail]>]

Le 08/11/2020 à 02:55, Mark Smith a écrit :
> On Sun, 8 Nov 2020 at 12:01, Ca By <[e-mail]> wrote:
>> 
>> 
>> 
>> On Sat, Nov 7, 2020 at 4:00 PM Joel M. Halpern
>> <[e-mail]> wrote:
>>> 
>>> I am not sure what data you are looking for Nick. By definition,
>>> no one complying with the RFCs is giving out prefixes longer than
>>> /64. By observation, folks are giving out /64s, when we would
>>> prefer they gave out /56 or even shorter. Given that there are
>>> policy statements from various groups about giving out shorter,
>>> adn those are being ignored, something is causing that. There may
>>> be multiple causes.
>>> 
>>> History does tell us that ISPs give out very long prefixes even
>>> when they do not need to.
>>> 
>>> Since there appears to be know way to observe a trend past /64,
>>> we have to look to history and analogy for data.  History is
>>> data.  We can argue about whether it is relevant data.  But it is
>>> all the data we have on the topic.
>> 
>> 
>> History tells us that ipv4 was scarce so people conserved
>> addresses.
>> 
>> Operators have unlearend that lesson but the ietf has not. And so,
>> ietf people think operators are trying conserve addresses, this is
>> not true. Stop saying it. Stop saying “race to the bottom”, it does
>> not mean anything.
>> 
> 
> So you're saying this 33% has gone to zero in the past 4 years?
> 
> "With regards to what prefix is allocated for customers’ LANs, 22%
> of the respondents indicated that they are using a /48, 35%
> indicated they are using a /56, 33% a /64 and 10% other sizes (among
> them, a /60, a /62, a /57, a /127 and a /128). "
> 
> "IPv6 deployment survey: the results" 
> https://blog.apnic.net/2016/11/14/ipv6-deployment-survey-results/
> 
> 
>> The current and future issue is that the mechanics of providing n
>> number of /64 is broken, dhcp pd is not being deployed in Mobile.
>> Accept reality. Mobile devices dont support it. Mobile networks
>> dont deploy it.
>> 
> 
> You're not explaining why it hasn't been deployed. What are the 
> problems with DHCPv6-PD that are unique to mobile networks that
> don't exist in large scale residential broadband networks that have 
> successfully deployed PD at scale with /56s or shorter?

There are some differences.

The CPE devices are all entirely controlled by their ISPs.  I cant log
into them.  The smartphones are all mandated by legislation to allow
their owners to log into them.

I suspect (some humans at some computers at some) operators protect
themselves against malicious smartphone owners by retaining closeness
and onwership of one part of the smartphone - the modem.  I can login
into the modem OS (a sub-OS connected to Android)) even though I can
login on Android.  That sub-OS of the modem manufacturer in 3GPP devices
does not do DHCPv6-PD and even blocks it.

If one wants to understand why such modem does not do DHCPv6-PD and
blocks it one has to get in touch to that modem manufacturer and ask the
question.

For my side, I did, with backing from operator.  I held long
discussions.   It all boils down to this: 'the IPv6 design is SLAAC and
no DHCP'.

One may want to interpret that phrase in many ways.

One might speculate of why that manufacturer maintains position against
DHCP.  It's not only they are against DHCPv6-PD but against DHCP
altogether.  The reason - I speculate - might have to do with IPR.  IPR
is present somehow on DHCP but absent somehow from SLAAC.  Add to that
the sensitivity of that manufacturer to IPR aspects in 3GPP, and it may
consitute a valid explanation.

But I am not sure this is the kind of answer you are looking for when
asking what are the problems of DHCPv6-PD unique to mobile as opposed to
household networks.

Alex

> 
>> So, the problem statement in mobile is - how do we better make use
>> of the /64 that is provided or get more /64s in an effective way
>> 
>> No, yelling at operators and making punitive standards will not
>> help.
>> 
>>> 
>>> 
>>> Yours, Joel
>>> 
>>> On 11/7/2020 6:56 PM, Nick Hilliard wrote:
>>>> Mark Smith wrote on 07/11/2020 23:41:
>>>>> They're not assumptions if you have first hand experience of
>>>>> the history of the rise of IPv4 address conservation
>>>>> measures, and can remember what IPv4 addressing practices and
>>>>> mindsets were before IPv4 addresses became precious.
>>>> 
>>>> btdt, thanks.
>>>> 
>>>>> The address conservation mindset is even more distinct and 
>>>>> distinguishable when you've actually taught it through
>>>>> teaching IPv4 VLSM in the mid 90s.
>>>> 
>>>> this looks very much like an appeal to authority.  We're better
>>>> than this.
>>>> 
>>>> So once again, let's try to keep the topic about actual data
>>>> concerning ipv6 and this "race to the bottom" as it relates to
>>>> ipv6.
>>>> 
>>>> Nick
>>>> 
>>>> --------------------------------------------------------------------
>>>>
>>>> 
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 
>>> --------------------------------------------------------------------
>>
>>
>>> 
--------------------------------------------------------------------
>> 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 
> --------------------------------------------------------------------
>