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

[AFRINIC-rpd] IPv4 Address Allocation and Assignment proposal

Andrew Alston alston.networks at gmail.com
Tue Jan 22 21:16:09 UTC 2013


Hi SM,

I am going to paste parts from your document as I go and attempt to respond in an almost inline fashion for easier reading... However before I do this... let me say this...

I cannot even begin to express how opposed I am to what is in this policy.  It is misguided, it will create a hike in the fees paid by end users, it creates massive renumbering issues, it increases the complexity of getting space as an end user (drastically), it will result in a SLOWING of allocations rather than the speeding up of such as has been strongly promoted on this list in the last few days, it is inconsistent and ambiguous in parts, and various other reasons.

This document would require a complete and total rewrite before I could voice support for it, and I view it as EXTREMELY dangerous in its current form.

See below for detailed comments.

Andrew


> 2.1 Internet Registry
> An Internet Registry is an organization that is responsible for distributing
> IP address space to its customers and for registering those addresses.
> Internet Registries are classified according to their primary function.


This clause is vague... define its customers?  Is anyone who asks for and gets granted space by an organization under this definition automatically a customer?  This needs a lot of clarification because its ambiguous and open to interpretation that could lead to serious issues.

> 2.3 Local Internet Registry
> A Local Internet Registry (LIR) is an Internet Registry that receives
> allocations from an RIR and primarily assigns address space to the users
> of the network services it provides.   The users are end users and possibly
> other Internet Service Providers.

Again, this clause creates a problem in the holistic context of the rest of the policy.  It effectively means that you are removing direct assignments by the RIR, and then forcing an end user to choose his LIR in conjunction with his ISP, and I have an issue with that.  If you are forcing the use of an LIR on someone, you can't really force them to pick a specific LIR based on pre-determined criteria (like who their ISP is)

> 2.5 Internet Service Provider
> An Internet Service Provider (ISP) assigns IP address space to the end users
> of a network service it provides.  Its customers can be other ISPs.

This definition is incorrect - it is entirely possible to be an ISP that provides network services without fulfilling the functions of an LIR, and I know of such cases. (rare, but possible)

> 2.6 End User
> An end user or end site has a legal or commercial relationship (the same or
> associated entities) with an Internet Service Provider.

This in combination with 2.5 makes things even more complicated and messy.

> 2.8. Assign
> Assign means to delegate IP address space to an Internet Service Provider or
> End User for their operations.
> Assignments must only be made for specific purposes documented by the
> organisations and are not to be sub-assigned to other parties.

I cannot even voice how strongly I oppose the above clause.  It is the responsibility of the RIR to know that address space is being within a network that is reachable from the Internet (I.E globally routable space).  It is *NOT* the function of an RIR to know the specific purpose of that usage.  Under this clause the assignee would have the right to request information that could be considered confidential and is not the business of an LIR *OR* an RIR.  If I state and can prove I have sufficient devices to warrant X amount of space, I should NOT have to reveal anything beyond that.  Since when does getting IP space mean I have to reveal my business to the assigner?

> 2.10 Provider Independent IP Address Space
> Provider Independent (or portable) IP address space cannot be aggregated
> and can only be assigned by a RIR through an LIR.  Provider Independent (PI)
> IP address space is expensive to route and might not be globally routable.
> Sub-allocations cannot be made from this type of IP address space by the
> end user or LIR.

This clause has me choking slightly.  Firstly, PI space being expensive to route... that is complete and total nonsense.  It is not more expensive other than the marginal cost of an ASN to route than any other space.  Secondly, I STRONGLY oppose the removal of direct allocations by the RIR.   We already have the most expensive RIR fees in the world, and all this proposal would serve to do would ensure that end users have to pay LIR style fees when the LIR has to cost recover the fees.  While I realize this is a very clever and very well disguised way to push up AfriNIC revenue (though I do not say that is necessarily the intent), it is bizarre in the extreme.  I point out as well that up until the previous RIPE AGM direct assignments through RIPE NCC *WERE* possible according to what I have been told, and this only changed after soft landing / exhaustion phase kicked in.  There is no possible way to justify this stance, and it is completely out of line with the operations of all of the other RIR's. 
This clause reminds me HORRIBLY of a proposal made by the ITU in Egypt in 2005 to stop direct allocation from the RIR's and force it through country internet registries in a misguided attempt to seize control of IP routing.  I opposed that, I oppose this.

> 4.3 Aggregation
> Distributing IPv4 addresses in a hierachical manner permits the aggregation of
> routing information.  This helps to ensure proper operation of Internet
> routing, and to limit the expansion of Internet routing tables.

Your proposal to force PI allocations through LIR's is in direct contradiction of this.  There is no way you can force someone to use the same LIR for multiple applications.  This means that there is no way to assign on wider boundaries allowing for contiguous allocations upon second allocation request if the person choses to use two different LIR's for his applications.  This breaks aggregation and results in route table bloat.  

> 5. Documentation
> The decision-making process for each allocation or assignment shall be
> documented to ensure that the process is fair.  Documentation should conform
> to well-known practices.  Estimates and predictions must be realistic and
> justifiable.

I oppose the use of the term "well-known" practices, it is ambiguous, open to interpretation and could mean anything.  Well known by who?  Just because I know of a practice that says one thing, and 10 of my friends do, does not make it well known.  
Either define this or scrap it.

> 6. Registration Requirements
> An allocation or assignment is valid as long as the criteria on which the
> original allocation or assignment was based are still in place, the purpose
> for which the request was made has not changed, and it is registered in the
> AfriNIC Whois.  The registration data (name, range, contact information,
> status, etc.) must be kept up-to-date.

I oppose this on the grounds that business purposes do change.  Provided I still have hardware to number and the space is still in use there is no way anyone should have the right to reclaim the space because my business purpose has mutated.  I might remind you, one of the tier-1 ISP's of the world was originally a mining company (they still are incidentally),  are you going to revoke their space because they moved from mining to service provision?  That is what this clause would effectively allow.

6.1 last sentence reads:
AfriNIC shall inform the community that the IPv4 address block is once again
available.

This is based on cancellation, and just because AfriNIC cancels a registration, does not mean the space is actually available again.  You assume that the person they attempted to reclaim it from has actually stopped using it.  There are no guarantees anyone will ever give back space, and we all know that.  It's not really enforceable.

7.1. 
Justification is based on a combination of immediate need and existing usage
of IPv4 addresses.  Existing assignments of IPv4 addresses should be
renumbered into the LIR's new allocation.

SAY WHAT?! RENUMBER? No, No, and NO.  This is COMPLETELY impractical, it is MADNESS.  The costs associated with a renumbering exercise can be *massive*, the time constraints *HUGE* and the downtime *LONG*.  Sorry to say this, but this clause demonstrates a complete and total lack of experience with any large renumbering exercise.  Have you ever attempted to renumber a couple of hundred servers in one go that are live and doing massive traffic 24 hours a day?  Come on... this isn't April Fools day.

7.4 / 7.5

I have issues with this.  What you are saying is, people are forced to use an LIR to get space.  If they want a large block of PI space, they are still forced to use an LIR.  Since the chances are that NO LIR is going to be given permission to allocate large blocks of space, these have to be referred back to AfriNIC anyway.  All this does is delay the process and create chaos.  If you want a clause restricting the size of space by an LIR, then anything above that space should be open for direct assignment from the RIR if it is an end user (PI) application.  Hence I oppose this.

7.5 Maximum Allocation
The recommended maximum allocation is a /10 IPv4 address prefix length.

This clause is kind of pointless in the last days of IP space...

8.1
A LIR must obtain approval from AfriNIC approval for all sub-allocations above
its Sub-Allocation Window (see Section 9 for Sub-Allocation Window).

See opposition to 7.4/7.5 above 

8.2 Reservations not supported
End users cannot reserve IPv4 address space based on long term plans as this
affects fair distribution and fragments the IPv4 address space when initial
forecasts are not met.  A LIR assigning IPv4 address space to end users must
make the assignments from any unallocated or unassigned address space it
currently holds.  All IPv4 address space reserved by an LIR for its end users
is considered as unused.

I oppose this, define long term plans?  3 months? 6 months? a year? Let me point out here that on a larger tender process / equipment procurement process you can look at (kinda minimums), two weeks for RFQ response, a week for evaluation, 6 weeks for equipment delivery and possibly a few weeks for implementation.  Even if you put the implementation at a week, thats 10 weeks or almost 3 months.  No sane person is going to procure masses of hardware without knowing full well they have IP space to make the use of that hardware viable.  Reservations such as these are critical for any large organisation that is planning large deployments.

 8.5
IPv4 addresses used solely for connecting an end user to an LIR (e.g.,
point-to-point links) are considered as part of the LIR's infrastructure.
These addresses should be registered as part of the LIR's infrastructure.


I oppose this, if an end user chooses to use part of his space for the point to point on any uplink, that is his decision and should not be dictated.  (And it happens often, I can think of at least 10 cases just off the top of my head where this has happened)

I oppose clause 9, see comments on 7.4/7.5

I oppose clause 9.1, same reason.  I especially oppose the ambiguity introduced by 9.1.c.iii  If you want to refer to abuse or misuse, define them

I oppose clause 10c.  Written correspondance between an ISP and its customer is often business confidential and may not be limited in one communication to address allocation issues.  Provided that the end user is correctly using the space and this can be proved/justified (and when I say correctly using it, I mean, its on devices and its routed), such correspondence is not the business of AfriNIC.






More information about the RPD mailing list