On Wed, 9 Oct 2024, Howard, Lee wrote:
First, roll out IPv6 if you haven't yet. That should relieve a lot of pressure on your pool size, and gives customers a workaround for some of the weird things ("Use the IPv6 address instead of IPv4.").
Second, build your own geofeed. You can create a CSV providing as much detail as you want, down to "This individual address is at this long/lat" if you want. Then publish the location of that file in whois. Short pointer: https://mailman.nanog.org/pipermail/nanog/2022-April/219080.html
After you've rolled out IPv6 you can consider 464xlat or MAP-T. Both work well, but both require support from the CPE. I've heard of a custom implementation that kicks a customer off the CGN/xlat/BR if it detects uPNP (i.e., a customer that needs port forwarding). It requires reprovisioning the CPE and a reboot, but two minutes of downtime probably prevents a support call.
I was just googling something related, hit this thread, and realized I'd neglected to reply to some of the messages I should have responded to :) The network is "fully" dual-stack. There are a couple of pockets of legacy gear that didn't get dual-stacked when the rest of the network was done years ago, and we're not subjecting those pockets to CGNAT. Our policy has been, "if v4 is all you have, you keep your public IP service." We've had a geofeed for some time. The trick seems to be getting IP Geo providers to use it (and making sure the data in it is both accurate and syntactically correct). I added comments to each of our ARIN IP blocks: Comment: Geofeed: https://geofeed.bluestreamfiber.net/ ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Blue Stream Fiber, Sr. Neteng | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________