Network Working Group J. Klensin
Internet-Draft May 23, 2004
Expires: November 21, 2004
Terminology for Describing Internet Connectivity
draft-klensin-ip-service-terms-01.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 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 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 November 21, 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 November 21, 2004 [Page 1]
Internet-Draft IP Service Terms May 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Security Considerations . . . . . . . . . . . . . . . . . . . 6
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6
Intellectual Property and Copyright Statements . . . . . . . . 7
Klensin Expires November 21, 2004 [Page 2]
Internet-Draft IP Service Terms May 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 services, but not for someone 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.
Of course, the document describes only the functions provided or
permitted by the service provider. It does not, and cannot, specify
the functions that pass through and are supported by various
user-provided equipment.
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 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 subsection is to be dropped or moved (presumably in modified
form) to an appendix before final publication.]]
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,
Klensin Expires November 21, 2004 [Page 3]
Internet-Draft IP Service Terms May 2004
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.
Comments on the initial draft of this document suggest that the
observation above bears repeating and some expansion. It is easy to
come up with cases which the terms suggested do not provide adequate
differentiation. Some ISPs try to block VPNs in conjunction with
their "client only" services, others do not. In some parts of the
world, interception and reinterpretation of DNS queries is common, in
others it is quite rare. Those factors, and others, suggest that the
simple list below could easily be expanded into a matrix or
multidimensional array of features. That type of list might be
useful for people writing commercial procurement specifications, but
it would not be useful for the "what is being advertised and what are
you likely to get" goal of this document. For this specification,
anything more complex than a simple list is almost certain to be
unusable.
Specifically, the following distinctions have been suggested, but
have so far been resisted by the author as adding excessive
complication. They are listed both for further consideration and to
illustrate how easily things can become complicated. Input from the
community is, of course, desired.
Version support. The service should declare that it includes IPv4
support only, both IPv4 and IPv6 support, or IPv6 support only.
Authentication support. The service should declare which technical
mechanism(s) it uses to establish and possibly authenticate
connections - such as unauthenticated DHCP, PPP, RADIUS, HTTP
interception...
VPNs and Tunnels. Is IPSec blocked or permitted? Are other
tunneling techniques at the IP layer or below, such as L2TP,
permitted? Is there any attempt to block applications-layer
tunnel mechanisms such as SSH?
DNS support. Are users required to utilize DNS servers provided by
the service provider, or are DNS queries permitted to reach
arbitrary servers?
IP-related services. Are ICMP messages to and from end user sites
generally blocked or permitted? Are specific functions such as
ping and traceroute blocked and, if so, at what point in the
network?
Roaming support. The service should declare whether or not it
supports IP roaming. And, for "broadband" connections, whether
some dialup arrangement is supported for either backup or customer
travel and whether that arrangement has full access to mailboxes,
etc.
Klensin Expires November 21, 2004 [Page 4]
Internet-Draft IP Service Terms May 2004
Applications services. The service should identify whether it
provides email services and/or web hosting, and on what basis. An
email services listing should identify whether POP3, IMAP, or web
access are provided and in what combinations and what types of
authentication and privacy services are supported or required for
each. Is FTP PASV supported or blocked?
Filtering. The service should declare whether it provides filtering
or protection against worms or denial of service attacks against
its customers, virus and UCE filtering for its mail services (if
any), non-discretionary or "parental control" filtering of
content, and so on.
Wiretapping and interception. The service should indicate whether
traffic passing through it is subject to lawful intercept with or
without notice? Is traffic data stored for possible use by law
enforcement with or without notice?
2. Terminology
Terms are listed below more or less in order of ascending (to "full
Internet") capability. In each case, the terminology refers to the
intent of the provider (ISP) as expressed in either technical
measures or terms and conditions of service. It may be possible to
do some additional things with particular implementations of these
characteristic connectivity types, but those flexibilities are
generally not the intent of the provider and are unlikely to be
supported if the workarounds stop working.
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 most 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 most 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
Klensin Expires November 21, 2004 [Page 5]
Internet-Draft IP Service Terms May 2004
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
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. Harald Alvestrand, Brian Carpenter, George Michaelson,
Vernon Schryver, and others made several suggestions on the initial
draft that resulted in clarifications to the second one.
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 November 21, 2004 [Page 6]
Internet-Draft IP Service Terms May 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 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.
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 November 21, 2004 [Page 7]
