Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)
Extracted elements (25)
A second (inner) label is required rather than a single label because PHP on the penultimate IPv4 LSR would expose the egress 6PE to raw IPv6 packets without MPLS encapsulation, and an existing LSP using 'IPv4 Explicit NULL' cannot carry native IPv6 traffic (RFC 3032) but can carry labeled IPv6 traffic (RFC 4182).
The 6PE approach avoids explicit tunnel configuration by using MP-BGP to convey the IPv4 address of the egress 6PE as an IPv4-mapped IPv6 Next Hop, allowing dynamic use of existing IPv4-signaled LSPs without additional provisioning.
The 6PE approach requires only edge routers to be upgraded to Dual Stack, leaving the IPv4 MPLS core untouched. This makes it suitable for ISPs that want to offer IPv6 services without upgrading core infrastructure.
Configuration and operations of the 6PE approach are similar to BGP/MPLS IPv4 VPN (RFC 4364) and IPv6 VPN (RFC 4659) services since all use MP-BGP to distribute non-IPv4 reachability over an IPv4 MPLS core, but 6PE is simpler as it does not involve VRF tables.
In inter-AS case (c), exchange of IPv6 routes can only start after BGP has established IPv4 connectivity between the ASes, since the end-to-end IPv4 LSP must exist first.
A second label MUST be used with the 6PE approach; this label is bound via MP-BGP to the IPv6 prefix and signals to the egress 6PE that the packet is an IPv6 packet.
All 6PE implementations MUST support tunneling using IPv4-signaled MPLS LSPs established by LDP (RFC 3036) to ensure interoperability.
An ingress 6PE Router MUST be able to accept any label advertised by the egress 6PE Router via MP-BGP, whether it is an arbitrary label value or the IPv6 Explicit Null Label.
For inter-AS case (a), the exchange of IPv6 routes MUST be carried out as per RFC 2545.
For inter-AS case (b), when peering over IPv6 the exchange of labeled IPv6 routes MUST be per RFC 2545 and RFC 3107; when peering over IPv4, the ASBR's IPv4 address MUST be encoded as an IPv4-mapped IPv6 address in the BGP Next Hop field.
In inter-AS cases (b) and (c), an ASBR 6PE SHOULD only accept labeled packets from its peer ASBR 6PE if the topmost label is one it has explicitly signaled to that peer, to avoid label spoofing.
On MPLS links used for transport of IPv6 via the 6PE approach that do not support link-specific fragmentation and reassembly, the MTU must be configured to at least 1280 octets plus the encapsulation overhead.
The 6PE MUST bind a label to the IPv6 prefix as per RFC 3107, and the SAFI used in MP-BGP MUST be the 'label' SAFI (value 4) as defined in RFC 3107.
The 6PE router MUST be dual stack IPv4 and IPv6, and MUST be configured with at least one IPv4 address on the IPv4 side and at least one IPv6 address on the IPv6 side.
The 6PE routers MUST exchange IPv6 prefixes over MP-BGP sessions as per RFC 2545 running over IPv4, with the MP-BGP Address Family Identifier (AFI) set to IPv6 (value 2).
The ingress 6PE Router MUST directly perform label imposition of the IPv6 header without prepending any IPv4 header; the outer label imposed MUST correspond to the IPv4-signaled LSP from ingress to egress 6PE.
The ingress 6PE router MUST forward IPv6 data over the IPv4-signaled LSP towards the egress 6PE router identified by the IPv4 address encoded in the IPv4-mapped IPv6 BGP Next Hop.
The IPv4 address of the egress 6PE router MUST be encoded as an IPv4-mapped IPv6 address in the BGP Next Hop field when advertising IPv6 prefixes.
MP-BGP is used with AFI=2 (IPv6) and SAFI=4 (labeled) to distribute IPv6 prefixes with bound MPLS labels across the IPv4 core. The BGP Next Hop encodes the egress 6PE's IPv4 address as an IPv4-mapped IPv6 address.
The 6PE router is a Dual Stack router at the border of the IPv4 MPLS cloud, connecting IPv6 islands to the MPLS core. It speaks MP-BGP over IPv4 to exchange IPv6 reachability and uses IPv4-signaled LSPs for data transport without requiring IPv6 in the core.
Three approaches exist for crossing multiple IPv4 ASes: (a) eBGP redistribution of unlabeled IPv6 routes between ASBRs with separate per-AS LSP meshes; (b) eBGP redistribution of labeled IPv6 routes requiring inter-AS LSPs; (c) multi-hop eBGP with eBGP redistribution of labeled IPv4 /32 routes to build end-to-end LSPs across ASes.
Two levels of MPLS labels are used: an outer label corresponding to the IPv4-signaled LSP to the egress 6PE, and an inner label bound by MP-BGP to the IPv6 prefix per RFC 3107 that identifies the IPv6 routing context at the egress.
In inter-AS case (c), label spoofing is harder to prevent because the MPLS label for IPv6 routes is advertised transparently through AS boundaries via multi-hop eBGP, and the egress 6PE cannot verify whether an arriving labeled packet was legitimately pushed by an authorized ingress 6PE. This issue is identified as for further study.
No new security issues beyond BGP-4 and MP-BGP for IPv6 are introduced. For inter-AS cases (b) and (c), appropriate trust relationships must exist between ASes along the path, and ASBR 6PEs should only accept labeled packets with labels they explicitly signaled to the peer.
The BGP Next Hop field for IPv6 prefixes carries the egress 6PE's IPv4 address encoded as an IPv4-mapped IPv6 address (::ffff:0:0/96 prefix per RFC 4291), enabling automatic determination of the IPv4-signaled LSP to use.