Re: [AVT] FW: New Version Notification for draft-begen-avt-rtp-cnames-00

["Dan Wing" <[e-mail]>]

> The importance of using unique CNAMEs was brought up during 
> the RAMS wglc. Rather than specifying some rules in the RAMS 
> draft, the following draft attempts to revise the related 
> section of 3550 and the RAMS draft will simply provide a reference.
> 
> http://www.ietf.org/id/draft-begen-avt-rtp-cnames-00.txt
> 
> Comments are welcome.

It is not just hosts with 'private IP addresses' that need to follow the
guidelines in this draft, although they are the most obvious violators.  The
problem is two hosts using the same IP address -- even if they have public
IPv4 addresses (non-RFC1918 addresses).

For example, http://tools.ietf.org/html/draft-miles-behave-l2nat-00 describes
how two hosts might be provided the same public IPv4 address:

   "... For
   example, multiple PPP subscribers could be assigned the exact same
   IPv4 address through IPCP and the L2-Aware NAT will translate all
   packets to an external/WAN public IPv4 address by including
   subscriber-identifier as an additional delimiter in the NAT mapping
   table.
   ..."

There are other situations where this can occur, too (without layer-2-aware
NATs).


I suggest changing the title and abstract to be more inclusive; the problem
isn't just with RFC1918 interfaces.


In draft-begen-avt-rtp-cnames-00, Section 3 says:

   A host that does not know its fully qualified domain name, and is
   configured with a private IP address on the interface it is using for
   RTP communication, SHOULD use the numeric representation of the
   layer-2 (MAC) address of the interface it is using for RTP
   communication as the "host" part of its CNAME.

So, this means if the host changes from a wired interface to a WiFi interface,
its CNAME will change.  Is that acceptable?  (I don't know if it is acceptable
or not).



* Section 1:

   As noted in [RFC3550], the use of private network address space
   (e.g., 10.0.0.0/8) can result in hosts having network addresses that
....^^^^^^^^^^^^^^^^
  (it would be better to reference RFC1918)

   are not globally unique, and can lead to non-unique CNAMEs if hosts
   with private addresses and no direct IP connectivity to the public
   Internet have their RTP packets forwarded to the public Internet
   through an RTP-level translator.

Add something like,

  "The problem is not solely with private network addresses, but also
   occurs with public IP addresses, where multiple hosts are assigned 
   the same public IP address and connected to a NAT 
   [I-D.miles-behave-l2nat]."



Section 3,

   In private IP networks, using the numeric representation of the
......^^^^^^^^^^^^^^^^^^^
I fear this is not the sufficient guidance.  We should just recommend
everyone on IPv4 use something better than their IPv4 address --
it is too hard for a host to know if it is behind a NAT.

   private IP address as the RTCP CNAME is NOT RECOMMENDED, since it
   results in RTCP CNAMEs that are not globally unique.


In Section 3, I would say something like:

  "In order to meet the SHOULD requirement of Section 6.5.1 of
   [RFC3550], ..."

Afterall, draft-begen-avt-rtp-cnames is not creating or 
changing RFC3550, it is merely pointing out that while IPv4 
addresses are suggested in RFC3550, IPv4 addresses are 
insufficiently unique to satisfy RFC3550's 'CNAME identifier
SHOULD also be unique' requirement.

-d