On 11/7/2012 10:49 AM, Mikael Abrahamsson wrote:
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.
Yes, this is P2P ATM and per-customer-vlan "P2P" metro-e QinQ links. The number of bridged CPE is probably minimal, and this is really just sort of a test to see how many devices would "do v6" on or current network, natively. I guess I could tell that with LL addys, though, by slapping "ipv6 enable" on interfaces and seeing how many neighbors I end up with.
What I think I'm discovering is that v6 in the core is easy, and static assignments and/or tunneling is easy, but delivering v6 automatically to customers is probably going to be expensive or difficult or both. I knew that from the start, at least intellectually, but I keep discovering new scenarios I hadn't considered.
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.
Yeah, maybe LL is the way to go. I have to admit that I'm still sort of fuzzy on where LL-only makes sense and where it will cause issues, so I tend to use GUAs in all scenarios.
Deterministic DHCP-PD is where I'd like to end up, though how that's eventually done both provisioning-wise and equipment-wise is TBD. I'd like to have *some* control over provisioning, but I'm not crazy about having to maintain a database of client ID's, either. Obviously still lots of work to do on that front.
Thanks for the very useful input! TD _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
