On Wed, 7 Nov 2012, Tim Densmore wrote:
My aim here is to allow CPE, or CPE-connected devices to "pull" IPs via SLAAC, with DHCP-PD being a possible end-goal, but one that will require forklifting thousands of DSL modems and/or NAT routers.
Check.
Currently for most v4 DSL subscribers, we use "ip unnumbered" pointing towards a loopback that functions as the gateway and use DHCP or host routes or radius to assign IPs. This config appears impossible using v6, since loopbacks don't send RAs, and DAD wouldn't work with multiple isolated P2P links all IPd from the same /64 in any case. Basically, I'm looking for a way to send non-link-local RAs down ATM P2P subints, and dot1q qinq subints.
Is this point to point ATM, or is it ethernet over ATM? I'd say if it's EoATM and you're doing bridging in the CPE, your only choice is to put a /64 on the interface (one per customer), and try to limit the number of nd entries you allow per customer. Customer devices will use RA to get addresses, and use DHCPv6-stateless to hand out DNS resolvers etc. Optional DHCPv6-PD support in case the customer has a CPE to put behind the modem.
The better and future proof way is to run LL only on the p-t-p ATM link (regardless if it's EoATM or just routed IP over ATM), and do DHCPv6-PD with a /56 to the CPE which then handles all scaling aspects.
For the ETTH scenario, use a /64 per customer, do L2 isolation, do antispoofing, and support DHCPv6-PD in case the customer has a capable CPE. This means the customer can hook up a PC or a CPE, and both will work.
I prefer to do this all statically so the customer has the same prefix (both /64 and what he gets via PD) all the time, but that's a marketing decision more than a technical one.
-- Mikael Abrahamsson email: [email protected] _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
