How to preempt rogue RAs?

Leen Besselink leen at consolejunkie.net
Sat Oct 30 17:09:06 CEST 2010


On 10/30/2010 11:57 AM, Tore Anderson wrote:
> Hi,
>
> * Gert Doering
>
Hi Tore,

>> Some gear can filter out the RAs from sources where they are not 
>> authorized.
> I'm aware of that, but I don't think they're particularly open to
> forklift upgrading their entire access network to deal with this
> problem, or as Mikael suggested, doing drastic changes to their
> topology.  At least not in the sort term...
>
> The shared access LAN model clearly has its weaknesses, but it's quite
> common and for IPv4 works reasonably well in the absence of malicious
> users.  But for IPv6 it seems overwhelmingly likely that the users
> causing problems are completely oblivious as to what they're doing.
>

Yes, this is definitely a weakness.

Maybe this is a bad idea, but it is one of the few ideas I had.

I don't know the equipment or situation, but do you have a customer per
switch port ?

If the switch allows it, you could just block IPv6 per switch port based
on ethernet type.

Block it everywhere for everyone and enable IPv6 for customers that are
gonna use it.

Or allow it for everyone and play whack a mole and turn it off
selectively for those users
who are causing problems for others. I've never tried it, but I recently
noticed this tool,
it might help with that:

http://ndpmon.sourceforge.net/

It is not a solution, but if you are experiencing problems and first
want things to get back to
normal then this might be a temporary fix.

Hope that helps.

Have a nice weekend,
    Leen.

>> (Or someone at Microsoft could wake up, see the light, 
>> and stop ICS from breaking other people's IPv6 connectivity...  like, 
>> for example, only activate this if a) no other RAs are seen, and b) 
>> the user has manually enabled the feature)
> I haven't confirmed 100% that it's Windows ICS that's responsible for
> the RAs.  However some of the broken users ran the ISCI Netalyzr (a
> fantastic tool for getting great debugging info out of non-technical
> users by the way) at my request so I could see which 6to4 addresses they
> had configured and from which IPv4 addresses they were derived, and then
> I could see hits from some of those addresses, which identified
> themselves as Windows 7 (NT 6.1).  But that doesn't rule out the
> presence of a NAT box in between of course.
>
> I've briefly tried to reproduce the problem with a Windows 7 box I have
> here by turning on ICS on a IPv4-only LAN segment, and while I could see
> it activating the local 6to4 tunnel, it did not start transmitting RAs
> for that prefix.  So I'm not 100% sure if ICS is involved, and if it is,
> exactly how it has to be set up in order for the rogue RAs to show up.
> If somebody knows more in detail how ICS/6to4 operates I'd appreciate
> hearing about it, or if somebody has any suggestions on how it would
> have to be configured in order to break I'll be happy to try it out in
> my lab.
>
>> There's are a couple of IETF drafts focusing on this problem:
> Thanks.  I was hoping that deploying native IPv6 service would just
> sidestep the problem completely by having the ISPs router announce
> itself as the One True IPv6 Router by setting «ipv6 nd router-preference
> High».  But it doesn't seem to work.  :-(
>
> Best regards,




More information about the ipv6-ops mailing list