has IPv4 has IPv6" & 0 "no IPv4
has
> IPv6". In other words, there are more dead names than there are
> records, and there are not any IPv6-only sites in that group.
>
> Tony
>
>
> > -Original Message-
> > From: Owen DeLong [mailto:o...
y, November 22, 2013 1:48 PM
> To: Tony Hain
> Cc: joel jaeggli; valdis.kletni...@vt.edu; NANOG List
> Subject: Re: NAT64 and matching identities
>
> So one has to wonder how those names made it into the top 100 list if it's
> supposed to be a top 100 web sites, since they are obviously n
231
> 10059,92.242.195.233
> 23912,92.242.195.30
> 31520,92.242.195.111
> 35867,92.242.195.235
> 95233,92.242.195.129
>
>
>> -Original Message-
>> From: Owen DeLong [mailto:o...@delong.com]
>> Sent: Friday, November 22, 2013 12:16 PM
>> To: joel jaeggli
>&g
2.242.195.129
> -Original Message-
> From: Owen DeLong [mailto:o...@delong.com]
> Sent: Friday, November 22, 2013 12:16 PM
> To: joel jaeggli
> Cc: valdis.kletni...@vt.edu; Tony Hain; NANOG List
> Subject: Re: NAT64 and matching identities
>
> It would be way more than 2
It would be way more than 2 if it were CNAME, methinks.
Owen
On Nov 22, 2013, at 12:12 PM, joel jaeggli wrote:
> On 11/22/13, 12:01 PM, valdis.kletni...@vt.edu wrote:
>> On Fri, 22 Nov 2013 10:18:27 -0800, "Tony Hain" said:
>>
>>> The top 100 websites: records and IPv6 connectivity
>>>
On 11/22/13, 12:01 PM, valdis.kletni...@vt.edu wrote:
> On Fri, 22 Nov 2013 10:18:27 -0800, "Tony Hain" said:
>
>> The top 100 websites: records and IPv6 connectivity
>>count with A: 98 ( 98.000%)
>> count with : 30 ( 30.000%)
>> Of the 30 hosts with AA
On Fri, 22 Nov 2013 10:18:27 -0800, "Tony Hain" said:
> The top 100 websites: records and IPv6 connectivity
>count with A: 98 ( 98.000%)
> count with : 30 ( 30.000%)
> Of the 30 hosts with records, testing connectivity to TCP/80:
> count with
I question how one can have a top 100 website without an A record.
I am inclined to believe there is a bug in there somewhere.
Owen
On Nov 22, 2013, at 10:18 AM, Tony Hain wrote:
> Lee Howard wrote:
> ...
> There is obviously a long tail of ip4 destinations, but nearly all
> of 500 of
Lee Howard wrote:
...
> >> >There is obviously a long tail of ip4 destinations, but nearly all
> >> >of 500 of the Alexa global 500 have ip6 listeners,
> >>
> >> Do you have a data source for that? I see no indication of IPv6
> >> listeners on 85% of the top sites.
> >
> >A slightly different metr
It was a stale DNS entry. Now fixed (modulo TTLs and such), thanks.
That said, your troubleshooting was troubleshooting a different
problem, not your browser's inability to retrieve the page. The way
the browser sends the request is something like this (note the HTTP
version and the host header):
On Wed, Nov 20, 2013 at 1:30 PM, Gary E. Miller wrote:
> Yo Lee!
>
> On Wed, 20 Nov 2013 16:14:47 -0500
> Lee Howard wrote:
>
> > >There is obviously a long tail of ip4 destinations, but nearly all
> > >of 500 of the Alexa global 500 have ip6 listeners,
> >
> > Do you have a data source for that
On 11/20/13 4:30 PM, "Gary E. Miller" wrote:
>Yo Lee!
>
>On Wed, 20 Nov 2013 16:14:47 -0500
>Lee Howard wrote:
>
>> >There is obviously a long tail of ip4 destinations, but nearly all
>> >of 500 of the Alexa global 500 have ip6 listeners,
>>
>> Do you have a data source for that? I see no in
Yo Lee!
On Wed, 20 Nov 2013 16:14:47 -0500
Lee Howard wrote:
> >There is obviously a long tail of ip4 destinations, but nearly all
> >of 500 of the Alexa global 500 have ip6 listeners,
>
> Do you have a data source for that? I see no indication of IPv6
> listeners on 85% of the top sites.
A s
Leaving out stuff . . .
On 11/19/13 6:53 PM, "Ian Smith" wrote:
>
>There is obviously a long tail of ip4 destinations, but nearly all of 500
>of the Alexa global 500 have ip6 listeners,
Do you have a data source for that? I see no indication of IPv6 listeners
on 85% of the top sites.
Lee
On Tue, 19 Nov 2013, Ian Smith wrote:
It depends on what direction your are translating to:
IPv6-only host to IPv4 Internet: This isn't a problem if you are
dual-stack at the host, but if you really do have ip6 only hosts, you
aren't looking at any requirement that is different than LSN44 or
It depends on what direction your are translating to:
IPv6-only host to IPv4 Internet: This isn't a problem if you are dual-stack at
the host, but if you really do have ip6 only hosts, you aren't looking at any
requirement that is different than LSN44 or providing a IPv6 tunnel broker
service
On Nov 19, 2013, at 8:36 AM, Andrew Sullivan wrote:
> On Mon, Nov 18, 2013 at 03:06:52PM -0500, Justin M. Streiner wrote:
>> Other IPv6 transition mechanisms appear to be no less thorny than
>> NAT64 for a variety of reasons.
>
> Some of us who worked on the NAT64/DNS64 combination were content
From: Justin M. Streiner [mailto:strei...@cluebyfour.org]
>It's looking more and more like NAT64 will be in our future.
>One of the valid concerns for NAT64 - much like NAT44 - is being
>able to determine the identity of a given user through the NAT
>at a given point in time.
>How feasible thi
On Mon, Nov 18, 2013 at 03:06:52PM -0500, Justin M. Streiner wrote:
> Other IPv6 transition mechanisms appear to be no less thorny than
> NAT64 for a variety of reasons.
Some of us who worked on the NAT64/DNS64 combination were content that
it was a long way from the perfect solution. The idea I
On 11/18/13 3:06 PM, "Justin M. Streiner" wrote:
>It's looking more and more like NAT64 will be in our future. One of the
>valid concerns for NAT64 - much like NAT44 - is being able to determine
>the identity of a given user through the NAT at a given point in time.
Bulk port allocation. Your
MSOs logging subscriber flows, what could possibly go wrong?
Drive slow, like a Sandvine under load,
Paul Wall
On Mon, Nov 18, 2013 at 8:03 PM, Tom Taylor wrote:
>
> On 18/11/2013 3:06 PM, Justin M. Streiner wrote:
>
>> It's looking more and more like NAT64 will be in our future. One of the
>>
On 18/11/2013 3:06 PM, Justin M. Streiner wrote:
It's looking more and more like NAT64 will be in our future. One of the
valid concerns for NAT64 - much like NAT44 - is being able to determine
the identity of a given user through the NAT at a given point in time.
How feasible this is depends on
22 matches
Mail list logo
