Re: the race to the bottom problem

[Gyan Mishra <[e-mail]>]

All,

I will be adding a  "race to the bottom" slide to the v6ops deck as that
was a fairly contentious debate and I think you really need to understand
the internet routing architecture to see why there is not a race to the
bottom.  There are two sides to this so we would address both sides.

On side we have  the longer prefix discussion and the "race to bottom" fear
that ISPs will allocate /128.

The other side of this is address size allocation and being able to
allocate shorter prefixes like a /48 per human.

As the Global unicast space 2000::/3 is split between the RIRs and then the
ISPs get their allocation.  Because the allocations are block wise
allocations and not linear even though you have 35 trillion in 2000::/3
that is not what the ISPs are using to service millions of customers.   So
you have to think of it from a service provider allocation perspective and
that gets fairly complicated since you have to large buckets of
subscribers  broadband and cellular.

This will all be addressed in the slide deck on v6ops.

Thank you

Gyan




On Tue, Nov 10, 2020 at 4:50 AM <[e-mail]> wrote:

> > > 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
> >
> > I suspect you find the RA mechanism which assigns prefixes to a link
> simpler to use because that configuration information is tied to the
> lifetime of that particular link.
> > That premise does not hold when you are delegating address space to a
> network behind that link.
> >
> > If you were taking that approach, it would imply ephemeral addressing
> and flash renumbering.
> >
> > Yes, that is the case of the deployment today. I am simply looking to
> give < 64 instead of = 64, that is an improvement that is achievable
>
> If your "yes" was to "ephemeral addressing"...
> Not saying we shouldn't do it. But that has massive ramifications for all
> applications.
>
> It moves IP mobility to the transport or application layer. And would
> require something like MP-TCP or a new session layer.
>
> I'm also unsure if the network configuration protocols HNCP and ND would
> work.
> You would essentially get renumbered any time the cellular connection to
> the network flap, right? ;-)
>
> Best regards,
> Ole
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>


-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD