PPVPN Working Group Jim Guichard Internet Draft Monique Morrow Jeff Apcar Jean Philippe Vasseur Expiration Date: September 2002 Cisco Systems Inc Yakov Rekhter Juniper Networks Inc Robin Clipsham Xavier Vinet AAPT Limited EQUANT Tazri Tayaddin Adam Grace TeleKom Malaysia Yes Optus James Spenceley B Nagaraj COMindico Australia Pty Ltd Reliance InfoCom Arthur CHEONG Boon Leong Binsar Pardede STAR Hub Pte Ltd PT Telekomunikasi Indonesia Kenji Kumaki Yuichi Ikejiri KDDI Corporation NTT Communications Corporation Y. Reina Wang Raymond Zhang Fang, Luyuan Infonet Services Corporation AT&T Labs Dr. Thomas Kuehne Lars Braeunig Arcor AG & Co. William Copeland WorldCom Address Allocation for PE-CE links within an RFC2547bis Network draft-guichard-pe-ce-addr-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months 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. Abstract This document proposes to allocate a block of globally unique IPv4 addresses for exclusive use by Service Providers that provide [L3VPN] based Services. The Service Provider may use these addresses for the provisioning of IP addresses to the links that connect customer edge (CE) routers with provider edge (PE) routers (PE-CE links). The main motivation for this proposal is to simplify the Service Providers' operations by eliminating the need for the Service Providers to acquire globally unique addresses for the links that connect Customer Edge (CE) routers with Provider Edge (PE) routers. An additional benefit of this proposal is that it conserves IPv4 address space by allowing multiple Service Providers to share the same block of IPv4 addresses for provisioning of customer links. This addressing scheme is not intended for use by VPNs that span more than a single Service Provider, unless co-operation of addressing structure is maintained to ensure uniqueness between providers. Table of Contents 1. Conventions used in this document...............................2 2. Motivation......................................................2 2.1 PE-CE Connectivity.............................................3 3. Proposal........................................................4 4. Operational Considerations......................................4 5. Security Considerations.........................................5 6. IANA Considerations.............................................5 7. Acknowledgments.................................................5 8. References......................................................5 9. Authors Addresses...............................................5 1. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119]. 2. Motivation The emergence of [L3VPN] based services internationally, and the significant experience gained from the deployment of these services, has prompted the need for an additional IP address allocation scheme. The primary use for this scheme is for the address assignment to the links that connect Customer Edge (CE) routers with Provider Edge (PE) routers (PE-CE links). 2.1 PE-CE Connectivity There are various options currently available to the Service Provider when allocating IP addresses to VPN interfaces that connect CE devices to PE devices. They may use unnumbered addressing for the PE-CE links; assign address space from their own registered (globally unique) address block; use address space from the customer address block; use private addressing as detailed in [RFC-1918]; use a unique address block (whether private or registered) which is used for ALL VPNs; or use a unique address block (whether private or registered) which is used for ALL PE routers. There are various advantages and disadvantages associated with each of the possible address allocation approaches. These can be summarized as follows: Unnumbered addressing: Pros: Conservation of IP addresses. Only 1 IP address is required instead of a /30 or /31 subnet. Cons: Undesirable for Network Management purposes, as the network management stations do not capture the management view of the PE-CE links. This means that a separate Network Management loopback interface is needed for each CE device. A further disadvantage is the requirement for an additional loopback interface on the PE router for each VRF, which may be taken from the Service Providers registered address block, or from the customer address block, or from the [RFC-1918] address block. In either case, the same set of pros and cons apply. Address space from Service Provider registered block: Pros: Does not require any coordination with customer IP address allocation, as no address conflict is likely. Addresses used for PE-CE links are unique across all the PE-CE links for all the VPNs supported by the Service Provider. Cons: The Service Provider has to obtain these addresses from one of the addressing registries. Waste of globally unique addresses for private usage. A separate /30 or /31 subnet is required for each PE-CE connection, which may result in a very high number of wasted addresses, especially when there are potentially VPNs with hundreds, if not thousands, of sites. Address space taken from the customer address block: Pros: There is no requirement for Service Provider registered addresses, and the customer is responsible for the addressing plan. No need for the Service Provider to obtain these addresses from one of the addressing registries. Cons: Requires co-ordination of addressing plan between the Service Provider and the customer. May be problematic if the customers' addresses are from the [RFC-1918] range and the Service Provider also uses [RFC-1918] address space, as there is the potential for an address overlap between the Service Provider and the customer address space. Also, if the Service Provider manages PE-CE links, then this option requires NMS used by the provider to deal with non-unique addresses. Unique address block used for ALL VPNs: Pros: Address space can be saved as the same address block is used on the PE-CE links of ALL VPNs. Cons: Potential for address conflict when merging one VPN with another as the same addresses may be used on the PE-CE links. Also, if the Service Provider manages PE-CE links, then this option requires NMS used by the provider to deal with non-unique addresses. Unique address block used for ALL PE routers: Pros: Address space can be saved as the same address block is used for each PE router in the network. This address block is used to number all the PE-CE links of that PE router, irrespective of whether these links belong to the same or different VPNs. Cons: Potential for address conflict as two PE-CE links belonging to the same VPN but attached to two different PE routers may have the same /30 or /31 subnet assigned. Also, if the Service Provider manages the PE-CE links, then this option requires NMS used by the provider to deal with non-unique addresses. 3. Proposal This document defines a block of addresses [TBD] that a Service Provider could use for PE-CE addressing, and/or for local value- added services. 4. Operational Considerations Reserved addresses for [L3VPN] based services facilitate address uniqueness for Service Providers within their own administrative domain. The uniqueness of addresses is guaranteed even if the Service Provider network consists of multiple Autonomous Systems. Overlapping of these reserved addresses between Service Providers may cause problems if a VPN client site CE router connects to two different Service Provider PE routers, and the addresses used on the PE-CE links are the same. Private addressing [RFC-1918] is still available for use within a Service Provider and customer environment but the most important benefit of a dedicated address block for PE-CE connections and local value-added services is the guarantee against address overlap between Service Provider and customer address spaces for [L3VPN] based services, as well as the guarantee that all PE-CE numbered links would have addresses that are unique within a Service Provider This benefit impacts the service cost for preventing address overlapping and reduces the complexity in doing so. For Service Providers who offer managed customer PE-CE connectivity, this proposal facilitates SP NMS operations by guaranteeing unique addressing for the managed service thus minimizing provisioning complexity attributed to administering non-unique address space. This factor is a key benefit to Service Providers who are developing and deploying managed PE-CE connections. One specific example of the benefit is that the Service Provider only requires a single Management VPN (the Service Provider can import to the VPN_Management the PE-CE address block using a route-map), the number of Management Workstations (or instances of) is greatly reduced as there is no overlap. 5. Security Considerations Security issues are not addressed in this memo. 6. IANA Considerations IANA should allocate a /8 address block for sole use by [L3VPN] Service Providers. Actual address block assignment TBD. 7. Acknowledgements 8. References [L3VPN], Rosen, E. et al., "BGP/MPLS VPNs", draft-ietf-ppvpn- rfc2547bis-01, July, 2002. [RFC-1918], Rekhter, Y. et al. "Address Allocation for Private Internets", RFC 1918, February 1996. 9. Author's Addresses Jim Guichard Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824 Email: jguichar@cisco.com Monique Jeanne Morrow Cisco Systems, Inc. Glatt-Com CH-8301, Glattzentrum, Switzerland Email: mmorrow@cisco.com Jeff Apcar Cisco Systems, Inc 201 Pacific Highway St Leonards, NSW 2068 Australia Email: japcar@cisco.com JP Vasseur Cisco Systems, Inc. 11, rue Camille Desmoulins 92782 Issy les Moulineaux Cedex 9 FRANCE Email: jpv@cisco.com Yakov Rekhter Juniper Networks, Inc. 1194 N. Mathilda Ave. Sunnyvale, CA 94089 Email: yakov@juniper.net Xavier VINET EQUANT 9 rue du Chˆne Germain - BP 80 35512 Cesson Sevigne cedex FRANCE Email : xavier.vinet@equant.com Robin Clipsham AAPT Limited 180-181 Burnley St, Richmond VIC 3121 Australia Email: rclipsham@aapt.com.au Adam Grace Yes Optus L2, 50 Miller St North Sydney NSW 2060 AUSTRALIA Email: Adam.Grace@optus.com.au B Nagaraj Reliance Infocom, Chitrakoot, Sri Ram Mills Compound, Worli, Mumbai - 400031 India Email: B_Nagaraj@ril.com Tazri Tajuddin COINS GLobal, Telekom Malaysia 2nd Floor, Ibupejabat Telekom Malaysia, Jalan Pantai Baharu, 50672 Kuala Lumpur. Email: ttazri@telekom.com.my James Spenceley COMindico Australia Pty Ltd Level 15 201 Kent St Sydney NSW 2000 Australia Email: james.spenceley@comindico.com.au Binsar Pardede PT TELEKOMUNIKASI INDONESIA, Tbk Ghra Citra Caraka 7th Fl Jl. Gatot Subroto No. 52 Jakarta 12710 Indonesia Email: binsar_p@telkom.co.id Arthur CHEONG Boon Leong StarHub Pte Ltd (Head Office) 51 Cuppage Road #07-00 StarHub Centre Singapore 229469 Email: arthurc@starhub.com.sg Yuichi Ikejiri NTT Communications Corporation 1-1-6, Uchisaiwai-cho, Chiyoda-ku Tokyo 100-8019 Japan Email: ikejiri@ntt.ocn.ne.jp Kenji Kumaki KDDI Corporation KDDI Bldg. 2-3-2, Nishishinjyuku, Shinjyuku-ku Tokyo 163-8003 Japan Email: ke-kumaki@kddi.com Y. Reina Wang AT&T Labs 200 Laurel Ave Middletown, NJ 07748 USA Email: reinawang@att.com Luyuan Fang AT&T Labs 200 Laurel Avenue Middletown, NJ 07748 USA Email: luyuanfang@att.com Raymond Zhang INFONET Services Corporation 2160 E. Grand Ave. El Segundo, CA 90245 Email: raymond_zhang@infonet.com Dr. Thomas Kuehne Lars Braeunig Arcor AG & Co. K÷lner Strasse 5 65760 Eschborn GERMANY Email: thomas.kuehne@arcor.net William Copeland WorldCom Advisory Engineer 901 International Parkway Richardson, TX 75081 Email: william.copeland@wcom.com 10. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.