INTERNET DRAFT Jeremy De Clercq 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]