One document matched: draft-nguyen-bgp-ipv6-vpn-01.txt
Differences from draft-nguyen-bgp-ipv6-vpn-00.txt
INTERNET DRAFT Tri T. Nguyen
<draft-nguyen-bgp-ipv6-vpn-01.txt> Gerard Gastaud
Dirk Ooms
Jeremy De Clercq
Alcatel
February 2001
Expires August, 2001
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/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
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
an MPLS enabled IPv4 backbone to provide VPNs for its IPv6 customers.
This proposal makes use of the method to build network based VPNs
described in the RFC2547-Bis Internet draft [2547Bis]. In BGP/MPLS
VPN, MPLS is used for forwarding packets over the backbone, and BGP
is used for distributing VPN routes over the service provider
backbone. This document proposes to use one of the defined encodings
for the Route Distinguisher to support an IPv6 VPN address family. It
defines an encoding for the SAFI-field in the case of labeled VPN-
IPv6 routes.
Nguyen, et al. Expires August 2001 [Page 1]
Internet Draft draft-nguyen-bgp-ipv6-vpn February 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 ISP backbone via a 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, but the logical interface on which
the packet arrives determines the version (without looking
necessarily inside a received packet).
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 this is not
within the scope of this document.
BGP is 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
A VPN-IPv6 address is a 24-byte quantity, beginning with an 8-byte
Nguyen, et al. Expires August 2001 [Page 2]
Internet Draft draft-nguyen-bgp-ipv6-vpn February 2001
"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 or 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. At the present time, [2547bis] defines 2 values of the
type field. Type 0 is recommended for use with IPv6.
- Type 0: The Value field consists of two subfields:
* Administrator subfield: 2 bytes, it contains an ASN
* Assigned Number subfield: 4 bytes
3. VPN-IPv6 route distribution
Nguyen, et al. Expires August 2001 [Page 3]
Internet Draft draft-nguyen-bgp-ipv6-vpn February 2001
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 IBGP connection between them. Alternatively, each can have an
IBGP connection to a route reflector. For an IPv6 VPN, this is done
as mandated by [2547bis].
A PE being dual stack has at least one IPv6 and one IPv4 address. It
may have more, and in particular it must have an IPv4-compatible IPv6
address (that address is based on its existing IPv4 address) as one
of its IPv6 addresses. When a PE router distributes a VPN route via
BGP, it must use its IPv4-compatible IPv6 address as the "BGP next
hop". This address is encoded as a VPN address with a RD of 0.
([BGP-MP] requires that the next hop address be in the same address
family as the NLRI.)
It also assigns and distributes an MPLS label with the IPv6 VPN
route. (Essentially, PE routers distribute not VPN routes, but
Labeled VPN routes [MPLS-BGP]). When the PE processes a received
MPLS frame that has this label at the top of the stack, the PE will
pop the stack, and process the packet appropriately (i.e. in the
corresponding VPN context).
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.
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]. The
encoding recommended for IPv6 VPN is:
Type : 0x0002, administrator field = 2-byte ASN, assigned number
field is 4 octets.
4. How VPN 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
Nguyen, et al. Expires August 2001 [Page 4]
Internet Draft draft-nguyen-bgp-ipv6-vpn February 2001
- 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], but where 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
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., draft-rosen-rfc2547bis-02.txt, July 2000
[BGP-MP] Bates, Chandra, Katz, and Rekhter, "Multiprotocol Extensions
for BGP4", February 1998, RFC 2283
[BGP-EXTCOMM] Ramachandra, Tappan, "BGP Extended Communities
Attribute", February 2000, work in progress
[BGP-ORF] Chen, Rekhter, "Cooperative Route Filtering Capability for
BGP-4", March 2000, work in progress
[BGP-RFSH] Chen, "Route Refresh Capability for BGP-4", March 2000,
work in progress
Nguyen, et al. Expires August 2001 [Page 5]
Internet Draft draft-nguyen-bgp-ipv6-vpn February 2001
[BGP-RR] Bates and Chandrasekaran, "BGP Route Reflection: An
alternative to full mesh IBGP", RFC 2796, April 2000
[IPSEC] Kent and Atkinson, "Security Architecture for the Internet
Protocol", November 1998, RFC 2401
[MPLS-ARCH] Rosen, Viswanathan, and Callon, "Multiprotocol Label
Switching Architecture", August 1999, work in progress
[MPLS-BGP] Rekhter and Rosen, "Carrying Label Information in BGP4",
January 2000, work in progress
[MPLS-LDP] Andersson, Doolan, Feldman, Fredette, Thomas, "LDP
Specification", October 1999, work in progress
[MPLS-ENCAPS] Rosen, Rekhter, Tappan, Farinacci, Fedorkow, Li, and
Conta, "MPLS Label Stack Encoding", October 1999, 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
Nguyen, et al. Expires August 2001 [Page 6]
| PAFTECH AB 2003-2026 | 2026-04-24 02:01:43 |