L3VPN Working Group Bin. Lee, Huawei Internet Draft HF. Chen, Huawei Expires: April 2006 October 17, 2005 IPv6 VPN Based Address Format draft-lee-l3vpn-ipv6-vpn-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 as "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 This Internet-Draft will expire on April 17, 2005. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract This text introduces a kind of method to carry out VPN based on IPv6 addresses, defines VPN unicast and multicast address structure and the method to construct VPN topology, and depicts unicast and multicast routing and forwarding process between VPN sites. Moreover, this text discusses VPN security. Lee, Chen Expires April 17, 2006 [Page 1] Internet-Draft IPv6 VPN based Address Format October 2005 Table of Contents 1. Introduction.................................................2 2. VPN Address..................................................4 2.1. VPN-Local Addresses.....................................4 2.2. Global VPN Addresses....................................5 2.3. Mapping between Global VPN Addresses and VPN-local Addresses ............................................................6 3. Allocating VPN Site ID.......................................7 4. VPN Topology.................................................7 4.1. VPN Topology Discovery Process..........................8 4.2. Establishing Site Route Table...........................9 5. VPN Packet Forward...........................................9 5.1. Forward within the Site.................................9 5.2. Forward on SE at the Ingress...........................10 5.3. Forward in the Public Network..........................10 5.4. Forward on SE at the Egress............................10 6. Internet Access.............................................11 7. Overriding Autonomous System................................11 8. Interconnecting with IPv4 Sites.............................11 9. Security Considerations.....................................13 9.1. Ingress Check..........................................13 9.2. Egress Check...........................................13 10. IANA Considerations........................................13 11. References.................................................14 11.1. Normative References..................................14 11.2. Informative References................................14 Author's Addresses.............................................15 Intellectual Property Statement................................15 Disclaimer of Validity.........................................16 Copyright Statement............................................16 Acknowledgment.................................................16 1. Introduction This text describes a kind of VPN based on the IPv6 address structure. The Ipv6 address has been widely used for addressing in the site and subnet. But it hasn't been used for addressing between sites in VPN yet. There are enough bits available in IPv6 addresses to allow us to embed a VPN site ID in the IPv6 address, so that no encapsulation overhead is required to achieve isolation between VPNs. Meanwhile, VPN site ID can serve as an aggregation route to a site. Between sites in the same VPN, routes are reachable. Between sites in Lee, Chen Expires April 17, 2006 [Page 2] Internet-Draft IPv6 VPN based Address Format October 2005 different VPNs, routes are unreachable. In this way, VPNs may be formed in a great variety of topologies. Addresses used for mutual access in VPN are named VPN addresses. Their forms differ in VPN from those in Internet, who are named the VPN-local address and the global VPN address respectively. Compared with the internal VPN address, the global VPN address increases VPN site ID and carries out address translation by site edge devices. The VPN addresses defined in this text do not conflict with the unique local IPv6 unicast addresses defined in [UNILOCAL]. As a special local VPN address, the latter is not used for addressing in the public network, while the global VPN address is used for addressing in the public network. On site edge devices, unique local IPv6 unicast addresses can also be translated to global VPN addresses. For the sake of supporting multicast, assign specific multicast addresses for VPN. Similar to VPN site ID, site edge devices embed VPN group ID in VPN multicast addresses. Routing and forwarding of packets in VPN is the same as that in the site, and VPN hosts cannot tell the difference between mutual access in the site and mutual access in VPN. Therefore, the defined unicast and multicast address formats in VPN are the same as addresses in the site. Thus, hosts do not need modification. While addressing between sites or on Internet, the global VPN address is similar to the public network address of Internet in both format and routing and forwarding mode. Moreover, Internet addressing can be easily carried out on devices. For composing several sites into a VPN, this text defines VPN topology discovery mechanism. This kind of VPN has the following features: 1. VPN information is embedded in the IPv6 address, so there is no additional cost in VPN packets encapsulation. 2. The forward process of VPN packets is consistent with that of the average IP packets, so VPN traffic can be born on the pure IPv6 network. 3. Use VPN site ID as the valid global site identifier, as the aggregation route to reach the site and as the basis on which VPN topology forms. VPN site ID can be identical with global routing prefix of this site. Lee, Chen Expires April 17, 2006 [Page 3] Internet-Draft IPv6 VPN based Address Format October 2005 4. Site edge routes take charge of updating VPN information and ensuring the security of VPN information. The reference model of this VPN is shown as follows. ........... .................. ............ . . . . . . . . VPN1 . +-------+ . . +-------+ . VPN2 . . Site1 .---| | . .---| SE2 |----. Site2 . ........... | | . Public . +-------+ ............ | SE1 |---. IPv6 . ........... | | . Network . +-------+ ............ . .---| | . .---| SE3 |----. . . VPN2 . +-------+ . . +-------+ . VPN1 . . Site1 . . . . Site2 . ........... .................. ............ The device at the boundary between the VPN site and the public network is named Site Edge router (SE). When SE belongs to operators, this model becomes PE-based VPN. When SE belongs to clients, this model becomes CE-based VPN. 2. VPN Address Two kinds of VPN addresses are defined to carry out VPN addressing within VPN and on the public network. 2.1. VPN-Local Addresses The VPN-local address is similar to the link-local address and the site-local address. It's encapsulated by hosts. Valid only within VPN, this address can help complete interconnection in VPN. The unicast address structure is as follows. | 10 bits | 38 bits | 16 bits | 64 bits | +----------+-------------------------+------------------------+ |1111111011| reserved | subnet ID| interface ID | +----------+-------------------------+------------------------+ Lee, Chen Expires April 17, 2006 [Page 4] Internet-Draft IPv6 VPN based Address Format October 2005 Through using the same type prefix (1111111011) of the site-local address, the current hosts and routers can use the VPN-local address without changing. If sites have used unique local IPv6 unicast addresses that are defined in [UNILOCAL], they can continue to use it. Multicast address structure is as follows. | 8 | 4 | 4 | 80 | 32 | +--------+----+----+---------------------------------------------+ |11111111|flgs|scop| reserved | group ID | +--------+----+----+---------------------------------------------+ The flgs field contains four bits. +-+-+-+-+ |V|R|P|T| +-+-+-+-+ V bit(the ninth bit)refers to the VPN multicast address. In VPN, it is set as 0. For details about R bit and P bit, see [ADDR ARCH]. T bit (the twelfth bit) implies that the multicast address is not permanent, which is set as 1. The scop field (from the thirteen bit to the sixteen bit) is set as 0101, which is the same as the valid multicast address in the site. Thus, the current hosts and routers can use the VPN-local multicast address without changing. 2.2. Global VPN Addresses The global VPN address is used for destination addressing in VPN on the public network. Routers on the public network only consider how to reach a VPN site and which VPN site to reach, without considering how to reach the destination within the VPN site. Global VPN addresses are different from global public network addresses. Routers must prevent global VPN addresses of different VPNs from mutual access. Unicast address structure is as follows: Lee, Chen Expires April 17, 2006 [Page 5] Internet-Draft IPv6 VPN based Address Format October 2005 | 3 | 45 bits | 16 bits | 64 bits | +---+---------------------+-----------+----------------------------+ |010| VPN site ID | subnet ID | interface ID | +---+---------------------+-----------+----------------------------+ |Global VPN routing prefix| Global VPN routing prefix contains a prefix 010 and a VPN site ID. The former is separated from global public network addresses, and the latter is used for addressing a VPN site in the public network. Subnet ID and interface ID are only used to save internal VPN unicast addresses. When addressing in the public network, they are neglected. Multicast address structure is as follows. | 8 | 4 | 4 | 48 | 32 | 32 | +--------+----+----+--------------+--------------+---------------+ |11111111|flgs|scop| reserved | VPN group ID |local group ID | +--------+----+----+--------------+--------------+---------------+ VPN group ID causes site edge devices (but I'm guessing here - please let me know if I misunderstood) to transmit multicast packets between sites of VPN. V bit in flgs field is set as 1, which refers to a VPN multicast address. The scop field is set as 1110, which refers to a valid global multicast address. The local group ID is used to save internal VPN multicast addresses, which can be neglected when addressing in the public network. Or combining with the VPN group ID, it can be used for addressing in the public network. 2.3. Mapping between Global VPN Addresses and VPN-local Addresses Mutual mapping can be carried out between Global VPN unicast addresses and VPN-local unicast addresses. During the mapping, interface ID and subnet ID do not change, but different prefixes will be added and VPN site ID will be deleted or added to global addresses or local addresses. Lee, Chen Expires April 17, 2006 [Page 6] Internet-Draft IPv6 VPN based Address Format October 2005 If unique local IPv6 unicast addresses are used, mutual translation should be carried out between global ID and VPN site ID and different prefixes should be added to them during the mapping. Global VPN multicast addresses generate through the mapping from local addresses. During the mapping, different flags and scop fields are set and VPN group IDs are added or deleted for them. 3. Allocating VPN Site ID When the global routing prefix is assigned to a site, it can be used as VPN site ID. Global VPN unicast addresses and global unicast addresses are identical in format but different in prefix. The prefix of the former is 010, while that of the latter is 001. VPN site ID corresponds to global routing prefix. Therefore, a site can distinguish Internet from VPN by using different prefixes while accessing them. Independent of global routing prefix, allocating VPN site ID can be completed, as long as it is the unique one in the global. 4. VPN Topology VPN is composed of multiple sites. VPN topology refers to the connection between each site. If some sites belong to the same VPN, their routes are reachable. If not, their routes are unreachable. In Global VPN addresses, site ID is used to identify sites. Moreover, through site ID, there are several methods to learn which VPN a site belongs to. Method one: Use some fields in VPN site ID to identify VPN, that is, VPN ID. If some sites belong to the same VPN, they have the same VPN ID. The format of VPN site ID is as follows. | 29 bits | 16 bits | +-------------------------------------+ | VPN ID | Site ID | +-------------------------------------+ Lee, Chen Expires April 17, 2006 [Page 7] Internet-Draft IPv6 VPN based Address Format October 2005 Method two: Append route attributes to VPN site ID so as to express VPN topology. Route attributes can use the format of BGP extension community attributes, that is, Route Target (RT) [EXT COMM]. Method three: Through static configuration on SEs to determine between which sites exists VPN relation. 4.1. VPN Topology Discovery Process Using the first VPN site ID method: While initializing, SE sets VPN site ID containing VPN ID. Based on VPN site ID, SE generates an IPv6 aggregation route, that is, 010:VPN site ID::/48, which is named the VPN site route. SE advertises it to backbone router and other SEs. Destination SE matches with VPN ID of locally configured VPN site ID, based on the information about VPN ID of VPN site route. If they are identical, this route is installed. If not, it is dropped. Thus, routes between sites in the same VPN are reachable, while routes between sites in different VPNs are unreachable. Using the second VPN site ID method: While initializing, SE sets VPN site containing VPN site ID, the ingress RT list and the egress RT list. Based on such information, SE generates an IPv6 aggregation route, that is, 010:VPN site ID::/48 and appends RT extension community attribute contained in the egress RT list. SE advertises it to backbone router and other SEs. Destination SE matches with the local ingress RT list, based on RTs of the VPN route. If at least one RT is identical, this route is installed. If not, it is dropped. Thus, based on RT matching relationship, a wide variety of VPN topologies can be constructed, such as, full mesh and hub-spoke as well as Intranet and Extranet. Using the third VPN site ID method: While initializing, SE sets the VPN site. SE generates an IPv6 aggregation route, that is, 010:VPN site ID::/48 and advertises it to backbone router and other SEs. Destination SE judges which VPN it belongs to and determines to install or drop this route, based on the locally configured site list. If using unique local IPv6 unicast addresses, sites need to advertise the global ID to other SEs accompanies the above processes. To support multicast in VPN, set VPN group ID on SE when the VPN site is configured. Then, SE joins to this multicast group specified by Lee, Chen Expires April 17, 2006 [Page 8] Internet-Draft IPv6 VPN based Address Format October 2005 VPN group ID through multicast routing protocols. This group is used to propagate internal VPN multicast packets in the public network, including each local group. However, if no host joins to a local group within a site, it's unnecessary that the SE connected to this site still receives multicast packets from the SE connected to multicast source. Optimization method is as follows: Through multicast routing protocols, SE joins to the multicast group specified by VPN group ID + local group ID. This method aims at some specific local groups. For example, traffic in this local group is large, or only a fraction of sites join to this local group. No matter which method is used, each site has a VPN site list on SE. The list contains ID of other sites who have VPN relation with the site. If using unique local IPv6 unicast addresses, each site has an additional global ID. Thus, a mapping table comes into being between a VPN site ID and a global ID. 4.2. Establishing Site Route Table Each site generates a route table on SE. The table contains the route of this site as well as routes of all sites that have VPN relation with this site. Internal routes of a site can be obtained from the internal of sites through static configuration or routing protocols. Aggregation routes to other sites can be obtained during topology discovery, as described in the above section. Internal routes of other sites can be obtained from routing protocols between SEs. When SE advertises VPN routes to other sites, it should specify an attribute for these routes to indicate where they come from, that is, VPN site ID. If multiple VPN routes are installed on SE, VPN site ID can be used to distinguish different VPN routes to ensure the uniqueness of routes. After the destination SE receives this route, check which local site and this route belong to the same VPN so that install it to a route table that is related to this site. 5. VPN Packet Forward 5.1. Forward within the Site When forwarding within the site, both source addresses and destination addresses use the VPN-local address format without adding VPN site ID or VPN group ID. Standard unicast or multicast forward mechanism is also tolerable. Lee, Chen Expires April 17, 2006 [Page 9] Internet-Draft IPv6 VPN based Address Format October 2005 5.2. Forward on SE at the Ingress First of all, use interface or sub interface or packet header to judge which site the packets come from. After judgment, as for unicast packets, add site ID, translate source addresses into global VPN addresses, and search site route tables by destination addresses for destination site ID. Translate destination addresses into global VPN addresses and forward to the next hop based on the destination site ID. As for multicast packets, add source site ID, translate source addresses into global VPN addresses, and add VPN group ID based on VPN of the site. Then translate destination addresses into global VPN multicast addresses based on VPN group ID, search multicast route tables and forward them. 5.3. Forward in the Public Network During VPN topology discovery, an aggregation route to the destination site is obtained. Therefore, unicast packets use the standard IPv6 routing and forwarding mechanism to reach SE at the egress. Multicast packets search the multicast route table based on VPN group ID + local group ID in global VPN multicast addresses. If only the route of VPN group ID exists in the route table, forward packets on the basis of this aggregation route. If there is the route of VPN group ID + local group ID, forward packets on the basis of this precise route. Different from standard multicast forwarding process, this multicast forwarding process is carried out through longest matching method similar to unicast forwarding, which is named multicast longest matching forwarding. 5.4. Forward on SE at the Egress For unicast packets, locate the local site route table based on VPN site ID in the destination address, translate source and destination addresses into the VPN-local address, and search the site route table and then forward packets into site. In this process, if the unique local IPv6 unicast address is used, the VPN site ID of the source and destination address is mapped to corresponding global ID. For multicast packets, locate the local site based on VPN group ID in the destination address, translate the source address into the VPN- local address, and translate the destination address into the VPN- local multicast address and then forward packets based on the local group ID. Lee, Chen Expires April 17, 2006 [Page 10] Internet-Draft IPv6 VPN based Address Format October 2005 6. Internet Access VPN sites can access Internet and other sites of VPN at the same time. In the case of internet access, VPN-local addressed need to be translated into global Internet addresses. The format is shown as RFC3587. | 3 | 45 bits | 16 bits | 64 bits | +---+---------------------+-----------+----------------------------+ |001|global routing prefix| subnet ID | interface ID | +---+---------------------+-----------+----------------------------+ The global routing prefix can be identical with VPN site ID. This translation should be completed by terminals. The global routing Prefix can be obtained by automatic configuration mechanism defined in RFC2462 from SE. Internet cannot access internal VPN multicast addresses. 7. Overriding Autonomous System VPN uses the standard IPv6 routing and forwarding mechanism while forwarding packets. Therefore, when overriding Autonomous System (AS), VPN just needs to advertise VPN site and VPN group routes to the neighboring AS to ensure routes are reachable between sites of the same VPN. Then, internal site routes are advertised between SEs of the same VPN. 8. Interconnecting with IPv4 Sites This technology is also used to interconnect multiple IPv4 networks through IPv6 backbone networks or access VPN user who have used IPv4 addresses. By now, SE still assigns VPN site ID for each IPv4 site and a VPN group ID for multicast of this site. SE meanwhile maintains an IPv4 route table for this site. But this kind of IPv4 route carries a route attribute, which contains VPN site ID. After obtaining the IPv4 route within the site, SE appends a VPN site ID attribute and advertises it to other SEs. Then destination SE Lee, Chen Expires April 17, 2006 [Page 11] Internet-Draft IPv6 VPN based Address Format October 2005 checks whether this site and a local site belong to the same VPN. If so, this route is installed. If not, it is dropped. For the unicast packet entering SE, confirm which site it comes from based on the inbound interface or sub-interface, search this site's IPv4 route table, find the destination site ID and translate source and destination IPv4 addresses into VPN IPv4-embedded IPv6 address. The format is based IPv4-embedded IPv6 address defined by IP Version 6 Addressing Architecture, and add VPN site ID. It's shown as follows. | 3 | 45 bits | 32 | 16 | 32 bits | +---+-----------------------------+--------+--------------------------+ |010| VPN site ID |reserved|FFFF| IPv4 address | +---+-----------------------------+--------+----+---------------------+ Then forward packets based on the destination site ID at this SE and backbone routers. When packets reach SE at the egress, learn their destination is an IPv4 site based on VPN site ID. Translate them into IPv4 addresses and search the IPv4 route table of the site and then forward packets into site. For multicast packets entering SE, firstly detect which site they come from based on the inbound interface or sub-interface, obtain the VPN group ID of the site, and then translate the source address into the VPN IPv4-embedded IPv6 address and translate the destination address into the VPN ipv4-embedded IPv6 multicast address. The format is shown as follows. | 8 | 4 | 4 | 48 | 32 | 32 | +--------+----+----+--------------+--------------+---------------+ |11111111|1RP1|1110| reserved | VPN group ID | IPv4 Group | +--------+----+----+--------------+--------------+---------------+ Based on this address, forward packets in the backbone network, When packets reach the egress of SE, learn their destination is an IPv4 site based on the VPN group ID, and translate it into an IPv4 multicast address and then forward packets into site. Lee, Chen Expires April 17, 2006 [Page 12] Internet-Draft IPv6 VPN based Address Format October 2005 9. Security Considerations 9.1. Ingress Check The global VPN source and destination address can only be generated by SE. Prevent feigned VPN packets from entering the backbone network, through only receiving those packets whose source and destination addresses are VPN-local addresses, unique local IPv6 unicast addresses or global Internet addresses at interfaces connecting VPN sites on a SE. If source and destination addresses of packets are unique local IPv6 unicast addresses, check whether the global ID in the source address is legal. Other interfaces in the SE do not receive such packets whose source and destination addresses are VPN- local addresses or unique local IPv6 unicast addresses, nor do routers in backbone networks. 9.2. Egress Check At the egress of SE, prevent the ingoing packets from being set illegal source site ID. Separate VPN site ID from the source address of VPN packets and check whether it and the site in the VPN destination address belong to the same VPN. If not, drop this packet. 10. IANA Considerations The IANA is requested to assigned the 4000::/3 prefix to global VPN unicast address and add the following note and link it to this address block. 4000::/3 VPN Global Unicast [IPv6 VPN] Lee, Chen Expires April 17, 2006 [Page 13] Internet-Draft IPv6 VPN based Address Format October 2005 11. References 11.1. Normative References [ADDRARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", Work In Progress. [RFC 3587] R. Hinden S. Deering and E. Nordmark, "IPv6 Global Unicast Address Format", RFC3587, August 2003 [UNILOCAL] R. Hinden and B. Haberman, Unique Local IPv6 Unicast Addresses, Work In Progress. [RFC 2462] S. Thomson, T. Narten , "IPv6 Stateless Address Autoconfiguration", RFC2462, December 1998 [RFC 4110] R. Callon, M. Suzuki, "A Framework for Layer 3 Provider- Provisioned Virtual Private Networks (PPVPNs)", RFC4110, July 2005 [EXT COMM] Ramachandra, Tappan, Rekhter, "BGP Extended Communities Attribute", Work In Progress 11.2. Informative References [BGPv6VPN] Jeremy De Clercq , Dirk Ooms, Marco Carugi and Francois Le Faucheur , "BGP-MPLS IP VPN extension for IPv6 VPN", Work In Progress Lee, Chen Expires April 17, 2006 [Page 14] Internet-Draft IPv6 VPN based Address Format October 2005 Author's Addresses Bin Lee Huawei Technologies Hua Wei Bld.,No.3 Xinxi Rd., Shang-Di Information Industry Base Hai-Dian District Beijing P.R.China Phone: +86 10 82882987 Email: l.b@huawei.com Hongfei Chen HUAWEI Hua Wei Bld.,No.3 Xinxi Rd., Shang-Di Information Industry Base Hai-Dian District Beijing P.R.China Phone: +86 10 82882540 Email: chenhongfei@huawei.com Intellectual Property Statement 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. 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 Lee, Chen Expires April 17, 2006 [Page 15] Internet-Draft IPv6 VPN based Address Format October 2005 Disclaimer of Validity 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. Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Lee, Chen Expires April 17, 2006 [Page 16]