* Mark Andrews
In message <20160601103707.7de9d97f@envy.e5.y.home>, Tore Anderson writes:
Or you could simply accept that active sessions are torn down whenever the routing topology changes enough to flip traffic to the anycast prefix to another NAT64 instance in a different region.
It would be no different from any other anycasted service.
But some services are inherently short lived. NAT64 has no such property.
Well, yes - it depends on the service/application, right? That is, anycasted_${service} will work pretty much the same as ${service}_via_anycasted_nat64 for most values of ${service}. Assuming that: 1) most of your customer's sessions are short-lived and/or their applications can handle failures reasonably gracefully, and/or 2) you have a stable and well-designed network where you can be reasonably certain that the traffic from clients in city/region/country X is going to consistently be routed to the NAT64 instance in city/region/country X: ...you will have very little to gain by setting up some complicated NAT64 session replication scheme to city/region/country Y, Z, and so on. KISS: Just use different IPv4 source address pools in each location and accept that any long-lived sessions are interrupted when your routing turns really wonky once in a blue moon. If on the other hand you cannot under any circumstance accept disruption to existing sessions, you probably don't want to be using any form of NAT in the first place. It's not like anycast routes flipping is the only reason why sessions through a NAT can be disrupted. In that case, native IPv6 is probably better, or possibly MAP if you have no control over the (presumably IPv4-only) remote ends of those sessions. Tore