IPv6 duplicate DAD packets from Android clients?

[Andrew Yourtchenko]

Not sure which exactly version you run, I've looked at the behavior on
a lab 2500 running 7.4.100.108.

inline.

On 10/8/13, Phil Mayers <p.mayers at imperial.ac.uk> wrote:
> All,
>
> Since our student body have returned, we've been seeing a trickle of:
>
> %IPV6_ND-6-DUPLICATE_INFO: DAD attempt detected for FE80::5:73FF:FEA0:1
> on VlanNNN
>
> ...on our Cisco 6500s. The vlan points to a bunch of Cisco WLC
> controllers running 7.4 and with all the IPv6 FHS turned on.
>
> When I capture the packets (thanks for not logging the source MAC,
> Cisco!)

CCing Steve Simlo  so we take a note of this. A very valid operational
issue indeed. Sorry for the pain caused. (NB: no guarantees it ever
makes into a code, but I'll nag Steve periodically about it :-).

> I see it's coming from the MAC address of a couple of Android
> devices.
>
> Source IP is :: dest is ff02::1:ffa0:1 (obviously) and the IP is a
> HSRPv2 virtual IP on the router itself.
>
> So, two things:
>
>   1. Should the Cisco WLC IPv6 FHS stuff be blocking these, given the
> target IP is the HSRP VIP and is obviously not on a client?

No. NS is merely a query - it does not affect anything. It's the NAs
that you'd need to be worried about and have blocked. (And indeed they
were blocked for me and reflected in the WLC counters as 'martian').

Also, because the target is on the wired,  you do not need to worry
about the bandwidth saving, so AFAIK the ND proxying is not done in
this case - if this was another wireless client, the requester would
have seen the NA coming directly from the controller, avoiding the
mcast flooding of this NS in the subnet.

> Do I need to
> be worried about them?

Depends on what their source is. I'd investigate, because:

a) If those are seen only with HTC as another mail points out, I can
imagine someone could have used that as another way to do a quick
network probing (similar to iOS devices sending the queries the last
WiFi networks you've been to - it's fun stuff!) So the logic would be
- alongside with bringing up your own addressing try a DAD against a
few previously used routers and use it as a heuristic for network
connection. NB: I am speculating here. Blatantly.

b) OTOH, it could well be someone who either used some badly written
attack tool or did not RTFM properly before attempting to play around.
:-)

Anyway in my quick lab test the NS for default gateway's address
always got sent up the wired side but never to any other wireless
clients - so it's only this client which will suffer the consequences.

>
>   2. Where are they coming from? Is the client buggy and actually
> emitting the packet, or is it relaying these somehow from another network?
>

I tried to speculate a bit on this one above. But the definitive way
to get the answer would be to try and track the owner of these devices
and verify what the source of the behavior is.

HTH.

--a