Re: [ssm] Document Action: An Overview of Source-Specific Multicast(SSM) Deployment to Informational

Hitoshi Asaeda <> Tue, 10 June 2003 15:32 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id LAA05631 for <>; Tue, 10 Jun 2003 11:32:19 -0400 (EDT)
Received: from (localhost.localdomain []) by (8.11.6/8.11.6) with ESMTP id h5AFVLB31723; Tue, 10 Jun 2003 11:31:21 -0400
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id h5AFOGB31311 for <>; Tue, 10 Jun 2003 11:24:16 -0400
Received: from ietf-mx ( []) by (8.9.1a/8.9.1a) with ESMTP id LAA05314 for <>; Tue, 10 Jun 2003 11:24:14 -0400 (EDT)
Received: from ietf-mx ([]) by ietf-mx with esmtp (Exim 4.12) id 19Pkwu-0007Nh-00 for; Tue, 10 Jun 2003 11:22:12 -0400
Received: from ([]) by ietf-mx with esmtp (Exim 4.12) id 19Pkwt-0007Nb-00 for; Tue, 10 Jun 2003 11:22:11 -0400
Received: from localhost ( []) by (8.12.8/8.12.5) with ESMTP id h5AFNXvK003176; Tue, 10 Jun 2003 17:23:33 +0200
Date: Tue, 10 Jun 2003 17:23:32 +0200
Message-Id: <>
Subject: Re: [ssm] Document Action: An Overview of Source-Specific Multicast(SSM) Deployment to Informational
From: Hitoshi Asaeda <>
In-Reply-To: <>
References: <> <> <>
X-Mailer: Mew version 2.2rc1 on Emacs 21.1 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <>, <>
List-Id: Source-Specific Multicast <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: 7bit

> Ok, so in MLD i need not only start to send MLDv1 reports, i also have to
> have a smaller IP address to win and become the querier ? How much
> does this effectively buy me ?

Maybe I don't understand your question.. but, there is no change about
querier selection. (What is the relation to my last comment?)

> > 	"A forged Version 1 Query message will put MLDv2 listeners on
> > 	 that link in MLDv1 Host Compatibility Mode.  This scenario
> > 	 can be avoided by providing MLDv2 hosts with a configuration
> > 	 option to ignore Version 1 messages completely."
> Sure, such configuration options will be all over us and make deployment
> even more complex. You can pretty much figure that only the default
> behaviour will be what 90% of people will have installed. 

I prefer to have an option to fix the problem rather than close my
eyes, even though it may make some additional complexity. (But it's
really complex?)

Anyway, in a README file of IGMPv3 imple., I specify as follws:
	After this static configuration is done, any old IGMP Query
	message doesn't affect to change the compatibility mode.
	Remember this is useful only when correct upstream router(s)
	must be IGMPv3 capable and you want to filter out or ignore
	some bogus or unneeded old version's Report and Query messages
	transfered by irregular nodes. This configuration affects all
	interfaces of the box.
	Note that this configuration is not mentioned in a spec and
	turned off as the kernel's default value.

I've never said host compat is *always* wrong. But we may need to
bypass this automatic mode change *for some cases*. And at this
moment, I don't have other good idea to bypass it.
Or, do you have another solution to bypass the DoS Jon Zeeff mentioned?
Or, ignoring the problem is good for the deployment?

> > FYI, my IGMPv3/MLDv2 implementations (incl. KAME) support them, anyway.
> Is it on by default ? 


Hitoshi Asaeda
ssm mailing list