The purists don't like it but that doesn't make it un-viable. Said purists also like to claim that NAT is not a security feature, I disagree with this, having different addresses on your internal and external networks makes it much less likely you will end up with things wide open by accident. It also makes it harder for attackers to gather internal network ...
What you are suggesting is just one more "wrong-think" about IPv6. Stop thinking about things in terms of IPv4. If you have an actual, real, functional firewall, the security concern of having a public address is negligible. Unsolicited inbound traffic is blocked, and everything else is inspected.
IPv6 was designed to never have the insanity IPv4 ...
I've finally reproduced this scenario to check what will happen.
Using eve-ng network emulator (note, it's not a simulator, it runs real software images and shows what happens almost indistinguishably from real devices) I've created the following topology.
cumulus10 there (with AS 65003) hosts vlan1 interface (which is switch virtual interface) and ports ...
When you use a connection involving NAT64, your topology looks like this:
+-----+ +-------+ +-----+
| IP6 |===| NAT64 |---| IP4 |
+-----+ +-------+ +-----+
One peer is using IPv6 addresses, one peer is using IPv4 addresses and the NAT64 gateway translates between these addresses.
Now let's look at a TCP connection.
RFC793 says in 3.1. Header Format ...
Transport mode cryptographically verifies the IP addresses. NAT must manipulate the IP addresses to provide connectivity. That's why they're not compatible.
Tunnel mode works through NAT. Transport mode doesn't.
as of my understanding IPv4-embedded IPv6 containing private IPv4
address is supposed to be dropped either by the receiver or the
intermediate party (NAT64 translator)
That is only true of using the well-known prefix (64:ff9b::/96):
3.1. Restrictions on the Use of the Well-Known Prefix
The Well-Known Prefix MUST NOT be used to represent non-global IPv4
One big problem you seem to have with the serial interfaces is that you are not connecting DTE to DCE. You must set the clock rate on one side of the serial connection to set the interface as DCE, otherwise you are trying to connect DTE to DTE, and that does not work. You need to connect DTE to DCE.
For example, R2:
no ip address
I hope picture above shows it really nice, basically once one Gateway node for example GW1 will fail then server nodes will automatically use other dynamic gateways GW2 and GW3. Also dynamic gateways allows servers to load balance the traffic among them so you can avoid overloading one Gateway.