Named Based Virtual Hosting

Access networks connect end-user devices, such as computers, smartphones and tablets, to a wide area network (WAN), such as the internet. Such networks can save IPv4 addresses by sharing a unique address among many users. This is commonly known as Network Address Translation or NAT. It is one of the ways networks connect more users than they have addresses. NAT manages this feat by mapping the addresses inside a private network to a single public IP address and translating internal and external addresses on the fly.

But access networks are only part of the picture. User access is temporary and intermittent. Websites are usually available 24/7 and many have constant, heavy use where latency is frequently an issue. So, web hosting companies also need addresses for websites that have entirely different requirements from those needed for end users.

Tim Berners-Lee developed the foundations of the web at CERN in 1989. At the time, there was no concern about IPv4 depletion, so the protocol, HTTP/1.0 used one IPv4 address for each domain name, like home.cern.

One IPv4 Address per Website

This original design of name-based website domains – to map one name to a single IP address – made the process quite straightforward. DNS services distributed throughout the system executed the translation from one to the other so people could use words, not numbers in locating a website.

In the early days of internet access, dial-up was all that was available to most users. People would connect, collect and send mail, then disconnect to save money on phone charges. Buying a domain name and hosting it on a dedicated server was too expensive for most people.

And most people were connecting to the internet for fun, not to achieve a business goal. If they wanted to publish something, it was because they had something to say and not because they needed to establish a brand.

When market differentiation based on dial-up speed was hard, ISPs tried it with packages of services. These included access to Usenet, an early form of group discussion, and web hosting.

In 1996, Demon Internet, a popular ISP in the UK, started including web hosting in the bundle for its dial-up users. It dubbed this its homepages service and used account names in the URL that was included with its service. So, a user whose dial-up account was “example” could have www.example.demon.co.uk for their website. This structure was to set up a subdomain for the individual user’s website. This meant that Demon needed one IPv4 address for each site it hosted.

A similar but critically different service could have been provided by establishing a directory for the website, like this: www.demon.co.uk/example. Geocities used this solution. Because Geocities, and similar services, put account names in the directory path, they did not need one IPv4 address per customer.      

The clear issue at hand was the need for one IPv4 address per website if a simple, direct name-based system was to go into heavy use. This realization coincided with the suspected shortage of these very addresses.

Internet engineers had started to realize that IPv4 would run out by 1992. In fact, they had thought the runout would happen by 1995. Instead, networks had started other moves towards reducing demand for IPv4 addresses, including:

• Classless Inter-Domain Routing (CIDR).
• Dynamic dial-up, where your IPv4 address changed each time you dialed up, instead of one address per user.
• Network Address Translation (NAT).

An IPv4 address for each of its dial-up users’ bundled sites was seen as extravagant by some.

Changing Policy and Protocols

By 2000, technology had advanced. A new version of HTTP, the protocol for website access, had been agreed: HTTP/1.1. This upgrade to HTTP/1.0 supported name-based virtual hosting. That meant that multiple domain names could be hosted on a single IPv4 address.

This innovation was spurred by the growth in website hosting. There were about 16,000 domain names registered in 1992 but almost 27 million by the end of 2000. Most domain names have a website. Had this trend continued without name based-virtual hosting being developed and supported, the central pool of IPv4 addresses would have been depleted years earlier.

While HTTP/1.1 as a protocol supported name-based virtual hosting, it needed two groups of people to deploy it before it could have much impact. First, the hosting operators needed to upgrade their web hosting software. Then, the users needed browsers that supported it. But this was at a time where web browsers were distributed on disks and CD-ROMs because dial-up speeds were too slow to download regular upgrades. The upgrade cycle for user software was slow.

Netscape Communicator Complete 4.7, published at the Internet Archive by wossman.

But that wasn’t all. Any site doing things like processing card payments would need a unique IPv4 address because the certificates used for secure, HTTPS connections required a unique IPv4 address.

And the web wasn’t just the web. FTP, the File Transfer Protocol, was still an important way of distributing files. Each FTP site needed its own IP address. It’s only in the last couple of years that major browsers have removed support for FTP.

A computer logging into an FTP server and transferring a file, Brent Jones, CC BY-SA 3.0

Slow, Incremental Improvement

As recently as 2002, RIPE’s policy merely “strongly encouraged” name-based virtual hosting. HTTPS was the major barrier. Web commerce was growing and people were starting to recognize the need to use HTTPS when sharing usernames and passwords on the web.

HTTP/1.1 helped but it hadn’t solved the problem. The engineers needed to improve Transport Layer Security (TLS), the protocol that encrypts internet communication for the web, email, instant messaging and more. That came in 2003 when Server Name Indication (SNI) was developed to let the server know the DNS name of the server the client wanted to communicate with. One IPv4 address per HTTPS site was no longer necessary. A web server could host hundreds of sites, each with their own TLS certificate, on a single IPv4 address.

This was a gamechanger. But the browser vendors had to support it and the IT departments running fleets of computers had to upgrade their web browsers.

Internet Explorer on Windows XP never supported SNI. Internet Explorer had more than half of the browser market until 2011. Even in 2014, the year support for Windows XP ended, as many as four percent of users were reported as using Internet Explorer on Windows XP.

The last of the top-level IPv4 allocations were made in February 2011. That event triggered soft landing policies that reduced the amount of IPv4 space networks could get. That started to make providing support for older browsers more expensive.

Change is Faster Now

Independent web hosting providers still exist. But a huge part of the market uses Content Delivery Networks (CDN) now. They take the website as close as possible to its users. The content owner publishes on a server that only the CDN knows about, with the CDN doing everything else.

CDNs have developed a technology called Encrypted Client Hello (ECH). It hides the DNS name inside the encrypted session with the CDN. In combination with the encrypted DNS services CDNs operate, this could mean that network administrators cannot see which websites their users are visiting.

That’s a challenge for corporate and educational environments. There are ways to continue enforcing those policies despite this change. But they will require organizations to use browser controls or enforce use of a filtering DNS resolver.

While change is a constant, the pace is now much faster. Lots of software is either web services or updated weekly. Network administrators need to evaluate the impact of these external changes on their organization.