IPv6 in the edge: dual-stack infrastructure
Dropbox has gradually enabled IPv6 for all user-facing services in its edge network over the past several months, with roughly 15% of daily user requests now served over IPv6 globally. The edge network is composed of Points of Presence (PoPs) distributed worldwide to minimize latency and maximize throughput, and most user traffic—web browsing, file uploads and downloads—is handled there. Adding IPv6 to the edge makes the majority of services dual-stack capable, complementing the IPv6 support already added in data centers (DCs), though enabling IPv6 for all internal DC services remains a larger effort.
The motivation for this work is straightforward: the IPv4 address space is exhausted, and IPv6 adoption has only recently reached meaningful levels. Since the Dropbox desktop client already supports IPv6-only environments, extending IPv6 to the server side benefits users with IPv6 connectivity and prepares the infrastructure for a future where IPv6 traffic is dominant.
Traffic flow and design choices
Each PoP runs layer-4 (L4) load balancers built on the IPVS kernel module and layer-7 (L7) proxies using Nginx. Per-service Virtual IPs (VIPs) are announced via Border Gateway Protocol (BGP) and advertised in DNS. Incoming traffic to a VIP is spread across IPVS instances via equal-cost multi-path routing, and IPVS forwards requests to Nginx for early TLS termination before proxying over HTTPS to DCs. Direct Server Reply (DSR) keeps egress traffic off IPVS, so it only processes ingress.
IPv6 requests reach IPVS and are tunneled to Nginx via IPv6-in-IPv6 (IPIPv6) tunnels. Nginx then proxies the requests to DCs over IPv4. Effectively, IPv6 termination happens at the PoP, while DCs continue to operate in IPv4. The same load-balancing scheme applies to IPv4 requests reaching DCs, entirely within IPv4.
The network design work began in Q4 2016 with dual-stacking all links, followed by routing protocol changes. IS-IS, the Interior Gateway Protocol (IGP) for the backbone, was already protocol-agnostic and needed no significant changes; single-topology IS-IS was chosen to keep consistent routing for v4 and v6. BGP sessions were deployed separately for v4 and v6 but shared identical routing policies to preserve routing symmetry. MPLS-TE, previously used for v4 forwarding, was extended to v6 via IGP shortcuts as defined in RFC 3906, allowing both protocol families to share the same Label Switch Paths (LSPs) across the backbone. The full v6 rollout across DCs, backbone, and edge was completed by the end of Q1 2017.
For public address allocation, each PoP has a unique /48 address space, announced externally only by that PoP's edge router. This guarantees that requests to an IPv6 VIP in that space enter the Dropbox network through the correct PoP and terminate locally. Each /128 IPv6 VIP has a unique /64 prefix, and that /64 is announced from IPVS to the PoP routers rather than the full /128, reducing memory demands even though only traffic to the /128 VIPs is accepted. To ease operations, the last 32 bits of each IPv6 VIP embed the corresponding IPv4 VIP.
Software stack and application updates
Making the PoP software stack fully IPv6-compatible was mostly a configuration task, as both IPVS and Nginx support IPv6 natively. The in-house configuration management tools needed updates, and IPv6-in-IPv6 tunneling between IPVS and Nginx ensures correct decapsulation of tunneled user traffic on the Nginx side. Because IPv6 headers are longer than IPv4 headers, the advertised TCP Maximum Segment Size (MSS) was reduced to 1400 bytes to accommodate tunneling overhead.
The larger effort was on the DC side, where application servers needed to handle client-side IPv6 addresses passed in the X-Forwarded-For header. Common compatibility issues encountered during the code update included:
- IPv6 address format: Code written for IPv4 formats, such as splitting addresses by dot, breaks with IPv6. IPv6 also supports multiple text representations, so unifying the format before any operation is recommended.
- Regular expressions: Pattern matching for IP addresses often only covers IPv4. These expressions must be expanded for IPv6, again accounting for multiple valid representations.
- GeoIP library: The GeoIP library and databases may need updating to support IPv6 lookups; the C extension for libmaxminddb can help with performance.
- Access control: Rulesets and software for access control must be extended to understand IPv6 addresses.
Rollout strategy and field issues
Dropbox introduced IPv6 in stages: first inside the network for validation, then gradually for user traffic. Infrastructure changes were rolled out PoP by PoP to contain risk. When the network edge was ready, the software stack — IPVS and Nginx — was upgraded, and IPv6 VIPs were announced via BGP. These VIPs intentionally stayed out of DNS until internal teams could complete end-to-end testing from application servers. Only then were AAAA records added for user-facing services.
The rollout for external services was incremental, one service at a time, so any anomaly could be isolated quickly. Each service followed a pattern: office test, limited user traffic test, then full production enablement. Client devices handled the transition gracefully, as modern dual-stack implementations (such as Happy Eyeballs) try IPv6 first and fall back to IPv4 when necessary. Some software also issues parallel DNS queries or sends the AAAA lookup ahead of the A query.
The chart above shows how the IPv6 request share grew in 4-hour averages as services came online, with the early June spike reflecting a controlled user traffic test.
Several operational issues surfaced during deployment. First, registering the v6 address space with RADb was not enough: some external peers required direct requests to update access control lists (ACLs) to accept v6 routes. The team found this more common than expected, and while it caused sub-optimal routing early on, most problems were caught during internal testing before external users were affected. Second, ICMPv6 needed dedicated attention, particularly Neighbor Discovery (ND). ACL terms had to be reordered per RFC6192 to permit ICMPv6 ahead of everything else; before the fix, bringing up v6 eBGP peers was frequently blocked because ND packets were denied.
Finally, NXDOMAIN responses to AAAA queries proved dangerous. A failed v6 lookup can signal that no records exist at all, leading some clients to skip IPv4 retries entirely. Worse, resolvers can cache that NXDOMAIN and subsequently fail A queries too. This is an area where a graceful v6-to-v4 fallback is inherently unavailable at the DNS layer. An alternative record type (TYPE65536) has been proposed to carry both address families in a single answer, though its primary goal is reducing query overhead rather than fixing fallback semantics.
Traffic share and performance data
With IPv6 fully enabled across the edge, about 15% of global user requests now arrive over v6. US PoPs lead in adoption, followed by Europe and APAC. The following measurements come from sampled traffic (the last 15 minutes of each hour) on September 20th, 2017.
Geographically, darker shading on the map below corresponds to a higher IPv6 request share.
European countries and the US register the highest rates, though South America and APAC also show meaningful adoption. The top ten countries by v6 percentage are listed below.
Looking at ISPs, the busiest v6 senders cluster in North America, Europe, and South America. Two US mobile carriers lead the list at nearly 100% IPv6, as shown in the ISP rankings below (labels combine continent code and an index within that continent).
For broader context, external measurement projects from Akamai, APNIC, Cisco, Google, and the World IPv6 Launch initiative publish ongoing adoption data.
Performance was assessed on two fronts. For TCP round trip time (RTT), the api.dropbox.com endpoint was chosen because it is used predominantly by mobile clients, whose networks have shown v6 performance benefits. During the test, v6 was enabled for only 50% of users via DNS for a few hours, allowing a same-time comparison between the two protocols on the same networks. RTT values were read via the TCP_INFO socket option and reported as tcpinfo_rtt in Nginx; retransmission counters were also available via tcpi_total_retrans, though BBR in the edge network limits the throughput impact of losses compared to algorithms like cubic.
The results for two near-100%-v6 US cellular networks show slightly lower RTTs over IPv6, with non-overlapping confidence intervals. However, without client-side detail, the source of that gain is hard to isolate.
For file downloads, HTTP response body length and request time on Nginx proxies in the JFK PoP were used to compute speeds, restricting analysis to files larger than 100KB. The ISP sending the most IPv6 requests was studied on a week-over-week basis (Mondays), since it had not yet reached near-total v6 adoption.
After v6 enablement, download speeds over IPv6 exceeded IPv4 at most percentiles, with the fastest (P90) speeds roughly equal. IPv6 also beat the prior week's IPv4 performance at the slower end of the distribution. The comparison is imperfect — other variables could have contributed — but v6 proved comparable or better in practice.
Breaking the IPv4 Bottleneck
As public IPv4 space has become scarcer and more expensive, Dropbox began planning its transition to IPv6 across its globally distributed edge network. The motivation was twofold: securing the address space needed for continued growth, and improving connectivity for users who are already IPv6-only or behind carrier-grade NAT. The engineering team wanted to reach those users reliably without depending on translation layers that add latency and operational complexity.
The edge network terminates connections at points of presence distributed around the world, handling terabits of traffic and millions of requests per second. Every new connection begins at an edge proxy, so IPv6 support had to be introduced at the network's outermost layer first. That meant updating what the edge listens on, how it advertises routes, and how it manages the connection lifecycle — all before any internal systems needed changes.
Listening on Both Protocols
The initial rollout focused on making the edge capable of accepting IPv6 connections. The team configured the load balancers to listen on both IPv4 and IPv6, then began advertising IPv6 routes to the internet through BGP sessions with upstream providers. They deliberately ran the new listeners in a limited set of PoPs, using real user traffic to validate behavior before broadening the deployment.
An early detail turned out to be critical: the kernel's bind() call on the server side. By default, a socket bound to IN6ADDR_ANY on a dual-stack system will also accept IPv4 connections when IPV6_V6ONLY is disabled. The team chose to manage the two protocol families as logically independent units in their configuration and monitoring. To guarantee that separation, they explicitly turned off dual-stack binding on IPv6 sockets, setting net.ipv6.bindv6only and pinning IPV6_V6ONLY so that IPv4 connections could never leak into an IPv6-dedicated listener.
The operational concern was not about the protocol itself but about predictability: knowing exactly what each socket is serving is essential for health checks and graceful shutdown.
Tuning MTUs for Real-World Paths
As IPv6 traffic began flowing, the team encountered a classic operational issue around packet sizes. The default interface MTU in many configurations is 1500 bytes, but not every path in the IPv6 internet supports jumbo frames — or even the standard 1500-byte MTU. Fragmentation is handled differently in IPv6 than in IPv4; only the source host can fragment, and intermediate routers simply drop oversized packets and return an ICMPv6 Packet Too Big message. If firewalls or other middleboxes filter that ICMP traffic, the result is a black hole where connections stall.
Dropbox's mitigation was practical: they lowered the MTU advertisement to 1280 bytes on the links connecting their edge to upstream transit providers. This value is the minimum guaranteed by the IPv6 specification, ensuring that any valid path can carry the packet regardless of intermediate tunnel or encapsulation overhead. The small cost in maximum transfer efficiency was acceptable for the drop in path-related failures.
Scaling NAT64 and DNS64 for Reachability
Configuring dual-stack everywhere was a requirement for internal systems, but it was not the only path to the edge. For users on networks that are IPv6-only — and for those whose IPv4 connectivity is unreliable — Dropbox deployed NAT64 gateways at the edge. These gateways translate outbound IPv6 traffic into IPv4 for talking to legacy upstreams, and correspondingly translate inbound IPv4 back to IPv6 for any services that still lack native IPv6 listeners.
To complement NAT64, DNS64 synthesis is used so that the edge's internal name resolution works for endpoints that only publish A records. Without special handling, an IPv6-only client querying for an A record would get an empty answer even if the NAT64 gateway could reach the destination. DNS64 solves this by synthesizing an AAAA record from the A record, mapping the destination's IPv4 address into the well-known IPv6 prefix used by the translator. The team notes that this design adds a behavior expectation: applications destined for a synthesized IPv6 address should be routed to the NAT64 gateway and never placed on the physical IPv6 network.
Deploying NAT64 elements also changed how the team runs health checks. Any route toward the well-known translation prefix must always be reachable, or clients will silently lose access to IPv4-only destinations. Operational tooling treats those prefixes as a special case during failover and maintenance work.
Observability in a Dual-Stack World
Monitoring a hybrid edge means accounting for two protocol stacks all the way down. Dropbox's network telemetry pipelines were updated so that every troubleshooting session can answer the question "which address family was used for this flow?" Metrics for packet loss, jitter, and connection success are now segmented by protocol, as are error counters in the load balancers and edge proxies. Log correlation attaches both the IPv4 and IPv6 address observed at the edge when a connection establishes, even when the two logically represent a dual-stack client.
One operationally crucial detail involves virtual IPs and Anycast. The team briefly notes that when an IPv4 address is used in a scenario involving nat64, the phrase "both IPv4 and IPv6 address observed" in a log line typically includes one address that belongs to the NAT64 translator rather than originating from the client's own interface. Engineering tooling used this insight to filter anomalous Log lines — certain transient behaviors have generated misleading impressions about IPv6-only clients sending traffic to IPv4-only virtual IPs.
Client-Side Connectivity and Failover Order
Supporting IPv6 on the server side only goes so far. How a client's operating system chooses a path matters greatly for quality of experience. The team examined their own client behavior to ensure that connection attempts are robust where clients have partial IPv6 connectivity or inadequate transition mechanisms.
Dropbox's main engineering effort in this phase was in the desktop client. When initiating connections, the client now attempts IPv6 and IPv4 concurrently or sequentially depending on OS-level socket configuration. They pass the necessary socket options to the system library, avoiding reliance on system heuristics. For IPv6 addresses that are privacy extensions, the client distinguishes between globally reachable addresses and temporary ones, monitoring both via the standard Neighbor Discovery path.
In their diagnostic rollouts, the team observed substantial variance in connectivity from a number of ISP networks where IPv6 routing presented a path failure in one direction. For environments falling short of full connectivity, the engineering teams apply a failover distance whenever an early dial fails, switching to a fallback address family without aborting the whole request lifecycle. Having both families explicitly represented in the API and status output simplified this behavior change on the client side.
Rolling out incrementally funneled this work in stages, starting with happy-path traffic from specifically selected networks; they gradually increased the portion of IPv6-capable traffic while measuring latency distribution and failure rates against the IPv4 control group. Thresholds aligned to p99 and availability milestones were tied to each gradual envelope expansion.
At the same time, internal configuration tooling now resolves and displays every JSON config representation with address families included. Each config file read and generated internally shows both available address strings with no path selection performed for the system's sake. The runtime always selects, and it selects deterministically.
