Re: the race to the bottom problem

[Alexandre Petrescu <[e-mail]>]

Le 08/11/2020 à 22:10, Joel M. Halpern a écrit :
> The reason I asked about DHCP being broken is that some of the 
> earlier messages in the thread seemed (and I may have been 
> misreading) to say "some operators can't use DHCPv6" rather than 
> "some operators do not want to use DHCP, including almost all mobile 
> operators".

I agree.  In the discussions, DHCPv6-PD comes into the picture whenever
a hotspot-like, or 'stub network' or vehicle network is given as a use case.

Some operators do DHCPv6-PD for mobile phones but no mobile phone does
DHCPv6-PD because their modems dont allow for it.  That puts DHCPv6-PD
out of the discussion.

DHCPv6-PD has two entities: the Server and the Client.  Putting a Server
in place is not sufficient to mean that DHCPv6-PD works.

A same operator with DHCPv6-PD working ok with their CPEs does not mean
that same DHCPv6-PD works ok for their smartphones.  Even if it's a same
operator.

> The former statement is one where we as the IETF could look at the 
> problems and see if there was something to fix.

I think at IETF one couldnt solve the DHCPv6-PD lack of support in
Brandname modems.

As much as we cant request operators to give /56s to smartphones we cant
request modem manufacturers to implement protocol DHCPv6-PD either (not
even to let it through).

> The later statement is a not unreasonable policy statement that I am
> now trying to work with.

You are trying to formulate a policy statement?

Alex

> 
> Yours, Joel
> 
> On 11/8/2020 3:57 PM, Alexandre Petrescu wrote:
>> 
>> 
>> Le 08/11/2020 à 02:08, Joel M. Halpern a écrit :
>>> I follow most of your reasoning, but I am missing on critical 
>>> step. Can you please explain how / why / in what fashion DHCPv6 
>>> pd is broken?
>> 
>> Joel,
>> 
>> Allow me a question: I do not know why you ask the question of 
>> DHCPv6-PD brokenness in this context?
>> 
>> The race to the bottom problem might appear if the IID length is 
>> permitted to be of length 63.  Today 63, tomorrow 62, and so on 
>> down to the bottom.
>> 
>> That problem is on SLAAC, not on DHCP.
>> 
>> I would like a solution to the problem of mobile hotspots by using 
>> SLAAC with IID 63 on the Ethernet interface.  It's not a DHCP 
>> problem.  It's not an operator problem (some).
>> 
>> Bringing DHCPv6-PD in the figure is of no relevance, here, I 
>> think.
>> 
>> One cant expect mobile operators to use DHCPv6-PD, and, even if 
>> they did, there would still be race to the bottom problems.  They 
>> could use DHCPv6-PD as well to hand out /63 today, /64 tomorrow, 
>> /65 later, and so on down to the bottom.
>> 
>> THat is why I ask the above.
>> 
>> Alex
>> 
>>> Just saying ~mobile operators chose not to use it~ does not give 
>>> us any information to judge what solutions are likely to be 
>>> workable.
>>> 
>>> I will also note that even if mobile operators would have good 
>>> reason to use a longer prefix system, and would not abuse it, I 
>>> am not so sure the same can be said about fixed operators.  If 
>>> your claim is that DHCPv6 PD is broken for them too, then 
>>> explaining why and how becomes more important for us to 
>>> understand the situation.
>>> 
>>> Yours, Joel
>>> 
>>> On 11/7/2020 8:00 PM, Ca By wrote:
>>>> 
>>>> 
>>>> On Sat, Nov 7, 2020 at 4:00 PM Joel M. Halpern 
>>>> <[e-mail] <mailto:[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.
>>>> 
>>>> 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.
>>>> 
>>>> 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] <mailto:[e-mail]> Administrative 
>>>>> Requests:
>>>> https://www.ietf.org/mailman/listinfo/ipv6 
>>>> <https://www.ietf.org/mailman/listinfo/ipv6>
>>>>> 
>>>> --------------------------------------------------------------------
>>>>
>>>>
>>>>
>>>>  
>>>> --------------------------------------------------------------------
>>>>
>>>>
>>>> 
IETF IPv6 working group mailing list
>>>> [e-mail] <mailto:[e-mail]> Administrative Requests: 
>>>> https://www.ietf.org/mailman/listinfo/ipv6 
>>>> <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 
>> --------------------------------------------------------------------