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）。
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が有効になっていないネットワーク上でアプリケーションを実行できます。 このドキュメントでは、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
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バックボーンを通過するパケットは、複数のラベルを持つラベルスタックを伝送します。 [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.
これらのカプセル化により、LSPで隣接する2つのLSRが、IPネットワークがMPLSを提供していない場合でも、IPネットワークによって分離される可能性があります。
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 know
これらのカプセル化のいずれかを使用するには、カプセル化LSRは、
- the IP address of the decapsulating LSR, and
-カプセル化を解除するLSRのIPアドレス、および
- that the decapsulating LSR actually supports the particular
encapsulation.
-カプセル化解除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」、「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:
MPLS-in-IPメッセージの形式は次のとおりです。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IP Header |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MPLS Label Stack |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Message Body |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IP Header
IPヘッダー
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
MPLSラベルスタック
This field contains an MPLS Label Stack as defined in
[RFC3032].
このフィールドには、[RFC3032]で定義されているMPLSラベルスタックが含まれます。
Message Body
メッセージ本文
This field contains one MPLS message body.
このフィールドには、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.)
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 packet.
このカプセル化により、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 fields.
より正確には、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 specification.
MPLS-in-GREカプセル化装置の実装は、これらのオプションフィールドなしでパケットを生成できなければなりません（MUST）。 それはこれらのフィールドでパケットを生成する能力を持っているかもしれませんが、デフォルトの状態はこれらのフィールドなしでパケットが生成されることでなければなりません。 カプセル化解除者がフィールドを正しく処理できることがわかっている場合を除いて、カプセル化者はこれらのオプションフィールドを含めてはなりません（MUST NOT）。 この知識を伝える方法は、この仕様の範囲外です。
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".
特定の手順は、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.
トンネル化されたパケットの断片化が許可されるかどうかは、トンネルヘッドで構成可能でなければなりません。 デフォルト値は、パケットがフラグメント化されていないことである必要があります。 デフォルト値は、トンネルテールが再構成機能を適切に実行できることがわかっている場合にのみ変更されます。
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.
明らかに、パケットがフラグメント化されない場合、トンネルヘッドはパケットをカプセル化する前にフラグメント化してはなりません（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 event.)
IPv4を使用する場合、トンネルはDFビットを設定する必要があります。 これにより、トンネル内の中間ノードが断片化を実行するのを防ぎます。 （IPv6を使用する場合、中間ノードはどのような場合でもフラグメンテーションを実行しません。）
The tunnel head SHOULD perform Path MTU Discovery ([RFC1191] for IPv4, or [RFC1981] for IPv6).
トンネルヘッドは、パスMTUディスカバリ（IPv4の場合は[RFC1191]、IPv6の場合は[RFC1981]）を実行する必要があります（SHOULD）。
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）管理上構成された値、および（わかっている場合）、（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
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:
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
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トンネルを使用するときに直面する主なセキュリティ問題は、トンネルの受信エンドポイントが、トンネルから送信されたように見えても、実際にはトンネルの送信エンドポイントによってトンネルに送信されなかったパケットを取得する可能性です。 （指定されたカプセル化だけでは、カプセル開放装置がカプセル化装置を認証できるようにはなりません。）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 satisfactory.
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 boundaries.
場合によっては、管理ドメインの境界で送信元アドレスフィルタリングのみが実行されます（宛先アドレスフィルタリングは実行されません）。 この場合、MPLS-in-IPまたはMPLS-in-GREのカプセル開放装置がパケットのIP送信元アドレスを検証しない限り、フィルタリングは効果的な保護をまったく提供しません。 このドキュメントでは、カプセル化解除ツールがトンネル化パケットのIP送信元アドレスを検証する必要はありませんが、検証に失敗すると、宛先ベース（または送信元ベースと宛先ベースの組み合わせ）の効果的なフィルタリングが前提となることを理解してください 境界で。
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. 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. 10. Normative References
10.規範的な参照
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[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
2000.
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
11.有益な参照
[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
"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.
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
http://www.ietf.org/ipr.
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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Worster, et al. Standards Track [Page 14]