patchlwIP - A Lightweight TCP/IP stack - Patches: patch #9190, ipv6: adjust MLD membership on...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

patch #9190: ipv6: adjust MLD membership on address state changes

Submitter:  David van Moolenbroek <dcvmoole>
Submitted:  Fri 16 Dec 2016 10:25:11 PM UTC
   
 
Category:  IPv6 Priority:  5 - Normal
Status:  Done Privacy:  Public
Assigned to:  goldsimon Open/Closed:  Closed
Planned Release:  2.0.1

Jump to the original submission

Tue 20 Dec 2016 09:34:47 PM UTC, comment #8: 

Pushed since it looks correct (although I cannot really test it here, I'm afraid).

Thanks for your work on this, David!

Simon Goldschmidt <goldsimon>
Group administrator
Sun 18 Dec 2016 02:49:56 PM UTC, comment #7: 

I habe not found the time to Look at the patch, but from the explanation it sounds like a good idea.
The functions in netif have been introduced not too long ago, which explains why it is not used everywhere ;-)

Simon Goldschmidt <goldsimon>
Group administrator
Fri 16 Dec 2016 11:03:49 PM UTC, comment #6: 

Thanks! :)

David van Moolenbroek <dcvmoole>
Fri 16 Dec 2016 10:57:37 PM UTC, comment #5: 

cool, thanks.

I can actually think of some cases where I could use this case. I haven't reviewed the patch, but it sounds like a good idea.

Cheers
Ivan

Ivan Delamer <idelamer>
Group Member
Fri 16 Dec 2016 10:56:14 PM UTC, comment #4: 

In the current situation, it is moved from tentative to preferred (by nd6_tmr), but without joining the group. With my patch, that transition will automatically cause the group to be joined as well.

(I just noticed that I mistyped the actual name of the setting btw; it's DUP_DETECT_ATTEMPTS)

David van Moolenbroek <dcvmoole>
Fri 16 Dec 2016 10:47:55 PM UTC, comment #3: 

OK, I understand about deleting a local address.

Just another comment, what happens if DUP_DETECTION_ATTEMPTS is set to 0? I mean, if we set the address to tentative, does the stack set it to preferred and join the MLD group? I guess that would be the required functionality...

Ivan Delamer <idelamer>
Group Member
Fri 16 Dec 2016 10:45:46 PM UTC, comment #2: 

As far as I can tell, it is recommended ("should") but explicitly allowed to be disabled; see RFC 4862 Sec.4. However, even when forgetting both those cases, the issue of deleting a local address without desync'ing the multicast membership remains..

David van Moolenbroek <dcvmoole>
Fri 16 Dec 2016 10:36:34 PM UTC, comment #1: 

AFAIK you should never manually set an address to PREFERRED or set DUP_DETECTION_ATTEMPTS to 0.

I believe validating an address in the network is a pretty hard requirement...

Ivan Delamer <idelamer>
Group Member
Fri 16 Dec 2016 10:25:11 PM UTC, original submission:  

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.

David van Moolenbroek <dcvmoole>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by goldsimon (Posted a comment)
  • -email is unavailable- added by idelamer (Posted a comment)
  • -email is unavailable- added by dcvmoole (Submitted the item)
  • -email is unavailable- added by dcvmoole
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-12-20 goldsimon StatusNone Done
        Assigned toNone goldsimon
        Open/ClosedOpen Closed
        Planned ReleaseNone 2.0.1
    2016-12-16 dcvmoole Attached File- Added 0001-ipv6-adjust-MLD-membership-on-address-state-changes.patch, #39254
        Attached File- Added 0002-opt.h-provide-some-hints-regarding-MLD-settings.patch, #39255
        Carbon-Copy- Added idelamer

    Back to the top

    Powered by Savane 3.13-caa5.
    Corresponding source code