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

Versions: 00 01 02 03

INTERNET DRAFT                                             Tri T. Nguyen
<draft-ietf-ppvpn-bgp-ipv6-vpn-01.txt>                    Gerard Gastaud
                                                               Dirk Ooms
                                                        Jeremy De Clercq
                                                                 Alcatel
                                                            Marco Carugi
                                                      France Telecom R&D

                                                           November 2001
                                                       Expires May, 2002

    BGP-MPLS VPN extension for IPv6 VPN over an IPv4 infrastructure

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.''

     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/1id-abstracts.html

     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html

   Distribution of this memo is unlimited.

Abstract

   This document describes a method by which a Service Provider may  use
   an MPLS enabled IPv4 backbone to provide Virtual Private Networks for
   its IPv6 customers. This proposal makes use of the  method  to  build
   network  based  VPNs  described  in the Internet draft "BGP/MPLS VPN"
   [2547bis]. In BGP/MPLS VPN, MPLS is used to forward packets over  the
   backbone, and "Multiprotocol BGP" is used for distributing VPN routes
   over the service provider backbone. This document defines an IPv6 VPN
   address  family  and  describes  the  route distribution and the MPLS
   tunnel selection.




Nguyen, et al.              Expires May 2002                    [Page 1]


Internet Draft       draft-ietf-ppvpn-bgp-ipv6-vpn         November 2001


   This document assumes that the reader  is  familiar  with  [2547bis].
   Unless explicitly documented herein, [2547bis] applies.


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 interface or sub-interface
   to the SP backbone via a Provider Edge device (PE). A site  belonging
   to  an IPv6 VPN may have access to the 6Internet, but this is outside
   the scope of this document.

   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 a per-packet header lookup may determine the version.

   The PE being dual stack has full IPv4  capabilities,  must   maintain
   IPv6  VRFs  for  its  IPv6 sites and must be able to encapsulate IPv6
   datagrams in MPLS frames to be sent into the MPLS core  network.  The
   other  backbone  Network  Elements  are  assumed  to be IPv4 only. In
   principle the backbone network could be  IPv6-capable,  but  possible
   implications  of  this  feature  are  not  within  the  scope of this
   document.

   BGP and its extensions are used to cause routes from IPv6  VPN  sites
   to be distributed over the backbone to each other PE router connected
   to a site of the same 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  (site-local  addresses).
   This  requires  the  definition of a new address family, the VPN-IPv6
   Address Family, in a fashion similar to the VPN-IPv4  address  family
   definition given by [2547bis].

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 in [2547bis].

2.1 The VPN-IPv6 Address Family




Nguyen, et al.              Expires May 2002                    [Page 2]


Internet Draft       draft-ietf-ppvpn-bgp-ipv6-vpn         November 2001


   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 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
   against a VPN-IPv6 route, only the IPv6 part is actually matched.

   When a site is IPv4- and IPv6-capable, the same RD can  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], two 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



Nguyen, et al.              Expires May 2002                    [Page 3]


Internet Draft       draft-ietf-ppvpn-bgp-ipv6-vpn         November 2001


   subfields:
      * Administrator subfield: 4  bytes,  it  contains  a  global  IPv4
      address

      * Assigned Number subfield: 2 bytes

3. VPN-IPv6 route distribution

3.1. Route Distribution Among PEs by BGP

   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 can have
   an  IBGP  connection  to  a route reflector. For an IPv6 VPN, this is
   done as described in [2547bis].

   These considered PE  routers  are  Dual  Stack  MP-BGP-speaking  edge
   routers  (DS-BGP  routers) that are located at the border of the IPv4
   backbone. A DS-BGP router has at least one IPv4 address and one  IPv6
   address.  The  IPv4  address  must  be  routable in the IPv4 backbone
   network.

   The DS-BGP routers:

   (i) exchange, via MP-BGP [MP-BGP], IPv6 reachability information over
   the IPv4 backbone with their BGP-peers.

   (ii) announce themselves as the BGP Next Hop.

   MP-BGP has the constraint that the "BGP Next Hop" needs to be of  the
   same address family as the distributed NLRI. The NLRI consists of VPN
   IPv6 addresses, while we would like the BGP Next Hop to be a routable
   (in  the  SP's core) IPv4 address. For that reason, the DS-BGP router
   will construct an  IPv6  address  that  contains  its  routable  IPv4
   address.  The  format of this IPv6 address containing an IPv4 address
   is that of a IPv4-mapped IPv6 address [V6ADDR][BGP-TUNNEL].

   The DS-BGP router will use this IPv4-mapped IPv6  address,  prepended
   with  a  RD  of  0  as  the BGP Next Hop when it distributes IPv6 VPN
   addresses with BGP.

   The DS-BGP router also assigns and distributes MPLS labels  with  the
   IPv6  VPN  routes.  (Essentially,  PE  routers  do not distribute VPN
   routes, but Labeled VPN routes [MPLS-BGP]).  When the PE processes  a
   received  MPLS  frame that has this particular label, the PE will pop
   the  stack,  and  process  the  packet  appropriately  (i.e.  in  the
   corresponding VPN context).




Nguyen, et al.              Expires May 2002                    [Page 4]


Internet Draft       draft-ietf-ppvpn-bgp-ipv6-vpn         November 2001


   Note that the use of BGP-distributed MPLS labels is only possible  if
   there  is  a  label switched path between the PE router that installs
   the BGP-distributed route and the PE router which is the BGP next hop
   of that route.

   Encoding the "BGP next hop" as a routable IPv4 address  encoded  into
   an  IPv4-mapped  IPv6  address  allows  the  remote DS-BGP routers to
   automatically find the routable IPv4 address of  the  destination  PE
   and thus to select the correct MPLS tunnel.

   This requires only one IPv4 address (and a derived  IPv4-mapped  IPv6
   address)  per  DS-BGP  PE router. No extra routes will be injected in
   the SP's IPv4 core.

   An MPLS label-switched path can carry IPv4 and IPv6 packets. The  top
   LSP  terminates  at the PE and the bottom label directs the packet to
   the proper forwarding table or outgoing customer interface.

3.2. Route Target

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

4. How VPN IPv6 NLRI is carried in BGP

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

   - AFI: 2; for IPv6

   - SAFI: 129; for MPLS labeled VPN-IPv6

   In order for two BGP speakers to exchange labeled VPN NLRI, they must
   use BGP Capabilities Negotiation to ensure that they both are capable
   of properly processing such NLRI.   This  is  done  as  specified  in
   [BGP-MP],  by  using  capability code 1 (multiprotocol BGP), with AFI
   and SAFI fields according to above.

   The labeled VPN-IPv6 NLRI itself is encoded as  specified  in  [MPLS-
   BGP].  In the context of this extension, the prefix consists of an 8-
   byte RD followed by an IPv6 prefix.

5. Inter-Provider Backbones

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

6. Accessing the Internet from a VPN



Nguyen, et al.              Expires May 2002                    [Page 5]


Internet Draft       draft-ietf-ppvpn-bgp-ipv6-vpn         November 2001


   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's  IPv4  backbone, they must be
   tunnelled through the IPv4 backbone.

7. Security

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

8. Quality of Service

   [2547bis] is applicable.

9. References

   [2547bis]  Rosen   et   al.,   "BGP/MPLS   VPNs",   draft-ietf-ppvpn-
   rfc2547bis-00.txt, July 2001, work in progress

   [BGP-TUNNEL] De Clercq, J., et al., "Connecting IPv6  Islands  across
   IPv4  clouds with BGP", draft-ietf-ngtrans-bgp-tunnel-03.txt, work in
   progress

   [BGP-EXTCOMM] Ramachandra, Tappan, Rekhter, "BGP Extended Communities
   Attribute",   draft-ramachandra-bgp-ext-communities-09.txt,  December
   2001, work in progress

   [BGP-MP] Bates, Chandra, Katz, and Rekhter, "Multiprotocol Extensions
   for BGP4", February 1998, RFC2283

   [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

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

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




Nguyen, et al.              Expires May 2002                    [Page 6]


Internet Draft       draft-ietf-ppvpn-bgp-ipv6-vpn         November 2001


   [V6ADDR] Deering, S.,  and  Hinden,  R.,  "IP  Version  6  Addressing
   Architecture",    draft-ietf-ipngwg-addr-arch-v3-06.txt,    work   in
   progress

10. Authors' Addresses

   Tri T. Nguyen
   Alcatel
   Level 20 North Point Tower, 100 Miller Street,
   North Sydney NSW 2060, Australia
   E-mail: tri.t.nguyen@alcatel.com

   Gerard Gastaud
   Alcatel
   10 rue Latecoere, BP 57, 78141 Velizy Cedex, France
   E-mail: gerard.gastaud@alcatel.fr

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

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

   Marco Carugi
   France Telecom R&D
   Technopole Anticipa, 2 av. P. Marzin
   22307 Lannion cedex - France
   E-mail: marco.carugi@francetelecom.com



















Nguyen, et al.              Expires May 2002                    [Page 7]


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