RFC4023 日本語訳

Network Working Group                                         T. Worster
Request for Comments: 4023                                Motorola, Inc.
Category: Standards Track                                     Y. Rekhter
                                                  Juniper Networks, Inc.
                                                           E. Rosen, Ed.
                                                     Cisco Systems, Inc.
                                                              March 2005

コメントを求めるワーキンググループT.オースターの要求をネットワークでつないでください: 4023年のモトローラカテゴリ: エド標準化過程Y.Rekhter杜松ネットワークInc.E.ローゼン、シスコシステムズInc.行進2005

    Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)

IPか一般ルーティングのカプセル化でMPLSをカプセル化します。(GRE)

Status of This 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 (2005).

Copyright(C)インターネット協会(2005)。

Abstract

要約

   Various applications of MPLS make use of label stacks with multiple
   entries.  In some cases, it is possible to replace the top label of
   the stack with an IP-based encapsulation, thereby enabling the
   application to run over networks that do not have MPLS enabled in
   their core routers.  This document specifies two IP-based
   encapsulations: MPLS-in-IP and MPLS-in-GRE (Generic Routing
   Encapsulation).  Each of these is applicable in some circumstances.

MPLSの様々なアプリケーションは多回入国があるラベルスタックを利用します。 いくつかの場合、スタックのトップラベルをIPベースのカプセル化に取り替えるのは可能です、その結果、アプリケーションが彼らのコアルータでMPLSを有効にさせないネットワークをひくのを可能にします。 このドキュメントは2つのIPベースのカプセル化を指定します: IPにおけるMPLSとGREのMPLS(一般ルーティングのカプセル化)。 それぞれのこれらはいくつかの事情で適切です。

Worster, et al.             Standards Track                     [Page 1]

RFC 4023            Encapsulating MPLS in IP or GRE           March 2005

オースター、他 2005年3月にIPかGREでMPLSをカプセル化する標準化過程[1ページ]RFC4023

Table of Contents

目次

   1.  Motivation  ..................................................  2
   2.  Specification of Requirements  ...............................  3
   3.  Encapsulation in IP  .........................................  3
   4.  Encapsulation in GRE  ........................................  4
   5.  Common Procedures  ...........................................  5
       5.1.  Preventing Fragmentation and Reassembly  ...............  5
       5.2.  TTL or Hop Limit  ......................................  6
       5.3.  Differentiated Services  ...............................  7
   6.  Applicability  ...............................................  7
   7.  IANA Considerations  .........................................  8
   8.  Security Considerations  .....................................  8
       8.1.  Securing the Tunnel with IPsec .........................  8
       8.2.  In the Absence of IPsec  ............................... 10
   9.  Acknowledgements ............................................. 11
   10. Normative References  ........................................ 11
   11. Informative References  ...................................... 12
   Authors' Addresses ............................................... 13
   Full Copyright Statement ......................................... 14

1. 動機… 2 2. 要件の仕様… 3 3. IPにおけるカプセル化… 3 4. GREのカプセル化… 4 5. 常法… 5 5.1. 断片化とReassemblyを防ぎます… 5 5.2. TTLかホップ限界… 6 5.3. サービスを差別化します… 7 6. 適用性… 7 7. IANA問題… 8 8. セキュリティ問題… 8 8.1. IPsecと共にトンネルを固定します… 8 8.2. IPsecが不在のとき… 10 9. 承認… 11 10. 標準の参照… 11 11. 有益な参照… 12人の作者のアドレス… 13 完全な著作権宣言文… 14

1.  Motivation

1. 動機

   In many applications of MPLS, packets traversing an MPLS backbone
   carry label stacks with more than one label.  As described in section
   3.15 of [RFC3031], each label represents a Label Switched Path (LSP).
   For each LSP, there is a Label Switching Router (LSR) that is the
   "LSP Ingress", and an LSR that is the "LSP Egress".  If LSRs A and B
   are the Ingress and Egress, respectively, of the LSP corresponding to
   a packet's top label, then A and B are adjacent LSRs on the LSP
   corresponding to the packet's second label (i.e., the label
   immediately beneath the top label).

MPLSの多くのアプリケーションでは、MPLSバックボーンを横断するパケットが1個以上のラベルでラベルスタックを運びます。 [RFC3031]のセクション3.15で説明されるように、各ラベルはLabel Switched Path(LSP)を表します。 各LSPのために、「LSPイングレス」であるLabel Switching Router(LSR)、および「LSP出口」であるLSRがあります。 LSRs AとBがそれぞれパケットのトップラベルに対応するLSPのIngressとEgressであるなら、AとBはパケットの2番目のラベル(すなわち、トップラベルのすぐ下のラベル)に対応するLSPの上の隣接しているLSRsです。

   The purpose (or one of the purposes) of the top label is to get the
   packet delivered from A to B, so that B can further process the
   packet based on the second label.  In this sense, the top label
   serves as an encapsulation header for the rest of the packet.  In
   some cases, other sorts of encapsulation headers can replace the top
   label without loss of functionality.  For example, an IP header or a
   Generic Routing Encapsulation (GRE) header could replace the top
   label.  As the encapsulated packet would still be an MPLS packet, the
   result is an MPLS-in-IP or MPLS-in-GRE encapsulation.

トップラベルの目的(または、目的の1つ)はパケットをAからBまで提供させることです、Bがさらに2番目のラベルに基づくパケットを処理できるように。 この意味で、トップラベルはパケットの残りのためのカプセル化ヘッダーとして機能します。 いくつかの場合、他の種類のカプセル化ヘッダーは機能性の損失なしでトップラベルを取り替えることができます。 例えば、IPヘッダーかGenericルート設定Encapsulation(GRE)ヘッダーがトップラベルを取り替えることができました。 カプセル化されたパケットはまだMPLSパケットでしょう、したがって、結果がIPにおけるMPLSかGREのMPLSカプセル化です。

   With these encapsulations, it is possible for two LSRs that are
   adjacent on an LSP to be separated by an IP network, even if that IP
   network does not provide MPLS.

これらのカプセル化では、2LSPで隣接しているLSRsに、IPネットワークによって切り離されるのは、可能です、そのIPネットワークがMPLSを提供しないでも。

Worster, et al.             Standards Track                     [Page 2]

RFC 4023            Encapsulating MPLS in IP or GRE           March 2005

オースター、他 2005年3月にIPかGREでMPLSをカプセル化する標準化過程[2ページ]RFC4023

   To use either of these encapsulations, the encapsulating LSR must
   know

これらのカプセル化、LSRが知らなければならない要約のどちらかを使用するために

      -  the IP address of the decapsulating LSR, and

- そしてdecapsulating LSRのIPアドレス。

      -  that the decapsulating LSR actually supports the particular
         encapsulation.

- decapsulating LSRは実際に特定のカプセル化をサポートします。

   This knowledge may be conveyed to the encapsulating LSR by manual
   configuration, or by means of some discovery protocol.  In
   particular, if the tunnel is being used to support a particular
   application and that application has a setup or discovery protocol,
   then the application's protocol may convey this knowledge.  The means
   of conveying this knowledge is outside the scope of the this
   document.

この知識は手動の構成、または何らかの発見プロトコルによって要約のLSRに伝えられるかもしれません。 トンネルが特定用途をサポートするのに使用されていて、そのアプリケーションにセットアップか発見プロトコルがあるなら、特に、アプリケーションのプロトコルはこの知識を伝えるかもしれません。 範囲の外にこの知識を伝える手段がある、このドキュメント。

2.  Specification of Requirements

2. 要件の仕様

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" are to be interpreted as described in [RFC2119].

本書では、キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように解釈されることであるべきですか?

3.  Encapsulation in IP

3. IPにおけるカプセル化

   MPLS-in-IP messages have the following format:

IPにおけるMPLSメッセージには、以下の形式があります:

             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             |                                     |
             |             IP Header               |
             |                                     |
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             |                                     |
             |          MPLS Label Stack           |
             |                                     |
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             |                                     |
             |            Message Body             |
             |                                     |
             +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPヘッダー| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | MPLSラベルスタック| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | メッセージ本体| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         IP Header
             This field contains an IPv4 or an IPv6 datagram header
             as defined in [RFC791] or [RFC2460], respectively.  The
             source and destination addresses are set to addresses
             of the encapsulating and decapsulating LSRs, respectively.

IP Header This分野は[RFC791]か[RFC2460]でそれぞれ定義されるようにIPv4かIPv6データグラムヘッダーを含んでいます。 ソースと送付先アドレスはそれぞれ要約とdecapsulating LSRsのアドレスに用意ができています。

Worster, et al.             Standards Track                     [Page 3]

RFC 4023            Encapsulating MPLS in IP or GRE           March 2005

オースター、他 2005年3月にIPかGREでMPLSをカプセル化する標準化過程[3ページ]RFC4023

         MPLS Label Stack
             This field contains an MPLS Label Stack as defined in
             [RFC3032].

MPLS Label Stack This分野は[RFC3032]で定義されるようにMPLS Label Stackを含んでいます。

         Message Body
             This field contains one MPLS message body.

メッセージBody This分野は1つのMPLSメッセージボディーを含んでいます。

   The IPv4 Protocol Number field or the IPv6 Next Header field is set
   to 137, indicating an MPLS unicast packet.  (The use of the MPLS-in-
   IP encapsulation for MPLS multicast packets is not supported by this
   specification.)

MPLSユニキャストパケットを示して、IPv4プロトコルNumber分野かIPv6 Next Header分野が137に設定されます。 (MPLSマルチキャストパケットのためのカプセル化がこの仕様でサポートされない中のMPLS IPの使用。)

   Following the IP header is an MPLS packet, as specified in [RFC3032].
   This encapsulation causes MPLS packets to be sent through "IP
   tunnels".  When the tunnel's receive endpoint receives a packet, it
   decapsulates the MPLS packet by removing the IP header.  The packet
   is then processed as a received MPLS packet whose "incoming label"
   [RFC3031] is the topmost label of the decapsulated packet.

IPヘッダーに続くのは、[RFC3032]で指定されるようにMPLSパケットです。 このカプセル化で、「IPトンネル」を通してMPLSパケットを送ります。 トンネルのものが受信されるとき、終点はパケットを受けて、それは、IPヘッダーを取り除くことによって、MPLSパケットをdecapsulatesします。 そして、パケットは「入って来るラベル」[RFC3031]がdecapsulatedパケットの最上のラベルである容認されたMPLSパケットとして処理されます。

4.  Encapsulation in GRE

4. GREのカプセル化

   The MPLS-in-GRE encapsulation encapsulates an MPLS packet in GRE
   [RFC2784].  The packet then consists of an IP header (either IPv4 or
   IPv6), followed by a GRE header, followed by an MPLS label stack as
   specified in [RFC3032].  The protocol type field in the GRE header
   MUST be set to the Ethertype value for MPLS Unicast (0x8847) or
   Multicast (0x8848).

GREのMPLSカプセル化はGRE[RFC2784]でMPLSパケットをカプセルに入れります。 そして、パケットはGREヘッダーによって後をつけられた(IPv4かIPv6のどちらか)が[RFC3032]での指定されるとしてのMPLSラベルスタックを続けたIPヘッダーから成ります。 MPLS Unicast(0×8847)かMulticast(0×8848)のためのEthertype値にGREヘッダーのプロトコルタイプ分野を設定しなければなりません。

   This encapsulation causes MPLS packets to be sent through "GRE
   tunnels".  When the tunnel's receive endpoint receives a packet, it
   decapsulates the MPLS packet by removing the IP and the GRE headers.
   The packet is then processed as a received MPLS packet whose
   "incoming label" [RFC3031] is the topmost label of the decapsulated
   packet.

このカプセル化で、「GREトンネル」を通してMPLSパケットを送ります。 トンネルのものが受信されるとき、終点はパケットを受けて、それは、IPとGREヘッダーを取り除くことによって、MPLSパケットをdecapsulatesします。 そして、パケットは「入って来るラベル」[RFC3031]がdecapsulatedパケットの最上のラベルである容認されたMPLSパケットとして処理されます。

   [RFC2784] specifies an optional GRE checksum, and [RFC2890] specifies
   optional GRE key and sequence number fields.  These optional fields
   are not very useful for the MPLS-in-GRE encapsulation.  The sequence
   number and checksum fields are not needed, as there are no
   corresponding fields in the native MPLS packets being tunneled.  The
   GRE key field is not needed for demultiplexing, as the top MPLS label
   of the encapsulated packet is used for that purpose.  The GRE key
   field is sometimes considered a security feature, functioning as a
   32-bit cleartext password, but this is an extremely weak form of
   security.  In order (a) to facilitate high-speed implementations of
   the encapsulation/decapsulation procedures and (b) to ensure
   interoperability, we require that all implementations be able to
   operate correctly without these optional fields.

[RFC2784]は任意のGREチェックサムを指定します、そして、[RFC2890]は任意のGREキーと一連番号分野を指定します。 これらの任意の分野はそれほどGREのMPLSカプセル化の役に立ちません。 一連番号とチェックサム分野は必要ではありません、どんな対応する分野もトンネルを堀られるネイティブのMPLSパケットにないとき。 GREキーフィールドは逆多重化に必要ではありません、MPLSがラベルするカプセル化されたパケットの先端がそのために使用されるとき。 32ビットのcleartextパスワードとして機能して、GREキーフィールドはセキュリティ機能であると時々考えられますが、これは非常に弱いフォームのセキュリティです。 相互運用性を確実にするためにカプセル化/被膜剥離術手順と(b)の高速実装を容易にする命令(a)では、私たちは、すべての実装がこれらの任意の分野なしで正しく作動できるのを必要とします。

Worster, et al.             Standards Track                     [Page 4]

RFC 4023            Encapsulating MPLS in IP or GRE           March 2005

オースター、他 2005年3月にIPかGREでMPLSをカプセル化する標準化過程[4ページ]RFC4023

   More precisely, an implementation of an MPLS-in-GRE decapsulator MUST
   be able to process packets correctly without these optional fields.
   It MAY be able to process packets correctly with these optional
   fields.

より正確に、GRE decapsulatorのMPLSの実装はこれらの任意の分野なしでパケットを正しく処理できなければなりません。 それはこれらの任意の分野で正しくパケットを処理できるかもしれません。

   An implementation of an MPLS-in-GRE encapsulator MUST be able to
   generate packets without these optional fields.  It MAY have the
   capability to generate packets with these fields, but the default
   state MUST be that packets are generated without these fields.  The
   encapsulator MUST NOT include any of these optional fields unless it
   is known that the decapsulator can process them correctly.  Methods
   for conveying this knowledge are outside the scope of this
   specification.

GRE encapsulatorのMPLSの実装はこれらの任意の分野なしでパケットを生成することができなければなりません。 それには、これらの分野でパケットを生成する能力があるかもしれませんが、デフォルト状態はパケットがこれらの分野なしで生成されるということであるに違いありません。 decapsulatorが正しくそれらを処理できるのが知られていない場合、encapsulatorはこれらの任意の分野のいずれも含んではいけません。 この仕様の範囲の外にこの知識を伝えるためのメソッドがあります。

5.  Common Procedures

5. 常法

   Certain procedures are common to both the MPLS-in-IP and the MPLS-
   in-GRE encapsulations.  In the following, the encapsulator, whose
   address appears in the IP source address field of the encapsulating
   IP header, is known as the "tunnel head".  The decapsulator, whose
   address appears in the IP destination address field of the
   decapsulating IP header, is known as the "tunnel tail".

ある手順はIPにおけるMPLSとGREのMPLSカプセル化の両方に共通です。 以下では、encapsulator(アドレスは要約のIPヘッダーのIPソースアドレス・フィールドに現れる)は「トンネルヘッド」として知られています。 decapsulator(アドレスはdecapsulating IPヘッダーの受信者IPアドレス分野に現れる)は「トンネルテール」として知られています。

   If IPv6 is being used (for either MPLS-in-IPv6 or MPLS-in-GRE-in-
   IPv6), the procedures of [RFC2473] are generally applicable.

IPv6が使用されているなら(IPv6のMPLSか中の中のMPLS GRE IPv6のどちらかのために)、一般に、[RFC2473]の手順は適切です。

5.1.  Preventing Fragmentation and Reassembly

5.1. 断片化とReassemblyを防ぎます。

   If an MPLS-in-IP or MPLS-in-GRE packet were fragmented (due to
   "ordinary" IP fragmentation), the tunnel tail would have to
   reassemble it before the contained MPLS packet could be decapsulated.
   When the tunnel tail is a router, this is likely to be undesirable;
   the tunnel tail may not have the ability or the resources to perform
   reassembly at the necessary level of performance.

IPにおけるMPLSかGREのMPLSパケットが断片化されるなら(「普通」のIP断片化のため)、含まれたMPLSパケットをdecapsulatedされることができる前にトンネルテールはそれを組み立て直さなければならないでしょうに。 トンネルテールがルータであるときに、これは望ましくない傾向があります。 トンネルテールには、必要な技量で再アセンブリに実行する能力かリソースがないかもしれません。

   Whether fragmentation of the tunneled packets is allowed MUST be
   configurable at the tunnel head.  The default value MUST be that
   packets are not fragmented.  The default value would only be changed
   if it were known that the tunnel tail could perform the reassembly
   function adequately.

トンネルを堀られたパケットの断片化が許されているかどうかが、トンネルヘッドで構成可能であるに違いありません。 デフォルト値はパケットが断片化されないということであるに違いありません。 トンネルテールが適切に再アセンブリ機能を実行するかもしれないのを知っている場合にだけ、デフォルト値を変えるでしょうに。

   THE PROCEDURES SPECIFIED IN THE REMAINDER OF THIS SECTION ONLY APPLY
   IF PACKETS ARE NOT TO BE FRAGMENTED.

パケットが断片化されないつもりである場合にだけ、このセクションの残りで指定された手順は適用されます。

   Obviously, if packets are not to be fragmented, the tunnel head MUST
   NOT fragment a packet before encapsulating it.

明らかに、パケットが断片化されないつもりであるなら、それをカプセル化する前に、トンネルヘッドはパケットを断片化してはいけません。

Worster, et al.             Standards Track                     [Page 5]

RFC 4023            Encapsulating MPLS in IP or GRE           March 2005

オースター、他 2005年3月にIPかGREでMPLSをカプセル化する標準化過程[5ページ]RFC4023

   If IPv4 is used, then the tunnel MUST set the DF bit.  This prevents
   intermediate nodes in the tunnel from performing fragmentation.  (If
   IPv6 is used, intermediate nodes do not perform fragmentation in any
   event.)

IPv4が使用されているなら、トンネルはDFビットを設定しなければなりません。 これは、トンネルの中間的ノードが断片化を実行するのを防ぎます。 (IPv6が使用されているなら、中間的ノードはとにかく断片化を実行しません。)

   The tunnel head SHOULD perform Path MTU Discovery ([RFC1191] for
   IPv4, or [RFC1981] for IPv6).

トンネルヘッドSHOULDはPath MTUディスカバリー(IPv4のための[RFC1191]、またはIPv6のための[RFC1981])を実行します。

   The tunnel head MUST maintain a "Tunnel MTU" for each tunnel; this is
   the minimum of (a) an administratively configured value, and, if
   known, (b) the discovered Path MTU value minus the encapsulation
   overhead.

トンネルヘッドは「トンネルMTU」を各トンネルに維持しなければなりません。 これは頭上の(a) 行政上構成された値、および知られているときの発見されたPath MTUがカプセル化を引いて評価する(b)の最小限です。

   If the tunnel head receives, for encapsulation, an MPLS packet whose
   size exceeds the Tunnel MTU, that packet MUST be discarded.  However,
   silently dropping such packets may cause significant operational
   problems; the originator of the packets will notice that his data is
   not getting through, but he may not realize that large packets are
   causing packet loss.  He may therefore continue sending packets that
   are discarded.  Path MTU discovery can help (if the tunnel head sends
   back ICMP errors), but frequently there is insufficient information
   available at the tunnel head to identify the originating sender
   properly.  To minimize problems, it is advised that MTUs be
   engineered to be large enough in practice to avoid fragmentation.

トンネルヘッドがカプセル化のために、サイズがTunnel MTUを超えているMPLSパケットを受けるなら、そのパケットを捨てなければなりません。 しかしながら、静かにそのようなパケットを下げると、重要な運転上の問題は引き起こされるかもしれません。 パケットの生成元は、彼のデータが通っていないのに気付くでしょうが、彼は、大きいパケットがパケット損失を引き起こしているとわからないかもしれません。 したがって、彼は、捨てられたパケットを送り続けるかもしれません。 経路MTU探索は助けることができますが(トンネルヘッドが逆ICMP誤りを送るなら)、適切に起因している送付者を特定するトンネルヘッドで利用可能な不十分な情報が頻繁にあります。 問題を最小にするために、MTUsが断片化を避ける習慣で十分大きくなるように設計されると忠告されます。

   In some cases, the tunnel head receives, for encapsulation, an IP
   packet, which it first encapsulates in MPLS and then encapsulates in
   MPLS-in-IP or MPLS-in-GRE.  If the source of the IP packet is
   reachable from the tunnel head, and if the result of encapsulating
   the packet in MPLS would be a packet whose size exceeds the Tunnel
   MTU, then the value that the tunnel head SHOULD use for fragmentation
   and PMTU discovery outside the tunnel is the Tunnel MTU value minus
   the size of the MPLS encapsulation.  (That is, the Tunnel MTU value
   minus the size of the MPLS encapsulation is the MTU that is to be
   reported in ICMP messages.)  The packet will have to be discarded,
   but the tunnel head should send the IP source of the discarded packet
   the proper ICMP error message as specified in [RFC1191] or [RFC1981].

いくつかの場合、トンネルヘッドは、カプセル化のために、IPパケットを受けて、次に、IPにおけるMPLSかGREのMPLSで要約します。(それは最初に、MPLSでパケットをカプセルに入れります)。 IPパケットの源がトンネルヘッドから届いて、MPLSでパケットをカプセルに入れるという結果がサイズがTunnel MTUを超えているパケットであるなら、トンネルヘッドSHOULDが断片化とPMTU発見にトンネルの外で使用する値はMPLSカプセル化のサイズを引いたTunnel MTU値です。 (すなわち、MPLSカプセル化のサイズを引いたTunnel MTU値はICMPメッセージで報告されることになっているMTUです。) パケットは捨てられなければならないでしょうが、トンネルヘッドは[RFC1191]か[RFC1981]の指定されるとしての適切なICMPエラーメッセージを捨てられたパケットのIP源に送るべきです。

5.2.  TTL or Hop Limit

5.2. TTLかホップ限界

   The tunnel head MAY place the TTL from the MPLS label stack into the
   TTL field of the encapsulating IPv4 header or the Hop Limit field of
   the encapsulating IPv6 header.  The tunnel tail MAY place the TTL
   from the encapsulating IPv4 header or the Hop Limit from the
   encapsulating IPv6 header into the TTL field of the MPLS header, but
   only if this does not increase the TTL value in the MPLS header.

トンネルヘッドはTTLをMPLSラベルスタックから要約のIPv4ヘッダーのTTL分野か要約のIPv6ヘッダーのHop Limit分野に置くかもしれません。 これがMPLSヘッダーでTTL値を増強しない場合にだけ、トンネルテールはTTLを要約のIPv4ヘッダーかHop Limitから要約のIPv6ヘッダーからMPLSヘッダーのTTL分野に置くかもしれません。

Worster, et al.             Standards Track                     [Page 6]

RFC 4023            Encapsulating MPLS in IP or GRE           March 2005

オースター、他 2005年3月にIPかGREでMPLSをカプセル化する標準化過程[6ページ]RFC4023

   Whether such modifications are made, and the details of how they are
   made, will depend on the configuration of the tunnel tail and the
   tunnel head.

そのような変更をするか、そして、それらがどう作られているかに関する詳細はトンネルテールとトンネルヘッドの構成に依存するでしょう。

5.3.  Differentiated Services

5.3. 差別化されたサービス

   The procedures specified in this document enable an LSP to be sent
   through an IP or GRE tunnel.  [RFC2983] details a number of
   considerations and procedures that have to be applied to support the
   Differentiated Services Architecture properly in the presence of IP-
   in-IP tunnels.  These considerations and procedures also apply in the
   presence of MPLS-in-IP or MPLS-in-GRE tunnels.

本書では指定された手順は、LSPがIPかGREトンネルを通して送られるのを可能にします。 [RFC2983]はIPにおけるIPトンネルがあるとき適切にDifferentiated Services Architectureをサポートするために適用されなければならない多くの問題と手順を詳しく述べます。 また、これらの問題と手順はIPにおけるMPLSかGREのMPLSトンネルがあるとき適用されます。

   Accordingly, when a tunnel head is about to send an MPLS packet into
   an MPLS-in-IP or MPLS-in-GRE tunnel, the setting of the DS field of
   the encapsulating IPv4 or IPv6 header MAY be determined (at least
   partially) by the "Behavior Aggregate" of the MPLS packet.
   Procedures for determining the Behavior Aggregate of an MPLS packet
   are specified in [RFC3270].

トンネルヘッドがIPにおけるMPLSかGREのMPLSトンネルにMPLSパケットを送ろうとしているとき、それに従って、要約IPv4かIPv6ヘッダーのDS分野の設定はMPLSパケットの「振舞い集合」で決定しているかもしれません(少なくとも部分的に)。 MPLSパケットのBehavior Aggregateを決定するための手順は[RFC3270]で指定されます。

   Similarly, at the tunnel tail, the DS field of the encapsulating IPv4
   or IPv6 header MAY be used to determine the Behavior Aggregate of the
   encapsulated MPLS packet. [RFC3270] specifies the relation between
   the Behavior Aggregate and the subsequent disposition of the packet.

同様に、トンネルテールでは、要約IPv4かIPv6ヘッダーのDS分野は、カプセル化されたMPLSパケットのBehavior Aggregateを決定するのに使用されるかもしれません。 [RFC3270]はパケットのBehavior Aggregateとその後の気質との関係を指定します。

6.  Applicability

6. 適用性

   The MPLS-in-IP encapsulation is the more efficient, and it would
   generally be regarded as preferable, other things being equal.  There
   are, however, some situations in which the MPLS-in-GRE encapsulation
   may be used:

IPにおけるMPLSカプセル化は、より効率的です、そして、一般に、他のものが等しくて、それは望ましいと見なされるでしょう。 しかしながら、GREのMPLSカプセル化が使用されるかもしれないいくつかの状況があります:

      -  Two routers are "adjacent" over a GRE tunnel that exists for
         some reason that is outside the scope of this document, and
         those two routers have to send MPLS packets over that
         adjacency.  As all packets sent over this adjacency must have a
         GRE encapsulation, the MPLS-in-GRE encapsulation is more
         efficient than the alternative, that would be an MPLS-in-IP
         encapsulation which is then encapsulated in GRE.

- 2つのルータがこのドキュメントの範囲の外にある何らかの理由で存在するGREトンネルの上で「隣接しています」、そして、それらの2つのルータがその隣接番組の上でパケットをMPLSに送らなければなりません。 この隣接番組の上に送られたすべてのパケットがGREカプセル化を持たなければならないので、GREのMPLSカプセル化が代替手段より効率的である、それは次にGREでカプセル化されるIPにおけるMPLSカプセル化でしょう。

      -  Implementation considerations may dictate the use of MPLS-in-
         GRE.  For example, some hardware device might only be able to
         handle GRE encapsulations in its fastpath.

- 実装問題は中のMPLS GREの使用を決めるかもしれません。 例えば、いくらかのハードウェアデバイスがfastpathでGREカプセル化を扱うことができるだけであるかもしれません。

Worster, et al.             Standards Track                     [Page 7]

RFC 4023            Encapsulating MPLS in IP or GRE           March 2005

オースター、他 2005年3月にIPかGREでMPLSをカプセル化する標準化過程[7ページ]RFC4023

7.  IANA Considerations

7. IANA問題

   The IANA has allocated IP Protocol Number 137 for MPLS-in-IP
   encapsulation, as described in section 3.  No future IANA actions
   will be required.  The MPLS-in-GRE encapsulation does not require any
   IANA action.

IANAはIPにおけるMPLSカプセル化のためにセクション3で説明されるようにIPプロトコルNumber137を割り当てました。 どんな今後のIANA動作も必要でないでしょう。 GREのMPLSカプセル化は少しのIANA動作も必要としません。

8.  Security Considerations

8. セキュリティ問題

   The main security problem faced when IP or GRE tunnels are used is
   the possibility that the tunnel's receive endpoint will get a packet
   that appears to be from the tunnel, but that was not actually put
   into the tunnel by the tunnel's transmit endpoint.  (The specified
   encapsulations do not by themselves enable the decapsulator to
   authenticate the encapsulator.)  A second problem is the possibility
   that the packet will be altered between the time it enters the tunnel
   and the time it leaves. (The specified encapsulations do not by
   themselves assure the decapsulator of the packet's integrity.)  A
   third problem is the possibility that the packet's contents will be
   seen while the packet is in transit through the tunnel.  (The
   specification encapsulations do not ensure privacy.)  How significant
   these issues are in practice depends on the security requirements of
   the applications whose traffic is being sent through the tunnel.  For
   example, lack of privacy for tunneled packets is not a significant
   issue if the applications generating the packets do not require
   privacy.

IPかGREトンネルによる使用されているのが、トンネルのものが受信される可能性であるということであるときに、面されていて、現れるパケットが終点でトンネルから来ていることにおける実際に置かれないで、トンネルのもののそばのトンネルに、終点が送られているということであった主な警備上の問題。 (指定されたカプセル化は、decapsulatorがencapsulatorを認証するのを自分たちで可能にしません。) 2番目の問題はパケットがそれがトンネルに入る時、残っている時の間で変更される可能性です。 (指定されたカプセル化は自分たちでパケットの保全をdecapsulatorに保証しません。) 3番目の問題はパケットがトンネルを通るトランジット中である間パケットのコンテンツが見られる可能性です。 (仕様カプセル化は秘密を守りません。) これらの問題が実際にはどれくらい重要であるかはトラフィックがトンネルを通して送られるアプリケーションのセキュリティ要件によります。 例えば、パケットを生成するアプリケーションがプライバシーを必要としないなら、トンネルを堀られたパケットのためのプライバシーの欠如は重要な問題ではありません。

   Because of the different potential security requirements, deployment
   scenarios, and performance considerations of different applications
   using the described encapsulation mechanism, this specification
   defines IPsec support as OPTIONAL.  Basic implementation requirements
   if IPsec is implemented are described in section 8.1.  If IPsec is
   not implemented, additional mechanisms may have to be implemented and
   deployed.  Those are discussed in section 8.2.

説明されたカプセル化メカニズムを使用する異なったアプリケーションの異なった潜在的セキュリティ要件、展開シナリオ、および性能問題のために、この仕様はIPsecサポートをOPTIONALと定義します。 IPsecが実装されるなら、基本の実装要件はセクション8.1で説明されます。 IPsecが実装されないなら、追加メカニズムは、実装されて、配布されなければならないかもしれません。 セクション8.2でものについて議論します。

8.1.  Securing the Tunnel with IPsec

8.1. IPsecと共にトンネルを固定します。

   All of these security issues can be avoided if the MPLS-in-IP or
   MPLS-in-GRE tunnels are secured with IPsec.  Implementation
   requirements defined in this section apply if IPsec is implemented.

IPにおけるMPLSかGREのMPLSトンネルがIPsecと共に固定されているなら、これらの安全保障問題のすべてを避けることができます。 IPsecが実装されるなら、このセクションで定義された実装要件は適用されます。

   When IPsec is used, the tunnel head and the tunnel tail should be
   treated as the endpoints of a Security Association.  For this
   purpose, a single IP address of the tunnel head will be used as the
   source IP address, and a single IP address of the tunnel tail will be
   used as the destination IP address.  The means by which each node
   knows the proper address of the other is outside the scope of this
   document.  If a control protocol is used to set up the tunnels (e.g.,

IPsecが使用されているとき、トンネルヘッドとトンネルテールはSecurity Associationの終点として扱われるべきです。 このために、トンネルヘッドのただ一つのIPアドレスはソースIPアドレスとして使用されるでしょう、そして、トンネルテールのただ一つのIPアドレスは送付先IPアドレスとして使用されるでしょう。 このドキュメントの範囲の外に各ノードがもう片方の適切なアドレスを知っている手段があります。 制御プロトコルがトンネルを設立するのに使用される、(例えば。

Worster, et al.             Standards Track                     [Page 8]

RFC 4023            Encapsulating MPLS in IP or GRE           March 2005

オースター、他 2005年3月にIPかGREでMPLSをカプセル化する標準化過程[8ページ]RFC4023

   to inform one tunnel endpoint of the IP address of the other), the
   control protocol MUST have an authentication mechanism, and this MUST
   be used when the tunnel is set up.  If the tunnel is set up
   automatically as the result of, for example, information distributed
   by BGP, then the use of BGP's MD5-based authentication mechanism is
   satisfactory.

もう片方のIPアドレスの1つのトンネル終点を知らせる、)、制御プロトコルには、認証機構がなければならなくて、トンネルが設立されるとき、これを使用しなければなりません。 トンネルが例えばBGPによって分配された情報の結果として自動的に設立されるなら、BGPのMD5ベースの認証機構の使用は満足できます。

   The MPLS-in-IP or MPLS-in-GRE encapsulated packets should be viewed
   as originating at the tunnel head and as being destined for the
   tunnel tail; IPsec transport mode SHOULD thus be used.

トンネルヘッドで起因することとしてトンネルテールのために運命づけられることとしてパケットであるとカプセル化されたIPにおけるMPLSかGREのMPLSが見なされるべきです。 IPsecはモードSHOULDを輸送します、その結果、使用されてください。

   The IP header of the MPLS-in-IP packet becomes the outer IP header of
   the resulting packet when the tunnel head uses IPsec transport mode
   to secure the MPLS-in-IP packet.  This is followed by an IPsec
   header, followed by the MPLS label stack.  The IPsec header has to
   set the payload type to MPLS by using the IP protocol number
   specified in section 3.  If IPsec transport mode is applied on a
   MPLS-in-GRE packet, the GRE header follows the IPsec header.

トンネルヘッドがIPにおけるMPLSパケットを機密保護するのにIPsec交通機関を使用すると、IPにおけるMPLSパケットのIPヘッダーは結果として起こるパケットの外側のIPヘッダーになります。 これはMPLSラベルスタックが支えたIPsecヘッダーによって後をつけられています。 IPsecヘッダーは、セクション3で指定されたIPプロトコル番号を使用することによって、ペイロードタイプをMPLSに設定しなければなりません。 IPsec交通機関がGREのMPLSパケットで適用されるなら、GREヘッダーはIPsecヘッダーについて来ます。

   At the tunnel tail, IPsec outbound processing recovers the contained
   MPLS-in-IP/GRE packet.  The tunnel tail then strips off the
   encapsulating IP/GRE header to recover the MPLS packet, which is then
   forwarded according to its label stack.

トンネルテールでは、IPsecの外国行きの処理はIPにおける含まれたMPLS/GREパケットを回復します。 そして、トンネルテールは、MPLSパケットを回復するために要約IP/GREヘッダーを全部はぎ取ります。(次に、ラベルスタックに応じて、パケットは進められます)。

   Note that the tunnel tail and the tunnel head are LSP adjacencies,
   which means that the topmost label of any packet sent through the
   tunnel must be one that was distributed by the tunnel tail to the
   tunnel head.  The tunnel tail MUST know precisely which labels it has
   distributed to the tunnel heads of IPsec-secured tunnels.  Labels in
   this set MUST NOT be distributed by the tunnel tail to any LSP
   adjacencies other than those that are tunnel heads of IPsec-secured
   tunnels.  If an MPLS packet is received without an IPsec
   encapsulation, and if its topmost label is in this set, then the
   packet MUST be discarded.

トンネルテールとトンネルヘッドがLSP隣接番組であることに注意してください(トンネルを通して送られたどんなパケットの最上のラベルもトンネルテールによってトンネルヘッドに分配されたものであるに違いないことを意味します)。 トンネルテールは、それがトンネルヘッドにどのラベルを分配したかを正確にIPsecによって機密保護されたトンネルを知らなければなりません。 このセットにおけるラベルはトンネルテールによってIPsecによって機密保護されたトンネルのトンネルヘッドであるそれら以外のどんなLSP隣接番組にも分配されてはいけません。 IPsecカプセル化なしでMPLSパケットを受け取って、このセットに最上のラベルがあるなら、パケットを捨てなければなりません。

   An IPsec-secured MPLS-in-IP or MPLS-in-GRE tunnel MUST provide
   authentication and integrity.  (Note that the authentication and
   integrity will apply to the entire MPLS packet, including the MPLS
   label stack.)  Thus, the implementation MUST support ESP will null
   encryption.  ESP with encryption MAY be supported if a source
   requires confidentiality.  If ESP is used, the tunnel tail MUST check
   that the source IP address of any packet received on a given SA is
   the one expected.

IPにおけるIPsecによって機密保護されたMPLSかGREのMPLSトンネルは認証と保全を提供しなければなりません。 (認証と保全がMPLSラベルスタックを含む全体のMPLSパケットに適用されることに注意します) したがって、実装は、超能力が意志のヌルの暗号化であるとサポートしなければなりません。 ソースが秘密性を必要とするなら、暗号化がある超能力はサポートされるかもしれません。 超能力が使用されているなら、トンネルテールは、どんなパケットのアドレスも与えられたSAで受けたソースIPが期待されたものであることをチェックしなければなりません。

   Key distribution may be done either manually or automatically by
   means of IKE [RFC2409].  Manual keying MUST be supported.  If
   automatic keying is implemented, IKE in main mode with preshared keys

IKE[RFC2409]によって手動的か自動的に主要な分配をするかもしれません。 手動の合わせることをサポートしなければなりません。 自動であるなら、合わせることは実装されて、メインのIKEは前共有されたキーがあるモードです。

Worster, et al.             Standards Track                     [Page 9]

RFC 4023            Encapsulating MPLS in IP or GRE           March 2005

オースター、他 2005年3月にIPかGREでMPLSをカプセル化する標準化過程[9ページ]RFC4023

   MUST be supported.  A particular application may escalate this
   requirement and request implementation of automatic keying.

サポートしなければなりません。 特定用途は自動合わせることのこの要件と要求実装を徐々に拡大するかもしれません。

   Manual key distribution is much simpler, but also less scalable, than
   automatic key distribution.  Therefore, which method of key
   distribution is appropriate for a particular tunnel has to be
   carefully considered by the administrator (or pair of administrators)
   responsible for the tunnel endpoints.  If replay protection is
   regarded as necessary for a particular tunnel, automatic key
   distribution should be configured.

手動の主要な分配も、自動主要な分配ほどはるかに簡単ですが、また、スケーラブルではありません。 したがって、特定のトンネルに、主要な分配のどのメソッドが適切であるかはトンネル終点に責任がある管理者(または、管理者の組)によって慎重に考えられなければなりません。 反復操作による保護が特定のトンネルに必要であると見なされるなら、自動主要な分配は構成されるべきです。

   If the MPLS-in-IP encapsulation is being used, the selectors
   associated with the SA would be the source and destination addresses
   mentioned above, plus the IP protocol number specified in section 3.
   If it is desired to secure multiple MPLS-in-IP tunnels between a
   given pair of nodes separately, each tunnel must have unique pair of
   IP addresses.

IPにおけるMPLSカプセル化が使用されているなら、SAに関連しているセレクタは、前記のようにソースと送付先アドレスでしょう、そして、IPプロトコル番号はセクション3で指定しました。 別々にIPにおける複数のMPLSが与えられた組のノードの間のトンネルであると機密保護するのが必要であるなら、各トンネルには、IPアドレスのユニークな組がなければなりません。

   If the MPLS-in-GRE encapsulation is being used, the selectors
   associated with the SA would be the source and destination addresses
   mentioned above, and the IP protocol number representing GRE (47).
   If it is desired to secure multiple MPLS-in-GRE tunnels between a
   given pair of nodes separately, each tunnel must have unique pair of
   IP addresses.

GREのMPLSカプセル化が使用されているなら、SAに関連しているセレクタは、ソースと、前記のように送付先アドレスと、GRE(47)を表すIPプロトコル番号でしょう。 別々にGREの複数のMPLSが与えられた組のノードの間のトンネルであると機密保護するのが必要であるなら、各トンネルには、IPアドレスのユニークな組がなければなりません。

8.2.  In the Absence of IPsec

8.2. IPsecが不在のとき

   If the tunnels are not secured with IPsec, then some other method
   should be used to ensure that packets are decapsulated and forwarded
   by the tunnel tail only if those packets were encapsulated by the
   tunnel head.  If the tunnel lies entirely within a single
   administrative domain, address filtering at the boundaries can be
   used to ensure that no packet with the IP source address of a tunnel
   endpoint or with the IP destination address of a tunnel endpoint can
   enter the domain from outside.

トンネルヘッドがそれらのパケットをカプセルに入れってだけ、IPsecと共にトンネルを固定しないなら、ある他のメソッドをパケットがdecapsulatedされるのを保証するのに使用して、トンネルテールは進めます。 トンネルがただ一つの管理ドメインに完全に属すなら、トンネル終点のIPソースアドレスかトンネル終点の受信者IPアドレスがあるどんなパケットも外部からドメインに入ることができないのを保証するのに境界のアドレスフィルタリングを使用できます。

   However, when the tunnel head and the tunnel tail are not in the same
   administrative domain, this may become difficult, and filtering based
   on the destination address can even become impossible if the packets
   must traverse the public Internet.

しかしながら、トンネルヘッドとトンネルテールが同じ管理ドメインにないとき、これは難しくなるかもしれません、そして、パケットが公共のインターネットを横断しなければならないなら、送付先アドレスに基づくフィルタリングは不可能になることさえできます。

   Sometimes only source address filtering (but not destination address
   filtering) is done at the boundaries of an administrative domain.  If
   this is the case, the filtering does not provide effective protection
   at all unless the decapsulator of an MPLS-in-IP or MPLS-in-GRE
   validates the IP source address of the packet.  This document does
   not require that the decapsulator validate the IP source address of
   the tunneled packets, but it should be understood that failure to do

時々、管理ドメインの境界でソースアドレスフィルタリング(どんな送付先アドレスもフィルターにかけられないのを除いて)だけをします。 これがそうであり、IPにおけるMPLSかGREのMPLSのdecapsulatorがパケットのIPソースアドレスを有効にしない場合、フィルタリングは全く有効保護を提供しません。 このドキュメントが、decapsulatorがトンネルを堀られたパケットのIPソースアドレスを有効にするのを必要としませんが、それが理解されるべきである、するその失敗

Worster, et al.             Standards Track                    [Page 10]

RFC 4023            Encapsulating MPLS in IP or GRE           March 2005

オースター、他 2005年3月にIPかGREでMPLSを要約する標準化過程[10ページ]RFC4023

   so presupposes that there is effective destination-based (or a
   combination of source-based and destination-based) filtering at the
   boundaries.

したがって、有効な目的地ベース(または、ソースベースと目的地ベースの組み合わせ)のフィルタリングが境界にあるのを予想します。

9. Acknowledgements

9. 承認

   This specification combines prior work on encapsulating MPLS in IP,
   by Tom Worster, Paul Doolan, Yasuhiro Katsube, Tom K. Johnson, Andrew
   G. Malis, and Rick Wilder, with prior work on encapsulating MPLS in
   GRE, by Yakov Rekhter, Daniel Tappan, and Eric Rosen.  The current
   authors wish to thank all these authors for their contribution.

この仕様はトム・オースターによるIPポールDoolanにおけるMPLS、Yasuhiro Katsube、トム・K.ジョンソン、アンドリューG.Malisを要約することに対する先の仕事とリック・ワイルダーを結合します、GREでMPLSを要約することに対する先の仕事で、ヤコフRekhter、ダニエル・タッパン、およびエリック・ローゼン。 現在の作者は彼らの貢献についてこれらのすべての作者に感謝したがっています。

   Many people have made valuable comments and corrections, including
   Rahul Aggarwal, Scott Bradner, Alex Conta, Mark Duffy, Francois Le
   Feucheur, Allison Mankin, Thomas Narten, Pekka Savola, and Alex
   Zinin.

多くの人々が貴重なコメントと修正をしました、Rahul Aggarwal、スコット・ブラドナー、アレックス・コンタ、マーク・ダフィー、フランソアLe Feucheur、アリソン・マンキン、トーマスNarten、ペッカSavola、およびアレックス・ジニンを含んでいて。

10.  Normative References

10. 引用規格

   [RFC791]  Postel, J., "Internet Protocol", STD 5, RFC 791, September
             1981.

[RFC791] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。

   [RFC792]  Postel, J., "Internet Control Message Protocol", STD 5, RFC
             792, September 1981.

[RFC792] ポステル、J.、「インターネット・コントロール・メッセージ・プロトコル」、STD5、RFC792、1981年9月。

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

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

   [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
             for IP version 6", RFC 1981, August 1996.

[RFC1981] マッキャン、J.、デアリング、S.、およびJ.ムガール人、「IPのための経路MTUディスカバリー、バージョン6インチ、RFC1981、1996インチ年8月。

   [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月。

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

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

   [RFC2463] Conta, A. and S. Deering, "Internet Control Message
             Protocol (ICMPv6) for the Internet Protocol Version 6
             (IPv6) Specification", RFC 2463, December 1998.

[RFC2463] コンタ、A.、およびS.デアリング、「インターネットへのインターネット・コントロール・メッセージ・プロトコル(ICMPv6)はバージョン6(IPv6)仕様を議定書の中で述べます」、RFC2463、1998年12月。

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

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

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

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

Worster, et al.             Standards Track                    [Page 11]

RFC 4023            Encapsulating MPLS in IP or GRE           March 2005

オースター、他 2005年3月にIPかGREでMPLSを要約する標準化過程[11ページ]RFC4023

   [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
             Label Switching Architecture", RFC 3031, January 2001.

[RFC3031] ローゼンとE.とViswanathan、A.とR.Callon、「Multiprotocolラベル切り換え構造」、RFC3031、2001年1月。

   [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
             Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
             Encoding", RFC 3032, January 2001.

[RFC3032] ローゼン、E.、タッパン、D.、Fedorkow、G.、Rekhter、Y.、ファリナッチ、D.、李、T.、およびA.コンタ、「MPLSラベルスタックコード化」、RFC3032(2001年1月)。

11.  Informative References

11. 有益な参照

   [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
             Internet Protocol", RFC 2401, November 1998.

[RFC2401] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。

   [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
             2402, November 1998.

[RFC2402] ケントとS.とR.アトキンソン、「IP認証ヘッダー」、RFC2402、1998年11月。

   [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
             Payload (ESP)", RFC 2406, November 1998.

[RFC2406]ケントとS.とR.アトキンソン、「セキュリティ有効搭載量(超能力)を要約するIP」、RFC2406、1998年11月。

   [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
             (IKE)", RFC 2409, November 1998.

[RFC2409]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。

   [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
             and W. Weiss, "An Architecture for Differentiated Service",
             RFC 2475, December 1998.

[RFC2475] ブレーク、S.は黒くされます、D.、カールソン、M.、デイヴィース、E.、ワング、Z.とW.ウィス、「微分されたサービスのための構造」RFC2475、1998年12月。

   [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE",
             RFC 2890, September 2000.

[RFC2890] Dommety、G.、「GREへのキーと一連番号拡大」、RFC2890、2000年9月。

   [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983,
             October 2000.

[RFC2983]黒(D.)が「サービスとトンネルを微分した」、RFC2983、10月2000日

   [RFC3260] Grossman, D., "New Terminology and Clarifications for
             Diffserv", RFC 3260, April 2002.

[RFC3260] グロースマンと、D.と、「Diffservのための新しい用語と明確化」、RFC3260、4月2002日

   [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,
             P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-
             Protocol Label Switching (MPLS) Support of Differentiated
             Services", RFC 3270, May 2002.

[RFC3270]Le Faucheur(F.、ウー、L.、デイビー、B.、Davari、S.、バーナネン、P.、クリシュナン、R.、シェヴァル、P.、およびJ.Heinanen、「微分されたサービスのマルチプロトコルラベルの切り換え(MPLS)サポート」、RFC3270)は2002がそうするかもしれません。

Worster, et al.             Standards Track                    [Page 12]

RFC 4023            Encapsulating MPLS in IP or GRE           March 2005

オースター、他 2005年3月にIPかGREでMPLSを要約する標準化過程[12ページ]RFC4023

Authors' Addresses

作者のアドレス

   Tom Worster
   Motorola, Inc.
   120 Turnpike Road
   Southborough, MA 01772

Southborough、トムオースターモトローラ120有料道路MA 01772

   EMail: tom.worster@motorola.com

メール: tom.worster@motorola.com

   Yakov Rekhter
   Juniper Networks, Inc.
   1194 N. Mathilda Ave.
   Sunnyvale, CA 94089

ヤコフRekhter JuniperはInc.1194N.マチルダAveをネットワークでつなぎます。 サニーベル、カリフォルニア 94089

   EMail: yakov@juniper.net

メール: yakov@juniper.net

   Eric Rosen
   Cisco Systems, Inc.
   1414 Massachusetts Avenue
   Boxborough, MA 01719

マサチューセッツ通りBoxborough、エリックローゼンシスコシステムズInc.1414MA 01719

   EMail: erosen@cisco.com

メール: erosen@cisco.com

Worster, et al.             Standards Track                    [Page 13]

RFC 4023            Encapsulating MPLS in IP or GRE           March 2005

オースター、他 2005年3月にIPかGREでMPLSを要約する標準化過程[13ページ]RFC4023

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2005).

Copyright(C)インターネット協会(2005)。

   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 currently provided by the
   Internet Society.

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

Worster, et al.             Standards Track                    [Page 14]

オースター、他 標準化過程[14ページ]