Service eligibility and regional restrictions
PuppyIP serves only compliant overseas businesses and their authorized personnel. Proxy services are not available in mainland China. The service may only be used for lawful business activities outside mainland China. Use of this service within mainland China is prohibited.
Hosting a proxy IP or server overseas does not change these restrictions. The service must not be provided to end users in mainland China through relaying, forwarding, sharing or resale. Before use, read the Terms of Service.
Key Takeaways
- The November 6 announcement covers regional external and internal Application and proxy Network Load Balancers, plus cross-region internal Application and proxy Network Load Balancers.
- The client-to-load-balancer connection and the backend connection are independent. Backend connections use IPv4 by default, so you do not have to convert backends to IPv6 just to accept IPv6 clients.
- For this client-IPv6 support, the proxy-only subnet can use IPV4_ONLY or IPV4_IPV6; that setting is separate from the IPv6 address on a front-end forwarding rule.
- If the load balancer must also connect to backends over IPv6, check the separate dual-stack backend requirements for supported instance groups or zonal NEGs with GCE_VM_IP_PORT endpoints.
What became GA on November 6
The Google Cloud Load Balancing release notes announced on November 6, 2026, that front-end configuration for incoming IPv6 traffic is generally available for six load balancer types: regional external Application Load Balancers, regional external proxy Network Load Balancers, regional internal Application Load Balancers, regional internal proxy Network Load Balancers, cross-region internal Application Load Balancers, and cross-region internal proxy Network Load Balancers.
Treat those six as the scope named in this GA announcement. The broader IPv6 overview also lists other supported types, including global external and classic load balancers, but they are not in the November 6 list of newly GA types. Do not expand the announcement into a claim that every load balancer became GA that day. Check project eligibility, regions, quotas, and charges for the target product; the GA date does not establish one activation time for every project.
The client and backend connections are separate
Application Load Balancers and proxy Network Load Balancers terminate a client connection and then open a new connection to a backend. An IPv6 client means the first leg uses IPv6; it does not determine the address family of the separate load-balancer-to-backend leg.
Backend connections use IPv4 by default, and an IPv4-only backend can still receive them. Enabling an IPv6 front end does not require you to convert virtual machines, applications, or every backend endpoint to IPv6. To serve both IPv4 and IPv6 clients, you can configure separate IPv4 and IPv6 front-end addresses and forwarding rules on the same load balancer.
The proxy-only subnet does not have to become dual-stack
The release note says the proxy-only subnet can have either the IPV4_ONLY or IPV4_IPV6 stack type to support IPv6 client traffic. Do not read client-side IPv6 as a requirement for the proxy-only subnet itself to already have IPv6 addresses.
A proxy-only subnet is a dedicated resource used by proxy load balancers. The IPv6 front-end address is configured on a forwarding rule. These resources have different roles: do not treat the proxy-only subnet's stack setting as the front-end address configuration, or confuse either setting with IPv6 support on backends.
Check the address and subnet for the front-end type
Accepting IPv6 client connections requires an IPv6 address on the forwarding rule. The IPv6 overview says global external load balancers use a /64 address range for front-end rules, while regional external and internal load balancers use a /96 prefix. First distinguish global external, regional external, and internal front ends; these ranges are not interchangeable single-address settings.
A regional external front-end IPv6 address comes from a custom-mode dual-stack or IPv6-only subnet with EXTERNAL access type. An internal front end uses a custom-mode dual-stack or IPv6-only subnet with INTERNAL access type. In both cases, the subnet stack type can be IPV4_IPV6 or IPV6_ONLY. These front-end subnet requirements are separate from the proxy-only subnet setting above.
Check dual-stack support only if backends also need IPv6
If the application or network design requires IPv6 from the load balancer to its backends, configure the backend service's IP address selection policy separately and confirm the backend type is supported. Google Cloud lists VM instance groups and zonal network endpoint groups (NEGs) with GCE_VM_IP_PORT endpoints as supporting dual-stack backends.
This does not mean every NEG automatically supports dual stack. Classic Application Load Balancers and classic proxy Network Load Balancers also do not support dual-stack backends. Treat backend IPv6 as a separate optional change: check the load balancer type and endpoint type first, then decide whether the backend network needs to change. Adding an IPv6 front end does not perform that work for you.
Separate forwarding rules, client paths, and HTTP headers
Before a change, record the load balancer type, front-end address, forwarding rules, and proxy-only subnet setting. Decide whether the service needs IPv4 clients, IPv6 clients, or both. If it needs both, review each front-end rule and whether DNS should publish the intended IPv6 address in an AAAA record.
For Application Load Balancers, the HTTP X-Forwarded-For header can carry client address information as observed by the load balancer. A client or an intervening proxy may already have added other elements. Parse the header only according to a defined trusted-proxy boundary; do not treat an arbitrary first value as verified identity. This HTTP-header guidance applies to Application Load Balancers, not TCP proxy Network Load Balancers.
Sources
Frequently Asked Questions
Does this GA announcement include passthrough Network Load Balancers?
They are not among the six proxy load balancer types in the November 6 announcement. Google Cloud's IPv6 overview documents IPv6 support for passthrough Network Load Balancers separately, but their forwarding model and configuration path differ. Use the relevant passthrough load balancer documentation.
Does GA mean the same region, project, and pricing conditions apply everywhere?
That cannot be inferred. The release notes and IPv6 guide reviewed here describe the feature scope and connection behavior, but do not confirm every project's eligibility, availability in every region, quotas, or charges. Before implementation, check current product documentation, quotas, and pricing for the target load balancer type.