multiple SSM sources behind a NAT
"Dan Wing" <[email protected]> Mon, 16 Jul 2007 18:14:37 -0700
| Newsgroups | gmane.ietf.nat.behave,gmane.ietf.magma |
|---|---|
| Message-ID | <[email protected]> |
During some offline discussions, Prashant Jhingran brought up an issue
we aren't sure how to best resolve.
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).
Comments and additional suggestions are welcome.
-d