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

[Daryll Swer <[e-mail]>]

Hi


> 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.
>
I'd argue the spirit of RIPE-690 didn't turn out very well (hence this
discussion), if consensus could be reached for standards track RFC, I think
that would be ideal.
690 has been cited as authoritative source for years, yet here we are with
NAT66, dynamic /64s that changes every 6 hours and so on and so forth.

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

“VPC” has always confused me personally, as it appears the implementation
can vary from provider-software to provider-software (AWS VPC seems to be
not identical with Cloudstack VPC in my limited understanding). My question
is, within a given VPC, do we really need a /56, or would a /64 per VPC
suffice, i.e. the VM instances would get a /128 out of it. I assume, the VM
/128 (VPC) would be used for private comms, and for regular Internet bound
traffic then a regular non-VPC /64 routed-to-each-VM would suffice, or
possibly a /60 instead (giving sufficient /64s for more complex use cases
with K8s/encap/decaps/namespaces etc).

What's “virtual networks” mean in your example? I'd think a VPC is virtual,
so is the network/subnet routed to a VM for use with containers etc.

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

I'm by no means an expert with K8s, but I'm curious of the possible
solutions for NAT-less IPv6 with K8-based load balancing and address
preservation (anycast/BGP/ECMP/DSR).
If this aspect of CSPs could be standardised, I think it would help the
IPv6 deployments greatly.

The bottom-line (that I think most will agree with) is for both ISP and CSP
access network segments to be “good enough” that the end-user does not
require NAT66/NPTv6/NDP-Proxy hacks etc.

I've been thinking of what exactly classifies as “Stable PD” in SP world
and I think the answer should be something not locked to numbers but rather
with a statement, maybe something like this:
“The amount of time required for a prefix to be considered stable, is the
amount of time that the prefix has no justifications for change i.e. unless
drastic network changes and/or upgrades occurred such as M&As, physical
re-locations/re-route and/or major outages; until such or similar
conditions are met, the prefix must be stable for the end-user.”

This deletes “static” from the IPv6 PD vocabulary completely, which a lot
of “business” people really hate, while still, in theory, ensuring the
customer has minimal to zero issues. Again, I think using Starlink as a
planet-scale reference to base this off from, is a good approach — Their
IPv6 has never disappointed, even though it's not “static”, it's perfectly
stable.

*--*
Best Regards
Daryll Swer
Website: daryllswer.com
<https://l.shortlink.es/l/20784195556206c074967ff8d949217639e4fb58?u=2153471>


On Tue, 9 Sept 2025 at 18:59, Philipp Tiesel <[e-mail]> wrote:

> 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] <jordi.palet=
> [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]> 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]> wrote:
>>
>>> On Sep 4, 2025, at 16:47, Daryll Swer <[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/
> <https://l.shortlink.es/l/cc8106ec8db2251e4a0b8f851e0c278f45a43106?u=2153471>
>
>