Subject: Re: Fw: WG Last Call: IGMP Version 3 to Proposed Standard

From: Vijay Anand Chandrasekar <[email-masked]>
Date: Tue, 28 Nov 2000 17:31:16 +0530

During the last call for standardisation of IGMPv3 given about 3 months back
the need for incorporating network masks along with the source-group was
discussed at length in the mailing list.Has that feature been incorporated in
the new revision which is to be standardised.

Regards,
Vijay

> ----- Original Message -----
> From: Bill Fenner <[email-masked]>
> To: <[email-masked]>
> Sent: Tuesday, November 28, 2000 6:06 AM
> Subject: WG Last Call: IGMP Version 3 to Proposed Standard
>
> > Date: Mon, 27 Nov 2000 16:36:05 -0800
> > Versions: dmail (solaris) 2.2g
> >
> >
> > Dear IDMR WG,
> >
> >   IGMP Version 3, draft-ietf-idmr-igmp-v3-04.txt, went through a WG last
> > call with a couple of items raised at the IETF meeting in Pittsburgh.
> > draft-ietf-idmr-igmp-v3-05.{txt,ps} includes updates for these items.
> > I want to give the WG a chance to look at the document again before
> > submitting it to the IESG.  The changes include:
> >
> > - Requiring the abstract API to return an error when including too many
> >   sources, instead of allowing it to switch to EXCLUDE mode.  This
> >   function interfered with source-specific multicast.
> >
> > - Change "it may be delivered on.." to "it will be delivered on.." to
> >   make it clear that kernel filtering based upon socket memberships
> >   is required.  Added a note that this is a new feature of this API
> >   and that RFC1112 didn't require it.
> >
> > - Change "Max Response Time" and "Querier's Query Interval" to
> >   "Max Response Code" and "Querier's Query Interval Code".  The
> >   original values are now derived from the codes, allowing values
> >   greater than 128 to be treated as exponential.  This allows the
> >   maximum value of Max Response Time to represent 52 minutes instead
> >   of 25.5 seconds, and the maximum value of Querier's Query Interval
> >   is somewhere around 8.5 hours.
> >
> > - Change "forward packets" and "stop forwarding packets" to wording
> >   about informing the routing protocol of interest and lack of interest.
> >   IGMP does not make the decision about when to forward packets (e.g.
> >   when there are multiple upstreams, the routing protocol elects the
> >   proper forwarder, which then uses IGMP to gauge interest)
> >
> > - Added section 8.13, giving advice on how to configure IGMP's
> >   tunable parameters.
> >
> > - Mentioned IPSEC AH in Security Considerations.  Also point out the
> >   potential DoS attack in Group-and-Source-specific Queries with long
> >   Max Resp Time and/or with a large source list.
> >
> > Since there were so many changes, I thought it best to do another WG
> > last call.  Please comment by Wednesday, December 13, 2000, on the IDMR
> > mailing list <[email-masked]> or directly to working group chair,
> > <[email-masked]>.  (Note that this time frame includes the
> > upcoming IDMR WG meeting in San Diego, so feel free to save your comments
> > til then.)
> >
> > Thanks,
> >   Bill

---

From: Bill Fenner <[email-masked]>
Date: Tue, 28 Nov 2000 10:18:18 -0800

We determined on the mailing list and in the working group that
a) there was a rough consensus against netmasks (obviously with some
   dissent)
b) IGMPv3 has extension fields that can be used to carry netmasks if
   it becomes important.

  Bill