Re: the race to the bottom problem

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

If I understand you, you are not saying DHCPv6 is broken.  You are 
saying the 3GPP chose not to try to use it.  They had to develop a new 
address allocation mechanism for IPv6, and chose to use RA / SLAAC (a 
defensible choice) instead of DHCPv6.

If so, and if the goal is to allow subtending devices and networks more 
cleanly, and if the desired approach is to modify RA messages, then why 
not modify them to make clear to the UE when it is allowed to 
sub-allocated /64s (or shorter) out of something shorter than /64. 
Sure, it is abusing RA for a routing allocation.  But so is the approach 
you want.  And it avoids (or at least makes harder) creating any risk of 
misbehavior by networks using the extension in ways that were not intended.

Maybe there is even some other, better solution.  But let's not assume 
that we need to break the rules to build working networks.

Yours,
Joel

On 11/7/2020 9:31 PM, Ca By wrote:
> 
> 
> On Sat, Nov 7, 2020 at 5:56 PM Mark Smith <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>     On Sun, 8 Nov 2020 at 12:01, Ca By <[e-mail]
>     <mailto:[e-mail]>> 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.
>      >
> 
>     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/
>     <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?
> 
> 
> Wireline broadband (pon, docsis) has an assumption that there is a dhcp 
> server present as a fundamental part of the architecture in ipv4. So 
> there it is in ipv6.
> 
> DHCP is generally not used in mobile. There is no such function bake 
> into the architecture to evolve to support PD.  Could it be added as a 
> greenfield ? Yes. Will it? Probably not, and we have 10 years of proof.
> 
> 
> 
> 
>      > 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] <mailto:[e-mail]>
>      > Administrative Requests:
>     https://www.ietf.org/mailman/listinfo/ipv6
>     <https://www.ietf.org/mailman/listinfo/ipv6>
>      > --------------------------------------------------------------------
>