SUBSTANTIVE DIFFERENCES BETWEEN draft-ietf-dccp-spec-11 AND draft-ietf-dccp-spec-13 =========================================================================== Since the original Working Group Last Call, we have collected several editorial and substantive fixes, and at Allison Mankin's suggestion we are updating the draft. Here are all the changes with explanations. Changes below the equal-sign line are only in 13. Editorial change: The boilerplate was updated. A Colored Petri Net model produced by Somsak Vanit-Anunchai, Jonathan Billington, and Tul Kongprakaiwoot discovered a problem with DCCP-Reset and DCCP-Sync interaction. A DCCP-Reset can be sent with an invalid Sequence Number when, for example, the Reset is sent from a CLOSED connection in response to a DCCP-Data packet (which has no acknowledgement number). The problem: The DCCP-Sync packet sent in response wouldn't give the CLOSED endpoint enough information to send a valid Reset, leading to a long (but finite) Sync-Reset-Sync-Reset-Sync-Reset exchange. The solution: When sending a DCCP-Sync packet in response to a Reset, provide enough information to make the next Reset valid---that is, provide GSR. @@ Page 55, Section 7.5.4 @@ OLD: Endpoints MUST ignore sequence-invalid DCCP-Sync and DCCP-SyncAck packets, and MUST respond to other sequence-invalid packets with (possibly rate-limited) DCCP-Sync packets. Each DCCP-Sync packet MUST acknowledge the corresponding sequence-invalid packet's Sequence Number, not GSR. The DCCP-Sync MUST use a new Sequence Number, and thus will increase GSS; GSR will not change, however, since the received packet was sequence-invalid. NEW: Endpoints MUST ignore sequence-invalid DCCP-Sync and DCCP-SyncAck packets, and MUST respond to other sequence-invalid packets with (possibly rate-limited) DCCP-Sync packets. Each such DCCP-Sync packet MUST use a new Sequence Number, and thus will increase GSS; GSR will not change, however, since the received packet was sequence-invalid. Each such DCCP-Sync packet's Acknowledgement Number MUST equal GSR when the received sequence-invalid packet has type DCCP-Reset, and the received packet's Sequence Number otherwise. @@ Page 73, Section 8.5 @@ OLD: (from the end of Step 6) Otherwise, Send Sync packet acknowledging P.seqno Drop packet and return NEW: Otherwise, If P.type == Reset, Send Sync packet acknowledging S.GSR Otherwise, Send Sync packet acknowledging P.seqno Drop packet and return @@ Page 115, Section 20 @@ OLD: Bernard Aboba, Youngsoo Choi, Pengfei Di, Dan Duchamp, Gorry Fairhurst, Derek Fawcus, David Timothy Fleeman, John Loughney, Ghyslain Pelletier, Tom Phelan, Stanislav Shalunov, David Vos, Yufei Wang, and Michael Welzl. In particular, Colin Perkins provided extensive, detailed feedback, Michael Welzl suggested the Data Checksum option, and Gorry Fairhurst provided extensive feedback on various checksum issues. NEW: Bernard Aboba, Youngsoo Choi, Pengfei Di, Dan Duchamp, Gorry Fairhurst, Derek Fawcus, David Timothy Fleeman, John Loughney, Ghyslain Pelletier, Tom Phelan, Stanislav Shalunov, Somsak Vanit- Anunchai, David Vos, Yufei Wang, and Michael Welzl. In particular, Colin Perkins provided extensive, detailed feedback, Michael Welzl suggested the Data Checksum option, Gorry Fairhurst provided extensive feedback on various checksum issues, and Somsak Vanit- Anunchai et al.'s Colored Petri Net model discovered a problem with message exchange. Somsak Vanit-Anunchai also reported an error in the procedure for extending short sequence numbers to long sequence numbers. That procedure would fail in the presence of packet reordering. It needs to check for wrapping the sequence space in either direction. @@ Page 59, Section 7.6 @@ OLD: Set REF_low := low 24 bits of REF Set REF_hi := high 24 bits of REF If REF_low (<) S /* circular comparison mod 2^24 */ && S |<| REF_low, /* conventional, non-circular comparison */ Return (((REF_hi + 1) mod 2^24) << 24) | S Otherwise, Return (REF_hi << 24) | S The two different kinds of comparison in the if statement detect when the low-order bits of the sequence space have wrapped. (The circular comparison "REF_low (<) S" returns true if and only if (S - REF_low), calculated using two's-complement arithmetic and then represented as an unsigned number, is less than or equal to 2^23 (mod 2^24).) When this happens, the high-order bits are incremented. NEW: Set REF_low := low 24 bits of REF Set REF_hi := high 24 bits of REF If REF_low (<) S /* circular comparison mod 2^24 */ and S |<| REF_low, /* conventional, non-circular comparison */ Return (((REF_hi + 1) mod 2^24) << 24) | S Otherwise, if S (<) REF_low and REF_low |<| S, Return (((REF_hi - 1) mod 2^24) << 24) | S Otherwise, Return (REF_hi << 24) | S The two different kinds of comparison in the if statements detect when the low-order bits of the sequence space have wrapped. (The circular comparison "REF_low (<) S" returns true if and only if (S - REF_low), calculated using two's-complement arithmetic and then represented as an unsigned number, is less than or equal to 2^23 (mod 2^24).) When this happens, the high-order bits are incremented or decremented, as appropriate. This editorial change was also found by Somsak Vanit-Anunchai: there is no CLOSE state in the protocol. We meant CLOSING. @@ Page 69, Section 8.3 @@ OLD: DCCP-Data, DCCP-DataAck, and DCCP-Ack packets received in CLOSEREQ or CLOSE states MAY be either processed or ignored. NEW: DCCP-Data, DCCP-DataAck, and DCCP-Ack packets received in CLOSEREQ or CLOSING states MAY be either processed or ignored. Somsak Vanit-Anunchai also pointed out that the pseudocode was insufficiently clear about where S.GAR was set. This clarification is merely editorial. @@ Page 72, Section 8.5 @@ OLD: (from Step 2) S.state = RESPOND Choose S.ISS (initial seqno) or set from Init Cookie Set S.ISR, S.GSR, S.SWL, S.SWH from packet or Init Cookie Continue with S.state == RESPOND NEW: S.state = RESPOND Choose S.ISS (initial seqno) or set from Init Cookie Initialize S.GAR := S.ISS Set S.ISR, S.GSR, S.SWL, S.SWH from packet or Init Cookie Continue with S.state == RESPOND Yoshifumi Nishida requested that one Service Code be marked invalid, for ease of implementation. @@ Page 64, Section 8.1.2 @@ OLD: o Service Code 0 represents the absence of a meaningful Service Code, and MUST NOT be allocated. NEW: === NOTE CHANGE FROM -12 DRAFT === o Service Code 0 represents the absence of a meaningful Service Code, and MUST NOT be allocated. o The value 4294967295 is an invalid Service Code. Servers MUST reject any DCCP-Request with this Service Code value by sending a DCCP-Reset packet with Reset Code 8, "Bad Service Code". CHANGE AS OF -12 DRAFT: o Service Code 0 represents the absence of a meaningful Service Code, and MUST NOT be allocated. o The value 4294967295 is an invalid Service Code, and MUST NOT appear in the Service Code field of a DCCP-Request or DCCP- Response packet. @@ Page 115, Section 19.8 @@ OLD: Each entry in the Service Code registry contains a Service Code, which is a number in the range 0-4294967295; a short English ... NEW: Each entry in the Service Codes registry contains a Service Code, which is a number in the range 0-4294967294; a short English ... Colin Perkins pointed out that draft version 11 did not list well-known port numbers in its IANA Considerations section. This was an oversight. After some discussion on ways to address the registration procedure, we came up with the following simple procedure, which should mesh well with existing IANA practice for Port Numbers. The changes also include a convention for representing Service Codes in text, a single Service Code allocation (for discard), a single Port Number allocation (for discard), and a statement to the effect that IANA has in fact allocated Protocol Number 33 for DCCP. @@ Page 24, Section 5.1 @@ OLD: DCCP APIs should treat port numbers similarly to TCP and UDP port numbers. For example, machines that distinguish between "privileged" and "unprivileged" ports for TCP and UDP should do the same for DCCP. NEW: DCCP APIs should treat port numbers similarly to TCP and UDP port numbers. For example, machines that distinguish between "privileged" and "unprivileged" ports for TCP and UDP should do the same for DCCP. See Section 19.9 for more discussion. @@ Page 64, Section 8.1.2 @@ NEW: [[Add these paragraphs to the end of the section]] In text settings, we recommend that Service Codes be written in one of three forms, prefixed by the ASCII letters SC and either a colon ":" or equals sign "=". These forms are interpreted as follows. SC: Indicates a Service Code representable using a subset of the ASCII characters. The colon is followed by between one and four characters taken from the following set: letters, digits, and the characters in "-_+.*/?@" (not including quotes). Numerically, these characters have values in {42-43, 45-57, 63-90, 95, 97-122}. The Service Code is calculated by padding the string on the right with spaces (value 32) and intepreting the four-character result as a 32-bit big-endian number. SC= Indicates a decimal Service Code. The octothorp is followed by any number of decimal digits, which specify the Service Code. Values above 4294967294 are illegal. SC=x or SC=X Indicates a hexadecimal Service Code. The "x" or "X" is followed by any number of hexadecimal digits (upper or lower case), which specify the Service Code. Values above 4294967294 are illegal. Thus, the Service Code 1717858426 might be represented in text as either SC:fdpz, SC=1717858426, or SC=x6664707A. @@ Page 113, Section 19 @@ OLD: DCCP introduces eight sets of numbers whose values should be allocated by IANA. We refer to allocation policies, such as Standards Action, outlined in RFC 2434, and most registries reserve some values for experimental and testing use [RFC 3692]. In addition, DCCP requires a Protocol Number to be added to the registry of Assigned Internet Protocol Numbers. IANA is requested to assign IP Protocol Number 33 to DCCP; this number has already been informally made available for experimental DCCP use. NEW: IANA has assigned IP Protocol Number 33 to DCCP. DCCP introduces eight sets of numbers whose values should be allocated by IANA. We refer to allocation policies, such as Standards Action, outlined in RFC 2434, and most registries reserve some values for experimental and testing use [RFC 3692]. In addition, DCCP requires that the IANA Port Numbers registry be opened for DCCP port registrations; Section 19.9 describes how. @@ Page 115, Section 19.8 @@ OLD: ... Service Codes are not DCCP-specific. This document does not allocate any Service Codes, but Service Code 0 is permanently reserved (it represents the absence of a meaningful Service Code), and Service Codes 1056964608-1073741823 (high byte ASCII "?") are reserved for Private Use. Most of the remaining Service Codes are allocated First Come First Served, with no RFC publication required. Exceptions are listed in Section 8.1.2. NEW: ... Service Codes are not DCCP-specific. Service Code 0 is permanently reserved (it represents the absence of a meaningful Service Code), and Service Codes 1056964608-1073741823 (high byte ASCII "?") are reserved for Private Use. Note that 4294967295 is not a valid Service Code. Most of the remaining Service Codes are allocated First Come First Served, with no RFC publication required; exceptions are listed in Section 8.1.2. This document allocates a single Service Code, 1145656131 ("DISC"). This corresponds to the discard service, which discards all data sent to the service and sends no data in reply. @@ Page 116 @@ NEW: [[Add new section 19.9]] === NOTE THAT THIS IS THE 13 VERSION === 19.9. Port Numbers DCCP services may use contact port numbers to provide service to unknown callers, as in TCP and UDP. IANA is therefore requested to open the existing Port Numbers registry for DCCP using the following rules, which we intend to mesh well with existing Port Numbers registration procedures. Port numbers are divided into three ranges. The Well Known Ports are those from 0 through 1023, the Registered Ports are those from 1024 through 49151, and the Dynamic and/or Private Ports are those from 49152 through 65535. Well Known and Registered Ports are intended for use by server applications that desire a default contact point on a system. On most systems, Well Known Ports can only be used by system (or root) processes or by programs executed by privileged users, while Registered Ports can be used by ordinary user processes or programs executed by ordinary users. Dynamic and/or Private Ports are intended for temporary use, including client-side ports, out-of-band negotiated ports, and application testing prior to registration of a dedicated port; they MUST NOT be registered. The Port Numbers registry should accept registrations for DCCP ports in the Well Known Ports and Registered Ports ranges. Well Known and Registered Ports SHOULD NOT be used without registration. Although in some cases -- such as porting an application from UDP to DCCP -- it may seem natural to use a DCCP port before registration completes, we emphasize that IANA will not guarantee registration of particular Well Known and Registered Ports. Registrations should be requested as early as possible. Each port registration SHALL include the following information: o A short port name, consisting entirely of letters (A-Z and a-z), digits (0-9), and punctuation characters from "-_+./*" (not including the quotes). o The port number that is requested to be registered. o A short English phrase describing the port's purpose. This MUST include one or more space-separated textual Service Code descriptors naming the port's corresponding Service Codes (see Section 8.1.2). o Name and contact information for the person or entity performing the registration, and possibly a reference to a document defining the port's use. Registrations coming from IETF working groups need only name the working group, but it is also recommended to indicate a contact person. Registrants are encouraged to follow these guidelines when submitting a registration. The guidelines may be violated at IANA's discretion. o A port name SHOULD NOT be registered for more than one DCCP port number. o A port name registered for UDP MAY be registered for DCCP as well. Any such registration SHOULD use the same port number as the existing UDP registration. o Concrete intent to use a port SHOULD precede port registration. For example, existing UDP ports SHOULD NOT be registered in advance of any intent to use those ports for DCCP. o A port name generally associated with TCP and/or SCTP SHOULD NOT be registered for DCCP, since that port name implies reliable transport. For example, we discourage registration of any "http" port for DCCP. However, if such a registration makes sense (that is, if there is concrete intent to use such a port), the DCCP registration SHOULD use the same port number as the existing registration. o Multiple DCCP registrations for the same port number are allowed as long as the registrations' Service Codes do not overlap. This document registers the following port. (This should be considered a model registration.) discard 9/dccp Discard SC:DISC # IETF dccp WG, Eddie Kohler , DCCP RFC The discard service, which accepts DCCP connections on port 9, discards all incoming application data and sends no data in response. Thus, DCCP's discard port is analogous to TCP's discard port, and might be used to check the health of a DCCP stack. Editorial change: Several section names were changed to ensure that every section name in the document is unique. Rather than OLD/NEW format, here is a table. In the case of the Registries (19.1-19.8), the text was also changed to refer to, e.g., NEW "Reset Codes registry" rather than OLD "Reset Code registry" (note difference in pluralization). Section Old New ------- ----------------------------- ----------------------------- 4.2 Sequence Numbers Packet Sequencing 4.4 Congestion Control Congestion Control Mechanisms 4.5 Features Connection Features 6.5 Examples Feature Negotiation Examples 7.5.6 Examples Sequence Number Handling Examples 7.7.1 Usage Notes NDP Count Usage Notes 9.3.2 Usage Notes Checksum Usage Notes 19.1 Packet Types Packet Types Registry 19.2 Reset Codes Reset Codes Registry 19.3 Option Types Option Types Registry 19.4 Feature Numbers Feature Numbers Registry 19.5 Congestion Control Congestion Control Identifiers Identifiers Registry 19.6 Ack Vector States Ack Vector States Registry 19.7 Drop Codes Drop Codes Registry 19.8 Service Codes Service Codes Registry OTHER CHANGES IN DRAFT VERSION 13 =============================================================================== Editorial change: In discussion with Tom Phelan, it seemed that "equal" was clearer than "match" when discussing Service Code correspondence. @@ Page 62, Section 8.1.2 @@ OLD: If the DCCP-Request's Service Code doesn't match any of the server's Service Codes for the given port, ... NEW: If the DCCP-Request's Service Code doesn't equal any of the server's Service Codes for the given port, ... Editorial change: The "like" language was too Valley Girl. This is clearer. @@ Page 31, Section 5.6 @@ OLD: 12-127, Reserved Receivers should treat these codes like Reset Code 0, "Unspecified". 128-255, CCID-specific codes Semantics depend on the connection's CCIDs. See Section 10.3. Receivers should treat unknown CCID-specific Reset Codes like Reset Code 0, "Unspecified". NEW: 12-127, Reserved Receivers should treat these codes as they do Reset Code 0, "Unspecified". 128-255, CCID-specific codes Semantics depend on the connection's CCIDs. See Section 10.3. Receivers should treat unknown CCID-specific Reset Codes as they do Reset Code 0, "Unspecified". Editorial change: Define Flow ID. @@ Page 71, Section 8.5 @@ OLD: Step 2: Check ports and process TIMEWAIT state Look up flow ID in table and get corresponding socket NEW: Step 2: Check ports and process TIMEWAIT state /* Flow ID is 4-tuple */ Look up flow ID in table and get corresponding socket Editorial change: Suggested by the RFC Editor. @@ Page 110, Section 17.2 @@ OLD: Since DCCP doesn't provide reliable, ordered delivery, multiple application sub-flows may be multiplexed over a single DCCP connection with no inherent performance penalty. Thus, there is no need for DCCP to provide built-in, SCTP-style support for multiple sub-flows. NEW: Since DCCP doesn't provide reliable, ordered delivery, multiple application sub-flows may be multiplexed over a single DCCP connection with no inherent performance penalty. Thus, there is no need for DCCP to provide built-in support for multiple sub-flows. This differs from SCTP [RFC 2960]. Editorial change: Remove the only backtick in the spec. @@ Page 118, Appendix A @@ OLD Each `S,L' represents a State/Run length byte. We will draw these NEW Each "S,L" represents a State/Run length byte. We will draw these