RFC1701 日本語訳

Network Working Group                                           S. Hanks
Request for Comments: 1701                               NetSmiths, Ltd.
Category: Informational                                            T. Li
                                                            D. Farinacci
                                                               P. Traina
                                                           cisco Systems
                                                            October 1994

一かせがコメントのために要求するワーキンググループS.をネットワークでつないでください: 1701年のNetSmiths Ltd.カテゴリ: 情報のT.のD.ファリナッチP.Traina李コクチマスSystems1994年10月

                  Generic Routing Encapsulation (GRE)

一般ルーティングのカプセル化(GRE)

Status of this Memo

このMemoの状態

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

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

Abstract

要約

   This document specifies a protocol for performing encapsulation of an
   arbitrary network layer protocol over another arbitrary network layer
   protocol.

このドキュメントは別の任意のネットワーク層プロトコルの上で任意のネットワーク層プロトコルのカプセル化を実行するのにプロトコルを指定します。

Introduction

序論

   A number of different proposals [RFC 1234, RFC 1226] currently exist
   for the encapsulation of one protocol over another protocol. Other
   types of encapsulations [RFC 1241, SDRP, RFC 1479] have been proposed
   for transporting IP over IP for policy purposes. This memo describes
   a protocol which is very similar to, but is more general than, the
   above proposals.  In attempting to be more general, many protocol
   specific nuances have been ignored.  The result is that this proposal
   is may be less suitable for a situation where a specific "X over Y"
   encapsulation has been described.  It is the attempt of this protocol
   to provide a simple, general purpose mechanism which is reduces the
   problem of encapsulation from its current O(n^2) problem to a more
   manageable state.  This proposal also attempts to provide a
   lightweight encapsulation for use in policy based routing.  This memo
   explicitly does not address the issue of when a packet should be
   encapsulated.  This memo acknowledges, but does not address problems
   with mutual encapsulation [RFC 1326].

多くの異なった提案[RFC1234、RFC1226]が現在、1つのプロトコルのカプセル化のために別のプロトコルの上に存在します。 他のタイプのカプセル化[RFC1241、SDRP、RFC1479]は輸送しているIPのために政策目的のためのIPの上で提案されました。 このメモが非常に同様のプロトコルについて説明する、 より一般的である、上の提案。 より一般的であることを試みる際に、多くのプロトコルの特定のニュアンスが無視されました。 結果はこの提案がそれほど特定の「Yの上のX」カプセル化が説明される状況に適しないかもしれないということであるということです。 このプロトコルがそうする簡単で、汎用のメカニズムを提供する試みが現在のO(n^2)問題から、より処理しやすい状態にカプセル化の問題を減少させるということです。 また、この提案は、方針における使用のための軽量のカプセル化にベースのルーティングを提供するのを試みます。 このメモは明らかにパケットがカプセルに入れられるべきである時に関する問題を扱いません。 承認しますが、このメモは互いのカプセル化[RFC1326]に関するその問題を訴えません。

   In the most general case, a system has a packet that needs to be
   encapsulated and routed.  We will call this the payload packet.  The
   payload is first encapsulated in a GRE packet, which possibly also
   includes a route.  The resulting GRE packet can then be encapsulated
   in some other protocol and then forwarded.  We will call this outer

最も一般的な場合では、システムはカプセル化されて、発送される必要があるパケットを、持っています。 私たちは、これをペイロードパケットと呼ぶつもりです。 ペイロードは最初に、GREパケットでカプセル化されます。(ことによると、また、それは、ルートを含んでいます)。 次に、結果として起こるGREパケットをある他のプロトコルでカプセルに入れって、次に、進めることができます。 私たちが、これと呼ぶつもりである、外側

Hanks, Li, Farinacci & Traina                                   [Page 1]

RFC 1701          Generic Routing Encapsulation (GRE)       October 1994

ハンクス、李、ファリナッチ、およびTraina[1ページ]RFC1701一般ルーティングのカプセル化(GRE)1994年10月

   protocol the delivery protocol. The algorithms for processing this
   packet are discussed later.

配送プロトコルについて議定書の中で述べてください。 後でこのパケットを処理するためのアルゴリズムについて議論します。

Overall packet

総合的なパケット

   The entire encapsulated packet would then have the form:

次に、全体のカプセル化されたパケットには、フォームがあるでしょう:

                  ---------------------------------
                  |                               |
                  |       Delivery Header         |
                  |                               |
                  ---------------------------------
                  |                               |
                  |       GRE Header              |
                  |                               |
                  ---------------------------------
                  |                               |
                  |       Payload packet          |
                  |                               |
                  ---------------------------------

--------------------------------- | | | 配送ヘッダー| | | --------------------------------- | | | GREヘッダー| | | --------------------------------- | | | 有効搭載量パケット| | | ---------------------------------

Packet header

パケットのヘッダー

   The GRE packet header has the form:

GREパケットのヘッダーには、フォームがあります:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |C|R|K|S|s|Recur|  Flags  | Ver |         Protocol Type         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Checksum (optional)      |       Offset (optional)       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Key (optional)                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Sequence Number (optional)                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Routing (optional)
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C|R|K|S|s|再発してください。| 旗| Ver| プロトコルタイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム(任意の)| 相殺されます(任意の)。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 主要です(任意の)。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 一連番号(任意の)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ルート設定(任意の)+++++++++++++++++++++++++++++++++

      Flags and version (2 octets)

旗とバージョン(2つの八重奏)

      The GRE flags are encoded in the first two octets.  Bit 0 is the
      most significant bit, bit 15 is the least significant bit.  Bits
      13 through 15 are reserved for the Version field.  Bits 5 through
      12 are reserved for future use and MUST be transmitted as zero.

GRE旗は最初の2つの八重奏でコード化されます。 ビット0が最も重要なビットである、ビット15は最下位ビットです。 バージョン分野へのビット13〜15は予約されます。 ビット5〜12を今後の使用のために予約されて、ゼロとして伝えなければなりません。

Hanks, Li, Farinacci & Traina                                   [Page 2]

RFC 1701          Generic Routing Encapsulation (GRE)       October 1994

ハンクス、李、ファリナッチ、およびTraina[2ページ]RFC1701一般ルーティングのカプセル化(GRE)1994年10月

      Checksum Present (bit 0)

チェックサムプレゼント(ビット0)

      If the Checksum Present bit is set to 1, then the Checksum field
      is present and contains valid information.

Checksum Presentビットが1に設定されるなら、Checksum分野は、存在していて、有効な情報を含んでいます。

      If either the Checksum Present bit or the Routing Present bit are
      set, BOTH the Checksum and Offset fields are present in the GRE
      packet.

噛み付かれたルート設定PresentがBOTHのChecksum Presentが噛み付いたか、セットと、ChecksumとOffsetであるなら、分野はGREパケットに存在しています。

      Routing Present (bit 1)

ルート設定プレゼント(ビット1)

      If the Routing Present bit is set to 1, then it indicates that the
      Offset and Routing fields are present and contain valid
      information.

ルート設定Presentビットが1に設定されるなら、それは、Offsetとルート設定分野が存在していて、有効な情報を含むのを示します。

      If either the Checksum Present bit or the Routing Present bit are
      set, BOTH the Checksum and Offset fields are present in the GRE
      packet.

噛み付かれたルート設定PresentがBOTHのChecksum Presentが噛み付いたか、セットと、ChecksumとOffsetであるなら、分野はGREパケットに存在しています。

      Key Present (bit 2)

キープレゼント(ビット2)

      If the Key Present bit is set to 1, then it indicates that the Key
      field is present in the GRE header.  Otherwise, the Key field is
      not present in the GRE header.

Key Presentビットが1に設定されるなら、それは、Key分野がGREヘッダーに存在しているのを示します。 さもなければ、Key分野はGREヘッダーに存在していません。

      Sequence Number Present (bit 3)

一連番号プレゼント(ビット3)

      If the Sequence Number Present bit is set to 1, then it indicates
      that the Sequence Number field is present.  Otherwise, the
      Sequence Number field is not present in the GRE header.

Sequence Number Presentビットが1に設定されるなら、それは、Sequence Number分野が存在しているのを示します。 さもなければ、Sequence Number分野はGREヘッダーに存在していません。

      Strict Source Route (bit 4)

厳しい送信元経路(ビット4)

      The meaning of the Strict Source route bit is defined in other
      documents.  It is recommended that this bit only be set to 1 if
      all of the the Routing Information consists of Strict Source
      Routes.

Strict Sourceルートビットの意味は他のドキュメントで定義されます。 経路情報のすべてがStrict Source Routesから成るならこのビットが1にしか設定されないのは、お勧めです。

      Recursion Control (bits 5-7)

再帰コントロール(ビット5-7)

      Recursion control contains a three bit unsigned integer which
      contains the number of additional encapsulations which are
      permissible.  This SHOULD default to zero.

再帰コントロールは許されている追加カプセル化の数を含む3の噛み付いている符号のない整数を含んでいます。 このSHOULDはゼロをデフォルトとします。

      Version Number (bits 13-15)

バージョン番号(ビット13-15)

      The Version Number field MUST contain the value 0.  Other values
      are outside of the scope of this document.

バージョンNumber分野は値0を含まなければなりません。 他の値がこのドキュメントの範囲の外にあります。

Hanks, Li, Farinacci & Traina                                   [Page 3]

RFC 1701          Generic Routing Encapsulation (GRE)       October 1994

ハンクス、李、ファリナッチ、およびTraina[3ページ]RFC1701一般ルーティングのカプセル化(GRE)1994年10月

      Protocol Type (2 octets)

プロトコルタイプ(2つの八重奏)

      The Protocol Type field contains the protocol type of the payload
      packet.  In general, the value will be the Ethernet protocol type
      field for the packet.  Currently defined protocol types are listed
      below.  Additional values may be defined in other documents.

プロトコルType分野はペイロードパケットのプロトコルタイプを含んでいます。 一般に、値はパケットのためにイーサネットプロトコルタイプ分野になるでしょう。 現在定義されたプロトコルタイプは以下に記載されています。 加算値は他のドキュメントで定義されるかもしれません。

      Offset (2 octets)

相殺されます。(2つの八重奏)

      The offset field indicates the octet offset from the start of the
      Routing field to the first octet of the active Source Route Entry
      to be examined.  This field is present if the Routing Present or
      the Checksum Present bit is set to 1, and contains valid
      information only if the Routing Present bit is set to 1.

オフセット分野は、八重奏がルート設定分野の始まりから最初の調べられるべきアクティブなSource Route Entryの八重奏まで相殺されたのを示します。 この分野は、ルート設定PresentかChecksum Presentビットが1に用意ができているなら存在していて、ルート設定Presentビットが1に設定される場合にだけ、有効な情報を含んでいます。

      Checksum (2 octets)

チェックサム(2つの八重奏)

      The Checksum field contains the IP (one's complement) checksum of
      the GRE header and the payload packet.  This field is present if
      the Routing Present or the Checksum Present bit is set to 1, and
      contains valid information only if the Checksum Present bit is set
      to 1.

Checksum分野はGREヘッダーとペイロードパケットのIP(1の補数)チェックサムを含んでいます。 この分野は、ルート設定PresentかChecksum Presentビットが1に用意ができているなら存在していて、Checksum Presentビットが1に設定される場合にだけ、有効な情報を含んでいます。

      Key (4 octets)

キー(4つの八重奏)

      The Key field contains a four octet number which was inserted by
      the encapsulator.  It may be used by the receiver to authenticate
      the source of the packet.  The techniques for determining
      authenticity are outside of the scope of this document.  The Key
      field is only present if the Key Present field is set to 1.

Key分野はencapsulatorによって挿入された4八重奏番号を含んでいます。 それは受信機によって使用されて、パケットの源を認証するかもしれません。 信憑性を決定するためのテクニックがこのドキュメントの範囲の外にあります。 Key Present分野が1に設定される場合にだけ、Key分野は存在しています。

      Sequence Number (4 octets)

一連番号(4つの八重奏)

      The Sequence Number field contains an unsigned 32 bit integer
      which is inserted by the encapsulator.  It may be used by the
      receiver to establish the order in which packets have been
      transmitted from the encapsulator to the receiver.  The exact
      algorithms for the generation of the Sequence Number and the
      semantics of their reception is outside of the scope of this
      document.

Sequence Number分野はencapsulatorによって挿入される32ビットの未署名の整数を含んでいます。 それは受信機によって使用されます。パケットがencapsulatorから受信機まで伝えられたオーダーを確立するかもしれなくて、Sequence Numberの世代のための正確なアルゴリズムとそれらのレセプションの意味論がこのドキュメントの範囲の外にあります。

      Routing (variable)

ルート設定(可変)です。

      The Routing field is optional and is present only if the Routing
      Present bit is set to 1.

ルート設定Presentビットが1に設定される場合にだけ、ルート設定分野は、任意であり、存在しています。

Hanks, Li, Farinacci & Traina                                   [Page 4]

RFC 1701          Generic Routing Encapsulation (GRE)       October 1994

ハンクス、李、ファリナッチ、およびTraina[4ページ]RFC1701一般ルーティングのカプセル化(GRE)1994年10月

      The Routing field is a list of Source Route Entries (SREs).  Each
      SRE has the form:

ルート設定分野はSource Route Entries(SREs)のリストです。 各SREには、フォームがあります:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Address Family          |  SRE Offset   |  SRE Length   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Routing Information ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | アドレスファミリー| SREは相殺します。| SREの長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ルート設定情報… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The routing field is terminated with a "NULL" SRE containing an
   address family of type 0x0000 and a length of 0.

「ヌル」のSREがタイプ0x0000のアドレスファミリーと0の長さを含んでいて、ルーティング分野は終えられます。

   Address Family (2 octets)

アドレスファミリー(2つの八重奏)

   The Address Family field contains a two octet value which indicates
   the syntax and semantics of the Routing Information field.  The
   values for this field and the corresponding syntax and semantics for
   Routing Information are defined in other documents.

Address Family分野は経路情報分野の構文と意味論を示す2八重奏価値を含んでいます。 この分野と対応する構文のための値と経路情報のための意味論は他のドキュメントで定義されます。

   SRE Offset (1 octet)

SREは相殺します。(1つの八重奏)

   The SRE Offset field indicates the octet offset from the start of the
   Routing Information field to the first octet of the active entry in
   Source Route Entry to be examined.

SRE Offset分野は、八重奏が経路情報分野の始まりから最初の調べられるべきSource Route Entryにおける、活発なエントリーの八重奏まで相殺されたのを示します。

   SRE Length (1 octet)

SREの長さ(1つの八重奏)

   The SRE Length field contains the number of octets in the SRE.  If
   the SRE Length is 0, this indicates this is the last SRE in the
   Routing field.

SRE Length分野はSREの八重奏の数を含んでいます。 SRE Lengthが0歳であるなら、これは、ルート設定分野における最後のSREであることを示します。

   Routing Information (variable)

経路情報(可変)です。

   The Routing Information field contains data which may be used in
   routing this packet.  The exact semantics of this field is defined in
   other documents.

経路情報分野はこのパケットを発送する際に使用されるかもしれないデータを含んでいます。 この分野の正確な意味論は他のドキュメントで定義されます。

Forwarding of GRE packets

GREパケットの推進

   Normally, a system which is forwarding delivery layer packets will
   not differentiate GRE packets from other packets in any way.
   However, a GRE packet may be received by a system.  In this case, the
   system should use some delivery-specific means to determine that this
   is a GRE packet.  Once this is determined, the Key, Sequence Number
   and Checksum fields if they contain valid information as indicated by
   the corresponding flags may be checked.  If the Routing Present bit

通常、配送層のパケットを進めているシステムは他のパケットとGREパケットを何らかの方法で区別しないでしょう。 しかしながら、システムはGREパケットを受け取るかもしれません。 この場合、システムはこれがGREパケットであることを決定するいくつかの配送特有の手段を使用するはずです。 これによるKey、断固としていて、対応する旗で示されるように有効な情報を含んでいるならSequence NumberとChecksum分野がチェックされるかもしれないという一度、ことです。 ルート設定Presentが噛み付いたなら

Hanks, Li, Farinacci & Traina                                   [Page 5]

RFC 1701          Generic Routing Encapsulation (GRE)       October 1994

ハンクス、李、ファリナッチ、およびTraina[5ページ]RFC1701一般ルーティングのカプセル化(GRE)1994年10月

   is set to 1, then the Address Family field should be checked to
   determine the semantics and use of the SRE Length, SRE Offset and
   Routing Information fields.  The exact semantics for processing a SRE
   for each Address Family is defined in other documents.

1にはセットがあって、次に、Address Family分野は、SRE Length、SRE Offset、および経路情報分野の意味論と使用を決定するためにチェックされるべきです。 各Address FamilyのためにSREを処理するための正確な意味論は他のドキュメントで定義されます。

   Once all SREs have been processed, then the source route is complete,
   the GRE header should be removed, the payload's TTL MUST be
   decremented (if one exists) and the payload packet should be
   forwarded as a normal packet.  The exact forwarding method depends on
   the Protocol Type field.

次に、送信元経路が完全である、かつてのすべてのSREsを処理して、GREヘッダーを取り除くべきです、減少して(1つが存在しているなら)、ペイロードのTTL MUST。正常なパケットとしてペイロードパケットを進めるべきです。 正確な推進メソッドはプロトコルTypeフィールドによります。

Current List of Protocol Types

プロトコルの現在のリストはタイプされます。

   The following are currently assigned protocol types for GRE.  Future
   protocol types must be taken from DIX ethernet encoding.  For
   historical reasons, a number of other values have been used for some
   protocols.  The following table of values MUST be used to identify
   the following protocols:

以下は現在、GREのためにプロトコルタイプに割り当てられます。 DIXイーサネットコード化から将来のプロトコルタイプを取らなければなりません。 歴史的な理由で、他の多くの値がいくつかのプロトコルに使用されました。 以下のプロトコルを特定するのに値の以下のテーブルを使用しなければなりません:

       Protocol Family                     PTYPE
       ---------------                     -----
       Reserved                            0000
       SNA                                 0004
       OSI network layer                   00FE
       PUP                                 0200
       XNS                                 0600
       IP                                  0800
       Chaos                               0804
       RFC 826 ARP                         0806
       Frame Relay ARP                     0808
       VINES                               0BAD
       VINES Echo                          0BAE
       VINES Loopback                      0BAF
       DECnet (Phase IV)                   6003
       Transparent Ethernet Bridging       6558
       Raw Frame Relay                     6559
       Apollo Domain                       8019
       Ethertalk (Appletalk)               809B
       Novell IPX                          8137
       RFC 1144 TCP/IP compression         876B
       IP Autonomous Systems               876C
       Secure Data                         876D
       Reserved                            FFFF

プロトコルファミリーPTYPE--------------- ----- 0000年の予約されたSNA0004OSIネットワーク層00FE PUP0200XNS0600IP0800Chaos0804RFC826ARP0806Frame Relayアルプ0808バインズ0BADバインズEcho 0BAEバインズLoopback 0BAF DECnet(フェーズIV)6003TransparentイーサネットBridging6558Raw Frame Relay6559アポロDomain8019Ethertalk(Appletalk)809BノベルIPX8137RFC1144TCP/IP圧縮876B IP Autonomous Systems876C Secure Data 876D Reserved FFFF

   See the IANA list of Ether Types for the complete list of these
   values.

これらの値の全リストに関してEther TypesのIANAリストを見てください。

   URL = ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet-numbers.

URLは ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet-numbers と等しいです。

Hanks, Li, Farinacci & Traina                                   [Page 6]

RFC 1701          Generic Routing Encapsulation (GRE)       October 1994

ハンクス、李、ファリナッチ、およびTraina[6ページ]RFC1701一般ルーティングのカプセル化(GRE)1994年10月

References

参照

   RFC 1479
      Steenstrup, M. "Inter-Domain Policy Routing Protocol
      Specification: Version 1", RFC1479, BBN Systems and Technologies,
      July 1993.

RFC1479ステーンストルプ、M. 「相互ドメイン方針ルート設定は仕様を議定書の中で述べます」。 バージョン1インチとRFC1479とBBNシステムと技術、1993年7月。

   RFC 1226
      Kantor, B. "Internet Protocol Encapsulation of AX.25 Frames", RFC
      1226, University of California, San Diego, May 1991.

1226年のRFCカンター、B. 「斧.25のフレームのインターネットプロトコルカプセル化」、RFC1226、カリフォルニア大学、サンディエゴは1991がそうするかもしれません。

   RFC 1234
      Provan, D. "Tunneling IPX Traffic through IP Networks", RFC 1234,
      Novell, Inc., June 1991.

RFC1234Provan、D. 「IPネットワークを通したトンネリングIPXトラフィック」、RFC1234、ノベルInc.、1991年6月。

   RFC 1241
      Woodburn, R., and D. Mills, "Scheme for an Internet Encapsulation
      Protocol: Version 1", RFC 1241, SAIC, University of Delaware, July
      1991.

RFC1241Woodburn、R.、D.工場、「インターネットカプセル化の体系は以下について議定書の中で述べます」。 バージョン1インチ、RFC1241、SAIC、デラウエア大学、1991年7月。

   RFC 1326
      Tsuchiya, P., "Mutual Encapsulation Considered Dangerous", RFC
      1326, Bellcore, May 1992.

RFC1326Tsuchiya(P.、「危険であると考えられた互いのカプセル化」、RFC1326、Bellcore)は1992がそうするかもしれません。

   SDRP
      Estrin, D., Li, T., and Y. Rekhter, "Source Demand Routing
      Protocol Specification (Version 1)", Work in Progress.

D.、李、T.、およびY.Rekhter、「ソース要求ルート設定プロトコル仕様(バージョン1)」というSDRP Estrinは進行中で働いています。

   RFC 1702
      Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing
      Encapsulation over IPv4 networks", RFC 1702, NetSmiths, Ltd.,
      cisco Systems, October 1994.

RFC1702年のハンクスとS.と李とT.とファリナッチ、D.とP.Traina、「IPv4ネットワークの上のジェネリックルート設定Encapsulation」RFC1702、NetSmiths Ltd.、コクチマスSystems(1994年10月)。

Security Considerations

セキュリティ問題

   Security issues are not discussed in this memo.

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

Hanks, Li, Farinacci & Traina                                   [Page 7]

RFC 1701          Generic Routing Encapsulation (GRE)       October 1994

ハンクス、李、ファリナッチ、およびTraina[7ページ]RFC1701一般ルーティングのカプセル化(GRE)1994年10月

Acknowledgements

承認

   The authors would like to acknowledge Yakov Rekhter (IBM) and Deborah
   Estrin (USC) for their advice, encouragement and insightful comments.

作者は彼らのアドバイス、奨励、および洞察に満ちたコメントのために、ヤコフRekhter(IBM)とデボラEstrin(USC)を承認したがっています。

Authors'  Addresses

作者のアドレス

   Stan Hanks
   NetSmiths, Ltd.
   2025 Lincoln Highway
   Edison NJ, 08817

スタンハンクスNetSmiths Ltd.2025リンカーン・ハイウェイエディソン・ニュージャージー、08817

   EMail: stan@netsmiths.com

メール: stan@netsmiths.com

   Tony Li
   cisco Systems, Inc.
   1525 O'Brien Drive
   Menlo Park, CA 94025

トニー李コクチマスSystems Inc.1525オブライエン・Driveメンローパーク、カリフォルニア 94025

   EMail: tli@cisco.com

メール: tli@cisco.com

   Dino Farinacci
   cisco Systems, Inc.
   1525 O'Brien Drive
   Menlo Park, CA 94025

恐竜ファリナッチコクチマスSystems Inc.1525オブライエン・Driveメンローパーク、カリフォルニア 94025

   EMail: dino@cisco.com

メール: dino@cisco.com

   Paul Traina
   cisco Systems, Inc.
   1525 O'Brien Drive
   Menlo Park, CA 94025

ポールTrainaコクチマスSystems Inc.1525オブライエン・Driveメンローパーク、カリフォルニア 94025

   EMail: pst@cisco.com

メール: pst@cisco.com

Hanks, Li, Farinacci & Traina                                   [Page 8]

ハンクス、李、ファリナッチ、およびTraina[8ページ]