Public DNS64

Wed Jun 1 12:47:10 UTC 2016

* Mark Andrews

> In message <20160601103707.7de9d97f at 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