RFC 2873

TCP Processing of the IPv4 Precedence Field

📅 published June 2000, from ietf

Status of This Memo ✨

Okay so this doc is a standards track protocol spec for the Internet community, and it's basically asking for discussion and suggestions for improvements 🫶 Check the current "Internet Official Protocol Standards" (STD 1) for where this protocol stands in the standardization process and what its status is. Distribution of this memo is unlimited.

Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract 🌸

Okay this one is about a clash 💀 TCP [RFC793] and DiffServ [RFC2475] both want a say over the three leftmost bits in the TOS octet of an IPv4 header [RFC791]. On a network with DiffServ-capable nodes, that clash can make TCP connections fail to get set up, or it can reset established TCP connections when they really shouldn't be reset. This memo proposes a change to TCP to fix the clash. 🔧

The IPv6 [RFC2460] traffic class octet is the chill one here. It has no defined meaning beyond what RFC 2474 gives it, and it doesn't define precedence or security parameter bits at all. So TCP and DiffServ never fight over any bits in there. Literally no conflict ✨

1. Introduction 🧚

So in TCP, every connection has a set of states, and those states are tracked in variables stored in the TCP Control Block (TCB) at both ends. Those variables can include the local and remote socket number, the precedence of the connection, the security level and compartment, etc. 🎀 Both ends MUST agree on the precedence and security parameters to set up the connection and keep it open. No agreement, no connection, bestie 😭

There's no field in the TCP header that says what precedence a segment has. Instead, the precedence field in the IP packet header does that job. The security level and compartment ride along in the IP header too, but as IP options instead of a fixed header field. Because of that difference, the precedence problem in this memo doesn't apply to them 💅

TCP says the precedence (and the security parameters) of a connection MUST remain unchanged for the whole life of the connection. So if an established TCP connection with precedence gets a segment with a different precedence, that's an error, and the connection MUST be reset [RFC793, pp. 36, 37, 40, 66, 67, 71]. Harsh but fair 💀

With DiffServ in the picture, intermediate nodes MAY modify the Differentiated Services Codepoint (DSCP) [RFC2474] in the IP header to ask for a desired Per-hop Behavior (PHB) [RFC2475, RFC2597, RFC2598]. The DSCP includes the three bits that used to be the precedence field 👀 So if DiffServ changes those three bits, precedence-aware endpoints will treat it as illegal. That can make connections fail to establish, or reset connections that were fine 🥀

2. Terminology 📚

Segment: the unit of data that TCP sends to IP 🍓

Precedence Field: the three leftmost bits in the TOS octet of an IPv4 header. In DiffServ, these three bits may or may not be used to denote the precedence of the IP packet. IPv6 has no precedence field in its traffic class octet 🌈

TOS Field: bits 3-6 in the TOS octet of an IPv4 header [RFC 1349] 🦋

MBZ field: Must Be Zero 🙈

The structure of the TOS octet looks like this:

                   0     1     2     3     4     5     6     7
                +-----+-----+-----+-----+-----+-----+-----+-----+
                |   PRECEDENCE    |          TOS          | MBZ |
                +-----+-----+-----+-----+-----+-----+-----+-----+

DS Field: DiffServ renames the TOS octet of an IPv4 header to the Differentiated Services (DS) Field. Iconic rebrand 👑

The structure of the DS field looks like this:

                  0   1   2   3   4   5   6   7
                +---+---+---+---+---+---+---+---+
                |         DSCP          |  CU   |
                +---+---+---+---+---+---+---+---+

DSCP: Differentiated Service Code Point, the leftmost 6 bits in the DS field 💖

CU: currently unused 🫧

Per-hop Behavior (PHB): a description of the externally observable forwarding treatment applied at a differentiated services-compliant node to a behavior aggregate ✨

To be continued, bestie 🎀 Part 2 covers Section 3 (Problem Description) onward!

7. References ✨

  • [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. 🌸
  • [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. 💖
  • [RFC1349] Almquist, P., "Type of Service in the Internet Protocol Suite", RFC 1349, July 1992. 🦋
  • [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. 🧚
  • [RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. 🎀
  • [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. 👑
  • [RFC2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2587, June 1999. 💅
  • [RFC2598] Jacobson, V., Nichols, K. and K. Poduri, "An Expedited Forwarding PHB", RFC 2598, June 1999. ⭐

8. Authors' Addresses 🎀

Meet the crew who wrote this thing, bestie 🫶

Xipeng Xiao
Global Crossing
141 Caspian Court
Sunnyvale, CA 94089
USA

Phone: +1 408-543-4801
EMail: xipeng@gblx.net


Alan Hannan
iVMG, Inc.
112 Falkirk Court
Sunnyvale, CA 94087
USA

Phone: +1 408-749-7084
EMail: alan@ivmg.net


Edward Crabbe
Exodus Communications
2650 San Tomas Expressway
Santa Clara, CA 95051
USA

Phone: +1 408-346-1544
EMail: edc@explosive.net


Vern Paxson
ACIRI/ICSI
1947 Center Street
Suite 600
Berkeley, CA 94704-1198
USA

Phone: +1 510-666-2882
EMail: vern@aciri.org

Copyright (C) The Internet Society (2000). All Rights Reserved. 🌈

okay so the Internet Society holds the copyright here, and anyone can copy and share this document, and people can write stuff that comments on or explains it or helps with implementing it, and publish and distribute that too, in whole or in part, with basically no restrictions 🫶. The one catch is that the above copyright notice and this paragraph have to stay on all those copies and derivative works.

BUT the document itself can't be modified in any way, like removing the copyright notice or the references to the Internet Society or other Internet organizations. The exceptions are when it's needed for developing Internet standards (then the copyright procedures in the Internet Standards process have to be followed) or when it's translated into languages other than English. 🦋

These limited permissions are perpetual, which means forever 💜, and the Internet Society or its successors or assigns will not revoke them.

⚠️ Heads up, bestie: the document and the information in it are provided on an "AS IS" basis, and the rest of this part is all caps for a reason 😭

THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💀

Acknowledgement 🌸

Right now, the Internet Society is the one funding the RFC Editor function, and we love that for them 👑

📦 where this page comes from