Hi Nick,
When designing a medium to large ISP network, it’s common to split it
into multiple routing areas, each with its own subnet(s) for proper
aggregation.
In my case, as a medium-sized ISP, I wanted to create an address plan
that can scale to around 1 million end-users. A /28 would have made this
possible.
We started small, but want room to grow — redesigning the addressing
plan later would be much more complex.
Since there is plenty of address space available (RIPE already reserves
a /26), why not allow an ISP to start with an allocation that matches
its realistic growth target?
As Jordi also says, If you don't need that from the start, you are free
to go with the smaller /32 (or /31 or /30...)
Here’s the concrete plan:
256 routing areas → needs 8 bits
Up to 4,000 /48s per area → round to 4,096 = 2¹² → needs 12 bits
Total bits from allocation to /48 = 8 + 12 = 20 bits
=> /48 − 20 = /28
This checks out:
256 × 4,000 = 1,024,000 /48s ≈ 2²⁰
/28 provides 2^(48−28) = 2²⁰ = 1,048,576 /48s
A /28 fits this plan with a small safety margin (~24k /48s).
A /29 (2¹⁹ = 524,288 /48s) would not be sufficient in this case.
Regards,
Rinse
On 11/6/2025 7:06 PM, Nick Hilliard wrote:
jordi.palet--- via address-policy-wg wrote on 06/11/2025 14:42:
However, I don’t think this should be taken as the “only real data”
(and consequently % calculated by Nick are not good - we will not
have good data unless every member comes and say if they will have
wanted a shorter prefix).
Jordi,
Just to clarify the figures I quoted: a /29 will provide 2^(48-29) =
2^19 /48s.
In other words, /29 is roughly a reasonable general magnitude for an
organisation with a requirement of up to around 500,000 /48s.
The questions we need to ask are:
1. roughly how many organisations are there in the RIPE NCC service
region that need > 500,000 /48s. I.e. what's the size of the problem
we're trying to solve here?
2. how can we fix the ipv6 allocation policy to help these
organisations get the address space that they need?
If we tweak the netmask one bit to the left, from /29 to /28, then all
that will happen is that we'll be talking about 1m customers instead
of 1/2m, but the underlying problem will still be there, and unsolved.
That is why we need to discuss and try to fix the underlying problem.
Nick
-----
To unsubscribe from this mailing list or change your subscription
options, please visit:
https://mailman.ripe.net/mailman3/lists/address-policy-wg.ripe.net/
As we have migrated to Mailman 3, you will need to create an account
with the email matching your subscription before you can change your
settings. More details at:
https://www.ripe.net/membership/mail/mailman-3-migration/
-----
To unsubscribe from this mailing list or change your subscription options,
please visit:
https://mailman.ripe.net/mailman3/lists/address-policy-wg.ripe.net/
As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings.
More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
