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

Thu May 21 17:03:53 UTC 2026

Hi Sami,

I’m not sure if you are understanding that I’m for the improvements suggested by Jaco, so it will be:

“The above requirement is waived for network operators requesting new IPv4 addresses for demonstrated key technical requirements, which can be illustrated to not be practically serviceable from existing assigned/allocated IPv4 resources – 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."

With that we are already addressing your point 1.

The reporting of usage of any resource, can be requested by Afrinic at any time, so that covers 3.

2 will ruin the goal of the proposal. You’re limiting then the number of sites, DCs, or PoPs with transition that an operator needs to deploy.

4, in other RIR discussion I always tried to incorporate this kind of requirements. However, most of the time, the proposal didn’t advanced with that requirement because the community didn’t supported it. If there are sufficient voices in favor and none agains, I will be happy to add that as well, of course. But we need to hear opinions! many !

Now one additional question on 4, what is the meaning to hold and IPv6 allocation/assignment. Should state also that is actually used? How this is verified? As you can see is not that easy.

Note also that some folks may need some time to actually do the IPv6 deployment. I’m able to do that for any client in 3-6 months, because I’ve the expertise, but this is not the case for everyone, so not allowing it for IPv4-only usages, basically means those folks will be much slower to deploy IPv6 and have less interest. We need to make it as easy as possible.

We need to remember: lack of policy compliance means resources can be recovered, so using the text amended by Jaco, I think covers it very well.

Regards,
Jordi

@jordipalet

> El 21 may 2026, a las 18:51, Sami Salih <sami.salih at outlook.com> escribió:
> 
> Dear Jordi, Co-Chairs, and fellow PDWG members,
> Thank you for this proposal — the technical rationale is sound and I support the intent.
> That said, I have one focused concern: the waiver mechanism as drafted is broad enough to be systematically abused, as the qualifying categories are self-declared with no verification requirement in the policy text.
> To address this, I suggest four improvements:
> Require documented justification — applicants should submit supporting technical documentation to AFRINIC staff before the waiver is activated
> Cap waiver-based allocations — limit to one per member per 12-month period to prevent repeated invocations across rolling "new sites"
> Post-allocation follow-up — require utilisation reporting within 12 months, with reclamation if the stated deployment has not materialised
> Condition on IPv6 co-deployment — require the requesting member to hold an active IPv6 allocation, ensuring the waiver supports transition rather than extending IPv4-only operations
> I support this proposal with the above amendments and am happy to assist in drafting the updated text if required.
> 
> With Regards.
> Sami Salih.
> From: jordi.palet--- via RPD <rpd at afrinic.net <mailto:rpd at afrinic.net>>
> Sent: Thursday, May 21, 2026 6:01 PM
> To: rpd at afrinic.net <mailto:rpd at afrinic.net> <rpd at afrinic.net <mailto:rpd at afrinic.net>>
> Subject: Re: [rpd] New Draft Policy Proposal - Amendment of Utilisation in Soft Landing AFPUB-2026-IPv4-002-DRAFT01.
>  
> I will be happy myself with the text changes that you proposed.
> 
> Let’s make sure other folks agree/disagree and specially it will be awesome to get a confirmation from the staff that this doesn’t create excessive burden to them for the evaluation of the request, and we don’t miss the deadline for a v2.
> 
> Tks!
> 
> Regards,
> Jordi
> 
> @jordipalet
> 
> 
> El 21 may 2026, a las 16:56, Jaco Kroon <jaco at uls.co.za <mailto:jaco at uls.co.za>> escribió:
> 
> Hi,
> 
> On 2026/05/21 16:36, jordi.palet--- via RPD wrote:
> Hi and tks again,
> 
> I see your point that seems to easy, but we shall remember that you need to demonstrate the need to Afrinic *every time* you do a request. So if you say, I will build not 1 but 3 DCs, you will need to show contracts, right?
> 
> Is the same as when you request a bigger address block than what policies dictate, you need to justify the need, have network diagrams, etc.. If you need to deploy 4 NAT64 PoPs, you need to show the contracts, even the invoices for the NAT64 boxes, etc.
> Well, right now I don't think you can get more than /22 no matter how well you can illustrate that.  I would not mind being able to consolidate the resources that I have into a single block, however, there's one black that would be exceptionally hard to renumber (And I believe this is part of your point about renumbering).
> 
> All that are operational details, with don’t go into policy text. We want to avoid micromanagement of the RIR as much as possible, only got into the details if they are going to (clearly) do it wrong (or done wrong already previously).
> I agree.  But we also want policy to be clear so as to avoid misinterpretation - accidentally or otherwise.
> 
> If a request for 4 /24 for 4 NAT64 PoPs is fraudulent, the service agreement already enable Afrinic to review that and reclaim the space. I don’t think in general, people want to break rules on purpose.
> Agree, I expect most people to be rule-abiding and well-intentioned individuals.
> 
> Also I think asking for demonstrating that it can’t be done with renumbering is too expensive (just the exercise to analyze is it often a big hurdle), renumbering is extremely hard, and imposing this may go against some IPv6 deployments “the deployment cost me x and also I need to check if I can do it with renumbering first, then I just do with the renumbering, at least for some time”.
> Ok.
> 
> ****** Now, if the staff believes that they need some explicit text to demonstrate the need, please say so before the policy proposal submission deadline, because in that case, we still have time to incorporate that text into a v2.
> 
> May be something such as:
> 
> “The above requirement is waived for network operators requesting new IP addresses for demonstrated 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."
> How about:
> 
> “The above requirement is waived for network operators requesting new IPv4 addresses for demonstrated key technical requirements, which can be illustrated to not be practically serviceable from existing assigned/allocated IPv4 resources – 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."
> 
> As you say, there could be practical limitations that could potentially be alleviated by renumbering but where it isn't practical to do so, so I believe this hits more the middle ground, I hope.
> 
> 
> Repeating myself:
> I think overall, this way to approach what do to with the recovered space helps Africa to improve Internet penetration tied to IPv6 deployment, specially because dual-stack is not longer possible, so this helps IPv6 + IPv4aaS, so it is clearly in support of IPv6 deployment.
> I agree.  I just feel extremely sorry for those entities that were forced to approach leasing entities in order to obtain some IPv4 space that may now have that space revoked again ... refer to the other discussion.
> 
> Appreciate the discussion, use it don't use it, I think this is fine as is, my preference has been made known.
> 
> Kind regards,
> Jaco
> 
> 
> 
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com <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.

**********************************************
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/20260521/fb9d960a/attachment-0001.html>