ipv4 versus ipv6 - who connects faster?

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


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



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


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.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.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.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


0.0

0.2

0.4

0.6

0.8


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


0.0

0.2

0.4

0.6

0.8


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


0.0

0.2

0.4

0.6

0.8


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


0.0

0.2

0.4

0.6

0.8


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


0.0

0.2

0.4

0.6

0.8


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


0.0

0.2

0.4

0.6

0.8


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


0.0

0.2

0.4

0.6

0.8


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


0.0

0.2

0.4

0.6

0.8


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


0.0

0.2

0.4

0.6

0.8


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


0.0

0.2

0.4

0.6

0.8


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


0.0

0.2

0.4

0.6

0.8


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


0.0

0.2

0.4

0.6

0.8


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


0.0

0.2

0.4

0.6

0.8


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


0.0

0.2

0.4

0.6

0.8


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


0.0

0.2

0.4

0.6

0.8


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


0.0

0.2

0.4

0.6

0.8


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


0.0

0.2

0.4

0.6

0.8


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


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


100 101 102 103 104


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


100 101 102 103 104


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


100 101 102 103 104


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.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.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.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