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

Brian Haberman <[email protected]> Thu, 07 Jun 2007 09:15:31 -0400
Newsgroups gmane.ietf.nat.behave,gmane.ietf.magma
Message-ID <[email protected]>

Dan Wing wrote:
>> The NAPT knows what is SSM. Couldn't it also do a Multicast Group  
>> Translation for SSM groups ? Why
>> is this more difficult than, say, port translation ?
> 
> It may be fairly easy -- except for rewriting the advertisements in SAP,
> HTTP, HTTPS (a big problem there), email, SIP, RTSP, ....
> 
> And NAPTs don't do that kind of rewriting today; draft-ietf-behave-multicast
> is only a BCP and trying to describe what a NAT should best be doing as of
> its date of publication.
> 
> 
> If we want NAPTs to do this, we would want a different document that was
> standards-track and that document would define how we wanted NAPTs to
> perform this function.  However, I don't see a successful path if such an
> operation would require the NAPT to have an ALG for SAP, HTTP, SIP, and RTSP
> and requires the NAT also rewrite those packets.  We'd need something else.
> ALGs don't work well for a variety of reasons.

Given that, I would suggest that the document state that administrators
of the network behind the NAPT assign sub-ranges of the SSM space to
their multicast sources.  This could be done manually or *possibly* with
the tools developed by the MALLOC WG.  For the ma & pa type residential
networks, I doubt you will see multiple machines behind a NAPT sourcing
SSM.  For more corporate types, the network admin can control the
allocation of the SSM range.

Regards,
Brian