[AFRINIC-rpd] IPv4 Address Allocation and Assignment proposal

[sm+afrinic at elandsys.com]

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