跳到主要内容

RFC 4659 - BGP-MPLS IP 虚拟专用网络 (VPN) 对 IPv6 VPN 的扩展

  • 状态: 提议标准
  • 发布日期: 2006 年 9 月
  • 文档流: IETF
  • 勘误: 无勘误

文档信息​

  • RFC 编号: 4659
  • 标题: BGP-MPLS IP 虚拟专用网络 (VPN) 对 IPv6 VPN 的扩展
  • 作者: J. De Clercq, D. Ooms, M. Carugi, F. Le Faucheur
  • 日期: 2006 年 9 月
  • 类别: 标准轨道
  • ISSN: 2070-1721

摘要​

本文档描述了一种方法, 服务提供商可以利用其分组交换骨干网为 IPv6 客户提供虚拟专用网络 (VPN) 服务. 该方法复用并在必要时扩展"BGP/MPLS IP VPN"方法以支持 IPv6. 在 BGP/MPLS IP VPN 中, "Multiprotocol BGP"用于在服务提供商骨干网上分发 IPv4 VPN 路由, MPLS 用于通过骨干网转发 IPv4 VPN 数据包. 本文档定义了 IPv6 VPN 地址族, 并描述了"Multiprotocol BGP"中相应的 IPv6 VPN 路由分发. 本文档定义了在 IPv4 和 IPv6 骨干网上提供 IPv6 VPN 服务的支持, 以及在核心网中使用 MPLS、IP-in-IP、通用路由封装 (GRE) 和 IPsec 保护隧道等多种隧隧道技术. IPv4 站点与 IPv6 站点之间的互通不在本文档范围内.

本备忘录状态​

本文规格了互联网社区的互联网标准跟踪协议,并要求讨论和建议改进.请参阅"互联网官方协议标准" (STD 1) 的当前版本,了解该协议的标准化状态和状态.本备忘录的发行是无限的.

版权声明​

版权所有 (C) 互联网社会 (2006).

目录​

1. 简介​

本文描述了服务提供商可以使用其包交换后台为其IPv6客户提供虚拟专用网络服务的方法.

该方法复用并在必要时扩展 [BGP/MPLS-VPN] 的方法以支持 IPv6. 具体而言, 它采用与 [BGP/MPLS-VPN] 相同的"对等模型": 客户边缘路由器 (CE 路由器) 将 IPv6 路由发送给服务提供商边缘路由器 (PE 路由器). 随后, 服务提供商使用 BGP (Border Gateway Protocol, [BGP, BGP-MP]) 在连接到同一 IPv6 VPN 的 PE 路由器之间交换该 VPN 的路由. 最终, PE 路由器向特定 VPN 中的 CE 路由器分发来自该 VPN 其他 CE 路由器的 IPv6 路由. 与 IPv4 VPN 一样, 此对等模型的关键特征是 IPv6 VPN 内的 CE 路由器彼此不建立对等关系, IPv6 VPN 的路由算法看不到任何"覆盖网络".

本文采用[BGP/MPLS-VPN]中描述的定义,缩写和机制.除非另有说明,否则[BGP/MPLS-VPN]的机制适用,不会在这里重新描述.

据说VPN是一个IPv6 VPN,当每个VPN的站点都能使用IPv6并且通过IPv6接口或子接口通过Propiler Edge设备 (PE) 连接到服务提供商 (SP) 后台时.

站点可能既能 IPv4 并且能 IPv6. 包裹到达 PE 的逻辑接口可以确定 IP 版本. 另有,可以用于 IPv4 和 IPv6 两个,在这种情况下,每包的查找在 IP 包头版本字段确定 IP 版本.

本文只涉及在 IPv6 能力的站点上位于的IPv6 主机之间的IPv6通信处理.在 IPv4 能力的站点上位于的IPv4 主机之间的IPv4通信处理是本文范围之外的,并且被涵盖在 [BGP/MPLS-VPN].在 IPv4 能力的站点上位于的IPv4 主机和在 IPv6 能力的站点上位于的IPv6 主机之间的通信是本文范围之外的.

与 [BGP/MPLS-VPN] 分发 IPv4 VPN 路由的方式类似, BGP 及其扩展用于把某个 IPv6 VPN 站点的路由分发给连接到同一 IPv6 VPN 站点的所有其他 PE 路由器. PE 使用 VPN 路由和转发表 (VPN Routing and Forwarding table, VRF) 分别维护每个 IPv6 VPN 的可达性信息和转发信息.

与 [BGP/MPLS-VPN] 中的 IPv4 VPN 一样, 每个 IPv6 VPN 都可以拥有自己的 IPv6 地址空间, 因而同一地址在不同 VPN 中可以表示不同系统. 这是通过新的 VPN-IPv6 地址族实现的. 与 [BGP/MPLS-VPN] 定义的 VPN-IPv4 地址族类似, 该地址族在 IP 地址前附加一个路由区分器 (Route Distinguisher, RD).

除了通过MPLS标签交换路径 (LSP) 运行,IPv4 BGP/MPLS VPN解决方案也被扩展,允许使用其他隧道技术,包括GRE道,IP-in-IP道 [2547-GRE/IP],L2TPv3道 [MPLS-in-L2TPv3],IPsec保护道 [2547-IPsec].类似的方式,该文件允许支持IPv6 VPN服务通过MPLS LSP,以及其他隧道技术.

该文件允许支持IPv6 VPN服务通过IPv4骨干网,以及IPv6骨干网.支持的IPv6 VPN服务在两种情况下都是一样的.

在本文中定义的IPv6 VPN解决方案提供以下优势:

  • 从服务提供商和客户的角度来看,可以支持IPv6站点的VPN服务与可支持IPv4站点的VPN服务是一致的.

  • 从服务提供商的角度来看,IPv6 VPN服务的运行需要与IPv4 VPN服务相同的技能,程序和机制.

  • 在IPv4 VPN和IPv6 VPN服务均通过IPv4核心支持的情况下,可以 (MAY)用于两者均使用相同的MP-BGP同等关系和相同的PE-PE道网.

  • IPv6 VPN 服务独立于核心运行 IPv4 或 IPv6 服务.这就是为什么在 IPv4 转移至 IPv6 之后支持的 IPv6 VPN 服务对VPN 客户来说是不可区分的.

请注意,支持IPv4 VPN服务在IPv6核心上并未被本文涵盖.

2. VPN-IPv6 地址族​

BGP Multiprotocol Extensions [BGP-MP] 允许 BGP 携带多个地址族的路由. 本文引入 VPN-IPv6 地址族, 它与 [BGP/MPLS-VPN] 引入的 VPN-IPv4 地址族类似.

一个VPN-IPv6地址是一个24 octet的数量,从8 个八位字节的"路由区分器" (RD) 开始,并以16 octet的IPv6地址结束.

RD 的目的仅仅是允许一个人创建不同的路由到一个共同的IPv6地址前,这与 [BGP/MPLS-VPN]定义的 RD 的目的相似.就像每个 [BGP/MPLS-VPN] 实现的样子, RD 可以用来创建多个不同的路由到同一系统.这可以通过创建两个不同的VPN-IPv6路由,具有相同的IPv6部分,但不同的 RD. 这允许提供商的BGP安装多个不同的路由到同一系统,并允许使用政策来决定哪些包使用哪些路由.

此外,如果两个VPN使用相同的IPv6地址前 (有效表示不同的物理系统),PE将将这些转化为使用不同的RD的独特VPN-IPv6地址前.这确保如果同一地址在两个不同的VPN中使用,可以安装两个完全不同的路由,一个为每个VPN.

由于VPN-IPv6地址和IPv6地址属于不同的地址家庭,BGP从来没有将它们视为相似的地址.

一个VRF可能具有多个相同成本的VPN-IPv6路由,用于单个IPv6地址前.当一个包的目的地地址与VPN-IPv6路由相匹配时,只有IPv6部分才会真正匹配.

路由区分器格式和编码是按照 [BGP/MPLS-VPN] 规定的.

当一个站点能够 IPv4 和 IPv6 时,相同的 RD MAY用于IPv6 地址和IPv4 地址的广告.另有,可以 (MAY)用于IPv4 地址和IPv6 地址的广告.然而,请注意,在本规范范围内,IPv4 地址和IPv6 地址将始终在单独的背景下处理,并不会讨论IPv4-IPv6互动问题和技术.

3. VPN-IPv6 路由分发​

3.1. PE 之间通过 BGP 分发路由​

根据[BGP/MPLS-VPN]的描述,如果VPN的两个站点连接到同一自治系统中的PE,PE可以 (MAY)通过内部 (IPv4) 边境网关协议 (iBGP) 连接来分发VPN路由.

通过MP-BGP [BGP-MP]来交换IPv6 VPN中IPv6预先设的可访问性信息,从而宣布自己是BGP Next Hop.

接入可访问性信息和BGP Next Hop地址编码的规则在以下部分中详细说明.

3.2. VPN IPv6 NLRI 编码​

分发 IPv6 VPN 路由时, 通告方 PE 路由器 MUST 为这些路由分配并分发 MPLS 标签. 严格来说, PE 路由器分发的不是普通 IPv6 VPN 路由, 而是带标签的 IPv6 VPN 路由 [MPLS-BGP]. 当通告方 PE 收到携带该已通告标签的数据包时, 它会从 MPLS 标签栈中弹出该标签并适当处理数据包, 即根据标签直接转发, 或在相应的 IPv6-VPN 上下文中执行查找.

BGP Multiprotocol Extensions [BGP-MP] 用于在 MP_REACH 网络层可达性信息 (NLRI) 中通告 IPv6 VPN 路由. 地址族标识符 (AFI) 和后续地址族标识符 (SAFI) 字段 MUST 设置如下:

  • AFI: 2; 用于 IPv6

  • SAFI: 128; 用于带 MPLS 标签的 VPN-IPv6

NLRI 字段本身按照 [MPLS-BGP] 编码. 在本扩展中, 前缀属于 VPN-IPv6 地址族, 因此由 8 个八位字节的路由区分器和第 2 节所述的 IPv6 前缀组成.

3.2.1. BGP 下一跳编码​

BGP Next Hop 的编码取决于 BGP 扬声器的政策是要求将 IPv6 VPN 流量运输到 BGP Next Hop 通过 IPv6 道 ("要求 IPv6 运输的 BGP 扬声器") 或使用 IPv4 道 ("要求 IPv4 运输的 BGP 扬声器").

定义该政策 (要求通过IPv4 隧道或IPv6 隧道运输) 是网络运营商的责任,它超出了本文的范围.请注意,该政策可能要求通过IPv4 (回应IPv6) 道运输,而BGP扬声器在IPv6 (回应IPv4) 上交换IPv6 VPN可访问性信息.然而,在这种情况下,有几个操作影响值得考虑.特别是,一个未发现的错误影响IPv4 (回应IPv4). 通过IPv6 隧道数据路径,并不会影响IPv6 (相应IPv4) 数据路径,BGP可能会保持不被检测,这反过来可能导致交通黑洞.

控制本政策不属于本文范围,可能基于用户配置.

3.2.1.1. 请求 IPv6 传输的 BGP 发言者​

当IPv6 VPN流量要通过IPv6 隧道运输到BGP扬声器时 (例如IPv6 MPLS LSP,IPsec保护的IPv6 隧道),BGP扬声器必须 (SHALL)广告包含VPN-IPv6地址的Next Hop网络地址字段

  • 设置为8 个八位字节 RD为零,

  • 设置为广告BGP扬声器的全球IPv6地址.

后面可能会出现另一个VPN-IPv6地址

  • 设置为8 个八位字节 RD为零,

  • 设置为广告BGP扬声器的链接本地IPv6地址.

在 MP_REACH_NLRI属性中,下一个Hop网络地址字段长度值应设置为24只存在全球地址时,如果下一个Hop字段中也包含链接本地地址时,则设置为48.

如果BGP扬声器仅使用其链接本地IPv6地址 (例如,在IPv6 CE与IPv6PE同等的情况下,CE没有IPv6全球地址,并在链接本地地址上实现eBGP同等),广告BGP扬声器使用"未指定地址" ([V6ADDR]) 来表示下一个跳转网络地址领域中全球IPv6地址的缺失.

链接本地地址应在Next Hop字段中包含,如果广告BGP扬声器与同行广告路由的 [BGP-IPv6]分享一个共同的子网,并且只有这样.

在其他情况下,BGP扬声器在Next Hop网络地址字段中向其同行宣传,只会宣传下一个跳的全球IPv6地址.

因此,广告通向内部同行的BGP扬声器可能通过删除下一个跳转的链接本地IPv6地址来修改Next Hop的网络地址字段.

举例来说,BGP Next Hop地址领域将包括全球IPv6地址和链接本地IPv6地址,即IPv6 VPN服务通过多自主系统 (AS) 支持,并重新分配标记为VPN-

互联网系统的自主系统边界路由器 (ASBR) 之间IPv6路由:在这种情况下,ASBR将公布全球IPv6地址和链接本地IPv6地址.

3.2.1.2. 请求 IPv4 传输的 BGP 发言者​

当IPv6 VPN流量要通过IPv4 隧道运输到BGP扬声器时 (例如IPv4 MPLS LSP,IPsec保护的IPv4 隧道),BGP扬声器必须 (SHALL)向其同行宣传包含VPN-IPv6地址的Next Hop网络地址字段:

  • 设置为8 个八位字节 RD为零,

  • 具有16 octet的IPv6地址是包含广告BGP扬声器的IPv4地址的IPv4地址[V6ADDR]编码为IPv4映射的IPv6地址.该IPv4地址必须由其他BGP扬声器进行路由.

3.3. 路由目标​

路由目标的使用在 [BGP/MPLS-VPN] 中指定,适用于IPv6 VPN.扩展社区属性的编码定义在 [BGP-EXTCOM].

3.4. BGP 能力协商​

为了让两个私营企业交换标记为IPv6 VPNNLRI,它们必须 (MUST)使用BGP能力谈判,以确保他们都能够正确处理这些NLRI. 这是在 [BGP-MP]和 [BGP-CAP]中规定的,使用能力代码1 (多协议BGP),使用上述3.2节所规定的AFI和SAFI值.

4. 封装​

入口 PE 路由器 MUST 将 IPv6 VPN 数据通过骨干网隧道传送到出口 PE 路由器; 该出口 PE 路由器由相应目标 IPv6 VPN 前缀的 BGP Next Hop 标识.

当BGP Next Hop字段中包含的16 octetIPv6地址被编码为IPv4映射IPv6地址 (见3.2.1.2节),入口PE必须 (MUST)使用IPv4 隧道,除非明确配置以做其他事情.入口PE可 (MAY)通过明确配置允许使用IPv6 隧道,当BGP Next Hop字段中包含的16 octetIPv6地址被编码为IPv4映射IPv6地址. 这将允许支持特定的部署环境,其中希望进行IPv6 隧道,但IPv4映射的IPv6地址在IPv6地址而不是全球IPv6地址而不是IPv6地址.

当BGP Next Hop字段中包含的16 octetIPv6地址未被编码为IPv4地址 (见 3.2.1.1节),入口PE必须 (MUST)使用IPv6 隧道.

当PE从附加 CE 接收一个包时,它会在相应 CE 的 VRF 中查找该包的 IPv6 目的地地址.这使其能够找到VPN-IPv6 路由.VPN-IPv6 路由将有一个相关 MPLS 标签和相关 BGP Next Hop.首先,这个 MPLS 标签被按在包上作为下面的标签.然后,这个标签的包被封装在道中运输到 BGP Next Hop 所识别的出口.该封装的细节取决于实际隧道技术,如下:

与 IPv4 VPN 的 MPLS/BGP [2547-GRE/IP] 相同, 使用 IPv4 或 IPv6 隧道 (分别为 IPv4 GRE 或 IPv6 GRE 隧道) 时, 带标签 IPv6 VPN 数据包按照 [MPLS-in-IP/GRE] 封装为 MPLS-in-IP (或 MPLS-in-GRE) 数据包. 使用 L2TPv3 时, 带标签 IPv6 VPN 数据包按照 [MPLS-in-L2TPv3] 封装为 MPLS-in-L2TPv3 数据包.

与IPv4 VPN的MPLS/BGP一样,当通过IPsec安全道 [2547-IPsec]进行道时,标记为IPv6 VPN 数据包的封装结果是MPLS-in-IP或MPLS-in-GRE封装包 [MPLS-in-IP/GRE].IPsec运输模式用于保护IPv4或GRE道从入口PE到出口PE.

使用 IPv4 隧道时 (无论是否由 IPsec 保护), 入口 PE 路由器 MUST 把 BGP Next Hop 字段中 IPv4-mapped IPv6 address 所编码的 IPv4 地址用作所添加 IPv4 隧道头的目标地址, 并使用自身的某个 IPv4 地址作为该隧道头的源地址.

使用 IPv6 隧道时 (无论是否由 IPsec 保护), 入口 PE 路由器 MUST 把 BGP Next Hop 字段的 IPv6 地址字段中所含地址用作所添加 IPv6 隧道头的目标地址, 并使用自身的某个 IPv6 地址作为该隧道头的源地址.

通过MPLS LSP进行道挖掘时,可以使用任何标签分配技术 (LDP [LDP],RSVP-TE [RSVP-TE]等) 建立LSP.

使用 MPLS LSP 进行隧道传输时, 入口 PE 路由器 MUST 直接把 LSP 隧道标签压入带标签 IPv6 VPN 数据包的标签栈, 即不添加任何 IPv4 或 IPv6 头. 该标签对应从入口 PE 路由器开始、在出口 PE 路由器结束的 LSP. BGP Next Hop 字段用于确定出口 PE 路由器, 进而确定要压入标签栈的标签. 如果 BGP Next Hop 字段中的 IPv6 地址是 IPv4-mapped IPv6 address, 则由其中嵌入的 IPv4 地址确定要压入的隧道标签; 否则由该字段中的 IPv6 地址确定隧道标签.

为了确保实现本VPN架构的系统之间的互操作性,所有这些系统都必须 (MUST)支持通过LDP建立的MPLS LSP使用道. [LDP]

5. 地址类型​

由于Link-local unicast地址仅用于单个链接,因此这些地址可以在PE-CE链接上使用,但它们不支持在IPv6 VPN站点上可访问性,并且从未通过多协议边境网关协议 (MP-BGP) 广告远程PE.

全球单元化地址被定义为IPv6互联网任何地方的独特识别接口.全球地址预计将在IPv6 VPN站点内和跨域使用.它们显然是由此IPv6 VPN解决方案支持的,以便在IPv6 VPN站点上可访问,并通过MP-BGP向远程私营企业进行广告,并且没有任何具体考虑其全球范围.

引用[UNIQUE-LOCAL]: "本文定义了一个全球独特的IPv6单元地址格式,用于本地通信 [IPv6].这些地址被称为独特本地IPv6单元地址,并在本文中简称本地IPv6地址.它们不预计在全球互联网上可路由.它们可以在一个更有限的区域内路由,例如站点.它们也可以在有限的站点之间路由.

  • [UNIQUE-LOCAL] also says in its Section 4.7: "Local IPv6 addresses can be used for inter-site Virtual Private Networks (VPN) if appropriate routes are set up. Because the addresses are unique these VPNs will work reliably and without the need for translation. They have the additional property that they will continue to work if the individual sites are renumbered or merged."

根据此,本文中规定的IPv6 VPN解决方案支持独特本地IPv6单独地址,以便在IPv6 VPN站点上实现可访问性.因此,通过MP-BGP向远程PEs广告可通过此类独特本地IPv6地址,并通过全球单独地址进行PEs的处理.

建议和考虑在给定的IPv6 VPN环境中应用于哪些支持的地址类型,不属于本文档的范围.

6. 组播​

多媒体运营不属于本文范围.

7. 运营商的运营商​

有时,IPv6 VPN可能是IPv6ISP的网络,其自己的同行和路由政策.有时,IPv6 VPN可能是SP的网络,其反过来向其自己的客户提供VPN服务.像这些IPv6 VPN一样,也可以从另一SP,即"运输商运输商"获得脊柱服务,使用[BGP/MPLS-VPN]第9节所描述的运输商运输商方法,但适用于IPv6流量. 对于IPv6 VPN,IPv4 VPN运营商运营商 (carrier) 的所有考虑都适用于IPv6 VPN,除了PE和CE之间的MPLS (包括标签分布) 使用涉及IPv6路由而不是IPv4路由. [BGP/MPLS-VPN]

8. 多 AS 骨干网​

[BGP/MPLS-VPN]第10节所述的相同程序可用于解决IPv6 VPN两个站点连接到不同的自主系统的情况.

在 IPv6 VPN 应用时,这些程序在本节的其他部分中详细描述.

方法 (a):在AS (自主系统)边境路由器的VRF到VRF连接.

这种方法对IPv6 VPN相当于[BGP/MPLS-VPN]第10节的程序 (a).在IPv6 VPN的情况下,IPv6需要在ASBR间VRF到VRF (子) 接口上激活.在这种方法中,ASBR交换IPv6路由 (与VPN-IPv6路由相比),并且可能在IPv6或IPv4上进行交换.IPv6路由必须 (MUST)按照[BGP-IPv6].这种方法不使用AS间LSP.

最后,请注意,由于每个AS独立实施本文中描述的IPv6 VPN内部AS程序,参与的AS可能都会内部使用IPv4 隧道或IPv6 隧道;或另有,一些参与的AS可能会内部使用IPv4 隧道,而其他则使用IPv6 隧道.

方法 (b):EBGP将标记为VPN-IPv6路由从AS到邻近AS的重新分配.

通过这种方法,ASBR使用EBGP将标记的VPN-IPv4路由重新分配给其他ASBR. [BGP/MPLS-VPN]

在此方法中, 是否在 ASBR 间链路上启用 IPv6 是可选的, 因为交换 VPN-IPv6 路由的 ASBR 可以通过 IPv4 或 IPv6 建立对等关系 (若通过 IPv6 建立对等关系, 显然必须在 ASBR 间链路上启用 IPv6). 带标签 VPN-IPv6 路由的交换 MUST 按照 [BGP-IPv6] 和 [MPLS-BGP] 执行. 当 VPN-IPv6 流量使用 IPv6 隧道传输时, BGP Next Hop 字段 SHALL 包含 IPv6 地址. 当 VPN-IPv6 流量使用 IPv4 隧道传输时, BGP Next Hop 字段 SHALL 包含编码为 IPv4-mapped IPv6 address 的 IPv4 地址.

这种方法需要存在AS间LSP. 因此,[BGP/MPLS-VPN]第10节程序 (b) 所描述的相应 (安全) 考虑对IPv6的这种方法也适用于.

最后,请注意,与此程序一样,与程序 (a) 一样,由于每个AS独立实施本文中描述的IPv6 VPN内部AS程序,参与的AS都可能会内部使用IPv4 隧道或IPv6 隧道;另有,一些参与的AS可能会内部使用IPv4 隧道,而其他则使用IPv6 隧道.

方法 (c):源和目的地ASES之间标记的VPN-IPv6路由的多hopEBGP重新分配,从AS到邻近AS的标记的IPv4或IPv6路由的EBGP重新分配.

根据 [BGP/MPLS-VPN]第10节的程序 (c) 交换VPN-IPv6路由的方法,该方法相当于交换VPN-IPv4路由.

这种方法要求参与的ASE要么使用IPv4 隧道,要么使用IPv6 隧道.

在此方法中, ASBR 路由器既不维护也不分发 VPN-IPv6 路由, 且无须支持双协议栈. ASBR 需要维护通往本 AS 内 PE 路由器的带标签 IPv4 (或 IPv6) 路由, 并使用 EBGP 将这些路由分发给其他 AS. 各传输 AS 中的 ASBR 同样必须通过 EBGP 继续传递这些带标签 IPv4 (或 IPv6) 路由, 从而建立一条从入口 PE 路由器到出口 PE 路由器的 IPv4 (或 IPv6) 标签交换路径. 不同 AS 中的 PE 路由器随后可以通过 IPv4 或 IPv6 相互建立多跳 EBGP 连接, 并在这些连接上交换带标签 VPN-IPv6 路由. 使用 IPv6 隧道时, 这些 VPN-IPv6 路由的 BGP Next Hop 字段包含 IPv6 地址; 使用 IPv4 隧道时, 该字段包含 IPv4-mapped IPv6 address.

[BGP/MPLS-VPN]第10节程序 (c) 所述考虑因素,包括可能使用路由反射器,可能使用第三标签以及跨越多个ASS的LSP,均适用于此IPv6 VPN方法.

9. 从 VPN 访问互联网​

[BGP/MPLS-VPN]提出的访问全球IPv4互联网的方法可以在IPv6 VPN和全球IPv6互联网的背景下使用.但请注意,如果IPv6来自IPv6 VPN站点的IPv6包,并注定用于全球IPv6互联网,需要穿越SP脊柱,如果这是IPv4仅脊柱,这些包必须通过IPv4脊柱进行道.

显然,像VPN文本之外的情况一样,从IPv6 VPN访问IPv6互联网需要使用全球IPv6地址.

特别是在IPv6互联网访问中,不能使用唯一的本地IPv6地址.

10. 管理 VPN​

[BGP/MPLS-VPN]第12节讨论的管理考虑适用于IPv6 VPN的管理.

在服务提供商管理IPv6 VPN站点的CE的情况下,服务提供商可以选择使用IPv4来管理工具和CE之间的通信.在这种情况下,无论客户的IPv4站点是否实际上连接到CE (除了IPv6站点外),CE实际上是IPv4 VPN的一部分,除了属于IPv6 VPN之外 (即CE附加到支持IPv4的VRF外). 根据 [BGP/MPLS-VPN]提出的考虑,如何确保管理工具能够从多个VPN中与这些管理的CE通信,而不会允许不同VPN的CE之间不受欢迎的可访问性,适用于CE附加的VRF的IPv4可访问性.

在服务提供商管理IPv6 VPN站点的CE时,服务提供商可以选择使用IPv6来管理工具和CE之间的通信,以实现此类管理目的.在 [BGP/MPLS-VPN]中提出的考虑,关于如何确保管理工具可以从多个VPN中与此类管理的CE通信,而不允许不同VPN的CE之间不受欢迎的可访问性,则适用于CE附加的VRF的IPv6可访问性.

11. 安全注意事项​

在本文中定义的扩展允许MP-BGP传播IPv6 VPN路由的可访问性信息.

使用BGP运输IPv6可访问性信息的安全考虑在RFC2545第5节讨论,同样适用于本文描述的扩展.

本文描述的扩展提供IPv6 VPN的方法使用了如[BGP/MPLS-VPN]所述的方法.因此,与[BGP/MPLS-VPN]第13节所述的数据平面安全,控制平面安全和PE和P设备安全相同的安全考虑.

12. 服务质量​

由于[BGP/MPLS-VPN]第14节[BGP/MPLS-VPN]中讨论的所有QoS机制都以相同的方式运行IPv4和IPv6 (Diffserv, Intserv,MPLS交通工程),中讨论的QoS考虑对IPv6 VPN同样适用 (这也适用于IPv4 隧道或IPv6 隧道是否在脊椎部使用).

13. 可扩展性​

根据 [BGP/MPLS-VPN]第15节,为IPv4 VPN总结的可扩展性考虑中的每个都适用于IPv6 VPN.

14. IANA 注意事项​

本文规定 (见3.2节) 使用BGP AFI (地址家族识别符) 值 2,以及BGP SAFI (后续地址家族识别符) 值 128,来表示本文定义的"VPN-IPv6标签地址"地址家族.

对于IPv6使用AFI值2是目前IANA注册表"地址家族识别符"中所指定的,因此IANA不需要采取任何行动.

对于"MPLS标记的VPN地址"使用SAFI值128是目前IANA注册表"后续地址家庭识别器"中所指定的,因此IANA不需要采取任何行动.

15. 致谢​

我们想感谢为此文件做出贡献的杰拉德·加斯塔德和埃里克·莱维·阿贝格诺利.

纪念​

作者们想表达Tri T. Nguyen在2002年4月因突然患病而去世的价值贡献.

16. 参考文献​

16.1. 规范性参考文献​

  • [BGP/MPLS-VPN] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.

  • [BGP-EXTCOM] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006.

  • [BGP-MP] Bates, T., Rekhter, Y., Chandra, R., and D. Katz, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.

  • [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.

  • [MPLS-BGP] Rekhter, Y. and E. Rosen, "Carrying Label Information in BGP-4", RFC 3107, May 2001.

  • [BGP-CAP] Chandra, R. and J. Scudder, "Capabilities Advertisement with BGP-4", RFC 3392, November 2002.

  • [LDP] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "LDP Specification", RFC 3036, January 2001.

  • [BGP-IPv6] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing", RFC 2545, March 1999.

16.2. 资料性参考文献​

  • [V6ADDR] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.

  • [UNIQUE-LOCAL] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.

  • [2547-GRE/IP] Rekhter and Rosen, "Use of PE-PE GRE or IP in RFC2547 VPNs", Work in Progress.

  • [2547-IPsec] Rosen, De Clercq, Paridaens, T'Joens, Sargor, "Use of PE-PE IPsec in RFC2547 VPNs", Work in Progress, August 2005.

  • [RSVP-TE] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.

  • [MPLS-in-IP/GRE] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005.

  • [MPLS-in-L2TPv3] Townsley, M., et al., "Encapsulation of MPLS over Layer-2 Tunneling Protocol Version 3", Work in Progress, February 2006.

  • [BGP] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.

作者地址​

Jeremy De Clercq
Alcatel
Copernicuslaan 50, 2018 Antwerpen, Belgium

EMail: [email protected]

Dirk Ooms
OneSparrow
Belegstraat 13, 2018 Antwerpen, Belgium

EMail: [email protected]

Marco Carugi
Nortel Networks S.A.
Parc d'activites de Magny-Les Jeunes Bois CHATEAUFORT
78928 YVELINES Cedex 9 - France

EMail: [email protected]

Francois Le Faucheur
Cisco Systems, Inc.
Village d'Entreprise Green Side - Batiment T3
400, Avenue de Roumanille
06410 Biot-Sophia Antipolis
France

EMail: [email protected]

完整版权声明​

版权所有 (C) 互联网社会 (2006).

本文受BCP 78所载的权利,许可和限制,除了其中所述,作者保留所有权利.

本文和其中所载信息均以"如有"为基础提供,并提供者,所代表或赞助的组织 (如果有),互联网社会和互联网工程工作者力量,均声明所有保证,包括但不限于任何保证,在此信息的使用不会侵犯任何权利或任何保证,

知识产权​

国际贸易基金对任何涉及本文描述技术实施或使用的知识产权或其它权利的有效性或范围,以及在这些权利下的任何许可可能或可能无法获得的程度,并没有采取立场;也没有表示它已做出任何独立努力确定这些权利.有关RFC文件中的权利程序的信息可以在BCP 78和BCP 79中找到.

通过IETF在线知识产权存储库获取IETF秘书处提交的知识产权披露文件和将提供许可证的任何保证,或者通过实施者或本规范的用户获得此类专利权使用的一般许可或许可的结果.

国际贸易法委员会邀请任何有兴趣的方,请向其提醒,任何涉及实施本标准可能需要技术的版权,专利或专利申请或其他专利权.请向国际贸易法委员会发送信息以 [email protected].

致谢​

国际电信基金管理支持活动 (IASA) 为RFC编辑功能提供资金.

最后于 更新