What does “Internet Access” mean?

On the joint day of the the recent IESG and IAB retreats, the group discussed a number of topics related to network operator activities for encrypted flows. As part of that conversation, the group looked at RFC 4084, which tackled the question what “Internet Access” means. A dozen years on, that subject probably deserves a new look, and several of the folks at the retreat agreed to draft a new version for community review.

As one of those volunteers, I’d like to dive into RFC 4084 a bit and explore what may have changed since it was published. After walking through the need to avoid pejorative terms, the RFC sets out the following types of connectivity: web connectivity; client connectivity only with no public address; client connectivity only with a public address; firewalled Internet connectivity; and full Internet connectivity.

For those who have bought enterprise connectivity recently, it’s obvious that several common categories are missing: dark fiber, lit service connectivity to a home office, managed MPLS tunnels, and so on. More importantly, though, the RFC doesn’t really touch on cellular wireless connectivity at all, which is now one of the most common ways people connect to the Internet. That means that it doesn’t touch on topics like data caps, roaming for data services, zero rating, or data compression proxies. For cellular connectivity, those can be the key to understanding the trade-offs in connectivity, privacy, and costs for a particular service offering.

Beyond that proliferation in available offerings, there has been another major change, in the ubiquity of filtering. RFC 4084 describes filtering at the ISP level in section 3 and notes “the effort to control or limit objectionable network traffic has led to additional restrictions on the behavior and capabilities of internet services”. RFC 7754 has since provided a much more detailed description of blocking and filtering, and it highlights restricting objectionable content as a category beyond blocking objectionable traffic. That blocking may be a requirement imposed by state regulators. In those jurisdictions, what RFC 4084 described as “full Internet connectivity” has disappeared, because service providers are required to prevent their customers from reaching specific Internet resources, services, or destinations. Even where blocks are not in place, regulatory increases in the amount of Internet tracking data retained and the length of time it is kept have become common. These may contribute to self-censorship in the use of some content. Put simply, firewalled Internet connectivity has become the default offering required of service providers within those territories.

Lastly, the document describes Internet connectivity in terms that apply to the services which would be consumed by a human user and, though some social networking or streaming services are not included, it is generally useful in that regard. As we move into an era in which devices talk to other devices, we also need to examine what a service provides for traffic among devices or between devices and back-end services. Is the implication of a web-only service that the Internet of Things is not supported, or is the implication that it must be reached by a web-based gateway or proxy? The difference between those two is a serious topic of contemplation now, and the architecture of a number of services will depend on it.

In many cases, the architecture of the Internet has developed in the course of a commercial dialog between network operators’ offerings and consumers’ use. Many efforts to make cellular systems walled gardens failed, for example, because the users simply weren’t willing to use them that way and wanted the broader connectivity of the Internet. As we look at this new tension among users’ desires for confidential communication, network operators’ management practices, and regulatory frameworks, a common vocabulary for the services available to the user may help us understand what architectures we can build. If you’d like to contribute to the early discussion, architecture-discuss@iab.org is one place to start.