Bring Your Own IPv6 to Azure: A Guide for isp6 Members

Audience: isp6 members, cloud architects, and network engineers bringing their isp6-allocated IPv6 PA space to Azure using Custom IP Prefix (BYOIP).

Last updated: April 2026

Table of Contents

1. Introduction
2. Why Bring Your isp6 Allocation to Azure
3. What isp6 Handles vs. What You Do on Azure
4. How isp6 Manages the Lifecycle of Your Allocation
5. Solution Options: Portal vs. CLI / IaC
6. Cost Implications
7. Reference Architecture
8. Prerequisites for Azure Custom IP Prefix
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 Azure using Custom IP Prefix (Azure's BYOIP mechanism), so you can use your own addresses across your Azure 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 — Azure, another cloud provider, a colocation facility, or all three simultaneously. This guide covers everything you need to onboard your isp6 allocation to Azure and keep it running alongside isp6's ongoing RIPE lifecycle management.

2. Why Bring Your isp6 Allocation to Azure

2.1 Cost Elimination via Custom IP Prefix

Azure charges per hour for Standard SKU public IP addresses — both IPv4 and IPv6 — when drawn from Microsoft's pools. At approximately $0.005/hour per Standard SKU public IPv4 address, a modest estate of 500 public IPv4 addresses costs roughly $21,900/year before any data leaves the virtual network.

Public IPs derived from a Custom IP Prefix (BYOIP) incur no per-IP charge, regardless of IP version. Combined with removing the need for NAT Gateway (which carries per-hour and per-GB processing fees for IPv4 egress), IPv6 BYOIP removes two entire cost categories from your networking bill.

See Custom IP Prefix Overview for pricing details.

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 Azure via Custom IP Prefix, 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 decommission it from Azure 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 VNet CIDR planning across multi-subscription, multi-region architectures.

3. What isp6 Handles vs. What You Do on Azure

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 Azure 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 Azure, isp6 continues to manage the full RIPE lifecycle in the background. Understanding this lifecycle helps you see where Azure 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"]
    Azure["Azure BYOIP<br>Custom IP Prefix<br>(you provision)"]

    Order --> Reserve
    Reserve --> RIPE_A
    RIPE_A --> Activate
    Activate --> Active
    Active --> Azure

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

4.2 What Happens at Each Stage

4.3 How This Relates to Azure

Your Azure Custom IP Prefix operates alongside isp6's RIPE lifecycle management, not instead of it. Specifically:

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

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

5. Solution Options: Portal vs. CLI / IaC

Azure offers multiple onboarding paths for Custom IP Prefix. Choosing the right one depends on your organisational scale and operational maturity.

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

When CLI / IaC is preferred: You manage multiple subscriptions, operate in multiple regions, or need reproducible deployments via ARM templates, Bicep, or Terraform.

For full onboarding steps, see Create a Custom IP Prefix for IPv6 — Azure CLI or the Portal walkthrough.

isp6 /44 allocations and Azure Custom IP Prefix: Azure requires a minimum /48 for the Global Custom IP Prefix. If you hold a /44 from isp6, you can bring the entire /44 as a single global prefix, or bring individual /48 slices — for example, one /48 per subscription or region.

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 Azure Public IP Pricing and Azure NAT Gateway Pricing.

IPv6 eliminates both the per-IP charge and the NAT Gateway charge. Public IPv6 addresses on VM NICs route directly to the internet without NAT — Network Security Groups control inbound and outbound traffic.

Caveat: Pricing changes frequently and varies by region. The figures above are based on publicly available rates as of early 2026. Always consult the Azure 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 Azure-assigned or BYOIP addresses, and regardless of IP version.
• Inter-region (VNet peering) transfer charges remain the same for both IPv4 and IPv6.

7. Reference Architecture

The following diagram illustrates how your isp6-allocated IPv6 range flows from RIPE through Azure's Custom IP Prefix hierarchy 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 + Azure ASN 8075"]

        Alloc --> RIPE_DB
        Alloc --> ROA
    end

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

    ROA --> Verify
    RIPE_DB --> Verify

    %% Azure Custom IP Prefix hierarchy
    subgraph Azure_CIP ["Azure Custom IP Prefix Hierarchy"]
        direction TB
        Global["Global Custom IP Prefix<br>Your /48 or /44<br>(provisioned + commissioned)"]
        Regional_A["Regional Custom IP Prefix<br>(Region A)"]
        Regional_B["Regional Custom IP Prefix<br>(Region B)"]
        PIP_A["Public IP Prefix<br>(&le; /64)"]
        PIP_B["Public IP Prefix<br>(&le; /64)"]

        Global --> Regional_A
        Global --> Regional_B
        Regional_A --> PIP_A
        Regional_B --> PIP_B
    end

    Verify --> Global

    %% Azure Region
    subgraph Region ["Azure Region"]
        subgraph VNet ["VNet (Dual-Stack)"]
            direction TB

            subgraph Subnets [" "]
                direction LR
                subgraph SubA ["Subnet (Zone 1)"]
                    LB["Load Balancer<br>(v6 frontend)"]
                end
                subgraph SubB ["Subnet (Zone 2)"]
                    VM_B["VM<br>(v6 NIC)"]
                end
                subgraph SubC ["Subnet (Zone 3)"]
                    VM_C["VM<br>(v6 NIC)"]
                end
            end

            NSG["NSG: deny-all inbound / allow-specific<br>Public IPv6 &rarr; direct internet routing (no NAT)"]

            SubA --> NSG
            SubB --> NSG
            SubC --> NSG
        end
    end

    PIP_A --> VNet

    %% Internet
    Internet(["Internet"])

    NSG --> Internet

    %% Styling
    style ISP6_RIPE fill:transparent,stroke:#333,stroke-width:2px,stroke-dasharray: 5 5
    style Azure_CIP fill:transparent,stroke:#333,stroke-width:2px,stroke-dasharray: 5 5
    style Region fill:transparent,stroke:#333,stroke-width:2px,stroke-dasharray: 5 5
    style VNet 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

• No NAT required. Unlike IPv4 (where Azure NAT Gateway or Load Balancer outbound rules provide internet access for private instances), public IPv6 addresses route directly to and from the internet. Network Security Groups control traffic flow.
• Hierarchical prefix model. Azure uses a three-tier hierarchy: Global Custom IP Prefix (onboarded once) → Regional Custom IP Prefix (per region) → Public IP Prefix (allocatable to resources). This makes multi-region deployment straightforward — the same /48 is onboarded once globally, then carved into regional slices.
• Dual-stack is the recommended deployment model. Add your BYOIP IPv6 address space to the VNet alongside your IPv4 address space. Each subnet receives both an IPv4 and IPv6 CIDR.
• No intermediate allocation step. Public IPv6 addresses are created directly from a Public IP Prefix derived from your Custom IP Prefix, then attached to NICs or Load Balancer frontends.
• Your isp6 allocation remains portable. Even after onboarding to Azure, you retain full control through your isp6 dashboard. You can decommission from Azure and re-announce from another provider at any time.

8. Prerequisites for Azure Custom IP Prefix

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

8.1 What isp6 Has Already Done

8.2 ROA for Azure ASN

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

Add the Azure 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 Azure 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 Azure ROA. Removing it prematurely will cause a routing disruption.

8.3 Ownership Verification

Azure 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 Azure:

Use the private key from your isp6 onboarding to create the signed authorisation message that Azure requires during Custom IP Prefix provisioning. This message includes your Azure subscription ID, the prefix being onboarded, and an expiry date. See Create a Custom IP Prefix — IPv6 (CLI) 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 Azure Account Requirements

9. Implementation Overview

This section outlines the provisioning lifecycle on the Azure side. For exact CLI syntax, signed message construction, and API parameters, refer to the Azure Custom IP Prefix documentation.

9.1 Provisioning Lifecycle

flowchart LR
    Prepare["Prepare<br>(ROA via isp6 +<br>ownership verification)"]
    Global["Create Global<br>Custom IP Prefix<br>(Provisioning &rarr;<br>Provisioned)"]
    Commission["Commission<br>(BGP announced)"]
    Regional["Create Regional<br>Prefix + Public<br>IP Prefix"]
    InUse["In Use<br>(Assign to<br>VNet / NICs)"]
    Decommission["Decommission<br>(stop BGP)"]
    Delete["Delete<br>(remove from<br>Azure)"]

    Prepare --> Global
    Global -->|"Typically < 30 min<br>(up to 2 hours)"| Commission
    Commission --> Regional
    Regional --> InUse
    InUse --> Decommission
    Decommission --> Delete

9.2 Step-by-Step Summary

Do not make manual changes to RADb or other Internet Routing Registries — Azure automatically updates RADb when you commission or decommission your prefix.

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

• Create a Custom IP Prefix — IPv6 (CLI)
• Create a Custom IP Prefix — IPv6 (Portal)
• Manage a Custom IP Prefix

10. Monitoring & Security

10.1 Operational Monitoring

10.2 RBAC Least-Privilege Guidance

Restrict Custom IP Prefix lifecycle operations to a dedicated infrastructure team. The key resource provider actions to control are:

Construct custom Azure roles using the principle of least privilege. The built-in Network Contributor role includes all of the above — for tighter control, create a custom role that grants only the specific actions needed. See the Azure custom roles documentation for details.

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 Azure 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.
• Azure Policy for guardrails. In a multi-subscription environment, use Azure Policy to prevent non-infrastructure subscriptions from creating or deleting Custom IP Prefix resources. Combine with Management Groups for hierarchical enforcement.
• NSG hardening. Since public IPv6 addresses route directly (no NAT), ensure Network Security Groups on all subnets explicitly deny inbound traffic except for required ports. Do not rely on the absence of a public IP as a security boundary.
• ROA changes go through isp6. If you need to modify the ROA (e.g., to change the Azure 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 Azure side is the reverse of provisioning. Your isp6 allocation and RIPE registrations remain intact throughout.

Your allocation stays yours. Decommissioning from Azure 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 remove all derived resources (Public IPs, Public IP Prefixes, Regional Prefixes) before you can delete the parent resource. Azure will reject the delete 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 Azure depends on and cause your prefix to be withdrawn from BGP. Always decommission from Azure before allowing your membership to expire.

12. Recommendations

1. Start with a /48. The minimum IPv6 prefix for Azure Custom IP Prefix is /48. If you hold a /44 from isp6, decide whether to bring the full /44 or individual /48 slices based on your multi-subscription strategy.

2. Use the Global-to-Regional hierarchy. Onboard your /48 as a Global Custom IP Prefix once, then derive Regional Custom IP Prefixes for each Azure region you operate in. This avoids re-verifying ownership per region and provides a clean multi-region model.

3. Plan your prefix hierarchy. A /48 gives you 65,536 /64 subnets. Design a consistent allocation scheme (e.g., /56 per region, /60 per environment, /64 per subnet) before you start assigning — 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 Azure-side monitoring (az network custom-ip prefix show) to catch issues early. An expired ROA means Azure 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 NSG egress rules to prevent abuse originating from your range.

6. Deploy dual-stack, not IPv6-only (yet). While Azure 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 NSGs for direct routing. Unlike IPv4 where NAT provides an implicit security boundary, public IPv6 addresses are directly reachable from the internet. Treat NSG configuration as a first-class security control — default-deny inbound on every subnet, and allow only the ports your services require.

8. Codify with IaC. Define your Custom IP Prefix hierarchy, Public IP Prefixes, and Public IPs in ARM templates, Bicep, or Terraform. This ensures reproducibility, audit trails via source control, and safe rollback via redeployment.

13. Further Reading

Azure Documentation

• Custom IP Address Prefix Overview
• Create a Custom IP Prefix — IPv6 (CLI)
• Create a Custom IP Prefix — IPv6 (Portal)
• Manage a Custom IP Prefix
• Public IP Addresses Overview
• IPv6 for Azure Virtual Network
• Azure NAT Gateway Overview
• Azure Public IP Pricing
• Azure NAT Gateway Pricing
• Azure Virtual Network Pricing

RIPE NCC References

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

Azure Architecture & Governance

• Azure RBAC — Custom Roles
• Azure Policy Overview
• Management Groups
• Azure Monitor Activity Log
• Azure Resource Graph

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 onboard a Custom IP Prefix
• Stop Thinking in IPv4: Misconceptions That Sabotage Your IPv6 Deployment — IPv4 reflexes to unlearn before configuring NSGs and firewall rules
• Building an IPv6 Integrated Project Team — cross-functional programme structure for a successful Azure 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.