Summary

  • URG and the urgent pointer do not create a second data channel; urgent information remains in TCP's ordinary sequence space.
  • RFC 793 contained two conflicting boundary rules. RFC 1122 chose the “last urgent octet” before RFC 6093 aligned the standard with the widely deployed “octet following urgent data” practice.
  • RFC 9293 retains the current rule and mandatory implementation support, but it neither creates a priority lane nor recommends new application dependence.

When URG is set, the 16-bit urgent pointer is interpreted as a positive offset from the segment sequence number. It therefore belongs to the same sequence space as ordinary data. A receiver remains in urgent mode while the marked point is ahead of RCV.NXT and returns to normal when receive progress reaches it. The bytes stay in line. A socket API that presents one byte as “out of band” by default is exposing an API convention, not a second transport service.

The original contradiction was small but consequential. RFC 793's header description placed the pointer on the octet following urgent data, while its SEND processing set SND.UP to SND.NXT-1, implying the last urgent octet. RFC 1122 chose the last-octet interpretation and required support for an urgent sequence of any length plus asynchronous application notification. RFC 6093, however, reported that the widely deployed implementations it examined followed the following-octet interpretation. It therefore updated RFC 793, RFC 1011 and RFC 1122 to codify that practice. RFC 9293 carries it forward as the current MUST.

An urgent-pointer update while the receiver is already in urgent mode may not produce another application notification. Sender urgent calls and receiver notifications therefore need not have a one-to-one relationship. RFC 6093 also documented some middleboxes that cleared URG and zeroed the pointer; it did not claim that all devices behaved that way. The sources do not establish present usage, current operating-system defaults or attack frequency.

Sources