[AFRINIC-rpd] IPv4 Address Allocation and Assignment proposal

[Andrew Alston]

Hi SM,

I have to say your comments inline having read through them do nothing to actually endear my support for this policy.  They indicate what I think has been highlighted time and again on this list in the last few weeks, the requirements to get IP space from AfriNIC at the moment are complex and difficult and rigorous.  There have been multiple people who have commented that perhaps a loosening of the reigns is necessary and a change in existing policy is necessary to increase the current burn rate.  What this policy does is take everything that is negative about the current policy, duplicate it into a more modern policy and add more negative aspects.

Just because its in current policy does NOT mean that its necessarily sane and is no justification for using it in a new, draconian, complex and dangerous policy that could have extremely dangerous implications

Andrew

On 23 Jan 2013, at 12:35 AM, sm+afrinic at elandsys.com wrote:

> Hi Andrew,
> At 13:16 22-01-2013, Andrew Alston wrote:
>> 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.
> 
> Noted.
> 
> I'll comment inline.
> 
>> 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.
> 
> Ok.
> 
>> 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.
> 
> This is the text from the existing policy which has been in effect since 2006:
> 
>  "An Internet Registry (IR) is an organization that is responsible for
>   distributing IP address space to its customers and for registering those
>   addresses. IRs are classified according to their primary function and
>   territorial scope within the hierarchical structure."
> 
> "customers" is not defined in the existing policy.
> 
>> 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)
> 
> This is the text from the existing policy:
> 
>  "A Local Internet Registry (LIR) is an IR that receives allocations from an RIR and
>   primarily assigns address space to 'end-users'.  LIRs are generally ISPs. Their
>   customers are other ISPs and possibly end-users. LIRs must be members of AfriNIC."
> 
> The intent is not to change direct assignments by the RIR if that is covered by other existing policies.  If that is what the text says when taken together with other existing policies, I suggest looking into what should be changed.
> 
>> 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)
> 
> The existing policy does not define "ISP".  By the way I mentioned that case to Owen Delong.
> 
>> This in combination with 2.5 makes things even more complicated and messy.
> 
> Yes.  The problem is how to fit in the wording with what's in the existing policy.
> 
>> 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?
> 
> This is the text from the existing policy:
> 
>  'An assignment is an IP block given by an LIR to the end-users for their own usage.
>   To "assign" means to delegate address space to an ISP or End User for specific use
>   within the Internet infrastructure they operate. Assignments must only be made for
>   specific purposes documented by specific organisations and are not to be sub-assigned
>   to other parties.'
> 
> I am not suggesting that you should reveal your business to the assigner.  If the existing policy needs to be changed it might help if the text is discussed to determine what would be satisfactory to everyone.
> 
>> 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.
> 
> This is the text from the existing policy:
> 
>  "PI (or portable) space cannot be aggregated and can only be assigned by RIR through
>   an LIR. PI space is expensive to route and might not be globally routable.
>   Sub-allocations cannot be made from this type of address space by the end user or LIR."
> 
>> 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.
> 
> This is again text from the existing policy:
> 
>  "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 (RFC2519)."
> 
>> 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.
> 
> I wrote that term by the way.  This is the text from the existing policy:
> 
>  "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."
> 
> The alternative is to use "consistent standard".  It may make documentation more difficult.  I am okay if that's what the community wants.
> 
>> 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.
> 
> This is the text in the existing policy:
> 
>  "b) All allocations and assignments will be registered in an AfriNIC database.
>      Any unregistered assignemnts / allocations / sub-allocaion will be considered
>      invalid. The registration data (name, IP block/range, contacts, status, etc..)
>      must be correct at all times. This is necessary to support network operations."
> 
>> 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.
> 
> In a previous message posted to this mailing list about SLA, it is mentioned that:
> 
>  "A monthly reporting mechanism from AfriNIC that details the following:
> 
>   e.) If there was any space redeemed or returned to the registry,
>      how much space was it"
> 
> Should I remove Section 6.1?
> 
>> 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.
> 
> This is the text from the existing policy:
> 
>  "9.6 Re-numbering
>   ------------
> 
>   This is replacing IP addresses on a one-to-one basis. Valid assignments can be replaced
>   with the same number of addresses if the original assignment criteria are still met. The
>   addresses to be replaced must still be in use. When a renumbering request exceeds the
>   LIR's sub-allocation window, the request should be sent to AfriNIC for approval."
> 
>   A period of three months is normally considered sufficient to migrate a network to the
>   new IP space. Once a network has been renumbered, AfriNIC staff will remove the old
>   assignment from the AfriNIC database. In case the three months period is not sufficient,
>   the LIR should inform AfriNIC about the additional time they might take to completely
>   renumber."
> 
>> 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.
> 
> This is the text from the existing policy:
> 
> "8.5 Sub-Allocations
>  ---------------
> 
>  The minimum size of a sub-allocation is /24. It allows a reasonable number of small
>   assignments to be made by a downstream ISP. An LIR may not sub-allocate IPv4 space
>  above its suballocation window  (see section 10.0 for sub-allocation windows).
> 
>  LIR's may make sub-allocations to multiple downstream ISP's. (Downstream ISP's
>  efficiently using a sub-allocation qualify to receive a /22 allocation should
>  they want to become an LIR).
> 
>  The LIR is responsible for ensuring that address space allocated to it, and
>  subsequently, the address space that it sub-allocates, is used in accordance
>  with the community's policies and guidelines.
> 
>  LIRs are advised to make use of the slow-start mechanism when making sub-allocations
>  to downstream ISPs. Here, the LIR ensures that the space sub-allocated is efficiently
>  used and the LIR can also monitor and determine the ability of the downstream ISP to
>  operate within the policies set by the community.
> 
>  Sub-allocations form part of an LIR's aggregatable space. Therefore, an LIR should
>  ensure that IP space is not retained by the downstream ISP if the reseller
>  ceases to obtain connectivity from the LIR's network (sub-allocations are non-
>  portable)."
> 
>> 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...
> 
> Section 7.5 is based on the following about IPv4 fees:
> 
>  "The maximum allocation size at AFRINIC is /10."
> 
> I could not find any existing policy with that text.
> 
>> 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
> 
> This is the text from the existing policy:
> 
>  "LIR's must request approval from AfriNIC approval for all sub-allocations above
>   their Sub-Allocation Window (see section 10.0 for SAW policy)."
> 
>> 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.
> 
> This is the text from the existing policy:
> 
>  "9.4 Reservations not supported
>   --------------------------
> 
>   End-users are not permitted to reserve address space based on long term plans. This
>   violates the goal of conservation and fragments the address space when initial
>   forecasts are not met. If an LIR wants to assign address space for customers, it
>   must make the assignments from any unallocated or unassigned address space it
>   currently holds. For the purposes evaluating allocation requests, space reserved
>   by an LIR for other customers is considered unused."
> 
>> 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)
> 
> This is the text from the existing policy:
> 
> 
>  "9.2 Network infrastructure (of LIR) vs End-User networks
>   ---------------------------------------------------------------
> 
>   IP addresses used solely for connecting an end-user to a service provider (e.g.,
>   point-to-point links) are considered as part of the service provider's infrastructure.
>   Such addresses should only be registered as part of the service provider's
>   infrastructure. When an end user has a network using public address space, this space
>   must be registered with the contacts of the end-user. If the end-user is an individual
>   rather than an organisation, the space may be registered with the contact information
>   of the service provider but with the end-user referenced in the AfriNIC whois database
>   object."
> 
>> I oppose clause 9, see comments on 7.4/7.5
> 
> This is the text from the existing policy:
> 
>  "An sub-allocation window (SAW) refers to the maximum number of IPv4 addresses that the
>   LIR may sub-allocate to the end-users without seeking approval from AfriNIC. The SAW
>   size is expressed in CIDR notatation.
> 
>  AfriNIC will review sub-allocation made by the LIR's using their SAW in to ensure that
>  policies are followed correctly. LIR's should also ensure that documentation for
>  sub-allocation made using the SAW be similar to that requested for larger requests."
> 
>> 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
> 
> Section 9.1 is the same as the existing policy.
> 
>> 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.
> 
> This is the text from the existing policy:
> 
>  "These documents should be kept electronically for easier access. It's advisable
>   that these records should include but not be limited to:
> 
>   o The original request.
>   o Supporting documentation.
>   o Related correspondence between LIR and end-user.
>   o Decision of the assignment, and reasons behind any unusual decision.
>   o Role of person that made the decision."
> 
> As a summing up on the LIR part of the proposal only, you are opposed to what is already in AFPUB-2005-v4-001, the existing policy currently being applied.  It's not that I think that the points you raised are not valid.
> 
> Regards,
> S. Moonesamy