Trailing-Edge
-
PDP-10 Archives
-
SRI_NIC_PERM_SRC_1_19910112
-
6-1-monitor/domain.req
There are no other files named domain.req in the archive.
4-Apr-88 16:20:27-PDT,24656;000000000001
Return-Path: <braden@venera.isi.edu>
Received: from venera.isi.edu by SRI-NIC.ARPA with TCP; Mon 4 Apr 88 16:17:29-PDT
Received: from braden.isi.edu by venera.isi.edu (5.54/5.51)
id AA16783; Mon, 4 Apr 88 16:17:55 PDT
Date: Mon, 4 Apr 88 16:17:29 PDT
From: braden@venera.isi.edu
Posted-Date: Mon, 4 Apr 88 16:17:29 PDT
Message-Id: <8804042317.AA00258@braden.isi.edu>
Received: by braden.isi.edu (3.2/5.51)
id AA00258; Mon, 4 Apr 88 16:17:29 PDT
To: craig@nnsc.nsf.net, mkl@sri-nic.arpa, pvm@venera.isi.edu
Subject: How I Hacked Your Good Words
Cc: braden@venera.isi.edu
Hi. I glued together your words on UDP, mail, and domains, into an outline
of the proposed format. I also did a (little) editorial messing about.
Please let me know it you think I screwed it up, or if you dislike
something I did to your words.
Hey, thanks, guys!
Bob Braden
________________________________________________________________
2. MEDIA SUPPORT
An Internet host will have interfaces to one or more of the
networks that constitute the Internet. A host which has
direct interfaces to more than one network is said to be
"multihomed". A network to which a host is interfaced is
often known as the "local network" or the "sub-network"
relative to that host; however, both these terms can cause
confusion, and therefore we will use the term "connected
network" or "constituent network".
The requirements for interfacing a host to any of the
commonly-used network media will be found in Chapter 3 of
RFC-1009 (since at the network level, the requirements are
identical for a host and a gateway).
3. INTERNET PROTOCOL
((To be supplied))
- 2 -
4. TRANSPORT PROTOCOLS
There are two standard transport protocols used in the ARPA
Internet are the Transmission Control Protocol TCP, and the
User Datagram Protocol UDP. TCP provides reliable, in-
sequence delivery of a stream of octets (8-bit bytes). UDP
offers non-guaranteed delivery of datagrams.
TCP is used by those applications needing reliable,
connection-oriented transport service, e.g., mail (SMTP, see
section 5.1), bulk file transfers (FTP, see section 5.2),
and virtual terminal service (TELNET, see section 5.3)..
UDP provides a minimal transport service, designed to give
applications direct access to the datagram service of the IP
layer. UDP is used by applications that do not require the
level of service of TCP or wish to use communications ser-
vices (e.g. multicast or broadcast delivery) not available
from TCP.
4.1 REFERENCES
Military Standard Documents
* MIL-STD-1778 - "Transmission Control Protocol" - Aug
1983?
Request For Comments (RFC's)
* RFC-768 "User Datagram Protocol", J. Postel.
* RFC-793 "Transmission Control Protocol", J. Postel.
* RFC-813 "Window and Acknowledgement Strategy in TCP",
D. Clark.
* RFC-817 "Modularity and Efficiency in Protocol Imple-
mentation", D. Clark.
* RFC-889 "Internet Delay Experiments", D. Mills.
- 3 -
* RFC-896 "Congestion Control in IP/TCP", J. Nagle.
* RFC-970 "On Packet Switches With Infinite Storage", J.
Nagle. (also IEEE Transactions on Communications V 35
#4 April 1987)
* RFC-1025 "TCP and IP Bake Off", J. Postel
Papers
* "Divergence of Timeout Algorithms for Packet
Retransmissions", Raj Jain, Proc 5th Annual Interna-
tional Phoenix Conference on Computers and Communica-
tions, 1986.
* "A Timeout-Based Congestion Control Scheme for Window
Flow-Controlled Networks", Raj Jain, IEEE JSAC, SAC-4-
7, Oct86.
* "Fragmentation Considered Harmful", Chris Kent & Jeff
Mogul, SIGCOMM 1987
* "Round Trip Time Estimation", Phil Karn & Craig Par-
tridge, SIGCOMM 1987
* "Why TCP Timers Don't Work Well", Lixia Zhang, SIGCOMM
1986.
* "An Adaptive Timeout Algorithm for Retransmission
Across a Packet Switching Network", Steven Edge,
SIGCOMM 1983.
* "On Caching Out-of-order Packets in Window Flow-
controlled Networks", Raj Jain, DEC TR-342, Jan 1985.
4.2 DISCUSSION OF THE PROTOCOLS
4.2.1 UDP -- User Datagram Protocol
- 4 -
UDP adds only two services to IP: ports for addressing dif-
ferent application-level processes, and checksums of the
data.
There are no known errors in the specification of UDP.
There is, however, one very common error in UDP implementa-
tions: the checksum algorithm is mis-implemented. Unlike
TCP, UDP has an optional checksum; the value zero is
transmitted in the checksum field of a UDP header to indi-
cate no checksum. If the transmitter actually calculates a
UDP checksum of zero, it must instead transmit the checksum
as all-1's (65535). No special action is required at the
receiver, since zero and all-1's are equivalent in 1's com-
plement arithmetic.
4.2.2 TCP -- Transmission Control Protocol
((To be supplied by Craig Partridge et al))
- 5 -
5. APPLICATIONS
5.1 ELECTRONIC MAIL
In the TCP/IP protocol suite, electronic mail is exchanged
using the Simple Mail Transfer Protocol (SMTP) in the format
specified by RFC-822.
Over the years, while SMTP has remained unchanged, the
Internet community has made several changes in the way SMTP
is used. In particular, changes in address formats and the
way mail is routed have both been affected by the conversion
to domain names.
5.1.1 References
* RFC-821 "Simple Mail Transfer Protocol", J. Postel.
* RFC-822 "Standard For The Format of ARPA Internet Text
Messages. D. Crocker. (Obsoletes RFC-733).
* RFC-974 "Mail Routing and the Domain System", C. Par-
tridge.
* RFC-1047 "Duplicate Messages and SMTP", C. Partridge.
5.1.2 Simple Mail Transfer Protocol -- SMTP
5.1.2.1 Discussion of RFC-821
The SMTP specification in RFC-821 is quite clear and con-
tains numerous examples, so implementors should not find it
difficult to understand the specification.
This section simply updates or annotates portions of the
SMTP specification to conform with current usage. The fol-
lowing discussion is organized by section of RFC-821.
Section 2: The SMTP Model.
The text suggests that mail is delivered to a user at a
host. With the advent of the domain system and of mail
routing using mail-exchanger (MX) resource records (RR),
- 6 -
implementors should now think of delivering to a user at a
domain name, which may or may not be the name of a particu-
lar host. This *does not* change the fact that SMTP is a
host-to-host mail exchange protocol, and it has no important
effects on the correctness of the SMTP model.
o RFC-821 Section 3.3: Verifying and Expanding
While EXPN and VRFY are not required of minimum imple-
mentations, many users of SMTP do make regular use of
the commands and implementors should make some effort
to include them in any SMTP implementation.
However, some people believe that their membership in a
mailing list should be confidential, and so we recom-
mend that mechanisms be provided to turn off the EXPN
command either for selective addresses or on a per-
system basis.
o RFC-821 Section 3.4: Sending and Mailing
The commands to send to a user's terminal (SEND, SOML,
and SAML) have never been implemented in most mail sys-
tems and are not generally considered useful in the
current Internet environment.
o RFC-821 Section 3.6: Relaying
This section requires the use of a separate mail
envelope. Because SMTP supports the relaying of mail,
and requires that the return path be passed along with
the message from relay to relay, mail relays keep track
of the return path and forward path for each message.
This information may not be kept in the message itself.
Furthermore, it is generally considered bad practice to
alter the fields of the message itself to reflect the
path through which the message was delivered, except to
add the appropriate "Received:" lines to the message
header.
The major interconnected electronic mail environments
(ARPA Internet, CSNET, BITNET and UUCP) are actively
trying to encourage the use of simpler mail headers, in
which the To:, and Cc:, From: fields are all of the
- 7 -
form user@domain, and dispense with the more complex
addressing forms which are permitted under RFC-822.
Note that it is acceptable to rewrite the header fields
when messages are crossing environment boundaries and
there is reason to believe that the receiver will not
be able to respond to the addresses in the To, Cc and
From fields unless they are rewritten to use a source
route.
Mail relay host systems are required to add a source
route to the SMTP return path of each message passing
through the relay. For example, if a message sent from
user@nnsc.nsf.net passes through relays: relay.cs.net
and harvard.harvard.edu before reaching a final desti-
nation: husc7.harvard.edu, the return path should be:
@harvard.harvard.edu,@relay.cs.net:user@nnsc.nsf.net.
In addition, there has been some controversy about the
meaning of forward and return paths at network boun-
daries (i.e. at mail gateways between various cooperat-
ing electronic mail networks).
<<ISSUES ABOUT HOW MUCH GATEWAYS ARE ENTITLED TO FIDDLE
WITH ENVELOPE -- CAN THEY IGNORE SOURCE ROUTES WITHIN
THEIR NETWORK, CAN THEY DISCARD RETURN PATH ALA BIT-
NET?>>
<<Need to discuss relationship between relaying and MX
RRs -- not a problem -- just needs clarification>>
o RFC-821 Section 4.3: Sequencing Of Commands and Replies
There has been a problem with SMTP systems that use
reply codes that are not listed in the Command-Reply
Sequences in this section, although they are legal
according to the theory of reply codes explained in
Appendix E. Implementors shoulld avoid such problems
by writing software which only sends the reply codes
listed in this section, but properly recognizes any
reply code that conforms to Appendix E.
o RFC-821 Section 4.5.2: Transparency
Implementors should confirm that their mail system
always properly adds and deletes periods to ensure
- 8 -
message transparency in the cases described in this
section.
RFC-821 Appendix E
See notes above on section 4.3.
5.1.2.2 SMTP Implementation Issues
o Timeouts in SMTP
RFC-821 neither encourages nor precludes the use of
timeouts. In practice, timeouts are a key part of any
SMTP implementation since it is not uncommon for the
communications link to fail between peer mailers or for
one of the mailers to hang due to a software bug.
There are two accepted approaches to timeouts: (1) set
a time limit on the entire SMTP dialogue (for a single
mail message), or (2) place a time limit on each SMTP
command separately. There are advantages to both
schemes. Timing per-command generally catches problems
faster, but often times out remote systems that are
still functioning but simply take too long to respond.
Timing per-message accomodates slow systems but these
timeouts must typically be set to high values (often
more than an hour to accomodate very large messages),
causing problems to go undetected for an extended
period.
Finally, it is important to note that the timeout
periods should be scaled based on the message size.
Even in systems that time individual commands, the
timeout for the final period should be adjusted based
on message length because part of the delay in replying
to the final period is often the time taken to copy the
message body from temporary storage into a more per-
manent space in the system mail queues.
o Duplicate Messages in SMTP
One problem with all timeout schemes is that they
aggravate a problem in SMTP that permits duplicate
copies of a message to be generated. The problem comes
when the receiving peer waits a long time before
- 9 -
responding to the final period that ends a message.
Details of the problem and a suggested solution are
described in RFC-1047.
5.1.3 RFC-822 Message Formats
RFC-822 specifies the Internet standard format for
electronic mail messages. This format is logically
independent of the protocol used to transfer the mes-
sage, and in fact this same standard is used in some
non-Internet mail environments (e.g., BITNET and CSNET)
which use a different mail transfer protocol than SMTP.
RFC-822 supercedes an older standard, RFC-733, which,
although long out of date, may still be used in a few
places. The two formats are often referred to simply
by number (822 and 733).
RFC-822 is a long and very dense document. As a
result, incomplete or defective implementations are
common. In particular, sites often have trouble prop-
erly parsing all 822 addresses. Unfortunately, it is
also true that all the available address formats are
used, and thus a conforming implementation must recog-
nize and interpret them properly.
One general problem that the reader should be aware of
throughout the text. The BNF grammars within the text
of the specification are wrong. Use the BNF summary on
the last two pages.
Here are notes on RFC-822, organized by section of that
document.
o RFC-822 Section 5
<<Recently there was note on header-people that stated
that the military time zones were wrong -- I need to
retrieve it>>
There is also a general trend towards using numeric
instead of alphabetic timezone indicators.
o RFC-822 Section 6.1
- 10 -
Errors in formatting or parsing 822 addresses are
unfortunately quite common. This section mentions only
the most common errors. The implementor should ensure
that an implementation accepts all 822 addresses, and
should test more than the special cases mentioned here.
Many systems use a route-addr, an address specification
within angle brackets such as <craig@nnsc.nsf.net>,
without a leading phrase. Of the following examples:
From: "Craig Partridge" <craig@nnsc.nsf.net>
From: <craig@nnsc.nsf.net>
the first 'From' field is legal, but the second is not.
Another common error is to leave out the semi-colon
after a group identifier.
Many systems fail to fully qualify domain names in mes-
sages they send out. Headers with 'From' fields like:
From: user@cs
instead of
From: user@cs.myuniversity.edu
are unfortunately quite common.
Finally, many systems mis-parse multiple source routes
such as:
@relay1,@relay2,@relay3:user@domain.
<<Ed: A question that has long puzzled me: what is the
function of source routes in the 822 header vs. in the
SMTP envelope? >>
o RFC-822 Section 6.2.3
Although the use of domain literals is strong
discouraged, they are used occasionally and at minimum,
mailers must be able to parse them.
<<ANYTHING ELSE??>>
- 11 -
5.2 FILE TRANSFER
((To be supplied))
5.3 TELNET
((To be supplied))
6. SUPPORT SERVICES
6.1 NAME TO ADDRESS CONVERSION
Conversion of host names to IP addresses and vice-versa is a
required function of the host. User programs such as TELNET
need to take a host name from the user and convert it to an
IP address. Previously these conversions were done using a
global host table. The table eventually became too large to
update and distribute in a timely manner, so the domain sys-
tem was invented. The domain system is a distributed data-
base used primarily for the translation of host names to
host numbers.
Name to address conversion and associated conversions should
be performed using the domain name system. In some cases, a
host may not be connected to the Internet system and might
require a "host table" to be used instead. A host table may
also be used as a backup function to the domain system.
The DDN Host Table, which is being phased out <<Ed: CAN WE
MAKE THIS CLAIM FOR THE ENTIRE INTERNET?>>, is documented in
RFC-952. The DDN Host Table can be retrieved from the DDN
Network Information Center host using the Hostname protocol
described in RFC-953. Hosts using the Hostname server
should use the VERSION command to check if the table has
changed before requesting the entire table with the ALL com-
mand.
The domain system is a distributed database system and con-
sists of two logically distinct parts, servers and
resolvers. Domain servers store authoritative data about
certain sections of the database and answer queries about
- 12 -
the data. Domain resolvers query domain servers for data on
behalf of user processes. Every host therefore needs a way
to resolve host names. Some host machines will also need to
run domain servers.
The rest of this section will be concerned with the domain
system.
6.1.1 REFERENCES
* RFC-952
* RFC-953
* RFC-974
* RFC-1032
* RFC-1034 "Domain Names - Concepts and Facilities", P.
Mockapetris. (Obsoletes RFC-882 "RFC-883 "RFC-973).
* RFC-1035 "Domain Names - Implementation and Specifica-
tion", P. Mockapetris. (Obsoletes RFC-882, RFC-883,
RFC-973).
6.1.2 DOMAIN SERVICE REQUIREMENTS
Hosts should provide an interface to the domain system for
all programs running on the host. The interface typically
directs program requests to a system process which performs
the resolver function described in RFCs 1034 and 1035. At a
minimum, the interface should provide a method for the pro-
gram to ask for all information of a specific type associ-
ated with a specific name, and should return either the
requested information, a hard error code, or a soft error
indication. The interface should pass though the complete
information without modification, deletion, or ordering, so
that the interface need not be changed to acomodate new data
types. The soft error indication is an essential part of
the interface, since it may not always be possible to access
- 13 -
particular information.
Most hosts will provide other interfaces tailored to partic-
ular functions. These functions transform the raw domain
data into formats more suited to particular functions. It
is recommended that special interfaces be provided to facil-
itate translation between host addresses and host names.
When the host name to host address function encounters a
host with multiple addresses, it should rank or sort the
addresses using knowledge of the immediately connected net-
work number(s), and any other applicable performance or his-
tory information.
All interfaces should provide the ability to use user- or
program- specified search lists in locating information so
that short hands can be used for commonly used names. How-
ever, it is required that a request can be presented which
indicates that the name is complete and should not use the
search list mechanism.
6.1.3 RESOLVER IMPLEMENTATION STRATEGIES
The resolver process may be designed to operate in one of
two modes, general and restricted.
A general-mode resolver is a complete implementation of the
resolver service, and is capable of dealing with communica-
tion failures, failure of individual name servers, location
of the proper name server for a given name, etc.
* The resolver must implement a local caching function to
avoid repeated remote access for identical requests,
and must timeout information in the cache.
* The resolver must implement retransmission controls to
insure that it does not waste communication bandwidth,
and should be especially careful to impose finite
bounds on the amount of transmissions generated in
response to a single request.
* The resolver should be configured with start-up infor-
mation pointing to at least two root name servers and
two name servers for the local domain. This insures
that the resolver will be able to access the whole name
space in normal cases, and will be able to access local
- 14 -
domain information should the local network become
disconnected from the rest of the Internet.
* they may use TCP services where available.
A resolver in the restricted mode is a stub which relies on
the services of a recursive name server on the connected
network or a "nearby" network. This scheme allows the host
to pass on the burden of the resolver function to a server
on another host. This mode is often essential for less
capable hosts, such as PC's, and is also recommended when
the host is one of several workstations on a local network,
because it allows all of the workstations to share the cache
of the recursive name server and hence reduce the number of
domain requests exported by the local network. At a
minimum, the local resolver function should be capable of
directing its requests to redundant recursive name servers.
Note that recursive name servers are allowed to restrict the
sources of requests that they will honor, so the host
administrator must verify that the service will be provided.
Restricted-mode resolvers may implement caching if they
choose, but if so, must timeout cached information. TCP is
preferred, though UDP may be used.
In either mode, the local resolver should be able to multi-
plex concurrent requests if the host supports concurrent
processes.
6.1.3 APPLICATION USE OF DOMAIN SERVICES
Applications using domain services must be able to cope with
soft error conditions. Applications should not loop retry-
ing soft errors, since this will typically result in a con-
tinuous sequence of useless traffic.
Mailers are required to implement the MX scheme described in
RFC 974. Note that a mailer will typically need to be able
to requeue outgoing mail when soft errors are encountered
and move on to other requests.
6.1.4 DOMAIN SYSTEM REGISTRATION
Domains must be registered and administered properly. Hosts
must be registered within their domain, and domains must be
registered within their parent domain. See the Domain
Administrators Guide, RFC-1032 for details.
- 15 -
<<ED's NOTE: maybe 6.1.4 does not belong in this RFC...?>>
-------
6.2 NETWORK BOOTING
6.3 REMOTE MANAGEMENT
7. APPENDIX