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

[AFRINIC-rpd] Questions about IPv4 Allocation Policy AFPUB-2005-v4-001

McTim dogwallah at
Wed Nov 13 12:42:41 UTC 2013

On Wed, Nov 13, 2013 at 4:15 AM, Keshwarsingh Nadan <
keshwarsingh.nadan at> wrote:

> Dear Community,
> I realize that this isn't the proper list for this specific question, but
> since there isn't another active list to post to, I'm posting it here.
> I need the authors comment as well as members.
> Section 7.3 of the IPv4 Allocation Policy states the following:
> In order to properly evaluate requests, an RIR must carefully examine all
> relevant documentation relating to the networks in question. Such
> documentation may include network engineering plans, subnetting plans,
> descriptions of network topology, and descriptions of network routing
> plans.
> All documentation should conform to a consistent standard and any estimates
> and predictions that are documented must be realistic and justifiable.
> Section 8.4 of the IPv4 Allocation Policy states the following:
> An LIR may receive an additional allocation when about 80% of all the
> address space currently allocated to it has been used in valid assignments
> and/or sub-allocations. A new allocation can also be made if single
> assignment or sub-allocation requires more addresses than those currently
> held by the LIR.
> Reservations are not considered as valid assignments or sub-allocations. It
> may be useful for internal aggregation to keep some IP blocks free for
> future growth. These internal reservations are however not counted as valid
> usage and must be assigned or sub-allocated before requesting for an
> additional allocation.
> AFRINIC will always try to allocate contiguous address ranges, allowing the
> LIR to minimise the number of route announcements it makes. However, it
> will
> not always be possible to allocate a range contiguous with the LIR's
> previous allocation.
> Based on above sections of the policy, I, LIR-AAA needs another allocation
> since I ran out of IP space for the following reasons:
> a) I provide hosted services such as accounting / crm / erp on a Software
> as
> a Service (SaaS) basis.
> b) I am utilizing more than 80% of my previous allocation in valid
> assignments, which is assigned to my infrastructure since the IP space is
> being
> used to provide SaaS based service.
> Business Model:
> - CLIENT-BBB leases / outsources hosted service from LIR-AAA.
> - CLIENT-BBB resells the leased / outsourced hosted services to their own
> client, CLIENT-CCC.
> - CLIENT-CCC resells the hosted services purchased from their supplier
> CLIENT-BBB to their own customer base and the public in general.
> For facilitating evaluation procedures, LIR-AAA exceptionally granted
> AfriNIC a remote access to its infrastructure though a live remote session
> since AfriNIC hostmasters primarily liaise with LIRs in the telco industry,
> AfriNIC needs to fully understand:
> - The business model.
> - Why the service requires a whole IP space.
> - How the service works.
> - Peak sessions.
> AfriNIC insists that in order for LIR-AAA to comply with the current
> policy,
> AfriNIC needs to establish the existence of the end-users, i.e. CLIENT-CCC
> customers. Information requested:
> - Name of companies.
> - Physical address.
> - Contact persons.
> - Email addresses.
> - Phone numbers.
> - Contact them if necessary.
> Everyone seems to interpret the policy in his/her own way. In short:-
> - Is AfriNIC allowed to request such information for evaluation purposes
> according the current policy based on my business model, i.e. offering SaaS
> based services?

IMHO, yes.  But your biz model doesn't matter.  It's the usage of IP
addresses that matter.

> - Is AfriNIC generally allowed to request such information for evaluation
> purposes according to the current policy ?

see above.


"A name indicates what we seek. An address indicates where it is. A route
indicates how we get there."  Jon Postel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the RPD mailing list