[ppml] Policy Proposal 2003-15: IPv4 Allocation Policy for the Africa Portion of the ARIN Region

[Leo Bicknell]

In a message written on Wed, Sep 24, 2003 at 11:46:46AM +0200, Adiel AKPLOGAN wrote:
> *** for those wondering why ISP can not get IP from their upstream?
> One reason can be the coast for raising their
> membership level (category) according to the RIR fees model.
> Using more IP address by providing smaller blocks to their
> down stream can and up at their end  with the need to move
> to higher membership level and then paying more for IP block
> allocated to them....

I can see this is a very legitimate problem.  ARIN fees when
translated to local currency and put in the context of an ISP's
budget may be much more of a burden.  I don't think anyone wants
the ARIN support fee to prevent people from getting the IP's they
need, so if that's a problem we should get some economic data and
look at how we can make the fee less of a burden to African ISP's.

In a message written on Wed, Sep 24, 2003 at 01:15:16PM +0200, leo vegoda wrote:
> Our policy applies to the whole of the RIPE NCC service region. We
> do not have any policies that apply to a sub-set of countries within
> our region.
[snip]
> We have 69 active LIRs in the part of Africa served by the RIPE NCC.
> We have made 149 IPv4 allocations to these LIRs (about a /12 when
> combined) and assigned 49 AS Numbers. 
> 
> We have made eight PI assignments to network operators in Africa
> since July 2001. There were all between /24 and /22. 

So, is ARIN or RIPE assigning space in Africa?  From the discussion
so far it seems both are assigning space.  This surprises me, as I
thought things had been divided up geographically.  I don't think we
want two (or more) people assinging space to the same group.

In a message written on Wed, Sep 24, 2003 at 10:32:14AM +0100, Michael.Dillon at radianz.com wrote:
> It was already pointed out that portable space is needed for multihoming
> and, in Africa, there are more frequent outages for single-homed
> providers, therefore in order to increase service levels a provider
> needs to multihome. And since these are smaller companies on average
> it makes sense to allocate them smaller portable blocks to avoid
> wasting IP addresses.

Portable space is not /needed/ to multihome.  Portable space, in
many cases, makes multi-homing easier, but there are more than a
few ways to do it without.

> Since current policies make it impossible for African ISPs to get
> portable blocks, current policies are making multihoming impossible
> therefore current policies are an indirect cause of low service
> levels in Africa.

s/African ISPs/small providers in the ARIN service region/
s/in Africa/in areas where only a small ISP exists/

While the African's may have brought this up with their proposal,
this is not a situation unique to them.  They may well be the largest
affected group though.

> In this special case, I don't see a problem with setting special policies 
> for one geographic area. This is a transitional policy that is part of the
> process of setting up an African RIR to handle the needs of ISPs that are
> now served by RIPE and ARIN and APNIC. I would be opposed to special 
> policies
> for California or Newfoundland but I support them for continental Africa.

I guess we will just have to disagree on that point.  I am a firm
believer that RIPE, ARIN, APNIC, and any others that come along
should have the same rules for allocating IPv4 space.  There are
two simple reasons, first, it is a global resource, and second if
they are different companies that are able to span regions will be
at an advantage by being able to pick and choose.  While I don't
know the exact players, I'll bet there's at least one international
ISP in Africa that gives away IP's like water because they have a
larger allocation from somewhere else (eg, the old "you get a /24
with every T1" sort of sales campaign).  Differing policies fuel
that sort of abuse.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20030924/c1c36ee3/attachment.sig>