[lwip-devel] [patch #9190] ipv6: adjust MLD membership on address state changes

[David van Moolenbroek]

URL:
  <http://savannah.nongnu.org/patch/?9190>

                 Summary: ipv6: adjust MLD membership on address state changes
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: dcvmoole
            Submitted on: Fri 16 Dec 2016 10:25:11 PM GMT
                Category: IPv6
                Priority: 5 - Normal
                  Status: None
                 Privacy: Public
             Assigned to: None
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None

    _______________________________________________________

Details:

As I mentioned in another thread, the other day I discovered that enabling
LWIP_IPV6_MLD has the side effect of requiring that for *all* local IPv6
addresses, the appropriate solicited-node multicast group is joined as well.
This is not just a theoretical requirement (RFC 4291 Sec. 2.7.1) but also
practically necessary for other nodes to be able to contact the local node,
regardless of whether DAD is enabled. So, necessary stuff for anyone who
enables LWIP_IPV6_MLD.

Now that I'm looking into how to manage such multicast group membership, I'm
surprised by how complex this is getting. The main reason for the complexity
is that nd6.c has selective support already: it joins the multicast group when
moving a local address from state TENTATIVE (which from here on I'm calling
TENTATIVE_0 for clarity) to TENTATIVE_1, and leaves the group when a DAD
collision is detected (moving the state to INVALID). As far as I can tell, the
multicast group is not joined when the address is set manually to PREFERRED or
DEPRECATED, nor may be it be joined yet if the interface is down, nor is it
joined when DUP_DETECTION_ATTEMPTS is set to 0 in which case there is a direct
transition from TENTATIVE_0 to PREFERRED.

That means that the extra logic I would need to manage solicited-node
multicast membership in the light of arbitrary (i.e., user-initiated) address
addition and deletion, looks like this:

When adding a local IPv6 address:
- if the address is added and then immediately set to PREFERRED or DEPRECATED,
then join the corresponding multicast group

When deleting a local IPv6 address:
- if the address was originally added as PREFERRED or DEPRECATED, or it was
added as TENTATIVE_0 and is currently not in state TENTATIVE_0 or INVALID,
then leave the corresponding multicast group

And that does not even cover the DUP_DETECTION_ATTEMPTS==0 case.

To put this in another way: as far as I can tell, right now lwIP/nd6 takes
care of proper MLD membership out of the box *only* when addresses are only
ever added as TENTATIVE and never deleted, and DUP_DETECTION_ATTEMPTS is not
set to 0. In all other cases, additional user-side logic like above is needed,
or MLD membership will end up being off. This all seems unnecessarily
complicated to me, and it seems to me that lwIP itself is in fact in a much
better position to manage such multicast group membership.

My proposal here is to make netif_ip6_addr_set_state() take over management of
the solicited-node multicast group membership entirely. It can then simply
enforce the following invariant: at any time, if an address is not in INVALID
or TENTATIVE_0 state, the netif is a member of the corresponding
solicited-node group. That rule should be sufficient to replace the current
MLD logic in nd6 without any behavioral changes [*], and also reduces my
required efforts to manage the solicited-node multicast group membership to
the following..

When adding a local IPv6 address:
- (nothing further to do)

When deleting a local IPv6 address:
- (nothing further to do)

..which is kind of what I would like to see :) and I imagine others (who want
more than the above out-of-the-box situation) would prefer as well.

I believe that netif_ip6_addr_set_state() is then also the right place to
check NETIF_FLAG_MLD6, putting that flag to actual use, so that the automatic
membership transitions are skipped for eg PPP interfaces.

That is the first patch attached here. Please let me know if this makes sense
and/or whether I overlooked something at any level.

The second patch attempts to turn some of my initial ignorance on the general
subject into hints that are hopefully helpful to others..

[*] As far as I can tell, the biggest difference is that with AUTOCONFIG
addresses, the same multicast group will now be joined (and left) multiple
times rather than once. Since multicast groups have a use count anyway, this
does not have any visible effects.



    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Fri 16 Dec 2016 10:25:11 PM GMT  Name:
0001-ipv6-adjust-MLD-membership-on-address-state-changes.patch  Size: 5kB  
By: dcvmoole

<http://savannah.nongnu.org/patch/download.php?file_id=39254>
-------------------------------------------------------
Date: Fri 16 Dec 2016 10:25:11 PM GMT  Name:
0002-opt.h-provide-some-hints-regarding-MLD-settings.patch  Size: 1kB   By:
dcvmoole

<http://savannah.nongnu.org/patch/download.php?file_id=39255>

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/patch/?9190>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/