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

161–170 of 199 posts

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

#161

Post by hot_gril »

Macha wrote: post #159
hot_gril wrote: post #123

Earlier quoted context omitted.

If ipv4 is just simpler and people prefer it like you say, that's a sign that v6 isn't a good option for replacement.

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.

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

#162

Post by hot_gril »

icedchai wrote: post #157
hot_gril wrote: post #153

Earlier quoted context omitted.

They'd have to expand the header in a backwards-incompatible way, yes. IPv6's issues don't all stem from that. Changing all the existing addresses, adding new special kinds of addrs, trying to ditch NAT, and maybe even changing the human-readable format of addrs created most of this resistance. Asking someone to go v6 is asking for a whole network redesign, with an end result that isn't exactly simpler. Swap in v4.1-…

If you expand the header in a backwards-incompatible way, you have to upgrade all the routers and endpoints. You'd need to extend other protocols, like BGP and OSPF, to even route your "v4.1" prefixes. You'd have the exact same dual stack issues as you do with v6. Why bother? IPv6 is available today and has been here for over 20 years. The truth is it is actually simpler to deploy than v4. For example, the address fo…

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 statement. Most home and corporate users have little interest in outside connectivity, or when they do, it's easy to forward ports. And it's important how even the cheapest router or least savvy user won't accidentally expose local devices to inbound connections; see another user's note on unsafe defaults https://news.ycombinator.com/item?id=37765946

If you personally would like to go NAT-free on your network, still all you need is plentiful addresses like v4.1, but it wouldn't be the default that everything is optimized around.

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

#163

Post by Dagger2 »

hot_gril wrote: post #134
hatch_q wrote: post #127

Earlier quoted context omitted.

Name one vendor? I can name you 3 that don't. Zyxel, Ubiquiti, Mikrotik. Also anything wrt based (eg. dd-wrt). In fact one of the warnings on dd-wrt official IPv6 tutorial: """ Keep in mind it can be dangerous to enable IPv6 without also having a firewall on each client that handles IPv6 packets, or having ip6tables on your router to filter incoming connections. ip6tables is NOT included by default with DD-WRT, which…

This is my concern too. NAT is nice because it's stupid and secure by default. No matter how you misconfigure it, the router simply doesn't know where to forward inbound packets to, unlike a firewall which has to actively block. My assumption for routers is that they won't handle firewalls right, especially the many cheapo ones.

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 the search space needed for a hostile actor to find those servers via network scanning. At least, it does on v6 -- on v4 the search space is already too small to be a relevant factor.)

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

#164

Post by WorldMaker »

hot_gril wrote: post #162
icedchai wrote: post #157

Earlier quoted context omitted.

If you expand the header in a backwards-incompatible way, you have to upgrade all the routers and endpoints. You'd need to extend other protocols, like BGP and OSPF, to even route your "v4.1" prefixes. You'd have the exact same dual stack issues as you do with v6. Why bother? IPv6 is available today and has been here for over 20 years. The truth is it is actually simpler to deploy than v4. For example, the address fo…

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 header format without incrementing the version number. There is no way to not create a "second" stack when you increment the version number. Different versions are always different "stacks". They are always going to have different mechanics and need different hardware.

All the other things that IPv6 changed didn't make it a different stack. Making a version 6 at all made a new stack and all the other things were changed to throw in additional improvements (and make things simpler) since there needed to be a different stack anyway. If version 6 had changed "just" the header it still would have been just as hard to upgrade to, but people would have even fewer reasons to upgrade.

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

#165

Post by WorldMaker »

loondri wrote: post #48

I think retrofitting IPv4-only apps for IPv6 compatibility might be a short-term fix. It could be more forward-thinking to focus on developing new apps with inherent IPv6 support to prevent accruing technical debt and facing complications tied to maintaining outdated IPv4-only applications.

iOS app certification requires IPv6 support. Several mobile carriers only support IPv6 (with big carrier NAT64 gateways).

In general, consumer apps and consumer APIs are being developed with IPv6 support.

The new apps to name and shame for not natively supporting IPv6 in 2023 are mostly corporate and Big Enterprise.

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

#166

Post by WorldMaker »

ianburrell wrote: post #135
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…

IPv6 has been silently growing. If Hacker News supported IPv6, there is a good chance you would be accessing it with IPv6. The problem is that may have hit a plateau with the easy migrations. The issue is that there is no incentive for most businesses to make switch. I was thinking that there should be movement that IPv6 is the new default protocol. That includes requesting IPv6 from sites. Also, lots of docs on how…

All of the best practices seem to be in place in the consumer space. Several major consumer ISPs (mobile carriers) are IPv6-only and there hasn't been that much trouble. iOS requires IPv6 support in App Store certification because of this.

The trouble is definitely corporate networks. Changing opinions is hard, especially when network engineers have sunk cost fallacies and bad security training to worry about. Probably the only thing that's going to start making a difference for corporate networks is to let IPv4 costs continue to increase until enough corporate accountants start to notice that in financial reports and start to ask hard questions. Too bad there's no easy way to associate a market cost to 10.0.0.0/8 somehow.

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

#167

Post by KirillPanov »

londons_explore wrote: post #59
KirillPanov wrote: post #44

Earlier quoted context omitted.

The "upstream or nothing" attitude is an attempt to erase any difference between free software and "visible source". Offering changes back to upstream is always encouraged, but whether or not it is accepted is largely irrelevant to the patch author.

I just don't think it's a good use of OP's time - effectively developing and maintaining software for 1 user. One main benefit of software/computers/the internet is that work done by one person can benefit millions - thats what sets us apart from cavemen who had to do everything for themselves, and got a worse quality of life as a result.

> software for 1 user.

This bogus assumption is the whole problem with the "upstream or nothing" attitude.

You're letting a single project -- and usually a single individual -- be the gatekeeper between you and the entire remainder of humanity. That is stupid.

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

#168

Post by patmorgan23 »

ninkendo wrote: post #110
WirelessGigabit wrote: post #107

Earlier quoted context omitted.

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

The IPv4 traffic gets 'tunneled' between the v4 app and the v4 router over v6.

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

#169

Post by ninkendo »

patmorgan23 wrote: post #168
ninkendo wrote: post #110

Earlier quoted context omitted.

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

The IPv4 traffic gets 'tunneled' between the v4 app and the v4 router over v6.

NAT64 is just stateful NAT, exactly the same as IPv4 stateful NAT. It happens to be translating between v4 and v6 as part of the translation, but it’s no different whatsoever from pure-IPv4 NAT in this regard. You can call it “tunneling” if that helps you conceptualize it, sure, but you shouldn’t extend the tunneling analogy to make it seem like it’s conceptually different from IPv4 NAT, because it isn’t.

This phrase:

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

Makes it seem like NAT64 is doing something conceptually different from what we’ve had for decades with every IPv4 network. It’s not.

And when OP says:

> 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

Everything they just said applies to NAT64 too. You can “set up port forwarding” of your public IPv4 address to forward to an internal IPv6 address too. It’s just NAT!

Edit: I think what’s happening in this discussion, is that WirelessGigabit responded to my comment about my home setup, with drawbacks about their T-Mobile setup, which was a bit of a change of subject. It took a few re-readings of their comment for this to become clear. In my toplevel post I’m referring to a scenario where my ISP gives me an IPv4 address, but I don’t have IPv4 enabled in my LAN. (No IPv4 DHCP addresses are being handed out, my router does not have a v4 address on its LAN link.) WirelessGigabit is referring to a setup like in T-Mobile, where they’re putting the NAT64 box somewhere in T-Mobile’s infrastructure, and thus WirelessGigabit has no control over doing things like setting up port forwarding rules, etc. Basically they’re complaining about things I never mentioned about my setup. And as others have pointed out, T-Mobile’s XLAT setup is basically CGNAT by another name, but one where if your use case is pure IPv6, there’s a path to avoiding the NAT issues. This is very different from my case.

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

#170

Post by hot_gril »

Dagger2 wrote: post #163
hot_gril wrote: post #134

Earlier quoted context omitted.

This is my concern too. NAT is nice because it's stupid and secure by default. No matter how you misconfigure it, the router simply doesn't know where to forward inbound packets to, unlike a firewall which has to actively block. My assumption for routers is that they won't handle firewalls right, especially the many cheapo ones.

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.

Post reply on HN