Subnets

Virtual Private Cloud (VPC) networks are global resources. EachVPC network consists of one or more IPaddress ranges calledsubnets. Subnets are regional resources, and have IPaddress ranges associated with them.

In Google Cloud, the termssubnet andsubnetwork are synonymous. Theyare used interchangeably in the Google Cloud console, Google Cloud CLI commands, andAPI documentation.

Networks and subnets

A network must have at least one subnet before you can use it. Auto modeVPC networks create subnets in each region automatically. Custommode VPC networks start with no subnets, giving you full controlover subnet creation. You can create more than one subnet per region. Forinformation about the differences between auto mode and custom modeVPC networks, seetypes of VPCnetworks.

When you create a resource in Google Cloud, you choose a network andsubnet. For resources other than instance templates, you also select azoneor a region. Selecting a zone implicitly selects its parent region. Becausesubnets are regional objects, the region that you select for a resourcedetermines the subnets that it can use:

• When youcreate a virtual machine (VM) instance,you select a zone for the instance. If you don't select a network for the VM,the default VPC network is used, which has a subnet in everyregion. If you do select a network for the VM, you must select a network thatcontains a subnet in the selected zone's parent region.

• When youcreate a managed instancegroup,you select a zone or region, depending on the group type, and an instancetemplate. The instance template defines which VPC network to use.Therefore, when you create a managed instance group, you must select an instancetemplate with an appropriate configuration; the template must specify aVPC network that has subnets in the selected zone or region. Automode VPC networks always have a subnet in every region.

• The process ofcreating a Kubernetes containerclusterinvolves selecting a zone or region (depending on the cluster type), anetwork, and a subnet. You must select a subnet that is availablein the selected zone or region.

Types of subnets

VPC networks support subnets with the following stack types.A single VPC network can contain any combination of thesesubnets.

Stack type	Subnet ranges	Compatible VM network interfaces
IPv4-only (single-stack)	Only IPv4 subnet ranges	IPv4-only interfaces
IPv4 and IPv6 (dual-stack)	Both IPv4 and IPv6 subnet ranges	IPv4-only, dual-stack, and IPv6-only interfaces
IPv6-only (single-stack)	Only IPv6 subnet ranges	IPv6-only interfaces

When you create a subnet, you specify which stack type to use. You can alsochange the stack type of a subnet in the following scenarios:

• If the subnet is IPv4-only, you canchange it to dual-stack.
• If the subnet is dual-stack and has an external IPv6 address range,you canchange it to IPv4-only.

Subnets with IPv6 address ranges are supported on custom mode VPCnetworks only. Subnets with IPv6 address ranges aren't supported on auto modeVPC networks or legacy networks.

Note: If you want to create subnets with IPv6 address ranges in an auto modeVPC network, you must firstconvert an auto mode VPC network tocustom mode.

When you create an IPv4 subnet range, you provide the following information:

Subnet setting	Valid values	Details
IPv4 range	Avalid range that you choose	Required
Secondary IPv4 range	Avalid range that you choose	Optional

When you create an IPv6 subnet range, you provide the following information:

Subnet setting	Valid values	Details
IPv6 access type	Internal External	A/64 IPv6 address range is assigned to the subnet. Internal IPv6 ranges are automatically assigned from the VPC network'sinternal range, which usesunique local addresses (ULAs) External IPv6 ranges useglobal unicast addresses (GUAs). The IP address range can be automatically assigned by Google Cloud, or you canspecify a range from a BYOIP IPv6 sub-prefix.

Purposes of subnets

Subnets can be used for different purposes:

• Regular subnets: This is the default subnet type. Regular subnets arecreated by users or automatically created in auto mode VPCnetworks to be used with VM instances. Regular subnets have a purpose ofPRIVATE in the gcloud CLI or API. The purpose isNone in theGoogle Cloud console.
• Private Service Connect subnets: A subnet to use topublish a managed service by using Private Service Connect.
• Proxy-only subnets: Aproxy-only subnet to use withregional Envoy-based load balancers.
• Private NAT subnets: A subnet that is reserved for use as thesource range forPrivate NAT.
• Peer migration subnets: A subnet to use tomigrate a Shared VPC service toPrivate Service Connect.
• Hybrid subnets: A subnet that logically extends to an on-premises or sourcenetwork, letting youmigrate workloads to Google Cloud without needingto change IP addresses.

In most cases, you cannot change the purpose of a subnet after it has beencreated. For more information, see thegcloud compute networks subnets updatecommand reference.

Limitations for naming subnets

Subnet names have the following limitations:

• Within a Google Cloud project, a subnet cannot have the same name as a VPCnetwork unless it is a member of that network. Within a project, subnets inthe same region must have unique names. For example, a network namedproduction can have multiple subnets also namedproduction as long aseach of those subnets is in a unique region.

• You cannot change the name or region of a subnet after you create it.However, you can delete a subnet and replace it as long as no resources areusing it.

IPv4 subnet ranges

Each IPv4-only or dual-stack subnet must have aprimary IPv4 address range. When a subnet'spurpose isPRIVATE orNONE, the primary IPv4 range can be usedby the following:

• Primary internal IPv4 addresses of Compute Engine VM networkinterfaces, including GKE nodes.
• Alias IP ranges of VM network interfaces.
• Forwarding rules used byinternal protocolforwarding.
• Forwarding rules used byinternal Application Load Balancers,internal proxy Network Load Balancers, andinternal passthrough Network Load Balancers.
• Cloud DNSinbound server policy entry points.
• Private Service Connectendpoints for published services.

Subnets can optionally have one or moresecondary IPv4 address ranges, whichcan only be used by alias IP ranges. An alias IP range can come from either theprimary IPv4 range or a secondary IPv4 range of a subnet.

Your IPv4 subnets don't need to form a predefined contiguous CIDR block, but youcan do that if you prefer. For example, auto mode VPC networks docreate subnets that fit within a predefined auto mode IP range. However, theprimary range of a subnet can be10.0.0.0/24, while the primary range ofanother subnet in the same network can be192.168.0.0/16.

Limitations for IPv4 subnet ranges

IPv4 subnet ranges have the following limitations:

• Each primary or secondary IPv4 range for all subnets in a VPCnetwork must be a uniquevalid CIDR block.

• The number of secondary IP address ranges you can define is described inper network limits.

• After you create a subnet, the primary IPv4 range for the subnetcan beexpanded but notreplaced or shrunk.

• You can remove and replace a subnet's secondary IPv4 address range onlyif no instances are using that range.

• The minimum primary or secondary range size is eight IPv4 addresses. Inother words, the longest subnet mask that you can use is/29.

• The shortest subnet mask that you can use is/4. However, for most/4 IP address ranges, additional validations prevent you from creatinga subnet that is this large. For example, a subnet range cannot overlapwith a private IPv4 range or other reserved range. To minimize the chanceof choosing an invalid subnet range, we recommend that you limit yourmaximum subnet size to/8.

• You can't create primary and secondary ranges for subnets that overlap with anyallocated range, any primary orsecondary range of another subnet in the same network, or any IPv4 rangesof subnets inpeered networks. Google Cloud preventsthe creation of overlapping subnet ranges in these scenarios.

• Google Cloud creates correspondingsubnetroutes for both primary and secondary IPranges. Subnet routes, and therefore subnet IP ranges, must have the mostspecific IP ranges by definition.

  • Ensure that primary and secondary ranges don't conflict with on-premises IP ranges ifyou have connected your VPC network to another networkwithCloud VPN,Dedicated Interconnect, or Partner Interconnect. For more information, seeCheck overlapping subnet ranges.

  • Subnet IPv4 ranges cannot conflict with destinations forstaticroutes.

  • Avoid using IPv4 addresses from the10.128.0.0/9 block for a subnet's primaryor secondary IPv4 ranges.Automatically created subnets in auto modeVPC networks use IPv4 addresses from this block.If you use IP addresses in the10.128.0.0/9 block, you cannot connect your network to an auto mode VPC networkusingVPC Network Peering or with Cloud VPN tunnels.

• Subnet ranges cannot match, be narrower, or be broader than arestrictedrange. For example,169.0.0.0/8 is not a valid subnetrange because it overlaps with the link-local range169.254.0.0/16 (RFC3927), which is a restricted range.

• Subnet ranges cannot span anRFC range (described in the previous table)and a privately used public IP address range. For example,172.0.0.0/10 isnot a valid subnet range because it includes both the172.16.0.0/12 privateIP address range and public IP addresses.

• Subnet ranges cannot span multiple RFC ranges. For example,192.0.0.0/8isn't a valid subnet range because it includes both192.168.0.0/16 (from RFC1918) and192.0.0.0/24 (from RFC 6890). However, you can create two subnetswith different primary ranges, one with192.168.0.0/16 and one with192.0.0.0/24. Or, you could use both of these ranges on the same subnet ifyou make one of them a secondary range.

Valid IPv4 ranges

A subnet's primary and secondary IPv4 address ranges are regional internal IPv4addresses. The following table describes valid ranges.

Range	Description
Private IPv4 address ranges
10.0.0.0/8 172.16.0.0/12 192.168.0.0/16	Private IP addressesRFC 1918 For information about using172.17.0.0/16, seeAdditional considerations.
100.64.0.0/10	Shared address spaceRFC 6598
192.0.0.0/24	IETF protocol assignmentsRFC 6890
192.0.2.0/24 (TEST-NET-1) 198.51.100.0/24 (TEST-NET-2) 203.0.113.0/24 (TEST-NET-3)	DocumentationRFC 5737
192.88.99.0/24	IPv6 to IPv4 relay (deprecated)RFC 7526
198.18.0.0/15	Benchmark testingRFC 2544
240.0.0.0/4	Reserved for future use (Class E) as noted inRFC 5735 andRFC 1112. Some operating systems don't support the use of this range, so verify that your OS supports it before creating subnets that use this range.
Privately used public IP address ranges
Privately used public IPv4 addresses	Privately used public IPv4 addresses: Are IPv4 addresses that are normally routable on the internet, but that are used privately in a VPC network Cannot belong to aprohibited subnet range When you use these addresses as subnet ranges, Google Cloud does not announce these routes to the internet and does not route traffic from the internet to them. If you have imported public IP addresses to Google usingBring your own IP (BYOIP), your BYOIP ranges and privately used public IP address ranges in the same VPC network must not overlap. ForVPC Network Peering, subnet routes for public IP addresses are not automatically exchanged. The subnet routes are automatically exported by default, but peer networks must be explicitly configured to import them in order to use them.

Prohibited IPv4 subnet ranges

Prohibited subnet ranges include Google public IP addresses and commonlyreserved RFC ranges, as described in the following table. These ranges cannot beused for subnet ranges.

Range	Description
Public IP addresses for Google APIs and services, including Google Cloud netblocks.	You can find these IP addresses athttps://gstatic.com/ipranges/goog.txt.
199.36.153.4/30 and 199.36.153.8/30	Private Google Access-specific virtual IP addresses
0.0.0.0/8	Current (local) networkRFC 1122
127.0.0.0/8	Local hostRFC 1122
169.254.0.0/16	Link-localRFC 3927
224.0.0.0/4	Multicast (Class D)RFC 5771
255.255.255.255/32	Limited broadcast destination addressRFC 8190 andRFC 919

Unusable addresses in IPv4 subnet ranges

Google Cloud uses the first two and last two IPv4 addressesin each subnet primary IPv4 address range to host the subnet.Google Cloud lets you use all addresses insecondary IPv4 ranges.

Unusable IPv4 address	Description	Example
Network address	First address in the primary IPv4 range	10.1.2.0 from range10.1.2.0/24
Default gateway address	Second address in the primary IPv4 range	10.1.2.1 from range10.1.2.0/24
Second-to-last address	Second-to-last address in the primary IPv4 range This range is reserved by Google Cloud for potential future use.	10.1.2.254 from range10.1.2.0/24
Broadcast address	Last address in the primary IPv4 range	10.1.2.255 from range10.1.2.0/24

Note: Google Cloud software-defined networking reserves a virtual gatewayIP address for the primary IP ranges of each subnet in a VPCnetwork. However, virtual gateways donot respond to ICMP traffic ordecrement IP TTL headers.

Subnet secondary IP ranges don't have a reserved virtual gateway IP address.Thus, a default gateway doesn't respond toping and doesn't appear when youruntraceroute from a VM instance.

Tools that ping the gateway IP address as a connectivity test must be configuredso that they don't consider the inability to ping a virtual gateway to be afailure condition.

Auto mode IPv4 ranges

This table lists the IPv4 ranges for the automatically created subnets in an automode VPC network. IP ranges for these subnets fit inside the10.128.0.0/9 CIDR block. Auto mode VPC networks are built withone subnet per region at creation time and automatically receive new subnets innew regions. Unused portions of10.128.0.0/9 are reserved for futureGoogle Cloud use.

Region	IP range (CIDR)	Default gateway	Usable addresses (inclusive)
africa-south1	10.218.0.0/20	10.218.0.1	10.218.0.2 to 10.218.15.253
asia-east1	10.140.0.0/20	10.140.0.1	10.140.0.2 to 10.140.15.253
asia-east2	10.170.0.0/20	10.170.0.1	10.170.0.2 to 10.170.15.253
asia-northeast1	10.146.0.0/20	10.146.0.1	10.146.0.2 to 10.146.15.253
asia-northeast2	10.174.0.0/20	10.174.0.1	10.174.0.2 to 10.174.15.253
asia-northeast3	10.178.0.0/20	10.178.0.1	10.178.0.2 to 10.178.15.253
asia-south1	10.160.0.0/20	10.160.0.1	10.160.0.2 to 10.160.15.253
asia-south2	10.190.0.0/20	10.190.0.1	10.190.0.2 to 10.190.15.253
asia-southeast1	10.148.0.0/20	10.148.0.1	10.148.0.2 to 10.148.15.253
asia-southeast2	10.184.0.0/20	10.184.0.1	10.184.0.2 to 10.184.15.253
australia-southeast1	10.152.0.0/20	10.152.0.1	10.152.0.2 to 10.152.15.253
australia-southeast2	10.192.0.0/20	10.192.0.1	10.192.0.2 to 10.192.15.253
europe-central2	10.186.0.0/20	10.186.0.1	10.186.0.2 to 10.186.15.253
europe-north1	10.166.0.0/20	10.166.0.1	10.166.0.2 to 10.166.15.253
europe-north2	10.226.0.0/20	10.226.0.1	10.226.0.2 to 10.226.15.253
europe-west1	10.132.0.0/20	10.132.0.1	10.132.0.2 to 10.132.15.253
europe-west2	10.154.0.0/20	10.154.0.1	10.154.0.2 to 10.154.15.253
europe-west3	10.156.0.0/20	10.156.0.1	10.156.0.2 to 10.156.15.253
europe-west4	10.164.0.0/20	10.164.0.1	10.164.0.2 to 10.164.15.253
europe-west6	10.172.0.0/20	10.172.0.1	10.172.0.2 to 10.172.15.253
europe-west8	10.198.0.0/20	10.198.0.1	10.198.0.2 to 10.198.15.253
europe-west9	10.200.0.0/20	10.200.0.1	10.200.0.2 to 10.200.15.253
europe-west10	10.214.0.0/20	10.214.0.1	10.214.0.2 to 10.214.15.253
europe-west12	10.210.0.0/20	10.210.0.1	10.210.0.2 to 10.210.15.253
europe-southwest1	10.204.0.0/20	10.204.0.1	10.204.0.2 to 10.204.15.253
me-central1	10.212.0.0/20	10.212.0.1	10.212.0.2 to 10.212.15.253
me-central2	10.216.0.0/20	10.216.0.1	10.216.0.2 to 10.216.15.253
me-west1	10.208.0.0/20	10.208.0.1	10.208.0.2 to 10.208.15.253
northamerica-northeast1	10.162.0.0/20	10.162.0.1	10.162.0.2 to 10.162.15.253
northamerica-northeast2	10.188.0.0/20	10.188.0.1	10.188.0.2 to 10.188.15.253
northamerica-south1	10.224.0.0/20	10.224.0.1	10.224.0.2 to 10.224.15.253
southamerica-east1	10.158.0.0/20	10.158.0.1	10.158.0.2 to 10.158.15.253
southamerica-west1	10.194.0.0/20	10.194.0.1	10.194.0.2 to 10.194.15.253
us-central1	10.128.0.0/20	10.128.0.1	10.128.0.2 to 10.128.15.253
us-east1	10.142.0.0/20	10.142.0.1	10.142.0.2 to 10.142.15.253
us-east4	10.150.0.0/20	10.150.0.1	10.150.0.2 to 10.150.15.253
us-east5	10.202.0.0/20	10.202.0.1	10.202.0.2 to 10.202.15.253
us-south1	10.206.0.0/20	10.206.0.1	10.206.0.2 to 10.206.15.253
us-west1	10.138.0.0/20	10.138.0.1	10.138.0.2 to 10.138.15.253
us-west2	10.168.0.0/20	10.168.0.1	10.168.0.2 to 10.168.15.253
us-west3	10.180.0.0/20	10.180.0.1	10.180.0.2 to 10.180.15.253
us-west4	10.182.0.0/20	10.182.0.1	10.182.0.2 to 10.182.15.253

Additional considerations

Ensure that all subnet primary and secondary IPv4 address ranges don'tconflict with the IPv4 address ranges that software runningwithin yourVMs needs to use. Some Google and third-party products use172.17.0.0/16 forrouting within the guest operating system. For example, thedefault Docker bridge network uses this range. If you depend on a product thatuses172.17.0.0/16, don't use it as any subnet primary and secondary IPv4address range.

IPv6 subnet ranges

When youcreate a subnet with an IPv6 address range or enable IPv6 on an existing subnetin a VPC network, you choose an IPv6 access type for thesubnet. The IPv6 access type determines whether the subnet is configured withinternal IPv6 addresses orexternal IPv6addresses.

• Internal IPv6 addresses are used for VM to VM communication withinVPC networks. They can only be routed within the scope ofVPC networks and cannot be routed to the internet.

• External IPv6 addresses can be used for VM to VM communication withinVPC networks, and are also routable on the internet.

If a VM interface is connected to a subnet that has an IPv6 subnet range, youcanconfigure IPv6 addresses on theVM. TheIPv6 access type of the subnet determines whether the VM is assigned an internalIPv6 address or an external IPv6 address.

IPv6 specifications

Subnets with IPv6 address ranges are available in all regions, supporting bothinternal and external IPv6 subnet ranges:

• Internal IPv6 subnet ranges are always automatically assigned byGoogle Cloud.
  • If you want to prevent the use of a specific IPv6 address range in aVPC network, you cancreate an internal range resourcethat is associated with the IPv6 address range.
• External IPv6 subnet ranges can be assigned automatically byGoogle Cloud, or you canbring your own IP addresses (BYOIP).
• IPv6 subnet ranges are always/64 ranges.

Subnets with IPv6 address ranges have the following limitations:

• BYOIP-provided external IPv6 subnet ranges only supportassigning/96 address ranges to VM network interfaces. IP addresses fromthe subnet's external IPv6 address range can't be assigned to otherGoogle Cloud resources such as forwarding rules.

• You cannot change the IPv6 access type (internal or external) of a subnet.

• You cannot change a dual-stack subnet to IPv4 only if the IPv6 accesstype is internal.

• You cannot change a dual-stack or IPv4-only subnet toIPv6-only. Conversely,you cannot change an IPv6-only subnet to IPv4-only or dual-stack.

Internal IPv6 specifications

Internal IPv6 ranges areunique local addresses(ULAs).ULAs for IPv6 are analogous toRFC 1918addressesfor IPv4. ULAs cannot be reached from the internet, and are not publiclyroutable.

Before you can create subnets with internal IPv6 ranges, you firstassign a/48 ULA IPv6 range to the VPCnetwork.Keep the following in mind when assigning a/48 ULA IPv6 range to aVPC network:

• The/48 ULA IPv6 range for each VPC network must be uniquewith Google Cloud. This eliminates the possibility of overlapping IPv6subnet ranges when usingVPC Network Peering.

• You can let Google Cloud assign the VPC network's/48ULA IPv6 range automatically, or you can provide a/48 ULA IPv6 range touse. If the/48 ULA IPv6 range you provide is already used by anotherGoogle Cloud VPC network, you receive an error.

• The option to provide a/48 ULA IPv6 range is useful to avoid conflictsbetween your VPC network and connected on-premises networks ornetworks in other cloud providers.

• After a VPC network has been assigned a/48 ULA IPv6 range,you can't remove or change the/48 ULA IPv6 range.

When you create a subnet with an internal IPv6 range, Google Cloudautomatically selects an unused/64 IPv6 range from the VPCnetwork's/48 ULA IPv6 range. Subnet internal/64 IPv6 ranges can be used bythe following:

• Internal/96 IPv6 address ranges of VM network interfaces

• Internal/96 IPv6 address ranges of forwarding rules forinternal protocolforwarding orinternal passthrough Network Load Balancers

Internal/96 IPv6 address ranges can be assigned in the following ways:

• If not specified, Google Cloud automatically assignsan ephemeral internal IPv6/96 address range.
• You can specify areserved static regional internal IPv6/96 address range.
• For VM instances and regional forwarding rules, you can specify a customephemeral internal IPv6/96 address range.

External IPv6 specifications

External IPv6 address ranges areglobal unicastaddresses (GUAs). External IPv6 addresses are availableonly inPremium Tier.

There are two options for creating a subnet with an external IPv6 address range:

• You can have Google Cloud automatically select an unused/64 IPv6range fromGoogle's regional external IPv6 addresses.

• You can assign a/64 IPv6 range from within aBYOIP sub-prefix, either specifying a particular rangeor letting Google Cloud select an unused range.

The resources that can use a subnet's external IPv6 address range depend on thesource of the address range.

• BYOIP-provided IPv6 subnet ranges can only be usedfor external/96 IPv6 address ranges of VM network interfaces. You canassign IPv6 BYOIP addresses to forwarding rules,but those addresses aren't part of a subnet.

• Google-provided external IPv6 subnet ranges can be used as follows:

  • External/96 IPv6 address ranges of VM network interfaces can use thefirst half (/65) of the subnet's/64 range.
  • External/96 IPv6 address ranges of forwarding rules forexternal protocolforwarding orbackend service-basedexternal passthrough Network Load Balancerscan use the second half (/65) of the subnet's/64 range.

  You must create the preceding resources using IP addresses from thecorresponding/65 range allocated for the resource; otherwise, Google Cloudreturns an error.

  Consider an example in which a subnet's external IPv6 address range is2001:db8:981:4:0:0:0:0/64:

  • The/65 range allocated for use by VM instances is2001:db8:981:4:0:0:0:0/65.
  • The/65 range allocated for use by Cloud Load Balancing is2001:db8:981:4:8000:0.

To check the source of a subnet's external IPv6 address range, you candescribe the subnet.If theipv6AccessType property isEXTERNAL and theipCollection propertyisn't empty, the subnet was created with an IPv6 BYOIP address range.

External/96 IPv6 address ranges can be assigned in the following ways:

• If not specified, Google Cloud automatically assignsan ephemeral external IPv6/96 address range.

• You can specify areserved static regional external IPv6/96 address range.If you reserve a static regional external IPv6/96 range from aBYOIP-provided IPv6 subnet range, you must specifyVM for the endpoint type.

• For VM instances and regional forwarding rules, you can specify a customephemeral external IPv6/96 address range.

IPv6 range assignment

IPv6 address ranges are assigned to networks, subnets, virtual machine instances(VMs), and forwarding rules.

Resource type	Range size	Details
VPC network	/48	To enableinternal IPv6 on a subnet, you must firstassign an internal IPv6 range on the VPC network. A/48 ULA range from withinfd20::/20 is assigned to the network. All internal IPv6 subnet ranges in the network are assigned from this/48 range. The/48 range can be automatically assigned, or you can select a specific range from withinfd20::/20.
Subnet	/64	The IPv6 access type setting controls whether the IPv6 addresses are internal or external. A subnet can have either internal or external IPv6 addresses, but not both. When you enable IPv6, the following occurs: If you enable internal IPv6 on a subnet, a/64 range of internal ULAs is assigned from your VPC network's/48 range. If you enable external IPv6 on a subnet, a/64 range of external GUAs is assigned in one of the following ways: Google Cloud automatically assigns the range. Additionally, Google Cloud allocates each half of the/64 range for a specific purpose as follows: The/65 range that represents the first half of the subnet is allocated for VM instances. The/65 range that represents the second half of the subnet is allocated for Cloud Load Balancing. Alternatively, you can allocate a range from a BYOIP IPv6 sub-prefix in subnet creation mode.
VM instance	/96	When you configure a dual-stack or IPv6-only network interface on a VM, the interface is assigned a/96 IP address range from the interface's subnet. Google Cloud provides the first IP address in the/96 range by using DHCPv6. Whether a VM network interface uses an internal or external IPv6/96 address range depends on the IPv6 access type of the interface's subnet.
Forwarding rule for an internal passthrough Network Load Balancer, external passthrough Network Load Balancer, or protocol forwarding	/96 or specified by a BYOIP sub-prefix	The IPv6 address range of a forwarding rule for internal protocol forwarding or an internal passthrough Network Load Balancer is an internal/96 IP address range from a subnet's internal IPv6 address range. Internal/96 IP address ranges can be selected automatically by Google Cloud or you canreserve a static regional internal IPv6/96 address range. The IPv6 address range of a forwarding rule for external protocol forwarding or an external passthrough Network Load Balancer is one of the following: If using Google-provided external IPv6 addresses, the IPv6 address range is an external/96 address range selected automatically by Google Cloud from a subnet's external IPv6 address range. If using BYOIP external IPv6 addresses, the IPv6 address range comes from aBYOIP IPv6 address sub-prefix in forwarding rule creation mode. The size of the IPv6 range is determined by the allocatable prefix length of the sub-prefix.

Unusable addresses in IPv6 subnet ranges

The first and last/96 range of a subnet's internal/64 range cannot be specifiedmanually because Google Cloud reserves the first and last/96 range of a subnet'sinternal/64 range for system use. You can manually specify any other valid/96 IPv6range from the subnet's internal/64 range to be assigned to your VM network interfaces.

Unusable IPv6 address	Description	Example
The first/96 range from the subnet's internal/64 IPv6 range	Reserved for system use	fd20:db8::/96 from rangefd20:db8::/64
The last/96 range from the subnet's internal/64 IPv6 range	Reserved for system use	fd20:db8:0:0:ffff:ffff::/96 from rangefd20:db8::/64

What's next

• Learn more aboutGeography and regions

• Create VPC networks

• Assign an internal IPv6 range for a VPC network

• Create a subnet

• Learn aboutusing a hybrid subnet to migrate workloads to a VPC network without changing IP addresses

Try it for yourself

If you're new to Google Cloud, create an account to evaluate how Cloud NAT performs in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

Try Cloud NAT free