If you didn't see it in last thread, http://geekmerc.livejournal.com/699.html may provide some information for you, but I can tell from your concerns that your current choice of edge layouts is different than mine. As such, more below. Mikael Abrahamsson wrote:
Now, take for instance the residential LAN case. There are several models on how to do this, but they all (that I know of) reside around the fact that each customer gets one or more globally routed IP address via DHCP, and security against spoofing and "man in the middle"-attacks is either done via forced-forwarding in the L2 device the customer connects to, or it's done via setting L3 accesslists learnt via DHCP snooping that inspect L2-packets in that same device. Often both is done, and also things like "ARP inspection", rogue dhcp server protection, MAC-rewrite etc is used. These are essential security mechanisms because customers should be protected from each other when it comes to these types of L2 attacks. Tracability (who had what IP at what time) is done via DHCP option82 and logging of this information. So, the L2 devices closest to the customer does a lot of "magic". All of these mechanisms were developed in the first half of the last decade.
Unnumbered vlans and RBE support on cisco, I guess could be considered forced forwarding in layer 2. It definitely makes for beautifully long configurations and severely limits dslams to support enough vlans for 1 vlan per port, preferably with q-in-q. It also had the benefit of separation of responsibility, as telco could play with dslams (atm or vlans) and networking played with routers where tracking/policing was implemented. Of course, moving away from ATM terminated systems seems to be the big deal, and not all systems support massive vlan terminations. I believe the vendors said, "Why on earth would you want to do that! It's like replicating pvc's!" Those vendors do cute things in their dslams such as dhcp snooping and limiting broadcast domains. IPv6 changes this from broadcast domains to multicast. Luckily, thanks to triple play, most of these same dslams also understand multicast and do igmp snooping. Adding support for multicast RA snooping is considered trivial by most, which is why they haven't bothered with it yet.
Now, with IPv6 this model changes drastically. The proposed mechanisms for IP number handout etc, is RA and DHCPv6. How does that fit into the model above? It doesn't, and the L2 devices surely won't "sniff" it and enforce security measures mentioned above.
Why not? They "sniff" igmp. What's the difference? Multicast is already commonly supported by most dslam manufacturers using flat topology.
My ideal model would be to replace the above mentioned L2 device with a small and simple L3 device (L3 switch) with very small TCAM (TCAM size 6-8 times port number should be enough), where this device uses link-local with the CPEs (would require all customers to actually have a router at home), hands out prefixes via DHCPv6-PD, inserts route towards customer link-local address, provisions anti-spoofing ACLs on that port, logs what prefix was given out to each port at what time, and off we go.
I suggest heavy testing of this. I'm not sure that CPE's will be happy about doing PD requests without having received a prefix/IP for the interface. It'll also create create problems for traceroutes. ;) The other option that is extremely simple is statically assign /64 to each port and then if they do PD, insert the route and do anti-spoofing. This is, btw, what RBE sorta does with IPv6 in atm world.
So, how can we fit current IPv6 into the IPv4 security model? We can't. Current L2 devices won't do any of the IPv6 security stuff needed, and just turning on RA/DHCPv6 would make it work from a "let's move packets"-aspect, but it wouldn't be secure (perhaps in some forced-forwarding cases there might be a possibility of doing it securely, but what devices will log what customer had what IP at what time when it's done via RA?).
I'll agree that I haven't seen the necessary support by vendors for what should be trivial to change as mentioned above. One reason I took the headache of treating vlans like pvcs is lack of uniform support at layer 2 for security policies. Vlans, though. Simple. They either support the required number, or they don't.
and the L2 device doesn't know anything about that). I don't know if this has actually been done, but I see no theoretical problem with it, if someone can come up with something, please do tell.
Depends on the L2 device and how it's configured to deal with multicast. If you didn't think about multicast when deploying, then IPv6 is doing a service by reminding people that it exists. ;)
So, my view on IPv6 is that I would love to roll it out to all residential customers, but unfortunately all the development done for IPv4 security has gone unnoticed by the people developing IPv6 and now it's behind and needs to catch up, or pitch a different model and then get vendors to develop products that do this.
Vendors are the ones who are behind. Talk to yours. Multicast is simpler to manage in L2 than broadcast. As to the support by vendors, that's another question. I can't say I've been impressed with the overall vendor support. On the other hand, I'm the first to order equipment I didn't like to begin with into the trash due to no IPv6 support. ;)
In the mean time, we do (and I encourage everybody else to do the same) support 6to4 and Teredo, plus we do IPv6 native in the core and peering where possible plus we give IPv6 to customers where we're able to securely (mostly transit customers and corporate customers with IPv6 capable CPEs).
Hate Teredo, and 6to4 rarely works due to the billions of home routers. The best one can hope for is securing down to the edge and customers eventually will have to buy a new home router to get their IPv6. (Most cheapy routers on the market now have 2MB flash. The current images for download are ususally about 1.8MB in size. I don't see 2MB flash routers supporting the additional overhead of IPv6 support.) Jack