--ipv6-network-tier STANDARD produces error

According to this page, IPv6 addresses are supported on Standard Tier networking in preview.

According to this page, gcloud beta supports the creation of VM instances with --ipv6-network-tier STANDARD.

Upon testing this, I get the following error:

C:\>gcloud beta compute instances create test1 --subnet subnet --stack-type IPV4_IPV6 --ipv6-network-tier STANDARD
ERROR: (gcloud.beta.compute.instances.create) Could not fetch resource:
 - Invalid value for field 'resource.networkInterfaces[0].ipv6AccessConfigs.networkTier': ''. Network tier in IPv6 access config must be PREMIUM.

I am aware that the feature is in preview, but nevertheless I am confused why I get an error message suggesting I am passing an empty string value to --ipv6-network-tier.

Is the cli tool passing an incorrect value for this parameter?

I don’t think your flag is wrong. The ‘’ in the error means the networkTier field in ipv6AccessConfigs reached the API empty, so gcloud isn’t putting --ipv6-network-tier into the request body for instances create.

I’d run gcloud components update first. Preview flags sometimes show up in the docs before the beta client actually passes them through. Then rerun with --log-http and look at networkInterfaces in the request. If networkTier is missing or empty there, it’s the CLI.

If it’s still empty after updating, skip gcloud and call the beta Compute API directly with the access config set yourself:

"ipv6AccessConfigs": [{"type": "DIRECT_IPV6", "networkTier": "STANDARD"}]

Also worth knowing: the --network-interface reference still says PREMIUM is the only supported value there. If the raw API call also says it must be PREMIUM, the preview probably isn’t enabled for your project or region yet, and it’s not a gcloud bug.

Thank you for your reply and suggestion of --log-http, which shows the cli tool is indeed passing the flag’s value. It is therefore the backend API claiming I tried to send an empty string when instead it would appear STANDARD is not yet supported.

I found this page which states the feature is in preview as of 05 October 2026. Nevertheless I tried multiple US regions and all were rejected in the same way. I had thought public preview stage meant that a feature was in a state for all customers to test but in this case it appears to be premature for me to do so.

I am confused why I get an error message suggesting I am passing an empty string value to --ipv6-network-tier.

Is the cli tool passing an incorrect value for this parameter?

gcloud is sending "networkTier": "STANDARD" as expected. The '' in the error message is a bug in how the Compute Engine API formats validation errors for ipv6AccessConfigs. Because ipv6AccessConfigs is a list field (ipv6AccessConfigs[0]) and the error path omits the [0] index (resource.networkInterfaces[0].ipv6AccessConfigs.networkTier), the API fails to extract the value from your request payload and prints ''.

Invalid value for field ‘resource.networkInterfaces[0].ipv6AccessConfigs.networkTier’: ‘’. Network tier in IPv6 access config must be PREMIUM.

For external IPv6, the network tier is configured on the subnet first rather than per VM, since each VM gets a /96 range from the subnet’s /64 external IPv6 prefix. My assumption is that --subnet subnet had external IPv6 enabled before the Standard Tier IPv6 preview rolled out, so the subnet doesn’t have the ipv6NetworkTier property set on it (which causes the API to default to requiring PREMIUM).

You can verify the subnet’s IPv6 configuration with:

gcloud beta compute networks subnets describe subnet \
  --region=<REGION> \
  --format="yaml(stackType,ipv6AccessType,ipv6NetworkTier,externalIpv6Prefix)"

A subnet’s external IPv6 network tier can’t be changed once its /64 prefix is allocated. To use Standard Tier IPv6 on a VM, you’ll need to either 1) create a new dual-stack subnet with --ipv6-network-tier=STANDARD or 2) update an existing IPV4_ONLY subnet to enable external IPv6 with --ipv6-network-tier=STANDARD:

gcloud beta compute networks subnets create subnet-ipv6-std \
  --network=<NETWORK> \
  --region=<REGION> \
  --range=10.0.10.0/24 \
  --stack-type=IPV4_IPV6 \
  --ipv6-access-type=EXTERNAL \
  --ipv6-network-tier=STANDARD

Once the subnet has ipv6NetworkTier: STANDARD, creating the VM on that subnet with --ipv6-network-tier=STANDARD will succeed:

gcloud beta compute instances create test1 \
  --subnet=subnet-ipv6-std \
  --stack-type=IPV4_IPV6 \
  --ipv6-network-tier=STANDARD

Good catch, zachs, that explains it better than my guess did. So the ‘’ is just the error formatting, and it’s the subnet’s ipv6NetworkTier that decides it. @triatic, worth running that subnets describe command on your current subnet. If ipv6NetworkTier is empty or PREMIUM there, a new dual-stack subnet with --ipv6-network-tier=STANDARD is the way to test the preview, since the tier can’t be changed once the /64 is allocated.

Thank you @zachs , you were spot on, it is indeed a subnet created a long time ago with --stack-type=IPV4_IPV6, and creating a new subnet as you suggested allows instance creation with --ipv6-network-tier=STANDARD.

I wouldn’t have worked this out by myself, a verbose error message from cli about the subnet being incompatible would have been hugely helpful, maybe that’s in the works?

Either way, much appreciated.