Google Cloud makes static external BYOIPv6 reservations generally available

Google Cloud marked static external IPv6 reservations from BYOIP sub-prefixes as generally available on 27 August 2026. For supported forwarding rules, operators can reserve address ranges from their own IPv6 space or promote an existing ephemeral range to static. This is catch-up coverage of the dated VPC release note.

What changed

The capability applies to sub-prefixes configured with EXTERNAL_IPV6_FORWARDING_RULE_CREATION. Its supported destinations are regional external passthrough Network Load Balancers and external protocol forwarding. Treat those service names as the scope of this release, rather than assuming every Google Cloud load balancer accepts the same address configuration.

Google's IPv6 sub-prefix documentation describes both reserving a range before creating a forwarding rule and promoting a range already assigned to a rule. Promotion prevents that range being released when the forwarding rule is deleted.

There is also an inventory detail to preserve: the IPv6 address entered for a reservation represents the base of a range. Its size follows the sub-prefix's allocatable prefix length. The reservation and public delegated prefix must be in the same region.

Why it matters for BYOIP

For infrastructure teams, this creates a useful separation between an application endpoint's address identity and the resource currently serving it. A practical use case is an endpoint referenced in partner allowlists: the desired design is to retain its address reservation while changing the service configuration around it.

That is an architectural implication, not a promise of a disruption-free migration. Keeping an address reserved does not establish that backends, firewall policy or deployment ordering are correct. Treat address retention and service availability as separate review items.

This is especially relevant when infrastructure as code manages forwarding rules. Before incorporating the capability, decide which module owns the reservation and whether replacing a service is allowed to destroy that reservation. The Google Cloud BYOIP profile provides the wider integration context.

What to check

• Confirm that the target is one of the supported forwarding-rule services and that the sub-prefix uses the required mode.
• Record the full reserved range in IPAM, including its base address, prefix length, region and owning service.
• Review existing ephemeral ranges before planning a replacement. Determine whether promoting the current range would better preserve external dependencies.
• In a test environment, inspect the planned changes for service replacement and deletion. Require explicit review for any operation that would release an address reservation.
• Document dependencies such as DNS records, partner allowlists and monitoring targets so a retained address does not hide an incomplete service migration.

Sources and further reading

The release note establishes the GA date. The linked sub-prefix guide supplies the configuration scope and reservation behavior; its page-update date is not the launch date.