[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 RFC 4659

INTERNET DRAFT                                          Jeremy De Clercq
<draft-ietf-l3vpn-bgp-ipv6-03.txt>                             Dirk Ooms
                                                                 Alcatel
                                                            Marco Carugi
                                                         Nortel Networks
                                                    Francois Le Faucheur
                                                           Cisco Systems

                                                               June 2004
                                                  Expires December, 2004

                  BGP-MPLS VPN extension for IPv6 VPN

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months. Internet-Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet-
   Drafts as reference material or to cite them other than as a
   ``working draft'' or ``work in progress.''

   To view the entire list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
   Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au(Pacific
   Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).

   Distribution of this memo is unlimited.

Abstract

   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 extends the "BGP/MPLS
   VPN" method [2547bis] for support of IPv6. In BGP/MPLS VPN,
   "Multiprotocol BGP" is used for distributing IPv4 VPN routes over the
   service provider backbone and MPLS is used to forward IPv4 VPN
   packets over the backbone. This document defines an IPv6 VPN address
   family and describes the corresponding route distribution in
   "Multiprotocol BGP". This document defines support of the IPv6 VPN
   service over both an IPv4 and an IPv6 backbone, and using various



De Clercq, et al.        Expires December 2004                  [Page 1]


Internet Draft         draft-ietf-l3vpn-bgp-ipv6               June 2004


   tunnelling techniques over the core including MPLS, IPsec, IP-in-IP
   and GRE.

1. Introduction

   This document adopts the definitions, acronyms and mechanisms
   described in [2547bis]. Unless otherwise stated, the mechanisms of
   [2547bis] apply and will not be re-described here.

   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- and IPv6-capable. The logical interface on
   which packets arrive at the PE may determine the version, but
   alternatively the same logical interface MAY be used for both IPv4
   and IPv6 in which case a per-packet header lookup determines the
   version. This document only concerns itself with handling of the IPv6
   packets.

   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 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 definition given by [2547bis].

   In addition to operation over MPLS Label Switched Paths (LSPs), the
   BGP/MPLS VPN solution is extended to allow operation over other
   tunnelling techniques including GRE tunnels, IP-in-IP tunnels [2547-
   GRE/IP] and IPsec tunnels [2547-IPsec]. In a similar manner, this
   document allows support of an IPv6 VPN service over MPLS LSPs as well
   as over other tunnelling techniques including GRE tunnels, IP-in-IP
   tunnels and IPsec 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.

   The IPv6 VPN solution defined in this document offers the following
   benefits:

      o from both the Service Provider perspective and the customer



De Clercq, et al.        Expires December 2004                  [Page 2]


Internet Draft         draft-ietf-l3vpn-bgp-ipv6               June 2004


      perspective, the VPN service that can be supported for IPv6 sites
      is identical to the one that can be suported for IPv4 sites;

      o from the Service Provider perspective, operations of the IPv6
      VPN service require the exact same skills, procedures and
      mechanisms as for the IPv4 VPN service;

      o where both IPv4 VPNs and IPv6 VPN services are supported over an
      IPv4 core, the same single set of MP-BGP peering relationships and
      the same single PE-PE tunnel mesh MAY be used for both;

      o independence of whether the core runs IPv4 or IPv6. So that the
      IPv6 VPN service supported before, and after a migration of the
      core from IPv4 to IPv6 is undistinguishable to the VPN customer.

2. The VPN Address Family

   The BGP Multiprotocol Extensions [BGP-MP] allow BGP to carry routes
   from multiple "address families".  We introduce the notion of the
   "VPN-IPv6 address family", that is similar to the VPN-IPv4 address
   family introduced in [2547bis].

2.1 The VPN-IPv6 Address Family

   A VPN-IPv6 address is a 24-byte quantity, beginning with an 8-byte
   "Route Distinguisher" (RD) and ending with a 16-byte IPv6 address.
   If two VPNs use the same IPv6 address prefix (effectively denoting
   different physical systems), the PEs translate these into unique
   VPN-IPv6 address prefixes using different RDs. This ensures that if
   the same address is used in two different VPNs, it is possible to
   install two completely different routes to that address, one for each
   VPN.

   The purpose of the RD is solely to allow one to create distinct
   routes to a common IPv6 address prefix, similarly to the purpose of
   the RD defined in [2547bis]. As it is possible per [2547bis], the RD
   can also be used to create multiple different routes to the very same
   system. This can be achieved by creating two different VPN-IPv6
   routes that have the same IPv6 part, but different RDs. This allows
   BGP to install multiple different routes to the same system, and
   allows policy to be used to decide which packets use which route.

   Note that VPN-IPv6 addresses and IPv6 addresses are always considered
   by BGP to be incomparable.

   A VRF may have multiple equal-cost VPN-IPv6 routes for a single IPv6
   address prefix.  When a packet's destination address is matched in a
   VRF against a VPN-IPv6 route, only the IPv6 part is actually matched.



De Clercq, et al.        Expires December 2004                  [Page 3]


Internet Draft         draft-ietf-l3vpn-bgp-ipv6               June 2004


   When a site is IPv4- and IPv6-capable, the same RD MAY be used for
   the advertisement of IPv6 addresses and IPv4 addresses.

2.2. Encoding of Route Distinguishers

   The RDs are encoded as per [2547bis]:

   - TYPE field: 2 bytes

   - VALUE field: 6 bytes

   The interpretation of the VALUE field depends on the value of the
   TYPE field. As it is the case in [2547bis], 3 encodings can be used:

   - TYPE field = 0 : the VALUE field consists of the following two
   subfields:

      * Administrator subfield: 2 bytes, it contains an Autonomous
      System Number
      * Assigned Number subfield: 4 bytes

   - TYPE field = 1 : the VALUE field consists of the following two
   subfields:

      * Administrator subfield: 4 bytes, it contains a global IPv4
      address
      * Assigned Number subfield: 2 bytes

   - TYPE field = 2 : the VALUE field consists of the following two
   subfields:

      * Administrator subfield: 4 bytes, it contains a 4-byte Autonomous
      System Number
      * Assigned Number subfield: 2 bytes

3. VPN-IPv6 route distribution

3.1. Route Distribution Among PEs by BGP

   As described in [2547bis], if two sites of a VPN attach to PEs which
   are in the same Autonomous System, the PEs can distribute VPN routes
   to each other by means of an (IPv4) iBGP connection between them.
   Alternatively, each PE can have an iBGP connection to a route
   reflector. Similarly, for IPv6 VPN route distribution, PEs can use an
   iBGP connection between them or use iBGP connections to a route
   reflector.

   The PE routers:



De Clercq, et al.        Expires December 2004                  [Page 4]


Internet Draft         draft-ietf-l3vpn-bgp-ipv6               June 2004


   (i) exchange, via MP-BGP [MP-BGP], reachability information for the
   IPv6 prefixes in the IPv6 VPNs.

   (ii) announce themselves as the BGP Next Hop.

3.2 VPN IPv6 NLRI encoding

   The advertising PE router MUST also assign and distribute MPLS labels
   with the IPv6 VPN routes. Essentially, PE routers do not distribute
   IPv6 VPN routes, but Labeled IPv6 VPN routes [MPLS-BGP]. When the
   advertising PE receives a packet that has this particular advertised
   label, the PE will pop the MPLS stack, and process the packet
   appropriately (i.e. forward it directly based on the label or perform
   a lookup in the corresponding IPv6-VPN context).

   The BGP Multiprotocol Extensions [BGP-MP] are used to encode the
   MP_REACH NLRI. The AFI and SAFI fields MUST be set as follows:

   - AFI: 2; for IPv6

   - SAFI: 128; for MPLS labeled VPN-IPv6

   The labeled VPN-IPv6 MP_REACH_NLRI itself is encoded as specified in
   [MPLS-BGP]. In the context of this extension, the prefix belongs to
   the VPN-IPv6 Address Family and thus consists of an 8-byte Route
   Distinguisher followed by an IPv6 prefix as specified in section 2
   above.

3.2.1 BGP Next Hop encoding

3.2.1.1 BGP speakers with IPv6 connectivity

   A BGP speaker SHALL advertise to its peers a Next Hop Network Address
   field containing a VPN-IPv6 address:

      - whose RD is set to zero, and

      - whose 16-byte IPv6 address is set to the global IPv6 address of
      the advertising PE.

   potentially followed by another VPN-IPv6 address:

      - whose RD is set to zero, and

      - whose 16-byte IPv6 address is set to the link-local IPv6 address
      of the advertising PE.

   The value of the Length ofth  Next Hop Network Address field in the



De Clercq, et al.        Expires December 2004                  [Page 5]


Internet Draft         draft-ietf-l3vpn-bgp-ipv6               June 2004


   MP_REACH_NLRI attribute shall be set to 24 when only a global address
   is present, or 48 if a link-local address is also included in the
   Next Hop field.

   The link-local address shall be included in the Next Hop field if and
   only if the advertising BGP speaker shares a common subnet with the
   peer the route is being advertised to [RFC2545].

   In all other cases, a BGP speaker shall advertise to its peer in the
   Next Hop Network Address field only the global IPv6 address of the
   next hop.

   As a consequence, a BGP speaker that advertises a route to an
   internal peer may modify the Network Address of Next Hop field by
   removing the link-local IPv6 address of the next hop.

   An example scenario where both the global IPv6 address and the link-
   local IPv6 address shall be included in the BGP Next Hop address
   field is where the IPv6 VPN service is supported over a multi-AS
   backbone with redistribution of labeled VPN-IPv6 routes between ASBRs
   (of different AS) sharing a common IPv6 subnet: in that case, both
   the global IPv6 address and the link-local IPv6 address shall be
   advertised by the ASBRs.


3.2.1.2 BGP Speakers with IPv4 connectivity

   A BGP speaker SHALL advertise to its peer a Next Hop Network Address
   field containing a VPN-IPv6 address:

      - whose RD is set to zero, and

      - whose 16-byte IPv6 address is encoded as an IPv4-mapped IPv6
      address [V6ADDR] containing the IPv4 address of the advertising
      PE. This IPv4 address must be routable in the Service Provider's
      backbone.

3.3. Route Target

   The use of route target is specified in [2547bis] and applies to IPv6
   VPNs. Encoding of the extended community attribute is defined in
   [BGP-EXTCOM].

3.4 BGP Capability Negotiation

   In order for two PEs to exchange labelled IPv6 VPN NLRIs, they MUST
   use BGP Capabilities Negotiation to ensure that they both are capable
   of properly processing such NLRIs.  This is done as specified in



De Clercq, et al.        Expires December 2004                  [Page 6]


Internet Draft         draft-ietf-l3vpn-bgp-ipv6               June 2004


   [BGP-MP] and [BGP-CAP], by using capability code 1 (multiprotocol
   BGP), with AFI and SAFI values as specified above in section 3.2.

4. Determination of Tunnel Type

   As mentioned earlier, this document allows support of IPv6 VPN
   service using various tunneling techniques in the core.

   The tunneling type to use in the core for IPv6 VPN MAY be determined
   via configuration of PEs. Alternatively a mechanism to dynamically
   determine the tunneling type to use MAY be deployed (see for example
   [ENCAP-SIG] or [TUN-SAFI] and [SSA]).

5. Encapsulation

   The ingress PE Router MUST tunnel IPv6 VPN data over the backbone
   towards the Egress PE router identified as the BGP Next Hop for the
   corresponding IPv6 VPN prefix.

   When the 16-byte IPv6 address contained in the BGP Next Hop field is
   encoded as an IPv4-mapped IPv6 address (see section 3.2.1.2), the
   ingress PE MUST use IPv4 tunnelling.

   When the 16-byte IPv6 address contained in the BGP Next Hop field is
   not encoded as an IPv4-mapped address (see section 3.2.1.2), the
   ingress PE MUST use IPv6 tunnelling.

   Regardless of whether it is IPv4 or IPv6 tunnelling, the tunnelling
   type is determined as discussed above in section 4.

   When a PE receives a packet from a CE, it looks up the packet's IPv6
   destination address in the VRF corresponding to that CE. This enables
   it to find a VPN-IPv6 route. The VPN-IPv6 route will have an
   associated MPLS label and an associated BGP Next Hop. First, this
   MPLS label is pushed on the packet. Then, this labelled packet is
   encapsulated into the tunnel for transport to the egress PE
   identified as the BGP Next Hop. Details of this encapsulation depend
   on the actual tunnelling technique as follows:

   As with MPLS/BGP for IPv4 VPNs [2547-GRE/IP], when tunnelling is done
   using IPv4 tunnels or IPv6 tunnels (resp. IPv4 GRE tunnels or IPv6
   GRE tunnels), encapsulation of the labelled IPv6 VPN packet results
   in an MPLS-in-IP (resp. MPLS-in-GRE) encapsulated packet as specified
   in [MPLS-in-IP/GRE].

   As with MPLS/BGP for IPv4 VPNs, when tunnelling is done using an
   IPsec secured tunnel [2547-IPsec], encapsulation of the labelled IP6
   VPN packet results in an MPLS-in-IP or MPLS-in-GRE encapsulated



De Clercq, et al.        Expires December 2004                  [Page 7]


Internet Draft         draft-ietf-l3vpn-bgp-ipv6               June 2004


   packet [MPLS-in-IP/GRE]. The IPsec Transport Mode is used to secure
   this IPv4 or GRE tunnel from ingress PE to egress PE.

   When tunnelling is done using IPv4 tunnels or IPv4 GRE tunnels
   (whether IPsec secured or not), the Ingress PE Router MUST use the
   IPv4 address which is encoded in the IPv4-mapped IPv6 address field
   of the BGP next hop field, as the destination address of the
   prepended IPv4 tunnelling header. It uses one of its IPv4 addresses
   as the source address of the prepended IPv4 tunneling header.

   When tunnelling is done using IPv6 tunnels or IPv6 GRE tunnels
   tunnels (whether IPsec secured or not), the Ingress PE Router MUST
   use the IPv6 address which is contained in the IPv6 address field of
   the BGP next hop field, as the destination address of the prepended
   IPv6 tunnelling header. It uses one of its IPv6 addresses as the
   source address of the prepended IPv6 tunneling header.

   When tunneling is done using MPLS LSPs, the LSPs can be established
   using any label distribution technique (LDP[LDP], RSVP-TE [RSVP-TE],
   ...). Nevertheless, to ensure interoperability among systems that
   implement this VPN architecture using MPLS LSPs as the tunneling
   technology, all such systems MUST support LDP [LDP].

   When tunnelling is done using MPLS LSPs, the ingress PE Router
   directly pushes the LSP tunnel label on the label stack of the
   labelled IPv6 VPN packet (i.e. without prepending any IPv4 or IPv6
   header). This pushed label corresponds to the LSP starting on the
   ingress PE Router and ending on the egress PE Router. The BGP Next
   Hop field is used to identify the egress PE router and as such the
   label to be pushed on the stack. In case the IPv6 address in the BGP
   Next Hop field is a IPv4-mapped IPv6 address, the embedded IPv4
   address will determine the tunnel label to push on the label stack.
   In any other case, the IPv6 address in the BGP Next Hop field will
   determine the tunnel label to push on the label stack.


   The bottom label is the label bound to the IPv6 VPN Prefix via BGP.

6. Address Scope

   Since Link-local scope addresses are defined as uniquely identifying
   interfaces within (i.e., attached to) a single link only (see
   [SCOPE-ARCH]), those may be used on the PE-CE link but they are not
   supported for reachability across IPv6 VPN Sites and are never
   advertised via MP-BGP to remote PEs.

   Global scope addresses are defined as uniquely identifying interfaces
   anywhere in the Internet. Global addresses are expected to be



De Clercq, et al.        Expires December 2004                  [Page 8]


Internet Draft         draft-ietf-l3vpn-bgp-ipv6               June 2004


   commonly used within and across IPv6 VPN Sites. They are obviously
   supported by this IPv6 VPN solution for reachability across IPv6 VPN
   Sites and advertised via MP-BGP to remote PEs and processed without
   any specific considerations to their Global scope.

7. Multicast

   Multicast operations is outside the scope of this document.

8. Inter-Provider Backbones

   The same mechanisms described in [2547bis] can be used and have the
   same scalability properties.

9. Accessing the Internet from a VPN

   The methods proposed by [2547bis] to access the global Internet can
   be used in the context of IPv6 VPNs and the global IPv6 Internet.
   Note however that if the IPv6 packets destined for the global IPv6
   Internet need to traverse the SP backbone, and if this is an IPv4
   only backbone, they must be tunnelled through that IPv4 backbone.

10. Management VPN

   Where the IPv6 VPN service is supported over an IPv4 backbone, and
   where the Service Provider manages the CE, the Service Provider may
   elect to use IPv4 for communication between the management tool and
   the CE for such management purposes. In that case, regardless of
   whether a customer IPv4 site is actually connected to the CE or not,
   the CE is effectively part of an IPv4 VPN (i.e. it is attached to an
   IPv4 VRF) in addition to belonging to an IPv6 VPN. Considerations
   presented in [2547bis] on how to ensure that the management tool can
   communicate with such managed CEs from multiple VPNs without allowing
   undesired reachability across CEs of different VPNs, are applicable
   to the IPv4 VRF to which the CE attaches.

   Where the IPv6 VPN service is supported over an IPv4 backbone, and
   where the Service Provider manages the CE, the Service Provider may
   elect to use IPv6 for communication between the management tool and
   the CE for such management purposes. Considerations presented in
   [2547bis] on how to ensure that the management tool can communicate
   with such managed CEs from multiple VPNs without allowing undesired
   reachability across CEs of different VPNs, are then applicable to the
   IPv6 VRF to which the CE attaches.

11. Security

   The same security concerns as in [2547bis] are applicable.



De Clercq, et al.        Expires December 2004                  [Page 9]


Internet Draft         draft-ietf-l3vpn-bgp-ipv6               June 2004


12. Quality of Service

   [2547bis] is applicable.

13. Acknowledgements

   We would like to thank Gerard Gastaud who largely contributed to this
   document.

   In Memoriam:

   The authors would like to acknowledge the valuable contribution to
   this document from Tri T. Nguyen, who passed away in April 2002 after
   a sudden illness.


14. Normative References

   [2547bis] Rosen et al., "BGP/MPLS VPNs", draft-ietf-l3vpn-rfc2547bis,
   work in progress

   [BGP-EXTCOMM] Ramachandra, Tappan, Rekhter, "BGP Extended Communities
   Attribute", work in progress

   [BGP-MP] Bates, Chandra, Katz, and Rekhter, "Multiprotocol Extensions
   for BGP4", June 2000, RFC2858

   [IPv6] Deering, S., and R. Hinden, "Internet Protocol, Version 6
   (IPv6) Specification", RFC2460.

   [MPLS-ARCH] Rosen, Viswanathan, and Callon, "Multiprotocol Label
   Switching Architecture", RFC3031

   [MPLS-BGP] Rekhter and Rosen, "Carrying Label Information in BGP4",
   RFC3107

   [MPLS-ENCAPS] Rosen, Rekhter, Tappan, Farinacci, Fedorkow, Li, and
   Conta, "MPLS Label Stack Encoding", RFC3032

   [BGP-CAP] Chandra, R., Scudder, J., "Capabilities Advertisement with
   BGP-4", November 2002, RFC3392

   [MPLS-LDP] Andersson, Doolan, Feldman, Fredette, Thomas, "LDP
   Specification", RFC3036

   [RFC2545] Marques, P., Dupont, F., "Use of BGP-4 Multiprotocol
   Extensions for IPv6 Inter-Domain Routing", March 1999, RFC2545




De Clercq, et al.        Expires December 2004                 [Page 10]


Internet Draft         draft-ietf-l3vpn-bgp-ipv6               June 2004


15. Informative References

   [V6ADDR] Deering, S., and Hinden, R., "IP Version 6 Addressing
   Architecture", April 2003, RFC3513

   [2547-GRE/IP] Rekhter and Rosen, "Use of PE-PE GRE or IP in RFC2547
   VPNs", draft-ietf-l3vpn-gre-ip-2547, work in progress

   [2547-IPsec] Rosen, De Clercq, Paridaens, T'Joens, Sargor, "Use of
   PE-PE IPsec in RFC2547 VPNs", draft-ietf-l3vpn-ipsec-2547, work in
   progress

   [TRANS] R. Gilligan, E. Nordmark, "Transition Mechanisms for IPv6
   Hosts and Routers", RFC2893.

   [SCOPE-ARCH] Deering, S., et al., "IPv6 Scoped Address Architecture",
   draft-ietf-ipv6-scoping-arch, work in progress

   [RSVP-TE] Awduche, D., et al., "RSVP-TE: Extensions to RSVP for LSP
   Tunnels", December 2001, RFC3209

   [MPLS-in-IP/GRE] Worster, T., et al., "Encapsulating MPLS in IP or
   GRE", draft-ietf-mpls-in-ip-or-gre, work in progress

   [ENCAP-SIG] Aggarwal, R., et al., "Signaling Tunnel
   Encapsulation/Deencapsulation capabilities", draft-raggarwa-ppvpn-
   tunnel-encap-sig, work in progress

   [TUN-SAFI] Nalawade, et al., "IPv4 Tunnel SAFI", draft-nalawade-
   kapoor-tunnel-safi-00, work in progress

   [SSA] Kapoor, et al., "BGP-4 SAFI-specific Attribute", draft-kapoor-
   nalawade-idr-bgp-ssa, work in progress

16. Authors' Addresses

   Jeremy De Clercq
   Alcatel
   Fr. Wellesplein 1, 2018 Antwerpen, Belgium
   E-mail: jeremy.de_clercq@alcatel.be

   Dirk Ooms
   Alcatel
   Fr. Wellesplein 1, 2018 Antwerpen, Belgium
   E-mail: dirk.ooms@alcatel.be

   Marco Carugi
   Nortel Networks S.A.



De Clercq, et al.        Expires December 2004                 [Page 11]


Internet Draft         draft-ietf-l3vpn-bgp-ipv6               June 2004


   Parc d'activites de Magny-Les Jeunes Bois CHATEAUFORT
   78928 YVELINES Cedex 9 - France
   E-mail: marco.carugi@nortelnetworks.com

   Francois Le Faucheur
   Cisco Systems, Inc.
   Village d'Entreprise Green Side - Batiment T3
   400, Avenue de Roumanille
   06410 Biot-Sophia Antipolis
   France
   E-mail: flefauch@cisco.com








































De Clercq, et al.        Expires December 2004                 [Page 12]


Internet Draft         draft-ietf-l3vpn-bgp-ipv6               June 2004





















































De Clercq, et al.        Expires December 2004                 [Page 13]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/