DoD IP Space

Fri Feb 5 22:36:57 UTC 2021

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 at 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.
> 
> -- 
> . ___ ___  .   .  ___
> .  \    /  |\  |\ \
> .  _\_ /__ |-\ |-\ \__