Re: There Might Be An Alternative
I spent some time ingesting that draft, and I have a silly question... how is it different to running 6to4+NAT64?
To explain, I'm going to describe a network setup using Figure 1 as a basis, but using 6to4 and NAT64 instead of EzIP.
First, convert the WAN IPs of the SPRs into hex (4529be6e/4529be94), and set up 6to4 on each of them. SPR1 gets 2002:4529:be6e:/48 and SPR4 gets 2002:4529:be94::/48. Now set up NAT64 on SPR1 and SPR4, such that the 240/4 addresses behind SPR1 are mapped into 2002:4529:be6e:64::/96 and the 240/4 addresses behind SPR4 are mapped into 2002:4529:be94:64::/96.
It's also necessary to put /64s from the 6to4 allocation on each network. Let's say that T1a/T1z's network gets 2002:4529:be6e:1::/64 and T4a/T4z's network gets 2002:4529:be94:1::/64. T1z now has two IPs (192.168.1.9 and 2002:4529:be6e:1::9) and so does T4z (246.1.6.40 and 2002:4529:be94:1::1640/64). T1a and T4a still only have one address each (192.168.1.3 and 240.0.0.10), since they only support v4 -- but they are also reachable by 2002:4529:be6e:64::192.168.1.3 and 2002:4529:be94:64::240.0.0.10 due to the NAT64 running on SPR1 and SPR4.
The DNS records for T4a are now 126.96.36.199 and 2002:4529:be94:64::240.0.0.10. The DNS records for T4z are now 188.8.131.52 and 2002:4529:be94:1::1640.
Now consider the example in A.1 (a connection from T1a to T4a). How does it work with this 6to4+NAT64 setup? Basically nothing changes here; T1a sends a plain v4 packet from 192.168.1.3 to 184.108.40.206 and SPR4 needs to DNAT or DMZ it somewhere. A.3.1's scenario (T1a->T4z) is also essentially the same as this.
Next, consider A.2 (T1z->T4z). T1z sends a v6 packet from 2002:4529:be6e:1::9 to 2002:4529:be94:1::1640. The packet is routed through RG1 and reaches SPR1. SPR1 extracts the address of SPR4 from the dest IP (2002:4529:be94:1::1640 -> 4529:be94 -> 220.127.116.11), wraps the v6 packet in a 6in4 packet, and transmits it over the internet to 18.104.22.168. SPR4 receives the packet, unwraps the original v6 packet and forwards it to T4z.
Finally, A.3.2 (T1z->T4a). A.3.2 is weird in your draft, because it says that T1z should send a native v4 packet, and that the packet will be treated the same as the A.3.1 case... but that would mean that T1z has no way of addressing the packet to T4a. It has to resort to talking native v4 to SPR4 and then relying on port mapping or DMZ on SPR4. Doesn't this completely invalidate the point of the draft? It would make more sense for T1z to send an EzIP packet addressed to T4a (that is, 192.168.1.9 to 22.214.171.124 with extension headers that specify 126.96.36.199-240.0.0.10), and have SPR4 convert it to a native v4 packet for delivery over Premises 4's network to T4a.
I'm just gonna assume that's what A.3.2 supposed to say. The 6to4+NAT64 equivalent is for T1z to send a packet from 2002:4529:be6e:1::9 to 2002:4529:be94:64::240.0.0.10. The packet reaches SPR1, which sends it inside 6in4 to 188.8.131.52. SPR4 again unwraps the packet, but this time it spots that the destination is in 2002:4529:be94:64::/96, so it converts the packet to a native v4 packet with a dest IP of 240.0.0.10 and sends it to T4a. The reply packets get detected by SPR4's state tracking and converted back.
That's pretty much how things would work with 6to4+NAT64, and it seems to me that it largely has the same properties as your draft does. but with the added benefit of already being supported by existing software and hardware.
There are some other weird parts in the draft; for instance it says that RG1 is EzIP unaware, yet appendix A says that RG1 needs to insert "TCP ports" in the forwarded packet, which is an operation that routers don't currently do. There are other mentions of TCP ports elsewhere too which I kinda glossed over a bit, because TCP happens at a higher layer than IP and so should be irrelevant here. It's not supposed to be TCP-only, right? That would be called out right in the abstract, or better the title, if so. If not, then those "TCP ports" are actually weirdly-named extra option headers... but that's inconsistent with the IHL field which is explicitly 5 in the example packets shown with them.
The primary difference between the 6to4+NAT64 setup above and the setup described in Figure 1 seems to be the network behind RG1, which is described as being v4-only with an EzIP-unaware router in front of it (but, as I say, there's some disagreement about whether it's actually unaware or not). If RG1 is indeed unaware then nobody will be able to address T1a and T1z from outside their network, because they're hidden from SPR1 by NAT. Inbound connections to them aren't possible without relying on port forwarding rules.
In the 6to4+NAT64 setup, RG1 is definitely aware and inbound connections work fine. It's possible to set up a network where it's not aware, and if you do that then inbound connectivity ends up looking the same as it would with an unaware RG1 in the Figure 1 case. The problem is that T1z will lose its ability to directly address T4a and T4z, since it was relying on v6's dest IP field for that and it can't use that when on a v4-only network. You'd need some mechanism for T1z to communicate its desired dest IP to SPR1, and I don't think that's actually something we have yet. (Perhaps Teredo would do the job, if both SPR1 and SPR4 were Teredo relays. If they're not relays then you end up relying on both Teredo and 6to4's native IPv6 interop, which ought to work but doesn't always.)
If this is really the main difference, then wouldn't you be better served by focusing on this specific aspect (of T1z-on-unaware-network) and relying on technology that already exists for everything else? What advantage are you getting from reinventing those things rather than reusing them? At the moment it just seems like you're unnecessarily raising the implementation and deployment hurdles for yourself.
[This was a bit of an epic post for a comments section, but at least nobody can accuse me of not thinking about their suggestions -- when the suggestion is more substantial than the typical "just add an extra 0-255 to the beginning of the address", at any rate...]