[要約] RFC 4023は、MPLSをIPまたはGeneric Routing Encapsulation（GRE）でカプセル化する方法についての標準化ドキュメントです。このRFCの目的は、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または一般的なルーティングカプセル化（GRE）でのMPLのカプセル化
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.
MPLのさまざまなアプリケーションでは、複数のエントリを備えたラベルスタックを使用しています。場合によっては、スタックのトップラベルをIPベースのカプセル化に置き換えることができ、それにより、アプリケーションがコアルーターでMPLSを有効にしていないネットワーク上でアプリケーションを実行できるようにすることができます。このドキュメントは、2つのIPベースのカプセルを指定します：MPLS-in-IPとMPLS-in-GRE（一般的なルーティングカプセル化）。これらのそれぞれは、状況によっては適用できます。
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
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があります。LSRS AとBが、パケットのトップレーベルに対応するLSPのLSPと出口でそれぞれ侵入と出口である場合、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ヘッダーまたは一般的なルーティングカプセル化（GRE）ヘッダーは、トップレーベルを置き換えることができます。カプセル化されたパケットは依然としてMPLSパケットであるため、結果はMPLS-in-IPまたはMPLS-in-GRE-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.
これらのカプセルでは、たとえそのIPネットワークがMPLSを提供していなくても、LSPに隣接する2つのLSRがIPネットワークによって分離される可能性があります。
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をカプセル化することに伝えられる場合があります。特に、トンネルが特定のアプリケーションをサポートするために使用され、そのアプリケーションにセットアップまたは発見プロトコルがある場合、アプリケーションのプロトコルはこの知識を伝えることができます。この知識を伝える手段は、このドキュメントの範囲外です。
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].
このドキュメントでは、キーワードが「必須」、「必須」、「必須」、「shall」、「shall "、" low "of" bould "、" becommented "、"、 "、"、 "optional"[RFC2119]に記載されているように解釈されます。
MPLS-in-IP messages have the following format:
MPLS-in-IPメッセージには次の形式があります。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| 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.
IPヘッダーこのフィールドには、それぞれ[RFC791]または[RFC2460]で定義されているIPv4またはIPv6データグラムヘッダーが含まれています。ソースおよび宛先アドレスは、それぞれLSRをカプセル化および脱カプセル化するアドレスに設定されています。
MPLS Label Stack This field contains an MPLS Label Stack as defined in [RFC3032].
MPLSラベルスタックこのフィールドには、[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パケットを脱カプセル化します。その後、パケットは、「着信ラベル」[RFC3031]が脱カプセル化パケットの最上位ラベルである受信MPLSパケットとして処理されます。
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のカプセル化は、GRE [RFC2784]のMPLSパケットをカプセル化します。パケットは、IPヘッダー（IPv4またはIPv6のいずれか）で構成され、その後にGREヘッダーが続き、[RFC3032]で指定されている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パケットを脱カプセル化します。その後、パケットは、「着信ラベル」[RFC3031]が脱カプセル化パケットの最上位ラベルである受信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キーおよびシーケンス番号フィールドを指定します。これらのオプションのフィールドは、MPLS-in-GRE-in-GREのカプセル化にはあまり役に立ちません。シーケンス番号とチェックサムフィールドは必要ありません。これは、トンネル化されているネイティブMPLSパケットに対応するフィールドがないためです。カプセル化されたパケットのトップMPLSラベルがその目的に使用されるため、GREキーフィールドは非gultiplexingに必要はありません。GREキーフィールドは、32ビットのClearTextパスワードとして機能するセキュリティ機能と見なされる場合がありますが、これは非常に弱いセキュリティです。（a）カプセル化/脱カプセル化手順の高速実装を容易にするために、（b）相互運用性を確保するために、すべての実装がこれらのオプションフィールドなしで正しく動作できることを要求します。
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の脱カプセレータの実装は、これらのオプションのフィールドなしでパケットを正しく処理できる必要があります。これらのオプションのフィールドでパケットを正しく処理できる場合があります。
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エンコープカプレータの実装は、これらのオプションのフィールドなしでパケットを生成できる必要があります。これらのフィールドでパケットを生成する機能がある場合がありますが、デフォルトの状態は、これらのフィールドなしでパケットが生成されることです。カプセレータがそれらを正しく処理できることがわかっていない限り、カプセル装置には、これらのオプションのフィールドのいずれかを含めてはなりません。この知識を伝える方法は、この仕様の範囲外です。
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]の手順が一般的に適用されます。
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-GRIN-in-GRE-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.
明らかに、パケットを断片化しない場合、トンネルヘッドがカプセル化する前にパケットを断片化してはなりません。
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).
トンネルヘッドは、IPv4の場合はPATH MTUディスカバリー（[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）管理的に構成された値の最小であり、既知の場合、（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パケットを受信した場合、そのパケットを破棄する必要があります。ただし、このようなパケットを静かに削除すると、重大な運用上の問題が発生する可能性があります。パケットの創始者は、自分のデータが通過していないことに気付くでしょうが、大きなパケットがパケットの損失を引き起こしていることに気付かないかもしれません。したがって、彼は破棄されたパケットを送信し続けることができます。Path 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].
場合によっては、トンネルヘッドがカプセル化のために、最初にMPLSでカプセル化し、次にMPLS-in-IPまたはMPLS-in-GREでカプセル化するIPパケットを受け取ります。IPパケットのソースがトンネルヘッドから到達可能であり、MPLSのパケットをカプセル化した結果が、サイズがトンネルMTUを超えるパケットである場合、トンネルヘッドがフラグメンテーションとPMTUの発見に使用する値を除く値トンネルは、MPLSカプセル化のサイズを差し引いたトンネルMTU値です。（つまり、トンネルMTU値はMPLSカプセル化のサイズを差し引いて、ICMPメッセージで報告されるMTUです。）パケットは破棄する必要がありますが、トンネルヘッドは廃棄されたパケットのIPソースを送信する必要があります。[RFC1191]または[RFC1981]で指定されている適切なICMPエラーメッセージ。
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ヘッダーのホップ制限フィールドに配置する場合があります。トンネルテールは、カプセル化IPv4ヘッダーからTTLを配置するか、IPv6ヘッダーをカプセル化するIPv4ヘッダーからMPLSヘッダーのTTLフィールドに配置する場合がありますが、MPLSヘッダーのTTL値が増加しない場合のみです。
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.
そのような変更が行われ、それらの作成方法の詳細がトンネルテールとトンネルヘッドの構成に依存します。
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-GRINのトンネルの存在下でも適用されます。
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パケットをMPLS-in-IPまたはMPLS-in-GRINのトンネルに送信しようとしている場合、IPv4またはIPv6ヘッダーのカプセル化のDSフィールドの設定は、（少なくとも部分的に）決定することができます。MPLSパケットの「動作集約」。MPLSパケットの動作凝集を決定するための手順は、[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]は、動作の集合体とその後のパケットの処分との関係を指定します。
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.
- このドキュメントの範囲の外側にある何らかの理由で存在するGREトンネルの上に2つのルーターが「隣接」されており、これらの2つのルーターはその隣接を介してMPLSパケットを送信する必要があります。この隣接順に送信されるすべてのパケットにはGREのカプセル化が必要なため、GREでカプセル化されるMPLS-IPカプセル化となるMPLS-in-GRIN-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の使用を決定する可能性があります。たとえば、一部のハードウェアデバイスは、fastPathでGREカプセルのみを処理できる場合があります。
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アクションは必要ありません。
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で説明します。
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-GRINGREトンネルが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., 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アドレスの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.
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.
MPLS-in-IPパケットのIPヘッダーは、トンネルヘッドがIPSECトランスポートモードを使用してMPLS-in-IPパケットを保護するときに、結果のパケットの外側IPヘッダーになります。これに続いて、IPSECヘッダーが続き、その後、MPLSラベルスタックが続きます。IPSECヘッダーは、セクション3で指定されたIPプロトコル番号を使用して、Payload TypeをMPLSに設定する必要があります。IPSECトランスポートモードがMPLS-in-GRE-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パケットを回復し、ラベルスタックに従って転送します。
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隣接に分配してはなりません。MPLSパケットがIPSECカプセル化なしで受信され、その最上位ラベルがこのセットにある場合は、パケットを破棄する必要があります。
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-IN-GRE-in-GRERSトンネルは、認証と整合性を提供する必要があります。（認証と整合性は、MPLSラベルスタックを含むMPLSパケット全体に適用されることに注意してください。）したがって、実装はESPをサポートする必要があります。ソースが機密性を必要とする場合、暗号化付きの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 MUST be supported. A particular application may escalate this requirement and request implementation of automatic keying.
重要な分布は、IKE [RFC2409]によって手動または自動的に行うことができます。手動キーをサポートする必要があります。自動キーイングが実装されている場合、Presharedキーを備えたメインモードの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プロトコル番号になります。特定のノードの間のトンネル別々に、各トンネルには一意の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-GRPREトンネルを個別に固定することが望ましい場合、各トンネルには一意のIPアドレスペアが必要です。
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 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-GRSの脱カプセレーターがパケットのIPソースアドレスを検証しない限り、フィルタリングは効果的な保護をまったく提供しません。このドキュメントでは、カプセレータがトンネルパケットのIPソースアドレスを検証することは必要ありませんが、そうしないと、効果的な宛先ベースの（またはソースベースと宛先ベースの組み合わせ）フィルタリングがあることを前提としていることを理解する必要があります。境界で。
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.
この仕様は、Tom Worster、Paul Doolan、Yasuhiro Katube、Tom K. Johnson、Andrew G. Malis、およびRick WilderによるIPのMPLのカプセル化に関する以前の研究と、GREのMPLSのカプセル化に関する以前の作業を組み合わせています。、エリック・ローゼン。現在の著者は、これらすべての著者の貢献に感謝したいと考えています。
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、Scott Bradner、Alex Conta、Mark Duffy、Francois Le Feucheur、Allison Mankin、Thomas Narten、Pekka Savola、Alex Zininなど、貴重なコメントと修正を行っています。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC792] Postel、J。、「インターネット制御メッセージプロトコル」、STD 5、RFC 792、1981年9月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191] Mogul、J。およびS. Deering、「Path MTU Discovery」、RFC 1191、1990年11月。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981] McCann、J.、Deering、S。、およびJ. Mogul、「IPバージョン6のPath MTU Discovery」、RFC 1981、1996年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC2463] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998.
[RFC2463] Conta、A。およびS. Deering、「インターネットプロトコルバージョン6（IPv6）仕様のインターネット制御メッセージプロトコル（ICMPV6）」、RFC 2463、1998年12月。
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998.
[RFC2473] Conta、A。およびS. Deering、「IPv6仕様の一般的なパケットトンネル」、RFC 2473、1998年12月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784] Farinacci、D.、Li、T.、Hanks、S.、Meyer、D。、およびP. Traina、「Generic Routing Cancapstulation（GRE）」、RFC 2784、2000年3月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、RFC 3031、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] Rosen、E.、Tappan、D.、Fedorkow、G.、Rekhter、Y.、Farinacci、D.、Li、T。、およびA. conta、「Mpls Label Stack ending」、RFC 3032、2001年1月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[RFC2402]ケント、S。およびR.アトキンソン、「IP認証ヘッダー」、RFC 2402、1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406] Kent、S。およびR. Atkinson、「IPカプセンシングセキュリティペイロード（ESP）」、RFC 2406、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409] Harkins、D。およびD. Carrel、「The Internet Key Exchange（IKE）」、RFC 2409、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] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z.、およびW. Weiss、「Distementiated Serviceの建築」、RFC 2475、1998年12月。
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, September 2000.
[RFC2890] Dommety、G。、「GREへのキーおよびシーケンス番号拡張」、RFC 2890、2000年9月。
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC2983] Black、D。、「差別化されたサービスとトンネル」、RFC 2983、2000年10月。
[RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002.
[RFC3260] Grossman、D。、「Diffservの新しい用語と説明」、RFC 3260、2002年4月。
[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.、Wu、L.、Davie、B.、Davari、S.、Vaananen、P.、Krishnan、R.、Cheval、P。、およびJ. Heinanen、 "Multi-protocolラベルスイッチング（MPLS）差別化されたサービスのサポート」、RFC 3270、2002年5月。
Authors' Addresses
著者のアドレス
Tom Worster Motorola, Inc. 120 Turnpike Road Southborough, MA 01772
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
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
エリック・ローゼン・シスコ・システムズ、1414マサチューセッツ・アベニュー・ボックスボロー、マサチューセッツ州01719
EMail: erosen@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
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.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
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.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78および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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンライン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.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。