Live data from Hacker News

Enabling IPv6 support for IPv4-only apps on Linux

blog.apnic.net

181–190 of 199 posts

Re: Enabling IPv6 support for IPv4-only apps on Linux

#181
post #159

Earlier quoted context omitted.

Some of this is unavoidable while fixing the scaling problems of IPv4. Longer addresses are never going to be preferable for users over shorter addresses, but addresses are necessarily going to be longer than IPv4 if it's going to support more devices.

The existing users that already have short addresses should be able to keep them (ignoring the trailing 0s), and even the newer longer ones don't need to be 128 bits.

::ffff: is a perfectly valid V6 address. The problem is not the user facing representation but all the software and hardware implementations, including in middleboxes in between client and server.

128 is no different to 33 bits, or 32 bits plus extension header in that regard.

Re: Enabling IPv6 support for IPv4-only apps on Linux

#182

Earlier quoted context omitted.

It's not actually secure; your router will route inbound packets to whatever IP is in the packet's destination header, and that can be a machine on your LAN. This remains true whether or not you're applying NAT to your outbound connections. If anything, NAT makes you less secure by tricking you into a false sense of security. (It's also worse if you're deliberately running servers, because it catastrophically reduces…

> your router will route inbound packets to whatever IP is in the packet's destination header, and that can be a machine on your LAN The dst is going to be the router's address, not one of the LAN's private IPs.

Not necessarily. What enforces that? You can't rely on your attackers to kindly not send traffic to IPs you don't want them to.

Re: Enabling IPv6 support for IPv4-only apps on Linux

#183

Earlier quoted context omitted.

> your router will route inbound packets to whatever IP is in the packet's destination header, and that can be a machine on your LAN The dst is going to be the router's address, not one of the LAN's private IPs.

Not necessarily. What enforces that? You can't rely on your attackers to kindly not send traffic to IPs you don't want them to.

The routers. My ISP can't route dst=192.168.1.2 to anywhere, and even if someone managed to splice the packet in between my router and the ISP, my router won't take that dst. That address doesn't exist on the WAN.

Re: Enabling IPv6 support for IPv4-only apps on Linux

#184

Earlier quoted context omitted.

There's no IPv6 adoption problem in the consumer and developing world space. The remaining adoption hold-outs are corporate interests and the reasons for their hold-outs have generally nothing to do with BGP or other dissimilarities between v4 and v6, and everything to do with cargo culting "security best practices", sunk cost fallacy, and kind of generally wealth (massive ancient investments in IPv4 address space, i…

Enough things are v4-only that I can't go all-v6 at home, and that's predicated on my home ISP giving a v6 address, which hasn't been a given. V6 does seem intended to replace v4, otherwise I don't see the point; it's preferable to run one stack rather than two, and v4 is the easier choice still.

Why would the point of v6 be to entirely replace v4? That's such an impossible to accomplish goal even if v6 was the most perfect protocol to ever exist and even if you didn't believe that by that point v4 was embedded in so much hardware as to be physically impossible to replace without incredible amounts of hardware recycling problems, including some dangerous deep sea diving and missions to space. Even in your own home you indicate you likely have hardware that you aren't in a hurry to replace.

The point of IPv6 was always to build an internet that could address the next several billion devices. IPv4 addressed way more devices than its developers ever intended and did an arguably above-and-beyond job at addressing the first billion or so. (We can argue for hours though on how hacks like NAT44 have broken some of the original spirit of IPv4, of course, in the course of prolonging its useful device addressing lifespan.) IPv6 is succeeding in that. There are emerging world devices getting addressed that could never afford a cramped IPv4 address. There are nearly as many mobile devices running IPv6-only or IPv6-first as servers in the first couple of decades of IPv4.

Will all of the "first billion" devices move to the new protocol? On the one hand, probably not. On the other hand, does it matter? The dream of the internet was always about bridging a bunch of networks that had no right talking to each other and that many people thought it impossible that they would ever speak common protocols. There's only one internet because no matter how complicated it gets, people are still cobbling together incredible ways for different stacks to talk to each. This is how the internet was built, this is how the internet will always exist. This was true in the era when internet tools were built out of putty around unix-to-unix copy somehow speaking to VAX servers across an Appletalk bridge to a token ring ethernet adapter to a proprietary IBM Mainframe protocol. It is still the case with IPv4 and IPv6 acting as side-by-side "friends" working together for the common good of the internet.

The internet doesn't really care if you only want to run "one stack" instead of two if you are fine that an increasing amount of your traffic is going through the equivalents of an Appletalk bridge, who may start charging for it at some point (or are volunteers running it for fun and might get bored). (I think in this analogy the biggest one of those Appletalk bridges is Cloudflare? Even I can't tell if I'm joking or not. It does explain some things about CF's business model.) It will take decades for it to get to that, though.

Anecdotally, my home ISP grants me an IPv6 allotment and I've noticed quite a bit of traffic using it. It's kind of fascinating because my current Wifi router indeed has some sort of memory pressure issue with some combo of IPv4 BGP routes and NAT44 firewall states and just entirely falls apart routing IPv4 at some point when it has been running for long enough. My previous employer's IPv4-only VPN seemed to especially stress it for whatever reasons, during WFH life, and I'd have to restart the router somewhat regularly for it to start routing IPv4 correctly again. IPv6 traffic just worked even when the router was dying on IPv4 traffic. If I wasn't on my work laptop or trying to use a site like HN or GitHub, I could go sometimes hours to days before realizing IPv4 addressing was broken again. My "prosumer" perspective is IPv6 is the reliable stack I use most often (gaming, lots of daily browsing, key apps I rely on, even many of my consumer devices just quietly falling back to 464XLAT and "Teredo" tunnels and still reaching IPv4 stuff despite my local router falling apart) and IPv4 the increasingly weird and flaky stack. I only know I can point a finger at IPv4 because I'm just enough of a nerd to do small bits of debugging when it happens out of curiosity, but it is an interesting pattern, anecdotally.

Re: Enabling IPv6 support for IPv4-only apps on Linux

#185
post #181

Earlier quoted context omitted.

The existing users that already have short addresses should be able to keep them (ignoring the trailing 0s), and even the newer longer ones don't need to be 128 bits.

::ffff: is a perfectly valid V6 address. The problem is not the user facing representation but all the software and hardware implementations, including in middleboxes in between client and server. 128 is no different to 33 bits, or 32 bits plus extension header in that regard.

It's valid but not routable in practice. The Internet collectively didn't choose to map existing IPv4 addresses into v6 or keep the routing unified, that's the problem. It should've been that 1.1.1.1 on v4 now owns 1.1.1.1/32 on v6, so going all-v6 doesn't mean cutting yourself off from v4 hosts. Once v6 was well-adopted, they could start using the longer addresses. Instead, we got two totally separate networks.

Re: Enabling IPv6 support for IPv4-only apps on Linux

#186
post #181

Earlier quoted context omitted.

::ffff: is a perfectly valid V6 address. The problem is not the user facing representation but all the software and hardware implementations, including in middleboxes in between client and server. 128 is no different to 33 bits, or 32 bits plus extension header in that regard.

It's valid but not routable in practice. The Internet collectively didn't choose to map existing IPv4 addresses into v6 or keep the routing unified, that's the problem. It should've been that 1.1.1.1 on v4 now owns 1.1.1.1/32 on v6, so going all-v6 doesn't mean cutting yourself off from v4 hosts. Once v6 was well-adopted, they could start using the longer addresses. Instead, we got two totally separate networks.

This is an "IPv6" network that does not allow for more users. The IPv4 network space is already depleted. This is why mobile ISPs, Indian ISPs etc. are all dual stack with CGNAT for IPv4.

Perhaps you meant to suggest that they should own 1.1.1.1::/64 or 1.1.1.1/128 (or 1:1:1:1::/64)?

Even if it's the latter case, both the actual ::ffff:1.2.3.4 (or it's predecessor ::1.2.3.4) have the problem that some middle box receives a packet for 1.1.1.1::abcd:1234, doesn't understand the header the abcd:1234 portion is encoded in, throws it away, and the router at 1.1.1.1 receives a packet which is destined for some unknown device behind the router with no info for how to get the packet to that device.

Re: Enabling IPv6 support for IPv4-only apps on Linux

#187

Earlier quoted context omitted.

Upgrading the routers is a monumental task and handling the "transition" when some routers are upgraded with v4.1 and some are not is impossible. What happens during the transition when a v4.1 source tries to send data to a v4 destination? The v4 can't talk back. You can't fit 64 bits in a 32 bit address. This is the same problem as with v6.

Right, it only converts to v4 if both src and dst are 32-bit, which is fine in v4.1 too. Everyone can adopt v4.1 hardware/software without even thinking about it but hold off on using >32-bit addrs until they feel like enough peers are on v4.1. Yes it's only a one-way compatibility, but that's way better than v6 which is incompatible both ways, creating gridlock. If you really want extra compatibility, idk if this is…

I think you underestimate the complexity of deploying a new protocol like that.

Also, you know NAT64 exists, right? You can have a v6 only network connecting to v4 hosts. Is that not enough compatibility if you don't want dual stack hosts?

Re: Enabling IPv6 support for IPv4-only apps on Linux

#188
post #186

Earlier quoted context omitted.

It's valid but not routable in practice. The Internet collectively didn't choose to map existing IPv4 addresses into v6 or keep the routing unified, that's the problem. It should've been that 1.1.1.1 on v4 now owns 1.1.1.1/32 on v6, so going all-v6 doesn't mean cutting yourself off from v4 hosts. Once v6 was well-adopted, they could start using the longer addresses. Instead, we got two totally separate networks.

This is an "IPv6" network that does not allow for more users. The IPv4 network space is already depleted. This is why mobile ISPs, Indian ISPs etc. are all dual stack with CGNAT for IPv4. Perhaps you meant to suggest that they should own 1.1.1.1::/64 or 1.1.1.1/128 (or 1:1:1:1::/64)? Even if it's the latter case, both the actual ::ffff:1.2.3.4 (or it's predecessor ::1.2.3.4) have the problem that some middle box rece…

Yes, it wouldn't allow more users, which would've been fine back then. They'd focus on getting everyone onto the v6 protocol first, then open up the new addresses for use. That's the transition period that never happened.

Re: Enabling IPv6 support for IPv4-only apps on Linux

#189
post #186

Earlier quoted context omitted.

This is an "IPv6" network that does not allow for more users. The IPv4 network space is already depleted. This is why mobile ISPs, Indian ISPs etc. are all dual stack with CGNAT for IPv4. Perhaps you meant to suggest that they should own 1.1.1.1::/64 or 1.1.1.1/128 (or 1:1:1:1::/64)? Even if it's the latter case, both the actual ::ffff:1.2.3.4 (or it's predecessor ::1.2.3.4) have the problem that some middle box rece…

Yes, it wouldn't allow more users, which would've been fine back then. They'd focus on getting everyone onto the v6 protocol first, then open up the new addresses for use. That's the transition period that never happened.

The only motivation for the ISPs etc., who you need to get onboard, is to get more users. This is why IPv6 adoption has been soaring in the last 3-4 years when there's large new use cases that cannot economically get addresses in the volume they would require and didn't happen when IPv4 addresses were more freely available.

The only other way to get them to invest in alternatives to IPv4 before IPv4 stopped meeting their business needs would have been via regulation.

Re: Enabling IPv6 support for IPv4-only apps on Linux

#190
post #181

Earlier quoted context omitted.

::ffff: is a perfectly valid V6 address. The problem is not the user facing representation but all the software and hardware implementations, including in middleboxes in between client and server. 128 is no different to 33 bits, or 32 bits plus extension header in that regard.

It's valid but not routable in practice. The Internet collectively didn't choose to map existing IPv4 addresses into v6 or keep the routing unified, that's the problem. It should've been that 1.1.1.1 on v4 now owns 1.1.1.1/32 on v6, so going all-v6 doesn't mean cutting yourself off from v4 hosts. Once v6 was well-adopted, they could start using the longer addresses. Instead, we got two totally separate networks.

You are describing 6to4, where 1.1.1.1 owns 2002:101:101::/48.
Post reply on HN