RFC4459 日本語訳

Network Working Group                                          P. Savola
Request for Comments: 4459                                     CSC/FUNET
Category: Informational                                       April 2006

Savolaがコメントのために要求するワーキンググループP.をネットワークでつないでください: 4459年のCSC/FUNETカテゴリ: 情報の2006年4月

       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)インターネット協会(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における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

1. 序論…2 2. 問題声明…3 3. ソリューションの記述…4 3.1. 断片化とトンネル終点のそばのReassembly…4 3.2. 下側のMTUにソースまで合図します…5 3.3. 要約してください。Only When ThereはFree MTUです…6 3.4. 内側のパケットの断片化…8 4. 結論…9 5. セキュリティ問題…10 6. 承認…11 7. 参照…11 7.1. 標準の参照…11 7.2. 有益な参照…12

Savola                       Informational                      [Page 1]

RFC 4459         Packet Size Issues in Network Tunnels        April 2006

サイズが2006年4月にネットワークTunnelsで発行するSavolaの情報[1ページ]のRFC4459パケット

1.  Introduction

1. 序論

   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])、Genericルート設定Encapsulation(GRE)[4]、Layer2Tunnelingプロトコル(L2TP)[5]、またはトンネルモードによるIP Security(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冊が共通です: ソースがどのように最大のパケットサイズを選択するかので、パケットは、合って、カプセルに入れられさえしました、ネットワークにおける横断された経路の最も小さいMaximum Transmission Unit(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ディスカバリー(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

また、IPsecの上で例えば複数の層のカプセル化、GREまたはL2TPを走らせるのも一般的です。 トンネル終点は、ネットワークにおける入れ子にされたトンネルについて、同じであるか、または異なる場合があります、そして、両方の内側の、そして、外側のトンネルには、異なったMTU取り扱い戦略があるかもしれません。 コネ

Savola                       Informational                      [Page 2]

RFC 4459         Packet Size Issues in Network Tunnels        April 2006

サイズが2006年4月にネットワークTunnelsで発行するSavolaの情報[2ページ]のRFC4459パケット

   particular, signalling may be a scalable option for the outer tunnel
   or tunnels if the number of innermost tunnel endpoints is limited.

特定です、最も奥深いトンネル終点の数が限られるなら、合図は外トンネルかトンネルのためのスケーラブルなオプションであるかもしれません。

   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.

トンネリングパケットサイズ問題はPath 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.

この議論の大部分が下側のMTUとのリンクが経路に存在するより一般的なケースに適用されることに注意する価値があります。 この具体的で広く配備された例は顧客のアクセスリンクのイーサネット(PPPoE)[11]の上のPPPの使用法です。 これらの下側のMTUリンク、および特にPPPoEリンクが断片化と再アセンブリが実行不可能であるかもしれないtopologies(例えば、背骨)で通常配備されないので、これはわずかに簡単な問題であるかもしれません。 しかしながら、このより一般的なケースはこのメモの範囲から考えられます。

   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 Packet Too Bigメッセージに基づく発見されたインタフェースMTUをアップデートして、要約のパケットの源にICMP Packet Too Bigメッセージを溯源して戻す必要があるでしょう。 また、これは、ICMPメッセージ(IPv4ヘッダーの後の必要な64ビットを超えた)で十分なデータを背負ってあると仮定します。 そして、私たちが、セクション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は結論を提示します。

2.  Problem Statement

2. 問題声明

   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

したがって、断片化を避けて、できれば、再アセンブリするのは望ましいです。 他方では、他の解決策はそうではありません。

Savola                       Informational                      [Page 3]

RFC 4459         Packet Size Issues in Network Tunnels        April 2006

サイズが2006年4月にネットワークTunnelsで発行するSavolaの情報[3ページ]のRFC4459パケット

   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 Packet Too Bigに送るケースを考えてください。 カプセル化がまた、IPv6で利用可能でなくて、また利用可能にならない前のFragment(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.

この問題にはどんな些細な解決策もないこれはもたらされます、そして、取り引きがoffsであると考えるためにさらに探検されるのが必要です、このメモでするように。

3.  Description of Solutions

3. ソリューションの記述

   This section describes the potential solutions in a bit more detail.

このセクションはもう少しの詳細に潜在的解決策を説明します。

3.1.  Fragmentation and Reassembly by the Tunnel Endpoints

3.1. 断片化とトンネル終点のそばのReassembly

   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:

トンネリングパケットサイズ問題の外観上最も簡単な解決はdecapsulatorによるencapsulatorと再アセンブリによる外側のパケットの断片化です。 しかしながら、これは少なくとも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 断片化はオーバーヘッドを引き起こします: あらゆる断片が(20バイトか40バイト)、およびIPv6(Fragment Headerのための追加8バイト)と共にIPヘッダーを必要とします。

   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])。 線にこれをしなければならなかったら評価してください、例えば、10Gbit/s速度(その再アセンブリが禁止であることを必要とするかもしれないバッファの長さ)

Savola                       Informational                      [Page 4]

RFC 4459         Packet Size Issues in Network Tunnels        April 2006

サイズが2006年4月にネットワークTunnelsで発行するSavolaの情報[4ページ]のRFC4459パケット

   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は、データ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.

IPv6、および要約のヘッダーに設定されたDFビットがある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.

Appendix Aが説明するように、また、トンネルのMTUはパケットが断片化を必要として、再アセンブリされる要素です。 トンネルMTUが物理インターフェースMTUsと「無限」か等しいなら、最悪の場合は起こります。

   So, if reassembly could be made to work sufficiently reliably, this
   would be one acceptable fallback solution but only for IPv6.

それで、再アセンブリは十分確かに働かされることができるなら、これが1つの許容できる後退解決策にもかかわらず、IPv6のためだけのものでしょうに。

3.2.  Signalling the Lower MTU to the Sources

3.2. 下側のMTUにソースまで合図します。

   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。 推進のふるまい: IPv4DFビットが設定されるならパケットを進めるとき、出口のリンクのMTUが小さ過ぎるなら、ルータはICMP Packet Too Bigメッセージをソースに送ります。

   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 Packet Too Bigメッセージはトンネルに関連しました、それ。(1)はトンネルMTUを調整します、そして、(2)は要約のパケットのソースアドレスにICMP Packet Too Bigメッセージを溯源します。 (2) すぐにか次のパケットがICMPの引き金となるのを待つことによって、することができます。 前者はMTU変化によるパケット損失を最小にします。

Savola                       Informational                      [Page 5]

RFC 4459         Packet Size Issues in Network Tunnels        April 2006

サイズが2006年4月にネットワークTunnelsで発行するSavolaの情報[5ページ]のRFC4459パケット

   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キロバイトではなく、妥当なサイズのものであるならこれが働くだけであることに注意してください: 詳しい情報については、Appendix 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のために働いていて、操作に、重要ですが、例えば不適当にすべてのICMPパケット[14]、またはソフトウェアのバグ表現PMTUD inoperationalを落とすために構成されるIPv4では、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つのシナリオがネットワークから合図するのが非常に望ましくないところにあります。 1番目はカプセル化がネットワークにおける非常に多くのソースが、この情報で合図される必要があるくらいの(どれくらい長さであることによって、ことによると複数の回さえ、それらは、それらのPMTUDが状態であることを保ちます)目立つ場所で行われる時です。 2番目はカプセル化が受け身のモニターしている目的(ネットワークマネージメント、合法的な妨害など)のために行われる時です。 -- 交通が要約されているソースがこの出来事を意識していないのが、批判的であるときに。

   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パケットのMaximum Segment Size(MSS)はトンネル終点によって減少させられるので、TCP接続はそれ自体を最大の有効なパケットサイズに自動的に制限します。 明らかに、これはMSSを全く持っていないUDPか他のプロトコルのために働いていません。 このアプローチは、最も適切であり、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]にありますが、少なくとも受け身の監視要件でない。

3.3.  Encapsulate Only When There is Free MTU

3.3. 要約、Only When ThereはFree MTUです。

   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

カプセル化と被膜剥離術が実行されている環境によって、3番目のアプローチは操作上のものです。 すなわち、ISPが背骨のトンネリングを配備するなら、どれが高いMTUsを支持するリンクだけから成るでしょうか?

Savola                       Informational                      [Page 6]

RFC 4459         Packet Size Issues in Network Tunnels        April 2006

サイズが2006年4月にネットワークTunnelsで発行するSavolaの情報[6ページ]のRFC4459パケット

   (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.

(例えば、GigabitイーサネットかSDH/Sonet)、そのすべての顧客と同輩だけがa下側の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からの/にトンネルを造るのにおいて望ましいかもしれません。 または、トンネリング要件を満たすために、より高いMTUsを支持できないネットワークにはリンクがあるかもしれません。 または、トンネルは顧客と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.

別のもの、関連するアプローチで、ソースはすべての物理的なMTUsをうまくはめ込む十分低い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の2つの層がトンネルを堀って、バイト、またはいつがトンネルを堀って、IPv6のIPv6を持っているときには1280年の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を制限することによってどんな問題も避けるのが可能であるかもしれませんが、これはたぶん結局、設備業者の十分良い一般解ではありません。 また、他の解決法を提供しなければなりません。

Savola                       Informational                      [Page 7]

RFC 4459         Packet Size Issues in Network Tunnels        April 2006

サイズが2006年4月にネットワークTunnelsで発行するSavolaの情報[7ページ]のRFC4459パケット

3.4.  Fragmentation of the Inner Packet

3.4. 内側のパケットの断片化

   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も噛み付かなかったドンが用意ができていたところにそれはパケットのために許容されていません。 人が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と共に働いてください、そして、一般的な解決策であるとそれを考えることができませんでした。

Savola                       Informational                      [Page 8]

RFC 4459         Packet Size Issues in Network Tunnels        April 2006

サイズが2006年4月にネットワークTunnelsで発行するSavolaの情報[8ページ]のRFC4459パケット

4.  Conclusions

4. 結論

   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/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.

問題へのオペレーショナル・アプローチでありいくつかの環境で、断片化は要約されているところにネットワークで、より高いMTUsを保つことによって決して必要でないことをパケットが横断する確実にするのが十分であることが、明確です。 しかし、これは一般に、そして、およびオペレータの展開に関する仮定をすることができないかもしれない業者にとって十分でありそうにはありません。

   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で可能であるだけであり、規格-incompliantのふるまいが悪い副作用(例えば、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. IPv4に関しては、カプセル化の前に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

明らかに注意するおもしろいことは高速バックボーンでトンネリングをするとき、通常、環境で仮定をすることができるかもしれないということです。 しかしながら、そのようなネットワークで再アセンブリを実行しないとき、ソフトウェアか下側の要件でそれをするかもしれません、そして、再アセンブリは存在しています。

Savola                       Informational                      [Page 9]

RFC 4459         Packet Size Issues in Network Tunnels        April 2006

サイズが2006年4月にネットワークTunnelsで発行するSavolaの情報[9ページ]のRFC4459パケット

   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.

その結果、「より遅い速度」ネットワークがソフトウェアベースの再アセンブリ、それほどできないハードウェアベースの再アセンブリ、または他の次善策を切り抜けることができたか否かに関係なく、トンネリング、および2を)配備する高速ネットワークで、より高いMTUを想定できるか否かに関係なく、批判的な質問はここに1であるように)見えます。 重要な将来のタスクは、それには何か思いがけない欠点があるかどうかに注意するためにDFビットに関して観測されたincompliantのふるまいを分析することでしょう。

5.  Security Considerations

5. セキュリティ問題

   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 Packet Too Bigメッセージにスループット断片化/再アセンブリサービス不能攻撃として減少するために非常に低いMTUを示させることができました。 この攻撃は[16]でTCPの文脈で説明されます。

Savola                       Informational                     [Page 10]

RFC 4459         Packet Size Issues in Network Tunnels        April 2006

サイズが2006年4月にネットワークTunnelsで発行するSavolaの情報[10ページ]のRFC4459パケット

6.  Acknowledgements

6. 承認

   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.

話題はW.マークTownsleyとのL2TPについての新しくて、最近の議論から遠いのですが、断片化問題は、一般に、作者が座って、問題を詳しく書くことを引き起こしました。 マイケル・リチャードソンとミカJoutsenvirtaは最初のバージョンの役に立つフィードバックを提供しました。 NANOGリストからコメントに請求するとき、カルステン・ボルマン、ケビン・ミラー、ウォレンKumari、IljitschバンBeijnum、Alokデュベ、およびスティーブン・J.ウィルコックスは役に立つフィードバックを提供しました。 その後、ドキュメントを改良するのを助けて、カルロスPignataroは素晴らしい入力を提供しました。 また、ジョーTouchはメモに関する入力を提供しました。

7.  References

7. 参照

7.1.  Normative References

7.1. 引用規格

   [1]   Perkins, C., "IP Encapsulation within IP", RFC 2003, October
         1996.

[1] パーキンス、C.、「IPの中のIPカプセル化」、RFC2003、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ホストとルータのための基本的な変遷メカニズム」、RFC4213、2005年10月。

   [3]   Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6
         Specification", RFC 2473, December 1998.

[3] コンタとA.とS.デアリング、「IPv6仕様による一般的なパケットトンネリング」、RFC2473、1998年12月。

   [4]   Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina,
         "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.

2000年3月の[4] ファリナッチとD.と李とT.とハンクスとS.とマイヤー、D.とP.Traina、「一般ルーティングのカプセル化(GRE)」RFC2784。

   [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)」、RFC3931、3月2005日

   [6]   Kent, S. and K. Seo, "Security Architecture for the Internet
         Protocol", RFC 4301, December 2005.

[6] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、2005年12月。

   [7]   Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
         November 1990.

[7] ムガール人とJ.とS.デアリング、「経路MTU探索」、RFC1191、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.ムガール人、「IPのための経路MTUディスカバリー、バージョン6インチ、RFC1981、1996インチ年8月。

   [9]   Braden, R., "Requirements for Internet Hosts - Communication
         Layers", STD 3, RFC 1122, October 1989.

[9] ブレーデン、R.、「インターネットのためのホスト--コミュニケーションが層にされるという要件」、STD3、RFC1122、10月1989日

   [10]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
         Specification", RFC 2460, December 1998.

[10] デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日

Savola                       Informational                     [Page 11]

RFC 4459         Packet Size Issues in Network Tunnels        April 2006

サイズが2006年4月にネットワークTunnelsで発行するSavolaの情報[11ページ]のRFC4459パケット

7.2.  Informative References

7.2. 有益な参照

   [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.、エバーツ、J.、個人閲覧室、D.、シモン、D.、およびR.ウィーラー、「イーサネットの上にpppを伝えるための方法(PPPoE)」、RFC2516(1999年2月)。

   [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] 「経路MTU発見」というマシス、M.、およびJ.ヘフナーは進歩、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.

[15] ミラー、I.、「小さい断片攻撃の異形に対する保護、(RFC1858)、」、RFC3128、6月2001日

   [16]  Gont, F., "ICMP attacks against TCP", Work in Progress,
         February 2006.

[16]Gont、F.、「TCPに対するICMP攻撃」、Progress、2006年2月のWork。

Savola                       Informational                     [Page 12]

RFC 4459         Packet Size Issues in Network Tunnels        April 2006

サイズが2006年4月にネットワークTunnelsで発行するSavolaの情報[12ページ]のRFC4459パケット

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を使用するかもしれません。 何人かの他のものが予想されたIPオーバーヘッド(例えば、20バイトか28バイトか40バイト)を引いてデフォルトMTUを使用するかもしれません。 何人かの他のものが「無限の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]が説明するように、すなわち、いつも外側のパケット(そして、決して内側のパケットでない)を断片化して、トンネル経路にPMTUDを決して実行しないことで無限のMTUを持つのは、非常に悪い考えです、特にホストからルータへのシナリオで。 (ノードがこれがホストからホストへのトンネルであることを確信しているなら、断片化と再アセンブリがただ適切に発信するのがパケットを大きさで分けたより効率的であるならさらに大きいMTUが理解できるかもしれませんが、これが伸びのように見えると主張できました。)

Author's Address

作者のアドレス

   Pekka Savola
   CSC/FUNET
   Espoo
   Finland

ペッカ・Savola CSC/FUNETエスポーフィンランド

   EMail: psavola@funet.fi

メール: psavola@funet.fi

Savola                       Informational                     [Page 13]

RFC 4459         Packet Size Issues in Network Tunnels        April 2006

サイズが2006年4月にネットワークTunnelsで発行するSavolaの情報[13ページ]のRFC4459パケット

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2006).

Copyright(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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。

Savola                       Informational                     [Page 14]

Savola情報です。[14ページ]