One document matched: draft-nguyen-bgp-ipv6-vpn-00.txt
INTERNET DRAFT Tri T. Nguyen
<draft-nguyen-bgp-ipv6-vpn-00.txt> Gerard Gastaud
Dirk Ooms
Jeremy De Clercq
Alcatel
October 2000
Expires April, 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 codings
for the Router Distinguisher to support an IPv6 VPN address family.
It defines a coding for the SAFI-field in the case of labeled VPN-
IPv6 routes.
Nguyen, et al. Expires April 2001 [Page 1]
Internet Draft draft-nguyen-bgp-ipv6-vpn October 2000
This document assumes that the reader is familiar with draft-rosen-
rfc2547bis-02. 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 the MPLS core network. The rest of the backbone is
assumed to be IPv4 only. In principle it could be IPv6, but this is
not in the scope considered.
BGP is used to cause IPv6 VPN site routes 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 VPN [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 defining a new address family, the VPN-IPv6 Address
Family, in a fashion similar to the VPN-Ipv4 address family
definition of [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", similarly to the VPN-IPv4 address 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 April 2001 [Page 2]
Internet Draft draft-nguyen-bgp-ipv6-vpn October 2000
"Route Distinguisher(RD)" and ending with a 16-byte IPv6 address. If
two VPNs use the same IPv6 address prefix, the PEs translate these
into unique VPN-IPv6 address prefixes. 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 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 v4 and v6, the same RD can be used for 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
3.1. Route Distribution Among PEs by BGP
Nguyen, et al. Expires April 2001 [Page 3]
Internet Draft draft-nguyen-bgp-ipv6-vpn October 2000
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 has 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 uses 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. (Essentially, PE
routers distribute not VPN routes, but Labeled VPN routes [MPLS-
BGP]). When the PE processes a received packet that has this label
at the top of the stack, the PE will pop the stack, and process the
packet appropriately.
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 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.
3.2. Route Target
The use of route target is specified in [2547bis]. Coding of the
extended community attribute is defined in [BGP-EXTCOM]. The coding
recommended for IPv6 VPN is:
Type : higher octet = x'00, administrator field = 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
- SAFI: 129; for MPLS labeled VPN-IPv6
Nguyen, et al. Expires April 2001 [Page 4]
Internet Draft draft-nguyen-bgp-ipv6-vpn October 2000
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 ways proposed by [2547bis] apply with the following difference:
PE needs to tunnel IPv6 packets over the SP backbone when [2547bis]
forwards them natively.
7. Security
[2547bis] is applicable with labeled VPN IPv6 routes.
8. Quality of Service
[2547bis] is applicable.
9. Intellectual Property Considerations
Alcatel may seek patent or other intellectual property protection for
some of all of the technologies disclosed in this document. If any
standards arising from this document are or become protected by one
or more patents assigned to Alcatel, Alcatel intends to disclose
those patents and license them on reasonable and non-discriminatory
terms.
10. 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
Nguyen, et al. Expires April 2001 [Page 5]
Internet Draft draft-nguyen-bgp-ipv6-vpn October 2000
[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
[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
11. 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 April 2001 [Page 6]
| PAFTECH AB 2003-2026 | 2026-04-24 02:01:51 |