[101137] in North American Network Operators' Group
/48 for each and every endsite (Was: European ISP enables IPv6 for
daemon@ATHENA.MIT.EDU (Jeroen Massar)
Wed Dec 19 07:25:48 2007
Date: Wed, 19 Dec 2007 13:24:16 +0100
From: Jeroen Massar <jeroen@unfix.org>
To: Andy Davidson <andy@nosignal.org>
CC: Mikael Abrahamsson <swmike@swm.pp.se>, nanog@merit.edu
In-Reply-To: <47EF52C3-5A24-4753-9EBF-672CCCEED792@nosignal.org>
Errors-To: owner-nanog@merit.edu
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig698E44DE4DFEDF94D88FD6F2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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.
>=20
> 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
--------------enig698E44DE4DFEDF94D88FD6F2
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
iD8DBQFHaQ1zKaooUjM+fCMRAvGEAJ4iMTKR2IpiqRop1atLXOTUNnYLBwCghfV6
U1c9uZRComx1rIlqnqhqXqk=
=+djQ
-----END PGP SIGNATURE-----
--------------enig698E44DE4DFEDF94D88FD6F2--
