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

[rpd] Summary of proposals: IPv4 Runout Management

ALAIN AINA aalain at trstech.net
Fri Nov 4 19:51:15 UTC 2016


Hello All.

Thanks Co-chairs for the summary on the IPv4 softlanding-bis proposal.

Our proposal set:

a /16 for Critical Infrastructure : DNS root ops, IXPs, TLD (cc and g) ops, RIRs, IANA
a /14 for new entrants
a /13 for  unforeseen future
IPv6  address space (AFRINIC or upstreams) as requirement to IPv4 allocations

We invite people to read the FAQ which is attached to the proposal and which helps with the understanding. 

http://www.afrinic.net/en/community/policy-development/policy-proposals/1627-softlanding-bis-policy-faq-v2

From recent discussions, the authors of the solanding-bis proposal  would be happy  to consider  making explicit in the proposal the following points:


- Multiple new entrants under common ownership being treated as a single new entrant

- Allocations to New entrants being used exclusively for IPv6 transitions mechanisms and services as explained in the FAQ

Hope this helps

--Alain 

> On Nov 3, 2016, at 4:03 PM, Dewole Ajao <dewole at forum.org.ng> wrote:
> 
> Thank you for the feedback, Owen. We look forward to the authors of both proposals considering the various inputs as well as offering further clarification to help the community better understand the rationale(s) behind the current drafts of their proposal(s).
> 
> Regards,
> Dewole.
> 
> On 02/11/2016 23:16, Owen DeLong wrote:
>> Thanks for doing this… It’s very useful.
>> 
>> There are elements from each of the proposals I like, but none of them would get my support in their current form.
>> 
>> I like the idea of a reserved carve-out for critical infrastructure.
>> 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.
>> 
>> I do not like the idea of a large reservation for new entrants to the exclusion of the needs of existing participants.
>> 
>> 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.
>> 
>> I think that the reservation for critical infrastructure should be from a specific block.
>> 
>> 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.
>> 
>> 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.
>> 
>> 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.
>> 
>> Owen
>> 
>> 
>>> 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




More information about the RPD mailing list