Browse Prior Art Database

Internet name domains (RFC0799) Disclosure Number: IPCOM000003848D
Original Publication Date: 1981-Sep-01
Included in the Prior Art Database: 2019-Feb-14
Document File: 6 page(s) / 9K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

D.L. Mills: AUTHOR

Related Documents

10.17487/RFC0799: DOI

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

Network Working Group D. L. Mills Request for Comments: 799 COMSAT Laboratories September 1981

Internet Name Domains

1. Introduction

In the long run, it will not be practicable for every internet host to include all internet hosts in its name-address tables. Even now, with over four hundred names and nicknames in the combined ARPANET-DCNET tables, this has become awkward. Some sort of hierarchical name-space partitioning can easily be devised to deal with this problem; however, it has been wickedly difficult to find one compatible with the known mail systems throughout the community. The one proposed here is the product of several discussions and meetings and is believed both compatible with existing systems and extensible for future systems involving thousands of hosts.

2. General Topology

We first observe that every internet host is uniquely identified by one or more 32-bit internet addresses and that the entire system is fully connected. For the moment, the issue of protocol compatibility will be ignored, so that all hosts can be assumed MTP-competent. We next impose a topological covering on the space of all internet addresses with a set of so-called name domains. In the natural model, name domains would correspond to institutions such as ARPA, UCL and COMSAT, and would not be necessarily disjoint or complete. While in principle name domains could be hierarchically structured, we will assume in the following only a single-level structure.

Every name domain is associated with one or more internet processes called mail forwarders and the name of that domain is the name for any of these processes. Each forwarder process for a particular domain is expected to maintain duplicate name-address tables containing the names of all hosts in its domain and, in addition, the name of at least one forwarder process for every other domain. Forwarder processes may be replicated in the interests of robustness; however, the resulting complexities in addressing and routing will not be discussed further here. A particular internet host may support a number of forwarder processes and their collective names represent nicknames for that host, in addition to any other names that host may have. In the following an internet host supporting one or more forwarder proceses will be called simply a forwarder.

Every host is expected to maintain name-address tables including the names of at least one forwarder for every

Internet Name Domains PAGE 2

domain together with additional hosts as convenient. A host may belong to several domains, but it is not necessary that all hosts in any domain, be included in its tables. Following current practice, several nicknames may be associated with the principal name of a host in any domain and these names need not be unique relative to any other domain. Furthermore, hosts can be multi-homed, that is, respond to more than one address. For the purpose of mail forwarding and delivery, we will assume that any of these addresses can be use...