Enabling IPv6 support for IPv4-only apps on Linux • Hacker News Board

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

#171

Post by hot_gril » Thu, Oct 05, 2023, 3:32 PM UTC

WorldMaker wrote: post #164

hot_gril wrote: post #162

Earlier quoted context omitted.

The only reason v6 is dual stack is because they're changing all the existing addresses and routing. If you're only creating a second header format that everything is updated to support, it can be mostly unified. Routing tables etc would all shared. > end-to-end connectivity is how the internet is supposed to work This is the secondary motive of ipv6 that makes it not happen, cause not enough people agree with this s…

> The only reason v6 is dual stack is because they're changing all the existing addresses and routing. If you're only creating a second header format that everything is updated to support, it can be mostly unified. Routing tables etc would all shared. A new header format is a new version of IP. That's how it was designed. That's the compatibility story of IP. There is no way (there never was a way) to change the IPv4…

You can call it a separate stack if you want, either way, the difficulty of going v6 comes from having totally separate addresses and routes as opposed to sharing everything. Basically every system out there is already capable of handling ipv6 headers, but they don't use it.

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

#172

Post by icedchai » Thu, Oct 05, 2023, 4:17 PM UTC

hot_gril wrote: post #171

WorldMaker wrote: post #164

Earlier quoted context omitted.

> The only reason v6 is dual stack is because they're changing all the existing addresses and routing. If you're only creating a second header format that everything is updated to support, it can be mostly unified. Routing tables etc would all shared. A new header format is a new version of IP. That's how it was designed. That's the compatibility story of IP. There is no way (there never was a way) to change the IPv4…

You can call it a separate stack if you want, either way, the difficulty of going v6 comes from having totally separate addresses and routes as opposed to sharing everything. Basically every system out there is already capable of handling ipv6 headers, but they don't use it.

If you increase the size of the address with "v4.1", you have the same situation as v6: a new protocol. How are you going to announce "v4.1" routes without updating BGP? You can't.

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

#173

Post by hot_gril » Thu, Oct 05, 2023, 4:56 PM UTC

icedchai wrote: post #172

hot_gril wrote: post #171

Earlier quoted context omitted.

You can call it a separate stack if you want, either way, the difficulty of going v6 comes from having totally separate addresses and routes as opposed to sharing everything. Basically every system out there is already capable of handling ipv6 headers, but they don't use it.

If you increase the size of the address with "v4.1", you have the same situation as v6: a new protocol. How are you going to announce "v4.1" routes without updating BGP? You can't.

You'd update BGP and the routers. They'd support both v4 and v4.1 packets with unified routing. All existing ownership of /32s from ipv4 would get carried over. Say v4.1 addrs are 64-bit max. V4.1 dst=1.2.3.4.53.2.1 could get BGP-routed to a 1.2.3/24 router, routed to a 1.2.3.4/32, to 1.2.3.4.53/40, to the dst. Also, during the transition period, a v4.1 packet addressed to a 32-bit addr would get auto-translated to v4.

This is unlike v6, which cannot address anything inside the v4 space. v6 and v4 are totally separate planes.

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

#174

Post by imoverclocked » Thu, Oct 05, 2023, 5:07 PM UTC

p1mrx wrote: post #155

tsimionescu wrote: post #149

Earlier quoted context omitted.

Device counting has always been possible with IPv4 routers, and yet I don't know of a single ISP which does this. To be clear, I'm talking of ISP-provided (usually wifi) routers, which at least in my country are extremely common. Those could receive an IPv6 prefix and do DHCPv6 inside your own network.

The concept of an IPv4 NAT router exists today because people in the '90s wanted to connect multiple devices without permission from their ISP. SLAAC lets you extend a network without permission using ND Proxy, whereas DHCPv6 IA_NA can only be extended using NAT. So I think SLAAC is good because ND Proxy is less evil than NAT.

> whereas DHCPv6 IA_NA can only be extended using NAT.

Pedantically, it doesn’t force that but it can, right?

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

#175

Post by icedchai » Thu, Oct 05, 2023, 5:25 PM UTC

hot_gril wrote: post #173

icedchai wrote: post #172

Earlier quoted context omitted.

If you increase the size of the address with "v4.1", you have the same situation as v6: a new protocol. How are you going to announce "v4.1" routes without updating BGP? You can't.

You'd update BGP and the routers. They'd support both v4 and v4.1 packets with unified routing. All existing ownership of /32s from ipv4 would get carried over. Say v4.1 addrs are 64-bit max. V4.1 dst=1.2.3.4.53.2.1 could get BGP-routed to a 1.2.3/24 router, routed to a 1.2.3.4/32, to 1.2.3.4.53/40, to the dst. Also, during the transition period, a v4.1 packet addressed to a 32-bit addr would get auto-translated to v…

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.

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

#176

Post by WorldMaker » Thu, Oct 05, 2023, 5:32 PM UTC

hot_gril wrote: post #173

icedchai wrote: post #172

Earlier quoted context omitted.

If you increase the size of the address with "v4.1", you have the same situation as v6: a new protocol. How are you going to announce "v4.1" routes without updating BGP? You can't.

You'd update BGP and the routers. They'd support both v4 and v4.1 packets with unified routing. All existing ownership of /32s from ipv4 would get carried over. Say v4.1 addrs are 64-bit max. V4.1 dst=1.2.3.4.53.2.1 could get BGP-routed to a 1.2.3/24 router, routed to a 1.2.3.4/32, to 1.2.3.4.53/40, to the dst. Also, during the transition period, a v4.1 packet addressed to a 32-bit addr would get auto-translated to v…

BGP was already creaking under exponential growth effects under v4. It was the opinion of engineers deeper in that than me that BGP as it stood wouldn't have supported the weight of routes beyond 32-bits without massive tables that would not scale well at all. BGP was considered to be on the list of things that drastically needed to change as the address space expanded. (Again, you don't have to take my word for it, the IETF notes are of the various debates are generally public and so are the resulting RFCs.)

You are doing a lot of magic heavy lifting in "You'd update BGP and the routers" as if there was a way to do that with a "small point update", especially once you realize how much firmware and hardware was always the issue that needed changing; updating IP was never an easy software-only problem. Just because you think you can imagine it doesn't mean it was technically feasible, especially at internet scale. Engineers spent years exploring options before they arrived at the IPv6 proposals. The space/memory inefficiency of v4 BGP was one of the problems they had to address. Sure, they felt a need to address it with a brand new protocol with less resemblance to BGP than some would have liked, but that wasn't because they were a priori trying to make life more difficult for everyone: they wanted devices to be able to route IPv6 without needing GBs to TBs of RAM just for routes and were afraid that "just use good old BGP but massively extended with a larger address space" was going to go that way and possibly quickly.

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

#177

Post by hot_gril » Thu, Oct 05, 2023, 5:53 PM UTC

icedchai wrote: post #175

hot_gril wrote: post #173

Earlier quoted context omitted.

You'd update BGP and the routers. They'd support both v4 and v4.1 packets with unified routing. All existing ownership of /32s from ipv4 would get carried over. Say v4.1 addrs are 64-bit max. V4.1 dst=1.2.3.4.53.2.1 could get BGP-routed to a 1.2.3/24 router, routed to a 1.2.3.4/32, to 1.2.3.4.53/40, to the dst. Also, during the transition period, a v4.1 packet addressed to a 32-bit addr would get auto-translated to v…

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 a good idea but it's an option... Go v4.1 using up to 40-bit addresses for now (but leave room for more). Translate a v4.1 TCP/IP packet with a 40-bit src and 32-bit dst to v4, truncating the last 8 bits of the src IP, provided the last 8 of the src port matches them. IPv4-only dst can respond fine. When that /32 v4.1 router receives the v4 response, set the last 8 bits of the dst IP to the last 8 of the dst port. So it's kinda like NAT except translating to a public /40 IPv4.1 instead of a private IPv4. Actual NAT on the /40 addrs gets the remaining 8 bits for the src port. And you just speak v4.1 without all this if the dst is >32 bits.

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

#178

Post by hot_gril » Thu, Oct 05, 2023, 6:01 PM UTC

WorldMaker wrote: post #176

hot_gril wrote: post #173

Earlier quoted context omitted.

You'd update BGP and the routers. They'd support both v4 and v4.1 packets with unified routing. All existing ownership of /32s from ipv4 would get carried over. Say v4.1 addrs are 64-bit max. V4.1 dst=1.2.3.4.53.2.1 could get BGP-routed to a 1.2.3/24 router, routed to a 1.2.3.4/32, to 1.2.3.4.53/40, to the dst. Also, during the transition period, a v4.1 packet addressed to a 32-bit addr would get auto-translated to v…

BGP was already creaking under exponential growth effects under v4. It was the opinion of engineers deeper in that than me that BGP as it stood wouldn't have supported the weight of routes beyond 32-bits without massive tables that would not scale well at all. BGP was considered to be on the list of things that drastically needed to change as the address space expanded. (Again, you don't have to take my word for it,…

I don't mean to downplay the difficulty of supporting longer addresses in these systems, but it's been done for v6 already. That technical challenge has been mostly solved, and an adoption problem has taken its place.

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

#179

Post by WorldMaker » Thu, Oct 05, 2023, 6:42 PM UTC

hot_gril wrote: post #178

WorldMaker wrote: post #176

Earlier quoted context omitted.

BGP was already creaking under exponential growth effects under v4. It was the opinion of engineers deeper in that than me that BGP as it stood wouldn't have supported the weight of routes beyond 32-bits without massive tables that would not scale well at all. BGP was considered to be on the list of things that drastically needed to change as the address space expanded. (Again, you don't have to take my word for it,…

I don't mean to downplay the difficulty of supporting longer addresses in these systems, but it's been done for v6 already. That technical challenge has been mostly solved, and an adoption problem has taken its place.

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, including some ancient early windfalls when companies like Microsoft and GE got /8s just for asking in the right years; for now a lot of corporate America can easily afford to only support IPv4 for "business operations" so long as they don't have to deal with some major consumer networks).

There are major IPv6-only consumer networks (it's now quite common among the mobile carriers). IPv6 routing is starting to be generally faster and more reliable for consumers. Consumers have easily adopted v6 mostly without realizing it. ("Happy Eyeballs", indeed.)

There's no "adoption problem". It is adopted. It is working as intended. Will there be a day that we "turn off v4 for good"? Probably not, but every engineer who helped build v6 should have been well aware of Postel's Law and its many corollaries and the root "Internet law" that "no matter how many networks exist, they will always communicate and cooperate; there are many networks but only one Internet". IPv1 and IPv2 likely will always be the only IP versions to truly die and that will always be an historic accident of when IPv4 was devised while the Internet was still mostly young and "just" a research project among academics. Killing IPv4 was never the goal of IPv6, it had to live side-by-side, and everyone knew it. Is IPv6 a "success" at current adoption rates? Success is subjective. Obviously we disagree on how successful it is/has been. That may not change, because they are and always will be opinions.

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

#180

Post by hot_gril » Thu, Oct 05, 2023, 7:27 PM UTC

WorldMaker wrote: post #179

hot_gril wrote: post #178

Earlier quoted context omitted.

I don't mean to downplay the difficulty of supporting longer addresses in these systems, but it's been done for v6 already. That technical challenge has been mostly solved, and an adoption problem has taken its place.

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.