Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")
RFC 4605
No Objection
Recuse
Note: This ballot was opened for revision 06 and is now closed.
(Alex Zinin; former steering group member) No Objection
(Allison Mankin; former steering group member) No Objection
(Bert Wijnen; former steering group member) No Objection
(David Kessens; former steering group member) No Objection
(Harald Alvestrand; former steering group member) No Objection
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.
(Jon Peterson; former steering group member) No Objection
(Margaret Cullen; former steering group member) (was Discuss, Yes) No Objection
(Russ Housley; former steering group member) No Objection
(Scott Hollenbeck; former steering group member) No Objection
(Steven Bellovin; former steering group member) No Objection
(Ted Hardie; former steering group member) No Objection
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.
(Thomas Narten; former steering group member) No Objection
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?)
(Bill Fenner; former steering group member) Recuse