The use case that precipitated this was in the context of this howto/guide: https://github.com/openweave/openweave-core/blob/master/doc/guides/cross-network-inet-multicast-howto.md (https://openweave.io/guides/cross-network-inet-multicast-howto) when built against LwIP.

Sorry, not enough time for lwIP last year. I'm trying to catch up...

I am presently working on extensions to the Weave Inet IPv4/IPv6 portability layer to add full IPv4/IPv6 join/leave group multicast support <https://github.com/openweave/openweave-core/issues/115>.

I have working functional tests against BSD sockets that work well on Linux and Mac OS X. In running the same functional tests against LwIP, I’ve encountered what I believe to be a bug in one of two places.

For IPv6, the functional test uses several IPv6 site-local scoped multicast address groups sent from several nodes with only a link-local address and bound to the interface with that LLA. On sockets, we see that the LLA is selected as the source address. On LwIP, using top-of-tree, we see the any/unspecified address (assigned as address index 1 on the interface) as the selected source. This seems incorrect or at least inconsistent.

To address this, assuming the bug / issue is in ip6_select_source_address, the patch that fixed the issue and makes the behavior consistent with Linux and Mac OS X and, by my read of RFC 6724 Section 5, still RFC-compliant is (see also attached):

--- a/src/core/ipv6/ip6.c
+++ b/src/core/ipv6/ip6.c
@@ -281,6 +281,12 @@ ip6_select_source_address(struct netif *netif, const ip6_addr_t *dest)
     }
     /* Determine the scope of this candidate address. Same ordering idea. */
     cand_addr = netif_ip6_addr(netif, i);
+
+    if (ip6_addr_isany(cand_addr) || ip6_addr_ismulticast(cand_addr)) {
+        LWIP_DEBUGF(IP6_DEBUG | LWIP_DBG_LEVEL_WARNING, ("unspecified / multicast address assigned as unicast address on %c%c%u\n", netif->name[0], netif->name[1], netif->num));
+        continue;
+    }
+
     if (ip6_addr_isglobal(cand_addr)) {
       cand_scope = IP6_MULTICAST_SCOPE_GLOBAL;
     } else if (ip6_addr_islinklocal(cand_addr)) {

Now, it is also possible that the any/specified address on the interface should never be marked IP6_ADDR_PREFERRED; however, I know that is a valid source for some ND6 DAD use cases, so perhaps that assignment on the interface is intentional. However, if not, then the bug lies elsewhere perhaps and the patch to ip6_select_source_address is unneeded, though probably still good defense.