Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Enabling IPv6 support for IPv4-only apps on Linux

blog.apnic.net

Post reply on HN
Print view View original

101–110 of 199 posts

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

#101

Post by keep_reading »

VoodooJuJu wrote: post #97
kuon wrote: post #86

Discord hardcodes ipv4 addresses and will not work for webrtc calls in DNS64 setup. In 2023 I consider it an insult to the internet as a whole.

IPv6 is an insult.

- we never got the integrated IPSEC

- enough addresses for everyone on the planet, but we can't freely give out permanent static allocations to everyone because it would explode the routing tables

- so we never got our permanent roaming addresses we were promised

- NAT66 exists

- IPv6 was (still is?) a moving target for implementors

It's worse than an insult

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

#102

Post by josephcsible »

finaard wrote: post #53

Would be interesting to know which applications actually have problems with v6 - the example with directly using a v4 IP is more a user error, not an application issue. I pretty much stopped submitting patches enabling v6 functionality to various projects back in 2005 as everything I cared about was working at that point. (Side note, I was just trying to search a few of those - but seems that period pretty much doesn…

Docker's support for IPv6 is really poor. Basics are still gated behind the "experimental" flag, and there are bugs that have been open for years preventing very common configurations from working.

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

#103

Post by hatch_q »

giancarlostoro wrote: post #94

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 ICMP)

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

#104

Post by toast0 »

tsimionescu wrote: post #50
dspillett wrote: post #46

Earlier quoted context omitted.

> I recently had to setup a non-encrypted website because I have a few old devices that can no longer do HTTPS. That sounds like they haven't been updated for TLS>1.1 – if that is the case then rather than going all the way down the HTTP you could enable TLS1.1 (and maybe 1.0). It is open to POODLE/BEAST/others that way, but still have some protection and the site's configuration differs less from the rest of your in…

Is there any way to get a certificate that these old devices would trust and that would work over TLS < 1.2?

Technically the certificate issues are separate from the protocol versioning. It's just that clients that don't support TLS 1.2 often also don't support sha2 certificates or may not have a path to validate certificates from currently available CAs (although you can usually push through that; no protocol support and no cert signature support is not a user bypass prompt)

As a side note, barely anything supports TLS 1.1 but not TLS 1.2

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

#105

Post by p1mrx »

tsimionescu wrote: post #49
darkr wrote: 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

The only reason for that "rule" is SLAAC.

I think SLAAC's /64 limit functions as a "trojan horse" forcing ISPs to give everyone at least 64 bits of address space. Most would allocate /112-/128 per customer if it were slightly easier.

Designing the internet with lots of unused space at the edges will probably be useful in 100 years.

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

#106

Post by WirelessGigabit »

e61133e3 wrote: post #88
ninkendo wrote: post #81

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…

Where can I find documentation about this?

T-Mobile has it in the USA for their mobile network.

https://archive.nanog.org/sites/default/files/wednesday_gene...

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

#107

Post by WirelessGigabit »

ninkendo wrote: post #81

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 completely breaks stateless applications.

When you have an IPv4 IPv4 UDP tunnel you can just send traffic. If one device is behind NAT you set up port forwarding. It'll work today, it'll work tomorrow, and in 2 years.

The tunnel that the NAT64 system sets up is time-bound. So while outgoing traffic re-establishes the route, incoming traffic is not stateless. It stops.

I have this issue with WireGuard and iOS. The iOS implementation sadly prefers A over AAAA. So when I'm on 5G it connects over a NAT64 route, but due to the NAT64 route dropping after x time push notifications break. When you then turn on the phone, some traffic re-establishes the NAT64 tunnel and all of the sudden you get a whole bunch of notifications.

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

#108

Post by gorkish »

londons_explore wrote: post #32

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 discover that Linux does not seem to have the ability to do anything similar. It seems most solutions focus on using socat in userspace to proxy data between the sockets which is not really a practical solution.

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

#109

Post by photonbeam »

kuon wrote: post #96
giancarlostoro wrote: post #91

Earlier quoted context omitted.

I'm of the opinion that IPv6 is old enough that the fact we have not hopped to it yet means its not happening anytime soon. I wanted it back in 2008 when I first learned about it, and I know its older than that (90s iirc) so its either going to come one day "abruptly" by force and break half the internet, or people will do hacks to maintain IPv4 as is. I think the only way IPv6 will ever become mainstream is if eithe…

Yeah, we need more incentive. Ipv6 is harder to implement yes, it is true, there is no point in denying this and arguing it solves tons of problem (it does). Most companies have ipv4 experience and it's just simpler. There must be some political pressure to make it move. But "hopefully" the economical pressure is starting to build up, a lot of providers are cheaper in ipv6 only configuration. Still, for a company lik…

Plenty of big sites have no AAAA record even

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

#110

Post by ninkendo »

WirelessGigabit wrote: post #107
ninkendo wrote: post #81

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…

> The largest problem with this is that that this IPv6 router lives outside of your devices. It lives somewhere at the ISPs infrastructure.

I use my own router which supports NAT64. I use OpenBSD which supports it natively in-kernel, but you can get NAT64 with any competent router software (OpenWRT, pfsense, etc.)

> 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.

Huh? I don't follow what you're saying... websites see an IPv4 address when I connect. I'm using NAT64, after all. It's just the _client OS_ that thinks it doesn't have an IPv4 address. My OS sends traffic as IPv6 to 64:ff9b::/96, but the router turns around and makes an IPv4 request with the IPv4 address I get from my ISP. I have IPv4 at the gateway but nothing else in my network sees it.

> Also, it completely breaks stateless applications.

I don't know what this means but I haven't seen a single broken application?

> When you have an IPv4 IPv4 UDP tunnel you can just send traffic. If one device is behind NAT you set up port forwarding. It'll work today, it'll work tomorrow, and in 2 years.

I can NAT inbound IPv4 requests to my internal IPv6 machines too, I don't know what the issue is for you here. I choose not to, since I don't want to deal with it, but the option is available if I want.

> The tunnel that the NAT64 system sets up is time-bound. So while outgoing traffic re-establishes the route, incoming traffic is not stateless. It stops.

I don't know what you're referring to here... it's exactly the same as how NAT works in IPv4. Outbound requests from my internal network are tracked with NAT, and return traffic is rewritten back to the IPv6 address that sent it. There's no difference between that and IPv4 outbound NAT here. I don't know what you're talking about with "tunnels" or anything.

Post reply on HN