SUBSTANTIVE DIFFERENCES BETWEEN draft-ietf-dccp-spec-09 AND draft-ietf-dccp-spec-11 =========================================================================== This change (in the -11 draft) was requested by gen-art. @@ Page 11, Section 2 @@ OLD: This form of arithmetic preserves the relationships between sequence numbers as they roll over from 2**48 - 1 to 0. NEW: This form of arithmetic preserves the relationships between sequence numbers as they roll over from 2**48 - 1 to 0. Implementation strategies for DCCP sequence numbers will resemble those for other circular arithmetic spaces, including TCP's sequence numbers [RFC 793] and DNS's serial numbers [RFC 1982]. ((Also add a reference to RFC 1982 in Informative References.)) This clarification separates the cases of "nonsensical length" and "invalid length/data", which were formerly conflated. It specifies that any option space following a nonsensical-length option must be ignored, which is really just a clarification -- I think any implementer would have done that anyway. @@ Page 34, Section 5.8 @@ OLD: Options with unknown types, and options with invalid lengths (length byte less than two or more than the remaining space in the options portion of the header), MUST be ignored. NEW: Options with unknown types MUST be ignored. Also, options with nonsensical lengths (length byte less than two or more than the remaining space in the options portion of the header) MUST be ignored, and any option space following an option with nonsensical length MUST likewise be ignored. OLD: ((no text; add the following paragraph before "This section describes two generic options...")) NEW: Options with invalid values MUST be ignored unless otherwise specified. For example, any Data Checksum option with option length 4 MUST be ignored, since all valid Data Checksum options have option length 6. The Sequence Window feature was 6 bytes long, but we formerly allowed feature options to contain smaller data, which was padded on the left with zeros in the obvious way. Magnus Westerlund requested that we disallow this in WGLC review. @@ Page 52, Section 7.5.2 @@ OLD: It takes 48-bit (6-byte) integer values, like DCCP sequence numbers, but 1- to 5-byte values are also allowed in options; the receiver will pad on the left with zero bytes as necessary to total 48 bits. Change and Confirm options for Sequence Window are therefore between 4 and 9 bytes long. NEW: It takes 48-bit (6-byte) integer values, like DCCP sequence numbers. Change and Confirm options for Sequence Window are therefore 9 bytes long. @@ Page 40, Section 6.5 @@ OLD: Change L(Sequence Window, 1024) = 32,6,3,0,4,0 DCCP B should change Sequence Window/A's value (feature number 3, a non-negotiable feature) to the 3-byte string 0,4,0 (the value 1024). NEW: Change L(Sequence Window, 1024) = 32,9,3,0,0,0,0,4,0 DCCP B should change Sequence Window/A's value (feature number 3, a non-negotiable feature) to the 6-byte string 0,0,0,0,4,0 (the value 1024). OLD: Confirm R(Sequence Window, 1024) = 35,6,3,0,4,0 DCCP A has changed Sequence Window/B's value to the 3-byte string 0,4,0 (the value 1024). NEW: Confirm R(Sequence Window, 1024) = 35,9,3,0,0,0,0,4,0 DCCP A has changed Sequence Window/B's value to the 6-byte string 0,0,0,0,4,0 (the value 1024). This text was added on 12/1/2004 after discussion between the authors about evading congestion control through switching CCIDs. @@ Page 83, Section 10.5 @@ OLD: ((no text; add the NEW paragraph at the end of the section)) NEW: A DCCP implementation MAY also reset its congestion state when a CCID changes (that is, a negotiation for the CCID feature completes successfully, and the new feature value differs from the old value). Thus, a connection in a heavily congested environment might evade end-to-end congestion control by frequently renegotiating a CCID, just as it could evade end-to-end congestion control by opening new connections for the same session. This behavior is prohibited. To prevent it, DCCP implementations MAY limit the rate at which CCID can be changed -- for instance, by refusing to change a CCID feature value more than once per minute. Previously the Receive Buffer Drops option could cause the sender to stop sending altogether. The WG decided this behavior was needlessly conservative. @@ Page 97, Section 11.7.2 @@ OLD: Every packet newly acknowledged as Drop Code 2 SHOULD reduce the sender's instantaneous rate by one packet per round-trip time. NEW: Every packet newly acknowledged as Drop Code 2 SHOULD reduce the sender's instantaneous rate by one packet per round-trip time, unless the sender is already sending one packet per RTT or less. After extensive, nearly endless, discussion with Colin Perkins and others on the WG list, it was decided to change the units of the Elapsed Time option from tenths of milliseconds to hundredths of milliseconds, so as to support finer-grained measurements (Colin produced data arguing that tenths of milliseconds wouldn't be good enough). For some reason, the published draft has the correct *numbers* -- it says that the maximum elapsed time reportable with 2 bytes of option data is 0.65535 seconds, for example -- but not the correct *units*. @@ Page 101, Section 13.2 @@ OLD: The option data, Elapsed Time, represents an estimated upper bound on the amount of time elapsed since the packet being acknowledged was received, with units of tenths of milliseconds. NEW: The option data, Elapsed Time, represents an estimated upper bound on the amount of time elapsed since the packet being acknowledged was received, with units of hundredths of milliseconds. This is really editorial. @@ Page 103, Section 14.1 @@ OLD: In IPv4, these packets have the IP Don't Fragment (DF) bit set; in IPv6, all packets are unfragmentable. NEW: In IPv4, these packets have the IP Don't Fragment (DF) bit set; in IPv6, all packets are unfragmentable once emitted by an end host. Fernando Gont asked for a clarification on required router behavior for PMTU. @@ Page 104, Section 14.1 @@ OLD: (Routers are not required to return more than 64 bits of the DCCP header [RFC 792], but most modern routers will return far more, including the Sequence Number.) NEW: (According to current specifications, routers should return the full DCCP header and payload up to a maximum of 576 bytes [RFC 1812] or the minimum IPv6 MTU [RFC 2463], although they are not required to return more than 64 bits [RFC 792]. Any amount greater than 128 bits will include the Sequence Number.) These changes were requested by the IESG; the first by Allison (reworded slightly), the second by Russ Housley, the remainder by Allison. @@ Page 109, Section 18 @@ OLD: Applications desiring hard security should use IPsec or end-to-end security of some kind. NEW: Applications desiring cryptographic security services (integrity, authentication, confidentiality, access control, and anti-replay protection) should use IPsec or end-to-end security of some kind; Secure RTP is one candidate protocol [RFC 3711]. @@ Page 110, Section 18 (there is also an editorial change, not shown) @@ OLD: ((no text; add this paragraph before "DCCP provides no protection...")) NEW: DCCP also provides mechanisms to limit the potential impact of some denial-of-service attacks. These mechanisms include Init Cookie (Section 8.1.4), the DCCP-CloseReq packet (Section 5.5), the Application Not Listening Drop Code (Section 11.7.2), limitations on the processing of options that might cause connection reset (Section 7.5.5), limitations on the processing of some ICMP messages (Section 14.1), and various rate limits, which let servers avoid extensive computation or packet generation (Sections 7.5.3, 8.1.3, and others). @@ Page 112, Section 19.1 @@ OLD: Packet types 10-13 and 15 are currently reserved, and should be allocated with the Standards Action policy, which requires IETF working group review and standards-track RFC publication. NEW: Packet types 10-13 and 15 are currently reserved, and should be allocated with the Standards Action policy, which requires IESG review and approval and standards-track IETF RFC publication. @@ Page 112, Section 19.2 @@ OLD: Reset Codes 12-119 and 127 are currently reserved, and should be allocated with the IETF Consensus policy, which requires RFC publication (not necessarily standards- track). NEW: Reset Codes 12-119 and 127 are currently reserved, and should be allocated with the IETF Consensus policy, requiring an IETF RFC publication (standards-track or not) with IESG review and approval. @@ Page 112, Section 19.3 @@ OLD: Option types 3-30, 45-119, and 127 are currently reserved, and should be allocated with the IETF Consensus policy, which requires RFC publication (not necessarily standards-track). NEW: Option types 3-30, 45-119, and 127 are currently reserved, and should be allocated with the IETF Consensus policy, requiring an IETF RFC publication (standards-track or not) with IESG review and approval. @@ Page 112, Section 19.4 @@ OLD: Feature numbers 10-119 and 127 are currently reserved, and should be allocated with the IETF Consensus policy, which requires RFC publication (not necessarily standards-track). NEW: Feature numbers 10-119 and 127 are currently reserved, and should be allocated with the IETF Consensus policy, requiring an IETF RFC publication (standards- track or not) with IESG review and approval. @@ Page 114, Section 19.5 @@ OLD: CCIDs 0, 1, 4-247, and 255 are currently reserved, and should be allocated with the IETF Consensus policy, which requires RFC publication (not necessarily standards-track). NEW: CCIDs 0, 1, 4-247, and 255 are currently reserved, and should be allocated with the IETF Consensus policy, requiring an IETF RFC publication (standards-track or not) with IESG review and approval. @@ Page 114, Section 19.6 @@ OLD: State 2 is currently reserved, and should be allocated with the Standards Action policy, which requires IETF working group review and standards-track RFC publication. NEW: State 2 is currently reserved, and should be allocated with the Standards Action policy, which requires IESG review and approval and standards-track IETF RFC publication. @@ Page 114, Section 19.7 @@ OLD: Drop Codes 4-6 are currently reserved, and should be allocated with the Standards Action policy, which requires IETF working group review and standards-track RFC publication. NEW: Drop Codes 4-6 are currently reserved, and should be allocated with the Standards Action policy, which requires IESG review and approval and standards-track IETF RFC publication.