Re: [ssm] Document Action: An Overview of Source-Specific Multicast(SSM) Deployment to Informational
Hitoshi Asaeda <Hitoshi.Asaeda@sophia.inria.fr> Tue, 10 June 2003 15:32 UTC
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05631 for <ssm-archive@lists.ietf.org>; Tue, 10 Jun 2003 11:32:19 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AFVLB31723; Tue, 10 Jun 2003 11:31:21 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h5AFOGB31311 for <ssm@optimus.ietf.org>; Tue, 10 Jun 2003 11:24:16 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05314 for <ssm@ietf.org>; Tue, 10 Jun 2003 11:24:14 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Pkwu-0007Nh-00 for ssm@ietf.org; Tue, 10 Jun 2003 11:22:12 -0400
Received: from sophia.inria.fr ([138.96.64.20]) by ietf-mx with esmtp (Exim 4.12) id 19Pkwt-0007Nb-00 for ssm@ietf.org; Tue, 10 Jun 2003 11:22:11 -0400
Received: from localhost (odie.inria.fr [138.96.88.52]) by sophia.inria.fr (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: <20030610.172332.128597013.Hitoshi.Asaeda@sophia.inria.fr>
To: eckert@cisco.com
Cc: ssm@ietf.org
Subject: Re: [ssm] Document Action: An Overview of Source-Specific Multicast(SSM) Deployment to Informational
From: Hitoshi Asaeda <Hitoshi.Asaeda@sophia.inria.fr>
In-Reply-To: <20030610144558.GL23388@cypher.cisco.com>
References: <5.1.0.14.2.20030610085539.023c1740@mail.internet2.edu> <20030610.155931.117536967.Hitoshi.Asaeda@sophia.inria.fr> <20030610144558.GL23388@cypher.cisco.com>
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
Sender: ssm-admin@ietf.org
Errors-To: ssm-admin@ietf.org
X-BeenThere: ssm@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ssm>, <mailto:ssm-request@ietf.org?subject=unsubscribe>
List-Id: Source-Specific Multicast <ssm.ietf.org>
List-Post: <mailto:ssm@ietf.org>
List-Help: <mailto:ssm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ssm>, <mailto:ssm-request@ietf.org?subject=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 ? No. Thanks. -- Hitoshi Asaeda _______________________________________________ ssm mailing list ssm@ietf.org https://www1.ietf.org/mailman/listinfo/ssm
- [ssm] Document Action: An Overview of Source-Spec… Bill Fenner
- Re: [ssm] Document Action: An Overview of Source-… Jon Zeeff
- Re: [ssm] Document Action: An Overview of Source-… Toerless Eckert
- Re: [ssm] Document Action: An Overview of Source-… Jon Zeeff
- Re: [ssm] Document Action: An Overview of Source-… Hitoshi Asaeda
- Re: [ssm] Document Action: An Overview of Source-… Toerless Eckert
- Re: [ssm] Document Action: An Overview of Source-… Toerless Eckert
- Re: [ssm] Document Action: An Overview of Source-… Hitoshi Asaeda
- Re: [ssm] Document Action: An Overview of Source-… Toerless Eckert
- Re: [ssm] Document Action: An Overview of Source-… Hitoshi Asaeda
- Re: Re: [ssm] Document Action: An Overview of Sou… Hugh Holbrook
- Re: [ssm] Document Action: An Overview of Source-… Hitoshi Asaeda
- Re: [ssm] Document Action: An Overview of Source-… Jean-Jacques Pansiot