Network Working Group P. Savola
Request for Comments: 4459 CSC/FUNET
Category: Informational April 2006
MTU and Fragmentation Issues with In-the-Network Tunneling
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).
著作権（C）インターネット協会（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.
そのようなパケットは断片化及び再組立（および方法）されるかどうか、パスMTUディスカバリかどうか：例えばIPインIPネットワークの中央に配置されたとき、典型的には、ルータ間、取り扱うことができる方法を大きなパケットに関する特定の問題があるとして、トンネリング技術使用される、またはこのシナリオは、運用方法を回避することができます。このメモは、これは一般的な、些細な問題である理由を正当化し、いくつかの長さで異なるソリューションとその特性を記述するために行きます。
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イン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（最大伝送ユニット）であっても、カプセル化、収まるようにどのようにソースは、最大パケットサイズを選択しません。あなたはパケットサイズに影響を与えることができない場合や、何をどのような場合には、それらをカプセル化することができるように行うのですか？ （これらは、セクション3で詳述する）は、以下のように4つの主要な溶液です。
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.トラフィックカプセル化されなければならないすべてのソースへの信号、およびフィットよりも大きい場合、パスMTUディスカバリ（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ディスカバリーは唯一のソースノードに知らせる必要があるホストツールータートンネリングでは比較的簡単です。問題は、ルーターとこのメモの焦点である特定のルータからホストへのシナリオ、にはるかに困難です。
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.
この議論のほとんどは、パスの下側のMTUとのリンクが存在し、より一般的な場合に適用されることは注目に値します。これの具体的かつ広く配備例では、顧客のアクセスリンクでのイーサネット（PPPoEの）上のPPPの使用[11]です。これらの低い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パケットにカプセル化されたパケットのソースに過大メッセージ（S）（S）を発信する必要があります。これはまた、十分なデータが（IPv4ヘッダーの後に必要な64ビットを超えて）ICMPメッセージにピギーバックされていることを前提としています。我々は、簡単にセクション3.2にソースに信号を送るためにPMTUDを用いて説明しますが、で詳しく仕様および分析は他の場所に記載されている（例えば、[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.
したがって、可能な場合は、断片化と再構築を回避することが望ましいです。一方、他のソリューションは、どちらかの実用的ではないかもしれない。特にルータ - ルータまたはルータツーホストトンネリングでは、パスMTUディスカバリは非常に不利であるかもしれない - バックボーンルータはあまりにもICMPパケットを送信した場合を考えますそれを介してパケットを送信しようとするすべてのソースにBigメッセージ。 Do not Fragment（DF）ビットが（多くのためのセクション3.4を参照）に設定されている場合にカプセル化する前に、断片化は利用できないのIPv6でもご覧になれない、と。十分に高い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ギガビット/秒の速さのために、と、ラインレートで行わなければならない場合には、バッファの長さが必要な場合があります再構築は法外になること。
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.
ルータ間のトンネリングを調べるとき、第三の問題は、おそらく最悪です。確かに、ハードウェアの計算と実装要件も重要になるが、最終的にはすべてのことは困難ではない - と追加のオーバーヘッドにより、バックボーンに無駄なリンク容量は、いずれかの大きな問題ではないかもしれません。
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の識別ヘッダ長は、（IPv6では32ビットと比較して）は16ビットであり、パケットのより多くが、2つのIPアドレスとの間でトンネリングされている場合、IDは、ラップやデータmisassociationを引き起こす可能性が非常に高いです。誤って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.
再組み立ては十分に確実に動作するように作ることができるのであれば、これはしかし、IPv6のみのための1つの許容可能な代替ソリューションとなります。
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:
別のアプローチは、そのパケットそれらはカプセル化することができるように小さなパケットを送信するためにネットワーク内にカプセル化されるソースに知らせるためのパス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。行動を転送：出口リンクのMTUが小さすぎる場合はIPv4のみのDFビットが設定されている場合、パケットを転送するとき、ルータは元に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.
トンネルのMTUは、合理的なサイズである場合にのみ動作することに注意してください、とではない、例えば、64キロバイト：詳細については、付録Aを参照してください。
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.
このアプローチは、PMTUDが機能することを前提とするでしょう。それは現在、IPv6のために働いて、その動作のために重要であるが、IPv4では、PMTUDが不適切すべてのICMPパケットをドロップするように構成されている例示的なファイアウォールおよび他のボックスのために、原因に遠い信頼できるからであることを十分な証拠が存在する[14]、またはPMTUDが操作不能レンダリングソフトウェアのバグ。
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.
また、ネットワークからのシグナリングは非常に望ましくないであろう2つのシナリオがあります。カプセル化は、情報源の非常に大きな数がこの情報を通知する必要がネットワークで、そのような目立つ場所で行われることになるときに最初は（おそらくは複数回、に応じて、どのくらい彼らはPMTUD状態を保つ）です。それは重要だときにトラフィックがカプセル化されているこの出来事を認識していない情報源 - 第二は、カプセル化は、パッシブモニタリング目的（ネットワーク管理、合法的傍受など）のために行われたときです。
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つ必要とする[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接続が自動的に利用可能な最大パケットサイズに自分自身を制限するように「ハック」、TCPのパケットの最大セグメントサイズ（MSS）は、トンネルエンドポイントによって低減されます。明らかに、これは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.
第三のアプローチは、カプセル化及びデカプセル化が行われている環境に応じて、動作するものです。 ISPが高いだけのMTU（例えば、ギガビットイーサネットやSDH / SONET）をサポートするリンクで構成されますこれは、その骨格にトンネリングを配備するならばそれは、ですが、すべての顧客や同僚が持っているような低額のMTU（例えば、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インのIPv6トンネルを有する場合1280バイト、またはIPv6トンネルの二つの層を有するのMTUとのインターフェース。これは、IPv6のみがトンネリングされているの上のリンク1280バイトより幾分大きいMTU（例えば、40バイト）を有することを保証することによって回避することができます。この結論は、一般化することができます：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.
最終的な可能性は、カプセル化されたパケットがトンネルのパスMTU（PMTUDを用いて発見）に収まるように、カプセル化する前に、内部パケットを断片化されています。しかし、一つはIPv4のみが、この「飛行中の」断片化をサポートしていることに注意してください。さらに、それはないFragmentビットがセットされたパケットのために許可されていません。 1が完全にIPv6を無視することができたとしても、非常に多くのIPv4ホストスタックが、これは実現不可能と思われることを設定するDFビットのパケットを送信します。
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.
トンネルのエンドポイントによって断片化と再構築が問題に明確かつシンプルなソリューションですが、パケットが失われるハードウェアの再構築は克服できないかもしれ重要な実装上の課題に直面する可能性があります。このアプローチは、[12]フラグメント識別フィールドをラップでの問題に起因する高いデータ・レートで、特にIPv4のために、実現可能なようではありません。データレートは、IPv4用のMB / sのオーダーおよびIPv6のGB /秒の数十程度であるときに一定のラッピングが発生する可能性があります。しかし、この再構築のアプローチは、おそらく受動的な監視アプリケーションのための問題ではありません。
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.
PMTUD技術は、少なくとも現時点では、特にIPv4のために、バックボーンに使用するにはあまりにも信頼できないか、スケーラブルでないように見えます。将来のソリューションは、この局面では良い仕事かどうか未解決の問題です。
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. 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.
IPv4の場合2. DFビットが設定されていないパケットは、カプセル化の前に断片化することができる（及びカプセル化ヘッダは、DFビットセットを有するであろう）。そのDFビットセットされたパケットは、（これは非対応ですが）クリアDFビットを取得する必要があります。また、これは（信頼できない）は、インターネット全体のPMTUDの必要性を最小限に抑えることができます。
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.
明示的に注意すべき興味深いのは、トンネリングが高速バックボーンで行われたときに、典型的には、1つの環境上の仮定を作ることができるかもしれないということです。再組み立ては、ネットワークで実行されていない場合しかし、それはソフトウェアに以下の要件で行われ、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.
その結果、この時点での重要な質問が高いMTUは、トンネリングを展開高速ネットワークで想定することができるかどうか1）のように見える、と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.
しかし、別の解決策は、攻撃にそれらをより受けやすいことがあり特性を持っているかもしれない - 攻撃者がそれらのすべてを送信することなく、断片の十分な数を送信した場合、たとえば、ルータベースのフラグメント再構成を簡単に（再構築）バッファメモリの枯渇につながる可能性ように、再組み立てがタイムアウトするまでストールします。これらおよび他のフラグメント攻撃（例えば、[15]）は既に、例えば、ファイアウォールやホストスタックに対して使用、および実施において考慮される必要がされてきました。
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.マークTownsleyを持つ新しい、最近の議論から離れている間に座って、一般的に問題を書くために著者を引き起こしました。マイケル・リチャードソンとミカJoutsenvirtaは最初のバージョンで有用なフィードバックを提供します。 NANOGのリストからのコメントを募集する際、カールステンボーマン、ケビン・ミラー、ウォーレンクマリ、IljitschバンBeijnum、Alokデュベ、およびスティーブンJ.ウィルコックスは、有用なフィードバックを提供しました。その後、カルロスPignataroは、ドキュメントを改善するために貢献し、優れた入力を提供します。ジョー・タッチもメモに入力を提供します。
[1] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[1]パーキンス、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.ギリガン、 "IPv6ホストとルータのための基本的な変遷メカニズム"、RFC 4213、2005年10月。
[3] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[3]コンタ、A.、およびS.デアリング、 "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]ファリナッチ、D.、李、T.、ハンクス、S.、マイヤー、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]ラウ、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]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[7] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[7]モーグル、J.およびS.デアリング、 "経路MTUディスカバリ"、RFC 1191、1990年11月。
[8] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[8]マッキャン、J.、デアリング、S.、およびJ.ムガール人、RFC 1981 "IPバージョン6のパスMTUディスカバリー"、1996年8月。
[9] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[9]ブレーデン、R.、 "インターネットホストのための要件 - 通信層"、STD 3、RFC 1122、1989年10月。
[10] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[10]デアリング、S.と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.、カレル、D.、シモン、D.、およびR.ウィーラー、 "PPPオーバーイーサネット（PPPoEを）送信するための方法"、RFC 2516年2月1999。
[12] Mathis, M., "Fragmentation Considered Very Harmful", Work in Progress, July 2004.
[12]マシス、M.、 "非常に有害と考えられフラグメンテーション"、進歩、2004年7月の作業。
[13] Mathis, M. and J. Heffner, "Path MTU Discovery", Work in Progress, March 2006.
[13]マシス、M.とJ. Heffner、 "パスMTUディスカバリー"、進歩、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]メディナ、A.、オールマン、M.、およびS.フロイド、「インターネットにおけるトランスポートプロトコルの進化を測定する」、コンピュータコミュニケーションレビュー、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.
、RFC 3128、2001年6月[15]ミラー、I.、 "タイニーフラグメント攻撃（RFC 1858）のバリアントに対する保護"。
[16] Gont, F., "ICMP attacks against TCP", Work in Progress, February 2006.
[16] Gont、F.、 "TCPに対するICMP攻撃"、進歩、2006年2月に作業。
Appendix A. MTU of the Tunnel
トンネルの付録A. MTU
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バイト）を使用するかもしれません。いくつかの他のものでも、例えば、64キロバイトの「無限のMTU」を有するようにトンネルを扱うかもしれません。
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]常に外部パケット（決してインナパケット）を断片化、決してトンネルパスのPMTUDを行う、即ち、無限のMTUを有する、記載したように、特にホストとルータのシナリオでは、非常に悪い考えです。しかし、これはストレッチのように思える - （ノードが、これはホスト間のトンネルであることを確信している場合は、断片化と再組み立てはちょうど適切なサイズのパケットを送信するよりも効率的であれば、より大きなMTUは意味をなさない可能性があることを主張することができます。 ）
Author's Address
著者のアドレス
Pekka Savola CSC/FUNET Espoo Finland
ペッカSavola CSC / FUNETエスポーフィンランド
EMail: psavola@funet.fi
メールアドレス：psavola@funet.fi
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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）によって提供されます。