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