[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Public DNS64
- Subject: Public DNS64
- From: tore at fud.no (Tore Anderson)
- Date: Wed, 1 Jun 2016 10:37:07 +0200
- In-reply-to: <CAPkb-7APWcHOFSdUAe3m8BzpwnkoFB6sPX1gJV7jRhLO97+T-Q@mail.gmail.com>
- References: <CAE_ug17-taszAoO+wK-5G48_a=6mBH+Wm+a=rfcU9fWgdSZo=Q@mail.gmail.com> <CAE_ug16_y+Ww8B3vkh-V4RNgGJyGcT9GH65z7uYpf_-XuR_ReA@mail.gmail.com> <CAPkb-7Dwn1Ekc4sA1dp5_kVmJCkXiJznqF8=PB8co9Qd8k1Fbg@mail.gmail.com> <CAPkb-7Dcfwzy2amNXJS0jQKm1S36N8c5p=SpjMbeWFRt4OOphw@mail.gmail.com> <[email protected]> <[email protected]> <[email protected]> <CAPkb-7APWcHOFSdUAe3m8BzpwnkoFB6sPX1gJV7jRhLO97+T-Q@mail.gmail.com>
* Baldur Norddahl
> It goes to the USA and back again. They would need NAT64 servers in
> every region and then let the DNS64 service decide which one is close
> to you by encoding the region information in the returned IPv6
> address. Such as 2001:470:64:[region number]::/96.
>
> An anycast solution would need a distributed NAT64 implementation,
> such that the NAT64 servers could somehow synchronize state.
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.
Tore