RFC4460 日本語訳
4460 Stream Control Transmission Protocol (SCTP) Specification Errataand Issues. R. Stewart, I. Arias-Rodriguez, K. Poon, A. Caro, M.Tuexen. April 2006. (Format: TXT=215405 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループR.スチュワートの要求をネットワークでつないでください: 4460年のシスコシステムズInc.カテゴリ: 応用科学2006年4月の情報のI.のケアロBBN技術M.Tuexen Muenster AriasロドリゲスノキアリサーチセンターK.ヤラボサン・マイクロシステムズ・インクA.大学
Stream Control Transmission Protocol (SCTP) Specification
Errata and Issues
ストリーム制御伝動プロトコル(SCTP)仕様誤字と問題
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
This document is a compilation of issues found during six interoperability events and 5 years of experience with implementing, testing, and using Stream Control Transmission Protocol (SCTP) along with the suggested fixes. This document provides deltas to RFC 2960 and is organized in a time-based way. The issues are listed in the order they were brought up. Because some text is changed several times, the last delta in the text is the one that should be applied. In addition to the delta, a description of the problem and the details of the solution are also provided.
このドキュメントは提案されたフィックスに伴うStream Control Transmissionプロトコル(SCTP)を実装して、テストして、使用するのに6つの相互運用性イベントと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
1. 序論…6 1.1. コンベンション…7 2. RFC2960への修正…7 2.1. 塊処理の間の不正確な誤りタイプ。 ..............7 2.1.1. 問題の記述…7 2.1.2. テキストはドキュメントに変化します…7 2.1.3. ソリューション記述…7
Stewart, et al. Informational [Page 1] RFC 4460 SCTP Errata April 2006
スチュワート、他 [1ページ]情報のRFC4460SCTP誤字2006年4月
2.2. Parameter Processing Issue .................................7
2.2.1. Description of the Problem ..........................7
2.2.2. Text Changes to the Document ........................8
2.2.3. Solution Description ................................8
2.3. Padding Issues .............................................8
2.3.1. Description of the Problem ..........................8
2.3.2. Text Changes to the Document ........................9
2.3.3. Solution Description ...............................10
2.4. Parameter Types across All Chunk Types ....................10
2.4.1. Description of the Problem .........................10
2.4.2. Text Changes to the Document .......................10
2.4.3. Solution Description ...............................12
2.5. Stream Parameter Clarification ............................12
2.5.1. Description of the problem .........................12
2.5.2. Text Changes to the Document .......................12
2.5.3. Solution Description ...............................13
2.6. Restarting Association Security Issue .....................13
2.6.1. Description of the Problem .........................13
2.6.2. Text Changes to the Document .......................14
2.6.3. Solution Description ...............................18
2.7. Implicit Ability to Exceed cwnd by PMTU-1 Bytes ...........19
2.7.1. Description of the Problem .........................19
2.7.2. Text Changes to the Document .......................19
2.7.3. Solution Description ...............................19
2.8. Issues with Fast Retransmit ...............................19
2.8.1. Description of the Problem .........................19
2.8.2. Text Changes to the Document .......................20
2.8.3. Solution Description ...............................23
2.9. Missing Statement about partial_bytes_acked Update ........24
2.9.1. Description of the Problem .........................24
2.9.2. Text Changes to the Document .......................24
2.9.3. Solution Description ...............................25
2.10. Issues with Heartbeating and Failure Detection ...........25
2.10.1. Description of the Problem ........................25
2.10.2. Text Changes to the Document ......................26
2.10.3. Solution Description ..............................28
2.11. Security interactions with firewalls .....................29
2.11.1. Description of the Problem ........................29
2.11.2. Text Changes to the Document ......................29
2.11.3. Solution Description ..............................31
2.12. Shutdown Ambiguity .......................................31
2.12.1. Description of the Problem ........................31
2.12.2. Text Changes to the Document ......................31
2.12.3. Solution Description ..............................32
2.13. Inconsistency in ABORT Processing ........................32
2.13.1. Description of the Problem ........................32
2.13.2. Text changes to the document ......................33
2.13.3. Solution Description ..............................33
2.2. パラメタ処理問題…7 2.2.1. 問題の記述…7 2.2.2. テキストはドキュメントに変化します…8 2.2.3. ソリューション記述…8 2.3. 問題を水増しします…8 2.3.1. 問題の記述…8 2.3.2. テキストはドキュメントに変化します…9 2.3.3. ソリューション記述…10 2.4. パラメタは横切ってすべての塊タイプをタイプします…10 2.4.1. 問題の記述…10 2.4.2. テキストはドキュメントに変化します…10 2.4.3. ソリューション記述…12 2.5. パラメタ明確化を流してください…12 2.5.1. 問題の記述…12 2.5.2. テキストはドキュメントに変化します…12 2.5.3. ソリューション記述…13 2.6. 協会安全保障問題を再開します…13 2.6.1. 問題の記述…13 2.6.2. テキストはドキュメントに変化します…14 2.6.3. ソリューション記述…18 2.7. PMTU-1 BytesによるExceed cwndへの内在しているAbility…19 2.7.1. 問題の記述…19 2.7.2. テキストはドキュメントに変化します…19 2.7.3. ソリューション記述…19 2.8. 速いことの問題は再送されます…19 2.8.1. 問題の記述…19 2.8.2. テキストはドキュメントに変化します…20 2.8.3. ソリューション記述…23 2.9. 部分的な_バイト_acked Updateの周りのなくなったStatement…24 2.9.1. 問題の記述…24 2.9.2. テキストはドキュメントに変化します…24 2.9.3. ソリューション記述…25 2.10. Heartbeatingの問題と失敗検出…25 2.10.1. 問題の記述…25 2.10.2. テキストはドキュメントに変化します…26 2.10.3. ソリューション記述…28 2.11. ファイアウォールとのセキュリティ相互作用…29 2.11.1. 問題の記述…29 2.11.2. テキストはドキュメントに変化します…29 2.11.3. ソリューション記述…31 2.12. 閉鎖のあいまいさ…31 2.12.1. 問題の記述…31 2.12.2. テキストはドキュメントに変化します…31 2.12.3. ソリューション記述…32 2.13. アボート処理における矛盾…32 2.13.1. 問題の記述…32 2.13.2. テキストはドキュメントに変化します…33 2.13.3. ソリューション記述…33
Stewart, et al. Informational [Page 2] RFC 4460 SCTP Errata April 2006
スチュワート、他 [2ページ]情報のRFC4460SCTP誤字2006年4月
2.14. Cwnd Gated by Its Full Use ...............................34
2.14.1. Description of the Problem ........................34
2.14.2. Text Changes to the Document ......................34
2.14.3. Solution Description ..............................36
2.15. Window Probes in SCTP ....................................36
2.15.1. Description of the Problem ........................36
2.15.2. Text Changes to the Document ......................36
2.15.3. Solution Description ..............................38
2.16. Fragmentation and Path MTU Issues ........................39
2.16.1. Description of the Problem ........................39
2.16.2. Text Changes to the Document ......................39
2.16.3. Solution Description ..............................40
2.17. Initial Value of the Cumulative TSN Ack ..................40
2.17.1. Description of the Problem ........................40
2.17.2. Text Changes to the Document ......................40
2.17.3. Solution Description ..............................41
2.18. Handling of Address Parameters within the INIT or
INIT-ACK .................................................41
2.18.1. Description of the Problem ........................41
2.18.2. Text Changes to the Document ......................41
2.18.3. Solution description ..............................42
2.19. Handling of Stream Shortages .............................42
2.19.1. Description of the Problem ........................42
2.19.2. Text Changes to the Document ......................42
2.19.3. Solution Description ..............................43
2.20. Indefinite Postponement ..................................43
2.20.1. Description of the Problem ........................43
2.20.2. Text Changes to the Document ......................43
2.20.3. Solution Description ..............................44
2.21. User-Initiated Abort of an Association ...................44
2.21.1. Description of the Problem ........................44
2.21.2. Text changes to the document ......................44
2.21.3. Solution Description ..............................50
2.22. Handling of Invalid Initiate Tag of INIT-ACK .............50
2.22.1. Description of the Problem ........................50
2.22.2. Text Changes to the Document ......................50
2.22.3. Solution Description ..............................51
2.23. Sending an ABORT in Response to an INIT ..................51
2.23.1. Description of the Problem ........................51
2.23.2. Text Changes to the Document ......................51
2.23.3. Solution Description ..............................52
2.24. Stream Sequence Number (SSN) Initialization ..............52
2.24.1. Description of the Problem ........................52
2.24.2. Text Changes to the Document ......................52
2.24.3. Solution Description ..............................53
2.25. SACK Packet Format .......................................53
2.25.1. Description of the Problem ........................53
2.25.2. Text Changes to the Document ......................53
2.14. 完全利用で外出を禁止されたCwnd…34 2.14.1. 問題の記述…34 2.14.2. テキストはドキュメントに変化します…34 2.14.3. ソリューション記述…36 2.15. 窓はSCTPで調べられます…36 2.15.1. 問題の記述…36 2.15.2. テキストはドキュメントに変化します…36 2.15.3. ソリューション記述…38 2.16. 断片化と経路MTU問題…39 2.16.1. 問題の記述…39 2.16.2. テキストはドキュメントに変化します…39 2.16.3. ソリューション記述…40 2.17. 累積しているTSN Ackの値に頭文字をつけてください…40 2.17.1. 問題の記述…40 2.17.2. テキストはドキュメントに変化します…40 2.17.3. ソリューション記述…41 2.18. アドレスパラメタはイニットかイニット-ACKの中で扱われます…41 2.18.1. 問題の記述…41 2.18.2. テキストはドキュメントに変化します…41 2.18.3. ソリューション記述…42 2.19. ストリーム不足の取り扱い…42 2.19.1. 問題の記述…42 2.19.2. テキストはドキュメントに変化します…42 2.19.3. ソリューション記述…43 2.20. 無期延期…43 2.20.1. 問題の記述…43 2.20.2. テキストはドキュメントに変化します…43 2.20.3. ソリューション記述…44 2.21. 協会のユーザによって開始されたアボート…44 2.21.1. 問題の記述…44 2.21.2. テキストはドキュメントに変化します…44 2.21.3. ソリューション記述…50 2.22. イニット-ACKの無効の開始タグの取り扱い…50 2.22.1. 問題の記述…50 2.22.2. テキストはドキュメントに変化します…50 2.22.3. ソリューション記述…51 2.23. イニットに対応してアボートを送ります…51 2.23.1. 問題の記述…51 2.23.2. テキストはドキュメントに変化します…51 2.23.3. ソリューション記述…52 2.24. 一連番号(SSN)初期設定を流してください…52 2.24.1. 問題の記述…52 2.24.2. テキストはドキュメントに変化します…52 2.24.3. ソリューション記述…53 2.25. パケット・フォーマットを略奪してください…53 2.25.1. 問題の記述…53 2.25.2. テキストはドキュメントに変化します…53
Stewart, et al. Informational [Page 3] RFC 4460 SCTP Errata April 2006
スチュワート、他 [3ページ]情報のRFC4460SCTP誤字2006年4月
2.25.3. Solution Description ..............................53
2.26. Protocol Violation Error Cause ...........................53
2.26.1. Description of the Problem ........................53
2.26.2. Text Changes to the Document ......................54
2.26.3. Solution Description ..............................56
2.27. Reporting of Unrecognized Parameters .....................56
2.27.1. Description of the Problem ........................56
2.27.2. Text Changes to the Document ......................56
2.27.3. Solution Description ..............................57
2.28. Handling of IP Address Parameters ........................58
2.28.1. Description of the Problem ........................58
2.28.2. Text Changes to the Document ......................58
2.28.3. Solution Description ..............................58
2.29. Handling of COOKIE ECHO Chunks When a TCB Exists .........59
2.29.1. Description of the Problem ........................59
2.29.2. Text Changes to the Document ......................59
2.29.3. Solution Description ..............................59
2.30. The Initial Congestion Window Size .......................59
2.30.1. Description of the Problem ........................59
2.30.2. Text Changes to the Document ......................60
2.30.3. Solution Description ..............................61
2.31. Stream Sequence Numbers in Figures .......................62
2.31.1. Description of the Problem ........................62
2.31.2. Text Changes to the Document ......................63
2.31.3. Solution description ..............................67
2.32. Unrecognized Parameters ..................................67
2.32.1. Description of the Problem ........................67
2.32.2. Text Changes to the Document ......................67
2.32.3. Solution Description ..............................68
2.33. Handling of Unrecognized Parameters ......................68
2.33.1. Description of the Problem ........................68
2.33.2. Text Changes to the Document ......................68
2.33.3. Solution Description ..............................70
2.34. Tie Tags .................................................70
2.34.1. Description of the Problem ........................70
2.34.2. Text Changes to the Document ......................70
2.34.3. Solution Description ..............................72
2.35. Port Number Verification in the COOKIE-ECHO ..............72
2.35.1. Description of the Problem ........................72
2.35.2. Text Changes to the Document ......................72
2.35.3. Solution Description ..............................73
2.36. Path Initialization ......................................74
2.36.1. Description of the Problem ........................74
2.36.2. Text Changes to the Document ......................74
2.36.3. Solution Description ..............................76
2.37. ICMP Handling Procedures .................................76
2.37.1. Description of the Problem ........................76
2.37.2. Text Changes to the Document ......................77
2.25.3. ソリューション記述…53 2.26. 違反誤り原因について議定書の中で述べてください…53 2.26.1. 問題の記述…53 2.26.2. テキストはドキュメントに変化します…54 2.26.3. ソリューション記述…56 2.27. 認識されていないパラメタについて報告します…56 2.27.1. 問題の記述…56 2.27.2. テキストはドキュメントに変化します…56 2.27.3. ソリューション記述…57 2.28. IPアドレスパラメタの取り扱い…58 2.28.1. 問題の記述…58 2.28.2. テキストはドキュメントに変化します…58 2.28.3. ソリューション記述…58 2.29. TCBであるときに、クッキーエコー塊の取り扱いは存在しています…59 2.29.1. 問題の記述…59 2.29.2. テキストはドキュメントに変化します…59 2.29.3. ソリューション記述…59 2.30. 初期の混雑ウィンドウサイズ…59 2.30.1. 問題の記述…59 2.30.2. テキストはドキュメントに変化します…60 2.30.3. ソリューション記述…61 2.31. 数字の一連番号を流してください…62 2.31.1. 問題の記述…62 2.31.2. テキストはドキュメントに変化します…63 2.31.3. ソリューション記述…67 2.32. 認識されていないパラメタ…67 2.32.1. 問題の記述…67 2.32.2. テキストはドキュメントに変化します…67 2.32.3. ソリューション記述…68 2.33. 認識されていないパラメタの取り扱い…68 2.33.1. 問題の記述…68 2.33.2. テキストはドキュメントに変化します…68 2.33.3. ソリューション記述…70 2.34. タグを結んでください…70 2.34.1. 問題の記述…70 2.34.2. テキストはドキュメントに変化します…70 2.34.3. ソリューション記述…72 2.35. クッキーエコーで数の検証を移植してください…72 2.35.1. 問題の記述…72 2.35.2. テキストはドキュメントに変化します…72 2.35.3. ソリューション記述…73 2.36. 経路初期設定…74 2.36.1. 問題の記述…74 2.36.2. テキストはドキュメントに変化します…74 2.36.3. ソリューション記述…76 2.37. ICMP取り扱い手順…76 2.37.1. 問題の記述…76 2.37.2. テキストはドキュメントに変化します…77
Stewart, et al. Informational [Page 4] RFC 4460 SCTP Errata April 2006
スチュワート、他 [4ページ]情報のRFC4460SCTP誤字2006年4月
2.37.3. Solution Description ..............................79
2.38. Checksum .................................................79
2.38.1. Description of the problem ........................79
2.38.2. Text Changes to the Document ......................79
2.38.3. Solution Description ..............................86
2.39. Retransmission Policy ....................................86
2.39.1. Description of the Problem ........................86
2.39.2. Text Changes to the Document ......................87
2.39.3. Solution Description ..............................87
2.40. Port Number 0 ............................................88
2.40.1. Description of the Problem ........................88
2.40.2. Text Changes to the Document ......................88
2.40.3. Solution Description ..............................89
2.41. T Bit ....................................................89
2.41.1. Description of the Problem ........................89
2.41.2. Text Changes to the Document ......................89
2.41.3. Solution Description ..............................93
2.42. Unknown Parameter Handling ...............................93
2.42.1. Description of the Problem ........................93
2.42.2. Text Changes to the Document ......................93
2.42.3. Solution Description ..............................95
2.43. Cookie Echo Chunk ........................................95
2.43.1. Description of the Problem ........................95
2.43.2. Text Changes to the Document ......................95
2.43.3. Solution Description ..............................96
2.44. Partial Chunks ...........................................96
2.44.1. Description of the Problem ........................96
2.44.2. Text Changes to the Document ......................96
2.44.3. Solution Description ..............................97
2.45. Non-unicast Addresses ....................................97
2.45.1. Description of the Problem ........................97
2.45.2. Text Changes to the Document ......................97
2.45.3. Solution Description ..............................98
2.46. Processing of ABORT Chunks ...............................98
2.46.1. Description of the Problem ........................98
2.46.2. Text Changes to the Document ......................98
2.46.3. Solution Description ..............................98
2.47. Sending of ABORT Chunks ..................................99
2.47.1. Description of the Problem ........................99
2.47.2. Text Changes to the Document ......................99
2.47.3. Solution Description ..............................99
2.48. Handling of Supported Address Types Parameter ............99
2.48.1. Description of the Problem ........................99
2.48.2. Text Changes to the Document .....................100
2.48.3. Solution Description .............................100
2.49. Handling of Unexpected Parameters .......................101
2.49.1. Description of the Problem .......................101
2.49.2. Text Changes to the Document .....................101
2.37.3. ソリューション記述…79 2.38. チェックサム…79 2.38.1. 問題の記述…79 2.38.2. テキストはドキュメントに変化します…79 2.38.3. ソリューション記述…86 2.39. Retransmission方針…86 2.39.1. 問題の記述…86 2.39.2. テキストはドキュメントに変化します…87 2.39.3. ソリューション記述…87 2.40. No.0を移植してください…88 2.40.1. 問題の記述…88 2.40.2. テキストはドキュメントに変化します…88 2.40.3. ソリューション記述…89 2.41. Tに噛み付きました…89 2.41.1. 問題の記述…89 2.41.2. テキストはドキュメントに変化します…89 2.41.3. ソリューション記述…93 2.42. 未知のパラメタ取り扱い…93 2.42.1. 問題の記述…93 2.42.2. テキストはドキュメントに変化します…93 2.42.3. ソリューション記述…95 2.43. クッキーエコー塊…95 2.43.1. 問題の記述…95 2.43.2. テキストはドキュメントに変化します…95 2.43.3. ソリューション記述…96 2.44. 部分的な塊…96 2.44.1. 問題の記述…96 2.44.2. テキストはドキュメントに変化します…96 2.44.3. ソリューション記述…97 2.45. 非ユニキャストアドレス…97 2.45.1. 問題の記述…97 2.45.2. テキストはドキュメントに変化します…97 2.45.3. ソリューション記述…98 2.46. アボート塊の処理…98 2.46.1. 問題の記述…98 2.46.2. テキストはドキュメントに変化します…98 2.46.3. ソリューション記述…98 2.47. アボート塊を発信させます…99 2.47.1. 問題の記述…99 2.47.2. テキストはドキュメントに変化します…99 2.47.3. ソリューション記述…99 2.48. サポートしているアドレスの取り扱いはパラメタをタイプします…99 2.48.1. 問題の記述…99 2.48.2. テキストはドキュメントに変化します…100 2.48.3. ソリューション記述…100 2.49. 予期していなかったパラメタの取り扱い…101 2.49.1. 問題の記述…101 2.49.2. テキストはドキュメントに変化します…101
Stewart, et al. Informational [Page 5] RFC 4460 SCTP Errata April 2006
スチュワート、他 [5ページ]情報のRFC4460SCTP誤字2006年4月
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
2.49.3. ソリューション記述…102 2.50. 有効搭載量プロトコル識別子…102 2.50.1. 問題の記述…102 2.50.2. テキストはドキュメントに変化します…103 2.50.3. ソリューション記述…103 2.51. Karnのアルゴリズム…104 2.51.1. 問題の記述…104 2.51.2. テキストはドキュメントに変化します…104 2.51.3. ソリューション記述…104 2.52. 速くアルゴリズムを再送してください…104 2.52.1. 問題の記述…104 2.52.2. テキストはドキュメントに変化します…105 2.52.3. ソリューション記述…105 3. セキュリティ問題…105 4. 承認…106 5. IANA問題…106 6. 標準の参照…106
1. Introduction
1. 序論
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.
このドキュメントはStream Control Transmissionプロトコル(SCTP)(RFC2960[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
このドキュメントはRFC2960の[5]BISドキュメントにコンパイルされる変化の歴史を供給します。 誤りがフォームでこのドキュメントの中に詳細であるために望んでいるそれぞれ
o the problem description,
o 問題記述
o the text quoted from RFC 2960 [5],
o テキストはRFC2960[5]から引用しました。
o the replacement text that should be placed into the BIS document,
and
o そしてBISドキュメントに置かれるべきである交換テキスト。
o a description of the solution.
o ソリューションの記述。
This document is a historical record of sequential changes what have been found necessary at various interop events and through discussion on this list.
このドキュメントは連続することの歴史的な記録が、何がこのリストで様々な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
スチュワート、他 [6ページ]情報のRFC4460SCTP誤字2006年4月
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].
キーワードが解釈しなければならない、本書では現れるとき、RFC2119[2]で説明されるようにNOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、NOT RECOMMENDED、5月、およびOPTIONALを解釈することになっていなければなりませんか?
2. Corrections to RFC 2960
2. RFC2960への修正
2.1. Incorrect Error Type During Chunk Processing.
2.1. 塊処理の間の不正確な誤りタイプ。
2.1.1. Description of the Problem
2.1.1. 問題の記述
A typo was discovered in RFC 2960 [5] that incorrectly specifies an action to be taken when processing chunks of unknown identity.
誤植は未知のアイデンティティの塊を処理するとき、取るために不当に動作を指定するRFC2960[5]で発見されました。
2.1.2. Text changes to the document
2.1.2. ドキュメントへのテキスト変化
--------- Old text: (Section 3.2) ---------
--------- 古いテキスト: (セクション3.2) ---------
01 - Stop processing this SCTP packet and discard it, do not process
any further chunks within it, and report the unrecognized
parameter in an 'Unrecognized Parameter Type' (in either an
ERROR or in the INIT ACK).
01--停止がこのSCTPパケットを処理して、それを捨ててください、そして、それの中でどんなさらなる塊も処理しないでください、そして、'認識されていないParameter Type'(ERRORかINIT ACKの)の認識されていないパラメタを報告してください。
--------- New text: (Section 3.2) ---------
--------- 新しいテキスト: (セクション3.2) ---------
01 - Stop processing this SCTP packet and discard it, do not process
any further chunks within it, and report the unrecognized
chunk in an 'Unrecognized Chunk Type'.
01--停止がこのSCTPパケットを処理して、それを捨ててください、そして、それの中でどんなさらなる塊も処理しないでください、そして、'認識されていないChunk Type'で認識されていない塊を報告してください。
2.1.3. Solution Description
2.1.3. ソリューション記述
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. パラメタ処理問題
2.2.1. Description of the Problem
2.2.1. 問題の記述
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
スチュワート、他 [7ページ]情報のRFC4460SCTP誤字2006年4月
2.2.2. Text Changes to the Document
2.2.2. ドキュメントへのテキスト変化
--------- Old text: (Section 3.2.1) ---------
--------- 古いテキスト: (セクション3.2.1) ---------
00 - Stop processing this SCTP packet and discard it; do not process
any further chunks within it.
00--このSCTPパケットを処理するのを止めてください、そして、それを捨ててください。 それの中でどんなさらなる塊も処理しないでください。
01 - Stop processing this SCTP packet and discard it, do not process
any further chunks within it, and report the unrecognized
parameter in an 'Unrecognized Parameter Type' (in either an
ERROR or in the INIT ACK).
01--停止がこのSCTPパケットを処理して、それを捨ててください、そして、それの中でどんなさらなる塊も処理しないでください、そして、'認識されていないParameter Type'(ERRORかINIT ACKの)の認識されていないパラメタを報告してください。
--------- New text: (Section 3.2.1) ---------
--------- 新しいテキスト: (セクション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塊を処理して、それを捨ててください、そして、この塊の中でどんなさらなるパラメタも処理しないでください、そして、'認識されていないParameter Type'(ERRORかINIT ACKの)の認識されていないパラメタを報告してください。
2.2.3. Solution Description
2.2.3. ソリューション記述
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.
いつも1つが未知の塊かパラメタに0に設定された上側のビットであったレベルで処理するのを止めるのは、意図でした。 したがって、塊を処理しているなら、あなたはパケットを下げるべきです。 パラメタを処理しているなら、あなたは塊を下げるべきです。
2.3. Padding Issues
2.3. 問題を水増しします。
2.3.1. Description of the Problem
2.3.1. 問題の記述
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.
ChunkがTLVパラメタで終わったとき、問題は見つけられました。 この最後のTLVが32ビットの境界(必要に応じて)になかったなら、最後の詰め物が塊の長さに含まれたかどうかに関して混乱がありました。
Stewart, et al. Informational [Page 8] RFC 4460 SCTP Errata April 2006
スチュワート、他 [8ページ]情報のRFC4460SCTP誤字2006年4月
2.3.2. Text Changes to the Document
2.3.2. ドキュメントへのテキスト変化
--------- Old text: (Section 3.2) ---------
--------- 古いテキスト: (セクション3.2) ---------
Chunk Length: 16 bits (unsigned integer)
塊の長さ: 16ビット(符号のない整数)
This value represents the size of the chunk in bytes including the
Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields.
Therefore, if the Chunk Value field is zero-length, the Length
field will be set to 4. The Chunk Length field does not count any
padding.
この値はChunk Type、Chunk Flags、Chunk Length、およびChunk Value分野を含むバイトで表現される塊のサイズを表します。 したがって、Chunk Value分野がゼロ・レングスであるなら、Length分野は4に設定されるでしょう。 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.
Chunk Value分野は塊で移されるべき実際の情報を含んでいます。 この分野の用法と形式はChunk Typeに依存しています。
The total length of a chunk (including Type, Length and Value fields) MUST be a multiple of 4 bytes. If the length of the chunk is not a multiple of 4 bytes, the sender MUST pad the chunk with all zero bytes and this padding is not included in the chunk length field. The sender should never pad with more than 3 bytes. The receiver MUST ignore the padding bytes.
塊(Type、Length、およびValue分野を含んでいる)の全長は4バイトの倍数であるに違いありません。 塊の長さが4バイトの倍数でないなら、送付者はすべてのバイトでどんな塊を水増ししてはいけません、そして、この詰め物は塊長さの分野に含まれていません。 送付者は3バイト以上で決してそっと歩くべきではありません。 受信機は詰め物バイトを無視しなければなりません。
--------- New text: (Section 3.2) ---------
--------- 新しいテキスト: (セクション3.2) ---------
Chunk Length: 16 bits (unsigned integer)
塊の長さ: 16ビット(符号のない整数)
This value represents the size of the chunk in bytes, including
the Chunk Type, Chunk Flags, Chunk Length, and Chunk Value fields.
Therefore, if the Chunk Value field is zero-length, the Length
field will be set to 4. The Chunk Length field does not count any
chunk padding.
この値はバイトで表現される塊のサイズを表します、Chunk Type、Chunk Flags、Chunk Length、およびChunk Value分野を含んでいて。 したがって、Chunk Value分野がゼロ・レングスであるなら、Length分野は4に設定されるでしょう。 Chunk Length分野は少しの塊詰め物も数えません。
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.
塊(Type、Length、およびValue分野を含んでいる)はすべてのバイトでどんな送付者によって広げられても、4バイト長の倍数にしません。 この詰め物は合計で3バイト以上であるはずがありません。 Chunk Length値は、塊の詰め物を終えるのを含んでいません。 しかしながら、それは、塊における最後のパラメタ以外のどんな可変長のパラメタも水増しするのを含んでいます。 受信機は詰め物を無視しなければなりません。
Stewart, et al. Informational [Page 9] RFC 4460 SCTP Errata April 2006
スチュワート、他 [9ページ]情報のRFC4460SCTP誤字2006年4月
Note: A robust implementation should accept the Chunk whether or
not the final padding has been included in the Chunk Length.
以下に注意してください。 最終的な詰め物がChunk Lengthに含まれているか否かに関係なく、体力を要している実現はChunkを受け入れるべきです。
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.
Chunk Value分野は塊で移されるべき実際の情報を含んでいます。 この分野の用法と形式はChunk Typeに依存しています。
The total length of a chunk (including Type, Length, and Value fields) MUST be a multiple of 4 bytes. If the length of the chunk is not a multiple of 4 bytes, the sender MUST pad the chunk with all zero bytes, and this padding is not included in the chunk length field. The sender should never pad with more than 3 bytes. The receiver MUST ignore the padding bytes.
塊(Type、Length、およびValue分野を含んでいる)の全長は4バイトの倍数であるに違いありません。 塊の長さが4バイトの倍数でないなら、送付者はすべてのバイトでどんな塊を水増ししてはいけません、そして、この詰め物は塊長さの分野に含まれていません。 送付者は3バイト以上で決してそっと歩くべきではありません。 受信機は詰め物バイトを無視しなければなりません。
2.3.3. Solution Description
2.3.3. ソリューション記述
The above text makes clear that the padding of the last parameter is not included in the Chunk Length field. It also clarifies that the padding of parameters that are not the last one must be counted in the Chunk Length field.
上のテキストは、最後のパラメタの詰め物がChunk Length分野に含まれていないことを明らかにします。 また、Chunk Length分野で最後のものでないパラメタの詰め物を数えなければならないのははっきりさせられます。
2.4. Parameter Types across All Chunk Types
2.4. すべての塊タイプの向こう側のパラメータの型
2.4.1. Description of the Problem
2.4.1. 問題の記述
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
2.4.2. ドキュメントへのテキスト変化
--------- Old text: (Section 3.2.1) ---------
--------- 古いテキスト: (セクション3.2.1) ---------
The actual SCTP parameters are defined in the specific SCTP chunk sections. The rules for IETF-defined parameter extensions are defined in Section 13.2.
実際のSCTPパラメタは特定のSCTP塊部で定義されます。 IETFによって定義されたパラメタ拡張子のための規則はセクション13.2で定義されます。
--------- New text: (Section 3.2.1) ---------
--------- 新しいテキスト: (セクション3.2.1) ---------
The actual SCTP parameters are defined in the specific SCTP chunk sections. The rules for IETF-defined parameter extensions are
実際のSCTPパラメタは特定のSCTP塊部で定義されます。 IETFによって定義されたパラメタ拡張子のための規則はそうです。
Stewart, et al. Informational [Page 10] RFC 4460 SCTP Errata April 2006
スチュワート、他 [10ページ]情報のRFC4460SCTP誤字2006年4月
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.
セクション13.2では、定義されます。 パラメータの型がすべての塊の向こう側にユニークであるに違いないことに注意してください。 例えば、パラメータの型'5'は、IPv4アドレスを表すのに使用されます(セクション3.3.2を見てください)。 値'5'を、次に、IPv4アドレスを表すためにすべての塊の向こう側に予約して、いかなる他の塊における異なった意味でも再利用してはいけません。
--------- Old text: (Section 13.2) ---------
--------- 古いテキスト: (セクション13.2) ---------
13.2 IETF-defined Chunk Parameter Extension
13.2 IETFによって定義された塊パラメタ拡張子
The assignment of new chunk parameter type codes is done through an IETF Consensus action as defined in [RFC2434]. Documentation of the chunk parameter MUST contain the following information:
[RFC2434]で定義されるようにIETF Consensus動作で新しい塊パラメータの型コードの課題をします。 塊パラメタのドキュメンテーションは以下の情報を含まなければなりません:
a) Name of the parameter type.
a) パラメータの型の名前。
b) Detailed description of the structure of the parameter field.
This structure MUST conform to the general type-length-value
format described in Section 3.2.1.
b) パラメタ分野の構造の詳述。 この構造はセクション3.2.1で説明された一般的なタイプ長さの価値の形式に一致しなければなりません。
c) Detailed definition of each component of the parameter type.
c) パラメータの型のそれぞれの成分の詳細な定義。
d) Detailed description of the intended use of this parameter type,
and an indication of whether and under what circumstances multiple
instances of this parameter type may be found within the same
chunk.
d) このパラメータの型の意図している使用の記述、および指示を詳しく述べる、そして、どんな状況で、このパラメータの型の複数の例が同じ塊の中で見つけられるかもしれませんか?
--------- New text: (Section 13.2) ---------
--------- 新しいテキスト: (セクション13.2) ---------
13.2. IETF-defined Chunk Parameter Extension
13.2. IETFによって定義された塊パラメタ拡張子
The assignment of new chunk parameter type codes is done through an IETF Consensus action, as defined in [RFC2434]. Documentation of the chunk parameter MUST contain the following information:
[RFC2434]で定義されるようにIETF Consensus動作で新しい塊パラメータの型コードの課題をします。 塊パラメタのドキュメンテーションは以下の情報を含まなければなりません:
a) Name of the parameter type.
a) パラメータの型の名前。
b) Detailed description of the structure of the parameter field.
This structure MUST conform to the general type-length-value
format described in Section 3.2.1.
b) パラメタ分野の構造の詳述。 この構造はセクション3.2.1で説明された一般的なタイプ長さの価値の形式に一致しなければなりません。
c) Detailed definition of each component of the parameter type.
c) パラメータの型のそれぞれの成分の詳細な定義。
Stewart, et al. Informational [Page 11] RFC 4460 SCTP Errata April 2006
スチュワート、他 [11ページ]情報のRFC4460SCTP誤字2006年4月
d) Detailed description of the intended use of this parameter type,
and an indication of whether and under what circumstances multiple
instances of this parameter type may be found within the same
chunk.
d) このパラメータの型の意図している使用の記述、および指示を詳しく述べる、そして、どんな状況で、このパラメータの型の複数の例が同じ塊の中で見つけられるかもしれませんか?
e) Each parameter type MUST be unique across all chunks.
e) それぞれのパラメータの型はすべての塊の向こう側にユニークであるに違いありません。
2.4.3. Solution Description
2.4.3. ソリューション記述
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.
すべてのパラメタをすべての塊課題(現在の課題方針)の向こう側にユニークにすることによって、あいまいさは全くパラメタが異なった文脈で意味することに関して存在していません。 6万5536*数に従ってこれのためのトレードオフが、より小さいパラメタスペース、すなわち、6万5536のパラメタである、-、塊について。
2.5. Stream Parameter Clarification
2.5. 流れのパラメタ明確化
2.5.1. Description of the problem
2.5.1. 問題の記述
A problem was found where the specification is unclear on the legality of an endpoint asking for more stream resources than were allowed in the MIS value of the INIT. In particular, the value in the INIT ACK requested in its OS value was larger than the MIS value received in the INIT chunk. This behavior is illegal, yet it was unspecified in RFC 2960 [5]
仕様が終点の合法でINITのMIS値で許容されたよりさらに多くの流れのリソースを求めるのにおいて不明瞭であるところで問題は見つけられました。 OS値で要求されたINIT ACKの値はINIT塊におけるMIS対価領収より特に、大きかったです。 この振舞いが不法である、しかし、それはRFC2960で不特定でした。[5]
2.5.2. Text Changes to the Document
2.5.2. ドキュメントへのテキスト変化
--------- Old text: (Section 3.3.3) ---------
--------- 古いテキスト: (セクション3.3.3) ---------
Number of Outbound Streams (OS): 16 bits (unsigned integer)
外国行きの流れ(OS)の数: 16ビット(符号のない整数)
Defines the number of outbound streams the sender of this INIT ACK
chunk wishes to create in this association. The value of 0 MUST
NOT be used.
このINIT ACK塊の送付者がこの協会で作成したがっている外国行きの流れの数を定義します。 0の値を使用してはいけません。
Note: A receiver of an INIT ACK with the OS value set to 0 SHOULD
destroy the association discarding its TCB.
以下に注意してください。 0SHOULDへのOS選択値群があるINIT ACKの受信機はTCBを捨てる協会を破壊します。
Stewart, et al. Informational [Page 12] RFC 4460 SCTP Errata April 2006
スチュワート、他 [12ページ]情報のRFC4460SCTP誤字2006年4月
--------- New text: (Section 3.3.3) ---------
--------- 新しいテキスト: (セクション3.3.3) ---------
Number of Outbound Streams (OS): 16 bits (unsigned integer)
外国行きの流れ(OS)の数: 16ビット(符号のない整数)
Defines the number of outbound streams the sender of this INIT ACK
chunk wishes to create in this association. The value of 0 MUST
NOT be used, and the value MUST NOT be greater than the MIS value
sent in the INIT chunk.
このINIT ACK塊の送付者がこの協会で作成したがっている外国行きの流れの数を定義します。 0の値を使用してはいけなくて、値はMIS値がINIT塊を送ったよりすばらしいはずがありません。
Note: A receiver of an INIT ACK with the OS value set to 0 SHOULD
destroy the association, discarding its TCB.
以下に注意してください。 TCBを捨てて、0SHOULDへのOS選択値群があるINIT ACKの受信機は協会を破壊します。
2.5.3. Solution Description
2.5.3. ソリューション記述
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. 協会安全保障問題を再開します。
2.6.1. Description of the Problem
2.6.1. 問題の記述
A security problem was found when a restart occurs. It is possible for an intruder to send an INIT to an endpoint of an existing association. In the INIT the intruder would list one or more of the current addresses of an association and its own. The normal restart procedures would then occur, and the intruder would have hijacked an association.
再開が起こるとき、警備上の問題は見つけられました。 侵入者が既存の協会の終点にINITを送るのは、可能です。 INITでは、侵入者は協会とそれ自身の現在のアドレスの1つ以上を記載するでしょう。 次に、正常な再開手順は起こったでしょう、そして、侵入者は協会をハイジャックしたでしょう。
Stewart, et al. Informational [Page 13] RFC 4460 SCTP Errata April 2006
スチュワート、他 [13ページ]情報のRFC4460SCTP誤字2006年4月
2.6.2. Text Changes to the Document
2.6.2. ドキュメントへのテキスト変化
--------- Old text: (Section 3.3.10) ---------
--------- 古いテキスト: (セクション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
原因コード値原因コード--------- ---------------- 1 停止している間に受け取られたリソース5Unresolvableアドレス6認識されていない塊タイプ7無効の義務的なパラメタ8の認識されていないパラメタ9いいえ利用者データ10クッキーからの無効の流れの識別子2のなくなった義務的なパラメタ3の聞き古したクッキー誤り4
Cause Length: 16 bits (unsigned integer)
長さを引き起こしてください: 16ビット(符号のない整数)
Set to the size of the parameter in bytes, including the Cause
Code, Cause Length, and Cause-Specific Information fields
Cause Code、Cause Length、およびCause特有の情報分野を含むバイトで表現されるパラメタのサイズに、セットします。
Cause-specific Information: variable length
原因特有の情報: 可変長
This field carries the details of the error condition.
この分野はエラー条件の詳細を運びます。
Sections 3.3.10.1 - 3.3.10.10 define error causes for SCTP.
セクション3.3 .10 .1--3.3 .10 .10はSCTPの誤り原因を定義します。
Guidelines for the IETF to define new error cause values are discussed in Section 13.3.
セクション13.3でIETFが新しい誤り原因値を定義するガイドラインについて議論します。
Stewart, et al. Informational [Page 14] RFC 4460 SCTP Errata April 2006
スチュワート、他 [14ページ]情報のRFC4460SCTP誤字2006年4月
--------- New text: (Section 3.3.10) ---------
--------- 新しいテキスト: (セクション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
原因コード値原因コード--------- ---------------- 1 終業11が再開しますが、受け取られた新しいアドレスとの協会のリソース5Unresolvableアドレス6認識されていない塊タイプ7無効の義務的なパラメタ8の認識されていないパラメタ9いいえ利用者データ10クッキーからの無効の流れの識別子2のなくなった義務的なパラメタ3の聞き古したクッキー誤り4
Cause Length: 16 bits (unsigned integer)
長さを引き起こしてください: 16ビット(符号のない整数)
Set to the size of the parameter in bytes, including the Cause
Code, Cause Length, and Cause-Specific Information fields.
Cause Code、Cause Length、およびCause特有の情報分野を含むバイトで表現されるパラメタのサイズにセットしてください。
Cause-specific Information: variable length
原因特有の情報: 可変長
This field carries the details of the error condition.
この分野はエラー条件の詳細を運びます。
Sections 3.3.10.1 - 3.3.10.11 define error causes for SCTP. Guidelines for the IETF to define new error cause values are discussed in Section 13.3.
セクション3.3 .10 .1--3.3 .10 .11はSCTPの誤り原因を定義します。 セクション13.3でIETFが新しい誤り原因値を定義するガイドラインについて議論します。
--------- 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は協会の一部ではなく、協会への以前にそうであったアドレスを加えました。 新しいアドレスはエラーコードで記載されています。 通常、INITを拒否するABORTの一部としてこのERRORを送ります(セクション5.2を見てください)。
Stewart, et al. Informational [Page 15] RFC 4460 SCTP Errata April 2006
スチュワート、他 [15ページ]情報のRFC4460SCTP誤字2006年4月
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=11 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ New Address TLVs /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 原因コード=11| 原因の長さは変数と等しいです。| 新しい..アドレス
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.
以下に注意してください。 各New Address TLVは新しかったINIT塊で見つけられたTLVの正確なコピーです、Parameter TypeとParameterの長さを含んでいて。
--------- Old text: (Section 5.2.1) ---------
--------- 古いテキスト: (セクション5.2.1) ---------
Upon receipt of an INIT in the COOKIE-WAIT or COOKIE-ECHOED state, an endpoint MUST respond with an INIT ACK using the same parameters it sent in its original INIT chunk (including its Initiation Tag, unchanged). These original parameters are combined with those from the newly received INIT chunk. The endpoint shall also generate a State Cookie with the INIT ACK. The endpoint uses the parameters sent in its INIT to calculate the State Cookie.
COOKIE-WAITかCOOKIE-ECHOED状態のINITを受け取り次第、INIT ACKがそれがオリジナルのINIT塊で送った同じパラメタを使用している状態で、終点は応じなければなりません(Initiation Tagで、変わりがない状態で包含して)。 これらの元のパラメタは新たに受け取られたINIT塊からそれらに結合されます。 また、終点はINIT ACKと共に州Cookieを発生させるものとします。 終点は州Cookieについて計算するためにINITで送られたパラメタを使用します。
--------- New text: (Section 5.2.1) ---------
--------- 新しいテキスト: (セクション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 ACKがそれがオリジナルのINIT塊で送った同じパラメタを使用している状態で、終点は応じなければなりません(Initiation Tagで、変わりがない状態で包含して)。 応じるとき、終点はオリジナルのINIT(この終点のそばで発信する)が送られたのと同じアドレスにINIT ACKを送り返さなければなりません。
Upon receipt of an INIT in the COOKIE-ECHOED state, an endpoint MUST respond with an INIT ACK using the same parameters it sent in its original INIT chunk (including its Initiation Tag, unchanged), provided that no NEW address has been added to the forming association. If the INIT message indicates that a new address has been added to the association, then the entire INIT MUST be discarded, and NO changes should be made to the existing association. An ABORT SHOULD be sent in response that MAY include the error 'Restart of an association with new addresses'. The error SHOULD list the addresses that were added to the restarting association.
COOKIE-ECHOED状態のINITを受け取り次第、INIT ACKがそれがオリジナルのINIT塊で送った同じパラメタを使用している状態で、終点は応じなければなりません(Initiation Tagで、変わりがない状態で包含して)、NEWアドレスが全く形成協会に追加されていなければ。 INITメッセージがそれを示すなら、新しいアドレスを協会に追加してあって、捨てて、その時は全体INIT MUSTです。変更を全く既存の協会にするべきではありません。 ABORT SHOULD、誤り'新しいアドレスとの協会の再開'を含むかもしれない応答では、送ってください。 誤りSHOULDは再開協会に追加されたアドレスを記載します。
Stewart, et al. Informational [Page 16] RFC 4460 SCTP Errata April 2006
スチュワート、他 [16ページ]情報のRFC4460SCTP誤字2006年4月
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.
INIT ACKと共に状態(COOKIE-WAITかCOOKIE-ECHOED)で応じるとき、元のパラメタは新たに受け取られたINIT塊からそれらに結合されます。 また、終点はINIT ACKと共に州Cookieを発生させるものとします。 終点は州Cookieについて計算するためにINITで送られたパラメタを使用します。
--------- Old text: (Section 5.2.2) ---------
--------- 古いテキスト: (セクション5.2.2) ---------
5.2.2 Unexpected INIT in States Other than CLOSED, COOKIE-ECHOED,
COOKIE-WAIT and SHUTDOWN-ACK-SENT
5.2.2 閉じていて、クッキーで反響しているクッキー待ちとACKが送った閉鎖以外の州の予期していなかったイニット
Unless otherwise stated, upon reception of an unexpected INIT for this association, the endpoint shall generate an INIT ACK with a State Cookie. In the outbound INIT ACK the endpoint MUST copy its current Verification Tag and peer's Verification Tag into a reserved place within the state cookie. We shall refer to these locations as the Peer's-Tie-Tag and the Local-Tie-Tag. The outbound SCTP packet containing this INIT ACK MUST carry a Verification Tag value equal to the Initiation Tag found in the unexpected INIT. And the INIT ACK MUST contain a new Initiation Tag (randomly generated see Section 5.3.1). Other parameters for the endpoint SHOULD be copied from the existing parameters of the association (e.g., number of outbound streams) into the INIT ACK and cookie.
この協会のために別の方法で予期していなかったINITのレセプションに述べられない場合、終点は州Cookieと共にINIT ACKを発生させるものとします。 外国行きのINIT ACKでは、終点は州のクッキーの中の予約された場所にその現在のVerification Tagと同輩のVerification Tagをコピーしなければなりません。 私たちはPeerのものがタグを接続していて、Local繋がりのタグにこれらの位置について言及するつもりです。 このINIT ACK MUSTを含む外国行きのSCTPパケットは予期していなかったINITで見つけられたInitiation Tagと等しいVerification Tag値を運びます。 そして、INIT ACK MUSTは新しいInitiation Tagを含んでいます(手当たりしだいに発生して、セクション5.3.1を見てください)。 他のパラメタ、終点SHOULDに関しては、協会(例えば、外国行きの流れの数)の既存のパラメタから、INIT ACKとクッキーの中にコピーされてください。
After sending out the INIT ACK, the endpoint shall take no further actions, i.e., the existing association, including its current state, and the corresponding TCB MUST NOT be changed.
INIT ACKを出した後に、終点はこれ以上動作、すなわち、現状を含む既存の協会を取らないものとします、そして、対応するTcbを変えてはいけません。
Note: Only when a TCB exists and the association is not in a COOKIE- WAIT state are the Tie-Tags populated. For a normal association INIT (i.e., the endpoint is in a COOKIE-WAIT state), the Tie-Tags MUST be set to 0 (indicating that no previous TCB existed). The INIT ACK and State Cookie are populated as specified in section 5.2.1.
以下に注意してください。 TCBが存在していて、協会がCOOKIE- WAIT州にないときだけ、Tie-タグは居住されます。 INIT(すなわち、終点がCOOKIE-WAIT状態にある)、Tie-タグがそうしなければならない正常な協会には、0に設定されてください(どんな前のTCBも存在しなかったのを示して)。 INIT ACKと州Cookieはセクション5.2.1で指定されるように居住されます。
--------- New text: (Section 5.2.2) ---------
--------- 新しいテキスト: (セクション5.2.2) ---------
5.2.2. Unexpected INIT in States Other Than CLOSED, COOKIE-ECHOED,
COOKIE-WAIT, and SHUTDOWN-ACK-SENT
5.2.2. 閉じていて、クッキーで反響しているクッキー待ち、およびACKが送った閉鎖以外の州の予期していなかったイニット
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
この協会のための予期していなかったINITを受け取り次第別の方法で述べられない場合、終点は州Cookieと共にINIT ACKを発生させるものとします。 応じる前に、終点は、予期していなかったINITが新しいアドレスを協会に追加するかどうかを見るためにチェックしなければなりません。 新しいアドレスが協会に追加されるなら、終点は応じなければなりません。
Stewart, et al. Informational [Page 17] RFC 4460 SCTP Errata April 2006
スチュワート、他 [17ページ]情報のRFC4460SCTP誤字2006年4月
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.
ABORTを運ぶ外国行きのパケットの'検証Tag'に予期していなかったINITの'開始Tag'をコピーするABORTと共に。 ABORT応答では、誤りの原因は'新しいアドレスとの協会の再開'に設定されるかもしれません。 誤りSHOULDは再開協会に追加されたアドレスを記載します。
If no new addresses are added, when responding to the INIT in the outbound INIT ACK, the endpoint MUST copy its current Verification Tag and peer's Verification Tag into a reserved place within the state cookie. We shall refer to these locations as the Peer's-Tie- Tag and the Local-Tie-Tag. The outbound SCTP packet containing this INIT ACK MUST carry a Verification Tag value equal to the Initiation Tag found in the unexpected INIT. And the INIT ACK MUST contain a new Initiation Tag (randomly generated; see Section 5.3.1). Other parameters for the endpoint SHOULD be copied from the existing parameters of the association (e.g., number of outbound streams) into the INIT ACK and cookie.
外国行きのINIT ACKのINITに応じるとき、どんな新しいアドレスも加えられないなら、終点は州のクッキーの中の予約された場所にその現在のVerification Tagと同輩のVerification Tagをコピーしなければなりません。 私たちはPeerのもの-繋がりタグとLocal繋がりのタグにこれらの位置について言及するつもりです。 このINIT ACK MUSTを含む外国行きのSCTPパケットは予期していなかったINITで見つけられたInitiation Tagと等しいVerification Tag値を運びます。 そして、INIT ACK MUSTが新しいInitiation Tagを含んでいる、(;手当たりしだいに発生して、 セクション5.3.1を)見てください。 他のパラメタ、終点SHOULDに関しては、協会(例えば、外国行きの流れの数)の既存のパラメタから、INIT ACKとクッキーの中にコピーされてください。
After sending out the INIT ACK or ABORT, the endpoint shall take no further actions; i.e., the existing association, including its current state, and the corresponding TCB MUST NOT be changed.
INIT ACKかABORTを出した後に、終点はこれ以上行動を取らないものとします。 すなわち、現状を含む既存の協会と対応するTcbを変えてはいけません。
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州にないときだけ、Tie-タグは0以外の値で居住されます。 INIT(すなわち、終点がCLOSED状態にある)、Tie-タグがそうしなければならない正常な協会には、0に設定されてください(どんな前のTCBも存在しなかったのを示して)。
2.6.3. Solution Description
2.6.3. ソリューション記述
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.
また、Tie-タグの使用について説明するセクション5.2.2の終わりでの注意は、適切に、Tie-タグが0と異なった値に設定されるべきである州について説明するように変更されました。
Stewart, et al. Informational [Page 18] RFC 4460 SCTP Errata April 2006
スチュワート、他 [18ページ]情報のRFC4460SCTP誤字2006年4月
2.7. Implicit Ability to Exceed cwnd by PMTU-1 Bytes
2.7. PMTU-1 BytesによるExceed cwndへの内在しているAbility
2.7.1. Description of the Problem
2.7.1. 問題の記述
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を育てるのに苦労していました。 これは混雑制御規則の不適当な実施のためでした。 書かれるとして、aがこぼれるので、規則は提供されました。cwnd価値を終わらせます。 これがこぼれる、送付者は、完全なcwnd値を使用しているNOTに見えて、その結果、それを決して増加させません。
2.7.2. Text Changes to the Document
2.7.2. ドキュメントへのテキスト変化
--------- Old text: (Section 6.1) ---------
--------- 古いテキスト: (セクション6.1) ---------
B) At any given time, the sender MUST NOT transmit new data to a
given transport address if it has cwnd or more bytes of data
outstanding to that transport address.
B) その時々で、それにその輸送アドレスへの未払いのデータのcwndか、より多くのバイトがあるなら、送付者は与えられた輸送アドレスに新しいデータを送ってはいけません。
--------- New text: (Section 6.1) ---------
--------- 新しいテキスト: (セクション6.1) ---------
B) At any given time, the sender MUST NOT transmit new data to a
given transport address if it has cwnd or more bytes of data
outstanding to that transport address. The sender may exceed cwnd
by up to (PMTU-1) bytes on a new transmission if the cwnd is not
currently exceeded.
B) その時々で、それにその輸送アドレスへの未払いのデータのcwndか、より多くのバイトがあるなら、送付者は与えられた輸送アドレスに新しいデータを送ってはいけません。 cwndが現在超えられていないなら、送付者はcwndを新しいトランスミッションの(PMTU-1)バイトまで超えるかもしれません。
2.7.3. Solution Description
2.7.3. ソリューション記述
The text changes make clear the ability to go over the cwnd value by no more than (PMTU-1) bytes.
テキスト変化はcwnd値を(PMTU-1)バイトだけ調べる能力を明らかにします。
2.8. Issues with Fast Retransmit
2.8. 速いことの問題は再送されます。
2.8.1. Description of the Problem
2.8.1. 問題の記述
Several problems were found in the current specification of fast retransmit. The current wording did not require GAP ACK blocks to be sent, even though they are essential to the workings of SCTP's congestion control. The specification left unclear how to handle the fast retransmit cycle, having the implementation wait on the cwnd to retransmit a TSN that was marked for fast retransmit. No limit was placed on how many times a TSN could be fast retransmitted. Fast Recovery was not specified, causing the congestion window to be reduced drastically when there are multiple losses in a single RTT.
数個が速いことの現在の仕様で再送されます問題が見つけられた。 現在の言葉遣いは、GAP ACKブロックが送られるのを必要としませんでした、それらがSCTPの輻輳制御の作業に不可欠ですが。 実現をcwndでマークされたTSNを再送するのを待たせて、どう速さを扱うかがサイクルを再送するのが不明瞭な状態で速く残っている仕様は再送されます。 限界は全く何回速くTSNを再送できたかに置かれませんでした。 速く、Recoveryは指定されませんでした、複数の損失が独身のRTTにあるとき、混雑ウィンドウが抜本的に減少することを引き起こして。
Stewart, et al. Informational [Page 19] RFC 4460 SCTP Errata April 2006
スチュワート、他 [19ページ]情報のRFC4460SCTP誤字2006年4月
2.8.2. Text Changes to the Document
2.8.2. ドキュメントへのテキスト変化
--------- Old text: (Section 6.2) ---------
--------- 古いテキスト: (セクション6.2) ---------
Acknowledgements MUST be sent in SACK chunks unless shutdown was requested by the ULP in which case an endpoint MAY send an acknowledgement in the SHUTDOWN chunk. A SACK chunk can acknowledge the reception of multiple DATA chunks. See Section 3.3.4 for SACK chunk format. In particular, the SCTP endpoint MUST fill in the Cumulative TSN Ack field to indicate the latest sequential TSN (of a valid DATA chunk) it has received. Any received DATA chunks with TSN greater than the value in the Cumulative TSN Ack field SHOULD also be reported in the Gap Ack Block fields.
ULPが閉鎖を要求しなかったなら、SACK塊で承認を送らなければなりません、その場合、終点はSHUTDOWN塊における承認を送るかもしれません。 SACK塊は複数のDATA塊のレセプションを承認できます。 SACK塊形式に関してセクション3.3.4を見てください。 特に、SCTP終点は、それが受けた最新の連続したTSN(有効なDATA塊の)を示すためにCumulative TSN Ack分野に記入しなければなりません。 いずれもTSNがまたよりすばらしい状態でGap Ack Block分野で報告されたDATA塊を受けました。
--------- New text: (Section 6.2) ---------
--------- 新しいテキスト: (セクション6.2) ---------
Acknowledegments MUST be sent in SACK chunks unless shutdown was requested by the ULP, in which case an endpoint MAY send an acknowledgement in the SHUTDOWN chunk. A SACK chunk can acknowledge the reception of multiple DATA chunks. See Section 3.3.4 for SACK chunk format. In particular, the SCTP endpoint MUST fill in the Cumulative TSN Ack field to indicate the latest sequential TSN (of a valid DATA chunk) it has received. Any received DATA chunks with TSN greater than the value in the Cumulative TSN Ack field are reported in the Gap Ack Block fields. The SCTP endpoint MUST report as many Gap Ack Blocks as can fit in a single SACK chunk limited by the current path MTU.
ULPが閉鎖を要求しなかったなら、SACK塊でAcknowledegmentsを送らなければなりません、その場合、終点はSHUTDOWN塊における承認を送るかもしれません。 SACK塊は複数のDATA塊のレセプションを承認できます。 SACK塊形式に関してセクション3.3.4を見てください。 特に、SCTP終点は、それが受けた最新の連続したTSN(有効なDATA塊の)を示すためにCumulative TSN Ack分野に記入しなければなりません。 Cumulative TSN Ack分野で値よりすばらしいTSNがあるどんな容認されたDATA塊もGap Ack Block分野で報告されます。 SCTP終点は現在の経路MTUによって制限されたただ一つのSACK塊をうまくはめ込むことができるのと同じくらい多くのGap Ack Blocksを報告しなければなりません。
--------- Old text: (Section 6.2.1) ---------
--------- 古いテキスト: (セクション6.2.1) ---------
D) Any time a SACK arrives, the endpoint performs the following:
D) いつでも、SACKは到着して、終点は以下を実行します:
i) If Cumulative TSN Ack is less than the Cumulative TSN Ack
Point, then drop the SACK. Since Cumulative TSN Ack is
monotonically increasing, a SACK whose Cumulative TSN Ack is
less than the Cumulative TSN Ack Point indicates an out-of-
order SACK.
i) Cumulative TSN AckがCumulative TSN Ack Point以下であるなら、SACKを落としてください。 Cumulative TSN Ackが単調に増加しているのでCumulative TSN AckがCumulative TSN Ack Point以下であるSACKがアウトを示す、-、オーダーSACKについて。
ii) Set rwnd equal to the newly received a_rwnd minus the
number of bytes still outstanding after processing the
Cumulative TSN Ack and the Gap Ack Blocks.
ii) セットrwndはCumulative TSN AckとGap Ack Blocksを処理した後にまだ未払いのバイト数を引いて新たに受け取るのと_rwndと等しいです。
Stewart, et al. Informational [Page 20] RFC 4460 SCTP Errata April 2006
スチュワート、他 [20ページ]情報のRFC4460SCTP誤字2006年4月
iii) If the SACK is missing a TSN that was previously
acknowledged via a Gap Ack Block (e.g., the data receiver
reneged on the data), then mark the corresponding DATA chunk
as available for retransmit: Mark it as missing for fast
retransmit as described in Section 7.2.4 and if no
retransmit timer is running for the destination address
to which the DATA chunk was originally transmitted, then
T3-rtx is started for that destination address.
iii) SACKがそうなら、以前に、Gap Ack Blockを通して承認されて(例えば、データ受信装置はデータを破りました)、次に利用可能であるとして対応するDATA塊をマークするTSNがいなくて寂しくて、再送してください: セクション7.2.4で説明されるように速く再送してください。そうすれば、どんな再送信タイマもDATA塊が元々伝えられた送付先アドレスに立候補していないならT3-rtxがその送付先アドレスのために始動されるので消えるとしてそれをマークしてください。
--------- New text: (Section 6.2.1) ---------
--------- 新しいテキスト: (セクション6.2.1) ---------
D) Any time a SACK arrives, the endpoint performs the following:
D) いつでも、SACKは到着して、終点は以下を実行します:
i) If Cumulative TSN Ack is less than the Cumulative TSN Ack
Point, then drop the SACK. Since Cumulative TSN Ack is
monotonically increasing, a SACK whose Cumulative TSN Ack is
less than the Cumulative TSN Ack Point indicates an out-of-
order SACK.
i) Cumulative TSN AckがCumulative TSN Ack Point以下であるなら、SACKを落としてください。 Cumulative TSN Ackが単調に増加しているのでCumulative TSN AckがCumulative TSN Ack Point以下であるSACKがアウトを示す、-、オーダーSACKについて。
ii) Set rwnd equal to the newly received a_rwnd minus the
number of bytes still outstanding after processing the
Cumulative TSN Ack and the Gap Ack Blocks.
ii) セットrwndはCumulative TSN AckとGap Ack Blocksを処理した後にまだ未払いのバイト数を引いて新たに受け取るのと_rwndと等しいです。
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を考えてください: 速いことへのカウント1ミス指示はセクション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) Cumulative TSN AckがFast Recovery exitpoint(セクション7.2.4)を合わせるか、または超えているなら、Fast Recoveryは出られます。
--------- Old text: (Section 7.2.4) ---------
--------- 古いテキスト: (セクション7.2.4) ---------
Whenever an endpoint receives a SACK that indicates some TSN(s) missing, it SHOULD wait for 3 further miss indications (via subsequent SACK's) on the same TSN(s) before taking action with regard to Fast Retransmit.
終点がいくつかのTSN(s)の取り逃がすことを示すSACKを受けて、それがSHOULDであるときはいつも、Fast Retransmitに関して行動を取る前に、同じTSN(s)におけるさらなる3つのミス指摘(その後のSACKのものを通した)を待ってください。
When the TSN(s) is reported as missing in the fourth consecutive SACK, the data sender shall:
TSN(s)が第4連続したSACKに消えるとして報告されるとき、データ送付者は報告されるでしょう:
Stewart, et al. Informational [Page 21] RFC 4460 SCTP Errata April 2006
スチュワート、他 [21ページ]情報のRFC4460SCTP誤字2006年4月
1) Mark the missing DATA chunk(s) for retransmission,
1) 「再-トランスミッション」のためになくなったDATAが塊であるとマークしてください。
2) Adjust the ssthresh and cwnd of the destination address(es) to
which the missing DATA chunks were last sent, according to the
formula described in Section 7.2.3.
2) なくなったDATA塊が最後に送られた送付先アドレス(es)のssthreshとcwndを調整してください、セクション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.
3) 最も早いのについていくつ決定してくださいか(すなわち、最も低いTSN)。 「再-トランスミッション」のためにマークされたDATA塊はパケットが送られる送付先輸送アドレスの経路MTUの規制を条件として単一のパケットに収まるでしょう。 単一のパケットにこの値のK.RetransmitをそれらのK DATA塊と呼んでください。
4) Restart T3-rtx timer only if the last SACK acknowledged the lowest
outstanding TSN number sent to that address, or the endpoint is
retransmitting the first outstanding DATA chunk sent to that
address.
4) 最後のSACKがそのアドレスに送られる中で最も下位の傑出しているTSN番号を承認した場合にだけ、T3-rtxタイマを再開してください。さもないと、終点はそのアドレスに送られた最初の傑出しているDATA塊を再送しています。
Note: Before the above adjustments, if the received SACK also acknowledges new DATA chunks and advances the Cumulative TSN Ack Point, the cwnd adjustment rules defined in Sections 7.2.1 and 7.2.2 must be applied first.
以下に注意してください。 上の調整の前に、容認されたSACKがまた、新しいDATA塊を承認して、Cumulative TSN Ack Pointを進めるなら、cwnd調整は、セクション7.2.1と7.2で定義されて、最初に.2を適用しなければならないと裁決します。
A straightforward implementation of the above keeps a counter for each TSN hole reported by a SACK. The counter increments for each consecutive SACK reporting the TSN hole. After reaching 4 and starting the fast retransmit procedure, the counter resets to 0. Because cwnd in SCTP indirectly bounds the number of outstanding TSN's, the effect of TCP fast-recovery is achieved automatically with no adjustment to the congestion control window size.
上記での簡単な実現は、SACKがそれぞれのTSN穴へのカウンタを報告し続けます。 TSNを報告するそれぞれの連続したSACKのためのカウンタ増分は掘られます。 4に達して、速さを始めた後に、手順、カウンタリセットを0に再送してください。 傑出しているTSNのものの数がSCTPでcwndに間接的にバウンドしているので、TCPの速い回復の効果は調整なしで輻輳制御ウィンドウサイズに自動的に達成されます。
--------- New text: (Section 7.2.4) ---------
--------- 新しいテキスト: (セクション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.
終点がいくつかのTSNsがなくなって、それがSHOULDであることを示すSACKを受けるときはいつも、Fast Retransmitに関して行動を取る前に、同じTSN(s)におけるさらなる3つのミス指摘(その後のSACKsを通した)を待ってください。
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.
指摘SHOULDさんはHTNA(最も高いTSN Newly Acknowledged)アルゴリズムに従います。 それぞれの入って来るSACKに関しては、ミス指摘はなくなったTSNsのためだけにTSNのSACKで新たに承認される中で最も高い前で増加されます。 新たに承認されたDATA塊は以前にSACKで承認されなかったものです。 終点がFast Recoveryにあって、Cumulative TSN Ack Pointを進めるSACKが到着するなら、ミス指摘はSACKでなくなると報告されたすべてのTSNsのために増加されます。
Stewart, et al. Informational [Page 22] RFC 4460 SCTP Errata April 2006
スチュワート、他 [22ページ]情報のRFC4460SCTP誤字2006年4月
When the fourth consecutive miss indication is received for a TSN(s), the data sender shall do the following:
TSN(s)のために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) そうでなければ、Fast Recoveryでは、なくなったDATA塊が最後に送られた送付先アドレス(es)のssthreshとcwndを調整してください、セクション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. 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) 最も早いのについていくつ決定してくださいか(すなわち、最も低いTSN)。 「再-トランスミッション」のためにマークされたDATA塊はパケットが送られる送付先輸送アドレスの経路MTUの規制を条件として単一のパケットに収まるでしょう。 単一のパケットにこの値のK.RetransmitをそれらのK DATA塊と呼んでください。 Fast Retransmitが実行されているとき、送付者SHOULDはこの単一のパケットのためにcwndとSHOULD NOT遅れ「再-トランスミッション」の値を無視します。
4) Restart T3-rtx timer only if the last SACK acknowledged the lowest
outstanding TSN number sent to that address, or the endpoint is
retransmitting the first outstanding DATA chunk sent to that
address.
4) 最後のSACKがそのアドレスに送られる中で最も下位の傑出しているTSN番号を承認した場合にだけ、T3-rtxタイマを再開してください。さもないと、終点はそのアドレスに送られた最初の傑出しているDATA塊を再送しています。
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 TSNsを運ぶ送られたデータグラムをうまくはめ込まなかったFast Retransmitアルゴリズムのため「再-トランスミッション」のためにマークされたそれらのTSNsはマークされます。 しかしながら、「再-トランスミッション」のためにマークされるとき、それらは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) そうでなければ、Fast Recoveryに、Fast Recoveryを入れてください、そして、Fast Recoveryエキジットポイントとして最も高い傑出しているTSNをマークしてください。 SACKがこのエキジットポイントを含めてすべてのTSNsを承認すると、Fast Recoveryは出られます。 その後のFast Recovery出来事のため中でFast Recovery、ssthresh、およびcwnd SHOULD NOT変化をあらゆる目的地とゆったり過ごしてください(すなわち、あるSHOULD NOTがその後の断食への一層の支払われるべきものが再送するcwndを減少させます)。
Note: Before the above adjustments, if the received SACK also acknowledges new DATA chunks and advances the Cumulative TSN Ack Point, the cwnd adjustment rules defined in Sections 7.2.1 and 7.2.2 must be applied first.
以下に注意してください。 上の調整の前に、容認されたSACKがまた、新しいDATA塊を承認して、Cumulative TSN Ack Pointを進めるなら、cwnd調整は、セクション7.2.1と7.2で定義されて、最初に.2を適用しなければならないと裁決します。
2.8.3. Solution Description
2.8.3. ソリューション記述
The effect of the above wording changes are as follows:
上の言葉遣い変化の効果は以下の通りです:
Stewart, et al. Informational [Page 23] RFC 4460 SCTP Errata April 2006
スチュワート、他 [23ページ]情報のRFC4460SCTP誤字2006年4月
o It requires with a MUST the sending of GAP Ack blocks instead of
the current RFC 2960 [5] SHOULD.
o 現在のRFC2960[5]SHOULDの代わりにGAP Ackブロックの発信はaでそうしなければなりませんそれが、必要である。
o It allows a TSN being Fast Retransmitted (FR) to be sent only once
via FR.
o それは、Fast Retransmitted(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.
o TSNがFRに準備ができているとして特定されるとき、飛行サイズが低下するのを待ちながら、それは遅れに終わります。
o It changes the way chunks are marked during fast retransmit, so
that only new reports are counted.
o それはマークされた塊が速い間、再送されるので最新の報告だけが数えられる方法を変えます。
o It introduces a Fast Recovery period to avoid multiple congestion
window reductions when there are multiple losses in a single RTT
(as shown by Caro et al. [3]).
o それは、複数の損失が独身のRTTにあるとき、複数の混雑窓の減少を避けるためにFast Recoveryの期間を導入します。(ケアロ他で、示されます。 [3]).
These changes will effectively allow SCTP to follow a similar model as TCP+SACK in the handling of Fast Retransmit.
これらの変化で、事実上、SCTPはTCP+SACKとしてFast Retransmitの取り扱いで同様のモデルに従うことができるでしょう。
2.9. Missing Statement about partial_bytes_acked Update
2.9. 部分的な_バイト_acked Updateの周りのなくなったStatement
2.9.1. Description of the Problem
2.9.1. 問題の記述
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、および_がackedした部分的な_バイト。 SACKからのパケット損失の検出かそれともT3-rtxタイマがいつアドレスで期限が切れるかに関して、セクション7.2.3で述べられているようにcwndとssthreshをアップデートするべきです。 しかしながら、また、また、セクションがバイト_がackedしたその部分的な_をはっきりさせるべきであるのをアップデートしなければなりません。 それは0にリセットされなければなりません。
2.9.2. Text Changes to the Document
2.9.2. ドキュメントへのテキスト変化
--------- Old text: (Section 7.2.3) ---------
--------- 古いテキスト: (セクション7.2.3) ---------
7.2.3 Congestion Control
7.2.3 輻輳制御
Upon detection of packet losses from SACK (see Section 7.2.4), An endpoint should do the following:
SACK(セクション7.2.4を見る)からのパケット損失の検出のときに、An終点は以下をするべきです:
ssthresh = max(cwnd/2, 2*MTU)
cwnd = ssthresh
ssthresh=最大(cwnd/2、2*MTU)cwndはssthreshと等しいです。
Basically, a packet loss causes cwnd to be cut in half.
基本的に、パケット損失で、半分にcwndを切ります。
When the T3-rtx timer expires on an address, SCTP should perform slow start by:
T3-rtxタイマがアドレスで期限が切れると、SCTPは以下で遅れた出発を実行するはずです。
Stewart, et al. Informational [Page 24] RFC 4460 SCTP Errata April 2006
スチュワート、他 [24ページ]情報のRFC4460SCTP誤字2006年4月
ssthresh = max(cwnd/2, 2*MTU)
cwnd = 1*MTU
ssthresh=最大(cwnd/2、2*MTU)cwndは1*MTUと等しいです。
--------- New text: (Section 7.2.3) ---------
--------- 新しいテキスト: (セクション7.2.3) ---------
7.2.3. Congestion Control
7.2.3. 輻輳制御
Upon detection of packet losses from SACK (see Section 7.2.4), an endpoint should do the following if not in Fast Recovery:
そうでなければ、SACK(セクション7.2.4を見る)からのパケット損失の検出のときに、終点はFast Recoveryで以下をするべきです:
ssthresh = max(cwnd/2, 2*MTU)
cwnd = ssthresh
partial_bytes_acked = 0
_がackedしたssthreshの部分的な_ssthresh=最大(cwnd/2、2*MTU)cwnd=バイト=0
Basically, a packet loss causes cwnd to be cut in half.
基本的に、パケット損失で、半分にcwndを切ります。
When the T3-rtx timer expires on an address, SCTP should perform slow start by
いつまでに、T3-rtxタイマはアドレスで期限が切れて、SCTPは遅れた出発を実行するはずですか。
ssthresh = max(cwnd/2, 2*MTU)
cwnd = 1*MTU
partial_bytes_acked = 0
_がackedした1*MTUの部分的な_ssthresh=最大(cwnd/2、2*MTU)cwnd=バイト=0
2.9.3. Solution Description
2.9.3. ソリューション記述
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と共にそれを明らかにして、セクション7.2.3で述べられた状況でackedされた_とcwndでするべきことに関する疑問を解決します、また、0にリセットされることによって、_がackedした部分的な_バイトをアップデートするべきです。
2.10. Issues with Heartbeating and Failure Detection
2.10. Heartbeatingの問題と失敗検出
2.10.1. Description of the Problem
2.10.1. 問題の記述
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
スチュワート、他 [25ページ]情報のRFC4460SCTP誤字2006年4月
o When responding to a Heartbeat, it is unclear what to do if more
than a single TLV is present.
o Heartbeatに応じるとき、独身の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
2.10.2. ドキュメントへのテキスト変化
--------- Old text: (Section 8.1) ---------
--------- 古いテキスト: (セクション8.1) ---------
8.1 Endpoint Failure Detection
8.1 終点失敗検出
An endpoint shall keep a counter on the total number of consecutive retransmissions to its peer (including retransmissions to all the destination transport addresses of the peer if it is multi-homed). If the value of this counter exceeds the limit indicated in the protocol parameter 'Association.Max.Retrans', the endpoint shall consider the peer endpoint unreachable and shall stop transmitting any more data to it (and thus the association enters the CLOSED state). In addition, the endpoint shall report the failure to the upper layer, and optionally report back all outstanding user data remaining in its outbound queue. The association is automatically closed when the peer endpoint becomes unreachable.
終点が連続した「再-トランスミッション」の総数のカウンタを同輩に保つものとする、(それが含めるなら同輩のすべての送付先輸送アドレスに「再-トランスミッション」を含める、マルチ、家へ帰り、) このカウンタの値が'Association.Max.Retrans'というプロトコルパラメタで示された限界を超えているなら、終点は、同輩終点が手が届かないと考えて、それ以上のデータをそれに送るのを止めるものとします(その結果、協会はCLOSED状態に入ります)。 さらに、終点は、上側の層に失敗を報告して、任意に外国行きの待ち行列に残っているすべての傑出している利用者データの報告を持ちかえるものとします。 同輩終点が手が届かなくなるとき、協会は自動的に休業します。
The counter shall be reset each time a DATA chunk sent to that peer endpoint is acknowledged (by the reception of a SACK), or a HEARTBEAT-ACK is received from the peer endpoint.
その同輩終点に送られたDATA塊が承認されるたびに(SACKのレセプションで)カウンタをリセットするものとしますか、または同輩終点からHEARTBEAT-ACKを受け取ります。
Stewart, et al. Informational [Page 26] RFC 4460 SCTP Errata April 2006
スチュワート、他 [26ページ]情報のRFC4460SCTP誤字2006年4月
--------- New text: (Section 8.1) ---------
--------- 新しいテキスト: (セクション8.1) ---------
8.1. Endpoint Failure Detection
8.1. 終点失敗検出
An endpoint shall keep a counter on the total number of consecutive retransmissions to its peer (this includes retransmissions to all the destination transport addresses of the peer if it is multi-homed), including unacknowledged HEARTBEAT Chunks. If the value of this counter exceeds the limit indicated in the protocol parameter 'Association.Max.Retrans', the endpoint shall consider the peer endpoint unreachable and shall stop transmitting any more data to it (and thus the association enters the CLOSED state). In addition, the endpoint MAY report the failure to the upper layer and optionally report back all outstanding user data remaining in its outbound queue. The association is automatically closed when the peer endpoint becomes unreachable.
終点が連続した「再-トランスミッション」の総数のカウンタを同輩に保つものとする、(それが含めるならこれが同輩のすべての送付先輸送アドレスに「再-トランスミッション」を含める、マルチ、家へ帰り、)、不承認のHEARTBEAT Chunksを含んでいます。 このカウンタの値が'Association.Max.Retrans'というプロトコルパラメタで示された限界を超えているなら、終点は、同輩終点が手が届かないと考えて、それ以上のデータをそれに送るのを止めるものとします(その結果、協会はCLOSED状態に入ります)。 さらに、終点は、上側の層に失敗を報告して、任意に外国行きの待ち行列に残っているすべての傑出している利用者データの報告を持ちかえるかもしれません。 同輩終点が手が届かなくなるとき、協会は自動的に休業します。
The counter shall be reset each time a DATA chunk sent to that peer endpoint is acknowledged (by the reception of a SACK), or a HEARTBEAT-ACK is received from the peer endpoint.
その同輩終点に送られたDATA塊が承認されるたびに(SACKのレセプションで)カウンタをリセットするものとしますか、または同輩終点からHEARTBEAT-ACKを受け取ります。
--------- Old text: (Section 8.3) ---------
--------- 古いテキスト: (セクション8.3) ---------
8.3 Path Heartbeat
8.3 経路鼓動
By default, an SCTP endpoint shall monitor the reachability of the idle destination transport address(es) of its peer by sending a HEARTBEAT chunk periodically to the destination transport address(es).
デフォルトで、SCTP終点は、定期的に送付先輸送アドレス(es)にHEARTBEAT塊を送ることによって、同輩の無駄な送付先輸送アドレス(es)の可到達性をモニターするものとします。
--------- New text: (Section 8.3) ---------
--------- 新しいテキスト: (セクション8.3) ---------
8.3 Path Heartbeat
8.3 経路鼓動
By default, an SCTP endpoint SHOULD monitor the reachability of the idle destination transport address(es) of its peer by sending a HEARTBEAT chunk periodically to the destination transport address(es). HEARTBEAT sending MAY begin upon reaching the ESTABLISHED state and is discontinued after sending either SHUTDOWN or SHUTDOWN-ACK. A receiver of a HEARTBEAT MUST respond to a HEARTBEAT with a HEARTBEAT-ACK after entering the COOKIE-ECHOED state
デフォルトで、SCTP終点SHOULDは、定期的に送付先輸送アドレス(es)にHEARTBEAT塊を送ることによって、同輩の無駄な送付先輸送アドレス(es)の可到達性をモニターします。 HEARTBEAT発信は、ESTABLISHED状態に達して、攻撃するかもしれなくて、SHUTDOWNかSHUTDOWN-ACKのどちらかを送った後に、中止されます。 HEARTBEAT MUSTの受信機はCOOKIE-ECHOED状態に入った後に、HEARTBEAT-ACKと共にHEARTBEATに応じます。
Stewart, et al. Informational [Page 27] RFC 4460 SCTP Errata April 2006
スチュワート、他 [27ページ]情報のRFC4460SCTP誤字2006年4月
(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).
(INIT送付者)かESTABLISHEDが(INIT受信機)を述べます、SHUTDOWN-SENT州(SHUTDOWN送付者)かSHUTDOWN- ACK-SENT状態(SHUTDOWN受信機)に達するまで。
--------- Old text: (Section 8.3) ---------
--------- 古いテキスト: (セクション8.3) ---------
The receiver of the HEARTBEAT should immediately respond with a HEARTBEAT ACK that contains the Heartbeat Information field copied from the received HEARTBEAT chunk.
HEARTBEATの受信機はすぐに、容認されたHEARTBEAT塊からコピーされたHeartbeat情報分野を含むHEARTBEAT ACKと共に応じるはずです。
--------- New text: (Section 8.3) ---------
--------- 新しいテキスト: (セクション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を含むHEARTBEAT ACKと共に応じるはずです、容認されたHEARTBEAT塊から変わりがない状態でコピーされたいかなる他の容認されたTLVsと共にも。
--------- Old text: (Section 8.3) ---------
--------- 古いテキスト: (セクション8.3) ---------
On an idle destination address that is allowed to heartbeat, a HEARTBEAT chunk is RECOMMENDED to be sent once per RTO of that destination address plus the protocol parameter 'HB.interval' , with jittering of +/- 50%, and exponential back-off of the RTO if the previous HEARTBEAT is unanswered.
HEARTBEAT塊が+/- 50%のジッタリングと共にその送付先アドレスと'HB.interval'というプロトコルパラメタのRTOに一度送って、指数である鼓動に許容されている無駄な送付先アドレスではRECOMMENDEDである、逆、-、RTOが前のHEARTBEATであるなら答えがありません。
--------- New text: (Section 8.3) ---------
--------- 新しいテキスト: (セクション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.
鼓動に許容されている無駄な送付先アドレスではHEARTBEAT塊が+/- RTO価値の50%のジッタリングと共にその送付先アドレスと'HB.interval'というプロトコルパラメタのRTOに一度送って、指数であることが、お勧めである、逆、-、RTOが前のHEARTBEATであるなら答えがありません。
2.10.3. Solution Description
2.10.3. ソリューション記述
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,
上のテキストはどうセクション2.10.1で参照された5冊に応じるかに関して指導を提供します。 いつ始まって、heartbeatingするのを止めるかに関して特に、言葉遣い変化は指導を提供します。
Stewart, et al. Informational [Page 28] RFC 4460 SCTP Errata April 2006
スチュワート、他 [28ページ]情報のRFC4460SCTP誤字2006年4月
how to respond to a heartbeat with extra parameters, and it clarifies the error counting procedures for the association.
余分なパラメタ、およびそれでどう鼓動に応じるかは協会のために手順を数える誤りをはっきりさせます。
2.11. Security interactions with firewalls
2.11. ファイアウォールとのセキュリティ相互作用
2.11.1. Description of the Problem
2.11.1. 問題の記述
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
2.11.2. ドキュメントへのテキスト変化
--------- New text: (no old text, new section added) ---------
--------- 新しいテキスト: (古いテキストがない、加えられた新しいセクション) ---------
11.4 SCTP Interactions with Firewalls
11.4 ファイアウォールとのSCTP相互作用
It is helpful for some firewalls if they can inspect just the first fragment of a fragmented SCTP packet and unambiguously determine whether it corresponds to an INIT chunk (for further information, please refer to RFC1858). Accordingly, we stress the requirements, stated in 3.1, that (1) an INIT chunk MUST NOT be bundled with any other chunk in a packet, and (2) a packet containing an INIT chunk MUST have a zero Verification Tag. Furthermore, we require that the receiver of an INIT chunk MUST enforce these rules by silently discarding an arriving packet with an INIT chunk that is bundled with other chunks.
まさしく断片化しているSCTPパケットの最初の断片を点検して、それがINIT塊に対応するかどうか(詳細について、RFC1858を参照してください)明白に決定できるなら、いくつかのファイアウォールにおいて、役立っています。 (2) それに従って、私たちは(1) いかなる他の塊もパケットにある状態でINIT塊を束ねてはいけないという3.1で述べられた要件を強調します、そして、INIT塊を含むパケットはVerification Tagを全く持ってはいけません。 その上、私たちは、INIT塊の受信機が他の塊で束ねられるINIT塊で静かに到着パケットを捨てることによってこれらの規則を実施しなければならないのを必要とします。
--------- Old text: (Section 18) ---------
--------- 古いテキスト: (セクション18) ---------
18. Bibliography
18. 図書目録
[ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End
Network Path Properties", Proc. SIGCOMM'99, 1999.
[ALLMAN99]オールマン、M.、およびパクソン対「終わりから端へのネットワーク経路が土地であると見積もっている」ときのProc SIGCOMM'99、1999'。
[FALL96] Fall, K. and Floyd, S., Simulation-based Comparisons of
Tahoe, Reno, and SACK TCP, Computer Communications Review,
V. 26 N. 3, July 1996, pp. 5-21.
[FALL96] 秋とK.とフロイドとS.、タホ、リノのSimulationベースのComparisonsとSACK TCP、コンピュータCommunications Review、V.26N.3、1996年7月、ページ 5-21.
[RFC1750] Eastlake, D. (ed.), "Randomness Recommendations for
Security", RFC 1750, December 1994.
[RFC1750]イーストレーク、D.編、「セキュリティのための偶発性推薦」、RFC1750、1994年12月。
Stewart, et al. Informational [Page 29] RFC 4460 SCTP Errata April 2006
スチュワート、他 [29ページ]情報のRFC4460SCTP誤字2006年4月
[RFC1950] Deutsch P. and J. Gailly, "ZLIB Compressed Data Format
Specification version 3.3", RFC 1950, May 1996.
[RFC1950] ドイツ語P.とJ.ゲイル、「ZLIB Compressed Data Format Specification、バージョン3.3インチ、RFC1950、1996インチ年5月。
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, March 1997.
[RFC2104] Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年3月。
[RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196,
September 1997.
[RFC2196] フレーザ、B.、「サイトセキュリティハンドブック」、FYI8、RFC2196、1997年9月。
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management
Protocol", RFC 2522, March 1999.
[RFC2522] Karn、P.、およびW.シンプソン、「Photuris:」 「セッションKey Managementプロトコル」、RFC2522、1999年3月。
[SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T.,
"TCP Congestion Control with a Misbehaving Receiver", ACM
Computer Communication Review, 29(5), October 1999.
[SAVAGE99]サヴェージとS.とカードウェルとN.とWetherall、D.とアンダーソン、T.、「ふらちな事する受信機とのTCP輻輳制御」ACMコンピュータコミュニケーションレビュー、29(5)(1999年10月)。
--------- New text: (Section 18) ---------
--------- 新しいテキスト: (セクション18) ---------
18. Bibliography
18. 図書目録
[ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End
Network Path Properties", Proc. SIGCOMM'99, 1999.
[ALLMAN99]オールマン、M.、およびパクソン対「終わりから端へのネットワーク経路が土地であると見積もっている」ときのProc SIGCOMM'99、1999'。
[FALL96] Fall, K. and Floyd, S., Simulation-based Comparisons of
Tahoe, Reno, and SACK TCP, Computer Communications Review,
V. 26 N. 3, July 1996, pp. 5-21.
[FALL96] 秋とK.とフロイドとS.、タホ、リノのSimulationベースのComparisonsとSACK TCP、コンピュータCommunications Review、V.26N.3、1996年7月、ページ 5-21.
[RFC1750] Eastlake, D. (ed.), "Randomness Recommendations for
Security", RFC 1750, December 1994.
[RFC1750]イーストレーク、D.編、「セキュリティのための偶発性推薦」、RFC1750、1994年12月。
[RFC1858] Ziemba, G., Reed, D. and Traina P., "Security
Considerations for IP Fragment Filtering", RFC 1858,
October 1995.
[RFC1858] ZiembaとG.とリードとD.とTraina P.、「IP断片フィルタリングのためのセキュリティ問題」、RFC1858、1995年10月。
[RFC1950] Deutsch P. and J. Gailly, "ZLIB Compressed Data Format
Specification version 3.3", RFC 1950, May 1996.
[RFC1950] ドイツ語P.とJ.ゲイル、「ZLIB Compressed Data Format Specification、バージョン3.3インチ、RFC1950、1996インチ年5月。
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, March 1997.
[RFC2104] Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年3月。
[RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196,
September 1997.
[RFC2196] フレーザ、B.、「サイトセキュリティハンドブック」、FYI8、RFC2196、1997年9月。
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management
Protocol", RFC 2522, March 1999.
[RFC2522] Karn、P.、およびW.シンプソン、「Photuris:」 「セッションKey Managementプロトコル」、RFC2522、1999年3月。
Stewart, et al. Informational [Page 30] RFC 4460 SCTP Errata April 2006
スチュワート、他 [30ページ]情報のRFC4460SCTP誤字2006年4月
[SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T.,
"TCP Congestion Control with a Misbehaving Receiver", ACM
Computer Communication Review, 29(5), October 1999.
[SAVAGE99]サヴェージとS.とカードウェルとN.とWetherall、D.とアンダーソン、T.、「ふらちな事する受信機とのTCP輻輳制御」ACMコンピュータコミュニケーションレビュー、29(5)(1999年10月)。
2.11.3. Solution Description
2.11.3. ソリューション記述
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).
上のテキスト、どのような場合でも、静かにこの規則に従わないパケットを捨てるいかなる他の塊でもINIT塊を束ねてはいけません(この規則はパケット受信機によって励行されます)。(それは、RFC2960[5]のSecurity Considerations部への新しい小区分がファイアウォールとの相互作用をより簡単にするようにそれを明らかにすると言い足します)。
2.12. Shutdown Ambiguity
2.12. 閉鎖のあいまいさ
2.12.1. Description of the Problem
2.12.1. 問題の記述
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
2.12.2. ドキュメントへのテキスト変化
--------- Old text: (Section 9.2) ---------
--------- 古いテキスト: (セクション9.2) ---------
If there are still outstanding DATA chunks left, the SHUTDOWN receiver shall continue to follow normal data transmission procedures defined in Section 6 until all outstanding DATA chunks are acknowledged; however, the SHUTDOWN receiver MUST NOT accept new data from its SCTP user.
傑出しているDATA塊がまだ残っているなら、SHUTDOWN受信機は、すべての傑出しているDATA塊が承認されるまでセクション6で定義された正常なデータ伝送手順に従い続けているものとします。 しかしながら、SHUTDOWN受信機はSCTPユーザから新しいデータを受け入れてはいけません。
While in SHUTDOWN-SENT state, the SHUTDOWN sender MUST immediately respond to each received packet containing one or more DATA chunk(s) with a SACK, a SHUTDOWN chunk, and restart the T2-shutdown timer. If it has no more outstanding DATA chunks, the SHUTDOWN receiver shall send a SHUTDOWN ACK and start a T2-shutdown timer of its own, entering the SHUTDOWN-ACK-SENT state. If the timer expires, the endpoint must re-send the SHUTDOWN ACK.
SHUTDOWN送付者は、SHUTDOWN-SENT状態ですぐに、SACKがある1つ以上のDATA塊、SHUTDOWN塊を含むそれぞれの容認されたパケットに応じて、T2-閉鎖タイマを再開しなければなりませんが。 それにそれ以上の傑出しているDATA塊がないなら、SHUTDOWN受信機は、SHUTDOWN ACKを送って、それ自身のT2-閉鎖タイマを始動するものとします、SHUTDOWN-ACK-SENT状態に入って。 タイマが期限が切れるなら、終点はSHUTDOWN ACKを再送しなければなりません。
Stewart, et al. Informational [Page 31] RFC 4460 SCTP Errata April 2006
スチュワート、他 [31ページ]情報のRFC4460SCTP誤字2006年4月
--------- New text: (Section 9.2) ---------
--------- 新しいテキスト: (セクション9.2) ---------
If there are still outstanding DATA chunks left, the SHUTDOWN receiver MUST continue to follow normal data transmission procedures defined in Section 6, until all outstanding DATA chunks are acknowledged; however, the SHUTDOWN receiver MUST NOT accept new data from its SCTP user.
傑出しているDATA塊がまだ残っているなら、SHUTDOWN受信機は、セクション6で定義された正常なデータ伝送手順に従い続けなければなりません、すべての傑出しているDATA塊が承認されるまで。 しかしながら、SHUTDOWN受信機はSCTPユーザから新しいデータを受け入れてはいけません。
While in SHUTDOWN-SENT state, the SHUTDOWN sender MUST immediately respond to each received packet containing one or more DATA chunks with a SHUTDOWN chunk and restart the T2-shutdown timer. If a SHUTDOWN chunk by itself cannot acknowledge all of the received DATA chunks (i.e., there are TSNs that can be acknowledged that are larger than the cumulative TSN, and thus gaps exist in the TSN sequence), or if duplicate TSNs have been received, then a SACK chunk MUST also be sent.
SHUTDOWN送付者は、SHUTDOWN-SENT状態ですぐに、SHUTDOWN塊で1つ以上のDATA塊を含むそれぞれの容認されたパケットに応じて、T2-閉鎖タイマを再開しなければなりませんが。 また、それ自体でSHUTDOWN塊が容認されたDATA塊のすべてを承認できないか(すなわち、承認されて、それが累積しているTSNより大きく、その結果、ギャップがTSN系列で存在しているということであることができるTSNsがあります)、または写しTSNsを受け取ったなら、SACK塊を送らなければなりません。
The sender of the SHUTDOWN MAY also start an overall guard timer 'T5-shutdown-guard' to bound the overall time for shutdown sequence. At the expiration of this timer, the sender SHOULD abort the association by sending an ABORT chunk. If the 'T5-shutdown-guard' timer is used, it SHOULD be set to the recommended value of 5 times 'RTO.Max'.
また、SHUTDOWN MAYの送付者はバウンドへの総合的な警備タイマ'T5閉鎖警備'のために閉鎖系列のための全治療期間を始めます。 このタイマの満了のときに、送付者SHOULDは、ABORT塊を送ることによって、協会を中止します。 タイマは'T5閉鎖警備'であるなら使用されていて、それはSHOULDです。5回'RTO.Max'について推奨値に設定されます。
If the receiver of the SHUTDOWN has no more outstanding DATA chunks, the SHUTDOWN receiver MUST send a SHUTDOWN ACK and start a T2-shutdown timer of its own, entering the SHUTDOWN-ACK-SENT state. If the timer expires, the endpoint must re-send the SHUTDOWN ACK.
SHUTDOWNの受信機にそれ以上の傑出しているDATA塊がないなら、SHUTDOWN受信機は、SHUTDOWN ACKを送って、それ自身のT2-閉鎖タイマを始動しなければなりません、SHUTDOWN-ACK-SENT状態に入って。 タイマが期限が切れるなら、終点はSHUTDOWN ACKを再送しなければなりません。
2.12.3. Solution Description
2.12.3. ソリューション記述
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の使用をはっきりさせます。 また、それは、SHUTDOWN塊の誤った受信機から守るためにSCTP閉鎖系列に警備タイマを追加します。
2.13. Inconsistency in ABORT Processing
2.13. アボート処理における矛盾
2.13.1. Description of the Problem
2.13.1. 問題の記述
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における言葉遣いがVerification Tagsとの'Tビット'の使用の適切な指示を与えなかったことに注意されました。
Stewart, et al. Informational [Page 32] RFC 4460 SCTP Errata April 2006
スチュワート、他 [32ページ]情報のRFC4460SCTP誤字2006年4月
2.13.2. Text changes to the document
2.13.2. ドキュメントへのテキスト変化
--------- Old text: (Section 8.5.1) ---------
--------- 古いテキスト: (セクション8.5.1) ---------
B) Rules for packet carrying ABORT:
B) ABORTを運ぶパケットのための規則:
- The endpoint shall always fill in the Verification Tag field
of the outbound packet with the destination endpoint's tag
value if it is known.
- それが知られているなら、終点はいつも目的地終点のタグ値で外国行きのパケットのVerification Tag分野に記入するものとします。
- If the ABORT is sent in response to an OOTB packet, the
endpoint MUST follow the procedure described in Section 8.4.
- OOTBパケットに対応してABORTを送るなら、終点はセクション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.
- Verification Tagがそれ自身のタグに合っているなら、受信機はパケットを受け入れなければならなくて、ORは同輩のタグです。 さもなければ、受信機は、静かにパケットを捨てて、これ以上行動を取ってはいけません。
--------- New text: (Section 8.5.1) ---------
--------- 新しいテキスト: (セクション8.5.1) ---------
B) Rules for packet carrying ABORT:
B) ABORTを運ぶパケットのための規則:
- The endpoint MUST always fill in the Verification Tag field of
the outbound packet with the destination endpoint's tag value,
if it is known.
- 終点はいつも目的地終点のタグ値で外国行きのパケットのVerification Tag分野に記入しなければなりません、それが知られているなら。
- If the ABORT is sent in response to an OOTB packet, the
endpoint MUST follow the procedure described in Section 8.4.
- OOTBパケットに対応してABORTを送るなら、終点はセクション8.4で説明された手順に従わなければなりません。
- The receiver of a ABORT MUST accept the packet if the
Verification Tag field of the packet matches its own tag OR if
it is set to its peer's tag and the T bit is set in the Chunk
Flags. Otherwise, the receiver MUST silently discard the
packet and take no further action.
- それが同輩のタグに設定されて、TビットがChunk Flagsに設定されるならパケットのVerification Tag分野がそれ自身のタグORに合っているなら、ABORT MUSTの受信機はパケットを受け入れます。 さもなければ、受信機は、静かにパケットを捨てて、これ以上行動を取ってはいけません。
2.13.3. Solution Description
2.13.3. ソリューション記述
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
スチュワート、他 [33ページ]情報のRFC4460SCTP誤字2006年4月
2.14. Cwnd Gated by Its Full Use
2.14. 完全利用で外出を禁止されたCwnd
2.14.1. Description of the Problem
2.14.1. 問題の記述
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はFast Recoveryの間、増加するべきではありません、Fast Recoveryの間の完全なcwndが完全に利用されるとしてcwndに資格を与えないので。 さらに、単一の窓の複数の損失シナリオで、窓の損害件数が[3]を増加させるのに応じて、cwndは、より急速に成長するかもしれません。
2.14.2. Text Changes to the Document
2.14.2. ドキュメントへのテキスト変化
--------- Old text: (Section 6.1) ---------
--------- 古いテキスト: (セクション6.1) ---------
D) Then, the sender can send out as many new DATA chunks as Rule A
and Rule B above allow.
D) そして、Rule AとRule Bとしての上の多くの新しいDATA塊が許容するように送付者は出すことができます。
--------- New text: (Section 6.1) ---------
--------- 新しいテキスト: (セクション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によって適用されるかもしれません:
if((flightsize + Max.Burst*MTU) < cwnd)
cwnd = flightsize + Max.Burst*MTU
((+ Max.Burst*MTUをflightsizeします)<cwnd)cwnd=が+ Max.Burst*MTUをflightsizeするなら
Or it MAY be applied by strictly limiting the number of packets
emitted by the output routine.
または、それは、厳密に出力ルーチンで放たれたパケットの数を制限することによって、適用されるかもしれません。
E) Then, the sender can send out as many new DATA chunks as Rule A
and Rule B allow.
E) そして、Rule AとRule Bが許容するように送付者は同じくらい多くの新しいDATA塊を出すことができます。
Stewart, et al. Informational [Page 34] RFC 4460 SCTP Errata April 2006
スチュワート、他 [34ページ]情報のRFC4460SCTP誤字2006年4月
--------- Old text: (Section 7.2.1) ---------
--------- 古いテキスト: (セクション7.2.1) ---------
o When cwnd is less than or equal to ssthresh an SCTP endpoint MUST
use the slow start algorithm to increase cwnd (assuming the
current congestion window is being fully utilized). If an
incoming SACK advances the Cumulative TSN Ack Point, cwnd MUST be
increased by at most the lesser of 1) the total size of the
previously outstanding DATA chunk(s) acknowledged, and 2) the
destination's path MTU. This protects against the ACK-Splitting
attack outlined in [SAVAGE99].
o cwndが、よりssthresh以下であるときに、SCTP終点は、cwndを増加させるのに遅れた出発アルゴリズムを使用しなければなりません(現在の混雑ウィンドウを仮定するのは完全に利用されています)。 入って来るSACKがCumulative TSN Ack Pointを進めるなら、cwndによる高々増加して、以前に傑出しているDATA塊の総サイズが承認した1、)および2で)目的地の経路MTUが、より少ないということでなければなりません。 これは[SAVAGE99]に概説されたACK-分かれる攻撃から守ります。
--------- New text: (Section 7.2.1) ---------
--------- 新しいテキスト: (セクション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終点はcwndを増加させるのに遅れた出発アルゴリズムを使用しなければなりません、そして、入って来るSACKはCumulative TSN Ack Pointを進めます、そして、データ送付者はFast Recoveryにいません。 これらの3つの条件が満たされるときだけ、cwndは増加できます。 さもなければ、cwndを増加させてはいけません。 これらの状態が会われます、次に、cwndが増加しなければならないということであるなら、目的地の経路MTUは以前に傑出しているDATA塊の総サイズが承認した1、)および2で)高々、少ないです。 この上限は[SAVAGE99]に概説されたACK-分かれる攻撃から守ります。
--------- Old text: (Section 14) ---------
--------- 古いテキスト: (セクション14) ---------
14. Suggested SCTP Protocol Parameter Values
14. 提案されたSCTPプロトコルパラメタ値
The following protocol parameters are RECOMMENDED:
以下のプロトコルパラメタはRECOMMENDEDです:
RTO.Initial - 3 seconds RTO.Min - 1 second RTO.Max - 60 seconds RTO.Alpha - 1/8 RTO.Beta - 1/4 Valid.Cookie.Life - 60 seconds Association.Max.Retrans - 10 attempts Path.Max.Retrans - 5 attempts (per destination address) Max.Init.Retransmits - 8 attempts HB.interval - 30 seconds
RTO.Initial--3秒のRTO.Min--1 第2RTO.Max--60秒のRTO.Alpha----1/4Valid.Cookie.Life--60秒Association.Max.Retrans(10試みPath.Max.Retrans)5試み(送付先アドレスあたりの)Max.Init.Retransmits--8試みHB.interval--30秒の1/8RTO.Beta
Stewart, et al. Informational [Page 35] RFC 4460 SCTP Errata April 2006
スチュワート、他 [35ページ]情報のRFC4460SCTP誤字2006年4月
--------- New text: (Section 14) ---------
--------- 新しいテキスト: (セクション14) ---------
14. Suggested SCTP Protocol Parameter Values
14. 提案されたSCTPプロトコルパラメタ値
The following protocol parameters are RECOMMENDED:
以下のプロトコルパラメタはRECOMMENDEDです:
RTO.Initial - 3 seconds RTO.Min - 1 second RTO.Max - 60 seconds Max.Burst - 4 RTO.Alpha - 1/8 RTO.Beta - 1/4 Valid.Cookie.Life - 60 seconds Association.Max.Retrans - 10 attempts Path.Max.Retrans - 5 attempts (per destination address) Max.Init.Retransmits - 8 attempts HB.Interval - 30 seconds
RTO.Initial--3秒のRTO.Min--1 第2RTO.Max--60 Max.Burst--4RTO.Alpha--1/8RTO.Beta--1/4Valid.Cookie.Life--8がHB.Intervalを試みるという30秒の秒60秒Association.Max.Retrans(10試みPath.Max.Retrans)5試み(送付先アドレスあたりの)Max.Init.Retransmits
2.14.3. Solution Description
2.14.3. ソリューション記述
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
2.15. SCTPの窓の徹底的調査
2.15.1. Description of the Problem
2.15.1. 問題の記述
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
2.15.2. ドキュメントへのテキスト変化
--------- Old text: (Section 6.2) ---------
--------- 古いテキスト: (セクション6.2) ---------
The SCTP endpoint MUST always acknowledge the receipt of each valid DATA chunk.
SCTP終点はいつもそれぞれの有効なDATA塊の領収書を受け取ったことを知らせなければなりません。
Stewart, et al. Informational [Page 36] RFC 4460 SCTP Errata April 2006
スチュワート、他 [36ページ]情報のRFC4460SCTP誤字2006年4月
--------- New text: (Section 6.2) ---------
--------- 新しいテキスト: (セクション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塊のレセプションが中であると認めなければならない、それ、窓を受けてください。
When the receiver's advertised window is 0, the receiver MUST drop any new incoming DATA chunk with a TSN larger than the largest TSN received so far. If the new incoming DATA chunk holds a TSN value less than the largest TSN received so far, then the receiver SHOULD drop the largest TSN held for reordering and accept the new incoming DATA chunk. In either case, if such a DATA chunk is dropped, the receiver MUST immediately send back a SACK with the current receive window showing only DATA chunks received and accepted so far. The dropped DATA chunk(s) MUST NOT be included in the SACK, as they were not accepted. The receiver MUST also have an algorithm for advertising its receive window to avoid receiver silly window syndrome (SWS), as described in RFC 813. The algorithm can be similar to the one described in Section 4.2.3.3 of RFC 1122.
受信機の広告を出している窓が0であるときに、TSNが最も大きいTSNが今までのところ受信したより大きい状態で受信機はどんな新しい入って来るDATA塊も落とさなければなりません。 新しい入って来るDATA塊が最も大きいTSNが今までのところ受信したほどTSN値を保持しないなら、受信機SHOULDは再命令するために持たれている中で最も大きいTSNを落として、新しい入って来るDATA塊を受け入れます。 どちらの場合ではも、そのようなDATA塊が落とされるなら、受信機はすぐに、電流を塊が受信されたのをDATAだけに示す窓を受けて、今までのところ受け入れていてSACKを返送しなければなりません。 それらが受け入れられなかったので、SACKに低下しているDATA塊を含んではいけません。 また、受信機には広告のためのアルゴリズムがなければならない、それ、窓を受けて、受信機の愚かな窓のシンドローム(SWS)を避けてください、RFC813で説明されるように。 アルゴリズムは1つ説明されたコネセクション4.2.3.3RFC1122と同様である場合があります。
--------- Old text: (Section 6.1) ---------
--------- 古いテキスト: (セクション6.1) ---------
A) At any given time, the data sender MUST NOT transmit new data to
any destination transport address if its peer's rwnd indicates
that the peer has no buffer space (i.e., rwnd is 0, see Section
6.2.1). However, regardless of the value of rwnd (including if it
is 0), the data sender can always have one DATA chunk in flight to
the receiver if allowed by cwnd (see rule B below). This rule
allows the sender to probe for a change in rwnd that the sender
missed due to the SACK having been lost in transit from the data
receiver to the data sender.
a) その時々で、同輩のrwndが、同輩にはバッファ領域が全くないのを示すなら(すなわち、rwndは0です、とセクション6.2.1は見ます)、データ送付者はどんな送付先輸送アドレスにも新しいデータを送ってはいけません。 しかしながら、rwnd(それが0であるかどうかを含んでいる)の値にかかわらず、cwndによって許容されているなら、データ送付者はいつも受信機へのフライトでの1つのDATA塊を持つことができます(以下の規則Bを見てください)。 この規則で、送付者は送付者がデータ受信装置からデータ送付者までのトランジットでなくされたSACKのためなくしたrwndで珍しく調べることができます。
Stewart, et al. Informational [Page 37] RFC 4460 SCTP Errata April 2006
スチュワート、他 [37ページ]情報のRFC4460SCTP誤字2006年4月
--------- New text: (Section 6.1) ---------
--------- 新しいテキスト: (セクション6.1) ---------
A) At any given time, the data sender MUST NOT transmit new data to
any destination transport address if its peer's rwnd indicates
that the peer has no buffer space (i.e., rwnd is 0; see Section
6.2.1). However, regardless of the value of rwnd (including if it
is 0), the data sender can always have one DATA chunk in flight to
the receiver if allowed by cwnd (see rule B, below). This rule
allows the sender to probe for a change in rwnd that the sender
missed due to the SACK's having been lost in transit from the data
receiver to the data sender.
a) 同輩のrwndが、同輩にはバッファ領域が全くないのを示すなら、その時々で、データ送付者はどんな送付先輸送アドレスにも新しいデータを送ってはいけません。(すなわち、rwndは0です。 セクション6.2.1を)見てください。 しかしながら、rwnd(それが0であるかどうかを含んでいる)の値にかかわらず、cwndによって許容されているなら、データ送付者はいつも受信機へのフライトでの1つのDATA塊を持つことができます(以下で規則Bを見てください)。 この規則で、送付者はSACKの有のためいなくて寂しい送付者がいるrwndで珍しくデータ受信装置からデータ送付者までのトランジットで無くなった状態で調べることができます。
When the receiver's advertised window is zero, this probe is
called a zero window probe. Note that a zero window probe
SHOULD only be sent when all outstanding DATA chunks have
been cumulatively acknowledged and no DATA chunks are in
flight. Zero window probing MUST be supported.
受信機の広告を出している窓がゼロであるときに、この徹底的調査は窓が調べるゼロと呼ばれます。 すべての傑出しているDATA塊が累積的に承認されて、DATA塊が全く飛行でないときだけ、窓の徹底的調査がないSHOULDが送られることに注意してください。 窓の調べを支持してはいけません。
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.
送付者が、受信機から新しいパケットを受け続けているなら調べ、徹底的調査が増加するべきでない不承認の窓をどんな窓にもしていない間協会のための誤りカウンタかどんな目的地輸送address.Thisも受信機が、無期限に窓を閉じ続けるかもしれないからです。 それがaゼロの窓の広告を出したら受信機の振舞いのときにセクション6.2を参照してください。 SHOULDが1番目を送る送付者は窓の徹底的調査のゼロに合っています。それがそれを検出する1RTOの後に、受信機は窓を閉じました、そして、SHOULDはその後、徹底的調査間隔を指数関数的に増加させます。 また、セクション7.2.1に応じてcwnd 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.
また、送付者には、RFC813で説明されるように愚かな窓のシンドローム(SWS)を避けるために新しいDATA塊を送るためのアルゴリズムがなければなりません。 アルゴリズムは1つ説明されたコネセクション4.2.3.4RFC1122と同様である場合があります。
2.15.3. Solution Description
2.15.3. ソリューション記述
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.
上で、受信機は消えるとして到着しますが、SACKに変わりがない状態で(新しいa_rwndの可能な例外がある)状態を示させるようにまだ受信機を必要としている新しいデータと低下している塊を落とすことができます。 これはrwnd状態がクリアされるまで続く協会を許容するでしょう。
Stewart, et al. Informational [Page 38] RFC 4460 SCTP Errata April 2006
スチュワート、他 [38ページ]情報のRFC4460SCTP誤字2006年4月
2.16. Fragmentation and Path MTU Issues
2.16. 断片化と経路MTU問題
2.16.1. Description of the Problem
2.16.1. 問題の記述
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.
FragmentationとReassemblyの現在の言葉遣いによって、断片化を支持する実現はいつもやむを得ず断片化します。 これが禁止する、無効にするオプションをユーザに提供するのからのSCTP断片化ポイントを超えている実現は発信します。
The restriction in RFC 2960 [5], Section 6.9, was never meant to restrict an implementations API from this behavior.
RFC2960[5]での制限(セクション6.9)はこの振舞いから実現APIを決して制限することになっていませんでした。
2.16.2. Text Changes to the Document
2.16.2. ドキュメントへのテキスト変化
--------- Old text: (Section 6.1) ---------
--------- 古いテキスト: (セクション6.1) ---------
6.9 Fragmentation and Reassembly
6.9 断片化と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.
終点は、塊をDATAに送るとき、断片化を支持するかもしれませんが、DATA塊を受けるとき、再アセンブリを支持しなければなりません。 終点が断片化を支持するなら、外国行きのSCTPパケットサイズが送られるべきユーザメッセージのサイズで現在のMTUを超えているなら、それはユーザメッセージを断片化しなければなりません。 実現が外国行きのユーザメッセージの断片化を支持しないなら、終点は、上側の層に誤りを返して、ユーザメッセージを送るのを試みてはいけません。
IMPLEMENTATION NOTE: In this error case, the Send primitive discussed in Section 10.1 would need to return an error to the upper layer.
実現注意: この誤り事件では、セクション10.1で議論したSend基関数は、上側の層に誤りを返す必要があるでしょう。
--------- New text: (Section 6.1) ---------
--------- 新しいテキスト: (セクション6.1) ---------
6.9. Fragmentation and Reassembly
6.9. 断片化と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.
塊をDATAに送るとき、終点は断片化を支持するかもしれませんが、DATA塊を受けるとき、それは再アセンブリを支持しなければなりません。 終点が断片化を支持するなら、外国行きのSCTPパケットサイズが送られるべきユーザメッセージのサイズで現在のMTUを超えているなら、それはユーザメッセージを断片化しなければなりません。 実現が外国行きのユーザメッセージの断片化を支持しないなら、終点は、上側の層に誤りを返して、ユーザメッセージを送るのを試みてはいけません。
Stewart, et al. Informational [Page 39] RFC 4460 SCTP Errata April 2006
スチュワート、他 [39ページ]情報のRFC4460SCTP誤字2006年4月
Note: If an implementation that supports fragmentation makes available to its upper layer a mechanism to turn off fragmentation it may do so. However, in so doing, it MUST react just like an implementation that does NOT support fragmentation, i.e., it MUST reject sends that exceed the current P-MTU.
以下に注意してください。 断片化からターンするメカニズムが断片化を支持する実現で上側の層に利用可能になるなら、それはそうするかもしれません。 しかしながら、そうする際に、それはまさしくすなわち、断片化、それがそうしなければならないサポートでないのをする実現のように反応しなければなりません。現在のP-MTUを超えている廃棄物が発信します。
IMPLEMENTATION NOTE: In this error case, the Send primitive discussed in Section 10.1 would need to return an error to the upper layer.
実現注意: この誤り事件では、セクション10.1で議論したSend基関数は、上側の層に誤りを返す必要があるでしょう。
2.16.3. Solution Description
2.16.3. ソリューション記述
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
2.17. 累積しているTSN Ackの初期の値
2.17.1. Description of the Problem
2.17.1. 問題の記述
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
2.17.2. ドキュメントへのテキスト変化
--------- Old text: (Section 3.3.4) ---------
--------- 古いテキスト: (セクション3.3.4) ---------
Cumulative TSN Ack: 32 bits (unsigned integer)
累積しているTSN Ack: 32ビット(符号のない整数)
This parameter contains the TSN of the last DATA chunk received in
sequence before a gap.
このパラメタはギャップの連続して前に受け取られた最後のDATA塊のTSNを含んでいます。
--------- New text: (Section 3.3.4) ---------
--------- 新しいテキスト: (セクション3.3.4) ---------
Cumulative TSN Ack: 32 bits (unsigned integer)
累積しているTSN Ack: 32ビット(符号のない整数)
This parameter contains the TSN of the last DATA chunk received in
sequence before a gap. In the case where no DATA chunk has
been received, this value is set to the peer's Initial TSN minus
one.
このパラメタはギャップの連続して前に受け取られた最後のDATA塊のTSNを含んでいます。 DATA塊が全く受け取られていない場合では、1を引いてこの値は同輩のInitial TSNに設定されます。
Stewart, et al. Informational [Page 40] RFC 4460 SCTP Errata April 2006
スチュワート、他 [40ページ]情報のRFC4460SCTP誤字2006年4月
2.17.3. Solution Description
2.17.3. ソリューション記述
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
2.18. イニットの中のアドレスパラメタの取り扱いかイニット-ACK
2.18.1. Description of the Problem
2.18.1. 問題の記述
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
2.18.2. ドキュメントへのテキスト変化
--------- Old text: (Section 5.1.2) ---------
--------- 古いテキスト: (セクション5.1.2) ---------
C) If there are only IPv4/IPv6 addresses present in the received INIT
or INIT ACK chunk, the receiver shall derive and record all the
transport address(es) from the received chunk AND the source IP
address that sent the INIT or INIT ACK. The transport address(es)
are derived by the combination of SCTP source port (from the
common header) and the IP address parameter(s) carried in the INIT
or INIT ACK chunk and the source IP address of the IP datagram.
The receiver should use only these transport addresses as
destination transport addresses when sending subsequent packets to
its peer.
C) 容認されたINITかINIT ACK塊における現在のIPv4/IPv6アドレスしかなければ、受信機は、ソースIPの容認された塊とINITを送ったアドレスかINIT ACKからすべての輸送アドレス(es)を引き出して、記録するものとします。 輸送アドレス(es)はSCTPソース港(一般的なヘッダーからの)、INITかINIT ACK塊で運ばれたIPアドレスパラメタ、およびIPデータグラムのソースIPアドレスの組み合わせで引き出されます。 その後のパケットを同輩に送るとき、受信機は送付先輸送アドレスとしてこれらの輸送アドレスだけを使用するはずです。
--------- New text: (Section 5.1.2) ---------
--------- 新しいテキスト: (セクション5.1.2) ---------
C) If there are only IPv4/IPv6 addresses present in the received INIT
or INIT ACK chunk, the receiver MUST derive and record all the
transport addresses from the received chunk AND the source IP
address that sent the INIT or INIT ACK. The transport addresses
are derived by the combination of SCTP source port (from the
common header) and the IP address parameter(s) carried in the INIT
or INIT ACK chunk and the source IP address of the IP datagram.
The receiver should use only these transport addresses as
destination transport addresses when sending subsequent packets to
its peer.
C) 容認されたINITかINIT ACK塊における現在のIPv4/IPv6アドレスしかなければ、受信機は、ソースIPの容認された塊とINITを送ったアドレスかINIT ACKからすべての輸送アドレスを引き出して、記録しなければなりません。 輸送アドレスはSCTPソース港(一般的なヘッダーからの)、INITかINIT ACK塊で運ばれたIPアドレスパラメタ、およびIPデータグラムのソースIPアドレスの組み合わせで引き出されます。 その後のパケットを同輩に送るとき、受信機は送付先輸送アドレスとしてこれらの輸送アドレスだけを使用するはずです。
Stewart, et al. Informational [Page 41] RFC 4460 SCTP Errata April 2006
スチュワート、他 [41ページ]情報のRFC4460SCTP誤字2006年4月
D) An INIT or INIT ACK chunk MUST be treated as belonging
to an already established association (or one in the
process of being established) if the use of any of the
valid address parameters contained within the chunk
would identify an existing TCB.
D) 塊の中に含まれた有効なアドレスパラメタのどれかの使用が既存のTCBを特定するなら既に設立された協会(または、設立されることの途中に1)に属すとしてINITかINIT ACK塊を扱わなければなりません。
2.18.3. Solution description
2.18.3. ソリューション記述
This new text clearly specifies to an implementor the need to look within the INIT or INIT ACK. Any implementation that does not do this may (for example) not be able to recognize an INIT chunk coming from an already established association that adds new addresses (see Section 2.6) or an incoming INIT ACK chunk sent from a source address different from the destination address used to send the INIT chunk.
この新しいテキストは明確にINITかINIT ACKの中で見る必要性を作成者に指定します。 これをしないどんな実現もないかもしれません(例えば)。新しいアドレス(セクション2.6を見る)か送付先アドレスと異なったソースアドレスから送られた入って来るINIT ACK塊が以前はよくINIT塊を送ったと言い足す既に設立された協会から来ながら、INIT塊を認識できます。
2.19. Handling of Stream Shortages
2.19. 流れの不足の取り扱い
2.19.1. Description of the Problem
2.19.1. 問題の記述
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
2.19.2. ドキュメントへのテキスト変化
--------- Old text: ---------
--------- 古いテキスト: ---------
5.1.1 Handle Stream Parameters
5.1.1 流れのパラメタを扱ってください。
In the INIT and INIT ACK chunks, the sender of the chunk shall indicate the number of outbound streams (OS) it wishes to have in the association, as well as the maximum inbound streams (MIS) it will accept from the other endpoint.
INITとINIT ACK塊では、塊の送付者はそれが協会で持ちたがっている外国行きの流れ(OS)の数を示すものとします、それがもう片方の終点から受け入れる最大の本国行きの流れ(MIS)と同様に。
After receiving the stream configuration information from the other side, each endpoint shall perform the following check: If the peer's MIS is less than the endpoint's OS, meaning that the peer is incapable of supporting all the outbound streams the endpoint wants to configure, the endpoint MUST either use MIS outbound streams, or abort the association and report to its upper layer the resources shortage at its peer.
反対側から流れの設定情報を受け取った後に、各終点は以下のチェックを実行するものとします: 同輩が終点が構成したがっているすべての外国行きの流れを支持できないことを意味して、同輩のMISが終点のOS以下であるなら、終点は、MISの外国行きの流れを使用しなければならないか、協会を中止して、または同輩でリソース不足を上側の層に報告しなければなりません。
Stewart, et al. Informational [Page 42] RFC 4460 SCTP Errata April 2006
スチュワート、他 [42ページ]情報のRFC4460SCTP誤字2006年4月
--------- New text: (Section 5.1.2) ---------
--------- 新しいテキスト: (セクション5.1.2) ---------
5.1.1. Handle Stream Parameters
5.1.1. 流れのパラメタを扱ってください。
In the INIT and INIT ACK chunks, the sender of the chunk MUST indicate the number of outbound streams (OS) it wishes to have in the association, as well as the maximum inbound streams (MIS) it will accept from the other endpoint.
INITとINIT ACK塊では、塊の送付者はそれが協会で持ちたがっている外国行きの流れ(OS)の数を示さなければなりません、それがもう片方の終点から受け入れる最大の本国行きの流れ(MIS)と同様に。
After receiving the stream configuration information from the other side, each endpoint MUST perform the following check: If the peer's MIS is less than the endpoint's OS, meaning that the peer is incapable of supporting all the outbound streams the endpoint wants to configure, the endpoint MUST use MIS outbound streams and MAY report any shortage to the upper layer. The upper layer can then choose to abort the association if the resource shortage is unacceptable.
反対側から流れの設定情報を受け取った後に、各終点は以下のチェックを実行しなければなりません: 同輩が終点が構成したがっているすべての外国行きの流れを支持できないことを意味して、同輩のMISが終点のOS以下であるなら、終点は、MISの外国行きの流れを使用しなければならなくて、どんな不足も上側の層に報告するかもしれません。 そして、リソース不足が容認できないなら、上側の層は、協会を中止するのを選ぶことができます。
2.19.3. Solution Description
2.19.3. ソリューション記述
The above changes take the decision to ABORT out of the realm of the SCTP stack and place it into the user's hands.
上の変化は、SCTPスタックの分野からABORTとの決定を取り出して、ユーザの手にそれを置きます。
2.20. Indefinite Postponement
2.20. 延期
2.20.1. Description of the Problem
2.20.1. 問題の記述
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
2.20.2. ドキュメントへのテキスト変化
--------- Old text: (Section 6.1) ---------
--------- 古いテキスト: (セクション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.
以下に注意してください。 データ送付者SHOULD NOTはTSNを使用します、すなわち、電流の始めTSNを超えた2**31--1以上が窓を送ります。
6.2 Acknowledgement on Reception of DATA Chunks
6.2 データ塊のレセプションにおける承認
Stewart, et al. Informational [Page 43] RFC 4460 SCTP Errata April 2006
スチュワート、他 [43ページ]情報のRFC4460SCTP誤字2006年4月
--------- New text: (Section 6.1) ---------
--------- 新しいテキスト: (セクション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.
以下に注意してください。 データ送付者SHOULD NOTはTSNを使用します、すなわち、電流の始めTSNを超えた2**31--1以上が窓を送ります。
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
実現が特定の協会で連続したTSNsをメッセージに割り当てるアルゴリズムは、TSNが割り当てられるのでSCTPによって受け入れられていないユーザメッセージが全く無期限に延期されるのを確実にしなければなりません。 TSNsが含む割り当てのための許容できるアルゴリズム
(a) assigning TSNs in round-robin order over all streams with
pending data; and
(a) すべて上の連続オーダーでTSNsを割り当てると、未定のデータはあふれます。 そして
(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受信機SHOULDがすべての提出物のメッセージから最も低いTSNがあるメッセージを選ぶよう要求するとき。 ユーザが特定の流れに関するデータを要求できるSCTP実現では、これ以来データを得ることができないならSHOULD NOTが妨げるこの操作は一定の条件の下で行き詰まりにつながることができます。
6.2. Acknowledgement on Receipt of DATA Chunks
6.2. データ塊を受け取り次第承認
2.20.3. Solution Description
2.20.3. ソリューション記述
The above wording clarifies how TSNs SHOULD be assigned by the sender.
上の言葉遣いはどのようにTSNs SHOULDをはっきりさせるか。送付者によって割り当てられます。
2.21. User-Initiated Abort of an Association
2.21. 協会のユーザによって開始されたアボート
2.21.1. Description of the Problem
2.21.1. 問題の記述
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
2.21.2. ドキュメントへのテキスト変化
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
スチュワート、他 [44ページ]情報のRFC4460SCTP誤字2006年4月
--------- Old text: (Section 3.3.10) ---------
--------- 古いテキスト: (セクション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
原因コード値原因コード--------- ---------------- 1 停止している間に受け取られたリソース5Unresolvableアドレス6認識されていない塊タイプ7無効の義務的なパラメタ8の認識されていないパラメタ9いいえ利用者データ10クッキーからの無効の流れの識別子2のなくなった義務的なパラメタ3の聞き古したクッキー誤り4
Cause Length: 16 bits (unsigned integer)
長さを引き起こしてください: 16ビット(符号のない整数)
Set to the size of the parameter in bytes, including the Cause
Code, Cause Length, and Cause-Specific Information fields
Cause Code、Cause Length、およびCause特有の情報分野を含むバイトで表現されるパラメタのサイズに、セットします。
Cause-specific Information: variable length
原因特有の情報: 可変長
This field carries the details of the error condition.
この分野はエラー条件の詳細を運びます。
Sections 3.3.10.1 - 3.3.10.10 define error causes for SCTP. Guidelines for the IETF to define new error cause values are discussed in Section 13.3.
セクション3.3 .10 .1--3.3 .10 .10はSCTPの誤り原因を定義します。 セクション13.3でIETFが新しい誤り原因値を定義するガイドラインについて議論します。
Stewart, et al. Informational [Page 45] RFC 4460 SCTP Errata April 2006
スチュワート、他 [45ページ]情報のRFC4460SCTP誤字2006年4月
--------- New text: (Section 3.3.10) ---------
--------- 新しいテキスト: (セクション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
原因コード値原因コード--------- ---------------- 1 終業11が再開しますが、受け取られた協会の新しいアドレス12でユーザによって開始されたアボートのリソース5Unresolvableアドレス6認識されていない塊タイプ7無効の義務的なパラメタ8の認識されていないパラメタ9いいえ利用者データ10クッキーからの無効の流れの識別子2のなくなった義務的なパラメタ3の聞き古したクッキー誤り4
Cause Length: 16 bits (unsigned integer)
長さを引き起こしてください: 16ビット(符号のない整数)
Set to the size of the parameter in bytes, including the Cause
Code, Cause Length, and Cause-Specific Information fields
Cause Code、Cause Length、およびCause特有の情報分野を含むバイトで表現されるパラメタのサイズに、セットします。
Cause-specific Information: variable length
原因特有の情報: 可変長
This field carries the details of the error condition.
この分野はエラー条件の詳細を運びます。
Sections 3.3.10.1 - 3.3.10.12 define error causes for SCTP. Guidelines for the IETF to define new error cause values are discussed in Section 13.3.
セクション3.3 .10 .1--3.3 .10 .12はSCTPの誤り原因を定義します。 セクション13.3でIETFが新しい誤り原因値を定義するガイドラインについて議論します。
--------- 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)
3.3.10.12. ユーザによって開始されたアボート(12)
Cause of error
--------------
誤りの原因--------------
This error cause MAY be included in ABORT chunks that are sent
because of an upper layer request. The upper layer can specify
an Upper Layer Abort Reason that is transported by SCTP
transparently and MAY be delivered to the upper layer protocol
at the peer.
この誤り原因は上側の層の要求のために送られるABORT塊に含まれるかもしれません。 上側の層は同輩でSCTPによって透明に輸送されて、上側の層のプロトコルに届けられるかもしれないUpper Layer Abort Reasonを指定できます。
Stewart, et al. Informational [Page 46] RFC 4460 SCTP Errata April 2006
スチュワート、他 [46ページ]情報のRFC4460SCTP誤字2006年4月
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=12 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Upper Layer Abort Reason /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 原因コード=12| 原因の長さは変数と等しいです。| 上側..層..アボート..理由
--------- Old text: (Section 9.1) ---------
--------- 古いテキスト: (セクション9.1) ---------
9.1 Abort of an Association
9.1 協会のアボート
When an endpoint decides to abort an existing association, it
shall send an ABORT chunk to its peer endpoint. The sender MUST
fill in the peer's Verification Tag in the outbound packet and
MUST NOT bundle any DATA chunk with the ABORT.
終点が、既存の協会を中止すると決めると、それはABORT塊を同輩終点に送るものとします。 送付者は、外国行きのパケットに同輩のVerification Tagに記入しなければならなくて、ABORTと共にどんなDATA塊も束ねてはいけません。
An endpoint MUST NOT respond to any received packet that contains
an ABORT chunk (also see Section 8.4).
終点はABORT塊を含むどんな容認されたパケットにも応じてはいけません(また、セクション8.4を見てください)。
An endpoint receiving an ABORT shall apply the special
Verification Tag check rules described in Section 8.5.1.
ABORTを受ける終点はセクション8.5.1で説明された特別なVerification Tagチェック規則を適用するものとします。
After checking the Verification Tag, the receiving endpoint shall
remove the association from its record and shall report the
termination to its upper layer.
Verification Tagをチェックした後に、受信終点は、記録から協会を移して、上側の層に終了を報告するものとします。
---------
New text: (Section 9.1)
---------
--------- 新しいテキスト: (セクション9.1) ---------
9.1. Abort of an Association
9.1. 協会のアボート
When an endpoint decides to abort an existing association, it MUST
send an ABORT chunk to its peer endpoint. The sender MUST fill in
the peer's Verification Tag in the outbound packet and MUST NOT
bundle any DATA chunk with the ABORT. If the association is
aborted on request of the upper layer, a User-Initiated Abort
error cause (see 3.3.10.12) SHOULD be present in the ABORT chunk.
終点が、既存の協会を中止すると決めると、それはABORT塊を同輩終点に送らなければなりません。 送付者は、外国行きのパケットに同輩のVerification Tagに記入しなければならなくて、ABORTと共にどんなDATA塊も束ねてはいけません。 協会が上側の層について要求に応じて中止されるなら、aがAbort誤り原因をUser開始した、(3.3に.10を見てください、.12)SHOULD、ABORT塊では、存在してください。
An endpoint MUST NOT respond to any received packet that contains
an ABORT chunk (also see Section 8.4).
終点はABORT塊を含むどんな容認されたパケットにも応じてはいけません(また、セクション8.4を見てください)。
An endpoint receiving an ABORT MUST apply the special Verification
Tag check rules described in Section 8.5.1.
ABORT MUSTを受ける終点はセクション8.5.1で説明された特別なVerification Tagチェック規則を適用します。
After checking the Verification Tag, the receiving endpoint MUST
Verification Tagをチェックした後に、受信終点はそうしなければなりません。
Stewart, et al. Informational [Page 47] RFC 4460 SCTP Errata April 2006
スチュワート、他 [47ページ]情報のRFC4460SCTP誤字2006年4月
remove the association from its record and SHOULD report the
termination to its upper layer. If a User-Initiated Abort error
cause is present in the ABORT chunk, the Upper Layer Abort Reason
SHOULD be made available to the upper layer.
記録から協会を移してください。そうすれば、SHOULDは上側の層に終了を報告します。 誤り原因はUserによって開始されたAbortであるならABORT塊で存在しています、Upper Layer Abort Reason SHOULD。上側の層に利用可能に作られてください。
--------- Old text: (Section 10.1) ---------
--------- 古いテキスト: (セクション10.1) ---------
D) Abort
D) アボート
Format: ABORT(association id [, cause code])
-> result
形式: ABORT(協会イド[コードを引き起こす])->結果
Ungracefully closes an association. Any locally queued user
data will be discarded and an ABORT chunk is sent to the peer.
A success code will be returned on successful abortion of the
association. If attempting to abort the association results
in a failure, an error code shall be returned.
協会を無様に閉じます。 どんな局所的に列に並ばせられた利用者データも捨てるでしょう、そして、ABORT塊を同輩に送ります。 成功コードは協会のうまくいっている妊娠中絶のときに返されるでしょう。 失敗における協会結果を中止するのを試みるなら、エラーコードは返されるものとします。
Mandatory attributes:
義務的な属性:
o association id - local handle to the SCTP association
o association id - local handle to the SCTP association
Optional attributes:
Optional attributes:
o cause code - reason of the abort to be passed to the peer.
o cause code - reason of the abort to be passed to the peer.
--------- New text: (Section 10.1) ---------
--------- New text: (Section 10.1) ---------
D) Abort
D) Abort
Format: ABORT(association id [, Upper Layer Abort Reason])
-> result
Format: ABORT(association id [, Upper Layer Abort Reason]) -> 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.
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:
Mandatory attributes:
o association id - Local handle to the SCTP association.
o association id - Local handle to the SCTP association.
Stewart, et al. Informational [Page 48] RFC 4460 SCTP Errata April 2006
Stewart, et al. Informational [Page 48] RFC 4460 SCTP Errata April 2006
Optional attributes:
Optional attributes:
o Upper Layer Abort Reason - Reason of the abort to be passed
to the peer.
o Upper Layer Abort Reason - Reason of the abort to be passed to the peer.
None.
None.
--------- Old text: (Section 10.2) ---------
--------- Old text: (Section 10.2) ---------
E) COMMUNICATION LOST notification
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.
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:
The following shall be passed with the notification:
o association id - local handle to the SCTP association
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.
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:
The following may be passed with the notification:
o data retrieval id - an identification used to retrieve
unsent and unacknowledged data.
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-acked - the TSN last acked by that peer endpoint;
o last-sent - the TSN last sent to that peer endpoint;
o last-sent - the TSN last sent to that peer endpoint;
--------- New text: (Section 10.2) ---------
--------- New text: (Section 10.2) ---------
E) COMMUNICATION LOST notification
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.
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:
The following shall be passed with the notification:
o association id - Local handle to the SCTP association.
o association id - Local handle to the SCTP association.
Stewart, et al. Informational [Page 49] RFC 4460 SCTP Errata April 2006
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 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.
The following may be passed with the notification:
The following may be passed with the notification:
o data retrieval id - An identification used to retrieve unsent
and unacknowledged data.
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-acked - The TSN last acked by that peer endpoint.
o last-sent - The TSN last sent to that peer endpoint.
o last-sent - The TSN last sent to that peer endpoint.
o Upper Layer Abort Reason - The abort reason specified in
case of a user-initiated abort.
o Upper Layer Abort Reason - The abort reason specified in case of a user-initiated abort.
2.21.3. Solution Description
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.
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
2.22. Handling of Invalid Initiate Tag of INIT-ACK
2.22.1. Description of the Problem
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 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.
2.22.2. Text Changes to the Document
2.22.2. Text Changes to the Document
--------- Old text: (Section 3.3.3) ---------
--------- Old text: (Section 3.3.3) ---------
Initiate Tag: 32 bits (unsigned integer)
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 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.
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
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.
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) ---------
--------- New text: (Section 3.3.3) ---------
Initiate Tag: 32 bits (unsigned integer)
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 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.
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.
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.
2.22.3. Solution Description
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.
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.
2.23. Sending an ABORT in Response to an INIT
2.23. Sending an ABORT in Response to an INIT
2.23.1. Description of the Problem
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.
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.
2.23.2. Text Changes to the Document
2.23.2. Text Changes to the Document
--------- Old text: (Section 8.4) ---------
--------- Old text: (Section 8.4) ---------
3) If the packet contains an INIT chunk with a Verification Tag
set to '0', process it as described in Section 5.1.
Otherwise,
3) 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
Stewart, et al. Informational [Page 51] RFC 4460 SCTP Errata April 2006
--------- New text: (Section 8.4) ---------
--------- New text: (Section 8.4) ---------
3) If the packet contains an INIT chunk with a Verification Tag
set to '0', process it as described in Section 5.1. If, for
whatever reason, the INIT cannot be processed normally and
an ABORT has to be sent in response, the Verification Tag
of the packet containing the ABORT chunk MUST be the
Initiate tag of the received INIT chunk, and the T-Bit of
the ABORT chunk has to be set to 0, indicating that
a TCB was destroyed. Otherwise,
3) 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,
2.23.3. Solution Description
2.23.3. Solution Description
The new text stated clearly which value of the Verification Tag and T-bit have to be used.
The new text stated clearly which value of the Verification Tag and T-bit have to be used.
2.24. Stream Sequence Number (SSN) Initialization
2.24. Stream Sequence Number (SSN) Initialization
2.24.1. Description of the Problem
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 does not describe the fact that the SSN has to be initialized to 0, as required by RFC 2119.
2.24.2. Text Changes to the Document
2.24.2. Text Changes to the Document
--------- Old text: (Section 6.5) ---------
--------- 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.
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) ---------
--------- 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.
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.
Stewart, et al. Informational [Page 52] RFC 4460 SCTP Errata April 2006
Stewart, et al. Informational [Page 52] RFC 4460 SCTP Errata April 2006
2.24.3. Solution Description
2.24.3. Solution Description
The 'shall' in the text is replaced by a 'MUST' to clearly state the required behavior.
The 'shall' in the text is replaced by a 'MUST' to clearly state the required behavior.
2.25. SACK Packet Format
2.25. SACK Packet Format
2.25.1. Description of the Problem
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.
It is not clear in RFC 2960 whether a SACK must contain the fields Number of Gap Ack Blocks and Number of Duplicate TSNs.
2.25.2. Text Changes to the Document
2.25.2. Text Changes to the Document
--------- Old text: (Section 3.3.4) ---------
--------- Old text: (Section 3.3.4) ---------
The SACK MUST contain the Cumulative TSN Ack and
Advertised Receiver Window Credit (a_rwnd) parameters.
The SACK MUST contain the Cumulative TSN Ack and Advertised Receiver Window Credit (a_rwnd) parameters.
--------- New text: (Section 3.3.4) ---------
--------- 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.
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.
2.25.3. Solution Description
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.
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.
2.26. Protocol Violation Error Cause
2.26. Protocol Violation Error Cause
2.26.1. Description of the Problem
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.
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.
Stewart, et al. Informational [Page 53] RFC 4460 SCTP Errata April 2006
Stewart, et al. Informational [Page 53] RFC 4460 SCTP Errata April 2006
2.26.2. Text Changes to the Document
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.
Some of the changes given here already include changes suggested in Section 2.6 and 2.21 of this document.
--------- Old text: (Section 3.3.10) ---------
--------- 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 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)
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
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
Cause-specific Information: variable length
This field carries the details of the error condition.
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.
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
Stewart, et al. Informational [Page 54] RFC 4460 SCTP Errata April 2006
--------- New text: (Section 3.3.10) ---------
--------- New text: (Section 3.3.10) ---------
Cause Code
Value Cause Code
--------- ----------------
1 Invalid Stream Identifier
2 Missing Mandatory Parameter
3 Stale Cookie Error
4 Out of Resource
5 Unresolvable Address
6 Unrecognized Chunk Type
7 Invalid Mandatory Parameter
8 Unrecognized Parameters
9 No User Data
10 Cookie Received While Shutting Down
11 Restart of an Association with New Addresses
12 User Initiated Abort
13 Protocol Violation
Cause Code Value Cause Code --------- ---------------- 1 Invalid Stream Identifier 2 Missing Mandatory Parameter 3 Stale Cookie Error 4 Out of Resource 5 Unresolvable Address 6 Unrecognized Chunk Type 7 Invalid Mandatory Parameter 8 Unrecognized Parameters 9 No User Data 10 Cookie Received While Shutting Down 11 Restart of an Association with New Addresses 12 User Initiated Abort 13 Protocol Violation
Cause Length: 16 bits (unsigned integer)
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
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
Cause-specific Information: variable length
This field carries the details of the error condition.
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.
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.
--------- New text: (Note: no old text; new error added in section 3.3.10) ---------
--------- New text: (Note: no old text; new error added in section 3.3.10) ---------
3.3.10.13. Protocol Violation (13)
3.3.10.13. Protocol Violation (13)
Cause of error
--------------
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.
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.
Stewart, et al. Informational [Page 55] RFC 4460 SCTP Errata April 2006
Stewart, et al. Informational [Page 55] RFC 4460 SCTP Errata April 2006
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=13 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Additional Information /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cause Code=13 | Cause Length=Variable | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / Additional Information / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.26.3. Solution Description
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.
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. Reporting of Unrecognized Parameters
2.27.1. Description of the Problem
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.
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.
2.27.2. Text Changes to the Document
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.
Some of the changes given here already include changes suggested in Section 2.2 of this document.
--------- Old text: (Section 3.2.1) ---------
--------- Old text: (Section 3.2.1) ---------
00 - Stop processing this SCTP packet and discard it, do not process
any further chunks within it.
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).
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.
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).
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
Stewart, et al. Informational [Page 56] RFC 4460 SCTP Errata April 2006
--------- New text: (Section 3.2.1) ---------
--------- 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 - Stop processing this SCTP chunk and discard it; do not process any further parameters within this chunk.
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 - 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.
10 - Skip this parameter and continue processing.
10 - Skip this parameter and continue processing.
11 - Skip this parameter and continue processing but report the
unrecognized parameter in an 'Unrecognized Parameter Type', as
described in 3.2.2.
11 - Skip this parameter and continue processing but report the unrecognized parameter in an 'Unrecognized Parameter Type', as described in 3.2.2.
--------- New text: (Note: no old text; clarification added in Section 3.2) ---------
--------- New text: (Note: no old text; clarification added in Section 3.2) ---------
3.2.2. Reporting of Unrecognized Parameters
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.
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.
If the receiver of an INIT-ACK chunk detects unrecognized
parameters and has to report them according to Section 3.2.1,
it SHOULD bundle the ERROR chunk containing the
'Unrecognized Parameter' error cause with the COOKIE-ECHO
chunk sent in response to the INIT-ACK chunk. If the
receiver of the INIT-ACK cannot bundle the COOKIE-ECHO chunk
with the ERROR chunk, the ERROR chunk MAY be sent separately
but not before the COOKIE-ACK has been received.
If the receiver of an INIT-ACK chunk detects unrecognized parameters and has to report them according to Section 3.2.1, it SHOULD bundle the ERROR chunk containing the 'Unrecognized Parameter' error cause with the COOKIE-ECHO chunk sent in response to the INIT-ACK chunk. If the receiver of the INIT-ACK cannot bundle the COOKIE-ECHO chunk with the ERROR chunk, the ERROR chunk MAY be sent separately but not before the COOKIE-ACK has been received.
Note: Any time a COOKIE-ECHO is sent in a packet, it MUST be the
first chunk.
Note: Any time a COOKIE-ECHO is sent in a packet, it MUST be the first chunk.
2.27.3. Solution Description
2.27.3. Solution Description
The procedure of reporting unrecognized parameters has been described clearly.
The procedure of reporting unrecognized parameters has been described clearly.
Stewart, et al. Informational [Page 57] RFC 4460 SCTP Errata April 2006
Stewart, et al. Informational [Page 57] RFC 4460 SCTP Errata April 2006
2.28. Handling of IP Address Parameters
2.28. Handling of IP Address Parameters
2.28.1. Description of the Problem
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.
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.
2.28.2. Text Changes to the Document
2.28.2. Text Changes to the Document
--------- Old text: (Section 5.1.2) ---------
--------- 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.
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) ---------
--------- 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: 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.
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.3. Solution Description
2.28.3. Solution Description
The procedure of handling IP address parameters has been described clearly.
The procedure of handling IP address parameters has been described clearly.
Stewart, et al. Informational [Page 58] RFC 4460 SCTP Errata April 2006
Stewart, et al. Informational [Page 58] RFC 4460 SCTP Errata April 2006
2.29. Handling of COOKIE ECHO Chunks When a TCB Exists
2.29. Handling of COOKIE ECHO Chunks When a TCB Exists
2.29.1. Description of the Problem
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.
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.
2.29.2. Text Changes to the Document
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.
--------- 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.
--------- 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.
2.29.3. Solution Description
2.29.3. Solution Description
The procedure of handling of COOKIE-ECHO chunks when a TCB exists has been described clearly.
The procedure of handling of COOKIE-ECHO chunks when a TCB exists has been described clearly.
2.30. The Initial Congestion Window Size
2.30. The Initial Congestion Window Size
2.30.1. Description of the Problem
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 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.
Stewart, et al. Informational [Page 59] RFC 4460 SCTP Errata April 2006
Stewart, et al. Informational [Page 59] RFC 4460 SCTP Errata April 2006
2.30.2. Text Changes to the Document
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.
--------- 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)).
--------- New text: (Section 7.2.1) --------- o The initial cwnd before DATA transmission or after a sufficiently long idle period MUST be set to min(4*MTU, max (2*MTU, 4380 bytes)).
---------
Old text: (Section 7.2.1)
---------
o When the endpoint does not transmit data on a given transport
address, the cwnd of the transport address should be adjusted
to max(cwnd/2, 2*MTU) per RTO.
--------- 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.
--------- New text: (Section 7.2.1) --------- o When the endpoint does not transmit data on a given transport address, the cwnd of the transport address should be adjusted to max(cwnd/2, 4*MTU) per RTO.
---------
Old text: (Section 7.2.2)
---------
o Same as in the slow start, when the sender does not transmit
DATA on a given transport address, the cwnd of the transport
address should be adjusted to max(cwnd / 2, 2*MTU) per RTO.
--------- 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.
--------- 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.
Stewart, et al. Informational [Page 60] RFC 4460 SCTP Errata April 2006
Stewart, et al. Informational [Page 60] RFC 4460 SCTP Errata April 2006
--------- Old text: (Section 7.2.3) ---------
--------- Old text: (Section 7.2.3) ---------
7.2.3. Congestion Control
7.2.3. Congestion Control
Upon detection of packet losses from SACK (see Section 7.2.4), an
endpoint should do the following:
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
ssthresh = max(cwnd/2, 2*MTU) cwnd = ssthresh
Basically, a packet loss causes cwnd to be cut in half.
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
When the T3-rtx timer expires on an address, SCTP should perform slow start by
ssthresh = max(cwnd/2, 2*MTU)
cwnd = 1*MTU
ssthresh = max(cwnd/2, 2*MTU) cwnd = 1*MTU
--------- New text: (Section 7.2.3) ---------
--------- New text: (Section 7.2.3) ---------
7.2.3 Congestion Control
7.2.3 Congestion Control
Upon detection of packet losses from SACK (see Section 7.2.4), An
endpoint should do the following:
Upon detection of packet losses from SACK (see Section 7.2.4), An endpoint should do the following:
ssthresh = max(cwnd/2, 4*MTU)
cwnd = ssthresh
ssthresh = max(cwnd/2, 4*MTU) cwnd = ssthresh
Basically, a packet loss causes cwnd to be cut in half.
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:
When the T3-rtx timer expires on an address, SCTP should perform slow start by:
ssthresh = max(cwnd/2, 4*MTU)
cwnd = 1*MTU
ssthresh = max(cwnd/2, 4*MTU) cwnd = 1*MTU
2.30.3. Solution Description
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.
The change to SCTP's initial congestion window will allow it to continue to maintain the same congestion control properties as TCP.
Stewart, et al. Informational [Page 61] RFC 4460 SCTP Errata April 2006
Stewart, et al. Informational [Page 61] RFC 4460 SCTP Errata April 2006
2.31. Stream Sequence Numbers in Figures
2.31. Stream Sequence Numbers in Figures
2.31.1. Description of the Problem
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.
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.
Stewart, et al. Informational [Page 62] RFC 4460 SCTP Errata April 2006
Stewart, et al. Informational [Page 62] RFC 4460 SCTP Errata April 2006
2.31.2. Text Changes to the Document
2.31.2. Text Changes to the Document
--------- Old text: (Section 7.2.1) ---------
--------- Old text: (Section 7.2.1) ---------
Endpoint A Endpoint Z
{app sets association with Z}
(build TCB)
INIT [I-Tag=Tag_A
& other info] ------\
(Start T1-init timer) \
(Enter COOKIE-WAIT state) \---> (compose temp TCB and Cookie_Z)
/-- INIT ACK [Veri Tag=Tag_A,
/ I-Tag=Tag_Z,
(Cancel T1-init timer) <-----/ Cookie_Z, & other info]
(destroy temp TCB)
COOKIE ECHO [Cookie_Z] ------\
(Start T1-init timer) \
(Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED
state)
/---- COOKIE-ACK
/
(Cancel T1-init timer, <-----/
Enter ESTABLISHED state)
{app sends 1st user data; strm 0}
DATA [TSN=initial TSN_A
Strm=0,Seq=1 & user data]--\
(Start T3-rtx timer) \
\->
/----- SACK [TSN Ack=init
/ TSN_A,Block=0]
(Cancel T3-rtx timer) <------/
...
{app sends 2 messages;strm 0}
/---- DATA
/ [TSN=init TSN_Z
<--/ Strm=0,Seq=1 & user data 1]
SACK [TSN Ack=init TSN_Z, / ---- DATA
Block=0] --------\ / [TSN=init TSN_Z +1,
\/ Strm=0,Seq=2 & user data 2]
<------/\
\
\------>
終点A Endpoint Z、装置がZとの協会を設定する、(Tcbを建てます)INIT[I-タグ=タグと他のインフォメーション]------\(T1-イニットタイマを始動する)\(COOKIE-WAIT状態に入る)\--->(臨時TCBとCookie_Zを構成する)/--、INIT ACK、[ベリTagはタグと等しいです、/Iタグ=タグ_Z、(キャンセルT1-イニットタイマ)<、-、-、-、--、インフォメーション] /クッキー_Z、およびもう一方(臨時Tcbを破壊します)COOKIE ECHO[クッキー_Z]------\(T1-イニットタイマを始動する)\(COOKIE-ECHOED状態に入る)\--->(体格TCBはESTABLISHED状態に入る)/---- COOKIE-ACK/、(T1-イニットタイマを取り消してください、<、-、-、-、--/はESTABLISHED状態) {装置は最初の利用者データを送ります; strm0}というDATAに入ります[TSNはイニシャルTSNStrm=0、Seq=1、および利用者データと等しいです]--、\(T3-rtxタイマを始動する)\\->/----- SACK[TSN Ackはイニット/TSN、Block=0と等しいです](T3-rtxタイマを取り消す)<。------/ ... {装置は2つのメッセージを送ります; strm0}という/---- DATA/[TSN=イニットTSN_Z<--/Strm=0、Seq=1、および利用者データ1]SACK[TSN AckはイニットTSN_Z、/---- DATA Block=0と等しいです]--------\/[TSNはイニットTSN_Z+1、\/Strm=0、Seq=2、および利用者データ2と等しいです]<。------/\ \ \------>。
Figure 4: INITiation Example
図4: 開始の例
Stewart, et al. Informational [Page 63] RFC 4460 SCTP Errata April 2006
スチュワート、他 [63ページ]情報のRFC4460SCTP誤字2006年4月
--------- New text: (Section 7.2.1) ---------
--------- 新しいテキスト: (セクション7.2.1) ---------
Endpoint A Endpoint Z
{app sets association with Z}
(build TCB)
INIT [I-Tag=Tag_A
& other info] ------\
(Start T1-init timer) \
(Enter COOKIE-WAIT state) \---> (compose temp TCB and Cookie_Z)
/-- INIT ACK [Veri Tag=Tag_A,
/ I-Tag=Tag_Z,
(Cancel T1-init timer) <------/ Cookie_Z, & other info]
(destroy temp TCB)
COOKIE ECHO [Cookie_Z] ------\
(Start T1-init timer) \
(Enter COOKIE-ECHOED state) \---> (build TCB enter ESTABLISHED
state)
/---- COOKIE-ACK
/
(Cancel T1-init timer, <-----/
Enter ESTABLISHED state)
{app sends 1st user data; strm 0}
DATA [TSN=initial TSN_A
Strm=0,Seq=0 & user data]--\
(Start T3-rtx timer) \
\->
/----- SACK [TSN Ack=init
/ TSN_A,Block=0]
(Cancel T3-rtx timer) <------/
...
{app sends 2 messages;strm 0}
/---- DATA
/ [TSN=init TSN_Z
<--/ Strm=0,Seq=0 & user data 1]
SACK [TSN Ack=init TSN_Z, /---- DATA
Block=0] --------\ / [TSN=init TSN_Z +1,
\/ Strm=0,Seq=1 & user data 2]
<------/\
\
\------>
終点A Endpoint Z、装置がZとの協会を設定する、(Tcbを建てます)INIT[I-タグ=タグと他のインフォメーション]------\(T1-イニットタイマを始動する)\(COOKIE-WAIT状態に入る)\--->(臨時TCBとCookie_Zを構成する)/--、INIT ACK、[ベリTagはタグと等しいです、/Iタグ=タグ_Z、(キャンセルT1-イニットタイマ)<、-、-、-、-、--、インフォメーション] /クッキー_Z、およびもう一方(臨時Tcbを破壊します)COOKIE ECHO[クッキー_Z]------\(T1-イニットタイマを始動する)\(COOKIE-ECHOED状態に入る)\--->(体格TCBはESTABLISHED状態に入る)/---- COOKIE-ACK/、(T1-イニットタイマを取り消してください、<、-、-、-、--/はESTABLISHED状態) {装置は最初の利用者データを送ります; strm0}というDATAに入ります[TSNはイニシャルTSNStrm=0、Seq=0、および利用者データと等しいです]--、\(T3-rtxタイマを始動する)\\->/----- SACK[TSN Ackはイニット/TSN、Block=0と等しいです](T3-rtxタイマを取り消す)<。------/ ... {装置は2つのメッセージを送ります; strm0}という/---- DATA/[TSN=イニットTSN_Z<--/Strm=0、Seq=0、および利用者データ1]SACK、[TSN AckはイニットTSN_Z、/--と等しいです--DATA Block=0]--------\/[TSNはイニットTSN_Z+1、\/Strm=0、Seq=1、および利用者データ2と等しいです]<。------/\ \ \------>。
Figure 4: INITiation Example
図4: 開始の例
Stewart, et al. Informational [Page 64] RFC 4460 SCTP Errata April 2006
スチュワート、他 [64ページ]情報のRFC4460SCTP誤字2006年4月
--------- Old text: (Section 5.2.4.1) ---------
--------- 古いテキスト: (セクション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) <------/
終点は終点Z<です。------------ 協会は設立されます。---------------------->タグ=タグタグ=タグ_Z<。-------------------------------------------------------------'>、装置がZとの協会に設定するAクラッシュと再開(Tcbを建てる)、INIT[Iタグ=は'他のインフォメーションにタグ付けをします]--------\(T1-イニットタイマを始動する)\(COOKIE-WAIT状態に入る)\--->(既存のTCBがTie-タグで臨時TCBとCookie_Zを前の協会に構成するのがわかる)/--- ベリ..等しい..タグ..タグ..タグ..キャンセル..イニット..タイマ..クッキー..タグ..インフォメーション..破壊..臨時..休暇..オリジナル..適所..ベリ..等しい..タグ..タグ付け..始める..イニット..タイマ..入る..状態..見つける..既存..協会..タグ..マッチ..古い..タグ..マッチ..すなわち..ケースに入れる..上..リセット..協会; COOKIE-ACK、(T1-イニットタイマを取り消してください、<、-、-、-、-、--/はESTABLISHED状態) {装置は最初の利用者データを送ります; strm0}というDATA TSN=イニシャルTSNStrm=0、Seq=1、および利用者データを入力します--、\(T3-rtxタイマを始動する)\\->/、-、--、SACK TSN AckはイニットTSNと等しいです、Block=0(T3-rtxタイマを取り消す)<-、-、-、-、--、/
Figure 5: A Restart Example
図5: 再開の例
Stewart, et al. Informational [Page 65] RFC 4460 SCTP Errata April 2006
スチュワート、他 [65ページ]情報のRFC4460SCTP誤字2006年4月
--------- New text: (Section 5.2.4.1) ---------
--------- 新しいテキスト: (セクション5.2.4、.1) ---------
Endpoint A Endpoint Z
<-------------- Association is established---------------------->
Tag=Tag_A Tag=Tag_Z
<--------------------------------------------------------------->
{A crashes and restarts}
{app sets up a association with Z}
(build TCB)
INIT [I-Tag=Tag_A'
& other info] --------\
(Start T1-init timer) \
(Enter COOKIE-WAIT state) \---> (find a existing TCB
compose temp TCB and Cookie_Z
with Tie-Tags to previous
association)
/--- INIT ACK [Veri Tag=Tag_A',
/ I-Tag=Tag_Z',
(Cancel T1-init timer) <------/ Cookie_Z[TieTags=
Tag_A,Tag_Z
& other info]
(destroy temp TCB,leave original
in place)
COOKIE ECHO [Veri=Tag_Z',
Cookie_Z
Tie=Tag_A,
Tag_Z]----------\
(Start T1-init timer) \
(Enter COOKIE-ECHOED state) \---> (Find existing association,
Tie-Tags match old tags,
Tags do not match i.e.,
case X X M M above,
Announce Restart to ULP
and reset association).
/---- COOKIE-ACK
(Cancel T1-init timer, <------/
Enter ESTABLISHED state)
{app sends 1st user data; strm 0}
DATA [TSN=initial TSN_A
Strm=0,Seq=0 & user data]--\
(Start T3-rtx timer) \
\->
/--- SACK [TSN Ack=init TSN_A,Block=0]
(Cancel T3-rtx timer) <------/
終点は終点Z<です。-------------- 協会は設立されます。---------------------->タグ=タグタグ=タグ_Z<。---------------------------------------------------------------'>、装置がZとの協会に設定するAクラッシュと再開(Tcbを建てる)、INIT[Iタグ=は'他のインフォメーションにタグ付けをします]--------\(T1-イニットタイマを始動する)\(COOKIE-WAIT状態に入る)\--->(既存のTCBがTie-タグで臨時TCBとCookie_Zを前の協会に構成するのがわかる)/--- ベリ..等しい..タグ..タグ..タグ..キャンセル..イニット..タイマ..クッキー..タグ..インフォメーション..破壊..臨時..休暇..オリジナル..適所..ベリ..等しい..タグ..タグ付け..始める..イニット..タイマ..入る..状態..見つける..既存..協会..タグ..マッチ..古い..タグ..マッチ..すなわち..ケースに入れる..上..リセット..協会; COOKIE-ACK、(T1-イニットタイマを取り消してください、<、-、-、-、-、--/はESTABLISHED状態) {装置は最初の利用者データを送ります; strm0}というDATA TSN=イニシャルTSNStrm=0、Seq=0、および利用者データを入力します--、\(T3-rtxタイマを始動する)\\->/、-、--、SACK TSN AckはイニットTSNと等しいです、Block=0(T3-rtxタイマを取り消す)<-、-、-、-、--、/
Figure 5: A Restart Example
図5: 再開の例
Stewart, et al. Informational [Page 66] RFC 4460 SCTP Errata April 2006
スチュワート、他 [66ページ]情報のRFC4460SCTP誤字2006年4月
2.31.3. Solution description
2.31.3. ソリューション記述
Figure 4 and 5 were changed so that the SSN starts with 0 instead of 1.
図4と5を変えたので、SSNは1の代わりに0から始まります。
2.32. Unrecognized Parameters
2.32. 認識されていないパラメタ
2.32.1. Description of the Problem
2.32.1. 問題の記述
The RFC does not state clearly in Section 3.3.3.1 whether one or multiple unrecognized parameters are included in the 'Unrecognized Parameter' parameter.
RFCは、セクション3.3.3で.1が1か複数の認識されていないパラメタであることにかかわらず'認識されていないParameter'パラメタに含まれていると明確に述べません。
2.32.2. Text Changes to the Document
2.32.2. ドキュメントへのテキスト変化
---------
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
--------- 古いテキスト: (セクション3.3.3) --------- 可変パラメタ状態は値をタイプします。------------------------------------------------------------- 任意の8が電子証券取引ネットワークのできる(注意2)任意の32768(0×8000)ホスト名アドレス(注意3)の任意の11のために予約した6つのクッキーの義務的な7IPv4アドレス(注意1)の任意の5IPv6アドレス(注意1)の任意の認識されていないパラメタを述べてください。
---------
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
--------- 新しいテキスト: (セクション3.3.3) --------- 可変パラメタ状態は値をタイプします。------------------------------------------------------------- 任意の8が電子証券取引ネットワークのできる(注意2)任意の32768(0×8000)ホスト名アドレス(注意3)の任意の11のために予約したクッキーの義務的な7IPv4アドレス(注意1)の任意の5IPv6アドレス(注意1)の任意の6認識されていないパラメタを述べてください。
---------
Old text: (Section 3.3.3.1)
---------
Unrecognized Parameters:
--------- 古いテキスト: (セクション3.3.3、.1) --------- 認識されていないパラメタ:
Parameter Type Value: 8
パラメータの型値: 8
Parameter Length: Variable Size.
パラメタの長さ: 可変サイズ。
Stewart, et al. Informational [Page 67] RFC 4460 SCTP Errata April 2006
スチュワート、他 [67ページ]情報のRFC4460SCTP誤字2006年4月
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.
パラメタ値: INITがそれが送付者に報告されるべきであるのを示す値を持っている認識されていないパラメタを含むとき、このパラメタはINIT塊の創始者に返されます。 このパラメタ値の分野はParameter Type、Length、およびValue分野で完全なINIT塊からコピーされた認識されていないパラメタを含むでしょう。
---------
New text: (Section 3.3.3.1)
---------
Unrecognized Parameter:
--------- 新しいテキスト: (セクション3.3.3、.1) --------- 認識されていないパラメタ:
Parameter Type Value: 8
パラメータの型値: 8
Parameter Length: Variable Size.
パラメタの長さ: 可変サイズ。
Parameter Value:
パラメタ値:
This parameter is returned to the originator of the INIT
chunk when the INIT contains an unrecognized parameter
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.
INITがそれが送付者に報告されるべきであるのを示す値を持っている認識されていないパラメタを含むとき、このパラメタはINIT塊の創始者に返されます。 このパラメタ値の分野はParameter Type、Length、およびValue分野で完全なINIT塊からコピーされた認識されていないパラメタを含むでしょう。
2.32.3. Solution Description
2.32.3. ソリューション記述
The new text states clearly that only one unrecognized parameter is reported per parameter.
新しいテキストは、1つの認識されていないパラメタだけがパラメタ単位で報告されると明確に述べます。
2.33. Handling of Unrecognized Parameters
2.33. 認識されていないパラメタの取り扱い
2.33.1. Description of the Problem
2.33.1. 問題の記述
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.
[5] 認識されていないパラメタがどのように扱われるべきであるかはRFC2960に明確に述べられていません。 INITが最も高いビット00がある認識されていないパラメタを含んでいると、問題は来ます。 INIT-ACKを送るべきであるかどうかは明確ではありませんでした。
2.33.2. Text Changes to the Document
2.33.2. ドキュメントへのテキスト変化
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
スチュワート、他 [68ページ]情報のRFC4460SCTP誤字2006年4月
--------- Old text: (Section 3.2.1) ---------
--------- 古いテキスト: (セクション3.2.1) ---------
00 - Stop processing this SCTP packet and discard it, do not process
any further chunks within it.
00--このSCTPパケットを処理するのを止めてください、そして、それを捨ててください、そして、それの中でどんなさらなる塊も処理しないでください。
01 - Stop processing this SCTP packet and discard it, do not process
any further chunks within it, and report the unrecognized
parameter in an 'Unrecognized Parameter Type' (in either an
ERROR or in the INIT ACK).
01--停止がこのSCTPパケットを処理して、それを捨ててください、そして、それの中でどんなさらなる塊も処理しないでください、そして、'認識されていないParameter Type'(ERRORかINIT ACKの)の認識されていないパラメタを報告してください。
10 - Skip this parameter and continue processing.
10--このパラメタをスキップして、処理し続けています。
11 - Skip this parameter and continue processing but report the
unrecognized parameter in an 'Unrecognized Parameter Type' (in
either an ERROR or in the INIT ACK).
11--'認識されていないParameter Type'(ERRORかINIT ACKの)でこのパラメタをスキップして、処理し続けますが、認識されていないパラメタを報告します。
--------- New text: (Section 3.2.1) ---------
--------- 新しいテキスト: (セクション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--停止がこのパラメタを処理して、この塊の中でどんなさらなるパラメタも処理しないでください、そして、'認識されていないParameter Type'の認識されていないパラメタを報告してください、中で説明されるように3.2、.2
10 - Skip this parameter and continue processing.
10--このパラメタをスキップして、処理し続けています。
11 - Skip this parameter and continue processing but report the
unrecognized parameter in an 'Unrecognized Parameter Type', as
described in 3.2.2.
11--中で説明されるように'認識されていないParameter Type'でこのパラメタをスキップして、処理し続けますが、認識されていないパラメタを報告する、3.2、.2
--------- New text: (Note: no old text; clarification added in section 3.2) ---------
--------- 新しいテキスト: (注意: 古いテキストがありません; セクション3.2で加えられた明確化) ---------
3.2.2. Reporting of Unrecognized Parameters
3.2.2. 認識されていないパラメタの報告
If the receiver of an INIT chunk detects unrecognized parameters and has to report them according to Section 3.2.1, it MUST put the 'Unrecognized Parameter' parameter(s) in the INIT-ACK chunk sent in response to the INIT-chunk. Note that if the receiver of the INIT chunk is NOT going to establish an association (e.g., due to lack of
INIT塊の受信機が認識されていないパラメタを検出して、セクション3.2.1に従ってそれらを報告しなければならないなら、それはINIT-塊に対応して送られたINIT-ACK塊に'認識されていないParameter'パラメタを置かなければなりません。 INIT塊の受信機が協会を設立しないならそれに注意してください、(例えば欠けている支払われるべきもの
Stewart, et al. Informational [Page 69] RFC 4460 SCTP Errata April 2006
スチュワート、他 [69ページ]情報のRFC4460SCTP誤字2006年4月
resources), an 'Unrecognized Parameter' would NOT be included with any ABORT being sent to the sender of the INIT.
リソース)、'認識されていないParameter'はどんなABORTもINITの送付者に送って含まれていないでしょう。
If the receiver of an INIT-ACK chunk detects unrecognized parameters and has to report them according to Section 3.2.1, it SHOULD bundle the ERROR chunk containing the 'Unrecognized Parameter' error cause with the COOKIE-ECHO chunk sent in response to the INIT-ACK chunk. If the receiver of the INIT-ACK cannot bundle the COOKIE-ECHO chunk with the ERROR chunk, the ERROR chunk MAY be sent separately but not before the COOKIE-ACK has been received.
INIT-ACK塊の受信機が認識されていないパラメタを検出して、検出しなければならないなら、セクション3.2.1に従って、それらを報告してください、それ。COOKIE-ECHO塊のINIT-ACK塊に対応した送付での'認識されていないParameter'誤り原因を含んでいて、SHOULDはERROR塊を束ねます。 INIT-ACKの受信機がERROR塊でCOOKIE-ECHO塊を束ねることができないなら、別々にERROR塊を送るかもしれませんが、以前でないときに、COOKIE-ACKを受け取ったことがあります。
Note: Any time a COOKIE-ECHO is sent in a packet, it MUST be the first chunk.
以下に注意してください。 いつでも、パケットでCOOKIE-ECHOを送って、それは最初の塊であるに違いありません。
2.33.3. Solution Description
2.33.3. ソリューション記述
The procedure of handling unrecognized parameters has been described clearly.
認識されていないパラメタを扱う手順は明確に説明されます。
2.34. Tie Tags
2.34. 繋がりのタグ
2.34.1. Description of the Problem
2.34.1. 問題の記述
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.
RFC2960は、Tie-タグがCOOKIEに含まれているのを必要とします。 クッキーはコード化されないかもしれません。 攻撃者は、INITを送った後に受け取られたクッキーを分析することによって、Verification Tagsの値を発見できるでしょう。
2.34.2. Text Changes to the Document
2.34.2. ドキュメントへのテキスト変化
---------
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.
--------- 古いテキスト: (セクション1.4) --------- o 繋がりタグ: 前の協会からの検証Tags。 これらのTagsは、再開しなかった終点の中で新たに再開している協会をオリジナルの協会にリンクできるように州Cookieの中で使用されます。
--------- New text: (Section 1.4) ---------
--------- 新しいテキスト: (セクション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の噛み付いている一回だけを作ります。 これらのTagsは、再開しましたが、既存の協会の本当のVerification Tagsを明らかにしなかった終点の中で新たに再開している協会はオリジナルの協会にリンクできるように州CookieとTCBの中で使用されます。
Stewart, et al. Informational [Page 70] RFC 4460 SCTP Errata April 2006
スチュワート、他 [70ページ]情報のRFC4460SCTP誤字2006年4月
--------- Old text: (Section 5.2.1) ---------
--------- 古いテキスト: (セクション5.2.1) ---------
For an endpoint that is in the COOKIE-ECHOED state it MUST
populate its Tie-Tags with the Tag information of itself and
its peer (see Section 5.2.2 for a description of the Tie-Tags).
COOKIE-ECHOED状態にある終点に関しては、それはそれ自体とその同輩のTag情報でTie-タグに居住しなければなりません(Tie-タグの記述に関してセクション5.2.2を見てください)。
---------
New text: (Section 5.2.1)
---------
For an endpoint that is in the COOKIE-ECHOED state it MUST
populate its Tie-Tags within both the association TCB and
inside the State Cookie (see section 5.2.2 for a description
of the Tie-Tags).
--------- 新しいテキスト: (セクション5.2.1) --------- COOKIE-ECHOED状態にある終点に関しては、それは協会TCBと州Cookieの中で両方の中でTie-タグに居住しなければなりません(Tie-タグの記述に関してセクション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.
--------- 古いテキスト: (セクション5.2.2) --------- この協会のために別の方法で予期していなかったINITのレセプションに述べられない場合、終点は州Cookieと共にINIT ACKを発生させるものとします。 外国行きのINIT ACKでは、終点は州のクッキーの中の予約された場所にその現在のVerification Tagと同輩のVerification Tagをコピーしなければなりません。 私たちはPeerのものがタグを接続していて、Local繋がりのタグにこれらの位置について言及するつもりです。 このINIT ACK MUSTを含む外国行きのSCTPパケットは予期していなかったINITで見つけられたInitiation Tagと等しいVerification Tag値を運びます。 そして、INIT ACK MUSTは新しいInitiation Tagを含んでいます(手当たりしだいに発生して、セクション5.3.1を見てください)。 他のパラメタ、終点SHOULDに関しては、協会(例えば、外国行きの流れの数)の既存のパラメタから、INIT ACKとクッキーの中にコピーされてください。
--------- New text: (Section 5.2.2) ---------
--------- 新しいテキスト: (セクション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
この協会のための予期していなかったINITを受け取り次第別の方法で述べられない場合、終点は州Cookieと共にINIT ACKを発生させなければなりません。 外国行きのINIT ACKでは、終点は州のCookieと協会のTCBの中に現在のTie-タグを予約された場所にコピーしなければなりません。 私たちはPeerのものがタグを接続していて、Local繋がりのタグにクッキーの中のこれらの位置について言及するつもりです。 私たちは協会のTCBの中のコピーをLocal TagとPeerのTagと呼ぶつもりです。 このINIT ACK MUSTを含む外国行きのSCTPパケットは予期していなかったINITで見つけられたInitiation Tagと等しいVerification Tag値を運びます。 そして、INIT ACK MUSTはaを含んでいます。
Stewart, et al. Informational [Page 71] RFC 4460 SCTP Errata April 2006
スチュワート、他 [71ページ]情報のRFC4460SCTP誤字2006年4月
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.
新しいInitiation Tag、(;手当たりしだいに発生して、 セクション5.3.1を)見てください。 他のパラメタ、終点SHOULDに関しては、協会(例えば、外国行きの流れの数)の既存のパラメタから、INIT ACKとクッキーの中にコピーされてください。
2.34.3. Solution Description
2.34.3. ソリューション記述
The solution to this problem is not to use the real Verification Tags within the State Cookie as tie-tags. Instead, two 32-bit random numbers are created to form one 64-bit nonce and stored both in the State Cookie and the existing association TCB. This prevents exposing the Verification Tags inadvertently.
この問題の解決は繋がりタグとして州Cookieの中で本当のVerification Tagsを使用しないことです。 代わりに、2つの32ビットの乱数が、1つの64ビットの一回だけを形成するために作成されて、州Cookieと既存の協会TCBに格納されます。 これは、うっかりVerification Tagsを露出するのを防ぎます。
2.35. Port Number Verification in the COOKIE-ECHO
2.35. クッキーエコーにおけるポートナンバー検証
2.35.1. Description of the Problem
2.35.1. 問題の記述
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は元のポートナンバーか地方のVerification Tagを含まないかもしれません。 終点が、COOKIE-ECHOを受け取り次第これらの値が協会セットアップを始めたINITとINIT-ACKで見つけられた元の値に合っていることを確かめることができないのは、その時、可能です。
2.35.2. Text Changes to the Document
2.35.2. ドキュメントへのテキスト変化
---------
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,
--------- 古いテキスト: (セクション5.1.5) --------- 3) 州Cookieの創造タイムスタンプを現地時間の電流と比較してください。 経過時間が次に、州Cookieで運ばれた寿命、COOKIE ECHOと何か付属DATA塊、SHOULDを含むパケットより捨てられた状態で長いか、そして、終点は「新鮮でないクッキー」誤り原因でERROR塊を同輩終点に送らなければなりません。
4) If the State Cookie is valid, create an association to the
sender of the COOKIE ECHO chunk with the information in the
TCB data carried in the COOKIE ECHO, and enter the
ESTABLISHED state,
4) 州Cookieが有効であるなら、情報がCOOKIE ECHOで運ばれたTCBデータにある状態で、COOKIE ECHO塊の送付者に協会を創設してください、そして、ESTABLISHED状態に入れてください。
5) Send a COOKIE ACK chunk to the peer acknowledging reception
of the COOKIE ECHO. The COOKIE ACK MAY be bundled with an
outbound DATA chunk or SACK chunk; however, the COOKIE ACK
MUST be the first chunk in the SCTP packet.
5) COOKIE ECHOのレセプションを承認する同輩にCOOKIE ACK塊を送ってください。 COOKIE ACK MAY、外国行きのDATA塊かSACK塊で、束ねられてください。 しかしながら、COOKIE ACK MUST、SCTPパケットにおける最初の塊になってください。
6) Immediately acknowledge any DATA chunk bundled with the COOKIE
ECHO with a SACK (subsequent DATA chunk acknowledgement should
follow the rules defined in Section 6.2). As mentioned in step
6) 至急、どんなDATA塊もCOOKIE ECHOと共にSACKで荷物をまとめた(その後のDATA塊承認はセクション6.2で定義された規則に従うべきである)と認めてください。 中に言及されるように、踏んでください。
Stewart, et al. Informational [Page 72] RFC 4460 SCTP Errata April 2006
スチュワート、他 [72ページ]情報のRFC4460SCTP誤字2006年4月
5), if the SACK is bundled with the COOKIE ACK, the COOKIE ACK
MUST appear first in the SCTP packet.
5) SACKがCOOKIE ACKと共に束ねられるなら、COOKIE ACK MUSTは最初に、SCTPパケットに現れます。
--------- New text: (Section 5.1.5) ---------
--------- 新しいテキスト: (セクション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) 容認されたパケットのSCTPの一般的なヘッダーの中にCOOKIE ECHO塊の中に実際のポートナンバーとVerification Tagに含まれたポートナンバーとVerification Tagを比較してください。 これらの値が合っていないなら、静かにパケットを捨てなければなりません。
4) Compare the creation timestamp in the State Cookie to the
current local time. If the elapsed time is longer than the
lifespan carried in the State Cookie, then the packet,
including the COOKIE ECHO and any attached DATA chunks,
SHOULD be discarded, and the endpoint MUST transmit an
ERROR chunk with a "Stale Cookie" error cause to the peer
endpoint.
4) 州Cookieの創造タイムスタンプを現地時間の電流と比較してください。 経過時間が寿命が運び込んだより長いなら、州Cookie、次に、捨てられて、COOKIE ECHOとどんな付属DATA塊、SHOULDも含むパケット、および終点は「新鮮でないクッキー」誤り原因でERROR塊を同輩終点に送らなければなりません。
5) If the State Cookie is valid, create an association to the
sender of the COOKIE ECHO chunk with the information in the
TCB data carried in the COOKIE ECHO and enter the
ESTABLISHED state.
5) 州Cookieが有効であるなら、情報がCOOKIE ECHOで運ばれたTCBデータにある状態で、COOKIE ECHO塊の送付者に協会を創設してください、そして、ESTABLISHED状態に入れてください。
6) Send a COOKIE ACK chunk to the peer acknowledging receipt of
the COOKIE ECHO. The COOKIE ACK MAY be bundled with an
outbound DATA chunk or SACK chunk; however, the COOKIE ACK
MUST be the first chunk in the SCTP packet.
6) COOKIE ECHOの領収書を受け取ったことを知らせる同輩にCOOKIE ACK塊を送ってください。 COOKIE ACK MAY、外国行きのDATA塊かSACK塊で、束ねられてください。 しかしながら、COOKIE ACK MUST、SCTPパケットにおける最初の塊になってください。
7) Immediately acknowledge any DATA chunk bundled with the COOKIE
ECHO with a SACK (subsequent DATA chunk acknowledgement should
follow the rules defined in Section 6.2). As mentioned in step
5, if the SACK is bundled with the COOKIE ACK, the COOKIE ACK
MUST appear first in the SCTP packet.
7) 至急、どんなDATA塊もCOOKIE ECHOと共にSACKで荷物をまとめた(その後のDATA塊承認はセクション6.2で定義された規則に従うべきである)と認めてください。 ステップ5で言及されるように、SACKがCOOKIE ACKと共に束ねられるなら、COOKIE ACK MUSTは最初に、SCTPパケットで見えます。
2.35.3. Solution Description
2.35.3. ソリューション記述
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の中にポートナンバーと地方のVerification Tagの両方を含んで、COOKIE-ECHO処理の間、これらについて確かめることによって、この問題は解決されています。
Stewart, et al. Informational [Page 73] RFC 4460 SCTP Errata April 2006
スチュワート、他 [73ページ]情報のRFC4460SCTP誤字2006年4月
2.36. Path Initialization
2.36. 経路初期設定
2.36.1. Description of the Problem
2.36.1. 問題の記述
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
2.36.2. ドキュメントへのテキスト変化
--------- Old text: None ---------
--------- 古いテキスト: なし---------
--------- New text: (Section 5.4) --------- 5.4. Path Verification
--------- 新しいテキスト: (セクション5.4) --------- 5.4. 経路検証
During association establishment, the two peers exchange a list of addresses. In the predominant case, these lists accurately represent the addresses owned by each peer. However, it is possible that a misbehaving peer may supply addresses that it does not own. To prevent this, the following rules are applied to all addresses of the new association:
協会設立の間、2人の同輩が住所録を交換します。 支配的な場合では、これらのリストは正確に各同輩によって所有されていたアドレスを表します。 しかしながら、ふらちな事をしている同輩がそれが所有していないアドレスを供給するのは、可能です。 これを防ぐために、以下の規則は新連合のすべてのアドレスに適用されます:
1) Any address passed to the sender of the INIT by its upper layer is
automatically considered to be CONFIRMED.
1) 上側の層でINITの送付者に渡されたどんなアドレスもCONFIRMEDであると自動的に考えられます。
2) For the receiver of the COOKIE-ECHO the only CONFIRMED address is
the one that the INIT-ACK was sent to.
2) COOKIE-ECHOの受信機に関しては、唯一のCONFIRMEDアドレスがINIT-ACKが送られたものです。
3) All other addresses not covered by rules 1 and 2 are considered
UNCONFIRMED and are subject to probing for verification.
3) 規則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.
検証のためのアドレスを調べるために、終点はHEARTBEATパラメタの中に64ビットの無作為の一回だけと経路インディケータ(HEARTBEATが送られるアドレスを特定する)を含むHEARTBEATsを送るでしょう。
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
スチュワート、他 [74ページ]情報のRFC4460SCTP誤字2006年4月
These probing procedures are started when an association moves to the ESTABLISHED state and are ended when all paths are confirmed.
手順を調べるこれらは、協会がESTABLISHED状態に動くとき、始められて、すべての経路が確認されるとき、終わっています。
Each RTO a probe may be sent on an active UNCONFIRMED path in an attempt to move it to the CONFIRMED state. If during this probing the path becomes inactive, this rate is lowered to the normal HEARTBEAT rate. At the expiration of the RTO timer, the error counter of any path that was probed but not CONFIRMED is incremented by one and subjected to path failure detection, as defined in section 8.2. When probing UNCONFIRMED addresses, however, the association overall error count is NOT incremented.
探測装置がそれをCONFIRMED状態に動かす試みにおけるアクティブなUNCONFIRMED経路で送られるかもしれない各RTO。 経路がこの調べの間、不活発になるなら、このレートは標準のHEARTBEATレートに下げられます。 RTOタイマの満了のときに、CONFIRMEDではなく、調べられたどんな経路の誤りカウンタも、1つ増加されて、経路失敗検出にかけられます、セクション8.2で定義されるように。 しかしながら、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.
制限されていて、HB.Max.Burstパラメタによって各RTO SHOULDに送られたHEARTBEATSの数。 それはどう経路検証のための同輩のアドレスにHEARTBEATSを分配するかに関する実現決定です。
Whenever a path is confirmed, an indication MAY be given to the upper layer.
経路が確認されるときはいつも、上側の層に指示を与えるかもしれません。
An endpoint MUST NOT send any chunks to an UNCONFIRMED address, with the following exceptions:
終点はどんな塊もUNCONFIRMEDアドレスに以下の例外で送ってはいけません:
- A HEARTBEAT including a nonce MAY be sent to an UNCONFIRMED
address.
- 一回だけを含むHEARTBEATをUNCONFIRMEDアドレスに送るかもしれません。
- A HEARTBEAT-ACK MAY be sent to an UNCONFIRMED address.
- HEARTBEAT-ACK MAY、UNCONFIRMEDアドレスに送ってください。
- 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.
- UNCONFIRMEDアドレスにCOOKIE-ACK MAYを送って、HEARTBEATが一回だけを含んでいて、それだけを束ねなければなりません。 荷物をまとめるのを支持しない実現はUNCONFIRMEDアドレスにCOOKIE-ACKを送ってはいけません。
- 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.
- クック-ECHO MAYをUNCONFIRMEDアドレスに送って、HEARTBEATが一回だけを含んでいて、それだけを束ねなければなりません、そして、パケットは経路MTUを超えてはいけません。 実現が、荷物をまとめるのを支持しないか、または束ねられたCOOKIE-ECHOとHEARTBEAT(一回だけを含んでいる)が経路MTUを超えているなら、実現はUNCONFIRMEDアドレスにCOOKIE-ECHOを送ってはいけません。
--------- Old text: (Section 14) ---------
--------- 古いテキスト: (セクション14) ---------
14. Suggested SCTP Protocol Parameter Values
14. 提案されたSCTPプロトコルパラメタ値
The following protocol parameters are RECOMMENDED:
以下のプロトコルパラメタはRECOMMENDEDです:
Stewart, et al. Informational [Page 75] RFC 4460 SCTP Errata April 2006
スチュワート、他 [75ページ]情報のRFC4460SCTP誤字2006年4月
RTO.Initial - 3 seconds RTO.Min - 1 second RTO.Max - 60 seconds RTO.Alpha - 1/8 RTO.Beta - 1/4 Valid.Cookie.Life - 60 seconds Association.Max.Retrans - 10 attempts Path.Max.Retrans - 5 attempts (per destination address) Max.Init.Retransmits - 8 attempts HB.interval - 30 seconds
RTO.Initial--3秒のRTO.Min--1 第2RTO.Max--60秒のRTO.Alpha----1/4Valid.Cookie.Life--60秒Association.Max.Retrans(10試みPath.Max.Retrans)5試み(送付先アドレスあたりの)Max.Init.Retransmits--8試みHB.interval--30秒の1/8RTO.Beta
--------- New text: (Section 14) ---------
--------- 新しいテキスト: (セクション14) ---------
14. Suggested SCTP Protocol Parameter Values
14. 提案されたSCTPプロトコルパラメタ値
The following protocol parameters are RECOMMENDED:
以下のプロトコルパラメタはRECOMMENDEDです:
RTO.Initial - 3 seconds RTO.Min - 1 second RTO.Max - 60 seconds Max.Burst - 4 RTO.Alpha - 1/8 RTO.Beta - 1/4 Valid.Cookie.Life - 60 seconds Association.Max.Retrans - 10 attempts Path.Max.Retrans - 5 attempts (per destination address) Max.Init.Retransmits - 8 attempts HB.Interval - 30 seconds HB.Max.Burst - 1
RTO.Initial--3 RTO.Min--RTO.Max--60秒Max.Burst(4RTO.Alpha)1/8RTO.Beta(1/4Valid.Cookie.Life)60の秒Association.Max.Retrans--10はPath.Max.Retransを試みます--5がMax.Init.Retransmitsを試みる(送付先アドレス単位で)1秒----30秒のHB.Max.Burst--1の秒8試みHB.Interval
2.36.3. Solution Description
2.36.3. ソリューション記述
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
2.37. ICMP取り扱い手順
2.37.1. Description of the Problem
2.37.1. 問題の記述
RFC 2960 does not describe how ICMP messages should be processed by an SCTP endpoint.
RFC2960はICMPメッセージがSCTP終点によってどう処理されるべきであるかを説明しません。
Stewart, et al. Informational [Page 76] RFC 4460 SCTP Errata April 2006
スチュワート、他 [76ページ]情報のRFC4460SCTP誤字2006年4月
2.37.2. Text Changes to the Document
2.37.2. ドキュメントへのテキスト変化
-------- Old text: None --------
-------- 古いテキスト: なし--------
--------- New text ---------
--------- 新しいテキスト---------
11.5. Protection of Non-SCTP Capable Hosts.
11.5. 非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取り扱いを実行しなければなりません。
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塊と処理が応答における、複数の塊の発信を必要とするとき、応答塊の送付者は1つ以上のパケットを送ってはいけません。 バンドリングが支持されるなら、単一のパケットに収まる複数の応答塊が1つの単一の応答パケットに一緒に投げ込まれるかもしれません。 バンドリングが支持されないなら、送付者は、1つ以上の応答塊を送ってはいけなくて、他のすべての応答を捨てなければなりません。 この規則がSACK塊に適用されないことに注意してください、本来SACK塊がDATAへの応答であり、SACKが、より多くのDATAの応答を必要としないので。
An SCTP implementation SHOULD abort the association if it receives a SACK acknowledging a TSN that has not been sent.
送られないTSNを承認しながらSACKを受けるなら、SCTP実現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を受けるSCTP実現は、複数のERRORパラメタの包含のためINIT-ACKのサイズを減少させるためにERRORパラメタのいくつかかすべてを省略するのを(自己判断で)選ぶかもしれません。 INITの受信機が同輩に示しているかもしれないCOOKIEパラメタのサイズとアドレスの数の組み合わせのために、INIT-ACKがオリジナルのINITよりさらに大きくなるのは、いつも可能です。 INIT-ACKをバイト増幅の可能性を減少させるためにできるだけ小さくするSCTP実現SHOULD試みは攻撃されます。
--------- Old text: None ---------
--------- 古いテキスト: なし---------
Stewart, et al. Informational [Page 77] RFC 4460 SCTP Errata April 2006
スチュワート、他 [77ページ]情報のRFC4460SCTP誤字2006年4月
--------- New text: (Appendix C) ---------
--------- 新しいテキスト: (付録C) ---------
Appendix C ICMP Handling
付録C ICMP取り扱い
Whenever an ICMP message is received by an SCTP endpoint the following procedures MUST be followed to ensure proper utilization of the information being provided by layer 3.
SCTP終点でICMPメッセージを受け取るときはいつも、層3で提供される情報の適切な利用を確実にするために以下の手順に従わなければなりません。
ICMP1) An implementation MAY ignore all ICMPv4 messages where the
type field is not set to "Destination Unreachable".
ICMP1) 実現はタイプ分野が「目的地手の届かなく」設定されないすべてのICMPv4メッセージを無視するかもしれません。
ICMP2) An implementation MAY ignore all ICMPv6 messages where the
type field is not "Destination Unreachable, "Parameter
Problem" or "Packet Too Big".
ICMP2) または、実現がタイプ分野がそうでないすべてのICMPv6メッセージを無視するかもしれない、「手の届かない目的地「パラメタ問題」、「パケット、あまりに大きい」、」
ICMP3) An implementation MAY ignore any ICMPv4 messages where the
code does not indicate "Protocol Unreachable" or
"Fragmentation Needed".
ICMP3) 実現がコードがそうしないどんなICMPv4メッセージも無視するかもしれない、表示、「」 手の届かない「必要である断片化」について議定書の中で述べてください。
ICMP4) An implementation MAY ignore all ICMPv6 messages of type
"Parameter Problem" if the code is not "Unrecognized next
header type encountered".
ICMP4) 実現はコードが「タイプが遭遇した次の認識されていないヘッダー」でないならタイプ「パラメタ問題」に関するすべてのICMPv6メッセージを無視するかもしれません。
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)のペイロードを使用しなければなりません。 協会を見つけることができないなら、実現SHOULDはICMPメッセージを無視します。
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) 実現は有効にされなければなりません。Verification TagはICMPメッセージマッチに同輩の検証タグを含みました。 Verification Tagが0歳でなく、また合っていないなら、ICMPメッセージを捨ててください。 それが0であり、ICMPメッセージが塊タイプがINIT塊であり、開始タグが同輩のタグに合っていることを確かめることができるくらいのバイトを含むなら、ICMP7を続行してください。 ICMPメッセージが短過ぎるか、または塊タイプか開始タグが合っていないなら、静かにパケットを捨ててください。
ICMP7) If the ICMP message is either a V6 "Packet Too Big" or a V4
"Fragmentation Needed", an implementation MAY process this
information as defined for PATH MTU discovery.
ICMP7) ICMPメッセージがV6である、「パケット、PATH MTU発見のために定義されて、」 大き過ぎるV4「必要である断片化」と実現は、この情報を処理するかもしれません。
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
ICMP8) ICMPコードが「タイプが遭遇した次の認識されていないヘッダー」であるかaが「プロトコル手が届きません」なら、実現はそれがINIT塊を含んでいないなら設定されたTビットでこのメッセージをアボートとして扱わなければなりません。 それがINITを含んでいるなら
Stewart, et al. Informational [Page 78] RFC 4460 SCTP Errata April 2006
スチュワート、他 [78ページ]情報のRFC4460SCTP誤字2006年4月
chunk and the association is in COOKIE-WAIT state, handle the
ICMP message like an ABORT.
塊と協会は、ABORTのようにCOOKIE-WAIT状態にあって、ICMPメッセージを扱います。
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コードが「目的地手が届きません」なら、実現は、手の届かない状態に目的地を示すか、またはあるいはまた、経路誤りカウンタを増加するかもしれません。
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.
これらの手順がRFC1122[1]とポート手の届かないメッセージの処理のための要件と実現が「プロトコル手の届かない」メッセージに対応して協会を中止しなければならないという要件と異なることに注意してください。 意志がABORTを送る実現以来ポートの手の届かないメッセージはaポート手の届かないのではなく処理されていません。 「プロトコル手の届かない」メッセージの、より厳しい取り扱いはSCTPを支持しないホストのための安全上の配慮のためです。
2.37.3. Solution Description
2.37.3. ソリューション記述
The new appendix now describes proper handling of ICMP messages in conjunction with SCTP.
新しい付録は現在、SCTPに関連してICMPメッセージの適切な取り扱いについて説明します。
2.38. Checksum
2.38. チェックサム
2.38.1. Description of the problem
2.38.1. 問題の記述
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).
RFC3309[6]はオリジナルのアドラー32チェックサムにおける弱点のため小さいメッセージのためにSCTPチェックサムを変えます。 その結果、また、カットアンドペースト交換がRFC2960をアップデートするのにガイドとして使用されるこのドキュメントは、チェックサム変化を取り入れる必要があります。 考えは1つがこのガイドでRFC2960のコピーに見つけられたすべての変化を適用して、すべての変化を持っている「新しい」ドキュメントを持っているかもしれないという(RFC3309を含んでいて)ことです。
2.38.2. Text Changes to the Document
2.38.2. ドキュメントへのテキスト変化
--------- Old text: ---------
--------- 古いテキスト: ---------
6.8 Adler-32 Checksum Calculation
6.8 アドラー-32チェックサム計算
When sending an SCTP packet, the endpoint MUST strengthen the data
integrity of the transmission by including the Adler-32 checksum
value calculated on the packet, as described below.
SCTPパケットを送るとき、終点はパケットの上で計算されたアドラー-32チェックサム価値を含んでいることによって、トランスミッションのデータ保全を強化しなければなりません、以下で説明されるように。
After the packet is constructed (containing the SCTP common header
and one or more control or DATA chunks), the transmitter shall:
パケットが組み立てられた(SCTPの一般的なヘッダーと1つ以上のコントロールかDATA塊を含んでいて)後に、送信機は組み立てられるでしょう:
Stewart, et al. Informational [Page 79] RFC 4460 SCTP Errata April 2006
スチュワート、他 [79ページ]情報のRFC4460SCTP誤字2006年4月
1) Fill in the proper Verification Tag in the SCTP common header
and initialize the checksum field to 0's.
1) SCTPの一般的なヘッダーに適切なVerification Tagに記入してください、そして、チェックサム分野を0に初期化してください。
2) Calculate the Adler-32 checksum of the whole packet, including
the SCTP common header and all the chunks. Refer to
appendix B for details of the Adler-32 algorithm. And,
2) SCTPの一般的なヘッダーとすべての塊を含む全体のパケットのアドラー-32チェックサムについて計算してください。 アドラー-32アルゴリズムの詳細について付録Bを参照してください。 そして
3) Put the resultant value into the checksum field in the common
header, and leave the rest of the bits unchanged.
3) 一般的なヘッダーのチェックサム分野に結果の値を入れてください、そして、ビットの残りを変わりがないままにしてください。
When an SCTP packet is received, the receiver MUST first check the
Adler-32 checksum:
SCTPパケットが受け取られているとき、受信機は最初に、アドラー-32チェックサムをチェックしなければなりません:
1) Store the received Adler-32 checksum value aside,
1) 傍らに容認されたアドラー-32チェックサム価値を格納してください。
2) Replace the 32 bits of the checksum field in the received SCTP
packet with all '0's and calculate an Adler-32 checksum value
of the whole received packet. And,
2) 容認されたSCTPパケットのチェックサム分野の32ビットをすべての'に0取り替えてくださいといって、全体の容認されたパケットのアドラー-32チェックサム価値について計算してください、' そして
3) Verify that the calculated Adler-32 checksum is the same as the
received Adler-32 checksum. If not, the receiver MUST treat
the packet as an invalid SCTP packet.
3) 計算されたアドラー-32チェックサムが容認されたアドラー-32チェックサムと同じであることを確かめてください。 そうでなければ、受信機は無効のSCTPパケットとしてパケットを扱わなければなりません。
The default procedure for handling invalid SCTP packets is to
silently discard them.
無効のSCTPパケットを扱うためのデフォルト手順は静かにそれらを捨てることです。
--------- New text: ---------
--------- 新しいテキスト: ---------
6.8 CRC-32c Checksum Calculation
6.8 CRC-32cチェックサム計算
When sending an SCTP packet, the endpoint MUST strengthen the data
integrity of the transmission by including the CRC32c checksum
value calculated on the packet, as described below.
SCTPパケットを送るとき、終点はパケットの上で計算されたCRC32cチェックサム価値を含んでいることによって、トランスミッションのデータ保全を強化しなければなりません、以下で説明されるように。
After the packet is constructed (containing the SCTP common header
and one or more control or DATA chunks), the transmitter MUST
パケットが組み立てられた(SCTPの一般的なヘッダーと1つ以上のコントロールかDATA塊を含んでいて)後に、送信機は組み立てられなければなりません。
1) fill in the proper Verification Tag in the SCTP common header
and initialize the checksum field to '0's,
1) SCTPの一般的なヘッダーに適切なVerification Tagに記入してくださいといって、チェックサム分野を'に0初期化してください、'
2) calculate the CRC32c checksum of the whole packet, including
the SCTP common header and all the chunks (refer to
appendix B for details of the CRC32c algorithm); and
2) 全体のパケットのCRC32cチェックサムについて計算してください、SCTPの一般的なヘッダーとすべての塊を含んでいて、ことです(CRC32cアルゴリズムの詳細について付録Bを参照してください)。 そして
3) put the resultant value into the checksum field in the common
header, and leave the rest of the bits unchanged.
3) 一般的なヘッダーのチェックサム分野に結果の値を入れてください、そして、ビットの残りを変わりがないままにしてください。
Stewart, et al. Informational [Page 80] RFC 4460 SCTP Errata April 2006
スチュワート、他 [80ページ]情報のRFC4460SCTP誤字2006年4月
When an SCTP packet is received, the receiver MUST first check the
CRC32c checksum as follows:
SCTPパケットが受け取られているとき、受信機は最初に、以下のCRC32cチェックサムをチェックしなければなりません:
1) Store the received CRC32c checksum value aside.
1) 傍らに容認されたCRC32cチェックサム価値を格納してください。
2) Replace the 32 bits of the checksum field in the received SCTP
packet with all '0's and calculate a CRC32c checksum value of
the whole received packet.
2) 容認されたSCTPパケットのチェックサム分野の32ビットをすべての'に0取り替えてくださいといって、全体の容認されたパケットのCRC32cチェックサム価値について計算してください、'
3) Verify that the calculated CRC32c checksum is the same as the
received CRC32c checksum. If it is not, the receiver MUST
treat the packet as an invalid SCTP packet.
3) 計算されたCRC32cチェックサムが容認されたCRC32cチェックサムと同じであることを確かめてください。 それがそうでないなら、受信機は無効のSCTPパケットとしてパケットを扱わなければなりません。
The default procedure for handling invalid SCTP packets is to
silently discard them.
無効のSCTPパケットを扱うためのデフォルト手順は静かにそれらを捨てることです。
Any hardware implementation SHOULD be done in a way that is
verifiable by the software.
どんなハードウェア実装SHOULD、もソフトウェアで証明可能な方法でしてください。
--------- Old text: ---------
--------- 古いテキスト: ---------
Appendix B Alder 32 bit checksum calculation
32ビットの付録B Alderチェックサム計算
The Adler-32 checksum calculation given in this appendix is
copied from [RFC1950].
この付録で与えられたアドラー-32チェックサム計算は[RFC1950]からコピーされます。
Adler-32 is composed of two sums accumulated per byte: s1 is the
sum of all bytes, s2 is the sum of all s1 values. Both sums are
done modulo 65521. s1 is initialized to 1, s2 to zero. The
Adler-32 checksum is stored as s2*65536 + s1 in network byte
order.
アドラー-32は1バイト単位で蓄積された2つの合計で構成されます: s1がすべてのバイトの合計である、s2はすべてのs1値の合計です。 両方の合計に法65521をします。1、ゼロへのs2にs1を初期化します。 アドラー-32チェックサムはs2*65536+s1としてネットワークバイトオーダーに格納されます。
The following C code computes the Adler-32 checksum of a data
buffer. It is written for clarity, not for speed. The sample
code is in the ANSI C programming language. Non C users may
find it easier to read with these hints:
以下のCコードはデータバッファのアドラー-32チェックサムを計算します。 それは速度のために書かれているのではなく、明快ために書かれています。 ANSI Cプログラミング言語にはサンプルコードがあります。 非Cユーザは、これらのヒントで読書するのが、より簡単であることがわかるかもしれません:
& Bitwise AND operator.
>> Bitwise right shift operator. When applied to an
unsigned quantity, as here, right shift inserts zero bit(s)
at the left.
<< Bitwise left shift operator. Left shift inserts zero
bit(s) at the right.
++ "n++" increments the variable n.
% modulo operator: a % b is the remainder of a divided by b.
ANDオペレータをBitwiseします。 >>は正しいシフトオペレータをBitwiseします。 正しいシフト差し込みがここで左におけるビットのゼロに合っていて無記名の量に適用されると。 <<は左のシフトオペレータをBitwiseします。 左のシフト差し込みは権利におけるビットのゼロに合っています。 + +、「n++」は可変nを増加します。 %、法オペレータ: %bはbが割られたaの残りです。
Stewart, et al. Informational [Page 81] RFC 4460 SCTP Errata April 2006
スチュワート、他 [81ページ]情報のRFC4460SCTP誤字2006年4月
#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.
#65536*//*より小さく基地の65521/*最も大きい第1を定義してください。バイトbuf[0..len-1]で走行アドラー-32チェックサムをアップデートしてください、そして、アップデートされたチェックサムを返してください。 アドラー-32チェックサムは1に初期化されるべきです。
Usage example:
使用例:
unsigned long adler = 1L;
無記名の長い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;
(_バッファ(バッファ、長さ)!=EOFを読みます) adler=アップデート_adler32(adler、バッファ、長さ); (adler!はオリジナル_adlerと等しいです)誤り()であるなら。 */無記名の長いアップデート_adler32(無記名の長いadler、無記名の炭の*をbufされます、int len)、無記名の長いs1はadlerと0xffffと等しいです; 無記名の長い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;
}
(n=0; n<len; n++)、s1が等しい、(s1+buf[n])%基地; s2は%基地と等しいです(s2+s1);、+ リターン(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);
}
/*はバイトbuf[0..len-1]*/無記名の長いadler32(無記名の炭*buf、int len)のadler32を返します。リターンアップデート_adler32(1L、buf、len)。
--------- New text: ---------
--------- 新しいテキスト: ---------
Appendix B CRC32c Checksum Calculation
付録B CRC32cチェックサム計算
We define a 'reflected value' as one that is the opposite of the
normal bit order of the machine. The 32-bit CRC is calculated as
described for CRC-32c and uses the polynomial code 0x11EDC6F41
(Castagnoli93) or x^32+x^28+x^27+x^26+x^25
+x^23+x^22+x^20+x^19+x^18+x^14+x^13+x^11+x^10+x^9+x^8+x^6+x^0.
The CRC is computed using a procedure similar to ETHERNET CRC
[ITU32], modified to reflect transport level usage.
私たちはマシンの標準のビットの正反対であるものとしての'反射した値'注文を定義します。 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. CRCは、輸送レベル用法を反映するように変更されたETHERNET CRC[ITU32]と同様の手順を用いることで計算されます。
Stewart, et al. Informational [Page 82] RFC 4460 SCTP Errata April 2006
スチュワート、他 [82ページ]情報のRFC4460SCTP誤字2006年4月
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) 多項式演算[ピーターソン72]を使用することで計算されます。
When CRCs are used at the link layer, the polynomial is derived
from on-the-wire bit ordering: the first bit 'on the wire' is the
high-order coefficient. Since SCTP is a transport-level protocol,
it cannot know the actual serial-media bit ordering. Moreover,
different links in the path between SCTP endpoints may use
different link-level bit orders.
リンクレイヤでCRCsを使用するとき、以下を注文するワイヤのビットから多項式を得ます。 'ワイヤ'の最初のビットは高位係数です。 SCTPが輸送レベルプロトコルであるので、それは、実際の連続のメディアが注文に噛み付いたのを知ることができません。 そのうえ、SCTP終点の間の経路の異なったリンクは異なったリンク・レベル噛み付いている命令を使用するかもしれません。
A convention must therefore be established for mapping SCTP
transport messages to polynomials for purposes of CRC computation.
The bit-ordering for mapping SCTP messages to polynomials is that
bytes are taken most-significant first; but within each byte, bits
are taken least-significant first. The first byte of the message
provides the eight highest coefficients. Within each byte,
the least-significant SCTP bit gives the most significant
polynomial coefficient within that byte, and the most-significant
SCTP bit is the least significant polynomial coefficient in that
byte. (This bit ordering is sometimes called 'mirrored' or
'reflected' [WILLIAMS93].) CRC polynomials are to be transformed
back into SCTP transport-level byte values, using a consistent
mapping.
したがって、CRC計算の目的のためにSCTP輸送メッセージを多項式に写像するためにコンベンションを設立しなければなりません。 SCTPメッセージを多項式に写像するためのビット注文は最初に最も重要な状態でバイトを取るということです。 しかし、各バイトの中では、最初に、最も最少に重要な状態でビットを取ります。 メッセージの最初のバイトは8つの最も高い係数を提供します。 各バイトの中では、最も最少に重要なSCTPビットはそのバイトの中で最も重要な多項式係数を与えます、そして、最も多くの重要なSCTPビットはそのバイトで最も重要でない多項式係数です。 (注文が時々呼ばれるこのビットは、[WILLIAMS93]を'映す'か、または'反映しました'。) CRC多項式は一貫したマッピングを使用して、SCTP輸送レベルバイト値に変えて戻られることです。
The SCTP transport-level CRC value should be calculated as
follows:
SCTP輸送レベルCRC価値は以下の通り計算されるべきです:
- CRC input data are assigned to a byte stream, numbered from
0 to N-1.
- CRC入力データは0〜N-1まで付番されたバイト・ストリームに割り当てられます。
- The transport-level byte-stream is mapped to a polynomial
value. An N-byte PDU with j bytes numbered 0 to N-1 is
considered as coefficients of a polynomial M(x) of order
8N-1, with bit 0 of byte j being coefficient x^(8(N-j)-8),
and bit 7 of byte j being coefficient x^(8(N-j)-1).
- 輸送レベルバイト・ストリームは多項式値に写像されます。 N-1へのjバイト番号付の0があるN-バイトPDUはオーダー8N-1の多項式M(x)の係数であるとみなされます、バイトjのビット0が係数x^(8(N-j)-8)であり、バイトjのビット7が係数x^(8(N-j)-1)であることで。
- The CRC remainder register is initialized with all 1s and
the CRC is computed with an algorithm that simultaneously
multiplies by x^32 and divides by the CRC polynomial.
- CRC残りレジスタはすべての1で初期化されます、そして、CRCは同時に、x^32で増えて、CRC多項式で割られるアルゴリズムで計算されます。
- The polynomial is multiplied by x^32 and divided by G(x),
the generator polynomial, producing a remainder R(x) of
degree less than or equal to 31.
- 多項式はx^32が掛けられて、G(x)を割られます、ジェネレータ多項式、度の31以下の残りR(x)を生産して。
- The coefficients of R(x) are considered a 32-bit sequence.
- R(x)の係数は32ビットの系列であると考えられます。
Stewart, et al. Informational [Page 83] RFC 4460 SCTP Errata April 2006
スチュワート、他 [83ページ]情報のRFC4460SCTP誤字2006年4月
- The bit sequence is complemented. The result is the CRC
polynomial.
- 噛み付いている系列は補足となります。 結果はCRC多項式です。
- The CRC polynomial is mapped back into SCTP transport-level
bytes. The coefficient of x^31 gives the value of bit 7 of
SCTP byte 0, and the coefficient of x^24 gives the value of
bit 0 of byte 0. The coefficient of x^7 gives bit 7 of
byte 3, and the coefficient of x^0 gives bit 0 of byte 3.
The resulting four-byte transport-level sequence is the
32-bit SCTP checksum value.
- CRC多項式はSCTP輸送レベルバイトに写像して戻されます。 x^31の係数はSCTPバイト0のビット7の価値を与えます、そして、x^24の係数はバイト0のビット0の価値を与えます。 x^7の係数はバイト3のビット7を与えます、そして、x^0の係数はバイト3のビット0を与えます。 結果として起こる4バイトの輸送レベル系列は32ビットのSCTPチェックサム価値です。
IMPLEMENTATION NOTE: Standards documents, textbooks, and vendor
literature on CRCs often follow an alternative formulation, in
which the register used to hold the remainder of the
long-division algorithm is initialized to zero rather than
all-1s, and instead the first 32 bits of the message are
complemented. The long-division algorithm used in our
formulation is specified such that the initial
multiplication by 2^32 and the long-division are combined into
one simultaneous operation. For such algorithms, and for
messages longer than 64 bits, the two specifications are
precisely equivalent. That equivalence is the intent of
this document.
実現注意: CRCsに関する規格文書、教科書、および業者文学はしばしば代替の定式化に続きます、そして、代わりにメッセージの最初の32ビットは補足となります。(そこでは、長除法アルゴリズムの残りを保持するのに使用されるレジスタがall-1sよりむしろゼロに初期化されます)。 私たちの定式化に使用される長除法アルゴリズムが指定されるので、2^32の初期の乗法と長除法は1つの同時処理操作に結合されます。 そのようなアルゴリズム、および64ビットより長いメッセージに関しては、2つの仕様が正確に同等です。 その等価性はこのドキュメントの意図です。
Implementors of SCTP are warned that both specifications are to be
found in the literature, sometimes with no restriction on the
long-division algorithm. The choice of formulation in this
document is to permit non-SCTP usage, where the same CRC
algorithm may be used to protect messages shorter than 64 bits.
SCTPの作成者は両方の仕様が文学で見つけられることであるのに注意されます、無制限に時々長除法アルゴリズムで。 このドキュメントにおける定式化の選択は非SCTP用法が64ビットより短いメッセージを保護することを許可することです。(そこでは、同じCRCアルゴリズムが使用されるかもしれません)。
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.
Verification Tagに対してAssociationを有効にするのにおいてコンピュータの利点があるかもしれません、チェックサムを実行する前に、多くの場合、無効のタグが悪いチェックサムと同じ動作をもたらす間。 このテクニックのための例外は、INITと、いくつかのSHUTDOWN-COMPLETE交換と、聞き古したCOOKIE-ECHOでしょう。 これらの特別なケース交換は、小型小包を表さなければならなくて、チェックサム計算の効果を最小にするでしょう。
--------- Old text: (Section 18) ---------
--------- 古いテキスト: (セクション18) ---------
18. Bibliography
18. 図書目録
[ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End
Network Path Properties", Proc. SIGCOMM'99, 1999.
[ALLMAN99]オールマン、M.、およびパクソン対「終わりから端へのネットワーク経路が土地であると見積もっている」ときのProc SIGCOMM'99、1999'。
Stewart, et al. Informational [Page 84] RFC 4460 SCTP Errata April 2006
スチュワート、他 [84ページ]情報のRFC4460SCTP誤字2006年4月
[FALL96] Fall, K. and Floyd, S., Simulation-based Comparisons of
Tahoe, Reno, and SACK TCP, Computer Communications Review,
V. 26 N. 3, July 1996, pp. 5-21.
[FALL96] 秋とK.とフロイドとS.、タホ、リノのSimulationベースのComparisonsとSACK TCP、コンピュータCommunications Review、V.26N.3、1996年7月、ページ 5-21.
[RFC1750] Eastlake, D. (ed.), "Randomness Recommendations for
Security", RFC 1750, December 1994.
[RFC1750]イーストレーク、D.編、「セキュリティのための偶発性推薦」、RFC1750、1994年12月。
[RFC1950] Deutsch P. and J. Gailly, "ZLIB Compressed Data Format
Specification version 3.3", RFC 1950, May 1996.
[RFC1950] ドイツ語P.とJ.ゲイル、「ZLIB Compressed Data Format Specification、バージョン3.3インチ、RFC1950、1996インチ年5月。
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, March 1997.
[RFC2104] Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年3月。
[RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196,
September 1997.
[RFC2196] フレーザ、B.、「サイトセキュリティハンドブック」、FYI8、RFC2196、1997年9月。
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management
Protocol", RFC 2522, March 1999.
[RFC2522] Karn、P.、およびW.シンプソン、「Photuris:」 「セッションKey Managementプロトコル」、RFC2522、1999年3月。
[SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T.,
"TCP Congestion Control with a Misbehaving Receiver", ACM
Computer Communication Review, 29(5), October 1999.
[SAVAGE99]サヴェージとS.とカードウェルとN.とWetherall、D.とアンダーソン、T.、「ふらちな事する受信機とのTCP輻輳制御」ACMコンピュータコミュニケーションレビュー、29(5)(1999年10月)。
--------- New text: (Section 18, including changes from 2.11) ---------
--------- 新しいテキスト: (2.11からの変化を含んでいるセクション18 ---------
18. Bibliography
18. 図書目録
[ALLMAN99] Allman, M. and Paxson, V., "On Estimating End-to-End
Network Path Properties", Proc. SIGCOMM'99, 1999.
[ALLMAN99]オールマン、M.、およびパクソン対「終わりから端へのネットワーク経路が土地であると見積もっている」ときのProc SIGCOMM'99、1999'。
[FALL96] Fall, K. and Floyd, S., Simulation-based Comparisons of
Tahoe, Reno, and SACK TCP, Computer Communications Review,
V. 26 N. 3, July 1996, pp. 5-21.
[FALL96] 秋とK.とフロイドとS.、タホ、リノのSimulationベースのComparisonsとSACK TCP、コンピュータCommunications Review、V.26N.3、1996年7月、ページ 5-21.
[ITU32] ITU-T Recommendation V.42, "Error-correcting
procedures for DCEs using asynchronous-to-synchronous
conversion", Section 8.1.1.6.2, October 1996.
[ITU32]ITU-T Recommendation V.42、「DCEsのための同期に非同期な変換を使用するエラー修正手順」、セクション8.1.1、.6 .2 1996年10月。
[PETERSON 1972] W. W. Peterson and E.J Weldon, Error Correcting
Codes, 2nd Edition, MIT Press, Cambridge,
Massachusetts.
[ピーターソン1972]W.W.ピーターソンとE.Jウェルダン、誤り検出方式、第2版、MITプレス、ケンブリッジ、マサチューセッツ。
[RFC1750] Eastlake, D., Ed., "Randomness Recommendations for
Security", RFC 1750, December 1994.
[RFC1750] イーストレーク、D.、エド、「セキュリティのための偶発性推薦」、RFC1750、12月1994日
Stewart, et al. Informational [Page 85] RFC 4460 SCTP Errata April 2006
スチュワート、他 [85ページ]情報のRFC4460SCTP誤字2006年4月
[RFC1858] Ziemba, G., Reed, D. and Traina P., "Security
Considerations for IP Fragment Filtering", RFC 1858,
October 1995.
[RFC1858] ZiembaとG.とリードとD.とTraina P.、「IP断片フィルタリングのためのセキュリティ問題」、RFC1858、1995年10月。
[RFC1950] Deutsch P. and J. Gailly, "ZLIB Compressed Data Format
Specification version 3.3", RFC 1950, May 1996.
[RFC1950] ドイツ語P.とJ.ゲイル、「ZLIB Compressed Data Format Specification、バージョン3.3インチ、RFC1950、1996インチ年5月。
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, March 1997.
[RFC2104] Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年3月。
[RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196,
September 1997.
[RFC2196] フレーザ、B.、「サイトセキュリティハンドブック」、FYI8、RFC2196、1997年9月。
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management
Protocol", RFC 2522, March 1999.
[RFC2522] Karn、P.、およびW.シンプソン、「Photuris:」 「セッションKey Managementプロトコル」、RFC2522、1999年3月。
[SAVAGE99] Savage, S., Cardwell, N., Wetherall, D., and Anderson, T.,
"TCP Congestion Control with a Misbehaving Receiver", ACM
Computer Communication Review, 29(5), October 1999.
[SAVAGE99]サヴェージとS.とカードウェルとN.とWetherall、D.とアンダーソン、T.、「ふらちな事する受信機とのTCP輻輳制御」ACMコンピュータコミュニケーションレビュー、29(5)(1999年10月)。
[WILLIAMS93] Williams, R., "A PAINLESS GUIDE TO CRC ERROR
DETECTION ALGORITHMS" - Internet publication, August
1993,
http://www.geocities.com/SiliconValley/Pines/
8659/crc.htm.
[WILLIAMS93] ウィリアムズ、R.、「CRC誤り検出アルゴリズムへの無痛のガイド」--インターネット公表、1993年8月、 http://www.geocities.com/SiliconValley/Pines/ 8659/crc.htm。
2.38.3. Solution Description
2.38.3. ソリューション記述
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].
この変化はRFC2960[5]に結合されるとRFC3309[6]からの変化を取り囲む完全な変化を作成者のガイドに追加します。
2.39. Retransmission Policy
2.39. Retransmission方針
2.39.1. Description of the Problem
2.39.1. 問題の記述
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
スチュワート、他 [86ページ]情報のRFC4460SCTP誤字2006年4月
2.39.2. Text Changes to the Document
2.39.2. ドキュメントへのテキスト変化
--------- Old text: (Section 6.4) ---------
--------- 古いテキスト: (セクション6.4) ---------
Furthermore, when its peer is multi-homed, an endpoint SHOULD try to retransmit a chunk to an active destination transport address that is different from the last destination address to which the DATA chunk was sent.
その上、同輩がいつか、マルチ、家へ帰り、DATA塊が送られた最後の送付先アドレスと異なったアクティブな送付先輸送アドレスに塊を再送する終点SHOULDトライ。
--------- New text: (Section 6.4) ---------
--------- 新しいテキスト: (セクション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.
その上、同輩がいつか、マルチ、家へ帰り、アクティブな送付先輸送アドレスへの外でそれを調節した塊を再送する終点SHOULDトライはDATA塊が送られた最後の送付先アドレスと異なっています。
--------- Old text: (Section 6.4.1) ---------
--------- 古いテキスト: (セクション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) ---------
--------- 新しいテキスト: (セクション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.
終点が再送するなら外で調節されたデータを再送する、マルチ、家へ帰り、それは「再-トランスミッション」選択方針でそれぞれのソース目的地アドレス組を考えるべきです。 調節された出ているデータを再送するとき、終点は、パケットが伝えられたオリジナルのソース目的地組からの最も分岐しているソース目的地組を選ぶのを試みるべきです。
2.39.3. Solution Description
2.39.3. ソリューション記述
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
スチュワート、他 [87ページ]情報のRFC4460SCTP誤字2006年4月
2.40. Port Number 0
2.40. ポートナンバー0
2.40.1. Description of the Problem
2.40.1. 問題の記述
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.
ポートNo.0で、特別番組は様々なAPIで意味的になります。 例えば、ソケットAPIでは、ユーザが0を指定するなら、SCTP実現はユーザのための適切なポートナンバーを選びます。 したがって、ワイヤの上にポートNo.0を使用するべきではありません。
2.40.2. Text Changes to the Document
2.40.2. ドキュメントへのテキスト変化
--------- Old text: (Section 3.1) ---------
--------- 古いテキスト: (セクション3.1) ---------
Source Port Number: 16 bits (unsigned integer)
ソースポートナンバー: 16ビット(符号のない整数)
This is the SCTP sender's port number. It can be used by the
receiver in combination with the source IP address, the SCTP
destination port, and possibly the destination IP address to
identify the association to which this packet belongs.
これはSCTP送付者のポートナンバーです。 それはソースIPアドレス、SCTP仕向港、およびことによると送付先IPアドレスと組み合わせて受信機によって使用されて、このパケットが属する協会を特定できます。
Destination Port Number: 16 bits (unsigned integer)
仕向港番号: 16ビット(符号のない整数)
This is the SCTP port number to which this packet is destined.
The receiving host will use this port number to de-multiplex
the SCTP packet to the correct receiving endpoint/application.
これはこのパケットが運命づけられているSCTPポートナンバーです。 受信ホストは、反-正しい受信終点/アプリケーションにSCTPパケットを多重送信するのにこのポートナンバーを使用するでしょう。
--------- New text: (Section 3.1) ---------
--------- 新しいテキスト: (セクション3.1) ---------
Source Port Number: 16 bits (unsigned integer)
ソースポートナンバー: 16ビット(符号のない整数)
This is the SCTP sender's port number. It can be used by the
receiver in combination with the source IP address, the SCTP
destination port and possibly the destination IP address to
identify the association to which this packet belongs.
The port number 0 MUST NOT be used.
これはSCTP送付者のポートナンバーです。 それはソースIPアドレス、SCTP仕向港、およびことによると送付先IPアドレスと組み合わせて受信機によって使用されて、このパケットが属する協会を特定できます。 ポートNo.0を使用してはいけません。
Destination Port Number: 16 bits (unsigned integer)
仕向港番号: 16ビット(符号のない整数)
This is the SCTP port number to which this packet is destined.
The receiving host will use this port number to de-multiplex
the SCTP packet to the correct receiving endpoint/application.
The port number 0 MUST NOT be used.
これはこのパケットが運命づけられているSCTPポートナンバーです。 受信ホストは、反-正しい受信終点/アプリケーションにSCTPパケットを多重送信するのにこのポートナンバーを使用するでしょう。 ポートNo.0を使用してはいけません。
Stewart, et al. Informational [Page 88] RFC 4460 SCTP Errata April 2006
スチュワート、他 [88ページ]情報のRFC4460SCTP誤字2006年4月
2.40.3. Solution Description
2.40.3. ソリューション記述
It is clearly stated that the port number 0 is an invalid value on the wire.
ポートNo.0がワイヤの無効の値であると明確に述べられています。
2.41. T Bit
2.41. Tビット
2.41.1. Description of the Problem
2.41.1. 問題の記述
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
2.41.2. ドキュメントへのテキスト変化
--------- Old text: (Section 3.3.7) ---------
--------- 古いテキスト: (セクション3.3.7) ---------
T bit: 1 bit
The T bit is set to 0 if the sender had a TCB that it
destroyed. If the sender did not have a TCB it should set
this bit to 1.
Tに噛み付きました: 送付者がそれが破壊したTCBを持っていたなら、1ビット、Tビットは0に設定されます。 送付者がTCBを持っていないなら、それはこのビットを1に設定するでしょうに。
--------- New text: (Section 3.3.7) ---------
--------- 新しいテキスト: (セクション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に噛み付きました: 送付者が同輩によって予想されたVerification Tagに記入したなら、1ビット、Tビットは0に設定されます。 Verification Tagが反映されるなら、Tビットを1に設定しなければなりません。 反射は、送られたVerification Tagが容認されたものと同じであることを意味します。
--------- Old text: (Section 3.3.13) ---------
--------- 古いテキスト: (セクション3.3.13) ---------
T bit: 1 bit
The T bit is set to 0 if the sender had a TCB that it
destroyed. If the sender did not have a TCB it should set
this bit to 1.
Tに噛み付きました: 送付者がそれが破壊したTCBを持っていたなら、1ビット、Tビットは0に設定されます。 送付者がTCBを持っていないなら、それはこのビットを1に設定するでしょうに。
Stewart, et al. Informational [Page 89] RFC 4460 SCTP Errata April 2006
スチュワート、他 [89ページ]情報のRFC4460SCTP誤字2006年4月
--------- New text: (Section 3.3.13) ---------
--------- 新しいテキスト: (セクション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に噛み付きました: 送付者が同輩によって予想されたVerification Tagに記入したなら、1ビット、Tビットは0に設定されます。 Verification Tagが反映されるなら、Tビットを1に設定しなければなりません。 反射は、送られたVerification Tagが容認されたものと同じであることを意味します。
--------- Old text: (Section 8.4) ---------
--------- 古いテキスト: (セクション8.4) ---------
3) If the packet contains an INIT chunk with a Verification Tag
set to '0', process it as described in Section 5.1.
Otherwise,
3) パケットがVerification TagセットがあるINIT塊を'0'に含むなら、セクション5.1で説明されるようにそれを処理してください。 そうでなければ
---------
New text: (Section 8.4)
---------
3) If the packet contains an INIT chunk with a Verification Tag
set to '0', process it as described in Section 5.1. If, for
whatever reason, the INIT cannot be processed normally and
an ABORT has to be sent in response, the Verification Tag of
the packet containing the ABORT chunk MUST be the Initiate
tag of the received INIT chunk, and the T-Bit of the ABORT
chunk has to be set to 0, indicating that the Verification
Tag is NOT reflected.
--------- 新しいテキスト: (セクション8.4) --------- 3) パケットがVerification TagセットがあるINIT塊を'0'に含むなら、セクション5.1で説明されるようにそれを処理してください。 いかなる理由でも、通常、INITを処理できないで、応答でABORTを送らなければならないなら、ABORT塊を含むパケットのVerification Tagは容認されたINIT塊のInitiateタグであるに違いありません、そして、ABORT塊のT-ビットは0に設定されなければなりません、Verification Tagが反映されないのを示して。
---------
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,
--------- 古いテキスト: (セクション8.4) --------- 5) パケットがSHUTDOWN ACK塊を含んでいるなら、受信機はSHUTDOWN COMPLETEと共にOOTBパケットの送付者に応じるはずです。 SHUTDOWN COMPLETEを送るとき、OOTBパケットの受信機は、SHUTDOWN ACKにVerification Tagを受け取っていて外国行きのパケットのVerification Tag分野に記入して、Chunk FlagsのT-ビットにTCBが全く見つけられなかったのを示すように設定しなければなりません。 そうでなければ
Stewart, et al. Informational [Page 90] RFC 4460 SCTP Errata April 2006
スチュワート、他 [90ページ]情報のRFC4460SCTP誤字2006年4月
--------- New text: (Section 8.4) ---------
--------- 新しいテキスト: (セクション8.4) ---------
5) If the packet contains a SHUTDOWN ACK chunk, the receiver
should respond to the sender of the OOTB packet with a
SHUTDOWN COMPLETE. When sending the SHUTDOWN COMPLETE, the
receiver of the OOTB packet must fill in the Verification
Tag field of the outbound packet with the Verification Tag
received in the SHUTDOWN ACK and set the T-bit in the
Chunk Flags to indicate that the Verification Tag is
reflected. Otherwise,
5) パケットがSHUTDOWN ACK塊を含んでいるなら、受信機はSHUTDOWN COMPLETEと共にOOTBパケットの送付者に応じるはずです。 SHUTDOWN COMPLETEを送るとき、OOTBパケットの受信機は、SHUTDOWN ACKにVerification Tagを受け取っていて外国行きのパケットのVerification Tag分野に記入して、Chunk FlagsのT-ビットにVerification Tagが反映されるのを示すように設定しなければなりません。 そうでなければ
--------- Old text: (Section 8.4) ---------
--------- 古いテキスト: (セクション8.4) ---------
8) The receiver should respond to the sender of the OOTB packet
with an ABORT. When sending the ABORT, the receiver of the
OOTB packet MUST fill in the Verification Tag field of the
outbound packet with the value found in the Verification
Tag field of the OOTB packet and set the T-bit in the Chunk
Flags to indicate that no TCB was found. After sending this
ABORT, the receiver of the OOTB packet shall discard the
OOTB packet and take no further action.
8) 受信機はABORTと共にOOTBパケットの送付者に応じるはずです。 ABORTを送るとき、OOTBパケットの受信機は、値がOOTBパケットのVerification Tag野原で発見されている状態で外国行きのパケットのVerification Tag分野に記入して、Chunk FlagsのT-ビットにTCBが全く見つけられなかったのを示すように設定しなければなりません。 このABORTを送った後に、OOTBパケットの受信機は、OOTBパケットを捨てて、これ以上行動を取らないものとします。
--------- New text: (Section 8.4) ---------
--------- 新しいテキスト: (セクション8.4) ---------
8) The receiver should respond to the sender of the OOTB packet
with an ABORT. When sending the ABORT, the receiver of the
OOTB packet MUST fill in the Verification Tag field of the
outbound packet with the value found in the Verification Tag
field of the OOTB packet and set the T-bit in the Chunk Flags
to indicate that the Verification Tag is reflected. After
sending this ABORT, the receiver of the OOTB packet shall
discard the OOTB packet and take no further action.
8) 受信機はABORTと共にOOTBパケットの送付者に応じるはずです。 ABORTを送るとき、OOTBパケットの受信機は、値がOOTBパケットのVerification Tag野原で発見されている状態で外国行きのパケットのVerification Tag分野に記入して、Chunk FlagsのT-ビットにVerification Tagが反映されるのを示すように設定しなければなりません。 このABORTを送った後に、OOTBパケットの受信機は、OOTBパケットを捨てて、これ以上行動を取らないものとします。
--------- Old text: (Section 8.5.1) ---------
--------- 古いテキスト: (セクション8.5.1) ---------
B) Rules for packet carrying ABORT:
B) ABORTを運ぶパケットのための規則:
Stewart, et al. Informational [Page 91] RFC 4460 SCTP Errata April 2006
スチュワート、他 [91ページ]情報のRFC4460SCTP誤字2006年4月
- 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.
- それが知られているなら、終点はいつも目的地終点のタグ値で外国行きのパケットのVerification Tag分野に記入するものとします。
- If the ABORT is sent in response to an OOTB packet, the
endpoint MUST follow the procedure described in
Section 8.4.
- OOTBパケットに対応してABORTを送るなら、終点はセクション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.
- Verification Tagがそれ自身のタグに合っているなら、受信機はパケットを受け入れなければならなくて、ORは同輩のタグです。 さもなければ、受信機は、静かにパケットを捨てて、これ以上行動を取ってはいけません。
--------- New text: (Section 8.5.1) ---------
--------- 新しいテキスト: (セクション8.5.1) ---------
B) Rules for packet carrying ABORT:
B) ABORTを運ぶパケットのための規則:
- The endpoint MUST always fill in the Verification Tag
field of the outbound packet with the destination
endpoint's tag value, if it is known.
- 終点はいつも目的地終点のタグ値で外国行きのパケットのVerification Tag分野に記入しなければなりません、それが知られているなら。
- If the ABORT is sent in response to an OOTB packet, the
endpoint MUST follow the procedure described in
Section 8.4.
- OOTBパケットに対応してABORTを送るなら、終点はセクション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 MUSTの受信機はパケットのVerification Tag分野がそれ自身のタグに合って、それが同輩のタグに設定されて、TビットがChunk Flagsに設定されるならTビットがセットORでないならパケットを受け入れます。 さもなければ、受信機は、静かにパケットを捨てて、これ以上行動を取ってはいけません。
--------- Old text: (Section 8.5.1) ---------
--------- 古いテキスト: (セクション8.5.1) ---------
C) Rules for packet carrying SHUTDOWN COMPLETE:
C) 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.
- SHUTDOWN COMPLETEを送るとき、SHUTDOWN ACKの受信機にTCBがあるなら、目的地終点のタグを使用しなければなりません。 送付者はどんなTCBも存在しないところでSHUTDOWN ACKからVerification Tagを使用するだけであるべきです。
Stewart, et al. Informational [Page 92] RFC 4460 SCTP Errata April 2006
スチュワート、他 [92ページ]情報のRFC4460SCTP誤字2006年4月
- 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.
- それ自身のパケットマッチタグORのVerification Tag分野が同輩のタグにセットして、TビットがChunk Flagsに設定されるなら、SHUTDOWN COMPLETEの受信機はパケットを受け入れるものとします。 さもなければ、受信機は、静かにパケットを捨てて、これ以上行動を取ってはいけません。 それがSHUTDOWN-ACK-SENT状態にないなら、終点はSHUTDOWN COMPLETEを無視しなければなりません。
--------- New text: (Section 8.5.1) ---------
--------- 新しいテキスト: (セクション8.5.1) ---------
C) Rules for packet carrying SHUTDOWN COMPLETE:
C) 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があるなら、目的地終点のタグを使用しなければなりません、そして、T-ビットは設定されてはいけません。 どんなTCBも送付者がSHUTDOWN ACKからVerification Tagを使用するなら存在していて、T-ビットを設定してはいけないところだけ。
- The receiver of a SHUTDOWN COMPLETE shall accept the packet
if the Verification Tag field of the packet matches its own
tag and the T bit is not set
OR
if it is set to its peer's tag and the T bit is set in the
Chunk Flags.
Otherwise, the receiver MUST silently discard the packet
and take no further action. An endpoint MUST ignore the
SHUTDOWN COMPLETE if it is not in the SHUTDOWN-ACK-SENT
state.
- SHUTDOWN COMPLETEの受信機はパケットのVerification Tag分野がそれ自身のタグに合って、それが同輩のタグに設定されて、TビットがChunk Flagsに設定されるならTビットがセットORでないならパケットを受け入れるものとします。 さもなければ、受信機は、静かにパケットを捨てて、これ以上行動を取ってはいけません。 それがSHUTDOWN-ACK-SENT状態にないなら、終点はSHUTDOWN COMPLETEを無視しなければなりません。
2.41.3. Solution Description
2.41.3. ソリューション記述
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. 未知のパラメタ取り扱い
2.42.1. Description of the Problem
2.42.1. 問題の記述
The description given in Section 2.33 does not state clearly whether an INIT-ACK or COOKIE-ECHO is sent.
INIT-ACKかCOOKIE-ECHOを送るか否かに関係なく、セクション2.33で与えられた記述ははっきり述べません。
2.42.2. Text Changes to the Document
2.42.2. ドキュメントへのテキスト変化
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
スチュワート、他 [93ページ]情報のRFC4460SCTP誤字2006年4月
--------- Old text: (Section 3.2.1) ---------
--------- 古いテキスト: (セクション3.2.1) ---------
00 - Stop processing this SCTP packet and discard it do not process
any further chunks within it.
00--このSCTPパケットを処理するのを止めて、それを捨てるのはそれの中でどんなさらなる塊も処理しません。
01 - Stop processing this SCTP packet and discard it, do not process
any further chunks within it, and report the unrecognized
parameter in an 'Unrecognized Parameter Type' (in either an
ERROR or in the INIT ACK).
01--停止がこのSCTPパケットを処理して、それを捨ててください、そして、それの中でどんなさらなる塊も処理しないでください、そして、'認識されていないParameter Type'(ERRORかINIT ACKの)の認識されていないパラメタを報告してください。
10 - Skip this parameter and continue processing.
10--このパラメタをスキップして、処理し続けています。
11 - Skip this parameter and continue processing but report the
unrecognized parameter in an 'Unrecognized Parameter Type' (in
either an ERROR or in the INIT ACK).
11--'認識されていないParameter Type'(ERRORかINIT ACKの)でこのパラメタをスキップして、処理し続けますが、認識されていないパラメタを報告します。
--------- New text: (Section 3.2.1) ---------
--------- 新しいテキスト: (セクション3.2.1) ---------
00 - Stop processing this parameter; do not process
any further parameters within this chunk.
00--このパラメタを処理するのを止めてください。 この塊の中でどんなさらなるパラメタも処理しないでください。
01 - Stop processing this parameter, do not process
any further parameters within this chunk, and report the
unrecognized parameter in an 'Unrecognized Parameter', as
described in 3.2.2.
01--停止がこのパラメタを処理して、この塊の中でどんなさらなるパラメタも処理しないでください、そして、'認識されていないParameter'の認識されていないパラメタを報告してください、中で説明されるように3.2、.2
10 - Skip this parameter and continue processing.
10--このパラメタをスキップして、処理し続けています。
11 - Skip this parameter and continue processing but report the
unrecognized parameter in an 'Unrecognized Parameter', as
described in 3.2.2.
11--中で説明されるように'認識されていないParameter'でこのパラメタをスキップして、処理し続けますが、認識されていないパラメタを報告する、3.2、.2
Please note that in all four cases an INIT-ACK or COOKIE-ECHO chunk is sent. In the 00 or 01 case the processing of the parameters after the unknown parameter is canceled, but no processing already done is rolled back.
すべての4つの場合では、INIT-ACKかCOOKIE-ECHO塊を送ります。 00か01場合では、未知のパラメタが取り消された後にパラメタの処理にもかかわらず、既に行われた処理はロールバックされません。
Stewart, et al. Informational [Page 94] RFC 4460 SCTP Errata April 2006
スチュワート、他 [94ページ]情報のRFC4460SCTP誤字2006年4月
--------- New text: (Note: no old text; clarification added in Section 3.2) ---------
--------- 新しいテキスト: (注意: 古いテキストがありません; セクション3.2で加えられた明確化) ---------
3.2.2. Reporting of Unrecognized Parameters
3.2.2. 認識されていないパラメタの報告
If the receiver of an INIT chunk detects unrecognized parameters
and has to report them according to Section 3.2.1, it MUST put
the 'Unrecognized Parameter' parameter(s) in the INIT-ACK chunk
sent in response to the INIT-chunk. Note that if the receiver
of the INIT chunk is NOT going to establish an association (e.g.,
due to lack of resources), an 'Unrecognized Parameter' would NOT
be included with any ABORT being sent to the sender of the INIT.
INIT塊の受信機が認識されていないパラメタを検出して、セクション3.2.1に従ってそれらを報告しなければならないなら、それはINIT-塊に対応して送られたINIT-ACK塊に'認識されていないParameter'パラメタを置かなければなりません。 INIT塊の受信機が協会(例えば、財源不足による)を設立しないなら、'認識されていないParameter'がどんなABORTも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.
INIT-ACK塊の受信機が認識されていないパラメタを検出して、検出しなければならないなら、セクション3.2.1に従って、それらを報告してください、それ。COOKIE-ECHO塊のINIT-ACK塊に対応した送付での'認識されていないParameters'誤り原因を含んでいて、SHOULDはERROR塊を束ねます。 INIT-ACKの受信機がERROR塊でCOOKIE-ECHO塊を束ねることができないなら、別々にERROR塊を送るかもしれませんが、以前でないときに、COOKIE-ACKを受け取ったことがあります。
Note: Any time a COOKIE-ECHO is sent in a packet, it MUST be the
first chunk.
以下に注意してください。 いつでも、パケットでCOOKIE-ECHOを送って、それは最初の塊であるに違いありません。
2.42.3. Solution Description
2.42.3. ソリューション記述
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
2.43. クッキーエコー塊
2.43.1. Description of the Problem
2.43.1. 問題の記述
The description given in Section 3.3.11 of RFC 2960 [5] is unclear as to how the COOKIE-ECHO is composed.
COOKIE-ECHOがどう落ち着いているかに関して.11セクション3.3RFC2960[5]で与えられた記述は不明瞭です。
2.43.2. Text Changes to the Document
2.43.2. ドキュメントへのテキスト変化
---------
Old text: (Section 3.3.11)
---------
Cookie: variable size
--------- 古いテキスト: (セクション3.3.11) --------- クッキー: 可変サイズ
This field must contain the exact cookie received in the State
Cookie parameter from the previous INIT ACK.
この分野は州Cookieパラメタに前のINIT ACKから受け取られた正確なクッキーを含まなければなりません。
Stewart, et al. Informational [Page 95] RFC 4460 SCTP Errata April 2006
スチュワート、他 [95ページ]情報のRFC4460SCTP誤字2006年4月
An implementation SHOULD make the cookie as small as possible
to insure interoperability.
SHOULDが相互運用性を保障するためにできるだけ小さくクッキーをする実現。
---------
New text: (Section 3.3.11)
---------
Cookie: variable size
--------- 新しいテキスト: (セクション3.3.11) --------- クッキー: 可変サイズ
This field must contain the exact cookie received in the State
Cookie parameter from the previous INIT ACK.
この分野は州Cookieパラメタに前のINIT ACKから受け取られた正確なクッキーを含まなければなりません。
An implementation SHOULD make the cookie as small as possible
to ensure interoperability.
SHOULDが相互運用性を確実にするためにできるだけ小さくクッキーをする実現。
Note: A Cookie Echo does NOT contain a State Cookie
Parameter; instead, the data within the State Cookie's
Parameter Value becomes the data within the Cookie Echo's
Chunk Value. This allows an implementation to change only
the first two bytes of the State Cookie parameter to become
a Cookie Echo Chunk.
以下に注意してください。 Cookie Echoは州Cookie Parameterを含んでいません。 代わりに、州CookieのParameter Valueの中のデータはCookie EchoのChunk Valueの中でデータになります。 これで、実現は、Cookie Echo Chunkになるように最初の2バイトの州Cookieパラメタしか変えることができません。
2.43.3. Solution Description
2.43.3. ソリューション記述
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.
2バイトだけが変更されている状態で、新しいテキストはCookie Echo塊がただ州Cookieパラメタであるというそれがはっきりさせるのを助けるメモを加えます。
2.44. Partial Chunks
2.44. 部分的な塊
2.44.1. Description of the Problem
2.44.1. 問題の記述
Section 6.10 of RFC 2960 [5] uses the notion of 'partial chunks' without defining it.
それを定義しないで、RFC2960[5]のセクション6.10は'部分的な塊'の概念を使用します。
2.44.2. Text Changes to the Document
2.44.2. ドキュメントへのテキスト変化
--------- Old text: (Section 6.10) --------- Partial chunks MUST NOT be placed in an SCTP packet.
--------- 古いテキスト: (セクション6.10) --------- 部分的な塊をSCTPパケットに置いてはいけません。
--------- 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.
--------- 新しいテキスト: (セクション6.10) --------- 部分的な塊をSCTPパケットに置いてはいけません。 部分的な塊はSCTPパケットに完全に含まれるというわけではない塊です。 すなわち、SCTPパケットは塊の長さによって示されるように塊ですべてのバイト含むことができないくらい脆いです。
Stewart, et al. Informational [Page 96] RFC 4460 SCTP Errata April 2006
スチュワート、他 [96ページ]情報のRFC4460SCTP誤字2006年4月
2.44.3. Solution Description
2.44.3. ソリューション記述
The new text adds a definition of 'partial chunks'.
新しいテキストは'部分的な塊'の定義を加えます。
2.45. Non-unicast Addresses
2.45. 非ユニキャストアドレス
2.45.1. Description of the Problem
2.45.1. 問題の記述
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.
RFC2960[5]のセクション8.4によって、OOTB取り扱いはやむを得ずすべての非ユニキャストアドレスを捨てます。 これはanycastの今後の使用を問題のアドレスに残します。 ipについて付記している特徴の添加で、SCTPは容易に、続くことができるanycast INIT sを扱うはずであることができます、後協会のセットアップ、aで削除、協会からのanycastアドレスについて。
2.45.2. Text Changes to the Document
2.45.2. ドキュメントへのテキスト変化
--------- Old text: (Section 8.4) --------- 8.4 Handle "Out of the blue" Packets
--------- 古いテキスト: (セクション8.4) --------- 8.4は「青」から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.
すなわち、受信機のアドラー-32チェックが通過されて、それが正しく形成されるなら(セクション6.8を見てください)、SCTPパケットは「青」(OOTB)パケットと呼ばれますが、受信機はこのパケットが属する協会を特定できません。
The receiver of an OOTB packet MUST do the following:
OOTBパケットの受信機は以下をしなければなりません:
1) If the OOTB packet is to or from a non-unicast address,
silently discard the packet. Otherwise,
1) OOTBパケットがアドレスか非ユニキャストアドレスからあるなら、静かにパケットを捨ててください。 そうでなければ
--------- New text: (Section 8.4) ---------
--------- 新しいテキスト: (セクション8.4) ---------
8.4. Handle "Out of the Blue" Packets
8.4. ハンドル「アウト・オブ・ブルー」パケット
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.
それが正しく形成されるなら(すなわち、受信機のCRC32cチェック; セクション6.8を見るのを通過します)、SCTPパケットは「青」(OOTB)パケットと呼ばれますが、受信機はこのパケットが属する協会を特定できません。
The receiver of an OOTB packet MUST do the following:
OOTBパケットの受信機は以下をしなければなりません:
1) If the OOTB packet is to or from a non-unicast address, a
receiver SHOULD silently discard the packet. Otherwise,
1) OOTBパケットがユニキャストか非ユニキャストからあるなら、アドレス、受信機SHOULDは静かにパケットを捨てます。 そうでなければ
Stewart, et al. Informational [Page 97] RFC 4460 SCTP Errata April 2006
スチュワート、他 [97ページ]情報のRFC4460SCTP誤字2006年4月
2.45.3. Solution Description
2.45.3. ソリューション記述
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への言葉遣いの緩みは現在、anycastアドレスの今後の使用を許すでしょう。 変更が全く放送演説への応じるの以来の.1がフラッディング攻撃に導くかもしれなくて、作成者がこれらの単語に関する慎重な注意を向けるべきであるセクション11.2.4まで行われないことに注意してください。
2.46. Processing of ABORT Chunks
2.46. アボート塊の処理
2.46.1. Description of the Problem
2.46.1. 問題の記述
Section 3.3.7 of RFC 2960 [5] requires an SCTP endpoint to silently discard ABORT chunks received for associations that do not exist. It is not clear what this means in the COOKIE-WAIT state, for example. Therefore, it was not clear whether an ABORT sent in response to an INIT should be processed or silently discarded.
.7セクション3.3RFC2960[5]が、静かに存在しない協会のために受け取られたABORT塊を捨てるためにSCTP終点を必要とします。 これがCOOKIE-WAIT状態で何を意味するかは、例えば明確ではありません。 したがって、ABORTがINITに対応して発信したかどうかが処理されるべきであるか、または静かに捨てられるべきであるのが、明確ではありませんでした。
2.46.2. Text Changes to the Document
2.46.2. ドキュメントへのテキスト変化
--------- Old text: (Section 3.3.7) ---------
--------- 古いテキスト: (セクション3.3.7) ---------
If an endpoint receives an ABORT with a format error or for an
association that doesn't exist, it MUST silently discard it.
終点が形式誤りか存在しない協会のためにABORTを受けるなら、それは静かにそれを捨てなければなりません。
--------- New text: (Section 3.3.7) ---------
--------- 新しいテキスト: (セクション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が全く見つけられないなら、それは静かにそれを捨てなければなりません。
2.46.3. Solution Description
2.46.3. ソリューション記述
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
スチュワート、他 [98ページ]情報のRFC4460SCTP誤字2006年4月
2.47. Sending of ABORT Chunks
2.47. アボート塊の発信
2.47.1. Description of the Problem
2.47.1. 問題の記述
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.
RFC2960[5]のセクション5.1は、聴取エンドポイントが全くないとき、ABORT塊がINIT塊に対応して送られるのを必要とします。 より一生懸命スキャンしながら港に入るために、だれかがINIT塊の送付者にこれらのABORTsを受け取って欲しくないかもしれません。 現在、これを実施する唯一の方法はINIT塊を含むパケットかABORT塊を含むパケットを捨てるファイアウォールを使用することです。 中央箱なしで同じくらいができるのは望ましいです。
2.47.2. Text Changes to the Document
2.47.2. ドキュメントへのテキスト変化
--------- Old text: (Section 5.1) ---------
--------- 古いテキスト: (セクション5.1) ---------
If an endpoint receives an INIT, INIT ACK, or COOKIE ECHO chunk
but decides not to establish the new association due to missing
mandatory parameters in the received INIT or INIT ACK, invalid
parameter values, or lack of local resources, it MUST respond with
an ABORT chunk.
終点が、INIT、INIT ACK、またはCOOKIE ECHO塊を受けますが、なくなった義務的なパラメタのためローカル資源の容認されたINIT、INIT ACK、無効のパラメタ値、または不足に新連合を設立しないと決めるなら、それはABORT塊で応じなければなりません。
--------- New text: (Section 5.1) ---------
--------- 新しいテキスト: (セクション5.1) ---------
If an endpoint receives an INIT, INIT ACK, or COOKIE ECHO chunk
but decides not to establish the new association due to missing
mandatory parameters in the received INIT or INIT ACK, invalid
parameter values, or lack of local resources, it SHOULD respond
with an ABORT chunk.
終点が、INIT、INIT ACK、またはCOOKIE ECHO塊を受けますが、受けないと決めるなら、なくなった義務的なパラメタのためローカル資源の容認されたINIT、INIT ACK、無効のパラメタ値、または不足に新連合を設立してください、それ。SHOULDはABORT塊で応じます。
2.47.3. Solution Description
2.47.3. ソリューション記述
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. 支持されたアドレスの取り扱いはパラメタをタイプします。
2.48.1. Description of the Problem
2.48.1. 問題の記述
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
INIT塊の送付者は、どのアドレス家族が養われるかを示すために'支持されたAddress Types'パラメタを入れることができます。 INIT塊がどのように処理されるべきであるかが、不明瞭である、パケットがINIT塊か記載を含むソースアドレスが記述するどこ
Stewart, et al. Informational [Page 99] RFC 4460 SCTP Errata April 2006
スチュワート、他 [99ページ]情報のRFC4460SCTP誤字2006年4月
within the INIT chunk indicate that more address types are supported than those listed in the 'Supported Address Types' parameter.
INIT塊の中では、より多くのアドレスタイプが'支持されたAddress Types'パラメタに記載されたものより支持されるのを示してください。
2.48.2. Text Changes to the Document
2.48.2. ドキュメントへのテキスト変化
The changes given here already include changes suggested in Section 2.28 of this document.
ここに与えられた変化は既にこのドキュメントのセクション2.28に示された変化を含みます。
--------- Old text: (Section 5.1.2) ---------
--------- 古いテキスト: (セクション5.1.2) ---------
IMPLEMENTATION NOTE: In the case that the receiver of an INIT ACK
fails to resolve the address parameter due to an unsupported type,
it can abort the initiation process and then attempt a
re-initiation by using a 'Supported Address Types' parameter in
the new INIT to indicate what types of address it prefers.
実現注意: INIT ACKの受信機がサポートされないタイプのためアドレスパラメタを決議しないで、それは、それがどんなタイプのアドレスを好むかを示すのに新しいINITの'支持されたAddress Types'パラメタを使用することによって、開始過程を中止して、次に、再開始を試みることができます。
--------- New text: (Section 5.1.2) ---------
--------- 新しいテキスト: (セクション5.1.2) ---------
IMPLEMENTATION NOTE: In the case that the receiver of an INIT ACK
fails to resolve the address parameter due to an unsupported type,
it can abort the initiation process and then attempt a re-
initiation by using a 'Supported Address Types' parameter in the
new INIT to indicate what types of address it prefers.
実現注意: INIT ACKの受信機がサポートされないタイプのためアドレスパラメタを決議しないで、それは、それがどんなタイプのアドレスを好むかを示すのに新しいINITの'支持されたAddress Types'パラメタを使用することによって、開始過程を中止して、次に、再開始を試みることができます。
IMPLEMENTATION NOTE: If an SCTP endpoint that only supports either
IPv4 or IPv6 receives IPv4 and IPv6 addresses in an INIT or INIT-
ACK chunk from its peer, it MUST use all the addresses belonging
to the supported address family. The other addresses MAY be
ignored. The endpoint SHOULD NOT respond with any kind of error
indication.
実現注意: IPv4かIPv6のどちらかを支持するだけであるSCTP終点が同輩からINITかINIT- ACK塊におけるIPv4とIPv6アドレスを受け取るなら、それは支持されたアドレス家族のものであるすべてのアドレスを使用しなければなりません。 他のアドレスは無視されるかもしれません。 終点SHOULD NOTはどんな種類の誤り表示でも応じます。
IMPLEMENTATION NOTE: If an SCTP endpoint lists in the 'Supported
Address Types' parameter either IPv4 or IPv6, but uses the other
family for sending the packet containing the INIT chunk, or if it
also lists addresses of the other family in the INIT chunk, then
the address family that is not listed in the 'Supported Address
Types' parameter SHOULD also be considered as supported by the
receiver of the INIT chunk. The receiver of the INIT chunk SHOULD
NOT respond with any kind of error indication.
実現注意: SCTP終点が'支持されたAddress Types'パラメタのIPv4かIPv6のどちらかに記載しますが、INIT塊を含むパケットを送るのにもう片方の家族を使用するか、またはまた、INIT塊でもう片方の家族のアドレスを記載するなら、また、INIT塊の受信機によって支持されるように考えられて、アドレス家族は'支持されたAddress Types'パラメタSHOULDに記載しませんでした。 SHOULD NOTがどんな種類の誤り表示でも反応させるINIT塊の受信機。
2.48.3. Solution Description
2.48.3. ソリューション記述
It is now clearly described how these Supported Address Types parameters with incorrect data should be handled.
間違ったデータがあるこれらのSupported Address Typesパラメタがどのように扱われるべきであるかは現在、明確に説明されます。
Stewart, et al. Informational [Page 100] RFC 4460 SCTP Errata April 2006
スチュワート、他 [100ページ]情報のRFC4460SCTP誤字2006年4月
2.49. Handling of Unexpected Parameters
2.49. 予期していなかったパラメタの取り扱い
2.49.1. Description of the Problem
2.49.1. 問題の記述
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.
RFC2960[5]は明確にINITとINIT-ACK塊における未知のパラメタがどう処理されるべきであるかを説明します。 しかし、予期していなかったパラメタがどのように処理されるべきであるかは説明されません。 パラメタをそれが知られていて、任意のパラメタであるならINITかINIT-ACK塊において予期していないのですが、それが任意のパラメタでない塊で受け取ります。 例えば、INIT- ACK塊に含まれているなら、'支持されたAddress Types'パラメタは予期していなかったパラメタでしょう。
2.49.2. Text Changes to the Document
2.49.2. ドキュメントへのテキスト変化
--------- Old text: (Section 3.3.2) ---------
--------- 古いテキスト: (セクション3.3.2) ---------
Note 4: This parameter, when present, specifies all the address
types the sending endpoint can support. The absence of this
parameter indicates that the sending endpoint can support any
address type.
注意4: 存在しているとき、このパラメタは送付終点が支持できるすべてのアドレスタイプを指定します。 このパラメタの欠如は、送付終点がどんなアドレスタイプも支持できるのを示します。
--------- New text: (Section 3.3.2) ---------
--------- 新しいテキスト: (セクション3.3.2) ---------
Note 4: This parameter, when present, specifies all the address
types the sending endpoint can support. The absence of this
parameter indicates that the sending endpoint can support any
address type.
注意4: 存在しているとき、このパラメタは送付終点が支持できるすべてのアドレスタイプを指定します。 このパラメタの欠如は、送付終点がどんなアドレスタイプも支持できるのを示します。
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塊を受け取るなら、受信機SHOULDはINIT塊を処理して、INIT-ACKを返送します。 INIT塊の受信機は後でCOOKIE-ACK塊でERROR塊を束ねるかもしれません。 しかしながら、制限している実現はINIT塊に対応してABORT塊を返送するかもしれません。
Stewart, et al. Informational [Page 101] RFC 4460 SCTP Errata April 2006
スチュワート、他 [101ページ]情報のRFC4460SCTP誤字2006年4月
--------- Old text: (Section 3.3.3) ---------
--------- 古いテキスト: (セクション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.
実現注意: 州のクッキーの可変サイズと可変住所録のためかなり大きいINIT ACK(1500バイト以上)を受け取るように実現を準備しなければなりません。 例えば、INITへの応答者にそれが送りたがっている1000のIPv4アドレスがあるなら、それは、INIT ACKでこれをコード化するために少なくとも8,000バイトを必要とするでしょう。
--------- New text: (Section 3.3.3) ---------
--------- 新しいテキスト: (セクション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.
実現注意: 州のクッキーの可変サイズと可変住所録のためかなり大きいINIT ACK(1500バイト以上)を受け取るように実現を準備しなければなりません。 例えば、INITへの応答者にそれが送りたがっている1000のIPv4アドレスがあるなら、それは、INIT ACKでこれをコード化するために少なくとも8,000バイトを必要とするでしょう。
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塊を受け取るなら、受信機SHOULDはINIT-ACK塊を処理して、COOKIE-ECHOを返送します。 INIT-ACK塊の受信機はCOOKIE-ECHO塊でERROR塊を束ねるかもしれません。 しかしながら、制限している実現はINIT-ACK塊に対応してABORT塊を返送するかもしれません。
2.49.3. Solution Description
2.49.3. ソリューション記述
It is now stated how unexpected parameters should be processed.
予期していなかったパラメタがどのように処理されるべきであるかは現在、述べられます。
2.50. Payload Protocol Identifier
2.50. 有効搭載量プロトコル識別子
2.50.1. Description of the Problem
2.50.1. 問題の記述
The current description of the payload protocol identifier does NOT highlight the fact that the field is NOT necessarily in network byte order.
ペイロードプロトコル識別子の現在の記述は分野が必ずネットワークバイトオーダーでそうであるというわけではないという事実を目立たせません。
Stewart, et al. Informational [Page 102] RFC 4460 SCTP Errata April 2006
スチュワート、他 [102ページ]情報のRFC4460SCTP誤字2006年4月
2.50.2. Text Changes to the Document
2.50.2. ドキュメントへのテキスト変化
---------
Old text: (Section 3.3.1)
---------
Payload Protocol Identifier: 32 bits (unsigned integer)
--------- 古いテキスト: (セクション3.3.1) --------- 有効搭載量プロトコル識別子: 32ビット(符号のない整数)
This value represents an application (or upper layer) specified
protocol identifier. This value is passed to SCTP by its upper
layer and sent to its peer. This identifier is not used by
SCTP but can be used by certain network entities as well as
the peer application to identify the type of information being
carried in this DATA chunk. This field must be sent even in
fragmented DATA chunks (to make sure it is available for agents
in the middle of the network).
この値はアプリケーション(または、上側の層)の指定されたプロトコル識別子を表します。 この値を上側の層のそばでSCTPに通過して、同輩に送ります。 この識別子はSCTPによって使用されませんが、同輩アプリケーションと同様にあるネットワーク実体によって使用されて、このDATA塊で運ばれる情報の種類は特定できます。 断片化しているDATA塊でさえこの野原を送らなければなりません(ネットワークの中央のエージェントについて、念のためそれがあります)。
The value 0 indicates no application identifier is specified by
the upper layer for this payload data.
値0は、アプリケーション識別子が全く上側の層によってこのペイロードデータに指定されないのを示します。
---------
New text: (Section 3.3.1)
---------
Payload Protocol Identifier: 32 bits (unsigned integer)
--------- 新しいテキスト: (セクション3.3.1) --------- 有効搭載量プロトコル識別子: 32ビット(符号のない整数)
This value represents an application (or upper layer) specified
protocol identifier. This value is passed to SCTP by its upper
layer and sent to its peer. This identifier is not used by
SCTP but can be used by certain network entities, as well as by
the peer application, to identify the type of information being
carried in this DATA chunk. This field must be sent even in
fragmented DATA chunks (to make sure it is available for agents
in the middle of the network). Note that this field is NOT
touched by an SCTP implementation, therefore its byte order is
NOT necessarily Big Endian. The upper layer is responsible
for any byte order conversions to this field.
この値はアプリケーション(または、上側の層)の指定されたプロトコル識別子を表します。 この値を上側の層のそばでSCTPに通過して、同輩に送ります。 この識別子をSCTPによって使用されませんが、このDATA塊で運ばれる情報の種類を特定するのに、あるネットワーク実体、および同輩アプリケーションで使用できます。 断片化しているDATA塊でさえこの野原を送らなければなりません(ネットワークの中央のエージェントについて、念のためそれがあります)。 SCTP実現でこの分野が触れられないことに注意してください、そして、したがって、バイトオーダーは必ずBig Endianであるというわけではありません。 上側の層はこの分野へのどんなバイトオーダー変換にも原因となります。
The value 0 indicates that no application identifier is
specified by the upper layer for this payload data.
値0は、アプリケーション識別子が全く上側の層によってこのペイロードデータに指定されないのを示します。
2.50.3. Solution Description
2.50.3. ソリューション記述
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
スチュワート、他 [103ページ]情報のRFC4460SCTP誤字2006年4月
2.51. Karn's Algorithm
2.51. Karnのアルゴリズム
2.51.1. Description of the Problem
2.51.1. 問題の記述
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.
Karnのアルゴリズムの使用の現在の言葉遣いがそれを確実にすることができるくらいには描写的でない、aでの実現、マルチ、家へ帰り、協会は不当でなくmismeasureにRTTをします。
2.51.2. Text Changes to the Document
2.51.2. ドキュメントへのテキスト変化
--------- Old text: (Section 6.3.1) ---------
--------- 古いテキスト: (セクション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のアルゴリズム: 再送されたパケットを使用して、RTT測定をしてはいけない、(このようにして、回答がパケットの最初の例か後の例のためのものであったかがあいまいである、) --------- 新しいテキスト: (セクション6.3.1) ---------
C5) Karn's algorithm: RTT measurements MUST NOT be made using
chunks that were retransmitted (and thus for which it is
ambiguous whether the reply was for the first instance of
the chunk or for a later instance)
C5) Karnのアルゴリズム: 再送された塊を使用して、RTT測定をしてはいけません。(その結果、それがどれであるかに回答が塊の最初の例のためのものであったかa後の例のためにあいまい)
IMPLEMENTATION NOTE: RTT measurements should only be
made using a chunk with TSN r if no chunk
with TSN less than or equal to r is retransmitted
since r is first sent.
実現注意: RTT測定値はTSNがある塊でないならTSN rがある塊を使用することで作られて、よりrが最初にrを送るので再送されるということであるにすぎないべきです。
2.51.3. Solution Description
2.51.3. ソリューション記述
The above clarification adds an implementation note that will provide additional guidance in the application of Karn's algorithm.
上の明確化はKarnのアルゴリズムの適用における追加指導を提供する実現注意を加えます。
2.52. Fast Retransmit Algorithm
2.52. 速くアルゴリズムを再送してください。
2.52.1. Description of the Problem
2.52.1. 問題の記述
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
スチュワート、他 [104ページ]情報のRFC4460SCTP誤字2006年4月
2.52.2. Text Changes to the Document
2.52.2. ドキュメントへのテキスト変化
--------- Old text: ---------
--------- 古いテキスト: ---------
7.2.4 Fast Retransmit on Gap Reports
7.2.4 ギャップレポートで速く再送してください。
In the absence of data loss, an endpoint performs delayed
acknowledgement. However, whenever an endpoint notices a hole in
the arriving TSN sequence, it SHOULD start sending a SACK back
every time a packet arrives carrying data until the
hole is filled.
データの損失が不在のとき、終点は遅れた承認を実行します。 しかしながら、終点が到着しているTSN系列の穴に気付いて、それがSHOULDであるときはいつも、パケットが穴がいっぱいにされるまでデータを運びながら到着するときはいつも、SACKを返送し始めてください。
Whenever an endpoint receives a SACK that indicates some TSN(s)
missing, it SHOULD wait for 3 further miss indications (via
subsequent SACK's) on the same TSN(s) before taking action with
regard to Fast Retransmit.
終点がいくつかのTSN(s)の取り逃がすことを示すSACKを受けて、それがSHOULDであるときはいつも、Fast Retransmitに関して行動を取る前に、同じTSN(s)におけるさらなる3つのミス指摘(その後のSACKのものを通した)を待ってください。
--------- New text: ---------
--------- 新しいテキスト: ---------
7.2.4. Fast Retransmit on Gap Reports
7.2.4. ギャップレポートで速く再送してください。
In the absence of data loss, an endpoint performs delayed
acknowledgement. However, whenever an endpoint notices a hole in
the arriving TSN sequence, it SHOULD start sending a SACK back
every time a packet arrives carrying data until the
hole is filled.
データの損失が不在のとき、終点は遅れた承認を実行します。 しかしながら、終点が到着しているTSN系列の穴に気付いて、それがSHOULDであるときはいつも、パケットが穴がいっぱいにされるまでデータを運びながら到着するときはいつも、SACKを返送し始めてください。
Whenever an endpoint receives a SACK that indicates that some
TSNs are missing, it SHOULD wait for 2 further miss indications
(via subsequent SACKs for a total of 3 missing reports) on the
same TSNs before taking action with regard to Fast Retransmit.
終点がいくつかのTSNsがなくなって、それがSHOULDであることを示すSACKを受けるときはいつも、Fast Retransmitに関して行動を取る前に、同じTSNsにおけるさらなる2つのミス指摘(合計3つの捜索願のためのその後のSACKsを通した)を待ってください。
2.52.3. Solution Description
2.52.3. ソリューション記述
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.
上の変化で、捜索願を受け取るときそれらがFast Retransmissionアルゴリズムをどれくらい速く従事させるかに関してSCTPとTCPは同様に振る舞うでしょう。
3. Security Considerations
3. セキュリティ問題
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に加えるはずがありません、そして、事実上、いったん法人組織になると、SHOULDは正本の中のいくつかの元のセキュリティー・フローをRFC2960[5]BISドキュメントに修正します。
Stewart, et al. Informational [Page 105] RFC 4460 SCTP Errata April 2006
スチュワート、他 [105ページ]情報のRFC4460SCTP誤字2006年4月
4. Acknowledgements
4. 承認
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.
バリー・ザッカーマン、LaモンテYarroll、Qiaobingシェ、ワングのシャオパン、ジョナサンWood、ジェフWaskow、マイク・ターナー、ジョン・タウンゼンド、サビナ・トレンテ、クリフ・トーマス、Yuji鈴木、Manoj Solanki、Sverre Slotte、Keyurシャー、ジャンRovins、ベン・ロビンソン、ルネRevis、イアンPeriam、RCモニーSanjayラオ、Sujithラーダークリシュナン、ハインツPrantner、Birenパテル、ナタリーMouellic、ミッチMiers、Bernward Meyknecht、スタン・マクレラン、オリバー市長、トマス・Ortiマーチン、Sandeep高利貸し、デヴィッド・レーマン; ジョナサン・リー、フィリップ・ラングロイ、カールKnutson、ジョー・ケラー、ギャレスKeily、アンドレアスJungmaier、Janardhanアイアンガー、Mutsuyaイリエ、ジョン・エベール、Kausarハッサン、フレッドHasle、ダン・ハリソン、ジョンGrimです、ローランGlaude、スティーブン・ファーニス、篤Fukumoto、ケンフジタ、スティーブDimig、トーマス・カラン、Serkan Cil(メリッサ・キャンベル、ピーター・バトラー)はブレナン、厳しいBhondwe、ブライアンBidulock、ケイトリンBestler、ジョン・バーガー、ロビーBenedyk、スティーブンBaucke、Sandeep Balani、およびロニーセラーから略奪します。
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.
特別番組は、マーク・オールマンをありがとうございますが、専門的表現による外で何とか揺れました。(実際に、オールマンは、最大炸裂に対する彼の仕事のための共著者であるべきです)。 また、彼らの貴重な入力と多くの貢献のためにリンドン・オングとフィル・コンラッドを承認したいと思います。
5. IANA Considerations
5. 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.
このドキュメントはRFC2960[5]BISドキュメントのために変化を推薦します。 そういうものとして、新しい誤り原因コードを記載しますが、このドキュメントは本来それらの新法を定義しません。 代わりに、BISドキュメントはRFC2960への必要な変更を[5]にするでしょう、そして、その結果、IANA部は、作られているために釣り銭がいるでしょう。
6. Normative References
6. 引用規格
[1] Braden, R., "Requirements for Internet Hosts - Communication
Layers", STD 3, RFC 1122, October 1989.
[1] ブレーデン、R.、「インターネットのためのホスト--コミュニケーションが層にされるという要件」、STD3、RFC1122、10月1989日
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[3] Caro, A., Shah, K., Iyengar, J., Amer, P., and R. Stewart, "SCTP
and TCP Variants: Congestion Control Under Multiple Losses",
Technical Report TR2003-04, Computer and Information Sciences
Department, University of Delaware, February 2003,
<http://www.armandocaro.net/papers>.
[3] ケアロ、A.、シャー、K.、アイアンガー、J.、アメア、P.、およびR.スチュワート、「SCTPとTCP異形:」 技術報告書の「複数の損失での輻輳制御」とTR2003-04とコンピュータと情報科学部、デラウエア大学、2003年2月、<http://www.armandocaro.net/書類>。
Stewart, et al. Informational [Page 106] RFC 4460 SCTP Errata April 2006
スチュワート、他 [106ページ]情報のRFC4460SCTP誤字2006年4月
[4] Caro, A., Amer, P., and R. Stewart, "Retransmission Schemes for
End-to-end Failover with Transport Layer Multihoming", GLOBECOM,
November 2004., <http://www.armandocaro.net/papers>.
[4] ケアロ、A.、アメア、P.、およびR.スチュワート、「Retransmissionはトランスポート層マルチホーミングで終わりから終わりへのフェイルオーバーを計画します」、GLOBECOM、11月の2004.、<http://www.armandocaro.net/書類>。
[5] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V.
Paxson, "Stream Control Transmission Protocol", RFC 2960,
October 2000.
[5] スチュワート、R.、シェ、Q.、K.の、そして、鋭いMorneault、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カッラ、M.、チャン、L.、および「流れの制御伝動プロトコル」、RFC2960(2000年10月)対パクソン
[6] Stone, J., Stewart, R., and D. Otis, "Stream Control
Transmission Protocol (SCTP) Checksum Change", RFC 3309,
September 2002.
[6] ストーン、J.、スチュワート、R.、およびD.オーティス、「流れの制御伝動プロトコル(SCTP)チェックサム変化」、RFC3309、2002年9月。
Stewart, et al. Informational [Page 107] RFC 4460 SCTP Errata April 2006
スチュワート、他 [107ページ]情報のRFC4460SCTP誤字2006年4月
Authors' Addresses
作者のアドレス
Randall R. Stewart Cisco Systems, Inc. 4875 Forest Drive Suite 200 Columbia, SC 29206 USA
ランドルR.スチュワートシスコシステムズInc.4875森林ドライブSuite200SC29206コロンビア(米国)
EMail: rrs@cisco.com
メール: rrs@cisco.com
Ivan Arias-Rodriguez Nokia Research Center PO Box 407 FIN-00045 Nokia Group Finland
イワンAriasロドリゲスノキアリサーチセンター私書箱407フィン-00045Nokia Groupフィンランド
EMail: ivan.arias-rodriguez@nokia.com
メール: ivan.arias-rodriguez@nokia.com
Kacheong Poon Sun Microsystems, Inc. 3571 N. First St. San Jose, CA 95134 USA
最初に、Kacheongヤラボサン・マイクロシステムズ・インク3571N.聖カリフォルニア95134サンノゼ(米国)
EMail: kacheong.poon@sun.com
メール: kacheong.poon@sun.com
Armando L. Caro Jr. BBN Technologies 10 Moulton St. Cambridge, MA 02138
ケンブリッジ、アルマンドL.ケアロJr.BBN技術10モールトン通りMA 02138
EMail: acaro@bbn.com URI: http://www.armandocaro.net
メール: acaro@bbn.com ユリ: http://www.armandocaro.net
Michael Tuexen Muenster Univ. of Applied Sciences Stegerwaldstr. 39 48565 Steinfurt Germany
応用科学StegerwaldstrのマイケルTuexen Muenster大学。 39 48565Steinfurtドイツ
EMail: tuexen@fh-muenster.de
メール: tuexen@fh-muenster.de
Stewart, et al. Informational [Page 108] RFC 4460 SCTP Errata April 2006
スチュワート、他 [108ページ]情報のRFC4460SCTP誤字2006年4月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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はこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Stewart, et al. Informational [Page 109]
スチュワート、他 情報[109ページ]
一覧
スポンサーリンク
