The files defines.h and misc.c refer to the wrong constants. It should be: IPTOS_CLASS_CS0 and not: IPTOS_DSCP_CS0 (etc for 0..7). These constants are externally defined in /usr/include/netinet/ip.h in glibc 2.12 and later. Add: #define IPTOS_CLASS_DEFAULT IPTOS_CLASS_CS0 Also, the table ipqos[] should probably include: { "none", IPTOS_CLASS_DEFAULT }, Lastly, the ToS values defines in RFC-791 were deprecated in 1998 with the introduction of RFC-2474. The bit assignments used in RFC-791 now conflict with other RFCs in deployment such as RFC-3168 (section 5 "Explicit Congestion Notification in IP"). It's strongly recommended that the lines: if (options->ip_qos_interactive == -1) options->ip_qos_interactive = IPTOS_LOWDELAY; if (options->ip_qos_bulk == -1) options->ip_qos_bulk = IPTOS_THROUGHPUT; in servconf.c and readconf.c be replaced by: if (options->ip_qos_interactive == -1) options->ip_qos_interactive = IPTOS_DSCP_AF21; if (options->ip_qos_bulk == -1) options->ip_qos_bulk = IPTOS_DSCP_AF11; as per the definitions in RFC-4594 sections 4.7 ("Low-Latency Data Service Class") and 4.8 ("High-Throughput Data Service Class"), respectively... and the documentation of the default values be updated accordingly.
Also, the defaults should be explicitly called out in a comment in sshd_config and ssh_config.
Created attachment 1995 [details] Fix IPTOS_CLASS_CSx naming and change default values to something not obsolete
Quoting the entire Section 3 of RFC-2474 for reference: 3. Differentiated Services Field Definition A replacement header field, called the DS field, is defined, which is intended to supersede the existing definitions of the IPv4 TOS octet [RFC791] and the IPv6 Traffic Class octet [IPv6]. Six bits of the DS field are used as a codepoint (DSCP) to select the PHB a packet experiences at each node. A two-bit currently unused (CU) field is reserved and its definition and interpretation are outside the scope of this document. The value of the CU bits are ignored by differentiated services-compliant nodes when determining the per-hop behavior to apply to a received packet. The DS field structure is presented below: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | DSCP | CU | +---+---+---+---+---+---+---+---+ DSCP: differentiated services codepoint CU: currently unused In a DSCP value notation 'xxxxxx' (where 'x' may equal '0' or '1') used in this document, the left-most bit signifies bit 0 of the DS field (as shown above), and the right-most bit signifies bit 5. Implementors should note that the DSCP field is six bits wide. DS- compliant nodes MUST select PHBs by matching against the entire 6-bit DSCP field, e.g., by treating the value of the field as a table index which is used to select a particular packet handling mechanism which has been implemented in that device. The value of the CU field MUST be ignored by PHB selection. The DSCP field is defined as an unstructured field to facilitate the definition of future per-hop behaviors. With some exceptions noted below, the mapping of codepoints to PHBs MUST be configurable. A DS-compliant node MUST support the logical equivalent of a configurable mapping table from codepoints to PHBs. PHB specifications MUST include a recommended default codepoint, which MUST be unique for codepoints in the standard space (see Sec. 6). Implementations should support the recommended codepoint-to-PHB mappings in their default configuration. Operators may choose to use different codepoints for a PHB, either in addition to or in place of the recommended default. Note that if operators do so choose, re- marking of DS fields may be necessary at administrative boundaries even if the same PHBs are implemented on both sides of the boundary. See [ARCH] for further discussion of re-marking. The exceptions to general configurability are for codepoints 'xxx000' and are noted in Secs. 4.2.2 and 4.3. Packets received with an unrecognized codepoint SHOULD be forwarded as if they were marked for the Default behavior (see Sec. 4), and their codepoints should not be changed. Such packets MUST NOT cause the network node to malfunction. The structure of the DS field shown above is incompatible with the existing definition of the IPv4 TOS octet in [RFC791]. The presumption is that DS domains protect themselves by deploying re- marking boundary nodes, as should networks using the RFC 791 Precedence designations. Correct operational procedure SHOULD follow [RFC791], which states: "If the actual use of these precedence designations is of concern to a particular network, it is the responsibility of that network to control the access to, and use of, those precedence designations." Validating the value of the DS field at DS boundaries is sensible in any case since an upstream node can easily set it to any arbitrary value. DS domains that are not isolated by suitably configured boundary nodes may deliver unpredictable service. and excerpting the most pertinent two sentences: "A replacement header field, called the DS field, is defined, which is intended to supersede the existing definitions of the IPv4 TOS octet [RFC791] and the IPv6 Traffic Class octet [IPv6]. [...] The structure of the DS field shown above is incompatible with the existing definition of the IPv4 TOS octet in [RFC791]." and quoting Section 4, also for reference: 4. Historical Codepoint Definitions and PHB Requirements The DS field will have a limited backwards compatibility with current practice, as described in this section. Backwards compatibility is addressed in two ways. First, there are per-hop behaviors that are already in widespread use (e.g., those satisfying the IPv4 Precedence queueing requirements specified in [RFC1812]), and we wish to permit their continued use in DS-compliant nodes. In addition, there are some codepoints that correspond to historical use of the IP Precedence field and we reserve these codepoints to map to PHBs that meet the general requirements specified in Sec. 4.2.2.2, though the specific differentiated services PHBs mapped to by those codepoints MAY have additional specifications. No attempt is made to maintain backwards compatibility with the "DTR" or TOS bits of the IPv4 TOS octet, as defined in [RFC791]. The most significant sentence being the last one: "No attempt is made to maintain backwards compatibility with the "DTR" or TOS bits of the IPv4 TOS octet, as defined in [RFC791]."
Created attachment 1998 [details] Drop obsolete RFC-791 D/T/R/C ToS markings Minus the glibc vs. OpenBSD header constant diffs.
We ended up going with IPTOS_DSCP_AF21 for interactive and IPTOS_DSCP_CS1 for bulk some time ago.
Move resolved bugs -> CLOSED after 8.0 release