IPv4 address utilization is incredibly low. For example, consider 44.0.0.0/8 - it's sitting around almost entirely unallocated. UCSD Caida uses it for their network telescope (pretending to use it for amateur radio) and won't give it back.
If anything, the first organization to have netblocks yanked out from under them should be the US DoD. As I mentioned a few days ago [0]:
> There are also large portions of the 13 /8s (218 million IPs!) assigned to the US Department of Defense [5] that you wouldn't need to scan since there are no routes to them at all: the 11.0.0.0/8, 22.0.0.0/8, 26.0.0.0/8, 28.0.0.0/8, 29.0.0.0/8, 30.0.0.0/8, and 33.0.0.0/8 networks are, for all intents and purposes, "missing" from the public Internet.
> Additionally, there are only four /24s in 21.0.0.0/8 that are reachable from the public Internet. Out of the 16,777,216 IP addresses that make up 7.0.0.0/8, only 255 are reachable (7.7.7.0/24) [6].
Just because we can't "see" them or get to them doesn't mean they aren't using them, though.
Yes, it sucks that we're out of IPv4 addresses but we've known this was coming for, what, 20+ years? The quicker we all get moved over to IPv6, the quicker we can forget about it.
(Disclosure: I've had a static IP from 44/8 for ~25 years and I don't wanna give it back.)
Technically that depends on the agreements with IANA. If IANA could say "HEY YOU if you're not using 80% of your space actively, by January after next then we'll charge you a an exponentially increasing fee" I suspect they'd get a lot more movement. I suspect that the price of IP space on the market will also change that attitude as people go "Well crap that's worth a lot of money"
If the US military had to pay a staggering $100/IP per year it wouldn't even show up in a detailed audit. It's an utterly inconsequential amount compared to the military budget.
It's not a price thing, it's a "why should we" thing.
Well, see, compared to what most of us are used to nowadays, IP networking looked a little bit different back then.
In 1981, RFC791 [0] came about, describing a way of doing IP addressing on the ARPANET (based upon "classful networks" [1]). In accordance with this scheme, you would get either a /8 ("Class A"), a /16 ("Class B"), or a /24 ("Class C") -- depending on how many hosts you had (or thought you might reasonably have). This is the main reason why you see some organizations with a /8 today that you wouldn't expect.
Classless routing ("CIDR") [2] -- or, more specifically, variable length subnet masking (VLSM), what we're all familiar with today -- didn't officially exist until RFC1518 [3] and RFC1519 [4] (fall 1993). CIDR was introduced as a solution to a problem people were already starting to experience then: a shortage of IPv4 addresses!
(Yes, 25 years ago, they realized they were running out of IPv4 addresses and started working on solutions. IPv6 [5] first emerged as a "draft standard" in late 1998 -- but only officially became an "Internet standard" last summer!)
How come IPv6 wasn't standardized before 2017? I suspect there's some kind of story there. Do you happen to know the details? Any links/pointers? Thanks!
It's just nonsense. In the IETF's nomenclature, the label "Internet Standard" is used to refer to, and I quote:
A specification for which significant implementation and successful
operational experience has been obtained may be elevated to the
Internet Standard level. An Internet Standard (which may simply be
referred to as a Standard) is characterized by a high degree of
technical maturity and by a generally held belief that the specified
protocol or service provides significant benefit to the Internet
community.
A specification that reaches the status of Standard is assigned a
number in the STD series while retaining its RFC number.
Most internet standards are not "Internet Standard"s, as can be seen by the fact that IPv6 got assigned the standard number 86, and up until last year, IPv6 wasn't either, but it still was a perfectly fine and well-documented standard, and has been for a long time.
I'm sort of familiar with how sacred these standards are. I'm interested in what was the deciding factor, when IETF and which WG decided now we have enough (significant) successful operational experience.
It's surprising, because IPv6 was set in stone at least around 2010 already, with a lot of experience (6bone ended in 2006, and so on), but on the hand general rollout is still very much ongoing.
There was a time before NAT, where every machine had a publicly routable IP, and things were good. Any machine could talk directly to any port on any other machine (firewall willing). Until one day, IP exhaustion attacked.
Thankfully NAT doesn't exist in IPv6, because 2^128 addresses should be enough for everybody.
You need NAT whenever you can't change your peers' routing table, for whatever reason.
It's used extensively in IPv4 world for LAN=>WAN connectivity because your only peer (your ISP) won't agree to send all traffic for 192.168.0.0/24 to your home.
Its most popular use case disappearing doesn't make it any less useful for the narrow set of circumstances when it's basically your only option.
NAT64 is NAT in reverse, essentially. Your internal, IPv6 network can use it to contact an IPv4 host by embedding the target address. This is arguably better than current NAT44. The NAT64 only needs to track which ports and IPs are used on the IPv4 side which should become easier as more hosts don't require an IPv4 anymore.
It's a last-stage transitional method IMO, when most but not all of the internet is IPv6.
Routable != Reachable, which is obvious once you actually setup a firewall once.
My IPv6 /48 is entirely routable. The reachable portions are some ports in the list of popular protocols like SSH, HTTPS and similar.
The good part is that the entire /48 is reachable from within and simplifies OpenVPN routing a lot compared to IPv4, which requires a bit of outbound NAT hackery so it doesn't have to traverse the firewall three times (OpenVPN->WAN->LAN instead of OpenVPN->LAN)
NAT of course is not the best solution ever, but vast majority of currently used network nodes do not need publicly routed IPs in a limited global space. If anything, many of them are much better without one. Yes, I know, firewalls. But why not just avoid the issue by not having publicly accessible address for non-public systems in the first place?
Because NAT is an abominable hack with significant technical and administrative overhead.
My home is not intended to be a public space. But, it has a unique address, just like any other bar or restaurant in the area. Being able to locate it with a unique identifier is valuable, even if I don't intend for my living room to be publicly accessible.
> Because NAT is an abominable hack with significant technical and administrative overhead.
Agreed. But you can use private networks without NAT. In fact, 99% of traffic in the private network doesn't need NAT. Only outside traffic does, and only that which can't use proxies etc. - which is pretty small amount of overall traffic, I think.
Particularly notable example of this is that the three ip6tables rules needed to get NAT-like everything out nothing out behavior are exactly the same three rules that you need in v4 iptables for the NAT to have any security effect at all.
And how is NAT not added security by default? By default it drops everything incoming, no? (I mean, theoretically NAT doesn't, but [almost] every practical implementation situations means that there's no possible automatic internal-external address correspondence, otherwise you wouldn't need the NAT.)
A NAT doesn't drop anything. A NAT translates. A firewall drops.
If you only have a NAT, your ISP (or anyone who has compromised their router, or possibly simply your neighbour when ISPs occasionally fail to isolate their customers on layer 2) still can send you packets addressed directly to your "internal" addresses. The only thing that actually helps is a stateful firewall. And when you have that, the NAT does not add anything security-wise.
NAT and "internal addresses" is as much a security mechanism as not telling anyone that there is a room called "living room" in your house. If you want to prevent strangers from getting into your living room, you don't use internal names for your rooms, you install a lock on the door.
By default a NAT is unconfigured, so it doesn't know what to translate into what. The usual practical deployment consists of a dynamic outgoing NAT setup and UPnP. So outgoing TCP/UDP/etc protocols are snooped and the incoming packets are translated accordingly. (Hence the UDP NAT hole punching technique.) This setup works well for SoHo sites.
In this case without knowing my egress traffic, any incoming packet will be dropped by the NAT middlebox/facility/software/device/module/thing. So NATs do drop. And nice ones emit ICMP or TCP RST too.
> The only thing that actually helps is a stateful firewall. And when you have that, the NAT does not add anything security-wise.
Yes, indeed. That's a different threat model though. And I agree that hosts should have a default deny ingress policy.
Yet NATs do work wonderfully for SoHo networks. And of course a stateful firewall is just as easy to fool (circumvent) with a back-connecting connection as a NAT.
And a NAT as described above or a stateful firewall that enables local network functions such as CIFS/SMB were just as vulnerable to the usual Blaster-type worms/malware.
Again, of course, usually things go hand in hand. Firewalls usually have SNAT/DNAT capabilities, and SoHo shitboxes come with too much of every kind of NAT/firewall thingies already.
And, I know the misery of interconnecting two internal networks both using the same 192.168.0.0/24 or whatever prefix, so I can't wait to get rid of this and move to proper v6. But the fact of life is that the typical NAT setup was very convenient for ticking the local network ingress security checkbox for ISPs for years (decades).
> In this case without knowing my egress traffic, any incoming packet will be dropped by the NAT middlebox/facility/software/device/module/thing. So NATs do drop.
No, that is the firewall, or simply the IP stack of the device, not the NAT. A NAT only translates. In your typical home setup, it will track connections coming from the LAN side and translate the source address of the connection to the public address, and then match packets of the same connection in the opposite direction and translate them back. If there is a packet coming in on the WAN side that does not match any known connections that are being translated, the packet is simply left unmodified by the NAT. If it happens to be addressed to the public adress of the gateway, it will then be passed to the higher layers of the IP stack of the gateway where it might be delivered to some TCP or UDP socket or who knows what other stuff that is running on the device and using IP--and if the IP stack cannot find any applicable socket to deliver it to, it might respond with the appropriate ICMP error or TCP reset or whatever. If the packet is not addressed to the gateway's public address, it will simply be forwarded to wherever the routing table says--if it's addressed to an address from the LAN range, it will be forwarded to the LAN.
A NAT without a firewall does not drop packets. A NAT only translates addresses of packets belonging to connections it is configured to translate, everything else is left untouched. If there is no firewall in addition to the NAT, it will not prevent inbound connections from the WAN side to the LAN side.
> But the fact of life is that the typical NAT setup was very convenient for ticking the local network ingress security checkbox for ISPs for years (decades).
Well, the real fact of life is that tons of supposed network professionals think that, and then potentially deploy a pure NAT setup that allows unlimited access to the LAN from the ISP's router and possibly other customers of the ISP when the ISP fails to properly isolate customers on layer 2 because of the completely baseless assumption that a NAT prevents inbound connections.
This is largely theoretical now, as there's a single bit difference in definition (or implementation) of a NAT. (Leaves unknown untouched, or drops them.) But you are right, that thinking of a NAT as a pure transformer that cannot drop packets results in a better model.
> deploy a pure NAT setup
Is that even possible? I mean, sure, get a PC with 2 NICs and use raw sockets, but with a simple off the shelf network gadget?
> This is largely theoretical now, as there's a single bit difference in definition (or implementation) of a NAT. (Leaves unknown untouched, or drops them.)
So ... any distinction between two different things is a single-bit difference and therefore largely theoretical? I am not sure I follow ...
> But you are right, that thinking of a NAT as a pure transformer that cannot drop packets results in a better model.
Which is the important point, in particular in this context where the common argument essentially is "because I consider dropping packets a function of a NAT, NAT is good to have", where the whole argument only hinges on the definition, not on any real-world facts about network devices.
> Is that even possible? I mean, sure, get a PC with 2 NICs and use raw sockets, but with a simple off the shelf network gadget?
I don't know, I have never investigated that, as I don't tend to use off the shelf network gadgets. However, there is no need to use raw sockets, just install Linux and use the kernel's netfilter, which behaves in exactly that way: If you only configure NAT rules but no filtering rules to prevent inbound connections, your LAN is wide open. And that is not bad design, that is the obvious way to implement this as a matter of separating concerns.
Now, Linux is (was?) a popular OS for off the shelf home routers, and some of them at some point even use(d?) netfilter for their NAT. If you consider what kinds of completely moronic security holes have been and still are being found in those kinds of devices (shell injection in the web interface, trivial buffer overflows, backdoors with hard-coded passwords, ...), that does not make me particularly optimistic that they are careful when putting together the actual network setup on those devices. Not configuring the filtering of inbound connections is exactly the kind of mistake that I would expect to happen in an environment that produces that kind of garbage: Unless you are competent and do invest in quality assurance, that is exactly the kind of problem that noone will notice, as it does not affect day-to-day operation, and noone in the target market will notice if you screw it up because even the supposed experts think that the NAT implies that they are safe.
I suspect other network stacks or even ASICs have similar separation of concerns in order to be usable for a broader market than "home routers", so I suspect you can make the same mistake on other platforms used for implementing home routers.
So, do I know that there are devices out there that do NAT but don't filter? No. Would I be surprised if there were? No, definitely not.
However, if you do away with NAT, that makes it much more likely that a home router lacking a filter wouldn't go unnoticed for long, because it's trivial to check whether it does filter or not. So, it's not only that NAT does not logically imply a firewall and that a firewall does not necessitate NAT, but that not having a NAT makes it actually more likely that your device does in fact have a firewall.
I think the most productive way to look at it that for NAT/NAPT/cone NAT to work, a necessary prerequisite is a default-deny inbound firewall policy and stateful connection tracking.
Once you have that, layering on NAT is possible. But the security implications were already addressed before you get to that point.
> NAT does nothing meaningful securitywise that a firewall cannot achive
One good thing about NAT is even if you screw up the firewall config, such as configure everything in "allow all" mode, your internal network is still secure, because private IPs are not routable at the Internet level.
Using NAT and the IPv4 private address ranges sounds at first like a good solution but it creates some operational problems when two organizations want to connect their networks or when two organizations merge.
The fact something looks "dark" on that plot doesn't tell you anything about how much of the space is allocated.
The site linked by that many years old Reddit post says that in fact loads of this space is allocated, to specific people, in this case "Hams", I see alphanumeric designations which I seem to remember Hams call "handles" as well as geographic locations and some human names.
Is the Amateur Radio "Ham" community disorganised? Yup. Does that magically mean they're not using this address space and so it's "unallocated"? Nope.
The allocation is for equipment within the packet radio network and, if you announce BGP, for your gateway connecting that equipment to the wider internet. I'm happy for UCSD to keep this block but I may be biased due to my participation in the network and general vicinity (~10mi) to the school itself.
> The fact something looks "dark" on that plot doesn't tell you anything about how much of the space is allocated.
A lot will also depend on when the scan is done. For instance, the University of Cambridge has 131.111/16 and hands it out to student devices, so if you scan during a vacation a large portion of it will look empty.
I had this thought too, but do we realistically know anything about what types of devices are likely to respond to ping? What's the alternative? Try to initiate a TCP handshake to every port of every IP? How many servers are in UDP listen only mode or whitelist IPs to whats on their network?
The alternative is to switch to IPv6. There is no requirement to offer any particular publicly reachable service on an IP address, a machine or device might be completely firewalled off from directly communicating with the public internet, and it is still perfectly acceptable for it to have a globally unique IP address, so it is ultimately pointless to try and measure "the real utilization" using packets.
As far as I understand the situation, it would be pointless to chase “unused” address ranges and try to claw them back because:
1. It would be technically very difficult, and old equipment is frequently hardcoded.
2. With the rate the allocations are going, you’d get maybe an additional few months or a couple of years out of this enormous effort. After that, all the addresses really would be allocated, and now what do you do?
Considering the huge effort, technical and political, it would take to do such a thing, it is easier to just adopt IPv6.
Yes this, we were blowing through a /8 every couple months in the past, haven't checked recently but might even be faster now. The parent argument comes up in every one of these threads.
Using ping is a really crude way of establishing the 'darkness' of a prefix.
Complete prefixes just block off all ICMP incoming traffic, as do many core internet infra-structural devices (although they may pass them on, they won't answer pings directed to them).
No, but they probably have a bunch of probes along the lines of "if you see any traffic in these ranges on the public internet, raise all the alarms," which is arguably a kind of usage in its own way.
It is very much in use - it may not all be visible to the public internet however.
If you said it was underutilized, you'd be correct.
But before we go after the hams, what about the absolutely massive address space held by the US DOD and related agencies? its literally 20x the size of the /8 held reserved for the ham community.
I see this argument posted a lot. Even if every one of the underutilized /8 or non publicly announced (US DoD) /8s was given back and allocated in small /24 to /20 chunks to small to medium sized ISPs, it would not have a greatly measurable long term impact. It would postpone the absolute need to migrate to ipv6 by maybe... 3-4 years, globally.
The argument that we should expend a lot of effort (technical, legal, and otherwise) to reclaim a dozen /8s and start making them part of the global routing table has been pretty thoroughly debunked by ARIN, RIPE and APNIC. They are instead focused on getting people to use v6.
Due to the efforts of a small number of people in Apple engineering (notably Erik Fair), Apple was a pretty major internet presence in the early 90’s. Though, oddly, the exec level pretty much didn’t know it existed. Remember eWorld? (Probably not.)
The relevant bit: 'we renumbered the entire company from "picked out of the air" IP Addresses to net 17, assigned to us upon request by the Internet Assigned Numbers Authority (IANA) (R.I.P., Jon Postel).'
Originally Apple's MacTCP was actually a product they sold separately, it wasn't bundled into the OS until 1994. Although it was usually easy to get a hold of a copy since universities and such had site licenses, and ISPs often had redistribution licenses
Remember that Microsoft believed that the future was subscriptions to CDROMs like Encarta that would be delivered by mail.
It was late to the party on the internet, but was a pioneer in seeing the value of subscription computing, predating pretty much every SaaS company out there today.
>UCSD Caida uses it for their network telescope (pretending to use it for amateur radio) and won't give it back.
Why do we have to convince them to give it back? It's not like IP addresses are tangible and we have to break into their offices to steal them. Major ISPs could stop all routes with them and those addresses could be recovered and reassigned to other AS's
I understand this is quite a big threshold to cross, but it feels necessary.
Just look at how dark it is: https://benjojo.co.uk/internet-2018.png (from https://blog.benjojo.co.uk/post/scan-ping-the-internet-hilbe...)
Discussion on r/amateurradio - https://www.reddit.com/r/amateurradio/comments/ohi7j/did_you...