Draft: draft-ietf-magma-igmp-proxy-05 Reviewer: Spencer Dawkins Date: March 29, 2004 * This draft is basically ready for publication as a Proposed Standard RFC. It is generally very well-written and clear. I have pointed out a few exceptions where things could be stated more clearly, but this document is very close to ready to go. The thing I'd REALLY like to see fixed is my comment on Section 5 (Security Considerations) ----------------------------- 1.1. Motivation Using IGMP/MLD-based forwarding to replicate multicast traffic on devices such as the edge boxes can greatly simplify the design and implementation of those devices. By not supporting more complicated multicast routing protocols such as Protocol Independent Multicast (PIM) or Distance Vector Multicast Routing Protocol (DVMRP), it reduces not only the cost of the devices but also the operational overhead. Another advantage is that it makes the proxy devices Spencer: suggest "advantage of using this mechanism is that it makes" independent of the multicast routing protocol used by the core network routers. Hence proxy devices can be easily deployed in any multicast network. Robustness in an edge box is usually achieved by using a hot spare connection to the core network. When the first connection fails, the edge box fails over to the second connection. IGMP/MLD-based forwarding can benefit from such mechanism and use the spare connection for its redundant or backup connection to multicast routers. When an edge box fails over to the second connection, the proxy upstream connection can also be updated to the new connection. Spencer: my understanding is that the mechanism for failover is outside the scope of this document - it would be nice to say so explicitly, if this is in fact the case. 2. Definitions Spencer: the definitions list is very good as far as it goes, but since multicast is something of a cult art, you might make a pass for additional entries, to accommodate readers who aren't Routing Area ADs... 3. Abstract protocol definition 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. IGMP/MLD Querier election rule defines that the Querier that has the lowest IP address wins the election (The IGMP/MLD Querier election rule is defined in IGMP/MLD specifications as part of the IGMP/MLD behavior). So in an IGMP/MLD- Spencer: a more exact pointer to a specific spec would be very nice. based forwarding only environment, if non proxy device wins the IGMP/MLD Querier election, no packets will flow. Spencer: it would be nice to explain this in a little more detail. "no packets will flow down the tree, because the proxy device isn't forwarding join requests toward the root of the tree, and nothing else is, either", or whatever the real answer is. The rest of this section is very good, I'm just looking for a one-sentence description. 4.2. Forwarding Packets A proxy device forwards packets received on its upstream interface to each downstream interface based upon the downstream interface's subscriptions and whether or not this proxy device is the IGMP/MLD Querier on each interface. A proxy device forwards packets received on any downstream interface to the upstream interface, and to each downstream interface other than the incoming interface based upon the downstream interfaces' subscriptions and whether or not this proxy device is the IGMP/MLD Querier on each interface. A proxy device MAY use a forwarding cache in order not to make this decision for each Spencer: "to avoid making this decision" packet, but MUST update the cache using these rules any time any of the information used to build it changes. Spencer: "to build the cache changes" 4.3. SSM Considerations To support Source-Specific Multicast (SSM), the proxy device should be compliant with the specification about using IGMPv3 for SSM [SSM]. Spencer: "Using IGMPv3 for Source-Specific Multicast" [SSM] Note that the proxy device should be compliant with both the IGMP Host Requirement and the IGMP Router Requirement for SSM since it Spencer: it's not clear whether these are specifications, sections in specifications, or just part of the cosmos - could you cite these more clearly? It would be great to put the titles in quotes, if these are intended to be titles... performs IGMP Host Portion on the upstream interface and IGMP Router Portion on each downstream interface. 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... IGMP/MLD-based forwarding does not provide "upstream loop" detection mechanism as described in section 3. Hence to avoid the problems caused by an "upstream loop", it MUST be administratively assured that such loops don't exist when deploying IGMP/MLD Proxying. Spencer: I'm assuming that this problem is limited by TTL decrementing in normal operation, but it would be nice to point this out - I'm talking to people who forget stuff like this in other working groups, so it's not universal knowledge these days...