idnits 2.17.1 draft-ietf-dccp-spec-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 5737. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 5748. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 5755. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 5761. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 5729), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 40. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1822 has weird spacing: '...t value snd...' == Line 2381 has weird spacing: '...loseReq seq...' == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (25 October 2004) is 7122 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) == Missing Reference: 'CLOSED' is mentioned on line 838, but not defined == Missing Reference: 'LISTEN' is mentioned on line 838, but not defined == Missing Reference: 'TIMEWAIT' is mentioned on line 847, but not defined == Missing Reference: 'Nonce 0' is mentioned on line 4504, but not defined == Missing Reference: 'Nonce 1' is mentioned on line 4504, but not defined == Missing Reference: 'AWL' is mentioned on line 2344, but not defined == Missing Reference: 'AWH' is mentioned on line 2344, but not defined == Missing Reference: 'SWL' is mentioned on line 2344, but not defined == Missing Reference: 'SWH' is mentioned on line 2344, but not defined == Missing Reference: 'RFC TBA' is mentioned on line 3548, but not defined == Missing Reference: 'DrpCd' is mentioned on line 4262, but not defined == Missing Reference: 'E' is mentioned on line 5250, but not defined -- Looks like a reference, but probably isn't: '1' on line 5461 -- Looks like a reference, but probably isn't: '0' on line 5444 == Unused Reference: 'RFC 2960' is defined on line 5670, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3309 (Obsoleted by RFC 4960) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-11) exists of draft-ietf-pmtud-method-01 -- Obsolete informational reference (is this intentional?): RFC 1750 (Obsoleted by RFC 4086) -- Obsolete informational reference (is this intentional?): RFC 1948 (Obsoleted by RFC 6528) -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2581 (Obsoleted by RFC 5681) -- Obsolete informational reference (is this intentional?): RFC 2960 (Obsoleted by RFC 4960) -- Obsolete informational reference (is this intentional?): RFC 3448 (Obsoleted by RFC 5348) Summary: 11 errors (**), 0 flaws (~~), 19 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Eddie Kohler 2 INTERNET-DRAFT UCLA 3 draft-ietf-dccp-spec-08.txt Mark Handley 4 Expires: 25 April 2005 UCL 5 Sally Floyd 6 ICIR 7 25 October 2004 9 Datagram Congestion Control Protocol (DCCP) 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as 28 reference material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on 25 April 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). All Rights Reserved. 42 Abstract 44 The Datagram Congestion Control Protocol (DCCP) is a transport 45 protocol that provides bidirectional unicast connections of 46 congestion-controlled unreliable datagrams. DCCP is suitable for 47 applications that transfer fairly large amounts of data, but can 48 benefit from control over the tradeoff between timeliness and 49 reliability. 51 TO BE DELETED BY THE RFC EDITOR UPON PUBLICATION: 53 Changes since draft-ietf-dccp-spec-07.txt: 55 * Many changes, not listed here, for WGLC. 57 * The more stringent Sequence Number checks on DCCP-Sync and DCCP- 58 SyncAck packets become SHOULD, not MAY. 60 Changes since draft-ietf-dccp-spec-06.txt: 62 * Change extended sequence numbers. Now 48-bit sequence numbers are 63 MANDATORY, and all packet types except Data, Ack, and DataAck always 64 use 48-bit sequence numbers. This change improves DCCP's robustness 65 against blind attacks. 67 * Removed empty Change options. 69 * Allow preference list changes during feature negotiations (this 70 seems easier to implement than the alternative). This required a 71 new feature negotiation state, UNSTABLE. 73 * Add Minimum Checksum Coverage feature. 75 * Add Reset Congestion State option. 77 * Simplify the implementation of CCID-specific option processing: no 78 need to check whether the CCID feature is being negotiated. 80 * Many more minor changes. 82 Changes since draft-ietf-dccp-spec-05.txt: 84 * Organization overhaul. 86 * Add pseudocode for event processing. 88 * Remove # NDP; replace with Ack Count. 90 * Remove Identification, Challenge, ID Regime, and Connection Nonce. 92 * Data Checksum (formerly Payload Checksum) uses a 32-bit CRC. 94 * Switch location of non-negotiable features to clarify 95 presentation; now the feature location controls its value. 97 * Rename "value type" to "reconciliation rule". 99 * Rename "Reset Reason" to "Reset Code". 101 * Mobility ID becomes 128 bits long. 103 * Add probabilities to Mobility ID discussion. 105 * Add SyncAck. 107 Table of Contents 109 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 10 110 2. Design Rationale. . . . . . . . . . . . . . . . . . . . . . . 11 111 3. Conventions and Terminology . . . . . . . . . . . . . . . . . 12 112 3.1. Numbers and Fields . . . . . . . . . . . . . . . . . . . 12 113 3.2. Parts of a Connection. . . . . . . . . . . . . . . . . . 13 114 3.3. Features . . . . . . . . . . . . . . . . . . . . . . . . 13 115 3.4. Round-Trip Times . . . . . . . . . . . . . . . . . . . . 14 116 3.5. Security Limitation. . . . . . . . . . . . . . . . . . . 14 117 3.6. Robustness Principle . . . . . . . . . . . . . . . . . . 14 118 4. Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . 14 119 4.1. Packet Types . . . . . . . . . . . . . . . . . . . . . . 15 120 4.2. Sequence Numbers . . . . . . . . . . . . . . . . . . . . 16 121 4.3. States . . . . . . . . . . . . . . . . . . . . . . . . . 17 122 4.4. Congestion Control . . . . . . . . . . . . . . . . . . . 19 123 4.5. Features . . . . . . . . . . . . . . . . . . . . . . . . 19 124 4.6. Differences From TCP . . . . . . . . . . . . . . . . . . 20 125 4.7. Example Connection . . . . . . . . . . . . . . . . . . . 21 126 5. Packet Formats. . . . . . . . . . . . . . . . . . . . . . . . 23 127 5.1. Generic Header . . . . . . . . . . . . . . . . . . . . . 23 128 5.2. DCCP-Request Packets . . . . . . . . . . . . . . . . . . 27 129 5.3. DCCP-Response Packets. . . . . . . . . . . . . . . . . . 28 130 5.4. DCCP-Data, DCCP-Ack, and DCCP-DataAck Packets. . . . . . 28 131 5.5. DCCP-CloseReq and DCCP-Close Packets . . . . . . . . . . 30 132 5.6. DCCP-Reset Packets . . . . . . . . . . . . . . . . . . . 30 133 5.7. DCCP-Sync and DCCP-SyncAck Packets . . . . . . . . . . . 33 134 5.8. Options. . . . . . . . . . . . . . . . . . . . . . . . . 34 135 5.8.1. Padding Option. . . . . . . . . . . . . . . . . . . 36 136 5.8.2. Mandatory Option. . . . . . . . . . . . . . . . . . 36 137 6. Feature Negotiation . . . . . . . . . . . . . . . . . . . . . 37 138 6.1. Change Options . . . . . . . . . . . . . . . . . . . . . 37 139 6.2. Confirm Options. . . . . . . . . . . . . . . . . . . . . 38 140 6.3. Reconciliation Rules . . . . . . . . . . . . . . . . . . 38 141 6.3.1. Server-Priority . . . . . . . . . . . . . . . . . . 38 142 6.3.2. Non-Negotiable. . . . . . . . . . . . . . . . . . . 39 143 6.4. Feature Numbers. . . . . . . . . . . . . . . . . . . . . 39 144 6.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . 40 145 6.6. Option Exchange. . . . . . . . . . . . . . . . . . . . . 41 146 6.6.1. Normal Exchange . . . . . . . . . . . . . . . . . . 42 147 6.6.2. Processing Received Options . . . . . . . . . . . . 42 148 6.6.3. Loss and Retransmission . . . . . . . . . . . . . . 44 149 6.6.4. Reordering. . . . . . . . . . . . . . . . . . . . . 45 150 6.6.5. Preference Changes. . . . . . . . . . . . . . . . . 46 151 6.6.6. Simultaneous Negotiation. . . . . . . . . . . . . . 46 152 6.6.7. Unknown Features. . . . . . . . . . . . . . . . . . 46 153 6.6.8. Invalid Options . . . . . . . . . . . . . . . . . . 47 154 6.6.9. Mandatory Feature Negotiation . . . . . . . . . . . 48 156 7. Sequence Numbers. . . . . . . . . . . . . . . . . . . . . . . 48 157 7.1. Variables. . . . . . . . . . . . . . . . . . . . . . . . 49 158 7.2. Initial Sequence Numbers . . . . . . . . . . . . . . . . 49 159 7.3. Quiet Time . . . . . . . . . . . . . . . . . . . . . . . 50 160 7.4. Acknowledgement Numbers. . . . . . . . . . . . . . . . . 51 161 7.5. Validity and Synchronization . . . . . . . . . . . . . . 51 162 7.5.1. Sequence and Acknowledgement Number 163 Windows. . . . . . . . . . . . . . . . . . . . . . . . . . 52 164 7.5.2. Sequence Window Feature . . . . . . . . . . . . . . 53 165 7.5.3. Sequence-Validity Rules . . . . . . . . . . . . . . 53 166 7.5.4. Handling Sequence-Invalid Packets . . . . . . . . . 55 167 7.5.5. Sequence Number Attacks . . . . . . . . . . . . . . 56 168 7.5.6. Examples. . . . . . . . . . . . . . . . . . . . . . 57 169 7.6. Short Sequence Numbers . . . . . . . . . . . . . . . . . 58 170 7.6.1. Allow Short Sequence Numbers Feature. . . . . . . . 59 171 7.6.2. When to Avoid Short Sequence Numbers. . . . . . . . 59 172 7.7. NDP Count and Detecting Application Loss . . . . . . . . 60 173 7.7.1. Usage Notes . . . . . . . . . . . . . . . . . . . . 61 174 7.7.2. Send NDP Count Feature. . . . . . . . . . . . . . . 61 175 8. Event Processing. . . . . . . . . . . . . . . . . . . . . . . 61 176 8.1. Connection Establishment . . . . . . . . . . . . . . . . 62 177 8.1.1. Client Request. . . . . . . . . . . . . . . . . . . 62 178 8.1.2. Service Codes . . . . . . . . . . . . . . . . . . . 63 179 8.1.3. Server Response . . . . . . . . . . . . . . . . . . 64 180 8.1.4. Init Cookie Option. . . . . . . . . . . . . . . . . 65 181 8.1.5. Handshake Completion. . . . . . . . . . . . . . . . 66 182 8.2. Data Transfer. . . . . . . . . . . . . . . . . . . . . . 66 183 8.3. Termination. . . . . . . . . . . . . . . . . . . . . . . 67 184 8.3.1. Abnormal Termination. . . . . . . . . . . . . . . . 69 185 8.4. DCCP State Diagram . . . . . . . . . . . . . . . . . . . 69 186 8.5. Pseudocode . . . . . . . . . . . . . . . . . . . . . . . 70 187 9. Checksums . . . . . . . . . . . . . . . . . . . . . . . . . . 74 188 9.1. Header Checksum Field. . . . . . . . . . . . . . . . . . 75 189 9.2. Header Checksum Coverage Field . . . . . . . . . . . . . 76 190 9.2.1. Minimum Checksum Coverage Feature . . . . . . . . . 77 191 9.3. Data Checksum Option . . . . . . . . . . . . . . . . . . 77 192 9.3.1. Check Data Checksum Feature . . . . . . . . . . . . 78 193 9.3.2. Usage Notes . . . . . . . . . . . . . . . . . . . . 78 194 10. Congestion Control . . . . . . . . . . . . . . . . . . . . . 79 195 10.1. TCP-like Congestion Control . . . . . . . . . . . . . . 80 196 10.2. TFRC Congestion Control . . . . . . . . . . . . . . . . 80 197 10.3. CCID-Specific Options, Features, and Reset 198 Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 199 10.4. CCID Profile Requirements . . . . . . . . . . . . . . . 83 200 10.5. Congestion State. . . . . . . . . . . . . . . . . . . . 83 201 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 84 202 11.1. Acks of Acks and Unidirectional Connections . . . . . . 84 203 11.2. Ack Piggybacking. . . . . . . . . . . . . . . . . . . . 86 204 11.3. Ack Ratio Feature . . . . . . . . . . . . . . . . . . . 86 205 11.4. Ack Vector Options. . . . . . . . . . . . . . . . . . . 88 206 11.4.1. Ack Vector Consistency . . . . . . . . . . . . . . 90 207 11.4.2. Ack Vector Coverage. . . . . . . . . . . . . . . . 92 208 11.5. Send Ack Vector Feature . . . . . . . . . . . . . . . . 92 209 11.6. Slow Receiver Option. . . . . . . . . . . . . . . . . . 93 210 11.7. Data Dropped Option . . . . . . . . . . . . . . . . . . 93 211 11.7.1. Data Dropped and Normal Congestion 212 Response . . . . . . . . . . . . . . . . . . . . . . . . . 96 213 11.7.2. Particular Drop Codes. . . . . . . . . . . . . . . 97 214 12. Explicit Congestion Notification . . . . . . . . . . . . . . 98 215 12.1. ECN Incapable Feature . . . . . . . . . . . . . . . . . 98 216 12.2. ECN Nonces. . . . . . . . . . . . . . . . . . . . . . . 99 217 12.3. Other Aggression Penalties. . . . . . . . . . . . . . . 100 218 13. Timing Options . . . . . . . . . . . . . . . . . . . . . . . 100 219 13.1. Timestamp Option. . . . . . . . . . . . . . . . . . . . 101 220 13.2. Elapsed Time Option . . . . . . . . . . . . . . . . . . 101 221 13.3. Timestamp Echo Option . . . . . . . . . . . . . . . . . 102 222 14. Maximum Packet Size. . . . . . . . . . . . . . . . . . . . . 103 223 14.1. Measuring PMTU. . . . . . . . . . . . . . . . . . . . . 104 224 14.2. Sender Behavior . . . . . . . . . . . . . . . . . . . . 105 225 15. Forward Compatibility. . . . . . . . . . . . . . . . . . . . 106 226 16. Middlebox Considerations . . . . . . . . . . . . . . . . . . 107 227 17. Relations to Other Specifications. . . . . . . . . . . . . . 108 228 17.1. RTP . . . . . . . . . . . . . . . . . . . . . . . . . . 108 229 17.2. Congestion Manager and Multiplexing . . . . . . . . . . 109 230 18. Security Considerations. . . . . . . . . . . . . . . . . . . 110 231 18.1. Security Considerations for Partial 232 Checksums . . . . . . . . . . . . . . . . . . . . . . . . . . 110 233 19. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 111 234 19.1. Packet Types. . . . . . . . . . . . . . . . . . . . . . 111 235 19.2. Reset Codes . . . . . . . . . . . . . . . . . . . . . . 111 236 19.3. Option Types. . . . . . . . . . . . . . . . . . . . . . 112 237 19.4. Feature Numbers . . . . . . . . . . . . . . . . . . . . 112 238 19.5. Congestion Control Identifiers. . . . . . . . . . . . . 112 239 19.6. Ack Vector States . . . . . . . . . . . . . . . . . . . 113 240 19.7. Drop Codes. . . . . . . . . . . . . . . . . . . . . . . 113 241 19.8. Service Codes . . . . . . . . . . . . . . . . . . . . . 113 242 20. Thanks . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 243 A. Appendix: Ack Vector Implementation Notes . . . . . . . . . . 114 244 A.1. Packet Arrival . . . . . . . . . . . . . . . . . . . . . 116 245 A.1.1. New Packets . . . . . . . . . . . . . . . . . . . . 116 246 A.1.2. Old Packets . . . . . . . . . . . . . . . . . . . . 117 247 A.2. Sending Acknowledgements . . . . . . . . . . . . . . . . 118 248 A.3. Clearing State . . . . . . . . . . . . . . . . . . . . . 119 249 A.4. Processing Acknowledgements. . . . . . . . . . . . . . . 120 250 B. Appendix: Design Motivation . . . . . . . . . . . . . . . . . 121 251 B.1. CsCov and Partial Checksumming . . . . . . . . . . . . . 121 253 Normative References . . . . . . . . . . . . . . . . . . . . . . 122 254 Informative References . . . . . . . . . . . . . . . . . . . . . 123 255 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 125 256 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 125 257 Intellectual Property. . . . . . . . . . . . . . . . . . . . . . 125 258 List of Tables 260 Table 1: DCCP Packet Types . . . . . . . . . . . . . . . . . . . 25 261 Table 2: DCCP Reset Codes. . . . . . . . . . . . . . . . . . . . 33 262 Table 3: DCCP Options. . . . . . . . . . . . . . . . . . . . . . 35 263 Table 4: DCCP Feature Numbers. . . . . . . . . . . . . . . . . . 39 264 Table 5: DCCP Congestion Control Identifiers . . . . . . . . . . 79 265 Table 6: DCCP Ack Vector States. . . . . . . . . . . . . . . . . 88 266 Table 7: DCCP Drop Codes . . . . . . . . . . . . . . . . . . . . 95 268 1. Introduction 270 The Datagram Congestion Control Protocol (DCCP) is a transport 271 protocol that implements bidirectional, unicast connections of 272 congestion-controlled, unreliable datagrams. Specifically, DCCP 273 provides: 275 o Unreliable flows of datagrams, with acknowledgements. 277 o Reliable handshakes for connection setup and teardown. 279 o Reliable negotiation of options, including negotiation of a 280 suitable congestion control mechanism. 282 o Mechanisms allowing servers to avoid holding state for 283 unacknowledged connection attempts and already-finished 284 connections. 286 o Congestion control incorporating Explicit Congestion Notification 287 (ECN) and the ECN Nonce, as per [RFC 3168] and [RFC 3540]. 289 o Acknowledgement mechanisms communicating packet loss and ECN 290 information. Acks are transmitted as reliably as the relevant 291 congestion control mechanism requires, possibly completely 292 reliably. 294 o Optional mechanisms that tell the sending application, with high 295 reliability, which data packets reached the receiver, and whether 296 those packets were ECN marked, corrupted, or dropped in the 297 receive buffer. 299 o Path Maximum Transmission Unit (PMTU) discovery, as per [RFC 300 1191]. 302 o A choice of modular congestion control mechanisms. Two 303 mechanisms are currently specified, TCP-like Congestion Control 304 [CCID 2 PROFILE] and TFRC (TCP-Friendly Rate Control) Congestion 305 Control [CCID 3 PROFILE], but DCCP is easily extensible to 306 further forms of unicast congestion control. 308 DCCP is intended for applications that can benefit from control over 309 the tradeoffs between delay and reliable in-order delivery. Such 310 applications include streaming media and Internet telephony. TCP is 311 not well-suited for these applications, since reliable in-order 312 delivery and congestion control can cause arbitrarily long delays. 313 UDP avoids long delays, but UDP applications that implement 314 congestion control must do so on their own. DCCP provides built-in 315 congestion control, including ECN support, for unreliable datagram 316 flows, avoiding the arbitrary delays associated with TCP. It also 317 implements reliable connection setup, teardown, and feature 318 negotiation. 320 2. Design Rationale 322 One DCCP design goal was to give most streaming UDP applications 323 little reason not to switch to DCCP, once it is deployed. To 324 facilitate this, DCCP was designed to have as little overhead as 325 possible, both in terms of the packet header size and in terms of 326 the state and CPU overhead required at end hosts. Only the minimal 327 necessary functionality was included in DCCP, leaving other 328 functionality, such as forward error correction (FEC), semi- 329 reliability, and multiple streams, to be layered on top of DCCP as 330 desired. 332 Different forms of conformant congestion control are appropriate for 333 different applications. For example, on-line games might want to 334 make quick use of any available bandwidth, while streaming media 335 might trade off this responsiveness for a steadier, less bursty 336 rate. (Sudden rate changes can cause unacceptable UI glitches, such 337 as audible pauses or clicks in the playout stream.) DCCP thus 338 allows applications to choose from a set of congestion control 339 mechanisms. One alternative, TCP-like Congestion Control, halves 340 the congestion window in response to a packet drop or mark, as in 341 TCP. Applications using this congestion control mechanism will 342 respond quickly to changes in available bandwidth, but must tolerate 343 the abrupt changes in congestion window typical of TCP. A second 344 alternative, TCP-Friendly Rate Control (TFRC, [RFC 3448]), a form of 345 equation-based congestion control, minimizes abrupt changes in the 346 sending rate while maintaining longer-term fairness with TCP. Other 347 alternatives can be added as future congestion control mechanisms 348 are standardized. 350 DCCP also lets unreliable traffic safely use ECN. A UDP kernel API 351 might not allow applications to set UDP packets as ECN-capable, 352 since the API could not guarantee the application would properly 353 detect or respond to congestion. DCCP kernel APIs will have no such 354 issues, since DCCP implements congestion control itself. 356 We chose not to require the use of the Congestion Manager [RFC 357 3124], which allows multiple concurrent streams between the same 358 sender and receiver to share congestion control. The current 359 Congestion Manager can only be used by applications that have their 360 own end-to-end feedback about packet losses, but this is not the 361 case for many of the applications currently using UDP. In addition, 362 the current Congestion Manager does not easily support multiple 363 congestion control mechanisms, or lend itself to the use of forms of 364 TFRC where the state about past packet drops or marks is maintained 365 at the receiver rather than at the sender. DCCP should be able to 366 make use of CM where desired by the application, but we do not see 367 any benefit in making the deployment of DCCP contingent on the 368 deployment of CM itself. 370 We intend for DCCP's protocol mechanisms, which are described in 371 this document, to suit any application desiring unicast congestion- 372 controlled streams of unreliable datagrams. The congestion control 373 mechanisms currently approved for use with DCCP, which are described 374 in separate Congestion Control ID Profiles [CCID 2 PROFILE] [CCID 3 375 PROFILE], may, however, cause problems for some applications, 376 including high-bandwidth interactive video. These applications 377 should be able to use DCCP once suitable Congestion Control ID 378 Profiles are standardized. 380 3. Conventions and Terminology 382 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 383 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 384 this document are to be interpreted as described in [RFC 2119]. 386 3.1. Numbers and Fields 388 All multi-byte numerical quantities in DCCP, such as port numbers, 389 Sequence Numbers, and arguments to options, are transmitted in 390 network byte order (most significant byte first). 392 We occasionally refer to the "left" and "right" sides of a bit 393 field. "Left" means towards the most significant bit, and "right" 394 means towards the least significant bit. 396 Random numbers in DCCP are used for their security properties, and 397 SHOULD be chosen according to the guidelines in [RFC 1750]. 399 All operations on DCCP sequence numbers, and comparisons such as 400 "greater" and "greatest", use circular arithmetic modulo 2**48. 401 This form of arithmetic preserves the relationships between sequence 402 numbers as they roll over from 2**48 - 1 to 0. We note that the 403 two's-complement trick for implementing circular comparison -- 404 namely, A < B in the circular comparison sense if and only if 405 (A - B) < 0 in the conventional arithmetic sense -- applies directly 406 to DCCP sequence numbers, as long as they are stored in the most 407 significant 48 bits of 64-bit integers. 409 Reserved bitfields in DCCP packet headers MUST be set to zero by 410 senders, and MUST be ignored by receivers, unless otherwise 411 specified. This is to allow for future protocol extensions. In 412 particular, DCCP processors MUST NOT reset a DCCP connection simply 413 because a Reserved field has non-zero value [RFC 3360]. 415 3.2. Parts of a Connection 417 Each DCCP connection runs between two hosts, which we often name 418 DCCP A and DCCP B. Each connection is actively initiated by one of 419 the hosts, which we call the client; the other, initially passive 420 host is called the server. The term "DCCP endpoint" is used to 421 refer to either of the two hosts explicitly named by the connection 422 (the client and the server). The term "DCCP processor" refers more 423 generally to any host that might need to process a DCCP header; this 424 includes the endpoints and any middleboxes on the path, such as 425 firewalls and network address translators. 427 DCCP connections are bidirectional: data may pass from either 428 endpoint to the other. This means that data and acknowledgements 429 may be flowing in both directions simultaneously. Logically, 430 however, a DCCP connection consists of two separate unidirectional 431 connections, called half-connections. Each half-connection consists 432 of the application data sent by one endpoint and the corresponding 433 acknowledgements sent by the other endpoint. We can illustrate this 434 as follows: 436 +--------+ A-to-B half-connection: +--------+ 437 | | --> application data --> | | 438 | | <-- acknowledgements <-- | | 439 | DCCP A | | DCCP B | 440 | | B-to-A half-connection: | | 441 | | <-- application data <-- | | 442 +--------+ --> acknowledgements --> +--------+ 444 Although they are logically distinct, in practice the half- 445 connections overlap; a DCCP-DataAck packet, for example, contains 446 application data relevant to one half-connection and acknowledgement 447 information relevant to the other. 449 In the context of a single half-connection, the terms "HC-Sender" 450 and "HC-Receiver" denote the endpoints sending application data and 451 acknowledgements, respectively. For example, DCCP A is the HC- 452 Sender and DCCP B is the HC-Receiver in the A-to-B half-connection. 454 3.3. Features 456 A DCCP feature is a connection attribute on whose value the two 457 endpoints agree. Many properties of a DCCP connection are 458 controlled by features, including the congestion control mechanisms 459 in use on the two half-connections. The endpoints achieve agreement 460 through the exchange of feature negotiation options in DCCP headers. 462 DCCP features are identified by a feature number and an endpoint. 463 The notation "F/X" represents the feature with feature number F 464 located at DCCP endpoint X. Each valid feature number thus 465 corresponds to two features, which are negotiated separately and 466 need not have the same value. The two endpoints know, and agree on, 467 the value of every valid feature. DCCP A is the "feature location" 468 for all features F/A, and the "feature remote" for all features F/B. 470 3.4. Round-Trip Times 472 DCCP round-trip time measurements are performed by congestion 473 control mechanisms; different mechanisms may measure round-trip time 474 in different ways, or not measure it at all. However, the main DCCP 475 protocol does use round-trip times occasionally, such as in the 476 initial values for certain timers. Each DCCP implementation thus 477 defines a default round-trip time for use when no estimate is 478 available; this parameter should default to not less than 479 0.2 seconds, a reasonable median round-trip time for Internet TCP 480 connections. Protocol behavior specified in terms of "round-trip 481 time" values actually refers to "a current round-trip time estimate 482 taken by some CCID, or, if no estimate is available, the default 483 round-trip time parameter". 485 The maximum segment lifetime, or MSL, is the maximum length of time 486 a packet can survive in the network. The DCCP MSL should equal that 487 of TCP, which is normally two minutes. 489 3.5. Security Limitation 491 DCCP provides no protection against attackers who can snoop on a 492 connection in progress, or who can guess valid sequence numbers in 493 other ways. Applications desiring stronger security should use 494 IPsec [RFC 2401]; depending on the level of security required, 495 application-level cryptography may also suffice. These issues are 496 discussed further in Sections 18 and 7.5.5. 498 3.6. Robustness Principle 500 DCCP implementations will follow TCP's "general principle of 501 robustness": "be conservative in what you do, be liberal in what you 502 accept from others" [RFC 793]. 504 4. Overview 506 DCCP's high-level connection dynamics echo those of TCP. 507 Connections progress through three phases: initiation, including a 508 three-way handshake; data transfer; and termination. Data can flow 509 both ways over the connection. An acknowledgement framework lets 510 senders discover how much data has been lost, and thus avoid 511 unfairly congesting the network. Of course, DCCP provides 512 unreliable datagram semantics, not TCP's reliable bytestream 513 semantics. The application must package its data into explicit 514 frames, and must retransmit its own data as necessary. It may be 515 useful to think of DCCP as TCP minus bytestream semantics and 516 reliability, or as UDP plus congestion control, handshakes, and 517 acknowledgements. 519 4.1. Packet Types 521 Ten packet types implement DCCP's protocol functions. For example, 522 every new connection attempt begins with a DCCP-Request packet sent 523 by the client. A DCCP-Request packet thus resembles a TCP SYN; but 524 DCCP-Request is a packet type, not a flag, so there's no way to send 525 an unexpected combination such as TCP's SYN+FIN+ACK+RST. 527 Eight packet types occur during the progress of a typical 528 connection, shown here. Note the three-way handshakes during 529 initiation and termination. 531 Client Server 532 ------ ------ 533 (1) Initiation 534 DCCP-Request --> 535 <-- DCCP-Response 536 DCCP-Ack --> 537 (2) Data transfer 538 DCCP-Data, DCCP-Ack, DCCP-DataAck --> 539 <-- DCCP-Data, DCCP-Ack, DCCP-DataAck 540 (3) Termination 541 <-- DCCP-CloseReq 542 DCCP-Close --> 543 <-- DCCP-Reset 545 The two remaining packet types are used to resynchronize after 546 bursts of loss. 548 Every DCCP packet starts with a 12-byte generic header. Particular 549 packet types include additional fixed-size header data; for example, 550 DCCP-Acks include an Acknowledgement Number. DCCP options and any 551 application data follow the fixed-size header. 553 The packet types are as follows: 555 DCCP-Request 556 Sent by the client to initiate a connection (the first part of 557 the three-way initiation handshake). 559 DCCP-Response 560 Sent by the server in response to a DCCP-Request (the second 561 part of the three-way initiation handshake). 563 DCCP-Data 564 Used to transmit application data. 566 DCCP-Ack 567 Used to transmit pure acknowledgements. 569 DCCP-DataAck 570 Used to transmit application data with piggybacked 571 acknowledgements. 573 DCCP-CloseReq 574 Sent by the server to request that the client close the 575 connection. 577 DCCP-Close 578 Used by the client or the server to close the connection; 579 elicits a DCCP-Reset in response. 581 DCCP-Reset 582 Used to terminate the connection, either normally or abnormally. 584 DCCP-Sync, DCCP-SyncAck 585 Used to resynchronize sequence numbers after large bursts of 586 loss. 588 4.2. Sequence Numbers 590 Each DCCP packet carries a sequence number, so that losses can be 591 detected and reported. Unlike TCP sequence numbers, which are byte- 592 based, DCCP sequence numbers increment by one per packet. For 593 example: 595 DCCP A DCCP B 596 ------ ------ 597 DCCP-Data(seqno 1) --> 598 DCCP-Data(seqno 2) --> 599 <-- DCCP-Ack(seqno 10, ackno 2) 600 DCCP-DataAck(seqno 3, ackno 10) --> 601 <-- DCCP-Data(seqno 11) 603 Every DCCP packet increments the sequence number, whether or not it 604 contains application data. DCCP-Ack pure acknowledgements increment 605 the sequence number, for instance: DCCP B's second packet above uses 606 sequence number 11, since sequence number 10 was used for an 607 acknowledgement. This lets endpoints detect all packet loss, 608 including acknowledgement loss. It also means that endpoints can 609 get out of sync after long bursts of loss; the DCCP-Sync and DCCP- 610 SyncAck packet types are used to recover (Section 7.5). 612 Since DCCP provides unreliable semantics, there are no 613 retransmissions, and it doesn't make sense to have a TCP-style 614 cumulative acknowledgement field. DCCP's Acknowledgement Number 615 field equals the greatest sequence number received, rather than the 616 smallest sequence number not received. Separate options indicate 617 any intermediate sequence numbers that weren't received. 619 4.3. States 621 DCCP endpoints progress through different states during the course 622 of a connection, corresponding roughly to the three phases of 623 initiation, data transfer, and termination. The figure below shows 624 the typical progress through these states for a client and server. 626 Client Server 627 ------ ------ 628 (0) No connection 629 CLOSED LISTEN 631 (1) Initiation 632 REQUEST DCCP-Request --> 633 <-- DCCP-Response RESPOND 634 PARTOPEN DCCP-Ack or DCCP-DataAck --> 636 (2) Data transfer 637 OPEN <-- DCCP-Data, Ack, DataAck --> OPEN 639 (3) Termination 640 <-- DCCP-CloseReq CLOSEREQ 641 CLOSING DCCP-Close --> 642 <-- DCCP-Reset CLOSED 643 TIMEWAIT 644 CLOSED 646 The nine possible states are as follows. They are listed in 647 increasing order, so that "state >= CLOSEREQ" means the same as 648 "state = CLOSEREQ or state = CLOSING or state = TIMEWAIT". Section 649 8 describes the states in more detail. 651 CLOSED 652 Represents nonexistent connections. 654 LISTEN 655 Represents server sockets in the passive listening state. 656 LISTEN and CLOSED are not associated with any particular DCCP 657 connection. 659 REQUEST 660 A client socket enters this state, from CLOSED, after sending a 661 DCCP-Request packet to try to initiate a connection. 663 RESPOND 664 A server socket enters this state, from LISTEN, after receiving 665 a DCCP-Request from a client. 667 PARTOPEN 668 A client socket enters this state, from REQUEST, after receiving 669 a DCCP-Response from the server. This state represents the 670 third phase of the three-way handshake. The client may send 671 application data in this state, but it MUST include an 672 Acknowledgement Number on all of its packets. 674 OPEN 675 The central, data transfer portion of a DCCP connection. Client 676 and server sockets enter this state from PARTOPEN and RESPOND, 677 respectively. Sometimes we speak of SERVER-OPEN and CLIENT-OPEN 678 states, corresponding to the server's OPEN state and the 679 client's OPEN state. 681 CLOSEREQ 682 A server socket enters this state, from SERVER-OPEN, to signal 683 that the connection is over, but the client must hold TIMEWAIT 684 state. 686 CLOSING 687 Server and client sockets can both enter this state to close the 688 connection. 690 TIMEWAIT 691 A server or client socket remains in this state for 2MSL (4 692 minutes) after the connection has been torn down, to prevent 693 mistakes due to the delivery of old packets. Only one of the 694 endpoints need enter TIMEWAIT state (the other can enter CLOSED 695 state immediately), and a server can request its client to hold 696 TIMEWAIT state using the DCCP-CloseReq packet type. 698 4.4. Congestion Control 700 DCCP connections are congestion controlled, but unlike in TCP, DCCP 701 applications have a choice of congestion control mechanism. In 702 fact, the two half-connections can be governed by different 703 mechanisms. Mechanisms are denoted by one-byte congestion control 704 identifiers, or CCIDs. The endpoints negotiate their CCIDs during 705 connection initiation. Each CCID describes how the HC-Sender limits 706 data packet rates, how the HC-Receiver sends congestion feedback via 707 acknowledgements, and so forth. CCIDs 2 and 3 are currently 708 defined; CCIDs 0, 1, and 4-255 are reserved. Other CCIDs may be 709 defined in the future. 711 CCID 2 provides TCP-like Congestion Control, which is similar to 712 that of TCP. The sender maintains a congestion window and sends 713 packets until that window is full. Packets are acknowledged by the 714 receiver. Dropped packets and ECN [RFC 3168] indicate congestion; 715 the response to congestion is to halve the congestion window. 716 Acknowledgements in CCID 2 contain the sequence numbers of all 717 received packets within some window, similar to a selective 718 acknowledgement (SACK) [RFC 2018]. 720 CCID 3 provides TFRC Congestion Control, an equation-based form of 721 congestion control intended to respond to congestion more smoothly 722 than CCID 2. The sender maintains a transmit rate, which it updates 723 using the receiver's estimate of the packet loss and mark rate. 724 CCID 3 behaves somewhat differently from TCP in the short term, it 725 is designed to operate fairly with TCP over the long term. 727 Section 10 describes DCCP's CCIDs in more detail. The behaviors of 728 CCIDs 2 and 3 are fully defined in separate profile documents [CCID 729 2 PROFILE] [CCID 3 PROFILE]. 731 4.5. Features 733 DCCP endpoints use Change and Confirm options to negotiate and agree 734 on feature values. Feature negotiation will almost always happen on 735 the connection initiation handshake, but it can begin at any time. 737 There are four feature negotiation options in all: Change L, 738 Confirm L, Change R, and Confirm R. The "L" options are sent by the 739 feature location, and the "R" options are sent by the feature 740 remote. A Change R option says to the feature location, "change 741 this feature value as follows". The feature location responds with 742 Confirm L, meaning "I've changed it". Some features allow Change R 743 options to contain multiple values, sorted in preference order. For 744 example: 746 Client Server 747 ------ ------ 748 Change R(CCID, 2) --> 749 <-- Confirm L(CCID, 2) 750 * agreement that CCID/Server = 2 * 752 Change R(CCID, 3 4) --> 753 <-- Confirm L(CCID, 4, 4 2) 754 * agreement that CCID/Server = 4 * 756 Both exchanges negotiate the CCID/Server feature's value, which is 757 the CCID in use on the server-to-client half-connection. In the 758 second exchange, the client requests that the server use either 759 CCID 3 or CCID 4, with 3 preferred; the server chooses 4 and 760 supplies its preference list, "4 2". 762 The Change L and Confirm R options are used for feature negotiations 763 initiated by the feature location. In the following example, the 764 server requests that CCID/Server be set to 3 or 2, with 3 preferred, 765 and the client agrees. 767 Client Server 768 ------ ------ 769 <-- Change L(CCID, 3 2) 770 Confirm R(CCID, 3, 3 2) --> 771 * agreement that CCID/Server = 3 * 773 Section 6 describes the feature negotiation options further, 774 including the retransmission strategies that make negotiation 775 reliable. 777 4.6. Differences From TCP 779 Differences between DCCP and TCP apart from those discussed so far 780 include: 782 o Copious space for options (up to 1008 bytes or the PMTU). 784 o Different acknowledgement formats. The CCID for a connection 785 determines how much acknowledgement information needs to be 786 transmitted. For example, in CCID 2 (TCP-like), this is about one 787 ack per 2 packets, and each ack must declare exactly which 788 packets were received; in CCID 3 (TFRC), it's about one ack per 789 round-trip time, and acks must declare at minimum just the 790 lengths of recent loss intervals. 792 o Denial-of-service (DoS) protection. Several mechanisms help 793 limit the amount of state possibly-misbehaving clients can force 794 DCCP servers to maintain. An Init Cookie option, analogous to 795 TCP's SYN Cookies [SYNCOOKIES], avoids SYN-flood-like attacks. 796 Only one connection endpoint need hold TIMEWAIT state; the DCCP- 797 CloseReq packet, which may only be sent by the server, passes 798 that state to the client. Various rate limits let servers avoid 799 attacks that might force extensive computation or packet 800 generation. 802 o Distinguishing different kinds of loss. A Data Dropped option 803 (Section 11.7) lets an endpoint declare that a packet was dropped 804 because of corruption, because of receive buffer overflow, and so 805 on. This facilitates research into more appropriate rate-control 806 responses for these non-network-congestion losses (although 807 currently such losses will cause a congestion response). 809 o Acknowledgeability. In TCP, a packet may be acknowledged only 810 once the data is reliably queued for application delivery. This 811 does not make sense in DCCP, where an application might, for 812 example, request a drop-from-front receive buffer. A DCCP packet 813 may be acknowledged as soon as its header has been successfully 814 processed. Concretely, a packet becomes acknowledgeable at 815 Step 8 of Section 8.5's packet processing pseudocode. 816 Acknowledgeability does not guarantee data delivery, however: the 817 Data Dropped option may later report that the packet's 818 application data was discarded. 820 o No receive window. DCCP is a congestion control protocol, not a 821 flow control protocol. 823 o No simultaneous open. Every connection has one client and one 824 server. 826 o No half-closed states. DCCP has no states corresponding to TCP's 827 FINWAIT and CLOSEWAIT, where one half-connection is explicitly 828 closed while the other is still active. The Data Dropped 829 option's Drop Code 1, Application Not Listening (Section 11.7), 830 can achieve a similar effect, however. 832 4.7. Example Connection 834 The progress of a typical DCCP connection is as follows. (This 835 description is informative, not normative.) 836 Client Server 837 ------ ------ 838 0. [CLOSED] [LISTEN] 839 1. DCCP-Request --> 840 2. <-- DCCP-Response 841 3. DCCP-Ack --> 842 4. DCCP-Data, DCCP-Ack, DCCP-DataAck --> 843 <-- DCCP-Data, DCCP-Ack, DCCP-DataAck 844 5. <-- DCCP-CloseReq 845 6. DCCP-Close --> 846 7. <-- DCCP-Reset 847 8. [TIMEWAIT] 849 1. The client sends the server a DCCP-Request packet specifying the 850 client and server ports, the service being requested, and any 851 features being negotiated, including the CCID that the client 852 would like the server to use. The client may optionally 853 piggyback an application request on the DCCP-Request packet, 854 which the server may ignore. 856 2. The server sends the client a DCCP-Response packet indicating 857 that it is willing to communicate with the client. This 858 response indicates any features and options that the server 859 agrees to, begins other feature negotiations as desired, and 860 optionally includes an Init Cookie that wraps up all this 861 information and which must be returned by the client for the 862 connection to complete. 864 3. The client sends the server a DCCP-Ack packet that acknowledges 865 the DCCP-Response packet. This acknowledges the server's 866 initial sequence number and returns the Init Cookie if there was 867 one in the DCCP-Response. It may also continue feature 868 negotiation. The client may piggyback an application-level 869 request on its final ack, producing a DCCP-DataAck packet. 871 4. The server and client then exchange DCCP-Data packets, DCCP-Ack 872 packets acknowledging that data, and, optionally, DCCP-DataAck 873 packets containing data with piggybacked acknowledgements. If 874 the client has no data to send, then the server will send DCCP- 875 Data and DCCP-DataAck packets, while the client will send DCCP- 876 Acks exclusively. (However, the client may not send DCCP-Data 877 packets before receiving at least one non-DCCP-Response packet 878 from the server.) 880 5. The server sends a DCCP-CloseReq packet requesting a close. 882 6. The client sends a DCCP-Close packet acknowledging the close. 884 7. The server sends a DCCP-Reset packet with Reset Code 1, 885 "Closed", and clears its connection state. DCCP-Resets are part 886 of normal connection termination; see Section 5.6. 888 8. The client receives the DCCP-Reset packet and holds state for 889 two maximum segment lifetimes, or 2MSL, to allow any remaining 890 packets to clear the network. 892 An alternative connection closedown sequence is initiated by the 893 client: 895 5b. The client sends a DCCP-Close packet closing the connection. 897 6b. The server sends a DCCP-Reset packet with Reset Code 1, 898 "Closed", and clears its connection state. 900 7b. The client receives the DCCP-Reset packet and holds state for 901 2MSL to allow any remaining packets to clear the network. 903 5. Packet Formats 905 The DCCP header can be from 12 to 1020 bytes long. The initial 12 906 bytes of the header have the same semantics for all currently- 907 defined packet types. Following this comes any additional fixed- 908 length fields required by the packet type, and then a variable- 909 length list of options. The application data area follows the 910 header. In some packet types, this area contains data for the 911 application; in other packet types, its contents are ignored. 913 +---------------------------------------+ -. 914 | Generic Header | | 915 +---------------------------------------+ | 916 | Additional Fields (depending on type) | +- DCCP Header 917 +---------------------------------------+ | 918 | Options (optional) | | 919 +=======================================+ -' 920 | Application Data Area | 921 +---------------------------------------+ 923 5.1. Generic Header 925 The DCCP generic header takes different forms depending on the value 926 of X, the Extended Sequence Numbers bit. If X is one, the Sequence 927 Number field is 48 bits long and the generic header takes 16 bytes, 928 as follows. 930 0 1 2 3 931 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 932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 933 | Source Port | Dest Port | 934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 935 | Data Offset | CCVal | CsCov | Checksum | 936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 937 | | |X| | . 938 | Res | Type |=| Reserved | Sequence Number (high bits) . 939 | | |1| | . 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 . Sequence Number (low bits) | 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 If X is zero, only the low 24 bits of the Sequence Number are 945 transmitted, and the generic header is 12 bytes long. 947 0 1 2 3 948 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 949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 | Source Port | Dest Port | 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 952 | Data Offset | CCVal | CsCov | Checksum | 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 954 | | |X| | 955 | Res | Type |=| Sequence Number (low bits) | 956 | | |0| | 957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 The generic header fields are defined as follows. 961 Source and Destination Ports: 16 bits each 962 These fields identify the connection, similar to the 963 corresponding fields in TCP and UDP. The Source Port represents 964 the relevant port on the endpoint that sent this packet, the 965 Destination Port the relevant port on the other endpoint. When 966 initiating a connection, the client SHOULD choose its Source 967 Port randomly to reduce the likelihood of attack. 969 DCCP APIs should treat port numbers similarly to TCP and UDP 970 port numbers. For example, machines that distinguish between 971 "privileged" and "unprivileged" ports for TCP and UDP should do 972 the same for DCCP. 974 Data Offset: 8 bits 975 The offset from the start of the packet's DCCP header to the 976 start of its application data area, in 32-bit words. The 977 receiver MUST ignore packets whose Data Offset is smaller than 978 the minimum-sized header for the given Type, or larger than the 979 DCCP packet itself. 981 CCVal: 4 bits 982 Used by the HC-Sender CCID. For example, the A-to-B CCID's 983 sender, which is active at DCCP A, MAY send 4 bits of 984 information per packet to its receiver by encoding that 985 information in CCVal. The sender MUST set CCVal to zero unless 986 its HC-Sender CCID specifies otherwise, and the receiver MUST 987 ignore the CCVal field unless its HC-Receiver CCID specifies 988 otherwise. 990 Checksum Coverage (CsCov): 4 bits 991 Checksum Coverage determines the parts of the packet that are 992 covered by the Checksum field. This always includes the DCCP 993 header and options, but some or all of the application data may 994 be excluded. This can improve performance on noisy links for 995 applications that can tolerate corruption. See Section 9. 997 Checksum: 16 bits 998 The Internet checksum of the packet's DCCP header (including 999 options), a network-layer pseudoheader, and, depending on 1000 Checksum Coverage, all, some, or none of the application data. 1001 See Section 9. 1003 Reserved (Res): 3 bits 1004 Senders MUST set this field to all zeroes on generated packets, 1005 and receivers MUST ignore its value. 1007 Type: 4 bits 1008 The Type field specifies the type of the packet. The following 1009 values are defined: 1011 Type Meaning 1012 ---- ------- 1013 0 DCCP-Request 1014 1 DCCP-Response 1015 2 DCCP-Data 1016 3 DCCP-Ack 1017 4 DCCP-DataAck 1018 5 DCCP-CloseReq 1019 6 DCCP-Close 1020 7 DCCP-Reset 1021 8 DCCP-Sync 1022 9 DCCP-SyncAck 1023 10-15 Reserved 1025 Table 1: DCCP Packet Types 1027 Receivers MUST ignore any packets with reserved type. That is, 1028 packets with reserved type MUST NOT be processed and they MUST 1029 NOT be acknowledged as received. 1031 Extended Sequence Numbers (X): 1 bit 1032 Set to one to indicate the use of an extended generic header 1033 with 48-bit Sequence and Acknowledgement Numbers. DCCP-Data, 1034 DCCP-DataAck, and DCCP-Ack packets MAY set X to zero or one. 1035 All DCCP-Request, DCCP-Response, DCCP-CloseReq, DCCP-Close, 1036 DCCP-Reset, DCCP-Sync, and DCCP-SyncAck packets MUST set X to 1037 one; endpoints MUST ignore any such packets with X set to zero. 1038 High-rate connections SHOULD set X to one on all packets to gain 1039 increased protection against wrapped sequence numbers and 1040 attacks. See Section 7.6. 1042 Sequence Number: 48 or 24 bits 1043 Identifies the packet uniquely in the sequence of all packets 1044 the source sent on this connection. Sequence Number increases 1045 by one with every packet sent, including packets such as DCCP- 1046 Ack that carry no application data. See Section 7. 1048 All currently defined packet types except DCCP-Request and DCCP-Data 1049 carry an Acknowledgement Number Subheader in the four or eight bytes 1050 immediately following the generic header. When X=1, its format is: 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 | Reserved | Acknowledgement Number . 1054 | | (high bits) . 1055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1056 . Acknowledgement Number (low bits) | 1057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1059 When X=0, only the low 24 bits of the Acknowledgement Number are 1060 transmitted, giving the Acknowledgement Number Subheader this 1061 format: 1063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1064 | Reserved | Acknowledgement Number (low bits) | 1065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 Reserved: 16 or 8 bits 1068 Senders MUST set this field to all zeroes on generated packets, 1069 and receivers MUST ignore its value. 1071 Acknowledgement Number: 48 or 24 bits 1072 Generally contains GSR, the Greatest Sequence Number Received on 1073 any acknowledgeable packet so far. A packet is acknowledgeable 1074 if and only if its header was successfully processed by the 1075 receiver; Section 7.4 describes this further. Options such as 1076 Ack Vector (Section 11.4) combine with the Acknowledgement 1077 Number to provide precise information about which packets have 1078 arrived. 1080 Acknowledgement Numbers on DCCP-Sync and DCCP-SyncAck packets 1081 need not equal GSR. See Section 5.7. 1083 5.2. DCCP-Request Packets 1085 A client initiates a DCCP connection by sending a DCCP-Request 1086 packet. These packets MAY contain application data, and MUST use 1087 48-bit sequence numbers (X=1). 1089 0 1 2 3 1090 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 1091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1092 / Generic DCCP Header with X=1 (16 bytes) / 1093 / with Type=0 (DCCP-Request) / 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 | Service Code | 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 / Options and Padding / 1098 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1099 / Application Data / 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1102 Service Code: 32 bits 1103 Describes the application-level service to which the client 1104 application wants to connect. Service Codes are intended to 1105 provide information about which application protocol a 1106 connection intends to use, and thus aiding middleboxes and 1107 reducing reliance on globally well-known ports. See Section 1108 8.1.2. 1110 5.3. DCCP-Response Packets 1112 The server responds to valid DCCP-Request packets with DCCP-Response 1113 packets. This is the second phase of the three-way handshake. 1114 DCCP-Response packets MAY contain application data, and MUST use 1115 48-bit sequence numbers (X=1). 1117 0 1 2 3 1118 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 1119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 / Generic DCCP Header with X=1 (16 bytes) / 1121 / with Type=1 (DCCP-Response) / 1122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1123 / Acknowledgement Number Subheader (8 bytes) / 1124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1125 | Service Code | 1126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1127 / Options and Padding / 1128 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1129 / Application Data / 1130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1132 Acknowledgement Number: 48 bits 1133 Contains GSR. Since DCCP-Responses are only sent during 1134 connection initiation, this will always equal the Sequence 1135 Number on a received DCCP-Request. 1137 Service Code: 32 bits 1138 MUST equal the Service Code on the corresponding DCCP-Request. 1140 5.4. DCCP-Data, DCCP-Ack, and DCCP-DataAck Packets 1142 The central data transfer portion of every DCCP connection uses 1143 DCCP-Data, DCCP-Ack, and DCCP-DataAck packets. These packets MAY 1144 use 24-bit sequence numbers, depending on the value of the Allow 1145 Short Sequence Numbers feature (Section 7.6.1). DCCP-Data packets 1146 carry application data without acknowledgements. 1148 0 1 2 3 1149 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 1150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1151 / Generic DCCP Header (16 or 12 bytes) / 1152 / with Type=2 (DCCP-Data) / 1153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1154 / Options and Padding / 1155 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1156 / Application Data / 1157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1159 DCCP-Ack packets dispense with the data, but contain an 1160 Acknowledgement Number. They are used for pure acknowledgements. 1162 0 1 2 3 1163 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 1164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1165 / Generic DCCP Header (16 or 12 bytes) / 1166 / with Type=3 (DCCP-Ack) / 1167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1168 / Acknowledgement Number Subheader (8 or 4 bytes) / 1169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1170 / Options and Padding / 1171 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1172 / Application Data Area (Ignored) / 1173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1175 DCCP-DataAck packets carry both application data and an 1176 Acknowledgement Number: acknowledgement information is piggybacked 1177 on a data packet. 1179 0 1 2 3 1180 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 1181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1182 / Generic DCCP Header (16 or 12 bytes) / 1183 / with Type=4 (DCCP-DataAck) / 1184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1185 / Acknowledgement Number Subheader (8 or 4 bytes) / 1186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1187 / Options and Padding / 1188 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1189 / Application Data / 1190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1192 A DCCP-Data or DCCP-DataAck packet may have a zero-length 1193 application data area, which indicates that the application sent a 1194 zero-length datagram. This differs from DCCP-Request and DCCP- 1195 Response packets, where an empty application data area indicates the 1196 absence of application data (not the presence of zero-length 1197 application data). The API SHOULD report any received zero-length 1198 datagrams to the receiving application. 1200 A DCCP-Ack packet MAY have a non-zero-length application data area, 1201 which essentially pads the DCCP-Ack to a desired length. Receivers 1202 MUST ignore the content of the application data area in DCCP-Ack 1203 packets. 1205 DCCP-Ack and DCCP-DataAck packets often include additional 1206 acknowledgement options, such as Ack Vector, as required by the 1207 congestion control mechanism in use. 1209 5.5. DCCP-CloseReq and DCCP-Close Packets 1211 DCCP-CloseReq and DCCP-Close packets begin the handshake that 1212 normally terminates a connection. Either client or server may send 1213 a DCCP-Close packet, which will elicit a DCCP-Reset packet. Only 1214 the server can send a DCCP-CloseReq packet, which indicates that the 1215 server wants to close the connection, but does not want to hold its 1216 TIMEWAIT state. Both packet types MUST use 48-bit sequence numbers 1217 (X=1). 1219 0 1 2 3 1220 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 1221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1222 / Generic DCCP Header with X=1 (16 bytes) / 1223 / with Type=5 (DCCP-CloseReq) or 6 (DCCP-Close) / 1224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1225 / Acknowledgement Number Subheader (8 bytes) / 1226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1227 / Options and Padding / 1228 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1229 / Application Data Area (Ignored) / 1230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1232 As with DCCP-Ack packets, DCCP-CloseReq and DCCP-Close packets MAY 1233 have non-zero-length application data areas, whose contents 1234 receivers MUST ignore. 1236 5.6. DCCP-Reset Packets 1238 DCCP-Reset packets unconditionally shut down a connection. 1239 Connections normally terminate with a DCCP-Reset, but resets may be 1240 sent for other reasons, including bad port numbers, bad option 1241 behavior, incorrect ECN Nonce Echoes, and so forth. DCCP-Resets 1242 MUST use 48-bit sequence numbers (X=1). 1244 0 1 2 3 1245 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 1246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1247 / Generic DCCP Header with X=1 (16 bytes) / 1248 / with Type=7 (DCCP-Reset) / 1249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1250 / Acknowledgement Number Subheader (8 bytes) / 1251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1252 | Reset Code | Data 1 | Data 2 | Data 3 | 1253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1254 / Options and Padding / 1255 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1256 / Application Data Area (Error Text) / 1257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1259 Reset Code: 8 bits 1260 Represents the reason that the sender reset the DCCP connection. 1262 Data 1, Data 2, and Data 3: 8 bits each 1263 The Data fields provide additional information about why the 1264 sender reset the DCCP connection. The meanings of these fields 1265 depend on the value of Reset Code. 1267 Application Data Area: Error Text 1268 If present, Error Text is a human-readable text string encoded 1269 in Unicode UTF-8, and preferably in English, that describes the 1270 error in more detail. For example, a DCCP-Reset with Reset Code 1271 11, "Aggression Penalty", might contain Error Text such as 1272 "Aggression Penalty: Received 3 bad ECN Nonce Echoes, assuming 1273 misbehavior". 1275 The following Reset Codes are currently defined. Unless otherwise 1276 specified, the Data 1, 2, and 3 fields MUST be set to 0 by the 1277 sender of the DCCP-Reset and ignored by its receiver. Section 1278 references describe concrete situations that will cause each Reset 1279 Code to be generated; they are not meant to be exhaustive. 1281 0, "Unspecified" 1282 Indicates the absence of a meaningful Reset Code. Use of Reset 1283 Code 0 is NOT RECOMMENDED: the sender should choose a Reset Code 1284 that more clearly defines why the connection is being reset. 1286 1, "Closed" 1287 Normal connection close. See Section 8.3. 1289 2, "Aborted" 1290 The sending endpoint gave up on the connection because of lack 1291 of progress. See Sections 8.1.1 and 8.1.5. 1293 3, "No Connection" 1294 No connection exists. See Section 8.3.1. 1296 4, "Packet Error" 1297 A valid packet arrived with unexpected type. For example, a 1298 DCCP-Data packet with valid header checksum and sequence numbers 1299 arrived at a connection in the REQUEST state. See Section 1300 8.3.1. The Data 1 field equals the offending packet type as an 1301 eight-bit number; thus, an offending packet with Type 2 will 1302 result in a Data 1 value of 2. 1304 5, "Option Error" 1305 An option was erroneous, and the error was serious enough to 1306 warrant resetting the connection. See Sections 6.6.7, 6.6.8, 1307 and 11.4. The Data 1 field equals the offending option type; 1308 Data 2 and Data 3 equal the first two bytes of option data (or 1309 zero if the option had less than two bytes of data). 1311 6, "Mandatory Error" 1312 The sending endpoint could not process an option O that was 1313 immediately preceded by Mandatory. The Data fields report the 1314 option type and data of option O, using the format of Reset Code 1315 5, "Option Error". See Section 5.8.2. 1317 7, "Connection Refused" 1318 The Destination Port didn't correspond to a port open for 1319 listening. Sent only in response to DCCP-Requests. See Section 1320 8.1.3. 1322 8, "Bad Service Code" 1323 The Service Code didn't equal the service code attached to the 1324 Destination Port. Sent only in response to DCCP-Requests. See 1325 Section 8.1.3. 1327 9, "Too Busy" 1328 The server is too busy to accept new connections. Sent only in 1329 response to DCCP-Requests. See Section 8.1.3. 1331 10, "Bad Init Cookie" 1332 The Init Cookie echoed by the client was incorrect or missing. 1333 See Section 8.1.4. 1335 11, "Aggression Penalty" 1336 This endpoint has detected congestion control-related 1337 misbehavior on the part of the other endpoint. See Sections 1338 12.2 and 13.2. 1340 12-127, Reserved 1341 Receivers should treat these codes like Reset Code 0, 1342 "Unspecified". 1344 128-255, CCID-specific codes 1345 Semantics depend on the connection's CCIDs. See Section 10.3. 1346 Receivers should treat unknown CCID-specific Reset Codes like 1347 Reset Code 0, "Unspecified". 1349 The following table summarizes this information. 1351 Reset 1352 Code Name Data 1 Data 2 & 3 1353 ----- ---- ------ ---------- 1354 0 Unspecified 0 0 1355 1 Closed 0 0 1356 2 Aborted 0 0 1357 3 No Connection 0 0 1358 4 Packet Error pkt type 0 1359 5 Option Error option # option data 1360 6 Mandatory Error option # option data 1361 7 Connection Refused 0 0 1362 8 Bad Service Code 0 0 1363 9 Too Busy 0 0 1364 10 Bad Init Cookie 0 0 1365 11 Aggression Penalty 0 0 1366 12-127 Reserved 1367 128-255 CCID-specific codes 1369 Table 2: DCCP Reset Codes 1371 Options on DCCP-Reset packets are processed before the connection is 1372 shut down. This means that certain combinations of options, 1373 particularly involving Mandatory, may cause an endpoint to respond 1374 to a valid DCCP-Reset with another DCCP-Reset. This cannot lead to 1375 a reset storm; since the first endpoint has already reset the 1376 connection, the second DCCP-Reset will be ignored. 1378 5.7. DCCP-Sync and DCCP-SyncAck Packets 1380 DCCP-Sync packets help DCCP endpoints recover synchronization after 1381 bursts of loss, or recover from half-open connections. Each valid 1382 received DCCP-Sync immediately elicits a DCCP-SyncAck. Both packet 1383 types MUST use 48-bit sequence numbers (X=1). 1385 0 1 2 3 1386 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 1387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1388 / Generic DCCP Header with X=1 (16 bytes) / 1389 / with Type=8 (DCCP-Sync) or 9 (DCCP-SyncAck) / 1390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1391 / Acknowledgement Number Subheader (8 bytes) / 1392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1393 / Options and Padding / 1394 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1395 / Application Data Area (Ignored) / 1396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1398 The Acknowledgement Number field has special semantics for DCCP-Sync 1399 and DCCP-SyncAck packets. First, the packet corresponding to a 1400 DCCP-Sync's Acknowledgement Number need not have been 1401 acknowledgeable. Thus, receivers MUST NOT assume that a packet was 1402 processed simply because it appears in the Acknowledgement Number 1403 field of a DCCP-Sync packet. This differs from all other packet 1404 types, where the Acknowledgement Number by definition corresponds to 1405 an acknowledgeable packet. Second, the Acknowledgement Number on 1406 any DCCP-SyncAck packet MUST correspond to the Sequence Number on an 1407 acknowledgeable DCCP-Sync packet. In the presence of reordering, 1408 this might not equal GSR. 1410 As with DCCP-Ack packets, DCCP-Sync and DCCP-SyncAck packets MAY 1411 have non-zero-length application data areas, whose contents 1412 receivers MUST ignore. Padded DCCP-Sync packets may be useful when 1413 performing Path MTU discovery; see Section 14. 1415 5.8. Options 1417 Any DCCP packet may contain options, which occupy space at the end 1418 of the DCCP header. Each option is a multiple of 8 bits in length. 1419 Individual options are not padded to multiples of 32 bits, and any 1420 option may begin on any byte boundary. However, the combination of 1421 all options MUST add up to a multiple of 32 bits; Padding options 1422 MUST be added as necessary to fill out option space to a word 1423 boundary. Any options present are included in the header checksum. 1425 The first byte of an option is the option type. Options with types 1426 0 through 31 are single-byte options. Other options are followed by 1427 a byte indicating the option's length. This length value includes 1428 the two bytes of option-type and option-length as well as any 1429 option-data bytes, and must therefore be greater than or equal to 1430 two. 1432 Options are processed sequentially, starting at the first option in 1433 the packet header. Options with unknown types, and options with 1434 invalid lengths (length byte less than two or more than the 1435 remaining space in the options portion of the header), MUST be 1436 ignored. 1438 The following options are currently defined: 1440 Option DCCP- Section 1441 Type Length Meaning Data? Reference 1442 ---- ------ ------- ----- --------- 1443 0 1 Padding Y 5.8.1 1444 1 1 Mandatory N 5.8.2 1445 2 1 Slow Receiver Y 11.6 1446 3-31 1 Reserved 1447 32 variable Change L N 6.1 1448 33 variable Confirm L N 6.2 1449 34 variable Change R N 6.1 1450 35 variable Confirm R N 6.2 1451 36 variable Init Cookie N 8.1.4 1452 37 3-5 NDP Count Y 7.7 1453 38 variable Ack Vector [Nonce 0] N 11.4 1454 39 variable Ack Vector [Nonce 1] N 11.4 1455 40 variable Data Dropped N 11.7 1456 41 6 Timestamp Y 13.1 1457 42 6/8/10 Timestamp Echo Y 13.3 1458 43 4/6 Elapsed Time N 13.2 1459 44 6 Data Checksum Y 9.3 1460 45-127 variable Reserved 1461 128-255 variable CCID-specific options - 10.3 1463 Table 3: DCCP Options 1465 Not all options are suitable for all packet types. For example, 1466 since the Ack Vector option is interpreted relative to the 1467 Acknowledgement Number, it isn't suitable on DCCP-Request and DCCP- 1468 Data packets, which have no Acknowledgement Number. If an option 1469 occurs on an unexpected packet type, it MUST generally be ignored; 1470 any such restrictions are mentioned in each option's description. 1471 The table summarizes the most common restriction: when the DCCP- 1472 Data? column value is N, the corresponding option MUST be ignored 1473 when received on a DCCP-Data packet. 1475 This section describes two generic options, Padding and Mandatory. 1476 Other options are described later. 1478 5.8.1. Padding Option 1480 +--------+ 1481 |00000000| 1482 +--------+ 1483 Type=0 1485 Padding is a single-byte "no-operation" option used to pad between 1486 or after options. If the length of a packet's other options is not 1487 a multiple of 4, then Padding options are REQUIRED to pad out the 1488 options area to the length implied by Data Offset. Padding may also 1489 be used between options -- for example, to align the beginning of a 1490 subsequent option on a word boundary. There is no guarantee that 1491 senders will use this option, so receivers must be prepared to 1492 process options even if they do not begin on a word boundary. 1494 5.8.2. Mandatory Option 1496 +--------+ 1497 |00000001| 1498 +--------+ 1499 Type=1 1501 Mandatory is a single byte option that marks the immediately 1502 following option as mandatory. Say that the immediately following 1503 option is O. Then the Mandatory option has no effect if the 1504 receiving DCCP endpoint understands and processes O. If the 1505 endpoint does not understand or process O, however, then it MUST 1506 reset the connection using Reset Code 6, "Mandatory Failure". For 1507 instance, the endpoint would reset the connection if it did not 1508 understand O's type; if it understood O's type, but not O's data; if 1509 O's data was invalid for O's type; if O was a feature negotiation 1510 option, and the endpoint did not understand the enclosed feature 1511 number; if the endpoint understood O, but chose not to perform the 1512 action O implies; and so forth. 1514 Mandatory options MUST NOT be sent on DCCP-Data packets, and any 1515 Mandatory options received on DCCP-Data packets MUST be ignored. 1517 The connection is in error and should be reset with Reset Code 5, 1518 "Option Error" if option O is absent (Mandatory was the last byte of 1519 the option list), or if option O equals Mandatory. However, the 1520 combination "Mandatory Padding" is valid, and MUST behave like two 1521 bytes of Padding. 1523 Section 6.6.9 describes the behavior of Mandatory feature 1524 negotiation options in more detail. 1526 6. Feature Negotiation 1528 Four DCCP options, Change L, Confirm L, Change R, and Confirm R, are 1529 used to negotiate feature values. Change options initiate a 1530 negotiation; Confirm options complete that negotiation. The "L" 1531 options are sent by the feature location, and the "R" options are 1532 sent by the feature remote. Change options are retransmitted to 1533 ensure reliability. 1535 All these options have the same format. The first byte of option 1536 data is the feature number, and the second and subsequent data bytes 1537 hold one or more feature values. The exact format of the feature 1538 value area depends on the feature type; see Section 6.3. 1540 +--------+--------+--------+--------+-------- 1541 | Type | Length |Feature#| Value(s) ... 1542 +--------+--------+--------+--------+-------- 1544 Together, the feature number and the option type ("L" or "R") 1545 uniquely identify the feature to which an option applies. The exact 1546 format of the Value(s) area depends on the feature number. 1548 Feature negotiation options MUST NOT be sent on DCCP-Data packets, 1549 and any feature negotiation options received on DCCP-Data packets 1550 MUST be ignored. 1552 6.1. Change Options 1554 Change L and Change R options initiate feature negotiation. The 1555 option to use depends on the relevant feature's location: To start a 1556 negotiation for feature F/A, DCCP A will send a Change L option; to 1557 start a negotiation for F/B, it will send a Change R option. Change 1558 options are retransmitted until some response is received. They 1559 contain at least one Value, and thus have length at least 4. 1561 +--------+--------+--------+--------+-------- 1562 Change L: |00100000| Length |Feature#| Value(s) ... 1563 +--------+--------+--------+--------+-------- 1564 Type=32 1566 +--------+--------+--------+--------+-------- 1567 Change R: |00100010| Length |Feature#| Value(s) ... 1568 +--------+--------+--------+--------+-------- 1569 Type=34 1571 6.2. Confirm Options 1573 Confirm L and Confirm R options complete feature negotiation, and 1574 are sent in response to Change R and Change L options, respectively. 1575 Confirm options MUST NOT be generated except in response to Change 1576 options. Confirm options need not be retransmitted, since Change 1577 options are retransmitted as necessary. The first byte of the 1578 Confirm option contains the feature number from the corresponding 1579 Change. Following this is the selected Value, and then possibly the 1580 sender's preference list. 1582 +--------+--------+--------+--------+-------- 1583 Confirm L: |00100001| Length |Feature#| Value(s) ... 1584 +--------+--------+--------+--------+-------- 1585 Type=33 1587 +--------+--------+--------+--------+-------- 1588 Confirm R: |00100011| Length |Feature#| Value(s) ... 1589 +--------+--------+--------+--------+-------- 1590 Type=35 1592 If an endpoint receives an invalid Change option -- with an unknown 1593 feature number, or an invalid value -- it will respond with an empty 1594 Confirm option containing the problematic feature number, but no 1595 value. Such options have length 3. 1597 6.3. Reconciliation Rules 1599 Reconciliation rules determine how the two sets of preferences for a 1600 given feature are resolved into a unique result. The reconciliation 1601 rule depends only on the feature number. Each reconciliation rule 1602 must have the property that the result is uniquely determined given 1603 the contents of Change options sent by the two endpoints. 1605 All current DCCP features use one of two reconciliation rules, 1606 server-priority ("SP") and non-negotiable ("NN"). 1608 6.3.1. Server-Priority 1610 The feature value is a fixed-length byte string (length determined 1611 by the feature number). Each Change option contains a list of 1612 values ordered by preference, with the most preferred value coming 1613 first. Each Confirm option contains the confirmed value, followed 1614 by the confirmer's preference list. Thus, the feature's current 1615 value will generally appear twice in Confirm options' data, once as 1616 the current value and once in the confirmer's preference list. 1618 To reconcile the preference lists, select the first entry in the 1619 server's list that also occurs in the client's list. If there is no 1620 shared entry, the feature's value MUST NOT change, and the Confirm 1621 option will confirm the feature's previous value (unless the Change 1622 option was Mandatory; see Section 6.6.9). 1624 6.3.2. Non-Negotiable 1626 The feature value is a byte string. Each option contains exactly 1627 one feature value. The feature location signals a new value by 1628 sending a Change L option. The feature remote MUST accept any valid 1629 value, responding with a Confirm R option containing the new value, 1630 and it MUST send empty Confirm R options in response to invalid 1631 values (unless the Change L option was Mandatory; see Section 1632 6.6.9). Change R and Confirm L options MUST NOT be sent for non- 1633 negotiable features; see Section 6.6.8. Non-negotiable features use 1634 the feature negotiation mechanism to achieve reliability. 1636 6.4. Feature Numbers 1638 This document defines the following feature numbers. 1640 Rec'n Initial Section 1641 Number Meaning Rule Value Req'd Reference 1642 ------ ------- ----- ----- ----- --------- 1643 0 Reserved 1644 1 Congestion Control ID (CCID) SP 2 Y 10 1645 2 Allow Short Seqnos SP 1 Y 7.6.1 1646 3 Sequence Window NN 100 Y 7.5.2 1647 4 ECN Incapable SP 0 N 12.1 1648 5 Ack Ratio NN 2 N 11.3 1649 6 Send Ack Vector SP 0 N 11.5 1650 7 Send NDP Count SP 0 N 7.7.2 1651 8 Minimum Checksum Coverage SP 0 N 9.2.1 1652 9 Check Data Checksum SP 0 N 9.3.1 1653 10-127 Reserved 1654 128-255 CCID-specific features 10.3 1656 Table 4: DCCP Feature Numbers 1658 Rec'n Rule The reconciliation rule used for the feature. SP is 1659 server-priority and NN is non-negotiable. 1661 Initial Value The initial value for the feature. Every feature has 1662 a known initial value. 1664 Req'd This column is "Y" if and only if every DCCP 1665 implementation MUST understand the feature. If it is 1666 "N", then the feature behaves like an extension (see 1667 Section 15), and it is safe to respond to Change 1668 options for the feature with empty Confirm options. 1669 Of course, a CCID might require the feature; a DCCP 1670 that implements CCID 2 MUST support Ack Ratio and 1671 Send Ack Vector, for example. 1673 6.5. Examples 1674 Here are three example feature negotiations for features located at 1675 the server, the first two for the Congestion Control ID feature, the 1676 last for the Ack Ratio. 1678 Client Server 1679 ------ ------ 1680 1. Change R(CCID, 2 3 1) --> 1681 ("2 3 1" is client's preference list) 1682 2. <-- Confirm L(CCID, 3, 3 2 1) 1683 (3 is the negotiated value; 1684 "3 2 1" is server's pref list) 1685 * agreement that CCID/Server = 3 * 1687 1. XXX <-- Change L(CCID, 3 2 1) 1688 2. Retransmission: 1689 <-- Change L(CCID, 3 2 1) 1690 3. Confirm R(CCID, 3, 2 3 1) --> 1691 * agreement that CCID/Server = 3 * 1693 1. <-- Change L(Ack Ratio, 3) 1694 2. Confirm R(Ack Ratio, 3) --> 1695 * agreement that Ack Ratio/Server = 3 * 1697 This example shows a simultaneous negotiation. 1699 Client Server 1700 ------ ------ 1701 1a. Change R(CCID, 2 3 1) --> 1702 b. <-- Change L(CCID, 3 2 1) 1703 2a. <-- Confirm L(CCID, 3, 3 2 1) 1704 b. Confirm R(CCID, 3, 2 3 1) --> 1705 * agreement that CCID/Server = 3 * 1707 Here are the byte encodings of several Change and Confirm options. 1708 Each option is sent by DCCP A. 1710 Change L(CCID, 2 3) = 32,5,1,2,3 1711 DCCP B should change CCID/A's value (feature number 1, a server- 1712 priority feature); DCCP A's preferred values are 2 and 3, in 1713 that preference order. 1715 Change L(Sequence Window, 1024) = 32,6,3,0,4,0 1716 DCCP B should change Sequence Window/A's value (feature number 1717 3, a non-negotiable feature) to the 3-byte string 0,4,0 (the 1718 value 1024). 1720 Confirm L(CCID, 2, 2 3) = 33,6,1,2,2,3 1721 DCCP A has changed CCID/A's value to 2; its preferred values are 1722 2 and 3, in that preference order. 1724 Empty Confirm L(126) = 33,3,126 1725 DCCP A doesn't implement feature number 126, or DCCP B's 1726 proposed value for feature 126/A was invalid. 1728 Change R(CCID, 3 2) = 34,5,1,3,2 1729 DCCP B should change CCID/B's value; DCCP A's preferred values 1730 are 3 and 2, in that preference order. 1732 Confirm R(CCID, 2, 3 2) = 35,6,1,2,3,2 1733 DCCP A has changed CCID/B's value to 2; its preferred values 1734 were 3 and 2, in that preference order. 1736 Confirm R(Sequence Window, 1024) = 35,6,3,0,4,0 1737 DCCP A has changed Sequence Window/B's value to the 3-byte 1738 string 0,4,0 (the value 1024). 1740 Empty Confirm R(126) = 35,3,126 1741 DCCP A doesn't implement feature number 126, or DCCP B's 1742 proposed value for feature 126/B was invalid. 1744 6.6. Option Exchange 1746 A few basic rules govern feature negotiation option exchange. 1748 1. Every non-reordered Change option gets a Confirm option in 1749 response. 1751 2. Change options are retransmitted until a response for the latest 1752 Change is received. 1754 3. Feature negotiation options are processed in strictly increasing 1755 order by Sequence Number. 1757 The rest of this section describes the consequences of these rules 1758 in more detail. 1760 6.6.1. Normal Exchange 1762 Change options are generated when a DCCP endpoint wants to change 1763 the value of some feature. Generally, this will happen at the 1764 beginning of a connection, although it may happen at any time. We 1765 say the endpoint "generates" or "sends" a Change L or Change R 1766 option, but of course the option must be attached to a packet. The 1767 endpoint may attach the option to a packet it would have generated 1768 anyway (such as a DCCP-Request), or it may create a "feature 1769 negotiation packet", often a DCCP-Ack or DCCP-Sync, just to carry 1770 the option. Feature negotiation packets are controlled by the 1771 relevant congestion control mechanism. For example, DCCP A may send 1772 a DCCP-Ack or DCCP-Sync for feature negotiation only if the B-to-A 1773 CCID would allow sending a DCCP-Ack. In addition, an endpoint 1774 SHOULD generate at most one feature negotiation packet per round- 1775 trip time. 1777 On receiving a Change L or Change R option, a DCCP endpoint examines 1778 the included preference list, reconciles that with its own 1779 preference list, calculates the new value, and sends back a 1780 Confirm R or Confirm L option, respectively, informing its peer of 1781 the new value or that the feature was not understood. Every non- 1782 reordered Change option MUST result in a corresponding Confirm 1783 option, and any packet including a Confirm option MUST carry an 1784 Acknowledgement Number. Generated Confirm options may be attached 1785 to packets that would have been sent anyway (such as DCCP-Response 1786 or DCCP-SyncAck), or to new feature negotiation packets, as 1787 described above. 1789 The Change-sending endpoint MUST wait to receive a corresponding 1790 Confirm option before changing its stored feature value. The 1791 Confirm-sending endpoint changes its stored feature value as soon as 1792 it sends the Confirm. 1794 A packet MAY contain more than one feature negotiation option, as 1795 long as no two options refer to the same feature. Note, however, 1796 that a packet is allowed to contain one L option and one R option 1797 with the same feature number, since the two options actually refer 1798 to different features (F/A and F/B). 1800 6.6.2. Processing Received Options 1802 DCCP endpoints exist in one of three states relative to each 1803 feature. STABLE is the normal state, where the endpoint knows the 1804 feature's value and thinks the other endpoint agrees. An endpoint 1805 enters the CHANGING state when it first sends a Change for the 1806 feature, and returns to STABLE once it receives a corresponding 1807 Confirm. The final state, UNSTABLE, indicates that an endpoint in 1808 CHANGING state changed its preference list, but has not yet 1809 transmitted a Change option with the new preference list. 1811 Feature state transitions at a feature location are implemented 1812 according to this diagram. The diagram ignores sequence number and 1813 option validity issues; these are handled explicitly in the 1814 pseudocode that follows. 1816 timeout/ 1817 rcv Confirm R app/protocol evt : snd Change L rcv non-ack 1818 : ignore +---------------------------------------+ : snd Change L 1819 +----+ | | +----+ 1820 | v | rcv Change R v | v 1821 +------------+ rcv Confirm R : calc new value, +------------+ 1822 | | : accept value snd Confirm L | | 1823 | STABLE |<-----------------------------------| CHANGING | 1824 | | rcv empty Confirm R | | 1825 +------------+ : revert to old value +------------+ 1826 | ^ | ^ 1827 +----+ pref list | | snd 1828 rcv Change R changes | | Change L 1829 : calc new value, snd Confirm L v | 1830 +------------+ 1831 +---| | 1832 rcv Confirm/Change R | | UNSTABLE | 1833 : ignore +-->| | 1834 +------------+ 1836 Feature locations SHOULD use the following pseudocode, which 1837 corresponds to the state diagram, to react to each feature 1838 negotiation option on each valid packet received. The pseudocode 1839 refers to "P.seqno" and "P.ackno", which are properties of the 1840 packet; "O.type", and "O.len", which are properties of the option; 1841 "FGSR" and "FGSS", which are properties of the connection, and 1842 handle reordering as described in Section 6.6.4; "F.state", which is 1843 the feature's state (STABLE, CHANGING, or UNSTABLE); and "F.value", 1844 which is the feature's value. 1846 First, check for unknown features (Section 6.6.7); 1847 If F is unknown, 1848 If the option was Mandatory, /* Section 6.6.9 */ 1849 Reset connection and return 1850 Otherwise, if O.type == Change R, 1851 Send Empty Confirm L on a future packet 1852 Return 1854 Second, check for reordering (Section 6.6.4); 1855 If F.state == UNSTABLE or P.seqno <= FGSR 1856 or (O.type == Confirm R and P.ackno < FGSS), 1857 Ignore option and return 1859 Third, process Change R options; 1860 If O.type == Change R, 1861 If the option's value is valid, /* Section 6.6.8 */ 1862 Calculate new value 1863 Send Confirm L on a future packet 1864 Set F.state := STABLE 1865 Otherwise, if the option was Mandatory, 1866 Reset connection and return 1867 Otherwise, 1868 Send Empty Confirm L on a future packet 1869 /* Remain in existing state. If that's CHANGING, this 1870 endpoint will retransmit its Change L option later. */ 1872 Fourth, process Confirm R options (but only in CHANGING state). 1873 If F.state == CHANGING and O.type == Confirm R, 1874 If O.len > 3, /* nonempty */ 1875 If the option's value is valid, 1876 Set F.value := new value 1877 Otherwise, 1878 Reset connection and return 1879 Set F.state := STABLE 1881 Of course, every DCCP endpoint is both a feature location and a 1882 feature remote. A similar diagram and pseudocode applies to feature 1883 remotes; simply switch the "L"s and "R"s, so that the relevant 1884 options are Change R and Confirm L. 1886 6.6.3. Loss and Retransmission 1888 Packets containing Change and Confirm options might be lost or 1889 delayed by the network. Therefore, Change options are repeatedly 1890 transmitted to achieve reliability. We refer to this as 1891 "retransmission", although of course there are no packet-level 1892 retransmissions in DCCP: a Change option that is sent again will be 1893 sent on a new packet with a new sequence number. 1895 A CHANGING endpoint transmits another Change option once it realizes 1896 that it has not heard back from the other endpoint. The new Change 1897 option need not contain the same payload as the original; reordering 1898 protection will ensure that agreement is reached based on the most 1899 recently transmitted option. 1901 A CHANGING endpoint MUST continue retransmitting Change options 1902 until it gets some response or the connection terminates. 1904 Endpoints SHOULD use an exponential-backoff timer to decide when to 1905 retransmit Change options. (Endpoints that generate packets 1906 specifically for feature negotiation MUST use such a timer.) The 1907 timer interval is initially set to not less than one round-trip 1908 time, and should back off to not less than 64 seconds. The backoff 1909 protects against delayed agreement due to the reordering protection 1910 algorithms described in the next section. Again, endpoints may 1911 piggyback Change options on packets they would have sent anyway, or 1912 create new packets to carry the options; any such new packets are 1913 controlled by the relevant congestion-control mechanism. 1915 Confirm options are never retransmitted, but the Confirm-sending 1916 endpoint MUST generate a Confirm option after every non-reordered 1917 Change. 1919 6.6.4. Reordering 1921 Reordering might cause packets containing Change and Confirm options 1922 to arrive in an unexpected order. Endpoints MUST ignore feature 1923 negotiation options that do not arrive in strictly-increasing order 1924 by Sequence Number. The rest of this section presents two 1925 algorithms that fulfill this requirement. 1927 The first algorithm introduces two sequence number variables that 1928 each endpoint maintains for the connection. 1930 FGSR Feature Greatest Sequence Number Received: The greatest 1931 sequence number received, considering only valid packets 1932 that contained one or more feature negotiation options 1933 (Change and/or Confirm). This value is initialized to 1934 ISR - 1. 1936 FGSS Feature Greatest Sequence Number Sent: The greatest 1937 sequence number sent, considering only packets that 1938 contained one or more non-retransmitted Change options. 1939 (Retransmitted Change options MUST have exactly the same 1940 contents as previously transmitted options, so limited 1941 reordering can safely be tolerated.) This value is 1942 initialized to ISS. 1944 Each endpoint checks two conditions on sequence numbers to decide 1945 whether to process received feature negotiation options. 1947 1. If a packet's Sequence Number is less than or equal to FGSR, 1948 then its Change options MUST be ignored. 1950 2. If a packet's Sequence Number is less than or equal to FGSR, OR 1951 it has no Acknowledgement Number, OR its Acknowledgement Number 1952 is less than FGSS, then its Confirm options MUST be ignored. 1954 Alternatively, an endpoint MAY maintain separate FGSR and FGSS 1955 values for every feature. FGSR(F/X) would equal the greatest 1956 sequence number received, considering only packets that contained 1957 Change or Confirm options applying to feature F/X; FGSS(F/X) would 1958 be defined similarly. This algorithm requires more state, but is 1959 slightly more forgiving to multiple overlapped feature negotiations. 1960 Either algorithm MAY be used; the first algorithm, with connection- 1961 wide FGSR and FGSS variables, is RECOMMENDED. 1963 One consequence of these rules is that a CHANGING endpoint will 1964 ignore any Confirm option that does not acknowledge the latest 1965 Change option sent. This ensures that agreement, once achieved, 1966 used the most recent available information about the endpoints' 1967 preferences. 1969 6.6.5. Preference Changes 1971 Endpoints are allowed to change their preference lists at any time. 1972 However, an endpoint that changes its preference list while in the 1973 CHANGING state MUST transition to the UNSTABLE state. It will 1974 transition back to CHANGING once it has transmitted a Change option 1975 with the new preference list. This ensures that agreement is based 1976 on active preference lists. Without the UNSTABLE state, 1977 simultaneous negotiation -- where the endpoints began independent 1978 negotiations for the same feature at the same time -- might lead to 1979 the negotiation terminating with the endpoints thinking the feature 1980 had different values. 1982 6.6.6. Simultaneous Negotiation 1984 The two endpoints might simultaneously open negotiation for the same 1985 feature, after which an endpoint in the CHANGING state will receive 1986 a Change option for the same feature. Such received Change options 1987 can act as responses to the original Change options. The CHANGING 1988 endpoint MUST examine the received Change's preference list, 1989 reconcile that with its own preference list (as expressed in its 1990 generated Change options), and generate the corresponding Confirm 1991 option. It can then transition to the STABLE state. 1993 6.6.7. Unknown Features 1995 Endpoints may receive Change options referring to feature numbers 1996 they do not understand -- for instance, when an extended DCCP 1997 converses with a non-extended DCCP. Endpoints MUST respond to 1998 unknown Change options with Empty Confirm options (that is, Confirm 1999 options containing no data), which inform the CHANGING endpoint that 2000 the feature was not understood. However, if the Change option was 2001 Mandatory, the connection MUST be reset; see Section 6.6.9. 2003 On receiving an empty Confirm option for some feature, the CHANGING 2004 endpoint MUST transition back to the STABLE state, leaving the 2005 feature's value unchanged. Section 15 suggests that the default 2006 value for any extension feature should correspond to "extension not 2007 available". 2009 Some features are required to be understood by all DCCPs (see 2010 Section 6.4). The CHANGING endpoint SHOULD reset the connection 2011 (with Reset Code 5, "Option Error") if it receives an empty Confirm 2012 option for such a feature. 2014 Since Confirm options are generated only in response to Change 2015 options, an endpoint should never receive a Confirm option referring 2016 to a feature number it does not understand. Nevertheless, endpoints 2017 MUST ignore any such options they receive. 2019 6.6.8. Invalid Options 2021 A DCCP endpoint might receive a Change or Confirm option that lists 2022 one or more values that it does not understand. Some, but not all, 2023 such options are invalid, depending on the relevant reconciliation 2024 rule (Section 6.3). For instance: 2026 o All features have length limitiations, and options with invalid 2027 lengths are invalid. For example, the Ack Ratio feature takes 2028 16-bit values, so valid "Confirm R(Ack Ratio)" options have 2029 option length 5. 2031 o Some non-negotiable features have value limitations. The Ack 2032 Ratio feature takes two-byte, non-zero integer values, so a 2033 "Change L(Ack Ratio, 0)" option is never valid. Note that 2034 server-priority features do not have value limitations, since 2035 unknown values are handled as a matter of course. 2037 o Any Confirm option that selects the wrong value, based on the two 2038 preference lists and the relevant reconciliation rule, is 2039 invalid. 2041 o However, unexpected Confirm options -- that refer to unknown 2042 feature numbers, or that don't appear to be part of a current 2043 negotiation -- are considered valid, although they are ignored by 2044 the receiver. 2046 An endpoint receiving an invalid Change option MUST respond with the 2047 corresponding empty Confirm option. An endpoint receiving an 2048 invalid Confirm option MUST reset the connection, with Reset Code 5, 2049 "Option Error". 2051 6.6.9. Mandatory Feature Negotiation 2053 Change options may be preceded by Mandatory options (Section 5.8.2). 2054 Mandatory Change options are processed like normal Change options, 2055 except that the following failure cases will cause the receiver to 2056 reset the connection with Reset Code 6, "Mandatory Failure", rather 2057 than send a Confirm option. The connection MUST be reset if: 2059 o The Change option's feature number was not understood; 2061 o The Change option's value was invalid, and the receiver would 2062 normally have sent an empty Confirm option in response; or 2064 o For server-priority features, there was no shared entry in the 2065 two endpoints' preference lists. 2067 There's no reason to mark Confirm options as Mandatory in this 2068 version of DCCP, since Confirm options are sent only in response to 2069 Change options and therefore can't mention potentially-invalid 2070 values or unexpected feature numbers. 2072 7. Sequence Numbers 2074 DCCP uses sequence numbers to arrange packets into sequence, detect 2075 losses and network duplicates, and protect against attackers, half- 2076 open connections, and the delivery of very old packets. Every 2077 packet carries a Sequence Number; most packet types carry an 2078 Acknowledgement Number as well. 2080 DCCP sequence numbers are packet-based. That is, the packets 2081 generated by each endpoint have Sequence Numbers that increase by 2082 one, modulo 2^48, for every packet. Even DCCP-Ack and DCCP-Sync 2083 packets, and other packets that don't carry user data, increment the 2084 Sequence Number. Since DCCP is an unreliable protocol, there are no 2085 true retransmissions; but effective retransmissions, such as 2086 retransmissions of DCCP-Request packets, also increment the Sequence 2087 Number. This lets DCCP implementations detect network duplication, 2088 retransmissions, and acknowledgement loss, and is a significant 2089 departure from TCP practice. 2091 7.1. Variables 2093 DCCP endpoints maintain a set of sequence number variables for each 2094 connection. 2096 ISS The Initial Sequence Number Sent by this endpoint. This 2097 equals the Sequence Number of the first DCCP-Request or 2098 DCCP-Response sent. 2100 ISR The Initial Sequence Number Received from the other 2101 endpoint. This equals the Sequence Number of the first 2102 DCCP-Request or DCCP-Response received. 2104 GSS The Greatest Sequence Number Sent by this endpoint. Here, 2105 and elsewhere, "greatest" is measured in circular sequence 2106 space. 2108 GSR The Greatest Sequence Number Received from the other 2109 endpoint on an acknowledgeable packet. (Section 7.4 defines 2110 this term.) 2112 GAR The Greatest Acknowledgement Number Received from the other 2113 endpoint on an acknowledgeable packet that was not a DCCP- 2114 Sync. 2116 Some other variables are derived from these primitives. 2118 SWL and SWH 2119 (Sequence Number Window Low and High) The extremes of the 2120 validity window for received packets' Sequence Numbers. 2122 AWL and AWH 2123 (Acknowledgement Number Window Low and High) The extremes 2124 of the validity window for received packets' Acknowledgement 2125 Numbers. 2127 7.2. Initial Sequence Numbers 2129 The endpoints' initial sequence numbers are set by the first DCCP- 2130 Request and DCCP-Response packets sent. Initial sequence numbers 2131 MUST be chosen to avoid two problems: 2133 o Delivery of old packets, where packets lingering in the network 2134 from an old connection are delivered to a new connection with the 2135 same addresses and port numbers. 2137 o Sequence number attacks, where an attacker can guess the sequence 2138 numbers that a future connection would use [M85]. 2140 These problems are the same as problems faced by TCP, and DCCP 2141 implementations SHOULD use TCP's strategies to avoid them [RFC 793] 2142 [RFC 1948]. The rest of this section explains these strategies in 2143 more detail. 2145 To address the first problem, an implementation MUST ensure that the 2146 initial sequence number for a given 4-tuple doesn't overlap with 2148 recent sequence numbers on previous connections with the same 2149 4-tuple. ("Recent" means sent within 2 maximum segment lifetimes, 2150 or 4 minutes.) The implementation MUST additionally ensure that the 2151 lower 24 bits of the initial sequence number don't overlap with the 2152 lower 24 bits of recent sequence numbers (unless the implementation 2153 plans to avoid short sequence numbers; see Section 7.6). An 2154 implementation that has state for a recent connection with the same 2155 4-tuple can pick a good initial sequence number explicitly. 2156 Otherwise, it could tie initial sequence number selection to some 2157 clock, such as the 4-microsecond clock used by TCP [RFC 793]. Two 2158 separate clocks may be required, one for the upper 24 bits and one 2159 for the lower 24 bits. 2161 To address the second problem, an implementation MUST provide each 2162 4-tuple with an independent initial sequence number space. Then 2163 opening a connection doesn't provide any information about initial 2164 sequence numbers on other connections to the same host. RFC 1948 2165 achieves this by adding a cryptographic hash of the 4-tuple and a 2166 secret to each initial sequence number. For the secret, RFC 1948 2167 recommends a combination of some truly-random data [RFC 1750], an 2168 administratively-installed passphrase, the endpoint's IP address, 2169 and the endpoint's boot time, but truly-random data is sufficient. 2170 Care should be taken when changing the secret; such a change alters 2171 all initial sequence number spaces, which might make an initial 2172 sequence number for some 4-tuple equal a recently sent sequence 2173 number for the same 4-tuple. To avoid this problem, the endpoint 2174 might remember dead connection state for each 4-tuple or stay quiet 2175 for 2 maximum segment lifetimes around such a change. 2177 7.3. Quiet Time 2179 DCCP endpoints, like TCP endpoints, must take care before initiating 2180 connections when they boot. In particular, they MUST NOT send 2181 packets whose sequence numbers are close to the sequence numbers of 2182 packets lingering in the network from before the boot. The simplest 2183 way to enforce this rule is for DCCP endpoints to avoid sending any 2184 packets until one maximum segment lifetime (2 minutes) after boot. 2185 Other enforcement mechanisms include remembering recent sequence 2186 numbers across boots, and reserving the upper 8 or so bits of 2187 initial sequence numbers for a persistent counter that decrements by 2188 two each boot. (The latter mechanism would require disallowing 2189 packets with short sequence numbers; see Section 7.6.1.) 2191 7.4. Acknowledgement Numbers 2193 Cumulative acknowledgements are meaningless in an unreliable 2194 protocol. Therefore, DCCP's Acknowledgement Number field has a 2195 different meaning than TCP's. 2197 A received packet is classified as acknowledgeable if and only if 2198 its header was succesfully processed by the receiving DCCP. In 2199 terms of the pseudocode in Section 8.5, a received packet becomes 2200 acknowledgeable when the receiving endpoint reaches Step 8. This 2201 means, for example, that all acknowledgeable packets have valid 2202 header checksums and sequence numbers. The Acknowledgement Number 2203 MUST equal GSR, the Greatest Sequence Number Received on an 2204 acknowledgeable packet, for all packet types except DCCP-Sync and 2205 DCCP-SyncAck. 2207 "Acknowledgeable" does not refer to data processing. Even 2208 acknowledgeable packets may have their application data dropped, due 2209 to receive buffer overflow or corruption, for instance. Data 2210 Dropped options report these data losses when necessary, letting 2211 congestion control mechanisms distinguish between network losses and 2212 endpoint losses. This issue is discussed further in Sections 11.4 2213 and 11.7. 2215 DCCP-Sync and DCCP-SyncAck packets' Acknowledgement Numbers differ 2216 as follows: The Acknowledgement Number on a DCCP-Sync packet 2217 corresponds to a received packet, but not necessarily an 2218 acknowledgeable packet; in particular, it might correspond to an 2219 out-of-sync packet whose options were not processed. The 2220 Acknowledgement Number on a DCCP-SyncAck packet always corresponds 2221 to an acknowledgeable DCCP-Sync packet; it might be less than GSR in 2222 the presence of reordering. 2224 7.5. Validity and Synchronization 2226 Any DCCP endpoint might receive packets that are not actually part 2227 of the current connection. For instance, the network might deliver 2228 an old packet, an attacker might attempt to hijack a connection, or 2229 the other endpoint might crash, causing a half-open connection. 2231 DCCP, like TCP, uses sequence number checks to detect these cases. 2232 Packets whose Sequence and/or Acknowledgement Numbers are out of 2233 range are called sequence-invalid, and are not processed normally. 2235 Unlike TCP, DCCP requires a synchronization mechanism to recover 2236 from large bursts of loss. One endpoint might send so many packets 2237 during a burst of loss that when one of its packets finally got 2238 through, the other endpoint would label its Sequence Number as 2239 invalid. A handshake of DCCP-Sync and DCCP-SyncAck packets recovers 2240 from this case. 2242 7.5.1. Sequence and Acknowledgement Number Windows 2244 Each DCCP endpoint defines sequence validity windows that are 2245 subsets of the Sequence and Acknowledgement Number spaces. These 2246 windows correspond to packets the endpoint expects to receive in the 2247 next few round-trip times. The Sequence and Acknowledgement Number 2248 windows always contain GSR and GSS, respectively. The window widths 2249 are controlled by Sequence Window features for the two half- 2250 connections. 2252 The Sequence Number validity window for packets from DCCP B is [SWL, 2253 SWH]. This window always contains GSR, the Greatest Sequence Number 2254 Received on a sequence-valid packet from DCCP B. It is W packets 2255 wide, where W is the value of the Sequence Window/B feature. One- 2256 fourth of the sequence window, rounded down, is less than or equal 2257 to GSR, and three-fourths is greater than GSR. (This asymmetric 2258 placement assumes that bursts of loss are more common in the network 2259 than significant reordering.) 2261 invalid | valid Sequence Numbers | invalid 2262 <---------*|*===========*=======================*|*---------> 2263 GSR -|GSR + 1 - GSR GSR +|GSR + 1 + 2264 floor(W/4)|floor(W/4) ceil(3W/4)|ceil(3W/4) 2265 = SWL = SWH 2267 The Acknowledgement Number validity window for packets from DCCP B 2268 is [AWL, AWH]. The high end of the window, AWH, equals GSS, the 2269 Greatest Sequence Number Sent by DCCP A; the window is W' packets 2270 wide, where W' is the value of the Sequence Window/A feature. 2272 invalid | valid Acknowledgement Numbers | invalid 2273 <---------*|*===================================*|*---------> 2274 GSS - W'|GSS + 1 - W' GSS|GSS + 1 2275 = AWL = AWH 2277 SWL and AWL are initially adjusted so that they are not less than 2278 the initial Sequence Numbers received and sent, respectively: 2279 SWL := max(GSR + 1 - floor(W/4), ISR), 2280 AWL := max(GSS - W' + 1, ISS). 2281 These adjustments MUST be applied only at the beginning of the 2282 connection. (Long-lived connections may wrap sequence numbers so 2283 that they appear to be less than ISR or ISS; the adjustments MUST 2284 NOT be applied in that case.) 2286 7.5.2. Sequence Window Feature 2288 The Sequence Window/A feature determines the width of the Sequence 2289 Number validity window used by DCCP B, and the width of the 2290 Acknowledgement Number validity window used by DCCP A. DCCP A sends 2291 a "Change L(Sequence Window, W)" option to notify DCCP B that the 2292 Sequence Window/A value is W. 2294 Sequence Window has feature number 3, and is non-negotiable. It 2295 takes 48-bit (6-byte) integer values, like DCCP sequence numbers, 2296 but 1- to 5-byte values are also allowed in options -- they are 2297 padded on the left with zero bytes as necessary to total 48 bits. 2298 Change and Confirm options for Sequence Window are therefore between 2299 4 and 9 bytes long. New connections start with Sequence Window 100 2300 for both endpoints. The maximum valid Sequence Window value is 2301 Wmax = 2^46 - 1 = 70368744177663; circular sequence number 2302 comparisons would stop working absent this constraint. Change 2303 options suggesting larger Sequence Window values are invalid and 2304 MUST be handled accordingly. 2306 A proper Sequence Window/A value should reflect how many packets 2307 DCCP A expects to be in flight. Only DCCP A can anticipate this 2308 number. Too-small values increase the risk of the endpoints getting 2309 out sync after bursts of loss; too-large values increase the risk of 2310 connection hijacking. (The next section quantifies this risk.) One 2311 good guideline is for each endpoint to set Sequence Window to about 2312 five times the maximum number of packets it expects to send in a 2313 round-trip time. This value may not be available at connection 2314 initiation, when the round-trip time is unknown, but the endpoint 2315 can always send updates as the connection progresses. 2317 7.5.3. Sequence-Validity Rules 2319 Sequence-validity depends on the received packet's type. This table 2320 shows the sequence and acknowledgement number checks applied to each 2321 packet; a packet is sequence-valid if it passes both tests, and 2322 sequence-invalid if it does not. Many of the checks refer to the 2323 sequence and acknowledgement number validity windows [SWL, SWH] and 2324 [AWL, AWH], which are defined in Section 7.5.1. 2326 Acknowledgement Number 2327 Packet Type Sequence Number Check Check 2328 ----------- --------------------- ---------------------- 2329 DCCP-Request SWL <= seqno <= SWH (*) N/A 2330 DCCP-Response SWL <= seqno <= SWH (*) AWL <= ackno <= AWH 2331 DCCP-Data SWL <= seqno <= SWH N/A 2332 DCCP-Ack SWL <= seqno <= SWH AWL <= ackno <= AWH 2333 DCCP-DataAck SWL <= seqno <= SWH AWL <= ackno <= AWH 2334 DCCP-CloseReq GSR < seqno <= SWH GAR <= ackno <= AWH 2335 DCCP-Close GSR < seqno <= SWH GAR <= ackno <= AWH 2336 DCCP-Reset GSR < seqno <= SWH GAR <= ackno <= AWH 2337 DCCP-Sync SWL <= seqno AWL <= ackno <= AWH 2338 DCCP-SyncAck SWL <= seqno AWL <= ackno <= AWH 2340 (*) Check not applied if connection is in LISTEN or REQUEST state. 2342 In general, packets are sequence-valid if their Sequence and 2343 Acknowledgement Numbers lie within the corresponding valid windows, 2344 [SWL, SWH] and [AWL, AWH]. The exceptions to this rule are as 2345 follows: 2347 o Since DCCP-CloseReq, DCCP-Close, and DCCP-Reset packets end a 2348 connection, they cannot have Sequence Numbers less than or equal 2349 to GSR, or Acknowledgement Numbers less than GAR. 2351 o DCCP-Sync and DCCP-SyncAck Sequence Numbers are not strongly 2352 checked. These packet types exist specifically to get the 2353 endpoints back into sync; checking their Sequence Numbers would 2354 eliminate their usefulness. 2356 Although the lenient checks on DCCP-Sync and DCCP-SyncAck packets 2357 allow continued operation after unusual events, such as endpoint 2358 crashes and large bursts of loss, there's no need for leniency when 2359 the endpoints are actively sending packets to one another. 2360 Therefore, DCCP implementations SHOULD use the following, more 2361 stringent checks for active connections. A connection is considered 2362 active if it has received valid packets from the other endpoint 2363 within the last five round-trip times. 2365 Acknowledgement Number 2366 Packet Type Sequence Number Check Check 2367 ----------- --------------------- ---------------------- 2368 DCCP-Sync SWL <= seqno <= SWH AWL <= ackno <= AWH 2369 DCCP-SyncAck SWL <= seqno <= SWH AWL <= ackno <= AWH 2371 Finally, an endpoint MAY apply the following more stringent checks 2372 to DCCP-CloseReq, DCCP-Close, and DCCP-Reset packets, further 2373 lowering the probability of successful blind attacks using those 2374 packet types. Since these checks can cause extra synchronization 2375 overhead and delay connection closing when packets are lost, they 2376 should be considered experimental. 2378 Acknowledgement Number 2379 Packet Type Sequence Number Check Check 2380 ----------- --------------------- ---------------------- 2381 DCCP-CloseReq seqno == GSR + 1 GAR <= ackno <= AWH 2382 DCCP-Close seqno == GSR + 1 GAR <= ackno <= AWH 2383 DCCP-Reset seqno == GSR + 1 GAR <= ackno <= AWH 2385 Note that sequence-validity is only one of the validity checks 2386 applied to received packets. 2388 7.5.4. Handling Sequence-Invalid Packets 2390 Endpoints MUST ignore sequence-invalid DCCP-Sync and DCCP-SyncAck 2391 packets, and MUST respond to other sequence-invalid packets with 2392 (possibly rate-limited) DCCP-Sync packets. Each DCCP-Sync packet 2393 MUST acknowledge the corresponding sequence-invalid packet's 2394 Sequence Number, not GSR. The DCCP-Sync MUST use a new Sequence 2395 Number, and thus will increase GSS; GSR will not change, however, 2396 since the received packet was sequence-invalid. 2398 On receiving a sequence-valid DCCP-Sync packet, the peer endpoint 2399 (say, DCCP B) MUST update its GSR variable and reply with a DCCP- 2400 SyncAck packet. The DCCP-SyncAck packet's Acknowledgement Number 2401 will equal the DCCP-Sync's Sequence Number, not necessarily GSR. 2402 Upon receiving this DCCP-SyncAck, which will be sequence-valid since 2403 it acknowledges the DCCP-Sync, DCCP A will update its GSR variable, 2404 and the endpoints will be back in sync. As an exception, if the 2405 peer endpoint is in the REQUEST state, it MUST respond with a DCCP- 2406 Reset instead of a DCCP-SyncAck. This serves to clean up DCCP A's 2407 half-open connection. 2409 To protect against denial-of-service attacks, DCCP implementations 2410 SHOULD impose a rate limit on DCCP-Syncs sent in response to 2411 sequence-invalid packets, such as not more than eight DCCP-Syncs per 2412 second. 2414 DCCP endpoints MUST NOT process sequence-invalid packets except, 2415 perhaps, by generating a DCCP-Sync. For instance, options MUST NOT 2416 but processed. An endpoint MAY temporarily preserve sequence- 2417 invalid packets in case they become valid later, however; this can 2418 reduce the impact of bursts of loss by delivering more packets to 2419 the application. In particular, an endpoint MAY preserve sequence- 2420 invalid packets for up to 2 round-trip times. If, within that time, 2421 the relevant sequence windows change so that the packets become 2422 sequence-valid, the endpoint MAY process them again. 2424 Note that sequence-invalid DCCP-Reset packets cause DCCP-Syncs to be 2425 generated. This is because endpoints in an unsynchronized state 2426 (CLOSED, REQUEST, and LISTEN) might not have enough information to 2427 generate a proper DCCP-Reset on the first try. For example, if a 2428 peer endpoint is in CLOSED state and receives a DCCP-Data packet, it 2429 cannot guess the right Sequence Number to use on the DCCP-Reset it 2430 generates (since the DCCP-Data packet has no Acknowledgement 2431 Number). The DCCP-Sync generated in response to this bad reset 2432 serves as a challenge, and contains enough information for the peer 2433 to generate a proper DCCP-Reset. However, the new DCCP-Reset may 2434 carry a different Reset Code than the original DCCP-Reset; probably 2435 the new Reset Code will be 3, "No Connection". The endpoint SHOULD 2436 use information from the original DCCP-Reset when possible. 2438 7.5.5. Sequence Number Attacks 2440 Sequence and Acknowledgement Numbers form DCCP's main line of 2441 defense against attackers. An attacker that cannot guess sequence 2442 numbers cannot easily manipulate or hijack a DCCP connection, and 2443 requirements like careful initial sequence number choice eliminate 2444 the most serious attacks. 2446 An attacker might still send many packets with randomly chosen 2447 Sequence and Acknowledgement Numbers, however. If one of those 2448 probes ends up sequence-valid, it may shut down the connection or 2449 otherwise cause problems. The easiest such attacks to execute are: 2451 o Send DCCP-Data packets with random Sequence Numbers. If one of 2452 these packets hits the valid sequence number window, the attack 2453 packet's application data may be inserted into the data stream. 2455 o Send DCCP-Sync packets with random Sequence and Acknowledgement 2456 Numbers. If one of these packets hits the valid acknowledgement 2457 number window, the receiver will shift its sequence number window 2458 accordingly, getting out of sync with the correct endpoint -- 2459 perhaps permanently. 2461 The attacker has to guess both Source and Destination Ports for any 2462 of these attacks to succeed. Additionally, the connection would 2463 have to be inactive for the DCCP-Sync attack to succeed, assuming 2464 the victim implemented the more stringent checks for active 2465 connections recommended in Section 7.5.3. 2467 To quantify the probability of success, let N be the number of 2468 attack packets the attacker is willing to send, W be the relevant 2469 sequence window width, and L be the length of sequence numbers (24 2470 or 48). The attacker's best strategy is to space the attack packets 2471 evenly over sequence space. Then the probability of hitting one 2472 sequence number window is P = WN/2^L. 2474 The success probability for a DCCP-Data attack using short sequence 2475 numbers thus equals P = WN/2^24. For W = 100, then, the attacker 2476 must send more than 83,000 packets to achieve a 50% chance of 2477 success. For reference, the easiest TCP attack -- sending a SYN 2478 with a random sequence number, which will cause a connection reset 2479 if it falls within the window -- has W = 8760 (a common default) and 2480 L = 32, and requires more than 245,000 packets to achieve a 50% 2481 chance of success. 2483 A fast connection's W will generally be high, increasing the attack 2484 success probability for fixed N. If this probability gets 2485 uncomfortably high with L = 24, the endpoint SHOULD prevent the use 2486 of short sequence numbers by manipulating the Allow Short Sequence 2487 Numbers feature (see Section 7.6.1). The probability limit depends 2488 on the application, however. Some applications, such as those 2489 already designed to handle corruption, are quite resilient to data 2490 injection attacks. 2492 The DCCP-Sync attack has L = 48, since DCCP-Sync packets use long 2493 sequence numbers exclusively; in addition, the success probability 2494 is halved, since only half the Sequence Number space is valid. 2495 Attacks have a correspondingly smaller probability of success. For 2496 a large W of 2000 packets, then, the attacker must send more than 2497 10^11 packets to achieve a 50% chance of success. 2499 Attacks involving DCCP-Ack, DCCP-DataAck, DCCP-CloseReq, DCCP-Close, 2500 and DCCP-Reset packets are more difficult, since Sequence and 2501 Acknowledgement Numbers must both be guessed. The probability of 2502 attack success for these packet types equals P = WXN/2^(2L), where W 2503 is the Sequence Number window, X is the Acknowledgement Number 2504 window, and N and L are as before. 2506 Since DCCP-Data attacks with short sequence numbers are by far the 2507 easiest for attackers to execute, DCCP has been engineered to 2508 prevent such data injection attacks from escalating to reset attacks 2509 or other, more serious attacks. In particular, any options whose 2510 processing might cause the connection to be reset are ignored when 2511 they appear on DCCP-Data packets. 2513 7.5.6. Examples 2515 In the following example, DCCP A and DCCP B recover from a large 2516 burst of loss that runs DCCP A's sequence numbers out of DCCP B's 2517 appropriate sequence number window. 2519 DCCP A DCCP B 2520 (GSS=1,GSR=10) (GSS=10,GSR=1) 2521 --> DCCP-Data(seq 2) XXX 2522 ... 2523 --> DCCP-Data(seq 100) XXX 2524 --> DCCP-Data(seq 101) --> ??? 2525 seqno out of range; 2526 send Sync 2527 OK <-- DCCP-Sync(seq 11, ack 101) <-- 2528 (GSS=11,GSR=1) 2529 --> DCCP-SyncAck(seq 102, ack 11) --> OK 2530 (GSS=102,GSR=11) (GSS=11,GSR=102) 2532 In the next example, a DCCP connection recovers from a simple blind 2533 attack. 2535 DCCP A DCCP B 2536 (GSS=1,GSR=10) (GSS=10,GSR=1) 2537 *ATTACKER* --> DCCP-Data(seq 10^6) --> ??? 2538 seqno out of range; 2539 send Sync 2540 ??? <-- DCCP-Sync(seq 11, ack 10^6) <-- 2541 ackno out of range; ignore 2542 (GSS=1,GSR=10) (GSS=11,GSR=1) 2544 The final example demonstrates recovery from a half-open connection. 2546 DCCP A DCCP B 2547 (GSS=1,GSR=10) (GSS=10,GSR=1) 2548 (Crash) 2549 CLOSED OPEN 2550 REQUEST --> DCCP-Request(seq 400) --> ??? 2551 !! <-- DCCP-Sync(seq 11, ack 400) <-- OPEN 2552 REQUEST --> DCCP-Reset(seq 401, ack 11) --> (Abort) 2553 REQUEST CLOSED 2554 REQUEST --> DCCP-Request(seq 402) --> ... 2556 7.6. Short Sequence Numbers 2558 DCCP sequence numbers are 48 bits long. This large sequence space 2559 protects DCCP connections against some blind attacks, such as the 2560 injection of DCCP-Resets into the connection. However, DCCP-Data, 2561 DCCP-Ack, and DCCP-DataAck packets, which make up the body of any 2562 DCCP connection, may reduce header space by transmitting only the 2563 lower 24 bits of the relevant Sequence and Acknowledgement Numbers. 2564 The receiving endpoint will extend these numbers to 48 bits using 2565 the following pseudocode: 2567 procedure Extend_Sequence_Number(S, REF) 2568 /* S is a 24-bit sequence number from the packet header. 2569 REF is the relevant 48-bit reference sequence number: 2570 GSS if S is an Acknowledgement Number, and GSR if S is a 2571 Sequence Number. */ 2572 Set REF_low := low 24 bits of REF 2573 Set REF_hi := high 24 bits of REF 2574 If REF_low (<) S /* circular comparison mod 2^24 */ 2575 && S |<| REF_low, /* conventional, non-circular 2576 comparison */ 2577 Return (((REF_hi + 1) mod 2^24) << 24) | S 2578 Otherwise, 2579 Return (REF_hi << 24) | S 2581 The two different kinds of comparison in the if statement detect 2582 when the low-order bits of the sequence space have wrapped. (The 2583 circular comparison "REF_low (<) S" returns true if and only if 2584 (S - REF_low), calculated using two's-complement arithmetic and then 2585 represented as an unsigned number, is less than or equal to 2^23 2586 (mod 2^24).) When this happens, the high-order bits are 2587 incremented. 2589 7.6.1. Allow Short Sequence Numbers Feature 2591 Endpoints can require that all packets use long sequence numbers by 2592 setting the Allow Short Sequence Numbers feature to false. This can 2593 reduce the risk that data will be inappropriately injected into the 2594 connection. DCCP A sends a "Change R(Allow Short Seqnos, 0)" option 2595 to ask DCCP B to send only long sequence numbers. 2597 Allow Short Sequence Numbers has feature number 2, and is server- 2598 priority. It takes one-byte Boolean values. DCCP B MUST NOT send 2599 packets with short sequence numbers when Allow Short Seqnos/B is 2600 zero. Values of two or more are reserved. New connections start 2601 with Allow Short Sequence Numbers 1 for both endpoints. 2603 7.6.2. When to Avoid Short Sequence Numbers 2605 Short sequence numbers reduce the rate DCCP connections can safely 2606 achieve, and increase the risks of certain kinds of attacks, 2607 including blind data injection. Very-high-rate DCCP connections, 2608 and connections with large sequence windows (Section 7.5.2), SHOULD 2609 NOT use short sequence numbers on their data packets. The attack 2610 risk issues have been discussed in Section 7.5.5; we discuss the 2611 rate limitation issue here. 2613 The sequence-validity mechanism assumes that the network does not 2614 deliver extremely old data. In particular, it assumes that the 2615 network must have dropped any packet by the time the connection 2616 wraps around and uses its sequence number again. This constraint 2617 limits the maximum connection rate that can be safely achieved. Let 2618 MSL equal the maximum segment lifetime, P equal the average DCCP 2619 packet size in bits, and L equal the length of sequence numbers (24 2620 or 48 bits). Then the maximum safe rate, in bits per second, is R = 2621 P*(2^L)/2MSL. 2623 For the default MSL of 2 minutes, 1500-byte DCCP packets, and short 2624 sequence numbers, the safe rate is therefore approximately 800 Mb/s. 2625 Although 2 minutes is a very large MSL for any networks that could 2626 sustain that rate with such small packets, long sequence numbers 2627 allow much higher rates under the same constraints: up to 2628 14 petabits a second for 1500-byte packets and the default MSL. 2630 7.7. NDP Count and Detecting Application Loss 2632 DCCP's sequence numbers increment by one on every packet, including 2633 non-data packets (packets that don't carry application data). This 2634 makes DCCP sequence numbers suitable for detecting any network loss, 2635 but not for detecting the loss of application data. The NDP Count 2636 option reports the length of each burst of non-data packets. This 2637 lets the receiving DCCP reliably determine when a burst of loss 2638 included application data. 2640 +--------+--------+-------- ... --------+ 2641 |00100101| Length | NDP Count | 2642 +--------+--------+-------- ... --------+ 2643 Type=37 Len=3-5 (1-3 bytes) 2645 If a DCCP endpoint's Send NDP Count feature is one (see below), then 2646 that endpoint MUST send an NDP Count option on every packet whose 2647 immediate predecessor was a non-data packet. Non-data packets 2648 consist of DCCP packet types DCCP-Ack, DCCP-Close, DCCP-CloseReq, 2649 DCCP-Reset, DCCP-Sync, and DCCP-SyncAck. The other packet types, 2650 namely DCCP-Request, DCCP-Response, DCCP-Data, and DCCP-DataAck, are 2651 considered data packets, although not all DCCP-Request and DCCP- 2652 Response packets will actually carry application data. 2654 The value stored in NDP Count equals the number of consecutive non- 2655 data packets in the run immediately previous to the current packet. 2656 Packets with no NDP Count option are considered to have NDP Count 2657 zero. 2659 The NDP Count option can carry one to three bytes of data. The 2660 smallest option format that can hold the NDP Count SHOULD be used. 2662 With NDP Count, the receiver can reliably tell only whether a burst 2663 of loss contained at least one data packet. For example, the 2664 receiver cannot always tell whether a burst of loss contained a non- 2665 data packet. 2667 7.7.1. Usage Notes 2669 Say that K consecutive sequence numbers are missing in some burst of 2670 loss, and the Send NDP Count feature is on. Then some application 2671 data was lost within those sequence numbers unless the packet 2672 following the hole contains an NDP Count option whose value is 2673 greater than or equal to K. 2675 For example, say that an endpoint sent the following sequence of 2676 non-data packets (Nx) and data packets (Dx). 2678 N0 N1 D2 N3 D4 D5 N6 D7 D8 D9 D10 N11 N12 D13 2680 Those packets would have NDP Counts as follows. 2682 N0 N1 D2 N3 D4 D5 N6 D7 D8 D9 D10 N11 N12 D13 2683 - 1 2 - 1 - - 1 - - - - 1 2 2685 NDP Count is not useful for applications that include their own 2686 sequence numbers with their packet headers. 2688 7.7.2. Send NDP Count Feature 2690 The Send NDP Count feature lets DCCP endpoints negotiate whether 2691 they should send NDP Count options on their packets. DCCP A sends a 2692 "Change R(Send NDP Count, 1)" option to ask DCCP B to send NDP Count 2693 options. 2695 Send NDP Count has feature number 7, and is server-priority. It 2696 takes one-byte Boolean values. DCCP B MUST send NDP Count options 2697 as described above when Send NDP Count/B is one, although it MAY 2698 send NDP Count options even when Send NDP Count/B is zero. Values 2699 of two or more are reserved. New connections start with Send NDP 2700 Count 0 for both endpoints. 2702 8. Event Processing 2704 This section describes how DCCP connections move between states, and 2705 which packets are sent when. Note that feature negotiation takes 2706 place in parallel with the connection-wide state transitions 2707 described here. 2709 8.1. Connection Establishment 2711 DCCP connections' initiation phase consists of a three-way 2712 handshake: an initial DCCP-Request packet sent by the client, a 2713 DCCP-Response sent by the server in reply, and finally an 2714 acknowledgement from the client, usually via a DCCP-Ack or DCCP- 2715 DataAck packet. The client moves from the REQUEST state to 2716 PARTOPEN, and finally to OPEN; the server moves from LISTEN to 2717 RESPOND, and finally to OPEN. 2719 Client State Server State 2720 CLOSED LISTEN 2721 1. REQUEST --> Request --> 2722 2. <-- Response <-- RESPOND 2723 3. PARTOPEN --> Ack, DataAck --> 2724 4. <-- Data, Ack, DataAck <-- OPEN 2725 5. OPEN <-> Data, Ack, DataAck <-> OPEN 2727 8.1.1. Client Request 2729 When a client decides to initiate a connection, it enters the 2730 REQUEST state, chooses an initial sequence number (Section 7.2), and 2731 sends a DCCP-Request packet using that sequence number to the 2732 intended server. 2734 DCCP-Request packets will commonly carry feature negotiation options 2735 that open negotiations for various connection parameters, such as 2736 preferred congestion control IDs for each half-connection. They may 2737 also carry application data, but the client should be aware that the 2738 server may not accept such data. 2740 A client in the REQUEST state SHOULD send use an exponential-backoff 2741 timer to send new DCCP-Request packets if no response is received. 2742 The first retransmission should occur after approximately one 2743 second, backing off to not less than one packet every 64 seconds; or 2744 the endpoint can use whatever retransmission strategy is followed 2745 for retransmitting TCP SYNs. Each new DCCP-Request MUST increment 2746 the Sequence Number by one, and MUST contain the same Service Code 2747 and application data as the original DCCP-Request. 2749 A client MAY give up on its DCCP-Requests after some time 2750 (3 minutes, for example). When it does, it SHOULD send a DCCP-Reset 2751 packet to the server with Reset Code 2, "Aborted", to clean up state 2752 in case one or more of the Requests actually arrived. A client in 2753 REQUEST state has never received an initial sequence number from its 2754 peer, so the DCCP-Reset's Acknowledgement Number MUST be set to 2755 zero. 2757 The client leaves the REQUEST state for PARTOPEN when it receives a 2758 DCCP-Response from the server. 2760 8.1.2. Service Codes 2762 Each DCCP-Request contains a 32-bit Service Code, which identifies 2763 the application-level service to which the client application is 2764 trying to connect. Service Codes should correspond to application 2765 services and protocols. For example, there might be a Service Code 2766 for SIP control connections and one for RTP audio connections. 2767 Middleboxes, such as firewalls, can use the Service Code to identify 2768 the application running on a nonstandard port (assuming the DCCP 2769 header has not been encrypted). 2771 Endpoints MUST associate a Service Code with every DCCP socket, both 2772 actively and passively opened. The application will generally 2773 supply this Service Code. Each active socket MUST have exactly one 2774 Service Code. Passive sockets MAY, at the implementation's 2775 discretion, be associated with more than one Service Code; this 2776 might let multiple applications, or multiple versions of the same 2777 application, listen on the same port, differentiated by Service 2778 Code. If the DCCP-Request's Service Code doesn't match any of the 2779 server's Service Codes for the given port, the server MUST reject 2780 the request by sending a DCCP-Reset packet with Reset Code 8, "Bad 2781 Service Code". A middlebox MAY also send such a DCCP-Reset in 2782 response to packets whose Service Code is considered unsuitable. 2784 Service Codes are not intended to be DCCP-specific, and are 2785 allocated by IANA. Following the policies outlined in [RFC 2434], 2786 most Service Codes are allocated First Come First Served, subject to 2787 the following guidelines. 2789 o Service Codes are allocated one at a time, or in small blocks. A 2790 short English description of the intended service is REQUIRED to 2791 obtain a Service Code assignment, but no specification, 2792 standards-track or otherwise, is necessary. IANA maintains an 2793 association of Service Codes to the corresponding phrases. 2795 o Users request specific Service Code values. We suggest that 2796 users request Service Codes that can be interpreted as meaningful 2797 four-byte ASCII strings. Thus, the "Frobodyne Plotz Protocol" 2798 might correspond to "fdpz", or the number 1717858426. The 2799 canonical interpretation of a Service Code field is numeric. 2801 o Service Codes whose bytes each have values in the set {32, 45-57, 2802 65-90} use a Specification Required allocation policy. That is, 2803 these Service Codes are used for international standard or 2804 standards-track specifications, IETF or otherwise. (This set 2805 consists of the ASCII digits, uppercase letters, and characters 2806 space, '-', '.', and '/'.) 2808 o Service Codes whose high-order byte equals 63 (ASCII '?') are 2809 reserved for Private Use. 2811 o Service Code 0 represents the absence of a meaningful Service 2812 Code, and MUST never be allocated. 2814 This design for Service Code allocation is based on the allocation 2815 of 4-byte identifiers for Macintosh resources, PNG chunks, and 2816 TrueType and OpenType tables. 2818 8.1.3. Server Response 2820 In the second phase of the three-way handshake, the server moves 2821 from the LISTEN state to RESPOND, and sends a DCCP-Response message 2822 to the client. In this phase, a server will often specify the 2823 features it would like to use, either from among those the client 2824 requested, or in addition to those. Among these options is the 2825 congestion control mechanism the server expects to use. 2827 The server MAY respond to a DCCP-Request packet with a DCCP-Reset 2828 packet to refuse the connection. Relevant Reset Codes for refusing 2829 a connection include 7, "Connection Refused", when the DCCP- 2830 Request's Destination Port did not correspond to a DCCP port open 2831 for listening; 8, "Bad Service Code", when the DCCP-Request's 2832 Service Code did not correspond to the service code registered with 2833 the Destination Port; and 9, "Too Busy", when the server is 2834 currently too busy to respond to requests. The server SHOULD limit 2835 the rate at which it generates these resets, for example to not more 2836 than 1024 per second. 2838 The server SHOULD NOT retransmit DCCP-Response packets; the client 2839 will retransmit the DCCP-Request if necessary. (Note that the 2840 "retransmitted" DCCP-Request will have, at least, a different 2841 sequence number from the "original" DCCP-Request. The server can 2842 thus distinguish true retransmissions from network duplicates.) The 2843 server will detect that the retransmitted DCCP-Request applies to an 2844 existing connection because of its Source and Destination Ports. 2845 Every valid DCCP-Request received while the server is in the RESPOND 2846 state MUST elicit a new DCCP-Response. Each new DCCP-Response MUST 2847 increment the server's Sequence Number by one, and MUST include the 2848 same application data, if any, as the original DCCP-Response. 2850 The server MUST NOT accept more than one piece of DCCP-Request 2851 application data per connection. In particular, the DCCP-Response 2852 sent in reply to a retransmitted DCCP-Request with application data 2853 SHOULD contain a Data Dropped option, in which the retransmitted 2854 DCCP-Request data is reported with Drop Code 0, Protocol 2855 Constraints. The original DCCP-Request SHOULD also be reported in 2856 the Data Dropped option, either in a Normal Block (if the server 2857 accepted the data, or there was no data), or in a Drop Code 0 Drop 2858 Block (if the server refused the data the first time as well). 2860 The Data Dropped and Init Cookie options are particularly useful for 2861 DCCP-Response packets (Sections 11.7 and 8.1.4). 2863 The server leaves the RESPOND state for OPEN when it receives a 2864 valid DCCP-Ack from the client, completing the three-way handshake. 2865 It MAY also leave the RESPOND state for CLOSED after a timeout of 2866 not less than 4MSL (8 minutes); when doing so, it SHOULD send a 2867 DCCP-Reset with Reset Code 2, "Aborted", to clean up state at the 2868 client. 2870 8.1.4. Init Cookie Option 2872 +--------+--------+--------+--------+--------+-------- 2873 |00100100| Length | Init Cookie Value ... 2874 +--------+--------+--------+--------+--------+-------- 2875 Type=36 2877 The Init Cookie option lets a DCCP server avoid having to hold any 2878 state until the three-way connection setup handshake has completed, 2879 in a similar fashion as TCP SYN cookies [SYNCOOKIES]. The server 2880 wraps up the Service Code, server port, and any options it cares 2881 about from both the DCCP-Request and DCCP-Response in an opaque 2882 cookie. Typically the cookie will be encrypted using a secret known 2883 only to the server and include a cryptographic checksum or magic 2884 value so that correct decryption can be verified. When the server 2885 receives the cookie back in the response, it can decrypt the cookie 2886 and instantiate all the state it avoided keeping. In the meantime, 2887 it need not move from the LISTEN state. 2889 The Init Cookie option MUST NOT be sent on DCCP-Request or DCCP-Data 2890 packets, and any such options received on DCCP-Request or DCCP-Data 2891 packets MUST be ignored. The server MAY include an Init Cookie 2892 option in its DCCP-Response. If so, then the client MUST echo the 2893 same Init Cookie option in each succeeding DCCP packet until one of 2894 those packets is acknowledged, meaning the three-way handshake has 2895 completed, or the connection is reset. (As a result, the client 2896 MUST NOT use DCCP-Data packets until the three-way handshake 2897 completes or the connection is reset.) The server SHOULD design its 2898 Init Cookie format so that Init Cookies can be checked for 2899 tampering; it SHOULD respond to a tampered Init Cookie option by 2900 resetting the connection with Reset Code 10, "Bad Init Cookie". 2902 The precise implementation of the Init Cookie does not need to be 2903 specified here; since Init Cookies are opaque to the client, there 2904 are no interoperability concerns. 2906 Init Cookies are limited to at most 253 bytes in length. 2908 8.1.5. Handshake Completion 2910 When the client receives a DCCP-Response from the server, it moves 2911 from the REQUEST state to PARTOPEN and completes the three-way 2912 handshake by sending a DCCP-Ack packet to the server. The client 2913 remains in PARTOPEN until it can be sure that the server has 2914 received some packet the client sent from PARTOPEN (either the 2915 initial DCCP-Ack or a later packet). Clients in the PARTOPEN state 2916 that want to send data MUST do so using DCCP-DataAck packets, not 2917 DCCP-Data packets. This is because DCCP-Data packets lack 2918 Acknowledgement Numbers, so the server can't tell from a DCCP-Data 2919 packet whether the client saw its DCCP-Response. Furthermore, if 2920 the DCCP-Response included an Init Cookie, that Init Cookie MUST be 2921 included on every packet sent in PARTOPEN. 2923 The single DCCP-Ack sent when entering the PARTOPEN state might, of 2924 course, be dropped by the network. The client SHOULD ensure that 2925 some packet gets through eventually. The preferred mechanism would 2926 be a roughly 200-millisecond timer, set every time a packet is 2927 transmitted in PARTOPEN. If this timer goes off and the client is 2928 still in PARTOPEN, the client generates another DCCP-Ack and backs 2929 off the timer. If the client remains in PARTOPEN for more than 4MSL 2930 (8 minutes), it SHOULD reset the connection with Reset Code 2, 2931 "Aborted". 2933 The client leaves the PARTOPEN state for OPEN when it receives a 2934 valid packet other than DCCP-Response, DCCP-Reset, or DCCP-Sync from 2935 the server. 2937 8.2. Data Transfer 2939 In the central data transfer phase of the connection, both server 2940 and client are in the OPEN state. 2942 DCCP A sends DCCP-Data and DCCP-DataAck packets to DCCP B due to 2943 application events on host A. These packets are congestion- 2944 controlled by the CCID for the A-to-B half-connection. In contrast, 2945 DCCP-Ack packets sent by DCCP A are controlled by the CCID for the 2946 B-to-A half-connection. Generally, DCCP A will piggyback 2947 acknowledgement information on DCCP-Data packets when acceptable, 2948 creating DCCP-DataAck packets. DCCP-Ack packets are used when there 2949 is no data to send from DCCP A to DCCP B, or when the congestion 2950 state of the A-to-B CCID will not allow data to be sent. 2952 DCCP-Sync and DCCP-SyncAck packets may also occur in the data 2953 transfer phase. Some cases causing DCCP-Sync generation are 2954 discussed in Section 7.5. One important distinction between DCCP- 2955 Sync packets and other packet types is that DCCP-Sync elicits an 2956 immediate acknowledgement. On receiving a valid DCCP-Sync packet, a 2957 DCCP endpoint MUST immediately generate and send a DCCP-SyncAck 2958 response (subject to any implementation rate limits); the 2959 Acknowledgement Number on that DCCP-SyncAck MUST equal the Sequence 2960 Number of the DCCP-Sync. 2962 A particular DCCP implementation might decide to initiate feature 2963 negotiation only once the OPEN state was reached, in which case it 2964 might not allow data transfer until some time later. Data received 2965 during that time SHOULD be rejected and reported using a Data 2966 Dropped Drop Block with Drop Code 0, Protocol Constraints (see 2967 Section 11.7). 2969 8.3. Termination 2971 DCCP connection termination uses a handshake consisting of an 2972 optional DCCP-CloseReq packet, a DCCP-Close packet, and a DCCP-Reset 2973 packet. The server moves from the OPEN state, possibly through the 2974 CLOSEREQ state, to CLOSED; the client moves from OPEN through 2975 CLOSING to TIMEWAIT, and after 2MSL wait time (4 minutes), to 2976 CLOSED. 2978 The sequence DCCP-CloseReq, DCCP-Close, DCCP-Reset is used when the 2979 server decides to close the connection, but doesn't want to hold 2980 TIMEWAIT state: 2982 Client State Server State 2983 OPEN OPEN 2984 1. <-- CloseReq <-- CLOSEREQ 2985 2. CLOSING --> Close --> 2986 3. <-- Reset <-- CLOSED (LISTEN) 2987 4. TIMEWAIT 2988 5. CLOSED 2990 A shorter sequence occurs when the client decides to close the 2991 connection. 2993 Client State Server State 2994 OPEN OPEN 2995 1. CLOSING --> Close --> 2996 2. <-- Reset <-- CLOSED (LISTEN) 2997 3. TIMEWAIT 2998 4. CLOSED 3000 Finally, the server can decide to hold TIMEWAIT state: 3002 Client State Server State 3003 OPEN OPEN 3004 1. <-- Close <-- CLOSING 3005 2. CLOSED --> Reset --> 3006 3. TIMEWAIT 3007 4. CLOSED (LISTEN) 3009 In all cases, the receiver of the DCCP-Reset packet holds TIMEWAIT 3010 state for the connection. As in TCP, TIMEWAIT state, where an 3011 endpoint quietly preserves a socket for 2MSL (4 minutes) after its 3012 connection has closed, ensures that no connection duplicating the 3013 current connection's source and destination addresses and ports can 3014 start up while old packets might remain in the network. 3016 The termination handshake proceeds as follows. The receiver of a 3017 valid DCCP-CloseReq packet MUST respond with a DCCP-Close packet. 3018 The receiver of a valid DCCP-Close packet MUST respond with a DCCP- 3019 Reset packet, with Reset Code 1, "Closed". The receiver of a valid 3020 DCCP-Reset packet -- which is also the sender of the DCCP-Close 3021 packet and the receiver of any DCCP-CloseReq packet -- will hold 3022 TIMEWAIT state for the connection. 3024 A DCCP-Reset packet completes every DCCP connection, whether the 3025 termination is clean (due to application close; Reset Code 1, 3026 "Closed") or unclean. Unlike TCP, which has two distinct 3027 termination mechanisms (FIN and RST), DCCP ends all connections in a 3028 uniform manner. This is justified because some aspects of 3029 connection termination are the same independent of whether 3030 termination was clean. For instance, the endpoint that receives a 3031 valid DCCP-Reset SHOULD hold TIMEWAIT state for the connection. 3032 Processors that must distinguish between clean and unclean 3033 termination can examine the Reset Code. DCCP-Reset packets MUST NOT 3034 be generated in response to received DCCP-Reset packets. DCCP 3035 implementations generally transition to the CLOSED state after 3036 sending a DCCP-Reset packet. 3038 Endpoints in the CLOSEREQ and CLOSING states MUST retransmit DCCP- 3039 CloseReq and DCCP-Close packets, respectively, until leaving those 3040 states. The retransmission timer should initially be set to go off 3041 in two round-trip times, and should back off to not less than once 3042 every 64 seconds if no relevant response is received. 3044 Only the server can send a DCCP-CloseReq packet or enter the 3045 CLOSEREQ state. A server receiving a sequence-valid DCCP-CloseReq 3046 packet MUST respond with a DCCP-Sync packet, and otherwise ignore 3047 the DCCP-CloseReq. 3049 DCCP-Data, DCCP-DataAck, and DCCP-Ack packets received in CLOSEREQ 3050 or CLOSE states MAY be either processed or ignored. 3052 8.3.1. Abnormal Termination 3054 DCCP endpoints generate DCCP-Reset packets to terminate connections 3055 abnormally; a DCCP-Reset packet may be generated from any state. 3056 Resets sent in the CLOSED, LISTEN, and TIMEWAIT states use Reset 3057 Code 3, "No Connection", unless otherwise specified. Resets sent in 3058 the REQUEST or RESPOND states use Reset Code 4, "Packet Error", 3059 unless otherwise specified. 3061 DCCP endpoints in CLOSED or LISTEN state may need to generate a 3062 DCCP-Reset packet in response to a packet received from a peer. 3063 Since these states have no associated sequence number variables, the 3064 Sequence and Acknowledgement Numbers on the DCCP-Reset packet R are 3065 taken from the received packet P, as follows. 3067 1. If P.ackno exists, then set R.seqno := P.ackno + 1. Otherwise, 3068 set R.seqno := 0. 3070 2. Set R.ackno := P.seqno. 3072 3. If the packet used short sequence numbers (P.X == 0), then set 3073 the upper 24 bits of R.seqno and R.ackno to 0. 3075 8.4. DCCP State Diagram 3077 The most common state transitions discussed above can be summarized 3078 in the following state diagram. The diagram is illustrative; the 3079 text in Section 8.5 and elsewhere should be considered definitive. 3080 For example, there are arcs (not shown) from every state except 3081 CLOSED to TIMEWAIT, contingent on the receipt of a valid DCCP-Reset. 3083 +---------------------------+ +---------------------------+ 3084 | v v | 3085 | +----------+ | 3086 | +-------------+ CLOSED +------------+ | 3087 | | passive +----------+ active | | 3088 | | open open | | 3089 | | snd Request | | 3090 | v v | 3091 | +----------+ +----------+ | 3092 | | LISTEN | | REQUEST | | 3093 | +----+-----+ +----+-----+ | 3094 | | rcv Request rcv Response | | 3095 | | snd Response snd Ack | | 3096 | v v | 3097 | +----------+ +----------+ | 3098 | | RESPOND | | PARTOPEN | | 3099 | +----+-----+ +----+-----+ | 3100 | | rcv Ack/DataAck rcv packet | | 3101 | | | | 3102 | | +----------+ | | 3103 | +------------>| OPEN |<-----------+ | 3104 | +--+-+--+--+ | 3105 | server active close | | | active close | 3106 | snd CloseReq | | | or rcv CloseReq | 3107 | | | | snd Close | 3108 | | | | | 3109 | +----------+ | | | +----------+ | 3110 | | CLOSEREQ |<---------+ | +--------->| CLOSING | | 3111 | +----+-----+ | +----+-----+ | 3112 | | rcv Close | rcv Reset | | 3113 | | snd Reset | | | 3114 |<---------+ | v | 3115 | | +----+-----+ | 3116 | rcv Close | | TIMEWAIT | | 3117 | snd Reset | +----+-----+ | 3118 +-----------------------------+ | | 3119 +-----------+ 3120 2MSL timer expires 3122 8.5. Pseudocode 3124 This section presents an algorithm describing the processing steps a 3125 DCCP endpoint must go through when it receives a packet. A DCCP 3126 implementation need not implement the algorithm as it is described 3127 here, but any implementation MUST generate observable effects 3128 exactly as indicated by this pseudocode, except where allowed 3129 otherwise by another part of this document. 3131 The received packet is written as P, the socket as S. 3132 Packet variables P.seqno and P.ackno are 48-bit sequence numbers. 3133 Socket variables: 3134 S.SWL - sequence number window low 3135 S.SWH - sequence number window high 3136 S.AWL - acknowledgement number window low 3137 S.AWH - acknowledgement number window high 3138 S.ISS - initial sequence number sent 3139 S.ISR - initial sequence number received 3140 S.OSR - first OPEN sequence number received 3141 S.GSS - greatest sequence number sent 3142 S.GSR - greatest valid sequence number received 3143 S.GAR - greatest valid acknowledgement number received on a 3144 non-Sync; initialized to S.ISS 3145 "Send packet" actions always use, and increment, S.GSS. 3147 Step 1: Check header basics 3148 /* This step checks for malformed packets. Packets that fail 3149 these checks are ignored -- they do not receive Resets in 3150 response */ 3151 If the packet is shorter than 12 bytes, drop packet and return 3152 If the packet type is not understood, drop packet and return 3153 If P.Data Offset is too small for packet type, or too large for 3154 packet, drop packet and return 3155 If P.type is not Data, Ack, or DataAck and P.X == 0 (the packet 3156 has short sequence numbers), drop packet and return 3157 If the header checksum is incorrect, drop packet and return 3158 If P.CsCov is too large for the packet size, drop packet and 3159 return 3161 Step 2: Check ports and process TIMEWAIT state 3162 Look up flow ID in table and get corresponding socket 3163 If no socket, or S.state == TIMEWAIT, 3164 Generate Reset(No Connection) unless P.type == Reset 3165 Drop packet and return 3167 Step 3: Process LISTEN state 3168 If S.state == LISTEN, 3169 If P.type == Request or P contains a valid Init Cookie option, 3170 /* Must scan the packet's options to check for an Init 3171 Cookie. Only the Init Cookie is processed here, 3172 however; other options are processed in Step 8. This 3173 scan need only be performed if the endpoint uses Init 3174 Cookies */ 3175 /* Generate a new socket and switch to that socket */ 3176 Set S := new socket for this port pair 3177 S.state = RESPOND 3178 Choose S.ISS (initial seqno) or set from Init Cookie 3179 Set S.ISR, S.GSR, S.SWL, S.SWH from packet or Init Cookie 3180 Continue with S.state == RESPOND 3181 /* A Response packet will be generated in Step 11 */ 3182 Otherwise, 3183 Generate Reset(No Connection) unless P.type == Reset 3184 Drop packet and return 3186 Step 4: Prepare sequence numbers in REQUEST 3187 If S.state == REQUEST, 3188 If (P.type == Response or P.type == Reset) 3189 and S.AWL <= P.ackno <= S.AWH, 3190 /* Set sequence number variables corresponding to the 3191 other endpoint, so P will pass the tests in Step 6 */ 3192 Set S.GSR, S.ISR, S.SWL, S.SWH 3193 /* Response processing continues in Step 10; Reset 3194 processing continues in Step 9 */ 3195 Otherwise, 3196 /* Only Response and Reset are valid in REQUEST state */ 3197 Generate Reset(Packet Error) 3198 Drop packet and return 3200 Step 5: Prepare sequence numbers for Sync 3201 If P.type == Sync or P.type == SyncAck, 3202 If S.AWL <= P.ackno <= S.AWH and P.seqno >= S.SWL, 3203 /* P is valid, so update sequence number variables 3204 accordingly. After this update, P will pass the tests 3205 in Step 6. A SyncAck is generated if necessary in 3206 Step 15 */ 3207 Update S.GSR, S.SWL, S.SWH 3208 Otherwise, 3209 Drop packet and return 3211 Step 6: Check sequence numbers 3212 Let LSWL = S.SWL and LAWL = S.AWL 3213 If P.type == CloseReq or P.type == Close or P.type == Reset, 3214 LSWL := S.GSR + 1, LAWL := S.GAR 3215 If LSWL <= P.seqno <= S.SWH 3216 and (P.ackno does not exist or LAWL <= P.ackno <= S.AWH), 3217 Update S.GSR, S.SWL, S.SWH 3218 If P.type != Sync, 3219 Update S.GAR 3220 Otherwise, 3221 Send Sync packet acknowledging P.seqno 3222 Drop packet and return 3224 Step 7: Check for unexpected packet types 3225 If (S.is_server and P.type == CloseReq) 3226 or (S.is_server and P.type == Response) 3227 or (S.is_client and P.type == Request) 3228 or (S.state >= OPEN and P.type == Request 3229 and P.seqno >= S.OSR) 3230 or (S.state >= OPEN and P.type == Response 3231 and P.seqno >= S.OSR) 3232 or (S.state == RESPOND and P.type == Data), 3233 Send Sync packet acknowledging P.seqno 3234 Drop packet and return 3236 Step 8: Process options and mark acknowledgeable 3237 /* Option processing is not specifically described here. 3238 Certain options, such as Mandatory, may cause the connection 3239 to be reset, in which case Steps 9 and on are not executed */ 3240 Mark packet as acknowledgeable (in Ack Vector terms, Received 3241 or Received ECN Marked) 3243 Step 9: Process Reset 3244 If P.type == Reset, 3245 Tear down connection 3246 S.state := TIMEWAIT 3247 Set TIMEWAIT timer 3248 Drop packet and return 3250 Step 10: Process REQUEST state (second part) 3251 If S.state == REQUEST, 3252 /* If we get here, P is a valid Response from the server (see 3253 Step 4), and we should move to PARTOPEN state. PARTOPEN 3254 means send an Ack, don't send Data packets, retransmit 3255 Acks periodically, and always include any Init Cookie from 3256 the Response */ 3257 S.state := PARTOPEN 3258 Set PARTOPEN timer 3259 Continue with S.state == PARTOPEN 3260 /* Step 12 will send the Ack completing the three-way 3261 handshake */ 3263 Step 11: Process RESPOND state 3264 If S.state == RESPOND, 3265 If P.type == Request, 3266 Send Response, possibly containing Init Cookie 3267 If Init Cookie was sent, 3268 Destroy S and return 3269 /* Step 3 will create another socket when the client 3270 completes the three-way handshake */ 3271 Otherwise, 3272 S.OSR := P.seqno 3273 S.state := OPEN 3275 Step 12: Process PARTOPEN state 3276 If S.state == PARTOPEN, 3277 If P.type == Response, 3278 Send Ack 3279 Otherwise, if P.type != Sync, 3280 S.OSR := P.seqno 3281 S.state := OPEN 3283 Step 13: Process CloseReq 3284 If P.type == CloseReq and S.state < CLOSEREQ, 3285 Generate Close 3286 S.state := CLOSING 3287 Set CLOSING timer 3289 Step 14: Process Close 3290 If P.type == Close, 3291 Generate Reset(Closed) 3292 Tear down connection 3293 Drop packet and return 3295 Step 15: Process Sync 3296 If P.type == Sync, 3297 Generate SyncAck 3299 Step 16: Process data 3300 /* At this point any application data on P can be passed to the 3301 application, except that the application MUST NOT receive 3302 data from more than one Request or Response */ 3304 9. Checksums 3306 DCCP uses a header checksum to protect its header against 3307 corruption. Generally, this checksum also covers any application 3308 data. DCCP applications can, however, request that the header 3309 checksum cover only part of the application data, or perhaps no 3310 application data at all. Link layers may then reduce their 3311 protection on unprotected parts of DCCP packets. For some noisy 3312 links, and applications that can tolerate corruption, this can 3313 greatly improve delivery rates and perceived performance. 3315 Checksum coverage may eventually impact congestion control 3316 mechanisms as well. A packet with corrupt application data and 3317 complete checksum coverage is treated as lost. This incurs a heavy- 3318 duty loss response from the sender's congestion control mechanism, 3319 which can unfairly penalize connections on links with high 3320 background corruption. The combination of reduced checksum coverage 3321 and Data Checksum options may let endpoints report packets as 3322 corrupt rather than dropped, using Data Dropped options and Drop 3323 Code 3 (see Section 11.7). This may eventually benefit 3324 applications. However, further research is required to determine an 3325 appropriate response to corruption, which can sometimes correlate 3326 with congestion. Corrupt packets currently incur a loss response. 3328 The Data Checksum option, which contains a strong CRC, lets 3329 endpoints detect application data corruption. An API can then be 3330 used to avoid delivering corrupt data to the application, even if 3331 links deliver corrupt data to the endpoint due to reduced checksum 3332 coverage. However, the use of reduced checksum coverage for 3333 applications that demand correct data is currently considered 3334 experimental. This is because the combined loss-plus-corruption 3335 rate for packets with reduced checksum coverage may be significantly 3336 higher than that for packets with full checksum coverage, although 3337 the loss rate will generally be lower. Actual behavior will depend 3338 on link design; further research and experience is required. 3340 Reduced checksum coverage introduces some security considerations; 3341 see Section 18.1. See Appendix B.1 for further motivation and 3342 discussion. DCCP's implementation of reduced checksum coverage was 3343 inspired by UDP-Lite [RFC 3828]. 3345 9.1. Header Checksum Field 3347 DCCP uses the TCP/IP checksum algorithm. The Checksum field in the 3348 DCCP generic header (see Section 5.1) equals the 16 bit one's 3349 complement of the one's complement sum of all 16 bit words in the 3350 DCCP header, DCCP options, a pseudoheader taken from the network- 3351 layer header, and, depending on the value of the Checksum Coverage 3352 field, some or all of the application data. When calculating the 3353 checksum, the Checksum field itself is treated as 0. If a packet 3354 contains an odd number of header and payload bytes to be 3355 checksummed, 8 zero bits are added on the right to form a 16 bit 3356 word for checksum purposes. The pad byte is not transmitted as part 3357 of the packet. 3359 The pseudoheader is calculated as for TCP. For IPv4, it is 96 bits 3360 long, and consists of the IPv4 source and destination addresses, the 3361 IP protocol number for DCCP (padded on the left with 8 zero bits), 3362 and the DCCP length as a 16-bit quantity (the length of the DCCP 3363 header with options, plus the length of any data); see Section 3.1 3364 of [RFC 793]. For IPv6, it is 320 bits long, and consists of the 3365 IPv6 source and destination addresses, the DCCP length as a 32-bit 3366 quantity, and the IP protocol number for DCCP (padded on the left 3367 with 24 zero bits); see Section 8.1 of [RFC 2460]. 3369 Packets with invalid header checksums MUST be ignored. In 3370 particular, their options MUST NOT be processed. 3372 9.2. Header Checksum Coverage Field 3374 The Checksum Coverage field in the DCCP generic header (see Section 3375 5.1) specifies what parts of the packet are covered by the Checksum 3376 field, as follows: 3378 CsCov = 0 The Checksum field covers the DCCP header, DCCP 3379 options, network-layer pseudoheader, and all 3380 application data in the packet, possibly padded on 3381 the right with zeros to an even number of bytes. 3383 CsCov = 1-15 The Checksum field covers the DCCP header, DCCP 3384 options, network-layer pseudoheader, and the initial 3385 (CsCov-1)*4 bytes of the packet's application data. 3387 Thus, if CsCov is 1, none of the application data is protected by 3388 the header checksum. The value (CsCov-1)*4 MUST be less than or 3389 equal to the length of the application data. Packets with invalid 3390 CsCov values MUST be ignored; in particular, their options MUST NOT 3391 be processed. The meanings of values other than 0 and 1 should be 3392 considered experimental. 3394 Values other than 0 specify that corruption is acceptable in some or 3395 all of the DCCP packet's application data. In fact, DCCP cannot 3396 even detect corruption in areas not covered by the header checksum, 3397 unless the Data Checksum option is used. Applications should not 3398 make any assumptions about the correctness of received data not 3399 covered by the checksum, and should if necessary introduce their own 3400 validity checks. 3402 A DCCP application interface should let sending applications suggest 3403 a value for CsCov for sent packets, defaulting to 0 (full coverage). 3404 The Minimum Checksum Coverage feature, described below, lets an 3405 endpoint refuse delivery of application data on packets with partial 3406 checksum coverage; by default, only fully-covered application data 3407 is accepted. Lower layers that support partial error detection MAY 3408 use the Checksum Coverage field as a hint of where errors do not 3409 need to be detected. Lower layers MUST use a strong error detection 3410 mechanism to detect at least errors that occur in the sensitive part 3411 of the packet, and discard damaged packets. The sensitive part 3412 consists of the bytes between the first byte of the IP header and 3413 the last byte identified by Checksum Coverage. 3415 For more details on application and lower-layer interface issues 3416 relating to partial checksumming, see [RFC 3828]. 3418 9.2.1. Minimum Checksum Coverage Feature 3420 The Minimum Checksum Coverage feature lets a DCCP endpoint determine 3421 whether its peer is willing to accept packets with reduced Checksum 3422 Coverage. For example, DCCP A sends a "Change R(Minimum Checksum 3423 Coverage, 1)" option to DCCP B to check whether B is willing to 3424 accept packets with Checksum Coverage set to 1. 3426 Minimum Checksum Coverage has feature number 8, and is server- 3427 priority. It takes one-byte integer values between 0 and 15; values 3428 of 16 or more are reserved. Minimum Checksum Coverage/B reflects 3429 values of Checksum Coverage that DCCP B finds unacceptable. Say 3430 that the value of Minimum Checksum Coverage/B is MinCsCov. Then: 3432 o If MinCsCov = 0, then DCCP B only finds packets with CsCov = 0 3433 acceptable. 3435 o If MinCsCov > 0, then DCCP B additionally finds packets with 3436 CsCov >= MinCsCov acceptable. 3438 DCCP B MAY refuse to process application data from packets with 3439 unacceptable Checksum Coverage. Such packets SHOULD be reported 3440 using Data Dropped options (Section 11.7) with Drop Code 0, Protocol 3441 Constraints. New connections start with Minimum Checksum Coverage 0 3442 for both endpoints. 3444 9.3. Data Checksum Option 3446 The Data Checksum option holds a 32-bit CRC-32c cyclic redundancy- 3447 check code of a DCCP packet's application data. 3449 +--------+--------+--------+--------+--------+--------+ 3450 |00101100|00000110| CRC-32c | 3451 +--------+--------+--------+--------+--------+--------+ 3452 Type=44 Length=6 3454 The sending DCCP computes the CRC of the bytes comprising the 3455 application data area and stores it in the option data. The CRC-32c 3456 algorithm used for Data Checksum is the same as that used for SCTP 3457 [RFC 3309]; note that the CRC-32c of zero bytes of data equals zero. 3458 The DCCP header checksum will cover the Data Checksum option, so the 3459 data checksum must be computed before the header checksum. 3461 A DCCP endpoint receiving a packet with a Data Checksum option 3462 SHOULD compute the received application data's CRC-32c, using the 3463 same algorithm as the sender, and compare the result with the Data 3464 Checksum value. (The endpoint can indicate its willingness to check 3465 Data Checksums using the Check Data Checksum feature, described 3466 below.) If the CRCs differ, the endpoint reacts in one of two ways. 3468 o The receiving application may have requested delivery of known- 3469 corrupt data via some optional API. In this case, the packet's 3470 data MUST be delivered to the application, with a note that it is 3471 known to be corrupt. Furthermore, the receiving endpoint MUST 3472 report the packet as delivered corrupt using a Data Dropped 3473 option (Drop Code 7, Delivered Corrupt). 3475 o Otherwise, the receiving endpoint MUST drop the application data, 3476 and report that data as dropped due to corruption using a Data 3477 Dropped option (Drop Code 3, Corrupt). 3479 In either case, the packet is considered acknowledgeable (since its 3480 header was processed), and will therefore be acknowledged using the 3481 equivalent of Ack Vector's Received or Received ECN Marked states. 3483 Although Data Checksum is intended for packets containing 3484 application data, it may be included on other packets, such as DCCP- 3485 Ack, DCCP-Sync, and DCCP-SyncAck. The receiver SHOULD calculate the 3486 application data area's CRC-32c on such packets, just as it does for 3487 DCCP-Data and similar packets; and if the CRCs differ, the packets 3488 similarly MUST be reported using Data Dropped options (Drop Code 3), 3489 although their application data areas would not be delivered to the 3490 application in any case. 3492 9.3.1. Check Data Checksum Feature 3494 The Check Data Checksum feature lets a DCCP endpoint determine 3495 whether its peer will definitely check Data Checksum options. 3496 DCCP A sends a Mandatory "Change R(Check Data Checksum, 1)" option 3497 to DCCP B to require it to check Data Checksum options (the 3498 connection will be reset if it cannot). 3500 Check Data Checksum has feature number 9, and is server-priority. 3501 It takes one-byte Boolean values. DCCP B MUST check any received 3502 Data Checksum options when Check Data Checksum/B is one, although it 3503 MAY check them even when Check Data Checksum/B is zero. Values of 3504 two or more are reserved. New connections start with Check Data 3505 Checksum 0 for both endpoints. 3507 9.3.2. Usage Notes 3509 Internet links must normally apply strong integrity checks to the 3510 packets they transmit [RFC 3828] [RFC 3819]. This is the default 3511 case when the DCCP header's Checksum Coverage value equals zero 3512 (full coverage). However, the DCCP Checksum Coverage value might 3513 not be zero. By setting partial Checksum Coverage, the application 3514 indicates that it can tolerate corruption in the unprotected part of 3515 the application data. Recognizing this, link layers may reduce 3516 error detection and/or correction strength when transmitting this 3517 unprotected part. This, in turn, can significantly increase the 3518 likelihood of the endpoint receiving corrupt data; Data Checksum 3519 lets the receiver detect that corruption with very high probability. 3521 10. Congestion Control 3523 Each congestion control mechanism supported by DCCP is assigned a 3524 congestion control identifier, or CCID: a number from 0 to 255. 3525 During connection setup, and optionally thereafter, the endpoints 3526 negotiate their congestion control mechanisms by negotiating the 3527 values for their Congestion Control ID features. Congestion Control 3528 ID has feature number 1. The CCID/A value equals the CCID in use 3529 for the A-to-B half-connection. DCCP B sends a "Change R(CCID, K)" 3530 option to ask DCCP A to use CCID K for its data packets. 3532 CCID is a server-priority feature, so CCID negotiation options can 3533 list multiple acceptable CCIDs, sorted in descending order of 3534 priority. For example, the option "Change R(CCID, 2 3 4)" asks the 3535 receiver to use CCID 2 for its packets, although CCIDs 3 and 4 are 3536 also acceptable. (This corresponds to the bytes "35, 6, 1, 2, 3, 3537 4": Change R option (35), option length (6), feature ID (1), CCIDs 3538 (2, 3, 4).) Similarly, "Confirm L(CCID, 1, 2 3 4)" tells the 3539 receiver that the sender is using CCID 2 for its packets, but that 3540 CCIDs 3 and 4 might also be acceptable. 3542 Currently allocated CCIDs are as follows. 3544 CCID Meaning Reference 3545 ---- ------- --------- 3546 0-1 Reserved 3547 2 TCP-like Congestion Control [RFC TBA] 3548 3 TFRC Congestion Control [RFC TBA] 3549 4-255 Reserved 3551 Table 5: DCCP Congestion Control Identifiers 3553 New connections start with CCID 2 for both endpoints. If this is 3554 unacceptable for a DCCP endpoint, that endpoint MUST send Mandatory 3555 Change(CCID) options on its first packets. 3557 All CCIDs standardized for use with DCCP will correspond to 3558 congestion control mechanisms previously standardized by the IETF. 3559 We expect that for quite some time, all such mechanisms will be TCP- 3560 friendly, but TCP-friendliness is not an explicit DCCP requirement. 3562 A DCCP implementation intended for general use, such as an 3563 implementation in a general-purpose operating system kernel, SHOULD 3564 implement at least CCID 2. The intent is to make CCID 2 broadly 3565 available for interoperability, although particular applications 3566 might disallow its use. 3568 10.1. TCP-like Congestion Control 3570 CCID 2, TCP-like Congestion Control, denotes Additive Increase, 3571 Multiplicative Decrease (AIMD) congestion control with behavior 3572 modelled directly on TCP, including congestion window, slow start, 3573 timeouts, and so forth [RFC 2581]. CCID 2 achieves maximum 3574 bandwidth over the long term, consistent with the use of end-to-end 3575 congestion control, but halves its congestion window in response to 3576 each congestion event. This leads to the abrupt rate changes 3577 typical of TCP. Applications should use CCID 2 if they prefer 3578 maximum bandwidth utilization to steadiness of rate. This is often 3579 the case for applications that are not playing their data directly 3580 to the user. For example, a hypothetical application that 3581 transferred files over DCCP, using application-level retransmissions 3582 for lost packets, would prefer CCID 2 to CCID 3. On-line games may 3583 also prefer CCID 2. 3585 CCID 2 is further described in [CCID 2 PROFILE]. 3587 10.2. TFRC Congestion Control 3589 CCID 3 denotes TCP-Friendly Rate Control (TFRC), an equation-based 3590 rate-controlled congestion control mechanism. TFRC is designed to 3591 be reasonably fair when competing for bandwidth with TCP-like flows, 3592 where a flow is "reasonably fair" if its sending rate is generally 3593 within a factor of two of the sending rate of a TCP flow under the 3594 same conditions. However, TFRC has a much lower variation of 3595 throughput over time compared with TCP, which makes CCID 3 more 3596 suitable than CCID 2 for applications such as telephony or streaming 3597 media where a relatively smooth sending rate is of importance. 3599 CCID 3 is further described in [CCID 3 PROFILE]. The TFRC 3600 congestion control algorithms were initially described in [RFC 3601 3448]. 3603 10.3. CCID-Specific Options, Features, and Reset Codes 3605 Half of the option types, feature numbers, and Reset Codes are 3606 reserved for CCID-specific use. CCIDs may often need new options, 3607 for communicating acknowledgement or rate information, for example; 3608 reserved option spaces let CCIDs create options at will without 3609 polluting the global option space. Option 128 might have different 3610 meanings on a half-connection using CCID 4 and a half-connection 3611 using CCID 8. CCID-specific options and features will never 3612 conflict with global options and features introduced by later 3613 versions of this specification. 3615 Any packet may contain information meant for either half-connection, 3616 so CCID-specific option types, feature numbers, and Reset Codes 3617 explicitly signal the half-connection to which they apply. 3619 o Option numbers 128 through 191 are for options sent from the HC- 3620 Sender to the HC-Receiver; option numbers 192 through 255 are for 3621 options sent from the HC-Receiver to the HC-Sender. 3623 o Reset Codes 128 through 191 indicate that the HC-Sender reset the 3624 connection (most likely because of some problem with 3625 acknowledgements sent by the HC-Receiver); Reset Codes 192 3626 through 255 indicate that the HC-Receiver reset the connection 3627 (most likely because of some problem with data packets sent by 3628 the HC-Sender). 3630 o Finally, feature numbers 128 through 191 are used for features 3631 located at the HC-Sender; feature numbers 192 through 255 are for 3632 features located at the HC-Receiver. Since Change L and 3633 Confirm L options for a feature are sent by the feature location, 3634 we know that any Change L(128) option was sent by the HC-Sender, 3635 while any Change L(192) option was sent by the HC-Receiver. 3636 Similarly, Change R(128) options are sent by the HC-Receiver, 3637 while Change R(192) options are sent by the HC-Sender. 3639 For example, consider a DCCP connection where the A-to-B half- 3640 connection uses CCID 4 and the B-to-A half-connection uses CCID 5. 3641 Here is how a sampling of CCID-specific options are assigned to 3642 half-connections. 3644 Relevant Relevant 3645 Packet Option Half-conn. CCID 3646 ------ ------ ---------- ---- 3647 A > B 128 A-to-B 4 3648 A > B 192 B-to-A 5 3649 A > B Change L(128, ...) A-to-B 4 3650 A > B Change R(192, ...) A-to-B 4 3651 A > B Confirm L(128, ...) A-to-B 4 3652 A > B Confirm R(192, ...) A-to-B 4 3653 A > B Change R(128, ...) B-to-A 5 3654 A > B Change L(192, ...) B-to-A 5 3655 A > B Confirm R(128, ...) B-to-A 5 3656 A > B Confirm L(192, ...) B-to-A 5 3658 B > A 128 B-to-A 5 3659 B > A 192 A-to-B 4 3660 B > A Change L(128, ...) B-to-A 5 3661 B > A Change R(192, ...) B-to-A 5 3662 B > A Confirm L(128, ...) B-to-A 5 3663 B > A Confirm R(192, ...) B-to-A 5 3664 B > A Change R(128, ...) A-to-B 4 3665 B > A Change L(192, ...) A-to-B 4 3666 B > A Confirm R(128, ...) A-to-B 4 3667 B > A Confirm L(192, ...) A-to-B 4 3669 Using CCID-specific options and feature options during a negotiation 3670 for that CCID feature is NOT RECOMMENDED, since it is difficult to 3671 predict the CCID that will be in force when the option is processed. 3672 For example, if a DCCP-Request contains the option sequence 3673 "Change L(CCID, 3), 128", the CCID-specific option "128" may be 3674 processed either by CCID 3 (if the server supports CCID 3) or by the 3675 default CCID 2 (if it does not). However, it is safe to include 3676 CCID-specific options following certain Mandatory Change(CCID) 3677 options. For example, if a DCCP-Request contains the option 3678 sequence "Mandatory, Change L(CCID, 3), 128", then either the "128" 3679 option will be processed by CCID 3 or the connection will be reset. 3681 Servers that do not implement the default CCID 2 might nevertheless 3682 receive CCID 2-specific options on a DCCP-Request packet. (Such a 3683 server MUST send Mandatory Change(CCID) options on its DCCP- 3684 Response, so CCID-specific options on any other packet won't refer 3685 to CCID 2.) The server MUST treat such options as non-understood. 3686 Thus, it will reset the connection on encountering a Mandatory CCID- 3687 specific option, send an empty Confirm for a non-Mandatory Change 3688 option for a CCID-specific feature, and ignore other options. 3690 10.4. CCID Profile Requirements 3692 Each CCID Profile document MUST address at least the following 3693 requirements: 3695 o The profile MUST include the name and number of the CCID being 3696 described. 3698 o The profile MUST describe the conditions in which it is likely to 3699 be useful. Often the best way to do this is by comparison to 3700 existing CCIDs. 3702 o The profile MUST list and describe any CCID-specific options, 3703 features, and Reset Codes, and SHOULD list those general options 3704 and features described in this document that are especially 3705 relevant to the CCID. 3707 o Any newly defined acknowledgement mechanism MUST include a way to 3708 transmit ECN Nonce Echoes back to the sender. 3710 o The profile MUST describe the format of data packets, including 3711 any options that should be included and the setting of the CCval 3712 header field. 3714 o The profile MUST describe the format of acknowledgement packets, 3715 including any options that should be included. 3717 o The profile MUST define how data packets are congestion 3718 controlled. This includes responses to congestion events, idle 3719 and application-limited periods, and responses to the DCCP Data 3720 Dropped and Slow Receiver options. CCIDs that implement per- 3721 packet congestion control SHOULD discuss how packet size is 3722 factored in to congestion control decisions. 3724 o The profile MUST specify when acknowledgement packets are 3725 generated, and how they are congestion controlled. 3727 o The profile MUST define when a sender using the CCID is 3728 considered quiescent. 3730 o The profile MUST say whether its CCID's acknowledgements ever 3731 need to be acknowledged, and if so, how often. 3733 10.5. Congestion State 3735 Most congestion control algorithms depend on past history to 3736 determine the current allowed sending rate. In CCID 2, this 3737 congestion state includes a congestion window and a measurement of 3738 the number of packets outstanding in the network; in CCID 3, it 3739 includes the lengths of recent loss intervals; and both CCIDs use an 3740 estimate of the round-trip time. Congestion state depends on the 3741 network path, and is invalidated by path changes. Therefore, DCCP 3742 senders and receivers SHOULD reset their congestion state -- 3743 essentially restarting congestion control from "slow start" or 3744 equivalent -- on significant changes in end-to-end path. For 3745 example, an endpoint that sends or receives a Mobile IPv6 Binding 3746 Update message [RFC 3775] SHOULD reset its congestion state for any 3747 corresponding DCCP connections. 3749 11. Acknowledgements 3751 Congestion control requires receivers to transmit information about 3752 packet losses and ECN marks to senders. DCCP receivers MUST report 3753 all congestion they see, as defined by the relevant CCID profile. 3754 Each CCID says when acknowledgements should be sent, what options 3755 they must use, and so on. DCCP acknowledgements are congestion 3756 controlled, although it is not required that the acknowledgement 3757 stream be more than very roughly TCP-friendly; each CCID defines how 3758 acknowledgements are congestion controlled. 3760 Most acknowledgements use DCCP options. For example, on a half- 3761 connection with CCID 2 (TCP-like), the receiver reports 3762 acknowledgement information using the Ack Vector option. This 3763 section describes common acknowledgement options and shows how acks 3764 using those options will commonly work. Full descriptions of the 3765 ack mechanisms used for each CCID are laid out in the CCID profile 3766 specifications. 3768 Acknowledgement options, such as Ack Vector, generally depend on the 3769 DCCP Acknowledgement Number, and are thus only allowed on packet 3770 types that carry that number (all packets except DCCP-Request and 3771 DCCP-Data). Detailed acknowledgement options are not necessarily 3772 required on every packet that carries an Acknowledgement Number, 3773 however. 3775 11.1. Acks of Acks and Unidirectional Connections 3777 DCCP was designed to work well for both bidirectional and 3778 unidirectional flows of data, and for connections that transition 3779 between these states. However, acknowledgements required for a 3780 unidirectional connection are very different from those required for 3781 a bidirectional connection. In particular, unidirectional 3782 connections need to worry about acks of acks. 3784 The ack-of-acks problem arises because some acknowledgement 3785 mechanisms are reliable. For example, an HC-Receiver using CCID 2, 3786 TCP-like Congestion Control, sends Ack Vectors containing completely 3787 reliable acknowledgement information. The HC-Sender should 3788 occasionally inform the HC-Receiver that it has received an ack. If 3789 it did not, the HC-Receiver might resend complete Ack Vector 3790 information, going back to the start of the connection, with every 3791 DCCP-Ack packet! However, note that acks-of-acks need not be 3792 reliable themselves: when an ack-of-acks is lost, the HC-Receiver 3793 will simply maintain, and periodically retransmit, old 3794 acknowledgement-related state for a little longer. Therefore, there 3795 is no need for acks-of-acks-of-acks. 3797 When communication is bidirectional, any required acks-of-acks are 3798 automatically contained in normal acknowledgements for data packets. 3799 On a unidirectional connection, however, the receiver DCCP sends no 3800 data, so the sender would not normally send acknowledgements. 3801 Therefore, the CCID in force on that half-connection must explicitly 3802 say whether, when, and how the HC-Sender should generate acks-of- 3803 acks. 3805 For example, consider a bidirectional connection where both half- 3806 connections use the same CCID (either 2 or 3), and where DCCP B goes 3807 "quiescent". This means that the connection becomes unidirectional: 3808 DCCP B stops sending data, and sends only sends DCCP-Ack packets to 3809 DCCP A. For example, in CCID 2, TCP-like Congestion Control, DCCP B 3810 uses Ack Vector to reliably communicate which packets it has 3811 received. As described above, DCCP A must occasionally acknowledge 3812 a pure acknowledgement from DCCP B, so that B can free old Ack 3813 Vector state. For instance, A might send a DCCP-DataAck packet 3814 every now and then, instead of DCCP-Data. In contrast, in CCID 3, 3815 TFRC Congestion Control, DCCP B's acknowledgements generally need 3816 not be reliable, since they contain cumulative loss rates; TFRC 3817 works even if every DCCP-Ack is lost. Therefore, DCCP A need never 3818 acknowledge an acknowledgement. 3820 When communication is unidirectional, a single CCID -- in the 3821 example, the A-to-B CCID -- controls both DCCPs' acknowledgements, 3822 in terms of their content, their frequency, and so forth. For 3823 bidirectional connections, the A-to-B CCID governs DCCP B's 3824 acknowledgements (including its acks of DCCP A's acks), while the B- 3825 to-A CCID governs DCCP A's acknowledgements. 3827 DCCP A switches its ack pattern from bidirectional to unidirectional 3828 when it notices that DCCP B has gone quiescent. It switches from 3829 unidirectional to bidirectional when it must acknowledge even a 3830 single DCCP-Data or DCCP-DataAck packet from DCCP B. 3832 Each CCID defines how to detect quiescence on that CCID, and how 3833 that CCID handles acks-of-acks on unidirectional connections. The 3834 B-to-A CCID defines when DCCP B has gone quiescent. Usually, this 3835 happens when a period has passed without B sending any data packets; 3836 in CCID 2, for example, this period is the maximum of 0.2 seconds 3837 and two round-trip times. The A-to-B CCID defines how DCCP A 3838 handles acks-of-acks once DCCP B has gone quiescent. 3840 11.2. Ack Piggybacking 3842 Acknowledgements of A-to-B data MAY be piggybacked on data sent by 3843 DCCP B, as long as that does not delay the acknowledgement longer 3844 than the A-to-B CCID would find acceptable. However, data 3845 acknowledgements often require more than 4 bytes to express. A 3846 large set of acknowledgements prepended to a large data packet might 3847 exceed the allowed maximum packet size. In this case, DCCP B SHOULD 3848 send separate DCCP-Data and DCCP-Ack packets, or wait, but not too 3849 long, for a smaller datagram. 3851 Piggybacking is particularly common at DCCP A when the B-to-A half- 3852 connection is quiescent -- that is, when DCCP A is just 3853 acknowledging DCCP B's acknowledgements. There are three reasons to 3854 acknowledge DCCP B's acknowledgements: to allow DCCP B to free up 3855 information about previously acknowledged data packets from A; to 3856 shrink the size of future acknowledgements; and to manipulate the 3857 rate at which future acknowledgements are sent. Since these are 3858 secondary concerns, DCCP A can generally afford to wait indefinitely 3859 for a data packet to piggyback its acknowledgement onto; if DCCP B 3860 wants to elicit an acknowledgement, it can send a DCCP-Sync. 3862 Any restrictions on ack piggybacking are described in the relevant 3863 CCID's profile. 3865 11.3. Ack Ratio Feature 3867 The Ack Ratio feature lets HC-Senders influence the rate at which 3868 HC-Receivers generate DCCP-Ack packets, thus controlling reverse- 3869 path congestion. This differs from TCP, which presently has no 3870 congestion control for pure acknowledgement traffic. Ack Ratio 3871 reverse-path congestion control does not try to be TCP-friendly. It 3872 just tries to avoid congestion collapse, and to be somewhat better 3873 than TCP in the presence of a high packet loss or mark rate on the 3874 reverse path. 3876 Ack Ratio applies to CCIDs whose HC-Receivers clock acknowledgements 3877 off the receipt of data packets. The value of Ack Ratio/A equals 3878 the rough ratio of data packets sent by DCCP A to DCCP-Ack packets 3879 sent by DCCP B. Higher Ack Ratios correspond to lower DCCP-Ack 3880 rates; the sender raises Ack Ratio when the reverse path is 3881 congested and lowers Ack Ratio when it is not. Each CCID profile 3882 defines how it controls congestion on the acknowledgement path, and, 3883 particularly, whether Ack Ratio is used. CCID 2, for example, uses 3884 Ack Ratio for acknowledgement congestion control, but CCID 3 does 3885 not. However, each Ack Ratio feature has a value whether or not 3886 that value is used by the relevant CCID. 3888 Ack Ratio has feature number 5, and is non-negotiable. It takes 3889 two-byte integer values. An Ack Ratio/A value of four means that 3890 DCCP B will send at least one acknowledgement packet for every four 3891 data packets sent by DCCP A. DCCP A sends a "Change L(Ack Ratio)" 3892 option to notify DCCP B of its ack ratio. An Ack Ratio value of 3893 zero indicates that the relevant half-connection does not use an Ack 3894 Ratio to control its acknowledgement rate. New connections start 3895 with Ack Ratio 2 for both endpoints; this Ack Ratio results in 3896 acknowledgement behavior analogous to TCP's delayed acks. 3898 Ack Ratio should be treated as a guideline rather than a strict 3899 requirement. We intend Ack Ratio-controlled acknowledgement 3900 behavior to resemble TCP's acknowledgement behavior when there is no 3901 reverse-path congestion, and to be somewhat more conservative when 3902 there is reverse-path congestion. Following this intent is more 3903 important than implementing Ack Ratio precisely. In particular: 3905 o Receivers MAY piggyback acknowledgement information on data 3906 packets, creating DCCP-DataAck packets. The Ack Ratio does not 3907 apply to piggybacked acknowledgements. However, if the data 3908 packets are too big to carry acknowledgement information, or the 3909 data sending rate is lower than Ack Ratio would suggest, then 3910 DCCP B SHOULD send enough pure DCCP-Ack packets to maintain the 3911 rate of one acknowledgement per Ack Ratio received data packets. 3913 o Receivers MAY rate-pace their acknowledgements, rather than 3914 sending acknowledgements immediately upon the receipt of data 3915 packets. Receivers that rate-pace acknowledgements SHOULD pick a 3916 rate that approximates the effect of Ack Ratio, and SHOULD 3917 include Elapsed Time options (Section 13.2) to help the sender 3918 calculate round-trip times. 3920 o Receivers SHOULD implement delayed acknowledgement timers like 3921 TCP's, whereby any packet's acknowledgement is delayed by at most 3922 T seconds. This delay lets the receiver collect additional 3923 packets to acknowledge, and thus reduce the per-packet overhead 3924 of acknowledgements; but if T seconds have passed by and the ack 3925 is still around, it is sent out right away. The default value of 3926 T should be 0.2 seconds, as is common in TCP implementations. 3927 This may lead to sending more acknowledgement packets than Ack 3928 Ratio would suggest. 3930 o Receivers SHOULD send acknowledgements immediately on receiving 3931 packets marked ECN Congestion Experienced, or packets whose out- 3932 of-order sequence numbers potentially indicate loss. However, 3933 there is no need to send such immediate acknowledgements for 3934 marked packets more than once per round-trip time. 3936 o Receivers MAY ignore Ack Ratio if they perform their own 3937 congestion control on acknowledgements. For example, a receiver 3938 that knows the loss and mark rate for its DCCP-Ack packets might 3939 maintain a TCP-friendly acknowledgement rate on its own. Such a 3940 receiver MUST either ensure that it always obtains sufficient 3941 acknowledgement loss and mark information, or fall back to Ack 3942 Ratio when sufficient information is not available, as might 3943 happen during periods when the receiver is quiescent. 3945 11.4. Ack Vector Options 3947 The Ack Vector gives a run-length encoded history of data packets 3948 received at the client. Each byte of the vector gives the state of 3949 that data packet in the loss history, and the number of preceding 3950 packets with the same state. The option's data looks like this: 3952 +--------+--------+--------+--------+--------+-------- 3953 |0010011?| Length |SSLLLLLL|SSLLLLLL|SSLLLLLL| ... 3954 +--------+--------+--------+--------+--------+-------- 3955 Type=38/39 \___________ Vector ___________... 3957 The two Ack Vector options (option types 38 and 39) differ only in 3958 the values they imply for ECN Nonce Echo. Section 12.2 describes 3959 this further. 3961 The vector itself consists of a series of bytes, each of whose 3962 encoding is: 3964 0 1 2 3 4 5 6 7 3965 +-+-+-+-+-+-+-+-+ 3966 |Sta| Run Length| 3967 +-+-+-+-+-+-+-+-+ 3969 Sta[te] occupies the most significant two bits of each byte, and can 3970 have one of four values, as follows. 3972 State Meaning 3973 ----- ------- 3974 0 Received 3975 1 Received ECN Marked 3976 2 Reserved 3977 3 Not Yet Received 3979 Table 6: DCCP Ack Vector States 3981 The term "ECN marked" refers to packets with ECN code point 11, CE 3982 (Congestion Experienced); packets received with this ECN code point 3983 MUST be reported using State 1, Received ECN Marked. Packets 3984 received with other ECN code points 00, 01, or 10 (Non-ECT, ECT(0), 3985 or ECT(1), respectively) MUST be reported using State 0, Received. 3987 Run Length, the least significant six bits of each byte, specifies 3988 how many consecutive packets have the given State. Run Length zero 3989 says the corresponding State applies to one packet only; Run Length 3990 63 says it applies to 64 consecutive packets. Run lengths of 65 or 3991 more must be encoded in multiple bytes. 3993 The first byte in the first Ack Vector option refers to the packet 3994 indicated in the Acknowledgement Number; subsequent bytes refer to 3995 older packets. (Ack Vector MUST NOT be sent on DCCP-Data and DCCP- 3996 Request packets, which lack an Acknowledgement Number.) An Ack 3997 Vector containing the decimal values 0,192,3,64,5 and the 3998 Acknowledgement Number is decimal 100 indicates that: 4000 Packet 100 was received (Acknowledgement Number 100, State 0, 4001 Run Length 0). 4003 Packet 99 was lost (State 3, Run Length 0). 4005 Packets 98, 97, 96 and 95 were received (State 0, Run Length 3). 4007 Packet 94 was ECN marked (State 1, Run Length 0). 4009 Packets 93, 92, 91, 90, 89, and 88 were received (State 0, Run 4010 Length 5). 4012 A single Ack Vector option can acknowledge up to 16192 data packets. 4013 Should more packets need to be acknowledged than can fit in 253 4014 bytes of Ack Vector, then multiple Ack Vector options can be sent; 4015 the second Ack Vector begins where the first left off, and so forth. 4017 Ack Vector states are subject to two general constraints. (These 4018 principles SHOULD also be followed for other acknowledgement 4019 mechanisms; referring to Ack Vector states simplifies their 4020 explanation.) 4022 1. Packets reported as State 0 or State 1 MUST be acknowledgeable: 4023 their options have been processed by the receiving DCCP stack. 4024 Any data on the packet need not have been delivered to the 4025 receiving application; in fact, the data may have been dropped. 4027 2. Packets reported as State 3 MUST NOT be acknowledgeable. 4028 Feature negotiations and options on such packets MUST NOT have 4029 been processed, and the Acknowledgement Number MUST NOT 4030 correspond to such a packet. 4032 Packets dropped in the application's receive buffer MUST be reported 4033 as Received or Received ECN Marked (States 0 and 1), depending on 4034 their ECN state; such packets' ECN Nonces MUST be included in the 4035 Nonce Echo. The Data Dropped option informs the sender that some 4036 packets reported as received actually had their application data 4037 dropped. 4039 One or more Ack Vector options that, together, report the status of 4040 more packets than have actually been sent SHOULD be considered 4041 invalid. The receiving DCCP SHOULD either ignore the options or 4042 reset the connection with Reset Code 5, "Option Error". Packets 4043 that haven't been included in any Ack Vector option SHOULD be 4044 treated as "not yet received" (State 3) by the sender. 4046 Appendix A provides a non-normative description of the details of 4047 DCCP acknowledgement handling, in the context of an abstract Ack 4048 Vector implementation. 4050 11.4.1. Ack Vector Consistency 4052 A DCCP sender will commonly receive multiple acknowledgements for 4053 some of its data packets. For instance, an HC-Sender might receive 4054 two DCCP-Acks with Ack Vectors, both of which contained information 4055 about sequence number 24. (Information about a sequence number is 4056 generally repeated in every ack until the HC-Sender acknowledges an 4057 ack. In this case, perhaps the HC-Receiver is sending acks faster 4058 than the HC-Sender is acknowledging them.) In a perfect world, the 4059 two Ack Vectors would always be consistent. However, there are many 4060 reasons why they might not be. For example: 4062 o The HC-Receiver received packet 24 between sending its acks, so 4063 the first ack said 24 was not received (State 3) and the second 4064 said it was received or ECN marked (State 0 or 1). 4066 o The HC-Receiver received packet 24 between sending its acks, and 4067 the network reordered the acks. In this case, the packet will 4068 appear to transition from State 0 or 1 to State 3. 4070 o The network duplicated packet 24, and one of the duplicates was 4071 ECN marked. This might show up as a transition between States 0 4072 and 1. 4074 To cope with these situations, HC-Sender DCCP implementations SHOULD 4075 combine multiple received Ack Vector states according to this table: 4077 Received State 4078 0 1 3 4079 +---+---+---+ 4080 0 | 0 |0/1| 0 | 4081 Old +---+---+---+ 4082 1 | 1 | 1 | 1 | 4083 State +---+---+---+ 4084 3 | 0 | 1 | 3 | 4085 +---+---+---+ 4087 To read the table, choose the row corresponding to the packet's old 4088 state and the column corresponding to the packet's state in the 4089 newly received Ack Vector, then read the packet's new state off the 4090 table. For an old state of 0 (received non-marked) and received 4091 state of 1 (received ECN marked), the packet's new state may be set 4092 to either 0 or 1. The HC-Sender implementation will be indifferent 4093 to ack reordering if it chooses new state 1 for that cell. 4095 The HC-Receiver should collect information about received packets, 4096 which it will eventually report to the HC-Sender on one or more 4097 acknowledgements, according to the following table: 4099 Received Packet 4100 0 1 3 4101 +---+---+---+ 4102 0 | 0 |0/1| 0 | 4103 Stored +---+---+---+ 4104 1 |0/1| 1 | 1 | 4105 State +---+---+---+ 4106 3 | 0 | 1 | 3 | 4107 +---+---+---+ 4109 This table equals the sender's table, except that when the stored 4110 state is 1 and the received state is 0, the receiver is allowed to 4111 switch its stored state to 0. 4113 A HC-Sender MAY choose to throw away old information gleaned from 4114 the HC-Receiver's Ack Vectors, in which case it MUST ignore newly 4115 received acknowledgements from the HC-Receiver for those old 4116 packets. It is often kinder to save recent Ack Vector information 4117 for a while, so that the HC-Sender can undo its reaction to presumed 4118 congestion when a "lost" packet unexpectedly shows up (the 4119 transition from State 3 to State 0). 4121 11.4.2. Ack Vector Coverage 4123 We can divide the packets that have been sent from an HC-Sender to 4124 an HC-Receiver into four roughly contiguous groups. From oldest to 4125 youngest, these are: 4127 1. Packets already acknowledged by the HC-Receiver, where the HC- 4128 Receiver knows that the HC-Sender has definitely received the 4129 acknowledgements. 4131 2. Packets already acknowledged by the HC-Receiver, where the HC- 4132 Receiver cannot be sure that the HC-Sender has received the 4133 acknowledgements. 4135 3. Packets not yet acknowledged by the HC-Receiver. 4137 4. Packets not yet received by the HC-Receiver. 4139 The union of groups 2 and 3 is called the Acknowledgement Window. 4140 Generally, every Ack Vector generated by the HC-Receiver will cover 4141 the whole Acknowledgement Window: Ack Vector acknowledgements are 4142 cumulative. (This simplifies Ack Vector maintenance at the HC- 4143 Receiver; see Appendix A, below.) As packets are received, this 4144 window both grows on the right and shrinks on the left. It grows 4145 because there are more packets, and shrinks because the data 4146 packets' Acknowledgement Numbers will acknowledge previous 4147 acknowledgements, moving packets from group 2 into group 1. 4149 11.5. Send Ack Vector Feature 4151 The Send Ack Vector feature lets DCCPs negotiate whether they should 4152 use Ack Vector options to report congestion. Ack Vector provides 4153 detailed loss information, and lets senders report back to their 4154 applications whether particular packets were dropped. Send Ack 4155 Vector is mandatory for some CCIDs, and optional for others. 4157 Send Ack Vector has feature number 6, and is server-priority. It 4158 takes one-byte Boolean values. DCCP A MUST send Ack Vector options 4159 on its acknowledgements when Send Ack Vector/A has value one, 4160 although it MAY send Ack Vector options even when Send Ack Vector/A 4161 is zero. Values of two or more are reserved. New connections start 4162 with Send Ack Vector 0 for both endpoints. DCCP B sends a 4163 "Change R(Send Ack Vector, 1)" option to DCCP A to ask A to send Ack 4164 Vector options as part of its acknowledgement traffic. 4166 11.6. Slow Receiver Option 4168 An HC-Receiver sends the Slow Receiver option to its sender to 4169 indicate that it is having trouble keeping up with the sender's 4170 data. The HC-Sender SHOULD NOT increase its sending rate for 4171 approximately one round-trip time after seeing a packet with a Slow 4172 Receiver option. After one round-trip time, the effect of Slow 4173 Receiver disappears and the HC-Sender may again increase its rate, 4174 so the HC-Receiver SHOULD continue to send Slow Receiver options if 4175 it needs to prevent the HC-Sender from going faster in the long 4176 term. The Slow Receiver option does not indicate congestion, and 4177 the HC-Sender need not reduce its sending rate. (If necessary, the 4178 receiver can force the sender to slow down by dropping packets, with 4179 or without Data Dropped, or reporting false ECN marks.) APIs should 4180 let receiver applications set Slow Receiver, and sending 4181 applications determine whether or not their receivers are Slow. 4183 Slow Receiver is a one-byte option. 4185 +--------+ 4186 |00000010| 4187 +--------+ 4188 Type=2 4190 Slow Receiver does not specify why the receiver is having trouble 4191 keeping up with the sender. Possible reasons include lack of buffer 4192 space, CPU overload, and application quotas. A sending application 4193 might react to Slow Receiver by reducing its sending rate, for 4194 example. 4196 The sending application should not react to Slow Receiver by sending 4197 more data, however. The optimal response to a CPU-bound receiver 4198 might be to increase the sending rate, by switching to a less- 4199 compressed sending format, since a highly-compressed data format 4200 might overwhelm a slow CPU more seriously than the higher memory 4201 requirements of a less-compressed data format. This kind of format 4202 change should be requested at the application level, not via the 4203 Slow Receiver option. 4205 Slow Receiver implements a portion of TCP's receive window 4206 functionality. 4208 11.7. Data Dropped Option 4210 The Data Dropped option indicates that the application data on one 4211 or more received packets did not actually reach the application. 4213 Data Dropped additionally reports why the data was dropped: perhaps 4214 the data was corrupt, or perhaps the receiver cannot keep up with 4215 the sender's current rate and the data was dropped in some receive 4216 buffer. Using Data Dropped, DCCP endpoints can discriminate between 4217 different kinds of loss; this differs from TCP, in which all loss is 4218 reported the same way. 4220 Unless explicitly specified otherwise, DCCP congestion control 4221 mechanisms MUST react as if each Data Dropped packet was marked as 4222 ECN Congestion Experienced by the network. We intend for Data 4223 Dropped to enable research into richer congestion responses to 4224 corrupt and other endpoint-dropped packets, but DCCP CCIDs MUST 4225 react conservatively to Data Dropped until this behavior is 4226 standardized. Section 11.7.2, below, describes congestion responses 4227 for all current Drop Codes. 4229 If a received packet's application data is dropped for one of the 4230 reasons listed below, this SHOULD be reported using a Data Dropped 4231 option. Alternatively, the receiver MAY choose to report as 4232 "received" only those packets whose data were not dropped, subject 4233 to the constraint that packets not reported as received MUST NOT 4234 have had their options processed. 4236 The option's data looks like this: 4238 +--------+--------+--------+--------+--------+-------- 4239 |00101000| Length | Block | Block | Block | ... 4240 +--------+--------+--------+--------+--------+-------- 4241 Type=40 \___________ Vector ___________ ... 4243 The Vector consists of a series of bytes, called Blocks, each of 4244 whose encoding corresponds to one of two choices: 4246 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 4247 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 4248 |0| Run Length | or |1|DrpCd|Run Len| 4249 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ 4250 Normal Block Drop Block 4252 The first byte in the first Data Dropped option refers to the packet 4253 indicated in the Acknowledgement Number; subsequent bytes refer to 4254 older packets. (Data Dropped MUST NOT be sent on DCCP-Data or DCCP- 4255 Request packets, which lack an Acknowledgement Number, and any Data 4256 Dropped options received on these packet types MUST be ignored.) 4257 Normal Blocks, which have high bit 0, indicate that any received 4258 packets in the Run Length had their data delivered to the 4259 application. Drop Blocks, which have high bit 1, indicate that 4260 received packets in the Run Len[gth] were not delivered as usual. 4262 The 3-bit Drop Code [DrpCd] field says what happened; generally, no 4263 data from that packet reached the application. Packets reported as 4264 "not yet received" MUST be included in Normal Blocks; packets not 4265 covered by any Data Dropped option are treated as if they were in a 4266 Normal Block. Defined Drop Codes for Drop Blocks are as follows. 4268 Drop Code Meaning 4269 --------- ------- 4270 0 Protocol Constraints 4271 1 Application Not Listening 4272 2 Receive Buffer 4273 3 Corrupt 4274 4-6 Reserved 4275 7 Delivered Corrupt 4277 Table 7: DCCP Drop Codes 4279 To go into more detail: 4281 0 The packet data was dropped due to protocol constraints. 4282 For example, the data was included on a DCCP-Request packet, 4283 but the receiving application does not allow such 4284 piggybacking; or the data was included on a packet with 4285 inappropriately low Checksum Coverage. 4287 1 The packet data was dropped because the application is no 4288 longer listening. See Section 11.7.2. 4290 2 The packet data was dropped in a receive buffer, probably 4291 because of receive buffer overflow. See Section 11.7.2. 4293 3 The packet data was dropped due to corruption. See Section 4294 9.3. 4296 7 The packet data was corrupted, but delivered to the 4297 application anyway. See Section 9.3. 4299 For example, assume a packet arrives with Acknowledgement Number 4300 100, an Ack Vector reporting all packets as received, and a Data 4301 Dropped option containing the decimal values 0,160,3,162. Then: 4303 Packet 100 was received (Acknowledgement Number 100, Normal 4304 Block, Run Length 0). 4306 Packet 99 was dropped in a receive buffer (Drop Block, Drop Code 4307 2, Run Length 0). 4309 Packets 98, 97, 96, and 95 were received (Normal Block, Run 4310 Length 3). 4312 Packets 95, 94, and 93 were dropped in the receive buffer (Drop 4313 Block, Drop Code 2, Run Length 2). 4315 Run lengths of more than 128 (for Normal Blocks) or 16 (for Drop 4316 Blocks) must be encoded in multiple Blocks. A single Data Dropped 4317 option can acknowledge up to 32384 Normal Block data packets, 4318 although the receiver SHOULD NOT send a Data Dropped option when all 4319 relevant packets fit into Normal Blocks. Should more packets need 4320 to be acknowledged than can fit in 253 bytes of Data Dropped, then 4321 multiple Data Dropped options can be sent. The second option will 4322 begin where the first left off, and so forth. 4324 One or more Data Dropped options that, together, report the status 4325 of more packets than have been sent, or that change the status of a 4326 packet, or that disagree with Ack Vector or equivalent options (by 4327 reporting a "not yet received" packet as "dropped in the receive 4328 buffer", for example), SHOULD be considered invalid. The receiving 4329 DCCP SHOULD either such options, or respond by resetting the 4330 connection with Reset Code 5, "Option Error". 4332 A DCCP application interface should let receiving applications 4333 specify the Drop Codes corresponding to received packets. For 4334 example, this would let applications calculate their own checksums, 4335 but still report "dropped due to corruption" packets via the Data 4336 Dropped option. The interface SHOULD NOT let applications reduce 4337 the "seriousness" of a packet's Drop Code; for example, the 4338 application should not be able to upgrade a packet from delivered 4339 corrupt (Drop Code 7) to delivered normally (no Drop Code). 4341 Data Dropped information is transmitted reliably. That is, 4342 endpoints SHOULD continue to transmit Data Dropped options until 4343 receiving an acknowledgement indicating that the relevant options 4344 have been processed. In Ack Vector terms, each acknowledgement 4345 should contain Data Dropped options that cover the whole 4346 Acknowledgement Window (Section 11.4.2), although when every packet 4347 in that window would be placed in a Normal Block no actual option is 4348 required. 4350 11.7.1. Data Dropped and Normal Congestion Response 4352 When deciding on a response to a particular acknowledgement or set 4353 of acknowledgements containing Data Dropped options, a congestion 4354 control mechanism MUST consider dropped packets and ECN Congestion 4355 Experienced marks (including marked packets that are included in 4356 Data Dropped), as well as the packets singled out in Data Dropped. 4358 For window-based mechanisms, the valid response space is defined as 4359 follows. 4361 Assume an old window of W. Independently calculate a new window 4362 W_new1 that assumes no packets were Data Dropped (so W_new1 contains 4363 only the normal congestion response), and a new window W_new2 that 4364 assumes no packets were lost or marked (so W_new2 contains only the 4365 Data Dropped response). We are assuming that Data Dropped 4366 recommended a reduction in congestion window, so W_new2 < W. 4368 Then the actual new window W_new MUST NOT be larger than the minimum 4369 of W_new1 and W_new2; and the sender MAY combine the two responses, 4370 by setting 4371 W_new = W + min(W_new1 - W, 0) + min(W_new2 - W, 0). 4373 The details of how this is accomplished are specified in CCID 4374 profile documents. Non-window-based congestion control mechanisms 4375 MUST behave analogously; again, CCID profiles define how. 4377 11.7.2. Particular Drop Codes 4379 Drop Code 0, Protocol Constraints, does not indicate any kind of 4380 congestion, so the sender's CCID SHOULD react to packets with Drop 4381 Code 0 as if they were received (with or without ECN Congestion 4382 Experienced marks, as appropriate). However, the sending endpoint 4383 SHOULD NOT send data until it believes the protocol constraint no 4384 longer applies. 4386 Drop Code 1, Application Not Listening, means the application 4387 running at the endpoint that sent the option is no longer listening 4388 for data. For example, a server might close its receiving half- 4389 connection to new data after receiving a complete request from the 4390 client. This would limit the amount of state available at the 4391 server for incoming data, and thus reduce the potential damage from 4392 certain denial-of-service attacks. A Data Dropped option containing 4393 Drop Code 1 SHOULD be sent whenever received data is ignored due to 4394 a non-listening application. Once an endpoint reports Drop Code 1 4395 for a packet, it SHOULD report Drop Code 1 for every succeeding data 4396 packet on that half-connection; once an endpoint receives a Drop 4397 State 1 report, it SHOULD expect that no more data will ever be 4398 delivered to the other endpoint's application, so it SHOULD NOT send 4399 more data. 4401 Drop Code 2, Receive Buffer, indicates congestion inside the 4402 receiving host. For instance, if a drop-from-tail kernel socket 4403 buffer is too full to accept a packet's application data, that 4404 packet should be reported as Drop Code 2. For a drop-from-head or 4405 more complex socket buffer, the dropped packet should be reported as 4406 Drop Code 2. DCCP implementations may also provide an API by which 4407 applications can mark received packets as Drop Code 2, indicating 4408 that the application ran out of space in its user-level receive 4409 buffer. (However, it is not generally useful to report packets as 4410 dropped due to Drop Code 2 after more than a couple round-trip times 4411 have passed. The HC-Sender may have forgotten its acknowledgement 4412 state for the packet by that time, so the Data Dropped report will 4413 have no effect.) Every packet newly acknowledged as Drop Code 2 4414 SHOULD reduce the sender's instantaneous rate by one packet per 4415 round-trip time. Each CCID profile defines the CCID-specific 4416 mechanism by which this is accomplished. 4418 Currently, the other Drop Codes, namely Drop Code 3, Corrupt, Drop 4419 Code 7 Delivered Corrupt, and reserved Drop Codes 4-6, MUST cause 4420 the relevant CCID to behave as if the relevant packets were ECN 4421 marked (ECN Congestion Experienced). 4423 12. Explicit Congestion Notification 4425 The DCCP protocol is fully ECN-aware [RFC 3168]. Each CCID 4426 specifies how its endpoints respond to ECN marks. Furthermore, 4427 DCCP, unlike TCP, allows senders to control the rate at which 4428 acknowledgements are generated (with options like Ack Ratio); since 4429 acknowledgements are congestion-controlled, they also qualify as 4430 ECN-Capable Transport. 4432 A CCID profile describes how that CCID interacts with ECN, both for 4433 data traffic and pure-acknowledgement traffic. A sender SHOULD set 4434 ECN-Capable Transport on its packets' IP headers, unless the 4435 receiver's ECN Incapable feature is on or the relevant CCID 4436 disallows it. 4438 The rest of this section describes the ECN Incapable feature and the 4439 interaction of the ECN Nonce with acknowledgement options such as 4440 Ack Vector. 4442 12.1. ECN Incapable Feature 4444 DCCP endpoints are ECN-aware by default, but the ECN Incapable 4445 feature lets an endpoint reject the use of Explicit Congestion 4446 Notification. The use of this feature is NOT RECOMMENDED. ECN 4447 incapability both avoids ECN's possible benefits and prevents 4448 senders from using the ECN Nonce to check for receiver misbehavior. 4449 A DCCP stack MAY therefore leave the ECN Incapable feature 4450 unimplemented, acting as if all connections were ECN capable. It is 4451 worth noting that the inappropriate firewall interactions that 4452 dogged TCP's implementation of ECN [RFC 3360] involve TCP header 4453 bits, not the IP header's ECN bits; we know of no middlebox that 4454 would block ECN-capable DCCP packets, but allow ECN-incapable DCCP 4455 packets. 4457 ECN Incapable has feature number 4, and is server-priority. It 4458 takes one-byte Boolean values. DCCP A MUST be able to read ECN bits 4459 from received frames' IP headers when ECN Incapable/A is zero. 4460 (This is independent of whether it can set ECN bits on sent frames.) 4461 DCCP A thus sends a "Change L(ECN Inapable, 1)" option to DCCP B to 4462 inform it that A cannot read ECN bits. If the ECN Incapable/A 4463 feature is one, then all of DCCP B's packets MUST be sent as ECN 4464 incapable. New connections start with ECN Incapable 0 (that is, ECN 4465 capable) for both endpoints. Values of two or more are reserved. 4467 If a DCCP is not ECN capable, it MUST send Mandatory "Change L(ECN 4468 Incapable, 1)" options to the other endpoint until acknowledged (by 4469 "Confirm R(ECN Incapable, 1)") or the connection closes. 4470 Furthermore, it MUST NOT accept any data until the other endpoint 4471 sends "Confirm R(ECN Incapable, 1)". It SHOULD send Data Dropped 4472 options on its acknowledgements, with Drop Code 0 ("protocol 4473 constraints"), if the other endpoint does send data inappropriately. 4475 12.2. ECN Nonces 4477 Congestion avoidance will not occur, and the receiver will sometimes 4478 get its data faster, if the sender isn't told about congestion 4479 events. Thus, the receiver has some incentive to falsify 4480 acknowledgement information, reporting that marked or dropped 4481 packets were actually received unmarked. This problem is more 4482 serious with DCCP than with TCP, since TCP provides reliable 4483 transport: it is more difficult with TCP to lie about lost packets 4484 without breaking the application. 4486 ECN Nonces are a general mechanism to prevent ECN cheating (or loss 4487 cheating). Two values for the two-bit ECN header field indicate 4488 ECN-Capable Transport, 01 and 10. The second code point, 10, is the 4489 ECN Nonce. In general, a protocol sender chooses between these code 4490 points randomly on its output packets, remembering the sequence it 4491 chose. The protocol receiver reports, on every acknowledgement, the 4492 number of ECN Nonces it has received thus far. This is called the 4493 ECN Nonce Echo. Since ECN marking and packet dropping both destroy 4494 the ECN Nonce, a receiver that lies about an ECN mark or packet drop 4495 has a 50% chance of guessing right and avoiding discipline. The 4496 sender may react punitively to an ECN Nonce mismatch, possibly up to 4497 dropping the connection. The ECN Nonce Echo field need not be an 4498 integer; one bit is enough to catch 50% of infractions, and the 4499 probability of success drops exponentially as more bits are sent 4500 [RFC 3540]. 4502 In DCCP, the ECN Nonce Echo field is encoded in acknowledgement 4503 options. For example, the Ack Vector option comes in two forms, Ack 4504 Vector [Nonce 0] (option 38) and Ack Vector [Nonce 1] (option 39), 4505 corresponding to the two values for a one-bit ECN Nonce Echo. The 4506 Nonce Echo for a given Ack Vector equals the one-bit sum (exclusive- 4507 or, or parity) of ECN nonces for packets reported by that Ack Vector 4508 as received and not ECN marked. Thus, only packets marked as State 4509 0 matter for this calculation (that is, valid received packets that 4510 were not ECN marked). Every Ack Vector option is detailed enough 4511 for the sender to determine what the Nonce Echo should have been. 4512 It can check this calculation against the actual Nonce Echo, and 4513 complain if there is a mismatch. (The Ack Vector could conceivably 4514 report every packet's ECN Nonce state, but this would severely limit 4515 Ack Vector's compressibility without providing much extra 4516 protection.) 4518 Each DCCP sender SHOULD set ECN Nonces on its packets, and remember 4519 which packets had nonces. When a sender detects an ECN Nonce Echo 4520 mismatch, it SHOULD behave as if the receiver had reported one or 4521 more packets as ECN-marked (instead of unmarked). It MAY take more 4522 punitive action, such as resetting the connection with Reset Code 4523 11, "Aggression Penalty". Each DCCP receiver MUST calculate and use 4524 the correct value for ECN Nonce Echo when sending acknowledgement 4525 options. 4527 ECN incapability, as indicated by the ECN Incapable feature, is 4528 handled as follows: An endpoint sending packets to an ECN-incapable 4529 receiver MUST send its packets as ECN incapable, and an ECN- 4530 incapable receiver MUST use the value zero for all ECN Nonce Echoes. 4532 12.3. Other Aggression Penalties 4534 The ECN Nonce provides one way for a DCCP sender to discover that a 4535 receiver is misbehaving. There may be other mechanisms, and a 4536 receiver or middlebox may also discover that a sender is misbehaving 4537 -- sending more data than it should. In any of these cases, the 4538 entity that discovers the misbehavior MAY react by resetting the 4539 connection with Reset Code 11, "Aggression Penalty". A receiver 4540 that detects marginal (meaning possibly spurious) sender misbehavior 4541 MAY instead react with a Slow Receiver option, or by reporting some 4542 packets as ECN marked that were not, in fact, marked. A large of 4543 range of alternate strategies are available, including priority 4544 queueing, rate limiting, and so forth. 4546 13. Timing Options 4548 The Timestamp, Timestamp Echo, and Elapsed Time options help DCCP 4549 endpoints explicitly measure round-trip times. 4551 13.1. Timestamp Option 4553 This option is permitted in any DCCP packet. The length of the 4554 option is 6 bytes. 4556 +--------+--------+--------+--------+--------+--------+ 4557 |00101001|00000110| Timestamp Value | 4558 +--------+--------+--------+--------+--------+--------+ 4559 Type=41 Length=6 4561 The four bytes of option data carry the timestamp of this packet. 4562 The timestamp is a 32-bit integer that increases monotonically with 4563 time, at a rate of 1 unit per 10 microseconds. At this rate, 4564 Timestamp Value will wrap approximately every 11.9 hours. Endpoints 4565 need not measure time at this fine granularity; for example, an 4566 endpoint that preferred to measure time at millisecond granularity 4567 might send Timestamp Values that were all multiples of 100. The 4568 precise time corresponding to Timestamp Value zero is not specified: 4569 Timestamp Values are only meaningful relative to other Timestamp 4570 Values sent on the same connection. A DCCP receiving a Timestamp 4571 option SHOULD respond with a Timestamp Echo option on the next 4572 packet it sends. 4574 13.2. Elapsed Time Option 4576 This option is permitted in any DCCP packet that contains an 4577 Acknowledgement Number (such options received on other packet types 4578 MUST be ignored). It indicates how much time has elapsed, in 4579 hundredths of milliseconds (or, equivalently, multiples of 4580 10 microseconds), since the packet being acknowledged -- the packet 4581 with the given Acknowledgement Number -- was received. The option 4582 may take 4 or 6 bytes, depending on the size of the Elapsed Time 4583 value. Elapsed Time helps correct round-trip time estimates when 4584 the gap between receiving a packet and acknowledging that packet may 4585 be long -- in CCID 3, for example, where acknowledgements are sent 4586 infrequently. 4588 +--------+--------+--------+--------+ 4589 |00101011|00000100| Elapsed Time | 4590 +--------+--------+--------+--------+ 4591 Type=43 Len=4 4593 +--------+--------+--------+--------+--------+--------+ 4594 |00101011|00000110| Elapsed Time | 4595 +--------+--------+--------+--------+--------+--------+ 4596 Type=43 Len=6 4598 The option data, Elapsed Time, represents an estimated upper bound 4599 on the amount of time elapsed since the packet being acknowledged 4600 was received, with units of tenths of milliseconds. If Elapsed Time 4601 is less than a half-second, the first, smaller form of the option 4602 SHOULD be used. Elapsed Times of more than 0.65535 seconds MUST be 4603 sent using the second form of the option. The special Elapsed Time 4604 value 4294967295, which corresponds to approximately 11.9 hours, is 4605 used to represent any Elapsed Time greater than 42949.67294 seconds. 4606 DCCP endpoints MUST NOT report Elapsed Times that are significantly 4607 larger than the true elapsed times. A connection MAY be reset with 4608 Reset Code 11, "Aggression Penalty", if one endpoint determines that 4609 the other is reporting a much-too-large Elapsed Time. 4611 Elapsed Time is measured in hundredths of milliseconds as a 4612 compromise between two conflicting goals. First, it provides enough 4613 granularity to reduce rounding error when measuring elapsed time 4614 over fast LANs; second, it allows many reasonable elapsed times to 4615 fit into two bytes of data. 4617 13.3. Timestamp Echo Option 4619 This option is permitted in any DCCP packet, as long as at least one 4620 packet carrying the Timestamp option has been received. Generally, 4621 a DCCP endpoint should send one Timestamp Echo option for each 4622 Timestamp option it receives; and it should send that option as soon 4623 as is convenient. The length of the option is between 6 and 10 4624 bytes, depending on whether Elapsed Time is included and how large 4625 it is. 4627 +--------+--------+--------+--------+--------+--------+ 4628 |00101010|00000110| Timestamp Echo | 4629 +--------+--------+--------+--------+--------+--------+ 4630 Type=42 Len=6 4632 +--------+--------+------- ... -------+--------+--------+ 4633 |00101010|00001000| Timestamp Echo | Elapsed Time | 4634 +--------+--------+------- ... -------+--------+--------+ 4635 Type=42 Len=8 (4 bytes) 4637 +--------+--------+------- ... -------+------- ... -------+ 4638 |00101010|00001010| Timestamp Echo | Elapsed Time | 4639 +--------+--------+------- ... -------+------- ... -------+ 4640 Type=42 Len=10 (4 bytes) (4 bytes) 4642 The first four bytes of option data, Timestamp Echo, carry a 4643 Timestamp Value taken from a preceding received Timestamp option. 4644 Usually, this will be the last packet that was received -- the 4645 packet indicated by the Acknowledgement Number, if any -- but it 4646 might be a preceding packet. Each Timestamp received will generally 4647 result in exactly one Timestamp Echo transmitted. If an endpoint 4648 has received multiple Timestamp options since the last time it sent 4649 a packet, then it MAY ignore all Timestamp options but the one 4650 included on the packet with the greatest sequence number; 4651 alternatively, it MAY include multiple Timestamp Echo options in its 4652 response, each corresponding to a different Timestamp option. 4654 The Elapsed Time value, similar to that in the Elapsed Time option, 4655 indicates the amount of time elapsed since receiving the packet 4656 whose timestamp is being echoed. This time MUST be in hundredths of 4657 milliseconds. Elapsed Time is meant to help the Timestamp sender 4658 separate the network round-trip time from the Timestamp receiver's 4659 processing time. This may be particularly important for CCIDs where 4660 acknowledgements are sent infrequently, so that there might be 4661 considerable delay between receiving a Timestamp option and sending 4662 the corresponding Timestamp Echo. A missing Elapsed Time field is 4663 equivalent to an Elapsed Time of zero. The smallest version of the 4664 option SHOULD be used that can hold the relevant Elapsed Time value. 4666 14. Maximum Packet Size 4668 A DCCP implementation MUST maintain the maximum packet size (MPS) 4669 allowed for each active DCCP session. The MPS is influenced by the 4670 maximum packet size allowed by the current congestion control 4671 mechanism (CCMPS), the maximum packet size supported by the path's 4672 links (PMTU, the Path Maximum Transmission Unit) [RFC 1191], and the 4673 lengths of the IP and DCCP headers. 4675 A DCCP application interface SHOULD let the application discover 4676 DCCP's current MPS. Generally, the DCCP implementation will refuse 4677 to send any packet bigger than the MPS, returning an appropriate 4678 error to the application. A DCCP interface MAY allow applications 4679 to request fragmentation for packets larger than PMTU, but not 4680 larger than CCMPS (packets larger than CCMPS MUST be rejected in any 4681 case). Fragmentation SHOULD NOT be the default, since it decreases 4682 robustness: an entire packet is discarded if even one of its 4683 fragments is lost. Applications can usually get better error 4684 tolerance by producing packets smaller than the PMTU. 4686 The MPS reported to the application SHOULD be influenced by the size 4687 expected to be required for DCCP headers and options. If the 4688 application provides data that, when combined with the options the 4689 DCCP implementation would like to include, would exceed the MPS, the 4690 implementation should either send the options on a separate packet 4691 (such as a DCCP-Ack) or lower the MPS, drop the data, and return an 4692 appropriate error to the application. 4694 14.1. Measuring PMTU 4696 Each DCCP endpoint MUST keep track of the current PMTU for each 4697 connection, except that this is not required for IPv4 connections 4698 whose applications have requested fragmentation. The PMTU SHOULD be 4699 initialized from the interface MTU that will be used to send 4700 packets. The MPS will be initialized with the minimum of the PMTU 4701 and the CCMPS, if any. 4703 Classical PMTU discovery uses unfragmentable packets. In IPv4, 4704 these packets have the IP Don't Fragment (DF) bit set; in IPv6, all 4705 packets are unfragmentable. As specified in [RFC 1191], when a 4706 router receives a packet with DF set that is larger than the next 4707 link's MTU, it sends an ICMP Destination Unreachable message back to 4708 the source whose Code indicates that an unfragmentable packet was 4709 too large to forward (a "Datagram Too Big" message). When a DCCP 4710 implementation receives a Datagram Too Big message, it decreases its 4711 PMTU to the Next-Hop MTU value given in the ICMP message. If the 4712 MTU given in the message is zero, the sender chooses a value for 4713 PMTU using the algorithm described in Section 7 of [RFC 1191]. If 4714 the MTU given in the message is greater than the current PMTU, the 4715 Datagram Too Big message is ignored, as described in [RFC 1191]. 4716 (We are aware that this may cause problems for DCCP endpoints behind 4717 certain firewalls.) 4719 A DCCP implementation may allow the application to occasionally 4720 request that PMTU discovery be performed again. This will reset the 4721 PMTU to the outgoing interface's MTU. Such requests SHOULD be rate 4722 limited, to one per two seconds, for example. 4724 A DCCP sender MAY treat the reception of an ICMP Datagram Too Big 4725 message as an indication that the packet being reported was not lost 4726 due to congestion, and so for the purposes of congestion control it 4727 MAY ignore the DCCP receiver's indication that this packet did not 4728 arrive. However, if this is done, then the DCCP sender MUST check 4729 the ECN bits of the IP header echoed in the ICMP message, and only 4730 perform this optimization if these ECN bits indicate that the packet 4731 did not experience congestion prior to reaching the router whose 4732 link MTU it exceeded. 4734 A DCCP implementation SHOULD ensure, as far as possible, that ICMP 4735 Datagram Too Big messages were actually generated by routers, so 4736 that attackers cannot drive the PMTU down to a falsely small value. 4737 The simplest way to do this is to verify that the Sequence Number on 4738 the ICMP error's encapsulated header corresponds to a Sequence 4739 Number that the implementation recently sent. (Routers are not 4740 required to return more than 64 bits of the DCCP header [RFC 792], 4741 but most modern routers will return far more, including the Sequence 4742 Number.) ICMP Datagram Too Big messages with incorrect or missing 4743 Sequence Numbers may be ignored, or the DCCP implementation may 4744 lower the PMTU only temporarily in response. If more than three odd 4745 Datagram Too Big messages are received and the other DCCP endpoint 4746 reports more than three lost packets, however, the DCCP 4747 implementation SHOULD assume the presence of a confused router, and 4748 either obey the ICMP messages' PMTU or (on IPv4 networks) switch to 4749 allowing fragmentation. 4751 DCCP also allows upward probing of the PMTU [PMTUD], where the DCCP 4752 endpoint begins by sending small packets with DF set, then gradually 4753 increases the packet size until a packet is lost. This mechanism 4754 does not require any ICMP error processing. DCCP-Sync packets are 4755 the best choice for upward probing, since DCCP-Sync probes do not 4756 risk application data loss. The DCCP implementation inserts 4757 arbitrary data into the DCCP-Sync application area, padding the 4758 packet to the right length; and since every valid DCCP-Sync 4759 generates an immediate DCCP-SyncAck in response, the endpoint will 4760 have a pretty good idea of when a probe is lost. 4762 14.2. Sender Behavior 4764 A DCCP sender SHOULD send every packet as unfragmentable, as 4765 described above, with the following exceptions. 4767 o On IPv4 connections whose applications have requested 4768 fragmentation, the sender SHOULD send packets with the DF bit not 4769 set. 4771 o On IPv6 connections whose applications have requested 4772 fragmentation, the sender SHOULD use fragmentation extension 4773 headers to fragment packets larger than PMTU into suitably-sized 4774 chunks. (Those chunks are, of course, unfragmentable.) 4776 o It is undesirable for PMTU discovery to occur on the initial 4777 connection setup handshake, as the connection setup process may 4778 not be representative of packet sizes used during the connection, 4779 and performing MTU discovery on the initial handshake might 4780 unnecessarily delay connection establishment. Thus, DCCP-Request 4781 and DCCP-Response packets SHOULD be sent as fragmentable. In 4782 addition, DCCP-Reset packets SHOULD be sent as fragmentable, 4783 although typically these would be small enough to not be a 4784 problem. For IPv4 connections, these packets SHOULD be sent with 4785 the DF bit not set; for IPv6 connections, they SHOULD be 4786 preemptively fragmented to a size not larger than the relevant 4787 interface MTU. 4789 However, applications are not advised 4791 If the DCCP implementation has decreased the PMTU, the sending 4792 application has not requested fragmentation, and the sending 4793 application attempts to send a packet larger than the new MPS, the 4794 API MUST refuse to send the packet and return an appropriate error 4795 to the application. The application should then use the API to 4796 query the new value of MPS. The kernel might have some packets 4797 buffered for transmission that are smaller than the old MPS, but 4798 larger than the new MPS. It MAY send these packets as fragmentable, 4799 or it MAY discard these packets; it MUST NOT send them as 4800 unfragmentable. 4802 15. Forward Compatibility 4804 Future versions of DCCP may add new options and features. A few 4805 simple guidelines will let extended DCCPs interoperate with normal 4806 DCCPs. 4808 o DCCP processors MUST NOT act punitively towards options and 4809 features they do not understand. For example, DCCP processors 4810 MUST NOT reset the connection if some field marked Reserved in 4811 this specification is non-zero; if some unknown option is 4812 present; or if some feature negotiation option mentions an 4813 unknown feature. Instead, DCCP processors MUST ignore these 4814 events. The Mandatory option is the single exception: if 4815 Mandatory precedes some unknown option or feature, the connection 4816 MUST be reset. 4818 o DCCP processors MUST anticipate the possibility of unknown 4819 feature values, which might occur as part of a negotiation for a 4820 known feature. For server-priority features, unknown values are 4821 handled as a matter of course: since the non-extended DCCP's 4822 priority list will not contain unknown values, the result of the 4823 negotiation cannot be an unknown value. A DCCP SHOULD respond 4824 with an empty Confirm option if it is assigned an unacceptable 4825 value for some non-negotiable feature. 4827 o Each DCCP extension SHOULD be controlled by some feature. The 4828 default value of this feature should correspond to "extension not 4829 available". If an extended DCCP wants to use the extension, it 4830 SHOULD attempt to change the feature's value using a Change L or 4831 Change R option. Any non-extended DCCP will ignore the option, 4832 thus leaving the feature value at its default, "extension not 4833 available". 4835 Section 19 lists DCCP assigned numbers reserved for experimental and 4836 testing purposes. 4838 16. Middlebox Considerations 4840 This section describes properties of DCCP that firewalls, network 4841 address translators, and other middleboxes should consider, 4842 including parts of the packet that middleboxes should not change. 4843 The intent is to draw attention to aspects of DCCP that may be 4844 useful, or dangerous, for middleboxes, or that differ significantly 4845 from TCP. 4847 The Service Code field in DCCP-Request packets provides information 4848 that may be useful for stateful middleboxes. With Service Code, a 4849 middlebox can tell what protocol a connection will use without 4850 relying on port numbers. Middleboxes can disallow connections that 4851 attempt to access unexpected services by sending a DCCP-Reset with 4852 Reset Code 8, "Bad Service Code". Middleboxes should not modify the 4853 Service Code unless they are really changing the service a 4854 connection is accessing. 4856 The Source and Destination Port fields are in the same packet 4857 locations as the corresponding fields in TCP and UDP, which may 4858 simplify some middlebox implementations. 4860 The forward compatibility considerations in Section 15 apply to 4861 middleboxes as well. In particular, middleboxes generally shouldn't 4862 act punitively towards options and features they do not understand. 4864 Modifying DCCP Sequence Numbers and Acknowledgement Numbers is more 4865 tedious and dangerous than modifying TCP sequence numbers. A 4866 middlebox that added packets to, or removed packets from, a DCCP 4867 connection would have to modify acknowledgement options, such as Ack 4868 Vector, and CCID-specific options, such as TFRC's Loss Intervals, at 4869 minimum. On ECN-capable connections, the middlebox would have to 4870 keep track of ECN Nonce information for packets it introduced or 4871 removed, so that the relevant acknowledgement options continued to 4872 have correct ECN Nonce Echoes, or risk the connection being reset 4873 for "Aggression Penalty". We therefore recommend that middleboxes 4874 not modify packet streams by adding or removing packets. 4876 Note that there is less need to modify DCCP's per-packet sequence 4877 numbers than TCP's per-byte sequence numbers; for example, a 4878 middlebox can change the contents of a packet without changing its 4879 sequence number. (In TCP, sequence number modification is required 4880 to support protocols like FTP that carry variable-length addresses 4881 in the data stream. If such an application were deployed over DCCP, 4882 middleboxes would simply grow or shrink the relevant packets as 4883 necessary, without changing their sequence numbers. This might 4884 involve fragmenting the packet.) 4885 Middleboxes may, of course, reset connections in progress. Clearly 4886 this requires inserting a packet into one or both packet streams, 4887 but the difficult issues do not arise. 4889 DCCP is somewhat unfriendly to "connection splicing" [SHHP00], in 4890 which clients' connection attempts are intercepted, but possibly 4891 later "spliced in" to external server connections via sequence 4892 number manipulations. A connection splicer at minimum would have to 4893 ensure that the spliced connections agreed on all relevant feature 4894 values, which might take some renegotiation. 4896 The contents of this section should not be interpreted as a 4897 wholesale endorsement of stateful middleboxes. 4899 17. Relations to Other Specifications 4901 17.1. RTP 4903 The Real-Time Transport Protocol, RTP [RFC 3550], is currently used 4904 over UDP by many of DCCP's target applications (for instance, 4905 streaming media). Therefore, it is important to examine the 4906 relationship between DCCP and RTP, and in particular, the question 4907 of whether any changes in RTP are necessary or desirable when it is 4908 layered over DCCP instead of UDP. 4910 There are two potential sources of overhead in the RTP-over-DCCP 4911 combination, duplicated acknowledgement information and duplicated 4912 sequence numbers. Together, these sources of overhead add slightly 4913 more than 4 bytes per packet relative to RTP-over-UDP, and that 4914 eliminating the redundancy would not reduce the overhead. 4916 First, consider acknowledgements. Both RTP and DCCP report feedback 4917 about loss rates to data senders, via RTP Control Protocol Sender 4918 and Receiver Reports (RTCP SR/RR packets) and via DCCP 4919 acknowledgement options. These feedback mechanisms are potentially 4920 redundant. However, RTCP SR/RR packets contain information not 4921 present in DCCP acknowledgements, such as "interarrival jitter", and 4922 DCCP's acknowledgements contain information not transmitted by RTCP, 4923 such as the ECN Nonce Echo. Neither feedback mechanism makes the 4924 other redundant. 4926 Sending both types of feedback need not be particularly costly 4927 either. RTCP reports may be sent relatively infrequently: once 4928 every 5 seconds on average, for low-bandwidth flows. In DCCP, some 4929 feedback mechanisms are expensive -- Ack Vector, for example, is 4930 frequent and verbose -- but others are relatively cheap: CCID 3 4931 (TFRC) acknowledgements take between 16 and 32 bytes of options sent 4932 once per round-trip time. (Reporting less frequently than once per 4933 RTT would make congestion control less responsive to loss.) We 4934 therefore conclude that acknowledgement overhead in RTP-over-DCCP 4935 need not be significantly higher than for RTP-over-UDP, at least for 4936 CCID 3. 4938 One clear redundancy can be addressed at the application level. The 4939 verbose packet-by-packet loss reports sent in RTCP Extended Reports 4940 Loss RLE Blocks [RFC 3611] can be derived from DCCP's Ack Vector 4941 options. (The converse is not true, since Loss RLE Blocks contain 4942 no ECN information.) Since DCCP implementations should provide an 4943 API for application access to Ack Vector information, RTP-over-DCCP 4944 applications might request either DCCP Ack Vectors or RTCP Extended 4945 Report Loss RLE Blocks, but not both. 4947 Now consider sequence number redundancy on data packets. The 4948 embedded RTP header contains a 16-bit RTP sequence number. Most 4949 data packets will use the DCCP-Data type; DCCP-DataAck and DCCP-Ack 4950 packets need not usually be sent. The DCCP-Data header is 12 bytes 4951 long without options, including a 24-bit sequence number. This is 4 4952 bytes more than a UDP header. Any options required on data packets 4953 would add further overhead, although many CCIDs (for instance, CCID 4954 3, TFRC) don't require options on most data packets. 4956 The DCCP sequence number cannot be inferred from the RTP sequence 4957 number since it increments on non-data packets as well as data 4958 packets. The RTP sequence number cannot be inferred from the DCCP 4959 sequence number either [RFC 3550]. Furthermore, removing RTP's 4960 sequence number would not save any header space because of alignment 4961 issues. We therefore recommend that RTP transmitted over DCCP use 4962 the same headers currently defined. The 4 byte header cost is a 4963 reasonable tradeoff for DCCP's congestion control features and 4964 access to ECN. Truly bandwidth-starved endpoints should use some 4965 future header compression scheme. 4967 17.2. Congestion Manager and Multiplexing 4969 Since DCCP doesn't provide reliable, ordered delivery, multiple 4970 application sub-flows may be multiplexed over a single DCCP 4971 connection with no inherent performance penalty. Thus, there is no 4972 need for DCCP to provide built-in, SCTP-style support for multiple 4973 sub-flows. 4975 Some applications might want to share congestion control state among 4976 multiple DCCP flows that share the same source and destination 4977 addresses. This functionality could be provided by the Congestion 4978 Manager [RFC 3124], a generic multiplexing facility. However, the 4979 CM would not fully support DCCP without change; it does not 4980 gracefully handle multiple congestion control mechanisms, for 4981 example. 4983 18. Security Considerations 4985 DCCP does not provide cryptographic security guarantees. 4986 Applications desiring hard security should use IPsec or end-to-end 4987 security of some kind. 4989 Nevertheless, DCCP is intended to protect against some classes of 4990 attackers: Attackers cannot hijack a DCCP connection (close the 4991 connection unexpectedly, or cause attacker data to be accepted by an 4992 endpoint as if it came from the sender) unless they can guess valid 4993 sequence numbers. Thus, as long as endpoints choose initial 4994 sequence numbers well, a DCCP attacker must snoop on data packets to 4995 get any reasonable probability of success. Sequence number validity 4996 checks provide this guarantee. Section 7.5.5 describes sequence 4997 number security further. 4999 This security property only holds assuming that DCCP's random 5000 numbers are chosen according to the guidelines in [RFC 1750]. 5002 DCCP provides no protection against attackers that can snoop on data 5003 packets. 5005 18.1. Security Considerations for Partial Checksums 5007 The partial checksum facility has a separate security impact, 5008 particularly in its interaction with authentication and encryption 5009 mechanisms. The impact is the same in DCCP as in the UDP-Lite 5010 protocol, and what follows was adapted from the corresponding text 5011 in the UDP-Lite specification [RFC 3828]. 5013 When a DCCP packet's Checksum Coverage field is not zero, the 5014 uncovered portion of a packet may change in transit. This is 5015 contrary to the idea behind most authentication mechanisms: 5016 authentication succeeds if the packet has not changed in transit. 5017 Unless authentication mechanisms that operate only on the sensitive 5018 part of packets are developed and used, authentication will always 5019 fail for partially-checksummed DCCP packets whose uncovered part has 5020 been damaged. 5022 The IPsec integrity check (Encapsulation Security Protocol, ESP, or 5023 Authentication Header, AH) is applied (at least) to the entire IP 5024 packet payload. Corruption of any bit within that area will then 5025 result in the IP receiver discarding a DCCP packet, even if the 5026 corruption happened in an uncovered part of the DCCP application 5027 data. 5029 When IPsec is used with ESP payload encryption, a link can not 5030 determine the specific transport protocol of a packet being 5031 forwarded by inspecting the IP packet payload. In this case, the 5032 link MUST provide a standard integrity check covering the entire IP 5033 packet and payload. DCCP partial checksums provide no benefit in 5034 this case. 5036 Encryption (e.g., at the transport or application levels) may be 5037 used. Note that omitting an integrity check can, under certain 5038 circumstances, compromise confidentiality [BEL98]. 5040 If a few bits of an encrypted packet are damaged, the decryption 5041 transform will typically spread errors so that the packet becomes 5042 too damaged to be of use. Many encryption transforms today exhibit 5043 this behavior. There exist encryption transforms, stream ciphers, 5044 which do not cause error propagation. Proper use of stream ciphers 5045 can be quite difficult, especially when authentication-checking is 5046 omitted [BB01]. In particular, an attacker can cause predictable 5047 changes to the ultimate plaintext, even without being able to 5048 decrypt the ciphertext. 5050 19. IANA Considerations 5052 DCCP introduces eight sets of numbers whose values should be 5053 allocated by IANA. We refer to allocation policies, such as 5054 Standards Action, outlined in [RFC 2434], and most registries 5055 reserve some values for experimental and testing use [RFC 3692]. In 5056 addition, DCCP requires a Protocol Number to be added to the 5057 registry of Assigned Internet Protocol Numbers. IANA is requested 5058 to assign IP Protocol Number 33 to DCCP; this number has already 5059 been informally made available for experimental DCCP use. 5061 19.1. Packet Types 5063 Each entry in the DCCP Packet Type registry contains a packet type, 5064 which is a number in the range 0-15; a packet type name, such as 5065 DCCP-Request; and a reference to the RFC defining the packet type. 5066 The registry is initially populated using the values in Table 1 5067 (Section 5.1). This document allocates packet types 0-9, and packet 5068 type 14 is permanently reserved for experimental and testing use. 5069 Packet types 10-13 and 15 are currently reserved, and should be 5070 allocated with the Standards Action policy, which requires DCCP 5071 working group review and standards-track RFC publication. 5073 19.2. Reset Codes 5075 Each entry in the DCCP Reset Code registry contains a Reset Code, 5076 which is a number in the range 0-255; a short description of the 5077 Reset Code, such as "No Connection"; and a reference to the RFC 5078 defining the Reset Code. The registry is initially populated using 5079 the values in Table 2 (Section 5.6). This document allocates Reset 5080 Codes 0-11, and Reset Codes 120-126 are permanently reserved for 5081 experimental and testing use. Reset Codes 12-119 and 127 are 5082 currently reserved, and should be allocated with the IETF Consensus 5083 policy, which requires RFC publication (not necessarily standards- 5084 track). Reset Codes 128-255 are permanently reserved for CCID- 5085 specific registries. 5087 19.3. Option Types 5089 Each entry in the DCCP option type registry contains an option type, 5090 which is a number in the range 0-255; the name of the option, such 5091 as "Slow Receiver"; and a reference to the RFC defining the option 5092 type. The registry is initially populated using the values in Table 5093 3 (Section 5.8). This document allocates option types 0-2 and 5094 32-44, and option types 31 and 120-126 are permanently reserved for 5095 experimental and testing use. Option types 3-30, 45-119, and 127 5096 are currently reserved, and should be allocated with the IETF 5097 Consensus policy, which requires RFC publication (not necessarily 5098 standards-track). Option types 128-255 are permanently reserved for 5099 CCID-specific registries. 5101 19.4. Feature Numbers 5103 Each entry in the DCCP feature number registry contains a feature 5104 number, which is a number in the range 0-255; the name of the 5105 feature, such as "ECN Incapable"; and a reference to the RFC 5106 defining the feature number. The registry is initially populated 5107 using the values in Table 4 (Section 6). This document allocates 5108 feature numbers 0-9, and feature numbers 120-126 are permanently 5109 reserved for experimental and testing use. Feature numbers 10-119 5110 and 127 are currently reserved, and should be allocated with the 5111 IETF Consensus policy, which requires RFC publication (not 5112 necessarily standards-track). Feature numbers 128-255 are 5113 permanently reserved for CCID-specific registries. 5115 19.5. Congestion Control Identifiers 5117 Each entry in the DCCP Congestion Control Identifier (CCID) registry 5118 contains a CCID, which is a number in the range 0-255; the name of 5119 the CCID, such as "TCP-like Congestion Control"; and a reference to 5120 the RFC defining the CCID. The registry is initially populated 5121 using the values in Table 5 (Section 10). CCIDs 2 and 3 are 5122 allocated by concurrently published profiles, and CCIDs 248-254 are 5123 permanently reserved for experimental and testing use. CCIDs 0, 1, 5124 4-247, and 255 are currently reserved, and should be allocated with 5125 the IETF Consensus policy, which requires RFC publication (not 5126 necessarily standards-track). 5128 19.6. Ack Vector States 5130 Each entry in the DCCP Ack Vector State registry contains an Ack 5131 Vector State, which is a number in the range 0-3; the name of the 5132 State, such as "Received ECN Marked"; and a reference to the RFC 5133 defining the State. The registry is initially populated using the 5134 values in Table 6 (Section 11.4). This document allocates States 0, 5135 1, and 3. State 2 is currently reserved, and should be allocated 5136 with the Standards Action policy, which requires DCCP working group 5137 review and standards-track RFC publication. 5139 19.7. Drop Codes 5141 Each entry in the DCCP Drop Code registry contains a Data Dropped 5142 Drop Code, which is a number in the range 0-7; the name of the Drop 5143 Code, such as "Application Not Listening"; and a reference to the 5144 RFC defining the Drop Code. The registry is initially populated 5145 using the values in Table 7 (Section 11.7). This document allocates 5146 Drop Codes 0-3 and 7. Drop Codes 4-6 are currently reserved, and 5147 should be allocated with the Standards Action policy, which requires 5148 DCCP working group review and standards-track RFC publication. 5150 19.8. Service Codes 5152 Each entry in the Service Code registry contains a Service Code, 5153 which is a number in the range 0-4294967295; a short English 5154 description of the intended service; and, when appropriate, a 5155 reference to the RFC defining the Service Code. The registry should 5156 list the Service Code's numeric value as a decimal number, but when 5157 each byte of the four-byte Service Code is in the range 32-127, the 5158 registry should also show a four-character ASCII interpretation of 5159 the Service Code. Thus, the number 1717858426 would additionally 5160 appear as "fdpz". Service Codes are not DCCP-specific. This 5161 document does not allocate any Service Codes, but Service Code 0 is 5162 permanently reserved (it represents the absence of a meaningful 5163 Service Code), and Service Codes 1056964608-1073741823 (high byte 5164 ASCII "?") are reserved for Private Use. Most of the remaining 5165 Service Codes are allocated First Come First Served, with no RFC 5166 publication required. Exceptions are listed in Section 8.1.2. 5168 20. Thanks 5170 Thanks to Jitendra Padhye for his help with early versions of this 5171 specification. 5173 Thanks to Junwen Lai and Arun Venkataramani, who, as interns at 5174 ICIR, built a prototype DCCP implementation. In particular, Junwen 5175 Lai recommended that the old feature negotiation mechanism be 5176 scrapped and helped design the current mechanism, and Arun 5177 Venkataramani's feedback improved Appendix A. 5179 We thank the staff and interns of ICIR and, formerly, ACIRI, the 5180 members of the End-to-End Research Group, and the members of the 5181 Transport Area Working Group for their feedback on DCCP. We 5182 especially thank the DCCP expert reviewers: Greg Minshall, Eric 5183 Rescorla, and Magnus Westerlund for detailed written comments and 5184 problem spotting, and Rob Austein and Steve Bellovin for verbal 5185 comments and written notes. 5187 We also thank those who provided comments and suggestions via the 5188 DCCP BOF, Working Group, and mailing lists, including Damon 5189 Lanphear, Patrick McManus, Sara Karlberg, Kevin Lai, Bernard Aboba, 5190 Youngsoo Choi, Dan Duchamp, Gorry Fairhurst, Derek Fawcus, David 5191 Timothy Fleeman, John Loughney, Ghyslain Pelletier, Tom Phelan, 5192 Stanislav Shalunov, David Vos, Yufei Wang, and Michael Welzl. In 5193 particular, Michael Welzl suggested the Data Checksum option, and 5194 Gorry Fairhurst provided extensive feedback on various checksum 5195 issues. 5197 A. Appendix: Ack Vector Implementation Notes 5199 This appendix discusses particulars of DCCP acknowledgement 5200 handling, in the context of an abstract implementation for Ack 5201 Vector. It is informative rather than normative. 5203 The first part of our implementation runs at the HC-Receiver, and 5204 therefore acknowledges data packets. It generates Ack Vector 5205 options. The implementation has the following characteristics: 5207 o At most one byte of state per acknowledged packet. 5209 o O(1) time to update that state when a new packet arrives (normal 5210 case). 5212 o Cumulative acknowledgements. 5214 o Quick removal of old state. 5216 The basic data structure is a circular buffer containing information 5217 about acknowledged packets. Each byte in this buffer contains a 5218 state and run length; the state can be 0 (packet received), 1 5219 (packet ECN marked), or 3 (packet not yet received). The buffer 5220 grows from right to left. The implementation maintains five 5221 variables, aside from the buffer contents: 5223 o "buf_head" and "buf_tail", which mark the live portion of the 5224 buffer. 5226 o "buf_ackno", the Acknowledgement Number of the most recent packet 5227 acknowledged in the buffer. This corresponds to the "head" 5228 pointer. 5230 o "buf_nonce", the one-bit sum (exclusive-or, or parity) of the ECN 5231 Nonces received on all packets acknowledged by the buffer with 5232 State 0. 5234 We draw acknowledgement buffers like this: 5236 +---------------------------------------------------------------+ 5237 |S,L|S,L|S,L|S,L| | | | |S,L|S,L|S,L|S,L|S,L|S,L|S,L|S,L| 5238 +---------------------------------------------------------------+ 5239 ^ ^ 5240 buf_tail buf_head, buf_ackno = A buf_nonce = E 5242 <=== buf_head and buf_tail move this way <=== 5244 Each `S,L' represents a State/Run length byte. We will draw these 5245 buffers showing only their live portion, and will add an annotation 5246 showing the Acknowledgement Number for the last live byte in the 5247 buffer. For example: 5249 +-----------------------------------------------+ 5250 A |S,L|S,L|S,L|S,L|S,L|S,L|S,L|S,L|S,L|S,L|S,L|S,L| T BN[E] 5251 +-----------------------------------------------+ 5253 Here, buf_nonce equals E and buf_ackno equals A. 5255 We will use this buffer as a running example. 5257 +---------------------------+ 5258 10 |0,0|3,0|3,0|3,0|0,4|1,0|0,0| 0 BN[1] [Example Buffer] 5259 +---------------------------+ 5261 In concrete terms, its meaning is as follows: 5263 Packet 10 was received. (The head of the buffer has sequence 5264 number 10, state 0, and run length 0.) 5266 Packets 9, 8, and 7 have not yet been received. (The three 5267 bytes preceding the head each have state 3 and run length 0.) 5268 Packets 6, 5, 4, 3, and 2 were received. 5270 Packet 1 was ECN marked. 5272 Packet 0 was received. 5274 The one-bit sum of the ECN Nonces on packets 10, 6, 5, 4, 3, 2, 5275 and 0 equals 1. 5277 Additionally, the HC-Receiver must keep some information about the 5278 Ack Vectors it has recently sent. For each packet sent carrying an 5279 Ack Vector, it remembers four variables: 5281 o "ack_seqno", the Sequence Number used for the packet. This is an 5282 HC-Receiver sequence number. 5284 o "ack_ptr", the value of buf_head at the time of acknowledgement. 5286 o "ack_ackno", the Acknowledgement Number used for the packet. 5287 This is an HC-Sender sequence number. Since acknowledgements are 5288 cumulative, this single number completely specifies all necessary 5289 information about the packets acknowledged by this Ack Vector. 5291 o "ack_nonce", the one-bit sum of the ECN Nonces for all State 0 5292 packets in the buffer from buf_head to ack_ackno, inclusive. 5293 Initially, this equals the Nonce Echo of the acknowledgement's 5294 Ack Vector (or, if the ack packet contained more than one Ack 5295 Vector, the exclusive-or of all the acknowledgement's Ack 5296 Vectors). It changes as information about old acknowledgements 5297 is removed (so ack_ptr and buf_head diverge), and as old packets 5298 arrive (so they change from State 3 or State 1 to State 0). 5300 A.1. Packet Arrival 5302 This section describes how the HC-Receiver updates its 5303 acknowledgement buffer as packets arrive from the HC-Sender. 5305 A.1.1. New Packets 5307 When a packet with Sequence Number greater than buf_ackno arrives, 5308 the HC-Receiver updates buf_head (by moving it to the left 5309 appropriately), buf_ackno (which is set to the new packet's Sequence 5310 Number), and possibly buf_nonce (if the packet arrived unmarked with 5311 ECN Nonce 1), in addition to the buffer itself. For example, if HC- 5312 Sender packet 11 arrived ECN marked, the Example Buffer above would 5313 enter this new state (changes are marked with stars): 5315 ** +***----------------------------+ 5316 11 |1,0|0,0|3,0|3,0|3,0|0,4|1,0|0,0| 0 BN[1] 5317 ** +***----------------------------+ 5319 If the packet's state equals the state at the head of the buffer, 5320 the HC-Receiver may choose to increment its run length (up to the 5321 maximum). For example, if HC-Sender packet 11 arrived without ECN 5322 marking and with ECN Nonce 0, the Example Buffer might enter this 5323 state instead: 5325 ** +--*------------------------+ 5326 11 |0,1|3,0|3,0|3,0|0,4|1,0|0,0| 0 BN[1] 5327 ** +--*------------------------+ 5329 Of course, the new packet's sequence number might not equal the 5330 expected sequence number. In this case, the HC-Receiver will enter 5331 the intervening packets as State 3. If several packets are missing, 5332 the HC-Receiver may prefer to enter multiple bytes with run length 5333 0, rather than a single byte with a larger run length; this 5334 simplifies table updates if one of the missing packets arrives. For 5335 example, if HC-Sender packet 12 arrived with ECN Nonce 1, the 5336 Example Buffer would enter this state: 5338 ** +*******----------------------------+ * 5339 12 |0,0|3,0|0,1|3,0|3,0|3,0|0,4|1,0|0,0| 0 BN[0] 5340 ** +*******----------------------------+ * 5342 Of course, the circular buffer may overflow, either when the HC- 5343 Sender is sending data at a very high rate, when the HC-Receiver's 5344 acknowledgements are not reaching the HC-Sender, or when the HC- 5345 Sender is forgetting to acknowledge those acks (so the HC-Receiver 5346 is unable to clean up old state). In this case, the HC-Receiver 5347 should either compress the buffer (by increasing run lengths when 5348 possible), transfer its state to a larger buffer, or, as a last 5349 resort, drop all received packets, without processing them 5350 whatsoever, until its buffer shrinks again. 5352 A.1.2. Old Packets 5354 When a packet with Sequence Number S arrives, and S <= buf_ackno, 5355 the HC-Receiver will scan the table for the byte corresponding to S. 5356 (Indexing structures could reduce the complexity of this scan.) If 5357 S was previously lost (State 3), and it was stored in a byte with 5358 run length 0, the HC-Receiver can simply change the byte's state. 5359 For example, if HC-Sender packet 8 was received with ECN Nonce 0, 5360 the Example Buffer would enter this state: 5362 +--------*------------------+ 5363 10 |0,0|3,0|0,0|3,0|0,4|1,0|0,0| 0 BN[1] 5364 +--------*------------------+ 5366 If S was not marked as lost, or if it was not contained in the 5367 table, the packet is probably a duplicate, and should be ignored. 5368 (The new packet's ECN marking state might differ from the state in 5369 the buffer; Section 11.4.1 describes what is allowed then.) If S's 5370 buffer byte has a non-zero run length, then the buffer might need be 5371 reshuffled to make space for one or two new bytes. 5373 The ack_nonce fields may also need manipulation when old packets 5374 arrive. In particular, when S transitions from State 3 or State 1 5375 to State 0, and S had ECN Nonce 1, then the implementation should 5376 flip the value of ack_nonce for every acknowledgement with ack_ackno 5377 >= S. 5379 It is impossible with this data structure to shift packets from 5380 State 0 to State 1, since the buffer doesn't store individual 5381 packets' ECN Nonces. 5383 A.2. Sending Acknowledgements 5385 Whenever the HC-Receiver needs to generate an acknowledgement, the 5386 buffer's contents can simply be copied into one or more Ack Vector 5387 options. Copied Ack Vectors might not be maximally compressed; for 5388 example, the Example Buffer above contains three adjacent 3,0 bytes 5389 that could be combined into a single 3,2 byte. The HC-Receiver 5390 might, therefore, choose to compress the buffer in place before 5391 sending the option, or to compress the buffer while copying it; 5392 either operation is simple. 5394 Every acknowledgement sent by the HC-Receiver SHOULD include the 5395 entire state of the buffer. That is, acknowledgements are 5396 cumulative. 5398 If the acknowledgement fits in one Ack Vector, that Ack Vector's 5399 Nonce Echo simply equals buf_nonce. For multiple Ack Vectors, more 5400 care is required. The Ack Vectors should be split at points 5401 corresponding to previous acknowledgements, since the stored 5402 ack_nonce fields provide enough information to calculate correct 5403 Nonce Echoes. The implementation should therefore acknowledge data 5404 at least once per 253 bytes of buffer state. (Otherwise, there'd be 5405 no way to calculate a Nonce Echo.) 5407 For each acknowledgement it sends, the HC-Receiver will add an 5408 acknowledgement record. ack_seqno will equal the HC-Receiver 5409 sequence number it used for the ack packet; ack_ptr will equal 5410 buf_head; ack_ackno will equal buf_ackno; and ack_nonce will equal 5411 buf_nonce. 5413 A.3. Clearing State 5415 Some of the HC-Sender's packets will include acknowledgement 5416 numbers, which ack the HC-Receiver's acknowledgements. When such an 5417 ack is received, the HC-Receiver finds the acknowledgement record R 5418 with the appropriate ack_seqno, then: 5420 o Sets buf_tail to R.ack_ptr + 1. 5422 o If R.ack_nonce is 1, it flips buf_nonce, and the value of 5423 ack_nonce for every later ack record. 5425 o Throws away R and every preceding ack record. 5427 (The HC-Receiver may choose to keep some older information, in case 5428 a lost packet shows up late.) For example, say that the HC-Receiver 5429 storing the Example Buffer had sent two acknowledgements already: 5431 1. ack_seqno = 59, ack_ackno = 3, ack_nonce = 1. 5433 2. ack_seqno = 60, ack_ackno = 10, ack_nonce = 0. 5435 Say the HC-Receiver then received a DCCP-DataAck packet with 5436 Acknowledgement Number 59 from the HC-Sender. This informs the HC- 5437 Receiver that the HC-Sender received, and processed, all the 5438 information in HC-Receiver packet 59. This packet acknowledged HC- 5439 Sender packet 3, so the HC-Sender has now received HC-Receiver's 5440 acknowledgements for packets 0, 1, 2, and 3. The Example Buffer 5441 should enter this state: 5443 +------------------*+ * * 5444 10 |0,0|3,0|3,0|3,0|0,2| 4 BN[0] 5445 +------------------*+ * * 5447 The tail byte's run length was adjusted, since packet 3 was in the 5448 middle of that byte. Since R.ack_nonce was 1, the buf_nonce field 5449 was flipped, as were the ack_nonce fields for later acknowledgements 5450 (here, the HC-Receiver Ack 60 record, not shown, has its ack_nonce 5451 flipped to 1). The HC-Receiver can also throw away stored 5452 information about HC-Receiver Ack 59 and any earlier 5453 acknowledgements. 5455 A careful implementation might try to ensure reasonable robustness 5456 to reordering. Suppose that the Example Buffer is as before, but 5457 that packet 9 now arrives, out of sequence. The buffer would enter 5458 this state: 5460 +----*----------------------+ 5461 10 |0,0|0,0|3,0|3,0|0,4|1,0|0,0| 0 BN[1] 5462 +----*----------------------+ 5464 The danger is that the HC-Sender might acknowledge the HC-Receiver's 5465 previous acknowledgement (with sequence number 60), which says that 5466 Packet 9 was not received, before the HC-Receiver has a chance to 5467 send a new acknowledgement saying that Packet 9 actually was 5468 received. Therefore, when packet 9 arrived, the HC-Receiver might 5469 modify its acknowledgement record to: 5471 1. ack_seqno = 59, ack_ackno = 3, ack_nonce = 1. 5473 2. ack_seqno = 60, ack_ackno = 3, ack_nonce = 1. 5475 That is, Ack 60 is now treated like a duplicate of Ack 59. This 5476 would prevent the Tail pointer from moving past packet 9 until the 5477 HC-Receiver knows that the HC-Sender has seen an Ack Vector 5478 indicating that packet's arrival. 5480 A.4. Processing Acknowledgements 5482 When the HC-Sender receives an acknowledgement, it generally cares 5483 about the number of packets that were dropped and/or ECN marked. It 5484 simply reads this off the Ack Vector. Additionally, it should check 5485 the ECN Nonce for correctness. (As described in Section 11.4.1, it 5486 may want to keep more detailed information about acknowledged 5487 packets in case packets change states between acknowledgements, or 5488 in case the application queries whether a packet arrived.) 5490 The HC-Sender must also acknowledge the HC-Receiver's 5491 acknowledgements so that the HC-Receiver can free old Ack Vector 5492 state. (Since Ack Vector acknowledgements are reliable, the HC- 5493 Receiver must maintain and resend Ack Vector information until it is 5494 sure that the HC-Sender has received that information.) A simple 5495 algorithm suffices: since Ack Vector acknowledgements are 5496 cumulative, a single acknowledgement number tells HC-Receiver how 5497 much ack information has arrived. Assuming that the HC-Receiver 5498 sends no data, the HC-Sender can ensure that at least once a round- 5499 trip time, it sends a DCCP-DataAck packet acknowledging the latest 5500 DCCP-Ack packet it has received. Of course, the HC-Sender only 5501 needs to acknowledge the HC-Receiver's acknowledgements if the HC- 5502 Sender is also sending data. If the HC-Sender is not sending data, 5503 then the HC-Receiver's Ack Vector state is stable, and there is no 5504 need to shrink it. The HC-Sender must watch for drops and ECN marks 5505 on received DCCP-Ack packets so that it can adjust the HC-Receiver's 5506 ack-sending rate -- for example, with Ack Ratio -- in response to 5507 congestion. 5509 If the other half-connection is not quiescent -- that is, the HC- 5510 Receiver is sending data to the HC-Sender, possibly using another 5511 CCID -- then the acknowledgements on that half-connection are 5512 sufficient for the HC-Receiver to free its state. 5514 B. Appendix: Design Motivation 5516 This section attempts to capture some of the rationale behind 5517 specific details of DCCP design. 5519 B.1. CsCov and Partial Checksumming 5521 A great deal of discussion has taken place regarding the utility of 5522 allowing a DCCP sender to restrict the checksum so that it does not 5523 cover the complete packet. 5525 Many of the applications that we envisage using DCCP are resilient 5526 to some degree of data loss, or they would typically have chosen a 5527 reliable transport. Some of these applications may also be 5528 resilient to data corruption -- some audio payloads, for example. 5529 These resilient applications might prefer to receive corrupted data 5530 than to have DCCP drop a corrupted packet. This is particularly 5531 because of congestion control: DCCP cannot tell the difference 5532 between packets dropped due to corruption and packets dropped due to 5533 congestion, and so it must reduce the transmission rate accordingly. 5534 This response may cause the connection to receive less bandwidth 5535 than it is due; corruption in some networking technologies is 5536 independent of, or at least not always correlated to, congestion. 5537 Therefore, corrupted packets do not need to cause as strong a 5538 reduction in transmission rate as the congestion response would 5539 dictate (so long as the DCCP header and options are not corrupt). 5541 Thus DCCP allows the checksum to cover all of the packet, just the 5542 DCCP header, or both the DCCP header and some number of bytes from 5543 the application data. If the application cannot tolerate any data 5544 corruption, then the checksum must cover the whole packet. If the 5545 application would prefer to tolerate some corruption rather than 5546 have the packet dropped, then it can set the checksum to cover only 5547 part of the packet (but always the DCCP header). In addition, if 5548 the application wishes to decouple checksumming of the DCCP header 5549 from checksumming of the application data, it may do so by including 5550 the Data Checksum option. This would allow DCCP to discard 5551 corrupted application data, but still not mistake the corruption for 5552 network congestion. 5554 Thus, from the application point of view, partial checksums seem to 5555 be a desirable feature. However, the usefulness of partial 5556 checksums depends on partially corrupted packets being delivered to 5557 the receiver. If the link-layer CRC always discards corrupted 5558 packets, then this will not happen, and so the usefulness of partial 5559 checksums would be restricted to corruption that occurred in routers 5560 and other places not covered by link CRCs. There does not appear to 5561 be consensus on how likely it is that future network links that 5562 suffer significant corruption will not cover the entire packet with 5563 a single strong CRC. DCCP makes it possible to tailor such links to 5564 the application, but it is difficult to predict if this will be 5565 compelling for future link technologies. 5567 In addition, partial checksums do not co-exist well with IP-level 5568 authentication mechanisms such as IPsec AH, which cover the entire 5569 packet with a cryptographic hash. Thus, if cryptographic 5570 authentication mechanisms are required to co-exist with partial 5571 checksums, the authentication must be carried in the application 5572 data. A possible mode of usage would appear to be similar to that 5573 of Secure RTP. However, such "application-level" authentication 5574 does not protect the DCCP option negotiation and state machine from 5575 forged packets. An alternative would be to use IPsec ESP, and use 5576 encryption to protect the DCCP headers against attack, while using 5577 the DCCP header validity checks to authenticate that the header is 5578 from someone who possessed the correct key. However, while this is 5579 resistant to replay (due to the DCCP sequence number), it is not by 5580 itself resistant to some forms of man-in-the-middle attacks because 5581 the application data is not tightly coupled to the packet header. 5582 Thus an application-level authentication probably needs to be 5583 coupled with IPsec ESP or a similar mechanism to provide a 5584 reasonably complete security solution. The overhead of such a 5585 solution might be unacceptable for some applications that would 5586 otherwise wish to use partial checksums. 5588 On balance, the authors believe that DCCP partial checksums have the 5589 potential to enable some future uses that would otherwise be 5590 difficult. As the cost and complexity of supporting them is small, 5591 it seems worth including them at this time. It remains to be seen 5592 whether they are useful in practice. 5594 Normative References 5596 [RFC 793] J. Postel, editor. Transmission Control Protocol. 5597 RFC 793. 5599 [RFC 1191] J. C. Mogul and S. E. Deering. Path MTU Discovery. 5600 RFC 1191. 5602 [RFC 2119] S. Bradner. Key Words For Use in RFCs to Indicate 5603 Requirement Levels. RFC 2119. 5605 [RFC 2434] T. Narten and H. Alvestrand. Guidelines for Writing an 5606 IANA Considerations Section in RFCs. RFC 2434. 5608 [RFC 2460] S. Deering and R. Hinden. Internet Protocol, Version 6 5609 (IPv6) Specification. RFC 2460. 5611 [RFC 3168] K.K. Ramakrishnan, S. Floyd, and D. Black. The Addition 5612 of Explicit Congestion Notification (ECN) to IP. RFC 3168. 5614 [RFC 3309] J. Stone, R. Stewart, and D. Otis. Stream Control 5615 Transmission Protocol (SCTP) Checksum Change. RFC 3309. 5617 [RFC 3692] T. Narten. Assigning Experimental and Testing Numbers 5618 Considered Useful. RFC 3692. 5620 [RFC 3775] D. Johnson, C. Perkins, and J. Arkko. Mobility Support 5621 in IPv6. RFC 3775. 5623 [RFC 3828] L-A. Larzon, M. Degermark, S. Pink, L-E. Jonsson, editor, 5624 and G. Fairhurst, editor. The Lightweight User Datagram Protocol 5625 (UDP-Lite). RFC 3828. 5627 Informative References 5629 [BB01] S.M. Bellovin and M. Blaze. Cryptographic Modes of Operation 5630 for the Internet. 2nd NIST Workshop on Modes of Operation, 5631 August 2001. 5633 [BEL98] S.M. Bellovin. Cryptography and the Internet. Proc. CRYPTO 5634 '98 (LNCS 1462), pp46-55, August, 1988. 5636 [CCID 2 PROFILE] S. Floyd and E. Kohler. Profile for DCCP 5637 Congestion Control ID 2: TCP-like Congestion Control. draft- 5638 ietf-dccp-ccid2-05.txt, work in progress, February 2004. 5640 [CCID 3 PROFILE] S. Floyd, E. Kohler, and J. Padhye. Profile for 5641 DCCP Congestion Control ID 3: TFRC Congestion Control. draft- 5642 ietf-dccp-ccid3-05.txt, work in progress, February 2004. 5644 [M85] Robert T. Morris. A Weakness in the 4.2BSD Unix TCP/IP 5645 Software. Computer Science Technical Report 117, AT&T Bell 5646 Laboratories, Murray Hill, NJ, February 1985. 5648 [PMTUD] Matt Mathis, John Heffner, and Kevin Lahey. Path MTU 5649 Discovery. draft-ietf-pmtud-method-01.txt, work in progress, 5650 February 2004. 5652 [RFC 792] J. Postel, editor. Internet Control Message Protocol. 5653 RFC 792. 5655 [RFC 1750] D. Eastlake, S. Crocker, and J. Schiller. Randomness 5656 Recommendations for Security. RFC 1750. 5658 [RFC 1948] S. Bellovin. Defending Against Sequence Number Attacks. 5659 RFC 1948. 5661 [RFC 2018] M. Mathis, J. Mahdavi, S. Floyd, and A. Romanow. TCP 5662 Selective Acknowledgement Options. RFC 2018. 5664 [RFC 2401] S. Kent and R. Atkinson. Security Architecture for the 5665 Internet Protocol. RFC 2401. 5667 [RFC 2581] M. Allman, V. Paxson, and W. Stevens. TCP Congestion 5668 Control. RFC 2581. 5670 [RFC 2960] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. 5671 Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, and V. 5672 Paxson. Stream Control Transmission Protocol. RFC 2960. 5674 [RFC 3124] H. Balakrishnan and S. Seshan. The Congestion Manager. 5675 RFC 3124. 5677 [RFC 3360] S. Floyd. Inappropriate TCP Resets Considered Harmful. 5678 RFC 3360. 5680 [RFC 3448] M. Handley, S. Floyd, J. Padhye, and J. Widmer. TCP 5681 Friendly Rate Control (TFRC): Protocol Specification. RFC 3448. 5683 [RFC 3540] N. Spring, D. Wetherall, and D. Ely. Robust Explicit 5684 Congestion Notification (ECN) Signaling with Nonces. RFC 3540. 5686 [RFC 3550] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson. 5687 RTP: A Transport Protocol for Real-Time Applications. STD 64. 5688 RFC 3550. 5690 [RFC 3611] T. Friedman, R. Caceres, and A. Clark, editors. RTP 5691 Control Protocol Extended Reports (RTCP XR). RFC 3611. 5693 [RFC 3819] P. Karn, editor, C. Bormann, G. Fairhurst, D. Grossman, 5694 R. Ludwig, J. Mahdavi, G. Montenegro, J. Touch, and L. Wood. 5695 Advice for Internet Subnetwork Designers. RFC 3819. 5697 [SHHP00] Oliver Spatscheck, Jorgen S. Hansen, John H. Hartman, and 5698 Larry L. Peterson. Optimizing TCP Forwarder Performance. 5699 IEEE/ACM Transactions on Networking 8(2):146-157, April 2000. 5701 [SYNCOOKIES] Daniel J. Bernstein. SYN Cookies. 5702 http://cr.yp.to/syncookies.html, as of July 2003. 5704 Authors' Addresses 5706 Eddie Kohler 5707 4531C Boelter Hall 5708 UCLA Computer Science Department 5709 Los Angeles, CA 90095 5710 USA 5712 Mark Handley 5713 Department of Computer Science 5714 University College London 5715 Gower Street 5716 London WC1E 6BT 5717 UK 5719 Sally Floyd 5720 ICSI Center for Internet Research 5721 1947 Center Street, Suite 600 5722 Berkeley, CA 94704 5723 USA 5725 Full Copyright Statement 5727 Copyright (C) The Internet Society 2004. This document is subject 5728 to the rights, licenses and restrictions contained in BCP 78, and 5729 except as set forth therein, the authors retain all their rights. 5731 This document and the information contained herein are provided on 5732 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 5733 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 5734 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 5735 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 5736 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 5737 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 5739 Intellectual Property 5741 The IETF takes no position regarding the validity or scope of any 5742 Intellectual Property Rights or other rights that might be claimed 5743 to pertain to the implementation or use of the technology described 5744 in this document or the extent to which any license under such 5745 rights might or might not be available; nor does it represent that 5746 it has made any independent effort to identify any such rights. 5747 Information on the procedures with respect to rights in RFC 5748 documents can be found in BCP 78 and BCP 79. 5750 Copies of IPR disclosures made to the IETF Secretariat and any 5751 assurances of licenses to be made available, or the result of an 5752 attempt made to obtain a general license or permission for the use 5753 of such proprietary rights by implementers or users of this 5754 specification can be obtained from the IETF on-line IPR repository 5755 at http://www.ietf.org/ipr. 5757 The IETF invites any interested party to bring to its attention any 5758 copyrights, patents or patent applications, or other proprietary 5759 rights that may cover technology that may be required to implement 5760 this standard. Please address the information to the IETF at ietf- 5761 ipr@ietf.org.