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 <idmr-archive@lists.ietf.org>; 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 <g.11119-0@pan2.cs.ucl.ac.uk>;
          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 <g.11113-0@pan2.cs.ucl.ac.uk>; Fri, 2 Nov 2001 05:50:14 +0000
Received: from wiproecmx1.wipro.com by bells.cs.ucl.ac.uk with Internet SMTP 
          id <g.15940-0@bells.cs.ucl.ac.uk>; 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 <idmr@cs.ucl.ac.uk>; 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 <idmr@cs.ucl.ac.uk>;
          Fri, 2 Nov 2001 11:17:50 +0530
Message-ID: <01c701c16362$cab66360$e102910a@SNRPRO107674>
From: Vinodkumar Parasmal <vinodkumar.paras@wipro.com>
To: IDMR <idmr@cs.ucl.ac.uk>
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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi All,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Is there any IGMPv3 Host Patch =
available for Redhat=20
Linux2.4.2 ?  I found one for 2.4.0 in the Sprintlabs site.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Can that be used for 2.4.2 =
also.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thanks in Advance</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Vinod</FONT></DIV></BODY></HTML>

------=_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 <idmr-archive@lists.ietf.org>; 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 <g.15284-0@pan2.cs.ucl.ac.uk>;
          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 <g.15278-0@pan2.cs.ucl.ac.uk>; Mon, 12 Nov 2001 04:28:33 +0000
Received: from acsys.anu.edu.au by bells.cs.ucl.ac.uk with Internet SMTP 
          id <g.20852-0@bells.cs.ucl.ac.uk>; 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 <Markus.Buchhorn@anu.edu.au>
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 <idmr-archive@lists.ietf.org>; 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 <g.18603-0@pan2.cs.ucl.ac.uk>;
          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 <g.18597-0@pan2.cs.ucl.ac.uk>; 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 <g.00809-0@bells.cs.ucl.ac.uk>; 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 <kouvelas@cisco.com>
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 <idmr-archive@lists.ietf.org>; 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 <g.18909-0@pan2.cs.ucl.ac.uk>;
          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 <g.18618-0@pan2.cs.ucl.ac.uk>; 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 <g.01345-0@bells.cs.ucl.ac.uk>; 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 <holbrook@cisco.com>
To: Isidor Kouvelas <kouvelas@cisco.com>
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 <idmr-archive@lists.ietf.org>; 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 <g.18929-0@pan2.cs.ucl.ac.uk>;
          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 <g.18658-0@pan2.cs.ucl.ac.uk>; 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 <g.03014-0@bells.cs.ucl.ac.uk>;
          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 <falko.dressler@rrze.uni-erlangen.de>
To: Isidor Kouvelas <kouvelas@cisco.com>
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: <Pine.GSO.4.02A.10111190859580.11877-100000@lisa.rrze.uni-erlangen.de>
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 <idmr-archive@lists.ietf.org>; 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 <g.18889-0@pan2.cs.ucl.ac.uk>;
          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 <g.18517-0@pan2.cs.ucl.ac.uk>; Mon, 19 Nov 2001 02:06:10 +0000
Received: from cypher.cisco.com by bells.cs.ucl.ac.uk with Internet SMTP 
          id <g.28575-0@bells.cs.ucl.ac.uk>; 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 <eckert@cisco.com>
To: Magma@innovationslab.net, idmr@cs.ucl.ac.uk
Cc: Hugh Holbrook <holbrook@cisco.com>, Isidor Kouvelas <kouvelas@cisco.com>,
        ajit@torrentnet.com, fenner@research.att.com,
        Stephen Deering <deering@cisco.com>
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 <idmr-archive@lists.ietf.org>; 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 <g.19090-0@pan2.cs.ucl.ac.uk>;
          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 <g.19084-0@pan2.cs.ucl.ac.uk>; Mon, 19 Nov 2001 15:46:44 +0000
Received: from motgate3.mot.com by bells.cs.ucl.ac.uk with Internet SMTP 
          id <g.08754-0@bells.cs.ucl.ac.uk>; 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 <idmr@cs.ucl.ac.uk>; 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 <idmr@cs.ucl.ac.uk>; Mon, 19 Nov 2001 08:45:40 -0700 (MST)]
Received: by il06exw10.corp.mot.com with Internet Mail Service (5.5.2654.52) 
          id <W4NDLGGH>; Mon, 19 Nov 2001 09:45:39 -0600
Message-ID: <FB578B06F252D511B95B009027E3267B01FE6A15@il06exm04.corp.mot.com>
From: Jung Cyndi-ACJ099 <ACJ099@motorola.com>
To: "'holbrook@cisco.com'" <holbrook@cisco.com>,
        Isidor Kouvelas <kouvelas@cisco.com>
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 <idmr-archive@lists.ietf.org>; 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 <g.19189-0@pan2.cs.ucl.ac.uk>;
          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 <g.19130-0@pan2.cs.ucl.ac.uk>; Mon, 19 Nov 2001 17:03:29 +0000
Received: from cypher.cisco.com by bells.cs.ucl.ac.uk with Internet SMTP 
          id <g.16082-0@bells.cs.ucl.ac.uk>; 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 <eckert@cisco.com>
To: Hugh Holbrook <holbrook@cisco.com>
Cc: Isidor Kouvelas <kouvelas@cisco.com>, 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 <idmr-archive@lists.ietf.org>; 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 <g.22305-0@pan2.cs.ucl.ac.uk>;
          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 <g.22230-0@pan2.cs.ucl.ac.uk>; Mon, 26 Nov 2001 11:19:15 +0000
Received: from odin.ietf.org by bells.cs.ucl.ac.uk with Internet SMTP 
          id <g.14461-0@bells.cs.ucl.ac.uk>; 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 <idmr-archive@lists.ietf.org>; 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 <g.23249-0@pan2.cs.ucl.ac.uk>;
          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 <g.23243-0@pan2.cs.ucl.ac.uk>; 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 <g.05970-0@bells.cs.ucl.ac.uk>;
          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 <fenner@research.att.com>
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