All,
We have occasional but serious problems with rogue IPv6 routers on our
Cisco lightweight wireless service (WiSMs in 6500s). Win7/vista machines
with internet connection sharing seem to acquire then re-advertise a
6to4 prefix. This causes broken connectivity (because 6to4 is blocked at
our site - sadly this does not prevent the windows machines *thinking*
they have a 6to4 range)
In addition, the windows machines are DHCPv6 servers, and advertise
themselves as DNSv6 servers. When they disconnect from the wireless,
clients suffer DNS timeouts. This seems to particularly cause problems
for iPhones.
And finally of course there are the obvious security implications -
firewall traversal and sending peoples traffic through other peoples
machines.
I believe that various bits of the lightweight wireless are IPv4 only
"under the hood" and will likely require a controller hardware update to
make IPv6-aware. This is fine - annoying, but fine. What I really want
to do in the meantime is block *ALL* ipv6 - i.e. drop ethertype 0x86dd.
Can this be done? I do not think it can in the current firmware release,
but it seems obvious the access points are capable of it - it's a
trivial operation. Is anyone at Cisco reading and can give some insight
if and when this problem might be alleviated?
It has been suggested to me that the IDS signatures cannot drop
offending packets - they can only be used to disconnect the client after
the packet has been forwarded. This is a pretty sub-optimal solution -
this isn't malicious activity, and the support overhead of banning lots
of users is high.
To be clear - upstream blocking on the router does not work. The issue
is client->client traffic. It needs to happen right at the radio
interface on the wireless APs to be bulletproof AFAICT.
I am also reluctant to enable "real" IPv6, which ought to suppress the
client 6to4 activity, because (I believe) the IPv6 forwarding does not
obey vlan-assignment, a feature we use to segregate clients.
[Obviously I would *much* prefer to enable real IPv6, and we're prepared
for it - except for the vlan assignment issue...]
Suggestions greatly appreciated.
Cheers,
Phil
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
