Network Working Group J. Klensin Request for Comments: 4084 May 2005 BCP: 104 Category: Best Current Practice Terminology for Describing Internet Connectivity Status of This Memo This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2005).
AbstractAs 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, the effort to distinguish between these services has caused 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. 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. The Problem and the Requirement . . . . . . . . . . . . 2 1.2. Adoption and a Non-pejorative Terminology . . . . . . . 2 2. General Terminology . . . . . . . . . . . . . . . . . . . . . 3 3. Filtering or Security Issues and Terminology . . . . . . . . . 5 4. Additional Terminology . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 7. Informative References . . . . . . . . . . . . . . . . . . . . 9
Section 3. This 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. The terms SHOULD, MUST, or MAY are capitalized in this document, as defined in .
Section 3 for further discussion of this terminology and its implications) and relatively short-lived (hours or days rather than months or years). These addresses are often announced as "dynamic" to those who keep lists of dial-up or dynamic addresses. 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. o Client connectivity only, without a public address. This service provides access to the Internet without support for servers or most peer-to-peer functions. The IP address assigned to the customer is dynamic and is characteristically assigned from non-public address space. Servers and peer-to-peer functions are generally not supported by the network address translation (NAT) systems that are required by the use of private addresses. (The more precise categorization of types of NATs given in  are somewhat orthogonal to this document, but they may be provided as additional terms, as described in Section 4.)
Filtering Web proxies are common with this type of service, and the provider SHOULD indicate whether or not one is present. o Client only, public address. This service provides access to the Internet without support for servers or most peer-to-peer functions. The IP address assigned to the customer is in the public address space. It is usually nominally dynamic or otherwise subject to change, but it may not change for months at a time. Most VPN and similar connections will work with this service. The provider may prohibit the use of server functions by either legal (contractual) restrictions or by filtering incoming connection attempts. Filtering Web proxies are uncommon with this type of service, and the provider SHOULD indicate if one is present. o Firewalled Internet Connectivity. This service provides access to the Internet and supports most servers and most peer-to-peer functions, with one or (usually) more static public addresses. It is similar to "Full Internet Connectivity", below, and all of the qualifications and restrictions described there apply. However, this service places a provider-managed "firewall" between the customer and the public Internet, typically at customer request and at extra cost compared to non-firewalled services. Typically by contractual arrangements with the customer, this may result in blocking of some services. Other services may be intercepted by proxies, content-filtering arrangements, or application gateways. The provider SHOULD specify which services are blocked and which are intercepted or altered in other ways. In most areas, this service arrangement is offered as an add-on, extra-cost, option with what would otherwise be Full Internet Connectivity. It is distinguished from the models above by the fact that any filtering or blocking services are ultimately performed at customer request, rather than being imposed as service restrictions. o Full Internet Connectivity. This service provides the user full Internet connectivity, with one or more static public addresses. Dynamic addresses that are long-lived enough to make operating servers practical without highly dynamic DNS entries are possible, provided that they are not characterized as "dynamic" to third parties.
Filtering Web proxies, interception proxies, NAT, and other provider-imposed restrictions on inbound or outbound ports and traffic are incompatible with this type of service. Servers on a connected customer LAN are typically considered normal. The only compatible restrictions are bandwidth limitations and prohibitions against network abuse or illegal activities.
they contain telltale strings such as "dsl" or "dial". In some cases, the absence of a reverse-mapping DNS address is taken as an indication that the address is "dynamic". (Prohibition on connections based on the absence of a reverse-mapping DNS record was a technique developed for FTP servers many years ago; it was found to have fairly high rates of failure, both prohibiting legitimate connection attempts and failing to prevent illegitimate ones). Service providers SHOULD describe what they are doing in this area for both incoming and outgoing message traffic, and users should be aware that, if an address is advertised as "dynamic", it may be impossible to use it to send mail to an arbitrary system even if Full Internet Connectivity is otherwise provided. o Non-public addresses and NATs. The NAT systems that are used to map between private and public address spaces may support connections to distant mail systems for outbound and inbound mail, but terms of service often prohibit the use of systems not supplied by the connectivity provider and prohibit the operation of "servers" (typically not precisely defined) on the client connection. o Outbound port filtering from the provider. Another common technique involves blocking connections to servers outside the provider's control by blocking TCP "ports" that are commonly used for messaging functions. Different providers have different theories about this. Some prohibit their customers from accessing external SMTP servers for message submission, but they permit the use of the mail submission protocol () with sender authentication. Others try to block all outgoing messaging- related protocols, including remote mail retrieval protocols; however, this is less common with public-address services than those that are dependent on private addresses and NATs. If this type of filtering is present, especially with "Client only, public address" and "Full Internet Connectivity" services, the provider MUST indicate that fact (see also Section 4). Still others may divert (reroute) outbound email traffic to their own servers, on the theory that this eliminates the need for reconfiguring portable machines as they connect from a different network location. Again, such diversion MUST be disclosed, especially since it can have significant security and privacy implications.
More generally, filters that block some or all mail being sent to (or submitted to) remote systems (other than via provider- supported servers), or that attempt to divert that traffic to their own servers, are, as discussed above, becoming common and SHOULD be disclosed.
o Roaming support. Does the service intentionally include support for IP roaming and, if so, how is this defined? For "broadband" connections, is some dialup arrangement provided for either backup or customer travel? If present, does that arrangement have full access to mailboxes, etc. o Applications services provided. Are email services and/or Web hosting provided as part of the service, and on what basis? An email services listing should identify whether POP3, IMAP4, or Web access are provided and in what combinations, and what types of authentication and privacy services are supported or required for each. o Use and Blocking of Outbound Applications Services. Does the service block use of SMTP or mail submission to other than its own servers or intercept such submissions and route them to its servers? Do its servers restrict the user to use of its domain names on outbound email? (For email specifically, also see Section 3 above.) Is the FTP PASV command supported or blocked? Are blocks or intercepts imposed on other file sharing or file transfer mechanisms, on conferencing applications, or on private applications services? More generally, the provider should identify any actions of the service to block, restrict, or alter the destination of, the outbound use (i.e., the use of services not supplied by the provider or on the provider's network) of applications services. o Blocking of Inbound Applications Services. In addition to issues raised by dynamic or private address space (when present), does the service take any other measures that specifically restrict the connections that can be made to equipment operated by the customer? Specifically, are inbound SMTP, HTTP or HTTPS, FTP, or various peer-to-peer or other connections (possibly including applications not specifically recognized by the provider) prohibited and, if so, which ones? o Application Content Filtering. The service should declare whether it provides filtering or protection against worms or denial of service attacks against its customers, virus and spam filtering for its mail services (if
any), non-discretionary or "parental control" filtering of content, and so on. o Wiretapping and interception. The service SHOULD indicate whether traffic passing through it is subject to lawful intercept, and whether the provider will make a proactive attempt to inform the user of such an intercept when such notice is legal. Analogous questions can be asked for traffic data that is stored for possible use by law enforcement.  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.  Gellens, R. and J. Klensin, "Message Submission", RFC 2476, December 1998.
Full 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. 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. Intellectual Property 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- email@example.com. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.