[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Public DNS64
- Subject: Public DNS64
- From: marka at isc.org (Mark Andrews)
- Date: Wed, 01 Jun 2016 21:49:30 +1000
- In-reply-to: Your message of "Wed, 01 Jun 2016 10:37:07 +0200." <[email protected]>
- 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> <[email protected]>
In message <20160601103707.7de9d97f at envy.e5.y.home>, Tore Anderson writes:
> * 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.
But some services are inherently short lived. NAT64 has no such
property.
> Tore
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka at isc.org