netdev - Re: Premature timeout for MLDv1 Host compatibility mode?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAOLNa-e0DB7Vhvv8tcSdW_JSWavpmyNt0vFYHLymh_zDaqUiMw@mail.gmail.com>
Date:	Fri, 3 Aug 2012 10:54:09 +0200
From:	Dragos Ilie <dragos.ilie@...il.com>
To:	David Stevens <dlstevens@...ibm.com>
Cc:	netdev@...r.kernel.org, netdev-owner@...r.kernel.org
Subject: Re: Premature timeout for MLDv1 Host compatibility mode?

Hi David,

I have been thinking about how to address your concerns about the
MLDv1-mode timeout. Unfortunately, I think by doing that we would stop
being compliant with RFC 3810 on the following points:

a) Section 5.1.9 states that the QQIC field is meant for other
multicast routers that are not the current querier. I "grep-ed" after
mld2q_qqic in the entire kernel source tree and it is not being used
at all. I take this as a sign that the field is not to be interpreted
by listeners. Of course, that does not mean we cannot use it, but see
b) below

b) Section 8.3.1 says that "if an MLDv1 router is present on the link,
the Querier MUST use the lowest  version of MLD present on the
network". Also, "if an MLDv1 router is present on the link, the system
administrator must explicitly configure all MLDv2 routers to act in
MLDv1 mode". It seems to me that these statements together preclude a
scenario with MLDv1 and MLDv2 routers mixed together on the same link,
unless all routers speak MLDv1.

The current implementation for MLDv1 compatibility mode works very
badly. The listeners fail most of the time to join the groups on the
MLDv1 server. I suggest  that my patch sent earlier this week is
pushed upstream, unless there are concerns that it will make things
worse than they are today. This will improve the behavior of MLDv2
listeners with MLDv1 routers and keep us compliant with the RFC. What
do you think?

On Thu, Aug 2, 2012 at 4:25 PM, David Stevens <dlstevens@...ibm.com> wrote:
> netdev-owner@...r.kernel.org wrote on 08/02/2012 10:03:24 AM:
>
>> > The QQIC would come from v2 queries prior to the v1 query that
>> > triggered us to switch to v1. But, see below.
>>
>> How about the scenario where you have only MLDv1 queriers? There will
>> be no prior v2 query
>
>         Yes, this is why I suggested initializing it to the
> default of 125. If we actually saw v2 queries with different
> intervals, we'd adjust longer or shorter, but use the default
> only when we had no queries to update it.
>
>                                                 +-DLS
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html