RFC2784 日本語訳

Network Working Group                                    D. Farinacci
Request for Comments: 2784                                      T. Li
Category: Standards Track                            Procket Networks
                                                             S. Hanks
                                                 Enron Communications
                                                             D. Meyer
                                                        Cisco Systems
                                                            P. Traina
                                                     Juniper Networks
                                                           March 2000

コメントを求めるワーキンググループD.ファリナッチの要求をネットワークでつないでください: 2784年のT.李カテゴリ: 標準化過程Procketは2000年3月にS.ハンクスエンロンコミュニケーションD.マイヤーシスコシステムズP.Traina杜松ネットワークをネットワークでつなぎます。

                  Generic Routing Encapsulation (GRE)

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

Status of this Memo

このMemoの状態

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Copyright(C)インターネット協会(2000)。 All rights reserved。

Abstract

要約

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

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

1.  Introduction

1. 序論

   A number of different proposals [RFC1234, RFC1226] currently exist
   for the encapsulation of one protocol over another protocol. Other
   types of encapsulations [RFC1241, RFC1479] 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
   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 reduces the
   problem of encapsulation from its current O(n^2) size to a more
   manageable size. This memo purposely does not address the issue of
   when a packet should be encapsulated.  This memo acknowledges, but
   does not address problems such as mutual encapsulation [RFC1326].

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

Farinacci, et al.           Standards Track                     [Page 1]

RFC 2784             Generic Routing Encapsulation            March 2000

ファリナッチ、他 規格は2000年の一般ルーティングのカプセル化行進のときにRFC2784を追跡します[1ページ]。

   In the most general case, a system has a packet that needs to be
   encapsulated and delivered to some destination.  We will call this
   the payload packet.  The payload is first encapsulated in a GRE
   packet.  The resulting GRE packet can then be encapsulated in some
   other protocol and then forwarded.  We will call this outer protocol
   the delivery protocol. The algorithms for processing this packet are
   discussed later.

最も一般的な場合では、システムはいくつかの送付先にカプセル化されて、提供される必要があるパケットを、持っています。 私たちは、これをペイロードパケットと呼ぶつもりです。 ペイロードは最初に、GREパケットでカプセル化されます。 次に、結果として起こるGREパケットをある他のプロトコルでカプセルに入れって、次に、進めることができます。 私たちは、この外側のプロトコルを配送プロトコルと呼ぶつもりです。 後でこのパケットを処理するためのアルゴリズムについて議論します。

   Finally this specification describes the intersection of GRE
   currently deployed by multiple vendors.

最終的にこの仕様は現在複数のベンダーによって配布されているGREの交差点について説明します。

   The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED,
   SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as defined
   in RFC 2119 [RFC2119].

キーワードが解釈しなければならない、RFC2119[RFC2119]で定義されるようにNOT、5月、OPTIONAL、REQUIRED、RECOMMENDED、SHALL、SHALL NOT、SHOULD、SHOULD NOTを解釈することになっていなければなりませんか?

2. Structure of a GRE Encapsulated Packet

2. パケットであるとカプセル化されたGREの構造

   A GRE encapsulated packet has the form:

パケットであるとカプセル化されたGREはフォームを持っています:

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

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

   This specification is generally concerned with the structure of the
   GRE header, although special consideration is given to some of the
   issues surrounding IPv4 payloads.

一般に、この仕様はGREヘッダーの構造に関係があります、IPv4ペイロードを囲む問題のいくつかに特別の配慮を与えますが。

2.1. GRE Header

2.1. GREヘッダー

   The GRE packet header has the form:

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

    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|       Reserved0       | Ver |         Protocol Type         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      Checksum (optional)      |       Reserved1 (Optional)    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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| Reserved0| Ver| プロトコルタイプ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | チェックサム(任意の)| Reserved1(任意の)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Farinacci, et al.           Standards Track                     [Page 2]

RFC 2784             Generic Routing Encapsulation            March 2000

ファリナッチ、他 規格は2000年の一般ルーティングのカプセル化行進のときにRFC2784を追跡します[2ページ]。

2.2. Checksum Present (bit 0)

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

   If the Checksum Present bit is set to one, then the Checksum and the
   Reserved1 fields are present and the Checksum field contains valid
   information. Note that a compliant implementation MUST accept and
   process this field.

Checksum Presentビットが1つに設定されるなら、ChecksumとReserved1分野は存在しています、そして、Checksum分野は有効な情報を含んでいます。 対応する実装がこの野原を受け入れて、処理しなければならないことに注意してください。

2.3. Reserved0 (bits 1-12)

2.3. Reserved0(ビット1-12)

   A receiver MUST discard a packet where any of bits 1-5 are non-zero,
   unless that receiver implements RFC 1701. Bits 6-12 are reserved for
   future use. These bits MUST be sent as zero and MUST be ignored on
   receipt.

その受信機が、RFCが1701であると実装しない場合、受信機はビット1-5のどれかが非ゼロであるところでパケットを捨てなければなりません。 ビット6-12は今後の使用のために予約されます。 これらのビットをゼロとして送らなければならなくて、領収書の上で無視しなければなりません。

2.3.1. Version Number (bits 13-15)

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

   The Version Number field MUST contain the value zero.

バージョンNumber分野は値ゼロを含まなければなりません。

2.4. Protocol Type (2 octets)

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

   The Protocol Type field contains the protocol type of the payload
   packet. These Protocol Types are defined in [RFC1700] as "ETHER
   TYPES" and in [ETYPES]. An implementation receiving a packet
   containing a Protocol Type which is not listed in [RFC1700] or
   [ETYPES] SHOULD discard the packet.

プロトコルType分野はペイロードパケットのプロトコルタイプを含んでいます。 これらのプロトコルTypesは「エーテルはタイプし」て[ETYPES]の[RFC1700]で定義されます。 [RFC1700]に記載されていないプロトコルTypeを含むパケットを受ける実装か[ETYPES]SHOULDがパケットを捨てます。

2.5. Checksum (2 octets)

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

   The Checksum field contains the IP (one's complement) checksum sum of
   the all the 16 bit words in the GRE header and the payload packet.
   For purposes of computing the checksum, the value of the checksum
   field is zero. This field is present only if the Checksum Present bit
   is set to one.

Checksum分野がIP(1の補数)チェックサム合計を含んでいる、すべての16がGREヘッダーとペイロードパケットで単語に噛み付きました。 チェックサムを計算する目的のために、チェックサム分野の値はゼロです。 Checksum Presentビットが1つに設定される場合にだけ、この分野は存在しています。

2.6. Reserved1 (2 octets)

2.6. Reserved1(2つの八重奏)

   The Reserved1 field is reserved for future use, and if present, MUST
   be transmitted as zero. The Reserved1 field is present only when the
   Checksum field is present (that is, Checksum Present bit is set to
   one).

Reserved1野原は今後の使用のために予約されます、そして、存在しているなら、ゼロとして伝えなければなりません。 Checksum分野が存在しているときだけ(すなわち、Checksum Presentビットは1つに設定されます)、Reserved1分野は存在しています。

3. IPv4 as a Payload

3. 有効搭載量としてのIPv4

   When IPv4 is being carried as the GRE payload, the Protocol Type
   field MUST be set to 0x800.

IPv4がGREペイロードとして運ばれるとき、プロトコルType分野を0×800に設定しなければなりません。

Farinacci, et al.           Standards Track                     [Page 3]

RFC 2784             Generic Routing Encapsulation            March 2000

ファリナッチ、他 規格は2000年の一般ルーティングのカプセル化行進のときにRFC2784を追跡します[3ページ]。

3.1. Forwarding Decapsulated IPv4 Payload Packets

3.1. 推進Decapsulated IPv4有効搭載量パケット

   When a tunnel endpoint decapsulates a GRE packet which has an IPv4
   packet as the payload, the destination address in the IPv4 payload
   packet header MUST be used to forward the packet and the TTL of the
   payload packet MUST be decremented. Care should be taken when
   forwarding such a packet, since if the destination address of the
   payload packet is the encapsulator of the packet (i.e., the other end
   of the tunnel), looping can occur. In this case, the packet MUST be
   discarded.

トンネル終点がペイロードとしてIPv4パケットを持っているGREパケットをdecapsulatesするとき、パケットを進めるのにIPv4ペイロードパケットのヘッダーの送付先アドレスを使用しなければなりません、そして、ペイロードパケットのTTLは減少しなければなりません。 そのようなパケットを進めるとき、注意するべきです、ループがペイロードパケットの送付先アドレスがパケット(すなわち、トンネルのもう一方の端)のencapsulatorであるなら、起こることができるので。 この場合、パケットを捨てなければなりません。

4. IPv4 as a Delivery Protocol

4. 配送プロトコルとしてのIPv4

   The IPv4 protocol 47 [RFC1700] is used when GRE packets are
   enapsulated in IPv4. See [RFC1122] for requirements relating to the
   delivery of packets over IPv4 networks.

GREパケットがIPv4でenapsulatedされるとき、IPv4プロトコル47[RFC1700]は使用されています。 IPv4ネットワークの上のパケットの配信に関連する要件に関して[RFC1122]を見てください。

5. Interoperation with RFC 1701 Compliant Implementations

5. RFC1701対応することの実装があるInteroperation

   In RFC 1701, the field described here as Reserved0 contained a number
   of flag bits which this specification deprecates. In particular, the
   Routing Present, Key Present, Sequence Number Present, and Strict
   Source Route bits have been deprecated, along with the Recursion
   Control field. As a result, the GRE header will never contain the
   Key, Sequence Number or Routing fields specified in RFC 1701.

RFC1701では、ここでReserved0と説明された分野はこの仕様が非難する多くのフラグビットを含みました。 ルート設定Present、Key Present、Sequence Number Present、およびStrict Source Routeビットは特に、推奨しないです、Recursion Control分野と共に。 その結果、GREヘッダーはRFC1701で指定されたKey、Sequence Numberまたはルート設定分野を決して含まないでしょう。

   There are, however, existing implementations of RFC 1701. The
   following sections describe correct interoperation with such
   implementations.

しかしながら、RFC1701の既存の実装があります。 以下のセクションはそのような実装で正しいinteroperationについて説明します。

5.1. RFC 1701 Compliant Receiver

5.1. RFC1701の言いなりになっている受信機

   An implementation complying to this specification will transmit the
   Reserved0 field set to zero. An RFC 1701 compliant receiver will
   interpret this as having the Routing Present, Key Present, Sequence
   Number Present, and Strict Source Route bits set to zero, and will
   not expect the RFC 1701 Key, Sequence Number or Routing fields to be
   present.

この仕様に応じる実装はReserved0分野セットをゼロに伝えるでしょう。 RFC1701対応することの受信機は、RFC1701Key、Sequence Numberまたはルート設定分野が現在であるとビットがゼロに設定するルート設定のPresent、Key Present、Sequence Number Present、およびStrict Source Routeを持っているとこれを解釈して、予想しないでしょう。

5.2. RFC 1701 Compliant Transmitter

5.2. RFC1701の言いなりになっている送信機

   An RFC 1701 transmitter may set any of the Routing Present, Key
   Present, Sequence Number Present, and Strict Source Route bits set to
   one, and thus may transmit the RFC 1701 Key, Sequence Number or
   Routing fields in the GRE header. As stated in Section 5.3, a packet
   with non-zero bits in any of bits 1-5 MUST be discarded unless the
   receiver implements RFC 1701.

1701年のRFC送信機がルート設定Presentのどれかを設定するかもしれなくて、Key Present、Sequence Number Present、およびStrict Source Routeビットは、1つにセットして、その結果、GREヘッダーでRFC1701Key、Sequence Numberまたはルート設定野原を伝えるかもしれません。 セクション5.3に述べられていて、受信機が、RFCが1701であると実装しない場合非ゼロ・ビットがビット1-5のどれかにあるパケットを捨てなければならないとき。

Farinacci, et al.           Standards Track                     [Page 4]

RFC 2784             Generic Routing Encapsulation            March 2000

ファリナッチ、他 規格は2000年の一般ルーティングのカプセル化行進のときにRFC2784を追跡します[4ページ]。

6. Security Considerations

6. セキュリティ問題

   Security in a network using GRE should be relatively similar to
   security in a normal IPv4 network, as routing using GRE follows the
   same routing that IPv4 uses natively. Route filtering will remain
   unchanged. However packet filtering requires either that a firewall
   look inside the GRE packet or that the filtering is done on the GRE
   tunnel endpoints. In those environments in which this is considered
   to be a security issue it may be desirable to terminate the tunnel at
   the firewall.

GREを使用するネットワークにおけるセキュリティは正常なIPv4ネットワークにおいてセキュリティと比較的同様であるべきです、GREを使用するルーティングがIPv4がネイティブに使用するのと同じルーティングに従うとき。 ルートフィルタリングは変わりがないでしょう。 しかしながら、パケットフィルタリングは、ファイアウォールがGREパケットの中で見るか、またはGREトンネル終点でフィルタリングをするのを必要とします。 これが安全保障問題であると考えられるそれらの環境で、ファイアウォールでトンネルを終えるのは望ましいかもしれません。

7. IANA Considerations

7. IANA問題

   This section considers the assignment of additional GRE Version
   Numbers and Protocol Types.

このセクションは追加GREバージョン民数記とプロトコルTypesの課題を考えます。

7.1.  GRE Version Numbers

7.1. GREバージョン番号

   This document specifies GRE version number 0. GRE version number 1 is
   used by PPTP [RFC2637]. Additional GRE version numbers are assigned
   by IETF Consensus as defined in RFC 2434 [RFC2434].

このドキュメントはGREバージョンNo.0を指定します。 GREバージョンNo.1はPPTP[RFC2637]によって使用されます。 追加GREバージョン番号はRFC2434[RFC2434]で定義されるようにIETF Consensusによって割り当てられます。

7.2.  Protocol Types

7.2. プロトコルタイプ

   GRE uses an ETHER Type for the Protocol Type. New ETHER TYPES are
   assigned by Xerox Systems Institute [RFC1700].

GREはプロトコルTypeにETHER Typeを使用します。 新しいETHER TYPESはゼロックスSystems Institute[RFC1700]によって割り当てられます。

8. Acknowledgments

8. 承認

   This document is derived from the original ideas of the authors of
   RFC 1701 and RFC 1702. Hitoshi Asaeda, Scott Bradner, Randy Bush,
   Brian Carpenter, Bill Fenner, Andy Malis, Thomas Narten, Dave Thaler,
   Tim Gleeson and others provided many constructive and insightful
   comments.

RFC1701とRFC1702の作者の着想からこのドキュメントを得ます。 等Asaeda、スコット・ブラドナー、ランディ・ブッシュ、ブライアンCarpenter、ビル・フェナー、アンディMalis、トーマスNarten、デーヴThaler、ティム・グリーソン、および他のものは多くの建設的で洞察に満ちたなコメントを提供しました。

Farinacci, et al.           Standards Track                     [Page 5]

RFC 2784             Generic Routing Encapsulation            March 2000

ファリナッチ、他 規格は2000年の一般ルーティングのカプセル化行進のときにRFC2784を追跡します[5ページ]。

9. Appendix -- Known Issues

9. 付録--知られている問題

   This document specifies the behavior of currently deployed GRE
   implementations. As such, it does not attempt to address the
   following known issues:

このドキュメントはGRE実装であると配布された現在の振舞いを指定します。 そういうものとして、以下の知られている問題を扱うのを試みません:

   o Interaction Path MTU Discovery (PMTU) [RFC1191]

o 相互作用経路MTU発見(PMTU)[RFC1191]

     Existing implementations of GRE, when using IPv4 as the Delivery
     Header, do not implement Path MTU discovery and do not set the
     Don't Fragment bit in the Delivery Header.  This can cause large
     packets to become fragmented within the tunnel and reassembled at
     the tunnel exit (independent of whether the payload packet is using
     PMTU).  If a tunnel entry point were to use Path MTU discovery,
     however, that tunnel entry point would also need to relay ICMP
     unreachable error messages (in particular the "fragmentation needed
     and DF set" code) back to the originator of the packet, which is
     not a requirement in this specification. Failure to properly relay
     Path MTU information to an originator can result in the following
     behavior: the originator sets the don't fragment bit, the packet
     gets dropped within the tunnel, but since the originator doesn't
     receive proper feedback, it retransmits with the same PMTU, causing
     subsequently transmitted packets to be dropped.

GREの既存の実装は、Delivery HeaderとしてIPv4を使用するとき、Path MTUが発見であると実装しないで、またDelivery Headerで噛み付かれたFragmentではなく、ドンを設定しません。 これによって、大きいパケットはトンネルの中で断片化されてトンネルの出口で組み立て直されるようになることができます(ペイロードパケットがPMTUを使用しているかどうかの如何にかかわらず)。 しかしながら、トンネルエントリー・ポイントがPath MTU発見を使用することであるなら、また、そのトンネルエントリー・ポイントは、ICMPの手の届かないエラーメッセージ(特に「必要である断片化とDFセット」コード)をパケットの生成元にリレーして戻す必要があります(この仕様で要件ではありません)。 適切にPath MTU情報を創始者にリレーしない場合、以下の振舞いをもたらすことができます: 創始者がセットする、同じPMTUと共にビットを断片化しないでください、創始者が適切なフィードバックを受けないのでパケットがトンネルの中で下げられるのを再送します、次に伝えられたパケットが下げられることを引き起こして。

   o IPv6 as Delivery and/or Payload Protocol

o 配送、そして/または、有効搭載量プロトコルとしてのIPv6

     This specification describes the intersection of GRE currently
     deployed by multiple vendors. IPv6 as delivery and/or payload
     protocol is not included in the currently deployed versions of GRE.

この仕様は現在複数のベンダーによって配布されているGREの交差点について説明します。 配送、そして/または、ペイロードプロトコルとしてのIPv6はGREの現在配布しているバージョンに含まれていません。

   o Interaction with ICMP

o ICMPとの相互作用

   o Interaction with the Differentiated Services Architecture

o 差別化されたサービスアーキテクチャとの相互作用

   o Multiple and Looping Encapsulations

o 複数の、そして、輪にしているカプセル化

10. REFERENCES

10. 参照

   [ETYPES]  ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet-
             numbers

[ETYPES] ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet- 番号

   [RFC1122] Braden, R., "Requirements for Internet hosts -
             communication layers", STD 3, RFC 1122, October 1989.

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

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

[RFC1191] ムガール人とJ.とS.デアリング、「経路MTU発見」、RFC1191、1990年11月。

Farinacci, et al.           Standards Track                     [Page 6]

RFC 2784             Generic Routing Encapsulation            March 2000

ファリナッチ、他 規格は2000年の一般ルーティングのカプセル化行進のときにRFC2784を追跡します[6ページ]。

   [RFC1226] Kantor, B., "Internet Protocol Encapsulation of AX.25
             Frames", RFC 1226, May 1991.

[RFC1226]カンター(B.、「斧.25のフレームのインターネットプロトコルカプセル化」、RFC1226)は1991がそうするかもしれません。

   [RFC1234] Provan, D., "Tunneling IPX Traffic through IP Networks",
             RFC 1234, June 1991.

[RFC1234] Provan、D.、「IPネットワークを通したトンネリングIPXトラフィック」、RFC1234、1991年6月。

   [RFC1241] Woodburn, R. and D. Mills, "Scheme for an Internet
             Encapsulation Protocol: Version 1", RFC 1241, July 1991.

[RFC1241]Woodburn、研究開発工場、「インターネットカプセル化の体系は以下について議定書の中で述べます」。 バージョン1インチ、RFC1241、1991年7月。

   [RFC1326] Tsuchiya, P., "Mutual Encapsulation Considered Dangerous",
             RFC 1326, May 1992.

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

   [RFC1479] Steenstrup, M., "Inter-Domain Policy Routing Protocol
             Specification: Version 1", RFC 1479, July 1993.

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

   [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC
             1700, October 1994.

[RFC1700] レイノルズとJ.とJ.ポステル、「規定番号」、STD2、RFC1700、1994年10月。

   [RFC1701] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic
             Routing Encapsulation", RFC 1701, October 1994.

[RFC1701] ハンクスとS.と李とT.とファリナッチとD.とP.Traina、「一般ルーティングのカプセル化」、RFC1701、1994年10月。

   [RFC1702] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic
             Routing Encapsulation over IPv4 networks", RFC 1702,
             October 1994.

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

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March, 1997.

[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [RFC2408] Maughan, D., Schertler, M., Schneider, M. and J.  Turner,
             "Internet Security Association and Key Management Protocol
             (ISAKMP)", RFC 2408, November 1998.

[RFC2408] Maughan、D.、Schertler、M.、シュナイダー、M.、およびJ.ターナー、「インターネットセキュリティ協会とKey Managementは(ISAKMP)について議定書の中で述べます」、RFC2408、1998年11月。

   [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
             IANA Considerations Section in RFCs", BCP 26, RFC 2434,
             October, 1998.

[RFC2434]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。

   [RFC2637] Hamzeh, K., et al., "Point-to-Point Tunneling Protocol
             (PPTP)", RFC 2637, July, 1999.

[RFC2637] Hamzeh、K.、他、「二地点間トンネリングプロトコル(PPTP)」、RFC2637、1999年7月。

Farinacci, et al.           Standards Track                     [Page 7]

RFC 2784             Generic Routing Encapsulation            March 2000

ファリナッチ、他 規格は2000年の一般ルーティングのカプセル化行進のときにRFC2784を追跡します[7ページ]。

11.  Authors' Addresses

11. 作者のアドレス

   Dino Farinacci
   Procket Networks
   3850 No. First St., Ste. C
   San Jose, CA 95134

ディーノファリナッチProcketは3850年のNo.をネットワークでつなぎます。 1番街、Ste。 Cサンノゼ、カリフォルニア 95134

   EMail: dino@procket.com

メール: dino@procket.com

   Tony Li
   Procket Networks
   3850 No. First St., Ste. C
   San Jose, CA 95134

トニー李Procketは3850年のNo.をネットワークでつなぎます。 1番街、Ste。 Cサンノゼ、カリフォルニア 95134

   Phone: +1 408 954 7903
   Fax:   +1 408 987 6166
   EMail: tony1@home.net

以下に電話をしてください。 +1 408 954、7903Fax: +1 6166年の408 987メール: tony1@home.net

   Stan Hanks
   Enron Communications

スタンハンクスエンロンコミュニケーション

   EMail: stan_hanks@enron.net

メール: stan_hanks@enron.net

   David Meyer
   Cisco Systems, Inc.
   170 Tasman Drive
   San Jose, CA, 95134

Driveサンノゼ、デヴィッドマイヤーシスコシステムズInc.170タスマン・カリフォルニア 95134

   EMail: dmm@cisco.com

メール: dmm@cisco.com

   Paul Traina
   Juniper Networks
   EMail: pst@juniper.net

ポールTraina杜松ネットワークはメールされます: pst@juniper.net

Farinacci, et al.           Standards Track                     [Page 8]

RFC 2784             Generic Routing Encapsulation            March 2000

ファリナッチ、他 規格は2000年の一般ルーティングのカプセル化行進のときにRFC2784を追跡します[8ページ]。

12.  Full Copyright Statement

12. 完全な著作権宣言文

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Copyright(C)インターネット協会(2000)。 All rights reserved。

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Farinacci, et al.           Standards Track                     [Page 9]

ファリナッチ、他 標準化過程[9ページ]