| ▲ | 1970-01-01 7 hours ago |
| Why not IPv6? Pretending that it doesn't exist?? https://en.wikipedia.org/wiki/List_of_IPv6_transition_mechan... |
|
| ▲ | pcarroll 5 minutes ago | parent | next [-] |
| IPv6 is very badly supported at the low end of the market. Cheap webcams, doorbells, etc. And that not counting already old equipment...
If we had a nuclear war, we could start over. But for now, we are stuck. Blame it on Cisco for inventing NAT. |
|
| ▲ | duskwuff 2 hours ago | parent | prev | next [-] |
| I wouldn't be surprised if a lot of the hardware under management (e.g. IP cameras, NVRs, cable modems) lacks support for IPv6, and/or the customer networks that it's resident on don't have working IPv6 transit. |
| |
| ▲ | zokier 2 hours ago | parent | next [-] | | The solution is to run ipv6 on the overlay and have the customer site gateway thing they have to translate it to target ipv4. Conveniently you can do the translation it more or less statefully and very easily because you can just embed the ipv4 addr in ipv6. For example you could grab a /64 prefix, assign 32 bits to customer/gateway id and other 32 bits to target ipv4 addr. | |
| ▲ | reactordev 2 hours ago | parent | prev [-] | | It’s definitely on the software side… The human side. | | |
| ▲ | eqvinox an hour ago | parent [-] | | The squishy side. Coincidentally I think that's an overestimation on the number of devices that don't support IPv6. At this point, vendors have to go out of their way to disable IPv6, and they lose out on some government/enterprise tenders that require IPv6 even if they're not running it (yet). | | |
|
|
|
| ▲ | lxgr 6 hours ago | parent | prev [-] |
| IPv6 solves the addressing problem, not the reachability problem. Good luck opening ports in the stateful IPv6 firewalls in the scenarios outlined in TFA: > And that assumes a single NAT. Many sites have a security firewall behind the ISP modem, or a cellular modem in front of it. Double or triple NAT means configuring port forwarding on two or three devices in series, any of which can be reset or replaced independently. |
| |
| ▲ | zamadatix 2 hours ago | parent | next [-] | | The article's proposed solution for IPv4 is a combination of VPN+NAT. The solution in IPv6 can be just VPN, sans NAT. | |
| ▲ | bigstrat2003 5 hours ago | parent | prev | next [-] | | I'm not really seeing a reason why it would be impossible to open firewalls in that scenario. More work, sure, but by no means impossible. In any case TFA says right up front that it is trying to solve the problem of overlapping subnets, which IPv6 solves nicely. | | |
| ▲ | throwway120385 2 hours ago | parent | next [-] | | Then you've probably never worked in any serious networked embedded systems space. Getting people to open ports on the firewall and making the firewall configuration palatable to the end customer is like a quarter of what I think about when my team makes new features. | | | |
| ▲ | lxgr 4 hours ago | parent | prev | next [-] | | It's completely impossible if you simply don't have the necessary access. Not everybody can administer all firewalls upstream from them. Nor can everyone control whether their connection supports v6, unfortunately. | | |
| ▲ | digiown 2 hours ago | parent [-] | | Hole punching is a thing. Ports are not normally completely blocked. They allow replies, which can be exploited to do make a connection. Obviously this requires an out of band signaling mechanism. Tailscale does this, so does WebRTC, iirc. See: https://tailscale.com/blog/how-nat-traversal-works | | |
| ▲ | lxgr 2 hours ago | parent [-] | | Yes, but I don't believe all firewalls support that, especially for TCP, and as you've mentioned, now you also need to maintain a handshaking mechanism. The complexity makes sense if you need to transport a lot of data peer-to-peer or the lowest possible latency, but if you don't, you might as well use that coordination server (which outbound-only clients are connecting to) for payload communication as well. |
|
| |
| ▲ | mschuster91 2 hours ago | parent | prev [-] | | > I'm not really seeing a reason why it would be impossible to open firewalls in that scenario. Cheap ass ISP-managed routers. Got to be lucky for these rubbish bins to even somewhat reliably provide IPv6 connectivity to clients at all, or you run into bullshit like new /64's being assigned every 24 hours, or they may provide IPv6 but not provide any firewall control... | | |
| ▲ | themafia 2 hours ago | parent [-] | | > or you run into bullshit like new /64's being assigned every 24 hours It'd be nice if DNS servers supported this. Save the 64 host bits in the zone and just use whatever 64 prefix bits happen to be issued right now. Otherwise it makes a strong case for the continued use of "private networks" and the IPv6 ULA mechanism. | | |
| ▲ | lxgr 2 hours ago | parent [-] | | > Otherwise it makes a strong case for the continued use of "private networks" and the IPv6 ULA mechanism. Let's please not. Even without inbound reachability, hole punching is significantly easier given globally routeable addresses. | | |
| ▲ | themafia 2 hours ago | parent [-] | | You can have /both/ a ULA and a Globally Routable address. In practice it works just fine. My internal DNS points to the ULA for internal connectivity and my hosts use their global addresses for external connectivity. | | |
| ▲ | lxgr an hour ago | parent [-] | | Ah, you mean for cases where you want both stable addresses (even if only internal) and globally reachable ones (even if non-constant)? Yeah, that works, but everything gets much easier if your internal DNS can just support the varying prefix natively, e.g. via integration with the external-facing DHCP or PPPoE or whatever other address configuration protocol you use, since then you can reach everything both locally and globally by name. | | |
| ▲ | themafia an hour ago | parent [-] | | > but everything gets much easier It also gets more fragile. If your ISP can't or doesn't issue you a prefix for whatever reason then your entire IPv6 network stops working even internally. This is even more pertinent if, like me, you're on a 4G LTE connection. Verizon has great IPv6 support, when you can get it, and when you can't I'd still prefer to have a stable internal network. |
|
|
|
|
|
| |
| ▲ | 1970-01-01 6 hours ago | parent | prev [-] | | With IPv6 you don’t forward ports at all. The device already has a public address. | | |
| ▲ | lxgr 4 hours ago | parent | next [-] | | That's why I said "open ports", not "forward ports". Stateful firewalls are very much a thing on v6. Many mobile ISPs don't allow incoming connections by default, for example. Many CPEs (home routers) also come with a v6 firewall (I'd guess it's probably more common than not?), and not everybody has admin access to theirs. | |
| ▲ | jlokier 5 hours ago | parent | prev [-] | | That's the addressing problem, although I have some bad news on that: NAT is used with IPv6 in some places. The reachability problem is, even with public addresses, sometimes you have to do the same thing to "configure port forwarding" with stateful IPv6 firewalls as with double or triple NAT IPv4. |
|
|
