<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi,</p>
<p>I'm going to state this again - I support the principle but not
the implementation.<br>
</p>
<p>Specifically the way in which this links IPv4 requests to IPv6
*traffic levels* as a percentage, rather than percentage of
network to which IPv6 has been deployed.<br>
<br>
I'm unable to sensibly force my customers to consume IPv6, no
matter what. Further - we host a bunch of content which due to
lack of external IPv6 deployment (specifically on MNO networks)
brings down our overall level of network IPv6 thresholds. This in
spite of but one single /29 subnet (which communicates exclusively
with MNO networks, this might change in the next month, thus
deploying IPv6 here until now made no sense, and this little
subnet single-handedly carries around 5% of our ingress and ~30%
of our egress bandwidth).</p>
<p>As written this policy punishes network operators for bad
behaviour of others, be it other access networks, or customers.<br>
<br>
It also adds significant additional costs towards otherwise
needless network monitoring that would otherwise not be required.<br>
<br>
Again, to be clear: I'm in full support of the principle of
linking IPv4 allocations/assignments to IPv6 deployment, I simply
disagree with how it should be measured.</p>
<p>Traffic levels are not a good measure. If 50% of my network is
capable of IPv6, and 50% of content being accessed, or 50% of of
eyeballs accessing my network are IPv6 capable, that puts my
general IPv6 network levels around 25%, depending on exact
patterns, possibly a bit higher, but no higher than 50%. Now our
ability to access IPv4 resources is being limited by *others's*
IPv6 deployment rather than merely our own.</p>
<p>This should be measured as:<br>
<br>
What percentage of existing deployed IPv4 resources on the network
also has IPv6 deployed in the case of content provisioning, and
has access to IPv6 for downstream networks.<br>
<br>
For us the former percentage, having somewhere between a /22 and
/23 provisioned for *services*, so let's work on a /23 or about
512 IPs with only a /29 not being IPv6 enabled as of right now is
98.5%, however, traffic patterns on access shows less than 5% of
actual traffic is IPv6.<br>
<br>
For the latter, 100% of downstream customers/networks has *access*
to IPv6. On customers using ppp less than 5% are consuming IPv6.
At least a portion of these configures IPv6 LL (just over 30%).
Once that happens we do actively send RAs to provoke
configuration.</p>
<p>For AE customers (Or "DHCP Customers") things looked better, as
of right now we've got 43% active IPv6 customers (which shows
that consumer routers are more inclined to grab IPv6 on "DHCP
uplinks compared to PPP", however, this percentage used to be
closer to 96%, as customers are *actively against recommendation
insisting on switching OFF IPv6*.<br>
<br>
Whilst we are pushing we cannot prescribe to customers to keep
IPv6 enabled - they'll simply move their business elsewhere if we
push, thus this policy - as written - creates a significant
operational issue.</p>
<p>Kind regards,<br>
Jaco</p>
<p>On 2026/07/19 11:26, Mark Elkins via RPD wrote:</p>
<blockquote type="cite"
cite="mid:95592897-0d54-4f5f-b5f8-cd918dd51c24@posix.co.za">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>Dear PDWG,</p>
<p>I have two major concerns regarding the Internet in Africa.</p>
<p>1 - Lack of DNSSEC - for DNS security</p>
<p>2 - Lack of IPv6 - for growth</p>
<p>I run something called the Observatory - <a
class="moz-txt-link-freetext"
href="https://observatory.dnsstudy.africa"
moz-do-not-send="true">https://observatory.dnsstudy.africa</a>
- which has in the past collected information such as how many
domains there are, are they DNSSEC Signed and are they IPv6
accessible.</p>
<p>So I want Domain content to be IPv6 Accessible...</p>
<p>ISP's need to have IPv6 resources, they need to make sure that
all content has IPv6 - so that as end users access that content,
they have IPv6 access all the way through. IPv6 doesn't use
RFC1918 addresses - all IPv6 addresses are unique.</p>
<p>We are running out of IPv4. Yes - some resources will still
need IPv4 addresses - so let's stretch what we have out. The
IPv4 Soft Landing proposal helps this stretching process - by
forcing IPv6 onto LIR's/ ISP's.</p>
<p>So I support the Proposal. It may not be perfect but it will
help shape the African Internet Industry further into the right
direction.</p>
<div class="moz-signature">-- <br>
<meta http-equiv="content-type"
content="text/html; charset=UTF-8">
<title></title>
<p>Mark James ELKINS - Posix Systems - (South) Africa<br>
<a class="moz-txt-link-abbreviated moz-txt-link-freetext"
href="mailto:mje@posix.co.za" moz-do-not-send="true">mje@posix.co.za</a>
Tel: <a href="tel:+27826010496" moz-do-not-send="true">+27.826010496</a><br>
For fast, reliable, low cost Internet in ZA: <a
href="https://ftth.posix.co.za"
class="moz-txt-link-freetext" moz-do-not-send="true">https://ftth.posix.co.za</a><br>
<br>
<br>
</p>
</div>
<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>