Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

[AfriNIC-rpd] Updated Version of the "IPv4 Soft Landing Policy"now Available Online

Andrew Alston aa at tenet.ac.za
Thu Feb 24 16:36:48 UTC 2011


> 
> That's not what this clause does. Here's how I think it goes for African
> companies with this clause:
> 
> 1. They will soon be unable to get additional IPv4 space to use in
> significant proportion off-continent.

Correct

> 
> 2. They will be able to continue to expand IPv4 on-continent for
> a year or two more.

Yet we're saying they need to go IPv6 and we need to encourage that, why are
we trying to prolong a resource that the rest of the world will have been
forced to abandon.

Further more, this clause is unenforceable and will not stop the pillaging
of African IP space, and if you believe it will, once again, I ask you,
please explain to me HOW it will be enforced, HOW you will stop the use of
IP space off the continent, and HOW you will tell where it is being used.

I've asked that before, and I've yet to get an answer.

> 
> Here's how it goes without this clause:
> 
> 1. They will soon be unable to get additional IPv4 at all.

That's going to happen anyway, we can't enforce this, we cannot stop people
pillaging the space, hence my policy proposal to allow of out region
membership of AfriNIC post another region RIR depleting

> 
> 2. Foreign companies will set up African shells or whatever else
> is needed in order to export addresses from Africa for their
> purposes, removing the address resources from the reach of
> African companies regardless of where they wish to deploy them.

There is nothing in this policy that stops them doing it anyway, we can't
enforce it.  Further more, I can give you a fairly good technical run down
on how companies can do this anyway by announcing the space in Africa and
still "using" it outside, at which point, the space is used in Africa, there
are null routes which put the IP space into the RIB to allow BGP to announce
it, so the space is actively routed, the network statements ore distribution
are happening in the African continent, the space is then pushed out in iBGP
until it reaches the edge off continent and enters a transit provider.  When
someone comes back in, they will follow the deaggregated IGP on the network
to whereever the hell the space is actually assigned to systems / point to
points / whatever, and the space is now also used out of region.  So, where
is the space being used?  You want a policy that restricts usage, you better
start defining what you mean by usage

> 
> I don't see how African companies IPv4 expansion to other continents
> is facilitated in either case. Can you please explain how you think
> it would be?

Without the clause at least Africans will have the option of attempting to
get the space before its pillaged and doing this, with the clause, they cant
do it, and the space gets pillaged anyway.

> 
>> When the other RIRs cant offer you space and you want to expand, and the
>> only space you can get in the V4 world is from AfriNIC, are you going to
>> happy when you're told you can't use the space for your expansion?  Are you
>> prepared to be forced to renumber your networks into your new allocations so
>> you can use your old allocations off continent?  Do you believe that there
>> is no scope for you as an African company to expand beyond this continent
>> and join the global market?
>> 
> Without this clause, when the other RIRs can't offer you space, AfriNIC won't
> be able to, either.

With this clause if the pillaging happens, the same will apply, without this
clause, at least you can get some space WHILE the pillaging is happening and
there is still some left :)

> 
>> I challenge EVERY African to really think this through, and ask yourself, do
>> you want these limitations?  Personally, I know I don't
>> 
> I challenge you to really think this through and consider what ACTUALLY
> happens to African companies without this clause.
> 
I have, long and hard, with this clause, the space is still pillaged, used
off continent and no one outside of the AfriNIC region will give a damn if
this clause exists or not anyway.

I wonder how many Africans with AfriNIC IP space have ever bothered to read
the policies much less adhere to them, cause I know several institutions who
you could query on AfriNIC policy who couldn't tell you a word of what it
says.  If you believe that the rest of the world is going to care when IP
space runs out and money starts talking about what a completely
unenforceable, impractical policy says, well, more power to you, I
personally am a little more pragmatic and abandoned idealism in the face of
harsh reality a long time ago



Andrew

> Owen
> 
>> Andrew
>> 
>> 
>> 
>> On 2011/02/24 3:29 PM, "McTim" <dogwallah at gmail.com> wrote:
>> 
>>> On Thu, Feb 24, 2011 at 1:20 PM, Andrew Alston <aa at tenet.ac.za> wrote:
>>>> 
>>>> 
>>>> <SNIP>
>>>> 
>>>>>> 
>>>>> As has been pointed out by others, the probability of African ISPs
>>>>> making significant off-shore expansions in IPv4 is somewhere between
>>>>> slim and none, so I tend to doubt that this is anything more than a
>>>>> straw man argument.
>>>> 
>>>> Errrr the possibility is slim to none?  Ok, so hold on, lets look at a few
>>>> things for a second.  MTN is currently in the top 10 largest cellular
>>>> networks in the world, and one of the largest by market cap, they didn't do
>>>> this by not expanding, they are an ISP.
>>>> 
>>>> Vodacom is a large company, with the potential for market expansion.
>>>> 
>>>> Anglo Gold and Debeers Mining both are African companies with HUGE
>>>> international holdings, what happens when they need more space?
>>> 
>>> They need to shift to IPv6.
>>> 
>>> 
>>> They aren't
>>>> an ISP so they don't count or something?  So P.I space can then be
>>>> specifically excluded from this clause?  Or not?
>>> 
>>> 
>>> no, addresses are addresses.
>>> 
>>> We have been talking about this one for 2 years, and we finally got
>>> consensus on it.  I would say that the part that you are objecting to
>>> has historically had the most support of any of the bits of this
>>> policy.
> 




More information about the RPD mailing list