Create a public advertised prefix

You can bring your own IP addresses (BYOIP) to Google Cloud. After we validate that you own the IP range, and the IP addresses are imported to Google Cloud, you can assign them to supported resources.

The first step in using bring your own IP is to create a public advertised prefix. The following options are available:

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 internal (v2)	Regional (v1)	Global (v1)
Availability	Recommended regional configuration	Used for internal IPv6 addresses	Not recommended for new regional configurations	Must request adding your project to an allowlist
Public advertised prefix provisioning time	Approximately 2 weeks	Immediate	Approximately 4 weeks	Approximately 4 weeks
Public delegated prefix provisioning time	A few minutes	Immediate	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	Immediate	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.	Not announced	The public advertised prefix is automatically announced after provisioning completes.	The public advertised prefix is automatically announced after provisioning completes.
Access type	External	Internal	External	External
Network Service Tiers	Premium Tier Standard Tier (Preview)	Premium Tier	Premium Tier	Premium Tier
IP stack	Premium Tier: IPv4, IPv6 (only for external passthrough Network Load Balancers and subnets that exclusively host VMs) Standard Tier: IPv4	IPv6	IPv4	IPv4

Before you begin

• Bringing your own IP addresses to Google Cloud requires careful planning. For more information, see Planning for bring your own IP addresses.
• Consider using an organization, and creating a dedicated project for managing BYOIP addresses. For more information, see Project architecture.
• If you are creating an external access public advertised prefix, check if any part of the prefix that you want to import is already publicly advertised. If it is, you must make sure that Google Cloud does not advertise it while it is being advertised from another source:
  • If you are creating a v2 public advertised prefix for regional addresses, you have control over the announcement of the prefix. You can create the public advertised prefix and public delegated prefixes, but you must ensure the prefix is not advertised anywhere else before you announce it from Google Cloud.
  • If you are creating a v1 public advertised prefix for global addresses, the prefix is automatically announced as soon as public delegated prefix provisioning is complete. Don't create public delegated prefixes until the prefix is no longer being announced from another source.

Roles

To get the permissions that you need to complete the tasks in this guide, ask your administrator to grant you the Compute Public IP Admin (roles/compute.publicIpAdmin) IAM role on your project. For more information about granting roles, see Manage access to projects, folders, and organizations.

You might also be able to get the required permissions through custom roles or other predefined roles.

Create and validate a public advertised prefix

When you create a public advertised prefix, you must validate ownership of the prefix. The details of these validation tasks are outlined in the following sections. The validation process depends on the access type of the prefix:

• For external access prefixes, you complete two tasks which together let Google Cloud validate that you own this prefix:

  • Creating a Route Origin Authorization (ROA) for your prefix.
  • Creating a PTR record for an IP address in your prefix.

  After validation is complete, it takes approximately two weeks to complete configuration for v2 prefixes or four weeks for v1 prefixes.

• For internal access prefixes, you only need to create a ROA for your prefix. The configuration is complete immediately, and the prefix is ready to use.

Create a ROA request

To prove that you have ownership of a prefix, create a Route Origin Authorization (ROA) request.

Submit the ROA request with your regional registry for the prefix that you want Google Cloud to advertise. When you create a public advertised prefix, the ROA for that prefix must exist and point to the ASN for Google Cloud, remaining in effect for some time after you delete the public advertised prefix. For more information, see Remove a ROA.

The values that you include in the ROA request depend on the network tier of the prefix.

Premium Tier ROA requirements

For Premium Tier, create a ROA request that includes the public advertised prefix, its prefix length, and the Premium Tier ASN for Google Cloud: 396982.

Standard Tier ROA requirements

For Standard Tier (Preview), do one of the following:

• Create separate ROA requests for the public advertised prefix and each top-level public delegated prefix that you plan to provision. For each request, include the prefix, its prefix length, and the Standard Tier ASN for Google Cloud: 19527. Google recommends this approach.

• Create a single ROA request that includes the public advertised prefix, its prefix length, a maximum prefix length (maxLength) of /24, and the Standard Tier ASN for Google Cloud: 19527.

Create a ROA for your own ASN

We recommend that you submit another ROA request for your public advertised prefix. Use the same details as the ROA you submitted with Google's ASN, but substitute your own ASN as the origin. If you ever need to advertise the prefix, the ROA with your ASN prevents networks that use Resource Public Key Infrastructure (RPKI) from considering the prefix to be invalid because it is also advertised with the origin ASN for Google Cloud.

Regional internet registries

Your local regional internet registry processes ROA requests. For more information, see the link for your location:

• AFRINIC (Africa)
• APNIC (Portions of Asia and Oceania)
• ARIN (North America and some Caribbean Islands)
• LACNIC (Latin America)
• RIPE NCC (Europe, Central Asia, Middle East)

Renew a ROA

To let Google Cloud advertise your public advertised prefixes, you must actively maintain a valid ROA with your regional internet registry. ROAs expire periodically and must be renewed before expiration.

If your ROA expires and you fail to renew it within four weeks of receiving a renewal notification, Google Cloud stops advertising the public advertised prefix to the internet, which might result in connectivity disruptions for resources that use IP addresses from the prefix.

To renew your ROA, consult your local regional internet registry for specific instructions. For more information, see Create a ROA request.

Create a public advertised prefix

You can create a public advertised prefix for the prefix that you want to bring to Google Cloud.

A public advertised prefix name can't be changed without deleting and recreating the resource. For this reason, we recommend that you create generic names that won't need to change—for example, pap-203-0-113-0-24, where pap denotes the resource type and 203-0-113-0-24 denotes the specific prefix and prefix length.

If you want to use the public advertised prefix to create global public delegated prefixes, your project must be added to an allowlist. For more information, see Global public delegated prefixes.

For external access prefixes, choose an unused IP address for DNS validation. Verification requires that you configure a new PTR record for this IP address, and you don't know the hostname until after you create the public advertised prefix.

Validate ownership with DNS

If you created an external access public advertised prefix, complete the steps in the following sections to verify that you own the prefix. If you created an internal access public advertised prefix, you don't need to validate ownership with DNS.

Find the name to use for the PTR record

When you create an external access public advertised prefix, Google Cloud generates a name for you to use as a hostname for the PTR validation step.

Create the PTR record

To verify that you own the IP address range that you are importing to Google Cloud, you must create a public PTR record in the DNS zone that is used for the IP address range that you are importing.

Use the following values in the PTR record:

• IP address: the verification IP address that you used when you created the public advertised prefix.
• Hostname: the name (sharedSecret) that Google Cloud provided.
• Domain name: the domain name associated with the DNS zone that is used for the IP address range that you are importing.

Examples:

• IPv4: If your verification IP address is 203.0.113.144, and the DNS domain for 203.0.113.0/24 is example.net, and the name provided by Google Cloud is 55kk88tt00, the required PTR record would look like this:

  $ dig +noall +answer -x 203.0.113.144
  
  144.113.0.203.in-addr.arpa. 21599 IN PTR 55kk88tt00.example.net
  

• IPv6: If your verification IP address is 2001:db8::10, and the DNS domain for 2001:db8::/32 is example.net, and the name provided by Google Cloud is 55kk88tt00, the required PTR record would look like this:

  $ dig +noall +answer -x 2001:db8::10
  
  0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
  21599 IN PTR 55kk88tt00.example.net.
  

Validate the PTR record

After you have created the PTR record, update the public advertised prefix to trigger validation of the PTR record.

gcloud compute public-advertised-prefixes update PAP_NAME --status=PTR-CONFIGURED

Check the status of a public advertised prefix

It takes approximately four weeks for Google Cloud to provision the public advertised prefix. You can check the status to see if provisioning is complete.

gcloud compute public-advertised-prefixes describe PAP_NAME --format='value(status)'

After the prefix is validated, the status field changes from VALIDATED to PREFIX_CONFIGURATION_COMPLETE.

What's next

• Create public delegated prefixes