3 ms·

I don't really get the point driving attempts to disable IPv4 entirely. Companies like Github and Steam are too shit to add a few AAAA records, so you need to l

I don't really get the point driving attempts to disable IPv4 entirely. Companies like Github and Steam are too shit to add a few AAAA records, so you need to layer hacks upon hacks to make things work. At that point, just use dual stack, even if it's just CG-NAT. Yeah, it's pretty shit and you get CAPTCHAs out the ass whenever you hit an IPv4 website but at least shit hardware like the Switch will just work. Same with the IoT garbage that couldn't be bothered to spend the quarter of a cent on a megabyte of extra flash so they removed IPv6 supporter. Let the shit hardware and software suffer from having to deal with NAT and save yourself the trouble. Network administrators around the world decided that they didn't like IPv6, don't bother to learn anything new, and pretend there is no IPv6, so take the easy way and placate them with the shitty NAT over NAT they'd much rather prefer. I must admit I'm disappointed about the Deck, but I can't be too surprised given that the entire Valve server stack seems to be IPv4 only.

Sesse__ 2y ago
> At that point, just use dual stack, even if it's just CG-NAT. The motivating factor is the ability to turn off IPv4 within your own core network. For a large-ish ISP, running v6-only to all of your customers and having IPv4 to only a couple of points (your NAT64 gateway) can be attractive, assuming you generally know what you're doing and your CPE can do 464XLAT. This becomes _even_ more attractive when your network is too big for it to reasonably fit within 10.0.0.0/8 (very cell phone companies are in this boat). For an end user in a home network, there is no practical benefit.
- jeroenhd 2y ago
  Using IPv6 on the backend is already something ISPs do in many CG-NAT scenarios. This is exactly what DS-Lite does, though that does require a CG-NAT termination solution (then again, if you're an ISP you probably have a box that supports doing that lying around somewhere anyway). For new networks larger than 10/8 going IPv6 native makes sense I suppose, but for existing networks I'd expect migrations to move towards DS-Lite and similar techniques rather than 464XLAT; it's a less messy solution, and from what I can tell it's also more often present in CPEs.
  - Sesse__ 2y ago
    The big difference is whether the CLAT part is in the CPE or in the endpoints, right?
BlueTemplar 2y ago
It's 2024, you should be blocking GitHub (and, arguably, Steam) anyway. And if the hardware ( / firmware) is so shit that it still doesn't support it, you shouldn't be using it, since it's basically e-waste at this point (and causing more e-waste by the network effect). The issue with trying to run dual-stack is that now you have to learn two kinds of networking, and all the extra complexity (which is actually more than 2x, complexity doesn't scale linearly), which matters since mistakes here can easily become security mistakes.
- yjftsjthsd-h 2y ago
  > And if the hardware ( / firmware) is so shit that it still doesn't support it, you shouldn't be using it, since it's basically e-waste at this point (and causing more e-waste by the network effect). Well, no. If you have an IPv4 connection then the devices work, therefore they're not e-waste. If you make up a requirement to not use a still-functional technology and thus your gear breaks, that's a you problem.
  - BlueTemplar 2y ago
    At some point you won't have an IPv4 connection, which I hear is already the case for some Asian ISPs.
    - yjftsjthsd-h 2y ago
      Perhaps. If that happens, then such devices might become e-waste (assuming that it happens before they're updated, because this can all be fixed in software). But at least where I am I seriously doubt that'll happen anytime soon, to the point that such devices are somewhat likely to have died of natural causes before then anyways.
yjftsjthsd-h 2y ago
> Companies like Github and Steam are too shit to add a few AAAA records Yeah, it's... it's not that. Github has talked about it being difficult because their whole stack expects v4 and IIRC is doing some sort of IP reputation/rate-limiting system. I don't know specifically about Steam but I'd be shocked if they aren't even more invested in reputation systems that are built around v4 addresses. Now to be clear, I agree that both of them should do the engineering work to support IPv6 (dual-stack and single), but claiming it's just a matter of adding AAAA records is wrong.

Sesse__ 2y ago

> At that point, just use dual stack, even if it's just CG-NAT. The motivating factor is the ability to turn off IPv4 within your own core network. For a large-ish ISP, running v6-only to all of your customers and having IPv4 to only a couple of points (your NAT64 gateway) can be attractive, assuming you generally know what you're doing and your CPE can do 464XLAT. This becomes _even_ more attractive when your network is too big for it to reasonably fit within 10.0.0.0/8 (very cell phone companies are in this boat). For an end user in a home network, there is no practical benefit.

jeroenhd 2y ago
Using IPv6 on the backend is already something ISPs do in many CG-NAT scenarios. This is exactly what DS-Lite does, though that does require a CG-NAT termination solution (then again, if you're an ISP you probably have a box that supports doing that lying around somewhere anyway). For new networks larger than 10/8 going IPv6 native makes sense I suppose, but for existing networks I'd expect migrations to move towards DS-Lite and similar techniques rather than 464XLAT; it's a less messy solution, and from what I can tell it's also more often present in CPEs.
- Sesse__ 2y ago
  The big difference is whether the CLAT part is in the CPE or in the endpoints, right?

BlueTemplar 2y ago

It's 2024, you should be blocking GitHub (and, arguably, Steam) anyway. And if the hardware ( / firmware) is so shit that it still doesn't support it, you shouldn't be using it, since it's basically e-waste at this point (and causing more e-waste by the network effect). The issue with trying to run dual-stack is that now you have to learn two kinds of networking, and all the extra complexity (which is actually more than 2x, complexity doesn't scale linearly), which matters since mistakes here can easily become security mistakes.

yjftsjthsd-h 2y ago
> And if the hardware ( / firmware) is so shit that it still doesn't support it, you shouldn't be using it, since it's basically e-waste at this point (and causing more e-waste by the network effect). Well, no. If you have an IPv4 connection then the devices work, therefore they're not e-waste. If you make up a requirement to not use a still-functional technology and thus your gear breaks, that's a you problem.
- BlueTemplar 2y ago
  At some point you won't have an IPv4 connection, which I hear is already the case for some Asian ISPs.
  - yjftsjthsd-h 2y ago
    Perhaps. If that happens, then such devices might become e-waste (assuming that it happens before they're updated, because this can all be fixed in software). But at least where I am I seriously doubt that'll happen anytime soon, to the point that such devices are somewhat likely to have died of natural causes before then anyways.

yjftsjthsd-h 2y ago

> Companies like Github and Steam are too shit to add a few AAAA records Yeah, it's... it's not that. Github has talked about it being difficult because their whole stack expects v4 and IIRC is doing some sort of IP reputation/rate-limiting system. I don't know specifically about Steam but I'd be shocked if they aren't even more invested in reputation systems that are built around v4 addresses. Now to be clear, I agree that both of them should do the engineering work to support IPv6 (dual-stack and single), but claiming it's just a matter of adding AAAA records is wrong.