Live data from Hacker News

Millions of the Pentagon’s dormant IP addresses sprang to life on January 20

washingtonpost.com

221–230 of 257 posts

Re: Millions of the Pentagon’s dormant IP addresses sprang to life on January 20

#221
post #94

Earlier quoted context omitted.

That isn't really how it works anymore. It's possible (and standard) to push any political agenda without ever stating an opinion directly. It's all about which specific facts you choose to report and which you choose to ignore. It's very easy to select and report only facts that make group A look good, or only facts that make them look bad. In that way, 2 news sources can give people the opposite opinion without any…

And furthermore, public sentiment (and therefore elections) are decided by what the main sources of media determine is the most important news. Example: Cops have shot a thousand people a year for several years in a row (maybe a decade). About 300 of those each year have been black, which is a disproportionate amount by some measures. However, it is nowhere near the biggest problem in our country even for black peopl…

[deleted]

Re: Millions of the Pentagon’s dormant IP addresses sprang to life on January 20

#222

Earlier quoted context omitted.

JEDI was a deal for internal cloud infrastructure. I don't think they would be utilizing public IP address ranges.

Good point, but, here's an anecdote to serve as a counterpoint: When I was at a US three-letter department from 2013-2015, they did in fact use non-private IPs for their internal datacenter networks, and even for their office space LAN DHCP lease ranges. It blew my mind when I looked at my laptop and saw a public IP on it's ethernet interface. Watching the realization dawn on my InfoSec peers' faces there was amusing…

That's awesome. I'm guessing you couldn't straightforwardly get port-forwards to individual machines though :)

Re: Millions of the Pentagon’s dormant IP addresses sprang to life on January 20

#223
My theory: apparently a lot of companies use the IP-addresses internally. And apparently the intention was to sell the IP-addresses already for a long time. But buyers would be faced with a lot of traffic coming from all those companies using the ranges internally, instant DDoS. Maybe this is an attempt to "clean" the IP-addresses before selling them. It will probably only take time before most companies using the ranges internally and having problems now (or happily continuing business now with the help of Pentagon servers), to reconfigure their networks to fix it. In the meantime the Pentagon can probably collect some interesting traffic, speeding up the whole process of reconfiguration by companies who use the ranges, to prevent their secrets from falling into exactly the right hands.

Re: Millions of the Pentagon’s dormant IP addresses sprang to life on January 20

#225

Earlier quoted context omitted.

You can debate semantics all you want, it doesn't change the reality of the situation and how the problem of IPv4 address exhaustion is very real and not just down to "incompetent network staff". The DoD sitting on all that unused address space actively contributed to that problem and now it's exploiting band-aid fixes around it to once again play data kranken of the world under the guise of "We are just fighting APT…

It’s pretty clear that the DoD realizes how close they were to being forced to sell all that IP space off and wouldn’t have even been able to say “we’re using it” as it wasn’t routed.

IP address space doesn’t have to be announced to the internet in order to be in use, or require global uniqueness.

Re: Millions of the Pentagon’s dormant IP addresses sprang to life on January 20

#226
post #223

My theory: apparently a lot of companies use the IP-addresses internally. And apparently the intention was to sell the IP-addresses already for a long time. But buyers would be faced with a lot of traffic coming from all those companies using the ranges internally, instant DDoS. Maybe this is an attempt to "clean" the IP-addresses before selling them. It will probably only take time before most companies using the ra…

why would somebody use public ranges (even though unused) internally?

Re: Millions of the Pentagon’s dormant IP addresses sprang to life on January 20

#227
post #223

My theory: apparently a lot of companies use the IP-addresses internally. And apparently the intention was to sell the IP-addresses already for a long time. But buyers would be faced with a lot of traffic coming from all those companies using the ranges internally, instant DDoS. Maybe this is an attempt to "clean" the IP-addresses before selling them. It will probably only take time before most companies using the ra…

why would somebody use public ranges (even though unused) internally?

This comment shows why for example: https://news.ycombinator.com/item?id=26927455

Re: Millions of the Pentagon’s dormant IP addresses sprang to life on January 20

#228

Earlier quoted context omitted.

My wifi is called nsa_net

Yeah, sharing SSIDs isnt such a great idea. Check out https://wigle.net ... Obviously multiple people around the world use this one, but it narrows it down for dedicated people

[deleted]

Re: Millions of the Pentagon’s dormant IP addresses sprang to life on January 20

#229
post #70
post #7

"several Chinese companies use network numbering systems that resemble the U.S. military’s IP addresses in their internal systems" I don't think I've heard of this before. What does it mean? Does China operate a disconnected BGP network? Or do they have some modified protocol, or what?

Not just Chinese companies. I know of one FAANG company that used internal IP addresses in the 11.0.0.0/8 space (in addition to, not instead of, RFC 1918 space).

Why don't they use IPv6? Is there still a lot of hardware out there that doesn't support it? It seems perfect if it's internal only.

Re: Millions of the Pentagon’s dormant IP addresses sprang to life on January 20

#230
post #205

Earlier quoted context omitted.

IPv6 on an internal network is trivial. It is supported by both Windows and MacOS (and Linux) out of the box. If your ISP doesn't provide it, get one that does. They should allocate you a /56 by default per connection, if not something larger like a /48 if you have multiple locations. Subnet the /48 for each connection, subnet each /56 into /64 subnets. reserve one of the /56's for site-to-site if needed. Done.

Ipv6 is like python3. A worthy upgrade, but tried to do too much in a single coup and broke backwards compatibility. If they simply added two top octets, saying that 0.0. . . . was the old ipv4, everyone would have used it ages ago. Instead they made other improvements which led to complex standard and worse adoption.

> If they simply added two top octets, saying that 0.0.... was the old ipv4, everyone would have used it ages ago.

How would you "simply add two top octets"? The address fields in the IPv4 header are a fixed size of 32 bits. Every time this is discussed, someone comes up with this suggestion to "just make the addresses longer and change nothing else", but there's no way to make the addresses longer without changing something else. And that's before considering compatibility with older hosts or routers; how would an old host talk to a new host, or two new hosts talk one to another with an old router in the path? In the end, what you'd have would be two separate networks, with some hosts being in both networks, which is exactly what we have with IPv4 and IPv6.

Post reply on HN