Of course, all such encapsulated "IPv6" traffic is routed according to the public IPv4 rules up to the network that emitted the rules, which will further examine the full address and take appropriate private routing decisions. To talk to your "IPv6" node, I don't need to know the full route, just be able to route to a system close enough to you that understands "IPv6" - the border of your network.
I stress again that when you connect me from behind NAT, I see your public IPv4 but have no idea how to reach you back, nor can you publish such info. When you contact me over an 6:4 encapsulation, I get your globally unique IPv6 which I can use to connect back to you at a later date - connection works end to end as if we were inside an IPv6 Internet, so it's not fair to call it "NAT".
It's more aptly a NAT64-tunneling hybrid, that's transparent, backwards compatible and can be switched to full v6 operation when critical mass is achieved, by symply publishing 128 bit routes. In hindsight, I am convinced the dual stack solution is much, much harder to deploy and was the wrong solution.
6to4 works like that. It's largely not been successful, because routing is asymmetric and failures are silent, to the extent that IETF considered deprecating it this year. 6rd exists (a replacement for 6to4 that makes the routing more symmetrical and accountable) and a few people may still be trying to use it, but most have reached the conclusion that dual-stack is easier.
>most have reached the conclusion that dual-stack is easier.
I know about the so called transition technologies and their dubious record, however the original context was "an alternative protocol backwards compatible with IPv4", not making IPv6 work on the IPv4 Internet. The former is possible (x) and was preferable circa 1996, while the latter are afterthoughts bound to fail: you obviously can't route true IPv6 on IPv4 hardware without upgrading it, and at that point, why not go dual-stack ?
Unlike a backwards compatible packet format, transition technologies require gateways to the "new" IPv6 Internet, that are checkpoints by definition and need configuration, resources and attack surface, amplifying the chicken and egg problem - why deploy gateways to the IPv6 when there's nothing there ? Add flakiness of the transition technology itself, for example Teredo clients can't even reach one other 25% of the time due to symmetric NATs.
(x) brain fart time:
If I were to redesign IPv6 today in a backwards compatible manner, I would treat the existing NAT hierarchy as a set of different routing realms, and upgrade only these points to do a stateless forwarding of the extended packets, while keeping their existing behavior for regular IPv4 traffic.
For example, to reach host 10.10.10.10 siting behind NAT 2.2.2.2, an IPv4 packet is prepared with an extension field :
IP Header: DEST: 2.2.2.2
Extended Header: DEST: 10.10.10.10, REALM=0
(src omitted etc.)
The IPv4 infrastructure will forward the packet blindly while the upgraded NAT/router will recognize the extended format and instead of dropping it will mangle it and forward it along:
IP Header: DEST: 10.10.10.10
Extended Header: DEST: 2.2.2.2, REALM=1
The destination stack will establish a connection if it recognizes the packet format, or drop it if it's a legacy IPv4 implementation.
You can repeat this for a bunch of chained NATs, incrementing the realm and swapping more routing bits from the Extended header into to the IP header, while reversing the mangling when extended packets exit from the inner routing realms. In an 128 bits address you could do this 4 times, sufficient even when dealing with something like "NAT44444".
So you can keep end to end stateless routability as long as all NATs are cooperant, and fall back to regular IPv4 over NAT when they are not. In time, NATs will transform to routers, simply mangling and forwarding extended packets and do less and less state tracking for legacy packets, until eventually tracking can be turned off.
The idea is to upgrade only key edge infrastructure (NATs), to do a very simple and stateless transformation, and not the whole Internet with a risky and complex technology. NAT clients are incentivised to upgrade (for p2p, voip etc.) without finding themselves in an Internet ghetto with high latency and routing blackholes. It's the same Internet with the same routes. In time, ISPs can release some of the massive SOHO IP space that's no longer justified.
Maybe not an entirely thought out idea, but it's a starting point. Or would have been. Despite it's troubled childhood IPv6 is of course superior, allows easy renumbering and real multicast, etc.
I stress again that when you connect me from behind NAT, I see your public IPv4 but have no idea how to reach you back, nor can you publish such info. When you contact me over an 6:4 encapsulation, I get your globally unique IPv6 which I can use to connect back to you at a later date - connection works end to end as if we were inside an IPv6 Internet, so it's not fair to call it "NAT".
It's more aptly a NAT64-tunneling hybrid, that's transparent, backwards compatible and can be switched to full v6 operation when critical mass is achieved, by symply publishing 128 bit routes. In hindsight, I am convinced the dual stack solution is much, much harder to deploy and was the wrong solution.