RE: [MBONED] multiple SSM sources behind a NAT

Hello:
 
Lasth month we were disussing the same and I made the same proposal as Marshall: change the multicast group, but there is necesary some mechanism to inform of this change to multicast receivers. I think this is the problem.
This is an extract from the discussion of last month:
 

Alvaro Fernandez wrote:
> Brian:
>
>
> It is an idea regarding the BEHAVE Internet Draft and how the multicast
> NAPT can allow outside multicast routers to uniquely identify different
> multicast SSM channels (S,G) coming from inside interfaces in the case
> two inside interfaces use the same multicast group.
>

How prevalent do people expect the scenario of a SSM sender being
located behind a NAPT?

> 
>
> In the BEHAVE draft, REQ-4, if there is a host on the inside interface
> sending UDP packets to a multicast group, the NAPT can change the source
> address and the port but not the multicast group address. In this way, I
> think the outside routers can not differentiate the two channels because
> they have the same source (the public interface) and the same multicast
> group address.
>

Is it possible for the NAPT to have multiple external addresses to use
as source addresses?

> 
>
> Allowing the NAPT to change the multicast group address in the case two
> sender behind the NAPT use the same group address in a similar way the
> NATP changes a UDP port is a possible solution. There are other
> possibilities.

>From the global perspective, how does a receiver outside the NAPT know
the (S,G) combination to join?

Regards,
Brian




________________________________

De: Marshall Eubanks [mailto:[email protected]]
Enviado el: mar 17/07/2007 4:09
Para: Dan Wing
CC: [email protected]; [email protected]
Asunto: 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



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

_______________________________________________
magma mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/magma