Type of Service in the Internet Protocol Suite
obsoleted by
- rfc-2474 — Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers
updates
- rfc-1060 — Assigned numbers
- rfc-1122 — Requirements for Internet Hosts - Communication Layers
- rfc-1123 — Requirements for Internet Hosts - Application and Support
- rfc-1195 — Use of OSI IS-IS for routing in TCP/IP and dual environments
- rfc-1247 — OSPF Version 2
- rfc-1248 — OSPF Version 2 Management Information Base
- rfc-791 — Internet Protocol
Extracted elements (27)
Longest-match destination routing is retained as the primary criterion, with TOS as a secondary tie-breaker. This matches Internet routing tradition and avoids the misconfiguration risk of the alternative (TOS-first) approach, where packets that should be delivered locally could follow a default route into the Internet.
The fundamental design rule is that a host should never be penalized for using the TOS facility. If a network cannot provide the requested TOS, it must deliver the packet as if no TOS bits were set, rather than discarding it. This was considered essential for ensuring the facility would actually be deployed.
The 'minimize monetary cost' TOS value was defined as 0001 (setting no RFC-791 bits) so that pre-existing implementations would treat it as the default TOS rather than as a low-delay or high-throughput request. A value meaning 'must not cost money' or 'willing to pay' was rejected as philosophically inconsistent and impractical.
The TOS facility is strictly advisory and cannot provide service guarantees because (1) not all networks will consider TOS when routing, and (2) TOS cannot quantify a specific service level (e.g., a specific bandwidth). Discarding packets because no suitable TOS path is available would violate the no-penalty principle.
The TOS field was fixed at four bits (not three or five) to permanently resolve the RFC-791 vs. RFC-1122 conflict, allow the new 'minimize monetary cost' value (0001) without touching RFC-791 bit positions, and leave one IP header bit free for other future use. Fixing the size permanently is necessary to prevent routing loops when routers disagree on TOS field width.
TOS values are defined as enumerated integers rather than independently settable bits to reclaim the many bit-combination values (which have no useful semantics) for future TOS definitions. This provides 11 additional values for future standardization while remaining compatible with RFC-791 single-bit semantics.
Weak TOS routing was chosen over Strong TOS (which would discard packets if no route with the requested TOS exists, penalizing hosts for using TOS) and Very Weak TOS (which falls back to the numerically smallest TOS, an unjustifiable heuristic). Weak TOS falls back to the default route, consistent with OSPF and IS-IS.
ICMP Destination Unreachable codes 11 (network unreachable for TOS) and 12 (host unreachable for TOS) were defined in RFC-1122 but omitted from RFC-792; this memo updates RFC-792 to include them. Hosts receiving these codes should treat them as routing transients rather than proof of unreachability.
Integrated IS-IS maps the 4-bit TOS field to its four metrics: TOS 0000 uses default metric, 1000 uses delay metric, 0100 uses default metric, 0010 uses reliability metric, 0001 uses cost metric, and all other values use the default metric. The MBZ bit (bit 7) is ignored by IS-IS.
OSPF encodes TOS values in Link State Advertisements using even integers 0–30 (decimal), where the OSPF integer divided by 2 gives the TOS binary value's position. For example: OSPF 0 = TOS 0000, OSPF 2 = TOS 0001 (minimize cost), OSPF 16 = TOS 1000 (minimize delay). This memo provides an updated mapping table for RFC-1247.
A host receiving a Destination Unreachable message (codes 0, 1, 11, or 12) should recognize that it may result from a routing transient and interpret it only as a hint, not proof, that the destination is unreachable.
A host should correctly handle code 2 and code 3 ICMP Redirects in addition to codes 0 and 1. If a host cannot, it is better to treat code 2 as equivalent to code 0 and code 3 as equivalent to code 1 rather than ignoring them entirely.
A router MUST generate a code 11 (network unreachable for TOS) or code 12 (host unreachable for TOS) ICMP Destination Unreachable when an unreachable destination would have been reachable with a different TOS value. Codes 0 or 1 are used in other cases.
A router SHOULD generate a code 3 ICMP Redirect (redirect for type of service and host) when the redirect applies only to packets requesting a particular TOS, and code 1 when the optimal next hop is the same for any TOS. Routers should refrain from using codes 0 and 2 in Redirects.
A transport protocol MUST use the TOS requested by the application when sending a datagram. There is no requirement that both ends of a transport connection use the same TOS, and it is permissible to change the TOS mid-connection if the nature of traffic changes.
An ICMP error message (types 3, 4, 5, 11, 12) is always sent with the default TOS (0000). An ICMP reply message is sent with the same TOS value as was used in the corresponding ICMP request message.
Hosts and routers must not preclude the use of any TOS field value, including those whose semantics are not yet defined by this memo. Only the default TOS (0000) is in any way special.
TCP should use the same TOS for datagrams containing only TCP control information as it does for datagrams containing user data, to avoid corrupting TCP's round-trip time estimates.
The originator of a datagram MUST set the MBZ bit (bit 7 of the TOS octet) to zero unless participating in an Internet protocol experiment that uses that bit. Routers and recipients ignore the value of this field.
When a host creates or updates a type 2 route cache entry, it must flush any type 1 entries with the same destination, since the type 1 entry may be obsolete but would continue to be preferred. The converse does not hold: creating a type 1 entry should not flush type 2 entries.
When forwarding a packet, a router first finds candidate routes by destination address (longest match), then selects the route whose TOS exactly matches the packet's requested TOS. If no exact match exists, the route with the default TOS (0000) is chosen. If neither is available, the destination is unreachable.
A host's route cache must conceptually support two entry types: type 1 { destination, TOS, router } from code 3 (or code 1) Redirects, and type 2 { destination, *, router } from code 2 (or code 0) Redirects. Type 1 entries are always preferred over type 2 for matching destination and TOS.
A router associates a TOS value with each route in its forwarding table. Routes learned via TOS-aware routing protocols get the appropriate TOS; routes from non-TOS protocols get the default TOS (0000); static routes have their TOS assigned by the network manager.
The Assigned Numbers document specifies per-application TOS values: TELNET/FTP-Control/TFTP/SMTP-Command use 1000 (minimize delay); FTP-Data/SMTP-Data/DNS-ZoneTransfer use 0100 (maximize throughput); NNTP uses 0001 (minimize cost); IGP/SNMP use 0010 (maximize reliability); DNS-UDP-Query uses 1000; EGP/BOOTP use 0000.
The TOS field is redefined as a 4-bit enumerated integer (not a set of independent bits): 1000=minimize delay, 0100=maximize throughput, 0010=maximize reliability, 0001=minimize monetary cost, 0000=normal/default service. Computing the logical OR of two TOS values is no longer meaningful.
The author states that the specifications in this memo neither weaken nor enhance the security of the IP protocol or of the other protocols mentioned. No explicit security mechanisms or threats are introduced by the TOS facility as defined here.
The Type of Service octet in the IP header consists of three fields: a 3-bit PRECEDENCE field (bits 0-2), a 4-bit TOS field (bits 3-6), and a 1-bit MBZ (must be zero) field (bit 7). This memo redefines the TOS field as four bits wide, resolving a conflict between RFC-791 (3 bits) and RFC-1122 (5 bits).