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

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

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

                                                           November 2002
                                                       Expires May, 2003

                  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
   Directorieson 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



De Clercq, et al.           Expires May 2003                    [Page 1]


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


   srvice over both an IPv4 and an IPv6 backbone, and using various
   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 a per-packet header lookup may determine 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 (as may be required when
   site-local addresses are used by the end customers). 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
   MPLS/BGP 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. Similar BGP-based negotiation and
   discovery [TUNNEL-ATTR] mechanisms are proposed to dynamically
   determine which tunnelling technique is to be used in a given
   network.

   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



De Clercq, et al.           Expires May 2003                    [Page 2]


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


   benefits:

      o from both the Service Provider perspective and the customer
      perspective, the VPN service that can be supported for IPv6 sites
      is identical to the one that can be supported 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 suppported over
      an IPv4 core, the same single set of MP-BGP peering relationships
      and the same single PE-PE tunnel mesh can be used for both;

      o independence of whether the core runs IPv4 or IPv6. So that the
      IPv6 VPN service suppported 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.




De Clercq, et al.           Expires May 2003                    [Page 3]


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


   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], 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 can have an IBGP connection to a route reflector.
   Similarly, for IPv6 VPN route distribution, PEs can use an iBGP



De Clercq, et al.           Expires May 2003                    [Page 4]


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


   connection between them or use iBGP connections to a route reflector.

   The PE routers:

   (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 corresponing 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

   MP-BGP has the constraint that the "BGP Next Hop" field in the
   MP_REACH_NLRI attribute needs to be of the same address family as the
   NLRI encoded in the MP_REACH_NLRI attribute. In this document, this
   means that the BGP Next Hop field must belong to the VPN-IPv6 Address
   Family.

3.2.1.1 IPv6 backbone

   When an IPv6 VPN service is offered as per this document over an IPv6
   backbone, the BGP Next Hop MUST contain a VPN-IPV6 address:

      - whose RD is set to zero, and

      - whose 16-byte IPv6 address is set to the IPv6 address of the



De Clercq, et al.           Expires May 2003                    [Page 5]


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


      advertising PE. This IPv6 address must be routable in the Service
      Provider's backbone.

   This is the same approach as used in [2547bis] where the PE encodes
   its IPv4 address in a VPN-IPv4 Address Family format.

3.2.1.2 IPv4 backbone

   When an IPv6 VPN service is offered as per this document over an IPv4
   backbone, the BGP Next Hop MUST contain 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 NLRI.  This is done as specified in
   [BGP-MP] and [BGP-CAP], by using capability code 1 (multiprotocol
   BGP), with AFI and SAFI fields according to above.

4. Automatic 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.

   There is work underway [TUNNEL-ATTR] on a new BGP attribute (Tunnel
   Type) and associated procedures so that BGP speakers can
   automatically determine which tunneling type to use for a given
   Prefix and a given BGP next hop.

   This document defines MPLS as the default tunneling type. This means
   that when no Tunnel Type attribute is included in a BGP advertisement
   for a labeled VPN-IPv6 Prefix and when the tunnel type to be used is



De Clercq, et al.           Expires May 2003                    [Page 6]


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


   not specified by the PE configuration, MPLS LSPs MUST be used to
   tunnel IPv6 VPN packets to the BGP Next Hop over the Service Provider
   backbone.

   Where another tunneling technique than MPLS is desired for tunneling
   traffic to an IPv6 VPN prefix between PEs, the Tunnel Type attribute
   MAY be used in BGP advertisement of a labeled VPN-IPv6 Prefix, as
   specified in [TUNNEL-ATTR].

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 will 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 will 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. 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 IP-in-IP IPv4 tunnels or IP-in-IP 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] (resp. [MPLS-in-GRE]).

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



De Clercq, et al.           Expires May 2003                    [Page 7]


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


   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 IP-in-IP IPv6 tunnels or IPv6 GRE
   tunnels tunnels (whether IPsec secured or not), the Ingress PE Router
   MUST simply 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). The topmost label imposed 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 topmost label to be pushed on the stack. The bottom label is the
   label bound to the IPv6 VPN Prefix via BGP.

6. Address Scope

   The IPv6 address architecture [ADDRARCH] defines the concept of scope
   for IPv6 addresses and defines the following unicast address scopes:

      - link-local,

      - site-local,

      - global

   Since Link-local scope addresses are defined as uniquely identifying
   interfaces within (i.e., attached to) a single link only, 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 May 2003                    [Page 8]


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


   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.

   Site-local scope addresses are defined as uniquely identifying
   interfaces within a single site only. Quoting from [SCOPE-ARCH], ''a
   "site" is, by intent, not rigorously defined,...''. However, it is
   anticipated by the authors of this document that, when used in an
   IPv6 VPN network, the concept of Site Local scope will typically be
   used in either of the following scenarios:

      - all IPv6 VPN sites of a given VPN are within the same Site-Local
      zone. Thus, Site-Local addresses may be used for reachability
      across all IPv6 VPN sites and corresponding Site-Local routes may
      be advertised via MP-BGP to remote PEs and installed in VRFs. In
      this scenario, Site Local routes MUST effectively be treated by
      the PE in exactly the same way as Global routes.

      - Each IPv6 VPN site of a given VPN is in a different Site-Local
      zone. Site-Local addresses can not be used for reachability across
      IPv6 VPN sites and corresponding Site-Local routes should not be
      advertised via MP-BGP to remote PEs. This IPv6 VPN solution
      proposes that this scenario be supported simply by effectively
      hiding the Site Local routes to the PE. This can be seen as
      placing the Site-Local zone boundary on the CE (as opposed to on
      the PE) and thus locating the PE outside the Site-Local zone.
      Then, when dynamic IPv6 routing is used between the PE and CE (v6
      IGP, MP-BGP), the CE will not distribute Site-Local routes to the
      PE. Thus, no special handling of Site Local routes is required on
      the PE since there are none.

   The following is an example of the first scenario:

     I   VPN   I VPN   I  Site-Local  I Site-Local addresses within  I
     I         I Site  I    Zone      I                              I
     =================================================================
     I Yellow  I   1   I     1        I       FEC0::CAFE1/64         I
     I Yellow  I   2   I     1        I       FEC0::CAFE2/64         I
     I Yellow  I   3   I     1        I       FEC0::CAFE3/64         I

   The following is an example of the second scenario:









De Clercq, et al.           Expires May 2003                    [Page 9]


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


     I   VPN   I VPN   I  Site-Local  I Site-Local addresses within  I
     I         I Site  I     Zone     I                              I
     =================================================================
     I  Green  I   1   I    1         I       FEC0::BEEF1/64         I
     I  Green  I   2   I    2         I       FEC0::BEEF2/64         I
     I  Green  I   3   I    3         I       FEC0::BEEF3/64         I

   Note that these two scenarios can be supported by the IPv6 VPN
   solution without any additional PE mechanism specific to the concept
   of Site-Local scope, since in the first scenario Site-Local routes
   are treated by the PEs in exactly the same way as Global routes, and
   in the second scenario Site Local routes are hidden to the PEs.

   Additional scenarios for the use of Site-Local scope in the context
   of IPv6 VPNs are conceivable. For example, a scenario could involve a
   given VPN which comprises a first set of VPN Sites which are within
   the same Site-Local zone and a second set of VPN Sites which are
   within another Site-Local zone. In that case, Site-Local addresses
   may be used to support reachability across VPN sites of the same
   Site-Local zone, but not across VPN Sites of different Site-Local
   zones. Such scenarios would require that Global routes be advertised
   and installed in the VRFs of all the VPN sites but that Site-Local
   routes only be installed in the VRFs of a subset of the VPN sites.
   Thus, such scenarios may require additional PE mechanisms specific to
   the concept of Site Local scope (such as perhaps automatically using
   a different Route Targets for Site Local routes and Global routes).
   Because it is unclear at this point in time that there is a practical
   requirement for handling such scenarios, support for these scenarios,
   and corresponding mechanisms, are left for further study.

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's backbone, and if this is an IPv4
   only backbone, they must be tunnelled through that IPv4 backbone.

10. Management VPN



De Clercq, et al.           Expires May 2003                   [Page 10]


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


   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.

12. Quality of Service

   [2547bis] is applicable.

13. Acknowledgements

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

   [2547bis] Rosen et al., "BGP/MPLS VPNs", draft-ietf-ppvpn-
   rfc2547bis-03.txt, October 2002, work in progress

   [2547-GRE/IP] Rekhter and Rosen, "Use of PE-PE GRE or IP in RFC2547
   VPNs", draft-ietf-ppvpn-gre-ip-2547-01.txt, February 2002, work in
   progress

   [2547-IPsec] Rosen, De Clercq, Paridaens, T'Joens, Sargor, "Use of



De Clercq, et al.           Expires May 2003                   [Page 11]


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


   PE-PE IPsec in RFC2547 VPNs", draft-ietf-ppvpn-ipsec-2547-01.txt,
   August 2002, work in progress

   [BGP-EXTCOMM] Ramachandra, Tappan, Rekhter, "BGP Extended Communities
   Attribute", draft-ietf-idr-bgp-ext-communities-05.txt, work in
   progress

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

   [BGP-CAP] Chandra, R., Scudder, J., "Capabilities Advertisement with
   BGP-4", draft-ietf-idr-rfc2842bis-02.txt, April 2002, work in
   progress

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

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

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

   [TUNNEL-ATTR] Cristallo, G., De Clercq, J., "BGP Tunnel Attribute",
   draft-cristallo-bgp-tunnel-attr-00.txt, June 2002, work in progress

   [LDP] Andersson, L., et al., "LDP Specification", January 2001,
   RFC3036

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




De Clercq, et al.           Expires May 2003                   [Page 12]


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


   [MPLS-in-IP] Doolan, P., et al., "MPLS Label Stack Encapsulation in
   IP", draft-worster-mpls-in-ip-03.txt, work in progress

   [MPLS-in-GRE] Rekhter, Y., Tappan, D., Rosen, E., "MPLS Label Stack
   Encapsulation in GRE", draft-rekhter-mpls-over-gre-01.txt, work in
   progress

11. Authors' Addresses

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

   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

   Marco Carugi
   Nortel Networks S.A.
   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 May 2003                   [Page 13]


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





















































De Clercq, et al.           Expires May 2003                   [Page 14]


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