On Many Addresses per Host (RFC1681)
Original Publication Date: 1994-Aug-01
Included in the Prior Art Database: 2000-Sep-12
Internet Society Requests For Comment (RFCs)
AbstractThis document was submitted to the IETF IPng area in response to RFC 1550. Publication of this document does not imply acceptance by the IPng area of any ideas expressed within. Comments should be submitted to the email@example.com mailing list.
Network Working Group S. Bellovin
Request for Comments: 1681 AT&T Bell Laboratories
Category: Informational August 1994
On Many Addresses per Host
Status of this Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This document was submitted to the IETF IPng area in response to RFC
1550. Publication of this document does not imply acceptance by the
IPng area of any ideas expressed within. Comments should be
submitted to the firstname.lastname@example.org mailing list.
Overview and Rational
Currently, most hosts have only one address. With comparatively rare
exceptions, hosts as hosts -- as opposed to hosts acting as routers
or PPP servers -- are single-homed. Our address space calculations
reflect this; we are assuming that we can estimate the size of the
address space by counting hosts. But this may be a serious error. I
suggest that that model may -- and should -- change.
For the ideas outlined below, I do not claim that multiple addresses
per host is the only or even necessarily the best way to accomplish
the goal. I do claim that my ideas are at the very least plausible,
and that I expect that many of them will be tried.
More and more often, services are being encoded in the host name.
One can fetch files from ftp.research.att.com, look up an IP address
on ns.uu.net, synchronize clocks from ntp.udel.edu, etc. Should this
practice be generalized to the IP address domain?
In some cases it would be a very good idea. Certain services need to
be configured by IP address; they are either used when the DNS is
being bootstrapped (such as in glue records and root server cache
records), or when its unavailable (i.e., when booting after a power
hit, and the local name servers are slower to reboot than their
Security is another reason, in some cases. Address-based
authentication is bad enough; relying on the name service adds
another layer of risk. An attacker can go after the DNS, in that
case. A risk-averse system manager might prefer to avoid the extra
exposure, instead granting privileges (i.e., rlogin or NFS) by
address instead of name. But that, of course, leads to all the usual
headaches when the location of the service changes. If the address
for the service could be held constant, there would be much more
freedom to move it to another machine. One way to do that is by
assigning the serving host a secondary address.
A related notion comes from the need 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,