[c-nsp] IPv6 SLAAC on P2P or QinQ subints

[Tim Densmore]

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