Behavior Engineering for Hindrance Avoidance (behave) Internet Drafts
| Session Traversal Utilities for (NAT) (STUN) | |||||||||||||||||
|
Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with NAT traversal. It can be used by an endpoint to determine the IP address and port allocated to it by a NAT. It can also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them. STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This is an important change from the previous version of this specification (RFC 3489), which presented STUN as a complete solution. This document obsoletes RFC 3489. | ||||||||||||||||
| NAT Behavioral Requirements for TCP | |||||||||||||||||
|
This document defines a set of requirements for NATs that handle TCP that would allow many applications, such as peer-to-peer applications and on-line games, to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly. | ||||||||||||||||
| Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) | |||||||||||||||||
|
If a host is located behind a NAT, then in certain situations it can be impossible for that host to communicate directly with other hosts (peers) located behind other NATs. In these situations, it is necessary for the host to use the services of an intermediate node that acts as a communication relay. This specification defines a protocol, called TURN (Traversal Using Relays around NAT), that allows the host to control the operation of the relay and to exchange packets with its peers using the relay. The TURN protocol can be used in isolation, but is more properly used as part of the ICE (Interactive Connectivity Establishment) approach to NAT traversal. | ||||||||||||||||
| Traversal Using Relays around NAT (TURN) Extension for IPv4/IPv6 Transition | |||||||||||||||||
|
This document defines the REQUESTED-ADDRESS-TYPE attribute for the Traversal Using Relays around NAT (TURN), which allows a client to explicitly request the address type the TURN server will allocate (e.g., an IPv4-only node may request the TURN server to allocate an IPv6 address). Additionally, this document also defines a new error response code with the value 440 (Address Family not Supported). | ||||||||||||||||
| NAT Behavioral Requirements for ICMP protocol | |||||||||||||||||
|
This document specifies the behavioral properties required of the Network Address Translator (NAT) devices in conjunction with the Internet Control Message Protocol (ICMP). The objective of this memo is to make NAT devices more predictable and compatible with diverse application protocols that traverse the devices. Companion documents provide behavioral recommendations specific to TCP, UDP and other protocols. | ||||||||||||||||
| NAT Behavior Discovery Using STUN | |||||||||||||||||
|
This specification defines an experimental usage of the Simple Traversal Underneath Network Address Translators (NAT) (STUN) Protocol that discovers the presence and current behaviour of NATs and firewalls between the STUN client and the STUN server. | ||||||||||||||||
| Test vectors for STUN | |||||||||||||||||
|
The Session Traversal Utilities for NAT (STUN) protocol defines two STUN attributes -- FINGERPRINT and MESSAGE-INTEGRITY -- that may be included in STUN messages. This document provides test vectors for those two attributes. | ||||||||||||||||
| Network Address Translation (NAT) Behavioral Requirements for DCCP | |||||||||||||||||
|
This document defines a set of requirements for DCCP-capable NATs that would allow certain applications, such as streaming applications to operate consistently. These requirements are very similar to the TCP requirements for NATs already published by this IETF working group. Developing NATs that meet this set of requirements will greatly increase the likelihood that applications using DCCP will function properly. | ||||||||||||||||
 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
Behavior Engineering for Hindrance Avoidance (behave)
Last Modified: 2008-04-23
Additional information is available at tools.ietf.org/wg/behave
Chair(s):
Transport Area Director(s):
Transport Area Advisor:
Mailing Lists:
General Discussion: behave@ietf.orgTo Subscribe: behave-request@ietf.org
In Body: In Body: subscribe
Archive: http://www1.ietf.org/mail-archive/web/behave/current/index.html
Description of Working Group:
Given the current near-universal deployment of NATs (Network AddressTranslators) in the public Internet, the lack of standards for NAT
behavior has given rise to a crisis. While it is widely acknowledged
that NATs create problems for numerous Internet applications, our
inability to describe precisely what a NAT is or how it behaves leaves
us few solutions for compensating for the presence of NATs.
The behavior of NATs varies dramatically from one implementation to
another. As a result it is very difficult for applications to predict
or discover the behavior of these devices. Predicting and/or
discovering the behavior of NATs is important for designing
application protocols and NAT traversal techniques that work reliably
in existing networks. This situation is especially problematic for end-
to-end interactive applications such as multiuser games and
interactive multimedia.
NATs continue to proliferate and have seen an increasing rate of
deployment. IPv6 deployments can eliminate this problem, but there is
a significant interim period in which applications will need to work
both in IPv4 NAT environments and with the IPv6 to IPv4 transition
mechanisms.
This working group proposes to generate requirements documents and best
current practices to enable NATs to function in as deterministic a
fashion as possible. It will consider what is broken by these devices
and document approaches for characterizing and testing them. The NAT
behavior practices will be application independent.
The group will also advise on how to develop applications that
discover and reliably function in environments with NATs that follow
the best current practices identified by this working group. This will
include the development of protocol-independent toolkits usable by
application protocols for NAT traversal. This will include a revision
of RFC 3489 for NAT binding discovery and a relay protocol that
focuses on security.
The work will be done with the goal of encouraging eventual migration
to IPv6 and compliance with the UNSAF [RFC 3424] considerations. It
will not encourage the proliferation of NATs.
The behavior that will be considered includes IP fragmentation and
parameters that impact ICMP, UDP, TCP, IGMP, MLD, and multicast. The
proposed WG will coordinate with v6ops, midcom and nsis. The work is
largely limited to examining various approaches that are already in
use today and providing suggestions about which ones are likely to
work best in the internet architecture.
Goals and Milestones:
| Done | Submit BCP that defines unicast UDP behavioral requirements for NATs to IESG | |
| Done | Submit a BCP that defines TCP behavioral requireents for NATs to IESG | |
| Done | Submit a BCP that defines ICMP behavioral requirements for NATs to IESG | |
| Done | Submit informational that discusses current NAT traversal techniques used by applications | |
| Done | Submit BCP that defines multicast UDP | |
| Done | Submit revision of RFC 3489 to IESG behavioral requirements for NATs to IESG | |
| Jan 2008 | Submit informational document for rfc3489bis test vectors | |
| Jan 2008 | Submit experimental document that describes how an application can determine the type of NAT it is behind | |
| Mar 2008 | Submit standards-track relay protocol | |
| Mar 2008 | Submit IPv6 relay protocol to IESG | |
| Mar 2008 | Submit standards-track document for media relaying of TCP | |
| Jul 2008 | Submit BCP document for DCCP NAT behavior | |
| Dec 2008 | Submit BCP document for SCTP NAT behavior | |
| Dec 2008 | Close working group or recharter |
Internet-Drafts:
Session Traversal Utilities for (NAT) (STUN) (128739 bytes)NAT Behavioral Requirements for TCP (50576 bytes)
Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) (120314 bytes)
Traversal Using Relays around NAT (TURN) Extension for IPv4/IPv6 Transition (15358 bytes)
NAT Behavioral Requirements for ICMP protocol (65018 bytes)
NAT Behavior Discovery Using STUN (68596 bytes)
Test vectors for STUN (16144 bytes)
Network Address Translation (NAT) Behavioral Requirements for DCCP (19262 bytes)
Request For Comments:
Network Address Translation (NAT) Behavioral Requirements for Unicast UDP (RFC 4787) (68693 bytes)IP Multicast Requirements for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT) (RFC 5135) (36528 bytes)
State of Peer-to-Peer(P2P) Communication Across Network Address Translators(NATs) (RFC 5128) (81008 bytes)
IETF Secretariat - Please send questions, comments, and/or suggestions to ietf-web@ietf.org.
Return to working group directory. 
