DCCP Working Group G. Fairhurst
Internet-Draft University of Aberdeen
Updates: 4340 (if approved) Oct 8, 2008
Intended status: Standards Track
Expires: April 11, 2009
DCCP Simultaneous-Open Technique to Facilitate NAT/Middlebox Traversaldraft-ietf-dccp-simul-open-05
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
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
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 11, 2009.
Fairhurst Expires April 11, 2009 [Page 1]

Internet-Draft DCCP Simultaneous-Open Technique Oct 20081. Introduction
The Datagram Congestion Control Protocol (DCCP) [RFC4340] is both
datagram-based and connection-oriented. As such, it faces the same
problems as TCP in sending packets through devices that require all
connections to be initiated by a 'trusted' host. This is true of
host-based firewalls, the default policy on many firewalls, and (due
to port overloading) Network Address Port Translators, NAPTs
[ID-BEHAVE-DCCP]. DCCP can not simply reuse traversal solutions that
work for UDP. In addition, the original specification of DCCP did
not allow a server to perform a simultaneous-open, an inherent
characteristic of TCP that greatly simplifies TCP Network Address
Translator (NAT) traversal.
After discussing the problem space for DCCP, this document specifies
an update to the DCCP state machine to offer native DCCP support for
middlebox traversal. This reduces dependence on external aids such
as data relay servers ) [ID-BEHAVE-TURN] by explicitly supporting a
widely used principle known as 'hole punching'.
The method requires only a minor change to the standard DCCP
operational procedure. The use of a dedicated DCCP packet type ties
usage to a specific condition, ensuring the method is inter-operable
with hosts that do not implement this update, or choose to disable it
(see Section 4).
1.1. Scope of this Document
This method is useful in scenarios when a DCCP server is located
behind a middlebox. It is relevant to both client/server and peer-
to-peer applications, such as VoIP, file sharing, or online gaming
and assists connections that utilise prior out-of-band signaling
(e.g. via a well-known rendezvous server ([RFC3261], [H.323])) to
notify both endpoints of the connection parameters ([RFC3235],
[NAT-APP]).
1.2. DCCP NAT Traversal
The behavioural requirements for NAT devices supporting DCCP are
described in [ID-BEHAVE-DCCP]. A "traditional NAT" [RFC3022], that
directly maps an IP address to a different IP address does not
require the simultaneous open method described in this document.
The method is required when the DCCP server is positioned behind one
or more NAT devices in the path (i.e. hierarchies of nested NAT
devices are possible). This document refers to DCCP hosts located
behind one or more NAT devices as having "private" addresses, and to
DCCP hosts located in the global address realm as having "public"
Fairhurst Expires April 11, 2009 [Page 3]

Internet-Draft DCCP Simultaneous-Open Technique Oct 2008
addresses.
DCCP NAT traversal is considered for the following scenarios:
1. Private client connects to public server.
2. Public server connects to private client.
3. Private client connects to private server.
A defining characteristic of traditional NAT devices [RFC3022] is
that private hosts can connect to external hosts, but not vice versa.
Hence the case (1) is possible using the protocol defined in
[RFC4340]. A pre-configured, static NAT address map would allow
outside hosts to connect to the private network in cases (2) and (3).
This document describes a method to support cases (2) and (3) that
require NAT traversal techniques. A DCCP implementation conforming
to [RFC4340] and a NAT device conforming to [ID-BEHAVE-DCCP] would
require a DCCP relay server to perform NAT traversal for cases (2)
and (3).
The document updates RFC 4340 to enable DCCP NAT traversal without
the aid of DCCP relay servers. This method requires the DCCP server
to discover the IP address and the DCCP port that correspond to the
DCCP client. Such signalling may be performed out-of-band (e.g.
using SDP [RFC4566]).
1.3. Structure of this Document
For background information on existing NAT traversal techniques,
please consult Appendix A.
The normative specification of the update is presented in Section 2.
An informative discussion of underlying design decisions then
follows, in Section 3. Security considerations are provided in
Section 4 and IANA considerations in the concluding Section 5.
Fairhurst Expires April 11, 2009 [Page 4]

Internet-Draft DCCP Simultaneous-Open Technique Oct 20082. Procedure for Near-Simultaneous Open
This section is normative and specifies the simultaneous-open
technique for DCCP. It updates the connection-establishment
procedures of [RFC4340].
2.1. Conventions and Terminology
The document uses the terms and definitions provided in [RFC4340].
Familiarity with this specification is assumed. In particular, the
following convention from ([RFC4340], 3.2) is used:
"Each DCCP connection runs between two hosts, which we often name
DCCP A and DCCP B. Each connection is actively initiated by one of
the hosts, which we call the client; the other, initially passive
host is called the server."
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 [RFC2119].
2.2. Protocol Method
The term "session" is used as defined in ([RFC2663], 2.3): DCCP
sessions are uniquely identified by the tuple of <source IP-address,
source port, target IP-address, target port>.
DCCP, in addition, introduces service codes, which can be used to
identify different services available via the same port [ID-DCCP-SC].
2.2.1. DCCP-Listen Packet Format
This document adds a new DCCP packet type, DCCP-Listen, whose format
is shown below.
Fairhurst Expires April 11, 2009 [Page 5]

Internet-Draft DCCP Simultaneous-Open Technique Oct 2008
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Dest Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Offset | CCVal | CsCov | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Res | Type |X| Reserved | Sequence Number High Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number Low Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Format of a DCCP-Listen Packet
o The Source Port is the port on which the DCCP server is listening
for a connection from the IP address that appears as the
destination IP address in the packet.
o The default value of 0 for the Allow Short Seqno feature MUST be
used, X MUST be set to 1. Since the use of short sequence numbers
([RFC4340], 5.1) depends on the value of the Allow Short Seqno
feature ([RFC4340], 7.6.1) and since DCCP-Listen packets are sent
before a connection is established, there is no way of negotiating
the use of short sequence numbers.
o The sequence number of a DCCP-Listen packet is not related to the
DCCP sequence number for normal DCCP messages Section 3. Thus,
for DCCP-Listen packets:
* DCCP servers should set both Sequence Number fields to 0.
* DCCP clients MUST ignore the value of the Sequence Number
fields.
* Middleboxes MUST NOT interpret sequence numbers on DCCP-Listen
packets.
o The Service Code field contains the service code value for which
the server is listening for a connections([RFC4340], 8.1.2). This
value MUST correspond to a service code that the server is
actually offering for connection identified by the same source IP
address and the same Source Port as that of the DCCP-Listen
packet. Since the server may use multiple service codes, the
specific value of the Service Code field needs to be communicated
out-of-band, from client to server, prior to sending the DCCP-
Listen packet, e.g. described using the Session Description
Fairhurst Expires April 11, 2009 [Page 6]

Internet-Draft DCCP Simultaneous-Open Technique Oct 2008
Protocol, SDP [RFC4566].
o At the time of writing, there are no known uses of the header
option ([RFC4340] , sec. 5.8) with a DCCP-Listen packet. Clients
MUST ignore all options in received DCCP-Listen packets.
Therefore, option values can not be negotiated using a DCCP-Listen
packet.
o There is no payload data. Since DCCP-Listen packets are issued
before an actual connection is established, they MUST NOT carry
payload data. Endpoints MUST ignore any payload data encountered
in DCCP-Listen packets. In addition, DCCP clients MUST ignore the
value of the Sequence Number fields; and middleboxes MUST NOT
interpret the sequence numbers of DCCP-Listen packets.
o The following protocol fields are required to have specific
values:
* Data Offset MUST be zero (there is no payload).
* CCVal MUST be zero (a connection has not been established).
* CsCov MUST be zero (there is no payload).
* Type has the value 10 (assigned by IANA to denote a DCCP-Listen
packet).
* X MUST be 1 (the Generic header must be used).
The remaining fields, including the "Res" and "Reserved" fields are
specified by [RFC4340] and its successors. The interpretation of
these fields is not modified by this document.
Fairhurst Expires April 11, 2009 [Page 7]

Internet-Draft DCCP Simultaneous-Open Technique Oct 2008
Note to the RFC Editor:
This value assigned to the DCCP-Listen packet needs to be confirmed
by IANA when this document is published. Please then remove this
note.
==> End of note to the RFC Editor. <==
2.2.2. Protocol Method for DCCP-Server Endpoints
This document updates [RFC4340] for the case of a fully specified
DCCP server endpoint. The update modifies the way the server
performs a passive-open.
Prior to connection setup, it is common for DCCP server endpoints to
not be fully specified: before the connection is established, a
server usually sets the target IP-address:port to wildcard values
(i.e. leaves these unspecified); the endpoint only becomes fully
specified after performing the handshake with an incoming connection.
For such cases, this document does not update [RFC4340], i.e. the
server adheres to the existing state transitions in the left half of
Figure 2 (CLOSED => LISTEN => RESPOND).
A fully specified DCCP server endpoint permits exactly one client,
identified by target IP-address:port plus a single service code, to
set up the connection. Such a server SHOULD perform the actions and
state transitions shown in the right half of Figure 2, and specified
below.
unspecified remote +--------+ fully specified remote
+---------------------| CLOSED |---------------------+
| +--------+ send DCCP-Listen |
| |
| |
v v
+--------+ timeout +---------+
| LISTEN |<------------------------------+-----------| INVITED |
+--------+ more than 2 retransmissions | +---------+
| | 1st / 2nd ^ |
| | retransm. | |
| +-------------+ |
| resend Listen |
| |
| |
| receive Request +---------+ receive Request |
+------------------->| RESPOND |<--------------------+
send Response +---------+ send Response
Fairhurst Expires April 11, 2009 [Page 8]

Internet-Draft DCCP Simultaneous-Open Technique Oct 2008
Figure 2: Updated state transition diagram for DCCP-Listen
A fully specified server endpoint performs a passive-open from the
CLOSED state by inviting the remote client to connect. This is
performed by sending a single DCCP-Listen packet to the specified
remote IP-address:port, using the format specified in Section 2.2.1.
The server then transitions to the INVITED state.
The INVITED state is, like LISTEN, a passive state, characterised by
waiting in the absence of an established connection. If the server
endpoint in state INVITED receives a DCCP-Request, it transitions to
RESPOND, where further processing resumes as specified in [RFC4340].
The server SHOULD repeat sending a DCCP-Listen packet while in the
INVITED state, at a 200 millisecond interval and up to at most 2
retransmissions (Section 3 discusses this choice of time interval).
If the server is still in the INVITED state after a further period of
200ms following transmission of the third DCCP-Listen packet, it
SHOULD progress to LISTEN, and resume processing as specified in
[RFC4340].
Fully specified server endpoints SHOULD treat ICMP error messages
received in response to a DCCP-Listen packet as "soft errors" that do
not cause a state transition. Reception of an ICMP error message as
a result of sending a DCCP-Listen packet does not necessarily
indicate a failure of the following connection request, and therefore
should not result in a server state change. This reaction to soft
errors exploits the valuable feature of the Internet that for many
network failures, the network can be dynamically reconstructed
without any disruption of the endpoints.
Server endpoints SHOULD ignore any incoming DCCP-Listen packets. A
DCCP Server in state LISTEN MAY generate a DCCP-Reset packet (Code 7,
"Connection Refused") in response to a received DCCP-Listen packet.
This DCCP-Reset packet is an indication that two servers are
simultaneously awaiting connections on the same port.
Further details on the design rationale are discussed in Section 3.
2.2.3. Protocol Method for DCCP-Client Endpoints
This document updates ection 8 of [RFC4340], by adding the following
rule for the reception of DCCP-Listen packets by clients:
A client in any state MUST silently discard any received DCCP-Listen
packet.
Fairhurst Expires April 11, 2009 [Page 9]

Internet-Draft DCCP Simultaneous-Open Technique Oct 20082.2.4. Processing by Routers and Middleboxes
DCCP-Listen packets do not require special treatment and should thus
be forwarded end-to-end across Internet paths, by routers and
middleboxes alike.
Middleboxes may utilise the connection information (address, port,
service code) to establish local forwarding state. The DCCP-Listen
packet carries the necessary information to uniquely identify a DCCP
session in combination with the source and destination addresses
(found in the enclosing IP-header), including the DCCP service code
value [ID-DCCP-SC]. The processing of the DCCP-Listen packet by NAT
devices is specified in [ID-BEHAVE-DCCP].
2.3. Examples of Use
In the examples below, DCCP A is the client and DCCP B is the server.
A middlebox device (NAT/Firewall), NA is placed before DCCP A, and
another middlebox, NB, is placed before DCCP B. Both NA and NB use a
policy that permits DCCP packets to traverse the device for outgoing
links, but only permit incoming DCCP packets when a previous packet
has been sent out for the same connection.
In the figure below, DCCP A and DCCP B decide to communicate using an
out-of-band mechanism, whereupon the client and server are started.
DCCP A initiates a connection by sending a DCCP-Request. DCCP B
actively indicates its listening state by sending a DCCP-Listen
message. This fulfils the requirement of punching a hole in NB, so
that DCCP A can retransmit the DCCP-Request and connect through it.
DCCP A DCCP B
------ NA NB ------
+------------------+ +-+ +-+ +-----------------+
|(1) Initiation | | | | | | |
|DCCP-Request --> +--+-+---X| | | |
| |<-+-+----+-+--+<-- DCCP-Listen |
| | | | | | | |
|DCCP-Request --> +--+-+----+-+->| |
| |<-+-+----+-+--+<-- DCCP-Response|
|DCCP-Ack --> +--+-+----+-+->| |
| | | | | | | |
|(2) Data transfer | | | | | | |
|DCCP-Data --> +--+-+----+-+->| |
+------------------+ +-+ +-+ +-----------------+
Figure 3: Event sequence when the client is started before the server
Fairhurst Expires April 11, 2009 [Page 10]

Internet-Draft DCCP Simultaneous-Open Technique Oct 2008
The figure below shows the reverse sequence of events, where the
server sends the DCCP-Listen before the client sends a DCCP-Request:
DCCP A DCCP B
------ NA NB ------
+------------------+ +-+ +-+ +-----------------+
|(1) Initiation | | | | | | |
| | | |X---+-+--+<-- DCCP-Listen |
|DCCP-Request --> +--+-+----+-+->| |
| | <+-+----+-+--+<-- DCCP-Response|
|DCCP-Ack --> +--+-+----+-+> | |
| | | | | | | |
|(2) Data transfer | | | | | | |
|DCCP-Data --> +--+-+----+-+> | |
+------------------+ +-+ +-+ +-----------------+
Figure 4: Event sequence when the server is started before the client
The figure below shows the sequence of packets where the DCCP server
enters the INVITED state after reception of out-of-band signaling
(e.g. SDP). It considers the case when the server does not receive
a DCCP-Request within the first 600 ms (often the request would be
received within this interval). Retransmission is implemented using
a timer. The timer is restarted with an interval of 200ms when
sending each DCCP-Listen packet. It is cancelled when the server
leaves the INVITED state. If the timer expires after the first and
second transmission, it triggers a retransmission of the DCCP-Listen
Packet. If it expires after sending the third DCCP-Listen packet,
the server leaves the INVITED state, to enter the LISTEN state (where
it passively waits for a DCCP-Request).
Fairhurst Expires April 11, 2009 [Page 11]

Internet-Draft DCCP Simultaneous-Open Technique Oct 20083. Discussion of Design Decisions
This is an informative section that reviews the rationale for the
design of this method.
3.1. Rationale for a New Packet Type
The DCCP-Listen packet specified in Section 2.2.1 has the same format
as the DCCP-Request packet ([RFC4340], 5.1), the only difference is
in the value of the Type field. The usage, however, differs. The
DCCP-Listen packet serves as an advisory message, not as part of the
actual connection setup: sequence numbers have no meaning, and no
payload may be present.
A DCCP-Request packet could in theory also have been used for the
same purpose. The following arguments were against this:
The first problem was that of semantic overloading: the DCCP-Request
defined in [RFC4340] serves a well-defined purpose, being the initial
packet of the 3-way handshake. Additional use in the manner of a
DCCP-Listen packet would have required DCCP processors to have had
two different processing paths: one where a DCCP-Request was
interpreted as part of the initial handshake, and another where the
same packet was interpreted as an indicator message. This would
complicate packet processing in hosts and in particular stateful
middleboxes (which may have restricted computational resources).
The second problem is that a client receiving a DCCP-Request from a
server could generate a DCCP-Reset packet if it had not yet entered
the REQUEST state (step 7 in [RFC4340], 8.5). The method specified
in this document lets client endpoints ignore DCCP-Listen packets.
Adding a similar rule for the DCCP-Request packet would have been
cumbersome: clients would not have been able to distinguish between a
Request meant to be an indicator message and a genuinely erratic
connection initiation.
The third problem is similar, and refers to a client receiving the
indication after having itself sent a (connection-initiation) DCCP-
Request. Step 7 in section 8.5 of [RFC4340] requires the client to
reply to an "indicator message" Request from the server with a DCCP-
Sync. Since sequence numbers are ignored for this type of message,
additional and complex processing would become necessary: either to
ask the client not to respond to a DCCP-Request when the request is
of type "indicator message"; or ask middleboxes and servers to ignore
Sync packets generated in response to "indicator message" DCCP-
Requests. Furthermore, since no initial sequence numbers have been
negotiated at this stage, sending a DCCP-SyncAck would not be
meaningful.
Fairhurst Expires April 11, 2009 [Page 13]

Internet-Draft DCCP Simultaneous-Open Technique Oct 2008
The use of a separate packet type therefore allows simpler and
clearer processing.
3.1.1. Use of sequence numbers
Although the DCCP-Listen sequence number fields are ignored, they
have been retained in the DCCP-Listen packet header to reuse the
generic header format from section 5.1 of [RFC4340].
DCCP assigns a random initial value to the sequence number when a
DCCP connection is established [RFC4340]. However, a sender is
required to set this value to zero for a DCCP-Listen packet. Both
clients and middleboxes are also required to ignore this value.
The rationale for ignoring the sequence number fields of DCCP-Listen
packets is that at the time the DCCP-Listen is exchanged, the
endpoints have not yet entered connection setup: the DCCP-Listen
packet is sent while the server is still in the passive-open
(INVITED) state, i.e. it has not yet allocated state, other than
binding to the client's IP-address:port and service code.
3.2. Generation of Listen Packets
Since DCCP-Listen packets solve a particular problem (NAT and/or
firewall traversal), the generation of DCCP-Listen packets on passive
sockets is tied to a condition (binding to an a priori known remote
address and service code) to ensure this does not interfere with the
general case of "normal" DCCP connections (where client addresses are
generally not known in advance).
In the TCP world, the analogue is a transition from LISTEN to
SYN_SENT by virtue of sending data: "A fully specified passive call
can be made active by the subsequent execution of a SEND" ([RFC0793],
3.8). Unlike TCP, this update does not perform a role-change from
passive to active. Like TCP, DCCP-Listen packets are only sent by a
DCCP-server when the endpoint is fully specified (Section 2.2).
3.3. Repetition of DCCP-Listen Packets
Repetition is a necessary requirement, to increase robustness and the
chance of successful connection establishment when a DCCP-Listen
packet is lost due to congestion, link loss, or some other reason.
The decision to recommend a maximum number of 3 timeouts (2 repeated
copies of the original DCCP-Listen packet) results from the following
considerations: The repeated copies need to be spaced sufficiently
far apart in time to avoid suffering from correlated loss. The
interval of 200 ms was chosen to accommodate a wide range of wireless
Fairhurst Expires April 11, 2009 [Page 14]

Internet-Draft DCCP Simultaneous-Open Technique Oct 2008
and wired network paths.
Another constraint is given by the retransmission interval for the
DCCP-Request ([RFC4340], 8.1.1). To establish state, intermediate
systems need to receive a (retransmitted) DCCP-Listen packet before
the DCCP-Request times out (1 second). With three timeouts, each
spaced 200 milliseconds apart, the overall time is still below one
second. On the other hand, the sum of 600 milliseconds is
sufficiently large to provide for longer one-way delays, such as e.g.
found on some wireless links.
The rationale behind transitioning to the LISTEN state after two
retransmissions is that other problems, independent of establishing
middlebox state, may occur (such as delay or loss of the initial
DCCP-Request). Any late or retransmitted DCCP-Request packets will
then still reach the server allowiing connection establishment to
successfully complete.
Fairhurst Expires April 11, 2009 [Page 15]

Internet-Draft DCCP Simultaneous-Open Technique Oct 20084. Security Considerations
The method specified in this document generates a DCCP-Listen packet
addressed to a specific DCCP client. This exposes the state of a
DCCP server that is in a passive listening state (i.e. waiting to
accept a connection from a known client).
The exposed information is not encrypted and therefore could be seen
on the network path to the DCCP client. An attacker on this return
path could observe a DCCP-Listen packet and then exploit this by
spoofing a packet (e.g. DCCP-Request, DCCP-Reset) with the IP
addresses, DCCP ports, and service code that correspond to the values
to be used for the connection. As in other on-path attacks, this
could be used to inject data into a connection or to deny a
connection request. A similar on-path attack is also possible for
any DCCP connection, once the session is initiated by the client
([RFC4340], Section 18).
The DCCP-Listen packet is only sent in response to explicit prior
out-of-band signaling from a DCCP client to the DCCP server (e.g.
SDP [RFC4566]) information communicated via the Session Initiation
Protocol [RFC3261]), and will normally directly precede a DCCP-
Request sent by the client (which carries the same information).
This update does not significantly increase the complexity or
vulnerability of a DCCP implementation that conforms to [RFC4340]. A
DCCP server SHOULD therefore by default permit generation of DCCP-
Listen packets. A server that wishes to prevent disclosing this
information MAY refrain from generating DCCP-Listen packets, without
impacting subsequent DCCP state transitions, but possibly inhibiting
middlebox traversal.
Fairhurst Expires April 11, 2009 [Page 16]

Internet-Draft DCCP Simultaneous-Open Technique Oct 20085. IANA Considerations
The IANA should register a new Packet Type, "DCCP-Listen", in the
IANA DCCP Packet Types Registry. The decimal value 10 has been
assigned to this types. This registry entry must reference this
document.
Fairhurst Expires April 11, 2009 [Page 17]

Internet-Draft DCCP Simultaneous-Open Technique Oct 2008
Note to the RFC Editor:
This value must be confirmed by IANA in the registry when this
document is published, please then remove this note.
Fairhurst Expires April 11, 2009 [Page 18]

Internet-Draft DCCP Simultaneous-Open Technique Oct 2008
Acknowledgement
This update was originally co-authored by Dr Gerrit Renker,
University of Aberdeen, and the present author acknowledges his
insight in design of the protocol mechanism and in careful review of
the early revisions of the document text. Dan Wing assisted on
issues relating to the use of NAT and NAPT.
Fairhurst Expires April 11, 2009 [Page 19]

Internet-Draft DCCP Simultaneous-Open Technique Oct 2008Appendix A. Discussion of Existing NAT Traversal Techniques
This appendix provides a brief review of existing techniques to
establish connectivity across NAT devices, with the aim of providing
background information. This first considers TCP NAT traversal based
on simultaneous-open, and then discuss a second technique based on
role reversal. Further information can be found in [GTF04] and
[GF05].
A central idea shared by these techniques is to make peer-to-peer
sessions look like "outbound" sessions on each NAT device. Often a
rendezvous server, located in the public address realm, is used to
enable clients to discover their NAT topology and the addresses of
peers.
The term 'hole punching' was coined in [FSK05] and refers to creating
soft state in a traditional NAT device, by initiating an outbound
connection. A well-behaved NAT can subsequently exploit this to
allow a reverse connection back to the host in the private address
realm.
UDP and TCP hole punching use nearly the same technique. The
adaptation of the basic UDP hole punching principle to TCP NAT
traversal was introduced in section 4 of [FSK05] and relies on the
simultaneous-open feature of TCP [RFC0793]. A further difference
between UDP and TCP lies in the way the clients perform connectivity
checks, after obtaining suitable address pairs for connection
establishment. Whereas in UDP a single socket is sufficient, TCP
clients require several sockets for the same address / port tuple:
o a passive socket to listen for connectivity tests from peers and
o multiple active connections from the same address to test
reachability of other peers.
The SYN sent out by client A to its peer B creates soft state in A's
NAT. At the same time, B tries to connect to A:
o if the SYN from B has left B's NAT before the arrival of A's SYN,
both endpoints perform simultaneous-open (4-way handshake of SYN/
SYNACK);
o otherwise A's SYN may not enter B's NAT, which leads to B
performing a normal open (SYN_SENT => ESTABLISHED) and A
performing a simultaneous-open (SYN_SENT => SYN_RCVD =>
ESTABLISHED).
In the latter case, it is necessary that the NAT does not interfere
Fairhurst Expires April 11, 2009 [Page 22]

Internet-Draft DCCP Simultaneous-Open Technique Oct 2008
with a RST segment (REQ-4 in [ID-BEHAVE-TCP]). The simultaneous-open
solution is convenient due to its simplicity, and is thus a preferred
mode of operation in the TCP extension for ICE ([ID-MMUSIC-ICE], sec.
2).
A.1. NAT traversal Based on a Simultaneous-Request
Among the various TCP NAT traversal approaches, the one using
simultaneous-open suggests itself as a candidate for DCCP due to its
simplicity [GF05], [NAT-APP].
A characteristic of TCP simultaneous-open is that this erases the
clear distinction between client and server: both sides enter through
active (SYN_SENT) as well as passive (SYN_RCVD) states. This
characteristic conflicts with the DCCP design decision to provide a
clear separation between client and server functions ([RFC4340],
4.6). Furthermore, several mechanisms implicitly rely on clearly-
defined client/server roles:
o Feature Negotiation: with few exceptions, almost all of DCCP's
negotiable features use the "server-priority" reconciliation rule
([RFC4340], 6.3.1), whereby peers exchange their preference lists
of feature values, and the server decides the outcome.
o Closing States: only servers may generate DCCP-CloseReq packets
(asking the peer to hold timewait state), while clients are only
permitted to send DCCP-Close or DCCP-Reset packets to terminate a
connection ([RFC4340], 8.3).
o Service Codes [ID-DCCP-SC]: servers may be associated with
multiple service codes, while clients must be associated with
exactly one ([RFC4340], 8.1.2).
o Init Cookies: may only be used by the server and on DCCP-Response
packets ([RFC4340], 8.1.4).
The latter two points are not obstacles per se, but would have
hindered the transition from a passive to an active socket. In DCCP,
a DCCP-Request is only generated by a client. The assumption that
"all DCCP hosts may be clients", was dismissed, since it would
require undersirable changes to the state machine and would limit
application programming. As a consequence, the retro-fitting a TCP-
style simultaneous-open into DCCP to allow simulatenous exchange of
DCCP-Connect packets was not recommended.
Fairhurst Expires April 11, 2009 [Page 23]

Internet-Draft DCCP Simultaneous-Open Technique Oct 2008A.2. Role Reversal
Another simple TCP NAT traversal schemes uses role traversal ([Epp05]
and [GTF04]), where a peer first opens an active connection for the
single purpose of punching a hole in the firewall; and then reverts
to a listening socket, accepting connections arriving via the new
path.
This solution would have had several disadvantages if used with DCCP.
First, a DCCP server would be required to change its role to
temporarily become a 'client'. This would have required modification
to the state machine, in particular the trearment of service codes
and perhaps Init Cookies. Further, the method must follow feature
negotiation, since a host's choice of initial options can rely on its
role (i.e. if an endpoint knows it is the server, it can make a
priori assumptions about the preference lists of features it is
negotiating with the client, thereby enforcing a particular policy).
Finally, the server would have needed additional processing to ensure
that the connection arriving at the listening socket matches the
previously opened active connection.
This approach was therefore not recommend for DCCP.
Fairhurst Expires April 11, 2009 [Page 24]

Internet-Draft DCCP Simultaneous-Open Technique Oct 2008Appendix B. Change Log
Revision 00 was based on a previous individual submission
draft-fairhurst-dccp-behave-update-01 by the same authors.
Revision 01:
o introduced many format changes to improve readability
o migrated background information into the Appendix
o added Section 1.3 to summarize the document structure
o updated introductory paragraph of Section 2 to account for new
structure
o added captions to all figures
o updated the specification in Section 2 to (i) permit options on
DCCP-Listen packets; (ii) explain why the presence of payload data
is not useful; (iii) clarify that middleboxes must not interpret
sequence numbers on DCCP-Listen packets
o clarified that the default value of the Allow Short Seqno feature
is to be used
o added references to the service code draft [ID-DCCP-SC]
o clarified the processing of DCCP-Listen packets by server
endpoints
o corrected the reaction of a client implementing [RFC4340] only -
DCCP-Listen packets are treated as unknown and hence do not
generate a DCCP-Reset
o swapped order of IANA / Security-Considerations sections
o added a note in the Security Considerations section that servers
may refrain from generating DCCP-Listen packets
Revision 02:
o minor edits following WG feedback at IETF meeting
o updated to reflect ID.Behave-DCCP
o update to reflect comments from Colin Perkins
Fairhurst Expires April 11, 2009 [Page 25]

Internet-Draft DCCP Simultaneous-Open Technique Oct 2008
o added a tentative IANA code point (as suggested at IETF-73)
o DRAFT -02
o Edits following editorial corrections and suggestions from Tom
Phelan
o Edits following comments from Dan Wing on role of NAT,
retransmision, and other issues.
o Revised authors list
o Reworded abstract, reworded appendices to clarify what was not
done
o Checked spelling
o Although this version includes significant changes to format and
text it does not seek to modify the intended procedure for a
server.
o
o DRAFT - 03
o Comments by Dan Wing
o DRAFT -04
o Corrections by Dan Wing, and new diagram Figure 5 to and text to
clarify the retransmission algorithm.
o DRAFT -05
o Sections re-ordered to bring the packet type definition to the
front, and to correct a section mis-order in draft-04. References
linked to IETF WGs and updated to satisfy IDNiTs.
o A number of Typos were fixed.
Fairhurst Expires April 11, 2009 [Page 26]

Internet-Draft DCCP Simultaneous-Open Technique Oct 2008
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.
Fairhurst Expires April 11, 2009 [Page 29]