Network Working Group G. Dommety
Request for Comments: 2890 Cisco Systems
Category: Standards Track September 2000
Key and Sequence Number Extensions to GRE
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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
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（総称ルーティングカプセル化）は、他の任意のネットワーク層プロトコル上で任意のプロトコルをカプセル化するためのプロトコルを規定します。この文書は、二つのフィールド、キー及びシーケンス番号は、任意にGREヘッダ[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.
総称ルーティングカプセル化[1]の現在の仕様は、他の任意のネットワーク層プロトコル上で任意のプロトコルをカプセル化するためのプロトコルを規定します。この文書は、二つのフィールド、キー及びシーケンス番号は、任意にGREヘッダ[1]で搬送することが可能な拡張機能を記述する。キー・フィールドは、トンネル内の個々のトラフィックフローを識別するために使用されることが意図されます。シーケンス番号フィールドは、GREトンネル内のパケットの順序を維持するために使用されます。
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"、 "MUST NOT"、 "REQUIRED" は、 "NOT SHALL" "ものと" この文書では、 "SHOULD"、 "推奨" "NOT SHOULD"、 "MAY"、 "OPTIONAL" はにありますRFC 2119に記載されるように解釈される[3]。
In addition, the following words are used to signify the requirements of the specification.
また、以下の単語は、仕様の要件を意味するために使用されています。
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.
サイレント実装は、さらなる処理なしにデータグラムを破棄し、送信者にエラーを示すことなく廃棄します。実装は、廃棄されたデータグラムの内容を含め、エラーをログに記録する機能を提供すべきである、と統計カウンターにイベントを記録する必要があります。
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
キー現在のビットが1に設定される場合、それはキーフィールドはGREヘッダ内に存在することを示しています。それ以外の場合は、キーフィールドは、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.
シーケンス番号現在のビットが1に設定される場合、それはシーケンス番号フィールドが存在することを示します。そうでない場合は、シーケンス番号フィールドは、GREヘッダーに存在しません。
The Key and the Sequence Present bits are chosen to be compatible with RFC 1701 [2].
キーとシーケンス存在するビットを、RFC 1701に適合するように選択されている[2]。
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.
キーフィールドは、カプセル化によって挿入された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.
シーケンス番号フィールドは、4つのバイトのフィールドであり、シーケンス番号現在のビットがセットされたときにカプセル化によって挿入されています。シーケンス番号は、パケットが受信機にカプセル化装置から送信された順序を確立するために受信機によって使用されなければなりません。シーケンスフィールドの使用目的は、信頼できないが、順序どおりの配信を提供することです。キー本のビット（ビット2）が設定されている場合、シーケンス番号はキーフィールドによって識別されるトラフィックフローに特異的です。シーケンスビットが設定されていないパケットはシーケンスのビットがセットされたパケットとインターリーブすることができることに留意されたいです。
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に表されています。受信機は、最後に正常デカプセル化パケットのシーケンス番号値を維持しています。 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.
カプセル化を解くには、アウトオブシーケンスパケットを受信すると、それは静かに捨てられるべきです。受信したパケットのシーケンス番号が最後に正常デカプセル化パケットのシーケンス番号以下である場合、パケットは、アウトオブシーケンスパケットであると考えられます。その値が最後に受信したシーケンス番号と前回の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).
受信したパケットがインシーケンスパケットである場合は、それが正常にカプセル化が解除されます。インシーケンスパケットは、シーケンス番号フィールドは、（Sビットがセットされていない）が存在しないである（モジュロ2 ** 32）最後に成功しデカプセル化パケット、または1より厳密に1より大きいシーケンス番号を有するものです。
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.
受信パケットがインシーケンスもアウトオブシーケンスパケットでもない場合には、シーケンス番号のギャップを示しています。受信機は、送信されたパケットのオリジナルシーケンスを回復する試みにおいてバッファリングの少量を実行することができます。この場合、パケットは、シーケンス番号順に並べ替えバッファに配置することができます。イン・シーケンスのパケットをカプセル化解除正常に受信された場合、受信機は、次のインシーケンスパケットがすでに受信されているかどうかを確認するために、このバッファの先頭に相談してください。もしそうであれば、受信機は、バッファ内に存在していてもよい以下でシーケンスパケットと同様にそれをデカプセル化すべきです。 「最後に正常にカプセル化が解除シーケンス番号が」その後、バッファからカプセル開放された最後のパケットに設定する必要があります。
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ミリ秒以上待っていたバッファにパケットが存在しなくなるまでパケットをデカプセル化（および任意のシーケンス番号のギャップを無視して）、ソート順でバッファを通過しなければなりません。 「最後に正常デカプセル化シーケンス番号は、」そのようにデカプセル化最後のパケットに設定する必要があります。
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.
受信機は、（フローに属する同一のキーフィールド値を有するパケット）の任意のフロー別バッファ内のパケットの数に制限を置くことができます。パケットがその受信機が与えられたバッファにMAX_PERFLOW_BUFFERパケットよりも多く配置する原因となる到着した場合には、バッファの先頭にあるパケットは、直ちにそのシーケンス番号にかかわらず、カプセル化が解除され、「成功したカプセル化が解除シーケンス番号が最後」に設定されているそのシーケンス番号。新たに到着したパケットは、バッファ内に配置することができます。
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.
シーケンス番号は、失われたパケットを検出および/または輸送中に並べ替えされていてもよい（バッファリング）パケットの元の順序を復元するために使用されることに注意してください。シーケンス番号オプションの使用は適切に使用する必要があります。上位層における順序配信メカニズムを持っているか、アウトオブオーダー配信に対して耐性であるプロトコルをトンネリングするとき、特に、それが使用を避けることをお勧めします。唯一のいくつかの例で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 packet reordering in the network by buffering.
アウトオブシーケンスパケットの並べ替えは、ネットワーク内の並べ替えに改善された性能および耐性のためのカプセル開放装置によって実行することができます。上位層は、ステートフル圧縮または暗号化を採用するときにリオーダリングバッファ（MAX_PERFLOW_BUFFER）少量の性能を改善するのに役立つことができます。ステートフル圧縮や暗号化の状態はパケットロスによってリセットされるので、パフォーマンスがバッファリングすることで、ネットワーク内のパケットの並べ替えのいくつかの小さな量を許容するのに役立つかもしれません。
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（総称ルーティングカプセル化）ヘッダ[1]で搬送することが可能な拡張機能を記述する。シーケンス番号フィールドを使用する場合は、任意のシーケンス番号を持つパケットを注入し、サービス拒否攻撃を起動することが可能です。このような攻撃から保護するために、IPセキュリティプロトコル[4]はGREヘッダーとトンネリングペイロードを保護するために使用されなければなりません。 ESP（カプセル化セキュリティペイロード）[5]またはAH（認証ヘッダ）のいずれか[6] GREヘッダを保護するために使用されなければなりません。 ESPを使用する場合には、GREヘッダを含むIPペイロードを保護します。 AHは、可変フィールドが認証されている以外のパケット全体を使用している場合。キーフィールドは（その名前にもかかわらず）任意の並べ替えやセキュリティに関与していないことに注意してください。
This document does not require any allocations by the IANA and therefore does not have any new IANA considerations.
このドキュメントは、IANAによって任意の割り当てを必要としないため、任意の新しいIANAの考慮事項はありません。
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.
この文書は、RFC 1701ケントレオン、ピートマッキャン、マークTownsley、デビッド・マイヤー、Yingchun徐、Ajoyシンおよび他の多くの有益な議論を提供する作家の独創的なアイデアに由来しています。著者は、上記のすべての人々に感謝したいと思います。
[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.とP. Trainaの、 "総称ルーティングカプセル化（GRE）"、RFC 2784、2000年3月。
[2] Hanks, S., Li, T, Farinacci, D., and P. Traina, "Generic Routing Encapsulation", RFC 1701, October 1994.
[2]ハンクス、S.、リチウム、T、ファリナッチ、D.、およびP. Trainaの、 "汎用ルーティングカプセル化"、RFC 1701、1994年10月。
[3] Bradner S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3]ブラドナーのS.、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[4] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[4]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[5] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[5]ケント、S.とR.アトキンソン、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 2406、1998年11月。
[6] Kent, S., and R. Atkinson, " IP Authentication Header", RFC 2402, November 1998.
[6]ケント、S.、およびR.アトキンソン、 "IP認証ヘッダ"、RFC 2402、1998年11月。
Author's Address
著者のアドレス
Gopal Dommety Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134
ゴパルDommetyシスコシステムズ、株式会社170西タスマン・ドライブサンノゼ、CA 95134
EMail: gdommety@cisco.com
メールアドレス：gdommety@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
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.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
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機能のための基金は現在、インターネット協会によって提供されます。