MLD maturity in kernel version 2.6.32.60

MLD maturity in kernel version 2.6.32.60

[Simon Schneider]

Hi,
in a development project, we started evaluating MLD functionality.
 
Our development is based on kernel version 2.6.32.60.
 
We noticed some pretty basic issues:
 
- With force_mld_version set to 0 (we expect "MLDv2 with MLDv1 fallback"), we saw only MLDv2 messages, the fallback to MLDv1 didn't seem to work, when we sent MLDv1 messages to the unit.
- With force_mld_version set to 1 (we expect "MLDv1 only mode"), we also saw MLDv2 messages being generated.
 
Can someone give a general statement about the MLD implementation maturity in kernel 2.6.32.60? Are there known bugs that would explain the above observations?

We need to see whether it makes sense to put further effort in investigating/fixing any MLD related issue we see.

If this is the wrong list to ask this kind of question, please point me to the correct one.

Thanks in advance,
best regards, Simon Schneider
 

Re: MLD maturity in kernel version 2.6.32.60

[Daniel Borkmann]

On 11/18/2013 01:17 PM, Simon Schneider wrote:
>
> Hi,
> in a development project, we started evaluating MLD functionality.
>
> Our development is based on kernel version 2.6.32.60.
>
> We noticed some pretty basic issues:
>
> - With force_mld_version set to 0 (we expect "MLDv2 with MLDv1 fallback"), we saw only MLDv2 messages, the fallback to MLDv1 didn't seem to work, when we sent MLDv1 messages to the unit.
> - With force_mld_version set to 1 (we expect "MLDv1 only mode"), we also saw MLDv2 messages being generated.
>
> Can someone give a general statement about the MLD implementation maturity in kernel 2.6.32.60? Are there known bugs that would explain the above observations?

(cc'ing Hannes)

You might want to try 3.12 kernel, and if needed backport some of these:

   http://www.spinics.net/lists/netdev/msg249262.html

> We need to see whether it makes sense to put further effort in investigating/fixing any MLD related issue we see.
>
> If this is the wrong list to ask this kind of question, please point me to the correct one.
>
> Thanks in advance,
> best regards, Simon Schneider
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: MLD maturity in kernel version 2.6.32.60

[Hannes Frederic Sowa]

On Mon, Nov 18, 2013 at 01:17:28PM +0100, Simon Schneider wrote:
> in a development project, we started evaluating MLD functionality.
>  
> Our development is based on kernel version 2.6.32.60.
>  
> We noticed some pretty basic issues:
>  
> - With force_mld_version set to 0 (we expect "MLDv2 with MLDv1 fallback"), we saw only MLDv2 messages, the fallback to MLDv1 didn't seem to work, when we sent MLDv1 messages to the unit.
> - With force_mld_version set to 1 (we expect "MLDv1 only mode"), we also saw MLDv2 messages being generated.
>  
> Can someone give a general statement about the MLD implementation maturity in kernel 2.6.32.60? Are there known bugs that would explain the above observations?
> 
> We need to see whether it makes sense to put further effort in investigating/fixing any MLD related issue we see.
> 
> If this is the wrong list to ask this kind of question, please point me to the correct one.

It would be great if you could share test results with newer kernel with us.
Last time I checked we did correctly fallback to MDLv1 mode but it has been a
while.

If you come up with a specific patch from Daniel's series which fixes the
issues you are seeing, we can think about including this to stable.

There are still some issues in mld: we are currently a bit too noisy for my
taste (e.g. on re-enabling interfaces). This is a big problem for large
wireless networks e.g.

Thanks,

  Hannes

Re: MLD maturity in kernel version 2.6.32.60

[Daniel Borkmann]

On 11/18/2013 11:18 PM, Hannes Frederic Sowa wrote:
> On Mon, Nov 18, 2013 at 01:17:28PM +0100, Simon Schneider wrote:
>> in a development project, we started evaluating MLD functionality.
>>
>> Our development is based on kernel version 2.6.32.60.
>>
>> We noticed some pretty basic issues:
>>
>> - With force_mld_version set to 0 (we expect "MLDv2 with MLDv1 fallback"), we saw only MLDv2 messages, the fallback to MLDv1 didn't seem to work, when we sent MLDv1 messages to the unit.
>> - With force_mld_version set to 1 (we expect "MLDv1 only mode"), we also saw MLDv2 messages being generated.
>>
>> Can someone give a general statement about the MLD implementation maturity in kernel 2.6.32.60? Are there known bugs that would explain the above observations?
>>
>> We need to see whether it makes sense to put further effort in investigating/fixing any MLD related issue we see.
>>
>> If this is the wrong list to ask this kind of question, please point me to the correct one.
>
> It would be great if you could share test results with newer kernel with us.

Indeed, please do so, thus in case something is still missing so that we can fix it.

> Last time I checked we did correctly fallback to MDLv1 mode but it has been a
> while.

Yes, the fallback timeout should work now.

> If you come up with a specific patch from Daniel's series which fixes the
> issues you are seeing, we can think about including this to stable.
>
> There are still some issues in mld: we are currently a bit too noisy for my
> taste (e.g. on re-enabling interfaces). This is a big problem for large
> wireless networks e.g.

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.

Re: MLD maturity in kernel version 2.6.32.60

[Simon Schneider]

First of all, many thanks for your quick replies.

Unfortunately, we're only part of a big project, so decision about the 
kernel version is not really in our hands.

I.e. we're pretty much fixed on 2.6.32.60.

I had a look at the information about Daniel's patches and I also 
searched CHANGE LOGs for MLD related stuff.

But I didn't find patches/fixes that seem to address the very basic 
issues we have seen.

Would you say that even in 2.6.32.60:
- with force_mld_version=0, MLDv2 with fallback to MLDv1 should 
basically work (apart from "details" like wrong timer calculation)
- with force_mld_version=1, we should never see MLDv2 messages being 
generated?

best regards, Simon


Am 19.11.2013 01:12, schrieb Daniel Borkmann:
> On 11/18/2013 11:18 PM, Hannes Frederic Sowa wrote:
>> On Mon, Nov 18, 2013 at 01:17:28PM +0100, Simon Schneider wrote:
>>> in a development project, we started evaluating MLD functionality.
>>>
>>> Our development is based on kernel version 2.6.32.60.
>>>
>>> We noticed some pretty basic issues:
>>>
>>> - With force_mld_version set to 0 (we expect "MLDv2 with MLDv1 
>>> fallback"), we saw only MLDv2 messages, the fallback to MLDv1 didn't 
>>> seem to work, when we sent MLDv1 messages to the unit.
>>> - With force_mld_version set to 1 (we expect "MLDv1 only mode"), we 
>>> also saw MLDv2 messages being generated.
>>>
>>> Can someone give a general statement about the MLD implementation 
>>> maturity in kernel 2.6.32.60? Are there known bugs that would 
>>> explain the above observations?
>>>
>>> We need to see whether it makes sense to put further effort in 
>>> investigating/fixing any MLD related issue we see.
>>>
>>> If this is the wrong list to ask this kind of question, please point 
>>> me to the correct one.
>>
>> It would be great if you could share test results with newer kernel 
>> with us.
>
> Indeed, please do so, thus in case something is still missing so that 
> we can fix it.
>
>> Last time I checked we did correctly fallback to MDLv1 mode but it 
>> has been a
>> while.
>
> Yes, the fallback timeout should work now.
>
>> If you come up with a specific patch from Daniel's series which fixes 
>> the
>> issues you are seeing, we can think about including this to stable.
>>
>> There are still some issues in mld: we are currently a bit too noisy 
>> for my
>> taste (e.g. on re-enabling interfaces). This is a big problem for large
>> wireless networks e.g.
>
> 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.

Re: MLD maturity in kernel version 2.6.32.60

[Daniel Borkmann]

On 11/19/2013 07:11 AM, Simon Schneider wrote:
> First of all, many thanks for your quick replies.
>
> Unfortunately, we're only part of a big project, so decision about the kernel version is not really in our hands.
>
> I.e. we're pretty much fixed on 2.6.32.60.
>
> I had a look at the information about Daniel's patches and I also searched CHANGE LOGs for MLD related stuff.
> But I didn't find patches/fixes that seem to address the very basic issues we have seen.

So what's missing in 3.13? Can you elaborate on "very basic issues"?

> Would you say that even in 2.6.32.60:
> - with force_mld_version=0, MLDv2 with fallback to MLDv1 should basically work (apart from "details" like wrong timer calculation)
> - with force_mld_version=1, we should never see MLDv2 messages being generated?

 From the code in 3.10 and earlier (therefore also 2.6.32.60), it seems that even if
we'd be in v1 fallback, nothing prevents us to process a v2 message as we would do
normally at least in igmp6_event_query(), which is not correct as we apply knowledge
how to process a v2 message although we're in v1-only fallback mode.

We have the macro MLD_V1_SEEN(idev) in these versions, which results always to true,
but we shouldn't even process it further at this point in igmp6_event_query(). So,
again, I'd recommend to backport the patchset and its dependencies to your kernel,
or just try out the latest one first.

> best regards, Simon
>
>
> Am 19.11.2013 01:12, schrieb Daniel Borkmann:
>> On 11/18/2013 11:18 PM, Hannes Frederic Sowa wrote:
>>> On Mon, Nov 18, 2013 at 01:17:28PM +0100, Simon Schneider wrote:
>>>> in a development project, we started evaluating MLD functionality.
>>>>
>>>> Our development is based on kernel version 2.6.32.60.
>>>>
>>>> We noticed some pretty basic issues:
>>>>
>>>> - With force_mld_version set to 0 (we expect "MLDv2 with MLDv1 fallback"), we saw only MLDv2 messages, the fallback to MLDv1 didn't seem to work, when we sent MLDv1 messages to the unit.
>>>> - With force_mld_version set to 1 (we expect "MLDv1 only mode"), we also saw MLDv2 messages being generated.
>>>>
>>>> Can someone give a general statement about the MLD implementation maturity in kernel 2.6.32.60? Are there known bugs that would explain the above observations?
>>>>
>>>> We need to see whether it makes sense to put further effort in investigating/fixing any MLD related issue we see.
>>>>
>>>> If this is the wrong list to ask this kind of question, please point me to the correct one.
>>>
>>> It would be great if you could share test results with newer kernel with us.
>>
>> Indeed, please do so, thus in case something is still missing so that we can fix it.
>>
>>> Last time I checked we did correctly fallback to MDLv1 mode but it has been a
>>> while.
>>
>> Yes, the fallback timeout should work now.
>>
>>> If you come up with a specific patch from Daniel's series which fixes the
>>> issues you are seeing, we can think about including this to stable.
>>>
>>> There are still some issues in mld: we are currently a bit too noisy for my
>>> taste (e.g. on re-enabling interfaces). This is a big problem for large
>>> wireless networks e.g.
>>
>> 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.
>

Aw: Re: MLD maturity in kernel version 2.6.32.60

[Simon Schneider]

Hi Daniel and Hannes,
thanks for your help so far.
 
We start with IPv6 now on a different product, which already uses kernel version 3.8.4.
 
Can we expect that the existing MLD patches are already integrated in that kernel?
 
Or are there still major differences between that kernel and the latest one, regarding MLD?
 
I think we will be able to do some MLD testing on that product.
 
best regards, Simon
 

Gesendet: Dienstag, 19. November 2013 um 08:29 Uhr
Von: "Daniel Borkmann" <dborkman@redhat.com>
An: simon-schneider@gmx.net
Cc: "Hannes Frederic Sowa" <hannes@stressinduktion.org>, netdev@vger.kernel.org
Betreff: Re: MLD maturity in kernel version 2.6.32.60
On 11/19/2013 07:11 AM, Simon Schneider wrote:
> First of all, many thanks for your quick replies.
>
> Unfortunately, we're only part of a big project, so decision about the kernel version is not really in our hands.
>
> I.e. we're pretty much fixed on 2.6.32.60.
>
> I had a look at the information about Daniel's patches and I also searched CHANGE LOGs for MLD related stuff.
> But I didn't find patches/fixes that seem to address the very basic issues we have seen.

So what's missing in 3.13? Can you elaborate on "very basic issues"?

> Would you say that even in 2.6.32.60:
> - with force_mld_version=0, MLDv2 with fallback to MLDv1 should basically work (apart from "details" like wrong timer calculation)
> - with force_mld_version=1, we should never see MLDv2 messages being generated?

From the code in 3.10 and earlier (therefore also 2.6.32.60), it seems that even if
we'd be in v1 fallback, nothing prevents us to process a v2 message as we would do
normally at least in igmp6_event_query(), which is not correct as we apply knowledge
how to process a v2 message although we're in v1-only fallback mode.

We have the macro MLD_V1_SEEN(idev) in these versions, which results always to true,
but we shouldn't even process it further at this point in igmp6_event_query(). So,
again, I'd recommend to backport the patchset and its dependencies to your kernel,
or just try out the latest one first.

> best regards, Simon
>
>
> Am 19.11.2013 01:12, schrieb Daniel Borkmann:
>> On 11/18/2013 11:18 PM, Hannes Frederic Sowa wrote:
>>> On Mon, Nov 18, 2013 at 01:17:28PM +0100, Simon Schneider wrote:
>>>> in a development project, we started evaluating MLD functionality.
>>>>
>>>> Our development is based on kernel version 2.6.32.60.
>>>>
>>>> We noticed some pretty basic issues:
>>>>
>>>> - With force_mld_version set to 0 (we expect "MLDv2 with MLDv1 fallback"), we saw only MLDv2 messages, the fallback to MLDv1 didn't seem to work, when we sent MLDv1 messages to the unit.
>>>> - With force_mld_version set to 1 (we expect "MLDv1 only mode"), we also saw MLDv2 messages being generated.
>>>>
>>>> Can someone give a general statement about the MLD implementation maturity in kernel 2.6.32.60? Are there known bugs that would explain the above observations?
>>>>
>>>> We need to see whether it makes sense to put further effort in investigating/fixing any MLD related issue we see.
>>>>
>>>> If this is the wrong list to ask this kind of question, please point me to the correct one.
>>>
>>> It would be great if you could share test results with newer kernel with us.
>>
>> Indeed, please do so, thus in case something is still missing so that we can fix it.
>>
>>> Last time I checked we did correctly fallback to MDLv1 mode but it has been a
>>> while.
>>
>> Yes, the fallback timeout should work now.
>>
>>> If you come up with a specific patch from Daniel's series which fixes the
>>> issues you are seeing, we can think about including this to stable.
>>>
>>> There are still some issues in mld: we are currently a bit too noisy for my
>>> taste (e.g. on re-enabling interfaces). This is a big problem for large
>>> wireless networks e.g.
>>
>> 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.
>

Re: Re: MLD maturity in kernel version 2.6.32.60

[Hannes Frederic Sowa]

On Fri, Dec 06, 2013 at 08:40:16AM +0100, Simon Schneider wrote:
> thanks for your help so far.
>  
> We start with IPv6 now on a different product, which already uses kernel version 3.8.4.
>  
> Can we expect that the existing MLD patches are already integrated in that kernel?

Nope:
$ git describe --contains 89225d1ce6af3916bf32aecbe9d83f571a098588
v3.12-rc1~132^2~23

You will have to backport them yourself. There aren't lots of changes and they
are rather independent. So a backport should not be too complicated.

> Or are there still major differences between that kernel and the latest one, regarding MLD?

Yes, I guess so. Especially in the MLD v1<->v2 switcheroo.

Greetings,

  Hannes

Re: MLD maturity in kernel version 2.6.32.60

[Hannes Frederic Sowa]

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.

Re: MLD maturity in kernel version 2.6.32.60

[Daniel Borkmann]

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.