This is the problem. Lots of arm-chair protocol engineers claim it'd be easy if 'They did X'. Of course, these immediately fall apart under the barest of scrutiny but they keep coming up.
Here is your challenge. Create a way to add this address space extension in a way that doesn't break backwards compatibility. Remember, you need to be specific how you would add the change and how it would keep backwards compatibility.
i didn't say it wouldn't break backward compatibility - you're moving the goal posts. what i said was "a superset of IP with a different packet format and wider fields"
> arm-chair protocol engineers
don't be condescending. i've likely been designing protocols for longer than you think.
> Remember, you need to be specific how you would add the change and how it would keep backwards compatibility.
if all you had to do to deal with IPv6 was bigger addresses and a slightly different wire format, it wouldn't have had the barrier to adoption. don't design an entirely different protocol. the wire format is the least of the problems.
This again. The biggest barrier to IPv6 adoption has always been a different wire format, it doesn't matter the degree of difference.
How you assign addresses is completely different. How you configure your firewall as a result is completely different. In fact software support for the latter was one of the things I struggled with for years before having to change router software from pfSense to OpenWRT. Last I checked pfSense still didn't have full support.
They changed the way you write the addresses, using the port separator as group separator as well, leading to needing special software support for parsing IPv6 addresses. I know because I had to fix this in a few projects where we bothered to add IPv6 support, and that was the biggest PITA by far when adding IPv6 support, the rest was trivial.
Out of all the trouble I've had with IPv6, the wire format was the least problematic by far. All the wire format did was cause it to take some time to get IPv6 capable hardware.
But I've had that hardware for decades at this point. The thing keeping IPv6 back is all the other things they changed.
Spoiler: you will come to the conclusion that you can’t find the additional bits. Your only option is to break compatibility and create a new packet header format. At this point you can choose literally any size address larger than 32 bits. 64 is good, but the cost to go to 128 is literally nothing while giving you a lot more possibilities of what you can do with it.
Lastly, IPv6 fixes a lot of craft from IPv4. It is a more streamlined protocol that is actually easier to work with than IPv4. The people who told you that IPv6 is overengineered didn’t have an alternative better protocol. Their point was that IPv4 is fine and we don’t need anything but what it provides because a new protocol is scary and annoying to learn because new things are scary. Literally, mathematically, there is no alternative that solves address exhaustion in a backwards compatible way. CGNAT is the overengineered hack, not IPv6.
I really hope you stop respond in to people with nonsense before you look at the packet structure yourself.
well, yes obviously you need more bits. what you don't need is all the other changes.
> I really hope you stop respond in to people with nonsense before you look at the packet structure yourself.
don't be condescending.
