Browse Prior Art Database

TCP Processing of the IPv4 Precedence Field (RFC2873) Disclosure Number: IPCOM000003474D
Original Publication Date: 2000-Jun-01
Included in the Prior Art Database: 2019-Feb-13
Document File: 8 page(s) / 10K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

X. Xiao: AUTHOR [+3]

Related Documents

10.17487/RFC2873: DOI


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]

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 24% of the total text.

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 Notice

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.

1. Introduction

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...