You'll have to connect the dots for me here, I'm not seeing the problem. The ISP's local network is not "the public Internet."
It very much is. An autonomous system can contain both "eyeballs" (possibly RFC6598 adressed) and services in datacenters/clouds, it's not *always* a different ISP. Perhaps I should have started this topic with a very specific example: - ISP A has a residential customer "Bob" in RFC6598 space - ISP A CGNATs Bob if the destination is beyond it's own IP space - ISP A doesn't CGNAT if the destination is within its IP space (as explained in the OP, this means reducing state and logging) - ISP A has a cloud customer "Alice" running mail/webservers, which is of course using public IP address space - when Bob access Alice's mail/webserver, the source IP will show RFC6598 addressing - if Alice filters RFC6598, Bob can't connect - Alice should not drop RFC6598, it should threat RFC6598 just like every other public IP subnet - only ISPs (which Alice is not) should drop RFC6598 on its network borders RFC6598 filters belong on network borders to other autonomous systems, not in a datacenter on a mail/webserver.
They can use RFC6598 and even RFC1918 at their leisure.
No, they really can't and shouldn't use RFC1918 in the public part of their network, because that will conflict with RFC1918 used by customers. Which is the entire point of RFC6598: an address space that does NOT conflict with private deployments, so that it can actually be used by the ISP. RFC1918 : the ISP customer gets to assign it RFC6598 : the ISP get's to assign it Of course a customer can configure 8.8.8.0/24 or 100.64.25.0/24 on their LAN, and a ISP can assign 192.168.0.0/16 to an addressing pool. That is technically possibly and I'm sure there are folks that are doing it. But it is not a good idea, it's not RFC compliant and will lead to issues down the road, which is why we have RFC's and BCP's.
If they choose to place services on those addresses and you want to use them, you'll have to exclude them from your local filtering and/or your own internal use. For everybody else, they're bogons.
I think my example above may clarify this. It's not about services in RFC6598. It's about services in public IP space, where clients connect to *from* RFC6598 IPs, which can and does happen when eyeball and service are in the same ASN/ISP. Thanks, Lukas