Bring Your Own IPv6 to Google Cloud: A Guide for isp6 Members

Audience: isp6 members, cloud architects, and network engineers bringing their isp6-allocated IPv6 PA space to Google Cloud using BYOIP.

Last updated: April 2026

Table of Contents

1. Introduction
2. Why Bring Your isp6 Allocation to Google Cloud
3. What isp6 Handles vs. What You Do on Google Cloud
4. How isp6 Manages the Lifecycle of Your Allocation
5. Solution Options: Console vs. gcloud CLI / IaC
6. Cost Implications
7. Reference Architecture
8. Prerequisites for Google Cloud BYOIP
9. Implementation Overview
10. Monitoring & Security
11. Rollback & Deprovisioning
12. Recommendations
13. Further Reading

1. Introduction

As an isp6 member, you already own a portable IPv6 allocation — a /48 or /44 block of Provider Assigned (PA) address space, registered in the RIPE Database and managed through your isp6 subnet dashboard. This guide walks you through how to bring that allocation to Google Cloud using BYOIP, so you can use your own addresses across your cloud infrastructure while retaining full portability.

isp6 is a RIPE NCC accredited Local Internet Registry (LIR). Your allocation is drawn from isp6's RIPE address pool and is yours to announce from any network — Google Cloud, another cloud provider, a colocation facility, or all three simultaneously. Google Cloud's global VPC model makes it a particularly clean fit for BYOIP: a single /48 onboarded once can serve every region you operate in. This guide covers everything you need to make it work.

2. Why Bring Your isp6 Allocation to Google Cloud

2.1 Cost Elimination, Not Just Cost Reduction

Google Cloud charges for every external IPv4 address — in-use static addresses cost approximately $0.004/hour, and idle (reserved but unattached) static addresses cost $0.010/hour. A modest estate of 500 in-use public IPv4 addresses costs roughly $17,520/year before a single byte of data leaves the VPC.

IPv6 changes the equation entirely: Google Cloud does not charge for external IPv6 addresses — whether Google-assigned or BYOIP. Combined with eliminating the need for Cloud NAT (which carries per-hour gateway and per-GB processing fees for IPv4), IPv6 removes two entire line items from your networking bill.

2.2 A Clean Reputation Slate

Your isp6 allocation is a fresh, never-before-used block from isp6's RIPE address pool. There is no prior owner, no inherited blocklist entries, no "noisy neighbour" effect. When you bring this allocation to Google Cloud via BYOIP, you start with a pristine reputation — ideal for outbound email, API integrations, and any service where IP reputation affects deliverability or trust scoring.

Note: While your allocation starts clean, you are responsible for maintaining that reputation post-deployment. Misconfigured mail servers or abusive traffic originating from your range will degrade it over time.

2.3 True Portability

Because your allocation is registered through isp6's LIR under RIPE NCC, you can withdraw it from Google Cloud and re-advertise it from another provider, a colocation facility, or a different cloud — all without changing a single allowlist entry or DNS record on the consumer side. Your addresses are never locked to a single cloud provider.

2.4 Address Planning at Scale

A /48 allocation gives you 65,536 /64 subnets — each containing a practically unlimited number of host addresses. A /44 gives you 16 times that. This removes subnet exhaustion as a design constraint and simplifies VPC subnet planning. Because Google Cloud's VPC is global with regional subnets, a single /48 can be cleanly partitioned across every region you operate in.

3. What isp6 Handles vs. What You Do on Google Cloud

One of the advantages of ordering your IPv6 space through isp6's self-service portal is that many of the traditionally complex steps in the BYOIP process are already taken care of. Here is a clear breakdown.

isp6 handles

You handle on the Google Cloud side

Key point: You do not need to apply to RIPE NCC, justify address need, or navigate RIR processes. Your isp6 membership and order give you a registered, RPKI-ready allocation that is ready for BYOIP from day one.

4. How isp6 Manages the Lifecycle of Your Allocation

When you bring your isp6 allocation to Google Cloud, isp6 continues to manage the full RIPE lifecycle in the background. Understanding this lifecycle helps you see where Google Cloud BYOIP fits within the broader picture.

4.1 Lifecycle Overview

flowchart LR
    Order["Order & Payment<br>(isp6 portal)"]
    Reserve["Reservation<br>Block assigned<br>to your account"]
    RIPE_A["RIPE Registration<br>inet6num created<br>(automatic)"]
    Activate["Activation<br>You submit your ASN<br>route6 + ROA created"]
    Active["Active Management<br>RPKI, rDNS, ROA<br>via isp6 dashboard"]
    GCP["Google Cloud BYOIP<br>PAP + PDP<br>(you provision)"]

    Order --> Reserve
    Reserve --> RIPE_A
    RIPE_A --> Activate
    Activate --> Active
    Active --> GCP

    style GCP fill:transparent,stroke:#333,stroke-width:2px,stroke-dasharray: 5 5

4.2 What Happens at Each Stage

4.3 How This Relates to Google Cloud

Your Google Cloud PAP and PDPs operate alongside isp6's RIPE lifecycle management, not instead of it. Specifically:

• ROAs — isp6 manages all ROAs for your allocation. Your network ASN and the Google ASN (396982) are both published through isp6's RIPE certification authority.
• route6 objects — isp6 manages the RIPE DB route6 for your origin ASN. Google separately updates route registries when you announce your PAP (you do not need to manage RADb entries).
• Reverse DNS — configured through your isp6 dashboard. Google Cloud does not manage reverse DNS for BYOIP prefixes — the delegation configured in RIPE via isp6 is authoritative.
• Deprovisioning — if you withdraw from Google Cloud, your isp6 allocation and all RIPE registrations remain intact. If your isp6 membership expires, the RIPE objects are cleaned up by isp6 — you should withdraw your PAP before that happens.

Important: Keep your isp6 membership active for as long as you are using the allocation on Google Cloud. If the membership lapses, isp6 will deprovision the RIPE objects, which will invalidate the ROA and cause Google to stop advertising your prefix.

5. Solution Options: Console vs. gcloud CLI / IaC

Google Cloud offers multiple onboarding paths for BYOIP. Choosing the right one depends on your organisational scale and operational maturity.

When to choose the Console: You are onboarding a single /48 in one or two regions, your team prefers visual management, and you do not need CI/CD integration.

When CLI / IaC is preferred: You manage multiple projects, operate across many regions, or need reproducible deployments via Terraform.

For full onboarding steps, see Using Bring Your Own IP Addresses.

isp6 /44 allocations and Google Cloud BYOIP: Google Cloud requires a minimum /48 for the Public Advertised Prefix. If you hold a /44 from isp6, you can bring the entire /44 as a single PAP, or bring individual /48 slices — for example, one /48 per Google Cloud project.

6. Cost Implications

6.1 Comparative Cost Model

The table below compares the annualised cost of three addressing strategies. All pricing is indicative — verify current rates at VPC Network Pricing and Cloud NAT Pricing.

IPv6 egress uses external IPv6 addresses assigned directly to VM NICs — no Cloud NAT gateway is needed, eliminating both the per-hour gateway charge and the per-GB processing fee.

Caveat: Pricing changes frequently and varies by region and Network Service Tier (Premium vs. Standard). The figures above use Premium Tier pricing and are based on publicly available rates as of early 2026. Always consult the Google Cloud Pricing Calculator and the service-specific pricing pages linked above before making financial decisions.

6.2 What Doesn't Change

• Data transfer out charges are identical regardless of whether you use Google-assigned or BYOIP addresses, and regardless of IP version.
• Inter-region transfer rates remain the same for both IPv4 and IPv6.
• Network Service Tier (Premium or Standard) pricing applies equally to IPv4 and IPv6 traffic.

7. Reference Architecture

The following diagram illustrates how your isp6-allocated IPv6 range flows from RIPE through Google Cloud's BYOIP infrastructure to your workloads.

flowchart TD
    %% isp6 / RIPE Section
    subgraph ISP6_RIPE ["isp6 + RIPE NCC"]
        direction LR
        Alloc["Your IPv6 /48 or /44<br>PA Allocation (isp6)"]
        RIPE_DB["RIPE Database<br>inet6num + route6<br>(managed by isp6)"]
        ROA["ROAs via isp6<br>Your ASN + Google ASN<br>396982"]

        Alloc --> RIPE_DB
        Alloc --> ROA
    end

    %% Ownership verification
    Verify["Google Cloud Ownership Verification<br><br>X.509 cert on inet6num<br>+ signed authorisation message"]

    ROA --> Verify
    RIPE_DB --> Verify

    %% Google Cloud BYOIP hierarchy
    subgraph GCP_BYOIP ["Google Cloud BYOIP Hierarchy"]
        direction TB
        PAP["Public Advertised Prefix (PAP)<br>Your /48 or /44 (global)<br>VALIDATED &rarr; ANNOUNCED"]
        PDP_A["Public Delegated Prefix (PDP)<br>europe-west1"]
        PDP_B["Public Delegated Prefix (PDP)<br>us-central1"]
        PDP_C["Public Delegated Prefix (PDP)<br>asia-east1"]

        PAP --> PDP_A
        PAP --> PDP_B
        PAP --> PDP_C
    end

    Verify --> PAP

    %% Google Cloud VPC
    subgraph VPC ["VPC (Global, Dual-Stack)"]
        direction TB

        subgraph Subnets [" "]
            direction LR
            subgraph SubA ["Subnet (europe-west1)"]
                VM_A["VM<br>(v6 on NIC)"]
            end
            subgraph SubB ["Subnet (us-central1)"]
                VM_B["VM<br>(v6 on NIC)"]
            end
            subgraph SubC ["Subnet (asia-east1)"]
                VM_C["VM<br>(v6 on NIC)"]
            end
        end

        FW["VPC Firewall Rules (IPv6-aware)<br>External IPv6 &rarr; direct internet routing (no Cloud NAT)"]
        GLB["External Application Load Balancer<br>(global, IPv6 frontend)"]

        SubA --> FW
        SubB --> FW
        SubC --> FW
    end

    PDP_A --> SubA
    PDP_B --> SubB
    PDP_C --> SubC

    %% Internet
    Internet(["Internet"])

    FW --> Internet
    GLB --> Internet

    %% Styling
    style ISP6_RIPE fill:transparent,stroke:#333,stroke-width:2px,stroke-dasharray: 5 5
    style GCP_BYOIP fill:transparent,stroke:#333,stroke-width:2px,stroke-dasharray: 5 5
    style VPC fill:transparent,stroke:#333,stroke-width:2px
    style Subnets fill:transparent,stroke:none
    style SubA fill:transparent,stroke:#666,stroke-width:1px
    style SubB fill:transparent,stroke:#666,stroke-width:1px
    style SubC fill:transparent,stroke:#666,stroke-width:1px
    style Internet fill:#e4e4e4,stroke:#333,stroke-width:2px

Key Architectural Notes

• Global VPC. Unlike AWS and Azure (where VPCs/VNets are regional), Google Cloud's VPC is a global resource. Subnets are regional. A single VPC can span every region, with your BYOIP IPv6 range partitioned across regional subnets via PDPs.
• No Cloud NAT required. VMs with external IPv6 addresses route directly to and from the internet. Cloud NAT is an IPv4-only construct — it is not needed (and not used) for IPv6 traffic.
• Dual-stack subnets. Enable IPv6 on each subnet with the --stack-type=IPV4_IPV6 flag and set --ipv6-access-type=EXTERNAL to make IPv6 addresses publicly routable. When using BYOIP, the subnet's IPv6 range is drawn from your Public Delegated Prefix.
• Global load balancing. Google Cloud's external Application Load Balancer is natively global and supports IPv6 frontends. BYOIP IPv6 addresses can be used as the load balancer's forwarding rule address, providing a deterministic, portable entry point.
• Your isp6 allocation remains portable. Even after onboarding to Google Cloud, you retain full control through your isp6 dashboard. You can withdraw your PAP and re-announce from another provider at any time.

8. Prerequisites for Google Cloud BYOIP

Because your IPv6 space is already allocated and registered through isp6, several of the traditional BYOIP prerequisites are already satisfied. This section covers what is already in place and what you still need to configure for Google Cloud.

8.1 What isp6 Has Already Done

8.2 ROA for Google ASN

For Google Cloud to announce your prefix via BGP, you need a ROA that authorises the Google Autonomous System Number. This is managed through isp6's RPKI management — the same mechanism used for your own network's ROA.

Add the Google ASN using the cloud panel on your isp6 subnet dashboard — select your cloud provider and the ASN is populated automatically. isp6 manages RPKI for your allocation — the ROA is published through isp6's RIPE certification authority, alongside your existing ROA for your own ASN.

ROA propagation via RPKI can take up to 24 hours. Do not proceed to Google Cloud provisioning until the ROA is visible. Your isp6 subnet dashboard displays ROA propagation status, so you can track readiness without leaving the platform.

Important: If your prefix is currently announced from your own ASN (e.g., from on-premises infrastructure or another cloud provider), ensure your existing ROA remains in place alongside the Google ROA. Removing it prematurely will cause a routing disruption.

8.3 Ownership Verification

Google Cloud requires an X.509 certificate-based verification to prove ownership of the IP range. isp6 has already completed the most complex part of this process during your onboarding.

What isp6 has already done:

During onboarding (step 9 — "Configure certificate"), the isp6 portal generates an RSA 2048-bit key pair in your browser using the Web Crypto API. The public key is automatically registered on the RIPE inet6num descr field for your allocation. You downloaded the corresponding private key at that time — isp6 never stores it.

What you do for Google Cloud:

Use the private key from your isp6 onboarding to create the signed authorisation message that Google Cloud requires when creating the Public Advertised Prefix. See Using Bring Your Own IP Addresses for the exact message format and openssl signing commands.

Lost your private key? You can regenerate a new key pair at any time from your isp6 dashboard (/member/certificate). Regenerating invalidates the previous key — isp6 will update the public key on the RIPE inet6num automatically.

8.4 Google Cloud Project Requirements

9. Implementation Overview

This section outlines the provisioning lifecycle on the Google Cloud side. For exact CLI syntax, signed message construction, and API parameters, refer to the BYOIP documentation.

9.1 Provisioning Lifecycle

flowchart LR
    Prepare["Prepare<br>(ROA via isp6 +<br>ownership verification)"]
    PAP["Create PAP<br>(Public Advertised<br>Prefix)<br>VALIDATED"]
    Announce["Announce<br>(BGP active)<br>ANNOUNCED"]
    PDP["Create PDPs<br>(regional slices)"]
    InUse["In Use<br>(Assign to<br>VMs / LBs)"]
    Withdraw["Withdraw<br>(stop BGP)"]
    Delete["Delete PAP<br>(release from<br>Google Cloud)"]

    Prepare --> PAP
    PAP -->|"Minutes to hours"| Announce
    Announce --> PDP
    PDP --> InUse
    InUse --> Withdraw
    Withdraw --> Delete

9.2 Key Concepts: PAP and PDP

Google Cloud uses a two-tier resource model for BYOIP:

The PAP is onboarded once, then PDPs are created per region — a natural fit for Google Cloud's global VPC with regional subnets.

9.3 Step-by-Step Summary

Do not make manual changes to RADb or other Internet Routing Registries — Google Cloud automatically updates route registries when you announce or withdraw your prefix.

For the complete CLI walkthrough, including signed message construction, see:

• BYOIP Overview
• Using BYOIP
• Configuring BYOIP

10. Monitoring & Security

10.1 Operational Monitoring

10.2 IAM Least-Privilege Guidance

Restrict BYOIP lifecycle operations to a dedicated infrastructure team. The key Compute Engine permissions to control are:

The built-in Compute Network Admin (roles/compute.networkAdmin) role includes all of the above. For tighter control, create a custom IAM role that grants only the specific permissions needed. Scope role bindings to the project or folder level, not the organisation level, to limit blast radius.

10.3 Security Considerations

• RPKI is non-negotiable. Your ROA is what prevents another AS from hijacking your prefix via BGP. isp6 manages your RPKI state and monitors ROA propagation status through your subnet dashboard — an expired or invalid ROA means Google will cease advertising your range.
• Do not share the RSA private key used to sign the provisioning message. It is not needed after provisioning; store it securely or destroy it per your key management policy.
• Organization Policies for guardrails. In a multi-project environment, use Organization Policy constraints to prevent non-infrastructure projects from creating PAP or PDP resources.
• VPC Firewall Rules for direct routing. Since external IPv6 addresses are directly reachable from the internet (no Cloud NAT intermediary), ensure VPC firewall rules explicitly deny inbound traffic except for required ports. Use Hierarchical Firewall Policies to enforce organisation-wide baseline rules that individual projects cannot override.
• ROA changes go through isp6. If you need to modify the ROA (e.g., to change the Google ASN configuration or add a new provider's ASN), make the change through your isp6 subnet dashboard to avoid disrupting your BGP advertisements.

11. Rollback & Deprovisioning

If you need to revert — whether to move the range to another provider or to troubleshoot a routing issue — the Google Cloud side is the reverse of provisioning. Your isp6 allocation and RIPE registrations remain intact throughout.

Your allocation stays yours. Withdrawing from Google Cloud does not affect your isp6 membership, your RIPE registration, or your ability to re-announce the prefix from another provider. This is the core portability benefit of owning your address space through isp6.

Warning: You must delete all PDPs before you can withdraw and delete the PAP. Google Cloud will reject the operation if child resources still exist.

Membership expiry warning: If your isp6 membership lapses, isp6 will deprovision the RIPE objects (ROA, route6, inet6num) following the standard lifecycle. This will invalidate the ROA that Google depends on and cause your prefix to be withdrawn from BGP. Always withdraw your PAP before allowing your membership to expire.

12. Recommendations

1. Start with a /48. The minimum publicly advertisable IPv6 prefix for Google Cloud BYOIP is /48. If you hold a /44 from isp6, decide whether to bring the full /44 or individual /48 slices based on your multi-project strategy.

2. Leverage the global VPC. Google Cloud's VPC is global — unlike AWS and Azure, you do not need to create separate network constructs per region. Plan your PDP allocations to map cleanly to your regional subnet layout within a single VPC.

3. Plan your PDP and subnet hierarchy. A /48 gives you 65,536 /64 subnets. Design a consistent allocation scheme before you start assigning — for example, a /56 per region and a /64 per subnet within that region. Retrofitting a numbering plan is painful.

4. Monitor RPKI via your isp6 dashboard. Your isp6 subnet dashboard shows RIPE registration state, ROA validity, and propagation status. Complement this with Google Cloud-side monitoring (gcloud compute public-advertised-prefixes describe) to catch issues early. An expired ROA means Google will stop advertising your prefix.

5. Leverage the clean slate. Your fresh isp6 allocation has never been used. Protect that reputation by deploying proper SPF, DKIM, and DMARC records from day one if you use these addresses for outbound email, and by implementing egress firewall rules to prevent abuse originating from your range.

6. Deploy dual-stack, not IPv6-only (yet). While Google Cloud services increasingly support IPv6, many third-party integrations and SaaS APIs still require IPv4. Run dual-stack with your isp6 BYOIP IPv6 as the primary addressing layer, falling back to IPv4 where necessary.

7. Harden VPC firewall rules for direct routing. Unlike IPv4 where Cloud NAT provides an implicit security boundary, external IPv6 addresses are directly reachable from the internet. Use Hierarchical Firewall Policies to enforce organisation-wide default-deny inbound rules, then allow only the ports your services require at the project or VPC level.

8. Use Premium Network Service Tier. BYOIP prefixes are announced from Google's edge network. Premium Tier routes traffic over Google's private backbone to the closest edge point of presence, giving the best latency and reliability for your BYOIP addresses. See Network Service Tiers for details.

9. Codify with Terraform. Define your PAP, PDPs, subnets, and firewall rules in Terraform using the Google Cloud provider. This ensures reproducibility, audit trails via source control, and safe rollback via redeployment.

13. Further Reading

Google Cloud Documentation

• Bring Your Own IP Addresses — Overview
• Using Bring Your Own IP Addresses
• Configuring Bring Your Own IP
• External IP Address Pricing
• Cloud NAT Overview
• Cloud NAT Pricing
• VPC Overview
• VPC Subnets
• IPv6 Addresses on Compute Engine
• VPC Firewall Rules
• Hierarchical Firewall Policies
• Network Service Tiers

RIPE NCC References

• RIPE — Managing ROAs
• RIPE — RPKI Validator
• RIPE Database — Query

Google Cloud Architecture & Governance

• IAM — Creating Custom Roles
• Organization Policy Overview
• Cloud Audit Logs
• Cloud Asset Inventory
• Google Cloud Terraform Provider

Related isp6 knowledge base articles

• Designing the Next Internet: An Introduction to IPv6 — protocol primer for engineers new to IPv6; covers address anatomy, scopes, and SLAAC before you touch the cloud
• Planning Your isp6 Allocation — sizing and structuring your /48 or /44 before you announce it to Google Cloud
• Stop Thinking in IPv4: Misconceptions That Sabotage Your IPv6 Deployment — IPv4 reflexes to unlearn before configuring VPC firewall rules
• Building an IPv6 Integrated Project Team — cross-functional programme structure for a successful Google Cloud rollout

isp6

• isp6 — Sign up
• isp6 — Digital Sovereignty

This document is provided for informational purposes. Protocol specifications and cloud provider behaviour are subject to change. Consult the linked RFCs and vendor documentation for authoritative, up-to-date information before making architectural decisions.