Re: Public DNS64

2016-06-01 Thread Ca By
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

Re: Public DNS64

2016-06-01 Thread Tore Anderson
* 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.

Re: Public DNS64

2016-06-01 Thread Mark Andrews
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

Re: Public DNS64

2016-06-01 Thread Tore Anderson
* 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

Re: Public DNS64

2016-05-30 Thread Mark Tinka
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 >>

Re: Public DNS64

2016-05-30 Thread Ca By
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

Re: Public DNS64

2016-05-30 Thread Baldur Norddahl
> > 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:

Re: Public DNS64

2016-05-30 Thread Mark Andrews
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

Re: Public DNS64

2016-05-30 Thread Mikael Abrahamsson
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

Re: Public DNS64

2016-05-30 Thread Hugo Slabbert
On Mon 2016-May-30 11:45:11 +1000, Mark Andrews wrote: In message

Re: Public DNS64

2016-05-29 Thread Mark Andrews
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 ;

Re: Public DNS64

2016-05-29 Thread Mark Andrews
In message

Re: Public DNS64

2016-05-29 Thread Mark Andrews
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

Re: Public DNS64

2016-05-29 Thread Baldur Norddahl
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

Re: Public DNS64

2016-05-29 Thread 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: > >

Re: Public DNS64

2016-05-29 Thread 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

Re: Public DNS64

2014-08-16 Thread Niels Bakker
* 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

Re: Public DNS64

2014-08-15 Thread Rubens Kuhl
On Fri, Aug 15, 2014 at 3:29 PM, Tim Durack tdur...@gmail.com 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

Re: Public DNS64

2014-08-15 Thread Tim Durack
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 rube...@gmail.com wrote: On Fri, Aug 15, 2014 at 3:29 PM, Tim Durack

Re: Public DNS64

2014-08-15 Thread Mark Andrews
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

Re: Public DNS64

2014-08-15 Thread Jima
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

Re: Public DNS64

2014-08-15 Thread Mark Andrews
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

Re: Public DNS64

2014-08-15 Thread Mark Andrews
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

Re: Public DNS64

2014-08-15 Thread Larry Sheldon
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

Re: Public DNS64

2014-08-15 Thread Jima
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