On 23 Jun 2011, at 08:03, Mikael Abrahamsson wrote: > Securing L2 networks is something not generally done today in enterprise and > surprisingly often in SP environments as well. This can be seen by all the > problems reported by Windows ICS v6 RA:s being sent out and causing problems > to other users (which in a properly build network it shouldn't have the > capability of doing, because those packets should be filtered by the access > network).
I think there is some effort to secure layer 2 in academic enterprises, e.g. I did a straw poll at a recent UK event and about 2/3rds of the admins there were using DHCPv4 snooping/filtering on layer 2 devices. But pretty much none had any filters applied for RAs, even if they could. This probably explains in part why so many admins are 'comfortable' with the idea of DHCPv6-only operation, in that it's a known risk model. Some mechanisms also don't help in the way they're deployed. While academic sites are now heavily into 802.1X for eduroam deployment, pretty much every rogue ICS-a-like RA that's seen is issued by a device that has authenticated using 802.1X, but in almost every case the devices are put into a shared VLAN, not one per user/device. But ICS-a-like rogue RAs are invariably 6to4 prefix, and RFC3484-bis generally handles that. And such 'accidental' rogue RAs are very unlikely to be fragmented in an attempt to defeat RA-Guard. RFC6104 was written with accidental RAs in mind, for reasons stated in the text. Interestingly I've noticed a few scenarios where unicast RAs are being suggested more, e.g. related to wireless roaming on campuses. Tim -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
