Re: the race to the bottom problem

["Joel M. Halpern" <[e-mail]>]

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