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 how robust/scalable $XYZ's translation logging capabilities are, and possibly how easily that data can be matched against a source of identify information, such as RADIUS accounting logs, DHCP lease logs, etc. Other IPv6 transition mechanisms appear to be no less thorny than NAT64 for a variety of reasons. I'm curious to see how others are planning to tackle (or already have tacked) this issue. Discussing vendor-specific solutions is fine, but I think keeping things as platform/vendor agnostic as possible for the time being would allow this thread to be more beneficial to a wider audience. The floor is open... jms
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 how robust/scalable $XYZ's translation logging capabilities are, and possibly how easily that data can be matched against a source of identify information, such as RADIUS accounting logs, DHCP lease logs, etc.
Other IPv6 transition mechanisms appear to be no less thorny than NAT64 for a variety of reasons.
I'm curious to see how others are planning to tackle (or already have tacked) this issue. Discussing vendor-specific solutions is fine, but I think keeping things as platform/vendor agnostic as possible for the time being would allow this thread to be more beneficial to a wider audience.
The floor is open...
jms
For logging, the following IETF Behave WG drafts are nearly complete. The IPFIX version will be updated soon (I hope) to more closely match the SYSLOG based one. They both will match the new NAT MIB document, also listed below: http://datatracker.ietf.org/doc/draft-ietf-behave-ipfix-nat-logging/ http://datatracker.ietf.org/doc/draft-ietf-behave-syslog-nat-logging/ http://datatracker.ietf.org/doc/draft-ietf-behave-nat-mib/ There is also work being done on reducing log volumes by bulk allocation of ports. The following drafts will be combined to meet a Sunset WG milestone: http://datatracker.ietf.org/doc/draft-chen-sunset4-cgn-port-allocation/ http://datatracker.ietf.org/doc/draft-tsou-behave-natx4-log-reduction/ http://datatracker.ietf.org/doc/draft-donley-behave-deterministic-cgn/ Tom Taylor
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 <tom.taylor.stds@gmail.com>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 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 how robust/scalable $XYZ's translation logging capabilities are, and possibly how easily that data can be matched against a source of identify information, such as RADIUS accounting logs, DHCP lease logs, etc.
Other IPv6 transition mechanisms appear to be no less thorny than NAT64 for a variety of reasons.
I'm curious to see how others are planning to tackle (or already have tacked) this issue. Discussing vendor-specific solutions is fine, but I think keeping things as platform/vendor agnostic as possible for the time being would allow this thread to be more beneficial to a wider audience.
The floor is open...
jms
For logging, the following IETF Behave WG drafts are nearly complete. The IPFIX version will be updated soon (I hope) to more closely match the SYSLOG based one. They both will match the new NAT MIB document, also listed below:
http://datatracker.ietf.org/doc/draft-ietf-behave-ipfix-nat-logging/
http://datatracker.ietf.org/doc/draft-ietf-behave-syslog-nat-logging/
http://datatracker.ietf.org/doc/draft-ietf-behave-nat-mib/
There is also work being done on reducing log volumes by bulk allocation of ports. The following drafts will be combined to meet a Sunset WG milestone:
http://datatracker.ietf.org/doc/draft-chen-sunset4-cgn-port-allocation/
http://datatracker.ietf.org/doc/draft-tsou-behave-natx4-log-reduction/
http://datatracker.ietf.org/doc/draft-donley-behave-deterministic-cgn/
Tom Taylor
On 11/18/13 3:06 PM, "Justin M. Streiner" <streiner@cluebyfour.org> 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 NAT logs then approximate your DHCP (or whatever) logs in size and scope. Unless you mean to use it to front a web service. Then just use x-forwarded-for, and make sure your logs and log parsers can handle it. Might want to write a correlation script.
How feasible this is depends on how robust/scalable $XYZ's translation logging capabilities are, and possibly how easily that data can be matched against a source of identify information, such as RADIUS accounting logs, DHCP lease logs, etc.
Ask the vendors; it took them a while, but they all have techniques for reducing logs.
Other IPv6 transition mechanisms appear to be no less thorny than NAT64 for a variety of reasons.
Yes; see rfc7021. Once you've deployed it, an experience report at a NANOG meeting would be welcome. Lee
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 at least had was to get something that mostly worked most of the time, and was simple enough that anyone could basically understand it. Nevertheless, I have to admit that it's a pig. That piggishness was not something I wanted to get rid of. I thought (and still think) that if the transition mechanisms are awful enough, it will encourage moving things to v6 for real so that we can get rid of the kludges. Perhaps this is wishful thinking, however. In any case, I'm sorry to have contributed in some little way to this headache of yours. Best, A -- Andrew Sullivan Dyn, Inc. asullivan@dyn.com v: +1 603 663 0448
On Nov 19, 2013, at 8:36 AM, Andrew Sullivan <asullivan@dyn.com> 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 that it was a long way from the perfect solution. The idea I at least had was to get something that mostly worked most of the time, and was simple enough that anyone could basically understand it. Nevertheless, I have to admit that it's a pig.
That piggishness was not something I wanted to get rid of. I thought (and still think) that if the transition mechanisms are awful enough, it will encourage moving things to v6 for real so that we can get rid of the kludges. Perhaps this is wishful thinking, however.
In any case, I'm sorry to have contributed in some little way to this headache of yours.
Speaking as one of the co-authors of RFC 6052, 6144, and 6145... I'm actually not sorry. The predecessor to RFCs 6052/6144/6145/6146/6147 was NAT-PT, which didn't work very well in part due to a nasty coupling (see RFC 4966). It's pretty straightforward to insert an IPv4 address into a specified IPv6 prefix (RFC 6052), and use that to statelessly translate between a IPv4 address and an RFC 6052 address (RFC 6145), or to statefully translate a random IPv6 address into an IPv4 space much in the way IPv4/IPv4 translation works (RFC 6146). What is hard is statefully translating from IPv4 to a generic IPv6 address - its hard to compress 128 bits of information into 32 bits. NAT-PT does it by having the DNS lookup temporarily assign an IPv4 address to the IPv6 device and inform the translator of the translation. http://tools.ietf.org/html/draft-anderson-siit-dc (which Tore didn't, to my knowledge, try to get turned into an RFC, although I'd be willing to discuss that with v6ops) does it by pre-assigning address pairs, enabling an IPv6-only domain to be accessed from an IPv4-only domain by a defined translation between the two for a small set of servers. I'm all for helping people to transition. Where I get a little crazy is when the so-called transition tool makes them comfortable enough that they think they don't need to. What I expect to see in the IETF over the coming few years - and which I see in detail coming from several <nationality> competitors and their <nationality> network customers now - is a series of ideas of the form "but people with ancient IPv4-only hosts are having trouble with the IPv6 network; let's do this *temporary* patch to ease their pain". I submit that the best way to ease their pain is to upgrade their hosts. They will have to deal with it at some point.
From: Justin M. Streiner [mailto:streiner@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 this is depends on how robust/scalable $XYZ's translation logging capabilities are, and possibly how easily that data can be matched against a source of identify information, such as RADIUS accounting logs, DHCP lease logs, etc.
... snip ... We implemented a product around this. What we found in doing so was that a) you need to use port-block allocation to make it feasible (cannot do unbounded NATP where every flow gets its own port), That AAA works well when the NAT is a gateway device, and that Otherwise DHCP works ok, and syslog is the fallback. All devices Supported one of those three. We also found there was a need for IPV6 identification (e.g. some customers used DNS reverse lookup in ipv4 to find the ID of a user for e.g. single-sign-on type solutions, and this no longer worked in a NAT44/NAT64/IPv6 environment. We found there was a need for both real-time (e.g. query who is this right now, e.g. sign-on), and after the fact (who had this @ this time). The general purpose coordinates we called 'session qualifiers', and we found that sometimes it included VLAN or MPLS or other tunnels. Let me know if u want more info and I can follow up offline.
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 (like he.net). Since NAT64 is necessarily predicated by a DNS64 operation and you know who you gave an IP address to because they logged in (in some fashion) so you could bill them, you can log {subID,src_ip6,xlat_ip4:port,dst_ip4:port,fqdn} using syslog or ipfix (in as little as one message, depending on the AAA and IPAM architecture) and invest in log servers. Port block allocation and deterministic schemes are possible here as well, but really, the only way to know you aren't going to be surprised by a lost or inaccurate data set under subpoena is to just log everything and write it off as a statutory expense. There is obviously a long tail of ip4 destinations, but nearly all of 500 of the Alexa global 500 have ip6 listeners, so the majority of your connections from ip6 only hosts should be leaving your network without NAT and if they aren't, you should figure out why as part of reassessing the problem. IPv6 Internet to IPv4-only host: Just do LB64 with an IP proxy. Most commercial SLB/ADC vendors do this today and offer varying degrees of ALG to fix-up protocols that have multiple channels. Your server doesn't need to know that there is a IPv6 portion of the connection unless they are doing something absurd like trying to initiate connections to IPv6 only hosts, and the ADC will help you deal with it as well. Conveying the xlat information is protocol specific - HTTP and SIP are super easy, since that same ADC will do header inserts with the original client ip, others might not be, but by not having dual-stack applications, you are committing yourself to the tedium of protocol by protocol fix-ups. You can help out that particular headache by using name lookups instead of address lookups (getaddrinfo instead of gethostbyaddr on POSIX systems) ________________________________________ From: Justin M. Streiner [streiner@cluebyfour.org] Sent: Monday, November 18, 2013 3:06 PM To: nanog@nanog.org Subject: NAT64 and matching identities 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 how robust/scalable $XYZ's translation logging capabilities are, and possibly how easily that data can be matched against a source of identify information, such as RADIUS accounting logs, DHCP lease logs, etc. Other IPv6 transition mechanisms appear to be no less thorny than NAT64 for a variety of reasons. I'm curious to see how others are planning to tackle (or already have tacked) this issue. Discussing vendor-specific solutions is fine, but I think keeping things as platform/vendor agnostic as possible for the time being would allow this thread to be more beneficial to a wider audience. The floor is open... jms
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 providing a IPv6 tunnel broker service (like he.net). Since NAT64 is necessarily predicated by a DNS64 operation and you know who you gave an IP address to because they logged in (in some fashion) so you could bill them, you can log {subID,src_ip6,xlat_ip4:port,dst_ip4:port,fqdn} using syslog or ipfix (in as little as one message, depending on the AAA and IPAM architecture) and invest in log servers. Port block allocation and deterministic schemes are possible here as well, but really, the only way to know you aren't going to be surprised by a lost or inaccurate data set under subpoena is to just log everything and write it off as a statutory expense.
Much of our initial deployment will be dual-stack, however I also want to plan for situations where we won't have enough v4 addresses to dual-stack (or we reach a point where we need to hold some of our routable v4 space in reserve for transition mechanisms), plus dual-stack on its own provides no incentive for users to migrate completely to v6. That said, I need to plan for the eventuality of v6-only hosts being able to reach the v4 Internet. While many of the Alexa global 500 sites have some sort of v6 capability today and the percentage of global Internet traffic that is v6 is increasing every day, the need for reachability to what remains of the v4 Internet will not go away any time soon. jms
Leaving out stuff . . . On 11/19/13 6:53 PM, "Ian Smith" <I.Smith@F5.com> 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
Yo Lee! On Wed, 20 Nov 2013 16:14:47 -0500 Lee Howard <Lee@asgard.org> 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 metric, 44% of USA content available on IPv6: http://6lab.cisco.com/stats/ RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701 gem@rellim.com Tel:+1(541)382-8588
On 11/20/13 4:30 PM, "Gary E. Miller" <gem@rellim.com> wrote:
Yo Lee!
On Wed, 20 Nov 2013 16:14:47 -0500 Lee Howard <Lee@asgard.org> 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 metric, 44% of USA content available on IPv6:
Right, weighted by DNS queries. Compare to http://www.vyncke.org/ipv6status/detailed.php?country=us and http://www.employees.org/~dwing/aaaa-stats/ Not equivalent to "nearly all of Alexa 500." Lee
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 metric, 44% of USA content available on IPv6:
Right, weighted by DNS queries. Compare to http://www.vyncke.org/ipv6status/detailed.php?country=us and http://www.employees.org/~dwing/aaaa-stats/
Not equivalent to "nearly all of Alexa 500."
Using a derivative of Dan Wings code from a couple of years back I get: The top 5 websites: AAAA records and IPv6 connectivity count with A: 5 (100.000%) count with AAAA: 4 ( 80.000%) Of the 4 hosts with AAAA records, testing connectivity to TCP/80: count with IPv6 ok: 4 (100.000%) The top 10 websites: AAAA records and IPv6 connectivity count with A: 10 (100.000%) count with AAAA: 6 ( 60.000%) Of the 6 hosts with AAAA records, testing connectivity to TCP/80: count with IPv6 ok: 6 (100.000%) The top 25 websites: AAAA records and IPv6 connectivity count with A: 25 (100.000%) count with AAAA: 10 ( 40.000%) Of the 10 hosts with AAAA records, testing connectivity to TCP/80: count with IPv6 ok: 10 (100.000%) The top 50 websites: AAAA records and IPv6 connectivity count with A: 50 (100.000%) count with AAAA: 21 ( 42.000%) Of the 21 hosts with AAAA records, testing connectivity to TCP/80: count with IPv6 ok: 21 (100.000%) The top 100 websites: AAAA records and IPv6 connectivity count with A: 98 ( 98.000%) count with AAAA: 30 ( 30.000%) Of the 30 hosts with AAAA records, testing connectivity to TCP/80: count with IPv6 ok: 30 (100.000%) The top 250 websites: AAAA records and IPv6 connectivity count with A: 248 ( 99.200%) count with AAAA: 56 ( 22.400%) Of the 56 hosts with AAAA records, testing connectivity to TCP/80: count with IPv6 ok: 56 (100.000%) The top 500 websites: AAAA records and IPv6 connectivity count with A: 494 ( 98.800%) count with AAAA: 91 ( 18.200%) Of the 91 hosts with AAAA records, testing connectivity to TCP/80: count with IPv6 ok: 91 (100.000%) The top 1000 websites: AAAA records and IPv6 connectivity count with A: 990 ( 99.000%) count with AAAA: 132 ( 13.200%) Of the 132 hosts with AAAA records, testing connectivity to TCP/80: count with IPv6 ok: 132 (100.000%) The top 2500 websites: AAAA records and IPv6 connectivity count with A: 2479 ( 99.160%) count with AAAA: 216 ( 8.640%) Of the 216 hosts with AAAA records, testing connectivity to TCP/80: count with IPv6 ok: 214 ( 99.074%) The top 5000 websites: AAAA records and IPv6 connectivity count with A: 4959 ( 99.220%) count with AAAA: 354 ( 7.083%) Of the 354 hosts with AAAA records, testing connectivity to TCP/80: count with IPv6 ok: 347 ( 98.023%) The top 10000 websites: AAAA records and IPv6 connectivity count with A: 9918 ( 99.230%) count with AAAA: 600 ( 6.003%) Of the 600 hosts with AAAA records, testing connectivity to TCP/80: count with IPv6 ok: 575 ( 95.833%) Original code developed by dwing@employees.org. manual run by tony on arabian.tndh.net using ./IPv6-check . on Fri Nov 22 09:48:17 PST 2013 (elapsed: 00:08:33, t: 15). Top 10000 websites based on Alexa top-1m.csv.
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 <alh-ietf@tndh.net> wrote:
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 metric, 44% of USA content available on IPv6:
Right, weighted by DNS queries. Compare to http://www.vyncke.org/ipv6status/detailed.php?country=us and http://www.employees.org/~dwing/aaaa-stats/
Not equivalent to "nearly all of Alexa 500."
Using a derivative of Dan Wings code from a couple of years back I get:
The top 5 websites: AAAA records and IPv6 connectivity count with A: 5 (100.000%) count with AAAA: 4 ( 80.000%) Of the 4 hosts with AAAA records, testing connectivity to TCP/80: count with IPv6 ok: 4 (100.000%)
The top 10 websites: AAAA records and IPv6 connectivity count with A: 10 (100.000%) count with AAAA: 6 ( 60.000%) Of the 6 hosts with AAAA records, testing connectivity to TCP/80: count with IPv6 ok: 6 (100.000%)
The top 25 websites: AAAA records and IPv6 connectivity count with A: 25 (100.000%) count with AAAA: 10 ( 40.000%) Of the 10 hosts with AAAA records, testing connectivity to TCP/80: count with IPv6 ok: 10 (100.000%)
The top 50 websites: AAAA records and IPv6 connectivity count with A: 50 (100.000%) count with AAAA: 21 ( 42.000%) Of the 21 hosts with AAAA records, testing connectivity to TCP/80: count with IPv6 ok: 21 (100.000%)
The top 100 websites: AAAA records and IPv6 connectivity count with A: 98 ( 98.000%) count with AAAA: 30 ( 30.000%) Of the 30 hosts with AAAA records, testing connectivity to TCP/80: count with IPv6 ok: 30 (100.000%)
The top 250 websites: AAAA records and IPv6 connectivity count with A: 248 ( 99.200%) count with AAAA: 56 ( 22.400%) Of the 56 hosts with AAAA records, testing connectivity to TCP/80: count with IPv6 ok: 56 (100.000%)
The top 500 websites: AAAA records and IPv6 connectivity count with A: 494 ( 98.800%) count with AAAA: 91 ( 18.200%) Of the 91 hosts with AAAA records, testing connectivity to TCP/80: count with IPv6 ok: 91 (100.000%)
The top 1000 websites: AAAA records and IPv6 connectivity count with A: 990 ( 99.000%) count with AAAA: 132 ( 13.200%) Of the 132 hosts with AAAA records, testing connectivity to TCP/80: count with IPv6 ok: 132 (100.000%)
The top 2500 websites: AAAA records and IPv6 connectivity count with A: 2479 ( 99.160%) count with AAAA: 216 ( 8.640%) Of the 216 hosts with AAAA records, testing connectivity to TCP/80: count with IPv6 ok: 214 ( 99.074%)
The top 5000 websites: AAAA records and IPv6 connectivity count with A: 4959 ( 99.220%) count with AAAA: 354 ( 7.083%) Of the 354 hosts with AAAA records, testing connectivity to TCP/80: count with IPv6 ok: 347 ( 98.023%)
The top 10000 websites: AAAA records and IPv6 connectivity count with A: 9918 ( 99.230%) count with AAAA: 600 ( 6.003%) Of the 600 hosts with AAAA records, testing connectivity to TCP/80: count with IPv6 ok: 575 ( 95.833%)
Original code developed by dwing@employees.org. manual run by tony on arabian.tndh.net using ./IPv6-check . on Fri Nov 22 09:48:17 PST 2013 (elapsed: 00:08:33, t: 15). Top 10000 websites based on Alexa top-1m.csv.
On Fri, 22 Nov 2013 10:18:27 -0800, "Tony Hain" said:
The top 100 websites: AAAA records and IPv6 connectivity count with A: 98 ( 98.000%) count with AAAA: 30 ( 30.000%) Of the 30 hosts with AAAA records, testing connectivity to TCP/80: count with IPv6 ok: 30 (100.000%)
Statistics whoopsie, or are there actually 2 sites in the top100 that are IPv6-only?
On 11/22/13, 12:01 PM, Valdis.Kletnieks@vt.edu wrote:
On Fri, 22 Nov 2013 10:18:27 -0800, "Tony Hain" said:
The top 100 websites: AAAA records and IPv6 connectivity count with A: 98 ( 98.000%) count with AAAA: 30 ( 30.000%) Of the 30 hosts with AAAA records, testing connectivity to TCP/80: count with IPv6 ok: 30 (100.000%)
Statistics whoopsie, or are there actually 2 sites in the top100 that are IPv6-only?
IN CNAME ? or is that being accounted for.
It would be way more than 2 if it were CNAME, methinks. Owen On Nov 22, 2013, at 12:12 PM, joel jaeggli <joelja@bogus.com> wrote:
On 11/22/13, 12:01 PM, Valdis.Kletnieks@vt.edu wrote:
On Fri, 22 Nov 2013 10:18:27 -0800, "Tony Hain" said:
The top 100 websites: AAAA records and IPv6 connectivity count with A: 98 ( 98.000%) count with AAAA: 30 ( 30.000%) Of the 30 hosts with AAAA records, testing connectivity to TCP/80: count with IPv6 ok: 30 (100.000%)
Statistics whoopsie, or are there actually 2 sites in the top100 that are IPv6-only?
IN CNAME ? or is that being accounted for.
The only thing it explicitly strips out are dotted-quads, which don't occur until # 4255. The code makes five passes at getaddrinfo() for IPv4 before giving up, and then it checks for a leading www and if that exists it strips it off and does the 5 tries loop again, then later the same process for IPv6. For the top 100 run: akamaihd.net no IPv4 no IPv6 bp.blogspot.com no IPv4 no IPv6 FWIW ::: Dotted-quad's in the top 10,000 4255,92.242.195.24 4665,1.1.1.1 5079,92.242.195.231 6130,1.254.254.254 9518,208.98.30.70
whois 92.242.195.24 ... netname: Respina descr: BroadBand IP Pool country: IR ... route: 92.242.195.0/24
Respina BroadBand IP Pool in the top 100,000 4255,92.242.195.24 5079,92.242.195.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:owen@delong.com] Sent: Friday, November 22, 2013 12:16 PM To: joel jaeggli Cc: Valdis.Kletnieks@vt.edu; Tony Hain; NANOG List Subject: Re: NAT64 and matching identities
It would be way more than 2 if it were CNAME, methinks.
Owen
On Nov 22, 2013, at 12:12 PM, joel jaeggli <joelja@bogus.com> wrote:
On 11/22/13, 12:01 PM, Valdis.Kletnieks@vt.edu wrote:
On Fri, 22 Nov 2013 10:18:27 -0800, "Tony Hain" said:
The top 100 websites: AAAA records and IPv6 connectivity count with A: 98 ( 98.000%) count with AAAA: 30 ( 30.000%) Of the 30 hosts with AAAA records, testing connectivity to TCP/80: count with IPv6 ok: 30 (100.000%)
Statistics whoopsie, or are there actually 2 sites in the top100 that are IPv6-only?
IN CNAME ? or is that being accounted for.
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 not web sites. (at least in the case of the two in the top 100) Owen On Nov 22, 2013, at 1:28 PM, Tony Hain <alh-ietf@tndh.net> wrote:
The only thing it explicitly strips out are dotted-quads, which don't occur until # 4255. The code makes five passes at getaddrinfo() for IPv4 before giving up, and then it checks for a leading www and if that exists it strips it off and does the 5 tries loop again, then later the same process for IPv6. For the top 100 run: akamaihd.net no IPv4 no IPv6 bp.blogspot.com no IPv4 no IPv6
FWIW ::: Dotted-quad's in the top 10,000 4255,92.242.195.24 4665,1.1.1.1 5079,92.242.195.231 6130,1.254.254.254 9518,208.98.30.70
whois 92.242.195.24 ... netname: Respina descr: BroadBand IP Pool country: IR ... route: 92.242.195.0/24
Respina BroadBand IP Pool in the top 100,000 4255,92.242.195.24 5079,92.242.195.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:owen@delong.com] Sent: Friday, November 22, 2013 12:16 PM To: joel jaeggli Cc: Valdis.Kletnieks@vt.edu; Tony Hain; NANOG List Subject: Re: NAT64 and matching identities
It would be way more than 2 if it were CNAME, methinks.
Owen
On Nov 22, 2013, at 12:12 PM, joel jaeggli <joelja@bogus.com> wrote:
On 11/22/13, 12:01 PM, Valdis.Kletnieks@vt.edu wrote:
On Fri, 22 Nov 2013 10:18:27 -0800, "Tony Hain" said:
The top 100 websites: AAAA records and IPv6 connectivity count with A: 98 ( 98.000%) count with AAAA: 30 ( 30.000%) Of the 30 hosts with AAAA records, testing connectivity to TCP/80: count with IPv6 ok: 30 (100.000%)
Statistics whoopsie, or are there actually 2 sites in the top100 that are IPv6-only?
IN CNAME ? or is that being accounted for.
Someone from Alexa really needs to answer how that list is created because their web site discussion is way too hand-wavy, but given that neither of those appear to be currently valid names, and 1.1.1.1 is on the list at all, there must be some measure of cross link and redirection occurrences. For the entire top-1m, I show today's file has 2815 as dotted-quad. In the top 50,000 there are 1790 with "no IPv4 no IPv6". Clearly they don't bother to prune the list for validity. ~4% of the next 25,000 names are dead (50,000-75,000), and one can only guess that as you get further down the list the percentage of dead names will continue to go up. I have a full 1M run in process, but would not count on it completing before Monday. Just to add a level of 'extra effort' to the process, I increased the number of attempts to 10, and the time between attempts to 10 seconds. With that, dead names in the top 1000: akamaihd.net no IPv4 no IPv6 bp.blogspot.com no IPv4 no IPv6 delta-search.com no IPv4 no IPv6 bannersdontwork.com no IPv4 no IPv6 cloudfront.net no IPv4 no IPv6 doorblog.jp no IPv4 no IPv6 uimserv.net no IPv4 no IPv6 linksynergy.com no IPv4 no IPv6 lipixeltrack.com no IPv4 no IPv6 australianbrewingcompany.com no IPv4 no IPv6 searchfun.in no IPv4 no IPv6 greatappsdownload.com no IPv4 no IPv6 klikbca.com no IPv4 no IPv6 jobfindgold.info no IPv4 no IPv6 adnxs.com no IPv4 no IPv6 rakuten.ne.jp no IPv4 no IPv6 sweetpacks-search.com no IPv4 no IPv6 yomiuri.co.jp no IPv4 no IPv6 incredibar-search.com no IPv4 no IPv6 searchgol.com no IPv4 no IPv6 livedoor.biz no IPv4 no IPv6 workercn.cn no IPv4 no IPv6 FWIW: in the top 50,000, I show 1525 "has IPv4 has IPv6" & 0 "no IPv4 has IPv6". In other words, there are more dead names than there are AAAA records, and there are not any IPv6-only sites in that group. Tony
-----Original Message----- From: Owen DeLong [mailto:owen@delong.com] Sent: Friday, November 22, 2013 1:48 PM To: Tony Hain Cc: joel jaeggli; Valdis.Kletnieks@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 not web sites. (at least in the case of the two in the top 100)
Owen
On Nov 22, 2013, at 1:28 PM, Tony Hain <alh-ietf@tndh.net> wrote:
The only thing it explicitly strips out are dotted-quads, which don't occur until # 4255. The code makes five passes at getaddrinfo() for IPv4 before giving up, and then it checks for a leading www and if that exists it strips it off and does the 5 tries loop again, then later the same process for IPv6. For the top 100 run: akamaihd.net no IPv4 no IPv6 bp.blogspot.com no IPv4 no IPv6
FWIW ::: Dotted-quad's in the top 10,000 4255,92.242.195.24 4665,1.1.1.1 5079,92.242.195.231 6130,1.254.254.254 9518,208.98.30.70
whois 92.242.195.24 ... netname: Respina descr: BroadBand IP Pool country: IR ... route: 92.242.195.0/24
Respina BroadBand IP Pool in the top 100,000 4255,92.242.195.24 5079,92.242.195.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:owen@delong.com] Sent: Friday, November 22, 2013 12:16 PM To: joel jaeggli Cc: Valdis.Kletnieks@vt.edu; Tony Hain; NANOG List Subject: Re: NAT64 and matching identities
It would be way more than 2 if it were CNAME, methinks.
Owen
On Nov 22, 2013, at 12:12 PM, joel jaeggli <joelja@bogus.com> wrote:
On 11/22/13, 12:01 PM, Valdis.Kletnieks@vt.edu wrote:
On Fri, 22 Nov 2013 10:18:27 -0800, "Tony Hain" said:
The top 100 websites: AAAA records and IPv6 connectivity count with A: 98 ( 98.000%) count with AAAA: 30 ( 30.000%) Of the 30 hosts with AAAA records, testing connectivity to TCP/80: count with IPv6 ok: 30 (100.000%)
Statistics whoopsie, or are there actually 2 sites in the top100 that are IPv6-only?
IN CNAME ? or is that being accounted for.
So it turns out that in many cases a missing www is causing the "no IPv4" response, and someone from Alexa does need to explain what is going on. For the entire top-1m.csv file, 35,554 entries returned "no IPv4". For each entry in the csv file; some return NXDOMAIN: discart.ru --> NXDOMAIN www.discart.ru resolves, but Alexa file missing www. Alexa position: 4721,discart.ru some return without any answer: bp.blogspot.com --> No Answer www.bp.blogspot.com resolves, but Alexa file missing www. Alexa position: 87,bp.blogspot.com while others point to MX-only entries: akamaihd.net --> MX-only www.akamaihd.net resolves, but Alexa file missing www. Alexa position: 74,akamaihd.net The version of the code I have been using strips the www. and tries again, but obviously it also needs to add the www. and retry. In any case, the Alexa file points to names that do not serve web content, so the entire 'top 1M' list is suspect. Tony
-----Original Message----- From: Tony Hain [mailto:alh-ietf@tndh.net] Sent: Friday, November 22, 2013 3:50 PM To: 'Owen DeLong' Cc: Sherfesee@amazon.com; 'NANOG List' Subject: RE: NAT64 and matching identities
Someone from Alexa really needs to answer how that list is created because their web site discussion is way too hand-wavy, but given that neither of those appear to be currently valid names, and 1.1.1.1 is on the list at all, there must be some measure of cross link and redirection occurrences. For the entire top-1m, I show today's file has 2815 as dotted-quad. In the top 50,000 there are 1790 with "no IPv4 no IPv6". Clearly they don't bother to prune the list for validity. ~4% of the next 25,000 names are dead (50,000- 75,000), and one can only guess that as you get further down the list the percentage of dead names will continue to go up. I have a full 1M run in process, but would not count on it completing before Monday.
Just to add a level of 'extra effort' to the process, I increased the number of attempts to 10, and the time between attempts to 10 seconds. With that, dead names in the top 1000: akamaihd.net no IPv4 no IPv6 bp.blogspot.com no IPv4 no IPv6 delta-search.com no IPv4 no IPv6 bannersdontwork.com no IPv4 no IPv6 cloudfront.net no IPv4 no IPv6 doorblog.jp no IPv4 no IPv6 uimserv.net no IPv4 no IPv6 linksynergy.com no IPv4 no IPv6 lipixeltrack.com no IPv4 no IPv6 australianbrewingcompany.com no IPv4 no IPv6 searchfun.in no IPv4 no IPv6 greatappsdownload.com no IPv4 no IPv6 klikbca.com no IPv4 no IPv6 jobfindgold.info no IPv4 no IPv6 adnxs.com no IPv4 no IPv6 rakuten.ne.jp no IPv4 no IPv6 sweetpacks-search.com no IPv4 no IPv6 yomiuri.co.jp no IPv4 no IPv6 incredibar-search.com no IPv4 no IPv6 searchgol.com no IPv4 no IPv6 livedoor.biz no IPv4 no IPv6 workercn.cn no IPv4 no IPv6
FWIW: in the top 50,000, I show 1525 "has IPv4 has IPv6" & 0 "no IPv4 has IPv6". In other words, there are more dead names than there are AAAA records, and there are not any IPv6-only sites in that group.
Tony
-----Original Message----- From: Owen DeLong [mailto:owen@delong.com] Sent: Friday, November 22, 2013 1:48 PM To: Tony Hain Cc: joel jaeggli; Valdis.Kletnieks@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 not web sites. (at least in the case of the two in the top 100)
Owen
On Nov 22, 2013, at 1:28 PM, Tony Hain <alh-ietf@tndh.net> wrote:
The only thing it explicitly strips out are dotted-quads, which don't occur until # 4255. The code makes five passes at getaddrinfo() for IPv4 before giving up, and then it checks for a leading www and if that exists it strips it off and does the 5 tries loop again, then later the same process for IPv6. For the top 100 run: akamaihd.net no IPv4 no IPv6 bp.blogspot.com no IPv4 no IPv6
FWIW ::: Dotted-quad's in the top 10,000 4255,92.242.195.24 4665,1.1.1.1 5079,92.242.195.231 6130,1.254.254.254 9518,208.98.30.70
whois 92.242.195.24 ... netname: Respina descr: BroadBand IP Pool country: IR ... route: 92.242.195.0/24
Respina BroadBand IP Pool in the top 100,000 4255,92.242.195.24 5079,92.242.195.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:owen@delong.com] Sent: Friday, November 22, 2013 12:16 PM To: joel jaeggli Cc: Valdis.Kletnieks@vt.edu; Tony Hain; NANOG List Subject: Re: NAT64 and matching identities
It would be way more than 2 if it were CNAME, methinks.
Owen
On Nov 22, 2013, at 12:12 PM, joel jaeggli <joelja@bogus.com> wrote:
On 11/22/13, 12:01 PM, Valdis.Kletnieks@vt.edu wrote:
On Fri, 22 Nov 2013 10:18:27 -0800, "Tony Hain" said:
> The top 100 websites: AAAA records and IPv6 connectivity > count with A: 98 ( 98.000%) > count with AAAA: 30 ( 30.000%) > Of the 30 hosts with AAAA records, testing connectivity to TCP/80: > count with IPv6 ok: 30 (100.000%)
Statistics whoopsie, or are there actually 2 sites in the top100 that are IPv6-only?
IN CNAME ? or is that being accounted for.
On Wed, Nov 20, 2013 at 1:30 PM, Gary E. Miller <gem@rellim.com> wrote:
Yo Lee!
On Wed, 20 Nov 2013 16:14:47 -0500 Lee Howard <Lee@asgard.org> 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 metric, 44% of USA content available on IPv6:
I'm puzzled; I have native v6 connectivity to 6lab.cisco.com according to traceroute6 output, and yet the page says I'm connecting to it via IPv4. :( So, I did some poking; it seems 6lab.cisco.com doesn't have working IPv6 for their stats system, which makes me wonder how accurate the data from it is likely to be: mpetach@mintyHP:~> telnet -6 6lab.cisco.com 80 Trying 2001:420:4420:101:0:c:15c0:4664... Connected to 6lab.cisco.com. Escape character is '^]'. GET / HTTP/1.0 HTTP/1.1 302 Found Date: Thu, 21 Nov 2013 19:03:29 GMT Server: Apache/2.2.16 (Debian) Location: http://6lab-stats.com/index.php Cache-Control: max-age=1 Expires: Thu, 21 Nov 2013 19:03:30 GMT Vary: Accept-Encoding Content-Length: 295 Connection: close Content-Type: text/html; charset=iso-8859-1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>302 Found</title> </head><body> <h1>Found</h1> <p>The document has moved <a href="http://6lab-stats.com/index.php ">here</a>.</p> <hr> <address>Apache/2.2.16 (Debian) Server at 6lab-stats.com Port 80</address> </body></html> Connection closed by foreign host. mpetach@mintyHP:~> telnet -6 6lab-stats.com 80 Trying 2001:420:81:101:0:c:15c0:4664... telnet: Unable to connect to remote host: Connection timed out mpetach@mintyHP:~> mpetach@mintyHP:~> ping6 6lab-stats.com PING 6lab-stats.com(2001:420:81:101:0:c:15c0:4664) 56 data bytes ^C --- 6lab-stats.com ping statistics --- 10 packets transmitted, 0 received, 100% packet loss, time 9071ms mpetach@mintyHP:~>
RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701 gem@rellim.com Tel:+1(541)382-8588
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): ayourtch@mcmini:~$ telnet -6 6lab.cisco.com 80 Trying 2001:420:4420:101:0:c:15c0:4664... Connected to 6lab.cisco.com. Escape character is '^]'. GET / HTTP/1.1 Host: 6lab.cisco.com HTTP/1.1 302 Found Date: Thu, 21 Nov 2013 19:38:31 GMT Server: Apache/2.2.16 (Debian) X-Frame-Options: SAMEORIGIN Location: http://6lab.cisco.com/index.php Cache-Control: max-age=1 Expires: Thu, 21 Nov 2013 19:38:32 GMT Vary: Accept-Encoding Content-Length: 295 Content-Type: text/html; charset=iso-8859-1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>302 Found</title> </head><body> <h1>Found</h1> <p>The document has moved <a href="http://6lab.cisco.com/index.php">here</a>.</p> <hr> <address>Apache/2.2.16 (Debian) Server at 6lab.cisco.com Port 80</address> </body></html> Anyway, the fact that you were still able to retrieve the original reply with a redirect, makes me think that there could be a PMTUD problem somewhere inbetween 6lab and yourself for retrieving the larger content ... If you tell your client address I will be able to test this theory. Or you can quickly tweak your local interface value to 1280 and if that works, then tell me your client address so i could debug from the other side. --a On 11/21/13, Matthew Petach <mpetach@netflight.com> wrote:
On Wed, Nov 20, 2013 at 1:30 PM, Gary E. Miller <gem@rellim.com> wrote:
Yo Lee!
On Wed, 20 Nov 2013 16:14:47 -0500 Lee Howard <Lee@asgard.org> 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 metric, 44% of USA content available on IPv6:
I'm puzzled; I have native v6 connectivity to 6lab.cisco.com according to traceroute6 output, and yet the page says I'm connecting to it via IPv4. :( So, I did some poking; it seems 6lab.cisco.com doesn't have working IPv6 for their stats system, which makes me wonder how accurate the data from it is likely to be:
mpetach@mintyHP:~> telnet -6 6lab.cisco.com 80 Trying 2001:420:4420:101:0:c:15c0:4664... Connected to 6lab.cisco.com. Escape character is '^]'. GET / HTTP/1.0
HTTP/1.1 302 Found Date: Thu, 21 Nov 2013 19:03:29 GMT Server: Apache/2.2.16 (Debian) Location: http://6lab-stats.com/index.php Cache-Control: max-age=1 Expires: Thu, 21 Nov 2013 19:03:30 GMT Vary: Accept-Encoding Content-Length: 295 Connection: close Content-Type: text/html; charset=iso-8859-1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>302 Found</title> </head><body> <h1>Found</h1> <p>The document has moved <a href="http://6lab-stats.com/index.php ">here</a>.</p> <hr> <address>Apache/2.2.16 (Debian) Server at 6lab-stats.com Port 80</address> </body></html> Connection closed by foreign host. mpetach@mintyHP:~> telnet -6 6lab-stats.com 80 Trying 2001:420:81:101:0:c:15c0:4664... telnet: Unable to connect to remote host: Connection timed out mpetach@mintyHP:~> mpetach@mintyHP:~> ping6 6lab-stats.com PING 6lab-stats.com(2001:420:81:101:0:c:15c0:4664) 56 data bytes ^C --- 6lab-stats.com ping statistics --- 10 packets transmitted, 0 received, 100% packet loss, time 9071ms
mpetach@mintyHP:~>
RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701 gem@rellim.com Tel:+1(541)382-8588
participants (15)
-
Andrew Sullivan -
Andrew Yourtchenko -
Don Bowman -
Fred Baker (fred) -
Gary E. Miller -
Ian Smith -
joel jaeggli -
Justin M. Streiner -
Lee Howard -
Matthew Petach -
Owen DeLong -
Paul WALL -
Tom Taylor -
Tony Hain -
Valdis.Kletnieks＠vt.edu