Subject: [BEHAVE] AAAA records on the Internet (::ffff: (IPv4-mapped), loopback)

From: "Dan Wing" <[email-masked]>
Date: Wed, 21 Oct 2009 09:40:24 -0700

During today's interim meeting I shared a summary of AAAA records on the
Internet with IPv4-mapped addresses (::ffff:).  

My test uses Alexa's list of top-1,000,000 websites (see top right of
http://www.alexa.com/topsites).  I examine the top 25,000 sites and eliminate
duplicates and IPv4 address literals resulting in 24959 hosts checked.  This
is run on a system with native IPv4 and native IPv6 connectivity and its own
BIND nameserver.  I ran the test again after the interim meeting to have fresh
data which shows of the 99 AAAA records advertised for the top 24,959 sites,
20 of them (approximately 20%) are using IPv4-mapped addresses.

             total hostnames checked:    24959
                        count with A:    24771  (99.247%)
                     count without A:      188  ( 0.753%)
                  count without AAAA:    24860  (99.603%)

                     count with AAAA:       99  ( 0.397%)
  count of AAAA, without IPv4-mapped:       77  (77.778%)
     count of AAAA, with IPv4-mapped:       20  (20.202%)
        count of AAAA, with loopback:        2  ( 2.020%)

  Testing connectivity to TCP/80 for IPv6 records of non-IPv4-mapped hosts:
                        hosts tested:       77
                  IPv6 connection ok:       67  (87.013%)
              IPv6 connection failed:       10  (12.987%)

Another address that DNS64 operators may want to treat similar to IPv4-mapped
(::ffff:) and ignore is the IPv6 loopback address (::1).  As shown in the
summary above, there are 2 occurrences in the 99 AAAA records, accounting for
2% of what would be failures for DNS64/NAT64 (or very confused users, if the
user is running an IPv6 webserver on their own host):

  # grep " ::1 " weekly.out-2009-10-21 
  top100.cn                      has IPv4  has IPv6  ::1 (ok)
  akilli.tv                      has IPv4  has IPv6  ::1 (ok)
  # host top100.cn
  top100.cn has address 59.151.24.134
  top100.cn has IPv6 address ::1
  top100.cn mail is handled by 10 mx.sina.net.
  # host akilli.tv                      
  akilli.tv has address 212.146.130.4
  akilli.tv has IPv6 address ::1
  akilli.tv mail is handled by 10 mail.akilli.tv.

(my result shows "(ok)" instead of "(failed)" for those hosts because there is
an IPv6 webserver running on the same host running the test.)

Many people are surprised with the high number of "count without A", which was
188 on this run.  I agree this is odd considering those very same FQDNs were
compiled by Alexa as being top sites the previous day.  I copied my raw data
to ftp://ftpeng.cisco.com/dwing/behave/weekly.out-2009-10-21 so that everyone
can do their own tests against it.  Almost all of the failures can be verified
to be legitimate failures by running:
  #grep "no IPv4" weekly.out-2009-10-21 | cut -d " " -f 1 | xargs -n 1 host
  Host www.bp.blogspot.com not found: 3(NXDOMAIN)
  Host www.rmxads.com not found: 3(NXDOMAIN)
  Host www.ggpht.com not found: 3(NXDOMAIN)
  Host www.webry.info not found: 3(NXDOMAIN)
  Host www.866-86.cn not found: 3(NXDOMAIN)
  Host www.images-amazon.com not found: 3(NXDOMAIN)
  Host www.ytimg.com not found: 3(NXDOMAIN)
  Host www.1e100.net not found: 3(NXDOMAIN)
  Host www.livefilestore.com not found: 3(NXDOMAIN)
  Host www.myspacecdn.com not found: 3(NXDOMAIN)
  Host www.tokyo.jp not found: 3(NXDOMAIN)
  Host www.edgesuite.net not found: 3(NXDOMAIN)
  Host www.uimserv.net not found: 3(NXDOMAIN)
  Host www.pgmediaserve.com not found: 3(NXDOMAIN)
  Host www.k12.ca.us not found: 3(NXDOMAIN)
  Host www.ucom.ne.jp not found: 3(NXDOMAIN)
  Host www.xii.jp not found: 3(NXDOMAIN)
  Host www.yahoofs.jp not found: 3(NXDOMAIN)
  Host www.wateen.net not found: 3(NXDOMAIN)
  Host www.ebayrtm.com not found: 3(NXDOMAIN)
  www.fastwebnet.it mail is handled by 10 mx3.fastwebnet.it.
  www.fastwebnet.it mail is handled by 10 mx4.fastwebnet.it.
  www.fastwebnet.it mail is handled by 10 mx1.fastwebnet.it.
  www.fastwebnet.it mail is handled by 10 mx2.fastwebnet.it.
  Host www.rj.gov.br not found: 3(NXDOMAIN)

  ... and so on ...

I find the results similar on three different hosts, all using different
nameservers.   Thus, I have attributed this anomaly to DNS hiccups.

Finally, the last part of the report shows the success/failure of connections
to the IPv6 address.  This is a simple connect() call; I do not try to
download a web page.  If we exclude the IPv4-mapped addresses (which don't
interest us, because DNS64 will essentially ignore them), there are still some
failures:

  # grep failed weekly.out | grep -v "::ffff"
  www.fudan.edu.cn               has IPv4  has IPv6
2001:da8:8001:2:21e:c9ff:feb5:eace (failed)
  exchangecash.de                has IPv4  has IPv6  ::1bcc:2f02:0:0:21cc:2f02
(failed)
  www.bayimg.com                 has IPv4  has IPv6  2a01:298:3:1:1337::13
(failed)
  sify.com                       has IPv4  has IPv6  2001:e48:0:10::10
(failed)
  tribune.com                    has IPv4  has IPv6  2002:a3c0:1712::a3c0:1712
(failed)
  die.net                        has IPv4  has IPv6  2607:f820:42::4 (failed)
  pcc.edu                        has IPv4  has IPv6  192:192:168:168:1:1:1:1
(failed)
  cbn.net.id                     has IPv4  has IPv6  2001:d10:2:80::80
(failed)
  www.bt-chat.com                has IPv4  has IPv6  2001:5c0:1500:b300::1:1
(failed)
  www.proua.com                  has IPv4  has IPv6  2a01:d0::10:1 (failed)

but all of those work fine with IPv4, as can be tested with:

  # grep failed weekly.out-2009-10-21 | grep -v "::ffff" | cut -d " " -f 1 |
xargs -n 1 wget --spider -4
  Spider mode enabled. Check if remote file exists.
  --2009-10-21 09:33:32--  http://www.fudan.edu.cn/
  Resolving www.fudan.edu.cn... 61.129.42.5
  Connecting to www.fudan.edu.cn|61.129.42.5|:80... connected.
  HTTP request sent, awaiting response... 200 OK
  Length: unspecified [text/html]
  Remote file exists and could contain further links,
  but recursion is disabled -- not retrieving.

  Spider mode enabled. Check if remote file exists.
  --2009-10-21 09:33:33--  http://exchangecash.de/
  Resolving exchangecash.de... 91.121.20.228
  Connecting to exchangecash.de|91.121.20.228|:80... connected.
  HTTP request sent, awaiting response... 302 Found
  Location: http://exchangecash.de/infoseite/index.html [following]
  Spider mode enabled. Check if remote file exists.
  --2009-10-21 09:33:33--  http://exchangecash.de/infoseite/index.html
  Connecting to exchangecash.de|91.121.20.228|:80... connected.
  HTTP request sent, awaiting response... 200 OK
  Length: 3202 (3.1K) [text/html]
  Remote file exists and could contain further links,
  but recursion is disabled -- not retrieving.

  ... and so on ...  

All of them worked fine for IPv4.

I expect this information provides sufficient justification for keeping text
in the DNS64 document encouraging implementors to allow the DNS64 operator to
treat certain AAAA responses as bogus.

-d