Changing subject for these replies which will definitely be a bit on the quite mean side... no offense but start reading for once. Next to that there are also LIR courses which cover all of this. (see other mail for /56 for end-user-sites, /48 for end-business-sites) Mikael Abrahamsson wrote: [..]> So, out of our /32, if we assign each customer a /48 we can only
support 65k customers.
Can I read from this that you never actually read any of the $RIR policy documentation about getting IPv6 address space even though you did request a /32 before, clearly without thinking about it?
So in order to support millions of customers, we need a new allocation
"new" as in "We already have one, but we actually didn't really know what we where requesting, now we need more" and I would really like for each new subnet allocated to
be very much larger so we in the forseeable future don't need to get a newer one. So for larger ISPs with millions of customers, next step after /32 should be /20 (or in that neighborhood). Does RIPE/ARIN policy conform to this, so we don't end up with ISPs themselves having tens of aggregates (we don't need to drive the default free FIB more than what's really needed).
This explains quite a bit why people are looking so weird when certain other organizations get a /20 and upward from $RIR. My suggestion: start reading.
Other option is to have more restrictive assignments to end users and therefore save on the /32, but that might be bad as well (long term).
That would be stupid and totally against the idea of IPv6. Andy Davidson wrote: [..]
From the RIPE perspective, there are seven "empty" /32s between my /32 and the next allocation.
I imagine this is fully intentional, and allows the NCC to grow my v6 address pool, without growing my footprint in the v6 routing table.
That is exactly what it is for. Then again, if you actually had *PLANNED* your address space like you are supposed to when you make a request you could have already calculated how much address space you really needed and then justify it to the $RIR. In case you have to go back to ask the $RIR for more you already made a mistake while doing the initial request... Greets, Jeroen