[v6ops] Re: question about RFC9096 - lifetime for PDs delegated by forced roll ISPs

[Philipp Tiesel <[e-mail]>]

Hi,

> On 5. Sep 2025, at 10:41, Daryll Swer <contact=[e-mail]> wrote:
> 
> 
> Jordi
> 
>> May be we want to turn RIPE690 into a BCP and add current experience, according to this discussion?
> Good idea. But perhaps something more “enforcing-effect” than just a BCP, though (look how BCP-38 turned out).

Its’ an RFC, even for standards track RFCs, there is no RFC police that enforces anything. I guess BCP would be fine and match the spirit of RIPE-690.

> But I would propose RIPE-690 revision/review first, it's time we include CSP (Cloud Service Provider) networking into it, this means NAT-less IPv6 for K8s/K3s/VPS/Managed Web hosting etc, i.e. purely native-IPv6-only. I believe there were other members on this list who expressed in interest in writing something up for CSP networking + NAT-less IPv6.

As I do this at work, I might be able to just copy&paste our requirements into a draft ;-)
Currently, there is still a lot in flux and IPv6 is still not as mature as I wish for most CSPs.
Basic requirements I currently fight for:
- /56 or shorter per VPC
- /64 for virtual networks
- /96 or longer per VM (/64 would be nice, but only works out with regards to address space usage if you have no VPCs)
- NO NAT (yes, there are CSPs that currently force usage of NAT66)
- Address preservation across load balancers event in cases where an L4/L7 LB converts across address families.

> 
> And even for traditional residential SP networking, that “/56” suggestion may not bode well, for future home networks, as the number of IoT devices will scale exponentially, if we were to encourage ia_pd for all endpoints, everywhere, in a decade or two, with all the IoT stuff, we'd probably see more than 256 devices on a home LAN — this is with respect to RFC9663 not just for large domains but also home-network where ideally everything gets a prefix. Others can share their thoughts too.
> 
> --
> Best Regards
> Daryll Swer
> Website: daryllswer.com <https://l.shortlink.es/l/84a123fa90d5c141653c6fd4a5ebdd8ae157b09a?u=2153471>
> 
> On Fri, 5 Sept 2025 at 13:54, [e-mail] <mailto:[e-mail]> <jordi.palet=[e-mail] <mailto:[e-mail]>> wrote:
>> May be we want to turn RIPE690 into a BCP and add current experience, according to this discussion?
>> 
>> I’m happy to start that.
>> 
>> Regards,
>> Jordi
>> 
>> @jordipalet
>> 
>> 
>>> El 5 sept 2025, a las 10:14, Daryll Swer <contact=[e-mail] <mailto:[e-mail]>> escribió:
>>> 
>>> 
>>> I'll reply in a single email, saw many parts:
>>> 
>>>> Do we know of a case where this happens? I don't remember that from the earlier discussion. It sounds like we think it does happen, but this is faster than I've heard of before.
>>> I've come across end-user reports over the years of some (not saying it's common, but it's out there) ISPs having PD change every 60 minutes. I used “15 mins” for dramatic effect (the tone didn't pass very well over text), but yes, 60 mins, I've heard of such reports — I receive DMs/Emails from end-users who come across my IPv6 blogs, so it's insightful, as we don't typically see such reports in the public forums/social media (as far as I know).
>>> 
>>>> I get that this document says that. My question is, why is the host not choosing the most recently advertised GUA?
>>> Well, it does choose new, for “new” connection flows, for example, your web browser “reloads” a tab, new socket, new src, new flow. But that's not the case with a lot of end-user everyday applications — The many times I emulated dynamic PD (since I have my own /32 to play with along with physical IP transit to my home lab) and ran on-the-wire PCAPs, I see my end-user apps like WhatsApp, Instagram etc all Happy Eyeballs to IPv4 very fast (which is good), and they stay there for quite some random amount of time, whenever my host (iPhone, Android, Windows, whatever OS, all the above) receives the RA flood for zero lifetime and NEW RA with new prefix.
>>> 
>>> In fact, with Apple FaceTime, what's strange is even for inter-VLAN P2P call where both VLANs have a /64, these /64 are simulated to be dynamic, it defaults to IPv4 with Apple's STUN (over my Hairpin NAT configuration of course which allowed native intra-NAT traffic, this means no TURN).
>>> 
>>> In contrast, when my prefix is stable/static (in my testing, I set valid/pref timers to infinite, some NOSes allow this) and repeated the above tests (again PCAPs) and indeed the majority of the traffic starts-with, stays-on, remains-with IPv6 GUAs for both Global Internet traffic and Inter/Intra-VLAN traffic. For Intra-VLAN traffic, it depends on the end-user software, Apple FaceTime IIRC supported link-local with mDNS and talks directly that way (good job Apple, I have always been a fan of how you implement your network code on mobile devices at least), I also noticed the iPhones sent STUN packets to each other intra-LAN, which I assumed is meant to help track network state to keep a call stable, but again, never seen GUA-based traffic when the ISP PD changes often and/or unstable.
>>> 
>>> Conclusion:
>>> Unstable IPv6 prefix from ISP messes up end-user app software, Happy Eyeballs kicks in (working as designed), traffic moves to IPv4 and stays there for X (not-so-short) amount of time.
>>> If the goal is “We want the public to be completely oblivious to IPv4 vs IPv6 AFI”, then in my opinion, stable ISP prefix is the only way to achieve this goal. Make IPv6 so good, that nobody can go back to IPv4.
>>> 
>>>> Those are temporary addresses. There are only (ha!) six prefixes there. Granted this is not great. An easy way to deal with this would be to say that if we get subsequent RAs from the router advertising new on-link prefixes and not advertising the old on-link prefix, that means the old on-link prefix is no longer valid and we should stop using it. What you are showing here is an indication that RAs were in fact successfully received.
>>> Look closely, “secured” addresses are in there, which of course becomes “temporary” because the ISP changes my prefix every random hours (5-6-7 etc), six prefixes indeed, uptime was around 14 hours on my local router.
>>> 
>>> Indeed, this was my macOS device with a MikroTik CE on my end, RAs worked correctly here for both “new” and “old”. But what worked for me, doesn't work for everyone and every CPE in the market.
>>> 
>>>> RFC7084 recommends it. 7084bis will require it. RFC9818 describes how to sub-delegate the ULA.
>>> Thanks, I'll review these.
>>> 
>>>> What are you talking about? Why do they need to know any of this? Why aren't they using mDNS to discover services on the network?
>>> Again, you're conflating professional network engineers with the average everyday Joe. The average everyday Joe prefers something like “mylaptop.lan, A record: 192.168.10.5, on the local stub resolver at that”, these are people who don't even know what .home.arpa is for.
>>> 
>>> mDNS of course works for mDNS applications like casting etc, but not every end-user “wants/needs” is mDNS-compatible or mDNS-based, one of these that I came across from end-users is Android/iPhone apps that lets you (v4/v6) access the phone gallery temporarily over IP:Port directly for easy-transfer into non-walled-garden OS simply by using a web browser like this one: https://simpletransfer.app/ <https://l.shortlink.es/l/ccf911ab479134c12c1846ac798061bdceb3edb6?u=2153471>
>>> 
>>> I've done many roll-outs for residential ISP use-cases and there are all kinds of support tickets coming in from end-users (please remember, these are people's grandparents, senior folks who many never even learnt IP networking beyond 192.168.0.0/24 <https://l.shortlink.es/l/740ea72b330efe5ec087cd010574b947eecf4e5e?u=2153471> if at all), these don't really make into the public forums/social media. The above example isn't uncommon. I in fact, would prefer if more NOC engineers who deal with this daily at far greater scale than myself, were involved in these IETF mailing lists, the more operational insights and data, the better for all of us here, less theory-only-on-paper, more practical-backed data.
>>> 
>>>> Sorry, that doesn't answer my question. If we are just griping about IPv6, and not being specific about what's broken, that's not a good use of WG time.
>>> I think so far in this email thread/chain, many of us have shared “what's broken” — i.e. dynamic prefixes from ISP level as the base foundation of the problem statement.
>>> 
>>>> So what I glean from this is that your IPv6 prefix changes more frequently than your IPv4 address. Otherwise, you would not see different behavior for IPv4—when your public IP address changes, there's nothing NAT can do to prevent the connection breaking.
>>>> 
>>>> So why is that?
>>> In most ISP deployments, the CPE gets a static /32 address from the 100.64.0.0/10 <https://l.shortlink.es/l/028d572b50ee331e48e1ca02538adb9419a4d027?u=2153471> range, it's statically assigned over RADIUS and in conjunction with deterministic CGNAT, a permanent (nothing is forever permanent, but “static” enough to be permanent) public IP:Port range is defined, meaning that the mapping once defined doesn't change very often.
>>> 
>>> So, something like this:
>>> DFZ-facing PE<>Core<>CGNAT<>BNG<>P nodes<>PE<>OLT<>ONT/CPE<>End-user human
>>> 
>>> ONT/CPE - 100.64.0.10
>>> CGNAT config - 100.64.0.10 mapped for 1.1.1.1 public IP, port range 3000-5000.
>>> 
>>> What happens if mid-way connectivity breaks?
>>> The DHCPv4 lease time is usually 24 hours + the RADIUS ensures it never changes even if you reboot your CPE.
>>> 
>>> Let's assume the MPLS transport between the OLT and the BNG breaks for say 10 seconds (common in real-life residential world, it's not the same thing as DIA/IPT/MEF carrier services segment). The CPE had a connection flow on 100.64.0.10:9000 <https://l.shortlink.es/l/14cacef25425c39dddf093b8ee14a5e0f935edf6?u=2153471> (Src IP:Port), with dst 8.8.8.8:443 <https://l.shortlink.es/l/128063adfe1be80523e89062924cf841216563bc?u=2153471>. The CGNAT box happened to map this session to 1.1.1.1:3001 <https://l.shortlink.es/l/5da224e72cbf885a2fea2960375ec3731f368d6f?u=2153471>, say connection state TCP-established (or UDP-Stream=yes, a feature on stateful tracking). All of a sudden connectivity is broken, well what happens:
>>> 1. The conn_track table entry on the CGNAT box is still there for this session
>>> 2. The conn_track table entry on the CPE is also still there for this session
>>> 3. Connectivity restored in 10 seconds
>>> 4. Connection flow resumes — no changes occurred to public IP:Port source IP (or “private” for that matter on the LAN).
>>> 
>>> Of course this can vary based on applications (retry/kill the session etc), but that's not the point. The point is IPv4/CGNAT is actually very “statically” architected at ISP level, especially intended to ease law enforcement requests (static mappings all over ensuring easier tracking/tracing). This isn't the case with IPv6 PD, it literally changes source IP every time.
>>> 
>>> --
>>> Best Regards
>>> Daryll Swer
>>> Website: daryllswer.com <https://l.shortlink.es/l/4362e66a969d8aa30fddf6ed552b57740ba910fe?u=2153471>
>>> 
>>> On Fri, 5 Sept 2025 at 02:40, Edward Lemon <[e-mail] <mailto:[e-mail]>> wrote:
>>>> On Sep 4, 2025, at 16:47, Daryll Swer <[e-mail] <mailto:[e-mail]>> wrote:
>>>> > When the home LAN/endpoint uses the deprecated prefix as egress source address for Internet-bound traffic, it will anyway hit the uRPF filters on the BNG, and even if the ISP failed to deploy uRPF (Hint: The majority), then you are correct, it just blackholes on the return path and there goes my SSH session to my jump host while doing mission-critical work, welp, IPv4 looks more attractive. 
>>>> 
>>>> So what I glean from this is that your IPv6 prefix changes more frequently than your IPv4 address. Otherwise, you would not see different behavior for IPv4—when your public IP address changes, there's nothing NAT can do to prevent the connection breaking.
>>>> 
>>>> So why is that?
>>>> 

AVE!
   Philipp S. Tiesel

-- 
Philipp S. Tiesel 
https://philipp.tiesel.net/