summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5596.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5596.txt')
-rw-r--r--doc/rfc/rfc5596.txt1403
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]
+