RE: RE: [MBONED] FW: WGLC: draft-ietf-behave-multicast-06.txt
"Dan Wing" <[email protected]>
| Newsgroups | gmane.ietf.nat.behave,gmane.ietf.magma |
|---|---|
| Message-ID | <[email protected]> |
> http://www.ietf.org/internet-drafts/draft-ietf-behave-multicas > t-06.txt: > > What if the NAPT or NAT device just passed IGMP queries and reports > through, changing only the source address of the reports, and let the > multicast router outside do all the hard work? I'm wondering > whether the IGMP aggregation function is mandatory in NAT/NATP. For IGMPv3, you would have the problem described in the document, namely: Failure to do this aggregation will cause undesired temporary blackholing of multicast traffic. For example, consider two hosts behind the same NAPT. If one host is joining a session at the same time another is lesaving the session, and the NAPT merely relays the join and leave upstream, the session will be terminated and the join and leave announcements do not comply with section 5 of [RFC3376]. Based on Prashant Jhingran's comment, <http://www1.ietf.org/mail-archive/web/behave/current/msg02373.html>, I'm trying to determine if this same problem exists for IGMPv1 and IGMPv2. If so, we will need to require aggregating all flavors of IGMP to avoid that problem. -d