Question: Is there a particular reason as to why neighbor solicitations for IPv6 are being flooded back out to the wireless network? Shouldn't the controller be able to serve as a proxy for DAD, and hence filter the NSs being sent for DAD? (if the controller were to detect a duplicate IPv6 address in its user table, then it could either flood it out or unicast it to the client in question)
When it comes to IPv6, we have largely followed the same rules as IPv4 apart from for DAD probes.
To answer question about why controller can't respond to DAD probes, it is not guaranteed that the other
user has already taken over the IPv6 address it is performing DAD for. Since, we don't create a user entry using DAD, we can't as the client itself is not sure about whether it can use the IP address or not.
We have a solution in mind wherein we shall create a temporary user based on first DAD probe seen and then respond to any client with proxy-NA as response. There is no timeline yet for this solution though.
As for suppress ARP, it all depends on what kind of grat ARP it is, sip 0 wherein it is a dup detection probe with ARP type being request or a grat ARP reply. For grat ARP requests, we drop them if don't find a user on the wireless, and this is done regardless of whether the request was seen from an AP tunnel or just a wired port.
Grat ARP replies, used to update the arp caches of peers is allowed to go as is. This also applies to Unsolicited IPv6 NA packets.