464XLAT/MAT-T Optimization

5.2.1. Optimization enabling

This optimization MUST be enabled by default, but only when the WAN link is IPv6-only and the NAT46/CLAT is being used. Note that the NAT64/CLAT can only be used if the NAT64 prefix has been discovered. This allows the users to get CEs from the retail and take advantage of the optimization, without requiring any configuration.¶

The CE MUST support a way to completely disable the optimization, in order to allow the operator to turn it off in case it is required.¶

It is expected as well, that the NAT64/CLAT is only enabled if the WAN link is IPv6-only.¶

5.2.6. Forwarding path via stateful NAT for existing EAMT entries

Following this approach, if there is a valid EAMT entry, for a given pair of source-MAC-address/IPv4-destination, the IPv6-native path pointed by the IPv6 address of that EAMT entry, will take precedence versus the NAT64 path, so the traffic will not be forwarded to the NAT64.¶

However, this is not sufficient to ensure that individual applications are able to keep existing connections. In many cases, audio and video streaming may use a single TCP connection lasting from minutes to hours. Instead, the CDN TTLs may be configured in the range from 10 to 300 seconds in order to allow new resolutions to switch quickly and to handle large recursive resolvers (with hundreds of thousands of clients behind them).¶

Consequently, the EAMT entries MUST NOT be used directly to establish a forwarding path, but instead, MUST be used to create a stateful NAT entry for the 4-tuple for the duration of the session/connection. This means that to implement the optimization the NAT46 MUST be stateful. Typically, stateful NAT46 are implemented by means of a stateful NAT44 (which often maybe hardware off-loaded), followed by a stateless NAT46. If the SoC/code is able to do stateless NAT46, this still could be used when the optimization is disabled.¶

5.2.7. Maintenance of the EAMT entries

An EATM entry with the Auto/Static bit set, MUST NOT be automatically modified.¶

An EAMT entry with the Auto/Static bit clear, MUST be set to Stale in case of:¶

1. TTL time-out.¶
2. Or the conditions for creation of the EAMT entry (Section 5.2.5) aren't longer met.¶

Entries in Stale state MUST be set to Invalid once existing connections time-out.¶

The Invalid EAMT entries MUST be deleted, unless the Auto/Static bit is set. This allows users/operators to set explicit rules for diagnostics or resolution of issues in special situations.¶

5.2.8. Usage example

Using the same example as in the previous approach:¶

www.example.com                   A       192.0.2.1
                                  AAAA    2001:db8::a:b:c:d
EAMT entry                     192.0.2.1  2001:db8::a:b:c:d
NAT46/CLAT translated to                  2001:db8::a:b:c:d
CDN IPv6 interface already is             2001:db8::a:b:c:d
Operator already has a specific route to  2001:db8::a:b:c:d

The following is an example of the CE behavior after the previous case has already created an EAMT entry and a reverse-proxy is detected:¶

1. A query for www.example.net A RR is received¶
2. www.example.net A 192.0.2.1¶
3. www.example.net AAAA 2001:db8::e:e:f:f¶
4. A conflict has been detected¶
5. The existing EAMT entry for 192.0.2.1 is set to Stale¶

5.2.9. Behavior in case of multiple A/AAAA RRs

If multiple A/AAAA RRs are available, any of them could be chosen and the optimization will not present any different result to the hosts compared with a situation where the optimization is not used.¶

Existing DNS proxy/stub resolvers already implement mechanisms for DNS Load Balancing ([RFC1794]). This don't need to be modified to implement the optimization if some degree of randomness is already secured.¶

To secure sufficient randomness, a possible algorithm shall ensure that different EAMT entries (for different hosts) are permuted randomly among different A/AAAA records on the A/AAAA RR set.¶

5.2.10. Behavior in presence/absence of DNS64

464XLAT can be deployed/used with and without a DNS64. However, as indicated in Section 5.2.3, the EAMT entry is only created when the service is IPv6-enabled, because the optimization is only relevant for destinations which already have AAAA records. In those cases DNS64 is not relevant.¶

5.2.11. Behavior when using literal addresses or non IPv6-compliant APIs

Because the EAMT entries are only created when the NAT46/CLAT/CE proxy/stub DNS is being used, any hosts or applications that don't use DNS, will not create the relevant entries.¶

They will not be optimized unless EAMT entries are statically configured.¶

5.2.12. Behavior in case of Foreign DNS

Hosts or applications may use DNS servers from other networks. For a complete description of reasons for that, refer to Section 4.4 of [RFC8683]. In the case the DNS is modified, or some hosts or applications use other DNS servers, the possible scenarios and the implications are:¶

1. Devices configured to use a DNS proxy/resolver which is not the CE/NAT46/CLAT (as it is the case for some consumer electronics). In this case this optimization will not work, because the EAMT entry will not be created based on their own flows. Nevertheless, the EAMT entry may be manually created. However, the lack of EAMT entry, will not impact negatively in the user's hosts/applications (the optimization is not performed). It should be noticed that users commonly, don't change the configuration of devices such as SmartTVs or STBs (if they do, some other functionalities, such as CDN/caches optimizations may not work as well), so this only happens typically if the vendor is doing it on-purpose and for good well-known reasons.¶
2. DNS privacy/encryption. Hosts or applications that use mechanisms for DNS privacy/encryption, such as DoT ([RFC7858], [RFC8094]), DoH ([RFC8484]) or DoQ ([RFC9250]), will not make use of the stub/proxy resolver, so the same considerations as for the previous case applies.¶
3. Users that modify the DNS in their Operating Systems. This is quite frequent, however commonly Operating Systems are dual-stack, so aren't part of the problem statement described by this document and will not be adversely affected.¶
4. Users that modify the DNS in the CE. This is less common. In this case, this optimization is not adversely affected, because it doesn't depend on the operator DNS, it works only based on the internal CE interaction between the NAT46/CLAT and the stub/proxy resolver. Note that it may be affected if the operator offers different "DNS views" or "split DNS", however this is not related to this optimization and will anyway impact in the other possible operator optimizations (i.e. CDN/cache features).¶
5. Combinations of the above ones. No further impact is observed, beyond the ones already described.¶

5.2.13. False detection of a dual-stack host as IPv4-only

If a dual-stack host is being detected as IPv4-only, is because it is not responding to the CE ND messages, so by all means, should be considered, at the time being, as IPv4-only, and consequently EAMT entries will be created and traffic will be optimized for IPv4 flows.¶

However, if this hosts suddenly become IPv6-enabled (or dual-stack), the relevant EAMT entries must be flagged by the CE as "Stale". The host will be able to complete the connections and the entries will be marked as "Invalid" and deleted.¶

Anyway, those EAMT entries, while "Valid", may not be actually used by the dual-stack hosts, because those hosts or applications should prefer IPv6, so most probably was either a temporary failure or done on-purpose (user, troubleshooting). If the host is preferring IPv4 for connecting to the CDN/cache or IPv6-enabled service, it will be actually using the NAT46/CLAT, including the EAMT entry and consequently IPv6, so this mechanism will be correcting an undesirable behavior. This may be also a special case, which actually seems to be an incoherent host or application implementation.¶

5.2.14. Behavior in presence of Happy Eyeballs

Happy Eyeballs [RFC8305] is only enabled in dual-stack hosts. Consequently, it is not affected by this optimization because both, as the host should not be detected as IPv4-only, following Section 5.2.2.¶

If Happy Eyeballs triggers a fallback to IPv4 for a given host, it will be actually using IPv4 without the optimization, which in turn, uses the IPv6-only WAN link of the NAT46/CLAT/CE. So even if Happy Eyeballs is present, IPv4 is expected to be slower than native IPv6 itself due to delays added by the NAT46/CLAT+NAT64 translations. This optimization reduces those delays by eliminating the second translation (NAT64) for IPv4-only detected hosts.¶

However, there may be cases where this may be understood as problematic. The possible reasons why Happy Eyeballs may trigger an IPv4 fallback, in the case of IPv6-only access networks with IPv4aaS, in general, can be classified as:¶

1. Failure at the CE or customer LANs. It may happen that the CE or other devices in the customer LANs are showing erratic behaviors or malfunctions. It is difficult to believe that this happens only with IPv6, and if that's the case Happy Eyeballs will not resolve the issue, because IPv4 is provided as a service on top of IPv6.¶
2. Complete failure of the IPv6-only link or IPv6-only operator's infrastructure (up to the NAT64). In this case, IPv4 will not work for that subscriber. Happy Eyeballs will not resolve the issue, and instead will only be adding some extra delay (the attempt to fallback to IPv4 before timing-out).¶
3. Complete failure of both IPv4 and IPv6 links behind the operator's NAT64 towards the destination. In this case, typically both, IPv4 and IPv6 will fail (in many cases, they are dual-stack links, not different links). Again, Happy Eyeballs will also fail to resolve the issue.¶
4. Complete failure only in the IPv6 links behind the operator's NAT64 towards the destination. This is less frequent, bus still miss-configured AAAA RRs, or diverse paths for IPv4 and IPv6 together with outages or IPv6-only routing issues, could generate this problem. In this case, Happy Eyeballs could resolve the issue, however. It will work because the optimization is not enabled for dual-stack hosts.¶
5. Partial failure: Slower IPv6 vs IPv4 path end-to-end. In general, the added delay of the IPv4 translations and NATs across the path, increases the chances that IPv4 is slower than IPv6. However, it may happen that there is some IPv6 specific link congestion or packet dropping, that generates the reverse situation, so IPv4 become faster than IPv6. Because the optimization is not being used for dual-stack hosts, Happy Eyeballs will be resolving the issue.¶

In summary, the optimization will not change the Happy Eyeballs behaviour. Furthermore, it should be observed that IPv6 failures will also impact other operators (even if not using the optimization), and especially those using only NAT64+DNS64 instead of 464XLAT, or even more, any IPv6-only hosts and applications in any operator network across the entire Internet. It looks like it is very important to make sure that, as IPv6 is more prevalent, there is a better monitoring and failures are detected ASAP, instead of being hidden by Happy Eyeballs, specially in IPv6-only networks. It should be noticed also that in IPv6-only with IPv4aaS, the chances of troubles in the IPv4 paths seem to be higher than in the IPv6, as there are more translations, more devices, more delays, while the optimization will precisely reduce them.¶

5.2.15. Troubleshooting Implications

When there is a need to troubleshoot IPv4 from the CE LANs, it may happen that there is an EAMT entry forcing the flow to a given destination(s) to use IPv6, which will distort the results, unless the host being used is dual-stack (which is the most common situation).¶

This can be avoided, using a CLI/GUI or provisioning procedure, to either completely disable the optimization during the troubleshooting, or create specific static EAMT entries, using the Valid/Stale/Invalid and Auto/Static flags, as described in Section 5.2.5.¶

Consequently, the CE MUST allow both, disabling the optimization and the setup of manual/static EAMT entries.¶