Mailing List Archive

There's no error code. Customer only sees the message "DRM license resquest failed" on LG TV WebOS 3.8 or above.

Translation “I use a broken GEOIP database that doesn’t handle IPv6 correctly. If you turn off IPv6 then the request will use IPv4 and it may work.”.

Mark

> On 25 Jan 2021, at 01:03, Travis Garrison <tgarrison@netviscom.com> wrote:
>
> I have personally seen the issue with streaming from a Samsung cell phone and the Disney+ app to a Google chrome cast and a regular not-smart TV.
>
> Travis
>
> -----Original Message-----
> From: NANOG <nanog-bounces+tgarrison=netviscom.com@nanog.org> On Behalf Of Doug Barton
> Sent: Friday, January 22, 2021 5:30 PM
> To: nanog@nanog.org
> Subject: Re: DoD IP Space
>
> The KB indicates that the problem is with the "LG TV WebOS 3.8 or above."
>
> Doug
>
> (not speaking for any employers, current or former)
>
>
> On 1/22/21 12:42 PM, Mark Andrews wrote:
>> Disney should hire some proper developers and QA team.
>>
>> RFC 1123 instructed developers to make sure your products handled multi-homed servers properly and dealing with one of the addresses being unreachable is part of that. It’s not like the app can’t attempt to a stream from the IPv6 address and if there is no response in 200ms start a parallel attempt from the IPv4 address. If the IPv6 stream succeeds drop the IPv4 stream Happy Eyeballs is just a specific case of multi-homed servers.
>>
>> QA should have test scenarios where the app has a dual stack network and the servers are silently untraceable over one then the other transport. It isn’t hard to do. Dealing with broken networks is something every application should do.
>>

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

> On Jan 21, 2021, at 14:22 , Randy Bush <randy@psg.com> wrote:
>
>>> I’m sure we all remember Y2k (well, most of us, there could be some
>>> young-uns on the list). That day was happening whether we wanted it to
>>> or not. It was an unchangeable, unmovable deadline.
>>
>> but i thought 3gpp was gong to force ipv6 adoption
>
> let me try it a different way
>
> why should i care whether you deploy ipv6, move to dual stack, cgnat,
> ...? you will do whatever makes sense to the pointy heads in your c
> suite. why should i give them or some tech religion free rent in my
> mind when i already have too much real work to do?
>

Presumably because you have reason to connect to the internet.

Presumably you intend that connection to the internet to be able to reach
a variety of third parties.

As such, there is some reasonable basis for the idea that how third parties
choose to manage their network impacts decisions you need to make about
your own network.

E.G. Facebook has decided to go almost entirely IPv6, yet they maintain an
IPv4 presence on their front-end in order to support users that are victims of
IPv4-only networks and devices. Facebook faces a cost in having to maintain
those services to reach those customers. That cost could be reduced by the
providers in question (and in some cases the device manufacturers) providing
robust IPv6 implementations in their products and services.

Unfortunately, NAT, CGNAT, and IPv4 in general are an unrecognized cost
inflicted on people who are not involved in the decision to implement those
processes vs. deploying IPv6, thus creating. a situation where those who
have deployed IPv6 yet wish to maintain connectivity to those who have not
are essentially subsidizing those who have not in order to maintain that
connectivity.

Now, if the true cost of that were more transparent and the organizations
not deploying IPv6 could be made more aware of the risks of what happens
when a variety of organizations choose to put an end to that subsidy,
it might get more attention at the CxO level. Unfortunately, the perverse
incentives of the market (providers that are willing to offer legacy services
are more likely to retain customers than providers that aren’t) prevent
those paying the subsidy from opting out (at least for now) because the
critical mass of customers still clinging to their legacy networks presumably
comes with a value that exceeds the cost of that subsidy.

There was actually some excellent work done to try and quantify this
in terms of Per User Per Year costs to an average ISP by
Lee Howard: https://www.rmv6tf.org/wp-content/uploads/2012/11/TCO-of-CGN1.pdf

Owen

At the bottom of that page, there is a question “Was this answer helpful.” I clicked NO. It gave me a free form text box to explain why I felt it was not helpful… Here’s what I typed:

The advice is just bad and the facts are incorrect.
IPv6 is not blocking the Disney application. Either IPv6 is broken in the users environment (in which case, the user should work with their network administrator to resolve this) or Disney has failed to implement IPv6 correctly on their DRM platform.

IPv6 cannot "Block" an application.

Turning off IPv6 will degrade several other services and cause additional problems. This is simply very bad advice and shame on Disney for issuing it.

Hopefully if enough people follow suit, Disney will get the idea.

Owen

> On Jan 21, 2021, at 18:29 , Travis Garrison <tgarrison@netviscom.com> wrote:
>
> What's all your opinion when company's such as Disney actively recommend disabling IPv6? They are presenting it as IPv6 is blocking their app. We all know that isn’t possible. Several people have issues with their app and Amazon firesticks. I use my phone and a chromecast and I see the issues when IPv6 is enabled. We are in the testing phase on rolling out IPv6 on our network. All the scripts are ready, just trying to work through the few issues like this one.
>
> https://help.disneyplus.com/csp?id=csp_article_content&sys_kb_id=c91af021dbe46850b03cc58a139619ed
>
> Thank you
> Travis
>
>
>
> -----Original Message-----
> From: NANOG <nanog-bounces+tgarrison=netviscom.com@nanog.org> On Behalf Of Mark Andrews
> Sent: Thursday, January 21, 2021 7:45 PM
> To: Sabri Berisha <sabri@cluecentral.net>
> Cc: nanog <nanog@nanog.org>
> Subject: Re: DoD IP Space
>
> IPv6 doesn’t need a hard date. It is coming, slowly, but it is coming.
> Every data set says the same thing. It may not be coming as fast as a lot of us would want or actually think is reasonable as ISP’s are currently being forced to deploy CGNs (NAT44 and NAT64) because there are laggards that are not doing their part.
>
> If you offer a service over the Internet then it should be available over
> IPv6 otherwise you are costing your customers more to reach you. CGNs are not free.
>
> Mark
>
>> On 22 Jan 2021, at 06:07, Sabri Berisha <sabri@cluecentral.net> wrote:
>>
>> ----- On Jan 21, 2021, at 6:40 AM, Andy Ringsmuth andy@andyring.com wrote:
>>
>> Hi,
>>
>>> I’m sure we all remember Y2k
>>
>> Ah, yes. As a young IT consultant wearing a suit and tie (rofl), I
>> upgraded many bioses in many office buildings in the months leading up to it...
>>
>>> I’d love to see a line in the concrete of, say, January 1, 2025,
>>> whereby IPv6 will be the default.
>>
>> The challenge with that is the market. Y2K was a problem that was
>> existed. It was a brick wall that we would hit no matter what. The
>> faulty code was released years before the date.
>>
>> We, IETF, or even the UN could come up with 1/1/25 as the date where
>> we switch off IPv4, and you will still find networks that run IPv4 for
>> the simple reason that the people who own those networks have a choice. With Y2K there was no choice.
>>
>> The best way to have IPv6 implemented worldwide is by having an
>> incentive for the executives that make the decisions. From experience,
>> as I've said on this list a few times before, I can tell you that
>> decision makers with a limited budget that have to choose between a
>> new revenue generating feature, or a company-wide implementation of
>> IPv6, will choose the one that's best for their own short-term interests.
>>
>> On that note, I did have a perhaps silly idea: One way to create the
>> demand could be to have browser makers add a warning to the URL bar,
>> similar to the HTTPS warnings we see today. If a site is IPv4 only,
>> warn that the site is using deprecated technology.
>>
>> Financial incentives also work. Perhaps we can convince Mr. Biden to
>> give a .5% tax cut to corporations that fully implement v6. That will
>> create some bonus targets.
>>
>> Thanks,
>>
>> Sabri
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
>

His example may have included incompetence. However, it takes longer, but
it is definitely possible to run out of RFC-1918 space with scale and no incompetence.

No rational network will ever be able to put every single /32 endpoint on a host, but
I know of several networks that have come darn close and still run multiple partitioned
RFC-1918 “zones” because RFC-1918 just isn’t enough for them.

The good news is that IPv6 has plenty of addresses available for all of these applications
and there’s absolutely no need for separate private addressing unless you really want it.

Owen


> On Jan 22, 2021, at 14:42 , Izaac <izaac@setec.org> wrote:
>
> On Fri, Jan 22, 2021 at 01:03:15PM -0800, Sabri Berisha wrote:
>> TL;DR: a combination of scale and incompetence means you can run out of 10/8
>> really quick.
>
> Indeed. Thank you for providing a demonstration of my point.
>
> I'd question the importance of having an console on target in Singapore
> be able to directly address an BMC controller in Phoenix (wait for it),
> but I'm sure that's a mission requirement.
>
> But just in case you'd like to reconsider, can I interest you in NAT?
> Like nutmeg, a little will add some spice to your recipe -- but too much
> will cause nausea and hallucinations. It's entirely possible to put an
> entire 192.168.0.0/16 network behind every single 172.16.0.0/12 address.
>
> So, you've already "not at all hypothetical'd" entire racks completely
> full of 1U hosts that are supporting lots of VMs in their beefy memory
> on their two processors and also doing SAN into another universe. Let's
> just magic a rack controller to handle the NAT. We can just cram it
> into the extra-dimensional space where the switches live.
>
> A standard port mapping configuration to match your "blueprint" ought to
> be straight-foward. But let's elide the details and learn by
> demonstration by just using it!
>
> If the Singapore AZ were assigned 172.18.0.0/16.
> And the 7th pod were 172.18.7.0/24.
> And the 12th rack were 172.18.7.12/32.
> We can SSH to the 39th host at: 172.18.7.11:2239
> Which NATs to 192.168.0.39:22 on the 192.168.0.0/24 standard net.
>
> If the Phoenix AZ (payoff!) were assigned 172.22.0.0/16.
> And the 9th pod were 172.22.9.0/24
> And the 33rd rack were 172.22.9.33/32.
> We can VNC to the BMC of the 27th host at: 172.22.9.33:5927.
> Which NATs to 192.168.1.27:5900 on the 192.168.1.0/24 management net.
>
> Let's see. We've met all our requirements, left unused more than 50% of
> the 172.16/12 space by being very generous to our AZs, left unused 98%
> of the 192.168/16 space in each rack, threw every zero-network to the
> wolves for our human counting from 1, and still haven't even touched
> 10/8. And all less than an hour's chin pulling.
>
> Good for us.
>
> --
> . ___ ___ . . ___
> . \ / |\ |\ \
> . _\_ /__ |-\ |-\ \__

WebOS implemented IPv6 in 3.8 IIRC.

Owen


> On Jan 22, 2021, at 15:30 , Doug Barton <dougb@dougbarton.us> wrote:
>
> The KB indicates that the problem is with the "LG TV WebOS 3.8 or above."
>
> Doug
>
> (not speaking for any employers, current or former)
>
>
> On 1/22/21 12:42 PM, Mark Andrews wrote:
>> Disney should hire some proper developers and QA team.
>> RFC 1123 instructed developers to make sure your products handled multi-homed servers properly and dealing with one of the addresses being unreachable is part of that. It’s not like the app can’t attempt to a stream from the IPv6 address and if there is no response in 200ms start a parallel attempt from the IPv4 address. If the IPv6 stream succeeds drop the IPv4 stream Happy Eyeballs is just a specific case of multi-homed servers.
>> QA should have test scenarios where the app has a dual stack network and the servers are silently untraceable over one then the other transport. It isn’t hard to do. Dealing with broken networks is something every application should do.

ROTFL! I’m sorry, but the imagery of people paying rent for a piece of Randy’s mind is just too much :)

> On Jan 21, 2021, at 14:22 , Randy Bush <randy@psg.com> wrote:
>
>>> I’m sure we all remember Y2k (well, most of us, there could be some
>>> young-uns on the list). That day was happening whether we wanted it to
>>> or not. It was an unchangeable, unmovable deadline.
>>
>> but i thought 3gpp was gong to force ipv6 adoption
>
> let me try it a different way
>
> why should i care whether you deploy ipv6, move to dual stack, cgnat,
> ...? you will do whatever makes sense to the pointy heads in your c
> suite. why should i give them or some tech religion free rent in my
> mind when i already have too much real work to do?
>

Owen,

I am genuinely curious, how would you explain the problem, and describe
a solution, to an almost exclusively non-technical audience who just
wants to get the bits flowing again?

Doug
(still not speaking for anyone other than myself)


On 2/5/21 2:25 PM, Owen DeLong wrote:
> At the bottom of that page, there is a question “Was this answer
> helpful.” I clicked NO. It gave me a free form text box to explain why I
> felt it was not helpful… Here’s what I typed:
>
> The advice is just bad and the facts are incorrect.
> IPv6 is not blocking the Disney application. Either IPv6 is broken
> in the users environment (in which case, the user should work with
> their network administrator to resolve this) or Disney has failed to
> implement IPv6 correctly on their DRM platform.
>
> IPv6 cannot "Block" an application.
>
> Turning off IPv6 will degrade several other services and cause
> additional problems. This is simply very bad advice and shame on
> Disney for issuing it.
>
>
> Hopefully if enough people follow suit, Disney will get the idea.
>
> Owen

On Fri, 05 Feb 2021 17:25:34 -0800, Doug Barton said:
> I am genuinely curious, how would you explain the problem, and describe
> a solution, to an almost exclusively non-technical audience who just
> wants to get the bits flowing again?

"The people who did Disney's software wrote it for the Internet protocols
of last century, so it fails with this century's Internet. Adding insult to injury,
the reason you even notice a problem is because it reacts badly to the failure,
because it doesn't even include *last* century's well-known methods of
error recovery".

> On Jan 22, 2021, at 10:28 PM, Valdis Kl?tnieks <valdis.kletnieks@vt.edu> wrote:
>
> And how would you define "fully implement v6", anyhow?

I would define it this way: if something can be done using IPv4, it has an obvious IPv6 counterpart that is usable by the same community to the extent that the community is itself able to use such. Web sites, mail, bandwidth, routing, ROAs, firewalls with appropriate rules, and so on. The problem with my suggested wording is that if one turns IPv4 off, by implication someone turns IPv6 off, and I don't intend that. So reword to make IPv6 the surviving service in some way, and I think you're pretty much there.

On Fri, Feb 05, 2021 at 02:36:57PM -0800, Owen DeLong wrote:
> it is definitely possible to run out of RFC-1918 space with scale and no incompetence.

No, it isn't. It's the year 2021. Stop making excuses.

--
. ___ ___ . . ___
. \ / |\ |\ \
. _\_ /__ |-\ |-\ \__

Please explain to me how you uniquely number 40M endpoints with RFC-1918 without running out of
addresses and without creating partitioned networks.

If you can’t, then I’m not the one making excuses.

Owen


> On Feb 9, 2021, at 15:44 , Izaac <izaac@setec.org> wrote:
>
> On Fri, Feb 05, 2021 at 02:36:57PM -0800, Owen DeLong wrote:
>> it is definitely possible to run out of RFC-1918 space with scale and no incompetence.
>
> No, it isn't. It's the year 2021. Stop making excuses.
>
> --
> . ___ ___ . . ___
> . \ / |\ |\ \
> . _\_ /__ |-\ |-\ \__

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.

On Wed, Feb 10, 2021 at 4:32 AM Valdis Kl?tnieks <valdis.kletnieks@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

Owen DeLong <owen@delong.com> writes:

> Please explain to me how you uniquely number 40M endpoints with RFC-1918 without running out of
> addresses and without creating partitioned networks.
>
> If you can’t, then I’m not the one making excuses.


You added "without ..." and did not explain why. This does look a bit
like an excuse to me. But there is probably some explanation I don't
see.

Why would you not partition the network?


Bjørn

Ca By <cb.list6@gmail.com> writes:

> On Wed, Feb 10, 2021 at 4:32 AM Valdis Kl?tnieks <valdis.kletnieks@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

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

> Ca By <cb.list6@gmail.com> writes:
>
> > On Wed, Feb 10, 2021 at 4:32 AM Valdis Kl?tnieks <
> valdis.kletnieks@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


>

Ca By <cb.list6@gmail.com> writes:

> 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 certainly agree that this is easier and makes more sense. I just
don't buy the "can't be done" wrt using rfc1918.


Bjørn

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

> Ca By <cb.list6@gmail.com> writes:
>
> > 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 certainly agree that this is easier and makes more sense. I just
> don't buy the "can't be done" wrt using rfc1918.
>

Well, it is not rfc1918 that is best invoked here.

May i point you to rfc1925 section 2.3, regarding pigs flying with
sufficient thrust. IPv4 is the pig, and a steam engined fueled by dollars
is the source of thrust

https://tools.ietf.org/html/rfc1925


>
> Bjørn
>

On 2/10/21 5:56 AM, Ca By wrote>
> 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.

So that answers the question of how to scale networks past what can be
done with 1918 space. Although why the phones would need to talk
directly to each other, I can't imagine.

I also reject the premise that any org, no matter how large, needs to
uniquely number every endpoint. When I was doing IPAM for a living, not
allowing the workstations in Tucson to talk to the printers in Singapore
was considered a feature. I even had one customer who wanted the
printers to all have the same (1918) IP address in every office because
they had a lot of sales people who traveled between offices who couldn't
handle reconfiguring every time they visited a new location. I thought
it was a little too precious personally, but the customer is always
right. :)

Sure, it's easier to give every endpoint a unique address, but it is not
a requirement, and probably isn't even a good idea. Spend a little time
designing your network so that the things that need to talk to each
other can, and the things that don't have to, can't. I did a lot of
large multinational corporations using this type of design and never
even came close to exhausting 1918 space.

Doug

On Fri, Jan 22, 2021 at 12:30 PM Izaac <izaac@setec.org> wrote:
> On Wed, Jan 20, 2021 at 02:47:32PM +0100, Cynthia Revström via NANOG wrote:
> > certain large corporations that have run out of RFC1918, etc. space
>
> At what level of incompetence must an organization operate to squander
> roughly 70,000 /24 networks?

Hi Isaac,

None whatsoever. You just have to be really big.

Imagine you're Amazon. You have this insanely large deployment of
servers. Your customers have this virtual concept you've presented
them called a "VPC" but there are no wires or routers. The subnets
only exist as bits in memory. The Virtual Private Cloud is a ruleset
in the network adapter of every physical machine running one of the
VMs that participate in the VPC. A big, flat network where every one
of these servers has a need to talk to every other server that could
possibly be tasked to run a VM in that VPC.

Regards,
Bill Herrin

--
William Herrin
bill@herrin.us
https://bill.herrin.us/

On 2/10/21 19:50, Doug Barton wrote:

>
> I also reject the premise that any org, no matter how large, needs to
> uniquely number every endpoint. When I was doing IPAM for a living,
> not allowing the workstations in Tucson to talk to the printers in
> Singapore was considered a feature.

Preventing communication exchange between devices does not have to be
driven by their IP addressing.


> I even had one customer who wanted the printers to all have the same
> (1918) IP address in every office because they had a lot of sales
> people who traveled between offices who couldn't handle reconfiguring
> every time they visited a new location. I thought it was a little too
> precious personally, but the customer is always right.  :)

It's 2021 - Bonjour. You're welcome :-).

Mark.

> On Feb 10, 2021, at 04:29 , Valdis Kl?tnieks <valdis.kletnieks@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.

The ability to tolerate pain is not a criteria for competence.

Partitioning (e.g.) the set-top box management network for a major cable provider is, in fact, pain and costly vs.
being able to have a contiguous network with unique addressing. IPv6 is the right answer in this case (and virtually
any other), but the addition of arbitrary pain thresholds doesn’t meet the criteria of whether or not one can run
out of RFC-1918 without incompetence.

Owen

> On Feb 10, 2021, at 06:11 , Bjørn Mork <bjorn@mork.no> wrote:
>
> Ca By <cb.list6@gmail.com> writes:
>
>> 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 certainly agree that this is easier and makes more sense. I just
> don't buy the "can't be done" wrt using rfc1918.
>
>
> Bjørn

The argument was that you can’t run out of RFC-1918 without incompetence.

You don’t have to be incompetent to decide that partitioning your network is a bad idea for
multiple (I would think obvious) reasons.

Trying to allow arbitrary phone calls between 100M subscribers (5+ copies of RFC-1918 space)
where any endpoint may need to reach any other endpoint involves some mapping gymnastics
that would make SS7 look like child’s play.

Cable providers did, in some cases go with partitioned networks for set-top management,
but I don’t know anyone who was involved in building or maintaining or troubleshooting those
systems that doesn’t curse them.

Owen

> On Feb 10, 2021, at 09:50 , Doug Barton <dougb@dougbarton.us> wrote:
>
> On 2/10/21 5:56 AM, Ca By wrote>
>> 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.
>
> So that answers the question of how to scale networks past what can be done with 1918 space. Although why the phones would need to talk directly to each other, I can't imagine.

Ideally SIP does the call setup and registration of the phone’s DIDN to to IP mapping, but once call setup is completed, ideal is a pair of RTP streams between the phones directly (modulo annoying CALEA provisions getting in the way).

> I also reject the premise that any org, no matter how large, needs to uniquely number every endpoint. When I was doing IPAM for a living, not allowing the workstations in Tucson to talk to the printers in Singapore was considered a feature. I even had one customer who wanted the printers to all have the same (1918) IP address in every office because they had a lot of sales people who traveled between offices who couldn't handle reconfiguring every time they visited a new location. I thought it was a little too precious personally, but the customer is always right. :)

Unique numbering doesn’t mean connectivity, it means the possibility of allowing connectivity.

There’s. also the transitive issue… If A needs to talk to B and B needs to talk to C, then having A and C in the same address space is a problem, even if A doesn’t need to talk to C.

> Sure, it's easier to give every endpoint a unique address, but it is not a requirement, and probably isn't even a good idea. Spend a little time designing your network so that the things that need to talk to each other can, and the things that don't have to, can't. I did a lot of large multinational corporations using this type of design and never even came close to exhausting 1918 space.

It’s absolutely a good idea. Using address overloading to avoid the possibility of permitting connectivity is just bad design any way you slice it.

Oh, and no network design survives contact with the real world. The set of things that need to talk today are not the same set of things that will need to talk in 1 year, 5 years, 10 years, etc.

The accounting department will NEVER talk directly to the sales department until they do.

Owen

On Wed, Feb 10, 2021 at 04:04:43AM -0800, Owen DeLong wrote:
> without creating partitioned networks.

Ridiculous. Why would you establish such a criteria? The defining
characteristic of rfc1918 networks is that they are partitioned.

The ability to recognize and exploit partitions within a network,
natural or otherwise, is the measure of competence in a network
engineer.

Stop making excuses.

--
. ___ ___ . . ___
. \ / |\ |\ \
. _\_ /__ |-\ |-\ \__