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

Wed Jul 22 14:22:56 UTC 2026

HI Jordi,

Most of my clients ACTIVELY DO NOT want IPv6 near their network.  (very sad, but true) Thus this policy has commercial implications.

I’ll agree that we need to make it available should they want, but nothing configured should be mandatory.

Thanks
Saul

From: jordi.palet--- via RPD <rpd at afrinic.net>
Sent: Wednesday, 22 July 2026 12:30
To: rpd at afrinic.net
Subject: Re: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT02

Hi Ben,

Precisely what Jaco is suggesting is removing all that, and instead just asking that IPv6 prefix is provided to the CPE and routable, not traffic measurements needed.

To avoid mixing the current Last Call discussion on the other proposals and not create additional noise, I decided to respond to all the points on this proposal once the LC ends. I will provide then a detailed review of the previous emails open this proposal and we can draft a new version.

Tks!

Regards,
Jordi

@jordipalet

El 22 jul 2026, a las 12:06, Ben Roberts - AfriNIC <ben.roberts at afrinic.net<mailto:ben.roberts at afrinic.net>> escribió:

Jaco,
I re-iterate that this kind of relatively sophisticated traffic destination analysis is beyond the technical capacity for many emerging ISPs and enterprise networks in continental Africa, and is just putting up unrealistic barriers to accessing IP addresses

Cheers

Ben
Sent from my iPhone

On 22 Jul 2026, at 11:30, Jaco Kroon via RPD <rpd at afrinic.net<mailto:rpd at afrinic.net>> wrote:

Hi Jordi, Mark,

After in-person discussion with Mark, I'd like to propose alternative wording for specifically this portion:

"The IPv6 deployment plan must show the actual IPv4 top-25 traffic destinations of that network. For each of those external destinations
that are IPv6-enabled, the following minimum IPv6 % will be considered as compliant:
"25% in a maximum of 12 months.
50% in a maximum of 24 months.
75% in a maximum of 48 months.

"In case of networks hosting any kind of services, applications or contents, will be considered as compliant when matching the following % of AAAA RRs available and IPv6 reachable from Internet:
"25% in a maximum of 12 months.
75% in a maximum of 24 months.
95% in a maximum of 48 months.

"Failure to comply with the IPv6 deployment plan according to the relevant criteria, constitutes a policy violation."

As can be seen the author(s) already distinguish between access (eyeball) and hosting (content) networks.  It does not make it clear in the case of hybrid networks here.  For most larger networks this won't particularly matter since they are unlikely to be able to apply for additional /22s and even if they are /22s (as per in-person discussions with at least one network operator that makes me look like an extremely mild-mannered person) are not useful to them.

Regardless, I feel that for access networks the measurement above is not well defined, nor sensible, as per discussion with Mark the measurement depends not only on your own behaviour but also that of external networks (be they customers or external content networks).  Not discussed and which I only realised later on Monday after our discussion is that "actual IPv4 top-25 destinations" would *shift* as traffic moves to IPv6, which is to say that if *all* of my customers suddenly and unsuspectedly re-enable IPv6, then the likes of Google, Youtube, Cloudflare, Akamai, Meta and (AWS) won't be in our top-25 IPv4 destinations.  Now my top-25 would start shifting to the likes of the banks, NTT, Xneelo, Hostafrica, Hetzner and probably other content hosting providers that are NOT IPv6 enabled (or not advertising that they are).  Yes, I've been told that Xneelo does support IPv6 but I've yet to see a single site myself hosted on Xneelo side that has AAAA records deployed.  As such, since this is a shifting target it cannot be a reliable measure.

The measurements I would suggest:

For access networks:  The percentage of downstream networks/customers that has access to well-connected IPv6 should they so choose (well-connected in this sense means that the provided addresses are routable and reachable in the Internet's "DFZ"/Global routing table.  To be clear:  This doesn't mean they have to have it enabled downstream, just that it's available to the customer/network.

This is something that can be easily shown/proven by any network.  It would also (based on existing knowledge) force exactly those parties that are NOT currently deploying IPv6 to deploy.  Yes, this includes some of our own downstream IPT and/or consulting customers who would score 0% on either measure.  This would also allow us to raise the bar to a higher percentage such as the 95% as for content networks.

This must not be a "made available on request" situation - and a customer should be in a position to obtain IPv6 via the usual configuration mechanisms, and RAs should be advertised standard to these downstream customers, and provide for managed DHCPv6 PD, including at least a set of DNS servers.

My issue with hosting networks is that the network provider doesn't, in many (most) cases, also control DNS.  And in a significant portion of cases the third-party IT providers just flatly refuse to deploy AAAA records.  This ends up punishing a network operator for the behaviour of external parties.

I thus suggest the following:

"When applying for additional IPv4 space, the following conditions must be met as per the time frames from issuance of the first IPv6 space to LIRs and EUs, or {policy approval date}, whichever is later:

In the case of access networks, the percentage of customers that has access to global IPv6 delegations without interference required from the Network Operator must be at or above the following thresholds:

* 25 % within 12 months;
* 50 % within 24 months;
* 75 % within 36 months;
* 95 % within 48 months;

For the avoidance of doubt: "without interference required from the Network Operator" means that routers directly upstream from access clients must permit IPv6CP in the case of PPP connections, and all upstream routers must actively transmit IPv6 Router-Advertisements, and in order to allow for such downstream customers to obtain Prefix Delegations, most likely by way of DHCPv6 PD, and the space must be reachable from the global routing table.

In the case of content hosting network, the percentage of assigned IPv4 space assigned to those networks also covered by IPv6 assignments must reach:

* 25 % within 12 months;
* 50 % within 24 months;
* 75 % within 36 months;
* 95 % within 48 months;

For avoidance of doubt:  Assigned IPv6 space must be reachable from the global routing table.

In the case where a network provides both access and content hosting services, both criteria must be independently complied with."

This would address my concerns, and I believe still force those networks looking to obtain additional space that have not yet deployed IPv6 to do so.

I think linking this to traffic thresholds is a very bad idea.  Especially if it's linked to specific top 25-IPv4 external sites.  I suspect at least a few of those top external sites in our case would be banking sites - and NONE of the major banks in SA has any client-facing IPv6 deployed that I'm aware of - making it impossible for us to comply even if 100% of our customers has access to and are IPv6 enabled.  I did have a discussion about this and DNSSEC with at least one such case yesterday, but I promise you nothing will come from that.

One concern I still have is that the above implies every single piece of assigned address space can 100% clearly be categorised into access or hosting, which isn't always as clearly defined as one would like it to be, but I'd wager that in those cases one or the other will be the predominant purpose, and we can just use that purpose for those cases.  This is something I'd leave to operational discretion to qualify at application/assessment time to be honest.  As long as each piece of assigned space (ie, the minimum 90% usage) from the LIR/EU is classified into one of these categories.

I hope this helps, and thanks for the chat Mark.

Kind regards,
Jaco

On 2026/07/20 10:30, Jaco Kroon via RPD wrote:

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<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<mailto:mje at posix.co.za>       Tel: +27.826010496<tel:+27826010496>
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za<https://ftth.posix.co.za>

_______________________________________________

RPD mailing list

RPD at afrinic.net<mailto:RPD at afrinic.net>

https://lists.afrinic.net/mailman/listinfo/rpd<https://lists.afrinic.net/mailman/listinfo/rpd>

_______________________________________________

RPD mailing list

RPD at afrinic.net<mailto:RPD at afrinic.net>

https://lists.afrinic.net/mailman/listinfo/rpd<https://lists.afrinic.net/mailman/listinfo/rpd>
_______________________________________________
RPD mailing list
RPD at afrinic.net<mailto:RPD at afrinic.net>
https://lists.afrinic.net/mailman/listinfo/rpd<https://lists.afrinic.net/mailman/listinfo/rpd>

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com<http://www.theipv6company.com>
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20260722/05981c9e/attachment-0001.html>