Movatterモバイル変換

Network Working Group                                     D. L. MillsRequest for Comments:  799                        COMSAT Laboratories                                                       September 1981Internet Name Domains1.  Introduction     In the long run, it will not be practicable for every internethost to include all internet hosts in its name-address tables.  Evennow, with over four hundred names and nicknames in the combinedARPANET-DCNET tables, this has become awkward.  Some sort ofhierarchical name-space partitioning can easily be devised to dealwith this problem; however, it has been wickedly difficult to find onecompatible with the known mail systems throughout the community.  Theone proposed here is the product of several discussions and meetingsand is believed both compatible with existing systems and extensiblefor future systems involving thousands of hosts.2.  General Topology     We first observe that every internet host is uniquely identifiedby one or more 32-bit internet addresses and that the entire system isfully connected.  For the moment, the issue of protocol compatibilitywill be ignored, so that all hosts can be assumed MTP-competent.  Wenext impose a topological covering on the space of all internetaddresses with a set of so-called name domains.  In the natural model,name domains would correspond to institutions such as ARPA, UCL andCOMSAT, and would not be necessarily disjoint or complete.  While inprinciple name domains could be hierarchically structured, we willassume in the following only a single-level structure.     Every name domain is associated with one or more internetprocesses called mail forwarders and the name of that domain is thename for any of these processes.  Each forwarder process for aparticular domain is expected to maintain duplicate name-addresstables containing the names of all hosts in its domain and, inaddition, the name of at least one forwarder process for every otherdomain.  Forwarder processes may be replicated in the interests ofrobustness; however, the resulting complexities in addressing androuting will not be discussed further here.  A particular internethost may support a number of forwarder processes and their collectivenames represent nicknames for that host, in addition to any othernames that host may have.  In the following an internet hostsupporting one or more forwarder proceses will be called simply aforwarder.     Every host is expected to maintain name-address tables includingthe names of at least one forwarder for every

Internet Name Domains                               PAGE   2domain together with additional hosts as convenient.  A host maybelong to several domains, but it is not necessary that all hosts inany domain, be included in its tables.  Following current practice,several nicknames may be associated with the principal name of a hostin any domain and these names need not be unique relative to any otherdomain.  Furthermore, hosts can be multi-homed, that is, respond tomore than one address.  For the purpose of mail forwarding anddelivery, we will assume that any of these addresses can be usedwithout prejudice.  The use of multi-homing to facilitate sourcerouting is a topic for future study.3.  Naming Conventions     In its most general form, a standard internet mailbox name hasthe syntax                  <user>.<host>@<domain> ,where <user> is the name of a user known at the host <host> in thename domain <domain>.  This syntax is intended to suggest athree-level hierarchically structured name (reading from the right)which is unique throughout the internet system.  However, hosts withina single domain may agree to adopt another structure, as long as itdoes not conflict with the above syntax and as long as the forwardersfor that domain are prepared to make the requisite transformations.For instance, let the name of a domain including DCNET be COMSAT andthe name of one of its hosts be COMSAT-DLM with Mills a user known tothat host.  From within the COMSAT domain the name Mills@COMSAT-DLMuniquely identifies that mailbox as could, for example, the nameMills.COMSAT-DLM@COMSAT from anywhere in the internet system.However, Mills@COMSAT-DLM is not necessarily meaningful anywhereoutside the COMSAT domain (but it could be).     A typical set of name domains covering the current internetsystem might include ARPA (ARPANET), COMSAT (DCNET), DCA (EDNET,WBNET), UCL (UCLNET, RSRENET, SRCNET), MIT (CHAOSNET), INTELPOST(INTELPOSTNET) and the various public data networks.  The ARPAforwarder would use a name-address table constructed from the latestversion of the HOSTS.TXT table in the NIC data base.  The otherforwarders would construct their own, but be expected to deposit acopy in the NIC data base.4.  Mail Transport Principles     In the interests of economy and simplicity, it is expected thatthe bulk of all mail transport in the internet system will take placedirectly from originator to recipient

Internet Name Domains                               PAGE   3host and without intermediate relay.  A technique of caching willprobably be necessary for many hosts in order to reduce the trafficwith forwarders merely to learn the internet address associated with acorrespondent host.  This naturally encourages naming strategiesdesigned to minimize duplicate names in the various domains; however,such duplicates are not forbidden.     There are several reasons why some messages will have to bestaged at an intermediate relay, among them the following:1.  It may not be possible or convenient for theoriginator    and recipient hosts to be up on the internet system at    the same time for the duration of the transfer.2.  The originatorhost  may  not  have  the  resources  to    perform all name-address translations required.3.  A direct-connection path maynot  be  feasible  due  to    regulatory economic or security constraints.4.  The originator and recipient hosts may not recognize the    same lower-level transport protocol (e.g.  TCP and NCP).     A mail relay is an internet process equipped to store an MTPmessage for subsequent transmission.  A mail forwarder is a mailrelay, but not all relays are forwarders, since they might not includethe full name-address capability required of forwarders.  In addition,relays may not be competent in all domains.  For instance, a MTP/TCPrelay may not understand NCP.  In other words, the forwarders must befully connected, but the relays may not.     The particular sequence of relays traversed by a message isdetermined by the sender by means of the source route specification inthe MRCP command.  There are several implications to this:1.  Advisory messages returned to the originator by a relay    or recipient host are expected to traverse the route in    reverse order.2.  Relay host names follow the samenaming  convention  as    all  host  names relative to their domain.  Since it may    not be possible (see below) to use internet addresses to    dis-ambiguate the domain, the complete standard internet    name .<host>@<domain> is required everywhere.3.  There is no currentprovision  for  strict/loose  route    specifications.    If,  in  fact,  the  "ordinary"  host    specification @<host> were used, each relay or forwarder

Internet Name Domains                               PAGE   4    would  use  the  rules  outlined in the next section for    routing.  This may result in additional relay hops.5.  Forwarder Operations     This section describes a likely scenario involving hosts, relaysand forwarders and typical internet routes.  When a forwarder receivesa message for <user>.<host>@<domain>, it transforms <host> ifnecessary and forwards the message to its address found in thename-address table for <domain>.  Note that a single host can be aforwarder for several independent domains in this model and that thesedomains can intersect.  Thus, the names Mills@USC-ISIE,Mills.USC-ISIE@ARPA and Mills.USC-ISIE@COMSAT can all refer to thesame mailbox and the names USC-ISIE, ARPA and COMSAT can, conceivably,all be known in the same domain.  Such use would be permissable onlyin case the name USC-ISIE did not conflict with other names in thisdomain.     In order for this scheme to work efficiently, it is desireablethat messages transiting forwarders always contain standard internetmailbox names.  When this is not feasible, as in the current ARPANETmail system, the forwarder must be able to determine which domain themessage came from and edit the names accordingly.  This would benecessary in order to compose a reply to the message in any case.     In theRFC-780 model a message arriving at a forwarder isprocessed by the MTP server there.  The server extracts the firstentry in the recipient-route field of an MRCP command.  There are twocases, depending on whether this entry specifies a domain name or ahost name.  If a domain name, as determined by a search of a universaltable, it refers to one of the domains the server represents.  If not,it must a name or nickname of the server's host relative to ooe of thedomains to which the sender belongs.  This allows a distinction to bemade between the domains COMSAT and INTELPOST on one hand and theCOMSAT host COMSAT-PLA on the other, all of which might be representedby the same internet address, and implies that domain names must beunique in all domains.     The server next extracts the second entry in the recipient-routefield of the MRCP command and resolves its address relative to thedomain established by the first entry.  If the second entry specifiesan explicit domain, then that overrides the first entry.  If not andthe first entry specifies a domain, then that domain is effective.However, if the first entry specifies the server's host, it may not beapparent which domain is intended.  For instance, consider thefollowing two MRCP commands:

Internet Name Domains                               PAGE   5MRCP to:<@COMSAT,Mills@HOST> andMRCP to:<@INTELPOST,Mills@HOST> ,where Mills.HOST@COMSAT and Mills.HOST@INTELPOST are distinctmailboxes on different hosts.  A receiving host supporting forwardersfor both COMSAT and INTELPOST can then preserve this distinction andforward correctly using the above rules.     Now let the forwarder host have the name FORWARDER in both theCOMSAT and INTELPOST domains and consider its options when receivingthe commandMRCP to:<@FORWARDER,Mills@HOST> .The forwarder is being asked simply to relay within the domain of thesender; however, it belongs to more than one domain! The obvious wayto resolve this issue would be to forbid the use of implicit domains,as represented by Mills@HOST, and require the full internet mailboxnames Mills.HOST@COMSAT or Mills.HOST@INTELPOST.  It is also possibleto dis-ambiguate the domain by inspecting the first entry of thesender-route field of the MAIL command (see below).6.  Source and Return Routing     In theRFC-780 model, routes can be specified in therecipient-route field of the MRCP command and in the sender-routefield of the MAIL command.  In point of fact, neither therecipient-route or sender-route is necessary if the originatorspecifies standard internet mailbox names.  So long as the routes,when used, consist only of domain names, there is no conflict with thecurrentRFC-780 specification.  If for some reason forwarding must bedone via other hosts, then the use of a complete and unambigous syntaxlike .<host>@<domain> is required in order to avoid problems like thatdescribed above.     The presentRFC-780 specification requires the receiver toconstruct a name for the sender and insert this at the beginning ofthe sender-route.  Presumably, the only information it has toconstruct this name is the internet address of the sender.  Considerthe case, as in the example above, where multiple domains aresupported by a single server on a particular host.  If hosts receivinga message relayed via that server were to map its address into a name,there would be no way to determine which domain was intended.  Weconclude that the sending host must update the sender-route as well asthe recipient-route.  It does this simply by copying the first entryin the recipient-route as received as the new first entry in thesender-route.

Internet Name Domains                               PAGE   67.  Editing theRFC-733 Header     Every effort should be made to avoid editing theRFC-733 header,since this is an invasive procedure requiring extensive analysis.  Itis expected that newly developed mail systems will be aware of thestandard internet mailbox syntax and ensure its use everywhere in theRFC-733 andRFC-780 fields.  On the occasions where this is notpossible, such as in many current ARPANET hosts, the necessary editingshould be performed upon first entry to the internet mail system fromthe local mail system.  This avoids the problems mentioned above andsimplifies reply functions.     In the case of ARPANET hosts, the editing operations assume thatall names in the form <anything>@<domain>, where <domain> is the nameof a domain, are unchanged.  Names in the form <anything>@<host>,where <host> is the name of a host in the ARPA domain, are transformedto the form <anything>.<host>@ARPA.  Anything else is an error.Before handing off to an ARPANET NCP mailer, an ARPA MTP forwardermight optionally transform <anything>.<host>@ARPA to <anything>@<host>in order to reduce the forwarder traffic when local mail systems areavailable.  Similar situations might exist elsewhere.8.  Concluding Remarks     This memorandum is intended to stimulate discussion, not simulateit.-------