はじめに
- この文書は RFC9401 を勉強と好奇心のため適当に訳したものです。
- 翻訳の正確さは全く保証しません。
- 誤字誤訳等の指摘はいつでも大歓迎です。
- アニメ、漫画、ライトノベルなどで有名な「死亡フラグ」を TCP に追加しようというもの？
- 著者(Satoshi Toyosawa さん)は日本人だったりするのかな？ もしそうなら、公式の日本語版を出してほしい……（既にどこかにある？）。
- 今年のジョーク RFC は RFC9401、RFC9402、RFC9405 の３本でした。その他は、ジョーク RFC 一覧 をどうぞ。
The Addition of the Death (DTH) Flag to TCP（TCP への死亡フラグ(DTH)の追加）
- Independent Submission
- Request for Comments: 9401
- Category: Informational
- ISSN: 2070-1721
- S. Toyosawa
- Independent
- 1 April 2023
Abstract（概要）
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 ヘッダーでの DTH の 1 ビットの使用を含め、TCP への死亡フラグ (DTH) の組み込みの仕様を規定する。
このフラグは、TCP セッションの話の流れをスムーズで魅力的にするように設計されている。
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.
これは、他の 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.
この文書の現在のステータス、正誤表、フィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9401 で入手できる。
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
(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.
Table of Contents
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
1. 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.
提案する死亡フラグ (略して 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 RST の 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].
フラグの名前は、アニメや漫画、ライトノベルの風習を取り入れた [NOVEL]。 「死亡フラグ」とは、キャラクターが間もなく死亡するというヒントをしめす [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 フラグは、致死の発明に過度の自信を示したときに設定される。 科学者はしばしば自分の発明によって殺される。 このタイプの物語は、従来の映画でも一般的である。 注目すべき例は、塹壕の兵士である。 兵士のフラグは、婚約者の写真を共有し、戦闘から戻った後に行われる次の結婚について伝えた直後に 1 に設定さる。 もう 1 つの例は、深夜の小旅行のために隔離された小屋からこっそり抜け出すカップルにフラグを設定することである。 一般的に、小旅行はチェーンソーを持った個人によって暴力的に終了される。
2. 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 [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」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」 」は、ここに示すようにすべて大文字で表示される場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈される。
3. Specification（仕様）
3.1. TCP Packet Format（TCP パケットフォーマット）
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 に示すように、TCP ヘッダーの制御ビット フィールドの 4 番目のビットを使用する [RFC9293]。 4 番目のビットが意図的に選択されたのは、中国語の「四」が Sì であるためである。 「死」を意味するSǐに似た音を持っている。
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.
1 つの目盛りは 1 つのビット位置を表すことに注意すること。
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 セグメントを送信する必要がある (SHOULD)。 サーバーとクライアントの両方から送信できる (MAY)。 アプリケーションまたは 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 フラグ自体は、シーケンスまたは確認応答番号を変更しない。 承認(ACK)は必要ない。
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.
フラグの受信者は、受信時に別の行動をとる必要はない。 ただし、エンドユーザーにインシデントを通知できるように、情報をアプリケーション層に伝達することを推奨する (RECOMMENDED)。 DTH セグメントの受信者は、受信直後にソケットを閉じるべきではない(SHOULD NOT)。 RST または FIN セグメントを待機する必要がある (SHOULD)。
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 セグメントの最大数を規定していない。 ただし、劇的な効果を最大化するには、数に制限することを推奨する (RECOMMENDED)。
3.2. 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.
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 へのリダイレクト (30x) を送信する直前に送信される [RFC9110]。
同様に、偽造された User-Agent または Server 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 ピアは、メモリスペースや帯域幅の減少など、リソースの問題に気付いたときにフラグを送信することを推奨する(RECOMMENDED)。 禁止されたプロトコルを使用する AI ボット、サイボーグ、ソーサラーアプリケーションなどは、エラーメッセージを大量に吐き出し始めたときにフラグの送信を検討する必要がある (SHOULD)。
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).
タスクを実行する能力の低いアプリケーションは、時々フラグを送ることができる (MAY)。 遅かれ早かれ、その非効率性のために、OS (宿敵) または CTRL-C (エンドユーザー) によって殺される。 同じことが、メモリを大量に消費するアプリケーションでも発生する可能性がある。たとえば、すべての宝物を奪おうとする不謹慎なキャラクターは、しばしば偶発的に死亡する (たとえば、崖から落ちる)。
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.
アプリケーションは、「ハニーポット」または呪われたサーバー（訳注：パフォーマンスの低下、不安定な動作をしているサーバーの意味）にアクセスする前に、よく考えるべきである (SHOULD)。 選択肢が限られている場合 (たとえば、お気に入りのサーバーが人里離れた場所で故障し、DNS 上にないダークサーバーが避難できる唯一の場所である場合)、定期的にフラグを送信することをよいアイデアである。 セッションはおそらく呪われている。
3.3. 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") [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 フラグは、FIN フラグに相乗りすべきではない (SHOULD NOT)。 存在する場合、受信者は DTH フラグを黙って無視する必要がある (SHOULD)。 唯一の例外は、受信者が北斗神拳 ("Big Dipper Divine Fist") の専門家である場合である [WIKI-FNS]。 その状況では、送信者はすでに死んでいるが、数秒間アクティブなままである (これは非公式に「ハーフゾンビオープン」状態と呼ばれる)。
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] と共に送信すべきではない(SHOULD NOT)。 新しい実装では、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 セッションの初期状態でのフラグの使用は推奨されない(NOT RECOMMENDED)。 初期段階で死亡したキャラクターは必須ではないと見なされるため、死亡してもセッションの質には影響しない。 （もちろん、例外もある。）
3.4. Use with the IP Evil Bit（IP Evil ビットとの併用）
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 ヘッダーの Evil ビット [RFC3514] を使用して、セッションが悪のキャラクターを描写しているかどうかを示す。 DTH フラグは、TCP セッションを特徴付けるようには設計されていない。 セッションの性質に関係なく、セッションの運命を示すことを目的としている。 Evil ビットと DTH フラグの両方が存在する場合、それらは個別に解釈されなければならない(MUST)。
4. 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.
TCP セッションの必然的な死 (しばしば暴力的) の前兆は、上位層のアプリケーションとエンドユーザーにとって有用である。 ただし、セキュリティと使いやすさのバランスも考慮する必要がある。 DTH フラグは TCP セッションの内部状態を公開する可能性があるため、攻撃者によって悪用される可能性がある (たとえば、探偵が容疑者を指摘する前に殺人者を指名するなど)。 スポイラー(ネタばれ)は悪の行為である。 ストーリーを秘密にしたい人は、フラグを控えめに使用する必要がある。
5. IANA Considerations（IANAに関する考慮事項）
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) 制御ビットの 1 つの動作を定義する。 これは、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.
この機能は、ハリウッドや日本のアニメーション スタジオ ネットワークで既にさまざまな方法で実装されている可能性がある。 ただし、著者の知る限り、この技術はまだ特許を取得されていない。
6. References
6.1. Normative References
[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>.
6.2. Informative References
[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>.
Author's Address
Satoshi Toyosawa
Independent
Email: s2.toyosawa@gmail.com