nanog mailing list archives
Re: Public DNS64
From: Tore Anderson <tore () fud no>
Date: Wed, 1 Jun 2016 14:47:10 +0200
* 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
Current thread:
- Re: Public DNS64 Tore Anderson (Jun 01)
- Re: Public DNS64 Mark Andrews (Jun 01)
- Re: Public DNS64 Tore Anderson (Jun 01)
- <Possible follow-ups>
- Re: Public DNS64 Ca By (Jun 01)
- Re: Public DNS64 Mark Andrews (Jun 01)