[rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT02

[Jaco Kroon]

Hi,

I'm going to state this again - I support the principle but not the 
implementation.

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.

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

As written this policy punishes network operators for bad behaviour of 
others, be it other access networks, or customers.

It also adds significant additional costs towards otherwise needless 
network monitoring that would otherwise not be required.

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.

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.

This should be measured as:

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.

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.

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.

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

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.

Kind regards,
Jaco

On 2026/07/19 11:26, Mark Elkins via RPD wrote:

> Dear PDWG,
>
> I have two major concerns regarding the Internet in Africa.
>
> 1 - Lack of DNSSEC - for DNS security
>
> 2 - Lack of IPv6 - for growth
>
> I run something called the Observatory - 
> https://observatory.dnsstudy.africa - which has in the past collected 
> information such as how many domains there are, are they DNSSEC Signed 
> and are they IPv6 accessible.
>
> So I want Domain content to be IPv6 Accessible...
>
> 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.
>
> 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.
>
> So I support the Proposal. It may not be perfect but it will help 
> shape the African Internet Industry further into the right direction.
>
> -- 
>
> Mark James ELKINS  -  Posix Systems - (South) Africa
> mje at posix.co.za Tel: +27.826010496 <tel:+27826010496>
> For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za
>
>
>
> _______________________________________________
> 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/20260720/d4ecd37b/attachment-0001.html>