RFC 2474

Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers

📅 published December 1998, from ietf

Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers 💖

Okay bestie, here's the vibe check on this RFC ✨

RFC number: 2474
Network Working Group 🦋
Authors: K. Nichols (Cisco Systems), S. Blake (Torrent Networking Technologies), F. Baker (Cisco Systems), and D. Black (EMC Corporation) 👑
Category: Standards Track 🔥
Date: December 1998 🌸
Obsoletes: 1455, 1349 💅

Status of this Memo 🎀

So this doc is an Internet standards track protocol spec for the Internet community. It's also asking people to talk about it and suggest improvements 🫶 If you want the official standardization state and status of this protocol, check the current edition of "Internet Official Protocol Standards" (STD 1). And distribution of this memo is unlimited, so share away 💜

Copyright Notice 🌈

Abstract 🧚

Okay so the whole point of these differentiated services enhancements is to get scalable service discrimination on the Internet, and it's giving no per-flow state and no signaling at every hop 😭 A bunch of services can be built out of a small, well-defined set of building blocks that get deployed in network nodes. These services can be end-to-end or intra-domain, and they cover both the ones that hit quantitative performance requirements (like peak bandwidth) and the ones based on relative performance (like "class" differentiation) ✨ Services get put together by combining:

setting bits in an IP header field at network boundaries (autonomous system boundaries, internal administrative boundaries, or hosts),
using those bits to determine how packets are forwarded by the nodes inside the network, and
conditioning the marked packets at network boundaries in accordance with the requirements or rules of each service.

The requirements or rules of each service must be set through administrative policy mechanisms, and those are outside the scope of this document 🙈 A differentiated services-compliant network node has a classifier that selects packets based on the value of the DS field. It also has buffer management and packet scheduling mechanisms that can deliver the specific packet forwarding treatment the DS field value indicates 🔥 Setting the DS field and conditioning the temporal behavior of marked packets only needs to happen at network boundaries, and those can vary in complexity.

This document defines the IP header field called the DS (for differentiated services) field 🦋 In IPv4, it defines the layout of the TOS octet. In IPv6, it defines the layout of the Traffic Class octet. It also defines a base set of packet forwarding treatments, which are called per-hop behaviors 👑

If you want the whole picture of differentiated services, also check out the differentiated services architecture [ARCH] 📚

Table of Contents 💜

1.  Introduction .................................................  3
2.  Terminology Used in This Document ............................  5
3.  Differentiated Services Field Definition .....................  7
4.  Historical Codepoint Definitions and PHB Requirements ........  9
  4.1  A Default PHB .............................................  9
  4.2  Once and Future IP Precedence Field Use ................... 10
    4.2.1  IP Precedence History and Evolution in Brief .......... 10
    4.2.2  Subsuming IP Precedence into Class Selector  .......... 11
           Codepoints
      4.2.2.1  The Class Selector Codepoints ..................... 11
      4.2.2.2  The Class Selector PHB Requirements ............... 11
      4.2.2.3  Using the Class Selector PHB Requirements ......... 12
               for IP Precedence Compatibility
      4.2.2.4  Example Mechanisms for Implementing Class ......... 12
               Selector Compliant PHB Groups
  4.3  Summary ................................................... 13
5.  Per-Hop Behavior Standardization Guidelines .................. 13
6.  IANA Considerations .......................................... 14
7.  Security Considerations ...................................... 15
  7.1  Theft and Denial of Service ............................... 15
  7.2  IPsec and Tunneling Interactions .......................... 16
8.  Acknowledgments .............................................. 17
9.  References ................................................... 17
Authors' Addresses ............................................... 19
Full Copyright Statement ......................................... 20

1. Introduction ✨

Differentiated services are meant to give us a framework and building blocks for deploying scalable service discrimination in the Internet 💅 The big idea is to split the architecture into two major components. One is pretty well-understood, and the other one is just starting to get understood 🧠 This approach is inspired by the original Internet design, which chose to separate forwarding from routing 🦋

Here's the tea on forwarding: it's the relatively simple task that has to happen per packet, as quickly as possible. Forwarding reads the packet header to find an entry in a routing table, and that entry tells it the packet's output interface ⚡ Routing is what fills in those table entries. It may need to reflect a range of transit and other policies, and it also has to keep track of route failures 💀 Routing tables get maintained as a background process next to forwarding. Routing is the more complex job, and it has kept evolving over the past 20 years 🫶

The differentiated services architecture has two main components too, and it's giving déjà vu 👑 One is the fairly well-understood behavior in the forwarding path. The other is the more complex, still-emerging background policy and allocation component, which configures the parameters the forwarding path uses ✨ The forwarding path behaviors cover the differential treatment an individual packet gets. That's done through queue service disciplines and/or queue management disciplines 🔥 These per-hop behaviors are useful and required in network nodes to deliver differentiated treatment of packets, no matter how end-to-end or intra-domain services get built 💖 The focus is on the general semantics of the behaviors, not the specific mechanisms that implement them, because the behaviors will evolve less quickly than the mechanisms 🌸

Per-hop behaviors, plus the ways to select them on a per-packet basis, can be deployed in network nodes today. That's the part of the architecture being addressed first 🦋 The forwarding path may also need some monitoring, policing, and shaping on traffic marked for "special" treatment. That's how you enforce the requirements tied to delivering that special treatment 🎀 Traffic conditioning mechanisms are also pretty well-understood. Widely deploying those traffic conditioners matters for building services too, even though how they actually get used in building services may change over time 💜

How network elements get configured, meaning which packets get special treatment and what rules apply to using resources, is way less well-understood 😅 Still, you can deploy useful differentiated services with simple policies and static configurations. As described in [ARCH], there are a bunch of ways to compose per-hop behaviors and traffic conditioners into services 🧚 Along the way we gain experience that will guide more complex policies and allocations. The basic forwarding path behaviors can stay the same while this part of the architecture evolves 🌈 Building services is going to keep getting experience for a while, so we're avoiding standardizing that construction because it's still premature. Plus, a lot of the details of service construction are covered by legal agreements between business entities, and that's way outside the scope of the IETF 🙈

This document focuses on the forwarding path component. In the forwarding path, differentiated services happen by mapping the codepoint in a field of the IP packet header to a particular forwarding treatment, which is a per-hop behavior (PHB), at each network node along the path 🦋 The codepoints can come from a set of mandatory values defined later in this document, from a set of recommended values to be defined in future documents, or they can have purely local meaning 💅 PHBs are expected to be implemented with a range of queue service and/or queue management disciplines on a network node's output interface queue. Examples are weighted round-robin (WRR) queue servicing or drop-preference queue management 🔥

Marking is done by traffic conditioners at network boundaries. Those include the edges of the network (first-hop router or source host) and administrative boundaries 👑 Traffic conditioners may include the primitives of marking, metering, policing, and shaping, which are described in [ARCH] ✨ Services are realized by using particular packet classification and traffic conditioning mechanisms at boundaries, combined with concatenating per-hop behaviors along the transit path of the traffic 💖 A goal of the differentiated services architecture is to specify these building blocks for future extensibility, both in how many building blocks there are and what type they are, and in the services built from them 🌸

Terminology used in this memo is defined in Sec. 2 🎀 The differentiated services field definition (DS field) is given in Sec. 3. In Sec. 4, we talk about wanting partial backwards compatibility with current use of the IPv4 Precedence field. To solve that, we introduce Class Selector Codepoints and Class Selector Compliant PHBs 🧚 Sec. 5 has guidelines for per-hop behavior standardization. Sec. 6 discusses guidelines for allocating codepoints. Sec. 7 covers security considerations 💜

This document is a concise description of the DS field and its uses. It's meant to be read alongside the differentiated services architecture [ARCH] 🦋

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🫶

2. Terminology Used in This Document ✨

Okay bestie, these are the words the whole doc runs on, so let's get them straight 🎀

Behavior Aggregate: a collection of packets with the same codepoint crossing a link in a particular direction. "aggregate" and "behavior aggregate" mean the same thing here, so they're used interchangeably 🦋

Classifier: an entity that picks packets based on what's in their headers, following defined rules 🔍

Class Selector Codepoint: any of the eight codepoints in the range 'xxx000' (where 'x' may equal '0' or '1'). We get the full tea on these in Sec. 4.2.2 🍵

Class Selector Compliant PHB: a per-hop behavior that satisfies the Class Selector PHB Requirements from Sec. 4.2.2.2 💅

Codepoint: a specific value of the DSCP portion of the DS field. Recommended codepoints SHOULD map to specific, standardized PHBs. Multiple codepoints MAY map to the same PHB 🌈

Differentiated Services Boundary: the edge of a DS domain, where classifiers and traffic conditioners are likely to be deployed. It can be split into ingress and egress nodes, where those are the downstream and upstream nodes of a boundary link in a given traffic direction. Usually it's found at the ingress of the first-hop differentiated services-compliant router (or network node) that a host's packets traverse, or at the egress of the last-hop one before packets arrive at a host. People sometimes call this the boundary at a leaf router. A DS boundary may also be co-located with a host, subject to local policy. Also DS boundary 🧚

Differentiated Services-Compliant: in compliance with the requirements in this document. Also DS-compliant ✨

Differentiated Services Domain: a contiguous chunk of the Internet where a consistent set of differentiated services policies is administered in a coordinated way. A DS domain can cover different administrative domains or autonomous systems, different trust regions, different network technologies (e.g., cell/frame), hosts and routers, and more. Also DS domain 🌸

Differentiated Services Field: the IPv4 header TOS octet or the IPv6 Traffic Class octet, when it's interpreted the way this document defines it. Also DS field 💜

Mechanism: the implementation of one or more per-hop behaviors according to a particular algorithm ⚙️

Microflow: a single instance of an application-to-application flow of packets, identified by source address, destination address, protocol id, and source port and destination port (where applicable) 🎯

Per-hop Behavior (PHB): a description of the externally observable forwarding treatment applied to a behavior aggregate at a differentiated services-compliant node. The description of a PHB SHOULD be detailed enough to allow predictable services to be built, as documented in [ARCH] 🔥

Per-hop Behavior Group: a set of one or more PHBs that can only be meaningfully specified and implemented at the same time, because they all share a common constraint, such as a queue servicing or queue management policy. Also PHB Group 👑

Traffic Conditioning: control functions that can be applied to a behavior aggregate, application flow, or other operationally useful subset of traffic, e.g., routing updates. These MAY include metering, policing, shaping, and packet marking. Traffic conditioning enforces agreements between domains, and it conditions traffic to get differentiated service within a domain by marking packets with the right codepoint in the DS field and by monitoring and altering the temporal characteristics of the aggregate where needed. See [ARCH] 🦋

Traffic Conditioner: an entity that performs traffic conditioning functions and which MAY contain meters, policers, shapers, and markers. Traffic conditioners are typically deployed in DS boundary nodes (i.e., not in interior nodes of a DS domain) 🫶

Service: a description of the overall treatment of (a subset of) a customer's traffic across a particular domain, across a set of interconnected DS domains, or end-to-end. Service descriptions are covered by administrative policy. Services are built by applying traffic conditioning to create behavior aggregates that each experience a known PHB at every node in the DS domain. A single per-hop behavior can support multiple services when it's paired with a range of traffic conditioners 💖

To sum up: classifiers and traffic conditioners are used to pick which packets get added to behavior aggregates. Aggregates receive differentiated treatment in a DS domain, and traffic conditioners MAY alter the temporal characteristics of the aggregate to conform to some requirements. A packet's DS field designates its behavior aggregate, and that's then used to decide which forwarding treatment the packet gets. A behavior aggregate classifier that can select a PHB based on the codepoint in the DS field, for example a differential output queue servicing discipline, SHOULD be included in all network nodes in a DS domain. The classifiers and traffic conditioners at DS boundaries are configured according to some service specification, which is administrative policy and outside the scope of this document 🎀

Additional differentiated services definitions are given in [ARCH] 📚

3. Differentiated Services Field Definition 💅

A replacement header field, called the DS field, is defined. It's meant 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. Differentiated services-compliant nodes ignore the value of the CU bits when they figure out the per-hop behavior to apply to a received packet 🫧

The DS field structure looks like this:

     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 is bit 0 of the DS field (as shown above), and the right-most bit is 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 field's value as a table index that picks out a particular packet handling mechanism 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 so that future per-hop behaviors can be defined 🌈

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. If operators do so, 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 they're 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 DS field structure shown above is incompatible with the existing definition of the IPv4 TOS octet in [RFC791]. The assumption is that DS domains protect themselves by deploying re-marking boundary nodes, and networks using the RFC 791 Precedence designations should do the same. 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 makes sense in any case, since an upstream node can easily set it to any arbitrary value. DS domains that aren't isolated by suitably configured boundary nodes may deliver unpredictable service 😭

Nodes MAY rewrite the DS field as needed to provide a desired local or end-to-end service. Specifications of DS field translations at DS boundaries are the subject of service level agreements between providers and users, and they're outside the scope of this document. Standardized PHBs let providers build their services from a well-known set of packet forwarding treatments that can be expected to be present in the equipment of many vendors 🍓

4. Historical Codepoint Definitions and PHB Requirements 🕰️

The DS field has limited backwards compatibility with current practice, as described in this section. Backwards compatibility is handled 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 want to keep letting them be used in DS-compliant nodes. Second, some codepoints correspond to historical use of the IP Precedence field, and those codepoints are reserved to map to PHBs that meet the general requirements in Sec. 4.2.2.2. 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] 🫶

4.1. A Default PHB ✨

okay bestie, so a "default" PHB MUST be available in a DS-compliant node 💅 This is the common, best-effort forwarding behavior that existing routers already have, as standardized in [RFC1812] 🌸 When no other agreements are in place, packets are assumed to belong to this aggregate. Such packets MAY be sent into a network without following any particular rules, and the network will deliver as many of them as possible and as soon as possible, subject to other resource policy constraints 🦋

A reasonable implementation of this PHB would be a queueing discipline that sends packets of this aggregate whenever the output link is not needed to satisfy another PHB 🧚 A reasonable policy for building services would make sure the aggregate doesn't get "starved" 😭 One way to enforce that is a mechanism in each node that reserves some minimal resources (e.g, buffers, bandwidth) for Default behavior aggregates 🫶 This lets senders that aren't differentiated services-aware keep using the network the same way they do today 💜

The impact of bringing differentiated services into a domain on the service expectations of its customers and peers is a complex matter 🙈 It involves policy decisions by the domain and is outside the scope of this document, so we're not getting into it here 🍓

The RECOMMENDED codepoint for the Default PHB is 000000 👑 The value 000000 MUST map to a PHB that meets these specifications ✨ This codepoint choice for Default behavior is compatible with existing practice [RFC791] 🎀 If a codepoint isn't mapped to a standardized or local use PHB, it SHOULD be mapped to the Default PHB 🌈

A packet that was initially marked for the Default behavior MAY be re-marked with another codepoint as it crosses a boundary into a DS domain 💖 That way it gets forwarded using a different PHB inside that domain, possibly subject to some negotiated agreement between the peering domains ⭐

4.2. Once and Future IP Precedence Field Use 🦋

we wish to keep some form of backward compatibility with present uses of the IP Precedence Field, which is bits 0-2 of the IPv4 TOS octet 💅 Routers already exist that use the IP Precedence field to pick different per-hop forwarding treatments, kind of like what's proposed here for the DSCP field 🌸 So a simple prototype differentiated services architecture can be quickly deployed by configuring these routers appropriately ✨

Also, IP systems today already understand where the IP Precedence field lives 🧚 So if these bits are used in a similar way as DS-compliant equipment gets deployed, significant failures aren't likely during early deployment 🫶 In other words, strict DS-compliance doesn't need to be everywhere, even inside a single service provider's network, as long as bits 0-2 of the DSCP field are used in a manner similar to, or subsuming, the deployed uses of the IP Precedence field 👑

4.2.1. IP Precedence History and Evolution in Brief 📜

the IP Precedence field is kind of a forerunner of the DS field 💜 IP Precedence, and the IP Precedence Field, were first defined in [RFC791] 🍓 The values the three-bit IP Precedence Field could take were assigned to various uses, including network control traffic, routing traffic, and various levels of privilege 🌈 The lowest level of privilege was deemed "routine traffic" 💀

In [RFC791], Precedence was defined broadly as "An independent measure of the importance of this datagram." 🎀 Not every value of the IP Precedence field was assumed to mean something across boundaries 😭 For instance, "The Network Control precedence designation is intended to be used within a network only. The actual use and control of that designation is up to each network." [RFC791] 🙈

Early BBN IMPs implemented the Precedence feature, but early commercial routers and UNIX IP forwarding code generally didn't 💅 As networks got more complex and customer requirements grew, commercial router vendors built ways to do various kinds of queueing services, including priority queueing 🔥 These were generally based on policies encoded in filters in the routers, which could examine IP addresses, IP protocol numbers, TCP or UDP ports, and other header fields 🦋 IP Precedence was and is among the options such filters can examine ✨

Short version: IP Precedence is widely deployed and widely used, just not always in exactly the manner intended in [RFC791] 💖 This was recognized in [RFC1122], which states that while the use of the IP Precedence field is valid, the specific assignment of the priorities in [RFC791] were merely historical 🫶

4.2.2. Subsuming IP Precedence into Class Selector Codepoints 🌸

A specification of the packet forwarding treatments selected by the IP Precedence field today would have to be pretty general 😭 It probably wouldn't be specific enough to build predictable services from in the differentiated services framework 🙈 To keep partial backwards compatibility with known current uses of the IP Precedence field without sacrificing future flexibility, we went with describing minimum requirements on a set of PHBs that are compatible with most of the deployed forwarding treatments selected by the IP Precedence field 👑

We also give a set of codepoints that MUST map to PHBs meeting these minimum requirements ✨ The PHBs mapped to by these codepoints MAY have a more detailed list of specifications in addition to the required ones stated here 🧚 Other codepoints MAY map to these same PHBs 🌈 We call this set of codepoints the Class Selector Codepoints, and the minimum requirements for PHBs these codepoints may map to are called the Class Selector PHB Requirements 💜

4.2.2.1. The Class Selector Codepoints 💅

A specification of the packet forwarding treatments selected by the The DS field values of xxx000|xx, or DSCP = xxx000 and CU subfield unspecified, are reserved as a set of Class Selector Codepoints 🎀 PHBs mapped to by these codepoints MUST satisfy the Class Selector PHB requirements, in addition to preserving the Default PHB requirement on codepoint 000000 (Sec. 4.1) 🔥

4.2.2.2. The Class Selector PHB Requirements ⭐

We call a Class Selector Codepoint with a larger numerical value than another Class Selector Codepoint as having a higher relative order 🦋 A Class Selector Codepoint with a smaller numerical value than another is said to have a lower relative order 🌸 The set of PHBs mapped to by the eight Class Selector Codepoints MUST yield at least two independently forwarded classes of traffic 🫶 PHBs selected by a Class Selector Codepoint SHOULD give packets a probability of timely forwarding that is not lower than the one given to packets marked with a Class Selector codepoint of lower relative order, under reasonable operating conditions and traffic loads 💖 A discarded packet counts as an extreme case of untimely forwarding 😭

Also, PHBs selected by codepoints 11x000 MUST give packets a preferential forwarding treatment compared to the PHB selected by codepoint 000000, to preserve the common usage of IP Precedence values 110 and 111 for routing traffic 👑

Further, PHBs selected by distinct Class Selector Codepoints SHOULD be independently forwarded, which means packets marked with different Class Selector Codepoints MAY be re-ordered 🌈 A network node MAY enforce limits on the amount of the node's resources each of these PHBs can use 🧚

PHB groups whose specifications satisfy these requirements are called Class Selector Compliant PHBs ✨

The Class Selector PHB Requirements on codepoint 000000 are compatible with those listed for the Default PHB in Sec. 4.1 💅

4.2.2.3. Using the Class Selector PHB Requirements for IP Precedence Compatibility 🎀

A DS-compliant network node can be deployed with a set of one or more Class Selector Compliant PHB groups 🌸 This document states that the set of codepoints xxx000 MUST map to such a set of PHBs 🔥 Since it's also possible to map multiple codepoints to the same PHB, the vendor or the network administrator MAY configure the network node to map codepoints to PHBs irrespective of bits 3-5 of the DSCP field, to yield a network that's compatible with historical IP Precedence use 🦋 So, for example, codepoint 011010 would map to the same PHB as codepoint 011000 💖

4.2.2.4. Example Mechanisms for Implementing Class Selector Compliant PHB Groups 🧚

Class Selector Compliant PHBs can be realized by a variety of mechanisms, including strict priority queueing, weighted fair queueing (WFQ), WRR, or variants [RPS, HPFQA, DRR], or Class-Based Queuing [CBQ] 🌈 The distinction between PHBs and mechanisms is described in more detail in Sec. 5 💜

It's important to note that these mechanisms might be available through other PHBs (standardized or not) that are available in a particular vendor's equipment 💅 For example, future documents may standardize a Strict Priority Queueing PHB group for a set of recommended codepoints 🫶 A network administrator might configure those routers to select the Strict Priority Queueing PHBs with codepoints xxx000 in conformance with the requirements of this document ✨

As a further example, another vendor might use a CBQ mechanism in its routers 🎀 The CBQ mechanism could implement the Strict Priority Queueing PHBs, as well as a set of Class Selector Compliant PHBs with a wider range of features than a set of PHBs that did no more than meet the minimum Class Selector PHB requirements 🔥

4.3. Summary 🎀

This document defines codepoints xxx000 as the Class Selector codepoints, where PHBs selected by these codepoints MUST meet the Class Selector PHB Requirements described in Sec. 4.2.2.2 🌸 This is done to preserve a useful level of backward compatibility with current uses of the IP Precedence field in the Internet, without unduly limiting future flexibility 👑 Codepoint 000000 is used as the Default PHB value for the Internet and, as such, is not configurable 💖 The remaining seven non-zero Class Selector codepoints are configurable only to the extent that they map to PHBs meeting the requirements in Sec. 4.2.2.2 ✨

5. Per-Hop Behavior Standardization Guidelines ✨

okay so the big rule here is that we standardize the behavior of a PHB, not the exact algorithms or mechanisms that make it happen 💅 A node can have a (possibly large) set of parameters for controlling how packets get scheduled onto an output interface (e.g., N separate queues with settable priorities, queue lengths, round-robin weights, drop algorithm, drop preference weights and thresholds, etc). To show the difference between a PHB and a mechanism, Class Selector Compliant PHBs might be implemented by several mechanisms, including: strict priority queueing, WFQ, WRR, or variants [HPFQA, RPS, DRR], or CBQ [CBQ], in isolation or in combination. 🎀

PHBs can be specified individually, or as a group (a single PHB is a special case of a PHB group) 🫶 A PHB group usually has two or more PHBs that can only be meaningfully specified and implemented simultaneously, because they share a common constraint, such as a queue servicing or queue management policy. A PHB group specification SHOULD describe conditions under which a packet might be re-marked to select another PHB within the group. It is RECOMMENDED that PHB implementations do not introduce any packet re-ordering within a microflow. PHB group specifications MUST identify any possible packet re-ordering implications which may occur for each individual PHB, and which may occur if different packets within a microflow are marked for different PHBs within the group. 😭

Only those per-hop behaviors that are not described by an existing PHB standard, and that have been implemented, deployed, and shown to be useful, SHOULD be standardized 🧚 Current experience with differentiated services is pretty limited, so it is premature to guess the exact specification of these per-hop behaviors. 🙈

Each standardized PHB MUST have an associated RECOMMENDED codepoint, allocated out of a space of 32 codepoints (see Sec. 6) 🌸 This specification left room in the codepoint space so things can evolve, which is why the defined space (xxx000) is intentionally sparse. 💜

Network equipment vendors are free to offer whatever parameters and capabilities are useful or marketable 💅 When a particular, standardized PHB is implemented in a node, a vendor MAY use any algorithm that satisfies the definition of the PHB according to the standard. The node's capabilities and its particular configuration decide the different ways packets can be treated. 🍓

Service providers aren't required to use the same node mechanisms or configurations to enable service differentiation within their networks. They're free to configure the node parameters in whatever way fits their service offerings and traffic engineering objectives ✨ Over time, certain common per-hop behaviors are likely to evolve (i.e., ones that are particularly useful for implementing end-to-end services), and these MAY be associated with particular EXP/LU PHB codepoints in the DS field, which allows use across domain boundaries (see Sec. 6). These PHBs are candidates for future standardization. 🦋

It is RECOMMENDED that standardized PHBs be specified in accordance with the guidelines set out in [ARCH]. 👑

6. IANA Considerations 🌈

The DSCP field within the DS field can convey 64 distinct codepoints. The codepoint space is split into three pools for assignment and management: a pool of 32 RECOMMENDED codepoints (Pool 1) to be assigned by Standards Action as defined in [CONS], a pool of 16 codepoints (Pool 2) reserved for experimental or Local Use (EXP/LU) as defined in [CONS], and a pool of 16 codepoints (Pool 3) which are initially available for experimental or local use, but which should be preferentially utilized for standardized assignments if Pool 1 is ever exhausted. 🎀 The pools are defined in the following table (where 'x' refers to either '0' or '1'):

   Pool        Codepoint space          Assignment Policy
   ----        ---------------          -----------------

    1            xxxxx0                 Standards Action
    2            xxxx11                 EXP/LU
    3            xxxx01                 EXP/LU (*)

   (*) may be utilized for future Standards Action allocations as
       necessary

This document assigns eight RECOMMENDED codepoints (xxx000) which are drawn from Pool 1 above. These codepoints MUST be mapped, not to specific PHBs, but to PHBs that meet "at least" the requirements set forth in Sec. 4.2.2.2 to provide a minimal level of backwards compatibility with IP Precedence as defined in [RFC791] and as deployed in some current equipment. 💖

7. Security Considerations 💀

okay this section is the serious one bestie 😭 It looks at the security issues raised by introducing differentiated services, mainly the potential for denial-of-service attacks, and the related potential for theft of service by unauthorized traffic (Section 7.1). Section 7.2 covers how differentiated services work when IPsec is present, including its interaction with IPsec tunnel mode and other tunnelling protocols. See [ARCH] for a more extensive treatment of the security concerns raised by the overall differentiated services architecture. 🔥

7.1. Theft and Denial of Service

The primary goal of differentiated services is to let different levels of service be provided for traffic streams on a common network infrastructure ✨ There are a bunch of techniques to achieve this, but the end result is that some packets get different (e.g., better) service than others. The mapping of network traffic to the specific behaviors that cause different (e.g., better or worse) service is indicated primarily by the DS codepoint. That means an adversary might be able to get better service by modifying the codepoint to values that indicate behaviors used for enhanced services, or by injecting packets with those codepoint values 👀 Taken to its limits, that theft of service becomes a denial-of-service attack when the modified or injected traffic depletes the resources available to forward it and other traffic streams. 💀

The defense against this class of theft- and denial-of-service attacks is the combination of traffic conditioning at DS domain boundaries with security and integrity of the network infrastructure within a DS domain 🛡️ DS domain boundary nodes MUST ensure that all traffic entering the domain is marked with codepoint values appropriate to the traffic and the domain, remarking the traffic with new codepoint values if necessary. These DS boundary nodes are the primary line of defense against theft- and denial-of-service attacks based on modified codepoints, because success of any such attack means the codepoints used by the attacking traffic were inappropriate. An important instance of a boundary node is that any traffic-originating node within a DS domain is the initial boundary node for that traffic. Interior nodes in a DS domain rely on DS codepoints to associate traffic with the forwarding PHBs, and they are NOT REQUIRED to check codepoint values before using them. 🫠 As a result, the interior nodes depend on the correct operation of the DS domain boundary nodes to prevent the arrival of traffic with inappropriate codepoints, or traffic in excess of provisioned levels, that would disrupt operation of the domain. 🧱

7.2. IPsec and Tunnelling Interactions

The IPsec protocol, as defined in [ESP, AH], does not include the IP header's DS field in any of its cryptographic calculations (in the case of tunnel mode, it's the outer IP header's DS field that isn't included) 🙃 So modifying the DS field at a network node has no effect on IPsec's end-to-end security, because it can't cause any IPsec integrity check to fail. As a consequence, IPsec doesn't provide any defense against an adversary modifying the DS field (i.e., a man-in-the-middle attack), since the adversary's modification also has no effect on IPsec's end-to-end security. 🕵️‍♀️

IPsec's tunnel mode DOES provide security for the encapsulated IP header's DS field. A tunnel mode IPsec packet contains two IP headers: an outer header supplied by the tunnel ingress node, and an encapsulated inner header supplied by the original source of the packet. When an IPsec tunnel is hosted (in whole or in part) on a differentiated services network, the intermediate network nodes operate on the DS field in the outer header. At the tunnel egress node, IPsec processing includes removing the outer header and forwarding the packet (if required) using the inner header. The IPsec protocol REQUIRES that the inner header's DS field not be changed by this decapsulation processing, so that modifications to the DS field can't be used to launch theft- or denial-of-service attacks across an IPsec tunnel endpoint 🔒 This document makes no change to that requirement. If the inner IP header has not been processed by a DS boundary node for the tunnel egress node's DS domain, the tunnel egress node is the boundary node for traffic exiting the tunnel, and so it MUST ensure that the resulting traffic has appropriate DS codepoints. 🌷

When IPsec tunnel egress decapsulation processing includes a sufficiently strong cryptographic integrity check of the encapsulated packet (where "sufficiently" is decided by local security policy), the tunnel egress node can safely assume that the DS field in the inner header has the same value it had at the tunnel ingress node 🥹 An important consequence is that otherwise insecure links within a DS domain can be secured by a sufficiently strong IPsec tunnel. This analysis and its implications apply to any tunnelling protocol that performs integrity checks, but the level of assurance for the inner header's DS field depends on the strength of the integrity check the tunnelling protocol performs. Without sufficient assurance for a tunnel that may transit nodes outside the current DS domain (or that is otherwise vulnerable), the encapsulated packet MUST be treated as if it had arrived at a boundary from outside the DS domain. 🚨

8. Acknowledgements 🫶

The authors would like to acknowledge the Differentiated Services Working Group for discussions which helped shape this document. Thank you, babes 💜🧚

9. References ✨

Okay bestie, here's the reading list 📚 every source this spec leans on, so you can go deeper whenever you want 🫶

[AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[ARCH] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[CBQ] S. Floyd and V. Jacobson, "Link-sharing and Resource Management Models for Packet Networks", IEEE/ACM Transactions on Networking, Vol. 3 no. 4, pp. 365-386, August 1995.
[CONS] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October 1998.
[DRR] M. Shreedhar and G. Varghese, Efficient Fair Queueing using Deficit Round Robin", Proc. ACM SIGCOMM 95, 1995.
[ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[HPFQA] J. Bennett and Hui Zhang, "Hierarchical Packet Fair Queueing Algorithms", Proc. ACM SIGCOMM 96, August 1996.
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC791] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC1122] Braden, R., "Requirements for Internet hosts - communication layers", STD 3, RFC 1122, October 1989.
[RFC1812] Baker, F., Editor, "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RPS] D. Stiliadis and A. Varma, "Rate-Proportional Servers: A Design Methodology for Fair Queueing Algorithms", IEEE/ACM Trans. on Networking, April 1998.

Authors' Addresses 🎀

Meet the squad who wrote this! Here's how to reach each of them 💌

Kathleen Nichols
Cisco Systems
170 West Tasman Drive
San Jose, CA  95134-1706

Phone:  +1-408-525-4857
EMail: kmn@cisco.com


Steven Blake
Torrent Networking Technologies
3000 Aerial Center, Suite 140
Morrisville, NC  27560

Phone:  +1-919-468-8466 x232
EMail: slblake@torrentnet.com


Fred Baker
Cisco Systems
519 Lado Drive
Santa Barbara, CA  93111

Phone:  +1-408-526-4257
EMail: fred@cisco.com


David L. Black
EMC Corporation
35 Parkwood Drive
Hopkinton, MA  01748

Phone:  +1-508-435-1000 x76140
EMail: black_david@emc.com

Full Copyright Statement 🌈

The legal part, kept word-for-word so nothing gets lost in translation 📜

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

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works.  However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and 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.

📦 where this page comes from

ietf: rfc2474 1998-12
💖 girlified by claude-haiku-5-5 on 2026-10-15: a language model's rewrite of the original, under its terms