|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Last Update: May 8, 2008
-- Color Legend: RFC Editor Queue
/ Processed by IESG
/ ID Exists
/ Recently Expired
-- Each I-D name is a link to an I-D description, which points to a text version, a two-page and fit-in-window PDF version, as well as the IETF Tools' HTML version.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| The charter of the BEHAVE working group -- updated on March 8, 2006 --
is reported below.
|
|
|
|
Given the current near-universal deployment of NATs (Network Address
Translators) 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.
The Behavior Engineering for Hindrance Avoidance (BEHAVE) 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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC4787
01/2007
(29 p.)
[html]
[pdf(2)] |
F. Audet
C. Jennings |
|
Network Address Translation (NAT) Behavioral Requirements for Unicast UDP |
|
This document defines basic terminology for describing different
types of Network Address Translation (NAT) behavior when handling
Unicast UDP and also defines a set of requirements that would allow
many applications, such as multimedia communications or online
gaming, to work consistently. Developing NATs that meet this set of
requirements will greatly increase the likelihood that these
applications will function properly.
|
|
|
| |
| Up List |
Status: | Best Current Practice |
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Status: | Best Current Practice |
|
|
|
|
|
|
|
|
|
| | |
RFC5128
03/2008
(32 p.)
[html]
[pdf(2)] |
P. Srisuresh
B. Ford
D. Kegel |
|
State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs) |
|
This memo documents the various methods known to be in use by
applications to establish direct communication in the presence of
Network Address Translators (NATs) at the current time. Although
this memo is intended to be mainly descriptive, the Security
Considerations section makes some purely advisory recommendations
about how to deal with security vulnerabilities the applications
could inadvertently create when using the methods described. This
memo covers NAT traversal approaches used by both TCP- and UDP-based
applications. This memo is not an endorsement of the methods
described, but merely an attempt to capture them in a document.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Status: | Best Current Practice |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | |
behave-tcp-07
RFC Ed Queue (05/07)
Apr 28, 2007
(21 p.)
[pdf(2)]
[html]
|
S. Guha
K. Biswas
B. Ford
P. Francis
S. Sivakumar
P. Srisuresh |
| 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.
|
|
|
| |
| Up List |
Intended Status: | Best Current Practice |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | |
behave-nat-icmp-07
IESG Evaluation::
AD Follow up
Feb 7, 2008
(24 p.)
[pdf(2)]
[html]
|
P. Srisuresh
B. Ford
S. Sivakumar
S. Guha |
|
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.
|
|
|
| |
| Up List |
Intended Status: | Best Current Practice |
|
|
|
|
|
|
|
|
| | |
behave-
rfc3489bis-15
IESG Evaluation::
AD Followup
Feb 23, 2008
(51 p.)
[pdf(2)]
[html]
|
J. Rosenberg
R. Mahy
P. Matthews
D. Wing |
|
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.
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
behave-turn-07
AD is watching
Feb 25, 2008
(49 p.)
[pdf(2)]
[html]
|
J. Rosenberg
R. Mahy
P. Matthews |
|
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.
|
|
|
| |
| Up List |
Intended Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | |
behave-nat-dccp-00
ID Exists
May 4, 2008
(10 p.)
[pdf(2)]
[html]
|
R. Denis-
Courmont |
|
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.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Experimental |
|
|
|
|
|
|
|
|
| | |
behave-stun-
test-vectors-01
ID Exists
Mar 10, 2008
(9 p.)
[pdf(2)]
[html]
|
R. Denis
-Courmont |
|
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.
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
behave-turn-tcp-00
ID Exists
Nov 11, 2007
(9 p.)
[pdf(2)]
[html]
|
J. Rosenberg
R. Mahy |
|
Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations |
|
This specification defines an extension of Traversal Using Relays
around NAT (TURN), a relay protocol for NAT traversal, to allows a
TURN client to request TCP allocations, and defines new requests and
indications for the TURN server to open and accept and manage TCP
connection with the client's peers. TURN and this extension both
purposefully restricts the ways in which the relayed address can be
used. In particular, it prevents users from running general purpose
servers from ports obtained from the STUN server.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | |
jennings-behave-
test-results-04
ID Exists
(Recently Expired)
Jul 7, 2007
(14 p.)
[pdf(2)]
[html]
|
C. Jennings |
|
NAT Classification Test Results |
IETF has several working groups that are considering the impact of
NATs on various protocols. Having a classification of the types of
NATs that are being developed and deployed is useful in gauging the
impact of various solutions. This draft records the results of
classifying NATs.
This draft is not complete and has only a few test results but it is
worth discussing all the testing we wish to do before all the test
results are collected. The test results here are very old and work
is being done to update them with more current information.
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
| | |
kaplan-behave-
twist-00
ID Exists
Mar 26, 2008
(18 p.)
[html]
|
H. Kaplan |
|
Traversal With Internet Server Transports (TWIST): 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 on the Internet that acts as a communication relay.
Likewise, if a host of one IP address family wants to communicate with the host of
another address family, through one or more NATs, an intermediate node may be
necessary. This specification defines a protocol, called TWIST (Traversal With
Internet Server Transports), that allows the host to control the operation of a
TWIST relay and to exchange packets with its peers using the relay, or directly
between each other.
This is similar to TURN, but defines an alternative mechanism which is more
scalable, cheaper to deploy, and is thus more likely to succeed in achieving wide-
spread use. TWIST is not meant to replace TURN, but rather to provide an
alternative. This document is a straw-man proposal, to stimulate discussion, not
a fully defined draft.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
stewart-behave-
sctpnat-03
ID Exists
Nov 17, 2007
(11 p.)
[pdf(2)]
[html]
|
R. Stewart
M. Tuexen |
|
Stream Control Transmission Protocol (SCTP) Network Address Translation |
Stream Control Transmission Protocol [RFC4960] provides a reliable
communications channel between two end-hosts in many ways similar to
TCP [RFC0793]. With the widespread deployment of Network Address
Translators (NAT), specialized code has been added to NAT for TCP
that allows multiple hosts to reside behind a NAT and yet use only a
single globally unique IPv4 address, even when two hosts (behind the
NAT) choose the same port numbers for their connection. This
additional code is sometimes classified as Network Address and Port
Translation or NAPT. To date, specialized code for SCTP has NOT yet
been added to most NAT's so that only pure NAT is available. The end
result of this is that only one SCTP capable host can be behind a
NAT.
This document describes an SCTP specific variant of NAT which
provides similar features of NAPT in the single point traversal
scenario described in [I-D.xie-behave-sctp-nat-cons]. Furthermore
both algorithms are compared.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
| | |
wing-behave-
nat-control-
stun-usage-05
ID Exists
(Recently Expired)
Oct 16, 2007
(31 p.)
[pdf(2)]
[html]
|
D. Wing
J. Rosenberg
H. Tschofenig |
|
Discovering, Querying, and Controlling Firewalls and NATs using STUN |
A drawback with many NAT UDP hole punching techniques is the
keepalive traffic necessary to keep the UDP binding open. It it
necessary to send keepalives frequently because it is not possible to
determine or modify the NAT's binding lifetime. This keepalive
traffic causes server load and additional network traffic, which is
especially problematic with battery-operated wireless devices.
This document describes two mechanisms to discover NATs and firewalls
and a mechanism to query and control their binding lifetime. With
these mechanisms, UDP binding discovery and UDP keepalive traffic can
be reduced to involve only the necessary NATs or firewalls. This
eliminates the keepalive traffic to servers, and vastly reduces
keepalive traffic across the network. At the same time, backwards
compatibility with NATs and firewalls that do not support this
specification is retained, which allows for incremental deployment of
this mechanism.
|
|
|
| |
| Up List |
Intended Status: | Standards Track |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
