Hi Indran= il,

Why the Query coming f= rom VLAN-A has to be forwarded to VLAN-B?

In general switch should forward the Query packets to all t= he ports in same VLAN(VLAN-A). Hosts receiving the Query can reply to the q= uery even the source address of the Query is in different subnet.

Is there anything I am missing in y= our reply???

Thanks

B S Reddy

From: magma-bounces@ietf.org [mailto:magma-bounces@ietf.org] = On Behalf Of Indranil Bhattacharya
Sent: Wednesday, Octobe= r 12, 2011 2:06 PM
To: Kunal Shah
Cc: magma@ietf.orgSubject: Re: [magma] Question about IGMP host implementation

Hi Kunal,

= ;

&nb= sp; Yes it should. The scenario t= hat I have in mind is a switch whose mrouter interface is in vlanA and igmp= joins are received on an interface in vlanB. In this case, query coming fr= om vlanA(different subnet) has to be answered by hosts in vlanB.=

Thanks,

Indranil

On Wed, Oct 12, 2011 at 6:08 AM, Kunal Shah <kunal.shah@ericsson.com> wrote:

Hi all,

&= nbsp;

Can an IGMPv2 host respon= d to a general query originated from a subnet other then its own?? RFC 2236= states:

""query received" occurs when the host= receives either a valid
     General Membership Que= ry message, or a valid Group-Specific
     Membershi= p Query message. To be valid, the Query message must be
&nbs= p;   at least 8 octets long, and have a correct IGMP checksum.&nb= sp; The
     group address in the IGMP header must e= ither be zero (a General
     Query) or a valid mult= icast group address (a Group-Specific Query)"

There= is no requirement for the source address to be on the same subnet as the h= ost.

Thanks,

Kunal

_______________________________________________
magma mailing list
<= a href=3D"mailto:magma@ietf.org">magma@ietf.org
https://www.ietf.org/= mailman/listinfo/magma

&n= bsp;

= --_000_23E658492CE48649B5B5168EBC60387842DA686A76GVW1101EXCame_-- From bharat_joshi@infosys.com Wed Oct 12 04:24:30 2011 Return-Path: X-Original-To: magma@ietfa.amsl.com Delivered-To: magma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D48121F8C4C for ; Wed, 12 Oct 2011 04:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3uAEgJZPryo for ; Wed, 12 Oct 2011 04:24:29 -0700 (PDT) Received: from kecgate06.infosys.com (kecgate06.infosys.com [122.98.14.33]) by ietfa.amsl.com (Postfix) with ESMTP id 1334621F8C5F for ; Wed, 12 Oct 2011 04:24:28 -0700 (PDT) X-TM-IMSS-Message-ID: Received: from blrkechub01.ad.infosys.com ([10.66.236.41]) by infosys.com ([122.98.14.33]) with ESMTP (TREND IMSS SMTP Service 7.1) id dc2aac4e000510c2 ; Wed, 12 Oct 2011 16:56:10 +0530 Received: from blrkechub12.ad.infosys.com (10.66.236.47) by blrkechub01.ad.infosys.com (10.66.236.41) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 12 Oct 2011 16:53:24 +0530 Received: from BLRKECMBX02.ad.infosys.com ([10.66.236.22]) by blrkechub12.ad.infosys.com ([10.66.236.47]) with mapi; Wed, 12 Oct 2011 16:53:24 +0530 From: Bharat Joshi To: Kunal Shah , "magma@ietf.org" Date: Wed, 12 Oct 2011 16:49:55 +0530 Thread-Topic: Question about IGMP host implementation Thread-Index: AcyId0SCeinZjfcnSnCOOiiZpocqFgAWZnLt Message-ID: <31D55C4D55BEED48A4459EB64567589A1186EB24E9@BLRKECMBX02.ad.infosys.com> References: <4FD1E7CD248BF84F86BD4814EDDDBCC151401F3936@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <4FD1E7CD248BF84F86BD4814EDDDBCC151401F3936@EUSAACMS0703.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [magma] Question about IGMP host implementation X-BeenThere: magma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast and Anycast Group Membership List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 11:24:30 -0000 Hi=20Kunal, =20=20=20=20=20=20=20=20I=20think=20to=20keep=20the=20security=20tight,= =20it=20is=20better=20to=20not=20respond=20to=20queries=20received=20from= =20a=20source=20address=20which=20does=20not=20fall=20on=20a=20subnet=20o= n=20that=20interface.=20Please=20note=20that=20this=20should=20be=20done= =20only=20broadcast=20interfaces.=20It=20may=20not=20work=20on=20point-to= -point=20links. =20=20=20=20=20=20=20=20If=20you=20look=20at=20the=20security=20considera= tion=20in=20RFC=202236,=20it=20is=20mentioned=20that=20for=20reports,=20t= he=20above=20check=20should=20be=20done. Regards, Bharat ________________________________________ From:=20magma-bounces@ietf.org=20[magma-bounces@ietf.org]=20On=20Behalf= =20Of=20Kunal=20Shah=20[kunal.shah@ericsson.com] Sent:=20Wednesday,=20October=2012,=202011=206:08=20AM To:=20magma@ietf.org Subject:=20[magma]=20Question=20about=20IGMP=20host=20implementation Hi=20all, Can=20an=20IGMPv2=20host=20respond=20to=20a=20general=20query=20originate= d=20from=20a=20subnet=20other=20then=20its=20own??=20RFC=202236=20states: ""query=20received"=20occurs=20when=20the=20host=20receives=20either=20a= =20valid =20=20=20=20=20General=20Membership=20Query=20message,=20or=20a=20valid= =20Group-Specific =20=20=20=20=20Membership=20Query=20message.=20=20To=20be=20valid,=20the= =20Query=20message=20must=20be =20=20=20=20=20at=20least=208=20octets=20long,=20and=20have=20a=20correct= =20IGMP=20checksum.=20=20The =20=20=20=20=20group=20address=20in=20the=20IGMP=20header=20must=20either= =20be=20zero=20(a=20General =20=20=20=20=20Query)=20or=20a=20valid=20multicast=20group=20address=20(a= =20Group-Specific=20Query)" There=20is=20no=20requirement=20for=20the=20source=20address=20to=20be=20= on=20the=20same=20subnet=20as=20the=20host. Thanks, Kunal ****************=20CAUTION=20-=20Disclaimer=20***************** This=20e-mail=20contains=20PRIVILEGED=20AND=20CONFIDENTIAL=20INFORMATION= =20intended=20solely=20 for=20the=20use=20of=20the=20addressee(s).=20If=20you=20are=20not=20the= =20intended=20recipient,=20please=20 notify=20the=20sender=20by=20e-mail=20and=20delete=20the=20original=20mes= sage.=20Further,=20you=20are=20not=20 to=20copy,=20disclose,=20or=20distribute=20this=20e-mail=20or=20its=20con= tents=20to=20any=20other=20person=20and=20 any=20such=20actions=20are=20unlawful.=20This=20e-mail=20may=20contain=20= viruses.=20Infosys=20has=20taken=20 every=20reasonable=20precaution=20to=20minimize=20this=20risk,=20but=20is= =20not=20liable=20for=20any=20damage=20 you=20may=20sustain=20as=20a=20result=20of=20any=20virus=20in=20this=20e-= mail.=20You=20should=20carry=20out=20your=20 own=20virus=20checks=20before=20opening=20the=20e-mail=20or=20attachment.= =20Infosys=20reserves=20the=20 right=20to=20monitor=20and=20review=20the=20content=20of=20all=20messages= =20sent=20to=20or=20from=20this=20e-mail=20 address.=20Messages=20sent=20to=20or=20from=20this=20e-mail=20address=20m= ay=20be=20stored=20on=20the=20 Infosys=20e-mail=20system. ***INFOSYS********=20End=20of=20Disclaimer=20********INFOSYS*** From bharat_joshi@infosys.com Wed Oct 12 04:25:38 2011 Return-Path: X-Original-To: magma@ietfa.amsl.com Delivered-To: magma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 727E821F84DB for ; Wed, 12 Oct 2011 04:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNChQ7ntHcER for ; Wed, 12 Oct 2011 04:25:38 -0700 (PDT) Received: from KECGATE03.infosys.com (kecgate03.infosys.com [122.98.10.31]) by ietfa.amsl.com (Postfix) with ESMTP id 367FD21F84D2 for ; Wed, 12 Oct 2011 04:25:36 -0700 (PDT) X-TM-IMSS-Message-ID: Received: from blrkechub03.ad.infosys.com ([10.66.236.43]) by infosys.com ([122.98.10.31]) with ESMTP (TREND IMSS SMTP Service 7.1) id dc35c33c00040064 ; Wed, 12 Oct 2011 16:54:27 +0530 Received: from BLRKECMBX02.ad.infosys.com ([10.66.236.22]) by blrkechub03.ad.infosys.com ([10.66.236.43]) with mapi; Wed, 12 Oct 2011 16:54:36 +0530 From: Bharat Joshi To: Indranil Bhattacharya , Kunal Shah Date: Wed, 12 Oct 2011 16:53:27 +0530 Thread-Topic: [magma] Question about IGMP host implementation Thread-Index: AcyIudBczRqs4ScsTHG0vVMrRn63dwAF4xuv Message-ID: <31D55C4D55BEED48A4459EB64567589A1186EB24EA@BLRKECMBX02.ad.infosys.com> References: <4FD1E7CD248BF84F86BD4814EDDDBCC151401F3936@EUSAACMS0703.eamcs.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "magma@ietf.org" Subject: Re: [magma] Question about IGMP host implementation X-BeenThere: magma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast and Anycast Group Membership List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 11:25:38 -0000 How=20is=20a=20switch=20has=20two=20different=20subnets=20on=20its=20two= =20ports?=20Typically=20switch=20divides=20the=20broadcast=20domain.=20Ri= ght? Regards, Bharat ________________________________________ From:=20magma-bounces@ietf.org=20[magma-bounces@ietf.org]=20On=20Behalf= =20Of=20Indranil=20Bhattacharya=20[myselfindranil@gmail.com] Sent:=20Wednesday,=20October=2012,=202011=202:05=20PM To:=20Kunal=20Shah Cc:=20magma@ietf.org Subject:=20Re:=20[magma]=20Question=20about=20IGMP=20host=20implementatio= n Hi=20Kunal, =20=20=20=20=20=20=20=20=20=20=20=20=20Yes=20it=20should.=20The=20scenari= o=20that=20I=20have=20in=20mind=20is=20a=20switch=20whose=20mrouter=20int= erface=20is=20in=20vlanA=20and=20igmp=20joins=20are=20received=20on=20an= =20interface=20in=20vlanB.=20In=20this=20case,=20query=20coming=20from=20= vlanA(different=20subnet)=20has=20to=20be=20answered=20by=20hosts=20in=20= vlanB. Thanks, Indranil On=20Wed,=20Oct=2012,=202011=20at=206:08=20AM,=20Kunal=20Shah=20>=20wrote: Hi=20all, Can=20an=20IGMPv2=20host=20respond=20to=20a=20general=20query=20originate= d=20from=20a=20subnet=20other=20then=20its=20own??=20RFC=202236=20states: ""query=20received"=20occurs=20when=20the=20host=20receives=20either=20a= =20valid =20=20=20=20=20General=20Membership=20Query=20message,=20or=20a=20valid= =20Group-Specific =20=20=20=20=20Membership=20Query=20message.=20=20To=20be=20valid,=20the= =20Query=20message=20must=20be =20=20=20=20=20at=20least=208=20octets=20long,=20and=20have=20a=20correct= =20IGMP=20checksum.=20=20The =20=20=20=20=20group=20address=20in=20the=20IGMP=20header=20must=20either= =20be=20zero=20(a=20General =20=20=20=20=20Query)=20or=20a=20valid=20multicast=20group=20address=20(a= =20Group-Specific=20Query)" There=20is=20no=20requirement=20for=20the=20source=20address=20to=20be=20= on=20the=20same=20subnet=20as=20the=20host. Thanks, Kunal _______________________________________________ magma=20mailing=20list magma@ietf.org https://www.ietf.org/mailman/listinfo/magma ****************=20CAUTION=20-=20Disclaimer=20***************** This=20e-mail=20contains=20PRIVILEGED=20AND=20CONFIDENTIAL=20INFORMATION= =20intended=20solely=20 for=20the=20use=20of=20the=20addressee(s).=20If=20you=20are=20not=20the= =20intended=20recipient,=20please=20 notify=20the=20sender=20by=20e-mail=20and=20delete=20the=20original=20mes= sage.=20Further,=20you=20are=20not=20 to=20copy,=20disclose,=20or=20distribute=20this=20e-mail=20or=20its=20con= tents=20to=20any=20other=20person=20and=20 any=20such=20actions=20are=20unlawful.=20This=20e-mail=20may=20contain=20= viruses.=20Infosys=20has=20taken=20 every=20reasonable=20precaution=20to=20minimize=20this=20risk,=20but=20is= =20not=20liable=20for=20any=20damage=20 you=20may=20sustain=20as=20a=20result=20of=20any=20virus=20in=20this=20e-= mail.=20You=20should=20carry=20out=20your=20 own=20virus=20checks=20before=20opening=20the=20e-mail=20or=20attachment.= =20Infosys=20reserves=20the=20 right=20to=20monitor=20and=20review=20the=20content=20of=20all=20messages= =20sent=20to=20or=20from=20this=20e-mail=20 address.=20Messages=20sent=20to=20or=20from=20this=20e-mail=20address=20m= ay=20be=20stored=20on=20the=20 Infosys=20e-mail=20system. ***INFOSYS********=20End=20of=20Disclaimer=20********INFOSYS*** From myselfindranil@gmail.com Wed Oct 12 07:24:28 2011 Return-Path: X-Original-To: magma@ietfa.amsl.com Delivered-To: magma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F14321F8C7D for ; Wed, 12 Oct 2011 07:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id djuv8gwCdBjg for ; Wed, 12 Oct 2011 07:24:27 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3151E21F8C6E for ; Wed, 12 Oct 2011 07:24:27 -0700 (PDT) Received: by wwf22 with SMTP id 22so75147wwf.13 for ; Wed, 12 Oct 2011 07:24:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4uj9mrY1R6x/O5GQrPTu1nXG4/xv2o9uJ2u0YQfzg8A=; b=W5e1rofKDIoumgdjhNNpTj7BXXbSHrErFgrTTmBaH4QDH2h8SyYnOt/CYug7o21KkG V/XnKO3YaTE0dz8/UkSuO8m2yKarR8JJetJRZAJWY28I/myp1+ZsYY1ILc3IlTdbsjQ1 sIg1sqKyZOE/njbE/fDo28HG9aKWm6f9wo4T0= MIME-Version: 1.0 Received: by 10.216.24.2 with SMTP id w2mr7961265wew.49.1318429466235; Wed, 12 Oct 2011 07:24:26 -0700 (PDT) Received: by 10.216.39.80 with HTTP; Wed, 12 Oct 2011 07:24:26 -0700 (PDT) In-Reply-To: <23E658492CE48649B5B5168EBC60387842DA686A76@GVW1101EXC.americas.hpqcorp.net> References: <4FD1E7CD248BF84F86BD4814EDDDBCC151401F3936@EUSAACMS0703.eamcs.ericsson.se> <23E658492CE48649B5B5168EBC60387842DA686A76@GVW1101EXC.americas.hpqcorp.net> Date: Wed, 12 Oct 2011 19:54:26 +0530 Message-ID: From: Indranil Bhattacharya To: "Beeram, Suresh KumarReddy" Content-Type: multipart/alternative; boundary=0016e642db94ff13ef04af1ac7f0 Cc: "magma@ietf.org" Subject: Re: [magma] Question about IGMP host implementation X-BeenThere: magma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast and Anycast Group Membership List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 14:24:28 -0000 --0016e642db94ff13ef04af1ac7f0 Content-Type: text/plain; charset=ISO-8859-1 Hi Suresh, VLANA(10.x.x.x) VLANB(20.x.x.x) RTR-------------------------------sw------------------------------HOST. All the queries received on VLANA will be forwared to VLANB. When mcast data is received on vlanA those will also be forwarded on vlanB after some header rewrite. Please let me know if this answers your question. Thanks, Indranil On Wed, Oct 12, 2011 at 4:16 PM, Beeram, Suresh KumarReddy wrote: > Hi Indranil,**** > > Why the Query coming from VLAN-A has to be forwarded to VLAN-B?**** > > In general switch should forward the Query packets to all the ports in same > VLAN(VLAN-A). Hosts receiving the Query can reply to the query even the > source address of the Query is in different subnet.**** > > Is there anything I am missing in your reply???**** > > Thanks**** > > B S Reddy**** > > ** ** > > *From:* magma-bounces@ietf.org [mailto:magma-bounces@ietf.org] *On Behalf > Of *Indranil Bhattacharya > *Sent:* Wednesday, October 12, 2011 2:06 PM > *To:* Kunal Shah > *Cc:* magma@ietf.org > *Subject:* Re: [magma] Question about IGMP host implementation**** > > ** ** > > Hi Kunal,**** > > **** > > Yes it should. The scenario that I have in mind is a switch > whose mrouter interface is in vlanA and igmp joins are received on an > interface in vlanB. In this case, query coming from vlanA(different subnet) > has to be answered by hosts in vlanB.**** > > **** > > Thanks,**** > > Indranil**** > > On Wed, Oct 12, 2011 at 6:08 AM, Kunal Shah > wrote:**** > > Hi all,**** > > **** > > Can an IGMPv2 host respond to a general query originated from a subnet > other then its own?? RFC 2236 states: **** > > **** > > ""query received" occurs when the host receives either a valid > General Membership Query message, or a valid Group-Specific > Membership Query message. To be valid, the Query message must be > at least 8 octets long, and have a correct IGMP checksum. The > group address in the IGMP header must either be zero (a General > Query) or a valid multicast group address (a Group-Specific Query)" * > *** > > **** > > There is no requirement for the source address to be on the same subnet as > the host.**** > > **** > > Thanks,**** > > Kunal**** > > **** > > > _______________________________________________ > magma mailing list > magma@ietf.org > https://www.ietf.org/mailman/listinfo/magma**** > > ** ** > --0016e642db94ff13ef04af1ac7f0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Suresh,

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 VLANA(10.x.x.x)=A0=A0=A0=A0=A0=A0=A0=A0=A0VLANB(20.x.x.x)

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 RTR------------------------= -------sw------------------------------HOST.

=A0

All the queries received on VLANA will be forwared to VLANB. When mcas= t data is received on vlanA those will also be forwarded on vlanB after som= e header rewrite. Please let me know if this answers your question.

Thanks,

Indranil

On Wed, Oct 12, 2011 at 4:16 PM, Beeram, Suresh = KumarReddy <sbeeram@= hp.com> wrote:

Hi I= ndranil,

Why = the Query coming from VLAN-A has to be forwarded to VLAN-B?

In g= eneral switch should forward the Query packets to all the ports in same VLA= N(VLAN-A). Hosts receiving the Query can reply to the query even the source= address of the Query is in different subnet.

Is t= here anything I am missing in your reply???

Than= ks

B S= =A0 Reddy

<= /u>=A0

From:<= span style=3D"FONT-SIZE: 10pt"> magma-bounces@ietf.org [mailto:magma-bounces@ietf.org] On Beha= lf Of Indranil Bhattacharya
Sent: Wednesday, October 12, 2011 2:06 PM
To: Kunal ShahCc: magma@ietf= .org
Subject: Re: [magma] Question about IGMP host implementa= tion

=A0

Hi Kunal,

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Yes it should. = The scenario that I have in mind is a switch whose mrouter interface is in = vlanA and igmp joins are received on an interface in vlanB. In this case, q= uery coming from vlanA(different subnet) has to be answered by hosts in vla= nB.

=A0

Thanks,

Indranil=

On Wed, Oct 12, 2011 at 6:08 AM, Kunal Shah <kunal.shah@ericsso= n.com> wrote:

Hi all,

=A0

Can an IGMPv2 host r= espond to a general query originated from a subnet other then its own?? RFC= 2236 states:

=A0

""query re= ceived" occurs when the host receives either a valid
=A0=A0=A0=A0 G= eneral Membership Query message, or a valid Group-Specific
=A0=A0=A0=A0 Membership Query message.=A0 To be valid, the Query message mu= st be
=A0=A0=A0=A0 at least 8 octets long, and have a correct IGMP check= sum.=A0 The
=A0=A0=A0=A0 group address in the IGMP header must either be= zero (a General
=A0=A0=A0=A0 Query) or a valid multicast group address = (a Group-Specific Query)"

=A0

There is no requirem= ent for the source address to be on the same subnet as the host.<= /u>

=A0

Thanks,

Kunal<= /span>

=A0

__________________= _____________________________
magma mailing list
magma@ietf.org
https://www.ietf.org/m= ailman/listinfo/magma

=A0

--0016e642db94ff13ef04af1ac7f0-- From myselfindranil@gmail.com Wed Oct 12 07:25:17 2011 Return-Path: X-Original-To: magma@ietfa.amsl.com Delivered-To: magma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF95E21F8CA0 for ; Wed, 12 Oct 2011 07:25:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ZSaUMnEhU6j for ; Wed, 12 Oct 2011 07:25:17 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 47DF721F8C81 for ; Wed, 12 Oct 2011 07:25:15 -0700 (PDT) Received: by wwf22 with SMTP id 22so76056wwf.13 for ; Wed, 12 Oct 2011 07:25:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lG5thXkDH5KZ3hkmkk2Z0DpbwyAJ+HdAhSdqQt41A+M=; b=Mh0MTfIv2dPD2x2nw2yBf9a8QMxSjRpy7WhYeoeO8Bk3QyIEBN3J1BfOuusviMlri9 478MA57m0W0FJPuBVpiS3l1o5PohfxpgLbi0piwfz/HiYmPxLcJKVHhTECxjNIITQUa3 BZCEM5VwGRNcarovHwAVuO3qMs3M3a6QKsfoc= MIME-Version: 1.0 Received: by 10.216.14.83 with SMTP id c61mr2667152wec.4.1318429514314; Wed, 12 Oct 2011 07:25:14 -0700 (PDT) Received: by 10.216.39.80 with HTTP; Wed, 12 Oct 2011 07:25:14 -0700 (PDT) In-Reply-To: <31D55C4D55BEED48A4459EB64567589A1186EB24EA@BLRKECMBX02.ad.infosys.com> References: <4FD1E7CD248BF84F86BD4814EDDDBCC151401F3936@EUSAACMS0703.eamcs.ericsson.se> <31D55C4D55BEED48A4459EB64567589A1186EB24EA@BLRKECMBX02.ad.infosys.com> Date: Wed, 12 Oct 2011 19:55:14 +0530 Message-ID: From: Indranil Bhattacharya To: Bharat Joshi Content-Type: multipart/alternative; boundary=001485f6d9fedcb3ef04af1aca0a Cc: "magma@ietf.org" Subject: Re: [magma] Question about IGMP host implementation X-BeenThere: magma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast and Anycast Group Membership List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 14:25:17 -0000 --001485f6d9fedcb3ef04af1aca0a Content-Type: text/plain; charset=ISO-8859-1 Hi Bharat, I was thinking on the line of cat3k switches where we can configure SVIs. Thanks, Indranil On Wed, Oct 12, 2011 at 4:53 PM, Bharat Joshi wrote: > How is a switch has two different subnets on its two ports? Typically > switch divides the broadcast domain. Right? > > Regards, > Bharat > ________________________________________ > From: magma-bounces@ietf.org [magma-bounces@ietf.org] On Behalf Of > Indranil Bhattacharya [myselfindranil@gmail.com] > Sent: Wednesday, October 12, 2011 2:05 PM > To: Kunal Shah > Cc: magma@ietf.org > Subject: Re: [magma] Question about IGMP host implementation > > Hi Kunal, > > Yes it should. The scenario that I have in mind is a switch > whose mrouter interface is in vlanA and igmp joins are received on an > interface in vlanB. In this case, query coming from vlanA(different subnet) > has to be answered by hosts in vlanB. > > Thanks, > Indranil > > On Wed, Oct 12, 2011 at 6:08 AM, Kunal Shah > wrote: > Hi all, > > Can an IGMPv2 host respond to a general query originated from a subnet > other then its own?? RFC 2236 states: > > ""query received" occurs when the host receives either a valid > General Membership Query message, or a valid Group-Specific > Membership Query message. To be valid, the Query message must be > at least 8 octets long, and have a correct IGMP checksum. The > group address in the IGMP header must either be zero (a General > Query) or a valid multicast group address (a Group-Specific Query)" > > There is no requirement for the source address to be on the same subnet as > the host. > > Thanks, > Kunal > > > _______________________________________________ > magma mailing list > magma@ietf.org > https://www.ietf.org/mailman/listinfo/magma > > > > **************** CAUTION - Disclaimer ***************** > This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended > solely > for the use of the addressee(s). If you are not the intended recipient, > please > notify the sender by e-mail and delete the original message. Further, you > are not > to copy, disclose, or distribute this e-mail or its contents to any other > person and > any such actions are unlawful. This e-mail may contain viruses. Infosys has > taken > every reasonable precaution to minimize this risk, but is not liable for > any damage > you may sustain as a result of any virus in this e-mail. You should carry > out your > own virus checks before opening the e-mail or attachment. Infosys reserves > the > right to monitor and review the content of all messages sent to or from > this e-mail > address. Messages sent to or from this e-mail address may be stored on the > Infosys e-mail system. > ***INFOSYS******** End of Disclaimer ********INFOSYS*** > --001485f6d9fedcb3ef04af1aca0a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Bharat,

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 I was thinking on the line of = cat3k switches where we can configure SVIs.

=A0

Thanks,

Indranil

On Wed, Oct 12, 2011 at 4:53 PM, Bharat Joshi <bharat_josh= i@infosys.com> wrote:

How is a switch has two differen= t subnets on its two ports? Typically switch divides the broadcast domain. = Right?

Regards,
Bharat
________________________________________
From:= magma-bounces@ietf.org [magma-bounces@ietf.org] On Behalf= Of Indranil Bhattacharya [myse= lfindranil@gmail.com]
Sent: Wednesday, October 12, 2011 2:05 PM

To: Kunal Shah
Cc: m= agma@ietf.org
Subject: Re: [magma] Question about IGMP host im= plementation

Hi Kunal,

=A0 =A0 =A0 =A0 =A0 =A0 Yes it shoul= d. The scenario that I have in mind is a switch whose mrouter interface is = in vlanA and igmp joins are received on an interface in vlanB. In this case= , query coming from vlanA(different subnet) has to be answered by hosts in = vlanB.

Thanks,
Indranil

On Wed, Oct 12, 2011 at 6:08 AM, Kunal Shah <kunal.shah@ericsson.com<mailto:<= a href=3D"mailto:kunal.shah@ericsson.com">kunal.shah@ericsson.com>&g= t; wrote:
Hi all,

Can an IGMPv2 host respond to a general query originated fro= m a subnet other then its own?? RFC 2236 states:

""query r= eceived" occurs when the host receives either a valid
=A0 =A0 Gener= al Membership Query message, or a valid Group-Specific
=A0 =A0 Membership Query message. =A0To be valid, the Query message must be=
=A0 =A0 at least 8 octets long, and have a correct IGMP checksum. =A0Th= e
=A0 =A0 group address in the IGMP header must either be zero (a Genera= l
=A0 =A0 Query) or a valid multicast group address (a Group-Specific Qu= ery)"

There is no requirement for the source address to be on the same subnet= as the host.

Thanks,
Kunal

__________________________= _____________________
magma mailing list
magma@ietf.org<mailto:= magma@ietf.org>
h= ttps://www.ietf.org/mailman/listinfo/magma

**************** CAUTION - Disclaimer *******= **********
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION = intended solely
for the use of the addressee(s). If you are not the inte= nded recipient, please
notify the sender by e-mail and delete the original message. Further, you a= re not
to copy, disclose, or distribute this e-mail or its contents to a= ny other person and
any such actions are unlawful. This e-mail may conta= in viruses. Infosys has taken
every reasonable precaution to minimize this risk, but is not liable for an= y damage
you may sustain as a result of any virus in this e-mail. You sh= ould carry out your
own virus checks before opening the e-mail or attach= ment. Infosys reserves the
right to monitor and review the content of all messages sent to or from thi= s e-mail
address. Messages sent to or from this e-mail address may be st= ored on the
Infosys e-mail system.
***INFOSYS******** End of Disclaim= er ********INFOSYS***

--001485f6d9fedcb3ef04af1aca0a-- From kunal.shah@ericsson.com Wed Oct 12 08:48:05 2011 Return-Path: X-Original-To: magma@ietfa.amsl.com Delivered-To: magma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED6E021F8B8E for ; Wed, 12 Oct 2011 08:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDmzfYTfUGYP for ; Wed, 12 Oct 2011 08:48:05 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 62CCF21F8B7E for ; Wed, 12 Oct 2011 08:48:05 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p9CFlgR4021727; Wed, 12 Oct 2011 10:48:04 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.120]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 12 Oct 2011 11:48:00 -0400 From: Kunal Shah To: Bharat Joshi , "magma@ietf.org" Date: Wed, 12 Oct 2011 11:47:59 -0400 Thread-Topic: Question about IGMP host implementation Thread-Index: AcyId0SCeinZjfcnSnCOOiiZpocqFgAWZnLtAAlSjLA= Message-ID: <4FD1E7CD248BF84F86BD4814EDDDBCC151401F3B7A@EUSAACMS0703.eamcs.ericsson.se> References: <4FD1E7CD248BF84F86BD4814EDDDBCC151401F3936@EUSAACMS0703.eamcs.ericsson.se> <31D55C4D55BEED48A4459EB64567589A1186EB24E9@BLRKECMBX02.ad.infosys.com> In-Reply-To: <31D55C4D55BEED48A4459EB64567589A1186EB24E9@BLRKECMBX02.ad.infosys.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [magma] Question about IGMP host implementation X-BeenThere: magma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast and Anycast Group Membership List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 15:48:06 -0000 Hi Bharat, The security consideration addresses the processing of a report from a diff= erent subnet on the router. My question pertains to the processing of a Que= ry from a different subnet on the host. Kunal=20 -----Original Message----- From: Bharat Joshi [mailto:bharat_joshi@infosys.com]=20 Sent: Wednesday, October 12, 2011 4:20 AM To: Kunal Shah; magma@ietf.org Subject: RE: Question about IGMP host implementation Hi Kunal, I think to keep the security tight, it is better to not respond to = queries received from a source address which does not fall on a subnet on t= hat interface. Please note that this should be done only broadcast interfac= es. It may not work on point-to-point links. If you look at the security consideration in RFC 2236, it is mentio= ned that for reports, the above check should be done. Regards, Bharat ________________________________________ From: magma-bounces@ietf.org [magma-bounces@ietf.org] On Behalf Of Kunal Sh= ah [kunal.shah@ericsson.com] Sent: Wednesday, October 12, 2011 6:08 AM To: magma@ietf.org Subject: [magma] Question about IGMP host implementation Hi all, Can an IGMPv2 host respond to a general query originated from a subnet othe= r then its own?? RFC 2236 states: ""query received" occurs when the host receives either a valid General Membership Query message, or a valid Group-Specific Membership Query message. To be valid, the Query message must be at least 8 octets long, and have a correct IGMP checksum. The group address in the IGMP header must either be zero (a General Query) or a valid multicast group address (a Group-Specific Query)" There is no requirement for the source address to be on the same subnet as = the host. Thanks, Kunal **************** CAUTION - Disclaimer ***************** This e-mail contain= s PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of th= e addressee(s). If you are not the intended recipient, please notify the se= nder by e-mail and delete the original message. Further, you are not to cop= y, disclose, or distribute this e-mail or its contents to any other person = and any such actions are unlawful. This e-mail may contain viruses. Infosys= has taken every reasonable precaution to minimize this risk, but is not li= able for any damage you may sustain as a result of any virus in this e-mail= . You should carry out your own virus checks before opening the e-mail or a= ttachment. Infosys reserves the right to monitor and review the content of = all messages sent to or from this e-mail address. Messages sent to or from = this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** From bharat_joshi@infosys.com Wed Oct 12 08:53:29 2011 Return-Path: X-Original-To: magma@ietfa.amsl.com Delivered-To: magma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9732F21F8B21 for ; Wed, 12 Oct 2011 08:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPqFn8w9M4Lu for ; Wed, 12 Oct 2011 08:53:29 -0700 (PDT) Received: from KECGATE03.infosys.com (kecgate03.infosys.com [122.98.10.31]) by ietfa.amsl.com (Postfix) with ESMTP id BE58721F8B50 for ; Wed, 12 Oct 2011 08:53:25 -0700 (PDT) X-TM-IMSS-Message-ID: Received: from blrkechub04.ad.infosys.com ([10.66.236.44]) by infosys.com ([122.98.10.31]) with ESMTP (TREND IMSS SMTP Service 7.1) id dd2ad8b000042b59 ; Wed, 12 Oct 2011 21:22:09 +0530 Received: from BLRKECHUB05.ad.infosys.com (10.66.236.45) by blrkechub04.ad.infosys.com (10.66.236.44) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 12 Oct 2011 21:22:18 +0530 Received: from BLRKECMBX02.ad.infosys.com ([10.66.236.22]) by BLRKECHUB05.ad.infosys.com ([10.66.236.45]) with mapi; Wed, 12 Oct 2011 21:22:17 +0530 From: Bharat Joshi To: Kunal Shah , "magma@ietf.org" Date: Wed, 12 Oct 2011 21:20:11 +0530 Thread-Topic: Question about IGMP host implementation Thread-Index: AcyId0SCeinZjfcnSnCOOiiZpocqFgAWZnLtAAlSjLAAAB3mLg== Message-ID: <31D55C4D55BEED48A4459EB64567589A1186EB24EB@BLRKECMBX02.ad.infosys.com> References: <4FD1E7CD248BF84F86BD4814EDDDBCC151401F3936@EUSAACMS0703.eamcs.ericsson.se> <31D55C4D55BEED48A4459EB64567589A1186EB24E9@BLRKECMBX02.ad.infosys.com>, <4FD1E7CD248BF84F86BD4814EDDDBCC151401F3B7A@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <4FD1E7CD248BF84F86BD4814EDDDBCC151401F3B7A@EUSAACMS0703.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [magma] Question about IGMP host implementation X-BeenThere: magma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast and Anycast Group Membership List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 15:53:29 -0000 Kunal, What I am suggesting is that though RFC does not explicitly suggest= it, it might be better to do this for broadcast interfaces. But yes, RFC does not suggest anything on this so a host can proces= s a query message with a source address from any other subnet as well. Regards, Bharat ________________________________________ From: Kunal Shah [kunal.shah@ericsson.com] Sent: Wednesday, October 12, 2011 9:17 PM To: Bharat Joshi; magma@ietf.org Subject: RE: Question about IGMP host implementation Hi Bharat, The security consideration addresses the processing of a report from a diff= erent subnet on the router. My question pertains to the processing of a Que= ry from a different subnet on the host. Kunal -----Original Message----- From: Bharat Joshi [mailto:bharat_joshi@infosys.com] Sent: Wednesday, October 12, 2011 4:20 AM To: Kunal Shah; magma@ietf.org Subject: RE: Question about IGMP host implementation Hi Kunal, I think to keep the security tight, it is better to not respond to = queries received from a source address which does not fall on a subnet on t= hat interface. Please note that this should be done only broadcast interfac= es. It may not work on point-to-point links. If you look at the security consideration in RFC 2236, it is mentio= ned that for reports, the above check should be done. Regards, Bharat ________________________________________ From: magma-bounces@ietf.org [magma-bounces@ietf.org] On Behalf Of Kunal Sh= ah [kunal.shah@ericsson.com] Sent: Wednesday, October 12, 2011 6:08 AM To: magma@ietf.org Subject: [magma] Question about IGMP host implementation Hi all, Can an IGMPv2 host respond to a general query originated from a subnet othe= r then its own?? RFC 2236 states: ""query received" occurs when the host receives either a valid General Membership Query message, or a valid Group-Specific Membership Query message. To be valid, the Query message must be at least 8 octets long, and have a correct IGMP checksum. The group address in the IGMP header must either be zero (a General Query) or a valid multicast group address (a Group-Specific Query)" There is no requirement for the source address to be on the same subnet as = the host. Thanks, Kunal **************** CAUTION - Disclaimer ***************** This e-mail contain= s PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of th= e addressee(s). If you are not the intended recipient, please notify the se= nder by e-mail and delete the original message. Further, you are not to cop= y, disclose, or distribute this e-mail or its contents to any other person = and any such actions are unlawful. This e-mail may contain viruses. Infosys= has taken every reasonable precaution to minimize this risk, but is not li= able for any damage you may sustain as a result of any virus in this e-mail= . You should carry out your own virus checks before opening the e-mail or a= ttachment. Infosys reserves the right to monitor and review the content of = all messages sent to or from this e-mail address. Messages sent to or from = this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** From karen.kimball@hp.com Wed Oct 12 10:35:57 2011 Return-Path: X-Original-To: magma@ietfa.amsl.com Delivered-To: magma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB3F21F869E for ; Wed, 12 Oct 2011 10:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id glAw2Z8j++TC for ; Wed, 12 Oct 2011 10:35:55 -0700 (PDT) Received: from g4t0017.houston.hp.com (g4t0017.houston.hp.com [15.201.24.20]) by ietfa.amsl.com (Postfix) with ESMTP id 90D4921F8634 for ; Wed, 12 Oct 2011 10:35:55 -0700 (PDT) Received: from G2W1953G.americas.hpqcorp.net (g2w1953g.austin.hp.com [16.238.8.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g4t0017.houston.hp.com (Postfix) with ESMTPS id 1CE483822C for ; Wed, 12 Oct 2011 17:35:55 +0000 (UTC) Received: from G4W3200G.americas.hpqcorp.net (16.234.105.236) by G2W1953G.americas.hpqcorp.net (16.238.8.185) with Microsoft SMTP Server (TLS) id 14.1.289.1; Wed, 12 Oct 2011 17:32:34 +0000 Received: from G4W3296.americas.hpqcorp.net ([169.254.10.66]) by G4W3200G.americas.hpqcorp.net ([16.234.105.236]) with mapi id 14.01.0289.001; Wed, 12 Oct 2011 17:32:29 +0000 From: "Kimball, Karen E" To: "magma@ietf.org" Thread-Topic: Cross-Vlan IGMP query-forwarding. Thread-Index: AQHMiQTqbHdhDL/zF02vWRnar3IqAQ== Date: Wed, 12 Oct 2011 17:32:26 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [16.216.12.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [magma] Cross-Vlan IGMP query-forwarding. X-BeenThere: magma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast and Anycast Group Membership List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 17:35:57 -0000 Hello, all, IGMP is not responsible for routing across VLANs. It is actually designed t= o keep things local to its own VLAN-- to reduce flooding, rather than creat= e it. Indranil's diagram is shown below: > VLANA(10.x.x.x) VLANB(20.x.x.x) > > RTR--------------------------sw-------------------------HOST. If you want to route IGMP Queries from one VLAN to IGMP hosts on another, t= hen you use a multicast routing protocol such as PIM. IGMP alone is not expected to perform this function. Thank you and best regards, Karen Kimball Message: 1 Date: Wed, 12 Oct 2011 19:54:26 +0530 From: Indranil Bhattacharya To: "Beeram, Suresh KumarReddy" Cc: "magma@ietf.org" Subject: Re: [magma] Question about IGMP host implementation Message-ID: Content-Type: text/plain; charset=3D"iso-8859-1" Hi Suresh, VLANA(10.x.x.x) VLANB(20.x.x.x) RTR-------------------------------sw------------------------------HOST. All the queries received on VLANA will be forwared to VLANB. When mcast dat= a is received on vlanA those will also be forwarded on vlanB after some heade= r rewrite. Please let me know if this answers your question. Thanks, Indranil On Wed, Oct 12, 2011 at 4:16 PM, Beeram, Suresh KumarReddy wrote: > Hi Indranil,**** > > Why the Query coming from VLAN-A has to be forwarded to VLAN-B?**** > > In general switch should forward the Query packets to all the ports in sa= me > VLAN(VLAN-A). Hosts receiving the Query can reply to the query even the > source address of the Query is in different subnet.**** > > Is there anything I am missing in your reply???**** > > Thanks**** > > B S Reddy**** > > ** ** > > *From:* magma-bounces@ietf.org [mailto:magma-bounces@ietf.org] *On Behalf > Of *Indranil Bhattacharya > *Sent:* Wednesday, October 12, 2011 2:06 PM > *To:* Kunal Shah > *Cc:* magma@ietf.org > *Subject:* Re: [magma] Question about IGMP host implementation**** > > ** ** > > Hi Kunal,**** > > **** > > Yes it should. The scenario that I have in mind is a switch > whose mrouter interface is in vlanA and igmp joins are received on an > interface in vlanB. In this case, query coming from vlanA(different subne= t) > has to be answered by hosts in vlanB.**** > > **** > > Thanks,**** > > Indranil**** > > On Wed, Oct 12, 2011 at 6:08 AM, Kunal Shah > wrote:**** > > Hi all,**** > > **** > > Can an IGMPv2 host respond to a general query originated from a subnet > other then its own?? RFC 2236 states: **** > > **** > > ""query received" occurs when the host receives either a valid > General Membership Query message, or a valid Group-Specific > Membership Query message. To be valid, the Query message must be > at least 8 octets long, and have a correct IGMP checksum. The > group address in the IGMP header must either be zero (a General > Query) or a valid multicast group address (a Group-Specific Query)" = * > *** > > **** > > There is no requirement for the source address to be on the same subnet a= s > the host.**** > > **** > > Thanks,**** > > Kunal**** > > **** > > > _______________________________________________ > magma mailing list > magma@ietf.org > https://www.ietf.org/mailman/listinfo/magma**** > > ** ** > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Wed, 12 Oct 2011 19:55:14 +0530 From: Indranil Bhattacharya To: Bharat Joshi Cc: "magma@ietf.org" Subject: Re: [magma] Question about IGMP host implementation Message-ID: Content-Type: text/plain; charset=3D"iso-8859-1" Hi Bharat, I was thinking on the line of cat3k switches where we can configure SVIs. Thanks, Indranil On Wed, Oct 12, 2011 at 4:53 PM, Bharat Joshi wro= te: > How is a switch has two different subnets on its two ports? Typically > switch divides the broadcast domain. Right? > > Regards, > Bharat > ________________________________________ > From: magma-bounces@ietf.org [magma-bounces@ietf.org] On Behalf Of > Indranil Bhattacharya [myselfindranil@gmail.com] > Sent: Wednesday, October 12, 2011 2:05 PM > To: Kunal Shah > Cc: magma@ietf.org > Subject: Re: [magma] Question about IGMP host implementation > > Hi Kunal, > > Yes it should. The scenario that I have in mind is a switch > whose mrouter interface is in vlanA and igmp joins are received on an > interface in vlanB. In this case, query coming from vlanA(different subne= t) > has to be answered by hosts in vlanB. > > Thanks, > Indranil > > On Wed, Oct 12, 2011 at 6:08 AM, Kunal Shah > wrote: > Hi all, > > Can an IGMPv2 host respond to a general query originated from a subnet > other then its own?? RFC 2236 states: > > ""query received" occurs when the host receives either a valid > General Membership Query message, or a valid Group-Specific > Membership Query message. To be valid, the Query message must be > at least 8 octets long, and have a correct IGMP checksum. The > group address in the IGMP header must either be zero (a General > Query) or a valid multicast group address (a Group-Specific Query)" > > There is no requirement for the source address to be on the same subnet a= s > the host. > > Thanks, > Kunal > > > _______________________________________________ > magma mailing list > magma@ietf.org > https://www.ietf.org/mailman/listinfo/magma > > > > **************** CAUTION - Disclaimer ***************** > This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended > solely > for the use of the addressee(s). If you are not the intended recipient, > please > notify the sender by e-mail and delete the original message. Further, you > are not > to copy, disclose, or distribute this e-mail or its contents to any other > person and > any such actions are unlawful. This e-mail may contain viruses. Infosys h= as > taken > every reasonable precaution to minimize this risk, but is not liable for > any damage > you may sustain as a result of any virus in this e-mail. You should carry > out your > own virus checks before opening the e-mail or attachment. Infosys reserve= s > the > right to monitor and review the content of all messages sent to or from > this e-mail > address. Messages sent to or from this e-mail address may be stored on th= e > Infosys e-mail system. > ***INFOSYS******** End of Disclaimer ********INFOSYS*** > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 3 Date: Wed, 12 Oct 2011 11:47:59 -0400 From: Kunal Shah To: Bharat Joshi , "magma@ietf.org" Subject: Re: [magma] Question about IGMP host implementation Message-ID: <4FD1E7CD248BF84F86BD4814EDDDBCC151401F3B7A@EUSAACMS0703.eamcs.ericsson.se= > =09 Content-Type: text/plain; charset=3D"us-ascii" Hi Bharat, The security consideration addresses the processing of a report from a diff= erent subnet on the router. My question pertains to the processing of a Que= ry from a different subnet on the host. Kunal=20 -----Original Message----- From: Bharat Joshi [mailto:bharat_joshi@infosys.com]=20 Sent: Wednesday, October 12, 2011 4:20 AM To: Kunal Shah; magma@ietf.org Subject: RE: Question about IGMP host implementation Hi Kunal, I think to keep the security tight, it is better to not respond to = queries received from a source address which does not fall on a subnet on t= hat interface. Please note that this should be done only broadcast interfac= es. It may not work on point-to-point links. If you look at the security consideration in RFC 2236, it is mentio= ned that for reports, the above check should be done. Regards, Bharat ________________________________________ From: magma-bounces@ietf.org [magma-bounces@ietf.org] On Behalf Of Kunal Sh= ah [kunal.shah@ericsson.com] Sent: Wednesday, October 12, 2011 6:08 AM To: magma@ietf.org Subject: [magma] Question about IGMP host implementation Hi all, Can an IGMPv2 host respond to a general query originated from a subnet othe= r then its own?? RFC 2236 states: ""query received" occurs when the host receives either a valid General Membership Query message, or a valid Group-Specific Membership Query message. To be valid, the Query message must be at least 8 octets long, and have a correct IGMP checksum. The group address in the IGMP header must either be zero (a General Query) or a valid multicast group address (a Group-Specific Query)" There is no requirement for the source address to be on the same subnet as = the host. Thanks, Kunal **************** CAUTION - Disclaimer ***************** This e-mail contain= s PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of th= e addressee(s). If you are not the intended recipient, please notify the se= nder by e-mail and delete the original message. Further, you are not to cop= y, disclose, or distribute this e-mail or its contents to any other person = and any such actions are unlawful. This e-mail may contain viruses. Infosys= has taken every reasonable precaution to minimize this risk, but is not li= able for any damage you may sustain as a result of any virus in this e-mail= . You should carry out your own virus checks before opening the e-mail or a= ttachment. Infosys reserves the right to monitor and review the content of = all messages sent to or from this e-mail address. Messages sent to or from = this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** ------------------------------ Message: 4 Date: Wed, 12 Oct 2011 21:20:11 +0530 From: Bharat Joshi To: Kunal Shah , "magma@ietf.org" Subject: Re: [magma] Question about IGMP host implementation Message-ID: <31D55C4D55BEED48A4459EB64567589A1186EB24EB@BLRKECMBX02.ad.infosys.com> =09 Content-Type: text/plain; charset=3D"us-ascii" Kunal, What I am suggesting is that though RFC does not explicitly suggest= it, it might be better to do this for broadcast interfaces. But yes, RFC does not suggest anything on this so a host can proces= s a query message with a source address from any other subnet as well. Regards, Bharat ________________________________________ From: Kunal Shah [kunal.shah@ericsson.com] Sent: Wednesday, October 12, 2011 9:17 PM To: Bharat Joshi; magma@ietf.org Subject: RE: Question about IGMP host implementation Hi Bharat, The security consideration addresses the processing of a report from a diff= erent subnet on the router. My question pertains to the processing of a Que= ry from a different subnet on the host. Kunal -----Original Message----- From: Bharat Joshi [mailto:bharat_joshi@infosys.com] Sent: Wednesday, October 12, 2011 4:20 AM To: Kunal Shah; magma@ietf.org Subject: RE: Question about IGMP host implementation Hi Kunal, I think to keep the security tight, it is better to not respond to = queries received from a source address which does not fall on a subnet on t= hat interface. Please note that this should be done only broadcast interfac= es. It may not work on point-to-point links. If you look at the security consideration in RFC 2236, it is mentio= ned that for reports, the above check should be done. Regards, Bharat ________________________________________ From: magma-bounces@ietf.org [magma-bounces@ietf.org] On Behalf Of Kunal Sh= ah [kunal.shah@ericsson.com] Sent: Wednesday, October 12, 2011 6:08 AM To: magma@ietf.org Subject: [magma] Question about IGMP host implementation Hi all, Can an IGMPv2 host respond to a general query originated from a subnet othe= r then its own?? RFC 2236 states: ""query received" occurs when the host receives either a valid General Membership Query message, or a valid Group-Specific Membership Query message. To be valid, the Query message must be at least 8 octets long, and have a correct IGMP checksum. The group address in the IGMP header must either be zero (a General Query) or a valid multicast group address (a Group-Specific Query)" There is no requirement for the source address to be on the same subnet as = the host. Thanks, Kunal **************** CAUTION - Disclaimer ***************** This e-mail contain= s PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of th= e addressee(s). If you are not the intended recipient, please notify the se= nder by e-mail and delete the original message. Further, you are not to cop= y, disclose, or distribute this e-mail or its contents to any other person = and any such actions are unlawful. This e-mail may contain viruses. Infosys= has taken every reasonable precaution to minimize this risk, but is not li= able for any damage you may sustain as a result of any virus in this e-mail= . You should carry out your own virus checks before opening the e-mail or a= ttachment. Infosys reserves the right to monitor and review the content of = all messages sent to or from this e-mail address. Messages sent to or from = this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** ------------------------------ _______________________________________________ magma mailing list magma@ietf.org https://www.ietf.org/mailman/listinfo/magma End of magma Digest, Vol 77, Issue 2 ************************************ From thomas.morin@orange.com Thu Oct 13 01:26:48 2011 Return-Path: X-Original-To: magma@ietfa.amsl.com Delivered-To: magma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB7921F8B5B for ; Thu, 13 Oct 2011 01:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M25mc0baTOpQ for ; Thu, 13 Oct 2011 01:26:47 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 526C821F8A56 for ; Thu, 13 Oct 2011 01:26:46 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 35252FDC004 for ; Thu, 13 Oct 2011 10:26:44 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 26D06FC4003 for ; Thu, 13 Oct 2011 10:26:44 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 Oct 2011 10:26:44 +0200 Received: from [10.193.71.92] ([10.193.71.92]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 Oct 2011 10:26:43 +0200 Message-ID: <4E96A0C3.9010602@orange.com> Date: Thu, 13 Oct 2011 10:26:43 +0200 From: Thomas Morin Organization: France Telecom Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: magma@ietf.org References: <4FD1E7CD248BF84F86BD4814EDDDBCC151401F3936@EUSAACMS0703.eamcs.ericsson.se> <31D55C4D55BEED48A4459EB64567589A1186EB24E9@BLRKECMBX02.ad.infosys.com>, <4FD1E7CD248BF84F86BD4814EDDDBCC151401F3B7A@EUSAACMS0703.eamcs.ericsson.se> <31D55C4D55BEED48A4459EB64567589A1186EB24EB@BLRKECMBX02.ad.infosys.com> In-Reply-To: <31D55C4D55BEED48A4459EB64567589A1186EB24EB@BLRKECMBX02.ad.infosys.com> Content-Type: multipart/alternative; boundary="------------020507060806080000000703" X-OriginalArrivalTime: 13 Oct 2011 08:26:43.0740 (UTC) FILETIME=[D6FA0DC0:01CC8981] Subject: Re: [magma] Question about IGMP host implementation X-BeenThere: magma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast and Anycast Group Membership List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 08:26:48 -0000 This is a multi-part message in MIME format. --------------020507060806080000000703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi, Obviously there is no legitimate case where a query would come from another subnet. The question is how to avoiding such queries from being processed... IGMPv3 specs talks a bit about this aspect ; RFC3376, section 9.1, Security Considerations, Query message: There are three measures necessary to defend against externally forged Queries: o Routers SHOULD NOT forward Queries. This is easier for a router to accomplish if the Query carries the Router-Alert option. o Hosts SHOULD ignore v2 or v3 Queries without the Router-Alert option. o Hosts SHOULD ignore v1, v2 or v3 General Queries sent to a multicast address other than 224.0.0.1, the all-systems address. If a host enforces these rules, AFAICT there is no case were it would process a Query from another subnet. Even though RFC2236 is silent on this aspect, an RFC3376 host implementation in IGMPv2 compatibility mode would be expected to apply these checks. On the other hand, RFC3376 also says, in 4.1.12. IP Destination Addresses for Queries: In IGMPv3, General Queries are sent with an IP destination address of 224.0.0.1, the all-systems multicast address. Group-Specific and Group-and-Source-Specific Queries are sent with an IP destination address equal to the multicast address of interest. *However*, a system MUST accept and process any Query whose IP Destination Address ^^^^^^^^^^^^^^^ field contains *any* of the addresses (unicast or multicast) ^^^^^^^^^^^^^^^^^^^^^^^^^^ assigned to the interface on which the Query arrives. This rule contradicts the third rule above (which would in itself deserve a discussion), but the two first rules are possibly enough: if an attacker forges a Query, under the assumption that at least one Router on the path to the victim supports the Router Alert option and implements IGMP and enforces the first of the three rules above, if hosts apply the second rule, then no forged packet will be processed by hosts... The issue is that it may not be reasonable to count on all this to be true (eg. there are IGMP Querier implementations in the wild that do not set the RA option in Query messages...). The most reasonable thing to do, as suggested below, is to drop Queries whose source address is from another subnet. A nicer solution would be to apply GTSM (RFC5082) to IGMP, but transitioning to it is absolutely not trivial. -Thomas Bharat Joshi a �crit : > Kunal, > > What I am suggesting is that though RFC does not explicitly suggest it, it might be better to do this for broadcast interfaces. > > But yes, RFC does not suggest anything on this so a host can process a query message with a source address from any other subnet as well. > > Regards, > Bharat > ________________________________________ > From: Kunal Shah [kunal.shah@ericsson.com] > Sent: Wednesday, October 12, 2011 9:17 PM > To: Bharat Joshi;magma@ietf.org > Subject: RE: Question about IGMP host implementation > > Hi Bharat, > > The security consideration addresses the processing of a report from a different subnet on the router. My question pertains to the processing of a Query from a different subnet on the host. > > Kunal > > -----Original Message----- > From: Bharat Joshi [mailto:bharat_joshi@infosys.com] > Sent: Wednesday, October 12, 2011 4:20 AM > To: Kunal Shah;magma@ietf.org > Subject: RE: Question about IGMP host implementation > > Hi Kunal, > > I think to keep the security tight, it is better to not respond to queries received from a source address which does not fall on a subnet on that interface. Please note that this should be done only broadcast interfaces. It may not work on point-to-point links. > > If you look at the security consideration in RFC 2236, it is mentioned that for reports, the above check should be done. > > Regards, > Bharat > ________________________________________ > From:magma-bounces@ietf.org [magma-bounces@ietf.org] On Behalf Of Kunal Shah [kunal.shah@ericsson.com] > Sent: Wednesday, October 12, 2011 6:08 AM > To:magma@ietf.org > Subject: [magma] Question about IGMP host implementation > > Hi all, > > Can an IGMPv2 host respond to a general query originated from a subnet other then its own?? RFC 2236 states: > > ""query received" occurs when the host receives either a valid > General Membership Query message, or a valid Group-Specific > Membership Query message. To be valid, the Query message must be > at least 8 octets long, and have a correct IGMP checksum. The > group address in the IGMP header must either be zero (a General > Query) or a valid multicast group address (a Group-Specific Query)" > > There is no requirement for the source address to be on the same subnet as the host. > > Thanks, > Kunal > > > **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. > ***INFOSYS******** End of Disclaimer ********INFOSYS*** > _______________________________________________ > magma mailing list > magma@ietf.org > https://www.ietf.org/mailman/listinfo/magma --------------020507060806080000000703 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

Obviously there is no legitimate case where a query would come from another subnet.
The question is how to avoiding such queries from being processed...

IGMPv3 specs talks a bit about this aspect ; RFC3376, section 9.1, Security Considerations, Query message:

 There are three measures necessary to defend against externally forged Queries:

   o Routers SHOULD NOT forward Queries.  This is easier for a router to
     accomplish if the Query carries the Router-Alert option.

   o Hosts SHOULD ignore v2 or v3 Queries without the Router-Alert
     option.

   o Hosts SHOULD ignore v1, v2 or v3 General Queries sent to a
     multicast address other than 224.0.0.1, the all-systems address.

If a host enforces these rules, AFAICT there is no case were it would process a Query from another subnet.
Even though RFC2236 is silent on this aspect, an RFC3376 host implementation in IGMPv2 compatibility mode would be expected to apply these checks.

On the other hand, RFC3376 also says, in 4.1.12. IP Destination Addresses for Queries:

   In IGMPv3, General Queries are sent with an IP destination address of
   224.0.0.1, the all-systems multicast address.  Group-Specific and
   Group-and-Source-Specific Queries are sent with an IP destination
   address equal to the  multicast address of interest.  *However*, a
   system MUST accept and  process any Query whose IP Destination Address
          ^^^^^^^^^^^^^^^
   field contains *any* of the addresses (unicast or multicast)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^                  
   assigned to the interface on which the Query arrives.

This rule contradicts the third rule above (which would in itself deserve a discussion), but the two first rules are possibly enough: if an attacker forges a Query, under the assumption that at least one Router on the path to the victim supports the Router Alert option and implements IGMP and enforces the first of the three rules above, if hosts apply the second rule, then no forged packet will be processed by hosts... The issue is that it may not be reasonable to count on all this to be true (eg. there are IGMP Querier implementations in the wild that do not set the RA option in Query messages...).

The most reasonable thing to do, as suggested below, is to drop Queries whose source address is from another subnet.

A nicer solution would be to apply GTSM (RFC5082) to IGMP, but transitioning to it is absolutely not trivial.

-Thomas

Bharat Joshi a écrit :

Kunal,

        What I am suggesting is that though RFC does not explicitly suggest it, it might be better to do this for broadcast interfaces.

        But yes, RFC does not suggest anything on this so a host can process a query message with a source address from any other subnet as well.

Regards,
Bharat
________________________________________
From: Kunal Shah [kunal.shah@ericsson.com]
Sent: Wednesday, October 12, 2011 9:17 PM
To: Bharat Joshi; magma@ietf.org
Subject: RE: Question about IGMP host implementation

Hi Bharat,

The security consideration addresses the processing of a report from a different subnet on the router. My question pertains to the processing of a Query from a different subnet on the host.

Kunal

-----Original Message-----
From: Bharat Joshi [mailto:bharat_joshi@infosys.com]
Sent: Wednesday, October 12, 2011 4:20 AM
To: Kunal Shah; magma@ietf.org
Subject: RE: Question about IGMP host implementation

Hi Kunal,

        I think to keep the security tight, it is better to not respond to queries received from a source address which does not fall on a subnet on that interface. Please note that this should be done only broadcast interfaces. It may not work on point-to-point links.

        If you look at the security consideration in RFC 2236, it is mentioned that for reports, the above check should be done.

Regards,
Bharat
________________________________________
From: magma-bounces@ietf.org [magma-bounces@ietf.org] On Behalf Of Kunal Shah [kunal.shah@ericsson.com]
Sent: Wednesday, October 12, 2011 6:08 AM
To: magma@ietf.org
Subject: [magma] Question about IGMP host implementation

Hi all,

Can an IGMPv2 host respond to a general query originated from a subnet other then its own?? RFC 2236 states:

""query received" occurs when the host receives either a valid
     General Membership Query message, or a valid Group-Specific
     Membership Query message.  To be valid, the Query message must be
     at least 8 octets long, and have a correct IGMP checksum.  The
     group address in the IGMP header must either be zero (a General
     Query) or a valid multicast group address (a Group-Specific Query)"

There is no requirement for the source address to be on the same subnet as the host.

Thanks,
Kunal


**************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***
_______________________________________________
magma mailing list
magma@ietf.org
https://www.ietf.org/mailman/listinfo/magma

--------------020507060806080000000703-- From stig@venaas.com Thu Oct 13 10:10:32 2011 Return-Path: X-Original-To: magma@ietfa.amsl.com Delivered-To: magma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3CFE21F8A64 for ; Thu, 13 Oct 2011 10:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eiojy0u99Sco for ; Thu, 13 Oct 2011 10:10:31 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id E14F921F8B72 for ; Thu, 13 Oct 2011 10:10:30 -0700 (PDT) Received: from [10.33.12.90] (128-107-239-233.cisco.com [128.107.239.233]) by ufisa.uninett.no (Postfix) with ESMTPSA id F201F7FD8; Thu, 13 Oct 2011 19:10:28 +0200 (CEST) Message-ID: <4E971B82.2090508@venaas.com> Date: Thu, 13 Oct 2011 10:10:26 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Thomas Morin References: <4FD1E7CD248BF84F86BD4814EDDDBCC151401F3936@EUSAACMS0703.eamcs.ericsson.se> <31D55C4D55BEED48A4459EB64567589A1186EB24E9@BLRKECMBX02.ad.infosys.com>, <4FD1E7CD248BF84F86BD4814EDDDBCC151401F3B7A@EUSAACMS0703.eamcs.ericsson.se> <31D55C4D55BEED48A4459EB64567589A1186EB24EB@BLRKECMBX02.ad.infosys.com> <4E96A0C3.9010602@orange.com> In-Reply-To: <4E96A0C3.9010602@orange.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: magma@ietf.org Subject: Re: [magma] Question about IGMP host implementation X-BeenThere: magma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast and Anycast Group Membership List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 17:10:32 -0000 On 10/13/2011 1:26 AM, Thomas Morin wrote: > Hi, > > Obviously there is no legitimate case where a query would come from > another subnet. > The question is how to avoiding such queries from being processed... > > IGMPv3 specs talks a bit about this aspect ; RFC3376, section 9.1, > Security Considerations, Query message: > > There are three measures necessary to defend against externally forged Queries: > > o Routers SHOULD NOT forward Queries. This is easier for a router to > accomplish if the Query carries the Router-Alert option. > > o Hosts SHOULD ignore v2 or v3 Queries without the Router-Alert > option. > > o Hosts SHOULD ignore v1, v2 or v3 General Queries sent to a > multicast address other than 224.0.0.1, the all-systems address. > > If a host enforces these rules, AFAICT there is no case were it would > process a Query from another subnet. > Even though RFC2236 is silent on this aspect, an RFC3376 host > implementation in IGMPv2 compatibility mode would be expected to apply > these checks. > > On the other hand, RFC3376 also says, in 4.1.12. IP Destination > Addresses for Queries: > > In IGMPv3, General Queries are sent with an IP destination address of > 224.0.0.1, the all-systems multicast address. Group-Specific and > Group-and-Source-Specific Queries are sent with an IP destination > address equal to the multicast address of interest. *However*, a > system MUST accept and process any Query whose IP Destination Address > ^^^^^^^^^^^^^^^ > field contains *any* of the addresses (unicast or multicast) > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > assigned to the interface on which the Query arrives. > > > This rule contradicts the third rule above (which would in itself > deserve a discussion), but the two first rules are possibly enough: if > an attacker forges a Query, under the assumption that at least one > Router on the path to the victim supports the Router Alert option and > implements IGMP and enforces the first of the three rules above, if > hosts apply the second rule, then no forged packet will be processed by > hosts... The issue is that it may not be reasonable to count on all this > to be true (eg. there are IGMP Querier implementations in the wild that > do not set the RA option in Query messages...). > > The most reasonable thing to do, as suggested below, is to drop Queries > whose source address is from another subnet. > > A nicer solution would be to apply GTSM (RFC5082) to IGMP, but > transitioning to it is absolutely not trivial. Yes, I have been thinking whether GTSM should be used for unicast IGMPv3 messages. I don't think transitioning to that is all that hard. It depends a bit how common it is to do unicast IGMP today. Checking GTSM on the receiving end would have to be something that can be configured until one can expect all senders to do it. If there is some support for GTSM, we could try a draft updating the IGMPv3 RFC perhaps... Stig > > -Thomas > > > > Bharat Joshi a �crit : >> Kunal, >> >> What I am suggesting is that though RFC does not explicitly suggest it, it might be better to do this for broadcast interfaces. >> >> But yes, RFC does not suggest anything on this so a host can process a query message with a source address from any other subnet as well. >> >> Regards, >> Bharat >> ________________________________________ >> From: Kunal Shah [kunal.shah@ericsson.com] >> Sent: Wednesday, October 12, 2011 9:17 PM >> To: Bharat Joshi;magma@ietf.org >> Subject: RE: Question about IGMP host implementation >> >> Hi Bharat, >> >> The security consideration addresses the processing of a report from a different subnet on the router. My question pertains to the processing of a Query from a different subnet on the host. >> >> Kunal >> >> -----Original Message----- >> From: Bharat Joshi [mailto:bharat_joshi@infosys.com] >> Sent: Wednesday, October 12, 2011 4:20 AM >> To: Kunal Shah;magma@ietf.org >> Subject: RE: Question about IGMP host implementation >> >> Hi Kunal, >> >> I think to keep the security tight, it is better to not respond to queries received from a source address which does not fall on a subnet on that interface. Please note that this should be done only broadcast interfaces. It may not work on point-to-point links. >> >> If you look at the security consideration in RFC 2236, it is mentioned that for reports, the above check should be done. >> >> Regards, >> Bharat >> ________________________________________ >> From:magma-bounces@ietf.org [magma-bounces@ietf.org] On Behalf Of Kunal Shah [kunal.shah@ericsson.com] >> Sent: Wednesday, October 12, 2011 6:08 AM >> To:magma@ietf.org >> Subject: [magma] Question about IGMP host implementation >> >> Hi all, >> >> Can an IGMPv2 host respond to a general query originated from a subnet other then its own?? RFC 2236 states: >> >> ""query received" occurs when the host receives either a valid >> General Membership Query message, or a valid Group-Specific >> Membership Query message. To be valid, the Query message must be >> at least 8 octets long, and have a correct IGMP checksum. The >> group address in the IGMP header must either be zero (a General >> Query) or a valid multicast group address (a Group-Specific Query)" >> >> There is no requirement for the source address to be on the same subnet as the host. >> >> Thanks, >> Kunal >> >> >> **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. >> ***INFOSYS******** End of Disclaimer ********INFOSYS*** >> _______________________________________________ >> magma mailing list >> magma@ietf.org >> https://www.ietf.org/mailman/listinfo/magma > > > > > _______________________________________________ > magma mailing list > magma@ietf.org > https://www.ietf.org/mailman/listinfo/magma From myselfindranil@gmail.com Thu Oct 13 10:30:29 2011 Return-Path: X-Original-To: magma@ietfa.amsl.com Delivered-To: magma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDB8B21F8B4A for ; Thu, 13 Oct 2011 10:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=-0.830, BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ips6hu0uJsrQ for ; Thu, 13 Oct 2011 10:30:29 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0A6FA21F87FA for ; Thu, 13 Oct 2011 10:30:28 -0700 (PDT) Received: by wyg24 with SMTP id 24so2400578wyg.31 for ; Thu, 13 Oct 2011 10:30:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=MbkpbYSDFclDtIAKBYQd9kcPN+dmyK1PNhJZsu6ENro=; b=Z5aKU0K923sJ8fWvDFW2yHFR99DDZ4aFIUl9cirOQhk1VSaLcJEgRz3qm9zuhdlh/X UvhkhB5oim6PVKg7EV8zYWOzmCSnhlerUqpY3YSnVe2HmeJkxhKOffMRAhyfaDzA7fcU MJZNPN+LuP1DlCP0D8rbep3LQ069Oi85fKHik= MIME-Version: 1.0 Received: by 10.216.24.2 with SMTP id w2mr1560495wew.49.1318527028087; Thu, 13 Oct 2011 10:30:28 -0700 (PDT) Received: by 10.216.39.80 with HTTP; Thu, 13 Oct 2011 10:30:27 -0700 (PDT) Date: Thu, 13 Oct 2011 23:00:27 +0530 Message-ID: From: Indranil Bhattacharya To: magma@ietf.org Content-Type: multipart/alternative; boundary=0016e642db9422ca1f04af317ff1 Subject: [magma] Destination address in v2 leave message X-BeenThere: magma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast and Anycast Group Membership List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 17:30:29 -0000 --0016e642db9422ca1f04af317ff1 Content-Type: text/plain; charset=ISO-8859-1 Hi, Can anyone please tell me the disadvantage of using queriers address as destination address in v2 leave message? Is there any advantage of sending it to 224.0.0.2? Non-querier never processes leave message anyway. Thanks, Indranil --0016e642db9422ca1f04af317ff1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi,

=A0

=A0=A0=A0 Can anyone please tell me the disadvantage of using queriers= address as destination address in v2 leave message? Is there any advantage= =A0of sending it to 224.0.0.2? Non-querier never processes leave message an= yway.

=A0

Thanks,

Indranil

--0016e642db9422ca1f04af317ff1-- From kunal.shah@ericsson.com Thu Oct 13 11:18:25 2011 Return-Path: X-Original-To: magma@ietfa.amsl.com Delivered-To: magma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E96221F8A6F for ; Thu, 13 Oct 2011 11:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oi28njWzzIpx for ; Thu, 13 Oct 2011 11:18:24 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id B225C21F8A58 for ; Thu, 13 Oct 2011 11:18:24 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p9DIIID2016745 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Oct 2011 13:18:19 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.120]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Thu, 13 Oct 2011 14:18:18 -0400 From: Kunal Shah To: Indranil Bhattacharya , "magma@ietf.org" Date: Thu, 13 Oct 2011 14:18:17 -0400 Thread-Topic: [magma] Destination address in v2 leave message Thread-Index: AcyJzdTVrjNI9LgCTsyt3BxQEj8+VAABgJQA Message-ID: <4FD1E7CD248BF84F86BD4814EDDDBCC151402959E6@EUSAACMS0703.eamcs.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_4FD1E7CD248BF84F86BD4814EDDDBCC151402959E6EUSAACMS0703e_" MIME-Version: 1.0 Subject: Re: [magma] Destination address in v2 leave message X-BeenThere: magma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast and Anycast Group Membership List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 18:18:25 -0000 --_000_4FD1E7CD248BF84F86BD4814EDDDBCC151402959E6EUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Non-querier does process the leave message. On receiving a leave the non-qu= erier is going to reduce the group timer to [Max Response Time] in the pack= et * [Last Member Query Count] but will not send the leave. Please refer to= section 7 of RFC 2236. ________________________________ From: magma-bounces@ietf.org [mailto:magma-bounces@ietf.org] On Behalf Of I= ndranil Bhattacharya Sent: Thursday, October 13, 2011 10:30 AM To: magma@ietf.org Subject: [magma] Destination address in v2 leave message Hi, Can anyone please tell me the disadvantage of using queriers address as= destination address in v2 leave message? Is there any advantage of sending= it to 224.0.0.2? Non-querier never processes leave message anyway. Thanks, Indranil --_000_4FD1E7CD248BF84F86BD4814EDDDBCC151402959E6EUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Non-querier does process the leave message. On receiv= ing a=20 leave the non-querier is going to reduce the group timer to [Max Response Time] in the packet * [Last Member= Query=20 Count] but will not send the leave. Plea= se refer=20 to section 7 of RFC 2236.

From: magma-bounces@ietf.org=20 [mailto:magma-bounces@ietf.org] On Behalf Of Indranil=20 Bhattacharya
Sent: Thursday, October 13, 2011 10:30 AM
To:<= /B>=20 magma@ietf.org
Subject: [magma] Destination address in v2 leave=20 message

Hi,

    Can anyone please tell me the disadvantage of using= =20 queriers address as destination address in v2 leave message? Is there any=20 advantage of sending it to 224.0.0.2? Non-querier never processes leav= e=20 message anyway.

Thanks,

Indranil
--_000_4FD1E7CD248BF84F86BD4814EDDDBCC151402959E6EUSAACMS0703e_-- From myselfindranil@gmail.com Thu Oct 13 13:35:45 2011 Return-Path: X-Original-To: magma@ietfa.amsl.com Delivered-To: magma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9519821F84AC for ; Thu, 13 Oct 2011 13:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.291 X-Spam-Level: X-Spam-Status: No, score=-3.291 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dAuYiQ91nsuf for ; Thu, 13 Oct 2011 13:35:45 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id D60A021F84AB for ; Thu, 13 Oct 2011 13:35:44 -0700 (PDT) Received: by wwf22 with SMTP id 22so1677982wwf.13 for ; Thu, 13 Oct 2011 13:35:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=V2d5EPbks6swU7PApB+cLB+7O+6ArKlq5ZntqY38XN4=; b=jd75QQao/fgabMTk5VtxSuEev9IvPOuS+CK72qEH9gwQ6IzTP4+vzIWjnlzF6ILBvM qWaCSsejXG6XEdyZRRuf9iQkWgIo2vHmSnsCc3Qi/bgumPehz++67kpYgblqBaCDAZ23 3jnUTndFbUzrhNIvcSo54JEIKoqjFziMi738Y= MIME-Version: 1.0 Received: by 10.216.14.83 with SMTP id c61mr521060wec.4.1318538143675; Thu, 13 Oct 2011 13:35:43 -0700 (PDT) Received: by 10.216.39.80 with HTTP; Thu, 13 Oct 2011 13:35:43 -0700 (PDT) In-Reply-To: <4FD1E7CD248BF84F86BD4814EDDDBCC151402959E6@EUSAACMS0703.eamcs.ericsson.se> References: <4FD1E7CD248BF84F86BD4814EDDDBCC151402959E6@EUSAACMS0703.eamcs.ericsson.se> Date: Fri, 14 Oct 2011 02:05:43 +0530 Message-ID: From: Indranil Bhattacharya To: Kunal Shah Content-Type: multipart/alternative; boundary=001485f6d9fead352d04af3415c7 Cc: "magma@ietf.org" Subject: Re: [magma] Destination address in v2 leave message X-BeenThere: magma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast and Anycast Group Membership List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 20:35:45 -0000 --001485f6d9fead352d04af3415c7 Content-Type: text/plain; charset=ISO-8859-1 Hi Kunal, Non-queriers lower the group timers upon receiving group-specific query from querier. They always ignore leave messages. Please refer the last state diagram in section 7 which is for non-querier. Thanks, Indranil On Thu, Oct 13, 2011 at 11:48 PM, Kunal Shah wrote: > ** > Non-querier does process the leave message. On receiving a leave the > non-querier is going to reduce the group timer to [Max Response Time] in > the packet * [Last Member Query Count] but will not send the leave. Please > refer to section 7 of RFC 2236. > > ------------------------------ > *From:* magma-bounces@ietf.org [mailto:magma-bounces@ietf.org] *On Behalf > Of *Indranil Bhattacharya > *Sent:* Thursday, October 13, 2011 10:30 AM > *To:* magma@ietf.org > *Subject:* [magma] Destination address in v2 leave message > > Hi, > > Can anyone please tell me the disadvantage of using queriers address as > destination address in v2 leave message? Is there any advantage of sending > it to 224.0.0.2? Non-querier never processes leave message anyway. > > Thanks, > Indranil > --001485f6d9fead352d04af3415c7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Kunal,

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Non-queriers lower the group timers = upon receiving group-specific query from querier. They always ignore leave = messages. Please refer the last state diagram in section 7 which is for non= -querier.

=A0

Thanks,

Indranil

On Thu, Oct 13, 2011 at 11:48 PM, Kunal Shah <kunal.shah@er= icsson.com> wrote:

Non-querier does process the leave message. On receiving= a leave the non-querier is going to reduce the group timer to [Max=A0Response Time] in the packet * [Last Memb= er Query Count] but will not send th= e leave. Please refer to section 7 of RFC 2236.

From: magma-bounces@ietf.org [mailto:magma-bounces@ietf.org= ] On Behalf Of Indranil Bhattacharya
Sent: Thursday, October 13, 2011 10:30 AM
To: magma@ietf.org
Subject: [magma] Destination address in v2 leave message

Hi,

=A0

=A0=A0=A0 Can anyone please tell me the disadvantage of using queriers= address as destination address in v2 leave message? Is there any advantage= =A0of sending it to 224.0.0.2? Non-querier never processes leave message an= yway.

=A0

Thanks,

Indranil

--001485f6d9fead352d04af3415c7-- From bharat_joshi@infosys.com Thu Oct 13 18:48:20 2011 Return-Path: X-Original-To: magma@ietfa.amsl.com Delivered-To: magma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDA7021F87C9 for ; Thu, 13 Oct 2011 18:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRNcQPAXFYVN for ; Thu, 13 Oct 2011 18:48:20 -0700 (PDT) Received: from KECGATE08.infosys.com (kecgate08.infosysconsulting.com [122.98.10.33]) by ietfa.amsl.com (Postfix) with ESMTP id 9378421F891D for ; Thu, 13 Oct 2011 18:48:13 -0700 (PDT) X-TM-IMSS-Message-ID: <5afc31b20006a6c1@infosys.com> Received: from blrkechub01.ad.infosys.com ([10.66.236.41]) by infosys.com ([122.98.10.33]) with ESMTP (TREND IMSS SMTP Service 7.1) id 5afc31b20006a6c1 ; Fri, 14 Oct 2011 07:24:48 +0530 Received: from blrkechub11.ad.infosys.com (10.66.236.46) by blrkechub01.ad.infosys.com (10.66.236.41) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 14 Oct 2011 07:16:57 +0530 Received: from BLRKECMBX02.ad.infosys.com ([10.66.236.22]) by blrkechub11.ad.infosys.com ([10.66.236.46]) with mapi; Fri, 14 Oct 2011 07:16:58 +0530 From: Bharat Joshi To: Stig Venaas , Thomas Morin Date: Fri, 14 Oct 2011 07:14:34 +0530 Thread-Topic: [magma] Question about IGMP host implementation Thread-Index: AcyJyuazYLcingQMRiuHIYzqj0oHcwAR+wXQ Message-ID: <31D55C4D55BEED48A4459EB64567589A1186EB24F0@BLRKECMBX02.ad.infosys.com> References: <4FD1E7CD248BF84F86BD4814EDDDBCC151401F3936@EUSAACMS0703.eamcs.ericsson.se> <31D55C4D55BEED48A4459EB64567589A1186EB24E9@BLRKECMBX02.ad.infosys.com>, <4FD1E7CD248BF84F86BD4814EDDDBCC151401F3B7A@EUSAACMS0703.eamcs.ericsson.se> <31D55C4D55BEED48A4459EB64567589A1186EB24EB@BLRKECMBX02.ad.infosys.com> <4E96A0C3.9010602@orange.com>,<4E971B82.2090508@venaas.com> In-Reply-To: <4E971B82.2090508@venaas.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "magma@ietf.org" Subject: Re: [magma] Question about IGMP host implementation X-BeenThere: magma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast and Anycast Group Membership List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 01:48:21 -0000 Stig, I think GTSM does solve the issue of forwarding IGMP messages but as= you mentioned its only for unicast. Till now, I have not seen any implementation using Unicast destinati= on address for IGMP messages. So I am not sure if someone will really be in= terested in this work. May be there are some legacy or customized implementation which I am= not aware of and we need to see if these people would be interested in thi= s., Regards, Bharat ________________________________________ From: magma-bounces@ietf.org [magma-bounces@ietf.org] On Behalf Of Stig Ven= aas [stig@venaas.com] Sent: Thursday, October 13, 2011 10:40 PM To: Thomas Morin Cc: magma@ietf.org Subject: Re: [magma] Question about IGMP host implementation On 10/13/2011 1:26 AM, Thomas Morin wrote: > Hi, > > Obviously there is no legitimate case where a query would come from > another subnet. > The question is how to avoiding such queries from being processed... > > IGMPv3 specs talks a bit about this aspect ; RFC3376, section 9.1, > Security Considerations, Query message: > > There are three measures necessary to defend against externally forged = Queries: > > o Routers SHOULD NOT forward Queries. This is easier for a router to > accomplish if the Query carries the Router-Alert option. > > o Hosts SHOULD ignore v2 or v3 Queries without the Router-Alert > option. > > o Hosts SHOULD ignore v1, v2 or v3 General Queries sent to a > multicast address other than 224.0.0.1, the all-systems address. > > If a host enforces these rules, AFAICT there is no case were it would > process a Query from another subnet. > Even though RFC2236 is silent on this aspect, an RFC3376 host > implementation in IGMPv2 compatibility mode would be expected to apply > these checks. > > On the other hand, RFC3376 also says, in 4.1.12. IP Destination > Addresses for Queries: > > In IGMPv3, General Queries are sent with an IP destination address of > 224.0.0.1, the all-systems multicast address. Group-Specific and > Group-and-Source-Specific Queries are sent with an IP destination > address equal to the multicast address of interest. *However*, a > system MUST accept and process any Query whose IP Destination Addres= s > ^^^^^^^^^^^^^^^ > field contains *any* of the addresses (unicast or multicast) > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > assigned to the interface on which the Query arrives. > > > This rule contradicts the third rule above (which would in itself > deserve a discussion), but the two first rules are possibly enough: if > an attacker forges a Query, under the assumption that at least one > Router on the path to the victim supports the Router Alert option and > implements IGMP and enforces the first of the three rules above, if > hosts apply the second rule, then no forged packet will be processed by > hosts... The issue is that it may not be reasonable to count on all this > to be true (eg. there are IGMP Querier implementations in the wild that > do not set the RA option in Query messages...). > > The most reasonable thing to do, as suggested below, is to drop Queries > whose source address is from another subnet. > > A nicer solution would be to apply GTSM (RFC5082) to IGMP, but > transitioning to it is absolutely not trivial. Yes, I have been thinking whether GTSM should be used for unicast IGMPv3 messages. I don't think transitioning to that is all that hard. It depends a bit how common it is to do unicast IGMP today. Checking GTSM on the receiving end would have to be something that can be configured until one can expect all senders to do it. If there is some support for GTSM, we could try a draft updating the IGMPv3 RFC perhaps... Stig > > -Thomas > > > > Bharat Joshi a =E9crit : >> Kunal, >> >> What I am suggesting is that though RFC does not explicitly sug= gest it, it might be better to do this for broadcast interfaces. >> >> But yes, RFC does not suggest anything on this so a host can pr= ocess a query message with a source address from any other subnet as well. >> >> Regards, >> Bharat >> ________________________________________ >> From: Kunal Shah [kunal.shah@ericsson.com] >> Sent: Wednesday, October 12, 2011 9:17 PM >> To: Bharat Joshi;magma@ietf.org >> Subject: RE: Question about IGMP host implementation >> >> Hi Bharat, >> >> The security consideration addresses the processing of a report from a d= ifferent subnet on the router. My question pertains to the processing of a = Query from a different subnet on the host. >> >> Kunal >> >> -----Original Message----- >> From: Bharat Joshi [mailto:bharat_joshi@infosys.com] >> Sent: Wednesday, October 12, 2011 4:20 AM >> To: Kunal Shah;magma@ietf.org >> Subject: RE: Question about IGMP host implementation >> >> Hi Kunal, >> >> I think to keep the security tight, it is better to not respond= to queries received from a source address which does not fall on a subnet = on that interface. Please note that this should be done only broadcast inte= rfaces. It may not work on point-to-point links. >> >> If you look at the security consideration in RFC 2236, it is me= ntioned that for reports, the above check should be done. >> >> Regards, >> Bharat >> ________________________________________ >> From:magma-bounces@ietf.org [magma-bounces@ietf.org] On Behalf Of Kunal= Shah [kunal.shah@ericsson.com] >> Sent: Wednesday, October 12, 2011 6:08 AM >> To:magma@ietf.org >> Subject: [magma] Question about IGMP host implementation >> >> Hi all, >> >> Can an IGMPv2 host respond to a general query originated from a subnet o= ther then its own?? RFC 2236 states: >> >> ""query received" occurs when the host receives either a valid >> General Membership Query message, or a valid Group-Specific >> Membership Query message. To be valid, the Query message must be >> at least 8 octets long, and have a correct IGMP checksum. The >> group address in the IGMP header must either be zero (a General >> Query) or a valid multicast group address (a Group-Specific Query)= " >> >> There is no requirement for the source address to be on the same subnet = as the host. >> >> Thanks, >> Kunal >> >> >> **************** CAUTION - Disclaimer ***************** This e-mail cont= ains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of= the addressee(s). If you are not the intended recipient, please notify the= sender by e-mail and delete the original message. Further, you are not to = copy, disclose, or distribute this e-mail or its contents to any other pers= on and any such actions are unlawful. This e-mail may contain viruses. Info= sys has taken every reasonable precaution to minimize this risk, but is not= liable for any damage you may sustain as a result of any virus in this e-m= ail. You should carry out your own virus checks before opening the e-mail o= r attachment. Infosys reserves the right to monitor and review the content = of all messages sent to or from this e-mail address. Messages sent to or fr= om this e-mail address may be stored on the Infosys e-mail system. >> ***INFOSYS******** End of Disclaimer ********INFOSYS*** >> _______________________________________________ >> magma mailing list >> magma@ietf.org >> https://www.ietf.org/mailman/listinfo/magma > > > > > _______________________________________________ > magma mailing list > magma@ietf.org > https://www.ietf.org/mailman/listinfo/magma _______________________________________________ magma mailing list magma@ietf.org https://www.ietf.org/mailman/listinfo/magma From bharat_joshi@infosys.com Thu Oct 13 18:56:33 2011 Return-Path: X-Original-To: magma@ietfa.amsl.com Delivered-To: magma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFAC121F8ACE for ; Thu, 13 Oct 2011 18:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRuRjQtLBGDo for ; Thu, 13 Oct 2011 18:56:33 -0700 (PDT) Received: from KECGATE08.infosys.com (kecgate08.infosysconsulting.com [122.98.10.33]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8ED21F8AD3 for ; Thu, 13 Oct 2011 18:56:32 -0700 (PDT) X-TM-IMSS-Message-ID: <5b03ef140006a724@infosys.com> Received: from blrkechub03.ad.infosys.com ([10.66.236.43]) by infosys.com ([122.98.10.33]) with ESMTP (TREND IMSS SMTP Service 7.1) id 5b03ef140006a724 ; Fri, 14 Oct 2011 07:33:15 +0530 Received: from BLRKECMBX02.ad.infosys.com ([10.66.236.22]) by blrkechub03.ad.infosys.com ([10.66.236.43]) with mapi; Fri, 14 Oct 2011 07:25:25 +0530 From: Bharat Joshi To: Indranil Bhattacharya , Kunal Shah Date: Fri, 14 Oct 2011 07:23:31 +0530 Thread-Topic: [magma] Destination address in v2 leave message Thread-Index: AcyJ54/SgXXV6IZLRFGSZKhHnbwv9wALIMG7 Message-ID: <31D55C4D55BEED48A4459EB64567589A1186EB24F1@BLRKECMBX02.ad.infosys.com> References: <4FD1E7CD248BF84F86BD4814EDDDBCC151402959E6@EUSAACMS0703.eamcs.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "magma@ietf.org" Subject: Re: [magma] Destination address in v2 leave message X-BeenThere: magma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast and Anycast Group Membership List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 01:56:33 -0000 Hi=20Kunal/Indranil, =20=20=20=20=20=20=20=20=20Leave=20message=20is=20sent=20to=20ALL-Routers= =20address=20because=20host=20does=20not=20keep=20track=20of=20the=20quer= ier. =20=20=20=20=20=20=20=20=20If=20host=20needs=20to=20keep=20track=20of=20q= uerier,=20it=20will=20have=20to=20implement=20querier=20election=20algori= thm=20and=20maintain=20a=20state=20with=20querier-timeout=20etc.=20which= =20is=20unnecessary. Regards, Bharat ________________________________________ From:=20magma-bounces@ietf.org=20[magma-bounces@ietf.org]=20On=20Behalf= =20Of=20Indranil=20Bhattacharya=20[myselfindranil@gmail.com] Sent:=20Friday,=20October=2014,=202011=202:05=20AM To:=20Kunal=20Shah Cc:=20magma@ietf.org Subject:=20Re:=20[magma]=20Destination=20address=20in=20v2=20leave=20mess= age Hi=20Kunal, =20=20=20=20=20=20=20=20=20=20=20=20Non-queriers=20lower=20the=20group=20= timers=20upon=20receiving=20group-specific=20query=20from=20querier.=20Th= ey=20always=20ignore=20leave=20messages.=20Please=20refer=20the=20last=20= state=20diagram=20in=20section=207=20which=20is=20for=20non-querier. Thanks, Indranil On=20Thu,=20Oct=2013,=202011=20at=2011:48=20PM,=20Kunal=20Shah=20>=20wrote: Non-querier=20does=20process=20the=20leave=20message.=20On=20receiving=20= a=20leave=20the=20non-querier=20is=20going=20to=20reduce=20the=20group=20= timer=20to=20[Max=20Response=20Time]=20in=20the=20packet=20*=20[Last=20Me= mber=20Query=20Count]=20but=20will=20not=20send=20the=20leave.=20Please= =20refer=20to=20section=207=20of=20RFC=202236. ________________________________ From:=20magma-bounces@ietf.org=20[mailto:m= agma-bounces@ietf.org]=20On=20Behalf=20Of= =20Indranil=20Bhattacharya Sent:=20Thursday,=20October=2013,=202011=2010:30=20AM To:=20magma@ietf.org Subject:=20[magma]=20Destination=20address=20in=20v2=20leave=20message Hi, =20=20=20=20Can=20anyone=20please=20tell=20me=20the=20disadvantage=20of= =20using=20queriers=20address=20as=20destination=20address=20in=20v2=20le= ave=20message?=20Is=20there=20any=20advantage=20of=20sending=20it=20to=20= 224.0.0.2?=20Non-querier=20never=20processes=20leave=20message=20anyway. Thanks, Indranil ****************=20CAUTION=20-=20Disclaimer=20***************** This=20e-mail=20contains=20PRIVILEGED=20AND=20CONFIDENTIAL=20INFORMATION= =20intended=20solely=20 for=20the=20use=20of=20the=20addressee(s).=20If=20you=20are=20not=20the= =20intended=20recipient,=20please=20 notify=20the=20sender=20by=20e-mail=20and=20delete=20the=20original=20mes= sage.=20Further,=20you=20are=20not=20 to=20copy,=20disclose,=20or=20distribute=20this=20e-mail=20or=20its=20con= tents=20to=20any=20other=20person=20and=20 any=20such=20actions=20are=20unlawful.=20This=20e-mail=20may=20contain=20= viruses.=20Infosys=20has=20taken=20 every=20reasonable=20precaution=20to=20minimize=20this=20risk,=20but=20is= =20not=20liable=20for=20any=20damage=20 you=20may=20sustain=20as=20a=20result=20of=20any=20virus=20in=20this=20e-= mail.=20You=20should=20carry=20out=20your=20 own=20virus=20checks=20before=20opening=20the=20e-mail=20or=20attachment.= =20Infosys=20reserves=20the=20 right=20to=20monitor=20and=20review=20the=20content=20of=20all=20messages= =20sent=20to=20or=20from=20this=20e-mail=20 address.=20Messages=20sent=20to=20or=20from=20this=20e-mail=20address=20m= ay=20be=20stored=20on=20the=20 Infosys=20e-mail=20system. ***INFOSYS********=20End=20of=20Disclaimer=20********INFOSYS*** From stig@venaas.com Thu Oct 13 19:43:27 2011 Return-Path: X-Original-To: magma@ietfa.amsl.com Delivered-To: magma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4040E21F8B7E for ; Thu, 13 Oct 2011 19:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKzdY00hsHxe for ; Thu, 13 Oct 2011 19:43:26 -0700 (PDT) Received: from ufisa.uninett.no (ufisa.uninett.no [IPv6:2001:700:1:2:158:38:152:126]) by ietfa.amsl.com (Postfix) with ESMTP id 1EFC821F8B33 for ; Thu, 13 Oct 2011 19:43:26 -0700 (PDT) Received: from [192.168.1.107] (c-67-170-194-177.hsd1.ca.comcast.net [67.170.194.177]) by ufisa.uninett.no (Postfix) with ESMTPSA id E5FD57FE2; Fri, 14 Oct 2011 04:43:21 +0200 (CEST) Message-ID: <4E97A191.3070800@venaas.com> Date: Thu, 13 Oct 2011 19:42:25 -0700 From: Stig Venaas User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Bharat Joshi References: <4FD1E7CD248BF84F86BD4814EDDDBCC151401F3936@EUSAACMS0703.eamcs.ericsson.se> <31D55C4D55BEED48A4459EB64567589A1186EB24E9@BLRKECMBX02.ad.infosys.com>, <4FD1E7CD248BF84F86BD4814EDDDBCC151401F3B7A@EUSAACMS0703.eamcs.ericsson.se> <31D55C4D55BEED48A4459EB64567589A1186EB24EB@BLRKECMBX02.ad.infosys.com> <4E96A0C3.9010602@orange.com>, <4E971B82.2090508@venaas.com> <31D55C4D55BEED48A4459EB64567589A1186EB24F0@BLRKECMBX02.ad.infosys.com> In-Reply-To: <31D55C4D55BEED48A4459EB64567589A1186EB24F0@BLRKECMBX02.ad.infosys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Thomas Morin , "magma@ietf.org" Subject: Re: [magma] Question about IGMP host implementation X-BeenThere: magma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast and Anycast Group Membership List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 02:43:27 -0000 On 13.10.2011 18:44, Bharat Joshi wrote: > Stig, > > I think GTSM does solve the issue of forwarding IGMP messages but as you mentioned its only for unicast. > > Till now, I have not seen any implementation using Unicast destination address for IGMP messages. So I am not sure if someone will really be interested in this work. > > May be there are some legacy or customized implementation which I am not aware of and we need to see if these people would be interested in this., I know one implementation at least. But note that even if no one sends them, the RFC says they should be accepted. So we do have a problem if someone intentionally spoofs unicast packet. If almost no one sends them, then changing to GTSM will be easier. Stig > Regards, > Bharat > ________________________________________ > From: magma-bounces@ietf.org [magma-bounces@ietf.org] On Behalf Of Stig Venaas [stig@venaas.com] > Sent: Thursday, October 13, 2011 10:40 PM > To: Thomas Morin > Cc: magma@ietf.org > Subject: Re: [magma] Question about IGMP host implementation > > On 10/13/2011 1:26 AM, Thomas Morin wrote: >> Hi, >> >> Obviously there is no legitimate case where a query would come from >> another subnet. >> The question is how to avoiding such queries from being processed... >> >> IGMPv3 specs talks a bit about this aspect ; RFC3376, section 9.1, >> Security Considerations, Query message: >> >> There are three measures necessary to defend against externally forged Queries: >> >> o Routers SHOULD NOT forward Queries. This is easier for a router to >> accomplish if the Query carries the Router-Alert option. >> >> o Hosts SHOULD ignore v2 or v3 Queries without the Router-Alert >> option. >> >> o Hosts SHOULD ignore v1, v2 or v3 General Queries sent to a >> multicast address other than 224.0.0.1, the all-systems address. >> >> If a host enforces these rules, AFAICT there is no case were it would >> process a Query from another subnet. >> Even though RFC2236 is silent on this aspect, an RFC3376 host >> implementation in IGMPv2 compatibility mode would be expected to apply >> these checks. >> >> On the other hand, RFC3376 also says, in 4.1.12. IP Destination >> Addresses for Queries: >> >> In IGMPv3, General Queries are sent with an IP destination address of >> 224.0.0.1, the all-systems multicast address. Group-Specific and >> Group-and-Source-Specific Queries are sent with an IP destination >> address equal to the multicast address of interest. *However*, a >> system MUST accept and process any Query whose IP Destination Address >> ^^^^^^^^^^^^^^^ >> field contains *any* of the addresses (unicast or multicast) >> ^^^^^^^^^^^^^^^^^^^^^^^^^^ >> assigned to the interface on which the Query arrives. >> >> >> This rule contradicts the third rule above (which would in itself >> deserve a discussion), but the two first rules are possibly enough: if >> an attacker forges a Query, under the assumption that at least one >> Router on the path to the victim supports the Router Alert option and >> implements IGMP and enforces the first of the three rules above, if >> hosts apply the second rule, then no forged packet will be processed by >> hosts... The issue is that it may not be reasonable to count on all this >> to be true (eg. there are IGMP Querier implementations in the wild that >> do not set the RA option in Query messages...). >> >> The most reasonable thing to do, as suggested below, is to drop Queries >> whose source address is from another subnet. >> >> A nicer solution would be to apply GTSM (RFC5082) to IGMP, but >> transitioning to it is absolutely not trivial. > > Yes, I have been thinking whether GTSM should be used for unicast IGMPv3 > messages. I don't think transitioning to that is all that hard. It > depends a bit how common it is to do unicast IGMP today. Checking GTSM > on the receiving end would have to be something that can be configured > until one can expect all senders to do it. > > If there is some support for GTSM, we could try a draft updating the > IGMPv3 RFC perhaps... > > Stig > >> >> -Thomas >> >> >> >> Bharat Joshi a �crit : >>> Kunal, >>> >>> What I am suggesting is that though RFC does not explicitly suggest it, it might be better to do this for broadcast interfaces. >>> >>> But yes, RFC does not suggest anything on this so a host can process a query message with a source address from any other subnet as well. >>> >>> Regards, >>> Bharat >>> ________________________________________ >>> From: Kunal Shah [kunal.shah@ericsson.com] >>> Sent: Wednesday, October 12, 2011 9:17 PM >>> To: Bharat Joshi;magma@ietf.org >>> Subject: RE: Question about IGMP host implementation >>> >>> Hi Bharat, >>> >>> The security consideration addresses the processing of a report from a different subnet on the router. My question pertains to the processing of a Query from a different subnet on the host. >>> >>> Kunal >>> >>> -----Original Message----- >>> From: Bharat Joshi [mailto:bharat_joshi@infosys.com] >>> Sent: Wednesday, October 12, 2011 4:20 AM >>> To: Kunal Shah;magma@ietf.org >>> Subject: RE: Question about IGMP host implementation >>> >>> Hi Kunal, >>> >>> I think to keep the security tight, it is better to not respond to queries received from a source address which does not fall on a subnet on that interface. Please note that this should be done only broadcast interfaces. It may not work on point-to-point links. >>> >>> If you look at the security consideration in RFC 2236, it is mentioned that for reports, the above check should be done. >>> >>> Regards, >>> Bharat >>> ________________________________________ >>> From:magma-bounces@ietf.org [magma-bounces@ietf.org] On Behalf Of Kunal Shah [kunal.shah@ericsson.com] >>> Sent: Wednesday, October 12, 2011 6:08 AM >>> To:magma@ietf.org >>> Subject: [magma] Question about IGMP host implementation >>> >>> Hi all, >>> >>> Can an IGMPv2 host respond to a general query originated from a subnet other then its own?? RFC 2236 states: >>> >>> ""query received" occurs when the host receives either a valid >>> General Membership Query message, or a valid Group-Specific >>> Membership Query message. To be valid, the Query message must be >>> at least 8 octets long, and have a correct IGMP checksum. The >>> group address in the IGMP header must either be zero (a General >>> Query) or a valid multicast group address (a Group-Specific Query)" >>> >>> There is no requirement for the source address to be on the same subnet as the host. >>> >>> Thanks, >>> Kunal >>> >>> >>> **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. >>> ***INFOSYS******** End of Disclaimer ********INFOSYS*** >>> _______________________________________________ >>> magma mailing list >>> magma@ietf.org >>> https://www.ietf.org/mailman/listinfo/magma >> >> >> >> >> _______________________________________________ >> magma mailing list >> magma@ietf.org >> https://www.ietf.org/mailman/listinfo/magma > > _______________________________________________ > magma mailing list > magma@ietf.org > https://www.ietf.org/mailman/listinfo/magma From myselfindranil@gmail.com Thu Oct 13 20:13:06 2011 Return-Path: X-Original-To: magma@ietfa.amsl.com Delivered-To: magma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4CA21F8BF4 for ; Thu, 13 Oct 2011 20:13:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.352 X-Spam-Level: X-Spam-Status: No, score=-3.352 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sy1Nzm2XJSVi for ; Thu, 13 Oct 2011 20:13:05 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 51AF321F8C06 for ; Thu, 13 Oct 2011 20:13:05 -0700 (PDT) Received: by wwf22 with SMTP id 22so1908738wwf.13 for ; Thu, 13 Oct 2011 20:13:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YNqLIzOHf947L+AXO+Ouk4bOdGW+FZGEZaWdlAKEmF8=; b=mMoWtTYWOaXc94Wh5dAdLGeO2y+yGaZQtGBHLq11/vd0mQsBbiW+hynd1aDY+QyThQ tRAJfRZMpx3mOl5NcNYVSKIrKyNS9JZjTiUh477TdcL4QwsSVaYXDFFX2mXmdvvCt/lZ AMY72DQXCCoAY12eU/PWS65JD0kkzvunw7i88= MIME-Version: 1.0 Received: by 10.216.230.37 with SMTP id i37mr2235955weq.34.1318561984224; Thu, 13 Oct 2011 20:13:04 -0700 (PDT) Received: by 10.216.39.80 with HTTP; Thu, 13 Oct 2011 20:13:04 -0700 (PDT) In-Reply-To: <31D55C4D55BEED48A4459EB64567589A1186EB24F1@BLRKECMBX02.ad.infosys.com> References: <4FD1E7CD248BF84F86BD4814EDDDBCC151402959E6@EUSAACMS0703.eamcs.ericsson.se> <31D55C4D55BEED48A4459EB64567589A1186EB24F1@BLRKECMBX02.ad.infosys.com> Date: Fri, 14 Oct 2011 08:43:04 +0530 Message-ID: From: Indranil Bhattacharya To: Bharat Joshi Content-Type: multipart/alternative; boundary=0016e643452caf1fe604af39a207 Cc: "magma@ietf.org" Subject: Re: [magma] Destination address in v2 leave message X-BeenThere: magma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast and Anycast Group Membership List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 03:13:06 -0000 --0016e643452caf1fe604af39a207 Content-Type: text/plain; charset=ISO-8859-1 Thanks Bharat. - Indranil On Fri, Oct 14, 2011 at 7:23 AM, Bharat Joshi wrote: > Hi Kunal/Indranil, > > Leave message is sent to ALL-Routers address because host does not > keep track of the querier. > > If host needs to keep track of querier, it will have to implement > querier election algorithm and maintain a state with querier-timeout etc. > which is unnecessary. > > Regards, > Bharat > ________________________________________ > From: magma-bounces@ietf.org [magma-bounces@ietf.org] On Behalf Of > Indranil Bhattacharya [myselfindranil@gmail.com] > Sent: Friday, October 14, 2011 2:05 AM > To: Kunal Shah > Cc: magma@ietf.org > Subject: Re: [magma] Destination address in v2 leave message > > Hi Kunal, > > Non-queriers lower the group timers upon receiving > group-specific query from querier. They always ignore leave messages. Please > refer the last state diagram in section 7 which is for non-querier. > > Thanks, > Indranil > > On Thu, Oct 13, 2011 at 11:48 PM, Kunal Shah > wrote: > Non-querier does process the leave message. On receiving a leave the > non-querier is going to reduce the group timer to [Max Response Time] in the > packet * [Last Member Query Count] but will not send the leave. Please refer > to section 7 of RFC 2236. > > ________________________________ > From: magma-bounces@ietf.org [mailto: > magma-bounces@ietf.org] On Behalf Of > Indranil Bhattacharya > Sent: Thursday, October 13, 2011 10:30 AM > To: magma@ietf.org > Subject: [magma] Destination address in v2 leave message > > Hi, > > Can anyone please tell me the disadvantage of using queriers address as > destination address in v2 leave message? Is there any advantage of sending > it to 224.0.0.2? Non-querier never processes leave message anyway. > > Thanks, > Indranil > > > **************** CAUTION - Disclaimer ***************** > This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended > solely > for the use of the addressee(s). If you are not the intended recipient, > please > notify the sender by e-mail and delete the original message. Further, you > are not > to copy, disclose, or distribute this e-mail or its contents to any other > person and > any such actions are unlawful. This e-mail may contain viruses. Infosys has > taken > every reasonable precaution to minimize this risk, but is not liable for > any damage > you may sustain as a result of any virus in this e-mail. You should carry > out your > own virus checks before opening the e-mail or attachment. Infosys reserves > the > right to monitor and review the content of all messages sent to or from > this e-mail > address. Messages sent to or from this e-mail address may be stored on the > Infosys e-mail system. > ***INFOSYS******** End of Disclaimer ********INFOSYS*** > --0016e643452caf1fe604af39a207 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Bharat.

=A0

- Indranil

On Fri, Oct 14, 2011 at 7:23 AM, Bharat Joshi <bharat_josh= i@infosys.com> wrote:

Hi Kunal/Indranil,

=A0 = =A0 =A0 =A0 Leave message is sent to ALL-Routers address because host does = not keep track of the querier.

=A0 =A0 =A0 =A0 If host needs to keep track of querier, it will have to= implement querier election algorithm and maintain a state with querier-tim= eout etc. which is unnecessary.

Regards,
Bharat
______________= __________________________
From: magma-bounces@ietf.org = [magma-bounces@ietf.org] On B= ehalf Of Indranil Bhattacharya [myselfindranil@gmail.com]
Sent: Friday, October 14, 2011 2:05 AM
To: Kunal Shah
Cc: magma@ietf.org
Subject: Re: [magma] Destinati= on address in v2 leave message

Hi Kunal,

=A0 =A0 =A0 =A0 =A0 =A0Non-queriers = lower the group timers upon receiving group-specific query from querier. Th= ey always ignore leave messages. Please refer the last state diagram in sec= tion 7 which is for non-querier.

Thanks,
Indranil

On Thu, Oct 13, 2011 at 11:48 PM, Kunal Shah <kunal.shah@ericsson.com<mailto:<= a href=3D"mailto:kunal.shah@ericsson.com">kunal.shah@ericsson.com>&g= t; wrote:
Non-querier does process the leave message. On receiving a leave the non-qu= erier is going to reduce the group timer to [Max Response Time] in the pack= et * [Last Member Query Count] but will not send the leave. Please refer to= section 7 of RFC 2236.

________________________________
From: magma-bounces@ietf.org<mailto:magma-bounces@ietf.org> [mailto:magma-bounces@ietf.org<mailto:magma-bounces@ietf.org>] On Behal= f Of Indranil Bhattacharya

Sent: Thursday, October 13, 2011 10:30 AM
To: magma@ietf.org<mailto:magma@ietf.org>

Subject: [magma] Destination address in v2 leave message<= br>
Hi,

=A0 =A0Can anyone please tell me the disadvantage of usin= g queriers address as destination address in v2 leave message? Is there any= advantage of sending it to 224.0.0.2? Non-querier never processes leave me= ssage anyway.

Thanks,
Indranil

**************** CAUTION - Disclai= mer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL I= NFORMATION intended solely
for the use of the addressee(s). If you are n= ot the intended recipient, please
notify the sender by e-mail and delete the original message. Further, you a= re not
to copy, disclose, or distribute this e-mail or its contents to a= ny other person and
any such actions are unlawful. This e-mail may conta= in viruses. Infosys has taken
every reasonable precaution to minimize this risk, but is not liable for an= y damage
you may sustain as a result of any virus in this e-mail. You sh= ould carry out your
own virus checks before opening the e-mail or attach= ment. Infosys reserves the
right to monitor and review the content of all messages sent to or from thi= s e-mail
address. Messages sent to or from this e-mail address may be st= ored on the
Infosys e-mail system.
***INFOSYS******** End of Disclaim= er ********INFOSYS***

--0016e643452caf1fe604af39a207-- From asaeda@sfc.wide.ad.jp Thu Oct 13 20:30:39 2011 Return-Path: X-Original-To: magma@ietfa.amsl.com Delivered-To: magma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C21D221F8C0D for ; Thu, 13 Oct 2011 20:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.096 X-Spam-Level: X-Spam-Status: No, score=-99.096 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBP7QUo4kjXU for ; Thu, 13 Oct 2011 20:30:39 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id 4036D21F8C0B for ; Thu, 13 Oct 2011 20:30:38 -0700 (PDT) Received: from localhost (p16206-ipngn201hodogaya.kanagawa.ocn.ne.jp [114.175.255.206]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 3957A27809F; Fri, 14 Oct 2011 12:30:06 +0900 (JST) Date: Fri, 14 Oct 2011 12:30:05 +0900 (JST) Message-Id: <20111014.123005.235216170.asaeda@sfc.wide.ad.jp> To: bharat_joshi@infosys.com From: Hitoshi Asaeda In-Reply-To: <31D55C4D55BEED48A4459EB64567589A1186EB24F1@BLRKECMBX02.ad.infosys.com> References: <4FD1E7CD248BF84F86BD4814EDDDBCC151402959E6@EUSAACMS0703.eamcs.ericsson.se> <31D55C4D55BEED48A4459EB64567589A1186EB24F1@BLRKECMBX02.ad.infosys.com> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: magma@ietf.org Subject: Re: [magma] Destination address in v2 leave message X-BeenThere: magma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast and Anycast Group Membership List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 03:30:39 -0000 Hi, > Leave message is sent to ALL-Routers address because host > does not keep track of the querier. > > If host needs to keep track of querier, it will have to > implement querier election algorithm and maintain a state with > querier-timeout etc. which is unnecessary. And also, querier is not always forwarder. Regards, -- Hitoshi Asaeda From asaeda@sfc.wide.ad.jp Thu Oct 13 20:38:13 2011 Return-Path: X-Original-To: magma@ietfa.amsl.com Delivered-To: magma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D3421F8C04 for ; Thu, 13 Oct 2011 20:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.096 X-Spam-Level: X-Spam-Status: No, score=-99.096 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S+lbjRVCBV9J for ; Thu, 13 Oct 2011 20:38:13 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id 108D521F8B38 for ; Thu, 13 Oct 2011 20:38:12 -0700 (PDT) Received: from localhost (p16206-ipngn201hodogaya.kanagawa.ocn.ne.jp [114.175.255.206]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 7EF41278097; Fri, 14 Oct 2011 12:37:41 +0900 (JST) Date: Fri, 14 Oct 2011 12:37:40 +0900 (JST) Message-Id: <20111014.123740.41797110.asaeda@sfc.wide.ad.jp> To: stig@venaas.com From: Hitoshi Asaeda In-Reply-To: <4E97A191.3070800@venaas.com> References: <4E971B82.2090508@venaas.com> <31D55C4D55BEED48A4459EB64567589A1186EB24F0@BLRKECMBX02.ad.infosys.com> <4E97A191.3070800@venaas.com> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: thomas.morin@orange.com, magma@ietf.org Subject: Re: [magma] Question about IGMP host implementation X-BeenThere: magma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast and Anycast Group Membership List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 03:38:13 -0000 >> I think GTSM does solve the issue of forwarding IGMP messages but as >> you mentioned its only for unicast. >> >> Till now, I have not seen any implementation using Unicast >> destination address for IGMP messages. So I am not sure if someone >> will really be interested in this work. >> >> May be there are some legacy or customized implementation which I am >> not aware of and we need to see if these people would be interested >> in this., > > I know one implementation at least. But note that even if no one sends > them, the RFC says they should be accepted. So we do have a problem if > someone intentionally spoofs unicast packet. > > If almost no one sends them, then changing to GTSM will be easier. I think using unicast query is not well defined and considered in rfc3376 and 3810. Although it would be useful for some environment, e.g. resource sensitive wireless link, it may cause some security concern. And also, unicast query is not used standalone. Multicast query must be also coexist. Please check Appendix A. in; http://tools.ietf.org/html/draft-ietf-multimob-igmp-mld-tuning-01 Regards, -- Hitoshi Asaeda p.s. I'd appreciate any comment for above draft. Please post your comment to the multimob ML if you have. From deepak.kudachi@hp.com Thu Oct 13 20:58:18 2011 Return-Path: X-Original-To: magma@ietfa.amsl.com Delivered-To: magma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B07E21F8B70 for ; Thu, 13 Oct 2011 20:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTHNL720D+iZ for ; Thu, 13 Oct 2011 20:58:17 -0700 (PDT) Received: from g1t0029.austin.hp.com (g1t0029.austin.hp.com [15.216.28.36]) by ietfa.amsl.com (Postfix) with ESMTP id DE96821F8B53 for ; Thu, 13 Oct 2011 20:58:16 -0700 (PDT) Received: from G6W1798G.americas.hpqcorp.net (g6w1798g.atlanta.hp.com [16.230.17.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g1t0029.austin.hp.com (Postfix) with ESMTPS id 24DB938273; Fri, 14 Oct 2011 03:58:16 +0000 (UTC) Received: from G4W3200G.americas.hpqcorp.net (16.234.105.236) by G6W1798G.americas.hpqcorp.net (16.230.17.175) with Microsoft SMTP Server (TLS) id 14.1.289.1; Fri, 14 Oct 2011 03:56:39 +0000 Received: from G4W3218.americas.hpqcorp.net ([169.254.10.199]) by G4W3200G.americas.hpqcorp.net ([16.234.105.236]) with mapi id 14.01.0289.001; Fri, 14 Oct 2011 03:56:38 +0000 From: "Kudachi, Deepak S" To: Indranil Bhattacharya , Kunal Shah Thread-Topic: [magma] Destination address in v2 leave message Thread-Index: AQHMic3S15a2BsO/t068aNHNr/84BJV6lVmAgAAmZoCAAHo9kA== Date: Fri, 14 Oct 2011 03:56:37 +0000 Message-ID: References: <4FD1E7CD248BF84F86BD4814EDDDBCC151402959E6@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [16.216.12.10] Content-Type: multipart/alternative; boundary="_000_A73087BEA2747741B7965ACF956E5004036635G4W3218americashp_" MIME-Version: 1.0 Cc: "magma@ietf.org" Subject: Re: [magma] Destination address in v2 leave message X-BeenThere: magma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast and Anycast Group Membership List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 03:58:18 -0000 --_000_A73087BEA2747741B7965ACF956E5004036635G4W3218americashp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi kunal, If you are tracking querier's then I guess there should not be any issue in= sending it Towards querier only. Again it is implementation dependent. Thanks and Regards Deepak From: magma-bounces@ietf.org [mailto:magma-bounces@ietf.org] On Behalf Of I= ndranil Bhattacharya Sent: Friday, October 14, 2011 2:06 AM To: Kunal Shah Cc: magma@ietf.org Subject: Re: [magma] Destination address in v2 leave message Hi Kunal, Non-queriers lower the group timers upon receiving group-specif= ic query from querier. They always ignore leave messages. Please refer the = last state diagram in section 7 which is for non-querier. Thanks, Indranil On Thu, Oct 13, 2011 at 11:48 PM, Kunal Shah > wrote: Non-querier does process the leave message. On receiving a leave the non-qu= erier is going to reduce the group timer to [Max Response Time] in the pack= et * [Last Member Query Count] but will not send the leave. Please refer to= section 7 of RFC 2236. ________________________________ From: magma-bounces@ietf.org [mailto:magma-b= ounces@ietf.org] On Behalf Of Indranil Bhatt= acharya Sent: Thursday, October 13, 2011 10:30 AM To: magma@ietf.org Subject: [magma] Destination address in v2 leave message Hi, Can anyone please tell me the disadvantage of using queriers address as= destination address in v2 leave message? Is there any advantage of sending= it to 224.0.0.2? Non-querier never processes leave message anyway. Thanks, Indranil --_000_A73087BEA2747741B7965ACF956E5004036635G4W3218americashp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi kunal,

<= /p>
If you are tracking queri= er’s then I guess there should not be any issue in sending it

Towards querier only.

<= /p>
Again it is implementatio= n dependent.

<= /p>
Thanks and Regards

Deepak<= /p>
<= /p>

From: magma-bo= unces@ietf.org [mailto:magma-bounces@ietf.org] On Behalf Of Indranil Bhattacharya
Sent: Friday, October 14, 2011 2:06 AM
To: Kunal Shah
Cc: magma@ietf.org
Subject: Re: [magma] Destination address in v2 leave message

Hi Kunal,

        &nbs= p;   Non-queriers lower the group timers upon receiving group-spe= cific query from querier. They always ignore leave messages. Please refer t= he last state diagram in section 7 which is for non-querier.

Thanks,

Indranil

On Thu, Oct 13, 2011 at 11:48 PM, Kunal Shah <kunal.shah@ericsson.com> wro= te:

Non-querier does process the l= eave message. On receiving a leave the non-querier is going to reduce the g= roup timer to [Max Response Time] in the packet * [Last Member Query Count] but will not send the leave. Please refer to section 7= of RFC 2236.

From:<= /span> magma-bounces@i= etf.org [mailto:magma-bounces@ietf.org] On Behalf Of Indranil Bhattacharya
Sent: Thursday, October 13, 2011 10:30 AM
To: magma@ietf.o= rg
Subject: [magma] Destination address in v2 leave message=

Hi,

    Can anyone please tell me the dis= advantage of using queriers address as destination address in v2 leave mess= age? Is there any advantage of sending it to 224.0.0.2? Non-querier ne= ver processes leave message anyway.

Thanks,

Indranil

--_000_A73087BEA2747741B7965ACF956E5004036635G4W3218americashp_-- From bharat_joshi@infosys.com Thu Oct 13 21:49:40 2011 Return-Path: X-Original-To: magma@ietfa.amsl.com Delivered-To: magma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55C6421F8C04 for ; Thu, 13 Oct 2011 21:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPiYAO7sDc5x for ; Thu, 13 Oct 2011 21:49:39 -0700 (PDT) Received: from kecgate02.infosys.com (kecgate02.infosys.com [122.98.14.32]) by ietfa.amsl.com (Postfix) with ESMTP id EC3DB21F8BF9 for ; Thu, 13 Oct 2011 21:49:38 -0700 (PDT) X-TM-IMSS-Message-ID: <026ae3f9000012de@infosys.com> Received: from blrkechub02.ad.infosys.com ([10.66.236.42]) by infosys.com ([122.98.14.32]) with ESMTP (TREND IMSS SMTP Service 7.1) id 026ae3f9000012de ; Fri, 14 Oct 2011 10:19:34 +0530 Received: from BLRKECHUB05.ad.infosys.com (10.66.236.45) by blrkechub02.ad.infosys.com (10.66.236.42) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 14 Oct 2011 10:18:26 +0530 Received: from BLRKECMBX02.ad.infosys.com ([10.66.236.22]) by BLRKECHUB05.ad.infosys.com ([10.66.236.45]) with mapi; Fri, 14 Oct 2011 10:18:26 +0530 From: Bharat Joshi To: Hitoshi Asaeda Date: Fri, 14 Oct 2011 10:14:01 +0530 Thread-Topic: [magma] Destination address in v2 leave message Thread-Index: AcyKIW3XItnzqpHCRj6eOlvwtEsZ7AACnbPO Message-ID: <31D55C4D55BEED48A4459EB64567589A1186EB24F2@BLRKECMBX02.ad.infosys.com> References: <4FD1E7CD248BF84F86BD4814EDDDBCC151402959E6@EUSAACMS0703.eamcs.ericsson.se> <31D55C4D55BEED48A4459EB64567589A1186EB24F1@BLRKECMBX02.ad.infosys.com>, <20111014.123005.235216170.asaeda@sfc.wide.ad.jp> In-Reply-To: <20111014.123005.235216170.asaeda@sfc.wide.ad.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "magma@ietf.org" Subject: Re: [magma] Destination address in v2 leave message X-BeenThere: magma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast and Anycast Group Membership List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 04:49:40 -0000 Hi=20Hitoshi, =20=20=20=20=20=20=20=20=20Yes.=20Querier=20need=20not=20be=20a=20multica= st=20data=20forwarder.=20But=20are=20you=20suggesting=20that=20a=20forwar= der=20who=20is=20not=20a=20IGMP=20querier=20process=20the=20leave=20messa= ge?=20If=20yes,=20what=20action=20do=20they=20take? =20=20=20=20=20=20=20=20=20As=20per=20RFC=202236,=20non-querier=20should= =20be=20using=20group=20specific=20queries=20to=20lower=20down=20the=20gr= oup=20timer=20instead=20of=20leave=20messages. Regards, Bharat PS:=20Sorry=20for=20not=20able=20to=20reply=20inline. ________________________________________ From:=20Hitoshi=20Asaeda=20[asaeda@sfc.wide.ad.jp] Sent:=20Friday,=20October=2014,=202011=209:00=20AM To:=20Bharat=20Joshi Cc:=20myselfindranil@gmail.com;=20magma@ietf.org Subject:=20Re:=20[magma]=20Destination=20address=20in=20v2=20leave=20mess= age Hi, >=20=20=20=20=20=20=20=20=20=20Leave=20message=20is=20sent=20to=20ALL-Rou= ters=20address=20because=20host >=20does=20not=20keep=20track=20of=20the=20querier. > >=20=20=20=20=20=20=20=20=20=20If=20host=20needs=20to=20keep=20track=20of= =20querier,=20it=20will=20have=20to >=20implement=20querier=20election=20algorithm=20and=20maintain=20a=20sta= te=20with >=20querier-timeout=20etc.=20which=20is=20unnecessary. And=20also,=20querier=20is=20not=20always=20forwarder. Regards, -- Hitoshi=20Asaeda ****************=20CAUTION=20-=20Disclaimer=20***************** This=20e-mail=20contains=20PRIVILEGED=20AND=20CONFIDENTIAL=20INFORMATION= =20intended=20solely=20 for=20the=20use=20of=20the=20addressee(s).=20If=20you=20are=20not=20the= =20intended=20recipient,=20please=20 notify=20the=20sender=20by=20e-mail=20and=20delete=20the=20original=20mes= sage.=20Further,=20you=20are=20not=20 to=20copy,=20disclose,=20or=20distribute=20this=20e-mail=20or=20its=20con= tents=20to=20any=20other=20person=20and=20 any=20such=20actions=20are=20unlawful.=20This=20e-mail=20may=20contain=20= viruses.=20Infosys=20has=20taken=20 every=20reasonable=20precaution=20to=20minimize=20this=20risk,=20but=20is= =20not=20liable=20for=20any=20damage=20 you=20may=20sustain=20as=20a=20result=20of=20any=20virus=20in=20this=20e-= mail.=20You=20should=20carry=20out=20your=20 own=20virus=20checks=20before=20opening=20the=20e-mail=20or=20attachment.= =20Infosys=20reserves=20the=20 right=20to=20monitor=20and=20review=20the=20content=20of=20all=20messages= =20sent=20to=20or=20from=20this=20e-mail=20 address.=20Messages=20sent=20to=20or=20from=20this=20e-mail=20address=20m= ay=20be=20stored=20on=20the=20 Infosys=20e-mail=20system. ***INFOSYS********=20End=20of=20Disclaimer=20********INFOSYS*** From thomas.morin@orange.com Fri Oct 14 01:01:32 2011 Return-Path: X-Original-To: magma@ietfa.amsl.com Delivered-To: magma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5FE921F8ABB for ; Fri, 14 Oct 2011 01:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ccUUlaRCYd1e for ; Fri, 14 Oct 2011 01:01:32 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id DB48521F84D7 for ; Fri, 14 Oct 2011 01:01:31 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 98B79858002; Fri, 14 Oct 2011 10:11:10 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 906EA858001; Fri, 14 Oct 2011 10:11:10 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Oct 2011 10:01:30 +0200 Received: from [10.193.71.92] ([10.193.71.92]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 14 Oct 2011 10:01:29 +0200 Message-ID: <4E97EC5A.5020400@orange.com> Date: Fri, 14 Oct 2011 10:01:30 +0200 From: Thomas Morin Organization: France Telecom Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Hitoshi Asaeda References: <4E971B82.2090508@venaas.com> <31D55C4D55BEED48A4459EB64567589A1186EB24F0@BLRKECMBX02.ad.infosys.com> <4E97A191.3070800@venaas.com> <20111014.123740.41797110.asaeda@sfc.wide.ad.jp> In-Reply-To: <20111014.123740.41797110.asaeda@sfc.wide.ad.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Oct 2011 08:01:29.0633 (UTC) FILETIME=[7AE96910:01CC8A47] Cc: stig@venaas.com, magma@ietf.org Subject: Re: [magma] Question about IGMP host implementation X-BeenThere: magma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast and Anycast Group Membership List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 08:01:32 -0000 2011-10-14, Hitoshi Asaeda: >Stig: >>Barat: >>> I think GTSM does solve the issue of forwarding IGMP messages but as >>> you mentioned its only for unicast. >>> >>> Till now, I have not seen any implementation using Unicast >>> destination address for IGMP messages. So I am not sure if someone >>> will really be interested in this work. >>> >>> May be there are some legacy or customized implementation which I am >>> not aware of and we need to see if these people would be interested >>> in this., >> >> I know one implementation at least. But note that even if no one sends >> them, the RFC says they should be accepted. So we do have a problem if >> someone intentionally spoofs unicast packet. >> >> If almost no one sends them, then changing to GTSM will be easier. > > I think using unicast query is not well defined and considered in > rfc3376 and 3810. It may or may not be the same as the one Stig knows, but I also know about one equipment that has a useful feature that relies on this. > Although it would be useful for some environment, e.g. resource > sensitive wireless link, it may cause some security concern. Well, even if no Querier would use it, an IGMP host implementation may accept them. So it seems to me that working on this issue, or even encouraging the use of unicasted Queries, does not make any problem worse. Documenting how to do GTSM with IGMP would somehow improve security. > And also, unicast query is not used standalone. Multicast query must be also > coexist. > There are context where you could use only unicasted Queries. -Thomas From magesh.v@alcatel-lucent.com Tue Oct 11 22:23:10 2011 Return-Path: X-Original-To: magma@ietfa.amsl.com Delivered-To: magma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 362CD21F8BF8 for ; Tue, 11 Oct 2011 22:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1qS+tbSEIy0 for ; Tue, 11 Oct 2011 22:23:09 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2F521F8B34 for ; Tue, 11 Oct 2011 22:23:08 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p9C5MxdG025748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 12 Oct 2011 00:23:02 -0500 (CDT) Received: from INBANSXCHHUB03.in.alcatel-lucent.com (inbansxchhub03.in.alcatel-lucent.com [135.250.12.80]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p9C5Mxsx009498 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 12 Oct 2011 10:52:59 +0530 Received: from INBANSXCHMBSA2.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB03.in.alcatel-lucent.com ([135.250.12.80]) with mapi; Wed, 12 Oct 2011 10:52:58 +0530 From: "V, Magesh (Magesh)" To: Kunal Shah , "magma@ietf.org" Date: Wed, 12 Oct 2011 10:52:58 +0530 Thread-Topic: Question about IGMP host implementation Thread-Index: AcyId0SCeinZjfcnSnCOOiiZpocqFgAJwdKw Message-ID: <05D3B4AA7527D74EBF4921238463575321641601BA@INBANSXCHMBSA2.in.alcatel-lucent.com> References: <4FD1E7CD248BF84F86BD4814EDDDBCC151401F3936@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <4FD1E7CD248BF84F86BD4814EDDDBCC151401F3936@EUSAACMS0703.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_05D3B4AA7527D74EBF4921238463575321641601BAINBANSXCHMBSA_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Mailman-Approved-At: Fri, 14 Oct 2011 07:27:27 -0700 Subject: Re: [magma] Question about IGMP host implementation X-BeenThere: magma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast and Anycast Group Membership List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 05:23:10 -0000 --_000_05D3B4AA7527D74EBF4921238463575321641601BAINBANSXCHMBSA_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To the best of my knowledge the host does not care about the source-ip of t= he query for it to respond. I've seen this work always. OTOH, the igmp router needs to do this check for the reports received becau= se they come from the untrusted side of the n/w. Thanks, Magesh. ________________________________ From: magma-bounces@ietf.org [mailto:magma-bounces@ietf.org] On Behalf Of K= unal Shah Sent: Wednesday, October 12, 2011 6:09 AM To: magma@ietf.org Subject: [magma] Question about IGMP host implementation Hi all, Can an IGMPv2 host respond to a general query originated from a subnet othe= r then its own?? RFC 2236 states: ""query received" occurs when the host receives either a valid General Membership Query message, or a valid Group-Specific Membership Query message. To be valid, the Query message must be at least 8 octets long, and have a correct IGMP checksum. The group address in the IGMP header must either be zero (a General Query) or a valid multicast group address (a Group-Specific Query)" There is no requirement for the source address to be on the same subnet as = the host. Thanks, Kunal --_000_05D3B4AA7527D74EBF4921238463575321641601BAINBANSXCHMBSA_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

To the best of my knowledge the host d= oes not care about the source-ip of the query for it to respond. I’ve see= n this work always.

OTOH, the igmp router needs to do this check for the reports received because they come from the untrusted side of= the n/w.

Thanks,

Magesh.

From:= magma-bounces@ietf.org [mailto:magma-bounces@ietf.org] On Behalf Of Kunal Shah
Sent: Wednesday, October 12,= 2011 6:09 AM
To: magma@ietf.org
Subject: [magma] Question ab= out IGMP host implementation

Hi all,

Can an IGMPv2 host respond to = a general query originated from a subnet other then its own?? RFC 2236 states= :

""query received" occurs when the host receives either a valid
     General Membership Query message, or a valid Group-Specific
     Membership Query message. To be valid, the Q= uery message must be
     at least 8 octets long, and have a correct IGMP checksum. The
     group address in the IGMP header must either be ze= ro (a General
     Query) or a valid multicast group address (a Group= -Specific Query)"

There is no requirement for th= e source address to be on the same subnet as the host.

Thanks,

Kunal=

--_000_05D3B4AA7527D74EBF4921238463575321641601BAINBANSXCHMBSA_-- From asaeda@sfc.wide.ad.jp Sat Oct 15 09:49:31 2011 Return-Path: X-Original-To: magma@ietfa.amsl.com Delivered-To: magma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3BAD21F8B00 for ; Sat, 15 Oct 2011 09:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.096 X-Spam-Level: X-Spam-Status: No, score=-99.096 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQwupdW5ivWw for ; Sat, 15 Oct 2011 09:49:31 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id 5362321F8A95 for ; Sat, 15 Oct 2011 09:49:30 -0700 (PDT) Received: from localhost (p16206-ipngn201hodogaya.kanagawa.ocn.ne.jp [114.175.255.206]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 7DBBA2780B9; Sun, 16 Oct 2011 01:48:57 +0900 (JST) Date: Sun, 16 Oct 2011 01:48:57 +0900 (JST) Message-Id: <20111016.014857.191479968.asaeda@sfc.wide.ad.jp> To: bharat_joshi@infosys.com From: Hitoshi Asaeda In-Reply-To: <31D55C4D55BEED48A4459EB64567589A1186EB24F2@BLRKECMBX02.ad.infosys.com> References: <31D55C4D55BEED48A4459EB64567589A1186EB24F1@BLRKECMBX02.ad.infosys.com> <20111014.123005.235216170.asaeda@sfc.wide.ad.jp> <31D55C4D55BEED48A4459EB64567589A1186EB24F2@BLRKECMBX02.ad.infosys.com> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: magma@ietf.org Subject: Re: [magma] Destination address in v2 leave message X-BeenThere: magma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast and Anycast Group Membership List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2011 16:49:31 -0000 Hi Bharat, > Yes. Querier need not be a multicast data forwarder. But > are you suggesting that a forwarder who is not a IGMP querier > process the leave message? If yes, what action do they take? If non-querier on the link has the forwaring state for the corresponding channels, it should be able to hear IGMP report and proceed to change its state if needed, while it does not send any IGMP query. The action on the router whether sending prune or not is coordinated by the routing protocol, PIM. This is my understanding. > As per RFC 2236, non-querier should be using group specific > queries to lower down the group timer instead of leave messages. It seems not very precise. RFC2236 says; When a non-Querier receives a Group-Specific Query message, if its existing group membership timer is greater than [Last Member Query Count] times the Max Response Time specified in the message, it sets its group membership timer to that value. BTW, I found the following statements in RFC2236; Non-Queriers MUST ignore Leave Group messages, and Queriers SHOULD ignore Leave Group messages for which there are no group members on the reception interface. But I don't think above "ignore" is appropriate. I interpret "Non-Queriers MUST ignore Leave Group messages" to mean "Non-Queriers MUST NOT respond IGMP queries when it receives Leave Group messages". (If I'm wrong, please correct me.) Anyway, we should refer RFC3376. Regards, -- Hitoshi Asaeda From asaeda@sfc.wide.ad.jp Sat Oct 15 10:00:50 2011 Return-Path: X-Original-To: magma@ietfa.amsl.com Delivered-To: magma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 332D221F84A9 for ; Sat, 15 Oct 2011 10:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.096 X-Spam-Level: X-Spam-Status: No, score=-99.096 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CeVcaXozzAQJ for ; Sat, 15 Oct 2011 10:00:49 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id B60C321F84A7 for ; Sat, 15 Oct 2011 10:00:48 -0700 (PDT) Received: from localhost (p16206-ipngn201hodogaya.kanagawa.ocn.ne.jp [114.175.255.206]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id BCD952780C2; Sun, 16 Oct 2011 02:00:17 +0900 (JST) Date: Sun, 16 Oct 2011 02:00:17 +0900 (JST) Message-Id: <20111016.020017.99553331.asaeda@sfc.wide.ad.jp> To: thomas.morin@orange.com From: Hitoshi Asaeda In-Reply-To: <4E97EC5A.5020400@orange.com> References: <4E97A191.3070800@venaas.com> <20111014.123740.41797110.asaeda@sfc.wide.ad.jp> <4E97EC5A.5020400@orange.com> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: magma@ietf.org Subject: Re: [magma] Question about IGMP host implementation X-BeenThere: magma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast and Anycast Group Membership List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2011 17:00:50 -0000 >> I think using unicast query is not well defined and considered in >> rfc3376 and 3810. > > It may or may not be the same as the one Stig knows, but I also know > about one equipment that has a useful feature that relies on this. RFC3376 and 3810 do not disallow unicast query. I said that it is useful for some condition, but it is not generally used and should've been more precisely specified in these RFCs. >> Although it would be useful for some environment, e.g. resource >> sensitive wireless link, it may cause some security concern. > > Well, even if no Querier would use it, an IGMP host implementation may > accept them. Because these RFCs do not disallow unicast query, hosts may accept it. I don't deny this possibility. But the question is whether such host implementation is (or should be) common or not. > So it seems to me that working on this issue, or even > encouraging the use of unicasted Queries, does not make any problem > worse. Documenting how to do GTSM with IGMP would somehow improve > security. GTSM or some other technique should be used together if you use unicast query secure. The point we need to know is there is no such requirement mentioned in these RFCs. >> And also, unicast query is not used standalone. Multicast query must >> be also >> coexist. > > There are context where you could use only unicasted Queries. I don't know. Please read Appendix A in the following IGMP/MLD tuning draft, http://tools.ietf.org/html/draft-ietf-multimob-igmp-mld-tuning-01 and if you have comments for this draft, please tell us or post to the ML. Thank you. Regards, -- Hitoshi Asaeda From bharat_joshi@infosys.com Sun Oct 16 23:52:36 2011 Return-Path: X-Original-To: magma@ietfa.amsl.com Delivered-To: magma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74E3C21F8672 for ; Sun, 16 Oct 2011 23:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqkGaYrF1N6M for ; Sun, 16 Oct 2011 23:52:35 -0700 (PDT) Received: from KECGATE08.infosys.com (kecgate08.infosysconsulting.com [122.98.10.33]) by ietfa.amsl.com (Postfix) with ESMTP id 1916121F85D1 for ; Sun, 16 Oct 2011 23:52:34 -0700 (PDT) X-TM-IMSS-Message-ID: <6b85fd800007dae1@infosys.com> Received: from blrkechub02.ad.infosys.com ([10.66.236.42]) by infosys.com ([122.98.10.33]) with ESMTP (TREND IMSS SMTP Service 7.1) id 6b85fd800007dae1 ; Mon, 17 Oct 2011 12:29:14 +0530 Received: from blrkechub12.ad.infosys.com (10.66.236.47) by blrkechub02.ad.infosys.com (10.66.236.42) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 17 Oct 2011 12:21:07 +0530 Received: from BLRKECMBX02.ad.infosys.com ([10.66.236.22]) by blrkechub12.ad.infosys.com ([10.66.236.47]) with mapi; Mon, 17 Oct 2011 12:21:07 +0530 From: Bharat Joshi To: Hitoshi Asaeda Date: Mon, 17 Oct 2011 12:21:06 +0530 Thread-Topic: [magma] Destination address in v2 leave message Thread-Index: AcyLWjCNCDHxPfOrRX+vOsGgxKw51ABPPrav Message-ID: <31D55C4D55BEED48A4459EB64567589A1186EB24F5@BLRKECMBX02.ad.infosys.com> References: <31D55C4D55BEED48A4459EB64567589A1186EB24F1@BLRKECMBX02.ad.infosys.com> <20111014.123005.235216170.asaeda@sfc.wide.ad.jp> <31D55C4D55BEED48A4459EB64567589A1186EB24F2@BLRKECMBX02.ad.infosys.com>, <20111016.014857.191479968.asaeda@sfc.wide.ad.jp> In-Reply-To: <20111016.014857.191479968.asaeda@sfc.wide.ad.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "magma@ietf.org" Subject: Re: [magma] Destination address in v2 leave message X-BeenThere: magma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast and Anycast Group Membership List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 06:52:36 -0000 Hi=20Hitoshi, >=20>=20=20=20=20=20=20=20=20=20=20Yes.=20Querier=20need=20not=20be=20a= =20multicast=20data=20forwarder.=20But >=20>=20are=20you=20suggesting=20that=20a=20forwarder=20who=20is=20not=20= a=20IGMP=20querier >=20>=20process=20the=20leave=20message?=20If=20yes,=20what=20action=20do= =20they=20take? >=20 >=20If=20non-querier=20on=20the=20link=20has=20the=20forwaring=20state=20= for=20the >=20corresponding=20channels,=20it=20should=20be=20able=20to=20hear=20IGM= P=20report=20and >=20proceed=20to=20change=20its=20state=20if=20needed,=20while=20it=20doe= s=20not=20send=20any=20IGMP >=20query.=20The=20action=20on=20the=20router=20whether=20sending=20prune= =20or=20not=20is >=20coordinated=20by=20the=20routing=20protocol,=20PIM. >=20This=20is=20my=20understanding. > Though=20I=20understand=20what=20you=20are=20suggesting.=20But=20a=20rout= er=20that=20is=20non-querier=20won't=20be=20able=20to=20take=20a=20decisi= on=20of=20pruning=20a=20multicast=20path=20with=20just=20a=20leave=20mess= age.=20There=20may=20be=20others=20who=20are=20still=20interested=20in=20= this=20group=20on=20that=20LAN=20and=20until=20that=20is=20made=20sure,= =20non-querier=20cannot=20prune=20the=20multicast=20path.=20This=20is=20d= one=20by=20lowering=20the=20group=20timer=20when=20non-querier=20sees=20a= =20group=20specific=20query=20from=20querier=20and=20once=20it=20expires,= =20non-querier=20can=20prune=20the=20multicast=20path. There=20may=20be=20one=20case=20where=20this=20non-querier=20router=20can= =20prune=20on=20its=20own=20and=20in=20that=20case=20this=20router=20will= =20have=20to=20keep=20track=20of=20all=20hosts=20who=20had=20subscribed= =20to=20this=20group.=20Once=20the=20last=20host=20sent=20a=20leave=20mes= sage,=20non-querier=20need=20not=20wait=20for=20the=20group-specific=20qu= ery=20or=20group=20timeout. I=20remember=20seeing=20a=20draft=20for=20explicit=20tracking=20in=20PIM= =20working=20group=20sometime=20back=20so=20until=20this=20functionality= =20is=20available,=20non-querier=20cannot=20prune=20on=20their=20own. =20 >=20>=20=20=20=20=20=20=20=20=20=20As=20per=20RFC=202236,=20non-querier= =20should=20be=20using=20group=20specific >=20>=20queries=20to=20lower=20down=20the=20group=20timer=20instead=20of= =20leave=20messages. >=20 >=20It=20seems=20not=20very=20precise.=20RFC2236=20says; >=20 >=20=20=20=20When=20a=20non-Querier=20receives=20a=20Group-Specific=20Que= ry=20message,=20if=20its >=20=20=20=20existing=20group=20membership=20timer=20is=20greater=20than= =20[Last=20Member=20Query >=20=20=20=20Count]=20times=20the=20Max=20Response=20Time=20specified=20i= n=20the=20message,=20it=20sets >=20=20=20=20its=20group=20membership=20timer=20to=20that=20value. >=20 >=20BTW,=20I=20found=20the=20following=20statements=20in=20RFC2236; >=20 >=20=20=20=20Non-Queriers=20MUST=20ignore=20Leave=20Group=20messages,=20a= nd=20Queriers=20SHOULD >=20=20=20=20ignore=20Leave=20Group=20messages=20for=20which=20there=20ar= e=20no=20group=20members=20on >=20=20=20=20the=20reception=20interface. >=20 >=20But=20I=20don't=20think=20above=20"ignore"=20is=20appropriate. >=20I=20interpret=20"Non-Queriers=20MUST=20ignore=20Leave=20Group=20messa= ges"=20to=20mean >=20"Non-Queriers=20MUST=20NOT=20respond=20IGMP=20queries=20when=20it=20r= eceives=20Leave >=20Group=20messages".=20(If=20I'm=20wrong,=20please=20correct=20me.) I=20think=20with=20'ignore'=20also=20things=20work=20pretty=20much=20fine= =20as=20I=20explained=20above. >=20Anyway,=20we=20should=20refer=20RFC3376. >=20 To=20me=20RFC=203376=20also=20looks=20pretty=20much=20same.=20Do=20you=20= see=20any=20difference=20in=20processing=20for=20the=20above=20case=20in= =20RFC=203376? Regards, Bharat ****************=20CAUTION=20-=20Disclaimer=20***************** This=20e-mail=20contains=20PRIVILEGED=20AND=20CONFIDENTIAL=20INFORMATION= =20intended=20solely=20 for=20the=20use=20of=20the=20addressee(s).=20If=20you=20are=20not=20the= =20intended=20recipient,=20please=20 notify=20the=20sender=20by=20e-mail=20and=20delete=20the=20original=20mes= sage.=20Further,=20you=20are=20not=20 to=20copy,=20disclose,=20or=20distribute=20this=20e-mail=20or=20its=20con= tents=20to=20any=20other=20person=20and=20 any=20such=20actions=20are=20unlawful.=20This=20e-mail=20may=20contain=20= viruses.=20Infosys=20has=20taken=20 every=20reasonable=20precaution=20to=20minimize=20this=20risk,=20but=20is= =20not=20liable=20for=20any=20damage=20 you=20may=20sustain=20as=20a=20result=20of=20any=20virus=20in=20this=20e-= mail.=20You=20should=20carry=20out=20your=20 own=20virus=20checks=20before=20opening=20the=20e-mail=20or=20attachment.= =20Infosys=20reserves=20the=20 right=20to=20monitor=20and=20review=20the=20content=20of=20all=20messages= =20sent=20to=20or=20from=20this=20e-mail=20 address.=20Messages=20sent=20to=20or=20from=20this=20e-mail=20address=20m= ay=20be=20stored=20on=20the=20 Infosys=20e-mail=20system. ***INFOSYS********=20End=20of=20Disclaimer=20********INFOSYS*** From asaeda@sfc.wide.ad.jp Mon Oct 17 00:17:51 2011 Return-Path: X-Original-To: magma@ietfa.amsl.com Delivered-To: magma@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29BC611E8082 for ; Mon, 17 Oct 2011 00:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.096 X-Spam-Level: X-Spam-Status: No, score=-99.096 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mvvhj6ZLzkfQ for ; Mon, 17 Oct 2011 00:17:50 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id 7473C21F8AA9 for ; Mon, 17 Oct 2011 00:17:49 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:200:0:8801:129a:ddff:fe4f:16d2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 0C44C27806E; Mon, 17 Oct 2011 16:17:17 +0900 (JST) Date: Mon, 17 Oct 2011 16:17:16 +0900 (JST) Message-Id: <20111017.161716.48811104.asaeda@sfc.wide.ad.jp> To: bharat_joshi@infosys.com From: Hitoshi Asaeda In-Reply-To: <31D55C4D55BEED48A4459EB64567589A1186EB24F5@BLRKECMBX02.ad.infosys.com> References: <31D55C4D55BEED48A4459EB64567589A1186EB24F2@BLRKECMBX02.ad.infosys.com> <20111016.014857.191479968.asaeda@sfc.wide.ad.jp> <31D55C4D55BEED48A4459EB64567589A1186EB24F5@BLRKECMBX02.ad.infosys.com> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: magma@ietf.org Subject: Re: [magma] Destination address in v2 leave message X-BeenThere: magma@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multicast and Anycast Group Membership List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 07:17:51 -0000 Hi Bharat, >> > Yes. Querier need not be a multicast data forwarder. But >> > are you suggesting that a forwarder who is not a IGMP querier >> > process the leave message? If yes, what action do they take? >> >> If non-querier on the link has the forwaring state for the >> corresponding channels, it should be able to hear IGMP report and >> proceed to change its state if needed, while it does not send any IGMP >> query. The action on the router whether sending prune or not is >> coordinated by the routing protocol, PIM. >> This is my understanding. >> > > Though I understand what you are suggesting. But a router that is > non-querier won't be able to take a decision of pruning a > multicast path with just a leave message. There may be others who > are still interested in this group on that LAN and until that is > made sure, non-querier cannot prune the multicast path. This is > done by lowering the group timer when non-querier sees a group > specific query from querier and once it expires, non-querier can > prune the multicast path. > > There may be one case where this non-querier router can prune on its > own and in that case this router will have to keep track of all > hosts who had subscribed to this group. Once the last host sent a > leave message, non-querier need not wait for the group-specific > query or group timeout. Yes, your description is correct. I didn't mean different things. > I remember seeing a draft for explicit tracking in PIM working group > sometime back so until this functionality is available, non-querier > cannot prune on their own. The explicit tracking contributes to the first leave, but the draft does not mention that last member query count should be 0. This means, whether the explicit tracking function is enabled or not, group(-and-source)-specific query for the channel should be sent when the router thinks the report sender is the last member according to its member record, and a router having the routing state for the channel will coordinate prune for that channel if the router confirms the report sender is the last member. >> > As per RFC 2236, non-querier should be using group specific >> > queries to lower down the group timer instead of leave messages. >> >> It seems not very precise. RFC2236 says; >> >> When a non-Querier receives a Group-Specific Query message, if its >> existing group membership timer is greater than [Last Member Query >> Count] times the Max Response Time specified in the message, it sets >> its group membership timer to that value. >> >> BTW, I found the following statements in RFC2236; >> >> Non-Queriers MUST ignore Leave Group messages, and Queriers SHOULD >> ignore Leave Group messages for which there are no group members on >> the reception interface. >> >> But I don't think above "ignore" is appropriate. >> I interpret "Non-Queriers MUST ignore Leave Group messages" to mean >> "Non-Queriers MUST NOT respond IGMP queries when it receives Leave >> Group messages". (If I'm wrong, please correct me.) > > I think with 'ignore' also things work pretty much fine as I explained above. I still don't think "ignore" is appropriate here. >> Anyway, we should refer RFC3376. >> > > To me RFC 3376 also looks pretty much same. Do you see any > difference in processing for the above case in RFC 3376? RFC3376 does not say "Non-Queriers MUST ignore Leave Group messages or other IGMP messages". If a non-querier router has some routing states, it must also recognize IGMP messages. This is what I understand. Regards, -- Hitoshi Asaeda