Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")
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' **)
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' **)
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' **)
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?)