Re: [BEHAVE] RE: FW: WGLC: draft-ietf-behave-multicast-06.txt
Brian Haberman <[email protected]>
| Newsgroups | gmane.ietf.mboned,gmane.ietf.magma,gmane.ietf.nat.behave |
|---|---|
| Message-ID | <[email protected]> |
Dan Wing wrote: >> 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]. The main issue being that on the upstream interface of the NAPT, the same source address will be used for the Report and Done message. So depending on the order of those messages, traffic may stop temporarily (until the router sends another Query). > > 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. I would favor aggregation for all flavors of IGMP. The implementations of RFC 4605 that I have seen do this. Regards, Brian _______________________________________________ MBONED mailing list [email protected] https://www1.ietf.org/mailman/listinfo/mboned