<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><br id="lineBreakAtBeginningOfMessage" style="font-size: 18px;"><div style="font-size: 18px;"><br><blockquote type="cite"><div>On Oct 16, 2025, at 00:33, Jaco Kroon <jaco@uls.co.za> wrote:</div><br class="Apple-interchange-newline"><div>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div><p>Hi Hendrik,</p><p>I'm in two minds on this. On the one hand ... let it burn seems
good.</p><p>On the other hand, the single largest cheap hosting provider is
SA still has no sensible plan on deploying IPv6 as far as I can
tell, neither does any of the MNOs.<br></p></div></div></blockquote><div><br></div>If they don’t by now, then actual runout is likely the only thing that will finally spur them to act.</div><div style="font-size: 18px;"><br><blockquote type="cite"><div><div><p>The MNOs (at least two of them) claim they're ready, but no
customer wants it ... and when the customers ask, they're being
told it's in the roadmap but no timelines has been set since
there's not high demand.<br></p></div></div></blockquote><div style="font-size: 18px;">They are lying. This has been par for the course for 20+ years. In the early 2000s, I was staffing an ARIN booth at a trade show next to a software vendor that had a product for network monitoring. All day long, we’d hear people walk up, ask about IPv6 support in the product and be told “None of our customers have expressed any interest.” About half of them walked away in dismay, the other half pointed out that this _WAS_ a customer expressing interest.</div><div style="font-size: 18px;"><br></div><div style="font-size: 18px;">The vendor seemed utterly impervious to the customer requests.</div><blockquote type="cite"><div><div><p>
Doing v6-only on hosting side, and then using a small amount of v4
space to stateless NAT into the v6 infra is easy. There are
rumours (good authority but I've not personally confirmed it) that
Facebook does exactly this already, and given it's stateless I can
imagine that.<br></p></div></div></blockquote>Not a rumor. Facebook does something slightly different, but it has roughly the same effect (IIRC, they’re using transparent proxies to terminate the v4 and pass it along in v6). Facebook is all v6 behind the scenes and you get better performance if you arrive native v6.<br><blockquote type="cite"><div><div><p>
My concern is getting CG-NAT just right is non-trivial, as anybody
that provides services even marginally more complex than http will
attest to. And given the above situation where hosting providers
are reluctant to deploy IPv6 for some reason.<br></p></div></div></blockquote>NAT of any form is a horrible ugly hack that has consistently and for all time it has existed provided more pain than good. If we don’t get provider off the stick to provide IPv6, CG-NAT is the future we will be stuck with. Worse, it’s going to likely be multi-layer CG-NAT and it’s only going to get uglier the longer we preserve the fallacious illusion that IPv4 must be the lingua franca of the internet and all sites must support v4 and v6 is optional.</div><div style="font-size: 18px;"><blockquote type="cite"><div><div><p>
INVARIABLY when we are for AAAA records for services run
externally where we manage DNS, we're being told one of two
things:<br>
<br>
1. There's not IPv6 available; or<br>
2. Nobody cares about IPv6 so we don't bother.<br>
<br>
This seems like circular reasoning to me, nobody cares because
nobody has it, and nobody has it because nobody cares.<br></p></div></div></blockquote>It’s an excuse. It’s mainly a dunwanna problem. They don’t want to deal with it as long as there’s no forcing function. The “global north” as I’ve heard it called elsewhere in this discussion isn’t ahead on this because of great foresight or better funding or better anticipation or more cooperative vendors. It’s ahead because the RIRs all ran out of IPv4 years ago and the lack of an IPv4 free pool and the high costs in the transfer market have served as a forcing function.<br><blockquote type="cite"><div><div><p>
IPv6 for me seems more and more like the answer to IPv$ (which I
differentiate from IPv4 …).<br></p></div></div></blockquote>What, exactly is the distinction? Is IPv$ the amount of money it costs you to continually add layers of hacks to keep your IPv4 network running? (That would make sense to me and if that’s the case, the longer IPv4 stays “necessary”, the more IPv$ you’re going to have to spend.)</div><div style="font-size: 18px;"><blockquote type="cite"><div><div><p>
Reality is that there is only one way IPv6 will become a reality,
and that's by letting IPv4 burn down and causing it to break.<br></p></div></div></blockquote>Sad, but true.<br><blockquote type="cite"><div><div><p>
Until customers can't get to stuff because no IPv6 nobody is going
to care.</p><p>The ONLY customers I've got asking for IPv6 are those with home
cameras that streams ... typically using RTP of sorts, and here
what ends up happening is that the camera suppliers are making
boatloads of money thanks to IPv4 since that means they get to
sell a platform, camera connects to platform, and streaming goes
through platform (TURN protocol). The performance is poor, and
given most of these I've investigated sits in HK - that also
raises some privacy concerns about who has access to video feeds.<br></p></div></div></blockquote>Yep.</div><div style="font-size: 18px;"><blockquote type="cite"><div><div><p>
When those customers gets IPv6 I get two positives:<br>
<br>
1. Their streaming is more reliable (no NAT ... no need to TURN
via HK, results in less jitter, less buffering, less freezing and
skipping).<br>
2. Overall less bandwidth ... for some reason I haven't
investigated yet.</p></div></div></blockquote>Probably because of the number of packets and the number of times the payload(s) have to traverse your network in the Customer Camera <-> Customer UI Device vs. Customer Camera <-> Rendezvous Server in HK <-> Customer UI Device.</div><div style="font-size: 18px;"><br></div><div style="font-size: 18px;">Also, the Rendezvous server adds some overhead on each packet for encoding the customer identity, etc. that isn’t necessary on a direct stream.</div><div style="font-size: 18px;"><blockquote type="cite"><div><div><p>
On the one hand I like having happy customers (need IPv4 or else
they can't get to www.{somerandomsite}.co.za). On the other hand,
let it burn so we can stop having these discussions.<br></p></div></div></blockquote>The first hand can be best addressed by convincing randomsites.co.za to make their content available on v6. Unfortunately, if they don’t by now, the only thing likely to spur that is when they start losing customers that can’t get IPv4 addresses to reach them or at least the customers start suffering the poor performance of NAT64/etc.</div><div style="font-size: 18px;"><br></div><div style="font-size: 18px;">Owen</div><div style="font-size: 18px;"><br><blockquote type="cite"><div><div><p>
<br>
Kind regards,<br>
Jaco</p><p>On 2025/10/14 10:21, Hendrik Visage wrote:</p>
<blockquote type="cite" cite="mid:30A65637-790B-45E7-9213-D3BAC3720F77@hevis.co.za">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
Question:
<div><br>
</div>
<div> Shouldn’t we rather consider pushing IPv6 deployment
assistance across Africa? ie. let the rest of the IPv4 go ASAP
without much resistance instead of making this a
begging/pleading/fighting game?</div>
<div><br>
</div>
<div>ARIN (North America) & RIPE (Europe) serviced areas are
way ahead of IPv6 roll outs, ‘cause they don’t have any left,
and looking at AfriNIC services countries, we are still have an
abundance of IPv4, so IPv6 percentage roll outs are very low,
and rathe we should be pushing to mirror the IPv6 percentage
rollout and usage rather than fighting over the few remaining
IPv4s if we want to grow digital rollouts.</div>
<div><br>
</div>
<div>Perhaps even moving to a state of: “You can have IPv6, once
you’ve proven a complete IPv6 rollout can you get anymore IPv4"</div>
<div><br id="lineBreakAtBeginningOfMessage">
<div>
<div dir="auto" style="caret-color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
<div dir="auto" style="caret-color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
<div dir="auto" style="caret-color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
<div dir="auto" style="caret-color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
<div dir="auto" style="caret-color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
<div style="letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
<div style="letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
---<br>
Hendrik Visage</div>
<div style="letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
Instant messaging: <a class="moz-txt-link-freetext" href="https://t.me/hvisage">https://t.me/hvisage</a><br>
<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<div><br>
<blockquote type="cite">
<div>On 13 Oct 2025, at 16:43, Andrew Alston
<a class="moz-txt-link-rfc2396E" href="mailto:aa@alstonnetworks.net"><aa@alstonnetworks.net></a> wrote:</div>
<br class="Apple-interchange-newline">
<div>
<div dir="ltr">Hi All,
<div><br>
</div>
<div>I was wondering if there were updated statistics
for the amount of space allocated in the last 3
years. In addition to this information regarding
exactly how much free space is still available in the
IPv4 unallocated pool (excluding reservations)</div>
<div><br>
</div>
<div>I ask this because depending on the allocation rate
- we may wish to consider revising the soft-landing
policy that currently reserves a /12 worth of ipv4
space for "future uses, as yet unforeseen".</div>
<div><br>
</div>
<div>I point out that the soft landing policy was
ratified in 2011, and if we still, after 14 years,
have not been able to articulate a clear reason for
such a large reservation, I think it's time we look at
most, if not all, of that /12 back into the main
unallocated pool that can be allocated for African
resource holders that actually need it.</div>
<div><br>
</div>
<div>Amongst other reasons, sitting with unallocated,
unannounced, reserved space like this leaves the space
vulnerable to hijacking and malicious use or even
potential theft.</div>
<div><br>
</div>
<div>Thanks</div>
<div><br>
</div>
<div>Andrew</div>
<div><br>
</div>
<div><br>
</div>
</div>
_______________________________________________<br>
RPD mailing list<br>
<a class="moz-txt-link-abbreviated" href="mailto:RPD@afrinic.net">RPD@afrinic.net</a><br>
<a class="moz-txt-link-freetext" href="https://lists.afrinic.net/mailman/listinfo/rpd">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
</div>
</blockquote>
</div>
<br>
</div><p>---</p><p>Hendrik Visage</p><p><a class="moz-txt-link-abbreviated" href="mailto:hvisage@hevis.co.za">hvisage@hevis.co.za</a><br>
</p><p><br>
HeViS.Co Systems Pty Ltd</p><p><a class="moz-txt-link-freetext" href="https://www.envisage.co.za/">https://www.envisage.co.za</a></p><div> <br class="webkit-block-placeholder"></div><div> <br class="webkit-block-placeholder"></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>
</div>
_______________________________________________<br>RPD mailing list<br>RPD@afrinic.net<br>https://lists.afrinic.net/mailman/listinfo/rpd<br></div></blockquote></div><br></body></html>