DCCP Working Group                                          G. Fairhurst
Internet-Draft                                                 G. Renker
Intended status: Standards Track                  University of Aberdeen
Expires: August 21, 2008                               February 18, 2008

 DCCP Simultaneous-Open Technique to Facilitate NAT/Middlebox Traversal

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on August 21, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Fairhurst & Renker       Expires August 21, 2008                [Page 1]

Internet-Draft      DCCP Simultaneous-Open Technique       February 2008


   This document specifies an update to the Datagram Congestion Control
   Protocol (DCCP), a connection-oriented and datagram-based transport

   The update assists DCCP applications which need to communicate
   through one or more middleboxes (e.g.  Network Address Translators or
   firewalls), where establishing necessary middlebox state requires
   peering endpoints to initiate communication in a near-simultaneous

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Scope of this Document . . . . . . . . . . . . . . . . . .  3
     1.2.  Scope of the Problem to be Tackled . . . . . . . . . . . .  4
     1.3.  Discussion of Existing NAT Traversal Techniques  . . . . .  4
       1.3.1.  Near Simultaneous-Open of Connections  . . . . . . . .  5
       1.3.2.  Role Reversal  . . . . . . . . . . . . . . . . . . . .  6
   2.  Procedure for Near-Simultaneous Open . . . . . . . . . . . . .  8
     2.1.  Conventions and Terminology  . . . . . . . . . . . . . . .  8
     2.2.  DCCP-Listen Packet Format  . . . . . . . . . . . . . . . .  8
     2.3.  Protocol Method  . . . . . . . . . . . . . . . . . . . . . 10
       2.3.1.  Protocol Method for DCCP-Server Endpoints  . . . . . . 10
       2.3.2.  Protocol Method for DCCP-Client Endpoints  . . . . . . 12
       2.3.3.  Processing by Routers and Middleboxes  . . . . . . . . 12
     2.4.  Examples of Use  . . . . . . . . . . . . . . . . . . . . . 12
     2.5.  Backwards Compatibility with RFC 4340  . . . . . . . . . . 14
   3.  Discussion of Design Decisions . . . . . . . . . . . . . . . . 15
     3.1.  Rationale for a New Packet Type  . . . . . . . . . . . . . 15
     3.2.  Generation of Listen Packets . . . . . . . . . . . . . . . 16
     3.3.  Repetition of Listen Packets . . . . . . . . . . . . . . . 16
   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 21
     6.2.  Informative References . . . . . . . . . . . . . . . . . . 21
   Appendix A.  Change Log  . . . . . . . . . . . . . . . . . . . . . 23
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
   Intellectual Property and Copyright Statements . . . . . . . . . . 25

Fairhurst & Renker       Expires August 21, 2008                [Page 2]

Internet-Draft      DCCP Simultaneous-Open Technique       February 2008

1.  Introduction

   UDP Network Address Translator (NAT) traversal is well understood and
   widely implemented.  NAT traversal for connection-oriented protocols
   (e.g.  TCP) uses similar principles, but in some cases requires more
   complex and expensive solutions, such as data relay servers [TURN].

   DCCP [RFC4340] is both datagram-based and connection-oriented; and
   thus NAT traversal of DCCP faces the same problems as TCP NAT
   traversal, without being able to simply reuse UDP-based NAT traversal
   techniques.  In addition, DCCP has the disadvantage of not being able
   to perform a simultaneous-open, a TCP-inherent characteristic which
   greatly simplifies NAT traversal.

   After discussing the problem space for DCCP, this document specifies
   an extension to facilitate DCCP NAT traversal, by explicitly
   supporting a widely implemented traversal principle known as 'hole
   punching'.  This extension produces the same outward effect as an
   simultaneous-open, but without internal changes to the standard
   operational procedure of DCCP.  The extension uses a dedicated
   indicator message, whose usage is tied to a specific condition, can
   thus be turned off, and is inter-operable with non-extended hosts.

   The object of this extension is in built-in support for middlebox
   traversal, to reduce reliance on external aids such as data relay

1.1.  Scope of this Document

   The technique described by this document applies to scenarios where
   one or both DCCP peers are located behind a middlebox.

   This document is specifically targeted at NAT traversal.  However,
   due to the similarity of involved principles, the technique and
   presented extension of DCCP may also be of similar use to the
   traversal of other types of middlebox, such as firewalls.

   The proposed extension is relevant to both client/server and peer-to-
   peer applications, such as VoIP, file sharing, or online gaming.  It
   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]).

   For the scope of this document we assume traditional (outbound) types
   of NAT as defined in [RFC2663] and further discussed in [RFC3022].
   We understand NAT traversal as involving one or more NAT devices of
   this type in the path (i.e. hierarchies of nested NAT devices are
   possible).  It is assumed that all NATs in the path between endpoints

Fairhurst & Renker       Expires August 21, 2008                [Page 3]

Internet-Draft      DCCP Simultaneous-Open Technique       February 2008

   are BEHAVE-compliant [NAT-APP].

   This memo does not discuss behavioural requirements of NAT devices to
   support DCCP traversal.  These may be described by a separate
   document.  We further assume that NAT devices provide only a minimum
   of DCCP protocol support, in that layer-4 checksums are updated to
   account for changes in the pseudo-header.

1.2.  Scope of the Problem to be Tackled

   We refer 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" addresses.

   We consider DCCP NAT traversal 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 always possible, whereas cases (2) and (3)
   require NAT traversal techniques.  In this document we do not
   consider use of pre-configured static NAT address maps, which would
   also allow outside hosts to connect to the private network in cases
   (2) and (3).

   A DCCP implementation conforming to [RFC4340] can perform NAT
   traversal with the help of an external data relay server.  The
   extension described in this document facilitates NAT traversal
   without indirection via relay servers.

1.3.  Discussion of Existing NAT Traversal Techniques

   This section is a brief review of existing techniques to establish
   connectivity across NAT devices, the basic idea being 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

Fairhurst & Renker       Expires August 21, 2008                [Page 4]

Internet-Draft      DCCP Simultaneous-Open Technique       February 2008

   allow a reverse connection back to the host in the private address

   The adaptation of the basic hole punching principle to TCP NAT
   traversal was introduced in section 4 of [FSK05] and relies on the
   simultaneous-open feature of TCP [RFC0793].  UDP and TCP hole
   punching use nearly the same technique.  The main difference lies in
   the way the clients perform connectivity checks, after obtaining the
   address pairs from the server.  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
      connectivity 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/

   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 =>

   In the latter case it is necessary that the NAT does not interfere
   with a RST segment (REQ-4 in [GBF+07]).  The simultaneous-open
   solution is convenient due to its simplicity, and is thus a preferred
   mode of operation in the TCP extension for ICE (section 2 of

   We note that a simultaneous-open is not the only existing solution
   for TCP NAT traversal [GTF04], [GF05]; other approaches are reviewed
   in the next subsection.

1.3.1.  Near Simultaneous-Open of Connections

   Among the various TCP NAT traversal approaches, simultaneous-open
   suggests itself due to its simplicity [GF05], [NAT-APP].  A
   characteristic of simultaneous-open is that the clear distinction
   between client and server is erased: both sides enter through active
   (SYN_SENT) as well as passive (SYN_RCVD) states.  This characteristic
   is in conflict with several ideas underlying DCCP, as a clear
   separation between client and server has been one of the initial

Fairhurst & Renker       Expires August 21, 2008                [Page 5]

Internet-Draft      DCCP Simultaneous-Open Technique       February 2008

   design decisions ([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 CloseReq packets (asking
      the peer to hold timewait state), while clients are only permitted
      to send Close or Reset packets to terminate a connection
      ([RFC4340], 8.3).

   o  Service Codes: 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 hinder the
   transition from a passive to an active socket.  The assumption that
   "all DCCP hosts are clients", on the other hand, must be dismissed
   since it limits application programming.  As a consequence, retro-
   fitting simultaneous-open into DCCP does not seem a very sensible

1.3.2.  Role Reversal

   After the simultaneous-open, one of the simplest TCP NAT traversal
   schemes involves 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, to
   accept incoming connections arriving via the new path.

   This solution has several disadvantages for DCCP.  First, a DCCP
   server would be required to change its role temporarily to 'client'.
   This requires modification of settings, in particular service codes
   and perhaps Init Cookies.

   Further, the the server must not yet have started feature
   negotiation, since its choice of initial options may 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).

   Lastly, the server needs additional processing to ensure that the
   connection coming through the listening socket matches the one for

Fairhurst & Renker       Expires August 21, 2008                [Page 6]

Internet-Draft      DCCP Simultaneous-Open Technique       February 2008

   which it previously opened an active connection.

   We therefore do not recommend this approach for DCCP.

Fairhurst & Renker       Expires August 21, 2008                [Page 7]

Internet-Draft      DCCP Simultaneous-Open Technique       February 2008

2.  Procedure for Near-Simultaneous Open

   This section presents the packet-processing details of the
   simultaneous-open technique for DCCP.  The technique does not employ
   role reversal - both endpoints start out with their designated roles,
   as specified in [RFC4340].  Neither does it require protocol support
   for a genuinely simultaneous handshake.

   The presented extension 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",
   document are to be interpreted as described in [RFC2119].

2.2.  DCCP-Listen Packet Format

   The document updates DCCP by adding a new packet type, DCCP-Listen,
   whose format is shown below

   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                          |

                         DCCP-Listen Packet Format

   A DCCP-Listen Packet MUST NOT include any DCCP options (since this

Fairhurst & Renker       Expires August 21, 2008                [Page 8]

Internet-Draft      DCCP Simultaneous-Open Technique       February 2008

   packet does not modify the receiver protocol state) and also MUST NOT
   include application data.  Therefore Data Offset MUST be set to 5,
   the length of the DCCP-Listen packet in 32-bit words.

   Furthermore, the following protocol fields MUST all be set to zero:

      CCVal (the connection has not been established),

      CsCov (there is no payload).

   A server conforming to this revision of the specification SHOULD set
   both Sequence Number fields to 0; clients MUST ignore the value of
   the Sequence Number fields; and middleboxes SHOULD NOT interpret
   sequence numbers on DCCP-Listen packets.

   The "Res" and "Reserved" fields are specified by [RFC4340] and its
   successors.  The interpretation of these fields is not modified by
   this document.

   The Type field has the value XX-IANA-assigned-XX, which indicates
   that this is a DCCP-Listen packet.

Fairhurst & Renker       Expires August 21, 2008                [Page 9]

Internet-Draft      DCCP Simultaneous-Open Technique       February 2008

Note to the RFC Editor:

   Please replace XX-IANA-assigned-XX in the above paragraph with the
   value assigned in the registry and remove this note.

   ==> End of note to the RFC Editor. <==

   DCCP-Listen packets use a single format only and therefore do not
   support the alternative use of short sequence numbers defined in
   section 5.1 of [RFC4340].  Hence X MUST be set to 1, and all DCCP-
   Listen packets with X=0 MUST be ignored.

   The Service Code field contains the service code ([RFC4340], 8.1.2)
   that the client peer wants to use for this connection.  This value
   MUST correspond to a service code that the server is actually
   offering for connections identified by the same source IP address and
   the same Source Port as the DCCP-Listen packet.  Since the server may
   use multiple service codes, the value of the Service Code field needs
   to be communicated out-of-band, from client to server, prior to
   sending the DCCP-Listen packet.

2.3.  Protocol Method

   We use the term "session" 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 that may be offered via the same port.

   We call the five-tuple <source IP-address, source port, service code,
   target IP-address, target port> a fully specified DCCP connection,
   and refer to an endpoints that has been assigned all five parameters
   as a "fully specified endpoint".  DCCP-Listen packets are only sent
   for the specific case of fully specified DCCP-server endpoints.

2.3.1.  Protocol Method for DCCP-Server Endpoints

   This document updates [RFC4340] for the case of fully specified DCCP-
   server endpoints.  The update conditionally applies to the way the
   server performs 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 numbers
   (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

Fairhurst & Renker       Expires August 21, 2008               [Page 10]

Internet-Draft      DCCP Simultaneous-Open Technique       February 2008

   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 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

        Figure 2: Updated state transition diagram for DCCP-Listen

   A fully-specified server endpoint performs passive-open from CLOSED
   by inviting the remote client to connect, via a single DCCP-Listen
   packet.  The packet is sent to the specified remote IP-adress:port,
   using the format specified in Section 2.2.  The server then
   transitions to INVITED.  (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 state
   INVITED, at a 200 millisecond interval and up to at most 2
   repetitions.  The retransmission timer is restarted with the same
   200ms interval after the second retransmission.  When, upon the next
   timeout, the server is still in the INVITED state, it SHOULD progress
   to LISTEN, and resume processing as per [RFC4340].

Fairhurst & Renker       Expires August 21, 2008               [Page 11]

Internet-Draft      DCCP Simultaneous-Open Technique       February 2008

   Fully-specified server endpoints SHOULD treat ICMP error messages
   received in reply to a DCCP-Listen packet as "soft errors" that do
   not cause a state transition.

   Any server receiving a DCCP-Listen packet in the LISTEN state MUST
   reply with a Reset (using Reset Code 7, "Connection Refused"), which
   is the expected behaviour with regard to [RFC4340].  Listen packets
   received in any other state MUST be ignored (cf. next subsection).

   Further details on the rationale are discussed in Section 3.

2.3.2.  Protocol Method for DCCP-Client Endpoints

   This document updates [RFC4340], by adding the following rules for
   the reception of DCCP-Listen packets by clients.

   Clients MUST silently discard any received DCCP-Listen packets,
   regardless of their current state.  The packet indicates only a
   willingness to accept a connection: if the client has already
   established a connection (OPEN or PARTOPEN), this has no meaning.

   If a client is awaiting the response to a DCCP-Request, it does not
   need to take specific action.  While in state REQUEST, other than
   ignoring DCCP-Listen packets, it MUST use the protocol method defined
   in [RFC4340].  This ensures that retransmissions will happen in the
   expected manner.

2.3.3.  Processing by Routers and Middleboxes

   Routers and middleboxes both act as forwarding agents for DCCP
   packets.  This document does not specify rules for forwarding DCCP
   packets.  We note, however, that DCCP-Listen packets do not require
   special treatment, and should therefore be forwarded end-to-end
   across Internet paths.

   Middleboxes may utilise the connection information (address, port,
   Service Code) to establish local forwarding state.  This has been the
   main motivation for adding the Service Code field to the DCCP-Listen
   packet: in combination with the source and destination addresses
   found in the enclosing IP-header, the DCCP-Listen packet thereby
   communicates all the information necessary to uniquely identify a
   DCCP session.

2.4.  Examples of Use

   In the examples below, DCCP A is the client and DCCP B is the server.
   NAT/Firewall device NA is placed before DCCP A, and NAT/Firewall
   device NB is placed before DCCP B.

Fairhurst & Renker       Expires August 21, 2008               [Page 12]

Internet-Draft      DCCP Simultaneous-Open Technique       February 2008

   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.

   DCCP A and DCCP B decide to communicate using some 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 state by sending a 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 -->     +--+-+----+-+->|                 |
          +------------------+  +-+    +-+  +-----------------+

       Sequence of events when a client is started before the server

   The diagram below reverses this sequencing:

          DCCP A                                       DCCP B
          ------               NA      NB              ------
          +------------------+  +-+    +-+  +-----------------+
          |(1) Initiation    |  | |    | |  |                 |
          |                  |  | |X---+-+--+<-- DCCP-Listen  |
          |DCCP-Request -->  +--+-+----+-+->|                 |
          |                  | <+-+----+-+--+<-- DCCP-Response|
          |DCCP-Ack -->      +--+-+----+-+> |                 |
          |                  |  | |    | |  |                 |
          |(2) Data transfer |  | |    | |  |                 |
          |DCCP-Data -->     +--+-+----+-+> |                 |
          +------------------+  +-+    +-+  +-----------------+

       Sequence of events when a server is started before the client

Fairhurst & Renker       Expires August 21, 2008               [Page 13]

Internet-Draft      DCCP Simultaneous-Open Technique       February 2008

2.5.  Backwards Compatibility with RFC 4340

   This document updates the connection-establishment procedures of

   There are no changes if a client implementing the extensions
   described in this document communicates with a server conforming to

   This document also does not modify communication for any server that
   implements a passive-open without fully binding the addresses, ports
   and service codes to be used.

   The receipt of a DCCP-Listen packet by a client that implements only
   [RFC4340] would lead to a DCCP-Reset (likely using code 4, "Packet
   Error" if the unknown packet type passes through).  This would abort
   the connection.

   The authors do not however expect these compatibility issues to
   introduce practical deployment problems.

Fairhurst & Renker       Expires August 21, 2008               [Page 14]

Internet-Draft      DCCP Simultaneous-Open Technique       February 2008

3.  Discussion of Design Decisions

3.1.  Rationale for a New Packet Type

   The DCCP-Listen packet specified in Section 2.2 has the same format
   as the DCCP-Request packet ([RFC4340], sec. 5.1), the only difference
   is in the value of the Type field.

   The usage however differs, since the DCCP-Listen serves as advisory
   message, not as part of the actual connection setup: sequence numbers
   have no meaning, and neither options nor payload are present.

   It is important to point out that a DCCP-Request packet could in
   theory also serve as indicator message, in the same way as the DCCP-
   Listen packet.  The following arguments were against this

   The first problem is that of semantic overloading: the Request is
   defined in [RFC4340] to serve a well-defined purpose, as the first
   packet of the 3-way handshake.  Additionally using it in the way as
   here specified for the DCCP-Listen packet would require DCCP
   processors to have two different processing paths: one where a
   Request is interpreted as part of the initial handshake, and one
   where the same packet is interpreted as indicator message.  This
   complicates 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 Reset if it has not yet entered the REQUEST
   state.  This document addresses that issue by asking clients to
   ignore DCCP-Listen packets in any state.  Adding a similar rule for
   the Request packet is more cumbersome: clients can not 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
   DCCP-Listen after having itself sent a (connection-initiation)
   Request.  Step 7 in section 8.5 of [RFC4340] requires the client to
   reply to an (indicator message) Request from the server with a Sync.
   However, sequence numbers are ignored for this type of message, so
   additional and complicating processing becomes necessary: either to
   ask the client not to respond to a Request when the Request of type
   "indicator message"; or ask middleboxes and servers to ignore Sync
   packets generated in response to Request packets serving as indicator
   message.  Furthermore, since no initial sequence numbers have been
   negotiated yet, sending a SyncAck would not be meaningful.

   Using a separate packet type allows simpler and clearer processing.

Fairhurst & Renker       Expires August 21, 2008               [Page 15]

Internet-Draft      DCCP Simultaneous-Open Technique       February 2008

   The rationale for ignoring the Sequence Number fields on DCCP-Listen
   packets is that endpoints have not yet entered connection setup: the
   Listen packet is sent out 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.

   Although the Sequence Number fields thus do not serve a purpose, both
   have been retained, to reuse the generic header format from section
   5.1 of [RFC4340].

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 has been tied to a condition (binding to an a priori known
   remote address and service code), so as to 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],

   Unlike TCP, this proposal does not perform a role-change from passive
   to active.

   Like TCP, we require that DCCP-Listen packets are only sent by a
   DCCP-server when the endpoint is fully specified (Section 2.3).

3.3.  Repetition of Listen Packets

   Repetition is a necessary requirement to increase robustness and the
   chance of successful connection establishment, in case a Listen
   packet is lost due to congestion, link loss or some other reason.

   Recommending a maximum number of 3 timeouts (2 repetitions) is due to
   the following considerations.  The repeated copies need to be spaced
   sufficiently far apart in time to avoid suffering from correlated
   loss.  The interval of 200ms has been chosen to accommodate a wide
   range of wired and wireless network paths.

   Another constraint is given by the retransmission interval for the
   DCCP-Request.  To establish state, intermediate systems need to
   receive a (retransmitted) DCCP-Listen packet before the DCCP-Request
   times out (1 second, cf. section 8.1.1 of [RFC4340]).  With three
   timeouts, each spaced 200 milliseconds apart, the overall time is
   still less than this value.  On the other hand, the sum of 600

Fairhurst & Renker       Expires August 21, 2008               [Page 16]

Internet-Draft      DCCP Simultaneous-Open Technique       February 2008

   milliseconds is sufficiently large to provide for large 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
   in such cases still reach the server, thus allowing connection
   establishment to succeed.

Fairhurst & Renker       Expires August 21, 2008               [Page 17]

Internet-Draft      DCCP Simultaneous-Open Technique       February 2008

4.  IANA Considerations

   This document requires IANA action by allocation of a new Packet Type
   from the IANA DCCP Packet Types Registry.  The name of the Packet
   Type is "DCCP-Listen" packet, and its type field is set to XX-IANA-

   The Registry entry is to reference this document.

Fairhurst & Renker       Expires August 21, 2008               [Page 18]

Internet-Draft      DCCP Simultaneous-Open Technique       February 2008

Note to the RFC Editor:

   Please replace XX-IANA-assigned-XX in the above paragraph with the
   value assigned in the registry and remove this note.

Fairhurst & Renker       Expires August 21, 2008               [Page 19]

Internet-Draft      DCCP Simultaneous-Open Technique       February 2008

5.  Security Considerations

   The method specified in this document exposes the state of a DCCP
   server that has been explicitly configured to accept a connection
   from a known client.  Establishing this state requires prior out-of-
   band signaling between the client and server (e.g. via SIP).  The
   technique generates a packet addressed to the expected client.

   This increases the vulnerability of the DCCP server, by revealing
   which ports are in a passive listening state (the information is not
   encrypted and therefore could be seen on the path to the client
   through the network).

   This document requires endpoint nodes to ignore reception of DCCP-
   Listen packets in any state other than LISTEN.

   We do not believe these changes significantly increase the complexity
   or vulnerability of a DCCP implementation that conforms to [RFC4340].

Fairhurst & Renker       Expires August 21, 2008               [Page 20]

Internet-Draft      DCCP Simultaneous-Open Technique       February 2008

6.  References

6.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4340]  Kohler, E., Handley, M., and S. Floyd, "Datagram
              Congestion Control Protocol (DCCP)", RFC 4340, March 2006.

6.2.  Informative References

   [Epp05]    Eppinger, J-L., "TCP Connections for P2P Apps: A Software
              Approach to Solving the NAT Problem", Carnegie Mellon
              University/ISRI Technical Report CMU-ISRI-05-104,
              January 2005.

   [FSK05]    Ford, B., Srisuresh, P., and D. Kegel, "Peer-to-Peer
              Communication Across Network Address Translators",
              Proceedings of USENIX-05, pages 179-192, 2005.

   [GBF+07]   Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
              Srisuresh, "NAT Behavioral Requirements for TCP", Work In
              Progress, draft-ietf-behave-tcp-07, April 2007.

   [GF05]     Guha, S. and P. Francis, "Characterization and Measurement
              of TCP Traversal through NATs and Firewalls", Proceedings
              of Internet Measurement Conference (IMC-05), pages 199-
              211, 2005.

   [GTF04]    Guha, S., Takeda, Y., and P. Francis, "NUTSS: A SIP based
              approach to UDP and TCP connectivity", Proceedings of
              SIGCOMM-04 Workshops, Portland, OR, pages 43-48, 2004.

   [H.323]    ITU-T, "Packet-based Multimedia Communications Systems",
              Recommendation H.323, July 2003.

   [NAT-APP]  Ford, B., Srisuresh, P., and D. Kegel, "Application Design
              Guidelines for Traversal through Network Address
              Translators", Work In Progress, draft-ford-behave-app-05,
              March 2007.

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, September 1981.

   [RFC2663]  Srisuresh, P. and M. Holdrege, "IP Network Address
              Translator (NAT) Terminology and Considerations",
              RFC 2663, August 1999.

Fairhurst & Renker       Expires August 21, 2008               [Page 21]

Internet-Draft      DCCP Simultaneous-Open Technique       February 2008

   [RFC3022]  Srisuresh, P. and K. Egevang, "Traditional IP Network
              Address Translator (Traditional NAT)", RFC 3022,
              January 2001.

   [RFC3235]  Senie, D., "Network Address Translator (NAT)-Friendly
              Application Design Guidelines", RFC 3235, January 2002.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [Ros07]    Rosenberg, J., "TCP Candidates with Interactive
              Connectivity Establishment (ICE)", Work In
              Progress, draft-ietf-mmusic-ice-tcp-05, November 2007.

   [TURN]     Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using
              Relays around NAT (TURN): Relay Extensions to Session
              Traversal Utilities for NAT (STUN)", Work In
              Progress, draft-ietf-behave-turn-06, January 2008.

Fairhurst & Renker       Expires August 21, 2008               [Page 22]

Internet-Draft      DCCP Simultaneous-Open Technique       February 2008

Appendix A.  Change Log

   Revision 00 retrieved from previous individual submission
   draft-fairhurst-dccp-behave-update-01 by the same authors.

Fairhurst & Renker       Expires August 21, 2008               [Page 23]

Internet-Draft      DCCP Simultaneous-Open Technique       February 2008

Authors' Addresses

   Godred Fairhurst
   University of Aberdeen
   School of Engineering
   Fraser Noble Building
   Aberdeen  AB24 3UE

   Email: gorry@erg.abdn.ac.uk
   URI:   http://www.erg.abdn.ac.uk

   Gerrit Renker
   University of Aberdeen
   School of Engineering
   Fraser Noble Building
   Aberdeen  AB24 3UE

   Email: gerrit@erg.abdn.ac.uk
   URI:   http://www.erg.abdn.ac.uk

Fairhurst & Renker       Expires August 21, 2008               [Page 24]

Internet-Draft      DCCP Simultaneous-Open Technique       February 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

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

   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


   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Fairhurst & Renker       Expires August 21, 2008               [Page 25]