Subject: [BEHAVE] 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
> 

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

---

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: Bharat Joshi <[email-masked]>
Date: Tue, 05 Jun 2007 10:18:28 +0530

Hi Dan,

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

* In section 4.2, why is it that a NAPT device implementing this draft
needs to aggregate IGMP message only for IGMPv3? I think if it is
implementing 'RFC4605', it will anyway do the aggregation.

* In case of IGMPv3, why is it that aggregation is a MUST? Also I think
when one of the hosts behind the NAPT generates LEAVE and another
generates JOIN simultaneously, the session will be UP till the
group-timer timesout and as JOIN is also received, it will be updated
and so session will always be UP. Am I mixing the session created in
NAPT with the state in upstream router?

* Typo "lesaving the session" -> "leaving the session"

* In section 4.4, though complete Multicast Range is 224/4 but out of
this range 232/8 is used for Source Specific Multicast or Single-Source
Multicast. So is the following statement syntactically correct

"Any-sosurce multicast (ASM) uses the IP addresses in the 224.0.0.0 -
239.255.255.255 range [IANA-ALLOC]."

What I meant is that it looks to be incorrect to call this range as ASM
range.

* In section 4.4,

     a.  This UDP mapping SHOULD be destroyed when the host leaves
         that host group.

  How do we find out that host has left the group? Please correct me if
I am wrong. We are talking about a host behind the NAPT device
generating Multicast data traffic [UDP traffic]. A multicast host does
not need to join the multicast group [By sending an IGMP join message]
to send multicast traffic to that group. So how does NAPT finds out when
it can destroy this mapping and so this mapping will have to timeout
before it can be removed.

Thanks & Regards,
Bharat

PS: I am not subscribed to 'behave' mailing list so please reply-all or
include my id in your reply.

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

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***

---

From: Prashant Jhingran <[email-masked]>
Date: Tue, 05 Jun 2007 14:10:54 +0530

Hi,

I have following comments on this draft:

Comment 1:
------------
Since NAPT is not applicable to IPv6 [RFC2460] then no need
to mention MLD along with  IGMP in the draft.

Comment 2:
------------
In Section 4.2, aggregation is made optional while in
section 4.3 its mandatory.
However the reason given for failure of not implementing 4.3
is also applicable  when 4.2 is not implemented. Moreover,
an IGMP device should perform aggregation for optimization
purposes.
Therefore REQ-2 & REQ-3 should be combined and aggregation
should be made  mandatory for all versions of IGMP.

Comment 3:
------------
On Page 4 of the draft:
"based on forwarding state established by the IGMP/MLP proxy
routing."

It should be Should be "IGMP/MLD" instead of typo "IGMP/MLP"

Regards,
Prashant Jhingran

Huawei Technologies
+91-80-41117676 Ext -5129
Mobile:+91-9448927814

============================================
"Sing, dance, serve, meditate and celebrate" 
- Sri Sri Ravi Shankar      www.artofliving.org
============================================

This e-mail and attachments contain confidential information
from HUAWEI, which is intended only for the person or entity
whose address is listed above. Any use of the information
contained herein in any way (including, but not limited to,
total or partial disclosure, reproduction, or dissemination)
by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please
notify the sender by phone or email immediately and delete
it!
=========

-----Original Message-----
From: Dan Wing [mailto:[email-masked]] 
Sent: Tuesday, June 05, 2007 5:08 AM
To: [email-masked]; [email-masked]
Cc: 'Behave WG'
Subject: [magma] FW: WGLC:
draft-ietf-behave-multicast-06.txt

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.

-Dan Wing

> Requirements for a Network Address Port Translator
(NAPT)", 
http://www.ietf.org/internet-drafts/draft-ietf-behave-multic
as

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

---

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: "Dan Wing" <[email-masked]>
Date: Tue, 5 Jun 2007 17:48:04 -0700

> From: Bharat Joshi [mailto:[email-masked]] 
> Sent: Monday, June 04, 2007 9:48 PM
> To: [email-masked]
> Subject: [BEHAVE] Re: [MBONED] FW: WGLC: 

Thanks for your comments!

> . to its submission

It's my understanding that things will work -- somewhat sub-optimally --
with IGMPv1 or IGMPv2 without the NAT doing aggregation of IGMPv1/v2
messages and blindly just forwarding them upstream.

If my understanding is incorrect, please let me know (it may well be;
multicast is not my expertise).

Slightly after that requirement in the document is this explanation:

    >
    >  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 leaving 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 <xref
    >  target="RFC3376"></xref>.
    >

> * Typo "lesaving the session" -> "leaving the session"

Thanks, fixed.

> What I meant is that it looks to be incorrect to call this 
> range as ASM range.

You're right.  I pulled this from the Terminology section of RFC3569 
("An Overview of Source-Specific Multicast (SSM)").  I have adjusted
my document so that it describes the ASM space as 224/8 through
231/8 and 233/8 through 239/8 (with a hole for 224/8).

>   How do we find out that host has left the group? Please 
> correct me if I am wrong.
> We are talking about a host behind the NAPT device

Ah, good point which I hadn't considered.  I have removed that 
requirement.

> Thanks & Regards,
> Bharat
> 
> PS: I am not subscribed to 'behave' mailing list so please 
> reply-all or include my id in your reply.

-d

> This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION 
> intended solely for the use of the addressee(s). If you are 
> not the intended recipient, please notify the sender by 
> e-mail and delete the original message. Further, you are not 
> to copy, disclose, or distribute this e-mail or its contents 
> to any other person and any such actions are unlawful. This 
> e-mail may contain viruses. Infosys has taken every 
> reasonable precaution to minimize this risk, but is not 
> liable for any damage you may sustain as a result of any 
> virus in this e-mail. You should carry out your own virus 
> checks before opening the e-mail or attachment. Infosys 
> reserves the right to monitor and review the content of all 
> messages sent to or from this e-mail address. Messages sent 
> to or from this e-mail address may be stored on the Infosys 
> e-mail system.

---

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

> From: Prashant Jhingran [mailto:[email-masked]] 
> Sent: Tuesday, June 05, 2007 1:41 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [magma] FW: WGLC: draft-ietf-behave-multicast-06.txt
> 
>  
> Hi,
> 

Removed.  Thanks.

> is also applicable  when 4.2 is not implemented.

I'll have to dig into that deeper.  I was under the impression
the same problem (loss of a multicast stream when different 
listners behind the same proxy left and joined) didn't occur 
with IGMPv1 or v2.

> Moreover,

Agreed, and I'll add a suggestion to that effect.  (Of course,
if we find that IGMPv1-3 all require aggregation in order to
avoid missing portions of multicast streams during leave/join
by different hosts behind the NAT, I'll drop the suggestion
as it'll become a hard MUST-level requirement.)

> should be made  mandatory for all versions of IGMP.

I fixed the typo by deleting MLD.  

Thanks for your review.   There is another thread, CC'd to 
magma and mboned, where the aggregation issue was also brought
up; I'll probably consolidate the conversation about that point
in that thread.

-d

---

From: Bharat Joshi <[email-masked]>
Date: Wed, 06 Jun 2007 10:55:01 +0530

Hi Dan,

    Please see my replies in line.

Thanks,
Bharat

> multicast is not my expertise).

Things should work even if we do not aggregate IGMPv3 message also. Why
we do aggregation is that we do not want to send multiple messages
upstream? Because upstream would forward multicast data traffic if he
knows that there is atleast one host interested in a group.

Aggregating IGMPv3 is a little more complex than V1 and V2.

I just wanted to point out that if an NAPT is implementing RFC 4605 than
it should be aggregating all versions of IGMP. So why do you want to
specifically mention the case for IGMPv3?

>     >  target="RFC3376"></xref>.

Thats exactly why I raised this question. How does this creates an
issue? This can happen in a host as well. Lets say application just
started and send a join and immediately after this because of some
failure, it goes down and send a leave. I am not sure what the problem
is.

> 231/8 and 233/8 through 239/8 (with a hole for 224/8).

I think this may not be completely correct. This is because 239/8 is
available to administrator and they can use this for SSM within a given
domain.

> Ah, good point which I hadn't considered.  I have removed that 

Ok. So now how do you remove that mapping? I guess only once that times
out. Right?

---

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

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

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

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: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 6 Jun 2007 15:02:52 -0400

> From: Marshall Eubanks [mailto:[email-masked]] 

> On Jun 6, 2007, at 1:01 PM, Brian Haberman wrote:

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

Port translation is only important within the NAPT device itself.
Whereas in multicast, the problem is how to advertize the address of the
group, and how to make sure this address remain stable. I think manual
configuration is probably a good bet, if not the only way.

Bert

---

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

> 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: Brian Haberman <[email-masked]>
Date: Wed, 06 Jun 2007 13:01:08 -0400

Marshall Eubanks wrote:

>>>>>
>>>>>
>>>>> 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?
>>>>
>>>
>>> Why would it need this ? ASM - (*,G) : SSM (S,G) ?
>>> 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.
>>
> 
> This has to be supported IMHO.
> 

Regards,
Brian

---

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,
     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: Marshall Eubanks <[email-masked]>
Date: Wed, 6 Jun 2007 14:51:47 -0400

Marshall

---

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

Marshall Eubanks wrote:
> Hello;
> 
> On 6/6/07, Brian Haberman <[email-masked]> wrote:
>>
>>
>> Alvaro Fernandez wrote:
>> > Brian:
>> >
>> >
>> >
>> > 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?
>>
> 
> 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.

I assume you mean without utilizing a VPN connection?

> 
> If that multicast moves to SSM then they will need NAT traversal.
> 
> 
>> >
>> >
>> > they have the same source (the public interface) and the same multicast
>> > group address.
>> >
>>

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,

Regards,
Brian

---

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

> collisions will not occur outside the NAPT.
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: Brian Haberman <[email-masked]>
Date: Wed, 06 Jun 2007 12:22:54 -0400

> 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

>  
> 
> 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: "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

---

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

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

...
> If channels are advertised by sources using SAP for example, 
> the NAT box could translate S and G (SAP adrvertisement) on the fly
> 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

---

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

        Asunto: [magma] RE: [MBONED] FW: WGLC:

       
        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,

  Regards

     Nic

	
	
	Bert

---

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

---

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

> > If my understanding is incorrect, please let me know (it 
> > may well be; multicast is not my expertise).

(By the way, to address that weakness, I have recently added 
Toerless Eckert as a co-author.)

> Things should work even if we do not aggregate IGMPv3 message 
> also. Why we do aggregation is that we do not want to send multiple 
> messages upstream?  Because upstream would forward multicast data 
> traffic if he knows that there is atleast one host interested in 
> a group.

But if blind forwarding is done, with no aggregation, the upstream
router will see arrival and leave packets arrive in the wrong order.
We adjusted the text in -07 and I think it should be clearer now.
It now reads:

***
   4.3.  IGMPv3 NAPT

   When a IGMPv3 proxying device receives an IGMP membership on an
   inside interface, it creates its own IGMP proxying membership state
   and its own IGMP forwarding table.  It then creates an independent
   IGMP membership report on its outside interface reporting the
   multicast groups/channels -- but there is no direct relationship or
   "relaying" of IGMP membership reports or queries across the
   interfaces.  The NAPT device will subsequently receive a multicast
   data packet on the outside ('public') interface and forward the
   multicast packet to inside ('internal') interfaces based on its IGMP
   forwarding table.

   By performing NAPT on IGMPv3 membership reports, the membership
   reports appear to originate from a single IGMPv3 reporter instead of
   different reporters.  Because IGMPv3 has different types of
   membership reports differentiating between status (IS_INCLUDE,
   IS_EXCLUDE) and change indication (e.g., TO_INCLUDE, TO_EXCLUDE), if
   a NAPT were to interleave reports from two or more reporters (joining
   and leaving the same groups) the NAPT would create a sequence of
   packets that are incompliant with an IGMPv3 reporter [RFC3376].  For
   this reason,

   REQ-4:  If a NAPT supports IGMPv3, the NAPT MUST implement [RFC4605].
           Such compliance causes the NAPT to aggregate the IGMPv3
           membership reports and report only the aggregated information
           upstream.

   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 leaving the session, and the NAPT were to merely
   relay the join and leave upstream, the session will be terminated,
   and the join and leave announcements would not comply with section 5
   of [RFC3376].
***

> Aggregating IGMPv3 is a little more complex than V1 and V2.

Yes, agreed.

> I just wanted to point out that if an NAPT is implementing 
> RFC 4605 than it should be aggregating all versions of IGMP. 
>
> So why do you want to

But IGMPv1 and IGMPv2 predated RFC4605, and there have been
and still are IGMPv1/v2-aware NATs that should "work" (but
perhaps not optimally) without implementing RFC4605.  I have
removed the old REQ-1 in -07 for this reason (and based on 
some other feedback).

In -07, I adjusted the requirements so that RFC4605 is only a 
requirement for NATs that support IGMPv3, and not a requirement 
for NATs that only do IGMPv1 or only IGMPv2.  I expect to publish
-07 in the middle of next week.

> failure, it goes down and send a leave. I am not sure what the problem

If it's a single host, it brought this behavior on itself.  I believe
this is identical to the behavior without a NAPT.

> available to administrator and they can use this for SSM 
> within a given domain.

Is there some other way a NAT could make this determination?  Perhaps,
(see below) the NAT could determine the host is doing ASM because the
host is sending to the same multicast group; that may well be far easier
anyway...   Although, with SSM, RTP fixed this problem (in 
draft-ietf-avt-rtcpssm, where it suggests identifying hosts using
information other than the source transport address), thus with 
SSM traffic the NAT doesn't need to keep the UDP binding open for
60 minutes.  It's ASM RTP applications which don't follow 
draft-ietf-avt-rtcpssm's suggestions for identifying hosts that 
are the reason that requirement exists in draft-ietf-behave-multicast.

> > > How do we find out that host has left the group?  Please correct
> > > me if I am wrong.  We are talking about a host behind the NAPT
> > > device generating Multicast data traffic [UDP traffic].  A
> > > multicast host does not need to join the multicast group [By
> > > sending an IGMP join message] to send multicast traffic to that
> > > group.  So how does NAPT finds out when it can destroy this
> > > mapping and so this mapping will have to timeout before it can
> > > be removed.
> > 

Sorry -- while making this edit, I remembered the genesis of the
problem for RTP.  The problem only occurs when a host is receiving 
the same multicast stream that it is also sending to.  Specifically, 
when the host is receiving an RTP stream it will occasionally 
send RTCP reports.  With ASM, these RTCP reports are sent to the 
multicast address (so that all participants can see all other 
participants RTCP reports and adjust some RTP behaviors according 
to the size of the group).

If a host is only sending packets into an ASM stream (such as 
sending RTP packets) and isn't also listening to the stream,
we don't have this problem with RTP.  So we don't need to require
a NAT to have this 60-minute timeout.

So, I'm going to leave this requirement in -07, and have tried
to adjust the discussion/justification to describe why this
requirement is only necessary when a host is both a member of
the multicast group _and_ sends traffic to that same multicast
group.

Related, I have previously received pushback for this 60-minute 
timer being a MUST, because the difficulties this causes RTP 
aren't sufficiently significant to flat-out break interoperability 
if a NAT didn't implement that MUST.  I tend to agree with this 
comment, but would sure like to hear from others before I adjust
it.

-d

> Ok. So now how do you remove that mapping? I guess only once 
> that times out. Right?