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

[Jeroen Massar]

Adiel A. Akplogan wrote:
> Hello Jeroen,
[..]

>> Gee, the RIR itself. How many people are using the AFRINIC network?
>> 10-50? Are they really *ever* going to need more than a /48? Are they
>> ever going to have a need for 65536 of those /48's?
> 
> You can not take AfriNIC own allocation case to illustrate your
> assertion here

Why not? Is AfriNIC special, is AfriNIC outside of the policy rules set by
their own membership? What does make AfriNIC so special to not even consult
the rest of the world, let alone your membership, in making these decisions?

So why did that not happen in the first place?

> We have allocated that bloc to our own Infrastructure (which has three
> locations to be connected together) so each with its own /48. Further
> to that we have other IPv6 Internal projects which will probably
> require several /48.

I can fully understand a /48 per 'location', especially when they are
administratively separate and/or very remote from each other. But you will
never reach more than 50 of those locations.

Those are a large amount and big projects AfriNIC is (going to) run then.
By going to provide these services don't you think you are going against your
membership, who only recently got the hard policy of only getting a /48 and
they have to fully justify it. Or does AfriNIC think that everybody will be
eligible for a /32?

Also, is AfriNIC really going to use a full /32 with a staff of what 10-50
people or even less than that? AfriNIC is not an ISP as far as I am aware,
unless some other business ventures unrelated to you being a RIR is being
tapped into. As such, hosting projects is not an option either as that would
mean you get clients, and that would be the only way that you could justify
having a need for multiple /48's in that area.

Can you clarify?

> As RIR I think we are in the position to evaluate
> our own need before making an allocation and if it
> was made be sure that is after careful evaluation.

Can you please explain again why a *RIR* (Regional Internet Registry) will be
using 65536 /48's in the coming, lets take a liberal, 10 years?

Can you show FULL justification for this?

Just as a little example, there is a little RIR, one of the older ones, you
might know them as "RIPE", they have been around for a long time and helped
AfriNIC get off the ground. They are running a LOT of big projects and doing a
lot of community work. Still they did not allocate a /32 to themselves, or a
/48 for that matter. They are using two /48's from ISP's who donated those
prefixes to them.

This as their membership decided for them that a RIR is not special and also
because they don't claim (_afaik_) to need that kind of address space. A /48
is sufficient for them.

Another good example is another little RIR, called ARIN, they also only have a
single /48 for their own network, also granted under the policy as specified
by their membership.

How come that AfriNIC doesn't think that a /48 or max a /40, under your own PI
policy which was recently approved by your membership is not good enough.

Is AfriNIC special on this planet?

>> Really this is just a waste of address space. Yes there is "enough",
>> but being sooo obviously wasteful just to be able to have a nice slot
>> in the routing
>> tables is a bit over done.
> 
> I don't see  the waist.

I almost am having to ponder asking you how good you are in a role of a RIR if
you can't do the math of 65536 /48's being wasted on this.

I agree, it is nothing compared to the full address space of 128bits, but that
is also what people though about 32bit IPv4 addresses, remind yourself of all
the wailing people are doing about MIT having a /8. This is the exact same
situation.

Except now people are pointing at you when you don't justify the space.
Especially when you are doing it without an appropriate policy in place.

> Please read http://www.afrinic.net/docs/policies/afpol-v6200701.htm

Which is not linked directly from the website, but I did find it from the
email archives. Also that policy specifies one single /48. Not a /32 which is
as you should know 65536 more than that.

Just in case you wonder, as I mentioned already a couple of times also in
other threads, I fully support organizations getting a /48 or upto even a /40
or more. But all as long as they can actually JUSTIFY that space.

Saying "we are RIR, we can do what we want, we will run big projects" is not a
good justification.

>> Funnily later in the above document they point to HD ratios. What
>> point is
>> that when the waste is already happened?
> 
> I think you are confusing the IPv6 allocation to LIR document with PI
> assignment document which in fact was a proposal until few days where
> it was ratified by AfriNIC board (... but not yet implemented).

No I was referring to the following URL which I mentioned in my mail:
http://www.afrinic.net/docs/policies/afpol-v6200407-000.htm#5

Also, clearly if such a policy is not implemented yet, how can AfriNIC itself
make use of that policy then?

>> RIR's should be giving out address space based on "need" and that need
>> must justified, giving out /32's as "those fit in the routing slots"
>> is a really really bad idea.
> 
> That is what we do. You can not have such affirmation based on a single
> case.

You didn't give any valid justification (yet), also you didn't even have a
policy for this kind of allocation.

Doing something once, doesn't mean you didn't break policy, especially when
there is no such policy.

>> In short: if you want a nice /32 without issues: setup a small shop in
>> Africa
>> and presto!
> 
> You won't get it like that.

Then how did you, being AfriNIC get it?

Please elaborate, I am really wondering about how this works. And I very sure
that a lot of other people are also very interested in knowing about these
practices.

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/b9d0a2a3/attachment.sig>