Re: MLD maturity in kernel version 2.6.32.60

[Daniel Borkmann <dborkman@redhat.com>]

On 11/21/2013 05:04 AM, Hannes Frederic Sowa wrote:
> On Tue, Nov 19, 2013 at 01:12:36AM +0100, Daniel Borkmann wrote:
>> There's also still one issue which I am hesitant to implement, as i) I don't
>> think it's overly useful, ii) nobody complained so far. :-)
>>
>> In RFC2710 (MLD v1 spec), it says:
>>
>> 3.7. Other fields
>>
>>     The length of a received MLD message is computed by taking the IPv6
>>     Payload Length value and subtracting the length of any IPv6 extension
>>     headers present between the IPv6 header and the MLD message.  If that
>>     length is greater than 24 octets, that indicates that there are other
>>     fields present beyond the fields described above, perhaps belonging
>>     to a future backwards-compatible version of MLD.  An implementation
>>     of the version of MLD specified in this document MUST NOT send an MLD
>>     message longer than 24 octets and MUST ignore anything past the first
>>     24 octets of a received MLD message.  In all cases, the MLD checksum
>>     MUST be computed over the entire MLD message, not just the first 24
>>     octets.
>>
>> Then, RFC3810 which "updates" RFC2710 obviously has a bigger message length
>> than that. In igmp6_event_query(), we only check for len == MLD_V1_QUERY_LEN
>> and process MLD v1. Now, in case of MLD v1-only fallback, we MUST only
>> operate in v1 mode.
>>
>> Now, in case a v2 message comes in we could assume above statement "if
>> that length is greater than 24 octets, that indicates that there are other
>> fields present beyond the fields described above, perhaps belonging to a
>> future backwards-compatible version of MLD".
>>
>> But then on the other hand, we get completely wrong "Maximum Response Delay"
>> codes in the packet header as they are differently encoded in MLD v1 and MLD
>> v2 thus not really backwards compatible.
>
> Daniel, let's add something where we can easier export the per-interface
> mld status for net-next inclusive the timers either via netlink or procfs.
>
> I guess we cannot change /proc/net/igmp6 because of backward compatibility
> so I favor to add this via Nicolas netconf api.

Yes, sure sounds good to me. We can do that.