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