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

Toerless Eckert <eckert@cisco.com> Fri, 06 June 2003 20:22 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 QAA11253 for <ssm-archive@lists.ietf.org>; Fri, 6 Jun 2003 16:22:33 -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 h56KLeB26472; Fri, 6 Jun 2003 16:21:40 -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 h56KKBB26404 for <ssm@optimus.ietf.org>; Fri, 6 Jun 2003 16:20:11 -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 QAA11220 for <ssm@ietf.org>; Fri, 6 Jun 2003 16:20:08 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ONfB-00067q-00 for ssm@ietf.org; Fri, 06 Jun 2003 16:18:13 -0400
Received: from sj-core-5.cisco.com ([171.71.177.238]) by ietf-mx with esmtp (Exim 4.12) id 19ONfA-00067B-00 for ssm@ietf.org; Fri, 06 Jun 2003 16:18:12 -0400
Received: from cisco.com (cypher.cisco.com [171.69.11.143]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h56KJcjc014424; Fri, 6 Jun 2003 13:19:38 -0700 (PDT)
Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id NAA10460; Fri, 6 Jun 2003 13:19:36 -0700 (PDT)
Date: Fri, 6 Jun 2003 13:19:36 -0700
From: Toerless Eckert <eckert@cisco.com>
To: Jon Zeeff <jzeeff@internet2.edu>
Cc: Bill Fenner <fenner@research.att.com>, ssm@ietf.org
Subject: Re: [ssm] Document Action: An Overview of Source-Specific Multicast(SSM) Deployment to Informational
Message-ID: <20030606201936.GI16697@cypher.cisco.com>
References: <200306040550.h545oaD08547@windsor.research.att.com> <5.1.0.14.2.20030606144813.01d03370@mail.internet2.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5.1.0.14.2.20030606144813.01d03370@mail.internet2.edu>
User-Agent: Mutt/1.4i
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>

On Fri, Jun 06, 2003 at 02:52:33PM -0400, Jon Zeeff wrote:
> 
> Where is a good source of information on the details of migrating to SSM on 
> real-world LANs?

You may have found a good place already.

> I've seen switches that crash when they see a IGMPv3 packet.  Apparently XP 
> doesn't send
> IGMPv3 packets when it sees certain traffic on an existing LAN.  Apparently 
> routers
> stop using IGMPv3 when they see IGMPv2 traffic (sounds an easy inadvertent 
> DOS attack).

>From my experience, windows XP does send IGMPv2 reports if it sees IGMPv2 queries.
It MUST do this according to the IGMPv3 spec.  Wether or not other hosts send
IGMPv2 membership reports does not seem to change windows XP behaviors if i
remember it correctly. It is allowed to do this according to the IGMPv3 spec,
and this certainly is the best and luckily also the easiest option to implement
on the host side.

> Please tell me I'm wrong and that a gradual migration from ASM to SSM is 
> easy....

Unfortunately, this was never an argument in the design of IGMPv3. SSM itself
was never an argument for the design of IGMPv3. IGMPv3 started out as being
source filtering for ASM at a time when SSM was not even invented. Then it 
lingered around quite some time (years?) in the IETF, and then people started
to see that one could do a cool thing called SSM by leveraging IGMPv3. That's
when more work was put into pushing IGMPv3 through the IETF. Unfortunately is
was only pushing, it was never really any redesign for the benefit of SSM.
We already had a hard time to get certain protocol details out of IGMPv3
that were extremely detremental to SSM (hosts announcing EXCLUDE mode if the
source list became too long and the like).

So, as far as easy gradual migration to SSM with DoS attack prevention is concerned,
this has almost completely been ignored by the IETF process. The best i can offer
you is to recommend talking to your vendors of choice and ask them what their
solution offers in support of such operational requirements. There is quite
a bit of leeway in what implementations can do, specifically in the IGMP Snooping
arena and that's where there might be one or the other competitive differentiation
which is maybe not best discussed on an open mailing list.

Cheers
	Toerless
_______________________________________________
ssm mailing list
ssm@ietf.org
https://www1.ietf.org/mailman/listinfo/ssm