IPまたはGeneric Routing Encapsulation(GRE)でのMPLSのカプセル化



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

    Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)

IPまたはGeneric Routing Encapsulation(GRE)でのMPLSのカプセル化

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.

このドキュメントは、インターネットコミュニティ用のインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。 このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」(STD 1)の最新版を参照してください。 このメモの配布は無制限です。

Copyright Notice


   Copyright (C) The Internet Society (2005).

Copyright(C)The Internet Society(2005)。



   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が有効になっていないネットワーク上でアプリケーションを実行できます。 このドキュメントでは、MPLS-in-IPとMPLS-in-GRE(汎用ルーティングカプセル化)の2つのIPベースのカプセル化を指定しています。 これらはそれぞれ、特定の状況で適用されます。

Worster, et al.             Standards Track                     [Page 1]
RFC 4023            Encapsulating MPLS in IP or GRE           March 2005

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.断片化と再組み立ての防止............... 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


   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バックボーンを通過するパケットは、複数のラベルを持つラベルスタックを伝送します。 [RFC3031]のセクション3.15で説明されているように、各ラベルはラベルスイッチドパス(LSP)を表します。 各LSPには、「LSP Ingress」であるラベルスイッチングルーター(LSR)と「LSP Egress」であるLSRがあります。 LSR AとBがそれぞれパケットのトップラベルに対応するLSPのIngressとEgressである場合、AとBはパケットの2番目のラベル(つまり、トップラベルのすぐ下のラベル)に対応するLSPの隣接LSRです。 。

   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 Routing Encapsulation(GRE)ヘッダーは、トップラベルを置き換えることができます。 カプセル化されたパケットは引き続きMPLSパケットであるため、結果はMPLS-in-IPまたはMPLS-in-GREカプセル化になります。

   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.


Worster, et al.             Standards Track                     [Page 2]
RFC 4023            Encapsulating MPLS in IP or GRE           March 2005

   To use either of these encapsulations, the encapsulating LSR must


      -  the IP address of the decapsulating LSR, and


      -  that the decapsulating LSR actually supports the particular


   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

この知識は、手動構成によって、または何らかの発見プロトコルによって、カプセル化LSRに伝えられます。 特に、特定のアプリケーションをサポートするためにトンネルが使用されていて、そのアプリケーションにセットアップまたはディスカバリプロトコルがある場合、アプリケーションのプロトコルはこの知識を伝えることができます。 この知識を伝える手段は、このドキュメントの範囲外です。

2.  Specification of Requirements


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

このドキュメントでは、キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」 [RFC2119]で説明されているように解釈されます。

3.  Encapsulation in IP

3. IPでのカプセル化

   MPLS-in-IP messages have the following format:


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

         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.

このフィールドには、[RFC791]または[RFC2460]でそれぞれ定義されているIPv4またはIPv6データグラムヘッダーが含まれます。 送信元アドレスと宛先アドレスは、それぞれカプセル化LSRとカプセル化解除LSRのアドレスに設定されます。

Worster, et al.             Standards Track                     [Page 3]
RFC 4023            Encapsulating MPLS in IP or GRE           March 2005

         MPLS Label Stack


             This field contains an MPLS Label Stack as defined in


         Message Body


             This field contains one MPLS message body.


   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

IPv4プロトコル番号フィールドまたはIPv6次ヘッダーフィールドは137に設定され、MPLSユニキャストパケットを示します。 (MPLSマルチキャストパケットに対するMPLS-in-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.

[RFC3032]で指定されているように、IPヘッダーの後にMPLSパケットが続きます。 このカプセル化により、MPLSパケットは「IPトンネル」を通じて送信されます。 トンネルの受信エンドポイントがパケットを受信すると、IPヘッダーを削除してMPLSパケットのカプセル化を解除します。 次に、パケットは受信したMPLSパケットとして処理され、その「着信ラベル」[RFC3031]はカプセル化解除されたパケットの最上位のラベルです。

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

MPLS-in-GREカプセル化は、MPLSパケットをGRE [RFC2784]にカプセル化します。 パケットは、[RFC3032]で指定されているように、IPヘッダー(IPv4またはIPv6)、GREヘッダー、MPLSラベルスタックで構成されます。 GREヘッダーのプロトコルタイプフィールドは、MPLSユニキャスト(0x8847)またはマルチキャスト(0x8848)のEthertype値に設定する必要があります。

   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

このカプセル化により、MPLSパケットが「GREトンネル」を介して送信されます。 トンネルの受信エンドポイントがパケットを受信すると、IPおよびGREヘッダーを削除することにより、MPLSパケットのカプセル化を解除します。 次に、パケットは受信したMPLSパケットとして処理され、その「着信ラベル」[RFC3031]はカプセル化解除されたパケットの最上位のラベルです。

   [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キーとシーケンス番号フィールドを指定します。 これらのオプションのフィールドは、MPLS-in-GREカプセル化にはあまり役立ちません。 トンネリングされるネイティブMPLSパケットには対応するフィールドがないため、シーケンス番号とチェックサムフィールドは必要ありません。 カプセル化されたパケットのトップMPLSラベルがその目的で使用されるため、GREキーフィールドは逆多重化には必要ありません。 GREキーフィールドは、32ビットのクリアテキストパスワードとして機能するセキュリティ機能と見なされることがありますが、これは非常に弱いセキュリティ形式です。 (a)カプセル化/カプセル化解除手順の高速実装を容易にするため、および(b)相互運用性を保証するために、すべての実装がこれらのオプションフィールドなしで正しく動作できる必要があります。

Worster, et al.             Standards Track                     [Page 4]
RFC 4023            Encapsulating MPLS in IP or GRE           March 2005

   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

より正確には、MPLS-in-GREカプセル化解除機能の実装は、これらのオプションのフィールドなしでパケットを正しく処理できなければなりません(MUST)。 これらのオプションのフィールドでパケットを正しく処理できる場合があります。

   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

MPLS-in-GREカプセル化装置の実装は、これらのオプションフィールドなしでパケットを生成できなければなりません(MUST)。 それはこれらのフィールドでパケットを生成する能力を持っているかもしれませんが、デフォルトの状態はこれらのフィールドなしでパケットが生成されることでなければなりません。 カプセル化解除者がフィールドを正しく処理できることがわかっている場合を除いて、カプセル化者はこれらのオプションフィールドを含めてはなりません(MUST NOT)。 この知識を伝える方法は、この仕様の範囲外です。

5.  Common Procedures


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

特定の手順は、MPLS-in-IPおよびMPLS-in-GREカプセル化の両方に共通です。 以下では、カプセル化IPヘッダーのIP送信元アドレスフィールドにアドレスが表示されるカプセル化装置を「トンネルヘッド」と呼びます。 カプセル化を解除する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が使用されている場合(MPLS-in-IPv6またはMPLS-in-GRE-in- IPv6のいずれか)、[RFC2473]の手順が一般的に適用されます。

5.1.  Preventing Fragmentation and Reassembly

5.1。 断片化と再組み立ての防止

   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.

MPLS-in-IPまたはMPLS-in-GREパケットが断片化された場合(「通常の」IP断片化が原因で)、含まれているMPLSパケットがカプセル化解除される前に、トンネルテールがパケットを再構成する必要があります。 トンネルテールがルータの場合、これは望ましくない可能性があります。 トンネルテールには、必要なレベルのパフォーマンスで再構成を実行する機能またはリソースがない可能性があります。

   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.

トンネル化されたパケットの断片化が許可されるかどうかは、トンネルヘッドで構成可能でなければなりません。 デフォルト値は、パケットがフラグメント化されていないことである必要があります。 デフォルト値は、トンネルテールが再構成機能を適切に実行できることがわかっている場合にのみ変更されます。



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

明らかに、パケットがフラグメント化されない場合、トンネルヘッドはパケットをカプセル化する前にフラグメント化してはなりません(MUST NOT)。

Worster, et al.             Standards Track                     [Page 5]
RFC 4023            Encapsulating MPLS in IP or GRE           March 2005

   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

IPv4を使用する場合、トンネルはDFビットを設定する必要があります。 これにより、トンネル内の中間ノードが断片化を実行するのを防ぎます。 (IPv6を使用する場合、中間ノードはどのような場合でもフラグメンテーションを実行しません。)

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


   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

トンネルヘッドは、各トンネルの「トンネルMTU」を維持する必要があります。 これは、(a)管理上構成された値、および(わかっている場合)、(b)検出されたパスMTU値からカプセル化のオーバーヘッドを引いた値の最小値です。

   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.

トンネルヘッドがカプセル化のために、サイズがトンネルMTUを超えるMPLSパケットを受信した場合、そのパケットは破棄されなければなりません(MUST)。 ただし、そのようなパケットを静かにドロップすると、重大な運用上の問題が発生する可能性があります。 パケットの発信者は、自分のデータが届かないことに気づくでしょうが、大きなパケットがパケット損失を引き起こしていることに気付かないかもしれません。 したがって、破棄されたパケットを送信し続ける可能性があります。 パスMTUディスカバリーは役立ちます(トンネルヘッドがICMPエラーを返送する場合)。ただし、発信元の送信者を適切に識別するには、トンネルヘッドで利用できる情報が不十分であることがよくあります。 問題を最小限に抑えるために、MTUは実際には断片化を回避するのに十分な大きさに設計することをお勧めします。

   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にカプセル化され、次にMPLS-in-IPまたはMPLS-in-GREにカプセル化されます。 IPパケットの送信元がトンネルヘッドから到達可能であり、MPLSでパケットをカプセル化した結果が、トンネルMTUを超えるサイズのパケットである場合、トンネルヘッドがフラグメント化とPMTU検出に外部で使用する値 トンネルは、トンネルMTU値からMPLSカプセル化のサイズを引いた値です。 (つまり、トンネルMTU値からMPLSカプセル化のサイズを引いた値が、ICMPメッセージで報告されるMTUになります。)パケットは破棄する必要がありますが、トンネルヘッドは破棄されたパケットのIPソースを送信する必要があります。 [RFC1191]または[RFC1981]で指定されている適切なICMPエラーメッセージ。

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.

トンネルヘッドは、MPLSラベルスタックからのTTLを、カプセル化するIPv4ヘッダーのTTLフィールドまたはカプセル化するIPv6ヘッダーのホップ制限フィールドに配置してもよい(MAY)。 トンネルテールは、カプセル化IPv4ヘッダーからのTTLまたはカプセル化IPv6ヘッダーからのホップ制限をMPLSヘッダーのTTLフィールドに配置する場合があります(ただし、これによりMPLSヘッダーのTTL値が増加しない場合のみ)。

Worster, et al.             Standards Track                     [Page 6]
RFC 4023            Encapsulating MPLS in IP or GRE           March 2005

   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-in-IPトンネルの存在下で差別化サービスアーキテクチャを適切にサポートするために適用する必要がある多くの考慮事項と手順について詳しく説明しています。 これらの考慮事項と手順は、MPLS-in-IPまたはMPLS-in-GREトンネルが存在する場合にも適用されます。

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

したがって、トンネルヘッドがMPLS-in-IPまたはMPLS-in-GREトンネルに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パケットの動作集約を決定できます。 [RFC3270]は、行動集約とその後のパケットの後処理の間の関係を指定します。

6.  Applicability


   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:

MPLS-in-IPカプセル化の方が効率的であり、通常は他の条件が同じであると見なされます。 ただし、MPLS-in-GREカプセル化を使用できる状況がいくつかあります。

      -  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カプセル化を必要とするため、MPLS-in-GREカプセル化は代替策よりも効率的です。つまり、MPLS-in-IPカプセル化はGREにカプセル化されます。

      -  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-in-GREの使用が決定される場合があります。 たとえば、一部のハードウェアデバイスは、高速パスでGREカプセル化のみを処理できる場合があります。

Worster, et al.             Standards Track                     [Page 7]
RFC 4023            Encapsulating MPLS in IP or GRE           March 2005

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は、セクション3で説明されているように、MPLS-in-IPカプセル化にIPプロトコル番号137を割り当てています。 将来のIANAアクションは必要ありません。 MPLS-in-GREカプセル化には、IANAアクションは必要ありません。

8.  Security Considerations


   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

IPまたはGREトンネルを使用するときに直面する主なセキュリティ問題は、トンネルの受信エンドポイントが、トンネルから送信されたように見えても、実際にはトンネルの送信エンドポイントによってトンネルに送信されなかったパケットを取得する可能性です。 (指定されたカプセル化だけでは、カプセル開放装置がカプセル化装置を認証できるようにはなりません。)2番目の問題は、トンネルに入るときと出るときとの間でパケットが変更される可能性です。 (指定されたカプセル化自体は、パケットの完全性のカプセル化解除を保証しません。)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サポートをオプションとして定義しています。 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.

MPLS-in-IPまたはMPLS-in-GREトンネルが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.,

Worster, et al.             Standards Track                     [Page 8]
RFC 4023            Encapsulating MPLS in IP or GRE           March 2005

   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

IPsecを使用する場合、トンネルヘッドとトンネルテールは、セキュリティアソシエーションのエンドポイントとして扱う必要があります。 この目的のために、トンネルヘッドの単一のIPアドレスがソースIPアドレスとして使用され、トンネルテールの単一のIPアドレスが宛先IPアドレスとして使用されます。 各ノードが他のノードの適切なアドレスを知る手段は、このドキュメントの範囲外です。 制御プロトコルを使用してトンネルを設定する場合(たとえば、一方のトンネルエンドポイントに他方のIPアドレスを通知する場合)、制御プロトコルには認証メカニズムが必要であり、これはトンネルを設定するときに使用する必要があります。 たとえば、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.

MPLS-in-IPまたはMPLS-in-GREでカプセル化されたパケットは、トンネルヘッドから発信され、トンネルテールに向けられていると見なす必要があります。 したがって、IPsecトランスポートモードを使用する必要があります。

   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.

トンネルヘッドがIPsecトランスポートモードを使用してMPLS-in-IPパケットを保護する場合、MPLS-in-IPパケットのIPヘッダーは、結果のパケットの外部IPヘッダーになります。 この後にIPsecヘッダーが続き、その後にMPLSラベルスタックが続きます。 IPsecヘッダーは、セクション3で指定されたIPプロトコル番号を使用して、ペイロードタイプをMPLSに設定する必要があります。 IPsecトランスポートモードがMPLS-in-GREパケットに適用されている場合、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アウトバウンド処理は含まれているMPLS-in-IP / GREパケットを回復します。 次に、トンネルテールはカプセル化IP / GREヘッダーを取り除き、MPLSパケットを回復します。MPLSパケットは、ラベルスタックに従って転送されます。

   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隣接に配布してはなりません(MUST NOT)。 IPsecカプセル化なしでMPLSパケットが受信され、その最上位ラベルがこのセットにある場合、パケットは破棄されなければなりません(MUST)。

   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.

IPsecで保護されたMPLS-in-IPまたはMPLS-in-GREトンネルは、認証と整合性を提供する必要があります。 (認証と整合性は、MPLSラベルスタックを含むMPLSパケット全体に適用されることに注意してください。)したがって、実装はESP will null暗号化をサポートする必要があります。 ソースに機密性が必要な場合は、暗号化されたESPがサポートされる場合があります。 ESPが使用されている場合、トンネルテールは、特定の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

Worster, et al.             Standards Track                     [Page 9]
RFC 4023            Encapsulating MPLS in IP or GRE           March 2005

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

鍵の配布は、IKE [RFC2409]を使用して手動または自動で行うことができます。 手動キーイングをサポートする必要があります。 自動キーイングが実装されている場合、事前共有キーを使用したメインモードのIKEをサポートする必要があります。 特定のアプリケーションがこの要件をエスカレートし、自動キーイングの実装を要求する場合があります。

   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.

MPLS-in-IPカプセル化が使用されている場合、SAに関連付けられたセレクターは、上記の送信元アドレスと宛先アドレス、およびセクション3で指定されたIPプロトコル番号になります。 特定のノードペア間で複数のMPLS-in-IPトンネルを個別に保護する必要がある場合は、各トンネルに一意の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.

MPLS-in-GREカプセル化が使用されている場合、SAに関連付けられたセレクターは、上記の送信元アドレスと宛先アドレス、およびGREを表すIPプロトコル番号になります(47)。 特定のノードのペア間で複数のMPLS-in-GREトンネルを個別に保護する必要がある場合は、各トンネルに一意の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で保護されていない場合は、他の方法を使用して、パケットがトンネルヘッドによってカプセル化されている場合にのみ、パケットがトンネルテールによってカプセル化解除されて転送されるようにする必要があります。 トンネルが完全に単一の管理ドメイン内にある場合、境界でのアドレスフィルタリングを使用して、トンネルエンドポイントの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

Worster, et al.             Standards Track                    [Page 10]
RFC 4023            Encapsulating MPLS in IP or GRE           March 2005

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

場合によっては、管理ドメインの境界で送信元アドレスフィルタリングのみが実行されます(宛先アドレスフィルタリングは実行されません)。 この場合、MPLS-in-IPまたはMPLS-in-GREのカプセル開放装置がパケットのIP送信元アドレスを検証しない限り、フィルタリングは効果的な保護をまったく提供しません。 このドキュメントでは、カプセル化解除ツールがトンネル化パケットのIP送信元アドレスを検証する必要はありませんが、検証に失敗すると、宛先ベース(または送信元ベースと宛先ベースの組み合わせ)の効果的なフィルタリングが前提となることを理解してください 境界で。

9. Acknowledgements


   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.

   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

10.  Normative References


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

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

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

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

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

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

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

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

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

Worster, et al.             Standards Track                    [Page 11]
RFC 4023            Encapsulating MPLS in IP or GRE           March 2005

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

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

11.  Informative References


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

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

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

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

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

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

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

   [RFC3260] Grossman, D., "New Terminology and Clarifications for
             Diffserv", RFC 3260, April 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.

Worster, et al.             Standards Track                    [Page 12]
RFC 4023            Encapsulating MPLS in IP or GRE           March 2005

Authors' Addresses

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

   EMail: tom.worster@motorola.com

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

   EMail: yakov@juniper.net

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

   EMail: erosen@cisco.com

Worster, et al.             Standards Track                    [Page 13]
RFC 4023            Encapsulating MPLS in IP or GRE           March 2005

Full Copyright Statement

   Copyright (C) The Internet Society (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.

   This document and the information contained herein are provided on an

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.

   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

   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-


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

Worster, et al.             Standards Track                    [Page 14]