/48 for each and every endsite (Was: European ISP enables IPv6 for all?)

Jeroen Massar jeroen at unfix.org
Wed Dec 19 12:24:16 UTC 2007

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...


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 187 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20071219/15031d1e/attachment.sig>

More information about the NANOG mailing list