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

From: Bill Fenner <[email-masked]>
Date: Mon, 27 Nov 2000 16:36:05 -0800

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: LEVIS Pierre FTRD/DMI/CAE <[email-masked]>
Date: Wed, 29 Nov 2000 09:08:45 +0100

I have a question about section 6.3 "IGMPv3 Source-Specific Forwarding
Rules" whose wording has changed in draft 5. I wonder to what extent the
filtering capabilities of IGMPv3 depend on the current routing protocol
implemented in the routers. I wonder whether the role of IGMPv3 is only to
convey membership information, the handling of this information being
entirely up to the routing protocol, or if IGMPv3 can force in certain
circumstances, a router to filter traffic whatever the routing protocol is.
In the former alternative IGMPv3 has no filtering capability per se.

Let's have an example:

Assume a host is requesting one source for a given group, e.g. a Group
Record "IS_IN(s1) for G" is sent to its router. Assume the routing protocol
implemented in the router can only do (*,G) joins, assume there's no other
request for this group and there's no more router downstream. Consider the
following scenarios: 

a) A (*,G) is processed, the whole traffic from the group is retrieved up to
the router, the router delivers all sources onto the host network

b) A (*,G) is processed, the whole traffic from the group is retrieved up to
the router, the router filters, and forwards only source s1 onto the host
network

c) The report is not taken into account at all

What is (are) the correct behavior(s) for the router? 

According to the previous wording of section 6.3 "IGMPv3 Source-Specific
Forwarding Rules" in <draft-ietf-idmr-igmp-v3-04.txt> I would say a) is NOT
a correct behavior, according to the new wording in
<draft-ietf-idmr-igmp-v3-05.txt> I'm not so sure.

What do you think?

Pierre

-----Message d'origine-----
De : Bill Fenner [mailto:[email-masked]]
Envoyé : mardi 28 novembre 2000 01:36
À : [email-masked]
Objet : WG Last Call: IGMP Version 3 to Proposed Standard

Dear IDMR WG,

Thanks,
  Bill

---

From: Bill Fenner <[email-masked]>
Date: Wed, 29 Nov 2000 11:00:42 -0800

>What is (are) the correct behavior(s) for the router? 

b) is the correct behavior.  The wording was changed because there might
be multiple upstream routers, and the routing protocol has to be allowed
to choose the correct one; the previous wording implied that all routers
would forward and the routing protocol didn't have any choice in the
matter.

The need for a document describing exactly how routing protocols react
to IGMPv3 information has been identified; however a new author for this
document needs to be identified since the person who volunteered seems
to have disappeared.

  Bill