4 ms·
It was doomed the moment you had to maintain two separate stacks, each with its own address, firewall rules and so on. It should have been ipv4 with extra opti
by redox99 10mo ago
It was doomed the moment you had to maintain two separate stacks, each with its own address, firewall rules and so on.
It should have been ipv4 with extra optional bits, so you could have the same rules and everything for both stacks.
I turn it off because it's a risk having one of either stacks malconfigured.
IPv6 should've been a superset of IPv4, as in addresses are shared, not that you have a separate IPv4 and IPv6 address for your server.
- kccqzy 10mo agoThat’s why my home network is IPv6 only. NAT64 and DNS64 and 464XLAT work very well, and you only need to configure IPv4 once: in your router, where you need special configuration anyways.
- apearson 10mo agoWhat do you do about IoT devices?
- torginus 10mo agoWhy would that be a desirable quality? Wifi devices (using Matter or not) live on the same network as my PC - meaning a compromised lightbulb (or one that hasn't been updated) can be used to infiltrate and attack my home computers. Thread+ Matter, despite using a different radio, suffers from the same issue, since a border router is on the Wifi network, a smart bulb using Thread can theoretically access my PC. Yes, I'm sure there are ways to fix this, but why have the problem in the first place? Zigbee is entirely incompatible networking standard, and doesn't have this problem.
- deleted 10mo ago[deleted]
- miyuru 10mo agofor me, I don't need to even setup NAT64. My ISP provides it for me free.
- orangeboats 10mo agoAnother day, another Godwin's law of networking. >It was doomed the moment you had to maintain two separate stacks Pray, tell me, how are we supposed to extend IPv4 with another {insert a number here} bits without creating a new protocol (that neccessitates running two stacks)? Suppose that you have an old computer that understands only 32 bit addresses -- good ol' IPv4. Let's name it 192.168.10.10. It then receives a packet from another computer with hypothetical "IPv4+" support, 172.12.10.98.12.4.24.31... ...Wait a minute, it can't, because your old computer understands only 32 bit addresses! What if we really forced it to receive the packet anyway? It will see that the packet is from 172.12.10.98, because once again, it understands 32 bit addresses only. It then sends back the reply to... you guessed it, 172.12.10.98. Not 172.12.10.98.12.4.24.31. Yeah,172.12.10.98.12.4.24.31 will never get its reply back. Do you see why any "IPv4 with extra octets" proposal are doomed to begin with now?
- redox99 10mo agoIt wouldn't be able to receive it. That simple. Which is not a problem, any server would still have an old ipv4 address (172.12.10.98 from your example), like they currently do and probably will for decades.
- russdill 10mo agoDevil's advocate. There could be a extension for ipv4 stacks. Ipv4 stacks would need to be modified to include the extension in any reply to a packet received with one. It would also be a dns modification to append the extension if is in the record. Ipv6 stacks would either internally reconstruct the packet as if it were ipv6.
- Dagger2 10mo agoIt would be easy to make such an extension, but you're going to hit the same problem v6 did: no v4 stacks use your extension. How will you fix that? By gradually reinventing v6, one constraint at a time. You're trying to extend v4, so you can't avoid hitting all of the same limits v6 did when it tried to do the same thing. In the end you'll produce something that's exactly as hard to deploy as 6to4 is, but v6 already did 6to4 so you achieved nothing.
- tonymet 10mo agoAnd 2 listeners