Network Working Group L. Berger
Request for Comments: 5566 LabN
Category: Standards Track R. White
E. Rosen
Cisco Systems
June 2009
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.
版权所有（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和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
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-in-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
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]将IPv6前缀映射到IPv4下一个跃点和隧道，使用[RFC5549]将IPv4前缀映射到IPv6下一个跃点和隧道。当根据[RFC4364]或[RFC4659]公布VPN前缀时，封装SAFI还可用于支持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[RFC2003]隧道类型中的IP的支持。本文档以[RFC5512]为基础，定义了对IPsec隧道的支持。定义了对隧道模式[RFC4302]中的IP认证头（AH）和隧道模式[RFC4303]中的IP封装安全有效负载（ESP）的支持。IPsec体系结构在[RFC4301]中定义。还定义了对受IPsec传输模式保护的IP[RFC2003]中的IP和IP[RFC4023]中的MPLS的支持。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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传输模式的IP隧道中的MPLS：隧道类型=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.
注意，[RFC4023]中关于具有IPsec传输模式的IP隧道中的MPLS的规范也适用于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下一跳的任何数据包，则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为两个BGP扬声器，可通过R3发送数据包，以便R3可通过同一接口接收来自R1和R2的数据包。在这种情况下，当R3向R2发送指示IPsec隧道类型的封装SAFI时，R3还应向R1发送指定具有IPsec隧道类型的封装SAFI的更新。也就是说，在给定的接口上，如果任何数据包都需要IPsec，那么所有数据包都应该需要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.
本文档定义了一个新的子TLV，用于[RFC5512]中定义的隧道封装属性。新的子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类型为3。子TLV长度是可变的。子TLV的结构如下所示：
- Authenticator Type: two octets
- 验证器类型：两个八位字节
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.
如果封装SAFI更新中存在验证器类型为1的IPsec隧道验证器子TLV，则R1（如上文第3节所定义）必须使用IKEv2[RFC4306]从R2（如上文第3节所定义）获取证书，R2必须为公钥发送证书，该公钥的哈希值出现在IPsec隧道身份验证子TLV的值字段中。R1不得尝试将SA建立到R2，除非证书中的公钥散列到IPsec隧道身份验证子TLV之一中出现的相同值。
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建立SA并且R1已通告具有验证器类型1的IPsec隧道验证器子TLV时，R2必须使用IKEv2[RFC4306]从R1获取证书，并且R1必须发送公钥的证书，该公钥的哈希出现在IPsec隧道验证器子TLV的值字段中。R2不得尝试将SA建立到R1，除非证书中的公钥散列到IPsec隧道身份验证子TLV中出现的相同值。
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]
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传输模式的IP隧道中的5 IP[RFC5566]
6 MPLS-in-IP tunnel with IPsec Transport Mode [RFC5566]
采用IPsec传输模式的IP隧道中的6个MPLS[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]
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.，“边境网关协议4（BGP-4）”，RFC 42712006年1月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]Kent，S.，“IP认证头”，RFC43022005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]考夫曼，C.，编辑，“互联网密钥交换（IKEv2）协议”，RFC4306，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]Farinaci，D.，Li，T.，Hanks，S.，Meyer，D.，和P.Traina，“通用路由封装（GRE）”，RFC 27842000年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.，Townsley，M.，Ed.，和I.Goyret，Ed.，“第二层隧道协议-版本3（L2TPv3）”，RFC 39312005年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，编辑，“在IP或通用路由封装（GRE）中封装MPLS”，RFC4023，2005年3月。
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, January 2006.
[RFC4272]Murphy，S.，“BGP安全漏洞分析”，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虚拟专用网络（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]De Clercq，J.，Ooms，D.，Carugi，M.，和F.Le Faucheur，“用于IPv6 VPN的BGP-MPLS IP虚拟专用网络（VPN）扩展”，RFC 46592006年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）通过IPv4 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，“通过IPv6下一跳来宣传IPv4网络层可达性信息”，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，“软线网格框架”，RFC 55652009年6月。
The authors wish to thank Sam Hartman and Tero Kivinen for their help with the security-related issues.
作者希望感谢Sam Hartman和Tero Kivinen在安全相关问题上提供的帮助。
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电子邮件：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号，邮编01719电子邮件：erosen@cisco.com