On Many Addresses per Host
RFC 1681

Document Type RFC - Informational (August 1994; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 1681 (Informational)
Telechat date
Responsible AD (None)
Send notices to (None)
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.

Abstract

   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 big-internet@munnari.oz.au 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.

Encoding Services

   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
   diskless clients.

Bellovin                                                        [Page 1]
RFC 1681               On Many Addresses per Host            August 1994

   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,
   without asking the user community to learn new protocols or custom
   port numbers.

   Archie is an even better example.  There are three principal ways to
   use Archie:  use a special protocol, and hence a special application
   program, on a dedicated port and host that is probably named
   archie.foo.bar; telnet to archie.foo.bar and go through an extra and
   gratuitous login as archie, or telnet to some special port on
   archie.foo.bar.  The latter two are examples of using a standard
   protocol (telnet) to offer a different service.  Neither alternative
   is very convenient.

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

   Note that there are security advantages here, too.  A firewall could
   be configured to allow access to the address associated with the
   Archie server, but not the other addresses on that host.  That would
   provide a high degree of safety, assuming, of course, that the other
   servers on that host were bound to its primary addresses, and not the
   exposed address.

   Another way to implement this concept would be to extend the DNS, to
   return port number information as well as IP addresses.  Thus,
   netlib.att.com might return 192.20.225.3/221.  But that would
   necessitate changing every FTP client program, a daunting task.

   We could also look on this as the extension of the MX concept.  MX
   records are very valuable, but they apply only to mail, and they
   don't supply port numbers.  Again, changing this would require
   massive client program changes.

Bellovin                                                        [Page 2]
Show full document text