[要約] 要約：RFC 8540は、RFC 4960での誤りと問題を修正するために作成されたものであり、Stream Control Transmission Protocol（SCTP）に関する情報を提供しています。 目的：RFC 8540の目的は、SCTPの実装や使用に関連する問題を解決し、より信頼性の高い通信プロトコルを提供することです。
Internet Engineering Task Force (IETF) R. Stewart
Request for Comments: 8540 Netflix, Inc.
Category: Informational M. Tuexen
ISSN: 2070-1721 Muenster Univ. of Appl. Sciences
M. Proshin
Ericsson
February 2019
Stream Control Transmission Protocol: Errata and Issues in RFC 4960
ストリーム制御伝送プロトコル：RFC 4960のエラッタと問題
Abstract
概要
This document is a compilation of issues found since the publication of RFC 4960 in September 2007, based on experience with implementing, testing, and using the Stream Control Transmission Protocol (SCTP) along with the suggested fixes. This document provides deltas to RFC 4960 and is organized in a time-ordered way. The issues are listed in the order in which they were brought up. Because some text is changed several times, the last delta in the text is the one that should be applied. In addition to the deltas, a description of each problem and the details of the solution for each are also provided.
このドキュメントは、2007年9月のRFC 4960の発行以降に発見された問題をまとめたものであり、推奨される修正とともに、ストリーム制御伝送プロトコル（SCTP）の実装、テスト、および使用の経験に基づいています。このドキュメントは、RFC 4960の差分を提供し、時間順に整理されています。問題は、取り上げられた順にリストされています。一部のテキストは複数回変更されるため、テキストの最後のデルタが適用される必要があります。デルタに加えて、各問題の説明とそれぞれの解決策の詳細も提供されます。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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/rfc8540.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8540で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Corrections to RFC 4960 . . . . . . . . . . . . . . . . . . . 4
3.1. Path Error Counter Threshold Handling . . . . . . . . . . 4
3.2. Upper-Layer Protocol Shutdown Request Handling . . . . . 5
3.3. Registration of New Chunk Types . . . . . . . . . . . . . 6
3.4. Variable Parameters for INIT Chunks . . . . . . . . . . . 7
3.5. CRC32c Sample Code on 64-Bit Platforms . . . . . . . . . 8
3.6. Endpoint Failure Detection . . . . . . . . . . . . . . . 9
3.7. Data Transmission Rules . . . . . . . . . . . . . . . . . 10
3.8. T1-Cookie Timer . . . . . . . . . . . . . . . . . . . . . 11
3.9. Miscellaneous Typos . . . . . . . . . . . . . . . . . . . 12
3.10. CRC32c Sample Code . . . . . . . . . . . . . . . . . . . 19
3.11. partial_bytes_acked after T3-rtx Expiration . . . . . . . 19
3.12. Order of Adjustments of partial_bytes_acked and cwnd . . 20
3.13. HEARTBEAT ACK and the Association Error Counter . . . . . 21
3.14. Path for Fast Retransmission . . . . . . . . . . . . . . 22
3.15. Transmittal in Fast Recovery . . . . . . . . . . . . . . 23
3.16. Initial Value of ssthresh . . . . . . . . . . . . . . . . 24
3.17. Automatically CONFIRMED Addresses . . . . . . . . . . . . 25
3.18. Only One Packet after Retransmission Timeout . . . . . . 26
3.19. INIT ACK Path for INIT in COOKIE-WAIT State . . . . . . . 27
3.20. Zero Window Probing and Unreachable Primary Path . . . . 28
3.21. Normative Language in Section 10 of RFC 4960 . . . . . . 29
3.22. Increase of partial_bytes_acked in Congestion Avoidance . 32
3.23. Inconsistent Handling of Notifications . . . . . . . . . 33
3.24. SACK.Delay Not Listed as a Protocol Parameter . . . . . . 37
3.25. Processing of Chunks in an Incoming SCTP Packet . . . . . 39
3.26. Increasing the cwnd in the Congestion Avoidance Phase . . 41
3.27. Refresh of cwnd and ssthresh after Idle Period . . . . . 43
3.28. Window Updates after Receiver Window Opens Up . . . . . . 45
3.29. Path of DATA and Reply Chunks . . . . . . . . . . . . . . 46
3.30. "Outstanding Data", "Flightsize", and "Data in Flight"
Key Terms . . . . . . . . . . . . . . . . . . . . . . . . 47
3.31. Degradation of cwnd due to Max.Burst . . . . . . . . . . 49
3.32. Reduction of RTO.Initial . . . . . . . . . . . . . . . . 50
3.33. Ordering of Bundled SACK and ERROR Chunks . . . . . . . . 51
3.34. Undefined Parameter Returned by RECEIVE Primitive . . . . 52
3.35. DSCP Changes . . . . . . . . . . . . . . . . . . . . . . 53
3.36. Inconsistent Handling of ICMPv4 and ICMPv6 Messages . . . 55
3.37. Handling of Soft Errors . . . . . . . . . . . . . . . . . 56
3.38. Honoring cwnd . . . . . . . . . . . . . . . . . . . . . . 57
3.39. Zero Window Probing . . . . . . . . . . . . . . . . . . . 58
3.40. Updating References regarding ECN . . . . . . . . . . . . 60
3.41. Host Name Address Parameter Deprecated . . . . . . . . . 62
3.42. Conflicting Text regarding the 'Supported Address Types'
Parameter . . . . . . . . . . . . . . . . . . . . . . . . 66
3.43. Integration of RFC 6096 . . . . . . . . . . . . . . . . . 67
3.44. Integration of RFC 6335 . . . . . . . . . . . . . . . . . 70
3.45. Integration of RFC 7053 . . . . . . . . . . . . . . . . . 72
3.46. CRC32c Code Improvements . . . . . . . . . . . . . . . . 76
3.47. Clarification of Gap Ack Blocks in SACK Chunks . . . . . 87
3.48. Handling of SSN Wraparounds . . . . . . . . . . . . . . . 89
3.49. Update to RFC 2119 Boilerplate Text . . . . . . . . . . . 90
3.50. Removal of Text (Previously Missed in RFC 4960) . . . . . 91
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 91
5. Security Considerations . . . . . . . . . . . . . . . . . . . 92
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 92
6.1. Normative References . . . . . . . . . . . . . . . . . . 92
6.2. Informative References . . . . . . . . . . . . . . . . . 92
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 94
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 94
This document contains a compilation of all defects for [RFC4960] ("Stream Control Transmission Protocol") that were found up until the publication of this document. These defects may be of an editorial or technical nature. This document may be thought of as a companion document to be used in the implementation of the Stream Control Transmission Protocol (SCTP) to clarify errors in the original SCTP document.
このドキュメントには、このドキュメントが公開されるまでに発見された[RFC4960]（ "Stream Control Transmission Protocol"）のすべての不具合の編集が含まれています。これらの欠陥は、編集上または技術上の性質を持つ可能性があります。このドキュメントは、元のSCTPドキュメントのエラーを明確にするために、ストリーム制御伝送プロトコル（SCTP）の実装で使用される関連ドキュメントと考えることができます。
This document provides a history of the changes that will be compiled into a bis document for [RFC4960]. It is structured similarly to [RFC4460].
このドキュメントは、[RFC4960]のbisドキュメントにコンパイルされる変更の履歴を提供します。 [RFC4460]と同様の構造です。
Each error will be detailed within this document in the form of:
各エラーは、このドキュメント内で次の形式で詳しく説明されます。
o The problem description,
o 問題の説明、
o The text quoted from [RFC4960],
o [RFC4960]から引用されたテキスト、
o The replacement text that should be placed into an upcoming bis document, and
o 今後のbisドキュメントに配置する必要がある置換テキスト、および
o A description of the solution.
o ソリューションの説明。
Note that when reading this document one must use care to ensure that a field or item is not updated later on within the document. Since this document is a historical record of the sequential changes that have been found necessary at various interop events and through discussion on the Transport Area Working Group mailing list, the last delta in the text is the one that should be applied.
このドキュメントを読むときは、フィールドまたはアイテムがドキュメント内で後で更新されないように注意する必要があることに注意してください。このドキュメントは、さまざまな相互運用イベントで必要なことが判明し、トランスポートエリアワーキンググループのメーリングリストでの議論を通じて見つかった一連の変更の履歴レコードであるため、テキストの最後のデルタを適用する必要があります。
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]で説明されているように解釈されます。
The handling of the 'Path.Max.Retrans' parameter is described in Sections 8.2 and 8.3 of [RFC4960] in an inconsistent way. Whereas Section 8.2 of [RFC4960] says that a path is marked inactive when the path error counter exceeds the threshold, Section 8.3 of [RFC4960] says that the path is marked inactive when the path error counter reaches the threshold.
'Path.Max.Retrans'パラメータの処理は、[RFC4960]のセクション8.2および8.3で一貫性のない方法で説明されています。 [RFC4960]のセクション8.2は、パスエラーカウンターがしきい値を超えるとパスが非アクティブとしてマークされると述べていますが、[RFC4960]のセクション8.3は、パスエラーカウンターがしきい値に達するとパスが非アクティブとしてマークされると述べています。
This issue was reported as an errata for [RFC4960] with Errata ID 1440.
この問題は、エラータID 1440の[RFC4960]のエラータとして報告されました。
---------
Old text: (Section 8.3)
---------
When the value of this counter reaches the protocol parameter 'Path.Max.Retrans', the endpoint should mark the corresponding destination address as inactive if it is not so marked, and may also optionally report to the upper layer the change of reachability of this destination address. After this, the endpoint should continue HEARTBEAT on this destination address but should stop increasing the counter.
このカウンターの値がプロトコルパラメーター 'Path.Max.Retrans'に到達すると、エンドポイントは、対応する宛先アドレスが非アクティブである場合は非アクティブとしてマークする必要があり、オプションで、この到達可能性の変更を上位層に報告することもできます。宛先アドレス。この後、エンドポイントはこの宛先アドレスでHEARTBEATを続行する必要がありますが、カウンターの増加を停止する必要があります。
---------
New text: (Section 8.3)
---------
When the value of this counter exceeds the protocol parameter 'Path.Max.Retrans', the endpoint SHOULD mark the corresponding destination address as inactive if it is not so marked and MAY also optionally report to the upper layer the change in reachability of this destination address. After this, the endpoint SHOULD continue HEARTBEAT on this destination address but SHOULD stop increasing the counter.
このカウンターの値がプロトコルパラメーター 'Path.Max.Retrans'を超える場合、エンドポイントは、対応する宛先アドレスにマークが付けられていない場合は、非アクティブとしてマークする必要があり（SHOULD）、オプションで、この宛先の到達可能性の変化を上位層に報告することもできます（MAY）。住所。この後、エンドポイントはこの宛先アドレスでハートビートを続行する必要がありますが、カウンターの増加を停止する必要があります（SHOULD）。
This text has been modified by multiple errata. It is further updated in Section 3.23.
このテキストは、複数のエラッタによって変更されています。セクション3.23でさらに更新されます。
The intended state change should happen when the threshold is exceeded.
しきい値を超えると、意図した状態変化が発生します。
Section 9.2 of [RFC4960] describes the handling of received SHUTDOWN chunks in the SHUTDOWN-RECEIVED state instead of the handling of shutdown requests from its upper layer in this state.
[RFC4960]のセクション9.2は、この状態での上位層からのシャットダウン要求の処理ではなく、SHUTDOWN-RECEIVED状態で受信したSHUTDOWNチャンクの処理について説明しています。
This issue was reported as an errata for [RFC4960] with Errata ID 1574.
この問題は、エラータID 1574の[RFC4960]のエラータとして報告されました。
---------
Old text: (Section 9.2)
---------
Once an endpoint has reached the SHUTDOWN-RECEIVED state, it MUST NOT send a SHUTDOWN in response to a ULP request, and should discard subsequent SHUTDOWN chunks.
エンドポイントがSHUTDOWN-RECEIVED状態に到達すると、ULP要求に応答してSHUTDOWNを送信してはならず（MUST NOT）、後続のSHUTDOWNチャンクを破棄する必要があります。
---------
New text: (Section 9.2)
---------
Once an endpoint has reached the SHUTDOWN-RECEIVED state, it MUST ignore ULP shutdown requests but MUST continue responding to SHUTDOWN chunks from its peer.
エンドポイントがSHUTDOWN-RECEIVED状態に到達すると、ULPシャットダウン要求を無視する必要がありますが、ピアからのSHUTDOWNチャンクへの応答を継続する必要があります。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
The text never intended that the SCTP endpoint ignore SHUTDOWN chunks from its peer. If it did, the endpoints could never gracefully terminate associations in some cases.
SCTPエンドポイントがピアからのSHUTDOWNチャンクを無視することをテキストは意図していません。そうした場合、エンドポイントが関連付けを正常に終了できない場合があります。
Section 14.1 of [RFC4960] should deal with new chunk types; however, the text only refers to parameter types.
[RFC4960]のセクション14.1では、新しいチャンクタイプを扱う必要があります。ただし、テキストはパラメータタイプのみを参照しています。
This issue was reported as an errata for [RFC4960] with Errata ID 2592.
この問題は、エラータID 2592の[RFC4960]のエラータとして報告されました。
---------
Old text: (Section 14.1)
---------
The assignment of new chunk parameter type codes is done through an IETF Consensus action, as defined in [RFC2434]. Documentation of the chunk parameter MUST contain the following information:
新しいチャンクパラメータタイプコードの割り当ては、[RFC2434]で定義されているように、IETFコンセンサスアクションを通じて行われます。チャンクパラメータのドキュメントには、次の情報を含める必要があります。
---------
New text: (Section 14.1)
---------
The assignment of new chunk type codes is done through an IETF Consensus action, as defined in [RFC8126]. Documentation for the chunk type MUST contain the following information:
新しいチャンクタイプコードの割り当ては、[RFC8126]で定義されているように、IETFコンセンサスアクションを通じて行われます。チャンクタイプのドキュメントには、次の情報を含める必要があります。
This text has been modified by multiple errata. It is further updated in Section 3.43.
このテキストは、複数のエラッタによって変更されています。セクション3.43でさらに更新されます。
The new text refers to chunk types as intended and changes the reference to [RFC8126].
新しいテキストは、意図したようにチャンクタイプを参照し、[RFC8126]への参照を変更します。
In Section 3.3.2 of [RFC4960], newlines in wrong places break the layout of the table of variable parameters for the INIT chunk.
[RFC4960]のセクション3.3.2で、間違った場所の改行は、INITチャンクの変数パラメーターのテーブルのレイアウトを壊します。
This issue was reported as an errata for [RFC4960] with Errata ID 3291 and Errata ID 3804.
この問題は、エラータID 3291およびエラータID 3804の[RFC4960]のエラッタとして報告されました。
---------
Old text: (Section 3.3.2)
---------
Variable Parameters Status Type Value
-------------------------------------------------------------
IPv4 Address (Note 1) Optional 5 IPv6 Address
(Note 1) Optional 6 Cookie Preservative
Optional 9 Reserved for ECN Capable (Note 2) Optional
32768 (0x8000) Host Name Address (Note 3) Optional
11 Supported Address Types (Note 4) Optional 12
---------
New text: (Section 3.3.2)
---------
Variable Parameters Status Type Value
-------------------------------------------------------------
IPv4 Address (Note 1) Optional 5
IPv6 Address (Note 1) Optional 6
Cookie Preservative Optional 9
Reserved for ECN Capable (Note 2) Optional 32768 (0x8000)
Host Name Address (Note 3) Optional 11
Supported Address Types (Note 4) Optional 12
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
The formatting of the table is corrected.
テーブルのフォーマットが修正されました。
The sample code for CRC32c computation, as provided in [RFC4960], assumes that a variable of type unsigned long uses 32 bits. This is not true on some 64-bit platforms (for example, platforms that use LP64).
[RFC4960]で提供されるCRC32c計算のサンプルコードは、unsigned long型の変数が32ビットを使用することを前提としています。これは、一部の64ビットプラットフォーム（たとえば、LP64を使用するプラットフォーム）では当てはまりません。
This issue was reported as an errata for [RFC4960] with Errata ID 3423.
この問題は、エラータID 3423の[RFC4960]のエラータとして報告されました。
---------
Old text: (Appendix C)
---------
unsigned long
generate_crc32c(unsigned char *buffer, unsigned int length)
{
unsigned int i;
unsigned long crc32 = ~0L;
---------
New text: (Appendix C)
---------
unsigned long
generate_crc32c(unsigned char *buffer, unsigned int length)
{
unsigned int i;
unsigned long crc32 = 0xffffffffL;
This text has been modified by multiple errata. It is further updated in Section 3.10 and again in Section 3.46.
このテキストは、複数のエラッタによって変更されています。セクション3.10でさらに更新され、セクション3.46でも再度更新されます。
The new text uses 0xffffffffL instead of ~0L; this gives the same value on platforms using 32 bits or 64 bits for variables of type unsigned long.
新しいテキストは〜0Lではなく0xffffffffLを使用します。これにより、unsigned long型の変数に32ビットまたは64ビットを使用するプラットフォームで同じ値が得られます。
The handling of the association error counter defined in Section 8.1 of [RFC4960] can result in an association failure even if the path used for data transmission is available (but idle).
[RFC4960]のセクション8.1で定義されたアソシエーションエラーカウンターの処理は、データ送信に使用されるパスが使用可能（ただしアイドル）であっても、アソシエーションエラーを引き起こす可能性があります。
This issue was reported as an errata for [RFC4960] with Errata ID 3788.
この問題は、エラータID 3788の[RFC4960]のエラータとして報告されました。
---------
Old text: (Section 8.1)
---------
An endpoint shall keep a counter on the total number of consecutive retransmissions to its peer (this includes retransmissions to all the destination transport addresses of the peer if it is multi-homed), including unacknowledged HEARTBEAT chunks.
エンドポイントは、未確認のHEARTBEATチャンクを含む、ピアへの連続した再送信の総数（マルチホームの場合、ピアのすべての宛先トランスポートアドレスへの再送信を含む）のカウンターを保持します。
---------
New text: (Section 8.1)
---------
An endpoint SHOULD keep a counter on the total number of consecutive retransmissions to its peer (this includes data retransmissions to all the destination transport addresses of the peer if it is multi-homed), including the number of unacknowledged HEARTBEAT chunks observed on the path that is currently used for data transfer. Unacknowledged HEARTBEAT chunks observed on paths different from the path currently used for data transfer SHOULD NOT increment the association error counter, as this could lead to association closure even if the path that is currently used for data transfer is available (but idle).
エンドポイントは、そのピアへの連続する再送信の総数（マルチホームの場合、ピアのすべての宛先トランスポートアドレスへのデータ再送信を含む）のカウンターを保持する必要があります（SHOULDは、そのパスで観察された未確認のHEARTBEATチャンクの数を含む）。現在、データ転送に使用されています。現在データ転送に使用されているパスとは異なるパスで観察される未確認のHEARTBEATチャンクは、現在データ転送に使用されているパスが使用可能（アイドル）であっても、アソシエーションエラーカウンターをインクリメントしないでください（SHOULD NOT）。
This text has been modified by multiple errata. It is further updated in Section 3.23.
このテキストは、複数のエラッタによって変更されています。セクション3.23でさらに更新されます。
A more refined handling of the association error counter is defined.
アソシエーションエラーカウンタのより洗練された処理が定義されています。
When integrating the changes to Section 6.1 A) of [RFC2960] as described in Section 2.15.2 of [RFC4460], some text was duplicated and became the final paragraph of Section 6.1 A) of [RFC4960].
[RFC4460]のセクション2.15.2の説明に従って[RFC2960]のセクション6.1 A）への変更を統合すると、一部のテキストが複製され、[RFC4960]のセクション6.1 A）の最後の段落になります。
This issue was reported as an errata for [RFC4960] with Errata ID 4071.
この問題は、エラータID 4071の[RFC4960]のエラータとして報告されました。
---------
Old text: (Section 6.1 A))
---------
The sender MUST also have an algorithm for sending new DATA chunks to avoid silly window syndrome (SWS) as described in [RFC0813]. The algorithm can be similar to the one described in Section 4.2.3.4 of [RFC1122].
[RFC0813]で説明されているように、送信者は新しいDATAチャンクを送信して愚かなウィンドウシンドローム（SWS）を回避するアルゴリズムも持っている必要があります。アルゴリズムは、[RFC1122]のセクション4.2.3.4で説明されているものと同様にすることができます。
However, regardless of the value of rwnd (including if it is 0), the data sender can always have one DATA chunk in flight to the receiver if allowed by cwnd (see rule B below). This rule allows the sender to probe for a change in rwnd that the sender missed due to the SACK having been lost in transit from the data receiver to the data sender.
ただし、rwndの値（0の場合も含む）に関係なく、cwndで許可されていれば、データ送信者は常に1つのDATAチャンクを受信者に送信できます（以下のルールBを参照）。このルールにより、送信者は、データ受信者からデータ送信者への転送中にSACKが失われたために送信者が見逃したrwndの変更をプローブできます。
---------
New text: (Section 6.1 A))
---------
The sender MUST also have an algorithm for sending new DATA chunks to avoid silly window syndrome (SWS) as described in [RFC1122]. The algorithm can be similar to the algorithm described in Section 4.2.3.4 of [RFC1122].
送信者はまた、[RFC1122]で説明されているような愚かなウィンドウシンドローム（SWS）を回避するために、新しいDATAチャンクを送信するためのアルゴリズムを持っている必要があります。このアルゴリズムは、[RFC1122]のセクション4.2.3.4で説明されているアルゴリズムと同様にすることができます。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
The last paragraph of Section 6.1 A) is removed, as had been intended in Section 2.15.2 of [RFC4460].
[RFC4460]のセクション2.15.2で意図されていた、セクション6.1 A）の最後の段落が削除されました。
Figure 4 of [RFC4960] illustrates the SCTP association setup. However, it incorrectly shows that the T1-init timer is used in the COOKIE-ECHOED state, whereas the T1-cookie timer should have been used instead.
[RFC4960]の図4は、SCTPアソシエーションのセットアップを示しています。ただし、誤ってT1-initタイマーがCOOKIE-ECHOED状態で使用されているのに対し、代わりにT1-cookieタイマーが使用されているはずです。
This issue was reported as an errata for [RFC4960] with Errata ID 4400.
この問題は、エラータID 4400の[RFC4960]のエラータとして報告されました。
---------
Old text: (Section 5.1.6, Figure 4)
---------
COOKIE ECHO [Cookie_Z] ------\
(Start T1-init timer) \
(Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED
state)
/---- COOKIE-ACK
/
(Cancel T1-init timer, <-----/
Enter ESTABLISHED state)
---------
New text: (Section 5.1.6, Figure 4)
---------
COOKIE ECHO [Cookie_Z] ------\
(Start T1-cookie timer) \
(Enter COOKIE-ECHOED state) \---> (build TCB, enter ESTABLISHED
state)
/---- COOKIE-ACK
/
(Cancel T1-cookie timer, <---/
enter ESTABLISHED state)
This text has been modified by multiple errata. It is further updated in Section 3.9.
このテキストは、複数のエラッタによって変更されています。セクション3.9でさらに更新されます。
The figure is changed such that the T1-cookie timer is used instead of the T1-init timer.
この図は、T1-initタイマーの代わりにT1-cookieタイマーが使用されるように変更されています。
While processing [RFC4960], some typos were not caught.
[RFC4960]の処理中に、一部のタイプミスが検出されませんでした。
One typo was reported as an errata for [RFC4960] with Errata ID 5003.
1つのタイプミスが[RFC4960]のエラッタであり、エラッタID 5003が報告されていました。
---------
Old text: (Section 1.6)
---------
Transmission Sequence Numbers wrap around when they reach 2**32 - 1. That is, the next TSN a DATA chunk MUST use after transmitting TSN = 2*32 - 1 is TSN = 0.
送信シーケンス番号は、2 ** 32-1に達したときにラップアラウンドします。つまり、送信後、DATAチャンクが使用する次のTSN = 2 * 32-1はTSN = 0です。
---------
New text: (Section 1.6)
---------
Transmission Sequence Numbers wrap around when they reach 2**32 - 1. That is, the next TSN a DATA chunk MUST use after transmitting TSN = 2**32 - 1 is TSN = 0.
送信シーケンス番号は、2 ** 32-1に達したときにラップアラウンドします。つまり、データチャンクがTSN = 2 ** 32-1を送信した後に使用する必要がある次のTSNはTSN = 0です。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
---------
Old text: (Section 3.3.10.9)
---------
No User Data: This error cause is returned to the originator of a
ユーザーデータなし：このエラー原因は、
DATA chunk if a received DATA chunk has no user data.
受信したDATAチャンクにユーザーデータがない場合は、DATAチャンク。
---------
New text: (Section 3.3.10.9)
---------
No User Data: This error cause is returned to the originator of a DATA chunk if a received DATA chunk has no user data.
ユーザーデータがない：受信したDATAチャンクにユーザーデータがない場合、このエラー原因はDATAチャンクの発信者に返されます。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
---------
Old text: (Section 6.7, Figure 9)
---------
Endpoint A Endpoint Z {App
sends 3 messages; strm 0} DATA [TSN=6,Strm=0,Seq=2] ----------
-----> (ack delayed) (Start T3-rtx timer)
DATA [TSN=7,Strm=0,Seq=3] --------> X (lost)
DATA [TSN=8,Strm=0,Seq=4] ---------------> (gap detected,
immediately send ack)
/----- SACK [TSN Ack=6,Block=1,
/ Start=2,End=2]
<-----/ (remove 6 from out-queue,
and mark 7 as "1" missing report)
---------
New text: (Section 6.7, Figure 9)
---------
Endpoint A Endpoint Z
{App sends 3 messages; strm 0}
DATA [TSN=6,Strm=0,Seq=2] ---------------> (ack delayed)
(Start T3-rtx timer)
DATA [TSN=7,Strm=0,Seq=3] --------> X (lost)
DATA [TSN=8,Strm=0,Seq=4] ---------------> (gap detected,
immediately send ack)
/----- SACK [TSN Ack=6,Block=1,
/ Start=2,End=2]
<-----/
(remove 6 from out-queue,
and mark 7 as "1" missing report)
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
---------
Old text: (Section 6.10)
---------
An endpoint bundles chunks by simply including multiple chunks in one outbound SCTP packet. The total size of the resultant IP datagram,
エンドポイントは、1つの送信SCTPパケットに複数のチャンクを含めるだけで、チャンクをバンドルします。結果のIPデータグラムの合計サイズ、
including the SCTP packet and IP headers, MUST be less that or equal to the current Path MTU.
SCTPパケットとIPヘッダーを含め、現在のパスMTU以下である必要があります。
---------
New text: (Section 6.10)
---------
An endpoint bundles chunks by simply including multiple chunks in one outbound SCTP packet. The total size of the resultant IP datagram, including the SCTP packet and IP headers, MUST be less than or equal to the current Path MTU (PMTU).
エンドポイントは、1つの送信SCTPパケットに複数のチャンクを含めるだけで、チャンクをバンドルします。 SCTPパケットとIPヘッダーを含む、結果のIPデータグラムの合計サイズは、現在のパスMTU（PMTU）以下でなければなりません（MUST）。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
---------
Old text: (Section 10.1 O))
---------
o Receive Unacknowledged Message
o 未確認メッセージを受信
Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer size, [,stream id] [, stream sequence number] [,partial flag] [,payload protocol-id])
形式：RECEIVE_UNACKED（データ取得ID、バッファアドレス、バッファサイズ、[、ストリームID] [、ストリームシーケンス番号] [、部分的なフラグ] [、ペイロードプロトコルID]）
---------
New text: (Section 10.1 O))
---------
O) Receive Unacknowledged Message
O）未確認のメッセージを受信する
Format: RECEIVE_UNACKED(data retrieval id, buffer address, buffer size [,stream id] [,stream sequence number] [,partial flag] [,payload protocol-id])
形式：RECEIVE_UNACKED（データ取得ID、バッファアドレス、バッファサイズ[、ストリームID] [、ストリームシーケンス番号] [、部分的なフラグ] [、ペイロードプロトコルID]）
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
---------
Old text: (Section 10.1 M))
---------
M) Set Protocol Parameters
M）プロトコルパラメータの設定
Format: SETPROTOCOLPARAMETERS(association id, [,destination transport address,] protocol parameter list)
形式：SETPROTOCOLPARAMETERS（関連付けID、[、宛先トランスポートアドレス、]プロトコルパラメータリスト）
---------
New text: (Section 10.1 M))
---------
M) Set Protocol Parameters
M）プロトコルパラメータの設定
Format: SETPROTOCOLPARAMETERS(association id, [destination transport address,] protocol parameter list)
形式：SETPROTOCOLPARAMETERS（関連付けID、[宛先トランスポートアドレス、]プロトコルパラメータリスト）
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
---------
Old text: (Appendix C)
---------
ICMP2) An implementation MAY ignore all ICMPv6 messages where the type field is not "Destination Unreachable", "Parameter Problem",, or "Packet Too Big".
ICMP2）実装は、typeフィールドが「Destination Unreachable」、「Parameter Problem」、または「Packet Too Big」ではないすべてのICMPv6メッセージを無視してもよい（MAY）。
---------
New text: (Appendix C)
---------
ICMP2) An implementation MAY ignore all ICMPv6 messages where the type field is not "Destination Unreachable", "Parameter Problem", or "Packet Too Big".
ICMP2）実装は、typeフィールドが「Destination Unreachable」、「Parameter Problem」、または「Packet Too Big」ではないすべてのICMPv6メッセージを無視してもよい（MAY）。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
---------
Old text: (Appendix C)
---------
ICMP7) If the ICMP message is either a v6 "Packet Too Big" or a v4 "Fragmentation Needed", an implementation MAY process this information as defined for PATH MTU discovery.
ICMP7）ICMPメッセージがv6 "Packet Too Big"またはv4 "Fragmentation Needed"のいずれかである場合、実装は、PATH MTUディスカバリーに対して定義されているように、この情報を処理できます（MAY）。
---------
New text: (Appendix C)
---------
ICMP7) If the ICMP message is either a v6 "Packet Too Big" or a v4 "Fragmentation Needed", an implementation MAY process this information as defined for PMTU discovery.
ICMP7）ICMPメッセージがv6 "Packet Too Big"またはv4 "Fragmentation Needed"のいずれかである場合、実装はPMTU検出用に定義されているようにこの情報を処理できます（MAY）。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
---------
Old text: (Section 5.4)
---------
2) For the receiver of the COOKIE ECHO, the only CONFIRMED address is the one to which the INIT-ACK was sent.
2）COOKIE ECHOの受信側の場合、CONFIRMEDアドレスは、INIT-ACKが送信されたアドレスのみです。
---------
New text: (Section 5.4)
---------
2) For the receiver of the COOKIE ECHO, the only CONFIRMED address is the address to which the INIT ACK was sent.
2）COOKIE ECHOの受信側の場合、確認済みアドレスは、INIT ACKが送信されたアドレスのみです。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
---------
Old text: (Section 5.1.6, Figure 4)
---------
COOKIE ECHO [Cookie_Z] ------\
(Start T1-init timer) \
(Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED
state)
/---- COOKIE-ACK
/
(Cancel T1-init timer, <-----/
Enter ESTABLISHED state)
---------
New text: (Section 5.1.6, Figure 4)
---------
COOKIE ECHO [Cookie_Z] ------\
(Start T1-cookie timer) \
(Enter COOKIE-ECHOED state) \---> (build TCB, enter ESTABLISHED
state)
/---- COOKIE ACK
/
(Cancel T1-cookie timer, <---/
enter ESTABLISHED state)
This text has been modified by multiple errata. It includes modifications from Section 3.8. It is in final form and is not further updated in this document.
このテキストは、複数のエラッタによって変更されています。セクション3.8からの変更が含まれます。これは最終的な形式であり、このドキュメントではこれ以上更新されません。
---------
Old text: (Section 5.2.5)
---------
5.2.5. Handle Duplicate COOKIE-ACK.
5.2.5. 重複するCOOKIE-ACKを処理します。
---------
New text: (Section 5.2.5)
---------
5.2.5. Handle Duplicate COOKIE ACK.
5.2.5. 重複するCOOKIE ACKを処理します。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
---------
Old text: (Section 8.3)
---------
By default, an SCTP endpoint SHOULD monitor the reachability of the idle destination transport address(es) of its peer by sending a HEARTBEAT chunk periodically to the destination transport address(es). HEARTBEAT sending MAY begin upon reaching the ESTABLISHED state and is discontinued after sending either SHUTDOWN or SHUTDOWN-ACK. A receiver of a HEARTBEAT MUST respond to a HEARTBEAT with a HEARTBEAT-ACK after entering the COOKIE-ECHOED state (INIT sender) or the ESTABLISHED state (INIT receiver), up until reaching the SHUTDOWN-SENT state (SHUTDOWN sender) or the SHUTDOWN-ACK-SENT state (SHUTDOWN receiver).
デフォルトでは、SCTPエンドポイントは、HEARTBEATチャンクを定期的に宛先トランスポートアドレスに送信することにより、ピアのアイドル宛先トランスポートアドレスの到達可能性を監視する必要があります（SHOULD）。 HEARTBEATの送信は、ESTABLISHED状態に達したときに開始される場合があり、SHUTDOWNまたはSHUTDOWN-ACKのいずれかを送信した後に中止されます。 HEARTBEATの受信者は、COOKIE-ECHOED状態（INIT送信側）またはESTABLISHED状態（INIT受信側）に入った後、SHUTDOWN-SENT状態（SHUTDOWN送信側）またはSHUTDOWNに到達するまで、HEARTBEAT-ACKでHEARTBEATに応答する必要があります。 -ACK-SENT状態（SHUTDOWNレシーバー）。
---------
New text: (Section 8.3)
---------
By default, an SCTP endpoint SHOULD monitor the reachability of the idle destination transport address(es) of its peer by sending a HEARTBEAT chunk periodically to the destination transport address(es). HEARTBEAT sending MAY begin upon reaching the ESTABLISHED state and is discontinued after sending either SHUTDOWN or SHUTDOWN ACK. A receiver of a HEARTBEAT MUST respond to a HEARTBEAT with a HEARTBEAT ACK after entering the COOKIE-ECHOED state (INIT sender) or the ESTABLISHED state (INIT receiver), up until reaching the SHUTDOWN-SENT state (SHUTDOWN sender) or the SHUTDOWN-ACK-SENT state (SHUTDOWN receiver).
デフォルトでは、SCTPエンドポイントは、HEARTBEATチャンクを定期的に宛先トランスポートアドレスに送信することにより、ピアのアイドル宛先トランスポートアドレスの到達可能性を監視する必要があります（SHOULD）。 HEARTBEATの送信は、ESTABLISHED状態に達したときに開始される場合があり、SHUTDOWNまたはSHUTDOWN ACKを送信した後に中止されます。 HEARTBEATの受信者は、COOKIE-ECHOED状態（INIT送信側）またはESTABLISHED状態（INIT受信側）に入った後、SHUTDOWN-SENT状態（SHUTDOWN送信側）またはSHUTDOWN-に到達するまで、HEARTBEAT ACKでHEARTBEATに応答する必要があります。 ACK-SENT状態（SHUTDOWNレシーバー）。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
Several typos have been fixed.
いくつかのタイプミスが修正されました。
The CRC32c computation is described in Appendix B of [RFC4960]. However, the corresponding sample code and its explanation appear at the end of Appendix C of [RFC4960], which deals with ICMP handling.
CRC32cの計算については、[RFC4960]の付録Bで説明されています。ただし、対応するサンプルコードとその説明は、[RFC4960]の付録Cの最後に記載されており、ICMPの処理を扱います。
The text in Appendix C of [RFC4960], starting with the following sentence, needs to be moved to the end of Appendix B.
[RFC4960]の付録Cのテキストは、次の文で始まり、付録Bの最後に移動する必要があります。
The following non-normative sample code is taken from an open-source CRC generator [WILLIAMS93], using the "mirroring" technique and yielding a lookup table for SCTP CRC32c with 256 entries, each 32 bits wide.
次の非規範的なサンプルコードは、「ミラーリング」技術を使用して、それぞれ32ビット幅の256エントリを持つSCTP CRC32cのルックアップテーブルを生成するオープンソースCRCジェネレータ[WILLIAMS93]から取得されます。
This text has been modified by multiple errata. It includes modifications from Section 3.5. It is further updated in Section 3.46.
このテキストは、複数のエラッタによって変更されています。セクション3.5からの変更が含まれます。セクション3.46でさらに更新されます。
The text is moved to the appropriate location.
テキストが適切な場所に移動します。
Section 7.2.3 of [RFC4960] explicitly states that partial_bytes_acked should be reset to 0 after packet loss detection from selective acknowledgment (SACK), but this information is not accounted for in the case of T3-rtx timer expiration.
[RFC4960]のセクション7.2.3は、選択的確認応答（SACK）からのパケット損失検出後に、partial_bytes_ackedを0にリセットする必要があることを明示的に述べていますが、T3-rtxタイマーの期限切れの場合、この情報は考慮されません。
---------
Old text: (Section 7.2.3)
---------
When the T3-rtx timer expires on an address, SCTP should perform slow start by:
T3-rtxタイマーがアドレスで期限切れになると、SCTPは次のようにスロースタートを実行する必要があります。
ssthresh = max(cwnd/2, 4*MTU)
cwnd = 1*MTU
---------
New text: (Section 7.2.3)
---------
When the T3-rtx timer expires on an address, SCTP SHOULD perform slow start by:
T3-rtxタイマーがアドレスで期限切れになると、SCTPはスロースタートを実行する必要があります（SHOULD）。
ssthresh = max(cwnd/2, 4*MTU)
cwnd = 1*MTU
partial_bytes_acked = 0
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
The new text specifies that partial_bytes_acked should be reset to 0 after T3-rtx timer expiration.
新しいテキストでは、T3-rtxタイマーの有効期限が切れた後、partial_bytes_ackedを0にリセットする必要があることを指定しています。
Section 7.2.2 of [RFC4960] likely implies the wrong order of adjustments applied to partial_bytes_acked and cwnd in the congestion avoidance phase.
[RFC4960]のセクション7.2.2は、輻輳回避フェーズでpartial_bytes_ackedとcwndに適用される調整の順序が間違っていることを示唆している可能性があります。
---------
Old text: (Section 7.2.2)
---------
o When partial_bytes_acked is equal to or greater than cwnd and before the arrival of the SACK the sender had cwnd or more bytes of data outstanding (i.e., before arrival of the SACK, flightsize was greater than or equal to cwnd), increase cwnd by MTU, and reset partial_bytes_acked to (partial_bytes_acked - cwnd).
o partial_bytes_ackedがcwnd以上で、SACKの到着前に送信者が未処理のデータのcwnd以上のバイトを持っていた場合（つまり、SACKの到着前に、flightsizeがcwnd以上であった場合）、MTUによってcwndを増やします。そして、partial_bytes_ackedを（partial_bytes_acked-cwnd）にリセットします。
---------
New text: (Section 7.2.2)
---------
o (1) when partial_bytes_acked is equal to or greater than cwnd and (2) before the arrival of the SACK the sender had cwnd or more bytes of data outstanding (i.e., before the arrival of the SACK, flightsize was greater than or equal to cwnd), partial_bytes_acked is reset to (partial_bytes_acked - cwnd). Next, cwnd is increased by 1*MTU.
o（1）partial_bytes_ackedがcwnd以上の場合、および（2）SACKの到着前に送信者が未処理のデータのcwnd以上のバイトを持っていた（つまり、SACKの到着前に、flightsizeが以上であった） cwnd）、partial_bytes_ackedは（partial_bytes_acked-cwnd）にリセットされます。次に、cwndが1 * MTUずつ増加します。
This text has been modified by multiple errata. It is further updated in Section 3.26.
このテキストは、複数のエラッタによって変更されています。セクション3.26でさらに更新されます。
The new text defines the exact order of adjustments of partial_bytes_acked and cwnd in the congestion avoidance phase.
新しいテキストは、輻輳回避フェーズでのpartial_bytes_ackedおよびcwndの調整の正確な順序を定義します。
Sections 8.1 and 8.3 of [RFC4960] prescribe that the receiver of a HEARTBEAT ACK must reset the association overall error count. In some circumstances, e.g., when a router discards DATA chunks but not HEARTBEAT chunks due to the larger size of the DATA chunk, it might be better to not clear the association error counter on reception of the HEARTBEAT ACK and reset it only on reception of the SACK to avoid stalling the association.
[RFC4960]のセクション8.1および8.3は、HEARTBEAT ACKの受信者が関連付け全体のエラー数をリセットする必要があることを規定しています。状況によっては、たとえば、DATAチャンクのサイズが大きいためにルーターがDATAチャンクを破棄し、HEARTBEATチャンクを破棄しない場合、HEARTBEAT ACKの受信時に関連付けエラーカウンターをクリアせず、受信時にのみリセットする方がよい場合があります。アソシエーションの停止を回避するためのSACK。
---------
Old text: (Section 8.1)
---------
The counter shall be reset each time a DATA chunk sent to that peer endpoint is acknowledged (by the reception of a SACK) or a HEARTBEAT ACK is received from the peer endpoint.
カウンターは、そのピアエンドポイントに送信されたDATAチャンクが（SACKの受信により）確認されるか、ピアエンドポイントからHEARTBEAT ACKが受信されるたびにリセットされます。
---------
New text: (Section 8.1)
---------
The counter MUST be reset each time a DATA chunk sent to that peer endpoint is acknowledged (by the reception of a SACK). When a HEARTBEAT ACK is received from the peer endpoint, the counter SHOULD also be reset. The receiver of the HEARTBEAT ACK MAY choose not to clear the counter if there is outstanding data on the association. This allows for handling the possible difference in reachability based on DATA chunks and HEARTBEAT chunks.
カウンターは、そのピアエンドポイントに送信されたDATAチャンクが（SACKの受信によって）確認されるたびにリセットされる必要があります。ピアエンドポイントからHEARTBEAT ACKを受信すると、カウンターもリセットする必要があります（SHOULD）。 HEARTBEAT ACKの受信側は、関連付けに未処理のデータがある場合、カウンターをクリアしないことを選択できます。これにより、DATAチャンクとHEARTBEATチャンクに基づいて到達可能性の違いの可能性を処理できます。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
---------
Old text: (Section 8.3)
---------
Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT should clear the error counter of the destination transport address to which the HEARTBEAT was sent, and mark the destination transport address as active if it is not so marked. The endpoint may optionally report to the upper layer when an inactive destination address is marked as active due to the reception of the latest HEARTBEAT ACK. The receiver of the HEARTBEAT ACK must also clear the association overall error count as well (as defined in Section 8.1).
HEARTBEAT ACKを受信すると、HEARTBEATの送信者は、HEARTBEATが送信された宛先トランスポートアドレスのエラーカウンターをクリアし、宛先トランスポートアドレスがアクティブでない場合はアクティブとしてマークする必要があります。最新のHEARTBEAT ACKを受信したために非アクティブな宛先アドレスがアクティブとしてマークされている場合、エンドポイントはオプションで上位層に報告する場合があります。 HEARTBEAT ACKの受信者は、アソシエーション全体のエラーカウントもクリアする必要があります（セクション8.1で定義）。
---------
New text: (Section 8.3)
---------
Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT MUST clear the error counter of the destination transport address to which the HEARTBEAT was sent and mark the destination transport address as active if it is not so marked. The endpoint MAY optionally report to the upper layer when an inactive destination address is marked as active due to the reception of the latest HEARTBEAT ACK. The receiver of the HEARTBEAT ACK SHOULD also clear the association overall error count (as defined in Section 8.1).
HEARTBEAT ACKを受信すると、HEARTBEATの送信者は、HEARTBEATが送信された宛先トランスポートアドレスのエラーカウンターをクリアし、マークされていない場合は宛先トランスポートアドレスをアクティブとしてマークする必要があります。最新のHEARTBEAT ACKを受信したために非アクティブな宛先アドレスがアクティブとしてマークされている場合、エンドポイントはオプションで上位層に報告する場合があります。 HEARTBEAT ACKの受信者は、関連付け全体のエラーカウントもクリアする必要があります（セクション8.1で定義）。
This text has been modified by multiple errata. It is further updated in Section 3.23.
このテキストは、複数のエラッタによって変更されています。セクション3.23でさらに更新されます。
The new text provides the possibility of not resetting the association overall error count when a HEARTBEAT ACK is received if there are valid reasons for not doing so.
新しいテキストでは、ハートビートACKを受信したときに正当な理由がある場合にそれを実行しないと、関連付け全体のエラーカウントがリセットされない可能性があります。
[RFC4960] clearly describes where to retransmit data that is timed out when the peer is multi-homed, but the same is not stated for fast retransmissions.
[RFC4960]は、ピアがマルチホームであるときにタイムアウトしたデータを再送信する場所を明確に説明していますが、高速再送信については同じことが述べられていません。
---------
Old text: (Section 6.4)
---------
Furthermore, when its peer is multi-homed, an endpoint SHOULD try to retransmit a chunk that timed out to an active destination transport address that is different from the last destination address to which the DATA chunk was sent.
さらに、ピアがマルチホームの場合、エンドポイントは、タイムアウトしたチャンクを、DATAチャンクが送信された最後の宛先アドレスとは異なるアクティブな宛先トランスポートアドレスに再送信する必要があります（SHOULD）。
---------
New text: (Section 6.4)
---------
Furthermore, when its peer is multi-homed, an endpoint SHOULD try to retransmit a chunk that timed out to an active destination transport address that is different from the last destination address to which the DATA chunk was sent.
さらに、ピアがマルチホームの場合、エンドポイントは、タイムアウトしたチャンクを、DATAチャンクが送信された最後の宛先アドレスとは異なるアクティブな宛先トランスポートアドレスに再送信する必要があります（SHOULD）。
When its peer is multi-homed, an endpoint SHOULD send fast retransmissions to the same destination transport address to which the original data was sent. If the primary path has been changed and the original data was sent to the old primary path before the Fast Retransmit, the implementation MAY send it to the new primary path.
ピアがマルチホームの場合、エンドポイントは、元のデータの送信先と同じ宛先トランスポートアドレスに高速再送信を送信する必要があります（SHOULD）。プライマリパスが変更され、元のデータが高速再送信の前に古いプライマリパスに送信された場合、実装はそれを新しいプライマリパスに送信できます（MAY）。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
The new text clarifies where to send fast retransmissions.
新しいテキストでは、高速再送信の送信先が明確になっています。
The Fast Retransmit on Gap Reports algorithm intends that only the very first packet may be sent regardless of cwnd in the Fast Recovery phase, but rule 3) in Section 7.2.4 of [RFC4960] misses this clarification.
ギャップレポートでの高速再送信アルゴリズムは、高速リカバリフェーズのcwndに関係なく、最初のパケットのみが送信されることを意図していますが、[RFC4960]のセクション7.2.4のルール3）はこの説明を逃しています。
---------
Old text: (Section 7.2.4)
---------
3) Determine how many of the earliest (i.e., lowest TSN) DATA chunks marked for retransmission will fit into a single packet, subject to constraint of the path MTU of the destination transport address to which the packet is being sent. Call this value K. Retransmit those K DATA chunks in a single packet. When a Fast Retransmit is being performed, the sender SHOULD ignore the value of cwnd and SHOULD NOT delay retransmission for this single packet.
3）パケットの送信先である宛先トランスポートアドレスのパスMTUの制約に従って、再送信用にマークされた最も早い（つまり、最低TSN）DATAチャンクが1つのパケットに適合する数を決定します。この値をKと呼びます。これらのK個のDATAチャンクを1つのパケットで再送信します。高速再送信が実行されている場合、送信者はcwndの値を無視する必要があり（SHOULD）、この単一パケットの再送信を遅延してはなりません（SHOULD NOT）。
---------
New text: (Section 7.2.4)
---------
3) If not in Fast Recovery, determine how many of the earliest (i.e., lowest TSN) DATA chunks marked for retransmission will fit into a single packet, subject to constraint of the PMTU of the destination transport address to which the packet is being sent. Call this value K. Retransmit those K DATA chunks in a single packet. When a Fast Retransmit is being performed, the sender SHOULD ignore the value of cwnd and SHOULD NOT delay retransmission for this single packet.
3）Fast Recoveryにない場合は、再送用にマークされた最も早い（つまり、最も低いTSN）DATAチャンクのうち、いくつが単一のパケットに収まるかを決定します（パケットの送信先の宛先トランスポートアドレスのPMTUの制約に従う）。 。この値をKと呼びます。これらのK個のDATAチャンクを1つのパケットで再送信します。高速再送信が実行されている場合、送信者はcwndの値を無視する必要があり（SHOULD）、この単一パケットの再送信を遅延してはなりません（SHOULD NOT）。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
The new text explicitly specifies that only the first packet in the Fast Recovery phase be sent and that the cwnd limitations be disregarded.
新しいテキストでは、高速復旧フェーズの最初のパケットのみが送信され、cwndの制限が無視されることが明示的に指定されています。
The initial value of ssthresh should be set arbitrarily high. Using the advertised receiver window of the peer is inappropriate if the peer increases its window after the handshake. Furthermore, a higher requirement level needs to be used, since not following the advice may result in performance problems.
ssthreshの初期値は、任意に高く設定する必要があります。ピアがハンドシェイク後にウィンドウを増やす場合、ピアのアドバタイズされたレシーバウィンドウの使用は不適切です。さらに、アドバイスに従わないとパフォーマンスの問題が発生する可能性があるため、より高い要件レベルを使用する必要があります。
---------
Old text: (Section 7.2.1)
---------
o The initial value of ssthresh MAY be arbitrarily high (for example, implementations MAY use the size of the receiver advertised window).
o ssthreshの初期値は任意に高くてもかまいません（たとえば、実装はレシーバがアドバタイズしたウィンドウのサイズを使用してもかまいません）。
---------
New text: (Section 7.2.1)
---------
o The initial value of ssthresh SHOULD be arbitrarily high (e.g., the size of the largest possible advertised window).
o ssthreshの初期値は任意に高くする必要があります（たとえば、可能な最大のアドバタイズされたウィンドウのサイズ）。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
The same value as the value suggested in [RFC5681], Section 3.1, is now used as an appropriate initial value. Also, the same requirement level is used.
[RFC5681]のセクション3.1で提案されている値と同じ値が、適切な初期値として使用されるようになりました。また、同じ要件レベルが使用されます。
The Path Verification procedure of [RFC4960] prescribes that any address passed to the sender of the INIT by its upper layer be automatically CONFIRMED. This, however, is unclear if (1) only addresses in the request to initiate association establishment or (2) any addresses provided by the upper layer in any requests (e.g., in 'Set Primary') are considered.
[RFC4960]のパス検証手順は、上位層によってINITの送信者に渡されたアドレスが自動的に確認されることを規定しています。ただし、これは、（1）アソシエーションの確立を開始するリクエスト内のアドレスのみ、または（2）リクエスト内の上位レイヤーによって提供されたアドレス（たとえば、「プライマリーの設定」）が考慮される場合、不明確です。
---------
Old text: (Section 5.4)
---------
1) Any address passed to the sender of the INIT by its upper layer is automatically considered to be CONFIRMED.
1) Any address passed to the sender of the INIT by its upper layer is automatically considered to be CONFIRMED.
---------
New text: (Section 5.4)
---------
1) Any addresses passed to the sender of the INIT by its upper layer in the request to initialize an association are automatically considered to be CONFIRMED.
1）アソシエーションを初期化する要求の上位層によってINITの送信側に渡されたアドレスは、自動的にCONFIRMEDと見なされます。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
The new text clarifies that only addresses provided by the upper layer in the request to initialize an association are automatically CONFIRMED.
新しいテキストでは、アソシエーションを初期化するリクエストで上位層から提供されたアドレスのみが自動的に確認されることが明記されています。
[RFC4960] is not completely clear when it describes data transmission after T3-rtx timer expiration. Section 7.2.1 of [RFC4960] does not specify how many packets are allowed to be sent after T3-rtx timer expiration if more than one packet fits into cwnd. At the same time, Section 7.2.3 of [RFC4960] has text without normative language saying that SCTP should ensure that no more than one packet will be in flight after T3-rtx timer expiration until successful acknowledgement. The text is therefore inconsistent.
[RFC4960] is not completely clear when it describes data transmission after T3-rtx timer expiration. Section 7.2.1 of [RFC4960] does not specify how many packets are allowed to be sent after T3-rtx timer expiration if more than one packet fits into cwnd. At the same time, Section 7.2.3 of [RFC4960] has text without normative language saying that SCTP should ensure that no more than one packet will be in flight after T3-rtx timer expiration until successful acknowledgement. The text is therefore inconsistent.
---------
Old text: (Section 7.2.1)
---------
o The initial cwnd after a retransmission timeout MUST be no more than 1*MTU.
o 再送信タイムアウト後の最初のcwndは、1 * MTU以下でなければなりません。
---------
New text: (Section 7.2.1)
---------
o The initial cwnd after a retransmission timeout MUST be no more than 1*MTU, and only one packet is allowed to be in flight until successful acknowledgement.
o 再送信タイムアウト後の最初のcwndは1 * MTU以下でなければならず、確認が成功するまで1つのパケットのみが飛行を許可されます。
This text is in final form and is not further updated in this document.
This text is in final form and is not further updated in this document.
The new text clearly specifies that only one packet is allowed to be sent after T3-rtx timer expiration until successful acknowledgement.
新しいテキストは、T3-rtxタイマーの有効期限が切れてから確認応答が成功するまで、1つのパケットのみを送信できることを明確に示しています。
In the case of an INIT received in the COOKIE-WAIT state, [RFC4960] prescribes that an INIT ACK be sent to the same destination address to which the original INIT has been sent. [RFC4960] does not address the possibility of the upper layer providing multiple remote IP addresses while requesting the association establishment. If the upper layer has provided multiple IP addresses and only a subset of these addresses are supported by the peer, then the destination address of the original INIT may be absent in the incoming INIT and sending an INIT ACK to that address is useless.
COOKIE-WAIT状態で受信されたINITの場合、[RFC4960]は、元のINITが送信されたのと同じ宛先アドレスにINIT ACKが送信されることを規定しています。 [RFC4960]は、アソシエーションの確立を要求している間に上位層が複数のリモートIPアドレスを提供する可能性に対処していません。上位層が複数のIPアドレスを提供し、これらのアドレスのサブセットのみがピアによってサポートされている場合、元のINITの宛先アドレスが着信INITになく、そのアドレスにINIT ACKを送信しても役に立たない場合があります。
---------
Old text: (Section 5.2.1)
---------
Upon receipt of an INIT in the COOKIE-WAIT state, an endpoint MUST respond with an INIT ACK using the same parameters it sent in its original INIT chunk (including its Initiate Tag, unchanged). When responding, the endpoint MUST send the INIT ACK back to the same address that the original INIT (sent by this endpoint) was sent.
COOKIE-WAIT状態でINITを受信すると、エンドポイントは、元のINITチャンクで送信したのと同じパラメーター（変更されていないInitiate Tagを含む）を使用して、INIT ACKで応答する必要があります。応答時に、エンドポイントはINIT ACKを、このエンドポイントによって送信された元のINITが送信されたのと同じアドレスに送信する必要があります。
---------
New text: (Section 5.2.1)
---------
Upon receipt of an INIT in the COOKIE-WAIT state, an endpoint MUST respond with an INIT ACK using the same parameters it sent in its original INIT chunk (including its Initiate Tag, unchanged). When responding, the following rules MUST be applied:
COOKIE-WAIT状態でINITを受信すると、エンドポイントは、元のINITチャンクで送信したのと同じパラメーター（変更されていないInitiate Tagを含む）を使用して、INIT ACKで応答する必要があります。応答するときは、次のルールを適用する必要があります。
1) The INIT ACK MUST only be sent to an address passed by the upper layer in the request to initialize the association.
1）INIT ACKは、アソシエーションを初期化する要求で上位層から渡されたアドレスにのみ送信する必要があります。
2) The INIT ACK MUST only be sent to an address reported in the incoming INIT.
2）INIT ACKは、着信INITで報告されたアドレスにのみ送信する必要があります。
3) The INIT ACK SHOULD be sent to the source address of the received INIT.
3）INIT ACKは、受信したINITの送信元アドレスに送信する必要があります（SHOULD）。
This text is in final form and is not further updated in this document.
This text is in final form and is not further updated in this document.
The new text requires sending an INIT ACK to a destination address that is passed by the upper layer and reported in the incoming INIT. If the source address of the INIT meets these conditions, sending the INIT ACK to the source address of the INIT is the preferred behavior.
新しいテキストでは、上位層によって渡され、着信INITで報告される宛先アドレスにINIT ACKを送信する必要があります。 INITの送信元アドレスがこれらの条件を満たす場合、INITの送信元アドレスにINIT ACKを送信することをお勧めします。
Section 6.1 of [RFC4960] states that when sending zero window probes, SCTP should neither increment the association counter nor increment the destination address error counter if it continues to receive new packets from the peer. However, the reception of new packets from the peer does not guarantee the peer's reachability, and if the destination address becomes unreachable during zero window probing, SCTP cannot get an updated rwnd until it switches the destination address for probes.
[RFC4960]のセクション6.1は、ゼロウィンドウプローブを送信するとき、ピアから新しいパケットを受信し続けている場合、SCTPがアソシエーションカウンターをインクリメントすることも、宛先アドレスエラーカウンターをインクリメントすることもないことを述べています。ただし、ピアからの新しいパケットの受信は、ピアの到達可能性を保証しません。ゼロウィンドウプローブ中に宛先アドレスに到達できなくなった場合、SCTPはプローブの宛先アドレスを切り替えるまで、更新されたrwndを取得できません。
---------
Old text: (Section 6.1 A))
---------
If the sender continues to receive new packets from the receiver while doing zero window probing, the unacknowledged window probes should not increment the error counter for the association or any destination transport address. This is because the receiver MAY keep its window closed for an indefinite time. Refer to Section 6.2 on the receiver behavior when it advertises a zero window.
ゼロウィンドウプローブを実行している間、送信側が受信側から新しいパケットを受信し続ける場合、未確認ウィンドウプローブは、アソシエーションまたは宛先トランスポートアドレスのエラーカウンターをインクリメントしないでください。これは、レシーバーがウィンドウを無期限に閉じたままにする可能性があるためです。ゼロウィンドウをアドバタイズするときのレシーバーの動作については、セクション6.2を参照してください。
---------
New text: (Section 6.1 A))
---------
If the sender continues to receive SACKs from the peer while doing zero window probing, the unacknowledged window probes SHOULD NOT increment the error counter for the association or any destination transport address. This is because the receiver could keep its window closed for an indefinite time. Section 6.2 describes the receiver behavior when it advertises a zero window.
ゼロウィンドウプローブを実行している間に送信側がピアからSACKを受信し続ける場合、未確認ウィンドウプローブは、アソシエーションまたは宛先トランスポートアドレスのエラーカウンターをインクリメントしないでください（SHOULD NOT）。これは、受信側がウィンドウを無期限に閉じたままにする可能性があるためです。セクション6.2では、ゼロウィンドウをアドバタイズするときのレシーバの動作について説明します。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
The new text clarifies that if the receiver continues to send SACKs, the sender of probes should not increment the error counter of the association and the destination address even if the SACKs do not acknowledge the probes.
The new text clarifies that if the receiver continues to send SACKs, the sender of probes should not increment the error counter of the association and the destination address even if the SACKs do not acknowledge the probes.
Section 10 of [RFC4960] is informative. Therefore, normative language such as MUST and MAY cannot be used there. However, there are several places in Section 10 of [RFC4960] where MUST and MAY are used.
[RFC4960]のセクション10は参考情報です。したがって、MUSTやMAYなどの規範的な言語は使用できません。ただし、[RFC4960]のセクション10には、MUSTおよびMAYが使用される場所がいくつかあります。
---------
Old text: (Section 10.1 E))
---------
o no-bundle flag - instructs SCTP not to bundle this user data with other outbound DATA chunks. SCTP MAY still bundle even when this flag is present, when faced with network congestion.
o no-bundleフラグ-このユーザーデータを他の送信DATAチャンクにバンドルしないようにSCTPに指示します。 SCTPは、このフラグが存在する場合でも、ネットワークの輻輳に直面したときにバンドルする場合があります。
---------
New text: (Section 10.1 E))
---------
o no-bundle flag - instructs SCTP not to bundle this user data with other outbound DATA chunks. When faced with network congestion, SCTP may still bundle the data, even when this flag is present.
o no-bundleフラグ-このユーザーデータを他の送信DATAチャンクにバンドルしないようにSCTPに指示します。ネットワークの輻輳に直面した場合、このフラグが存在していても、SCTPはデータをバンドルすることがあります。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
---------
Old text: (Section 10.1 G))
---------
o Stream Sequence Number - the Stream Sequence Number assigned by the sending SCTP peer.
o Stream Sequence Number - the Stream Sequence Number assigned by the sending SCTP peer.
o partial flag - if this returned flag is set to 1, then this Receive contains a partial delivery of the whole message. When this flag is set, the stream id and Stream Sequence Number MUST accompany this receive. When this flag is set to 0, it indicates that no more deliveries will be received for this Stream Sequence Number.
o 部分フラグ-この返されたフラグが1に設定されている場合、この受信にはメッセージ全体の部分配信が含まれます。このフラグが設定されている場合、ストリームIDとストリームシーケンス番号がこの受信に付随する必要があります。このフラグが0に設定されている場合、このストリームシーケンス番号の配信がこれ以上受信されないことを示します。
---------
New text: (Section 10.1 G))
---------
o stream sequence number - the Stream Sequence Number assigned by the sending SCTP peer.
o ストリームシーケンス番号-送信SCTPピアによって割り当てられたストリームシーケンス番号。
o partial flag - if this returned flag is set to 1, then this primitive contains a partial delivery of the whole message. When this flag is set, the stream id and stream sequence number must accompany this primitive. When this flag is set to 0, it indicates that no more deliveries will be received for this stream sequence number.
o 部分フラグ-この返されたフラグが1に設定されている場合、このプリミティブにはメッセージ全体の部分配信が含まれます。このフラグが設定されている場合、ストリームIDとストリームシーケンス番号がこのプリミティブに付随している必要があります。このフラグが0に設定されている場合、このストリームシーケンス番号に対してこれ以上の配信が受信されないことを示します。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
---------
Old text: (Section 10.1 N))
---------
o Stream Sequence Number - this value is returned indicating the Stream Sequence Number that was associated with the message.
o ストリームシーケンス番号-メッセージに関連付けられたストリームシーケンス番号を示すこの値が返されます。
o partial flag - if this returned flag is set to 1, then this message is a partial delivery of the whole message. When this flag is set, the stream id and Stream Sequence Number MUST accompany this receive. When this flag is set to 0, it indicates that no more deliveries will be received for this Stream Sequence Number.
o 部分的なフラグ-この返されたフラグが1に設定されている場合、このメッセージはメッセージ全体の部分的な配信です。このフラグが設定されている場合、ストリームIDとストリームシーケンス番号がこの受信に付随する必要があります。このフラグが0に設定されている場合、このストリームシーケンス番号の配信がこれ以上受信されないことを示します。
---------
New text: (Section 10.1 N))
---------
o stream sequence number - this value is returned indicating the Stream Sequence Number that was associated with the message.
o ストリームシーケンス番号-この値は、メッセージに関連付けられたストリームシーケンス番号を示して返されます。
o partial flag - if this returned flag is set to 1, then this message is a partial delivery of the whole message. When this flag is set, the stream id and stream sequence number must accompany this primitive. When this flag is set to 0, it indicates that no more deliveries will be received for this stream sequence number.
o 部分的なフラグ-この返されたフラグが1に設定されている場合、このメッセージはメッセージ全体の部分的な配信です。このフラグが設定されている場合、ストリームIDとストリームシーケンス番号がこのプリミティブに付随している必要があります。このフラグが0に設定されている場合、このストリームシーケンス番号に対してこれ以上の配信が受信されないことを示します。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
---------
Old text: (Section 10.1 O))
---------
o Stream Sequence Number - this value is returned indicating the Stream Sequence Number that was associated with the message.
o ストリームシーケンス番号-メッセージに関連付けられたストリームシーケンス番号を示すこの値が返されます。
o partial flag - if this returned flag is set to 1, then this message is a partial delivery of the whole message. When this flag is set, the stream id and Stream Sequence Number MUST accompany this receive. When this flag is set to 0, it indicates that no more deliveries will be received for this Stream Sequence Number.
o 部分的なフラグ-この返されたフラグが1に設定されている場合、このメッセージはメッセージ全体の部分的な配信です。このフラグが設定されている場合、ストリームIDとストリームシーケンス番号がこの受信に付随する必要があります。このフラグが0に設定されている場合、このストリームシーケンス番号の配信がこれ以上受信されないことを示します。
---------
New text: (Section 10.1 O))
---------
o stream sequence number - this value is returned indicating the Stream Sequence Number that was associated with the message.
o ストリームシーケンス番号-この値は、メッセージに関連付けられたストリームシーケンス番号を示して返されます。
o partial flag - if this returned flag is set to 1, then this message is a partial delivery of the whole message. When this flag is set, the stream id and stream sequence number must accompany this primitive. When this flag is set to 0, it indicates that no more deliveries will be received for this stream sequence number.
o 部分的なフラグ-この返されたフラグが1に設定されている場合、このメッセージはメッセージ全体の部分的な配信です。このフラグが設定されている場合、ストリームIDとストリームシーケンス番号がこのプリミティブに付随している必要があります。このフラグが0に設定されている場合、このストリームシーケンス番号に対してこれ以上の配信が受信されないことを示します。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
The normative language is removed from Section 10. In addition, the consistency of the text has been improved.
規範言語はセクション10から削除されました。さらに、テキストの一貫性が改善されました。
Two issues have been discovered in the text in Section 7.2.2 of [RFC4960] regarding partial_bytes_acked handling:
[RFC4960]のセクション7.2.2のテキストに、partial_bytes_ackedの処理に関する2つの問題が発見されました。
o If the Cumulative TSN Ack Point is not advanced but the SACK chunk acknowledges new TSNs in the Gap Ack Blocks, these newly acknowledged TSNs are not considered for partial_bytes_acked even though these TSNs were successfully received by the peer.
o 累積TSN Ackポイントが拡張されていないが、SACKチャンクがギャップAckブロックの新しいTSNを確認する場合、これらのTSNがピアによって正常に受信されたとしても、これらの新たに確認されたTSNはpartial_bytes_ackedとは見なされません。
o Duplicate TSNs are not considered in partial_bytes_acked even though they confirm that the DATA chunks were successfully received by the peer.
o 重複するTSNは、データチャンクがピアによって正常に受信されたことを確認しても、partial_bytes_ackedで考慮されません。
---------
Old text: (Section 7.2.2)
---------
o Whenever cwnd is greater than ssthresh, upon each SACK arrival that advances the Cumulative TSN Ack Point, increase partial_bytes_acked by the total number of bytes of all new chunks acknowledged in that SACK including chunks acknowledged by the new Cumulative TSN Ack and by Gap Ack Blocks.
o cwndがssthreshよりも大きい場合は常に、累積TSN Ackポイントを進める各SACKの到着時に、新しい累積TSN AckおよびギャップACKブロックによって確認されたチャンクを含む、そのSACKで確認されたすべての新しいチャンクの合計バイト数によって、partial_bytes_ackedを増やします。
---------
New text: (Section 7.2.2)
---------
o Whenever cwnd is greater than ssthresh, upon each SACK arrival, increase partial_bytes_acked by the total number of bytes of all new chunks acknowledged in that SACK, including chunks acknowledged by the new Cumulative TSN Ack, by Gap Ack Blocks, and by the number of bytes of duplicated chunks reported in Duplicate TSNs.
o cwndがssthreshより大きい場合は常に、SACKが到着するたびに、そのSACKで確認応答されたすべての新しいチャンクの合計バイト数（partial_bytes_acked）を増やします。これには、新しい累積TSN Ack、ギャップ確認ブロック、およびバイト数が確認されたチャンクも含まれます。重複TSNで報告された重複チャンクの数。
This text has been modified by multiple errata. It is further updated in Section 3.26.
This text has been modified by multiple errata. It is further updated in Section 3.26.
In the new text, partial_bytes_acked is increased by TSNs reported as duplicated, as well as TSNs newly acknowledged in Gap Ack Blocks, even if the Cumulative TSN Ack Point is not advanced.
In the new text, partial_bytes_acked is increased by TSNs reported as duplicated, as well as TSNs newly acknowledged in Gap Ack Blocks, even if the Cumulative TSN Ack Point is not advanced.
[RFC4960] uses inconsistent normative and non-normative language when describing rules for sending notifications to the upper layer. For example, Section 8.2 of [RFC4960] says that when a destination address becomes inactive due to an unacknowledged DATA chunk or HEARTBEAT chunk, SCTP SHOULD send a notification to the upper layer; however, Section 8.3 of [RFC4960] says that when a destination address becomes inactive due to an unacknowledged HEARTBEAT chunk, SCTP may send a notification to the upper layer.
[RFC4960]は、上位層に通知を送信するためのルールを記述するときに、一貫性のない規範的および非規範的言語を使用します。たとえば、[RFC4960]のセクション8.2は、未確認のDATAチャンクまたはHEARTBEATチャンクが原因で宛先アドレスが非アクティブになった場合、SCTPが上位層に通知を送信する必要があることを示しています。ただし、[RFC4960]のセクション8.3には、未確認のHEARTBEATチャンクが原因で宛先アドレスが非アクティブになると、SCTPが上位層に通知を送信する場合があると記載されています。
These inconsistent descriptions need to be corrected.
これらの矛盾した説明は修正する必要があります。
---------
Old text: (Section 8.1)
---------
An endpoint shall keep a counter on the total number of consecutive retransmissions to its peer (this includes retransmissions to all the destination transport addresses of the peer if it is multi-homed), including unacknowledged HEARTBEAT chunks.
エンドポイントは、未確認のHEARTBEATチャンクを含む、ピアへの連続した再送信の総数（マルチホームの場合、ピアのすべての宛先トランスポートアドレスへの再送信を含む）のカウンターを保持します。
---------
New text: (Section 8.1)
---------
An endpoint SHOULD keep a counter on the total number of consecutive retransmissions to its peer (this includes data retransmissions to all the destination transport addresses of the peer if it is multi-homed), including the number of unacknowledged HEARTBEAT chunks observed on the path that is currently used for data transfer. Unacknowledged HEARTBEAT chunks observed on paths different from the path currently used for data transfer SHOULD NOT increment the association error counter, as this could lead to association closure even if the path that is currently used for data transfer is available (but idle). If the value of this counter exceeds the limit indicated in the protocol parameter 'Association.Max.Retrans', the endpoint SHOULD consider the peer endpoint unreachable and SHALL stop transmitting any more data to it (and thus the association enters the CLOSED state). In addition, the endpoint SHOULD report the failure to the upper layer and optionally report back all outstanding user data remaining in its outbound queue. The association is automatically closed when the peer endpoint becomes unreachable.
エンドポイントは、そのピアへの連続する再送信の総数（マルチホームの場合、ピアのすべての宛先トランスポートアドレスへのデータ再送信を含む）のカウンターを維持する必要があります（SHOULD）。現在、データ転送に使用されています。現在データ転送に使用されているパスとは異なるパスで観察される未確認のHEARTBEATチャンクは、現在データ転送に使用されているパスが使用可能（ただしアイドル）であっても、アソシエーションが終了する可能性があるため、アソシエーションエラーカウンターをインクリメントしないでください。このカウンターの値がプロトコルパラメーター 'Association.Max.Retrans'で示されている制限を超える場合、エンドポイントはピアエンドポイントに到達できないと見なし、それ以上のデータの送信を停止する必要があります（したがって、関連付けはCLOSED状態になります）。さらに、エンドポイントは上位層に障害を報告する必要があり（SHOULD）、オプションでアウトバウンドキューに残っているすべての未処理のユーザーデータを報告します。ピアエンドポイントが到達不能になると、関連付けは自動的に閉じられます。
This text has been modified by multiple errata. It includes modifications from Section 3.6. It is in final form and is not further updated in this document.
このテキストは、複数のエラッタによって変更されています。セクション3.6からの変更が含まれています。これは最終的な形式であり、このドキュメントではこれ以上更新されません。
---------
Old text: (Section 8.2)
---------
When an outstanding TSN is acknowledged or a HEARTBEAT sent to that address is acknowledged with a HEARTBEAT ACK, the endpoint shall clear the error counter of the destination transport address to which the DATA chunk was last sent (or HEARTBEAT was sent). When the peer endpoint is multi-homed and the last chunk sent to it was a retransmission to an alternate address, there exists an ambiguity as to whether or not the acknowledgement should be credited to the address of the last chunk sent. However, this ambiguity does not seem to bear any significant consequence to SCTP behavior. If this ambiguity is undesirable, the transmitter may choose not to clear the error counter if the last chunk sent was a retransmission.
未解決のTSNが確認されるか、そのアドレスに送信されたHEARTBEATがHEARTBEAT ACKで確認されると、エンドポイントは、DATAチャンクが最後に送信された（またはHEARTBEATが送信された）宛先トランスポートアドレスのエラーカウンターをクリアします。ピアエンドポイントがマルチホームであり、最後に送信されたチャンクが代替アドレスへの再送信であった場合、最後に送信されたチャンクのアドレスに確認応答を送信する必要があるかどうかについて、あいまいさが存在します。ただし、このあいまいさがSCTPの動作に重大な影響を与えることはないようです。このあいまいさが望ましくない場合、送信された最後のチャンクが再送信であった場合、トランスミッタはエラーカウンタをクリアしないことを選択できます。
---------
New text: (Section 8.2)
---------
When an outstanding TSN is acknowledged or a HEARTBEAT sent to that address is acknowledged with a HEARTBEAT ACK, the endpoint SHOULD clear the error counter of the destination transport address to which the DATA chunk was last sent (or HEARTBEAT was sent) and SHOULD also report to the upper layer when an inactive destination address is marked as active. When the peer endpoint is multi-homed and the last chunk sent to it was a retransmission to an alternate address, there exists an ambiguity as to whether or not the acknowledgement could be credited to the address of the last chunk sent. However, this ambiguity does not seem to have significant consequences for SCTP behavior. If this ambiguity is undesirable, the transmitter MAY choose not to clear the error counter if the last chunk sent was a retransmission.
未解決のTSNが確認されるか、そのアドレスに送信されたHEARTBEATがHEARTBEAT ACKで確認されると、エンドポイントは、DATAチャンクが最後に送信された（またはHEARTBEATが送信された）宛先トランスポートアドレスのエラーカウンターをクリアし、報告する必要もあります（SHOULD）非アクティブな宛先アドレスがアクティブとしてマークされている場合、上位層に送信されます。ピアエンドポイントがマルチホームであり、最後に送信されたチャンクが代替アドレスへの再送信であった場合、最後に送信されたチャンクのアドレスに確認応答を送信できるかどうかについて曖昧さが存在します。ただし、このあいまいさがSCTPの動作に重大な影響を与えるとは思われません。このあいまいさが望ましくない場合、送信された最後のチャンクが再送信であった場合、トランスミッタはエラーカウンタをクリアしないことを選択できます（MAY）。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
---------
Old text: (Section 8.3)
---------
When the value of this counter reaches the protocol parameter 'Path.Max.Retrans', the endpoint should mark the corresponding destination address as inactive if it is not so marked, and may also optionally report to the upper layer the change of reachability of this destination address. After this, the endpoint should continue HEARTBEAT on this destination address but should stop increasing the counter.
このカウンターの値がプロトコルパラメーター 'Path.Max.Retrans'に到達すると、エンドポイントは、対応する宛先アドレスが非アクティブである場合は非アクティブとしてマークする必要があり、オプションで、この到達可能性の変更を上位層に報告することもできます。宛先アドレス。この後、エンドポイントはこの宛先アドレスでHEARTBEATを続行する必要がありますが、カウンターの増加を停止する必要があります。
---------
New text: (Section 8.3)
---------
When the value of this counter exceeds the protocol parameter 'Path.Max.Retrans', the endpoint SHOULD mark the corresponding destination address as inactive if it is not so marked and SHOULD also report to the upper layer the change in reachability of this destination address. After this, the endpoint SHOULD continue HEARTBEAT on this destination address but SHOULD stop increasing the counter.
このカウンターの値がプロトコルパラメーター 'Path.Max.Retrans'を超えると、エンドポイントは、対応する宛先アドレスが非アクティブである場合は非アクティブとしてマークする必要があり（SHOULD）、この宛先アドレスの到達可能性の変化も上位層に報告する必要があります（SHOULD）。 。この後、エンドポイントはこの宛先アドレスでハートビートを続行する必要がありますが、カウンターの増加を停止する必要があります（SHOULD）。
This text has been modified by multiple errata. It includes modifications from Section 3.1. It is in final form and is not further updated in this document.
このテキストは、複数のエラッタによって変更されています。セクション3.1からの変更が含まれています。これは最終的な形式であり、このドキュメントではこれ以上更新されません。
---------
Old text: (Section 8.3)
---------
Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT should clear the error counter of the destination transport address to which the HEARTBEAT was sent, and mark the destination transport address as active if it is not so marked. The endpoint may optionally report to the upper layer when an inactive destination address is marked as active due to the reception of the latest HEARTBEAT ACK. The receiver of the HEARTBEAT ACK must also clear the association overall error count as well (as defined in Section 8.1).
HEARTBEAT ACKを受信すると、HEARTBEATの送信者は、HEARTBEATが送信された宛先トランスポートアドレスのエラーカウンターをクリアし、宛先トランスポートアドレスがアクティブでない場合はアクティブとしてマークする必要があります。最新のHEARTBEAT ACKを受信したために非アクティブな宛先アドレスがアクティブとしてマークされている場合、エンドポイントはオプションで上位層に報告する場合があります。 HEARTBEAT ACKの受信者は、アソシエーション全体のエラーカウントもクリアする必要があります（セクション8.1で定義）。
---------
New text: (Section 8.3)
---------
Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT SHOULD clear the error counter of the destination transport address to which the HEARTBEAT was sent and mark the destination transport address as active if it is not so marked. The endpoint SHOULD report to the upper layer when an inactive destination address is marked as active due to the reception of the latest HEARTBEAT ACK. The receiver of the HEARTBEAT ACK SHOULD also clear the association overall error count (as defined in Section 8.1).
Upon the receipt of the HEARTBEAT ACK, the sender of the HEARTBEAT SHOULD clear the error counter of the destination transport address to which the HEARTBEAT was sent and mark the destination transport address as active if it is not so marked. The endpoint SHOULD report to the upper layer when an inactive destination address is marked as active due to the reception of the latest HEARTBEAT ACK. The receiver of the HEARTBEAT ACK SHOULD also clear the association overall error count (as defined in Section 8.1).
This text has been modified by multiple errata. It includes modifications from Section 3.13. It is in final form and is not further updated in this document.
このテキストは、複数のエラッタによって変更されています。セクション3.13からの変更が含まれています。これは最終的な形式であり、このドキュメントではこれ以上更新されません。
---------
Old text: (Section 9.2)
---------
An endpoint should limit the number of retransmissions of the SHUTDOWN chunk to the protocol parameter 'Association.Max.Retrans'. If this threshold is exceeded, the endpoint should destroy the TCB and MUST report the peer endpoint unreachable to the upper layer (and thus the association enters the CLOSED state).
エンドポイントは、SHUTDOWNチャンクの再送信の数をプロトコルパラメーター 'Association.Max.Retrans'に制限する必要があります。このしきい値を超える場合、エンドポイントはTCBを破棄し、到達できないピアエンドポイントを上位層に報告する必要があります（したがって、関連付けはCLOSED状態になります）。
---------
New text: (Section 9.2)
---------
An endpoint SHOULD limit the number of retransmissions of the SHUTDOWN chunk to the protocol parameter 'Association.Max.Retrans'. If this threshold is exceeded, the endpoint SHOULD destroy the TCB and SHOULD report the peer endpoint unreachable to the upper layer (and thus the association enters the CLOSED state).
エンドポイントは、SHUTDOWNチャンクの再送信数をプロトコルパラメータ 'Association.Max.Retrans'に制限する必要があります（SHOULD）。このしきい値を超えた場合、エンドポイントはTCBを破棄し（SHOULD）、ピアエンドポイントに到達できないことを上位層に報告する必要があります（したがって、関連付けはCLOSED状態になります）。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
---------
Old text: (Section 9.2)
---------
The sender of the SHUTDOWN ACK should limit the number of retransmissions of the SHUTDOWN ACK chunk to the protocol parameter 'Association.Max.Retrans'. If this threshold is exceeded, the endpoint should destroy the TCB and may report the peer endpoint unreachable to the upper layer (and thus the association enters the CLOSED state).
SHUTDOWN ACKの送信者は、SHUTDOWN ACKチャンクの再送信数をプロトコルパラメータ「Association.Max.Retrans」に制限する必要があります。このしきい値を超えると、エンドポイントはTCBを破棄し、到達できないピアエンドポイントを上位層に報告する可能性があります（したがって、関連付けはCLOSED状態になります）。
---------
New text: (Section 9.2)
---------
The sender of the SHUTDOWN ACK SHOULD limit the number of retransmissions of the SHUTDOWN ACK chunk to the protocol parameter 'Association.Max.Retrans'. If this threshold is exceeded, the endpoint SHOULD destroy the TCB and SHOULD report the peer endpoint unreachable to the upper layer (and thus the association enters the CLOSED state).
SHUTDOWN ACKの送信者は、SHUTDOWN ACKチャンクの再送信の数をプロトコルパラメータ 'Association.Max.Retrans'に制限する必要があります（SHOULD）。このしきい値を超えた場合、エンドポイントはTCBを破棄し（SHOULD）、ピアエンドポイントに到達できないことを上位層に報告する必要があります（したがって、関連付けはCLOSED状態になります）。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
The inconsistencies are removed by consistently using SHOULD.
矛盾は、SHOULDを一貫して使用することにより削除されます。
SCTP as specified in [RFC4960] supports delaying SACKs. The timer value for this is a parameter, and Section 6.2 of [RFC4960] specifies a default and maximum value for it. However, (1) defining a name for this parameter and (2) listing it in the table of protocol parameters in Section 15 of [RFC4960] are missing.
SCTP as specified in [RFC4960] supports delaying SACKs. The timer value for this is a parameter, and Section 6.2 of [RFC4960] specifies a default and maximum value for it. However, (1) defining a name for this parameter and (2) listing it in the table of protocol parameters in Section 15 of [RFC4960] are missing.
This issue was reported as an errata for [RFC4960] with Errata ID 4656.
この問題は、エラータID 4656の[RFC4960]のエラータとして報告されました。
---------
Old text: (Section 6.2)
---------
An implementation MUST NOT allow the maximum delay to be configured to be more than 500 ms. In other words, an implementation MAY lower this value below 500 ms but MUST NOT raise it above 500 ms.
実装では、最大遅延を500ミリ秒以上に構成することを許可してはなりません（MUST NOT）。言い換えると、実装はこの値を500ミリ秒未満にしてもよいが、500ミリ秒を超えてはならない（MUST NOT）。
---------
New text: (Section 6.2)
---------
An implementation MUST NOT allow the maximum delay (protocol parameter 'SACK.Delay') to be configured to be more than 500 ms. In other words, an implementation MAY lower the value of SACK.Delay below 500 ms but MUST NOT raise it above 500 ms.
実装では、最大遅延（プロトコルパラメータ 'SACK.Delay'）を500ミリ秒を超えるように構成してはなりません（MUST NOT）。言い換えれば、実装はSACK.Delayの値を500ミリ秒未満にしてもよいが、500ミリ秒を超えてはならない（MUST NOT）。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
---------
Old text: (Section 15)
---------
The following protocol parameters are RECOMMENDED:
次のプロトコルパラメータを推奨します。
RTO.Initial - 3 seconds
RTO.Min - 1 second
RTO.Max - 60 seconds
Max.Burst - 4
RTO.Alpha - 1/8
RTO.Beta - 1/4
Valid.Cookie.Life - 60 seconds
Association.Max.Retrans - 10 attempts
Path.Max.Retrans - 5 attempts (per destination address)
Max.Init.Retransmits - 8 attempts
HB.interval - 30 seconds
HB.Max.Burst - 1
---------
New text: (Section 15)
---------
The following protocol parameters are RECOMMENDED:
次のプロトコルパラメータを推奨します。
RTO.Initial: 3 seconds
RTO.Min: 1 second
RTO.Max: 60 seconds
Max.Burst: 4
RTO.Alpha: 1/8
RTO.Beta: 1/4
Valid.Cookie.Life: 60 seconds
Association.Max.Retrans: 10 attempts
Path.Max.Retrans: 5 attempts (per destination address)
Max.Init.Retransmits: 8 attempts
HB.interval: 30 seconds
HB.Max.Burst: 1
SACK.Delay: 200 milliseconds
This text has been modified by multiple errata. It is further updated in Section 3.32.
このテキストは、複数のエラッタによって変更されています。セクション3.32でさらに更新されます。
The parameter is given the name 'SACK.Delay' and added to the list of protocol parameters.
パラメータには「SACK.Delay」という名前が付けられ、プロトコルパラメータのリストに追加されます。
There are a few places in [RFC4960] where text specifies that the receiver of a packet must discard it while processing the chunks of the packet. Whether or not the receiver has to roll back state changes already performed while processing the packet is unclear.
[RFC4960]には、パケットのチャンクの処理中にパケットの受信者がパケットを破棄する必要があることを指定する場所がいくつかあります。受信側がパケットの処理中にすでに実行された状態変更をロールバックする必要があるかどうかは不明です。
The intention of [RFC4960] is to process an incoming packet chunk by chunk and not to perform any prescreening of chunks in the received packet. Thus, by discarding one chunk, the receiver also causes the discarding of all further chunks.
[RFC4960]の目的は、着信パケットのチャンクをチャンクごとに処理することであり、受信したパケットのチャンクの事前スクリーニングを実行しないことです。したがって、1つのチャンクを破棄することにより、レシーバはさらにすべてのチャンクを破棄します。
---------
Old text: (Section 3.2)
---------
00 - Stop processing this SCTP packet and discard it, do not process any further chunks within it.
00-このSCTPパケットの処理を停止して破棄し、その中のそれ以上のチャンクを処理しないでください。
01 - Stop processing this SCTP packet and discard it, do not process any further chunks within it, and report the unrecognized chunk in an 'Unrecognized Chunk Type'.
01-このSCTPパケットの処理を停止して破棄し、その中のそれ以上のチャンクを処理せず、認識されていないチャンクを「Unrecognized Chunk Type」で報告します。
---------
New text: (Section 3.2)
---------
00 - Stop processing this SCTP packet; discard the unrecognized chunk and all further chunks.
00-このSCTPパケットの処理を停止します。認識されていないチャンクとそれ以降のすべてのチャンクを破棄します。
01 - Stop processing this SCTP packet, discard the unrecognized chunk and all further chunks, and report the unrecognized chunk in an 'Unrecognized Chunk Type'.
01 - Stop processing this SCTP packet, discard the unrecognized chunk and all further chunks, and report the unrecognized chunk in an 'Unrecognized Chunk Type'.
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
---------
Old text: (Section 11.3)
---------
It is helpful for some firewalls if they can inspect just the first fragment of a fragmented SCTP packet and unambiguously determine whether it corresponds to an INIT chunk (for further information, please refer to [RFC1858]). Accordingly, we stress the requirements, stated in Section 3.1, that (1) an INIT chunk MUST NOT be bundled with any other chunk in a packet, and (2) a packet containing an INIT chunk MUST have a zero Verification Tag. Furthermore, we require that the receiver of an INIT chunk MUST enforce these rules by silently discarding an arriving packet with an INIT chunk that is bundled with other chunks or has a non-zero verification tag and contains an INIT-chunk.
一部のファイアウォールは、断片化されたSCTPパケットの最初のフラグメントのみを検査し、それがINITチャンクに対応するかどうかを明確に判断できる場合に役立ちます（詳細については、[RFC1858]を参照してください）。したがって、セクション3.1で述べた要件を強調します。（1）INITチャンクはパケット内の他のチャンクとバンドルしてはならず、（2）INITチャンクを含むパケットはゼロ検証タグを持つ必要があります。さらに、INITチャンクの受信者は、他のチャンクにバンドルされているか、ゼロ以外の検証タグがあり、INITチャンクを含むINITチャンクを持つ到着パケットをサイレントに破棄することにより、これらのルールを適用する必要があります。
---------
New text: (Section 11.3)
---------
It is helpful for some firewalls if they can inspect just the first fragment of a fragmented SCTP packet and unambiguously determine whether it corresponds to an INIT chunk (for further information, please refer to [RFC1858]). Accordingly, we stress the requirements, as stated in Section 3.1, that (1) an INIT chunk MUST NOT be bundled with any other chunk in a packet and (2) a packet containing an INIT chunk MUST have a zero Verification Tag. The receiver of an INIT chunk MUST silently discard the INIT chunk and all further chunks if the INIT chunk is bundled with other chunks or the packet has a non-zero Verification Tag.
一部のファイアウォールは、断片化されたSCTPパケットの最初のフラグメントのみを検査し、それがINITチャンクに対応するかどうかを明確に判断できる場合に役立ちます（詳細については、[RFC1858]を参照してください）。したがって、セクション3.1で述べたように、（1）INITチャンクはパケット内の他のチャンクとバンドルしてはならず（2）INITチャンクを含むパケットにはゼロ検証タグがなければならないという要件を強調します。 INITチャンクが他のチャンクとバンドルされているか、パケットにゼロ以外の検証タグがある場合、INITチャンクの受信者はINITチャンクとそれ以降のすべてのチャンクをサイレントに破棄する必要があります。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
The new text makes it clear that chunks can be processed from the beginning to the end and that no rollback or prescreening is required.
新しいテキストでは、チャンクを最初から最後まで処理できること、およびロールバックや事前スクリーニングが不要であることを明確にしています。
Section 7.2.2 of [RFC4960] prescribes that cwnd be increased by 1*MTU per RTT if the sender has cwnd or more bytes of data outstanding to the corresponding address in the congestion avoidance phase. However, this is described without normative language. Moreover, Section 7.2.2 of [RFC4960] includes an algorithm that specifies how an implementation can achieve this, but this algorithm is underspecified and actually allows increasing cwnd by more than 1*MTU per RTT.
[RFC4960]のセクション7.2.2は、送信者が輻輳回避フェーズで対応するアドレスに未解決のデータのcwnd以上のバイト数を持っている場合、RTTごとに1 * MTUずつcwndを増やすことを規定しています。ただし、これは規範的な言語なしで説明されています。さらに、[RFC4960]のセクション7.2.2には、実装でこれをどのように実現できるかを指定するアルゴリズムが含まれていますが、このアルゴリズムは十分に指定されておらず、RTTごとに1 * MTU以上のcwndの増加を許可しています。
---------
Old text: (Section 7.2.2)
---------
When cwnd is greater than ssthresh, cwnd should be incremented by 1*MTU per RTT if the sender has cwnd or more bytes of data outstanding for the corresponding transport address.
cwndがssthreshより大きい場合、送信者が対応するトランスポートアドレスに対して未処理のデータのcwnd以上のバイトを持っている場合、RTNごとに1 * MTUだけcwndを増やす必要があります。
---------
New text: (Section 7.2.2)
---------
When cwnd is greater than ssthresh, cwnd SHOULD be incremented by 1*MTU per RTT if the sender has cwnd or more bytes of data outstanding for the corresponding transport address. The basic guidelines for incrementing cwnd during congestion avoidance are as follows:
cwndがssthreshより大きい場合、送信者が対応するトランスポートアドレスに対して未処理のデータのcwnd以上のバイトを持っている場合、cwndはRTTごとに1 * MTUだけ増加する必要があります（SHOULD）。輻輳回避中にcwndをインクリメントするための基本的なガイドラインは次のとおりです。
o SCTP MAY increment cwnd by 1*MTU.
o SCTPは、cwndを1 * MTUだけ増分できます（MAY）。
o SCTP SHOULD increment cwnd by 1*MTU once per RTT when the sender has cwnd or more bytes of data outstanding for the corresponding transport address.
o SCTPは、送信者が対応するトランスポートアドレスに対して未処理のデータのcwnd以上のバイト数を持っている場合、RTTごとに1 * MTUずつcwndをインクリメントする必要があります（SHOULD）。
o SCTP MUST NOT increment cwnd by more than 1*MTU per RTT.
o SCTPは、RTTごとに1 * MTUを超えてcwndを増分してはなりません（MUST NOT）。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
---------
Old text: (Section 7.2.2)
---------
o Whenever cwnd is greater than ssthresh, upon each SACK arrival that advances the Cumulative TSN Ack Point, increase partial_bytes_acked by the total number of bytes of all new chunks acknowledged in that SACK including chunks acknowledged by the new Cumulative TSN Ack and by Gap Ack Blocks.
o cwndがssthreshよりも大きい場合は常に、累積TSN Ackポイントを進める各SACKの到着時に、新しい累積TSN AckおよびギャップACKブロックによって確認されたチャンクを含む、そのSACKで確認されたすべての新しいチャンクの合計バイト数によって、partial_bytes_ackedを増やします。
o When partial_bytes_acked is equal to or greater than cwnd and before the arrival of the SACK the sender had cwnd or more bytes of data outstanding (i.e., before arrival of the SACK, flightsize was greater than or equal to cwnd), increase cwnd by MTU, and reset partial_bytes_acked to (partial_bytes_acked - cwnd).
o partial_bytes_ackedがcwnd以上で、SACKの到着前に送信者が未処理のデータのcwnd以上のバイトを持っていた場合（つまり、SACKの到着前に、flightsizeがcwnd以上であった場合）、MTUによってcwndを増やします。そして、partial_bytes_ackedを（partial_bytes_acked-cwnd）にリセットします。
---------
New text: (Section 7.2.2)
---------
o Whenever cwnd is greater than ssthresh, upon each SACK arrival, increase partial_bytes_acked by the total number of bytes of all new chunks acknowledged in that SACK, including chunks acknowledged by the new Cumulative TSN Ack, by Gap Ack Blocks, and by the number of bytes of duplicated chunks reported in Duplicate TSNs.
o cwndがssthreshより大きい場合は常に、SACKが到着するたびに、そのSACKで確認応答されたすべての新しいチャンクの合計バイト数（partial_bytes_acked）を増やします。これには、新しい累積TSN Ack、ギャップ確認ブロック、およびバイト数が確認されたチャンクも含まれます。重複TSNで報告された重複チャンクの数。
o (1) when partial_bytes_acked is greater than cwnd and (2) before the arrival of the SACK the sender had less than cwnd bytes of data outstanding (i.e., before the arrival of the SACK, flightsize was less than cwnd), reset partial_bytes_acked to cwnd.
o （1）partial_bytes_ackedがcwndより大きい場合、および（2）SACKの到着前に、送信者は未処理のデータのcwndバイト未満でした（つまり、SACKの到着前に、flightsizeがcwnd未満でした）、partial_bytes_ackedをcwndにリセットします。 。
o (1) when partial_bytes_acked is equal to or greater than cwnd and (2) before the arrival of the SACK the sender had cwnd or more bytes of data outstanding (i.e., before the arrival of the SACK, flightsize was greater than or equal to cwnd), partial_bytes_acked is reset to (partial_bytes_acked - cwnd). Next, cwnd is increased by 1*MTU.
o （1）partial_bytes_ackedがcwnd以上の場合、および（2）SACKの到着前に送信者がcwnd以上の未処理のデータバイトを持っていた（つまり、SACKの到着前に、flightsizeがcwnd以上であった） ）、partial_bytes_ackedは（partial_bytes_acked-cwnd）にリセットされます。次に、cwndが1 * MTUずつ増加します。
This text has been modified by multiple errata. It includes modifications from Sections 3.12 and 3.22. It is in final form and is not further updated in this document.
This text has been modified by multiple errata. It includes modifications from Sections 3.12 and 3.22. It is in final form and is not further updated in this document.
The basic guidelines for incrementing cwnd during the congestion avoidance phase are added into Section 7.2.2. The guidelines include the normative language and are aligned with [RFC5681].
輻輳回避フェーズ中にcwndをインクリメントするための基本的なガイドラインは、セクション7.2.2に追加されています。ガイドラインは規範的な言語を含み、[RFC5681]に沿っています。
The algorithm from Section 7.2.2 is improved and now does not allow increasing cwnd by more than 1*MTU per RTT.
セクション7.2.2のアルゴリズムが改善され、RTTごとに1 * MTUを超えるcwndの増加が許可されなくなりました。
[RFC4960] prescribes that cwnd per RTO be adjusted if the endpoint does not transmit data on a given transport address. In addition to that, it prescribes that cwnd be set to the initial value after a sufficiently long idle period. The latter is excessive. Moreover, what is considered a sufficiently long idle period is unclear.
[RFC4960]は、エンドポイントが特定のトランスポートアドレスでデータを送信しない場合、RTOごとのcwndを調整することを規定しています。それに加えて、十分に長いアイドル期間の後、cwndを初期値に設定するように規定しています。後者は過剰です。さらに、十分に長いアイドル期間と見なされるものは不明確です。
[RFC4960] doesn't specify the handling of ssthresh in the idle case. If ssthresh is reduced due to packet loss, ssthresh is never recovered. So, traffic can end up in congestion avoidance all the time, resulting in a low sending rate and bad performance. The problem is even more serious for SCTP: in a multi-homed SCTP association, traffic that switches back to the previously failed primary path will also lead to the situation where traffic ends up in congestion avoidance.
[RFC4960]は、アイドル状態の場合のssthreshの処理を指定していません。パケット損失が原因でssthreshが減少した場合、ssthreshは回復されません。したがって、トラフィックは常に輻輳回避になる可能性があり、送信レートが低くなり、パフォーマンスが低下します。 SCTPの問題はさらに深刻です。マルチホームSCTPアソシエーションでは、以前に失敗したプライマリパスにスイッチバックするトラフィックも、トラフィックが輻輳回避になるという状況につながります。
---------
Old text: (Section 7.2.1)
---------
o The initial cwnd before DATA transmission or after a sufficiently long idle period MUST be set to min(4*MTU, max (2*MTU, 4380 bytes)).
o The initial cwnd before DATA transmission or after a sufficiently long idle period MUST be set to min(4*MTU, max (2*MTU, 4380 bytes)).
---------
New text: (Section 7.2.1)
---------
o The initial cwnd before data transmission MUST be set to min(4*MTU, max (2*MTU, 4380 bytes)).
o データ送信前の初期cwndは、min（4 * MTU、max（2 * MTU、4380バイト））に設定する必要があります。
---------
Old text: (Section 7.2.1)
---------
o When the endpoint does not transmit data on a given transport address, the cwnd of the transport address should be adjusted to max(cwnd/2, 4*MTU) per RTO.
o エンドポイントが特定のトランスポートアドレスでデータを送信しない場合、トランスポートアドレスのcwndをRTOごとにmax（cwnd / 2、4 * MTU）に調整する必要があります。
---------
New text: (Section 7.2.1)
---------
o While the endpoint does not transmit data on a given transport address, the cwnd of the transport address SHOULD be adjusted to max(cwnd/2, 4*MTU) once per RTO. Before the first cwnd adjustment, the ssthresh of the transport address SHOULD be set to the cwnd.
o エンドポイントは特定のトランスポートアドレスでデータを送信しませんが、トランスポートアドレスのcwndは、RTOごとに1回、max（cwnd / 2、4 * MTU）に調整する必要があります（SHOULD）。最初のcwnd調整の前に、トランスポートアドレスのssthreshをcwndに設定する必要があります（SHOULD）。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
A rule about cwnd adjustment after a sufficiently long idle period is removed.
十分に長いアイドル期間後のcwnd調整に関するルールが削除されました。
The text is updated to describe the handling of ssthresh. When the idle period is detected, the cwnd value is copied to ssthresh.
ssthreshの処理を説明するためにテキストが更新されました。アイドル期間が検出されると、cwnd値がssthreshにコピーされます。
The sending of SACK chunks for window updates is only indirectly referenced in Section 6.2 of [RFC4960], which states that an SCTP receiver must not generate more than one SACK for every incoming packet, other than to update the offered window.
ウィンドウ更新用のSACKチャンクの送信は、[RFC4960]のセクション6.2で間接的にのみ参照されています。これは、提供されたウィンドウを更新する場合を除いて、SCTP受信者がすべての着信パケットに対して複数のSACKを生成してはならないことを述べています。
However, to avoid performance problems, it is necessary to send the window updates when the receiver window opens up.
ただし、パフォーマンスの問題を回避するには、レシーバーウィンドウが開いたときにウィンドウの更新を送信する必要があります。
---------
Old text: (Section 6.2)
---------
An SCTP receiver MUST NOT generate more than one SACK for every incoming packet, other than to update the offered window as the receiving application consumes new data.
SCTP受信機は、受信アプリケーションが新しいデータを消費するときに提供されたウィンドウを更新する以外に、すべての着信パケットに対して複数のSACKを生成してはなりません（MUST NOT）。
---------
New text: (Section 6.2)
---------
An SCTP receiver MUST NOT generate more than one SACK for every incoming packet, other than to update the offered window as the receiving application consumes new data. When the window opens up, an SCTP receiver SHOULD send additional SACK chunks to update the window even if no new data is received. The receiver MUST avoid sending a large number of window updates -- in particular, large bursts of them. One way to achieve this is to send a window update only if the window can be increased by at least a quarter of the receive buffer size of the association.
SCTP受信機は、受信アプリケーションが新しいデータを消費するときに提供されたウィンドウを更新する以外に、すべての着信パケットに対して複数のSACKを生成してはなりません（MUST NOT）。ウィンドウが開いたら、SCTPレシーバーは新しいSACKチャンクを送信して、新しいデータを受信しなくてもウィンドウを更新する必要があります（SHOULD）。受信者は、多数のウィンドウ更新（特に、それらの大量のバースト）を送信しないようにする必要があります。これを実現する1つの方法は、ウィンドウがアソシエーションの受信バッファーサイズの少なくとも4分の1だけ増加できる場合にのみ、ウィンドウ更新を送信することです。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
The new text makes it clear that additional SACK chunks for window updates should be sent as long as excessive bursts are avoided.
新しいテキストでは、過度のバーストが回避されている限り、ウィンドウ更新用の追加のSACKチャンクを送信する必要があることが明確になっています。
Section 6.4 of [RFC4960] describes the transmission policy for multi-homed SCTP endpoints. However, this policy has the following issues:
[RFC4960]のセクション6.4では、マルチホームSCTPエンドポイントの送信ポリシーについて説明しています。ただし、このポリシーには次の問題があります。
o It states that a SACK should be sent to the source address of an incoming DATA. However, it is known that other SACK policies (e.g., always sending SACKs to the primary path) may be more beneficial in some situations.
o これは、SACKを着信DATAのソースアドレスに送信する必要があることを示しています。ただし、状況によっては、他のSACKポリシー（たとえば、常にプライマリパスにSACKを送信する）の方が有益な場合があることがわかっています。
o Also, it initially states that an endpoint should always transmit DATA chunks to the primary path but then states that the rule for the transmittal of reply chunks should also be followed if the endpoint is bundling DATA chunks together with the reply chunk. The second statement contradicts the first statement. Some implementations were having problems with it and sent DATA chunks bundled with reply chunks to a different destination address than the primary path, causing many gaps.
o また、最初はエンドポイントが常にDATAチャンクをプライマリパスに送信する必要があると述べていますが、エンドポイントがDATAチャンクを応答チャンクと一緒にバンドルしている場合は、応答チャンクの送信のルールにも従う必要があると述べています。 2番目のステートメントは、最初のステートメントと矛盾します。一部の実装では問題があり、応答チャンクにバンドルされたDATAチャンクをプライマリパスとは異なる宛先アドレスに送信したため、多くのギャップが生じていました。
---------
Old text: (Section 6.4)
---------
An endpoint SHOULD transmit reply chunks (e.g., SACK, HEARTBEAT ACK, etc.) to the same destination transport address from which it received the DATA or control chunk to which it is replying. This rule should also be followed if the endpoint is bundling DATA chunks together with the reply chunk.
エンドポイントは、応答チャンク（SACK、HEARTBEAT ACKなど）を、DATAの受信元と同じ宛先トランスポートアドレスまたは応答先の制御チャンクに送信する必要があります（SHOULD）。エンドポイントが応答チャンクと一緒にDATAチャンクをバンドルしている場合も、このルールに従う必要があります。
However, when acknowledging multiple DATA chunks received in packets from different source addresses in a single SACK, the SACK chunk may be transmitted to one of the destination transport addresses from which the DATA or control chunks being acknowledged were received.
ただし、単一のSACKで異なる送信元アドレスからパケットで受信された複数のDATAチャンクを確認する場合、SACKチャンクは、確認中のDATAまたは制御チャンクが送信された宛先トランスポートアドレスの1つに送信されることがあります。
---------
New text: (Section 6.4)
---------
An endpoint SHOULD transmit reply chunks (e.g., INIT ACK, COOKIE ACK, HEARTBEAT ACK) in response to control chunks to the same destination transport address from which it received the control chunk to which it is replying.
エンドポイントは、制御チャンクへの応答として、応答チャンクを受け取った元のトランスポートアドレスと同じ宛先トランスポートアドレスに応答チャンク（INIT ACK、COOKIE ACK、HEARTBEAT ACKなど）を送信する必要があります（SHOULD）。
The selection of the destination transport address for packets containing SACK chunks is implementation dependent. However, an endpoint SHOULD NOT vary the destination transport address of a SACK when it receives DATA chunks coming from the same source address.
SACKチャンクを含むパケットの宛先トランスポートアドレスの選択は、実装によって異なります。ただし、エンドポイントは、同じ送信元アドレスからのDATAチャンクを受信したときに、SACKの宛先トランスポートアドレスを変更してはなりません（SHOULD NOT）。
When acknowledging multiple DATA chunks received in packets from different source addresses in a single SACK, the SACK chunk MAY be transmitted to one of the destination transport addresses from which the DATA or control chunks being acknowledged were received.
単一のSACKで異なる送信元アドレスからパケットで受信された複数のDATAチャンクを確認する場合、SACKチャンクは、確認中のDATAまたは制御チャンクが送信された宛先トランスポートアドレスの1つに送信される場合があります。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
The SACK transmission policy is left implementation dependent, but the new text now specifies that the policy not vary the destination address of a packet containing a SACK chunk unless there are reasons for not doing so, as varying the destination address may negatively impact RTT measurement.
SACK送信ポリシーは実装に依存しますが、新しいテキストでは、ポリシーがSACKチャンクを含むパケットの宛先アドレスを変更しないことを指定しています。理由がない限り、宛先アドレスを変更するとRTT測定に悪影響を与える可能性があります。
New text removes a confusing statement that prescribes following the rule for transmittal of reply chunks when the endpoint is bundling DATA chunks together with the reply chunk.
新しいテキストは、エンドポイントがDATAチャンクを応答チャンクと一緒にバンドルしているときに、応答チャンクの送信に関する規則に従うことを規定する混乱するステートメントを削除します。
[RFC4960] uses the key terms "outstanding data", "flightsize", and "data in flight" in formulas and statements, but Section 1.3 ("Key Terms") of [RFC4960] does not provide their definitions. Furthermore, outstanding data does not include DATA chunks that are classified as lost but that have not yet been retransmitted, and there is a paragraph in Section 6.1 of [RFC4960] where this statement is broken.
[RFC4960]は、公式およびステートメントで「未処理データ」、「フライトサイズ」、および「飛行中のデータ」という主要な用語を使用していますが、[RFC4960]のセクション1.3（「主要な用語」）はそれらの定義を提供していません。さらに、未処理のデータには、失われたと分類されているが、まだ再送信されていないDATAチャンクは含まれていません。[RFC4960]のセクション6.1に、このステートメントが壊れている段落があります。
---------
Old text: (Section 1.3)
---------
o Congestion window (cwnd): An SCTP variable that limits the data, in number of bytes, a sender can send to a particular destination transport address before receiving an acknowledgement.
o 輻輳ウィンドウ（cwnd）：データをバイト数で制限するSCTP変数。送信者は、確認応答を受信する前に特定の宛先トランスポートアドレスに送信できます。
...
。。。
o Outstanding TSN (at an SCTP endpoint): A TSN (and the associated DATA chunk) that has been sent by the endpoint but for which it has not yet received an acknowledgement.
o 未処理のTSN（SCTPエンドポイント）：エンドポイントから送信されたが、まだ確認応答を受け取っていないTSN（および関連するDATAチャンク）。
---------
New text: (Section 1.3)
---------
o Congestion window (cwnd): An SCTP variable that limits outstanding data, in number of bytes, that a sender can send to a particular destination transport address before receiving an acknowledgement.
o 輻輳ウィンドウ（cwnd）：送信者が確認応答を受信する前に特定の宛先トランスポートアドレスに送信できる未処理のデータをバイト数で制限するSCTP変数。
...
。。。
o Flightsize: The amount of bytes of outstanding data to a particular destination transport address at any given time.
o フライトサイズ：ある時点での特定の宛先トランスポートアドレスへの未処理データのバイト数。
...
。。。
o Outstanding data (or "data outstanding" or "data in flight"): The total amount of the DATA chunks associated with outstanding TSNs. A retransmitted DATA chunk is counted once in outstanding data. A DATA chunk that is classified as lost but that has not yet been retransmitted is not in outstanding data.
o 未処理のデータ（または「未処理のデータ」または「処理中のデータ」）：未処理のTSNに関連付けられたDATAチャンクの合計量。再送信されたDATAチャンクは、未処理のデータで1回カウントされます。失われたと分類されているが、まだ再送信されていないDATAチャンクは、未処理のデータにはありません。
o Outstanding TSN (at an SCTP endpoint): A TSN (and the associated DATA chunk) that has been sent by the endpoint but for which it has not yet received an acknowledgement.
o 未処理のTSN（SCTPエンドポイント）：エンドポイントから送信されたが、まだ確認応答を受け取っていないTSN（および関連するDATAチャンク）。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
---------
Old text: (Section 6.1)
---------
C) When the time comes for the sender to transmit, before sending new DATA chunks, the sender MUST first transmit any outstanding DATA chunks that are marked for retransmission (limited by the current cwnd).
C）送信者が送信する時間になると、新しいDATAチャンクを送信する前に、送信者は最初に再送信のマークが付けられている未処理のDATAチャンクを送信する必要があります（現在のcwndによって制限されます）。
---------
New text: (Section 6.1)
---------
C) When the time comes for the sender to transmit, before sending new DATA chunks, the sender MUST first transmit any DATA chunks that are marked for retransmission (limited by the current cwnd).
C）送信者が送信する時間になると、新しいDATAチャンクを送信する前に、送信者は最初に再送信（現在のcwndによって制限される）としてマークされているDATAチャンクを送信する必要があります。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
Section 1.3 is corrected to include explanations of the key terms "outstanding data", "data in flight", and "flightsize". Section 6.1 is corrected to now use "any DATA chunks" instead of "any outstanding DATA chunks".
セクション1.3は、「未処理のデータ」、「飛行中のデータ」、および「フライトサイズ」という主要な用語の説明を含むように修正されています。セクション6.1が修正され、「未処理のDATAチャンク」の代わりに「任意のDATAチャンク」が使用されるようになりました。
Some implementations were experiencing a degradation of cwnd because of the Max.Burst limit. This was due to misinterpretation of the suggestion in Section 6.1 of [RFC4960] regarding how to use the Max.Burst parameter when calculating the number of packets to transmit.
Max.Burst制限のために、一部の実装でcwndの低下が発生していました。これは、送信するパケット数を計算する際のMax.Burstパラメータの使用方法に関する、[RFC4960]のセクション6.1の提案の誤解が原因でした。
---------
Old text: (Section 6.1)
---------
D) When the time comes for the sender to transmit new DATA chunks, the protocol parameter Max.Burst SHOULD be used to limit the number of packets sent. The limit MAY be applied by adjusting cwnd as follows:
D）送信者が新しいDATAチャンクを送信する時間になると、プロトコルパラメーターMax.Burstを使用して、送信されるパケットの数を制限する必要があります。この制限は、cwndを次のように調整することで適用できます（MAY）。
if((flightsize + Max.Burst*MTU) < cwnd) cwnd = flightsize +
Max.Burst*MTU
Or it MAY be applied by strictly limiting the number of packets emitted by the output routine.
または、出力ルーチンによって送信されるパケットの数を厳密に制限することで適用できます。
---------
New text: (Section 6.1)
---------
D) When the time comes for the sender to transmit new DATA chunks, the protocol parameter Max.Burst SHOULD be used to limit the number of packets sent. The limit MAY be applied by adjusting cwnd temporarily, as follows:
D）送信者が新しいDATAチャンクを送信する時間になると、プロトコルパラメーターMax.Burstを使用して、送信されるパケットの数を制限する必要があります。制限は、次のようにcwndを一時的に調整することで適用できます（MAY）。
if ((flightsize + Max.Burst*MTU) < cwnd)
cwnd = flightsize + Max.Burst*MTU
Or, it MAY be applied by strictly limiting the number of packets emitted by the output routine. When calculating the number of packets to transmit, and particularly when using the formula above, cwnd SHOULD NOT be changed permanently.
または、出力ルーチンが発行するパケットの数を厳密に制限することで適用できます。送信するパケット数を計算するとき、特に上記の式を使用するときは、cwndを永続的に変更しないでください。
This text is in final form and is not further updated in this document.
This text is in final form and is not further updated in this document.
The new text clarifies that cwnd should not be changed when applying the Max.Burst limit. This mitigates packet bursts related to the reception of SACK chunks but not bursts related to an application sending a burst of user messages.
新しいテキストでは、Max.Burst制限を適用するときにcwndを変更してはならないことが明記されています。これにより、SACKチャンクの受信に関連するパケットバーストは軽減されますが、ユーザーメッセージのバーストを送信するアプリケーションに関連するバーストは軽減されません。
[RFC4960] uses 3 seconds as the default value for RTO.Initial in accordance with Section 4.2.3.1 of [RFC1122]. [RFC6298] updates [RFC1122] and lowers the initial value of the retransmission timer from 3 seconds to 1 second.
[RFC4960] uses 3 seconds as the default value for RTO.Initial in accordance with Section 4.2.3.1 of [RFC1122]. [RFC6298] updates [RFC1122] and lowers the initial value of the retransmission timer from 3 seconds to 1 second.
---------
Old text: (Section 15)
---------
The following protocol parameters are RECOMMENDED:
次のプロトコルパラメータを推奨します。
RTO.Initial - 3 seconds
RTO.Min - 1 second
RTO.Max - 60 seconds
Max.Burst - 4
RTO.Alpha - 1/8
RTO.Beta - 1/4
Valid.Cookie.Life - 60 seconds
Association.Max.Retrans - 10 attempts
Path.Max.Retrans - 5 attempts (per destination address)
Max.Init.Retransmits - 8 attempts
HB.interval - 30 seconds
HB.Max.Burst - 1
---------
New text: (Section 15)
---------
The following protocol parameters are RECOMMENDED:
次のプロトコルパラメータを推奨します。
RTO.Initial: 1 second
RTO.Min: 1 second
RTO.Max: 60 seconds
Max.Burst: 4
RTO.Alpha: 1/8
RTO.Beta: 1/4
Valid.Cookie.Life: 60 seconds
Association.Max.Retrans: 10 attempts
Path.Max.Retrans: 5 attempts (per destination address)
Max.Init.Retransmits: 8 attempts
HB.interval: 30 seconds
HB.Max.Burst: 1
SACK.Delay: 200 milliseconds
This text has been modified by multiple errata. It includes modifications from Section 3.24. It is in final form and is not further updated in this document.
このテキストは、複数のエラッタによって変更されています。セクション3.24からの変更が含まれます。これは最終的な形式であり、このドキュメントではこれ以上更新されません。
The default value for RTO.Initial has been lowered to 1 second to be in tune with [RFC6298].
RTO.Initialのデフォルト値は[RFC6298]と調和するように1秒に引き下げられました。
When an SCTP endpoint receives a DATA chunk with an invalid stream identifier, it shall acknowledge it by sending a SACK chunk and indicate that the stream identifier was invalid by sending an ERROR chunk. These two chunks may be bundled. However, in the case of bundling, [RFC4960] requires that the ERROR chunk follow the SACK chunk. This restriction regarding the ordering of the chunks is not necessary and might limit interoperability.
SCTPエンドポイントは、無効なストリーム識別子を持つDATAチャンクを受信すると、SACKチャンクを送信してそれを確認し、ERRORチャンクを送信してストリーム識別子が無効であることを示します。これらの2つのチャンクはバンドルされる場合があります。しかしながら、バンドリングの場合、[RFC4960]はERRORチャンクがSACKチャンクに続くことを要求します。チャンクの順序に関するこの制限は不要であり、相互運用性を制限する可能性があります。
---------
Old text: (Section 6.5)
---------
Every DATA chunk MUST carry a valid stream identifier. If an endpoint receives a DATA chunk with an invalid stream identifier, it shall acknowledge the reception of the DATA chunk following the normal procedure, immediately send an ERROR chunk with cause set to "Invalid Stream Identifier" (see Section 3.3.10), and discard the DATA chunk. The endpoint may bundle the ERROR chunk in the same packet as the SACK as long as the ERROR follows the SACK.
すべてのDATAチャンクは、有効なストリーム識別子を運ぶ必要があります。エンドポイントが無効なストリーム識別子を持つDATAチャンクを受信した場合、エンドポイントは通常の手順に従ってDATAチャンクの受信を承認し、原因を「無効なストリーム識別子」に設定したERRORチャンクを直ちに送信します（セクション3.3.10を参照）。 DATAチャンクを破棄します。エンドポイントは、ERRORがSACKに続く限り、ERRORチャンクをSACKと同じパケットにバンドルできます。
---------
New text: (Section 6.5)
---------
Every DATA chunk MUST carry a valid stream identifier. If an endpoint receives a DATA chunk with an invalid stream identifier, it SHOULD acknowledge the reception of the DATA chunk following the normal procedure, immediately send an ERROR chunk with cause set to "Invalid Stream Identifier" (see Section 3.3.10), and discard the DATA chunk. The endpoint MAY bundle the ERROR chunk and the SACK chunk in the same packet.
すべてのDATAチャンクは、有効なストリーム識別子を運ぶ必要があります。エンドポイントが無効なストリーム識別子を持つDATAチャンクを受信した場合、エンドポイントは通常の手順に従ってDATAチャンクの受信を確認し、原因を「無効なストリーム識別子」に設定したERRORチャンクを直ちに送信する必要があります（セクション3.3.10を参照）。 DATAチャンクを破棄します。エンドポイントは、ERRORチャンクとSACKチャンクを同じパケットにバンドルしてもよい（MAY）。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
The unnecessary restriction regarding the ordering of the SACK and ERROR chunks has been removed.
SACKおよびERRORチャンクの順序に関する不要な制限が削除されました。
[RFC4960] provides a description of an abstract API. In the definition of the RECEIVE primitive, an optional parameter with name "delivery number" is mentioned. However, no definition of this parameter is given in [RFC4960], and the parameter is unnecessary.
[RFC4960]は、抽象APIの説明を提供します。 RECEIVEプリミティブの定義では、「配送番号」という名前のオプションのパラメーターが言及されています。ただし、このパラメーターの定義は[RFC4960]で指定されておらず、パラメーターは不要です。
---------
Old text: (Section 10.1 G))
---------
G) Receive
G）受け取る
Format: RECEIVE(association id, buffer address, buffer size [,stream id]) -> byte count [,transport address] [,stream id] [,stream sequence number] [,partial flag] [,delivery number] [,payload protocol-id]
形式：RECEIVE（関連付けID、バッファアドレス、バッファサイズ[、ストリームID]）->バイトカウント[、トランスポートアドレス] [、ストリームID] [、ストリームシーケンス番号] [、部分的なフラグ] [、配信番号] [、ペイロードプロトコルID]
---------
New text: (Section 10.1 G))
---------
G) Receive
G）受け取る
Format: RECEIVE(association id, buffer address, buffer size [,stream id]) -> byte count [,transport address] [,stream id] [,stream sequence number] [,partial flag] [,payload protocol-id]
形式：RECEIVE（関連付けID、バッファアドレス、バッファサイズ[、ストリームID]）->バイトカウント[、トランスポートアドレス] [、ストリームID] [、ストリームシーケンス番号] [、部分的なフラグ] [、ペイロードプロトコルID]
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
The undefined parameter has been removed.
未定義のパラメーターは削除されました。
The upper layer can change the Differentiated Services Code Point (DSCP) used for packets being sent. Changing the DSCP can result in packets hitting different queues on the path. Therefore, congestion control should be initialized when the DSCP is changed by the upper layer. This is not described in [RFC4960].
上位層は、送信されるパケットに使用されるDiffServコードポイント（DSCP）を変更できます。 DSCPを変更すると、パケットがパス上の異なるキューにヒットする可能性があります。したがって、上位層によってDSCPが変更されたときに、輻輳制御を初期化する必要があります。これは[RFC4960]で説明されていません。
---------
New text: (Section 7.2.5)
---------
7.2.5. Making Changes to Differentiated Services Code Points
7.2.5. DiffServコードポイントの変更
SCTP implementations MAY allow an application to configure the Differentiated Services Code Point (DSCP) used for sending packets. If a DSCP change might result in outgoing packets being queued in different queues, the congestion control parameters for all affected destination addresses MUST be reset to their initial values.
SCTP実装により、アプリケーションは、パケットの送信に使用されるDiffServコードポイント（DSCP）を構成できます。 DSCPの変更により、送信パケットが異なるキューにキューイングされる可能性がある場合は、影響を受けるすべての宛先アドレスの輻輳制御パラメーターを初期値にリセットする必要があります。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
---------
Old text: (Section 10.1 M))
---------
Mandatory attributes:
必須の属性：
o association id - local handle to the SCTP association.
o Association id-SCTPアソシエーションへのローカルハンドル。
o protocol parameter list - the specific names and values of the protocol parameters (e.g., Association.Max.Retrans; see Section 15) that the SCTP user wishes to customize.
o プロトコルパラメータリスト-SCTPユーザーがカスタマイズするプロトコルパラメータ（Association.Max.Retransなど）の特定の名前と値（セクション15を参照）。
---------
New text: (Section 10.1 M))
---------
Mandatory attributes:
必須の属性：
o association id - local handle to the SCTP association.
o Association id-SCTPアソシエーションへのローカルハンドル。
o protocol parameter list - the specific names and values of the protocol parameters (e.g., Association.Max.Retrans (see Section 15), or other parameters like the DSCP) that the SCTP user wishes to customize.
o プロトコルパラメータリスト-SCTPユーザーがカスタマイズするプロトコルパラメータの特定の名前と値（Association.Max.Retrans（セクション15を参照）、またはDSCPなどの他のパラメータ）。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
Text describing the required action for DSCP changes has been added.
DSCP変更に必要なアクションを説明するテキストが追加されました。
Appendix C of [RFC4960] describes the handling of ICMPv4 and ICMPv6 messages. The handling of ICMP messages indicating that the port number is unreachable, as described in the enumerated procedures, is not consistent with the description given in [RFC4960] after the procedures. Furthermore, the text explicitly describes the handling of ICMPv6 packets indicating reachability problems but does not do the same for the corresponding ICMPv4 packets.
[RFC4960]の付録Cでは、ICMPv4およびICMPv6メッセージの処理について説明しています。列挙された手順で説明されているように、ポート番号が到達不能であることを示すICMPメッセージの処理は、手順の後の[RFC4960]で与えられた説明と一致していません。さらに、テキストは、到達可能性の問題を示すICMPv6パケットの処理を明示的に説明しますが、対応するICMPv4パケットについては同じことを行いません。
---------
Old text: (Appendix C)
---------
ICMP3) An implementation MAY ignore any ICMPv4 messages where the code does not indicate "Protocol Unreachable" or "Fragmentation Needed".
ICMP3）コードが「プロトコル到達不能」または「断片化が必要」を示さない場合、実装はICMPv4メッセージを無視してもよい（MAY）。
---------
New text: (Appendix C)
---------
ICMP3) An implementation SHOULD ignore any ICMP messages where the code indicates "Port Unreachable".
ICMP3）実装は、コードが「Port Unreachable」を示しているICMPメッセージを無視する必要があります（SHOULD）。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
---------
Old text: (Appendix C)
---------
ICMP9) If the ICMPv6 code is "Destination Unreachable", the implementation MAY mark the destination into the unreachable state or alternatively increment the path error counter.
ICMP9）ICMPv6コードが「Destination Unreachable」の場合、実装は宛先を到達不能状態にマークするか、パスエラーカウンターをインクリメントできます（MAY）。
---------
New text: (Appendix C)
---------
ICMP9) If the ICMP type is "Destination Unreachable", the implementation MAY move the destination to the unreachable state or, alternatively, increment the path error counter.
ICMP9）ICMPタイプが「Destination Unreachable」の場合、実装は宛先を到達不能状態に移動するか、パスエラーカウンターをインクリメントできます（MAY）。
This text has been modified by multiple errata. It is further updated in Section 3.37.
このテキストは、複数のエラッタによって変更されています。セクション3.37でさらに更新されます。
The text has been changed to describe the intended handling of ICMP messages indicating that the port number is unreachable by replacing the third rule. Also, the limitation to ICMPv6 in the ninth rule has been removed.
The text has been changed to describe the intended handling of ICMP messages indicating that the port number is unreachable by replacing the third rule. Also, the limitation to ICMPv6 in the ninth rule has been removed.
[RFC1122] defines the handling of soft errors and hard errors for TCP. Appendix C of [RFC4960] only deals with hard errors.
[RFC1122]は、TCPのソフトエラーとハードエラーの処理を定義します。 [RFC4960]の付録Cはハードエラーのみを扱います。
---------
Old text: (Appendix C)
---------
ICMP9) If the ICMPv6 code is "Destination Unreachable", the implementation MAY mark the destination into the unreachable state or alternatively increment the path error counter.
ICMP9）ICMPv6コードが「Destination Unreachable」の場合、実装は宛先を到達不能状態にマークするか、パスエラーカウンターをインクリメントできます（MAY）。
---------
New text: (Appendix C)
---------
ICMP9) If the ICMP type is "Destination Unreachable", the implementation MAY move the destination to the unreachable state or, alternatively, increment the path error counter. SCTP MAY provide information to the upper layer indicating the reception of ICMP messages when reporting a network status change.
ICMP9) If the ICMP type is "Destination Unreachable", the implementation MAY move the destination to the unreachable state or, alternatively, increment the path error counter. SCTP MAY provide information to the upper layer indicating the reception of ICMP messages when reporting a network status change.
This text has been modified by multiple errata. It includes modifications from Section 3.36. It is in final form and is not further updated in this document.
このテキストは、複数のエラッタによって変更されています。セクション3.36からの変更が含まれます。これは最終的な形式であり、このドキュメントではこれ以上更新されません。
Text has been added allowing SCTP to notify the application in the case of soft errors.
テキストが追加され、ソフトエラーの場合にSCTPがアプリケーションに通知できるようになりました。
When using the slow start algorithm, SCTP increases the congestion window only when it is being fully utilized. Since SCTP uses DATA chunks and does not use the congestion window to fragment user messages, this requires that some overbooking of the congestion window be allowed.
スロースタートアルゴリズムを使用する場合、SCTPは、それが完全に利用されている場合にのみ輻輳ウィンドウを増やします。 SCTPはDATAチャンクを使用し、輻輳ウィンドウを使用してユーザーメッセージをフラグメント化しないため、輻輳ウィンドウのオーバーブッキングを許可する必要があります。
---------
Old text: (Section 6.1)
---------
B) At any given time, the sender MUST NOT transmit new data to a given transport address if it has cwnd or more bytes of data outstanding to that transport address.
B）常に、送信者がそのトランスポートアドレスに対して未処理のデータのcwnd以上のバイトを持っている場合、そのトランスポートアドレスに新しいデータを送信してはなりません。
---------
New text: (Section 6.1)
---------
B) At any given time, the sender MUST NOT transmit new data to a given transport address if it has cwnd + (PMTU - 1) or more bytes of data outstanding to that transport address. If data is available, the sender SHOULD exceed cwnd by up to (PMTU - 1) bytes on a new data transmission if the flightsize does not currently reach cwnd. The breach of cwnd MUST constitute one packet only.
B）ある時点で、送信者は、そのトランスポートアドレスに対して未処理のデータのcwnd +（PMTU-1）以上のバイトがある場合、そのトランスポートアドレスに新しいデータを送信してはなりません。データが利用可能な場合、flightsizeが現在cwndに到達していない場合、新しいデータ送信で送信者は最大で（PMTU-1）バイトだけcwndを超える必要があります（SHOULD）。 cwndの違反は、1つのパケットのみを構成する必要があります。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
---------
Old text: (Section 7.2.1)
---------
o Whenever cwnd is greater than zero, the endpoint is allowed to have cwnd bytes of data outstanding on that transport address.
o cwndがゼロより大きい場合は常に、エンドポイントはそのトランスポートアドレスで未処理のデータのcwndバイトを持つことができます。
---------
New text: (Section 7.2.1)
---------
o Whenever cwnd is greater than zero, the endpoint is allowed to have cwnd bytes of data outstanding on that transport address. A limited overbooking as described in Section 6.1 B) SHOULD be supported.
o cwndがゼロより大きい場合は常に、エンドポイントはそのトランスポートアドレスで未処理のデータのcwndバイトを持つことができます。セクション6.1 B）で説明されている限定的なオーバーブッキングがサポートされている必要があります。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
Text was added to clarify how the cwnd limit should be handled.
cwnd制限の処理方法を明確にするために、テキストが追加されました。
The text in Section 6.1 of [RFC4960] that describes zero window probing does not clearly address the case where the window is not zero but is too small for the next DATA chunk to be transmitted. Even in this case, zero window probing has to be performed to avoid deadlocks.
[RFC4960]のセクション6.1のゼロウィンドウプローブについての説明は、ウィンドウがゼロではないが次のDATAチャンクを送信するには小さすぎる場合を明確に扱っていません。この場合でも、デッドロックを回避するためにゼロウィンドウプローブを実行する必要があります。
---------
Old text: (Section 6.1)
---------
A) At any given time, the data sender MUST NOT transmit new data to any destination transport address if its peer's rwnd indicates that the peer has no buffer space (i.e., rwnd is 0; see Section 6.2.1). However, regardless of the value of rwnd (including if it is 0), the data sender can always have one DATA chunk in flight to the receiver if allowed by cwnd (see rule B, below). This rule allows the sender to probe for a change in rwnd that the sender missed due to the SACK's having been lost in transit from the data receiver to the data sender.
A）ピアのrwndがピアにバッファスペースがないことを示している場合（rwndが0、セクション6.2.1を参照）、データ送信者は常に新しいデータを宛先トランスポートアドレスに送信してはなりません（MUST NOT）。ただし、rwndの値に関係なく（0の場合も含む）、cwndで許可されている場合、データ送信者は常に1つのDATAチャンクを受信者に送信できます（以下のルールBを参照）。このルールにより、送信者は、データ受信者からデータ送信者への転送中にSACKが失われたために送信者が見逃したrwndの変更をプローブできます。
When the receiver's advertised window is zero, this probe is called a zero window probe. Note that a zero window probe SHOULD only be sent when all outstanding DATA chunks have been cumulatively acknowledged and no DATA chunks are in flight. Zero window probing MUST be supported.
レシーバーのアドバタイズされたウィンドウがゼロの場合、このプローブはゼロウィンドウプローブと呼ばれます。ゼロウィンドウプローブは、未解決のDATAチャンクがすべて累積的に確認され、DATAチャンクが実行されていない場合にのみ送信する必要があることに注意してください。ゼロウィンドウプローブをサポートする必要があります。
---------
New text: (Section 6.1)
---------
A) At any given time, the data sender MUST NOT transmit new data to any destination transport address if its peer's rwnd indicates that the peer has no buffer space (i.e., rwnd is smaller than the size of the next DATA chunk; see Section 6.2.1). However, regardless of the value of rwnd (including if it is 0), the data sender can always have one DATA chunk in flight to the receiver if allowed by cwnd (see rule B, below). This rule allows the sender to probe for a change in rwnd that the sender missed due to the SACK's having been lost in transit from the data receiver to the data sender.
A）ピアのrwndがピアにバッファスペースがないことを示している場合（つまり、rwndが次のDATAチャンクのサイズよりも小さい場合）、データ送信者は常に新しいデータを宛先トランスポートアドレスに送信してはなりません（セクション6.2を参照）。 .1）。ただし、rwndの値に関係なく（0の場合も含む）、cwndで許可されている場合、データ送信者は常に1つのDATAチャンクを受信者に送信できます（以下のルールBを参照）。このルールにより、送信者は、データ受信者からデータ送信者への転送中にSACKが失われたために送信者が見逃したrwndの変更をプローブできます。
When the receiver has no buffer space, this probe is called a zero window probe. Note that a zero window probe SHOULD only be sent when all outstanding DATA chunks have been cumulatively acknowledged and no DATA chunks are in flight. Zero window probing MUST be supported.
レシーバーにバッファースペースがない場合、このプローブはゼロウィンドウプローブと呼ばれます。ゼロウィンドウプローブは、未解決のDATAチャンクがすべて累積的に確認され、DATAチャンクが実行されていない場合にのみ送信する必要があることに注意してください。ゼロウィンドウプローブをサポートする必要があります。
This text is in final form and is not further updated in this document.
This text is in final form and is not further updated in this document.
The terminology is used in a cleaner way.
The terminology is used in a cleaner way.
For Explicit Congestion Notification (ECN), [RFC4960] refers only to [RFC3168], which has been updated by [RFC8311]. This needs to be reflected in the text when referring to ECN.
明示的輻輳通知（ECN）の場合、[RFC4960]は[RFC8311]によって更新された[RFC3168]のみを参照します。これは、ECNを参照するときにテキストに反映する必要があります。
---------
Old text: (Appendix A)
---------
ECN [RFC3168] describes a proposed extension to IP that details a method to become aware of congestion outside of datagram loss.
ECN [RFC3168]は、IPへの提案された拡張について説明しており、データグラムの損失以外に輻輳を認識できるようにする方法を詳しく説明しています。
---------
New text: (Appendix A)
---------
ECN as specified in [RFC3168] (updated by [RFC8311]) describes an extension to IP that details a method for becoming aware of congestion outside of datagram loss.
[RFC3168]で指定されたECN（[RFC8311]によって更新）は、データグラム損失の外で輻輳を認識できるようにする方法を詳述するIPへの拡張を記述しています。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
---------
Old text: (Appendix A)
---------
In general, [RFC3168] should be followed with the following exceptions.
一般に、[RFC3168]は以下の例外を除いて従うべきです。
---------
New text: (Appendix A)
---------
In general, [RFC3168] (updated by [RFC8311]) SHOULD be followed, with the following exceptions.
一般に、[RFC3168]（[RFC8311]によって更新）に従う必要がありますが、以下の例外があります。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
---------
Old text: (Appendix A)
---------
[RFC3168] details negotiation of ECN during the SYN and SYN-ACK stages of a TCP connection.
[RFC3168]は、TCP接続のSYNおよびSYN-ACKステージ中のECNのネゴシエーションについて詳しく説明しています。
---------
New text: (Appendix A)
---------
[RFC3168] (updated by [RFC8311]) details the negotiation of ECN during the SYN and SYN-ACK stages of a TCP connection.
[RFC3168]（[RFC8311]により更新）は、TCP接続のSYNおよびSYN-ACKステージ中のECNのネゴシエーションを詳述します。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
---------
Old text: (Appendix A)
---------
[RFC3168] details a specific bit for a receiver to send back in its TCP acknowledgements to notify the sender of the Congestion Experienced (CE) bit having arrived from the network.
[RFC3168]は、ネットワークから到着したCongestion Experienced（CE）ビットを送信者に通知するために、受信者がTCP確認応答で送り返す特定のビットの詳細を示しています。
---------
New text: (Appendix A)
---------
[RFC3168] (updated by [RFC8311]) details a specific bit for a receiver to send back in its TCP acknowledgements to notify the sender of the Congestion Experienced (CE) bit that the CE bit has arrived from the network.
[RFC3168]（[RFC8311]により更新）は、受信者がTCP確認応答で送り返す特定のビットの詳細を示し、CEビットがネットワークから到着したことを輻輳経験（CE）ビットで送信者に通知します。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
---------
Old text: (Appendix A)
---------
[RFC3168] details a specific bit for a sender to send in the header of its next outbound TCP segment to indicate to its peer that it has reduced its congestion window.
[RFC3168]は、次の発信TCPセグメントのヘッダーで送信者が送信する特定のビットの詳細を示し、輻輳ウィンドウが減少したことをピアに示します。
---------
New text: (Appendix A)
---------
[RFC3168] (updated by [RFC8311]) details a specific bit for a sender to send in the header of its next outbound TCP segment to indicate to its peer that it has reduced its congestion window.
[RFC3168]（[RFC8311]により更新）は、次の発信TCPセグメントのヘッダーで送信者が送信する特定のビットの詳細を示し、ピアに輻輳ウィンドウが減少したことを示します。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
References to [RFC8311] have been added. Some wordsmithing was also done while making those updates.
[RFC8311]への参照が追加されました。これらの更新を行っている間、いくつかの単語鍛造も行われました。
[RFC4960] defines three types of address parameters to be used with INIT and INIT ACK chunks:
[RFC4960]は、INITおよびINIT ACKチャンクで使用される3つのタイプのアドレスパラメータを定義しています。
1. IPv4 Address parameters.
1. IPv4アドレスパラメータ。
2. IPv6 Address parameters.
2. IPv6アドレスパラメータ。
3. Host Name Address parameters.
3. ホスト名アドレスパラメータ。
The first two parameter types are supported by the SCTP kernel implementations of FreeBSD, Linux, and Solaris, but the third is not. In addition, the first two were successfully tested in all nine interoperability tests for SCTP, but the third has never been successfully tested. Therefore, the Host Name Address parameter should be deprecated.
最初の2つのパラメータタイプは、FreeBSD、Linux、およびSolarisのSCTPカーネル実装でサポートされていますが、3番目はサポートされていません。さらに、最初の2つはSCTPの9つすべての相互運用性テストで正常にテストされましたが、3番目は正常にテストされていません。したがって、ホスト名アドレスパラメータは廃止する必要があります。
---------
Old text: (Section 3.3.2)
---------
Note 3: An INIT chunk MUST NOT contain more than one Host Name Address parameter. Moreover, the sender of the INIT MUST NOT combine any other address types with the Host Name Address in the INIT. The receiver of INIT MUST ignore any other address types if the Host Name Address parameter is present in the received INIT chunk.
注3：INITチャンクに複数のホスト名アドレスパラメータを含めることはできません。さらに、INITの送信者は、他のアドレスタイプをINITのホスト名アドレスと組み合わせてはなりません（MUST NOT）。受信したINITチャンクにホスト名アドレスパラメータが存在する場合、INITの受信者は他のアドレスタイプを無視する必要があります。
---------
New text: (Section 3.3.2)
---------
Note 3: An INIT chunk MUST NOT contain the Host Name Address parameter. The receiver of an INIT chunk containing a Host Name Address parameter MUST send an ABORT and MAY include an "Unresolvable Address" error cause.
注3：INITチャンクにホスト名アドレスパラメータを含めることはできません。ホスト名アドレスパラメータを含むINITチャンクの受信者は、ABORTを送信する必要があり、「解決できないアドレス」エラーの原因を含めることができます（MAY）。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
---------
Old text: (Section 3.3.2.1)
---------
The sender of INIT uses this parameter to pass its Host Name (in place of its IP addresses) to its peer. The peer is responsible for resolving the name. Using this parameter might make it more likely for the association to work across a NAT box.
INITの送信側はこのパラメーターを使用して、（IPアドレスの代わりに）ホスト名をピアに渡します。ピアは名前を解決する責任があります。このパラメーターを使用すると、関連付けがNATボックス全体で機能する可能性が高くなります。
---------
New text: (Section 3.3.2.1)
---------
The sender of an INIT chunk MUST NOT include this parameter. The usage of the Host Name Address parameter is deprecated.
INITチャンクの送信者は、このパラメーターを含めてはなりません（MUST NOT）。 Host Name Addressパラメータの使用は非推奨です。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
---------
Old text: (Section 3.3.2.1)
---------
Address Type: 16 bits (unsigned integer)
アドレスタイプ：16ビット（符号なし整数）
This is filled with the type value of the corresponding address TLV (e.g., IPv4 = 5, IPv6 = 6, Host name = 11).
これには、対応するアドレスTLVのタイプ値が入力されます（たとえば、IPv4 = 5、IPv6 = 6、ホスト名= 11）。
---------
New text: (Section 3.3.2.1)
---------
Address Type: 16 bits (unsigned integer)
アドレスタイプ：16ビット（符号なし整数）
This is filled with the type value of the corresponding address TLV (e.g., IPv4 = 5, IPv6 = 6). The value indicating the Host Name Address parameter (Host name = 11) MUST NOT be used.
これには、対応するアドレスTLVのタイプ値が入力されます（たとえば、IPv4 = 5、IPv6 = 6）。ホスト名アドレスパラメータ（ホスト名= 11）を示す値は使用してはなりません（MUST NOT）。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
---------
Old text: (Section 3.3.3)
---------
Note 3: The INIT ACK chunks MUST NOT contain more than one Host Name Address parameter. Moreover, the sender of the INIT ACK MUST NOT combine any other address types with the Host Name Address in the INIT ACK. The receiver of the INIT ACK MUST ignore any other address types if the Host Name Address parameter is present.
注3：INIT ACKチャンクには、複数のホスト名アドレスパラメータを含めることはできません。さらに、INIT ACKの送信者は、他のアドレスタイプをINIT ACKのホスト名アドレスと組み合わせてはなりません（MUST NOT）。 INIT ACKの受信者は、Host Name Addressパラメータが存在する場合、他のアドレスタイプを無視する必要があります。
---------
New text: (Section 3.3.3)
---------
Note 3: An INIT ACK chunk MUST NOT contain the Host Name Address parameter. The receiver of INIT ACK chunks containing a Host Name Address parameter MUST send an ABORT and MAY include an "Unresolvable Address" error cause.
注3：INIT ACKチャンクには、ホスト名アドレスパラメータを含めることはできません。ホスト名アドレスパラメータを含むINIT ACKチャンクの受信者はABORTを送信する必要があり、「解決できないアドレス」エラーの原因を含めることができます（MAY）。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
---------
Old text: (Section 5.1.2)
---------
B) If there is a Host Name parameter present in the received INIT or INIT ACK chunk, the endpoint shall resolve that host name to a list of IP address(es) and derive the transport address(es) of this peer by combining the resolved IP address(es) with the SCTP source port.
B）受信したINITまたはINIT ACKチャンクにホスト名パラメーターが存在する場合、エンドポイントはそのホスト名をIPアドレスのリストに解決し、解決されたものを組み合わせることにより、このピアのトランスポートアドレスを導出します。 SCTP送信元ポートのIPアドレス。
The endpoint MUST ignore any other IP Address parameters if they are also present in the received INIT or INIT ACK chunk.
受信したINITまたはINIT ACKチャンクにも存在する場合、エンドポイントは他のIPアドレスパラメータを無視する必要があります。
The time at which the receiver of an INIT resolves the host name has potential security implications to SCTP. If the receiver of an INIT resolves the host name upon the reception of the chunk, and the mechanism the receiver uses to resolve the host name involves potential long delay (e.g., DNS query), the receiver may open itself up to resource attacks for the period of time while it is waiting for the name resolution results before it can build the State Cookie and release local resources.
INITの受信者がホスト名を解決する時間は、SCTPに潜在的なセキュリティ上の影響があります。 INITのレシーバーがチャンクの受信時にホスト名を解決し、ホスト名を解決するためにレシーバーが使用するメカニズムが潜在的に長い遅延（DNSクエリなど）を伴う場合、レシーバーは、状態Cookieを構築してローカルリソースを解放する前に、名前解決の結果を待機している期間。
Therefore, in cases where the name translation involves potential long delay, the receiver of the INIT MUST postpone the name resolution till the reception of the COOKIE ECHO chunk from the peer. In such a case, the receiver of the INIT SHOULD build the State Cookie using the received Host Name (instead of destination transport addresses) and send the INIT ACK to the source IP address from which the INIT was received.
したがって、名前の変換に潜在的に長い遅延が含まれる場合、INITの受信者は、ピアからのCOOKIE ECHOチャンクの受信まで名前解決を延期する必要があります。このような場合、INITの受信者は、（宛先トランスポートアドレスの代わりに）受信したホスト名を使用して状態Cookieを作成し、INITの送信元IPアドレスにINIT ACKを送信する必要があります（SHOULD）。
The receiver of an INIT ACK shall always immediately attempt to resolve the name upon the reception of the chunk.
INIT ACKの受信者は、チャンクを受信するとすぐに名前を解決しようとします。
The receiver of the INIT or INIT ACK MUST NOT send user data (piggy-backed or stand-alone) to its peer until the host name is successfully resolved.
INITまたはINIT ACKの受信者は、ホスト名が正常に解決されるまで、ユーザーデータ（ピギーバックまたはスタンドアロン）をピアに送信してはなりません（MUST NOT）。
If the name resolution is not successful, the endpoint MUST immediately send an ABORT with "Unresolvable Address" error cause to its peer. The ABORT shall be sent to the source IP address from which the last peer packet was received.
名前解決が成功しない場合、エンドポイントは「原因不明のアドレス」エラーの原因を伴うABORTをすぐにピアに送信する必要があります。 ABORTは、最後のピアパケットが受信された送信元IPアドレスに送信されます。
---------
New text: (Section 5.1.2)
---------
B) If there is a Host Name Address parameter present in the received INIT or INIT ACK chunk, the endpoint MUST immediately send an ABORT and MAY include an "Unresolvable Address" error cause to its peer. The ABORT SHALL be sent to the source IP address from which the last peer packet was received.
B）受信したINITまたはINIT ACKチャンクにホスト名アドレスパラメータが存在する場合、エンドポイントは直ちにABORTを送信する必要があり、ピアに「解決できないアドレス」エラーの原因を含めることができます（MAY）。アボートは、最後のピアパケットが受信された送信元IPアドレスに送信する必要があります。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
---------
Old text: (Section 11.2.4.1)
---------
The use of the host name feature in the INIT chunk could be used to flood a target DNS server. A large backlog of DNS queries, resolving the host name received in the INIT chunk to IP addresses, could be accomplished by sending INITs to multiple hosts in a given domain. In addition, an attacker could use the host name feature in an indirect attack on a third party by sending large numbers of INITs to random hosts containing the host name of the target. In addition to the strain on DNS resources, this could also result in large numbers of INIT ACKs being sent to the target. One method to protect against this type of attack is to verify that the IP addresses received from DNS include the source IP address of the original INIT. If the list of IP addresses received from DNS does not include the source IP address of the INIT, the endpoint MAY silently discard the INIT. This last option will not protect against the attack against the DNS.
INITチャンクのホスト名機能を使用すると、ターゲットDNSサーバーをフラッディングする可能性があります。 INITチャンクで受け取ったホスト名をIPアドレスに解決するDNSクエリの大量のバックログは、特定のドメインの複数のホストにINITを送信することで実現できます。さらに、攻撃者は、ターゲットのホスト名を含むランダムなホストに大量のINITを送信することにより、第三者への間接攻撃でホスト名機能を使用する可能性があります。 DNSリソースへの負担に加えて、これにより、ターゲットに送信されるINIT ACKが大量になる可能性もあります。このタイプの攻撃から保護する1つの方法は、DNSから受信したIPアドレスに元のINITのソースIPアドレスが含まれていることを確認することです。 DNSから受け取ったIPアドレスのリストにINITのソースIPアドレスが含まれていない場合、エンドポイントはINITを通知せずに破棄する場合があります。この最後のオプションは、DNSに対する攻撃から保護しません。
---------
New text: (Section 11.2.4.1)
---------
Support for the Host Name Address parameter has been removed from the protocol. Endpoints receiving INIT or INIT ACK chunks containing the Host Name Address parameter MUST send an ABORT chunk in response and MAY include an "Unresolvable Address" error cause.
ホスト名アドレスパラメータのサポートがプロトコルから削除されました。ホスト名アドレスパラメータを含むINITまたはINIT ACKチャンクを受信するエンドポイントは、応答としてABORTチャンクを送信する必要があり、「解決できないアドレス」エラーの原因を含めることができます（MAY）。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
The usage of the Host Name Address parameter has been deprecated.
Host Name Addressパラメータの使用は廃止されました。
3.42. Conflicting Text regarding the 'Supported Address Types' Parameter
3.42. 「サポートされている住所タイプ」パラメータに関する矛盾するテキスト
Section 5.1.2 of [RFC4960] contains conflicting text regarding the receipt of an SCTP packet containing an INIT chunk sent from an address for which the corresponding address type is not listed in the 'Supported Address Types' parameter. The text states that the association MUST be aborted, but it also states that the association SHOULD be established and there SHOULD NOT be any error indication.
[RFC4960]のセクション5.1.2には、対応するアドレスタイプが「サポートされているアドレスタイプ」パラメーターにリストされていないアドレスから送信されたINITチャンクを含むSCTPパケットの受信に関する矛盾するテキストが含まれています。このテキストは、関連付けを中止する必要があることを示していますが、関連付けを確立する必要があり（SHOULD）、エラーを示すべきではないことも示しています。
---------
Old text: (Section 5.1.2)
---------
The sender of INIT may include a 'Supported Address Types' parameter in the INIT to indicate what types of address are acceptable. When this parameter is present, the receiver of INIT (initiate) MUST either use one of the address types indicated in the Supported Address Types parameter when responding to the INIT, or abort the association with an "Unresolvable Address" error cause if it is unwilling or incapable of using any of the address types indicated by its peer.
INITの送信者は、どのタイプのアドレスが受け入れられるかを示すために、INITに「サポートされているアドレスタイプ」パラメータを含めることができます。このパラメーターが存在する場合、INIT（開始）の受信者は、INITに応答するときに、サポートされているアドレスタイプパラメーターに示されているアドレスタイプの1つを使用するか、または、それが望まない場合、「解決できないアドレス」エラーの原因でアソシエーションを中止する必要があります。または、そのピアが示すアドレスタイプを使用できません。
---------
New text: (Section 5.1.2)
---------
The sender of INIT chunks MAY include a 'Supported Address Types' parameter in the INIT to indicate what types of addresses are acceptable.
INITチャンクの送信者は、どのタイプのアドレスが受け入れられるかを示すために、INITに「サポートされているアドレスタイプ」パラメータを含めることができます。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
The conflicting text has been removed.
競合するテキストは削除されました。
[RFC6096] updates [RFC4960] by adding the "Chunk Flags" registry. This should be integrated into the base specification.
[RFC6096]は、[Chunk Flags]レジストリを追加することによって[RFC4960]を更新します。これは、基本仕様に統合する必要があります。
---------
Old text: (Section 14.1)
---------
14.1. IETF-Defined Chunk Extension
14.1. IETF定義のチャンク拡張
The assignment of new chunk parameter type codes is done through an IETF Consensus action, as defined in [RFC2434]. Documentation of the chunk parameter MUST contain the following information:
新しいチャンクパラメータタイプコードの割り当ては、[RFC2434]で定義されているように、IETFコンセンサスアクションを通じて行われます。チャンクパラメータのドキュメントには、次の情報を含める必要があります。
a) A long and short name for the new chunk type.
a) 新しいチャンクタイプの長い名前と短い名前。
b) A detailed description of the structure of the chunk, which MUST conform to the basic structure defined in Section 3.2.
b) チャンクの構造の詳細な説明。セクション3.2で定義された基本構造に準拠する必要があります。
c) A detailed definition and description of the intended use of each field within the chunk, including the chunk flags if any.
c) チャンクフラグがある場合はそれを含め、チャンク内の各フィールドの使用目的の詳細な定義と説明。
d) A detailed procedural description of the use of the new chunk type within the operation of the protocol.
d) プロトコルの操作内での新しいチャンクタイプの使用に関する詳細な手順の説明。
The last chunk type (255) is reserved for future extension if necessary.
最後のチャンクタイプ（255）は、必要に応じて将来の拡張のために予約されています。
---------
New text: (Section 14.1)
---------
14.1. IETF-Defined Chunk Extension
14.1. IETF定義のチャンク拡張
The assignment of new chunk type codes is done through an IETF Review action, as defined in [RFC8126]. Documentation for a new chunk MUST contain the following information:
新しいチャンクタイプコードの割り当ては、[RFC8126]で定義されているIETFレビューアクションを介して行われます。新しいチャンクのドキュメントには、次の情報が含まれている必要があります。
a) A long and short name for the new chunk type.
a) 新しいチャンクタイプの長い名前と短い名前。
b) A detailed description of the structure of the chunk, which MUST conform to the basic structure defined in Section 3.2.
b) チャンクの構造の詳細な説明。セクション3.2で定義された基本構造に準拠する必要があります。
c) A detailed definition and description of the intended use of each field within the chunk, including the chunk flags (if any). Defined chunk flags will be used as initial entries in the chunk flags table for the new chunk type.
c) チャンクフラグ（存在する場合）を含む、チャンク内の各フィールドの使用目的の詳細な定義と説明。定義されたチャンクフラグは、新しいチャンクタイプのチャンクフラグテーブルの初期エントリとして使用されます。
d) A detailed procedural description of the use of the new chunk type within the operation of the protocol.
d) プロトコルの操作内での新しいチャンクタイプの使用に関する詳細な手順の説明。
The last chunk type (255) is reserved for future extension if necessary.
最後のチャンクタイプ（255）は、必要に応じて将来の拡張のために予約されています。
For each new chunk type, IANA creates a registration table for the chunk flags of that type. The procedure for registering particular chunk flags is described in Section 14.2.
新しいチャンクタイプごとに、IANAはそのタイプのチャンクフラグの登録テーブルを作成します。特定のチャンクフラグを登録する手順については、セクション14.2で説明します。
This text has been modified by multiple errata. It includes modifications from Section 3.3. It is in final form and is not further updated in this document.
このテキストは、複数のエラッタによって変更されています。セクション3.3からの変更が含まれます。これは最終的な形式であり、このドキュメントではこれ以上更新されません。
---------
New text: (Section 14.2)
---------
14.2. New IETF Chunk Flags Registration
14.2. 新しいIETFチャンクフラグの登録
The assignment of new chunk flags is done through an RFC Required action, as defined in [RFC8126]. Documentation for the chunk flags MUST contain the following information:
新しいチャンクフラグの割り当ては、[RFC8126]で定義されているように、RFC Requiredアクションを通じて行われます。チャンクフラグのドキュメントには、次の情報を含める必要があります。
a) A name for the new chunk flag.
a) 新しいチャンクフラグの名前。
b) A detailed procedural description of the use of the new chunk flag within the operation of the protocol. It MUST be considered that implementations not supporting the flag will send '0' on transmit and just ignore it on receipt.
b) プロトコルの操作内での新しいチャンクフラグの使用に関する詳細な手順の説明。フラグをサポートしない実装は送信時に「0」を送信し、受信時にそれを無視することを考慮しなければなりません。
IANA selects a chunk flags value. This MUST be one of 0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, or 0x80, which MUST be unique within the chunk flag values for the specific chunk type.
IANAはチャンクフラグ値を選択します。これは、0x01、0x02、0x04、0x08、0x10、0x20、0x40、または0x80のいずれかである必要があり、特定のチャンクタイプのチャンクフラグ値内で一意である必要があります。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
Please note that Sections 14.2, 14.3, 14.4, and 14.5 as shown in [RFC4960] will need to be renumbered when [RFC4960] is updated.
[RFC4960]に示されているセクション14.2、14.3、14.4、および14.5は、[RFC4960]が更新されたときに番号を付け直す必要があることに注意してください。
[RFC6096] has been integrated, and the reference has been updated to [RFC8126].
[RFC6096]が統合され、参照が[RFC8126]に更新されました。
[RFC6335] updates [RFC4960] by updating procedures for the "Service Name and Transport Protocol Port Number Registry". This should be integrated into the base specification. Also, the "Guidelines for Writing an IANA Considerations Section in RFCs" reference needs to be changed to [RFC8126].
[RFC6335]は、「サービス名およびトランスポートプロトコルのポート番号レジストリ」の手順を更新することにより、[RFC4960]を更新します。これは、基本仕様に統合する必要があります。また、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」の参照を[RFC8126]に変更する必要があります。
---------
Old text: (Section 14.5)
---------
SCTP services may use contact port numbers to provide service to unknown callers, as in TCP and UDP. IANA is therefore requested to open the existing Port Numbers registry for SCTP using the following rules, which we intend to mesh well with existing Port Numbers registration procedures. An IESG-appointed Expert Reviewer supports IANA in evaluating SCTP port allocation requests, according to the procedure defined in [RFC2434].
SCTPサービスは、コンタクトポート番号を使用して、TCPやUDPのように、不明な発信者にサービスを提供できます。したがって、IANAは、既存のポート番号の登録手順と十分に一致させる予定の次のルールを使用して、SCTPの既存のポート番号レジストリを開くように要求されます。 IESGが任命したExpert Reviewerは、[RFC2434]で定義されている手順に従って、SCTPポート割り当て要求を評価する際にIANAをサポートします。
Port numbers are divided into three ranges. The Well Known Ports are those from 0 through 1023, the Registered Ports are those from 1024 through 49151, and the Dynamic and/or Private Ports are those from 49152 through 65535. Well Known and Registered Ports are intended for use by server applications that desire a default contact point on a system. On most systems, Well Known Ports can only be used by system (or root) processes or by programs executed by privileged users, while Registered Ports can be used by ordinary user processes or programs executed by ordinary users. Dynamic and/or Private Ports are intended for temporary use, including client-side ports, out-of-band negotiated ports, and application testing prior to registration of a dedicated port; they MUST NOT be registered.
ポート番号は3つの範囲に分けられます。 Well Knownポートは0〜1023のポートであり、Registeredポートは1024〜49151のポートであり、Dynamicおよび/またはPrivateポートは49152〜65535のポートです。WellKnownポートおよびRegisteredポートは、サーバーアプリケーションでの使用を目的としています。システムのデフォルトの連絡先。ほとんどのシステムでは、既知のポートはシステム（またはルート）プロセスまたは特権ユーザーが実行するプログラムでのみ使用できますが、登録済みポートは通常のユーザープロセスまたは通常のユーザーが実行するプログラムで使用できます。動的および/またはプライベートポートは、クライアント側ポート、アウトオブバンドネゴシエーションポート、専用ポートの登録前のアプリケーションテストなど、一時的な使用を目的としています。登録してはなりません。
The Port Numbers registry should accept registrations for SCTP ports in the Well Known Ports and Registered Ports ranges. Well Known and Registered Ports SHOULD NOT be used without registration. Although in some cases -- such as porting an application from TCP to SCTP -- it may seem natural to use an SCTP port before registration completes, we emphasize that IANA will not guarantee registration of particular Well Known and Registered Ports. Registrations should be requested as early as possible.
ポート番号レジストリは、Well Known PortsおよびRegistered Portsの範囲のSCTPポートの登録を受け入れる必要があります。既知の登録済みのポートは、登録なしで使用してはなりません。アプリケーションをTCPからSCTPに移植する場合など、場合によっては、登録が完了する前にSCTPポートを使用するのが自然に思えるかもしれませんが、IANAは特定の既知の登録済みポートの登録を保証しないことを強調します。登録はできるだけ早くリクエストする必要があります。
Each port registration SHALL include the following information:
各ポート登録には、以下の情報が含まれている必要があります。
o A short port name, consisting entirely of letters (A-Z and a-z), digits (0-9), and punctuation characters from "-_+./*" (not including the quotes).
o 完全に文字（A-Zおよびa-z）、数字（0-9）、および「-_ +。/ *」からの句読文字（引用符は含まない）で構成される短いポート名。
o The port number that is requested for registration.
o 登録を要求されたポート番号。
o A short English phrase describing the port's purpose.
o 港の目的を説明する短い英語のフレーズ。
o Name and contact information for the person or entity performing the registration, and possibly a reference to a document defining the port's use. Registrations coming from IETF working groups need only name the working group, but indicating a contact person is recommended.
o 登録を実行する人またはエンティティの名前と連絡先情報、および場合によってはポートの使用を定義するドキュメントへの参照。 IETFワーキンググループからの登録では、ワーキンググループに名前を付けるだけで済みますが、連絡先を示すことをお勧めします。
Registrants are encouraged to follow these guidelines when submitting a registration.
登録者は、登録を送信する際にこれらのガイドラインに従うことをお勧めします。
o A port name SHOULD NOT be registered for more than one SCTP port number.
o ポート名は、複数のSCTPポート番号に対して登録してはなりません（SHOULD NOT）。
o A port name registered for TCP MAY be registered for SCTP as well. Any such registration SHOULD use the same port number as the existing TCP registration.
o TCPに登録されたポート名は、SCTPにも登録される場合があります。このような登録では、既存のTCP登録と同じポート番号を使用する必要があります（SHOULD）。
o Concrete intent to use a port SHOULD precede port registration. For example, existing TCP ports SHOULD NOT be registered in advance of any intent to use those ports for SCTP.
o ポートを使用する具体的な意図は、ポート登録の前にすべきです（SHOULD）。たとえば、既存のTCPポートは、SCTPにそれらのポートを使用する意図の前に登録してはなりません（SHOULD NOT）。
---------
New text: (Section 14.5)
---------
SCTP services can use contact port numbers to provide service to unknown callers, as in TCP and UDP. IANA is therefore requested to open the existing "Service Name and Transport Protocol Port Number Registry" for SCTP using the following rules, which we intend to mesh well with existing port-number registration procedures. An IESG-appointed expert reviewer supports IANA in evaluating SCTP port allocation requests, according to the procedure defined in [RFC8126]. The details of this process are defined in [RFC6335].
SCTPサービスは、コンタクトポート番号を使用して、TCPやUDPのように、不明な発信者にサービスを提供できます。したがって、IANAは、次のルールを使用して、SCTP用の既存の「サービス名およびトランスポートプロトコルのポート番号レジストリ」を開くように要求されます。 IESGが任命した専門家レビューアは、[RFC8126]で定義されている手順に従って、SCTPポート割り当て要求を評価する際にIANAをサポートします。このプロセスの詳細は[RFC6335]で定義されています。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
[RFC6335] has been integrated, and the reference has been updated to [RFC8126].
[RFC6335]が統合され、参照が[RFC8126]に更新されました。
[RFC7053] updates [RFC4960] by adding the I bit to the DATA chunk. This should be integrated into the base specification.
[RFC7053]は、IビットをDATAチャンクに追加して[RFC4960]を更新します。これは、基本仕様に統合する必要があります。
---------
Old text: (Section 3.3.1)
---------
The following format MUST be used for the DATA chunk:
DATAチャンクには次の形式を使用する必要があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0 | Reserved|U|B|E| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Identifier S | Stream Sequence Number n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Protocol Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ User Data (seq n of Stream S) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved: 5 bits
予約済み：5ビット
Should be set to all '0's and ignored by the receiver.
すべて「0」に設定し、レシーバーで無視する必要があります。
---------
New text: (Section 3.3.1)
---------
The following format MUST be used for the DATA chunk:
DATAチャンクには次の形式を使用する必要があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0 | Res |I|U|B|E| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Identifier S | Stream Sequence Number n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Protocol Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ User Data (seq n of Stream S) /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Res: 4 bits
Res：4ビット
SHOULD be set to all '0's and ignored by the receiver.
SHOULDはすべて「0」に設定され、受信者によって無視されます。
I bit: 1 bit
Iビット：1ビット
The (I)mmediate bit MAY be set by the sender whenever the sender of a DATA chunk can benefit from the corresponding SACK chunk being sent back without delay. See Section 4 of [RFC7053] for a discussion of the benefits.
（I）中間ビットは、DATAチャンクの送信者が対応するSACKチャンクが遅延なく送り返されることでメリットを得られる場合は常に、送信者によって設定される場合があります。利点の説明については、[RFC7053]のセクション4を参照してください。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
---------
New text: (Append to Section 6.1)
---------
Whenever the sender of a DATA chunk can benefit from the corresponding SACK chunk being sent back without delay, the sender MAY set the I bit in the DATA chunk header. Please note that why the sender has set the I bit is irrelevant to the receiver.
DATAチャンクの送信側が、対応するSACKチャンクが遅延なく返送されるメリットを享受できる場合は常に、送信側はDATAチャンクヘッダーのIビットを設定してもよい（MAY）。送信者がIビットを設定した理由は受信者とは無関係であることに注意してください。
Reasons for setting the I bit include, but are not limited to, the following (see Section 4 of [RFC7053] for a discussion of the benefits):
Iビットを設定する理由には次のものが含まれますが、これらに限定されません（利点の説明については、[RFC7053]のセクション4を参照してください）。
o The application requests that the I bit of the last DATA chunk of a user message be set when providing the user message to the SCTP implementation (see Section 7).
o アプリケーションは、ユーザーメッセージをSCTP実装に提供するときに、ユーザーメッセージの最後のDATAチャンクのIビットを設定するように要求します（セクション7を参照）。
o The sender is in the SHUTDOWN-PENDING state.
o 送信者はSHUTDOWN-PENDING状態です。
o The sending of a DATA chunk fills the congestion or receiver window.
o DATAチャンクの送信により、輻輳ウィンドウまたは受信ウィンドウがいっぱいになります。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
---------
Old text: (Section 6.2)
---------
Note: The SHUTDOWN chunk does not contain Gap Ack Block fields. Therefore, the endpoint should use a SACK instead of the SHUTDOWN chunk to acknowledge DATA chunks received out of order.
注：SHUTDOWNチャンクにはGap Ack Blockフィールドは含まれません。したがって、エンドポイントは、順不同で受信したDATAチャンクを確認するために、SHUTDOWNチャンクの代わりにSACKを使用する必要があります。
---------
New text: (Section 6.2)
---------
Note: The SHUTDOWN chunk does not contain Gap Ack Block fields. Therefore, the endpoint SHOULD use a SACK instead of the SHUTDOWN chunk to acknowledge DATA chunks received out of order.
注：SHUTDOWNチャンクにはGap Ack Blockフィールドは含まれません。したがって、エンドポイントは、順不同で受信したDATAチャンクを確認するために、SHUTDOWNチャンクの代わりにSACKを使用する必要があります（SHOULD）。
Upon receipt of an SCTP packet containing a DATA chunk with the I bit set, the receiver SHOULD NOT delay the sending of the corresponding SACK chunk, i.e., the receiver SHOULD immediately respond with the corresponding SACK chunk.
Iビットが設定されたDATAチャンクを含むSCTPパケットを受信すると、受信者は対応するSACKチャンクの送信を遅らせるべきではない（SHOULD NOT）、つまり、受信者は対応するSACKチャンクで即座に応答する必要がある（SHOULD）。
Please note that this change is only about adding a paragraph.
この変更は段落の追加に関するものだけであることに注意してください。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
---------
Old text: (Section 10.1 E))
---------
E) Send
E）送信
Format: SEND(association id, buffer address, byte count [,context] [,stream id] [,life time] [,destination transport address] [,unordered flag] [,no-bundle flag] [,payload protocol-id] ) -> result
形式：SEND（関連付けID、バッファアドレス、バイトカウント[、コンテキスト] [、ストリームID] [、ライフタイム] [、宛先トランスポートアドレス] [、順序付けられていないフラグ] [、バンドルなしフラグ] [、ペイロードプロトコルID ]）->結果
---------
New text: (Section 10.1 E))
---------
E) Send
E）送信
Format: SEND(association id, buffer address, byte count [,context]
[,stream id] [,life time] [,destination transport address]
[,unordered flag] [,no-bundle flag] [,payload protocol-id]
[,sack-immediately])
-> result
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
---------
New text: (Append optional parameter in item E) of Section 10.1)
---------
o sack-immediately flag - set the I bit on the last DATA chunk used for the user message to be transmitted.
o sack-immediatelyフラグ-ユーザーメッセージの送信に使用される最後のDATAチャンクにIビットを設定します。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
[RFC7053] has been integrated.
[RFC7053]が統合されました。
The code given for the CRC32c computations uses types such as "long", which may have different lengths on different operating systems or processors. Therefore, the code needs to be changed, so that it uses specific types such as uint32_t.
CRC32c計算用に指定されたコードは、「long」などのタイプを使用します。これは、オペレーティングシステムやプロセッサによって長さが異なる場合があります。したがって、コードを変更して、uint32_tなどの特定のタイプを使用する必要があります。
Some syntax errors and a comment also need to be fixed.
いくつかの構文エラーとコメントも修正する必要があります。
We remind the reader that per Section 3.10.2 of this document most of Appendix C of RFC 4960 will be moved to Appendix B in the bis document (thus the "Old text: (Appendix C)" and "New text: (Appendix B)" items in this section).
このドキュメントのセクション3.10.2に従って、RFC 4960のほとんどの付録Cがbisドキュメントの付録Bに移動することを読者に思い出させます（したがって、「古いテキスト：（付録C）」と「新しいテキスト：（付録B ） "このセクションの項目）。
---------
Old text: (Appendix C)
---------
/*************************************************************/
/* Note Definition for Ross Williams table generator would */
/* be: TB_WIDTH=4, TB_POLLY=0x1EDC6F41, TB_REVER=TRUE */
/* For Mr. Williams direct calculation code use the settings */
/* cm_width=32, cm_poly=0x1EDC6F41, cm_init=0xFFFFFFFF, */
/* cm_refin=TRUE, cm_refot=TRUE, cm_xorort=0x00000000 */
/*************************************************************/
/* Example of the crc table file */
#ifndef __crc32cr_table_h__
#define __crc32cr_table_h__
#define CRC32C_POLY 0x1EDC6F41
#define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])
unsigned long crc_c[256] = { 0x00000000L, 0xF26B8303L, 0xE13B70F7L, 0x1350F3F4L, 0xC79A971FL, 0x35F1141CL, 0x26A1E7E8L, 0xD4CA64EBL, 0x8AD958CFL, 0x78B2DBCCL, 0x6BE22838L, 0x9989AB3BL, 0x4D43CFD0L, 0xBF284CD3L, 0xAC78BF27L, 0x5E133C24L, 0x105EC76FL, 0xE235446CL, 0xF165B798L, 0x030E349BL, 0xD7C45070L, 0x25AFD373L, 0x36FF2087L, 0xC494A384L, 0x9A879FA0L, 0x68EC1CA3L, 0x7BBCEF57L, 0x89D76C54L, 0x5D1D08BFL, 0xAF768BBCL, 0xBC267848L, 0x4E4DFB4BL, 0x20BD8EDEL, 0xD2D60DDDL, 0xC186FE29L, 0x33ED7D2AL, 0xE72719C1L, 0x154C9AC2L, 0x061C6936L, 0xF477EA35L, 0xAA64D611L, 0x580F5512L, 0x4B5FA6E6L, 0xB93425E5L, 0x6DFE410EL, 0x9F95C20DL, 0x8CC531F9L, 0x7EAEB2FAL, 0x30E349B1L, 0xC288CAB2L, 0xD1D83946L, 0x23B3BA45L,
unsigned long型crc_c [256] = {0x00000000L、0xF26B8303L、0xE13B70F7L、0x1350F3F4L、0xC79A971FL、0x35F1141CL、0x26A1E7E8L、0xD4CA64EBL、0x8AD958CFL、0x78B2DBCCL、0x6BE22838L、0x9989AB3BL、0x4D43CFD0L、0xBF284CD3L、0xAC78BF27L、0x5E133C24L、0x105EC76FL、0xE235446CL、0xF165B798L、0x030E349BL、0xD7C45070L、 0x25AFD373L、0x36FF2087L、0xC494A384L、0x9A879FA0L、0x68EC1CA3L、0x7BBCEF57L、0x89D76C54L、0x5D1D08BFL、0xAF768BBCL、0xBC267848L、0x4E4DFB4BL、0x20BD8EDEL、0xD2D60DDDL、0xC186FE29L、0x33ED7D2AL、0xE72719C1L、0x154C9AC2L、0x061C6936L、0xF477EA35L、0xAA64D611L、0x580F5512L、0x4B5FA6E6L、0xB93425E5L、0x6DFE410EL、0x9F95C20DL、 0x8CC531F9L、0x7EAEB2FAL、0x30E349B1L、0xC288CAB2L、0xD1D83946L、0x23B3BA45L、
0xF779DEAEL, 0x05125DADL, 0x1642AE59L, 0xE4292D5AL, 0xBA3A117EL, 0x4851927DL, 0x5B016189L, 0xA96AE28AL, 0x7DA08661L, 0x8FCB0562L, 0x9C9BF696L, 0x6EF07595L, 0x417B1DBCL, 0xB3109EBFL, 0xA0406D4BL, 0x522BEE48L, 0x86E18AA3L, 0x748A09A0L, 0x67DAFA54L, 0x95B17957L, 0xCBA24573L, 0x39C9C670L, 0x2A993584L, 0xD8F2B687L, 0x0C38D26CL, 0xFE53516FL, 0xED03A29BL, 0x1F682198L, 0x5125DAD3L, 0xA34E59D0L, 0xB01EAA24L, 0x42752927L, 0x96BF4DCCL, 0x64D4CECFL, 0x77843D3BL, 0x85EFBE38L, 0xDBFC821CL, 0x2997011FL, 0x3AC7F2EBL, 0xC8AC71E8L, 0x1C661503L, 0xEE0D9600L, 0xFD5D65F4L, 0x0F36E6F7L, 0x61C69362L, 0x93AD1061L, 0x80FDE395L, 0x72966096L, 0xA65C047DL, 0x5437877EL, 0x4767748AL, 0xB50CF789L, 0xEB1FCBADL, 0x197448AEL, 0x0A24BB5AL, 0xF84F3859L, 0x2C855CB2L, 0xDEEEDFB1L, 0xCDBE2C45L, 0x3FD5AF46L, 0x7198540DL, 0x83F3D70EL, 0x90A324FAL, 0x62C8A7F9L, 0xB602C312L, 0x44694011L, 0x5739B3E5L, 0xA55230E6L, 0xFB410CC2L, 0x092A8FC1L, 0x1A7A7C35L, 0xE811FF36L, 0x3CDB9BDDL, 0xCEB018DEL, 0xDDE0EB2AL, 0x2F8B6829L, 0x82F63B78L, 0x709DB87BL, 0x63CD4B8FL, 0x91A6C88CL, 0x456CAC67L, 0xB7072F64L, 0xA457DC90L, 0x563C5F93L, 0x082F63B7L, 0xFA44E0B4L, 0xE9141340L, 0x1B7F9043L, 0xCFB5F4A8L, 0x3DDE77ABL, 0x2E8E845FL, 0xDCE5075CL, 0x92A8FC17L, 0x60C37F14L, 0x73938CE0L, 0x81F80FE3L, 0x55326B08L, 0xA759E80BL, 0xB4091BFFL, 0x466298FCL, 0x1871A4D8L, 0xEA1A27DBL, 0xF94AD42FL, 0x0B21572CL, 0xDFEB33C7L, 0x2D80B0C4L, 0x3ED04330L, 0xCCBBC033L, 0xA24BB5A6L, 0x502036A5L, 0x4370C551L, 0xB11B4652L, 0x65D122B9L, 0x97BAA1BAL, 0x84EA524EL, 0x7681D14DL, 0x2892ED69L, 0xDAF96E6AL, 0xC9A99D9EL, 0x3BC21E9DL, 0xEF087A76L, 0x1D63F975L, 0x0E330A81L, 0xFC588982L, 0xB21572C9L, 0x407EF1CAL, 0x532E023EL, 0xA145813DL, 0x758FE5D6L, 0x87E466D5L, 0x94B49521L, 0x66DF1622L, 0x38CC2A06L, 0xCAA7A905L, 0xD9F75AF1L, 0x2B9CD9F2L, 0xFF56BD19L, 0x0D3D3E1AL, 0x1E6DCDEEL, 0xEC064EEDL, 0xC38D26C4L, 0x31E6A5C7L, 0x22B65633L, 0xD0DDD530L, 0x0417B1DBL, 0xF67C32D8L, 0xE52CC12CL, 0x1747422FL, 0x49547E0BL, 0xBB3FFD08L, 0xA86F0EFCL, 0x5A048DFFL, 0x8ECEE914L, 0x7CA56A17L, 0x6FF599E3L, 0x9D9E1AE0L, 0xD3D3E1ABL, 0x21B862A8L, 0x32E8915CL, 0xC083125FL, 0x144976B4L, 0xE622F5B7L, 0xF5720643L, 0x07198540L, 0x590AB964L, 0xAB613A67L, 0xB831C993L, 0x4A5A4A90L, 0x9E902E7BL, 0x6CFBAD78L, 0x7FAB5E8CL, 0x8DC0DD8FL, 0xE330A81AL, 0x115B2B19L, 0x020BD8EDL, 0xF0605BEEL, 0x24AA3F05L, 0xD6C1BC06L, 0xC5914FF2L, 0x37FACCF1L, 0x69E9F0D5L, 0x9B8273D6L, 0x88D28022L, 0x7AB90321L, 0xAE7367CAL, 0x5C18E4C9L, 0x4F48173DL, 0xBD23943EL, 0xF36E6F75L, 0x0105EC76L, 0x12551F82L, 0xE03E9C81L,
0xF779DEAEL、0x05125DADL、0x1642AE59L、0xE4292D5AL、0xBA3A117EL、0x4851927DL、0x5B016189L、0xA96AE28AL、0x7DA08661L、0x8FCB0562L、0x9C9BF696L、0x6EF07595L、0x417B1DBCL、0xB3109EBFL、0xA0406D4BL、0x522BEE48L、0x86E18AA3L、0x748A09A0L、0x67DAFA54L、0x95B17957L、0xCBA24573L、0x39C9C670L、0x2A993584L、0xD8F2B687L、0x0C38D26CL、 0xFE53516FL、0xED03A29BL、0x1F682198L、0x5125DAD3L、0xA34E59D0L、0xB01EAA24L、0x42752927L、0x96BF4DCCL、0x64D4CECFL、0x77843D3BL、0x85EFBE38L、0xDBFC821CL、0x2997011FL、0x3AC7F2EBL、0xC8AC71E8L、0x1C661503L、0xEE0D9600L、0xFD5D65F4L、0x0F36E6F7L、0x61C69362L、0x93AD1061L、0x80FDE395L、0x72966096L、0xA65C047DL、0x5437877EL、 0x4767748AL、0xB50CF789L、0xEB1FCBADL、0x197448AEL、0x0A24BB5AL、0xF84F3859L、0x2C855CB2L、0xDEEEDFB1L、0xCDBE2C45L、0x3FD5AF46L、0x7198540DL、0x83F3D70EL、0x90A324FAL、0x62C8A7F9L、0xB602C312L、0x44694011L、0x5739B3E5L、0xA55230E6L、0xFB410CC2L、0x092A8FC1L、0x1A7A7C35L、0xE811FF36L、0x3CDB9BDDL、0xCEB018DEL、0xDDE0EB2AL、 0x2F8B6829L、0x82F63B78L、 0x709DB87BL、0x63CD4B8FL、0x91A6C88CL、0x456CAC67L、0xB7072F64L、0xA457DC90L、0x563C5F93L、0x082F63B7L、0xFA44E0B4L、0xE9141340L、0x1B7F9043L、0xCFB5F4A8L、0x3DDE77ABL、0x2E8E845FL、0xDCE5075CL、0x92A8FC17L、0x60C37F14L、0x73938CE0L、0x81F80FE3L、0x55326B08L、0xA759E80BL、0xB4091BFFL、0x466298FCL、0x1871A4D8L、0xEA1A27DBL、 0xF94AD42FL、0x0B21572CL、0xDFEB33C7L、0x2D80B0C4L、0x3ED04330L、0xCCBBC033L、0xA24BB5A6L、0x502036A5L、0x4370C551L、0xB11B4652L、0x65D122B9L、0x97BAA1BAL、0x84EA524EL、0x7681D14DL、0x2892ED69L、0xDAF96E6AL、0xC9A99D9EL、0x3BC21E9DL、0xEF087A76L、0x1D63F975L、0x0E330A81L、0xFC588982L、0xB21572C9L、0x407EF1CAL、0x532E023EL、 0xA145813DL、0x758FE5D6L、0x87E466D5L、0x94B49521L、0x66DF1622L、0x38CC2A06L、0xCAA7A905L、0xD9F75AF1L、0x2B9CD9F2L、0xFF56BD19L、0x0D3D3E1AL、0x1E6DCDEEL、0xEC064EEDL、0xC38D26C4L、0x31E6A5C7L、0x22B65633L、0xD0DDD530L、0x0417B1DBL、0xF67C32D8L、0xE52CC12CL、0x1747422FL、0x49547E0BL、0xBB3FFD08L、0xA86F0EFCL、0x5A048DFFL、 0x8ECEE914L、0x7CA56A17L 、0x6FF599E3L、0x9D9E1AE0L、0xD3D3E1ABL、0x21B862A8L、0x32E8915CL、0xC083125FL、0x144976B4L、0xE622F5B7L、0xF5720643L、0x07198540L、0x590AB964L、0xAB613A67L、0xB831C993L、0x4A5A4A90L、0x9E902E7BL、0x6CFBAD78L、0x7FAB5E8CL、0x8DC0DD8FL、0xE330A81AL、0x115B2B19L、0x020BD8EDL、0xF0605BEEL、0x24AA3F05L、0xD6C1BC06L、0xC5914FF2L 、0x37FACCF1L、0x69E9F0D5L、0x9B8273D6L、0x88D28022L、0x7AB90321L、0xAE7367CAL、0x5C18E4C9L、0x4F48173DL、0xBD23943EL、0xF36E6F75L、0x0125E51L76L0E05L76
0x34F4F86AL, 0xC69F7B69L, 0xD5CF889DL, 0x27A40B9EL, 0x79B737BAL, 0x8BDCB4B9L, 0x988C474DL, 0x6AE7C44EL, 0xBE2DA0A5L, 0x4C4623A6L, 0x5F16D052L, 0xAD7D5351L, };
0 x 4 x 4ポンド、0 x 1 x 1 xオニオン、0 x 1は0、0 x 4 x 4623、0 x 5は0ライター、0 x 4 x 4623、0 x 5 x 0ライター
#endif
#endif
---------
New text: (Appendix B)
---------
<CODE BEGINS>
/****************************************************************/
/* Note: The definitions for Ross Williams's table generator */
/* would be TB_WIDTH=4, TB_POLY=0x1EDC6F41, TB_REVER=TRUE. */
/* For Mr. Williams's direct calculation code, use the settings */
/* cm_width=32, cm_poly=0x1EDC6F41, cm_init=0xFFFFFFFF, */
/* cm_refin=TRUE, cm_refot=TRUE, cm_xorot=0x00000000. */
/****************************************************************/
/* Example of the crc table file */
#ifndef __crc32cr_h__
#define __crc32cr_h__
#define CRC32C_POLY 0x1EDC6F41UL
#define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])
uint32_t crc_c[256] =
{
0x00000000UL, 0xF26B8303UL, 0xE13B70F7UL, 0x1350F3F4UL,
0xC79A971FUL, 0x35F1141CUL, 0x26A1E7E8UL, 0xD4CA64EBUL,
0x8AD958CFUL, 0x78B2DBCCUL, 0x6BE22838UL, 0x9989AB3BUL,
0x4D43CFD0UL, 0xBF284CD3UL, 0xAC78BF27UL, 0x5E133C24UL,
0x105EC76FUL, 0xE235446CUL, 0xF165B798UL, 0x030E349BUL,
0xD7C45070UL, 0x25AFD373UL, 0x36FF2087UL, 0xC494A384UL,
0x9A879FA0UL, 0x68EC1CA3UL, 0x7BBCEF57UL, 0x89D76C54UL,
0x5D1D08BFUL, 0xAF768BBCUL, 0xBC267848UL, 0x4E4DFB4BUL,
0x20BD8EDEUL, 0xD2D60DDDUL, 0xC186FE29UL, 0x33ED7D2AUL,
0xE72719C1UL, 0x154C9AC2UL, 0x061C6936UL, 0xF477EA35UL,
0xAA64D611UL, 0x580F5512UL, 0x4B5FA6E6UL, 0xB93425E5UL,
0x6DFE410EUL, 0x9F95C20DUL, 0x8CC531F9UL, 0x7EAEB2FAUL,
0x30E349B1UL, 0xC288CAB2UL, 0xD1D83946UL, 0x23B3BA45UL,
0xF779DEAEUL, 0x05125DADUL, 0x1642AE59UL, 0xE4292D5AUL,
0xBA3A117EUL, 0x4851927DUL, 0x5B016189UL, 0xA96AE28AUL,
0x7DA08661UL, 0x8FCB0562UL, 0x9C9BF696UL, 0x6EF07595UL,
0x417B1DBCUL, 0xB3109EBFUL, 0xA0406D4BUL, 0x522BEE48UL,
0x86E18AA3UL, 0x748A09A0UL, 0x67DAFA54UL, 0x95B17957UL,
0xCBA24573UL, 0x39C9C670UL, 0x2A993584UL, 0xD8F2B687UL,
0x0C38D26CUL, 0xFE53516FUL, 0xED03A29BUL, 0x1F682198UL,
0x5125DAD3UL, 0xA34E59D0UL, 0xB01EAA24UL, 0x42752927UL,
0x96BF4DCCUL, 0x64D4CECFUL, 0x77843D3BUL, 0x85EFBE38UL,
0xDBFC821CUL, 0x2997011FUL, 0x3AC7F2EBUL, 0xC8AC71E8UL,
0x1C661503UL, 0xEE0D9600UL, 0xFD5D65F4UL, 0x0F36E6F7UL,
0x61C69362UL, 0x93AD1061UL, 0x80FDE395UL, 0x72966096UL,
0xA65C047DUL, 0x5437877EUL, 0x4767748AUL, 0xB50CF789UL,
0xEB1FCBADUL, 0x197448AEUL, 0x0A24BB5AUL, 0xF84F3859UL,
0x2C855CB2UL, 0xDEEEDFB1UL, 0xCDBE2C45UL, 0x3FD5AF46UL,
0x7198540DUL, 0x83F3D70EUL, 0x90A324FAUL, 0x62C8A7F9UL,
0xB602C312UL, 0x44694011UL, 0x5739B3E5UL, 0xA55230E6UL,
0xFB410CC2UL, 0x092A8FC1UL, 0x1A7A7C35UL, 0xE811FF36UL,
0x3CDB9BDDUL, 0xCEB018DEUL, 0xDDE0EB2AUL, 0x2F8B6829UL,
0x82F63B78UL, 0x709DB87BUL, 0x63CD4B8FUL, 0x91A6C88CUL,
0x456CAC67UL, 0xB7072F64UL, 0xA457DC90UL, 0x563C5F93UL,
0x082F63B7UL, 0xFA44E0B4UL, 0xE9141340UL, 0x1B7F9043UL,
0xCFB5F4A8UL, 0x3DDE77ABUL, 0x2E8E845FUL, 0xDCE5075CUL,
0x92A8FC17UL, 0x60C37F14UL, 0x73938CE0UL, 0x81F80FE3UL,
0x55326B08UL, 0xA759E80BUL, 0xB4091BFFUL, 0x466298FCUL,
0x1871A4D8UL, 0xEA1A27DBUL, 0xF94AD42FUL, 0x0B21572CUL,
0xDFEB33C7UL, 0x2D80B0C4UL, 0x3ED04330UL, 0xCCBBC033UL,
0xA24BB5A6UL, 0x502036A5UL, 0x4370C551UL, 0xB11B4652UL,
0x65D122B9UL, 0x97BAA1BAUL, 0x84EA524EUL, 0x7681D14DUL,
0x2892ED69UL, 0xDAF96E6AUL, 0xC9A99D9EUL, 0x3BC21E9DUL,
0xEF087A76UL, 0x1D63F975UL, 0x0E330A81UL, 0xFC588982UL,
0xB21572C9UL, 0x407EF1CAUL, 0x532E023EUL, 0xA145813DUL,
0x758FE5D6UL, 0x87E466D5UL, 0x94B49521UL, 0x66DF1622UL,
0x38CC2A06UL, 0xCAA7A905UL, 0xD9F75AF1UL, 0x2B9CD9F2UL,
0xFF56BD19UL, 0x0D3D3E1AUL, 0x1E6DCDEEUL, 0xEC064EEDUL,
0xC38D26C4UL, 0x31E6A5C7UL, 0x22B65633UL, 0xD0DDD530UL,
0x0417B1DBUL, 0xF67C32D8UL, 0xE52CC12CUL, 0x1747422FUL,
0x49547E0BUL, 0xBB3FFD08UL, 0xA86F0EFCUL, 0x5A048DFFUL,
0x8ECEE914UL, 0x7CA56A17UL, 0x6FF599E3UL, 0x9D9E1AE0UL,
0xD3D3E1ABUL, 0x21B862A8UL, 0x32E8915CUL, 0xC083125FUL,
0x144976B4UL, 0xE622F5B7UL, 0xF5720643UL, 0x07198540UL,
0x590AB964UL, 0xAB613A67UL, 0xB831C993UL, 0x4A5A4A90UL,
0x9E902E7BUL, 0x6CFBAD78UL, 0x7FAB5E8CUL, 0x8DC0DD8FUL,
0xE330A81AUL, 0x115B2B19UL, 0x020BD8EDUL, 0xF0605BEEUL,
0x24AA3F05UL, 0xD6C1BC06UL, 0xC5914FF2UL, 0x37FACCF1UL,
0x69E9F0D5UL, 0x9B8273D6UL, 0x88D28022UL, 0x7AB90321UL,
0xAE7367CAUL, 0x5C18E4C9UL, 0x4F48173DUL, 0xBD23943EUL,
0xF36E6F75UL, 0x0105EC76UL, 0x12551F82UL, 0xE03E9C81UL,
0x34F4F86AUL, 0xC69F7B69UL, 0xD5CF889DUL, 0x27A40B9EUL,
0x79B737BAUL, 0x8BDCB4B9UL, 0x988C474DUL, 0x6AE7C44EUL,
0xBE2DA0A5UL, 0x4C4623A6UL, 0x5F16D052UL, 0xAD7D5351UL,
};
#endif
#endif
This text has been modified by multiple errata. It includes modifications from Section 3.10. It is in final form and is not further updated in this document.
このテキストは、複数のエラッタによって変更されています。セクション3.10からの変更が含まれます。これは最終的な形式であり、このドキュメントではこれ以上更新されません。
---------
Old text: (Appendix C)
---------
/* Example of table build routine */
#include <stdio.h>
#include <stdlib.h>
#define OUTPUT_FILE "crc32cr.h"
#define CRC32C_POLY 0x1EDC6F41L
FILE *tf;
unsigned long
reflect_32 (unsigned long b)
{
int i;
unsigned long rw = 0L;
for (i = 0; i < 32; i++){
if (b & 1)
rw |= 1 << (31 - i);
b >>= 1;
}
return (rw);
}
unsigned long
build_crc_table (int index)
{
int i;
unsigned long rb;
rb = reflect_32 (index);
rb = Reflect_32（インデックス）;
for (i = 0; i < 8; i++){
if (rb & 0x80000000L)
rb = (rb << 1) ^ CRC32C_POLY;
else
rb <<= 1;
}
return (reflect_32 (rb));
}
main ()
メイン()
{
int i;
printf ("\nGenerating CRC-32c table file <%s>\n",
OUTPUT_FILE);
if ((tf = fopen (OUTPUT_FILE, "w")) == NULL){
printf ("Unable to open %s\n", OUTPUT_FILE);
exit (1);
}
fprintf (tf, "#ifndef __crc32cr_table_h__\n");
fprintf (tf, "#define __crc32cr_table_h__\n\n");
fprintf (tf, "#define CRC32C_POLY 0x%08lX\n",
CRC32C_POLY);
fprintf (tf,
"#define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])\n");
fprintf (tf, "\nunsigned long crc_c[256] =\n{\n");
for (i = 0; i < 256; i++){
fprintf (tf, "0x%08lXL, ", build_crc_table (i));
if ((i & 3) == 3)
fprintf (tf, "\n");
}
fprintf (tf, "};\n\n#endif\n");
if (fclose (tf) != 0)
printf ("Unable to close <%s>." OUTPUT_FILE);
else
printf ("\nThe CRC-32c table has been written to <%s>.\n",
OUTPUT_FILE);
}
---------
New text: (Appendix B)
---------
/* Example of table build routine */
#include <stdio.h>
#include <stdlib.h>
#define OUTPUT_FILE "crc32cr.h" #define CRC32C_POLY 0x1EDC6F41UL
#define OUTPUT_FILE "crc32cr.h" #define CRC32C_POLY 0x1EDC6F41UL
static FILE *tf;
静的ファイル* tf;
static uint32_t
reflect_32(uint32_t b)
{
int i;
uint32_t rw = 0UL;
for (i = 0; i < 32; i++) {
if (b & 1)
rw |= 1 << (31 - i);
b >>= 1;
}
return (rw);
}
static uint32_t
build_crc_table (int index)
{
int i;
uint32_t rb;
rb = reflect_32(index);
for (i = 0; i < 8; i++) {
if (rb & 0x80000000UL)
rb = (rb << 1) ^ (uint32_t)CRC32C_POLY;
else
rb <<= 1;
}
return (reflect_32(rb));
}
int
main (void)
{
int i;
printf("\nGenerating CRC32c table file <%s>.\n",
OUTPUT_FILE);
if ((tf = fopen(OUTPUT_FILE, "w")) == NULL) {
printf("Unable to open %s.\n", OUTPUT_FILE);
exit (1);
}
fprintf(tf, "#ifndef __crc32cr_h__\n");
fprintf(tf, "#define __crc32cr_h__\n\n");
fprintf(tf, "#define CRC32C_POLY 0x%08XUL\n",
(uint32_t)CRC32C_POLY);
fprintf(tf,
"#define CRC32C(c,d) (c=(c>>8)^crc_c[(c^(d))&0xFF])\n");
fprintf(tf, "\nuint32_t crc_c[256] =\n{\n");
for (i = 0; i < 256; i++) {
fprintf(tf, "0x%08XUL,", build_crc_table (i));
if ((i & 3) == 3)
fprintf(tf, "\n");
else
fprintf(tf, " ");
}
fprintf(tf, "};\n\n#endif\n");
if (fclose(tf) != 0)
printf("Unable to close <%s>.\n", OUTPUT_FILE);
else
printf("\nThe CRC32c table has been written to <%s>.\n",
OUTPUT_FILE);
}
This text has been modified by multiple errata. It includes modifications from Section 3.10. It is in final form and is not further updated in this document.
このテキストは、複数のエラッタによって変更されています。セクション3.10からの変更が含まれます。これは最終的な形式であり、このドキュメントではこれ以上更新されません。
---------
Old text: (Appendix C)
---------
/* Example of crc insertion */
#include "crc32cr.h"
#include "crc32cr.h"
unsigned long
generate_crc32c(unsigned char *buffer, unsigned int length)
{
unsigned int i;
unsigned long crc32 = ~0L;
unsigned long result;
unsigned char byte0,byte1,byte2,byte3;
for (i = 0; i < length; i++){
CRC32C(crc32, buffer[i]);
}
result = ~crc32;
/* result now holds the negated polynomial remainder;
* since the table and algorithm is "reflected" [williams95].
* That is, result has the same value as if we mapped the message
* to a polynomial, computed the host-bit-order polynomial
* remainder, performed final negation, then did an end-for-end
* bit-reversal.
* Note that a 32-bit bit-reversal is identical to four inplace
* 8-bit reversals followed by an end-for-end byteswap.
* In other words, the bytes of each bit are in the right order,
* but the bytes have been byteswapped. So we now do an explicit * byteswap. On a little-endian machine, this byteswap and * the final ntohl cancel out and could be elided. */
* しかし、バイトはバイトスワップされています。したがって、明示的に*バイトスワップを行います。リトルエンディアンマシンでは、このバイトスワップと*最後のntohlはキャンセルされ、省略できます。 * /
byte0 = result & 0xff;
byte1 = (result>>8) & 0xff;
byte2 = (result>>16) & 0xff;
byte3 = (result>>24) & 0xff;
crc32 = ((byte0 << 24) |
(byte1 << 16) |
(byte2 << 8) |
byte3);
return ( crc32 );
}
int
insert_crc32(unsigned char *buffer, unsigned int length)
{
SCTP_message *message;
unsigned long crc32;
message = (SCTP_message *) buffer;
message->common_header.checksum = 0L;
crc32 = generate_crc32c(buffer,length);
/* and insert it into the message */
message->common_header.checksum = htonl(crc32);
return 1;
}
int
validate_crc32(unsigned char *buffer, unsigned int length)
{
SCTP_message *message;
unsigned int i;
unsigned long original_crc32;
unsigned long crc32 = ~0L;
/* save and zero checksum */
message = (SCTP_message *) buffer;
original_crc32 = ntohl(message->common_header.checksum);
message->common_header.checksum = 0L;
crc32 = generate_crc32c(buffer,length);
return ((original_crc32 == crc32)? 1 : -1);
}
---------
New text: (Appendix B)
---------
/* Example of crc insertion */
#include "crc32cr.h"
#include "crc32cr.h"
uint32_t
generate_crc32c(unsigned char *buffer, unsigned int length)
{
unsigned int i;
uint32_t crc32 = 0xffffffffUL;
uint32_t result;
uint8_t byte0, byte1, byte2, byte3;
for (i = 0; i < length; i++) {
CRC32C(crc32, buffer[i]);
}
result = ~crc32;
/* result now holds the negated polynomial remainder,
* since the table and algorithm are "reflected" [williams95].
* That is, result has the same value as if we mapped the message
* to a polynomial, computed the host-bit-order polynomial
* remainder, performed final negation, and then did an
* end-for-end bit-reversal.
* Note that a 32-bit bit-reversal is identical to four in-place
* 8-bit bit-reversals followed by an end-for-end byteswap.
* In other words, the bits of each byte are in the right order,
* but the bytes have been byteswapped. So, we now do an explicit
* byteswap. On a little-endian machine, this byteswap and
* the final ntohl cancel out and could be elided.
*/
byte0 = result & 0xff;
byte1 = (result>>8) & 0xff;
byte2 = (result>>16) & 0xff;
byte3 = (result>>24) & 0xff;
crc32 = ((byte0 << 24) |
(byte1 << 16) |
(byte2 << 8) |
byte3);
return (crc32);
}
int
insert_crc32(unsigned char *buffer, unsigned int length)
{
SCTP_message *message;
uint32_t crc32;
message = (SCTP_message *) buffer;
message->common_header.checksum = 0UL;
crc32 = generate_crc32c(buffer,length);
/* and insert it into the message */
message->common_header.checksum = htonl(crc32);
return 1;
}
int
validate_crc32(unsigned char *buffer, unsigned int length)
{
SCTP_message *message;
unsigned int i;
uint32_t original_crc32;
uint32_t crc32;
/* save and zero checksum */
message = (SCTP_message *)buffer;
original_crc32 = ntohl(message->common_header.checksum);
message->common_header.checksum = 0L;
crc32 = generate_crc32c(buffer, length);
return ((original_crc32 == crc32)? 1 : -1);
}
<CODE ENDS>
This text has been modified by multiple errata. It includes modifications from Sections 3.5 and 3.10. It is in final form and is not further updated in this document.
このテキストは、複数のエラッタによって変更されています。セクション3.5および3.10からの変更が含まれています。これは最終的な形式であり、このドキュメントではこれ以上更新されません。
The code was changed to use platform-independent types.
プラットフォームに依存しない型を使用するようにコードが変更されました。
The Gap Ack Blocks in the SACK chunk are intended to be isolated. However, this is not mentioned with normative text.
SACKチャンクのギャップACKブロックは分離することを目的としています。ただし、これは規範的なテキストでは言及されていません。
This issue was reported as part of an errata for [RFC4960] with Errata ID 5202.
この問題は、エラータID 5202の[RFC4960]のエラータの一部として報告されました。
---------
Old text: (Section 3.3.4)
---------
The SACK also contains zero or more Gap Ack Blocks. Each Gap Ack Block acknowledges a subsequence of TSNs received following a break in the sequence of received TSNs. By definition, all TSNs acknowledged by Gap Ack Blocks are greater than the value of the Cumulative TSN Ack.
SACKには0個以上のギャップACKブロックも含まれます。各ギャップACKブロックは、受信したTSNのシーケンスの中断に続いて、受信したTSNのサブシーケンスを確認します。定義により、ギャップACKブロックによって確認応答されたすべてのTSNは、累積TSN ACKの値よりも大きくなります。
---------
New text: (Section 3.3.4)
---------
The SACK also contains zero or more Gap Ack Blocks. Each Gap Ack Block acknowledges a subsequence of TSNs received following a break in the sequence of received TSNs. The Gap Ack Blocks SHOULD be isolated. This means that the TSN just before each Gap Ack Block and the TSN just after each Gap Ack Block have not been received. By definition, all TSNs acknowledged by Gap Ack Blocks are greater than the value of the Cumulative TSN Ack.
SACKには0個以上のギャップACKブロックも含まれます。各ギャップACKブロックは、受信したTSNのシーケンスの中断に続いて、受信したTSNのサブシーケンスを確認します。ギャップACKブロックは分離する必要があります。つまり、各ギャップACKブロックの直前のTSNおよび各ギャップACKブロックの直後のTSNは受信されていません。定義により、ギャップACKブロックによって確認応答されたすべてのTSNは、累積TSN ACKの値よりも大きくなります。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
---------
Old text: (Section 3.3.4)
---------
Gap Ack Blocks:
ギャップACKブロック：
These fields contain the Gap Ack Blocks. They are repeated for each Gap Ack Block up to the number of Gap Ack Blocks defined in the Number of Gap Ack Blocks field. All DATA chunks with TSNs greater than or equal to (Cumulative TSN Ack + Gap Ack Block Start) and less than or equal to (Cumulative TSN Ack + Gap Ack Block End) of each Gap Ack Block are assumed to have been received correctly.
これらのフィールドには、ギャップACKブロックが含まれます。これらは、各ギャップACKブロックについて、[ギャップACKブロックの数]フィールドで定義されたギャップACKブロックの数まで繰り返されます。各Gap Ackブロックの（累積TSN Ack +ギャップAckブロックの開始）以上で（累積TSN Ack +ギャップAckブロックの終了）以下のTSNを持つすべてのDATAチャンクは、正しく受信されたと見なされます。
---------
New text: (Section 3.3.4)
---------
Gap Ack Blocks:
ギャップACKブロック：
These fields contain the Gap Ack Blocks. They are repeated for each Gap Ack Block up to the number of Gap Ack Blocks defined in the Number of Gap Ack Blocks field. All DATA chunks with TSNs greater than or equal to (Cumulative TSN Ack + Gap Ack Block Start) and less than or equal to (Cumulative TSN Ack + Gap Ack Block End) of each Gap Ack Block are assumed to have been received correctly. Gap Ack Blocks SHOULD be isolated. This means that the DATA chunks with TSNs equal to (Cumulative TSN Ack + Gap Ack Block Start - 1) and (Cumulative TSN Ack + Gap Ack Block End + 1) have not been received.
これらのフィールドには、ギャップACKブロックが含まれます。これらは、各ギャップACKブロックについて、[ギャップACKブロックの数]フィールドで定義されたギャップACKブロックの数まで繰り返されます。各Gap Ackブロックの（累積TSN Ack +ギャップAckブロックの開始）以上で（累積TSN Ack +ギャップAckブロックの終了）以下のTSNを持つすべてのDATAチャンクは、正しく受信されたと見なされます。ギャップACKブロックは分離する必要があります。これは、（累積TSN Ack +ギャップACKブロック開始-1）および（累積TSN Ack +ギャップACKブロック終了+ 1）に等しいTSNを持つDATAチャンクが受信されていないことを意味します。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
Normative text describing the intended usage of Gap Ack Blocks has been added.
Gap Ackブロックの使用目的を説明する規範的なテキストが追加されました。
The Stream Sequence Number (SSN) is used for preserving the ordering of user messages within each SCTP stream. The SSN is limited to 16 bits. Therefore, multiple wraparounds of the SSN might happen within the current send window. To allow the receiver to deliver ordered user messages in the correct sequence, the sender should limit the number of user messages per stream.
ストリームシーケンス番号（SSN）は、各SCTPストリーム内のユーザーメッセージの順序を維持するために使用されます。 SSNは16ビットに制限されています。したがって、現在の送信ウィンドウ内でSSNの複数のラップアラウンドが発生する可能性があります。受信者が順序付けられたユーザーメッセージを正しい順序で配信できるようにするには、送信者がストリームあたりのユーザーメッセージの数を制限する必要があります。
---------
Old text: (Section 6.1)
---------
Note: The data sender SHOULD NOT use a TSN that is more than 2**31 - 1 above the beginning TSN of the current send window.
注：データ送信者は、現在の送信ウィンドウの開始TSNの2 ** 31-1以上のTSNを使用してはなりません（SHOULD NOT）。
---------
New text: (Section 6.1)
---------
Note: The data sender SHOULD NOT use a TSN that is more than 2**31 - 1 above the beginning TSN of the current send window. Note: For each stream, the data sender SHOULD NOT have more than 2**16 - 1 ordered user messages in the current send window.
注：データ送信者は、現在の送信ウィンドウの開始TSNの2 ** 31-1以上のTSNを使用してはなりません（SHOULD NOT）。注：ストリームごとに、データ送信者は、現在の送信ウィンドウに2 ** 16-1を超える順序付けされたユーザーメッセージを持つべきではありません（SHOULD NOT）。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
The data sender is required to limit the number of ordered user messages within the current send window.
データ送信者は、現在の送信ウィンドウ内で注文されたユーザーメッセージの数を制限する必要があります。
The text to be used to refer to the terms ("key words") defined in [RFC2119] has been updated by [RFC8174]. This needs to be integrated into the base specification.
[RFC2119]で定義されている用語（「キーワード」）を参照するために使用されるテキストは、[RFC8174]によって更新されました。これは、基本仕様に統合する必要があります。
---------
Old text: (Section 2)
---------
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
---------
New text: (Section 2)
---------
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]で説明されているように解釈されます。
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
The text has been updated to the text specified in [RFC8174].
テキストは[RFC8174]で指定されたテキストに更新されました。
When integrating the changes to Section 7.2.4 of [RFC2960] as described in Section 2.8.2 of [RFC4460], some text was not removed and is therefore still in [RFC4960].
[RFC4460]のセクション2.8.2で説明されているように、[RFC2960]のセクション7.2.4への変更を統合する場合、一部のテキストは削除されなかったため、まだ[RFC4960]にあります。
---------
Old text: (Section 7.2.4)
---------
A straightforward implementation of the above keeps a counter for each TSN hole reported by a SACK. The counter increments for each consecutive SACK reporting the TSN hole. After reaching 3 and starting the Fast-Retransmit procedure, the counter resets to 0. Because cwnd in SCTP indirectly bounds the number of outstanding TSN's, the effect of TCP Fast Recovery is achieved automatically with no adjustment to the congestion control window size.
上記の簡単な実装は、SACKによって報告された各TSNホールのカウンターを保持します。 TSNホールを報告する連続するSACKごとにカウンターが増加します。 3に達し、Fast-Retransmitプロシージャを開始すると、カウンターは0にリセットされます。SCTPのcwndは未解決のTSNの数を間接的に制限するため、輻輳制御ウィンドウサイズを調整せずに、TCP Fast Recoveryの効果が自動的に達成されます。
---------
New text: (Section 7.2.4)
---------
This text is in final form and is not further updated in this document.
このテキストは最終的な形式であり、このドキュメントではこれ以上更新されません。
The text has finally been removed.
最終的にテキストが削除されました。
Section 3.44 of this document suggests new text that would update the "Service Name and Transport Protocol Port Number Registry" for SCTP to be consistent with [RFC6335].
このドキュメントのセクション3.44は、SCTPが[RFC6335]と整合するように「サービス名とトランスポートプロトコルのポート番号レジストリ」を更新する新しいテキストを提案しています。
IANA has confirmed that it is OK to make the proposed text change in an upcoming Standards Track document that will update [RFC4960]. IANA is not asked to perform any other action, and this document does not request that IANA make a change to any registry.
IANAは、[RFC4960]を更新する次のStandards Trackドキュメントで提案されているテキストを変更してもよいことを確認しました。 IANAは他のアクションを実行するように求められていません。このドキュメントでは、IANAがレジストリを変更することを要求していません。
This document does not add any security considerations to those given in [RFC4960].
このドキュメントは、[RFC4960]で与えられたものにセキュリティ上の考慮事項を追加しません。
[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>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, DOI 10.17487/RFC4960, September 2007, <https://www.rfc-editor.org/info/rfc4960>.
[RFC4960] Stewart、R.、Ed。、「Stream Control Transmission Protocol」、RFC 4960、DOI 10.17487 / RFC4960、2007年9月、<https://www.rfc-editor.org/info/rfc4960>。
[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>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <https://www.rfc-editor.org/info/rfc1122>.
[RFC1122] Braden、R。、編、「インターネットホストの要件-通信層」、STD 3、RFC 1122、DOI 10.17487 / RFC1122、1989年10月、<https://www.rfc-editor.org/info/ rfc1122>。
[RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security Considerations for IP Fragment Filtering", RFC 1858, DOI 10.17487/RFC1858, October 1995, <https://www.rfc-editor.org/info/rfc1858>.
[RFC1858] Ziemba、G.、Reed、D。、およびP. Traina、「IPフラグメントフィルタリングのセキュリティに関する考慮事項」、RFC 1858、DOI 10.17487 / RFC1858、1995年10月、<https://www.rfc-editor.org / info / rfc1858>。
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, DOI 10.17487/RFC2960, October 2000, <https://www.rfc-editor.org/info/rfc2960>.
[RFC2960]スチュワート、R。、シェイ、Q。、モーノー、K。、シャープ、C。、シュワルツバウアー、H。、テイラー、T。、リティナ、I。、カラ、M。、チャン、L.、V Paxson、「Stream Control Transmission Protocol」、RFC 2960、DOI 10.17487 / RFC2960、2000年10月、<https://www.rfc-editor.org/info/rfc2960>。
[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>.
[RFC3168]ラマクリシュナン、K。、フロイド、S。、およびD.ブラック、「IPへの明示的輻輳通知（ECN）の追加」、RFC 3168、DOI 10.17487 / RFC3168、2001年9月、<https：// www。 rfc-editor.org/info/rfc3168>。
[RFC4460] Stewart, R., Arias-Rodriguez, I., Poon, K., Caro, A., and M. Tuexen, "Stream Control Transmission Protocol (SCTP) Specification Errata and Issues", RFC 4460, DOI 10.17487/RFC4460, April 2006, <https://www.rfc-editor.org/info/rfc4460>.
[RFC4460] Stewart、R.、Arias-Rodriguez、I.、Poon、K.、Caro、A。、およびM. Tuexen、「Stream Control Transmission Protocol（SCTP）Specification Errata and Issues」、RFC 4460、DOI 10.17487 / RFC4460、2006年4月、<https://www.rfc-editor.org/info/rfc4460>。
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, <https://www.rfc-editor.org/info/rfc5681>.
[RFC5681] Allman、M.、Paxson、V。、およびE. Blanton、「TCP Congestion Control」、RFC 5681、DOI 10.17487 / RFC5681、2009年9月、<https://www.rfc-editor.org/info/ rfc5681>。
[RFC6096] Tuexen, M. and R. Stewart, "Stream Control Transmission Protocol (SCTP) Chunk Flags Registration", RFC 6096, DOI 10.17487/RFC6096, January 2011, <https://www.rfc-editor.org/info/rfc6096>.
[RFC6096] Tuexen、M。、およびR. Stewart、「Stream Control Transmission Protocol（SCTP）Chunk Flags Registration」、RFC 6096、DOI 10.17487 / RFC6096、2011年1月、<https://www.rfc-editor.org/info / rfc6096>。
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, DOI 10.17487/RFC6298, June 2011, <https://www.rfc-editor.org/info/rfc6298>.
[RFC6298] Paxson、V.、Allman、M.、Chu、J。、およびM. Sargent、「Computing TCP's Retransmission Timer」、RFC 6298、DOI 10.17487 / RFC6298、2011年6月、<https：//www.rfc- editor.org/info/rfc6298>。
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <https://www.rfc-editor.org/info/rfc6335>.
[RFC6335]綿、M。、エガート、L。、タッチ、J。、ウェスターランド、M。、およびS.チェシャー、「サービス名とトランスポートプロトコルのポート番号レジストリの管理のためのInternet Assigned Numbers Authority（IANA）手順"、BCP 165、RFC 6335、DOI 10.17487 / RFC6335、2011年8月、<https://www.rfc-editor.org/info/rfc6335>。
[RFC7053] Tuexen, M., Ruengeler, I., and R. Stewart, "SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol", RFC 7053, DOI 10.17487/RFC7053, November 2013, <https://www.rfc-editor.org/info/rfc7053>.
[RFC7053] Tuexen、M.、Ruengeler、I。、およびR. Stewart、「SACK-IMMEDIATELY Extension for the Stream Control Transmission Protocol」、RFC 7053、DOI 10.17487 / RFC7053、2013年11月、<https：//www.rfc -editor.org/info/rfc7053>。
[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>.
[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>.
[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>.
[RFC8311]ブラック、D。、「明示的な輻輳通知（ECN）実験に関する制限の緩和」、RFC 8311、DOI 10.17487 / RFC8311、2018年1月、<https://www.rfc-editor.org/info/rfc8311>。
Acknowledgements
謝辞
The authors wish to thank Pontus Andersson, Eric W. Biederman, Cedric Bonnet, Spencer Dawkins, Gorry Fairhurst, Benjamin Kaduk, Mirja Kuehlewind, Peter Lei, Gyula Marosi, Lionel Morand, Jeff Morriss, Karen E. E. Nielsen, Tom Petch, Kacheong Poon, Julien Pourtet, Irene Ruengeler, Michael Welzl, and Qiaobing Xie for their invaluable comments.
The authors wish to thank Pontus Andersson, Eric W. Biederman, Cedric Bonnet, Spencer Dawkins, Gorry Fairhurst, Benjamin Kaduk, Mirja Kuehlewind, Peter Lei, Gyula Marosi, Lionel Morand, Jeff Morriss, Karen E. E. Nielsen, Tom Petch, Kacheong Poon, Julien Pourtet, Irene Ruengeler, Michael Welzl, and Qiaobing Xie for their invaluable comments.
Authors' Addresses
Authors' Addresses
Randall R. Stewart Netflix, Inc. Chapin, SC 29036 United States of America
Randall R. Stewart Netflix、Inc. Chapin、SC 29036アメリカ合衆国
Email: randall@lakerest.net
Michael Tuexen Muenster University of Applied Sciences Stegerwaldstrasse 39 48565 Steinfurt Germany
Michael Tuexen Muenster応用科学大学Stegerwaldstrasse 39 48565シュタインフルトドイツ
Email: tuexen@fh-muenster.de
Maksim Proshin Ericsson Kistavaegen 25 Stockholm 164 80 Sweden
Maksim Proshin Ericsson Kistavaegen 25ストックホルム164 80スウェーデン
Email: mproshin@tieto.mera.ru