Subject: [v6ops] More thoughts on draft-ietf-v6ops-464xlat-optimization

From: Jen Linkova <[email-masked]>
Date: Thu, 16 Jul 2020 13:22:16 +1000

Sorry, it's me again with more comments..

First of all I fully agree there is a problem and it would be highly
desirable to solve this problem. It's not some form of corner case or
misconfiguration which we could ignore. However I'm getting less and
less convinced that the solution proposed in the document (Section
5.2) is the best way forward.

Others have already mentioned scenarios where the algorithm defined in
Section 5.2 would break things for clients and/or introduce new attack
vectors.

So I've been thinking about Section 5.1.
The draft provides two reasons to discard that approach:
1) this solution will only be possible if the CDN/cache is in the same
ASN as the provider network, or somehow interconnected without routing
thru Internet.
[nitpicking: 'the same ASN' is not a requirement, it's more about
having a direct connectivity. The caches can easily have their own
ASN]

What confuses me:  isn't it the case for IPv4 traffic already in a
dual-stack network? If the operator has a dual-stack network, the IPv4
traffic to local CDN caches would bypass CGN devices while traffic for
external destinations would need to be NATed. There is no easy way to
bypass CGN for external traffic, right? So if the solution from
Section 5.1 is implemented, the operator would need to do NAT64
instead of CGN for the same traffic. While it would not drastically
improve the situation compared to dual-stack/IPv4-only right away, it
would not make it worse either. Also, as IPv6 support is improving,
one could expect % of traffic to go through NAT64 decreasing.

2) some work required on the CDN/cache side.

Yes, it would introduce an additional requirement for CDNs to ensure
that for each IPv4 address there is a corresponding NAT46-translated
IPv6 address.
The routing needs to be updated as well - but I do not see this as a
big issue - whatever method is used to propagate IPv4 routing
information (BGP?) could be used for propagating IPv6 information as
well. Or am I missing anything?
At least in this case all mechanisms used are well-known,
straightforward, time-proved and much more predictable than creating
dynamic EAMT entries which are impossible to troubleshoot if smth goes
wrong.

To make the long story short, I believe the approach described in
Section 5.1 looks much cleaner and safer than one in Section 5.2.
-- 
SY, Jen Linkova aka Furry