RFC 1681

On Many Addresses per Host 🦋

Okay bestie, this is RFC 1681 from the Network Working Group 💅. It's an Informational doc, so it's giving "here are some ideas" and not an official standard. Steven M. Bellovin from AT&T Bell Laboratories wrote it, and it's dated August 1994 🍓. The title block doesn't list anything it obsoletes or updates.

Status of this Memo ✨

This memo gives information to the Internet community. It does not specify an Internet standard of any kind. Distribution is unlimited, so share away 💖

Abstract 📝

This document was submitted to the IETF IPng area in response to RFC 1550. Publishing it does not mean the IPng area accepts any of the ideas inside 😅 Comments go to the big-internet@munnari.oz.au mailing list.

Overview and Rational 🌸

Right now, most hosts have only one address. With a few rare exceptions, hosts (as in actual hosts, not things acting as routers or PPP servers) are single-homed 🏠. Our address space math assumes we can estimate the size of the address space by counting hosts. Bellovin says that might be a serious error, and he thinks that model may, and should, change 👀

He's not claiming that multiple addresses per host is the only way, or even the best way, to get there. What he does claim is that his ideas are at least plausible, and he expects that many of them will get tried 🦋

Encoding Services 🧚

More and more, services are getting encoded in host names. You can fetch files from ftp.research.att.com, look up an IP address on ns.uu.net, sync clocks from ntp.udel.edu, and so on. So should this get generalized to the IP address domain? 🤔

In some cases it would be a very good idea ✨ Some services need to be configured by IP address. They get used while DNS is being bootstrapped (like glue records and root server cache records), or when DNS is unavailable, like after a power hit when the local name servers take longer to reboot than their diskless clients 💀

Security is another reason, in some cases. Address-based authentication is already bad enough, and relying on the name service adds another layer of risk. An attacker can go after the DNS. A risk-averse sysadmin might prefer to grant privileges (like rlogin or NFS) by address instead of by name. But that leads to all the usual headaches when the service moves. If the address for the service could stay constant, there would be way more freedom to move it to another machine. One way to do that is to give the serving host a secondary address 🫶

A related notion comes from needing to offer different views of a service from a single host. For example, research.att.com has long offered two distinct FTP archives with slightly different access policies. It would be nice if both could live on the same machine, without asking users to learn new protocols or custom port numbers 🎀

Archie is an even better example 🙈 There are three main ways to use it. You can use a special protocol, and therefore a special application program, on a dedicated port and host that's probably named archie.foo.bar. You can telnet to archie.foo.bar and go through an extra, gratuitous login as archie. Or you can telnet to some special port on archie.foo.bar. The last two use a standard protocol (telnet) to offer a different service, and neither one is very convenient 😩

It would be better if archie.foo.bar provided the Archie service while host.foo.bar provided a login prompt. Again, the easy way to do that is to give the host a separate IP address for its extra service 💜

There are security advantages here too 🔥 A firewall could allow access to the address associated with the Archie server, but not the other addresses on that host. That would give a high degree of safety, assuming the other servers on that host are bound to its primary addresses and not the exposed one.

Another way to do this would be to extend the DNS so it returns port number information as well as IP addresses. Thus, netlib.att.com might return 192.20.225.3/221. But that would mean changing every FTP client program, which is a daunting task 😭

You could also look at this as an extension of the MX concept. MX records are very valuable, but they only apply to mail, and they don't supply port numbers. Changing that would again require massive client program changes 💅

Accounting and Billing 💸

For better or worse, some parts of the Internet are moving toward usage-sensitive charging. At least four charging schemes seem possible, and the marketeers in charge of this stuff will doubtless come up with more 🙄

The first is the traditional "pay as you go" approach. Each host is responsible for its own packets. The catch is that in a typical conversation, both parties pay, and the providers of free FTP archives end up paying dearly for their generosity 😭 That leads to the second model: caller pays. People might want to make collect calls, much like on the telephone today. Finally, there might be the equivalent of American "900" numbers, where the caller pays a premium to the server 📞

This isn't far-fetched at all. UUNET already has a 900 number for anonymous uucp clients. There's no need to register in advance. Just dial in, and let the phone company act as your agent ☎️

Given all these schemes, it's vital that the caller and the recipient know in advance who will pay. It's not acceptable for users to find out only after the fact that they've incurred a cost 🚫 You could imagine using IP options for this, but that would rule out today's standard clients.

It's not enough to show a message at connection time warning about the charges. Lots of interactions don't provide a hook for user interaction. And there are security concerns too. Suppose someone puts up a gopher server that redirects a caller to some pay-to-play address without displaying the required warning. A scam? Sure, but it's already happened with the phone network, and there's no reason to think the Internet will be far behind 💀

Bellovin's suggestion is to encode the charge algorithm in the destination address (and perhaps in the DNS name space as well). The bits themselves would determine who pays. Organizational border routers could implement policies on pay services. The anonymous workstations in a dorm computer lab wouldn't be allowed to call collect 🎓

An extension of this scheme would use a comparatively large number of bits. That would let the address act not just as a policy indicator, but also as an index into a charge algorithm table 🧮

Addresses per User 👑

It may be useful to assign each user on a host a separate IP address for the duration of their login session. This has a bunch of advantages 🌈

The first one ties in with the charging scheme above. Usage-sensitive accounting is done by routers today, and routers have no idea who's using the hosts. If each user had a separate IP address, we could keep gathering accounting data at the router. The host would just record the address assignments, and billing could happen offline 📊

Similarly, different classes of users could have different forms of addresses. People with hard-money accounts might have some bits set in the address that allow access to costly services. Border routers could make that distinction using today's technology 💰

An IP address per user also fits nicely with encryption. There's a lot of attention on network-layer encryption right now, but that only provides host-level granularity of protection, which is sometimes not enough. Transport-layer encryptors give finer-grained protection, but does the Internet really need two different low-level encryption schemes? If each user had a separate IP address (and maybe only on hosts that care about this stuff), we could provide user-level protection and accountability using the same infrastructure that supports host-level accountability 🔐

Low-Grade Mobility 🦋

There are several schemes under discussion for mobile IP hosts. These are aimed at a fairly general model of hosts moving anywhere. That's important, but there's also a need for limited mobility within a subnet. This could be used for load-balancing. A mail relay that's just been asked to send a huge message to a massive mailing list could offload some of its IP addresses to its peers. That would divert future incoming messages without invalidating thousands of cached MX records and their associated IP addresses 📬 Similarly, servers for low-speed X terminals could live on different physical machines, all without disturbing sessions in progress 🖥️

Merging Subnets 🧩

There's long been a need to merge subnets. Sometimes that's because of organizational changes. Other times, people installed bridges when routers would have been the better choice 🙃 Some hosts need to live on both logical networks at once, so they can avoid an extra hop through a router. It would be useful to be able to assign them addresses like that ✨

How Many Addresses Do We Need? 🤔

Assuming some of these ideas bear fruit, how many addresses do we need per host?

Most of these schemes are pretty cheap. Few people would offer more than a handful of distinct service views per system. But the address-per-user idea could be quite costly 💸 We also have to account for address mask assignment policies. In many of today's networks, enough host address bits have to be allocated to cover the largest subnet in an organization. Even if IPng's routing protocols get smarter about this, foresight in address allocation will still be needed to leave headroom for networks to grow while keeping a contiguous netmask. That in turn contributes to sparse utilization of the address space 😩

So Bellovin recommends allowing for 2^6, and perhaps as many as 2^8, extra addresses per host, to leave room for the ideas in this doc 🌸

He also notes that encoding the service in the transport address bears some relation to OSI's model. That similarity shouldn't, of course, invalidate the idea 🙌

Acknowledgements 🫶

Some of these ideas were derived from conversations with Matt Blaze 💜

Security Considerations 🚨

Security issues are discussed throughout this memo. Read the whole thing, bestie. Security is not a vibe you skip 💀🔥

Author's Address 💌

   Steven M. Bellovin
   Software Engineering Research Department
   AT&T Bell Laboratories
   600 Mountain Avenue
   Murray Hill, NJ  07974, USA

   Phone: +1 908-582-5886
   Fax: +1 908-582-3063
   EMail:  smb@research.att.com