INTERNET DRAFT Jeremy De Clercq
<draft-ietf-l3vpn-bgp-ipv6-03.txt> Dirk Ooms
Alcatel
Marco Carugi
Nortel Networks
Francois Le Faucheur
Cisco Systems
June 2004
Expires December, 2004
BGP-MPLS VPN extension for IPv6 VPN
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months. Internet-Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet-
Drafts as reference material or to cite them other than as a
``working draft'' or ``work in progress.''
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au(Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Distribution of this memo is unlimited.
Abstract
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 extends the "BGP/MPLS
VPN" method [2547bis] for support of IPv6. In BGP/MPLS 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 route distribution in
"Multiprotocol BGP". This document defines support of the IPv6 VPN
service over both an IPv4 and an IPv6 backbone, and using various
De Clercq, et al. Expires December 2004 [Page 1]
Internet Draft draft-ietf-l3vpn-bgp-ipv6 June 2004
tunnelling techniques over the core including MPLS, IPsec, IP-in-IP
and GRE.
1. Introduction
This document adopts the definitions, acronyms and mechanisms
described in [2547bis]. Unless otherwise stated, the mechanisms of
[2547bis] 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 SP backbone via a Provider Edge device (PE).
A site may be both IPv4- and IPv6-capable. The logical interface on
which packets arrive at the PE may determine the version, but
alternatively the same logical interface MAY be used for both IPv4
and IPv6 in which case a per-packet header lookup determines the
version. This document only concerns itself with handling of the IPv6
packets.
In a similar manner to how IPv4 VPN routes are distributed in
[2547bis], 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 VRFs to separately maintain the
reachability information and forwarding information of each IPv6 VPN.
As it is done for IPv4 VPNs [2547bis], 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 the VPN-IPv4 address family definition given by [2547bis].
In addition to operation over MPLS Label Switched Paths (LSPs), the
BGP/MPLS VPN solution is extended to allow operation over other
tunnelling techniques including GRE tunnels, IP-in-IP tunnels [2547-
GRE/IP] and IPsec tunnels [2547-IPsec]. In a similar manner, this
document allows support of an IPv6 VPN service over MPLS LSPs as well
as over other tunnelling techniques including GRE tunnels, IP-in-IP
tunnels and IPsec tunnels.
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
De Clercq, et al. Expires December 2004 [Page 2]
Internet Draft draft-ietf-l3vpn-bgp-ipv6 June 2004
perspective, the VPN service that can be supported for IPv6 sites
is identical to the one that can be suported for IPv4 sites;
o from the Service Provider perspective, operations of the IPv6
VPN service require the exact same skills, procedures and
mechanisms as 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 independence of whether the core runs IPv4 or IPv6. 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.
2. The VPN 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", that is similar to the VPN-IPv4 address
family introduced in [2547bis].
2.1 The VPN-IPv6 Address Family
A VPN-IPv6 address is a 24-byte quantity, beginning with an 8-byte
"Route Distinguisher" (RD) and ending with a 16-byte IPv6 address.
If two VPNs use the same IPv6 address prefix (effectively denoting
different physical systems), the PEs translate these into unique
VPN-IPv6 address prefixes using different RDs. This ensures that if
the same address is used in two different VPNs, it is possible to
install two completely different routes to that address, one for each
VPN.
The purpose of the RD is solely to allow one to create distinct
routes to a common IPv6 address prefix, similarly to the purpose of
the RD defined in [2547bis]. As it is possible per [2547bis], the RD
can also 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
BGP to install multiple different routes to the same system, and
allows policy to be used to decide which packets use which route.
Note that VPN-IPv6 addresses and IPv6 addresses are always considered
by BGP to be incomparable.
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.
De Clercq, et al. Expires December 2004 [Page 3]
Internet Draft draft-ietf-l3vpn-bgp-ipv6 June 2004
When a site is IPv4- and IPv6-capable, the same RD MAY be used for
the advertisement of IPv6 addresses and IPv4 addresses.
2.2. Encoding of Route Distinguishers
The RDs are encoded as per [2547bis]:
- TYPE field: 2 bytes
- VALUE field: 6 bytes
The interpretation of the VALUE field depends on the value of the
TYPE field. As it is the case in [2547bis], 3 encodings can be used:
- TYPE field = 0 : the VALUE field consists of the following two
subfields:
* Administrator subfield: 2 bytes, it contains an Autonomous
System Number
* Assigned Number subfield: 4 bytes
- TYPE field = 1 : the VALUE field consists of the following two
subfields:
* Administrator subfield: 4 bytes, it contains a global IPv4
address
* Assigned Number subfield: 2 bytes
- TYPE field = 2 : the VALUE field consists of the following two
subfields:
* Administrator subfield: 4 bytes, it contains a 4-byte Autonomous
System Number
* Assigned Number subfield: 2 bytes
3. VPN-IPv6 route distribution
3.1. Route Distribution Among PEs by BGP
As described in [2547bis], if two sites of a VPN attach to PEs which
are in the same Autonomous System, the PEs can distribute VPN routes
to each other by means of an (IPv4) iBGP connection between them.
Alternatively, each PE can have an iBGP connection to a route
reflector. Similarly, for IPv6 VPN route distribution, PEs can use an
iBGP connection between them or use iBGP connections to a route
reflector.
The PE routers:
De Clercq, et al. Expires December 2004 [Page 4]
Internet Draft draft-ietf-l3vpn-bgp-ipv6 June 2004
(i) exchange, via MP-BGP [MP-BGP], reachability information for the
IPv6 prefixes in the IPv6 VPNs.
(ii) announce themselves as the BGP Next Hop.
3.2 VPN IPv6 NLRI encoding
The advertising PE router MUST also 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 receives a packet that has this particular advertised
label, the PE will pop the MPLS stack, and process the packet
appropriately (i.e. forward it directly based on the label or perform
a lookup in the corresponding IPv6-VPN context).
The BGP Multiprotocol Extensions [BGP-MP] are used to encode the
MP_REACH NLRI. The AFI and SAFI fields MUST be set as follows:
- AFI: 2; for IPv6
- SAFI: 128; for MPLS labeled VPN-IPv6
The labeled VPN-IPv6 MP_REACH_NLRI 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-byte Route
Distinguisher followed by an IPv6 prefix as specified in section 2
above.
3.2.1 BGP Next Hop encoding
3.2.1.1 BGP speakers with IPv6 connectivity
A BGP speaker SHALL advertise to its peers a Next Hop Network Address
field containing a VPN-IPv6 address:
- whose RD is set to zero, and
- whose 16-byte IPv6 address is set to the global IPv6 address of
the advertising PE.
potentially followed by another VPN-IPv6 address:
- whose RD is set to zero, and
- whose 16-byte IPv6 address is set to the link-local IPv6 address
of the advertising PE.
The value of the Length ofth Next Hop Network Address field in the
De Clercq, et al. Expires December 2004 [Page 5]
Internet Draft draft-ietf-l3vpn-bgp-ipv6 June 2004
MP_REACH_NLRI attribute shall be set to 24 when only a global address
is present, or 48 if a link-local address is also included in the
Next Hop 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 [RFC2545].
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 where the IPv6 VPN service is supported over a multi-AS
backbone with redistribution of labeled VPN-IPv6 routes between ASBRs
(of different AS) 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 Speakers with IPv4 connectivity
A BGP speaker SHALL advertise to its peer a Next Hop Network Address
field containing a VPN-IPv6 address:
- whose RD is set to zero, and
- whose 16-byte IPv6 address is encoded as an IPv4-mapped IPv6
address [V6ADDR] containing the IPv4 address of the advertising
PE. This IPv4 address must be routable in the Service Provider's
backbone.
3.3. Route Target
The use of route target is specified in [2547bis] 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 labelled 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
De Clercq, et al. Expires December 2004 [Page 6]
Internet Draft draft-ietf-l3vpn-bgp-ipv6 June 2004
[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. Determination of Tunnel Type
As mentioned earlier, this document allows support of IPv6 VPN
service using various tunneling techniques in the core.
The tunneling type to use in the core for IPv6 VPN MAY be determined
via configuration of PEs. Alternatively a mechanism to dynamically
determine the tunneling type to use MAY be deployed (see for example
[ENCAP-SIG] or [TUN-SAFI] and [SSA]).
5. 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 IPv6 VPN prefix.
When the 16-byte 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 tunnelling.
When the 16-byte IPv6 address contained in the BGP Next Hop field is
not encoded as an IPv4-mapped address (see section 3.2.1.2), the
ingress PE MUST use IPv6 tunnelling.
Regardless of whether it is IPv4 or IPv6 tunnelling, the tunnelling
type is determined as discussed above in section 4.
When a PE receives a packet from a 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. Then, this labelled packet is
encapsulated into the tunnel for transport to the egress PE
identified as the BGP Next Hop. Details of this encapsulation depend
on the actual tunnelling technique as follows:
As with MPLS/BGP for IPv4 VPNs [2547-GRE/IP], when tunnelling is done
using IPv4 tunnels or IPv6 tunnels (resp. IPv4 GRE tunnels or IPv6
GRE tunnels), encapsulation of the labelled IPv6 VPN packet results
in an MPLS-in-IP (resp. MPLS-in-GRE) encapsulated packet as specified
in [MPLS-in-IP/GRE].
As with MPLS/BGP for IPv4 VPNs, when tunnelling is done using an
IPsec secured tunnel [2547-IPsec], encapsulation of the labelled IP6
VPN packet results in an MPLS-in-IP or MPLS-in-GRE encapsulated
De Clercq, et al. Expires December 2004 [Page 7]
Internet Draft draft-ietf-l3vpn-bgp-ipv6 June 2004
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 tunnelling is done using IPv4 tunnels or IPv4 GRE tunnels
(whether IPsec secured or not), the Ingress PE Router MUST use the
IPv4 address which is encoded in the IPv4-mapped IPv6 address field
of the BGP next hop field, as the destination address of the
prepended IPv4 tunnelling header. It uses one of its IPv4 addresses
as the source address of the prepended IPv4 tunneling header.
When tunnelling is done using IPv6 tunnels or IPv6 GRE tunnels
tunnels (whether IPsec secured or not), the Ingress PE Router MUST
use the IPv6 address which is contained in the IPv6 address field of
the BGP next hop field, as the destination address of the prepended
IPv6 tunnelling 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],
...). Nevertheless, to ensure interoperability among systems that
implement this VPN architecture using MPLS LSPs as the tunneling
technology, all such systems MUST support LDP [LDP].
When tunnelling is done using MPLS LSPs, the ingress PE Router
directly pushes the LSP tunnel label on the label stack of the
labelled 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 as such the
label to be pushed on the stack. In case the IPv6 address in the BGP
Next Hop field is a 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.
The bottom label is the label bound to the IPv6 VPN Prefix via BGP.
6. Address Scope
Since Link-local scope addresses are defined as uniquely identifying
interfaces within (i.e., attached to) a single link only (see
[SCOPE-ARCH]), 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 MP-BGP to remote PEs.
Global scope addresses are defined as uniquely identifying interfaces
anywhere in the Internet. Global addresses are expected to be
De Clercq, et al. Expires December 2004 [Page 8]
Internet Draft draft-ietf-l3vpn-bgp-ipv6 June 2004
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 processed without
any specific considerations to their Global scope.
7. Multicast
Multicast operations is outside the scope of this document.
8. Inter-Provider Backbones
The same mechanisms described in [2547bis] can be used and have the
same scalability properties.
9. Accessing the Internet from a VPN
The methods proposed by [2547bis] to access the global Internet can
be used in the context of IPv6 VPNs and the global IPv6 Internet.
Note however that if the IPv6 packets destined for the global IPv6
Internet need to traverse the SP backbone, and if this is an IPv4
only backbone, they must be tunnelled through that IPv4 backbone.
10. Management VPN
Where the IPv6 VPN service is supported over an IPv4 backbone, and
where the Service Provider manages the CE, 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 or not,
the CE is effectively part of an IPv4 VPN (i.e. it is attached to an
IPv4 VRF) in addition to belonging to an IPv6 VPN. Considerations
presented in [2547bis] 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 VRF to which the CE attaches.
Where the IPv6 VPN service is supported over an IPv4 backbone, and
where the Service Provider manages the CE, the Service Provider may
elect to use IPv6 for communication between the management tool and
the CE for such management purposes. Considerations presented in
[2547bis] 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 VRF to which the CE attaches.
11. Security
The same security concerns as in [2547bis] are applicable.
De Clercq, et al. Expires December 2004 [Page 9]
Internet Draft draft-ietf-l3vpn-bgp-ipv6 June 2004
12. Quality of Service
[2547bis] is applicable.
13. Acknowledgements
We would like to thank Gerard Gastaud who largely 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.
14. Normative References
[2547bis] Rosen et al., "BGP/MPLS VPNs", draft-ietf-l3vpn-rfc2547bis,
work in progress
[BGP-EXTCOMM] Ramachandra, Tappan, Rekhter, "BGP Extended Communities
Attribute", work in progress
[BGP-MP] Bates, Chandra, Katz, and Rekhter, "Multiprotocol Extensions
for BGP4", June 2000, RFC2858
[IPv6] Deering, S., and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC2460.
[MPLS-ARCH] Rosen, Viswanathan, and Callon, "Multiprotocol Label
Switching Architecture", RFC3031
[MPLS-BGP] Rekhter and Rosen, "Carrying Label Information in BGP4",
RFC3107
[MPLS-ENCAPS] Rosen, Rekhter, Tappan, Farinacci, Fedorkow, Li, and
Conta, "MPLS Label Stack Encoding", RFC3032
[BGP-CAP] Chandra, R., Scudder, J., "Capabilities Advertisement with
BGP-4", November 2002, RFC3392
[MPLS-LDP] Andersson, Doolan, Feldman, Fredette, Thomas, "LDP
Specification", RFC3036
[RFC2545] Marques, P., Dupont, F., "Use of BGP-4 Multiprotocol
Extensions for IPv6 Inter-Domain Routing", March 1999, RFC2545
De Clercq, et al. Expires December 2004 [Page 10]
Internet Draft draft-ietf-l3vpn-bgp-ipv6 June 2004
15. Informative References
[V6ADDR] Deering, S., and Hinden, R., "IP Version 6 Addressing
Architecture", April 2003, RFC3513
[2547-GRE/IP] Rekhter and Rosen, "Use of PE-PE GRE or IP in RFC2547
VPNs", draft-ietf-l3vpn-gre-ip-2547, work in progress
[2547-IPsec] Rosen, De Clercq, Paridaens, T'Joens, Sargor, "Use of
PE-PE IPsec in RFC2547 VPNs", draft-ietf-l3vpn-ipsec-2547, work in
progress
[TRANS] R. Gilligan, E. Nordmark, "Transition Mechanisms for IPv6
Hosts and Routers", RFC2893.
[SCOPE-ARCH] Deering, S., et al., "IPv6 Scoped Address Architecture",
draft-ietf-ipv6-scoping-arch, work in progress
[RSVP-TE] Awduche, D., et al., "RSVP-TE: Extensions to RSVP for LSP
Tunnels", December 2001, RFC3209
[MPLS-in-IP/GRE] Worster, T., et al., "Encapsulating MPLS in IP or
GRE", draft-ietf-mpls-in-ip-or-gre, work in progress
[ENCAP-SIG] Aggarwal, R., et al., "Signaling Tunnel
Encapsulation/Deencapsulation capabilities", draft-raggarwa-ppvpn-
tunnel-encap-sig, work in progress
[TUN-SAFI] Nalawade, et al., "IPv4 Tunnel SAFI", draft-nalawade-
kapoor-tunnel-safi-00, work in progress
[SSA] Kapoor, et al., "BGP-4 SAFI-specific Attribute", draft-kapoor-
nalawade-idr-bgp-ssa, work in progress
16. Authors' Addresses
Jeremy De Clercq
Alcatel
Fr. Wellesplein 1, 2018 Antwerpen, Belgium
E-mail: jeremy.de_clercq@alcatel.be
Dirk Ooms
Alcatel
Fr. Wellesplein 1, 2018 Antwerpen, Belgium
E-mail: dirk.ooms@alcatel.be
Marco Carugi
Nortel Networks S.A.
De Clercq, et al. Expires December 2004 [Page 11]
Internet Draft draft-ietf-l3vpn-bgp-ipv6 June 2004
Parc d'activites de Magny-Les Jeunes Bois CHATEAUFORT
78928 YVELINES Cedex 9 - France
E-mail: marco.carugi@nortelnetworks.com
Francois Le Faucheur
Cisco Systems, Inc.
Village d'Entreprise Green Side - Batiment T3
400, Avenue de Roumanille
06410 Biot-Sophia Antipolis
France
E-mail: flefauch@cisco.com
De Clercq, et al. Expires December 2004 [Page 12]
Internet Draft draft-ietf-l3vpn-bgp-ipv6 June 2004
De Clercq, et al. Expires December 2004 [Page 13]
