The Addition of the Death (DTH) Flag to TCPIndependents2.toyosawa@gmail.comTCPControl bitsflags
This memo specifies the incorporation of Death (DTH) flag to TCP,
including DTH's use of one bit in the TCP header. The flag is
designed to make TCP session narratives smooth and attractive.Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This is a contribution to the RFC Series, independently of any
other RFC stream. The RFC Editor has chosen to publish this
document at its discretion and makes no statement about its value
for implementation or deployment. Documents approved for
publication by the RFC Editor are not candidates for any level of
Internet Standard; see Section 2 of RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
() in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document.
Table of Contents
. Introduction
. Requirements Language
. Specification
. TCP Packet Format
. When to Send
. When Not to Send
. Use with the IP Evil Bit
. Security Considerations
. IANA Considerations
. References
. Normative References
. Informative References
Author's Address
Introduction
The proposed Death flag, or DTH for short, uses the fourth flag bit in the TCP header
to indicate likely termination of the TCP session.
The flag allows applications to prepare for abrupt session
terminations. Network engineers find this feature helpful in identifying
the one or more root causes of TCP RSTs. Critical end users can use the
information to better understand TCP narratives.
The flag name is adapted from the custom of anime, manga, or
light novels . "Death Flags" refer to hints that a character will die
soon .
For example, the DTH flag of an evil scientist is set when they
express too much confidence in their deadly invention. The scientist is often killed by their own invention.
This type of narrative is also common in conventional films.
A notable example is a solider in a trench. The soldier's flag is set to
1 immediately after they share a photograph of their fiancé and tell
about the upcoming marriage that will take place after returning from battle.
Another example is setting the flag for
a couple sneaking out from an isolated cabin for a
late-night excursion. Commonly, the excursion is violently
terminated by an individual with a chainsaw.Requirements Language
The key words "MUST", "MUST NOT",
"REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT",
"RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be
interpreted as described in BCP 14 when, and only when, they appear in all capitals, as
shown here.
SpecificationTCP Packet Format
The DTH flag uses the fourth bit in the
Control bits field in TCP header as depicted in Figure 1 .
The fourth bit was intentionally selected because "four" in Chinese is Sì; it has a similar sound to Sǐ, which means "die".
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.When to Send
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 . 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.When Not to Send
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") . 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 . The
use of the URG flag is not recommended in new implementations .
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.)Use with the IP Evil Bit
Some experimental implementations use the Evil bit 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.Security Considerations
Precursors to the inevitable death (often violent) of a TCP session
are useful for upper-layer applications and end users; however, the
security vs. usability balance should also be considered. Since DTH
flags may expose the internal state of the TCP session, they can be
exploited by attackers (e.g., naming the murderer before the
detective points out the suspect). Spoilers are an act of
evil. Those who wish to keep the story secret should use the
flag mildly.IANA Considerations
This document defines the behavior of the one of the currently reserved (Rsrvd) control bits in the
TCP header. It is used as an
informative indicator of the fate of a TCP session. The fourth bit
(counting from the beginning of the thirteenth octet in a TCP header) is
intentionally selected to signify its meaning; however, a change in the
bit position does not cause any functional deterioration.
This feature may already be implemented in different manners
in Hollywood and/or Japanese animation studio networks; however, to the
author's knowledge, the technology is not yet patented.ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.The Security Flag in the IPv4 HeaderFirewalls, packet filters, intrusion detection systems, and the like often have difficulty distinguishing between packets that have malicious intent and those that are merely unusual. We define a security flag in the IPv4 header as a means of distinguishing the two cases. This memo provides information for the Internet community.On the Implementation of the TCP Urgent MechanismThis document analyzes how current TCP implementations process TCP urgent indications and how the behavior of some widely deployed middleboxes affects how end systems process urgent indications. This document updates the relevant specifications such that they accommodate current practice in processing TCP urgent indications, raises awareness about the reliability of TCP urgent indications in the Internet, and recommends against the use of urgent indications (but provides advice to applications that do). [STANDARDS-TRACK]Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Transmission Control Protocol (TCP)This document specifies the Transmission Control Protocol (TCP). TCP is an important transport-layer protocol in the Internet protocol stack, and it has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs 1011 and 1122, and it should be considered as a replacement for the portions of those documents dealing with TCP requirements. It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state. The TCP header control bits from RFC 793 have also been updated based on RFC 3168.Informative References10 Death Flags That Mean An Anime Character is Probably Going To DieLight novelWikipediaHTTP SemanticsThe Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes.This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.List of Fist of the North Star charactersWikipediaAuthor's AddressIndependents2.toyosawa@gmail.com