Comment by redox99
5 days 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.
That’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.
for me, I don't need to even setup NAT64. My ISP provides it for me free.
What do you do about IoT devices?
Why 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.
Another 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?
It 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.
Devil'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.
1 reply →
Having just optional field in the ipv4 header with extra address bits would leave all the stack source code with just some 100 lines of extra code. Would mean, you can have one stack that handles just both. Make special addresses where the additional bits are all 0, which means the field is not there at all. These addresses could reach ipv4 only addresses and could be reached from them. When you really want to make sure these devices aren't parsing ipv4+ packets, change the checksum-code for all packages that contain the optional field. That would mean all ipv4 only devices would ignore ipv4+ packages. Instead you could change the version to 5 for all with optional address bits.
This is stuff that could be implemented in any ipv4 stack in some days of work.
IPv6 is overengineered, thats the reason why it's not adopted after 30 years.
You clearly do not understand networking. Or else you won't make such a statement:
>This is stuff that could be implemented in any ipv4 stack in some days of work.
The sysadmins across the world, who had to deal with decades-old, never-updated devices facepalmed in unison.
At least the other comment agreed that "IPv4+" hosts will never be able to talk to IPv4 hosts.
>IPv6 is overengineered, thats the reason why it's not adopted after 30 years.
It is already adopted in many countries. Don't blame the protocol for your countrymen's incompetence.
And 2 listeners