1. IETF 61 draft-ooms-v6ops-bgp-tunnel-04.txt Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider Edge Routers (6PE) Francois Le Faucheur - flefauch@cisco.com J. De Clerq, Alcatel D. Ooms S. Prevost, BT F. Le Faucheur, Cisco Systems

2. IETF 61 draft-ooms-v6ops-bgp-tunnel-04.txt P P P P IPv4 MPLS v4 CE PE 192.76.10.0 145.95.0.0 IPv6 Provider Edge Router (6PE): Problem Statement - Operator offers IPv4 services (IPv4 Internet, IPv4 VPNs) - Operator runs an IPv4 MPLS core v4

3. IETF 61 draft-ooms-v6ops-bgp-tunnel-04.txt P P P P v6 IPv4 MPLS v4 v6 v4 v6 CE 6PE 2001:0421:: 2001:0420:: 192.76.10.0 145.95.0.0 2001:0621:: 2001:0620:: IPv6 Provider Edge Router (6PE): Problem Statement v4 - Operator offers IPv4 services (IPv4 Internet, IPv4 VPNs) - Operator runs an IPv4 MPLS core - Operator wants to offer Global IPv6 rechability (IPv6 Internet) - Operator wants to keep the core IPv6-unaware

4. IETF 61 draft-ooms-v6ops-bgp-tunnel-04.txt P P P P v6 IPv4 MPLS v6 v4 v6 MP-iBGP sessions CE 6PE 2001:0421:: 2001:0420:: 145.95.0.0 2001:0621:: 2001:0620:: Dual Stack IPv4-IPv6 routers IPv6 Provider Edge Router (6PE): Solution - use existing protocol elements in a specific combination to achieve interoperability - use same architecture as 2547 and IPv6 VPN I-D (draft-ietf-l3vpn-bgp-ipv6) o IPv6 reachability information advertised Edge-to-Edge in MP-BGP o IPv4 MPLS transport through the core - 6PE advertises IPv6 NLRI with IPv4 Next Hop encoded as an “IPv4-mapped” IPv6 address

5. IETF 61 draft-ooms-v6ops-bgp-tunnel-04.txt v6ops and AD Consensus Quote from v6ops chair: “ In draft-ietf-v6ops-isp-scenarios-analysis-03.txt we (v6ops) found that we need draft-ooms-v6ops bgp-tunnel-03.txt ("6PE/BGP-tunnel") to provide easier transition for IPv4 MPLS networks. Let me try to summarize the consensus: 1. Problem: to deploy IPv6 over an MPLS network, you'll have to either use manually configured tunnels, deploy IPv6 natively, or upgrade the whole signalling plane to support IPv6. The MPLS operators haven't been enthusiastic about the last option, and in many cases, the others aren't suitable either (if the network is extensive, or using vendors without sufficient native IPv6 capabilities). Therefore an automatic encapsulation in IPv4 MPLS network is needed. 2. Why this solution: there haven't been other proposed solutions to this problem (in v6ops). However, one should note that the generic provider-provisioned VPN framework provides a slightly more extensive means to solve this problem, but is overly complex to those who do not need to provide IPv6 VPN services (but just want to support IPv6 over their MPLS core). Further, draft-ooms-v6ops-bgp-tunnel- 03.txt has been implemented, is interoperable, and has been already extensively deployed. 3. Is this ready: the document is ready to be progressed by the routing area for Standards Track -- it has recently been revised a couple of times to remove unneeded functionality that was present earlier on, and is now a very simple and compact specification. “

6. IETF 61 draft-ooms-v6ops-bgp-tunnel-04.txt Changes 03  04 Cleaned-up usage of “MUST/SHOULD/MAY” Expanded Inter-AS scenarios Expanded Security Considerations

7. IETF 61 draft-ooms-v6ops-bgp-tunnel-04.txt Relationship with l3vpn-bgp-ipv6 draft-ooms-v6ops-bgp-tunnel-04 specifies Global IPv6 reachability draft-ietf-l3vpn-bgp-ipv6-03.txt specifies BGP/MPLS IPv6 VPNs (due for Last Call) Both documents are consistent where they can be –(eg. Architecture, IPv6 AFI, IPv4-mapped IPv6 address) Documents differ where needed –(eg. Label SAFI vs VPN SAFI, all VPN machinery VRFs/RD/RT not applicable to bgp-tunnel,…)

8. IETF 61 draft-ooms-v6ops-bgp-tunnel-04.txt Next Steps Issue Last Call Conduct Implementation Survey