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

Stig Venaas wrote:

> 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

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

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

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.

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

Done.  That does help readability.

Thanks for your review.

-d