1. 引言

1. 引言 (Introduction)

本文描述一种方法, 使 Service Provider 可以使用 IP backbone 为其客户提供 IP Virtual Private Networks (VPNs). 该方法使用 "peer model", 在该模型中, 客户边缘路由器 (CE routers) 将其 routes 发送给 Service Provider 的边缘路由器 (PE routers). 然后 Service Provider 使用 Border Gateway Protocol (BGP) [BGP, BGP-MP], 在连接到某个 VPN 的 PE routers 之间交换该 VPN 的 routes. 这种方式确保来自不同 VPN 的 routes 保持不同且相互分离, 即使两个 VPN 的 address space 重叠也是如此. PE routers 会把某个 VPN 中其他 CE routers 的 routes 分发给该 VPN 中的 CE routers. CE routers 彼此之间不建立对等关系, 因此 VPN 的 routing algorithm 看不到任何 "overlay". "IP VPN" 中的 "IP" 表示 PE 从 CE 接收 IP datagrams, 检查其 IP headers, 并据此进行路由.

VPN 内的每条 route 都会被分配一个 Multiprotocol Label Switching (MPLS) [MPLS-ARCH, MPLS-BGP, MPLS-ENCAPS] label; 当 BGP 分发一条 VPN route 时, 它也会为该 route 分发一个 MPLS label. 在客户数据 packet 穿越 Service Provider 的 backbone 之前, 它会用一个 MPLS label 进行封装, 该 label 对应于客户 VPN 中与 packet destination address 最匹配的 route. 该 MPLS packet 会被进一步封装 (例如, 使用另一个 MPLS label, 或使用 IP 或 Generic Routing Encapsulation (GRE) tunnel header [MPLS-in-IP-GRE]), 从而通过 tunnel 穿越 backbone 到达正确的 PE router. 因此, backbone core routers 不需要知道 VPN routes.

该方法的主要目标是支持这样一种情形: 客户从一个或多个与其保持合同关系的 Service Provider 获取 IP backbone 服务. 客户可以是企业, 需要 extranet 的企业组, Internet Service Provider, application service provider, 使用同一方法向自身客户提供 VPN 的另一个 VPN Service Provider, 等等. 该方法让客户能够非常简单地使用 backbone 服务. 对 Service Provider 而言, 它也具有很好的可扩展性和灵活性, 并允许 Service Provider 增加价值.

1.1. 虚拟专用网络 (Virtual Private Networks)

考虑一组连接到公共网络的 "sites", 我们将这个公共网络称为 "the backbone". 现在应用某种 policy, 在该集合中创建若干子集, 并施加如下规则: 只有当至少一个这样的子集同时包含两个 sites 时, 这两个 sites 才可以通过该 backbone 具有 IP 互连能力.

这些子集就是 Virtual Private Networks (VPNs). 只有当存在某个 VPN 同时包含两个 sites 时, 这两个 sites 才能通过公共 backbone 具有 IP connectivity. 没有共同 VPN 的两个 sites 在该 backbone 上没有 connectivity.

如果某个 VPN 中的所有 sites 都由同一企业拥有, 该 VPN 可被视为企业 "intranet". 如果某个 VPN 中的不同 sites 由不同企业拥有, 该 VPN 可被视为 "extranet". 一个 site 可以属于多个 VPN; 例如, 同时属于一个 intranet 和若干 extranets. 一般而言, 当本文使用 "VPN" 一词时, 不区分 intranet 和 extranet.

我们将 sites 的所有者称为 "customers". 我们将 backbone 的所有者/运营者称为 "Service Providers" (SPs). customers 从 SPs 获取 "VPN service".

一个 customer 可以是单个企业, 一组企业, Internet Service Provider, Application Service Provider, 向自身客户提供同类 VPN service 的另一个 SP, 等等.

决定某个 sites 集合是否构成 VPN 的 policies 是 customers 的 policies. 一些 customers 希望这些 policies 的实现完全由 SP 负责. 其他 customers 可能希望与 SP 共同承担实现这些 policies 的责任. 本文规定了可用于实现这些 policies 的机制. 我们描述的机制足够通用, 既允许由 SP 单独实现这些 policies, 也允许由 VPN customer 与 SP 共同实现. 不过, 讨论的大部分重点放在前一种情形.

本文讨论的机制允许实现范围很广的 policies. 例如, 在给定 VPN 内, 可以允许每个 site 都有一条到每个其他 site 的 direct route ("full mesh"). 也可以强制某些 site 对之间的 traffic 经由第三个 site 路由. 例如, 如果希望一对 sites 之间的 traffic 通过 firewall, 且 firewall 位于第三个 site, 这种方式就很有用.

在本文中, 我们将讨论限制在 customer 明确从某个 SP, 或从一组已同意协作提供 VPN service 的 SPs, 购买 VPN service 的情形. 也就是说, customer 并非只是从某个 SP 购买 Internet access, VPN traffic 也不会经过随机互连的一组 SP networks.

我们还将讨论限制在 backbone 向 customer 提供 IP service 的情形, 而不是例如 Frame Relay, Asynchronous Transfer Mode (ATM), ethernet, High Level Data Link Control (HDLC), 或 Point-to-Point Protocol (PPP) 等 layer 2 service. customer 可以通过这些 (或其他) layer 2 services 之一连接到 backbone, 但该 layer 2 service 在 backbone 的 "edge" 处终止, 在那里 customer 的 IP datagrams 会从任何 layer 2 encapsulation 中取出.

在本引言的其余部分, 我们规定 VPNs 应具有的一些属性. 本文其余部分规定一组可部署的机制, 用于提供具备所有这些属性的 VPN model. 本节还介绍本文其余部分使用的一些技术术语.

1.2. 客户边缘和提供商边缘 (Customer Edge and Provider Edge)

Routers 可以通过多种不同方式相互连接, 或连接到 end systems: PPP connections, ATM Virtual Circuits (VCs), Frame Relay VCs, ethernet interfaces, ethernet interfaces 上的 Virtual Local Area Networks (VLANs), GRE tunnels, Layer 2 Tunneling Protocol (L2TP) tunnels, IPsec tunnels, 等等. 我们将使用 "attachment circuit" 一词泛指连接到 router 的此类手段. attachment circuit 可以是通常被视为 "data link" 的那种连接, 也可以是某种 tunnel; 关键在于两个设备能够通过该 attachment circuit 成为 network layer peers.

每个 VPN site 必须包含一个或多个 Customer Edge (CE) devices. 每个 CE device 通过某种 attachment circuit 连接到一个或多个 Provider Edge (PE) routers.

SP 网络中不连接 CE devices 的 routers 称为 "P routers".

CE devices 可以是 hosts 或 routers. 在典型情形下, 一个 site 包含一个或多个 routers, 其中一些连接到 PE routers. 连接到 PE routers 的 site routers 就是 CE devices, 或 "CE routers". 不过, 并没有什么阻止一个不执行路由的 host 直接连接到 PE router, 在这种情况下该 host 就是一个 CE device.

有时, 物理连接到 PE router 的是一个 layer 2 switch. 在这种情况下, 我们不称该 layer 2 switch 为 CE device. 相反, CE devices 是通过该 layer 2 switch 与 PE router 通信的 hosts 和 routers; layer 2 infrastructure 是透明的. 如果 layer 2 infrastructure 提供 multipoint service, 则多个 CE devices 可以通过同一个 attachment circuit 连接到 PE router.

CE devices 在逻辑上属于 customer 的 VPN. PE 和 P routers 在逻辑上属于 SP 的网络.

packet 从 CE 到 PE 时经过的 attachment circuit 称为该 packet 的 "ingress attachment circuit", 该 PE 称为该 packet 的 "ingress PE". packet 从 PE 到 CE 时经过的 attachment circuit 称为该 packet 的 "egress attachment circuit", 该 PE 称为该 packet 的 "egress PE".

如果某个 PE router 连接到某个 VPN 的某个 site 中的 CE device, 我们就说该 PE router 连接到这个特定 VPN. 类似地, 如果某个 PE router 连接到某个 site 中的 CE device, 我们就说该 PE router 连接到这个特定 site.

当 CE device 是 router 时, 它是其所连接的 PE(s) 的 routing peer, 但不是其他 sites 中 CE routers 的 routing peer. 不同 sites 中的 routers 不直接相互交换 routing information; 实际上, 它们甚至完全不需要知道彼此存在. 因此, customer 没有需要管理的 backbone 或 "virtual backbone", 也不必处理任何 inter-site routing 问题. 换言之, 在本文描述的方案中, VPN 不是叠加在 SP 网络之上的 "overlay".

关于 edge devices 的管理, SP 与其 customers 之间保持清晰的管理边界. customers 不需要出于管理目的访问 PE 或 P routers, SP 也不需要出于管理目的访问 CE devices.

1.3. 地址空间重叠的 VPNs (VPNs with Overlapping Address Spaces)

如果两个 VPNs 没有共同 sites, 则它们可以有重叠的 address spaces. 也就是说, 某个给定 address 在 VPN V1 中可以用作 system S1 的 address, 而在 VPN V2 中用作完全不同的 system S2 的 address. 当各 VPN 都使用 RFC 1918 private address space 时, 这是常见情形. 当然, 在每个 VPN 内, 每个 address 必须没有歧义.

即使两个 VPNs 确实有共同 sites, 只要不需要在具有此类 addresses 的 systems 与共同 sites 中的 systems 之间进行任何通信, 它们也可以有重叠的 address spaces.

1.4. 到同一系统具有不同路由的 VPNs (VPNs with Different Routes to the Same System)

虽然一个 site 可以属于多个 VPNs, 但到该 site 中某个给定 system 的 route 并不一定在所有 VPNs 中都相同. 例如, 假设我们有一个由 sites A, B, C 组成的 intranet, 以及一个由 A, B, C 和 "foreign" site D 组成的 extranet. 假设 site A 上有一台 server, 我们希望来自 B, C 或 D 的 clients 能够使用该 server. 再假设 site B 上有一个 firewall. 我们希望从 site D 到 server 的所有 traffic 都通过该 firewall, 以便对来自 extranet 的 traffic 进行访问控制. 但是, 我们不希望从 C 到 server 的 traffic 经过 firewall, 因为这是 intranet traffic.

可以为该 server 设置两条 routes. 一条 route 由 sites B 和 C 使用, 将 traffic 直接送到 site A. 第二条 route 由 site D 使用, 改为将 traffic 送到 site B 的 firewall. 如果 firewall 允许该 traffic 通过, 则该 traffic 随后看起来像来自 site B 的 traffic, 并沿着到 site A 的 route 转发.

1.5. SP 骨干路由器 (SP Backbone Routers)

SP 的 backbone 由 PE routers 以及其他不连接 CE devices 的 routers ("P routers") 组成.

如果 SP backbone 中的每台 router 都必须维护该 SP 支持的所有 VPNs 的 routing information, 就会出现严重的可扩展性问题; 可支持的 sites 数量将受限于单台 router 能够保存的 routing information 数量. 因此, 重要的是, 关于某个特定 VPN 的 routing information 只需要存在于连接到该 VPN 的 PE routers 中. 特别是, P routers 完全不需要任何 per-VPN routing information. (在考虑 multicast routing 时, 这个条件可能需要有所放宽. 本文不再进一步讨论这一点, 但 [VPN-MCAST] 对其进行了考察.)

因此, 正如 VPN owners 没有需要管理的 backbone 或 "virtual backbone" 一样, SPs 自身也不需要为每个 VPN 管理单独的 backbone 或 "virtual backbone". backbone 中的 site-to-site routing 是最优的 (在用于形成 VPNs 的 policies 约束内), 且不受人为的 tunnel "virtual topology" 以任何方式限制.

Section 10 讨论当 backbone 跨越多个 Service Providers 时出现的一些特殊问题.

1.6. 安全性 (Security)

这里讨论的这类 VPNs, 即使不使用加密安全措施, 也旨在提供与使用 layer 2 backbone (例如 Frame Relay) 时可获得的安全级别等价的安全性. 也就是说, 在不存在错误配置或不同 VPNs 被故意互连的情况下, 一个 VPN 中的 systems 不可能访问另一个 VPN 中的 systems. 当然, 本文描述的方法本身不会为了保密而加密数据, 也不提供判断数据在传输途中是否被篡改的方式. 如果需要这些能力, 必须另外应用加密措施. (参见例如 [MPLS/BGP-IPsec].) Section 13 更详细地讨论安全性.