IPv6 Termination for HTTP(S), SSL Proxy, and TCP Proxy Load Balancing

Google Cloud Platform (GCP) supports IPv6 clients with HTTP(S), SSL proxy, and TCP proxy load balancing. The load balancer accepts IPv6 connections from your users, then proxies those connections to your instances.


You can configure both IPv4 and IPv6 external addresses for HTTP(S), SSL proxy, and TCP proxy load balancers.

Global IPv6 load balancing (click to enlarge)
Global IPv6 load balancing (click to enlarge)

IPv6 termination for HTTP(S), SSL proxy, and TCP proxy load balancing enables you to handle IPv6 requests from your users and proxy them over IPv4 to your backends.

  • Use a single anycast IPv6 address for multi-region deployment: You only need one load balancer IPv6 address for application instances running across multiple regions. This means that your DNS server has a single AAAA record and that you don't need to load balance among multiple IPv6 addresses. Caching of AAAA records by clients is not an issue since there's only one address to cache. User requests to the IPv6 address are automatically load balanced to the closest healthy instance with available capacity.
  • Load balance HTTP, HTTPS, HTTP/2, TCP, and SSL/TLS IPv6 client traffic.
  • Overflow across regions with a single IPv6 load balancer address: If instances in one region are out of resources or unhealthy, the global load balancer automatically directs requests from users to the next closest region with available resources. Once the closest region has available resources, global load balancing reverts back to serving via this region.
  • Run dual stack: To serve both IPv6 and IPv4 clients, create two load balancer IP resources—one for IPv6 and the other for IPv4—and associate both with the same IPv4 application instances. IPv4 clients connect to the IPv4 address while IPv6 clients connect to the IPv6 address. These clients are then automatically load balanced to the closest healthy instances with available capacity. We provide IPv6 forwarding rules without charge, so you pay for only the IPv4 ones.
    Directing IPv4 and IPv6 traffic to the same backend instances (click to enlarge)
    Directing IPv4 and IPv6 traffic to the same backend instances (click to enlarge)

IPv6 termination and proxy

Configuring IPv6 termination for your load balancers lets your backend instances appear as IPv6 applications to your IPv6 clients.

IPv6 termination for load balancing (click to enlarge)
IPv6 termination for load balancing (click to enlarge)

When a user connects to the load balancer via IPv6, the following happens:

  1. Your load balancer, with its IPv6 address and forwarding rule, waits for user connections.
  2. An IPv6 client connects to the load balancer via IPv6.
  3. The load balancer acts as a reverse proxy and terminates the IPv6 client connection. It places the request into an IPv4 connection to a backend.
  4. On the reverse path, the load balancer receives the IPv4 response from the backend, then places it into the IPv6 connection back to the original client.

IPv6 address allocation for load balancer forwarding rules

When you configure an HTTP(S), SSL proxy, or TCP proxy load balancer, you provide it with one or more global forwarding rules, each with an external, publicly routed IPv4 or IPv6 IP address. You can use this IP address in the DNS records for your site.

When you create a forwarding rule, you can either use a static IP address reserved for your project or you can have the forwarding rule automatically acquire an ephemeral IP address when you create the rule. A static IP address is reserved to your project, and you can keep it until you deliberately release it. An ephemeral address belongs to the forwarding rule as long as the forwarding rule exists. If you delete the forwarding rule, the ephemeral address is released back into the GCP pool.

If you need both an IPv4 and IPv6 address for your load balancer, you can create two forwarding rules, associating an IPv4 address with one and an IPv6 address with the other. You can then associate both rules with the same load balancer.

Client IP header with IPv6 termination for HTTP(S) load balancing

When the load balancer proxies the IPv6 connection from the client to an IPv4 connection to your backend, the original source IP address is replaced with the load balancer's IP address. However, backends often need to know the original source IP for logging, for decision making, or for other purposes. GCP provides an HTTP header that is propagated to the backends that includes the original IPv6 client IP.

HTTP headers for IPv6 are similar to those for IPv4. The format for requests is:

  • X-Forwarded-For: <client IP(s)>, <global forwarding rule external IP>
  • The last element shows the load balancer IP. The second to last element shows the client IP as seen by the load balancer. There may be other elements in the X-Forwarded-For header in cases where the client or intervening proxies add other X-Forwarded-For headers before sending the request to the load balancer.

An example X-Forwarded-For header may look like this:

X-Forwarded-For: 2001:db8:abcd:1::1234, 2607:f8b0:4005:801::200e

The first (second-to-last) address is the client’s IPv6 address. The second address is the IPv6 address of the HTTP(S) load balancer.


Forwarding rules for IPv6 termination are provided at no additional cost. You are not charged for ephemeral IPv6 addresses. Reserved IPv6 addresses are charged at existing rates regardless of whether they are in use or not. The rest of the pricing is the same as that for IPv4 load balancing. View load balancing pricing details here.

What's next

Monitor your resources on the go

Get the Google Cloud Console app to help you manage your projects.

Send feedback about...

Compute Engine Documentation