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)
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.
このドキュメントでは、インターネットコミュニティ向けのインターネット標準追跡プロトコルを指定し、改善のための議論と提案を求めています。 このプロトコルの標準化状態とステータスについては、「Internet Official Protocol Standards」（STD 1）の最新版を参照してください。 このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
Various applications of MPLS make use of label stacks with multiple entries. In some cases, it is possible to replace the top label of the stack with an IP-based encapsulation, thereby enabling the application to run over networks that do not have MPLS enabled in their core routers. This document specifies two IP-based encapsulations: MPLS-in-IP and MPLS-in-GRE (Generic Routing Encapsulation). Each of these is applicable in some circumstances.
MPLSのさまざまなアプリケーションは、複数のエントリを持つラベルスタックを利用します。 場合によっては、スタックのトップラベルをIPベースのカプセル化に置き換えて、コアルーターでMPLSが有効になっていないネットワーク上でアプリケーションを実行できるようにすることができます。 このドキュメントでは、2つのIPベースのカプセル化、MPLS-in-IPとMPLS-in-GRE（Generic Routing Encapsulation）を指定しています。 これらはそれぞれ、状況によっては適用されます。
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で説明されているように、各ラベルはLabel Switched Path（LSP）を表します。 各LSPには、「LSP Ingress」であるLabel Switching Router（LSR）と「LSP Egress」であるLSRがあります。 LSR AおよびBがそれぞれパケットのトップラベルに対応する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ヘッダーまたは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.
これらのカプセル化により、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].
このドキュメントでは、キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「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 Next Headerフィールドは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]はカプセル化解除されたパケットの最上位ラベルです。
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パケットをカプセル化します。 パケットは、[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）相互運用性を確保するために、これらのオプションフィールドなしですべての実装が正しく動作できることを要求します。
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 decapsulatorの実装は、これらのオプションフィールドなしでパケットを正しく処理できる必要があります。 これらのオプションフィールドでパケットを正しく処理できる場合があります。
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が使用されている場合（IPv6のMPLSまたはIPv6のMPLSのいずれか）、[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-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).
トンネルヘッドは、パスMTUディスカバリを実行する必要があります（IPv4の場合は[RFC1191]、IPv6の場合は[RFC1981]）。
The tunnel head MUST maintain a "Tunnel MTU" for each tunnel; this is the minimum of (a) an administratively configured value, and, if known, (b) the discovered Path MTU value minus the encapsulation overhead.
トンネルヘッドは、トンネルごとに「トンネルMTU」を維持する必要があります。 これは、（a）管理上設定された値、および既知の場合、（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パケットを受信した場合、そのパケットは破棄されなければなりません。 ただし、このようなパケットを静かにドロップすると、重大な運用上の問題が発生する可能性があります。 パケットの発信者は、データが通過していないことに気付くでしょうが、大きなパケットがパケット損失を引き起こしていることに気付かないかもしれません。 したがって、彼は破棄されたパケットの送信を続けることができます。 パス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パケットを受信します。最初にMPLSでカプセル化し、次にMPLS-in-IPまたはMPLS-in-GREでカプセル化します。 IPパケットのソースがトンネルヘッドから到達可能であり、MPLSでパケットをカプセル化した結果がトンネルMTUを超えるサイズのパケットである場合、トンネルヘッドが外部でフラグメンテーションとPMTUディスカバリに使用する必要がある値 トンネルは、トンネルMTU値からMPLSカプセル化のサイズを引いたものです。 （つまり、トンネル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ヘッダーからのホップ制限を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.
このドキュメントで指定された手順により、IPまたはGREトンネルを介してLSPを送信できます。 [RFC2983]は、IP-in-IPトンネルが存在する場合に、Differentiated Services Architectureを適切にサポートするために適用する必要がある多くの考慮事項と手順を詳述しています。 これらの考慮事項と手順は、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パケットをMPLS-in-IPまたはMPLS-in-GREトンネルに送信しようとするとき、カプセル化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.
同様に、トンネルテールでは、カプセル化されたMPLSパケットの動作集約を決定するために、カプセル化されたIPv4またはIPv6ヘッダーのDSフィールドが使用される場合があります。 [RFC3270]は、Behavior Aggregateとその後のパケットの処理との関係を指定します。
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カプセル化を処理できる場合があります。
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.
セクション3で説明されているように、IANAは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-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., 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に設定する必要があります。MPLS-in-GREパケットにIPsecトランスポートモードが適用される場合、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隣接に配布してはなりません。 IPsecカプセル化なしでMPLSパケットを受信し、その最上位ラベルがこのセットにある場合、パケットを破棄する必要があります。
An IPsec-secured MPLS-in-IP or MPLS-in-GRE tunnel MUST provide authentication and integrity. (Note that the authentication and integrity will apply to the entire MPLS packet, including the MPLS label stack.) Thus, the implementation MUST support ESP will null encryption. ESP with encryption MAY be supported if a source requires confidentiality. If ESP is used, the tunnel tail MUST check that the source IP address of any packet received on a given SA is the one expected.
IPsecで保護されたIP-in-IPまたはMPLS-in-GREトンネルは、認証と整合性を提供する必要があります。 （認証と整合性は、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
鍵配布は、IKE [RFC2409]を使用して手動または自動で実行できます。 手動キーイングをサポートする必要があります。 自動キーイングが実装されている場合、事前共有キーを使用してメインモードのIKE
MUST be supported. A particular application may escalate this requirement and request implementation of automatic keying.
サポートする必要があります。 特定のアプリケーションがこの要件をエスカレートし、自動キーイングの実装を要求する場合があります。
Manual key distribution is much simpler, but also less scalable, than automatic key distribution. Therefore, which method of key distribution is appropriate for a particular tunnel has to be carefully considered by the administrator (or pair of administrators) responsible for the tunnel endpoints. If replay protection is regarded as necessary for a particular tunnel, automatic key distribution should be configured.
手動キー配布は、自動キー配布よりもはるかに簡単ですが、スケーラブルではありません。 したがって、特定のトンネルに適したキー配布方法は、トンネルエンドポイントを担当する管理者（または管理者のペア）によって慎重に検討する必要があります。 特定のトンネルでリプレイ保護が必要と見なされる場合、自動キー配布を設定する必要があります。
If the MPLS-in-IP encapsulation is being used, the selectors associated with the SA would be the source and destination addresses mentioned above, plus the IP protocol number specified in section 3. If it is desired to secure multiple MPLS-in-IP tunnels between a given pair of nodes separately, each tunnel must have unique pair of IP addresses.
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アドレスのペアが必要です。
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-GREのカプセル開放がパケットの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.
この仕様は、MPLSをIPにカプセル化する以前の作業（Tom Worster、Paul Doolan、Kasube Yasuhiro、Tom K.Johnson、Andrew G.Malis、およびRick Wilder）と、Yakov Rekhter、Daniel Tappanによる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]ポステル、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC792]ポステル、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。、ハンクス、S.、Meyer、D。、およびP. Traina、「Generic Routing Encapsulation（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 Label Switching Architecture」、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]ローゼン、E。、タッパン、D。、フェドルコウ、G。、レフター、Y。、ファリナッチ、D。、リー、T。、およびA.コンタ、「MPLSラベルスタックエンコーディング」、RFC 3032、2001年1月 。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]ケント、S。、およびR.アトキンソン、「インターネットプロトコルのセキュリティアーキテクチャ」、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]ケント、S。、およびR.アトキンソン、「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、「インターネットキーエクスチェンジ（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]ブレイク、S。、ブラック、D。、カールソン、M。、デイビス、E。、ワング、Z。、およびW.ワイス、「差別化されたサービスのためのアーキテクチャ」、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]ブラック、D。、「差別化されたサービスとトンネル」、RFC 2983、2000年10月。
[RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002.
[RFC3260]グロスマン、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、 "マルチプロトコルラベルスイッチング （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
メール：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. サニーベール、CA 94089
EMail: yakov@juniper.net
メール：yakov@juniper.net
Eric Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719
Eric Rosen Cisco Systems、Inc. 1414マサチューセッツアベニューBoxborough、MA 01719
EMail: erosen@cisco.com
メール：erosen@cisco.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、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開示のコピーおよび利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによる一般的なライセンスまたはそのような所有権の使用許可の取得を試みた結果を取得できます。 IETFオンラインIPRリポジトリ（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.
IETFは、この標準を実装するために必要な技術を対象とする著作権、特許、特許出願、またはその他の所有権に関心を寄せるよう、あらゆる利害関係者を招待します。 IETFのietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能の資金は、現在インターネット協会によって提供されています。