[要約] RFC 9401 は、TCP に Death (DTH) フラグを追加することを指定し、TCP ヘッダー内の1ビットの使用方法を定めています。このフラグは、TCP セッションの物語をスムーズで魅力的にすることを目的としています。
Independent Submission S. Toyosawa
Request for Comments: 9401 Independent
Category: Informational 1 April 2023
ISSN: 2070-1721
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.
このメモは、TCPヘッダーでの1ビットの使用を含む、TCPへの死（DTH）フラグの組み込み（DTH）を指定しています。フラグは、TCPセッションの物語をスムーズで魅力的にするように設計されています。
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.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。RFCエディターは、このドキュメントの裁量でこのドキュメントを公開することを選択しており、実装または展開に対する価値について声明を発表しません。RFCエディターによって公開されることが承認されたドキュメントは、インターネット標準のレベルの候補者ではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9401.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9401で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) 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.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
1. Introduction
2. Requirements Language
3. Specification
3.1. TCP Packet Format
3.2. When to Send
3.3. When Not to Send
3.4. Use with the IP Evil Bit
4. Security Considerations
5. IANA Considerations
6. References
6.1. Normative References
6.2. Informative References
Author's Address
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.
提案されたデスフラグ、または略してDTHは、TCPヘッダーの4番目のフラグビットを使用して、TCPセッションの可能性のある終了を示します。
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.
フラグにより、アプリケーションは急激なセッション終了に備えることができます。ネットワークエンジニアは、この機能がTCP RSTSの1つ以上の根本原因を特定するのに役立つと感じています。重要なエンドユーザーは、情報を使用してTCPの物語をよりよく理解できます。
The flag name is adapted from the custom of anime, manga, or light novels [NOVEL]. "Death Flags" refer to hints that a character will die soon [CBR-FLAG].
フラグ名は、アニメ、漫画、または軽い小説[小説]の習慣から採用されています。「死の旗」とは、キャラクターがすぐに死ぬというヒントを指します[cbr-flag]。
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.
たとえば、邪悪な科学者のdth旗は、彼らが致命的な発明にあまりにも多くの自信を表明するときに設定されます。科学者はしばしば彼ら自身の発明によって殺されます。このタイプの物語は、従来の映画でも一般的です。注目すべき例は、trenchのソリダーです。兵士の旗は、婚約者の写真を共有し、戦闘から戻った後に行われる今後の結婚について話す直後に1に設定されます。別の例は、深夜の遠足のために孤立したキャビンから忍び寄るカップルの旗を設定することです。一般的に、遠足はチェーンソーを持つ個人によって激しく終了します。
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
The DTH flag uses the fourth bit in the Control bits field in TCP header as depicted in Figure 1 [RFC9293]. The fourth bit was intentionally selected because "four" in Chinese is Sì; it has a similar sound to Sǐ, which means "die".
DTHフラグは、図1 [RFC9293]に示すように、TCPヘッダーのコントロールビットフィールドの4番目のビットを使用します。中国語の「4」がsìであるため、4番目のビットは意図的に選択されました。それはseと同様の音を持っています。これは「死ぬ」ことを意味します。
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.
Figure 1: TCP Header with the DTH Flag Bit
図1：DTHフラグビットを備えたTCPヘッダー
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.)
TCPセッションのピアは、TCPセッションがまもなく終了する可能性が高い場合にDTHセグメントを送信する必要があります。サーバーとクライアントの両方から送信できます。アプリケーションまたはTCPスタックは、セッションが終了することを知っていても、DTHセグメントを送信しないことを選択する場合があります。これは、ピアにとって劇的な驚きをもたらします。ただし、エンドユーザーは、終わりが便利すぎる、または過度に単純化されていることを認識する場合があります。セッション終了に関連付けられていないDTHセグメントの使用は奨励されていませんが、許可されています。（これはしばしば「からかい」または偽陽性のDTHフラグと呼ばれます。）
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.
DTHフラグは情報提供です。この機能を実装していないTCPソフトウェアは、このフラグを安全に無視できます。ただし、セッションを完全に評価するには、ユーザーはセッションの物語の微妙な兆候に注意する必要があります。
The DTH flag itself does not change the sequence or acknowledgment number. It does not require any acknowledgement.
DTHフラグ自体は、シーケンスまたは確認番号を変更しません。承認は必要ありません。
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.
旗の受信者は、受信時に異なる行動をとる必要はありません。ただし、情報をアプリケーションレイヤーに伝えることをお勧めします。そうすれば、エンドユーザーにインシデントを通知できます。DTHセグメントの受信者は、受信後すぐにソケットを閉じないでください。RSTまたはFINセグメントを待つ必要があります。
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.
この仕様では、1つのTCPセッションで許可されているDTHセグメントの最大数を規定していません。ただし、劇的な効果を最大化するには、それらをいくつかに制限することをお勧めします。
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.
DTHは、送信者がTCPピアに避けられない終わりを信号することが重要だと考えるときはいつでも使用できます。以下のシナリオの例は、DTHセグメントをいつ送信するかを示しています。
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.
悪意のある俳優は、突然悔い改めたときに旗を送ることができます。たとえば、送信者が突然DDOS攻撃で自分の役割を後悔し、予想外に攻撃をやめたとき。大鳥は一般に、行動の変化の直後に送信者を残酷に容赦なく終わらせます（または、ヒーローを保護するために殺されます）。DTH送信のタイミングは実装に依存します。それは、行動の変化の直前に、裏切りの初期の兆候からいつでも送ることができます。
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 [RFC9110]. 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.
送信者が暗号化保護の使用を停止し、たとえば、顔をさらすとしばしば死ぬマスクを備えた不思議なキャラクターであるプレーンテキストコンテンツを明らかにするときに、フラグを送信できます。この例では、DTHセグメントは、httpsからhttp [rfc9110]にリダイレクト（30x）を送信する直前に送信されます。同様に、ForgedユーザーエージェントまたはサーバーHTTPヘッダーフィールドが実際の値に変更されたときにフラグを設定できます。スパイ」など）。これは時々キャラクターの死につながります。
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.
TCPピアは、リソースの問題に気付いたときにフラグを送信することをお勧めします。たとえば、メモリスペースや帯域幅の減少です。AIボット、サイボーグ、禁止プロトコルを備えた魔術師アプリケーションなどは、咳のエラーメッセージを開始したときにフラグを送信することを検討する必要があります。
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).
タスクを実行できないアプリケーションは、時々フラグを送信する場合があります。その非効率性により、遅かれ早かれOS（Archvillain）またはCtrl-C（エンドユーザー）によって殺されます。同じことが、メモリホーギングのアプリケーションでも発生する可能性があります。たとえば、すべての宝物を取得しようとする不cru慎なキャラクターで、しばしば誤って死にます（たとえば、崖から落ちます）。
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.
「ハニーポット」または幽霊サーバーにアクセスする前に、アプリケーションは本当によく考えてください。選択肢が制限されている場合（たとえば、お気に入りのサーバーがどこにも故障し、DNSにないダークサーバーが避難できる場所だけです）、定期的にフラグを送信することは良い考えです。セッションはおそらく呪われています。
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).
dthフラグは、ひれなフラグに豚をぶら下げてはいけません。存在する場合、受信者はDTHフラグを静かに無視する必要があります。唯一の例外は、受信者が北朝鮮（「ビッグディッパーディバイディスト」）[wiki-fns]の専門家である場合です。そのような状況では、送信者はすでに死んでいますが、数秒間活動し続けています（これは非公式に「Half-Zombie Open」状態と呼ばれています）。
The DTH flag SHOULD NOT be sent with the URG flag [RFC6093]. The use of the URG flag is not recommended in new implementations [RFC9293].
DTHフラグは、URGフラグ[RFC 6093]で送信しないでください。URGフラグの使用は、新しい実装[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.)
TCPセッションの初期状態でのフラグの使用は推奨されません。初期段階で死ぬキャラクターは必須ではないと考えられているため、彼らの死はセッションの質に寄与しません。（明らかに、例外があります。）
Some experimental implementations use the Evil bit [RFC3514] 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.
一部の実験的実装は、IPヘッダーの邪悪なビット[RFC3514]を使用して、セッションが邪悪なキャラクターを描写しているかどうかを示します。DTHフラグは、TCPセッションを特徴付けるようには設計されていません。セッションの性質に関係なく、セッションの運命を示すことを目的としています。邪悪なビットとdthフラグの両方が存在する場合、それらは独立して解釈されなければなりません。
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.
TCPセッションの避けられない死（しばしば暴力的）の前兆は、上層層アプリケーションとエンドユーザーに役立ちます。ただし、セキュリティとユーザビリティバランスも考慮する必要があります。DTHフラグはTCPセッションの内部状態を公開する可能性があるため、攻撃者によって悪用される可能性があります（たとえば、探偵が容疑者を指摘する前に殺人者を命名します）。ネタバレは悪の行為です。物語を秘密にしたい人は、旗を穏やかに使用する必要があります。
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.
このドキュメントでは、TCPヘッダーの現在予約されている（RSRVD）制御ビットの動作を定義します。TCPセッションの運命の有益な指標として使用されます。4番目のビット（TCPヘッダーの13番目のオクテットの初めからカウント）は、その意味を示すために意図的に選択されます。ただし、ビット位置の変化は機能的な劣化を引き起こしません。
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.
この機能は、ハリウッドおよび/または日本のアニメーションスタジオネットワークのさまざまなマナーですでに実装される場合があります。ただし、著者の知る限り、テクノロジーはまだ特許を取得していません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3514] Bellovin, S., "The Security Flag in the IPv4 Header",
RFC 3514, DOI 10.17487/RFC3514, April 2003,
<https://www.rfc-editor.org/info/rfc3514>.
[RFC6093] Gont, F. and A. Yourtchenko, "On the Implementation of the
TCP Urgent Mechanism", RFC 6093, DOI 10.17487/RFC6093,
January 2011, <https://www.rfc-editor.org/info/rfc6093>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)",
STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
<https://www.rfc-editor.org/info/rfc9293>.
[CBR-FLAG] Stalberg, A., "10 Death Flags That Mean An Anime Character
is Probably Going To Die", 2023,
<https://www.cbr.com/anime-death-hints-signs/>.
[NOVEL] Wikipedia, "Light novel", February 2023,
<https://en.wikipedia.org/w/
index.php?title=Light_novel&oldid=1136814877>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[WIKI-FNS] Wikipedia, "List of Fist of the North Star characters",
March 2023, <https://en.wikipedia.org/w/index.php?title=Li
st_of_Fist_of_the_North_Star_characters&oldid=1145633265>.
Satoshi Toyosawa
Independent
Email: s2.toyosawa@gmail.com