The DTH flag uses the fourth bit in the Control bits field in TCP header as depicted in Figure 1 [RFC 9293
]. The fourth bit was intentionally selected because "four" in Chinese is Sì; it has a similar sound to Sĭ, which means "die".
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
| Source Port | Destination Port |
| Sequence Number |
| Acknowledgment Number |
| Data |D| |C|E|U|A|P|R|S|F| |
| Offset|T| Rsr |W|C|R|C|S|S|Y|I| Window |
| |H| vd |R|E|G|K|H|T|N|N| |
| Checksum | Urgent Pointer |
| [Options] |
: Data :
Note that one tick mark represents one bit position.
A TCP session peer SHOULD
transmit a DTH segment when the TCP session will likely be terminated soon. It can be sent from both the server and client. The application or TCP stack MAY
elect not to send DTH segments, even if it knows that the session will be terminated. This results in a dramatic surprise for the peer; however, the end users may perceive the end too convenient or overly simplistic. Use of the DTH segment that is not associated with the session termination is not encouraged but it is permitted. (This is often referred to as "teasing" or a false-positive DTH flag.)
The DTH flag is informational. TCP software that does not implement this feature can safely ignore this flag. However, to fully appreciate the session, users should be aware of the subtle signs of the session narratives.
The DTH flag itself does not change the sequence or acknowledgment number. It does not require any acknowledgement.
The recipient of the flag is not required to act differently upon reception; however, it is RECOMMENDED
that information be conveyed to the application layer, so the end user can be notified of the incident. The recipient of a DTH segment SHOULD NOT
close the socket immediately upon reception; it SHOULD
wait for a RST or FIN segment.
This specification does not stipulate the maximum number of DTH segments permitted in one TCP session; however, limiting them to a few is RECOMMENDED
to maximize the dramatic effect.
DTH can be used any time the sender considers it important to signal its inevitable end to the TCP peer. The example scenarios below illustrate when to send DTH segments.
A malicious actor can send the flag when it suddenly repents; for example, when a sender suddenly regrets their part in a DDoS attack and unexpectedly ceases the attack. The archvillain generally terminates the sender cruelly and mercilessly soon after the change in behavior (or they are killed for protecting the hero). The timing of DTH transmission is implementation dependent. It can be sent anytime from the early signs of betrayal to just prior to the behavioral change.
The flag can be sent when the sender stops using cryptographic protections and reveals its plain-text content, for example, a mysterious character with a mask that often dies after they expose their face. In this example, the DTH segment would be sent just before sending the redirect (30x) from HTTPS to HTTP [RFC 9110
]. Similarly, the flag can be set when the forged User-Agent or Server HTTP header field is changed to the actual value, when their true identity would be revealed (for example, "I am your long-lost twin", "I am a spy", etc.). This occasionally leads to the death of the character.
The TCP peer is RECOMMENDED
to send the flag when it notices resource issues, e.g., diminishing memory space or bandwidth. An AI bot, cyborg, sorcerer application with forbidden protocols, etc., SHOULD
consider sending the flag when it starts to heavily cough error messages.
An application less capable of performing its task MAY
send the flag from time to time. It will be killed by the OS (the archvillain) or CTRL-C (the end user) sooner or later due to its inefficiency. The same is likely to occur with a memory-hogging application, for example, an unscrupulous character that attempts to take all the treasure often dies accidentally (e.g., falls from a cliff).
An application SHOULD
really think twice before accessing a "honeypot" or haunted server. If your choices are limited (e.g., your favorite server breaks down in the middle of nowhere and the dark server that is not on the DNS is the only place you can shelter), sending the flag periodically is a good idea. The session is most likely cursed.
The DTH flag SHOULD NOT
be piggybacked on the FIN flag. If present, the recipient SHOULD
silently ignore DTH flag. The only exception is when the recipient is an expert at Hokuto-Shinken ("Big Dipper Divine Fist") [WIKI-FNS
]. In that circumstance, the sender is already dead but remains active for a few seconds (which is unofficially called the "half-zombie open" state).
The DTH flag SHOULD NOT
be sent with the URG flag [RFC 6093
]. The use of the URG flag is not recommended in new implementations [RFC 9293
Use of the flag in the early state of a TCP session is NOT RECOMMENDED
. Characters that die in the early stage are considered nonessential, hence their death does not contribute to the quality of the session. (Obviously, there are exceptions.)
Some experimental implementations use the Evil bit [RFC 3514
] of the IP header to indicate if the session portrays an evil character. The DTH flag is not designed to characterize a TCP session. It is intended to show the fate of the session irrespective of the nature of the session. When both Evil bit and DTH flag are present, they MUST
be interpreted independently.