[要約] 要約：RFC 4460は、Stream Control Transmission Protocol（SCTP）の仕様に関する誤りと問題を修正するための文書です。 目的：このRFCの目的は、SCTPの仕様に関する誤りや問題を特定し、それらを修正することによって、SCTPの正確性と信頼性を向上させることです。
Network Working Group R. Stewart
Request for Comments: 4460 Cisco Systems, Inc.
Category: Informational I. Arias-Rodriguez
Nokia Research Center
K. Poon
Sun Microsystems, Inc.
A. Caro
BBN Technologies
M. Tuexen
Muenster Univ. of Applied Sciences
April 2006
Stream Control Transmission Protocol (SCTP) Specification Errata and Issues
ストリーム制御伝送プロトコル（SCTP）仕様のエラッタと問題
Status of This Memo
本文書の状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準も規定していません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（C）The Internet Society（2006）。
Abstract
概要
This document is a compilation of issues found during six interoperability events and 5 years of experience with implementing, testing, and using Stream Control Transmission Protocol (SCTP) along with the suggested fixes. This document provides deltas to RFC 2960 and is organized in a time-based way. The issues are listed in the order 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 delta, a description of the problem and the details of the solution are also provided.
このドキュメントは、6つの相互運用性イベントで発見された問題をまとめたもので、ストリームコントロールトランスミッションプロトコル（SCTP）の実装、テスト、および使用に関する5年間の経験と推奨される修正をまとめたものです。このドキュメントはRFC 2960の差分を提供し、時間ベースの方法で編成されています。問題は、取り上げられた順にリストされています。一部のテキストは複数回変更されるため、テキストの最後のデルタが適用される必要があります。デルタに加えて、問題の説明とソリューションの詳細も提供されます。
Table of Contents
目次
1. Introduction ....................................................6
1.1. Conventions ................................................7
2. Corrections to RFC 2960 .........................................7
2.1. Incorrect Error Type During Chunk Processing. ..............7
2.1.1. Description of the Problem ..........................7
2.1.2. Text changes to the document ........................7
2.1.3. Solution Description ................................7
2.2. Parameter Processing Issue .................................7
2.2.1. Description of the Problem ..........................7
2.2.2. Text Changes to the Document ........................8
2.2.3. Solution Description ................................8
2.3. Padding Issues .............................................8
2.3.1. Description of the Problem ..........................8
2.3.2. Text Changes to the Document ........................9
2.3.3. Solution Description ...............................10
2.4. Parameter Types across All Chunk Types ....................10
2.4.1. Description of the Problem .........................10
2.4.2. Text Changes to the Document .......................10
2.4.3. Solution Description ...............................12
2.5. Stream Parameter Clarification ............................12
2.5.1. Description of the problem .........................12
2.5.2. Text Changes to the Document .......................12
2.5.3. Solution Description ...............................13
2.6. Restarting Association Security Issue .....................13
2.6.1. Description of the Problem .........................13
2.6.2. Text Changes to the Document .......................14
2.6.3. Solution Description ...............................18
2.7. Implicit Ability to Exceed cwnd by PMTU-1 Bytes ...........19
2.7.1. Description of the Problem .........................19
2.7.2. Text Changes to the Document .......................19
2.7.3. Solution Description ...............................19
2.8. Issues with Fast Retransmit ...............................19
2.8.1. Description of the Problem .........................19
2.8.2. Text Changes to the Document .......................20
2.8.3. Solution Description ...............................23
2.9. Missing Statement about partial_bytes_acked Update ........24
2.9.1. Description of the Problem .........................24
2.9.2. Text Changes to the Document .......................24
2.9.3. Solution Description ...............................25
2.10. Issues with Heartbeating and Failure Detection ...........25
2.10.1. Description of the Problem ........................25
2.10.2. Text Changes to the Document ......................26
2.10.3. Solution Description ..............................28
2.11. Security interactions with firewalls .....................29
2.11.1. Description of the Problem ........................29
2.11.2. Text Changes to the Document ......................29
2.11.3. Solution Description ..............................31
2.12. Shutdown Ambiguity .......................................31
2.12.1. Description of the Problem ........................31
2.12.2. Text Changes to the Document ......................31
2.12.3. Solution Description ..............................32
2.13. Inconsistency in ABORT Processing ........................32
2.13.1. Description of the Problem ........................32
2.13.2. Text changes to the document ......................33
2.13.3. Solution Description ..............................33
2.14. Cwnd Gated by Its Full Use ...............................34
2.14.1. Description of the Problem ........................34
2.14.2. Text Changes to the Document ......................34
2.14.3. Solution Description ..............................36
2.15. Window Probes in SCTP ....................................36
2.15.1. Description of the Problem ........................36
2.15.2. Text Changes to the Document ......................36
2.15.3. Solution Description ..............................38
2.16. Fragmentation and Path MTU Issues ........................39
2.16.1. Description of the Problem ........................39
2.16.2. Text Changes to the Document ......................39
2.16.3. Solution Description ..............................40
2.17. Initial Value of the Cumulative TSN Ack ..................40
2.17.1. Description of the Problem ........................40
2.17.2. Text Changes to the Document ......................40
2.17.3. Solution Description ..............................41
2.18. Handling of Address Parameters within the INIT or
INIT-ACK .................................................41
2.18.1. Description of the Problem ........................41
2.18.2. Text Changes to the Document ......................41
2.18.3. Solution description ..............................42
2.19. Handling of Stream Shortages .............................42
2.19.1. Description of the Problem ........................42
2.19.2. Text Changes to the Document ......................42
2.19.3. Solution Description ..............................43
2.20. Indefinite Postponement ..................................43
2.20.1. Description of the Problem ........................43
2.20.2. Text Changes to the Document ......................43
2.20.3. Solution Description ..............................44
2.21. User-Initiated Abort of an Association ...................44
2.21.1. Description of the Problem ........................44
2.21.2. Text changes to the document ......................44
2.21.3. Solution Description ..............................50
2.22. Handling of Invalid Initiate Tag of INIT-ACK .............50
2.22.1. Description of the Problem ........................50
2.22.2. Text Changes to the Document ......................50
2.22.3. Solution Description ..............................51
2.23. Sending an ABORT in Response to an INIT ..................51
2.23.1. Description of the Problem ........................51
2.23.2. Text Changes to the Document ......................51
2.23.3. Solution Description ..............................52
2.24. Stream Sequence Number (SSN) Initialization ..............52
2.24.1. Description of the Problem ........................52
2.24.2. Text Changes to the Document ......................52
2.24.3. Solution Description ..............................53
2.25. SACK Packet Format .......................................53
2.25.1. Description of the Problem ........................53
2.25.2. Text Changes to the Document ......................53
2.25.3. Solution Description ..............................53
2.26. Protocol Violation Error Cause ...........................53
2.26.1. Description of the Problem ........................53
2.26.2. Text Changes to the Document ......................54
2.26.3. Solution Description ..............................56
2.27. Reporting of Unrecognized Parameters .....................56
2.27.1. Description of the Problem ........................56
2.27.2. Text Changes to the Document ......................56
2.27.3. Solution Description ..............................57
2.28. Handling of IP Address Parameters ........................58
2.28.1. Description of the Problem ........................58
2.28.2. Text Changes to the Document ......................58
2.28.3. Solution Description ..............................58
2.29. Handling of COOKIE ECHO Chunks When a TCB Exists .........59
2.29.1. Description of the Problem ........................59
2.29.2. Text Changes to the Document ......................59
2.29.3. Solution Description ..............................59
2.30. The Initial Congestion Window Size .......................59
2.30.1. Description of the Problem ........................59
2.30.2. Text Changes to the Document ......................60
2.30.3. Solution Description ..............................61
2.31. Stream Sequence Numbers in Figures .......................62
2.31.1. Description of the Problem ........................62
2.31.2. Text Changes to the Document ......................63
2.31.3. Solution description ..............................67
2.32. Unrecognized Parameters ..................................67
2.32.1. Description of the Problem ........................67
2.32.2. Text Changes to the Document ......................67
2.32.3. Solution Description ..............................68
2.33. Handling of Unrecognized Parameters ......................68
2.33.1. Description of the Problem ........................68
2.33.2. Text Changes to the Document ......................68
2.33.3. Solution Description ..............................70
2.34. Tie Tags .................................................70
2.34.1. Description of the Problem ........................70
2.34.2. Text Changes to the Document ......................70
2.34.3. Solution Description ..............................72
2.35. Port Number Verification in the COOKIE-ECHO ..............72
2.35.1. Description of the Problem ........................72
2.35.2. Text Changes to the Document ......................72
2.35.3. Solution Description ..............................73
2.36. Path Initialization ......................................74
2.36.1. Description of the Problem ........................74
2.36.2. Text Changes to the Document ......................74
2.36.3. Solution Description ..............................76
2.37. ICMP Handling Procedures .................................76
2.37.1. Description of the Problem ........................76
2.37.2. Text Changes to the Document ......................77
2.37.3. Solution Description ..............................79
2.38. Checksum .................................................79
2.38.1. Description of the problem ........................79
2.38.2. Text Changes to the Document ......................79
2.38.3. Solution Description ..............................86
2.39. Retransmission Policy ....................................86
2.39.1. Description of the Problem ........................86
2.39.2. Text Changes to the Document ......................87
2.39.3. Solution Description ..............................87
2.40. Port Number 0 ............................................88
2.40.1. Description of the Problem ........................88
2.40.2. Text Changes to the Document ......................88
2.40.3. Solution Description ..............................89
2.41. T Bit ....................................................89
2.41.1. Description of the Problem ........................89
2.41.2. Text Changes to the Document ......................89
2.41.3. Solution Description ..............................93
2.42. Unknown Parameter Handling ...............................93
2.42.1. Description of the Problem ........................93
2.42.2. Text Changes to the Document ......................93
2.42.3. Solution Description ..............................95
2.43. Cookie Echo Chunk ........................................95
2.43.1. Description of the Problem ........................95
2.43.2. Text Changes to the Document ......................95
2.43.3. Solution Description ..............................96
2.44. Partial Chunks ...........................................96
2.44.1. Description of the Problem ........................96
2.44.2. Text Changes to the Document ......................96
2.44.3. Solution Description ..............................97
2.45. Non-unicast Addresses ....................................97
2.45.1. Description of the Problem ........................97
2.45.2. Text Changes to the Document ......................97
2.45.3. Solution Description ..............................98
2.46. Processing of ABORT Chunks ...............................98
2.46.1. Description of the Problem ........................98
2.46.2. Text Changes to the Document ......................98
2.46.3. Solution Description ..............................98
2.47. Sending of ABORT Chunks ..................................99
2.47.1. Description of the Problem ........................99
2.47.2. Text Changes to the Document ......................99
2.47.3. Solution Description ..............................99
2.48. Handling of Supported Address Types Parameter ............99
2.48.1. Description of the Problem ........................99
2.48.2. Text Changes to the Document .....................100
2.48.3. Solution Description .............................100
2.49. Handling of Unexpected Parameters .......................101
2.49.1. Description of the Problem .......................101
2.49.2. Text Changes to the Document .....................101
2.49.3. Solution Description .............................102
2.50. Payload Protocol Identifier .............................102
2.50.1. Description of the Problem .......................102
2.50.2. Text Changes to the Document .....................103
2.50.3. Solution Description .............................103
2.51. Karn's Algorithm ........................................104
2.51.1. Description of the Problem .......................104
2.51.2. Text Changes to the Document .....................104
2.51.3. Solution Description .............................104
2.52. Fast Retransmit Algorithm ...............................104
2.52.1. Description of the Problem .......................104
2.52.2. Text Changes to the Document .....................105
2.52.3. Solution Description .............................105
3. Security Considerations .......................................105
4. Acknowledgements ..............................................106
5. IANA Considerations ...........................................106
6. Normative References ..........................................106
This document contains a compilation of all defects found up until the publishing of this document for the Stream Control Transmission Protocol (SCTP), RFC 2960 [5]. 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 SCTP to clarify errors in the original SCTP document.
このドキュメントには、ストリームコントロールトランスミッションプロトコル（SCTP）、RFC 2960 [5]に関するこのドキュメントの公開までに発見されたすべての欠陥の編集が含まれています。これらの欠陥は、編集上または技術上の性質を持つ可能性があります。このドキュメントは、元のSCTPドキュメントのエラーを明確にするためにSCTPの実装で使用される関連ドキュメントと考えることができます。
This document provides a history of the changes that will be compiled into RFC 2960's [5] BIS document. Each error will be detailed within this document in the form of
このドキュメントは、RFC 2960の[5] BISドキュメントにまとめられる変更の履歴を提供します。各エラーは、このドキュメント内で次の形式で詳しく説明されます
o the problem description,
o 問題の説明
o the text quoted from RFC 2960 [5],
o RFC 2960 [5]から引用されたテキスト、
o the replacement text that should be placed into the BIS document, and
o BIS文書に配置する必要がある置換テキスト、および
o a description of the solution.
o ソリューションの説明。
This document is a historical record of sequential changes what have been found necessary at various interop events and through discussion on this list.
このドキュメントは、さまざまな相互運用イベントでこのリストでの議論を通じて必要であることが判明した一連の変更の履歴レコードです。
Note that because some text is changed several times, the last delta for a text in the document is the erratum for that text in RFC 2960.
一部のテキストは何度か変更されるため、ドキュメント内のテキストの最後のデルタはRFC 2960のそのテキストの正誤表であることに注意してください。
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [2].
このドキュメントに記載されているキーワードは、必須、必須、必須、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、NOT RECOMMENDED、MAY、およびOPTIONALであり、RFC 2119 [2]に記載されているように解釈されます。
2.1. Incorrect Error Type During Chunk Processing.
2.1. チャンク処理中の誤ったエラータイプ。
A typo was discovered in RFC 2960 [5] that incorrectly specifies an action to be taken when processing chunks of unknown identity.
RFC 2960 [5]で、不明なIDのチャンクを処理するときに実行するアクションを誤って指定するタイプミスが発見されました。
---------
Old text: (Section 3.2)
---------
01 - Stop processing this SCTP packet and discard it, do not process any further chunks within it, and report the unrecognized parameter in an 'Unrecognized Parameter Type' (in either an ERROR or in the INIT ACK).
01-このSCTPパケットの処理を停止して破棄し、その中のそれ以上のチャンクを処理せずに、「認識されないパラメータタイプ」（エラーまたはINIT ACKのいずれか）で認識されないパラメータを報告します。
---------
New text: (Section 3.2)
---------
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」で報告します。
The receiver of an unrecognized chunk should not send a 'parameter' error but instead should send the appropriate chunk error as described above.
認識されないチャンクの受信者は、「パラメーター」エラーを送信するべきではなく、上記のように適切なチャンクエラーを送信する必要があります。
A typographical error was introduced through an improper cut and paste in the use of the upper two bits to describe proper handling of unknown parameters.
不明なパラメータの適切な処理を説明するために、上位2ビットを使用して不適切なカットアンドペーストを行うことにより、誤植が発生しました。
---------
Old text: (Section 3.2.1)
---------
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 parameter in an 'Unrecognized Parameter Type' (in either an ERROR or in the INIT ACK).
01-このSCTPパケットの処理を停止して破棄し、その中のそれ以上のチャンクを処理せずに、「認識されないパラメータタイプ」（エラーまたはINIT ACKのいずれか）で認識されないパラメータを報告します。
---------
New text: (Section 3.2.1)
---------
00 - Stop processing this SCTP chunk and discard it, do not process any further parameters within this chunk.
00-このSCTPチャンクの処理を停止して破棄します。このチャンク内でこれ以上パラメーターを処理しないでください。
01 - Stop processing this SCTP chunk and discard it, do not process any further parameters within this chunk, and report the unrecognized parameter in an 'Unrecognized Parameter Type' (in either an ERROR or in the INIT ACK).
01-このSCTPチャンクの処理を停止して破棄し、このチャンク内のそれ以上のパラメーターを処理せず、「認識されないパラメータータイプ」（エラーまたはINIT ACKのいずれか）で認識されないパラメーターを報告します。
It was always the intent to stop processing at the level one was at in an unknown chunk or parameter with the upper bit set to 0. Thus, if you are processing a chunk, you should drop the packet. If you are processing a parameter, you should drop the chunk.
常に、上位ビットが0に設定されている不明なチャンクまたはパラメーターのレベルで処理を停止することを意図していたため、チャンクを処理している場合は、パケットをドロップする必要があります。パラメータを処理している場合は、チャンクを削除する必要があります。
A problem was found when a Chunk terminated in a TLV parameter. If this last TLV was not on a 32-bit boundary (as required), there was confusion as to whether the last padding was included in the chunk length.
チャンクがTLVパラメータで終了したときに問題が見つかりました。この最後のTLVが（必要に応じて）32ビット境界上にない場合、最後のパディングがチャンク長に含まれているかどうかに関して混乱がありました。
---------
Old text: (Section 3.2)
---------
Chunk Length: 16 bits (unsigned integer)
チャンク長：16ビット（符号なし整数）
This value represents the size of the chunk in bytes including the Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields. Therefore, if the Chunk Value field is zero-length, the Length field will be set to 4. The Chunk Length field does not count any padding.
この値は、チャンクタイプ、チャンクフラグ、チャンク長、およびチャンク値フィールドを含むバイト単位のチャンクのサイズを表します。したがって、「チャンク値」フィールドの長さがゼロの場合、「長さ」フィールドは4に設定されます。「チャンクの長さ」フィールドは、パディングをカウントしません。
Chunk Value: variable length
チャンク値：可変長
The Chunk Value field contains the actual information to be transferred in the chunk. The usage and format of this field is dependent on the Chunk Type.
チャンク値フィールドには、チャンクで転送される実際の情報が含まれています。このフィールドの使用法と形式は、チャンクタイプによって異なります。
The total length of a chunk (including Type, Length and Value fields) MUST be a multiple of 4 bytes. If the length of the chunk is not a multiple of 4 bytes, the sender MUST pad the chunk with all zero bytes and this padding is not included in the chunk length field. The sender should never pad with more than 3 bytes. The receiver MUST ignore the padding bytes.
チャンクの全長（Type、Length、Valueフィールドを含む）は、4バイトの倍数でなければなりません。チャンクの長さが4バイトの倍数でない場合、送信者はチャンクをすべてゼロバイトでパディングする必要があり、このパディングはチャンク長フィールドに含まれません。送信者は、3バイトを超えてパディングしないでください。レシーバーはパディングバイトを無視する必要があります。
---------
New text: (Section 3.2)
---------
Chunk Length: 16 bits (unsigned integer)
チャンク長：16ビット（符号なし整数）
This value represents the size of the chunk in bytes, including the Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields. Therefore, if the Chunk Value field is zero-length, the Length field will be set to 4. The Chunk Length field does not count any chunk padding.
この値は、チャンクタイプ、チャンクフラグ、チャンク長、チャンク値フィールドなど、チャンクのサイズをバイト単位で表します。したがって、チャンク値フィールドの長さがゼロの場合、長さフィールドは4に設定されます。チャンク長フィールドは、チャンクパディングをカウントしません。
Chunks (including Type, Length, and Value fields) are padded out by the sender with all zero bytes to be a multiple of 4 bytes long. This padding MUST NOT be more than 3 bytes in total. The Chunk Length value does not include terminating padding of the chunk. However, it does include padding of any variable-length parameter except the last parameter in the chunk. The receiver MUST ignore the padding.
チャンク（タイプ、長さ、および値フィールドを含む）は、すべてゼロバイトで長さが4バイトの倍数になるように送信者によって埋め込まれます。このパディングは、合計で3バイトを超えてはなりません。 Chunk Length値には、チャンクの終了パディングは含まれません。ただし、チャンク内の最後のパラメーターを除くすべての可変長パラメーターのパディングが含まれます。レシーバーはパディングを無視しなければなりません。
Note: A robust implementation should accept the Chunk whether or not the final padding has been included in the Chunk Length.
注：堅牢な実装は、最終的なパディングがチャンク長に含まれているかどうかに関係なく、チャンクを受け入れる必要があります。
Chunk Value: variable length
チャンク値：可変長
The Chunk Value field contains the actual information to be transferred in the chunk. The usage and format of this field is dependent on the Chunk Type.
チャンク値フィールドには、チャンクで転送される実際の情報が含まれています。このフィールドの使用法と形式は、チャンクタイプによって異なります。
The total length of a chunk (including Type, Length, and Value fields) MUST be a multiple of 4 bytes. If the length of the chunk is not a multiple of 4 bytes, the sender MUST pad the chunk with all zero bytes, and this padding is not included in the chunk length field. The sender should never pad with more than 3 bytes. The receiver MUST ignore the padding bytes.
チャンクの全長（Type、Length、Valueフィールドを含む）は、4バイトの倍数でなければなりません。チャンクの長さが4バイトの倍数でない場合、送信者はチャンクをすべてゼロバイトで埋める必要があり、この埋め込みはチャンク長フィールドに含まれません。送信者は、3バイトを超えてパディングしないでください。レシーバーはパディングバイトを無視する必要があります。
The above text makes clear that the padding of the last parameter is not included in the Chunk Length field. It also clarifies that the padding of parameters that are not the last one must be counted in the Chunk Length field.
上記のテキストは、最後のパラメーターのパディングが「チャンク長」フィールドに含まれていないことを明確にしています。また、最後ではないパラメーターのパディングは、[チャンク長]フィールドでカウントする必要があることも明確にしています。
A problem was noted when multiple errors are needed to be sent regarding unknown or unrecognized parameters. Since often the error type does not hold the chunk type field, it may become difficult to tell which error was associated with which chunk.
不明または認識されないパラメーターに関して複数のエラーを送信する必要がある場合、問題が指摘されました。多くの場合、エラータイプはチャンクタイプフィールドを保持しないため、どのエラーがどのチャンクに関連付けられていたかを判別するのが難しくなる場合があります。
---------
Old text: (Section 3.2.1)
---------
The actual SCTP parameters are defined in the specific SCTP chunk sections. The rules for IETF-defined parameter extensions are defined in Section 13.2.
実際のSCTPパラメータは、特定のSCTPチャンクセクションで定義されます。 IETFで定義されたパラメータ拡張のルールは、セクション13.2で定義されています。
---------
New text: (Section 3.2.1)
---------
The actual SCTP parameters are defined in the specific SCTP chunk sections. The rules for IETF-defined parameter extensions are defined in Section 13.2. Note that a parameter type MUST be unique across all chunks. For example, the parameter type '5' is used to represent an IPv4 address (see Section 3.3.2). The value '5' then is reserved across all chunks to represent an IPv4 address and MUST NOT be reused with a different meaning in any other chunk.
実際のSCTPパラメータは、特定のSCTPチャンクセクションで定義されます。 IETFで定義されたパラメータ拡張のルールは、セクション13.2で定義されています。パラメータタイプはすべてのチャンクで一意である必要があることに注意してください。たとえば、パラメータタイプ「5」はIPv4アドレスを表すために使用されます（セクション3.3.2を参照）。次に、値「5」はIPv4アドレスを表すためにすべてのチャンクにわたって予約され、他のチャンクでは異なる意味で再利用してはいけません。
---------
Old text: (Section 13.2)
---------
13.2 IETF-defined Chunk Parameter Extension
13.2 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) Name of the parameter type.
a) パラメータタイプの名前。
b) Detailed description of the structure of the parameter field. This structure MUST conform to the general type-length-value format described in Section 3.2.1.
b) パラメータフィールドの構造の詳細な説明。この構造は、セクション3.2.1で説明されている一般的なtype-length-value形式に準拠する必要があります。
c) Detailed definition of each component of the parameter type.
c) パラメータタイプの各コンポーネントの詳細な定義。
d) Detailed description of the intended use of this parameter type, and an indication of whether and under what circumstances multiple instances of this parameter type may be found within the same chunk.
d) このパラメータータイプの使用目的の詳細な説明、およびこのパラメータータイプの複数のインスタンスが同じチャンク内で見つかるかどうか、またどのような状況下にあるかを示します。
---------
New text: (Section 13.2)
---------
13.2. IETF-defined Chunk Parameter Extension
13.2. 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) Name of the parameter type.
a) パラメータタイプの名前。
b) Detailed description of the structure of the parameter field. This structure MUST conform to the general type-length-value format described in Section 3.2.1.
b) パラメータフィールドの構造の詳細な説明。この構造は、セクション3.2.1で説明されている一般的なtype-length-value形式に準拠する必要があります。
c) Detailed definition of each component of the parameter type.
c) パラメータタイプの各コンポーネントの詳細な定義。
d) Detailed description of the intended use of this parameter type, and an indication of whether and under what circumstances multiple instances of this parameter type may be found within the same chunk.
d) このパラメータータイプの使用目的の詳細な説明、およびこのパラメータータイプの複数のインスタンスが同じチャンク内で見つかるかどうか、またどのような状況下にあるかを示します。
e) Each parameter type MUST be unique across all chunks.
e) 各パラメータタイプは、すべてのチャンクで一意である必要があります。
By having all parameters unique across all chunk assignments (the current assignment policy), no ambiguity exists as to what a parameter means in different contexts. The trade-off for this is a smaller parameter space, i.e., 65,536 parameters versus 65,536 * Number-of- chunks.
すべてのパラメーターをすべてのチャンク割り当て（現在の割り当てポリシー）全体で一意にすることで、パラメーターが異なるコンテキストで何を意味するかについてのあいまいさがなくなります。これのトレードオフは、より小さなパラメーター空間です。つまり、65,536のパラメーターと65,536 *チャンクの数の関係です。
A problem was found where the specification is unclear on the legality of an endpoint asking for more stream resources than were allowed in the MIS value of the INIT. In particular, the value in the INIT ACK requested in its OS value was larger than the MIS value received in the INIT chunk. This behavior is illegal, yet it was unspecified in RFC 2960 [5]
INITのMIS値で許可されているよりも多くのストリームリソースを要求するエンドポイントの合法性について仕様が不明確である問題が見つかりました。特に、OS値で要求されたINIT ACKの値が、INITチャンクで受信したMIS値よりも大きかった。この動作は違法ですが、RFC 2960 [5]では規定されていません。
---------
Old text: (Section 3.3.3)
---------
Number of Outbound Streams (OS): 16 bits (unsigned integer)
アウトバウンドストリーム数（OS）：16ビット（符号なし整数）
Defines the number of outbound streams the sender of this INIT ACK chunk wishes to create in this association. The value of 0 MUST NOT be used.
このアソシエーションでこのINIT ACKチャンクの送信者が作成したいアウトバウンドストリームの数を定義します。値0は使用してはなりません。
Note: A receiver of an INIT ACK with the OS value set to 0 SHOULD destroy the association discarding its TCB.
注：OS値が0に設定されたINIT ACKの受信者は、そのTCBを破棄して関連付けを破棄する必要があります（SHOULD）。
---------
New text: (Section 3.3.3)
---------
Number of Outbound Streams (OS): 16 bits (unsigned integer)
アウトバウンドストリーム数（OS）：16ビット（符号なし整数）
Defines the number of outbound streams the sender of this INIT ACK chunk wishes to create in this association. The value of 0 MUST NOT be used, and the value MUST NOT be greater than the MIS value sent in the INIT chunk.
このアソシエーションでこのINIT ACKチャンクの送信者が作成したいアウトバウンドストリームの数を定義します。値0は使用してはならず（MUST NOT）、その値はINITチャンクで送信されたMIS値よりも大きくしてはなりません（MUST NOT）。
Note: A receiver of an INIT ACK with the OS value set to 0 SHOULD destroy the association, discarding its TCB.
注：OS値が0に設定されたINIT ACKの受信側は、関連付けを破棄して、そのTCBを破棄する必要があります（SHOULD）。
The change in wording, above, changes it so that a responder to an INIT chunk does not specify more streams in its OS value than were represented to it in the MIS value, i.e., its maximum.
上記の表現の変更は、INITチャンクへのレスポンダーがそのMIS値で表されたストリームよりも多くのストリーム、つまりその最大値をOS値で指定しないように変更します。
A security problem was found when a restart occurs. It is possible for an intruder to send an INIT to an endpoint of an existing association. In the INIT the intruder would list one or more of the current addresses of an association and its own. The normal restart procedures would then occur, and the intruder would have hijacked an association.
再起動時にセキュリティの問題が見つかりました。侵入者が既存の関連付けのエンドポイントにINITを送信する可能性があります。 INITでは、侵入者は関連付けの現在のアドレスとそのアドレスの1つ以上をリストします。その後、通常の再起動手順が発生し、侵入者は関連付けをハイジャックします。
---------
Old text: (Section 3.3.10)
---------
Cause Code
Value Cause Code
--------- ----------------
1 Invalid Stream Identifier
2 Missing Mandatory Parameter
3 Stale Cookie Error
4 Out of Resource
5 Unresolvable Address
6 Unrecognized Chunk Type
7 Invalid Mandatory Parameter
8 Unrecognized Parameters
9 No User Data
10 Cookie Received While Shutting Down
Cause Length: 16 bits (unsigned integer)
原因の長さ：16ビット（符号なし整数）
Set to the size of the parameter in bytes, including the Cause Code, Cause Length, and Cause-Specific Information fields
[原因コード]、[原因の長さ]、[原因固有の情報]フィールドを含む、パラメータのサイズをバイト単位で設定します
Cause-specific Information: variable length
原因固有の情報：可変長
This field carries the details of the error condition.
このフィールドには、エラー状態の詳細が含まれます。
Sections 3.3.10.1 - 3.3.10.10 define error causes for SCTP.
セクション3.3.10.1-3.3.10.10は、SCTPのエラー原因を定義します。
Guidelines for the IETF to define new error cause values are discussed in Section 13.3.
IETFが新しいエラー原因値を定義するためのガイドラインについては、セクション13.3で説明します。
---------
New text: (Section 3.3.10)
---------
Cause Code
Value Cause Code
--------- ----------------
1 Invalid Stream Identifier
2 Missing Mandatory Parameter
3 Stale Cookie Error
4 Out of Resource
5 Unresolvable Address
6 Unrecognized Chunk Type
7 Invalid Mandatory Parameter
8 Unrecognized Parameters
9 No User Data
10 Cookie Received While Shutting Down
11 Restart of an Association with New Addresses
Cause Length: 16 bits (unsigned integer)
原因の長さ：16ビット（符号なし整数）
Set to the size of the parameter in bytes, including the Cause Code, Cause Length, and Cause-Specific Information fields.
[原因コード]、[原因の長さ]、[原因固有の情報]フィールドを含む、パラメータのサイズをバイト単位で設定します。
Cause-specific Information: variable length
原因固有の情報：可変長
This field carries the details of the error condition.
このフィールドには、エラー状態の詳細が含まれます。
Sections 3.3.10.1 - 3.3.10.11 define error causes for SCTP. Guidelines for the IETF to define new error cause values are discussed in Section 13.3.
セクション3.3.10.1-3.3.10.11は、SCTPのエラー原因を定義します。 IETFが新しいエラー原因値を定義するためのガイドラインについては、セクション13.3で説明します。
---------
New text: (Note no old text, new error cause added in section 3.3.10)
---------
3.3.10.11. Restart of an Association with New Addresses (11)
3.3.10.11. 新しいアドレスとの関連付けの再開（11）
Cause of error
--------------
Restart of an association with new addresses: An INIT was received
on an existing association. But the INIT added addresses to the
association that were previously NOT part of the association. The
new addresses are listed in the error code. This ERROR is normally
sent as part of an ABORT refusing the INIT (see Section 5.2).
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=11 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ New Address TLVs /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: Each New Address TLV is an exact copy of the TLV that was found in the INIT chunk that was new, including the Parameter Type and the Parameter length.
注：それぞれの新しいアドレスTLVは、パラメータータイプとパラメーター長を含む、新しいINITチャンクで見つかったTLVの正確なコピーです。
---------
Old text: (Section 5.2.1)
---------
Upon receipt of an INIT in the COOKIE-WAIT or COOKIE-ECHOED state, an endpoint MUST respond with an INIT ACK using the same parameters it sent in its original INIT chunk (including its Initiation Tag, unchanged). These original parameters are combined with those from the newly received INIT chunk. The endpoint shall also generate a State Cookie with the INIT ACK. The endpoint uses the parameters sent in its INIT to calculate the State Cookie.
COOKIE-WAITまたはCOOKIE-ECHOED状態のINITを受信すると、エンドポイントは、元のINITチャンクで送信したのと同じパラメーター（変更されていない開始タグを含む）を使用して、INIT ACKで応答する必要があります。これらの元のパラメーターは、新しく受信したINITチャンクからのパラメーターと組み合わされます。エンドポイントは、INIT ACKを使用して状態Cookieも生成します。エンドポイントは、INITで送信されたパラメーターを使用して状態Cookieを計算します。
---------
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 Initiation 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 to.
COOKIE-WAIT状態でINITを受信すると、エンドポイントは、元のINITチャンクで送信したのと同じパラメーター（変更されていない開始タグを含む）を使用して、INIT ACKで応答する必要があります。応答時に、エンドポイントは、元のINIT（このエンドポイントによって送信された）が送信されたのと同じアドレスにINIT ACKを送信する必要があります。
Upon receipt of an INIT in the COOKIE-ECHOED state, an endpoint MUST respond with an INIT ACK using the same parameters it sent in its original INIT chunk (including its Initiation Tag, unchanged), provided that no NEW address has been added to the forming association. If the INIT message indicates that a new address has been added to the association, then the entire INIT MUST be discarded, and NO changes should be made to the existing association. An ABORT SHOULD be sent in response that MAY include the error 'Restart of an association with new addresses'. The error SHOULD list the addresses that were added to the restarting association.
COOKIE-ECHOED状態のINITを受信すると、新しいアドレスがに追加されていない限り、エンドポイントは元のINITチャンクで送信したのと同じパラメーター（変更されていない開始タグを含む）を使用してINIT ACKで応答する必要があります。協会を結成。新しいアドレスが関連付けに追加されたことをINITメッセージが示している場合は、INIT全体を破棄する必要があり、既存の関連付けは変更しないでください。 ABORT SHOULDは、「新しいアドレスとのアソシエーションの再開」というエラーを含む可能性があるという応答として送信する必要があります。エラーは、再起動アソシエーションに追加されたアドレスをリストする必要があります（SHOULD）。
When responding in either state (COOKIE-WAIT or COOKIE-ECHOED) with an INIT ACK, the original parameters are combined with those from the newly received INIT chunk. The endpoint shall also generate a State Cookie with the INIT ACK. The endpoint uses the parameters sent in its INIT to calculate the State Cookie.
どちらかの状態（COOKIE-WAITまたはCOOKIE-ECHOED）でINIT ACKを使用して応答すると、元のパラメーターは、新しく受信したINITチャンクからのパラメーターと結合されます。エンドポイントは、INIT ACKを使用して状態Cookieも生成します。エンドポイントは、INITで送信されたパラメーターを使用して状態Cookieを計算します。
---------
Old text: (Section 5.2.2)
---------
5.2.2 Unexpected INIT in States Other than CLOSED, COOKIE-ECHOED, COOKIE-WAIT and SHUTDOWN-ACK-SENT
5.2.2 CLOSED、COOKIE-ECHOED、COOKIE-WAIT、およびSHUTDOWN-ACK-SENT以外の状態での予期しないINIT
Unless otherwise stated, upon reception of an unexpected INIT for this association, the endpoint shall generate an INIT ACK with a State Cookie. In the outbound INIT ACK the endpoint MUST copy its current Verification Tag and peer's Verification Tag into a reserved place within the state cookie. We shall refer to these locations as the Peer's-Tie-Tag and the Local-Tie-Tag. The outbound SCTP packet containing this INIT ACK MUST carry a Verification Tag value equal to the Initiation Tag found in the unexpected INIT. And the INIT ACK MUST contain a new Initiation Tag (randomly generated see Section 5.3.1). Other parameters for the endpoint SHOULD be copied from the existing parameters of the association (e.g., number of outbound streams) into the INIT ACK and cookie.
特に明記されていない限り、この関連付けの予期しないINITを受信すると、エンドポイントは状態Cookieを使用してINIT ACKを生成します。アウトバウンドINIT ACKで、エンドポイントは現在の検証タグとピアの検証タグを状態Cookie内の予約された場所にコピーする必要があります。これらの場所をピアのタイタグとローカルのタイタグと呼びます。このINIT ACKを含むアウトバウンドSCTPパケットは、予期しないINITで見つかった開始タグに等しい検証タグ値を運ぶ必要があります。また、INIT ACKには新しい開始タグが含まれている必要があります（ランダムに生成されたセクション5.3.1を参照）。エンドポイントのその他のパラメーターは、関連付けの既存のパラメーター（アウトバウンドストリームの数など）からINIT ACKおよびCookieにコピーする必要があります（SHOULD）。
After sending out the INIT ACK, the endpoint shall take no further actions, i.e., the existing association, including its current state, and the corresponding TCB MUST NOT be changed.
INIT ACKを送信した後、エンドポイントはそれ以上のアクションを実行してはなりません。つまり、現在の状態を含む既存の関連付けであり、対応するTCBを変更してはなりません（MUST NOT）。
Note: Only when a TCB exists and the association is not in a COOKIE-WAIT state are the Tie-Tags populated. For a normal association INIT (i.e., the endpoint is in a COOKIE-WAIT state), the Tie-Tags MUST be set to 0 (indicating that no previous TCB existed). The INIT ACK and State Cookie are populated as specified in section 5.2.1.
注：TCBが存在し、関連付けがCOOKIE-WAIT状態でない場合にのみ、タイタグが入力されます。通常の関連付けINIT（つまり、エンドポイントがCOOKIE-WAIT状態にある）の場合、タイタグは0に設定する必要があります（以前のTCBが存在しなかったことを示します）。 INIT ACKとState Cookieは、セクション5.2.1で指定されているように入力されます。
---------
New text: (Section 5.2.2)
---------
5.2.2. Unexpected INIT in States Other Than CLOSED, COOKIE-ECHOED, COOKIE-WAIT, and SHUTDOWN-ACK-SENT
5.2.2. CLOSED、COOKIE-ECHOED、COOKIE-WAIT、およびSHUTDOWN-ACK-SENT以外の状態での予期しないINIT
Unless otherwise stated, upon receipt of an unexpected INIT for this association, the endpoint shall generate an INIT ACK with a State Cookie. Before responding, the endpoint MUST check to see if the unexpected INIT adds new addresses to the association. If new addresses are added to the association, the endpoint MUST respond with an ABORT, copying the 'Initiation Tag' of the unexpected INIT into the 'Verification Tag' of the outbound packet carrying the ABORT. In the ABORT response, the cause of error MAY be set to 'restart of an association with new addresses'. The error SHOULD list the addresses that were added to the restarting association.
特に明記されていない限り、この関連付けの予期しないINITを受信すると、エンドポイントは状態Cookieを使用してINIT ACKを生成します。応答する前に、エンドポイントは、予期しないINITが新しいアドレスを関連付けに追加するかどうかを確認する必要があります。アソシエーションに新しいアドレスが追加された場合、エンドポイントはABORTで応答する必要があり、予期しないINITの「開始タグ」を、ABORTを運ぶ送信パケットの「検証タグ」にコピーします。 ABORT応答では、エラーの原因は「新しいアドレスとの関連付けの再開」に設定される場合があります。エラーは、再起動アソシエーションに追加されたアドレスをリストする必要があります（SHOULD）。
If no new addresses are added, when responding to the INIT in the outbound INIT ACK, the endpoint MUST copy its current Verification Tag and peer's Verification Tag into a reserved place within the state cookie. We shall refer to these locations as the Peer's-Tie-Tag and the Local-Tie-Tag. The outbound SCTP packet containing this INIT ACK MUST carry a Verification Tag value equal to the Initiation Tag found in the unexpected INIT. And the INIT ACK MUST contain a new Initiation Tag (randomly generated; see Section 5.3.1). Other parameters for the endpoint SHOULD be copied from the existing parameters of the association (e.g., number of outbound streams) into the INIT ACK and cookie.
新しいアドレスが追加されない場合、アウトバウンドINIT ACKのINITに応答するとき、エンドポイントは現在の検証タグとピアの検証タグを状態Cookie内の予約された場所にコピーする必要があります。これらの場所をピアのタイタグとローカルのタイタグと呼びます。このINIT ACKを含むアウトバウンドSCTPパケットは、予期しないINITで見つかった開始タグに等しい検証タグ値を運ぶ必要があります。また、INIT ACKには新しい開始タグ（ランダムに生成されます。セクション5.3.1を参照）を含める必要があります。エンドポイントのその他のパラメーターは、関連付けの既存のパラメーター（アウトバウンドストリームの数など）からINIT ACKおよびCookieにコピーする必要があります（SHOULD）。
After sending out the INIT ACK or ABORT, the endpoint shall take no further actions; i.e., the existing association, including its current state, and the corresponding TCB MUST NOT be changed.
INIT ACKまたはABORTを送信した後、エンドポイントはそれ以上のアクションを実行してはなりません。つまり、現在の状態を含む既存の関連付け、および対応するTCBを変更してはなりません（MUST NOT）。
Note: Only when a TCB exists and the association is not in a COOKIE-WAIT or SHUTDOWN-ACK-SENT state are the Tie-Tags populated with a value other than 0. For a normal association INIT (i.e., the endpoint is in the CLOSED state), the Tie-Tags MUST be set to 0 (indicating that no previous TCB existed).
注：TCBが存在し、関連付けがCOOKIE-WAITまたはSHUTDOWN-ACK-SENT状態でない場合にのみ、タイタグに0以外の値が入力されます。通常の関連付けINITの場合（つまり、エンドポイントはCLOSED状態）、Tie-Tagは0に設定する必要があります（以前のTCBが存在しなかったことを示します）。
A new error code is being added, along with specific instructions to send back an ABORT to a new association in a restart case or collision case, where new addresses have been added. The error code can be used by a legitimate restart to inform the endpoint that it has made a software error in adding a new address. The endpoint then can choose to wait until the OOTB ABORT tears down the old association, or to restart without the new address.
新しいエラーコードが追加され、再起動の場合や衝突の場合に、新しい関連付けがABORTを新しいアソシエーションに送り返すための特定の手順が追加され、新しいアドレスが追加されています。正当な再起動でエラーコードを使用して、新しいアドレスの追加でソフトウェアエラーが発生したことをエンドポイントに通知できます。エンドポイントは、OOTB ABORTが古い関連付けを解除するまで待機するか、新しいアドレスなしで再起動するかを選択できます。
Also, the note at the end of Section 5.2.2 explaining the use of the Tie-Tags was modified to properly explain the states in which the Tie-Tags should be set to a value different than 0.
また、セクション5.2.2の最後にあるタイタグの使用に関する説明は、タイタグを0以外の値に設定する必要がある状態を適切に説明するように変更されました。
Some implementations were having difficulty growing their cwnd. This was due to an improper enforcement of the congestion control rules. The rules, as written, provided for a slop over of the cwnd value. Without this slop over, the sender would appear NOT to be using its full cwnd value and thus would never increase it.
一部の実装では、cwndを拡張することが困難でした。これは、輻輳制御ルールの不適切な施行が原因でした。記述されているように、ルールはcwnd値の傾斜を規定しています。この傾斜がないと、送信者は完全なcwnd値を使用していないように見えるため、増加することはありません。
---------
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 or more bytes of data outstanding to that transport address. The sender may exceed cwnd by up to (PMTU-1) bytes on a new transmission if the cwnd is not currently exceeded.
B）常に、送信者がそのトランスポートアドレスに対して未処理のデータのcwnd以上のバイトを持っている場合、そのトランスポートアドレスに新しいデータを送信してはなりません。送信者は、cwndが現在超過していない場合、新しい送信で最大（PMTU-1）バイトまでcwndを超過する可能性があります。
The text changes make clear the ability to go over the cwnd value by no more than (PMTU-1) bytes.
テキストの変更により、cwnd値を（PMTU-1）バイト以下で移動する機能が明確になります。
Several problems were found in the current specification of fast retransmit. The current wording did not require GAP ACK blocks to be sent, even though they are essential to the workings of SCTP's congestion control. The specification left unclear how to handle the fast retransmit cycle, having the implementation wait on the cwnd to retransmit a TSN that was marked for fast retransmit. No limit was placed on how many times a TSN could be fast retransmitted. Fast Recovery was not specified, causing the congestion window to be reduced drastically when there are multiple losses in a single RTT.
高速再送信の現在の仕様には、いくつかの問題が見つかりました。現在の言い回しでは、GATP ACKブロックを送信する必要はありませんでしたが、SCTPの輻輳制御の動作には欠かせません。仕様では、高速再送信サイクルの処理方法が不明確になり、実装はcwndで高速再送信用にマークされたTSNを再送信するまで待機しました。 TSNを高速で再送信できる回数に制限はありませんでした。高速リカバリは指定されていなかったため、1つのRTTで複数の損失が発生すると、輻輳ウィンドウが大幅に減少しました。
---------
Old text: (Section 6.2)
---------
Acknowledgements MUST be sent in SACK chunks unless shutdown was requested by the ULP in which case an endpoint MAY send an acknowledgement in the SHUTDOWN chunk. A SACK chunk can acknowledge the reception of multiple DATA chunks. See Section 3.3.4 for SACK chunk format. In particular, the SCTP endpoint MUST fill in the Cumulative TSN Ack field to indicate the latest sequential TSN (of a valid DATA chunk) it has received. Any received DATA chunks with TSN greater than the value in the Cumulative TSN Ack field SHOULD also be reported in the Gap Ack Block fields.
シャットダウンがULPによって要求された場合を除き、確認応答はSACKチャンクで送信する必要があります。この場合、エンドポイントはSHUTDOWNチャンクで確認応答を送信できます（MAY）。 SACKチャンクは、複数のDATAチャンクの受信を確認できます。 SACKチャンク形式については、セクション3.3.4を参照してください。特に、SCTPエンドポイントは、それが受信した（有効なDATAチャンクの）最新の順次TSNを示すために、累積TSN Ackフィールドに入力する必要があります。 TSNが累積TSN Ackフィールドの値より大きい受信DATAチャンクも、ギャップAckブロックフィールドで報告する必要があります（SHOULD）。
---------
New text: (Section 6.2)
---------
Acknowledegments MUST be sent in SACK chunks unless shutdown was requested by the ULP, in which case an endpoint MAY send an acknowledgement in the SHUTDOWN chunk. A SACK chunk can acknowledge the reception of multiple DATA chunks. See Section 3.3.4 for SACK chunk format. In particular, the SCTP endpoint MUST fill in the Cumulative TSN Ack field to indicate the latest sequential TSN (of a valid DATA chunk) it has received. Any received DATA chunks with TSN greater than the value in the Cumulative TSN Ack field are reported in the Gap Ack Block fields. The SCTP endpoint MUST report as many Gap Ack Blocks as can fit in a single SACK chunk limited by the current path MTU.
シャットダウンがULPによって要求されない限り、確認応答はSACKチャンクで送信する必要があります。この場合、エンドポイントはSHUTDOWNチャンクで確認応答を送信できます（MAY）。 SACKチャンクは、複数のDATAチャンクの受信を確認できます。 SACKチャンク形式については、セクション3.3.4を参照してください。特に、SCTPエンドポイントは、それが受信した（有効なDATAチャンクの）最新の順次TSNを示すために、累積TSN Ackフィールドに入力する必要があります。 TSNが累積TSN Ackフィールドの値より大きい受信DATAチャンクは、ギャップAckブロックフィールドで報告されます。 SCTPエンドポイントは、現在のパスMTUによって制限される単一のSACKチャンクに収まるだけの数のギャップACKブロックを報告する必要があります。
---------
Old text: (Section 6.2.1)
---------
D) Any time a SACK arrives, the endpoint performs the following:
D）SACKが到着するたびに、エンドポイントは以下を実行します。
i) If Cumulative TSN Ack is less than the Cumulative TSN Ack Point, then drop the SACK. Since Cumulative TSN Ack is monotonically increasing, a SACK whose Cumulative TSN Ack is less than the Cumulative TSN Ack Point indicates an out-of-order SACK.
i) 累積TSN Ackが累積TSN Ackポイントよりも小さい場合、SACKをドロップします。累積TSN Ackは単調に増加しているため、累積TSN Ackが累積TSN Ackポイントよりも小さいSACKは、順序が正しくないSACKを示します。
ii) Set rwnd equal to the newly received a_rwnd minus the number of bytes still outstanding after processing the Cumulative TSN Ack and the Gap Ack Blocks.
ii）rwndを、新しく受信したa_rwndから、累積TSN AckおよびGap Ackブロックを処理した後も未処理のバイト数を引いた値に設定します。
iii) If the SACK is missing a TSN that was previously acknowledged via a Gap Ack Block (e.g., the data receiver reneged on the data), then mark the corresponding DATA chunk as available for retransmit: Mark it as missing for fast retransmit as described in Section 7.2.4 and if no retransmit timer is running for the destination address to which the DATA chunk was originally transmitted, then T3-rtx is started for that destination address.
iii）ギャップACKブロックを介して以前に確認応答されたTSNがSACKにない場合（たとえば、データレシーバーがデータを破棄した場合）、対応するDATAチャンクを再送信可能としてマークします。セクション7.2.4で、DATAチャンクが最初に送信された宛先アドレスに対して再送信タイマーが実行されていない場合、その宛先アドレスに対してT3-rtxが開始されます。
---------
New text: (Section 6.2.1)
---------
D) Any time a SACK arrives, the endpoint performs the following:
D）SACKが到着するたびに、エンドポイントは以下を実行します。
i) If Cumulative TSN Ack is less than the Cumulative TSN Ack Point, then drop the SACK. Since Cumulative TSN Ack is monotonically increasing, a SACK whose Cumulative TSN Ack is less than the Cumulative TSN Ack Point indicates an out-of-order SACK.
i) 累積TSN Ackが累積TSN Ackポイントよりも小さい場合、SACKをドロップします。累積TSN Ackは単調に増加しているため、累積TSN Ackが累積TSN Ackポイントよりも小さいSACKは、順序が正しくないSACKを示します。
ii) Set rwnd equal to the newly received a_rwnd minus the number of bytes still outstanding after processing the Cumulative TSN Ack and the Gap Ack Blocks.
ii）rwndを、新しく受信したa_rwndから、累積TSN AckおよびGap Ackブロックを処理した後も未処理のバイト数を引いた値に設定します。
iii) If the SACK is missing a TSN that was previously acknowledged via a Gap Ack Block (e.g., the data receiver reneged on the data), then consider the corresponding DATA that might be possibly missing: Count one miss indication towards fast retransmit as described in Section 7.2.4, and if no retransmit timer is running for the destination address to which the DATA chunk was originally transmitted, then T3-rtx is started for that destination address.
iii）SACKに、ギャップACKブロックを介して以前に確認応答されたTSNが欠落している場合（たとえば、データレシーバーがデータを破棄した場合）、欠落している可能性のある対応するDATAを検討します。セクション7.2.4で、DATAチャンクが最初に送信された宛先アドレスに対して再送信タイマーが実行されていない場合、その宛先アドレスに対してT3-rtxが開始されます。
iv) If the Cumulative TSN Ack matches or exceeds the Fast Recovery exitpoint (Section 7.2.4), Fast Recovery is exited.
iv）累積TSN Ackが高速復旧出口点（7.2.4項）と一致するか超える場合、高速復旧は終了します。
---------
Old text: (Section 7.2.4)
---------
Whenever an endpoint receives a SACK that indicates some TSN(s) missing, it SHOULD wait for 3 further miss indications (via subsequent SACK's) on the same TSN(s) before taking action with regard to Fast Retransmit.
エンドポイントは、一部のTSNが欠落していることを示すSACKを受信するたびに、高速再送信に関してアクションを実行する前に、同じTSNで（後続のSACKを介して）さらに3つのミス表示を待つ必要があります。
When the TSN(s) is reported as missing in the fourth consecutive SACK, the data sender shall: 1) Mark the missing DATA chunk(s) for retransmission,
TSNが4番目の連続したSACKで欠落していると報告された場合、データ送信者は次のことを行う必要があります。1）欠落しているDATAチャンクに再送信のマークを付ける。
2) Adjust the ssthresh and cwnd of the destination address(es) to which the missing DATA chunks were last sent, according to the formula described in Section 7.2.3.
2）セクション7.2.3で説明されている式に従って、欠落しているDATAチャンクが最後に送信された宛先アドレスのssthreshおよびcwndを調整します。
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.
3）パケットの送信先である宛先トランスポートアドレスのパスMTUの制約に従って、再送信のマークが付けられた最も早い（つまり、最も低いTSN）DATAチャンクが1つのパケットに収まる数を決定します。この値をKと呼びます。これらのK個のDATAチャンクを1つのパケットで再送信します。
4) Restart T3-rtx timer only if the last SACK acknowledged the lowest outstanding TSN number sent to that address, or the endpoint is retransmitting the first outstanding DATA chunk sent to that address.
4）最後のSACKがそのアドレスに送信された未解決の最小TSN番号を確認した場合、またはエンドポイントがそのアドレスに送信された最初の未解決のDATAチャンクを再送信している場合にのみ、T3-rtxタイマーを再起動します。
Note: Before the above adjustments, if the received SACK also acknowledges new DATA chunks and advances the Cumulative TSN Ack Point, the cwnd adjustment rules defined in Sections 7.2.1 and 7.2.2 must be applied first.
注：上記の調整の前に、受信したSACKが新しいDATAチャンクも確認し、累積TSN Ackポイントを進める場合、セクション7.2.1および7.2.2で定義されたcwnd調整ルールを最初に適用する必要があります。
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 4 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ごとにカウンターが増加します。 4に達して高速再送信手順を開始すると、カウンターは0にリセットされます。SCTPのcwndは未解決のTSNの数を間接的に制限するため、輻輳制御ウィンドウサイズを調整せずに、TCP高速回復の効果が自動的に達成されます。
---------
New text: (Section 7.2.4)
---------
Whenever an endpoint receives a SACK that indicates that some TSNs are missing, it SHOULD wait for 3 further miss indications (via subsequent SACKs) on the same TSN(s) before taking action with regard to Fast Retransmit.
エンドポイントは、一部のTSNが欠落していることを示すSACKを受信すると、高速再送信に関してアクションを実行する前に、同じTSNで（後続のSACKを介して）さらに3つのミス表示を待つ必要があります。
Miss indications SHOULD follow the HTNA (Highest TSN Newly Acknowledged) algorithm. For each incoming SACK, miss indications are incremented only for missing TSNs prior to the highest TSN newly acknowledged in the SACK. A newly acknowledged DATA chunk is one not previously acknowledged in a SACK. If an endpoint is in Fast Recovery and a SACK arrives that advances the Cumulative TSN Ack Point, the miss indications are incremented for all TSNs reported missing in the SACK.
ミス表示は、HTNA（Highest TSN Newly Acknowledged）アルゴリズムに従う必要があります（SHOULD）。着信SACKごとに、SACKで新たに確認応答された最高のTSNの前に、欠落したTSNについてのみ、ミス表示が増分されます。新しく確認されたDATAチャンクは、以前にSACKで確認されていないものです。エンドポイントが高速復旧状態にあり、累積TSN Ackポイントを進めるSACKが到着した場合、SACKで欠落していると報告されたすべてのTSNのミス表示が増加します。
When the fourth consecutive miss indication is received for a TSN(s), the data sender shall do the following:
TSNに対して4回目の連続したミス表示が受信された場合、データ送信者は次のことを行うものとします。
1) Mark the DATA chunk(s) with four miss indications for retransmission.
1）再送信のために4つのミス表示でDATAチャンクをマークします。
2) If not in Fast Recovery, adjust the ssthresh and cwnd of the destination address(es) to which the missing DATA chunks were last sent, according to the formula described in Section 7.2.3.
2）高速リカバリでない場合は、セクション7.2.3で説明されている式に従って、欠落しているDATAチャンクが最後に送信された宛先アドレスのssthreshおよびcwndを調整します。
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 NOT）、この単一パケットの再送信を遅延してはなりません（SHOULD NOT）。
4) Restart T3-rtx timer only if the last SACK acknowledged the lowest outstanding TSN number sent to that address, or the endpoint is retransmitting the first outstanding DATA chunk sent to that address.
4）最後のSACKがそのアドレスに送信された未解決の最小TSN番号を確認した場合、またはエンドポイントがそのアドレスに送信された最初の未解決のDATAチャンクを再送信している場合にのみ、T3-rtxタイマーを再起動します。
5) Mark the DATA chunk(s) as being fast retransmitted and thus ineligible for a subsequent fast retransmit. Those TSNs marked for retransmission due to the Fast Retransmit algorithm that did not fit in the sent datagram carrying K other TSNs are also marked as ineligible for a subsequent fast retransmit. However, as they are marked for retransmission they will be retransmitted later on as soon as cwnd allows.
5）DATAチャンクを高速再送信としてマークし、後続の高速再送信の対象外とします。高速再送信アルゴリズムのために再送信のマークが付けられたTSNは、K個の他のTSNを伝送する送信データグラムに適合しなかったため、後続の高速再送信の対象外としてマークされます。ただし、再送信のマークが付けられているため、cwndが許可するとすぐに再送信されます。
6) If not in Fast Recovery, enter Fast Recovery and mark the highest outstanding TSN as the Fast Recovery exit point. When a SACK acknowledges all TSNs up to and including this exit point, Fast Recovery is exited. While in Fast Recovery, the ssthresh and cwnd SHOULD NOT change for any destinations due to a subsequent Fast Recovery event (i.e., one SHOULD NOT reduce the cwnd further due to a subsequent fast retransmit).
6）高速リカバリーでない場合は、高速リカバリーを入力し、最高の未解決TSNを高速リカバリー出口点としてマークします。 SACKがこの出口ポイントまでのすべてのTSNを確認すると、高速リカバリが終了します。高速復旧中は、ssthreshとcwndは、後続の高速復旧イベントのために、どの宛先に対しても変更すべきではありません（つまり、後続の高速再送信により、cwndをさらに削減すべきではありません）。
Note: Before the above adjustments, if the received SACK also acknowledges new DATA chunks and advances the Cumulative TSN Ack Point, the cwnd adjustment rules defined in Sections 7.2.1 and 7.2.2 must be applied first.
注：上記の調整の前に、受信したSACKが新しいDATAチャンクも確認し、累積TSN Ackポイントを進める場合、セクション7.2.1および7.2.2で定義されたcwnd調整ルールを最初に適用する必要があります。
The effect of the above wording changes are as follows: o It requires with a MUST the sending of GAP Ack blocks instead of the current RFC 2960 [5] SHOULD.
上記の表現の変更による影響は次のとおりです。o現在のRFC 2960の代わりにGAP Ackブロックを送信する必要があります[5]。
o It allows a TSN being Fast Retransmitted (FR) to be sent only once via FR.
o 高速再送信（FR）中のTSNがFR経由で1回だけ送信されることを可能にします。
o It ends the delay in waiting for the flight size to drop when a TSN is identified as being ready to FR.
o TSNがFRの準備ができていると識別されたときに、フライトサイズが低下するのを待つ遅延が終了します。
o It changes the way chunks are marked during fast retransmit, so that only new reports are counted.
o 高速再送信中にチャンクがマークされる方法が変更されるため、新しいレポートのみがカウントされます。
o It introduces a Fast Recovery period to avoid multiple congestion window reductions when there are multiple losses in a single RTT (as shown by Caro et al. [3]).
o 単一のRTTで複数の損失がある場合に、複数の輻輳ウィンドウの削減を回避するために高速回復期間が導入されます（Caro et al。[3]で示されているように）。
These changes will effectively allow SCTP to follow a similar model as TCP+SACK in the handling of Fast Retransmit.
これらの変更により、SCTPは、高速再送信の処理においてTCP + SACKと同様のモデルに従うことが事実上可能になります。
SCTP uses four control variables to regulate its transmission rate: rwnd, cwnd, ssthresh, and partial_bytes_acked. Upon detection of packet losses from SACK, or when the T3-rtx timer expires on an address, cwnd and ssthresh should be updated as stated in Section 7.2.3. However, that section should also clarify that partial_bytes_acked must be updated as well; it has to be reset to 0.
SCTPは、rwnd、cwnd、ssthresh、partial_bytes_ackedの4つの制御変数を使用して、その伝送速度を調整します。 SACKからのパケット損失を検出した場合、またはT3-rtxタイマーがアドレスで期限切れになった場合、cwndとssthreshは、セクション7.2.3で説明されているように更新されます。ただし、そのセクションでは、partial_bytes_ackedも更新する必要があることを明確にする必要があります。 0にリセットする必要があります。
---------
Old text: (Section 7.2.3)
---------
7.2.3 Congestion Control
7.2.3 輻輳制御
Upon detection of packet losses from SACK (see Section 7.2.4), An endpoint should do the following:
SACKからのパケット損失を検出すると（セクション7.2.4を参照）、エンドポイントは以下を実行する必要があります。
ssthresh = max(cwnd/2, 2*MTU)
cwnd = ssthresh
Basically, a packet loss causes cwnd to be cut in half.
基本的に、パケット損失によりcwndが半分にカットされます。
When the T3-rtx timer expires on an address, SCTP should perform slow start by:
T3-rtxタイマーがアドレスで期限切れになると、SCTPは次のようにスロースタートを実行する必要があります。
ssthresh = max(cwnd/2, 2*MTU)
cwnd = 1*MTU
---------
New text: (Section 7.2.3)
---------
7.2.3. Congestion Control
7.2.3. 輻輳制御
Upon detection of packet losses from SACK (see Section 7.2.4), an endpoint should do the following if not in Fast Recovery:
SACKからのパケット損失を検出すると（セクション7.2.4を参照）、エンドポイントはFast Recoveryでない場合、以下を実行する必要があります。
ssthresh = max(cwnd/2, 2*MTU)
cwnd = ssthresh
partial_bytes_acked = 0
Basically, a packet loss causes cwnd to be cut in half.
基本的に、パケット損失によりcwndが半分にカットされます。
When the T3-rtx timer expires on an address, SCTP should perform slow start by
T3-rtxタイマーがアドレスで期限切れになると、SCTPはスロースタートを実行する必要があります。
ssthresh = max(cwnd/2, 2*MTU)
cwnd = 1*MTU
partial_bytes_acked = 0
The missing text added solves the doubts about what to do with partial_bytes_acked in the situations stated in Section 7.2.3, making clear that, along with ssthresh and cwnd, partial_bytes_acked should also be updated by being reset to 0.
追加された欠落したテキストは、セクション7.2.3で述べた状況でpartial_bytes_ackedをどうするかに関する疑問を解決し、ssthreshとcwndとともに、partial_bytes_ackedも0にリセットして更新する必要があることを明確にします。
Five basic problems have been discovered with the current heartbeat procedures:
現在のハートビート手順で5つの基本的な問題が発見されました。
o The current specification does not specify that you should count a failed heartbeat as an error against the overall association.
o 現在の仕様では、失敗したハートビートを全体の関連付けに対するエラーとしてカウントする必要があるとは規定されていません。
o The current specification is not specific as to when you start sending heartbeats and when you should stop.
o 現在の仕様は、ハートビートの送信を開始するタイミングと停止するタイミングについては特定されていません。
o The current specification is not specific as to when you should respond to heartbeats.
o 現在の仕様は、ハートビートにいつ応答する必要があるかについては特定されていません。
o When responding to a Heartbeat, it is unclear what to do if more than a single TLV is present.
o ハートビートに応答するとき、複数のTLVが存在する場合の対処方法は不明です。
o The jitter applied to a heartbeat was meant to be a small variance of the RTO and is currently a wide variance, due to the default delay time and incorrect wording within the RFC.
o ハートビートに適用されるジッタは、RTOの変動が小さいことを意味しており、現在のところ、デフォルトの遅延時間とRFC内の不適切な表現のために、広い変動です。
---------
Old text: (Section 8.1)
---------
8.1 Endpoint Failure Detection
8.1 エンドポイント障害検出
An endpoint shall keep a counter on the total number of consecutive retransmissions to its peer (including retransmissions to all the destination transport addresses of the peer if it is multi-homed). If the value of this counter exceeds the limit indicated in the protocol parameter 'Association.Max.Retrans', the endpoint shall 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 shall 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.
エンドポイントは、ピアへの連続する再送信の総数（マルチホームの場合はピアのすべての宛先トランスポートアドレスへの再送信を含む）のカウンターを保持します。このカウンターの値がプロトコルパラメーター 'Association.Max.Retrans'で示された制限を超える場合、エンドポイントはピアエンドポイントに到達できないと見なし、それ以上のデータの送信を停止します（したがって、関連付けはCLOSED状態になります）。さらに、エンドポイントは障害を上位層に報告し、オプションでアウトバウンドキューに残っているすべての未処理のユーザーデータを報告します。ピアエンドポイントが到達不能になると、関連付けは自動的に閉じられます。
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)
---------
8.1. Endpoint Failure Detection
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. If the value of this counter exceeds the limit indicated in the protocol parameter 'Association.Max.Retrans', the endpoint shall 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 MAY 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.
エンドポイントは、ピアへの連続する再送信の総数（マルチホームの場合はピアのすべての宛先トランスポートアドレスへの再送信を含む）に、未確認のHEARTBEATチャンクを含めて、カウンターを保持します。このカウンターの値がプロトコルパラメーター 'Association.Max.Retrans'で示された制限を超える場合、エンドポイントはピアエンドポイントに到達できないと見なし、それ以上のデータの送信を停止します（したがって、関連付けはCLOSED状態になります）。さらに、エンドポイントは上位層に障害を報告し、オプションで、アウトバウンドキューに残っているすべての未処理のユーザーデータを報告する場合があります。ピアエンドポイントが到達不能になると、関連付けは自動的に閉じられます。
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が受信されるたびにリセットされます。
---------
Old text: (Section 8.3)
---------
8.3 Path Heartbeat
8.3 パスハートビート
By default, an SCTP endpoint shall 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).
デフォルトでは、SCTPエンドポイントは、HEARTBEATチャンクを定期的に宛先トランスポートアドレスに送信することで、ピアのアイドル宛先トランスポートアドレスの到達可能性を監視します。
---------
New text: (Section 8.3)
---------
8.3 Path Heartbeat
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レシーバー）。
---------
Old text: (Section 8.3)
---------
The receiver of the HEARTBEAT should immediately respond with a HEARTBEAT ACK that contains the Heartbeat Information field copied from the received HEARTBEAT chunk.
HEARTBEATの受信者は、受信したHEARTBEATチャンクからコピーされたハートビート情報フィールドを含むHEARTBEAT ACKですぐに応答する必要があります。
---------
New text: (Section 8.3)
---------
The receiver of the HEARTBEAT should immediately respond with a HEARTBEAT ACK that contains the Heartbeat Information TLV, together with any other received TLVs, copied unchanged from the received HEARTBEAT chunk.
HEARTBEATの受信者は、ハートビート情報TLVと、受信したHEARTBEATチャンクから変更されずにコピーされた他の受信TLVを含むHEARTBEAT ACKですぐに応答する必要があります。
---------
Old text: (Section 8.3)
---------
On an idle destination address that is allowed to heartbeat, a HEARTBEAT chunk is RECOMMENDED to be sent once per RTO of that destination address plus the protocol parameter 'HB.interval' , with jittering of +/- 50%, and exponential back-off of the RTO if the previous HEARTBEAT is unanswered.
ハートビートが許可されているアイドル宛先アドレスでは、HEARTBEATチャンクは、その宛先アドレスのRTOごとに1回、プロトコルパラメータ 'HB.interval'を1回送信することをお勧めします。ジッターは+/- 50％で、指数バックオフです。以前のHEARTBEATが応答されない場合のRTOの。
---------
New text: (Section 8.3)
---------
On an idle destination address that is allowed to heartbeat, it is recommended that a HEARTBEAT chunk is sent once per RTO of that destination address plus the protocol parameter 'HB.interval', with jittering of +/- 50% of the RTO value, and exponential back-off of the RTO if the previous HEARTBEAT is unanswered.
ハートビートが許可されているアイドル宛先アドレスでは、その宛先アドレスのRTOごとにHEARTBEATチャンクとプロトコルパラメーター 'HB.interval'を1回送信し、RTO値の+/- 50％のジッターを設定することをお勧めします。以前のハートビートが応答されなかった場合のRTOの指数バックオフ。
The above text provides guidance as to how to respond to the five issues mentioned in Section 2.10.1. In particular, the wording changes provide guidance as to when to start and stop heartbeating, how to respond to a heartbeat with extra parameters, and it clarifies the error counting procedures for the association.
上記のテキストは、セクション2.10.1で言及された5つの問題への対応方法に関するガイダンスを提供します。特に、表現の変更は、ハートビートを開始および停止するタイミング、追加のパラメーターでハートビートに応答する方法に関するガイダンスを提供し、関連付けのエラーカウント手順を明確にします。
When dealing with firewalls, it is advantageous for the firewall to be able to properly determine the initial startup sequence of a reliable transport protocol. With this in mind, the following text is to be added to SCTP's security section.
ファイアウォールを扱う場合、ファイアウォールが信頼できるトランスポートプロトコルの初期起動シーケンスを適切に決定できると便利です。これを念頭に置いて、次のテキストをSCTPのセキュリティセクションに追加します。
---------
New text: (no old text, new section added)
---------
11.4 SCTP Interactions with Firewalls
11.4 ファイアウォールとSCTPの相互作用
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 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.
一部のファイアウォールは、断片化されたSCTPパケットの最初のフラグメントのみを検査し、それがINITチャンクに対応するかどうかを明確に判断できる場合に役立ちます（詳細については、RFC1858を参照してください）。したがって、3.1で述べた要件を強調します。（1）INITチャンクはパケット内の他のチャンクとバンドルしてはならず（2）INITチャンクを含むパケットにはゼロ検証タグが必要です。さらに、INITチャンクの受信者は、他のチャンクにバンドルされているINITチャンクを持つ到着パケットをサイレントに破棄することにより、これらのルールを強制する必要があります。
---------
Old text: (Section 18)
---------
18. Bibliography
18. 参考文献
[ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End Network Path Properties", Proc. SIGCOMM'99, 1999.
[ALLMAN99] Allman、M。およびPaxson、V。、「End-to-End Network Path Propertiesの推定について」、Proc。 SIGCOMM'99、1999。
[FALL96] Fall, K. and Floyd, S., Simulation-based Comparisons of Tahoe, Reno, and SACK TCP, Computer Communications Review, V. 26 N. 3, July 1996, pp. 5-21.
[FALL96]秋、K。およびフロイド、S。、シミュレーションに基づくタホ、リノ、およびSACK TCPの比較、コンピュータ通信レビュー、V。26 N. 3、1996年7月、pp。5-21。
[RFC1750] Eastlake, D. (ed.), "Randomness Recommendations for Security", RFC 1750, December 1994.
[RFC1750] Eastlake、D.（ed。）、「Randomness Recommendations for Security」、RFC 1750、1994年12月。
[RFC1950] Deutsch P. and J. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996.
[RFC1950] Deutsch P.およびJ. Gailly、「ZLIB Compressed Data Format Specification version 3.3」、RFC 1950、1996年5月。
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, March 1997.
[RFC2104] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：Keyed-Hashing for Message Authentication」、RFC 2104、1997年3月。
[RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, September 1997.
[RFC2196] Fraser、B。、「Site Security Handbook」、FYI 8、RFC 2196、1997年9月。
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management Protocol", RFC 2522, March 1999.
[RFC2522] Karn、P。およびW. Simpson、「Photuris：Session-Key Management Protocol」、RFC 2522、1999年3月。
[SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T., "TCP Congestion Control with a Misbehaving Receiver", ACM Computer Communication Review, 29(5), October 1999.
[SAVAGE99] Savage、S.、Cardwell、N.、Wetherall、D。、およびAnderson、T。、「誤動作レシーバーによるTCP輻輳制御」、ACM Computer Communication Review、29（5）、1999年10月。
---------
New text: (Section 18)
---------
18. Bibliography
18. 参考文献
[ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End Network Path Properties", Proc. SIGCOMM'99, 1999.
[ALLMAN99] Allman、M。およびPaxson、V。、「End-to-End Network Path Propertiesの推定について」、Proc。 SIGCOMM'99、1999。
[FALL96] Fall, K. and Floyd, S., Simulation-based Comparisons of Tahoe, Reno, and SACK TCP, Computer Communications Review, V. 26 N. 3, July 1996, pp. 5-21.
[FALL96]秋、K。およびフロイド、S。、シミュレーションに基づくタホ、リノ、およびSACK TCPの比較、コンピュータ通信レビュー、V。26 N. 3、1996年7月、pp。5-21。
[RFC1750] Eastlake, D. (ed.), "Randomness Recommendations for Security", RFC 1750, December 1994.
[RFC1750] Eastlake、D.（ed。）、「Randomness Recommendations for Security」、RFC 1750、1994年12月。
[RFC1858] Ziemba, G., Reed, D. and Traina P., "Security Considerations for IP Fragment Filtering", RFC 1858, October 1995.
[RFC1858] Ziemba、G.、Reed、D。、およびTraina P。、「IPフラグメントフィルタリングのセキュリティに関する考慮事項」、RFC 1858、1995年10月。
[RFC1950] Deutsch P. and J. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996.
[RFC1950] Deutsch P.およびJ. Gailly、「ZLIB Compressed Data Format Specification version 3.3」、RFC 1950、1996年5月。
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, March 1997.
[RFC2104] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：Keyed-Hashing for Message Authentication」、RFC 2104、1997年3月。
[RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, September 1997.
[RFC2196] Fraser、B。、「Site Security Handbook」、FYI 8、RFC 2196、1997年9月。
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management Protocol", RFC 2522, March 1999.
[RFC2522] Karn、P。およびW. Simpson、「Photuris：Session-Key Management Protocol」、RFC 2522、1999年3月。
[SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T., "TCP Congestion Control with a Misbehaving Receiver", ACM Computer Communication Review, 29(5), October 1999.
[SAVAGE99] Savage、S.、Cardwell、N.、Wetherall、D。、およびAnderson、T。、「誤動作レシーバーによるTCP輻輳制御」、ACM Computer Communication Review、29（5）、1999年10月。
The above text, which adds a new subsection to the Security Considerations section of RFC 2960 [5] makes clear that, to make easier the interaction with firewalls, an INIT chunk must not be bundled in any case with any other chunk that will silently discard the packets that do not follow this rule (this rule is enforced by the packet receiver).
RFC 2960 [5]のセキュリティに関する考慮事項セクションに新しいサブセクションを追加する上記のテキストは、ファイアウォールとの相互作用を容易にするために、INITチャンクは、サイレントに破棄される他のチャンクと一緒にバンドルしてはならないことを明確にしていますこのルールに従わないパケット（このルールはパケットレシーバーによって適用されます）。
Currently, there is an ambiguity between the statements in Sections 6.2 and 9.2. Section 6.2 allows the sending of a SHUTDOWN chunk in place of a SACK when the sender is in the process of shutting down, while section 9.2 requires that both a SHUTDOWN chunk and a SACK chunk be sent.
現在、セクション6.2と9.2のステートメントにはあいまいさが存在します。セクション6.2では、送信者がシャットダウンの処理中にSACKの代わりにSHUTDOWNチャンクを送信できますが、セクション9.2では、SHUTDOWNチャンクとSACKチャンクの両方を送信する必要があります。
Along with this ambiguity there is a problem wherein an errant SHUTDOWN receiver may fail to stop accepting user data.
このあいまいさとともに、誤ったSHUTDOWNレシーバーがユーザーデータの受け入れを停止できないという問題があります。
---------
Old text: (Section 9.2)
---------
If there are still outstanding DATA chunks left, the SHUTDOWN receiver shall continue to follow normal data transmission procedures defined in Section 6 until all outstanding DATA chunks are acknowledged; however, the SHUTDOWN receiver MUST NOT accept new data from its SCTP user.
まだ未処理のDATAチャンクが残っている場合、SHUTDOWNレシーバーは、すべての未処理のDATAチャンクが確認されるまで、セクション6で定義された通常のデータ送信手順に従います。ただし、SHUTDOWNレシーバーは、SCTPユーザーからの新しいデータを受け入れてはなりません。
While in SHUTDOWN-SENT state, the SHUTDOWN sender MUST immediately respond to each received packet containing one or more DATA chunk(s) with a SACK, a SHUTDOWN chunk, and restart the T2-shutdown timer. If it has no more outstanding DATA chunks, the SHUTDOWN receiver shall send a SHUTDOWN ACK and start a T2-shutdown timer of its own, entering the SHUTDOWN-ACK-SENT state. If the timer expires, the endpoint must re-send the SHUTDOWN ACK.
SHUTDOWN-SENT状態の間、SHUTDOWN送信側は、1つ以上のDATAチャンクを含む受信した各パケットにSACK、SHUTDOWNチャンクで即座に応答し、T2シャットダウンタイマーを再起動する必要があります。未処理のDATAチャンクがなくなった場合、SHUTDOWNレシーバーはSHUTDOWN ACKを送信し、独自のT2シャットダウンタイマーを開始して、SHUTDOWN-ACK-SENT状態に入ります。タイマーが切れた場合、エンドポイントはSHUTDOWN ACKを再送信する必要があります。
---------
New text: (Section 9.2)
---------
If there are still outstanding DATA chunks left, the SHUTDOWN receiver MUST continue to follow normal data transmission procedures defined in Section 6, until all outstanding DATA chunks are acknowledged; however, the SHUTDOWN receiver MUST NOT accept new data from its SCTP user.
未処理のDATAチャンクがまだ残っている場合、SHUTDOWNレシーバーは、すべての未処理のDATAチャンクが確認されるまで、セクション6で定義された通常のデータ送信手順に従う必要があります。ただし、SHUTDOWNレシーバーは、SCTPユーザーからの新しいデータを受け入れてはなりません。
While in SHUTDOWN-SENT state, the SHUTDOWN sender MUST immediately respond to each received packet containing one or more DATA chunks with a SHUTDOWN chunk and restart the T2-shutdown timer. If a SHUTDOWN chunk by itself cannot acknowledge all of the received DATA chunks (i.e., there are TSNs that can be acknowledged that are larger than the cumulative TSN, and thus gaps exist in the TSN sequence), or if duplicate TSNs have been received, then a SACK chunk MUST also be sent.
SHUTDOWN-SENT状態の間、SHUTDOWN送信側は、1つ以上のDATAチャンクを含む各受信パケットにSHUTDOWNチャンクで即座に応答し、T2シャットダウンタイマーを再起動する必要があります。 SHUTDOWNチャンク自体が受信したDATAチャンクのすべてを確認できない場合（つまり、確認できるTSNが累積TSNより大きく、したがってTSNシーケンスにギャップがある場合）、または重複したTSNが受信された場合、次に、SACKチャンクも送信する必要があります。
The sender of the SHUTDOWN MAY also start an overall guard timer 'T5-shutdown-guard' to bound the overall time for shutdown sequence. At the expiration of this timer, the sender SHOULD abort the association by sending an ABORT chunk. If the 'T5-shutdown-guard' timer is used, it SHOULD be set to the recommended value of 5 times 'RTO.Max'.
SHUTDOWNの送信側は、全体的なガードタイマー「T5-shutdown-guard」を開始して、シャットダウンシーケンスの全体的な時間を制限する場合があります。このタイマーの満了時に、送信者はABORTチャンクを送信することで関連付けを中止する必要があります（SHOULD）。 「T5-shutdown-guard」タイマーを使用する場合、「RTO.Max」の5倍の推奨値に設定する必要があります。
If the receiver of the SHUTDOWN has no more outstanding DATA chunks, the SHUTDOWN receiver MUST send a SHUTDOWN ACK and start a T2-shutdown timer of its own, entering the SHUTDOWN-ACK-SENT state. If the timer expires, the endpoint must re-send the SHUTDOWN ACK.
SHUTDOWNのレシーバーに未処理のDATAチャンクがなくなった場合、SHUTDOWNレシーバーはSHUTDOWN ACKを送信し、独自のT2シャットダウンタイマーを開始して、SHUTDOWN-ACK-SENT状態に入る必要があります。タイマーが切れた場合、エンドポイントはSHUTDOWN ACKを再送信する必要があります。
The above text clarifies the use of a SACK in conjunction with a SHUTDOWN chunk. It also adds a guard timer to the SCTP shutdown sequence to protect against errant receivers of SHUTDOWN chunks.
上記のテキストは、SHACKDOWNチャンクと組み合わせたSACKの使用を明確にしています。また、SCTPシャットダウンシーケンスにガードタイマーを追加して、SHUTDOWNチャンクの誤ったレシーバーから保護します。
It was noted that the wording in Section 8.5.1 did not give proper directions in the use of the 'T bit' with the Verification Tags.
セクション8.5.1の表現は、検証タグでの「Tビット」の使用に関して適切な指示を与えていないことに注意してください。
---------
Old text: (Section 8.5.1)
---------
B) Rules for packet carrying ABORT:
B）ABORTを運ぶパケットのルール：
- The endpoint shall always fill in the Verification Tag field of the outbound packet with the destination endpoint's tag value if it is known.
- エンドポイントは、既知の場合、常に送信パケットの検証タグフィールドに宛先エンドポイントのタグ値を入力します。
- If the ABORT is sent in response to an OOTB packet, the endpoint MUST follow the procedure described in Section 8.4.
- ABORTがOOTBパケットに応答して送信される場合、エンドポイントはセクション8.4で説明されている手順に従う必要があります。
- The receiver MUST accept the packet if the Verification Tag matches either its own tag, OR the tag of its peer. Otherwise, the receiver MUST silently discard the packet and take no further action.
- 検証タグが自身のタグまたはピアのタグのいずれかに一致する場合、受信者はパケットを受け入れる必要があります。それ以外の場合、受信者は黙ってパケットを破棄し、それ以上のアクションを実行してはなりません（MUST）。
---------
New text: (Section 8.5.1)
---------
B) Rules for packet carrying ABORT:
B）ABORTを運ぶパケットのルール：
- The endpoint MUST always fill in the Verification Tag field of the outbound packet with the destination endpoint's tag value, if it is known.
- エンドポイントは、既知の場合、常に送信パケットの検証タグフィールドに宛先エンドポイントのタグ値を入力する必要があります。
- If the ABORT is sent in response to an OOTB packet, the endpoint MUST follow the procedure described in Section 8.4.
- ABORTがOOTBパケットに応答して送信される場合、エンドポイントはセクション8.4で説明されている手順に従う必要があります。
- The receiver of a ABORT MUST accept the packet if the Verification Tag field of the packet matches its own tag OR if it is set to its peer's tag and the T bit is set in the Chunk Flags. Otherwise, the receiver MUST silently discard the packet and take no further action.
- パケットの検証タグフィールドが自身のタグと一致する場合、またはピアのタグに設定され、Tビットがチャンクフラグに設定されている場合、ABORTの受信者はパケットを受け入れる必要があります。それ以外の場合、受信者は黙ってパケットを破棄し、それ以上のアクションを実行してはなりません（MUST）。
The above text change clarifies that the T bit must be set before an implementation looks for the peer's tag.
上記のテキスト変更は、実装がピアのタグを探す前にTビットを設定する必要があることを明確にしています。
A problem was found with the current specification of the growth and decay of cwnd. The cwnd should only be increased if it is being fully utilized, and after periods of underutilization, the cwnd should be decreased. In some sections, the current wording is weak and is not clearly defined. Also, the current specification unnecessarily introduces the need for special case code to ensure cwnd degradation. Plus, the cwnd should not be increased during Fast Recovery, since a full cwnd during Fast Recovery does not qualify the cwnd as being fully utilized. Additionally, multiple loss scenarios in a single window may cause the cwnd to grow more rapidly as the number of losses in a window increases [3].
cwndの増加と減衰の現在の仕様に問題が見つかりました。 cwndは、完全に使用されている場合にのみ増やす必要があり、十分に使用されていない期間が経過した後は、cwndを減らす必要があります。一部のセクションでは、現在の表現が弱く、明確に定義されていません。また、現在の仕様では、cwndの低下を確実にするために、特別な場合のコードの必要性を不必要に導入しています。さらに、高速リカバリ中にcwndを増やすことはできません。高速リカバリ中に完全なcwndを使用しても、cwndが完全に使用されているとは見なされないためです。さらに、単一のウィンドウで複数の損失シナリオが発生すると、ウィンドウでの損失の数が増えるにつれて、cwndがより急速に増加する可能性があります[3]。
---------
Old text: (Section 6.1)
---------
D) Then, the sender can send out as many new DATA chunks as Rule A and Rule B above allow.
D）次に、送信者は、上記のルールAとルールBで許可されている数の新しいDATAチャンクを送信できます。
---------
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 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.
または、出力ルーチンによって送信されるパケットの数を厳密に制限することで適用できます。
E) Then, the sender can send out as many new DATA chunks as Rule A and Rule B allow.
E）次に、送信者は、ルールAとルールBが許可するだけの新しいDATAチャンクを送信できます。
---------
Old text: (Section 7.2.1)
---------
o When cwnd is less than or equal to ssthresh an SCTP endpoint MUST use the slow start algorithm to increase cwnd (assuming the current congestion window is being fully utilized). If an incoming SACK advances the Cumulative TSN Ack Point, cwnd MUST be increased by at most the lesser of 1) the total size of the previously outstanding DATA chunk(s) acknowledged, and 2) the destination's path MTU. This protects against the ACK-Splitting attack outlined in [SAVAGE99].
o cwndがssthresh以下の場合、SCTPエンドポイントはスロースタートアルゴリズムを使用してcwndを増やす必要があります（現在の輻輳ウィンドウが完全に利用されていると想定）。着信SACKが累積TSN Ackポイントを進める場合、cwndは最大で1）確認済みの以前の未処理のDATAチャンクの合計サイズ、および2）宛先のパスMTUの小さい方の値まで増加する必要があります。これは、[SAVAGE99]で概説されているACK分割攻撃から保護します。
---------
New text: (Section 7.2.1)
---------
o When cwnd is less than or equal to ssthresh, an SCTP endpoint MUST use the slow start algorithm to increase cwnd only if the current congestion window is being fully utilized, an incoming SACK advances the Cumulative TSN Ack Point, and the data sender is not in Fast Recovery. Only when these three conditions are met can the cwnd be increased; otherwise, the cwnd MUST not be increased. If these conditions are met, then cwnd MUST be increased by, at most, the lesser of 1) the total size of the previously outstanding DATA chunk(s) acknowledged, and 2) the destination's path MTU. This upper bound protects against the ACK-Splitting attack outlined in [SAVAGE99].
o cwndがssthresh以下の場合、SCTPエンドポイントは、現在の輻輳ウィンドウが完全に利用されており、着信SACKが累積TSN ACKポイントを進め、データ送信者がいない場合にのみ、スロースタートアルゴリズムを使用してcwndを増やす必要があります。早い回復。これらの3つの条件が満たされた場合にのみ、cwndを増やすことができます。それ以外の場合は、cwndを増やしてはなりません（MUST）。これらの条件が満たされている場合、cwndは、最大で、1）確認済みの以前の未処理のDATAチャンクの合計サイズ、および2）宛先のパスMTUの小さい方だけ増やす必要があります。この上限は、[SAVAGE99]で概説されているACK分割攻撃から保護します。
---------
Old text: (Section 14)
---------
14. Suggested SCTP Protocol Parameter Values
14. SCTPプロトコルパラメータの推奨値
The following protocol parameters are RECOMMENDED:
次のプロトコルパラメータを推奨します。
RTO.Initial - 3 seconds
RTO.Min - 1 second
RTO.Max - 60 seconds
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
---------
New text: (Section 14)
---------
14. Suggested SCTP Protocol Parameter Values
14. SCTPプロトコルパラメータの推奨値
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
The above changes strengthen the rules and make it much more apparent as to the need to block cwnd growth when the full cwnd is not being utilized. The changes also apply cwnd degradation without introducing the need for complex special case code.
上記の変更により、ルールが強化され、完全なcwndが使用されていないときにcwndの成長をブロックする必要性がより明確になります。変更はまた、複雑な特殊なケースのコードを必要とせずに、cwndの低下を適用します。
When a receiver clamps its rwnd to 0 to flow control the peer, the specification implies that one must continue to accept data from the remote peer. This is incorrect and needs clarification.
レシーバーがrwndを0にクランプしてピアをフロー制御する場合、仕様では、リモートピアからのデータを引き続き受け入れなければならないことが示されています。これは誤りであり、説明が必要です。
---------
Old text: (Section 6.2)
---------
The SCTP endpoint MUST always acknowledge the receipt of each valid DATA chunk.
SCTPエンドポイントは、有効な各DATAチャンクの受信を常に確認する必要があります。
---------
New text: (Section 6.2)
---------
The SCTP endpoint MUST always acknowledge the reception of each valid DATA chunk when the DATA chunk received is inside its receive window.
受信したDATAチャンクが受信ウィンドウ内にある場合、SCTPエンドポイントは常に有効な各DATAチャンクの受信を確認する必要があります。
When the receiver's advertised window is 0, the receiver MUST drop any new incoming DATA chunk with a TSN larger than the largest TSN received so far. If the new incoming DATA chunk holds a TSN value less than the largest TSN received so far, then the receiver SHOULD drop the largest TSN held for reordering and accept the new incoming DATA chunk. In either case, if such a DATA chunk is dropped, the receiver MUST immediately send back a SACK with the current receive window showing only DATA chunks received and accepted so far. The dropped DATA chunk(s) MUST NOT be included in the SACK, as they were not accepted. The receiver MUST also have an algorithm for advertising its receive window to avoid receiver silly window syndrome (SWS), as described in RFC 813. The algorithm can be similar to the one described in Section 4.2.3.3 of RFC 1122.
受信者のアドバタイズされたウィンドウが0の場合、受信者は、これまでに受信した最大のTSNよりも大きいTSNを持つ新しい着信DATAチャンクをドロップする必要があります。新しい着信DATAチャンクがこれまでに受信した最大のTSN未満のTSN値を保持している場合、受信者は並べ替えのために保持されている最大のTSNを破棄し、新しい着信DATAチャンクを受け入れる必要があります。どちらの場合でも、そのようなDATAチャンクがドロップされた場合、受信者は、現在の受信ウィンドウに現在まで受信および受け入れられたDATAチャンクのみを示すSACKをすぐに送信する必要があります。ドロップされたDATAチャンクは受け入れられなかったため、SACKに含めることはできません。 RFC 813で説明されているように、受信者は受信ウィンドウをアドバタイズして受信者の愚かなウィンドウシンドローム（SWS）を回避するアルゴリズムも持っている必要があります。アルゴリズムは、RFC 1122のセクション4.2.3.3で説明されているものと同様にすることができます。
---------
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 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の変更をプローブできます。
---------
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 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チャンクが実行されていない場合にのみ送信する必要があることに注意してください。ゼロウィンドウプローブをサポートする必要があります。
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. The sender SHOULD send the first zero window probe after 1 RTO when it detects that the receiver has closed its window and SHOULD increase the probe interval exponentially afterwards. Also note that the cwnd SHOULD be adjusted according to Section 7.2.1. Zero window probing does not affect the calculation of cwnd.
ゼロウィンドウプローブを実行している間、送信側が受信側から新しいパケットを受信し続ける場合、未確認ウィンドウプローブは、アソシエーションまたは宛先トランスポートアドレスのエラーカウンターをインクリメントしないでください。 。ゼロウィンドウをアドバタイズするときのレシーバーの動作については、セクション6.2を参照してください。送信側は、受信側がウィンドウを閉じたことを検出すると、1 RTOの後に最初のゼロウィンドウプローブを送信する必要があり（SHOULD）、その後、プローブ間隔を指数関数的に増加させる必要があります（SHOULD）。また、cwndはセクション7.2.1に従って調整する必要があることに注意してください。ゼロウィンドウプローブは、cwndの計算に影響を与えません。
The sender MUST also have an algorithm for sending new DATA chunks to avoid silly window syndrome (SWS) as described in RFC 813. The algorithm can be similar to the one described in Section 4.2.3.4 of RFC 1122.
送信者は、RFC 813で説明されている愚かなウィンドウシンドローム（SWS）を回避するために、新しいDATAチャンクを送信するためのアルゴリズムも持っている必要があります。アルゴリズムは、RFC 1122のセクション4.2.3.4で説明されているものと同様にすることができます。
The above allows a receiver to drop new data that arrives and yet still requires the receiver to send a SACK showing the conditions unchanged (with the possible exception of a new a_rwnd) and the dropped chunk as missing. This will allow the association to continue until the rwnd condition clears.
上記により、レシーバーは到着した新しいデータをドロップできますが、変更されていない状態（新しいa_rwndを除く）と欠落したチャンクを示すSACKを送信する必要があります。これにより、rwnd状態がクリアされるまで関連付けを続行できます。
The current wording of the Fragmentation and Reassembly forces an implementation that supports fragmentation to always fragment. This prohibits an implementation from offering its users an option to disable sends that exceed the SCTP fragmentation point.
フラグメンテーションおよびリアセンブリの現在の表現では、フラグメンテーションをサポートする実装が常にフラグメント化するように強制されます。これにより、実装では、SCTP断片化ポイントを超える送信を無効にするオプションをユーザーに提供できなくなります。
The restriction in RFC 2960 [5], Section 6.9, was never meant to restrict an implementations API from this behavior.
RFC 2960 [5]のセクション6.9の制限は、実装APIをこの動作から制限することを意図したものではありません。
---------
Old text: (Section 6.1)
---------
6.9 Fragmentation and Reassembly
6.9 断片化と再構成
An endpoint MAY support fragmentation when sending DATA chunks, but MUST support reassembly when receiving DATA chunks. If an endpoint supports fragmentation, it MUST fragment a user message if the size of the user message to be sent causes the outbound SCTP packet size to exceed the current MTU. If an implementation does not support fragmentation of outbound user messages, the endpoint must return an error to its upper layer and not attempt to send the user message.
エンドポイントは、DATAチャンクを送信するときの断片化をサポートできますが、DATAチャンクを受信するときの再構成をサポートする必要があります。エンドポイントが断片化をサポートしている場合、送信されるユーザーメッセージのサイズによって送信SCTPパケットサイズが現在のMTUを超える場合、エンドポイントはユーザーメッセージを断片化する必要があります。実装が発信ユーザーメッセージの断片化をサポートしていない場合、エンドポイントはエラーを上位層に返し、ユーザーメッセージを送信しないようにする必要があります。
IMPLEMENTATION NOTE: In this error case, the Send primitive discussed in Section 10.1 would need to return an error to the upper layer.
実装上の注意：このエラーの場合、セクション10.1で説明した送信プリミティブは、上位層にエラーを返す必要があります。
---------
New text: (Section 6.1)
---------
6.9. Fragmentation and Reassembly
6.9. 断片化と再構成
An endpoint MAY support fragmentation when sending DATA chunks, but it MUST support reassembly when receiving DATA chunks. If an endpoint supports fragmentation, it MUST fragment a user message if the size of the user message to be sent causes the outbound SCTP packet size to exceed the current MTU. If an implementation does not support fragmentation of outbound user messages, the endpoint MUST return an error to its upper layer and not attempt to send the user message.
エンドポイントは、DATAチャンクを送信するときの断片化をサポートしてもかまいませんが、DATAチャンクを受信するときの再構成をサポートする必要があります。エンドポイントが断片化をサポートしている場合、送信されるユーザーメッセージのサイズによって送信SCTPパケットサイズが現在のMTUを超える場合、エンドポイントはユーザーメッセージを断片化する必要があります。実装がアウトバウンドユーザーメッセージの断片化をサポートしない場合、エンドポイントはその上位層にエラーを返さなければならず、ユーザーメッセージの送信を試みてはなりません（MUST）。
Note: If an implementation that supports fragmentation makes available to its upper layer a mechanism to turn off fragmentation it may do so. However, in so doing, it MUST react just like an implementation that does NOT support fragmentation, i.e., it MUST reject sends that exceed the current P-MTU.
注：断片化をサポートする実装が、その上位層で断片化をオフにするメカニズムを利用できるようにする場合は、そうすることができます。ただし、そうすることで、フラグメンテーションをサポートしない実装と同様に反応する必要があります。つまり、現在のP-MTUを超える送信を拒否する必要があります。
IMPLEMENTATION NOTE: In this error case, the Send primitive discussed in Section 10.1 would need to return an error to the upper layer.
実装上の注意：このエラーの場合、セクション10.1で説明した送信プリミティブは、上位層にエラーを返す必要があります。
The above wording will allow an implementation to offer the option of rejecting sends that exceed the P-MTU size even when the implementation supports fragmentation.
上記の文言により、実装がフラグメンテーションをサポートしている場合でも、実装はP-MTUサイズを超える送信を拒否するオプションを提供できます。
The current description of the SACK chunk within the RFC does not clearly state the value that would be put within a SACK when no DATA chunk has been received.
RFC内のSACKチャンクの現在の説明では、DATAチャンクが受信されなかった場合にSACK内に配置される値を明確に述べていません。
---------
Old text: (Section 3.3.4)
---------
Cumulative TSN Ack: 32 bits (unsigned integer)
累積TSN Ack：32ビット（符号なし整数）
This parameter contains the TSN of the last DATA chunk received in sequence before a gap.
このパラメータには、ギャップの前に順番に受信された最後のDATAチャンクのTSNが含まれています。
---------
New text: (Section 3.3.4)
---------
Cumulative TSN Ack: 32 bits (unsigned integer)
累積TSN Ack：32ビット（符号なし整数）
This parameter contains the TSN of the last DATA chunk received in sequence before a gap. In the case where no DATA chunk has been received, this value is set to the peer's Initial TSN minus one.
このパラメータには、ギャップの前に順番に受信された最後のDATAチャンクのTSNが含まれています。 DATAチャンクが受信されなかった場合、この値はピアの初期TSN-1に設定されます。
This change clearly states what the initial value will be for a SACK sender.
この変更により、SACK送信側の初期値が明確になります。
The current description on handling address parameters contained within the INIT and INIT-ACK does not fully describe a requirement for their handling.
INITおよびINIT-ACKに含まれるアドレスパラメータの処理に関する現在の説明では、それらの処理の要件を完全には説明していません。
---------
Old text: (Section 5.1.2)
---------
C) If there are only IPv4/IPv6 addresses present in the received INIT or INIT ACK chunk, the receiver shall derive and record all the transport address(es) from the received chunk AND the source IP address that sent the INIT or INIT ACK. The transport address(es) are derived by the combination of SCTP source port (from the common header) and the IP address parameter(s) carried in the INIT or INIT ACK chunk and the source IP address of the IP datagram. The receiver should use only these transport addresses as destination transport addresses when sending subsequent packets to its peer.
C）受信したINITまたはINIT ACKチャンクにIPv4 / IPv6アドレスしかない場合、受信者は受信したチャンクからすべてのトランスポートアドレスと、INITまたはINIT ACKを送信したソースIPアドレスを導出して記録します。トランスポートアドレスは、SCTP送信元ポート（共通ヘッダーから）と、INITまたはINIT ACKチャンクで伝送されるIPアドレスパラメーター、およびIPデータグラムの送信元IPアドレスの組み合わせによって導出されます。受信者は、後続のパケットをピアに送信するときに、これらのトランスポートアドレスのみを宛先トランスポートアドレスとして使用する必要があります。
---------
New text: (Section 5.1.2)
---------
C) If there are only IPv4/IPv6 addresses present in the received INIT or INIT ACK chunk, the receiver MUST derive and record all the transport addresses from the received chunk AND the source IP address that sent the INIT or INIT ACK. The transport addresses are derived by the combination of SCTP source port (from the common header) and the IP address parameter(s) carried in the INIT or INIT ACK chunk and the source IP address of the IP datagram. The receiver should use only these transport addresses as destination transport addresses when sending subsequent packets to its peer.
C）受信したINITまたはINIT ACKチャンクにIPv4 / IPv6アドレスのみが存在する場合、受信者は、受信したチャンクからすべてのトランスポートアドレスと、INITまたはINIT ACKを送信したソースIPアドレスを導出して記録する必要があります。トランスポートアドレスは、（共通ヘッダーからの）SCTPソースポートと、INITまたはINIT ACKチャンクで伝送されるIPアドレスパラメータおよびIPデータグラムのソースIPアドレスの組み合わせによって導出されます。受信者は、後続のパケットをピアに送信するときに、これらのトランスポートアドレスのみを宛先トランスポートアドレスとして使用する必要があります。
D) An INIT or INIT ACK chunk MUST be treated as belonging to an already established association (or one in the process of being established) if the use of any of the valid address parameters contained within the chunk would identify an existing TCB.
D）チャンク内に含まれる有効なアドレスパラメータのいずれかを使用して既存のTCBを識別する場合、INITまたはINIT ACKチャンクは、すでに確立されている関連付け（または確立中の関連付け）に属するものとして扱われなければなりません（MUST）。
This new text clearly specifies to an implementor the need to look within the INIT or INIT ACK. Any implementation that does not do this may (for example) not be able to recognize an INIT chunk coming from an already established association that adds new addresses (see Section 2.6) or an incoming INIT ACK chunk sent from a source address different from the destination address used to send the INIT chunk.
この新しいテキストは、INITまたはINIT ACK内を調べる必要性を実装者に明確に示しています。これを行わない実装では、（たとえば）新しいアドレスを追加する確立済みのアソシエーション（セクション2.6を参照）からのINITチャンク、または宛先とは異なるソースアドレスから送信された着信INIT ACKチャンクを認識できない場合があります。 INITチャンクの送信に使用されるアドレス。
The current wording in the RFC places the choice of sending an ABORT upon the SCTP stack when a stream shortage occurs. This decision should really be made by the upper layer, not the SCTP stack.
RFCの現在の表現では、ストリームの不足が発生したときに、SCTPスタックにABORTを送信するという選択肢があります。この決定は、SCTPスタックではなく、実際には上位層で行う必要があります。
---------
Old text:
---------
5.1.1 Handle Stream Parameters
5.1.1 ストリームパラメータの処理
In the INIT and INIT ACK chunks, the sender of the chunk shall indicate the number of outbound streams (OS) it wishes to have in the association, as well as the maximum inbound streams (MIS) it will accept from the other endpoint.
INITおよびINIT ACKチャンクでは、チャンクの送信者は、アソシエーションに含めたい発信ストリーム（OS）の数と、他のエンドポイントから受け入れる最大着信ストリーム（MIS）を示します。
After receiving the stream configuration information from the other side, each endpoint shall perform the following check: If the peer's MIS is less than the endpoint's OS, meaning that the peer is incapable of supporting all the outbound streams the endpoint wants to configure, the endpoint MUST either use MIS outbound streams, or abort the association and report to its upper layer the resources shortage at its peer.
反対側からストリーム構成情報を受信した後、各エンドポイントは次のチェックを実行する必要があります。ピアのMISがエンドポイントのOSより小さい場合、つまり、エンドポイントが構成するすべての送信ストリームをピアがサポートできない場合、エンドポイントMISアウトバウンドストリームを使用するか、関連付けを中止して、ピアでのリソース不足を上位層に報告する必要があります。
---------
New text: (Section 5.1.2)
---------
5.1.1. Handle Stream Parameters
5.1.1. ストリームパラメータの処理
In the INIT and INIT ACK chunks, the sender of the chunk MUST indicate the number of outbound streams (OS) it wishes to have in the association, as well as the maximum inbound streams (MIS) it will accept from the other endpoint.
INITおよびINIT ACKチャンクでは、チャンクの送信者は、アソシエーションに含めたいアウトバウンドストリーム（OS）の数と、他のエンドポイントから受け入れる最大インバウンドストリーム（MIS）を示さなければなりません（MUST）。
After receiving the stream configuration information from the other side, each endpoint MUST perform the following check: If the peer's MIS is less than the endpoint's OS, meaning that the peer is incapable of supporting all the outbound streams the endpoint wants to configure, the endpoint MUST use MIS outbound streams and MAY report any shortage to the upper layer. The upper layer can then choose to abort the association if the resource shortage is unacceptable.
反対側からストリーム構成情報を受信した後、各エンドポイントは次のチェックを実行する必要があります：ピアのMISがエンドポイントのOSより小さい場合、つまり、エンドポイントが構成するすべての送信ストリームをピアがサポートできない場合、エンドポイントMISアウトバウンドストリームを使用する必要があり、不足を上位層に報告する場合があります。上位層は、リソース不足が許容できない場合、関連付けを中止することを選択できます。
The above changes take the decision to ABORT out of the realm of the SCTP stack and place it into the user's hands.
上記の変更により、SCTPスタックの領域からABORTを実行して、ユーザーの手に渡すという決定が行われます。
The current RFC does not provide any guidance on the assignment of TSN sequence numbers to outbound messages nor reception of these messages. This could lead to a possible indefinite postponement.
現在のRFCでは、送信メッセージへのTSNシーケンス番号の割り当てや、これらのメッセージの受信に関するガイダンスは提供されていません。これにより、無期限に延期される可能性があります。
---------
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）。
6.2 Acknowledgement on Reception of DATA Chunks
6.2 DATAチャンクの受信に関する謝辞
---------
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.
注：データ送信者は、現在の送信ウィンドウの開始TSNの2 ** 31-1以上のTSNを使用してはなりません（SHOULD NOT）。
The algorithm by which an implementation assigns sequential TSNs to messages on a particular association MUST ensure that no user message that has been accepted by SCTP is indefinitely postponed from being assigned a TSN. Acceptable algorithms for assigning TSNs include
実装が特定のアソシエーションのメッセージに順次TSNを割り当てるアルゴリズムは、SCTPによって受け入れられたユーザーメッセージがTSNの割り当てから無期限に延期されないようにする必要があります。 TSNを割り当てるための許容可能なアルゴリズムには、
(a) assigning TSNs in round-robin order over all streams with pending data; and
（a）保留中のデータがあるすべてのストリームにラウンドロビン順にTSNを割り当てる。そして
(b) preserving the linear order in which the user messages were submitted to the SCTP association.
（b）ユーザーメッセージがSCTPアソシエーションに送信された線形順序を維持する。
When an upper layer requests to read data on an SCTP association, the SCTP receiver SHOULD choose the message with the lowest TSN from among all deliverable messages. In SCTP implementations that allow a user to request data on a specific stream, this operation SHOULD NOT block if data is not available, since this can lead to a deadlock under certain conditions.
上位層がSCTPアソシエーションでデータの読み取りを要求する場合、SCTP受信者は、すべての配信可能なメッセージの中からTSNが最も低いメッセージを選択する必要があります（SHOULD）。ユーザーが特定のストリームでデータを要求できるようにするSCTP実装では、特定の条件下でデッドロックを引き起こす可能性があるため、データが利用できない場合、この操作はブロックしてはなりません（SHOULD NOT）。
6.2. Acknowledgement on Receipt of DATA Chunks
6.2. DATAチャンクの受領に関する謝辞
The above wording clarifies how TSNs SHOULD be assigned by the sender.
上記の文言は、TSNが送信者によってどのように割り当てられるべきであるかを明確にします。
It is not possible for an upper layer to abort the association and provide the peer with an indication of why the association is aborted.
上位層がアソシエーションを中止して、アソシエーションが中止された理由をピアに提供することはできません。
Some of the changes given here already include changes suggested in Section 2.6 of this document.
ここに示す変更の一部には、このドキュメントのセクション2.6で提案されている変更がすでに含まれています。
---------
Old text: (Section 3.3.10)
---------
Cause Code
Value Cause Code
--------- ----------------
1 Invalid Stream Identifier
2 Missing Mandatory Parameter
3 Stale Cookie Error
4 Out of Resource
5 Unresolvable Address
6 Unrecognized Chunk Type
7 Invalid Mandatory Parameter
8 Unrecognized Parameters
9 No User Data
10 Cookie Received While Shutting Down
Cause Length: 16 bits (unsigned integer)
原因の長さ：16ビット（符号なし整数）
Set to the size of the parameter in bytes, including the Cause Code, Cause Length, and Cause-Specific Information fields
[原因コード]、[原因の長さ]、[原因固有の情報]フィールドを含む、パラメータのサイズをバイト単位で設定します
Cause-specific Information: variable length
原因固有の情報：可変長
This field carries the details of the error condition.
このフィールドには、エラー状態の詳細が含まれます。
Sections 3.3.10.1 - 3.3.10.10 define error causes for SCTP. Guidelines for the IETF to define new error cause values are discussed in Section 13.3.
セクション3.3.10.1-3.3.10.10は、SCTPのエラー原因を定義します。 IETFが新しいエラー原因値を定義するためのガイドラインについては、セクション13.3で説明します。
---------
New text: (Section 3.3.10)
---------
Cause Code
Value Cause Code
--------- ----------------
1 Invalid Stream Identifier
2 Missing Mandatory Parameter
3 Stale Cookie Error
4 Out of Resource
5 Unresolvable Address
6 Unrecognized Chunk Type
7 Invalid Mandatory Parameter
8 Unrecognized Parameters
9 No User Data
10 Cookie Received While Shutting Down
11 Restart of an Association with New Addresses
12 User-Initiated Abort
Cause Length: 16 bits (unsigned integer)
原因の長さ：16ビット（符号なし整数）
Set to the size of the parameter in bytes, including the Cause Code, Cause Length, and Cause-Specific Information fields
[原因コード]、[原因の長さ]、[原因固有の情報]フィールドを含む、パラメータのサイズをバイト単位で設定します
Cause-specific Information: variable length
原因固有の情報：可変長
This field carries the details of the error condition.
このフィールドには、エラー状態の詳細が含まれます。
Sections 3.3.10.1 - 3.3.10.12 define error causes for SCTP. Guidelines for the IETF to define new error cause values are discussed in Section 13.3.
セクション3.3.10.1-3.3.10.12は、SCTPのエラー原因を定義しています。 IETFが新しいエラー原因値を定義するためのガイドラインについては、セクション13.3で説明します。
---------
New text: (Note: no old text, new error added in Section 3.3.10)
---------
3.3.10.12. User-Initiated Abort (12)
3.3.10.12. ユーザー開始の中止（12）
Cause of error
--------------
This error cause MAY be included in ABORT chunks that are sent because of an upper layer request. The upper layer can specify an Upper Layer Abort Reason that is transported by SCTP transparently and MAY be delivered to the upper layer protocol at the peer.
このエラーの原因は、上位層の要求が原因で送信されるABORTチャンクに含まれる場合があります。上位層は、SCTPによって透過的に転送される上位層中止理由を指定でき、ピアの上位層プロトコルに配信される場合があります。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=12 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Upper Layer Abort Reason /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
---------
Old text: (Section 9.1)
---------
9.1 Abort of an Association
9.1 アソシエーションの中止
When an endpoint decides to abort an existing association, it shall send an ABORT chunk to its peer endpoint. The sender MUST fill in the peer's Verification Tag in the outbound packet and MUST NOT bundle any DATA chunk with the ABORT.
エンドポイントが既存の関連付けを中止することを決定した場合、エンドポイントはそのピアエンドポイントにABORTチャンクを送信します。送信者は、発信パケットにピアの検証タグを入力する必要があり、データチャンクをABORTにバンドルしてはなりません。
An endpoint MUST NOT respond to any received packet that contains an ABORT chunk (also see Section 8.4).
エンドポイントは、ABORTチャンクを含む受信パケットに応答してはなりません（MUST 8.4も参照）。
An endpoint receiving an ABORT shall apply the special Verification Tag check rules described in Section 8.5.1.
ABORTを受信するエンドポイントは、8.5.1項で説明されている特別な検証タグチェックルールを適用するものとします。
After checking the Verification Tag, the receiving endpoint shall remove the association from its record and shall report the termination to its upper layer.
検証タグをチェックした後、受信エンドポイントはその関連付けをレコードから削除し、終了を上位層に報告します。
---------
New text: (Section 9.1)
---------
9.1. Abort of an Association
9.1. アソシエーションの中止
When an endpoint decides to abort an existing association, it MUST send an ABORT chunk to its peer endpoint. The sender MUST fill in the peer's Verification Tag in the outbound packet and MUST NOT bundle any DATA chunk with the ABORT. If the association is aborted on request of the upper layer, a User-Initiated Abort error cause (see 3.3.10.12) SHOULD be present in the ABORT chunk.
エンドポイントが既存のアソシエーションを中止することを決定した場合、そのエンドポイントにABORTチャンクを送信する必要があります。送信者は、発信パケットにピアの検証タグを入力する必要があり、データチャンクをABORTにバンドルしてはなりません。上位層の要求により関連付けが中止された場合、ユーザーが開始した中止エラーの原因（3.3.10.12を参照）はABORTチャンクに存在する必要があります（SHOULD）。
An endpoint MUST NOT respond to any received packet that contains an ABORT chunk (also see Section 8.4).
エンドポイントは、ABORTチャンクを含む受信パケットに応答してはなりません（MUST 8.4も参照）。
An endpoint receiving an ABORT MUST apply the special Verification Tag check rules described in Section 8.5.1.
ABORTを受信するエンドポイントは、セクション8.5.1で説明されている特別な検証タグチェックルールを適用する必要があります。
After checking the Verification Tag, the receiving endpoint MUST remove the association from its record and SHOULD report the termination to its upper layer. If a User-Initiated Abort error cause is present in the ABORT chunk, the Upper Layer Abort Reason SHOULD be made available to the upper layer.
検証タグをチェックした後、受信側エンドポイントはその関連付けをレコードから削除する必要があり、その上位層に終了を報告する必要があります（SHOULD）。ユーザーが開始した中止エラーの原因がABORTチャンクに存在する場合、上位層の中止理由は上位層で利用可能にする必要があります（SHOULD）。
---------
Old text: (Section 10.1)
---------
D) Abort
D）中絶
Format: ABORT(association id [, cause code]) -> result
形式：ABORT（関連付けID [、原因コード]）->結果
Ungracefully closes an association. Any locally queued user data will be discarded and an ABORT chunk is sent to the peer. A success code will be returned on successful abortion of the association. If attempting to abort the association results in a failure, an error code shall be returned.
関連付けを不適切に閉じます。ローカルでキューに入れられたユーザーデータはすべて破棄され、ABORTチャンクがピアに送信されます。関連付けの中止が成功すると、成功コードが返されます。関連付けを中止しようとすると失敗した場合は、エラーコードが返されます。
Mandatory attributes:
必須の属性：
o association id - local handle to the SCTP association
o アソシエーションID-SCTPアソシエーションへのローカルハンドル
Optional attributes:
オプションの属性：
o cause code - reason of the abort to be passed to the peer.
o 原因コード-打ち切りの理由がピアに渡されます。
---------
New text: (Section 10.1)
---------
D) Abort
D）中絶
Format: ABORT(association id [, Upper Layer Abort Reason]) -> result
フォーマット：ABORT（association id [、Upper Layer Abort Reason]）->結果
Ungracefully closes an association. Any locally queued user data will be discarded, and an ABORT chunk is sent to the peer. A success code will be returned on successful abortion of the association. If attempting to abort the association results in a failure, an error code shall be returned.
関連付けを不適切に閉じます。ローカルでキューに入れられたユーザーデータはすべて破棄され、ABORTチャンクがピアに送信されます。関連付けの中止が成功すると、成功コードが返されます。関連付けを中止しようとすると失敗した場合は、エラーコードが返されます。
Mandatory attributes:
必須の属性：
o association id - Local handle to the SCTP association.
o association id-SCTPアソシエーションへのローカルハンドル。
Optional attributes:
オプションの属性：
o Upper Layer Abort Reason - Reason of the abort to be passed to the peer.
o 上位層の中止理由-ピアに渡される中止の理由。
None.
なし。
---------
Old text: (Section 10.2)
---------
E) COMMUNICATION LOST notification
E）COMMUNICATION LOST通知
When SCTP loses communication to an endpoint completely (e.g., via Heartbeats) or detects that the endpoint has performed an abort operation, it shall invoke this notification on the ULP.
SCTPがエンドポイントとの通信を完全に（ハートビートなどを介して）失うか、エンドポイントが中止操作を実行したことを検出すると、ULPでこの通知を呼び出します。
The following shall be passed with the notification:
次のものは通知とともに渡されます。
o association id - local handle to the SCTP association
o アソシエーションID-SCTPアソシエーションへのローカルハンドル
o status - This indicates what type of event has occurred; The status may indicate a failure OR a normal termination event occurred in response to a shutdown or abort request.
o status-これは、発生したイベントのタイプを示します。ステータスは、障害を示しているか、シャットダウンまたは中止要求に応答して通常の終了イベントが発生したことを示している可能性があります。
The following may be passed with the notification:
通知では以下が渡される場合があります。
o data retrieval id - an identification used to retrieve unsent and unacknowledged data.
o データ取得ID-未送信および未確認のデータを取得するために使用されるID。
o last-acked - the TSN last acked by that peer endpoint;
o last-acked-そのピアエンドポイントによって最後に確認されたTSN。
o last-sent - the TSN last sent to that peer endpoint;
o last-sent-そのピアエンドポイントに最後に送信されたTSN。
---------
New text: (Section 10.2)
---------
E) COMMUNICATION LOST notification
E）COMMUNICATION LOST通知
When SCTP loses communication to an endpoint completely (e.g., via Heartbeats) or detects that the endpoint has performed an abort operation, it shall invoke this notification on the ULP.
SCTPがエンドポイントとの通信を完全に（ハートビートなどを介して）失うか、エンドポイントが中止操作を実行したことを検出すると、ULPでこの通知を呼び出します。
The following shall be passed with the notification:
次のものは通知とともに渡されます。
o association id - Local handle to the SCTP association.
o association id-SCTPアソシエーションへのローカルハンドル。
o status - This indicates what type of event has occurred; The status may indicate that a failure OR a normal termination event occurred in response to a shutdown or abort request.
o status-これは、発生したイベントのタイプを示します。ステータスは、シャットダウンまたはアボート要求に応答して、障害または通常の終了イベントが発生したことを示す場合があります。
The following may be passed with the notification:
通知では以下が渡される場合があります。
o data retrieval id - An identification used to retrieve unsent and unacknowledged data.
o データ取得ID-未送信および未確認のデータを取得するために使用されるID。
o last-acked - The TSN last acked by that peer endpoint.
o last-acked-そのピアエンドポイントによって最後に確認されたTSN。
o last-sent - The TSN last sent to that peer endpoint.
o last-sent-そのピアエンドポイントに最後に送信されたTSN。
o Upper Layer Abort Reason - The abort reason specified in case of a user-initiated abort.
o 上位層の中止理由-ユーザーが開始した中止の場合に指定された中止理由。
The above allows an upper layer to provide its peer with an indication of why the association was aborted. Therefore, an addition error cause was introduced.
上記により、上位層がピアに、アソシエーションが中止された理由を示すことができます。したがって、追加エラーの原因が導入されました。
RFC 2960 requires that the receiver of an INIT-ACK with the Initiate Tag set to zero handles this as an error and sends back an ABORT. But the sender of the INIT-ACK normally has no TCB, and thus the ABORT is useless.
RFC 2960では、開始タグがゼロに設定されたINIT-ACKの受信者がこれをエラーとして処理し、ABORTを返信する必要があります。ただし、INIT-ACKの送信側には通常TCBがないため、ABORTは役に立ちません。
---------
Old text: (Section 3.3.3)
---------
Initiate Tag: 32 bits (unsigned integer)
タグの開始：32ビット（符号なし整数）
The receiver of the INIT ACK records the value of the Initiate Tag parameter. This value MUST be placed into the Verification Tag field of every SCTP packet that the INIT ACK receiver transmits within this association.
INIT ACKの受信側は、Initiate Tagパラメータの値を記録します。この値は、このアソシエーション内でINIT ACKレシーバーが送信するすべてのSCTPパケットの検証タグフィールドに配置する必要があります。
The Initiate Tag MUST NOT take the value 0. See Section 5.3.1 for more on the selection of the Initiate Tag value.
開始タグは値0をとってはなりません。開始タグ値の選択の詳細については、セクション5.3.1を参照してください。
If the value of the Initiate Tag in a received INIT ACK chunk is found to be 0, the receiver MUST treat it as an error and close the association by transmitting an ABORT.
受信したINIT ACKチャンクのInitiate Tagの値が0であることがわかった場合、受信者はそれをエラーとして扱い、ABORTを送信して関連付けを閉じる必要があります。
---------
New text: (Section 3.3.3)
---------
Initiate Tag: 32 bits (unsigned integer)
タグの開始：32ビット（符号なし整数）
The receiver of the INIT ACK records the value of the Initiate Tag parameter. This value MUST be placed into the Verification Tag field of every SCTP packet that the INIT ACK receiver transmits within this association.
INIT ACKの受信側は、Initiate Tagパラメータの値を記録します。この値は、このアソシエーション内でINIT ACKレシーバーが送信するすべてのSCTPパケットの検証タグフィールドに配置する必要があります。
The Initiate Tag MUST NOT take the value 0. See Section 5.3.1 for more on the selection of the Initiate Tag value.
開始タグは値0をとってはなりません。開始タグ値の選択の詳細については、セクション5.3.1を参照してください。
If the value of the Initiate Tag in a received INIT ACK chunk is found to be 0, the receiver MUST destroy the association discarding its TCB. The receiver MAY send an ABORT for debugging purpose.
受信したINIT ACKチャンクのInitiate Tagの値が0であることがわかった場合、受信者はそのTCBを破棄する関連付けを破棄する必要があります。受信者はデバッグ目的でABORTを送信してもよい（MAY）。
The new text does not require that the receiver of the invalid INIT-ACK send the ABORT. This behavior is in tune with the error case of invalid stream numbers in the INIT-ACK. However, sending an ABORT for debugging purposes is allowed.
新しいテキストでは、無効なINIT-ACKの受信者がABORTを送信する必要はありません。この動作は、INIT-ACKのストリーム番号が無効であるというエラーケースと調和しています。ただし、デバッグ目的でABORTを送信することはできます。
Whenever the receiver of an INIT chunk has to send an ABORT chunk in response, for whatever reason, it is not stated clearly which Verification Tag and value of the T-bit should be used.
INITチャンクの受信側が応答としてABORTチャンクを送信する必要がある場合は常に、理由の如何を問わず、どの検証タグとTビットの値を使用する必要があるかは明確に述べられていません。
---------
Old text: (Section 8.4)
---------
3) If the packet contains an INIT chunk with a Verification Tag set to '0', process it as described in Section 5.1. Otherwise,
3）パケットに検証タグが「0」に設定されたINITチャンクが含まれている場合は、セクション5.1の説明に従って処理します。さもないと、
---------
New text: (Section 8.4)
---------
3) If the packet contains an INIT chunk with a Verification Tag set to '0', process it as described in Section 5.1. If, for whatever reason, the INIT cannot be processed normally and an ABORT has to be sent in response, the Verification Tag of the packet containing the ABORT chunk MUST be the Initiate tag of the received INIT chunk, and the T-Bit of the ABORT chunk has to be set to 0, indicating that a TCB was destroyed. Otherwise,
3）パケットに検証タグが「0」に設定されたINITチャンクが含まれている場合は、セクション5.1の説明に従って処理します。何らかの理由でINITを正常に処理できず、ABORTを応答として送信する必要がある場合、ABORTチャンクを含むパケットの検証タグは、受信したINITチャンクの開始タグと、 ABORTチャンクは0に設定する必要があり、TCBが破棄されたことを示します。さもないと、
The new text stated clearly which value of the Verification Tag and T-bit have to be used.
新しいテキストには、検証タグとTビットのどの値を使用する必要があるかが明確に記載されていました。
RFC 2960 does not describe the fact that the SSN has to be initialized to 0, as required by RFC 2119.
RFC 2960は、RFC 2119で要求されているように、SSNを0に初期化する必要があるという事実を記述していません。
---------
Old text: (Section 6.5)
---------
The stream sequence number in all the streams shall start from 0 when the association is established. Also, when the stream sequence number reaches the value 65535 the next stream sequence number shall be set to 0.
関連付けが確立されると、すべてのストリームのストリームシーケンス番号は0から始まります。また、ストリームシーケンス番号が値65535に達すると、次のストリームシーケンス番号が0に設定されます。
---------
New text: (Section 6.5)
---------
The stream sequence number in all the streams MUST start from 0 when the association is established. Also, when the stream sequence number reaches the value 65535 the next stream sequence number MUST be set to 0.
関連付けが確立されると、すべてのストリームのストリームシーケンス番号は0から始まる必要があります。また、ストリームシーケンス番号が値65535に達すると、次のストリームシーケンス番号を0に設定する必要があります。
The 'shall' in the text is replaced by a 'MUST' to clearly state the required behavior.
本文中の「shall」は「MUST」に置き換えられ、必要な動作が明確に示されています。
It is not clear in RFC 2960 whether a SACK must contain the fields Number of Gap Ack Blocks and Number of Duplicate TSNs.
RFC 2960では、SACKにNumber of Gap Ack BlocksおよびNumber of Duplicate TSNsのフィールドを含める必要があるかどうかは明確ではありません。
---------
Old text: (Section 3.3.4)
---------
The SACK MUST contain the Cumulative TSN Ack and Advertised Receiver Window Credit (a_rwnd) parameters.
SACKには、累積TSN Ackおよびアドバタイズされたレシーバーウィンドウクレジット（a_rwnd）パラメーターが含まれている必要があります。
---------
New text: (Section 3.3.4)
---------
The SACK MUST contain the Cumulative TSN Ack, Advertised Receiver Window Credit (a_rwnd), Number of Gap Ack Blocks, and Number of Duplicate TSNs fields.
SACKには、累積TSN Ack、アドバタイズされたレシーバーウィンドウクレジット（a_rwnd）、ギャップAckブロックの数、および重複TSNフィールドの数が含まれている必要があります。
The text has been modified. It is now clear that a SACK always contains the fields Number of Gap Ack Blocks and Number of Duplicate TSNs.
テキストが変更されました。これで、SACKには常にフィールドのギャップACKブロックの数と重複TSNの数が含まれることが明らかになりました。
There are many situations where an SCTP endpoint may detect that its peer violates the protocol. The result of such detection often results in the association being destroyed by the sending of an ABORT. Currently, there are only some error causes that could be used to indicate the reason for the abort, but these do not cover all cases.
SCTPエンドポイントがそのピアがプロトコルに違反していることを検出する状況は数多くあります。このような検出の結果、ABORTの送信によって関連付けが破壊されることがよくあります。現在、アボートの理由を示すために使用できるエラーの原因はいくつかありますが、これらはすべてのケースをカバーしているわけではありません。
Some of the changes given here already include changes suggested in Section 2.6 and 2.21 of this document.
ここに示す変更の一部には、このドキュメントのセクション2.6および2.21で提案されている変更がすでに含まれています。
---------
Old text: (Section 3.3.10)
---------
Cause Code
Value Cause Code
--------- ----------------
1 Invalid Stream Identifier
2 Missing Mandatory Parameter
3 Stale Cookie Error
4 Out of Resource
5 Unresolvable Address
6 Unrecognized Chunk Type
7 Invalid Mandatory Parameter
8 Unrecognized Parameters
9 No User Data
10 Cookie Received While Shutting Down
Cause Length: 16 bits (unsigned integer)
原因の長さ：16ビット（符号なし整数）
Set to the size of the parameter in bytes, including the Cause Code, Cause Length, and Cause-Specific Information fields
[原因コード]、[原因の長さ]、[原因固有の情報]フィールドを含む、パラメータのサイズをバイト単位で設定します
Cause-specific Information: variable length
原因固有の情報：可変長
This field carries the details of the error condition.
このフィールドには、エラー状態の詳細が含まれます。
Sections 3.3.10.1 - 3.3.10.10 define error causes for SCTP. Guidelines for the IETF to define new error cause values are discussed in Section 13.3.
セクション3.3.10.1-3.3.10.10は、SCTPのエラー原因を定義します。 IETFが新しいエラー原因値を定義するためのガイドラインについては、セクション13.3で説明します。
---------
New text: (Section 3.3.10)
---------
Cause Code
Value Cause Code
--------- ----------------
1 Invalid Stream Identifier
2 Missing Mandatory Parameter
3 Stale Cookie Error
4 Out of Resource
5 Unresolvable Address
6 Unrecognized Chunk Type
7 Invalid Mandatory Parameter
8 Unrecognized Parameters
9 No User Data
10 Cookie Received While Shutting Down
11 Restart of an Association with New Addresses
12 User Initiated Abort
13 Protocol Violation
Cause Length: 16 bits (unsigned integer)
原因の長さ：16ビット（符号なし整数）
Set to the size of the parameter in bytes, including the Cause Code, Cause Length, and Cause-Specific Information fields
[原因コード]、[原因の長さ]、[原因固有の情報]フィールドを含む、パラメータのサイズをバイト単位で設定します
Cause-specific Information: variable length
原因固有の情報：可変長
This field carries the details of the error condition.
このフィールドには、エラー状態の詳細が含まれます。
Sections 3.3.10.1 - 3.3.10.13 define error causes for SCTP. Guidelines for the IETF to define new error cause values are discussed in Section 13.3.
セクション3.3.10.1-3.3.10.13は、SCTPのエラー原因を定義します。 IETFが新しいエラー原因値を定義するためのガイドラインについては、セクション13.3で説明します。
---------
New text: (Note: no old text; new error added in section 3.3.10)
---------
3.3.10.13. Protocol Violation (13)
3.3.10.13. プロトコル違反（13）
Cause of error
--------------
This error cause MAY be included in ABORT chunks that are sent because an SCTP endpoint detects a protocol violation of the peer that is not covered by the error causes described in 3.3.10.1 to 3.3.10.12. An implementation MAY provide additional information specifying what kind of protocol violation has been detected.
SCTPエンドポイントが、3.3.10.1から3.3.10.12で説明されているエラー原因でカバーされていないピアのプロトコル違反を検出するため、このエラー原因は送信されるABORTチャンクに含まれる場合があります。実装は、検出されたプロトコル違反の種類を指定する追加情報を提供する場合があります。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=13 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Additional Information /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An additional error cause has been defined that can be used by an endpoint to indicate a protocol violation of the peer.
エンドポイントがピアのプロトコル違反を示すために使用できる追加のエラー原因が定義されています。
It is not stated clearly in RFC 2960 [5] how unrecognized parameters should be reported. Unrecognized parameters in an INIT chunk could be reported in the INIT-ACK chunk or in a separate ERROR chunk, which can get lost. Unrecognized parameters in an INIT-ACK chunk have to be reported in an ERROR-chunk. This can be bundled with the COOKIE-ERROR chunk or sent separately. If it is sent separately and received before the COOKIE-ECHO, it will be handled as an OOTB packet, resulting in sending out an ABORT chunk. Therefore, the association would not be established.
RFC 2960 [5]には、認識されないパラメータがどのように報告されるかは明確に述べられていません。 INITチャンク内の認識されないパラメーターは、INIT-ACKチャンクまたは別のERRORチャンクで報告され、失われる可能性があります。 INIT-ACKチャンクの認識されないパラメーターは、ERROR-chunkで報告する必要があります。これはCOOKIE-ERRORチャンクにバンドルするか、個別に送信できます。個別に送信してCOOKIE-ECHOの前に受信した場合、OOTBパケットとして処理され、ABORTチャンクが送信されます。したがって、協会は設立されません。
Some of the changes given here already include changes suggested in Section 2.2 of this document.
ここに示す変更の一部には、このドキュメントのセクション2.2で提案されている変更がすでに含まれています。
---------
Old text: (Section 3.2.1)
---------
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 parameter in an 'Unrecognized Parameter Type' (in either an ERROR or in the INIT ACK).
01-このSCTPパケットの処理を停止して破棄し、その中のそれ以上のチャンクを処理せずに、「認識されないパラメータタイプ」（エラーまたはINIT ACKのいずれか）で認識されないパラメータを報告します。
10 - Skip this parameter and continue processing.
10-このパラメーターをスキップして、処理を続行します。
11 - Skip this parameter and continue processing but report the unrecognized parameter in an 'Unrecognized Parameter Type' (in either an ERROR or in the INIT ACK).
11-このパラメーターをスキップして処理を続行しますが、「認識されないパラメータータイプ」（ERRORまたはINIT ACKのいずれか）で認識されないパラメーターを報告します。
---------
New text: (Section 3.2.1)
---------
00 - Stop processing this SCTP chunk and discard it; do not process any further parameters within this chunk.
00-このSCTPチャンクの処理を停止して破棄します。このチャンク内でこれ以上パラメーターを処理しないでください。
01 - Stop processing this SCTP chunk and discard it, do not process any further parameters within this chunk, and report the unrecognized parameter in an 'Unrecognized Parameter Type', as described in 3.2.2.
01-このSCTPチャンクの処理を停止して破棄し、このチャンク内のそれ以上のパラメーターを処理せず、3.2.2で説明されているように、「認識されないパラメータータイプ」で認識されないパラメーターを報告します。
10 - Skip this parameter and continue processing.
10-このパラメーターをスキップして、処理を続行します。
11 - Skip this parameter and continue processing but report the unrecognized parameter in an 'Unrecognized Parameter Type', as described in 3.2.2.
11-このパラメーターをスキップして処理を続行しますが、3.2.2で説明されているように、「認識されないパラメータータイプ」で認識されないパラメーターを報告します。
---------
New text: (Note: no old text; clarification added in Section 3.2)
---------
3.2.2. Reporting of Unrecognized Parameters
3.2.2. 認識されないパラメータの報告
If the receiver of an INIT chunk detects unrecognized parameters and has to report them according to Section 3.2.1, it MUST put the 'Unrecognized Parameter' parameter(s) in the INIT-ACK chunk sent in response to the INIT-chunk. Note that if the receiver of the INIT chunk is NOT going to establish an association (e.g., due to lack of resources), then no report would be sent back.
INITチャンクのレシーバーが認識されないパラメーターを検出し、セクション3.2.1に従ってそれらを報告する必要がある場合、INITチャンクに応答して送信されるINIT-ACKチャンクに「Unrecognized Parameter」パラメーターを配置する必要があります。 INITチャンクの受信側が関連付けを確立しない場合（リソースの不足など）、レポートは返されないことに注意してください。
If the receiver of an INIT-ACK chunk detects unrecognized parameters and has to report them according to Section 3.2.1, it SHOULD bundle the ERROR chunk containing the 'Unrecognized Parameter' error cause with the COOKIE-ECHO chunk sent in response to the INIT-ACK chunk. If the receiver of the INIT-ACK cannot bundle the COOKIE-ECHO chunk with the ERROR chunk, the ERROR chunk MAY be sent separately but not before the COOKIE-ACK has been received.
INIT-ACKチャンクのレシーバーが認識されないパラメーターを検出し、セクション3.2.1に従ってそれらを報告する必要がある場合は、INITに応答して送信されたCOOKIE-ECHOチャンクに「Unrecognized Parameter」エラー原因を含むERRORチャンクをバンドルする必要があります（SHOULD）。 -ACKチャンク。 INIT-ACKの受信者がCOOKIE-ECHOチャンクをERRORチャンクとバンドルできない場合、ERRORチャンクは個別に送信できますが、COOKIE-ACKを受信する前に送信することはできません。
Note: Any time a COOKIE-ECHO is sent in a packet, it MUST be the first chunk.
注：COOKIE-ECHOがパケットで送信されるときは常に、それが最初のチャンクでなければなりません。
The procedure of reporting unrecognized parameters has been described clearly.
認識されないパラメータを報告する手順は明確に説明されています。
It is not stated clearly in RFC 2960 [5] how an SCTP endpoint that supports either IPv4 addresses or IPv6 addresses should respond if IPv4 and IPv6 addresses are presented by the peer in the INIT or INIT-ACK chunk.
RFC 2960 [5]では、IPv4およびIPv6アドレスがピアによってINITまたはINIT-ACKチャンクで提示された場合に、IPv4アドレスまたはIPv6アドレスのいずれかをサポートするSCTPエンドポイントがどのように応答するかは明確に述べられていません。
---------
Old text: (Section 5.1.2)
---------
IMPLEMENTATION NOTE: In the case that the receiver of an INIT ACK fails to resolve the address parameter due to an unsupported type, it can abort the initiation process and then attempt a re-initiation by using a 'Supported Address Types' parameter in the new INIT to indicate what types of address it prefers.
実装上の注意：サポートされていないタイプが原因でINIT ACKの受信者がアドレスパラメータを解決できない場合、初期化プロセスを中止し、新しいサポートされているアドレスタイプのパラメータを使用して再初期化を試みることができますINITは、優先するアドレスのタイプを示します。
---------
New text: (Section 5.1.2)
---------
IMPLEMENTATION NOTE: In the case that the receiver of an INIT ACK fails to resolve the address parameter due to an unsupported type, it can abort the initiation process and then attempt a re-initiation by using a 'Supported Address Types' parameter in the new INIT to indicate what types of address it prefers.
実装上の注意：サポートされていないタイプが原因でINIT ACKの受信者がアドレスパラメータを解決できない場合、初期化プロセスを中止し、新しいサポートされているアドレスタイプのパラメータを使用して再初期化を試みることができますINITは、優先するアドレスのタイプを示します。
IMPLEMENTATION NOTE: If an SCTP endpoint that only supports either IPv4 or IPv6 receives IPv4 and IPv6 addresses in an INIT or INIT-ACK chunk from its peer, it MUST use all the addresses belonging to the supported address family. The other addresses MAY be ignored. The endpoint SHOULD NOT respond with any kind of error indication.
実装上の注意：IPv4またはIPv6のいずれかのみをサポートするSCTPエンドポイントがピアからINITまたはINIT-ACKチャンクでIPv4およびIPv6アドレスを受信する場合、サポートされているアドレスファミリに属するすべてのアドレスを使用する必要があります。他のアドレスは無視されるかもしれません。エンドポイントは、いかなる種類のエラー表示でも応答してはなりません（SHOULD NOT）。
The procedure of handling IP address parameters has been described clearly.
IPアドレスパラメータの処理手順は明確に説明されています。
The description of the behavior in RFC 2960 [5] when a COOKIE ECHO chunk and a TCB exist could be misunderstood. When a COOKIE ECHO is received, a TCB exists and the local tag and peer's tag match, it is stated that the endpoint should enter the ESTABLISHED state if it has not already done so and send a COOKIE ACK. It was not clear that, in the case the endpoint has already left the ESTABLISHED state again, then it should not go back to established. In case D, the endpoint can only enter state ESTABLISHED from COOKIE-ECHOED because in state CLOSED it has no TCB and in state COOKIE-WAIT it has a TCB but knows nothing about the peer's tag, which is requested to match in this case.
COOKIE ECHOチャンクとTCBが存在する場合のRFC 2960 [5]の動作の説明は、誤解されている可能性があります。 COOKIE ECHOが受信され、TCBが存在し、ローカルタグとピアのタグが一致する場合、エンドポイントはまだ確立していない場合はESTABLISHED状態に入り、COOKIE ACKを送信する必要があると述べられています。エンドポイントがすでにESTABLISHED状態をすでに解除している場合、確立に戻るべきではないことは明らかではありませんでした。ケースDの場合、エンドポイントはCOOKIE-ECHOEDから状態ESTABLISHEDに入ることができるだけです。これは、状態CLOSEDにはTCBがなく、状態COOKIE-WAITにはTCBがあるためですが、この場合は一致が要求されているピアのタグについて何も知りません。
---------
Old text: (Section 5.2.4)
---------
D) When both local and remote tags match the endpoint should
always enter the ESTABLISHED state, if it has not already
done so. It should stop any init or cookie timers that may
be running and send a COOKIE ACK.
---------
New text: (Section 5.2.4)
---------
D) When both local and remote tags match, the endpoint should
enter the ESTABLISHED state, if it is in the COOKIE-ECHOED
state. It should stop any cookie timer that may
be running and send a COOKIE ACK.
The procedure of handling of COOKIE-ECHO chunks when a TCB exists has been described clearly.
TCBが存在する場合のCOOKIE-ECHOチャンクの処理手順が明確に説明されました。
RFC 2960 was published with the intention of having the same congestion control properties as TCP. Since the publication of RFC 2960, TCP's initial congestion window size has been increased via RFC 3390. This same update will be needed for SCTP to keep SCTP's congestion control properties equivalent to that of TCP.
RFC 2960は、TCPと同じ輻輳制御プロパティを持つことを目的として公開されました。 RFC 2960の公開以降、TCPの初期の輻輳ウィンドウサイズはRFC 3390によって増加しました。SCTPの輻輳制御プロパティをTCPと同等に保つには、SCTPにもこの同じ更新が必要になります。
---------
Old text: (Section 7.2.1)
---------
o The initial cwnd before DATA transmission or after a
sufficiently long idle period MUST be <= 2*MTU.
---------
New 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)).
---------
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, 2*MTU) per RTO.
---------
New 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.
---------
Old text: (Section 7.2.2)
---------
o Same as in the slow start, when the sender does not transmit
DATA on a given transport address, the cwnd of the transport
address should be adjusted to max(cwnd / 2, 2*MTU) per RTO.
---------
New text: (Section 7.2.2)
---------
o Same as in the slow start, when the sender 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.
---------
Old text: (Section 7.2.3)
---------
7.2.3. Congestion Control
7.2.3. 輻輳制御
Upon detection of packet losses from SACK (see Section 7.2.4), an endpoint should do the following:
SACKからのパケット損失を検出すると（セクション7.2.4を参照）、エンドポイントは以下を実行する必要があります。
ssthresh = max(cwnd/2, 2*MTU)
cwnd = ssthresh
Basically, a packet loss causes cwnd to be cut in half.
基本的に、パケット損失によりcwndが半分にカットされます。
When the T3-rtx timer expires on an address, SCTP should perform slow start by
T3-rtxタイマーがアドレスで期限切れになると、SCTPはスロースタートを実行する必要があります。
ssthresh = max(cwnd/2, 2*MTU)
cwnd = 1*MTU
---------
New text: (Section 7.2.3)
---------
7.2.3 Congestion Control
7.2.3 輻輳制御
Upon detection of packet losses from SACK (see Section 7.2.4), An endpoint should do the following:
SACKからのパケット損失を検出すると（セクション7.2.4を参照）、エンドポイントは以下を実行する必要があります。
ssthresh = max(cwnd/2, 4*MTU)
cwnd = ssthresh
Basically, a packet loss causes cwnd to be cut in half.
基本的に、パケット損失によりcwndが半分にカットされます。
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
The change to SCTP's initial congestion window will allow it to continue to maintain the same congestion control properties as TCP.
SCTPの初期の輻輳ウィンドウへの変更により、TCPと同じ輻輳制御プロパティを維持し続けることができます。
In Section 2.24 of this document, it is clarified that the SSN are initialized with 0. Two figures in RFC 2960 [5] illustrate that they start with 1.
このドキュメントのセクション2.24では、SSNが0で初期化されることが明確になっています。RFC2960 [5]の2つの図は、1で始まることを示しています。
---------
Old text: (Section 7.2.1)
---------
Endpoint A Endpoint Z
{app sets association with Z}
(build TCB)
INIT [I-Tag=Tag_A
& other info] ------\
(Start T1-init timer) \
(Enter COOKIE-WAIT state) \---> (compose temp TCB and Cookie_Z)
/-- INIT ACK [Veri Tag=Tag_A,
/ I-Tag=Tag_Z,
(Cancel T1-init timer) <-----/ Cookie_Z, & other info]
(destroy temp TCB)
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)
{app sends 1st user data; strm 0}
DATA [TSN=initial TSN_A
Strm=0,Seq=1 & user data]--\
(Start T3-rtx timer) \
\->
/----- SACK [TSN Ack=init
/ TSN_A,Block=0]
(Cancel T3-rtx timer) <------/
...
{app sends 2 messages;strm 0}
/---- DATA
/ [TSN=init TSN_Z
<--/ Strm=0,Seq=1 & user data 1]
SACK [TSN Ack=init TSN_Z, / ---- DATA
Block=0] --------\ / [TSN=init TSN_Z +1,
\/ Strm=0,Seq=2 & user data 2]
<------/\
\
\------>
Figure 4: INITiation Example
図4：初期化の例
---------
New text: (Section 7.2.1)
---------
Endpoint A Endpoint Z
{app sets association with Z}
(build TCB)
INIT [I-Tag=Tag_A
& other info] ------\
(Start T1-init timer) \
(Enter COOKIE-WAIT state) \---> (compose temp TCB and Cookie_Z)
/-- INIT ACK [Veri Tag=Tag_A,
/ I-Tag=Tag_Z,
(Cancel T1-init timer) <------/ Cookie_Z, & other info]
(destroy temp TCB)
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)
{app sends 1st user data; strm 0}
DATA [TSN=initial TSN_A
Strm=0,Seq=0 & user data]--\
(Start T3-rtx timer) \
\->
/----- SACK [TSN Ack=init
/ TSN_A,Block=0]
(Cancel T3-rtx timer) <------/
...
{app sends 2 messages;strm 0}
/---- DATA
/ [TSN=init TSN_Z
<--/ Strm=0,Seq=0 & user data 1]
SACK [TSN Ack=init TSN_Z, /---- DATA
Block=0] --------\ / [TSN=init TSN_Z +1,
\/ Strm=0,Seq=1 & user data 2]
<------/\
\
\------>
Figure 4: INITiation Example
図4：初期化の例
---------
Old text: (Section 5.2.4.1)
---------
Endpoint A Endpoint Z
<------------ Association is established---------------------->
Tag=Tag_A Tag=Tag_Z
<------------------------------------------------------------->
{A crashes and restarts}
{app sets up a association with Z}
(build TCB)
INIT [I-Tag=Tag_A'
& other info] --------\
(Start T1-init timer) \
(Enter COOKIE-WAIT state) \---> (find a existing TCB
compose temp TCB and Cookie_Z
with Tie-Tags to previous
association)
/--- INIT ACK [Veri Tag=Tag_A',
/ I-Tag=Tag_Z',
(Cancel T1-init timer) <------/ Cookie_Z[TieTags=
Tag_A,Tag_Z
& other info]
(destroy temp TCB,leave original
in place)
COOKIE ECHO [Veri=Tag_Z',
Cookie_Z
Tie=Tag_A,
Tag_Z]----------\
(Start T1-init timer) \
(Enter COOKIE-ECHOED state) \---> (Find existing association,
Tie-Tags match old tags,
Tags do not match i.e.,
case X X M M above,
Announce Restart to ULP
and reset association).
/---- COOKIE-ACK
(Cancel T1-init timer, <------/
Enter ESTABLISHED state)
{app sends 1st user data; strm 0}
DATA [TSN=initial TSN_A
Strm=0,Seq=1 & user data]--\
(Start T3-rtx timer) \
\->
/--- SACK [TSN Ack=init TSN_A,Block=0]
(Cancel T3-rtx timer) <------/
Figure 5: A Restart Example
図5：再起動の例
---------
New text: (Section 5.2.4.1)
---------
Endpoint A Endpoint Z
<-------------- Association is established---------------------->
Tag=Tag_A Tag=Tag_Z
<--------------------------------------------------------------->
{A crashes and restarts}
{app sets up a association with Z}
(build TCB)
INIT [I-Tag=Tag_A'
& other info] --------\
(Start T1-init timer) \
(Enter COOKIE-WAIT state) \---> (find a existing TCB
compose temp TCB and Cookie_Z
with Tie-Tags to previous
association)
/--- INIT ACK [Veri Tag=Tag_A',
/ I-Tag=Tag_Z',
(Cancel T1-init timer) <------/ Cookie_Z[TieTags=
Tag_A,Tag_Z
& other info]
(destroy temp TCB,leave original
in place)
COOKIE ECHO [Veri=Tag_Z',
Cookie_Z
Tie=Tag_A,
Tag_Z]----------\
(Start T1-init timer) \
(Enter COOKIE-ECHOED state) \---> (Find existing association,
Tie-Tags match old tags,
Tags do not match i.e.,
case X X M M above,
Announce Restart to ULP
and reset association).
/---- COOKIE-ACK
(Cancel T1-init timer, <------/
Enter ESTABLISHED state)
{app sends 1st user data; strm 0}
DATA [TSN=initial TSN_A
Strm=0,Seq=0 & user data]--\
(Start T3-rtx timer) \
\->
/--- SACK [TSN Ack=init TSN_A,Block=0]
(Cancel T3-rtx timer) <------/
Figure 5: A Restart Example
図5：再起動の例
Figure 4 and 5 were changed so that the SSN starts with 0 instead of 1.
図4および5は、SSNが1ではなく0で始まるように変更されました。
The RFC does not state clearly in Section 3.3.3.1 whether one or multiple unrecognized parameters are included in the 'Unrecognized Parameter' parameter.
RFCは、セクション3.3.3.1で、1つまたは複数の認識されないパラメーターが「認識されないパラメーター」パラメーターに含まれているかどうかを明確に述べていません。
---------
Old text: (Section 3.3.3)
---------
Variable Parameters Status Type Value
-------------------------------------------------------------
State Cookie Mandatory 7
IPv4 Address (Note 1) Optional 5
IPv6 Address (Note 1) Optional 6
Unrecognized Parameters Optional 8
Reserved for ECN Capable (Note 2) Optional 32768 (0x8000)
Host Name Address (Note 3) Optional 11
---------
New text: (Section 3.3.3)
---------
Variable Parameters Status Type Value
-------------------------------------------------------------
State Cookie Mandatory 7
IPv4 Address (Note 1) Optional 5
IPv6 Address (Note 1) Optional 6
Unrecognized Parameter Optional 8
Reserved for ECN Capable (Note 2) Optional 32768 (0x8000)
Host Name Address (Note 3) Optional 11
---------
Old text: (Section 3.3.3.1)
---------
Unrecognized Parameters:
Parameter Type Value: 8
パラメータタイプ値：8
Parameter Length: Variable Size.
パラメータの長さ：可変サイズ。
Parameter Value: This parameter is returned to the originator of the INIT chunk when the INIT contains an unrecognized parameter which has a value that indicates that it should be reported to the sender. This parameter value field will contain unrecognized parameters copied from the INIT chunk complete with Parameter Type, Length and Value fields.
Parameter Value: This parameter is returned to the originator of the INIT chunk when the INIT contains an unrecognized parameter which has a value that indicates that it should be reported to the sender. This parameter value field will contain unrecognized parameters copied from the INIT chunk complete with Parameter Type, Length and Value fields.
---------
New text: (Section 3.3.3.1)
---------
Unrecognized Parameter:
Parameter Type Value: 8
Parameter Type Value: 8
Parameter Length: Variable Size.
パラメータの長さ：可変サイズ。
Parameter Value:
Parameter Value:
This parameter is returned to the originator of the INIT chunk when the INIT contains an unrecognized parameter that has a value that indicates that it should be reported to the sender. This parameter value field will contain the unrecognized parameter copied from the INIT chunk complete with Parameter Type, Length, and Value fields.
This parameter is returned to the originator of the INIT chunk when the INIT contains an unrecognized parameter that has a value that indicates that it should be reported to the sender. This parameter value field will contain the unrecognized parameter copied from the INIT chunk complete with Parameter Type, Length, and Value fields.
The new text states clearly that only one unrecognized parameter is reported per parameter.
The new text states clearly that only one unrecognized parameter is reported per parameter.
It is not stated clearly in RFC 2960 [5] how unrecognized parameters should be handled. The problem comes up when an INIT contains an unrecognized parameter with highest bits 00. It was not clear whether an INIT-ACK should be sent.
RFC 2960 [5]には、認識されないパラメーターをどのように処理する必要があるかが明確に記載されていません。この問題は、INITに最上位ビットが00の認識されないパラメータが含まれている場合に発生します。INIT-ACKを送信する必要があるかどうかは明確ではありませんでした。
Some of the changes given here already include changes suggested in Section 2.27 of this document.
ここに示す変更の一部には、このドキュメントのセクション2.27で提案されている変更がすでに含まれています。
---------
Old text: (Section 3.2.1)
---------
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 parameter in an 'Unrecognized Parameter Type' (in either an ERROR or in the INIT ACK).
01-このSCTPパケットの処理を停止して破棄し、その中のそれ以上のチャンクを処理せずに、「認識されないパラメータタイプ」（エラーまたはINIT ACKのいずれか）で認識されないパラメータを報告します。
10 - Skip this parameter and continue processing.
10-このパラメーターをスキップして、処理を続行します。
11 - Skip this parameter and continue processing but report the unrecognized parameter in an 'Unrecognized Parameter Type' (in either an ERROR or in the INIT ACK).
11-このパラメーターをスキップして処理を続行しますが、「認識されないパラメータータイプ」（ERRORまたはINIT ACKのいずれか）で認識されないパラメーターを報告します。
---------
New text: (Section 3.2.1)
---------
00 - Stop processing this parameter; do not process any further parameters within this chunk.
00 - Stop processing this parameter; do not process any further parameters within this chunk.
01 - Stop processing this parameter, do not process any further parameters within this chunk, and report the unrecognized parameter in an 'Unrecognized Parameter Type', as described in 3.2.2.
01-このパラメーターの処理を停止し、このチャンク内でこれ以上パラメーターを処理せず、3.2.2で説明されているように、認識されないパラメーターを「認識されないパラメータータイプ」で報告します。
10 - Skip this parameter and continue processing.
10 - Skip this parameter and continue processing.
11 - Skip this parameter and continue processing but report the unrecognized parameter in an 'Unrecognized Parameter Type', as described in 3.2.2.
11-このパラメーターをスキップして処理を続行しますが、3.2.2で説明されているように、「認識されないパラメータータイプ」で認識されないパラメーターを報告します。
---------
New text: (Note: no old text; clarification added in section 3.2)
---------
3.2.2. Reporting of Unrecognized Parameters
3.2.2. 認識されないパラメータの報告
If the receiver of an INIT chunk detects unrecognized parameters and has to report them according to Section 3.2.1, it MUST put the 'Unrecognized Parameter' parameter(s) in the INIT-ACK chunk sent in response to the INIT-chunk. Note that if the receiver of the INIT chunk is NOT going to establish an association (e.g., due to lack of resources), an 'Unrecognized Parameter' would NOT be included with any ABORT being sent to the sender of the INIT.
INITチャンクのレシーバーが認識されないパラメーターを検出し、セクション3.2.1に従ってそれらを報告する必要がある場合、INITチャンクに応答して送信されるINIT-ACKチャンクに「Unrecognized Parameter」パラメーターを配置する必要があります。 INITチャンクの受信側が関連付けを確立しない場合（リソースの不足など）、「Unrecognized Parameter」は、INITの送信側に送信されるABORTに含まれないことに注意してください。
If the receiver of an INIT-ACK chunk detects unrecognized parameters and has to report them according to Section 3.2.1, it SHOULD bundle the ERROR chunk containing the 'Unrecognized Parameter' error cause with the COOKIE-ECHO chunk sent in response to the INIT-ACK chunk. If the receiver of the INIT-ACK cannot bundle the COOKIE-ECHO chunk with the ERROR chunk, the ERROR chunk MAY be sent separately but not before the COOKIE-ACK has been received.
If the receiver of an INIT-ACK chunk detects unrecognized parameters and has to report them according to Section 3.2.1, it SHOULD bundle the ERROR chunk containing the 'Unrecognized Parameter' error cause with the COOKIE-ECHO chunk sent in response to the INIT-ACK chunk. If the receiver of the INIT-ACK cannot bundle the COOKIE-ECHO chunk with the ERROR chunk, the ERROR chunk MAY be sent separately but not before the COOKIE-ACK has been received.
Note: Any time a COOKIE-ECHO is sent in a packet, it MUST be the first chunk.
注：COOKIE-ECHOがパケットで送信されるときは常に、それが最初のチャンクでなければなりません。
The procedure of handling unrecognized parameters has been described clearly.
認識されないパラメータの処理手順は明確に説明されています。
RFC 2960 requires that Tie-Tags be included in the COOKIE. The cookie may not be encrypted. An attacker could discover the value of the Verification Tags by analyzing cookies received after sending an INIT.
RFC 2960では、タイタグをCOOKIEに含める必要があります。 Cookieが暗号化されていない可能性があります。攻撃者は、INITの送信後に受信したCookieを分析することにより、検証タグの値を発見する可能性があります。
---------
Old text: (Section 1.4)
---------
o Tie-Tags: Verification Tags from a previous association. These
Tags are used within a State Cookie so that the newly
restarting association can be linked to the original
association within the endpoint that did not restart.
---------
New text: (Section 1.4)
---------
o Tie-Tags: Two 32-bit random numbers that together make a 64- bit nonce. These Tags are used within a State Cookie and TCB so that a newly restarting association can be linked to the original association within the endpoint that did not restart and yet not reveal the true Verification Tags of an existing association.
o タイタグ：64ビットのナンスを一緒に作る2つの32ビット乱数。これらのタグは、状態CookieとTCB内で使用されるため、新しく再起動する関連付けは、再起動せず、既存の関連付けの真の検証タグを明らかにしないエンドポイント内の元の関連付けにリンクできます。
---------
Old text: (Section 5.2.1)
---------
For an endpoint that is in the COOKIE-ECHOED state it MUST populate its Tie-Tags with the Tag information of itself and its peer (see Section 5.2.2 for a description of the Tie-Tags).
COOKIE-ECHOED状態のエンドポイントの場合、Tie-Tagに自身とそのピアのタグ情報を設定する必要があります（Tie-Tagの説明については、セクション5.2.2を参照してください）。
---------
New text: (Section 5.2.1)
---------
For an endpoint that is in the COOKIE-ECHOED state it MUST
populate its Tie-Tags within both the association TCB and
inside the State Cookie (see section 5.2.2 for a description
of the Tie-Tags).
---------
Old text: (Section 5.2.2)
---------
Unless otherwise stated, upon reception of an unexpected INIT for
this association, the endpoint shall generate an INIT ACK with a
State Cookie. In the outbound INIT ACK the endpoint MUST copy its
current Verification Tag and peer's Verification Tag into a
reserved place within the state cookie. We shall refer to these
locations as the Peer's-Tie-Tag and the Local-Tie-Tag. The
outbound SCTP packet containing this INIT ACK MUST carry a
Verification Tag value equal to the Initiation Tag found in the
unexpected INIT. And the INIT ACK MUST contain a new Initiation
Tag (randomly generated see Section 5.3.1). Other parameters
for the endpoint SHOULD be copied from the existing parameters
of the association (e.g., number of outbound streams) into the
INIT ACK and cookie.
---------
New text: (Section 5.2.2)
---------
Unless otherwise stated, upon receipt of an unexpected INIT for this association, the endpoint MUST generate an INIT ACK with a State Cookie. In the outbound INIT ACK, the endpoint MUST copy its current Tie-Tags to a reserved place within the State Cookie and the association's TCB. We shall refer to these locations inside the cookie as the Peer's-Tie-Tag and the Local-Tie-Tag. We will refer to the copy within an association's TCB as the Local Tag and Peer's Tag. The outbound SCTP packet containing this INIT ACK MUST carry a Verification Tag value equal to the Initiation Tag found in the unexpected INIT. And the INIT ACK MUST contain a new Initiation Tag (randomly generated; see Section 5.3.1). Other parameters for the endpoint SHOULD be copied from the existing parameters of the association (e.g., number of outbound streams) into the INIT ACK and cookie.
特に明記されていない限り、この関連付けの予期しないINITを受信すると、エンドポイントは状態Cookieを使用してINIT ACKを生成する必要があります。アウトバウンドINIT ACKでは、エンドポイントは、現在のタイタグを状態Cookieと関連付けのTCB内の予約された場所にコピーする必要があります。 Cookie内のこれらの場所を、Peer's-Tie-TagおよびLocal-Tie-Tagと呼びます。協会のTCB内のコピーをローカルタグおよびピアのタグと呼びます。このINIT ACKを含むアウトバウンドSCTPパケットは、予期しないINITで見つかった開始タグに等しい検証タグ値を運ぶ必要があります。また、INIT ACKには新しい開始タグ（ランダムに生成されます。セクション5.3.1を参照）を含める必要があります。エンドポイントのその他のパラメーターは、関連付けの既存のパラメーター（アウトバウンドストリームの数など）からINIT ACKおよびCookieにコピーする必要があります（SHOULD）。
The solution to this problem is not to use the real Verification Tags within the State Cookie as tie-tags. Instead, two 32-bit random numbers are created to form one 64-bit nonce and stored both in the State Cookie and the existing association TCB. This prevents exposing the Verification Tags inadvertently.
この問題の解決策は、状態Cookie内の実際の検証タグをタイタグとして使用しないことです。代わりに、2つの32ビット乱数が作成されて1つの64ビットnonceが形成され、状態Cookieと既存の関連付けTCBの両方に格納されます。これにより、確認タグが誤って公開されるのを防ぎます。
The State Cookie sent by a listening SCTP endpoint may not contain the original port numbers or the local Verification Tag. It is then possible that the endpoint, on receipt of the COOKIE-ECHO, will not be able to verify that these values match the original values found in the INIT and INIT-ACK that began the association setup.
リスニングSCTPエンドポイントによって送信された状態Cookieには、元のポート番号またはローカル検証タグが含まれていない場合があります。エンドポイントは、COOKIE-ECHOを受信すると、これらの値が、関連付けのセットアップを開始したINITおよびINIT-ACKで見つかった元の値と一致することを確認できない可能性があります。
---------
Old text: (Section 5.1.5)
---------
3) Compare the creation timestamp in the State Cookie to the
current local time. If the elapsed time is longer than the
lifespan carried in the State Cookie, then the packet,
including the COOKIE ECHO and any attached DATA chunks,
SHOULD be discarded and the endpoint MUST transmit an ERROR
chunk with a "Stale Cookie" error cause to the peer endpoint,
4) If the State Cookie is valid, create an association to the sender of the COOKIE ECHO chunk with the information in the TCB data carried in the COOKIE ECHO, and enter the ESTABLISHED state,
4）状態Cookieが有効な場合、COOKIE ECHOで伝送されるTCBデータの情報を使用してCOOKIE ECHOチャンクの送信者への関連付けを作成し、ESTABLISHED状態に入ります。
5) Send a COOKIE ACK chunk to the peer acknowledging reception of the COOKIE ECHO. The COOKIE ACK MAY be bundled with an outbound DATA chunk or SACK chunk; however, the COOKIE ACK MUST be the first chunk in the SCTP packet.
5）COOKIEエコーチャンクの受信を確認するピアにCOOKIE ACKチャンクを送信します。 COOKIE ACKは、送信DATAチャンクまたはSACKチャンクにバンドルされる場合があります。ただし、COOKIE ACKはSCTPパケットの最初のチャンクである必要があります。
6) Immediately acknowledge any DATA chunk bundled with the COOKIE ECHO with a SACK (subsequent DATA chunk acknowledgement should follow the rules defined in Section 6.2). As mentioned in step
6）COACKIE ECHOにバンドルされているDATAチャンクをSACKですぐに確認します（後続のDATAチャンクの確認応答は、セクション6.2で定義されたルールに従う必要があります）。ステップで述べたように
5), if the SACK is bundled with the COOKIE ACK, the COOKIE ACK MUST appear first in the SCTP packet.
5）、SACKがCOOKIE ACKにバンドルされている場合、SCTPパケットの最初にCOOKIE ACKが現れる必要があります。
---------
New text: (Section 5.1.5)
---------
3) Compare the port numbers and the Verification Tag contained within the COOKIE ECHO chunk to the actual port numbers and the Verification Tag within the SCTP common header of the received packet. If these values do not match, the packet MUST be silently discarded.
3）COOKIE ECHOチャンク内に含まれるポート番号と検証タグを、受信したパケットのSCTP共通ヘッダー内の実際のポート番号と検証タグと比較します。これらの値が一致しない場合、パケットは静かに破棄されなければなりません（MUST）。
4) Compare the creation timestamp in the State Cookie to the current local time. If the elapsed time is longer than the lifespan carried in the State Cookie, then the packet, including the COOKIE ECHO and any attached DATA chunks, SHOULD be discarded, and the endpoint MUST transmit an ERROR chunk with a "Stale Cookie" error cause to the peer endpoint.
4）状態Cookieの作成タイムスタンプを現在の現地時間と比較します。経過時間がState Cookieで運ばれる寿命よりも長い場合、COOKIE ECHOおよび添付されたDATAチャンクを含むパケットは破棄されるべきであり、エンドポイントは、「古くなったCookie」エラーの原因を含むERRORチャンクを送信する必要があります。ピアエンドポイント。
5) If the State Cookie is valid, create an association to the sender of the COOKIE ECHO chunk with the information in the TCB data carried in the COOKIE ECHO and enter the ESTABLISHED state.
5）状態Cookieが有効な場合、COOKIE ECHOで伝送されるTCBデータの情報を使用してCOOKIE ECHOチャンクの送信者への関連付けを作成し、ESTABLISHED状態に入ります。
6) Send a COOKIE ACK chunk to the peer acknowledging receipt of the COOKIE ECHO. The COOKIE ACK MAY be bundled with an outbound DATA chunk or SACK chunk; however, the COOKIE ACK MUST be the first chunk in the SCTP packet.
6）COOKIEエコーの受信を確認するピアにCOOKIE ACKチャンクを送信します。 COOKIE ACKは、送信DATAチャンクまたはSACKチャンクにバンドルされる場合があります。ただし、COOKIE ACKはSCTPパケットの最初のチャンクである必要があります。
7) Immediately acknowledge any DATA chunk bundled with the COOKIE ECHO with a SACK (subsequent DATA chunk acknowledgement should follow the rules defined in Section 6.2). As mentioned in step 5, if the SACK is bundled with the COOKIE ACK, the COOKIE ACK MUST appear first in the SCTP packet.
7）COOKIE ECHOにバンドルされているDATAチャンクをSACKですぐに確認します（後続のDATAチャンクの確認は、セクション6.2で定義されたルールに従う必要があります）。ステップ5で述べたように、SACKがCOOKIE ACKにバンドルされている場合、COOKIE ACKはSCTPパケットの最初に現れる必要があります。
By including both port numbers and the local Verification Tag within the State Cookie and verifying these during COOKIE-ECHO processing, this issue is resolved.
ポート番号とローカル検証タグの両方を州のCookieに含め、COOKIE-ECHO処理中にこれらを検証することにより、この問題は解決されます。
When an association enters the ESTABLISHED state, the endpoint has no verification that all of the addresses presented by the peer do in fact belong to the peer. This could cause various forms of denial of service attacks.
When an association enters the ESTABLISHED state, the endpoint has no verification that all of the addresses presented by the peer do in fact belong to the peer. This could cause various forms of denial of service attacks.
---------
Old text: None
---------
---------
New text: (Section 5.4)
---------
5.4. Path Verification
During association establishment, the two peers exchange a list of addresses. In the predominant case, these lists accurately represent the addresses owned by each peer. However, it is possible that a misbehaving peer may supply addresses that it does not own. To prevent this, the following rules are applied to all addresses of the new association:
アソシエーションの確立中に、2つのピアはアドレスのリストを交換します。主なケースでは、これらのリストは各ピアが所有するアドレスを正確に表します。ただし、正しく動作しないピアが、自分が所有していないアドレスを提供する可能性があります。これを防ぐために、次のルールが新しい関連付けのすべてのアドレスに適用されます。
1) Any address passed to the sender of the INIT by its upper layer is automatically considered to be CONFIRMED.
1）上位層によってINITの送信側に渡されたアドレスは、自動的にCONFIRMEDと見なされます。
2) For the receiver of the COOKIE-ECHO the only CONFIRMED address is the one that the INIT-ACK was sent to.
2）COOKIE-ECHOの受信側の場合、CONFIRMEDアドレスは、INIT-ACKが送信されたアドレスのみです。
3) All other addresses not covered by rules 1 and 2 are considered UNCONFIRMED and are subject to probing for verification.
3) All other addresses not covered by rules 1 and 2 are considered UNCONFIRMED and are subject to probing for verification.
To probe an address for verification, an endpoint will send HEARTBEATs including a 64-bit random nonce and a path indicator (to identify the address that the HEARTBEAT is sent to) within the HEARTBEAT parameter.
検証のためにアドレスをプローブするために、エンドポイントは、HEARTBEATパラメーター内で64ビットのランダムnonceおよびパスインジケーター（HEARTBEATの送信先アドレスを識別するため）を含むHEARTBEATを送信します。
Upon receipt of the HEARTBEAT-ACK, a verification is made that the nonce included in the HEARTBEAT parameter is the one sent to the address indicated inside the HEARTBEAT parameter. When this match occurs, the address that the original HEARTBEAT was sent to is now considered CONFIRMED and available for normal data transfer.
Upon receipt of the HEARTBEAT-ACK, a verification is made that the nonce included in the HEARTBEAT parameter is the one sent to the address indicated inside the HEARTBEAT parameter. When this match occurs, the address that the original HEARTBEAT was sent to is now considered CONFIRMED and available for normal data transfer.
These probing procedures are started when an association moves to the ESTABLISHED state and are ended when all paths are confirmed.
これらのプロービング手順は、関連付けがESTABLISHED状態に移行したときに開始され、すべてのパスが確認されたときに終了します。
Each RTO a probe may be sent on an active UNCONFIRMED path in an attempt to move it to the CONFIRMED state. If during this probing the path becomes inactive, this rate is lowered to the normal HEARTBEAT rate. At the expiration of the RTO timer, the error counter of any path that was probed but not CONFIRMED is incremented by one and subjected to path failure detection, as defined in section 8.2. When probing UNCONFIRMED addresses, however, the association overall error count is NOT incremented.
プローブをCONFIRMED状態に移動しようとして、アクティブなUNCONFIRMEDパスでプローブが送信される各RTOがあります。このプローブ中にパスが非アクティブになると、このレートは通常のハートビートレートまで低下します。 RTOタイマーの満了時に、セクション8.2で定義されているように、プローブされたがCONFIRMEDでなかったすべてのパスのエラーカウンターが1つインクリメントされ、パス障害検出が行われます。ただし、UNCONFIRMEDアドレスをプローブする場合、アソシエーション全体のエラーカウントは増分されません。
The number of HEARTBEATS sent at each RTO SHOULD be limited by the HB.Max.Burst parameter. It is an implementation decision as to how to distribute HEARTBEATS to the peer's addresses for path verification.
各RTOで送信されるハートビートの数は、HB.Max.Burstパラメーターによって制限されるべきです（SHOULD）。パス検証のためにハートビートをピアのアドレスに配布する方法に関する実装の決定です。
Whenever a path is confirmed, an indication MAY be given to the upper layer.
パスが確認されるときはいつでも、上位層に通知が与えられてもよい（MAY）。
An endpoint MUST NOT send any chunks to an UNCONFIRMED address, with the following exceptions:
エンドポイントは、以下の例外を除き、チャンクをUNCONFIRMEDアドレスに送信してはなりません（MUST NOT）。
- A HEARTBEAT including a nonce MAY be sent to an UNCONFIRMED address.
- nonceを含むHEARTBEATは、UNCONFIRMEDアドレスに送信される場合があります。
- A HEARTBEAT-ACK MAY be sent to an UNCONFIRMED address.
- A HEARTBEAT-ACK MAY be sent to an UNCONFIRMED address.
- A COOKIE-ACK MAY be sent to an UNCONFIRMED address, but it MUST be bundled with a HEARTBEAT including a nonce. An implementation that does NOT support bundling MUST NOT send a COOKIE-ACK to an UNCONFIRMED address.
- COOKIE-ACKは、確認されていないアドレスに送信される場合がありますが、ノンスを含むハートビートにバンドルされている必要があります。バンドリングをサポートしない実装は、COOKIE-ACKをUNCONFIRMEDアドレスに送信してはなりません（MUST NOT）。
- A COOKE-ECHO MAY be sent to an UNCONFIRMED address, but it MUST be bundled with a HEARTBEAT including a nonce, and the packet MUST NOT exceed the path MTU. If the implementation does NOT support bundling or if the bundled COOKIE-ECHO plus HEARTBEAT (including nonce) would exceed the path MTU, then the implementation MUST NOT send a COOKIE-ECHO to an UNCONFIRMED address.
- COOKE-ECHOは、確認されていないアドレスに送信される場合がありますが、ノンスを含むハートビートにバンドルされている必要があり、パケットはパスMTUを超えてはなりません。実装がバンドルをサポートしていない場合、またはバンドルされたCOOKIE-ECHOとHEARTBEAT（nonceを含む）がパスMTUを超える場合、実装はCOOKIE-ECHOをUNCONFIRMEDアドレスに送信してはなりません（MUST NOT）。
---------
Old text: (Section 14)
---------
14. Suggested SCTP Protocol Parameter Values
14. SCTPプロトコルパラメータの推奨値
The following protocol parameters are RECOMMENDED: RTO.Initial - 3 seconds RTO.Min - 1 second RTO.Max - 60 seconds 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
次のプロトコルパラメータが推奨されます：RTO.Initial-3秒RTO.Min-1秒RTO.Max-60秒RTO.Alpha-1/8 RTO.Beta-1/4 Valid.Cookie.Life-60秒Association.Max .Retrans-10回の試行Path.Max.Retrans-5回の試行（宛先アドレスごと）Max.Init.Retransmits-8回の試行HB.interval-30秒
---------
New text: (Section 14)
---------
14. Suggested SCTP Protocol Parameter Values
14. SCTPプロトコルパラメータの推奨値
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
By properly setting up initial path state and accelerated probing via HEARTBEAT's, a new association can verify that all addresses presented by a peer belong to that peer.
HEARTBEATを介して初期パス状態と加速プローブを適切に設定することにより、新しい関連付けは、ピアによって提示されたすべてのアドレスがそのピアに属していることを確認できます。
RFC 2960 does not describe how ICMP messages should be processed by an SCTP endpoint.
RFC 2960 does not describe how ICMP messages should be processed by an SCTP endpoint.
--------
Old text: None
--------
---------
New text
---------
11.5. Protection of Non-SCTP Capable Hosts.
11.5. Protection of Non-SCTP Capable Hosts.
To provide a non-SCTP capable host with the same level of protection against attacks as for SCTP-capable ones, all SCTP stacks MUST implement the ICMP handling described in Appendix C.
SCTP非対応ホストに、SCTP対応ホストと同じレベルの攻撃に対する保護を提供するには、すべてのSCTPスタックが、付録Cで説明されているICMP処理を実装する必要があります。
When an SCTP stack receives a packet containing multiple control or DATA chunks and the processing of the packet requires the sending of multiple chunks in response, the sender of the response chunk(s) MUST NOT send more than one packet. If bundling is supported, multiple response chunks that fit into a single packet MAY be bundled together into one single response packet. If bundling is not supported, then the sender MUST NOT send more than one response chunk and MUST discard all other responses. Note that this rule does NOT apply to a SACK chunk, since a SACK chunk is, in itself, a response to DATA and a SACK does not require a response of more DATA.
When an SCTP stack receives a packet containing multiple control or DATA chunks and the processing of the packet requires the sending of multiple chunks in response, the sender of the response chunk(s) MUST NOT send more than one packet. If bundling is supported, multiple response chunks that fit into a single packet MAY be bundled together into one single response packet. If bundling is not supported, then the sender MUST NOT send more than one response chunk and MUST discard all other responses. Note that this rule does NOT apply to a SACK chunk, since a SACK chunk is, in itself, a response to DATA and a SACK does not require a response of more DATA.
An SCTP implementation SHOULD abort the association if it receives a SACK acknowledging a TSN that has not been sent.
SCTP実装は、送信されていないTSNを確認するSACKを受信した場合、関連付けを中止する必要があります（SHOULD）。
An SCTP implementation that receives an INIT that would require a large packet in response, due to the inclusion of multiple ERROR parameters, MAY (at its discretion) elect to omit some or all of the ERROR parameters to reduce the size of the INIT-ACK. Due to a combination of the size of the COOKIE parameter and the number of addresses a receiver of an INIT may be indicating to a peer, it is always possible that the INIT-ACK will be larger than the original INIT. An SCTP implementation SHOULD attempt to make the INIT-ACK as small as possible to reduce the possibility of byte amplification attacks.
An SCTP implementation that receives an INIT that would require a large packet in response, due to the inclusion of multiple ERROR parameters, MAY (at its discretion) elect to omit some or all of the ERROR parameters to reduce the size of the INIT-ACK. Due to a combination of the size of the COOKIE parameter and the number of addresses a receiver of an INIT may be indicating to a peer, it is always possible that the INIT-ACK will be larger than the original INIT. An SCTP implementation SHOULD attempt to make the INIT-ACK as small as possible to reduce the possibility of byte amplification attacks.
---------
Old text: None
---------
---------
New text: (Appendix C)
---------
Appendix C ICMP Handling
付録C ICMP処理
Whenever an ICMP message is received by an SCTP endpoint the following procedures MUST be followed to ensure proper utilization of the information being provided by layer 3.
ICMPメッセージがSCTPエンドポイントによって受信されるときは常に、レイヤー3によって提供される情報の適切な利用を確実にするために、次の手順に従う必要があります。
ICMP1) An implementation MAY ignore all ICMPv4 messages where the type field is not set to "Destination Unreachable".
ICMP1）実装は、typeフィールドが "Destination Unreachable"に設定されていないすべてのICMPv4メッセージを無視してもよい（MAY）。
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）。
ICMP3) An implementation MAY ignore any ICMPv4 messages where the code does not indicate "Protocol Unreachable" or "Fragmentation Needed".
ICMP3）コードが「プロトコル到達不能」または「フラグメンテーションが必要」を示さない場合、実装はICMPv4メッセージを無視してもよい（MAY）。
ICMP4) An implementation MAY ignore all ICMPv6 messages of type "Parameter Problem" if the code is not "Unrecognized next header type encountered".
ICMP4）コードが「認識できない次のヘッダータイプが検出された」でない場合、実装はタイプ「パラメーターの問題」のすべてのICMPv6メッセージを無視してもよい（MAY）。
ICMP5) An implementation MUST use the payload of the ICMP message (V4 or V6) to locate the association that sent the message that ICMP is responding to. If the association cannot be found, an implementation SHOULD ignore the ICMP message.
ICMP5）実装は、ICMPメッセージ（V4またはV6）のペイロードを使用して、ICMPが応答しているメッセージを送信した関連付けを特定する必要があります。関連付けが見つからない場合、実装はICMPメッセージを無視する必要があります（SHOULD）。
ICMP6) An implementation MUST validate that the Verification Tag contained in the ICMP message matches the verification tag of the peer. If the Verification Tag is not 0 and does NOT match, discard the ICMP message. If it is 0 and the ICMP message contains enough bytes to verify that the chunk type is an INIT chunk and that the initiate tag matches the tag of the peer, continue with ICMP7. If the ICMP message is too short or the chunk type or the initiate tag does not match, silently discard the packet.
ICMP6）実装は、ICMPメッセージに含まれる検証タグがピアの検証タグと一致することを検証する必要があります。検証タグが0ではなく、一致しない場合は、ICMPメッセージを破棄します。それが0で、ICMPメッセージに十分なバイトが含まれていて、チャンクタイプがINITチャンクであり、開始タグがピアのタグと一致していることを確認する場合は、ICMP7に進みます。 ICMPメッセージが短すぎるか、チャンクのタイプまたは開始タグが一致しない場合は、静かにパケットを破棄します。
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）。
ICMP8) If the ICMP code is a "Unrecognized next header type encountered" or a "Protocol Unreachable", an implementation MUST treat this message as an abort with the T bit set if it does not contain an INIT chunk. If it does contain an INIT chunk and the association is in COOKIE-WAIT state, handle the ICMP message like an ABORT.
ICMP8) If the ICMP code is a "Unrecognized next header type encountered" or a "Protocol Unreachable", an implementation MUST treat this message as an abort with the T bit set if it does not contain an INIT chunk. If it does contain an INIT chunk and the association is in COOKIE-WAIT state, handle the ICMP message like an ABORT.
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）。
Note that these procedures differ from RFC 1122 [1] and from its requirements for processing of port-unreachable messages and the requirements that an implementation MUST abort associations in response to a "protocol unreachable" message. Port unreachable messages are not processed, since an implementation will send an ABORT, not a port unreachable. The stricter handling of the "protocol unreachable" message is due to security concerns for hosts that do NOT support SCTP.
Note that these procedures differ from RFC 1122 [1] and from its requirements for processing of port-unreachable messages and the requirements that an implementation MUST abort associations in response to a "protocol unreachable" message. Port unreachable messages are not processed, since an implementation will send an ABORT, not a port unreachable. The stricter handling of the "protocol unreachable" message is due to security concerns for hosts that do NOT support SCTP.
The new appendix now describes proper handling of ICMP messages in conjunction with SCTP.
新しい付録では、SCTPと連動したICMPメッセージの適切な処理について説明します。
RFC 3309 [6] changes the SCTP checksum due to weaknesses in the original Adler 32 checksum for small messages. This document, being used as a guide for a cut and paste replacement to update RFC 2960, thus also needs to incorporate the checksum changes. The idea is that one could apply all changes found in this guide to a copy of RFC 2960 and have a "new" document that has ALL changes (including RFC 3309).
RFC 3309 [6]は、小さなメッセージに対する元のAdler 32チェックサムの弱点のため、SCTPチェックサムを変更します。このドキュメントは、RFC 2960を更新するためのカットアンドペースト置換のガイドとして使用されているため、チェックサムの変更を組み込む必要もあります。このガイドで見つかったすべての変更をRFC 2960のコピーに適用し、すべての変更（RFC 3309を含む）を含む「新しい」ドキュメントを作成できるという考え方です。
---------
Old text:
---------
6.8 Adler-32 Checksum Calculation
6.8 Adler-32チェックサム計算
When sending an SCTP packet, the endpoint MUST strengthen the data integrity of the transmission by including the Adler-32 checksum value calculated on the packet, as described below.
SCTPパケットを送信する場合、エンドポイントは、以下で説明するように、パケットで計算されたAdler-32チェックサム値を含めることにより、送信のデータ整合性を強化する必要があります。
After the packet is constructed (containing the SCTP common header and one or more control or DATA chunks), the transmitter shall: 1) Fill in the proper Verification Tag in the SCTP common header and initialize the checksum field to 0's.
パケットが構築された後（SCTP共通ヘッダーと1つ以上の制御またはDATAチャンクを含む）、送信機は次のことを行います。1）SCTP共通ヘッダーに適切な検証タグを入力し、チェックサムフィールドを0に初期化します。
2) Calculate the Adler-32 checksum of the whole packet, including the SCTP common header and all the chunks. Refer to appendix B for details of the Adler-32 algorithm. And,
2）SCTP共通ヘッダーとすべてのチャンクを含む、パケット全体のAdler-32チェックサムを計算します。 Adler-32アルゴリズムの詳細については、付録Bを参照してください。そして、
3) Put the resultant value into the checksum field in the common header, and leave the rest of the bits unchanged.
3) Put the resultant value into the checksum field in the common header, and leave the rest of the bits unchanged.
When an SCTP packet is received, the receiver MUST first check the Adler-32 checksum:
SCTPパケットを受信すると、受信者は最初にAdler-32チェックサムを確認する必要があります。
1) Store the received Adler-32 checksum value aside,
1）受信したAdler-32チェックサム値を脇に保存し、
2) Replace the 32 bits of the checksum field in the received SCTP packet with all '0's and calculate an Adler-32 checksum value of the whole received packet. And,
2）受信したSCTPパケットのチェックサムフィールドの32ビットをすべて0に置き換え、受信したパケット全体のAdler-32チェックサム値を計算します。そして、
3) Verify that the calculated Adler-32 checksum is the same as the received Adler-32 checksum. If not, the receiver MUST treat the packet as an invalid SCTP packet.
3）計算されたAdler-32チェックサムが受信したAdler-32チェックサムと同じであることを確認します。そうでない場合、受信者はパケットを無効なSCTPパケットとして扱わなければなりません（MUST）。
The default procedure for handling invalid SCTP packets is to silently discard them.
無効なSCTPパケットを処理するためのデフォルトの手順は、それらをサイレントに破棄することです。
---------
New text:
---------
6.8 CRC-32c Checksum Calculation
6.8 CRC-32cチェックサム計算
When sending an SCTP packet, the endpoint MUST strengthen the data integrity of the transmission by including the CRC32c checksum value calculated on the packet, as described below.
SCTPパケットを送信する場合、エンドポイントは、以下で説明するように、パケットで計算されたCRC32cチェックサム値を含めることにより、送信のデータ整合性を強化する必要があります。
After the packet is constructed (containing the SCTP common header and one or more control or DATA chunks), the transmitter MUST
パケットが構築された後（SCTP共通ヘッダーと1つ以上の制御またはデータチャンクを含む）、送信機は
1) fill in the proper Verification Tag in the SCTP common header and initialize the checksum field to '0's,
1）SCTP共通ヘッダーに適切な検証タグを入力し、チェックサムフィールドを「0」に初期化します。
2) calculate the CRC32c checksum of the whole packet, including the SCTP common header and all the chunks (refer to appendix B for details of the CRC32c algorithm); and
2）SCTP共通ヘッダーとすべてのチャンクを含む、パケット全体のCRC32cチェックサムを計算します（CRC32cアルゴリズムの詳細については、付録Bを参照してください）。そして
3) put the resultant value into the checksum field in the common header, and leave the rest of the bits unchanged.
3）結果の値を共通ヘッダーのチェックサムフィールドに入力し、残りのビットは変更しません。
When an SCTP packet is received, the receiver MUST first check the CRC32c checksum as follows:
SCTPパケットを受信すると、受信者はまず次のようにCRC32cチェックサムを確認する必要があります。
1) Store the received CRC32c checksum value aside.
1）受信したCRC32cチェックサム値を保存します。
2) Replace the 32 bits of the checksum field in the received SCTP packet with all '0's and calculate a CRC32c checksum value of the whole received packet.
2）受信したSCTPパケットのチェックサムフィールドの32ビットをすべて「0」に置き換え、受信したパケット全体のCRC32cチェックサム値を計算します。
3) Verify that the calculated CRC32c checksum is the same as the received CRC32c checksum. If it is not, the receiver MUST treat the packet as an invalid SCTP packet.
3）計算されたCRC32cチェックサムが受信したCRC32cチェックサムと同じであることを確認します。そうでない場合、受信者はパケットを無効なSCTPパケットとして扱わなければなりません（MUST）。
The default procedure for handling invalid SCTP packets is to silently discard them.
無効なSCTPパケットを処理するためのデフォルトの手順は、それらをサイレントに破棄することです。
Any hardware implementation SHOULD be done in a way that is verifiable by the software.
ハードウェアの実装は、ソフトウェアで検証可能な方法で行う必要があります。
---------
Old text:
---------
Appendix B Alder 32 bit checksum calculation
付録B Alder 32ビットチェックサムの計算
The Adler-32 checksum calculation given in this appendix is copied from [RFC1950].
この付録で提供されているAdler-32チェックサム計算は、[RFC1950]からコピーされています。
Adler-32 is composed of two sums accumulated per byte: s1 is the sum of all bytes, s2 is the sum of all s1 values. Both sums are done modulo 65521. s1 is initialized to 1, s2 to zero. The Adler-32 checksum is stored as s2*65536 + s1 in network byte order.
Adler-32は、バイトごとに累積された2つの合計で構成されています。s1はすべてのバイトの合計、s2はすべてのs1値の合計です。両方の合計は65521を法として行われます。s1は1に初期化され、s2はゼロに初期化されます。 Adler-32チェックサムは、ネットワークバイトオーダーでs2 * 65536 + s1として保存されます。
The following C code computes the Adler-32 checksum of a data buffer. It is written for clarity, not for speed. The sample code is in the ANSI C programming language. Non C users may find it easier to read with these hints:
次のCコードは、データバッファーのAdler-32チェックサムを計算します。速度を上げるためではなく、明確にするために書かれています。サンプルコードはANSI Cプログラミング言語です。 C以外のユーザーは、次のヒントを読むと読みやすくなります。
& Bitwise AND operator. >> Bitwise right shift operator. When applied to an unsigned quantity, as here, right shift inserts zero bit(s) at the left. << Bitwise left shift operator. Left shift inserts zero bit(s) at the right. ++ "n++" increments the variable n. % modulo operator: a % b is the remainder of a divided by b.
＆ビットごとのAND演算子。 >>ビット単位の右シフト演算子。このように、符号なしの数量に適用すると、右シフトは左側にゼロビットを挿入します。 <<ビット単位の左シフト演算子。左シフトは、右側にゼロビットを挿入します。 ++ "n ++"は変数nをインクリメントします。 ％モジュロ演算子：a％bは、bで割った余りです。
#define BASE 65521 /* largest prime smaller than 65536 */
/*
Update a running Adler-32 checksum with the bytes buf[0..len-1]
and return the updated checksum. The Adler-32 checksum should
be initialized to 1.
Usage example:
使用例：
unsigned long adler = 1L;
unsigned long adler = 1L;
while (read_buffer(buffer, length) != EOF) {
adler = update_adler32(adler, buffer, length);
}
if (adler != original_adler) error();
*/
unsigned long update_adler32(unsigned long adler,
unsigned char *buf, int len)
{
unsigned long s1 = adler & 0xffff;
unsigned long s2 = (adler >> 16) & 0xffff;
int n;
for (n = 0; n < len; n++) {
s1 = (s1 + buf[n]) % BASE;
s2 = (s2 + s1) % BASE;
}
return (s2 << 16) + s1;
}
/* Return the adler32 of the bytes buf[0..len-1] */
unsigned long adler32(unsigned char *buf, int len)
{
return update_adler32(1L, buf, len);
}
---------
New text:
---------
Appendix B CRC32c Checksum Calculation
付録B CRC32cチェックサムの計算
We define a 'reflected value' as one that is the opposite of the normal bit order of the machine. The 32-bit CRC is calculated as described for CRC-32c and uses the polynomial code 0x11EDC6F41 (Castagnoli93) or x^32+x^28+x^27+x^26+x^25 +x^23+x^22+x^20+x^19+x^18+x^14+x^13+x^11+x^10+x^9+x^8+x^6+x^0. The CRC is computed using a procedure similar to ETHERNET CRC [ITU32], modified to reflect transport level usage.
「反映された値」を、マシンの通常のビット順序とは逆の値として定義します。 32ビットCRCはCRC-32cの説明に従って計算され、多項式コード0x11EDC6F41（Castagnoli93）またはx ^ 32 + x ^ 28 + x ^ 27 + x ^ 26 + x ^ 25 + x ^ 23 + x ^ 22を使用します+ x ^ 20 + x ^ 19 + x ^ 18 + x ^ 14 + x ^ 13 + x ^ 11 + x ^ 10 + x ^ 9 + x ^ 8 + x ^ 6 + x ^ 0。 CRCは、トランスポートレベルの使用を反映するように変更された、ETHERNET CRC [ITU32]と同様の手順を使用して計算されます。
CRC computation uses polynomial division. A message bit-string M is transformed to a polynomial, M(X), and the CRC is calculated from M(X) using polynomial arithmetic [PETERSON 72].
CRC計算は多項式除算を使用します。メッセージのビット文字列Mは多項式M（X）に変換され、CRCは多項式演算を使用してM（X）から計算されます[PETERSON 72]。
When CRCs are used at the link layer, the polynomial is derived from on-the-wire bit ordering: the first bit 'on the wire' is the high-order coefficient. Since SCTP is a transport-level protocol, it cannot know the actual serial-media bit ordering. Moreover, different links in the path between SCTP endpoints may use different link-level bit orders.
CRCがリンク層で使用される場合、多項式はオンザワイヤーのビット順序から導出されます。「ワイヤー上の」最初のビットは高次係数です。 SCTPはトランスポートレベルのプロトコルであるため、実際のシリアルメディアのビット順序を知ることはできません。さらに、SCTPエンドポイント間のパス内の異なるリンクは、異なるリンクレベルのビットオーダーを使用する場合があります。
A convention must therefore be established for mapping SCTP transport messages to polynomials for purposes of CRC computation. The bit-ordering for mapping SCTP messages to polynomials is that bytes are taken most-significant first; but within each byte, bits are taken least-significant first. The first byte of the message provides the eight highest coefficients. Within each byte, the least-significant SCTP bit gives the most significant polynomial coefficient within that byte, and the most-significant SCTP bit is the least significant polynomial coefficient in that byte. (This bit ordering is sometimes called 'mirrored' or 'reflected' [WILLIAMS93].) CRC polynomials are to be transformed back into SCTP transport-level byte values, using a consistent mapping.
したがって、CRC計算のためにSCTPトランスポートメッセージを多項式にマッピングするための規則を確立する必要があります。 SCTPメッセージを多項式にマッピングするためのビット順序は、バイトが最初に最も重要であると解釈されます。ただし、各バイト内では、ビットは最初に最下位として解釈されます。メッセージの最初のバイトは、8つの最も高い係数を提供します。各バイト内で、最下位のSCTPビットはそのバイト内の最上位の多項式係数を示し、最上位のSCTPビットはそのバイトの最下位の多項式係数です。 （このビット順序は、「ミラーリング」または「反射」と呼ばれることもあります。[WILLIAMS93]）CRC多項式は、一貫したマッピングを使用して、SCTPトランスポートレベルのバイト値に変換されます。
The SCTP transport-level CRC value should be calculated as follows:
SCTPトランスポートレベルのCRC値は、次のように計算する必要があります。
- CRC input data are assigned to a byte stream, numbered from 0 to N-1.
- CRC入力データは、0からN-1までの番号が付けられたバイトストリームに割り当てられます。
- The transport-level byte-stream is mapped to a polynomial value. An N-byte PDU with j bytes numbered 0 to N-1 is considered as coefficients of a polynomial M(x) of order 8N-1, with bit 0 of byte j being coefficient x^(8(N-j)-8), and bit 7 of byte j being coefficient x^(8(N-j)-1).
- トランスポートレベルのバイトストリームは、多項式値にマップされます。 0からN-1の番号が付けられたjバイトのNバイトPDUは、次数8N-1の多項式M（x）の係数と見なされます。バイトjのビット0は係数x ^（8（Nj）-8）です。バイトjのビット7は係数x ^（8（Nj）-1）です。
- The CRC remainder register is initialized with all 1s and the CRC is computed with an algorithm that simultaneously multiplies by x^32 and divides by the CRC polynomial.
- CRC剰余レジスタはすべて1で初期化され、CRCは同時にx ^ 32を乗算してCRC多項式で除算するアルゴリズムで計算されます。
- The polynomial is multiplied by x^32 and divided by G(x), the generator polynomial, producing a remainder R(x) of degree less than or equal to 31.
- 多項式はx ^ 32で乗算され、生成多項式であるG（x）で除算され、31以下の次数の剰余R（x）を生成します。
- The coefficients of R(x) are considered a 32-bit sequence.
- R（x）の係数は32ビットシーケンスと見なされます。
- The bit sequence is complemented. The result is the CRC polynomial.
- ビットシーケンスは補完されます。結果はCRC多項式です。
- The CRC polynomial is mapped back into SCTP transport-level bytes. The coefficient of x^31 gives the value of bit 7 of SCTP byte 0, and the coefficient of x^24 gives the value of bit 0 of byte 0. The coefficient of x^7 gives bit 7 of byte 3, and the coefficient of x^0 gives bit 0 of byte 3. The resulting four-byte transport-level sequence is the 32-bit SCTP checksum value.
- CRC多項式は、SCTPトランスポートレベルのバイトにマッピングされます。係数x ^ 31はSCTPバイト0のビット7の値を与え、x ^ 24の係数はバイト0のビット0の値を与えます。x^ 7の係数はバイト3のビット7を与え、係数x ^ 0のバイト3のビット0が得られます。結果の4バイトのトランスポートレベルシーケンスは、32ビットのSCTPチェックサム値です。
IMPLEMENTATION NOTE: Standards documents, textbooks, and vendor literature on CRCs often follow an alternative formulation, in which the register used to hold the remainder of the long-division algorithm is initialized to zero rather than all-1s, and instead the first 32 bits of the message are complemented. The long-division algorithm used in our formulation is specified such that the initial multiplication by 2^32 and the long-division are combined into one simultaneous operation. For such algorithms, and for messages longer than 64 bits, the two specifications are precisely equivalent. That equivalence is the intent of this document.
実装に関する注記：CRCに関する標準文書、教科書、およびベンダーの資料は、多くの場合、代替の定式化に従います。この場合、長分割アルゴリズムの残りの部分を保持するために使用されるレジスタは、すべて1ではなくゼロに初期化され、代わりに最初の32ビットが初期化されます。メッセージの補足されます。この定式化で使用される長除算アルゴリズムは、2 ^ 32による初期乗算と長除算が1つの同時演算に結合されるように指定されています。このようなアルゴリズム、および64ビットより長いメッセージの場合、2つの仕様はまったく同じです。この同等性は、このドキュメントの目的です。
Implementors of SCTP are warned that both specifications are to be found in the literature, sometimes with no restriction on the long-division algorithm. The choice of formulation in this document is to permit non-SCTP usage, where the same CRC algorithm may be used to protect messages shorter than 64 bits.
SCTPの実装者は、両方の仕様が文献に記載されており、場合によっては長分割アルゴリズムに制限がないことを警告しています。このドキュメントの定式化の選択は、SCTP以外の使用を許可することです。この場合、同じCRCアルゴリズムを使用して、64ビットより短いメッセージを保護できます。
There may be a computational advantage in validating the Association against the Verification Tag, prior to performing a checksum, as invalid tags will result in the same action as a bad checksum in most cases. The exceptions for this technique would be INIT and some SHUTDOWN-COMPLETE exchanges, as well as a stale COOKIE-ECHO. These special case exchanges must represent small packets and will minimize the effect of the checksum calculation.
チェックサムを実行する前に、検証タグに対してアソシエーションを検証することには、計算上の利点があります。無効なタグは、ほとんどの場合、不正なチェックサムと同じアクションになるためです。この手法の例外は、INITと一部のSHUTDOWN-COMPLETE交換、および古いCOOKIE-ECHOです。これらの特別な場合の交換は小さなパケットを表す必要があり、チェックサム計算の影響を最小限に抑えます。
---------
Old text: (Section 18)
---------
18. Bibliography
18. 参考文献
[ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End Network Path Properties", Proc. SIGCOMM'99, 1999.
[ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End Network Path Properties", Proc. SIGCOMM'99, 1999.
[FALL96] Fall, K. and Floyd, S., Simulation-based Comparisons of Tahoe, Reno, and SACK TCP, Computer Communications Review, V. 26 N. 3, July 1996, pp. 5-21.
[FALL96]秋、K。およびフロイド、S。、シミュレーションに基づくタホ、リノ、およびSACK TCPの比較、コンピュータ通信レビュー、V。26 N. 3、1996年7月、pp。5-21。
[RFC1750] Eastlake, D. (ed.), "Randomness Recommendations for Security", RFC 1750, December 1994.
[RFC1750] Eastlake、D.（ed。）、「Randomness Recommendations for Security」、RFC 1750、1994年12月。
[RFC1950] Deutsch P. and J. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996.
[RFC1950] Deutsch P.およびJ. Gailly、「ZLIB Compressed Data Format Specification version 3.3」、RFC 1950、1996年5月。
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, March 1997.
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, March 1997.
[RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, September 1997.
[RFC2196] Fraser、B。、「Site Security Handbook」、FYI 8、RFC 2196、1997年9月。
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management Protocol", RFC 2522, March 1999.
[RFC2522] Karn、P。およびW. Simpson、「Photuris：Session-Key Management Protocol」、RFC 2522、1999年3月。
[SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T., "TCP Congestion Control with a Misbehaving Receiver", ACM Computer Communication Review, 29(5), October 1999.
[SAVAGE99] Savage、S.、Cardwell、N.、Wetherall、D。、およびAnderson、T。、「誤動作レシーバーによるTCP輻輳制御」、ACM Computer Communication Review、29（5）、1999年10月。
---------
New text: (Section 18, including changes from 2.11)
---------
18. Bibliography
18. 参考文献
[ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End Network Path Properties", Proc. SIGCOMM'99, 1999.
[ALLMAN99] Allman、M。およびPaxson、V。、「End-to-End Network Path Propertiesの推定について」、Proc。 SIGCOMM'99、1999。
[FALL96] Fall, K. and Floyd, S., Simulation-based Comparisons of Tahoe, Reno, and SACK TCP, Computer Communications Review, V. 26 N. 3, July 1996, pp. 5-21.
[FALL96]秋、K。およびフロイド、S。、シミュレーションに基づくタホ、リノ、およびSACK TCPの比較、コンピュータ通信レビュー、V。26 N. 3、1996年7月、pp。5-21。
[ITU32] ITU-T Recommendation V.42, "Error-correcting procedures for DCEs using asynchronous-to-synchronous conversion", Section 8.1.1.6.2, October 1996.
[ITU32] ITU-T勧告V.42、「非同期から同期への変換を使用したDCEのエラー修正手順」、セクション8.1.1.6.2、1996年10月。
[PETERSON 1972] W. W. Peterson and E.J Weldon, Error Correcting Codes, 2nd Edition, MIT Press, Cambridge, Massachusetts.
[PETERSON 1972] W. W.ピーターソンとE.Jウェルドン、エラー修正コード、第2版、MIT Press、ケンブリッジ、マサチューセッツ。
[RFC1750] Eastlake, D., Ed., "Randomness Recommendations for Security", RFC 1750, December 1994.
[RFC1750] Eastlake、D.、Ed。、「Randomness Recommendations for Security」、RFC 1750、1994年12月。
[RFC1858] Ziemba, G., Reed, D. and Traina P., "Security Considerations for IP Fragment Filtering", RFC 1858, October 1995.
[RFC1858] Ziemba、G.、Reed、D。、およびTraina P。、「IPフラグメントフィルタリングのセキュリティに関する考慮事項」、RFC 1858、1995年10月。
[RFC1950] Deutsch P. and J. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996.
[RFC1950] Deutsch P. and J. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996.
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, March 1997.
[RFC2104] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：Keyed-Hashing for Message Authentication」、RFC 2104、1997年3月。
[RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, September 1997.
[RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, September 1997.
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management Protocol", RFC 2522, March 1999.
[RFC2522] Karn、P。およびW. Simpson、「Photuris：Session-Key Management Protocol」、RFC 2522、1999年3月。
[SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T., "TCP Congestion Control with a Misbehaving Receiver", ACM Computer Communication Review, 29(5), October 1999.
[SAVAGE99] Savage、S.、Cardwell、N.、Wetherall、D。、およびAnderson、T。、「誤動作レシーバーによるTCP輻輳制御」、ACM Computer Communication Review、29（5）、1999年10月。
[WILLIAMS93] Williams, R., "A PAINLESS GUIDE TO CRC ERROR DETECTION ALGORITHMS" - Internet publication, August 1993, http://www.geocities.com/SiliconValley/Pines/ 8659/crc.htm.
[WILLIAMS93]ウィリアムズR。、「CRCエラー検出アルゴリズムの無痛ガイド」-1993年8月のインターネット出版、http：//www.geocities.com/SiliconValley/Pines/ 8659 / crc.htm。
This change adds to the implementor's guide the complete set of changes that, when combined with RFC 2960 [5], encompasses the changes from RFC 3309 [6].
この変更により、RFC 2960 [5]と組み合わせると、RFC 3309 [6]からの変更が含まれる完全な一連の変更が実装者ガイドに追加されます。
The current retransmission policy (send all retransmissions an alternate destination) in the specification has performance issues under certain loss conditions with multihomed endpoints. Instead, fast retransmissions should be sent to the same destination, and only timeout retransmissions should be sent to an alternate destination [4].
仕様の現在の再送信ポリシー（すべての再送信を代替の宛先に送信する）には、マルチホームエンドポイントの特定の損失条件でパフォーマンスの問題があります。代わりに、高速再送信は同じ宛先に送信する必要があり、タイムアウト再送信のみを代替宛先に送信する必要があります[4]。
---------
Old text: (Section 6.4)
---------
Furthermore, when its peer is multi-homed, an endpoint SHOULD try to retransmit a chunk 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）。
---------
Old text: (Section 6.4.1)
---------
When retransmitting data, if the endpoint is multi-homed, it should consider each source-destination address pair in its retransmission selection policy. When retransmitting the endpoint should attempt to pick the most divergent source-destination pair from the original source-destination pair to which the packet was transmitted.
データを再送信するとき、エンドポイントがマルチホームの場合、再送信選択ポリシーで送信元と宛先の各ペアを考慮する必要があります。エンドポイントは、再送信時に、パケットが送信された元の送信元と宛先のペアから、最も異なる送信元と宛先のペアを選択する必要があります。
---------
New text: (Section 6.4.1)
---------
When retransmitting data that timed out, if the endpoint is multi-homed, it should consider each source-destination address pair in its retransmission selection policy. When retransmitting timed out data, the endpoint should attempt to pick the most divergent source-destination pair from the original source-destination pair to which the packet was transmitted.
タイムアウトしたデータを再送信するとき、エンドポイントがマルチホームの場合、再送信選択ポリシーで送信元と宛先の各ペアを考慮する必要があります。タイムアウトしたデータを再送信する場合、エンドポイントは、パケットが送信された元の送信元と宛先のペアから、最も異なる送信元と宛先のペアを選択する必要があります。
The above wording changes clarify that only timeout retransmissions should be sent to an alternate active destination.
上記の文言の変更により、タイムアウトの再送信のみを代替のアクティブな宛先に送信する必要があることが明確になりました。
The port number 0 has a special semantic in various APIs. For example, in the socket API, if the user specifies 0, the SCTP implementation chooses an appropriate port number for the user. Therefore, the port number 0 should not be used on the wire.
ポート番号0には、さまざまなAPIで特別な意味があります。たとえば、ソケットAPIでは、ユーザーが0を指定した場合、SCTP実装はユーザーに適切なポート番号を選択します。したがって、ポート番号0をワイヤで使用しないでください。
---------
Old text: (Section 3.1)
---------
Source Port Number: 16 bits (unsigned integer)
送信元ポート番号：16ビット（符号なし整数）
This is the SCTP sender's port number. It can be used by the receiver in combination with the source IP address, the SCTP destination port, and possibly the destination IP address to identify the association to which this packet belongs.
これはSCTP送信者のポート番号です。これは、送信元IPアドレス、SCTP宛先ポート、および場合によっては宛先IPアドレスと組み合わせて、このパケットが属するアソシエーションを識別するために受信者が使用できます。
Destination Port Number: 16 bits (unsigned integer)
Destination Port Number: 16 bits (unsigned integer)
This is the SCTP port number to which this packet is destined. The receiving host will use this port number to de-multiplex the SCTP packet to the correct receiving endpoint/application.
これは、このパケットの宛先であるSCTPポート番号です。受信ホストはこのポート番号を使用して、SCTPパケットを正しい受信エンドポイント/アプリケーションに逆多重化します。
---------
New text: (Section 3.1)
---------
Source Port Number: 16 bits (unsigned integer)
送信元ポート番号：16ビット（符号なし整数）
This is the SCTP sender's port number. It can be used by the receiver in combination with the source IP address, the SCTP destination port and possibly the destination IP address to identify the association to which this packet belongs. The port number 0 MUST NOT be used.
This is the SCTP sender's port number. It can be used by the receiver in combination with the source IP address, the SCTP destination port and possibly the destination IP address to identify the association to which this packet belongs. The port number 0 MUST NOT be used.
Destination Port Number: 16 bits (unsigned integer)
宛先ポート番号：16ビット（符号なし整数）
This is the SCTP port number to which this packet is destined. The receiving host will use this port number to de-multiplex the SCTP packet to the correct receiving endpoint/application. The port number 0 MUST NOT be used.
これは、このパケットの宛先であるSCTPポート番号です。受信ホストはこのポート番号を使用して、SCTPパケットを正しい受信エンドポイント/アプリケーションに逆多重化します。ポート番号0は使用してはなりません。
It is clearly stated that the port number 0 is an invalid value on the wire.
ポート番号0は、ワイヤでは無効な値であることが明確に述べられています。
The description of the T bit as the bit describing whether a TCB has been destroyed is misleading. In addition, the procedure described in Section 2.13 is not as precise as needed.
TCBが破壊されているかどうかを説明するビットとしてのTビットの説明は誤解を招くものです。さらに、セクション2.13で説明されている手順は、必要なほど正確ではありません。
---------
Old text: (Section 3.3.7)
---------
T bit: 1 bit The T bit is set to 0 if the sender had a TCB that it destroyed. If the sender did not have a TCB it should set this bit to 1.
Tビット：1ビットTビットは、送信側が破棄したTCBを持っている場合、0に設定されます。送信側にTCBがない場合は、このビットを1に設定する必要があります。
---------
New text: (Section 3.3.7)
---------
T bit: 1 bit The T bit is set to 0 if the sender filled in the Verification Tag expected by the peer. If the Verification Tag is reflected, the T bit MUST be set to 1. Reflecting means that the sent Verification Tag is the same as the received one.
Tビット：1ビットピアが予期する検証タグを送信者が入力した場合、Tビットは0に設定されます。検証タグが反映されている場合、Tビットは1に設定する必要があります。反映とは、送信された検証タグが受信した検証タグと同じであることを意味します。
---------
Old text: (Section 3.3.13)
---------
T bit: 1 bit The T bit is set to 0 if the sender had a TCB that it destroyed. If the sender did not have a TCB it should set this bit to 1.
Tビット：1ビットTビットは、送信側が破棄したTCBを持っている場合、0に設定されます。送信側にTCBがない場合は、このビットを1に設定する必要があります。
---------
New text: (Section 3.3.13)
---------
T bit: 1 bit The T bit is set to 0 if the sender filled in the Verification Tag expected by the peer. If the Verification Tag is reflected, the T bit MUST be set to 1. Reflecting means that the sent Verification Tag is the same as the received one.
Tビット：1ビットピアが予期する検証タグを送信者が入力した場合、Tビットは0に設定されます。検証タグが反映されている場合、Tビットは1に設定する必要があります。反映とは、送信された検証タグが受信した検証タグと同じであることを意味します。
---------
Old text: (Section 8.4)
---------
3) If the packet contains an INIT chunk with a Verification Tag set to '0', process it as described in Section 5.1. Otherwise,
3）パケットに検証タグが「0」に設定されたINITチャンクが含まれている場合は、セクション5.1の説明に従って処理します。さもないと、
---------
New text: (Section 8.4)
---------
3) If the packet contains an INIT chunk with a Verification Tag
set to '0', process it as described in Section 5.1. If, for
whatever reason, the INIT cannot be processed normally and
an ABORT has to be sent in response, the Verification Tag of
the packet containing the ABORT chunk MUST be the Initiate
tag of the received INIT chunk, and the T-Bit of the ABORT
chunk has to be set to 0, indicating that the Verification
Tag is NOT reflected.
---------
Old text: (Section 8.4)
---------
5) If the packet contains a SHUTDOWN ACK chunk, the receiver
should respond to the sender of the OOTB packet with a
SHUTDOWN COMPLETE. When sending the SHUTDOWN COMPLETE, the
receiver of the OOTB packet must fill in the Verification
Tag field of the outbound packet with the Verification Tag
received in the SHUTDOWN ACK and set the T-bit in the Chunk
Flags to indicate that no TCB was found. Otherwise,
---------
New text: (Section 8.4)
---------
5) If the packet contains a SHUTDOWN ACK chunk, the receiver should respond to the sender of the OOTB packet with a SHUTDOWN COMPLETE. When sending the SHUTDOWN COMPLETE, the receiver of the OOTB packet must fill in the Verification Tag field of the outbound packet with the Verification Tag received in the SHUTDOWN ACK and set the T-bit in the Chunk Flags to indicate that the Verification Tag is reflected. Otherwise,
5）パケットにSHUTDOWN ACKチャンクが含まれている場合、受信者はOOTBパケットの送信者にSHUTDOWN COMPLETEで応答する必要があります。 SHUTDOWN COMPLETEを送信する場合、OOTBパケットの受信者は、送信パケットの検証タグフィールドにSHUTDOWN ACKで受信した検証タグを入力し、チャンクフラグのTビットを設定して、検証タグが反映されていることを示す必要があります。 。さもないと、
---------
Old text: (Section 8.4)
---------
8) The receiver should respond to the sender of the OOTB packet with an ABORT. When sending the ABORT, the receiver of the OOTB packet MUST fill in the Verification Tag field of the outbound packet with the value found in the Verification Tag field of the OOTB packet and set the T-bit in the Chunk Flags to indicate that no TCB was found. After sending this ABORT, the receiver of the OOTB packet shall discard the OOTB packet and take no further action.
8）受信者は、OOTBパケットの送信者にABORTで応答する必要があります。 ABORTを送信するとき、OOTBパケットの受信者は、アウトバウンドパケットの検証タグフィールドにOOTBパケットの検証タグフィールドにある値を入力し、チャンクフラグのTビットを設定してTCBがないことを示す必要があります。発見された。このABORTを送信した後、OOTBパケットの受信者はOOTBパケットを破棄し、それ以上のアクションは行いません。
---------
New text: (Section 8.4)
---------
8) The receiver should respond to the sender of the OOTB packet with an ABORT. When sending the ABORT, the receiver of the OOTB packet MUST fill in the Verification Tag field of the outbound packet with the value found in the Verification Tag field of the OOTB packet and set the T-bit in the Chunk Flags to indicate that the Verification Tag is reflected. After sending this ABORT, the receiver of the OOTB packet shall discard the OOTB packet and take no further action.
8）受信者は、OOTBパケットの送信者にABORTで応答する必要があります。 ABORTを送信するとき、OOTBパケットの受信者は、アウトバウンドパケットの検証タグフィールドにOOTBパケットの検証タグフィールドにある値を入力し、チャンクフラグのTビットを設定して、検証を示す必要があります。タグが反映されます。このABORTを送信した後、OOTBパケットの受信者はOOTBパケットを破棄し、それ以上のアクションは行いません。
---------
Old text: (Section 8.5.1)
---------
B) Rules for packet carrying ABORT:
B）ABORTを運ぶパケットのルール：
- The endpoint shall always fill in the Verification Tag field of the outbound packet with the destination endpoint's tag value if it is known.
- エンドポイントは、既知の場合、常に送信パケットの検証タグフィールドに宛先エンドポイントのタグ値を入力します。
- If the ABORT is sent in response to an OOTB packet, the endpoint MUST follow the procedure described in Section 8.4.
- ABORTがOOTBパケットに応答して送信される場合、エンドポイントはセクション8.4で説明されている手順に従う必要があります。
- The receiver MUST accept the packet if the Verification Tag matches either its own tag, OR the tag of its peer. Otherwise, the receiver MUST silently discard the packet and take no further action.
- 検証タグが自身のタグまたはピアのタグのいずれかに一致する場合、受信者はパケットを受け入れる必要があります。それ以外の場合、受信者は黙ってパケットを破棄し、それ以上のアクションを実行してはなりません（MUST）。
---------
New text: (Section 8.5.1)
---------
B) Rules for packet carrying ABORT:
B）ABORTを運ぶパケットのルール：
- The endpoint MUST always fill in the Verification Tag field of the outbound packet with the destination endpoint's tag value, if it is known.
- エンドポイントは、既知の場合、常に送信パケットの検証タグフィールドに宛先エンドポイントのタグ値を入力する必要があります。
- If the ABORT is sent in response to an OOTB packet, the endpoint MUST follow the procedure described in Section 8.4.
- ABORTがOOTBパケットに応答して送信される場合、エンドポイントはセクション8.4で説明されている手順に従う必要があります。
- The receiver of an ABORT MUST accept the packet if the Verification Tag field of the packet matches its own tag and the T bit is not set OR if it is set to its peer's tag and the T bit is set in the Chunk Flags. Otherwise, the receiver MUST silently discard the packet and take no further action.
- ABORTの受信者は、パケットの検証タグフィールドが自身のタグと一致し、Tビットが設定されていない場合、またはピアのタグに設定されていて、チャンクフラグでTビットが設定されている場合、パケットを受け入れる必要があります。それ以外の場合、受信者は黙ってパケットを破棄し、それ以上のアクションを実行してはなりません（MUST）。
---------
Old text: (Section 8.5.1)
---------
C) Rules for packet carrying SHUTDOWN COMPLETE:
C）シャットダウンを完了するパケットのルール：
- When sending a SHUTDOWN COMPLETE, if the receiver of the SHUTDOWN ACK has a TCB then the destination endpoint's tag MUST be used. Only where no TCB exists should the sender use the Verification Tag from the SHUTDOWN ACK.
- SHUTDOWN COMPLETEを送信するとき、SHUTDOWN ACKの受信側にTCBがある場合、宛先エンドポイントのタグを使用する必要があります。 TCBが存在しない場合にのみ、送信者はSHUTDOWN ACKからの検証タグを使用する必要があります。
- The receiver of a SHUTDOWN COMPLETE shall accept the packet if the Verification Tag field of the packet matches its own tag OR it is set to its peer's tag and the T bit is set in the Chunk Flags. Otherwise, the receiver MUST silently discard the packet and take no further action. An endpoint MUST ignore the SHUTDOWN COMPLETE if it is not in the SHUTDOWN-ACK-SENT state.
- SHUTDOWN COMPLETEの受信者は、パケットの検証タグフィールドが自身のタグと一致するか、ピアのタグに設定され、チャンクフラグにTビットが設定されている場合、パケットを受け入れます。それ以外の場合、受信者は黙ってパケットを破棄し、それ以上のアクションを実行してはなりません（MUST）。エンドポイントがSHUTDOWN-ACK-SENT状態でない場合、エンドポイントはSHUTDOWN COMPLETEを無視する必要があります。
---------
New text: (Section 8.5.1)
---------
C) Rules for packet carrying SHUTDOWN COMPLETE:
C）シャットダウンを完了するパケットのルール：
- When sending a SHUTDOWN COMPLETE, if the receiver of the SHUTDOWN ACK has a TCB, then the destination endpoint's tag MUST be used, and the T-bit MUST NOT be set. Only where no TCB exists should the sender use the Verification Tag from the SHUTDOWN ACK, and MUST set the T-bit.
- SHUTDOWN COMPLETEを送信するとき、SHUTDOWN ACKの受信側にTCBがある場合、宛先エンドポイントのタグを使用する必要があり、Tビットを設定してはなりません（MUST NOT）。 TCBが存在しない場合にのみ、送信者はSHUTDOWN ACKからの検証タグを使用し、Tビットを設定する必要があります。
- The receiver of a SHUTDOWN COMPLETE shall accept the packet if the Verification Tag field of the packet matches its own tag and the T bit is not set OR if it is set to its peer's tag and the T bit is set in the Chunk Flags. Otherwise, the receiver MUST silently discard the packet and take no further action. An endpoint MUST ignore the SHUTDOWN COMPLETE if it is not in the SHUTDOWN-ACK-SENT state.
- SHUTDOWN COMPLETEの受信者は、パケットの検証タグフィールドが自身のタグと一致し、Tビットが設定されていない場合、またはピアのタグに設定されており、Tビットがチャンクフラグに設定されている場合、パケットを受け入れます。それ以外の場合、受信者は黙ってパケットを破棄し、それ以上のアクションを実行してはなりません（MUST）。エンドポイントがSHUTDOWN-ACK-SENT状態でない場合、エンドポイントはSHUTDOWN COMPLETEを無視する必要があります。
The description of the T bit now clearly describes the semantic of the bit. The procedures for receiving the T bit have been clarified.
Tビットの記述は、ビットの意味を明確に記述します。 Tビットの受信手順が明確になりました。
The description given in Section 2.33 does not state clearly whether an INIT-ACK or COOKIE-ECHO is sent.
セクション2.33に記載されている説明では、INIT-ACKまたはCOOKIE-ECHOのどちらが送信されたかを明確に述べていません。
The changes given here already include changes suggested in Section 2.2, 2.27, and 2.33 of this document.
ここでの変更には、このドキュメントのセクション2.2、2.27、および2.33で提案された変更がすでに含まれています。
---------
Old text: (Section 3.2.1)
---------
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 parameter in an 'Unrecognized Parameter Type' (in either an ERROR or in the INIT ACK).
01-このSCTPパケットの処理を停止して破棄し、その中のそれ以上のチャンクを処理せずに、「認識されないパラメータタイプ」（エラーまたはINIT ACKのいずれか）で認識されないパラメータを報告します。
10 - Skip this parameter and continue processing.
10-このパラメーターをスキップして、処理を続行します。
11 - Skip this parameter and continue processing but report the unrecognized parameter in an 'Unrecognized Parameter Type' (in either an ERROR or in the INIT ACK).
11-このパラメーターをスキップして処理を続行しますが、「認識されないパラメータータイプ」（ERRORまたはINIT ACKのいずれか）で認識されないパラメーターを報告します。
---------
New text: (Section 3.2.1)
---------
00 - Stop processing this parameter; do not process any further parameters within this chunk.
00-このパラメーターの処理を停止します。このチャンク内でこれ以上パラメーターを処理しないでください。
01 - Stop processing this parameter, do not process any further parameters within this chunk, and report the unrecognized parameter in an 'Unrecognized Parameter', as described in 3.2.2.
01-このパラメーターの処理を停止し、このチャンク内でこれ以上パラメーターを処理せず、3.2.2で説明されているように、「認識されないパラメーター」で認識されないパラメーターを報告します。
10 - Skip this parameter and continue processing.
10-このパラメーターをスキップして、処理を続行します。
11 - Skip this parameter and continue processing but report the unrecognized parameter in an 'Unrecognized Parameter', as described in 3.2.2.
11-このパラメーターをスキップして処理を続行しますが、3.2.2で説明されているように、「認識されないパラメーター」で認識されないパラメーターを報告します。
Please note that in all four cases an INIT-ACK or COOKIE-ECHO chunk is sent. In the 00 or 01 case the processing of the parameters after the unknown parameter is canceled, but no processing already done is rolled back.
4つのケースすべてで、INIT-ACKまたはCOOKIE-ECHOチャンクが送信されることに注意してください。 00または01の場合、不明なパラメーターの後のパラメーターの処理は取り消されますが、すでに行われた処理はロールバックされません。
---------
New text: (Note: no old text; clarification added in Section 3.2)
---------
3.2.2. Reporting of Unrecognized Parameters
3.2.2. 認識されないパラメータの報告
If the receiver of an INIT chunk detects unrecognized parameters and has to report them according to Section 3.2.1, it MUST put the 'Unrecognized Parameter' parameter(s) in the INIT-ACK chunk sent in response to the INIT-chunk. Note that if the receiver of the INIT chunk is NOT going to establish an association (e.g., due to lack of resources), an 'Unrecognized Parameter' would NOT be included with any ABORT being sent to the sender of the INIT.
INITチャンクのレシーバーが認識されないパラメーターを検出し、セクション3.2.1に従ってそれらを報告する必要がある場合、INITチャンクに応答して送信されるINIT-ACKチャンクに「Unrecognized Parameter」パラメーターを配置する必要があります。 INITチャンクの受信側が関連付けを確立しない場合（リソースの不足など）、「Unrecognized Parameter」は、INITの送信側に送信されるABORTに含まれないことに注意してください。
If the receiver of an INIT-ACK chunk detects unrecognized parameters and has to report them according to Section 3.2.1, it SHOULD bundle the ERROR chunk containing the 'Unrecognized Parameters' error cause with the COOKIE-ECHO chunk sent in response to the INIT-ACK chunk. If the receiver of the INIT-ACK cannot bundle the COOKIE-ECHO chunk with the ERROR chunk, the ERROR chunk MAY be sent separately but not before the COOKIE-ACK has been received.
INIT-ACKチャンクのレシーバーが認識できないパラメーターを検出し、セクション3.2.1に従ってそれらを報告する必要がある場合、INITに応答して送信されたCOOKIE-ECHOチャンクに「認識できないパラメーター」エラーの原因を含むERRORチャンクをバンドルする必要があります（SHOULD）。 -ACKチャンク。 INIT-ACKの受信者がCOOKIE-ECHOチャンクをERRORチャンクとバンドルできない場合、ERRORチャンクは個別に送信できますが、COOKIE-ACKを受信する前に送信することはできません。
Note: Any time a COOKIE-ECHO is sent in a packet, it MUST be the first chunk.
注：COOKIE-ECHOがパケットで送信されるときは常に、それが最初のチャンクでなければなりません。
The new text clearly states that an INIT-ACK or COOKIE-ECHO has to be sent.
新しいテキストは、INIT-ACKまたはCOOKIE-ECHOを送信する必要があることを明確に述べています。
The description given in Section 3.3.11 of RFC 2960 [5] is unclear as to how the COOKIE-ECHO is composed.
RFC 2960 [5]のセクション3.3.11に記載されている説明では、COOKIE-ECHOの構成については不明です。
---------
Old text: (Section 3.3.11)
---------
Cookie: variable size
This field must contain the exact cookie received in the State Cookie parameter from the previous INIT ACK.
このフィールドには、以前のINIT ACKからState Cookieパラメータで受け取った正確なCookieが含まれている必要があります。
An implementation SHOULD make the cookie as small as possible to insure interoperability.
実装は相互運用性を保証するためにCookieを可能な限り小さくする必要があります（SHOULD）。
---------
New text: (Section 3.3.11)
---------
Cookie: variable size
This field must contain the exact cookie received in the State Cookie parameter from the previous INIT ACK.
このフィールドには、以前のINIT ACKからState Cookieパラメータで受け取った正確なCookieが含まれている必要があります。
An implementation SHOULD make the cookie as small as possible to ensure interoperability.
実装は相互運用性を保証するためにCookieを可能な限り小さくする必要があります（SHOULD）。
Note: A Cookie Echo does NOT contain a State Cookie Parameter; instead, the data within the State Cookie's Parameter Value becomes the data within the Cookie Echo's Chunk Value. This allows an implementation to change only the first two bytes of the State Cookie parameter to become a Cookie Echo Chunk.
注：Cookieエコーには、State Cookieパラメーターは含まれていません。代わりに、状態Cookieのパラメーター値内のデータは、Cookieエコーのチャンク値内のデータになります。これにより、実装はState Cookieパラメーターの最初の2バイトのみを変更してCookie Echo Chunkになることができます。
The new text adds a note that helps clarify that a Cookie Echo chunk is nothing more than the State Cookie parameter with only two bytes modified.
新しいテキストには、Cookie Echoチャンクが2バイトのみが変更されたState Cookieパラメーターにすぎないことを明確にするのに役立つメモが追加されています。
Section 6.10 of RFC 2960 [5] uses the notion of 'partial chunks' without defining it.
RFC 2960 [5]のセクション6.10では、「部分的なチャンク」という概念を使用せずに定義しています。
---------
Old text: (Section 6.10)
---------
Partial chunks MUST NOT be placed in an SCTP packet.
---------
New text: (Section 6.10)
---------
Partial chunks MUST NOT be placed in an SCTP packet. A partial
chunk is a chunk that is not completely contained in the SCTP
packet; i.e., the SCTP packet is too short to contain all the bytes
of the chunk as indicated by the chunk length.
The new text adds a definition of 'partial chunks'.
The new text adds a definition of 'partial chunks'.
Section 8.4 of RFC 2960 [5] forces the OOTB handling to discard all non-unicast addresses. This leaves future use of anycast addresses in question. With the addition of the add-ip feature, SCTP should be able to easily handle anycast INIT s that can be followed, after association setup, with a delete of the anycast address from the association.
RFC 2960 [5]のセクション8.4は、OOTB処理がすべての非ユニキャストアドレスを破棄するように強制します。これにより、エニーキャストアドレスの将来の使用が問題になります。 add-ip機能の追加により、SCTPは、関連付けのセットアップ後に、関連付けからのエニーキャストアドレスの削除を伴うことができるエニーキャストINITを簡単に処理できるようになります。
---------
Old text: (Section 8.4)
---------
8.4 Handle "Out of the blue" Packets
An SCTP packet is called an "out of the blue" (OOTB) packet if it is correctly formed, i.e., passed the receiver's Adler-32 check (see Section 6.8), but the receiver is not able to identify the association to which this packet belongs.
SCTPパケットは、それが正しく形成されている場合、つまり受信者のAdler-32チェックに合格した場合（セクション6.8を参照）、「out of the blue」（OOTB）パケットと呼ばれますが、受信者はこれに関連付けを識別できません。パケットが属しています。
The receiver of an OOTB packet MUST do the following:
OOTBパケットの受信者は、以下を実行する必要があります。
1) If the OOTB packet is to or from a non-unicast address, silently discard the packet. Otherwise,
1）OOTBパケットが非ユニキャストアドレスとの間で送受信されている場合、パケットをサイレントに破棄します。さもないと、
---------
New text: (Section 8.4)
---------
8.4. Handle "Out of the Blue" Packets
8.4. 「Out of the Blue」パケットの処理
An SCTP packet is called an "out of the blue" (OOTB) packet if it is correctly formed (i.e., passed the receiver's CRC32c check; see Section 6.8), but the receiver is not able to identify the association to which this packet belongs.
SCTPパケットは、正しく形成されている場合（つまり、レシーバーのCRC32cチェックに合格した場合、セクション6.8を参照）、「out of the blue」（OOTB）パケットと呼ばれますが、レシーバーはこのパケットが属するアソシエーションを識別できません。 。
The receiver of an OOTB packet MUST do the following:
The receiver of an OOTB packet MUST do the following:
1) If the OOTB packet is to or from a non-unicast address, a receiver SHOULD silently discard the packet. Otherwise,
1）OOTBパケットが非ユニキャストアドレスとの間で送受信される場合、受信者はパケットをサイレントに破棄する必要があります（SHOULD）。さもないと、
The loosening of the wording to a SHOULD will now allow future use of anycast addresses. Note that no changes are made to Section 11.2.4.1, since responding to broadcast addresses could lead to flooding attacks and implementors should pay careful attention to these words.
SHOULDへの表現を緩めると、エニーキャストアドレスを将来使用できるようになります。ブロードキャストアドレスに応答するとフラッディング攻撃につながる可能性があるため、セクション11.2.4.1は変更されないことに注意してください。実装者はこれらの単語に注意を払う必要があります。
Section 3.3.7 of RFC 2960 [5] requires an SCTP endpoint to silently discard ABORT chunks received for associations that do not exist. It is not clear what this means in the COOKIE-WAIT state, for example. Therefore, it was not clear whether an ABORT sent in response to an INIT should be processed or silently discarded.
RFC 2960 [5]のセクション3.3.7では、存在しないアソシエーション用に受信したABORTチャンクをサイレントに破棄するSCTPエンドポイントが必要です。たとえば、COOKIE-WAIT状態でこれが何を意味するのかは明らかではありません。そのため、INITへの応答として送信されたABORTを処理するのか、暗黙のうちに破棄するのかは明確ではありませんでした。
---------
Old text: (Section 3.3.7)
---------
If an endpoint receives an ABORT with a format error or for an association that doesn't exist, it MUST silently discard it.
エンドポイントがフォーマットエラーのあるABORTを受け取った場合、または存在しないアソシエーションの場合、エンドポイントは黙ってそれを破棄する必要があります。
---------
New text: (Section 3.3.7)
---------
If an endpoint receives an ABORT with a format error or no TCB is found, it MUST silently discard it.
エンドポイントがフォーマットエラーのあるABORTを受信した場合、またはTCBが見つからなかった場合、エンドポイントはそれを黙って破棄する必要があります。
It is now clearly stated that an ABORT chunk should be processed whenever a TCB is found.
TCBが見つかった場合は必ずABORTチャンクを処理する必要があることが明記されました。
Section 5.1 of RFC 2960 [5] requires that an ABORT chunk be sent in response to an INIT chunk when there is no listening end point. To make port scanning harder, someone might not want these ABORTs to be received by the sender of the INIT chunks. Currently, the only way to enforce this is by using a firewall that discards the packets containing the INIT chunks or the packets containing the ABORT chunks. It is desirable that the same can be done without a middle box.
RFC 2960 [5]のセクション5.1では、リスニングエンドポイントがない場合、INITチャンクへの応答としてABORTチャンクを送信する必要があります。ポートスキャンを困難にするために、INITチャンクの送信者がこれらのABORTを受信したくない場合があります。現在、これを強制する唯一の方法は、INITチャンクを含むパケットまたはABORTチャンクを含むパケットを破棄するファイアウォールを使用することです。ミドルボックスなしでも同じことができることが望ましい。
---------
Old text: (Section 5.1)
---------
If an endpoint receives an INIT, INIT ACK, or COOKIE ECHO chunk but decides not to establish the new association due to missing mandatory parameters in the received INIT or INIT ACK, invalid parameter values, or lack of local resources, it MUST respond with an ABORT chunk.
エンドポイントがINIT、INIT ACK、またはCOOKIE ECHOチャンクを受信したが、受信したINITまたはINIT ACKの必須パラメーターが欠落している、無効なパラメーター値、またはローカルリソースがないために、新しい関連付けを確立しないことを決定した場合、 ABORTチャンク。
---------
New text: (Section 5.1)
---------
If an endpoint receives an INIT, INIT ACK, or COOKIE ECHO chunk but decides not to establish the new association due to missing mandatory parameters in the received INIT or INIT ACK, invalid parameter values, or lack of local resources, it SHOULD respond with an ABORT chunk.
エンドポイントがINIT、INIT ACK、またはCOOKIE ECHOチャンクを受信したが、受信したINITまたはINIT ACKの必須パラメーターが欠落している、無効なパラメーター値、またはローカルリソースがないために、新しい関連付けを確立しないことを決定した場合、エンドポイントはABORTチャンク。
The requirement of sending ABORT chunks is relaxed such that an implementation can decide not to send ABORT chunks.
実装がABORTチャンクを送信しないことを決定できるように、ABORTチャンクを送信する要件は緩和されています。
The sender of the INIT chunk can include a 'Supported Address Types' parameter to indicate which address families are supported. It is unclear how an INIT chunk should be processed where the source address of the packet containing the INIT chunk or listed addresses within the INIT chunk indicate that more address types are supported than those listed in the 'Supported Address Types' parameter.
INITチャンクの送信者には、サポートされているアドレスファミリを示す「サポートされているアドレスタイプ」パラメータを含めることができます。 INITチャンクを含むパケットの送信元アドレスまたはINITチャンク内のリストされたアドレスが、「サポートされているアドレスタイプ」パラメーターにリストされているアドレスタイプよりも多くのアドレスタイプがサポートされていることを示している場合、INITチャンクの処理方法は不明です。
The changes given here already include changes suggested in Section 2.28 of this document.
ここでの変更には、このドキュメントのセクション2.28で提案された変更がすでに含まれています。
---------
Old text: (Section 5.1.2)
---------
IMPLEMENTATION NOTE: In the case that the receiver of an INIT ACK fails to resolve the address parameter due to an unsupported type, it can abort the initiation process and then attempt a re-initiation by using a 'Supported Address Types' parameter in the new INIT to indicate what types of address it prefers.
実装上の注意：サポートされていないタイプが原因でINIT ACKの受信者がアドレスパラメータを解決できない場合、初期化プロセスを中止し、新しいサポートされているアドレスタイプのパラメータを使用して再初期化を試みることができますINITは、優先するアドレスのタイプを示します。
---------
New text: (Section 5.1.2)
---------
IMPLEMENTATION NOTE: In the case that the receiver of an INIT ACK fails to resolve the address parameter due to an unsupported type, it can abort the initiation process and then attempt a re-initiation by using a 'Supported Address Types' parameter in the new INIT to indicate what types of address it prefers.
実装上の注意：サポートされていないタイプが原因でINIT ACKの受信者がアドレスパラメータを解決できない場合、初期化プロセスを中止し、新しいサポートされているアドレスタイプのパラメータを使用して再初期化を試みることができますINITは、優先するアドレスのタイプを示します。
IMPLEMENTATION NOTE: If an SCTP endpoint that only supports either IPv4 or IPv6 receives IPv4 and IPv6 addresses in an INIT or INIT-ACK chunk from its peer, it MUST use all the addresses belonging to the supported address family. The other addresses MAY be ignored. The endpoint SHOULD NOT respond with any kind of error indication.
実装上の注意：IPv4またはIPv6のいずれかのみをサポートするSCTPエンドポイントがピアからINITまたはINIT-ACKチャンクでIPv4およびIPv6アドレスを受信する場合、サポートされているアドレスファミリに属するすべてのアドレスを使用する必要があります。他のアドレスは無視されるかもしれません。エンドポイントは、いかなる種類のエラー表示でも応答してはなりません（SHOULD NOT）。
IMPLEMENTATION NOTE: If an SCTP endpoint lists in the 'Supported Address Types' parameter either IPv4 or IPv6, but uses the other family for sending the packet containing the INIT chunk, or if it also lists addresses of the other family in the INIT chunk, then the address family that is not listed in the 'Supported Address Types' parameter SHOULD also be considered as supported by the receiver of the INIT chunk. The receiver of the INIT chunk SHOULD NOT respond with any kind of error indication.
実装上の注意：SCTPエンドポイントがIPv4またはIPv6の「サポートされているアドレスタイプ」パラメーターにリストされているが、INITチャンクを含むパケットの送信に他のファミリーを使用している場合、またはINITチャンクに他のファミリーのアドレスもリストされている場合、次に、「サポートされているアドレスタイプ」パラメータにリストされていないアドレスファミリも、INITチャンクの受信者によってサポートされていると見なされるべきです（SHOULD）。 INITチャンクの受信者は、いかなる種類のエラー表示でも応答してはなりません（SHOULD NOT）。
It is now clearly described how these Supported Address Types parameters with incorrect data should be handled.
正しくないデータを含むこれらのサポートされているアドレスタイプパラメータの処理方法が明確に説明されています。
RFC 2960 [5] clearly describes how unknown parameters in the INIT and INIT-ACK chunk should be processed. But it is not described how unexpected parameters should be processed. A parameter is unexpected if it is known and is an optional parameter in either the INIT or INIT-ACK chunk but is received in the chunk for which it is not an optional parameter. For example, the 'Supported Address Types' parameter would be an unexpected parameter if contained in an INIT-ACK chunk.
RFC 2960 [5]は、INITおよびINIT-ACKチャンク内の不明なパラメーターをどのように処理する必要があるかを明確に説明しています。ただし、予期しないパラメータの処理方法については説明されていません。パラメータは、既知であり、INITまたはINIT-ACKチャンクのオプションパラメータであるが、オプションパラメータではないチャンクで受信される場合、予期しないものです。たとえば、「サポートされているアドレスタイプ」パラメーターは、INIT-ACKチャンクに含まれている場合、予期しないパラメーターになります。
---------
Old text: (Section 3.3.2)
---------
Note 4: This parameter, when present, specifies all the address types the sending endpoint can support. The absence of this parameter indicates that the sending endpoint can support any address type.
注4：このパラメーターが存在する場合、送信エンドポイントがサポートできるすべてのアドレスタイプを指定します。このパラメーターがないことは、送信エンドポイントが任意のアドレスタイプをサポートできることを示しています。
---------
New text: (Section 3.3.2)
---------
Note 4: This parameter, when present, specifies all the address types the sending endpoint can support. The absence of this parameter indicates that the sending endpoint can support any address type.
Note 4: This parameter, when present, specifies all the address types the sending endpoint can support. The absence of this parameter indicates that the sending endpoint can support any address type.
IMPLEMENTATION NOTE: If an INIT chunk is received with known parameters that are not optional parameters of the INIT chunk then the receiver SHOULD process the INIT chunk and send back an INIT-ACK. The receiver of the INIT chunk MAY bundle an ERROR chunk with the COOKIE-ACK chunk later. However, restrictive implementations MAY send back an ABORT chunk in response to the INIT chunk.
実装上の注意：INITチャンクのオプションパラメーターではない既知のパラメーターを使用してINITチャンクを受信した場合、受信者はINITチャンクを処理してINIT-ACKを返信する必要があります（SHOULD）。 INITチャンクの受信者は、ERRORチャンクを後でCOOKIE-ACKチャンクにバンドルしてもよい（MAY）。ただし、制限のある実装は、INITチャンクへの応答としてABORTチャンクを送り返す場合があります。
---------
Old text: (Section 3.3.3)
---------
IMPLEMENTATION NOTE: An implementation MUST be prepared to receive a INIT ACK that is quite large (more than 1500 bytes) due to the variable size of the state cookie AND the variable address list. For example if a responder to the INIT has 1000 IPv4 addresses it wishes to send, it would need at least 8,000 bytes to encode this in the INIT ACK.
実装上の注意：ステートCookieの可変サイズと可変アドレスリストにより、非常に大きい（1500バイトを超える）INIT ACKを受信できるように実装を準備する必要があります。たとえば、INITへのレスポンダに送信したいIPv4アドレスが1000ある場合、これをINIT ACKにエンコードするには少なくとも8,000バイトが必要です。
---------
New text: (Section 3.3.3)
---------
IMPLEMENTATION NOTE: An implementation MUST be prepared to receive a INIT ACK that is quite large (more than 1500 bytes) due to the variable size of the state cookie AND the variable address list. For example, if a responder to the INIT has 1000 IPv4 addresses it wishes to send, it would need at least 8,000 bytes to encode this in the INIT ACK.
IMPLEMENTATION NOTE: An implementation MUST be prepared to receive a INIT ACK that is quite large (more than 1500 bytes) due to the variable size of the state cookie AND the variable address list. For example, if a responder to the INIT has 1000 IPv4 addresses it wishes to send, it would need at least 8,000 bytes to encode this in the INIT ACK.
IMPLEMENTATION NOTE: If an INIT-ACK chunk is received with known parameters that are not optional parameters of the INIT-ACK chunk, then the receiver SHOULD process the INIT-ACK chunk and send back a COOKIE-ECHO. The receiver of the INIT-ACK chunk MAY bundle an ERROR chunk with the COOKIE-ECHO chunk. However, restrictive implementations MAY send back an ABORT chunk in response to the INIT-ACK chunk.
実装上の注意：INIT-ACKチャンクのオプションのパラメーターではない既知のパラメーターを使用してINIT-ACKチャンクを受信した場合、受信者はINIT-ACKチャンクを処理してCOOKIE-ECHOを送信する必要があります（SHOULD）。 INIT-ACKチャンクの受信側は、ERRORチャンクをCOOKIE-ECHOチャンクにバンドルしてもよい（MAY）。ただし、制限のある実装は、INIT-ACKチャンクへの応答としてABORTチャンクを送り返す場合があります。
It is now stated how unexpected parameters should be processed.
予期しないパラメーターの処理方法について説明しました。
The current description of the payload protocol identifier does NOT highlight the fact that the field is NOT necessarily in network byte order.
ペイロードプロトコル識別子の現在の説明では、フィールドが必ずしもネットワークバイト順であるとは限らないという事実を強調していません。
---------
Old text: (Section 3.3.1)
---------
Payload Protocol Identifier: 32 bits (unsigned integer)
This value represents an application (or upper layer) specified protocol identifier. This value is passed to SCTP by its upper layer and sent to its peer. This identifier is not used by SCTP but can be used by certain network entities as well as the peer application to identify the type of information being carried in this DATA chunk. This field must be sent even in fragmented DATA chunks (to make sure it is available for agents in the middle of the network).
この値は、アプリケーション（または上位層）が指定したプロトコル識別子を表します。この値は、上位層によってSCTPに渡され、ピアに送信されます。この識別子はSCTPでは使用されませんが、このDATAチャンクで運ばれる情報のタイプを識別するために、特定のネットワークエンティティやピアアプリケーションで使用できます。このフィールドは、断片化されたDATAチャンクでも送信する必要があります（ネットワークの途中のエージェントが使用できるようにするため）。
The value 0 indicates no application identifier is specified by the upper layer for this payload data.
値0は、このペイロードデータの上位層でアプリケーション識別子が指定されていないことを示します。
---------
New text: (Section 3.3.1)
---------
Payload Protocol Identifier: 32 bits (unsigned integer)
This value represents an application (or upper layer) specified protocol identifier. This value is passed to SCTP by its upper layer and sent to its peer. This identifier is not used by SCTP but can be used by certain network entities, as well as by the peer application, to identify the type of information being carried in this DATA chunk. This field must be sent even in fragmented DATA chunks (to make sure it is available for agents in the middle of the network). Note that this field is NOT touched by an SCTP implementation, therefore its byte order is NOT necessarily Big Endian. The upper layer is responsible for any byte order conversions to this field.
この値は、アプリケーション（または上位層）が指定したプロトコル識別子を表します。この値は、上位層によってSCTPに渡され、ピアに送信されます。この識別子はSCTPでは使用されませんが、このDATAチャンクで伝送される情報のタイプを識別するために、特定のネットワークエンティティやピアアプリケーションで使用できます。このフィールドは、断片化されたDATAチャンクでも送信する必要があります（ネットワークの途中のエージェントが使用できるようにするため）。このフィールドはSCTP実装によって影響を受けないため、そのバイト順は必ずしもビッグエンディアンではないことに注意してください。上位層は、このフィールドへのバイト順変換を担当します。
The value 0 indicates that no application identifier is specified by the upper layer for this payload data.
値0は、このペイロードデータの上位層でアプリケーション識別子が指定されていないことを示します。
It is now explicitly stated that the upper layer is responsible for the byte order of this field.
現在、上位層がこのフィールドのバイト順序を担当していることが明示的に述べられています。
The current wording of the use of Karn's algorithm is not descriptive enough to ensure that an implementation in a multi-homed association does not incorrectly mismeasure the RTT.
カーンのアルゴリズムの使用に関する現在の表現は、マルチホームアソシエーションでの実装がRTTを誤って測定しないことを保証するのに十分な説明ではありません。
---------
Old text: (Section 6.3.1)
---------
C5) Karn's algorithm: RTT measurements MUST NOT be made using
packets that were retransmitted (and thus for which it is
ambiguous whether the reply was for the first instance of the
packet or a later instance)
---------
New text: (Section 6.3.1)
---------
C5) Karn's algorithm: RTT measurements MUST NOT be made using chunks that were retransmitted (and thus for which it is ambiguous whether the reply was for the first instance of the chunk or for a later instance)
C5）Karnのアルゴリズム：RTT測定は、再送信されたチャンクを使用して行われてはなりません（したがって、応答がチャンクの最初のインスタンスに対するものか、それ以降のインスタンスに対するものかが不明確です）。
IMPLEMENTATION NOTE: RTT measurements should only be made using a chunk with TSN r if no chunk with TSN less than or equal to r is retransmitted since r is first sent.
実装に関する注意：RTTの測定は、rが最初に送信されてからTSNがr以下のチャンクが再送信されない場合にのみ、TSN rのチャンクを使用して行う必要があります。
The above clarification adds an implementation note that will provide additional guidance in the application of Karn's algorithm.
上記の説明は、カーンのアルゴリズムの適用における追加のガイダンスを提供する実装ノートを追加します。
The original SCTP specification is overly conservative in requiring 4 missing reports before fast retransmitting a segment. TCP uses 3 missing reports or 4 acknowledgements indicating that the same segment was received.
元のSCTP仕様は、セグメントを高速で再送信する前に4つの欠落したレポートを要求するという点で、非常に保守的です。 TCPは、同じセグメントが受信されたことを示す3つの欠落したレポートまたは4つの確認応答を使用します。
---------
Old text:
---------
7.2.4 Fast Retransmit on Gap Reports
7.2.4 ギャップレポートでの高速再送信
In the absence of data loss, an endpoint performs delayed acknowledgement. However, whenever an endpoint notices a hole in the arriving TSN sequence, it SHOULD start sending a SACK back every time a packet arrives carrying data until the hole is filled.
データ損失がない場合、エンドポイントは確認応答の遅延を実行します。ただし、エンドポイントは、到着するTSNシーケンスのホールに気づいたときはいつでも、ホールが埋められるまで、データを運ぶパケットが到着するたびにSACKの送信を開始する必要があります。
Whenever an endpoint receives a SACK that indicates some TSN(s) missing, it SHOULD wait for 3 further miss indications (via subsequent SACK's) on the same TSN(s) before taking action with regard to Fast Retransmit.
エンドポイントは、一部のTSNが欠落していることを示すSACKを受信するたびに、高速再送信に関してアクションを実行する前に、同じTSNで（後続のSACKを介して）さらに3つのミス表示を待つ必要があります。
---------
New text:
---------
7.2.4. Fast Retransmit on Gap Reports
7.2.4. ギャップレポートでの高速再送信
In the absence of data loss, an endpoint performs delayed acknowledgement. However, whenever an endpoint notices a hole in the arriving TSN sequence, it SHOULD start sending a SACK back every time a packet arrives carrying data until the hole is filled.
データ損失がない場合、エンドポイントは確認応答の遅延を実行します。ただし、エンドポイントは、到着するTSNシーケンスのホールに気づいたときはいつでも、ホールが埋められるまで、データを運ぶパケットが到着するたびにSACKの送信を開始する必要があります。
Whenever an endpoint receives a SACK that indicates that some TSNs are missing, it SHOULD wait for 2 further miss indications (via subsequent SACKs for a total of 3 missing reports) on the same TSNs before taking action with regard to Fast Retransmit.
エンドポイントは、一部のTSNが欠落していることを示すSACKを受信するたびに、高速再送信に関してアクションを実行する前に、同じTSNで（後続のSACKを介して、合計3つの欠落レポートがある）通知を待つ必要があります（SHOULD）。
The above changes will make SCTP and TCP behave similarly in terms of how fast they engage the Fast Retransmission algorithm upon receiving missing reports.
上記の変更により、SCTPとTCPは、欠落しているレポートを受信したときに高速再送信アルゴリズムを実行する速度に関して、同様に動作します。
This document should add no additional security risks to SCTP and in fact SHOULD correct some original security flaws within the original document once it is incorporated into a RFC 2960 [5] BIS document.
このドキュメントはSCTPに追加のセキュリティリスクを追加してはならず、実際にRFC 2960 [5] BISドキュメントに組み込まれたら、元のドキュメント内のいくつかの元のセキュリティ欠陥を修正する必要があります。
The authors would like to thank the following people who have provided comments and input for this document:
著者は、このドキュメントにコメントと入力を提供してくれた以下の人々に感謝します。
Barry Zuckerman, La Monte Yarroll, Qiaobing Xie, Wang Xiaopeng, Jonathan Wood, Jeff Waskow, Mike Turner, John Townsend, Sabina Torrente, Cliff Thomas, Yuji Suzuki, Manoj Solanki, Sverre Slotte, Keyur Shah, Jan Rovins, Ben Robinson, Renee Revis, Ian Periam, RC Monee, Sanjay Rao, Sujith Radhakrishnan, Heinz Prantner, Biren Patel, Nathalie Mouellic, Mitch Miers, Bernward Meyknecht, Stan McClellan, Oliver Mayor, Tomas Orti Martin, Sandeep Mahajan, David Lehmann, Jonathan Lee, Philippe Langlois, Karl Knutson, Joe Keller, Gareth Keily, Andreas Jungmaier, Janardhan Iyengar, Mutsuya Irie, John Hebert, Kausar Hassan, Fred Hasle, Dan Harrison, Jon Grim, Laurent Glaude, Steven Furniss, Atsushi Fukumoto, Ken Fujita, Steve Dimig, Thomas Curran, Serkan Cil, Melissa Campbell, Peter Butler, Rob Brennan, Harsh Bhondwe, Brian Bidulock, Caitlin Bestler, Jon Berger, Robby Benedyk, Stephen Baucke, Sandeep Balani, and Ronnie Sellar.
バリー・ズッカーマン、ラ・モンテ・ヤロール、チャオビン・シェ、ワン・シャオペン、ジョナサン・ウッド、ジェフ・ワスコウ、マイク・ターナー、ジョン・タウンゼント、サビナ・トレンテ、クリフ・トーマス、スズキ・ユージ、マノジ・ソランキ、スヴェル・スロット、キール・シャー、ジャン・ロビンス、ベン・ロビンソン、レニーレヴィス、イアンペリアム、RCモニー、サンジャイラオ、スミスラダクリシュナン、ハインツプラント、バイレンパテル、ナタリームエリク、ミッチマイアーズ、ベルンワードメイクネヒト、スタンマクレラン、オリバーマヨール、トマスオルティマーティン、サンディープマハジャン、デビッドリーマン、ジョナサンリー、フィリップ、カール・ナットソン、ジョー・ケラー、ガレス・キーリー、アンドレアス・ジュングマイヤー、ジャナルダン・アイエンガー、ムツヤ・イリー、ジョン・ヒーバート、カウザー・ハッサン、フレッド・ハスル、ダン・ハリソン、ジョン・グリム、ローレント・グロード、スティーブン・ファーニス、福本淳、藤田健、スティーブ・ディミグ、トーマスカラン、セルカンシル、メリッサキャンベル、ピーターバトラー、ロブブレナン、ハーシュボンドウェ、ブライアンビデュロック、ケイトリンベストラー、ジョンバーガー、ロビーベネディク、スティーブンバウケ、サンディープバラニ、ロニーセラー。
A special thanks to Mark Allman, who should actually be a co-author for his work on the max-burst, but managed to wiggle out due to a technicality. Also, we would like to acknowledge Lyndon Ong and Phil Conrad for their valuable input and many contributions.
Mark Allmanに特に感謝します。MarkAllmanは、実際にはmax-burstに関する彼の研究の共著者であるはずですが、専門性のためになんとか揺れ動きました。また、Lyndon OngとPhil Conradの貴重な意見と多くの貢献に謝意を表します。
This document recommends changes for the RFC 2960 [5] BIS document. As such, even though it lists new error cause code, this document in itself does NOT define those new codes. Instead, the BIS document will make the needed changes to RFC 2960 [5] and thus its IANA section will require changes to be made.
このドキュメントでは、RFC 2960 [5] BISドキュメントの変更を推奨しています。そのため、新しいエラー原因コードがリストされていますが、このドキュメント自体ではそれらの新しいコードを定義していません。代わりに、BISドキュメントはRFC 2960 [5]に必要な変更を加えるため、IANAセクションでは変更を行う必要があります。
[1] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[1] ブレーデン、R。、「インターネットホストの要件-通信層」、STD 3、RFC 1122、1989年10月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] Caro, A., Shah, K., Iyengar, J., Amer, P., and R. Stewart, "SCTP and TCP Variants: Congestion Control Under Multiple Losses", Technical Report TR2003-04, Computer and Information Sciences Department, University of Delaware, February 2003, <http://www.armandocaro.net/papers>.
[3] Caro、A.、Shah、K.、Iyengar、J.、Amer、P.、and R. Stewart、 "SCTP and TCP Variants：Congestion Control under Multiple Loss"、Technical Report TR2003-04、Computer and Information Sciences、デラウェア大学、2003年2月、<http://www.armandocaro.net/papers>。
[4] Caro, A., Amer, P., and R. Stewart, "Retransmission Schemes for End-to-end Failover with Transport Layer Multihoming", GLOBECOM, November 2004., <http://www.armandocaro.net/papers>.
[4] Caro、A.、Amer、P。、およびR. Stewart、「トランスポート層マルチホーミングを使用したエンドツーエンドフェイルオーバーの再送信スキーム」、GLOBECOM、2004年11月。<http://www.armandocaro.net/papers> 。
[5] 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, October 2000.
[5] スチュワート、R.、Xie、Q.、Morneault、K.、Sharp、C.、Schwarzbauer、H.、Taylor、T.、Rytina、I.、Kalla、M.、Zhang、L。、およびV. Paxson、 「ストリーム制御伝送プロトコル」、RFC 2960、2000年10月。
[6] Stone, J., Stewart, R., and D. Otis, "Stream Control Transmission Protocol (SCTP) Checksum Change", RFC 3309, September 2002.
[6] Stone、J.、Stewart、R。、およびD. Otis、「Stream Control Transmission Protocol（SCTP）Checksum Change」、RFC 3309、2002年9月。
Authors' Addresses
著者のアドレス
Randall R. Stewart Cisco Systems, Inc. 4875 Forest Drive Suite 200 Columbia, SC 29206 USA
Randall R. Stewart Cisco Systems、Inc. 4875 Forest Drive Suite 200 Columbia、SC 29206 USA
EMail: rrs@cisco.com
Ivan Arias-Rodriguez Nokia Research Center PO Box 407 FIN-00045 Nokia Group Finland
Ivan Arias-Rodriguez Nokia Research Center PO Box 407 FIN-00045 Nokia Groupフィンランド
EMail: ivan.arias-rodriguez@nokia.com
Kacheong Poon Sun Microsystems, Inc. 3571 N. First St. San Jose, CA 95134 USA
Kacheong Poon Sun Microsystems、Inc. 3571 N. First St. San Jose、CA 95134 USA
EMail: kacheong.poon@sun.com
Armando L. Caro Jr. BBN Technologies 10 Moulton St. Cambridge, MA 02138
Armando L. Dear Jr. BBN Technologies 10 Moulton St. Cambridge、MA 02138
EMail: acaro@bbn.com
URI: http://www.armandocaro.net
Michael Tuexen Muenster Univ. of Applied Sciences Stegerwaldstr. 39 48565 Steinfurt Germany
マイケルトゥセンミュンスター大学Applied Sciences Stegerwaldstrの。 39 48565シュタインフルトドイツ
EMail: tuexen@fh-muenster.de
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2006).
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP 78に含まれる権利、ライセンス、および制限の対象であり、そこに記載されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」で提供され、寄稿者、彼/彼女の代理人、または（もしあれば）組織、インターネットエンジニアリングおよびインターネットエンジニアリングタスクフォースは、すべての保証を明示的または明示的に提供します。ここに含まれる情報の使用により、商品性または特定の目的への適合性に関するいかなる権利または黙示の保証も侵害されないという保証を含みますが、これに限定されるものではありません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に対して行われたIPR開示のコピー、および使用可能にされるライセンスの保証、または一般ライセンスを取得する試みの結果、またはこの仕様の実装者またはユーザーがそのような所有権を使用するための許可を取得できるhttp://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、この規格を実装するために必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許申請、またはその他の所有権に注意を向けるよう、利害関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポート活動（IASA）によって提供されます。