RFC 4084

Terminology for Describing Internet Connectivity

📅 published May 2005, from ietf

RFC 4084: Terminology for Describing Internet Connectivity 🦋✨

  • Who wrote it: J. Klensin 💅 (Network Working Group, the crew behind this doc)
  • Request for Comments number: 4084 🎀
  • Date: May 2005 📅
  • Category: Best Current Practice, filed as BCP: 104 👑
  • Obsoletes or updates anything? Nope! The header doesn't list any Obsoletes or Updates lines, so this one stands on its own 🌸

Status of This Memo 📝

Okay so this one is a Best Current Practice for the whole Internet Community, and it's basically asking everyone to talk about it and send ideas for making it better 🧚 Distribution is unlimited, so share away 💖

The Internet Society owns the copyright here, and the year is 2005 🌈

Abstract 🔥

Okay so here's the tea. As the Internet grew, a bunch of different things got sold as "Internet connectivity," and they can be wildly different in what they actually let you do. Between that, all the different options, and the fact that there's no standard vocab for any of it, people were super confused trying to figure out what they were buying 😭 This doc gives a list of terms and definitions that could help providers, consumers, and maybe regulators get clear on what kind of service is 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

1. Introduction 🌷

1.1. The Problem and the Requirement 🎀

Okay this is so real: different ISPs and other providers sell a whole bunch of stuff labeled "Internet" or "Internet access" 🙈 These products do different things, so some are a great fit for certain people and uses, and not for others. Like, a service that only gets you the Web (here, that means the part of the Internet you can reach over HTTP and HTTPS) might be perfect for someone who just wants to browse and use Web-based email 🦋 But it's not gonna work for someone who needs to download files or use email a lot. And it's even less suitable for someone who has to run servers for other users, needs virtual private network (VPN) capabilities or other secured access to a remote office, or needs to sync mail for offline use 💀

Recent and fast-changing stuff in the email world has also added extra limits on sending and receiving email 📬 Most of these came from well-meaning efforts to stop or fight unsolicited mail, and they can be applied no matter which service type you have. They're covered separately in Section 3 🧚

This document only covers the functions the service provider offers or allows. It can't cover the functions that go through and get supported by whatever equipment the user brings 🫶

The terms SHOULD, MUST, or MAY are capitalized in this document, as defined in [1]. 💖

1.2. Adoption and a Non-pejorative Terminology 🌈

Okay so these definitions are basically useless if providers and vendors don't actually want to use them 😭 The terms here are meant to be non-pejorative, even though some folks in the IETF community think a few of these connectivity models are just "broken" or "not really an Internet service" 💅 Mentioning a specific service or model here doesn't mean it's endorsed, just that it exists or might exist in the market 🍓 So the Best Current Practice in this document is all about terminology and the information that should be given to the user, not about what types of service should be offered 🔥

2. General Terminology ✨

This section lists the main IP service terms 💜 The hope is that service providers adopt these, so they can describe their services clearly to potential users or customers. These terms reflect what the provider (ISP) intends, whether that's shown in technical measures or in the terms and conditions of service. It might be possible to work around how particular implementations of these connectivity types behave, but that freedom usually isn't what the provider intends, and it probably won't keep working if the workarounds stop working 🙅‍♀️

The service terms are listed in order of ascending capability, all the way up to "full Internet connectivity" 🪜👑

  • Web connectivity. 🌸

This service gets you connected to the Web, meaning services you reach through a "Web browser" (like Firefox, Internet Explorer, Mozilla, Netscape, Lynx, or Opera), especially ones using the HTTP or HTTPS protocols 🌐 Other services are generally not supported. Specifically, 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're generally dynamic (see the discussion of dynamic addresses in Section 3 for more on this terminology and what it means) and relatively short-lived (hours or days rather than months or years) ⏳ These addresses are often announced as "dynamic" to the people who keep lists of dial-up or dynamic addresses 📋 The provider may put a filtering Web proxy on the connections, and that proxy may change and redirect URLs to sites other than the one the user originally specified or the embedded link pointed to 👀

  • Client connectivity only, without a public address. 🎀

This service gives you access to the Internet, but without support for servers or most peer-to-peer functions 💻 The IP address assigned to the customer is dynamic and typically comes from non-public address space 🔒 Servers and peer-to-peer functions are generally not supported by the network address translation (NAT) systems that come with using private addresses. (The more precise categorization of NAT types given in [2] is 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. 🫣

  • Client only, public address. 🌷

This service gives you 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's 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, either through 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. 💅

  • Firewalled Internet Connectivity. 🔥

This service gives you access to the Internet and supports most servers and most peer-to-peer functions, with one or (usually) more static public addresses 🏰 It's similar to "Full Internet Connectivity," below, and all of the qualifications and restrictions described there apply 👑 The difference is that this service puts a provider-managed "firewall" between the customer and the public Internet, typically at the customer's request and for extra cost compared to non-firewalled services 🧱 Typically, because of contractual arrangements with the customer, this may result in blocking 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 is offered as an add-on, extra-cost option on top of what would otherwise be Full Internet Connectivity 💸 What sets it apart from the models above is that any filtering or blocking is ultimately done at the customer's request, rather than being imposed as a service restriction 🫶

  • Full Internet Connectivity. 👑🌈

This service gives the user full Internet connectivity, with one or more static public addresses 💖 Dynamic addresses that are long-lived enough to make running servers practical, without highly dynamic DNS entries, are possible, as long as they aren't 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 🙌

3. Filtering or Security Issues and Terminology 🛡️✨

okay so, remember how the Introduction said people are trying to clean up junk traffic? 🧹 Things like spam, worms, viruses, and sometimes specific content. That effort has led to extra restrictions on what internet services can do and how they behave. It's giving "the rules got stricter" 💅

Honestly the biggest restrictions usually show up with Web connectivity and non-public-address services, but some current recommendations would put restrictions at every level, which is a lot ngl 😭 Some of the mail restrictions might stop you from sending outgoing mail (unless you go through the ISP's own servers for that), might stop you from using the return address you want, and might even block you from reaching your mail stored somewhere other than the provider's system with remote-access protocols like POP3 or IMAP4.

Now, users might have totally legit reasons to reach remote file services, use remote mail submission servers (or at least use their preferred email addresses from multiple locations), and get to remote mail repositories too. (Getting to those repositories is basically a must if you want to use just one address.) So it's super important that providers spill the tea on which services they offer and which filters and conditions they put in place 🫖💖

Okay, a few key email filtering issues are the real main character stuff 🎀

  • Dynamic Addresses.

A bunch of systems, including several "blacklist" systems, assume most of the unwanted email comes from systems with dynamic addresses, especially dialup and home broadband. So they try to stop those addresses from sending mail or doing other services, except through the provider systems set up for that purpose 🚫📭

There are different ways to spot dynamic addresses: providers advertising them to blacklist operators, heuristics that look at certain address ranges, and checking reverse-mapping domain names for telltale strings like dsl or dial. Sometimes, if there's no reverse-mapping DNS address at all, that's taken as a sign the address is "dynamic". (Blocking connections because of a missing reverse-mapping DNS record was a technique developed for FTP servers years ago. It turned out to have pretty high failure rates, both blocking legit connection attempts and failing to stop the shady ones 💀) Service providers SHOULD describe what they're doing in this area for both incoming and outgoing message traffic. And users should know 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 🥲

  • Non-public addresses and NATs.

The NAT systems used to map between private and public address spaces may support connections to distant mail systems for outbound and inbound mail. But the terms of service often ban using systems that weren't supplied by the connectivity provider, and they often ban running "servers" (which usually aren't precisely defined) on the client connection 🙅‍♀️

  • Outbound port filtering from the provider.

Another common move is blocking connections to servers outside the provider's control by blocking the TCP "ports" that are commonly used for messaging. Providers have totally different theories about this 🤷‍♀️ Some won't let customers reach external SMTP servers for message submission, but they do allow the mail submission protocol ([3]) with sender authentication. Others try to block every outgoing messaging-related protocol, including remote mail retrieval protocols. That's less common with public-address services than with services that depend on private addresses and NATs. If this kind of filtering is in place, 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. The idea is that this removes the need to reconfigure portable machines when they connect from a different network location. Again, that kind of diversion MUST be disclosed, especially since it can have big security and privacy implications 👀🔐

More generally, filters that block some or all mail being sent to (or submitted to) remote systems (other than through provider-supported servers), or that try to divert that traffic to their own servers, are becoming common, as discussed above. They SHOULD be disclosed 💜

4. Additional Terminology 📚💫

These extra terms aren't as basic to understanding a service as the ones above, but they're listed as bonus info a service provider might choose to share to round out those general definitions. A potential customer could use the relevant ones to build a list of specific questions to ask, for example 📝🧚

  • Version support.

Does the service include IPv4 support only, both IPv4 and IPv6 support, or IPv6 support only? 🌐

  • Authentication support.

Which technical mechanism(s) does the service use to set up and possibly authenticate connections? Examples might include unauthenticated DHCP, PPP, RADIUS, or 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 like SSH? 🕳️

  • Multicast support

Does the user machine have access to multicast packets and services? 📡

  • DNS support.

Are users required to use DNS servers provided by the service provider, or are DNS queries allowed to reach arbitrary servers? 🔍

  • IP-related services.

Are ICMP messages to and from end user sites generally blocked or permitted? Are specific functions like ping and traceroute blocked and, if so, at what point in the network? 🏓

  • Roaming support.

Does the service intentionally support IP roaming and, if so, how is that defined? For "broadband" connections, is some dialup arrangement provided for backup or for customers who are traveling? If there is one, does that arrangement have full access to mailboxes, etc.? 🧳

  • Applications services provided.

Are email services and/or Web hosting included as part of the service, and on what basis? An email services listing should say 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 one 📬

  • Use and Blocking of Outbound Applications Services.

Does the service block use of SMTP or mail submission to anything other than its own servers, or intercept those submissions and route them to its servers? Do its servers restrict users to its domain names for 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 the service takes to block, restrict, or alter the destination of outbound use of applications services (that is, use of services not supplied by the provider or not on the provider's network) 🗺️

  • Blocking of Inbound Applications Services.

Besides the 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 the provider doesn't specifically recognize) prohibited and, if so, which ones? 🚪

  • 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" content filtering, and so on 🧸

  • Wiretapping and interception.

The service SHOULD indicate whether traffic passing through it is subject to lawful intercept, and whether the provider will proactively try to tell the user about such an intercept when that notice is legal. Similar questions can be asked about traffic data stored for possible use by law enforcement 🕵️‍♀️

5. Security Considerations 🔒💀

okay real talk, this document is about terminology, not protocols, so it doesn't raise any particular security issues 🙈 BUT, and this is a big but, if the kind of terminology proposed here gets widely adopted, it may become a lot easier to figure out the security-related expectations for particular hosts, LANs, and types of connections. That's a whole vibe shift 🚨

6. Acknowledgements 🫶🌸

This document was inspired by an email conversation with Vernon Schryver, Paul Vixie, and Nathaniel Bornstein. People had been proposing definitions like this for years, but that conversation convinced the author it was finally time to put a strawman on the table and 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, which led to clarifications in the second one. Stephane Bortzmeyer, Brian Carpenter, Tony Finch, Susan Harris, David Kessens, Pekka Savola, and Vernon Schryver made very useful suggestions that were folded into later versions. Susan Harris also gave the penultimate version an exceptionally careful read, which is so appreciated, and so are the editorial suggestions from 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.

Author's Address 🦋

John C Klensin
1770 Massachusetts Ave, #322
Cambridge, MA  02140
USA

Phone: +1 617 491 5735
EMail: john-ietf@jck.com

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 ✨

okay bestie, this part is all about who owns what 💅 the IETF is basically saying "we're not picking a side on whether any patents or rights apply to the tech in this doc, and we haven't gone hunting for them either." 🫶 if you want to know how IETF handles rights stuff, go check out BCP 78 and BCP 79, that's where the rules live 📜

if you're an implementer or user and you want to see disclosures people have filed with the IETF Secretariat, or any promises of licenses, or what happened when someone tried to get a general license for these techniques, you can check the IETF online IPR repository at http://www.ietf.org/ipr 🌸

and if you think there's some copyright, patent, patent application, or other proprietary right that might cover tech you'd need to build this standard, the IETF wants to hear about it! send that info to ietf-ipr@ietf.org 💌 (no cap, that's the address, it's split across a line in the original but it's just ietf-ipr@ietf.org 🙈)

Acknowledgement 🎀

Funding for the RFC Editor function is currently provided by the Internet Society. 🌈 so the people keeping the RFC Editor running are funded by the Internet Society, which is lowkey iconic for the whole RFC world 🧚

📦 where this page comes from