Network Working Group J. Klensin Internet-Draft March 16, 2004 Expires: September 14, 2004 Terminology for Describing Internet Connectivivy draft-klensin-ip-service-terms-00.txt 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, and any of which I become aware will be disclosed, in accordance with RFC 3667. 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 September 14, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract As the Internet has evolved, many types of arrangements have been advertised and sold as "Internet connectivity". Because these may differ significantly in the capabilities they offer, the range of options, and the lack of any standard terminology, has cause considerable consumer confusion. This document provides a list of terms and definitions that may be helpful to providers, consumers, and, potentially, regulators in clarifying the type and character of services being offered. Klensin Expires September 14, 2004 [Page 1] Internet-Draft IP Service Terms March 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 The Problem and the Requirement . . . . . . . . . . . . . . . 3 1.2 Adoption and a Non-pejorative Terminology . . . . . . . . . . 3 1.3 Next Steps . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Security Considerations . . . . . . . . . . . . . . . . . . . 4 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 5 Intellectual Property and Copyright Statements . . . . . . . . 6 Klensin Expires September 14, 2004 [Page 2] Internet-Draft IP Service Terms March 2004 1. Introduction 1.1 The Problem and the Requirement Different ISPs and other providers offer a wide variety of products that are identified as "Internet" or "Internet access". These products offer different types of functionality and, as a result, some may be appropriate for certain users and uses and not others. For example, a service that offers only access to the Web, but that does not support any other type of Internet services, may be entirely appropriate for someone who is exclusively interested in browsing and in web-based email servcies, but not for someone who who requires access to download files or make more intense use of email. And it is likely to be even less appropriate for someone who requires the ability to operate servers for other users, who needs virtual private network (VPN) capabilities or other secured access to a remote office, or who needs to synchronize mail for offline use. This document is a first attempt at establishing some definitions for these various services. It is hoped that the definitions will evolve into ones that can be standardized and and adopted widely enough to be useful to users and consumers. 1.2 Adoption and a Non-pejorative Terminology The definitions proposed here are clearly of little value if service providers and vendors are not willing to adopt them. Consequently, the terms proposed are intended to not be pejorative, despite the belief of some members of the IETF community that some of these connectively models are simply "broken" or "not really an Internet service". 1.3 Next Steps This document is a first cut. For these definitions to be useful, considerable input from the IETF community, suggestions for additional terms, and better definitions will be required. The document assumes that a single set of terms will be adequate and that a more complex arrangement --e.g., a matrix or array that contrasts a service type with address availability, presence or absence of NATs, etc.-- is not needed. If something more complex _is_ needed, someone should propose it, although this author is very skeptical about the possibility of getting acceptance for a complex, multidimensional scheme. This version of the document ignores the availability of IPv6 connectivity, both to avoid additional complexity and because IPv6 is not significant today in the markets for which the document is most Klensin Expires September 14, 2004 [Page 3] Internet-Draft IP Service Terms March 2004 relevant. 2. Terminology Terms are listed below more or less in order of ascending (to "full Internet") capability. Web connectivity. This service provides connectivity to the web only. Other services are generally not supported. In particular, there may be no access to POP3 or IMAP email, encrypted tunnels or other VPN mechanisms, etc. The addresses used are generally dynamic, and may not be public. The provider may impose a filtering web proxy on the connections; that proxy may change and redirect URLs to other sites than the one originally specified by the user or embedded link. Client only, non-public address. This service provides access to the Internet without support for server or peer to peer functions. The IP address assigned to the customer will almost always be dynamic and will not represent public address space. Filtering web proxies are common with this type of service, but the provider should indicate whether or not one is present. Client only, public address. This service provides access to the Internet without support for server or peer to peer functions. The IP address assigned to the customer will often be dynamic but is in public address space. Most VPN and similar connections will work with this service, although the provider may prohibit the use of server functions by either legal (contractual) restrictions or by filtering of incoming connection attempts. Filtering web proxies are uncommon with this type of service, and the provider should indicate if one is present. Similarly, while filters on, e.g., use of remote mail servers are uncommon with this type of service, they do occur and their presence should be identified to the user. Full Internet Connectivity. This service provides the user full Internet connectivity, with one or more static (or long-lived dynamic) public addresses assigned to the user. Filtering web proxies and other restrictions on inbound or outbound ports and traffic are usually considered incompatible with this type of service and servers on a connected customer LAN are typically considered normal. 3. Security Considerations This document is about terminology, not protocols, and does not raise any particular security issues. However, if the type of terminology Klensin Expires September 14, 2004 [Page 4] Internet-Draft IP Service Terms March 2004 that is proposed is widely adopted, it may become easier to identify security-related expectations of particular hosts, LANs, and types of connections 4. Acknowledgements This document was inspired by an email conversation with Vernon Schryver, Paul Vixie, and Nathaniel Bornstein. While there have been proposals to produce definitions like the ones above for many years, that conversation convinced the author that it was finally time to get a strawman on the table to see if the IETF could actually carry it forward. Author's Address John C Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA Phone: +1 617 491 5735 EMail: john-ietf@jck.com Klensin Expires September 14, 2004 [Page 5] Internet-Draft IP Service Terms March 2004 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 IETF's procedures with respect to rights in IETF 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. 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 (2004). 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. Klensin Expires September 14, 2004 [Page 6]