/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...
Greets,
Jeroen
-------------- 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