From owner-idmr@cs.ucl.ac.uk Fri Nov 2 01:32:42 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA15118 for ; Fri, 2 Nov 2001 01:32:41 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Fri, 2 Nov 2001 05:50:20 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Fri, 2 Nov 2001 05:50:14 +0000 Received: from wiproecmx1.wipro.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Fri, 2 Nov 2001 05:49:36 +0000 Received: from ecvwall11.wipro.com (ecvwall1.wipro.com [164.164.23.6]) by wiproecmx1.wipro.com (8.11.3/8.11.3) with SMTP id fA25nSb11715 for ; Fri, 2 Nov 2001 11:19:29 +0530 (IST) Received: from SNRPRO107674 ([10.145.2.225]) by arabhi.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GM5S3Q00.GFS for ; Fri, 2 Nov 2001 11:17:50 +0530 Message-ID: <01c701c16362$cab66360$e102910a@SNRPRO107674> From: Vinodkumar Parasmal To: IDMR Subject: IGMPv3 Host Patch for Linux2.4.2 Date: Fri, 2 Nov 2001 11:24:09 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----=_NextPart_000_01C4_01C16390.E4391070" ------=_NextPart_000_01C4_01C16390.E4391070 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, Is there any IGMPv3 Host Patch available for Redhat Linux2.4.2 ? I = found one for 2.4.0 in the Sprintlabs site. Can that be used for 2.4.2 also. Thanks in Advance Vinod ------=_NextPart_000_01C4_01C16390.E4391070 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi All,

Is there any IGMPv3 Host Patch = available for Redhat=20 Linux2.4.2 ? I found one for 2.4.0 in the Sprintlabs site.

Can that be used for 2.4.2 = also.

Thanks in Advance

Vinod

------=_NextPart_000_01C4_01C16390.E4391070-- --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit ----------------------------------------------------------------------------------------------------------------------- Information transmitted by this E-MAIL is proprietary to Wipro and/or its Customers and is intended for use only by the individual or entity to which it is addressed, and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient or it appears that this mail has been forwarded to you without proper authority, you are notified that any use or dissemination of this information in any manner is strictly prohibited. In such cases, please notify us immediately at mailto:mailadmin@wipro.com and delete this mail from your records. ------------------------------------------------------------------------------------------------------------------------ --------------InterScan_NT_MIME_Boundary-- From owner-idmr@cs.ucl.ac.uk Mon Nov 12 00:16:58 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA06179 for ; Mon, 12 Nov 2001 00:16:58 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Mon, 12 Nov 2001 04:28:39 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Mon, 12 Nov 2001 04:28:33 +0000 Received: from acsys.anu.edu.au by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 12 Nov 2001 04:27:43 +0000 Received: from ACCORDION2.acsys.anu.edu.au (accordion2.apac.edu.au [150.203.56.15]) by acsys.anu.edu.au (8.9.3/8.9.3) with ESMTP id PAA21536; Mon, 12 Nov 2001 15:27:37 +1100 (EST) Message-Id: <5.0.2.1.0.20011112151616.04ed6ec0@acsys.anu.edu.au> X-Sender: markus@acsys.anu.edu.au X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 12 Nov 2001 15:27:36 +1100 To: confctrl@isi.edu From: Markus Buchhorn Subject: current igmp-v3 spec? Cc: idmr@cs.ucl.ac.uk Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Hi All The IGMPv3 draft (-07) expired in September 2001 - is there an RFC in the pipeline I have missed? Or a newer version of the draft hiding somewhere? Cheers, Markus Markus Buchhorn, Faculty of Engineering and IT, | Ph: +61 2 61258810 email: markus.buchhorn@anu.edu.au, mail: CSIT Bldg #108 |Fax: +61 2 61259805 Australian National University, Canberra 0200, Australia |Mobile: 0417 281429 From owner-idmr@cs.ucl.ac.uk Mon Nov 19 02:58:18 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA21987 for ; Mon, 19 Nov 2001 02:58:13 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Mon, 19 Nov 2001 07:11:13 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Mon, 19 Nov 2001 07:11:07 +0000 Received: from sj-msg-core-1.cisco.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 19 Nov 2001 07:10:06 +0000 Received: from kouvelas-u10.cisco.com (kouvelas-u10.cisco.com [128.107.162.231]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fAJ7A1809533; Sun, 18 Nov 2001 23:10:01 -0800 (PST) Received: from localhost (kouvelas@localhost) by kouvelas-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id XAA07183; Sun, 18 Nov 2001 23:10:01 -0800 (PST) Message-Id: <200111190710.XAA07183@kouvelas-u10.cisco.com> X-Authentication-Warning: kouvelas-u10.cisco.com: kouvelas owned process doing -bs To: eckert@cisco.com cc: Magma@innovationslab.net, idmr@cs.ucl.ac.uk, holbrook@cisco.com, kouvelas@cisco.com, ajit@torrentnet.com, fenner@research.att.com, deering@cisco.com Subject: Re: IGMP v3 / snooping suggestion In-reply-to: Your message of "Sun, 18 Nov 2001 18:04:06 PST." <20011118180406.A23784@cypher.cisco.com> Date: Sun, 18 Nov 2001 23:10:01 -0800 From: Isidor Kouvelas Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk What if you have more than one switches on the same router interface? Doesn't the use of a fixed address break explicit tracking? thanks I Toerless Eckert writes: >Opinions about the following please: useful, necessary ?: > >IGMP Snooping switches may want to implement "proxy-reporting", >eg: summarizing reports received from downstream hosts, building internal >forwarding state and then simply reporting out of their own state in >response to IGMP queries received from the upstream DR. This very >much helps to offload the total number of IGMP reports the router needs >to see, especially with IGMPv3 where there's no report suppression. >While this feature is certainly something that better be optional, >it is certainly worthwhile. > >When something like this is to be implemented, the question arises as >to which reporter ip address the switch should use. In general, switches >do _not_ have ip addresses on all of their VLANs. > >So the idea Hugh had here is to use the address 0.0.0.0 for reports in these >cases. Question: Would this be an implicitly allowed case because 0.0.0.0 >is always a valid source-ip-address on an ip-subnet (at least for certain >operations ?), or would that need to be / should this be explicitly noted >as a valid source address for reports - in the IGMPv3 spec ? And would it >be sufficient (not in violation of some other RFC) ? > >Beside the fact that this is very useful to make life easier for certain >products (IGMP Snooping switches), i also think this is just from the >pure service model quite valid - Unfortunately, RFC1112 (service model) >does not discuss the case of a host that _only_ supports receipt of >ip multicast - but for such a host, what would be the need to have >an assigned ip address ? > >Summary: i'd like to have some note about 0.0.0.0 being a valid reporter >source ip address in the IGMPv3 spec, unless this would already be >implicitly deducable from whatever other RFCs there are, and i'd like to >know if this is sufficient to be able to use this then on hosts/switches >whenever there's an IGMPv3 querier. > >Cheers > Toerless From owner-idmr@cs.ucl.ac.uk Mon Nov 19 09:09:50 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA29384 for ; Mon, 19 Nov 2001 09:09:48 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Mon, 19 Nov 2001 13:23:17 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Mon, 19 Nov 2001 07:35:04 +0000 Received: from sj-msg-core-4.cisco.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 19 Nov 2001 07:34:02 +0000 Received: from holbrook-laptop.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id fAJ7Xxl12969; Sun, 18 Nov 2001 23:34:00 -0800 (PST) Received: by holbrook-laptop.cisco.com (Postfix, from userid 500) id 42B8AC3B90; Sun, 18 Nov 2001 23:34:03 -0800 (PST) From: Hugh Holbrook To: Isidor Kouvelas Cc: eckert@cisco.com, Magma@innovationslab.net, idmr@cs.ucl.ac.uk, holbrook@cisco.com, kouvelas@cisco.com, ajit@torrentnet.com, fenner@research.att.com, deering@cisco.com In-reply-to: <200111190710.XAA07183@kouvelas-u10.cisco.com> Subject: Re: Re: IGMP v3 / snooping suggestion Reply-To: holbrook@cisco.com Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Message-Id: <20011119073403.42B8AC3B90@holbrook-laptop.cisco.com> Date: Sun, 18 Nov 2001 23:34:03 -0800 (PST) Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk A router doing explicit tracking would have to treat 0.0.0.0 specially, recognizing that it might correspond to multiple hosts. For example, it could use the L2 source address as the key for explicit membership tracking when the reporter's IP source address is 0.0.0.0. -Hugh > What if you have more than one switches on the same router interface? > Doesn't the use of a fixed address break explicit tracking? > > thanks > I > > > Toerless Eckert writes: > >Opinions about the following please: useful, necessary ?: > > > >IGMP Snooping switches may want to implement "proxy-reporting", > >eg: summarizing reports received from downstream hosts, building internal > >forwarding state and then simply reporting out of their own state in > >response to IGMP queries received from the upstream DR. This very > >much helps to offload the total number of IGMP reports the router needs > >to see, especially with IGMPv3 where there's no report suppression. > >While this feature is certainly something that better be optional, > >it is certainly worthwhile. > > > >When something like this is to be implemented, the question arises as > >to which reporter ip address the switch should use. In general, switches > >do _not_ have ip addresses on all of their VLANs. > > > >So the idea Hugh had here is to use the address 0.0.0.0 for reports in these > >cases. Question: Would this be an implicitly allowed case because 0.0.0.0 > >is always a valid source-ip-address on an ip-subnet (at least for certain > >operations ?), or would that need to be / should this be explicitly noted > >as a valid source address for reports - in the IGMPv3 spec ? And would it > >be sufficient (not in violation of some other RFC) ? > > > >Beside the fact that this is very useful to make life easier for certain > >products (IGMP Snooping switches), i also think this is just from the > >pure service model quite valid - Unfortunately, RFC1112 (service model) > >does not discuss the case of a host that _only_ supports receipt of > >ip multicast - but for such a host, what would be the need to have > >an assigned ip address ? > > > >Summary: i'd like to have some note about 0.0.0.0 being a valid reporter > >source ip address in the IGMPv3 spec, unless this would already be > >implicitly deducable from whatever other RFCs there are, and i'd like to > >know if this is sufficient to be able to use this then on hosts/switches > >whenever there's an IGMPv3 querier. > > > >Cheers > > Toerless > From owner-idmr@cs.ucl.ac.uk Mon Nov 19 09:14:27 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA29653 for ; Mon, 19 Nov 2001 09:14:26 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Mon, 19 Nov 2001 13:24:08 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Mon, 19 Nov 2001 08:14:38 +0000 Received: from max5.rrze.uni-erlangen.de by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 19 Nov 2001 08:13:28 +0000 Received: from lisa.rrze.uni-erlangen.de by max5.rrze.uni-erlangen.de with ESMTP; Mon, 19 Nov 2001 09:13:26 +0100 Received: from localhost by lisa.rrze.uni-erlangen.de (8.10.2+Sun/cl-RRZE) id fAJ8DCr11919; Mon, 19 Nov 2001 09:13:12 +0100 (MET) Date: Mon, 19 Nov 2001 09:13:12 +0100 (MET) From: Falko Dressler To: Isidor Kouvelas cc: eckert@cisco.com, Magma@innovationslab.net, idmr@cs.ucl.ac.uk, holbrook@cisco.com, ajit@torrentnet.com, fenner@research.att.com, deering@cisco.com Subject: Re: [Magma] Re: IGMP v3 / snooping suggestion In-Reply-To: <200111190710.XAA07183@kouvelas-u10.cisco.com> Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk The switch as a 'proxy reporter' interacts with the router / other switches just as a servant for the hosts which originated the IGMP report. Also, all interactions between layer-2 switches are based on the layer-2 address of these devices. So, the router may recognise the 'proxy-switch' on the basis its MAC address. The second question of Toerless is many more interesting. Currently, there is no way to have hosts for multicast receiving only. You always have to have an IP address assigned to it. We should find a way to avoid this requirement. Falko. > > What if you have more than one switches on the same router interface? > Doesn't the use of a fixed address break explicit tracking? > > thanks > I > > > Toerless Eckert writes: > >Opinions about the following please: useful, necessary ?: > > > >IGMP Snooping switches may want to implement "proxy-reporting", > >eg: summarizing reports received from downstream hosts, building internal > >forwarding state and then simply reporting out of their own state in > >response to IGMP queries received from the upstream DR. This very > >much helps to offload the total number of IGMP reports the router needs > >to see, especially with IGMPv3 where there's no report suppression. > >While this feature is certainly something that better be optional, > >it is certainly worthwhile. > > > >When something like this is to be implemented, the question arises as > >to which reporter ip address the switch should use. In general, switches > >do _not_ have ip addresses on all of their VLANs. > > > >So the idea Hugh had here is to use the address 0.0.0.0 for reports in these > >cases. Question: Would this be an implicitly allowed case because 0.0.0.0 > >is always a valid source-ip-address on an ip-subnet (at least for certain > >operations ?), or would that need to be / should this be explicitly noted > >as a valid source address for reports - in the IGMPv3 spec ? And would it > >be sufficient (not in violation of some other RFC) ? > > > >Beside the fact that this is very useful to make life easier for certain > >products (IGMP Snooping switches), i also think this is just from the > >pure service model quite valid - Unfortunately, RFC1112 (service model) > >does not discuss the case of a host that _only_ supports receipt of > >ip multicast - but for such a host, what would be the need to have > >an assigned ip address ? > > > >Summary: i'd like to have some note about 0.0.0.0 being a valid reporter > >source ip address in the IGMPv3 spec, unless this would already be > >implicitly deducable from whatever other RFCs there are, and i'd like to > >know if this is sufficient to be able to use this then on hosts/switches > >whenever there's an IGMPv3 querier. > > > >Cheers > > Toerless > _______________________________________________ > Magma mailing list > Magma@innovationslab.net > http://www.innovationslab.net/mailman/listinfo/magma > -- Falko Dressler Universitaet Erlangen-Nuernberg, RRZE EMail: Falko.Dressler@rrze.uni-erlangen.de Tel: +49 9131 85-27802 / Fax: +49 9131 302941 WWW: http://bsd.rrze.uni-erlangen.de/~fd/ From owner-idmr@cs.ucl.ac.uk Mon Nov 19 09:14:32 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA29665 for ; Mon, 19 Nov 2001 09:14:31 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Mon, 19 Nov 2001 13:22:20 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Mon, 19 Nov 2001 02:06:10 +0000 Received: from cypher.cisco.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 19 Nov 2001 02:05:11 +0000 Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id SAA00755; Sun, 18 Nov 2001 18:04:06 -0800 (PST) Date: Sun, 18 Nov 2001 18:04:06 -0800 From: Toerless Eckert To: Magma@innovationslab.net, idmr@cs.ucl.ac.uk Cc: Hugh Holbrook , Isidor Kouvelas , ajit@torrentnet.com, fenner@research.att.com, Stephen Deering Subject: IGMP v3 / snooping suggestion Message-ID: <20011118180406.A23784@cypher.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk Opinions about the following please: useful, necessary ?: IGMP Snooping switches may want to implement "proxy-reporting", eg: summarizing reports received from downstream hosts, building internal forwarding state and then simply reporting out of their own state in response to IGMP queries received from the upstream DR. This very much helps to offload the total number of IGMP reports the router needs to see, especially with IGMPv3 where there's no report suppression. While this feature is certainly something that better be optional, it is certainly worthwhile. When something like this is to be implemented, the question arises as to which reporter ip address the switch should use. In general, switches do _not_ have ip addresses on all of their VLANs. So the idea Hugh had here is to use the address 0.0.0.0 for reports in these cases. Question: Would this be an implicitly allowed case because 0.0.0.0 is always a valid source-ip-address on an ip-subnet (at least for certain operations ?), or would that need to be / should this be explicitly noted as a valid source address for reports - in the IGMPv3 spec ? And would it be sufficient (not in violation of some other RFC) ? Beside the fact that this is very useful to make life easier for certain products (IGMP Snooping switches), i also think this is just from the pure service model quite valid - Unfortunately, RFC1112 (service model) does not discuss the case of a host that _only_ supports receipt of ip multicast - but for such a host, what would be the need to have an assigned ip address ? Summary: i'd like to have some note about 0.0.0.0 being a valid reporter source ip address in the IGMPv3 spec, unless this would already be implicitly deducable from whatever other RFCs there are, and i'd like to know if this is sufficient to be able to use this then on hosts/switches whenever there's an IGMPv3 querier. Cheers Toerless From owner-idmr@cs.ucl.ac.uk Mon Nov 19 12:06:21 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10009 for ; Mon, 19 Nov 2001 12:06:20 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Mon, 19 Nov 2001 15:46:51 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Mon, 19 Nov 2001 15:46:44 +0000 Received: from motgate3.mot.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 19 Nov 2001 15:45:41 +0000 Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate3.mot.com (motgate3 2.1) with ESMTP id IAA28578 for ; Mon, 19 Nov 2001 08:36:26 -0700 (MST)] Received: [from il06exw10.corp.mot.com (il06exw10.corp.mot.com [199.5.78.81]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id IAA19409 for ; Mon, 19 Nov 2001 08:45:40 -0700 (MST)] Received: by il06exw10.corp.mot.com with Internet Mail Service (5.5.2654.52) id ; Mon, 19 Nov 2001 09:45:39 -0600 Message-ID: From: Jung Cyndi-ACJ099 To: "'holbrook@cisco.com'" , Isidor Kouvelas Cc: eckert@cisco.com, Magma@innovationslab.net, idmr@cs.ucl.ac.uk, ajit@torrentnet.com, fenner@research.att.com, deering@cisco.com Subject: RE: Re: IGMP v3 / snooping suggestion Date: Mon, 19 Nov 2001 09:45:39 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk I guess you couldn't use a BSD machine as the router then - it needs to see that IP address to determine which interface the IGMP was received on. Or is that no longer true? Cyndi -----Original Message----- From: Hugh Holbrook [mailto:holbrook@cisco.com] Sent: Sunday, November 18, 2001 11:34 PM To: Isidor Kouvelas Cc: eckert@cisco.com; Magma@innovationslab.net; idmr@cs.ucl.ac.uk; holbrook@cisco.com; kouvelas@cisco.com; ajit@torrentnet.com; fenner@research.att.com; deering@cisco.com Subject: Re: Re: IGMP v3 / snooping suggestion A router doing explicit tracking would have to treat 0.0.0.0 specially, recognizing that it might correspond to multiple hosts. For example, it could use the L2 source address as the key for explicit membership tracking when the reporter's IP source address is 0.0.0.0. -Hugh > What if you have more than one switches on the same router interface? > Doesn't the use of a fixed address break explicit tracking? > > thanks > I > > > Toerless Eckert writes: > >Opinions about the following please: useful, necessary ?: > > > >IGMP Snooping switches may want to implement "proxy-reporting", > >eg: summarizing reports received from downstream hosts, building internal > >forwarding state and then simply reporting out of their own state in > >response to IGMP queries received from the upstream DR. This very > >much helps to offload the total number of IGMP reports the router needs > >to see, especially with IGMPv3 where there's no report suppression. > >While this feature is certainly something that better be optional, > >it is certainly worthwhile. > > > >When something like this is to be implemented, the question arises as > >to which reporter ip address the switch should use. In general, switches > >do _not_ have ip addresses on all of their VLANs. > > > >So the idea Hugh had here is to use the address 0.0.0.0 for reports in these > >cases. Question: Would this be an implicitly allowed case because 0.0.0.0 > >is always a valid source-ip-address on an ip-subnet (at least for certain > >operations ?), or would that need to be / should this be explicitly noted > >as a valid source address for reports - in the IGMPv3 spec ? And would it > >be sufficient (not in violation of some other RFC) ? > > > >Beside the fact that this is very useful to make life easier for certain > >products (IGMP Snooping switches), i also think this is just from the > >pure service model quite valid - Unfortunately, RFC1112 (service model) > >does not discuss the case of a host that _only_ supports receipt of > >ip multicast - but for such a host, what would be the need to have > >an assigned ip address ? > > > >Summary: i'd like to have some note about 0.0.0.0 being a valid reporter > >source ip address in the IGMPv3 spec, unless this would already be > >implicitly deducable from whatever other RFCs there are, and i'd like to > >know if this is sufficient to be able to use this then on hosts/switches > >whenever there's an IGMPv3 querier. > > > >Cheers > > Toerless > From owner-idmr@cs.ucl.ac.uk Mon Nov 19 13:35:16 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15695 for ; Mon, 19 Nov 2001 13:35:16 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Mon, 19 Nov 2001 17:08:52 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Mon, 19 Nov 2001 17:03:29 +0000 Received: from cypher.cisco.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 19 Nov 2001 17:02:26 +0000 Received: (from eckert@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id JAA21747; Mon, 19 Nov 2001 09:01:21 -0800 (PST) Date: Mon, 19 Nov 2001 09:01:21 -0800 From: Toerless Eckert To: Hugh Holbrook Cc: Isidor Kouvelas , eckert@cisco.com, Magma@innovationslab.net, idmr@cs.ucl.ac.uk, ajit@torrentnet.com, fenner@research.att.com, deering@cisco.com Subject: Re: Re: IGMP v3 / snooping suggestion Message-ID: <20011119090121.C16637@cypher.cisco.com> References: <200111190710.XAA07183@kouvelas-u10.cisco.com> <20011119073403.42B8AC3B90@holbrook-laptop.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <20011119073403.42B8AC3B90@holbrook-laptop.cisco.com>; from holbrook@cisco.com on Sun, Nov 18, 2001 at 11:34:03PM -0800 Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk On Sun, Nov 18, 2001 at 11:34:03PM -0800, Hugh Holbrook wrote: > A router doing explicit tracking would have to treat 0.0.0.0 > specially, recognizing that it might correspond to multiple hosts. > For example, it could use the L2 source address as the key for > explicit membership tracking when the reporter's IP source address is > 0.0.0.0. I am glad that i did not have to say this, because the "layer violation" police force already has me on parole ;-), but yes, that's the way to go for explicit tracking - but remember, the explicit tracking then on the router is only good for zero leave latency, but not for actually keeping track of all reporters - that property is one that you MUST loose on the router when you enable such a feature on the switch for the reason of scaling you LAN for more reporters than you want to be able to see on the router itself. And by the way, "stealing" an ip address from one of the downstream reporters as someone else in this thread suggested is really ugly especially when that downstream reporter decides to move to some other port in the LAN (as might happen continuoously in a LAN hosting several 802.11 access points). Cheers Toerless From owner-idmr@cs.ucl.ac.uk Mon Nov 26 10:59:27 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06120 for ; Mon, 26 Nov 2001 10:59:26 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Mon, 26 Nov 2001 14:45:00 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Mon, 26 Nov 2001 11:19:15 +0000 Received: from odin.ietf.org by bells.cs.ucl.ac.uk with Internet SMTP id ; Mon, 26 Nov 2001 11:17:51 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19484; Mon, 26 Nov 2001 06:17:46 -0500 (EST) Message-Id: <200111261117.GAA19484@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: idmr@cs.ucl.ac.uk From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-idmr-igmp-v3-08.txt,.ps Date: Mon, 26 Nov 2001 06:17:46 -0500 Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Multicast Routing Working Group of the IETF. Title : Internet Group Management Protocol, Version 3 Author(s) : B. Cain, S. Deering, B. Fenner, I. Kouvelas, A. Thyagarajan Filename : draft-ietf-idmr-igmp-v3-08.txt,.ps Pages : 51 Date : 21-Nov-01 This document specifies Version 3 of the Internet Group Management Protocol, IGMPv3. IGMP is the protocol used by IPv4 systems to report their IP multicast group memberships to neighboring multicast routers. Version 3 of IGMP adds support for 'source filtering', that is, the ability for a system to report interest in receiving packets *only* from specific source addresses, or from *all but* specific source addresses, sent to a particular multicast address. That information may be used by multicast routing protocols to avoid delivering multicast packets from specific sources to networks where there are no interested receivers. This document is a product of the Inter-Domain Multicast Routing working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at idmr@cs.ucl.ac.uk and/or the authors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-idmr-igmp-v3-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-idmr-igmp-v3-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-idmr-igmp-v3-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011121141819.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-idmr-igmp-v3-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-idmr-igmp-v3-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011121141819.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-idmr@cs.ucl.ac.uk Wed Nov 28 17:35:41 2001 Received: from pan2.cs.ucl.ac.uk (pan2.cs.ucl.ac.uk [128.16.8.208]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20072 for ; Wed, 28 Nov 2001 17:35:41 -0500 (EST) Received: from pan2.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk via Local Delivery channel id ; Wed, 28 Nov 2001 21:40:20 +0000 Received: from bells.cs.ucl.ac.uk by pan2.cs.ucl.ac.uk with local SMTP id ; Wed, 28 Nov 2001 21:40:14 +0000 Received: from H-135-207-30-103.research.att.com by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 28 Nov 2001 21:39:00 +0000 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 81F571E030; Wed, 28 Nov 2001 16:38:59 -0500 (EST) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id QAA10679; Wed, 28 Nov 2001 16:38:58 -0500 (EST) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id NAA15743; Wed, 28 Nov 2001 13:38:57 -0800 (PST) Message-Id: <200111282138.NAA15743@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: eckert@cisco.com Subject: Re: [Magma] IGMP v3 / snooping suggestion Cc: magma@innovationslab.net, idmr@cs.ucl.ac.uk, holbrook@cisco.com, kouvelas@cisco.com, ajit@torrentnet.com, deering@cisco.com Date: Wed, 28 Nov 2001 13:38:57 -0800 Versions: dmail (solaris) 2.2j/makemail 2.9b Sender: owner-idmr@cs.ucl.ac.uk Precedence: bulk I have always thought that 0.0.0.0 was a perfectly fine source address for an IGMP Report. I think this was probably only ever from informal discussions with Steve, though, and not an explicit spec. Note that RFC1122 does permit using 0.0.0.0 source address when you don't know your IP address. It only permits it as part of an initialization procedure when you don't know your own address, but devices without IP addresses never know their IP addresses, so I think it's an OK stretch to make. Cyndi's worry about BSD routers can be addressed by using the IP_RECVIF socket option, which returns the interface index of the reception interface as ancillary data with the packet. I have some unreleased code from 1998 or so that uses this functionality in mrouted. Bill