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 (TE).
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) routers.
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 both labels.
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 understand IPv6.
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 IPv4.
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 addresses.
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 bottom label.
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.