Bring your own IP addresses

Bring your own IP addresses (BYOIP) lets you provision and use your own public IPv4 addresses for Google Cloud resources. After the IP addresses are imported, Google Cloud manages them in the same way as Google-provided IP addresses, with these exceptions:

• The IP addresses are available only to the customer who brought them.

• There are no charges for idle or in-use IP addresses.

Warning: Google does not support overlapping BYOIP route announcements. For example, importing 203.0.112.0/23 is not supported if 203.0.112.0/23 or a subset of this prefix, such as 203.0.112.0/24, is advertised outside Google. If Google and another network advertise the same route with matching or mismatched prefix lengths, you might experience unexpected routing and packet loss.

Overview

To bring your own IP to Google, you create a public advertised prefix (PAP). Verification of ownership is done for this public advertised prefix using ROA and reverse DNS validation. After verification is complete, we configure the announcement of this prefix to the internet, but the prefix is not advertised until it is provisioned. It takes approximately four weeks for the public advertised prefix to be provisioned.

While you wait for the public advertised prefix to provision, you split the prefix into public delegated prefixes (PDPs). You can then either divide the public delegated prefix further or use it to create assignable IP addresses. It takes approximately four weeks for the public delegated prefix to be provisioned.

After provisioning of the public delegated prefix is complete, the public advertised prefix is advertised to the internet.

Figure 1. Workflow for creating public advertised prefixes and public delegated prefixes.

Public advertised prefixes

A public advertised prefix (PAP) is a resource in Compute Engine that represents an IP prefix that you bring to Google Cloud. This lets you allocate IP addresses from your own prefix to Google Cloud resources. The public advertised prefix is a single unit of route advertisement. Google's global backbone advertises the public advertised prefix from all of its points of presence. IP addresses in the public advertised prefix always use the Premium Tier of Network Service Tiers.

A public advertised prefix can be used to either create global public delegated prefixes or regional public delegated prefixes, but not both.

If your public advertised prefix was created before July 10, 2023, see Behavior changes for BYOIP.

Public delegated prefixes

A public delegated prefix (PDP) is an IP address block within your public advertised prefix that is configured within a single scope (a specific region or global). The IP blocks must be delegated and assigned to a scope before you can allocate IP addresses to your project or organization.

Creation of global public delegated prefixes is controlled by an allowlist. For more information, see Global public delegated prefixes.

You can break up a single public delegated prefix into multiple smaller blocks, but these blocks must have the same scope as the parent block. You can configure multiple non-contiguous public delegated prefixes in a given scope. These smaller blocks are public delegated prefixes, but are also referred to as sub-prefixes.

Global public delegated prefixes

To create a global public delegated prefix, you must use a public advertised prefix that is used to create only global public delegated prefixes. You must create the public delegated prefix in a project that has been given access to create global prefixes.

To request access, file a support case to request that your project be added to the allowlist for global public delegated prefix creation.

IP addresses

When you create IP addresses from a public delegated prefix or sub-prefix, the IP addresses can be used only within the project and scope that they are allocated to. All IP addresses in the public delegated prefix or sub-prefix are made available; there is no reserved network address or broadcast address. For example, if you use a /28 public delegated prefix or sub-prefix to create IP addresses, 16 IP address resources are created.

Anyone who has the appropriate IAM permissions in the project can use the IP addresses:

• compute.addresses.* for regional IP addresses

• compute.globalAddresses.* for global IP addresses

Bring your own IP configurations

The following tables summarize the available bring your own IP configurations.

Note: Public advertised prefixes created before July 2023 can contain both regional and global public delegated prefixes. Any public advertised prefixes created after this date can be used to create either global or regional public delegated prefixes.

Configuration	Regional (v2)	Regional (v1)	Global (v1)
Availability	Recommended regional configuration	Not recommended for new regional configurations	Must request adding your project to an allowlist
Public advertised prefix provisioning time	Approximately 2 weeks	Approximately 4 weeks	Approximately 4 weeks
Public delegated prefix provisioning time	A few minutes	4 weeks Can overlap with public advertised prefix provisioning time	4 weeks Can overlap with public advertised prefix provisioning time
Sub-prefix provisioning time	A few minutes	A few minutes	A few minutes
BGP announcement	The public advertised prefix is not automatically announced when it is provisioned. You decide when to announce or withdraw advertisement.	The public advertised prefix is automatically announced after provisioning completes.	The public advertised prefix is automatically announced after provisioning completes.
IP stack	IPv4 IPv6 (for external passthrough Network Load Balancer only)	IPv4	IPv4

IPv4 prefixes

The following table summarizes the CIDR range requirements for IPv4 prefixes.

Configuration	Regional (v2)	Regional (v1)	Global (v1)
Public advertised prefix	/16 to /24	/16 to /24	/16 to /24
Public delegated prefix (top-level, not sub-prefix)	/16 to /28 Can be the same size or smaller (have a longer prefix length) than the public advertised prefix	/17 to /28 Must be smaller (have a longer prefix length) than the public advertised prefix	/17 to /28 Must be smaller (have a longer prefix length) than the public advertised prefix
Sub-prefix	Can be the same size or smaller (have a longer prefix length) than the parent public delegated prefix Minimum size (maximum prefix length) is /28	Can be the same size or smaller (have a longer prefix length) than the parent public delegated prefix Minimum size (maximum prefix length) is /28	Can be the same size or smaller (have a longer prefix length) than the parent public delegated prefix Minimum size (maximum prefix length) is /28

IPv6 prefixes

The following table summarizes the CIDR range requirements for IPv6 prefixes.

Configuration	Regional (v2)
Public advertised prefix	Minimum size (maximum prefix length) is /48
Public delegated prefix (top level, not sub-prefix)	Can be the same size or smaller (have a longer prefix length) than the parent public advertised prefix Valid lengths: /32, /40, /48, or /56 The difference between the prefix length of a top level public delegated prefix and its parent public advertised prefix can't be greater than 24
Sub-prefix	Can be the same size or smaller (have a longer prefix length) than the parent public delegated prefix Valid lengths: /32, /40, /48, /56, /64, or /72 The difference between the prefix length of a sub-prefix and its parent public delegated prefix can't be greater than 24
Allocatable prefix for forwarding rules	Must be smaller than the parent public delegated prefix—the difference between the allocatable prefix length and the parent sub-prefix length must be at least 8, and can't be greater than 32 Default lengths: If the parent sub-prefix's length is /64 or /72, the default allocatable prefix length is /96 Otherwise, the default allocatable prefix length is /64

Limitations

• Provisioning time takes multiple weeks and cannot be accelerated. For more information about provisioning time, see Bring your own IP configurations.

• A public delegated prefix can be sub-delegated up to three times from a public advertised prefix. For more information, see Create sub-prefixes.

• When you create IPv4 addresses from a public delegated prefix, the group of addresses can have length /17 to /28. You can't create a smaller group of addresses, for example, a single /32 address.

• If you use privately used public IP address ranges for any subnets in your VPC networks, your imported BYOIP prefixes must not overlap with these IP address ranges. Don't use any part of an imported BYOIP prefix as a primary or secondary IPv4 subnet range.

• You can't create global IPv6 BYOIP addresses, or use IPv6 BYOIP addresses with VMs. IPv6 BYOIP prefixes support only regional addresses, and can be used only for forwarding rules for external passthrough Network Load Balancer.

• Not all resources support using BYOIP addresses. For more information, see Support for BYOIP addresses.

Support for BYOIP addresses

IPv4 BYOIP addresses can be used with most resources that support static external IP addresses. However, there are some exceptions:

• Cloud VPN supports using an IPv4 BYOIP address as the peer IP address of a Classic VPN gateway tunnel. However, you cannot use a BYOIP address as the peer IP address of an HA VPN gateway tunnel.

• Cloud VPN does not support using an IPv4 BYOIP address as the external IP address of Classic VPN or HA VPN gateway tunnels.

• You can't use v2 regional BYOIP addresses with regional external Application Load Balancers or regional external proxy Network Load Balancers.

• You can create IPv4 BYOIP addresses in Shared VPC host projects and use the host project IP addresses in the service projects. However, Shared VPC does not support creating BYOIP addresses in service projects.

• You can use IPv4 BYOIP addresses to create external forwarding rules used with GKE ingress for external Application Load Balancers. However, Google Kubernetes Engine nodes and Pods don't support BYOIP addresses.

• Stateful managed instance groups (MIGs) support using IPv4 BYOIP addresses for configuring static IP addresses on VM creation in a MIG. However, MIGs that automatically allocate IP addresses to VMs don't support BYOIP.

IPv6 BYOIP addresses can be used for forwarding rules for external passthrough Network Load Balancer only.

Public IP Admin role

You can designate an administrator for your BYOIP prefixes and addresses by assigning them the Compute Public IP Admin role (roles/compute.publicIpAdmin). This role lets them manage publicly routable IP addresses in your organization.

The Public IP Admin can do the following tasks:

• Configure public advertised prefixes in a project they own.
• Configure the public advertised prefixes into public delegated prefixes in a project they own.
• Delegate sub-prefixes from the public delegated prefixes to specific projects in the organization.
• Revoke sub-prefixes that were previously delegated from the public delegated prefixes to a specific project in the organization.
• Delete public delegated prefixes.

Open ports on BYOIP addresses

Running a port scan on a BYOIP address might return unexpected results. Global BYOIP addresses are implemented by an infrastructure service called the Google Front End (GFE). A BYOIP address, even if it is unused, might appear to have open ports because those ports are used by other Google services that also share the GFE. Traffic to these ports is dropped and not logged.

Only supported load balancers can use global IP addresses. For more information about open ports on load balancers, see the following:

• Open ports on external Application Load Balancers
• Open ports on external proxy Network Load Balancers

Quotas and limits

There are quotas and limits for public delegated prefixes and public advertised prefixes. For more information, see VPC quotas and limits.

What's next

• Planning your bring your own IP deployment
• Create a public advertised prefix