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

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 NCC address pool and is yours to announce from any network, whether 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 NCC 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 NCC 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, which is 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 NCC lifecycle in the background. Understanding this lifecycle helps you see where Azure BYOIP fits within the broader picture.

4.1 Lifecycle Overview

4.2 What Happens at Each Stage

4.3 How This Relates to Azure

Your Azure Custom IP Prefix operates alongside isp6's RIPE NCC 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 NCC 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 NCC via isp6 is authoritative.
• Deprovisioning: if you decommission from Azure, your isp6 allocation and all RIPE NCC registrations remain intact. If your isp6 membership expires, the RIPE NCC objects are cleaned up by isp6, so 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 NCC 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, so 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, so 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 NCC through Azure's Custom IP Prefix hierarchy to your workloads.

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, then select your cloud provider and the ASN is populated automatically. isp6 manages RPKI for your allocation. The ROA is published through isp6's RIPE NCC 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 NCC 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, and isp6 will update the public key on the RIPE NCC 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

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 NCC registrations remain intact throughout.

Your allocation stays yours. Decommissioning from Azure does not affect your isp6 membership, your RIPE NCC 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 NCC 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, because retrofitting a numbering plan is painful.

4. Monitor RPKI via your isp6 dashboard. Your isp6 subnet dashboard shows RIPE NCC 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, with 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 NCC: Managing ROAs
• RIPE NCC: 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
• Reference Architectures: Microsoft Azure: the production topology this guide enables: hub-and-spoke with Azure Firewall and Application Gateway, and multi-region with Virtual WAN
• 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.