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

Brian Haberman wrote:
> Marshall Eubanks wrote:
>
>   
>>>>>> 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.
>>>>
>>>>         
>>> Yes, that is the scenario Alvaro described.  Two senders using the same
>>> G both behind the same NAPT.
>>>
>>>       
>> This has to be supported IMHO.
>>
>>     
>
> But it could be supported by having an administrator inside the NAPT
> assign different groups to all the SSM senders.  That way, (S,G)
> collisions will not occur outside the NAPT.
>
>   
In any case, receivers have to learn the public (S,G), so part of the 
problem is how receivers learn channel addresses.
If channels are advertised by sources using SAP for example, the NAT box 
could translate S and G (SAP adrvertisement) on the fly
 (I dont know if this would be hard) so that they dont collide.
If channels are advertised by other means (say a web site) it seems that 
the translation in the Nat box and the advertisement
have to be closely coordinated. One way would be to use a special 
multicast address coding (for example use a hash or a suffix of the 
private source address as a part of the group address,
so that they never collide. Obviously this works only if all private 
addresses behind the NAT are distinct)

cheers
Jean-Jacques


> I don't see an easy, automated solution.
>
> Regards,
> Brian
>
> _______________________________________________
> MBONED mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/mboned
>   


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