[要約] RFC 5566は、BGP IPsecトンネルカプセル化属性に関する仕様であり、BGPプロトコルを使用してIPsecトンネルの設定を自動化するための方法を提供します。このRFCの目的は、ネットワーク管理者がBGPを使用してIPsecトンネルを効率的に設定できるようにすることです。
Network Working Group L. Berger
Request for Comments: 5566 LabN
Category: Standards Track R. White
E. Rosen
Cisco Systems
June 2009
BGP IPsec Tunnel Encapsulation Attribute
BGP IPSECトンネルカプセル化属性
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) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Abstract
概要
The BGP Encapsulation Subsequent Address Family Identifier (SAFI) provides a method for the dynamic exchange of encapsulation information and for the indication of encapsulation protocol types to be used for different next hops. Currently, support for Generic Routing Encapsulation (GRE), Layer 2 Tunneling Protocol (L2TPv3), and IP in IP tunnel types are defined. This document defines support for IPsec tunnel types.
BGPカプセル化後のアドレスファミリ識別子（SAFI）は、カプセル化情報の動的交換と、異なる次のホップに使用されるカプセル化プロトコルタイプの指標の方法を提供します。現在、一般的なルーティングカプセル化（GRE）、レイヤー2トンネルプロトコル（L2TPV3）、およびIPトンネルタイプのIPのサポートが定義されています。このドキュメントでは、IPSECトンネルタイプのサポートを定義しています。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................2
2. Tunnel Encapsulation Types ......................................3
3. Use of IPsec Tunnel Types .......................................3
4. IPsec Tunnel Authenticator sub-TLV ..............................4
4.1. Use of the IPsec Tunnel Authenticator sub-TLV ..............5
5. Security Considerations .........................................5
6. IANA Considerations .............................................6
7. References ......................................................7
7.1. Normative References .......................................7
7.2. Informative References .....................................7
8. Acknowledgments .................................................8
The BGP [RFC4271] Encapsulation Subsequent Address Family Identifier (SAFI) allows for the communication of tunnel information and for the association of this information to a BGP next hop. The Encapsulation SAFI can be used to support the mapping of prefixes to next hops and tunnels of the same address family, IPv6 prefixes to IPv4 next hops and tunnels using [RFC4798], and IPv4 prefixes to IPv6 next hops and tunnels using [RFC5549]. The Encapsulation SAFI can also be used to support the mapping of VPN prefixes to tunnels when VPN prefixes are advertised per [RFC4364] or [RFC4659]. [RFC5565] provides useful context for the use of the Encapsulation SAFI.
BGP [RFC4271]カプセル化後のアドレスファミリ識別子（SAFI）により、トンネル情報の通信が可能になり、この情報とBGPの次のホップとの関連付けが可能になります。カプセル化Safiは、同じアドレスファミリの次のホップとトンネルへのプレフィックスのマッピング、[RFC4798]を使用してIPv4次のホップとトンネルへのIPv6プレフィックス、および[RFC5549]を使用してIPv6の次のホップとトンネルへのIPv4プレフィックスをサポートするために使用できます。カプセル化Safiは、VPNプレフィックスが[RFC4364]または[RFC4659]ごとに宣伝されている場合に、VPNプレフィックスのトンネルへのマッピングをサポートするためにも使用できます。[RFC5565]は、カプセル化Safiを使用するための有用なコンテキストを提供します。
The Encapsulation SAFI is defined in [RFC5512]. [RFC5512] also defines support for the GRE [RFC2784], L2TPv3 [RFC3931], and IP in IP [RFC2003] tunnel types. This document builds on [RFC5512] and defines support for IPsec tunnels. Support is defined for IP Authentication Header (AH) in tunnel mode [RFC4302] and for IP Encapsulating Security Payload (ESP) in tunnel mode [RFC4303]. The IPsec architecture is defined in [RFC4301]. Support for IP in IP [RFC2003] and MPLS-in-IP [RFC4023] protected by IPsec Transport Mode is also defined.
カプセル化Safiは[RFC5512]で定義されています。[RFC5512]は、GRE [RFC2784]、L2TPV3 [RFC3931]、およびIPのIP [RFC2003]トンネルタイプのサポートも定義しています。このドキュメントは[RFC5512]に基づいて構築され、IPSECトンネルのサポートを定義します。サポートは、トンネルモード[RFC4302]のIP認証ヘッダー（AH）およびトンネルモード[RFC4303]でのセキュリティペイロード（ESP）をカプセル化するIPについて定義されます。IPSECアーキテクチャは[RFC4301]で定義されています。IPSEC輸送モードで保護されたIP [RFC2003]およびMPLS-in-IP [RFC4023]のサポートも定義されています。
The Encapsulation Network Layer Reachability Information (NLRI) Format is not modified by this document.
カプセル化ネットワークレイヤーReachability情報（NLRI）形式は、このドキュメントによって変更されません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。
Per [RFC5512], tunnel type is indicated in the Tunnel Encapsulation attribute. This document defines the following tunnel type values:
[RFC5512]ごとに、トンネルのタイプはトンネルカプセル化属性に示されています。このドキュメントは、次のトンネルタイプの値を定義します。
- Transmit tunnel endpoint: Tunnel Type = 3
- トンネルエンドポイントを送信：トンネルタイプ= 3
- IPsec in Tunnel-mode: Tunnel Type = 4 [RFC4302], [RFC4303]
- トンネルモードのIPSEC：トンネルタイプ= 4 [RFC4302]、[RFC4303]
- IP in IP Tunnel with IPsec Transport Mode: Tunnel Type = 5 [RFC2003], [RFC4303]
- IPSEC輸送モードを備えたIPトンネルのIP：トンネルタイプ= 5 [RFC2003]、[RFC4303]
- MPLS-in-IP Tunnel with IPsec Transport Mode: Tunnel Type = 6 [RFC4023]
- IPSEC輸送モードを備えたMPLS-in-IPトンネル：トンネルタイプ= 6 [RFC4023]
Note, see Section 4.3 of [RFC5512] for a discussion on the advertisement and use of multiple tunnel types.
注、複数のトンネルタイプの広告と使用に関する議論については、[RFC5512]のセクション4.3を参照してください。
Note, the specification in [RFC4023] for MPLS-in-IP tunnels with IPsec Transport mode applies as well to IP in IP tunnels.
IPSECトランスポートモードを備えたMPLS-in-IPトンネルの[RFC4023]の仕様は、IPトンネルのIPにも適用されます。
This document does not specify the use of the sub-TLV types defined in [RFC5512] with these tunnel types. See below for the definition of a specific sub-TLV for use with the defined tunnel types.
このドキュメントでは、これらのトンネルタイプを使用して[RFC5512]で定義されたサブTLVタイプの使用を指定していません。定義されたトンネルタイプで使用する特定のサブTLVの定義については、以下を参照してください。
The IPsec tunnel types are defined above with the values 4, 5, and 6. If R1 is a BGP speaker that receives an Encapsulation SAFI update from another BGP speaker, R2, then if R1 has any data packets for which R2 is the BGP next hop, R1 MUST initiate an IPsec SA (security association) of the specified "tunnel type", and all such data packets MUST be sent through that SA.
IPSECトンネルタイプは、値4、5、および6で上記で定義されています。R1が別のBGPスピーカーR2からカプセル化SAFIアップデートを受信するBGPスピーカーの場合、R1が次にR2がBGPであるデータパケットを持っている場合HOP、R1は、指定された「トンネルタイプ」のIPSEC SA（セキュリティ協会）を開始する必要があり、そのようなデータパケットはすべてそのSAを介して送信する必要があります。
Let R1 and R2 be two BGP speakers that may send data packets through R3, such that the data packets from R1 and from R2 may be received by R3 over the same interface. In this case, when R3 sends an Encapsulation SAFI that indicates an IPsec tunnel type to R2, then R3 SHOULD also send an update specifying an Encapsulation SAFI with an IPsec tunnel type to R1. That is, on a given interface, if IPsec is required for any data packets, it SHOULD be required for all. This eliminates dependence on the IPsec selector mechanisms to correctly distinguish traffic that needs to be protected from traffic that does not.
R1とR2を2つのBGPスピーカーとし、R3を介してデータパケットを送信できるため、R1およびR2からデータパケットが同じインターフェイスでR3によって受信されます。この場合、R3がIPSECトンネルタイプをR2に示すカプセル化Safiを送信する場合、R3はIPSECトンネルタイプを持つカプセル化SafiをR1に指定する更新も送信する必要があります。つまり、特定のインターフェイスでは、データパケットにIPSECが必要な場合は、すべてに必要である必要があります。これにより、IPSECセレクターメカニズムへの依存性がなくなり、保護していないトラフィックから保護する必要があるトラフィックを正しく区別します。
Security policy has the granularity of BGP speaker to BGP speaker. The required security policies must be configured into the BGP speakers. Policies for each SA will typically be established using IKEv2 (Internet Key Exchange) [RFC4306], with either public-key or pre-shared key authentication. The SA MAY also be configured via manual techniques. Manual configuration specification and considerations are defined in [RFC4301], [RFC4302], and [RFC4303] (and includes keys, Security Parameter Index (SPI) numbers, IPsec protocol, integrity/encryption algorithms, and sequence number mode).
セキュリティポリシーには、BGPスピーカーのBGPスピーカーに対する粒度があります。必要なセキュリティポリシーは、BGPスピーカーに構成する必要があります。通常、各SAのポリシーは、IKEV2（Internet Key Exchange）[RFC4306]を使用して確立され、公開キーまたは事前共有キー認証を使用します。SAは、手動技術を介して構成することもできます。手動構成の仕様と考慮事項は、[RFC4301]、[RFC4302]、および[RFC4303]、および[RFC4303]で定義されています（キー、セキュリティパラメーターインデックス（SPI）番号、IPSECプロトコル、整合性/暗号化アルゴリズム、およびシーケンス番号モードを含む）。
This document defines a new sub-TLV for use with the Tunnel Encapsulation attribute defined in [RFC5512]. The new sub-TLV is referred to as the "IPsec Tunnel Authenticator sub-TLV", and one or more of the sub-TLVs MAY be included in any Encapsulation SAFI NLRI [RFC5512] indicating a tunnel type defined in this document. Support for the IPsec Tunnel Authenticator sub-TLV MUST be implemented whenever the tunnel types defined in this document are implemented. However, its use is OPTIONAL, and is a matter of policy.
このドキュメントでは、[RFC5512]で定義されているトンネルカプセル化属性で使用する新しいサブTLVを定義します。新しいサブTLVは「IPSEC Tunnel Authenticator Sub-TLV」と呼ばれ、1つ以上のサブTLVを、このドキュメントで定義されたトンネルタイプを示すカプセル化Safi NLRI [RFC5512]に含まれる場合があります。このドキュメントで定義されているトンネルタイプが実装されている場合は、IPSEC Tunnel Authenticator Sub-TLVのサポートを実装する必要があります。ただし、その使用はオプションであり、ポリシーの問題です。
The sub-TLV type of the IPsec Tunnel Authenticator sub-TLV is 3. The sub-TLV length is variable. The structure of the sub-TLV is as follows:
IPSECトンネルAuthenticator Sub-TLVのサブTLVタイプは3です。Sub-TLVの長さは可変です。Sub-TLVの構造は次のとおりです。
- Authenticator Type: two octets
- 認証器タイプ：2オクテット
This document defines authenticator type 1, "SHA-1 hash of public key", as defined in Section 3.7 of RFC 4306.
このドキュメントでは、RFC 4306のセクション3.7で定義されているように、認証機のタイプ1「公共鍵のSHA-1ハッシュ」を定義しています。
- Value: (variable)
- 値：（変数）
A value used to authenticate the BGP speaker that generated this NLRI. The length of this field is not encoded explicitly, but can be calculated as (sub-TLV length - 2).
このNLRIを生成したBGPスピーカーを認証するために使用される値。このフィールドの長さは明示的にエンコードされていませんが、（サブTLVの長さ-2）として計算できます。
In the case of authenticator type 1, this field contains the 20-octet value of the hash.
Authenticator Type 1の場合、このフィールドにはハッシュの20オクテット値が含まれています。
A BGP speaker that sends the IPsec Tunnel Authenticator sub-TLV with authenticator type 1 MUST be configured with a private key / public key pair, the public key being the key whose hash is sent in the value field of the sub-TLV. The BGP speaker MUST either (a) be able to generate a self-signed certificate for the public key, or else (b) be configured with a certificate for the public key.
Ipsec Tunnel Authenticator Sub-TLVをAuthenticator Type 1で送信するBGPスピーカーは、秘密キー /公開キーペアで構成する必要があります。公開キーは、サブTLVの値フィールドにハッシュが送信されるキーです。BGPスピーカーは、（a）公開キーの自己署名証明書を生成できるか、または（b）公開キーの証明書で構成されているかのいずれかでなければなりません。
When the IPsec Tunnel Authenticator sub-TLV is used, it is highly RECOMMENDED that the integrity of the BGP session itself be protected. This is usually done by using the TCP MD5 option [RFC2385].
IPSEC Tunnel Authenticator Sub-TLVを使用する場合、BGPセッション自体の完全性を保護することを強くお勧めします。これは通常、TCP MD5オプション[RFC2385]を使用して行われます。
If an IPsec Tunnel Authenticator sub-TLV with authenticator type 1 is present in the Encapsulation SAFI update, then R1 (as defined above in Section 3) MUST use IKEv2 [RFC4306] to obtain a certificate from R2 (as defined above in Section 3), and R2 MUST send a certificate for the public key whose hash occurred in the value field of the IPsec Tunnel Authenticator sub-TLV. R1 MUST NOT attempt to establish an SA to R2 UNLESS the public key in the certificate hashes to the same value that occurs in one of the IPsec Tunnel Authenticator sub-TLVs.
Authenticator Type 1を備えたIpsec Tunnel Authenticator Sub-TLVがカプセル化Safi Updateに存在する場合、R1（セクション3で上記で定義）を使用してIKEV2 [RFC4306]を使用してR2から証明書を取得する必要があります（セクション3で上記で定義）、およびR2は、IPSEC Tunnel Authenticator Sub-TLVの値フィールドでハッシュが発生した公開キーの証明書を送信する必要があります。R1は、証明書の公開キーがIPSECトンネル認証器サブTLVの1つで発生するのと同じ値にハッシュしない限り、R2にSAを確立しようとしてはなりません。
R2 MUST also perform the reciprocal processing. Specifically, when establishing an SA from R1 and R1 has advertised the IPsec Tunnel Authenticator sub-TLV with authenticator type 1, R2 MUST use IKEv2 [RFC4306] to obtain a certificate from R1, and R1 MUST send a certificate for the public key whose hash occurred in the value field of the IPsec Tunnel Authenticator sub-TLV. R2 MUST NOT attempt to establish an SA to R1 UNLESS the public key in the certificate hashes to the same value that occurs in one of the IPsec Tunnel Authenticator sub-TLVs.
R2は、相互処理も実行する必要があります。具体的には、R1とR1からSAを確立する場合、Authenticator Type 1を使用してIPSEC Tunnel Authenticator Sub-TLVを宣伝する場合、R2はIKEV2 [RFC4306]を使用してR1から証明書を取得する必要があり、R1はハッシュの公開キーの証明書を送信する必要があります。IPSEC Tunnel Authenticator Sub-TLVの値フィールドで発生しました。R2は、証明書の公開キーがIPSec Tunnel Authenticator Sub-TLVのいずれかで発生するのと同じ値にハッシュしない限り、R1にSAを確立しようとしてはなりません。
Note that the "Transmit tunnel endpoint" tunnel type (value = 3) may be used by a BGP speaker that does not want to be the receiving endpoint of an IPsec tunnel but only the transmitting endpoint.
「送信トンネルエンドポイント」トンネルタイプ（値= 3）は、IPSECトンネルの受信エンドポイントになりたくないが送信エンドポイントのみになりたくないBGPスピーカーが使用できることに注意してください。
This document uses IP-based tunnel technologies to support data plane transport. Consequently, the security considerations of those tunnel technologies apply. This document defines support for IPsec AH [RFC4302] and ESP [RFC4303]. The security considerations from those documents as well as [RFC4301] apply to the data plane aspects of this document.
このドキュメントでは、IPベースのトンネルテクノロジーを使用して、データプレーントランスポートをサポートしています。その結果、これらのトンネル技術のセキュリティ上の考慮事項が適用されます。このドキュメントは、IPSEC AH [RFC4302]およびESP [RFC4303]のサポートを定義しています。これらのドキュメントからのセキュリティ上の考慮事項と[RFC4301]は、このドキュメントのデータプレーンの側面に適用されます。
As with [RFC5512], any modification of the information that is used to form encapsulation headers, to choose a tunnel type, or to choose a particular tunnel for a particular payload type may lead to user data packets getting misrouted, misdelivered, and/or dropped. Misdelivery is less of an issue when IPsec is used, as such misdelivery is likely to result in a failure of authentication or decryption at the receiver. Furthermore, in environments where authentication of BGP speakers is desired, the IPsec Tunnel Authenticator sub-TLV defined in Section 4 may be used.
[RFC5512]と同様に、カプセル化ヘッダーを形成したり、トンネルタイプを選択したり、特定のペイロードタイプの特定のトンネルを選択したりするために使用される情報を変更すると、ユーザーデータパケットが誤って誤って装備され、誤った装備されている、および/または落とされた。IPSECが使用される場合、誤配信は問題ではありません。そのような誤配達は、受信者で認証または復号化の障害になる可能性が高いためです。さらに、BGPスピーカーの認証が必要な環境では、セクション4で定義されたIPSECトンネル認証装置のサブTLVを使用できます。
More broadly, the security considerations for the transport of IP reachability information using BGP are discussed in [RFC4271] and [RFC4272], and are equally applicable for the extensions described in this document.
より広く言えば、BGPを使用したIPリーチ可能性情報の輸送に関するセキュリティ上の考慮事項は、[RFC4271]および[RFC4272]で説明されており、このドキュメントで説明されている拡張機能に等しく適用できます。
If the integrity of the BGP session is not itself protected, then an imposter could mount a denial-of-service attack by establishing numerous BGP sessions and forcing an IPsec SA to be created for each one. However, as such an imposter could wreak havoc on the entire routing system, this particular sort of attack is probably not of any special importance.
BGPセッションの整合性自体が保護されていない場合、詐欺師は、多数のBGPセッションを確立し、それぞれにIPSEC SAを作成することにより、サービス拒否攻撃を行う可能性があります。しかし、そのため、詐欺師はルーティングシステム全体に大混乱をもたらす可能性があるため、この特定の攻撃はおそらく特に重要ではありません。
It should be noted that a BGP session may itself be transported over an IPsec tunnel. Such IPsec tunnels can provide additional security to a BGP session. The management of such IPsec tunnels is outside the scope of this document.
BGPセッション自体がIPSECトンネル上に輸送される可能性があることに注意する必要があります。このようなIPSECトンネルは、BGPセッションに追加のセキュリティを提供できます。このようなIPSECトンネルの管理は、このドキュメントの範囲外です。
IANA administers the assignment of new namespaces and new values for namespaces defined in this document and reviewed in this section.
IANAは、このドキュメントで定義され、このセクションでレビューされた新しい名前空間の割り当てと新しい値の新しい値を管理します。
IANA has made the following assignments in the "BGP Tunnel Encapsulation Attribute Tunnel Types" registry.
IANAは、「BGPトンネルカプセル化属性トンネルタイプ」レジストリで次の割り当てを行いました。
Value Name Reference
----- ---- ---------
3 Transmit tunnel endpoint [RFC5566]
4 IPsec in Tunnel-mode [RFC5566]
トンネルモードの4 IPSEC [RFC5566]
5 IP in IP tunnel with IPsec Transport Mode [RFC5566]
5 IPSEC輸送モードを備えたIPトンネルのIP [RFC5566]
6 MPLS-in-IP tunnel with IPsec Transport Mode [RFC5566]
IPSEC輸送モードを備えた6 MPLS-in-IPトンネル[RFC5566]
IANA has made the following assignment in the "BGP Tunnel Encapsulation Attribute Sub-TLVs" registry.
IANAは、「BGPトンネルカプセル化属性サブTLV」レジストリで次の割り当てを行いました。
Value Name Reference
----- ---- ---------
3 IPsec Tunnel Authenticator [RFC5566]
[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月。
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271] Rekhter、Y.、Ed。、Li、T.、ed。、およびS. Hares、ed。、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302] Kent、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロード（ESP）」、RFC 4303、2005年12月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306] Kaufman、C.、ed。、「Internet Key Exchange（IKEV2）Protocol」、RFC 4306、2005年12月。
[RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute", RFC 5512, April 2009.
[RFC5512] Mohapatra、P。およびE. Rosen、「BGPカプセル化後のアドレスファミリー識別子（SAFI）およびBGPトンネルカプセル化属性」、RFC 5512、2009年4月。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003] Perkins、C。、「IP内のIPカプセル化」、RFC 2003、1996年10月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385] Heffernan、A。、「TCP MD5署名オプションによるBGPセッションの保護」、RFC 2385、1998年8月。
[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月。
[RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[RFC3931] Lau、J.、ed。、Ed。、Townsley、M.、ed。、およびI. Goyret、ed。、「レイヤー2トンネリングプロトコル - バージョン3（L2TPV3）」、RFC 3931、2005年3月。
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005.
[RFC4023] Worster、T.、Rekhter、Y.、およびE. Rosen、ed。、「IPまたは汎用ルーティングカプセル化（GRE）のMPLのカプセル化」、RFC 4023、2005年3月。
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, January 2006.
[RFC4272] Murphy、S。、「BGP Security脆弱性分析」、RFC 4272、2006年1月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364] Rosen、E。およびY. Rekhter、「BGP/MPLS IP仮想プライベートネットワーク（VPNS）」、RFC 4364、2006年2月。
[RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, "BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN", RFC 4659, September 2006.
[RFC4659] De Clercq、J.、Ooms、D.、Carugi、M。、およびF. Le Faucheur、「BGP-MPLS IP仮想プライベートネットワーク（VPN）IPv6 VPNの拡張」、RFC 4659、2006年9月。
[RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)", RFC 4798, February 2007.
[RFC4798] de Clercq、J.、Ooms、D.、Prevost、S。、およびF. Le Faucheur、「IPv6プロバイダーエッジルーター（6PE）を使用してIPv6 MPLSを介してIPv6島を接続する」、RFC 4798、2007年2月。
[RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop", RFC 5549, May 2009.
[RFC5549] Le Faucheur、F。およびE. Rosen、「IPv4 Netword Reaginability情報をIPv6 Next Hopで広告する」、RFC 5549、2009年5月。
[RFC5565] Wu, J., Cui, Y., Metz, C. and E. Rosen, "Softwire Mesh Framework", RFC 5565, June 2009.
[RFC5565] Wu、J.、Cui、Y.、Metz、C。、およびE. Rosen、「Softwire Mesh Framework」、RFC 5565、2009年6月。
The authors wish to thank Sam Hartman and Tero Kivinen for their help with the security-related issues.
著者は、セキュリティ関連の問題を支援してくれたサムハートマンとテロキビネンに感謝したいと考えています。
Authors' Addresses
著者のアドレス
Lou Berger LabN Consulting, L.L.C. Phone: +1-301-468-9228 EMail: lberger@labn.net
Lou Berger Labn Consulting、L.L.C。電話：1-301-468-9228メール：lberger@labn.net
Russ White Cisco Systems EMail: riw@cisco.com
Russ White Cisco Systems Email：riw@cisco.com
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA, 01719 EMail: erosen@cisco.com
Eric C. Rosen Cisco Systems、Inc。1414 Massachusetts Avenue Boxborough、MA、01719メール：erosen@cisco.com