IPv4 versus IPv6 - Who connects faster?
Vaibhav Bajpai and Jürgen SchönwälderComputer Science, Jacobs University Bremen Germany
(v.bajpai | j.schoenwaelder)@jacobs-university.de
Abstract—We compare IPv4 and IPv6 connectivity of dual-stacked hosts using a metric that measures Transmission ControlProtocol (TCP) connection establishment time to 100 populardual-stacked websites. We have deployed an implementation ofthis metric on 20 SamKnows probes connected to dual-stackednetworks that are part of 18 different Autonomous Systems(AS). Using a year-long dataset gathered from these vantagepoints, we show how most of these websites centralise aroundContent Delivery Network (CDN) deployments and consequentlyshow similar performance. We show that these CDN clusters aredifferent for IPv4 and IPv6. Furthermore, some of these websitestend to be served by CDN caches deployed within service providernetworks. We show how these CDN caches are largely absent overIPv6. The distributions of TCP connect times show how clustersserving popular websites over IPv6 have improved over time. Wealso illustrate cases where network policies inhibit hosts fromconnecting to websites over IPv6.
I. INTRODUCTION
With the World IPv6 Launch day in 2012, several notableweb service providers started providing content services overIPv4 and IPv6. In two years since then, a number of large IPv6broadband roll-outs have happened1. For instance, Comcast,Deutsche Telekom AG and AT&T have demonstrated increasedpenetration of IPv6 in the fixed-line space, with Verizon Wire-less and T-Mobile USA showing similar trends in the cellularspace. In fact, Comcast recently2 completed transition of theirentire broadband network infrastructure to be 100% IPv6ready. These efforts have eventually led to an increased globaladoption of IPv6 to 5%, with Belgium (∼28.7%), Germany(∼11.9%) and USA (∼11.7%) leading the adoption rates asseen by Google’s IPv6 adoption statistics3 as of November2014. These numbers demonstrate that IPv6 adoption is finallyhappening. Jakub Czyz et al. in [1] (2014) provide a high-level view of the current state of IPv6 adoption. They studythe deployment from two lenses: a) prerequisite IP functions(addressing, naming, routing and end-to-end reachability), andb) operational characteristics (usage profile and performance).However, they measure IPv6 performance using an approxima-tion of 10− and 20−hop round-trip time (RTT)s over a sampleof dual-stacked nodes. In fact, they concede that a measureof actual client-to-service network performance would be amore ideal metric. In this study, we plug this gap by using ayear-long dataset to measure IPv6 performance of operationaldual-stacked websites from 20 dual-stacked vantage points.
A dual-stacked host with native IPv6 connectivity estab-lishing a TCP connection to a dual-stacked website will prefer
1http://www.worldipv6launch.org/measurements2http://goo.gl/9IKXZ13https://www.google.com/ intl/en/ ipv6/statistics.html
1) native IPv6 routes...2) native IPv4 routes...3) IPv4-IPv6 Transitioning routes
getaddrinfo(...) preference:
TCP connection request
Fig. 1. getaddrinfo(...) behavior as dictated by the default destinationaddress selection algorithm [2]. The algorithm makes applications iterate overendpoints in an order that prefers an IPv6-upgrade path.
IPv6. Fig. 1 shows how the function, getaddrinfo(...)adheres to the default address selection policy [2] by resolvinga service name to a list of endpoints in an order that prioritizesan IPv6-upgrade path. As a result, any application usinggetaddrinfo(...) to resolve service names will tend toprefer connections made over IPv6. We want to know whethercustomers with native IPv6 lines experience benefit (or anadded penalty) when connecting to websites over IPv6.
In order to achieve this, we introduce a metric that mea-sures TCP connection establishment times. We deploy animplementation of this metric on 20 SamKnows4 probes con-nected behind dual-stacked networks. We ran measurementsto a selectively chosen list of top 100 dual-stacked websitesfrom these vantage points and collected measurement data fora year. We show insights uncovered by analyzing this year-long dataset. We explore raw TCP connection establishmenttimes and uncover techniques to cluster websites around CDNdeployments. We show how these clusters are different for theIPv4 and the IPv6 network infrastructure. These clusters alsoreveal which websites are currently being served by contentcaches deployed inside the service provider network. We showhow these content caches are largely absent over IPv6. Thegathered trends have allowed us to identify special cases wherenetwork policies have resulted in inhibiting IPv6 for certainwebsites for some hosts. We describe these special cases.
Our measurement study provides four main contributions:
• An active metric (and a corresponding implementa-tion) to measure TCP connection establishment timesalongwith a list of top 100 dual-stacked websitesprocessed from Amazon 1M Alexa entries. We releasethese to the measurement community5.
• Identification of CDN deployments and content-cachesin service provider networks using Border GatewayProtocol (BGP)-based clusters processed from Internet
4http://www.samknows.com5happy.vaibhavbajpai.comISBN 978-3-901882-68-5 c© 2015 IFIP
Protocol (IP) endpoints seen from globally distributedSamKnows vantage points. A quantification of dispar-ity in IPv4 and IPv6 clusters is also made available.
• Distributions of TCP connection establishment timesover an year-long dataset to compare IPv4 and IPv6performance over each CDN cluster.
• A study of special cases such as www.bing.comglobally stopping IPv6 services in 2013, and GoogleCDN blacklisting resolvers that inhibit some hostsfrom receiving their services over IPv6.
The paper is organized as follows. In Section II we surveystudies measuring IPv6 performance. In Section III we intro-duce our measurement methodology, we describe our metricand related design choices, the measurement setup and currentdeployment. We capture our data analysis insights in SectionV and conclude in Section V.
II. RELATED WORK
Jakub Czyz et al. in [1] (2014) provide a survey of studiesmeasuring IPv6 adoption on the Internet. We therefore scopeour survey to studies measuring IPv6 performance.
Kenjiro Cho et al. in [3] (2004) passively monitor DomainName System (DNS) records for 3 months from within theWIDE research network to extract a destination list of ∼4Kdual-stacked nodes. They study IPv6 performance by compar-ing RTT and AS-level forward paths using a day-long datasetof ping and traceroute measurements collected from 3vantage points. They witnessed 16% unreachable destinations;while only a small proportion (among the rest) exhibited largerRTT over IPv6. Lorenzo Colitti et al. in [4] (2009) studyIPv6 performance by measuring latency using HTTP requeststo two experimental Google web service hostnames using asmall fraction of Google users. They show how performanceof native IPv6 (although small in 2009) is comparable to that ofIPv4, but transitioning technologies add considerable latency.They also show how operating systems (and browsers) bydefault tend to favor connections over IPv6. These studieshowever are dated. We therefore defer our methodology com-parison in favor of more recent studies discussed next.
Mehdi Nikkhah et al. in [5] (2011) study IPv6 performanceby measuring average download speeds (95% confidence in-terval within 10% of mean) towards dual-stacked webpageswithin Alexa top 1M websites (also used by us) from 6 vantagepoints (as opposed to 20 vantage points used by us). Theymeasure object size of the downloaded root page (withoutdownloading embedded objects) and filter out websites wherethese sizes are not within 6% (over IPv4 and IPv6) of eachother. They separate websites served by same (and different)origin AS over IPv4 and IPv6 and use AS paths (derivedfrom BGP route tables) to further separate them over same(and different) paths. We currently do not capture AS paths,but we do extend this technique by using origin AS tocluster websites by CDN deployments and CDN caches inservice provider networks. They [5] analyse performance bystudying controlled averages. We instead show distributionsof TCP connect times over an year-long dataset. AmoghDhamdhere et al. in [6] (2012) study the deployment of IPv6from three lenses: a) topology, b) routing dynamics and c)
happy1) endpoint 2) endpoint3) endpoint...n) endpoint
connection establishment times (µs)
1) service name2) port
Fig. 2. happy: A tool to measure TCP connection establishment times. Theinput parameter is a tuple (service name, port number) and the output is theconnection establishment time for each endpoint (measured in microseconds).The tool has been open-sourced and is available at: happy.vaibhavbajpai.com.
performance. The performance test extends on [5] in twoways: a) It downloads the smallest object (including embeddedobjects) that is atleast 10KB in size to overcome TCP slowstart and b) It measures AS paths using TCP traceroute(instead of BGP routing tables). They [6] measure the timeto fetch the page object towards a dual-stacked websites listgenerated from Alexa top 1M websites (also used by us). Theperformance measurements were conducted from 5 vantagepoints (as opposed to 20 vantage points used by us). Bothstudies [5], [6] show how IPv6 performance is comparable toIPv4 when forward AS-level paths are same, but much worsewhen they differ. They [6] reason how page fetch times (dueto small size of typical pages) are more dominated by delayrather than available bandwidth. This is why we measure TCPconnection establishment times since it allows us to capturethis end-to-end delay at the transport layer. Hussein A. Alzoubiet al. in [7] (2013) study the performance implications ofunilateral enabling of services over IPv6. They witnessed noperformance penalty in disabling the opt-in service. Googleused to impose such an opt-in policy to allow hosts to receiveGoogle services over IPv6. However, we show how Googlehas recently changed the policy.
III. METHODOLOGY
In this section, we describe our methodology. We introduceour metric and a corresponding implementation. We describeour rationale in selecting a list of dual-stacked websites and il-lustrate the overall measurement setup that utilizes SamKnowsprobes. We show the scope and lifetime of our measurementtrial by presenting the global vantage point distribution.
A. Metric, Implementation and Features
We have defined a metric that measures the time taken toestablish a TCP connection to a given endpoint. The inputparameter of the metric is a tuple (service name, port number)and the output is the TCP connection establishment time forall endpoints the service name resolves to, typically measuredin microseconds, as shown in Fig. 2.
The happy tool, is an implementation of our metric. Thetool can read one or more service names at once and applygetaddrinfo(...) to resolve their DNS entries to A andAAAA resource records. The list of service names can eitherbe supplied as command-line arguments or as a separatefile. It then uses non-blocking TCP connect(...) calls toconcurrently establish connections to all endpoints seen in the
DSL/Cable ModemSamKnows
Tests
Probe
ALEXA Dual-Stacked Top 100
resu
lts
HTTPS POST
TCP connect(...)IPv6!IPv4
happy
Data Collector
Fig. 3. A measurement setup on top of the SamKnows platform. A dual-stacked probe in addition to the standard SamKnows tests, executes a happytest. The happy test runs every hour and measures TCP connect times to100 dual-stacked websites both over IPv4 and IPv6. The locally collectedmeasurement results are pushed every hour to a data collector using HTTP.
resource records of each service name. It calculates the timeit takes for the TCP connect(...) call to complete as ameasure of the elapsed time. In order to allow delineating con-nection timeouts it also keeps a flag as an indication on whetherthe connection got established. This indication is made oncea socket in a select(...) call becomes writeable with nopending socket errors. We do not account the DNS resolutiontime in the measured connection establishment time. This isdone to avoid slow resolvers from biasing our connection es-tablishment time results. The tool enforces a small delay (25msby default) between concurrent TCP connect(...) calls toavoid generating bursty TCP SYN traffic. This delay, however,does not come in the way of pending TCP connect(...)calls. As such the measured times are not skewed by thisfeature. We also added the capability to lock the output streamto allow multiple processes to coordinate writes to the sameoutput stream. This is useful when multiple happy instancestry to append results to a single regular file from a resource-constrained device.
B. Selection of Websites
We wanted to measure a representative list of populardual-stacked websites. A large list will allow us to capturethe perspective of dual-stacked hosts that frequently visitpopular regional websites. The top websites within that listwhen combined with a widely distributed vantage point willadditionally allow us to also capture the perspective of dual-stack hosts from a global standpoint.
We investigated sources that can reveal this information.For instance, Alexa ranks and maintains listings of the mostpopular websites on the Internet. The public REST API,however, provides the capability to retrieve only the top 100website names. This is not enough, since only a fractionof these top 100 website names are dual-stacked today.Hurricane Electric (HE), a major IPv6 tunnel-broker basedin the US, maintains a list of top 100 dual-stacked websitenames6. The backend uses the top 1M website names list madeavailable by Amazon. However, we noticed that some of the
6http://bgp.he.net/ ipv6-progress-report.cgi
popular websites (e.g. Wikipedia) are missing from this listeven though they are dual-stacked. It appears some websitesprovide AAAA records only for domain names starting with www.For example, www.bing.com does have a AAAA record whilebing.com does not (In this particular case, a request to fetchthe latter leads to a redirect to the former). Since, HE does notfollow CNAMEs, they miss some dual-stacked websites in theirtop dual-stacked website list calculation.
We decided to use Amazon’s top 1M website names list7used by HE as input to prepare a top 100 dual-stacked websitenames list using our own custom script. Our script prependseach website name with the label www to make an additionalDNS request and it also explicitly follows CNAMEs. This way,we do not miss any of the popular dual-stacked websiteslike wikipedia.org. It is also important to note that weonly measure websites in this work. As such the connectionestablishment times and their comparison over IPv4 and IPv6reflect the performance as seen over TCP port 80.
C. Measurement Setup
We cross-compiled happy for the OpenWrt platform anddeployed it on SamKnows probes. These probes, in additionto the happy test, also perform standard SamKnows IPv4measurements. The test is executed on the top 100 dual-stacked websites list and the measurement runs every hour.Due to the inherent storage limitation of the probes, the locallycollected measurement results are pushed every hour to ourdata collector using a REST based architectural style on topof HTTP as shown in Fig. 3.
7http:// s3.amazonaws.com/alexa-static/ top-1m.csv.zip
IPv6 Trial
Location CountryNancy France
Bucharest Romania
Meyrin Switzerland
Toronto Canada
Niigata Japan
Fukuoka Japan
Probe shipped, pending to come online ... Probes pending to be shipped ...
Location CountrySolna Sweden
Southampton UK
Alleur Belgium
Madrid Spain
Shizuoka Japan
TYPE IPv4 AS IPv6 AS LOCATION PROVIDER PROBE ID
RESIDENTIAL AS31334 AS31334 BREMEN KABELDEUTSCHLAND #02RESIDENTIAL AS3320 AS3320 BREMEN DEUTSCHE TELEKOM #04RESIDENTIAL AS50989 AS1257 STOCKHOLM SITAB #11RESIDENTIAL AS4685 AS4718 FUKUOKA ASAHI NET #12RESIDENTIAL AS12715 AS12715 MADRID JAZZ TELECOM #13RESIDENTIAL AS9031 AS9031 ALLEUR EDPNET #17RESIDENTIAL AS3320 AS3320 BREMEN DEUTSCHE TELEKOM #19RESIDENTIAL AS2518 AS2516 SHIZUOKA BIGLOBE NEC #20
RESEARCH AS513 AS513 CERN CERN #16NREN AS680 AS680 BREMEN DFN #01NREN AS2614 AS2614 TIMISOARA ROEDUNET #08NREN AS2611 AS2611 LOUVAIN BELNET #15NREN AS680 AS680 BREMEN DFN #18
LAB AS5607 AS5607 LONDON BSKYB-BROADBAND #05LAB AS3269 AS3269 TORINO TELECOM ITALIA #06LAB AS8903 AS8903 MADRID BT ESPANA #07LAB AS2856 AS5400 IPSWICH BT UK #10
IXP AS18070 AS18070 NIIGATA NDAC #14
BUSINESS AS24956 AS24956 BRAUNSCHWEIG GAERTNER DATENSYSTEME #03BUSINESS AS13030 AS13030 OLTEN INIT SEVEN #09
Fig. 4. Deployment status of our measurement trial as of July 2014. Eachvantage point is a SamKnows probe which is part of a larger SamKnowsmeasurement platform. Most of these probes are deployed behind residentialnetworks and receive native IPv6 connectivity from their service provider. Apart of these probes are also connected within NREN.
101
102
103SamKnows Probe: #04 [04-May-2013 CET to 23-May-2014 CET]
IPv4biglobe.ne.jp
www.aol.com
www.appspot.com
www.att.com
www.bing.com
www.blogger.com
www.blogspot.co.uk
www.blogspot.com
www.blogspot.de
www.blogspot.in
www.blogspot.jp
www.blogspot.ru
www.comcast.net
www.detik.com
www.doubleclick.com
www.elmundo.es
www.engadget.com
www.facebook.com
www.fbcdn.net
www.flipkart.com
www.folha.uol.com.br
www.free.fr
www.google.ae
www.google.at
www.google.az
www.google.be
www.google.ca
www.google.ch
www.google.cl
www.google.cn
www.google.co.hu
www.google.co.id
www.google.co.il
www.google.co.in
www.google.co.jp
www.google.co.kr
www.google.co.th
www.google.co.uk
www.google.co.ve
www.google.co.za
www.google.com
www.google.com.ar
www.google.com.au
www.google.com.bd
www.google.com.br
www.google.com.co
www.google.com.eg
www.google.com.hk
www.google.com.mx
www.google.com.my
www.google.com.ng
www.google.com.pe
www.google.com.ph
www.google.com.pk
www.google.com.sa
www.google.com.sg
www.google.com.tr
www.google.com.tw
www.google.com.ua
www.google.com.vn
www.google.cz
www.google.de
www.google.dk
www.google.dz
www.google.es
www.google.fi
www.google.fr
www.google.gr
www.google.ie
www.google.it
www.google.nl
www.google.no
www.google.pl
www.google.pt
www.google.ro
www.google.ru
www.google.se
www.google.sk
www.googleusercontent.com
www.irs.gov
www.marca.com
www.mobile.de
www.mozilla.org
www.netflix.com
www.nifty.com
www.orange.fr
www.sakura.ne.jp
www.seznam.cz
www.t-online.de
www.terra.com.br
www.uol.com.br
www.usps.com
www.vk.com
www.wikimedia.org
www.wikipedia.org
www.wiktionary.org
www.yahoo.com
www.youm7.com
www.youtube.com
101
102
103
TCP
conn
ect
time
(ms
ecs)
IPv6
Fig. 5. Box plots showing distributions (in log-scale) of TCP connection establishment times to 100 dual-stacked websites. The SamKnows probe is connectedat a premium Deutsche Telekom customer. It has native IPv4 and IPv6 connectivity via DTAG - Deutsche Telekom AG [AS3320].
Sprint com206.159.101.0/24
Sprint206.159.0.0/16
Internet Assigned Numbers Authority/0
Akamai Technologies2.18.160.0/20
www.google.com.br
Google Inc.74.125.0.0/16
Google Inc.173.194.0.0/16
Akamai Technologies, Inc.23.60.0.0/14
www.google.bg
www.bing.com
Akamai Technologies, Inc.23.32.0.0/11
Akamai International B.V.80.239.230.128/25
Akamai Technologies95.100.249.0/24
www.google.bewww.blogspot.kr
Cluster network5.199.166.0/23
AI PI AKT OOD195.85.215.0/24
www.google.it
America Online64.12.0.0/16
AOL Inc195.93.64.0/18
www.mapquest.com
Netscape Communications Corp.207.200.64.0/18
www.balagana.net
www.google.co.il
CLIENT338546.19.137.80/29
www.google.co.ma
www.comcast.net
Akamai Technologies84.53.172.0/22
Akamai Technologies195.95.192.0/23
www.google.co.id
www.google.fr
www.google.com.sa
www.google.com.sg
www.google.co.in
America Online, Inc205.188.0.0/16
www.google.nl Latin American and Caribbean IP address Regional Registry190.0.0.0/8
www.google.fi
www.google.se
www.mozilla.org
Mozilla Corporation63.245.208.0/20
www.google.sk
www.google.co.uk
www.google.com
www.google.com.bd
www.google.ca
www.rtl.de
RTL-D Video portal217.118.169.0/24
www.bitsnoop.com
www.google.ch
www.google.cl
www.google.cn
RIPE Network Coordination Centre141.0.0.0/8
www.google.lk
www.blogspot.fr
www.google.cz
Virtual Private Servers for Customers89.187.142.0/23
www.facebook.com
Facebook, Inc.66.220.144.0/20
Facebook, Inc.173.252.64.0/18
www.networkedblogs.com
www.google.co.kr
DUB8 EC2176.34.184.0/21
EdgeCast Networks, Inc.68.232.32.0/20
www.google.com.au
www.youtube.com
www.googleusercontent.com
SoftLayer Technologies Inc.66.228.118.0/24
www.google.pt
www.google.gr
www.google.com.mx
www.google.kz
www.blogspot.com.es
www.google.pl
www.google.com.vn
www.blogspot.in
www.google.tn
www.gravatar.com
www.google.co.jp
www.google.de
www.google.co.nz
www.google.com.ec
www.blogspot.com www.google.com.eg
www.irs.gov
www.google.dk
www.google.lt
Azar-A Kft.91.219.236.0/22
VNET a.s.109.74.148.0/22
www.orkut.com
www.google.hr
www.blogger.com
Flipkart India Pvt Ltd103.4.252.0/22
www.google.com.hk
YIFY Torrents Solutions37.221.165.32/28
www.google.com.ua
www.google.com.ly
www.aol.com
www.softlayer.com
www.netflix.com
www.flipkart.com
www.yify-torrents.com
www.google.bywww.youm7.com
www.google.co.ve
www.google.com.do
www.android.com
www.google.ae
www.google.az
www.anitube.jp
Hosting Services, Inc.174.127.64.0/18
www.autoblog.com
www.google.co.za
www.blogspot.jp
www.goo.gl
www.google.at
www.google.com.tr
www.google.dz
www.att.com
www.google.iq
www.google.com.pk
www.google.com.ph
www.google.co.th
www.google.ru
www.google.com.pe
www.google.ro
Sprint65.172.0.0/14
Sprint com65.172.0.0/15
www.google.com.co
www.google.co.hu
www.google.ie
www.google.no
www.sprint.com
www.blogspot.co.uk
www.brainyquote.com
www.google.es
www.google.com.br
Google Ireland Limited2a00:1450::/29
www.flipkart.com
Flipkart India Pvt Ltd2001:df0:23e::/48
www.google.com.sg
www.google.com.sa
Internet Assigned Numbers Authority/0
www.goo.gl
Akamai Technologies2a02:26f0::/32
www.google.by
www.google.co.za
www.google.be
www.google.sk
www.google.bg
www.google.com.bd
www.google.ae
Mozilla Corporation2620:101:8000::/40
www.google.se
Facebook Ireland Ltd2a03:2880::/32
www.youtube.com
www.aol.com
America Online2001:4b0::/32
www.google.fi
SoftLayer Technologies Inc.2607:f0d0::/32
www.att.com
www.orkut.com
www.google.co.id
Magyar Telekom plc.2001:4c48::/29
www.google.co.in
www.google.co.il
www.balagana.net
www.google.co.ma
www.google.dz
www.blogspot.jp
www.google.frwww.google.nlwww.google.no
www.google.co.vewww.google.com.ly
www.google.com.mx
VNET s. r. o.2a01:390::/32
BUL.NET2a01:9e40:195::/48
www.google.ch
www.blogspot.co.uk
www.google.cn
www.youm7.com
665 Third Street2400:cb00::/32
www.google.com.vn
www.mapquest.com
www.google.ca
www.blogspot.com.es
www.blogger.com
www.rtl.de
RTL Interactive Frankfurt2a03:d680::/48
www.google.co.nz
www.bitsnoop.com
2a02:29b8:1925::/64
www.blogspot.in
www.softlayer.com
www.google.ro
www.yify-torrents.com
COOLHOUSING s.r.o.2a01:5f0::/32
www.google.co.jp
www.google.ru
www.comcast.net
Akamai Technologies2a02:26f0:5::/48
www.facebook.com
www.google.cl
www.google.kz
www.google.gr
www.blogspot.com
www.google.cz
www.google.com.hk
www.google.com.ua
www.google.de
www.google.dk
www.google.com.ec
www.android.com
www.google.com.eg
www.google.co.th
EdgeCast Networks, Inc.2606:2800::/32
www.google.co.kr
www.google.lk
www.google.tn
www.google.hr
www.bing.com
www.google.co.uk
www.google.com.au
www.netflix.com
Amazon Data Services Ireland LTD2a01:578::/32
www.google.lt
www.blogspot.kr
www.google.com.tr
www.google.es
2607:f0d0:3001:ae::/64www.google.az
www.gravatar.com
www.google.at
www.sprint.com
Sprint2600::/29
www.google.com.ph
www.blogspot.fr
www.google.com.pk
www.networkedblogs.com
www.google.com.pe
www.google.com.co
www.mozilla.org
www.irs.gov
www.google.ie
www.google.pl
www.autoblog.com
www.google.com
www.anitube.jp
www.google.com.do
www.google.it
www.google.co.hu
www.googleusercontent.com
www.google.iq
www.brainyquote.com
www.google.pt
Fig. 6. An IPv4 (left) and IPv6 (right) WHOIS-based aggregation of websites as seen by this (above) probe depicts how most of the websites centralize oncore CDNs and major cloud platforms. (The plots are vector graphics and hence zoomable.)
D. Measurement Trials
We wanted to measure from different locations of the Inter-net and wanted to ensure that access to certain websites is notblocked administratively. As such, we strategically deployedSamKnows probes to cover a diverse range of origin-ASes.Fig. 4 shows the current deployment status of the SamKnowsprobes that are part of our measurement trial. An associatedtable shows the origin AS (both over IPv4 and IPv6) of eachvantage point along with its geographic location. Most of theseprobes are deployed behind residential networks and receivenative IPv6 connectivity. Some probes are also deployed inNational Research and Education Network (NREN). We have
been collecting this data since March 10, 2013. This hasallowed us to collect time series of TCP connect times that maybe representative enough to provide us with insights on howIPv6 connectivity to websites compares to IPv4 connectivity.
IV. DATA ANALYSIS INSIGHTS
We performed a pre-processing run on the dataset to reducethe volume of raw measurements. In this work, we do notlook at TCP connection failure rates. As such we pruned outentries where the test reported a TCP connection timeout event.We also removed entries where the test failed in situationswhere it ran out of socket descriptors (a rare but plausible
IAN
A
APN
IC
SA
KU
RA
(A
S9
37
1)
ww
w.s
aku
ra.n
e.jp
BIG
LOB
E (
AS2518)
big
lobe.n
e.jp
DETIK
(A
S24211)
ww
w.d
eti
k.co
m
NETM
AG
IC (
AS17439)
ww
w.fl
ipka
rt.c
om
FKN
ET (
AS9
752
)
ww
w.fl
ipka
rt.c
om
INFO
WEB
(AS2
510)
ww
w.n
ifty.
com
ARIN
AOL
(AS1
668)
ww
w.a
ol.c
om
TERR
A (A
S402
60)
www.te
rra.
com
.br
MIC
ROSOFT
(AS8
075)
www.bin
g.co
m
YAHOO (A
S26101)
www.yahoo.c
om
MOZILLA (A
S36856)
www.mozil
la.org
DTAG (AS3320)
www.usps.com
AMAZON (AS14618)www.netflix.com
GO
OG
LE (AS15169)
www.google.com.my
www.googleusercontent.com
www.google.dz
www.google.co.hu
www.google.com
www.google.co.kr
www.google.es
www.blogspot.com
www.youtube.comwww.google.itwww.google.grwww.google.com.phwww.google.com.pkwww.google.com.vn
www.google.com.trwww.blogspot.de
www.google.iewww.google.co.il
www.google.at
www.google.pt
www.google.pl
www.google.co.ve
www.blogspot.ru
www.google.com.co
www.google.com.ar
www.google.com.ua
www.google.nl
www.google.ca
ww
w.google.sk
ww
w.google.com
.mx
ww
w.google.az
ww
w.blogspot.in
ww
w.blogspot.jp
ww
w.google.com
.ng
ww
w.g
oogle.com
.sg
ww
w.g
oogle.co.th
ww
w.g
oogle
.de
ww
w.g
oogle
.co.jp
ww
w.g
oogle
.com
.tw
ww
w.g
oogle
.co.id
ww
w.g
oogle
.com
.eg
ww
w.a
ppsp
ot.co
m
ww
w.g
oogle
.com
.br
ww
w.g
oog
le.n
o
ww
w.g
oogle
.be
ww
w.g
oogle
.se
ww
w.g
oogle
.cl
ww
w.b
logger.co
m
ww
w.g
oogle
.co.
za
ww
w.g
oogle
.ch
ww
w.g
oogle
.co.
in
ww
w.g
oogle
.fr
ww
w.d
ouble
clic
k.co
m
ww
w.g
oogl
e.cn
ww
w.g
oogl
e.co
m.h
k
ww
w.g
oogl
e.co
m.s
a
ww
w.g
oogl
e.co
m.p
e
ww
w.b
logs
pot.c
o.uk
ww
w.go
ogle
.com
.au
www.
goog
le.ro
www.g
oogl
e.cz
www.goo
gle.
co.u
k
www.goo
gle.
ae
www.goo
gle.co
m.b
d
www.google.ru
www.google.dk
www.google.fi
N/A
CHINA169 (AS4808)
www.qq.com
CHINA169 (AS4837)
www.qq.com
AOL (AS1668)
www.aol.com
LACNIC
Universo (AS7162)
www.uol.com.brwww.folha.uol.com.br
CLOUDFLARENET (AS13335)www.youm7.com
RIPE
Unidad (AS9052)www.elmundo.es
www.marca.com
YAHOO (AS34010)
www.yahoo.com
DTAG (AS3320)
www.google.dz
www.att.com
www.comcast.net
www.irs.gov
www.google.nl
www.t-online.de
WIKIMEDIA (AS43821)
www.wiktionary.org
www.wikimedia.org
www.wikipedia.org PROXAD (AS12322)
www.free.fr
Orange (AS8891)
www.orange.fr
VKONTAKTE (AS47541)
ww
w.vk.com
WAN
AD
OO
PORTA
ILS (AS24600)
ww
w.orange.fr
CLO
UD
FLAREN
ET (AS13335)
ww
w.youm
7.com
SEZ
NA
M (A
S43037)
ww
w.sezn
am.cz
AO
L (AS1668)
ww
w.e
ngadget.co
m
FAC
EB
OO
K (A
S32934)
ww
w.fb
cdn.n
et
ww
w.fa
cebook.co
m MA
RKT
PLA
ATS (A
S4
15
52
)w
ww
.mobile
.de
file:///home/steffie/Documents/happy/bgp-based-cl...
1 of 1 07/24/2014 01:30 PM
IAN
A
APN
IC
BIG
LOB
E (
AS2
51
8)
big
lobe.n
e.jp
FKN
ET (
AS9752)
ww
w.fl
ipka
rt.c
om
INFO
WEB
(A
S2510)
ww
w.n
ifty
.com
AM
AZ
ON
(A
S16509)
ww
w.n
etflix
.com
ARIN
AOL
(AS1
668)
ww
w.a
ol.c
om
WIK
IMED
IA (A
S438
21)
ww
w.w
iktio
nary
.org
ww
w.w
ikim
edia
.org
www.
wik
iped
ia.o
rg
MOZIL
LA (A
S368
56)
www.moz
illa.o
rg
TERRA (AS40260)
www.terra
.com
.br
YAHOO (A
S10310)
www.yahoo.com
GOOGLE (AS15169)
www.google.ch
www.google.at
www.google.nl
RIP
E
Unidad (AS9052)
www.elmundo.es
www.marca.com
NTT (AS2914)
www.usps.com
www.att.com
DTAG (AS3320) www.t-online.de
PROXAD (AS12322) www.free.frOrange (AS8891)www.orange.fr
VKONTAKTE (AS47541) www.vk.com
GO
OG
LE (AS1
5169
)
www.google.com.my
www.googleusercontent.com
www.google.dz
www.google.co.hu
www.google.com
www.google.co.kr
www.google.es
www.blogspot.com
www.youtube.com
www.google.it
ww
w.google.gr
ww
w.google.com
.ph
ww
w.google.com
.pk
ww
w.google.com
.vn
ww
w.google.com
.tr
ww
w.blogspot.de
ww
w.g
oogle.ie
ww
w.g
oogle
.co.il
ww
w.g
oogle
.at
ww
w.g
oogle
.pt
ww
w.g
oogle
.pl
ww
w.g
oogle
.co.v
e
ww
w.b
logsp
ot.ru
ww
w.g
oogle
.com
.coww
w.g
oogle
.com
.ar
ww
w.g
oogle
.com
.ua
ww
w.g
oogle
.nl
ww
w.g
oogle
.ca
ww
w.g
oogle
.sk
ww
w.g
oogle
.com
.mx
ww
w.g
oogle
.az
ww
w.b
logsp
ot.in
ww
w.b
logs
pot.
jp
ww
w.g
oogl
e.co
m.n
g
ww
w.g
oogl
e.co
m.s
g
ww
w.g
oogl
e.co
.th
ww
w.g
oogl
e.de
ww
w.go
ogle
.co.
jp
www.
goog
le.c
om.tw
www.g
oogl
e.co
.id
www.goo
gle.
com
.eg
www.appsp
ot.co
m
www.google.co
m.b
r
www.google.no
www.google.be
www.google.sewww.google.cl
www.blogger.comwww.google.co.zawww.google.chwww.google.co.inwww.google.frwww.doubleclick.com
www.google.cnwww.google.com.hk
www.google.com.sa
www.google.com.pe
www.blogspot.co.uk
www.google.com.au
www.google.ro
www.google.cz
www.google.co.uk
www.google.ae
www.google.com.bd
www.google.ru
www.google.dk
www.google.fi CW (AS1273)
www.usps.com
www.att.com
WANADOOPORTAILS (AS24600)
www.orange.fr
FACEBOOK (AS32934)
www.fbcdn.net
ww
w.facebook.com
AKA
MAI (A
S20940)
ww
w.irs.gov
ww
w.com
cast.net
SEZN
AM
(AS43
037)
ww
w.seznam
.cz
YAH
OO
(AS10310)
ww
w.ya
hoo.com M
AR
KTPLA
ATS (A
S41552)
ww
w.m
obile
.de
LAC
NIC
Univ
erso
(AS7
16
2)
ww
w.u
ol.co
m.b
rw
ww
.folh
a.u
ol.co
m.b
r
file:///home/steffie/Documents/happy/bgp-based-cl...
1 of 1 07/24/2014 01:30 PM
Fig. 7. An IPv4 (left) and IPv6 (right) BGP-based aggregation of websites as seen by one vantage point. The endpoints are aggregated to the announcedBGP prefixes as seen by RIPE RIS route collectors. The leaves represent individual websites. The level-2 nodes represent the AS announcing the BGP prefixand its holder name. Finally, the level-1 nodes represent the RIR that allocated the address block to the AS. The SamKnows probe is connected at a premiumDeutsche Telekom customer. It has native IPv4 and IPv6 connectivity via DTAG [AS3320].
occurance). We investigated time scales where the variation inTCP connection establishment times is small enough to allowstatistically meaningful aggregation. Since applications usuallyhonor the order of endpoints returned by getaddrinfo(...)when establishing a TCP connection, we decided to pickthe first endpoints returned in each measurement over a dayfor both address families, and aggregated their TCP connecttimes centered around the median. The calculated InterquartileRange (IQR) ranges around the median are low. As such,each data point in subsequent analysis refers to the median ofTCP connection establishment times seen by IPv4 and IPv6endpoints over a day.
A. Measuring Raw TCP Connect Times
Fig. 5 shows box plots of raw TCP connection estab-lishment times to 100 dual-stacked websites from one ofthe SamKnows probes over the entire year-long duration.This probe is connected behind a residential network inBremen. The host is subscribed to a premium triple-playservice from Deutsche Telekom and as a result receives nativeIPv4 and IPv6 connectivity at home. It can be seen howseveral websites appear to show similar performance overIPv4 and IPv6. However, there are also websites such aswww.facebook.com, www.fbcdn.net (served by FacebookCDN) and www.youm7.com (served by Cloudflare CDN)where the the probe reports substantially higher variance overIPv6. In fact observing the time-series of TCP connectionestablishment times for www.facebook.com for this probeshow how TCP connection establishment times have tangiblyimproved over time as shown in Fig. 8. Additionally websiteslike www.att.com, comcast.net and www.irs.gov appearsignificantly faster over IPv4 than IPv6. This is discussed inthe following sections.
B. Website Clusters
1) WHOIS-based: It can be seen from Fig. 5 that severalrelated websites, such as www.google.* within each addressfamily show very similar behavior. In fact, the median TCPconnection establishment times and the IQR values of manydisparate websites within the same address family are alsocomparable. For instance, www.att.com (a DSL networkprovider), www.comcast.com (a cable network provider), andwww.irs.gov (the US tax collection agency) show verysimilar performance. One possible explanation is that thesewebsites are provided via common CDNs. Looking at thecollected IP endpoints, we found that these websites eitherresolve to the same endpoint or a set of endpoints that belongto the same allocated address block. Digging through theWHOIS information for each of the endpoints (obtained viaprogrammatic APIs from the RIRs) seems to indicate that
04-M
ay-2
013
CET
30-Ju
n-20
13 C
ET
24-N
ov-2
013
CET
20-F
eb-2
014
CET
18-A
pr-2
014
CET0
50
100
150
200
250
TC
P c
onnect
tim
e (
mse
cs)
SamKnows Probe: #04 to www.facebook.com
IPv6
IPv4
04-M
ay-2
013
CET
30-Ju
n-20
13 C
ET
24-N
ov-2
013
CET
20-F
eb-2
014
CET
18-A
pr-2
014
CET0
50
100
150
200
250
TC
P c
onnect
tim
e o
ver
IPv6
(m
secs
)
27.5
28.0
28.5
29.0
29.5
30.0
30.5
31.0
31.5
32.0
TC
P c
onnect
tim
e o
ver
IPv4
(m
secs
)
SamKnows Probe: #04 to www.facebook.com
IPv6
IPv4
Fig. 8. Time-series to www.facebook.com from SamKnows Probe #04 fromMay 2013 to April 2014. It can be seen how this probe witnessed significantlyimproved TCP connect times over IPv6 since November 2013. The rightplot (in two separate scales) shows how TCP connect times over IPv4 alsoimproved at the same tme, but on a much smaller scale.
0.0 0.2 0.4 0.6 0.8 1.0
Number of Services
0.0
0.2
0.4
0.6
0.8
1.0
CDF of Services within each IPv4 BGP-based Cluster
GOOGLE (AS15169)
SEABONE (AS6762)
NTT (AS2914)
JAZZNET (AS12715)
AKAMAI (AS20940)
WIKIMEDIA (AS43821)
COMHEM (AS39651)
WIKIMEDIA (AS14907)
ECHIGO (AS55895)
AOL (AS1668)
UNIDAD (AS9052)
TINET (AS3257)
EDPNET (AS9031)
TELIANET (AS1299)
UNIVERSO (AS7162)
AKAMAI (AS16625)
FACEBOOK (AS32934)
0 1 2 3 4 5 60.0
0.2
0.4
0.6
0.8
1.0
% o
f N
um
ber
of
Sam
Know
s Pro
bes:
20
60 62 64 66 68 70
IPv4 Cluster #(↓)
GOOGLE (AS15169) 67SEABONE (AS6762) 05NTT (AS2914) 03JAZZNET (AS12715) 03AKAMAI (AS20940) 03WIKIMEDIA (AS43821) 03COMHEM (AS39651) 03WIKIMEDIA (AS14907) 03ECHIGO (AS55895) 02AOL (AS1668) 02UNIDAD (AS9052) 02TINET (AS3257) 02EDPNET (AS9031) 02TELIANET (AS1299) 02UNIVERSO (AS7162) 02AKAMAI (AS16625) 02FACEBOOK (AS32934) 02
0.0 0.2 0.4 0.6 0.8 1.0
Number of Services
0.0
0.2
0.4
0.6
0.8
1.0
CDF of Services within each IPv6 BGP-based Cluster
GOOGLE (AS15169)
AKAMAI (AS20940)
WIKIMEDIA (AS43821)
CW (AS1273)
WIKIMEDIA (AS14907)
UNIDAD (AS9052)
TINET (AS3257)
ECHIGO (AS55895)
DFN (AS680)
ACONET (AS1853)
UNIVERSO (AS7162)
NTT (AS2914)
FBDC (AS10013)
FACEBOOK (AS32934)
0 1 2 3 4 5 60.0
0.2
0.4
0.6
0.8
1.0
% o
f N
um
ber
of
Sam
Know
s Pro
bes:
20
60 62 64 66 68 70
IPv6 Cluster #(↓)
GOOGLE (AS15169) 67AKAMAI (AS20940) 04WIKIMEDIA (AS43821) 03CW (AS1273) 03WIKIMEDIA (AS14907) 03UNIDAD (AS9052) 02TINET (AS3257) 02ECHIGO (AS55895) 02DFN (AS680) 02ACONET (AS1853) 02UNIVERSO (AS7162) 02NTT (AS2914) 02FBDC (AS10013) 02FACEBOOK (AS32934) 02
Fig. 9. CDF showing the distribution of number of services within eachcluster as seen by all probes. A complementary table shows the number ofservices within each cluster (across all probes) centered around the median.
major portions of the websites map to address blocks owned byorganizations such as Google and Akamai as shown in Fig. 6.
2) BGP-based: The WHOIS-based aggregated clusters arecoarse-grained. This is due to the fact that a Local InternetRegistry (LIR) can decide to split an allocated address blockinto multiple smaller chunks. The LIR can then decide toannounce these smaller chunks from different ASes. Therefore,we decided to map the collected IP endpoints to announcedBGP prefixes as seen by RIPE RIS8 route collectors. Wecapture the AS, its holder name, and the RIR that allocated theaddress block for each announced BGP prefix as an additionalmetadata in our dataset. Fig. 7 for instance, shows an equiva-lent BGP-based cluster of websites as seen from the vantagepoint of this SamKnows probe. It can be seen how afore-mentioned websites like www.att.com, www.comcast.netand www.irs.gov get clustered behind Deutsche TelekomAG (DTAG) for IPv4, but are dissassociated behind separateclusters for IPv6. These websites are being served over IPv4by Akamai content caches deployed directly within the DTAGservice provider network. However, these caches appear to bemissing over IPv6. This correlates with the relative differencebetween TCP connection establishment times seen over IPv4and IPv6 for these websites. The BGP-based clusters shownin Fig. 7 are specific to this vantage point. Fig. 9 shows thedistribution of number of websites as seen across all probes,both over IPv4 and IPv6. The variation most likely is due
8http://www.ripe.net/ ris
to some of the websites getting pushed into service providernetworks as content caches. An associated table lists all theclusters in descending order of aggregated number of websitescentered around the median. Going forward we use theseclusters to perform the rest of the analysis.
C. Distribution of TCP Connect Times
In our pursuit to cover all vantage points, we narroweddown the list to clusters that were seen in both address familiesand by all probes. The resultant clusters: Google, Akamai,Facebook and Wikimedia are used in the analysis goingforward. Fig. 10 and Fig. 11 show the distribution of TCPconnection establishment times as seen by each probe. Fig. 12on the other hand shows box plots of observed TCP connectionestablishment times for each probe and a CDF as seen by allprobes combined. It can be seen how probes deployed in Japan(#12, #14, and #20) do not appear in Wikipedia-EU CDNmeasurements, but in fact measure against Wikipedia CDN(not shown). It can also be seen how probes connected behind
0.0 0.2 0.4 0.6 0.8 1.0
TCP connect time (msecs)
0.0
0.2
0.4
0.6
0.8
1.0SamKnows Probe: #05
GOOGLE (IPv6)
AKAMAI-ASN1 (IPv6)
FACEBOOK (IPv6)
WIKIMEDIA-EU (IPv6)
GOOGLE (IPv4)
AKAMAI-ASN1 (IPv4)
FACEBOOK (IPv4)
WIKIMEDIA-EU (IPv4)
100 101 102 1030.0
0.2
0.4
0.6
0.8
1.0
CD
F
10-1 100 101 102 103
0.0 0.2 0.4 0.6 0.8 1.0
TCP connect time (msecs)
0.0
0.2
0.4
0.6
0.8
1.0SamKnows Probe: #06
GOOGLE (IPv6)
FACEBOOK (IPv6)
WIKIMEDIA-EU (IPv6)
GOOGLE (IPv4)
FACEBOOK (IPv4)
WIKIMEDIA-EU (IPv4)
101 102 1030.0
0.2
0.4
0.6
0.8
1.0
CD
F
101 102 103
0.0 0.2 0.4 0.6 0.8 1.0
TCP connect time (msecs)
0.0
0.2
0.4
0.6
0.8
1.0SamKnows Probe: #07
GOOGLE (IPv6)
AKAMAI-ASN1 (IPv6)
FACEBOOK (IPv6)
WIKIMEDIA-EU (IPv6)
GOOGLE (IPv4)
AKAMAI-ASN1 (IPv4)
FACEBOOK (IPv4)
WIKIMEDIA-EU (IPv4)
100 101 102 103 1040.0
0.2
0.4
0.6
0.8
1.0
CD
F
100 101 102 103 0.0 0.2 0.4 0.6 0.8 1.0
TCP connect time (msecs)
0.0
0.2
0.4
0.6
0.8
1.0SamKnows Probe: #10
GOOGLE (IPv6)
AKAMAI-ASN1 (IPv6)
FACEBOOK (IPv6)
WIKIMEDIA-EU (IPv6)
GOOGLE (IPv4)
AKAMAI-ASN1 (IPv4)
FACEBOOK (IPv4)
WIKIMEDIA-EU (IPv4)
101 102 1030.0
0.2
0.4
0.6
0.8
1.0
CD
F
101 102 103
0.0 0.2 0.4 0.6 0.8 1.0
TCP connect time (msecs)
0.0
0.2
0.4
0.6
0.8
1.0SamKnows Probe: #03
GOOGLE (IPv6)
AKAMAI-ASN1 (IPv6)
FACEBOOK (IPv6)
WIKIMEDIA-EU (IPv6)
GOOGLE (IPv4)
AKAMAI-ASN1 (IPv4)
FACEBOOK (IPv4)
WIKIMEDIA-EU (IPv4)
100 101 102 1030.0
0.2
0.4
0.6
0.8
1.0
CD
F
100 101 102 103 0.0 0.2 0.4 0.6 0.8 1.0
TCP connect time (msecs)
0.0
0.2
0.4
0.6
0.8
1.0SamKnows Probe: #09
GOOGLE (IPv6)
AKAMAI-ASN1 (IPv6)
FACEBOOK (IPv6)
WIKIMEDIA-EU (IPv6)
GOOGLE (IPv4)
AKAMAI-ASN1 (IPv4)
FACEBOOK (IPv4)
WIKIMEDIA-EU (IPv4)
101 102 1030.0
0.2
0.4
0.6
0.8
1.0
CD
F
101 102 103
Fig. 10. Distribution of TCP connect times (in log scale) over IPv4 (blue)and IPv6 (red) as seen by probes wired behind an operator’s lab (boxed) andbusiness network (unboxed) for 4 CDN deployments: Google, Akamai-ASN1,Facebook and Wikimedia-EU. The list of origin AS (IPv4 and IPv6) of eachSamKnows probe is available in Fig. 4.
0.0 0.2 0.4 0.6 0.8 1.0
TCP connect time (msecs)
0.0
0.2
0.4
0.6
0.8
1.0SamKnows Probe: #02
GOOGLE (IPv6)
AKAMAI-ASN1 (IPv6)
FACEBOOK (IPv6)
WIKIMEDIA-EU (IPv6)
GOOGLE (IPv4)
AKAMAI-ASN1 (IPv4)
FACEBOOK (IPv4)
WIKIMEDIA-EU (IPv4)
101 102 103 1040.0
0.2
0.4
0.6
0.8
1.0
CD
F
101 102 103 104 0.0 0.2 0.4 0.6 0.8 1.0
TCP connect time (msecs)
0.0
0.2
0.4
0.6
0.8
1.0SamKnows Probe: #04
GOOGLE (IPv6)
AKAMAI-ASN1 (IPv6)
FACEBOOK (IPv6)
WIKIMEDIA-EU (IPv6)
GOOGLE (IPv4)
FACEBOOK (IPv4)
WIKIMEDIA-EU (IPv4)
101 102 1030.0
0.2
0.4
0.6
0.8
1.0
CD
F
101 102 0.0 0.2 0.4 0.6 0.8 1.0
TCP connect time (msecs)
0.0
0.2
0.4
0.6
0.8
1.0SamKnows Probe: #11
GOOGLE (IPv6)
AKAMAI-ASN1 (IPv6)
FACEBOOK (IPv6)
WIKIMEDIA-EU (IPv6)
GOOGLE (IPv4)
AKAMAI-ASN1 (IPv4)
FACEBOOK (IPv4)
WIKIMEDIA-EU (IPv4)
100 101 102 1030.0
0.2
0.4
0.6
0.8
1.0
CD
F
100 101 102 103
0.0 0.2 0.4 0.6 0.8 1.0
TCP connect time (msecs)
0.0
0.2
0.4
0.6
0.8
1.0SamKnows Probe: #12
GOOGLE (IPv6)
AKAMAI-ASN1 (IPv6)
FACEBOOK (IPv6)
GOOGLE (IPv4)
AKAMAI-ASN1 (IPv4)
FACEBOOK (IPv4)
101 102 1030.0
0.2
0.4
0.6
0.8
1.0
CD
F
101 102 103
0.0 0.2 0.4 0.6 0.8 1.0
TCP connect time (msecs)
0.0
0.2
0.4
0.6
0.8
1.0SamKnows Probe: #13
GOOGLE (IPv6)
AKAMAI-ASN1 (IPv6)
FACEBOOK (IPv6)
WIKIMEDIA-EU (IPv6)
GOOGLE (IPv4)
AKAMAI-ASN1 (IPv4)
FACEBOOK (IPv4)
WIKIMEDIA-EU (IPv4)
101 102 103 1040.0
0.2
0.4
0.6
0.8
1.0
CD
F
101 102 103 104 0.0 0.2 0.4 0.6 0.8 1.0
TCP connect time (msecs)
0.0
0.2
0.4
0.6
0.8
1.0SamKnows Probe: #17
GOOGLE (IPv6)
AKAMAI-ASN1 (IPv6)
FACEBOOK (IPv6)
WIKIMEDIA-EU (IPv6)
GOOGLE (IPv4)
AKAMAI-ASN1 (IPv4)
FACEBOOK (IPv4)
WIKIMEDIA-EU (IPv4)
101 102 1030.0
0.2
0.4
0.6
0.8
1.0C
DF
101 102 1030.0 0.2 0.4 0.6 0.8 1.0
TCP connect time (msecs)
0.0
0.2
0.4
0.6
0.8
1.0SamKnows Probe: #19
GOOGLE (IPv6)
AKAMAI-ASN1 (IPv6)
FACEBOOK (IPv6)
WIKIMEDIA-EU (IPv6)
GOOGLE (IPv4)
FACEBOOK (IPv4)
WIKIMEDIA-EU (IPv4)
100 101 102 1030.0
0.2
0.4
0.6
0.8
1.0
CD
F
100 101 102
0.0 0.2 0.4 0.6 0.8 1.0
TCP connect time (msecs)
0.0
0.2
0.4
0.6
0.8
1.0SamKnows Probe: #20
AKAMAI-ASN1 (IPv6)
FACEBOOK (IPv6)
GOOGLE (IPv4)
AKAMAI-ASN1 (IPv4)
FACEBOOK (IPv4)
101 102 1030.0
0.2
0.4
0.6
0.8
1.0
CD
F
100 101 102 103
0.0 0.2 0.4 0.6 0.8 1.0
TCP connect time (msecs)
0.0
0.2
0.4
0.6
0.8
1.0SamKnows Probe: #16
GOOGLE (IPv6)
AKAMAI-ASN1 (IPv6)
FACEBOOK (IPv6)
WIKIMEDIA-EU (IPv6)
GOOGLE (IPv4)
AKAMAI-ASN1 (IPv4)
FACEBOOK (IPv4)
WIKIMEDIA-EU (IPv4)
100 101 102 1030.0
0.2
0.4
0.6
0.8
1.0
CD
F
100 101 102 0.0 0.2 0.4 0.6 0.8 1.0
TCP connect time (msecs)
0.0
0.2
0.4
0.6
0.8
1.0SamKnows Probe: #01
GOOGLE (IPv6)
AKAMAI-ASN1 (IPv6)
FACEBOOK (IPv6)
WIKIMEDIA-EU (IPv6)
GOOGLE (IPv4)
AKAMAI-ASN1 (IPv4)
FACEBOOK (IPv4)
WIKIMEDIA-EU (IPv4)
100 101 102 1030.0
0.2
0.4
0.6
0.8
1.0
CD
F
100 101 102 103 104 0.0 0.2 0.4 0.6 0.8 1.0
TCP connect time (msecs)
0.0
0.2
0.4
0.6
0.8
1.0SamKnows Probe: #15
GOOGLE (IPv6)
AKAMAI-ASN1 (IPv6)
FACEBOOK (IPv6)
WIKIMEDIA-EU (IPv6)
GOOGLE (IPv4)
AKAMAI-ASN1 (IPv4)
FACEBOOK (IPv4)
WIKIMEDIA-EU (IPv4)
100 101 102 1030.0
0.2
0.4
0.6
0.8
1.0
CD
F
100 101 102 103 0.0 0.2 0.4 0.6 0.8 1.0
TCP connect time (msecs)
0.0
0.2
0.4
0.6
0.8
1.0SamKnows Probe: #18
GOOGLE (IPv6)
AKAMAI-ASN1 (IPv6)
FACEBOOK (IPv6)
WIKIMEDIA-EU (IPv6)
GOOGLE (IPv4)
AKAMAI-ASN1 (IPv4)
FACEBOOK (IPv4)
WIKIMEDIA-EU (IPv4)
100 101 102 1030.0
0.2
0.4
0.6
0.8
1.0
CD
F
100 101 102 103
Fig. 11. Distribution of TCP connect times (in log scale) over IPv4 (blue) and IPv6 (red) as seen by probes wired behind a residential gateway (boxed)and research network (unboxed) for 4 CDN deployments: Google, Akamai-ASN1, Facebook and Wikimedia-EU. The list of origin AS (IPv4 and IPv6) of eachSamKnows probe is available in Fig. 4.
DTAG networks (#04 and #19) do not reach out to websitesserved by Akamai CDN over IPv4, but instead are directlyserved by Akamai content caches deployed from within theDTAG network. It can also be seen how such content cachesare largely absent over the IPv6 network. A probe connectedto BELNET (the Belgian NREN) (#15) shows consistentbehaviour across address families. A probe connected to theDFN (the German NREN) (#01) shows similar medians overthe address families, however, the variation for the FacebookCDN over IPv6 is much higher. The probe connected to KabelDeutschland (#02) shows very similar behaviour with a certaindelay offset. This offset is likely due to the different accesstechnology (cable). In general, it seems that IPv6 access tothe Facebook CDN shows much higher variation comparedto IPv4. Some of the probes occasionally also see very slowconnect times (For instance, #13 connected to Jazz Telecomin Spain for all four CDNs and #02 connected to KabelDeutschland for all except the Facebook CDN). It is not clearwhat causes this but at least these effects do not seem to beaddress family specific. A probe connected to ROEDUNET
(the Romanian NREN) (#08) does not perform any IPv6measurements due to a routing issue in the upstream network.
D. Special Cases
Our dataset from a distributed set of vantage points hasallowed us to identify global events that have affected dual-stacked hosts. In this section, we discuss these events:
1) Bing: The website www.bing.com used to be dual-stacked. However, we witnessed how all of our SamKnowsprobes stopped performing measurements to www.bing.comover IPv6 starting September 2013. Fig. 13 shows the timeseries of TCP connection establishment times over IPv4 andIPv6 as seen from all and individual vantage points towardsthis website. There appears to be an abrupt cut-off of IPv6hinting towards a network policy decision. We investigatedthe DNS entries returned for www.bing.com and found thatthe upstream resolvers have stopped providing AAAA entriesfor this website.
#01
#02
#03
#04 #
05#06 #
07#08
#09
#10 #
11#12
#13
#14 #
15#16 #
17#18
#19
#20
SamKnows Probes
100
101
102
103
104
TC
P c
onnect
tim
e (
mse
cs)
GOOGLE (AS15169)[12-Mar-2013 CET to 15-Jul-2014 CET]
IPv4
#01
#02
#03
#04 #
05#06 #
07#09
#10 #
11#12
#13
#14 #
15#16 #
17#18
#19
SamKnows Probes
TC
P c
onnect
tim
e (
mse
cs)
GOOGLE (AS15169)[18-Apr-2013 CET to 27-May-2014 CET]
IPv6
Boxplot grouped by name
10-1 100 101 102 103 104
TCP connect time (msecs)
0.0
0.2
0.4
0.6
0.8
1.0
CD
F(n
um
ber
of
IPv6
measu
rem
ents
: 2
01
54
4)
0.0
0.2
0.4
0.6
0.8
1.0
CD
F(n
um
ber
of
IPv4
measu
rem
ents
: 2
19
34
6)
GOOGLE (AS15169)
IPv6
IPv4
#01
#02
#03
#04 #
05#06 #
07#08
#09
#10 #
11#12
#13
#14 #
15#16 #
17#18
#19
#20
SamKnows Probes
100
101
102
103
104
TC
P c
onnect
tim
e (
mse
cs)
FACEBOOK (AS32934)[12-Mar-2013 CET to 15-Jul-2014 CET]
IPv4
#01
#02
#03
#04 #
05#06 #
07#09
#10 #
11#12
#13
#14 #
15#16 #
17#18
#19
#20
SamKnows Probes
TC
P c
onnect
tim
e (
mse
cs)
FACEBOOK (AS32934)[18-Apr-2013 CET to 15-Jul-2014 CET]
IPv6
Boxplot grouped by name
100 101 102 103 104
TCP connect time (msecs)
0.0
0.2
0.4
0.6
0.8
1.0
CD
F(n
um
ber
of
IPv6
measu
rem
ents
: 6
25
7)
0.0
0.2
0.4
0.6
0.8
1.0
CD
F(n
um
ber
of
IPv4
measu
rem
ents
: 6
50
8)
FACEBOOK (AS32934)
IPv6
IPv4
#01
#02
#03
#05
#07
#08
#09
#10 #
11#12
#13
#14 #
15#16 #
17#18
#20
SamKnows Probes
100
101
102
103
104
TC
P c
onnect
tim
e (
mse
cs)
AKAMAI-ASN1 (AS20940)[12-Mar-2013 CET to 15-Jul-2014 CET]
IPv4
#01
#02
#03
#04 #
05#07
#09
#10 #
11#12
#13
#14 #
15#16 #
17#18
#19
#20
SamKnows Probes
TC
P c
onnect
tim
e (
mse
cs)
AKAMAI-ASN1 (AS20940)[18-Apr-2013 CET to 15-Jul-2014 CET]
IPv6
Boxplot grouped by name
100 101 102 103 104
TCP connect time (msecs)
0.0
0.2
0.4
0.6
0.8
1.0
CD
F(n
um
ber
of
IPv6
measu
rem
ents
: 9
04
7)
0.0
0.2
0.4
0.6
0.8
1.0
CD
F(n
um
ber
of
IPv4
measu
rem
ents
: 7
37
5)
AKAMAI-ASN1 (AS20940)
IPv6
IPv4
#01
#02
#03
#04 #
05#06 #
07#08
#09
#10 #
11#13
#15
#16 #
17#18
#19
SamKnows Probes
100
101
102
103
104
TC
P c
onnect
tim
e (
mse
cs)
WIKIMEDIA-EU (AS43821)[12-Mar-2013 CET to 27-May-2014 CET]
IPv4
#01
#02
#03
#04 #
05#06 #
07#09
#10 #
11#13
#15
#16 #
17#18
#19
SamKnows Probes
TC
P c
onnect
tim
e (
mse
cs)
WIKIMEDIA-EU (AS43821)[18-Apr-2013 CET to 27-May-2014 CET]
IPv6
Boxplot grouped by name
100 101 102 103 104
TCP connect time (msecs)
0.0
0.2
0.4
0.6
0.8
1.0C
DF
(num
ber
of
IPv6
measu
rem
ents
: 8
07
7)
0.0
0.2
0.4
0.6
0.8
1.0
CD
F(n
um
ber
of
IPv4
measu
rem
ents
: 8
30
9)
WIKIMEDIA-EU (AS43821)
IPv6
IPv4
Fig. 12. Box plots of TCP connection establishment times (in log scale) over IPv4 (left) and IPv6 (right) for 4 CDN deployments: Google, Akamai-ASN1,Facebook and Wikimedia-EU as seen by all vantage points. An associated CDF plot shows the distribution of TCP connection establishment times (in log scale)over IPv4 (blue) and IPv6 (red) aggregated over all SamKnows probes.
2) Google: On another SamKnows probe (deployed inJapan) we noticed how there were no measurements beingperformed to any of the google websites. Fig. 14 shows BGP-based clusters formed from endpoints seen by this vantagepoint both over IPv4 and IPv6. The measurements appear tobe active to Google CDNs over IPv4, but are completely absentfor IPv6. The probe itself is also successfully able to measureagainst other websites over IPv6. We investigated the issueand found that this happens to be a network policy decisionmade by these content providers. For instance, Google used toperform AAAA prefix whitelisting to prevent users with brokenIPv6 connectivity from requesting services over IPv6. Only thewhitelisted DNS resolvers received AAAA records for Google
services. This was an opt-in process, where an ISP explicitlysigned up to receive Google services over IPv6. This helpedensure users had reliable IPv6 connectivity before trying toreach Google services over IPv6 [8]. Since the World IPv6Launch Day in 20129, Google has changed their policy. Thewhitelist has been replaced by a blacklist10. This eliminatesthe opt-in process and increases the chance of a dual-stackedhost reaching Google services over IPv6. However, if a host isbehind a resolver from a blacklisted prefix, it will not receiveGoogle services over IPv6 even though the host may enjoyperfect IPv6 connectivity from the network provider. The pie
9http://www.worldipv6launch.org10http://www.google.com/ ipv6/statistics/data/no_aaaa.txt
chart in Fig. 15 shows a country-based distribution of theblacklisted prefixes. The geolocation of the prefix is fetchedfrom the MaxMind11 database. It appears, a large number ofblacklisted prefixes appear to originate from Japan. These areISPs whose DNS resolvers explicitly started filtering AAAArecords after World IPv6 launch day and are now blacklisted.We checked and our probe appears to be behind such ablacklisted resolver.
V. CONCLUSION
We have performed a study using a metric that measuresTCP connection establishment times to 100 dual-stacked web-sites from SamKnows probes connected behind both residentialand NREN. Using a year-long dataset derived from thesemeasurements we showed how popular websites cluster aroundCDN deployments. We showed how multiple websites areserved from CDN caches deployed within access networks.We also witnessed cases where these CDN caches were presentfor IPv4, but were largely absent for IPv6 leading to relativelyhigher TCP connection establishment times. We also showedhow CDN clusters and number of websites within each clustervary depending on the used address family. The distributionsof connection setup times revealed how IPv6 connectivityto popular CDN deployments have improved over time. Weshowed how www.bing.com stopped providing websites overIPv6 since Sep 2013 and how Google employ blacklists toblock some hosts from receiving their services over IPv6.
VI. ACKNOWLEDGEMENTS
This work was supported by the European Community’sSeventh Framework Programme (FP7/2007-2013) grant no.317647 (Leone). We would like to thank all the volunteers whohosted a SamKnows probe for us. We would like to thank SamCrawford and Jamie Mason for providing us technical supporton the SamKnows infrastructure and Steffie Jacob Eravuchirafor reviewing our manuscripts.
11http://www.maxmind.com
12-M
ar-2
013
CET
13-Ju
l-201
3 CET
15-Ja
n-20
14 C
ET
24-F
eb-2
014
CET
04-A
pr-2
014
CET
09-M
ay-2
014
CET
19-Ju
n-20
14 C
ET100
101
102
103
TC
P c
onnect
tim
e o
ver
IPv6 (
mse
cs)
www.bing.com
100
101
102
103
104
TC
P c
onnect
tim
e o
ver
IPv4 (
mse
cs)
www.bing.com
IPv6
IPv4
12-M
ar-2
013
CET
13-Ju
l-201
3 CET
15-Ja
n-20
14 C
ET
24-F
eb-2
014
CET
04-A
pr-2
014
CET
09-M
ay-2
014
CET
19-Ju
n-20
14 C
ET0
50
100
150
200
250
300
350
TC
P c
onnect
tim
e o
ver
IPv6 (
mse
cs)
www.bing.com
0
200
400
600
800
1000
1200
1400
1600
1800
TC
P c
onnect
tim
e o
ver
IPv4 (
mse
cs)
www.bing.com
IPv6
IPv4
0.0 0.2 0.4 0.6 0.8 1.00.0
0.2
0.4
0.6
0.8
1.0
www.bing.com
12-M
ar-2
013
CET
08-M
ay-2
013
CET
04-Ju
l-201
3 CET
25-S
ep-2
013
CET
12-F
eb-2
014
CET
10-A
pr-2
014
CET
30-M
ay-2
014
CET100
101
102
103
104
TC
P c
onnect
tim
e o
ver
IPv4
(m
secs
)
IPv4
Probes
12-M
ar-2
013
CET
08-M
ay-2
013
CET
04-Ju
l-201
3 CET
25-S
ep-2
013
CET
12-F
eb-2
014
CET
10-A
pr-2
014
CET
30-M
ay-2
014
CET100
101
102
103
104 IPv6
Probes
Fig. 13. Time series of TCP connect times to www.bing.com over IPv4 (blue)and IPv6 (red) as seen from all (above) and each (below) vantage point. Themeasurements over IPv6 stopped for all probes starting Sep 2013.
IANA
APNI
C
FKNE
T (A
S975
2)ww
w.flip
kart.
com
INFO
WEB
(AS2
510)
www.
nifty
.com
BIG
LOBE
(AS2
518)
bigl
obe.
ne.jp
YAHO
O (A
S561
73)
www.
yaho
o.co
m
CHIN
ATEL
ECO
M (A
S480
9)ww
w.qq
.com
SAKU
RA (A
S937
1)ww
w.sa
kura
.ne.
jp
DETI
K (A
S242
11)
www.
detik
.com
NETM
AGIC
(AS1
7439
)ww
w.flip
kart.
com
ARIN
MOZILLA
(AS3
6856
)
www.
mozilla
.org
AKAMAI (AS20
940)
www.att.c
om
www.usps
.com
TERRA (AS40
260)
www.terra
.com.br
WIKIMEDIA (AS14907)
www.wikimed
ia.org
www.wiktionary.o
rg
www.wikipedia.org
AOL (AS1668)
www.aol.com
www.engadget.com
MICROSOFT (AS8075)www.bing.com
GOOGLE (AS15169)
www.google.ru
www.google.se
www.google.com.hk
www.google.com.bd
www.google.com.ph
www.google.cz
www.google.ae
www.googleusercontent.com
www.blogspot.jp
www.google.co.id
www.google.co.in
www.google.com.ngwww.google.rowww.google.nlwww.blogspot.co.ukwww.google.co.ukwww.google.co.thwww.youtube.comwww.google.com.sawww.google.co.krwww.google.dzwww.google.comwww.google.com.co
www.google.com.pkwww.google.com.br
www.google.com.tr
www.google.co.il
www.google.bewww.google.es
www.google.no
www.google.com.ua
www.google.co.za
www.google.com.tw
www.google.it
www.google.sk
www.google.com.eg
www.google.co.hu
www.google.com.ar
www.google.fr
www.google.pl
www.google.com.sg
www.blogspot.ru
www.google.ie
www.google.at
www.google.co.jp
www.google.pt
www.google.com.au
www.google.co.ve
www.blogspot.in
www.google.com.vn
www.google.ca
www.google.com.pe
www.google.de
www.google.ch
www.google.gr
www.doubleclick.com
www.google.cl
www.google.com.m
x
www.google.azwww.google.fiwww.google.dk
www.
goog
le.c
om.m
y
MO
ZILL
A (A
S533
71)
www.
moz
illa.o
rg
AMAZ
ON
(AS1
4618
)
www.
netfl
ix.co
m
N/AAO
L (A
S166
8)
www.
enga
dget
.com
AKAM
AI (A
S209
40)
www.
irs.g
ov
www.
com
cast.
net
GOOGLE (AS15169)
www.
goog
le.se
www.
goog
le.co
m.b
d
www.
goog
le.co
m.ph
www.
goog
le.cz
www.
goog
le.ae
www.
apps
pot.c
om
www.blo
gspo
t.jp
www.go
ogle.
co.id
www.goog
le.co
.in
www.goog
le.co
m.ng
www.goog
le.ro
www.goog
le.nl
www.blogsp
ot.co.
uk
www.google.co.uk
www.google.co.th
www.youtube.co
m
www.google.com.sa
www.google.co.kr
www.google.dz
www.google.com.co
www.blogspot.com
www.google.com.brwww.google.co.ilwww.google.es
www.blogger.comwww.google.nowww.google.co.zawww.google.itwww.google.skwww.google.com.egwww.google.co.huwww.google.com.arwww.google.fr
www.google.cnwww.google.pl
www.google.com.sgwww.blogspot.ru
www.google.ie
www.google.at
www.google.pt
www.google.co.ve
www.blogspot.in
www.google.com.vn
www.google.ca
www.google.com.pe
www.google.de
www.google.ch
www.google.gr
www.blogspot.de
www.google.com.mx
www.google.az
www.google.fi
www.google.dk
www.google.com.my
RIPE
PROXAD (AS12322)
www.free.fr SEZNAM (AS43037)
www.seznam.cz
MARKTPLAATS (AS41552)
www.mobile.de VKONTAKTE (AS47541)
www.vk.com
Unidad (AS9052)
www.elmundo.es
www.marca.com
DTAG (AS3320)
www.t-online.deW
ANADOOPORTAILS (AS24600)
www.orange.fr
FACEBOOK (AS32934)
www.fbcdn.netwww.facebook.com
Orange (AS8891)
www.orange.fr
CLOUDFLARENET (AS13335)
www.youm7.com
LACNIC
CLOUDFLARENET (AS13335)
www.youm7.com
Universo (AS7162)
www.folha.uol.com.br
www.uol.com.br
IANA
APNIC
INFO
WEB
(AS2
510)
www.
nifty
.com
FKNE
T (A
S975
2)
www.
flipka
rt.co
m
BIGLO
BE (A
S251
8)
biglob
e.ne.j
p
CLOUDFLARENET (AS13335)www.yo
um7.com
AMAZON (AS16509)www.netflix.com
YHKR3 (AS38689)www.yahoo.com
CNNIC (AS45090) www.qq.com
ARIN
TERRA (AS40260)www.terra.com.br
AKAMAI (AS20940)
www.att.comwww.irs.govwww.usps.com
www.comcast.net
MOZILLA (AS36856)
www.mozilla.org
WIKIM
EDIA (AS14907)
www.wikimedia.org
www.wikipedia.org
www.
wikt
iona
ry.o
rg
AOL
(AS1
668)
www.
aol.c
om
RIPE
PROXA
D (A
S123
22)
www.
free.f
r
SEZNAM (AS43
037)
www.sezna
m.cz
VKONTAKTE (AS47541)
www.vk.com
MARKTPLAATS (AS41552)
www.mobile.de
Unidad (AS9052)
www.elmundo.es
www.marca.com
WANADOOPORTAILS (AS24600)
www.orange.fr
FACEBOOK (AS32934)
www.fbcdn.net
www.facebook.com
DTAG (AS3320)
www.t-online.de Orange (AS8891)
www.orange.fr
LACNIC
Universo (AS7162)
www.folha.uol.com.br
www.uol.com.br
Fig. 14. An IPv4 (left) and IPv6 (right) BGP-based aggregation of websitesas seen by a SamKnows probe deployed in Japan connected via BIGLOBENEC [AS2518, AS2516]. The probe does measurements to Google websitesover IPv4, but not over IPv6. Its IPv6 connectivity is not broken, since it doesperform measurements to rest of the websites over IPv6.
CountryDistribution
JPJP :32.10%
CNCN :16.05%
TWTW :9.88%
BRBR :3.09%
DEDE :2.47%
IDID :2.47%
CA(US)CA(US) :2.47%
GBGB :1.85%
ININ :1.85%
SGSG :1.85%
OTHERSOTHERS:25.93%
Highcharts.com
Fig. 15. A distribution of prefixes blacklisted by Google over IPv6. A largenumber of resolvers in Japan appear to be blacklisted.
REFERENCES
[1] J. Czyz, M. Allman, J. Zhang, S. Iekel-Johnson, E. Osterweil, andM. Bailey, “Measuring IPv6 Adoption,” ser. SIGCOMM, 2014. [Online].Available: http://doi.acm.org/10.1145/2619239.2626295
[2] D. Thaler, R. Draves, A. Matsumoto, and T. Chown, “Default AddressSelection for Internet Protocol Version 6 (IPv6),” RFC 6724, Sep. 2012.[Online]. Available: http://www.ietf.org/rfc/rfc6724.txt
[3] K. Cho, M. Luckie, and B. Huffaker, “Identifying IPv6 NetworkProblems in the Dual-stack World,” ser. NetT, 2004. [Online]. Available:http://doi.acm.org/10.1145/1016687.1016697
[4] L. Colitti, S. H. Gunderson, E. Kline, and T. Refice, “EvaluatingIPv6 Adoption in the Internet,” ser. PAM, 2010. [Online]. Available:http://dl.acm.org/citation.cfm?id=1889324.1889339
[5] M. Nikkhah, R. Guérin, Y. Lee, and R. Woundy, “Assessing IPv6Through Web Access a Measurement Study and Its Findings,”ser. CoNEXT, 2011. [Online]. Available: http://doi.acm.org/10.1145/2079296.2079322
[6] A. Dhamdhere, M. Luckie, B. Huffaker, k. claffy, A. Elmokashfi,and E. Aben, “Measuring the Deployment of IPv6: Topology,Routing and Performance,” ser. IMC, 2012. [Online]. Available:http://doi.acm.org/10.1145/2398776.2398832
[7] H. Alzoubi, M. Rabinovich, and O. Spatscheck, “PerformanceImplications of Unilateral Enabling of IPv6,” ser. PAM, 2013, vol. 7799.[Online]. Available: http://dx.doi.org/10.1007/978-3-642-36516-4_12
[8] J. Livingood, “Considerations for Transitioning Content to IPv6,” RFC6589, Apr. 2012. [Online]. Available: http://www.ietf.org/rfc/rfc6589.txt