Search for: All records

Routing strives to connect all the Internet, but compete: political pressure threatens routing fragmentation; architectural changes such as private clouds, carrier-grade NAT, and firewalls make connectivity conditional; and commercial disputes create partial reachability for days or years. This paper suggests \emph{persistent, partial reachability is fundamental to the Internet} and an underexplored problem. We first \emph{derive a conceptual definition of the Internet core} based on connectivity, not authority. We identify \emph{peninsulas}: persistent, partial connectivity; and \emph{islands}: when computers are partitioned from the Internet core. Second, we develop algorithms to observe each across the Internet, and apply them to two existing measurement systems: Trinocular, where 6 locations observe 5M networks frequently, and RIPE Atlas, where 13k locations scan the DNS roots frequently. Cross-validation shows our findings are stable over \emph{three years of data}, and consistent with as few as 3 geographically-distributed observers. We validate peninsulas and islands against CAIDA Ark, showing good recall (0.94) and bounding precision between 0.42 and 0.82. Finally, our work has broad practical impact: we show that \emph{peninsulas are more common than Internet outages}. Factoring out peninsulas and islands as noise can \emph{improve existing measurement systems}; their ``noise'' is $$5\times$$ to $$9.7\times$$ larger than the operational events in RIPE's DNSmon. We show that most peninsula events are routing transients (45\%), but most peninsula-time (90\%) is due to a few (7\%) long-lived events. Our work helps inform Internet policy and governance, with our neutral definition showing no single country or organization can unilaterally control the Internet core. 

Twelve years have passed since World IPv6 Launch Day, but what is the current state of IPv6 deployment? Prior work has examined IPv6 status as a binary: can a user do \emph{any} IPv6? As deployment increases, we must consider a more nuanced, non-binary perspective on IPv6: *how much and often can a user or a service use IPv6?* We consider this question as a client, server, and cloud provider. Considering the client's perspective, we observe user traffic. We see that the fraction of IPv6 traffic a user sends varies greatly, both across users and day-by-day, with a standard deviation of over 15\%. We show this variation occurs for two main reasons. First, IPv6 traffic is primarily human-generated, thus showing diurnal patterns. Second, some services lead with full IPv6 adoption, while others lag with partial or no support,so as users do different things their fraction of IPv6 varies. We look at server-side IPv6 adoption in two ways. First, we expand analysis of web services to examine how many are only partially IPv6 enabled due to their reliance on IPv4-only resources. Our findings reveal that only 12.6\% of top 100k websites qualify as fully IPv6-ready. Finally, we examine cloud support for IPv6. Although all clouds and CDNs support IPv6, we find that tenant deployment rates vary significantly across providers. We find that ease of enabling IPv6 in the cloud is correlated with tenant IPv6 adoption rates, and recommend best practices for cloud providers to improve IPv6 adoption. Our results suggest IPv6 deployment is growing, but many services lag, presenting a potential for improvement. 

How do VPNs interact with IPv6? Our poster shows that VPNs often leak IPv6 traffic, failing to provide the promised privacy, and VPNs often prefer IPv4, even though IPv6 is available and working. These results use new data from a website for IP identification, coupled with experiments on specific VPN software. We identify the fraction of v6 traffic leaked, and find the root-cause of IPv6 de-preferencing in interactions between address selection in OSes and VPNs.