Mark Andrews <marka@isc.org> writes:
The DHCP server usually is sitting in a data center on the other side of the country with zero ability to inject approptiate routes.
Not too sure about that. At least, that's not what we do. We run the DHCPv6 and DHCP servers on our BNGs (or BRAS or whatever the current buzzword for "access router" is). So the "servers" have full control of both DHCP/DHCPv6 and routing. The DHCP backend database may need to be centralised, but tunneling the DHCP protocol all they way through your network just to achieve that seems unnecessarily risky and error-prone. Moving the DHCP frontends as close as possible to the clients is a very simple way to make DHCP scalable and robust. If you feel you should have a DHCP server in more than one site for robustness, then you might as well do a fully distributed design. Going half-way, centralising everything and then dividing it on multiple datasenters is just ten times the trouble.. If you only do pool-based arbitrary address allocations, then you might not need a centralised database at all. Distribute your prefixes to the BNGs and let them manage the pools independently of each other.
The DHCP relay could also have injected routes but that is a second class solution.
DHCP relays *are* second class solutions :) Unfortunately they cannot always be avoided in the semi-L2-environments like ISP access networks often are. Bjørn