A. 6PE uses two labels:
The top label is the transport label, which is assigned hop-by-hop by
the Label Distribution Protocol (LDP) or by MPLS traffic engineering
The bottom label is the label assigned by the Border Gateway Protocol
(BGP) and advertised by the internal BGP (iBGP) between the Provider Edge (PE)
When the 6PE was released, a main requirement was that none of the MPLS
core routers (the P routers) had to be IPv6-aware. That requirement drove the
need for two labels in the data plane. There are two reasons why the 6PE needs
If only the transport label were used, and if penultimate hop popping
(PHP) were used, the penultimate hop router (the P router) would need to
With PHP, this penultimate hop router would need to remove the MPLS
label and forward the packet as an IPv6 packet. This P router would need to
know that the packet is IPv6 because the P router would need to use the correct
Layer 2 encapsulation type for IPv6. (The encapsulation type is different for
IPv6 and IPv4; for example, for Ethernet, the encapsulation type is 0x86DD for
IPv6, while it is 0x0800 for IPv4.) If the penultimate hop router is not
IPv6-capable, it would likely put the Layer 2 encapsulation type for IPv4 for
the IPv6 packet. The egress PE router would then believe that the packet was
There is time-to-live (TTL) processing in both the IPv4 and IPv6
headers. In IPv6, the field is called Hop Limit. The IPv4 and IPv6 fields are
at different locations in the headers. Also, the Header Checksum in the IPv4
header would also need to be changed; there is no Header Checksum field in
IPv6. If the penultimate hop router is not IPv6-capable, it would cause the
IPv6 packet to be malformed since the router expects to find the TTL field and
Header Checksum field in the header.
Because of these differences, the penultimate hop router would need to
know it is an IPv6 packet. How would this router know that the packet is an
IPv6 packet, since it did not assign a label to the IPv6 Forwarding Equivalence
Class (FEC), and there is no encapsulation field in the MPLS header? It could
scan for the first nibble after the label stack and determine that the packet
is IPv6 if the value is 6. However, that implies that the penultimate hop
router needs to be IPv6-capable.
This scenario could work if the explicit null label is used (hence no
PHP). However, the decision was to require PHP.
Typical load balancing on a P router follows this process. The P router
goes to the end of the label stack and determines if it is an IPv4 packet by
looking at the first nibble after the label stack.
If the nibble has a value of 4, the MPLS payload is an IPv4 packet,
and the P router load balances by hashing the source and destination IPv4
If the P router is IPv6-capable and the value of the nibble is 6, the
P router load balances by hashing the source and destination IPv6 addresses.
If the P router is not IPv6-capable and the value of the nibble is
not 4 (it could be 6 if the packet is an IPv6 packet), the P router determines
it is not an IPv4 packet and makes the load balancing decision based on the
In the 6PE scenario, imagine there are two egress PE routers
advertising one IPv6 prefix in BGP towards the ingress PE router. This IPv6
prefix would be advertised with two different labels in BGP. Hence, in the data
plane, the bottom label would be either of the two labels. This would allow a P
router to load balance on the bottom label on a per-flow basis.
If 6PE used only the transport label to transport the 6PE packets
through the MPLS core, the P routers would not be able to load balance these
packets on a per-flow basis unless the P routers were IPv6-capable. If the P
routers were IPv6-capable, they could use the source and destination IPv6
addresses in order to make a load balancing decision.