DoD IP Space

Ca By cb.list6 at gmail.com
Wed Feb 10 13:56:24 UTC 2021


On Wed, Feb 10, 2021 at 5:50 AM Bjørn Mork <bjorn at mork.no> wrote:

> Ca By <cb.list6 at gmail.com> writes:
>
> > On Wed, Feb 10, 2021 at 4:32 AM Valdis Klētnieks <
> valdis.kletnieks at vt.edu>
> > wrote:
> >
> >> On Wed, 10 Feb 2021 04:04:43 -0800, Owen DeLong said:
> >> > Please explain to me how you uniquely number 40M endpoints with
> RFC-1918
> >> without running out of
> >> > addresses and without creating partitioned networks.
> >>
> >> OK.. I'll bite.  What network design needs 40M endpoints and can't
> tolerate
> >> partitioned networks?  There's eyeball networks out there that have that
> >> many
> >> endpoints, but they end up partitioned behind multiple NAT boxes.
> >>
> >>
> > Why would you assume partitioning is an acceptable design constraint ?
> >
> > I don’t think the cellular networks in the USA, each with over a 100M
> > subscribers, wants their customers partitioned, and that is why the IMS /
> > SIP on each modern phone is exclusively ipv6, afaik
>
> You don't need to partition the customers to partition the network.
> It's not like any single network entity scales to a 100M sessions in any
> case.  You will need more than one SIP server.
>
> You'll have multiple instances of "that user with 10.10.10.10", but
> that's easily addressed that by including the associated network
> segment.  So you have "that user with 10.10.10.10 in segment A" and
> "that user with 10.10.10.10 in segment B". They can both be part of the
> same customer database or whatever
>
>
> Bjørn


I understand you think it could work that way

I am sharing with you that the gymnastics to make such a kludge work was
reject years ago

The 3 cellular networks in the usa, 100m subs each, use ipv6 to uniquely
address customers. And in the case of ims (telephony on a celluar), it is
ipv6-only, afaik.

I believe you will find similar cases for hyper-scalers like google, fb,
...

CB


>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20210210/309d8e3b/attachment.html>


More information about the NANOG mailing list