Skip to content

/44 or /48? Sizing IPv6 by Site and Region

Audience: isp6 members and prospective members deciding which allocation to order, and cloud and network architects translating that decision into an AWS deployment. This guide sizes by how many independently-routable sites you run. Its companion, Planning Your isp6 Allocation, sizes by bit budget (how deep your internal hierarchy needs to be). Read both, as they are two lenses on the same decision. For the AWS BYOIP mechanics referenced here, see Bring Your Own IPv6 to AWS.

Last updated: May 2026

1. The one rule that decides it

isp6 offers two allocation sizes: a /48 and a /44. There is a lot of arithmetic you can do to choose between them, but most of the time a single rule settles it:

Every site or cloud Region that needs its own internet-facing presence needs its own /48, because /48 is the longest IPv6 prefix the global routing table will carry. A /44 is sixteen /48s.

So the question is not really "how many addresses do I need?" (in IPv6 you will never run out inside a /48) but "how many places will independently announce my address space to the internet?"

  • One place: one data centre, one cloud Region, or a proof of concept → a /48.
  • Several places: multiple Regions, multiple data centres, an active/active estate → a /44, carved into one /48 per location.

The rest of this article explains why the /48 boundary exists, then walks through the single-site and multi-Region cases with AWS reference architectures.

2. Why /48 is the unit of internet routing

A /48 is special. It is the longest (most specific) IPv6 prefix that you can rely on being accepted across the public internet. Network operators routinely filter announcements longer than /48 to keep the global routing table manageable, following long-standing RIPE and operator-community guidance. Announce a /56 or a /64 to the internet and most networks will simply discard it; announce a /48 and it propagates everywhere.

This boundary has direct, practical consequences on AWS:

  • AWS BYOIP advertises a /48 at its most specific. The most specific IPv6 range you can bring and have AWS advertise on the public internet is a /48, exactly the global filtering boundary. (See AWS BYOIP to AWS.)
  • AWS BYOIP is a per-Region resource. You provision-byoip-cidr and advertise-byoip-cidr within a Region. The same /48 cannot be provisioned and advertised from two Regions at once, so a second Region that needs to announce your space needs a second /48.

Put those two facts together and the sizing rule writes itself. The /48 is both the smallest independently-routable unit and a per-Region resource, so the number of /48s you need is the number of Regions (or sites) that will independently reach the internet.

What about inside a /48? A /48 still gives you 65,536 /64 subnets to structure however you like: per-AZ, per-environment, per-service. The /48 boundary is about what the outside world routes, not about how much you can subnet internally. Internal depth is the subject of the bit-budget method.

3. The decision in one picture

The choice runs along a single axis, from the simplest possible deployment to a resilient, globally-distributed estate. As you add independently-routable sites, you add /48s, and sixteen of them make a /44.

A decision spectrum from a /48 to a /44. Left to right, increasing in capability and complexity: a /48 for a proof of concept, a /48 for a single production site, and a /44 for many sites or Regions where each gets its own routable /48.
The sizing spectrum. A /48 covers a proof of concept or a single production site; a /44 covers many sites, giving each its own independently-routable /48.

The three stops on that spectrum map to the three architectures in the next two sections, in order of increasing complexity.

4. When a /48 is the right choice

A single /48 is the right answer whenever your address space will be announced from one place. That covers two very common situations.

4.1 Testing an IPv6 rollout

If you are validating IPv6 before committing, proving that SLAAC, security groups, Egress-only Internet Gateways and BYOIP advertisement all behave as expected, a single /48 in one Region is everything you need. There is no IPAM to stand up and nothing to plan beyond the proof of concept itself; you can provision and withdraw the /48 with a couple of CLI calls.

Testing an IPv6 rollout with a single /48: one AWS Region, one dual-stack VPC, one public /64 subnet with a single test instance, advertised to the public internet, alongside a proof-of-concept checklist.
A proof of concept: one /48, one dual-stack VPC, one subnet, one instance. The simplest possible footprint, ideal for validating IPv6 behaviour before scaling the plan.

Because nothing here is hard to reverse, this is the recommended way to start. Prove the mechanics on a /48, then size your production allocation with confidence.

4.2 A single production site

A single production Region or data centre is also a /48 deployment, just a fuller one. One dual-stack VPC spans two or more Availability Zones, each with public and private /64 subnets, an Internet Gateway for inbound and an Egress-only Internet Gateway for outbound-only private workloads. The whole site advertises a single /48.

A single /48 serving one AWS Region: one dual-stack VPC across two Availability Zones, each with a public and a private /64 subnet, an Internet Gateway and an Egress-only Internet Gateway, advertising the /48 to the public internet.
A single production site on one /48. Two Availability Zones, public and private /64 subnets, and a single /48 advertisement. The 65,536 /64 subnets inside the /48 leave enormous room to grow without ever needing a second allocation.

A /48 here is not a compromise. It is the correct size. You would only outgrow it by adding another routable location, which is precisely the trigger for a /44.

5. When you need a /44: multi-Region and multi-DC

The moment you run in more than one Region or data centre and each needs to reach the internet on its own (for latency, for resilience, or to contain the blast radius of a regional failure), you cross from /48 territory into /44 territory.

5.1 Why each Region wants its own /48

Recall the two facts from Section 2: /48 is the most specific globally-routable prefix, and AWS BYOIP is per-Region. So a multi-Region estate cannot share one /48 across Regions. Each Region provisions and advertises its own /48. Giving every Region a distinct /48 also buys you real operational properties:

  • Regional ingress. Each Region announces its own prefix, so traffic enters close to where it is served rather than transiting from a single advertising Region.
  • Blast-radius isolation. A routing problem, a withdrawal, or an RPKI issue in one Region's /48 does not touch the others.
  • Independent lifecycle. You can provision, advertise, withdraw, or migrate one Region's /48 without coordinating a change across the whole estate.

Sixteen /48s fit in a /44, enough for sixteen Regions or sites, with headroom most organisations never exhaust.

5.2 Reference architecture: a /44 across three AWS Regions with IPAM

At multi-Region scale, manage the space with Amazon VPC IPAM. Bring your isp6 /44 into a top-level IPAM pool, then carve a regional /48 pool for each Region. Each Region's VPC draws a /56 from its regional pool, subnets take /64s, and each Region independently advertises its /48.

AWS multi-Region deployment: a single isp6 /44 brought into Amazon VPC IPAM, which allocates one /48 to each of three Regions (eu-west-2, eu-central-1, us-east-1); every Region runs a dual-stack VPC with public and private subnets and advertises its own /48 to the public internet.
A /44 across three AWS Regions. VPC IPAM holds the top-level pool (2001:db8:1000::/44) and hands one /48 to each Region; each Region advertises its own /48. Thirteen further /48s remain for new Regions, accounts, or sites.

This is also the natural shape for a multi-account strategy: hand one /48 per account (or per account and Region) from IPAM, and every team gets a clean, independently-routable block without renumbering. The same pattern applies beyond AWS: a /44 lets you put a /48 in a colocation facility, a /48 on-premises, and a /48 in each cloud, all from one isp6 allocation and all portable via BYOIP.

6. /48 vs /44 at a glance

/48 /44
Independently-routable blocks 1 (the /48 itself) 16 × /48
/64 subnets 65,536 1,048,576
Best for Single site, single Region, proof of concept Multi-Region, multi-DC, multi-account, active/active
AWS footprint One Region, one BYOIP CIDR One /48 provisioned per Region
IPAM Optional: CLI is fine for one /48 Recommended: top-level pool + regional /48 pools
Internet advertisement One /48 from one Region One /48 from each Region, independently
Headroom 65,536 /64s inside one site 16 routable locations
Order from isp6 isp6 membership isp6 membership

A useful tie-breaker: if you can foresee a second routable location within the life of the deployment (a DR Region, a new market, a cloud migration), order the /44 now. Adding the sixteen-fold headroom up front is far cheaper than renumbering or stitching together discontiguous /48s later.

7. Common sizing mistakes

Mistake Why it bites Do this instead
"We'll just announce a /56 per Region from one /48" Anything longer than /48 is filtered on the public internet, so the /56 never propagates Give each Region its own /48 (so, a /44)
Sizing a single site as a /44 "to be safe" A /48 already holds 65,536 /64s; the extra bits add nothing for one routable location Order a /48; revisit only when a second location appears
Treating /44 vs /48 as purely an address-count question IPv6 address counts are effectively unlimited at both sizes; the real driver is routable locations and internal hierarchy depth Combine this site-count lens with the bit-budget method
Trying to share one /48 across two AWS Regions AWS BYOIP is per-Region; the same /48 cannot be advertised from two Regions One /48 per Region, carved from a /44
Sequentially packing /48s out of a /44 Leaves no contiguous room for a site to grow or for a new neighbour Apply the bisection method when handing out /48s

8. How this maps to your isp6 order

Sizing the allocation is your decision; registering and maintaining it is isp6's.

Activity Owner
Counting routable sites / Regions and choosing /48 or /44 You
Allocating the /48 or /44 from isp6's RIPE NCC pool isp6
inet6num and route6 registration in the RIPE Database isp6
RPKI ROA creation and propagation monitoring (incl. cloud-provider ASNs) isp6
Reverse DNS delegation isp6
Carving the allocation into per-Region /48s and per-VPC /56s (IPAM) You
AWS BYOIP provisioning and advertisement, per Region You, see the AWS guide

Whichever size you order, the allocation is portable PA space: you can announce it from AWS, Azure, Google Cloud, a colocation facility, on-premises, or several of these at once, and move it between them for the life of your membership, without renumbering on the consumer side. That portability is exactly what makes the /44 multi-location pattern in Section 5 work.

9. Further reading

RIPE NCC and IETF references

AWS documentation

Not sure whether to order a /48 or a /44?

Count the sites and Regions that will announce your space to the internet. One location is a /48; several is a /44. isp6 allocates either from its RIPE NCC pool, registered in the RIPE Database within minutes and portable across every cloud, colo, and on-premises network for the life of your membership.

Get your /48 →

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.