kern/156317: Wrong order of IPv6 NS DAD/MLD Report

[Petr Lampa]

>Number:         156317
>Category:       kern
>Synopsis:       Wrong order of IPv6 NS DAD/MLD Report
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Apr 10 19:10:11 UTC 2011
>Closed-Date:
>Last-Modified:
>Originator:     Petr Lampa
>Release:        8.2-STABLE
>Organization:
BUT FIT
>Environment:
FreeBSD xxxx 8.2-STABLE FreeBSD 8.2-STABLE #7: Sat Feb 26 17:58:31 CET 2011
>Description:
RFC 4862 5.4.2. Sending Neighbor Solicitation Messages says:

Before sending a Neighbor Solicitation, an interface MUST join the
all-nodes multicast address and the solicited-node multicast address
of the tentative address.  The former ensures that the node receives
Neighbor Advertisements from other nodes already using the address;
the latter ensures that two nodes attempting to use the same address
simultaneously should detect each other's presence.
..
It should be noted, however, that in some link-
layer environments, particularly with MLD-snooping switches, no
multicast reception will be available until the MLD report is sent.

FreeBSD sends NS packet to solicited-node group (here ff02::1:ffe5:90e) before MLD Report for this group, which is wrong (if you have MLD snooping switch in network, you may loose response)! Time window for potential problems is small, but this should be fixed.

20:34:38.418878 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 24) :: > ff02::1:ffe5:90e: [icmp6 sum ok] ICMP6, neighbor solicitation, length 24, who has 2001:67c:1220:809::93e5:90e
20:34:38.418919 IP6 (hlim 1, next-header Options (0) payload length: 56) :: > ff02::16: HBH (padn)(rtalert: 0x0000) [icmp6 sum ok] ICMP6, multicast listener report v2, length 48, 2 group record(s) [gaddr ff02::1:ffe5:90e to_ex, 0 source(s)] [gaddr ff02::1:ffd7:3816 to_ex, 0 source(s)]
20:34:38.418961 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 24) :: > ff02::1:ffd7:3816: [icmp6 sum ok] ICMP6, neighbor solicitation, length 24, who has fe80::230:48ff:fed7:3816
20:34:38.419001 IP6 (hlim 1, next-header Options (0) payload length: 56) :: > ff02::16: HBH (padn)(rtalert: 0x0000) [icmp6 sum ok] ICMP6, multicast listener report v2, length 48, 2 group record(s) [gaddr ff02::1:ffe5:90e to_ex, 0 source(s)] [gaddr ff02::1:ffd7:3816 to_ex, 0 source(s)]

>How-To-Repeat:
Configure IPv6, boot system and watch packets.
>Fix:
The delay for MLD report is calculated at line 977 in in6.c:

                if ((flags & IN6_IFAUPDATE_DADDELAY)) {
                        /*
                         * We need a random delay for DAD on the address
                         * being configured.  It also means delaying
                         * transmission of the corresponding MLD report to
                         * avoid report collision.
                         * [draft-ietf-ipv6-rfc2462bis-02.txt]
                         */
                        delay = arc4random() %
                            (MAX_RTR_SOLICITATION_DELAY * hz);
                }
                imm = in6_joingroup(ifp, &llsol, &error, delay);

Then the same algorithm is independently used for DAD delay further, so it can produce smaller delay. DAD delay should be set to MLD delay + DAD delay (with MAX_RTR_SOLICITATION/2)!

>Release-Note:
>Audit-Trail:
>Unformatted: