Anyone know of a reliable public DNS64 service?
Would be cool if Google added a Public DNS64 service, then I could point
the NAT64 prefix at appropriately placed boxes in my network.
Why? Other people are better than me at running DNS resolvers 
No one is better than you at running DNS resolvers with low latency from
your network. Even if they can run DNS resolvers with magical capabilities,
they will still suffer from transit time.
Rubens
Yeah, sort of agree, except I'm allergic to running services that aren't
straight bit shoveling. NAT64 is pushing it, but at least that is just
announcing a prefix.
For a public DNS64 service you also need a public NAT64. I suppose
anyone willing to run a Tor exit node might be also willing to run
such a service but it would be a traffic source anonymiser and
likely would be abused.
That said I could see it as a commercial service where only certain
sets of IPv6 clients get to use the service with a strict mapping
to IPv4 source addresses, logging etc. A ISP which had already set
this up for themselves and had enough IPv4 addresses could offer
this to IPv6 only ISP's as a service they could buy.
Similarly a consortium of ISPs could set this up for their members
possibly pooling IPv4 addresses from the members.
Someone like HE might like to run such a service to further promote
IPv6.
This is something transit providers might get into. IPv6 to IPv4
Translation services for IPv6 only clients.
The same arguements also work for DS-Lite.
Mark
Not necessarily. If the public DNS64 server is using the well-known prefix 64:ff9b::/96 (from RFC6052), then all an eyeball network needs to do is route that /96 toward their own NAT64 environment.
      Jima
I can see a transfer request being made to TEXAS-WESLEYAN-UNIVERSITY
for 64.64.64.0/24.
Mark
For the record:
Tim,
I'm not on the NANOG lists and I don't see how I can respond to this thread:
    https://mailman.nanog.org/pipermail/nanog/2014-August/069267.html
but I figured I'd let you know that:
    https://developers.google.com/speed/public-dns/docs/dns64
is now available for testing. Perhaps it will be some use.
Regards,
-Erik
Interesting. Now we just need someone like he.net to announce the
64:ff9b::/96 prefix and run a public nat64 service.
Ok that would be a bad idea. Nat64 is not stateless so to anycast it would
be unstable.
Sorry time to get to sleep.
Regards
Baldur
DNS64 is a bad solution. It breaks DNSSEC. The proported benefits of
DNS64 over other ways of providing IPv4 over IPv6 don't actually exist.
DS-Lite or one of the MAP encapsulation will actually be better in the
long run.
I say this as someone who has written a DNS64 implementation.
Mark
Ok that would be a bad idea. Nat64 is not stateless so to anycast it would
be unstable.
This is not anycast NAT64. It is anycast DNS64 with the well known
64:ff9b::/96 prefix and a local NAT64 box.
While I don't like DNS64 as a solution, this service doesn't need
to be critised for faults that don't exist with it.
Mark
IP6.ARPA lookups aren't working. Adobe.com doesn't have AAAA record
so it correctly returns a DNS64 mapped AAAA record. However when
you attempt to do a IP6.ARPA lookup on that address it does not
follow the synthesised CNAME record as you would expect from a
recursive DNS64 server.
Mark
; <<>> DiG 9.11.0a2 <<>> aaaa adobe.com @2001:4860:4860::6464
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16081
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;adobe.com. IN AAAA
;; ANSWER SECTION:
adobe.com. 10799 IN AAAA 64:ff9b::c096:1075
;; Query time: 435 msec
;; SERVER: 2001:4860:4860::6464#53(2001:4860:4860::6464)
;; WHEN: Mon May 30 11:55:56 EST 2016
;; MSG SIZE rcvd: 66
; <<>> DiG 9.11.0a2 <<>> -x 64:ff9b::c096:1075 @2001:4860:4860::6464
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16070
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;5.7.0.1.6.9.0.c.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.b.9.f.f.4.6.0.0.ip6.arpa. IN PTR
;; ANSWER SECTION:
5.7.0.1.6.9.0.c.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.b.9.f.f.4.6.0.0.ip6.arpa. 10799 IN CNAME 117.16.150.192.in-addr.arpa.
;; Query time: 355 msec
;; SERVER: 2001:4860:4860::6464#53(2001:4860:4860::6464)
;; WHEN: Mon May 30 11:56:12 EST 2016
;; MSG SIZE rcvd: 138
; <<>> DiG 9.11.0a2 <<>> ptr 117.16.150.192.in-addr.arpa @2001:4860:4860::6464
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 93
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;117.16.150.192.in-addr.arpa. IN PTR
;; ANSWER SECTION:
117.16.150.192.in-addr.arpa. 10532 IN PTR www.wip4.adobe.com.
;; Query time: 338 msec
;; SERVER: 2001:4860:4860::6464#53(2001:4860:4860::6464)
;; WHEN: Mon May 30 11:56:36 EST 2016
;; MSG SIZE rcvd: 88
Ok that would be a bad idea. Nat64 is not stateless so to anycast it would
be unstable.This is not anycast NAT64. It is anycast DNS64 with the well known
64:ff9b::/96 prefix and a local NAT64 box.While I don't like DNS64 as a solution, this service doesn't need
to be critised for faults that don't exist with it.
Pretty sure this was in response to:
> Interesting. Now we just need someone like he.net to announce the
> 64:ff9b::/96 prefix and run a public nat64 service.
...so specifically regarding the idea of a public, anycast NAT64 service, rather than the public DNS64 service Google is doing.
Like HE is doing?
swmike@uplift:~$ dig +short AAAA ipv4.swm.pp.se @nat64.he.net
2001:470:64:ffff::d4f7:c88f
swmike@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... 
> ...so specifically regarding the idea of a public, anycast NAT64 service,
> rather than the public DNS64 service Google is doing.Like HE is doing?
swmike@uplift:~$ dig +short AAAA ipv4.swm.pp.se @nat64.he.net
2001:470:64:ffff::d4f7:c88f
swmike@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 msNow, pinging myself via DNS64/NAT64 service and getting 315ms RTT means
the NAT64 isn't very local to me...
I don't know if that is a anycast NAT64. Just because pings get
through doesn't mean that other traffic will get through. It really
depends upon whether all the IPv6 traffic in the stream all gets
routed to the same NAT64 instance. For short lived session this
is highly likely. For long lived sessions not so much.
For ping there is a single packet each direction. For other protocols
there isn't.
Mark
Like HE is doing?
swmike@uplift:~$ dig +short AAAA ipv4.swm.pp.se @nat64.he.net
2001:470:64:ffff::d4f7:c88f
swmike@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 msNow, pinging myself via DNS64/NAT64 service and getting 315ms RTT means
the NAT64 isn't very local to me...
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?
Regards,
Baldur
>
> Like HE is doing?
>
> swmike@uplift:~$ dig +short AAAA ipv4.swm.pp.se @nat64.he.net
> 2001:470:64:ffff::d4f7:c88f
> swmike@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...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.
CB
Regards,
That is what we do.
We've got NAT64 routers deployed at every PoP/region, to keep NAT64
state local and more predictable.
Needless to say, the distribution reduces the impact of the "CG" from
the "CG-NAT64".
Mark.
* 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
* 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.