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

[rpd] New Draft Policy Proposal - Amendment of Utilisation in Soft Landing AFPUB-2026-IPv4-002-DRAFT01.

jordi.palet at consulintel.es jordi.palet at consulintel.es
Mon Jun 15 07:42:23 UTC 2026


Hi Sylvain,

Some comments below, in-line.

Regards,
Jordi

@jordipalet

> El 15 jun 2026, a las 8:36, Sylvain BAYA <baya.sylvain at cmnog.cm> escribió:
> 
> {sent with a registered email address now!}
> {i hope i'm not too late to add my comment!}
> Le 21/05/2026 à 14:28, jordi.palet--- via RPD a écrit :
>> Hi all,
>> [...] 
>> Comments welcome! 
>> 
> 
> Hi Jordi,
> Thanks for your email, brother.
> It's my pleasure to be able to review the DPP 
> (Draft Policy Proposal)!
> 
>> Tks!
>> 
>> Regards,
>> Jordi
>> 
>> @jordipalet
>> 
>> 
>>> El 15 may 2026, a las 17:51, dacostadarwin at gmail.com <mailto:dacostadarwin at gmail.com> escribió:
>>> 
>>> Dear PDWG,
>>> 
>>> We have received a new draft policy proposal - Amendment of Utilisation in Soft Landing, ID AFPUB-2026-IPv4-002-DRAFT01 from author Jordi Palet Martinez. The proposal contents are published at:  
>>> 
>>> https://afrinic.net/policy/proposals/afpub-2026-ipv4-002-draft01
>>> 
>>> We encourage you to take some time to go through the proposal contents and  provide feedback as follows :
>>> 
> 
> Dear PDWG,
> 
> Do kindly consider my review of the 
> AFPUB-2026-IPv4-002-DRAFT01 DPP 
> (Draft Policy Proposal) below.
> 
> 
> <quote>
> 1. Summary of the problem being addressed by this proposal
> 
> The Soft-Landing utilisation criteria is preventing organisations that may have multiple sites, redundancy or high availability needs to achieve that, because section 5.4.6.1 states that 90% of the previous allocations or assignments must have been used.
> 
> For example, an end-user member may have received a /24 for a Data Centre and now is setting up new Data Centres. Current policy will not allow that until 90% of the first Data Centre prefix is utilised.
> 
> Another example may be an ISP, with multiple BGP PoPs, setting up 464XLAT in the network, with NAT64 devices in each PoP for high-availability purposes. Normally it will announce a /22-/24 in each PoP, even if all the addresses are not being used simultaneously all the time, so 90% utilisation is not allowing that deployment offering high-availability to the subscribers.
> 
> </quote>
> 
> ...maybe the Policy Liaison Team could tell us 
> more about the number of such requests; the 
> hostmaster is actually unable to satisfy. 
> 
> This problem seems to be reasonable; but i 
> have a small doubt on the urgency; of these 
> situation. Can we found at least three Orgs 
> per case? prior to validate the problem which 
> is formulated here.
> 
> 
> <quote>

According to my experience, with customers in all the 5 RIRs, those request not always come to the RIR.

If I need some resources, I see that the existing policy doesn’t allow me to request them, *most of the time* I will not waste my time going to the hostmasters to request something that the policy is clear I can’t request. So even if the hostmasters can provide some data, it may not be sufficiently representative.

The problem is there, can’t be denied, despite there have been 1 or 10 cases coming to the hostmasters.

> 2. Summary of how this proposal addresses the problem
> 
>  This proposal suggests that the utilisation criteria should allow cases such as those in the previous examples and similar ones.
> 
> Because the 3 million IPv4 recovered addresses, this change will not create an immediate drain of the AFRINIC pool, and instead, can help to increase the number of DC and high-availability, IPv6 deployment and better connectivity for the region.
> 
> </quote>
> 
> 3 million IPv4 recovered
> ~ /11 + /12
> 2²¹ + 2²⁰ = 3145728 ?
>  
> ...while the problem, as formulated, might be 
> validated (by real facts); i think if we want to 
> keep "one shop", then it's necessary to keep 
> the same definition of "first allocation"; for 
> instance. 
> 
> 
> <quote>

Please check the PIER, it talks about 3 years per each million, according to current delegation rates. It is clear, with IPv6 deployment, and the waiver provider by this proposal, that it may speed up a little bit, but even if it just give us 3 years for the 3 millions, once IPv6 is being deployed, less and less IPv4 addresses are needed. This is the reason why regions with more IPv6 deployment become the source for more IPv4 transfers.

> Proposed
> 
> ~~5.4.6.1 In order to receive IPv4 allocations or assignments during the Exhaustion Phase, the LIR or End User must have used at least 90% of all previous allocations or assignments (including those made during both the Current Phase and the Exhaustion Phase)
>  
> In the case of new LIRs or End Users with no previous allocations or assignments, this requirement does not apply to their first allocation or assignment request.~~
>  
> "The above requirement is waived for network operators requesting new IP addresses for key technical needs – such as redundancy and high-availability sites, IPv6 transition technologies, or expansion to new sites which pose a technical constraint on their current resource pool – and in these cases, the request is treated as a first allocation or request."
> </quote>
> 
> ...i disagree with the above approach; as it 
> looks like a less optimal approach. It goes 
> without saying that when a first allocation 
> or assignment exists, any resource holder 
> should be treated same as all the others in 
> same conditions. 
> 
> What could be done, imho, if the edge cases 
> you have described are proved true; should 
> be to consider a different approach in order 
> to address their specificity. 
> 
> ...if applicable; then i would suggest the text 
> below as a replacement to the part of text 
> between double quotes above:
> 
> "If a resource member (being a LIR or an 
> End-user) can prove that its actual need for 
> IPv4 resources can not be satisfied by its 
> available allocation/assignment, even in 
> case of a percentage of utilization lower 
> than 90 %; then notwithstanding the above 
> requirements, the requesting resource 
> member shall be *specially considered* 
> eligible to receive a new allocation or 
> assignment. 
> 
> This *special consideration* shall also 
> be applicable to a new LIR or End-user, 
> with similar structural needs in IPv4 
> resources. In that case, the given LIR or 
> End-user shall be *specially considered* 
> eligible to receive a two allocations or 
> assignments; to begin with."
> 
> 

I’m confused here. I think you’re reading v1, not the text that I’m proposing for v2.

Nevertheless, your point seems to be a wording issue, not against the goal. My point to make the wording this way was to avoid changes in the existing text, and adding a new paragraph.


> <quote>
> 4. References
> In other regions, all IPv4 addresses have been exhausted and it seems that the equivalent to the soft-landing is not any more an issue, because most of the existing members only can access IPv4 addresses via transfers.
>  </quote>
> 
> ...i have found a counter-example to the above 
> statement; see, brother: 
> ARIN NRPM Section 4.1.8 <https://www.arin.net/participate/policy/nrpm/#four18>. ARIN Waitlist.
> 
> Do kindly include this precision, to your 
> "References" section (4.), as you go.
> 

We have a waiting list in ARIN, LACNIC and RIPE NCC, but this is not the same as the soft landing.

> Thanks.
> 
> Shalom,
> --sb.
> 
> 
> 
>>> a) Do you support or oppose the proposal?
>>> b) If you oppose the proposal, state your reasons?
>>> c) Is there anything in the proposal that is not clear?
>>> d) What changes could be made to this proposal to make it more effective?
>>> 
>>> Regards,
>>> Vincent Ngundi & Darwin Da Costa
>>> AFRINIC PDWG Co-Chairs
>>> 
>>> 
>>> _______________________________________________
>>> RPD mailing list
>>> RPD at afrinic.net <mailto:RPD at afrinic.net>
>>> https://lists.afrinic.net/mailman/listinfo/rpd
>> [...]
>> 
> 
> 
> 
> -- 
> 
> Best Regards !
> 
> baya.sylvain [AT cmNOG DOT cm] | 
> cmNOG's Structure <https://www.cmnog.cm/dokuwiki/Structure> | CAMIX's Website <https://www.camix.cm/> | Douala-IX's Looking Glass <https://tools.std.douala-ix.net/lg> | 
> cmNOG's Surveys <https://survey2.cmnog.cm/> | Subscribe to cmNOG's Mailing List <https://lists.cmnog.cm/mailman/listinfo/cmnog> | 
> __ 
> #LASAINTEBIBLE|#Ephésiens5:18,15-21« <siens5:18,15-21%C2%AB>[...] 18 Et ne vous enivrez pas de vin, en quoi il y a de la dissolution; mais soyez remplis de l'Esprit, [...]» 
> ‬#LASAINTEBIBLE|#Hébreux13:9,5-15« <breux13:9,5-15%C2%AB>[...] 9 Ne soyez pas seduits par des doctrines diverses et etrangeres, car il est bon que le coeur soit affermi par la grace, non par les viandes, lesquels n'ont pas profite à ceux qui y ont marche. [...]» 
> #AMEN,#Maranatha,#MerciJÉSUS! #‎MaPrière‬ est que tu naisses de nouveau.#Chrétiennement
> <OpenPGP_0x0387408365AC8594.asc>



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20260615/33bf24c3/attachment-0001.html>


More information about the RPD mailing list