メインコンテンツまでスキップ

RFC 9401 - TCP への死亡 (DTH) フラグの追加

  • ステータス: Informational
  • 発行日: April 2023
  • ストリーム: INDEPENDENT
  • エラッタ: エラッタなし

概要 (Abstract)​

このメモは、TCP ヘッダーの 1 ビットの使用を含む、TCP への死亡 (Death, DTH) フラグの組み込みを規定します。このフラグは、TCP セッションのナラティブを滑らかで魅力的にするために設計されています。

このメモのステータス (Status of This Memo)​

この文書はインターネット標準トラック仕様ではありません。情報提供の目的で公開されています。

これは、他の RFC ストリームとは独立した RFC シリーズへの貢献です。RFC エディターは、独自の裁量でこの文書を公開することを選択しており、その実装または展開の価値について何も述べていません。RFC エディターによって公開が承認された文書は、いかなるレベルのインターネット標準の候補でもありません。RFC 7841 のセクション 2 を参照してください。

この文書の現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9401 から入手できます。

著作権 (c) 2023 IETF Trust および文書著者として特定された者。全著作権所有。

この文書は、BCP 78 および IETF 文書に関する IETF Trust の法的規定 (https://trustee.ietf.org/license-info) に従うものであり、これらの規定はこの文書の公開日に有効です。これらの文書には、この文書に関するあなたの権利と制限が記載されているため、注意深くお読みください。

目次 (Contents)​

重要な注意事項​

この RFC は独立提出ストリーム (Independent Submission stream) で公開されています。この RFC は IETF によって承認されておらず、IETF 標準プロセスにおいて正式な地位を持っていません。

注: この文書は 2023 年のエイプリルフール RFC であり、アニメ、マンガ、ライトノベルの「死亡フラグ」(Death Flag) の概念を参照した、ユーモラスな内容を含んでいます。

1. はじめに (Introduction)​

提案された死亡フラグ (Death flag)、略して DTH は、TCP ヘッダーの 4 番目のフラグビットを使用して、TCP セッションの終了が近いことを示します。

このフラグにより、アプリケーションは突然のセッション終了に備えることができます。ネットワークエンジニアは、この機能が TCP RST の 1 つ以上の根本原因を特定するのに役立つことを発見しています。重要なエンドユーザーは、この情報を使用して TCP のナラティブをよりよく理解できます。

フラグ名は、アニメ、マンガ、またはライトノベル [NOVEL] の慣習から採用されています。「死亡フラグ」(Death Flags) は、キャラクターがまもなく死ぬことを示唆するヒントを指します [CBR-FLAG]。

たとえば、邪悪な科学者が致命的な発明に対して過度の自信を表明すると、その DTH フラグが設定されます。科学者はしばしば自分の発明によって殺されます。このタイプのナラティブは、従来の映画でも一般的です。注目すべき例は、塹壕の中の兵士です。兵士が婚約者の写真を共有し、戦場から戻った後に行われる結婚式について語った直後に、兵士のフラグは 1 に設定されます。別の例は、孤立した小屋から深夜の遠足のためにこっそり抜け出すカップルにフラグを設定することです。通常、遠足はチェーンソーを持った個人によって暴力的に終了されます。

参考文献​

2. 要件言語 (Requirements Language)​

この文書のキーワード「MUST」(しなければならない)、「MUST NOT」(してはならない)、「REQUIRED」(必須)、「SHALL」(するものとする)、「SHALL NOT」(しないものとする)、「SHOULD」(すべきである)、「SHOULD NOT」(すべきでない)、「RECOMMENDED」(推奨される)、「NOT RECOMMENDED」(推奨されない)、「MAY」(してもよい)、「OPTIONAL」(任意) は、BCP 14 [RFC2119] [RFC8174] に記載されているとおりに解釈されるものとします。ただし、ここに示すように、すべて大文字で表示される場合に限ります。

参考文献​

  • [RFC2119]: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, 1997年3月
  • [RFC8174]: Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2017年5月

3. 仕様 (Specification)​

3.1. TCP パケットフォーマット (TCP Packet Format)​

DTH フラグは、図 1 [RFC9293] に示すように、TCP ヘッダーの制御ビットフィールドの 4 番目のビットを使用します。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                              :
:                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

注：1 つの目盛りは 1 ビット位置を表します。

図 1: DTH フラグビットを含む TCP ヘッダー

TCP セッションがまもなく終了する可能性が高い場合、TCP セッションピアは DTH セグメントを送信すべきです (SHOULD)。これはサーバーとクライアントの両方から送信できます。アプリケーションまたは TCP スタックは、セッションが終了することを知っていても、DTH セグメントを送信しないことを選択してもかまいません (MAY)。これにより、ピアに劇的な驚きがもたらされます。ただし、エンドユーザーは結末が便利すぎるか、過度に単純であると認識する可能性があります。セッション終了に関連しない DTH セグメントの使用は推奨されませんが、許可されています。（これはしばしば「ティージング」または偽陽性 DTH フラグと呼ばれます。）

DTH フラグは情報提供です。この機能を実装していない TCP ソフトウェアは、このフラグを安全に無視できます。ただし、セッションを完全に理解するには、ユーザーはセッションナラティブの微妙な兆候を認識する必要があります。

DTH フラグ自体は、シーケンス番号または確認応答番号を変更しません。確認応答は必要ありません。

フラグの受信者は、受信時に異なる動作をする必要はありません。ただし、エンドユーザーにインシデントを通知できるように、情報をアプリケーション層に伝達することが推奨されます (RECOMMENDED)。DTH セグメントの受信者は、受信時にすぐにソケットを閉じるべきではありません (SHOULD NOT)。RST または FIN セグメントを待つべきです (SHOULD)。

この仕様では、1 つの TCP セッションで許可される DTH セグメントの最大数は規定されていません。ただし、劇的な効果を最大化するために、数個に制限することが推奨されます (RECOMMENDED)。

3.2. 送信するタイミング (When to Send)​

送信者が TCP ピアに避けられない終わりを知らせることが重要であると考える場合はいつでも、DTH を使用できます。以下のシナリオ例は、DTH セグメントを送信するタイミングを示しています。

悪意のあるアクターは、突然悔い改めるときにフラグを送信できます。たとえば、送信者が DDoS 攻撃への関与を突然後悔し、予期せず攻撃を停止する場合です。大悪党は通常、行動の変化の直後に送信者を残酷かつ無慈悲に終了させます（または、ヒーローを保護したために殺されます）。DTH 送信のタイミングは実装に依存します。裏切りの早期兆候から行動変化の直前までのいつでも送信できます。

送信者が暗号化保護の使用を停止し、平文コンテンツを明らかにする場合、フラグを送信できます。たとえば、顔を露出した後によく死ぬマスクをかぶった謎のキャラクターなどです。この例では、DTH セグメントは HTTPS から HTTP [RFC9110] へのリダイレクト (30x) を送信する直前に送信されます。同様に、偽造された User-Agent または Server HTTP ヘッダーフィールドが実際の値に変更されたとき、真のアイデンティティが明らかになるとき（たとえば、「私はあなたの長く失われた双子です」、「私はスパイです」など）にフラグを設定できます。これは時折、キャラクターの死につながります。

TCP ピアは、リソースの問題に気付いたとき、たとえばメモリ空間や帯域幅の減少などに気付いたときに、フラグを送信することが推奨されます (RECOMMENDED)。AI ボット、サイボーグ、禁じられたプロトコルを持つ魔術師アプリケーションなどは、エラーメッセージを激しく咳き込み始めたときにフラグを送信することを検討すべきです (SHOULD)。

タスクを実行する能力が低いアプリケーションは、時々フラグを送信してもかまいません (MAY)。非効率性のため、遅かれ早かれ OS（大悪党）または CTRL-C（エンドユーザー）によって殺されます。メモリを大量に消費するアプリケーションでも同じことが起こる可能性があります。たとえば、すべての宝物を奪おうとする不誠実なキャラクターは、しばしば偶然死にます（たとえば、崖から落ちる）。

アプリケーションは、「ハニーポット」または幽霊サーバーにアクセスする前に本当によく考えるべきです (SHOULD)。選択肢が限られている場合（たとえば、お気に入りのサーバーが人里離れた場所で故障し、DNS にない暗いサーバーが避難できる唯一の場所である場合）、定期的にフラグを送信することは良い考えです。セッションはおそらく呪われています。

3.3. 送信しないタイミング (When Not to Send)​

DTH フラグは FIN フラグにピギーバックすべきではありません (SHOULD NOT)。存在する場合、受信者は DTH フラグを静かに無視すべきです (SHOULD)。唯一の例外は、受信者が北斗神拳 (Hokuto-Shinken, "Big Dipper Divine Fist") [WIKI-FNS] の専門家である場合です。その状況では、送信者はすでに死んでいますが、数秒間アクティブなままです（これは非公式に「半ゾンビオープン」状態と呼ばれます）。

DTH フラグは URG フラグ [RFC6093] と一緒に送信すべきではありません (SHOULD NOT)。URG フラグの使用は、新しい実装では推奨されません [RFC9293]。

TCP セッションの初期段階でフラグを使用することは推奨されません (NOT RECOMMENDED)。初期段階で死ぬキャラクターは非必須と見なされるため、その死はセッションの質に貢献しません。（明らかに、例外があります。）

3.4. IP Evil Bit との使用 (Use with the IP Evil Bit)​

一部の実験的実装では、IP ヘッダーの Evil ビット [RFC3514] を使用して、セッションが悪のキャラクターを描写しているかどうかを示します。DTH フラグは TCP セッションを特徴付けるように設計されていません。セッションの性質に関係なく、セッションの運命を示すことを意図しています。Evil ビットと DTH フラグの両方が存在する場合、それらは独立して解釈されなければなりません (MUST)。

参考文献​

  • [RFC3514]: Bellovin, S., "The Security Flag in the IPv4 Header", RFC 3514, 2003年4月
  • [RFC6093]: Gont, F. and A. Yourtchenko, "On the Implementation of the TCP Urgent Mechanism", RFC 6093, 2011年1月
  • [RFC9110]: Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, 2022年6月
  • [RFC9293]: Eddy, W., Ed., "Transmission Control Protocol (TCP)", STD 7, RFC 9293, 2022年8月
  • [WIKI-FNS]: Wikipedia, "List of Fist of the North Star characters", 2023年3月

4. セキュリティに関する考慮事項 (Security Considerations)​

TCP セッションの避けられない死（しばしば暴力的）の前兆は、上位層アプリケーションとエンドユーザーにとって有用です。ただし、セキュリティと使いやすさのバランスも考慮する必要があります。DTH フラグは TCP セッションの内部状態を公開する可能性があるため、攻撃者に悪用される可能性があります（たとえば、探偵が容疑者を指摘する前に殺人者を名指しする）。ネタバレは悪行です。ストーリーを秘密にしておきたい人は、フラグを穏やかに使用する必要があります。

リスク分析​

  1. 情報開示 (Information Disclosure): DTH フラグは、セッションの差し迫った終了に関する情報を攻撃者に明らかにする可能性があり、これはタイミング攻撃や他の悪意のある目的に使用される可能性があります。

  2. サービス拒否 (Denial of Service): 悪意のあるアクターは、DTH フラグを悪用して受信者を誤解させ、不必要なリソース割り当てやセッション管理の問題を引き起こす可能性があります。

  3. プライバシーに関する考慮事項 (Privacy Considerations): DTH フラグの過度の使用は、アプリケーションの動作パターンを漏洩し、それによってユーザーのプライバシーに影響を与える可能性があります。

  4. ネタバレ効果 (Spoiler Effect): セッション終了の事前知識は、ユーザー体験の劇的要素と驚き要素を減少させる可能性があります。

推奨事項​

  • 実装者は、DTH フラグを慎重に使用し、不必要な場合にフラグを設定することを避けるべきです。
  • ネットワーク管理者は、DTH フラグの使用パターンを監視して、潜在的なセキュリティ脅威を特定する必要があります。
  • アプリケーション開発者は、DTH フラグがもたらす可能性のあるセキュリティへの影響を考慮し、適切な保護措置を実装する必要があります。

5. IANA に関する考慮事項 (IANA Considerations)​

この文書は、TCP ヘッダーの現在予約されている (Reserved, Rsrvd) 制御ビットの 1 つの動作を定義します。これは TCP セッションの運命の情報提供インジケーターとして使用されます。4 番目のビット（TCP ヘッダーの 13 番目のオクテットの先頭から数えて）は、その意味を示すために意図的に選択されています。ただし、ビット位置の変更は、機能的な劣化を引き起こしません。

この機能は、ハリウッドおよび/または日本のアニメーションスタジオネットワークで既に異なる方法で実装されている可能性があります。ただし、著者の知る限り、この技術はまだ特許を取得していません。

TCP ヘッダー制御ビット割り当て​

この仕様は、以前は予約状態にあった TCP ヘッダーの制御ビットフィールドの 4 番目のビットを使用します。

ビット位置: ビット 4（制御ビットフィールドの開始から数えて）
フラグ名: DTH (Death)
目的: TCP セッションがまもなく終了する可能性があることを示す情報提供フラグ
参照: この文書

登録要件​

この文書は DTH フラグの使用を定義していますが、情報提供 RFC として公開されており、IANA TCP パラメータレジストリへの正式な変更要求を構成するものではありません。本番環境でこのフラグを使用したい実装者は、その非標準的な性質に注意する必要があります。

実装に関する注意事項​

  1. 下位互換性 (Backward Compatibility): DTH フラグをサポートしていない TCP 実装は、このビットを予約ビットとして扱うため、単にこのビットを無視します。

  2. 相互運用性 (Interoperability): DTH フラグの使用は、レガシー TCP 実装との相互運用性に影響を与えるべきではありません。

  3. 特許状況 (Patent Status): 著者の知る限り、この技術は特許保護されていませんが、ハリウッドまたは日本のアニメーションスタジオが独立して類似のナラティブ技術を開発している可能性があります。

6. 参考文献 (References)​

6.1. 規範的参考文献 (Normative References)​

6.2. 情報的参考文献 (Informative References)​

参考文献の説明​

規範的参考文献 (Normative References)​

規範的参考文献は、この仕様を実装するために必要な文書です。これらの文書は、DTH フラグの動作に必要な重要なプロトコル要素とキーワードの解釈を定義しています。

情報的参考文献 (Informative References)​

情報的参考文献は、DTH フラグの概念的起源と関連する背景に関する追加情報を提供します。これらの参考文献は、「死亡フラグ」概念の文化的背景を理解するのに役立ちますが、この仕様を実装するために必要ではありません。

関連 RFC 文書​

  • RFC 793 - Transmission Control Protocol (TCP の元の仕様)
  • RFC 9293 - Transmission Control Protocol (TCP の最新更新)
  • RFC 3514 - The Security Flag in the IPv4 Header (IP Evil Bit、別のエイプリルフール RFC)
  • RFC 2119 - Key words for use in RFCs (RFC キーワード定義)
  • RFC 8174 - Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words (RFC 2119 キーワードの大文字小文字の明確化)

著者の連絡先 (Author's Address)​

Satoshi Toyosawa
独立 (Independent)
電子メール (Email): [email protected]

著者について​

Satoshi Toyosawa は、ネットワークプロトコルとユーモラスな技術文書に強い関心を持つ独立研究者です。RFC 9401 は、アニメやマンガの「死亡フラグ」概念を TCP プロトコルに創造的に適用した、IETF エイプリルフール RFC の伝統への著者の貢献です。

連絡先情報​

この RFC に関する質問、提案、またはコメントについては、上記の電子メールアドレスで著者に連絡してください。

謝辞​

この文書にフィードバックと提案を提供してくださったすべての方に感謝します。特に、アニメ、マンガ、ネットワークプロトコルの交差点でのユーモアを理解し、感謝してくださった方々に感謝します。

歴史的背景​

この文書は 2023 年 4 月 1 日に公開され、IETF のエイプリルフール RFC の伝統を継続しています。この伝統は 1978 年の RFC 748 に始まり、長年にわたって多くの創造的でユーモラスな技術文書を生み出してきました。以下を含みます:

  • RFC 1149 - A Standard for the Transmission of IP Datagrams on Avian Carriers (伝書鳩による IP データグラム伝送)
  • RFC 2324 - Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0) (ハイパーテキストコーヒーポット制御プロトコル)
  • RFC 3514 - The Security Flag in the IPv4 Header (IP Evil Bit)
  • RFC 7511 - Scenic Routing for IPv6 (IPv6 の風光明媚なルーティング)
  • RFC 9401 - The Addition of the Death (DTH) Flag to TCP (この文書)

これらのエイプリルフール RFC はユーモラスな性質を持っていますが、多くの場合、実際の技術的問題に対する深い洞察を含み、技術コミュニティの創造性とユーモアのセンスを示しています。