Internet Engineering Task Force (IETF) M. Tüxen
Request for Comments: 9653 Münster Univ. of Appl. Sciences
Category: Standards Track V. Boivie
ISSN: 2070-1721 F. Castelli
Google
R. Jesup
Mozilla
September 2024
The Stream Control Transmission Protocol (SCTP) uses a 32-bit checksum in the common header of each packet to provide some level of data integrity. If another method used by SCTP already provides the same or a higher level of data integrity, computing this checksum does not provide any additional protection but does consume computing resources.
Stream Control Transmission Protocol（SCTP）は、各パケットの共通ヘッダーで32ビットチェックサムを使用して、ある程度のデータの整合性を提供します。SCTPが使用する別の方法が既に同じまたはより高いレベルのデータの整合性を提供している場合、このチェックサムを計算すると、追加の保護は提供されませんが、コンピューティングリソースを消費します。
This document provides a simple extension allowing SCTP to save these computing resources by using zero as the checksum in a backwards-compatible way. It also defines how this feature can be used when SCTP packets are encapsulated in Datagram Transport Layer Security (DTLS) packets.
このドキュメントは、SCTPがゼロを後方互換的な方法でゼロを使用してこれらのコンピューティングリソースを保存できるようにする簡単な拡張機能を提供します。また、SCTPパケットがデータグラムトランスポートレイヤーセキュリティ（DTLS）パケットにカプセル化されている場合に、この機能を使用する方法も定義します。
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/rfc9653.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9653で取得できます。
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. Conventions
3. Alternate Error Detection Methods
4. A New Chunk Parameter
5. Procedures
5.1. Declaration of Feature Support
5.2. Sender-Side Considerations
5.3. Receiver-Side Considerations
6. Error Detection via SCTP over DTLS
7. Socket API Considerations
7.1. Set Accepting a Zero Checksum (SCTP_ACCEPT_ZERO_CHECKSUM)
8. IANA Considerations
9. Security Considerations
10. References
10.1. Normative References
10.2. Informative References
Acknowledgments
Authors' Addresses
SCTP as specified in [RFC9260] uses a CRC32c checksum to provide some level of data integrity. When using, for example, Datagram Transport Layer Security (DTLS) as the lower layer for SCTP as specified in [RFC8261], using the CRC32c checksum does not provide any additional protection over that already provided by DTLS. However, computing the CRC32c checksum at the sender and receiver sides does consume computational resources for no benefit. This is particularly important for endpoints that are computationally limited and use SCTP over DTLS.
[RFC9260]で指定されているSCTPは、CRC32Cチェックサムを使用して、ある程度のデータの整合性を提供します。たとえば、[RFC8261]で指定されているSCTPの下層層としてデータグラムトランスポートレイヤーセキュリティ（DTL）を使用する場合、CRC32Cチェックサムを使用しても、DTLSが既に提供しているものよりも追加の保護は提供されません。ただし、送信者とレシーバーの側でCRC32Cチェックサムを計算すると、利益なしに計算リソースが消費されます。これは、計算的に制限され、DTLよりもSCTPを使用するエンドポイントにとって特に重要です。
The extension described in this document allows an SCTP endpoint to declare that it accepts SCTP packets with a checksum of zero when using a specific alternate error detection method. This declaration happens during the setup of the SCTP association and allows endpoints that support this extension to be interoperable with endpoints that don't. To provide this backwards compatibility, endpoints using this extension still need to implement the CRC32c checksum algorithm.
このドキュメントで説明されている拡張機能により、SCTPエンドポイントは、特定の代替エラー検出方法を使用する場合、ゼロのチェックサムを持つSCTPパケットを受け入れることを宣言できます。この宣言は、SCTP協会のセットアップ中に発生し、この拡張機能をサポートするエンドポイントが、そうでないエンドポイントと相互運用可能であることを可能にします。この逆方向の互換性を提供するには、この拡張機能を使用するエンドポイントは、CRC32Cチェックサムアルゴリズムを実装する必要があります。
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.
「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
SCTP uses a CRC32c checksum to provide some level of data integrity. The CRC32c checksum is computed based on the SCTP common header and the chunks contained in the packet. In particular, the computation of the CRC32c checksum does not involve a pseudo header for IPv4 or IPv6 like the computation of the TCP checksum, as specified in [RFC9293], or the UDP checksum, as specified in [RFC0768].
SCTPは、CRC32Cチェックサムを使用して、ある程度のデータの整合性を提供します。CRC32Cチェックサムは、SCTP共通ヘッダーとパケットに含まれるチャンクに基づいて計算されます。特に、CRC32Cチェックサムの計算には、[RFC9293]で指定されているように、[RFC0768]で指定されているように、TCPチェックサムの計算のようにIPv4またはIPv6の擬似ヘッダーは含まれません。
Zero is a valid result of the CRC32c checksum algorithm. For example, the following figure depicts an SCTP packet containing a minimal INIT chunk with a correct CRC32c checksum of zero.
Zeroは、CRC32Cチェックサムアルゴリズムの有効な結果です。たとえば、次の図は、ゼロの正しいCRC32Cチェックサムを備えた最小INITチャンクを含むSCTPパケットを示しています。
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 Number = 5001 |Destination Port Number = 5001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Verification Tag = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 |Chunk Flags = 0| Chunk Length = 20 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initiate Tag = 0xFCB75CCA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertised Receiver Window Credit (a_rwnd) = 1500 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Number of Outbound Streams = 1 | Number of Inbound Streams = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initial TSN = 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: SCTP Packet with a Correct CRC32c Checksum of Zero
図1：ゼロの正しいCRC32Cチェックサムを備えたSCTPパケット
Using SCTP in combination with other mechanisms or protocol extensions might provide data integrity protection with an equal or lower probability of false negatives than the one provided by using the CRC32c checksum algorithm. When using such alternate error detection methods, the SCTP common header containing the 32-bit checksum field might or might not be visible to middleboxes on the paths between the two endpoints.
SCTPを他のメカニズムまたはプロトコル拡張と組み合わせて使用すると、CRC32C Checksumアルゴリズムを使用して提供されたものよりも、誤検知の可能性が等しいまたは低い確率でデータ整合性保護を提供する場合があります。このような代替エラー検出方法を使用する場合、32ビットチェックサムフィールドを含むSCTP共通ヘッダーは、2つのエンドポイント間のパス上のミドルボックスに表示される場合と見えない場合があります。
Alternate error detection methods have two requirements:
代替エラー検出方法には2つの要件があります。
1. An alternate error detection method MUST provide an equal or lower probability of false negatives than the one provided by using the CRC32c checksum algorithm. This MAY only apply to packets satisfying some method-specific constraints.
1. 代替エラー検出方法は、CRC32Cチェックサムアルゴリズムを使用して提供されるものよりも、偽のネガの等または低い確率を提供する必要があります。これは、いくつかの方法固有の制約を満たすパケットにのみ適用される場合があります。
2. Using an alternate error detection method MUST NOT result in a path failure for more than two retransmission timeouts (RTOs) due to middleboxes on the path expecting correct CRC32c checksums.
2. 代替エラー検出方法を使用すると、正しいCRC32Cチェックサムを期待するパス上の中間ボックスのために、2回以上の再送信タイムアウト（RTO）のパス障害をもたらさないはずです。
To fulfill the second requirement, alternate error detection methods could use a heuristic to detect the existence of such middleboxes and use correct CRC32c checksums on these affected paths.
2番目の要件を満たすために、代替エラー検出方法はヒューリスティックを使用して、このような中間ボックスの存在を検出し、これらの影響を受けるパスで正しいCRC32Cチェックサムを使用できます。
Using DTLS as the lower layer of SCTP as specified in [RFC8261] is one example that fulfills the first requirement. Another example is using SCTP Authentication as specified in [RFC4895]. Of course, this only applies to each SCTP packet having an AUTH chunk as its first chunk. However, using SCTP Authentication without any heuristic does not fulfill the second requirement. Since using DTLS as the lower layer of SCTP as specified in [RFC8261] also fulfills the second requirement, it can be used as an alternate error detection method (see Section 6).
[RFC8261]で指定されているSCTPの下層としてDTLを使用することは、最初の要件を満たす1つの例です。別の例は、[RFC4895]で指定されているSCTP認証を使用することです。もちろん、これは各SCTPパケットに最初のチャンクとしてAuth Chunkを持つことにのみ適用されます。ただし、ヒューリスティックなしでSCTP認証を使用しても、2番目の要件は満たされません。[RFC8261]で指定されているSCTPの下層としてDTLを使用することも2番目の要件を満たすため、代替エラー検出方法として使用できます（セクション6を参照）。
If an alternate error detection method is used, the computation of the CRC32c checksum consumes computational resources without providing any benefit. To avoid this, an SCTP endpoint could be willing to accept SCTP packets with an incorrect CRC32c checksum value of zero in addition to SCTP packets with correct CRC32c checksum values.
代替エラー検出方法が使用される場合、CRC32Cチェックサムの計算は、利益を提供することなく計算リソースを消費します。これを回避するために、SCTPエンドポイントは、正しいCRC32Cチェックサム値を持つSCTPパケットに加えて、ゼロの誤ったCRC32Cチェックサム値を持つSCTPパケットを受け入れることをいとわない可能性があります。
Because zero is a valid result of the CRC32c checksum algorithm, a receiver of an SCTP packet containing a checksum value of zero cannot determine whether the sender included an incorrect CRC32c checksum of zero to reduce the CPU cost or the result of the CRC32c checksum computation was actually zero. However, if the receiver is willing to use an alternate error detection method, this ambiguity is irrelevant, since the receiver is fine with not using the CRC32c checksum to protect incoming packets.
ゼロはCRC32Cチェックサムアルゴリズムの有効な結果であるため、ゼロのチェックサム値を含むSCTPパケットの受信者は、送信者がCPUコストを削減するために誤ったCRC32Cチェックサムをゼロの誤ったCRC32Cチェックサムを含めるか、CRC32Cチェックサム計算の結果を削減するかどうかを判断できません。実際にはゼロ。ただし、受信者が代替エラー検出方法を使用する意思がある場合、受信者はCRC32Cチェックサムを使用して着信パケットを保護しないことには問題ありません。
The Zero Checksum Acceptable Chunk Parameter is defined by the following figure.
ゼロチェックサム許容塊パラメーターは、次の図で定義されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x8001 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Detection Method Identifier (EDMID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Zero Checksum Acceptable Chunk Parameter
図2：ゼロチェックサム許容チャンクパラメーター
Type: 16 bits (unsigned integer)
タイプ：16ビット（符号なし整数）
This field holds the IANA-defined parameter type for the "Zero Checksum Acceptable" chunk parameter. IANA has assigned the value 32769 (0x8001) for this parameter type.
このフィールドには、「ゼロチェックサム許容」チャンクパラメーターのIANA定義パラメータータイプが保持されます。IANAは、このパラメータータイプに値32769（0x8001）を割り当てました。
Length: 16 bits (unsigned integer)
長さ：16ビット（符号なし整数）
This field holds the length in bytes of the chunk parameter; the value MUST be 8.
このフィールドは、チャンクパラメーターのバイトの長さを保持します。値は8でなければなりません。
Error Detection Method Identifier (EDMID): 32 bits (unsigned integer)
エラー検出方法識別子（EDMID）：32ビット（符号なし整数）
An IANA-registered value specifying the alternate error detection method the sender of this parameter is willing to use for received packets.
代替エラー検出方法を指定するIANA登録値このパラメーターの送信者は、受信パケットに喜んで使用します。
All transported integer numbers are in network byte order, a.k.a. big endian.
輸送されたすべての整数数は、ネットワークバイトの順序であり、別名Big Endianです。
The Zero Checksum Acceptable Chunk Parameter MAY appear in INIT and INIT ACK chunks and MUST NOT appear in any other chunk. The Parameter MUST NOT appear more than once in any chunk.
ゼロチェックサムの許容塊パラメーターは、initおよびinit ackチャンクに表示され、他のチャンクに表示されてはなりません。パラメーターは、どのチャンクで複数回表示してはなりません。
If an endpoint not supporting the extension described in this document receives this parameter in an INIT or INIT ACK chunk, it is REQUIRED to skip this parameter and continue to process further parameters in the chunk. This behavior is specified by [RFC9260] because the highest-order two bits of the Type are '10'.
このドキュメントで説明されている拡張機能をサポートしていないエンドポイントがこのパラメーターをinitまたはinit ackチャンクで受信する場合、このパラメーターをスキップし、チャンクのさらなるパラメーターを処理し続ける必要があります。この動作は、[RFC9260]で指定されています。これは、タイプの最高級の2ビットが「10」であるためです。
An endpoint willing to accept SCTP packets with an incorrect checksum of zero MUST include the Zero Checksum Acceptable Chunk Parameter indicating the alternate error detection method it is willing to use in the INIT or INIT ACK chunk it sends.
ゼロの誤ったチェックサムを使用してSCTPパケットを受け入れるエンドポイントには、Zero Checksum許容塊パラメーターを含める必要があります。
An SCTP implementation MAY also require the upper layer to indicate that it is fine to use a specific alternate error detection method before including the corresponding Zero Checksum Acceptable Chunk Parameter.
SCTP実装では、対応するゼロチェックサム許容塊パラメーターを含める前に、特定の代替エラー検出方法を使用することが問題であることを示すために上層が必要になる場合があります。
An SCTP endpoint cannot just use an incorrect CRC32c checksum value of zero for all SCTP packets it sends. The following restrictions apply:
SCTPエンドポイントは、送信するすべてのSCTPパケットでゼロの誤ったCRC32Cチェックサム値を使用することはできません。次の制限が適用されます。
1. If an endpoint has not received an INIT or INIT ACK chunk containing a Zero Checksum Acceptable Chunk Parameter indicating an alternate error detection method it supports from its peer during the association setup, it MUST use a correct CRC32c checksum. In particular, when an endpoint
1. エンドポイントが、協会のセットアップ中にピアからサポートする代替エラー検出方法を示すゼロチェックサムの許容塊パラメーターを含むinitまたはinit ackチャンクを受信していない場合、正しいCRC32Cチェックサムを使用する必要があります。特に、エンドポイントの場合
a. sends a packet containing an INIT chunk, it MUST include a correct CRC32c checksum in the packet containing the INIT chunk.
a. init chunkを含むパケットを送信すると、initチャンクを含むパケットに正しいCRC32Cチェックサムを含める必要があります。
b. responds to an "Out of the Blue" (OOTB) SCTP packet, it MUST include a correct CRC32c checksum in the response packet.
b. 「Out of the Blue」（OOTB）SCTPパケットに応答すると、応答パケットに正しいCRC32Cチェックサムを含める必要があります。
2. When an endpoint sends a packet containing a COOKIE ECHO chunk, it MUST include a correct CRC32c checksum in the packet containing the COOKIE ECHO chunk.
2. エンドポイントがCookie Echo Chunkを含むパケットを送信する場合、Cookie Echo Chunkを含むパケットに正しいCRC32Cチェックサムを含める必要があります。
3. When an endpoint supports the dynamic address reconfiguration specified in [RFC5061] and sends a packet containing an ASCONF chunk, it MUST include a correct CRC32c checksum in the packet containing the ASCONF chunk.
3. エンドポイントが[RFC5061]で指定された動的アドレス再構成をサポートし、ASCONFチャンクを含むパケットを送信する場合、AsConfチャンクを含むパケットに正しいCRC32Cチェックサムを含める必要があります。
4. If an alternate error detection method has some method-specific constraints, the sender MUST include a correct CRC32c checksum in all packets that don't fulfill these method-specific constraints.
4. 代替エラー検出方法にメソッド固有の制約がある場合、送信者は、これらのメソッド固有の制約を満たさないすべてのパケットに正しいCRC32Cチェックサムを含める必要があります。
The first restriction allows backwards compatibility. The second and third restrictions allow a simpler implementation of the extension defined in this document, because looking up the association for SCTP packets containing a COOKIE ECHO chunk or an ASCONF chunk might be more complex than for other packets. Finally, the last restriction covers constraints specific to the alternate error detection method.
最初の制限により、逆方向の互換性が可能になります。2番目と3番目の制限により、Cookie Echo ChunkまたはAsConfチャンクを含むSCTPパケットの関連付けを検索することは、他のパケットよりも複雑になる可能性があるため、このドキュメントで定義されている拡張機能のより簡単な実装を可能にします。最後に、最後の制限は、代替エラー検出方法に固有の制約をカバーします。
An SCTP endpoint MAY require that the upper layer allow the use of the alternate error detection method that was announced by the peer before sending packets with an incorrect checksum of zero.
SCTPエンドポイントでは、上層がゼロの誤ったチェックサムでパケットを送信する前にピアによって発表された代替エラー検出方法の使用を許可する必要があります。
If none of the above restrictions apply, an endpoint SHOULD use zero as the checksum when sending an SCTP packet.
上記の制限のいずれも適用されない場合、エンドポイントはSCTPパケットを送信するときにチェックサムとしてゼロを使用する必要があります。
If an endpoint has sent the Zero Checksum Acceptable Chunk Parameter indicating the support of an alternate error detection method in an INIT or INIT ACK chunk, in addition to SCTP packets containing the correct CRC32c checksum value it MUST accept SCTP packets that have an incorrect checksum value of zero and that fulfill the requirements of the announced alternate error detection method used for this association. Otherwise, the endpoint MUST drop all SCTP packets with an incorrect CRC32c checksum.
エンドポイントが、正しいCRC32Cチェックサム値を含むSCTPパケットに加えて、initまたはinit ackチャンクでの代替エラー検出方法のサポートを示すゼロチェックサムの許容塊パラメーターを送信した場合、誤ったチェックサム値を持つSCTPパケットを受け入れる必要がありますゼロで、この関連付けに使用される発表された代替エラー検出方法の要件を満たしています。それ以外の場合、エンドポイントは、誤ったCRC32CチェックサムですべてのSCTPパケットをドロップする必要があります。
In addition to processing OOTB packets with a correct CRC32c checksum as specified in [RFC9260], an SCTP implementation MAY also process OOTB packets having an incorrect zero checksum. Doing so might result in faster SCTP association failure detection.
[RFC9260]で指定されている正しいCRC32Cチェックサムを使用してOOTBパケットを処理することに加えて、SCTP実装は、誤ったゼロチェックサムを持つOOTBパケットを処理する場合もあります。そうすることで、SCTP関連の障害検出が速くなる可能性があります。
Using SCTP over DTLS as specified in [RFC8261] provides a stronger error detection method than using the CRC32c checksum algorithm. Since middleboxes will not observe the unencrypted SCTP packet, there is no risk in interfering with using zero as an incorrect checksum. There are no additional constraints (specific to the error detection method) on packets when using DTLS encapsulation.
[RFC8261]で指定されているようにDTLを介してSCTPを使用すると、CRC32Cチェックサムアルゴリズムを使用するよりも強力なエラー検出方法が提供されます。ミドルボックスは暗号化されていないSCTPパケットを観察しないため、誤ったチェックサムとしてゼロを使用することに干渉するリスクはありません。DTLSカプセル化を使用する場合、パケットに追加の制約（エラー検出方法に固有）はありません。
This section describes how the socket API defined in [RFC6458] needs to be extended to provide a way for the application to control the acceptance of a zero checksum.
このセクションでは、[RFC6458]で定義されているソケットAPIを拡張して、アプリケーションがゼロチェックサムの受け入れを制御する方法を提供する方法について説明します。
A 'Socket API Considerations' section is contained in all SCTP-related specifications published after [RFC6458] describing an extension for which implementations using the socket API as specified in [RFC6458] would require some extension of the socket API. Please note that this section is informational only.
「ソケットAPI考慮事項」セクションは、[RFC6458]で指定されているソケットAPIを使用してソケットAPIを使用してソケットAPIの拡張機能を必要とする拡張機能を説明する[RFC6458]の後に公開されたすべてのSCTP関連仕様に含まれています。このセクションは情報のみであることに注意してください。
A socket API implementation based on [RFC6458] is extended by supporting one new write-only IPPROTO_SCTP-level socket option.
[RFC6458]に基づくソケットAPI実装は、1つの新しい書き込み専用IPPROTO_SCTPレベルソケットオプションをサポートすることにより拡張されます。
This IPPROTO_SCTP-level socket option with the name SCTP_ACCEPT_ZERO_CHECKSUM can be used to control the acceptance of a zero checksum. It is a write-only socket option and applies only to future SCTP associations on the socket.
sctp_accept_zero_checksumという名前のこのipproto_sctp-levelソケットオプションを使用して、ゼロチェックサムの受け入れを制御できます。これは、書き込みのみのソケットオプションであり、ソケット上の将来のSCTP関連にのみ適用されます。
This option expects an unsigned integer. Possible values include:
このオプションは、署名されていない整数が期待されます。考えられる値は次のとおりです。
SCTP_EDMID_NONE:
sctp_edmid_none：
Disable the use of any alternate error detection method. This means that all SCTP packets being received are only accepted if they have a correct CRC32c checksum value.
代替エラー検出方法の使用を無効にします。これは、受信中のすべてのSCTPパケットが正しいCRC32Cチェックサム値を持っている場合にのみ受け入れられることを意味します。
SCTP_EDMID_LOWER_LAYER_DTLS:
sctp_edmid_lower_layer_dtls：
Use the alternate error detection method described in Section 6.
セクション6で説明した代替エラー検出方法を使用します。
An implementation might only send packets with an incorrect checksum of zero, if the alternate error detection method announced by the peer is also enabled locally via this socket option.
実装は、ピアによって発表された代替エラー検出方法もこのソケットオプションを介してローカルに有効になっている場合、ゼロの誤ったチェックサムを持つパケットのみを送信する場合があります。
The default for this socket option is that the use of alternate error detection methods is disabled.
このソケットオプションのデフォルトは、代替エラー検出方法の使用が無効になっていることです。
A new chunk parameter type has been assigned by IANA in the "Chunk Parameter Types" registry for SCTP:
SCTPの「チャンクパラメータータイプ」レジストリでIANAによって新しいチャンクパラメータータイプが割り当てられています。
+==========+===================================+===========+
| ID Value | Chunk Parameter Type | Reference |
+==========+===================================+===========+
| 32769 | Zero Checksum Acceptable (0x8001) | RFC 9653 |
+----------+-----------------------------------+-----------+
Table 1: New Entry in "Chunk Parameter Types" Registry
表1：「チャンクパラメータータイプ」レジストリの新しいエントリ
Furthermore, IANA has established a new "Error Detection Method" registry for SCTP. The assignment of new error detection methods is done through the Specification Required policy as defined in [RFC8126]. Documentation for a new error detection method MUST contain the following information:
さらに、IANAは、SCTPの新しい「エラー検出方法」レジストリを確立しました。[RFC8126]で定義されているように、新しいエラー検出方法の割り当ては、必要なポリシーを使用して行われます。新しいエラー検出方法のドキュメントには、次の情報が含まれている必要があります。
1. A name of an alternate error detection method.
1. 代替エラー検出方法の名前。
2. A reference to a specification describing:
2. 説明する仕様への参照：
(a) the alternate error detection method,
(a) 代替エラー検出方法、
(b) why the alternate error detection method provides an equal or lower probability of false negatives than the one provided by using the CRC32c checksum,
(b) 代替エラー検出方法が、CRC32Cチェックサムを使用して提供されるものよりも誤検知の等または低い確率を提供する理由
(c) any constraints (specific to the alternate error detection method) that are referred to in the fourth exception in Section 5.2, and
(c) セクション5.2の4番目の例外で言及されている制約（代替エラー検出方法に固有）と
(d) why using the alternate error detection method does not result in path failures due to middleboxes expecting correct CRC32c checksums for more than two RTOs. In case the alternate error detection method uses a heuristic for detecting such middleboxes, this heuristic needs to be described.
(d) 代替エラー検出方法を使用しても、2つ以上のRTOの正しいCRC32Cチェックサムを期待するミドルボックスのため、パス障害が発生しない理由。代替エラー検出方法がそのようなミドルボックスを検出するためにヒューリスティックを使用している場合、このヒューリスティックを説明する必要があります。
The initial contents of the registry are as follows:
レジストリの最初の内容は次のとおりです。
+================+========================+===========+
| ID Value | Error Detection Method | Reference |
+================+========================+===========+
| 0 | Reserved | RFC 9653 |
+----------------+------------------------+-----------+
| 1 | SCTP over DTLS | RFC 9653 |
+----------------+------------------------+-----------+
| 2 - 4294967295 | Unassigned | |
+----------------+------------------------+-----------+
Table 2: Initial Contents of the "Error Detection Method" Registry
表2：「エラー検出方法」レジストリの初期内容
A designated expert (DE) is expected to ascertain the existence of suitable documentation (a specification) as described in [RFC8126] and to verify that the document is permanently and publicly available. Furthermore, the DE is expected to ensure that the above four points have been addressed appropriately.
指定された専門家（DE）は、[RFC8126]に記載されている適切なドキュメント（仕様）の存在を確認し、ドキュメントが永続的かつ公開されていることを確認することが期待されます。さらに、DEは、上記の4つのポイントが適切に対処されていることを確認することが期待されています。
This document does not change the considerations given in [RFC9260].
この文書は、[RFC9260]で与えられた考慮事項を変更しません。
Due to the first requirement in Section 3, using an alternate error detection method provides an equal or better level of data integrity than the one provided by using the CRC32c checksum algorithm. The second requirement in Section 3 ensures that the existence of middleboxes expecting correct CRC32c checksums does not result in permanent path failures.
セクション3の最初の要件により、代替エラー検出方法を使用すると、CRC32Cチェックサムアルゴリズムを使用して提供されたものよりも等しいまたはより良いレベルのデータ整合性が提供されます。セクション3の2番目の要件は、正しいCRC32Cチェックサムを期待するミドルボックスの存在が永続的なパス障害をもたらさないことを保証します。
[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>.
[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M.
Kozuka, "Stream Control Transmission Protocol (SCTP)
Dynamic Address Reconfiguration", RFC 5061,
DOI 10.17487/RFC5061, September 2007,
<https://www.rfc-editor.org/info/rfc5061>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[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>.
[RFC8261] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto,
"Datagram Transport Layer Security (DTLS) Encapsulation of
SCTP Packets", RFC 8261, DOI 10.17487/RFC8261, November
2017, <https://www.rfc-editor.org/info/rfc8261>.
[RFC9260] Stewart, R., Tüxen, M., and K. Nielsen, "Stream Control
Transmission Protocol", RFC 9260, DOI 10.17487/RFC9260,
June 2022, <https://www.rfc-editor.org/info/rfc9260>.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980,
<https://www.rfc-editor.org/info/rfc768>.
[RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla,
"Authenticated Chunks for the Stream Control Transmission
Protocol (SCTP)", RFC 4895, DOI 10.17487/RFC4895, August
2007, <https://www.rfc-editor.org/info/rfc4895>.
[RFC6458] Stewart, R., Tuexen, M., Poon, K., Lei, P., and V.
Yasevich, "Sockets API Extensions for the Stream Control
Transmission Protocol (SCTP)", RFC 6458,
DOI 10.17487/RFC6458, December 2011,
<https://www.rfc-editor.org/info/rfc6458>.
[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>.
The authors wish to thank Bernard Aboba, Deb Cooley, Martin Duke, Gorry Fairhurst, Mike Heard, Peter Lei, Nils Ohlmeier, Claudio Porfiri, Greg Skinner, Timo Völker, Éric Vyncke, and Magnus Westerlund for their invaluable comments.
著者は、バーナード・アボバ、デブ・クーリー、マーティン・デューク、ゴーリー・フェアハースト、マイク・ハード、ピーター・レイ、ニルズ・オールマイヤー、クラウディオ・ポルフィリ、グレッグ・スキナー、ティモ・ヴェルカー、エリック・ヴィンケ、マグナス・ウェスターランドに感謝します。
Michael Tüxen
Münster University of Applied Sciences
Stegerwaldstrasse 39
48565 Steinfurt
Germany
Email: tuexen@fh-muenster.de
Victor Boivie
Google
Kungsbron 2
SE-11122 Stockholm
Sweden
Email: boivie@google.com
Florent Castelli
Google
Kungsbron 2
SE-11122 Stockholm
Sweden
Email: orphis@google.com
Randell Jesup
Mozilla Corporation
1835 Horse Shoe Trl
Malvern, PA 19355
United States of America
Email: randell-ietf@jesup.org