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). (日本語訳について)----------------------------------------------------- この日本語訳は舟阪淳一が個人的に訳したものです。誤訳も含まれていると 思いますので、ご利用の際は注意してください。また不備をみつけられましたら ご連絡ください。この注意書きを残していれば、自由に改変、再配布できる ものとします。 連絡先 http://mary.net.info.hiroshima-cu.ac.jp/cgi-bin/mailaccept.pl ----------------------------------------------------------------------- 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年の経験において得られた課題を収集したものである。この文書 はRFC2960からの差分を示し、時間(編年体)を基に構成されている。 課題は持ちあがってきた順序で挙げられている。いくつかの文章は 何度か変更されているため、文章の最後の差分を適用するべきであ る。差分に加えて、問題の記述と解決法の詳細も示す。 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 Stewart, et al. Informational [Page 1] RFC 4460 SCTP Errata April 2006 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 Stewart, et al. Informational [Page 2] RFC 4460 SCTP Errata April 2006 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 Stewart, et al. Informational [Page 3] RFC 4460 SCTP Errata April 2006 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 Stewart, et al. Informational [Page 4] RFC 4460 SCTP Errata April 2006 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 Stewart, et al. Informational [Page 5] RFC 4460 SCTP Errata April 2006 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 1. Introduction はじめに 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. 解決法の記述。 This document is a historical record of sequential changes what have been found necessary at various interop events and through discussion on this list. この文書はさまざまな相互接続(interop)イベントやこのリスト(メー リングリスト?)の議論を通して必要であることのわかった変更につ いて、変更順に履歴として残す記録である。 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. いくつかの文章は数回変更されているので、この文書のある文章に ついて最後の差分がRFC2960からの訂正となることに注意すること。 Stewart, et al. Informational [Page 6] RFC 4460 SCTP Errata April 2006 1.1. Conventions 1.1. 慣行事項 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]. この文書内にMUST、MUST NOT、REQUIRED、SHALL、SHALL NOT、 SHOULD、SHOULD NOT、RECOMMENDED、NOT RECOMMENDED、MAY、およ びOPTIONALというキーワードが出てきたときは、RFC 2119 [2]で記 述されているように解釈するものとする。 2. Corrections to RFC 2960 2. RFC2960への訂正 2.1. Incorrect Error Type During Chunk Processing. チャンク処理中の不正なエラー型 2.1.1. Description of the Problem 問題の記述 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]に素性が未知のチャンクを処理する際にとるアクショ ンを不正に指定している誤植がみつかった。 2.1.2. Text changes to the document 文書内の文章についての変更 --------- 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). --------- 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 - この認識できないチャンクを「認識できないチャンク型」に より報告する。 2.1.3. Solution Description 解決策の記述 The receiver of an unrecognized chunk should not send a 'parameter' error but instead should send the appropriate chunk error as described above. 認識できないチャンクの受信者は「パラーメータ」エラーを送るの ではなく、かわりに上述の適切なチャンクエラーを送るべきである。 2.2. Parameter Processing Issue パラメータ処理の問題 2.2.1. Description of the Problem 問題の記述 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ビットの使い方につい て、不正なカットアンドペーストにより誤植が含まれていた。 Stewart, et al. Informational [Page 7] RFC 4460 SCTP Errata April 2006 2.2.2. Text Changes to the Document 文書内の文章についての変更 --------- Old text: (Section 3.2.1) --------- 旧文章 00 - Stop processing this SCTP packet and discard it; do not process any further chunks within it. 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). --------- 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チャンクの処理を中止し破棄せよ、このチャンクにつ いてはこれ以上いかなるパラメータも処理しないこと。そしてこの 認識できなかったパラメータを「認識できないパラメータ型」によっ て(ERRORまたはINIT ACKに含めて)報告せよ。 2.2.3. Solution Description 解決策の記述 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に設定している場合、未知のチャンクまたはパラメー タのレベルで処理を止めたいという意図がある。従って、チャンク を処理中の場合はそのパケットを破棄するべきである。またパラメー タを処理中の場合は、そのチャンクを破棄すべきである。 2.3. Padding Issues パディングの問題 2.3.1. Description of the Problem 問題の記述 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ビット境界に 合っていなかった場合、最後のパディングがチャンク長に含まれて いるのかどうかについて混乱をまねく。 Stewart, et al. Informational [Page 8] RFC 4460 SCTP Errata April 2006 2.3.2. Text Changes to the Document 文書内の文章についての変更 --------- Old text: (Section 3.2) --------- 旧文章 Chunk Length: 16 bits (unsigned integer) 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. 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. --------- New text: (Section 3.2) --------- 新文章 Chunk Length: 16 bits (unsigned integer) 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. (変更はincludingの前にコンマが入った程度) 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バ イトの倍数の長さになるように全て0のバイトでパディングされる。 このパディングは合計で3バイトをこえてはならない(MUST NOT)。 チャンク長の値はチャンクの最後のパディングを含まない。しかし ながら、チャンクの最後のパラメータをのぞいて、いずれの可変長 パラメータのパディングも含むことになる。受信者はこのパディン グを無視しなければならない(MUST)。 Stewart, et al. Informational [Page 9] RFC 4460 SCTP Errata April 2006 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. (all zero bytesのあとにコンマが入った程度) 2.3.3. Solution Description 解決策の記述 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. 上記の文章は最後のパラメータのパディングがチャンク長フィール ドに含まれないことを明確にする。また最後以外のパラメータのパ ディングはチャンク長フィールドの値として計算に入れられること も明らかにする。 2.4. Parameter Types across All Chunk Types 全てのチャンク型にまたがるパラメータ型 2.4.1. Description of the Problem 問題の記述 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. 未知の、あるいは認識できないパラメータについて複数のエラーを 送る必要があるときに問題があることがわかった。エラー型はチャ ンク型フィールドをもたないことがよくあるので、どのエラーがど のチャンクに関するものかの判別が難しくなるかもしれない。 2.4.2. Text Changes to the Document 文書内の文章についての変更 --------- 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. --------- 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 Stewart, et al. Informational [Page 10] RFC 4460 SCTP Errata April 2006 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. パラメータ型は全てのチャンクの中で一意でなければならない (MUST)ことに注意。例えば、パラメータ型'5'がIPv4アドレス (3.3.2節を参照)を示すのに使われていたとする。このとき、値'5' は全てのチャンクに対してIPv4アドレスを示すものとして予約され、 他のチャンクにおいて異なった意味で再利用してはならない(MUST NOT)。 --------- Old text: (Section 13.2) --------- 旧文章 13.2 IETF-defined Chunk Parameter Extension 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: a) Name of the parameter type. 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. c) Detailed definition of each component of the parameter type. 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. --------- New text: (Section 13.2) --------- 新文章 13.2. IETF-defined Chunk Parameter Extension 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: (asの前にコンマが入った。) a) Name of the parameter type. 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. c) Detailed definition of each component of the parameter type. Stewart, et al. Informational [Page 11] RFC 4460 SCTP Errata April 2006 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. e) Each parameter type MUST be unique across all chunks. パラメータ型は全てのチャンクを通して一意でなければならない(MUST)。 2.4.3. Solution Description 解決策の記述 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になるということである。 2.5. Stream Parameter Clarification ストリームパラメータの明確化 2.5.1. Description of the problem 問題の記述 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の値で許された以上のストリームリソー スを要求することの正当性について仕様が明らかでなかったことに 問題があるとわかった。特に、INIT ACKのOS値として知らせる値が INITチャンクで受信したMIS値よりも大きい場合である。このふる まいはRFC 2960 [5]では記述されていないが不正である。 2.5.2. Text Changes to the Document 文書内の文章についての変更 --------- Old text: (Section 3.3.3) --------- 旧文章 Number of Outbound Streams (OS): 16 bits (unsigned integer) 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. Note: A receiver of an INIT ACK with the OS value set to 0 SHOULD destroy the association discarding its TCB. Stewart, et al. Informational [Page 12] RFC 4460 SCTP Errata April 2006 --------- New text: (Section 3.3.3) --------- 新文章 Number of Outbound Streams (OS): 16 bits (unsigned integer) 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チャンクで送られたMISの値より大きくてはならない(MUST NOT)。 Note: A receiver of an INIT ACK with the OS value set to 0 SHOULD destroy the association, discarding its TCB. 2.5.3. Solution Description 解決策の記述 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の値に指定しない ように変更するものである。 2.6. Restarting Association Security Issue アソシエーションの再開についてのセキュリティ上の問題 2.6.1. Description of the Problem 問題の記述 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の中に、あるアソシエーションの現在のアドレスのう ち一つ以上を自分のアドレスとともに列挙するだろう。これにより 通常の再開処理が起こり、侵入者はアソシエーションをハイジャッ クするだろう。 Stewart, et al. Informational [Page 13] RFC 4460 SCTP Errata April 2006 2.6.2. Text Changes to the Document 文書内の文章についての変更 --------- 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) 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. Stewart, et al. Informational [Page 14] RFC 4460 SCTP Errata April 2006 --------- 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 11 新しいアドレスを伴なうアソシエーションの再開 Cause Length: 16 bits (unsigned integer) 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. (空行が削除された) --------- New text: (Note no old text, new error cause added in section 3.3.10) --------- 新文章(旧文章は存在せず、新しいエラー原因コードが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). 新しいアドレスを伴なうアソシエーションの再開: 存在するアソシ エーションに対してINITを受信した。しかしこのINITはこのアソシ エーションに、以前にこのアソシエーションの一部ではなかった (NOT)アドレスを追加するものであった。このエラーは通常、INIT を拒否するABORTの一部として送られる(5.2節参照)。 Stewart, et al. Informational [Page 15] RFC 4460 SCTP Errata April 2006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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. --------- 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で応答しなければならない(MUST)。応答の際、端末は(自身が送っ た)元々のINITを送ったのと同じアドレスにINIT ACKを返送しなけ ればならない(MUST)。 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を受信した場合、形成しようとす るアソシエーションに一つも新しい(NEW)アドレスが追加されてい ないならば、端末は自分が送ったINITチャンクと同じパラメータ (初期化タグを変更せずに含む)を用いたINIT ACKで応答しなければ ならない(MUST)。INITメッセージが新しいアドレスをこのアソシエー ションに追加することを示している場合、このINITはまるごと破棄 しなければならず(MUST)、現存のアソシエーションにいかなる変更 も加えてはならない(NO)。応答として「新しいアドレスを伴うアソ シエーションの再開」エラーを含むかもしれないABORTを送るべき である(SHOULD)。このエラーは再開しようとするアソシエーション に追加されるアドレスを列挙すべきである(SHOULD)。 Stewart, et al. Informational [Page 16] RFC 4460 SCTP Errata April 2006 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とともに状態クッキー も生成するだろう。端末は状態クッキーを計算するために自身が送っ たINITのパラメータを用いる。 --------- Old text: (Section 5.2.2) --------- 旧文章 5.2.2 Unexpected INIT in States Other than CLOSED, COOKIE-ECHOED, COOKIE-WAIT and SHUTDOWN-ACK-SENT 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. 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. 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. --------- New text: (Section 5.2.2) --------- 新文章 5.2.2. Unexpected INIT in States Other Than CLOSED, COOKIE-ECHOED, COOKIE-WAIT, and SHUTDOWN-ACK-SENT 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 Stewart, et al. Informational [Page 17] RFC 4460 SCTP Errata April 2006 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 がアソシエーションに新しいアドレスを追加するものかを確認しな ければならない(MUST)。このアソシエーションに新しいアドレスを 追加するものだった場合、端末はこの予想外のINITの初期化タグを ABORTを含む送出パケットの認証タグにコピーし、ABORTで応答しな ければならない(MUST)。ABORT応答においては、エラー原因が「新 しいアドレスを伴なうアソシエーションの再起動」に設定されるか もしれない(MAY)。このエラーは再開しようとしたアソシエーショ ンに加えられるアドレスを列挙するべきである(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に応答する際、端末は現在の認証タグと相手の認証タグを状態 クッキーの中の予約された場所にコピーしなければならない(MUST)。 これらの場所を相手のタイタグ、およびローカルのタイタグとして 参照することにしよう。(以下、see Section 5.3.1の前に;が追加 された以外は同じ文章。) 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の送信後、(以降同じ、,が;にかわっただけ)。 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状態にある)では、タイタグは0(以前のTCBが存在しないこ とを示す)に設定されなければならない(MUST)。 2.6.3. Solution Description 解決策の記述 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以外の値に設定する状態を正しく説明するように変更し た。 Stewart, et al. Informational [Page 18] RFC 4460 SCTP Errata April 2006 2.7. Implicit Ability to Exceed cwnd by PMTU-1 Bytes cwndをPMTU-1バイト超過してしまう潜在的可能性 2.7.1. Description of the Problem 問題の記述 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値を十分に使いきらない(NOT)ようにみえ、cwndを決して 増加させないだろう。(訳注: cwndを越えないように強制する実装 があったが、それは不適切であるという指摘と思われる。) 2.7.2. Text Changes to the Document 文書内の文章についての変更 --------- 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. --------- 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. 送信者はcwndが現在は超過していない場合、新しい送信において (PMTU-1)バイトまでcwndを超過させてしまうかもしれない。 2.7.3. Solution Description 解決策の記述 The text changes make clear the ability to go over the cwnd value by no more than (PMTU-1) bytes. この文章における変更は、(PMTU-1)バイト以内でcwnd値を越えてし まう可能性を明らかにする。 2.8. Issues with Fast Retransmit 早期再送に関わる問題 2.8.1. Description of the Problem 問題の記述 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. 早期再送の現在の仕様にはいくつかの問題がみつかった。現在の言 いまわしは、GAP ACKブロックがSCTPの輻輳制御の働きにとって不 可欠であるにもかかわらず、その送信を必須としていなかった。仕 様は早期再送のサイクルをどう扱うかが不明であり、早期再送対象 としてマークしたTSNを再送するため、実装にcwndを待たせること となっていた。あるTSNを何回早期再送できるかという限度も設定 されていなかった。早期回復が記述されておらず、1往復のRTTに複 数のロスがあった場合に輻輳ウインドウを劇的に低下させてしまっ ていた。 Stewart, et al. Informational [Page 19] RFC 4460 SCTP Errata April 2006 2.8.2. Text Changes to the Document 文書内の文章についての変更 --------- 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. --------- 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. (最初の文のin whichの前にコンマ)(3文同じ)累積TSN確認応答フィー ルドにある値よりも大きなTSNを持つDATAチャンクの受信について は、いずれもGap Ack Blockフィールドで報告される(旧文章は SHOULD)。SCTP端末は現在の経路MTUの制限内で、ひとつのSACKチャ ンクに入るようにできるだけ多くのGap Ack Blockを報告しなけれ ばならない(MUST)。 --------- Old text: (Section 6.2.1) --------- 旧文章 D) Any time a SACK arrives, the endpoint performs the following: 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. 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. Stewart, et al. Informational [Page 20] RFC 4460 SCTP Errata April 2006 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. --------- New text: (Section 6.2.1) --------- 新文章 D) Any time a SACK arrives, the endpoint performs the following: 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. 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. 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に以前Gap Ack Blockにて受信確認されていた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確認応答が早期回復脱出ポイント(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. When the TSN(s) is reported as missing in the fourth consecutive SACK, the data sender shall: Stewart, et al. Informational [Page 21] RFC 4460 SCTP Errata April 2006 1) Mark the missing DATA chunk(s) for retransmission, 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. 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. 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. 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. 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. --------- 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. (indicatesのあとがthat節になった、およびSACK'sの誤植がなおった。) 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. 欠落の示唆(miss indications)はHTNA(新しく確認応答されたなか で最も高いTSN)アルゴリズムにしたがうべきである(SHOULD)。受け 取るSACKのそれぞれについて、SACKの中で新しく確認応答されたも ののうち最も高いTSNよりも前にある欠落TSNだけについて、欠落の 示唆を増加させる。新しく確認応答されたDATAチャンクとは以前に SACKで確認されていないものである。端末が早期回復状態にあり、 累積TSN確認応答ポイントを先に進めるSACKが到着した場合、この SACKで報告されている全ての欠落TSNについて欠落の示唆を増加さ せる。 Stewart, et al. Informational [Page 22] RFC 4460 SCTP Errata April 2006 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) 早期回復にない場合、(以下変更なし)。 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) (三文同じ)早期再送が実行中のとき、送信者はcwndの値を無視 すべき(SHOULD)であり、この1個のパケットの再送を遅らせるべき ではない(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. 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チャンクを早期再送されているとし、以降の早期再送 の対象とはならないようにマークする。早期再送により再送対象と マークされながらも、K個のTSNを運ぶデータグラムに入り切らなかっ た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はいずれ の宛先についても後続の早期回復イベントによって変更するべきで はない(SHOULD)。(すなわち、さらに後続の早期再送があろうとも cwndを減らすべきではない(SHOULD NOT)。) 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. 2.8.3. Solution Description 解決策の記述 The effect of the above wording changes are as follows: 上記の言い回しの変更による効果は以下の通りである: Stewart, et al. Informational [Page 23] RFC 4460 SCTP Errata April 2006 o It requires with a MUST the sending of GAP Ack blocks instead of the current RFC 2960 [5] SHOULD. o GAP Ack blocksの送信について、現在のRFC 2960 [5]における SHOULDのかわりにMUSTを要求としている。 o It allows a TSN being Fast Retransmitted (FR) to be sent only once via FR. 早期再送(FR)の対象となるTSNにはFRによる送信は一回のみ許可する。 o It ends the delay in waiting for the flight size to drop when a TSN is identified as being ready to FR. あるTSNについてFRの準備ができているとわかったとき、応答待ち のデータサイズが減るまで待つための遅延処理を終了させる。 o It changes the way chunks are marked during fast retransmit, so that only new reports are counted. 早期再送中のチャンクのマーク方法を、新しい報告のみを考慮する ように変更する。 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]). 1RTTの間に複数のロスがあったときに輻輳ウインドウの複数回の減 少を避けるために早期回復期間を設ける(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に似たモ デルに効率的に従わせるだろう。 2.9. Missing Statement about partial_bytes_acked Update partial_bytes_ackedの更新についての記述の欠如 2.9.1. Description of the Problem 問題の記述 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はその伝送レートを調節するために4つの制御変数 -- rwnd、 cwnd、ssthresh、およびpartial_bytes_acked -- を用いている。 SACKによるパケットロスの検知、あるいはあるアドレスについての T3-rtxタイマの期限切れにあたり、cwndおよびssthreshは7.2.3節 で述べられているように更新すべきである。しかしながら、同節は partial_bytes_ackedも同様に更新すべき、すなわち0にリセットす る必要があると明示すべきである。 2.9.2. Text Changes to the Document 文書内の文章についての変更 --------- Old text: (Section 7.2.3) --------- 旧文章 7.2.3 Congestion Control Upon detection of packet losses from SACK (see Section 7.2.4), An endpoint should do the following: ssthresh = max(cwnd/2, 2*MTU) cwnd = ssthresh Basically, a packet loss causes cwnd to be cut in half. When the T3-rtx timer expires on an address, SCTP should perform slow start by: Stewart, et al. Informational [Page 24] RFC 4460 SCTP Errata April 2006 ssthresh = max(cwnd/2, 2*MTU) cwnd = 1*MTU --------- New text: (Section 7.2.3) --------- 新文章 7.2.3. Congestion Control 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節参照)際、端末は早 期回復になければ以下を行うべきである: ssthresh = max(cwnd/2, 2*MTU) cwnd = ssthresh partial_bytes_acked = 0 (partial_bytes_ackedのリセットが追加された) Basically, a packet loss causes cwnd to be cut in half. When the T3-rtx timer expires on an address, SCTP should perform slow start by (コロン削除) ssthresh = max(cwnd/2, 2*MTU) cwnd = 1*MTU partial_bytes_acked = 0 (partial_bytes_ackedのリセットが追加された) 2.9.3. Solution Description 解決策の記述 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. 欠落していた文章の追加によって、ssthreshやcwndとともに partial_bytes_ackedも0にリセットすることで更新すべきであるこ とを明示し、7.2.3節で述べられているような状況で partial_bytes_ackedをどうするかという疑問を解決する。 2.10. Issues with Heartbeating and Failure Detection ハートビートと障害検出についての問題 2.10.1. Description of the Problem 問題の記述 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 現在の仕様はいつハートビートに応答すべきかについて明記していない。 Stewart, et al. Informational [Page 25] RFC 4460 SCTP Errata April 2006 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の中にある不 正確な言い回しにより大きな分散となってしまっている。 2.10.2. Text Changes to the Document 文書内の文章についての変更 --------- Old text: (Section 8.1) --------- 旧文章 8.1 Endpoint Failure Detection 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. 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. Stewart, et al. Informational [Page 26] RFC 4460 SCTP Errata April 2006 --------- New text: (Section 8.1) --------- 新文章 8.1. Endpoint Failure Detection 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チャン クを含む。(1文変更なし)さらに、端末は上位層に障害を報告し、 オプションとして送出キューに残っている確認応答を受けていない 全てのユーザデータを報告してもよい(MAY)。(1文同じ) The counter shall be reset each time a DATA chunk sent to that peer endpoint is acknowledged (by the reception of a SACK), or a HEARTBEAT-ACK is received from the peer endpoint. --------- Old text: (Section 8.3) --------- 旧文章 8.3 Path Heartbeat 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). --------- New text: (Section 8.3) --------- 新文章 8.3 Path Heartbeat 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 Stewart, et al. Informational [Page 27] RFC 4460 SCTP Errata April 2006 (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). (最初の文はshallをSHOULDに変更したのみ)HEARTBEATの送出は ESTABLISHED状態に至れば開始しても構わず(MAY)、SHUTDOWNまたは SHUTDOWN-ACKの送出のあとは停止する。HEARTBEATの受信者は COOKIE-ECHOED状態(INIT送信者側)あるいはESTABLISHED状態(INIT 受信者側)に入ったあとでSHUTDOWN-SENT状態(SHUTDOWN送信者側)あ るいはSHUTDOWN-ACK-SENT状態(SHUTDOWN受信者側)に至るまで、 HEARTBEAT-ACKをもって応答しなければならない(MUST)。 --------- 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. --------- 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の受信者は受信したHEARTBEATチャンクから変更なしにコ ピーすることにより、ハートビート情報TLVにその他の受信した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. --------- 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にプロトコルパラメータ'HB.interval'および RTO値のプラスマイナス50%のジッタを加えたもの、さらに前回の HEARTBEATに返答が得られなかった場合はRTOの指数バックオフを加 えたもの、その時間あたりに一つのHEARTBEATチャンクを送ること が推奨される。 2.10.3. Solution Description 解決策の記述 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, Stewart, et al. Informational [Page 28] RFC 4460 SCTP Errata April 2006 how to respond to a heartbeat with extra parameters, and it clarifies the error counting procedures for the association. 上記の文章は2.10.1節で述べた5つの問題にどう対処するかについ てガイダンスを提供する。特に表現の変更によって、いつハートビー トを開始し停止するのか、余計なパラメータがついたハートビート にどう返答するか、についてガイダンスを提供し、アソシエーショ ンについてエラーをカウントする手順を明らかにする。 2.11. Security interactions with firewalls ファイアウォールとの間のセキュリティ面での相互作用 2.11.1. Description of the Problem 問題の記述 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 のセキュリティに関する節に追加する。 2.11.2. Text Changes to the Document 文書内の文章についての変更 --------- New text: (no old text, new section added) --------- 新文章(対応する旧文章はなし、新しい節を加える) 11.4 SCTP Interactions with Firewalls 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は一つのパケット内で他のチャンクとバンドルして はならない(MUST NOT)、および(2)INITチャンクを含むパケットは 認証タグを0としなければならない(MUST)、という要件を重視する。 さらに、INITチャンクの受信者が他のチャンクとバンドルされた INITチャンクを含んで到着したパケットを静かに(silently)破棄す ることによりこれらのルールを強化しなければならない(MUST)よう に要求する。 --------- Old text: (Section 18) --------- 旧文章 18. Bibliography [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. [RFC1750] Eastlake, D. (ed.), "Randomness Recommendations for Security", RFC 1750, December 1994. Stewart, et al. Informational [Page 29] RFC 4460 SCTP Errata April 2006 [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. [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. [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. --------- New text: (Section 18) --------- 18. Bibliography [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. (5の前にスペースがあいた(typo?)) [RFC1750] Eastlake, D. (ed.), "Randomness Recommendations for Security", RFC 1750, December 1994. [RFC1858] Ziemba, G., Reed, D. and Traina P., "Security Considerations for IP Fragment Filtering", RFC 1858, October 1995. (新しく追加された文献) [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. [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. Stewart, et al. Informational [Page 30] RFC 4460 SCTP Errata April 2006 [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. 2.11.3. Solution Description 解決策の記述 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チャンクはどんな場合であれ他のチャンクとバ ンドルしてはならず、このルールに従わないパケットは静かに (silently)破棄することをはっきりさせる。(メモ: 最後から2番目 の"that"?) 2.12. Shutdown Ambiguity シャットダウンのあいまいさ 2.12.1. Description of the Problem 問題の記述 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の受信者がユーザデータの 受け入れ停止に失敗してしまうかもしれないという問題がある。 2.12.2. Text Changes to the Document 文書内の文章についての変更 --------- 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. 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. Stewart, et al. Informational [Page 31] RFC 4460 SCTP Errata April 2006 --------- 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. (shallがMUSTになった。untilの前にコンマが入った。) 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の送信者は一つ以上の DATAチャンクを含むパケットを受信するごとに即座にSHUTDOWNチャ ンクで応答し、またT2-shutdownタイマを再始動させねばならない (MUST)。SHUTDOWNチャンクだけでは受信したDATAチャンクの全てに ついての確認応答ができない場合(すなわち、累積TSNよりも大きな TSNが確認できており、TSNの順序にギャップが存在する場合)、ま たは重複したTSNを受信した場合は、SACKチャンクもまた送らなけ ればならない(MUST)。 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'を始動してもよい(MAY)。このタイマの期限切 れにおいては、送信者はABORTチャンクを送ることによりアソシエー ションを中断すべきである(SHOULD)。'T5-shutdown-guard'タイマ を使用する場合、推奨値である'RTO.Max'の5倍に設定すべきである (SHOULD)。 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タイマを始動させ、SHUTDOWN-ACK-SENT状態に入らなけ ればならない(MUST)。このタイマが切れた場合、この端末は SHUTDOWN ACKを再送しなければならない。 2.12.3. Solution Description 解決策の記述 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. 上記の文章はSHUTDOWNチャンクと組みあわせたときのSACKの使用法 を明らかにする。またSCTPシャットダウンの一連の手順に監視タイ マも追加することで、SHUTDOWNチャンクを誤って処理する受信者か ら処理を保護する。 2.13. Inconsistency in ABORT Processing ABORT処理についての矛盾 2.13.1. Description of the Problem 問題の記述 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ビット」の使いかたに ついて正しい指示を与えていないことがわかった。 Stewart, et al. Informational [Page 32] RFC 4460 SCTP Errata April 2006 2.13.2. Text changes to the document 文書内の文章についての変更 --------- Old text: (Section 8.5.1) --------- 旧文章 B) Rules for packet carrying 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. - 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. --------- New text: (Section 8.5.1) --------- 新文章 B) Rules for packet carrying 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. (shallをMUSTに変更。ifの前にコンマが入った。) - If the ABORT is sent in response to an OOTB packet, the endpoint MUST follow the procedure described in Section 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. ABORTの受信者は、パケットの認証タグフィールドが自身のタグに 一致するか、あるいは認証タグが相手のタグに設定されておりチャ ンクフラグにおいてTビットが設定されているかいずれかの場合、 このパケットを受けいれなければならない(MUST)。さもなければ、 受信者は静かにこのパケットを破棄し、それ以上のいかなるアクショ ンもとってはならない(MUST)。 2.13.3. Solution Description 解決策の記述 The above text change clarifies that the T bit must be set before an implementation looks for the peer's tag. 上記の文章変更は実装が相手のタグをさがす以前にTビットが設定 されていないといけないことを明らかにする。 Stewart, et al. Informational [Page 33] RFC 4460 SCTP Errata April 2006 2.14. Cwnd Gated by Its Full Use 輻輳ウインドウが十分に活用されない問題 2.14.1. Description of the Problem 問題の記述 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]。 2.14.2. Text Changes to the Document 文書内の文章についての変更 --------- 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. --------- 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を用いるべきであ る(SHOULD)。この制限は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. あるいは出力ルーチンによって送出されるパケットの数を厳密に制 限することによって適用してもよい(MAY)。 E) Then, the sender can send out as many new DATA chunks as Rule A and Rule B allow. E) そののち、送信者はルールAおよびルールBが許す限りできるだ け多くの新しいDATAチャンクを送出することができる。 Stewart, et al. Informational [Page 34] RFC 4460 SCTP Errata April 2006 --------- 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]. --------- 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確認応答ポイン トを先に進めており、かつデータ送信者が早期回復にない場合に限っ て、スロースタートアルゴリズムを用いてcwndを増加させなければ ならない(MUST)。これら3つの条件が満たされるときのみcwndを増 加させることができる。さもなければ、cwndは増加させてはならな い(MUST)。これらの条件が満たされる場合、cwndは多くとも1)今回 確認応答された前に応答待ちだったDATAチャンクの総量と2)宛先の 経路MTUの小さい方だけ増加させなければならない(MUST)。この上 限は[SAVAGE99]で概説されたACK-Splitting攻撃を防ぐものである。 --------- Old text: (Section 14) --------- 旧文章 14. Suggested SCTP Protocol Parameter Values 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 Stewart, et al. Informational [Page 35] RFC 4460 SCTP Errata April 2006 --------- New text: (Section 14) --------- 新文章 14. Suggested SCTP Protocol Parameter Values The following protocol parameters are RECOMMENDED: RTO.Initial - 3 seconds RTO.Min - 1 second RTO.Max - 60 seconds Max.Burst - 4 (Max.Burstを追加。) 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 2.14.3. Solution Description 解決策の記述 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の減少に適用させる。 2.15. Window Probes in SCTP SCTPにおけるウインドウ探査 2.15.1. Description of the Problem 問題の記述 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にしたと き、仕様は相手からのデータを受けつけ続けなければならないこと を暗示していた。これは間違いで明確化が必要である。 2.15.2. Text Changes to the Document 文書内の文章についての変更 --------- Old text: (Section 6.2) --------- 旧文章 The SCTP endpoint MUST always acknowledge the receipt of each valid DATA chunk. Stewart, et al. Informational [Page 36] RFC 4460 SCTP Errata April 2006 --------- 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. SCTP端末は受信したDATAチャンクが受信ウインドウ内にあるとき、 正当なDATAチャンクそれぞれの受領についてつねに確認応答をしな ければならない(MUST)。 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チャンクは いずれも破棄しなければならない(MUST)。新しい到達DATAチャンク がここまで受けとった最大のTSNよりも小さなTSNをもつ場合、受信 者は並びかえのために保持している中で最大のTSNを破棄し、新し く到達したDATAチャンクを受けいれるべきである(SHOULD)。いずれ の場合も、このようなDATAチャンクを破棄するならば、ここまでに 受信して受けいれたDATAチャンクだけを示す現在の受信ウンドウと ともにSACKを即座に返さなければならない。これらの破棄された DATAチャンクは受けいれられていないので、SACKに含めてはならな い(MUST NOT)。受信者はまたRFC 813で記述されているように受信 者のシリーウインドウシンドローム(SWS)を避けるために、受信ウ インドウを広告する際のアルゴリズムを持っていなければならない (MUST)。このアルゴリズムは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. Stewart, et al. Informational [Page 37] RFC 4460 SCTP Errata April 2006 --------- 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. (rwnd is 0のあとのコンマがセミコロンに。rule Bのあとにコンマ が入った。SACKがSACK'sに。) 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. 受信者の広告ウインドウサイズが0のとき、この探査(probe)をゼロ ウインドウ探査と呼ぶ。ゼロウインドウ探査を送るのは全ての送信 済みDATAチャンクが累積確認応答されており未確認のDATAチャンク がないときに限ることに注意すること。ゼロウインドウ探査はサポー トされていなければならない(MUST)。 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. 送信者がゼロウインドウ探査を行っている間に受信者から新しいパ ケットを受信しつづける場合、確認応答が得られなかった探査につ いてアソシーエションまたはいずれの宛先トランスポートアドレス のエラーカウンタも増やすべきではない。これは受信者が不定時間 だけウインドウを閉じておいても構わない(MAY)からである。ゼロ ウインドウを広告したときの受信者のふるまいについては6.2節を 参照のこと。送信者は受信者がウインドウを閉じたことを検知して から1 RTO経ったのちに最初のゼロウインドウ探査を送るべきであ り(SHOULD)、その後は探査間隔を指数的に増加させるべきである (SHOULD)。cwndを7.2.1節に従って調節するべきである(SHOULD)こ とにも注意。ゼロウインドウ探査は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チャンクを送るためのアルゴリ ズムを持っていなければならない(MUST)。このアルゴリズムはRFC 1122の4.2.3.4節に記述されているのに似たものになるだろう。 2.15.3. Solution Description 解決策の記述 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の条件がクリアされ るまで継続することを可能にする。 Stewart, et al. Informational [Page 38] RFC 4460 SCTP Errata April 2006 2.16. Fragmentation and Path MTU Issues パケット分割と経路MTUの問題 2.16.1. Description of the Problem 問題の記述 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にこのふるまいを制限するも のではない。 2.16.2. Text Changes to the Document 文書内の文章についての変更 --------- Old text: (Section 6.1) --------- 旧文章 6.9 Fragmentation and Reassembly 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. IMPLEMENTATION NOTE: In this error case, the Send primitive discussed in Section 10.1 would need to return an error to the upper layer. --------- New text: (Section 6.1) --------- 新文章 6.9. Fragmentation and Reassembly 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. (最初の文にitが入った。最後の文のmustがMUSTになった。) Stewart, et al. Informational [Page 39] RFC 4460 SCTP Errata April 2006 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. 注意: パケット分割をサポートする実装がその上位層に分割を無効 にする機構を利用可能にする場合、そのようにしてもよい。しかし ながらそうする場合は、分割をサポートしていない(NOT)実装と同 様に反応しなければならない(MUST)。すなわちその実装は現在の経 路MTU(P-MTU)を越える送信を拒否しなければならない(MUST)。 IMPLEMENTATION NOTE: In this error case, the Send primitive discussed in Section 10.1 would need to return an error to the upper layer. 2.16.3. Solution Description 解決策の記述 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を越える送信は拒否するという選択肢の提供を可 能にするだろう。 2.17. Initial Value of the Cumulative TSN Ack 累積TSN確認応答の初期値 2.17.1. Description of the Problem 問題の記述 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チャンクに入れるべき値 について明記していない。 2.17.2. Text Changes to the Document 文書内の文章についての変更 --------- Old text: (Section 3.3.4) --------- 旧文章 Cumulative TSN Ack: 32 bits (unsigned integer) This parameter contains the TSN of the last DATA chunk received in sequence before a gap. --------- New text: (Section 3.3.4) --------- 新文章 Cumulative TSN Ack: 32 bits (unsigned integer) 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から1を引いた値に設定する。 Stewart, et al. Informational [Page 40] RFC 4460 SCTP Errata April 2006 2.17.3. Solution Description 解決策の記述 This change clearly states what the initial value will be for a SACK sender. この変更はSACKの送信者が初期値をいくつにすべきかを明確に記述する。 2.18. Handling of Address Parameters within the INIT or INIT-ACK INITまたはINIT-ACKの中のアドレスパラメータの扱い 2.18.1. Description of the Problem 問題の記述 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に含まれるアドレスパラメータの扱いについての現 在の記述はその取り扱いを十分に記述していない。 2.18.2. Text Changes to the Document 文書内の文章についての変更 --------- 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. --------- 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. (最初の文はshallがMUSTになりaddress(es)がaddressesに(パラメータと送信元IPアドレスで必ず複数になるため)なった。二番目の文もtransport address(es)がaddressesになった。三番目の文は変更なし。) Stewart, et al. Informational [Page 41] RFC 4460 SCTP Errata April 2006 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) INITやINIT ACKチャンクはその中に含まれる正当なアドレスパ ラメータが既存のTCBを同定するならば、既に確立されたアソシエー ション(または現在確立処理中のもの)に属するものとして扱わなけ ればならない(MUST)。 2.18.3. Solution description 解決策の記述 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の中を調べる必要性を明 示する。これを行わない実装は(例えば)既に確立したアソシエーショ ンからの新しいアドレスを加えるINITチャンク(2.6節参照)や、 INITチャンクを送るのに使った宛先アドレスとは異なる送信元アド レスから送られてきたINIT ACKチャンクを認識することができない かもしれない。 2.19. Handling of Stream Shortages ストリーム不足の扱い 2.19.1. Description of the Problem 問題の記述 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スタックではなく上位層でなされるべきである。 2.19.2. Text Changes to the Document 文書内の文章についての変更 --------- Old text: --------- 旧文章 5.1.1 Handle Stream Parameters 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. 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. Stewart, et al. Informational [Page 42] RFC 4460 SCTP Errata April 2006 --------- New text: (Section 5.1.2) --------- 新文章 5.1.1. Handle Stream Parameters 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. (shallが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. (コロンの前までではshallがMUSTになった): 相手のMISが端末のOS より小さい、すなわち端末が設定したい出力ストリームの全てを相 手がサポートできないことを意味する場合、端末はMIS本の出力ス トリームを用いなければならず(MUST)、この不足を上位層に報告し てもよい(MAY)。上位層は資源不足が受けいれられない場合、アソ シエーションを中止するという選択をとることができる。 2.19.3. Solution Description 解決策の記述 The above changes take the decision to ABORT out of the realm of the SCTP stack and place it into the user's hands. 上記の変更はABORTの決断をSCTPスタックの管轄から外し、ユーザの手に委ねる。 2.20. Indefinite Postponement 不定の延期 2.20.1. Description of the Problem 問題の記述 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シーケンス番号をわりあてるため のガイダンスもこれらのメッセージの受領についてのガイダンスも 与えていない。これは潜在的に不定の延期につながるおそれがある。 2.20.2. Text Changes to the Document 文書内の文章についての変更 --------- 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. 6.2 Acknowledgement on Reception of DATA Chunks Stewart, et al. Informational [Page 43] RFC 4460 SCTP Errata April 2006 --------- 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. 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を割り当てるまで不定の延期をしないことを確実にしなければ ならない(MUST)。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実装においては、ある条 件においてはデッドロックに陥る可能性があるので、データが利用 可能でないときにこの操作をブロックすべきではない。 6.2. Acknowledgement on Receipt of DATA Chunks 2.20.3. Solution Description 解決策の記述 The above wording clarifies how TSNs SHOULD be assigned by the sender. 上記の言いまわしは送信者がTSNをどのように割り当てるべき (SHOULD)かについて明らかにする。 2.21. User-Initiated Abort of an Association ユーザによるアソシエーションの中止 2.21.1. Description of the Problem 問題の記述 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. アソシエーションを中止し、なぜアソシエーションが中止されたか を相手に教えることが上位層には不可能である。 2.21.2. Text changes to the document 文書内の文章についての変更 Some of the changes given here already include changes suggested in Section 2.6 of this document. ここでのいくつかの変更は、すでに本文書の2.6節で示された変更 を含む。 Stewart, et al. Informational [Page 44] RFC 4460 SCTP Errata April 2006 --------- 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) 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. Stewart, et al. Informational [Page 45] RFC 4460 SCTP Errata April 2006 --------- 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) 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.10節までだったエラー原因の解説が3.3.10.12までに増えた。) --------- New text: (Note: no old text, new error added in Section 3.3.10) --------- 新文章 (注意: 旧文章はなく、新しいエラーが3.3.10節に追加された) 3.3.10.12. User-Initiated Abort (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チャンクに含 まれているかもしれない(MAY)。上位層はSCTPが透過的に転送し相 手の上位層プロトコルまで届けられる(MAY)上位層中止理由を指定 することができる。 (訳注: 透過的＝SCTP層は解釈しない) Stewart, et al. Informational [Page 46] RFC 4460 SCTP Errata April 2006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=12 | Cause Length=Variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Upper Layer Abort Reason / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --------- Old text: (Section 9.1) --------- 旧文章 9.1 Abort of an Association 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. An endpoint MUST NOT respond to any received packet that contains an ABORT chunk (also see Section 8.4). An endpoint receiving an ABORT shall apply the special Verification Tag check rules described in Section 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 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. (最初の文はshallがMUSTになった。次の文は変更なし。)上位層の 要求によりアソシエーションを中止した場合、ユーザによる中止と いうエラー原因(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). An endpoint receiving an ABORT MUST apply the special Verification Tag check rules described in Section 8.5.1. (shallをMUSTに変更。) After checking the Verification Tag, the receiving endpoint MUST Stewart, et al. Informational [Page 47] RFC 4460 SCTP Errata April 2006 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. (最初の文の前のshallはMUSTに、後のshallはSHOULDに変更。) ABORTチャンクの中にユーザによる中止というエラー原因がある場 合、「上位層の中止理由(Upper Layer Abort Reason)」は(訳注: ABORT受信者の)上位層から利用可能であるべきである(SHOULD)。 --------- Old text: (Section 10.1) --------- 旧文章 D) Abort Format: ABORT(association id [, cause code]) -> result 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. Mandatory attributes: o association id - local handle to the SCTP association Optional attributes: o cause code - reason of the abort to be passed to the peer. --------- New text: (Section 10.1) --------- 新文章 D) Abort Format: ABORT(association id [, Upper Layer Abort Reason]) -> result (cause codeを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. (2文目のandの前にコンマが入った。あとは変更なし。) Mandatory attributes: o association id - Local handle to the SCTP association. (ピリオドがついた。) Stewart, et al. Informational [Page 48] RFC 4460 SCTP Errata April 2006 Optional attributes: o Upper Layer Abort Reason - Reason of the abort to be passed to the peer. o 上位層の中止理由 - 相手にわたす中止理由 None. (訳注： このNoneは残骸なので消すべきかと。) --------- Old text: (Section 10.2) --------- 旧文章 E) COMMUNICATION LOST notification 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. The following shall be passed with the notification: o association id - local handle to the SCTP association 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. The following may be passed with the notification: o data retrieval id - an identification used to retrieve unsent and unacknowledged data. o last-acked - the TSN last acked by that peer endpoint; o last-sent - the TSN last sent to that peer endpoint; --------- New text: (Section 10.2) --------- 新文章 E) COMMUNICATION LOST notification 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. The following shall be passed with the notification: o association id - Local handle to the SCTP association. (最後にピリオドが入った。) Stewart, et al. Informational [Page 49] RFC 4460 SCTP Errata April 2006 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のあとに空白が一個補足された。) The following may be passed with the notification: o data retrieval id - An identification used to retrieve unsent and unacknowledged data. (anが大文字で始まるようになった。) o last-acked - The TSN last acked by that peer endpoint. (theが大文字で始まるようになり、セミコロンでなくピリオドで終わるようになった。) o last-sent - The TSN last sent to that peer endpoint. (theが大文字で始まるようになり、セミコロンでなくピリオドで終わるようになった。) o Upper Layer Abort Reason - The abort reason specified in case of a user-initiated abort. o 上位層における中止理由 - ユーザによる中止の場合に指定される中止の理由。 2.21.3. Solution Description 解決策の記述 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. 上記は上位層に、なぜアソシエーションが中止されたかという理由 を相手に示せるようにする。それゆえ、エラー原因の追加がなされ た。 2.22. Handling of Invalid Initiate Tag of INIT-ACK INIT-ACKにおける不正な初期化タグの扱い 2.22.1. Description of the Problem 問題の記述 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は初期化タグを0としたINIT-ACKの受信者にこれをエラー として扱いABORTを送り返すように要求する。しかしINIT-ACKの送 信者は通常TCBを持っていないので、このABORTは有効でない。 2.22.2. Text Changes to the Document 文書内の文章についての変更 --------- Old text: (Section 3.3.3) --------- 旧文章 Initiate Tag: 32 bits (unsigned integer) 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. The Initiate Tag MUST NOT take the value 0. See Section 5.3.1 for more on the selection of the Initiate Tag value. Stewart, et al. Informational [Page 50] RFC 4460 SCTP Errata April 2006 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. --------- New text: (Section 3.3.3) --------- 新文章 Initiate Tag: 32 bits (unsigned integer) 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. The Initiate Tag MUST NOT take the value 0. See Section 5.3.1 for more on the selection of the Initiate Tag value. (以上、変更なし。) 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チャンクの中の初期化タグの値が0であることが わかった場合、受信者はそのTCBを破棄することにより、そのアソ シエーションを破壊しなければならない(MUST)。受信者はデバッグ の目的でABORTを送信してもよい(MAY)。 2.22.3. Solution Description 解決策の記述 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を送信することは許されている。 2.23. Sending an ABORT in Response to an INIT INITへの応答としてのABORTの送信 2.23.1. Description of the Problem 問題の記述 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ビットの値を使うべきかがはっきりと述べられていない。 2.23.2. Text Changes to the Document 文書内の文章についての変更 --------- 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, Stewart, et al. Informational [Page 51] RFC 4460 SCTP Errata April 2006 --------- 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, (最初の文のみ変更なし。)どんな理由であれ、このINITを正常に処 理できず応答としてABORTを送らなければならない場合、ABORTチャ ンクを含むパケットの認証タグは受信したINITチャンクの初期化タ グでなければならず(MUST)、ABORTチャンクのTビットはTCBが破壊 されたことを示す0に設定される必要がある。さもなければ、 2.23.3. Solution Description 解決策の記述 The new text stated clearly which value of the Verification Tag and T-bit have to be used. 新しい文章は認証タグ及びTビットとしてどんな値が使われるべき かを明確に記述している。 2.24. Stream Sequence Number (SSN) Initialization ストリームシーケンス番号(SSN)の初期化 2.24.1. Description of the Problem 問題の記述 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に初期化されな ければならないことを記述していない。 2.24.2. Text Changes to the Document 文書内の文章についての変更 --------- 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. --------- 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. (二文ともshallがMUSTになった。) Stewart, et al. Informational [Page 52] RFC 4460 SCTP Errata April 2006 2.24.3. Solution Description 解決策の記述 The 'shall' in the text is replaced by a 'MUST' to clearly state the required behavior. 要求されるふるまいを明確に記述するために'shall'は'MUST'に置きかえる。 2.25. SACK Packet Format SACKのパケットフォーマット 2.25.1. Description of the Problem 問題の記述 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がギャップAckブロックの数と重複TSNの数の両フィー ルドを含まなければならないことが明確でない。 2.25.2. Text Changes to the Document 文書内の文章についての変更 --------- Old text: (Section 3.3.4) --------- 旧文章 The SACK MUST contain the Cumulative TSN Ack and Advertised Receiver Window Credit (a_rwnd) parameters. --------- 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確認応答、受信側広告ウインドウ(a_rwnd)、ギャッ プAckブロックの数、および重複TSNの数の各フィールドを含まなけ ればならない(MUST)。 2.25.3. Solution Description 解決策の記述 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の数のフィールドを含むことがこれで明らかである。 2.26. Protocol Violation Error Cause プロトコル違反というエラー原因 2.26.1. Description of the Problem 問題の記述 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の送信によって破壊される。現在のところ、この中止につ いて理由を提示するために使えるエラー原因はいくつかしかなく、 全ての場合をカバーしていない。 Stewart, et al. Informational [Page 53] RFC 4460 SCTP Errata April 2006 2.26.2. Text Changes to the Document 文書内の文章についての変更 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) 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. Stewart, et al. Informational [Page 54] RFC 4460 SCTP Errata April 2006 --------- 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 13 プロトコル違反 Cause Length: 16 bits (unsigned integer) 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.10までだったのが、3.3.10.13までになった。) --------- New text: (Note: no old text; new error added in section 3.3.10) --------- 新文章(注意: 旧文章はない。新しいエラーが3.3.10節に追加された。) 3.3.10.13. Protocol Violation (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チャンクの中に含んでよい(MAY)。実装 はどんな種類のプロトコル違反を検知したかを記述する追加情報を 提供してもよい(MAY)。 Stewart, et al. Informational [Page 55] RFC 4460 SCTP Errata April 2006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=13 | Cause Length=Variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Additional Information / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.26.3. Solution Description 解決策の記述 An additional error cause has been defined that can be used by an endpoint to indicate a protocol violation of the peer. 端末が相手のプロトコル違反を示すために使える追加のエラー原因 が定義された。 2.27. Reporting of Unrecognized Parameters 認識できないパラメータの報告 2.27.1. Description of the Problem 問題の記述 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チャンクの中で報告する必要がある。 これはCOOKIE-ERRORチャンクとバンドルしたり、別に送ることもで きる。別に送られCOOKIE-ECHOの前に受信された場合、これはOOTB パケットとして扱われ、結果としてABORTチャンクを送出すること になる。そのため、アソシエーションは確立されないだろう。 2.27.2. Text Changes to the Document 文書内の文章についての変更 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. 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). 10 - Skip this parameter and continue processing. 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). Stewart, et al. Informational [Page 56] RFC 4460 SCTP Errata April 2006 --------- New text: (Section 3.2.1) --------- 新文書 00 - Stop processing this SCTP chunk and discard it; do not process any further parameters within this chunk. (コンマがセミコロンに。最後のitがthis chunkに。SCTP packetが SCTP chunkに、chunksがparametersになった。) 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. 11 - Skip this parameter and continue processing but report the unrecognized parameter in an 'Unrecognized Parameter Type', as described in 3.2.2. (ERRORあるいはINIT ACKで報告することになっていたのが、3.2.2 節で記述したように報告することにかわった。) --------- New text: (Note: no old text; clarification added in Section 3.2) --------- 新文章(注意：旧文書はなし。3.2節に説明が追加された。) 3.2.2. Reporting of Unrecognized Parameters 認識できないパラメータの報告 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チャンクに「認識できないパラメー タ」というパラメータを入れなければならない(MUST)。INITチャン クの受信者がアソシエーションを確立しようとしていない(NOT)場 合(例えば資源不足により)、報告は返送されないことに注意するこ と。 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-ACKチャンク への返答として送られるCOOKIE-ECHOチャンクとともに「認識でき ないパラメータ」エラー原因を含むERRORチャンクをバンドルする べきである(SHOULD)。INIT-ACKの受信者がCOOKIE-ECHOチャンクと このERRORチャンクをバンドルできない場合、ERRORチャンクは別に して送ってもよい(MAY)がCOOKIE-ACKを受信する前でなくてはなら ない(?)。 Note: Any time a COOKIE-ECHO is sent in a packet, it MUST be the first chunk. 注意: COOKIE-ECHOをパケットに入れて送るときはいつでも、最初 のチャンクとしなければならない(MUST)。 2.27.3. Solution Description 解決策の記述 The procedure of reporting unrecognized parameters has been described clearly. 認識できないパラメータの報告手順について明確に記述された。 Stewart, et al. Informational [Page 57] RFC 4460 SCTP Errata April 2006 2.28. Handling of IP Address Parameters IPアドレスパラメータの扱い 2.28.1. Description of the Problem 問題の記述 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]ではINITまたはINIT-ACKチャンクにおいて相手がIPv4 アドレスとIPv6アドレスを提示した場合に、IPv4アドレスまたは IPv6アドレスのいずれかをサポートしているSCTP端末がどのように 応答すべきかが明記されていない。 2.28.2. Text Changes to the Document 文書内の文章についての変更 --------- 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. --------- 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. (改行位置がかわったのみ。) 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アドレスを受けとった場合、その端末はサポートしてい るアドレスファミリに属するアドレス全てを用いなければならない (MUST)。サポートしていない方のアドレスは無視してよい(MAY)。 その端末はいかなる種類のエラー提示にも応答するべきではない (SHOULD NOT)。 2.28.3. Solution Description 解決策の記述 The procedure of handling IP address parameters has been described clearly. IPアドレスパラメータの扱いの手順が明確に記述された。 Stewart, et al. Informational [Page 58] RFC 4460 SCTP Errata April 2006 2.29. Handling of COOKIE ECHO Chunks When a TCB Exists TCBが存在するときのCOOKIE ECHOチャンクの扱い 2.29.1. Description of the Problem 問題の記述 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をもつがこのケースで一致が要 求される相手のタグについては何も知らないからである。 2.29.2. Text Changes to the Document 文書内の文章についての変更 --------- 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. D) ローカルのタグとリモートのタグが一致したとき、端末は COOKIE-ECHOED状態にあるならばESTABLISHED状態に入るべきである。 走っているかもしれないクッキータイマーはいずれも止め、COOKIE ACKを送るべきである。 2.29.3. Solution Description 解決策の記述 The procedure of handling of COOKIE-ECHO chunks when a TCB exists has been described clearly. TCBが存在するときのCOOKIE-ECHOチャンクの扱いについての手順が 明確に記述された。 2.30. The Initial Congestion Window Size 輻輳ウインドウの初期サイズ 2.30.1. Description of the Problem 問題の記述 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にも同じ更新が必要であろう。 Stewart, et al. Informational [Page 59] RFC 4460 SCTP Errata April 2006 2.30.2. Text Changes to the Document 文書内の文章についての変更 --------- 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)). (初期cwndが2*MTU以下から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. (maxの2番目の対象が2*MTUから4*MTUとなった。) --------- 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. (maxの2番目の対象が2*MTUから4*MTUとなった。) Stewart, et al. Informational [Page 60] RFC 4460 SCTP Errata April 2006 --------- Old text: (Section 7.2.3) --------- 旧文章 7.2.3. Congestion Control Upon detection of packet losses from SACK (see Section 7.2.4), an endpoint should do the following: ssthresh = max(cwnd/2, 2*MTU) cwnd = ssthresh Basically, a packet loss causes cwnd to be cut in half. When the T3-rtx timer expires on an address, SCTP should perform slow start by ssthresh = max(cwnd/2, 2*MTU) cwnd = 1*MTU --------- New text: (Section 7.2.3) --------- 新文章 7.2.3 Congestion Control Upon detection of packet losses from SACK (see Section 7.2.4), An endpoint should do the following: (anがAnになった(訳者注: 誤植?)) ssthresh = max(cwnd/2, 4*MTU) (2*MTUが4*MTUになった) cwnd = ssthresh Basically, a packet loss causes cwnd to be cut in half. When the T3-rtx timer expires on an address, SCTP should perform slow start by: (コロンがついた。) ssthresh = max(cwnd/2, 4*MTU) (2*MTUが4*MTUになった。) cwnd = 1*MTU 2.30.3. Solution Description 解決策の記述 The change to SCTP's initial congestion window will allow it to continue to maintain the same congestion control properties as TCP. SCTPの初期輻輳ウインドウについての変更はTCPと同じ輻輳制御機 能を維持しつづけることを可能とする。 Stewart, et al. Informational [Page 61] RFC 4460 SCTP Errata April 2006 2.31. Stream Sequence Numbers in Figures 図の中のストリームシーケンス番号 2.31.1. Description of the Problem 問題の記述 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に初期化されると明記されている。 RFC 2960 [5]の図にSSNが1から始まるものが2つある。 Stewart, et al. Informational [Page 62] RFC 4460 SCTP Errata April 2006 2.31.2. Text Changes to the Document 文書内の文章についての変更 --------- 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 Stewart, et al. Informational [Page 63] RFC 4460 SCTP Errata April 2006 --------- 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]--\ (シーケンス番号(Seq)が1から0に変更された。) (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] (Seqが1から0に変更された。) SACK [TSN Ack=init TSN_Z, /---- DATA Block=0] --------\ / [TSN=init TSN_Z +1, \/ Strm=0,Seq=1 & user data 2] (Seqが2から1に変更された。) <------/\ \ \------> Figure 4: INITiation Example Stewart, et al. Informational [Page 64] RFC 4460 SCTP Errata April 2006 --------- 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 Stewart, et al. Informational [Page 65] RFC 4460 SCTP Errata April 2006 --------- 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]--\ (Seqが1から0に変更された。) (Start T3-rtx timer) \ \-> /--- SACK [TSN Ack=init TSN_A,Block=0] (Cancel T3-rtx timer) <------/ Figure 5: A Restart Example Stewart, et al. Informational [Page 66] RFC 4460 SCTP Errata April 2006 2.31.3. Solution description 解決策の記述 Figure 4 and 5 were changed so that the SSN starts with 0 instead of 1. Figure 4と5のSSNが1からではなく0から始まるように変更された。 2.32. Unrecognized Parameters 認識できないパラメータ 2.32.1. Description of the Problem 問題の記述 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節において「認識できないパラメータ」というパラメー タにひとつあるいは複数の認識できないパラメータを含むかどうか を明確に記述していない。 2.32.2. Text Changes to the Document 文書内の文章についての変更 --------- 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 Parameter Length: Variable Size. Stewart, et al. Informational [Page 67] RFC 4460 SCTP Errata April 2006 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 Length: Variable Size. 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. (パラメータが含むものが認識できない複数のパラメータから認識できないひとつのパラメータに変更された。) 2.32.3. Solution Description 解決策の記述 The new text states clearly that only one unrecognized parameter is reported per parameter. 新しい文章は一つのパラメータあたりに認識できないパラメータは 一つしか報告されないことを明確に記述する。 2.33. Handling of Unrecognized Parameters 認識できないパラメータの扱い 2.33.1. Description of the Problem 問題の記述 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を送るべきか どうかが明確でない。 2.33.2. Text Changes to the Document 文書内の文章についての変更 Some of the changes given here already include changes suggested in Section 2.27 of this document. ここで示す変更のいくつかはすでに本文書の2.27節で示された変更を含む。 Stewart, et al. Informational [Page 68] RFC 4460 SCTP Errata April 2006 --------- Old text: (Section 3.2.1) --------- 旧文章 00 - Stop processing this SCTP packet and discard it, do not process any further chunks within it. 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). 10 - Skip this parameter and continue processing. 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). --------- 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 Type', as described in 3.2.2. 01 - このパラメータの処理を停止し、このチャンクの中のいかな るパラメータもさらに処理してならない。また3.2.2節で記述され ているように「認識できないパラメータ型」に入れて認識できない パラメータを報告する。 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. (ERRORまたはINIT ACKの中の、だったのが、3.2.2節で記述したよ うに、に変更された。) --------- New text: (Note: no old text; clarification added in section 3.2) --------- 新文章(注意: 旧文章はない。3.2節に説明が追加された。) 3.2.2. Reporting of Unrecognized Parameters 認識できないパラメータの報告 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 Stewart, et al. Informational [Page 69] RFC 4460 SCTP Errata April 2006 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チャンクの中に「認識できないパ ラメータ」というパラメータを入れなければならない(MUST)。INIT チャンクの受信者がアソシエーションを確立しようとしない(NOT) 場合(例えば資源不足により)、「認識できないパラメータ」はINIT の送信者へ送られるABORTには含まれない(NOT)であろうことに注意 すること。 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-ACKチャ ンクへの応答として送られるCOOKIE-ECHOチャンクとともに「認識 できないパラメータ」というエラー原因を含んだERRORチャンクを バンドルするべきである(SHOULD)。INIT-ACKの受信者が COOKIE-ECHOチャンクとERRORチャンクをバンドルできない場合、こ のERRORチャンクは別にして送られてもよい(MAY)がCOOKIE-ACKを受 信する前でなくてはならない(?)。 Note: Any time a COOKIE-ECHO is sent in a packet, it MUST be the first chunk. 注意: COOKIE-ECHOがパケットの中で送られるときはいつでも、パ ケット内で最初のチャンクでなければならない(MUST)。 2.33.3. Solution Description 解決策の記述 The procedure of handling unrecognized parameters has been described clearly. 認識できないパラメータの扱いについての手順が明確に記述された。 2.34. Tie Tags タイタグ 2.34.1. Description of the Problem 問題の記述 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に含まれることを要求する。クッキー は暗号化されないかもしれない。攻撃者はINITを送ったあとで受信 したクッキーを解析することで認証タグの値を知ることができるか もしれない。 2.34.2. Text Changes to the Document 文書内の文章についての変更 --------- 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 タイタグ: 2つの32ビットの乱数で64ビットの仮の語を形成する。 これらのタグは、新しく再起動するアソシエーションを、再起動し ておらずまだ既存のアソシエーションの本当の認証タグを明らかに していない端末の中で元々のアソシエーションと関連づけることが できるように、状態クッキーとTCBの中で用いられる。 Stewart, et al. Informational [Page 70] RFC 4460 SCTP Errata April 2006 --------- 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). --------- 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). COOKIE-ECHOED状態にある端末においては、アソシエーションのTCB および状態クッキーの両方の中にタイタグを含めなければならない (MUST)(タイタグの記述については5.2.2節を参照)。 --------- 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 Stewart, et al. Informational [Page 71] RFC 4460 SCTP Errata April 2006 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. (最初の文はreceptionがreceiptになった。shallがMUSTになった。) 送出するINIT ACKの中で、端末は現在のタイタグを状態クッキーの 中の予約された場所およびアソシエーションのTCBにコピーしなけ ればならない(MUST)。(次の文はinside the cookieが追加された。) アソシエーションTCBの中のコピーをローカルタグ、およびピアの タグと呼ぶ。(次の文は変更なし。)(次の文はseeの前にセミコロン が入った。) 2.34.3. Solution Description 解決策の記述 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. この問題への解決策は状態クッキーの中でタイタグとして本当の認 証タグを用いないことである。そのかわり、2つの32ビットの乱数 を生成し64ビットの仮の語を形成し、両方を状態クッキーおよび存 在するアソシエーションのTCBに格納する。これによりうっかり認 証タグをさらしてしまうことを防ぐ。 2.35. Port Number Verification in the COOKIE-ECHO COOKIE-ECHOにおけるポート番号の検証 2.35.1. Description of the Problem 問題の記述 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-ECHOを受けとったとき、端末はこれ らの値がアソシエーションの確立を始めたINITとINIT-ACKにみられ た元々の値と一致しているかどうか検証することができないだろう。 2.35.2. Text Changes to the Document 文書内の文章についての変更 --------- 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, 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. 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 Stewart, et al. Informational [Page 72] RFC 4460 SCTP Errata April 2006 5), if the SACK is bundled with the COOKIE ACK, the COOKIE ACK MUST appear first in the SCTP packet. --------- 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. (旧文章の3)から少し変更。discardedのあとにコンマが入った。最後がコンマからピリオドになった。) 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. (旧文章の4)から、and enterの前のコンマが外された。) 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. (旧文章の5)からreceptionがreceiptになっただけ。) 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. (旧文章の6)とほぼ同じ。5)が5になっただけ。(訳注: ひとつずれたので6にすべきでしょう。)) 2.35.3. Solution Description 解決策の記述 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-ECHOの処理の際に検証することで、この問題は解 決される。 Stewart, et al. Informational [Page 73] RFC 4460 SCTP Errata April 2006 2.36. Path Initialization パス(経路)の初期化 2.36.1. Description of the Problem 問題の記述 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. アソシエーションがESTABLISHED状態に入ったとき、端末は相手に よって提示された全てのアドレスが確かにその相手に属しているも のだという確証がない。これはいろんな形のサービス不能攻撃の原 因となり得る。 2.36.2. Text Changes to the Document 文書内の文章についての変更 --------- 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: アソシエーションの確立時、二つの端末はアドレスのリストを交換 する。たいていの場合、これらのリストはそれぞれの端末がもつア ドレスを正確に示している。しかしながら、不正を働く端末が自分 の持っていないアドレスを示すことがあり得る。これを防ぐため、 以下のルールを新しいアソシエーションの全てのアドレスに適用す る: 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) ルール1および2によってカバーされない他のすべてのアドレス は未確認(UNCONFIRMED)とみなし、検証のためのプロービング対象 となる。 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. 確認検証のためにあるアドレスをプロービングするには、端末は64 ビットの乱数値とパスを示すもの(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. HEARTBEAT-ACKの受信にあたり、HEARTBEATパラメータに含まれてい る値がHEARTBEATパラメータの中で示されているアドレスに送られ た値であることを確認する。これらが一致するとき、元々の HEARTBEATが送られたアドレスは確認された(CONFIRMED)とみなし、 通常のデータ転送に利用可能となる。 Stewart, et al. Informational [Page 74] RFC 4460 SCTP Errata April 2006 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. RTOごとに一つのプローブが、アクティブでUNCONFIRMEDなパスに対 しこれをCONFIRMEDに移行させる意図で送られる。このプロービン グの途中でパスがインアクティブになった場合、このプローブ頻度 は通常のHEARTBEATのものに引き下げられる。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の間に送られるHEARTBEATの数はHB.Max.Burstパラメータによ り制限されるべきである。パスの確認のためにハートビートを相手 のアドレスに対しいかにばらまくかについては実装にまかされてい る。 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. - 値を含んだHEARTBEATは未確認(UNCONFIRMED)のアドレスに送ってよい(MAY)。 (訳注)プロービング。 - A HEARTBEAT-ACK MAY be sent to an UNCONFIRMED address. - HEARTBEAT-ACKは未確認(UNCONFIRMED)のアドレスに送ってよい(MAY)。 - 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は未確認(UNCONFIRMED)アドレスに送ってもよい(MAY) が、値を含んだHEARTBEATとバンドルしなければならない(MUST)。 バンドリングをサポートしない(NOT)実装は未確認(UNCONFIRMED)の アドレスにCOOKIE-ACKを送ってはならない(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. - COOKIE-ECHO(訳注: 原文誤植)は未確認(UNCONFIRMED)アドレスに 送ってもよいが、値を含んだHEARTBEATとバンドルしなければなら ず(MUST)、またこのパケットは経路MTUを超えてはならない(MUST NOT)。実装がバンドリングをサポートしていない(NOT)場合、ある いはバンドルしたCOOKIE-ECHOとHEARTBEAT(値を含む)の合計が経路 MTUを超える場合、実装は未確認(UNCONFIRMED)のアドレスに COOKIE-ECHOを送ってはならない(MUST NOT)。 --------- Old text: (Section 14) --------- 旧文章 14. Suggested SCTP Protocol Parameter Values The following protocol parameters are RECOMMENDED: Stewart, et al. Informational [Page 75] RFC 4460 SCTP Errata April 2006 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 The following protocol parameters are RECOMMENDED: RTO.Initial - 3 seconds RTO.Min - 1 second RTO.Max - 60 seconds Max.Burst - 4 (Max.Burst追加。) 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 (HB.Max.Burst追加。) 2.36.3. Solution Description 解決策の記述 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による加速したプロービングを正しく 設定することにより、新しいアソシエーションは相手によって提示 された全てのアドレスがその相手に属しているかどうかを検証する ことができる。 2.37. ICMP Handling Procedures ICMPの扱いの手順 2.37.1. Description of the Problem 問題の記述 RFC 2960 does not describe how ICMP messages should be processed by an SCTP endpoint. RFC 2960はSCTP端末がICMPメッセージをどう処理すべきかを記述していない。 Stewart, et al. Informational [Page 76] RFC 4460 SCTP Errata April 2006 2.37.2. Text Changes to the Document 文書内の文章についての変更 -------- Old text: None -------- 旧文章: なし --------- New text --------- 新文章 11.5. Protection of Non-SCTP Capable Hosts. SCTPが利用可能でないホストの保護(注: おそらく文末のピリオドは不要) 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スタック はAppendix Cで記述されるICMP処理を実装しなければならない (MUST)。 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. SCTPスタックが複数の制御またはDATAチャンクを含んだひとつのパ ケットを受信し、このパケットの処理により応答として複数のチャ ンクを送る必要があるとき、応答するチャンクの送信者は2つ以上 のパケットを送ってはならない(MUST NOT)。バンドリングがサポー トされている場合、複数の応答チャンクがひとつのパケットに入る ならばひとつの応答パケットにバンドルしてよい(MAY)。バンドリ ングがサポートされていない場合、送信者は2つ以上の応答チャン クを送ってはならず(MUST NOT)、他の応答は破棄しなければならな い(MUST)。このルールはSACKチャンクには適用しないことに注意。 というのはSACKチャンクは元々DATAへの応答そのものであり、より 多くの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. INITを受信し複数のERRORパラメータを含むことにより応答として 大きなパケットを必要とするSCTPの実装は、INIT-ACKのサイズを削 減するためにいくつかあるいは全てのERRORパラメータを省略する ことにしてもよい(MAY)(自身の判断で)。COOKIEパラメータのサイ ズおよびINITの受信者が相手に提示するであろうアドレスの数の組 み合わせにより、INIT-ACKが元々のINITより大きくなることが常に あり得る。SCTPの実装はバイト増幅攻撃の可能性を削減するために INIT-ACKをできるだけ小さくするように試みるべきである(SHOULD)。 --------- Old text: None --------- 旧文章: なし Stewart, et al. Informational [Page 77] RFC 4460 SCTP Errata April 2006 --------- New text: (Appendix C) --------- 新文章 Appendix C ICMP Handling 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. SCTP端末はICMPメッセージを受信したときはいつでも、レイヤー3 から提供された情報を正しく活用することを保証するため、以下の 手順にしたがわなければならない(MUST)。 ICMP1) An implementation MAY ignore all ICMPv4 messages where the type field is not set to "Destination Unreachable". ICMP1) 実装は型フィールドが"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) 実装は型フィールドが"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) 実装はコードが"Protocol Unreachable(プロトコル到達不 可)"、"Fragmentation Needed(フラグメントが必要)"を示していな い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) 実装はコードが"Unrecognized next header type encountered(次ヘッダ型が認識できない)"でないならば"Parameter Problem(パラメータの問題)"型の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が応答している元のメッセージを送ったアソシエーショ ンを特定するために、実装はICMPメッセージ(V4またはV6)のペイロー ドを用いなければならない(MUST)。このアソシエーションがみつけ られない場合、実装はこの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メッセージに含まれる検証タグが相手の検証タ グと一致することを検証しなければならない(MUST)。認証タグが0 でなくかつ一致しない場合、このICMPメッセージは破棄する。認証 タグが0で、チャンク型がINITチャンクであり初期タグが相手のタ グと一致することを検証するのに十分なバイト数をICMPメッセージ が含んでいる場合、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 Stewart, et al. Informational [Page 78] RFC 4460 SCTP Errata April 2006 chunk and the association is in COOKIE-WAIT state, handle the ICMP message like an ABORT. ICMP8) ICMPのコードが"Unrecognized next header type encountered(次ヘッダ型が認識できない)"または"Protocol Unreachable(プロトコル到達不可)"の場合、実装はこのメッセージ がINITチャンクを含んでいなければTビットの設定された中止とし て扱わなければならない(MUST)。INITチャンクを含んでおりアソシ エーションがCOOKIE-WAIT状態にある場合、このICMPメッセージは 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. これらの処理はRFC 1122 [1]と異なり、そのポート到達不可メッセー ジの処理への要求と異なり、また実装が"protocol unreachable(プ ロトコル到達不可)"メッセージへの応答としてアソシエーションを 中止しなければならない(MUST)という要求とも異なることに注意す ること。実装はポート到達不可でなくABORTを送るだろうからポー ト到達不可メッセージは処理されない。"プロトコル到達不可"メッ セージのより厳格な取り扱いは、セキュリティを考慮してSCTPをサ ポートしない(NOT)ホストのためのものである。 2.37.3. Solution Description 解決策の記述 The new appendix now describes proper handling of ICMP messages in conjunction with SCTP. 新しい付録(appendix)がSCTPに関連してICMPメッセージの正しい取 り扱いを記述するようになった。 2.38. Checksum チェックサム 2.38.1. Description of the problem 問題の記述 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のコピー に適用することにより、全ての(ALL)変更(RFC 3309を含む)を含む 新しい"new"文書ができあがるようにする。 2.38.2. Text Changes to the Document 文書内の文章についての変更 --------- Old text: --------- 旧文章 6.8 Adler-32 Checksum Calculation 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. After the packet is constructed (containing the SCTP common header and one or more control or DATA chunks), the transmitter shall: Stewart, et al. Informational [Page 79] RFC 4460 SCTP Errata April 2006 1) Fill in the proper Verification Tag in the SCTP common header and initialize the checksum field to 0's. 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, 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: 1) Store the received Adler-32 checksum value aside, 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, 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. The default procedure for handling invalid SCTP packets is to silently discard them. --------- New text: --------- 新文章 6.8 CRC-32c Checksum Calculation 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. (Adler-32がCRC32cに変更された。) After the packet is constructed (containing the SCTP common header and one or more control or DATA chunks), the transmitter MUST (shall:がMUSTに変更された。) 1) fill in the proper Verification Tag in the SCTP common header and initialize the checksum field to '0's, (行頭が小文字になった。0'sは'0'sに訂正された。) 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 (行頭が小文字になった。Adler-32はCRC32cに変更された。refer to以下はカッコづけとなり、ピリオドがセミコロンとなり次の文に 接続する。appendix Bの内容はAdler-32からCRC32cに変更された。) 3) put the resultant value into the checksum field in the common header, and leave the rest of the bits unchanged. (行頭が小文字に変更された。) Stewart, et al. Informational [Page 80] RFC 4460 SCTP Errata April 2006 When an SCTP packet is received, the receiver MUST first check the CRC32c checksum as follows: (Adler-32がCRC32cに変更され、"as follows"が追加された。) 1) Store the received CRC32c checksum value aside. (Adler-32が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. (an Adler-32がa CRC32cに変更された。次文の冒頭であるAnd,が削除された。) 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. (Adler-32がCRC32cに変更された(2ヶ所)。If notがIf it is notに変更された。) The default procedure for handling invalid SCTP packets is to silently discard them. Any hardware implementation SHOULD be done in a way that is verifiable by the software. ハードウェア実装はソフトウェアによって検証可能な形でなされる べきである(SHOULD)。 --------- Old text: --------- 旧文章 Appendix B Alder 32 bit checksum calculation The Adler-32 checksum calculation given in this appendix is copied from [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. 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: & 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. Stewart, et al. Informational [Page 81] RFC 4460 SCTP Errata April 2006 #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; 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: --------- 新文章 (訳注: RFC3309の拙訳よりコピー) Appendix B CRC32c Checksum Calculation 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. マシンの通常のビットオーダの反対で解釈した値を「反射値 (reflected value)」と定義する。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]と似た処理手順を用い、ト ランスポートレベルの使用を反映するために修正した形で計算する。 Stewart, et al. Informational [Page 82] RFC 4460 SCTP Errata April 2006 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]。 (訳注: Petersonが大文字に。) 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ビットがそのバイト における最も低位の多項式係数となる。(このビット順序はときに 「鏡像の(mirrored)」または「反射の(reflected)」と呼ばれる [WILLIAMS93]。) CRC多項式は一貫性のある対応づけによってSCTP トランスポートレベルのバイト値に変換して戻すことになる。 (訳注: WilliamsがWILLIAMSになった。) 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). - トランスポートレベルのバイトストリームは多項式の値に対応づ ける。jバイトを含む0からN-1まで番号づけされたNバイトのPDUは オーダ8N-1の多項式M(x)の係数とみなし、バイトjのビット0は x^(8(N-j)-8)の係数となり、バイトjのビット7はx^(8(N-j)-1)の係 数となる。 (訳注: 行頭は大文字に訂正された。) <訳注> (具体例) バイト0 バイト1 ...... バイトj ... 83 67 84 0 1 0 1 0 0 1 1 0 1 0 0 0 0 1 1 0 1 0 1 0 1 0 0 8N-8 8N-7 ... 8N-1 8N-16 8N-15 ... 8N-9 8(N-j)-8 ... 8(N-j)-1 係数に対応するxの指数 - 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ビット列とみなす。 (訳注: 行頭は大文字に訂正された。) Stewart, et al. Informational [Page 83] RFC 4460 SCTP Errata April 2006 - 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チェック サム値である。 (訳注: 2文目の冒頭にTheが入った、byte 3とandの間にコンマが入った。) 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についての標準文書、教科書、およびベンダの 文書はしばしば別の記述に従っており、それによると長い除算 (long-division)アルゴリズムの余りを保持するのに用いるレジス タは全て1ではなく0に初期化されており、そしてメッセージの最初 の32ビットの補数がとられている。我々の記述で用いている長い除 算(long-division)は、最初の2^32との積と長い除算を一つの同時 処理として組みあわせるように指定している。こうしたアルゴリズ ム、そして64ビットより長いメッセージについては、二つの記述は 正確に等価である。この等価性が本文書の趣旨である(?)。 (訳注: so thatの前のコンマが除かれた。直後のtheの誤植が修正された。) 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ビットよりも短いメッセー ジを保護するために使われるかもしれない。 (訳注: このあとRFC3309から1段落とばされている。) 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. チェックサム処理の前に認証タグに対してアソシエーションの正当 性チェックをする方が、計算上有利になるかもしれない。というの は不正なタグはほとんどの場合、合わないチェックサムと同じ処理 をする結果となるからである。このテクニックの例外は、期限切れ のCOOKIE-ECHOはもちろんのこと、INITやいくつかの SHUTDOWN-COMPLETEの交換が該当する。これらの特別な場合の交換 では小さなパケットを用いなければならず、それはチェックサム計 算の影響を最小にするだろう。 --------- Old text: (Section 18) --------- 旧文章 18. Bibliography [ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End Network Path Properties", Proc. SIGCOMM'99, 1999. Stewart, et al. Informational [Page 84] RFC 4460 SCTP Errata April 2006 [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. [RFC1750] Eastlake, D. (ed.), "Randomness Recommendations for Security", RFC 1750, December 1994. [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. [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. [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. --------- New text: (Section 18, including changes from 2.11) --------- 新文章(18節、2.11の変更も含む) 18. Bibliography [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. [ITU32] ITU-T Recommendation V.42, "Error-correcting procedures for DCEs using asynchronous-to-synchronous conversion", Section 8.1.1.6.2, October 1996. (文献追加。) [PETERSON 1972] W. W. Peterson and E.J Weldon, Error Correcting Codes, 2nd Edition, MIT Press, Cambridge, Massachusetts. (文献追加。) [RFC1750] Eastlake, D., Ed., "Randomness Recommendations for Security", RFC 1750, December 1994. (Ed.の表記変更。) Stewart, et al. Informational [Page 85] RFC 4460 SCTP Errata April 2006 [RFC1858] Ziemba, G., Reed, D. and Traina P., "Security Considerations for IP Fragment Filtering", RFC 1858, October 1995. (文献追加。) [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. [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. [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. [WILLIAMS93] Williams, R., "A PAINLESS GUIDE TO CRC ERROR DETECTION ALGORITHMS" - Internet publication, August 1993, http://www.geocities.com/SiliconValley/Pines/ 8659/crc.htm. (文献追加。) 2.38.3. Solution Description 解決策の記述 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]からの変更を含む完全な変更のまとまりを加えるも のである。 2.39. Retransmission Policy 再送ポリシ 2.39.1. Description of the Problem 問題の記述 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]。 Stewart, et al. Informational [Page 86] RFC 4460 SCTP Errata April 2006 2.39.2. Text Changes to the Document 文書内の文章についての変更 --------- 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. --------- 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. (a chunkがa chunk that timed outに変更された。タイムアウトによる再送だけが異なるアクティブな宛先トランスポートアドレスに送られる。) --------- 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. (最初の文は再送のdataがdata that timed outに変更された。また次の文は再送にあたって、が、タイムアウトしたデータの再送にあたって、に変更された。) 2.39.3. Solution Description 解決策の記述 The above wording changes clarify that only timeout retransmissions should be sent to an alternate active destination. 上記の言いまわしの変更は、タイムアウトによる再送だけが別のア クティブな宛先に送られるべきであることを明確にする。 Stewart, et al. Informational [Page 87] RFC 4460 SCTP Errata April 2006 2.40. Port Number 0 ポート番号0 2.40.1. Description of the Problem 問題の記述 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において特別な意味(セマンティクス) をもっている。例えばsocket APIにおいては、ユーザが0を指定す ると、SCTPの実装はふさわしいポート番号をユーザのために選ぶ。 それゆえ、ポート番号0はワイヤ上では使うべきではない。 2.40.2. Text Changes to the Document 文書内の文章についての変更 --------- Old text: (Section 3.1) --------- 旧文章 Source Port Number: 16 bits (unsigned integer) 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. 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. --------- New text: (Section 3.1) --------- 新文章 Source Port Number: 16 bits (unsigned integer) 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. (2番目の文でand possiblyの前のコンマが削除された。あとは最後の文のみ追加。)ポート番号0は使ってはならない(MUST NOT)。 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. The port number 0 MUST NOT be used. (最後の文のみ追加。)ポート番号0は使ってはならない(MUST NOT)。 Stewart, et al. Informational [Page 88] RFC 4460 SCTP Errata April 2006 2.40.3. Solution Description 解決策の記述 It is clearly stated that the port number 0 is an invalid value on the wire. ポート番号0はネットワーク(ワイヤ)上では不正な値であることが 明らかに記述された。 2.41. T Bit Tビット 2.41.1. Description of the Problem 問題の記述 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節で記述された手順は必要な正確性を欠 いている。 2.41.2. Text Changes to the Document 文書内の文章についての変更 --------- 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. --------- 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ビットは送信者が相手に期待されている認証タグを入れた場合に0 に設定される。認証タグがおうむ返し(reflecting)されている場合 はTビットは1に設定しなければならない(MUST)。おうむ返しとは送っ た認証タグが受けとったものと同じであることをいう。 --------- 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. Stewart, et al. Informational [Page 89] RFC 4460 SCTP Errata April 2006 --------- 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ビットは送信者が相手に期待されている認証タグを入れた場合に0 に設定される。認証タグがおうむ返し(reflecting)されている場合 はTビットは1に設定しなければならない(MUST)。おうむ返しとは送っ た認証タグが受けとったものと同じであることをいう。 --------- 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, --------- 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. (最初の文は変更なし。)いかなる理由であれINITが正常に処理され ず応答としてABORTを送信する必要がある場合、ABORTチャンクを含 むパケットの認証タグは受信したINITチャンクの初期化タグでなけ ればならず(MUST)、ABORTチャンクのTビットは認証タグがおうむ返 しされていない(NOT)ことを示すように0に設定する必要がある。 --------- 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, Stewart, et al. Informational [Page 90] RFC 4460 SCTP Errata April 2006 --------- 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, (最後の文で、TCBがみつからないことを示す、が、認証タグがおう む返しされていることを示す、に変更された。) --------- 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. --------- 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. (最後から2番目の文で、TCBがみつからないことを示す、から、認 証タグがおうむ返しされていることを示す、に変更された。) --------- Old text: (Section 8.5.1) --------- 旧文章 B) Rules for packet carrying ABORT: Stewart, et al. Informational [Page 91] RFC 4460 SCTP Errata April 2006 - 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. - 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. --------- New text: (Section 8.5.1) --------- 新文章 B) Rules for packet carrying 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. (shallがMUSTに変更された。ifの前にコンマが入った。) - If the ABORT is sent in response to an OOTB packet, the endpoint MUST follow the procedure described in Section 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ビットが設定されていないならば、あるいは (OR)、認証タグフィールドが相手のタグに設定されていおりチャン クフラグにおいてTビットが設定されているならば、このパケット を受けいれなければならない(MUST)。さもなければ、受信者はこの パケットを静かに破棄しなければならず、これ以上のアクションは とってはならない(MUST)。 --------- Old text: (Section 8.5.1) --------- 旧文章 C) Rules for packet carrying SHUTDOWN COMPLETE: - 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. Stewart, et al. Informational [Page 92] RFC 4460 SCTP Errata April 2006 - 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. --------- New text: (Section 8.5.1) --------- 新文章 C) Rules for packet carrying SHUTDOWN COMPLETE: - 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を 保持している場合、宛先端末のタグを使わなければならず(MUST)、 Tビットを設定してはならない(MUST NOT)。TCBが存在しない場合に 限り送信者はSHUTDOWN ACKの中の認証タグを用いるべきであり、T ビットを設定しなければならない(MUST)。 - 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ビットが設定されていない場合、あるいは (OR)、認証タグフィールドが相手のタグに設定されておりチャンク フラグにおいてTビットが設定されている場合、このパケットを受 けいれるだろう。(後の2文は変更なし。) 2.41.3. Solution Description 解決策の記述 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ビットを受けとる際の手順も明確になった。 2.42. Unknown Parameter Handling 未知のパラメータの扱い 2.42.1. Description of the Problem 問題の記述 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を送るべきかどうかを 明確に述べていない。 2.42.2. Text Changes to the Document 文書内の文章についての変更 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節で示され た変更を含んでいる。 Stewart, et al. Informational [Page 93] RFC 4460 SCTP Errata April 2006 --------- Old text: (Section 3.2.1) --------- 旧文章 00 - Stop processing this SCTP packet and discard it do not process any further chunks within it. 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). 10 - Skip this parameter and continue processing. 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). --------- New text: (Section 3.2.1) --------- 新文章 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', as described in 3.2.2. 10 - Skip this parameter and continue processing. 11 - Skip this parameter and continue processing but report the unrecognized parameter in an 'Unrecognized Parameter', as described in 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. (2.33.2から追加された部分)これら4つのすべての場合においてINIT-ACKまたはCOOKIE-ECHOチャンクが送られることに注意してもらいたい。00あるいは01の場合、未知のパラメータのあとのパラメータの処理はキャンセルされるが、すでになされた処理は取り消さ(rolled back)ない。 Stewart, et al. Informational [Page 94] RFC 4460 SCTP Errata April 2006 --------- New text: (Note: no old text; clarification added in Section 3.2) --------- 新文章(注意: 旧文章はない。3.2節に説明が追加された。) 3.2.2. Reporting of Unrecognized Parameters 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. 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. Note: Any time a COOKIE-ECHO is sent in a packet, it MUST be the first chunk. (2.33.2からの変更なし。) 2.42.3. Solution Description 解決策の記述 The new text clearly states that an INIT-ACK or COOKIE-ECHO has to be sent. 新しい文章はINIT-ACKまたはCOOKIE-ECHOを送る必要があることを 明確に述べる。 2.43. Cookie Echo Chunk Cookie Echoチャンク 2.43.1. Description of the Problem 問題の記述 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をどう構 成するかについてはっきりしない。 2.43.2. Text Changes to the Document 文書内の文章についての変更 --------- 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. Stewart, et al. Informational [Page 95] RFC 4460 SCTP Errata April 2006 An implementation SHOULD make the cookie as small as possible to insure interoperability. --------- 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. An implementation SHOULD make the cookie as small as possible to ensure interoperability. (insureがensureに変更された。) 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 Echoは状態クッキーパラメータを含まない(NOT)。そ のかわり、状態クッキーのパラメータ値であるデータはCookie Echoのチャンク値になる。これにより実装は状態クッキーパラメー タの最初の2バイトを変更するだけでCookie Echoチャンクとするこ とができる。 2.43.3. Solution Description 解決策の記述 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バイトを書きかえただけの 状態クッキーパラメータに他ならないことを明らかにするための注 記を追加する。 2.44. Partial Chunks 部分チャンク 2.44.1. Description of the Problem 問題の記述 Section 6.10 of RFC 2960 [5] uses the notion of 'partial chunks' without defining it. RFC 2960 [5]の6.10節は定義することなく「部分チャンク(partial chunks)」という表記を用いている。 2.44.2. Text Changes to the Document 文書内の文章についての変更 --------- 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. (最初の文はそのまま。)部分チャンクとはSCTPパケットに完全に含 まれていないチャンクのことである。すなわち、SCTPパケットが小 さすぎて、チャンク長によって示されているチャンクの全てのバイ トを含むことができないことをいう。 Stewart, et al. Informational [Page 96] RFC 4460 SCTP Errata April 2006 2.44.3. Solution Description 解決策の記述 The new text adds a definition of 'partial chunks'. 新しい文章が「部分チャンク」の定義を追加する。 2.45. Non-unicast Addresses ユニキャストでないアドレス 2.45.1. Description of the Problem 問題の記述 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機能(訳注: IPアドレス を追加する機能)を用いることで、SCTPはアソシエーション確立後 にエニキャストアドレスをアソシエーションから削除することによ り、簡単にエニキャストINITを扱えるようになるはずである。 2.45.2. Text Changes to the Document 文書内の文章についての変更 --------- 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. The receiver of an OOTB packet MUST do the following: 1) If the OOTB packet is to or from a non-unicast address, silently discard the packet. Otherwise, --------- New 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 CRC32c check; see Section 6.8), but the receiver is not able to identify the association to which this packet belongs. (Adler-32がCRC32cに変更された。6.8節参照のところだけだったカッ コづけの範囲がi.e.のところまで拡大した。) 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, (受信者は〜べきである(SHOULD)、に変更された。) Stewart, et al. Informational [Page 97] RFC 4460 SCTP Errata April 2006 2.45.3. Solution Description 解決策の記述 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節には変更を加えていな いことに注意すること。というのはブロードキャストアドレスに応 答するとフラッディング攻撃につながる恐れがあり、実装者はこれ らの表現に慎重に注意を払うべきだからである。 2.46. Processing of ABORT Chunks ABORTチャンクの処理 2.46.1. Description of the Problem 問題の記述 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節はSCTP端末に、存在しないアソシエーショ ンについて受けとったABORTチャンクは静かに破棄するように要求 している。これは例えばCOOKIE-WAIT状態において何を意味するの かはっきりしない。それゆえ、INITへの応答として送られたABORT を処理すべきか静かに破棄すべきかが明らかでない。 2.46.2. Text Changes to the Document 文書内の文章についての変更 --------- 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. --------- 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がみつか らないABORT、に変更された。) 2.46.3. Solution Description 解決策の記述 It is now clearly stated that an ABORT chunk should be processed whenever a TCB is found. TCBがみつかったときはいつでもそのABORTチャンクは処理すべきで あることが明確に記述された。 Stewart, et al. Informational [Page 98] RFC 4460 SCTP Errata April 2006 2.47. Sending of ABORT Chunks ABORTチャンクの送信 2.47.1. Description of the Problem 問題の記述 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節はlistenしている端末がないときにはINITチャ ンクに対する応答としてABORTチャンクを送るように要求している。 ポートスキャンを困難にするために、これらのABORTをINITチャン クの送信者に受信されたくないと思う人もいるだろう。現在のとこ ろ、これを強制するにはINITチャンクを含むパケットあるいは ABORTチャンクを含むパケットを破棄するファイアウォールを用い るしかない。同じことが中間機器なしにできる方が望ましい。 2.47.2. Text Changes to the Document 文書内の文章についての変更 --------- 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. --------- 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. (ABORTチャンクによる応答について、MUSTがSHOULDに変更された。) 2.47.3. Solution Description 解決策の記述 The requirement of sending ABORT chunks is relaxed such that an implementation can decide not to send ABORT chunks. 実装がABORTチャンクを送信しないという決断を下せるようにABORT チャンクの送信についての要求が緩和された。 2.48. Handling of Supported Address Types Parameter サポートしているアドレス型というパラメータの扱い 2.48.1. Description of the Problem 問題の記述 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 Stewart, et al. Informational [Page 99] RFC 4460 SCTP Errata April 2006 within the INIT chunk indicate that more address types are supported than those listed in the 'Supported Address Types' parameter. INITチャンクの送信者はどのアドレスファミリをサポートしている かを示すために「サポートしているアドレス型」パラメータを含む ことができる。INITチャンクを含むパケットの送信元アドレスある いはINITチャンクの中に列挙されたアドレスが「サポートしている アドレス型」パラメータに挙げられているよりも多くのアドレス型 をサポートしていることを示していた場合、INITチャンクをどう処 理すべきかが明らかでない。 2.48.2. Text Changes to the Document 文書内の文章についての変更 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. --------- 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. (2.28.2からは変更なし。) 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. (2.28.2で追加された部分そのまま。) 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)。 2.48.3. Solution Description 解決策の記述 It is now clearly described how these Supported Address Types parameters with incorrect data should be handled. これらのサポートしているアドレス型というパラメータに正しくな いデータが付随した場合にどう扱うべきかが明らかに記述されるよ うになった。 Stewart, et al. Informational [Page 100] RFC 4460 SCTP Errata April 2006 2.49. Handling of Unexpected Parameters 予期しないパラメータの扱い 2.49.1. Description of the Problem 問題の記述 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チャンクに含まれていた場合、予 期しないパラメータとなる。 2.49.2. Text Changes to the Document 文書内の文章についての変更 --------- 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. --------- 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. 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チャンクの受信者はあとでCOOKIE-ACKチャンクに ERRORチャンクをバンドルしてもよい(MAY)。しかしながら制限を設 ける実装はこのINITチャンクへの応答としてABORTチャンクを送り 返してよい(MAY)。 Stewart, et al. Informational [Page 101] RFC 4460 SCTP Errata April 2006 --------- 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. --------- 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. (For exampleのあとにコンマが入った。) 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チャンクの受信者はCOOKIE-ECHOチャ ンクにERRORチャンクをバンドルしてもよい(MAY)。しかしながら制 限を設ける実装はこのINIT-ACKチャンクへの応答としてABORTチャ ンクを送り返してよい(MAY)。 2.49.3. Solution Description 解決策の記述 It is now stated how unexpected parameters should be processed. 予期しないパラメータをどう処理すべきかが記述された。 2.50. Payload Protocol Identifier ペイロードプロトコルの識別子 2.50.1. Description of the Problem 問題の記述 The current description of the payload protocol identifier does NOT highlight the fact that the field is NOT necessarily in network byte order. ペイロードプロトコルの識別子についての現在の記述は、このフィー ルドがネットワークバイトオーダとは限らない(NOT)ということを 強調していない(NOT)。 Stewart, et al. Informational [Page 102] RFC 4460 SCTP Errata April 2006 2.50.2. Text Changes to the Document 文書内の文章についての変更 --------- 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). The value 0 indicates no application identifier is specified by the upper layer for this payload data. --------- 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. (最後に2行の追加をのぞけば、as well as the peer application の前後にコンマが入っただけ。)SCTPの実装はこのフィールドに触 れないので、そのバイトオーダはビッグエンディアン(訳注: ネッ トワークバイトオーダ)とは限らない(NOT)。このフィールドのバイ トオーダを変換する責任は上位層にある。 The value 0 indicates that no application identifier is specified by the upper layer for this payload data. (indicatesのあとにthatが入った。) 2.50.3. Solution Description 解決策の記述 It is now explicitly stated that the upper layer is responsible for the byte order of this field. このフィールドのバイトオーダについては上位層に責任があること を明記した。 Stewart, et al. Informational [Page 103] RFC 4460 SCTP Errata April 2006 2.51. Karn's Algorithm カーンのアルゴリズム 2.51.1. Description of the Problem 問題の記述 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を間違えて計 測しないことを確実にするように十分に記述されていない。 2.51.2. Text Changes to the Document 文書内の文章についての変更 --------- 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) (packetsとpacketがchunksとchunkになった。a later instanceの 前にforが入った。) 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. 実装上の注意: TSN rのチャンクを用いてRTT計測を行うのは、rが 最初に送られてからr以下のTSNをもつチャンクがいずれも再送され ていない場合のみであるべきである。 2.51.3. Solution Description 解決策の記述 The above clarification adds an implementation note that will provide additional guidance in the application of Karn's algorithm. 上記の説明はカーンのアルゴリズムの適用における追加の手引を提 供する実装上の注意を加える。 2.52. Fast Retransmit Algorithm 早期再送アルゴリズム 2.52.1. Description of the Problem 問題の記述 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つの確認応答を用い ている。 Stewart, et al. Informational [Page 104] RFC 4460 SCTP Errata April 2006 2.52.2. Text Changes to the Document 文書内の文章についての変更 --------- Old text: --------- 旧文章 7.2.4 Fast Retransmit on Gap Reports 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. 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. --------- New text: --------- 新文章 7.2.4. Fast Retransmit on Gap Reports 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. 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 についてさらに2つの損失示唆(後続のSACKを通して計3つの損失報 告)を待つべきである(SHOULD)。 2.52.3. Solution Description 解決策の記述 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を同じように ふるまわせる。 3. Security Considerations セキュリティの考慮 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文書にとりこまれるならば、元々の文書に含 まれていたセキュリティ上の弱点を修正するべきである。 Stewart, et al. Informational [Page 105] RFC 4460 SCTP Errata April 2006 4. Acknowledgements 謝辞 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. 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に特別に感謝する。彼は実際max-burstについての仕事 で共著者になるべきだが、専門の事情により外れることとなった (?)。またわれわれはLyndon OngとPhil Conradに貴重な入力と多く の貢献をいただいたことに感謝したい。 5. IANA Considerations IANAにまつわる考慮事項 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文書への変更をすすめるものである。し たがって新しいエラーコードを挙げてはいるものの、本文書自体は これらの新しいコードを定義するものではない(NOT)。そのかわり BIS文書がRFC 2960 [5]への必要な変更を行い、そのIANAについて の節も変更を要するだろう。 6. Normative References 規範に従う参考文献 [1] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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, . Stewart, et al. Informational [Page 106] RFC 4460 SCTP Errata April 2006 [4] Caro, A., Amer, P., and R. Stewart, "Retransmission Schemes for End-to-end Failover with Transport Layer Multihoming", GLOBECOM, November 2004., . [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. [6] Stone, J., Stewart, R., and D. Otis, "Stream Control Transmission Protocol (SCTP) Checksum Change", RFC 3309, September 2002. Stewart, et al. Informational [Page 107] RFC 4460 SCTP Errata April 2006 Authors' Addresses 著者連絡先 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 EMail: ivan.arias-rodriguez@nokia.com 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 EMail: acaro@bbn.com URI: http://www.armandocaro.net Michael Tuexen Muenster Univ. of Applied Sciences Stegerwaldstr. 39 48565 Steinfurt Germany EMail: tuexen@fh-muenster.de Stewart, et al. Informational [Page 108] RFC 4460 SCTP Errata April 2006 Full Copyright Statement 著作権の完全な記述 (訳注: 原文のみが有効ですので注意してください。) 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. この文書およびここに含まれる情報は基本的にそのままの("AS IS")状態で提供され、「貢献者、彼または彼女が代表する組織ある いは彼または彼女に資金を援助する組織(もしあれば)、The Internet Society、The IETF Trust、およびInternet Engineering Task Forceは、明示しているか暗示しているかに関わらず一切の保 証を放棄する。この保証にはここにある情報を用いることで特定の 目的のために商品性や適応性に関するどんな権利もどんな暗示的な 保証も侵害しないというような保証を含むがそれに限らない。」 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. この文書で記述された技術の実装や使用、またはライセンスが利用 可能あるいは不可能となる拡張に付随すると主張するかもしれない 知的財産権またはその他の権利の正当性や範囲に関してはいかなる 立場もとらない。またこのような権利を識別するためにそれぞれ独 立した努力を払うということを示すわけでもない。RFC文書におけ る権利に関する手続きの情報はBCP 78および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はこの標準を実装するために必要となるかもしれない技術をカ バーするような著作権、特許または特許応用、あるいは他の財産権 に注意を払ってくれる興味をもった団体を招いている。 ietr-ipr@ietr.orgのアドレスにIETFへのそのような情報を提供し ていただきたい。 Acknowledgement 謝辞 Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). RFC編集者職務への資金提供は、IASA( The IETF Administrative Support Activity)による。 Stewart, et al. Informational [Page 109]