The IESG has approved the following document: - 'BGP-MPLS IP VPN extension for IPv6 VPN ' <draft-ietf-l3vpn-bgp-ipv6-07.txt> as a Proposed Standard This document is the product of the Layer 3 Virtual Private Networks Working Group. The IESG contact persons are Mark Townsley and Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-bgp-ipv6-07.txt Technical Summary This document describes a method by which a Service Provider may use its packet switched backbone to provide Virtual Private Network services for its IPv6 customers. This method reuses, and extends where necessary, the "BGP/MPLS IP VPN" method [2547bis] for support of IPv6. In particular, this method uses the same "peer model" as [2547bis], in which the customers' edge routers ("CE routers") send their IPv6 routes to the Service Provider's edge routers ("PE routers"). BGP ("Border Gateway Protocol", [BGP, BGP-MP]) is then used by the Service Provider to exchange the routes of a particular IPv6 VPN among the PE routers that are attached to that IPv6 VPN. Eventually, the PE routers distribute, to the CE routers in a particular VPN, the IPv6 routes from other CE routers in that VPN. As with IPv4 VPNs, a key characteristic of this "peer model" is that the (IPv6) CE routers within an (IPv6) VPN do not peer with each other and there is no "overlay" visible to the (IPv6) VPN's routing algorithm. A VPN is said to be an IPv6 VPN, when each site of this VPN is IPv6 capable and is natively connected over an IPv6 interface or sub- interface to the SP backbone via a Provider Edge device (PE). A site may be both IPv4-capable and IPv6-capable. The logical interface on which packets arrive at the PE may determine the IP version. Alternatively the same logical interface may be used for both IPv4 and IPv6 in which case a per-packet lookup at the Version field of the IP packet header determines the IP version. This document only concerns itself with handling of the IPv6 packets. As such the inter-working between an IPv4 site and an IPv6 site is outside the scope of this document. In a similar manner to how IPv4 VPN routes are distributed in [2547bis], BGP and its extensions are used to distribute routes from an IPv6 VPN site to all the other PE routers connected to a site of the same IPv6 VPN. PEs use "VPN Routing and Forwarding tables" (VRFs) to separately maintain the reachability information and forwarding information of each IPv6 VPN. As it is done for IPv4 VPNs [2547bis], we allow each IPv6 VPN to have its own IPv6 address space, which means that a given address may denote different systems in different VPNs. This is achieved via a new address family, the VPN-IPv6 Address Family, in a fashion similar to the VPN-IPv4 address family defined in [2547bis] and which prepends a Route Distinguisher to the IP address. In addition to its operation over MPLS Label Switched Paths (LSPs), the IPv4 BGP/MPLS VPN solution has been extended to allow operation over other tunneling techniques including GRE tunnels, IP-in-IP tunnels [2547-GRE/IP], L2TPv3 tunnels [MPLS-in-L2TPv3] and IPsec- protected tunnels [2547-IPsec]. In a similar manner, this document allows support of an IPv6 VPN service over MPLS LSPs as well as over other tunneling techniques including GRE tunnels, IP-in-IP tunnels, L2TPv3 tunnels and IPsec-protected tunnels. This document allows support for an IPv6 VPN service over an IPv4 backbone as well as over an IPv6 backbone. The IPv6 VPN service supported is identical in both cases. Working Group Summary This document went smoothly through the WG process. Protocol Quality At least two vendors have developed to earlier versions of this draft. Jeffrey Haas and Pedro Marques both commented on the draft as it went through multiple revisions. RFC Editor Note: The document's references to draft-ietf-ipv6-unique-local-addr-09.txt need to be updated; one section refers to Section 10, which no longer exists. I believeit should refer to Section 4.7. Please search and replace on "byte" replacing it with "octet" throughout the document. Please remove the reference to [RFC2547bis] in the Abstract. There are citation inconsistencies, please work with the authors to clear theseup. See tracker for reference check tool output. Please add the following clarifying sentence at the end of Section 5: "Recommendations and considerations for which of these supported address types should be used in a given IPv6 VPN environments are beyond the scope of this document" _______________________________________________ IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
