<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Jordi,</p>
<p>As per my previous emails on the matter I agree with the message,
but based on the below, not with the implementation. Mostly
referencing your original email </p>
<p>I think the way you're proposing adds a significant cost to
smaller network operators in particular which is money that could
be better spent actually rolling out IPv6 or in other ways
improving networks.<br>
<br>
I'm not sure the alternative options. As an example, 100% of our
clients, primarily consumer clients, has IPv6 available for use
from ourselves. We offer IPv6 on the entirety of our active
ethernet networks by way of active RA + DHCPv6, as well as all
dial-in options. In spite of pressuring customers, we find they
actively switch off IPv6 where they see it, and they will actively
inform you when you request they switch it on to back off or
they'll move to a different ISP that won't put this pressure on
them.</p>
<p>Various different reasons are provided, ranging from the absurd
to the more absurd. The middle-arguments are in the "IPv6 puts
public addresses on my devices and I don't want that".</p>
<p>Do you want to now punish the smaller players because they're
struggling to get to 50% IPv6 uptake? Even with the above in
place, we're struggling to keep it active at >20% clients that
at least take a PD from us. Whether or not that's then actually
deployed internally in their network is yet another matter.</p>
<p>My problem with the proposal isn't that it needs to be deployed,
we have it deployed. There is one single /29 network where we
have in play that doesn't have IPv6 also deployed, mostly because
of the function thereof IPv6 cannot functionally be deployed there
(the moment it makes sense you can be guaranteed we'll have it
done in a week). Therefore I consider our network to be as close
to 100% deployed as can be, however, our downstream networks is a
different matter, with as stated, around 20%.</p>
<p>You're now forcing me towards LNS because I won't be able to
obtain additional resources because my customers are being
stubborn. This just incurs further costs, both in terms of capex
to procure (likely build) the equipment as well as opex in terms
of running costs (primarily rack space and electricity, but also
support staff training and additional complexity).</p>
<p>Further in threads there were mention about top 25 sites etc ...
all of that is highly impractical to measure for most networks.</p>
<p>Kind regards,<br>
Jaco</p>
<div class="moz-cite-prefix">On 2026/05/28 12:21, jordi.palet--- via
RPD wrote:<br>
</div>
<blockquote type="cite"
cite="mid:DE1022BE-BE8D-4388-944A-01F6F7CFDC77@consulintel.es">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
Hi Jaco,
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>About the determination/measurement that this is being done,
let me explain how I see this.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>By the way, dynamic prefixes in IPv6 is broken, terrible
idea, specially if there are power outages.</div>
<div><br>
</div>
<div>I suggest to read what, hopefully in a few months, will
become in RFC/BCP a successor of RIPE690:</div>
<div><br>
</div>
<div><a
href="https://datatracker.ietf.org/doc/draft-ietf-v6ops-prefix-to-end-sites/"
moz-do-not-send="true" class="moz-txt-link-freetext">https://datatracker.ietf.org/doc/draft-ietf-v6ops-prefix-to-end-sites/</a></div>
<div><br id="lineBreakAtBeginningOfMessage">
<div>
<div>Regards,<br>
Jordi<br>
<br>
@jordipalet<br>
<br>
</div>
</div>
<div><br>
<blockquote type="cite">
<div>El 28 may 2026, a las 11:43, Jaco Kroon
<a class="moz-txt-link-rfc2396E" href="mailto:jaco@uls.co.za"><jaco@uls.co.za></a> escribió:</div>
<br class="Apple-interchange-newline">
<div>
<meta http-equiv="Content-Type"
content="text/html; charset=UTF-8">
<div>
<p>Hi Jordi,</p>
<p>I support the principle very much. Practicality may
be a different story, yes, must implement v6, however:</p>
<p>How do you determine/measure that? I think your "In
addition" section addresses this to a degree.</p>
<p>Merely advertising IPv6 space? Sure, that's easy,
but it doesn't mean I have to actually make that
available to customers.</p>
<p>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."</p>
<p>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?</p>
<p>For PI space (6.8.2.2.d) - what does deployed mean?</p>
<div class="moz-signature">
<div
style="padding: 0px; margin: 0px; font-family: 'Open Sans';">
<p
style="font-size: large; padding-left: 10px; padding-top: 3px;">Kind
regards,<br>
Jaco Kroon<br>
<br>
On 2026/05/28 10:28, jordi.palet--- via RPD wrote:</p>
</div>
</div>
<blockquote type="cite"
cite="mid:75E8A336-B72B-4AE6-8EB0-CC25C75AE878@consulintel.es">
<pre wrap="" class="moz-quote-pre">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
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">El 28 may 2026, a las 10:05, Darwin Da Costa <a
class="moz-txt-link-rfc2396E"
href="mailto:dacostadarwin@gmail.com"
moz-do-not-send="true"><dacostadarwin@gmail.com></a> 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:
<a class="moz-txt-link-freetext"
href="https://afrinic.net/afpub-2026-v6-001-draft01"
moz-do-not-send="true">https://afrinic.net/afpub-2026-v6-001-draft01</a>
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
<a class="moz-txt-link-abbreviated moz-txt-link-freetext"
href="mailto:RPD@afrinic.net" moz-do-not-send="true">RPD@afrinic.net</a>
<a class="moz-txt-link-freetext"
href="https://lists.afrinic.net/mailman/listinfo/rpd"
moz-do-not-send="true">https://lists.afrinic.net/mailman/listinfo/rpd</a>
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">**********************************************
IPv4 is over
Are you ready for the new Internet ?
<a class="moz-txt-link-freetext" href="http://www.theipv6company.com/"
moz-do-not-send="true">http://www.theipv6company.com</a>
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
<a class="moz-txt-link-abbreviated moz-txt-link-freetext"
href="mailto:RPD@afrinic.net" moz-do-not-send="true">RPD@afrinic.net</a>
<a class="moz-txt-link-freetext"
href="https://lists.afrinic.net/mailman/listinfo/rpd"
moz-do-not-send="true">https://lists.afrinic.net/mailman/listinfo/rpd</a>
</pre>
</blockquote>
</div>
</div>
</blockquote>
</div>
<br>
</div>
<br>
**********************************************<br>
IPv4 is over<br>
Are you ready for the new Internet ?<br>
<a class="moz-txt-link-freetext" href="http://www.theipv6company.com">http://www.theipv6company.com</a><br>
The IPv6 Company<br>
<br>
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.<br>
<br>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre wrap="" class="moz-quote-pre">_______________________________________________
RPD mailing list
<a class="moz-txt-link-abbreviated" href="mailto:RPD@afrinic.net">RPD@afrinic.net</a>
<a class="moz-txt-link-freetext" href="https://lists.afrinic.net/mailman/listinfo/rpd">https://lists.afrinic.net/mailman/listinfo/rpd</a>
</pre>
</blockquote>
</body>
</html>