RFC1326 日本語訳

Network Working Group                                        P. Tsuchiya
Request for Comments: 1326                                      Bellcore
                                                                May 1992

Tsuchiyaがコメントのために要求するワーキンググループP.をネットワークでつないでください: 1326 Bellcore1992年5月

               Mutual Encapsulation Considered Dangerous

危険であると考えられた互いのカプセル化

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  It does
   not specify an Internet standard.  Distribution of this memo is
   unlimited.

このメモはインターネットコミュニティのための情報を提供します。 それはインターネット標準を指定しません。 このメモの分配は無制限です。

Abstract

要約

   This memo describes a packet explosion problem that can occur with
   mutual encapsulation of protocols (A encapsulates B and B
   encapsulates A).

このメモはプロトコルの互いのカプセル化で起こることができるパケット爆発問題について説明します(AがBを要約します、そして、BはAを要約します)。

The Current Environment

現在の環境

   In spite of international standardization efforts to the contrary, we
   are these days seeing a plethora of different protocols, both
   standard and proprietary, each designed to fill a technical or
   marketing niche.  The end result is that they eventually butt up
   against each other and are expected to interwork in some fashion.

国際標準化逆の方へ向かってする努力にもかかわらず、私たちは、最近、異なったプロトコルの標準の、そして、かつ独占である過剰がそれぞれ技術的であるか売り出している適所を中詰めに設計したのがわかっています。 結末はそれらが結局、互いに直面して隣接して、いくつかでファッションを織り込むと予想されるということです。

   One approach to this interworking is to encapsulate one protocol
   within another.  This has resulted in cases of mutual encapsulation,
   where protocol A runs over protocol B in some cases, and protocol B
   runs over protocol A in other cases.  For example, there exists cases
   of both IP over AppleTalk and AppleTalk over IP.  (The term mutual
   encapsulation comes from the paper by Shoch, Cohen, and Taft, called
   Mutual Encapsulation of Internetwork Protocols", Computer Networks 5,
   North-Holland, 1981, 287-300.  The problem identified in this RFC is
   not mentioned in the Shoch et. al. paper.)

この織り込むことへの1つのアプローチは別のものの中で1つのプロトコルを要約することです。 これは互いのカプセル化に関するケースをもたらしました、そして、プロトコルBは他の場合におけるプロトコルAをひきます。(いくつかの場合、そこでは、プロトコルAはプロトコルBをひきます)。 例えば、AppleTalkの上のIPとIPの上のAppleTalkの両方に関するケースは存在しています。 (「互いであるというカプセル化がShoch、コーエンによる紙、およびタフトから来させる用語、InternetworkプロトコルのMutual Encapsulationと呼ばれて、コンピュータNetworks5、北部オランダ1981、287-300 これで特定されて、RFCがあることにおける問題がShoch etで. アル紙を参照しなかった、)

   If there are not already other instances of mutual encapsulation,
   there will likely be more in the future.  This is particularly true
   with respect to the various internet protocols, such as IP, CLNP,
   AppleTalk, IPX, DECNET, and so on.

互いのカプセル化の他の例が既にないあると、将来、以上がおそらくあるでしょう。 これは様々なインターネットプロトコルに関して特に本当です、IP、CLNP、AppleTalk、IPX、DECNETなどなどのように。

The Problem

問題

   The problem with mutual encapsulation is the following.  Consider the
   topology shown in Figure 1.  We see two backbones and four stubs.
   Backbone B(X) uses a native protocol of X (that is, it expects to
   receive packets with a header for protocol X).  B(Y) uses a native

互いのカプセル化に関する問題は以下です。 図1に示されたトポロジーを考えてください。 私たちは2つの背骨と4つのスタッブを見ます。 背骨B(X)はXの固有のプロトコルを使用します(すなわち、それは、プロトコルXのためにヘッダーと共にパケットを受けると予想します)。 B(Y)はネイティブを使用します。

Tsuchiya                                                        [Page 1]

RFC 1326                Encapsulation Dangerous                 May 1992

1992年5月に危険なTsuchiya[1ページ]RFC1326カプセル化

   protocol of Y.  Likewise, the right and left S(Y) stubs use protocol
   Y, and the right and left S(X) stubs use protocol X.

Y.Likewiseのプロトコル、左右なS(Y)スタッブはプロトコルYを使用します、そして、左右なS(X)スタッブはプロトコルXを使用します。

          :::  :::::          :::::   :::          :::
 +------+ :Y   :X:Y  +------+ :X:Y    :Y  +------+ :Y   +------+
 |      | :::  ::::: |      | :::::   ::: |      | :::  |      |
 | S(Y) |-----Ra-----|      |-------Rb----|      |------| S(Y) |
 |      |            |      |             |      |      |      |
 +------+            |      |             |      |      +------+
                     | B(X) |             | B(Y) |
                     |      |             |      |
                :::  |      | :::   ::::: |      | :::::  :::
       +------+  X:  |      |  X:    X:Y: |      |  X:Y:   X: +------+
       |      | :::  |      | :::   ::::: |      | :::::  ::: |      |
       | S(X) |------|      |-----Rc------|      |------Rd----| S(X) |
       |      |      |      |             |      |            |      |
       +------+      |      |-----Re------|      |            +------+
                     +------+             +------+

::: ::::: ::::: ::: ::: +------+ :Y:X: Y+------+ :X: Y:Y+------+ :Y+------+ | | ::: ::::: | | ::::: ::: | | ::: | | | S(Y)|-----Ra-----| |-------Rb----| |------| S(Y)| | | | | | | | | +------+ | | | | +------+ | B(X)| | B(Y)| | | | | ::: | | ::: ::::: | | ::::: ::: +------+ X: | | X: X: Y: | | X: Y: X: +------+ | | ::: | | ::: ::::: | | ::::: ::: | | | S(X)|------| |-----Rc------| |------rd----| S(X)| | | | | | | | | +------+ | |-----re------| | +------+ +------+ +------+

   LEGEND:

伝説:

        :::::
         X:Y:  A packet with protocol X encapsulated in protocol
        :::::  Y, moving left to right

::::: X: Y: プロトコルXが中に要約されているパケットは以下について議定書の中で述べます:、:、:、: 右に左方へ動くY

           Rx  Router x

Rx Router x

         S(Y)  A stub network whose native protocol is protocol Y

S(Y)は固有のプロトコルがプロトコルYであるスタッブネットワークです。

         B(X)  A backbone network whose native protocol is protocol X

B(X)は固有のプロトコルがプロトコルXである背骨ネットワークです。

             FIGURE 1:  MUTUAL ENCAPSULATION

1図: 互いのカプセル化

   Figure 1 shows how packets would travel from left S(X) to right S(X),
   and from right S(Y) to left S(Y).  Consider a packet from left S(X)
   to right S(X).  The packet from left S(X) has just a header of X up
   to the point where it reaches router Rc.  Since B(Y) cannot forward
   header X, Rc encapsulates the packet into a Y header with a
   destination address of Rd.  When Rd receives the packet from B(Y), it
   strips off the Y header and forwards the X header packet to right
   S(X).  The reverse situation exists for packets from right S(Y) to
   left S(Y).

図1はパケットが左のS(X)から右のS(X)まで右のS(Y)から左のS(Y)までどう移動するだろうかを示しています。 左のS(X)から右のS(X)とパケットを考えてください。 左のS(X)からのパケットには、まさしくXのヘッダーがそれがルータRcに達するポイントまであります。 B(Y)がヘッダーXを進めることができないので、Rcは通りの送付先アドレスでYヘッダーにパケットをカプセルに入れります。 RdがB(Y)からパケットを受けるとき、それは、Yヘッダーを全部はぎ取って、Xヘッダーパケットを右のS(X)に送ります。 逆の状況は右のS(Y)から左のS(Y)までのパケットのために存在しています。

   In this example Rc and Rd treat B(Y) as a lower-level subnetwork in
   exactly the same way that an IP router currently treats an Ethernet
   as a lower-level subnetwork.  Note that Rc considers Rd to be the

この例では、RcとRdはまさに同じように低レベルサブネットワークとしてB(Y)を扱います。IPルータは現在、低レベルサブネットワークとしてイーサネットを扱います。 そのRcが、Rdは考えることに注意してください。

Tsuchiya                                                        [Page 2]

RFC 1326                Encapsulation Dangerous                 May 1992

1992年5月に危険なTsuchiya[2ページ]RFC1326カプセル化

   appropriate "exit router" for packets destined for right S(X), and Rb
   considers Ra to be the appropriate "exit router" for packets destined
   for left S(Y).

パケットのための適切な「出口ルータ」は右のS(X)のために運命づけられました、そして、RbはRaが左のS(Y)のために運命づけられたパケットのための適切な「出口ルータ」であると考えます。

   Now, assume that somehow a routing loop forms such that routers in
   B(Y) think that Rd is reachable via Rb, Rb thinks that Rd is
   reachable via Re, and routers in B(X) think that Re is reachable via
   Rc.  (This could result as a transient condition in the routing
   algorithm if Rd and Re crashed at the same time.) When the initial
   packet from left S(X) reaches Rc, it is encapsulated with Y and sent
   to B(Y), which forwards it onto Rb.  (The notation for this packet is
   Y<X>, meaning that X in encapsulated in Y.)

Rbは、RdにReを通して届いていると思います、そして、今度は、どうにかルーティングがRbを通して届いた状態でフォームを輪にすると仮定してください、そして、B(X)のルータはReにRcを通して届いていると思います。 (RdとReが同時にクラッシュするなら、これはルーティング・アルゴリズムによる一時的な状態として結果として生じることができるでしょうに。) 左のS(X)からの初期のパケットがRcに達するとき、それをYと共に要約して、B(Y)に送ります。(B(Y)はそれをRbに送ります)。 (Y.での要約にされるのでそのXを意味して、このパケットのための記法はY<X>です)

   When Rb receives Y<X> from B(Y), it encapsulates the packet in an X
   header to get it to Re through B(X).  Now the packet has headers
   X<Y<X>>.  In other words, the packet has two X encapsulates.  When Rc
   receives X<Y<X>>, it again encapsulates the packet, resulting in
   Y<X<Y<X>>>.  The packet is growing with each encapsulation.

RbがB(Y)からY<X>を受けるとき、それは、B(X)を通してそれをReに得るためにXヘッダーでパケットをカプセルに入れります。 今、パケットには、ヘッダーX<Y<X>>があります。 言い換えれば、パケットには、Xが要約する2があります。 RcがX<Y<X>>を受けるとき、Y<X<Y<X>>>をもたらして、それは再びパケットをカプセルに入れります。 パケットは各カプセル化で成長しています。

   Now, if we assume that each successive encapsulation does not
   preserve the hop count information in the previous header, then the
   packet will never expire.  Worse, the packet will eventually reach
   the Maximum Transmission Unit (MTU) size, and will fragment.  Each
   fragment will continue around the loop, getting successively larger
   until those fragments also fragment.  The result is an exponential
   explosion in the number of looping packets!

現在、私たちが、それぞれの連続したカプセル化が前のヘッダーにホップカウント情報を保存しないと思うと、パケットは決して期限が切れないでしょう。 よりひどく、パケットは、結局Maximum Transmission Unit(MTU)サイズに達して、断片化するでしょう。 また、それらの断片が断片化するまで相次ぐ増大して、各断片は輪の周りで続くでしょう。 結果はループパケットの数が指数の爆発です!

   The explosion will persist until the links are saturated, and the
   links will remain saturated until the loop is broken.  If the looping
   packets dominate the link to the point where other packets, such as
   routing update packets or management packets, are thrown away, then
   the loop may not automatically break itself, thus requiring manual
   intervention.  Once the loop is broken, the packets will quickly be
   flushed from the network.

リンクが飽和するまで、爆発は持続するでしょう、そして、輪が壊れるまで、リンクは飽和していたままで残るでしょう。 ループパケットがルーティングアップデートパケットか管理パケットなどの他のパケットが捨てられる肝心のリンクを支配しているなら、輪は自動的にそれ自体に壊れないかもしれません、その結果、手動の介入を必要とします。 輪がいったん壊れていると、パケットはネットワークからすぐに洗い流されるでしょう。

Potential Fixes

潜在的フィックス

   The first potential fix that comes to mind is to always preserve the
   hop count information in the new header.  Since hop count information
   is preserved in fragments, the explosion will not occur even if some
   fragmentation occurs before the hop count expires.  Not all headers,
   however, have hop count information in them (for instance, X.25 and
   SMDS).

思い浮かぶ最初の潜在的フィックスは新しいヘッダーにいつもホップカウント情報を保存することです。 ホップカウント情報が断片となって保存されるので、ホップカウントが期限が切れる前に何らかの断片化が起こっても、爆発は起こらないでしょう。 しかしながら、すべてのヘッダーが彼ら(例えば、X.25とSMDS)にホップカウント情報を持っているというわけではありません。

   And the hop counts ranges for different protocols are different,
   making direct translation not always possible.  For instance,
   AppleTalk has a maximum hop count of 16, whereas IP has up to 256.
   One could define a mapping whereby the hop count is lowered to fit

そして、ダイレクト翻訳をいつも可能であるというわけではなくして、異なったプロトコルのためのホップカウント範囲は異なっています。 例えば、AppleTalkには、16の最大のホップカウントがありますが、IPは最大256を持っています。 人はホップカウントが合うように下ろされるマッピングを定義できました。

Tsuchiya                                                        [Page 3]

RFC 1326                Encapsulation Dangerous                 May 1992

1992年5月に危険なTsuchiya[3ページ]RFC1326カプセル化

   into the smaller range when necessary.  This, however, might often
   result in unnecessary black holes because of overly small hop counts.
   There are for instance many IP paths that are longer than 16 hops.

より小さく、必要であるときには及んでください。 しかしながら、これはひどく小さいホップカウントのためにしばしば不要なブラックホールをもたらすかもしれません。 例えば、多くの16のホップより長いIP経路があります。

   It is worth noting that the current IP over AppleTalk Internet Draft
   does not preserve hop counts ("A Standard for the Transmission of
   Internet Packets Over AppleTalk Networks").

AppleTalkインターネットDraftの上の現在のIPがホップカウント(「AppleTalkネットワークの上のインターネットパケットのトランスミッションの規格」)を保存しないことに注意する価値があります。

   Another potential fix is to have routers peek into network layer
   headers to see if the planned encapsulation already exists.  For
   instance, in the example of Figure 1, when Rb receives Y<X>, it would
   see what Y had encapsulated (for instance by looking at the protocol
   id field of X's header), notice that X has already been encapsulated,
   and throw away the packet.  If the encapsulation loop involves more
   than two protocols, then the router may have to peek into successive
   network layer headers.  It would quit when it finally got to a
   transport layer header.

別の潜在的フィックスはルータを計画されたカプセル化が既に存在するかどうか確認するためにネットワーク層ヘッダーを覗き見させることです。 例えば、図1に関する例では、RbがY<X>を受けるとき、それは、Yが要約した(例えばXのヘッダーのプロトコルイド分野を見ることによって)ものを見て、Xが既に要約されたのに気付いて、パケットを捨てるでしょう。 カプセル化輪が2つ以上のプロトコルにかかわるなら、ルータは連続したネットワーク層ヘッダーを覗き見されなければならないかもしれません。 最終的にトランスポート層ヘッダーを始めたとき、それはやめるでしょう。

   There are several pitfalls with this approach.  First, it is always
   possible that a network layer protocol is being encapsulated within a
   transport layer protocol, thus I suppose requiring that the router
   continue to peek even above the transport layer.

このアプローチがあるいくつかの落とし穴があります。 まず最初にネットワーク層プロトコルがトランスポート層プロトコルの中で要約されているのが、いつも可能である、その結果、ルータが、トランスポート層を超えてさえ覗き見し続けるのが必要でありながら、私は思います。

   Second, the router may not recognize one of the network layer
   headers, thus preventing it from peeking any further.  For instance,
   consider a loop involving three routers Rxy, Ryz, and Rzx, and three
   protocols X, Y, and Z (the subscripts on the routers R denote which
   protocols the router recognizes).  After the first loop, Rxy receives
   X<Z<Y<X>>>.  Since Rxy does not recognize Z, it cannot peek beyond Z
   to discover the embedded Y header.

2番目に、ルータはネットワーク層ヘッダーのひとりを認識して、その結果、それがこれ以上覗き見されるのを防ぐことがないかもしれません。 例えば、輪の意味ありげな3つのルータがRxy、Ryzであり、Xと、Yと、Rzx、および3つのプロトコルがZであると考えてください(ルータRの添字はルータが認識するどのプロトコルを指示するか)。 最初の輪の後に、RxyはX<Z<Y<X>>>を受けます。 RxyがZを認識しないので、それは埋め込まれたYヘッダーを発見するためにZを超えて覗き見されることができません。

   Third, a router may be encrypting the packet that it sends to its
   peer, such as is done with Blacker routers.  For instance, Rc might
   be encrypting packets that it encapsulates for Rd, expecting Rd to
   decrypt it.  When Rb receives this packet (because of the loop), it
   cannot peek beyond the Y header.

3番目に、ルータはそれがBlackerルータでするような同輩に送るパケットをコード化しているかもしれません。 例えば、Rdがそれを解読すると予想して、RcはそれがRdのためにカプセルに入れるパケットをコード化しているかもしれません。 Rbがこのパケット(輪による)を受けるとき、それはYヘッダーを超えて覗き見されることができません。

   Finally, there may be situations where it is appropriate to have
   multiple instances of the same header.  For instance, in the nested
   mutual encapsulation of Figure 2, Ra will encapsulate Y in X to get
   it to Rd, but Rb will encapsulate X<Y> in Y to get it to Rc.  In this
   case, it is appropriate for Rb to transmit a packet with two Y
   headers.

最終的に、状況が同じヘッダーの複数の例を持っているのが適切であるところにあるかもしれません。 例えば、図2の入れ子にされた互いのカプセル化では、RaはそれをRdに得るためにXでYを要約するでしょうが、Rbは、それをRcに得るためにYでX<Y>を要約するでしょう。 この場合、Rbが2個のYヘッダーと共にパケットを伝えるのは、適切です。

   A third (somewhat hybrid) solution is to outlaw nested mutual
   encapsulation, employ both hop count preservation and header peeking
   where appropriate, and generally discourage the use of mutual
   encapsulation (or at least adopt the attitude that those who engage

3番目の(いくらかハイブリッド)の解決策が入れ子にされた互いのカプセル化を禁止して、適切であるところでホップカウント保存とヘッダー覗き見の両方を使って、一般に、互いのカプセル化の使用に水をさしていることである、(態度を少なくとも採用してください、それ、従事する人

Tsuchiya                                                        [Page 4]

RFC 1326                Encapsulation Dangerous                 May 1992

1992年5月に危険なTsuchiya[4ページ]RFC1326カプセル化

   in mutual encapsulation deserve what they get).

互いのカプセル化では、彼らが得るものに値してください、)

                     +--------------------+
                     |                    |
                     |               B(X) |
       +------+      |      +------+      |      +------+
       |      |      |      |      |      |      |      |
       | S(Y) |--Ra--+   Rb-| B(Y) |-Rc   +--Rd--| S(Y) |
       |      |      |      |      |      |      |      |
       +------+      |      +------+      |      +------+
                     |                    |
                     |                    |
                     +--------------------+

+--------------------+ | | | B(X)| +------+ | +------+ | +------+ | | | | | | | | | S(Y)|--Ra--+ Rb| B(Y)|-Rc+--、第--| S(Y)| | | | | | | | | +------+ | +------+ | +------+ | | | | +--------------------+

                FIGURE 2:  NESTED MUTUAL ENCAPSULATION

2は計算します: 入れ子にされた互いのカプセル化

Security Considerations

セキュリティ問題

   Security issues are not discussed in this memo.

このメモで安全保障問題について議論しません。

Author's Address

作者のアドレス

   Paul Tsuchiya
   Bellcore
   435 South St.
   MRE 2L-281
   Morristown, NJ 07960

南MRE 2L-281聖モリスタウン、ポールTsuchiya Bellcore435ニュージャージー 07960

   Phone: (908) 829-4484
   EMail:  tsuchiya@thumper.bellcore.com

以下に電話をしてください。 (908) 829-4484 メールしてください: tsuchiya@thumper.bellcore.com

Tsuchiya                                                        [Page 5]

Tsuchiya[5ページ]