Live data from Hacker News

Enabling IPv6 support for IPv4-only apps on Linux

blog.apnic.net

111–120 of 199 posts

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

#111

Why is this not just default behaviour? If I don't have IPv4 connectivity, yet a 6-to-4 gateway exists and I have IPv6 connectivity, and some app tries to use IPv4, then clearly the gateway should be used. How about some sysfs config option that says "redirect ipv4 to 6to4 gateway if no default ipv4 route exists", enabled by default.

Yeah I agree this does seem like something that really ought to simply be configurable out of the box with options for transparently handling both 6-to-4 and 4-to-6 when the appropriate services are discoverable or configured on the network. The top level reply here discussing how MacOS handles it seems like something that should be able to be recreated with iptables, but when searching I am extremely surprised to di…

Linux is usually king when it comes to networking and configurability - so I too am really surprised it isn't an option to do something sane.

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

#112

Coming from the Apple ecosystem, this is solved on macOS/iOS by a native implementation of 464XLAT on the device (particularly the CLAT relay part.) If you have a working NAT64/DNS64 setup, macOS can make a AAAA (ipv6 DNS) request to ipv4only.arpa, and observe the form the result comes back as, in order to learn the IPv6 prefix used for IPv4 compatibility on the network (eg. 64:ff9b::/96), and if it's not given an IP…

The largest problem with this is that that this IPv6 router lives outside of your devices. It lives somewhere at the ISPs infrastructure. And this causes a massive headache when it comes to systems that track you based on your IPv4 address. For example there are applications that track you by your IP address. And if you want to opt-out they refuse because the IPv4 address you give them is owned by T-Mobile. Also, it…

Google and Apple have both established an unofficial standard that any middleboxes that keep state (eg. NAT) has to keep a session open for 30 minutes for both TCP and UDP. Anyone that doesn't will have push notifications failing as you've pointed out.

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

#113
post #41
post #19

Earlier quoted context omitted.

You can do finer-grained subnets with DHCP than SLAAC will give you.

As a general rule, if you're deploying IPv6 subnets sized as anything other than /64, you're doing it wrong

It's all too common for ISPs to give you just a single /64 going into your home.

So if you want to define subnets within that, you're "doing it wrong"? Nah. Just use DHCPv6 and be happy.

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

#114

Why is this not just default behaviour? If I don't have IPv4 connectivity, yet a 6-to-4 gateway exists and I have IPv6 connectivity, and some app tries to use IPv4, then clearly the gateway should be used. How about some sysfs config option that says "redirect ipv4 to 6to4 gateway if no default ipv4 route exists", enabled by default.

The right solution for Linux would be 464XLAT support in systemd: https://github.com/systemd/systemd/issues/23674

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

#115

Coming from the Apple ecosystem, this is solved on macOS/iOS by a native implementation of 464XLAT on the device (particularly the CLAT relay part.) If you have a working NAT64/DNS64 setup, macOS can make a AAAA (ipv6 DNS) request to ipv4only.arpa, and observe the form the result comes back as, in order to learn the IPv6 prefix used for IPv4 compatibility on the network (eg. 64:ff9b::/96), and if it's not given an IP…

Author is here.

Thank you for sharing! Yes, macOS has such logic and it works just fine. The main issue from clatd that it's pretty tricky to setup and it emulates presence of IPv4 on machine which is not very desirable as it tends to hide issues with other tools.

My plan was to explicitly disable IPv4 connectivity for machine and hide it from other app but keep it active for subset of well known broken tools and then fix them one by one and switch to IPv6 only setup.

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

#116
post #24

Earlier quoted context omitted.

Can't you provide DNS servers as part of router advertisement packets ? RFC8106

This requires client support though, which isn't a given.

That is most operating systems and devices these days.

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

#117

Super cool! I tried doing a pure IPv6 network a little over a decade ago; Maybe I’ll try it again. Though, my cheap IoT devices likely still need IPv4… but perhaps not internet connectivity. It might be fun to explore just how much IPv4 continues to be ingrained into cheap Things (eg: Arduino WiFI?) There always seems to be a long tail of small places where IPv4 pops straight back into the equation.

Small places? When I disabled IPv4 a few weeks ago, I couldn't use: HN, GitHub, Reddit, Discord, Duckduckgo.

I don't have IPv6 enabled. Literally everything works.

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

#118
post #113
post #41

Earlier quoted context omitted.

As a general rule, if you're deploying IPv6 subnets sized as anything other than /64, you're doing it wrong

It's all too common for ISPs to give you just a single /64 going into your home. So if you want to define subnets within that, you're "doing it wrong"? Nah. Just use DHCPv6 and be happy.

Name and shame the ISP! And update your DHCPv6 Prefix Delegation request for a larger prefix (try /60, that seems to be a common supported PD size for most at home ISPs).

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

#119

So when and how will IPv6 become the absolute standard? I presume an act of government law would do it, otherwise, if tech companies got together to force the change en masse, that would also do it. I don't understand why IPv6 has not become more prevalent over the coming years. Seems like we're taking baby steps and growing in our dependence on IPv4 IPs, although based on other comments here it sounds like at least…

Possibly never, because security. NAT at least tries to hide insecure IoT device on your grandma's wifi. shodan.io has support for ipv6. With ipv4 you're somewhat restricted to devices that get public ip (corporate networks) or devices that drill a hole (uPnP/port forward). IPv6 devices are publicly visible by default and you need to manually setup firewall to filter this out (not trivial - especially for UDP and ICM…

Every firewall I’ve dealt with since forever has default deny on inbound traffic, state full allow for outbound connections. Regardless of NAT or not, and regardless of how cheap it is.
Post reply on HN