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

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 14 Apr 2010 11:57:59 -0700

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

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]] 
Sent: Wednesday, April 14, 2010 2:55 PM
To: Ali C. Begen (abegen)
Cc: [email-masked]
Subject: New Version Notification for draft-begen-avt-rtp-cnames-00 

A new version of I-D, draft-begen-avt-rtp-cnames-00.txt has been successfully submitted by Ali Begen and posted to the IETF repository.

Filename:	 draft-begen-avt-rtp-cnames
Revision:	 00
Title:		 Guidelines for Choosing an RTP Control Protocol (RTCP) Canonical Name (CNAME) for Hosts with Private IP Addresses
Creation_date:	 2010-04-14
WG ID:		 Independent Submission
Number_of_pages: 4

Abstract:
The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a
persistent transport-level identifier for an RTP endpoint.  While the
Synchronisation Source (SSRC) identifier of an RTP endpoint may
change if a collision is detected, or when the RTP application is
restarted, the CNAME is meant to stay unchanged, so that RTP
endpoints can be uniquely identified and associated with their RTP
media streams.  For proper functionality, CNAMEs should be unique
within the participants of an RTP session.  The recommendations for
choice of the RTCP CNAME provided in RFC 3550 are insufficient to
achieve uniqueness in some environments, particularly private IP
networks.  This memo updates the guidelines in RFC 3550 to allow
endpoints to choose unique CNAMEs in these environments.

The IETF Secretariat.

---

From: Peter Musgrave <[email-masked]>
Date: Wed, 14 Apr 2010 15:32:35 -0400

Hi Ali,

I remember the discussion. This was a bit of a "D'oh" moment for me -
since I had simply not thought about it carefully before.

I think this is an important revision.

Thanks,

Peter Musgrave

On Wed, Apr 14, 2010 at 2:57 PM, Ali C. Begen (abegen) <[email-masked]> wrote:
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 15 Apr 2010 10:08:40 -0700

On 04/14/2010 11:57 AM, Ali C. Begen (abegen) wrote:
> 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.
> 
> Comments are welcome. -acbegen

Did you consider using UUID (RFC 4122) instead of MAC addresses?

> 
> 
> -----Original Message----- From: IETF I-D Submission Tool
> [mailto:[email-masked]] Sent: Wednesday, April 14, 2010 2:55 PM To:
> Ali C. Begen (abegen) Cc: [email-masked] Subject: New Version Notification
> for draft-begen-avt-rtp-cnames-00
> 
> 
> A new version of I-D, draft-begen-avt-rtp-cnames-00.txt has been successfully
> submitted by Ali Begen and posted to the IETF repository.
> 
> Filename:	 draft-begen-avt-rtp-cnames Revision:	 00 Title:		 Guidelines for
> Choosing an RTP Control Protocol (RTCP) Canonical Name (CNAME) for Hosts with
> Private IP Addresses Creation_date:	 2010-04-14 WG ID:		 Independent
> Submission Number_of_pages: 4
> 
> Abstract: The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a 
> Synchronisation Source (SSRC) identifier of an RTP endpoint may change if a
> collision is detected, or when the RTP application is restarted, the CNAME is
> meant to stay unchanged, so that RTP endpoints can be uniquely identified and
> associated with their RTP media streams.  For proper functionality, CNAMEs
> should be unique within the participants of an RTP session.  The
> recommendations for choice of the RTCP CNAME provided in RFC 3550 are
> insufficient to achieve uniqueness in some environments, particularly private
> IP networks.  This memo updates the guidelines in RFC 3550 to allow endpoints
> to choose unique CNAMEs in these environments.

-- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 15 Apr 2010 11:35:43 -0700

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

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

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 15 Apr 2010 12:17:12 -0700

> Did you consider using UUID (RFC 4122) instead of MAC addresses?

No, but looks like a good idea. Another offline suggestion was to use IPv6 addresses, which will be unique, too. We will touch on these points in the next revision. 

Thanks,
-acbegen