Re: Public DNS64
On Monday, May 30, 2016, Ca By wrote: > > > On Monday, May 30, 2016, Baldur Norddahl > wrote: > >> > >> > Like HE is doing? >> > >> > swmike@uplift:~$ dig +short ipv4.swm.pp.se @nat64.he.net >> > 2001:470:64:::d4f7:c88f >> > swmike@uplift:~$ ping6 2001:470:64:::d4f7:c88f >> > PING 2001:470:64:::d4f7:c88f(2001:470:64:::d4f7:c88f) 56 data >> bytes >> > 64 bytes from 2001:470:64:::d4f7:c88f: icmp_seq=1 ttl=42 time=316 ms >> > 64 bytes from 2001:470:64:::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. > > CB > > Tore's email reminded me that we got no answers about a production large scale MAP deployment. I guess it is yet to be deployed. Since it came up 2x in this thread, not only is MAP apparently not deployed anywhere at scale and therefore unproven in the real world, it would not fit this public usecase. MAP requires dhcpv6 and that dhcpv6 server must statefully / tight-coordination assign the addresses and ports to the end user. This complexity and requirement, along with the unsavoriness of yet another tunnel made MAP a deal breaker for my network. It also statically assigns s fixed number of scarce ipv4 ports to users, this is inefficient and not flexible. I suppose some party could launch a public dhpv6 server. But the 2nd hop routing would not work without several hacks CB > Regards, >> >> Baldur >> >
Re: Public DNS64
* Mark Andrews
> In message <20160601103707.7de9d...@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
Re: Public DNS64
In message <20160601103707.7de9d...@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: ma...@isc.org
Re: Public DNS64
* 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
Re: Public DNS64
On 31/May/16 01:28, Baldur Norddahl wrote: >> >> >> 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. 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.
Re: Public DNS64
On Monday, May 30, 2016, Baldur Norddahl wrote: > > > > Like HE is doing? > > > > swmike@uplift:~$ dig +short ipv4.swm.pp.se @nat64.he.net > > 2001:470:64:::d4f7:c88f > > swmike@uplift:~$ ping6 2001:470:64:::d4f7:c88f > > PING 2001:470:64:::d4f7:c88f(2001:470:64:::d4f7:c88f) 56 data > bytes > > 64 bytes from 2001:470:64:::d4f7:c88f: icmp_seq=1 ttl=42 time=316 ms > > 64 bytes from 2001:470:64:::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. CB Regards, > > Baldur >
Re: Public DNS64
> > Like HE is doing? > > swmike@uplift:~$ dig +short ipv4.swm.pp.se @nat64.he.net > 2001:470:64:::d4f7:c88f > swmike@uplift:~$ ping6 2001:470:64:::d4f7:c88f > PING 2001:470:64:::d4f7:c88f(2001:470:64:::d4f7:c88f) 56 data bytes > 64 bytes from 2001:470:64:::d4f7:c88f: icmp_seq=1 ttl=42 time=316 ms > 64 bytes from 2001:470:64:::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? Regards, Baldur
Re: Public DNS64
In message , Mikael Abrah amsson writes: > On Mon, 30 May 2016, Hugo Slabbert wrote: > > > ...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 ipv4.swm.pp.se @nat64.he.net > 2001:470:64:::d4f7:c88f > swmike@uplift:~$ ping6 2001:470:64:::d4f7:c88f > PING 2001:470:64:::d4f7:c88f(2001:470:64:::d4f7:c88f) 56 data > bytes > 64 bytes from 2001:470:64:::d4f7:c88f: icmp_seq=1 ttl=42 time=316 ms > 64 bytes from 2001:470:64:::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 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 > -- > Mikael Abrahamssonemail: swm...@swm.pp.se -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Public DNS64
On Mon, 30 May 2016, Hugo Slabbert wrote: ...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 ipv4.swm.pp.se @nat64.he.net 2001:470:64:::d4f7:c88f swmike@uplift:~$ ping6 2001:470:64:::d4f7:c88f PING 2001:470:64:::d4f7:c88f(2001:470:64:::d4f7:c88f) 56 data bytes 64 bytes from 2001:470:64:::d4f7:c88f: icmp_seq=1 ttl=42 time=316 ms 64 bytes from 2001:470:64:::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 -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Public DNS64
On Mon 2016-May-30 11:45:11 +1000, Mark Andrews wrote: In message , Baldur Norddahl writes: 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. Mark -- Hugo Slabbert | email, xmpp/jabber: h...@slabnet.com pgp key: B178313E | also on Signal Sorry time to get to sleep. Regards Baldur Den 30. maj 2016 03.25 skrev "Baldur Norddahl" : > Interesting. Now we just need someone like he.net to announce the > 64:ff9b::/96 prefix and run a public nat64 service. > Den 30. maj 2016 03.08 skrev "Tim Durack" : > >> 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 >> >> On Fri, Aug 15, 2014 at 2:29 PM, Tim Durack wrote: >> >> > 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 :-) >> > >> > -- >> > Tim:> >> > >> >> >> >> -- >> Tim:> >> > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org signature.asc Description: Digital signature
Re: Public DNS64
IP6.ARPA lookups aren't working. Adobe.com doesn't have record so it correctly returns a DNS64 mapped 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 <<>> 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 ;; ANSWER SECTION: adobe.com. 10799 IN 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 In message , Tim Durack writes: > 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 > > On Fri, Aug 15, 2014 at 2:29 PM, Tim Durack wrote: > > > 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 :-) > > > > -- > > Tim:> > > > > > > -- > Tim:> -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Public DNS64
In message , Baldur Norddahl writes: > 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 > Sorry time to get to sleep. > > Regards > > Baldur > Den 30. maj 2016 03.25 skrev "Baldur Norddahl" : > > > Interesting. Now we just need someone like he.net to announce the > > 64:ff9b::/96 prefix and run a public nat64 service. > > Den 30. maj 2016 03.08 skrev "Tim Durack" : > > > >> 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 > >> > >> On Fri, Aug 15, 2014 at 2:29 PM, Tim Durack wrote: > >> > >> > 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 :-) > >> > > >> > -- > >> > Tim:> > >> > > >> > >> > >> > >> -- > >> Tim:> > >> > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Public DNS64
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 In message , Tim Durack writes: > 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 > > On Fri, Aug 15, 2014 at 2:29 PM, Tim Durack wrote: > > > 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 :-) > > > > -- > > Tim:> > > > > > > -- > Tim:> -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Public DNS64
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 Den 30. maj 2016 03.25 skrev "Baldur Norddahl" : > Interesting. Now we just need someone like he.net to announce the > 64:ff9b::/96 prefix and run a public nat64 service. > Den 30. maj 2016 03.08 skrev "Tim Durack" : > >> 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 >> >> On Fri, Aug 15, 2014 at 2:29 PM, Tim Durack wrote: >> >> > 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 :-) >> > >> > -- >> > Tim:> >> > >> >> >> >> -- >> Tim:> >> >
Re: Public DNS64
Interesting. Now we just need someone like he.net to announce the 64:ff9b::/96 prefix and run a public nat64 service. Den 30. maj 2016 03.08 skrev "Tim Durack" : > 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 > > On Fri, Aug 15, 2014 at 2:29 PM, Tim Durack wrote: > > > 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 :-) > > > > -- > > Tim:> > > > > > > -- > Tim:> >
Re: Public DNS64
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 On Fri, Aug 15, 2014 at 2:29 PM, Tim Durack wrote: > 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 :-) > > -- > Tim:> > -- Tim:>
Re: Public DNS64
* larryshel...@cox.net (Larry Sheldon) [Sat 16 Aug 2014, 02:09 CEST]: On 8/15/2014 6:39 PM, Mark Andrews wrote: I can see a transfer request being made to TEXAS-WESLEYAN-UNIVERSITY for 64.64.64.0/24. May be no. You need a memerable IPv6 addresses. "memerable"? -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn form their mistakes. 'form'? Cheers, -- Niels. -- "It's amazing what people will do to get their name on the internet, which is odd, because all you really need is a Blogspot account." -- roy edroso, alicublog.blogspot.com
Re: Public DNS64
On 2014-08-15 18:08, Larry Sheldon wrote: On 8/15/2014 6:39 PM, Mark Andrews wrote: >I can see a transfer request being made to TEXAS-WESLEYAN-UNIVERSITY >for 64.64.64.0/24. May be no. You need a memerable IPv6 addresses. "memerable"? Yeah, how do you expect anyone to make a meme out of 64:ff9b::/96? :-) Jima
Re: Public DNS64
On 8/15/2014 6:39 PM, Mark Andrews wrote: >I can see a transfer request being made to TEXAS-WESLEYAN-UNIVERSITY >for 64.64.64.0/24. May be no. You need a memerable IPv6 addresses. "memerable"? -- The unique Characteristics of System Administrators: The fact that they are infallible; and, The fact that they learn form their mistakes.
Re: Public DNS64
Mark Andrews writes:
>
> In message <53ee8a4b.9000...@jima.us>, Jima writes:
> > On 2014-08-15 16:11, Mark Andrews wrote:
> > > For a public DNS64 service you also need a public NAT64.
> >
> > 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.
May be no. You need a memerable IPv6 addresses.
This all said named supports dns64 in all currently supported versions.
e.g.
options {
dns64 64:ff9b::/96 { };
};
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Public DNS64
In message <53ee8a4b.9000...@jima.us>, Jima writes: > On 2014-08-15 16:11, Mark Andrews wrote: > > For a public DNS64 service you also need a public NAT64. > > 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Public DNS64
On 2014-08-15 16:11, Mark Andrews wrote: For a public DNS64 service you also need a public NAT64. 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
Re: Public DNS64
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 In message , Tim Durack writes: > 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. > > > On Fri, Aug 15, 2014 at 2:33 PM, Rubens Kuhl wrote: > > > > > > > > > On Fri, Aug 15, 2014 at 3:29 PM, Tim Durack wrote: > > > >> 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 > > > > > > > > -- > Tim:> -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Public DNS64
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. On Fri, Aug 15, 2014 at 2:33 PM, Rubens Kuhl wrote: > > > > On Fri, Aug 15, 2014 at 3:29 PM, Tim Durack wrote: > >> 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 > > -- Tim:>
Re: Public DNS64
On Fri, Aug 15, 2014 at 3:29 PM, Tim Durack wrote: > 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
