[Docs] [txt|pdf|xml] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-fairhurst-dccp-behave-update) 00 01 02 03 04 05 06 07 08 RFC 5596

DCCP Working Group                                          G. Fairhurst
Internet-Draft                                                 G. Renker
Updates: 4340 (if approved)                       University of Aberdeen
Intended status: Standards Track                           Sept 14, 2008
Expires: March 18, 2009

 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 March 18, 2009.

Fairhurst & Renker       Expires March 18, 2009                 [Page 1]

Internet-Draft      DCCP Simultaneous-Open Technique           Sept 2008


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

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

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.  Structure of this Document . . . . . . . . . . . . . . . .  4
   2.  Procedure for Near-Simultaneous Open . . . . . . . . . . . . .  5
     2.1.  Conventions and Terminology  . . . . . . . . . . . . . . .  5
     2.2.  DCCP-Listen Packet Format  . . . . . . . . . . . . . . . .  5
     2.3.  Protocol Method  . . . . . . . . . . . . . . . . . . . . .  7
       2.3.1.  Protocol Method for DCCP-Server Endpoints  . . . . . .  7
       2.3.2.  Protocol Method for DCCP-Client Endpoints  . . . . . .  9
       2.3.3.  Processing by Routers and Middleboxes  . . . . . . . .  9
     2.4.  Examples of Use  . . . . . . . . . . . . . . . . . . . . .  9
     2.5.  Backwards Compatibility with RFC 4340  . . . . . . . . . . 10
   3.  Discussion of Design Decisions . . . . . . . . . . . . . . . . 12
     3.1.  Rationale for a New Packet Type  . . . . . . . . . . . . . 12
     3.2.  Generation of Listen Packets . . . . . . . . . . . . . . . 13
     3.3.  Repetition of DCCP-Listen Packets  . . . . . . . . . . . . 13
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 18
     6.2.  Informative References . . . . . . . . . . . . . . . . . . 18
   Appendix A.  Discussion of Existing NAT Traversal Techniques . . . 20
     A.1.  NAT traversal Based on Simultaneous-Open . . . . . . . . . 21
     A.2.  Role Reversal  . . . . . . . . . . . . . . . . . . . . . . 21
   Appendix B.  Change Log  . . . . . . . . . . . . . . . . . . . . . 23
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
   Intellectual Property and Copyright Statements . . . . . . . . . . 27

Fairhurst & Renker       Expires March 18, 2009                 [Page 2]

Internet-Draft      DCCP Simultaneous-Open Technique           Sept 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.  As
   such it faces the same problems as TCP NAT traversal, without the
   ability to simply reuse traversal solutions that work for UDP.  An
   additional issue is that the original specification of DCCP did not
   allow a server to perform a simultaneous-open, an inherent
   characteristic of TCP that greatly simplifies NAT traversal.

   After discussing the problem space for DCCP, this document specifies
   a new DCCP extension to facilitate DCCP NAT traversal, by explicitly
   supporting a widely used principle known as 'hole punching'.  This
   represents only a minor change to the standard DCCP operational
   procedure.  The extension uses a dedicated DCCP packet type, whose
   usage is tied to a specific condition, can thus be turned off, and is
   inter-operable with hosts that do not implement this extension.

   The object of this extension is DCCP native support for middlebox
   traversal [ID-Behave-DCCP], reducing dependence on external aids such
   as data relay servers.

1.1.  Scope of this Document

   This document specifically targets DCCP NAT traversal.  However, due
   to the similarity of the principles involved, the extension may be of
   similar use to traversal of other types of middlebox, such as

   This technique applies to scenarios where one or both DCCP peers are
   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]).

   The document assumes a traditional (outbound) type 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 are BEHAVE-
   compliant [NAT-APP].

Fairhurst & Renker       Expires March 18, 2009                 [Page 3]

Internet-Draft      DCCP Simultaneous-Open Technique           Sept 2008

   This document does not discuss specific behavioural requirements of
   devices to support DCCP NAT traversal, which are addressed in

1.2.  Scope of the Problem to be Tackled

   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" 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] requires a relay server
   to perform NAT traversal.  The extension specified by this document
   updates RFC 4340 to enable DCCP NAT traversal without the aid of
   relay servers.

1.3.  Structure of this Document

   For background information on existing NAT traversal techniques,
   please consult Appendix A.

   The normative specification of the extension is presented in the next
   section.  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 & Renker       Expires March 18, 2009                 [Page 4]

Internet-Draft      DCCP Simultaneous-Open Technique           Sept 2008

2.  Procedure for Near-Simultaneous Open

   This section is normative and specifies the simultaneous-open
   technique for DCCP.

   This 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

   This document adds a new DCCP 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                          |

                 Figure 1: Format of a DCCP-Listen Packet

   Since DCCP-Listen packets are issued before an actual connection is
   established, they MUST NOT carry payload data, and endpoints MUST
   ignore any payload data encountered in DCCP-Listen packets.

Fairhurst & Renker       Expires March 18, 2009                 [Page 5]

Internet-Draft      DCCP Simultaneous-Open Technique           Sept 2008

   At the time of writing. there areo known uses of the header option
   ([RFC4340], sec. 5.8) with a DCCP-Listen packet.

   Servers SHOULD set both Sequence Number fields to 0; clients MUST
   ignore the value of the Sequence Number fields; and middleboxes MUST
   NOT interpret sequence numbers on DCCP-Listen packets.

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

      CCVal (a connection has not been established),

      CsCov (there is no payload).

   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 decimal value 10, which indicates that this is
   a DCCP-Listen packet.

Fairhurst & Renker       Expires March 18, 2009                 [Page 6]

Internet-Draft      DCCP Simultaneous-Open Technique           Sept 2008

Note to the RFC Editor:

   This value needs to be confirmed by IANA when this document is
   published.  Please then remove this note.

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

   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.  Consequently, the default value of 0 for the Allow Short
   Seqno feature MUST be used, X MUST be set to 1, and 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 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 Protocol, SDP.

2.3.  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 [Fai08].

   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 endpoint 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 modifies the way the server performs a

   Prior to connection setup, it is common for DCCP server endpoints to
   not be fully specified: before the connection is established, a

Fairhurst & Renker       Expires March 18, 2009                 [Page 7]

Internet-Draft      DCCP Simultaneous-Open Technique           Sept 2008

   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 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 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-adress:port, using the format specified in Section 2.2.
   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 state
   INVITED, at a 200 millisecond interval and up to at most 2
   repetitions (Section 3 discusses this choice of timer interval).  The

Fairhurst & Renker       Expires March 18, 2009                 [Page 8]

Internet-Draft      DCCP Simultaneous-Open Technique           Sept 2008

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

   Server endpoints SHOULD in general ignore any incoming DCCP-Listen
   packets.  As an exception to this rule, a DCCP Server in state LISTEN
   MAY generate a Reset (Code 7, "Connection Refused") in response to a
   DCCP-Listen packet.  This Reset is an indication that two servers are
   simultaneously awaiting connections on the same port.

   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 rule for the
   reception of DCCP-Listen packets by clients:

   Clients MUST silently discard any received DCCP-Listen packets,
   regardless of their current state.

2.3.3.  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.  This has been the
   main motivation for adding the Service Code field: in combination
   with the source and destination addresses (found in the enclosing IP-
   header), the DCCP-Listen packet carries the necessary information 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. 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

Fairhurst & Renker       Expires March 18, 2009                 [Page 9]

Internet-Draft      DCCP Simultaneous-Open Technique           Sept 2008

   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

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

2.5.  Backwards Compatibility with RFC 4340

   No changes are required if a DCCP Client conforming to this document
   communicates with a DCCP Server conforming to [RFC4340].

Fairhurst & Renker       Expires March 18, 2009                [Page 10]

Internet-Draft      DCCP Simultaneous-Open Technique           Sept 2008

   If a client implements only [RFC4340], an incoming DCCP-Listen packet
   would be ignored due to step 1 in [RFC4340], 8.1, which at the same
   time also conforms to the behaviour specified by this document.

   This document further 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 authors therefore do not
   expect practical deployment problems with existing conformant DCCP

Fairhurst & Renker       Expires March 18, 2009                [Page 11]

Internet-Draft      DCCP Simultaneous-Open Technique           Sept 2008

3.  Discussion of Design Decisions

3.1.  Rationale for a New Packet Type

   This is an informative setcion that reviews the rationale for the
   design of this technique.  The DCCP-Listen packet specified in
   Section 2.2 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 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 Request is
   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 require DCCP processors to have two
   different processing paths: one where a DCCP-Request is interpreted
   as part of the initial handshake, and another where the same packet
   is interpreted as 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 if it has not yet entered the
   REQUEST state (step 7 in [RFC4340], 8.5).  This document lets client
   endpoints ignore DCCP-Listen packets.  Adding a similar rule for the
   DCCP-Request packet is cumbersome: clients would not be 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)
   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.
   Since sequence numbers are ignored for this type of message,
   additional and complex processing becomes 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 SyncAck would not be meaningful.

   Using a separate packet type therefore allows simpler and clearer

Fairhurst & Renker       Expires March 18, 2009                [Page 12]

Internet-Draft      DCCP Simultaneous-Open Technique           Sept 2008

   The rationale for ignoring the Sequence Number fields on DCCP-Listen
   packets is that 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.

   Although the DCCP-Listen Sequence Number fields are ignored, they
   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 is 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 extension 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.3).

3.3.  Repetition of DCCP-Listen Packets

   Repetition is a necessary requirement, to increase robustness and the
   chance of successful connection establishment: in case 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
   repetitions) 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 has been
   chosen to accommodate a wide range of wireless and wired network

   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

Fairhurst & Renker       Expires March 18, 2009                [Page 13]

Internet-Draft      DCCP Simultaneous-Open Technique           Sept 2008

   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, so that connection establishment
   successfully completes.

Fairhurst & Renker       Expires March 18, 2009                [Page 14]

Internet-Draft      DCCP Simultaneous-Open Technique           Sept 2008

4.  Security Considerations

   The technique specified in this document exposes the state of a DCCP
   server that has been explicitly pre-configured to accept a connection
   from a known client.  Establishing this state requires prior out-of-
   band signalling between the client and server (e.g. via the Session
   Initiation Protocol [RFC3261]).

   The technique generates a packet addressed to the expected client.
   This increases the vulnerability of a 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).  Servers that do not wish to disclose this
   information MAY refrain from generating DCCP-Listen packets, without
   impacting subsequent DCCP state transitions.

   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 March 18, 2009                [Page 15]

Internet-Draft      DCCP Simultaneous-Open Technique           Sept 2008

5.  IANA Considerations

   This document requires IANA action by allocation of a new Packet Type
   from the IANA DCCP Packet Types Registry.  The decimal value 10 has
   been assigned to a "DCCP-Listen" packet.

   The Registry entry references this document.

Fairhurst & Renker       Expires March 18, 2009                [Page 16]

Internet-Draft      DCCP Simultaneous-Open Technique           Sept 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 & Renker       Expires March 18, 2009                [Page 17]

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

   [Fai08]    Fairhurst, G., "The DCCP Service Code", Work In
              Progress, draft-ietf-dccp-serv-codes-06, June 2008.

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

              "Network Address Translation (NAT) Behavioral Requirements
              for DCCP", Work in Progress draft-ietf-behave-dccp-02.txt,

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

Fairhurst & Renker       Expires March 18, 2009                [Page 18]

Internet-Draft      DCCP Simultaneous-Open Technique           Sept 2008

              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.

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

   [Ros08]    Rosenberg, J., "TCP Candidates with Interactive
              Connectivity Establishment (ICE)", Work In
              Progress, draft-ietf-mmusic-ice-tcp-07, February 2008.

   [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-09, February 2008.

Fairhurst & Renker       Expires March 18, 2009                [Page 19]

Internet-Draft      DCCP Simultaneous-Open Technique           Sept 2008

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

   We first consider 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

   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

   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/

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

Fairhurst & Renker       Expires March 18, 2009                [Page 20]

Internet-Draft      DCCP Simultaneous-Open Technique           Sept 2008

   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 ([Ros08], sec. 2).

A.1.  NAT traversal Based on Simultaneous-Open

   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
   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 this into DCCP does not seem a very sensible idea.

A.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,
   accepting connections arriving via the new path.

Fairhurst & Renker       Expires March 18, 2009                [Page 21]

Internet-Draft      DCCP Simultaneous-Open Technique           Sept 2008

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

   Finally, the server needs additional processing to ensure that the
   connection coming through the listening socket matches the one for
   which it previously opened an active connection.

   We therefore do not recommend this approach for DCCP.

Fairhurst & Renker       Expires March 18, 2009                [Page 22]

Internet-Draft      DCCP Simultaneous-Open Technique           Sept 2008

Appendix 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

   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 [Fai08]

   o  clarified the processing of DCCP-Listen packets by server

   o  corrected the reaction of a client implementing [RFC4340] only -
      DCCP-Listen packets are treated as unknown and hence do not
      generate a 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 & Renker       Expires March 18, 2009                [Page 23]

Internet-Draft      DCCP Simultaneous-Open Technique           Sept 2008

   o  added a tentative IANA code point (as suggested at IETF-73)

Fairhurst & Renker       Expires March 18, 2009                [Page 24]

Internet-Draft      DCCP Simultaneous-Open Technique           Sept 2008

Note to the RFC Editor:

   Please remove this Change Log when done with the document.

Fairhurst & Renker       Expires March 18, 2009                [Page 25]

Internet-Draft      DCCP Simultaneous-Open Technique           Sept 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 March 18, 2009                [Page 26]

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

Fairhurst & Renker       Expires March 18, 2009                [Page 27]

Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/