PPVPN Working Group Tissa Senevirathne Internet Draft Document: draft-tsenevir-vpn-addr-arch-00.txt Category: Informational August 2002 An Addressing Architecture for virtual Private Network Identifier Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. For potential updates to the above required-text see: http://www.ietf.org/ietf/1id-guidelines.txt Placement of This Memo in Sub-IP Area RELATED DOCUMENTS: See the reference WHERE DOES IT FIT IN THE PICTURE OF THE SUB-IP WORK PPVPN WHY IS IT TARGETED AT THIS WG PPVPN WG charter specifies inter-AS VPN services. Globally unique, structured VPN identifiers are important element of inetr-AS VPN services. JUSTIFICATION As VPN technology matures, a VPN services can either VPRN, VPLS, VPWS or some other future class. The VPN services now has a global reach, spanning multiple service providers. Having a well define Senevirathne Informational û Expiration February 2003 1 draft-tsenevir-vpn-addr-arch-00.txt August 2002 addressing architecture facilitates, management and administration of VPN services Abstract In this document we present an addressing architecture for VPN Identifier. Addressing Architecture presented in this document allows to identify VPN in globally unique manner. It introduces a non overlapping address space for different classes of VPN (L3 VPN, VPLS etc..). The addressing architecture presented in this document allow to identify attributes of the VPN as part of the VPN identifier through an embedded attribute field. Senevirathne Informational û Expiration February 2003 2 draft-tsenevir-vpn-addr-arch-00.txt August 2002 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]. 1. Introduction Only standard method of VPN addressing available is RFC 2685 [3]. RFC 2685 use 3byte OUI field and 4 byte index field. Thus making it 7 byte field. The non 32-bit aligned nature of RFC 2685 poses many challenges to implementers as well as protocol designers. In RFC 2685 there is no standard method to identify the class of the given VPN (i.e.: L3 VPN or l2 VPN etc..). Attributes of the VPN are considered as a separate process. This introduces special challenges to VPN discovery methods. VPN discovery methods try to address this by discovery method specific attributes. However, if the characteristics (class) and attributes of the VPN was part of the address, VPN discovery methods becomes simpler. In fact VPN discovery becomes some what closer to routing protocols. As a result user may select to use multiple discovery methods in combination. Mutually exclusive address spaces for different classes of VPN allow easy administration. On the other hand one may easily filter unwanted classes of VPN using simple policies. This may be attractive if global VPN discovery method in use. 2. Requirement for VPN addressing Architecture . Mutually exclusive address space for VPN classes(L3,L2..) . Address space for private VPN addresses . Address space for official addresses allocated by addressing authority. . Ability to encode VPN attribute such as underlying tunnel method as part of the address. . Format and the size of VPN identifier should be implementation and algorithm friendly. (e.g. in a 32 bit machine 32 or 64 bit aligned numbers can be handled much more efficiently than 56 bit number) 2.1 Mutually exclusive address space for VPN classes Mutually exclusive address space for each VPN class allow Providers to easily manage the VPN services. This is specially true when the provider is involved providing more than one class of VPN. On the other hand, Mutually exclusive address space lead to simpler VPN discovery methods. Presently most VPN discovery methods would Senevirathne Informational û Expiration February 2003 3 draft-tsenevir-vpn-addr-arch-00.txt August 2002 use discovery method specific attributes to identify the class of the VPN (ie:L3, L2 etc..). Some discovery methods may not have methods to identify such differences. Presence of mutually exclusive address space facilitate PE devices to clearly identify the class of a given VPN. 2.2 Address space for private VPN addresses Clearly identified VPN address space for private addresses allow easier management of VPN that are locally visible. Also this facilitate more efficient usage of official VPN addresses. (This is more like 10.x.x.x address space) 2.3 Address space for official addresses allocated by addressing authority Official address space is administered by an Addressing authority. Uniqueness of the address is ensured by the authority. Globally unique VPN address facilitate inter provider VPN services. 2.4 Ability to encode VPN attribute such as underlying tunnel method as part of the address. In a unique address there may be site specific information that may be useful to distribute and discover. As an example, use MPLS as a tunneling protocol may be specific to one originating PE site. In another words semantics of the 32 bit integer distributed can be easily derived from the attribute field of the VPN address. Or after a VPN end point discovery appropriate signaling may be initiated based on the information derived. 2.4 Format and size of VPN identifier Format and size of the VPN identifier MUST not adversely affect the efficiency search and algorithmic implementations. Any address that is either 32 or 64 bit aligned can be processed efficiently by most general purpose processors. RFC 2685 proposes a 56 bit value as the VPN Identifier. Such non 32 bit aligned number lead to inefficient algorithms. Senevirathne Informational û Expiration February 2003 4 draft-tsenevir-vpn-addr-arch-00.txt August 2002 3. Addressing Model Based on the above requirements we propose following address model for VPN addressing |<------------------------- 64 ------------------------------>| |<-----8------> | | | |<-- 7 --- >|<--- 8 --->|<------------48 ---------------->| +-------------------------------------------------------------+ |S | Class | Attribute | Address | +-------------------------------------------------------------+ S -- Scope 0 - Centrally administered , Globally unique VPN 1 - Locally Administered VPN Class -- 0 - Default (Local policy MAY derive the appropriate class) 1 - L3 VPN 2 - VPLS 3 - VPWS 4-127 - unused Attribute - Site specific attribute 0 - Default (Local policy MAY derive the appropriate tunnel type) 1 - MPLS Tunnels 2 - GRE Tunnels 3 - L2TP Tunnels 4 - IPsec Tunnels 5-255 û- unused 3.1 Possible variations to the proposed model It is possible to define Scope as two bits and one of the bits MAY indicate either scope;class;attribute;address structure is used or scope;address structure is used. This allows have significantly larger VPN addressing space. However, absence of class and attribute may negate some of the requirements we set forth. 4. Textual Representation of VPN addresses We propose to a textual representation similar to Ipv6 RFC 2373 [4]. An VPN address is may be represented as 16bit hexa decimal numbers separated by semicolon (:). E.g.: 8000:4000:0000:0001 Zeros may be eliminated using similar method as in RFC 2373 [4]. E.g.: 8000:4::1 5. Security Considerations Senevirathne Informational û Expiration February 2003 5 draft-tsenevir-vpn-addr-arch-00.txt August 2002 A complete security analysis of the proposed Addressing architecture has not yet been performed. 6. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 3 Fox, B. et.al Virtual Private Network Identifier, RFC 2685, September 1999 4 Hinden, R. et.al, IP Version 6 Addressing Architecture, RFC 2373, Julyb1998 7. Acknowledgments Mark Townsley provided extensive comments. His specific comments lead to Appendix A, entitled DevilÆs questions. 8. Author's Addresses Tissa Senevirathne 1567 Belleville Way, Sunnyvale, CA 94087 Phone: 408-245-5897 Email: tsenevir@hotmail.com Senevirathne Informational û Expiration February 2003 6 draft-tsenevir-vpn-addr-arch-00.txt August 2002 Appendix A: DevilÆs Questions Question : Someone might tell you that you are reinventing IP(v7?) addressing :-) Answer : Actually I proposing an alternative to RFC2685 for VPN addressing, RFC 2685 in my opinion is useless Question: Can't wait until someone proposes a VPN Address NAT on you ;-) Answer: :):) Actually it is possible, with the attribute field. Question: Seriously, I do thing that everyone's VPN life would be easier if there were a global address pool to tap. However, such a proposal does not come without serious management over head. Take a look at the resources necessary to manage the global IP address pool. Who will be the central assignment authority for VPN addresses? Who will run the root server to manage them? Will you include a DNS system to resolve the addresses? Answer : Juha is thinking of DNS based VPN discovery if that takeoff (most likely). Suddenly we are now looking of global VPN participation. Which essentially need to be unique. In addition global VPN administration may open new business opportunities. Question: Just unique within the set of folks participating in the discovery targeted at a given server. DNS Doesn't *have* to be global. Answer: If the DNS participants are limited, local address management is feasible. However, when the number of participants grow, having a centralized management helps. Question: That's just what we need, more for ICANN to do ;-) Answer : if you agree with me on my previous answer, global VPN administration is a small price to pay. Full Copyright Statement "Copyright (C) The Internet Society (2002). 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 Senevirathne Informational û Expiration February 2003 7 draft-tsenevir-vpn-addr-arch-00.txt August 2002 copyrights defined in the Internet Standards process must be followed, or as required to translate it into Senevirathne Informational û Expiration February 2003 8