[ppml] [GLOBAL-V6] How to get a IPv6 /32 the cheap way: go to AFRINIC

[Jeroen Massar]

JORDI PALET MARTINEZ wrote:
> Jeroen,
> 
> This is just ridiculous.

What is ridiculous is that /32's are getting wasted and will never be used.
What is also ridiculous is that RIR policies are trying to avoid end-sites
getting /48's in some places who need it to 'control routingtable entries'
but then this shows up as a full /32 that never will be used.

Now *THAT* is what is ridiculous.

I have no problem at all with an organization receiving a justified /48, but a
/32 for an organisation that will never ever use more than a /40 is ridiculous.

> All the RIRs have their own /32 for their internal usage.

APNIC has one indeed: 2001:dc0::/32 but the rest doesn't.
ARIN has a 2001:500::/48 which is more correct, they won't need much more.
Where exactly is the one for RIPE, ARIN and LACNIC? See that is not !ALL!

RIPE even went so far to use 2 /48's (SURFNET+BIT) to avoid coming into the
mess of being preferential to themselves.

Also, since when is a RIR special in anyway?
Also, since when do those networks justify the need of 65536 /48's?

The point is not about AFRINIC, it is about wasting address space without
justification.

Alain Patrick AINA wrote:
> This does not meet the requirements above. So you won't get it.

It fully does, how else did AFRINIC assign a /32 to themselves?

Nick Hilliard wrote:
> Frankly, I fail to see the problem here.  IMO, bona-fide LIRs should be
> entitled to an ipv6 allocation under these terms at least in the RIPE
> region.

I agree that when an organization can justify (using HD ratios etc) the need
for address space that they will fully be able to get that address space
without any issues. But is AFRINIC (10-50 people) able to justify a /32 based
on that?

Greets,
 Jeroen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 311 bytes
Desc: OpenPGP digital signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070622/b7c0ab75/attachment.sig>