BGP/MPLS IPv6 VPN: BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN
How a service provider carries IPv6 private networks over its own packet backbone.
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, <https://www.rfc-editor.org/info/rfc4659>.
@misc{rfc4659,
series = {Request for Comments},
number = 4659,
howpublished = {RFC 4659},
publisher = {RFC Editor},
doi = {10.17487/RFC4659},
url = {https://www.rfc-editor.org/info/rfc4659},
author = {J. De Clercq and D. Ooms and M. Carugi and F. Le Faucheur},
title = {{BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN}},
pagetotal = 18,
year = 2006,
month = sep,
} RFC text
Contents
Network Working Group J. De Clercq
Request for Comments: 4659 Alcatel
Category: Standards Track D. Ooms
OneSparrow
M. Carugi
Nortel Networks
F. Le Faucheur
Cisco Systems
September 2006
BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN
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.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes a method by which a Service Provider may use
its packet-switched backbone to provide Virtual Private Network (VPN)
services for its IPv6 customers. This method reuses, and extends
where necessary, the "BGP/MPLS IP VPN" method for support of IPv6.
In BGP/MPLS IP VPN, "Multiprotocol BGP" is used for distributing IPv4
VPN routes over the service provider backbone, and MPLS is used to
forward IPv4 VPN packets over the backbone. This document defines an
IPv6 VPN address family and describes the corresponding IPv6 VPN
route distribution in "Multiprotocol BGP".
This document defines support of the IPv6 VPN service over both an
IPv4 and an IPv6 backbone, and for using various tunneling techniques
over the core, including MPLS, IP-in-IP, Generic Routing
Encapsulation (GRE) and IPsec protected tunnels. The inter-working
between an IPv4 site and an IPv6 site is outside the scope of this
document.
Table of Contents
1. Introduction ....................................................2
2. The VPN-IPv6 Address Family .....................................4
3. VPN-IPv6 Route Distribution .....................................5
3.1. Route Distribution Among PEs by BGP ........................5
3.2. VPN IPv6 NLRI Encoding .....................................6
3.2.1. BGP Next Hop encoding ...............................6
3.2.1.1. BGP Speaker Requesting IPv6 Transport ......7
3.2.1.2. BGP Speaker Requesting IPv4 Transport ......8
3.3. Route Target ...............................................8
3.4. BGP Capability Negotiation .................................8
4. Encapsulation ...................................................8
5. Address Types ..................................................10
6. Multicast ......................................................11
7. Carriers' Carriers .............................................11
8. Multi-AS Backbones .............................................11
9. Accessing the Internet from a VPN ..............................13
10. Management VPN ................................................14
11. Security Considerations .......................................14
12. Quality of Service ............................................15
13. Scalability ...................................................15
14. IANA Considerations ...........................................15
15. Acknowledgements ..............................................15
16. References ....................................................16
16.1. Normative References .....................................16
16.2. Informative References ...................................16
1. Introduction
This document describes a method by which a Service Provider may use
its packet-switched backbone to provide Virtual Private Network
services for its IPv6 customers.
This method reuses, and extends where necessary, the "BGP/MPLS IP
VPN" method [BGP/MPLS-VPN] for support of IPv6. In particular, this
method uses the same "peer model" as [BGP/MPLS-VPN], in which the
customers' edge routers ("CE routers") send their IPv6 routes to the
Service Provider's edge routers ("PE routers"). BGP ("Border Gateway
Protocol", [BGP, BGP-MP]) is then used by the Service Provider to
exchange the routes of a particular IPv6 VPN among the PE routers
that are attached to that IPv6 VPN. Eventually, the PE routers
distribute, to the CE routers in a particular VPN, the IPv6 routes
from other CE routers in that VPN. As with IPv4 VPNs, a key
characteristic of this "peer model" is that the (IPv6) CE routers
within an (IPv6) VPN do not peer with each other; there is no
"overlay" visible to the (IPv6) VPN's routing algorithm.
This document adopts the definitions, acronyms, and mechanisms
described in [BGP/MPLS-VPN]. Unless it is stated otherwise, the
mechanisms of [BGP/MPLS-VPN] apply and will not be re-described here.
A VPN is said to be an IPv6 VPN when each site of this VPN is IPv6
capable and is natively connected over an IPv6 interface or sub-
interface to the Service Provider (SP) backbone via a Provider Edge
device (PE).
A site may be both IPv4 capable and IPv6 capable. The logical
interface on which packets arrive at the PE may determine the IP
version. Alternatively, the same logical interface may be used for
both IPv4 and IPv6, in which case a per-packet lookup at the Version
field of the IP packet header determines the IP version.
This document only concerns itself with handling of IPv6
communication between IPv6 hosts located on IPv6-capable sites.
Handling of IPv4 communication between IPv4 hosts located on IPv4-
capable sites is outside the scope of this document and is covered in
[BGP/MPLS-VPN]. Communication between an IPv4 host located in an
IPv4- capable site and an IPv6 host located in an IPv6-capable site
is outside the scope of this document.
In a similar manner to how IPv4 VPN routes are distributed in
[BGP/MPLS-VPN], BGP and its extensions are used to distribute routes
from an IPv6 VPN site to all the other PE routers connected to a site
of the same IPv6 VPN. PEs use "VPN Routing and Forwarding tables"
(VRFs) to maintain the reachability information and forwarding
information of each IPv6 VPN separately.
As is done for IPv4 VPNs [BGP/MPLS-VPN], we allow each IPv6 VPN to
have its own IPv6 address space, which means that a given address may
denote different systems in different VPNs. This is achieved via a
new address family, the VPN-IPv6 Address Family, in a fashion similar
to that of the VPN-IPv4 address family, defined in [BGP/MPLS-VPN],
which prepends a Route Distinguisher to the IP address.
In addition to its operation over MPLS Label Switched Paths (LSPs),
the IPv4 BGP/MPLS VPN solution has been extended to allow operation
over other tunneling techniques, including GRE tunnels, IP-in-IP
tunnels [2547-GRE/IP], L2TPv3 tunnels [MPLS-in-L2TPv3], and IPsec
protected tunnels [2547-IPsec]. In a similar manner, this document
allows support of an IPv6 VPN service over MPLS LSPs, as well as over
other tunneling techniques.
This document allows support for an IPv6 VPN service over an IPv4
backbone, as well as over an IPv6 backbone. The IPv6 VPN service
supported is identical in both cases.
The IPv6 VPN solution defined in this document offers the following
benefits:
o From both the Service Provider perspective and the customer
perspective, the VPN service that can be supported for IPv6
sites is identical to the one that can be supported for IPv4
sites.
o From the Service Provider perspective, operations of the IPv6
VPN service require the exact same skills, procedures, and
mechanisms as those for the IPv4 VPN service.
o Where both IPv4 VPNs and IPv6 VPN services are supported over an
IPv4 core, the same single set of MP-BGP peering relationships
and the same single PE-PE tunnel mesh MAY be used for both.
o The IPv6 VPN service is independent of whether the core runs
IPv4 or IPv6. This is so that the IPv6 VPN service supported
before and after a migration of the core from IPv4 to IPv6 is
undistinguishable to the VPN customer.
Note that supporting IPv4 VPN services over an IPv6 core is not
covered by this document.
2. The VPN-IPv6 Address Family
The BGP Multiprotocol Extensions [BGP-MP] allow BGP to carry routes
from multiple "address families". We introduce the notion of the
"VPN-IPv6 address family", which is similar to the VPN-IPv4 address
family introduced in [BGP/MPLS-VPN].
A VPN-IPv6 address is a 24-octet quantity, beginning with an 8-octet
"Route Distinguisher" (RD) and ending with a 16-octet IPv6 address.
The purpose of the RD is solely to allow one to create distinct
routes to a common IPv6 address prefix, which is similar to the
purpose of the RD defined in [BGP/MPLS-VPN]. In the same way as it
is possible per [BGP/MPLS-VPN], the RD can be used to create multiple
different routes to the very same system. This can be achieved by
creating two different VPN-IPv6 routes that have the same IPv6 part
but different RDs. This allows the provider's BGP to install
multiple different routes to the same system and allows policy to be
used to decide which packets use which route.
Also, if two VPNs were to use the same IPv6 address prefix
(effectively denoting different physical systems), the PEs would
translate these into unique VPN-IPv6 address prefixes using different
RDs. This ensures that if the same address is ever used in two
different VPNs, it is possible to install two completely different
routes to that address, one for each VPN.
Since VPN-IPv6 addresses and IPv6 addresses belong to different
address families, BGP never treats them as comparable addresses.
A VRF may have multiple equal-cost VPN-IPv6 routes for a single IPv6
address prefix. When a packet's destination address is matched in a
VRF against a VPN-IPv6 route, only the IPv6 part is actually matched.
The Route Distinguisher format and encoding is as specified in
[BGP/MPLS-VPN].
When a site is IPv4 capable and IPv6 capable, the same RD MAY be used
for the advertisement of IPv6 addresses and IPv4 addresses.
Alternatively, a different RD MAY be used for the advertisement of
the IPv4 addresses and of the IPv6 addresses. Note, however, that in
the scope of this specification, IPv4 addresses and IPv6 addresses
will always be handled in separate contexts, and that no IPv4-IPv6
interworking issues and techniques will be discussed.
3. VPN-IPv6 Route Distribution
3.1. Route Distribution Among PEs by BGP
As described in [BGP/MPLS-VPN], if two sites of a VPN attach to PEs
that are in the same Autonomous System, the PEs can distribute VPN
routes to each other by means of an (IPv4) internal Border Gateway
Protocol (iBGP) connection between them. Alternatively, each PE can
have iBGP connections to route reflectors. Similarly, for IPv6 VPN
route distribution, PEs can use iBGP connections between them or use
iBGP connections to route reflectors. For IPv6 VPN, the iBGP
connections MAY be over IPv4 or over IPv6.
The PE routers exchange, via MP-BGP [BGP-MP], reachability
information for the IPv6 prefixes in the IPv6 VPNs and thereby
announce themselves as the BGP Next Hop.
The rules for encoding the reachability information and the BGP Next
Hop address are specified in the following sections.
3.2. VPN IPv6 NLRI Encoding
When distributing IPv6 VPN routes, the advertising PE router MUST
assign and distribute MPLS labels with the IPv6 VPN routes.
Essentially, PE routers do not distribute IPv6 VPN routes, but
Labeled IPv6 VPN routes [MPLS-BGP]. When the advertising PE then
receives a packet that has this particular advertised label, the PE
will pop this label from the MPLS stack and process the packet
appropriately (i.e., forward it directly according to the label or
perform a lookup in the corresponding IPv6-VPN context).
The BGP Multiprotocol Extensions [BGP-MP] are used to advertise the
IPv6 VPN routes in the MP_REACH Network Layer Reachability
Information (NLRI). The Address Family Identifier (AFI) and
Subsequent Address Family Identifier (SAFI) fields MUST be set as
follows:
- AFI: 2; for IPv6
- SAFI: 128; for MPLS labeled VPN-IPv6
The NLRI field itself is encoded as specified in [MPLS-BGP]. In the
context of this extension, the prefix belongs to the VPN-IPv6 Address
Family and thus consists of an 8-octet Route Distinguisher followed
by an IPv6 prefix as specified in Section 2, above.
3.2.1. BGP Next Hop encoding
The encoding of the BGP Next Hop depends on whether the policy of the
BGP speaker is to request that IPv6 VPN traffic be transported to
that BGP Next Hop using IPv6 tunneling ("BGP speaker requesting IPv6
transport") or using IPv4 tunneling ("BGP speaker requesting IPv4
transport").
Definition of this policy (to request transport over IPv4 tunneling
or IPv6 tunneling) is the responsibility of the network operator and
is beyond the scope of this document. Note that it is possible for
that policy to request transport over IPv4 (resp. IPv6) tunneling
while the BGP speakers exchange IPv6 VPN reachability information
over IPv6 (resp. IPv4). However, in that case, a number of
operational implications are worth considering. In particular, an
undetected fault affecting the IPv4 (resp. IPv6) tunneling data path
and not affecting the IPv6 (resp. IPv4) data path could remain
undetected by BGP, which in turn may result in black-holing of
traffic.
Control of this policy is beyond the scope of this document and may
be based on user configuration.
3.2.1.1. BGP Speaker Requesting IPv6 Transport
When the IPv6 VPN traffic is to be transported to the BGP speaker
using IPv6 tunneling (e.g., IPv6 MPLS LSPs, IPsec-protected IPv6
tunnels), the BGP speaker SHALL advertise a Next Hop Network Address
field containing a VPN-IPv6 address
- whose 8-octet RD is set to zero, and
- whose 16-octet IPv6 address is set to the global IPv6 address of
the advertising BGP speaker.
This is potentially followed by another VPN-IPv6 address
- whose 8-octet RD is set to zero, and
- whose 16-octet IPv6 address is set to the link-local IPv6
address of the advertising BGP speaker.
The value of the Length of the Next Hop Network Address field in the
MP_REACH_NLRI attribute shall be set to 24 when only a global address
is present, and to 48 if a link-local address is also included in the
Next Hop field.
If the BGP speakers peer using only their link-local IPv6 address
(for example, in the case where an IPv6 CE peers with an IPv6 PE,
where the CE does not have any IPv6 global address, and where eBGP
peering is achieved over the link-local addresses), the "unspecified
address" ([V6ADDR]) is used by the advertising BGP speaker to
indicate the absence of the global IPv6 address in the Next Hop
Network Address field.
The link-local address shall be included in the Next Hop field if and
only if the advertising BGP speaker shares a common subnet with the
peer the route is being advertised to [BGP-IPv6].
In all other cases, a BGP speaker shall advertise to its peer in the
Next Hop Network Address field only the global IPv6 address of the
next hop.
As a consequence, a BGP speaker that advertises a route to an
internal peer may modify the Network Address of Next Hop field by
removing the link-local IPv6 address of the next hop.
An example scenario where both the global IPv6 address and the link-
local IPv6 address shall be included in the BGP Next Hop address
field is that where the IPv6 VPN service is supported over a multi-
Autonomous System (AS) backbone with redistribution of labeled VPN-
IPv6 routes between Autonomous System Border Routers (ASBR) of
different ASes sharing a common IPv6 subnet: in that case, both the
global IPv6 address and the link-local IPv6 address shall be
advertised by the ASBRs.
3.2.1.2. BGP Speaker Requesting IPv4 Transport
When the IPv6 VPN traffic is to be transported to the BGP speaker
using IPv4 tunneling (e.g., IPv4 MPLS LSPs, IPsec-protected IPv4
tunnels), the BGP speaker SHALL advertise to its peer a Next Hop
Network Address field containing a VPN-IPv6 address:
- whose 8-octet RD is set to zero, and
- whose 16-octet IPv6 address is encoded as an IPv4-mapped IPv6
address [V6ADDR] containing the IPv4 address of the advertising
BGP speaker. This IPv4 address must be routable by the other
BGP Speaker.
3.3. Route Target
The use of route target is specified in [BGP/MPLS-VPN] and applies to
IPv6 VPNs. Encoding of the extended community attribute is defined
in [BGP-EXTCOM].
3.4. BGP Capability Negotiation
In order for two PEs to exchange labeled IPv6 VPN NLRIs, they MUST
use BGP Capabilities Negotiation to ensure that they both are capable
of properly processing such NLRIs. This is done as specified in
[BGP-MP] and [BGP-CAP], by using capability code 1 (multiprotocol
BGP), with AFI and SAFI values as specified above, in Section 3.2.
4. Encapsulation
The ingress PE Router MUST tunnel IPv6 VPN data over the backbone
towards the Egress PE router identified as the BGP Next Hop for the
corresponding destination IPv6 VPN prefix.
When the 16-octet IPv6 address contained in the BGP Next Hop field is
encoded as an IPv4-mapped IPv6 address (see Section 3.2.1.2), the
ingress PE MUST use IPv4 tunneling unless explicitly configured to do
otherwise. The ingress PE MAY optionally allow, through explicit
configuration, the use of IPv6 tunneling when the 16-octet IPv6
address contained in the BGP Next Hop field is encoded as an IPv4-
mapped IPv6 address. This would allow support of particular
deployment environments where IPv6 tunneling is desired but where
IPv4-mapped IPv6 addresses happen to be used for IPv6 reachability of
the PEs instead of Global IPv6 addresses.
When the 16-octet IPv6 address contained in the BGP Next Hop field is
not encoded as an IPv4-mapped address (see Section 3.2.1.1), the
ingress PE MUST use IPv6 tunneling.
When a PE receives a packet from an attached CE, it looks up the
packet's IPv6 destination address in the VRF corresponding to that
CE. This enables it to find a VPN-IPv6 route. The VPN-IPv6 route
will have an associated MPLS label and an associated BGP Next Hop.
First, this MPLS label is pushed on the packet as the bottom label.
Then, this labeled packet is encapsulated into the tunnel for
transport to the egress PE identified by the BGP Next Hop. Details
of this encapsulation depend on the actual tunneling technique, as
follows:
As with MPLS/BGP for IPv4 VPNs [2547-GRE/IP], when tunneling is done
using IPv4 tunnels or IPv6 tunnels (resp. IPv4 GRE tunnels or IPv6
GRE tunnels), encapsulation of the labeled IPv6 VPN packet results in
an MPLS-in-IP (resp. MPLS-in-GRE) encapsulated packet as specified in
[MPLS-in-IP/GRE]. When tunneling is done using L2TPv3, encapsulation
of the labeled IPv6 VPN packet results in an MPLS-in-L2TPv3-
encapsulated packet, as specified in [MPLS-in-L2TPv3].
As with MPLS/BGP for IPv4 VPNs, when tunneling is done using an IPsec
secured tunnel [2547-IPsec], encapsulation of the labeled IPv6 VPN
packet results in an MPLS-in-IP- or MPLS-in-GRE-encapsulated packet
[MPLS-in-IP/GRE]. The IPsec Transport Mode is used to secure this
IPv4 or GRE tunnel from ingress PE to egress PE.
When tunneling is done using IPv4 tunnels (whether IPsec secured or
not), the Ingress PE Router MUST use the IPv4 address that is encoded
in the IPv4-mapped IPv6 address field of the BGP next hop field as
the destination address of the prepended IPv4 tunneling header. It
uses one of its IPv4 addresses as the source address of the prepended
IPv4 tunneling header.
When tunneling is done using IPv6 tunnels (whether IPsec secured or
not), the Ingress PE Router MUST use the IPv6 address that is
contained in the IPv6 address field of the BGP next hop field as the
destination address of the prepended IPv6 tunneling header. It uses
one of its IPv6 addresses as the source address of the prepended IPv6
tunneling header.
When tunneling is done using MPLS LSPs, the LSPs can be established
using any label distribution technique (LDP [LDP], RSVP-TE [RSVP-TE],
etc.).
When tunneling is done using MPLS LSPs, the ingress PE Router MUST
directly push the LSP tunnel label on the label stack of the labeled
IPv6 VPN packet (i.e., without prepending any IPv4 or IPv6 header).
This pushed label corresponds to the LSP starting on the ingress PE
Router and ending on the egress PE Router. The BGP Next Hop field is
used to identify the egress PE router and in turn the label to be
pushed on the stack. When the IPv6 address in the BGP Next Hop field
is an IPv4-mapped IPv6 address, the embedded IPv4 address will
determine the tunnel label to push on the label stack. In any other
case, the IPv6 address in the BGP Next Hop field will determine the
tunnel label to push on the label stack.
To ensure interoperability among systems that implement this VPN
architecture, all such systems MUST support tunneling using MPLS LSPs
established by LDP [LDP].
5. Address Types
Since Link-local unicast addresses are defined for use on a single
link only, those may be used on the PE-CE link, but they are not
supported for reachability across IPv6 VPN Sites and are never
advertised via MultiProtocol-Border Gateway Protocol (MP-BGP) to
remote PEs.
Global unicast addresses are defined as uniquely identifying
interfaces anywhere in the IPv6 Internet. Global addresses are
expected to be commonly used within and across IPv6 VPN Sites. They
are obviously supported by this IPv6 VPN solution for reachability
across IPv6 VPN Sites and advertised via MP-BGP to remote PEs and are
processed without any specific considerations to their global scope.
Quoting from [UNIQUE-LOCAL]: "This document defines an IPv6 unicast
address format that is globally unique and is intended for local
communications [IPv6]. These addresses are called Unique Local IPv6
Unicast Addresses and are abbreviated in this document as Local IPv6
addresses. They are not expected to be routable on the global
Internet. They are routable inside of a more limited area such as a
site. They may also be routed between a limited set of sites."
[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."
In accordance with this, Unique Local IPv6 Unicast Addresses are
supported by the IPv6 VPN solution specified in this document for
reachability across IPv6 VPN Sites. Hence, reachability to such
Unique Local IPv6 Addresses may be advertised via MP-BGP to remote
PEs and processed by PEs in the same way as Global Unicast addresses.
Recommendations and considerations for which of these supported
address types should be used in given IPv6 VPN environments are
beyond the scope of this document.
6. Multicast
Multicast operations are outside the scope of this document.
7. Carriers' Carriers
Sometimes, an IPv6 VPN may actually be the network of an IPv6 ISP,
with its own peering and routing policies. Sometimes, an IPv6 VPN
may be the network of an SP that is offering VPN services in turn to
its own customers. IPv6 VPNs like these can also obtain backbone
service from another SP, the "Carrier's Carrier", using the Carriers'
Carrier method described in Section 9 of [BGP/MPLS-VPN] but applied
to IPv6 traffic. All the considerations discussed in [BGP/MPLS-VPN]
for IPv4 VPN Carriers' Carrier apply for IPv6 VPN, with the exception
that the use of MPLS (including label distribution) between the PE
and the CE pertains to IPv6 routes instead of IPv4 routes.
8. Multi-AS Backbones
The same procedures described in Section 10 of [BGP/MPLS-VPN] can be
used (and have the same scalability properties) to address the
situation where two sites of an IPv6 VPN are connected to different
Autonomous Systems. However, some additional points should be noted
when applying these procedures for IPv6 VPNs; these are further
described in the remainder of this section.
Approach (a): VRF-to-VRF connections at the AS (Autonomous System)
border routers.
This approach is the equivalent for IPv6 VPNs to procedure (a) in
Section 10 of [BGP/MPLS-VPN]. In the case of IPv6 VPNs, IPv6 needs
to be activated on the inter-ASBR VRF-to-VRF (sub)interfaces. In
this approach, the ASBRs exchange IPv6 routes (as opposed to VPN-IPv6
routes) and may peer over IPv6 or over IPv4. The exchange of IPv6
routes MUST be carried out as per [BGP-IPv6]. This method does not
use inter-AS LSPs.
Finally, note that with this procedure, since every AS independently
implements the intra-AS procedures for IPv6 VPNs described in this
document, the participating ASes may all internally use IPv4
tunneling, or IPv6 tunneling; or alternatively, some participating
ASes may internally use IPv4 tunneling while others use IPv6
tunneling.
Approach (b): EBGP redistribution of labeled VPN-IPv6 routes from AS
to neighboring AS.
This approach is the equivalent for IPv6 VPNs to procedure (b) in
Section 10 of [BGP/MPLS-VPN]. With this approach, the ASBRs use EBGP
to redistribute labeled VPN-IPv4 routes to ASBRs in other ASes.
In this approach, IPv6 may or may not be activated on the inter-ASBR
links since the ASBRs exchanging VPN-IPv6 routes may peer over IPv4
or IPv6 (in which case, IPv6 obviously needs to be activated on the
inter-ASBR link). The exchange of labeled VPN-IPv6 routes MUST be
carried out as per [BGP-IPv6] and [MPLS-BGP]. When the VPN-IPv6
traffic is to be transported using IPv6 tunneling, the BGP Next Hop
Field SHALL contain an IPv6 address. When the VPN-IPv6 traffic is to
be transported using IPv4 tunneling, the BGP Next Hop Field SHALL
contain an IPv4 address encoded as an IPv4-mapped IPv6 address.
This approach requires that there be inter-AS LSPs. As such, the
corresponding (security) considerations described for procedure (b)
in Section 10 of [BGP/MPLS-VPN] apply equally to this approach for
IPv6.
Finally, note that with this procedure, as with procedure (a), since
every AS independently implements the intra-AS procedures for IPv6
VPNs described in this document, the participating ASes may all
internally use IPv4 tunneling or IPv6 tunneling; alternatively, some
participating ASes may internally use IPv4 tunneling while others use
IPv6 tunneling.
Approach (c): Multihop EBGP redistribution of labeled VPN-IPv6 routes
between source and destination ASes, with EBGP redistribution of
labeled IPv4 or IPv6 routes from AS to neighboring AS.
This approach is equivalent for exchange of VPN-IPv6 routes to
procedure (c) in Section 10 of [BGP/MPLS-VPN] for exchange of VPN-
IPv4 routes.
This approach requires that the participating ASes either all use
IPv4 tunneling or all use IPv6 tunneling.
In this approach, VPN-IPv6 routes are neither maintained nor
distributed by the ASBR routers. The ASBR routers need not be dual
stack. An ASBR needs to maintain labeled IPv4 (or IPv6) routes to
the PE routers within its AS. It uses EBGP to distribute these
routes to other ASes. ASBRs in any transit ASes will also have to
use EBGP to pass along the labeled IPv4 (or IPv6) routes. This
results in the creation of an IPv4 (or IPv6) label switch path from
ingress PE router to egress PE router. Now, PE routers in different
ASes can establish multi-hop EBGP connections to each other over IPv4
or IPv6 and can exchange labeled VPN-IPv6 routes over those EBGP
connections. Note that the BGP Next Hop field of these distributed
VPN-IPv6 routes will contain an IPv6 address when IPv6 tunneling is
used or an IPv4-mapped IPv6 address when IPv4 tunneling is used.
The considerations described for procedure (c) in Section 10 of
[BGP/MPLS-VPN] with respect to possible use of route-reflectors, with
respect to possible use of a third label, and with respect to LSPs
spanning multiple ASes apply equally to this IPv6 VPN approach.
9. Accessing the Internet from a VPN
The methods proposed by [BGP/MPLS-VPN] to access the global IPv4
Internet from an IPv4 VPN can be used in the context of IPv6 VPNs and
the global IPv6 Internet. Note, however, that if the IPv6 packets
from IPv6 VPN sites and destined for the global IPv6 Internet need to
traverse the SP backbone, and that if this is an IPv4 only backbone,
these packets must be tunneled through that IPv4 backbone.
Clearly, as is the case outside the VPN context, access to the IPv6
Internet from an IPv6 VPN requires the use of global IPv6 addresses.
In particular, Unique Local IPv6 addresses cannot be used for IPv6
Internet access.
10. Management VPN
The management considerations discussed in Section 12 of
[BGP/MPLS-VPN] apply to the management of IPv6 VPNs.
Where the Service Provider manages the CE of the IPv6 VPN site, the
Service Provider may elect to use IPv4 for communication between the
management tool and the CE for such management purposes. In that
case, regardless of whether a customer IPv4 site is actually
connected to the CE (in addition to the IPv6 site), the CE is
effectively part of an IPv4 VPN in addition to belonging to an IPv6
VPN (i.e., the CE is attached to a VRF that supports IPv4 in addition
to IPv6). Considerations presented in [BGP/MPLS-VPN], on how to
ensure that the management tool can communicate with such managed CEs
from multiple VPNs without allowing undesired reachability across CEs
of different VPNs, are applicable to the IPv4 reachability of the VRF
to which the CE attaches.
Where the Service Provider manages the CE of the IPv6 VPN site, the
Service Provider may elect to use IPv6 for communication between the
management tool and the CE for such management purposes.
Considerations presented in [BGP/MPLS-VPN], on how to ensure that the
management tool can communicate with such managed CEs from multiple
VPNs without allowing undesired reachability across CEs of different
VPNs, are then applicable to the IPv6 reachability of the VRF to
which the CE attaches.
11. Security Considerations
The extensions defined in this document allow MP-BGP to propagate
reachability information about IPv6 VPN routes.
Security considerations for the transport of IPv6 reachability
information using BGP are discussed in RFC2545, Section 5, and are
equally applicable for the extensions described in this document.
The extensions described in this document for offering IPv6 VPNs use
the exact same approach as the approach described in [BGP/MPLS-VPN].
As such, the same security considerations apply with regards to Data
Plane security, Control Plane security, and PE and P device security
as described in [BGP/MPLS-VPN], Section 13.
12. Quality of Service
Since all the QoS mechanisms discussed for IPv4 VPNs in Section 14 of
[BGP/MPLS-VPN] operate in the same way for IPv4 and IPv6 (Diffserv,
Intserv, MPLS Traffic Engineering), the QoS considerations discussed
in [BGP/MPLS-VPN] are equally applicable to IPv6 VPNs (and this holds
whether IPv4 tunneling or IPv6 tunneling is used in the backbone.)
13. Scalability
Each of the scalability considerations summarized for IPv4 VPNs in
Section 15 of [BGP/MPLS-VPN] is equally applicable to IPv6 VPNs.
14. IANA Considerations
This document specifies (see Section 3.2) the use of the BGP AFI
(Address Family Identifier) value 2, along with the BGP SAFI
(Subsequent Address Family Identifier) value 128, to represent the
address family "VPN-IPv6 Labeled Addresses", which is defined in this
document.
The use of AFI value 2 for IPv6 is as currently specified in the IANA
registry "Address Family Identifier", so IANA need not take any
action with respect to it.
The use of SAFI value 128 for "MPLS-labeled VPN address" is as
currently specified in the IANA registry "Subsequence Address Family
Identifier", so IANA need not take any action with respect to it.
15. Acknowledgements
We would like to thank Gerard Gastaud and Eric Levy-Abegnoli, who
contributed to this document.
In Memoriam
The authors would like to acknowledge the valuable contribution to
this document from Tri T. Nguyen, who passed away in April 2002 after
a sudden illness.
16. References
16.1. Normative References
[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. Informative References
[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.
Authors' Addresses
Jeremy De Clercq
Alcatel
Copernicuslaan 50, 2018 Antwerpen, Belgium
EMail: jeremy.de_clercq@alcatel.be
Dirk Ooms
OneSparrow
Belegstraat 13, 2018 Antwerpen, Belgium
EMail: dirk@onesparrow.com
Marco Carugi
Nortel Networks S.A.
Parc d'activites de Magny-Les Jeunes Bois CHATEAUFORT
78928 YVELINES Cedex 9 - France
EMail: marco.carugi@nortel.com
Francois Le Faucheur
Cisco Systems, Inc.
Village d'Entreprise Green Side - Batiment T3
400, Avenue de Roumanille
06410 Biot-Sophia Antipolis
France
EMail: flefauch@cisco.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
ISO Plain Language
On this page
§1The Method in One Page
The document describes how a service provider can use its packet-switched backbone to provide virtual private network services for its IPv6 customers. It reuses and extends the BGP/MPLS IP VPN method of RFC 4364, and in particular uses the same peer model: the customer's edge routers, the CE routers, send their IPv6 routes to the provider's edge routers, the PE routers. BGP is then used by the provider to exchange the routes of one IPv6 VPN among the PE routers attached to that VPN, and those PE routers pass the IPv6 routes on to the CE routers of that VPN. As in IPv4, the CE routers of a VPN do not peer with each other, so there is no overlay visible to the VPN's own routing algorithm.
Unless the document says otherwise, it adopts the definitions, acronyms and mechanisms of RFC 4364 without repeating them. A VPN is an IPv6 VPN when each of its sites is IPv6 capable and connected natively over an IPv6 interface or sub-interface to the provider backbone through a provider edge device. A site may be both IPv4 capable and IPv6 capable: the logical interface on which packets arrive at the provider edge may decide the IP version, or, when one interface carries both, the version field of the IP header decides it packet by packet.
The scope is narrow on purpose. Only IPv6 traffic between IPv6 hosts on IPv6-capable sites is covered. Handling IPv4 traffic between IPv4 hosts is covered by RFC 4364, and traffic between an IPv4 host and an IPv6 host is outside the scope of this document. Like the IPv4 method, each IPv6 VPN may have its own address space, so the same address can denote different systems in different VPNs. That is achieved with a new address family, the VPN-IPv6 address family, which prepends a route distinguisher to the IP address in the same way as the VPN-IPv4 address family of RFC 4364.
Where the IPv4 solution runs over MPLS label switched paths, this document also allows the IPv6 VPN to run over other tunnels, including GRE, IP-in-IP, L2TPv3 and IPsec protected tunnels. The service works over an IPv4 backbone and over an IPv6 backbone, and the service supported is the same in both cases.
The document lists four benefits: from the provider's point of view and from the customer's, the IPv6 VPN service is identical to the IPv4 one; operating it needs the same skills, procedures and mechanisms; where both are offered over an IPv4 core, the same multiprotocol BGP peering relationships and the same provider-to-provider tunnel mesh can be used for both; and the service does not depend on whether the core runs IPv4 or IPv6, so a customer cannot tell whether the core has been migrated. Supporting IPv4 VPN services over an IPv6 core is not covered.
The provider's method for IPv4 private networks is extended to IPv6. The customer router hands its IPv6 routes to the provider, the provider tells the other provider routers attached to the same private network about those routes, and those routers pass them to the other customer routers. The customer routers never talk to each other directly, so the private network is invisible to their own routing.
§2The VPN-IPv6 Address Family
The multiprotocol extensions to BGP let BGP carry routes from several address families. This document adds the VPN-IPv6 address family, which works like the VPN-IPv4 address family of RFC 4364. A VPN-IPv6 address is a 24-octet quantity: it begins with an 8-octet route distinguisher and ends with a 16-octet IPv6 address.
The route distinguisher exists for one reason, to allow distinct routes to a common IPv6 address prefix. As in RFC 4364, two different VPN-IPv6 routes can carry the same IPv6 part with different route distinguishers, which lets the provider's BGP install several different routes to the same system and lets policy decide which packets use which route. The same mechanism keeps two VPNs apart: if two VPNs use the same IPv6 prefix for different physical systems, the provider edge devices turn them into unique VPN-IPv6 prefixes with different route distinguishers, so the same address can have two completely different routes, one per VPN.
Because VPN-IPv6 addresses and IPv6 addresses belong to different address families, BGP never treats them as comparable addresses. A VRF may hold several equal-cost VPN-IPv6 routes for one IPv6 prefix, and when a packet's destination address is matched in a VRF against a VPN-IPv6 route, only the IPv6 part is actually matched. The format and encoding of the route distinguisher are as specified in RFC 4364.
Where a site is both IPv4 capable and IPv6 capable, the same route distinguisher may be used to advertise the IPv6 and the IPv4 addresses, or different ones may be used. Either way, IPv4 addresses and IPv6 addresses are always handled in separate contexts, and the document does not discuss IPv4 to IPv6 interworking.
Each route in the private network is written as a route distinguisher followed by the IPv6 address. The route distinguisher says which private network the address belongs to, so the same IPv6 address can mean different things in different private networks. When a packet is looked up, only the IPv6 part is compared.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
RD | Route Distinguisher | 8 bytes | 8 octets that make the route unique to one VPN. | |
IPV6 | IPv6 Address | 16 bytes | The 16-octet IPv6 prefix of the route. |
§3.1How the Routes Reach the Other Provider Routers
If two sites of a VPN attach to provider edge routers in the same autonomous system, those routers can distribute the VPN routes to each other over an internal BGP connection. Alternatively, each provider edge router can hold an internal BGP connection to a route reflector, which relays the routes on behalf of the others. For an IPv6 VPN the internal BGP connections may run over IPv4 or over IPv6.
The provider edge routers exchange reachability information for the IPv6 prefixes of their IPv6 VPNs through the multiprotocol extensions to BGP, and in doing so they announce themselves as the BGP next hop. The rules for encoding that reachability information, and the address of the next hop itself, are given in the following sections.
The provider routers pass the routes to each other over internal BGP, either directly or through a route reflector that relays them. The same session may run over IPv4 or IPv6, and the route that is sent says which provider router the traffic should be forwarded to.
- IPv6 ROUTEThe customer announces its prefix.
- MP-BGP UPDATEThe provider edge advertises the labelled route and announces itself as next hop.
- LABELLED PACKETTraffic for the destination, with the MPLS label pushed.
- IPv6 PACKETThe label is popped and the packet is delivered.
§3.2How the Route Is Encoded
When the provider edge router distributes IPv6 VPN routes, it must assign and distribute MPLS labels with them. In effect the routers do not distribute plain IPv6 VPN routes but labelled IPv6 VPN routes. When the advertising router later receives a packet carrying the label it advertised, it pops that label from the MPLS stack and processes the packet, either forwarding it directly according to the label or looking it up in the matching IPv6 VPN context.
The multiprotocol extensions carry the routes in the MP_REACH network layer reachability information field. Two fields there must be set: the Address Family Identifier must be 2, which is IPv6, and the Subsequent Address Family Identifier must be 128, which is MPLS labelled VPN-IPv6. The reachability information itself is encoded as specified in RFC 3107, so in this case the prefix is an 8-octet route distinguisher followed by an IPv6 prefix, as described above.
The document notes that both code points are already in the IANA registries: AFI 2 is registered for IPv6, and SAFI 128 is registered for MPLS-labelled VPN addresses. No new allocation is needed for this document. Two provider edge routers must also use the BGP capability negotiation to confirm that both can process these routes, using capability code 1 for multiprotocol BGP with the AFI and SAFI values above.
The route is sent with an MPLS label attached, so the receiving provider router can forward the traffic without looking the address up again. Two numbers identify the format: 2 for IPv6 and 128 for labelled VPN addresses. Both routers check that they understand the format before exchanging routes.
§3.2.1The Next Hop Address and the Address Types
The encoding of the BGP next hop depends on whether the router wants the traffic to reach it over IPv6 tunnelling or over IPv4 tunnelling. Choosing that policy is the network operator's job and is outside the scope of the document, and it is possible to ask for IPv4 tunnelling while the BGP speakers exchange IPv6 reachability over IPv6, or the other way round. The document warns about that combination: a fault on the tunnelling data path that does not affect the reachability path can go unnoticed by BGP, and the result is traffic being dropped without explanation.
When IPv6 tunnelling is requested, the router must advertise a next hop address made of a VPN-IPv6 address whose 8-octet route distinguisher is set to zero and whose 16-octet IPv6 address is the global IPv6 address of the advertising router. This may be followed by a second VPN-IPv6 address, again with a route distinguisher of zero, holding the link-local IPv6 address of the advertising router. The length of the next hop field is 24 when only the global address is present and 48 when a link-local address is included as well. If the two speakers peer using only their link-local addresses, the advertising router uses the unspecified address to say that no global address is present. The link-local address must be included if and only if the advertising router shares a common subnet with the peer it is advertising to, and in all other cases only the global address is advertised. A router advertising to an internal peer may remove the link-local address from the field. One case where both addresses are advertised is a multi-autonomous-system backbone where border routers in different autonomous systems share a common IPv6 subnet.
When IPv4 tunnelling is requested, the router must advertise a VPN-IPv6 address whose route distinguisher is zero and whose 16-octet IPv6 address is an IPv4-mapped IPv6 address holding the IPv4 address of the advertising router. That IPv4 address must be routable by the other BGP speaker.
The document also says which kinds of IPv6 address the service carries. Link-local unicast addresses are for one link only, so they may be used on the link between the provider edge and the customer edge but are not supported across sites and are never advertised to remote provider routers. Global unicast addresses are supported across sites and are advertised, and are processed without special treatment for their global scope. Unique local IPv6 unicast addresses are supported across sites as well, because RFC 4193 says they can be used for inter-site VPNs when the routes are in place, and because they keep working if the sites are renumbered or merged; they may be advertised to remote provider routers and are processed the same way as global addresses. Which type to use in a given environment is left to the operator.
The route says which provider router the traffic should go to next, and the address in that field also says how to reach it. If the provider wants IPv6 tunnels, the address is a normal IPv6 address, with a link-local address added when both routers are on the same subnet. If it wants IPv4 tunnels, the IPv4 address is written in the IPv6 field in its mapped form.
| Tunnelling | Next Hop field | Length |
|---|---|---|
| IPv6 | Global IPv6 address of the advertising router | 24 octets |
| IPv6 | Global and link-local IPv6 addresses | 48 octets |
| IPv4 | IPv4 address written as an IPv4-mapped IPv6 address | 24 octets |
§4How a Packet Is Carried Across the Backbone
The ingress provider edge router must tunnel the IPv6 VPN data over the backbone towards the egress provider edge router named as the BGP next hop for the destination prefix. When the IPv6 address in the next hop field is an IPv4-mapped address, the ingress router must use IPv4 tunnelling unless it has been configured explicitly to do otherwise, and it may be configured to allow IPv6 tunnelling in that case. When the address is not IPv4-mapped, the ingress router must use IPv6 tunnelling.
The forwarding path itself follows the ordinary steps. A provider edge router that receives a packet from an attached customer edge router looks up the packet's IPv6 destination address in the VRF that belongs to that customer, which yields a VPN-IPv6 route with an associated MPLS label and an associated BGP next hop. The label is pushed on the packet as the bottom label, and the labelled packet is then encapsulated into the tunnel that leads to the egress router.
Which tunnel that is depends on the technique in use. With IPv4 or IPv6 tunnels, and with IPv4 or IPv6 GRE tunnels, the result is an MPLS-in-IP or MPLS-in-GRE packet as specified in RFC 4023. With L2TPv3, the result is an MPLS-in-L2TPv3 packet. With an IPsec protected tunnel, the result is again MPLS-in-IP or MPLS-in-GRE, and IPsec transport mode secures the tunnel from the ingress router to the egress router. When IPv4 tunnels are used, the ingress router must use the IPv4 address from the IPv4-mapped next hop field as the destination of the prepended IPv4 header, and one of its own IPv4 addresses as the source. The same rule applies with IPv6 tunnels and the IPv6 address in the next hop field.
With MPLS label switched paths, the paths may be set up with any label distribution technique, such as LDP or RSVP-TE. In that case the ingress router must push the tunnel label directly on the label stack of the labelled packet, with no IPv4 or IPv6 header in front of it. The next hop field identifies the egress router and therefore the label to push; when the address in the next hop field is IPv4-mapped, the embedded IPv4 address determines the tunnel label, and otherwise the IPv6 address does. So that systems can interoperate, every implementation of this architecture must support tunnelling over MPLS label switched paths set up with LDP.
The router that receives a packet looks up the destination in the table for that customer, pushes the label the route carries, and puts the packet in a tunnel to the router that advertised it. The tunnel may be an MPLS path, a GRE tunnel, an L2TPv3 tunnel or an IPsec protected tunnel, and the choice of how the headers are stacked follows the technique used.
- IPv6 VPN packetThe customer's IPv6 packet
- MPLS labelPushed as the bottom label for the VPN route
- TunnelMPLS path, GRE, L2TPv3 or IPsec
- Provider backboneCarries the tunnel between the provider edges
§8Bigger Networks and Other Cases
When two sites of an IPv6 VPN attach to provider edge routers in different autonomous systems, the document applies the three procedures of RFC 4364, which have the same scalability properties, with some additions. Approach (a) connects the VRFs of the two border routers. The border routers exchange plain IPv6 routes rather than VPN-IPv6 routes, and may peer over IPv6 or over IPv4; the exchange must follow RFC 2545. This approach uses no label switched paths between the autonomous systems. Because each autonomous system implements the intra-domain procedures on its own, some autonomous systems may use IPv4 tunnelling internally while others use IPv6 tunnelling.
Approach (b) redistributes labelled VPN-IPv6 routes from one autonomous system to a neighbouring one with external BGP. The exchange of labelled VPN-IPv6 routes must follow RFC 2545 and RFC 3107. When the traffic is to be carried with IPv6 tunnelling, the next hop field must hold an IPv6 address, and when it is to be carried with IPv4 tunnelling, it must hold an IPv4 address written as an IPv4-mapped IPv6 address. This approach requires label switched paths between the autonomous systems, so the security considerations that RFC 4364 states for its equivalent procedure apply here as well. Again, the autonomous systems may differ in the tunnelling they use internally.
Approach (c) redistributes labelled VPN-IPv6 routes between the source and destination autonomous systems with multihop external BGP, while labelled IPv4 or IPv6 routes are redistributed from one autonomous system to the next. All the participating autonomous systems must use the same tunnelling type, either all IPv4 or all IPv6. The border routers neither maintain nor distribute the VPN-IPv6 routes and need not carry both IP versions: each keeps labelled IPv4 or IPv6 routes to the provider edge routers inside its own autonomous system and passes them on with external BGP, which builds a label switched path from the ingress to the egress provider edge router. Provider edge routers in different autonomous systems can then set up multihop external BGP connections to each other over IPv4 or IPv6 and exchange the labelled VPN-IPv6 routes over them. The route reflectors, the third label and the label switched paths spanning several autonomous systems, all discussed for the IPv4 case in RFC 4364, apply equally here.
Several other cases follow the IPv4 rules. An IPv6 VPN may be the network of an IPv6 internet service provider with its own peering and routing policy, or the network of a provider that sells VPN service to its own customers, and it may buy backbone service from another provider using the carriers' carrier method of RFC 4364, applied to IPv6 traffic. Access to the global IPv6 internet from an IPv6 VPN uses the methods of RFC 4364, but if the packets have to cross an IPv4-only backbone they must be tunnelled through it, and access to the internet needs global IPv6 addresses, so unique local addresses cannot be used for it. For management, the considerations of RFC 4364 apply, and where the provider manages the customer router over IPv4, that router is effectively part of an IPv4 VPN as well as the IPv6 one, so the measures that keep management traffic between different VPNs apart apply to the IPv4 side of its VRF.
When the sites of one private network sit in different provider networks, there are three ways to connect them: exchange plain IPv6 routes between the border routers, pass the labelled private routes from one network to the next, or build a label switched path across several networks and pass the private routes over it. The other cases, such as a provider buying backbone service from another provider or customers reaching the internet, follow the same rules as the IPv4 service.
§11Security, Quality of Service and Scale
The extensions in this document let multiprotocol BGP propagate reachability information about IPv6 VPN routes. The security considerations for carrying IPv6 reachability information over BGP, discussed in Section 5 of RFC 2545, apply just as they do to the extensions described here. The IPv6 VPN service is offered with exactly the same approach as the IPv4 service of RFC 4364, so the same security considerations apply for data plane security, control plane security, and the security of the provider edge and provider devices.
The quality of service mechanisms that RFC 4364 describes for IPv4 VPNs operate in the same way for IPv4 and IPv6, covering Diffserv, Intserv and MPLS traffic engineering. The same considerations therefore apply to IPv6 VPNs, and they hold whether the backbone uses IPv4 tunnelling or IPv6 tunnelling.
Each scalability consideration summarised for IPv4 VPNs in RFC 4364 is equally applicable to IPv6 VPNs.
The document adds no new security rules of its own, because the IPv6 service works the same way as the IPv4 one, so the same protections and the same limits on scale apply. The same is true of quality of service: the mechanisms that give a customer a guaranteed service behave the same whichever IP version the backbone uses.