Re: the race to the bottom problem

[Ca By <[e-mail]>]

On Sat, Nov 7, 2020 at 6:43 PM Joel M. Halpern <[e-mail]> wrote:

> 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



Joel,

Fully agree.

RA prefix information can be set to any number between 0 and 128

But, 3gpp enshrined it to be 64

https://tools.ietf.org/html/rfc6459#section-5.2

Let’s change and and make it so the UE to slice up a prefix into multiple
downstream /64s



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