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

 

Jean-Jacques Pansiot <[email protected]> wrote:

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

Such rewriting of the destination IP address, which creates a different
multicast realm, is complicated.  It's out of scope in the current document,
on purpose; it is fraught with problems (imagine if the session announcement
arrived via email, for example, instead of via SAP -- the NAT couldn't
rewrite it.  Similarly if it was communicated via HTTPS (instead of HTTP)).
The document currently says this in the introduction:

   As with normal NAPT operation for unicast flows, multicast packets
   received from the outside interface and forwarded to the inside
   interface do not have their source IP addresses changed.  Such
   multicast packets do not need to have their destination IP address
   changed (unless the NAT device wishes to establish septate multicast
   domains, but this is not the typical operation).

If this needs to be strengthened, please let me know.  Perhaps we need to
strongly discourage such an operation with requirements.

-d


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