RFC5061 日本語訳
5061 Stream Control Transmission Protocol (SCTP) Dynamic AddressReconfiguration. R. Stewart, Q. Xie, M. Tuexen, S. Maruyama, M.Kozuka. September 2007. (Format: TXT=91851 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Stewart
Request for Comments: 5061 Cisco Systems, Inc.
Category: Standards Track Q. Xie
Motorola, Inc.
M. Tuexen
Univ. of Applied Sciences Muenster
S. Maruyama
M. Kozuka
Kyoto University
September 2007
コメントを求めるワーキンググループR.スチュワートの要求をネットワークでつないでください: 5061年のシスコシステムズInc.カテゴリ: 規格はS.丸山M.小塚京都大学2007年9月に応用科学MuensterのQ.シェモトローラM.Tuexen大学を追跡します。
Stream Control Transmission Protocol (SCTP)
Dynamic Address Reconfiguration
制御伝動のプロトコルの(SCTP)ダイナミックなアドレス再構成を流してください。
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
A local host may have multiple points of attachment to the Internet, giving it a degree of fault tolerance from hardware failures. Stream Control Transmission Protocol (SCTP) (RFC 4960) was developed to take full advantage of such a multi-homed host to provide a fast failover and association survivability in the face of such hardware failures. This document describes an extension to SCTP that will allow an SCTP stack to dynamically add an IP address to an SCTP association, dynamically delete an IP address from an SCTP association, and to request to set the primary address the peer will use when sending to an endpoint.
ローカル・ホストは複数のポイントの付属をインターネットに持っているかもしれません、1段階の耐障害性をハードウェアの故障からそれに与えて。 流れのControl Transmissionプロトコル(SCTP)(RFC4960)がそのようなaを最大限に利用するために開発された、マルチ、家へ帰り、そのようなハードウェアの故障に直面して速いフェイルオーバーと協会の生存性を提供するために、接待します。 このドキュメントはSCTPスタックにIPアドレスをSCTP協会にダイナミックに追加させるSCTPに拡大について説明して、ダイナミックにSCTP協会と、終点に発信するとき同輩が使用する第一のアドレスを設定するという要求にIPアドレスを削除してください。
Stewart, et al. Standards Track [Page 1] RFC 5061 SCTP Dynamic Address Reconfiguration September 2007
スチュワート、他 規格はダイナミックなSCTPアドレス再構成2007年9月にRFC5061を追跡します[1ページ]。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Serial Number Arithmetic . . . . . . . . . . . . . . . . . . . 4
4. Additional Chunks and Parameters . . . . . . . . . . . . . . . 4
4.1. New Chunk Types . . . . . . . . . . . . . . . . . . . . . 4
4.1.1. Address Configuration Change Chunk (ASCONF) . . . . . 5
4.1.2. Address Configuration Acknowledgment Chunk
(ASCONF-ACK) . . . . . . . . . . . . . . . . . . . . . 6
4.2. New Parameter Types . . . . . . . . . . . . . . . . . . . 7
4.2.1. Add IP Address . . . . . . . . . . . . . . . . . . . . 8
4.2.2. Delete IP Address . . . . . . . . . . . . . . . . . . 9
4.2.3. Error Cause Indication . . . . . . . . . . . . . . . . 10
4.2.4. Set Primary IP Address . . . . . . . . . . . . . . . . 11
4.2.5. Success Indication . . . . . . . . . . . . . . . . . . 12
4.2.6. Adaptation Layer Indication . . . . . . . . . . . . . 13
4.2.7. Supported Extensions Parameter . . . . . . . . . . . . 13
4.3. New Error Causes . . . . . . . . . . . . . . . . . . . . . 14
4.3.1. Error Cause: Request to Delete Last Remaining IP
Address . . . . . . . . . . . . . . . . . . . . . . . 15
4.3.2. Error Cause: Operation Refused Due to Resource
Shortage . . . . . . . . . . . . . . . . . . . . . . . 15
4.3.3. Error Cause: Request to Delete Source IP Address . . . 16
4.3.4. Error Cause: Association Aborted Due to Illegal
ASCONF-ACK . . . . . . . . . . . . . . . . . . . . . . 17
4.3.5. Error Cause: Request Refused - No Authorization. . . . 17
5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1. ASCONF Chunk Procedures . . . . . . . . . . . . . . . . . 18
5.1.1. Congestion Control of ASCONF Chunks . . . . . . . . . 20
5.2. Upon Reception of an ASCONF Chunk . . . . . . . . . . . . 21
5.3. General Rules for Address Manipulation . . . . . . . . . . 24
5.3.1. A Special Case for OOTB ABORT Chunks . . . . . . . . . 29
5.3.2. A Special Case for Changing an Address . . . . . . . . 29
5.4. Setting of the Primary Address . . . . . . . . . . . . . . 29
5.5. Bundling of Multiple ASCONFs . . . . . . . . . . . . . . . 30
6. Security Considerations . . . . . . . . . . . . . . . . . . . 30
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
9.1. Normative References . . . . . . . . . . . . . . . . . . . 35
9.2. Informative References . . . . . . . . . . . . . . . . . . 35
Appendix A. Abstract Address Handling . . . . . . . . . . . . . . 36
A.1. General Remarks . . . . . . . . . . . . . . . . . . . . . 36
A.2. Generalized Endpoints . . . . . . . . . . . . . . . . . . 36
A.3. Associations . . . . . . . . . . . . . . . . . . . . . . . 37
A.4. Relationship with RFC 4960 . . . . . . . . . . . . . . . . 38
A.5. Rules for Address Manipulation . . . . . . . . . . . . . . 38
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 コンベンション. . . . . . . . . . . . . . . . . . . . . . . . . 3 3。 通し番号演算. . . . . . . . . . . . . . . . . . . 4 4。 追加塊とパラメタ. . . . . . . . . . . . . . . 4 4.1。 新しい塊は.1に.44.1をタイプします。 構成変更塊(ASCONF). . . . . 5 4.1.2を記述してください。 構成承認塊(ASCONF-ACK). . . . . . . . . . . . . . . . . . . . . 6 4.2を記述してください。 新しいパラメータの型. . . . . . . . . . . . . . . . . . . 7 4.2.1。 IPアドレス. . . . . . . . . . . . . . . . . . . . 8 4.2.2を加えてください。 IPアドレス. . . . . . . . . . . . . . . . . . 9 4.2.3を削除してください。 誤り原因指示. . . . . . . . . . . . . . . . 10 4.2.4。 第一のIPアドレス. . . . . . . . . . . . . . . . 11 4.2.5を設定してください。 成功指示. . . . . . . . . . . . . . . . . . 12 4.2.6。 適合層の指示. . . . . . . . . . . . . 13 4.2.7。 .134.3に拡大パラメタを支持しました。 新しい誤りは.1に.144.3を引き起こします。 誤り原因: 最後に残っているIPアドレス. . . . . . . . . . . . . . . . . . . . . . . 15 4.3.2を削除するよう要求します。 誤り原因: 操作はリソース不足. . . . . . . . . . . . . . . . . . . . . . . 15 4.3.3のため拒否しました。 誤り原因: ソースIPアドレス. . . 16 4.3.4を削除するよう要求します。 誤り原因: 協会は不法なASCONF-ACK. . . . . . . . . . . . . . . . . . . . . . 17 4.3.5のため中止になりました。 誤り原因: 要求は拒否しました--認可がありません。 . . . 17 5. 手順. . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.1。 ASCONF塊手順. . . . . . . . . . . . . . . . . 18 5.1.1。 ASCONF塊. . . . . . . . . 20 5.2の輻輳制御。 ASCONF塊. . . . . . . . . . . . 21 5.3のレセプションで。 一般はアドレス操作. . . . . . . . . . 24 5.3.1のために判決を下します。 OOTBアボート塊. . . . . . . . . 29 5.3.2のための特別なケース。 アドレス. . . . . . . . 29 5.4を変えるための特別なケース。 第一のアドレス. . . . . . . . . . . . . . 29 5.5の設定。 複数のASCONFs.306のバンドリング。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 30 7。 IANA問題. . . . . . . . . . . . . . . . . . . . . 33 8。 承認. . . . . . . . . . . . . . . . . . . . . . . 34 9。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 35 9.1。 引用規格. . . . . . . . . . . . . . . . . . . 35 9.2。 有益な参照. . . . . . . . . . . . . . . . . . 35の付録のA.の抽象的なアドレス取り扱. . . . . . . . . . . . . . 36いA.1。 概評. . . . . . . . . . . . . . . . . . . . . 36A.2。 終点. . . . . . . . . . . . . . . . . . 36A.3を一般化しました。 協会. . . . . . . . . . . . . . . . . . . . . . . 37A.4。 RFC4960.38A.5との関係。 アドレス操作. . . . . . . . . . . . . . 38のための規則
Stewart, et al. Standards Track [Page 2] RFC 5061 SCTP Dynamic Address Reconfiguration September 2007
スチュワート、他 規格はダイナミックなSCTPアドレス再構成2007年9月にRFC5061を追跡します[2ページ]。
1. Introduction
1. 序論
A local host may have multiple points of attachment to the Internet, giving it a degree of fault tolerance from hardware failures. SCTP was developed to take full advantage of such a multi-homed host to provide a fast failover and association survivability in the face of such hardware failures. However, many modern computers allow for the dynamic addition and deletion of network cards (sometimes termed a hot-pluggable interface). Complicate this with the ability of a provider, in IPv6, to dynamically renumber a network, and there still is a gap between full-fault tolerance and the currently defined SCTP protocol. No matter if a card is added or an interface is renumbered, in order to take advantage of this new configuration, the transport association must be restarted. For many fault-tolerant applications this restart is considered an outage and is undesirable.
ローカル・ホストは複数のポイントの付属をインターネットに持っているかもしれません、1段階の耐障害性をハードウェアの故障からそれに与えて。 SCTPがそのようなaを最大限に利用するために開発された、マルチ、家へ帰り、そのようなハードウェアの故障に直面して速いフェイルオーバーと協会の生存性を提供するために、接待します。 しかしながら、多くの現代のコンピュータがネットワークカード(時々熱いpluggableインタフェースと呼ばれる)のダイナミックな添加と削除を考慮します。 ネットワークにダイナミックに番号を付け替えさせるプロバイダーの能力がIPv6にある状態で、これを複雑にしてください。そうすれば、完全な耐障害性と現在定義されたSCTPプロトコルの間には、ギャップがまだあります。 カードが加えられるか、またはインタフェースがこの新しい構成を利用するために番号を付け替えられるなら、輸送協会を再開しなければならないのは、問題ではありません。 多くのフォールトトレラントアプリケーションにおいて、この再開は、供給停止であると考えられて、望ましくありません。
This document describes an extension to SCTP to attempt to correct this problem for the more demanding fault-tolerant application. This extension will allow an SCTP stack to:
このドキュメントは、より過酷なフォールトトレラントアプリケーションのためにこの問題を修正するのを試みるために拡大についてSCTPに説明します。 この拡大は、以下のことをSCTPスタックは許容するでしょう。
o Dynamically add an IP address to an association.
o ダイナミックにIPアドレスを協会に追加してください。
o Dynamically delete an IP address from an association.
o 協会からIPアドレスをダイナミックに削除してください。
o Request to set the primary address the peer will use when sending
to an endpoint.
o 終点に発信するとき同輩が使用する第一のアドレスを設定するよう要求します。
The dynamic addition and subtraction of IP addresses allows an SCTP association to continue to function through host and network reconfigurations. These changes, brought on by provider or user action, may mean that the peer would be better served by using the newly added address; however, this information may only be known by the endpoint that had the reconfiguration occur. In such a case this extension allows the local endpoint to advise the peer as to what it thinks is the better primary address that the peer should be using.
IPアドレスのダイナミックな足し算と引き算はホストとネットワーク再構成を通して機能し続けるSCTP協会を許容します。 プロバイダーかユーザ動作で起こされたこれらの変化は、新たに加えられたアドレスを使用することによって同輩が役立たれるほうがよいことを意味するかもしれません。 しかしながら、この情報は再構成が起こった終点によって知られているだけであるかもしれません。 このような場合にはこの拡大で、地方の終点はそれが同輩が使用するべきであるより良い第一のアドレスであると考えることに関して同輩にアドバイスできます。
One last thing this extension adds is a small, 32-bit integer called an adaptation indication that can be exchanged at startup. This is useful for applications where there are one or more specific layers below the application, yet still above SCTP. In such a case, the exchange of this indication can allow the proper layer to be enabled below the application.
この拡大が加える最後の1つのことが始動で交換できる適合指示と呼ばれる小さくて、32ビットの整数です。 これはまだまだSCTPの上に1つ以上の特定の層がアプリケーションの下にあるアプリケーションの役に立ちます。 このような場合には、この指示の交換は、適切な層がアプリケーションの下で可能にされるのを許容できます。
2. Conventions
2. コンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Stewart, et al. Standards Track [Page 3] RFC 5061 SCTP Dynamic Address Reconfiguration September 2007
スチュワート、他 規格はダイナミックなSCTPアドレス再構成2007年9月にRFC5061を追跡します[3ページ]。
3. Serial Number Arithmetic
3. 通し番号演算
It is essential to remember that the actual Address Configuration Change Chunk (ASCONF) Sequence Number space is finite, though very large. This space ranges from 0 to 2**32 - 1. Since the space is finite, all arithmetic dealing with ASCONF Sequence Numbers MUST be performed modulo 2**32. This unsigned arithmetic preserves the relationship of sequence numbers as they cycle from 2**32 - 1 to 0 again. There are some subtleties to computer modulo arithmetic, so great care should be taken in programming the comparison of such values. When referring to ASCONF Sequence Numbers, the symbol "=<" means "less than or equal"(modulo 2**32).
実際のAddress Configuration Change Chunk(ASCONF)系列Numberスペースが有限であって、もっとも、非常に大きいのを覚えているのは不可欠です。 このスペースは0〜2**32--1から変化します。 スペースが有限であるので、ASCONF Sequence民数記に対処するすべての演算が実行された法2**32であるに違いありません。 再び2**1〜32--0から循環するとき、この無記名の演算は一連番号の関係を保存します。 コンピュータモジュロ演算へのいくつかの微妙さがあります、非常にすばらしいので、そのような値の比較をプログラムしながら、注意を中に入れるべきです。 ASCONF Sequence民数記を示すとき、「<と等しい」というシンボルは「以下か等しいこと」を(法2**32)意味します。
Comparisons and arithmetic on ASCONF sequence numbers in this document SHOULD use Serial Number Arithmetic as defined in [RFC1982] where SERIAL_BITS = 32.
このドキュメントSHOULDのASCONF一連番号に関する比較と演算は[RFC1982]どこSERIAL_BITS=32に定義されるようにSerial Number Arithmeticを使用するか。
ASCONF Sequence Numbers wrap around when they reach 2**32 - 1. That is, the next ASCONF Sequence Number an ASCONF chunk MUST use after transmitting an ASCONF Sequence Number = 2**32 - 1 is 0.
それらが2**32--1に達する時の周りのASCONF Sequence民数記包装。 すなわち、ASCONF Sequence Number=2**32--1を伝えた後にASCONF塊が使用しなければならない次のASCONF Sequence Numberは0歳です。
Any arithmetic done on Stream Sequence Numbers SHOULD use Serial Number Arithmetic (as defined in [RFC1982]) where SERIAL_BITS = 16. All other arithmetic and comparisons in this document use normal arithmetic.
Stream Sequence民数記SHOULDで行われたどんな演算もSERIAL_BITSが16と等しいところでSerial Number Arithmeticを使用します([RFC1982]で定義されるように)。 他のすべての演算と比較は本書では正常な演算を使用します。
4. Additional Chunks and Parameters
4. 追加塊とパラメタ
This section describes the addition of two new chunks and seven new parameters to allow:
このセクションは許容する2つの新しい塊と7つの新しいパラメタの添加について説明します:
o Dynamic addition of IP addresses to an association.
o IPアドレスの協会へのダイナミックな追加。
o Dynamic deletion of IP addresses from an association.
o 協会からのIPアドレスのダイナミックな削除。
o A request to set the primary address the peer will use when
sending to an endpoint.
o 終点に発信するとき同輩が使用する第一のアドレスを設定するという要求。
Additionally, this section describes three new Error Causes that support these new chunks and parameters.
さらに、このセクションはこれらの新しい塊とパラメタを支持する3新しいError Causesについて説明します。
4.1. New Chunk Types
4.1. 新しい塊タイプ
This section defines two new chunk types that will be used to transfer the control information reliably. Table 1 illustrates the two new chunk types.
このセクションは制御情報を確かに移すのに使用される2つの新しい塊タイプを定義します。 テーブル1は2つの新しい塊タイプを例証します。
Stewart, et al. Standards Track [Page 4] RFC 5061 SCTP Dynamic Address Reconfiguration September 2007
スチュワート、他 規格はダイナミックなSCTPアドレス再構成2007年9月にRFC5061を追跡します[4ページ]。
Chunk Type Chunk Name
--------------------------------------------------------------
0xC1 Address Configuration Change Chunk (ASCONF)
0x80 Address Configuration Acknowledgment (ASCONF-ACK)
塊タイプ塊名-------------------------------------------------------------- 0xC1アドレス構成変更塊(ASCONF)0x80アドレス構成承認(ASCONF-ACK)
Table 1: Address Configuration Chunks
テーブル1: アドレス構成塊
4.1.1. Address Configuration Change Chunk (ASCONF)
4.1.1. アドレス構成変更塊(ASCONF)
This chunk is used to communicate to the remote endpoint one of the configuration change requests that MUST be acknowledged. The information carried in the ASCONF Chunk uses the form of a Type- Length-Value (TLV), as described in "3.2.1 Optional/Variable-length Parameter Format" in [RFC4960] for all variable parameters. This chunk MUST be sent in an authenticated way by using the mechanism defined in [RFC4895]. If this chunk is received unauthenticated it MUST be silently discarded as described in [RFC4895].
この塊は、承諾しなければならない構成変更要求の1つを遠く離れた終点に伝えるのに使用されます。 ASCONF Chunkで運ばれた情報はType長さ価値(TLV)のフォームを使用します、すべての可変パラメタのために[RFC4960]の「3.2の.1の任意の、または、可変長のパラメタ形式」で説明されるように。 [RFC4895]で定義されたメカニズムを使用することによって、認証された方法でこの塊を送らなければなりません。 非認証されていた状態でこの塊を受け取るなら、[RFC4895]で説明されるように捨てられて、それは静かにそうであるに違いありません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0xC1 | Chunk Flags | Chunk Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Parameter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASCONF Parameter #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ .... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASCONF Parameter #N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =0xC1をタイプしてください。| 塊旗| 塊の長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | アドレスパラメタ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ASCONFパラメタ#1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / .... / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ASCONFパラメタ#N| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sequence Number: 32 bits (unsigned integer)
一連番号: 32ビット(符号のない整数)
This value represents a Sequence Number for the ASCONF Chunk. The valid range of a Sequence Number is from 0 to 4294967295 (2**32 - 1). Sequence Numbers wrap back to 0 after reaching 4294967295.
この値はASCONF ChunkのためにSequence Numberを表します。 Sequence Numberの有効枠は、0〜4294967295(2**32--1)です。 4294967295に達した後の0への系列民数記包装。
Address Parameter: 8 or 20 bytes (depending on the address type)
パラメタを記述してください: 8バイトか20バイト(アドレスタイプに頼ります)
This field contains an address parameter, either IPv6 or IPv4, from [RFC4960]. The address is an address of the sender of the ASCONF Chunk; the address MUST be considered part of the association by the peer endpoint (the receiver of the ASCONF Chunk). This field may be
この分野は[RFC4960]からのアドレスパラメタ(IPv6かIPv4のどちらか)を含んでいます。 アドレスはASCONF Chunkの送信者のアドレスです。 同輩終点(ASCONF Chunkの受信機)で協会の一部であるとアドレスを考えなければなりません。 この分野はそうです。
Stewart, et al. Standards Track [Page 5] RFC 5061 SCTP Dynamic Address Reconfiguration September 2007
スチュワート、他 規格はダイナミックなSCTPアドレス再構成2007年9月にRFC5061を追跡します[5ページ]。
used by the receiver of the ASCONF to help in finding the association. If the address 0.0.0.0 or ::0 is provided, the receiver MAY lookup the association by other information provided in the packet. This parameter MUST be present in every ASCONF message, i.e. it is a mandatory TLV parameter.
ASCONFの受信機によって使用されて、協会を見つけるのを手伝います。 または、アドレス0.0.0である、.0、:、:0を提供して、受信機5月のルックアップはパケットに提供された他の情報による協会です。 このパラメタがあらゆるASCONFメッセージに存在していなければならない、すなわち、それは義務的なTLVパラメタです。
Note: The host name address MUST NOT be sent and MUST be ignored if received in any ASCONF message.
以下に注意してください。 どんなASCONFメッセージにも受け取るなら、ホスト名アドレスを送ってはいけなくて、無視しなければなりません。
It should be noted that the ASCONF Chunk format requires the receiver to report to the sender if it does not understand the ASCONF Chunk. This is accomplished by setting the upper bits in the chunk type as described in [RFC4960], Section 3.2. Note that the upper two bits in the ASCONF Chunk are set to one. As defined in [RFC4960], Section 3.2, when setting these upper bits in this manner the receiver that does not understand this chunk MUST skip the chunk and continue processing, and report in an Operation Error Chunk using the 'Unrecognized Chunk Type' cause of error. This will NOT abort the association but indicates to the sender that it MUST not send any further ASCONF chunks.
ASCONF Chunkを理解していないならASCONF Chunk形式が送付者に報告するために受信機を必要とすることに注意されるべきです。 これは、[RFC4960]、セクション3.2で説明されるように塊タイプに上側のビットをはめ込むことによって、達成されます。 ASCONF Chunkの上側の2ビットが1つに設定されることに注意してください。 [RFC4960]、セクション3.2で定義されるように、この様にこれらの上側のビットを設定するとき、この塊を理解していない受信機は、誤りの'認識されていないChunk Type'原因を使用するOperation Error Chunkで塊をスキップして、処理し続けて、報告しなければなりません。 これは、協会を中止しませんが、塊をASCONFにこれ以上送ってはいけないのを送付者に示します。
ASCONF Parameter: TLV format
ASCONFパラメタ: TLV形式
Each address configuration change is represented by a TLV parameter, as defined in Section 4.2. One or more requests may be present in an ASCONF Chunk.
それぞれのアドレス構成変更はセクション4.2で定義されるようにTLVパラメタによって表されます。 1つ以上の要求がASCONF Chunkに存在しているかもしれません。
4.1.2. Address Configuration Acknowledgment Chunk (ASCONF-ACK)
4.1.2. アドレス構成承認塊(ASCONF-ACK)
This chunk is used by the receiver of an ASCONF Chunk to acknowledge the reception. It carries zero or more results for any ASCONF parameters that were processed by the receiver. This chunk MUST be sent in an authenticated way by using the mechanism defined in [RFC4895]. If this chunk is received unauthenticated it MUST be silently discarded as described in [RFC4895].
この塊はASCONF Chunkの受信機によって使用されて、レセプションを承認します。 それは受信機によって処理されたどんなASCONFパラメタのためにもゼロか、より多くの結果を運びます。[RFC4895]で定義されたメカニズムを使用することによって、認証された方法でこの塊を送らなければなりません。 非認証されていた状態でこの塊を受け取るなら、[RFC4895]で説明されるように捨てられて、それは静かにそうであるに違いありません。
Stewart, et al. Standards Track [Page 6] RFC 5061 SCTP Dynamic Address Reconfiguration September 2007
スチュワート、他 規格はダイナミックなSCTPアドレス再構成2007年9月にRFC5061を追跡します[6ページ]。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x80 | Chunk Flags | Chunk Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASCONF Parameter Response#1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \
/ .... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASCONF Parameter Response#N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =0x80をタイプしてください。| 塊旗| 塊の長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 一連番号| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ASCONFパラメタ応答#1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / .... / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ASCONFパラメタ応答#N| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sequence Number: 32 bits (unsigned integer)
一連番号: 32ビット(符号のない整数)
This value represents the Sequence Number for the received ASCONF Chunk that is acknowledged by this chunk. This value is copied from the received ASCONF Chunk.
この値はこの塊によって承認される容認されたASCONF ChunkのためにSequence Numberを表します。 この値は容認されたASCONF Chunkからコピーされます。
ASCONF Parameter Response: TLV format
ASCONFパラメタ応答: TLV形式
The ASCONF Parameter Response is used in the ASCONF-ACK to report the status of ASCONF processing. By default, if a responding endpoint does not include any Error Cause, a success is indicated. Thus a sender of an ASCONF-ACK MAY indicate complete success of all TLVs in an ASCONF by returning only the Chunk Type, Chunk Flags, Chunk Length (set to 8), and the Sequence Number.
ASCONF Parameter Responseは、ASCONF処理の状態を報告するのにASCONF-ACKで使用されます。 デフォルトで、応じる終点が少しのError Causeも含んでいないなら、成功は示されます。 したがって、ASCONF-ACK MAYの送付者は、Chunk Type、Chunk Flags、Chunk Length(8に設定する)、およびSequence Numberだけを返すことによって、ASCONFのすべてのTLVsの完全な成功を示します。
4.2. New Parameter Types
4.2. 新しいパラメータの型
The seven new parameters added follow the format defined in Section 3.2.1 of [RFC4960]. Tables 2, 3, and 4 describe the parameters.
7つの新しいパラメタが、.1セクション3.2[RFC4960]で定義された書式に従うように言い足しました。 テーブル2、3、および4 パラメタについて説明してください。
Address Configuration Parameters Parameter Type
-------------------------------------------------
Set Primary Address 0xC004
Adaptation Layer Indication 0xC006
Supported Extensions 0x8008
アドレス設定パラメータパラメータの型------------------------------------------------- 0xC006が拡大0x8008を支持したという第一のアドレス0xC004適合層の指示を設定してください。
Table 2: Parameters That Can Be Used in an INIT/INIT-ACK Chunk
テーブル2: イニットイニット/ACK塊に使用できるパラメタ
Stewart, et al. Standards Track [Page 7] RFC 5061 SCTP Dynamic Address Reconfiguration September 2007
スチュワート、他 規格はダイナミックなSCTPアドレス再構成2007年9月にRFC5061を追跡します[7ページ]。
Address Configuration Parameters Parameter Type
-------------------------------------------------
Add IP Address 0xC001
Delete IP Address 0xC002
Set Primary Address 0xC004
アドレス設定パラメータパラメータの型------------------------------------------------- IPアドレス0xC001がIPのアドレスの0xC002のセットの第一のアドレス0xC004を削除すると言い足してください。
Table 3: Parameters Used in an ASCONF Parameter
テーブル3: ASCONFパラメタで使用されるパラメタ
Address Configuration Parameters Parameter Type
-------------------------------------------------
Error Cause Indication 0xC003
Success Indication 0xC005
アドレス設定パラメータパラメータの型------------------------------------------------- 誤り原因指示0xC003成功指示0xC005
Table 4: Parameters Used in an ASCONF Parameter Response
テーブル4: ASCONFパラメタ応答に使用されるパラメタ
Any parameter that appears where it is not allowed (for example, a 0xC002 parameter appearing within an INIT or INIT-ACK) MAY be responded to with an ABORT by the receiver of the invalid parameter. If the receiver chooses NOT to abort, the parameter MUST be ignored. A robust implementation SHOULD ignore the parameter and leave the association intact.
ABORTと共に無効のパラメタの受信機によってそれが許容されていないところに現れるどんなパラメタ(例えばINITかINIT-ACKの中に現れる0xC002パラメタ)にも応じられるかもしれません。 受信機が中止になるようにNOTを選ぶなら、パラメタを無視しなければなりません。 体力を要している実現SHOULDはパラメタを無視して、協会を完全なままにします。
4.2.1. Add IP Address
4.2.1. IPアドレスを加えてください。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0xC001 | Length = Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASCONF-Request Correlation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Parameter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =0xC001をタイプしてください。| 長さは変数と等しいです。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ASCONF-要求相関関係ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | アドレスパラメタ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ASCONF-Request Correlation ID: 32 bits
ASCONF-要求相関関係ID: 32ビット
This is an opaque integer assigned by the sender to identify each request parameter. The receiver of the ASCONF Chunk will copy this 2-bit value into the ASCONF Response Correlation ID field of the ASCONF-ACK response parameter. The sender of the ASCONF can use this same value in the ASCONF-ACK to find which request the response is for. Note that the receiver MUST NOT change this 32-bit value.
これはそれぞれの要求パラメタを特定するために送付者によって割り当てられた不透明な整数です。 ASCONF Chunkの受信機はASCONF-ACK応答パラメタのASCONF Response Correlation ID分野にこの2ビットの値をコピーするでしょう。 ASCONFの送付者は、どれが、応答があるよう要求するかわかるのにASCONF-ACKでこの同じ値を使用できます。 受信機がこの32ビットの値を変えてはいけないことに注意してください。
Stewart, et al. Standards Track [Page 8] RFC 5061 SCTP Dynamic Address Reconfiguration September 2007
スチュワート、他 規格はダイナミックなSCTPアドレス再構成2007年9月にRFC5061を追跡します[8ページ]。
Address Parameter: TLV
パラメタを記述してください: TLV
This field contains an IPv4 or IPv6 address parameter as described in Section 3.3.2.1 of [RFC4960]. The complete TLV is wrapped within this parameter. It informs the receiver that the address specified is to be added to the existing association. This parameter MUST NOT contain a broadcast or multicast address. If the address 0.0.0.0 or ::0 is provided, the source address of the packet MUST be added.
この分野は、セクション3.3.2で.1[RFC4960]について説明するので、IPv4かIPv6アドレスパラメタを含んでいます。 完全なTLVはこのパラメタの中で包装されます。 それは、指定されたアドレスが既存の協会に追加されることであることを受信機に知らせます。 このパラメタは放送かマルチキャストアドレスを含んではいけません。 または、アドレス0.0.0である、.0、:、:0は提供していて、パケットのソースアドレスを加えなければならないということです。
An example TLV requesting that the IPv4 address 192.0.2.1 be added to the association would look as follows:
IPv4アドレス192.0.2.1が協会に追加されるよう要求する例のTLVは以下の通りに見えるでしょう:
+--------------------------------+
| Type=0xC001 | Length = 16 |
+--------------------------------+
| C-ID = 0x01023474 |
+--------------------------------+
| Type=5 | Length = 8 |
+----------------+---------------+
| Value=0xC0000201 |
+----------------+---------------+
+--------------------------------+ | =0xC001をタイプしてください。| 長さ=16| +--------------------------------+ | C-ID=0x01023474| +--------------------------------+ | =5をタイプしてください。| 長さ=8| +----------------+---------------+ | 値は0xC0000201と等しいです。| +----------------+---------------+
Valid Chunk Appearance
有効な塊外観
The Add IP Address parameter may only appear in the ASCONF Chunk type.
Add IP AddressパラメタはASCONF Chunkタイプで現れるだけであるかもしれません。
4.2.2. Delete IP Address
4.2.2. IPアドレスを削除してください。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type =0xC002 | Length = Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASCONF-Request Correlation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Parameter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =0xC002をタイプしてください。| 長さは変数と等しいです。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ASCONF-要求相関関係ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | アドレスパラメタ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ASCONF-Request Correlation ID: 32 bits
ASCONF-要求相関関係ID: 32ビット
This is an opaque integer assigned by the sender to identify each request parameter. The receiver of the ASCONF Chunk will copy this 32-bit value into the ASCONF Response Correlation ID field of the ASCONF-ACK response parameter. The sender of the ASCONF can use this same value in the ASCONF-ACK to find which request the response is for. Note that the receiver MUST NOT change this 32-bit value.
これはそれぞれの要求パラメタを特定するために送付者によって割り当てられた不透明な整数です。 ASCONF Chunkの受信機はASCONF-ACK応答パラメタのASCONF Response Correlation ID分野にこの32ビットの値をコピーするでしょう。 ASCONFの送付者は、どれが、応答があるよう要求するかわかるのにASCONF-ACKでこの同じ値を使用できます。 受信機がこの32ビットの値を変えてはいけないことに注意してください。
Stewart, et al. Standards Track [Page 9] RFC 5061 SCTP Dynamic Address Reconfiguration September 2007
スチュワート、他 規格はダイナミックなSCTPアドレス再構成2007年9月にRFC5061を追跡します[9ページ]。
Address Parameter: TLV
パラメタを記述してください: TLV
This field contains an IPv4 or IPv6 address parameter, as described in Section 3.3.2.1 of [RFC4960]. The complete TLV is wrapped within this parameter. It informs the receiver that the address specified is to be removed from the existing association. This parameter MUST NOT contain a broadcast or multicast address. If the address 0.0.0.0 or ::0 is provided, all addresses of the peer except the source address of the packet MUST be deleted.
この分野は、セクション3.3.2で.1[RFC4960]について説明するので、IPv4かIPv6アドレスパラメタを含んでいます。 完全なTLVはこのパラメタの中で包装されます。 それは、指定されたアドレスが既存の協会から取り除かれることであることを受信機に知らせます。 このパラメタは放送かマルチキャストアドレスを含んではいけません。 または、アドレス0.0.0である、.0、:、:0は提供していて、パケットのソースアドレス以外の同輩のすべてのアドレスを削除しなければならないということです。
An example TLV deleting the IPv4 address 192.0.2.1 from an existing association would look as follows:
既存の協会からIPv4アドレス192.0.2.1を削除する例のTLVは以下の通りに見えるでしょう:
+--------------------------------+
| Type=0xC002 | Length = 16 |
+--------------------------------+
| C-ID = 0x01023476 |
+--------------------------------+
| Type=5 | Length = 8 |
+----------------+---------------+
| Value=0xC0000201 |
+----------------+---------------+
+--------------------------------+ | =0xC002をタイプしてください。| 長さ=16| +--------------------------------+ | C-ID=0x01023476| +--------------------------------+ | =5をタイプしてください。| 長さ=8| +----------------+---------------+ | 値は0xC0000201と等しいです。| +----------------+---------------+
Valid Chunk Appearance
有効な塊外観
The Delete IP Address parameter may only appear in the ASCONF Chunk type.
Delete IP AddressパラメタはASCONF Chunkタイプで現れるだけであるかもしれません。
4.2.3. Error Cause Indication
4.2.3. 誤り原因指示
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0xC003 | Length = Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASCONF-Response Correlation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Cause(s) or Success Indication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =0xC003をタイプしてください。| 長さは変数と等しいです。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ASCONF-応答Correlation ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 誤り原因か成功指示| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ASCONF-Response Correlation ID: 32 bits
ASCONF-応答Correlation ID: 32ビット
This is an opaque integer assigned by the sender to identify each request parameter. The receiver of the ASCONF Chunk will copy this 32-bit value from the ASCONF-Request Correlation ID into the ASCONF Response Correlation ID field so the peer can easily correlate the request to this response. Note that the receiver MUST NOT change this 32-bit value.
これはそれぞれの要求パラメタを特定するために送付者によって割り当てられた不透明な整数です。 同輩がこの応答に要求を容易に関連させることができるように、ASCONF Chunkの受信機はASCONF-要求Correlation IDをこの32ビットの値をASCONF Response Correlation ID分野に回避するでしょう。 受信機がこの32ビットの値を変えてはいけないことに注意してください。
Stewart, et al. Standards Track [Page 10] RFC 5061 SCTP Dynamic Address Reconfiguration September 2007
スチュワート、他 規格はダイナミックなSCTPアドレス再構成2007年9月にRFC5061を追跡します[10ページ]。
Error Cause(s): TLV(s)
誤り原因: TLV(s)
When reporting an error, this response parameter is used to wrap one or more standard Error Causes normally found within an SCTP Operational Error or SCTP Abort (as defined in [RFC4960]). The Error Cause(s) follow the format defined in Section 3.3.10 of [RFC4960].
誤りを報告するとき、この応答パラメタは、通常、SCTP Operational ErrorかSCTP Abortの中で見つけられた1標準のError Causesを包装するのに使用されます([RFC4960]で定義されるように)。 Error Cause(s)は.10セクション3.3[RFC4960]で定義された書式に従います。
Valid Chunk Appearance
有効な塊外観
The Error Cause Indication parameter may only appear in the ASCONF- ACK Chunk Type.
Error Cause IndicationパラメタはASCONF- ACK Chunk Typeに現れるだけであるかもしれません。
4.2.4. Set Primary IP Address
4.2.4. 第一のIPアドレスを設定してください。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type =0xC004 | Length = Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASCONF-Request Correlation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Parameter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =0xC004をタイプしてください。| 長さは変数と等しいです。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ASCONF-要求相関関係ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | アドレスパラメタ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ASCONF-Request Correlation ID: 32 bits
ASCONF-要求相関関係ID: 32ビット
This is an opaque integer assigned by the sender to identify each request parameter. The receiver of the ASCONF Chunk will copy this 32-bit value into the ASCONF Response Correlation ID field of the ASCONF-ACK response parameter. The sender of the ASCONF can use this same value in the ASCONF-ACK to find which request the response is for. Note that the receiver MUST NOT change this 32-bit value.
これはそれぞれの要求パラメタを特定するために送付者によって割り当てられた不透明な整数です。 ASCONF Chunkの受信機はASCONF-ACK応答パラメタのASCONF Response Correlation ID分野にこの32ビットの値をコピーするでしょう。 ASCONFの送付者は、どれが、応答があるよう要求するかわかるのにASCONF-ACKでこの同じ値を使用できます。 受信機がこの32ビットの値を変えてはいけないことに注意してください。
Address Parameter: TLV
パラメタを記述してください: TLV
This field contains an IPv4 or IPv6 address parameter as described in Section 3.3.2.1 of [RFC4960]. The complete TLV is wrapped within this parameter. It requests the receiver to mark the specified address as the primary address to send data to (see Section 5.1.2 of [RFC4960]). The receiver MAY mark this as its primary address upon receiving this request. If the address 0.0.0.0 or ::0 is provided, the receiver MAY mark the source address of the packet as its primary.
この分野は、セクション3.3.2で.1[RFC4960]について説明するので、IPv4かIPv6アドレスパラメタを含んでいます。 完全なTLVはこのパラメタの中で包装されます。 それは、データを送る第一のアドレスとして指定されたアドレスにマークするよう受信機に要求します(.2セクション5.1[RFC4960]を見てください)。 受信機は、受信に関する第一のアドレスとしてのこれがこの要求であるとマークするかもしれません。 または、アドレス0.0.0である、.0、:、:受信機は、0を提供して、予備選挙としてパケットのソースアドレスにマークするかもしれません。
An example TLV requesting that the IPv4 address 192.0.2.1 be made the primary destination address would look as follows:
IPv4が記述する例のTLV要求、192.0、.2、.1、作られていて、第一の送付先アドレスが以下の通りに見えるだろうということになってください:
Stewart, et al. Standards Track [Page 11] RFC 5061 SCTP Dynamic Address Reconfiguration September 2007
スチュワート、他 規格はダイナミックなSCTPアドレス再構成2007年9月にRFC5061を追跡します[11ページ]。
+--------------------------------+
| Type=0xC004 | Length = 16 |
+--------------------------------+
| C-ID = 0x01023479 |
+--------------------------------+
| Type=5 | Length = 8 |
+----------------+---------------+
| Value=0xC0000201 |
+----------------+---------------+
+--------------------------------+ | =0xC004をタイプしてください。| 長さ=16| +--------------------------------+ | C-ID=0x01023479| +--------------------------------+ | =5をタイプしてください。| 長さ=8| +----------------+---------------+ | 値は0xC0000201と等しいです。| +----------------+---------------+
Valid Chunk Appearance
有効な塊外観
The Set Primary IP Address parameter may appear in the ASCONF, the INIT, or the INIT-ACK Chunk Type. The inclusion of this parameter in the INIT or INIT-ACK can be used to indicate an initial preference of primary address.
Set Primary IP AddressパラメタはASCONF、INIT、またはINIT-ACK Chunk Typeに現れるかもしれません。 第一のアドレスの初期の優先を示すのにINITかINIT-ACKでのこのパラメタの包含を使用できます。
4.2.5. Success Indication
4.2.5. 成功指示
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0xC005 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASCONF-Response Correlation ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =0xC005をタイプしてください。| 長さ=8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ASCONF-応答Correlation ID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
By default, if a responding endpoint does not report an error for any requested TLV, a success is implicitly indicated. Thus, a sender of an ASCONF-ACK MAY indicate complete success of all TLVs in an ASCONF by returning only the Chunk Type, Chunk Flags, Chunk Length (set to 8), and the Sequence Number.
デフォルトで、応じる終点がどんな要求されたTLVのためにも誤りを報告しないなら、成功はそれとなく示されます。 したがって、ASCONF-ACK MAYの送付者は、Chunk Type、Chunk Flags、Chunk Length(8に設定する)、およびSequence Numberだけを返すことによって、ASCONFのすべてのTLVsの完全な成功を示します。
The responding endpoint MAY also choose to explicitly report a success for a requested TLV, by returning a success report ASCONF Parameter Response.
また、応じる終点は、要求されたTLVのために明らかに成功を報告するのを選ぶかもしれなくて、戻るのによる成功はレポートASCONF Parameter Responseです。
ASCONF-Response Correlation ID: 32 bits
ASCONF-応答Correlation ID: 32ビット
This is an opaque integer assigned by the sender to identify each request parameter. The receiver of the ASCONF Chunk will copy this 32-bit value from the ASCONF-Request Correlation ID into the ASCONF Response Correlation ID field so the peer can easily correlate the request to this response.
これはそれぞれの要求パラメタを特定するために送付者によって割り当てられた不透明な整数です。 同輩がこの応答に要求を容易に関連させることができるように、ASCONF Chunkの受信機はASCONF-要求Correlation IDをこの32ビットの値をASCONF Response Correlation ID分野に回避するでしょう。
Stewart, et al. Standards Track [Page 12] RFC 5061 SCTP Dynamic Address Reconfiguration September 2007
スチュワート、他 規格はダイナミックなSCTPアドレス再構成2007年9月にRFC5061を追跡します[12ページ]。
Valid Chunk Appearance
有効な塊外観
The Success Indication parameter may only appear in the ASCONF-ACK Chunk Type.
Success IndicationパラメタはASCONF-ACK Chunk Typeに現れるだけであるかもしれません。
4.2.6. Adaptation Layer Indication
4.2.6. 適合層の指示
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type =0xC006 | Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Adaptation Code point |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | =0xC006をタイプしてください。| 長さ=8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 適合コード・ポイント| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This parameter is specified for the communication of peer upper-layer protocols. It is envisioned to be used for flow control and other adaptation layers that require an indication to be carried in the INIT and INIT-ACK. Each adaptation layer that is defined that wishes to use this parameter MUST specify an adaptation code point in an appropriate RFC defining its use and meaning. This parameter SHOULD NOT be examined by the receiving SCTP implementation and should be passed opaquely to the upper-layer protocol.
このパラメタは同輩上側の層のプロトコルに関するコミュニケーションに指定されます。 それは、フロー制御と指示がINITとINIT-ACKで運ばれるのを必要とする他の適合層に使用されるために思い描かれます。 定義されて、それがこのパラメタを使用したがっているということであるそれぞれの適合層は使用を定義する適切なRFCと意味で適合コード・ポイントを指定しなければなりません。 このパラメタSHOULD NOTは受信SCTP実現で調べられて、上側の層のプロトコルに不透明に渡されるべきです。
Note: This parameter is not used in either the addition or deletion of addresses but is for the convenience of the upper layer. This document includes this parameter to minimize the number of SCTP documents.
以下に注意してください。 このパラメタは、アドレスの添加か削除では使用されませんが、上側の層の都合のためにあります。 このドキュメントは、SCTPドキュメントの数を最小にするためにこのパラメタを含んでいます。
Valid Chunk Appearance
有効な塊外観
The Adaptation Layer Indication parameter may appear in INIT or INIT- ACK chunk and SHOULD be passed to the receiver's upper-layer protocol based upon the upper-layer protocol configuration of the SCTP stack. This parameter MUST NOT be sent in any other chunks, and if it is received in another chunk, it MUST be ignored.
Adaptation Layer IndicationパラメタはINITかINIT- ACK塊とSHOULDに現れるかもしれません。SCTPスタックの上側の層のプロトコル構成に基づく受信機の上側の層のプロトコルに通過されてください。 いかなる他の塊でもこのパラメタを送ってはいけません、そして、別の塊でそれを受け取るなら、それを無視しなければなりません。
4.2.7. Supported Extensions Parameter
4.2.7. 支持された拡大パラメタ
This parameter is used at startup to identify any additional extensions that the sender supports. The sender MUST support both the sending and the receiving of any chunk types listed within the Supported Extensions Parameter. An implementation supporting this extension MUST list the ASCONF,the ASCONF-ACK, and the AUTH chunks in its INIT and INIT-ACK parameters.
このパラメタは、送付者が支持するどんな追加拡大も特定するのに始動で使用されます。 送付者は発信とSupported Extensions Parameterの中に記載されたどんな塊タイプの受信の両方も支持しなければなりません。 この拡大を支持する実現はINITとINIT-ACKパラメタのASCONF、ASCONF-ACK、およびAUTH塊を記載しなければなりません。
Stewart, et al. Standards Track [Page 13] RFC 5061 SCTP Dynamic Address Reconfiguration September 2007
スチュワート、他 規格はダイナミックなSCTPアドレス再構成2007年9月にRFC5061を追跡します[13ページ]。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Type = 0x8008 | Parameter Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CHUNK TYPE 1 | CHUNK TYPE 2 | CHUNK TYPE 3 | CHUNK TYPE 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CHUNK TYPE N | PAD | PAD | PAD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | パラメータの型=0×8008| パラメタの長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 塊タイプ1| 塊タイプ2| 塊タイプ3| 塊タイプ4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 塊タイプN| パッド| パッド| パッド| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameter Type This field holds the IANA-defined parameter type for the Supported Extensions Parameter. The value of this field is 0x8008.
パラメタType This分野はSupported Extensions ParameterのためのIANAによって定義されたパラメータの型を保持します。 この分野の値は0×8008です。
Parameter Type Length This field holds the length of the parameter, including the Parameter Type, Parameter Length, and any additional supported extensions. Note: The length MUST NOT include any padding.
パラメタType Length This分野はパラメタの長さを保持します、Parameter Type、Parameter Length、およびどんな追加支持された拡大も含んでいて。 以下に注意してください。 長さは少しの詰め物も含んではいけません。
CHUNK TYPE X This field(s) hold the chunk type of any SCTP extension(s) that are currently supported by the sending SCTP. Multiple chunk types may be defined listing each additional feature that the sender supports. The sender MUST NOT include multiple Supported Extensions Parameter within any chunk.
CHUNK TYPE X This分野は現在発信しているSCTPによって支持されるどんなSCTP拡張子の塊タイプも保持します。 複数の塊タイプが、送付者が支持する各付加的な機能を記載しながら、定義されるかもしれません。 送付者はどんな塊の中でも複数のSupported Extensions Parameterを入れてはいけません。
Parameter Appearance This parameter may appear in the INIT or INIT- ACK chunk. This parameter MUST NOT appear in any other chunk.
パラメタAppearance ThisパラメタはINITかINIT- ACK塊に現れるかもしれません。 このパラメタはいかなる他の塊にも現れてはいけません。
4.3. New Error Causes
4.3. 新しい誤り原因
Five new Error Causes are added to the SCTP Operational Errors, primarily for use in the ASCONF-ACK Chunk.
5新しいError Causesが主としてASCONF-ACK Chunkにおける使用のためにSCTP Operational Errorsに加えられます。
Cause Code
Value Cause Code
--------- ----------------
0x00A0 Request to Delete Last Remaining IP Address
0x00A1 Operation Refused Due to Resource Shortage
0x00A2 Request to Delete Source IP Address
0x00A3 Association Aborted Due to Illegal ASCONF-ACK
0x00A4 Request Refused - No Authorization
原因コード値原因コード--------- ---------------- 最後に削除する0x00A2が拒否された不法なASCONF-ACK 0x00A4要求のため中止されたソースIPアドレス0x00A3協会を削除するよう要求するリソース不足のため拒否されたIPアドレス0x00A1操作のままで残っている0x00A0要求--認可がありません。
Table 5: New Error Causes
テーブル5: 新しい誤り原因
Stewart, et al. Standards Track [Page 14] RFC 5061 SCTP Dynamic Address Reconfiguration September 2007
スチュワート、他 規格はダイナミックなSCTPアドレス再構成2007年9月にRFC5061を追跡します[14ページ]。
4.3.1. Error Cause: Request to Delete Last Remaining IP Address
4.3.1. 誤り原因: 最後に削除するIPアドレスのままで残っている要求
Cause of error
誤りの原因
Request to Delete Last Remaining IP Address: The receiver of this error sent a request to delete the last IP address from its association with its peer. This error indicates that the request is rejected.
最後に削除するIPアドレスのままで残っている要求: この誤りの受信機は同輩との仲間から最後のIPアドレスを削除するという要求を送りました。 この誤りは、要求が拒絶されるのを示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=0x00A0 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ TLV-Copied-From-ASCONF /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 原因コードは0x00A0と等しいです。| 原因の長さは変数と等しいです。| コピー
An example of a failed delete in an Error Cause TLV would look as follows in the response ASCONF-ACK message:
失敗されたaに関する例は応答ASCONF-ACKメッセージで以下の通りでError Cause TLVが見えるコネを削除します:
+--------------------------------+
| Type = 0xC003 | Length = 28 |
+----------------+---------------+
| C-ID = 0x01023476 |
+--------------------------------+
| Cause=0x00A0 | Length = 20 |
+----------------+---------------+
| Type= 0xC002 | Length = 16 |
+----------------+---------------+
| C-ID = 0x01023476 |
+--------------------------------+
| Type=0x0005 | Length = 8 |
+----------------+---------------+
| Value=0xC0000201 |
+----------------+---------------+
+--------------------------------+ | =0xC003をタイプしてください。| 長さ=28| +----------------+---------------+ | C-ID=0x01023476| +--------------------------------+ | 原因は0x00A0と等しいです。| 長さ=20| +----------------+---------------+ | =0xC002をタイプしてください。| 長さ=16| +----------------+---------------+ | C-ID=0x01023476| +--------------------------------+ | =0x0005をタイプしてください。| 長さ=8| +----------------+---------------+ | 値は0xC0000201と等しいです。| +----------------+---------------+
4.3.2. Error Cause: Operation Refused Due to Resource Shortage
4.3.2. 誤り原因: リソース不足のため拒否された操作
Cause of error
誤りの原因
This Error Cause is used to report a failure by the receiver to perform the requested operation due to a lack of resources. The entire TLV that is refused is copied from the ASCONF into the Error Cause.
このError Causeは、財源不足による要求された操作を実行するために受信機で失敗を報告するのに使用されます。 拒否される全体のTLVはASCONFからError Causeにコピーされます。
Stewart, et al. Standards Track [Page 15] RFC 5061 SCTP Dynamic Address Reconfiguration September 2007
スチュワート、他 規格はダイナミックなSCTPアドレス再構成2007年9月にRFC5061を追跡します[15ページ]。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=0x00A1 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ TLV-Copied-From-ASCONF /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 原因コードは0x00A1と等しいです。| 原因の長さは変数と等しいです。| コピー
An example of a failed addition in an Error Cause TLV would look as follows in the response ASCONF-ACK message:
Error Cause TLVでの失敗した添加に関する例は応答ASCONF-ACKメッセージで以下の通りに見えるでしょう:
+--------------------------------+
| Type = 0xC003 | Length = 28 |
+--------------------------------+
| C-ID = 0x01023474 |
+--------------------------------+
| Cause=0x00A1 | Length = 20 |
+----------------+---------------+
| Type=0xC001 | Length = 16 |
+--------------------------------+
| C-ID = 0x01023474 |
+--------------------------------+
| Type=0x0005 | Length = 8 |
+----------------+---------------+
| Value=0xC0000201 |
+----------------+---------------+
+--------------------------------+ | =0xC003をタイプしてください。| 長さ=28| +--------------------------------+ | C-ID=0x01023474| +--------------------------------+ | 原因は0x00A1と等しいです。| 長さ=20| +----------------+---------------+ | =0xC001をタイプしてください。| 長さ=16| +--------------------------------+ | C-ID=0x01023474| +--------------------------------+ | =0x0005をタイプしてください。| 長さ=8| +----------------+---------------+ | 値は0xC0000201と等しいです。| +----------------+---------------+
4.3.3. Error Cause: Request to Delete Source IP Address
4.3.3. 誤り原因: ソースIPアドレスを削除するという要求
Cause of error
誤りの原因
Request to Delete Source IP Address: The receiver of this error sent a request to delete the source IP address of the ASCONF message. This error indicates that the request is rejected.
ソースIPアドレスを削除するという要求: この誤りの受信機はASCONFメッセージのソースIPアドレスを削除するという要求を送りました。 この誤りは、要求が拒絶されるのを示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=0x00A2 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ TLV-Copied-From-ASCONF /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 原因コードは0x00A2と等しいです。| 原因の長さは変数と等しいです。| コピー
Stewart, et al. Standards Track [Page 16] RFC 5061 SCTP Dynamic Address Reconfiguration September 2007
スチュワート、他 規格はダイナミックなSCTPアドレス再構成2007年9月にRFC5061を追跡します[16ページ]。
An example of a failed delete in an Error Cause TLV would look as follows in the response ASCONF-ACK message:
失敗されたaに関する例は応答ASCONF-ACKメッセージで以下の通りでError Cause TLVが見えるコネを削除します:
+--------------------------------+
| Type = 0xC003 | Length = 28 |
+--------------------------------+
| C-ID = 0x01023476 |
+--------------------------------+
| Cause=0x00A2 | Length = 20 |
+----------------+---------------+
| Type=0xC002 | Length = 16 |
+----------------+---------------+
| C-ID = 0x01023476 |
+--------------------------------+
| Type=0x0005 | Length = 8 |
+----------------+---------------+
| Value=0xC0000201 |
+----------------+---------------+
+--------------------------------+ | =0xC003をタイプしてください。| 長さ=28| +--------------------------------+ | C-ID=0x01023476| +--------------------------------+ | 原因は0x00A2と等しいです。| 長さ=20| +----------------+---------------+ | =0xC002をタイプしてください。| 長さ=16| +----------------+---------------+ | C-ID=0x01023476| +--------------------------------+ | =0x0005をタイプしてください。| 長さ=8| +----------------+---------------+ | 値は0xC0000201と等しいです。| +----------------+---------------+
IMPLEMENTATION NOTE: It is unlikely that an endpoint would source a packet from the address being deleted, unless the endpoint does not do proper source address selection.
実現注意: 終点が削除されるアドレスからパケットの出典を明示するのは、ありそうもないです、終点が適切なソースアドレス選択をするなら。
4.3.4. Error Cause: Association Aborted Due to Illegal ASCONF-ACK
4.3.4. 誤り原因: 不法なASCONF-ACKのため中止された協会
This error is to be included in an ABORT that is generated due to the reception of an ASCONF-ACK that was not expected but is larger than the current Sequence Number (see Section 5.3, Rule F0 ). Note that a Sequence Number is larger than the last acked Sequence Number if it is either the next sequence or no more than 2**31-1 greater than the current Sequence Number. Sequence Numbers smaller than the last acked Sequence Number are silently ignored.
この誤りは予想されませんでしたが、現在のSequence Numberより大きいASCONF-ACKのレセプションのため発生するABORTに含まれる(セクション5.3を見てください、Rule F0)ことです。 Sequence Numberがそれが31-1 現在のSequence Numberより大きい次の系列か2**のどちらかであるだけであるなら最後のacked Sequence Numberより大きいことに注意してください。 最後のacked Sequence Numberが静かに無視されるより小さい系列民数記。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=0x00A3 | Cause Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 原因コードは0x00A3と等しいです。| 原因の長さ=4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.3.5. Error Cause: Request Refused - No Authorization.
4.3.5. 誤り原因: 要求は拒否しました--認可がありません。
Cause of error
誤りの原因
This Error Cause may be included to reject a request based on local security policies.
このError Causeは、ローカルの安全保障政策に基づく要求を拒絶するために含まれるかもしれません。
Stewart, et al. Standards Track [Page 17] RFC 5061 SCTP Dynamic Address Reconfiguration September 2007
スチュワート、他 規格はダイナミックなSCTPアドレス再構成2007年9月にRFC5061を追跡します[17ページ]。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cause Code=0x00A4 | Cause Length=Variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ TLV-Copied-From-ASCONF /
/ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 原因コードは0x00A4と等しいです。| 原因の長さは変数と等しいです。| コピー
5. Procedures
5. 手順
This section will lay out the specific procedures for address- configuration change chunk type and its processing.
このセクションはアドレス構成変更塊タイプとその処理のための特定の手順を広げるでしょう。
5.1. ASCONF Chunk Procedures
5.1. ASCONF塊手順
When an endpoint has an ASCONF signaled change to be sent to the remote endpoint, it MUST do the following:
いつ、終点にはASCONFがあるかが遠く離れた終点に送られるように変化に合図して、以下をしなければなりません:
A1) Create an ASCONF Chunk as defined in Section 4.1.1. The chunk
MUST contain all of the TLV(s) of information necessary to be
sent to the remote endpoint, and unique correlation identities
for each request.
A1) セクション4.1.1で定義されるようにASCONF Chunkを作成してください。 塊は遠く離れた終点に送られる必要情報のTLV(s)、および各要求のためのユニークな相関関係のアイデンティティのすべてを含まなければなりません。
A2) A Sequence Number MUST be assigned to the Chunk. The Sequence
Number MUST be larger by one. The Sequence Number MUST be
initialized at the start of the association to the same value as
the Initial Transmission Sequence Number (TSN) and every time a
new ASCONF Chunk is created, it MUST be incremented by one after
assigning the Sequence Number to the newly created chunk.
A2) Sequence NumberをChunkに割り当てなければなりません。 Sequence Numberは1時までに、より大きいに違いありません。 協会の始めでInitial Transmission Sequence Number(TSN)と同じ値にSequence Numberを初期化しなければなりません、そして、新しいASCONF Chunkが作成されるときはいつも、新たに作成された塊にSequence Numberを割り当てた後に、それを1つ増加しなければなりません。
A3) If no SCTP packet with one or more ASCONF Chunk(s) is
outstanding (unacknowledged) with the remote peer, send the
chunk and proceed to step A4. If an ASCONF chunk is
outstanding, then the ASCONF chunk should be queued for later
transmission and no further action should be taken until the
previous ASCONF is acknowledged or a timeout occurs.
A3) 1ASCONF Chunk(s)があるどんなSCTPパケットもリモート同輩と共に傑出していないなら(不承認の)、塊を送ってください、そして、A4を踏みかけてください。 ASCONF塊が傑出しているなら、後のトランスミッションのためにASCONF塊を列に並ばせるべきです、そして、前のASCONFが承認されるか、またはタイムアウトが起こるまで、さらなる行動を全く取るべきではありません。
A4) The sender MUST Start a T-4 Retransmission Timeout (RTO) timer,
using the RTO value of the selected destination address
(normally the primary path; see [RFC4960], Section 6.4 for
details).
A4) 送付者、選択された目的地のRTO値を使用するStart a T-4 Retransmission Timeout(RTO)タイマが記述しなければならない、(通常第一の経路。 見る、[RFC4960]、詳細のためのセクション6.4)
Stewart, et al. Standards Track [Page 18] RFC 5061 SCTP Dynamic Address Reconfiguration September 2007
スチュワート、他 規格はダイナミックなSCTPアドレス再構成2007年9月にRFC5061を追跡します[18ページ]。
A5) When the ASCONF-ACK that acknowledges the Sequence Number last
sent arrives, the sender MUST stop the T-4 RTO timer, and clear
the appropriate association and destination error counters as
defined in [RFC4960], Sections 8.1 and 8.2.
A5) 最後に送られたSequence Numberを承認するASCONF-ACKが到着すると、送付者は、T-4 RTOタイマを止めて、適切な協会をきれいにしなければなりません、そして、目的地誤りは[RFC4960](セクション8.1と8.2)で定義されるように反対します。
A6) The endpoint MUST process all of the TLVs within the ASCONF-
ACK(s) to find out particular status information returned to the
various requests that were sent. Use the Correlation IDs to
correlate the request and the responses.
A6) 終点は、特定の状態情報が送られた様々な要求に戻ったのを見つけるためにASCONF- ACK(s)の中でTLVsのすべてを処理しなければなりません。 Correlation IDを使用して、要求と応答を関連させてください。
A7) If an error response is received for a TLV parameter, all TLVs
with no response before the failed TLV are considered successful
if not reported. All TLVs after the failed response are
considered unsuccessful unless a specific success indication is
present for the parameter.
A7) TLVパラメタのために誤り応答を受けるなら、失敗したTLVの前の応答のないすべてのTLVsをうまくいくと考えるか、または報告します。 特定の成功指示がパラメタのために存在していない場合、失敗した応答の後のすべてのTLVsが失敗していると考えられます。
A8) If there is no response(s) to specific TLV parameter(s), and no
failures are indicated, then all request(s) are considered
successful.
A8) 特定のTLVパラメタへの応答が全くなくて、また失敗が全く示されないなら、すべての要求がうまくいくと考えられます。
A9) If the peer responds to an ASCONF with an ERROR Chunk reporting
that it did not recognize the ASCONF Chunk Type, the sender of
the ASCONF MUST NOT send any further ASCONF Chunks and MUST stop
its T-4 timer.
A9) ERROR Chunkが報告していて同輩がASCONFに応じるなら、それがASCONF Chunk Type、ASCONF MUST NOTの送付者を見分けなかったのが、どんな一層のASCONF Chunksも送って、T-4タイマを止めなければなりません。
If the T-4 RTO timer expires the endpoint MUST do the following:
T-4 RTOタイマが期限が切れるなら、終点は以下をしなければなりません:
B1) Increment the error counters and perform path failure detection
on the appropriate destination address as defined in [RFC4960],
Sections 8.1 and 8.2.
B1) 誤りカウンタを増加してください、そして、[RFC4960](セクション8.1と8.2)で定義されるように適切な送付先アドレスに経路失敗検出を実行してください。
B2) Increment the association error counters and perform endpoint
failure detection on the association as defined in [RFC4960],
Sections 8.1 and 8.2.
B2) 協会誤りカウンタを増加してください、そして、[RFC4960](セクション8.1と8.2)で定義されるように終点失敗検出を協会に実行してください。
B3) Backoff the destination address RTO value to which the ASCONF
chunk was sent by doubling the RTO timer value.
B3) RTOタイマ価値を倍にすることによってASCONF塊がどれであったかに送って、Backoff送付先アドレスRTOは評価します。
Note: The RTO value is used in the setting of all timer types
for SCTP. Each destination address has a single RTO estimate.
以下に注意してください。 RTO値はSCTPにすべてのタイマタイプの設定で使用されます。 それぞれの送付先アドレスには、ただ一つのRTO見積りがあります。
Stewart, et al. Standards Track [Page 19] RFC 5061 SCTP Dynamic Address Reconfiguration September 2007
スチュワート、他 規格はダイナミックなSCTPアドレス再構成2007年9月にRFC5061を追跡します[19ページ]。
B4) Re-transmit the ASCONF Chunk last sent and if possible choose an
alternate destination address (please refer to [RFC4960],
Section 6.4.1). An endpoint MUST NOT add new parameters to this
chunk; it MUST be the same (including its Sequence Number) as
the last ASCONF sent. An endpoint MAY, however, bundle an
additional ASCONF with new ASCONF parameters with the next
Sequence Number. For details, see Section 5.5.
B4) 最後に送られたASCONF Chunkを再送してください、そして、できれば、交互の送付先アドレスを選んでください([RFC4960]、セクション6.4.1を参照してください)。 終点はこの塊に新しいパラメタを加えてはいけません。 それは最後のASCONFが発信したのと同じであるに違いありません(Sequence Numberを含んでいます)。 しかしながら、終点は次のSequence Numberと共に新しいASCONFパラメタがある追加ASCONFを束ねるかもしれません。 詳細に関しては、セクション5.5を見てください。
B5) Restart the T-4 RTO timer. Note that if a different destination
is selected, then the RTO used will be that of the new
destination address.
B5) T-4 RTOタイマを再開してください。 異なった目的地が選択されるなら使用されるRTOが新しい送付先アドレスのものになることに注意してください。
Note: The total number of retransmissions is limited by B2 above. If the maximum is reached, the association will fail and enter into the CLOSED state (see [RFC4960], Section 6.4.1 for details).
以下に注意してください。 「再-トランスミッション」の総数は上のB2によって制限されます。 最大に達していると、協会は、CLOSED状態に失敗して、入るでしょう(詳細に関して[RFC4960]、セクション6.4.1を見てください)。
5.1.1. Congestion Control of ASCONF Chunks
5.1.1. ASCONF塊の輻輳制御
In defining the ASCONF Chunk transfer procedures, it is essential that these transfers MUST NOT cause congestion within the network. To achieve this, we place these restrictions on the transfer of ASCONF Chunks:
ASCONF Chunk転送手順を定義するのにおいて、これらの転送がネットワークの中で混雑を引き起こしてはいけないのは、不可欠です。 これを達成するために、私たちはASCONF Chunksの転送に関してこれらの制限を課します:
C1) One and only one SCTP packet-holding ASCONF Chunk(s) MAY be in
transit and unacknowledged at any one time. If a sender, after
sending an ASCONF chunk, decides it needs to transfer another
ASCONF Chunk, it MUST wait until the ASCONF-ACK Chunk returns
from the previous ASCONF Chunk before sending a subsequent
ASCONF. Note: This restriction binds each side, so at any time,
two ASCONF may be in-transit on any given association (one sent
from each endpoint). However, when an ASCONF Chunk is
retransmitted due to a time-out, the additionally held ASCONF
Chunks can be bundled into the retransmission packet as
described in Section 5.5.
C1) 1パケットを保持する唯一無二のSCTP ASCONF Chunk(s) いかなる時も、トランジットにはあって、認められないかもしれません。 ASCONF塊を送った後に送付者が、別のASCONF Chunkを移すのが必要であると決めるなら、その後のASCONFを送る前にASCONF-ACK Chunkが前のASCONF Chunkから戻るまで、それは待たなければなりません。 以下に注意してください。 この制限がそれぞれの側を縛るので、いつでも、2ASCONFはどんな与えられた協会におけるトランジットであるかもしれません(1つは各終点から発信しました)。 しかしながら、ASCONF Chunkがタイムアウトのため再送されるとき、セクション5.5で説明されるようにさらに、保持されたASCONF Chunksは「再-トランスミッション」パケットに投げ込むことができます。
C2) An ASCONF Chunk may be bundled with any other chunk type
including other ASCONF Chunks. If bundled with other ASCONF
Chunks, the chunks MUST appear in sequential order with respect
to their Sequence Number.
C2) いかなる他の塊タイプも他のASCONF Chunksを入れていて、ASCONF Chunkは束ねられるかもしれません。 他のASCONF Chunksと共に束ねられるなら、塊は連続したオーダーにそれらのSequence Numberに関して現れなければなりません。
C3) An ASCONF-ACK Chunk may be bundled with any other chunk type
including other ASCONF-ACK Chunks. If bundled with other
ASCONF-ACK Chunks, the chunks MUST appear in sequential order
with respect to their Sequence Number.
C3) いかなる他の塊タイプも他のASCONF-ACK Chunksを入れていて、ASCONF-ACK Chunkは束ねられるかもしれません。 他のASCONF-ACK Chunksと共に束ねられるなら、塊は連続したオーダーにそれらのSequence Numberに関して現れなければなりません。
Stewart, et al. Standards Track [Page 20] RFC 5061 SCTP Dynamic Address Reconfiguration September 2007
スチュワート、他 規格はダイナミックなSCTPアドレス再構成2007年9月にRFC5061を追跡します[20ページ]。
C4) Both ASCONF and ASCONF-ACK Chunks MUST NOT be sent in any SCTP
state except ESTABLISHED, SHUTDOWN-PENDING, SHUTDOWN-RECEIVED,
and SHUTDOWN-SENT.
C4) ESTABLISHED、SHUTDOWN-PENDING、SHUTDOWN-RECEIVED、およびSHUTDOWN-SENT以外のどんなSCTP状態でもASCONFとASCONF-ACK Chunksの両方を送ってはいけません。
C5) An ASCONF Chunk and an ASCONF-ACK Chunk SHOULD not be larger
than the PMTU. If the PMTU is unknown, then the PMTU should be
set to the minimum PMTU. The minimum PMTU depends on the IP
version used for transmission, and is the lesser of 576 octets
and the first-hop MTU for IPv4 [RFC1122] and 1280 octets for
IPv6 [RFC2460].
C5) ASCONF ChunkとASCONF-ACK Chunk SHOULD、PMTUより大きくいてください。 PMTUが未知であるなら、PMTUは最小のPMTUに用意ができるべきです。 最小のPMTUはトランスミッションに使用されるIPバージョンによって、IPv4[RFC1122]と1280の八重奏には、576の八重奏と最初に、ホップMTUではIPv6[RFC2460]のために、より少ないです。
An ASCONF sender without these restrictions could possibly flood the network with a large number of separate address-change operations, thus causing network congestion.
これらの制限のないASCONF送付者は多くの別々のアドレス変化操作でネットワークをあふれさせることができました、その結果、ネットワークの混雑を引き起こします。
If the sender of an ASCONF Chunk receives an Operational Error indicating that the ASCONF Chunk Type is not understood, then the sender MUST NOT send subsequent ASCONF Chunks to the peer. The endpoint should also inform the upper-layer application that the peer endpoint does not support any of the extensions detailed in this document.
ASCONF Chunkの送付者がASCONF Chunk Typeが理解されていないのを示すOperational Errorを受け取るなら、送付者はその後のASCONF Chunksを同輩に送ってはいけません。 また、終点は、同輩終点がこのドキュメントで詳細な拡大のいずれも支持しないことを上側の層のアプリケーションに知らせるべきです。
5.2. Upon Reception of an ASCONF Chunk
5.2. ASCONF塊のレセプションに関して
When an endpoint receives an ASCONF Chunk from the remote peer, special procedures may be needed to identify the association the ASCONF Chunk is associated with. To properly find the association, the following procedures SHOULD be followed:
終点がリモート同輩からASCONF Chunkを受けるとき、特別な手順が、ASCONF Chunkが関連している協会を特定するのに必要であるかもしれません。 協会、以下の手順SHOULDが続かれているのが適切にわかるために:
D1) Use the source address and port number of the sender to attempt
to identify the association (i.e., use the same method defined
in [RFC4960] used for all other SCTP Chunks). If found proceed
to rule D4.
D1) 送付者のソースアドレスとポートナンバーを使用して、協会(すなわち、他のすべてのSCTP Chunksに使用される[RFC4960]で定義された同じ方法を使用する)を特定するのを試みてください。 見つけられるなら、D4を統治しかけてください。
D2) If the association is not found, use the address found in the
Address Parameter TLV combined with the port number found in the
SCTP common header. If found, proceed to rule D4.
D2) 協会が見つけられないなら、SCTPの一般的なヘッダーで見つけられるポートナンバーに結合されたAddress Parameter TLVで見つけられたアドレスを使用してください。 見つけられるなら、D4を統治しかけてください。
D2-ext) If more than one ASCONF Chunks are packed together, use the
address found in the ASCONF Address Parameter TLV of each of
the subsequent ASCONF Chunks. If found, proceed to rule D4.
D2-ext) 1ASCONF Chunksがぎっしり詰められるなら、それぞれのその後のASCONF ChunksのASCONF Address Parameter TLVで見つけられたアドレスを使用してください。 見つけられるなら、D4を統治しかけてください。
Stewart, et al. Standards Track [Page 21] RFC 5061 SCTP Dynamic Address Reconfiguration September 2007
スチュワート、他 規格はダイナミックなSCTPアドレス再構成2007年9月にRFC5061を追跡します[21ページ]。
D3) If neither D1, D2, nor D2-ext locates the association, treat the
chunk as an Out Of The Blue packet as defined in [RFC4960].
D3) どちらのD1、D2、およびD2-extが協会の場所を見つけるなら、Out Ofとして塊を扱ってください。[RFC4960]の定義されるとしてのBlueパケット。
D4) Follow the normal rules to validate the SCTP verification tag
found in [RFC4960].
D4) 正常な規則に従って、[RFC4960]で見つけられたSCTP検証タグを有効にしてください。
D5) After the verification tag has been validated, normal chunk
processing should occur. Prior to finding the ASCONF chunk, the
receiver MUST encounter an AUTH chunk as described in [RFC4895].
If either authentication fails, or the AUTH chunk is missing,
the receiver MUST silently discard this chunk and the rest of
the packet.
D5) 検証タグが有効にされた後に、通常の塊処理は起こるべきです。 ASCONF塊を見つける前に、受信機は[RFC4895]で説明されるようにAUTH塊に遭遇しなければなりません。 認証が失敗するか、またはAUTH塊がなくなるなら、受信機は静かにこの塊とパケットの残りを捨てなければなりません。
After identification and verification of the association, the following should be performed to properly process the ASCONF Chunk:
協会の識別と検証の後に、以下は適切にASCONF Chunkを処理するために実行されるべきです:
E1) If the value found in the Sequence Number of the ASCONF Chunk is
equal to the ('Peer-Sequence-Number' + 1) and the Sequence
Number of the ASCONF Chunk is the first in the SCTP Packet, the
endpoint MAY clean any old cached ASCONF-ACK up to the 'Peer-
Sequence-Number' and then proceed to rule E4.
1E) 値がASCONF ChunkのSequence Numberが等しいコネを見つけた、('同輩系列番号'+1)とASCONF ChunkのSequence NumberがSCTP Packetで1番目であり、終点は、どんな古いキャッシュされたASCONF-ACKも'同輩系列番号'まで掃除して、次に、E4を統治しかけるかもしれません。
E1-ext) If the value found in the Sequence Number of the ASCONF
Chunk is equal to the ('Peer-Sequence-Number' + 1) and the
ASCONF chunk is NOT the first Sequence Number in the SCTP
packet, proceed to rule E4 but do NOT clear any cached
ASCONF- ACK or state information.
E1-ext) 値がASCONF ChunkのSequence Numberが等しいコネを見つけた、('同輩系列番号'+1)とASCONF塊は、SCTPパケットにおける最初のSequence Numberではありませんが、4Eを統治しかけますが、少しのキャッシュされたASCONF- ACKや州の情報もきれいにしません。
E2) If the value found in the Sequence Number is less than the
('Peer- Sequence-Number' + 1), simply skip to the next ASCONF,
and include in the outbound response packet any previously
cached ASCONF-ACK response that was sent and saved that matches
the Sequence Number of the ASCONF. Note: It is possible that no
cached ASCONF-ACK Chunk exists. This will occur when an older
ASCONF arrives out of order. In such a case, the receiver
should skip the ASCONF Chunk and not include ASCONF-ACK Chunk
for that chunk.
2E) Sequence Numberで見つけられた値が、より少ない、('同輩系列番号'+1) 単に次のASCONFまでスキップして、外国行きの応答パケットで送られたあらゆる以前にキャッシュされたASCONF-ACK応答を含めてください。そうすれば、救われて、それはASCONFのSequence Numberに合っています。 以下に注意してください。 どんなキャッシュされたASCONF-ACK Chunkも存在しないのは、可能です。 より古いASCONFが故障していた状態で到着すると、これは起こるでしょう。 このような場合には、受信機は、ASCONF Chunkをスキップして、その塊のためのASCONF-ACK Chunkを含んでいるはずがありません。
E3) Then, process each ASCONF one by one as above while the Sequence
Number of the ASCONF is less than the ('Peer-Sequence-Number' +
1).
3E) 次に、ASCONFのSequence Numberが、より少ない間、上として各ASCONFをひとつずつ処理してください、('同輩系列番号'+1。)
Stewart, et al. Standards Track [Page 22] RFC 5061 SCTP Dynamic Address Reconfiguration September 2007
スチュワート、他 規格はダイナミックなSCTPアドレス再構成2007年9月にRFC5061を追跡します[22ページ]。
E4) When the Sequence Number matches the next one expected, process
the ASCONF as described below and after processing the ASCONF
Chunk, append an ASCONF-ACK Chunk to the response packet and
cache a copy of it (in the event it later needs to be
retransmitted).
4E) Sequence Numberが期待された次のものに合っていたら処理してASCONF Chunkを処理した後に説明されるようにASCONFを処理してください、そして、応答パケットにASCONF-ACK Chunkを追加してください、そして、それ(それが後で再送されるために必要とする出来事における)のコピーをキャッシュしてください。
V1) Process the TLVs contained within the Chunk performing the
appropriate actions as indicated by each TLV type. The
TLVs MUST be processed in order within the Chunk. For
example, if the sender puts 3 TLVs in one chunk, the first
TLV (the one closest to the Chunk Header) in the Chunk MUST
be processed first. The next TLV in the chunk (the middle
one) MUST be processed second and finally, the last TLV in
the Chunk MUST be processed last.
V1) それぞれのTLVタイプによって示されるように適切な行動を実行するChunkの中に含まれたTLVsを処理してください。 Chunkの中で整然とした状態でTLVsを処理しなければなりません。 例えば、最初のTLV、送付者が1つの塊に3TLVsを入れるなら(もの、Chunk Header) コネの最も近くに、最初に、Chunkを処理しなければなりません。 塊(中くらいのもの)における次のTLV 2番目に、処理しなければならなくて、最終的に、最後にChunkにおける最後のTLVを処理しなければなりません。
V2) In processing the chunk, the receiver should build a
response message with the appropriate error TLVs, as
specified in the Parameter type bits, for any ASCONF
Parameter it does not understand. To indicate an
unrecognized parameter, Cause Type 8 should be used as
defined in the ERROR in Section 3.3.10.8, [RFC4960]. The
endpoint may also use the response to carry rejections for
other reasons, such as resource shortages, etc., using the
Error Cause TLV and an appropriate error condition.
V2) 塊を処理する際に、受信機は適切な誤りTLVsと共に応答メッセージを築き上げるはずです、Parameterタイプビットで指定されるように、それがするどんなASCONF Parameterも分からないので。 認識されていないパラメタを示すために、セクション3.3.10で.8、[RFC4960]をERRORで定義するとき、Cause Type8は使用されるべきです。 また、終点は他の理由で拒絶を運ぶのに応答を使用するかもしれません、リソース不足などのように、Error Cause TLVと適切なエラー条件を使用して。
Note: A positive response is implied if no error is indicated by
the sender.
以下に注意してください。 誤りが全く送付者によって示されないなら、積極的な応答は含意されます。
V3) All responses MUST copy the ASCONF-Request Correlation ID
field received in the ASCONF parameter from the TLV being
responded to, into the ASCONF-Request Correlation ID field
in the response parameter.
V3) すべての応答がASCONFパラメタに応じるTLVから受け取られたASCONF-要求Correlation ID野原をコピーしなければなりません、応答パラメタのASCONF-要求Correlation ID分野に。
V4) After processing the entire Chunk, the receiver of the
ASCONF MUST queue the response ASCONF-ACK Chunk for
transmission after the rest of the SCTP packet has been
processed. This allows the ASCONF-ACK Chunk to be bundled
with other ASCONF-ACK Chunks as well as any additional
responses, e.g., a Selective Acknowledgment (SACK) Chunk.
V4) SCTPパケットの残りが全体のChunkが処理された後に、ASCONF MUSTの受信機はトランスミッションのために次々と応答ASCONF-ACK Chunkを列に並ばせます。 これは、ASCONF-ACK Chunkがどんな追加応答と同様に他のASCONF-ACK Chunksと共に束ねられるのを許容します、例えば、Selective Acknowledgment(SACK) 塊。
V5) Update the 'Peer-Sequence-Number' to the value found in the
Sequence Number field.
V5) '同輩系列番号'をSequence Number野原で発見される値にアップデートしてください。
Stewart, et al. Standards Track [Page 23] RFC 5061 SCTP Dynamic Address Reconfiguration September 2007
スチュワート、他 規格はダイナミックなSCTPアドレス再構成2007年9月にRFC5061を追跡します[23ページ]。
E5) Otherwise, the ASCONF Chunk is discarded since it must be either
a stale packet or from an attacker. A receiver of such a packet
MAY log the event for security purposes.
5E) さもなければ、ASCONF Chunkは、聞き古したパケットか攻撃者から来ているに違いないので、捨てられます。 そのようなパケットの受信機はセキュリティ目的のために出来事を登録するかもしれません。
E6) When all ASCONF Chunks are processed for this SCTP packet, send
back the accumulated single response packet with all of the
ASCONF-ACK Chunks. The destination address of the SCTP packet
containing the ASCONF-ACK Chunks MUST be the source address of
the SCTP packet that held the ASCONF Chunks.
6E) すべてのASCONF ChunksがこのSCTPパケットのために処理されたら、ASCONF-ACK Chunksのすべてで蓄積された単一の応答パケットを返送してください。 ASCONF-ACK Chunksを含むSCTPパケットの送付先アドレスはASCONF Chunksを持っていたSCTPパケットのソースアドレスであるに違いありません。
E7) While processing the ASCONF Chunks in the SCTP packet, if the
response packet will exceed the PMTU of the return path, the
receiver MUST stop adding additional ASCONF-ACKs into the
response packet but MUST continue to process all of the ASCONF
Chunks, saving ASCONF-ACK Chunk responses in its cached copy.
The sender of the ASCONF Chunk will later retransmit the ASCONF
Chunks that were not responded to, at which time the cached
copies of the responses that would NOT fit in the PMTU can be
sent to the peer.
7E) 応答パケットがリターンパスのPMTUを超えるならSCTPパケットでASCONF Chunksを処理している間、受信機は、応答パケットに追加ASCONF-ACKsを加えるのを止めなければなりませんが、ASCONF Chunksのすべてを処理し続けなければなりません、キャッシュされたコピーにおける応答をASCONF-ACK Chunkに救って。 ASCONF Chunkの送付者は後でどの時にPMTUをうまくはめ込まない応答のキャッシュされたコピーを同輩に送ることができるかとき応じなかったASCONF Chunksを再送するでしょう。
Note: These rules have been presented with the assumption that the implementation is caching old ASCONF-ACKs in case of loss of SCTP packets in the ACK path. It is allowable for an implementation to maintain this state in another form it deems appropriate, as long as that form results in the same ASCONF-ACK sequences being returned to the peer as outlined above.
以下に注意してください。 実現がACK経路のSCTPパケットの損失の場合に古いASCONF-ACKsをキャッシュしているという仮定をこれらの規則に与えました。 実現がそれが考える別のフォームでのこの状態を適切に維持するのは、許容できます、そのフォームが上に概説されているように同輩に返される同じASCONF-ACK系列をもたらす限り。
5.3. General Rules for Address Manipulation
5.3. アドレス操作のための総則
When building TLV parameters for the ASCONF Chunk that will add or delete IP addresses, the following rules MUST be applied:
IPアドレスを加えるか、または削除するASCONF ChunkのためのパラメタをTLVに築き上げるとき、以下の規則を適用しなければなりません:
F0) If an endpoint receives an ASCONF-ACK that is greater than or
equal to the next Sequence Number to be used but no ASCONF Chunk
is outstanding, the endpoint MUST ABORT the association. Note
that a Sequence Number is greater than if it is no more than
2^^31-1 larger than the current Sequence Number (using serial
arithmetic).
F0) 終点がASCONF-ACKを受けるなら、すなわち、次の使用されるべきSequence Numberにもかかわらず、どんなASCONF Chunkもより傑出していなくて、終点MUST ABORTは協会です。 Sequence Numberが、よりすばらしいことに注意してください、それが現在のSequence Numberより大きい2^^31-1であるだけである(連続の演算を使用して)なら。
F1) When adding an IP address to an association, the IP address is
NOT considered fully added to the association until the ASCONF-
ACK arrives. This means that until such time as the ASCONF
containing the add is acknowledged, the sender MUST NOT use the
new IP address as a source for ANY SCTP packet except on
carrying an ASCONF Chunk. The receiver of the Add IP Address
F1) IPアドレスを協会に追加するとき、IPアドレスはASCONF- ACKが到着するまで協会に完全に追加されていると考えられません。 これがASCONF含有のような時間までそれを意味する、付加、承認されていて、送付者はANY SCTPパケットASCONF Chunkを運ぶ上のソースとして新しいIPアドレスを使用してはいけません。 Add IP Addressの受信機
Stewart, et al. Standards Track [Page 24] RFC 5061 SCTP Dynamic Address Reconfiguration September 2007
スチュワート、他 規格はダイナミックなSCTPアドレス再構成2007年9月にRFC5061を追跡します[24ページ]。
request may use the address as a destination immediately. The
receiver MUST use the path-verification procedure for the added
address before using that address. The receiver MUST NOT send
packets to the new address except for the corresponding ASCONF-
ACK Chunk or HEARTBEAT Chunks for path verification before the
new path is verified. If the ASCONF-ACK is sent to the new
address, it MAY be bundled with the HEARTBEAT chunk for path
verification.
要求はすぐに、目的地としてアドレスを使用するかもしれません。 そのアドレスを使用する前に、受信機は加えられたアドレスに経路検証手続を使用しなければなりません。 新しい経路が確かめられる前に受信機は経路検証のための対応するASCONF- ACK ChunkかHEARTBEAT Chunks以外の新しいアドレスにパケットを送ってはいけません。 新しいアドレスにASCONF-ACKを送るなら、経路検証のためにHEARTBEAT塊でそれを束ねるかもしれません。
F2) After the ASCONF-ACK of an IP address Add arrives, the endpoint
MAY begin using the added IP address as a source address for any
type of SCTP chunk.
F2) IPアドレスAddのASCONF-ACKが到着した後に、終点は、どんなタイプのSCTP塊にもソースアドレスとして加えられたIPアドレスを使用し始めるかもしれません。
F3a) If an endpoint receives an Error Cause TLV indicating that the
IP address Add or IP address Deletion parameters was not
understood, the endpoint MUST consider the operation failed and
MUST NOT attempt to send any subsequent Add or Delete requests
to the peer.
F3a) 終点がIPアドレスAddかIPアドレスDeletionパラメタが理解されていなかったのを示すError Cause TLVを受けるなら、終点は、操作が失敗されていると考えなければならなくて、どんなその後のAddやDelete要求も同輩に送るのを試みてはいけません。
F3b) If an endpoint receives an Error Cause TLV indicating that the
IP address Set Primary IP Address parameter was not understood,
the endpoint MUST consider the operation failed and MUST NOT
attempt to send any subsequent Set Primary IP Address requests
to the peer.
F3b) 終点がIPアドレスSet Primary IP Addressパラメタが理解されていなかったのを示すError Cause TLVを受けるなら、終点は、操作が失敗されていると考えなければならなくて、どんなその後のSet Primary IP Address要求も同輩に送るのを試みてはいけません。
F4) When deleting an IP address from an association, the IP address
MUST be considered a valid destination address for the reception
of SCTP packets until the ASCONF-ACK arrives and MUST NOT be
used as a source address for any subsequent packets. This means
that any datagrams that arrive before the ASCONF-ACK destined to
the IP address being deleted MUST be considered part of the
current association. One special consideration is that ABORT
Chunks arriving destined to the IP address being deleted MUST be
ignored (see Section 5.3.1 for further details).
F4) 協会からIPアドレスを削除するとき、IPアドレスは、ASCONF-ACKが到着するまでSCTPパケットのレセプションのための有効な送付先アドレスであると考えなければならなくて、どんなその後のパケットにもソースアドレスとして使用されてはいけません。 これは、現在の協会の一部であるとASCONF-ACKが削除されるIPアドレスに運命づける前に届くどんなデータグラムも考えなければならないことを意味します。 1つの特別の配慮は削除されるIPアドレスに運命づけられたABORT Chunks到着を無視しなければならないという(さらに詳しい明細についてはセクション5.3.1を見てください)ことです。
F5) An endpoint MUST NOT delete its last remaining IP address from
an association. In other words, if an endpoint is NOT multi-
homed, it MUST NOT use the delete IP address without an Add IP
Address preceding the delete parameter in the ASCONF Chunk. Or,
if an endpoint sends multiple requests to delete IP addresses,
it MUST NOT delete all of the IP addresses that the peer has
listed for the requester.
F5) 終点は、最後に協会からIPアドレスのままで残っているのを削除してはいけません。 言い換えれば、終点がそうでない、マルチ、家へ帰り、使用してはいけない、Add IP Addressが先行しないでIPアドレスを削除してください、ASCONF Chunkのパラメタを削除してください。 または、終点がIPアドレスを削除するという複数の要求を送るなら、それは同輩がリクエスタのために記載したIPアドレスのすべてを削除してはいけません。
Stewart, et al. Standards Track [Page 25] RFC 5061 SCTP Dynamic Address Reconfiguration September 2007
スチュワート、他 規格はダイナミックなSCTPアドレス再構成2007年9月にRFC5061を追跡します[25ページ]。
F6) An endpoint MUST NOT set an IP header source address for an SCTP
packet holding the ASCONF Chunk to be the same as an address
being deleted by the ASCONF Chunk.
F6) 終点はASCONF ChunkがASCONF Chunkによって削除されるアドレスと同じであると主張するSCTPパケットのためのIPヘッダーソースアドレスを設定してはいけません。
F7) If a request is received to delete the last remaining IP address
of a peer endpoint, the receiver MUST send an Error Cause TLV
with the Error Cause set to the new error code 'Request to
Delete Last Remaining IP Address'. The requested delete MUST
NOT be performed or acted upon, other than to send the ASCONF-
ACK.
F7) 同輩終点の最後の残っているIPアドレスを削除するために要求を受け取るなら、受信機は新しいエラーコード'Delete Last Remaining IP Addressへの要求'にError CauseセットがあるError Cause TLVを送らなければなりません。 実行されてはいけないか、またはASCONF- ACKを送るのを除いて、作用されて、要求は削除します。
F8) If a request is received to delete an IP address that is also
the source address of the IP packet that contained the ASCONF
chunk, the receiver MUST reject this request. To reject the
request, the receiver MUST send an Error Cause TLV set to the
new error code 'Request to Delete Source IP Address' (unless
Rule F5 has also been violated, in which case the error code
'Request to Delete Last Remaining IP Address' is sent).
F8) またASCONF塊を含んだIPパケットのソースアドレスであるIPアドレスを削除するために要求を受け取るなら、受信機はこの要求を拒絶しなければなりません。 要求を拒絶するために、受信機は新しいエラーコード'Delete Source IP Addressへの要求'にError Cause TLVセットを送らなければなりません(また、Rule F5に違反していない場合、その場合、エラーコード'Delete Last Remaining IP Addressへの要求'を送ります)。
F9) If an endpoint receives an ADD IP Address request and does not
have the local resources to add this new address to the
association, it MUST return an Error Cause TLV set to the new
error code 'Operation Refused Due to Resource Shortage'.
F9) 終点がADD IP Address要求を受け取って、この新しいアドレスを協会に追加するローカル資源を持っていないなら、それは新しいエラーコード'Resource Shortageへの操作Refused Due'にError Cause TLVセットを返さなければなりません。
F10) If an endpoint receives an 'Out of Resource' error in response
to its request to ADD an IP address to an association, it must
either ABORT the association or not consider the address part of
the association. In other words, if the endpoint does not ABORT
the association, it must consider the add attempt failed and NOT
use this address since its peer will treat SCTP packets destined
to the address as Out Of The Blue packets.
F10) 終点が受信される、'Resource'誤りからの要求に対応したADDへのIPアドレス、協会にそうしなければならない、ABORT、協会であるか否かに関係なく、協会のアドレス部を考えてください。 言い換えれば、終点がどんなABORTにも協会をしないなら、考えなければならない、試みが失敗して、同輩がSCTPパケットを扱うのでこれが記述するNOT使用がOut OfとしてBlueパケットをアドレスに運命づけたと言い足してください。
F11) When an endpoint receives an ASCONF to add an IP address sends
an 'Out of Resource' in its response, it MUST also fail any
subsequent add or delete requests bundled in the ASCONF. The
receiver MUST NOT reject an ADD and then accept a subsequent
DELETE of an IP address in the same ASCONF Chunk. In other
words, once a receiver begins failing any ADD or DELETE request,
it must fail all subsequent ADD or DELETE requests contained in
that single ASCONF.
F11) また、終点がIPアドレスが応答における'Resource'を送ると言い足すためにASCONFを受けるときいずれにも失敗しなければならない、その後、ASCONFに束ねられた要求を、加えるか、または削除してください。 受信機は、ADDを拒絶して、次に、同じASCONF ChunkのIPアドレスのその後のDELETEを受け入れてはいけません。 言い換えれば、受信機がいったんどんなADDやDELETEも要求する失敗を始めると、それはその独身のASCONFに含まれたすべてのその後のADDかDELETE要求に失敗しなければなりません。
Stewart, et al. Standards Track [Page 26] RFC 5061 SCTP Dynamic Address Reconfiguration September 2007
スチュワート、他 規格はダイナミックなSCTPアドレス再構成2007年9月にRFC5061を追跡します[26ページ]。
F12) When an endpoint receives a request to delete an IP address that
is the current primary address, it is an implementation decision
as to how that endpoint chooses the new primary address.
F12) 終点が現在の第一のアドレスであるIPアドレスを削除するという要求を受け取るとき、それはその終点がどう新しい第一のアドレスを選ぶかに関する実現決定です。
F13) When an endpoint receives a valid request to DELETE an IP
address, the endpoint MUST consider the address no longer part
of the association. It MUST NOT send SCTP packets for the
association to that address and it MUST treat subsequent packets
received from that address as Out Of The Blue.
F13) 終点が有効な要求をDELETEに受け取るとき、IPアドレス、終点は、アドレスがもう協会の一部であると考えなければなりません。 それはそのアドレスへの協会のためにパケットをSCTPに送ってはいけません、そして、そのアドレスから受け取られたその後のパケットをOut Of Blueとして扱わなければなりません。
During the time interval between sending out the ASCONF and
receiving the ASCONF-ACK, it MAY be possible to receive DATA
Chunks out of order. The following examples illustrate these
problems:
ASCONFを出して、ASCONF-ACKを受けるところの時間間隔の間、故障していた状態でDATA Chunksを受け取るのは可能であるかもしれません。 以下の例はこれらの問題を例証します:
F14) All addresses added by the reception of an ASCONF Chunk MUST be
put into the UNCONFIRMED state and MUST have path verification
performed on them before the address can be used as described in
[RFC4960], Section 5.4.
F14) ASCONF Chunkのレセプションによって加えられたすべてのアドレスで、[RFC4960](セクション5.4)で説明されるようにUNCONFIRMED状態に入れなければならなくて、アドレスを使用できる前に経路検証をそれらに実行しなければなりません。
Endpoint-A Endpoint-Z
---------- ----------
ASCONF[Add-IP:X]------------------------------>
/--ASCONF-ACK
/
/--------/---New DATA:
/ / Destination
<-------------------/ / IP:X
/
<--------------------------/
終点A終点Z---------- ---------- ASCONF、[IPを加えます:、X]------------------------------>/--ASCONF-ACK//--------/---新しいデータ: //目的地<。-------------------: //IP X/<。--------------------------/
In the above example, we see a new IP address (X) being added to the Endpoint-A. However, due to packet re-ordering in the network, a new DATA chunk is sent and arrives at Endpoint-A before the ASCONF-ACK confirms the add of the address to the association.
上記の例では、私たちは、新しいIPアドレス(X)がEndpoint-Aに加えられているのを見ます。 しかしながら、新しいDATA塊がネットワークで再注文されるパケットのため、ASCONF-ACKの前で送られて、Endpoint-Aに到着する、確認、アドレスを協会に追加してください。
Stewart, et al. Standards Track [Page 27] RFC 5061 SCTP Dynamic Address Reconfiguration September 2007
スチュワート、他 規格はダイナミックなSCTPアドレス再構成2007年9月にRFC5061を追跡します[27ページ]。
A similar problem exists with the deletion of an IP address as follows:
IPアドレスの削除は以下の通りで同様の問題は存在しています:
Endpoint-A Endpoint-Z
---------- ----------
/------------New DATA:
/ Destination
/ IP:X
ASCONF [DEL-IP:X]---------/---------------->
<-----------------/------------------ASCONF-ACK
/
/
<-------------/
終点A終点Z---------- ---------- /------------新しいデータ: /目的地/IP: X ASCONF[DEL-IP: X]---------/----------------><。-----------------/------------------ASCONF-ACK//<。-------------/
In this example, we see a DATA chunk destined to the IP:X (which is about to be deleted) arriving after the deletion is complete. For the ADD case, an endpoint SHOULD consider the newly added IP address for the purpose of sending data to the association before the ASCONF- ACK has been received. The endpoint MUST NOT source data from this new address until the ASCONF-ACK arrives, but it may receive out-of- order data as illustrated and MUST NOT treat this data as an OOTB datagram (please see [RFC4960] section 8.4). It MAY drop the data silently or it MAY consider it part of the association, but it MUST NOT respond with an ABORT.
この例では、私たちは、DATA塊がIPに運命づけられているのを見ます: 削除が完全になった後に到着するX(削除されようとしています)。 ADDケースにおいて、SHOULDがASCONF- ACKの前の協会にデータを送る目的のための新たに加えられたIPアドレスであると考える終点を受け取りました。 ASCONF-ACKが到着するまで終点がこの新しいアドレスからのデータの出典を明示してはいけませんが、外で受信するかもしれない、-、-例証して、OOTBデータグラムとしてこのデータを扱ってはいけないとき、データを注文してください([RFC4960]セクション8.4を見てください)。 それは静かにデータを落としてはいけないかもしれませんか、それが協会の一部であると考えるかもしれませんが、それはABORTと共に応じてはいけません。
For the DELETE case, an endpoint MAY respond to the late-arriving DATA packet as an OOTB datagram or it MAY hold the deleting IP address for a small period of time as still valid. If it treats the DATA packet as OOTB, the peer will silently discard the ABORT (since by the time the ABORT is sent, the peer will have removed the IP address from this association). If the endpoint elects to hold the IP address valid for a period of time, it MUST NOT hold it valid longer than 2 RTO intervals for the destination being removed.
DELETEケースのために、小さい期間の間まだ有効であるとして削除がIPアドレスであることを維持するとき、終点は遅く到着しているDATAパケットに応じるかもしれません。 DATAパケットをOOTBとして扱うと、同輩は静かにABORTを捨てるでしょう(同輩がABORTを送る時までにこの協会からIPアドレスを取り除いてしまうだろうので)。 終点が、しばらくIPアドレスを有効であるとして保持するのを選ぶなら、それは取り除かれる目的地への2回のRTO間隔より長い間、有効にそれを保ってはいけません。
Stewart, et al. Standards Track [Page 28] RFC 5061 SCTP Dynamic Address Reconfiguration September 2007
スチュワート、他 規格はダイナミックなSCTPアドレス再構成2007年9月にRFC5061を追跡します[28ページ]。
5.3.1. A Special Case for OOTB ABORT Chunks
5.3.1. OOTBアボート塊のための特別なケース
Another case worth mentioning is illustrated below:
言及する価値がある別のケースは以下で例証されます:
Endpoint-A Endpoint-Z
---------- ----------
終点A終点Z---------- ----------
New DATA:------------\
Source IP:X \
\
ASCONF-REQ[DEL-IP:X]----\------------------>
\ /---------ASCONF-ACK
\ /
\----/-----------> OOTB
(Ignored <---------------------/-------------ABORT
by rule F4) /
<---------------------/
新しいデータ:------------\ソースIP: X\\ASCONF-REQ[DEL-IP: X]----\------------------>\/---------ASCONF-ACK\/\----/-----------> OOTB (Ignored <---------------------/-------------ABORT by rule F4) / <---------------------/
For this case, during the deletion of an IP address, an Abort MUST be ignored if the destination address of the Abort message is that of a destination being deleted.
このような場合、IPアドレスの削除の間、Abortメッセージの送付先アドレスがそれであるなら削除される目的地についてAbortを無視しなければなりません。
5.3.2. A Special Case for Changing an Address
5.3.2. アドレスを変えるための特別なケース
In some instances, the sender may only have one IP address in an association that is being renumbered. When this occurs, the sender may not be able to send the appropriate ADD/DELETE pair to the peer, and may use the old address as a source in the IP header. For this reason, the sender MUST fill in the Address Parameter field with an address that is part of the association (in this case, the one being deleted). This will allow the receiver to locate the association without using the source address found in the IP header.
ある場合に、送付者には、1つのIPアドレスしか番号を付け替えられている協会でないかもしれません。 これが起こると、送付者は、適切なADD/DELETE組を同輩に送ることができないで、IPヘッダーというソースとして旧住所を使用するかもしれません。 この理由で、送付者は協会(この場合削除されるもの)の一部であるアドレスでAddress Parameter分野に記入しなければなりません。 これで、IPヘッダーで見つけられたソースアドレスを使用しないで、受信機は協会の場所を見つけることができるでしょう。
The receiver of such a chunk MUST always first use the source address found in the IP header in looking up the association. The receiver should attempt to use the address found in the Address Parameter field only if the lookup using the source address from the IP header fails. The receiver MUST reply to the source address of the packet in this case, which is the new address that was added by the ASCONF (since the old address is no longer part of the association after processing).
そのような塊の受信機は最初に、いつもIPヘッダーで協会を見上げる際に見つけられたソースアドレスを使用しなければなりません。 受信機は、IPヘッダーからのソースアドレスを使用するルックアップが失敗する場合にだけAddress Parameter野原で発見されるアドレスを使用するのを試みるはずです。 受信機はこの場合、パケットのソースアドレスに答えなければなりません(旧住所がもう処理の後の協会の一部でないので)。(それは、ASCONFによって加えられた新しいアドレスです)。
5.4. Setting of the Primary Address
5.4. 第一のアドレスの設定
A sender of the set primary parameter MAY elect to send this combined with an add or delete of an address. A sender MUST only send a set primary request to an address that is already considered part of the association. In other words, if a sender combines a set primary with
これを送るためには5月の次期の第一のパラメタが結合したセットの送付者、アドレスの加えるか、削除 送付者は協会の一部であると既に考えられるアドレスにセットの第一の要求を送るだけでよいです。 言い換えれば、送付者が結合するなら、aは第一でセットしました。
Stewart, et al. Standards Track [Page 29] RFC 5061 SCTP Dynamic Address Reconfiguration September 2007
スチュワート、他 規格はダイナミックなSCTPアドレス再構成2007年9月にRFC5061を追跡します[29ページ]。
an add new IP address request, the set primary will be discarded unless the add request is to be processed BEFORE the set primary (i.e., it precedes the set primary).
新しいIPアドレス要求、セット予備選挙が捨てられると言い足してください、処理BEFOREが設定予備選挙であったなら要求があると言い足してください(すなわち、それはセット予備選挙に先行します)。
A request to set primary MAY also appear in an INIT or INIT-ACK chunk, which can give advice to the peer endpoint as to which of its addresses the sender of the INIT or INIT-ACK would prefer as the primary address.
また、予備選挙を設定するという要求はINITかINIT-ACK塊に現れるかもしれません。(INITかINIT-ACKの送付者が第一のアドレスとしてアドレスのどれを好むだろうかに関してそれは、同輩終点にアドバイスできます)。
The request to set an address as the primary path is an option the receiver SHOULD perform. It is considered advice to the receiver of the best-destination address to use in sending SCTP packets (in the requester's view). If a request arrives that asks the receiver to set an address as primary that does not exist, the receiver SHOULD NOT honor the request, leaving its existing primary address unchanged.
第一の経路としてアドレスを設定するという要求は受信機SHOULDが実行するオプションです。 それは送付SCTPパケット(リクエスタの意見における)で使用する最も良い送付先アドレスの受信機へのアドバイスであると考えられます。 存在しない第一の同じくらいアドレスを設定するように受信機に頼む要求が到着するなら、受信機SHOULD NOTは要求を光栄に思います、第一のアドレスに存在を変わりがないままにして。
5.5. Bundling of Multiple ASCONFs
5.5. 複数のASCONFsのバンドリング
In the normal case, a single ASCONF is sent in a packet and a single reply ASCONF-ACK is received. However, in the event of the loss of an SCTP packet containing either an ASCONF or ASCONF-ACK, it is allowable for a sender to bundle additional ASCONFs in the retransmission. In bundling multiple ASCONFs, the following rules MUST be followed:
正常な場合では、パケットで独身のASCONFを送ります、そして、独身の回答ASCONF-ACKは受け取られています。 しかしながら、SCTPパケットの損失がASCONFかASCONF-ACKのどちらかを含む場合、送付者が「再-トランスミッション」に追加ASCONFsを束ねるのは、許容できます。 複数のASCONFsを束ねる際に、以下の規則に従わなければなりません:
1. Previously transmitted ASCONF Chunks MUST be left unchanged.
1. 以前伝えられたASCONF Chunksを変わりがないままにしなければなりません。
2. Each SCTP packet containing ASCONF Chunks MUST be bundled
starting with the smallest ASCONF Sequence Number first in the
packet (closest to the Chunk header) and preceding in sequential
order from the lowest to highest ASCONF Sequence Number.
2. 最初に、パケット(Chunkヘッダーについて最も近い)で最も小さいASCONF Sequence Numberから始まって、連続した最も低いASCONF Sequence Numberから最も高いASCONF Sequence Numberまでのオーダーで先行して、ASCONF Chunksを含むそれぞれのSCTPパケットを束ねなければなりません。
3. All ASCONFs within the packet MUST be adjacent to each other,
i.e., no other chunk type must separate the ASCONFs.
3. パケットの中のすべてのASCONFsが互いに隣接しているに違いありません、すなわち、他のどんな塊タイプもASCONFsを切り離してはいけません。
4. Each new ASCONF lookup address MUST be populated as if the
previous ASCONFs had been processed and accepted.
4. まるで前のASCONFsを処理して、受け入れたかのようにそれぞれの新しいASCONFルックアップアドレスに居住しなければなりません。
6. Security Considerations
6. セキュリティ問題
The addition and or deletion of an IP address to an existing association does provide an additional mechanism by which existing associations can be hijacked. Therefore, this document requires the use of the authentication mechanism defined in [RFC4895] to limit the ability of an attacker to hijack an association.
または、そして、添加、既存の協会へのIPアドレスの削除は既存の協会をハイジャックできる追加メカニズムを提供します。 したがって、このドキュメントは攻撃者が協会をハイジャックする能力を制限するために[RFC4895]で定義された認証機構の使用を必要とします。
Stewart, et al. Standards Track [Page 30] RFC 5061 SCTP Dynamic Address Reconfiguration September 2007
スチュワート、他 規格はダイナミックなSCTPアドレス再構成2007年9月にRFC5061を追跡します[30ページ]。
Hijacking an association by using the addition and deletion of an IP address is only possible for an attacker who is able to intercept the initial two packets of the association setup when the SCTP-AUTH extension is used without pre-shared keys. If such a threat is considered a possibility, then the [RFC4895] extension MUST be used with a preconfigured shared endpoint pair key to mitigate this threat. For a more detailed analysis, see [RFC4895].
SCTP-AUTH拡張子があらかじめ共有されたキーなしで使用されるとき協会セットアップの初期の2つのパケットを妨害できる攻撃者だけに、IPアドレスの添加と削除を使用することによって協会をハイジャックするのは可能です。 そのような脅威が可能性であると考えられるなら、この脅威を緩和するために主要なあらかじめ設定された共有された終点組と共に[RFC4895]拡張子を使用しなければなりません。 より詳細な分析に関しては、[RFC4895]を見てください。
When the address parameter in ASCONF chunks with Add, IP Delete IP, or Set Primary IP parameters is a wildcard, the source address of the packet is used. This address is not protected by SCTP-AUTH [RFC4895] and an attacker can therefore intercept such a packet and modify the source address. Even if the source address is not one presently an alternate for the association, the identification of the association may rely on the other information in the packet (perhaps the verification tag, for example). An on-path attacker can therefore modify the source address to its liking.
AddがあるASCONF塊、IP Delete IP、またはSet Primary IPパラメタのアドレスパラメタがワイルドカードであるときに、パケットのソースアドレスは使用されています。 このアドレスがSCTP-AUTH[RFC4895]によって保護されないで、攻撃者は、したがって、そのようなパケットを妨害して、ソースアドレスを変更できます。 現在の補欠あたりソースアドレスが協会のための1つでなくても、協会の識別はパケット(例えば、恐らく検証タグ)でもう片方の情報を当てにするかもしれません。 したがって、経路の攻撃者はソースアドレスを好みに変更できます。
If the ASCONF includes an Add IP with a wildcard address, the attacker can add an address of its liking, which provides little immediate damage but can set up later attacks.
ASCONFがワイルドカードアドレスがあるAdd IPを含んでいるなら、攻撃者は、ほとんど即座の損害を供給しない好みのアドレスを加えることができますが、後の攻撃をセットアップできます。
If the ASCONF includes a Delete IP with a wildcard address, the attacker can cause all addresses but one of its choosing to be deleted from an association. The address supplied by the attacker must already belong to the association, which makes this more difficult for the attacker. However, the sole remaining address might be one that the attacker controls, for example, or can monitor, etc. In the least, the sender and the deceived receiver would have different ideas of what that sole remaining address would be. This will eventually cause the association to fail, but in the meantime, the deceived receiver could be transmitting packets to an address the sender did not intend.
ASCONFがワイルドカードアドレスがあるDelete IPを含んでいるなら、攻撃者は、すべてのアドレスを削除して、協会から選ぶことのものを削除させることができます。 攻撃者によって供給されたアドレスは既に協会に属さなければなりません。(それは、この以上を攻撃者にとって難しくします)。 しかしながら、唯一の残っているアドレスは攻撃者が例えば、制御するか、またはモニターできるものであるかもしれませんなど。 送付者とごまかされた受信機には、全く、その唯一の残っているアドレスが何であるだろうかに関する異なった考えがあるでしょう。 これは結局、失敗する協会を引き起こすでしょうが、差し当たりごまかされた受信機は送付者が意図しなかったアドレスにパケットを伝えているかもしれません。
If the ASCONF includes a Set Primary IP with a wildcard address, then the attacker can cause an address to be used as a primary address. This is limited to an address that already belongs to the association, so the damage is limited. At least, the result would be that the recipient is using a primary address that the sender did not intend. However, if both a wildcard Add IP and a wildcard Set Primary IP are used, then the attacker can modify the source address to both add an address to its liking to the association and make it the primary address. Such a combination would present the attacker with an opportunity for more damage.
ASCONFがワイルドカードアドレスがあるSet Primary IPを含んでいるなら、攻撃者は第一のアドレスとしてアドレスを使用させることができます。 これが既に協会に属すアドレスに制限されるので、損害は限られています。 結果は少なくとも、受取人が送付者が意図しなかった第一のアドレスを使用しているということでしょう。 しかしながら、aワイルドカードAdd IPとaワイルドカードSet Primary IPの両方が使用されているなら、攻撃者は、協会における好みにアドレスを加えて、それを第一のアドレスにするようにソースアドレスを変更できます。 そのような組み合わせは、より多くの損害の機会を攻撃者に与えるでしょう。
Stewart, et al. Standards Track [Page 31] RFC 5061 SCTP Dynamic Address Reconfiguration September 2007
スチュワート、他 規格はダイナミックなSCTPアドレス再構成2007年9月にRFC5061を追跡します[31ページ]。
Note that all these attacks are from an on-path attacker. Endpoints that believe they face a threat from on-path attackers SHOULD NOT use wildcard addresses in ASCONF Add IP, Delete IP, or Set Primary IP parameters.
これらのすべての攻撃が経路の攻撃者から来ていることに注意してください。 経路の攻撃者SHOULD NOTから直面しているそれがそれらに脅威を信じている終点がASCONF Add IPのワイルドカードアドレス、Delete IP、またはSet Primary IPパラメタを使用します。
If an SCTP endpoint that supports this extension receives an INIT that indicates that the peer supports the ASCONF extension but does NOT support the [RFC4895] extension, the receiver of such an INIT MUST send an ABORT in response. Note that an implementation is allowed to silently discard such an INIT as an option as well, but under NO circumstance is an implementation allowed to proceed with the association setup by sending an INIT-ACK in response.
この拡大を支持するSCTP終点が同輩がASCONF拡張子をサポートしますが、[RFC4895]拡大を支持しないのを示すINITを受けるなら、そのようなINIT MUSTの受信機は応答でABORTを送ります。 実現が静かにまた、オプションのようなINITを捨てることができることに注意しなさい、ただし、どんな状況の下では、INIT-ACKを送ることによって協会セットアップを続けることができるだろう実現は応答ではありません。
An implementation that receives an INIT-ACK that indicates that the peer does not support the [RFC4895] extension MUST NOT send the COOKIE-ECHO to establish the association. Instead, the implementation MUST discard the INIT-ACK and report to the upper- layer user that an association cannot be established destroying the Transmission Control Block (TCB).
同輩が[RFC4895]拡大を支持しないのを示すINIT-ACKを受ける実現は、協会を証明するためにCOOKIE-ECHOを送ってはいけません。 代わりに、実現は、INIT-ACKを捨てて、Transmission Control Block(TCB)を破壊しながら協会を設立できないと上側の層のユーザに報告しなければなりません。
Other types of attacks, e.g., bombing, are discussed in detail in [RFC5062]. The bombing attack, in particular, is countered by the use of a random nonce and is required by [RFC4960].
[RFC5062]で詳細に他のタイプの攻撃(例えば、爆撃)について議論します。 爆撃攻撃は、特に無作為の一回だけの使用で対抗されて、[RFC4960]によって必要とされます。
An on-path attacker can modify the INIT and INIT-ACK Supported Extensions parameter (and authentication-related parameters) to produce a denial of service. If the on-path attacker removes the [RFC4895]-related parameters from an INIT that indicates it supports the ASCONF extension, the association will not be established. If the on-path attacker adds a Supported Extensions parameter mentioning the ASCONF type to an INIT or INIT-ACK that does not carry any AUTH- related parameters, the association will not be established. If the on-path attacker removes the Supported Extensions parameter (or removes the ASCONF type from that parameter) from the INIT or the INIT-ACK, then the association will not be able to use the ADD-IP feature. If the on-path attacker adds the Supported Extensions parameter listing the ASCONF type to an INIT-ACK that did not carry one (but did carry AUTH-related parameters), then the INIT sender may use ASCONF where the INIT-ACK sender does not support it. This would be discovered later if the INIT sender transmitted an ASCONF, but the INIT sender could have made configuration choices at that point. As the INIT and INIT-ACK are not protected by the AUTH feature, there is no way to counter such attacks. Note however that an on-path attacker capable of modifying the INIT and INIT-ACK would almost certainly also be able to prevent the INIT and INIT-ACK from being delivered or modify the verification tags or checksum to cause the packet to be discarded, so the Supported Extensions adds little additional vulnerability (with respect to preventing association
経路の攻撃者は、サービスの否定を起こすように、INITとINIT-ACK Supported Extensionsパラメタ(そして、認証関連のパラメタ)を変更できます。 経路の攻撃者がASCONF拡張子をサポートするのを示すINITから[RFC4895]関連のパラメタを取り除くと、協会は設立されないでしょう。 経路の攻撃者が、ASCONFが少しのAUTHも運ばないINITかINIT-ACKにタイプすると言及するSupported Extensionsパラメタがパラメタについて話したと言い足すと、協会は設立されないでしょう。 経路の攻撃者がINITかINIT-ACKからSupported Extensionsパラメタ(または、そのパラメタからASCONFタイプを外す)を取り除くと、協会はADD-IPの特徴を使用できないでしょう。 経路の攻撃者が1つ(しかし、AUTH関連のパラメタを運んだ)を運ばなかったINIT-ACKにASCONFタイプを記載するSupported Extensionsパラメタを加えるなら、INIT送付者はINIT-ACK送付者がそれを支持しないASCONFを使用するかもしれません。 INIT送付者がASCONFを伝えるなら、これは後で発見されるでしょうにが、INIT送付者はその時、構成選択をしたかもしれません。 INITとINIT-ACKがAUTHの特徴によって保護されないとき、そのような攻撃に対抗する方法が全くありません。 しかしながら、Supported Extensionsがほとんど追加脆弱性を加えないように経路のINITとINIT-ACKを変更できる攻撃者がINITとINIT-ACKが届けられるのを防ぐか、またはまた、パケットが捨てられることを引き起こすようにほぼ確実に検証タグかチェックサムを変更できることに注意してください、(協会を防ぐこと。
Stewart, et al. Standards Track [Page 32] RFC 5061 SCTP Dynamic Address Reconfiguration September 2007
スチュワート、他 規格はダイナミックなSCTPアドレス再構成2007年9月にRFC5061を追跡します[32ページ]。
formation) to the SCTP protocol. The ability to prevent the use of this new feature is an additional vulnerability to SCTP but only for this new feature.
構成) SCTPに、議定書を作ってください。 この新機能の使用を防ぐ能力はSCTPにもかかわらず、この新機能のためだけの追加脆弱性です。
The Adaptation Layer Indication is subject to corruption, insertion, or deletion from the INIT and INIT-ACK chunks by an on-path attacker. This parameter SHOULD be opaque to the SCTP protocol (see Section 4.2.6), and so changes to the parameter will likely not affect the SCTP protocol. However, any adaptation layer that is defined SHOULD consider its own vulnerabilities in the Security Considerations section of the RFC that defines its adaptation code point.
Adaptation Layer Indicationは経路の攻撃者でINITとINIT-ACK塊からの不正、挿入、または削除を受けることがあります。 このパラメタSHOULDは、SCTPプロトコル(セクション4.2.6を見る)に不透明であるので、パラメタに変化します。おそらく、SCTPプロトコルに影響しないでしょう。 しかしながら、定義されたSHOULDであるどんな適合層も適合コード・ポイントを定義するRFCのSecurity Considerations部でそれ自身の脆弱性を考えます。
The Set Primary IP Address parameter is subject to corruption, insertion, or deletion by an on-path attacker when included in the INIT and INIT-ACK chunks. The attacker could use this to influence the receiver to choose an address to its own purposes (one over which it has control, one that would be less desirable for the sender, etc.). An on-path attacker would also have the ability to include or remove addresses for the association from the INIT or INIT-ACK, so it is not limited in the address it can specify in the Set Primary IP Address. Endpoints that wish to avoid this possible threat MAY defer sending the initial Set Primary request and wait until the association is fully established before sending a fully protected ASCONF with the Set Primary as its single parameter.
INITとINIT-ACK塊に含まれていると、Set Primary IP Addressパラメタは経路の攻撃者による不正、挿入、または削除を受けることがあります。 攻撃者は、受信機がそれ自身の目的(それがコントロールを持っているもの、送付者には、それほど望ましくないものなど)にアドレスを選ぶのに影響を及ぼすのにこれを使用できました。 また、経路の攻撃者には、INITかINIT-ACKから協会のためのアドレスを含んでいるか、または取り除く能力があるでしょう、したがって、それはSet Primary IP Addressで指定できるアドレスで制限されません。 ただ一つのパラメタとしてSet Primaryと完全に保護されたASCONFを送る脅威が初期のSet Primaryが要求する発信を延期して、協会まで待つかもしれないのが可能な状態でこれを避けるという願望が完全に確立している前終点。
7. IANA Considerations
7. IANA問題
This document defines the following new SCTP parameters, chunks, and errors (http://www.iana.org/assignments/sctp-parameters):
このドキュメントは以下の新しいSCTPパラメタ、塊、および誤り( http://www.iana.org/assignments/sctp-parameters )を定義します:
o two new chunk types,
o 2つの新しい塊タイプ
o six parameter types, and
o そして6人のパラメータの型。
o five new SCTP error causes.
o 5つの新しいSCTP誤り原因。
The chunk types with their assigned values are shown below.
彼らの割り当てられた値がある塊タイプは以下で見せられます。
Chunk Type Chunk Name
--------------------------------------------------------------
0xC1 Address Configuration Change Chunk (ASCONF)
0x80 Address Configuration Acknowledgment (ASCONF-ACK)
塊タイプ塊名-------------------------------------------------------------- 0xC1アドレス構成変更塊(ASCONF)0x80アドレス構成承認(ASCONF-ACK)
Stewart, et al. Standards Track [Page 33] RFC 5061 SCTP Dynamic Address Reconfiguration September 2007
スチュワート、他 規格はダイナミックなSCTPアドレス再構成2007年9月にRFC5061を追跡します[33ページ]。
The parameter types are listed below:
パラメータの型は以下に記載されています:
Parameter Type Parameter Name
-------------------------------------------------
0x8008 Supported Extensions
0xC001 Add IP Address
0xC002 Delete IP Address
0xC003 Error Cause Indication
0xC004 Set Primary Address
0xC005 Success Indication
0xC006 Adaptation Layer Indication
パラメータの型パラメタ名------------------------------------------------- 0×8008 支持された拡大0xC001は、IPアドレス0xC002が0xC004が第一のアドレスの成功指示0xC006適合層の0xC005指示を設定するというIPアドレス0xC003誤り原因指示を削除すると言い足します。
The Error Causes are listed below:
Error Causesは以下に記載されています:
Cause Code
Value Cause Code
--------- ----------------
0x00A0 Request to Delete Last Remaining IP Address
0x00A1 Operation Refused Due to Resource Shortage
0x00A2 Request to Delete Source IP Address
0x00A3 Association Aborted Due to Illegal ASCONF-ACK
0x00A4 Request Refused - No Authorization
原因コード値原因コード--------- ---------------- 最後に削除する0x00A2が拒否された不法なASCONF-ACK 0x00A4要求のため中止されたソースIPアドレス0x00A3協会を削除するよう要求するリソース不足のため拒否されたIPアドレス0x00A1操作のままで残っている0x00A0要求--認可がありません。
This document also defines an adaptation code point. The adaptation code point is a 32-bit integer that is assigned by IANA through an IETF Consensus action as defined in [RFC2434]. For this new registry, no initial values are being added by this document; however, [RDDP] will add the first entry.
また、このドキュメントは適合コード・ポイントを定義します。 適合コード・ポイントは[RFC2434]で定義されるようにIETF Consensus動作でIANAによって割り当てられる32ビットの整数です。 この新しい登録に関しては、どんな初期の値もこのドキュメントによって加えられていません。 しかしながら、[RDDP]は初記入を加えるでしょう。
8. Acknowledgments
8. 承認
The authors would like to express a special note of thanks to Michael Ramahlo and Phillip Conrad for their extreme efforts in the early formation of this draft.
作者はこの草稿の早めの構成における彼らの極端な努力のためにマイケルRamahloとフィリップ・コンラッドに感謝の特別な注意を言い表したがっています。
The authors wish to thank Jon Berger, Mark Butler, Lars Eggert, Janardhan Iyengar, Greg Kendall, Seok Koh, Salvatore Loreto, Peter Lei, John Loughney, Sandy Murphy, Ivan Arias Rodriguez, Renee Revis, Marshall Rose, Ronnie Sellars, Chip Sharp, and Irene Ruengeler for their invaluable comments.
作者は彼らの非常に貴重なコメントについてジョン・バーガー、マーク・バトラー、ラース・エッゲルト、Janardhanアイアンガー、グレッグ・ケンドール、Seok Koh、サルヴァトーレ・ロレト、ピーターLei、ジョンLoughney、サンディー・マーフィー、イワン・Ariasロドリゲス、ルネRevis、マーシャル・ローズ、ロニーセラーズ、Chipシャープ、およびアイリーンRuengelerに感謝したがっています。
The authors would also like to give special mention to Maria-Carmen Belinchon and Ian Rytina for their early contributions to this document and their thoughtful comments.
また、作者はこのドキュメントと彼らの考え深いコメントへの彼らの早めの貢献のためにマリア-カルメンBelinchonとイアンRytinaに特記を与えたがっています。
And a special thanks to James Polk, abstract writer to the few but lucky.
ジェイムズ・ポーク、わずかであるのにもかかわらずの、幸運への抽象的な作家のおかげで特別番組。
Stewart, et al. Standards Track [Page 34] RFC 5061 SCTP Dynamic Address Reconfiguration September 2007
スチュワート、他 規格はダイナミックなSCTPアドレス再構成2007年9月にRFC5061を追跡します[34ページ]。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、R.、「インターネットのためのホスト--コミュニケーションが層にされるという要件」、STD3、RFC1122、10月1989日
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
August 1996.
[RFC1982]ElzとR.とR.ブッシュ、「通し番号演算」、RFC1982、1996年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2434]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, September 2007.
[RFC4960] スチュワート、R.、エド、「流れの制御伝動プロトコル」、RFC4960、9月2007日
[RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla,
"Authenticated Chunks for the Stream Control Transmission
Protocol (SCTP)", RFC 4895, August 2007.
[RFC4895]Tuexen(M.、スチュワート、R.、レイ、P.、およびE.レスコラ)は「流れの制御伝動プロトコル(SCTP)のために塊を認証しました」、RFC4895、2007年8月。
9.2. Informative References
9.2. 有益な参照
[RFC5062] Stewart, R., Tuexen, M., and G. Camarillo, "Security
Attacks Found Against SCTP and Current Countermeasures",
RFC 5062, September 2007.
[RFC5062] スチュワート、R.、Tuexen、M.、およびG.キャマリロ、「セキュリティー攻撃はSCTPと現在の対策を有罪と議決した」RFC5062、2007年9月。
[RDDP] Bestler, C. and R. Stewart, "Stream Control Transmission
Protocol (SCTP) Direct Data Placement (DDP) Adaptation",
Work in Progress, September 2006.
[RDDP] 「流れの制御伝動プロトコル(SCTP)ダイレクトデータプレースメント(DDP)適合」というBestler、C.、およびR.スチュワートは進行中(2006年9月)で働いています。
Stewart, et al. Standards Track [Page 35] RFC 5061 SCTP Dynamic Address Reconfiguration September 2007
スチュワート、他 規格はダイナミックなSCTPアドレス再構成2007年9月にRFC5061を追跡します[35ページ]。
Appendix A. Abstract Address Handling
付録のA.の抽象的なアドレス取り扱い
A.1. General Remarks
A.1。 概評
This appendix is non-normative. It is present to give the reader a concise mathematical definition of an SCTP endpoint. The following text provides a working definition of the endpoint notion to discuss address reconfiguration. It is not intended to restrict implementations in any way; its goal is to provide a set of definitions only. Using these definitions should make a discussion about address issues easier.
この付録は非規範的です。 SCTP終点の簡潔な数学の定義を読者に与えるのは存在しています。 以下のテキストは、アドレス再構成について議論するために終点概念の仮の定義を提供します。 それが何らかの方法で実現を制限することを意図しません。 目標は1セットの定義だけを提供することです。 これらの定義を使用するのに、アドレス問題についての議論は、より簡単になるべきです。
A.2. Generalized Endpoints
A.2。 一般化された終点
A generalized endpoint is a pair of a set of IP addresses and a port number at any given point of time. The precise definition is as follows:
一般化された終点は、1組の1セットのIPアドレスと任意な与えられた点の回ポートナンバーです。 厳密な定義は以下の通りです:
A generalized endpoint gE at time t is given by
tが与えられる時間の一般化された終点gE
gE(t) = ({IP1, ..., IPn}, Port)
gE(t)=(IP1、…、IPnが移植する、)
where {IP1, ..., IPn} is a non-empty set of IP addresses.
IP1、…、IPnがIPアドレスの非空集合であるところ。
Please note that the dynamic addition and deletion of IP addresses described in this document allows the set of IP addresses of a generalized endpoint to be changed at some point of time. The port number can never be changed.
本書では説明されたIPアドレスのダイナミックな添加と削除で、一般化された終点のIPアドレスのセットは何らかのポイントの回変化します。 ポートナンバーを決して変えることができません。
The set of IP addresses of a generalized endpoint gE at a time t is defined as
時間tの一般化された終点gEのアドレスが定義されるIPのセット
Addr(gE)(t) = {IP1, ..., IPn}
Addr(gE)(t)=IP1、…、IPn
if gE(t) = ({IP1, ..., IPn}, Port) holds at time t.
gE(t)=である、(IP1、…、IPn、Port) 時間tの船倉。
The port number of a generalized endpoint gE is defined as
一般化された終点gEの数が定義されるポート
Port(gE) = Port
ポート(gE)はポートと等しいです。
if gE(t) = ({IP1, ..., IPn}, Port) holds at time t.
gE(t)=である、(IP1、…、IPn、Port) 時間tの船倉。
There is one fundamental rule that restricts all generalized endpoints:
すべての一般化された終点を制限する1つの原理があります:
For two different generalized endpoints gE' and gE'' with the same port number Port(gE') = Port(gE''), the address sets Addr(gE')(t) and Addr(gE'')(t) must be disjoint at every point in time.
同じポートがある「'2の異なった一般化された終点gE'とgE」がPortに付番する、(gE、'、)、=ポート、(gE、」、)、アドレスがAddrを設定する、(gE、'、)、(t)とAddr、(gE、」、)、(t)は時間内にあらゆるポイントでばらばらになることであるに違いありません。
Stewart, et al. Standards Track [Page 36] RFC 5061 SCTP Dynamic Address Reconfiguration September 2007
スチュワート、他 規格はダイナミックなSCTPアドレス再構成2007年9月にRFC5061を追跡します[36ページ]。
A.3. Associations
A.3。 協会
Associations consist of two generalized endpoints and the two address sets known by the peer at any time. The precise definition is as follows:
協会はいつでも同輩によって知られていた2つの一般化された終点と2つのアドレスセットから成ります。 厳密な定義は以下の通りです:
An association A between two different generalized endpoints gE' and gE'' is given by
「'2の間で異なった協会Aは終点gEを一般化し'てgE」を与えます。
A = (gE', S', gE'', S'')
='「(gE、'S、'gE」S」)
where S'(t) and S''(t) are a set of addresses at any time t such that S'(t) is a non-empty subset of Addr(gE')(t) and S''(t) is a non-empty subset of Addr(gE'')(t).
'、「S'(t)とS」(t)が何時tでも1セットのアドレスであるのでS'(t)がAddrの非空の部分集合である、(gE、'、)、(t)とS」(t)がAddrの非空の部分集合である、(gE、」、)、(t)。
If A = (gE', S', gE'', S'') is an association between the generalized endpoints gE' and gE'', the following notion is used:
「'A=である(gE、'S、'gE」S」)なら、一般化された終点の間の協会はgEです'とgE」、以下の概念は使用されています:
Addr(A, gE') = S' and Addr(A, gE'') = S''.
「'Addr、(A、gE、'、)、=S'とAddr、(A、gE、」、)、=S」。
If the dependency on time is important the notion Addr(A, gE')(t) = S'(t) will be used.
(t)はSと等しいです。'時の依存が重要である、概念Addr、(A、gE、'、)、'(t)は使用されるでしょう'。
If A is an association between gE' and gE'', then Addr(A, gE') is the subset of IP addresses of gE', which is known by gE'' and used by gE'.
そして「''Aであるなら、gEの間の協会はgEである」というAddr、(A、gE、'、)、gEのIPアドレスが部分集合がある、'どれがgEによって知られている」、gEによって使用される、'
Association establishment between gE' and gE'' can be seen as:
以下を「'gEの間の協会設立'とgE」を見ることができます。
1. gE' and gE'' do exist before the association.
「'1.gE'とgE」は協会の前に存在しています。
2. If an INIT has to be sent from gE' to gE'', address-scoping rules
and other limitations are applied to calculate the subset S' from
Addr(gE'). The addresses of S' are included in the INIT chunk.
2. Addrから「'gEから'gE」にINITを送らなければならないなら、部分集合Sについて計算するためにアドレスを見る規則と他の制限を適用する'、(gE、'、) SのアドレスはINIT塊に含まれています。
3. If an INIT-ACK has to be sent from gE'' to gE', address-scoping
rules and other limitations are applied to calculate the subset
S'' from Addr(gE''). The addresses of S'' are included in the
INIT-ACK chunk.
3. 'gEに「gEからINIT-ACKを送らなければならないなら」'、アドレスを見る規則、および他の制限がAddrから部分集合S」について計算するために適用される、(gE、」、) 「Sのアドレス」はINIT-ACK塊に含まれています。
4. After the handshake the association A = (gE', S', gE'', S'') has
been established.
4. '「握手の後に、協会A=(gE、'S、'gE」S」)は設立されました。
5. Right after the association establishment Addr(A, gE') and
Addr(A, gE'') are the addresses that have been seen on the wire
during the handshake.
5. '「協会設立Addrの後の権利、(A、gE、'、)、Addr、(A、gE、」、)、握手の間にワイヤの上に見られているアドレスはそうです。
Stewart, et al. Standards Track [Page 37] RFC 5061 SCTP Dynamic Address Reconfiguration September 2007
スチュワート、他 規格はダイナミックなSCTPアドレス再構成2007年9月にRFC5061を追跡します[37ページ]。
A.4. Relationship with RFC 4960
A.4。 RFC4960との関係
[RFC4960] defines the notion of an endpoint. This subsection will show that these endpoints are also (special) generalized endpoints.
[RFC4960]は終点の概念を定義します。 この小区分は、これらの終点が(特別)のも一般化された終点であることを示すでしょう。
[RFC4960] has no notion of address-scoping or other address-handling limitations and provides no mechanism to change the addresses of an endpoint.
[RFC4960]は、アドレスを見ているか、他のアドレス取り扱い制限の考えを全く持たないで、また終点のアドレスを変えるためにメカニズムを全く提供しません。
This means that an endpoint is simply a generalized endpoint that does not depend on time. Neither the port nor the address list changes.
これは、終点が単に定刻によらない一般化された終点であることを意味します。 ポートもアドレスも変化を記載しません。
During association setup, no address-scoping rules or other limitations will be applied. This means that for an association A between two endpoints gE' and gE'', the following is true:
協会セットアップの間、どんなアドレスを見る規則も他の制限も適用されないでしょう。 「'これは、2つの終点gEと'gE」の間の協会Aに、以下が本当であることを意味します:
Addr(A, gE') = Addr(gE') and Addr(A, gE'') = Addr(gE'').
「'Addr、(A、gE、'、)、=Addr、(gE、'、)、Addr、(A、gE、」、)、=Addr、(gE、」、)
A.5. Rules for Address Manipulation
A.5。 アドレス操作のための規則
The rules for address manipulation can now be stated in a simple way:
現在、簡単な方法でアドレス操作のための規則を述べることができます:
1. An address can be added to a generalized endpoint gE only if this
address is not an address of a different generalized endpoint
with the same port number.
1. このアドレスが同じポートナンバーがある異なった一般化された終点のアドレスでない場合にだけ一般化された終点gEにアドレスを加えることができます。
2. An address can be added to an association A with generalized
endpoint gE if it has been added to the generalized endpoint gE
first. This means that the address must be an element of
Addr(gE) first and then it can become an element of Addr(A, gE).
But this is not necessary. If the association does not allow the
reconfiguration of the addresses only Addr(gE) can be modified.
2. それが最初に一般化された終点gEに加えられるなら、一般化された終点gEとの協会Aにアドレスを追加できます。 これは、アドレスが最初にAddr(gE)の要素であるに違いないことを意味します、そして、次に、それはAddr(A、gE)の要素になることができます。 しかし、これは必要ではありません。 協会がアドレスの再構成を許さないなら、Addr(gE)しか変更できません。
3. An address can be deleted from an association A with generalized
endpoint gE as long as Addr(A, gE) stays non-empty.
3. Addr(A、gE)が非空のままである限り、一般化された終点gEとの協会Aからアドレスを削除できます。
4. An address can be deleted from an generalized endpoint gE only if
it has been removed from all associations having gE as a
generalized endpoint.
4. 一般化された終点としてgEを持っているすべての協会からそれを取り除いた場合にだけ、一般化された終点gEからアドレスを削除できます。
These rules simply make sure that the rules for the endpoints and associations given above are always fulfilled.
これらの規則は、上に与えられた終点と協会のための規則がいつも実現するのを単に確実にします。
Stewart, et al. Standards Track [Page 38] RFC 5061 SCTP Dynamic Address Reconfiguration September 2007
スチュワート、他 規格はダイナミックなSCTPアドレス再構成2007年9月にRFC5061を追跡します[38ページ]。
Authors' Addresses
作者のアドレス
Randall R. Stewart Cisco Systems, Inc. 4875 Forest Drive Suite 200 Columbia, SC 29206 US
ランドルR.スチュワートシスコシステムズInc.4875森林ドライブSuite200SC29206コロンビア(米国)
Phone: EMail: rrs@cisco.com
以下に電話をしてください。 メール: rrs@cisco.com
Qiaobing Xie Motorola, Inc. 1501 W. Shure Drive, 2-3C Arlington Heights, IL 60004 USA
シェをQiaobingして、モトローラ1501のW.シュアーは運転して、2-3 Cアーリントンハイツ、ILは60004米国です。
Phone: +1-847-632-3028 EMail: Qiaobing.Xie@motorola.com
以下に電話をしてください。 +1-847-632-3028 メールしてください: Qiaobing.Xie@motorola.com
Michael Tuexen Univ. of Applied Sciences Muenster Stegerwaldstr. 39 48565 Steinfurt Germany
応用科学Muenster StegerwaldstrのマイケルTuexen大学。 39 48565Steinfurtドイツ
EMail: tuexen@fh-muenster.de
メール: tuexen@fh-muenster.de
Shin Maruyama Kyoto University Yoshida-Honmachi Sakyo-ku Kyoto, Kyoto 606-8501 JAPAN
向こうずね京都大学の吉田Honmachi Sakyo区の京都京都606-8501丸山(日本)
Phone: +81-75-753-7417 EMail: mail@marushin.gr.jp
以下に電話をしてください。 +81-75-753-7417 メールしてください: mail@marushin.gr.jp
Stewart, et al. Standards Track [Page 39] RFC 5061 SCTP Dynamic Address Reconfiguration September 2007
スチュワート、他 規格はダイナミックなSCTPアドレス再構成2007年9月にRFC5061を追跡します[39ページ]。
Masahiro Kozuka Kyoto University Yoshida-Honmachi Sakyo-ku Kyoto, Kyoto 606-8501 JAPAN
京都、小塚京都大学の吉田Honmachi Sakyo区の京都日本の正裕606-8501
Phone: +81-75-753-7417 EMail: ma-kun@kozuka.jp
以下に電話をしてください。 +81-75-753-7417 メールしてください: ma-kun@kozuka.jp
Stewart, et al. Standards Track [Page 40] RFC 5061 SCTP Dynamic Address Reconfiguration September 2007
スチュワート、他 規格はダイナミックなSCTPアドレス再構成2007年9月にRFC5061を追跡します[40ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
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, THE IETF TRUST 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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に情報を記述してください。
Stewart, et al. Standards Track [Page 41]
スチュワート、他 標準化過程[41ページ]
一覧
スポンサーリンク
