diff options
Diffstat (limited to 'doc/rfc/rfc4084.txt')
| -rw-r--r-- | doc/rfc/rfc4084.txt | 619 |
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc4084.txt b/doc/rfc/rfc4084.txt new file mode 100644 index 0000000..b05d189 --- /dev/null +++ b/doc/rfc/rfc4084.txt @@ -0,0 +1,619 @@ + + + + + + +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). + +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, 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. + +Table of Contents + + 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 + + + + + + + + + + +Klensin Best Current Practice [Page 1] + +RFC 4084 IP Service Terms May 2005 + + +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 (in this + context, the portion of the Internet that is accessible via the HTTP + and HTTPS protocols) may be appropriate for someone who is + exclusively interested in browsing and in Web-based email services. + It will not be appropriate for someone who needs to download files or + use email more frequently. And it is likely to be even less + appropriate for someone who needs 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. + + Recent and rapidly evolving changes to the Internet's email + environment have led to additional restrictions on sending and + retrieving email. These restrictions, most of them developed as part + of well intentioned attempts to prevent or fight unsolicited mail, + may be imposed independently of the service types described below and + are discussed separately in 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 [1]. + +1.2. Adoption and a Non-pejorative Terminology + + The definitions proposed here are of little value if service + providers and vendors are not willing to adopt them. The terms + proposed are intended not to be pejorative, despite the belief of + some members of the IETF community that some of these connectivity + models are simply "broken" or "not really an Internet service". The + mention of a particular service or model in this document does not + imply any endorsement of it, only recognition of something that + exists or might exist in the marketplace. Thus, the Best Current + Practice described in this document is about terminology and + information that should be supplied to the user and not about the + types of service that should be offered. + + + + +Klensin Best Current Practice [Page 2] + +RFC 4084 IP Service Terms May 2005 + + +2. General Terminology + + This section lists the primary IP service terms. It is hoped that + service providers will adopt these terms, to better define the + services to potential users or customers. The terms refer to the + intent of the provider (ISP), as expressed in either technical + measures or terms and conditions of service. It may be possible to + work around particular implementations of these characteristic + connectivity types, but that freedom is generally not the intent of + the provider and is unlikely to be supported if the workarounds stop + working. + + The service terms are listed in order of ascending capability, to + reach "full Internet connectivity". + + o Web connectivity. + + This service provides connectivity to the Web, i.e., to services + supported through a "Web browser" (such as Firefox, Internet + Explorer, Mozilla, Netscape, Lynx, or Opera), particularly those + services using the HTTP or HTTPS protocols. Other services are + generally not supported. In particular, there may be no access to + POP3 or IMAP4 email, encrypted tunnels or other VPN mechanisms. + + The addresses used may be private and/or not globally reachable. + They are generally dynamic (see the discussion of dynamic + addresses 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 [2] are + somewhat orthogonal to this document, but they may be provided as + additional terms, as described in Section 4.) + + + + + +Klensin Best Current Practice [Page 3] + +RFC 4084 IP Service Terms May 2005 + + + 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. + + + +Klensin Best Current Practice [Page 4] + +RFC 4084 IP Service Terms May 2005 + + + 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. + +3. Filtering or Security Issues and Terminology + + As mentioned in the Introduction, the effort to control or limit + objectionable network traffic has led to additional restrictions on + the behavior and capabilities of internet services. Such + objectionable traffic may include unsolicited mail of various types + (including "spam"), worms, viruses, and their impact, and in some + cases, specific content. + + In general, significant restrictions are most likely to be + encountered with Web connectivity and non-public-address services, + but some current recommendations would apply restrictions at all + levels. Some of these mail restrictions may prevent sending outgoing + mail (except through servers operated by the ISP for that purpose), + may prevent use of return addresses of the user's choice, and may + even prevent access to mail repositories (other than those supplied + by the provider) by remote-access protocols such as POP3 or IMAP4. + Because users may have legitimate reasons to access remote file + services, remote mail submission servers (or, at least, to use their + preferred email addresses from multiple locations), and to access + remote mail repositories (again, a near-requirement if a single + address is to be used), it is important that providers disclose the + services they are making available and the filters and conditions + they are imposing. + + Several key issues in email filtering are of particular importance. + + o Dynamic Addresses. + + A number of systems, including several "blacklist" systems, are + based on the assumption that most undesired email originates from + systems with dynamic addresses, especially dialup and home + broadband systems. Consequently, they attempt to prevent the + addresses from being used to send mail, or perform some other + services, except through provider systems designated for that + purpose. + + Different techniques are used to identify systems with dynamic + addresses, including provider advertising of such addresses to + blacklist operators, heuristics that utilize certain address + ranges, and inspection of reverse-mapping domain names to see if + + + +Klensin Best Current Practice [Page 5] + +RFC 4084 IP Service Terms May 2005 + + + 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 ([3]) 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. + + + + + + +Klensin Best Current Practice [Page 6] + +RFC 4084 IP Service Terms May 2005 + + + 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. + +4. Additional Terminology + + These additional terms, while not as basic to understanding a service + offering as the ones identified above, are listed as additional + information that a service provider might choose to provide to + complement those general definitions. A potential customer might use + those that are relevant to construct a list of specific questions to + ask, for example. + + o Version support. + + Does the service include IPv4 support only, both IPv4 and IPv6 + support, or IPv6 support only? + + o Authentication support. + + Which technical mechanism(s) are used by the service to establish + and possibly authenticate connections? Examples might include + unauthenticated DHCP, PPP, RADIUS, or HTTP interception. + + o 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? + + o Multicast support + + Does the user machine have access to multicast packets and + services? + + o DNS support. + + Are users required to utilize DNS servers provided by the service + provider, or are DNS queries permitted to reach arbitrary servers? + + o 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? + + + + +Klensin Best Current Practice [Page 7] + +RFC 4084 IP Service Terms May 2005 + + + 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 + + + + +Klensin Best Current Practice [Page 8] + +RFC 4084 IP Service Terms May 2005 + + + 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. + +5. Security Considerations + + This document is about terminology, not protocols, so it 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. + +6. Acknowledgements + + This document was inspired by an email conversation with Vernon + Schryver, Paul Vixie, and Nathaniel Bornstein. While there have been + proposals to produce such definitions for many years, that + conversation convinced the author that it was finally time to put 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 and Stephane + Bortzmeyer, Brian Carpenter, Tony Finch, Susan Harris, David Kessens, + Pekka Savola, and Vernon Schryver made very useful suggestions that + were incorporated into subsequent versions. Susan Harris also gave + the penultimate version an exceptionally careful reading, which is + greatly appreciated, as are editorial suggestions by the RFC Editor. + +7. Informative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [2] Srisuresh, P. and M. Holdrege, "IP Network Address Translator + (NAT) Terminology and Considerations", RFC 2663, August 1999. + + [3] Gellens, R. and J. Klensin, "Message Submission", RFC 2476, + December 1998. + + + + + + +Klensin Best Current Practice [Page 9] + +RFC 4084 IP Service Terms May 2005 + + +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 Best Current Practice [Page 10] + +RFC 4084 IP Service Terms May 2005 + + +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- + ipr@ietf.org. + + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + +Klensin Best Current Practice [Page 11] + |