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

[Jaco Kroon]

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 
IPv4addresses 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20260521/22ecc48b/attachment.html>