Re: [MBONED] multiple SSM sources behind a NAT
Bharat Joshi <[email protected]> Tue, 17 Jul 2007 11:34:35 +0530
| Newsgroups | gmane.ietf.magma,gmane.ietf.nat.behave |
|---|---|
| Organization | Infosys Technologies Ltd |
| Message-ID | <1184652275.14104.83.camel@magadha> |
Dan, > The problem is that if two (or more) SSM sources are on the 'inside' > of a NAT, they can choose the same multicast IP address (G). This > works fine on the 'inside' of the NAT -- they are distinguished > because their SSM channel is unique because they have different > source IP addresses (S). However, if their traffic is NATted, they > will share the same IP source address on the Internet, as in the > following diagram: > > +-----+ > SSM source A -----+ | > 192.168.1.1 | NAT +------------- Internet > | |192.0.2.1 > SSM source B -----+ | > 192.168.1.2 +-----+ > > > There seems to be only one viable approach to address this problem: > > First SSM source wins and new SSM source loses. That is, when the > number of SSM sources exceeds the number of public IP interfaces, the > first SSM source(s) win, and the newest SSM source loses. That is, > the newest SSM source's traffic is not forwarded towards the public > interface. > > Difficulties: > > - NAT can't detect that first SSM source has finished sending and > the block should be removed, except with a timeout. How long > should we recommend for that timeout? > > - We can't communicate to the losing SSM source that its SSM data > isn't being forwarded by the NAT. > > - Do we want to RECOMMEND that a NAT allow the NAT administrator > to override this behavior, and transmit multicast packets > without regard to this problem? (This is functionally the same > as using a timeout of 0ms). > First of all, for SSM, receives MUST know the source address so that they can subscribe to the SSM channel [A given S,G pair]. In the first place, I would say that this would be a wrong configuration. If someone wants to support this and gateway does NAT, NAT device could change the group address to something different. But there should be a way for receivers to find out what group address NAT device chooses for a given stream. Not allowing a second stream destined to same SSM group looks fine. I am not sure if receivers can differentiate the streams based on the destination port [if stream is destined for one] but this will not work if the hosts inside NAT uses the same destination port also. My 2 cents. Thanks, Bharat **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS***