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

Wed Jul 22 09:29:24 UTC 2026

Hi Jordi, Mark,

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

"TheIPv6deploymentplanmust showtheactualIPv4top-25traffic 
destinationsofthatnetwork.For eachofthoseexternaldestinations
thatareIPv6-enabled,thefollowing minimumIPv6%willbeconsidered ascompliant:

"25% inamaximumof12months.
50% inamaximumof24months.
75% inamaximumof48months.

"Incaseofnetworkshostingany kindofservices,applicationsor 
contents,willbeconsideredas compliantwhenmatchingthe 
following%ofAAAARRsavailable andIPv6reachablefromInternet:

"25% inamaximumof12months.
75% inamaximumof24months.
95% inamaximumof48months.

"FailuretocomplywiththeIPv6 deploymentplanaccordingtothe 
relevantcriteria,constitutesapolicy 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 - 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
>
> _______________________________________________
> 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/20260722/334f4e0c/attachment-0001.html>