Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")
RFC 4605

Note: This ballot was opened for revision 06 and is now closed.

(Harald Alvestrand) No Objection

Comment (2004-04-01 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Reviewed by Spencer Dawkins, Gen-ART

One comment to the security section might have been a DISCUSS:

5. Security Considerations

   Since only the Querier forwards packets, the IGMP/MLD Querier
   election process may lead to black holes if a non-forwarder is
   elected Querier.  An attacker on a downstream LAN can cause itself to
   be elected Querier resulting in no packets being forwarded. However,
   there are some operational ways to avoid this problem. It is fairly
   common for an operator to number the routers starting from the bottom
   of the subnet. So an operator can assign the subnet's lowest IP
   address to a proxy in order for the proxy to win the querier
   election.

Spencer: isn't the requirement that ALL of the proxies need to be lower
than any of the queriers, in order for proxy operation to continue after a
proxy failover? That's not exactly what the last sentence of this 
paragraph says...

More comments in review.

(Steven Bellovin) No Objection

(Margaret Cullen) (was Discuss, Yes) No Objection

(Ted Hardie) No Objection

Comment (2004-03-29 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I really like the use of the applicability statement here, but I would suggest a minor extension.  This
text from section 3:

   Note that the rule that a proxy device must be the querier in order
   to forward packets restricts the IP addressing scheme used; in
   particular, the IGMP/MLD-based forwarding devices must be given the
   lowest IP addresses of any potential IGMP/MLD Querier on the link, in
   order to win the IGMP/MLD Querier election.

implies a slightly different restriction to the applicability.  I'd suggest adding
a statement to that effect to this:

   The IGMP/MLD-based forwarding only works in a simple tree topology.
   The tree must be manually configured by designating upstream and
   downstream interfaces on each proxy device. 

possibly--"The IP addressing scheme applied to the topology must also
be configured to ensure that the proxy device is assigned an appropriate
role by protocol elections."  

Though this point is made later, it clearly limits the applicability of this
to tree topologies where the IP address assignment can be managed in
this way, and so I think it would be useful to have it in the applicability statement.

(Scott Hollenbeck) No Objection

(Russ Housley) No Objection

(David Kessens) No Objection

(Allison Mankin) No Objection

(Thomas Narten) No Objection

Comment (2004-04-02 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
review of -05 (on agenda)

   The IGMP/MLD-based forwarding only works in a simple tree topology.
   The tree must be manually configured by designating upstream and
   downstream interfaces on each proxy device. There are no multicast
   routers within the tree and the root of the tree is expected to be
   connected to a wider multicast infrastructure. This protocol is
   limited to a single administrative domain.

the above defn of a multicast router is one that runs a routing
protocol. the routers still need to do multicast forwarding, so they
are still routers (in my mind).

   For example, in an IGMP/MLD-based forwarding only environment as
   shown in the figure below:

  
           LAN 1  --------------------------------------
                  Upstream |              | Upstream
                           A(non-proxy)   B(proxy)
                Downstream |(lowest IP)   | Downstream
           LAN 2  --------------------------------------

THis isn't a tree. But earlier, the document says:

   Discovery (MLD) only environment.  The topology is limited to a tree,
   since we specify no protocol to build a spanning tree over a more
   complex topology.  The root of the tree is assumed to be connected to
   a wider multicast infrastructure.

I gather the "tree" needs to be configured, but the discussion here
seems to be missing some context/caveats about why the general case is
being discussed.



>    importantly, the packets with source-specific addresses SHOULD not be

s/not/NOT/??

>    [SSM]       Holbrook, H., and Cain, B., "Using IGMPv3 for Source-
>                Specific Multicast", Work in Progress.

status of this normative reference? (what document is this?)

(Jon Peterson) No Objection

(Bert Wijnen) No Objection

(Alex Zinin) No Objection

(Bill Fenner) Recuse