Network Working Group D. Farinacci Request for Comments: 2784 T. Li Category: Standards Track Procket Networks S. Hanks Enron Communications D. Meyer Cisco Systems P. Traina Juniper Networks March 2000 Generic Routing Encapsulation (GRE) |GRE (Generic Routing Encapsulation) 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. |このドキュメントはインターネットコミュニティに対してインターネット |スタンダードトラックプロトコルを規定し、改善のための議論や提案を |要求するものである。このプロトコルの状況と標準化の状況については、 |"Internet Official Protocol Standards"(STD 1)の最新版を参照のこと。 |このメモの配布に制限はない。 Copyright Notice |著作権表示 Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract |概要 This document specifies a protocol for encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol. |このドキュメントは任意のネットワーク層のプロトコルを他の任意のネット |ワーク層のプロトコル上にカプセル化するためのプロトコルを記述する。 1. Introduction |はじめに A number of different proposals [RFC1234, RFC1226] currently exist for the encapsulation of one protocol over another protocol. Other types of encapsulations [RFC1241, RFC1479] have been proposed for transporting IP over IP for policy purposes. This memo describes a protocol which is very similar to, but is more general than, the above proposals. In attempting to be more general, many protocol specific nuances have been ignored. The result is that this proposal may be less suitable for a situation where a specific "X over Y" encapsulation has been described. It is the attempt of this protocol to provide a simple, general purpose mechanism which reduces the problem of encapsulation from its current O(n^2) size to a more manageable size. This memo purposely does not address the issue of when a packet should be encapsulated. This memo acknowledges, but does not address problems such as mutual encapsulation [RFC1326]. |あるプロトコルを他のプロトコルにカプセル化することについて、現在 |いくつかの異なる提案[RFC1234, RFC1226]が存在する。その他の種類の |カプセル化としては、ある目的のためにIP上にIPを転送するためのもの |が既に提案 [RFC1241, RFC1479] されている。このメモは上記の提案に |非常に似ているが、より一般的なプロトコルを記述している。より一般 |的にしようとするために、多くのプロトコルの特定の差異は無視された。 |この結果、この提案は特定の「Yの上にXを」カプセル化する状況において |は最適ではないかもしれない。このプロトコルはシンプルに、一般的に |使用される現在のO(n^2)サイズからより扱いやすいサイズにカプセル化 |の問題を削減するメカニズムを提供しようとしている。このメモでは、 |相互カプセル化[RFC1326]のような問題を認識しているが、ここでは、 |これを扱わない。 In the most general case, a system has a packet that needs to be encapsulated and delivered to some destination. We will call this the payload packet. The payload is first encapsulated in a GRE packet. The resulting GRE packet can then be encapsulated in some other protocol and then forwarded. We will call this outer protocol the delivery protocol. The algorithms for processing this packet are discussed later. |最も一般的な場合で、システムはカプセル化してどこかの宛先に配送する |必要のあるパケットをもっている。我々はこれをペイロードパケット(/ |payload packet)と呼ぶ。ペイロードはGREパケットで最初にカプセル化 |される。その結果として生じたGREパケットは、他のなんらかのプロトコル |にカプセル化されて、その後に転送される。我々はこの外側のプロトコルを |配送プロトコル(/delivery protocol)と呼ぶ。このパケットを処理するアル |ゴリズムは後で議論する。 Finally this specification describes the intersection of GRE currently deployed by multiple vendors. |最後に、この仕様書は、複数のベンダによって展開されている現在のGREの |相互動作について記述する。 The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED, SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as defined in RFC 2119 [RFC2119]. |キーワード MUST、MUST NOT、MAY、OPTIONAL、REQUIRED、RECOMMENDED、 |SHALL、SHALL NOT、SHOULD、SHOULD NOTは、RFC2119での定義で解釈される。 2. Structure of a GRE Encapsulated Packet |GREカプセル化パケットの構造 A GRE encapsulated packet has the form: |GREカプセル化パケットは次のフォームをもつ: --------------------------------- | | | Delivery Header | | | --------------------------------- | | | GRE Header | | | --------------------------------- | | | Payload packet | | | --------------------------------- This specification is generally concerned with the structure of the GRE header, although special consideration is given to some of the issues surrounding IPv4 payloads. |この仕様書は、IPv4ペイロードを取り巻くいくつかの議論を特に扱っては |いるが、GREヘッダの構造に関する全体のものである。 2.1. GRE Header |GREヘッダ The GRE packet header has the form: |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| Reserved0 | Ver | Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum (optional) | Reserved1 (Optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2.2. Checksum Present (bit 0) |Checksum Present (ビット 0) If the Checksum Present bit is set to one, then the Checksum and the Reserved1 fields are present and the Checksum field contains valid information. Note that a compliant implementation MUST accept and process this field. |もし Checksum Present ビットが設定されていれば、Checksum と |Reserved1 フィールドが提供されていて、Checksumフィールドには |有効な情報が含まれている。準拠した実装はこのフィールドを受け |つけ処理しなければならない[MUST]。 2.3. Reserved0 (bits 1-12) |Reserved0 (ビット 1-12) A receiver MUST discard a packet where any of bits 1-5 are non-zero, unless that receiver implements RFC 1701. Bits 6-12 are reserved for future use. These bits MUST be sent as zero and MUST be ignored on receipt. |レシーバは、レシーバがRFC1701を実装していない限り、ビット1-5の |どれかがゼロでなければパケットを破棄しなければならない[MUST]。 |ビット6-12は将来の使用のために予約されている。これらのビットは |ゼロで送信しなければならず[MUST]、受信時には無視しなければなら |ない[MUST]。 2.3.1. Version Number (bits 13-15) |Version Number (ビット 13-15) The Version Number field MUST contain the value zero. |Version Number フィールドには値0が入っていなければならない[MUST]。 2.4. Protocol Type (2 octets) |Protocol Type (2 オクテット) The Protocol Type field contains the protocol type of the payload packet. These Protocol Types are defined in [RFC1700] as "ETHER TYPES" and in [ETYPES]. An implementation receiving a packet containing a Protocol Type which is not listed in [RFC1700] or [ETYPES] SHOULD discard the packet. |Protocol Typeフィールドにはペイロードパケットのプロトコル種別が |入っている。これらのプロトコル種別は[RFC1700]に「ETHER TYPE」と |して、及び、[ETYPES] に定義されている。[RFC1700] 又は [ETYPES]の |にリストされていないプロトコル種別が入ったパケットを受信した場合、 |実装はそのパケットを破棄すべきである[SHOULD]。 2.5. Checksum (2 octets) |Checksum (2 オクテット) The Checksum field contains the IP (one's complement) checksum sum of the all the 16 bit words in the GRE header and the payload packet. For purposes of computing the checksum, the value of the checksum field is zero. This field is present only if the Checksum Present bit is set to one. |Checksum フィールドには、GRE ヘッダとペイロードパケットの全ての 16 |ビットワードを合計したIP(1の補数)チェックサムが入っている。チェック |サムの計算のためのチェックサムフィールドの値はゼロである。このフィー |ルドは、Checksum Present ビットが 1にセットされている場合にだけ、提 |供される。 2.6. Reserved1 (2 octets) |Reserved1 (2 オクテット) The Reserved1 field is reserved for future use, and if present, MUST be transmitted as zero. The Reserved1 field is present only when the Checksum field is present (that is, Checksum Present bit is set to one). |Reserved1フィールドは将来の使用のために予約されていて、存在する場合 |ゼロで送信しなければならない。Reserved1フィールドは、Checksumフィー |ルドが存在する場合のみ存在する (これは、Checksum Presentビットが 1 |に設定されていることである)。 3. IPv4 as a Payload |ペイロードとしてのIPv4 When IPv4 is being carried as the GRE payload, the Protocol Type field MUST be set to 0x800. |IPv4 が GREペイロードとして運ばれる際、Protocol Typeフィールドは |0x800に設定しなければならない[MUST]。 3.1. Forwarding Decapsulated IPv4 Payload Packets |カプセル化されたIPv4ペイロードパケットの転送 When a tunnel endpoint decapsulates a GRE packet which has an IPv4 packet as the payload, the destination address in the IPv4 payload packet header MUST be used to forward the packet and the TTL of the payload packet MUST be decremented. Care should be taken when forwarding such a packet, since if the destination address of the payload packet is the encapsulator of the packet (i.e., the other end of the tunnel), looping can occur. In this case, the packet MUST be discarded. |トンネルエンドポイントで IPv4 パケットをペイロードとしてもつ GRE |パケットを逆カプセル化する際、IPv4 ペイロードパケットヘッダの宛先 |アドレスは転送アドレスとして使用され[MUST]、ペイロードパケットの |TTL は -1 される [MUST]。 このようなパケットを転送する際に、もし |ペイロードパケットの宛先アドレスがパケットのエンカプセレータ(例えば、 |他のトンネルの終端)であった場合、ループが発生してしまうので注意しな |ければならない。このような場合、パケットは破棄されなければならない |[MUST]。 4. IPv4 as a Delivery Protocol |配送プロトコルとしてのIPv4 The IPv4 protocol 47 [RFC1700] is used when GRE packets are enapsulated in IPv4. See [RFC1122] for requirements relating to the delivery of packets over IPv4 networks. |IPv4 に GREパケットがカプセル化された場合、IPv4プロトコル 47 |[RFC1700] が使用される。IPv4ネットワーク上でのパケット配送に |関する要求は [RFC1122] を見よ。 5. Interoperation with RFC 1701 Compliant Implementations |RFC1701に準拠した実装との相互動作 In RFC 1701, the field described here as Reserved0 contained a number of flag bits which this specification deprecates. In particular, the Routing Present, Key Present, Sequence Number Present, and Strict Source Route bits have been deprecated, along with the Recursion Control field. As a result, the GRE header will never contain the Key, Sequence Number or Routing fields specified in RFC 1701. |RFC1701において、ここで Reserved0 として記述されている、いくつかの |フラグビットで構成されたフィールドは、批判されている。特に、Routing |Present、Key Present、Sequence Number Present 及び Strict Source Route |ビットは Recursion Control field と共に批判されている。結果として、GRE |ヘッダは、RFC1701に記述されているような、Key、Sequence Number 又は |Routingフィールドを含めることはなかった。 There are, however, existing implementations of RFC 1701. The following sections describe correct interoperation with such implementations. |しかしながら、RFC1701の実装は既に存在する。以下のセクションでは |このような実装と、正常に相互動作させることについて記述する。 5.1. RFC 1701 Compliant Receiver |RFC1701に準拠したレシーバ An implementation complying to this specification will transmit the Reserved0 field set to zero. An RFC 1701 compliant receiver will interpret this as having the Routing Present, Key Present, Sequence Number Present, and Strict Source Route bits set to zero, and will not expect the RFC 1701 Key, Sequence Number or Routing fields to be present. |この仕様書に従った実装はReserved0フィールドにゼロを設定して送信する。 |RFC1701に準拠したレシーバは、Routing Present、Key Present、Sequence |Number Present 及び Strict Source Route にゼロが設定されていると解釈 |し、RFC 1701 Key、Sequence Number 又は Routing フィールドが存在する |と思わせない。 5.2. RFC 1701 Compliant Transmitter |RFC1701に準拠したトランスミッタ An RFC 1701 transmitter may set any of the Routing Present, Key Present, Sequence Number Present, and Strict Source Route bits set to one, and thus may transmit the RFC 1701 Key, Sequence Number or Routing fields in the GRE header. As stated in Section 5.3, a packet with non-zero bits in any of bits 1-5 MUST be discarded unless the receiver implements RFC 1701. |RFC1701トランスミッタは、Routing Present、Key Present、Sequence Number |Present 及び Strict Source Route ビットのどれかに 1 を設定し、GREヘッダ |に、RFC 1701 Key、Sequence Number 又は Routing フィールドをいれて送信 |するかもしれない。セクション5.3に示すように、ビット1-5のどれかのビット |がゼロでないパケットは、RFC1701を実装していないレシーバでは破棄しなけ |ればならない[MUST]。 6. Security Considerations |セキュリティに関する考察 Security in a network using GRE should be relatively similar to security in a normal IPv4 network, as routing using GRE follows the same routing that IPv4 uses natively. Route filtering will remain unchanged. However packet filtering requires either that a firewall look inside the GRE packet or that the filtering is done on the GRE tunnel endpoints. In those environments in which this is considered to be a security issue it may be desirable to terminate the tunnel at the firewall. |GRE を使用したルーティングは IPv4本来のルーティングを使用したものと |同じく従うので、GRE を使用したネットワークのセキュリティは、通常の |IPv4 ネットワークでのセキュリティと同じ関係である。経路のフィルタ |リングは変更されていないままである。しかしながらパケットへのフィルタ |リングの要求は、ファイヤウォールが GREパケットの中を見るか、GREトン |ネリングエンドポイントでフィルタリングを行うかのどちらかである。これ |らの環境では、セキュリティ問題で考えると、ファイヤウォールでトンネル |を終端させることが望ましいであろう。 7. IANA Considerations |IANAの考察 This section considers the assignment of additional GRE Version Numbers and Protocol Types. |このセクションはGREバージョン番号とプロトコル種別の追加について |考察する。 7.1. GRE Version Numbers |GREバージョン番号 This document specifies GRE version number 0. GRE version number 1 is used by PPTP [RFC2637]. Additional GRE version numbers are assigned by IETF Consensus as defined in RFC 2434 [RFC2434]. |このドキュメントはGREバージョン番号0を指定している。GREバージョン |番号1 は PPTP[REF2637]で使用されている。GREバージョン番号の追加は |RFC2343 に定義されているように、IETFの同意によって割り当てられる。 7.2. Protocol Types |プロトコル種別 GRE uses an ETHER Type for the Protocol Type. New ETHER TYPES are assigned by Xerox Systems Institute [RFC1700]. |GRE は Protocol Type に ETHER Type を使用している。新たな ETHER TYPES |は、Xerox Systems Institute [RFC1700] によって割り当てられる。 8. Acknowledgments |謝辞 This document is derived from the original ideas of the authors of RFC 1701 and RFC 1702. Hitoshi Asaeda, Scott Bradner, Randy Bush, Brian Carpenter, Bill Fenner, Andy Malis, Thomas Narten, Dave Thaler, Tim Gleeson and others provided many constructive and insightful comments. |このドキュメントのオリジナルのアイデアは、RFC1701 及び RFC1702の著者、 |Hitoshi Asaeda、Scott Bradner、Randy Bush、Brian Carpenter、Bill Fenner、 |Andy Malis、Thomas Narten、Dave Thaler、Tim Gleeson 及び、多くの積極的 |かつ見識のあるコメントを提供してくれた多くの人々によって得られた。 9. Appendix -- Known Issues |付録 -- 既知の問題 This document specifies the behavior of currently deployed GRE implementations. As such, it does not attempt to address the following known issues: |このドキュメントは現在展開されているGREの実装の振舞いを記述する。 |しかし、以下の既知の問題を扱っていない。 o Interaction Path MTU Discovery (PMTU) [RFC1191] |パスのMTU検出(PMTU)の相互作用 [RFC1191] Existing implementations of GRE, when using IPv4 as the Delivery Header, do not implement Path MTU discovery and do not set the Don't Fragment bit in the Delivery Header. This can cause large packets to become fragmented within the tunnel and reassembled at the tunnel exit (independent of whether the payload packet is using PMTU). If a tunnel entry point were to use Path MTU discovery, however, that tunnel entry point would also need to relay ICMP unreachable error messages (in particular the "fragmentation needed and DF set" code) back to the originator of the packet, which is not a requirement in this specification. Failure to properly relay Path MTU information to an originator can result in the following behavior: the originator sets the don't fragment bit, the packet gets dropped within the tunnel, but since the originator doesn't receive proper feedback, it retransmits with the same PMTU, causing subsequently transmitted packets to be dropped. |GREの実在する実装は、Delivery Header として IPv4 が使用された場合、 |パスのMTUの検出は実装されておらず、Delivery Header の Fragmentビット |は設定されない。これは大きなパケットをトンネル内で分割し、トンネル |の出口で最構築させる要因となる(ペイロードパケットが PMTU を使用して |いるかどうかに依存)。もし、トンネルエンドポイントがパスのMTUの検出を |使用していたとしても、トンネルエントリポイントはパケットの発信者に |対しICMP未到達エラーメッセージ(特に「分割を必要とし、DFをセット」の |コード)をリレーバックすることを必要とし、これはこの仕様書には要求さ |れていない。パスのMTUの情報を適切に発信者に伝達することに失敗する |ことは、以下の振舞いを結果として生じさせる:発信者は分割ビットを設定 |しない、そのパケットはトンネル内で落とされる、しかし発信者は適切な |フィードバックを受信しないので、同じPMTUで再送し、続いて転送される |パケットを落とす要因となる。 o IPv6 as Delivery and/or Payload Protocol |配送及び/又はペイロードプロトコルとしてのIPv6 This specification describes the intersection of GRE currently deployed by multiple vendors. IPv6 as delivery and/or payload protocol is not included in the currently deployed versions of GRE. |この仕様書は複数のベンダによって展開されている現在のGREの相互動作に |ついて記述する。配送及び/又はペイロードプロトコルとしての IPv6 は |GREの現在展開されているバージョンには含まれていない。 o Interaction with ICMP |ICMPとの相互作用 o Interaction with the Differentiated Services Architecture |DiffServアーキテクチャとの相互作用 o Multiple and Looping Encapsulations |複数の及びループするカプセル化 10. REFERENCES |参考 [ETYPES] ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet- numbers [RFC1122] Braden, R., "Requirements for Internet hosts - communication layers", STD 3, RFC 1122, October 1989. [RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990. [RFC1226] Kantor, B., "Internet Protocol Encapsulation of AX.25 Frames", RFC 1226, May 1991. [RFC1234] Provan, D., "Tunneling IPX Traffic through IP Networks", RFC 1234, June 1991. [RFC1241] Woodburn, R. and D. Mills, "Scheme for an Internet Encapsulation Protocol: Version 1", RFC 1241, July 1991. [RFC1326] Tsuchiya, P., "Mutual Encapsulation Considered Dangerous", RFC 1326, May 1992. [RFC1479] Steenstrup, M., "Inter-Domain Policy Routing Protocol Specification: Version 1", RFC 1479, July 1993. [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. [RFC1701] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation", RFC 1701, October 1994. [RFC1702] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing Encapsulation over IPv4 networks", RFC 1702, October 1994. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March, 1997. [RFC2408] Maughan, D., Schertler, M., Schneider, M. and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October, 1998. [RFC2637] Hamzeh, K., et al., "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637, July, 1999. 11. Authors' Addresses |著者の連絡先 Dino Farinacci Procket Networks 3850 No. First St., Ste. C San Jose, CA 95134 EMail: dino@procket.com Tony Li Procket Networks 3850 No. First St., Ste. C San Jose, CA 95134 Phone: +1 408 954 7903 Fax: +1 408 987 6166 EMail: tony1@home.net Stan Hanks Enron Communications EMail: stan_hanks@enron.net David Meyer Cisco Systems, Inc. 170 Tasman Drive San Jose, CA, 95134 EMail: dmm@cisco.com Paul Traina Juniper Networks EMail: pst@juniper.net 12. 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. |RFCエディタの職務のための資金は現在、インターネットソサイエティに |よって提供されている。 -- 訳: O.K.U. ( oku@olive.plala.or.jp ) ( http://kotekote.zatunen.com/rfc/ ) 注: 翻訳内容に関していかなる保障もいたしません。