How to preempt rogue RAs?

[Tore Anderson]

* Mikael Abrahamsson

> Well, it's good that they did it, it's bad that they didn't do it properly.
> 
> They're the ISP, they should make sure one customer can't affect other
> customer by means of L2 or L3 errors/trickery, either intentional or
> unintentional.

As Steinar Haug said in another message:  We can all agree that fixing
the shared L2 is the best solution.

However, shared L2 deployment in IPv4-only networks with rogue RA
problems is very common, it's certainly not something the ISP in
question was alone about.  I'm grateful to them for working with me in
trying to solve the problem instead of just ignoring it (which is what
most networks I've contacted do).

I'd like to come up with a solution to the problem I could present to
the next network on my list.  However if that includes drastically
changing the access model and/or replacing lots of hardware...  Well,
it'd be like tilting at windmills I suppose.  I'm not even sure it's at
all possible to insulate users from each other in all cases.  How would
you do it in a public WiFi network?  (I've heard that even the IETF har
problems with rogue RAs on their conference network...  If they can't
get it right, who can?)

My hope was that deploying native IPv6 would stop the 6to4 rogue RA
madness.  After all, there's no reason whatsoever for a OS or HGW to
bother with tunneling when native IPv6 service is available, and
everything would have worked fine.  Of course, the ISP would still be
vulnerable to malicious rogue RAs, but then again they already had that
problem with rogue DHCPv4 servers and have been able to live with it so
far.  IMHO it's a big problem if you can't retro-fit IPv6 onto
infrastructure already running IPv4 and at the same time keep the
operational stability for both protocols about the same.

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27