I'm aware of how routers work and this is obviously simplified. But basically you would just have a high part of the address that would be outside the mask, and old routers would just ignore it.
So your IPv6 would be 1.2.3.4.5.6.7.8, and old routers would just see 5.6.7.8 and route to the place where that IP should go. The router at 5.6.7.8 would be responsible for understanding IPv6 and how to route from there with the full address.
That wouldn't work either. Why would the 5.6.7.8 router necessarily know how to route to the longer-address destination? There's no guarantee it's been upgraded. And why should it have to, anyway? It could get DoSed (accidentally, even) by traffic intended for a completely different destination outside its control.
Also consider that even if that 5.6.7.8 router knew how to route to the 1.2.3.4.5.6.7.8 network, it would have no guarantee that the packets wouldn't hit another router along the way that didn't understand the extra address bits. You could end up with weird routing loops and other issues. (Fortunately TTLs would quash these, but not after wasting a bunch of extra resources.)
Now, there might be some clever ways to work around this, and it might require some more internet infrastructure to deal with these routing challenges. Maybe that would have been faster and cheaper to deal with than the current IPv6 mess we have, maybe not.
The device with IP 5.6.7.8 would have to be capable of routing the new packets, but nothing in between would. Just like today the device at 5.6.7.1 has to know how to route 5.6.7.8/24. It’s just assumed that the special IP knows what to do.
> So your IPv6 would be 1.2.3.4.5.6.7.8, and old routers would just see 5.6.7.8 and route to the place where that IP should go.
Thats absolutely not what would happen to an IPv4 only router though. You're fundamentally misunderstanding what IPv4 actually is.
That IPv4 router getting a packet with a source address of 9.10.11.12.13.14.15.16 addressed to 1.2.3.4.5.6.7.8 wouldn't know to route it to 5.6.7.8. That packet would be parsed as a source of 9.10.11.12 and a destination of 13.14.15.16. The real destination would have been spilled over into the Options header or payload of the packet. This is because in IPv4, bits 128-159 are the source address, 160-191 are the destination. Having a 64-bit address mushed into an IPv4 packet would just lead to those bits spilling over to the next location.
An IPv4-only router would not be able to route your theoretical IPv6 packet.
I assume the high bits would be in the variable length ip option field. So to an old stack it would look like a packet from 13.14.15.16 to 5.6.7.8. Both of those devices would have to be capable of routing ipv6 packets, but nothing in between would.
Hmm, might work for the middle boxes that just do routing.
This would then only really work with both ends supporting this new IPv6 though. If one side only spoke OG IPv4 and the other side spoke this weird IPv6 with half its address bits in the header, there's a good chance the IPv4 side would just ignore the header bits on its return packets and thus wouldn't address it right. So, while that router in the middle might route these packets OK, you'd still practically need an IPv4 address to talk to other IPv4 devices. Which means we'd still have this mixed support, or that 5.6.7.8 would need to pretty much be a complete stateful NAT keeping track of connections for 6 to 4.
> or that 5.6.7.8 would need to pretty much be a complete stateful NAT keeping track of connections for 6 to 4.
Yeah, that would be the transition period. Where any v6 router would also be a NAT gateway for any OG connections and would have to have both a v4 and v6 address.
So your IPv6 would be 1.2.3.4.5.6.7.8, and old routers would just see 5.6.7.8 and route to the place where that IP should go. The router at 5.6.7.8 would be responsible for understanding IPv6 and how to route from there with the full address.