SLAAC on Mac OS X

[sahe]

Hi folks,

I see strange issue with DAD on my macbook. MacOS version is 10.8.2.
My hardware is router which is configured to provide RA for it's LAN and WLAN clients. Also router has configured 6in4 tunnel to HE. First of all I want to tell you that on Win7 and on android devices (4.0 and 4.1) SLAAC is working correctly with my router, issue is inside MacOS.
When my macbook is trying to add link-Local address, everything is fine. In wireshark I see correct NS message (Source MAC is en0 MAC of macbook, Destination MAC is IPv6 multicast MAC (33.33.xx.xx.xx), Source IP is unspecified (:: ) and Destination IP is computed solicited multicast address of tentative inet6 address). DAD is successful, tentative address becomes active and reachable.
After that macbook is trying to add two global unicast addresses - for one of them interface id is based on MAC address, and the second one based on randomly chosen MAC address (temporary inet6 address). For both of these addresses I see common behavior in wireshark. I see two NS messages for each of tentative inet6 addresses. One message looks fine, all the fields in header are correct (the same as for link-local NS which is described earlier). The second one is a little bit strange. All the fields are the same except of one - Destination MAC. Destination MAC is MAC of my macbook's en0 nterface. As you see, source MAC and Destination MAC are the same for this message. When I've tried to run tcpdump on my router, I don't see the second NS, so it's alive only inside my laptop. As a result I see tag duplicated in the output of ifconfig on macbook and both of Global Unicast addresses are not active for me. In logfile I see that DAD detected duplicate address with NS in/out=1/1 in description.
Do anybody has the same issue on Mac OS? If no, please tell me the version of your OS.

I've checked RFC 2462 and there is something interesting in paragraph 5.4.3:

If the solicitation is from the node itself (because the node loops back multicast packets), the solicitation does not indicate the presence of a duplicate address.

If I understand correctly, macbook ignores this race condition for DAD. Also there is Appendix A  in RFC which describes some issues with DAD.
Guys, I need your help. Static configuration is working fine, but it's not the workaround:)

Sorry for my english, it's not my native language.

[tdensmore]

EDIT:  NM, sorry, I missed the part where you say that link-local addy works fine.

[tdensmore]

No problems with SLAAC IPv6 via wifi on either a macbook or a mac mini.  I believe they are running leopard and lion respectively, but I forgot to verify.  CPE is a mikrotik 751.

[Kjempeblakk]

Hi,

I'm having the exact same problem as you, and I'm also running OS X 10.8.2.

My steps to reproduce:
1) Reboot everything.
2) Connect Mac. The first time it connects everything is ok, and I get IPv6 connectivity to the Internet
3) Connect a Win7 PC. Both machines will now work fine.
4) Disconnect the Mac and reconnect it again, the problem will occur!

The only thing I have seen that differs from your description is that sometimes the DAD will actually fail on the link-local address first (with source MAC and destination MAC being the Mac's interface for the second NS-packet, just like you see), thereby stopping the whole process. Other times the link-local-address will be ok, but it fails on the two global-addresses.

Please let me know if you have found the root-cause for this, I'm stuck :-(


The only "workaround" I have found is to disable DAD on the Mac by using "sysctl -w net.inet6.ip6.dad_count=0". This is fine if you are a single user, but it really doesn't help me much from an ISP-perspective....


I'm also looking into if this problem only happens in WLAN. It seems that when I connect with cable everything works fine, but I have only tested this on OS X 10.7.4 so it's too soon to conclude. Of course the Mac I have with 10.7.4 has a defect WLAN-card and the one running 10.8.2 doesn't have a wired ethernet-connector so.....

[sahe]

Hi,

Thanks for your replies guys! Looks like it's an MLD snooper issue on my router's Wi-Fi driver. At the moment developer of my firmware added this bug to his todolist.

[Kjempeblakk]

Hi,

do you have any more details on the driver-bug? What chipset is used in the router? Mine is using Ralink3062. I'll discuss this issue with my firmware-developers...

Thanks!

[sahe]

Mine is Ralink RT3883 (Asus RT-N56U). I don't have enough details about bug, but we see that MLD snooper doesn't work correctly on WiFi interfaces (ra0 and rai0). This causes MAC-unicasts back to source of multicast packets which is incorrect. I could give you details later after resolving of issue.

[kasperd]

Is this one of those problems, that only manifests themselves, when there is a bug on both the router and the host?

[Kjempeblakk]

Correct, you need a combination of router-problem and client-problem. So far it seems Mac OS X (unclear which versions) and Win XP have a problem, but Win7 and some Android-devices does not have a problem.

[sahe]

Hi guys.

FYI, issue had been completely resolved for me. While enabling IGMP/MLD snooping on router, some multicast packets are sent as unicasts to all the clients which are known by router (via ARP cache). Also router send packet to it's originator. It causes SLAAC client to receive its NS message with its MAC address as source and destination. Client thinks that it is NS from another host. Then it detects duplicate and that's it. It's the issue of Ralink drivers on router, you need to fix sources to resolve it. Ralink coders forgot about DAD logic while performing snooping.
Here is commit from git of custom firmware for Asus RT-N56/N65 routers with DAD fix http://code.google.com/p/rt-n56u/source/detail?r=db54a88ab10034c729cd2b3f89d83c4e411605c5. You could check all the changes from original drivers by yourself. I hope this info will be helpful.