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

Hi,

Just another comment:

If the sender behind the NAT uses Ethernet and maps de lower 28 bits IP multicast address ( first 4 bits are always 1110) to 23 bits in the multicast MAC address, ¿which 5 high order bits uses the NAT to send the IP multicast packets? 

Considering that SSM range is 232/8. How the NAT knows if the paquet is within the SSM range?

Regards

Alvaro

________________________________

De: Dan Wing [mailto:dwing@cisco.com]
Enviado el: lun 13/08/2007 19:30
Para: 'Brian Haberman'
CC: 'Marshall Eubanks'; mboned@ietf.org; Alvaro Fernandez; magma@ietf.org; behave@ietf.org; 'Marshall Eubanks'; 'Toerless Eckert'
Asunto: RE: [BEHAVE] Re: [magma] RE: [MBONED] FW: WGLC:draft-ietf-behave-multicast-06.txt

> -----Original Message-----
> From: Brian Haberman [mailto:brian@innovationslab.net]
> Sent: Thursday, June 07, 2007 6:16 AM
> To: Dan Wing
> Cc: 'Marshall Eubanks'; mboned@ietf.org; 'Alvaro Fernandez';
> magma@ietf.org; behave@ietf.org; 'Marshall Eubanks'; Toerless Eckert
> Subject: Re: [BEHAVE] Re: [magma] RE: [MBONED] FW:
> WGLC:draft-ietf-behave-multicast-06.txt
....
>
>
>
> 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.

I moved text discussing what applications should do into an appendix,
as the document's BCP scope is really around NATs (rather than
applications that need to handle NATs).  Based on your comment above,
and some other input, the text now has the following paragraph.  I
believe this captures your suggestion.

  "If multiple SSM sources on the inside of a NAT choose the same
   multicast group address, those sources are uniquely identifiable
   because their IP addresses are unique.  However, if their multicast
   traffic is NATted and sent on the NAT's public interface, the traffic
   from those individual sources is no longer uniquely identifiable.
   This will cause problems for multicast receivers which will see an
   intermixing of traffic from those sources.  Resolution of this issue
   is left for future study.  In the meantime, applications that source
   SSM multicast traffic are encouraged to allow the user to modify the
   multicast SSM address so that users can avoid this problem if that
   application is placed behind a NAT."

The text doesn't quite go so far to say that a range has to be assigned a
priori.  But let me know if it is acceptable.

I have not submitted -09, but a preview is here if anyone wants to see the
full context:
http://svn.resiprocate.org/rep/ietf-drafts/behave/draft-ietf-behave-multicast-
09.txt

-d