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

[Mikael Abrahamsson]

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: swmike at swm.pp.se