rfc3489
rfc3304
draft-ietf-sip-nat
draft-ietf-sip-symmetric-response
draft-ietf-mmusic-sdp4nat
draft-ietf-sipping-nat-scenarios
draft-rosenberg-sip-entfw
draft-sen-midcom-fw-nat
draft-shore-friendly-midcom
draft-ietf-mmusic-natreq4udp
draft-tschofenig-nsis-casp-midcom
draft-ietf-mmusic-sdp-comedia
draft-rosenberg-midcom-turn
draft-jennings-midcom-stun-results
draft-ietf-mmusic-ice
rfc3489.txt  | STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) |
| Author(s) | J. Rosenberg, J. Weinberger, C. Huitema, R. Mahy |
| Organization | ietf |
| State | proposed standard |
| Size | 117562 bytes |
| Abstract | Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs) (STUN) is a lightweight protocol that allows applications to discover the presence and types of NATs and firewalls between them and the public Internet. It also provides the ability for applications to determine the public Internet Protocol (IP) addresses allocated to them by the NAT. STUN works with many existing NATs, and does not require any special behavior from them. As a result, it allows a wide variety of applications to work through existing NAT infrastructure. |
| rfc3304.txt | Middlebox Communications (midcom) Protocol Requirements |
| Author(s) | R. P. Swale, P. A. Mart, P. Sijben, S. Brim, M. Shore |
| Organization | ietf |
| State | informational |
| Size | 16187 bytes |
| Abstract | This document specifies the requirements that the Middlebox Communication (midcom) protocol must satisfy in order to meet the needs of applications wishing to influence the middlebox function. These requirements were developed with a specific focus on network address translation and firewall middleboxes. |
| draft-ietf-sip-nat-03.txt
|
| draft-ietf-sip-symmetric-response-00.txt | An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing |
| Author(s) | Jonathan Rosenberg, Henning Schulzrinne, Joel Weinberger |
| Organization | ietf |
| Working group | sip |
| State | unknown |
| Date | 2002-09-30 |
| Size | 26640 bytes |
| Abstract | The Session Initiation Protocol (SIP) operates over UDP and TCP. When used with UDP, responses to requests are returned to the source address the request came from, and to the port written into the topmost Via header field value of the request. This behavior is not desirable in many cases, most notably, when the client is behind a Network Address Translator (NAT). This extension defines a new parameter for the Via header field, called "rport", that allows a client to request that the server send the response back to the source IP address and port where the request came from. Table of Contents 1 Introduction ........................................ 3 2 Terminology ......................................... 3 3 Client Behavior ..................................... 3 4 Server Behavior ..................................... 4 5 Syntax .............................................. 5 6 Example ............................................. 5 7 Security Considerations ............................. 6 8 IANA Considerations ................................. 7 9 IAB Considerations .................................. 7 9.1 Problem Definition .................................. 8 9.2 Exit Strategy ....................................... 8 9.3 Brittleness Introduced by this Specification ........ 8 9.4 Requirements for a Long Term Solution ............... 9 9.5 Issues with Existing NAPT Boxes ..................... 10 10 Acknowledgements .................................... 10 11 Author's Addresses .................................. 11 12 Normative References ................................ 11 13 Informative References .............................. 12 |
| draft-ietf-mmusic-sdp4nat-05.txt
|
"RTCP attribute in SDP", Christian Huitema, 02-Jun-03,
The session description protocol (SDP) is used to describe the parameters of media streams used in multimedia sessions. When a session requires multiple ports, SDP assumes that these port have consecutive numbers. However, when the session crosses a network address translation device that also uses port mapping, the ordering of ports can be destroyed by the translation. To handle this, we propose an extension attribute to SDP. |
| draft-ietf-sipping-nat-scenarios-01.txt
|
| draft-rosenberg-sip-entfw-03.txt
|
| draft-sen-midcom-fw-nat-02.txt
|
| draft-shore-friendly-midcom-02.txt
|
| draft-ietf-mmusic-natreq4udp-01.txt
|
| draft-tschofenig-nsis-casp-midcom-01.txt
|
"A Firewall/NAT Traversal Client for CASP", Henning Schulzrinne, Cedric
Aoun, Hannes Tschofenig, 07-MAR-03,
This document describes a CASP client protocol that allows nodes to signal information to firewalls both in an in-path and off-path fashion. The protocol furthermore allows to establish a NAT binding and to provide the signaling initiator with the NAT information. This is information can then be used within other protocols such as SIP. |
| draft-ietf-mmusic-sdp-comedia-05.txt
|
"Connection-Oriented Media Transport in SDP", David Yon, 07-Mar-03,
This document describes how to express media transport over connection-oriented protocols using the Session Description Protocol (SDP). It defines two new protocol identifiers: TCP and TLS. It also defines the syntax and semantics for an SDP 'direction' attribute that describes the connection setup procedure. |
| draft-rosenberg-midcom-turn-01.txt
|
"Traversal Using Relay NAT (TURN)", Jonathan Rosenberg, 10-Mar-03,
Traversal Using Relay NAT (TURN) is a protocol that allows for an element behind a NAT or firewall to receive incoming data over TCP or UDP connections. It is most useful for elements behind symmetric NATs or firewalls that wish to be on the receiving end of a connection to a single peer. TURN does not allow for users to run servers on well known ports if they are behind a nat; it supports the connection of a user behind a nat to only a single peer. In that regard, its role is to provide the same security functions provided by symmetric NATs firewalls, but to ``turn'' the tables so that the element on the inside can be on the receiving end, rather than the sending end, of a connection that is requested by the client. |