[要約] RFC 7588は、GREフラグメンテーションの問題に対する広く展開された解決策を提供しています。このRFCの目的は、GREトンネルでのフラグメンテーションの問題を解決し、ネットワークのパフォーマンスと信頼性を向上させることです。
Internet Engineering Task Force (IETF) R. Bonica
Request for Comments: 7588 Juniper Networks
Category: Informational C. Pignataro
ISSN: 2070-1721 Cisco Systems
J. Touch
USC/ISI
July 2015
A Widely Deployed Solution to the Generic Routing Encapsulation (GRE) Fragmentation Problem
Generic Routing Encapsulation（GRE）フラグメンテーション問題に対する広く展開されたソリューション
Abstract
概要
This memo describes how many vendors have solved the Generic Routing Encapsulation (GRE) fragmentation problem. The solution described herein is configurable. It is widely deployed on the Internet in its default configuration.
このメモは、Generic Routing Encapsulation（GRE）フラグメンテーション問題を解決したベンダーの数を説明しています。ここで説明するソリューションは構成可能です。これは、デフォルトの構成でインターネット上に広く展開されています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7588.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7588で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. RFC 4459 Solutions . . . . . . . . . . . . . . . . . . . 5
2.2. A Widely Deployed Solution . . . . . . . . . . . . . . . 5
3. Implementation Details . . . . . . . . . . . . . . . . . . . 6
3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. GRE MTU (GMTU) Estimation and Discovery . . . . . . . . . 6
3.3. GRE Ingress Node Procedures . . . . . . . . . . . . . . . 7
3.3.1. Procedures Affecting the GRE Payload . . . . . . . . 7
3.3.2. Procedures Affecting the GRE Deliver Header . . . . . 8
3.4. GRE Egress Node Procedures . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Normative References . . . . . . . . . . . . . . . . . . 10
5.2. Informative References . . . . . . . . . . . . . . . . . 11
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
Generic Routing Encapsulation (GRE) [RFC2784] [RFC2890] can be used to carry any network-layer protocol over any network-layer protocol. GRE has been implemented by many vendors and is widely deployed in the Internet.
Generic Routing Encapsulation（GRE）[RFC2784] [RFC2890]を使用すると、任意のネットワーク層プロトコルを介して任意のネットワーク層プロトコルを伝送できます。 GREは多くのベンダーによって実装されており、インターネットで広く展開されています。
The GRE specification does not describe fragmentation procedures. Lacking guidance from the specification, vendors have developed implementation-specific fragmentation solutions. A GRE tunnel will operate correctly only if its ingress and egress nodes support compatible fragmentation solutions. [RFC4459] describes several fragmentation solutions and evaluates their relative merits.
GRE仕様では、断片化手順については説明されていません。仕様からのガイダンスがないため、ベンダーは実装固有の断片化ソリューションを開発しています。 GREトンネルは、入力ノードと出力ノードが互換性のあるフラグメンテーションソリューションをサポートしている場合にのみ正しく動作します。 [RFC4459]はいくつかの断片化ソリューションを説明し、それらの相対的なメリットを評価します。
This memo reviews the fragmentation solutions presented in [RFC4459]. It also describes how many vendors have solved the GRE fragmentation problem. The solution described herein is configurable and has been widely deployed in its default configuration.
このメモは、[RFC4459]で提示された断片化ソリューションをレビューします。また、GREの断片化の問題を解決したベンダーの数についても説明します。ここで説明するソリューションは構成可能であり、デフォルトの構成で広く展開されています。
This memo addresses point-to-point unicast GRE tunnels that carry IPv4, IPv6, or MPLS payloads over IPv4 or IPv6. All other tunnel types are beyond the scope of this document.
このメモは、IPv4またはIPv6を介してIPv4、IPv6、またはMPLSペイロードを伝送するポイントツーポイントユニキャストGREトンネルを扱います。他のすべてのトンネルタイプは、このドキュメントの範囲外です。
The following terms are specific to GRE:
次の用語はGREに固有のものです。
o GRE delivery header - an IPv4 or IPv6 header whose source address represents the GRE ingress node and whose destination address represents the GRE egress node. The GRE delivery header encapsulates a GRE header.
o GRE配信ヘッダー-ソースアドレスがGRE入力ノードを表し、宛先アドレスがGRE出力ノードを表すIPv4またはIPv6ヘッダー。 GRE配信ヘッダーは、GREヘッダーをカプセル化します。
o GRE header - the GRE protocol header. The GRE header is encapsulated in the GRE delivery header and encapsulates the GRE payload.
o GREヘッダー-GREプロトコルヘッダー。 GREヘッダーはGRE配信ヘッダーにカプセル化され、GREペイロードをカプセル化します。
o GRE payload - a network-layer packet that is encapsulated by the GRE header. The GRE payload can be IPv4, IPv6, or MPLS. Procedures for encapsulating IPv4 in GRE are described in [RFC2784] and [RFC2890]. Procedures for encapsulating IPv6 in GRE are described in [IPv6-GRE]. Procedures for encapsulating MPLS in GRE are described in [RFC4023]. While other protocols may be delivered over GRE, they are beyond the scope of this document.
o GREペイロード-GREヘッダーによってカプセル化されるネットワーク層パケット。 GREペイロードは、IPv4、IPv6、またはMPLSにすることができます。 GREでIPv4をカプセル化する手順は、[RFC2784]および[RFC2890]で説明されています。 GREでIPv6をカプセル化する手順は、[IPv6-GRE]で説明されています。 GREでMPLSをカプセル化する手順は、[RFC4023]で説明されています。他のプロトコルがGREを介して配信される場合がありますが、それらはこのドキュメントの範囲外です。
o GRE delivery packet - a packet containing a GRE delivery header, a GRE header, and the GRE payload.
o GRE配信パケット-GRE配信ヘッダー、GREヘッダー、およびGREペイロードを含むパケット。
o GRE payload header - the IPv4, IPv6, or MPLS header of the GRE payload.
o GREペイロードヘッダー-GREペイロードのIPv4、IPv6、またはMPLSヘッダー。
o GRE overhead - the combined size of the GRE delivery header and the GRE header, measured in octets.
o GREオーバーヘッド-オクテットで測定された、GRE配信ヘッダーとGREヘッダーの合計サイズ。
The following terms are specific to MTU discovery:
以下の用語は、MTUディスカバリーに固有のものです。
o Link MTU (LMTU) - the maximum transmission unit, i.e., maximum packet size in octets, that can be conveyed over a link. LMTU is a unidirectional metric. A bidirectional link may be characterized by one LMTU in the forward direction and another LMTU in the reverse direction.
o リンクMTU（LMTU）-リンクを介して伝送できる最大伝送単位（オクテット単位の最大パケットサイズ）。 LMTUは単方向のメトリックです。双方向リンクは、順方向の1つのLMTUと逆方向の別のLMTUによって特徴付けられます。
o Path MTU (PMTU) - the minimum LMTU of all the links in a path between a source node and a destination node. If the source and destination nodes are connected through an Equal-Cost Multipath (ECMP), the PMTU is equal to the minimum LMTU of all links contributing to the multipath.
o パスMTU（PMTU）-ソースノードと宛先ノード間のパス内のすべてのリンクの最小LMTU。送信元ノードと宛先ノードが等コストマルチパス（ECMP）を介して接続されている場合、PMTUはマルチパスに寄与するすべてのリンクの最小LMTUと等しくなります。
o GRE MTU (GMTU) - the maximum transmission unit, i.e., maximum packet size in octets, that can be conveyed over a GRE tunnel without fragmentation of any kind. The GMTU is equal to the PMTU associated with the path between the GRE ingress and the GRE egress nodes minus the GRE overhead.
o GRE MTU（GMTU）-あらゆる種類の断片化なしにGREトンネルを介して伝達できる最大伝送単位、つまりオクテット単位の最大パケットサイズ。 GMTUは、GRE入力ノードとGRE出力ノードの間のパスに関連付けられたPMTUからGREオーバーヘッドを引いた値に等しくなります。
o Path MTU Discovery (PMTUD) - a procedure for dynamically discovering the PMTU between two nodes on the Internet. PMTUD procedures for IPv4 are defined in [RFC1191]. PMTUD procedures for IPv6 are defined in [RFC1981].
o パスMTU発見（PMTUD）-インターネット上の2つのノード間のPMTUを動的に発見するための手順。 IPv4のPMTUD手順は[RFC1191]で定義されています。 IPv6のPMTUD手順は[RFC1981]で定義されています。
The following terms are introduced by this memo:
このメモでは、次の用語が導入されています。
o Fragmentable Packet - a packet that can be fragmented by the GRE ingress node before being transported over a GRE tunnel. That is, an IPv4 packet with the Don't Fragment (DF) bit equal to 0 and whose payload is larger than 64 bytes. IPv6 packets are not fragmentable.
o フラグメント化可能なパケット-GREトンネルを介して転送される前に、GRE入力ノードによってフラグメント化できるパケット。つまり、Do n't Fragment（DF）ビットが0で、ペイロードが64バイトより大きいIPv4パケット。 IPv6パケットはフラグメント化できません。
o ICMP Packet Too Big (PTB) message - an ICMPv4 [RFC792] Destination Unreachable message (Type = 3) with code equal to 4 (fragmentation needed and DF set) or an ICMPv6 [RFC4443] Packet Too Big message (Type = 2).
o ICMPパケットが大きすぎます（PTB）メッセージ-コードが4に等しいICMPv4 [RFC792]宛先到達不能メッセージ（タイプ= 3）（フラグメンテーションが必要、DFが設定されています）またはICMPv6 [RFC4443]パケットが大きすぎますメッセージ（タイプ= 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 RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
Section 3 of [RFC4459] identifies several tunnel fragmentation solutions. These solutions define procedures to be invoked when the tunnel ingress router receives a packet so large that it cannot be forwarded through the tunnel without fragmentation of any kind. When applied to GRE, these procedures are:
[RFC4459]のセクション3は、いくつかのトンネルフラグメンテーションソリューションを示しています。これらのソリューションは、トンネルの入口ルーターが非常に大きなパケットを受信したときに呼び出される手順を定義しています。これらの手順をGREに適用すると、次のようになります。
1. Discard the incoming packet and send an ICMP PTB message to the incoming packet's source.
1. 着信パケットを破棄し、ICMP PTBメッセージを着信パケットのソースに送信します。
2. Fragment the incoming packet and encapsulate each fragment within a complete GRE header and GRE delivery header.
2. 着信パケットをフラグメント化し、各フラグメントを完全なGREヘッダーとGRE配信ヘッダー内にカプセル化します。
3. Encapsulate the incoming packet in a single GRE header and GRE delivery header. Perform source fragmentation on the resulting GRE delivery packet.
3. 着信パケットを単一のGREヘッダーとGRE配信ヘッダーにカプセル化します。結果のGRE配信パケットでソースフラグメンテーションを実行します。
As per RFC 4459, Strategy 2 is applicable only when the incoming packet is fragmentable. Also as per RFC 4459, each strategy has its relative merits and costs.
RFC 4459に従って、戦略2は着信パケットがフラグメント化可能な場合にのみ適用できます。また、RFC 4459によると、各戦略には相対的なメリットとコストがあります。
Many vendors have implemented a configurable GRE fragmentation solution. In its default configuration, the solution behaves as follows:
多くのベンダーが構成可能なGREフラグメンテーションソリューションを実装しています。デフォルトの構成では、ソリューションは次のように動作します。
o When the GRE ingress node receives a fragmentable packet with length greater than the GMTU, it fragments the incoming packet and encapsulates each fragment within a complete GRE header and GRE delivery header. Fragmentation logic is as specified by the payload protocol.
o GRE入力ノードは、GMTUより長いフラグメント化可能なパケットを受信すると、着信パケットをフラグメント化し、完全なGREヘッダーとGRE配信ヘッダー内に各フラグメントをカプセル化します。フラグメンテーションロジックは、ペイロードプロトコルで指定されているとおりです。
o When the GRE ingress node receives a non-fragmentable packet with length greater than the GMTU, it discards the packet and sends an ICMP PTB message to the packet's source.
o GRE入力ノードは、GMTUを超える長さのフラグメント化できないパケットを受信すると、そのパケットを破棄し、ICMP PTBメッセージをパケットの送信元に送信します。
o When the GRE egress node receives a GRE delivery packet fragment, it silently discards the fragment without attempting to reassemble the GRE delivery packet to which the fragment belongs.
o GRE出力ノードがGRE配信パケットフラグメントを受信すると、フラグメントが属するGRE配信パケットを再構成することなく、フラグメントをサイレントに破棄します。
In non-default configurations, the GRE ingress node can execute any of the procedures defined in RFC 4459.
デフォルト以外の構成では、GRE入力ノードはRFC 4459で定義されている任意の手順を実行できます。
The solution described above is widely deployed on the Internet in its default configuration. However, the default configuration is not always appropriate for GRE tunnels that carry IPv6.
上記のソリューションは、デフォルトの構成でインターネットに広く導入されています。ただし、デフォルトの設定は、IPv6を伝送するGREトンネルには必ずしも適切ではありません。
IPv6 requires that every link in the Internet have an MTU of 1280 octets or greater. On any link that cannot convey a 1280-octet packet in one piece, link-specific fragmentation and reassembly must be provided at a layer below IPv6.
IPv6では、インターネットのすべてのリンクのMTUが1280オクテット以上である必要があります。 1280オクテットのパケットを1つにまとめて伝送できないリンクでは、リンク固有のフラグメンテーションと再構成をIPv6の下のレイヤーで提供する必要があります。
Therefore, the default configuration is appropriate for tunnels that carry IPv6 only if the network is engineered so that the GMTU is guaranteed to be 1280 bytes or greater. In all other scenarios, a non-default configuration is required.
したがって、デフォルトの構成は、GMTUが1280バイト以上であることが保証されるようにネットワークが設計されている場合にのみ、IPv6を伝送するトンネルに適しています。他のすべてのシナリオでは、デフォルト以外の構成が必要です。
In the non-default configuration, when the GRE ingress router receives a packet lager than the GMTU, the GRE ingress router encapsulates the entire packet in a single GRE and delivery header. It then fragments the delivery header and sends the resulting fragments to the GRE egress node, where they are reassembled.
デフォルト以外の構成では、GRE入力ルーターがGMTUよりも大きいパケットを受信すると、GRE入力ルーターはパケット全体を単一のGREおよび配信ヘッダーにカプセル化します。次に、配信ヘッダーをフラグメント化し、結果のフラグメントをGRE出力ノードに送信し、そこで再構成されます。
This section describes how many vendors have implemented the solution described in Section 2.2.
このセクションでは、セクション2.2で説明したソリューションを実装したベンダーの数について説明します。
The GRE ingress nodes satisfy all of the requirements stated in [RFC2784].
GRE入力ノードは、[RFC2784]で述べられているすべての要件を満たしています。
GRE ingress nodes support a configuration option that associates a GMTU with a GRE tunnel. By default, GMTU is equal to the MTU associated with the next hop toward the GRE egress node minus the GRE overhead.
GRE入力ノードは、GMTUをGREトンネルに関連付ける構成オプションをサポートしています。デフォルトでは、GMTUはGRE出力ノードへのネクストホップに関連付けられたMTUからGREオーバーヘッドを差し引いた値に等しくなります。
Typically, GRE ingress nodes further refine their GMTU estimate by executing PMTUD procedures. However, if an implementation supports PMTUD for GRE tunnels, it also includes a configuration option that disables PMTUD. This configuration option is required to mitigate certain denial-of-service attacks (see Section 4).
通常、GRE入力ノードは、PMTUD手順を実行することにより、GMTUの見積もりをさらに調整します。ただし、実装がGREトンネルのPMTUDをサポートしている場合は、PMTUDを無効にする構成オプションも含まれています。この構成オプションは、特定のサービス拒否攻撃を軽減するために必要です（セクション4を参照）。
The GRE ingress node's estimate of the GMTU will not always be accurate. It is only an estimate. When the GMTU changes, the GRE ingress node will not discover that change immediately. Likewise, if the GRE ingress node performs PMTUD procedures and interior nodes cannot deliver ICMP feedback to the GRE ingress node, GMTU estimates may be inaccurate.
GRE入力ノードのGMTUの推定値は常に正確であるとは限りません。あくまでも目安です。 GMTUが変更されると、GRE入力ノードはその変更をすぐには検出しません。同様に、GRE入力ノードがPMTUD手順を実行し、内部ノードがGMP入力ノードにICMPフィードバックを配信できない場合、GMTUの見積もりは不正確になる可能性があります。
This section defines procedures that GRE ingress nodes execute when they receive a packet whose size is greater than the relevant GMTU.
このセクションでは、関連するGMTUより大きいサイズのパケットを受信したときにGRE入力ノードが実行する手順を定義します。
By default, if the payload is fragmentable, the GRE ingress node fragments the incoming packet and encapsulates each fragment within a complete GRE header and GRE delivery header. Therefore, the GRE egress node receives several complete, non-fragmented delivery packets. Each delivery packet contains a fragment of the GRE payload. The GRE egress node forwards the payload fragments to their ultimate destination where they are reassembled.
デフォルトでは、ペイロードがフラグメント化可能な場合、GRE入力ノードは着信パケットをフラグメント化し、完全なGREヘッダーとGRE配信ヘッダー内に各フラグメントをカプセル化します。したがって、GRE出力ノードは、いくつかの完全で断片化されていない配信パケットを受信します。各配信パケットには、GREペイロードのフラグメントが含まれています。 GRE出力ノードは、ペイロードフラグメントを最終的な宛先に転送し、そこで再構成されます。
Also by default, if the payload is not fragmentable, the GRE ingress node discards the packet and sends an ICMPv4 Destination Unreachable message to the packet's source. The ICMPv4 Destination Unreachable message code equals 4 (fragmentation needed and DF set). The ICMPv4 Destination Unreachable message also contains a next-hop MTU (as specified by [RFC1191]), and the next-hop MTU is equal to the GMTU associated with the tunnel.
また、デフォルトでは、ペイロードがフラグメント化できない場合、GRE入力ノードはパケットを破棄し、ICMPv4 Destination Unreachableメッセージをパケットの送信元に送信します。 ICMPv4宛先到達不能メッセージコードは4（フラグメンテーションが必要であり、DFが設定されている）です。 ICMPv4宛先到達不能メッセージにはネクストホップMTU（[RFC1191]で指定）も含まれており、ネクストホップMTUはトンネルに関連付けられたGMTUと同じです。
The GRE ingress node supports a non-default configuration option that invokes an alternative behavior. If that option is configured, the GRE ingress node fragments the delivery packet. See Section 3.3.2 for details.
GRE入力ノードは、代替動作を呼び出すデフォルト以外の設定オプションをサポートしています。そのオプションが設定されている場合、GRE入力ノードは配信パケットをフラグメント化します。詳細については、セクション3.3.2を参照してください。
By default, the GRE ingress node discards the packet and sends an ICMPv6 [RFC4443] Packet Too Big message to the payload source. The MTU specified in the Packet Too Big message is equal to the GMTU associated with the tunnel.
デフォルトでは、GRE入力ノードはパケットを破棄し、ICMPv6 [RFC4443] Packet Too Bigメッセージをペイロードソースに送信します。 Packet Too Bigメッセージで指定されたMTUは、トンネルに関連付けられたGMTUと同じです。
The GRE ingress node supports a non-default configuration option that invokes an alternative behavior. If that option is configured, the GRE ingress node fragments the delivery packet. See Section 3.3.2 for details.
GRE入力ノードは、代替動作を呼び出すデフォルト以外の設定オプションをサポートしています。そのオプションが設定されている場合、GRE入力ノードは配信パケットをフラグメント化します。詳細については、セクション3.3.2を参照してください。
By default, the GRE ingress node discards the packet. As it is impossible to reliably identify the payload source, the GRE ingress node does not attempt to send an ICMP PTB message to the payload source.
デフォルトでは、GRE入力ノードはパケットを破棄します。ペイロードソースを確実に識別することは不可能であるため、GRE入力ノードはICMP PTBメッセージをペイロードソースに送信しようとしません。
The GRE ingress node supports a non-default configuration option that invokes an alternative behavior. If that option is configured, the GRE ingress node fragments the delivery packet. See Section 3.3.2 for details.
GRE入力ノードは、代替動作を呼び出すデフォルト以外の設定オプションをサポートしています。そのオプションが設定されている場合、GRE入力ノードは配信パケットをフラグメント化します。詳細については、セクション3.3.2を参照してください。
By default, the GRE ingress node does not fragment delivery packets. However, the GRE ingress node includes a configuration option that allows delivery packet fragmentation.
デフォルトでは、GRE入力ノードは配信パケットをフラグメント化しません。ただし、GRE入力ノードには、配信パケットの断片化を可能にする構成オプションが含まれています。
By default, the GRE ingress node sets the DF bit in the delivery header to 1 (Don't Fragment). However, the GRE ingress node also supports a configuration option that invokes the following behavior:
デフォルトでは、GRE入力ノードは配信ヘッダーのDFビットを1（フラグメントしない）に設定します。ただし、GRE入力ノードは、次の動作を呼び出す構成オプションもサポートしています。
o When the GRE payload is IPv6, the DF bit on the delivery header is set to 0 (Fragments Allowed).
o GREペイロードがIPv6の場合、配信ヘッダーのDFビットは0（フラグメント許可）に設定されます。
o When the GRE payload is IPv4, the DF bit is copied from the payload header to the delivery header.
o GREペイロードがIPv4の場合、DFビットはペイロードヘッダーから配信ヘッダーにコピーされます。
When the DF bit on an IPv4 delivery header is set to 0, the GRE delivery packet can be fragmented by any router between the GRE ingress and egress nodes.
IPv4配信ヘッダーのDFビットが0に設定されている場合、GRE入力ノードと出力ノードの間のルーターはGRE配信パケットをフラグメント化できます。
If the GRE egress node is configured to support reassembly, it will reassemble fragmented delivery packets. Otherwise, the GRE egress node will discard delivery packet fragments.
GRE出力ノードが再構成をサポートするように構成されている場合、フラグメント化された配信パケットを再構成します。そうでない場合、GRE出力ノードは配信パケットフラグメントを破棄します。
By default, the GRE ingress node does not fragment delivery packets. However, the GRE ingress node includes a configuration option that allows this.
デフォルトでは、GRE入力ノードは配信パケットをフラグメント化しません。ただし、GRE入力ノードには、これを可能にする構成オプションが含まれています。
If the GRE egress node is configured to support reassembly, it will reassemble fragmented delivery packets. Otherwise, the GRE egress node will discard delivery packet fragments.
GRE出力ノードが再構成をサポートするように構成されている場合、フラグメント化された配信パケットを再構成します。そうでない場合、GRE出力ノードは配信パケットフラグメントを破棄します。
By default, the GRE egress node silently discards GRE delivery packet fragments without attempting to reassemble the GRE delivery packets to which the fragments belongs.
デフォルトでは、GRE出力ノードは、フラグメントが属するGRE配信パケットを再構成することなく、サイレントにGRE配信パケットフラグメントを破棄します。
However, the GRE egress node supports a configuration option that allows it to reassemble GRE delivery packets.
ただし、GRE出力ノードは、GRE配信パケットを再構成できるようにする構成オプションをサポートしています。
In the GRE fragmentation solution described above, either the GRE payload or the GRE delivery packet can be fragmented. If the GRE payload is fragmented, it is typically reassembled at its ultimate destination. If the GRE delivery packet is fragmented, it is typically reassembled at the GRE egress node.
上記のGREフラグメント化ソリューションでは、GREペイロードまたはGRE配信パケットのいずれかをフラグメント化できます。 GREペイロードがフラグメント化されている場合、通常は最終的な宛先で再構成されます。 GRE配信パケットがフラグメント化されている場合、通常はGRE出力ノードで再構成されます。
The packet reassembly process is resource intensive and vulnerable to several denial-of-service attacks. In the simplest attack, the attacker sends fragmented packets more quickly than the victim can reassemble them. In a variation on that attack, the first fragment of each packet is missing so that no packet can ever be reassembled.
パケットの再構成プロセスはリソースを大量に消費し、いくつかのサービス拒否攻撃に対して脆弱です。最も単純な攻撃では、攻撃者は断片化されたパケットを、被害者が再構築するよりも速く送信します。その攻撃のバリエーションでは、各パケットの最初のフラグメントが欠落しているため、パケットを再構成することはできません。
Given that the packet reassembly process is resource intensive and vulnerable to denial-of-service attacks, operators should decide where the reassembly process is best performed. Having made that decision, they should decide whether to fragment the GRE payload or GRE delivery packet accordingly.
パケットの再構成プロセスはリソースを大量に消費し、サービス拒否攻撃に対して脆弱であることを考えると、オペレーターは、再構成プロセスが最適に実行される場所を決定する必要があります。その決定を行ったら、GREペイロードまたはGRE配信パケットを適宜フラグメント化するかどうかを決定する必要があります。
Some IP implementations are vulnerable to the Overlapping Fragment Attack [RFC1858]. This vulnerability is not specific to GRE and needs to be considered in all environments where IP fragmentation is present. [RFC3128] describes a procedure by which IPv4 implementations can partially mitigate the vulnerability. [RFC5722] mandates a procedure by which IPv6-compliant implementations are required to mitigate the vulnerability. The procedure described in RFC 5722 completely mitigates the vulnerability. Operators SHOULD ensure that the vulnerability is mitigated to their satisfaction on equipment that they deploy.
一部のIP実装は、重複フラグメント攻撃[RFC1858]に対して脆弱です。この脆弱性はGREに固有のものではなく、IPフラグメンテーションが存在するすべての環境で考慮する必要があります。 [RFC3128]は、IPv4実装が脆弱性を部分的に緩和できる手順を説明しています。 [RFC5722]は、脆弱性を緩和するためにIPv6準拠の実装が必要となる手順を義務付けています。 RFC 5722で説明されている手順により、脆弱性が完全に緩和されます。事業者は、展開する機器に対する満足度が高まるように脆弱性を緩和する必要があります。
PMTUD is vulnerable to two denial-of-service attacks (see Section 8 of [RFC1191] for details). Both attacks are based upon on a malicious party sending forged ICMPv4 Destination Unreachable or ICMPv6 Packet Too Big messages to a host. In the first attack, the forged message indicates an inordinately small PMTU. In the second attack, the forged message indicates an inordinately large MTU. In both cases, throughput is adversely affected. In order to mitigate such attacks, GRE implementations include a configuration option to disable PMTUD on GRE tunnels. Also, they can include a configuration option that conditions the behavior of PMTUD to establish a minimum PMTU.
PMTUDは2つのサービス拒否攻撃に対して脆弱です（詳細については、[RFC1191]のセクション8を参照してください）。どちらの攻撃も、偽造されたICMPv4 Destination UnreachableまたはICMPv6 Packet Too Bigメッセージをホストに送信する悪意のあるパーティに基づいています。最初の攻撃では、偽造されたメッセージが異常に小さいPMTUを示しています。 2番目の攻撃では、偽造されたメッセージが異常に大きなMTUを示しています。どちらの場合も、スループットが低下します。このような攻撃を緩和するために、GRE実装には、GREトンネルでPMTUDを無効にする設定オプションが含まれています。また、最小PMTUを確立するためにPMTUDの動作を調整する構成オプションを含めることもできます。
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, <http://www.rfc-editor.org/info/rfc792>.
[RFC792] Postel、J。、「インターネット制御メッセージプロトコル」、STD 5、RFC 792、DOI 10.17487 / RFC0792、1981年9月、<http://www.rfc-editor.org/info/rfc792>。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990, <http://www.rfc-editor.org/info/rfc1191>.
[RFC1191] Mogul、J。およびS. Deering、「Path MTU discovery」、RFC 1191、DOI 10.17487 / RFC1191、1990年11月、<http://www.rfc-editor.org/info/rfc1191>。
[RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security Considerations for IP Fragment Filtering", RFC 1858, DOI 10.17487/RFC1858, October 1995, <http://www.rfc-editor.org/info/rfc1858>.
[RFC1858] Ziemba、G.、Reed、D。、およびP. Traina、「IPフラグメントフィルタリングのセキュリティに関する考慮事項」、RFC 1858、DOI 10.17487 / RFC1858、1995年10月、<http://www.rfc-editor.org / info / rfc1858>。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 1996, <http://www.rfc-editor.org/info/rfc1981>.
[RFC1981] McCann、J.、Deering、S。、およびJ. Mogul、「Path MTU Discovery for IP version 6」、RFC 1981、DOI 10.17487 / RFC1981、1996年8月、<http：//www.rfc-editor。 org / info / rfc1981>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, DOI 10.17487/RFC2784, March 2000, <http://www.rfc-editor.org/info/rfc2784>.
[RFC2784] Farinacci、D.、Li、T.、Hanks、S.、Meyer、D。、およびP. Traina、「Generic Routing Encapsulation（GRE）」、RFC 2784、DOI 10.17487 / RFC2784、2000年3月、<http ：//www.rfc-editor.org/info/rfc2784>。
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, DOI 10.17487/RFC2890, September 2000, <http://www.rfc-editor.org/info/rfc2890>.
[RFC2890] Dommety、G。、「GREのキーとシーケンス番号の拡張」、RFC 2890、DOI 10.17487 / RFC2890、2000年9月、<http://www.rfc-editor.org/info/rfc2890>。
[RFC3128] Miller, I., "Protection Against a Variant of the Tiny Fragment Attack (RFC 1858)", RFC 3128, DOI 10.17487/RFC3128, June 2001, <http://www.rfc-editor.org/info/rfc3128>.
[RFC3128]ミラー、I。、「小さなフラグメント攻撃のバリアントからの保護（RFC 1858）」、RFC 3128、DOI 10.17487 / RFC3128、2001年6月、<http://www.rfc-editor.org/info/ rfc3128>。
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005, <http://www.rfc-editor.org/info/rfc4023>.
[RFC4023] Worster、T.、Rekhter、Y。、およびE. Rosen、編、「IPまたはGeneric Routing Encapsulation（GRE）でのMPLSのカプセル化」、RFC 4023、DOI 10.17487 / RFC4023、2005年3月、<http：/ /www.rfc-editor.org/info/rfc4023>。
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, DOI 10.17487/RFC4443, March 2006, <http://www.rfc-editor.org/info/rfc4443>.
[RFC4443] Conta、A.、Deering、S。、およびM. Gupta、編、「インターネットプロトコルバージョン6（IPv6）仕様のインターネット制御メッセージプロトコル（ICMPv6）」、RFC 4443、DOI 10.17487 / RFC4443、3月2006、<http://www.rfc-editor.org/info/rfc4443>。
[RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", RFC 5722, DOI 10.17487/RFC5722, December 2009, <http://www.rfc-editor.org/info/rfc5722>.
[RFC5722] Krishnan、S。、「Handling of Overlapping IPv6 Fragments」、RFC 5722、DOI 10.17487 / RFC5722、2009年12月、<http://www.rfc-editor.org/info/rfc5722>。
[IPv6-GRE] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support for Generic Routing Encapsulation (GRE)", Work in Progress, draft-ietf-intarea-gre-ipv6-10, June 2015.
[IPv6-GRE] Pignataro、C.、Bonica、R。、およびS. Krishnan、「IPv6 Support for Generic Routing Encapsulation（GRE）」、作業中、draft-ietf-intarea-gre-ipv6-10、2015年6月。
[RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the-Network Tunneling", RFC 4459, DOI 10.17487/RFC4459, April 2006, <http://www.rfc-editor.org/info/rfc4459>.
[RFC4459] Savola、P。、「ネットワーク内トンネリングでのMTUおよびフラグメンテーションの問題」、RFC 4459、DOI 10.17487 / RFC4459、2006年4月、<http://www.rfc-editor.org/info/rfc4459> 。
Acknowledgements
謝辞
The authors would like to thank Fred Baker, Fred Detienne, Jagadish Grandhi, Jeff Haas, Brian Haberman, Vanitha Neelamegam, Masataka Ohta, John Scudder, Mike Sullenberger, Tom Taylor, and Wen Zhang for their constructive comments. The authors also express their gratitude to Vanessa Ameen, without whom this memo could not have been written.
著者は、建設的なコメントを提供してくれたフレッドベイカー、フレッドデティエンヌ、ジャガディッシュグランディ、ジェフハース、ブライアンハーバーマン、ヴァニサニーラメガム、大田正孝、ジョンスカッダー、マイクサレンバーガー、トムテイラー、ウェンチャンに感謝します。著者はまた、このメモが書かれなかったはずのヴァネッサ・アミーンに感謝の意を表します。
Authors' Addresses
著者のアドレス
Ron Bonica Juniper Networks 2251 Corporate Park Drive Herndon, Virginia 20170 United States
Ron Bonica Juniper Networks 2251 Corporate Park Drive Herndon、Virginia 20170アメリカ
Email: rbonica@juniper.net
Carlos Pignataro Cisco Systems 7200-12 Kit Creek Road Research Triangle Park, North Carolina 27709 United States
カルロスピグナタロCisco Systems 7200-12 Kit Creek Road Research Triangle Park、North Carolina 27709 United States
Email: cpignata@cisco.com
Joe Touch USC/ISI 4676 Admiralty Way Marina del Rey, California 90292-6695 United States
Joe Touch USC / ISI 4676 Admiralty Wayマリナデルレイ、カリフォルニア90292-6695アメリカ合衆国
Phone: +1 (310) 448-9151
Email: touch@isi.edu
URI: http://www.isi.edu/touch