RFC 4659
BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN
RFC 4659 💖 BGP-MPLS IP VPN Extension for IPv6 VPN 🦋
Okay bestie, this one is from September 2006 and it's on the Standards Track 👑, so people actually build this stuff. It's written by four people: J. De Clercq (Alcatel), D. Ooms (OneSparrow), M. Carugi (Nortel Networks), and F. Le Faucheur (Cisco Systems). It's from the Network Working Group. It doesn't list any RFCs that it obsoletes or updates in its header, so it's standing on its own 🌸
Status of This Memo ✨
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 💅
Copyright Notice 🎀
Copyright (C) The Internet Society (2006).
Abstract 🌈
Okay so this doc is about how a Service Provider can use its packet-switched backbone to offer VPN services for its IPv6 customers 🛰️ It reuses the "BGP/MPLS IP VPN" method for IPv6 support, and extends it where needed. Quick refresher: in regular BGP/MPLS IP VPN, "Multiprotocol BGP" passes IPv4 VPN routes around the backbone, and MPLS forwards the IPv4 VPN packets across it. This RFC defines an IPv6 VPN address family and explains how IPv6 VPN routes get distributed with "Multiprotocol BGP". It's giving clean and organized 🫶
It also covers IPv6 VPN service running over both an IPv4 backbone and an IPv6 backbone, and using different tunneling techniques across the core. Those include 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 ...................................161. Introduction 🌸
Okay this section sets the scene. Same idea as before: a Service Provider uses its packet-switched backbone to give VPN services to its IPv6 customers 💅
The method reuses the "BGP/MPLS IP VPN" method [BGP/MPLS-VPN] for IPv6, and extends it where necessary. It uses the same "peer model" as [BGP/MPLS-VPN]. In this model, the customers' edge routers ("CE routers") send their IPv6 routes to the Service Provider's edge routers ("PE routers"). Then the Service Provider uses BGP ("Border Gateway Protocol", [BGP, BGP-MP]) to swap the routes of a particular IPv6 VPN among the PE routers attached to that VPN. Eventually, the PE routers pass the IPv6 routes from other CE routers in a VPN down to the CE routers in that same VPN ✨
The big vibe here is that the (IPv6) CE routers in an (IPv6) VPN do not peer with each other. There's no "overlay" the VPN's routing algorithm can see. Same as IPv4 VPNs 🫶
This document adopts the definitions, acronyms, and mechanisms from [BGP/MPLS-VPN]. Unless it says otherwise, the mechanisms of [BGP/MPLS-VPN] apply, and they won't be re-explained here. No need to retell the whole story 🙈
A VPN counts as an IPv6 VPN when every site in it is IPv6 capable, and each site is natively connected over an IPv6 interface or sub-interface to the Service Provider (SP) backbone through a Provider Edge device (PE) 🌈
A site can be both IPv4 capable and IPv6 capable. The logical interface where packets arrive at the PE can determine the IP version. Or, the same logical interface can handle both IPv4 and IPv6. In that case, a per-packet lookup on the Version field of the IP packet header decides the IP version 👑
This document only deals with IPv6 communication between IPv6 hosts on IPv6-capable sites. Handling IPv4 communication between IPv4 hosts on IPv4-capable sites is outside the scope here, and it's covered in [BGP/MPLS-VPN]. Communication between an IPv4 host on an IPv4-capable site and an IPv6 host on an IPv6-capable site is also outside the scope of this document 💀
Here's the similar idea from IPv4 VPNs. BGP and its extensions distribute routes from an IPv6 VPN site to all the other PE routers connected to a site of the same IPv6 VPN, just like [BGP/MPLS-VPN] does for IPv4 VPN routes. PEs use "VPN Routing and Forwarding tables" (VRFs) to keep the reachability and forwarding information of each IPv6 VPN separate 🦋
Just like IPv4 VPNs [BGP/MPLS-VPN], each IPv6 VPN gets its own IPv6 address space. That means a given address might point to different systems in different VPNs. This works through a new address family, the VPN-IPv6 Address Family. It's modeled on the VPN-IPv4 address family defined in [BGP/MPLS-VPN], and it prepends a Route Distinguisher to the IP address 🎀
Besides operating over MPLS Label Switched Paths (LSPs), the IPv4 BGP/MPLS VPN solution has been extended to run over other tunneling techniques. Those include GRE tunnels, IP-in-IP tunnels [2547-GRE/IP], L2TPv3 tunnels [MPLS-in-L2TPv3], and IPsec protected tunnels [2547-IPsec]. This document does the same thing for IPv6 VPN service: it supports MPLS LSPs and other tunneling techniques 🧚
This document supports an IPv6 VPN service over an IPv4 backbone and over an IPv6 backbone. The IPv6 VPN service is identical in both cases ✨
The IPv6 VPN solution in this document offers these benefits:
- 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.
- From the Service Provider perspective, operating the IPv6 VPN service requires the exact same skills, procedures, and mechanisms as the IPv4 VPN service.
- 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.
- The IPv6 VPN service is independent of whether the core runs IPv4 or IPv6. So the IPv6 VPN service stays the same before and after a migration of the core from IPv4 to IPv6, and the VPN customer can't tell the difference 🌟
Also, note that supporting IPv4 VPN services over an IPv6 core is not covered by this document 🙅♀️
2. The VPN-IPv6 Address Family 🍓
Okay, this is the part where we meet the new address family 🫶 The BGP Multiprotocol Extensions [BGP-MP] let BGP carry routes from multiple "address families". This doc introduces the "VPN-IPv6 address family", which is similar to the VPN-IPv4 address family from [BGP/MPLS-VPN] ✨
A VPN-IPv6 address is a 24-octet quantity. It starts with an 8-octet "Route Distinguisher" (RD) and ends with a 16-octet IPv6 address 🧮
The RD exists only to let you create distinct routes to a common IPv6 address prefix. That's similar to the purpose of the RD in [BGP/MPLS-VPN]. Just like [BGP/MPLS-VPN] allows, the RD can create multiple different routes to the very same system. You do this by making two VPN-IPv6 routes that share the same IPv6 part but have different RDs. That lets the provider's BGP install multiple different routes to the same system, and policy can decide which packets use which route 🔥
Also, if two VPNs use the same IPv6 address prefix (meaning different physical systems), the PEs translate these into unique VPN-IPv6 address prefixes using different RDs. So if the same address ever shows up in two different VPNs, you can install two completely different routes to that address, one per VPN 🌈
VPN-IPv6 addresses and IPv6 addresses belong to different address families, so BGP never treats them as comparable addresses. Not the same thing, bestie 💜
A VRF can have multiple equal-cost VPN-IPv6 routes for a single IPv6 address prefix. When a packet's destination address gets matched in a VRF against a VPN-IPv6 route, only the IPv6 part is actually matched 👑
The Route Distinguisher format and encoding follow [BGP/MPLS-VPN] 🎀
When a site is both IPv4 capable and IPv6 capable, the same RD MAY be used to advertise IPv6 addresses and IPv4 addresses. Or, a different RD MAY be used to advertise the IPv4 addresses and the IPv6 addresses. Note, though, that in the scope of this specification, IPv4 addresses and IPv6 addresses are always handled in separate contexts. IPv4-IPv6 interworking issues and techniques are not discussed here 🙈
3. VPN-IPv6 Route Distribution 🦋
Okay, part 1 wraps up right here, and we're about to get into how VPN-IPv6 routes actually get distributed. Stay tuned, bestie 💖
3.1. Route Distribution Among PEs by BGP 💖
okay so, as described in [BGP/MPLS-VPN] ✨, if two sites of a VPN attach to PEs that live in the same Autonomous System, those PEs can share VPN routes with each other over an (IPv4) internal Border Gateway Protocol (iBGP) connection between them. 🦋 Or each PE can have iBGP connections to route reflectors instead. Same deal for IPv6 VPN route distribution: PEs can use iBGP connections between each other, or use iBGP connections to route reflectors. For IPv6 VPN, the iBGP connections MAY be over IPv4 or over IPv6. 🫶
The PE routers swap reachability info for the IPv6 prefixes in the IPv6 VPNs using MP-BGP [BGP-MP] 🌸, and in the process they announce themselves as the BGP Next Hop. It's giving teamwork 💅
The rules for encoding the reachability info and the BGP Next Hop address are spelled out 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 along with the IPv6 VPN routes. 🔥 Honestly this is the main character moment: PE routers don't actually distribute plain IPv6 VPN routes. They distribute Labeled IPv6 VPN routes [MPLS-BGP] 💜. When the advertising PE gets a packet carrying that advertised label, it pops the label off the MPLS stack and handles the packet properly (so it either forwards it directly based on the label, or does a lookup in the matching IPv6-VPN context). ✨
The BGP Multiprotocol Extensions [BGP-MP] are how the IPv6 VPN routes get advertised, inside 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 this extension, the prefix belongs to the VPN-IPv6 Address Family, so it's made 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 BGP speaker's policy is to ask that IPv6 VPN traffic gets transported to that BGP Next Hop using IPv6 tunneling ("BGP speaker requesting IPv6 transport") or using IPv4 tunneling ("BGP speaker requesting IPv4 transport"). 🧚
Defining this policy (requesting transport over IPv4 tunneling or IPv6 tunneling) is the responsibility of the network operator, and it's beyond the scope of this document 🙈. Heads up: it's 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). 😭 But in that case there are a bunch of operational implications worth thinking about. Specifically, an undetected fault affecting the IPv4 (resp. IPv6) tunneling data path, which doesn't affect the IPv6 (resp. IPv4) data path, could stay undetected by BGP, and that may end up black-holing 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 (for example, IPv6 MPLS LSPs or 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 may be 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, when an IPv6 CE peers with an IPv6 PE, the CE doesn't have any IPv6 global address, and the eBGP peering runs over the link-local addresses) 🙈, the "unspecified address" [V6ADDR] is used by the advertising BGP speaker to indicate that the global IPv6 address is absent from 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. ✨
So 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. 🧚
One example where both the global IPv6 address and the link-local IPv6 address shall be included in the BGP Next Hop address field: the IPv6 VPN service runs over a multi-Autonomous System (AS) backbone, with labeled VPN-IPv6 routes redistributed between Autonomous System Border Routers (ASBR) of different ASes that share 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 (for example, IPv4 MPLS LSPs or 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. ✨ The encoding of the extended community attribute is defined in [BGP-EXTCOM]. 💅
3.4. BGP Capability Negotiation 🔥
For two PEs to exchange labeled IPv6 VPN NLRIs, they MUST use BGP Capabilities Negotiation, so they can both confirm that they're capable of properly processing those NLRIs. 🫶 This is done as specified in [BGP-MP] and [BGP-CAP], using capability code 1 (multiprotocol BGP), with the AFI and SAFI values 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 it's 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 support particular deployment environments where IPv6 tunneling is desired but 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 lets it find a VPN-IPv6 route. 🦋 The VPN-IPv6 route has an associated MPLS label and an associated BGP Next Hop. ✨ First, this MPLS label gets pushed onto 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. 👑 The 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), encapsulating 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, encapsulating 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] 🔐, encapsulating 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 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 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 onto the label stack of the labeled IPv6 VPN packet (that is, 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 identifies the egress PE router, and in turn the label to be pushed onto the stack. 🙈 When the IPv6 address in the BGP Next Hop field is an IPv4-mapped IPv6 address, the embedded IPv4 address determines the tunnel label to push onto the label stack. 💅 In any other case, the IPv6 address in the BGP Next Hop field determines the tunnel label to push onto 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 ✨
okay so let's talk about address types 🦋 first up, Link-local unicast addresses are only meant for a single link 💅 so they can be used on the PE-CE link, but they're NOT supported for reachability across IPv6 VPN Sites, and they are never advertised via MultiProtocol-Border Gateway Protocol (MP-BGP) to remote PEs 🙈 not me them just being local 💀
then we've got Global unicast addresses 🌍 these uniquely identify interfaces anywhere in the IPv6 Internet, and they're expected to be super common within and across IPv6 VPN Sites 😭 they're fully supported for reachability across IPv6 VPN Sites, get advertised via MP-BGP to remote PEs, and get processed without any special handling for their global scope 👑 iconic behavior honestly
now the bit from [UNIQUE-LOCAL] 📚 it says: "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."
and in its Section 4.7 it adds: "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."
so following that 🎀 Unique Local IPv6 Unicast Addresses are supported by the IPv6 VPN solution in this document for reachability across IPv6 VPN Sites. reachability to them MAY be advertised via MP-BGP to remote PEs and PEs process them the same way as Global Unicast addresses 🫶 wait I need to be careful here, the original says "may be advertised", so I'm keeping it as a MAY, no upgrades or downgrades 😤
and which of these supported address types should be used in a given IPv6 VPN environment? 🤷♀️ that's beyond the scope of this document, bestie 🍓
6. Multicast 🧚
Multicast operations are outside the scope of this document 💜 so we're skipping it here, no cap 😌
7. Carriers' Carriers 🌸
sometimes an IPv6 VPN is actually the network of an IPv6 ISP, with its own peering and routing policies 💅 and sometimes an IPv6 VPN is the network of an SP that offers VPN services to its own customers 👑 these IPv6 VPNs can also get backbone service from another SP, the "Carrier's Carrier", using the Carriers' Carrier method from Section 9 of [BGP/MPLS-VPN], just applied to IPv6 traffic ✨
all the considerations in [BGP/MPLS-VPN] for IPv4 VPN Carriers' Carrier apply to IPv6 VPNs too 🦋 the one exception is that MPLS (including label distribution) between the PE and the CE is about IPv6 routes instead of IPv4 routes 🎀
8. Multi-AS Backbones 🌈
the same procedures from Section 10 of [BGP/MPLS-VPN] can be used (and they have the same scalability properties) when two sites of an IPv6 VPN are connected to different Autonomous Systems 🫶 but there are a few extra points to note for IPv6 VPNs, and we'll go through them in the rest of this section 💖
8.1. Approach (a): VRF-to-VRF connections at the AS (Autonomous System) border routers
Hmm, the original doesn't number this as a subsection, so I'll keep the label as written:
Approach (a): VRF-to-VRF connections at the AS (Autonomous System) border routers.
this is the IPv6 version of procedure (a) in Section 10 of [BGP/MPLS-VPN] 🌸 IPv6 has to be activated on the inter-ASBR VRF-to-VRF (sub)interfaces 💅 in this approach the ASBRs exchange IPv6 routes (not VPN-IPv6 routes) and they can peer over IPv6 or over IPv4 🦋 the exchange of IPv6 routes MUST be carried out as per [BGP-IPv6] 👑 and this method does NOT use inter-AS LSPs 💀
finally, since every AS independently implements the intra-AS procedures for IPv6 VPNs described in this document, the participating ASes can all use IPv4 tunneling internally, or all use IPv6 tunneling 🌈 or some can use IPv4 tunneling while others use IPv6 tunneling, mixing and matching 🧚
Approach (b): EBGP redistribution of labeled VPN-IPv6 routes from AS to neighboring AS.
this is the IPv6 equivalent of procedure (b) in Section 10 of [BGP/MPLS-VPN] 🎀 here the ASBRs use EBGP to redistribute labeled VPN-IPv4 routes to ASBRs in other ASes 💅
IPv6 may or may not be activated on the inter-ASBR links 🤷♀️ since the ASBRs exchanging VPN-IPv6 routes can peer over IPv4 or IPv6 (and if they peer over IPv6, IPv6 obviously needs to be activated on that inter-ASBR link 🙄). the exchange of labeled VPN-IPv6 routes MUST be carried out as per [BGP-IPv6] and [MPLS-BGP] 💜 when VPN-IPv6 traffic is transported using IPv6 tunneling, the BGP Next Hop Field SHALL contain an IPv6 address 🫶 when VPN-IPv6 traffic is transported using IPv4 tunneling, the BGP Next Hop Field SHALL contain an IPv4 address encoded as an IPv4-mapped IPv6 address 🔥
this approach requires inter-AS LSPs 😤 so the corresponding (security) considerations for procedure (b) in Section 10 of [BGP/MPLS-VPN] apply equally to this approach for IPv6 🔒 yikes but important
finally, same energy as procedure (a) 💅 every AS independently implements the intra-AS procedures for IPv6 VPNs from this document, so the participating ASes can all use IPv4 tunneling or IPv6 tunneling internally, or mix it up with some on IPv4 and some on IPv6 🌸
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 one is equivalent, for exchanging VPN-IPv6 routes, to procedure (c) in Section 10 of [BGP/MPLS-VPN] for exchanging VPN-IPv4 routes 🧚
this approach requires that the participating ASes either all use IPv4 tunneling or all use IPv6 tunneling 💜 no mixing here, bestie 🙅♀️
in this approach, VPN-IPv6 routes are neither maintained nor distributed by the ASBR routers 🦋 the ASBR routers do NOT need to be dual stack 🎀 an ASBR needs to maintain labeled IPv4 (or IPv6) routes to the PE routers within its AS 💅 and it uses EBGP to distribute these routes to other ASes 👑 ASBRs in any transit ASes also have to use EBGP to pass along the labeled IPv4 (or IPv6) routes 🌈 this creates an IPv4 (or IPv6) label switch path from ingress PE router to egress PE router ✨ now PE routers in different ASes can set up multi-hop EBGP connections to each other over IPv4 or IPv6 and exchange labeled VPN-IPv6 routes over those connections 🫶 the BGP Next Hop field of these distributed VPN-IPv6 routes contains an IPv6 address when IPv6 tunneling is used, or an IPv4-mapped IPv6 address when IPv4 tunneling is used 💖
the considerations in Section 10 of [BGP/MPLS-VPN] for procedure (c), about possible use of route-reflectors, a possible third label, and LSPs spanning multiple ASes, apply equally to this IPv6 VPN approach 🔥
9. Accessing the Internet from a VPN 🌍
the methods from [BGP/MPLS-VPN] for accessing the global IPv4 Internet from an IPv4 VPN can be used with IPv6 VPNs and the global IPv6 Internet 💅 BUT 😭 if IPv6 packets from IPv6 VPN sites headed for the global IPv6 Internet need to cross the SP backbone, and that backbone is IPv4 only, those packets MUST be tunneled through that IPv4 backbone 🚨
clearly, just like outside the VPN context, accessing the IPv6 Internet from an IPv6 VPN requires global IPv6 addresses 👑
and in particular, Unique Local IPv6 addresses cannot be used for IPv6 Internet access 🙅♀️ (they're local, bestie 🧚)
10. Management VPN 🎀
the management considerations in Section 12 of [BGP/MPLS-VPN] apply to managing IPv6 VPNs 💜
where the Service Provider manages the CE of the IPv6 VPN site, the SP MAY choose IPv4 for communication between the management tool and the CE 🦋 in that case, whether or not a customer IPv4 site is actually connected to the CE (on top of the IPv6 site), the CE is effectively part of an IPv4 VPN as well as an IPv6 VPN 🌸 (the CE is attached to a VRF that supports IPv4 in addition to IPv6 😌) the considerations in [BGP/MPLS-VPN], about making sure the management tool can talk to managed CEs from multiple VPNs without allowing undesired reachability across CEs of different VPNs, apply to the IPv4 reachability of the VRF the CE attaches to 🫶
where the Service Provider manages the CE of the IPv6 VPN site, the SP MAY choose IPv6 for communication between the management tool and the CE 🧚 then the considerations in [BGP/MPLS-VPN] about the same management tool reaching managed CEs from multiple VPNs (without undesired cross-VPN reachability) apply to the IPv6 reachability of the VRF the CE attaches to 💅
11. Security Considerations 🔒
the extensions in this document let MP-BGP propagate reachability information about IPv6 VPN routes 💖
security considerations for transporting IPv6 reachability information using BGP are discussed in RFC2545, Section 5, and they apply equally to the extensions in this document 🦋
the extensions in this document for offering IPv6 VPNs use the EXACT same approach as [BGP/MPLS-VPN] 🌈 so the same security considerations apply, covering Data Plane security, Control Plane security, and PE and P device security, as described in [BGP/MPLS-VPN], Section 13 😭🔥
12. Quality of Service ✨
all the QoS mechanisms from Section 14 of [BGP/MPLS-VPN] for IPv4 VPNs (Diffserv, Intserv, MPLS Traffic Engineering) work the same way for IPv4 and IPv6 🎀 so the QoS considerations 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 on 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 on 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 ✨
okay so these are the must-read ones, bestie 💖 the spec literally can't work without them
[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 ✨
and these are the nice-to-know extras that give you the full picture 🦋
[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 🎀
meet the squad who wrote this thing, they're literally iconic 👑
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.comFull Copyright Statement 💜
the legal bits, but make it cute 🙈
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions in BCP 78. Apart from what that says, the authors keep 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 doesn't take a side on whether any Intellectual Property Rights or other rights that someone might claim over the technology in this document are valid or how far they reach. It also doesn't say whether licenses for those rights are available. It hasn't independently checked for any such rights either. Info on how RFC documents handle rights lives in BCP 78 and BCP 79.
Copies of IPR disclosures sent to the IETF Secretariat, plus any assurances of licenses, or the results of any attempt to get a general license or permission for implementers or users of this spec, can be found in the IETF's online IPR repository at http://www.ietf.org/ipr.
The IETF invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org. 💅
Acknowledgement 🧚
Funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA). Thank you, IASA, you're the real MVP ⭐
📦 where this page comes from
- ietf: rfc4659 2006-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms