Browse Prior Art Database

On Many Addresses per Host (RFC1681)

IP.com Disclosure Number: IPCOM000002519D
Original Publication Date: 1994-Aug-01
Included in the Prior Art Database: 2019-Feb-12
Document File: 5 page(s) / 8K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

S. Bellovin: AUTHOR

Related Documents

10.17487/RFC1681: DOI

Abstract

This document was submitted to the IETF IPng area in response to RFC 1550.This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 28% of the total text.

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 us...

Processing...
Loading...