The 6PE model is based on IPv6 labeled unicast BGP (BGP-LU) as routing information and distribution vehicle among different systems. Although configuring IPv6 BGP-LU is simple with Junos OS, there are some relevant details to analyze. This post reviews the needed protocol resources, applicable Junos OS configuration and some expected results in the field. Feedback about this topic would be much appreciated, please feel free to chime in!
The IPv6 labeled-unicast MP-BGP family
[RFC2545] defined the support for IPv6 address family routes with Border Gateway Protocol (BGP) version 4 by means of specific Multiprotocol extensions. This was the first building block to enable IPv6 routing distribution via BGP.
Later, [RFC3107] described mechanisms and structures needed to associate an MPLS label to a BGP route. This implementation has been traditionally called Labeled BGP (L-BGP) or Labeled Unicast BGP (BGP-LU) and basically makes use of BGP structures to distribute MPLS label bindings.
BGP-LU is a tremendously useful MPLS label distribution protocol between adjacent Label Switched Routers (LSRs), among Autonomous System Border Routers (ASBRs) to distribute label bindings across different domains (and therefore allowing InterAS MPLS LSPs) and may act as MPLS label binding transport in an overlay hierarchy over another internal MPLS label distribution protocol, such as the Label Distribution Protocol (LDP) or the Resource Reservation Protocol with Traffic Engineering extensions (RSVP-TE).
In the case of the 6PE model, the MP-BGP sessions may be established between peers represented by IPv4 addresses, but they use the IPv6 BGP-LU family. This protocol can be then used to distribute label bindings for IPv6 prefixes between IPv4-based control planes.
Next Hops for the 6PE model
Unlike IPv4, IPv6 introduces different scopes for unicast addresses; mostly global and link-local addresses as per [RFC4007] (site-local got deprecated with [RFC3879] because the concept was too fuzzy, and we take Unique Local Addresses apart). At a first sight, link-local addresses may not look suitable to be conveyed in the NEXT HOP attribute of a particular route, but there are certain IPv6 mechanisms, such as ICMP Redirect Messages for Neighbor Discovery, or protocols, such as RIPng that rely on link-local addresses to be used.
In the 6PE model, the generic situation (particularly in the case of internal BGP (iBGP)) results in a single global IPv6 address being set as BGP NEXT HOP and the removal of link-local addresses when advertising such routes to iBGP peers.
A proper recursive resolution to a valid Next Hop for IPv6 prefixes requires that BGP Next Hop addresses are represented embedded in IPv6 prefixes. IPv4-Mapped IPv6 addresses represent a transition mechanism in which the IPv4 prefix is automatically and uniquely embedded into the IPv6 address and is an adequate tool for this purpose. These IPv4-mapped IPv6 addresses are defined in [RFC4291] Section 18.104.22.168 to represent the addresses of IPv4 nodes as IPv6 addresses:
The IPv6 labeled-unicast NLRI format
To represent such label binding associated to a BGP route, the MPLS label is encoded into the Network Layer Reachability Information (NLRI) field of the attribute, and the concrete SAFI value of 4 indicates that such NLRI is used for label binding. This NLRI encoding is performed by setting triples of length, label, prefix. This looks like the following:
For proper scalability, multiple routes to a single or several destinations can be easily transported, advertised and withdrawn. It simply requires that a specific label is bound to each route and they may all be carried in the same BGP Update message.
And the reason for that configuration knob comes now...
6PE label allocation
Let's look at the BGP Updates with these NLRIs on the wire, as described above. Assuming a multivendor topology between a Junos OS PE and a MP-iBGP Route Reflector from another vendor, a BGP Update with some IPv6 labeled-unicast routes looks as follows:
The label bound by MP-BGP to the IPv6 prefix indicates to the egress
6PE Router that the packet is an IPv6 packet. This label advertised
by the egress 6PE Router with MP-BGP MAY be an arbitrary label value,
which identifies an IPv6 routing context or outgoing interface to
send the packet to, or MAY be the IPv6 Explicit Null Label. An
ingress 6PE Router MUST be able to accept any such advertised label.
So, the current understanding in Junos OS is that 2 suffices for identification and resolution in this environment. The key component is that this prefix needs to be resolved in the global IPv6 RIB (inet6.0 in Junos wording) so the prefix by itself should provide uniqueness, in order to identify and resolve the route. It is not constrained to a particular private RIB or context (as a VRF) where another distinguisher would be needed.
The summary is that IPv6 BGP-LU requires specific Next Hop types and implements label binding per IPv6 prefix. In a 6PE interop environment one should expect Junos OS devices allocating label 2 for originated IPv6 prefixes and one may expect others allocating arbitrary labels.
Does it pose a problem for route identification or resolution? Not in the case of a Junos OS 6PE router (aligned with standard excerpt above). Using the same example above: