doc: Add RFC documents

1 files changed, 1403 insertions, 0 deletions

diff --git a/doc/rfc/rfc5596.txt b/doc/rfc/rfc5596.txt
new file mode 100644
index 0000000..577f765
--- /dev/null
+++ b/doc/rfc/rfc5596.txt
@@ -0,0 +1,1403 @@
+
+
+
+
+
+
+Network Working Group                                       G. Fairhurst
+Request for Comments: 5596                        University of Aberdeen
+Updates: 4340                                             September 2009
+Category: Standards Track
+
+
+              Datagram Congestion Control Protocol (DCCP)
+   Simultaneous-Open Technique to Facilitate NAT/Middlebox Traversal
+
+Abstract
+
+   This document specifies an update to the Datagram Congestion Control
+   Protocol (DCCP), a connection-oriented and datagram-based transport
+   protocol.  The update adds support for the DCCP-Listen packet.  This
+   assists DCCP applications to communicate through middleboxes (e.g., a
+   Network Address Port Translator or a DCCP server behind a firewall),
+   where peering endpoints need to initiate communication in a near-
+   simultaneous manner to establish necessary middlebox state.
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright and License Notice
+
+   Copyright (c) 2009 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the BSD License.
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+
+
+
+Fairhurst                   Standards Track                     [Page 1]
+
+RFC 5596            DCCP Simultaneous-Open Technique      September 2009
+
+
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     1.1.  Scope of This Document . . . . . . . . . . . . . . . . . .  3
+     1.2.  DCCP NAT Traversal . . . . . . . . . . . . . . . . . . . .  4
+     1.3.  Structure of This Document . . . . . . . . . . . . . . . .  4
+   2.  Procedure for Near-Simultaneous-Open . . . . . . . . . . . . .  5
+     2.1.  Conventions and Terminology  . . . . . . . . . . . . . . .  5
+     2.2.  Protocol Method  . . . . . . . . . . . . . . . . . . . . .  5
+       2.2.1.  DCCP-Listen Packet Format  . . . . . . . . . . . . . .  6
+       2.2.2.  Protocol Method for DCCP Server Endpoints  . . . . . .  7
+       2.2.3.  Protocol Method for DCCP Client Endpoints  . . . . . . 11
+       2.2.4.  Processing by Routers and Middleboxes  . . . . . . . . 11
+     2.3.  Examples of Use  . . . . . . . . . . . . . . . . . . . . . 12
+       2.3.1.  Repetition of DCCP-Listen  . . . . . . . . . . . . . . 13
+       2.3.2.  Optional Triggered Retransmission of DCCP-Request  . . 14
+     2.4.  Backwards Compatibility with RFC 4340  . . . . . . . . . . 16
+   3.  Discussion of Design Decisions . . . . . . . . . . . . . . . . 16
+     3.1.  Rationale for a New Packet Type  . . . . . . . . . . . . . 17
+       3.1.1.  Use of Sequence Numbers  . . . . . . . . . . . . . . . 18
+     3.2.  Generation of Listen Packets . . . . . . . . . . . . . . . 18
+     3.3.  Repetition of DCCP-Listen Packets  . . . . . . . . . . . . 18
+   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
+   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
+   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
+   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
+     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 21
+     7.2.  Informative References . . . . . . . . . . . . . . . . . . 21
+   Appendix A.  Discussion of Existing NAT Traversal Techniques . . . 23
+     A.1.  NAT Traversal Based on a Simultaneous-Request  . . . . . . 24
+     A.2.  Role Reversal  . . . . . . . . . . . . . . . . . . . . . . 25
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fairhurst                   Standards Track                     [Page 2]
+
+RFC 5596            DCCP Simultaneous-Open Technique      September 2009
+
+
+1.  Introduction
+
+   The Datagram Congestion Control Protocol (DCCP) [RFC4340] is both
+   datagram-based and connection-oriented.  According to RFC 4340, DCCP
+   servers establish connections by passively listening for incoming
+   connection requests that are actively transmitted by DCCP clients.
+   These asymmetric roles can cause problems when the server is 'inside'
+   a middlebox, such as a Network Address Port Translation (NAPT), that
+   only allows connection requests to be initiated from inside (e.g.,
+   due to port overloading) [RFC5597].  Host-based and network firewalls
+   can also implement policies that lead to similar problems.  This
+   behaviour is currently the default for many firewalls.
+
+   UDP can support middlebox traversal using various techniques
+   [RFC4787] that leverage the connectionless nature of UDP and are
+   therefore not suitable for DCCP.  TCP supports middlebox traversal
+   through the use of its simultaneous-open procedure [RFC5382].  The
+   concepts of the TCP solution are applicable to DCCP, but DCCP cannot
+   simply reuse the same methods (see Appendix A).
+
+   After discussing the problem space for DCCP, this document specifies
+   an update to the DCCP state machine to offer native support that
+   allows a DCCP client to establish a connection to a DCCP server that
+   is inside one or more middleboxes.  This reduces dependence on
+   external aids such as data relay servers [STUN] 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 that 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
+   inside the perimeter controlled by a middlebox.  It is relevant to
+   both client/server and peer-to-peer applications, such as Voice over
+   IP (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]).
+
+
+
+
+
+
+
+
+
+Fairhurst                   Standards Track                     [Page 3]
+
+RFC 5596            DCCP Simultaneous-Open Technique      September 2009
+
+
+1.2.  DCCP NAT Traversal
+
+   The behavioural requirements for NAT devices supporting DCCP are
+   described in [RFC5597].  A "traditional NAT" [RFC3022] that directly
+   maps an IP address to a different IP address does not require the
+   simultaneous-open technique described in this document.
+
+   The method is required when the DCCP server is positioned behind one
+   or more NAPT devices in the path (hierarchies of nested NAPT devices
+   are possible).  This document refers to DCCP hosts located inside the
+   perimeter controlled by one or more NAPT devices as having "private"
+   addresses, and to DCCP hosts located in the global address realm as
+   having "public" addresses.
+
+   DCCP NAT traversal is considered for the following scenarios:
+
+   1.  Private client connects to public server.
+
+   2.  Public client connects to private server.
+
+   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, case (1) is possible using the protocol defined in [RFC4340].
+   A pre-configured, static NAT address map would allow outside hosts to
+   establish connections in cases (2) and (3).
+
+   A DCCP implementation conforming to [RFC4340] and a NAT device
+   conforming to [RFC5597] would require a DCCP relay server to perform
+   NAT traversal for cases (2) and (3).
+
+   This document describes a method to support cases (2) and (3) without
+   the aid of a DCCP relay server.  This method updates RFC 4340 and
+   requires the DCCP server to discover the IP address and the DCCP port
+   that correspond to the DCCP client.  Such signaling may be performed
+   out-of-band (e.g., using the Session Description Protocol (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 are provided in the concluding Section 5.
+
+
+
+Fairhurst                   Standards Track                     [Page 4]
+
+RFC 5596            DCCP Simultaneous-Open Technique      September 2009
+
+
+2.  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 Section 3.2 of [RFC4340] 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], Section 2.3):
+   DCCP sessions are uniquely identified by the 4-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 [RFC5595].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fairhurst                   Standards Track                     [Page 5]
+
+RFC 5596            DCCP Simultaneous-Open Technique      September 2009
+
+
+2.2.1.  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
+
+   o  The Source Port field indicates 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 Destination Port field indicates the port selected by a DCCP
+      client to identify the connection.  In this technique, this value
+      must be communicated out-of-band to the server.
+
+   o  The value of X MUST be set to 1.  A DCCP-Listen packet is sent
+      before a connection is established; therefore, there is no way to
+      negotiate use of short sequence numbers ([RFC4340], Section 5.1).
+
+   o  The value of the Sequence Number field in a DCCP-Listen packet is
+      not related to the DCCP sequence number used in normal DCCP
+      messages (see Section 3 for a description of the use of the DCCP
+      sequence number).  Thus, for DCCP-Listen packets:
+
+      *  A DCCP server SHOULD set the high and low bits of the Sequence
+         Number field to 0.
+
+      *  A DCCP client MUST ignore the value of the Sequence Number
+         field.
+
+      *  Middleboxes MUST NOT interpret sequence numbers in DCCP-Listen
+         packets.
+
+
+
+
+
+Fairhurst                   Standards Track                     [Page 6]
+
+RFC 5596            DCCP Simultaneous-Open Technique      September 2009
+
+
+   o  The Service Code field contains the Service Code value for which
+      the server is listening for a connection (Section 8.1.2 of
+      [RFC4340] and [RFC5595]).  This value MUST correspond to a Service
+      Code that the server is actually offering for a 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 Protocol (SDP) [RFC4566].
+
+   o  At the time of writing, there are no known uses of header options
+      ([RFC4340], Section 5.8) with a DCCP-Listen packet.  Clients MUST
+      ignore all options in received DCCP-Listen packets.  Therefore,
+      feature values cannot be negotiated using a DCCP-Listen packet.
+
+   o  At the time of writing, there are no known uses of payload data
+      with a DCCP-Listen packet.  Since DCCP-Listen packets are issued
+      before an actual connection is established, endpoints MUST ignore
+      any payload data encountered in DCCP-Listen packets.
+
+   o  The following protocol fields are required to have specific
+      values:
+
+      *  Data Offset MUST have a value of five or more (i.e., at least
+         20 bytes).
+
+      *  CCVal MUST be zero (a connection has not been established).
+
+      *  CsCov MUST be zero (use of the CsCov feature cannot be
+         negotiated).
+
+      *  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.
+
+2.2.2.  Protocol Method for DCCP Server Endpoints
+
+   This document updates Section 8.1 of [RFC4340] for the case of a
+   fully specified DCCP server endpoint.  The update modifies the way
+   the server performs a passive-open.
+
+
+
+
+
+Fairhurst                   Standards Track                     [Page 7]
+
+RFC 5596            DCCP Simultaneous-Open Technique      September 2009
+
+
+   Prior to connection setup, it is common for a DCCP server endpoint to
+   not be fully specified: before the connection is established, a
+   server usually specifies only the destination port and Service Code.
+   (Sometimes the destination address is also specified.)  This leaves
+   the source address and source port unspecified.  The endpoint only
+   becomes fully specified after performing the handshake for an
+   incoming connection.  For such cases, this document does not update
+   Section 8.4 of [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 source IP-address:port, destination 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 |
+     +--------+                           |   |           +---------+
+          |                               |   |  1st / 2nd  ^  |
+          |                 more than 2   |   |  retransm.  |  | receive
+          |               retransmissions |   +-------------+  | Request
+          |                               |    resend Listen   v
+          |                               |               +---------+
+          |                               +-------------->| LISTEN1 |
+          |                                               +---------+
+          |                                                    |
+          |  receive Request   +---------+    receive Request* |
+          +------------------->| RESPOND |<--------------------+
+             send Response     +---------+    send Response
+
+   * Note: The case of a server that responds to a DCCP-Request in
+   the INVITED state, transitions to the LISTEN1 state, and then
+   immediately transitions to the RESPOND state does not require
+   reception of an additional DCCP-Request packet.
+
+        Figure 2: Updated State Transition Diagram for DCCP-Listen
+
+
+
+
+
+
+
+
+Fairhurst                   Standards Track                     [Page 8]
+
+RFC 5596            DCCP Simultaneous-Open Technique      September 2009
+
+
+   This diagram introduces two additional DCCP server states in addition
+   to those listed in Section 4.3 of [RFC4340]:
+
+   INVITED
+      The INVITED state is associated with a specific DCCP connection
+      and represents a fully specified server socket in the listening
+      state that is generating DCCP-Listen packets towards the client.
+
+   LISTEN1
+      The LISTEN1 state is associated with a specific DCCP connection
+      and represents a fully specified server socket in the passive
+      listening state that will not generate further DCCP-Listen packets
+      towards the client.
+
+   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 figure below provides pseudocode describing the packet processing
+   in the INVITED state.  This processing step follows Step 2 in Section
+   8.5 of [RFC4340]).
+
+   The INVITED state is, like LISTEN, a passive state, characterised by
+   waiting in the absence of an established connection.  If the server
+   endpoint in the INVITED state receives a DCCP-Request that matches
+   the set of bound ports and addresses, it transitions to the LISTEN1
+   state and then immediately transitions to the RESPOND state, 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 with up to at most 2
+   repetitions (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 the LISTEN1 state.
+
+   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 the LISTEN, INVITED, or LISTEN1 states MAY generate a
+
+
+
+Fairhurst                   Standards Track                     [Page 9]
+
+RFC 5596            DCCP Simultaneous-Open Technique      September 2009
+
+
+   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.
+
+   The figure below provides pseudocode describing the packet processing
+   in the INVITED state.  This processing step follows Step 2 in Section
+   8.5 of RFC 4340 [RFC4340].
+
+    Step 2a: Process INVITED state
+      If S.state == INVITED,
+          /* State only entered for fully specified server endpoints */
+          /* on entry S will have been set to a socket */
+          If P.type == Request
+             /* Exit INVITED state and continue to process the packet */
+             S.state = LISTEN1
+             Continue with S.state := LISTEN1
+          Otherwise,
+             If P.type == Listen
+                /* The following line is optional */
+                Generate Reset(Connection Refused)
+                /* Otherwise, drop packet and return */
+             Otherwise,
+                Generate Reset(No Connection) unless P.type == Reset
+
+    Step 2b: Process LISTEN1 state
+      If S.state == LISTEN1,
+          /* State only entered for fully specified server endpoints */
+          /* Follows receipt of a Response packet */
+          /* or sending third Listen packet (after timer expiry) */
+          If P.type == Request,
+             S.state = RESPOND
+             Choose S.ISS (initial seqno) or set from Init Cookies
+             Initialize S.GAR := S.ISS
+             Set S.ISR, S.GSR, S.SWL, S.SWH from packet or Init Cookies
+             Continue with S.state == RESPOND
+             /* A Response packet will be generated in Step 11 */
+          Otherwise,
+             If P.type == Listen
+                /* The following line is optional */
+                Generate Reset(Connection Refused)
+                /* Otherwise, drop packet and return */
+             Otherwise,
+                Generate Reset(No Connection) unless P.type == Reset
+
+     Figure 3: Updated DCCP Pseudocode for INVITED and LISTEN1 States
+
+
+
+Fairhurst                   Standards Track                    [Page 10]
+
+RFC 5596            DCCP Simultaneous-Open Technique      September 2009
+
+
+2.2.3.  Protocol Method for DCCP Client Endpoints
+
+   This document updates Section 8.1.1 of [RFC4340] by adding the
+   following rule for the reception of DCCP-Listen packets by clients:
+
+   Endpoints are required to ignore any header options or payload data
+   encountered in DCCP-Listen packets (Section 2.2.1) and hence do not
+   provide meaningful communication to a client.  A client in any state
+   MUST silently discard any received DCCP-Listen packet, unless it
+   implements the optional procedure defined in the following section.
+
+2.2.3.1.  Optional Generation of Triggered Requests
+
+   This section describes an optional optimisation at the client that
+   can allow the client to avoid having to wait for a timeout following
+   a dropped DCCP-Request.  The operation requires clients to respond to
+   reception of DCCP-Listen packets when received in the REQUEST state.
+   DCCP-Listen packets MUST be silently discarded in all other states.
+
+   A client implementing this optimisation MAY immediately perform a
+   retransmission of a DCCP-Request following the reception of the first
+   DCCP-Listen packet.  The retransmission is performed in the same
+   manner as a timeout in the REQUEST state [RFC4340].  A triggered
+   retransmission SHOULD result in the client increasing the
+   exponential-backoff timer interval.
+
+   Note that a path delay greater than 200ms will result in multiple
+   DCCP-Listen packets arriving at the client before a DCCP-Response is
+   received.  Clients MUST therefore perform only one such
+   retransmission for each DCCP connection.  This requires maintaining
+   local state (e.g., one flag per connection).
+
+   Implementors and users of this optional method need to be aware that
+   host timing or path reordering can result in a server receiving two
+   DCCP-Requests (i.e., the server sending one unnecessary packet).
+   This would, in turn, trigger a client to send a second corresponding
+   DCCP-Response (also unnecessary).  These additional packets are not
+   expected to modify or delay the DCCP open procedure [RFC4340].
+
+   Section 2.3.2 provides examples of the use of triggered
+   retransmission.
+
+2.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.
+
+
+
+
+Fairhurst                   Standards Track                    [Page 11]
+
+RFC 5596            DCCP Simultaneous-Open Technique      September 2009
+
+
+   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 [RFC5595].  The processing of the DCCP-Listen packet by NAT
+   devices is specified in [RFC5597].
+
+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 permits 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 (in this case, labelled SDP), whereupon the
+   client and server are started.  DCCP B actively indicates its
+   listening state by sending a DCCP-Listen message.  This fulfills the
+   requirement of punching a hole in NB (also creating the binding to
+   the external address and port).  This message is dropped by NA since
+   no hole exists there yet.  DCCP A initiates a connection by entering
+   the REQUEST state and sending a DCCP-Request.  (It is assumed that if
+   NA were a NAT device, then this would also result in a binding that
+   maps the pinhole to the external address and port.)  The DCCP-Request
+   is received by DCCP B, via the binding at NB.  DCCP B transmits the
+   DCCP-Response and connects through the bindings now in place at NA
+   and NB.
+
+    DCCP A                                        DCCP B
+    ------               NA      NB               ------
+    +-----------------+  +-+    +-+  +-----------------+
+    |                 |  | |    | |  |                 | State = CLOSED
+    | SDP -->         |--+-+----+-+->|                 | State = INVITED
+    |                 |  | |X---+-+--|<-- DCCP-Listen  |
+    |(State=REQUEST)  |  | |    | |  |                 |
+    |DCCP-Request --> |--+-+----+-+->|                 |
+    |(State=PARTOPEN) | <+-+----+-+--|<-- DCCP-Response| State = RESPOND
+    |DCCP-Ack -->     |--+-+----+-+> |                 |
+    |                 |  | |    | |  |                 |
+    |                 |  | |    | |  |                 |
+    |DCCP-Data -->    |--+-+----+-+->|                 | State = OPEN
+    +-----------------+  +-+    +-+  +-----------------+
+
+   Figure 4: Event Sequence When the Server Is Started Before the Client
+
+
+
+
+Fairhurst                   Standards Track                    [Page 12]
+
+RFC 5596            DCCP Simultaneous-Open Technique      September 2009
+
+
+2.3.1.  Repetition of DCCP-Listen
+
+   This section examines the effect of not receiving the DCCP-Request.
+
+   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).  The key timer operations at the client and server are
+   respectively shown on the left and right of the diagram.  It
+   considers the case when the server does not receive a DCCP-Request
+   within the first 600ms (often the request would be received within
+   this interval).
+
+   The repetition of DCCP-Listen packets may be 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 transmission of another DCCP-Listen
+   packet.  If it expires after sending the third DCCP-Listen packet,
+   the server leaves the INVITED state to enter the LISTEN1 state (where
+   it passively waits for a DCCP-Request).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fairhurst                   Standards Track                    [Page 13]
+
+RFC 5596            DCCP Simultaneous-Open Technique      September 2009
+
+
+                DCCP A                           DCCP B
+                ------  NA      NB               ------
+                +----+  +-+    +-+  +-----------------+
+                |    |  | |    | |  |                 | State = CLOSED
+                | -->|--+-+----+-+--|--> SDP          |
+                |    |  | |    | |  |                 | State = INVITED
+                |    |  | |    | |  |                 |
+                |    |  | |X---+-+--|<-- DCCP-Listen  | Timer Starts
+                |    |  | |    | |  |                 |      |
+   DCCP-Request | -->|--->+--X | |  |   (dropped)     |      |
+   Timer Starts |    |  | |    | |  |                 |      |
+         |      |    |  | |    | |  |                 | 1st Timer Expiry
+         |      |    |<-+-+----+++--|<-- DCCP-Listen  |
+         |      |    |  | |    | |  |                 | Timer Starts
+         |      |    |  | |    | |  |                 |       |
+         |      |    |  | |    | |  |                 | 2nd Timer Expiry
+         |      |    |  | |    | |  |                 |
+         |      |    |<-+-+----+-+--|<-- DCCP-Listen  | Timer Starts
+         |      |    |  | |    | |  |                 |       |
+         |      |    |  | |    | |  |                 | 3rd Timer Expiry
+         |      |    |  | |    | |  |                 |
+         |      |    |  | |    | |  |                 | State = LISTEN1
+         |      ~    ~  ~ ~    ~ ~  ~                 ~
+         |      |    |  | |    | |  |                 |
+   Timer Expiry | -->|--+-+----+-+--|--> DCCP-Request |
+                |    |  | |    | |  |                 | State = RESPOND
+                | <--|--+-+----+-+--|<-- DCCP-Response|
+                +----+  +-+    +-+  +-----------------+
+
+              Figure 5: Repetition of the DCCP-Listen Packet
+
+2.3.2.  Optional Triggered Retransmission of DCCP-Request
+
+   The following figure illustrates a triggered retransmission.  In this
+   figure, the first DCCP-Listen is assumed to be lost in the network
+   (e.g., does not open a pinhole at NB).  A later DCCP-Request is also
+   not received (perhaps as a side effect of the first loss).  After
+   200ms, the DCCP-Listen packet is retransmitted and correctly
+   received.  This triggers the retransmission of the DCCP-Request,
+   which, when received, results in a corresponding DCCP-Response.
+
+
+
+
+
+
+
+
+
+
+
+Fairhurst                   Standards Track                    [Page 14]
+
+RFC 5596            DCCP Simultaneous-Open Technique      September 2009
+
+
+   DCCP A                                         DCCP B
+   ------               NA      NB               ------
+   +-----------------+  +-+    +-+  +-----------------+
+   |                 |  | |    | |  |                 | State = CLOSED
+   |SDP              |--+-+----+-+->|                 | State = INVITED
+   |(State= REQUEST) |  | |    | |  |                 |
+   |                 |  | |    | |X-|<-- DCCP-Listen  |
+   |DCCP-Request --> |--+-+---X| |  |                 |
+   |                 | <+-+----+-+--|<-- DCCP-Listen  |(retransmit)
+   |                 |  | |    | |  |                 |
+   |DCCP-Request --> |--+-+----+-+->|                 | State = RESPOND
+   |  (Triggered)    |  | |    | |  |                 |
+   |                 |<-+-+----+-+--|<-- DCCP-Response|
+   |(State= PARTOPEN)|  | |    | |  |                 |
+   |DCCP-Ack -->     |--+-+----+-+->|                 | State = OPEN
+   +-----------------+  +-+    +-+  +-----------------+
+
+            Figure 6: Example Showing a Triggered DCCP-Request
+
+   The figure below illustrates the sequence of packets exchanged when a
+   DCCP-Listen and DCCP-Request are processed out of order.  Reception
+   of the DCCP-Listen packet by the client triggers retransmission of
+   the DCCP-Request.  The server responds to the first DCCP-Request and
+   enters the RESPOND state.  The server subsequently responds to the
+   second DCCP-Request with another DCCP-Response, which is ignored by
+   the client (already in the PARTOPEN state).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fairhurst                   Standards Track                    [Page 15]
+
+RFC 5596            DCCP Simultaneous-Open Technique      September 2009
+
+
+   DCCP A                                        DCCP B
+   ------                NA     NB              ------
+   +-----------------+  +-+    +-+  +-----------------+
+   |                 |  | |    | |  |                 | State = CLOSED
+   |SDP              |--+-+----+-+->|                 | State = INVITED
+   |(State = REQUEST)|  | |    | |  |                 |
+   |DCCP-Request --> |--+-+-  -+-+--|<-- DCCP-Listen  |
+   |                 |  | | \/ | |  |                 |
+   |                 |  | | /\ | |  |                 |
+   |                 |<-+-+-  -+-+->|                 |
+   |DCCP-Request --> |--+-+-  -+-+--|<-- DCCP-Response| State = RESPOND
+   |  (Triggered)    |  | | \/ | |  |                 |
+   |                 |  | | /\ | |  |                 |
+   |                 |<-+-+-  -+-+->|                 |
+   |(State= PARTOPEN)|  | |    | |  |                 |
+   |DCCP-Ack     --> |--+-+-  -+-+--|<-- DCCP-Response|
+   |  (Triggered)    |  | | \/ | |  |                 |
+   |                 |  | | /\ | |  |                 |
+   |  (Ignored)      |<-+-+-  -+-+->|                 | State = OPEN
+   |                 |  | |    | |  |                 |
+   +-----------------+  +-+    +-+  +-----------------+
+
+      Figure 7: Example Showing an Unnecessary Triggered DCCP-Request
+
+2.4.  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].
+
+   If a client implements only [RFC4340], an incoming DCCP-Listen packet
+   would be ignored due to step 1 in Section 8.1 of [RFC4340], which at
+   the same time also conforms to the behaviour specified by this
+   document.
+
+   This document further does not modify communication for any DCCP
+   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 implementations.
+
+3.  Discussion of Design Decisions
+
+   This is an informative section that reviews the rationale for the
+   design of this method.
+
+
+
+
+
+
+
+Fairhurst                   Standards Track                    [Page 16]
+
+RFC 5596            DCCP Simultaneous-Open Technique      September 2009
+
+
+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], Section 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 can be communicated.
+
+   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 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 indication of an intention to accept a new
+   connection.  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 Section 8.5 of [RFC4340]).  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 DCCP-Request packet meant to indicate an intention to
+   accept a new connection 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 a DCCP-Request from the server with a DCCP-Sync packet.
+   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
+   used as an indication, or to ask middleboxes and servers to ignore
+   DCCP-Sync packets generated in response to DCCP-Request packets that
+   are used as indications.  Furthermore, since no initial sequence
+   numbers have been negotiated at this stage, sending a DCCP-SyncAck
+   would not be meaningful.
+
+   The use of a separate packet type therefore allows simpler and
+   clearer processing.
+
+
+
+Fairhurst                   Standards Track                    [Page 17]
+
+RFC 5596            DCCP Simultaneous-Open Technique      September 2009
+
+
+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
+
+   A DCCP server should by default permit generation of DCCP-Listen
+   packets.  Since DCCP-Listen packets solve a particular problem with
+   NAT and/or firewall traversal, the generation of DCCP-Listen packets
+   on passive sockets is tied to a condition (binding to a remote
+   address and Service Code that are both known a priori) 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],
+   Section 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
+   consideration: the repeated copies need to be spaced sufficiently far
+   apart in time to avoid suffering from correlated loss.  The interval
+   of 200ms was chosen to accommodate a wide range of wireless and wired
+   network paths.
+
+
+
+
+Fairhurst                   Standards Track                    [Page 18]
+
+RFC 5596            DCCP Simultaneous-Open Technique      September 2009
+
+
+   Another constraint is given by the retransmission interval for the
+   DCCP-Request ([RFC4340], Section 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.  The sum of 600 milliseconds is sufficiently
+   large to provide for longer one-way delays, as is the case, e.g., on
+   some wireless links.
+
+   The rationale behind transitioning to the LISTEN1 state after two
+   repetitions 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, allowing connection establishment to
+   successfully complete.
+
+4.  Security Considerations
+
+   General security considerations for DCCP are described in [RFC4340].
+   Security considerations for Service Codes are further described in
+   [RFC5595].
+
+   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 or 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
+
+
+
+Fairhurst                   Standards Track                    [Page 19]
+
+RFC 5596            DCCP Simultaneous-Open Technique      September 2009
+
+
+   information MAY refrain from generating DCCP-Listen packets without
+   impacting subsequent DCCP state transitions, but possibly inhibiting
+   middlebox traversal.
+
+   The DCCP base specification in RFC 4340 defines an Init Cookie
+   option, which lets a DCCP server avoid having to hold any state until
+   the three-way, connection-setup handshake has completed.  This
+   specification enables an out-of-band mechanism that forces the server
+   to hold state for a connection that has not yet been established.
+   This is a change in the security profile of DCCP, although the impact
+   is expected to be minimal and depends on the security features of the
+   out-of-band mechanism (SIP SDP is one such mechanism that provides
+   sufficient security features).
+
+   The method creates a new way for a client to set up a DCCP connection
+   to a server using out-of-band data, transported over a signaling
+   connection.  If the signaling connection is not encrypted, an
+   eavesdropper could see the client IP address and the port for the to-
+   be-established DCCP connection, and generate a DCCP-Listen packet
+   towards the client using its own server IP address and port.
+   However, a client will only respond to a received DCCP-Listen packet
+   if the server IP address and port match an existing DCCP connection
+   that is in the REQUEST state (Section 2.3.2).  The method therefore
+   cannot be used to redirect the connection to a different server IP
+   address.
+
+5.  IANA Considerations
+
+   The IANA registered a new packet type, "DCCP-Listen", in the IANA
+   DCCP Packet Types Registry.  The decimal value 10 has been assigned
+   to this type.  This registry entry references this document.
+
+6.  Acknowledgements
+
+   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                   Standards Track                    [Page 20]
+
+RFC 5596            DCCP Simultaneous-Open Technique      September 2009
+
+
+7.  References
+
+7.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.
+
+   [RFC5595]  Fairhurst, G., "The DCCP Service Code", RFC 5595,
+              September 2009.
+
+7.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.
+
+   [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.
+
+   [ICE]      Rosenberg, J., "TCP Candidates with Interactive
+              Connectivity Establishment (ICE)", Work in Progress,
+              July 2008.
+
+   [NAT-APP]  Ford, B., "Application Design Guidelines for Traversal
+              through Network Address Translators", Work in Progress,
+              March 2007.
+
+   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
+              RFC 793, September 1981.
+
+
+
+
+
+Fairhurst                   Standards Track                    [Page 21]
+
+RFC 5596            DCCP Simultaneous-Open Technique      September 2009
+
+
+   [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.
+
+   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
+              Description Protocol", RFC 4566, July 2006.
+
+   [RFC4787]  Audet, F. and C. Jennings, "Network Address Translation
+              (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
+              RFC 4787, January 2007.
+
+   [RFC5382]  Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
+              Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
+              RFC 5382, October 2008.
+
+   [RFC5597]  Denis-Courmont, R., "Network Address Translation (NAT)
+              Behavioral Requirements for the Datagram Congestion
+              Control Protocol", BCP 150, RFC 5597, September 2009.
+
+   [STUN]     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,
+              June 2009.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fairhurst                   Standards Track                    [Page 22]
+
+RFC 5596            DCCP Simultaneous-Open Technique      September 2009
+
+
+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.  It first considers TCP NAT traversal based
+   on simultaneous-open, and then discusses 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 [RFC4787].
+   The adaptation of the basic UDP hole punching principle to TCP NAT
+   traversal [RFC5382] 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
+   and 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).
+
+
+
+
+Fairhurst                   Standards Track                    [Page 23]
+
+RFC 5596            DCCP Simultaneous-Open Technique      September 2009
+
+
+   In the latter case, it is necessary that the NAT does not interfere
+   with a RST segment (REQ-4 in [RFC5382]).  The simultaneous-open
+   solution is convenient due to its simplicity, and is thus a preferred
+   mode of operation in the TCP extension for Interactive Connectivity
+   Establishment (ICE) ([ICE], Section 2).
+
+A.1.  NAT Traversal Based on a Simultaneous-Request
+
+   Among the various TCP NAT traversal approaches, the one using a TCP
+   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],
+   Section 4.6).
+
+   In DCCP, 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], Section 6.3.1), whereby a peer exchanges its
+      preference lists of feature values, and the server decides the
+      outcome.
+
+   o  Closing States: only a server may generate DCCP-CloseReq packets
+      (asking the peer to hold timewait state), while a client is only
+      permitted to send DCCP-Close or DCCP-Reset packets to terminate a
+      connection ([RFC4340], Section 8.3).
+
+   o  Service Codes [RFC5595]: a server may be associated with multiple
+      Service Codes, while a client must be associated with exactly one
+      ([RFC4340], Section 8.1.2).
+
+   o  Init Cookies: may only be used by a server and on DCCP-Response
+      packets ([RFC4340], Section 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
+   undesirable changes to the state machine and would limit application
+   programming.  As a consequence, the retro-fitting of a TCP-style
+   simultaneous-open into DCCP to allow simultaneous exchange of DCCP-
+   Connect packets was not recommended.
+
+
+
+Fairhurst                   Standards Track                    [Page 24]
+
+RFC 5596            DCCP Simultaneous-Open Technique      September 2009
+
+
+A.2.  Role Reversal
+
+   Another simple TCP NAT traversal scheme uses role traversal ([Epp05],
+   [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 that arrive 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 treatment of Service Codes
+   and perhaps Init Cookies.  Further, the method would have needed to
+   follow feature negotiation, since an endpoint's choice of initial
+   options can rely on its role (i.e., an endpoint that knows it is the
+   server 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.
+
+Author's Address
+
+   Godred Fairhurst
+   University of Aberdeen
+   School of Engineering
+   Fraser Noble Building
+   Aberdeen  AB24 3UE
+   Scotland
+
+   EMail: gorry@erg.abdn.ac.uk
+   URI:   http://www.erg.abdn.ac.uk
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fairhurst                   Standards Track                    [Page 25]
+