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.

Live migration lets you control when Google starts advertising routes for your prefix. Live migration is not available by default. To request access, contact your Google Cloud customer engineer.

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 up to 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 (PDP). You can then either divide the public delegated prefix further or use it to create assignable IP addresses. It takes up to four weeks for the public delegated prefix to be provisioned.

Once provisioning of the public delegated prefix is complete, the public advertised prefix is advertised to the internet. If you're using live migration, see Use live migration for additional steps.

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.

When creating a new public advertised prefix, it must have an IPv4 IP range with a minimum CIDR range of size /24. A smaller CIDR range, for example /25, cannot be created as a new public advertised prefix. However, once created, you can break up a public advertised prefix, say a /24 or /23, into smaller public delegated prefixes.

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.

Creating global public delegated prefixes is restricted. 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 allowlisted 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

Behavior changes for BYOIP

The following behavior changes take effect on July 10, 2023:

  • A public advertised prefix can be used to create either global public delegated prefixes or regional public delegated prefixes, but not both.
  • Public advertised prefixes that were created before July 10, 2023 can be used to create regional public delegated prefixes only.
  • To create global public delegated prefixes, you must request access.

Any existing global public delegated prefix configurations are not affected.

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:

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 IPs 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.

Planning your deployment

It's important to plan your deployment, because provisioning and deletion processes require several weeks to complete. For more information about the provisioning timeline and allowed prefix sizes, see Limitations.

Here are some decisions that should be considered when you plan your deployment:

  • Who is responsible for administering BYOIP addresses? This is typically an admin or group, but is not typically the same users who manage individual projects. Use IAM roles and permissions to distinguish who has privileges for the public advertised prefixes and public delegated prefixes that you plan to provision.

  • How are prefixes managed? It is likely that you want to use your BYOIP addresses in different projects. You can manage prefixes centrally in a project distinct from the ultimate destinations of the IP addresses. We recommend that you isolate prefix administration in a project of its own, including its own users and groups with Public IP Admin permissions. This isolation helps to prevent confusion about prefix administration and inadvertent or unauthorized use of prefixes. For more information, see Project architecture.

  • How are prefixes named? Every BYOIP resource (public advertised prefix, public delegated prefix, sub-prefix) requires a name, and the name is used to manage each resource. You assign the name during resource creation, and names can't be changed without deleting and recreating the resource. For this reason, we recommend that you create names that are easy to manage. For example, pap-203-0-113-0-24, pdp-203-0-113-0-25, sub-203-0-113-0-28, where the letters denote the resource type, and the numbers denote the specific prefix and prefix length.

  • Where are the IP addresses provisioned? It's useful to think of the provisioning process as "stocking" IPs into regions (or the global scope). The provisioning process for stocking IP addresses takes several weeks to complete, so it's useful to plan and deploy public delegated prefixes long before they are needed.

    You don't have to use all IPs in a public delegated prefix immediately. If you aren't sure where you need them, provision only the public delegated prefixes that you're certain you need to use. Moving a public delegated prefix requires complete deletion and then recreation, which can take up to eight weeks.

    After public delegated prefix provisioning is complete, you can delegate sub-prefixes to projects and create addresses for use with resources. If you anticipate needing BYOIP addresses in a region, complete the public delegated prefix provisioning process in advance, so you can later fulfill addressing needs on-demand.

    For example, if you need some IP addresses in us-central1 and some IP addresses for global load balancers, and you want to reserve some IP addresses for the future, you should create the following plan.

    Prefix type Prefix Scope
    Public advertised prefix 203.0.113.0/24
    Public advertised prefix for global load balancers 192.0.2.0/24
    Public delegated prefix 203.0.113.0/28 us-central1
    Public delegated prefix 203.0.113.16/28 us-east-4
    Public delegated prefix 192.0.2.0/28 global

    The remaining IP addresses are reserved for future use.

Live migration

Live migration is a powerful feature that requires detailed planning and execution.

Use live migration to import a BYOIP prefix when any part of the prefix is already publicly advertised. Importing an advertised prefix without using live migration might cause unexpected routing and packet loss.

Live migration has limited availability. Contact your Google Cloud customer engineer to get access before you create a public delegated prefix with live migration enabled.

You enable live migration when you create a public delegated prefix. To prevent Google from advertising the public advertised prefix to peers, you must ensure the following:

  • All public delegated prefixes within the public advertised prefix are configured with regional scope, not global scope. See live migration recommendations for more information.

  • No IP addresses in the range of the public advertised prefix are assigned to resources.

Figure 2 displays the same project with different configurations, one of which prevents the prefix from being advertised, and two which cause the public advertised prefix to be advertised.

Figure 2. Public advertised prefix advertisement during live migration (click to enlarge).

Figure 2 illustrates the following scenarios:

  • In the first project example, all public delegated prefixes in the public advertised prefix are configured with live migration enabled. No VMs are configured with IP addresses from this prefix.

    Result: The public advertised prefix is not advertised.

  • In the second project example, all public delegated prefixes in the public advertised prefix are configured with live migration enabled. One VM is configured with an IP address from this prefix.

    Result: The public advertised prefix is advertised.

  • In the third project example, one public delegated prefix within the public advertised prefix is not configured with live migration enabled. No VMs are configured with IP addresses from this prefix.

    Result: The public advertised prefix is advertised.

You control when the advertisement starts by assigning IP addresses from your public delegated prefix to Google Cloud resources. For more information, see Use live migration.

After your live migration is complete, contact your Google Cloud customer engineer so that they can disable live migration for your prefix. By default, live migration is disabled 30 days after you start advertisement of the public advertised prefix. If you need to have the live migration option available for longer than 30 days, contact your customer engineer.

Live migration limitations

When planning a live migration, it is important that you understand the following requirements and limitations:

  • Creating a public delegated prefix with live migration enabled is not supported if the scope is set to global. See live migration recommendations for information about managing live migration for global resources.

  • The longest prefix that can be migrated is a /24 because /24 is the maximum routable prefix-length on the internet.

  • Don't assume that all Google's peers respect the longest prefix between two sites. Some peers might not have full routing tables. As a result, a shorter prefix advertised by Google to those peers is the only (and therefore also the longest) prefix that the peer sees. As a result, the existence of any prefix from Google takes precedence, even if you are advertising a more specific route from your on-premises location.

    For example:

    A customer has a /23 which is actively routed from their on-premises location. The customer plans to disaggregate the /23 into two /24 prefixes, and announce the more specific routes from their on-premises location. Following the disaggregation, they plan to configure a /23 public advertised prefix for BYOIP. They assume that the more specific routes from their on-premises location take precedence over the shorter BYOIP prefix, and that traffic continues to route to the more specific on-premises prefixes.

    Unfortunately, this plan works only partially:

    • Google peers who have full routing tables prefer the more specific /24 on-premises prefixes.

    • Google peers who do not have full routing tables prefer the public advertised prefix announced from Google, since their routing tables don't include the more specific prefixes.

  • Your traffic is not delivered if Google receives traffic for a valid public advertised prefix for which you have not provisioned services, even if there is an active on-premises advertisement for the prefix.

    For example:

    A customer has an on-premises network comprising two /24 prefixes. Their public advertised prefix is the aggregate /23.

    The customer migrates a single /24 to Google and withdraws the on-premises prefix, but leaves the other /24 active in the on-premises location.

    This configuration results in some of the traffic routing to Google for the whole /23 prefix, even though there is still a more specific /24 prefix announced from the on-premises location. This scenario is difficult to diagnose, since various Autonomous Systems deliver traffic to your on-premises location, but others deliver to Google, in which case the traffic is dropped.

Live migration recommendations

As a best practice, follow these recommendations when using live migration.

  • Disaggregate all live migration prefixes into the longest prefixes that reflect how you want to advertise these prefixes during migration. In the previous examples, the /23 should be disaggregated into two /24 prefixes and announced as such from their on-premises location before you create the public advertised prefix.

  • Create exact prefix length ROA requests, and do not rely on the maximum length parameter to be respected.

  • Make sure that RPKI ROA requests exist for both the on-premises origin ASN and Google's origin ASN. If there is no ROA for the on-premises prefix, the creation of a Google origin ROA might cause third-party ISPs to filter out those on-premises prefixes if they are using automatic RPKI filtering.

  • Create separate public advertised prefixes for global resources and regional resources if you need to use live migration. When you enable live migration on a public delegated prefix, you must specify a region for the scope. Specifying global scope for a public delegated prefix that has live migration enabled is not supported. If you create a public delegated prefix with global scope and live migration enabled, the prefix is advertised immediately.

    Having regional prefixes in one public advertised prefix and global prefixes in another public advertised prefix lets you manage them separately. You can manage the live migration of the regional resources and contact your Google Cloud customer engineer to manage live migration of the global resources.

Project architecture

We recommend that you use organizations to benefit from features such as IAM permissions at the organization level and Shared VPC. See creating and managing organizations for more information about using an organization.

BYOIP address administration in an organization

In this example of a project belonging to an organization, there is a dedicated project, Public IP project, used to manage BYOIP addresses. The Public IP Admin for the organization has created the public advertised prefix and public delegated prefixes in the Public IP project.

When the VPC project needs public IP addresses, the Public IP Admin for the organization creates the IP addresses in the VPC project.

The organization can contain multiple projects, and the Public IP Admin can delegate IP addresses to them all from the Public IP project.

Figure 3. You can use organizations and projects to manage BYOIP addresses.

BYOIP addresses administration with Shared VPC

In this example of an organization that contains Shared VPC, there is a dedicated project, Public IP project, used to manage BYOIP addresses. The Public IP Admin for the organization has created the public advertised prefix and public delegated prefixes in the Public IP project.

When the Shared VPC host project or the related service projects need public IP addresses, the Public IP Admin for the organization creates the IP addresses in the Shared VPC host project. The host project and the service projects can access the BYOIP addresses from the host project.

Creating IP addresses in a Shared VPC service project is not supported.

Figure 4. You can delegate BYOIP addresses to a Shared VPC host project, but not to a Shared VPC service project. However, a service project can use BYOIP addresses that were delegated to the host project.

BYOIP address administration without an organization

If you use a project that does not belong to an organization, you can't create a separate project for BYOIP address administration. Create the public advertised prefix and public delegated prefixes in the same project that needs the BYOIP addresses.

Quotas and limits

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

What's next