Search RPD Archives
[rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01.
jordi.palet at consulintel.es
jordi.palet at consulintel.es
Wed Jun 24 15:13:31 UTC 2026
Hi Musa,
I don’t agree in your understanding of the AFRINIC function.
In the policies we already do a kind of “regulation”.
If you get IPv4, ASN or IPv6 resources, and you don’t follow the rules, the resources can be reclaimed.
If you don’t set RDNS, the resources can be reclaimed.
If you don’t correctly manage the whois, register the relevant contacts, including abuse-c, etc. the resources can be reclaimed.
This is on top of policies, because the RSA already obligate members to follow the policies.
So there is no difference in now setting a policy that clearly say, you get more IPv4, but you must also deploy IPv6.
We could also do something slightly different, I’m not sure if this is what Seun tried to say in the mic earlier this afternoon.
We don’t give any more IPv4 resources if you already got them previously. This has been done by most of the other RIRs. Will you agree with that? Only newcomers can get IPv4.
Now, as a 2nd part of the proposal, resources left (even recovered), can be provided to anyone who also deploy IPv6, regardless of being a newcomer or an existing member.
What do you think?
Regards,
Jordi
@jordipalet
> El 24 jun 2026, a las 15:43, Musa Stephen Honlue <honlue at gmail.com> escribió:
>
>
> Thank you Mark for your response.
>
> I would like to clarify that my opposition is not to IPv6 deployment itself. I fully support wider IPv6 adoption across the AFRINIC service region and agree that organizations should be encouraged to deploy and actively use the IPv6 resources they receive. I have been training and supporting engineers on the deployment of IPv6 and other technologies.
>
> Where I differ is on the role that AFRINIC policy should play in achieving that objective.
>
> Your suggestion that AFRINIC should eventually require IPv6-only interactions with AFRINIC services is an operational decision that AFRINIC may choose to make for its own infrastructure and services. However, the proposal under discussion goes much further by prescribing how resource holders should deploy IPv6 within their own networks and by attaching compliance obligations to operational outcomes.
>
> My concern is that this moves AFRINIC from managing and registering number resources into regulating network operations. Whether IPv6 is cheaper, more efficient, or technically preferable does not automatically mean that deployment targets, traffic ratios, service reachability percentages, and compliance enforcement belong in resource management policy.
>
> I also do not believe that making IPv6 deployment a policy compliance matter is the right solution to the concern that some members may later claim they were not encouraged to adopt IPv6. AFRINIC already allocates IPv6 resources, provides training, conducts outreach, and can require applicants to demonstrate IPv6 planning as part of resource requests. These are measures that encourage adoption without attempting to regulate operational implementation.
>
> In my view, there is a significant difference between encouraging IPv6 deployment and enforcing specific deployment outcomes. I support the former, but I remain unconvinced that the latter falls within the appropriate scope of AFRINIC policy.
>
>
>
>> On 24 Jun 2026, at 10:30, Mark Elkins via RPD <rpd at afrinic.net> wrote:
>>
>>
>> Dear Musa Stephen Honlue,
>>
>> I disagree with your viewpoint and can see that in the future some resource members muttering that "nobody told us we had to have IPv6 - why didn't AFRINIC enforce it?"
>> Personally, I want AFRINIC to make sure all resource members have IPv6 the change that to all IPv6 resource holders need to make their space visible then one day insist that all communications with AFRINIC is over IPv6 and AFRINIC somewhat terminates access via IPv4. Harsh, I know, but IPv6 is cheaper and more efficient to run than IPv4... Step by step - and this is a good step.
>>
>> On 2026/06/24 00:20, Musa Stephen Honlue wrote:
>>> Dear Jordi
>>>
>>> I would like to express my opposition to this proposal in its current form.
>>>
>>> While I fully support the objective of increasing IPv6 deployment across the AFRINIC service region, I do not believe that the problem statement and the proposed solution adequately justify the measures being introduced.
>>>
>>> First, I believe the problem statement is inappropriately framed. The proposal relies heavily on comparisons between Africa and other regions of the world, suggesting that Africa’s lower IPv6 deployment rate is, by itself, evidence that stronger policy intervention is required. I do not think this is a useful basis for policy development.
>>>
>>> The AFRINIC community should not be comparing itself to other regions from a technological adoption perspective. There are numerous economic, infrastructural, educational, and operational factors that influence IPv6 deployment across different regions. The fact that Africa has lower IPv6 deployment than other regions does not automatically indicate a policy failure.
>>>
>>> Furthermore, after more than 25 years of IPv6 availability, even the regions often considered technologically advanced are still reporting deployment levels that are far from complete. If the reported global capability is approximately 44%, this demonstrates that IPv6 adoption remains a challenge worldwide and not exclusively within Africa.
>>>
>>> If the objective is to highlight low IPv6 deployment within the AFRINIC service region, the problem statement should focus on that issue directly and objectively, without relying on comparisons with other regions. Any benchmarking should be done carefully and within relevant peer groups rather than presenting Africa as lagging behind the rest of the world.
>>>
>>> Second, I am concerned that the proposal moves AFRINIC beyond its traditional role as a registry and into the role of an operational regulator.
>>>
>>> The primary function of an RIR is the fair and efficient management and registration of Internet number resources. This proposal goes significantly further by attempting to regulate how networks deploy IPv6, how quickly they deploy it, what percentage of traffic should use it, and what percentage of services should be reachable over it.
>>>
>>> Such requirements extend beyond resource registration and enter the realm of network operations and business decisions. I do not believe this falls within the intended scope of RIR policy.
>>>
>>> Third, the proposed compliance criteria appear difficult to evaluate objectively.
>>>
>>> For example, the proposal requires networks to demonstrate specific percentages of IPv6 traffic to their top-25 external destinations. It is unclear:
>>>
>>> How these destinations will be identified and measured;
>>> Over what period measurements will be taken;
>>> How AFRINIC staff will independently verify the information provided;
>>> How compliance will be assessed when traffic patterns change over time.
>>> In addition, network operators do not control whether external destinations support IPv6, nor do they fully control the applications and services used by their customers. As a result, the proposed traffic thresholds may not accurately reflect the deployment efforts undertaken by the resource holder.
>>>
>>> Similarly, evaluating IPv6 reachability through percentages of AAAA records and service availability introduces a high degree of subjectivity. Different networks host different types of services, operate different architectures, and face different technical constraints. A single set of percentages may not be appropriate across all deployment scenarios.
>>>
>>> Finally, I am particularly concerned by the statement that failure to comply with the IPv6 deployment plan constitutes a policy violation.
>>>
>>> An organization may make genuine efforts to deploy IPv6 and still fail to meet prescribed percentages due to factors outside its control. Turning such outcomes into policy violations creates uncertainty and potentially disproportionate consequences for resource holders.
>>>
>>> I would support measures that encourage IPv6 adoption, such as requiring organizations requesting IPv4 resources to also obtain IPv6 resources if they do not already have them, or requiring applicants to submit an IPv6 deployment plan. However, I do not support introducing operational deployment targets, traffic thresholds, service reachability metrics, and compliance enforcement mechanisms that move beyond AFRINIC’s core registration function.
>>>
>>> For these reasons, I oppose the proposal in its current form.
>>>
>>>>
>>>> On 23 Jun 2026, at 23:45, Musa Stephen Honlue <honlue at gmail.com> <mailto:honlue at gmail.com> wrote:
>>>>
>>>> Thank you Madhvi.
>>>>
>>>>>
>>>>> On 23 Jun 2026, at 23:25, Madhvi Gokool <madhvi at afrinic.net> <mailto:madhvi at afrinic.net> wrote:
>>>>>
>>>>>
>>>>> Hello Stephen
>>>>>
>>>>> There seems to be an issue with the first version of the proposal on the website. We'll ensure it's fixed the soonest.
>>>>>
>>>>> Please note that the author submitted a revised version of the proposal - https://afrinic.net/participate/policy/proposals/afpub-2026-v6-001-draft02 and that the latter will be discussed during the AFRINIC-37 PPM.
>>>>>
>>>>> Kind Regards
>>>>>
>>>>> Madhvi
>>>>>
>>>>> Policy Liaison AFRINIC
>>>>>
>>>>> On 24/06/2026 00:25, Musa Stephen Honlue wrote:
>>>>>> <image0.png>
>>>>>>
>>>>>>
>>>>>>
>>>>>> This is what the link is showing, please confirm that you have access.
>>>>>>
>>>>>>> On 28 May 2026, at 12:27, Sami Salih <sami.salih at outlook.com> <mailto:sami.salih at outlook.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>> Hi Jordi, colleagues,
>>>>>>>
>>>>>>> Thank you, Jordi, for considering my previous comments and for restructuring this into a more focused proposal.
>>>>>>>
>>>>>>> In principle, I support linking IPv4 allocations under the Soft Landing policy with commitment toward IPv6 deployment. Given the IPv4 exhaustion reality, this is a reasonable policy direction.
>>>>>>>
>>>>>>> I also appreciate the additional clarifications regarding the existing policy references and deployment expectations. Nevertheless, I believe the implementation and enforcement aspects may still require further refinement to ensure the criteria remain objective, measurable, and operationally practical across the AFRINIC service region. I believe the staff analysis may further help clarify the operational feasibility, compliance verification approach, and enforcement practicality of the proposed requirements.
>>>>>>>
>>>>>>> Overall, I support the intent of the proposal and appreciate the more granular approach to the discussion.
>>>>>>>
>>>>>>> With Regards,
>>>>>>> Sami Salih.
>>>>>>>
>>>>>>>
>>>>>>> Sami Salih
>>>>>>> From: jordi.palet--- via RPD <rpd at afrinic.net> <mailto:rpd at afrinic.net>
>>>>>>> Sent: Thursday, May 28, 2026 1:21:52 PM
>>>>>>> To: rpd at afrinic.net <mailto:rpd at afrinic.net> <rpd at afrinic.net> <mailto:rpd at afrinic.net>
>>>>>>> Subject: Re: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01.
>>>>>>>
>>>>>>> Hi Jaco,
>>>>>>>
>>>>>>> Tks, next version will use: “Any IPv4 request must be done with a simultaneous IPv6 request if the requesting party does not already have IPv6 space.” This may depend on the impact analysis inputs, of course.
>>>>>>>
>>>>>>> About the determination/measurement that this is being done, let me explain how I see this.
>>>>>>>
>>>>>>> The existing 6.5.1.1 (for LIRs) and 6.8.2, already set the conditions to be met. AFRINIC already has, in both cases, a 12 months period to confirm the deployment. May be is not sufficiently clear there if AFRINIC should do something if that’s not actually done. We aren’t talking there only about announcing the prefix, but also in the case of LIRs, about making assignments to end-sites, and the text is clear, /48s, nothing different. There is no reason for using different sizes for different type of customers on that text. There is no technical reason at all for not doing it correctly, however, this is a discussion for amending that part of the policy, not for this proposal.
>>>>>>>
>>>>>>> What this proposal wants to make sure is that you *actually*, *following existing policy*, if you get IPv4, you really deploy IPv6 in 12 months. To reinforce it I explicitly mention “In addition …”, as you said. Note that “in addition” section enforces a more detailed work from the member requesting IPv4, to justify a credible IPv6 addressing and deployment plan, this will be accepted or not by AFRINIC, as with any request evaluation.
>>>>>>>
>>>>>>> For example, in many RIRs, not just AFRINIC, I’ve observed that many members get by default a /32, even if they have 800.000 end-sites. Clearly wrong, they didn’t have done any real addressing plan and they will end up providing a single /64 to each end-site. If they do it correctly, they will soon discover why they should use /48s, so with a /32 they can only cover around 50.000 customers, which means that typically for 800.000 of customers (depending on the topological distribution of the network) will mean that they need a /27-/28.
>>>>>>>
>>>>>>> I don’t think nobody can say “deploy” is not clear. If this is the case, we can improve it, something like “and IPv6 is actually being used”. We can even set a minimum level of traffic, such as 50% for example? Those that have deployed IPv6 know that, at least in the case of residential and cellular customers, because most of the traffic (typically 75-90%) is from big CDNs, caches, and contend providers (all google, all Meta, Akamai and all the other CDNs), already provide IPv6, when you turn on IPv6 in an end-site, the IPv6 traffic of that end-site becomes 75%-90% IPv6, in turn the total ISP traffic reaches similar levels.
>>>>>>>
>>>>>>> So asking for 50% seems to me conservative, but I’m happy for lower levels, if we agree that we can ask for more later on. We can even consider something like 25% after 12 months, 50% after 24 months, 75% after 48 months. Just an example.
>>>>>>>
>>>>>>> Finally, as we have many policies that AFRINIC not necessarily is measuring the compliance, that’s what the other proposal (compliance dashboard) was already trying to resolve, now in a “light” version.
>>>>>>>
>>>>>>> This proposal also added a trigger (failure to comply) to ensure that abuse (requesting IPv4, but then not deploying IPv6) can enact the RSA terms, because clearly shows that there is a policy breach.
>>>>>>>
>>>>>>> By the way, dynamic prefixes in IPv6 is broken, terrible idea, specially if there are power outages.
>>>>>>>
>>>>>>> I suggest to read what, hopefully in a few months, will become in RFC/BCP a successor of RIPE690:
>>>>>>>
>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-prefix-to-end-sites/
>>>>>>>
>>>>>>> Regards,
>>>>>>> Jordi
>>>>>>>
>>>>>>> @jordipalet
>>>>>>>
>>>>>>>
>>>>>>>> El 28 may 2026, a las 11:43, Jaco Kroon <jaco at uls.co.za> <mailto:jaco at uls.co.za> escribió:
>>>>>>>>
>>>>>>>> Hi Jordi,
>>>>>>>>
>>>>>>>> I support the principle very much. Practicality may be a different story, yes, must implement v6, however:
>>>>>>>>
>>>>>>>> How do you determine/measure that? I think your "In addition" section addresses this to a degree.
>>>>>>>>
>>>>>>>> Merely advertising IPv6 space? Sure, that's easy, but it doesn't mean I have to actually make that available to customers.
>>>>>>>>
>>>>>>>> Re proposed text, the word "However, " doesn't add value, merely "Any IPv4 request must be done with a simultaneous IPv6 request if the requesting party does not already have IPv6 space."
>>>>>>>>
>>>>>>>> This does also be the question, it seems 6.5.1.1.3 states that you must give /48s to end sites - we do distinguish between business and home users, for business we happily do /48 if so required (at least we reserve a /48 per site minimum), but for home users we generally do dynamically allocated /56 (but will again do /48 on request) - would this imply failure to comply with your proposed policy? If so, should the proposed policy be adjusted, or 6.5.1.1.3?
>>>>>>>>
>>>>>>>> For PI space (6.8.2.2.d) - what does deployed mean?
>>>>>>>>
>>>>>>>> Kind regards,
>>>>>>>> Jaco Kroon
>>>>>>>>
>>>>>>>> On 2026/05/28 10:28, jordi.palet--- via RPD wrote:
>>>>>>>>
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> Somehow this is a response to Sami input on a previous proposal.
>>>>>>>>>
>>>>>>>>> This way we can split the problem space in 2 proposals, which may reach consensus without depending one on the other.
>>>>>>>>>
>>>>>>>>> So we have a very basic question: If we believe that the members that receive IPv4 out of the Soft Landing policy, must implement IPv6, or not?
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Jordi
>>>>>>>>>
>>>>>>>>> @jordipalet
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> El 28 may 2026, a las 10:05, Darwin Da Costa <dacostadarwin at gmail.com> <mailto:dacostadarwin at gmail.com> escribió:
>>>>>>>>>>
>>>>>>>>>> Dear PDWG,
>>>>>>>>>>
>>>>>>>>>> We have received a new draft policy proposal - IPv6 as a criteria in IPv4 Soft Landing ID AFPUB-2026-v6-001-DRAFT01 from author Jordi Palet Martinez. The proposal contents are published at:
>>>>>>>>>>
>>>>>>>>>> https://afrinic.net/afpub-2026-v6-001-draft01
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> We encourage you to take some time to go through the proposal contents and provide feedback as follows:
>>>>>>>>>>
>>>>>>>>>> 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
>>>>>>>>> **********************************************
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> RPD mailing list
>>>>>>>>> RPD at afrinic.net <mailto:RPD at afrinic.net>
>>>>>>>>> https://lists.afrinic.net/mailman/listinfo/rpd
>>>>>>>
>>>>>>>
>>>>>>> **********************************************
>>>>>>> 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.
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> RPD mailing list
>>>>>>> RPD at afrinic.net <mailto:RPD at afrinic.net>
>>>>>>> https://lists.afrinic.net/mailman/listinfo/rpd
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> RPD mailing list
>>>>>> RPD at afrinic.net <mailto:RPD at afrinic.net>
>>>>>> https://lists.afrinic.net/mailman/listinfo/rpd
>>>
>>>
>>> _______________________________________________
>>> RPD mailing list
>>> RPD at afrinic.net <mailto:RPD at afrinic.net>
>>> https://lists.afrinic.net/mailman/listinfo/rpd
>> --
>> Mark James ELKINS - Posix Systems - (South) Africa
>> mje at posix.co.za <mailto:mje at posix.co.za> Tel: +27.826010496 <tel:+27826010496>
>> For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za <https://ftth.posix.co.za/>
>>
>> <abessive_logo.jpg>
>> <QR-MJElkins.png>
>>
>>
>> _______________________________________________
>> 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
**********************************************
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/20260624/bcb641d6/attachment-0001.html>
More information about the RPD
mailing list