Re: [MBONED] WGLC for draft-ietf-behave-multicast-09

Dan Wing wrote:
> 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).
[...]

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