If you have a need for ULA, you're not going to hit those same restrictions.

Or you just get yourself a proper /32 and do it right.

Hell, Spectrum did this to TWC when they acquired them. I had working DHCPv6-PD in 2016. Spectrum ripped it all out in 2017. I just got a working WAN v6 address back like.... a year ago.

As for the decision makers who think, "This sounds hard and expensive." The worst, especially when you have a couple loud mouthed IPv6 opposers grabbing for their ears, essentially making the bad decisions for them.

I still say that the biggest roadblock to IPv6 adoption is shitty techs.

You're half-right about the problem, but it's even more basic: folks in positions of authority who confidently assert that IPv6 wasn't even needed in the first place.

I will say, if my next ISP gig decides to go CGNAT, I will probably go full NAT64 for it, and ignore the RFC6598 space altogther. But that promised gig has yet to actually materialize and I'm not holding my breath. They were also debating buying a /19 to get started, in liue of buying CGNAT hardware.

As for why your assignment ultimately failed. I am going to venture a guess it had something to do with the original target of this rule: IPv6 naysayers who firmly believe the two cannot coexist in any way shape or form. A lot of ID10Ts out there.

The technical aspects were not the hard part, nor the cause of the project's demise.

For some of these companies, renumbering isn't a one-and-done thing; it's a continual, never-ending time/resource sink.

But they'll still confidently assert that IPv6 won't help them.

RFC 4193 is not the solution in that case. No doubt RFC 4193 is better than RFC 1918 in most cases. But a /48 RFC 4193 prefix divided into /64 link prefixes doesn't give you anymore segments than 10/8 divided into /24s.

There are other ways to allocate IPv6 addresses which solves that problem. But there doesn't seem to be consensus on how it should be done.

My current stance is more:

Dual-stack when feasible and significant v4 access is still required.
Avoid CGNAT like the plague it is. NAT44 isn't nearly as awful to deal with. While fudementally the same basic thing, CGNAT is a very service provider centric thing, and it comes with a whole host of issues for the end users.
Single-stack with NAT64 when practical.

But, back to your original point. If you are facing RFC1918 exhaustion, you likely already looked into single stack and NAT64. if you didn't, you should be out of a job. The rule was originally aimed at people who had yet to invest in IPv6 at all. Going from v4 only to v6 only with NAT64 is a rather tall order. Dual stack is the far easier next step.

But yeah, the rule needs rewritten. I think I first coined this one in 2015, it was part of the original Twitter rant that later became the rules.

Generally speaking, you're gonna have to NAT your Internet-bound v4 traffic any which way; I don't see the big philosophical difference between using NAT64 versus NAT44 to do so.

In the USA, we are still dealing with people who want to debate whether IPv6 is ready for prime time, or even feasible. Meanwhile, there are nations that have been IPv6 heavy for over a decade now.

The world I live in, you have to maintain connectivity to both stacks somehow. I probably need to update some of the rules with corollaries. if you can actually exist without v4, consider doing it.

.... and I'm usually losing that battle.