Re: RE: [MBONED] FW: WGLC: draft-ietf-behave-multicast-06.txt

Hello;

On 6/6/07, Brian Haberman <[email protected]> wrote:
>
>
> Alvaro Fernandez wrote:
> > Brian:
> >
> >
> >
> > My e-mail was not an answer to Albert, sorry for that,
> >
> >
> >
> > 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?
>

I would expect that this has the potential of being fairly common.

- Enterprises use NATs a lot. (I am not going to get into the question
as to whether they should...)

- Enterprises use multicast video

- This video needs to go to remote offices, which are commonly behind
their own NATs.

If that multicast moves to SSM then they will need NAT traversal.


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

Why would it need this ? ASM - (*,G) : SSM (S,G) ?
Or are you worried about 2 different SSM sources using the same G.

Regards
Marshall


> >
> >
> > 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
>
>
> _______________________________________________
> magma mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/magma
>