draft-begen-avt-rtp-cnames-00.txt | draft-begen-avt-rtp-cnames-01.txt | |||
---|---|---|---|---|
AVT A. Begen | AVT A. Begen | |||
Internet-Draft Cisco | Internet-Draft Cisco | |||
Updates: 3550 (if approved) C. Perkins | Updates: 3550 (if approved) C. Perkins | |||
Intended status: Standards Track University of Glasgow | Intended status: Standards Track University of Glasgow | |||
Expires: October 16, 2010 April 14, 2010 | Expires: November 6, 2010 May 5, 2010 | |||
Guidelines for Choosing an RTP Control Protocol (RTCP) Canonical Name | Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names | |||
(CNAME) for Hosts with Private IP Addresses | (CNAMEs) | |||
draft-begen-avt-rtp-cnames-00 | draft-begen-avt-rtp-cnames-01 | |||
Abstract | Abstract | |||
The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a | The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a | |||
persistent transport-level identifier for an RTP endpoint. While the | persistent transport-level identifier for an RTP endpoint. While the | |||
Synchronisation Source (SSRC) identifier of an RTP endpoint may | Synchronization Source (SSRC) identifier of an RTP endpoint may | |||
change if a collision is detected, or when the RTP application is | change if a collision is detected, or when the RTP application is | |||
restarted, the CNAME is meant to stay unchanged, so that RTP | restarted, the CNAME is meant to stay unchanged, so that RTP | |||
endpoints can be uniquely identified and associated with their RTP | endpoints can be uniquely identified and associated with their RTP | |||
media streams. For proper functionality, CNAMEs should be unique | media streams. For proper functionality, CNAMEs should be unique | |||
within the participants of an RTP session. The recommendations for | within the participants of an RTP session. However, the | |||
choice of the RTCP CNAME provided in RFC 3550 are insufficient to | recommendations for choice of the RTCP CNAME provided in RFC 3550 are | |||
achieve uniqueness in some environments, particularly private IP | insufficient to achieve this uniqueness. This memo updates the | |||
networks. This memo updates the guidelines in RFC 3550 to allow | guidelines in RFC 3550 to allow endpoints to choose unique CNAMEs. | |||
endpoints to choose unique CNAMEs in these environments. | ||||
Status of this Memo | Status of this Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on October 16, 2010. | This Internet-Draft will expire on November 6, 2010. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2010 IETF Trust and the persons identified as the | Copyright (c) 2010 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 2, line 22 ¶ | skipping to change at page 2, line 20 ¶ | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . . 3 | 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . . 3 | |||
3. Choice of RTCP CNAME in Private Networks . . . . . . . . . . . 3 | 3. Choice of RTCP CNAME in Private Networks . . . . . . . . . . . 3 | |||
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 | 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 | |||
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 | |||
6. Normative References . . . . . . . . . . . . . . . . . . . . . 4 | 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 4 | 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
7.1. Normative References . . . . . . . . . . . . . . . . . . . 5 | ||||
7.2. Informative References . . . . . . . . . . . . . . . . . . 5 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 | ||||
1. Introduction | 1. Introduction | |||
In Section 6.5.1 of [RFC3550], there are a number of recommendations | In Section 6.5.1 of [RFC3550], there are a number of recommendations | |||
for choosing the RTCP CNAME for an RTP endpoint. These recommend | for choosing the RTCP CNAME for an RTP endpoint. These recommend | |||
that the CNAME is of the form "user@host" for multiuser systems, or | that the CNAME is of the form "user@host" for multiuser systems, or | |||
"host" if the username is not available. The "host" part is | "host" if the username is not available. The "host" part is | |||
specified to be the fully qualified domain name of the host from | specified to be the fully qualified domain name of the host from | |||
which the real-time data originates, or the numeric representation of | which the real-time data originates, or the numeric representation of | |||
the IP address of the interface from which the RTP data originates | the IP address of the interface from which the RTP data originates | |||
for hosts that do not have a domain name. | for hosts that do not have a domain name. | |||
As noted in [RFC3550], the use of private network address space | 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 | [RFC1918] can result in hosts having network addresses that are not | |||
are not globally unique, and can lead to non-unique CNAMEs if hosts | globally unique. However, this problem is not solely with private | |||
with private addresses and no direct IP connectivity to the public | network addresses, but may also occur with public IP addresses, where | |||
Internet have their RTP packets forwarded to the public Internet | multiple hosts are assigned the same public IP address and connected | |||
through an RTP-level translator. [RFC3550] suggests that such | to a Network Address Translation (NAT) device | |||
applications provide a configuration option to allow the user to | [I-D.miles-behave-l2nat]. When multiple hosts share the same IP | |||
address, using the IP address as the CNAME can lead to non-unique | ||||
CNAMEs. | ||||
[RFC3550] also notes that 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, | ||||
they may end up having non-unique CNAMEs. [RFC3550] suggests that | ||||
such applications provide a configuration option to allow the user to | ||||
choose a unique CNAME, and puts the burden on the translator to | choose a unique CNAME, and puts the burden on the translator to | |||
translate CNAMEs from private addresses to public addresses if | translate CNAMEs from private addresses to public addresses if | |||
necessary to keep private addresses from being exposed. Experience | necessary to keep private addresses from being exposed. Experience | |||
has shown that this does not work in practice, therefore this memo | has shown that this does not work well in practice. | |||
proposes an alternate algorithm for CNAME choice in private networks. | ||||
For all these reasons, this memo proposes alternative algorithms for | ||||
choosing CNAMEs. | ||||
2. Requirements Notation | 2. Requirements Notation | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in [RFC2119]. | document are to be interpreted as described in [RFC2119]. | |||
3. Choice of RTCP CNAME in Private Networks | 3. Choice of RTCP CNAME in Private Networks | |||
In private IP networks, using the numeric representation of the | It is a difficult task for a host to determine whether it resides | |||
private IP address as the RTCP CNAME is NOT RECOMMENDED, since it | behind a NAT without the help of an external mechanism such as STUN | |||
results in RTCP CNAMEs that are not globally unique. | [RFC5389]. Furthermore, even some public IP addresses can be shared | |||
by multiple hosts in the Internet. Thus, using the numeric | ||||
representation of the IP address as the RTCP CNAME is NOT | ||||
RECOMMENDED. | ||||
A host that does not know its fully qualified domain name, and is | In order to meet the SHOULD requirement of Section 6.5.1 of | |||
configured with a private IP address on the interface it is using for | [RFC3550], RTP endpoints SHOULD practice one of the following | |||
RTP communication, SHOULD use the numeric representation of the | guidelines: | |||
layer-2 (MAC) address of the interface it is using for RTP | ||||
communication as the "host" part of its CNAME. For IEEE 802 MAC | o Given that IPv6 addresses are naturally unique, a host MAY use its | |||
addresses, such as Ethernet, the standard colon-separated hexadecimal | IPv6 address as the CNAME when using an IPv6 interface for RTP | |||
format is to be used, e.g., "00:23:32:af:9b:aa". | communication. If the RTP endpoint is associated with a unique | |||
local IPv6 unicast address [RFC4193], that address MAY be used as | ||||
the CNAME as well. Using IPv6 addresses as CNAMEs was originally | ||||
suggested in [RFC3550]. | ||||
o 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, MAY 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. For IEEE 802 MAC | ||||
addresses, such as Ethernet, the standard colon-separated | ||||
hexadecimal format is to be used, e.g., "00:23:32:af:9b:aa". | ||||
o A host MAY use its Universally Unique IDentifier (UUID) [RFC4122] | ||||
as the CNAME. | ||||
This memo does not mandate a specific order in which these methods | ||||
should be practiced. A specific order would be only needed if an RTP | ||||
endpoint was expected to be comprised of multiple programs that | ||||
independently needed to choose the same CNAME. Since this is not a | ||||
common implementation technique, a specific order is not needed. | ||||
4. Security Considerations | 4. Security Considerations | |||
The security considerations of [RFC3550] apply to this document as | The security considerations of [RFC3550] apply to this document as | |||
well. | well. | |||
5. IANA Considerations | 5. IANA Considerations | |||
There are no IANA considerations in this document. | There are no IANA considerations in this document. | |||
6. Normative References | 6. Acknowledgments | |||
Thanks to Dan Wing who pointed out the concerns about cases where two | ||||
hosts could share the same public IP address. Also, thanks to Marc | ||||
Petit-Huguenin who suggested to use UUIDs as CNAMEs. | ||||
7. References | ||||
7.1. Normative References | ||||
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. | [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. | |||
Jacobson, "RTP: A Transport Protocol for Real-Time | Jacobson, "RTP: A Transport Protocol for Real-Time | |||
Applications", STD 64, RFC 3550, July 2003. | Applications", STD 64, RFC 3550, July 2003. | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast | ||||
Addresses", RFC 4193, October 2005. | ||||
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally | ||||
Unique IDentifier (UUID) URN Namespace", RFC 4122, | ||||
July 2005. | ||||
7.2. Informative References | ||||
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and | ||||
E. Lear, "Address Allocation for Private Internets", | ||||
BCP 5, RFC 1918, February 1996. | ||||
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, | ||||
"Session Traversal Utilities for NAT (STUN)", RFC 5389, | ||||
October 2008. | ||||
[I-D.miles-behave-l2nat] | ||||
Miles, D. and M. Townsley, "Layer2-Aware NAT", | ||||
draft-miles-behave-l2nat-00 (work in progress), | ||||
March 2009. | ||||
Authors' Addresses | Authors' Addresses | |||
Ali Begen | Ali Begen | |||
Cisco | Cisco | |||
170 West Tasman Drive | 181 Bay Street | |||
San Jose, CA 95134 | Toronto, ON M5J 2T3 | |||
USA | CANADA | |||
Email: abegen@cisco.com | Email: abegen@cisco.com | |||
Colin Perkins | Colin Perkins | |||
University of Glasgow | University of Glasgow | |||
Department of Computing Science | Department of Computing Science | |||
Glasgow, G12 8QQ | Glasgow, G12 8QQ | |||
UK | UK | |||
Email: csp@csperkins.org | Email: csp@csperkins.org | |||
End of changes. 14 change blocks. | ||||
36 lines changed or deleted | 100 lines changed or added | |||
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |