There's no need, those interfaces are already on the same subnet, and therefore, there's already a RIB entry stating that subnet prefix goes out that interface.
Now, Cisco is Big Brain(TM) and made it so that a DHCPv6 relay will inspect the relayed responses to slap static routes in. IPv4 DHCP does this too... if the interface the client is on is unnumbered.
So that means all my PE-CE links need to be over something P2P (serial), because multiaccess links (ethernet) can't be unnumbered.
This also means that... for special considerations, that all those PPP links used because... serial, likely need to go to a central AAA server like RADIUS, which might even be able to set things like static routes too instead of leases.
I know it can do it but this is spiraling out of control quickly.
Next up: CG-NAT, AKA NAT444. Seems pretty simple in theory, with a couple VRFs and some IP pools to configure the mappings.
Note on that: what that means is that for regular customers, the AAA server is going to have the DHCP server send out a free 100.64.0.0/10 address and start tracking them (once I learn how to configure the accounting part of AAA), and for enterprise customers, that means giving a static map for whatever IP block they're assigned that, if done right, either gets autoconfigured because PPP IPCP, or just heck with it, no configuration. They assign it themselves (Like I do right now)
What I'll likely end up doing is designating one CE group as enterprise, and another group as residential, with one IPv4 only and one IPv4/IPv6 client each. Each CE group has it's own DHCP server, but probably share the same central AAA server.
In total this means... at least 5 IS-IS areas (if I go back to IS-IS now that I realized my configuration mistake and don't stay on OSPF). Backbone, borders, res CE, ent CE, internal servers.
I bet my laptop and VM will love running some 3 dozen routers
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!