RFC2890 日本語訳
2890 Key and Sequence Number Extensions to GRE. G. Dommety. September 2000. (Format: TXT=14503 bytes) (Updates RFC2784) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. Dommety Request for Comments: 2890 Cisco Systems Category: Standards Track September 2000
Dommetyがコメントのために要求するワーキンググループG.をネットワークでつないでください: 2890年のシスコシステムズカテゴリ: 標準化過程2000年9月
Key and Sequence Number Extensions to GRE
GREへのキーと一連番号拡大
Status of this Memo
この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)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
GRE (Generic Routing Encapsulation) specifies a protocol for encapsulation of an arbitrary protocol over another arbitrary network layer protocol. This document describes extensions by which two fields, Key and Sequence Number, can be optionally carried in the GRE Header [1].
GRE(ジェネリックルート設定Encapsulation)は別の任意のネットワーク層プロトコルの上で任意のプロトコルのカプセル化にプロトコルを指定します。 このドキュメントはGRE Header[1]で2つの野原(KeyとSequence Number)を任意に、運ぶことができる拡大について説明します。
1. Introduction
1. 序論
The current specification of Generic Routing Encapsulation [1] specifies a protocol for encapsulation of an arbitrary protocol over another arbitrary network layer protocol. This document describes enhancements by which two fields, Key and Sequence Number, can be optionally carried in the GRE Header [1]. The Key field is intended to be used for identifying an individual traffic flow within a tunnel. The Sequence Number field is used to maintain sequence of packets within the GRE Tunnel.
Genericルート設定Encapsulation[1]の現在の仕様は別の任意のネットワーク層プロトコルの上で任意のプロトコルのカプセル化にプロトコルを指定します。 このドキュメントはGRE Header[1]で2つの野原(KeyとSequence Number)を任意に、運ぶことができる増進について説明します。 トンネルの中で個々の交通の流れを特定するのにKey分野が使用されることを意図します。 Sequence Number分野は、GRE Tunnelの中でパケットの系列を維持するのに使用されます。
1.1. Specification Language
1.1. 仕様言語
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [3].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[3]で説明されるように本書では解釈されることであるべきですか?
In addition, the following words are used to signify the requirements of the specification.
さらに、以下の単語は、仕様の要件を意味するのに使用されます。
Dommety Standards Track [Page 1] RFC 2890 Key and Sequence Number Extensions to GRE September 2000
Dommety規格は2000年9月に2890年のRFCキーと一連番号拡大をGREに追跡します[1ページ]。
Silently discard The implementation discards the datagram without further processing, and without indicating an error to the sender. The implementation SHOULD provide the capability of logging the error, including the contents of the discarded datagram, and SHOULD record the event in a statistics counter.
静かに、破棄は実装がデータグラムを捨てる処理、および表示のない誤りを送付者に促進します。 実装SHOULDは捨てられたデータグラムのコンテンツを含む誤りを登録する能力を提供します、そして、SHOULDは統計カウンタに出来事を記録に残します。
2. Extensions to GRE Header
2. GREヘッダーへの拡大
The GRE packet header[1] has the following format:
GREパケットのヘッダー[1]には、以下の形式があります:
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C| Reserved0 | Ver | Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum (optional) | Reserved1 (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C| Reserved0| Ver| プロトコルタイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム(任意の)| Reserved1(任意の)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The proposed GRE header will have the following format:
提案されたGREヘッダーには、以下の形式があるでしょう:
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C| |K|S| Reserved0 | Ver | Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum (optional) | Reserved1 (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Key (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C| |K|S| Reserved0| Ver| プロトコルタイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム(任意の)| Reserved1(任意の)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 主要です(任意の)。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 一連番号(任意の)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Key Present (bit 2)
キープレゼント(ビット2)
If the Key Present bit is set to 1, then it indicates that the Key field is present in the GRE header. Otherwise, the Key field is not present in the GRE header.
Key Presentビットが1に設定されるなら、それは、Key分野がGREヘッダーに存在しているのを示します。 さもなければ、Key分野はGREヘッダーに存在していません。
Sequence Number Present (bit 3)
一連番号プレゼント(ビット3)
If the Sequence Number Present bit is set to 1, then it indicates that the Sequence Number field is present. Otherwise, the Sequence Number field is not present in the GRE header.
Sequence Number Presentビットが1に設定されるなら、それは、Sequence Number分野が存在しているのを示します。 さもなければ、Sequence Number分野はGREヘッダーに存在していません。
The Key and the Sequence Present bits are chosen to be compatible with RFC 1701 [2].
KeyとSequence Presentビットは、RFC1701[2]と互換性があるように選ばれています。
Dommety Standards Track [Page 2] RFC 2890 Key and Sequence Number Extensions to GRE September 2000
Dommety規格は2000年9月に2890年のRFCキーと一連番号拡大をGREに追跡します[2ページ]。
2.1. Key Field (4 octets)
2.1. キーフィールド(4つの八重奏)
The Key field contains a four octet number which was inserted by the encapsulator. The actual method by which this Key is obtained is beyond the scope of the document. The Key field is intended to be used for identifying an individual traffic flow within a tunnel. For example, packets may need to be routed based on context information not present in the encapsulated data. The Key field provides this context and defines a logical traffic flow between encapsulator and decapsulator. Packets belonging to a traffic flow are encapsulated using the same Key value and the decapsulating tunnel endpoint identifies packets belonging to a traffic flow based on the Key Field value.
Key分野はencapsulatorによって挿入された4八重奏番号を含んでいます。 このKeyが入手される実際のメソッドはドキュメントの範囲を超えています。 トンネルの中で個々の交通の流れを特定するのにKey分野が使用されることを意図します。 例えば、パケットは、カプセル化されたデータの現在でない文脈情報に基づいて発送される必要があるかもしれません。 Key分野は、encapsulatorとdecapsulatorの間でこの文脈を提供して、論理的な交通の流れを定義します。 交通の流れに属すパケットが同じKey値を使用することでカプセルに入れられます、そして、decapsulatingトンネル終点はKey Field値に基づく交通の流れに属すパケットを特定します。
2.2. Sequence Number (4 octets)
2.2. 一連番号(4つの八重奏)
The Sequence Number field is a four byte field and is inserted by the encapsulator when Sequence Number Present Bit is set. The Sequence Number MUST be used by the receiver to establish the order in which packets have been transmitted from the encapsulator to the receiver. The intended use of the Sequence Field is to provide unreliable but in-order delivery. If the Key present bit (bit 2) is set, the sequence number is specific to the traffic flow identified by the Key field. Note that packets without the sequence bit set can be interleaved with packets with the sequence bit set.
Sequence Number野原は、4バイトの分野であり、Sequence Number Present Bitが用意ができているとき、encapsulatorによって挿入されます。 encapsulatorから受信機まで送られてください、そうした。受信機でSequence Numberを使用して、それのパケットに頼り無い状態で提供するSequence Fieldの意図している使用がことであるオーダーにもかかわらず、オーダーにおける配送を確立しなければなりません。 Key現在のビット(ビット2)が設定されるなら、一連番号はKey分野によって特定された交通の流れに特定です。 系列ビットがセットした状態で、パケットで系列ビットのないパケットがセットしたというメモをはさみ込むことができます。
The sequence number value ranges from 0 to (2**32)-1. The first datagram is sent with a sequence number of 0. The sequence number is thus a free running counter represented modulo 2**32. The receiver maintains the sequence number value of the last successfully decapsulated packet. Upon establishment of the GRE tunnel, this value should be set to (2**32)-1.
一連番号値は0から(2**32)-1に変化します。 0の一連番号と共に最初のデータグラムを送ります。 その結果、一連番号は自由な実行しているカウンタ表された法2**32です。 受信機は最後に首尾よくdecapsulatedされたパケットの一連番号値を維持します。 GREトンネルの設立のときに、この値は(2**32)-1に設定されるべきです。
When the decapsulator receives an out-of sequence packet it SHOULD be silently discarded. A packet is considered an out-of-sequence packet if the sequence number of the received packet is less than or equal to the sequence number of last successfully decapsulated packet. The sequence number of a received message is considered less than or equal to the last successfully received sequence number if its value lies in the range of the last received sequence number and the preceding 2**31-1 values, inclusive.
decapsulatorが受信される、順序が狂ってパケット、それ、捨てられて、SHOULDは静かにそうです。 パケットは容認されたパケットの一連番号が最後に首尾よくdecapsulatedされたパケットの、より一連番号以下であるなら系列で出ているパケットであると考えられます。 値が最後の容認された一連番号と2**31-1の前の値の範囲にあるなら、受信されたメッセージの一連番号は最後に首尾よく受け取られたより一連番号であると考えられます、包括的です。
If the received packet is an in-sequence packet, it is successfully decapsulated. An in-sequence packet is one with a sequence number exactly 1 greater than (modulo 2**32) the last successfully decapsulated packet, or one in which the sequence number field is not present (S bit not set).
容認されたパケットが系列のパケットであるなら、それは首尾よくdecapsulatedされます。 系列のパケットはまさに一連番号がある1です。1 最後に首尾よくdecapsulatedされた(法2**32)パケット、または一連番号分野が現在でないもの(Sビットはセットしなかった)よりすばらしいです。
Dommety Standards Track [Page 3] RFC 2890 Key and Sequence Number Extensions to GRE September 2000
Dommety規格は2000年9月に2890年のRFCキーと一連番号拡大をGREに追跡します[3ページ]。
If the received packet is neither an in-sequence nor an out-of- sequence packet it indicates a sequence number gap. The receiver may perform a small amount of buffering in an attempt to recover the original sequence of transmitted packets. In this case, the packet may be placed in a buffer sorted by sequence number. If an in- sequence packet is received and successfully decapsulated, the receiver should consult the head of this buffer to see if the next in-sequence packet has already been received. If so, the receiver should decapsulate it as well as the following in-sequence packets that may be present in the buffer. The "last successfully decapsulated sequence number" should then be set to the last packet that was decapsulated from the buffer.
または、容認されたパケットがどちらもでない連続して、アウト、-系列パケットでは、それは一連番号ギャップを示します。 受信機は伝えられたパケットの元の系列を回復する試みでわずかな量のバッファリングを実行するかもしれません。 この場合、パケットは一連番号によって分類されたバッファに置かれるかもしれません。 コネ系列パケットが受け取られて、首尾よくdecapsulatedされるなら、受信機は、系列の次のパケットが既に受け取られたかどうかを見るためにこのバッファのヘッドに相談するはずです。 そうだとすれば、受信機はそれを以下が中でバッファに存在するかもしれないパケットを配列するのと同じくらいよくdecapsulateするはずです。 そして、「最後に首尾よくdecapsulatedされた一連番号」はバッファからdecapsulatedされた最後のパケットに設定されるべきです。
Under no circumstances should a packet wait more that OUTOFORDER_TIMER milliseconds in the buffer. If a packet has been waiting that long, the receiver MUST immediately traverse the buffer in sorted order, decapsulating packets (and ignoring any sequence number gaps) until there are no more packets in the buffer that have been waiting longer than OUTOFORDER_TIMER milliseconds. The "last successfully decapsulated sequence number" should then be set to the last packet so decapsulated.
パケットはバッファのそのOUTOFORDER_TIMERミリセカンドをさらに決して、待つはずがありません。 パケットがそんなに長い間待っているなら、受信機はすぐに分類されたオーダーにおけるバッファを横断しなければなりません、OUTOFORDER_TIMERミリセカンドより長い間待っているバッファにはそれ以上のパケットが全くないまでパケット(どんな一連番号ギャップも無視して)をdecapsulatingして。 そして、「最後に首尾よくdecapsulatedされた一連番号」はそのようにdecapsulatedされた最後のパケットに設定されるべきです。
The receiver may place a limit on the number of packets in any per- flow buffer (Packets with the same Key Field value belong to a flow). If a packet arrives that would cause the receiver to place more than MAX_PERFLOW_BUFFER packets into a given buffer, then the packet at the head of the buffer is immediately decapsulated regardless of its sequence number and the "last successfully decapsulated sequence number" is set to its sequence number. The newly arrived packet may then be placed in the buffer.
受信機がいずれのパケットの数に限度を設けるかもしれない、-、流れバッファ(同じKey Field値があるパケットは流れに属します)。 受信機がマックス_PERFLOW_BUFFERパケットより与えられたバッファの中に入賞するパケットが到着するなら、バッファのヘッドのパケットはすぐに一連番号にかかわらずdecapsulatedされます、そして、「最後に首尾よくdecapsulatedされた一連番号」は一連番号に設定されます。 そして、新たに到着したパケットはバッファに置かれるかもしれません。
Note that the sequence number is used to detect lost packets and/or restore the original sequence of packets (with buffering) that may have been reordered during transport. Use of the sequence number option should be used appropriately; in particular, it is a good idea a avoid using when tunneling protocols that have higher layer in- order delivery mechanisms or are tolerant to out-of-order delivery. If only at certain instances the protocol being carried in the GRE tunnel requires in-sequence delivery, only the corresponding packets encapsulated in a GRE header can be sent with the sequence bit set.
一連番号が無くなっているパケットを検出する、そして/または、輸送の間に再命令されているかもしれないパケット(バッファリングがある)の元の系列を回復するのに使用されることに注意してください。 一連番号オプションの使用は適切に使用されるべきです。 より高い層に中で排紙機構を注文させるか、または不適切な配送に許容性があるのが、特に、aがプロトコルにトンネルを堀るとき、使用するのを避ける名案です。 単にあるインスタンスでは、GREトンネルで運ばれるプロトコルが連続して配送を必要とするなら、系列ビットがセットした状態で、GREヘッダーでカプセルに入れられた対応するパケットだけは送ることができます。
Reordering of out-of sequence packets MAY be performed by the decapsulator for improved performance and tolerance to reordering in the network. A small amount of reordering buffer (MAX_PERFLOW_BUFFER) may help in improving performance when the higher layer employs stateful compression or encryption. Since the state of the stateful compression or encryption is reset by packet loss, it might help the performance to tolerate some small amount of
順序が狂ってパケットのReorderingはdecapsulatorによってネットワークで再命令することへの向上した性能と寛容に実行されるかもしれません。 少量の再命令バッファ(マックス_PERFLOW_BUFFER)が、より高い層の雇用が圧縮か暗号化をstatefulするとき、性能を向上させるのを手伝うかもしれません。 stateful圧縮か暗号化の状態がパケット損失でリセットされるので、それはいくらかの少量を許容する性能を助けるかもしれません。
Dommety Standards Track [Page 4] RFC 2890 Key and Sequence Number Extensions to GRE September 2000
Dommety規格は2000年9月に2890年のRFCキーと一連番号拡大をGREに追跡します[4ページ]。
packet reordering in the network by buffering.
ネットワークでバッファリングすることによって再命令されるパケット。
3. Security Considerations
3. セキュリティ問題
This document describes extensions by which two fields, Key and Sequence Number, can be optionally carried in the GRE (Generic Routing Encapsulation) Header [1]. When using the Sequence number field, it is possible to inject packets with an arbitrary Sequence number and launch a Denial of Service attack. In order to protect against such attacks, IP security protocols [4] MUST be used to protect the GRE header and the tunneled payload. Either ESP (Encapsulating Security Payload) [5] or AH (Authentication Header)[6] MUST be used to protect the GRE header. If ESP is used it protects the IP payload which includes the GRE header. If AH is used the entire packet other than the mutable fields are authenticated. Note that Key field is not involved in any sort or security (despite its name).
このドキュメントはGRE(ジェネリックルート設定Encapsulation)ヘッダー[1]で2つの野原(KeyとSequence Number)を任意に、運ぶことができる拡大について説明します。 Sequenceナンバーフィールドを使用するとき、任意のSequence番号をパケットに注射して、サービス妨害攻撃に着手するのは可能です。 そのような攻撃から守って、GREヘッダーとトンネルを堀られたペイロードを保護するのにIPセキュリティプロトコル[4]を使用しなければなりません。 GREヘッダーを保護するのに超能力(Securityが有効搭載量であるとカプセル化する)[5]かAH(認証Header)[6]のどちらかを使用しなければなりません。 超能力が使用されているなら、それはGREヘッダーを含んでいるIPペイロードを保護します。 AHが使用されているなら、無常の分野以外の全体のパケットは認証されます。 Key分野がどんな種類やセキュリティ(名前にもかかわらず)にもかかわらないことに注意してください。
4. IANA Considerations
4. IANA問題
This document does not require any allocations by the IANA and therefore does not have any new IANA considerations.
このドキュメントは、IANAによる少しの配分も必要としないで、またしたがって、どんな新しいIANA問題も持っていません。
5. Acknowledgments
5. 承認
This document is derived from the original ideas of the authors of RFC 1701. Kent Leung, Pete McCann, Mark Townsley, David Meyer, Yingchun Xu, Ajoy Singh and many others provided useful discussion. The author would like to thank all the above people.
RFC1701の作者の着想からこのドキュメントを得ます。 ケントレオン、ピートマッキャン、マークTownsley、デヴィッド・マイヤー、Yingchunシュー、Ajoyシン、および多くの他のものが役に立つ議論を提供しました。 作者はすべての上の人々に感謝したがっています。
Dommety Standards Track [Page 5] RFC 2890 Key and Sequence Number Extensions to GRE September 2000
Dommety規格は2000年9月に2890年のRFCキーと一連番号拡大をGREに追跡します[5ページ]。
6. References
6. 参照
[1] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[1] ファリナッチとD.と李とT.とハンクスとS.とマイヤーとD.と2000年のP.Traina、「一般ルーティングのカプセル化(GRE)」、RFC2784行進。
[2] Hanks, S., Li, T, Farinacci, D., and P. Traina, "Generic Routing Encapsulation", RFC 1701, October 1994.
[2] ハンクスとS.と李とTとファリナッチ、D.とP.Traina、「一般ルーティングのカプセル化」、RFC1701、1994年10月。
[3] Bradner S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] ブラドナーS.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[4] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[4] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[5] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[5] ケントとS.とR.アトキンソン、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC2406、1998年11月。
[6] Kent, S., and R. Atkinson, " IP Authentication Header", RFC 2402, November 1998.
[6] ケント、S.とR.アトキンソン、「IP認証ヘッダー」、RFC2402、1998年11月。
Author's Address
作者のアドレス
Gopal Dommety Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134
ゴパルDommetyシスコシステムズInc.170の西タスマン・Driveサンノゼ、カリフォルニア 95134
EMail: gdommety@cisco.com
メール: gdommety@cisco.com
Dommety Standards Track [Page 6] RFC 2890 Key and Sequence Number Extensions to GRE September 2000
Dommety規格は2000年9月に2890年のRFCキーと一連番号拡大をGREに追跡します[6ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Dommety Standards Track [Page 7]
Dommety標準化過程[7ページ]
一覧
スポンサーリンク