12 ms·

The Road Not Taken: A World Where IPv4 Evolved

95 points by billpg 7mo ago

convolvatron 7mo ago
what happens when a legacy host sends a 32 bit address to a 128 bit endpoint? it doesn't have enough information to forward it anywhere
- imurray 7mo ago
  I think that's meant to be covered by the "IPv4x when we can. NAT when we must" part, in particular "ISPs used carrier‑grade NAT as a compatibility shim rather than a lifeline: if you needed to reach an IPv4‑only service, CGNAT stepped in while IPv4x traffic flowed natively and without ceremony." It seemed strange that the need for CGNAT wasn't mentioned until after the MIT story. The "Nothing broke" claim in that story seems unlikely; I was on a public IP at University at the end of the 90s and if I'd suddenly been put behind NAT, some things I did would have broken until the workarounds were worked out.
  - lxgr 7mo ago
    > "ISPs used carrier‑grade NAT as a compatibility shim rather than a lifeline: if you needed to reach an IPv4‑only service, CGNAT stepped in while IPv4x traffic flowed natively and without ceremony." What's the difference between that and dual stack v4/v6, though? Other than not needing v6 address range assignments, of course.
    - tocitadel 7mo ago
      Try an IPv6-only VPS and see how quickly something breaks for you. Dual-stack fails miserably when the newer stack is incompatible with the older one. With a stack that extends the old stack, you always have something to fallback to. To replace something, you embrace it and extend it so the old version can be effectively phrased out.
      - lxgr 7mo ago
        > Try an IPv6-only VPS and see how quickly something breaks for you. Who's arguing for that? That would be completely non-viable even today, and even with NAT64 it would be annoying. > Dual-stack fails miserably when the newer stack is incompatible with the older one. Does it? All my clients and servers are dual stack. > With a stack that extends the old stack, you always have something to fallback to. Yes, v4/v6 dual stack is indeed great! > To replace something, you embrace it and extend it so the old version can be effectively phrased out. Some changes unfortunately really are breaking. Sometimes you can do a flag day, sometimes you drag out the migration over years or decades, sometimes you get something in between. We'll probably be done in a few more decades, hopefully sooner. I don't see how else it could have realistically worked, other than maybe through top-down decree, which might just have wasted more resources than the transition we ended up with.
        simoncion 7mo ago
        > We'll probably be done in a few more decades... I don't see IPv4 going away within the next fifty years. I'd not be surprised for it to last for the next hundred+ years. I expect to see more and more residential ISPs provide their customers with globally-routable IPv6 service and put their customers behind IPv4 CGNs (or whatever the reasonable "Give the customer's edge router a not-globally-routable IPv4 address, but serve its traffic with IPv6 infrastructure" mechanism to use is). That IPv4 space will get freed up to use in IPv4-only publicly-facing services in datacenters. There's IPv4-only software out there, and I expect that it will outlive everyone who's reading this site today. That's fine. What matters is getting proper IPv6 service to every Internet-connected site on (and off) the planet.
        lxgr 7mo ago
        With you on “IPv6 only will become a thing for many clients”, but servers (or at least load balancers) will absolutely not stay v4-reachable only. They’re already not. For example, I believe you won’t get an iOS app approved for distribution by Apple these days if it doesn’t work on v6-only clients.
- lxgr 7mo ago
  It can't even address a 128 bit endpoint, so nothing would happen.
  - jandrese 7mo ago
    Sure it can, the DNS server returns the A record if your client doesn't understand Ax. It just won't work. Honestly, this backwards compatibility thing seems even worse than IPv6 because it would be so confusing. At least IPv6 is distinctive on the network.
    - lxgr 7mo ago
      The question was about forwarding as I understand it, not address resolution, and there simply won't be any forwarding, since the 32 bit only sending host won't be able to address the 128 bit receiving one.
philipkglass 7mo ago
My fantasy road-not-taken for IPv4 is one where it originally used 36 bit addressing like the PDP-10. 64 billion addresses would be enough that we probably wouldn't have had the address exhaustion crisis in the first place, though routing would still get more complicated as most of the world's population (and many devices) started communicating over IP networks.
- UltraSane 7mo ago
  Even better if it had used 48 bit addressing like Ethernet. 32 bits is almost the worst possible option since it was big enough to seem inexhaustible initially while not actually being big enough.
- ianburrell 7mo ago
  36-bit is still too small for the future. We are at 30 billion connected devices. We will probably hit 64 billion in decade or two. The most likely alternative would have been 64-bit. That's big enough that could have worked for a long time.
  - pocksuppet 7mo ago
    A flat address space causes problems tracking it. Think of the IPv4 space which is fragmenting towards having a completely separate route for every /24 (the smallest unit). Longer addresses enable levels of aggregation which is good for routing, hence 128 bits.
bombcar 7mo ago
IPv4 was evolved, it is now a 48 bit address, signified by IP:PORT.
- nine_k 7mo ago
  Routing of this additional /16 is more tricky and non-uniform though. NAT, hole-punching, all that.
  - WorldMaker 7mo ago
    Which is the exact problem any other IPv4 "extended" proposal would have hit. But the practical reality if the port number really was the only freely available bits in the IPv4 header to reasonably extend into. Almost everything else had ossified middleboxes doing something dumb with it. (And we've seen from NAT/hole-punching/etc how even port numbers had a lot of assumptions to overcome from middle boxes and we aren't using a full /16 there either. A lot of the safest traffic has to be > 10,000, a constraint on 14 of those 16 bits.) There was never 64-78 bits in the IPv4 header unconstrained enough to extend IPv4 in place even if you accepted the CGNAT-like compromise of routing through IPv4 "super-routers" on the way to 128-bit addresses. Extending address size was always going to need a version change.
    - bombcar 7mo ago
      DNS SRV records actually can identify a port, so for "many" uses it would be transparent. I've rarely seen it used in practice, but it's in theory doable.
- lxgr 7mo ago
  There are many things wrong with this analogy, but the most important ones seem to be: - NAT gateways are inherently stateful (per connection) and IP networks are stateless (per host, disregarding routing information). So even if you only look at the individual connection level, disregarding the host/connection layering violation, the analogy breaks. - NAT gateways don't actually route/translate by (IP, port) as you imply, but rather by (source IP, source port, destination IP, destination port), as otherwise there simply would not be enough ports in many cases.
imurray 7mo ago
Reminds me of https://cr.yp.to/djbdns/ipv6mess.html https://cr.yp.to/djbdns/ipv6mess.html Which has been discussed previously: https://hn.algolia.com/?q=The+IPv6+mess https://hn.algolia.com/?q=The+IPv6+mess
deleted 7mo ago
[deleted]
miyuru 7mo ago
In my view, the problem largely comes from the way the Internet has grown. Many of these concepts developed together with the Internet, and IPv4 was the protocol that evolved with them. I see many ISPs deploying IPv6 but still following the same design principles they used for IPv4. In reality, IPv6 should be treated as a new protocol with different capabilities and assumptions. For example, dynamic IP addresses are common with IPv4, but with IPv6 every user should ideally receive a stable /64 prefix, with the ability to request additional prefixes through prefix delegation (PD) if needed. Another example is bring-your-own IP space. This is practically impossible for normal users with IPv4, but IPv6 makes it much more feasible. However, almost no ISPs offer this. It would be great if ISPs allowed technically inclined users to announce their own address space and move it with them when switching providers.
- Gigachad 7mo ago
  Dynamic v6 is likely a business and billing issue rather than a technical one. They want to sell you the static IP like they do with v4.
  - pocksuppet 7mo ago
    It's also a privacy issue, in fact it's mandatory in some European countries because otherwise you'd be easily tracked by your address, but it's also mandated you can get a static one if you ask.
  - miyuru 7mo ago
    You're correct, but the issue is that static IPv6 isn’t even available as an option—at least in my experience with two ISPs in my country. It may be different in other places.
throw0101d 7mo ago
> In a nutshell, an IPv4x packet is a normal IPv4 packet, just with 128‑bit addresses. The first 32 bits of both the source and target address sit in their usual place in the header, while the extra 96 bits of each address (the “subspace”) are tucked into the first 24 bytes of the IPv4 body. A flag in the header marks the packet as IPv4x, so routers that understand the extension can read the full address, while routers that don’t simply ignore the extra data and forward it as usual. So you have to ship new code to every 'network element' to support IPv4x. Just like with IPv6. So you have to update DNS to create new resource record types ("A" is hard-coded to 32-bits) to support the new longer addresses, and have all user-land code start asking for, using, and understanding the new record replies. Just like with IPv6. (And their DNS idea won't work—or won't work differently than IPv6: a lot of legacy code did not have room in data structures for multiple reply types: sure you'd get the "A" but unless you updated the code to get the "AX" address (for ipv4X addresses) you could never get to the longer with address… just like IPv6 needed code updates to recognize AAAA, otherwise you were A-only.) You need to update socket APIs to hold new data structures for longer addresses so your app can tell the kernel to send packets to the new addresses. Just like with IPv6. A single residential connection that gets a single IPv4 address also gets to use all the /96 'behind it' with this IPv4x proposal? People complain about the "wastefulness" of /64s now, and this is even more so (to the tune of 32 bits). You'd probably be better served with pushing the new bits to the other end… like… * https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresse...
- lxgr 7mo ago
  Yes, I was wondering if I was missing something reading the hypothetical: This is still splits the Internet into two incompatible (but often bridged etc.) subnetworks, one on the v4, one on the v4x side, right? It just so happens that, unlike for v6, v4 and v4x have some "implicit bridges" built-in (i.e. between everything in v4 and everything in v4x that happens to have the last 96 bits unset). Not sure if that actually makes anything better or just kicks the can down the road in an even more messy way.
  - xorcist 7mo ago
throw0101d 7mo ago
> Who owns all these new addresses? You do. If you own an IPv4 address, you automatically own the entire 96‑bit subspace beneath it. Every IPv4 address becomes the root of a vast extended address tree. It has to work this way because any router that doesn’t understand IPv4x will still route purely on the old 32‑bit address. There’s no point assigning part of your subspace to someone else — their packets will still land on your router whether you like it or not. So the folks that just happen to get in early on the IPv4 address land rush (US, Western world) now also get to grab all this new address space? What about any new players? This particular aspect idea seems to reward incumbents. Unlike IPv6, where new players (and countries and continents) that weren't online early get a chance to get equal footing in the expanded address space.
- wmf 7mo ago
  The new players would each get a /24 and everyone would say that's "enough".
  - avidiax 7mo ago
    Yeah, and the value of IPv4 address space would plummet, and there would be no reason for any company to own a /8. Clawing back address space would involve a few emails and a few months to get network configs ready.
  - throw0101d 7mo ago
    > The new players would each get a /24 and everyone would say that's "enough". From where? All then-existing IPv4 addresses would get all the bits behind them. There would, at the time, still be IPv4 addresses available that could be given out, and as people got them they would also get the extend "IPv4x" address associated with them. But at some point IPv4 addresses would all be allocated… along with all the extended addresses 'behind' them. Then what? The extended IPv4x addresses are attached to the legacy IPv4 addressed they are 'prefixed' by, so once the legacy bits are assigned, so are the new bits. If someone comes along post-legacy-IPv4 exhaustion, where do new addresses come from? You're in the exact same situation as we are now: legacy code is stuck with 32-bit-only addresses, new code is >32-bits… just like with IPv6. Great you managed to purchase/rent a legacy address range… but you still need a translation box for non-updated code… like with CG-NAT and IPv6.
themafia 7mo ago
IPv6 is fine. The advice on ULAs is garbage. The purpose of a protocol is to provide utility, not proscription.
- simoncion 7mo ago
  What's the advice on ULAs? On my internet-connected VLANs, I have a -er- site-local IPv4 subnet, a unique local IPv6 subnet, and a global IPv6 subnet. This works just fine. Does the "advice" boil down to "You should NEVER use ULAs and ALWAYS use GUAs!" and is given by the same very, very loud subset of people who seemed to feel very strongly that IPv6 implementations should explicitly make it impossible to do NAT?
  - UltraSane 7mo ago
    Why would IPv6 ever need NAT?
    - simoncion 7mo ago
      Why would anyone need IPv6 to be incapable of doing NAT? To answer your question: Who knows? Perhaps you have a shitlord ISP that only provides you with a /128 (such as that one "cloud provider" whose name escapes me). [0] It's a nice tool to have in your toolbox, should you find that you need to use it. [0] Yes, I'm aware that a "cloud provider" is not strictly an ISP. They are providing your VMs with access to the Internet, so I think the definition fits with only a little stretching-induced damage.
      - UltraSane 7mo ago
        As a network admin I can say that NAT makes everything much harder and that the source and destination IP should stay the same from source to destination whenever possible.
        simoncion 7mo ago
        Sure. I agree. That doesn't help when your shitbag ISP has given you exactly one /128.
lxgr 7mo ago
> The Version field must remain 4. And at the same time the address format and IP header is extended, effectively still splitting one network into two (one of which is a superset of the others)? A fundamentally breaking change remains a breaking change, whether you have the guts to bump your version number or not.
- billpg 7mo ago
  The central idea is that a IPv4x packet is still a globally routable IPv4 packet. The extra stuff all goes in the body of the packet.
  - simoncion 7mo ago
    > The central idea is that a IPv4x packet is still a globally routable IPv4 packet. That's cool and all, but end-user edge routers are absolutely going to have to be updated to handle "IPv4x". Why? Because the entire point of IPvNext is to address address space exhaustion, their ISP will stop giving them IPv4 addresses. This means that the ISP is also going to have to update significant parts of their systems to handle "IPv4x" packets, because they're going to have to handle customer site address management. The only thing that doesn't have to change is the easiest part of the system to get changed... the core routers and associated infrastructure.
    - billpg 7mo ago
      Yes. The router in your home would absolutely need to support IPv4x if you wanted to make use of the extended address space, just like how in the real world your home router needs to support NAT if you want to make use of shared IP.
      - simoncion 7mo ago
        > The router in your home would absolutely need to support IPv4x if you wanted to make use of the extended address space... No. The router in your home would need to support IPv4x, or you would get no Internet connection. Why? Because IPv4x extends the address space "under" each IPv4 address -thus- competing with it for space. ISPs in areas with serious address pressure sure as fuck aren't going to be giving you IPv4 addresses anymore. As I mentioned, similarly, ISPs will need to update their systems to handle IPv4x, because they are -at minimum- going to be doing IPv4x address management for their customers. They're probably going to -themselves- be working from IPv4x allocations. Maybe each ISP gets knocked down from several v4 /16s or maybe a couple of /20s to a handful of v4 /32s to carve up for v4x customer sites. Your scheme has the adoption problems of IPv6, but even worse because it relies on reclaiming and repurposing IPv4 address space that's currently in use.
fulafel 7mo ago
This sounds a lot like what we have in 6to4 (for 25+ years now), where nodes behind two ipv4 derived prefixes can automatically talk to each other p2p, and use a gateway to communicate with the rest of the v6 internet.
- billpg 7mo ago
  Interesting. Who deploys and maintains the gateway?
  - wmf 7mo ago
    That was one of the problems with 6to4. If there was no gateway or it was overloaded or there was a gateway but you couldn't reach it because of a weird firewall, all your IPv6 packets would be silently dropped and you'd have no idea why. And this was before happy eyeballs so your computer might default to broken IPv6.
  - pocksuppet 7mo ago
    I think the intention was to use normal internet (anycast) routing to send it to the closest translator - which would be your ISP, or the nearest ISP that supports IPv6, or a tier 1 network which is happy to have extra traffic traversing its network unnecessarily since they get paid for all of it. (The same reason HE runs the free tunnel broker)
  - fulafel 7mo ago
    You can configure it statically but there used to be the anycast address 192.88.99.1 and the idea was that you'll get routed to the nearest one by magic of BGP. It was retired once native IPv6 deployment took off. Apparently the practical problems were related to people haplessly firewalling it out (ref. https://labs.ripe.net/author/emileaben/6to4-why-is-it-so-bad/ https://labs.ripe.net/author/emileaben/6to4-why-is-it-so-bad...)
avidiax 7mo ago
Similar discussion from a couple of months ago: https://news.ycombinator.com/item?id=46468625 https://news.ycombinator.com/item?id=46468625 I personally feel that IPv6 is one of the clearest cases of second system syndrome. What we needed was more address bits. What we got was a nearly total redesign-by-committee with many elegant features but had difficult backwards compatibility. https://en.wikipedia.org/wiki/Second-system_effect https://en.wikipedia.org/wiki/Second-system_effect
- lxgr 7mo ago
  Which IPv6 “gratuitious” features (i.e. anything other than the decision to make a breaking change to address formats and accordingly require adapters) would you argue made adoption more difficult? IPv6 gets a lot of hate for all the bells and whistles, but on closer examination, the only one that really matters is always “it’s a second network and needs me to touch all my hosts and networking stack”. Don’t like SLAAC? Don’t use it! Want to keep using DHCP instead? Use DHCPv6! Love manual address configuration? Go right ahead! It even makes the addresses much shorter. None of that stuff is essential to IPv6. In fact, in my view TFA makes a very poor case for a counterfactual IPv4+ world. The only thing it really simplifies is address space assignment.
  - iso1631 7mo ago
    Having both a real address, a link-local address, and a unique local address, and the requirement to use the right one in each circumstance The removal of arp and removal of broadcast, the enforcement of multicast The almost-required removal of NAT and the quasi-relgious dislike from many network people. Instead of simply src-natting your traffic behind ISP1 or ISP2, you are supposed to have multiple public IPs and somehow make your end devices choose the best routing rather than your router. All of these were choices made in addition to simply expanding the address scope.
    - lxgr 7mo ago
      > Having both a real address, a link-local address, and a unique local address, and the requirement to use the right one in each circumstance Only use the real one then (unless you happen to be implementing ND or something)! > The removal of arp and removal of broadcast, the enforcement of multicast ARP was effectively only replaced by ND, no? Maybe there are many disadvantages I'm not familiar with, but is there a fundamental problem with it? > The almost-required removal of NAT Don't like that part? Don't use it, and do use NAT66. It works great, I use it sometimes!
wmf 7mo ago
Similar discussion from 10 years ago: https://news.ycombinator.com/item?id=10854570 https://news.ycombinator.com/item?id=10854570
iso1631 7mo ago
30 years on and if I have a machine with an ipv6 only network and run "ping 1.1.1.1" it doesn't work. If stacks had moved to ipv6 only, and the OS and network library do the translation of existing ipv4, I think things would have moved faster. Every few months I try out my ipv6 only network and inevitably something fails and I'm back to my ipv4 only network (as I don't see the benefit of dual-stack, just the headaches) Sure you'd need a 64 gateway, but then that can be the same device that does your current 44 natting.
- wmf 7mo ago
  This works if you have 464xlat turned on. It's mostly used by phones though.
  - zokier 7mo ago
    It's bit weird how despite Linux kernel having otherwise fairly advanced network stack, the 464xlat and other transition mechanism situation is not great. There are some out of tree modules (jool and nat46) available, but nothing in mainline. Does anyone know why that is?
    - jcgl 7mo ago
      NetworkManager just recently got CLAT! https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2107 https://gitlab.freedesktop.org/NetworkManager/NetworkManager... Issue for CLAT in systemd-networkd: https://github.com/systemd/systemd/issues/23674 https://github.com/systemd/systemd/issues/23674
      - iso1631 7mo ago
        And if that's applies across the board, in 20 years time that might have filtered through to mean ipv4 can be dropped in my company. I'd rather see this at a lower level than network manager and bodging in with bpf, so it's just a default part of any device running a linux network stack, but I don't know enough about kernel development and choices to know how possible that is in practice. This should have been supported in the kernel 25 years ago though if the goal was to help ipv6 migration
tonymet 7mo ago
in 100 years ipv4 will be recognized as one of the great discoveries like calculus. ipv6 is a misnomer really. It's a separate, and lesser protocol. Much like other second systems, it was too ambitious and not pragmatic enough. Rather than looking down on IPv4 , we should admire how incredible it's design was. Its elegance and intuitiveness, resourcefulness have all led to it outlasting every prediction of it's demise.
billpg 7mo ago
"IPv6 does that." Are you sure about that? Until a few years ago my residential ISP was IPv4 only. I definitely couldn't connect to an IPv6-only service back then.
massysett 7mo ago
“IPv6 is waiting for adoption” A major website sees over 46 percent of its traffic over ipv6. A major mobile operator has a network that runs entirely over ipv6. This is not “waiting for adoption” so I stopped reading there. https://www.google.com/intl/en/ipv6/statistics.html https://www.google.com/intl/en/ipv6/statistics.html https://www.internetsociety.org/deploy360/2014/case-study-t-mobile-us-goes-ipv6-only-using-464xlat/ https://www.internetsociety.org/deploy360/2014/case-study-t-...
- billpg 7mo ago
  You'd happily deploy a website for use by the general public on IPv6-only?
  - simoncion 7mo ago
    I use Devouring Goats on your straw man. It's Super Effective! To be less glib: IPv6 is well-adopted. It's not universally adopted.
    - billpg 7mo ago
      Until you would happily deploy a service on IPv6 only, I suggest that you're still dependent on IPv4.
      - simoncion 7mo ago
        I'll repeat myself: IPv6 is well-adopted. It's not universally adopted.
  - massysett 7mo ago
    No. Which doesn’t prove the technology has not been adopted. The internet also consists of much more than public-facing websites. So what’s your point?
    - billpg 7mo ago
      My point is that we're still dependent on IPv4. For all the progress IPv6 has made, no-one is willing to switch IPv4 off yet. Until we do, we're still constrained by all the problems IPv4 has.
billpg 7mo ago
Thanks for reading and commenting everyone! Note though that I'm not proposing IPv4x as something we should work towards now. Indeed, I come down on the side of being happy that we're in the IPv6 world instead of this alternative history.
dboreham 7mo ago
Em-dashes in this article. What is described here is basically just CIDR plus NAT which is...what we actually have. At the time IPv6 was being defined (I was there) CIDR was just being introduced and NAT hadn't been deployed widely. If someone had raised their hand and said "I think if we force people to use NAT and push down on the route table size with CIDR, I think it'll be ok" (nobody said that iirc), they would have been rejected because sentiment was heavily against creating a two-level network. After all having uniform addressing was pretty much the reason internet protocols took off.
commandersaki 7mo ago
I'm glad this exists, because it demonstrates there are ways to make a next-gen IP interoperable with IPv4, and that while IPng had interoperability has part of its assessment, it completely nixed it because they didn't want to go with the other proposals at the time which had some consideration for it.
throw0101d 7mo ago
> Who owns all these new addresses? You do. If you own an IPv4 address, you automatically own the entire 96‑bit subspace beneath it. Every IPv4 address becomes the root of a vast extended address tree. Huh: > For any 32-bit global IPv4 address that is assigned to a host, a 48-bit 6to4 IPv6 prefix can be constructed for use by that host (and if applicable the network behind it) by appending the IPv4 address to 2002::/16. > For example, the global IPv4 address 192.0.2.4 has the corresponding 6to4 prefix 2002:c000:0204::/48. This gives a prefix length of 48 bits, which leaves room for a 16-bit subnet field and 64 bit host addresses within the subnets. * https://en.wikipedia.org/wiki/6to4 https://en.wikipedia.org/wiki/6to4
aboardRat4 7mo ago
We should basically all call our ISPs and ask for ipv6 to be implemented.
nayuki 7mo ago
Their hypothetical approach of extending IPv4 reminds me of how TLS v1.3 masquerades as v1.2 in order to pass through meddling middleboxes safely.
linsomniac 7mo ago
It seems like this really only helps intermediate routers. All endpoints need to upgrade to IPv4x before anyone can reasonably use it. If I have servers on IPv4x, clients can reach my network fine, but they then can't reach individual servers. Clients need to know IPv4x to reach IPv4x servers. Similarly, IPv4x clients talking to IPv4 servers do what? Send an IPv4x packet with the remaining IPv4x address bits zeroed out? Nope a V4 server won't understand it. So they're sending an IPv4 packet and the response gets back to your network but doesn't know how to get the last mile back to the IPv4x client? I desperately wish there was a way to have "one stack to rule them all", whether that is IPv4x or IPv4 mapped into a portion of IPv6. But there doesn't seem to be an actually workable solution to it.
- perennialmind 7mo ago
  There's no viable alternative to dual stack with NAT now. We're stuck with it. But when IPv6 was standardized, a pure upgrade to IPv4 was still feasible. IPv4 allows for extensions headers and middleboxes hadn't yet imposed protocol ossification. If instead of the encapsulation the article supposes, the upgrade embraced translation, we could have had an IPv4+ with NAT fallback. A node on a network behind a IPv4+ router would send out a packet with the RFC1918 interior address encoded as the address extension. Either the server (which would have a proper IPV4 address) responds without the extension header, at which point the IPv4+ router at the edge has to do NAT-style connection tracking, or the response packet can be forwarded as-is. All the pain of upgrading software to a new protocol still applies, with the added headache of variable length addresses (4 bytes, 8 bytes, potentially more). But no ISP has to make the investments or take the risk of the parallel infrastructure. The IPv4 core carries on, with incremental improvements but zero mandatory upgrades.
  - Dagger2 7mo ago
    Sure there is: use single-stack v6 with NAT64. What you're describing there is just an approach to store NAT state inside every packet instead of on the router. I'm not sure that's even an improvement on v4, but in any case it wouldn't increase the size of the address space so it wouldn't help with the one thing driving the need for IPv6.
sedatk 7mo ago
I actually disagree: that's the road taken. NAT is practically this. When you're behind a NAT, you're effectively using a 64-bit address space. Two more layers of NAT, and you can have 128-bit address space. "The first part" of the address is a globally routable IPv4 address, and the rest is kept by the routers on the path tracking NAT connection states. And NAT needed zero software changes. That's why it's won. It brought the benefits of whatever extension protocol with existing mechanisms of IPv4. IPv6 isn't an alternative to IPv4, it's an alternative to all IPv4xes.
jibal 7mo ago
Not a single discussion here of his SixGate proposal (but many mischaracterizations of IPv4x as a "proposal", when it was rather an alternate history). So HN.
- billpg 7mo ago
  le sigh Thanks though. Your comment really cheered me up.
  - jibal 7mo ago
    > And yes, this whole piece was a sneaky way to get you to read my SixGate proposal. Too sneaky, apparently. I suggest putting something at the top mentioning it ... then even folks with very short attention spans will see it.
ralferoo 7mo ago
I've often thought similar thoughts to this because fundamentally, IPv4 should still be enough for us, except that we've chronically wasted lots of it. The first main issue is that most often we waste an entire IPv4 for things that just have a single service, usually HTTPS and also an HTTP redirector that just replies with a redirect to the HTTPS variant. This doesn't require an entire IPv4, just a single port or two. We could have solved the largest issue with address exhaustion simply by extending DNS to have results that included a port number as well as an IP address, or if browsers had adopted the SRV DNS records, then a typical ISP could share a single IPv4 across hundreds of customers. The second massive waste of IPv4 space is BGP being limited to /24. In the days of older routers when memory was expensive and space was limited, limiting to /24 makes sense. Now, even the most naive way of routing - having a byte per IP address specifying what the next hop is - would fit in 4GB of RAM. Sure, there is still a lot of legacy hardware out there, but if we'd said 10 years ago that the smallest BGP announcements would reduce from /24 to /32, 1 bit per year, so giving operators time to upgrade their kit, then we'd already be there by now. They've already spent the money on getting IPv6 kit which can handle prefixes larger than this, so it would have been entirely possible. And following on from the BGP thing is that often this is used to provide anycast, so that a single IPv4 can be routed to the geographically closest server. And usually, this requires an entire /24, even though often it's only a single port on a single IPv4 that's actually being used. Arguably, we don't even need BGP for anycast anyway. Again, going back to DNS, if the SRV record was extended to include an approximate location (maybe even just continent, region of continent, country, city) where each city is allocated a hierarchical location field split up roughly like ITU did for phone numbers, then the DNS could return multiple results and the browser can simply choose the one(s) that's closest, and gracefully fall back to other regions if they're not available. Alternatively, the client could specify their geo location during the request. So, basically, all of that can be done with IPv4 as it currently exists, just using DNS more effectively. We also have massive areas of IPv4 that's currently wasted. Over 8% of the space is in the 240.0.0.0/4 range that's marked as "reserved for future use" and which many software vendors (e.g. Microsoft) have made the OS return errors if it's used. Why? This is crazy. We could, and should, make use of this space, and specifically for usages where ports are better used, so that companies can share a single IPv4 at the ISP level. Another 8% is reserved for multicast, but nowadays almost nothing on the public IPv4 uses it and multicast is only supported on private networks. But in any case, 225.0.0.0/8-231.0.0.0/8 and 234.0.0.0/8-238.0.0.0/8 (collectively 12 /8s, or 75% of the multicast block) is reserved and should never have been used for any purpose. This too could be re-purposed for alleviating pressure on IPv4 space. Finally, there are still many IPv4 /24s or larger that are effectively being hoarded by companies knowing they can make good money from renting them out or selling them later. Rather than being considered an asset, we should be charging an annual fee to keep hold of these ranges and turn them into a liability instead, as that would encourage companies with a large allocation that they don't need to release them back. The other main argument against IPv4 is NAT, but actually I see that as a feature. If services actually had port number discovery via DNS, then forwarding specific ports to the server than deals with them is an obvious thing to do, not something exceptional. The majority of machines don't even want incoming connections from a security point of view, and most firewalls will block incoming IPv6 traffic apart from to designated servers anyway. The "global routing" promised by IPv6 isn't actually desired for the most part, the only benefit is when it is wanted you have the same address for the service everywhere. The logical conclusion from that is that IPv4 needs a sensible way of allocating a range of ports to individual machines rather than stopping just at the IP address. When you then look at IPv6 space, it initially looks vast and inexhaustible, but then you realise that the smallest routable prefix with BGP is /48, it should be apparent that it suffers from essentially the same constraints as IPv4. All of "the global internet" is in 2002::/16, which effectively gives 32 bits of assignable space. Exactly the same as IPv4. Even more, IPv6 space is usually given out in /44 or /40 chunks, which means it's going to be exhausted at almost the same rate as IPv4 given out in /24 chunks. So much additional complexity, for little extra gain, although I will concede that as 2003::/16 to 3ffe::/16 isn't currently allocated there is room to expand, as long as routers aren't baking in the assumption that all routable prefixes are in 2001::/16 as specified. TLDR: browsers should use SRV to look up ports as well as addresses, and SRV should return geo information so clients can choose the closest server to them. If we did that, the IPv4 space is perfectly large enough because a single IPv4 address can support hundreds or thousands of customers that use the same ISP. Effectively a /32 IPv4 address is no different to a /40 IPv4 prefix, and the additional bits considered part of the address in IPv6 could be encoded in the port number for IPv4.
HocusLocus 7mo ago
I tend to give the lack of credible ready to deploy asteroid response for Earth defense 41 years after consensus was reached on the KT boundary, 70 years since the 'space age' began, much greater weight. Motivation for retiring IPv4 completely would NOT be to make the world a better more route-able place. It would be to deliberately obsolescence old products to sell new.
JackSlateur 7mo ago
Yes It is awesome until you understand that most equipement expect a TCP or UDP header; Then, with IPv4x, they find none, and drop the packet; Protocol ossification is a real thing and the main bane in this topic
- billpg 7mo ago
  An earlier draft had a section discussing how IPv4x would work with NAT routers. Essentially, an IPv4x packet would be a UDP/IPv4 packet using a port number (84) that's been allocated to IPv4x. Old routers would be a normal UDP packet inside a normal IPv4 and route it normally. New routers would detect UDP port 84 and treat it as an extended IPv4x packet. I took all that out because I wasn't writing a proposal for something we should actually implement in the real world, but an alternate history "What if people who wanted IPv4 but with extra space got their way" and the story was already too long.
zadikian 7mo ago
It's not too late to do something kinda like this using the ipv6 packet format, since routers already understand that. They'd put the whole "ipv4x" address space under a prefix.
- Dagger2 7mo ago
  We already did it decades ago, with 6to4. The extra address space is under 2002:<v4 address>::/48.
  - zadikian 7mo ago
    v4-mapped v6 (rfc4038), not 6to4, right? It was only a transition feature and not how v6 was rolled out by default. I don't even have such an address. You enable v6 and it suddenly means you're reachable with the new addresses, typically assigned via slaac. Also idk if v4-mapped was meant to be split beyond /32s.

95 points by billpg 7mo ago

what happens when a legacy host sends a 32 bit address to a 128 bit endpoint? it doesn't have enough information to forward it anywhere

imurray 7mo ago
I think that's meant to be covered by the "IPv4x when we can. NAT when we must" part, in particular "ISPs used carrier‑grade NAT as a compatibility shim rather than a lifeline: if you needed to reach an IPv4‑only service, CGNAT stepped in while IPv4x traffic flowed natively and without ceremony." It seemed strange that the need for CGNAT wasn't mentioned until after the MIT story. The "Nothing broke" claim in that story seems unlikely; I was on a public IP at University at the end of the 90s and if I'd suddenly been put behind NAT, some things I did would have broken until the workarounds were worked out.
- lxgr 7mo ago
  > "ISPs used carrier‑grade NAT as a compatibility shim rather than a lifeline: if you needed to reach an IPv4‑only service, CGNAT stepped in while IPv4x traffic flowed natively and without ceremony." What's the difference between that and dual stack v4/v6, though? Other than not needing v6 address range assignments, of course.
  - tocitadel 7mo ago
    Try an IPv6-only VPS and see how quickly something breaks for you. Dual-stack fails miserably when the newer stack is incompatible with the older one. With a stack that extends the old stack, you always have something to fallback to. To replace something, you embrace it and extend it so the old version can be effectively phrased out.
    - lxgr 7mo ago
      > Try an IPv6-only VPS and see how quickly something breaks for you. Who's arguing for that? That would be completely non-viable even today, and even with NAT64 it would be annoying. > Dual-stack fails miserably when the newer stack is incompatible with the older one. Does it? All my clients and servers are dual stack. > With a stack that extends the old stack, you always have something to fallback to. Yes, v4/v6 dual stack is indeed great! > To replace something, you embrace it and extend it so the old version can be effectively phrased out. Some changes unfortunately really are breaking. Sometimes you can do a flag day, sometimes you drag out the migration over years or decades, sometimes you get something in between. We'll probably be done in a few more decades, hopefully sooner. I don't see how else it could have realistically worked, other than maybe through top-down decree, which might just have wasted more resources than the transition we ended up with.
      - simoncion 7mo ago
        > We'll probably be done in a few more decades... I don't see IPv4 going away within the next fifty years. I'd not be surprised for it to last for the next hundred+ years. I expect to see more and more residential ISPs provide their customers with globally-routable IPv6 service and put their customers behind IPv4 CGNs (or whatever the reasonable "Give the customer's edge router a not-globally-routable IPv4 address, but serve its traffic with IPv6 infrastructure" mechanism to use is). That IPv4 space will get freed up to use in IPv4-only publicly-facing services in datacenters. There's IPv4-only software out there, and I expect that it will outlive everyone who's reading this site today. That's fine. What matters is getting proper IPv6 service to every Internet-connected site on (and off) the planet.
        lxgr 7mo ago
        With you on “IPv6 only will become a thing for many clients”, but servers (or at least load balancers) will absolutely not stay v4-reachable only. They’re already not. For example, I believe you won’t get an iOS app approved for distribution by Apple these days if it doesn’t work on v6-only clients.
lxgr 7mo ago
It can't even address a 128 bit endpoint, so nothing would happen.
- jandrese 7mo ago
  Sure it can, the DNS server returns the A record if your client doesn't understand Ax. It just won't work. Honestly, this backwards compatibility thing seems even worse than IPv6 because it would be so confusing. At least IPv6 is distinctive on the network.
  - lxgr 7mo ago
    The question was about forwarding as I understand it, not address resolution, and there simply won't be any forwarding, since the 32 bit only sending host won't be able to address the 128 bit receiving one.

philipkglass 7mo ago

My fantasy road-not-taken for IPv4 is one where it originally used 36 bit addressing like the PDP-10. 64 billion addresses would be enough that we probably wouldn't have had the address exhaustion crisis in the first place, though routing would still get more complicated as most of the world's population (and many devices) started communicating over IP networks.

UltraSane 7mo ago
Even better if it had used 48 bit addressing like Ethernet. 32 bits is almost the worst possible option since it was big enough to seem inexhaustible initially while not actually being big enough.
ianburrell 7mo ago
36-bit is still too small for the future. We are at 30 billion connected devices. We will probably hit 64 billion in decade or two. The most likely alternative would have been 64-bit. That's big enough that could have worked for a long time.
- pocksuppet 7mo ago
  A flat address space causes problems tracking it. Think of the IPv4 space which is fragmenting towards having a completely separate route for every /24 (the smallest unit). Longer addresses enable levels of aggregation which is good for routing, hence 128 bits.

bombcar 7mo ago

IPv4 was evolved, it is now a 48 bit address, signified by IP:PORT.

nine_k 7mo ago
Routing of this additional /16 is more tricky and non-uniform though. NAT, hole-punching, all that.
- WorldMaker 7mo ago
  Which is the exact problem any other IPv4 "extended" proposal would have hit. But the practical reality if the port number really was the only freely available bits in the IPv4 header to reasonably extend into. Almost everything else had ossified middleboxes doing something dumb with it. (And we've seen from NAT/hole-punching/etc how even port numbers had a lot of assumptions to overcome from middle boxes and we aren't using a full /16 there either. A lot of the safest traffic has to be > 10,000, a constraint on 14 of those 16 bits.) There was never 64-78 bits in the IPv4 header unconstrained enough to extend IPv4 in place even if you accepted the CGNAT-like compromise of routing through IPv4 "super-routers" on the way to 128-bit addresses. Extending address size was always going to need a version change.
  - bombcar 7mo ago
    DNS SRV records actually can identify a port, so for "many" uses it would be transparent. I've rarely seen it used in practice, but it's in theory doable.
lxgr 7mo ago
There are many things wrong with this analogy, but the most important ones seem to be: - NAT gateways are inherently stateful (per connection) and IP networks are stateless (per host, disregarding routing information). So even if you only look at the individual connection level, disregarding the host/connection layering violation, the analogy breaks. - NAT gateways don't actually route/translate by (IP, port) as you imply, but rather by (source IP, source port, destination IP, destination port), as otherwise there simply would not be enough ports in many cases.

imurray 7mo ago

Reminds me of https://cr.yp.to/djbdns/ipv6mess.html https://cr.yp.to/djbdns/ipv6mess.html Which has been discussed previously: https://hn.algolia.com/?q=The+IPv6+mess https://hn.algolia.com/?q=The+IPv6+mess

deleted 7mo ago

[deleted]

miyuru 7mo ago

In my view, the problem largely comes from the way the Internet has grown. Many of these concepts developed together with the Internet, and IPv4 was the protocol that evolved with them. I see many ISPs deploying IPv6 but still following the same design principles they used for IPv4. In reality, IPv6 should be treated as a new protocol with different capabilities and assumptions. For example, dynamic IP addresses are common with IPv4, but with IPv6 every user should ideally receive a stable /64 prefix, with the ability to request additional prefixes through prefix delegation (PD) if needed. Another example is bring-your-own IP space. This is practically impossible for normal users with IPv4, but IPv6 makes it much more feasible. However, almost no ISPs offer this. It would be great if ISPs allowed technically inclined users to announce their own address space and move it with them when switching providers.

Gigachad 7mo ago
Dynamic v6 is likely a business and billing issue rather than a technical one. They want to sell you the static IP like they do with v4.
- pocksuppet 7mo ago
  It's also a privacy issue, in fact it's mandatory in some European countries because otherwise you'd be easily tracked by your address, but it's also mandated you can get a static one if you ask.
- miyuru 7mo ago
  You're correct, but the issue is that static IPv6 isn’t even available as an option—at least in my experience with two ISPs in my country. It may be different in other places.

throw0101d 7mo ago

> In a nutshell, an IPv4x packet is a normal IPv4 packet, just with 128‑bit addresses. The first 32 bits of both the source and target address sit in their usual place in the header, while the extra 96 bits of each address (the “subspace”) are tucked into the first 24 bytes of the IPv4 body. A flag in the header marks the packet as IPv4x, so routers that understand the extension can read the full address, while routers that don’t simply ignore the extra data and forward it as usual. So you have to ship new code to every 'network element' to support IPv4x. Just like with IPv6. So you have to update DNS to create new resource record types ("A" is hard-coded to 32-bits) to support the new longer addresses, and have all user-land code start asking for, using, and understanding the new record replies. Just like with IPv6. (And their DNS idea won't work—or won't work differently than IPv6: a lot of legacy code did not have room in data structures for multiple reply types: sure you'd get the "A" but unless you updated the code to get the "AX" address (for ipv4X addresses) you could never get to the longer with address… just like IPv6 needed code updates to recognize AAAA, otherwise you were A-only.) You need to update socket APIs to hold new data structures for longer addresses so your app can tell the kernel to send packets to the new addresses. Just like with IPv6. A single residential connection that gets a single IPv4 address also gets to use all the /96 'behind it' with this IPv4x proposal? People complain about the "wastefulness" of /64s now, and this is even more so (to the tune of 32 bits). You'd probably be better served with pushing the new bits to the other end… like… * https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresses https://en.wikipedia.org/wiki/IPv6#IPv4-mapped_IPv6_addresse...

lxgr 7mo ago
Yes, I was wondering if I was missing something reading the hypothetical: This is still splits the Internet into two incompatible (but often bridged etc.) subnetworks, one on the v4, one on the v4x side, right? It just so happens that, unlike for v6, v4 and v4x have some "implicit bridges" built-in (i.e. between everything in v4 and everything in v4x that happens to have the last 96 bits unset). Not sure if that actually makes anything better or just kicks the can down the road in an even more messy way.
- xorcist 7mo ago

throw0101d 7mo ago

> Who owns all these new addresses? You do. If you own an IPv4 address, you automatically own the entire 96‑bit subspace beneath it. Every IPv4 address becomes the root of a vast extended address tree. It has to work this way because any router that doesn’t understand IPv4x will still route purely on the old 32‑bit address. There’s no point assigning part of your subspace to someone else — their packets will still land on your router whether you like it or not. So the folks that just happen to get in early on the IPv4 address land rush (US, Western world) now also get to grab all this new address space? What about any new players? This particular aspect idea seems to reward incumbents. Unlike IPv6, where new players (and countries and continents) that weren't online early get a chance to get equal footing in the expanded address space.

wmf 7mo ago
The new players would each get a /24 and everyone would say that's "enough".
- avidiax 7mo ago
  Yeah, and the value of IPv4 address space would plummet, and there would be no reason for any company to own a /8. Clawing back address space would involve a few emails and a few months to get network configs ready.
- throw0101d 7mo ago
  > The new players would each get a /24 and everyone would say that's "enough". From where? All then-existing IPv4 addresses would get all the bits behind them. There would, at the time, still be IPv4 addresses available that could be given out, and as people got them they would also get the extend "IPv4x" address associated with them. But at some point IPv4 addresses would all be allocated… along with all the extended addresses 'behind' them. Then what? The extended IPv4x addresses are attached to the legacy IPv4 addressed they are 'prefixed' by, so once the legacy bits are assigned, so are the new bits. If someone comes along post-legacy-IPv4 exhaustion, where do new addresses come from? You're in the exact same situation as we are now: legacy code is stuck with 32-bit-only addresses, new code is >32-bits… just like with IPv6. Great you managed to purchase/rent a legacy address range… but you still need a translation box for non-updated code… like with CG-NAT and IPv6.

themafia 7mo ago

IPv6 is fine. The advice on ULAs is garbage. The purpose of a protocol is to provide utility, not proscription.

simoncion 7mo ago
What's the advice on ULAs? On my internet-connected VLANs, I have a -er- site-local IPv4 subnet, a unique local IPv6 subnet, and a global IPv6 subnet. This works just fine. Does the "advice" boil down to "You should NEVER use ULAs and ALWAYS use GUAs!" and is given by the same very, very loud subset of people who seemed to feel very strongly that IPv6 implementations should explicitly make it impossible to do NAT?
- UltraSane 7mo ago
  Why would IPv6 ever need NAT?
  - simoncion 7mo ago
    Why would anyone need IPv6 to be incapable of doing NAT? To answer your question: Who knows? Perhaps you have a shitlord ISP that only provides you with a /128 (such as that one "cloud provider" whose name escapes me). [0] It's a nice tool to have in your toolbox, should you find that you need to use it. [0] Yes, I'm aware that a "cloud provider" is not strictly an ISP. They are providing your VMs with access to the Internet, so I think the definition fits with only a little stretching-induced damage.
    - UltraSane 7mo ago
      As a network admin I can say that NAT makes everything much harder and that the source and destination IP should stay the same from source to destination whenever possible.
      - simoncion 7mo ago
        Sure. I agree. That doesn't help when your shitbag ISP has given you exactly one /128.

lxgr 7mo ago

> The Version field must remain 4. And at the same time the address format and IP header is extended, effectively still splitting one network into two (one of which is a superset of the others)? A fundamentally breaking change remains a breaking change, whether you have the guts to bump your version number or not.

billpg 7mo ago
The central idea is that a IPv4x packet is still a globally routable IPv4 packet. The extra stuff all goes in the body of the packet.
- simoncion 7mo ago
  > The central idea is that a IPv4x packet is still a globally routable IPv4 packet. That's cool and all, but end-user edge routers are absolutely going to have to be updated to handle "IPv4x". Why? Because the entire point of IPvNext is to address address space exhaustion, their ISP will stop giving them IPv4 addresses. This means that the ISP is also going to have to update significant parts of their systems to handle "IPv4x" packets, because they're going to have to handle customer site address management. The only thing that doesn't have to change is the easiest part of the system to get changed... the core routers and associated infrastructure.
  - billpg 7mo ago
    Yes. The router in your home would absolutely need to support IPv4x if you wanted to make use of the extended address space, just like how in the real world your home router needs to support NAT if you want to make use of shared IP.
    - simoncion 7mo ago
      > The router in your home would absolutely need to support IPv4x if you wanted to make use of the extended address space... No. The router in your home would need to support IPv4x, or you would get no Internet connection. Why? Because IPv4x extends the address space "under" each IPv4 address -thus- competing with it for space. ISPs in areas with serious address pressure sure as fuck aren't going to be giving you IPv4 addresses anymore. As I mentioned, similarly, ISPs will need to update their systems to handle IPv4x, because they are -at minimum- going to be doing IPv4x address management for their customers. They're probably going to -themselves- be working from IPv4x allocations. Maybe each ISP gets knocked down from several v4 /16s or maybe a couple of /20s to a handful of v4 /32s to carve up for v4x customer sites. Your scheme has the adoption problems of IPv6, but even worse because it relies on reclaiming and repurposing IPv4 address space that's currently in use.

fulafel 7mo ago

This sounds a lot like what we have in 6to4 (for 25+ years now), where nodes behind two ipv4 derived prefixes can automatically talk to each other p2p, and use a gateway to communicate with the rest of the v6 internet.

billpg 7mo ago
Interesting. Who deploys and maintains the gateway?
- wmf 7mo ago
  That was one of the problems with 6to4. If there was no gateway or it was overloaded or there was a gateway but you couldn't reach it because of a weird firewall, all your IPv6 packets would be silently dropped and you'd have no idea why. And this was before happy eyeballs so your computer might default to broken IPv6.
- pocksuppet 7mo ago
  I think the intention was to use normal internet (anycast) routing to send it to the closest translator - which would be your ISP, or the nearest ISP that supports IPv6, or a tier 1 network which is happy to have extra traffic traversing its network unnecessarily since they get paid for all of it. (The same reason HE runs the free tunnel broker)
- fulafel 7mo ago
  You can configure it statically but there used to be the anycast address 192.88.99.1 and the idea was that you'll get routed to the nearest one by magic of BGP. It was retired once native IPv6 deployment took off. Apparently the practical problems were related to people haplessly firewalling it out (ref. https://labs.ripe.net/author/emileaben/6to4-why-is-it-so-bad/ https://labs.ripe.net/author/emileaben/6to4-why-is-it-so-bad...)

avidiax 7mo ago

Similar discussion from a couple of months ago: https://news.ycombinator.com/item?id=46468625 https://news.ycombinator.com/item?id=46468625 I personally feel that IPv6 is one of the clearest cases of second system syndrome. What we needed was more address bits. What we got was a nearly total redesign-by-committee with many elegant features but had difficult backwards compatibility. https://en.wikipedia.org/wiki/Second-system_effect https://en.wikipedia.org/wiki/Second-system_effect

lxgr 7mo ago
Which IPv6 “gratuitious” features (i.e. anything other than the decision to make a breaking change to address formats and accordingly require adapters) would you argue made adoption more difficult? IPv6 gets a lot of hate for all the bells and whistles, but on closer examination, the only one that really matters is always “it’s a second network and needs me to touch all my hosts and networking stack”. Don’t like SLAAC? Don’t use it! Want to keep using DHCP instead? Use DHCPv6! Love manual address configuration? Go right ahead! It even makes the addresses much shorter. None of that stuff is essential to IPv6. In fact, in my view TFA makes a very poor case for a counterfactual IPv4+ world. The only thing it really simplifies is address space assignment.
- iso1631 7mo ago
  Having both a real address, a link-local address, and a unique local address, and the requirement to use the right one in each circumstance The removal of arp and removal of broadcast, the enforcement of multicast The almost-required removal of NAT and the quasi-relgious dislike from many network people. Instead of simply src-natting your traffic behind ISP1 or ISP2, you are supposed to have multiple public IPs and somehow make your end devices choose the best routing rather than your router. All of these were choices made in addition to simply expanding the address scope.
  - lxgr 7mo ago
    > Having both a real address, a link-local address, and a unique local address, and the requirement to use the right one in each circumstance Only use the real one then (unless you happen to be implementing ND or something)! > The removal of arp and removal of broadcast, the enforcement of multicast ARP was effectively only replaced by ND, no? Maybe there are many disadvantages I'm not familiar with, but is there a fundamental problem with it? > The almost-required removal of NAT Don't like that part? Don't use it, and do use NAT66. It works great, I use it sometimes!

wmf 7mo ago

Similar discussion from 10 years ago: https://news.ycombinator.com/item?id=10854570 https://news.ycombinator.com/item?id=10854570

iso1631 7mo ago

30 years on and if I have a machine with an ipv6 only network and run "ping 1.1.1.1" it doesn't work. If stacks had moved to ipv6 only, and the OS and network library do the translation of existing ipv4, I think things would have moved faster. Every few months I try out my ipv6 only network and inevitably something fails and I'm back to my ipv4 only network (as I don't see the benefit of dual-stack, just the headaches) Sure you'd need a 64 gateway, but then that can be the same device that does your current 44 natting.

wmf 7mo ago
This works if you have 464xlat turned on. It's mostly used by phones though.
- zokier 7mo ago
  It's bit weird how despite Linux kernel having otherwise fairly advanced network stack, the 464xlat and other transition mechanism situation is not great. There are some out of tree modules (jool and nat46) available, but nothing in mainline. Does anyone know why that is?
  - jcgl 7mo ago
    NetworkManager just recently got CLAT! https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2107 https://gitlab.freedesktop.org/NetworkManager/NetworkManager... Issue for CLAT in systemd-networkd: https://github.com/systemd/systemd/issues/23674 https://github.com/systemd/systemd/issues/23674
    - iso1631 7mo ago
      And if that's applies across the board, in 20 years time that might have filtered through to mean ipv4 can be dropped in my company. I'd rather see this at a lower level than network manager and bodging in with bpf, so it's just a default part of any device running a linux network stack, but I don't know enough about kernel development and choices to know how possible that is in practice. This should have been supported in the kernel 25 years ago though if the goal was to help ipv6 migration

tonymet 7mo ago

in 100 years ipv4 will be recognized as one of the great discoveries like calculus. ipv6 is a misnomer really. It's a separate, and lesser protocol. Much like other second systems, it was too ambitious and not pragmatic enough. Rather than looking down on IPv4 , we should admire how incredible it's design was. Its elegance and intuitiveness, resourcefulness have all led to it outlasting every prediction of it's demise.

billpg 7mo ago

"IPv6 does that." Are you sure about that? Until a few years ago my residential ISP was IPv4 only. I definitely couldn't connect to an IPv6-only service back then.

massysett 7mo ago

“IPv6 is waiting for adoption” A major website sees over 46 percent of its traffic over ipv6. A major mobile operator has a network that runs entirely over ipv6. This is not “waiting for adoption” so I stopped reading there. https://www.google.com/intl/en/ipv6/statistics.html https://www.google.com/intl/en/ipv6/statistics.html https://www.internetsociety.org/deploy360/2014/case-study-t-mobile-us-goes-ipv6-only-using-464xlat/ https://www.internetsociety.org/deploy360/2014/case-study-t-...

billpg 7mo ago
You'd happily deploy a website for use by the general public on IPv6-only?
- simoncion 7mo ago
  I use Devouring Goats on your straw man. It's Super Effective! To be less glib: IPv6 is well-adopted. It's not universally adopted.
  - billpg 7mo ago
    Until you would happily deploy a service on IPv6 only, I suggest that you're still dependent on IPv4.
    - simoncion 7mo ago
      I'll repeat myself: IPv6 is well-adopted. It's not universally adopted.
- massysett 7mo ago
  No. Which doesn’t prove the technology has not been adopted. The internet also consists of much more than public-facing websites. So what’s your point?
  - billpg 7mo ago
    My point is that we're still dependent on IPv4. For all the progress IPv6 has made, no-one is willing to switch IPv4 off yet. Until we do, we're still constrained by all the problems IPv4 has.

billpg 7mo ago

Thanks for reading and commenting everyone! Note though that I'm not proposing IPv4x as something we should work towards now. Indeed, I come down on the side of being happy that we're in the IPv6 world instead of this alternative history.

dboreham 7mo ago

Em-dashes in this article. What is described here is basically just CIDR plus NAT which is...what we actually have. At the time IPv6 was being defined (I was there) CIDR was just being introduced and NAT hadn't been deployed widely. If someone had raised their hand and said "I think if we force people to use NAT and push down on the route table size with CIDR, I think it'll be ok" (nobody said that iirc), they would have been rejected because sentiment was heavily against creating a two-level network. After all having uniform addressing was pretty much the reason internet protocols took off.

commandersaki 7mo ago

I'm glad this exists, because it demonstrates there are ways to make a next-gen IP interoperable with IPv4, and that while IPng had interoperability has part of its assessment, it completely nixed it because they didn't want to go with the other proposals at the time which had some consideration for it.

throw0101d 7mo ago

> Who owns all these new addresses? You do. If you own an IPv4 address, you automatically own the entire 96‑bit subspace beneath it. Every IPv4 address becomes the root of a vast extended address tree. Huh: > For any 32-bit global IPv4 address that is assigned to a host, a 48-bit 6to4 IPv6 prefix can be constructed for use by that host (and if applicable the network behind it) by appending the IPv4 address to 2002::/16. > For example, the global IPv4 address 192.0.2.4 has the corresponding 6to4 prefix 2002:c000:0204::/48. This gives a prefix length of 48 bits, which leaves room for a 16-bit subnet field and 64 bit host addresses within the subnets. * https://en.wikipedia.org/wiki/6to4 https://en.wikipedia.org/wiki/6to4

aboardRat4 7mo ago

We should basically all call our ISPs and ask for ipv6 to be implemented.

nayuki 7mo ago

Their hypothetical approach of extending IPv4 reminds me of how TLS v1.3 masquerades as v1.2 in order to pass through meddling middleboxes safely.

linsomniac 7mo ago

It seems like this really only helps intermediate routers. All endpoints need to upgrade to IPv4x before anyone can reasonably use it. If I have servers on IPv4x, clients can reach my network fine, but they then can't reach individual servers. Clients need to know IPv4x to reach IPv4x servers. Similarly, IPv4x clients talking to IPv4 servers do what? Send an IPv4x packet with the remaining IPv4x address bits zeroed out? Nope a V4 server won't understand it. So they're sending an IPv4 packet and the response gets back to your network but doesn't know how to get the last mile back to the IPv4x client? I desperately wish there was a way to have "one stack to rule them all", whether that is IPv4x or IPv4 mapped into a portion of IPv6. But there doesn't seem to be an actually workable solution to it.

perennialmind 7mo ago
There's no viable alternative to dual stack with NAT now. We're stuck with it. But when IPv6 was standardized, a pure upgrade to IPv4 was still feasible. IPv4 allows for extensions headers and middleboxes hadn't yet imposed protocol ossification. If instead of the encapsulation the article supposes, the upgrade embraced translation, we could have had an IPv4+ with NAT fallback. A node on a network behind a IPv4+ router would send out a packet with the RFC1918 interior address encoded as the address extension. Either the server (which would have a proper IPV4 address) responds without the extension header, at which point the IPv4+ router at the edge has to do NAT-style connection tracking, or the response packet can be forwarded as-is. All the pain of upgrading software to a new protocol still applies, with the added headache of variable length addresses (4 bytes, 8 bytes, potentially more). But no ISP has to make the investments or take the risk of the parallel infrastructure. The IPv4 core carries on, with incremental improvements but zero mandatory upgrades.
- Dagger2 7mo ago
  Sure there is: use single-stack v6 with NAT64. What you're describing there is just an approach to store NAT state inside every packet instead of on the router. I'm not sure that's even an improvement on v4, but in any case it wouldn't increase the size of the address space so it wouldn't help with the one thing driving the need for IPv6.

sedatk 7mo ago

I actually disagree: that's the road taken. NAT is practically this. When you're behind a NAT, you're effectively using a 64-bit address space. Two more layers of NAT, and you can have 128-bit address space. "The first part" of the address is a globally routable IPv4 address, and the rest is kept by the routers on the path tracking NAT connection states. And NAT needed zero software changes. That's why it's won. It brought the benefits of whatever extension protocol with existing mechanisms of IPv4. IPv6 isn't an alternative to IPv4, it's an alternative to all IPv4xes.

jibal 7mo ago

Not a single discussion here of his SixGate proposal (but many mischaracterizations of IPv4x as a "proposal", when it was rather an alternate history). So HN.

billpg 7mo ago
le sigh Thanks though. Your comment really cheered me up.
- jibal 7mo ago
  > And yes, this whole piece was a sneaky way to get you to read my SixGate proposal. Too sneaky, apparently. I suggest putting something at the top mentioning it ... then even folks with very short attention spans will see it.

ralferoo 7mo ago

I've often thought similar thoughts to this because fundamentally, IPv4 should still be enough for us, except that we've chronically wasted lots of it. The first main issue is that most often we waste an entire IPv4 for things that just have a single service, usually HTTPS and also an HTTP redirector that just replies with a redirect to the HTTPS variant. This doesn't require an entire IPv4, just a single port or two. We could have solved the largest issue with address exhaustion simply by extending DNS to have results that included a port number as well as an IP address, or if browsers had adopted the SRV DNS records, then a typical ISP could share a single IPv4 across hundreds of customers. The second massive waste of IPv4 space is BGP being limited to /24. In the days of older routers when memory was expensive and space was limited, limiting to /24 makes sense. Now, even the most naive way of routing - having a byte per IP address specifying what the next hop is - would fit in 4GB of RAM. Sure, there is still a lot of legacy hardware out there, but if we'd said 10 years ago that the smallest BGP announcements would reduce from /24 to /32, 1 bit per year, so giving operators time to upgrade their kit, then we'd already be there by now. They've already spent the money on getting IPv6 kit which can handle prefixes larger than this, so it would have been entirely possible. And following on from the BGP thing is that often this is used to provide anycast, so that a single IPv4 can be routed to the geographically closest server. And usually, this requires an entire /24, even though often it's only a single port on a single IPv4 that's actually being used. Arguably, we don't even need BGP for anycast anyway. Again, going back to DNS, if the SRV record was extended to include an approximate location (maybe even just continent, region of continent, country, city) where each city is allocated a hierarchical location field split up roughly like ITU did for phone numbers, then the DNS could return multiple results and the browser can simply choose the one(s) that's closest, and gracefully fall back to other regions if they're not available. Alternatively, the client could specify their geo location during the request. So, basically, all of that can be done with IPv4 as it currently exists, just using DNS more effectively. We also have massive areas of IPv4 that's currently wasted. Over 8% of the space is in the 240.0.0.0/4 range that's marked as "reserved for future use" and which many software vendors (e.g. Microsoft) have made the OS return errors if it's used. Why? This is crazy. We could, and should, make use of this space, and specifically for usages where ports are better used, so that companies can share a single IPv4 at the ISP level. Another 8% is reserved for multicast, but nowadays almost nothing on the public IPv4 uses it and multicast is only supported on private networks. But in any case, 225.0.0.0/8-231.0.0.0/8 and 234.0.0.0/8-238.0.0.0/8 (collectively 12 /8s, or 75% of the multicast block) is reserved and should never have been used for any purpose. This too could be re-purposed for alleviating pressure on IPv4 space. Finally, there are still many IPv4 /24s or larger that are effectively being hoarded by companies knowing they can make good money from renting them out or selling them later. Rather than being considered an asset, we should be charging an annual fee to keep hold of these ranges and turn them into a liability instead, as that would encourage companies with a large allocation that they don't need to release them back. The other main argument against IPv4 is NAT, but actually I see that as a feature. If services actually had port number discovery via DNS, then forwarding specific ports to the server than deals with them is an obvious thing to do, not something exceptional. The majority of machines don't even want incoming connections from a security point of view, and most firewalls will block incoming IPv6 traffic apart from to designated servers anyway. The "global routing" promised by IPv6 isn't actually desired for the most part, the only benefit is when it is wanted you have the same address for the service everywhere. The logical conclusion from that is that IPv4 needs a sensible way of allocating a range of ports to individual machines rather than stopping just at the IP address. When you then look at IPv6 space, it initially looks vast and inexhaustible, but then you realise that the smallest routable prefix with BGP is /48, it should be apparent that it suffers from essentially the same constraints as IPv4. All of "the global internet" is in 2002::/16, which effectively gives 32 bits of assignable space. Exactly the same as IPv4. Even more, IPv6 space is usually given out in /44 or /40 chunks, which means it's going to be exhausted at almost the same rate as IPv4 given out in /24 chunks. So much additional complexity, for little extra gain, although I will concede that as 2003::/16 to 3ffe::/16 isn't currently allocated there is room to expand, as long as routers aren't baking in the assumption that all routable prefixes are in 2001::/16 as specified. TLDR: browsers should use SRV to look up ports as well as addresses, and SRV should return geo information so clients can choose the closest server to them. If we did that, the IPv4 space is perfectly large enough because a single IPv4 address can support hundreds or thousands of customers that use the same ISP. Effectively a /32 IPv4 address is no different to a /40 IPv4 prefix, and the additional bits considered part of the address in IPv6 could be encoded in the port number for IPv4.

HocusLocus 7mo ago

I tend to give the lack of credible ready to deploy asteroid response for Earth defense 41 years after consensus was reached on the KT boundary, 70 years since the 'space age' began, much greater weight. Motivation for retiring IPv4 completely would NOT be to make the world a better more route-able place. It would be to deliberately obsolescence old products to sell new.

JackSlateur 7mo ago

Yes It is awesome until you understand that most equipement expect a TCP or UDP header; Then, with IPv4x, they find none, and drop the packet; Protocol ossification is a real thing and the main bane in this topic

billpg 7mo ago
An earlier draft had a section discussing how IPv4x would work with NAT routers. Essentially, an IPv4x packet would be a UDP/IPv4 packet using a port number (84) that's been allocated to IPv4x. Old routers would be a normal UDP packet inside a normal IPv4 and route it normally. New routers would detect UDP port 84 and treat it as an extended IPv4x packet. I took all that out because I wasn't writing a proposal for something we should actually implement in the real world, but an alternate history "What if people who wanted IPv4 but with extra space got their way" and the story was already too long.

zadikian 7mo ago

It's not too late to do something kinda like this using the ipv6 packet format, since routers already understand that. They'd put the whole "ipv4x" address space under a prefix.

Dagger2 7mo ago
We already did it decades ago, with 6to4. The extra address space is under 2002:<v4 address>::/48.
- zadikian 7mo ago
  v4-mapped v6 (rfc4038), not 6to4, right? It was only a transition feature and not how v6 was rolled out by default. I don't even have such an address. You enable v6 and it suddenly means you're reachable with the new addresses, typically assigned via slaac. Also idk if v4-mapped was meant to be split beyond /32s.