@b0rk You are totally hitting the ball out of the park today with "Excellent questions that will draw out uninformed opinions from people who wish they were experts in this area but can type like them". (I say this as someone whose response to questions about IP addresses is "ask my friends like @spamvictim, @andy, @nygren or anyone who has been in the RIPE community for >20 years.)
Discussion
Loading...
@b0rk You are totally hitting the ball out of the park today with "Excellent questions that will draw out uninformed opinions from people who wish they were experts in this area but can type like them". (I say this as someone whose response to questions about IP addresses is "ask my friends like @spamvictim, @andy, @nygren or anyone who has been in the RIPE community for >20 years.)
@paulehoffman @b0rk @spamvictim @andy
There are many angles here, so I'll provide one or two.
1) Having a large amount of IPv4 space made address planning and structured addresses easy. For example, MIT used to split up 18.0.0.0/8 in a structured manner -- for example buildings often got a /16. My undergrad dorm didn't *need* 64k IPv4 addresses, but being able to look at the second octet to know where it was turned out to be super convenient.
This is actually one of the huge benefits of IPv6, especially when people treat it as its own things rather than just as "bigger IPv4". If you get you address plan right then you can have structured addresses. As a large scale operator this turns out to be super convenient.
For example, if an organization has a /32 then they can slice this up in various ways. For example:
* Have a /48 per site, and then have common structure within each site.
* Have a /36 per function (prod servers, lab/QA, clients, etc) then have a /48 per site within that.
That sort of structure makes IPv6 addresses actually easier to work with than IPv4 -- it's not like anyone managing a network with hundreds of thousands of nodes is typing IP addresses by hand or memorizing them.
While structured addressing sometimes happens in RFC1918 space (eg, for K8s clusters in net-10), it is much easier to run out of space in IPv4 this way in ways that get you stuck, especially if you ever need to connect multiple environments together. While 24M addresses in 10.0.0.0/8 sounds like a lot, it turns out to be not big enough for structured addressing in large compute environments, or even for unstructured addressing for large ISPs with many tens of millions of subscribers.
@paulehoffman @b0rk @spamvictim @andy
2) Limited Public #IPv4 address space forces most organizations into CGNAT. This has lots of challenges (shared IP reputation, scaling/reliability/perf issues, etc). Those NATs can be fairly costly to operate as well. This also makes troubleshooting hard (eg, if a compromised or broken client is behind a NAT, it can be hard to chase the problem down and it can have impact to all of the other users behind that IP).
(Viet Nam has actually been making some great progress with their #Ipv6 transition and unlike some countries just talking about it, they seem to be following through so far: https://blog.apnic.net/2025/08/27/modernizing-viet-nams-internet-infrastructure-security-action/ )
@b0rk Oh man the MIT network has so many assumptions baked in that the whole thing is publicly addressable. Professors used to run servers on their desks. The whole organization had a very anarchic network, and then layers of administration on top to deal with _that_. @dentalflossbay might have more details of how it used to be and how it's changed, but that really is a shaping assumption that changed as we brought in NAT in organizations.
I started my career when NAT was new, and mostly symmetric, a tool for migrating between networks — you'd have a rule like "rewrite 1.2.3.x to 5.6.7.x" and apply it bidirectionally, without any of the state-tracking that modern NAT does.
@aredridel @b0rk Back in college, our institute's FTP server (a Pentium 90 with a VGA monitor) had researcher's files, early GNOME releases, and it was one of the machines we used to play Doom in the afternoons. I think it may have driven one of the shared printers there, too.