TCP Processing of the IPv4 Precedence Field (RFC2873)
Original Publication Date: 2000-Jun-01
Included in the Prior Art Database: 2019-Feb-13
Internet Society Requests For Comment (RFCs)
X. Xiao: AUTHOR [+3]
This memo describes a conflict between TCP and DiffServ on the use of the three leftmost bits in the TOS octet of an IPv4 header. [STANDARDS-TRACK]
Network Working Group X. Xiao Request for Comments: 2873 Global Crossing Category: Standards Track A. Hannan iVMG V. Paxson ACIRI/ICSI E. Crabbe Exodus Communications June 2000
TCP Processing of the IPv4 Precedence Field
Status of this Memo
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
Copyright (C) The Internet Society (2000). All Rights Reserved.
This memo describes a conflict between TCP [RFC793] and DiffServ [RFC2475] on the use of the three leftmost bits in the TOS octet of an IPv4 header [RFC791]. In a network that contains DiffServ-capable nodes, such a conflict can cause failures in establishing TCP connections or can cause some established TCP connections to be reset undesirably. This memo proposes a modification to TCP for resolving the conflict.
Because the IPv6 [RFC2460] traffic class octet does not have any defined meaning except what is defined in RFC 2474, and in particular does not define precedence or security parameter bits, there is no conflict between TCP and DiffServ on the use of any bits in the IPv6 traffic class octet.
In TCP, each connection has a set of states associated with it. Such states are reflected by a set of variables stored in the TCP Control Block (TCB) of both ends. Such variables may include the local and remote socket number, precedence of the connection, security level
Xiao, et al. Standards Track [Page 1]
RFC 2873 TCP and the IPv4 Precedence Field June 2000
and compartment, etc. Both ends must agree on the setting of the precedence and security parameters in order to establish a connection and keep it open.
There is no field in the TCP header that indicates the precedence of a segment. Instead, the precedence field in the header of the IP packet is used as the indication. The security level and compartment are likewise carried in the IP header, but as IP options rather than a fixed header field. Because of this difference, the problem with precedence discussed in this memo does not apply to them.
TCP requires that the precedence (and security parameters) of a connection must remain unchanged during the lifetime of the connection. Therefore, for an established TCP connection with precedence, the receipt of a segment with different precedence indicates an error. The connection must be reset [RFC793, pp. 36, 37, 40, 66, 67, 71].
With the advent of DiffServ, intermediate nodes may modify the Differentiated Services Codepoint (DSCP) [RFC2474] of the IP header to indicate the desired Per-hop Behavior (PHB) [RFC2475, RFC2597, RFC2598]. The DSCP includes the three bits formerly known as the precedence field. Because any modification to those three bits will be considered illegal by e...