Subscribe to our newsletter
Get the latest news and industry insights in your inbox.
Subscribe to our newsletter
Thanks for subscribing.
Adding core features for Fastly is not as simple as typing something into an appliance command line or activating a pre-packaged module. As Fastly CEO Artur Bergman has said, “We will always insist that every component of the Fastly platform is fully integrated – we don't limit features to subsets of our network.” This is especially true when it comes to routing and switching; we don’t treat the network layer as a black box by using locked down hardware appliances.
We take the time to fully integrate standardized protocols and technologies like HTTP/2 and IPv6 into our stack, and maintain the standards our customers have come to expect. We decided early on to build our own network software for routing and inbound load balancing in order to achieve higher efficiency and availability. This allows us to retain more granular control over traffic and select network paths based on TCP performance metrics. Deploying IPv6 involved not only overhauling our existing software to support a new protocol, but also redesigning our network to explore the advantages of a larger address space.
IPv6 adoption is primarily being driven by network operators with limited IPv4 address space to allocate to their subscribers. As the number of IPv6 enabled clients on the internet increases, it becomes more important to reach these clients over a native IPv6 connection. Companies such as Facebook have reported significant speed improvements when using IPv6, while Apple has recently made IPv6 a requirement for IOS apps.
For content providers, using a CDN for IPv6 termination is an excellent way to reap the benefits of IPv6 seamlessly, without incurring the cost of overhauling backend infrastructure.
If you’re on our shared or dedicated maps, you have the option to use the corresponding IPv6 dualstack (IPv4 and IPv6) map right away. All new shared maps already have a dualstack option by default and new custom maps can be dualstack enabled with a support ticket at the time the map is created (or after the fact).
Shared map customers
If you CNAME to our shared maps, you can start using your IPv6 dualstack map immediately at your own convenience. The corresponding nomenclature will be the following:
For HTTP/1: dualstack.[single_letter].ssl.[global or us-eu].fastly.net
For HTTP/2: dualstack.[single_letter].shared.[global or us-eu].fastly.net
For example, here are the CNAME map formats you can use today if you’re on our “g” shared SAN certificate:
To take advantage of the “g” cert map’s dualstack capability, you now have the following options:
You can see that the word “dualstack” is prepended on both types of maps, and while the HTTP/1 maps now include a more detailed notation of “global” or “us-eu,” the HTTP/2 maps are consistent in nomenclature to what you’re using today.
Enabling IPv6 shouldn’t negatively impact performance (if you do observe anything amiss, please let us know); most modern clients have implemented an approach known as Happy Eyeballs to connect over either IPv4 or IPv6, whichever is faster. IPv6 will be preferred over IPv4 when all else is equal, but enabling it doesn't penalize users in the process. For more background, check out this description of how IOS and OSX use the Happy Eyeballs methodology.
Dedicated map customers
Similar to our HTTP/2 rollout for dedicated certificate customers, you can ask us via support ticket to generate a new dualstack map (please specify if it needs to be global or us-eu only) for an existing map or CNAME. Additionally, if you’d like us to enable IPv6 announcements for a current map, let us know which one you’d like to enable via a support ticket and we’ll activate IPv6 on that map for you.
Anycast IPv6 addresses for Apex domains
If you use our Anycast IP addresses for Apex domains and are interested in IPv6 Anycast, please let us know via a support ticket, and we’ll provide the appropriate IPv6 Anycast addresses.
Geolocation functionality for IPv6
Our updated geolocation functionality supports geo ip data for IPv6, along with many new geo-related variables. These variables will live in a new namespace.
New VCL variable
Customers will be able to track whether a request came in as an IPv6 request with a new VCL variable, req.is_ipv6.
Once you’re up and running with IPv6, you can test with a command line dig to make sure your map is returning AAAA records:
‘dig jevans.freetls.fastly.net AAAA +short 2a04:4e42:5::591’