[要約] 要約：RFC 4459は、ネットワーク内トンネリングにおけるMTUとフラグメンテーションの問題について説明しています。 目的：このRFCの目的は、ネットワーク内トンネリングにおけるMTUとフラグメンテーションの問題を理解し、解決策を提供することです。
Network Working Group P. Savola
Request for Comments: 4459 CSC/FUNET
Category: Informational April 2006
MTU and Fragmentation Issues with In-the-Network Tunneling
ネットワーク内トンネリングに関するMTUおよび断片化の問題
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
Tunneling techniques such as IP-in-IP when deployed in the middle of the network, typically between routers, have certain issues regarding how large packets can be handled: whether such packets would be fragmented and reassembled (and how), whether Path MTU Discovery would be used, or how this scenario could be operationally avoided. This memo justifies why this is a common, non-trivial problem, and goes on to describe the different solutions and their characteristics at some length.
ネットワークの中央に展開された場合のIP-in-IPなどのトンネリング技術は、通常はルーター間で、パケットの処理方法に関する特定の問題を抱えています。そのようなパケットが断片化され、再組み立てされているか（およびどのように再組み立てされるか（およびどのように）、PATH MTU発見かどうか使用されます、またはこのシナリオを運用上回避する方法。このメモは、なぜこれが一般的で非自明な問題であるのかを正当化し、何らかの長さでさまざまな解決策とその特性を説明し続けています。
Table of Contents
目次
1. Introduction ....................................................2
2. Problem Statement ...............................................3
3. Description of Solutions ........................................4
3.1. Fragmentation and Reassembly by the Tunnel Endpoints .......4
3.2. Signalling the Lower MTU to the Sources ....................5
3.3. Encapsulate Only When There is Free MTU ....................6
3.4. Fragmentation of the Inner Packet ..........................8
4. Conclusions .....................................................9
5. Security Considerations ........................................10
6. Acknowledgements ...............................................11
7. References .....................................................11
7.1. Normative References ......................................11
7.2. Informative References ....................................12
A large number of ways to encapsulate datagrams in other packets, i.e., tunneling mechanisms, have been specified over the years: for example, IP-in-IP (e.g., [1] [2], [3]), Generic Routing Encapsulation (GRE) [4], Layer 2 Tunneling Protocol (L2TP) [5], or IP Security (IPsec) [6] in tunnel mode -- any of which might run on top of IPv4, IPv6, or some other protocol and carrying the same or a different protocol.
他のパケットのデータグラムをカプセル化する多くの方法、つまりトンネリングメカニズムが長年にわたって指定されてきました：たとえば、IP-in-IP（例：[1] [2]、[3]）、一般的なルーティングカプセル化（GRE）[4]、レイヤー2トンネリングプロトコル（L2TP）[5]、またはIPセキュリティ（IPSEC）[6]トンネルモードで - IPv4、IPv6、またはその他のプロトコルおよび運搬の上で実行される可能性があります。同じまたは異なるプロトコル。
All of these can be run so that the endpoints of the inner protocol are co-located with the endpoints of the outer protocol; in a typical scenario, this would correspond to "host-to-host" tunneling. It is also possible to have one set of endpoints co-located, i.e., host-to-router or router-to-host tunneling. Finally, many of these mechanisms are also employed between the routers for all or a part of the traffic that passes between them, resulting in router-to-router tunneling.
これらすべてを実行して、内部プロトコルのエンドポイントが外部プロトコルのエンドポイントと共同で開催されるようにします。典型的なシナリオでは、これは「ホストからホストまでの」トンネルに対応します。また、1つのエンドポイントのセット、つまりホストツールーターまたはルーターからホストのトンネリングを使用することもできます。最後に、これらのメカニズムの多くは、それらの間を通過するトラフィックのすべてまたは一部のルーター間でも使用され、ルーターからルーターへのトンネリングが行われます。
All these protocols and scenarios have one issue in common: how does the source select the maximum packet size so that the packets will fit, even encapsulated, in the smallest Maximum Transmission Unit (MTU) of the traversed path in the network; and if you cannot affect the packet sizes, what do you do to be able to encapsulate them in any case? The four main solutions are as follows (these will be elaborated in Section 3):
これらのすべてのプロトコルとシナリオには共通の問題が1つあります。ソースは、ネットワーク内のトラバースパスの最小最大伝送ユニット（MTU）にパケットが適合し、カプセル化されるように、最大パケットサイズをどのように選択しますか。また、パケットサイズに影響を与えることができない場合、いずれにせよ、それらをカプセル化できるために何をしますか？4つの主要なソリューションは次のとおりです（これらはセクション3で詳しく説明されます）。
1. Fragmenting all too big encapsulated packets to fit in the paths, and reassembling them at the tunnel endpoints.
1. あまりにも大きなカプセル化されたパケットを断片化して、パスに収まり、トンネルエンドポイントでそれらを再組み立てします。
2. Signal to all the sources whose traffic must be encapsulated, and is larger than fits, to send smaller packets, e.g., using Path MTU Discovery (PMTUD)[7][8].
2. トラフィックをカプセル化する必要があり、適合よりも大きいすべてのソースに信号を送信して、Path MTU Discovery（PMTUD）[7] [8]を使用して、より小さなパケットを送信します。
3. Ensure that in the specific environment, the encapsulated packets will fit in all the paths in the network, e.g., by using MTU bigger than 1500 in the backbone used for encapsulation.
3. 特定の環境では、カプセル化されたパケットがネットワーク内のすべてのパスに適合することを確認してください。たとえば、カプセル化に使用されるバックボーンで1500を超えるMTUを使用することにより。
4. Fragmenting the original too big packets so that their fragments will fit, even encapsulated, in the paths, and reassembling them at the destination nodes. Note that this approach is only available for IPv4 under certain assumptions (see Section 3.4).
4. 元の大きすぎるパケットを断片化して、フラグメントがパスに適合し、カプセル化され、宛先ノードで再組み立てされるようにします。このアプローチは、特定の仮定の下でIPv4でのみ利用可能であることに注意してください（セクション3.4を参照）。
It is also common to run multiple layers of encapsulation, for example, GRE or L2TP over IPsec; with nested tunnels in the network, the tunnel endpoints can be the same or different, and both the inner and outer tunnels may have different MTU handling strategies. In particular, signalling may be a scalable option for the outer tunnel or tunnels if the number of innermost tunnel endpoints is limited.
また、IPSECを介してGREまたはL2TPなど、複数のカプセル化の層を実行することも一般的です。ネットワーク内にネストされたトンネルを使用すると、トンネルのエンドポイントは同じまたは異なる場合があり、内側と外側のトンネルの両方にMTU処理戦略が異なる場合があります。特に、最も内側のトンネルエンドポイントの数が限られている場合、シグナリングは外側トンネルまたはトンネルのスケーラブルなオプションになる場合があります。
The tunneling packet size issues are relatively straightforward in host-to-host tunneling or host-to-router tunneling where Path MTU Discovery only needs to signal to one source node. The issues are significantly more difficult in router-to-router and certain router-to-host scenarios, which are the focus of this memo.
トンネルパケットサイズの問題は、ホストからホストのトンネルまたはホストからルーターへのトンネルで比較的簡単です。パスMTUディスカバリーは、1つのソースノードにのみ信号を送信する必要があります。このメモの焦点であるルーターからルーターへのルーターから特定のルーター間シナリオでは、この問題は非常に困難です。
It is worth noting that most of this discussion applies to a more generic case, where there exists a link with a lower MTU in the path. A concrete and widely deployed example of this is the usage of PPP over Ethernet (PPPoE) [11] at the customers' access link. These lower-MTU links, and particularly PPPoE links, are typically not deployed in topologies where fragmentation and reassembly might be unfeasible (e.g., a backbone), so this may be a slightly easier problem. However, this more generic case is considered out of scope of this memo.
この議論のほとんどは、より一般的なケースに適用されることは注目に値します。これの具体的で広く展開された例は、顧客のアクセスリンクでのイーサネット（PPPOE）[11]上のPPPの使用です。これらの低MTUリンク、特にPPPOEリンクは、通常、断片化と再組み立てが実行不可能である可能性があるトポロジに展開されていないため（例：バックボーン）、これは少し簡単な問題になる可能性があります。ただし、このより一般的なケースは、このメモの範囲外であると見なされます。
There are also known challenges in specifying and implementing a mechanism that would be used at the tunnel endpoint to obtain the best suitable packet size to use for encapsulation: if a static value is chosen, a lot of fragmentation might end up being performed. On the other hand, if PMTUD is used, the implementation would need to update the discovered interface MTU based on the ICMP Packet Too Big messages and originate ICMP Packet Too Big message(s) back to the source(s) of the encapsulated packets; this also assumes that sufficient data has been piggybacked on the ICMP messages (beyond the required 64 bits after the IPv4 header). We'll discuss using PMTUD to signal the sources briefly in Section 3.2, but in-depth specification and analysis are described elsewhere (e.g., in [4] and [2]) and are out of scope of this memo.
トンネルエンドポイントで使用されるメカニズムの指定と実装には、カプセル化に使用する最適なパケットサイズを取得する際にも既知の課題があります。静的値が選択されている場合、多くの断片化が実行される可能性があります。一方、PMTUDを使用する場合、実装はICMPパケットに基づいて発見されたインターフェイスMTUを更新し、ICMPパケットを発信し、カプセル化されたパケットのソースに戻ってICMPパケットを元に戻す必要があります。これはまた、ICMPメッセージで十分なデータがピギーバックされていることを前提としています（IPv4ヘッダー後の必要な64ビットを超えて）。PMTUDを使用してセクション3.2でソースを簡単に信号することについて説明しますが、詳細な仕様と分析については、他の場所（[4]および[2]で）で説明され、このメモの範囲外です。
Section 2 includes a problem statement, section 3 describes the different solutions with their drawbacks and advantages, and section 4 presents conclusions.
セクション2には問題の声明が含まれており、セクション3では、さまざまなソリューションが欠点と利点を備えた説明を説明し、セクション4は結論を示しています。
It is worth considering why exactly this is considered a problem.
これが正確に問題と見なされる理由を考慮する価値があります。
It is possible to fix all the packet size issues using solution 1, fragmenting the resulting encapsulated packet, and reassembling it by the tunnel endpoint. However, this is considered problematic for at least three reasons, as described in Section 3.1.
ソリューション1を使用してすべてのパケットサイズの問題を修正し、結果のカプセル化されたパケットを断片化し、トンネルエンドポイントで再組み立てすることができます。ただし、セクション3.1で説明されているように、これは少なくとも3つの理由で問題があると考えられています。
Therefore, it is desirable to avoid fragmentation and reassembly if possible. On the other hand, the other solutions may not be practical either: especially in router-to-router or router-to-host tunneling, Path MTU Discovery might be very disadvantageous -- consider the case where a backbone router would send ICMP Packet Too Big messages to every source that would try to send packets through it. Fragmenting before encapsulation is also not available in IPv6, and not available when the Don't Fragment (DF) bit has been set (see Section 3.4 for more). Ensuring a high enough MTU so encapsulation is always possible is of course a valid approach, but requires careful operational planning, and may not be a feasible assumption for implementors.
したがって、可能であれば断片化と再組み立てを避けることが望ましいです。一方、他のソリューションも実用的ではないかもしれません：特にルーターからルーターまたはルーターからホストへのトンネリングでは、PATH MTUの発見は非常に不利な場合があります - バックボーンルーターがICMPパケットを送信する場合を考慮してくださいすべてのソースへの大きなメッセージは、それを介してパケットを送信しようとします。カプセル化の前に断片化することもIPv6では使用できず、DONTフラグメント（DF）ビットが設定されている場合は使用できません（詳細についてはセクション3.4を参照）。カプセル化が常に可能になるほど十分なMTUを確保することは常に有効なアプローチですが、慎重な運用計画が必要であり、実装者にとって実行可能な仮定ではない場合があります。
This yields that there is no trivial solution to this problem, and it needs to be further explored to consider the trade offs, as is done in this memo.
This section describes the potential solutions in a bit more detail.
このセクションでは、潜在的なソリューションについてもう少し詳しく説明します。
The seemingly simplest solution to tunneling packet size issues is fragmentation of the outer packet by the encapsulator and reassembly by the decapsulator. However, this is highly problematic for at least three reasons:
パケットサイズの問題のトンネリングの最も単純なソリューションは、エンコプセーターによる外側パケットの断片化と、脱カプセレータによる再組み立てです。ただし、これは少なくとも3つの理由で非常に問題があります。
o Fragmentation causes overhead: every fragment requires the IP header (20 or 40 bytes), and with IPv6, an additional 8 bytes for the Fragment Header.
o 断片化は頭上を引き起こします：すべてのフラグメントにはIPヘッダー（20または40バイト）が必要であり、IPv6ではフラグメントヘッダーの追加8バイトです。
o Fragmentation and reassembly require computation: splitting datagrams to fragments is a non-trivial procedure, and so is their reassembly. For example, software router forwarding implementations may not be able to perform these operations at line rate.
o 断片化と再組み立てには計算が必要です。データグラムをフラグメントに分割することは、非自明の手順であり、それらの再組み立ても同様です。たとえば、ソフトウェアルーターの転送実装は、これらの操作をラインレートで実行できない場合があります。
o At the time of reassembly, all the information (i.e., all the fragments) is normally not available; when the first fragment arrives to be reassembled, a buffer of the maximum possible size may have to be allocated because the total length of the reassembled datagram is not known at that time. Furthermore, as fragments might get lost, or be reordered or delayed, the reassembly engine has to wait with the partial packet for some time (e.g., 60 seconds [9]). When this would have to be done at the line rate, with, for example 10 Gbit/s speed, the length of the buffers that reassembly might require would be prohibitive.
o 再組み立ての時点で、すべての情報（つまり、すべてのフラグメント）は通常使用できません。最初のフラグメントが再組み立てされるために到着すると、再構築されたデータグラムの全長が当時知られていないため、可能な最大サイズのバッファーを割り当てる必要があります。さらに、フラグメントが紛失したり、並べ替えたり遅れたりすると、再組み立てエンジンはしばらくの間、部分的なパケットで待つ必要があります（たとえば、60秒[9]）。これをラインレートで行う必要がある場合、たとえば10 gbit/s速度で行う必要がある場合、再組み立てが必要とするバッファーの長さは法外になります。
When examining router-to-router tunneling, the third problem is likely the worst; certainly, a hardware computation and implementation requirement would also be significant, but not all that difficult in the end -- and the link capacity wasted in the backbones by additional overhead might not be a huge problem either.
ルーターからルーターへのトンネリングを調べるとき、3番目の問題はおそらく最悪です。確かに、ハードウェアの計算と実装の要件も重要ですが、最終的にはそれほど難しいわけではありません。また、追加のオーバーヘッドによってバックボーンで無駄になったリンク容量も大きな問題ではないかもしれません。
However, IPv4 identification header length is only 16 bits (compared to 32 bits in IPv6), and if a larger number of packets are being tunneled between two IP addresses, the ID is very likely to wrap and cause data misassociation. This reassembly wrongly combining data from two unrelated packets causes data integrity and potentially a confidentiality violation. This problem is further described in [12].
ただし、IPv4識別ヘッダーの長さはわずか16ビットです（IPv6の32ビットと比較）。2つのIPアドレスの間でより多くのパケットがトンネリングされている場合、IDはデータの誤sociationをラップして引き起こす可能性が非常に高くなります。この再組み立ては、2つの無関係なパケットからのデータを誤って組み合わせることで、データの整合性と潜在的に機密性違反を引き起こします。この問題は[12]でさらに説明されています。
IPv6, and IPv4 with the DF bit set in the encapsulating header, allows the tunnel endpoints to optimize the tunnel MTU and minimize network-based reassembly. This also prevents fragmentation of the encapsulated packets on the tunnel path. If the IPv4 encapsulating header does not have the DF bit set, the tunnel endpoints will have to perform a significant amount of fragmentation and reassembly, while the use of PMTUD is minimized.
カプセル化ヘッダーにDFビットが設定されたIPv6およびIPv4は、トンネルのエンドポイントがトンネルMTUを最適化し、ネットワークベースの再組み立てを最小限に抑えることができます。これにより、トンネルパス上のカプセル化されたパケットの断片化も防止されます。IPv4のカプセル化ヘッダーにDFビットが設定されていない場合、トンネルエンドポイントはかなりの量の断片化と再組み立てを実行する必要がありますが、PMTUDの使用が最小化されます。
As Appendix A describes, the MTU of the tunnel is also a factor on which packets require fragmentation and reassembly; the worst case occurs if the tunnel MTU is "infinite" or equal to the physical interface MTUs.
付録Aが説明しているように、トンネルのMTUは、パケットが断片化と再組み立てを必要とする要因でもあります。最悪のケースは、トンネルMTUが「無限」または物理インターフェイスMTUと等しい場合に発生します。
So, if reassembly could be made to work sufficiently reliably, this would be one acceptable fallback solution but only for IPv6.
したがって、再組み立てを十分に確実に機能させることができれば、これは1つの許容可能なフォールバックソリューションになりますが、IPv6のみです。
Another approach is to use techniques like Path MTU Discovery (or potentially a future derivative [13]) to signal to the sources whose packets will be encapsulated in the network to send smaller packets so that they can be encapsulated; in particular, when done on routers, this includes two separable functions:
別のアプローチは、Path MTUディスカバリー（または潜在的に将来のデリバティブ[13]）などの手法を使用して、ネットワークにカプセル化されて小さなパケットを送信してカプセル化できるソースに信号を送ることです。特に、ルーターで行われた場合、これには2つの分離可能な機能が含まれます。
a. Forwarding behaviour: when forwarding packets, if the IPv4-only DF bit is set, the router sends an ICMP Packet Too Big message to the source if the MTU of the egress link is too small.
a. 転送の動作：パケットを転送するとき、IPv4のみのDFビットが設定されている場合、ルーターは、EgressリンクのMTUが小さすぎる場合、ICMPパケットをソースに送信します。
b. Router's "host" behaviour: when the router receives an ICMP Packet Too Big message related to a tunnel, it (1) adjusts the tunnel MTU, and (2) originates an ICMP Packet Too Big message to the source address of the encapsulated packet. (2) can be done either immediately or by waiting for the next packet to trigger an ICMP; the former minimizes the packet loss due to MTU changes.
b. ルーターの「ホスト」動作：ルーターがトンネルに関連するICMPパケットを受け取ると、（1）トンネルMTUを調整し、（2）カプセル化されたパケットのソースアドレスにICMPパケットが大きすぎるメッセージを調整します。（2）すぐに、または次のパケットがICMPをトリガーするのを待つことで実行できます。前者は、MTUの変更によるパケット損失を最小限に抑えます。
Note that this only works if the MTU of the tunnel is of reasonable size, and not, for example, 64 kilobytes: see Appendix A for more.
This approach would presuppose that PMTUD works. While it is currently working for IPv6, and critical for its operation, there is ample evidence that in IPv4, PMTUD is far from reliable due to, for example firewalls and other boxes being configured to inappropriately drop all the ICMP packets [14], or software bugs rendering PMTUD inoperational.
Furthermore, there are two scenarios where signalling from the network would be highly undesirable. The first is when the encapsulation would be done in such a prominent place in the network that a very large number of sources would need to be signalled with this information (possibly even multiple times, depending on how long they keep their PMTUD state). The second is when the encapsulation is done for passive monitoring purposes (network management, lawful interception, etc.) -- when it's critical that the sources whose traffic is being encapsulated are not aware of this happening.
When desiring to avoid fragmentation, IPv4 requires one of two alternatives [1]: copy the DF bit from the inner packets to the encapsulating header, or always set the DF bit of the outer header. The latter is better, especially in controlled environments, because it forces PMTUD to converge immediately.
断片化を避けたい場合、IPv4には2つの選択肢のいずれかが必要です[1]：内側のパケットからカプセリングヘッダーにDFビットをコピーするか、常に外側ヘッダーのDFビットを設定します。後者は、特に制御された環境では、PMTUDがすぐに収束するため、より優れています。
A related technique, which works with TCP under specific scenarios only, is so-called "MSS clamping". With that technique or rather a "hack", the TCP packets' Maximum Segment Size (MSS) is reduced by tunnel endpoints so that the TCP connection automatically restricts itself to the maximum available packet size. Obviously, this does not work for UDP or other protocols that have no MSS. This approach is most applicable and used with PPPoE, but could be applied otherwise as well; the approach also assumes that all the traffic goes through tunnel endpoints that do MSS clamping -- this is trivial for the single-homed access links, but could be a challenge otherwise.
特定のシナリオのみでTCPで動作する関連手法は、いわゆる「MSSクランプ」です。そのテクニックまたはむしろ「ハック」により、TCPパケットの最大セグメントサイズ（MSS）はトンネルエンドポイントによって縮小されるため、TCP接続は自動的に利用可能なパケットサイズに自動的に制限されます。明らかに、これはUDPやMSSのない他のプロトコルでは機能しません。このアプローチは最も適用可能であり、PPPOEで使用されますが、そうでない場合も適用できます。また、このアプローチでは、すべてのトラフィックがMSSクランプを行うトンネルエンドポイントを通過することを前提としています。これは、シングルホームのアクセスリンクにとって些細なことですが、それ以外の場合は課題になる可能性があります。
A new approach to PMTUD is in the works [13], but it is uncertain whether that would fix the problems -- at least not the passive monitoring requirements.
PMTUDへの新しいアプローチは作業中です[13]が、それが問題を解決するかどうかは不明です - 少なくともパッシブ監視要件ではありません。
The third approach is an operational one, depending on the environment where encapsulation and decapsulation are being performed. That is, if an ISP would deploy tunneling in its backbone, which would consist only of links supporting high MTUs (e.g., Gigabit Ethernet or SDH/SONET), but all its customers and peers would have a lower MTU (e.g., 1500, or the backbone MTU minus the encapsulation overhead), this would imply that no packets (with the encapsulation overhead added) would have a larger MTU than the "backbone MTU", and all the encapsulated packets would always fit MTU-wise in the backbone links.
3番目のアプローチは、カプセル化と脱カプセル化が実行されている環境に応じて、運用上のアプローチです。つまり、ISPがバックボーンにトンネリングを展開する場合、これは高MTU（Gigabit EthernetまたはSDH/Sonetなど）をサポートするリンクのみで構成されますが、その顧客とピアはすべてMTU（1500、または1500、または1500、または1500、またはバックボーンMTUからカプセル化オーバーヘッドを差し引いたもの）、これは、パケット（カプセル化オーバーヘッドが追加された）が「バックボーンMTU」よりも大きなMTUを持たないことを意味し、カプセル化されたすべてのパケットは常にバックボーンリンクにMTUワイズに適合します。
This approach is highly assumptive of the deployment scenario. It may be desirable to build a tunnel to/from another ISP, for example, where this might no longer hold; or there might be links in the network that cannot support the higher MTUs to satisfy the tunneling requirements; or the tunnel might be set up directly between the customer and the ISP, in which case fragmentation would occur, with tunneled fragments terminating on the ISP and thus requiring reassembly capability from the ISP's equipment.
このアプローチは、展開シナリオを非常に仮定しています。たとえば、これがもはや保持されない場合がある場合、別のISPとの間でトンネルを建設することが望ましい場合があります。または、トンネルの要件を満たすためにより高いMTUをサポートできないリンクがネットワークにあるかもしれません。または、トンネルは顧客とISPの間に直接セットアップされる場合があります。この場合、ISPでトンネルフラグメントが終了するため、ISPの機器からの再組み立て機能が必要です。
To restate, this approach can only be considered when tunneling is done inside a part of specific kind of ISP's own network, not, for example, transiting an ISP.
修正するために、このアプローチは、特定の種類のISP独自のネットワークの一部内でトンネリングが行われる場合にのみ考慮します。たとえば、ISPを通過することはできません。
Another, related approach might be having the sources use only a low enough MTU that would fit in all the physical MTUs; for example, IPv6 specifies the minimum MTU of 1280 bytes. For example, if all the sources whose traffic would be encapsulated would use this as the maximum packet size, there would probably always be enough free MTU for encapsulation in the network. However, this is not the case today, and it would be completely unrealistic to assume that this kind of approach could be made to work in general.
別の関連するアプローチは、ソースにすべての物理MTUに適合する十分な低MTUのみを使用することです。たとえば、IPv6は1280バイトの最小MTUを指定します。たとえば、トラフィックがカプセル化されるすべてのソースがこれを最大パケットサイズとして使用する場合、おそらくネットワーク内のカプセル化には常に十分な無料のMTUがあります。しかし、これは今日ではありません。この種のアプローチが一般的に機能するために行われる可能性があると仮定することは完全に非現実的です。
It is worth remembering that while the IPv6 minimum MTU is 1280 bytes [10], there are scenarios where the tunnel implementation must implement fragmentation and reassembly [3]: for example, when having an IPv6-in-IPv6 tunnel on top of a physical interface with an MTU of 1280 bytes, or when having two layers of IPv6 tunneling. This can only be avoided by ensuring that links on top of which IPv6 is being tunneled have a somewhat larger MTU (e.g., 40 bytes) than 1280 bytes. This conclusion can be generalized: because IP can be tunneled on top of IP, no single minimum or maximum MTU can be found such that fragmentation or signalling to the sources would never be needed.
IPv6の最小MTUは1280バイト[10]であるが、トンネルの実装が断片化と再組み立てを実装する必要があるシナリオがあることを覚えておく価値があります[3]：たとえば、物理の上にIPv6-in-IPV6トンネルを持っている場合1280バイトのMTUとのインターフェース、または2層のIPv6トンネルがある場合。これは、1280バイトよりも多少大きなMTU（40バイト）が多少大きいMTUを持つことを保証することによってのみ回避できます。この結論は一般化できます。IPをIPの上にトンネル化できるため、ソースへの断片化またはシグナル伝達が決して必要ないように、単一の最小または最大MTUを見つけることができません。
All in all, while in certain operational environments it might be possible to avoid any problems by deployment choices, or limiting the MTU that the sources use, this is probably not a sufficiently good general solution for the equipment vendors. Other solutions must also be provided.
全体として、特定の運用環境では、展開の選択肢またはソースが使用するMTUを制限することにより、問題を回避することが可能かもしれませんが、これはおそらく機器ベンダーにとって十分に良い一般的なソリューションではありません。他のソリューションも提供する必要があります。
A final possibility is fragmenting the inner packet, before encapsulation, in such a manner that the encapsulated packet fits in the tunnel's path MTU (discovered using PMTUD). However, one should note that only IPv4 supports this "in-flight" fragmentation; furthermore, it isn't allowed for packets where the Don't Fragment bit has been set. Even if one could ignore IPv6 completely, so many IPv4 host stacks send packets with the DF bit set that this would seem unfeasible.
However, there are existing implementations that violate the standard that:
o discard too big packets with the DF bit not set instead of fragmenting them (this is rare);
o DFビットを断片化する代わりに設定しない大きなパケットを廃棄します（これはまれです）。
o ignore the DF bit completely, for all or specified interfaces; or
o すべてまたは指定されたインターフェイスについて、DFビットを完全に無視します。また
o clear the DF bit before encapsulation, in the egress of configured interfaces. This is typically done for all the traffic, not just too big packets (allowing configuring this is common).
o 設定されたインターフェイスの出口で、カプセル化の前にDFビットをクリアします。これは通常、大きなパケットだけでなく、すべてのトラフィックに対して行われます（これを構成することは一般的です）。
This is non-compliant behaviour, but there are certainly uses for it, especially in certain tightly controlled passive monitoring scenarios, and it has potential for more generic applicability as well, to work around PMTUD issues.
これは非準拠の動作ですが、特に特定の厳密に制御されたパッシブモニタリングシナリオには確かに使用があり、PMTUDの問題を回避するための一般的な適用性の可能性もあります。
Clearing the DF bit effectively disables the sender's PMTUD for the path beyond the tunnel. This may result in fragmentation later in the network, but as the packets have already been fragmented prior to encapsulation, this fragmentation later on does not make matters significantly worse.
DFビットをクリアすると、トンネルを越えたパスに対して送信者のPMTUDが効果的に無効になります。これにより、ネットワークの後半で断片化が発生する可能性がありますが、カプセル化の前にパケットがすでに断片化されているため、この断片化は問題を大幅に悪化させません。
As this is an implemented and desired (by some) behaviour, the full impacts e.g., for the functioning of PMTUD (for example) should be analyzed, and the use of fragmentation-related IPv4 bits should be re-evaluated.
これは実装および望ましい（一部の）動作であるため、たとえばPMTUD（たとえば）の機能のための完全な影響を分析する必要があり、断片化関連のIPv4ビットの使用を再評価する必要があります。
In summary, this approach provides a relatively easy fix for IPv4 problems, with potential for causing problems for PMTUD; as this would not work with IPv6, it could not be considered a generic solution.
要約すると、このアプローチは、PMTUDの問題を引き起こす可能性があるIPv4の問題に対する比較的簡単な修正を提供します。これはIPv6で動作しないため、一般的なソリューションとは見なされませんでした。
Fragmentation and reassembly by the tunnel endpoints are a clear and simple solution to the problem, but the hardware reassembly when the packets get lost may face significant implementation challenges that may be insurmountable. This approach does not seem feasible, especially for IPv4 with high data rates due to problems with wrapping the fragment identification field [12]. Constant wrapping may occur when the data rate is in the order of MB/s for IPv4 and in the order of dozens of GB/s for IPv6. However, this reassembly approach is probably not a problem for passive monitoring applications.
トンネルエンドポイントによる断片化と再組み立ては、問題に対する明確で簡単な解決策ですが、ハードウェアの再組み立てが失われると、克服できない重要な実装の課題に直面する可能性があります。このアプローチは、特にフラグメント識別フィールドのラッピングに問題があるため、高いデータレートを持つIPv4では実行不可能とは思えません[12]。データレートがIPv4のMb/sの順に、IPv6の場合は数十Gb/sの順にある場合、一定のラッピングが発生する場合があります。ただし、この再組み立てアプローチは、パッシブモニタリングアプリケーションの問題ではない可能性があります。
PMTUD techniques, at least at the moment and especially for IPv4, appear to be too unreliable or unscalable to be used in the backbones. It is an open question whether a future solution might work better in this aspect.
少なくとも現時点では、特にIPv4のPMTUDテクニックは、バックボーンで使用するには信頼性が低すぎるか、非衝撃がないようです。将来の解決策がこの面でより良く機能する可能性があるかどうかは、未解決の問題です。
It is clear that in some environments the operational approach to the problem, ensuring that fragmentation is never necessary by keeping higher MTUs in the networks where encapsulated packets traverse, is sufficient. But this is unlikely to be enough in general, and for vendors that may not be able to make assumptions about the operators' deployments.
一部の環境では、問題への運用アプローチがあり、カプセル化されたパケットをトラバースするネットワークでより高いMTUを維持することで、断片化が十分ではないことを保証することは明らかです。しかし、これは一般的に十分であり、オペレーターの展開について仮定を立てることができないベンダーにとってはありそうもない。
Fragmentation of the inner packet is only possible with IPv4, and is sufficient only if standards-incompliant behaviour, with potential for bad side-effects (e.g., for PMTUD), is adopted. It should not be used if there are alternatives; fragmentation of the outer packet seems a better option for passive monitoring.
内側のパケットの断片化はIPv4でのみ可能であり、悪い副作用（PMTUDなど）の可能性がある標準不変の動作が採用されている場合にのみ十分です。代替手段がある場合は使用しないでください。外側のパケットの断片化は、パッシブモニタリングに適したオプションのようです。
However, if reassembly in the network must be avoided, there are basically two possibilities:
ただし、ネットワーク内の再組み立てを回避する必要がある場合、基本的に2つの可能性があります。
1. For IPv6, use ICMP signalling or operational methods.
1. IPv6の場合、ICMPシグナル伝達または運用方法を使用します。
2. For IPv4, packets for which the DF bit is not set can be fragmented before encapsulation (and the encapsulating header would have the DF bit set); packets whose DF bit is set would need to get the DF bit cleared (though this is non-compliant). This also minimizes the need for (unreliable) Internet-wide PMTUD.
2.
An interesting thing to explicitly note is that when tunneling is done in a high-speed backbone, typically one may be able to make assumptions on the environment; however, when reassembly is not performed in such a network, it might be done in software or with lower requirements, and there exists either a reassembly implementation using PMTUD or using a separate approach for passive monitoring -- so this might not be a real problem.
明示的に注意すべき興味深いことは、高速バックボーンでトンネリングが行われると、通常、環境について仮定を立てることができるかもしれないということです。ただし、そのようなネットワークで再組み立てが実行されない場合、ソフトウェアまたは低い要件で実行される可能性があり、PMTUDを使用するか、パッシブモニタリングのために別のアプローチを使用して再組み立て実装が存在する可能性があります。。
In consequence, the critical questions at this point appear to be 1) whether a higher MTU can be assumed in the high-speed networks that deploy tunneling, and 2) whether "slower-speed" networks could cope with a software-based reassembly, a less capable hardware-based reassembly, or the other workarounds. An important future task would be analyzing the observed incompliant behaviour about the DF bit to note whether it has any unanticipated drawbacks.
その結果、この時点での重要な質問は、1）トンネリングを展開する高速ネットワークでより高いMTUを想定できるかどうか、および2）「遅い速度」ネットワークがソフトウェアベースの再組み立てに対処できるかどうか、あまり能力の低いハードウェアベースの再組み立て、または他の回避策。重要な将来のタスクは、DFビットに関する観測された不浸透の動作を分析して、予期しない欠点があるかどうかを把握することです。
This document describes different issues with packet sizes and in-the-network tunneling; this does not have security considerations on its own.
However, different solutions might have characteristics that may make them more susceptible to attacks -- for example, a router-based fragment reassembly could easily lead to (reassembly) buffer memory exhaustion if the attacker sends a sufficient number of fragments without sending all of them, so that the reassembly would be stalled until a timeout; these and other fragment attacks (e.g., [15]) have already been used against, for example, firewalls and host stacks, and need to be taken into consideration in the implementations.
It is worth considering the cryptographic expense (which is typically more significant than the reassembly, if done in software) with fragmentation of the inner or outer packet. If an outer fragment goes missing, no cryptographic operations have been yet performed; if an inner fragment goes missing, cryptographic operations have already been performed. Therefore, which of these approaches is preferable also depends on whether cryptography or reassembly is already provided in hardware; for high-speed routers, at least, one should be able to assume that if it is performing relatively heavy cryptography, hardware support is already required.
内側または外側のパケットの断片化により、暗号化費用（ソフトウェアで行われた場合、通常は再組み立てよりも重要です）を考慮する価値があります。外側のフラグメントが欠落している場合、暗号化操作はまだ実行されていません。内側の断片が欠落している場合、暗号化操作はすでに実行されています。したがって、これらのアプローチのどれが好ましいのかは、暗号化または再組み立てがハードウェアですでに提供されているかどうかにも依存します。高速ルーターの場合、少なくとも、比較的重い暗号化を実行している場合、ハードウェアサポートがすでに必要であると想定できるはずです。
The solutions using PMTUD (and consequently ICMP) will also need to take into account the attacks using ICMP. In particular, an attacker could send ICMP Packet Too Big messages indicating a very low MTU to reduce the throughput and/or as a fragmentation/reassembly denial-of-service attack. This attack has been described in the context of TCP in [16].
PMTUD（および結果としてICMP）を使用したソリューションも、ICMPを使用した攻撃を考慮する必要があります。特に、攻撃者はICMPパケットを送信して、非常に低いMTUを示す大きなメッセージを送信することができます。この攻撃は、[16]のTCPのコンテキストで説明されています。
While the topic is far from new, recent discussions with W. Mark Townsley on L2TP fragmentation issues caused the author to sit down and write up the issues in general. Michael Richardson and Mika Joutsenvirta provided useful feedback on the first version. When soliciting comments from the NANOG list, Carsten Bormann, Kevin Miller, Warren Kumari, Iljitsch van Beijnum, Alok Dube, and Stephen J. Wilcox provided useful feedback. Later, Carlos Pignataro provided excellent input, helping to improve the document. Joe Touch also provided input on the memo.
このトピックは、L2TPの断片化の問題に関するW.マークタウンズリーとの最近の議論とはほど遠いものですが、著者は座って一般的に問題を書き留めました。マイケル・リチャードソンとミカ・ジュッテンヴィルタは、最初のバージョンに関する有用なフィードバックを提供しました。Nanogリストからコメントを求めると、Carsten Bormann、Kevin Miller、Warren Kumari、Iljitsch Van Beijnum、Alok Dube、Stephen J. Wilcoxが有用なフィードバックを提供しました。その後、Carlos Pignataroは優れた入力を提供し、ドキュメントの改善に役立ちました。Joe Touchはメモに関する入力も提供しました。
[1] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[1] Perkins、C。、「IP内のIPカプセル化」、RFC 2003、1996年10月。
[2] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[2] Nordmark、E。およびR. Gilligan、「IPv6ホストとルーターの基本的な遷移メカニズム」、RFC 4213、2005年10月。
[3] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[3] Conta、A。and S. Deering、「IPv6仕様における一般的なパケットトンネル」、RFC 2473、1998年12月。
[4] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[4] Farinacci、D.、Li、T.、Hanks、S.、Meyer、D。、およびP. Traina、「一般的なルーティングカプセル化（GRE）」、RFC 2784、2000年3月。
[5] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[5] Lau、J.、Townsley、M。、およびI. Goyret、「レイヤー2トンネルプロトコル - バージョン3（L2TPV3）」、RFC 3931、2005年3月。
[6] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[6] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[7] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[7]
[8] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[8]
[9] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[9] Braden、R。、「インターネットホストの要件 - 通信レイヤー」、STD 3、RFC 1122、1989年10月。
[10] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[10] Deering、S。and R. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[11] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and R. Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, February 1999.
[11] Mamakos、L.、Lidl、K.、Evarts、J.、Carrel、D.、Simone、D。、およびR. Wheeler、「PPPを超える（PPPOE）を送信する方法」、RFC 2516、1999年2月。
[12] Mathis, M., "Fragmentation Considered Very Harmful", Work in Progress, July 2004.
[12] Mathis、M。、「断片化は非常に有害であると考えられている」、2004年7月の進行中の作業。
[13] Mathis, M. and J. Heffner, "Path MTU Discovery", Work in Progress, March 2006.
[13] Mathis、M。およびJ. Heffner、「Path MTU Discovery」、2006年3月、進行中の作業。
[14] Medina, A., Allman, M., and S. Floyd, "Measuring the Evolution of Transport Protocols in the Internet", Computer Communications Review, Apr 2005, <http://www.icir.org/tbit/>.
[14] Medina、A.、Allman、M。、およびS. Floyd、「インターネットでの輸送プロトコルの進化の測定」、Computer Communications Review、2005年4月、<http://www.icir.org/tbit/>。
[15] Miller, I., "Protection Against a Variant of the Tiny Fragment Attack (RFC 1858)", RFC 3128, June 2001.
[15] Miller、I。、「小さなフラグメント攻撃のバリアント（RFC 1858）に対する保護」、RFC 3128、2001年6月。
[16] Gont, F., "ICMP attacks against TCP", Work in Progress, February 2006.
[16] Gont、F。、「TCPに対するICMP攻撃」、2006年2月、進行中の作業。
Different tunneling mechanisms may treat the tunnel links as having different kinds of MTU values. Some might use the same default MTU as for other interfaces; some others might use the default MTU minus the expected IP overhead (e.g., 20, 28, or 40 bytes); some others might even treat the tunnel as having an "infinite MTU", e.g., 64 kilobytes.
異なるトンネルメカニズムは、トンネルリンクをさまざまな種類のMTU値を持つものとして扱う可能性があります。他のインターフェイスと同じデフォルトのMTUを使用する人もいます。他のいくつかは、デフォルトのMTUから予想されるIPオーバーヘッド（20、28、または40バイトなど）を差し引いてから使用する場合があります。他の人は、トンネルを「無限のMTU」、たとえば64キロバイトを持っていると扱うことさえあります。
As [2] describes, having an infinite MTU, i.e., always fragmenting the outer packet (and never the inner packet) and never performing PMTUD for the tunnel path, is a very bad idea, especially in host-to-router scenarios. (It could be argued that if the nodes are sure that this is a host-to-host tunnel, a larger MTU might make sense if fragmentation and reassembly are more efficient than just sending properly sized packets -- but this seems like a stretch.)
[2]が説明するように、無限のMTUを持つこと、つまり常に外側のパケットを断片化し（そして内側のパケットを決して断片化しない）、トンネルパスのPMTUDを実行することはありませんが、特にホストからルーターへのシナリオでは非常に悪い考えです。（これがホストツーホストトンネルであるとノードが確信している場合、フラグメンテーションと再組み立てが適切にサイズのパケットを送信するよりも効率的である場合、より大きなMTUが意味をなすかもしれないと主張することができますが、これはストレッチのようです。））
Author's Address
著者の連絡先
Pekka Savola CSC/FUNET Espoo Finland
Pekka Savola CSC/Funet Espoo Finland
EMail: psavola@funet.fi
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。