Internet Engineering Task Force (IETF) X. Xu
Request for Comments: 7814 Huawei Technologies
Category: Informational C. Jacquenet
ISSN: 2070-1721 Orange
R. Raszuk
T. Boyes
Bloomberg LP
B. Fee
Extreme Networks
March 2016
Internet Engineering Task Force (IETF) X. Xu
Request for Comments: 7814 Huawei Technologies
Category: Informational C. Jacquenet
ISSN: 2070-1721 Orange
R. Raszuk
T. Boyes
Bloomberg LP
B. Fee
Extreme Networks
March 2016
Virtual Subnet: A BGP/MPLS IP VPN-Based Subnet Extension Solution
虚拟子网：一种基于BGP/MPLS IP VPN的子网扩展解决方案
Abstract
摘要
This document describes a BGP/MPLS IP VPN-based subnet extension solution referred to as "Virtual Subnet", which can be used for building Layer 3 network virtualization overlays within and/or between data centers.
本文档介绍了一种基于BGP/MPLS IP VPN的子网扩展解决方案，称为“虚拟子网”，可用于在数据中心内和/或数据中心之间构建第3层网络虚拟化覆盖。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7814.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7814.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Solution Description . . . . . . . . . . . . . . . . . . . . 5
3.1. Unicast . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1. Intra-subnet Unicast . . . . . . . . . . . . . . . . 5
3.1.2. Inter-subnet Unicast . . . . . . . . . . . . . . . . 6
3.2. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3. Host Discovery . . . . . . . . . . . . . . . . . . . . . 9
3.4. ARP/ND Proxy . . . . . . . . . . . . . . . . . . . . . . 9
3.5. Host Mobility . . . . . . . . . . . . . . . . . . . . . . 9
3.6. Forwarding Table Scalability on Data-Center Switches . . 10
3.7. ARP/ND Cache Table Scalability on Default Gateways . . . 10
3.8. ARP/ND and Unknown Unicast Flood Avoidance . . . . . . . 10
3.9. Path Optimization . . . . . . . . . . . . . . . . . . . . 10
4. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Non-support of Non-IP Traffic . . . . . . . . . . . . . . 11
4.2. Non-support of IP Broadcast and Link-Local Multicast . . 11
4.3. TTL and Traceroute . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Normative References . . . . . . . . . . . . . . . . . . 12
6.2. Informative References . . . . . . . . . . . . . . . . . 13
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Solution Description . . . . . . . . . . . . . . . . . . . . 5
3.1. Unicast . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1. Intra-subnet Unicast . . . . . . . . . . . . . . . . 5
3.1.2. Inter-subnet Unicast . . . . . . . . . . . . . . . . 6
3.2. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3. Host Discovery . . . . . . . . . . . . . . . . . . . . . 9
3.4. ARP/ND Proxy . . . . . . . . . . . . . . . . . . . . . . 9
3.5. Host Mobility . . . . . . . . . . . . . . . . . . . . . . 9
3.6. Forwarding Table Scalability on Data-Center Switches . . 10
3.7. ARP/ND Cache Table Scalability on Default Gateways . . . 10
3.8. ARP/ND and Unknown Unicast Flood Avoidance . . . . . . . 10
3.9. Path Optimization . . . . . . . . . . . . . . . . . . . . 10
4. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Non-support of Non-IP Traffic . . . . . . . . . . . . . . 11
4.2. Non-support of IP Broadcast and Link-Local Multicast . . 11
4.3. TTL and Traceroute . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Normative References . . . . . . . . . . . . . . . . . . 12
6.2. Informative References . . . . . . . . . . . . . . . . . 13
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
For business continuity purposes, Virtual Machine (VM) migration across data centers is commonly used in situations such as data-center maintenance, migration, consolidation, expansion, or disaster avoidance. The IETF community has recognized that IP renumbering of servers (i.e., VMs) after the migration is usually complex and costly. To allow the migration of a VM from one data center to another without IP renumbering, the subnet on which the VM resides needs to be extended across these data centers.
出于业务连续性目的，跨数据中心的虚拟机（VM）迁移通常用于数据中心维护、迁移、整合、扩展或灾难避免等情况。IETF社区已经认识到，迁移后服务器（即VM）的IP重新编号通常是复杂和昂贵的。要允许虚拟机从一个数据中心迁移到另一个数据中心而无需重新编号，需要在这些数据中心之间扩展虚拟机所在的子网。
To achieve subnet extension across multiple cloud data centers in a scalable way, the following requirements and challenges must be considered:
要以可扩展的方式实现跨多个云数据中心的子网扩展，必须考虑以下要求和挑战：
a. VPN Instance Space Scalability: In a modern cloud data-center environment, thousands or even tens of thousands of tenants could be hosted over a shared network infrastructure. For security and performance isolation purposes, these tenants need to be isolated from one another.
a. VPN实例空间可扩展性：在现代云数据中心环境中，数千甚至数万租户可以通过共享网络基础设施托管。出于安全和性能隔离的目的，这些租户需要彼此隔离。
b. Forwarding Table Scalability: With the development of server virtualization technologies, it's not uncommon for a single cloud data center to contain millions of VMs. This number already implies a big challenge to the forwarding table scalability of data-center switches. Provided multiple data centers of such scale were interconnected at Layer 2, this challenge would become even worse.
b. 转发表可扩展性：随着服务器虚拟化技术的发展，单个云数据中心包含数百万虚拟机的情况并不少见。这个数字已经对数据中心交换机的转发表可伸缩性提出了巨大挑战。如果多个如此规模的数据中心在第2层互连，这一挑战将变得更加严峻。
c. ARP/ND Cache Table Scalability: [RFC6820] notes that the Address Resolution Protocol (ARP) / Neighbor Discovery (ND) cache tables maintained by default gateways within cloud data centers can raise scalability issues. Therefore, mastering the size of the ARP/ND cache tables is critical as the number of data centers to be connected increases.
c. ARP/ND缓存表可伸缩性：[RFC6820]注意，由云数据中心内默认网关维护的地址解析协议（ARP）/邻居发现（ND）缓存表可能会引发可伸缩性问题。因此，随着要连接的数据中心数量的增加，掌握ARP/ND缓存表的大小至关重要。
d. ARP/ND and Unknown Unicast Flooding: It's well-known that the flooding of ARP/ND broadcast/multicast messages as well as unknown unicast traffic within large Layer 2 networks is likely to affect network and host performance. When multiple data centers that each host millions of VMs are interconnected at Layer 2, the impact of such flooding would become even worse. As such, it becomes increasingly important to avoid the flooding of ARP/ND broadcast/multicast as well as unknown unicast traffic across data centers.
d. ARP/ND和未知单播泛洪：众所周知，ARP/ND广播/多播消息以及大型第2层网络中未知单播流量的泛洪可能会影响网络和主机性能。当多个数据中心在第2层相互连接，每个中心承载数百万个虚拟机时，这种洪水的影响将变得更加严重。因此，避免ARP/ND广播/多播以及数据中心未知的单播流量泛滥变得越来越重要。
e. Path Optimization: A subnet usually indicates a location in the network. However, when a subnet has been extended across multiple geographically dispersed data-center locations, the location semantics of such a subnet is not retained any longer. As a result, traffic exchanged between a specific user and a server that would be located in different data centers may first be forwarded through a third data center. This suboptimal routing would obviously result in unnecessary consumption of the bandwidth resources between data centers. Furthermore, in the case where traditional Virtual Private LAN Service (VPLS) technology [RFC4761] [RFC4762] is used for data-center interconnect, return traffic from a server may be forwarded to a default gateway located in a different data center due to the configuration of a virtual router redundancy group. This suboptimal routing would also unnecessarily consume the bandwidth resources between data centers.
e. 路径优化：子网通常表示网络中的位置。但是，如果子网已扩展到多个地理位置分散的数据中心位置，则不再保留此类子网的位置语义。结果，特定用户和将位于不同数据中心的服务器之间交换的通信量可以首先通过第三数据中心转发。这种次优路由显然会导致数据中心之间不必要的带宽资源消耗。此外，在传统虚拟专用LAN服务（VPLS）技术[RFC4761][RFC4762]用于数据中心互连的情况下，由于虚拟路由器冗余组的配置，来自服务器的返回流量可转发到位于不同数据中心的默认网关。这种次优路由也会不必要地消耗数据中心之间的带宽资源。
This document describes a BGP/MPLS IP VPN-based subnet extension solution referred to as "Virtual Subnet", which can be used for data-center interconnection while addressing all of the aforementioned requirements and challenges. Here, the BGP/MPLS IP VPN means both BGP/MPLS IPv4 VPN [RFC4364] and BGP/MPLS IPv6 VPN [RFC4659]. In addition, since Virtual Subnet is built mainly on proven technologies such as BGP/MPLS IP VPN and ARP/ND proxy [RFC925] [RFC1027] [RFC4389], those service providers that provide Infrastructure as a Service (IaaS) cloud services can rely upon their existing BGP/MPLS IP VPN infrastructure and take advantage of their BGP/MPLS VPN operational experience to interconnect data centers.
本文档描述了一种基于BGP/MPLS IP VPN的子网扩展解决方案，称为“虚拟子网”，可用于数据中心互连，同时满足上述所有要求和挑战。这里，BGP/MPLS IP VPN指的是BGP/MPLS IPv4 VPN[RFC4364]和BGP/MPLS IPv6 VPN[RFC4659]。此外，由于虚拟子网主要基于经验证的技术构建，如BGP/MPLS IP VPN和ARP/ND代理[RFC925][RFC1027][RFC4389]，因此提供基础设施即服务（IaaS）的服务提供商云服务可以依赖其现有的BGP/MPLS IP VPN基础设施，并利用其BGP/MPLS VPN运营经验互连数据中心。
Although Virtual Subnet is described in this document as an approach for data-center interconnection, it can be used within data centers as well.
尽管本文档将虚拟子网描述为数据中心互连的一种方法，但它也可以在数据中心内使用。
Note that the approach described in this document is not intended to achieve an exact emulation of Layer 2 connectivity, and therefore it can only support a restricted Layer 2 connectivity service model with limitations that are discussed in Section 4. The discussion about where this service model can apply is outside the scope of this document.
请注意，本文档中描述的方法并非旨在实现第2层连接的精确模拟，因此它只能支持第4节中讨论的受限第2层连接服务模型。关于此服务模型可应用于何处的讨论超出了本文档的范围。
This memo makes use of the terms defined in [RFC4364].
本备忘录使用了[RFC4364]中定义的术语。
+--------------------+
+------------------+ | | +------------------+
|VPN_A:192.0.2.1/24| | | |VPN_A:192.0.2.1/24|
| \ | | | | / |
| +------+ \ ++---+-+ +-+---++/ +------+ |
| |Host A+-----+ PE-1 | | PE-2 +----+Host B| |
| +------+\ ++-+-+-+ +-+-+-++ /+------+ |
| 192.0.2.2/24 | | | | | | 192.0.2.3/24 |
| | | | | | | |
| DC West | | | IP/MPLS Backbone | | | DC East |
+------------------+ | | | | +------------------+
| +--------------------+ |
| |
VRF_A : V VRF_A : V
+------------+---------+--------+ +------------+---------+--------+
| Prefix |Next hop |Protocol| | Prefix |Next hop |Protocol|
+------------+---------+--------+ +------------+---------+--------+
|192.0.2.1/32|127.0.0.1| Direct | |192.0.2.1/32|127.0.0.1| Direct |
+------------+---------+--------+ +------------+---------+--------+
|192.0.2.2/32|192.0.2.2| Direct | |192.0.2.2/32| PE-1 | IBGP |
+------------+---------+--------+ +------------+---------+--------+
|192.0.2.3/32| PE-2 | IBGP | |192.0.2.3/32|192.0.2.3| Direct |
+------------+---------+--------+ +------------+---------+--------+
|192.0.2.0/24|192.0.2.1| Direct | |192.0.2.0/24|192.0.2.1| Direct |
+------------+---------+--------+ +------------+---------+--------+
+--------------------+
+------------------+ | | +------------------+
|VPN_A:192.0.2.1/24| | | |VPN_A:192.0.2.1/24|
| \ | | | | / |
| +------+ \ ++---+-+ +-+---++/ +------+ |
| |Host A+-----+ PE-1 | | PE-2 +----+Host B| |
| +------+\ ++-+-+-+ +-+-+-++ /+------+ |
| 192.0.2.2/24 | | | | | | 192.0.2.3/24 |
| | | | | | | |
| DC West | | | IP/MPLS Backbone | | | DC East |
+------------------+ | | | | +------------------+
| +--------------------+ |
| |
VRF_A : V VRF_A : V
+------------+---------+--------+ +------------+---------+--------+
| Prefix |Next hop |Protocol| | Prefix |Next hop |Protocol|
+------------+---------+--------+ +------------+---------+--------+
|192.0.2.1/32|127.0.0.1| Direct | |192.0.2.1/32|127.0.0.1| Direct |
+------------+---------+--------+ +------------+---------+--------+
|192.0.2.2/32|192.0.2.2| Direct | |192.0.2.2/32| PE-1 | IBGP |
+------------+---------+--------+ +------------+---------+--------+
|192.0.2.3/32| PE-2 | IBGP | |192.0.2.3/32|192.0.2.3| Direct |
+------------+---------+--------+ +------------+---------+--------+
|192.0.2.0/24|192.0.2.1| Direct | |192.0.2.0/24|192.0.2.1| Direct |
+------------+---------+--------+ +------------+---------+--------+
Figure 1: Intra-subnet Unicast Example
图1：子网内单播示例
As shown in Figure 1, two hosts (i.e., Hosts A and B) belonging to the same subnet (i.e., 192.0.2.0/24) are located in different data centers (i.e., DC West and DC East), respectively. PE routers (i.e., PE-1 and PE-2) that are used for interconnecting these two data centers create host routes for their own local hosts respectively and then advertise these routes by means of the BGP/MPLS IP VPN signaling. Meanwhile, an ARP proxy is enabled on Virtual Routing and Forwarding (VRF) attachment circuits of these PE routers.
如图1所示，属于同一子网（即192.0.2.0/24）的两台主机（即主机A和主机B）分别位于不同的数据中心（即DC West和DC East）。用于互连这两个数据中心的PE路由器（即PE-1和PE-2）分别为其本地主机创建主机路由，然后通过BGP/MPLS IP VPN信令发布这些路由。同时，在这些PE路由器的虚拟路由和转发（VRF）连接电路上启用ARP代理。
Let's now assume that Host A sends an ARP request for Host B before communicating with Host B. Upon receiving the ARP request, PE-1 acting as an ARP proxy returns its own MAC address as a response. Host A then sends IP packets for Host B to PE-1. PE-1 tunnels such packets towards PE-2, which in turn forwards them to Host B. Thus,
现在假设主机A在与主机B通信之前向主机B发送ARP请求。收到ARP请求后，作为ARP代理的PE-1将返回自己的MAC地址作为响应。然后，主机A向PE-1发送主机B的IP数据包。PE-1将这些数据包传输到PE-2，PE-2将它们转发给主机B。因此，
Hosts A and B can communicate with each other as if they were located within the same subnet.
主机A和B可以彼此通信，就像它们位于同一子网中一样。
+--------------------+
+------------------+ | | +------------------+
|VPN_A:192.0.2.1/24| | | |VPN_A:192.0.2.1/24|
| \ | | | | / |
| +------+ \ ++---+-+ +-+---++/ +------+ |
| |Host A+-------+ PE-1 | | PE-2 +-+----+Host B| |
| +------+\ ++-+-+-+ +-+-+-++ | /+------+ |
| 192.0.2.2/24 | | | | | | | 192.0.2.3/24 |
| GW=192.0.2.4 | | | | | | | GW=192.0.2.4 |
| | | | | | | | +------+ |
| | | | | | | +----+ GW +-- |
| | | | | | | /+------+ |
| | | | | | | 192.0.2.4/24 |
| | | | | | | |
| DC West | | | IP/MPLS Backbone | | | DC East |
+------------------+ | | | | +------------------+
| +--------------------+ |
| |
VRF_A : V VRF_A : V
+------------+---------+--------+ +------------+---------+--------+
| Prefix |Next hop |Protocol| | Prefix |Next hop |Protocol|
+------------+---------+--------+ +------------+---------+--------+
|192.0.2.1/32|127.0.0.1| Direct | |192.0.2.1/32|127.0.0.1| Direct |
+------------+---------+--------+ +------------+---------+--------+
|192.0.2.2/32|192.0.2.2| Direct | |192.0.2.2/32| PE-1 | IBGP |
+------------+---------+--------+ +------------+---------+--------+
|192.0.2.3/32| PE-2 | IBGP | |192.0.2.3/32|192.0.2.3| Direct |
+------------+---------+--------+ +------------+---------+--------+
|192.0.2.4/32| PE-2 | IBGP | |192.0.2.4/32|192.0.2.4| Direct |
+------------+---------+--------+ +------------+---------+--------+
|192.0.2.0/24|192.0.2.1| Direct | |192.0.2.0/24|192.0.2.1| Direct |
+------------+---------+--------+ +------------+---------+--------+
| 0.0.0.0/0 | PE-2 | IBGP | | 0.0.0.0/0 |192.0.2.4| Static |
+------------+---------+--------+ +------------+---------+--------+
+--------------------+
+------------------+ | | +------------------+
|VPN_A:192.0.2.1/24| | | |VPN_A:192.0.2.1/24|
| \ | | | | / |
| +------+ \ ++---+-+ +-+---++/ +------+ |
| |Host A+-------+ PE-1 | | PE-2 +-+----+Host B| |
| +------+\ ++-+-+-+ +-+-+-++ | /+------+ |
| 192.0.2.2/24 | | | | | | | 192.0.2.3/24 |
| GW=192.0.2.4 | | | | | | | GW=192.0.2.4 |
| | | | | | | | +------+ |
| | | | | | | +----+ GW +-- |
| | | | | | | /+------+ |
| | | | | | | 192.0.2.4/24 |
| | | | | | | |
| DC West | | | IP/MPLS Backbone | | | DC East |
+------------------+ | | | | +------------------+
| +--------------------+ |
| |
VRF_A : V VRF_A : V
+------------+---------+--------+ +------------+---------+--------+
| Prefix |Next hop |Protocol| | Prefix |Next hop |Protocol|
+------------+---------+--------+ +------------+---------+--------+
|192.0.2.1/32|127.0.0.1| Direct | |192.0.2.1/32|127.0.0.1| Direct |
+------------+---------+--------+ +------------+---------+--------+
|192.0.2.2/32|192.0.2.2| Direct | |192.0.2.2/32| PE-1 | IBGP |
+------------+---------+--------+ +------------+---------+--------+
|192.0.2.3/32| PE-2 | IBGP | |192.0.2.3/32|192.0.2.3| Direct |
+------------+---------+--------+ +------------+---------+--------+
|192.0.2.4/32| PE-2 | IBGP | |192.0.2.4/32|192.0.2.4| Direct |
+------------+---------+--------+ +------------+---------+--------+
|192.0.2.0/24|192.0.2.1| Direct | |192.0.2.0/24|192.0.2.1| Direct |
+------------+---------+--------+ +------------+---------+--------+
| 0.0.0.0/0 | PE-2 | IBGP | | 0.0.0.0/0 |192.0.2.4| Static |
+------------+---------+--------+ +------------+---------+--------+
Figure 2: Inter-subnet Unicast Example (1)
图2：子网间单播示例（1）
As shown in Figure 2, only one data center (i.e., DC East) is deployed with a default gateway (i.e., GW). PE-2, which is connected to GW, would either be configured with or have learned a default route from GW with the next hop being pointed at GW. Meanwhile, this route is distributed to other PE routers (i.e., PE-1) as per normal operation as described in [RFC4364]. Assume Host A sends an ARP
如图2所示，只有一个数据中心（即DC East）部署了默认网关（即GW）。连接到GW的PE-2将配置或已从GW学习默认路由，下一跳指向GW。同时，按照[RFC4364]中描述的正常操作，该路由被分配到其他PE路由器（即PE-1）。假设主机A发送一个ARP
request for its default gateway (i.e., 192.0.2.4) prior to
communicating with a destination host outside of its subnet. Upon
receiving this ARP request, PE-1 acting as an ARP proxy returns its
own MAC address as a response. Host A then sends a packet for Host B
to PE-1. PE-1 tunnels such a packet towards PE-2 according to the
default route learned from PE-2, which in turn forwards that packet
to GW.
+--------------------+
+------------------+ | | +------------------+
|VPN_A:192.0.2.1/24| | | |VPN_A:192.0.2.1/24|
| \ | | | | / |
| +------+ \ ++---+-+ +-+---++/ +------+ |
| |Host A+----+--+ PE-1 | | PE-2 +-+----+Host B| |
| +------+\ | ++-+-+-+ +-+-+-++ | /+------+ |
| 192.0.2.2/24 | | | | | | | | 192.0.2.3/24 |
| GW=192.0.2.4 | | | | | | | | GW=192.0.2.4 |
| +------+ | | | | | | | | +------+ |
|--+ GW-1 +----+ | | | | | | +----+ GW-2 +-- |
| +------+\ | | | | | | /+------+ |
| 192.0.2.4/24 | | | | | | 192.0.2.4/24 |
| | | | | | | |
| DC West | | | IP/MPLS Backbone | | | DC East |
+------------------+ | | | | +------------------+
| +--------------------+ |
| |
VRF_A : V VRF_A : V
+------------+---------+--------+ +------------+---------+--------+
| Prefix |Next hop |Protocol| | Prefix |Next hop |Protocol|
+------------+---------+--------+ +------------+---------+--------+
|192.0.2.1/32|127.0.0.1| Direct | |192.0.2.1/32|127.0.0.1| Direct |
+------------+---------+--------+ +------------+---------+--------+
|192.0.2.2/32|192.0.2.2| Direct | |192.0.2.2/32| PE-1 | IBGP |
+------------+---------+--------+ +------------+---------+--------+
|192.0.2.3/32| PE-2 | IBGP | |192.0.2.3/32|192.0.2.3| Direct |
+------------+---------+--------+ +------------+---------+--------+
|192.0.2.4/32|192.0.2.4| Direct | |192.0.2.4/32|192.0.2.4| Direct |
+------------+---------+--------+ +------------+---------+--------+
|192.0.2.0/24|192.0.2.1| Direct | |192.0.2.0/24|192.0.2.1| Direct |
+------------+---------+--------+ +------------+---------+--------+
| 0.0.0.0/0 |192.0.2.4| Static | | 0.0.0.0/0 |192.0.2.4| Static |
+------------+---------+--------+ +------------+---------+--------+
request for its default gateway (i.e., 192.0.2.4) prior to
communicating with a destination host outside of its subnet. Upon
receiving this ARP request, PE-1 acting as an ARP proxy returns its
own MAC address as a response. Host A then sends a packet for Host B
to PE-1. PE-1 tunnels such a packet towards PE-2 according to the
default route learned from PE-2, which in turn forwards that packet
to GW.
+--------------------+
+------------------+ | | +------------------+
|VPN_A:192.0.2.1/24| | | |VPN_A:192.0.2.1/24|
| \ | | | | / |
| +------+ \ ++---+-+ +-+---++/ +------+ |
| |Host A+----+--+ PE-1 | | PE-2 +-+----+Host B| |
| +------+\ | ++-+-+-+ +-+-+-++ | /+------+ |
| 192.0.2.2/24 | | | | | | | | 192.0.2.3/24 |
| GW=192.0.2.4 | | | | | | | | GW=192.0.2.4 |
| +------+ | | | | | | | | +------+ |
|--+ GW-1 +----+ | | | | | | +----+ GW-2 +-- |
| +------+\ | | | | | | /+------+ |
| 192.0.2.4/24 | | | | | | 192.0.2.4/24 |
| | | | | | | |
| DC West | | | IP/MPLS Backbone | | | DC East |
+------------------+ | | | | +------------------+
| +--------------------+ |
| |
VRF_A : V VRF_A : V
+------------+---------+--------+ +------------+---------+--------+
| Prefix |Next hop |Protocol| | Prefix |Next hop |Protocol|
+------------+---------+--------+ +------------+---------+--------+
|192.0.2.1/32|127.0.0.1| Direct | |192.0.2.1/32|127.0.0.1| Direct |
+------------+---------+--------+ +------------+---------+--------+
|192.0.2.2/32|192.0.2.2| Direct | |192.0.2.2/32| PE-1 | IBGP |
+------------+---------+--------+ +------------+---------+--------+
|192.0.2.3/32| PE-2 | IBGP | |192.0.2.3/32|192.0.2.3| Direct |
+------------+---------+--------+ +------------+---------+--------+
|192.0.2.4/32|192.0.2.4| Direct | |192.0.2.4/32|192.0.2.4| Direct |
+------------+---------+--------+ +------------+---------+--------+
|192.0.2.0/24|192.0.2.1| Direct | |192.0.2.0/24|192.0.2.1| Direct |
+------------+---------+--------+ +------------+---------+--------+
| 0.0.0.0/0 |192.0.2.4| Static | | 0.0.0.0/0 |192.0.2.4| Static |
+------------+---------+--------+ +------------+---------+--------+
Figure 3: Inter-subnet Unicast Example (2)
图3：子网间单播示例（2）
As shown in Figure 3, in the case where each data center is deployed with a default gateway, hosts will get ARP responses directly from their local default gateways, rather than from their local PE routers when sending ARP requests for their default gateways.
如图3所示，在每个数据中心都部署了一个默认网关的情况下，主机将直接从其本地默认网关获得ARP响应，而不是在为其默认网关发送ARP请求时从其本地PE路由器获得ARP响应。
+------+
+------+ PE-3 +------+
+------------------+ | +------+ | +------------------+
|VPN_A:192.0.2.1/24| | | |VPN_A:192.0.2.1/24|
| \ | | | | / |
| +------+ \ ++---+-+ +-+---++/ +------+ |
| |Host A+-------+ PE-1 | | PE-2 +------+Host B| |
| +------+\ ++-+-+-+ +-+-+-++ /+------+ |
| 192.0.2.2/24 | | | | | | 192.0.2.3/24 |
| GW=192.0.2.1 | | | | | | GW=192.0.2.1 |
| | | | | | | |
| DC West | | | IP/MPLS Backbone | | | DC East |
+------------------+ | | | | +------------------+
| +--------------------+ |
| |
VRF_A : V VRF_A : V
+------------+---------+--------+ +------------+---------+--------+
| Prefix |Next hop |Protocol| | Prefix |Next hop |Protocol|
+------------+---------+--------+ +------------+---------+--------+
|192.0.2.1/32|127.0.0.1| Direct | |192.0.2.1/32|127.0.0.1| Direct |
+------------+---------+--------+ +------------+---------+--------+
|192.0.2.2/32|192.0.2.2| Direct | |192.0.2.2/32| PE-1 | IBGP |
+------------+---------+--------+ +------------+---------+--------+
|192.0.2.3/32| PE-2 | IBGP | |192.0.2.3/32|192.0.2.3| Direct |
+------------+---------+--------+ +------------+---------+--------+
|192.0.2.0/24|192.0.2.1| Direct | |192.0.2.0/24|192.0.2.1| Direct |
+------------+---------+--------+ +------------+---------+--------+
| 0.0.0.0/0 | PE-3 | IBGP | | 0.0.0.0/0 | PE-3 | IBGP |
+------------+---------+--------+ +------------+---------+--------+
+------+
+------+ PE-3 +------+
+------------------+ | +------+ | +------------------+
|VPN_A:192.0.2.1/24| | | |VPN_A:192.0.2.1/24|
| \ | | | | / |
| +------+ \ ++---+-+ +-+---++/ +------+ |
| |Host A+-------+ PE-1 | | PE-2 +------+Host B| |
| +------+\ ++-+-+-+ +-+-+-++ /+------+ |
| 192.0.2.2/24 | | | | | | 192.0.2.3/24 |
| GW=192.0.2.1 | | | | | | GW=192.0.2.1 |
| | | | | | | |
| DC West | | | IP/MPLS Backbone | | | DC East |
+------------------+ | | | | +------------------+
| +--------------------+ |
| |
VRF_A : V VRF_A : V
+------------+---------+--------+ +------------+---------+--------+
| Prefix |Next hop |Protocol| | Prefix |Next hop |Protocol|
+------------+---------+--------+ +------------+---------+--------+
|192.0.2.1/32|127.0.0.1| Direct | |192.0.2.1/32|127.0.0.1| Direct |
+------------+---------+--------+ +------------+---------+--------+
|192.0.2.2/32|192.0.2.2| Direct | |192.0.2.2/32| PE-1 | IBGP |
+------------+---------+--------+ +------------+---------+--------+
|192.0.2.3/32| PE-2 | IBGP | |192.0.2.3/32|192.0.2.3| Direct |
+------------+---------+--------+ +------------+---------+--------+
|192.0.2.0/24|192.0.2.1| Direct | |192.0.2.0/24|192.0.2.1| Direct |
+------------+---------+--------+ +------------+---------+--------+
| 0.0.0.0/0 | PE-3 | IBGP | | 0.0.0.0/0 | PE-3 | IBGP |
+------------+---------+--------+ +------------+---------+--------+
Figure 4: Inter-subnet Unicast Example (3)
图4：子网间单播示例（3）
Alternatively, as shown in Figure 4, PE routers themselves could be configured as default gateways for their locally connected hosts as long as these PE routers have routes to reach outside networks.
或者，如图4所示，PE路由器本身可以配置为其本地连接主机的默认网关，只要这些PE路由器具有到达外部网络的路由。
To support IP multicast between hosts of the same Virtual Subnet, Multicast VPN (MVPN) technologies [RFC6513] could be used without any change. For example, PE routers attached to a given VPN join a default provider multicast distribution tree that is dedicated to that VPN. Ingress PE routers, upon receiving multicast packets from their local hosts, forward them towards remote PE routers through the corresponding default provider multicast distribution tree. Within this context, the IP multicast doesn't include link-local multicast.
为了支持同一虚拟子网的主机之间的IP多播，可以使用多播VPN（MVPN）技术[RFC6513]，而无需任何更改。例如，连接到给定VPN的PE路由器加入专用于该VPN的默认提供商多播分发树。入口PE路由器从其本地主机接收多播数据包后，通过相应的默认提供商多播分发树将其转发到远程PE路由器。在此上下文中，IP多播不包括链路本地多播。
PE routers should be able to dynamically discover their local hosts and keep the list of these hosts up-to-date in a timely manner to ensure the availability and accuracy of the corresponding host routes originated from them. PE routers could accomplish local host discovery by some traditional host-discovery mechanisms using ARP or ND protocols.
PE路由器应能够动态发现其本地主机，并及时更新这些主机的列表，以确保源自它们的相应主机路由的可用性和准确性。PE路由器可以通过使用ARP或ND协议的一些传统主机发现机制来完成本地主机发现。
Acting as an ARP or ND proxy, a PE router should only respond to an ARP request or Neighbor Solicitation (NS) message for a target host when it has a best route for that target host in the associated VRF and the outgoing interface of that best route is different from the one over which the ARP request or NS message is received. In the scenario where a given VPN site (i.e., a data center) is multihomed to more than one PE router via an Ethernet switch or an Ethernet network, the Virtual Router Redundancy Protocol (VRRP) [RFC5798] is usually enabled on these PE routers. In this case, only the PE router being elected as the VRRP Master is allowed to perform the ARP/ND proxy function.
作为ARP或ND代理，当PE路由器在相关VRF中具有针对该目标主机的最佳路由且该最佳路由的输出接口不同于接收ARP请求或NS消息的接口时，PE路由器应仅响应目标主机的ARP请求或邻居请求（NS）消息。在给定VPN站点（即数据中心）通过以太网交换机或以太网网络多宿到多个PE路由器的场景中，通常在这些PE路由器上启用虚拟路由器冗余协议（VRRP）[RFC5798]。在这种情况下，只允许被选为VRRP主机的PE路由器执行ARP/ND代理功能。
During the VM migration process, the PE router to which the moving VM is now attached would create a host route for that host upon receiving a notification message of VM attachment (e.g., a gratuitous ARP or unsolicited NA message). The PE router to which the moving VM was previously attached would withdraw the corresponding host route when noticing the detachment of that VM. Meanwhile, the latter PE router could optionally broadcast a gratuitous ARP or send an unsolicited NA message on behalf of that host with the source MAC address being one of its own. In this way, the ARP/ND entry of this host that moved and that has been cached on any local host would be updated accordingly. In the case where there is no explicit VM detachment notification mechanism, the PE router could also use the following trick to detect the VM detachment: upon learning a route update for a local host from a remote PE router for the first time, the PE router could immediately check whether that local host is still attached to it by some means (e.g., ARP/ND PING and/or ICMP PING). It is important to ensure that the same MAC and IP are associated to the default gateway active in each data center, as the VM would most likely continue to send packets to the same default gateway address after having migrated from one data center to another. One possible way to achieve this goal is to configure the
在VM迁移过程中，移动VM现在连接到的PE路由器将在收到VM连接的通知消息（例如，免费ARP或未经请求的NA消息）时为该主机创建主机路由。移动虚拟机先前连接到的PE路由器在注意到虚拟机分离时将撤回相应的主机路由。同时，后一个PE路由器可以选择性地广播免费的ARP，或者代表该主机发送一个未经请求的NA消息，源MAC地址是它自己的地址之一。通过这种方式，移动并缓存在任何本地主机上的该主机的ARP/ND条目将相应地更新。在没有显式VM分离通知机制的情况下，PE路由器还可以使用以下技巧来检测VM分离：在第一次从远程PE路由器学习本地主机的路由更新时，PE路由器可以立即检查本地主机是否仍然通过某种方式连接到它（例如，ARP/ND PING和/或ICMP PING）。确保相同的MAC和IP与每个数据中心中活动的默认网关相关联非常重要，因为VM在从一个数据中心迁移到另一个数据中心后很可能会继续向相同的默认网关地址发送数据包。实现此目标的一种可能方法是配置
same VRRP group on each location to ensure that the default gateway active in each data center shares the same virtual MAC and virtual IP addresses.
每个位置上都有相同的VRRP组，以确保每个数据中心中活动的默认网关共享相同的虚拟MAC和虚拟IP地址。
In a Virtual Subnet environment, the MAC learning domain associated with a given Virtual Subnet that has been extended across multiple data centers is partitioned into segments, and each segment is confined within a single data center. Therefore, data-center switches only need to learn local MAC addresses, rather than learning both local and remote MAC addresses.
在虚拟子网环境中，与已扩展到多个数据中心的给定虚拟子网相关联的MAC学习域被划分为多个段，每个段都限制在单个数据中心内。因此，数据中心交换机只需要学习本地MAC地址，而不需要学习本地和远程MAC地址。
When default gateway functions are implemented on PE routers as shown in Figure 4, the ARP/ND cache table on each PE router only needs to contain ARP/ND entries of local hosts. As a result, the ARP/ND cache table size would not grow as the number of data centers to be connected increases.
如图4所示，在PE路由器上实现默认网关功能时，每个PE路由器上的ARP/ND缓存表只需要包含本地主机的ARP/ND条目。因此，ARP/ND缓存表的大小不会随着要连接的数据中心数量的增加而增加。
In a Virtual Subnet environment, the flooding domain associated with a given Virtual Subnet that was extended across multiple data centers, is partitioned into segments and each segment is confined within a single data center. Therefore, the performance impact on networks and servers imposed by the flooding of ARP/ND broadcast/ multicast and unknown unicast traffic is minimized.
在虚拟子网环境中，与跨多个数据中心扩展的给定虚拟子网关联的泛洪域被划分为多个段，每个段都限制在单个数据中心内。因此，ARP/ND广播/多播和未知单播流量泛滥对网络和服务器的性能影响降至最低。
As shown in Figure 4, to optimize the forwarding path for the traffic between cloud users and cloud data centers, PE routers located in cloud data centers (i.e., PE-1 and PE-2), which are also acting as default gateways, propagate host routes for their own local hosts to remote PE routers that are attached to cloud user sites (i.e., PE-3). As such, traffic from cloud user sites to a given server on the Virtual Subnet that has been extended across data centers would be forwarded directly to the data-center location where that server resides, since traffic is now forwarded according to the host route for that server, rather than the subnet route. Furthermore, for traffic coming from cloud data centers and forwarded to cloud user sites, each PE router acting as a default gateway would forward traffic according to the longest-match route in the corresponding VRF. As a result, traffic from data centers to cloud user sites is forwarded along an optimal path as well.
如图4所示，为了优化云用户和云数据中心之间流量的转发路径，位于云数据中心（即PE-1和PE-2）中的PE路由器也充当默认网关，将其自身本地主机的主机路由传播到连接到云用户站点（即PE-3）的远程PE路由器。因此，从云用户站点到虚拟子网上已跨数据中心扩展的给定服务器的流量将直接转发到该服务器所在的数据中心位置，因为流量现在是根据该服务器的主机路由而不是子网路由转发的。此外，对于来自云数据中心并转发到云用户站点的流量，作为默认网关的每个PE路由器将根据相应VRF中最长的匹配路由转发流量。因此，从数据中心到云用户站点的流量也会沿着最佳路径转发。
Although most traffic within and across data centers is IP traffic, there may still be a few legacy clustering applications that rely on non-IP communications (e.g., heartbeat messages between cluster nodes). Since Virtual Subnet is strictly based on L3 forwarding, those non-IP communications cannot be supported in the Virtual Subnet solution. In order to support those few non-IP traffic (if present) in the environment where the Virtual Subnet solution has been deployed, the approach following the idea of "route all IP traffic, bridge non-IP traffic" could be considered. In other words, all IP traffic including both intra- and inter-subnet, would be processed according to the Virtual Subnet design, while non-IP traffic would be forwarded according to a particular Layer 2 VPN approach. Such a unified L2/L3 VPN approach requires ingress PE routers to classify packets received from hosts before distributing them to the corresponding L2 or L3 VPN forwarding processes. Note that more and more cluster vendors are offering clustering applications based on Layer 3 interconnection.
尽管数据中心内部和跨数据中心的大部分流量是IP流量，但仍可能有一些传统群集应用程序依赖于非IP通信（例如，群集节点之间的心跳消息）。由于虚拟子网严格基于L3转发，因此虚拟子网解决方案中不支持这些非IP通信。为了在部署了虚拟子网解决方案的环境中支持这些少量的非IP流量（如果存在），可以考虑遵循“路由所有IP流量，桥接非IP流量”的思想的方法。换句话说，包括子网内和子网间的所有IP流量将根据虚拟子网设计进行处理，而非IP流量将根据特定的第2层VPN方法进行转发。这种统一的L2/L3 VPN方法要求入口PE路由器对从主机接收的数据包进行分类，然后再将其分发到相应的L2或L3 VPN转发进程。请注意，越来越多的集群供应商正在提供基于第3层互连的集群应用程序。
As illustrated before, intra-subnet traffic across PE routers is forwarded at Layer 3 in the Virtual Subnet solution. Therefore, IP broadcast and link-local multicast traffic cannot be forwarded across PE routers in the Virtual Subnet solution. In order to support the IP broadcast and link-local multicast traffic in the environment where the Virtual Subnet solution has been deployed, the unified L2/ L3 overlay approach as described in Section 4.1 could be considered as well. That is, IP broadcast and link-local multicast messages would be forwarded at Layer 2 while routable IP traffic would be processed according to the Virtual Subnet design.
如前所示，通过PE路由器的子网内流量在虚拟子网解决方案的第3层转发。因此，IP广播和链路本地多播流量不能在虚拟子网解决方案中跨PE路由器转发。为了在部署虚拟子网解决方案的环境中支持IP广播和链路本地多播流量，还可以考虑第4.1节中描述的统一L2/L3覆盖方法。也就是说，IP广播和链路本地多播消息将在第2层转发，而可路由IP流量将根据虚拟子网设计进行处理。
As mentioned before, intra-subnet traffic is forwarded at Layer 3 in the Virtual Subnet context. Since it doesn't require any change to the Time-To-Live (TTL) handling mechanism of the BGP/MPLS IP VPN, when doing a traceroute operation on one host for another host (assuming that these two hosts are within the same subnet but are attached to different sites), the traceroute output would reflect the fact that these two hosts within the same subnet are actually connected via a Virtual Subnet, rather than a Layer 2 connection since the PE routers to which those two hosts are connected would be displayed in the traceroute output. In addition, for any other applications that generate intra-subnet traffic with TTL set to 1,
如前所述，子网内流量在虚拟子网上下文的第3层转发。由于它不需要对BGP/MPLS IP VPN的生存时间（TTL）处理机制进行任何更改，因此在一台主机上为另一台主机执行跟踪路由操作时（假设这两台主机位于同一子网内，但连接到不同的站点），跟踪路由输出将反映一个事实，即同一子网中的这两个主机实际上是通过虚拟子网连接的，而不是通过第2层连接，因为这两个主机所连接的PE路由器将显示在跟踪路由输出中。此外，对于生成TTL设置为1的子网内流量的任何其他应用程序，
these applications may not work properly in the Virtual Subnet context, unless special TTL processing and loop-prevention mechanisms for such context have been implemented. Details about such special TTL processing and loop-prevention mechanisms are outside the scope of this document.
这些应用程序可能无法在虚拟子网上下文中正常工作，除非针对此类上下文实现了特殊的TTL处理和循环预防机制。有关此类特殊TTL处理和循环预防机制的详细信息不在本文档范围内。
Since the BGP/MPLS IP VPN signaling is reused without any change, those security considerations as described in [RFC4364] are applicable to this document. Meanwhile, since security issues associated with the NDP are inherited due to the use of NDP proxy, those security considerations and recommendations as described in [RFC6583] are applicable to this document as well.
由于BGP/MPLS IP VPN信令在没有任何更改的情况下被重用，因此[RFC4364]中描述的安全注意事项适用于本文档。同时，由于使用NDP代理会继承与NDP相关的安全问题，[RFC6583]中所述的安全注意事项和建议也适用于本文件。
Inter-data-center traffic often carries highly sensitive information at higher layers that is not directly understood (parsed) within an egress or ingress PE. For example, migrating a VM will often mean moving private keys and other sensitive configuration information. For this reason, inter-data-center traffic should always be protected for both confidentiality and integrity using a strong security mechanism such as IPsec [RFC4301]. In the future, it may be feasible to protect that traffic within the MPLS layer [MPLS-SEC] though at the time of writing, the mechanism for that is not sufficiently mature to recommend. Exactly how such security mechanisms are deployed will vary from case to case, so securing the inter-data-center traffic may or may not involve deploying security mechanisms on the ingress/egress PEs or further "inside" the data centers concerned. Note though that if security is not deployed on the egress/ingress PEs, there is a substantial risk that some sensitive traffic may be sent in the clear and will therefore be vulnerable to pervasive monitoring [RFC7258] or other attacks.
数据中心间通信通常在更高的层上传输高度敏感的信息，这些信息在出口或入口PE中无法直接理解（解析）。例如，迁移VM通常意味着移动私钥和其他敏感配置信息。因此，应始终使用IPsec[RFC4301]等强大的安全机制保护数据中心间通信的机密性和完整性。在未来，保护MPLS层[MPLS-SEC]内的流量可能是可行的，尽管在撰写本文时，该机制还不够成熟，无法推荐。具体部署此类安全机制的方式因情况而异，因此保护数据中心间流量可能涉及也可能不涉及在入口/出口PEs或相关数据中心内部部署安全机制。请注意，如果出口/入口PEs上未部署安全性，则存在一些敏感流量可能以透明方式发送的重大风险，因此容易受到普遍监控[RFC7258]或其他攻击。
[RFC925] Postel, J., "Multi-LAN address resolution", RFC 925, DOI 10.17487/RFC0925, October 1984, <http://www.rfc-editor.org/info/rfc925>.
[RFC925]Postel，J.，“多局域网地址解析”，RFC 925，DOI 10.17487/RFC0925，1984年10月<http://www.rfc-editor.org/info/rfc925>.
[RFC1027] Carl-Mitchell, S. and J. Quarterman, "Using ARP to implement transparent subnet gateways", RFC 1027, DOI 10.17487/RFC1027, October 1987, <http://www.rfc-editor.org/info/rfc1027>.
[RFC1027]Carl Mitchell，S.和J.Quarterman，“使用ARP实现透明子网网关”，RFC 1027，DOI 10.17487/RFC1027，1987年10月<http://www.rfc-editor.org/info/rfc1027>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <http://www.rfc-editor.org/info/rfc4364>.
[RFC4364]Rosen，E.和Y.Rekhter，“BGP/MPLS IP虚拟专用网络（VPN）”，RFC 4364，DOI 10.17487/RFC4364，2006年2月<http://www.rfc-editor.org/info/rfc4364>.
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April 2006, <http://www.rfc-editor.org/info/rfc4389>.
[RFC4389]Thaler，D.，Talwar，M.，和C.Patel，“邻居发现代理（ND代理）”，RFC 4389，DOI 10.17487/RFC4389，2006年4月<http://www.rfc-editor.org/info/rfc4389>.
[MPLS-SEC] Farrel, A. and S. Farrell, "Opportunistic Security in MPLS Networks", Work in Progress, draft-ietf-mpls-opportunistic-encrypt-01, March 2016.
[MPLS-SEC]Farrel，A.和S.Farrell，“MPLS网络中的机会主义安全”，正在进行的工作，草稿-ietf-MPLS-Opportatic-encrypt-01，2016年3月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 4301，DOI 10.17487/RFC4301，2005年12月<http://www.rfc-editor.org/info/rfc4301>.
[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, DOI 10.17487/RFC4659, September 2006, <http://www.rfc-editor.org/info/rfc4659>.
[RFC4659]De Clercq，J.，Ooms，D.，Carugi，M.，和F.Le Faucheur，“用于IPv6 VPN的BGP-MPLS IP虚拟专用网络（VPN）扩展”，RFC 4659，DOI 10.17487/RFC4659，2006年9月<http://www.rfc-editor.org/info/rfc4659>.
[RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, <http://www.rfc-editor.org/info/rfc4761>.
[RFC4761]Kompella，K.，Ed.和Y.Rekhter，Ed.，“使用BGP进行自动发现和信令的虚拟专用LAN服务（VPLS）”，RFC 4761，DOI 10.17487/RFC4761，2007年1月<http://www.rfc-editor.org/info/rfc4761>.
[RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, <http://www.rfc-editor.org/info/rfc4762>.
[RFC4762]Lasserre，M.，Ed.和V.Kompella，Ed.，“使用标签分发协议（LDP）信令的虚拟专用LAN服务（VPLS）”，RFC 4762，DOI 10.17487/RFC4762，2007年1月<http://www.rfc-editor.org/info/rfc4762>.
[RFC5798] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6", RFC 5798, DOI 10.17487/RFC5798, March 2010, <http://www.rfc-editor.org/info/rfc5798>.
[RFC5798]Nadas，S.，Ed.，“IPv4和IPv6的虚拟路由器冗余协议（VRRP）第3版”，RFC 5798，DOI 10.17487/RFC5798，2010年3月<http://www.rfc-editor.org/info/rfc5798>.
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 2012, <http://www.rfc-editor.org/info/rfc6513>.
[RFC6513]Rosen，E.，Ed.和R.Aggarwal，Ed.，“MPLS/BGP IP VPN中的多播”，RFC 6513，DOI 10.17487/RFC6513，2012年2月<http://www.rfc-editor.org/info/rfc6513>.
[RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational Neighbor Discovery Problems", RFC 6583, DOI 10.17487/RFC6583, March 2012, <http://www.rfc-editor.org/info/rfc6583>.
[RFC6583]Gashinsky，I.，Jaeggli，J.，和W.Kumari，“操作邻居发现问题”，RFC 6583，DOI 10.17487/RFC6583，2012年3月<http://www.rfc-editor.org/info/rfc6583>.
[RFC6820] Narten, T., Karir, M., and I. Foo, "Address Resolution Problems in Large Data Center Networks", RFC 6820, DOI 10.17487/RFC6820, January 2013, <http://www.rfc-editor.org/info/rfc6820>.
[RFC6820]Narten，T.，Karir，M.，和I.Foo，“解决大型数据中心网络中的解决方案问题”，RFC 6820，DOI 10.17487/RFC6820，2013年1月<http://www.rfc-editor.org/info/rfc6820>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <http://www.rfc-editor.org/info/rfc7258>.
[RFC7258]Farrell，S.和H.Tschofenig，“普遍监控是一种攻击”，BCP 188，RFC 7258，DOI 10.17487/RFC7258，2014年5月<http://www.rfc-editor.org/info/rfc7258>.
Acknowledgements
致谢
Thanks to Susan Hares, Yongbing Fan, Dino Farinacci, Himanshu Shah, Nabil Bitar, Giles Heron, Ronald Bonica, Monique Morrow, Rajiv Asati, Eric Osborne, Thomas Morin, Martin Vigoureux, Pedro Roque Marque, Joe Touch, Wim Henderickx, Alia Atlas, and Stephen Farrell for their valuable comments and suggestions on this document. Thanks to Loa Andersson for his WG LC review on this document. Thanks to Alvaro Retana for his AD review on this document. Thanks to Ronald Bonica for his RtgDir review. Thanks to Donald Eastlake 3rd for his Sec-DIR review of this document. Thanks to Jouni Korhonen for the OPS-Dir review of this document. Thanks to Roni Even for the Gen-ART review of this document. Thanks to Sabrina Tanamal for the IANA review of this document.
感谢Susan Hares、范永兵、迪诺·法里纳奇、希曼苏·沙阿、纳比尔·比塔、贾尔斯·赫隆、罗纳德·博尼卡、莫妮克·莫罗、拉吉夫·阿萨蒂、埃里克·奥斯本、托马斯·莫林、马丁·维古鲁、佩德罗·罗克·马尔克、乔·图奇、维姆·亨德里克、艾莉亚·阿特拉斯和斯蒂芬·法雷尔对本文件提出的宝贵意见和建议。感谢Loa Andersson对本文件的工作组信用证审查。感谢Alvaro Retana对本文档的广告评论。感谢Ronald Bonica的RtgDir评论。感谢Donald Eastlake 3rd对本文件的Sec DIR审查。感谢Jouni Korhonen对本文件的OPS Dir审查。感谢Roni对本文档的Gen ART评论。感谢Sabrina Tanamal对本文件的IANA审查。
Authors' Addresses
作者地址
Xiaohu Xu Huawei Technologies No.156 Beiqing Rd Beijing 100095 China
中国北京市北青路156号华为科技有限公司徐晓虎100095
Email: xuxiaohu@huawei.com
Email: xuxiaohu@huawei.com
Christian Jacquenet Orange 4 rue du Clos Courtel Cesson-Sevigne, 35512 France
克里斯蒂安·雅克内特·奥兰治法国塞森塞维涅路4号，邮编：35512
Email: christian.jacquenet@orange.com
Email: christian.jacquenet@orange.com
Robert Raszuk Bloomberg LP 731 Lexington Avenue New York City, NY 10022 United States
Robert Raszuk Bloomberg LP美国纽约市列克星敦大道731号，邮编10022
Email: robert@raszuk.net
Email: robert@raszuk.net
Truman Boyes Bloomberg LP
杜鲁门·博伊斯彭博有限公司
Email: tboyes@bloomberg.net
Email: tboyes@bloomberg.net
Brendan Fee Extreme Networks
布伦丹费极端网络
Email: bfee@extremenetworks.com
Email: bfee@extremenetworks.com