Subject: [BEHAVE] I-D ACTION:draft-ietf-behave-multicast-09.txt

From: [email-masked]
Date: Wed, 15 Aug 2007 16:15:01 -0400

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF.

	Title		: IP Multicast Requirements for a Network Address (and port) Translator (NAT)
	Author(s)	: T. Eckert, D. Wing
	Filename	: draft-ietf-behave-multicast-09.txt
	Pages		: 16
	Date		: 2007-8-15
	
This document specifies requirements for a Network Address (and port)
   Translator (NAT) that supports any source IP multicast or source
   specific IP multicast.  An IP multicast-capable NAT device that
   adheres to the requirements of this document can optimize the
   operation of IP multicast applications that are generally unaware of
   IP multicast NAT devices.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-behave-multicast-09.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-behave-multicast-09.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-behave-multicast-09.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Behave mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/behave

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 15 Aug 2007 15:36:52 -0700

I am starting the 3rd WGLC on draft-ietf-behave-multicast-09, "IP Multicast
Requirements for a Network Address (and port) Translator NAT".  The WGLC ends
on September 3.  The previous WGLCs were for -06 and -03 (which also went to
IESG).

Draft-ietf-behave-multicast-09 integrates all of the comments received to
date.  Significant changes from -08 include:

* Consideration of Gorry Fairhurst's comments in Chicago about a multicast
source inside of a multi-homed network; unfortunately the best I could
describe to deal with that problem was the new requirement 5-a:

           "a:  If a network is multihomed, the NATs or the network
                configuration MUST ensure that duplicate instances of
                the multicast data traffic does not appear on the public
                network.  This can be accomplished by network design (an
                access control list) or a protocol between the NATs
                (e.g., the NAT with the higher IP address transmits
                multicast data towards the public network and other NATs
                drop it)."

* a NAT with multiple public interfaces SHOULD pair for multicast in the same
way it pairs for unicast (new requirement 4-c).

* The "application considerations" section has been moved to an appendix, as
it seems outside the scope of a document describing the behavior for NATs.

Differences between -09 and -08:
 
http://tools.ietf.org/rfcdiff?url2=http://tools.ietf.org/id/draft-ietf-behave-
multicast-09.txt
  http://tinyurl.com/yqej5l

Differences between -09 and -06:
 
http://tinyurl.com/create.php?url=http://tools.ietf.org/rfcdiff?url1=http://to
ols.ietf.org/id/draft-ietf-behave-multicast-06.txt&url2=http://tools.ietf.org/
id/draft-ietf-behave-multicast-09.txt
  http://tinyurl.com/yulw5t

Please reply with any comments.
-d

---

From: Stig Venaas <[email-masked]>
Date: Thu, 16 Aug 2007 10:15:10 +0200

> on September 3.  The previous WGLCs were for -06 and -03 (which also went to
[...]

Here are my thoughts upon reading this draft.

In section 3 background it says:

   This specifically means that IGMP protocol packets sent by the NAT
   device will always use IP address of the interface (inside or
   outside) to which they are sent, but because those packets are
           ^^^^^
   logically "sourced" and not "forwarded", NAT does not have any impact
   into this.

I might be confused here, but shouldn't it be "_from_ which they are
sent"?

In 4.1.1:

   REQ-1:   For IP multicast packets that are forward to a host(s) on
                                              ^^^^^^^^^
forwarded

My only substantial comment is regarding 4.3 and RTP.

I think it should be noted that there might be SSRC collisions that
are not detected since RTP packets from different hosts behind a NAT
might appear to be from the same. One could then note that CNAME
(defined in RFC 3550) might be of help. One interesting thing here
is that hosts might use their IP address to construct the CNAME. This
means that their private addresses may be exposed. I don't know how
serious a problem that is though... However, it is not unlikely that
two hosts behind two different NATs have the same private IP
address. If they both source RTP, they may pick the same CNAME which
is a problem.

RFC 3550 says in 6.5.1:

   applications MAY provide a means to configure a unique CNAME, but the
   burden is on the translator to translate CNAMEs from private
   addresses to public addresses if necessary to keep private addresses
   from being exposed.

Doing this however, could mean that two multicast sources behind the
same NAT end up sending RTP with the same CNAME, so I don't know how
good that is.

Anyhow, I believe this draft should note some of the issues with CNAME.

Finally, one tiny editorial comment. At least I would write
"Source-Specific Multicast" rather than "source specific multicast", and
"Any Source Multicast" rather than "any source multicast". At least I
find this easier to read.

Stig

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 16 Aug 2007 12:31:22 -0700

Stig Venaas wrote:

> Dan Wing wrote:
> > I am starting the 3rd WGLC on 
> > draft-ietf-behave-multicast-09, "IP Multicast
>    logically "sourced" and not "forwarded", NAT does not have 
>    any impact into this.
> 

Thanks, I made those adjustments in -10, which I expect will
be sent to IESG.

> Anyhow, I believe this draft should note some of the issues 

I agreed.  

Would the following additional text in the non-normative
Application Considerations appendix be sufficient:

   As many NATs use the same private address space (e.g.,
   192.168.0.0/16, [RFC1918]), RTP stacks are encouraged to generate
   CNAMEs properly (see end of Section 6.5.1 of [RFC3550].)

Please let me know if that is suitable.

> find this easier to read.

Done.  That does help readability.

Thanks for your review.

-d