[rpd] Summary of proposals: IPv4 Runout Management

[Andrew Alston]

My Thanks as well,

Owen just to address a few points in your email below that may not be clear.

➢ I like the idea of a reserved carve-out for critical infrastructure.

This was deliberately excluded from the soft landing overhaul proposal as the authors believe that it is already by and large catered for.  Specifically we have the IXP reservation block already, and most CCTLD’s on the continent already have space (and if they don’t, for the purposes of what a CCTLD does there is sufficient time to get the space before this kicks in).  If however you feel that we need to set aside more space for other critical infrastructure, the authors would like to understand what sort of things you feel the space would be used for beyond the current reservations in place under other policies and we could then look at modifying accordingly.

    I like the idea of a small (/12, perhaps) cutout for new organizations that are late to the party to receive up to a /24 for transition purposes.

The authors are happy to consider this, the only question is the size of the space.  The /13 allocation in the overhaul proposal was a specific number chosen based on the approximate number of new members showing up in AfriNIC each year, and this covers for new entrants.  Now, as of the last time I ran my stats (which  was admittedly a couple weeks back), we had approximately 1700 separate members.  With that in mind though, am happy to how much space you propose to reserve for this purpose (I do think a /12 though may be too much)

    I do not like the idea of a large reservation for new entrants to the exclusion of the needs of existing participants.

This is why we deliberately made it pretty small, a /13 caters for 512 members, sufficient to cover based on new member growth of approximately 2 years.
    
    I especially do not like the idea of reserving a block of addresses for some undefined future use. Any future development that would require such a thing should be done under IPv6. There is no excuse for such development to be done in a manner that requires IPv4 addresses at this point in the evolution of the internet. We should not reward or encourage backward-thinking engineering.

+1, and the authors of the soft landing overhall are 100% in agreement with you.
    
    I think that the reservation for critical infrastructure should be from a specific block.

See comment above about critical infrastructure – before we put something in the overhall policy we would want an *exact and exhaustive* list of what is covered under it and some justification as to the amount of space being allocated.  Considering that IXP space is already catered for under another policy, the authors simply do not see the need to block out an entire /12 for this purpose (though if we have an exhaustive list of everything that is critical infrastructure we can run some actual hard statistics and come up with a proper reservation number).  We have been very careful in the numbers allocated in the overhall policy to be able to justify with hard data as to why we came up with them, rather than picking arbitrary numbers, so we’d like to be able to do the same if we allocate space for critical infrastructure.
    
    I think it would be reasonable, if there is need, for the new entrant block to be comprised of fragments totaling a /12 equivalent rather than necessarily blocking out a specific /12.

The authors agree – we don’t see a need for contiguous allocations here.

    I do not think that reclaimed space should be reserved for new entrants. Rather, I would prefer to see one of two approaches taken to reclaimed space:
    
    	1.	An annoucement is made on relevant mailing lists that the space has been received and applications will be accepted beginning at a
    		certain date and time. Such date and time to be not less than 14 days after the announcement is sent out.
     or
    
    	2.	A waiting list of unmet requests is created and the space is offered to those requestors on the waiting list on a FIFO basis.
    
The authors here are prepared to look at this – but have a preference for option 2, where FIFO is strictly based on pre-approved requests from a waiting list.  This avoids the situation that we currently have where FIFO is impractical because larger allocations take longer than smaller allocations and the argument then arises, does everyone wait while the queue is dealt with in a FIFO manner. Would you be ok with saying that should there be no waiting list and space comes back, it can be moved into the new entrant pool?

    If we are to have a new-entrant block (I consider this optional, but desirable), it should be strictly for purposes of providing the addresses needed for transitional technologies (CGN, 6rd, etc.) and we should not allocate more than a /24 to any single new entrant. Multiple new entrants under common ownership should be treated as a single new entrant in most cases.
    
The authors hesitate to tell anyone what their space can be used for, and believe this runs contrary to how the RIR’s have always operated, that being that needs based justification is based on an entities need for globally unique address space, and does not dictate any specific technological use of that space.   The authors do agree with the second sentiment above however about new entrants under common ownership, the only issue here is actually being able to verify this.

Thanks

Andrew

    
    > On Nov 2, 2016, at 13:49 , Dewole Ajao <dewole at forum.org.ng> wrote:
    > 
    > Good day,
    > 
    > As indicated in an earlier email, please take some time to view and comment on https://goo.gl/FDLmZF with a view toward fine-tuning and producing an improved IPv4 runout management plan.
    > 
    > Thank you.
    > 
    > Dewole Ajao
    > PDWG Co-Chair
    > 
    > _______________________________________________
    > RPD mailing list
    > RPD at afrinic.net
    > https://lists.afrinic.net/mailman/listinfo/rpd
    
    
    _______________________________________________
    RPD mailing list
    RPD at afrinic.net
    https://lists.afrinic.net/mailman/listinfo/rpd