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/