Re: [MBONED] multiple SSM sources behind a NAT

Hello;

On Jul 16, 2007, at 9:14 PM, Dan Wing wrote:

> 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.

Why not change the SSM group, say by incrementing the second address  
by one until it is unique.

- On the outside of the NAT, the SSM channel will be unique,  
regardless of what G is chosen.
- I can't think of a multicast situation where the inside and outside  
of the NAT will communicate about
this.
- In either case, the source cannot easily communicate the channel  
address, as you are changing the S address
anyway. Given that, it is not clear how much use we can expect of SSM  
broadcasts from within the NAT to outside.

Regards
Marshall


>
> -d
>
>
>
>
>
> _______________________________________________
> MBONED mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/mboned