Skip to main content

BGP-MPLS IP Virtual Private Network (VPN) Extension for IPv6 VPN
RFC 4659

Approval announcement
Draft of message to be sent after approval:


From: The IESG <>
To: IETF-Announce <>
Cc: Internet Architecture Board <>,
    RFC Editor <>, 
    l3vpn mailing list <>, 
    l3vpn chair <>
Subject: Protocol Action: 'BGP-MPLS IP VPN extension for IPv6 
         VPN' to Proposed Standard 

The IESG has approved the following document:

- 'BGP-MPLS IP VPN extension for IPv6 VPN '
   <draft-ietf-l3vpn-bgp-ipv6-08.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 Ross Callon.

A URL of this Internet-Draft is:

Ballot Text

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

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"

RFC Editor Note