{"id":111598,"date":"2024-09-19T06:00:00","date_gmt":"2024-09-19T13:00:00","guid":{"rendered":"https:\/\/www.backblaze.com\/blog\/?p=111598"},"modified":"2025-12-11T12:38:57","modified_gmt":"2025-12-11T20:38:57","slug":"announcing-support-for-ipv6","status":"publish","type":"post","link":"https:\/\/www.backblaze.com\/blog\/announcing-support-for-ipv6\/","title":{"rendered":"Announcing Support for IPv6"},"content":{"rendered":"\r\n
\"An<\/figure>\r\n\r\n\r\n\r\n
\u00a0<\/div>\r\n\r\n\r\n\r\n

If your systems are IPv6-enabled or enabling IPv6 is on your roadmap, good news\u2014starting yesterday and continuing over the course of the next few weeks, Backblaze will be \u201cflipping the switch\u201d and turning on IPv6 for our S3 Compatible API. While our IPv6 deployment isn\u2019t completely done yet (we\u2019re phasing the roll out through our environment), we thought we\u2019d share some of the decisions we made that affect performance and functionality.\u00a0\u00a0\u00a0<\/p>\r\n\r\n\r\n\r\n

Today, I\u2019ll talk a little bit more about our choices along the way, and answer some questions that might come up about how we\u2019re supporting the protocol (jump to the FAQ<\/a> for that).<\/p>\r\n\r\n\r\n\r\n

\r\n

Hi, I’m Anthony<\/h4>\r\nSince this is the first time you\u2019re hearing from me, I thought I should introduce myself. I\u2019m a senior network engineer here at Backblaze. The Network Engineering group is responsible for ensuring the reliability, capacity, and security of network traffic, and that includes our IPv6 deployment.<\/div>\r\n\r\n\r\n\r\n

What is IPv6 and why did we enable it?<\/h2>\r\n\r\n\r\n\r\n

Internet protocol version 6 (IPv6) is replacing internet protocol version 4 (IPv4) as the standard for IP addresses. Most of the internet uses IPv4, and this protocol has been reliable and resilient for over 20 years. However, IPv4 has limitations that might cause problems as the internet expands\u2014namely, there aren\u2019t enough IPv4 addresses to go around<\/a>.\u00a0<\/p>\r\n\r\n\r\n\r\n

Demand for IPv6 is continuing to increase exponentially. A major factor in this is the combination of the continually growing population and the number of connected devices a given person carries. One study from 2020<\/a> suggests the average number of connected devices per person globally was 2.4 in 2018, and forecasted to be 3.6 in 2023. Specifically for North America, the study suggests 8.2 connected devices in 2018 and a whopping 13.4 in 2023! Every device connected to the internet needs an IP address, and the finite address space of IPv4 it is simply no longer sufficient. The key to IPv6 enhancement is the expansion of the IP address space from 32 bits to 128 bits, enabling virtually unlimited, unique IP addresses.<\/p>\r\n\r\n\r\n\r\n

Support for IPv6 means our customers can reach our services in the most efficient and secure way possible.<\/p>\r\n\r\n\r\n\r\n

Why should you care about us deploying IPv6?<\/h2>\r\n\r\n\r\n\r\n

We\u2019ve learned some things over the years, so we approached our IPv6 deployment a little differently than our IPv4 deployment. If you\u2019re a customer or potential customer, here\u2019s what that means for you:\u00a0<\/p>\r\n\r\n\r\n\r\n

    \r\n
  1. No action needed on your part:<\/strong> Unlike some of the traditional cloud providers, we chose to use the same endpoint URL and let the client choose whether or not to use IPv6. This allows for any systems already IPv6 enabled to benefit immediately. In fact, if your systems are IPv6 enabled and you are a B2 customer using the S3 compatible API, you might already be connecting to us over IPv6 now.<\/li>\r\n\r\n\r\n\r\n
  2. Our deployment is better set up to scale:<\/strong> Because of the way we decided to assign virtual IPs (VIPs) to our API endpoints, we have more flexibility to distribute ingress traffic and the ability to add VIPs as we need to in the future.<\/li>\r\n\r\n\r\n\r\n
  3. Improved network performance and simpler network management:<\/strong> With IPv6, we simplified IP assignments and reduced the need for customers to use Network Address Translation<\/a> (NAT). NAT adds processing overhead to network traffic as it translates IP addresses, which can lead to latency issues, especially with high-volume data transfer. The less traffic you have to NAT, the better. On our end, there is no NAT with customer data flows regardless of IPv4 vs IPv6. We also made the decision to route traffic before using network switches, this helps with reducing IPv6 multicast \u201cnoise\u201d and generally helps keep the \u201cwire\u201d cleaner.<\/li>\r\n<\/ol>\r\n\r\n\r\n\r\n

    And here\u2019s how we got it all done.<\/p>\r\n\r\n\r\n\r\n

    If a VIP could only talk<\/h2>\r\n\r\n\r\n\r\n

    First, a little background: Backblaze offers two APIs\u2014the Backblaze S3 Compatible API<\/a> and the Backblaze B2 Native API<\/a>. You can learn more about our APIs here in our documentation<\/a>, but a couple differences are important to note when it comes to our IPv6 deployment:<\/p>\r\n\r\n\r\n\r\n