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
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.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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）のサポートは、IPトンネルタイプのレイヤ2トンネリングプロトコル（L2TPv3の）、および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は、IPv4にIPv6プレフィックス[RFC4798]を使用して次のホップとトンネル、およびIPv4のプレフィックスは[RFC5549]を使用して次のホップとトンネルIPv6へ、同じアドレスファミリーの次ホップとトンネルにプレフィックスのマッピングをサポートするために使用することができます。カプセル化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トンネルのサポートを定義します。支持体は、トンネルモードでIP認証ヘッダ（AH）[RFC4302]のために、トンネルモードでIPカプセル化セキュリティペイロード（ESP）[RFC4303]のために定義されています。 IPsecのアーキテクチャは、[RFC4301]で定義されています。 IP [RFC2003]とMPLS-で-IPのIPsecトランスポートモードにより保護[RFC4023]でIPのサポートも定義されています。
The Encapsulation Network Layer Reachability Information (NLRI) Format is not modified by this document.
カプセル化ネットワーク層到達可能性情報（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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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]
トンネルタイプ= 5 [RFC2003]、[RFC4303]： - IPsecのトランスポートモードとIPトンネル内のIP
- MPLS-in-IP Tunnel with IPsec Transport Mode: Tunnel Type = 6 [RFC4023]
トンネル型= 6 [RFC4023]： - IPsecのトランスポートモードとMPLSインIPトンネル
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.
IPトンネル内のIPにも同様に適用される、のIPsecトランスポート・モードとMPLSインIPトンネルの[RFC4023]の指定に注意してください。
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.
R1は、別のBGPスピーカ、R2からカプセル化SAFI更新を受信するBGPスピーカである場合、IPsecトンネルタイプは値4,5を有する上記で定義され、及び6れる、次にR1はR2は次BGPされた任意のデータパケットを有する場合ホップは、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はR1からR2とからのデータ・パケットは同じインターフェースを介してR3によって受信することができるように、R3を介してデータパケットを送信することができる2つのBGPスピーカとします。 R3はR2へのIPsecトンネルタイプを示すカプセル化SAFIを送信した場合この場合、その後R3はまた、R1へのIPsecトンネルタイプにカプセル化SAFIを指定更新を送信すべきです。すなわち、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
セキュリティポリシーは、BGPスピーカへのBGPスピーカの粒度を持っています。必要なセキュリティポリシーは、BGPスピーカに設定する必要があります。各SAのポリシーは、一般的に使用して確立されます
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).
公開鍵または事前共有鍵認証のいずれかとのIKEv2（インターネット鍵交換）[RFC4306]、。 SAはまた、手動技術を介して構成することができます。手動構成仕様と考察は、[RFC4301]、[RFC4302]及び[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トンネル認証サブTLV」と呼ばれ、サブのTLVの一つ以上は、この文書で定義されたトンネルタイプを示す任意のカプセル化SAFI NLRI [RFC5512]に含まれるかもしれ。この文書で定義されたトンネルタイプが実装されるたびにIPsecトンネル認証サブ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トンネル認証サブTLVのサブTLVのタイプは、サブTLVの長さが可変である3です。次のようにサブ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.
オーセンティケータタイプ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.
オーセンティケータタイプ1とIPsecトンネル認証サブTLVを送信する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トンネル認証サブ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.
オーセンティケータタイプ1とIPsecトンネル認証サブTLVは、カプセル化SAFI更新中に存在する場合、R1（第3節において上記に定義した通り）（セクション3で上記で定義した通り）R2から証明書を取得するためのIKEv2 [RFC4306]を使用しなければなりません、及びR2は、ハッシュIPsecトンネル認証サブTLVの値フィールドで発生した公開鍵の証明書を送信しなければなりません。 R1は、IPsecトンネル認証サブのTLVのいずれかで発生し、同じ値に証明書ハッシュ内の公開鍵がない限り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を確立する際、具体的に、オーセンティケータタイプ1とIPsecトンネル認証サブTLVアドバタイズた、R2はR1から証明書を取得するためのIKEv2 [RFC4306]を使用しなければならない、そしてR1は、そのハッシュの公開鍵のための証明書を送信しなければなりませんIPsecトンネル認証サブTLVの値フィールドで発生しました。 R2は、IPsecトンネル認証サブの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]
IPsecのトランスポートモード[RFC5566]とのIPトンネルで5 IP
6 MPLS-in-IP tunnel with IPsec Transport Mode [RFC5566]
IPsecのトランスポートモード[RFC5566]と6 MPLSインIPトンネル
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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、エド。、李、T.、エド。、およびS.野兎、編、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 4271、2006年1月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]ケント、S.、 "IP認証ヘッダー"、RFC 4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]カウフマン、C.、エド。、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、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.ローゼン、 "BGPカプセル化次のアドレスファミリ識別子（SAFI）及びBGPトンネルカプセル化属性"、RFC 5512、2009年4月。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003]パーキンス、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]ファリナッチ、D.、李、T.、ハンクス、S.、マイヤー、D.、およびP. Trainaの、 "総称ルーティングカプセル化（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]ラウ、J.、エド、Townsley、M.、エド、およびI. Goyret、エド、 "レイヤ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.ローゼン、編、 "IP又は総称ルーティングカプセル化（GRE）でMPLSカプセル化"、RFC 4023、2005年3月。
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, January 2006.
[RFC4272]マーフィー、S.、 "BGPセキュリティの脆弱性分析"、RFC 4272、2006年1月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]ローゼン、E.およびY. Rekhter、 "BGP / MPLS IP仮想プライベートネットワーク（VPN）"、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]デClercq、J.、Ooms、D.、Carugi、M.、およびF.ル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]デClercq、J.、Ooms、D.、プレボ、S.、およびF.ルFaucheur、 "IPv6のプロバイダエッジルータを使用したIPv4 MPLS上のIPv6諸島接続（6PE）"、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]ルFaucheur、F.とE.ローゼン、 "IPv6のネクストホップと広告のIPv4ネットワーク層到達可能性情報"、RFC 5549、2009年5月。
[RFC5565] Wu, J., Cui, Y., Metz, C. and E. Rosen, "Softwire Mesh Framework", RFC 5565, June 2009.
[RFC5565]呉、J.、キュイ、Y.、メス、C.およびE.ローゼン、 "Softwireメッシュフレームワーク"、RFC 5565、2009年6月。
The authors wish to thank Sam Hartman and Tero Kivinen for their help with the security-related issues.
著者は、セキュリティ関連の問題で彼らの助けのためのサム・ハートマンとTERO Kivinenに感謝したいです。
Authors' Addresses
著者のアドレス
Lou Berger LabN Consulting, L.L.C. Phone: +1-301-468-9228 EMail: lberger@labn.net
ルー・バーガーLabNコンサルティング、L.L.C.電話：+ 1-301-468-9228 Eメール：lberger@labn.net
Russ White Cisco Systems EMail: riw@cisco.com
ラスホワイトシスコシステムズ電子メール：riw@cisco.com
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA, 01719 EMail: erosen@cisco.com
エリックC.ローゼンシスコシステムズ株式会社1414年マサチューセッツアベニューボックスボロー、MA、01719 Eメール：erosen@cisco.com