Subject: [magma] FW: WGLC: draft-ietf-behave-multicast-06.txt

From: "Dan Wing" <[email-masked]>
Date: Mon, 4 Jun 2007 16:38:17 -0700

The BEHAVE working group concluded its WGLC of
draft-ietf-behave-multicast-06 with no comments received.  I would like
MBONED and MAGMA to please take a look at this draft prior to its submission
to IESG.

Please send replies to [email-masked].  Thanks!

-Dan Wing
 chair, BEHAVE working group

> -----Original Message-----
> From: Dan Wing [mailto:[email-masked]] 
> Sent: Thursday, May 17, 2007 2:47 PM
> To: [email-masked]'
> Subject: WGLC: draft-ietf-behave-multicast-06.txt
> 
> The working group last call is starting now for "Multicast 
> Requirements for a Network Address Port Translator (NAPT)", 
> http://www.ietf.org/internet-drafts/draft-ietf-behave-multicas
> t-06.txt: 
> 
>    This document specifies requirements for a Network Address
>    Translator (NAT) and Network Address and Port Translator (NAPT)
>    that supports any-source multicast or single-source multicast.  A
>    multicast-capable NAPT device that adheres to the requirements of
>    this document can optimize the operation of multicast
>    applications that are generally unaware of multicast NAPT
>    devices.
> 
> This WGLC will finish on Thursday, May 31 (two weeks from today).
> 
> If this WGLC is successful, I will ask for review by the 
> MAGMA working group and [email-masked] prior to 
> submitting to IESG.
> 
> -d
> 

_______________________________________________
magma mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/magma

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 5 Jun 2007 10:02:13 -0400

> Sent: Monday, June 04, 2007 7:38 PM
> To: [email-masked]; [email-masked]
> Cc: 'Behave WG'
> Subject: [MBONED] FW: WGLC: draft-ietf-behave-multicast-06.txt
> 

http://www.ietf.org/internet-drafts/draft-ietf-behave-multicast-06.txt: 

What if the NAPT or NAT device just passed IGMP queries and reports
through, changing only the source address of the reports, and let the
multicast router outside do all the hard work? I'm wondering whether the
IGMP aggregation function is mandatory in NAT/NATP.

Bert

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 5 Jun 2007 17:46:54 -0700

> multicast router outside do all the hard work? I'm wondering 
> whether the IGMP aggregation function is mandatory in NAT/NATP.

For IGMPv3, you would have the problem described in the document, namely:

   Failure to do this aggregation will cause undesired temporary
   blackholing of multicast traffic.  For example, consider two hosts
   behind the same NAPT.  If one host is joining a session at the same
   time another is lesaving the session, and the NAPT merely relays the
   join and leave upstream, the session will be terminated and the join
   and leave announcements do not comply with section 5 of [RFC3376].

Based on Prashant Jhingran's comment,
<http://www1.ietf.org/mail-archive/web/behave/current/msg02373.html>, I'm
trying to determine if this 
same problem exists for IGMPv1 and IGMPv2.  If so, we will need to require
aggregating all flavors of IGMP to avoid that problem.

-d

---

From: Brian Haberman <[email-masked]>
Date: Wed, 06 Jun 2007 08:16:42 -0400

>    and leave announcements do not comply with section 5 of [RFC3376].

The main issue being that on the upstream interface of the NAPT, the
same source address will be used for the Report and Done message.  So
depending on the order of those messages, traffic may stop temporarily
(until the router sends another Query).

> aggregating all flavors of IGMP to avoid that problem.

I would favor aggregation for all flavors of IGMP.  The implementations
of RFC 4605 that I have seen do this.

Regards,
Brian

---

From: "Alvaro Fernandez" <[email-masked]>
Date: Wed, 6 Jun 2007 15:22:26 +0200

Hi all.

If you have two sources from two different inside interfaces sending multicast data to the outside interface and both sources use the same multicast address (G1) then outside routers, using for example PIM-SM, will consider that there is only one multicast channel and will send all the traffic. Also hosts receiving all the traffic need to separate it.

One solution is to reserve an IP address range inside SSM range ( for example 232.0.0.0 to 232.0.255.255) and let the NAPT change, not only the source address of the sender, but also the multicast address of the sender to be unique in this range. In this way outside routers ( and receivers ) will consider traffic as coming from different channels (IP public ,G2) and ( IP public, G3) with G2 and G3 inside the said range.

Best Regards

Alvaro 

________________________________

De: Manfredi, Albert E [mailto:[email-masked]]
Enviado el: mar 05/06/2007 16:02
Para: [email-masked]; [email-masked]; [email-masked]
Asunto: [magma] RE: [MBONED] FW: WGLC: draft-ietf-behave-multicast-06.txt

Bert

---

From: Brian Haberman <[email-masked]>
Date: Wed, 06 Jun 2007 10:06:29 -0400

Alvaro,
     I am not sure what problem this solves.  Alfred's comments had to
do with receivers behind the NAPT sending Report and Done messages that
had to be aggregated at the NAPT in order to avoid having the external
router stop the multicast stream.  What you describe *appears* to put
the senders behind the NAPT.  Could you elaborate on what your concern is?

Regards,
Brian

Alvaro Fernandez wrote:
> Hi all.
> 
>  
> 
> If you have two sources from two different inside interfaces sending
> multicast data to the outside interface and both sources use the same
> multicast address (G1) then outside routers, using for example PIM-SM,
> will consider that there is only one multicast channel and will send all
> the traffic. Also hosts receiving all the traffic need to separate it.
> 
>  
> 
> One solution is to reserve an IP address range inside SSM range ( for
> example 232.0.0.0 to 232.0.255.255) and let the NAPT change, not only
> the source address of the sender, but also the multicast address of the
> sender to be unique in this range. In this way outside routers ( and
> receivers ) will consider traffic as coming from different channels (IP
> public ,G2) and ( IP public, G3) with G2 and G3 inside the said range.
> 
>  
> 
> Best Regards
> 
>  
> 
> Alvaro
> 
> 
> ------------------------------------------------------------------------
> *De:* Manfredi, Albert E [mailto:[email-masked]]
> *Enviado el:* mar 05/06/2007 16:02
> *Para:* [email-masked]; [email-masked]; [email-masked]
> *Asunto:* [magma] RE: [MBONED] FW: WGLC: draft-ietf-behave-multicast-06.txt
> 
> ------------------------------------------------------------------------
>

---

From: "Alvaro Fernandez" <[email-masked]>
Date: Wed, 6 Jun 2007 16:59:15 +0200

Brian:

My e-mail was not an answer to Albert, sorry for that, 

It is an idea regarding the BEHAVE Internet Draft and how the multicast NAPT can allow outside multicast routers to uniquely identify different multicast SSM channels (S,G) coming from inside interfaces in the case two inside interfaces use the same multicast group.

In the BEHAVE draft, REQ-4, if there is a host on the inside interface sending UDP packets to a multicast group, the NAPT can change the source address and the port but not the multicast group address. In this way, I think the outside routers can not differentiate the two channels because they have the same source (the public interface) and the same multicast group address.

Allowing the NAPT to change the multicast group address in the case two sender behind the NAPT use the same group address in a similar way the NATP changes a UDP port is a possible solution. There are other possibilities.

Regards

Alvaro

De: Brian Haberman [mailto:[email-masked]]
Enviado el: mié 06/06/2007 16:06
Para: Alvaro Fernandez
CC: Manfredi, Albert E; [email-masked]; [email-masked]; [email-masked]
Asunto: Re: [magma] RE: [MBONED] FW: WGLC: draft-ietf-behave-multicast-06.txt

Alvaro,

Regards,
Brian

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 6 Jun 2007 11:12:18 -0400

> From: Brian Haberman [mailto:[email-masked]] 

> (until the router sends another Query).

Except that, I thought, the multicast router has to send group-specific
or group-and-source-specific queries before it stops forwarding
multicast packets, in IGMPv2 (the former only) and v3. This is supposed
to ensure that there are no members left in the group, before the
multicast router stops forwarding the packets.

So I'm not sure why there would be this gap in multicasts if everything
is working as it should.

Not that I have anything against aggregation. Just that it seems
unnecessary. It would be nice if the NAT or NAPT device could be as
transparent as possible, I think.

Bert

---

From: Brian Haberman <[email-masked]>
Date: Wed, 06 Jun 2007 12:15:28 -0400

> multicast router stops forwarding the packets.

That is true.  A conforming router would send a group-specific query
prior to changing its forwarding state.

> So I'm not sure why there would be this gap in multicasts if everything

I was using the basic model from the IGMP Proxy work where the inside
interface state is aggregated and the outside interface uses that
aggregate information within the context of the IGMP timers in use on
the external network.  That way, any gap in data forwarding would be
found in the proxy/NAPT device.

Regards,
Brian

---

From: Brian Haberman <[email-masked]>
Date: Wed, 06 Jun 2007 12:22:54 -0400

Alvaro Fernandez wrote:
> It is an idea regarding the BEHAVE Internet Draft and how the multicast
> NAPT can allow outside multicast routers to uniquely identify different
> multicast SSM channels (S,G) coming from inside interfaces in the case
> two inside interfaces use the same multicast group.
> 

How prevalent do people expect the scenario of a SSM sender being
located behind a NAPT?

>  
> 
> In the BEHAVE draft, REQ-4, if there is a host on the inside interface
> sending UDP packets to a multicast group, the NAPT can change the source
> address and the port but not the multicast group address. In this way, I
> think the outside routers can not differentiate the two channels because
> they have the same source (the public interface) and the same multicast
> group address.
> 

Is it possible for the NAPT to have multiple external addresses to use
as source addresses?

>  
> 
> Allowing the NAPT to change the multicast group address in the case two
> sender behind the NAPT use the same group address in a similar way the
> NATP changes a UDP port is a possible solution. There are other
> possibilities.

>From the global perspective, how does a receiver outside the NAPT know
the (S,G) combination to join?

Regards,
Brian

---

From: "Marshall Eubanks" <[email-masked]>
Date: Wed, 6 Jun 2007 12:40:17 -0400

Hello;

> How prevalent do people expect the scenario of a SSM sender being

I would expect that this has the potential of being fairly common.

- Enterprises use NATs a lot. (I am not going to get into the question
as to whether they should...)

- Enterprises use multicast video

- This video needs to go to remote offices, which are commonly behind
their own NATs.

If that multicast moves to SSM then they will need NAT traversal.

> Is it possible for the NAPT to have multiple external addresses to use

Why would it need this ? ASM - (*,G) : SSM (S,G) ?
Or are you worried about 2 different SSM sources using the same G.

Regards
Marshall

---

From: Brian Haberman <[email-masked]>
Date: Wed, 06 Jun 2007 12:49:11 -0400

> - This video needs to go to remote offices, which are commonly behind

I assume you mean without utilizing a VPN connection?

> Or are you worried about 2 different SSM sources using the same G.

Yes, that is the scenario Alvaro described.  Two senders using the same
G both behind the same NAPT.

Regards,
Brian

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 6 Jun 2007 12:55:39 -0400

> I assume you mean without utilizing a VPN connection?

Yes, could be.

Or could be using NAT through a VPN connection. I have seen this too.  
I have seen large company mergers
where they have extreme RFC 1918 collisions between the old pieces  
and use NATs everywhere.

> G both behind the same NAPT.

This has to be supported IMHO.

Regards
Marshall

> MBONED mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mboned

---

From: Brian Haberman <[email-masked]>
Date: Wed, 06 Jun 2007 13:01:08 -0400

> This has to be supported IMHO.

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.

I don't see an easy, automated solution.

Regards,
Brian

---

From: "Alvaro Fernandez" <[email-masked]>
Date: Wed, 6 Jun 2007 19:23:54 +0200

Brian:

1. How prevalent do people expect the scenario of a SSM sender being
located behind a NAPT?

People like to upload content: wikipedia, youtube, blogs, P2P, ... Actually they can not upload multimedia content in real time.

I think that if people can upload multicast data in real time they will do it. For example: Mobile + camera + multicast = personal IPTV 

2. Is it possible for the NAPT to have multiple external addresses to use as source addresses?

The external source address is only one. What I suggest is to change the multicast group address so each multicast channel is unique.

We can make a reservation of SSM multicast addresses for this purpose. If the NAPT detects that a multicast group in this range is used the NAPT understands that it can changes the multicast address to be unique if it is necessary.

3. From the global perspective, how does a receiver outside the NAPT know the (S,G) combination to join?

This is the problem.

P2P programs have a similar problem when locating "peers" behind NATs and there are solutions that we can imitate: DHT (dynamic hash tables), "superpeers", "torrent" files, ...

Another solution can be to identify each channel with some metadata including description of the content and use "multicast search engines" to access the desired channel in a similar way of how we actually access websites. 

It's a problem but there are solutions. I think we can leave the solution of this problem to the specific application that uses the multicast channel data. 

Regards

Alvaro

De: Brian Haberman [mailto:[email-masked]]
Enviado el: mié 06/06/2007 18:22
Para: Alvaro Fernandez
CC: Manfredi, Albert E; [email-masked]; [email-masked]; [email-masked]
Asunto: Re: [magma] RE: [MBONED] FW: WGLC: draft-ietf-behave-multicast-06.txt

Regards,
Brian

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 6 Jun 2007 14:51:47 -0400

> I don't see an easy, automated solution.

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 ?

Marshall

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 6 Jun 2007 15:08:22 -0700

> How prevalent do people expect the scenario of a SSM sender being

Not very prevalent with today's broadcast model for SSM where
the broadcaster is the video service provider.

However, we don't want to encourage proliferation of NATs which
are compliant with a BCP that do not allow SSM senders behind
those NATs.  With today's bandwidth to the home we might 
consider someone running a 'radio station' from behind a NAT.
With tomorrow's bandwidth, we might considering someone doing
video sharing to their family from behind a NAT.  Hard to say;
I would like to do this once if we know how to do it today.

> Is it possible for the NAPT to have multiple external addresses to use

Some NAPTs do that, yes -- larger ones used by service providers
and by enterprises.  Your traditional residential-class NAPT doesn't
do that, though.

> From the global perspective, how does a receiver outside the 
> NAPT know the (S,G) combination to join?

-d

> Behave mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/behave

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 6 Jun 2007 15:13:28 -0700

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

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

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 6 Jun 2007 15:20:49 -0700

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

-d

---

From: Brian Haberman <[email-masked]>
Date: Thu, 07 Jun 2007 09:15:31 -0400

> 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

---

From: "Alvaro Fernandez" <[email-masked]>
Date: Thu, 7 Jun 2007 18:53:12 +0200

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-masked]]
Enviado el: jue 07/06/2007 15:15
Para: Dan Wing
CC: 'Marshall Eubanks'; [email-masked]; Alvaro Fernandez; [email-masked]; [email-masked]; 'Marshall Eubanks'; Toerless Eckert
Asunto: Re: [BEHAVE] Re: [magma] RE: [MBONED] FW: WGLC:draft-ietf-behave-multicast-06.txt

Regards,
Brian

---

From: "Alvaro Fernandez" <[email-masked]>
Date: Fri, 8 Jun 2007 12:21:42 +0200

Leyman:

One possible solution ( out of the scope of the draft)

1. The sender behind the  NAPT sends the channel (Si,Gj) using a random Gj inside the multicast SSS range

2. Logically the sender expects that some one will be interested in the data, so the sender sends a unicast message (for example http)  to a "multicast index portal" describing the content and the channel (Si,Gj)

3. The NAPT changes the internal Si into a IP public in both cases: the unicast data and the multicast data using the same IP public.

4. The multicast portal knows the IP public and tries to connect with the multicast channel ( IP public, Gj)

If the multicast portal connects with ( IP public, Gj) there is no Gj collision and the portal shows the channel (IP public, Gj) in its index. Everybody can connect.

5. If after a few seconds the channel don't appears in the index, the senders understands that there is a multicast Group collision and changes the Gj into another randomly selected Gk.

Another business for the search engines.

Regards

Alvaro

De: Leymann, Nicolai [mailto:[email-masked]]
Enviado el: vie 08/06/2007 11:44
Para: Alvaro Fernandez; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Asunto: AW: [magma] RE: [MBONED] FW: WGLC: draft-ietf-behave-multicast-06.txt

Hi Everybody,

> Hi all.
> If you have two sources from two different inside interfaces
> sending multicast data to the outside interface and both
> sources use the same multicast address (G1) then outside
> routers, using for example PIM-SM, will consider that there
> is only one multicast channel and will send all the traffic.
> Also hosts receiving all the traffic need to separate it.
Right. This is from my point of view not the solution you want.
The reason for SSM is to have different senders (source) using
the same group and to be able to route based on (S,G) information.

> One solution is to reserve an IP address range inside SSM range
> ( for example 232.0.0.0 to 232.0.255.255) and let the NAPT change,
> not only the source address of the sender, but also the multicast
> address of the sender to be unique in this range. In this way
> outside routers ( and receivers ) will consider traffic as coming
> from different channels (IP public ,G2) and ( IP public, G3) with
> G2 and G3 inside the said range.
The main problem is how to signal either the (S,G) channel or the
multicast group if this information is changed by a NAPT device.

E.g. in a typical IPTV scenario the signalling of the group or
channel information is done out-bband using servers providing
information about the IPTV channels. Clients are receiving this
information from the server (http/xml) to join the appropriate
IPTV channels.

If a sender (S1) sends multicast traffic to a group (G1) the receiver
joins (S1,G1) due to the information it got from the server. If the
NAPT device changes this to (S2,G1) or (S1,G2) the receiver is not
going to receive any traffic.

I'm not sure if this problem can be solved without making to many
assumptions about the applications deploying IP-Multicast.

  Regards

     Nic

        De: Manfredi, Albert E [mailto:[email-masked]]
        Enviado el: mar 05/06/2007 16:02
        Para: [email-masked]; [email-masked]; [email-masked]
        Asunto: [magma] RE: [MBONED] FW: WGLC:
draft-ietf-behave-multicast-06.txt

       
        What if the NAPT or NAT device just passed IGMP queries and
reports
        through, changing only the source address of the reports, and
let the
        multicast router outside do all the hard work? I'm wondering
whether the
        IGMP aggregation function is mandatory in NAT/NATP.
       
        Bert

---

From: "Leymann, Nicolai" <[email-masked]>
Date: Fri, 8 Jun 2007 11:44:43 +0200

Hi Everybody,

If a sender (S1) sends From [email-masked] Fri Jun 08 07:20:33 2007
Content-class: urn:content-classes:message
Subject: AW: [magma] RE: [MBONED] FW: WGLC: draft-ietf-behave-multicast-06.txt
Date: Fri, 8 Jun 2007 11:44:43 +0200
From: "Leymann, Nicolai" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>,
	<[email-masked]>, <[email-masked]>
Cc: 

Hi Everybody,

  Regards

     Nic

	
	
	Bert

---

From: Jean-Jacques Pansiot <[email-masked]>
Date: Wed, 06 Jun 2007 19:18:21 +0200

Regards

     Nic

=09
=09

	> Please send replies to [email-masked].  Thanks!
=09
=09
=09
=09
=09
=09

---

From: Jean-Jacques Pansiot <[email-masked]>
Date: Wed, 06 Jun 2007 19:18:21 +0200

Brian Haberman wrote:
>>>>>> sending UDP packets to a multicast group, the NAPT can change the
>>>>>>             
>>>>> source
>>>>>           
>>>>>> address and the port but not the multicast group address. In this
>>>>>>             
>>>>> way, I
>>>>>           
>>>>>> think the outside routers can not differentiate the two channels
>>>>>>             
>>>>> because
>>>>>           
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. 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

O_RELAYS
	autolearn=disabled version=3.1.8
Cc: 

Brian Haberman wrote:
>>>>>> sending UDP packets to a multicast group, the NAPT can change the
>>>>>>             
>>>>> source
>>>>>           
>>>>>> address and the port but not the multicast group address. In this
>>>>>>             
>>>>> way, I
>>>>>           
>>>>>> think the outside routers can not differentiate the two channels
>>>>>>             
>>>>> because
>>>>>           
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. 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

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 8 Jun 2007 18:06:57 -0700

> assumptions about the applications deploying IP-Multicast.

I agree, and I'll leave such a recommendation out of the -07
revision of this document.  I expect to have -07 ready next week.

-d