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).