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

Brian / Dan:

 

"Unicast" TCP/UDO sessions are uniquely identified by the tuple

 

 ( source IP address, source TCP/UDP port, target IP address, target TCP/UDP port )

 

Routers use IP addresses to send and receive the information. NAPT can change the insider interface IP and port and TCP/UDP sessions are ok.

 

Multicast routing is different because it uses also the multicast group address for routing.  I think at least this is a point to consider and to debate when talking about a multicast NAPT. This was the reason of my e-mail of yesterday with the example of the problem of two senders behind NAPT using the same multicast group and how outside routers consider this traffic as coming from only one source.

 

Ideally a multicast NAPT should do the same function of a unicast NAPT: establish multicast sessions changing parameters that uniquely identify each multicast session.

 

One problem is how the receiver will contact with the sender behind the NAPT. But there is still the same problem if the NAPT don't change the multicast address. I think this problem is out of the scope of the BEHAVE draft.

 

I think it is difficult to know today how multicast sessions will be used in the future and which parameters will be used to establish sessions and how sessions will be started. One solution is to consider this out of the scope of the document but I think is a good idea to mention it.

 

Regards


Alvaro


________________________________

De: Brian Haberman [mailto:[email protected]]
Enviado el: jue 07/06/2007 15:15
Para: Dan Wing
CC: 'Marshall Eubanks'; [email protected]; Alvaro Fernandez; [email protected]; [email protected]; 'Marshall Eubanks'; Toerless Eckert
Asunto: 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.

Regards,
Brian