[rpd] Pushing IPv6 ? Re: Questions about IP Allocation rate

Thu Oct 16 09:03:14 UTC 2025

> On Oct 16, 2025, at 00:33, Jaco Kroon <jaco at uls.co.za> wrote:
> 
> Hi Hendrik,
> 
> I'm in two minds on this.  On the one hand ... let it burn seems good.
> 
> 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.
> 

If they don’t by now, then actual runout is likely the only thing that will finally spur them to act.

> 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.
> 
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.

The vendor seemed utterly impervious to the customer requests.
> 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.
> 
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.
> 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.
> 
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.
> INVARIABLY when we are for AAAA records for services run externally where we manage DNS, we're being told one of two things:
> 
> 1.  There's not IPv6 available; or
> 2.  Nobody cares about IPv6 so we don't bother.
> 
> This seems like circular reasoning to me, nobody cares because nobody has it, and nobody has it because nobody cares.
> 
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.
> IPv6 for me seems more and more like the answer to IPv$ (which I differentiate from IPv4 …).
> 
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.)
> 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.
> 
Sad, but true.
> Until customers can't get to stuff because no IPv6 nobody is going to care.
> 
> 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.
> 
Yep.
> When those customers gets IPv6 I get two positives:
> 
> 1.  Their streaming is more reliable (no NAT ... no need to TURN via HK, results in less jitter, less buffering, less freezing and skipping).
> 2.  Overall less bandwidth ... for some reason I haven't investigated yet.
> 
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.

Also, the Rendezvous server adds some overhead on each packet for encoding the customer identity, etc. that isn’t necessary on a direct stream.
> 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.
> 
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.

Owen

> 
> Kind regards,
> Jaco
> 
> On 2025/10/14 10:21, Hendrik Visage wrote:
> 
>> Question:
>> 
>>  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?
>> 
>> 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.
>> 
>> Perhaps even moving to a state of: “You can have IPv6, once you’ve proven a complete IPv6 rollout can you get anymore IPv4"
>> 
>> ---
>> Hendrik Visage
>> Instant messaging: https://t.me/hvisage
>> 
>> 
>>> On 13 Oct 2025, at 16:43, Andrew Alston <aa at alstonnetworks.net> <mailto:aa at alstonnetworks.net> wrote:
>>> 
>>> Hi All,
>>> 
>>> 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)
>>> 
>>> 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".
>>> 
>>> 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.
>>> 
>>> Amongst other reasons, sitting with unallocated, unannounced, reserved space like this leaves the space vulnerable to hijacking and malicious use or even potential theft.
>>> 
>>> Thanks
>>> 
>>> Andrew
>>> 
>>> 
>>> _______________________________________________
>>> RPD mailing list
>>> RPD at afrinic.net <mailto:RPD at afrinic.net>
>>> https://lists.afrinic.net/mailman/listinfo/rpd
>> 
>> ---
>> 
>> Hendrik Visage
>> 
>> hvisage at hevis.co.za <mailto:hvisage at hevis.co.za>
>> 
>> HeViS.Co Systems Pty Ltd
>> 
>> https://www.envisage.co.za <https://www.envisage.co.za/>
>>  
>>  
>> 
>> 
>> _______________________________________________
>> 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
> https://lists.afrinic.net/mailman/listinfo/rpd

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20251016/cb077777/attachment-0001.html>