draft-ietf-mmusic-rtsp-nat-evaluation-01.txt   draft-ietf-mmusic-rtsp-nat-evaluation-02.txt 
Network Working Group M. Westerlund Network Working Group M. Westerlund
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Informational T. Zeng Intended status: Informational T. Zeng
Expires: January 12, 2009 July 11, 2008 Expires: July 24, 2010 January 20, 2010
The evaluation of different NAT traversal Techniques for media The evaluation of different NAT traversal Techniques for media
controlled by Real-time Streaming Protocol (RTSP) controlled by Real-time Streaming Protocol (RTSP)
draft-ietf-mmusic-rtsp-nat-evaluation-01 draft-ietf-mmusic-rtsp-nat-evaluation-02
Abstract
This document describes several NAT traversal techniques that could
be used by RTSP. Each technique includes a description on how it
would be used, the security implications of using it and any other
deployment considerations it has. There are also disussions on how
NAT traversal techniques relates to firewalls and how each technique
can be applied in different use cases. These findings where used
when selecting the NAT traversal for RTSP solution to standardize in
the MMUSIC WG.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 12, 2009. This Internet-Draft will expire on July 24, 2010.
Abstract Copyright Notice
This document describes several NAT traversal techniques that could Copyright (c) 2010 IETF Trust and the persons identified as the
be used by RTSP. Each technique includes a description on how it document authors. All rights reserved.
would be used, the security implications of using it and any other
deployment considerations it has. There are also disussions on how
NAT traversal techniques relates to firewalls and how each technique
can be applied in different use cases. These findings where used
when selecting the NAT traversal for RTSP solution to standardize in
the MMUSIC WG.
Requirements Language This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", This document may contain material from IETF Documents or IETF
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this Contributions published or made publicly available before November
document are to be interpreted as described in RFC 2119 [RFC2119]. 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Network Address Translators . . . . . . . . . . . . . . . 5 1.1. Network Address Translators . . . . . . . . . . . . . . . 5
1.2. Firewalls . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Firewalls . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Detecting the loss of NAT mappings . . . . . . . . . . . . . . 7 2. Detecting the loss of NAT mappings . . . . . . . . . . . . . . 7
3. Requirements on NAT-Traversal . . . . . . . . . . . . . . . . 8 3. Requirements on NAT-Traversal . . . . . . . . . . . . . . . . 7
4. NAT Traversal Techniques . . . . . . . . . . . . . . . . . . . 9 4. NAT Traversal Techniques . . . . . . . . . . . . . . . . . . . 9
4.1. STUN . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. STUN . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1. Introduction . . . . . . . . . . . . . . . . . . . . . 10 4.1.1. Introduction . . . . . . . . . . . . . . . . . . . . . 9
4.1.2. Using STUN to traverse NAT without server 4.1.2. Using STUN to traverse NAT without server
modifications . . . . . . . . . . . . . . . . . . . . 10 modifications . . . . . . . . . . . . . . . . . . . . 10
4.1.3. Embedding STUN in RTSP . . . . . . . . . . . . . . . . 12 4.1.3. Embedding STUN in RTSP . . . . . . . . . . . . . . . . 12
4.1.4. Discussion On Co-located STUN Server . . . . . . . . . 13 4.1.4. Discussion On Co-located STUN Server . . . . . . . . . 13
4.1.5. ALG considerations . . . . . . . . . . . . . . . . . . 14 4.1.5. ALG considerations . . . . . . . . . . . . . . . . . . 13
4.1.6. Deployment Considerations . . . . . . . . . . . . . . 14 4.1.6. Deployment Considerations . . . . . . . . . . . . . . 14
4.1.7. Security Considerations . . . . . . . . . . . . . . . 16 4.1.7. Security Considerations . . . . . . . . . . . . . . . 16
4.2. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.2. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2.1. Introduction . . . . . . . . . . . . . . . . . . . . . 17 4.2.1. Introduction . . . . . . . . . . . . . . . . . . . . . 17
4.2.2. Using ICE in RTSP . . . . . . . . . . . . . . . . . . 17 4.2.2. Using ICE in RTSP . . . . . . . . . . . . . . . . . . 17
4.2.3. Implementation burden of ICE . . . . . . . . . . . . . 19 4.2.3. Implementation burden of ICE . . . . . . . . . . . . . 19
4.2.4. Deployment Considerations . . . . . . . . . . . . . . 20 4.2.4. Deployment Considerations . . . . . . . . . . . . . . 19
4.2.5. Security Consideration . . . . . . . . . . . . . . . . 20 4.2.5. Security Consideration . . . . . . . . . . . . . . . . 20
4.3. Symmetric RTP . . . . . . . . . . . . . . . . . . . . . . 20 4.3. Symmetric RTP . . . . . . . . . . . . . . . . . . . . . . 20
4.3.1. Introduction . . . . . . . . . . . . . . . . . . . . . 20 4.3.1. Introduction . . . . . . . . . . . . . . . . . . . . . 20
4.3.2. Necessary RTSP extensions . . . . . . . . . . . . . . 21 4.3.2. Necessary RTSP extensions . . . . . . . . . . . . . . 21
4.3.3. Deployment Considerations . . . . . . . . . . . . . . 21 4.3.3. Deployment Considerations . . . . . . . . . . . . . . 21
4.3.4. Security Consideration . . . . . . . . . . . . . . . . 22 4.3.4. Security Consideration . . . . . . . . . . . . . . . . 22
4.3.5. A Variation to Symmetric RTP . . . . . . . . . . . . . 23 4.3.5. A Variation to Symmetric RTP . . . . . . . . . . . . . 23
4.4. Application Level Gateways . . . . . . . . . . . . . . . . 25 4.4. Application Level Gateways . . . . . . . . . . . . . . . . 25
4.4.1. Introduction . . . . . . . . . . . . . . . . . . . . . 25 4.4.1. Introduction . . . . . . . . . . . . . . . . . . . . . 25
4.4.2. Outline On how ALGs for RTSP work . . . . . . . . . . 25 4.4.2. Outline On how ALGs for RTSP work . . . . . . . . . . 25
4.4.3. Deployment Considerations . . . . . . . . . . . . . . 26 4.4.3. Deployment Considerations . . . . . . . . . . . . . . 26
4.4.4. Security Considerations . . . . . . . . . . . . . . . 27 4.4.4. Security Considerations . . . . . . . . . . . . . . . 27
4.5. TCP Tunneling . . . . . . . . . . . . . . . . . . . . . . 27 4.5. TCP Tunneling . . . . . . . . . . . . . . . . . . . . . . 27
4.5.1. Introduction . . . . . . . . . . . . . . . . . . . . . 27 4.5.1. Introduction . . . . . . . . . . . . . . . . . . . . . 27
4.5.2. Usage of TCP tunneling in RTSP . . . . . . . . . . . . 27 4.5.2. Usage of TCP tunneling in RTSP . . . . . . . . . . . . 27
4.5.3. Deployment Considerations . . . . . . . . . . . . . . 28 4.5.3. Deployment Considerations . . . . . . . . . . . . . . 27
4.5.4. Security Considerations . . . . . . . . . . . . . . . 28 4.5.4. Security Considerations . . . . . . . . . . . . . . . 28
4.6. TURN (Traversal Using Relay NAT) . . . . . . . . . . . . . 28 4.6. TURN (Traversal Using Relay NAT) . . . . . . . . . . . . . 28
4.6.1. Introduction . . . . . . . . . . . . . . . . . . . . . 28 4.6.1. Introduction . . . . . . . . . . . . . . . . . . . . . 28
4.6.2. Usage of TURN with RTSP . . . . . . . . . . . . . . . 29 4.6.2. Usage of TURN with RTSP . . . . . . . . . . . . . . . 29
4.6.3. Deployment Considerations . . . . . . . . . . . . . . 30 4.6.3. Deployment Considerations . . . . . . . . . . . . . . 30
4.6.4. Security Considerations . . . . . . . . . . . . . . . 30 4.6.4. Security Considerations . . . . . . . . . . . . . . . 30
5. Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . 31 5. Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6. Comparision of NAT traversal techniques . . . . . . . . . . . 32 6. Comparision of NAT traversal techniques . . . . . . . . . . . 32
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
8. Security Considerations . . . . . . . . . . . . . . . . . . . 33 8. Security Considerations . . . . . . . . . . . . . . . . . . . 33
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
10. Informative References . . . . . . . . . . . . . . . . . . . . 34 10. Informative References . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
Intellectual Property and Copyright Statements . . . . . . . . . . 37
1. Introduction 1. Introduction
Today there is a proliferate deployment of different flavors of Today there is a proliferate deployment of different flavors of
Network Address Translator (NAT) boxes that in many cases only Network Address Translator (NAT) boxes that in many cases only
loosely follows standards[RFC3022][RFC2663][RFC3424]]. NATs cause loosely follows standards[RFC3022][RFC2663][RFC3424]]. NATs cause
discontinuity in address realms [RFC3424], therefore an application discontinuity in address realms [RFC3424], therefore an application
protocol, such as RTSP, needs to deal with such discontinuities protocol, such as RTSP, needs to deal with such discontinuities
caused by NATs. The problem is that, being a media control protocol caused by NATs. The problem is that, being a media control protocol
managing one or more media streams, RTSP carries network address and managing one or more media streams, RTSP carries network address and
skipping to change at page 6, line 44 skipping to change at page 7, line 44
DDOS: Distributed Denial Of Service attacks DDOS: Distributed Denial Of Service attacks
MID: Media Identifier from Grouping of media lines in SDP, see MID: Media Identifier from Grouping of media lines in SDP, see
[RFC3388]. [RFC3388].
NAT: Network Address Translator, see [RFC3022]. NAT: Network Address Translator, see [RFC3022].
NAPT: Network Address/Port Translator, see [RFC3022]. NAPT: Network Address/Port Translator, see [RFC3022].
NAT-PT: Network Address Translator Protocol Translator, see
[RFC2766].
RTP: Real-time Transport Protocol, see [RFC3550]. RTP: Real-time Transport Protocol, see [RFC3550].
RTSP: Real-Time Streaming Protocol, see [RFC2326] and RTSP: Real-Time Streaming Protocol, see [RFC2326] and
[I-D.ietf-mmusic-rfc2326bis]. [I-D.ietf-mmusic-rfc2326bis].
SDP: Session Description Protocol, see [RFC4566]. SDP: Session Description Protocol, see [RFC4566].
SSRC: Synchronization source in RTP, see [RFC3550]. SSRC: Synchronization source in RTP, see [RFC3550].
2. Detecting the loss of NAT mappings 2. Detecting the loss of NAT mappings
skipping to change at page 9, line 42 skipping to change at page 10, line 39
sections, each technique is outlined in details with discussions on sections, each technique is outlined in details with discussions on
the corresponding advantages and disadvantages. the corresponding advantages and disadvantages.
This section includes NAT traversal techniques that have not been This section includes NAT traversal techniques that have not been
formally specified anywhere else. The overview section of this formally specified anywhere else. The overview section of this
document may be the only publicly available specification of some of document may be the only publicly available specification of some of
the NAT traversal techniques. However that is no real barrier the NAT traversal techniques. However that is no real barrier
against doing an evaluation of the NAT traversal technique. Some against doing an evaluation of the NAT traversal technique. Some
other techniques are currently (at the time of writing) in a state of other techniques are currently (at the time of writing) in a state of
flux due to ongoing standardization work on these techniques, e.g. flux due to ongoing standardization work on these techniques, e.g.
ICE [I-D.ietf-mmusic-ice], STUN [I-D.ietf-behave-rfc3489bis] and RTP ICE [I-D.ietf-mmusic-ice], STUN [RFC5389] and RTP No-Op
No-Op [I-D.ietf-avt-rtp-no-op]. [I-D.ietf-avt-rtp-no-op].
4.1. STUN 4.1. STUN
4.1.1. Introduction 4.1.1. Introduction
STUN - "Simple Traversal of UDP Through Network Address Translators" STUN - "Simple Traversal of UDP Through Network Address Translators"
[RFC3489][I-D.ietf-behave-rfc3489bis] is a standardized protocol that [RFC3489][RFC5389] is a standardized protocol that allows a client to
allows a client to use secure means to discover the presence of a NAT use secure means to discover the presence of a NAT between himself
between himself and the STUN server and the type of that NAT. The and the STUN server and the type of that NAT. The client then uses
client then uses the STUN server to discover the address bindings the STUN server to discover the address bindings assigned by the NAT.
assigned by the NAT. STUN is a client-server protocol. STUN client
sends a request to a STUN server and the server returns a response. STUN is a client-server protocol. STUN client sends a request to a
There are two types of STUN requests - Binding Requests, sent over STUN server and the server returns a response. There are two types
UDP, and Shared Secret Requests, sent over TLS over TCP. of STUN requests - Binding Requests, sent over UDP, and Shared Secret
Requests, sent over TLS over TCP.
STUN is in the process of being updated by the BEHAVE WG to address STUN is in the process of being updated by the BEHAVE WG to address
issues found during usage. The BEHAVE WG intends to integrate it issues found during usage. The BEHAVE WG intends to integrate it
better with TURN [I-D.ietf-behave-turn]. better with TURN [I-D.ietf-behave-turn].
4.1.2. Using STUN to traverse NAT without server modifications 4.1.2. Using STUN to traverse NAT without server modifications
This section describes how a client can use STUN to traverse NATs to This section describes how a client can use STUN to traverse NATs to
RTSP servers without requiring server modifications. Note that this RTSP servers without requiring server modifications. Note that this
method has limited applicability and requires the server to be method has limited applicability and requires the server to be
skipping to change at page 34, line 34 skipping to change at page 35, line 34
like to give special thanks to Greg Sherwood of PacketVideo for his like to give special thanks to Greg Sherwood of PacketVideo for his
input into this memo. input into this memo.
Section Section 1.1 contains text originally written for RFC 4787 by Section Section 1.1 contains text originally written for RFC 4787 by
Francois Audet and Cullen Jennings. Francois Audet and Cullen Jennings.
10. Informative References 10. Informative References
[I-D.ietf-avt-app-rtp-keepalive] [I-D.ietf-avt-app-rtp-keepalive]
Marjou, X. and A. Sollaud, "Application Mechanism for Marjou, X. and A. Sollaud, "Application Mechanism for
maintaining alive the Network Address Translator (NAT) maintaining alive the Network Address Translator (NAT)
mappings associated to RTP flows.", mappings associated to RTP flows.",
draft-ietf-avt-app-rtp-keepalive-03 (work in progress), draft-ietf-avt-app-rtp-keepalive-07 (work in progress),
April 2008. December 2009.
[I-D.ietf-avt-rtp-no-op] [I-D.ietf-avt-rtp-no-op]
Andreasen, F., "A No-Op Payload Format for RTP", Andreasen, F., "A No-Op Payload Format for RTP",
draft-ietf-avt-rtp-no-op-04 (work in progress), May 2007. draft-ietf-avt-rtp-no-op-04 (work in progress), May 2007.
[I-D.ietf-behave-rfc3489bis]
Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for (NAT) (STUN)",
draft-ietf-behave-rfc3489bis-16 (work in progress),
July 2008.
[I-D.ietf-behave-turn] [I-D.ietf-behave-turn]
Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", Traversal Utilities for NAT (STUN)",
draft-ietf-behave-turn-08 (work in progress), June 2008. draft-ietf-behave-turn-16 (work in progress), July 2009.
[I-D.ietf-mmusic-ice] [I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-19 (work in progress), October 2007. draft-ietf-mmusic-ice-19 (work in progress), October 2007.
[I-D.ietf-mmusic-rfc2326bis] [I-D.ietf-mmusic-rfc2326bis]
Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M.,
and M. Stiemerling, "Real Time Streaming Protocol 2.0 and M. Stiemerling, "Real Time Streaming Protocol 2.0
(RTSP)", draft-ietf-mmusic-rfc2326bis-18 (work in (RTSP)", draft-ietf-mmusic-rfc2326bis-22 (work in
progress), May 2008. progress), July 2009.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[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.
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998. Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2588] Finlayson, R., "IP Multicast and Firewalls", RFC 2588, [RFC2588] Finlayson, R., "IP Multicast and Firewalls", RFC 2588,
May 1999. May 1999.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", Translator (NAT) Terminology and Considerations",
RFC 2663, August 1999. RFC 2663, August 1999.
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
Translation - Protocol Translation (NAT-PT)", RFC 2766,
February 2000.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, Address Translator (Traditional NAT)", RFC 3022,
January 2001. January 2001.
[RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. [RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H.
Schulzrinne, "Grouping of Media Lines in the Session Schulzrinne, "Grouping of Media Lines in the Session
Description Protocol (SDP)", RFC 3388, December 2002. Description Protocol (SDP)", RFC 3388, December 2002.
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral
Self-Address Fixing (UNSAF) Across Network Address Self-Address Fixing (UNSAF) Across Network Address
skipping to change at page 36, line 25 skipping to change at page 37, line 16
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP)
and RTP Control Protocol (RTCP) Packets over Connection- and RTP Control Protocol (RTCP) Packets over Connection-
Oriented Transport", RFC 4571, July 2006. Oriented Transport", RFC 4571, July 2006.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127, (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007. RFC 4787, January 2007.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008.
[STUN-IMPL] [STUN-IMPL]
"Open Source STUN Server and Client, http:// "Open Source STUN Server and Client, http://
www.vovida.org/applications/downloads/stun/index.html", www.vovida.org/applications/downloads/stun/index.html",
June 2007. June 2007.
Authors' Addresses Authors' Addresses
Magnus Westerlund Magnus Westerlund
Ericsson Ericsson
Torshamsgatan 23 Farogatan 6
Stockholm, SE-164 80 Stockholm, SE-164 80
Sweden Sweden
Phone: +46 8 719 0000 Phone: +46 8 719 0000
Fax: Fax:
Email: magnus.westerlund@ericsson.com Email: magnus.westerlund@ericsson.com
URI: URI:
Thomas Zeng Thomas Zeng
Phone: Phone:
Fax: Fax:
Email: thomas.zeng@gmail.com Email: thomas.zeng@gmail.com
URI: URI:
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 28 change blocks. 
57 lines changed or deleted 74 lines changed or added

This html diff was produced by rfcdiff 1.37c. The latest version is available from http://tools.ietf.org/tools/rfcdiff/