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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.