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:
> 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
Ca By <cb.list6@gmail.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.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, afaikYou 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 whateverBjø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
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
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
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
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.
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
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
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
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.
Hi Beel,
Thanks for backing me up with an example of an organization with
competent network engineering. Their ability to almost infinitely
leverage the existing rfc1918 address space to serve an appreciable
fraction of all Internet attached hosts is a real demonstration of the
possible.
Since relay,
Ridiculous… TCP/IP was designed to be a peer to peer system where each endpoint was uniquely
addressable whether reachable by policy or not.
IPv6 restores that ability and RFC-1918 is a bandaid for an obsolete protocol.
Stop making excuses and let’s fix the network.
Owen
What amazes me about the movies is that they never seem to have IP(v4) problems. But then again, listening to every keystroke being accompanied by a beeping sound, or feverishly typing on a keyboard in order to zoom into a photo when I generally move my mouse to do exactly that, doesn't necessarily inspire real world alignment. Ah well, it's the movies... one can depart one airport in a B737 and land at their destination in an A380.
Also, in the movies, IP(v4) addresses can begin with 260 and end in 314. And yet, somehow, every Internet user in the movies can be mapped to a person, on a desk, in their bedroom, in a house on their street.
*shrugs*
In the real world, for us, I don't get why we are still fighting hard to keep IPv4 around. When I type on my keyboard, there is no corresponding beep with each key. Nor do I need to type 100 characters to zoom into a picture; I just use my mouse or trackpad. The movies which make the Internet and computers these weird objects actually rely on a working Internet to get produced and distributed.
Let's not normalize the sustenance of IPv4 in 2021, in the real world.
Mark.
You don’t, you wastefully assign a /24 to every unique thing that you think needs an internal management IP block (even if there’s 5 things that answer pings there), and decide it’s too much work to renumber things. Easy for a big ISP that’s also acquired many small/mid-sized ISPs to run out of v4 private IP space that way.
> None whatsoever. You just have to be really big.
Hi Beel,
That was unnecessary. Sorry I used an S instead of a Z.
Thanks for backing me up with an example of an organization with
competent network engineering. Their ability to almost infinitely
leverage the existing rfc1918 address space to serve an appreciable
fraction of all Internet attached hosts is a real demonstration of the
possible.
Except they don't. One of the reasons you can't put vms in multiple
regions into the same VPC is they don't have enough IP addresses to
uniquely address the backend hosts in every region. They end up with a
squirrelly VPC peering thing they relies on multiple gateway hosts to
overcome the address partitioning from overlapping RFC1918.
In other words, it proves the exact opposite of your assertion.
Regards,
Bill Herrin
Hi,
You're right and wrong.
You don't, you wastefully assign a /24 to every unique thing that you think
needs an internal management IP block (even if there's 5 things that answer
pings there),
Reword that to: in the late 1990s, someone took an ICND course and decided
that assigned a /24 as a minimum for each subnet was fine as they would never
run out of RFC1918 space.
Today, the current network owner is stuck with that inherited problem.
and decide it's too much work to renumber things.
Reword that to: and management decides that they are not going to fund a
renumbering project as they have other priorities. (that's how work gets
funded in every large org that I've worked for)
Easy for a big ISP that's also acquired many small/mid-sized ISPs to run out of
v4 private IP space that way.
Not just ISPs. Plenty of decades old enterprises.
Mark Tinka wrote:
Let's not normalize the sustenance of IPv4 in 2021, in the real world.
Our opinions don't matter to the PHBs whos bonuses rely on features delivered.
The only time that I got some serious attention with regards to this matter was
when my manager and I took it three layers up and warned them that we were
about to run out of RFC1918 space unless drastic measures were taken. They were,
but now how we wanted: they forced other groups to return unused allocations.
Now we had half of 10/8 back, and deployment of new pods could resume...
Problem "solved".
I get really sad when people bicker on this list about who is at fault. The
purity fundamentalists complain that realists have run out of RFC1918 due to
their poor decisions, while in 99% of the cases it's a result of decisions made
long ago by their predecessors. The true enemy here is mid-level management
that refuses to prioritize deployment of IPv6.
What we should be discussing is how best to approach that problem. It's where
ops and corporate politics overlap.
Thanks,
Sabri