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 2
* 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.
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 r
* 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 solu
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:[regi
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)
>
> 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_
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.
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:~
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
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
; <<>
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 do
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
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 se
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.na
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 testi
* 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 o
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 6
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,
Th
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 R
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
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 environm
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
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 o
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
25 matches
Mail list logo
