Public DNS64

Ca By cb.list6 at
Mon May 30 23:44:05 UTC 2016

On Monday, May 30, 2016, Baldur Norddahl <baldur.norddahl at> wrote:

> >
> > Like HE is doing?
> >
> > swmike at uplift:~$ dig +short AAAA
> > 2001:470:64:ffff::d4f7:c88f
> > swmike at uplift:~$ ping6 2001:470:64:ffff::d4f7:c88f
> > PING 2001:470:64:ffff::d4f7:c88f(2001:470:64:ffff::d4f7:c88f) 56 data
> bytes
> > 64 bytes from 2001:470:64:ffff::d4f7:c88f: icmp_seq=1 ttl=42 time=316 ms
> > 64 bytes from 2001:470:64:ffff::d4f7:c88f: icmp_seq=2 ttl=42 time=315 ms
> >
> > Now, pinging myself via DNS64/NAT64 service and getting 315ms RTT means
> > the NAT64 isn't very local to me... :P
> 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. A more simple
> solution is just to have the DNS64 be anycast and have a DNS64 at each
> NAT64 location with the DNS64 returning pointers to the local NAT64.
> Now, can we have a public MAP server? That might scale. The geo blockers
> will hate it. What is not to like?
MAP scale. I know folks think it is theoretically nice but....

Just curious, has anyone yet deployed MAP at scale? I know of several
production and large scale nat64s (usually mobile 464xlat related), and a
few large ds-lite, but never MAP in production at scale.  Maybe i am
missing something.


> Baldur

More information about the NANOG mailing list