idnits 2.17.1 draft-ietf-dccp-simul-open-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4340, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 340 has weird spacing: '... Listen v...' (Using the creation date from RFC4340, updated by this document, for RFC5378 checks: 2002-10-30) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 02, 2009) is 5471 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-11) exists of draft-ietf-dccp-serv-codes-09 == Outdated reference: A later version (-16) exists of draft-ietf-behave-turn-14 == Outdated reference: A later version (-16) exists of draft-ietf-mmusic-ice-tcp-07 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DCCP Working Group G. Fairhurst 3 Internet-Draft University of Aberdeen 4 Updates: 4340 (if approved) May 02, 2009 5 Intended status: Standards Track 6 Expires: November 3, 2009 8 DCCP Simultaneous-Open Technique to Facilitate NAT/Middlebox Traversal 9 draft-ietf-dccp-simul-open-08 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on November 3, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This document specifies an update to the Datagram Congestion Control 48 Protocol (DCCP), a connection-oriented and datagram-based transport 49 protocol. The update adds support for the DCCP-Listen packet. This 50 assists DCCP applications to communicate through middleboxes (e.g. a 51 DCCP server behind a firewall, or a Network Address Port Translator), 52 where peering endpoints need to initiate communication in a near- 53 simultaneous manner to establish necessary middlebox state. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Scope of this Document . . . . . . . . . . . . . . . . . . 3 59 1.2. DCCP NAT Traversal . . . . . . . . . . . . . . . . . . . . 3 60 1.3. Structure of this Document . . . . . . . . . . . . . . . . 4 61 2. Procedure for Near-Simultaneous Open . . . . . . . . . . . . . 5 62 2.1. Conventions and Terminology . . . . . . . . . . . . . . . 5 63 2.2. Protocol Method . . . . . . . . . . . . . . . . . . . . . 5 64 2.2.1. DCCP-Listen Packet Format . . . . . . . . . . . . . . 5 65 2.2.2. Protocol Method for DCCP Server Endpoints . . . . . . 8 66 2.2.3. Protocol Method for DCCP Client Endpoints . . . . . . 11 67 2.2.4. Processing by Routers and Middleboxes . . . . . . . . 12 68 2.3. Examples of Use . . . . . . . . . . . . . . . . . . . . . 13 69 2.3.1. Repetition of DCCP-Listen . . . . . . . . . . . . . . 13 70 2.3.2. Optional Triggered Retransmission of DCCP-Request . . 15 71 2.4. Backwards Compatibility with RFC 4340 . . . . . . . . . . 16 72 3. Discussion of Design Decisions . . . . . . . . . . . . . . . . 17 73 3.1. Rationale for a New Packet Type . . . . . . . . . . . . . 17 74 3.1.1. Use of sequence numbers . . . . . . . . . . . . . . . 18 75 3.2. Generation of Listen Packets . . . . . . . . . . . . . . . 18 76 3.3. Repetition of DCCP-Listen Packets . . . . . . . . . . . . 18 77 4. Security Considerations . . . . . . . . . . . . . . . . . . . 20 78 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 79 6. Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . 25 80 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 81 7.1. Normative References . . . . . . . . . . . . . . . . . . . 26 82 7.2. Informative References . . . . . . . . . . . . . . . . . . 26 83 Appendix A. Discussion of Existing NAT Traversal Techniques . . . 28 84 A.1. NAT traversal Based on a Simultaneous-Request . . . . . . 29 85 A.2. Role Reversal . . . . . . . . . . . . . . . . . . . . . . 30 86 Appendix B. Change Log - to be removed by RFC-Ed . . . . . . . . 31 87 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 34 89 1. Introduction 91 The Datagram Congestion Control Protocol (DCCP) [RFC4340] is both 92 datagram-based and connection-oriented. According to RFC 4340, DCCP 93 servers establish connections by passively listening for incoming 94 connection requests that are actively transmitted by DCCP clients. 95 These asymmetric roles can cause problems when the server is 'inside' 96 a middlebox, such as a Network Address and Port Translator (NAPT) 97 that only allows connection requests to be initiated from inside 98 (e.g. due to port overloading) [ID-BEHAVE-DCCP]. Host-based and 99 network firewalls can also implement policies that lead to similar 100 problems. This behaviour is currently the default for many 101 firewalls. 103 UDP can support middlebox traversal using various techniques 104 [RFC4787] that leverage the connectionless nature of UDP and are 105 therefore not suitable for DCCP. TCP supports middlebox traversal 106 through the use of its simultaneous open procedure [RFC5382]. The 107 concepts of the TCP solution are applicable to DCCP, but DCCP can not 108 simply reuse the same methods (see Appendix A). 110 After discussing the problem space for DCCP, this document specifies 111 an update to the DCCP state machine to offer native support to allow 112 a DCCP client to establish a connection to a DCCP server that is 113 inside one or more middleboxes. This reduces dependence on external 114 aids such as data relay servers [ID-BEHAVE-TURN] by explicitly 115 supporting a widely used principle known as 'hole punching'. 117 The method requires only a minor change to the standard DCCP 118 operational procedure. The use of a dedicated DCCP packet type ties 119 usage to a specific condition, ensuring the method is inter-operable 120 with hosts that do not implement this update, or choose to disable it 121 (see Section 4). 123 1.1. Scope of this Document 125 This method is useful in scenarios when a DCCP server is located 126 inside the perimeter controlled by a middlebox. It is relevant to 127 both client/server and peer-to-peer applications, such as VoIP, file 128 sharing, or online gaming and assists connections that utilise prior 129 out-of-band signaling (e.g. via a well-known rendezvous server 130 ([RFC3261], [H.323])) to notify both endpoints of the connection 131 parameters ([RFC3235], [NAT-APP]). 133 1.2. DCCP NAT Traversal 135 The behavioural requirements for NAT devices supporting DCCP are 136 described in [ID-BEHAVE-DCCP]. A "traditional NAT" [RFC3022], that 137 directly maps an IP address to a different IP address does not 138 require the simultaneous open method described in this document. 140 The method is required when the DCCP server is positioned behind one 141 or more NAPT devices in the path (hierarchies of nested NAPT devices 142 are possible). This document refers to DCCP hosts located inside the 143 perimeter controlled by one or more NAPT devices as having "private" 144 addresses, and to DCCP hosts located in the global address realm as 145 having "public" addresses. 147 DCCP NAT traversal is considered for the following scenarios: 149 1. Private client connects to public server. 151 2. Public client connects to private server. 153 3. Private client connects to private server. 155 A defining characteristic of traditional NAT devices [RFC3022] is 156 that private hosts can connect to external hosts, but not vice versa. 157 Hence the case (1) is possible using the protocol defined in 158 [RFC4340]. A pre-configured, static NAT address map would allow 159 outside hosts to connections in cases (2) and (3). 161 A DCCP implementation conforming to [RFC4340] and a NAT device 162 conforming to [ID-BEHAVE-DCCP] would require a DCCP relay server to 163 perform NAT traversal for cases (2) and (3). 165 This document describes a method to support cases (2) and (3) without 166 the aid of a DCCP relay server. This method updates RFC 4340 and 167 requires the DCCP server to discover the IP address and the DCCP port 168 that correspond to the DCCP client. Such signalling may be performed 169 out-of-band (e.g. using SDP [RFC4566]). 171 1.3. Structure of this Document 173 For background information on existing NAT traversal techniques, 174 please consult Appendix A. 176 The normative specification of the update is presented in Section 2. 177 An informative discussion of underlying design decisions then 178 follows, in Section 3. Security considerations are provided in 179 Section 4 and IANA considerations in the concluding Section 5. 181 2. Procedure for Near-Simultaneous Open 183 This section is normative and specifies the simultaneous-open 184 technique for DCCP. It updates the connection-establishment 185 procedures of [RFC4340]. 187 2.1. Conventions and Terminology 189 The document uses the terms and definitions provided in [RFC4340]. 190 Familiarity with this specification is assumed. In particular, the 191 following convention from ([RFC4340], 3.2) is used: 193 "Each DCCP connection runs between two hosts, which we often name 194 DCCP A and DCCP B. Each connection is actively initiated by one of 195 the hosts, which we call the client; the other, initially passive 196 host is called the server." 198 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 199 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 200 document are to be interpreted as described in [RFC2119]. 202 2.2. Protocol Method 204 The term "session" is used as defined in ([RFC2663], 2.3): DCCP 205 sessions are uniquely identified by the tuple of . 208 DCCP, in addition, introduces Service Codes, which can be used to 209 identify different services available via the same port [ID-DCCP-SC]. 211 2.2.1. DCCP-Listen Packet Format 213 This document adds a new DCCP packet type, DCCP-Listen, whose format 214 is shown below. 216 0 1 2 3 217 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 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Source Port | Dest Port | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Data Offset | CCVal | CsCov | Checksum | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Res | Type |X| Reserved | Sequence Number High Bits | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Sequence Number Low Bits | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Service Code | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 Figure 1: Format of a DCCP-Listen Packet 232 o The Source Port is the port on which the DCCP server is listening 233 for a connection from the IP address that appears as the 234 destination IP address in the packet. 236 o The Destination Port is the port selected by a DCCP client to 237 identify a connection by the DCCP client. In this technique, this 238 value must be communicated out-of-band to the server. 240 o The value of X MUST be set to 1. A DCCP-Listen packet is sent 241 before a connection is established, therefore there is no way to 242 negotiate use of short sequence numbers ([RFC4340], 5.1). 244 o The value of the sequence number field in a DCCP-Listen packet is 245 not related to the DCCP sequence number used in normal DCCP 246 messages (see Section 3 for a description of the use of the DCCP 247 sequence number). Thus, for DCCP-Listen packets: 249 * A DCCP server SHOULD set the high and low bits of the Sequence 250 Number field to 0. 252 * A DCCP client MUST ignore the value of the Sequence Number 253 field. 255 * Middleboxes MUST NOT interpret sequence numbers on DCCP-Listen 256 packets. 258 o The Service Code field contains the Service Code value for which 259 the server is listening for a connection ([RFC4340], 8.1.2, 260 [ID-DCCP-SC]). This value MUST correspond to a Service Code that 261 the server is actually offering for a connection identified by the 262 same source IP address and the same Source Port as that of the 263 DCCP-Listen packet. Since the server may use multiple Service 264 Codes, the specific value of the Service Code field needs to be 265 communicated out-of-band, from client to server, prior to sending 266 the DCCP-Listen packet, e.g. described using the Session 267 Description Protocol, SDP [RFC4566]. 269 o At the time of writing, there are no known uses of header options 270 ([RFC4340] , sec. 5.8) with a DCCP-Listen packet. Clients MUST 271 ignore all options in received DCCP-Listen packets. Therefore, 272 feature values can not be negotiated using a DCCP-Listen packet. 274 o At the time of writing, there are no known uses of payload data 275 with a DCCP-Listen packet. Since DCCP-Listen packets are issued 276 before an actual connection is established, endpoints MUST ignore 277 any payload data encountered in DCCP-Listen packets. 279 o The following protocol fields are required to have specific 280 values: 282 * Data Offset MUST have a value of five or more (i.e. at least 20 283 bytes). 285 * CCVal MUST be zero (a connection has not been established). 287 * CsCov MUST be zero (use of the CsCov feature can not be 288 negotiated). 290 * Type has the value 10, assigned by IANA to denote a DCCP-Listen 291 packet. 293 * X MUST be 1 (the Generic header must be used). 295 The remaining fields, including the "Res" and "Reserved" fields are 296 specified by [RFC4340] and its successors. The interpretation of 297 these fields is not modified by this document. 299 Note to the RFC Editor: 301 This value assigned to the DCCP-Listen packet needs to be confirmed 302 by IANA when this document is published. Please then remove this 303 note. 305 ==> End of note to the RFC Editor. <== 307 2.2.2. Protocol Method for DCCP Server Endpoints 309 This document updates section 8.1 of [RFC4340] for the case of a 310 fully specified DCCP server endpoint. The update modifies the way 311 the server performs a passive-open. 313 Prior to connection setup, it is common for a DCCP server endpoint to 314 not be fully specified: before the connection is established, a 315 server usually specifies only the destination port, and Service Code. 316 (Sometimes the destination address is also specified.) This leaves 317 the source address and source port unspecified. The endpoint only 318 becomes fully specified after performing the handshake for an 319 incoming connection. For such cases, this document does not update 320 [RFC4340], i.e. the server adheres to the existing state transitions 321 in the left half of Figure 2 (CLOSED => LISTEN => RESPOND). 323 A fully specified DCCP server endpoint permits exactly one client, 324 identified by source IP-address:port, destination IP-address:port, 325 plus a single Service Code, to set up the connection. Such a server 326 SHOULD perform the actions and state transitions shown in the right 327 half of Figure 2 in section 8.4, and specified below. 329 unspecified remote +--------+ fully specified remote 330 +---------------------| CLOSED |---------------------+ 331 | +--------+ send DCCP-Listen | 332 | | 333 v v 334 +--------+ timeout +---------+ 335 | LISTEN | +---+-----------| INVITED | 336 +--------+ | | +---------+ 337 | | | 1st / 2nd ^ | 338 | more than 2 | | retransm. | | receive 339 | retransmissions | +-------------+ | Request 340 | | resend Listen v 341 | | +---------+ 342 | +-------------->| LISTEN1 | 343 | +---------+ 344 | | 345 | receive Request +---------+ receive Request* | 346 +------------------->| RESPOND |<--------------------+ 347 send Response +---------+ send Response 349 * Note: A server that responds a DCCP-Request in the INVITED state, 350 transitions to the LISTEN1 state and then immediately transitions 351 to the RESPOND state. This does not require reception of an 352 additional DCCP-Request packet. 354 Figure 2: Updated state transition diagram for DCCP-Listen 356 This diagram introduces two additional DCCP server states in addition 357 to those listed in section 4.3 of [RFC4340]: 359 o INVITED The INVITED state is associated with a specific DCCP 360 connection and represents a fully-specified server socket in the 361 listening state that is generating DCCP-Listen packets towards the 362 client. 364 o LISTEN1 The LISTEN1 state is associated with a specific DCCP 365 connection and represents a fully-specified server socket in the 366 passive listening state that will not generate further DCCP-Listen 367 packets towards the client. 369 A fully specified server endpoint performs a passive-open from the 370 CLOSED state by inviting the remote client to connect. This is 371 performed by sending a single DCCP-Listen packet to the specified 372 remote IP-address:port, using the format specified in Section 2.2.1. 373 The figure below provides pseudocode describing the packet processing 374 in the INVITED state. This processing step follows Step 2 in section 375 8,5 of [RFC4340]). 377 The INVITED state is, like LISTEN, a passive state, characterised by 378 waiting in the absence of an established connection. If the server 379 endpoint in the INVITED state receives a DCCP-Request that matches 380 the set of bound ports and addresses, it transitions to the LISTEN' 381 state and then immediately transitions to the RESPOND state, where 382 further processing resumes as specified in [RFC4340]. 384 The server SHOULD repeat sending a DCCP-Listen packet while in the 385 INVITED state, at a 200 millisecond interval with up to at most 2 386 repetitions (Section 3 discusses this choice of time interval). If 387 the server is still in the INVITED state after a further period of 388 200ms following transmission of the third DCCP-Listen packet, it 389 SHOULD progress to the LISTEN1state. 391 Fully specified server endpoints SHOULD treat ICMP error messages 392 received in response to a DCCP-Listen packet as "soft errors" that do 393 not cause a state transition. Reception of an ICMP error message as 394 a result of sending a DCCP-Listen packet does not necessarily 395 indicate a failure of the following connection request, and therefore 396 should not result in a server state change. This reaction to soft 397 errors exploits the valuable feature of the Internet that for many 398 network failures, the network can be dynamically reconstructed 399 without any disruption of the endpoints. 401 Server endpoints SHOULD ignore any incoming DCCP-Listen packets. A 402 DCCP server in the LISTEN, INVITED, or LISTEN1states MAY generate a 403 DCCP-Reset packet (Code 7, "Connection Refused") in response to a 404 received DCCP-Listen packet. This DCCP-Reset packet is an indication 405 that two servers are simultaneously awaiting connections on the same 406 port. 408 Further details on the design rationale are discussed in Section 3. 410 The figure below provides pseudocode describing the packet processing 411 in the INVITED state. This processing step follows Step 2 in section 412 8.5 of RFC 4340 [RFC4340] 413 Step 2a: Process INVITED state 414 If S.state == INVITED, 415 /* State only entered for fully-specified server endpoints */ 416 /* on entry S will have been set to a socket */ 417 If P.type == Request 418 /* Exit INVITED state and continue to process the packet */ 419 S.state = LISTEN1 420 Continue with S.state := LISTEN1 421 Otherwise, 422 If P.type == Listen 423 /* The following line is optional */ 424 Generate Reset(Connection Refused) 425 /* otherwise Drop packet and return */ 426 Otherwise, 427 Generate Reset(No Connection) unless P.type == Reset 429 Step 2b: Process LISTEN1 state 430 If S.state == LISTEN1, 431 /* State only entered for fully-specified server endpoints */ 432 /* Follows receipt of a Response packet */ 433 /* or sending third Listen packet (after timer expiry) */ 434 If P.type == Request, 435 S.state = RESPOND 436 Choose S.ISS (initial seqno) or set from Init Cookies 437 Initialize S.GAR := S.ISS 438 Set S.ISR, S.GSR, S.SWL, S.SWH from packet or Init Cookies 439 Continue with S.state == RESPOND 440 /* A Response packet will be generated in Step 11 */ 441 Otherwise, 442 If P.type == Listen 443 /* The following line is optional */ 444 Generate Reset(Connection Refused) 445 /* otherwise Drop packet and return */ 446 Otherwise, 447 Generate Reset(No Connection) unless P.type == Reset 449 Figure 3: Updated DCCP pseudocode for INVITED and LISTEN' states 451 2.2.3. Protocol Method for DCCP Client Endpoints 453 This document updates section 8.1.1 of [RFC4340], by adding the 454 following rule for the reception of DCCP-Listen packets by clients: 456 A client in any state MUST silently discard any received DCCP-Listen 457 packet, unless it implements the optional procedure defined in the 458 following section. 460 2.2.3.1. Optional generation of Triggered Requests 462 This section describes an optional optimisation at the client that 463 can avoid clients having to wait for a timeout following a dropped 464 DCCP-Request. The operation requires clients to respond to reception 465 of DCCP-Listen packets when received in the REQUEST state. DCCP- 466 Listen packets MUST be silently discarded in all other states. 468 A client implementing this optmisation MAY immediately perform a 469 retransmission of a DCCP-Request following the reception of the first 470 DCCP-Listen packet. The retransmission is performed in the same 471 manner as a timeout in the REQUEST state [RFC4340]. A triggered 472 retransmission SHOULD result in the client increasing the 473 exponential-backoff timer interval. 475 Note that a path delay greater than 200ms will result in multiple 476 DCCP-Listen packets arriving at the client before a DCCP-Response is 477 received. Clients MUST therefore perform only one such 478 retransmission for each DCCP connection. This requires maintaining 479 local state (e.g. one flag per connection) 481 Implementors and users of this optional method need to be aware that 482 host timing or path reordering can result in a server receiving two 483 DCCP-Requests (i.e., the server sending one unnecessary packet). 484 This would, in turn, trigger a client to send a second corresponding 485 DCCP-Response (also unnecessary). These additional packets are not 486 expected to modify or delay the DCCP open procedure [RFC4340]. 488 Section 2.3.2 provides examples of the use of triggered 489 retransmission. 491 2.2.4. Processing by Routers and Middleboxes 493 DCCP-Listen packets do not require special treatment and should thus 494 be forwarded end-to-end across Internet paths, by routers and 495 middleboxes alike. 497 Middleboxes may utilise the connection information (address, port, 498 Service Code) to establish local forwarding state. The DCCP-Listen 499 packet carries the necessary information to uniquely identify a DCCP 500 session in combination with the source and destination addresses 501 (found in the enclosing IP-header), including the DCCP Service Code 502 value [ID-DCCP-SC]. The processing of the DCCP-Listen packet by NAT 503 devices is specified in [ID-BEHAVE-DCCP]. 505 2.3. Examples of Use 507 In the examples below, DCCP A is the client and DCCP B is the server. 508 A middlebox device (NAT/Firewall), NA is placed before DCCP A, and 509 another middlebox, NB, is placed before DCCP B. Both NA and NB use a 510 policy that permits DCCP packets to traverse the device for outgoing 511 links, but only permit incoming DCCP packets when a previous packet 512 has been sent out for the same connection. 514 In the figure below, DCCP A and DCCP B decide to communicate using an 515 out-of-band mechanism (in this case labelled SDP), whereupon the 516 client and server are started. DCCP B actively indicates its 517 listening state by sending a DCCP-Listen message. This fulfils the 518 requirement of punching a hole in NB (also creating the binding to 519 the external address and port). This message is dropped by NA since 520 no hole exists there yet. DCCP A initiates a connection by entering 521 the REQUEST state and sending a DCCP-Request. (It is assumed that if 522 NA were a NAT device, then this would also result in a binding that 523 maps the pinhole to the external address and port.) The DCCP-Request 524 is received by DCCP B, via the binding at NB. DCCP B transmits the 525 DCCP-Response and connects through the bindings now in place at NA 526 and NB. 528 DCCP A DCCP B 529 ------ NA NB ------ 530 +-----------------+ +-+ +-+ +-----------------+ 531 | | | | | | | | State = CLOSED 532 | SDP --> |--+-+----+-+->| | State = INVITED 533 | | | |X---+-+--|<-- DCCP-Listen | 534 |(State=REQUEST) | | | | | | | 535 |DCCP-Request --> |--+-+----+-+->| | 536 |(State=PARTOPEN) | <+-+----+-+--|<-- DCCP-Response| State = RESPOND 537 |DCCP-Ack --> |--+-+----+-+> | | 538 | | | | | | | | 539 | | | | | | | | 540 |DCCP-Data --> |--+-+----+-+->| | State = OPEN 541 +-----------------+ +-+ +-+ +-----------------+ 543 Figure 4: Event sequence when the server is started before the client 545 2.3.1. Repetition of DCCP-Listen 547 This section examines the effect of not receiving the DCCP-Request. 549 The figure below shows the sequence of packets where the DCCP server 550 enters the INVITED state after reception of out-of-band signaling 551 (e.g. SDP). The key timer operations at the client and server are 552 respectively shown on the left and right of the diagram. It 553 considers the case when the server does not receive a DCCP-Request 554 within the first 600 ms (often the request would be received within 555 this interval). 557 The repetition of DCCP-Listen packets may be implemented using a 558 timer. The timer is restarted with an interval of 200ms when sending 559 each DCCP-Listen packet. It is cancelled when the server leaves the 560 INVITED state. If the timer expires after the first and second 561 transmission, it triggers a transmission of another DCCP-Listen 562 Packet. If it expires after sending the third DCCP-Listen packet, 563 the server leaves the INVITED state, to enter the LISTEN1state (where 564 it passively waits for a DCCP-Request). 566 DCCP A DCCP B 567 ------ NA NB ------ 568 +----+ +-+ +-+ +-----------------+ 569 | | | | | | | | State = CLOSED 570 | -->|--+-+----+-+--|--> SDP | 571 | | | | | | | | State = INVITED 572 | | | | | | | | 573 | | | |X---+-+--|<-- DCCP-Listen | Timer Starts 574 | | | | | | | | | 575 DCCP-Request | -->|--->+--X | | | (dropped) | | 576 Timer Starts | | | | | | | | | 577 | | | | | | | | | 1st Timer Expiry 578 | | |<-+-+----+++--|<-- DCCP-Listen | 579 | | | | | | | | | Timer Starts 580 | | | | | | | | | | 581 | | | | | | | | | 2nd Timer Expiry 582 | | | | | | | | | 583 | | |<-+-+----+-+--|<-- DCCP-Listen | Timer Starts 584 | | | | | | | | | | 585 | | | | | | | | | 3rd Timer Expiry 586 | | | | | | | | | 587 | | | | | | | | | State = LISTEN1 588 | ~ ~ ~ ~ ~ ~ ~ ~ 589 | | | | | | | | | 590 Timer Expiry | -->|--+-+----+-+--|--> DCCP-Request | 591 | | | | | | | | State = RESPOND 592 | <--|--+-+----+-+--|<-- DCCP-Response| 593 +----+ +-+ +-+ +-----------------+ 595 Figure 5: Repetition of the DCCP-Listen Packet 597 2.3.2. Optional Triggered Retransmission of DCCP-Request 599 The following figure illustrates a triggered retransmission. In this 600 figure, the first DCCP-Listen is assumed to be lost in the network 601 (e.g. does not open a pin-hole at NB). A later DCCP-Request is also 602 not received (perhaps as a side-effect of the first loss). After 603 200ms, the DCCP-Listen packet is retransmitted and correctly 604 received. This triggers the retransmission of the DCCP-Request, 605 which, when received, results in a corresponding DCCP-Response. 607 DCCP A DCCP B 608 ------ NA NB ------ 609 +-----------------+ +-+ +-+ +-----------------+ 610 | | | | | | | | State = CLOSED 611 |SDP |--+-+----+-+->| | State = INVITED 612 |(State= REQUEST) | | | | | | | 613 | | | | | |X-|<-- DCCP-Listen | 614 |DCCP-Request --> |--+-+---X| | | | 615 | | <+-+----+-+--|<-- DCCP-Listen |(retransmit) 616 | | | | | | | | 617 |DCCP-Request --> |--+-+----+-+->| | State = RESPOND 618 | (Triggered) | | | | | | | 619 | |<-+-+----+-+--|<-- DCCP-Response| 620 |(State= PARTOPEN)| | | | | | | 621 |DCCP-Ack --> |--+-+----+-+->| | State = OPEN 622 +-----------------+ +-+ +-+ +-----------------+ 624 Figure 6: Example showing a triggered DCCP-Request 626 The figure below illustrates the sequence of packets exchanged when a 627 DCCP-Listen and DCCP-Request are processed out of order. Reception 628 of the DCCP-Listen packet by the client triggers retransmission of 629 the DCCP-Request. The server responds to the first DCCP-Request, and 630 enters the RESPOND state. The server subsequently responds to the 631 second DCCP-Request with another DCCP-Response, which is ignored by 632 the client (already in the PARTOPEN state). 634 DCCP A DCCP B 635 ------ NA NB ------ 636 +-----------------+ +-+ +-+ +-----------------+ 637 | | | | | | | | State = CLOSED 638 |SDP |--+-+----+-+->| | State = INVITED 639 |(State = REQUEST)| | | | | | | 640 |DCCP-Request --> |--+-+- -+-+--|<-- DCCP-Listen | 641 | | | | \/ | | | | 642 | | | | /\ | | | | 643 | |<-+-+- -+-+->| | 644 |DCCP-Request --> |--+-+- -+-+--|<-- DCCP-Response| State = RESPOND 645 | (Triggered) | | | \/ | | | | 646 | | | | /\ | | | | 647 | |<-+-+- -+-+->| | 648 |(State= PARTOPEN)| | | | | | | 649 |DCCP-Ack --> |--+-+- -+-+--|<-- DCCP-Response| 650 | (Triggered) | | | \/ | | | | 651 | | | | /\ | | | | 652 | (Ignored) |<-+-+- -+-+->| | State = OPEN 653 | | | | | | | | 654 +-----------------+ +-+ +-+ +-----------------+ 656 Figure 7: Example showing an unnecessary triggered DCCP-Request 658 2.4. Backwards Compatibility with RFC 4340 660 No changes are required if a DCCP client conforming to this document 661 communicates with a DCCP server conforming to [RFC4340]. 663 If a client implements only [RFC4340], an incoming DCCP-Listen packet 664 would be ignored due to step 1 in [RFC4340], 8.1, which at the same 665 time also conforms to the behaviour specified by this document. 667 This document further does not modify communication for any DCCP 668 server that implements a passive-open without fully binding the 669 addresses, ports and Service Codes to be used. The authors therefore 670 do not expect practical deployment problems with existing conformant 671 DCCP implementations. 673 3. Discussion of Design Decisions 675 This is an informative section that reviews the rationale for the 676 design of this method. 678 3.1. Rationale for a New Packet Type 680 The DCCP-Listen packet specified in Section 2.2.1 has the same format 681 as the DCCP-Request packet ([RFC4340], 5.1), the only difference is 682 in the value of the Type field. The usage, however, differs. The 683 DCCP-Listen packet serves as an advisory message, not as part of the 684 actual connection setup: sequence numbers have no meaning, and no 685 payload can be communicated. 687 A DCCP-Request packet could in theory also have been used for the 688 same purpose. The following arguments were against this: 690 The first problem was that of semantic overloading: the DCCP-Request 691 defined in [RFC4340] serves a well-defined purpose, being the initial 692 packet of the 3-way handshake. Additional use in the manner of a 693 DCCP-Listen packet would have required DCCP processors to have had 694 two different processing paths: one where a DCCP-Request was 695 interpreted as part of the initial handshake, and another where the 696 same packet was interpreted as an indicator message. This would 697 complicate packet processing in hosts and in particular stateful 698 middleboxes (which may have restricted computational resources). 700 The second problem is that a client receiving a DCCP-Request from a 701 server could generate a DCCP-Reset packet if it had not yet entered 702 the REQUEST state (step 7 in [RFC4340], 8.5). The method specified 703 in this document lets client endpoints ignore DCCP-Listen packets. 704 Adding a similar rule for the DCCP-Request packet would have been 705 cumbersome: clients would not have been able to distinguish between a 706 Request meant to be an indicator message and a genuinely erratic 707 connection initiation. 709 The third problem is similar, and refers to a client receiving the 710 indication after having itself sent a (connection-initiation) DCCP- 711 Request. Step 7 in section 8.5 of [RFC4340] requires the client to 712 reply to an "indicator message" Request from the server with a DCCP- 713 Sync. Since sequence numbers are ignored for this type of message, 714 additional and complex processing would become necessary: either to 715 ask the client not to respond to a DCCP-Request when the request is 716 of type "indicator message"; or ask middleboxes and servers to ignore 717 Sync packets generated in response to "indicator message" DCCP- 718 Requests. Furthermore, since no initial sequence numbers have been 719 negotiated at this stage, sending a DCCP-SyncAck would not be 720 meaningful. 722 The use of a separate packet type therefore allows simpler and 723 clearer processing. 725 3.1.1. Use of sequence numbers 727 Although the DCCP-Listen sequence number fields are ignored, they 728 have been retained in the DCCP-Listen packet header to reuse the 729 generic header format from section 5.1 of [RFC4340]. 731 DCCP assigns a random initial value to the sequence number when a 732 DCCP connection is established [RFC4340]. However, a sender is 733 required to set this value to zero for a DCCP-Listen packet. Both 734 clients and middleboxes are also required to ignore this value. 736 The rationale for ignoring the sequence number fields of DCCP-Listen 737 packets is that at the time the DCCP-Listen is exchanged, the 738 endpoints have not yet entered connection setup: the DCCP-Listen 739 packet is sent while the server is still in the passive-open 740 (INVITED) state, i.e. it has not yet allocated state, other than 741 binding to the client's IP-address:port and Service Code. 743 3.2. Generation of Listen Packets 745 A DCCP server SHOULD by default permit generation of DCCP-Listen 746 packets. Since DCCP-Listen packets solve a particular problem with 747 NAT and/or firewall traversal, the generation of DCCP-Listen packets 748 on passive sockets is tied to a condition (binding to an a priori 749 known remote address and Service Code) to ensure this does not 750 interfere with the general case of "normal" DCCP connections (where 751 client addresses are generally not known in advance). 753 In the TCP world, the analogue is a transition from LISTEN to 754 SYN_SENT by virtue of sending data: "A fully specified passive call 755 can be made active by the subsequent execution of a SEND" ([RFC0793], 756 3.8). Unlike TCP, this update does not perform a role-change from 757 passive to active. Like TCP, DCCP-Listen packets are only sent by a 758 DCCP-server when the endpoint is fully specified (Section 2.2). 760 3.3. Repetition of DCCP-Listen Packets 762 Repetition is a necessary requirement, to increase robustness and the 763 chance of successful connection establishment when a DCCP-Listen 764 packet is lost due to congestion, link loss, or some other reason. 766 The decision to recommend a maximum number of 3 timeouts (2 repeated 767 copies of the original DCCP-Listen packet) results from the following 768 considerations: The repeated copies need to be spaced sufficiently 769 far apart in time to avoid suffering from correlated loss. The 770 interval of 200 ms was chosen to accommodate a wide range of wireless 771 and wired network paths. 773 Another constraint is given by the retransmission interval for the 774 DCCP-Request ([RFC4340], 8.1.1). To establish state, intermediate 775 systems need to receive a (retransmitted) DCCP-Listen packet before 776 the DCCP-Request times out (1 second). With three timeouts, each 777 spaced 200 milliseconds apart, the overall time is still below one 778 second. On the other hand, the sum of 600 milliseconds is 779 sufficiently large to provide for longer one-way delays, such as e.g. 780 found on some wireless links. 782 The rationale behind transitioning to the LISTEN1 state after two 783 repetitions is that other problems, independent of establishing 784 middlebox state, may occur (such as delay or loss of the initial 785 DCCP-Request). Any late or retransmitted DCCP-Request packets will 786 then still reach the server allowing connection establishment to 787 successfully complete. 789 4. Security Considerations 791 General security considerations for DCCP are described in [RFC4340]. 792 Security considerations for Service Codes are further described in 793 [ID-DCCP-SC]. 795 The method specified in this document generates a DCCP-Listen packet 796 addressed to a specific DCCP client. This exposes the state of a 797 DCCP server that is in a passive listening state (i.e. waiting to 798 accept a connection from a known client). 800 The exposed information is not encrypted and therefore could be seen 801 on the network path to the DCCP client. An attacker on this return 802 path could observe a DCCP-Listen packet and then exploit this by 803 spoofing a packet (e.g. DCCP-Request, DCCP-Reset) with the IP 804 addresses, DCCP ports, and Service Code that correspond to the values 805 to be used for the connection. As in other on-path attacks, this 806 could be used to inject data into a connection or to deny a 807 connection request. A similar on-path attack is also possible for 808 any DCCP connection, once the session is initiated by the client 809 ([RFC4340], Section 18). 811 The DCCP-Listen packet is only sent in response to explicit prior 812 out-of-band signaling from a DCCP client to the DCCP server (e.g. 813 SDP [RFC4566]) information communicated via the Session Initiation 814 Protocol [RFC3261]), and will normally directly precede a DCCP- 815 Request sent by the client (which carries the same information). 817 This update does not significantly increase the complexity or 818 vulnerability of a DCCP implementation that conforms to [RFC4340]. A 819 DCCP server should therefore by default permit generation of DCCP- 820 Listen packets. A server that wishes to prevent disclosing this 821 information MAY refrain from generating DCCP-Listen packets, without 822 impacting subsequent DCCP state transitions, but possibly inhibiting 823 middlebox traversal. 825 The DCCP base specification in RFC 4340 defines an Init Cookie 826 option, which lets a DCCP server avoid having to hold any state until 827 the three-way connection setup handshake has completed. This 828 specification enables an out-of-band mechanism that forces the server 829 to hold state for a connection that has not yet been established. 830 This is a change in the security profile of DCCP, although the impact 831 is expected to be minimal and depends on the security features of the 832 out-of-band mechanism (SIP SDP is one such mechanism that provides 833 sufficient security features). 835 The method creates a new way for a client to set up a DCCP connection 836 to a server using out-of-band data, transported over a signaling 837 connection. If the signaling connection is not encrypted, an 838 eavesdropper could see the client IP address and the port for the to- 839 be-established DCCP connection and generate a DCCP-Listen packet 840 towards the client using its own server-IP address and port. 841 However, a client will only respond to a received DCCP-Listen packet 842 if the server-IP address and port match an existing DCCP connection 843 that is in the REQUEST state (section 2.3.2). The method therefore 844 cannot be used to redirect the connection to a different server IP 845 address. 847 5. IANA Considerations 849 The IANA should register a new Packet Type, "DCCP-Listen", in the 850 IANA DCCP Packet Types Registry. The decimal value 10 has been 851 assigned to this type. This registry entry must reference this 852 document. 854 Note to the RFC Editor: 856 This value of 10 must be confirmed by IANA in the registry when this 857 document is published, please then remove this note. 859 Acknowledgement 861 This update was originally co-authored by Dr Gerrit Renker, 862 University of Aberdeen, and the present author acknowledges his 863 insight in design of the protocol mechanism and in careful review of 864 the early revisions of the document text. Dan Wing assisted on 865 issues relating to the use of NAT and NAPT. 867 6. Disclaimer 869 This document may contain material from IETF Documents or IETF 870 Contributions published or made publicly available before November 871 10, 2008. The person(s) controlling the copyright in some of this 872 material may not have granted the IETF Trust the right to allow 873 modifications of such material outside the IETF Standards Process. 874 Without obtaining an adequate license from the person(s) controlling 875 the copyright in such materials, this document may not be modified 876 outside the IETF Standards Process, and derivative works of it may 877 not be created outside the IETF Standards Process, except to format 878 it for publication as an RFC or to translate it into languages other 879 than English. 881 7. References 883 7.1. Normative References 885 [ID-DCCP-SC] 886 Fairhurst, G., "The DCCP Service Code", Work In 887 Progress, draft-ietf-dccp-serv-codes-09, June 2008. 889 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 890 Requirement Levels", March 1997. 892 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 893 Congestion Control Protocol (DCCP)", March 2006. 895 7.2. Informative References 897 [Epp05] Eppinger, J-L., "TCP Connections for P2P Apps: A Software 898 Approach to Solving the NAT Problem", Carnegie Mellon 899 University/ISRI Technical Report CMU-ISRI-05-104, 900 January 2005. 902 [FSK05] Ford, B., Srisuresh, P., and D. Kegel, "Peer-to-Peer 903 Communication Across Network Address Translators", 904 Proceedings of USENIX-05, pages 179-192, 2005. 906 [GF05] Guha, S. and P. Francis, "Characterization and Measurement 907 of TCP Traversal through NATs and Firewalls", Proceedings 908 of Internet Measurement Conference (IMC-05), pages 199- 909 211, 2005. 911 [GTF04] Guha, S., Takeda, Y., and P. Francis, "NUTSS: A SIP based 912 approach to UDP and TCP connectivity", Proceedings of 913 SIGCOMM-04 Workshops, Portland, OR, pages 43-48, 2004. 915 [H.323] ITU-T, "Packet-based Multimedia Communications Systems", 916 Recommendation H.323, July 2003. 918 [ID-BEHAVE-DCCP] 919 "Network Address Translation (NAT) Behavioral Requirements 920 for DCCP", Work in Progress draft-ietf-behave-dccp-05.txt, 921 2008. 923 [ID-BEHAVE-TURN] 924 Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using 925 Relays around NAT (TURN): Relay Extensions to Session 926 Traversal Utilities for NAT (STUN)", Work In 927 Progress, draft-ietf-behave-turn-14, February 2008. 929 [ID-MMUSIC-ICE] 930 Rosenberg, J., "TCP Candidates with Interactive 931 Connectivity Establishment (ICE)", Work In 932 Progress, draft-ietf-mmusic-ice-tcp-07, February 2008. 934 [NAT-APP] Ford, B., Srisuresh, P., and D. Kegel, "Application Design 935 Guidelines for Traversal through Network Address 936 Translators", Work In Progress, draft-ford-behave-app-05, 937 March 2007. 939 [RFC0793] Postel, J., "Transmission Control Protocol", 940 September 1981. 942 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 943 Translator (NAT) Terminology and Considerations", 944 August 1999. 946 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 947 Address Translator (Traditional NAT)", January 2001. 949 [RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly 950 Application Design Guidelines", January 2002. 952 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 953 A., Peterson, J., Sparks, R., Handley, M., and E. 954 Schooler, "SIP: Session Initiation Protocol", June 2002. 956 [RFC4566] "SDP: Session Description Protocol", July 2006. 958 [RFC4787] "Network Address Translation (NAT) Behavioral Requirements 959 for Unicast UDP", January 2007. 961 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 962 Srisuresh, "NAT Behavioral Requirements for TCP", 963 RFC5382, April 2007. 965 Appendix A. Discussion of Existing NAT Traversal Techniques 967 This appendix provides a brief review of existing techniques to 968 establish connectivity across NAT devices, with the aim of providing 969 background information. This first considers TCP NAT traversal based 970 on simultaneous-open, and then discuss a second technique based on 971 role reversal. Further information can be found in [GTF04] and 972 [GF05]. 974 A central idea shared by these techniques is to make peer-to-peer 975 sessions look like "outbound" sessions on each NAT device. Often a 976 rendezvous server, located in the public address realm, is used to 977 enable clients to discover their NAT topology and the addresses of 978 peers. 980 The term 'hole punching' was coined in [FSK05] and refers to creating 981 soft state in a traditional NAT device, by initiating an outbound 982 connection. A well-behaved NAT can subsequently exploit this to 983 allow a reverse connection back to the host in the private address 984 realm. 986 UDP and TCP hole punching use nearly the same technique [RFC4787]. 987 The adaptation of the basic UDP hole punching principle to TCP NAT 988 traversal [RFC5382] was introduced in section 4 of [FSK05] and relies 989 on the simultaneous-open feature of TCP [RFC0793]. A further 990 difference between UDP and TCP lies in the way the clients perform 991 connectivity checks, after obtaining suitable address pairs for 992 connection establishment. Whereas in UDP a single socket is 993 sufficient, TCP clients require several sockets for the same address 994 and port tuple: 996 o a passive socket to listen for connectivity tests from peers and 998 o multiple active connections from the same address to test 999 reachability of other peers. 1001 The SYN sent out by client A to its peer B creates soft state in A's 1002 NAT. At the same time, B tries to connect to A: 1004 o if the SYN from B has left B's NAT before the arrival of A's SYN, 1005 both endpoints perform simultaneous-open (4-way handshake of SYN/ 1006 SYNACK); 1008 o otherwise A's SYN may not enter B's NAT, which leads to B 1009 performing a normal open (SYN_SENT => ESTABLISHED) and A 1010 performing a simultaneous-open (SYN_SENT => SYN_RCVD => 1011 ESTABLISHED). 1013 In the latter case, it is necessary that the NAT does not interfere 1014 with a RST segment (REQ-4 in [RFC5382]). The simultaneous-open 1015 solution is convenient due to its simplicity, and is thus a preferred 1016 mode of operation in the TCP extension for ICE ([ID-MMUSIC-ICE], sec. 1017 2). 1019 A.1. NAT traversal Based on a Simultaneous-Request 1021 Among the various TCP NAT traversal approaches, the one using a TCP 1022 simultaneous-open suggests itself as a candidate for DCCP due to its 1023 simplicity [GF05], [NAT-APP]. 1025 A characteristic of TCP simultaneous-open is that this erases the 1026 clear distinction between client and server: both sides enter through 1027 active (SYN_SENT) as well as passive (SYN_RCVD) states. This 1028 characteristic conflicts with the DCCP design decision to provide a 1029 clear separation between client and server functions ([RFC4340], 1030 4.6). 1032 In DCCP several mechanisms implicitly rely on clearly-defined client/ 1033 server roles: 1035 o Feature Negotiation: with few exceptions, almost all of DCCP's 1036 negotiable features use the "server-priority" reconciliation rule 1037 ([RFC4340], 6.3.1), whereby a peer exchanges its preference lists 1038 of feature values, and the server decides the outcome. 1040 o Closing States: only a server may generate DCCP-CloseReq packets 1041 (asking the peer to hold timewait state), while a client is only 1042 permitted to send DCCP-Close or DCCP-Reset packets to terminate a 1043 connection ([RFC4340], 8.3). 1045 o Service Codes [ID-DCCP-SC]: a server may be associated with 1046 multiple Service Codes, while a client must be associated with 1047 exactly one ([RFC4340], 8.1.2). 1049 o Init Cookies: may only be used by a server and on DCCP-Response 1050 packets ([RFC4340], 8.1.4). 1052 The latter two points are not obstacles per se, but would have 1053 hindered the transition from a passive to an active socket. In DCCP, 1054 a DCCP-Request is only generated by a client. The assumption that 1055 "all DCCP hosts may be clients", was dismissed, since it would 1056 require undersirable changes to the state machine and would limit 1057 application programming. As a consequence, the retro-fitting a TCP- 1058 style simultaneous-open into DCCP to allow simulatenous exchange of 1059 DCCP-Connect packets was not recommended. 1061 A.2. Role Reversal 1063 Another simple TCP NAT traversal scheme uses role traversal ([Epp05] 1064 and [GTF04]), where a peer first opens an active connection for the 1065 single purpose of punching a hole in the firewall; and then reverts 1066 to a listening socket, accepting connections arriving via the new 1067 path. 1069 This solution would have had several disadvantages if used with DCCP. 1070 First, a DCCP server would be required to change its role to 1071 temporarily become a 'client'. This would have required modification 1072 to the state machine, in particular the treatment of Service Codes 1073 and perhaps Init Cookies. Further, the method must follow feature 1074 negotiation, since an endpoint's choice of initial options can rely 1075 on its role (i.e. if an endpoint knows it is the server, it can make 1076 a priori assumptions about the preference lists of features it is 1077 negotiating with the client, thereby enforcing a particular policy). 1078 Finally, the server would have needed additional processing to ensure 1079 that the connection arriving at the listening socket matches the 1080 previously opened active connection. 1082 This approach was therefore not recommend for DCCP. 1084 Appendix B. Change Log - to be removed by RFC-Ed 1086 Revision 00 was based on a previous individual submission 1087 draft-fairhurst-dccp-behave-update-01 by the same authors. 1089 Revision 01: 1091 o introduced many format changes to improve readability 1093 o migrated background information into the Appendix 1095 o added Section 1.3 to summarize the document structure 1097 o updated introductory paragraph of Section 2 to account for new 1098 structure 1100 o added captions to all figures 1102 o updated the specification in Section 2 to (i) permit on DCCP- 1103 Listen packets; (ii) explain why the presence of payload data is 1104 not useful; (iii) clarify that middleboxes must not interpret 1105 sequence numbers on DCCP-Listen packets 1107 o clarified that the default value of the Allow Short Seqno feature 1108 is to be used 1110 o added references to the Service Code draft [ID-DCCP-SC] 1112 o clarified the processing of DCCP-Listen packets by server 1113 endpoints 1115 o corrected the reaction of a client implementing [RFC4340] only - 1116 DCCP-Listen packets are treated as unknown and hence do not 1117 generate a DCCP-Reset 1119 o swapped order of IANA / Security-Considerations sections 1121 o added a note in the Security Considerations section that servers 1122 may refrain from generating DCCP-Listen packets 1124 Revision 02: 1126 o minor edits following WG feedback at IETF meeting 1128 o updated to reflect ID.Behave-DCCP 1130 o update to reflect comments from Colin Perkins 1131 o added a tentative IANA code point (as suggested at IETF-73) 1133 o DRAFT -02 1135 o Edits following editorial corrections and suggestions from Tom 1136 Phelan 1138 o Edits following comments from Dan Wing on role of NAT, 1139 retransmission, and other issues. 1141 o Revised authors list 1143 o Reworded abstract, reworded appendices to clarify what was not 1144 done 1146 o Checked spelling 1148 o Although this version includes significant changes to format and 1149 text it does not seek to modify the intended procedure for a 1150 server. 1152 o 1154 o DRAFT - 03 1156 o Comments by Dan Wing 1158 o DRAFT -04 1160 o Corrections by Dan Wing, and new diagram Figure 5 to and text to 1161 clarify the retransmission algorithm. 1163 o DRAFT -05 1165 o Sections re-ordered to bring the packet type definition to the 1166 front, and to correct a section mis-order in draft-04. References 1167 linked to IETF WGs and updated to satisfy IDNiTs. 1169 o A number of Typos were fixed. 1171 o DRAFT -06 1173 o This draft follows a completed WGLC. 1175 o It includes responses to comments from Eddie Kohler, during WGLC. 1177 o Magnus Westerlund requested two updates: 1179 o A triggered join, based on reception of a DCCP-Listen causing a 1180 retransmission of a DCCP-Request. 1182 o Updated figure 5. 1184 o Updated language to differentiate the loss-prevention DCCP-Listen 1185 repetition being confused with the DCCP-Request retransmission. 1187 o Added pseudocode and redrew state diagram, to match the 1188 pseudocode, including a transitory state transition to the 1189 LISTEN1state to process the received DCCP-Request. This is 1190 intended to be the same processing as in draft -05, even though 1191 the diagram now looks less pretty, and another state was created. 1193 o This version circulated in draft form to WG on 29/11/08 - no 1194 additional comments received. 1196 o Updated references. 1198 o 1200 o DRAFT -07 1202 o Fixed Section heading (missing in rev -06) 1204 o Updated figure with a note to clarify the Response (from Magnus 1205 Westerlund). 1207 o Editorial corrections proposed by T.Phelan. 1209 o 1211 o DRAFT -08 1213 o Fixed text in response to Sec-Dir review (Chris Newman) and GEN- 1214 ART review (Miguel A. Garcia) 1216 o SC draft made normative (draft currently with IESG) 1218 o Listen' changed to LISTEN1 in all places - to make this label 1219 clearer in the text 1221 o Security considerations updated 1223 o Addressed editorial comments received during LC. 1225 Author's Address 1227 Godred Fairhurst 1228 University of Aberdeen 1229 School of Engineering 1230 Fraser Noble Building 1231 Aberdeen AB24 3UE 1232 Scotland 1234 Email: gorry@erg.abdn.ac.uk 1235 URI: http://www.erg.abdn.ac.uk