Jose,
I was able to reproduce the problem. I should have known this problem looked familiar ... I actually have seen this issue before on different hardware and I am pretty sure that it is a problem in the driver related to the reception of multicast packets for IPv6 (and possibly IPv4, as well)
The problem you are seeing exactly matches the following bug, which was a driver problem and was fixed in the driver for a different hardware platform (OMAPL138, a.k.a "Freon"):
SDOCM00098789 - NDK doesn't respond to Neighbor Solicitation messages on Freon
I will get in touch with the 6678 driver team about this issue.
Steve
P.S. From the bug's description:
"This problem only seems to occur on Freon. I suspect it may be a driver issue (ICMPv6 messages or IPv6 multicast messages being filtered at driver level ...)
When running the IPv6 enabled client example, a Linux or Windows host will not get any response when trying to ping6 to the Freon board.
It seems that the stack never receives the NS message that comes out from the Windows/Linux host as a result of running IPv6 ping.
What's interesting is that if one telnets into the NDK, then runs an IPv6 ping from the NDK to the Linux or Windows host, the NDK will get a response. (this is due to the Linux/Windows host *not* having such a problem receiving NS messages).
Once the Linux/Win host responds to the NDK's NS message (with a NA), it updates its neighbor table and can then "see" the other hosts.
After this, it is possible to ping6 from Linux/Windows host to the NDK.
Note that this does not happen on M3. These NS messages are received on the Concerto platform and pings work right off the bat there."