I think what is first necessary is to force compliance of upgrading of IPV4 stacks to accept some information in the options section of the IP packet. According to wikipedia, many/most routers ignore or block packets that have anything specified there.
You know what? That sounds like the RFC isn't being followed, but if it's a large enough pattern, then the RFC doesn't matter. It is the standard.
I would say:
1) gather all the engineers from the major switches and networking companies, the Linux network stack, and apple and microsoft, and sure the mobiles. And ask them the easiest way to change the code to support a vast expansion of addresses in the general format of the IPV4 header: options section? Magic IPV4 address that triggers a IPV4r2 packet?
2) as a carrot, maybe you make some way that NATs / VPNs / bridging / whatever works BETTER in the IPV4r2 packet? If the packets had more information in them about the mapping/bridging so external polling was easier and numerous other use cases, then that would spur the vendors to change.
3) accept that NATs, Bridges, etc exist and will continue to. They are now established as a way to think about networking, and there are likely millions of people that think about networking in these ways, even if they are superfluous / unnecessary in the utopia of IPv6 universal adoption. So put them in the protocol. If universal addressing with firewalls eliminates everything, then they will wither on the vine over the course of a couple decades.
So, what's wrong with this? It's obviously naive.
Also, NO SLASHES NO COLONS in the notation. And ... can we increase the number of ports to 32 bits or more?
OK I want to expand on a "magic IPv4" address that is used to flag if a packet is legacy IPV4 routable or requires IPV4 processing.
If there is that magic IPV4 and an unupgraded router encounters that packet, it ROUTES IT TO THAT MAGIC IP.
... that magic IP isn't a ghost IP. It's a service that takes the packet and routes it using IPV4v2, and NAT translates it back to the legacy router on the return path.
So I think the difference here is then is gradual migration of the same IP stacks / infrastructure, and not introducing an entirely new "separate" stack.
My only experience with IPv6 was converting an IPV4 distributed database to IPV6. It wasn't... fun. Looking up separate flags and settings, weird errors (thank the gods for stack overflow), frustration.
Nowhere was it suggested, demonstrated, or detailed such a backwards compatibility / migration strategy.
That's what we have with v6. It's not entirely separate; it tends to be implemented together with v4 in the same stack of code and deployed on the same infrastructure. It's designed to allow you to migrate gradually.
> My only experience with IPv6 was converting an IPV4 distributed database to IPV6
I assume you mean patching the software to handle it... there are basically two socket APIs, the old one which was v4-only and the new one which works with any generic IP family. v6 had to add the second one because the first one was v4-only, but any replacement protocol for v4 would have had to do the same.
You know what? That sounds like the RFC isn't being followed, but if it's a large enough pattern, then the RFC doesn't matter. It is the standard.
I would say:
1) gather all the engineers from the major switches and networking companies, the Linux network stack, and apple and microsoft, and sure the mobiles. And ask them the easiest way to change the code to support a vast expansion of addresses in the general format of the IPV4 header: options section? Magic IPV4 address that triggers a IPV4r2 packet?
2) as a carrot, maybe you make some way that NATs / VPNs / bridging / whatever works BETTER in the IPV4r2 packet? If the packets had more information in them about the mapping/bridging so external polling was easier and numerous other use cases, then that would spur the vendors to change.
3) accept that NATs, Bridges, etc exist and will continue to. They are now established as a way to think about networking, and there are likely millions of people that think about networking in these ways, even if they are superfluous / unnecessary in the utopia of IPv6 universal adoption. So put them in the protocol. If universal addressing with firewalls eliminates everything, then they will wither on the vine over the course of a couple decades.
So, what's wrong with this? It's obviously naive.
Also, NO SLASHES NO COLONS in the notation. And ... can we increase the number of ports to 32 bits or more?