From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Borkmann Subject: Re: MLD maturity in kernel version 2.6.32.60 Date: Thu, 21 Nov 2013 11:16:04 +0100 Message-ID: <528DDD64.3020601@redhat.com> References: <20131118221850.GO16541@order.stressinduktion.org> <528AACF4.1090302@redhat.com> <20131121040416.GA4347@order.stressinduktion.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: netdev@vger.kernel.org, Simon Schneider To: Hannes Frederic Sowa Return-path: Received: from mx1.redhat.com ([209.132.183.28]:21099 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750860Ab3KUKQM (ORCPT ); Thu, 21 Nov 2013 05:16:12 -0500 In-Reply-To: <20131121040416.GA4347@order.stressinduktion.org> Sender: netdev-owner@vger.kernel.org List-ID: 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.