GREのキーとシーケンス番号の拡張
英文を機械翻訳で日本語訳としています。日本語訳が正しくないことが考えられますので原文をメインとし、参考程度にご利用ください。
日本語訳
Network Working Group G. Dommety
Request for Comments: 2890 Cisco Systems
Category: Standards Track September 2000
Key and Sequence Number Extensions to GRE
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.
Copyright（C）The Internet Society（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（Generic Routing Encapsulation）は、任意のプロトコルを別の任意のネットワーク層プロトコルにカプセル化するためのプロトコルを指定します。 このドキュメントでは、キーとシーケンス番号の2つのフィールドをオプションでGREヘッダーに含めることができる拡張機能について説明します[1]。
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 Routing Encapsulation [1]の現在の仕様では、任意のプロトコルを別の任意のネットワーク層プロトコルにカプセル化するためのプロトコルを指定しています。 このドキュメントでは、キーとシーケンス番号の2つのフィールドをオプションでGREヘッダーに含めることができる拡張機能について説明します[1]。 キーフィールドは、トンネル内の個々のトラフィックフローを識別するために使用することを目的としています。 シーケンス番号フィールドは、GREトンネル内のパケットのシーケンスを維持するために使用されます。
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」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [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 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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]と互換性があるように選択されています。
Dommety Standards Track [Page 2] RFC 2890 Key and Sequence Number Extensions to GRE September 2000 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.
キーフィールドには、カプセル化担当者によって挿入された4オクテット番号が含まれています。 このキーを取得する実際の方法は、ドキュメントの範囲を超えています。 キーフィールドは、トンネル内の個々のトラフィックフローを識別するために使用することを目的としています。 たとえば、パケットは、カプセル化されたデータに存在しないコンテキスト情報に基づいてルーティングされる必要がある場合があります。 キーフィールドはこのコンテキストを提供し、カプセル化装置とカプセル開放装置間の論理トラフィックフローを定義します。 トラフィックフローに属するパケットは、同じキー値を使用してカプセル化され、カプセル化解除トンネルエンドポイントは、キーフィールド値に基づいてトラフィックフローに属するパケットを識別します。
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.
シーケンス番号フィールドは4バイトのフィールドであり、シーケンス番号存在ビットが設定されると、カプセル化装置によって挿入されます。 シーケンス番号は、パケットがカプセル化装置から受信機に送信された順序を確立するために受信機によって使用されなければなりません（MUST）。 シーケンスフィールドの使用目的は、信頼性の低い順序どおりの配信を提供することです。 キー存在ビット（ビット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.
カプセル開放装置がシーケンス外のパケットを受信すると、それは静かに破棄されるべきです（SHOULD）。 受信したパケットのシーケンス番号が、最後に正常にカプセル化解除されたパケットのシーケンス番号以下の場合、パケットはシーケンス外パケットと見なされます。 受信したメッセージのシーケンス番号は、その値が最後に受信したシーケンス番号とその前の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).
受信したパケットがシーケンス内のパケットである場合は、カプセル化が正常に解除されます。 インシーケンスパケットは、最後に正常にカプセル化が解除されたパケット（2 ** 32を法とする）よりも1だけ大きいシーケンス番号を持つパケット、またはシーケンス番号フィールドが存在しない（Sビットが設定されていない）パケットです。
Dommety Standards Track [Page 3] RFC 2890 Key and Sequence Number Extensions to GRE September 2000 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 Dommety Standards Track [Page 4] RFC 2890 Key and Sequence Number Extensions to GRE September 2000 packet reordering in the network by buffering.
シーケンス外パケットの並べ替えは、ネットワークでの並べ替えに対するパフォーマンスと耐性を改善するために、カプセル化解除装置によって実行される場合があります。 上位層がステートフル圧縮または暗号化を採用している場合、少量の並べ替えバッファ（MAX_PERFLOW_BUFFER）がパフォーマンスの向上に役立つことがあります。 ステートフル圧縮または暗号化の状態はパケット損失によってリセットされるため、パフォーマンスを向上させるために、バッファリングによってネットワーク内の少量のパケットの並べ替えを許容できる場合があります。
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).
このドキュメントでは、キーとシーケンス番号の2つのフィールドをオプションでGRE（Generic Routing Encapsulation）ヘッダーに含めることができる拡張機能について説明します[1]。 シーケンス番号フィールドを使用すると、任意のシーケンス番号のパケットを挿入し、サービス拒否攻撃を開始することが可能です。 このような攻撃から保護するために、IPセキュリティプロトコル[4]を使用して、GREヘッダーとトンネルペイロードを保護する必要があります。 ESP（カプセル化セキュリティペイロード）[5]またはAH（認証ヘッダー）[6]のいずれかを使用して、GREヘッダーを保護する必要があります。 ESPを使用すると、GREヘッダーを含むIPペイロードが保護されます。 AHが使用される場合、可変フィールド以外のパケット全体が認証されます。 キーフィールドは、その名前にかかわらず、並べ替えやセキュリティには関与しないことに注意してください。
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.
このドキュメントは、RFC 1701の作成者の元のアイデアから派生しています。 Kent Leung、Pete McCann、Mark Townsley、David Meyer、Yingchun Xu、Ajoy Singh、その他多くの人が有益な議論を行いました。 著者は上記のすべての人々に感謝したいと思います。
Dommety Standards Track [Page 5]
RFC 2890 Key and Sequence Number Extensions to GRE September 2000
6. References
[1] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina,
"Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[2] Hanks, S., Li, T, Farinacci, D., and P. Traina, "Generic Routing
Encapsulation", RFC 1701, October 1994.
[3] Bradner S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] Kent, S. and R. Atkinson, "Security Architecture for the Internet
Protocol", RFC 2401, November 1998.
[5] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
[6] Kent, S., and R. Atkinson, " IP Authentication Header", RFC 2402,
November 1998.
Author's Address
Gopal Dommety
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
EMail: gdommety@cisco.com
Dommety Standards Track [Page 6]
RFC 2890 Key and Sequence Number Extensions to GRE September 2000
Full Copyright Statement
Copyright (C) The Internet Society (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.
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.
Dommety Standards Track [Page 7]