Internet Engineering Task Force (IETF) M. Boucadair
Request for Comments: 9565 Orange
Obsoletes: 7125 March 2024
Category: Standards Track
ISSN: 2070-1721
RFC 7125 revised the tcpControlBits IP Flow Information Export (IPFIX) Information Element that was originally defined in RFC 5102 to reflect changes to the TCP header control bits since RFC 793. However, that update is still problematic for interoperability because some flag values have subsequently been deprecated.
RFC 7125は、RFC 793以降のTCPヘッダー制御ビットの変更を反映するためにRFC 5102で元々定義されていたTCPControlbits IPフロー情報エクスポート（IPFIX）情報要素を改訂しました。非推奨。
This document removes stale information from the IANA "IPFIX Information Elements" registry and avoids future conflicts with the authoritative IANA "TCP Header Flags" registry.
このドキュメントは、IANAの「IPFIX情報要素」レジストリから古い情報を削除し、権威あるIANA「TCPヘッダーフラグ」レジストリとの将来の競合を回避します。
This document obsoletes RFC 7125.
このドキュメントは、RFC 7125を廃止します。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、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/rfc9565.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9565で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Terminology
3. Revised tcpControlBits Information Element
4. An Example
5. IANA Considerations
6. Security Considerations
7. References
7.1. Normative References
7.2. Informative References
Appendix A. Changes from RFC 7125
Acknowledgments
Acknowledgments from RFC 7125
Contributors
Author's Address
TCP defines a set of control bits (also known as "flags") for managing connections (Section 3.1 of [RFC9293]). The "TCP Header Flags" registry was initially set by [RFC3168], but it was populated with only TCP control bits that were defined in [RFC3168]. [RFC9293] fixed that by moving that registry to be listed as a subregistry under the "Transmission Control Protocol (TCP) Parameters" registry [TCP-FLAGS], adding bits that had previously been specified in [RFC0793], and removing the NS (Nonce Sum) bit per [RFC8311]. Also, Section 6 of [RFC9293] introduces "Bit Offset" to ease referencing each header flag's offset within the 16-bit aligned view of the TCP header (Figure 1 of [RFC9293]). [TCP-FLAGS] is thus settled as the authoritative reference for the assigned TCP control bits.
TCPは、接続を管理するためのコントロールビットのセット（「フラグ」とも呼ばれます）を定義します（[RFC9293]のセクション3.1）。「TCPヘッダーフラグ」レジストリは最初は[RFC3168]によって設定されましたが、[RFC3168]で定義されたTCPコントロールビットのみが入力されました。[RFC9293]は、そのレジストリを「トランスミッションコントロールプロトコル（TCP）パラメーター」レジストリ[TCP-FLAGS]に基づいてサブレジストリとしてリストすることにより、[RFC0793]で以前に指定されていたビットを追加し、NS（[rfc8311]ごとにビット）。また、[RFC9293]のセクション6では、「ビットオフセット」を導入して、TCPヘッダーの16ビットアライメントビュー内の各ヘッダーフラグのオフセットを容易にします（[RFC9293]の図1）。したがって、[TCP-FLAGS]は、割り当てられたTCP制御ビットの権威ある参照として解決されます。
Note: The bits in offsets 0 through 3 are not header flags, but the TCP segment Data Offset field.
注：オフセット0〜3のビットはヘッダーフラグではなく、TCPセグメントデータオフセットフィールドです。
[RFC7125] revised the tcpControlBits IP Flow Information Export (IPFIX) Information Element that was originally defined in [RFC5102] to reflect changes to the TCP control bits since [RFC0793]. However, that update is still problematic for interoperability because a value was deprecated since then (Section 7 of [RFC8311]), and, therefore, [RFC7125] risks deviating from the authoritative "TCP Header Flags" registry [TCP-FLAGS].
[RFC7125]は、[RFC0793]以降のTCP制御ビットの変化を反映するために、[RFC5102]で元々[RFC5102]で定義されていたTCPControlbits IPフロー情報エクスポート（IPFIX）情報要素を修正しました。ただし、その更新は、それ以来値が非推奨（[RFC8311]のセクション7）であるため、相互運用性にとって依然として問題があります。
This document fixes that problem by removing stale information from the "IPFIX Information Elements" registry [IPFIX] and avoiding future conflicts with the authoritative "TCP Header Flags" registry [TCP-FLAGS]. The update in this document also enhances observability. For example, network operators can identify packets that are observed with unassigned TCP flags set and, therefore, identify which applications in the network should be upgraded to reflect the changes to TCP flags that were introduced, e.g., in [RFC8311].
このドキュメントは、「IPFIX情報要素」レジストリ[IPFIX]から古い情報を削除し、権威ある「TCPヘッダーフラグ」レジストリ[TCP-FLAGS]との将来の競合を回避することにより、その問題を修正します。このドキュメントの更新は、観察性も向上します。たとえば、ネットワークオペレーターは、未割り当てのTCPフラグセットで観察されるパケットを識別でき、したがって、[RFC8311]で導入されたTCPフラグの変更を反映するようにネットワーク内のどのアプリケーションをアップグレードする必要があるかを特定できます。
The main changes from [RFC7125] are listed in Appendix A.
[RFC7125]からの主な変更は、付録Aにリストされています。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
This document uses the terms defined in Section 2 of [RFC7011].
このドキュメントでは、[RFC7011]のセクション2で定義されている用語を使用します。
ElementID:
ElementID：
6
6
Name:
名前：
tcpControlBits
tcpcontrolbits
Abstract Data Type:
抽象データ型：
unsigned16
unsigned16
Data Type Semantics:
データ型セマンティクス：
flags
フラグ
Status:
状態：
current
現在カレント現行流れ当座風潮瀬一水ストリーム
Description:
説明：
TCP control bits observed for the packets of this Flow. This information is encoded as a bit field; each TCP control bit has a corresponding bit in that field. A bit is set to 1 if any observed packet of this Flow has the corresponding TCP control bit set to 1. The bit is cleared to 0 otherwise.
このフローのパケットに対して観察されたTCP制御ビット。この情報は、少しフィールドとしてエンコードされています。各TCPコントロールビットは、そのフィールドに対応するビットを持っています。このフローの観察されたパケットに対応するTCPコントロールビットが1に設定されている場合、ビットは1に設定されます。ビットは0にクリアされます。
Per [RFC9293], the assignment of TCP control bits is managed by IANA via the "TCP Header Flags" registry [TCP-FLAGS]. Implementers can retrieve the current TCP control bits from that registry, which is authoritative for them.
[RFC9293]に従って、TCP制御ビットの割り当ては、「TCPヘッダーフラグ」レジストリ[TCP-FLAGS]を介してIANAによって管理されます。実装者は、そのレジストリから現在のTCP制御ビットを取得できます。
As the most significant 4 bits of octets 12 and 13 (counting from zero) of the TCP header [RFC9293] are used to encode the TCP data offset (header length), the corresponding bits in this Information Element MUST be reported by the Exporter with a value of zero and MUST be ignored by the Collector. Use the tcpHeaderLength Information Element to encode this value.
TCPヘッダー[RFC9293]の最も重要な4ビット12および13（ゼロからカウント）を使用してTCPデータオフセット（ヘッダー長）をエンコードするため、この情報要素の対応するビットは、輸出国が報告する必要があります。ゼロの値であり、コレクターは無視する必要があります。TCPheaderLength情報要素を使用して、この値をエンコードします。
All TCP control bits (including those unassigned) MUST be exported as observed in the TCP headers of the packets of this Flow.
すべてのTCP制御ビット（未割り当てのものを含む）は、このフローのパケットのTCPヘッダーで観察されるようにエクスポートする必要があります。
If exported as a single octet with reduced-size encoding (Section 6.2 of [RFC7011]), this Information Element covers the low-order octet of this field (i.e., bit offset positions 8 to 15) [TCP-FLAGS]. A Collector receiving this Information Element with reduced-size encoding must not assume anything about the content of the four bits with bit offset positions 4 to 7.
縮小サイズのエンコードを備えた単一のオクテットとしてエクスポートされた場合（[RFC7011]のセクション6.2）、この情報要素はこのフィールドの低次のオクテット（つまり、ビットオフセット位置8〜15）[TCP-FLAGS]をカバーします。縮小サイズのエンコードでこの情報要素を受信するコレクターは、ビットオフセット位置4〜7の4ビットのコンテンツについて何も想定してはなりません。
Exporting Processes exporting this Information Element on behalf of a Metering Process that is not capable of observing any of the flags with bit offset positions 4 to 7 SHOULD use reduced-size encoding, and only export the least significant 8 bits of this Information Element.
この情報要素をエクスポートするプロセスのエクスポートは、ビットオフセット位置4〜7のフラグを観察できない計量プロセスに代わってエクスポートする必要があります。
Note that previous revisions of this Information Element's definition specified that flags with bit offset positions 8 and 9 must be exported as zero, even if observed. Collectors should therefore not assume that a value of zero for these bits in this Information Element indicates the bits were never set in the observed traffic, especially if these bits are zero in every Flow Record sent by a given Exporter.
この情報要素の定義の以前の改訂は、たとえ観察されたとしても、ビットオフセット位置8と9のフラグをゼロとしてエクスポートする必要があることを指定したことに注意してください。したがって、コレクターは、この情報要素のこれらのビットのゼロの値が、特に特定の輸出業者から送信されたすべてのフローレコードでこれらのビットがゼロである場合、観測されたトラフィックにビットが設定されないことを示していると仮定すべきではありません。
Note also that the "TCP Header Flags" registry [TCP-FLAGS] indexes the bit offset from the most significant bit of octet 12 to the least significant bit of octet 13 in the TCP header, but the tcpControlBits is encoded as a regular unsigned 16-bit integer.
また、「TCPヘッダーフラグ」レジストリ[TCP-FLAGS]は、TCPヘッダーのオクテット12の最も重要なビットからオクテット13の最も重要なビットからビットオフセットをインデックス化するが、TCPCONTROLBITSは通常の署名されていない16としてエンコードされていることに注意してください。 - ビット整数。
Units:
ユニット：
Range:
範囲：
Additional Information:
追加情報：
See the assigned TCP control bits in the "TCP Header Flags" registry [TCP-FLAGS].
「TCPヘッダーフラグ」レジストリ[TCP-Flags]に割り当てられたTCPコントロールビットを参照してください。
Reference:
参照：
[RFC9293], RFC 9565
[RFC9293]、RFC 9565
Revision:
リビジョン：
2
2
Figure 1 shows an example of a tcpControlBits Information Element set to 0x92, where MSB indicates the most significant bit and LSB indicates the least significant bit. This Information Element is used to report TCP control bits for a Flow that has CWR (Congestion Window Reduced), ACK, and SYN flag bits set (that is, bit offset positions 8, 11, and 14).
図1は、0x92に設定されたTCPControlbits情報要素の例を示しています。ここで、MSBは最も重要なビットを示し、LSBは最も有意なビットを示します。この情報要素は、CWR（混雑ウィンドウが減少）、ACK、およびSynフラグビットセット（つまり、ビットオフセット位置8、11、および14）のフローのTCP制御ビットを報告するために使用されます。
MSB LSB
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|0|0|0|0|1|0|0|1|0|0|1|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: An Example of the tcpControlBits Information Element
図1：TCPControlbits情報要素の例
IANA has updated the "tcpControlBits" entry of the "IPFIX Information Elements" registry [IPFIX] to echo the details provided in Section 3.
IANAは、「IPFIX情報要素」レジストリ[IPFIX]の「TCPControlbits」エントリを更新して、セクション3で提供される詳細をエコーしました。
Because the setting of TCP control bits may be misused in some Flows (e.g., Distributed Denial-of-Service (DDoS) attacks), an Exporter has to report all observed control bits even if no meaning is associated with a given TCP flag. This document uses a stronger requirements language compared to [RFC7125].
TCPコントロールビットの設定は、一部のフロー（たとえば、分散型サービス拒否（DDOS）攻撃）で誤用される可能性があるため、輸出業者は、特定のTCPフラグに関連付けられていなくても、観察されたすべてのコントロールビットを報告する必要があります。このドキュメントでは、[RFC7125]と比較して、より強力な要件言語を使用しています。
This document does not add new security considerations to those already discussed for IPFIX in [RFC7011].
このドキュメントでは、[RFC7011]でIPFIXについてすでに議論されている人々に新しいセキュリティ上の考慮事項を追加しません。
[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>.
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
"Specification of the IP Flow Information Export (IPFIX)
Protocol for the Exchange of Flow Information", STD 77,
RFC 7011, DOI 10.17487/RFC7011, September 2013,
<https://www.rfc-editor.org/info/rfc7011>.
[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>.
[TCP-FLAGS]
IANA, "TCP Header Flags",
<https://www.iana.org/assignments/tcp-parameters/>.
[IPFIX] IANA, "IPFIX Information Elements",
<https://www.iana.org/assignments/ipfix/>.
[RFC0793] Postel, J., "Transmission Control Protocol", RFC 793,
DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>.
[RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J.
Meyer, "Information Model for IP Flow Information Export",
RFC 5102, DOI 10.17487/RFC5102, January 2008,
<https://www.rfc-editor.org/info/rfc5102>.
[RFC7125] Trammell, B. and P. Aitken, "Revision of the
tcpControlBits IP Flow Information Export (IPFIX)
Information Element", RFC 7125, DOI 10.17487/RFC7125,
February 2014, <https://www.rfc-editor.org/info/rfc7125>.
[RFC8311] Black, D., "Relaxing Restrictions on Explicit Congestion
Notification (ECN) Experimentation", RFC 8311,
DOI 10.17487/RFC8311, January 2018,
<https://www.rfc-editor.org/info/rfc8311>.
[RFC9487] Graf, T., Claise, B., and P. Francois, "Export of Segment
Routing over IPv6 Information in IP Flow Information
Export (IPFIX)", RFC 9487, DOI 10.17487/RFC9487, November
2023, <https://www.rfc-editor.org/info/rfc9487>.
* Cleaned up the description of the tcpControlBits Information Element by removing mentions of stale flag bits, referring to the flag bits by their bit offset position, and relying upon the IANA "TCP Header Flags" registry.
* 古いフラグビットの言及を削除し、ビットオフセット位置でフラグビットを参照し、IANAの「TCPヘッダーフラグ」レジストリに依存することにより、TCPControlbits情報要素の説明をクリーンアップしました。
* Removed the table of TCP flag bits from the description of the tcpControlBits Information Element.
* TCPControlbits情報要素の説明からTCPフラグビットのテーブルを削除しました。
* Added the reference [TCP-FLAGS] to the Additional Information field of the tcpControlBits Information Element.
* TCPControlbits情報要素の追加情報フィールドに参照[TCP-FLAGS]を追加しました。
* Used strong normative language for exporting observed flags.
* 観測されたフラグをエクスポートするために強力な規範的言語を使用しました。
* Updated the references of the tcpControlBits Information Element.
* TCPコントロールビット情報要素の参照を更新します。
* Bumped the revision of the tcpControlBits Information Element.
* TCPControlbits情報要素の改訂に衝突しました。
* Replaced obsolete RFCs (e.g., [RFC0793]).
* 廃止されたRFCS（例：[RFC0793]）を置き換えました。
* Added an example section (Section 4).
* セクションの例（セクション4）を追加しました。
This document was triggered by a discussion in the opsawg working group between the author and the authors of [RFC9487].
この文書は、著者と[RFC9487]の著者との間のOpSAWGワーキンググループでの議論によって引き起こされました。
Thanks to Christian Jacquenet, Thomas Graf, and Benoît Claise for the review and comments.
Christian Jacquenet、Thomas Graf、およびBenoîtClaiseにレビューとコメントをしてくれたことに感謝します。
Thanks to Michael Scharf for the tsvart review, Ketan Talaulikar for the rtgdir review, and Elwyn Davies for the genart review.
TSVARTレビューのMichael Scharf、RTGDIRレビューのKetan Talaulikar、Genart ReviewのElwyn Daviesに感謝します。
Thanks to Rob Wilton for the AD review.
広告レビューをしてくれたRob Wiltonに感謝します。
Thanks to Tim Bray for the artart review and Shawn Emery for the secdir review.
Artart ReviewのTim BrayとSecdir ReviewのShawn Emeryに感謝します。
Thanks to Éric Vyncke and Paul Wouters for the comments in the IESG review.
IESGレビューのコメントについては、エリック・ヴィンケとポール・ウーターズに感謝します。
Thanks to Andrew Feren, Lothar Braun, Michael Scharf, and Simon Josefsson for comments on the revised definition. This work is partially supported by the European Commission under grant agreement FP7-ICT-318627 mPlane; this does not imply endorsement by the Commission.
Andrew Feren、Lothar Braun、Michael Scharf、およびSimon Josefssonに、改訂された定義についてのコメントに感謝します。この作業は、助成金契約FP7-ich-318627 Mplaneに基づく欧州委員会によって部分的にサポートされています。これは、委員会による承認を意味するものではありません。
The authors of [RFC7125] are as follows:
[RFC7125]の著者は次のとおりです。
Brian Trammell
Paul Aitken
Mohamed Boucadair
Orange
35000 Rennes
France
Email: mohamed.boucadair@orange.com