INTERNET DRAFT Defeng Li Huawei Technologies Expires January, 2004 July 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-01 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-01 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-01 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-01 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-01 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-01 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-01 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-01 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-01 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-01 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-01 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-01 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-01 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-01 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-01 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]