[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
A draft about VPN in IPv4/IPv6 Hybrid Network(new version)
Dear all,
Attached is a draft about VPN in IPv4/IPv6 Hybrid Network, I hope this
draft can be processed in the v6ops WG as soon as possible, discussions and
comments are appreciated.
BTW, I hope to discuss it at 60th IETF meeting, I would like to have a
chance to make presentation for it, Could you please arrange a time slot for
me? I think 10min slot will do.
Thanks in advance.
Defeng Li
Huawei Technologies
INTERNET DRAFT Defeng Li
<draft-defeng-l3vpn-ipv4-ipv6-hybrid-00.txt> Huawei Technologies
Expires December, 2004
June 2004
BGP-MPLS VPN extension for IPv4/IPv6 Hybrid Network
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been
disclosed, or will be disclosed, and any of which I become aware
will be disclosed, in accordance with RFC 3668.
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 and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than a "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
List of authors/editors
Defeng Li Huawei Technologies
Abstract
This document describes some methods which may be used by Service
Providers to provide Virtual Private Networks for some scenarios
where the Service Provider's network or Customer's network is
comprised of part of IPv4 network and part of IPv6 network.These
situations can't be avoided during the process of IPv4 transition to
IPv6, e.g. IPv6 backbone network for IPv4-IPv6 hybrid VPN sites,or
IPv4 backbone network for IPv4-IPv6 hybrid VPN sites,or IPv4-IPv6
hybrid backbone network for IPv4-IPv6 hybrid VPN sites.This proposal
continue to use the concepts described in the Internet draft
"BGP/MPLS VPN"[2547bis],such as RD,VRF,Route Target and some
mechanisms. In BGP/MPLS VPN, MPLS is used to forward packets over
Defeng Li Expires December 2004 [Page 1]
Internet Draft draft-defeng-l3vpn-ipv4-ipv6-hybrid-00 June 2004
the backbone, and "Multiprotocol BGP" is used for distributing VPN
routes over the service provider backbone.
This document makes the reference to the current RFC or Internet Draft
as to the IPv4 VPN address family and IPv6 VPN address family,In some
hybrid scenarios,IPv4/IPv6 dual VPN address family should be supported
in backbone, accordingly, some VPN sites should support IPv4/IPv6 dual
route table.
1. Introduction
This document assumes that the reader is familiar with [2547bis].
Unless explicitly documented herein, [2547bis] applies.
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 hybrid VPN, when one of the following
conditions is meeted:
(a) Some sites 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).
(b) Backbone network for VPN consists of IPv6 capable network and IPv4
capable network.
A site may be both IPv4-capable and IPv6-capable. The logical interface
on which packets arrive at the PE may determine the version, or
alternatively a per-packet header lookup on the same interface may
determine the version. In this document, for those sites having VPN
relationship with other IPv4 sites and IPv6 sites in the same VPN,
and those sites connected to the different IP version part of backbone
(e.g. IPv4 sites connected to IPv6 part of backbone or IPv6 sites
connected to IPv4 part of backbone),CE MUST support both IPv4 and IPv6.
When PE connects to both IPv4 sites and IPv6 sites(maybe these sites
belong to different VPN), or PE connects to CE which must be
dual-stacked according to the rules above mentioned, then PE should
be dual-stacked too.
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.
BGP and its extensions are used to cause routes from IPv4 or IPv6 VPN
sites to be distributed over the backbone to each other PE router
connected to a site of the same IPv6 hybrid VPN.
As it is done for IPv4 VPNs [2547bis], we allow each IPv6 hybrid VPN
to have IPv4/IPv6 hybrid address space, i.e. for a VPN with both IPv4
VPN sites and IPv6 VPN sites, both VPN-IPv4 and VPN-IPv6 address
family are needed, VPN-IPv4 address family refers to [2547bis],
Defeng Li Expires December 2004 [Page 2]
Internet Draft draft-defeng-l3vpn-ipv4-ipv6-hybrid-00 June 2004
VPN-IPv6 address family is a 24-byte quantity, composed of an 8-byte
"Route Distinguisher" (RD) and a 16-byte IPv6 address. MP-BGP allows
BGP to carry routes from multiple "address families", so IPv4/IPv6
hybrid address space enables the VPN routes of IPv4 sites and IPv6
sites of the same VPN to be distributed across the backbone.
This document first addresses BGP/MPLS VPN mechanism under the
situation where VPN sites consist of IPv4 sites and IPv6 sites, and
the backbone network consists of one or more IPv4 autonomous system
and at least an IPv6 autonomous system, then propose some mechanism
for the simple situations.
2. Hybrid Backbone and Hybrid VPN sites
In Hybrid Backbone and Hybrid sites situation, VPN backbone network
consists of one or more IPv4 autonomous system and at least an IPv6
autonomous system, and VPN sites consist of IPv4 sites and IPv6
sites.
Note: This document proposes two methods to address this hybrid VPN
scenario, and are detailed in section 2.1 and section 2.2 respectively.
2.1. Method 1
In this method, PEs and ASBR in every AS establish MP-IBGP to
distribute the VPN routes between the sites belong to the same AS,
and ASBRs of the adjacency AS establish MP-EBGP to distribute VPN
routes between the sites belong to the different AS.For the
conveniency of discussion, we first consider the situation where
backbone network consists only two autonomous system(from
Section 2.1.1. to Section 2.1.5.), one is IPv4 AS(AS1) and the
other is IPv6 AS2, they connected to each other through some ASBRs,
for simplicity, considering the situation where only one ASBR for
each AS, ASBR1 for AS1,ASBR2 for AS2, and in some of VPNs accessed
to the backbone, some sites are IPv6 sites, others are IPv4 sites.
In the following sections, several aspects such as address family,
routing distribution, label assignment, data forwarding, VPN
topology implementation. In Section 2.1.6., we will discuss how to
extend the mechanism to the situation where more than two AS(at
least one of them is IPv6 AS).
2.1.1. Address Family
In this method, we only consider Unicast communication between VPN
sites, and Unicast address(IPv4 or IPv6) should be used. Considering
there are still some IPv4 Sites in the VPN and the scarcity of IPv4
address, private IPv4 addresses(defined in RFC 1918) are allowed to
be used IN vpn sites, and if two VPNs have no sites in common, they
may have overlapping address spaces, this aspect is the same as
[RFC 2547bis]. For IPv6 sites, the global unicast address should be
used, for the huge IPv6 address space, all the addresses are public
addresses.
Defeng Li Expires December 2004 [Page 3]
Internet Draft draft-defeng-l3vpn-ipv4-ipv6-hybrid-00 June 2004
Communications between IPv4 sites use IPv4 address, accordingly, AFI
field in MP-BGP can be valued as 1, which is assigned for IPv4 in
RFC 1700. Communications between one IPv4 site and one IPv6 site or
communications between IPv6 sites use IPv6 address, the IPv4 addresses
A.B.C.D/MASK in IPv4 sites can be mapped to IPv6 addresses in the
form of 0::A:B:C:D/(96+MASK), accordingly, AFI field in MP-BGP can be
valued as 2, which is assigned for IPv6 in RFC 1700. SAFI field in
MP-BGP can be valued as 128 to denote the address family for VPN-IPv4
or VPN-IPv6 address. So there will be two VPN address family in this
mechanism, MP-BGP will distribute VPN-IPv4 routes and VPN-IPv6 routes
at the same time, PEs and ASBRs in this mechanism should support
IPv4/IPv6 dual-stack and maintain both VPN-IPv4 routes and VPN-IPv6
routes.If some IPv4 sites have only communications with other IPv4
sites, CEs in these sites can only support IPv4 protocol and maintain
IPv4 VPN routes, otherwise CE should support IPv4/IPv6 dual-stack
and maintain both IPv4 VPN routes and IPv6 VPN routes of the same VPN.
As stated above, private IPv4 addresses is used in this method, for
the same reason as stated in RFC 2547bis, RD continues to serve the
purpose of forming the VPN-IPv4 or VPN-IPv6 address, i.e. A VPN-IPv4
address is a 12-byte quantity, beginning with an 8-byte "Route
Distinguisher (RD)" and ending with a 4-byte IPv4 address, and AFI
for this address family is 1. 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(In the case of IPv4 site which
has communication with IPv6 site, IPv4 addresses is mapped to IPv6
addresses before forming VPN-IPv6 addresses), and AFI for this
address family is 2.
2.1.2. VPN routes distribution
VPN sites distribute their routes to PE through routing protocol
between CE in the VPN site and PE connected to CE, For the hybrid
characteristic of VPN routes, i.e. CE should maintain both IPv4
routes of other IPv4 sites and IPv6 routes of other IPv6 sites, this
document proposes to run BGP4+ or IS-ISv6 protocol between CE and PE.
It is noted that these two routing protocols can carry both IPv4
routes and IPv6 routes at the same time. When BGP4+ is run between
CE and PE, the private AS number should be used in VPN sites. Of
course, if OSPFv3 run between CE and PE, IPv4 routes can also be
distributed between them through mapping IPv4 routes to IPv6 routes,
i.e. when PE learns IPv4 route a.b.c.d/n(where a.b.c.d is subnet
address, and n is mask) across backbone, it maps the route to
IPv6 route in the form of 0::a:b:c:d/(96+n) and distributes to CE,
CE then revert it to a.b.c.d/n and maintain it in IPv4 routing table.
After PE learns VPN routes from CE, PE should distribute the VPN
routes to the related sites in the same VPN through backbone network
before these sites can visit each other, and backbone is composed of
IPv4 AS and IPv6 AS, in this section, we only consider the case in
which backbone is composed of one IPv4 AS(AS1) and one IPv6 AS(AS2).
The distribution process of VPN routes across backbone is as follows:
(1) Every two of PEs and ASBR1 in AS1 setting up MP-IBGP based on IPv4;
Defeng Li Expires December 2004 [Page 4]
Internet Draft draft-defeng-l3vpn-ipv4-ipv6-hybrid-00 June 2004
(2) Every two of PEs and ASBR2 in AS2 setting up MP-IBGP based on IPv6;
(3) ASBR1 and ASBR2 setting up MP-EBGP based on IPv6;
(4) VPN routes from the sites connected to AS1 can be distributed to
each other through those MP-IBGP relationships set up in (1), IPv4
routes and IPv6 routes can be piggybacked on the same MP-IBGP;
(5) VPN routes from the sites connected to AS2 can be distributed to
each other through those MP-IBGP relationships set up in (2), IPv4
routes and IPv6 routes can be piggybacked on the same MP-IBGP;
(6) VPN routes need to be distributed to sites connected to
neighboring AS can be achieved by MP-EBGP between ASBR1 and ASBR2,
according to BGP protocol, routes learned from EBGP PEER should be
distributed to IBGP PEER, IPv4 routes and IPv6 routes can be
piggybacked on the same MP-EBGP.
After the above steps, all the VPN routes can be distributed across
backbone network, then PEs maintain the related routes. The difference
from RFC 2547bis is that PEs should maintain both IPv4 routes and
IPv6 routes in the respective VRFs, IPv4 routes and IPv6 routes can be
differentiated by the AFI of the routes received, if AFI is 1, routes
will be maintained in IPv4 part of VRF, if AFI is 2, then routes
will be maintained in IPv6 part of VRF.
As to the decision whether to accept and advertise the routes
received from MP-BGP PEER, PE follows the same rule as stated in
RFC 2547bis, where Route Target attribute is used, and this attribute
is related to the topology of VPN, it will be detailed in section
2.1.5.
Following this mechanism, all the VPN routes can be correctly
distributed all over the VPN network, For some sites need to visit
IPv4 sites and IPv6 sites, IPv4 routing table in CE can be matched
when the destination is IPv4 sites, IPv6 routing table in CE can be
matched when the destination is IPv6 sites.
If some sites have no relationship with other IPv6 sites, then it is
not necessary for these sites to run IPv6 routing protocol with PEs,
Even it is enough for these sites to support only IPv4, i.e. IPv4/IPv6
dual-stack is not a must.
2.1.3. Label Distribution
Sites belongs to different VPN can connect to the same PE, PE
differentiates them by assigning different labels for the sites, this
label is called inner label, which will be attached to the VPN routes
when PE distributing the VPN routes to MP-BGP PEERs. If backbone
network supports MPLS and LDP/RSVP-TE runs in backbone, LDP/RSVP-TE
will setup LSPs between PEs and ASBR1 in AS1 and PEs and ASBR2 in AS2
respectively and the label related to these LSPs is called outer
label, i.e. the packet received from CE will be label-stacked with
two label before IP header. If backbone network doesn't support MPLS,
other tunnelling technology can be utilized to setup the tunnel
between PE and ASBR,such as GRE, IPsec, and so on. And ASBR1 will
establish MP-EBGP with ASBR2, and MP-EBGP will distribute the labels
Defeng Li Expires December 2004 [Page 5]
Internet Draft draft-defeng-l3vpn-ipv4-ipv6-hybrid-00 June 2004
between ASBR1 and ASBR2(refer the mechanism to RFC 3107), these two
labels will form a tunnel segment to "stick" the tunnel segments in
AS1 and AS2.
2.1.4. Forwarding
Data forwarding between VPN sites across backbone consists of
following steps:
(1) IP Forwarding from source site to Ingress PE;
(2) Label or tunneling Forwarding from Ingress PE to Egress PE;
(3) IP forwarding from Egress PE to destination site.
Where, step (1) follows normal IP forwarding process. As stated in
section 2.2.3, if one site has VPN relationship with other IPv4 sites
and IPv6 sites simultaniously, CE in this site should maintain both
IPv4 route table and IPv6 route table respectively. when the
destination is IPv4 site, the IPv4 route table can be queried,
otherwise IPv6 route table will be matched. In step (2), ingress PE
pushes the inner label to the packet, if backbone supports MPLS,
pushes the outer label distributed in the Ingress PE's AS, or
encapsulates the tunnel header(when MPLS isn't supported) and
forwards packet to ASBR in Ingress PE's AS, where pops the outer
label(or penultimate hop poped the outer label) or decapsulates
the tunnel header, and pushes the label assigned by MP-EBGP between
ASBRs, forwards the packet to the ASBR in the neighboring AS, then
VPN packet is forwarded to Egress PE in the neighboring AS following
the same rules as in the previous AS. In step (3),Egress PE receives
the packet with inner label(outer label has been popped or the
tunnel header has been decapsulated) and distinguishes the
destination site by the inner label, then pops the inner label,
forwards packet to CE, at last the packet is forwarded to the
destination following normal IP forwarding rules.
mechanism
2.1.5. VPN topology
VPN sites can form different kinds of relationships, such as full
mesh, partial mesh, Hub-Spoke, which is called VPN topology.
To achieve this, the mechanism of utilizing Route Target as stated
in RFC 2547bis can still be used. VPN topology is formed through the
routes in VPN sites, if one site have routes to other sites, then it
has VPN relationships with those sites, all of VPN relationships
among VPN sites form VPN topology. PE can decide whether to accept
VPN routes received from other PE carried in MP-BGP UPDATE messages
through matching Route Target attributes. When Egress PE distributes
VPN routes, the configured Export Route Targets will be attached,
and Ingress PE is also configured with Import Route Targets, so
Ingress PE can compare the local Import Route Target with the remote
Export Route Target attached to the received routes from MP-BGP PEERs,
then only those routes with route target attributes matched can be
accepted and maintained in VRF by Ingress PE, others will be
discarded, After that Ingress PE advertise the accepted VPN routes to
the directly connected CE.
Defeng Li Expires December 2004 [Page 6]
Internet Draft draft-defeng-l3vpn-ipv4-ipv6-hybrid-00 June 2004
2.1.6. IPv4/IPv6 Multi-AS Hybrid Backbone
In Section 2.1.1. through to Section 2.1.5. , the case where only two
ASes(one is IPv4 AS, the other is IPv6 AS) is addressed in detail.
In the case of IPv4/IPv6 multi-AS hybrid backbone, the mechanisms in
Address Family, VPN routes distribution, Label Distribution,
Forwarding, VPN topology are analogic to the case of two ASes,
MP-IBGPs are setup in all the ASes between PEs and ASBR, and MP-EBGPs
are established between directly connected ASBRs in adjacent ASes,
and this MP-EBGPs will distribute the labels for these ASBRs.
VPN routes for IPv4 sites and IPv6 sites can be "relayed" among these
MP-IBGP or MP-EBGP. The tunnel used to forward packets between
Ingress PE and Egress PE can be "sticked" together from tunnel
segments of respective AS and tunnel segments between ASBRs of
adjacent ASes.
2.2. Method 2
Similar to Method 1, we first consider the scenario where backbone
network consists only two autonomous system(from Section 2.2.1. to
Section 2.2.5.), one is IPv4 AS(AS1) and the other is IPv6 AS2, they
connected to each other through some ASBRs, for simplicity,
considering the case where only one ASBR for each AS, ASBR1 for AS1,
ASBR2 for AS2, and in some of VPNs accessed to the backbone, some
sites are IPv6 sites, others are IPv4 sites.
In this method, PEs and ASBRs in IPv6 AS establish IPv6-based
full-mesh MP-IBGP(or MP-BGP Route Reflector) to distribute VPN
routes of sites belong to IPv6 AS, and every two PEs in IPv4 AS
establish IPv4-based MP-IBGP to distribute VPN routes of sites
belong to IPv4 AS, and every PE in IPv4 AS doesn't establish MP-IBGP
with ASBR in its own AS as in Method 1, but establishes IPv4-based
multi-hop MP-EBGP with ASBR in the IPv6 AS, so the VPN routes across
IPv4 AS and IPv6 AS will be distributed through these multi-hop
MP-EBGP, We call IPv6 AS as Primary AS(PAS), and IPv4 AS as
Dependent AS(DAS).
2.2.1. Address Family
Address scheme in Method 2 is the same as that in Method 1, refer to
section 2.1.1.
2.2.2. VPN routes distribution
VPN sites distribute their routes to PE through routing protocol
between CE in the VPN site and PE connected to CE, For the hybrid
characteristic of VPN routes, i.e. CE should maintain both IPv4
routes of other IPv4 sites and IPv6 routes of other IPv6 sites, this
document proposes to run BGP4+ or IS-ISv6 protocol between CE and PE.
It is noted that these two routing protocols can carry both IPv4
routes and IPv6 routes at the same time. When BGP4+ is run between
CE and PE, the private AS number should be used in VPN sites. Of
Defeng Li Expires December 2004 [Page 7]
Internet Draft draft-defeng-l3vpn-ipv4-ipv6-hybrid-00 June 2004
course, if OSPFv3 run between CE and PE, IPv4 routes can also be
distributed between them through mapping IPv4 routes to IPv6 routes,
i.e. when PE learns IPv4 route a.b.c.d/n(where a.b.c.d is subnet
address, and n is mask) across backbone, it maps the route to
IPv6 route in the form of 0::a:b:c:d/(96+n) and distributes to CE,
CE then revert it to a.b.c.d/n and maintain it in IPv4 routing table.
After PE learns VPN routes from CE, PE should distribute the VPN
routes to the related sites in the same VPN through backbone network
before these sites can visit each other, and backbone is composed of
IPv4 AS and IPv6 AS, in this section, we only consider the case in
which backbone is composed of one IPv4 AS(AS1) and one IPv6 AS(AS2).
The distribution process of VPN routes across backbone is as follows:
(1) Every two of PEs in DAS setting up MP-IBGP based on IPv4;
(2) Every two of PEs and ASBR2 in PAS setting up MP-IBGP based on IPv6;
(3) Every PE and ASBR2 setting up multi-hop MP-EBGP based on IPv4;
(4) VPN routes from the sites connected to DAS can be distributed to
each other through those MP-IBGP relationships set up in (1), IPv4
routes and IPv6 routes can be piggybacked on the same MP-IBGP;
(5) VPN routes from the sites connected to PAS can be distributed to
each other through those MP-IBGP relationships set up in (2), IPv4
routes and IPv6 routes can be piggybacked on the same MP-IBGP;
(6) VPN routes need to be distributed to sites connected to
neighboring AS can be achieved by multi-hop MP-EBGP between PEs in
DAS and ASBR2 in PAS,according to BGP protocol, routes learned from EBGP
PEER should be distributed to IBGP PEER, IPv4 routes and IPv6 routes
can be piggybacked on the same MP-EBGP.
After the above steps, all the VPN routes can be distributed across
backbone network, then PEs maintain the related routes. The difference
from RFC 2547bis is that PEs should maintain both IPv4 routes and
IPv6 routes in the respective VRFs, IPv4 routes and IPv6 routes can be
differentiated by the AFI of the routes received, if AFI is 1, routes
will be maintained in IPv4 part of VRF, if AFI is 2, then routes
will be maintained in IPv6 part of VRF.
As to the decision whether to accept and advertise the routes
received from MP-BGP PEER, PE follows the same rule as stated in
RFC 2547bis, where Route Target attribute is used, and this attribute
is related to the topology of VPN, it will be detailed in section
2.2.6.
Following the above mechanism, all the VPN routes can be correctly
distributed all over the VPN network, For some sites need to visit
IPv4 sites and IPv6 sites, IPv4 routing table in CE can be matched
when the destination is IPv4 sites, IPv6 routing table in CE can be
matched when the destination is IPv6 sites.
If some sites have no relationship with other IPv6 sites, then it is
not necessary for these sites to run IPv6 routing protocol with PEs,
Even it is enough for these sites to support only IPv4, i.e. IPv4/IPv6
dual-stack is not a must.
Defeng Li Expires December 2004 [Page 8]
Internet Draft draft-defeng-l3vpn-ipv4-ipv6-hybrid-00 June 2004
2.2.3. Label Distribution
Egress PE assigns the different labels for different sites, which may
be related to different interfaces or sub-interfaces. These labels
are attached to VPN routes of the sites when PEs distribute these
routes across backbone, these labels are inner labels in label stack
during encapsulation before forwarding VPN packets across backbone.
To guarantee the isolation of VPN service in backbone, VPN packets
are forwarded in tunnels between Ingress PE and Egress PE, if some
AS in backbone supports MPLS, the tunnel can be LSP, the labels form
the LSP are distributed by LDP/RSVP-TE, and these labels are outer
labels in label stack, if MPLS is not supported in some AS, then
other types of tunnel, such as IPsec(tunnel mode) or GRE tunnel can
be used. ASBR in DAS and ASBR in PAS can distribute labels for each
other by MP-EBGP between them, these labels will be encapsulated as
outer labels between these two ASBRs.
2.2.4. Segmented Tunnel
In this method, The tunnel between Ingress PE and Egress PE is
composed of segments of those from PE to ASBR in their respective ASes
and those between ASBRs. The segments in the respective ASes can be
LSP formed by outer labels distributed LDP run in ASes, or other type
of IP tunnel, such as GRE tunnel or IPsec in tunnel mode. Segment
between ASes is LSP of label distributed by MP-EBGP between ASBRs.
2.2.5. Forwarding
VPN packets forwarding in this method is the same as that in Methos 1,
which is addressed in detail in section 2.1.4.
2.2.6. VPN topology
This aspect is the same as that in Method 1, which is addressed in
section 2.1.5.
2.2.7. Hierarchical IPv4/IPv6 Multi-AS Hybrid Backbone
In sections 2.2.1. through to 2.2.6., the case where VPN backbone
is composed of one IPv4 AS(DAS) and one IPv6 AS(PAS) is addressed.
In some cases, VPN backbone is composed of three or more ASes, and
at least one of them is IPv6 AS, then the IPv6 AS with largest number
of PEs than other IPv6 AS is looked upon as PAS, other IPv6 AS and
IPv4 AS are looked upon as DAS, in the case of three ASes, the
topology can be DAS-PAS-DAS, or DAS-DAS-PAS, it can be looked upon
as a new DAS was concatenated to the "DAS-PAS" topology as addressed
in section 2.2.1 by the rule that PEs in the new DAS establish
MP-IBGP to distribute the VPN routes of sites connected to PEs
belong to this new DAS, and PEs establish multi-hop MP-EBGP with
ASBR in the adjacent AS of this new DAS, and the ASBR involved should
establish multi-hop MP-EBGP with the ASBR in its adjacent AS, until
this MP-EBGP relationship reaches the ASBR in PAS. So the MP-EBGP is
Defeng Li Expires December 2004 [Page 9]
Internet Draft draft-defeng-l3vpn-ipv4-ipv6-hybrid-00 June 2004
hierarchical multi-hop MP-EBGP, VPN routes of sites across AS can be
distributed by this hierarchical multi-hop MP-EBGP. This architecture
is called hierarchy of DAS and PAS. Ths case of IPv4/IPv6 Multi-AS
Hybrid Backbone can be addressed by this architecture.
3. IPv4 backbone and IPv4/IPv6 hybrid VPN sites
In the scenario where VPN backbone is IPv4 network of one or more
AS, and some VPN sites is IPv4 enable, other VPN sites is IPv6
enable, and these VPN sites would like to establish VPN service. In
this case, the goal can be achieved by assigning the private IPv4
addresses for these IPv6 sites at PE device, and then run private
IPv4 address NAT-PT at the related PE device, an private IPv4
address pool can be maintained at PE for every IPv6 VPN site
connected. The address pool is denoted in a private IPv4 subnet
prefix, and this subnet prefix can't be duplicated in the VPN this
subnet prefix belongs to, and PE assigns different private IPv4
subnet prefix for different IPv6 sites. NAT-PT address pool assigns
every private IPv4 address for every IPv6 hosts in IPv6 sites
dynamically or statically, so as to every IPv6 host can get unique
private IPv4 address. To be compatible with other VPN routes, these
private IPv4 subnet prefix are treated as VPN routes of the
corresponding IPv6 sites, and will be formed to IPv4-VPN routes by
prefixing with RD, these IPv4-VPN routes can be distributed across
backbone by MP-BGP in RFC 2858, To identify whether a VPN site is
an IPv6 site, we can extend MP-BGP protocol by adding an Extended
Community attribute: If-V6-Site, this attribute can be attached to
VPN routes when distributing IPv4-VPN among PEs with MP-BGP, for
VPN routes of IPv6 sites, both the mapped IPv4 routes(private IPv4
subnet prefix maintained by NAT-PT) at PE device and the true IPv6
routes of the IPv6 sites should be distributed to the MP-BGP Peer,
the true IPv6 routes can be attached to UPDATE message in MP-BGP
as the "value" field of If-V6-Site extended community attribute.
The MP-BGP Peers which receive these UPDATE message can decide
whether to accept the IPv4-VPN routes by matching the Route Target
attributes as stated in RFC 2547bis, then decide whether to accept
the true IPv6 routes by identifying if the IPv6 sites of the same
VPN is conneted, if MP-BGP Peer connects IPv6 sites of the same VPN,
the true IPv6 routes will be accepted too, otherwise the true IPv6
routes will be discarded. By this mechanism, a IPv6 site can visit
other IPv6 sites with these true IPv6 routes directly, and IPv6
packets can be directly encapsulated with MPLS label-stack or GRE
tunnel header and forwarded across VPN backbone, so that two-way
NAT-PT translation at Ingress PE and Egress can be avoided,which
maybe introduce the missing information during NAT-PT. In this way,
the integrity of communication between IPv6 sites in the hybrid VPN
can be achieved. As to communication between IPv4 site and IPv6 site,
NAT-PT translation at PE where IPv6 site is connected should be
performed. Of course, communication among IPv4 sites follows the
same rule detailed in RFC 2547bis.
3.1. Address Family and Route Distribution
Defeng Li Expires December 2004 [Page 10]
Internet Draft draft-defeng-l3vpn-ipv4-ipv6-hybrid-00 June 2004
We only consider Unicast communication between VPN sites, and
Unicast address(IPv4 or IPv6) should be used. Considering
there are still some IPv4 Sites in the VPN and the scarcity of IPv4
address, private IPv4 addresses(defined in RFC 1918) are allowed to
be used IN vpn sites, and if two VPNs have no sites in common, they
may have overlapping address spaces, this aspect is the same as
[RFC 2547bis]. For IPv6 sites, the global unicast address should be
used, for the huge IPv6 address space, all the addresses are public
addresses.
Communications between IPv4 sites or between one IPv4 site and one
IPv6 site use IPv4 address, the address for IPv6 site can be the
private address assigned by NAT-PT, communications between IPv6
sites use IPv6 address. As the true IPv6 routes for the IPv6 sites
and IPv4 routes(including the subnet prefix for IPv6 sites maintained
by NAT-PT at PE) are both distributed by IPv4-based MP-BGP across
backbone, AFI field in MP-BGP can be valued as 1, which is assigned
for IPv4 in RFC 1700. SAFI field in MP-BGP can be valued as 128 to
denote the address family for VPN-IPv4 address. PEs connect IPv6
sites should run NAT-PT, these PEs should be dual-stacked, and CEs
in those sites having VPN relationships with both IPv4 sites and
IPv6 sites should be dual-stacked too, and CEs maintain both IPv4
routes and IPv6 routes for these sites. If some sites have only
communications with other sites of the same IP version, such as
IPv4 to IPv4, or IPv6 or IPv6, CEs in these sites can only support
one IP version protocol and maintain only one IP version routes,
in this case, CEs can select only part of the same IP version as
the sites in VPN routes when CEs learn VPN routes from PEs.
As stated above, private IPv4 addresses is used in this method, for
the same reason as stated in RFC 2547bis, RD continues to serve the
purpose of forming the VPN-IPv4, i.e. A VPN-IPv4 address is a
12-byte quantity, beginning with an 8-byte "Route Distinguisher (RD)"
and ending with a 4-byte IPv4 address. VRF can also used to maintain
VPN-IPv4 routes(including the private IPv4 subnet prefix for IPv6
site at PE maintained by NAT-PT) as stated in RFC 2547bis, as to the
true IPv6 routes received as If-V6-Site attribute value in UPDATE
message, they can be maintained seperately from VRF, normally, they
can be globally unique.
Routing protocol runs between PE and CE to distribute VPN routes,
Considering the requirement of distributing both IPv4 routes
(including Private IPv4 subnet prefix for IPv6 sites at PE maintained
by NAT-PT) and true IPv6 routes for IPv6 sites, BGP4+ and IS-ISv6
protocol which can piggybacking IPv4 and IPv6 routes simultaniously
are suggested.
If local site is IPv4 site, CE distributes aggregated IPv4 routes
in the local site to PE, and PE distributes to CE the VPN routes of
remote sites of the same VPN, if the remote site is IPv6 site, only
the private IPv4 subnet prefix for that IPv6 site maintained by
NAT-PT at the remote PE will be distributed to the local IPv4 site,
and ignore If-V6-Site attribute attached.
Defeng Li Expires December 2004 [Page 11]
Internet Draft draft-defeng-l3vpn-ipv4-ipv6-hybrid-00 June 2004
If local site is IPv6 site, CE distributes aggregated IPv4 routes
in the local site to PE, and PE distributes to CE the VPN routes of
remote sites of the same VPN, if the remote site is IPv6 site, the
VPN routes will include the true IPv6 routes for the remote site,
and CE can only learn this part and discard the related private IPv4
subnet prefix for the remote IPv6 site, if the remote site is IPv4
site, the VPN routes for the remote IPv4 site(a.b.c.d/mask) can be
translated to the form of (NAT-PT Prefix:a:b:c:d:/(96+mask)) and
distribute to CE in the local IPv6 site.
Note: NAT-PT Prefix in a prefix assigned by IANA.
After learning VPN routes from CEs, PEs will distribute VPN routes
through IPv4-based MP-BGP across backbone, and the true IPv6 routes
can be piggybacked on IPv4-based MP-BGP in If-V6-Site attributes
with the mechanism stated above.
3.2. Judgement of IPv4/IPv6 sites
Whether the sites is IPv6 or not can be identified by the address
of the interface(subinterface) between CE and PE, then PE can set
the related fields in If-V6-Site Extended Community attribute when
distributing the VPN routes across backbone, and whether the remote
site is IPv6 can be identified by If-V6-Site attached to VPN routes
received.
3.3. If-V6-Site Attribute
If-V6-Site is an Extended Community attribute for MP-BGP defined in
this document, it is a triple of (Type,Length,Value), the structure
can be denoted temporarily as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T| length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+|
| IPv6 Route1 | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Routen | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:
T: 0 or 1, "0" denotes the site is IPv4 site, "1" denotes the site
is IPv6 site.
Length: denotes the number of NLRI entries in the value field. If
T = 0, then, Length Field should be zero when setting in sender and
ignore at receiver.
Value: denotes the specific the true IPv6 routes in the related
site in the form of concatenated IPv6 route entries.
3.4. Label Distribution and Tunnel
Defeng Li Expires December 2004 [Page 12]
Internet Draft draft-defeng-l3vpn-ipv4-ipv6-hybrid-00 June 2004
In these aspects, the mechanism in RFC 2547bis can be inherited
totally. The inner label can be distributed by Egress PE and
attached to VPN routes when PE distributing VPN routes to MP-BGP
Peers, As to the outer label can be distributed by LDP/RSVP-TE if
backbone support MPLS, otherwise other type of tunnel can be
utilized, such as GRE, IPsec(tunnel mode).
3.5. Forwarding
(1) For communication between IPv4 sites, the forwarding procedure in
RFC 2547bis can be inherited, take the situation where MPLS is
supported for example, Egress PE distributes the inner labels for
different VPN sites when distributing the VPN routes for these sites
through MP-BGP, when Ingress PE receives VPN routes, the inner labels
are attached. In addition, LDP/RSVP-TE can run between Ingress PE and
Egress PE, they can distribute the outer labels between them, and LSP
between Ingress PE and Egress PE can be setup, VPN packets are
encapsulated with two-layer labels and forwarded to Egress PE
following the LSP, and the outer label will be popped at Egress PE or
penultimate hop popped, Egress PE then forwards the VPN packets with
inner label to the destination site according the inner packets.
(2) For communication from IPv4 site to IPv6 site, IPv4 site has
learned the private IPv4 subnet prefix for IPv6 site maintained by
NAT-PT at the remote PE, so the destination address in the VPN packet
can be the private IPv4 address assigned for IPv6 address of the sink
host in the remote IPv6 site(this procedure will involve DNS function,
which is out of the scope of this docuent), this packet is forwarded
to Egress PE following the normal mechanism stated in RFC 2547bis, at
Egress PE, the related NAT-PT will translate the packet to IPv6
packet by translating the source IPv4 address to (NAT-PT Prefix:source
IPv4 address), and destination address to the true IPv6 address in the
IPv6 site( in some cases, the ALG should be deployed at Egress PE to
process the address translation in the application layer, however,
this aspect will not be discussed in this document). Then the packet
is forwarded to CE and then reaches the sink host following the normal
IPv6 forwarding.
(3) For communication from IPv6 site to IPv4 site, IPv6 site has
learned the IPv6 routes in the form of (NAT-PT Prefix:IPv4 routes),
the destination address of the packet will be set (NAT-PT Prefix:
destination IPv4 address), the packet is forwarded to Ingress PE,
NAT-PT at Ingress PE will translate the source IPv6 address to the
private IPv4 address NAT-PT assigned for the IPv6 host, and translate
the destination address to the "destination IPv4 address" part in
IPv6 address of (NAT-PT Prefix:destination IPv4 address) form, and
a IPv4 packet will be encapsulated. This packet is forwarded to
Egress PE then forwarded to the sink host following the mechanism
stated in RFC 2547bis, DNS and ALG may be required in this case,
however, it will not be discussed here.
(4) For communication between IPv6 sites, as stated in the above
sections, If-V6-Site Extended Community attribute is introduced
in this mechanism, and the true IPv6 routes in source and destination
Defeng Li Expires December 2004 [Page 13]
Internet Draft draft-defeng-l3vpn-ipv4-ipv6-hybrid-00 June 2004
IPv6 sites are learned across backbone, so the packet in the site can
be forwarded according the true IPv6 routes, when the packet reaches
Ingress PE, Ingress PE just encapsulates it with two layered label
stack and forwarded to Egress PE, then Egress PE forward the packet
to sink host following the normal IPv6 forwarding procedure. In this
case, maybe IPv6-DNS is required, however, NAT-PT doesn't participate
the translation so as to guarantee the integrity of communication
between IPv6 sites.
4. Quality of Service
[2547bis] is applicable.
5. Security Considerarion
This document extended BGP/MPLS VPN for some scenarios, such as that
of IPv4 backbone and IPv4/IPv6 hybrid VPN sites and that of IPv4/IPv6
Hybrid Backbone and Hybrid VPN sites. All the security analysis
stated in http://www.ietf.org/internet-drafts/draft-ietf-l3vpn-
security-framework-01.txt applys to the mechanisms in this document.
6. IANA Consideration
This document has no actions for IANA.
7. Normative References
[2547bis] Rosen et al., "BGP/MPLS VPNs", draft-ietf-ppvpn-
rfc2547bis-01.txt, January 2004, 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 2004, work in
progress
[2547-IPsec] Rosen, De Clercq, Paridaens, T'Joens, Sargor, "Use of
PE-PE IPsec in RFC2547 VPNs", draft-ietf-ppvpn-ipsec-2547-01.txt,
February 2004, work in progress
[BGP-TUNNEL] De Clercq, J., et al., "Connecting IPv6 Islands across
IPv4 clouds with BGP", draft-ietf-ngtrans-bgp-tunnel-04.txt, 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
[IPv6] Deering, S., and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC2460.
[MPLS-ARCH] Rosen, Viswanathan, and Callon, "Multiprotocol Label
Switching Architecture", RFC3031
Defeng Li Expires December 2004 [Page 14]
Internet Draft draft-defeng-l3vpn-ipv4-ipv6-hybrid-00 June 2004
[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.
[RFC3513] Deering, S., and Hinden, R., "IP Version 6 Addressing
Architecture", RFC3513.
[RFC2766] G. Tsirtsis, P. Srisuresh, " Network Address Translation
- Protocol Translation (NAT-PT)", RFC2766.
8. Informative References
[RFC1701] Hanks, S., Li, T., Farinacci, D. and P. Traina,
"Generic Routing Encapsulation (GRE)", RFC 1701,
October 1994.
9. Authors' Addresses
Li Defeng
D201 ,HuaWei Bld. No.3 Xinxi Rd.
Hai-Dian District BeiJing P.R.China
Zip : 100085
Email : 77cronux.leed0621@huawei.com
10. IPR Disclosure
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668."
11. IPR Notice
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to rights
in RFC documents can be found in BCP 78 and BCP 79.
Defeng Li Expires December 2004 [Page 15]
Internet Draft draft-defeng-l3vpn-ipv4-ipv6-hybrid-00 June 2004
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org.
12. Copyright Notice and Disclaimer
Copyright (C) The Internet Society (year). This document is
subject to the rights, licenses and restrictions contained in BCP
78, and except as set forth therein, the authors retain all their
rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Defeng Li Expires December 2004 [Page 16]