RFC 1123
Requirements for Internet Hosts - Application and Support
Pages: 98
Internet Standard: 3
→ Errata
STD 3 is also: 1122
Updates: 0822 0952
Updated by: 1349 2181 5321 5966 7766 9210
Internet Standard: 3
→ Errata
STD 3 is also: 1122
Updates: 0822 0952
Updated by: 1349 2181 5321 5966 7766 9210
Part 4 of 4 – Pages 72 to 98
6. SUPPORT SERVICES 6.1 DOMAIN NAME TRANSLATION 6.1.1 INTRODUCTION Every host MUST implement a resolver for the Domain Name System (DNS), and it MUST implement a mechanism using this DNS resolver to convert host names to IP addresses and vice-versa [DNS:1, DNS:2]. In addition to the DNS, a host MAY also implement a host name translation mechanism that searches a local Internet host table. See Section 6.1.3.8 for more information on this option. DISCUSSION: Internet host name translation was originally performed by searching local copies of a table of all hosts. This table became too large to update and distribute in a timely manner and too large to fit into many hosts, so the DNS was invented. The DNS creates a distributed database used primarily for the translation between host names and host addresses. Implementation of DNS software is required. The DNS consists of two logically distinct parts: name servers and resolvers (although implementations often combine these two logical parts in the interest of efficiency) [DNS:2]. Domain name servers store authoritative data about certain sections of the database and answer queries about the data. Domain resolvers query domain name servers for data on behalf of user processes. Every host therefore needs a DNS resolver; some host machines will also need to run domain name servers. Since no name server has complete information, in general it is necessary to obtain information from more than one name server to resolve a query. 6.1.2 PROTOCOL WALK-THROUGH An implementor must study references [DNS:1] and [DNS:2] carefully. They provide a thorough description of the theory, protocol, and implementation of the domain name system, and reflect several years of experience.
6.1.2.1 Resource Records with Zero TTL: RFC-1035 Section 3.2.1 All DNS name servers and resolvers MUST properly handle RRs with a zero TTL: return the RR to the client but do not cache it. DISCUSSION: Zero TTL values are interpreted to mean that the RR can only be used for the transaction in progress, and should not be cached; they are useful for extremely volatile data. 6.1.2.2 QCLASS Values: RFC-1035 Section 3.2.5 A query with "QCLASS=*" SHOULD NOT be used unless the requestor is seeking data from more than one class. In particular, if the requestor is only interested in Internet data types, QCLASS=IN MUST be used. 6.1.2.3 Unused Fields: RFC-1035 Section 4.1.1 Unused fields in a query or response message MUST be zero. 6.1.2.4 Compression: RFC-1035 Section 4.1.4 Name servers MUST use compression in responses. DISCUSSION: Compression is essential to avoid overflowing UDP datagrams; see Section 6.1.3.2. 6.1.2.5 Misusing Configuration Info: RFC-1035 Section 6.1.2 Recursive name servers and full-service resolvers generally have some configuration information containing hints about the location of root or local name servers. An implementation MUST NOT include any of these hints in a response. DISCUSSION: Many implementors have found it convenient to store these hints as if they were cached data, but some neglected to ensure that this "cached data" was not included in responses. This has caused serious problems in the Internet when the hints were obsolete or incorrect.
6.1.3 SPECIFIC ISSUES 6.1.3.1 Resolver Implementation A name resolver SHOULD be able to multiplex concurrent requests if the host supports concurrent processes. In implementing a DNS resolver, one of two different models MAY optionally be chosen: a full-service resolver, or a stub resolver. (A) Full-Service Resolver A full-service resolver is a complete implementation of the resolver service, and is capable of dealing with communication failures, failure of individual name servers, location of the proper name server for a given name, etc. It must satisfy the following requirements: o The resolver MUST implement a local caching function to avoid repeated remote access for identical requests, and MUST time out information in the cache. o The resolver SHOULD be configurable with start-up information pointing to multiple root name servers and multiple 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 domain information should the local network become disconnected from the rest of the Internet. (B) Stub Resolver A "stub resolver" 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 name server on another host. This model is often essential for less capable hosts, such as PCs, 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 stub resolver MUST 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. Stub resolvers MAY implement
caching if they choose, but if so, MUST timeout cached
information.
6.1.3.2 Transport Protocols
DNS resolvers and recursive servers MUST support UDP, and
SHOULD support TCP, for sending (non-zone-transfer) queries.
Specifically, a DNS resolver or server that is sending a
non-zone-transfer query MUST send a UDP query first. If the
Answer section of the response is truncated and if the
requester supports TCP, it SHOULD try the query again using
TCP.
DNS servers MUST be able to service UDP queries and SHOULD
be able to service TCP queries. A name server MAY limit the
resources it devotes to TCP queries, but it SHOULD NOT
refuse to service a TCP query just because it would have
succeeded with UDP.
Truncated responses MUST NOT be saved (cached) and later
used in such a way that the fact that they are truncated is
lost.
DISCUSSION:
UDP is preferred over TCP for queries because UDP
queries have much lower overhead, both in packet count
and in connection state. The use of UDP is essential
for heavily-loaded servers, especially the root
servers. UDP also offers additional robustness, since
a resolver can attempt several UDP queries to different
servers for the cost of a single TCP query.
It is possible for a DNS response to be truncated,
although this is a very rare occurrence in the present
Internet DNS. Practically speaking, truncation cannot
be predicted, since it is data-dependent. The
dependencies include the number of RRs in the answer,
the size of each RR, and the savings in space realized
by the name compression algorithm. As a rule of thumb,
truncation in NS and MX lists should not occur for
answers containing 15 or fewer RRs.
Whether it is possible to use a truncated answer
depends on the application. A mailer must not use a
truncated MX response, since this could lead to mail
loops.
Responsible practices can make UDP suffice in the vast
majority of cases. Name servers must use compression
in responses. Resolvers must differentiate truncation
of the Additional section of a response (which only
loses extra information) from truncation of the Answer
section (which for MX records renders the response
unusable by mailers). Database administrators should
list only a reasonable number of primary names in lists
of name servers, MX alternatives, etc.
However, it is also clear that some new DNS record
types defined in the future will contain information
exceeding the 512 byte limit that applies to UDP, and
hence will require TCP. Thus, resolvers and name
servers should implement TCP services as a backup to
UDP today, with the knowledge that they will require
the TCP service in the future.
By private agreement, name servers and resolvers MAY arrange
to use TCP for all traffic between themselves. TCP MUST be
used for zone transfers.
A DNS server MUST have sufficient internal concurrency that
it can continue to process UDP queries while awaiting a
response or performing a zone transfer on an open TCP
connection [DNS:2].
A server MAY support a UDP query that is delivered using an
IP broadcast or multicast address. However, the Recursion
Desired bit MUST NOT be set in a query that is multicast,
and MUST be ignored by name servers receiving queries via a
broadcast or multicast address. A host that sends broadcast
or multicast DNS queries SHOULD send them only as occasional
probes, caching the IP address(es) it obtains from the
response(s) so it can normally send unicast queries.
DISCUSSION:
Broadcast or (especially) IP multicast can provide a
way to locate nearby name servers without knowing their
IP addresses in advance. However, general broadcasting
of recursive queries can result in excessive and
unnecessary load on both network and servers.
6.1.3.3 Efficient Resource Usage The following requirements on servers and resolvers are very important to the health of the Internet as a whole, particularly when DNS services are invoked repeatedly by higher level automatic servers, such as mailers. (1) The resolver MUST implement retransmission controls to insure that it does not waste communication bandwidth, and MUST impose finite bounds on the resources consumed to respond to a single request. See [DNS:2] pages 43- 44 for specific recommendations. (2) After a query has been retransmitted several times without a response, an implementation MUST give up and return a soft error to the application. (3) All DNS name servers and resolvers SHOULD cache temporary failures, with a timeout period of the order of minutes. DISCUSSION: This will prevent applications that immediately retry soft failures (in violation of Section 2.2 of this document) from generating excessive DNS traffic. (4) All DNS name servers and resolvers SHOULD cache negative responses that indicate the specified name, or data of the specified type, does not exist, as described in [DNS:2]. (5) When a DNS server or resolver retries a UDP query, the retry interval SHOULD be constrained by an exponential backoff algorithm, and SHOULD also have upper and lower bounds. IMPLEMENTATION: A measured RTT and variance (if available) should be used to calculate an initial retransmission interval. If this information is not available, a default of no less than 5 seconds should be used. Implementations may limit the retransmission interval, but this limit must exceed twice the Internet maximum segment lifetime plus service delay at the name server. (6) When a resolver or server receives a Source Quench for
a query it has issued, it SHOULD take steps to reduce
the rate of querying that server in the near future. A
server MAY ignore a Source Quench that it receives as
the result of sending a response datagram.
IMPLEMENTATION:
One recommended action to reduce the rate is to
send the next query attempt to an alternate
server, if there is one available. Another is to
backoff the retry interval for the same server.
6.1.3.4 Multihomed Hosts
When the host name-to-address function encounters a host
with multiple addresses, it SHOULD rank or sort the
addresses using knowledge of the immediately connected
network number(s) and any other applicable performance or
history information.
DISCUSSION:
The different addresses of a multihomed host generally
imply different Internet paths, and some paths may be
preferable to others in performance, reliability, or
administrative restrictions. There is no general way
for the domain system to determine the best path. A
recommended approach is to base this decision on local
configuration information set by the system
administrator.
IMPLEMENTATION:
The following scheme has been used successfully:
(a) Incorporate into the host configuration data a
Network-Preference List, that is simply a list of
networks in preferred order. This list may be
empty if there is no preference.
(b) When a host name is mapped into a list of IP
addresses, these addresses should be sorted by
network number, into the same order as the
corresponding networks in the Network-Preference
List. IP addresses whose networks do not appear
in the Network-Preference List should be placed at
the end of the list.
6.1.3.5 Extensibility DNS software MUST support all well-known, class-independent formats [DNS:2], and SHOULD be written to minimize the trauma associated with the introduction of new well-known types and local experimentation with non-standard types. DISCUSSION: The data types and classes used by the DNS are extensible, and thus new types will be added and old types deleted or redefined. Introduction of new data types ought to be dependent only upon the rules for compression of domain names inside DNS messages, and the translation between printable (i.e., master file) and internal formats for Resource Records (RRs). Compression relies on knowledge of the format of data inside a particular RR. Hence compression must only be used for the contents of well-known, class-independent RRs, and must never be used for class-specific RRs or RR types that are not well-known. The owner name of an RR is always eligible for compression. A name server may acquire, via zone transfer, RRs that the server doesn't know how to convert to printable format. A resolver can receive similar information as the result of queries. For proper operation, this data must be preserved, and hence the implication is that DNS software cannot use textual formats for internal storage. The DNS defines domain name syntax very generally -- a string of labels each containing up to 63 8-bit octets, separated by dots, and with a maximum total of 255 octets. Particular applications of the DNS are permitted to further constrain the syntax of the domain names they use, although the DNS deployment has led to some applications allowing more general names. In particular, Section 2.1 of this document liberalizes slightly the syntax of a legal Internet host name that was defined in RFC-952 [DNS:4]. 6.1.3.6 Status of RR Types Name servers MUST be able to load all RR types except MD and MF from configuration files. The MD and MF types are obsolete and MUST NOT be implemented; in particular, name servers MUST NOT load these types from configuration files.
DISCUSSION:
The RR types MB, MG, MR, NULL, MINFO and RP are
considered experimental, and applications that use the
DNS cannot expect these RR types to be supported by
most domains. Furthermore these types are subject to
redefinition.
The TXT and WKS RR types have not been widely used by
Internet sites; as a result, an application cannot rely
on the the existence of a TXT or WKS RR in most
domains.
6.1.3.7 Robustness
DNS software may need to operate in environments where the
root servers or other servers are unavailable due to network
connectivity or other problems. In this situation, DNS name
servers and resolvers MUST continue to provide service for
the reachable part of the name space, while giving temporary
failures for the rest.
DISCUSSION:
Although the DNS is meant to be used primarily in the
connected Internet, it should be possible to use the
system in networks which are unconnected to the
Internet. Hence implementations must not depend on
access to root servers before providing service for
local names.
6.1.3.8 Local Host Table
DISCUSSION:
A host may use a local host table as a backup or
supplement to the DNS. This raises the question of
which takes precedence, the DNS or the host table; the
most flexible approach would make this a configuration
option.
Typically, the contents of such a supplementary host
table will be determined locally by the site. However,
a publically-available table of Internet hosts is
maintained by the DDN Network Information Center (DDN
NIC), with a format documented in [DNS:4]. This table
can be retrieved from the DDN NIC using a protocol
described in [DNS:5]. It must be noted that this table
contains only a small fraction of all Internet hosts.
Hosts using this protocol to retrieve the DDN NIC host
table should use the VERSION command to check if the
table has changed before requesting the entire table
with the ALL command. The VERSION identifier should be
treated as an arbitrary string and tested only for
equality; no numerical sequence may be assumed.
The DDN NIC host table includes administrative
information that is not needed for host operation and
is therefore not currently included in the DNS
database; examples include network and gateway entries.
However, much of this additional information will be
added to the DNS in the future. Conversely, the DNS
provides essential services (in particular, MX records)
that are not available from the DDN NIC host table.
6.1.4 DNS USER INTERFACE
6.1.4.1 DNS Administration
This document is concerned with design and implementation
issues in host software, not with administrative or
operational issues. However, administrative issues are of
particular importance in the DNS, since errors in particular
segments of this large distributed database can cause poor
or erroneous performance for many sites. These issues are
discussed in [DNS:6] and [DNS:7].
6.1.4.2 DNS User Interface
Hosts MUST provide an interface to the DNS for all
application programs running on the host. This interface
will typically direct requests to a system process to
perform the resolver function [DNS:1, 6.1:2].
At a minimum, the basic interface MUST support a request for
all information of a specific type and class associated with
a specific name, and it MUST return either all of the
requested information, a hard error code, or a soft error
indication. When there is no error, the basic interface
returns the complete response information without
modification, deletion, or ordering, so that the basic
interface will not need to be changed to accommodate new
data types.
DISCUSSION:
The soft error indication is an essential part of the
interface, since it may not always be possible to
access particular information from the DNS; see Section
6.1.3.3.
A host MAY provide other DNS interfaces tailored to
particular functions, transforming the raw domain data into
formats more suited to these functions. In particular, a
host MUST provide a DNS interface to facilitate translation
between host addresses and host names.
6.1.4.3 Interface Abbreviation Facilities
User interfaces MAY provide a method for users to enter
abbreviations for commonly-used names. Although the
definition of such methods is outside of the scope of the
DNS specification, certain rules are necessary to insure
that these methods allow access to the entire DNS name space
and to prevent excessive use of Internet resources.
If an abbreviation method is provided, then:
(a) There MUST be some convention for denoting that a name
is already complete, so that the abbreviation method(s)
are suppressed. A trailing dot is the usual method.
(b) Abbreviation expansion MUST be done exactly once, and
MUST be done in the context in which the name was
entered.
DISCUSSION:
For example, if an abbreviation is used in a mail
program for a destination, the abbreviation should be
expanded into a full domain name and stored in the
queued message with an indication that it is already
complete. Otherwise, the abbreviation might be
expanded with a mail system search list, not the
user's, or a name could grow due to repeated
canonicalizations attempts interacting with wildcards.
The two most common abbreviation methods are:
(1) Interface-level aliases
Interface-level aliases are conceptually implemented as
a list of alias/domain name pairs. The list can be
per-user or per-host, and separate lists can be
associated with different functions, e.g. one list for
host name-to-address translation, and a different list
for mail domains. When the user enters a name, the
interface attempts to match the name to the alias
component of a list entry, and if a matching entry can
be found, the name is replaced by the domain name found
in the pair.
Note that interface-level aliases and CNAMEs are
completely separate mechanisms; interface-level aliases
are a local matter while CNAMEs are an Internet-wide
aliasing mechanism which is a required part of any DNS
implementation.
(2) Search Lists
A search list is conceptually implemented as an ordered
list of domain names. When the user enters a name, the
domain names in the search list are used as suffixes to
the user-supplied name, one by one, until a domain name
with the desired associated data is found, or the
search list is exhausted. Search lists often contain
the name of the local host's parent domain or other
ancestor domains. Search lists are often per-user or
per-process.
It SHOULD be possible for an administrator to disable a
DNS search-list facility. Administrative denial may be
warranted in some cases, to prevent abuse of the DNS.
There is danger that a search-list mechanism will
generate excessive queries to the root servers while
testing whether user input is a complete domain name,
lacking a final period to mark it as complete. A
search-list mechanism MUST have one of, and SHOULD have
both of, the following two provisions to prevent this:
(a) The local resolver/name server can implement
caching of negative responses (see Section
6.1.3.3).
(b) The search list expander can require two or more
interior dots in a generated domain name before it
tries using the name in a query to non-local
domain servers, such as the root.
DISCUSSION:
The intent of this requirement is to avoid
excessive delay for the user as the search list is
tested, and more importantly to prevent excessive
traffic to the root and other high-level servers.
For example, if the user supplied a name "X" and
the search list contained the root as a component,
a query would have to consult a root server before
the next search list alternative could be tried.
The resulting load seen by the root servers and
gateways near the root would be multiplied by the
number of hosts in the Internet.
The negative caching alternative limits the effect
to the first time a name is used. The interior
dot rule is simpler to implement but can prevent
easy use of some top-level names.
6.1.5 DOMAIN NAME SYSTEM REQUIREMENTS SUMMARY
| | | | |S| |
| | | | |H| |F
| | | | |O|M|o
| | |S| |U|U|o
| | |H| |L|S|t
| |M|O| |D|T|n
| |U|U|M| | |o
| |S|L|A|N|N|t
| |T|D|Y|O|O|t
FEATURE |SECTION | | | |T|T|e
-----------------------------------------------|-----------|-|-|-|-|-|--
GENERAL ISSUES | | | | | | |
| | | | | | |
Implement DNS name-to-address conversion |6.1.1 |x| | | | |
Implement DNS address-to-name conversion |6.1.1 |x| | | | |
Support conversions using host table |6.1.1 | | |x| | |
Properly handle RR with zero TTL |6.1.2.1 |x| | | | |
Use QCLASS=* unnecessarily |6.1.2.2 | |x| | | |
Use QCLASS=IN for Internet class |6.1.2.2 |x| | | | |
Unused fields zero |6.1.2.3 |x| | | | |
Use compression in responses |6.1.2.4 |x| | | | |
| | | | | | |
Include config info in responses |6.1.2.5 | | | | |x|
Support all well-known, class-indep. types |6.1.3.5 |x| | | | |
Easily expand type list |6.1.3.5 | |x| | | |
Load all RR types (except MD and MF) |6.1.3.6 |x| | | | |
Load MD or MF type |6.1.3.6 | | | | |x|
Operate when root servers, etc. unavailable |6.1.3.7 |x| | | | |
-----------------------------------------------|-----------|-|-|-|-|-|--
RESOLVER ISSUES: | | | | | | |
| | | | | | |
Resolver support multiple concurrent requests |6.1.3.1 | |x| | | |
Full-service resolver: |6.1.3.1 | | |x| | |
Local caching |6.1.3.1 |x| | | | |
Information in local cache times out |6.1.3.1 |x| | | | |
Configurable with starting info |6.1.3.1 | |x| | | |
Stub resolver: |6.1.3.1 | | |x| | |
Use redundant recursive name servers |6.1.3.1 |x| | | | |
Local caching |6.1.3.1 | | |x| | |
Information in local cache times out |6.1.3.1 |x| | | | |
Support for remote multi-homed hosts: | | | | | | |
Sort multiple addresses by preference list |6.1.3.4 | |x| | | |
| | | | | | |
-----------------------------------------------|-----------|-|-|-|-|-|--
TRANSPORT PROTOCOLS: | | | | | | |
| | | | | | |
Support UDP queries |6.1.3.2 |x| | | | |
Support TCP queries |6.1.3.2 | |x| | | |
Send query using UDP first |6.1.3.2 |x| | | | |1
Try TCP if UDP answers are truncated |6.1.3.2 | |x| | | |
Name server limit TCP query resources |6.1.3.2 | | |x| | |
Punish unnecessary TCP query |6.1.3.2 | | | |x| |
Use truncated data as if it were not |6.1.3.2 | | | | |x|
Private agreement to use only TCP |6.1.3.2 | | |x| | |
Use TCP for zone transfers |6.1.3.2 |x| | | | |
TCP usage not block UDP queries |6.1.3.2 |x| | | | |
Support broadcast or multicast queries |6.1.3.2 | | |x| | |
RD bit set in query |6.1.3.2 | | | | |x|
RD bit ignored by server is b'cast/m'cast |6.1.3.2 |x| | | | |
Send only as occasional probe for addr's |6.1.3.2 | |x| | | |
-----------------------------------------------|-----------|-|-|-|-|-|--
RESOURCE USAGE: | | | | | | |
| | | | | | |
Transmission controls, per [DNS:2] |6.1.3.3 |x| | | | |
Finite bounds per request |6.1.3.3 |x| | | | |
Failure after retries => soft error |6.1.3.3 |x| | | | |
Cache temporary failures |6.1.3.3 | |x| | | |
Cache negative responses |6.1.3.3 | |x| | | |
Retries use exponential backoff |6.1.3.3 | |x| | | |
Upper, lower bounds |6.1.3.3 | |x| | | |
Client handle Source Quench |6.1.3.3 | |x| | | |
Server ignore Source Quench |6.1.3.3 | | |x| | |
-----------------------------------------------|-----------|-|-|-|-|-|--
USER INTERFACE: | | | | | | |
| | | | | | |
All programs have access to DNS interface |6.1.4.2 |x| | | | |
Able to request all info for given name |6.1.4.2 |x| | | | |
Returns complete info or error |6.1.4.2 |x| | | | |
Special interfaces |6.1.4.2 | | |x| | |
Name<->Address translation |6.1.4.2 |x| | | | |
| | | | | | |
Abbreviation Facilities: |6.1.4.3 | | |x| | |
Convention for complete names |6.1.4.3 |x| | | | |
Conversion exactly once |6.1.4.3 |x| | | | |
Conversion in proper context |6.1.4.3 |x| | | | |
Search list: |6.1.4.3 | | |x| | |
Administrator can disable |6.1.4.3 | |x| | | |
Prevention of excessive root queries |6.1.4.3 |x| | | | |
Both methods |6.1.4.3 | |x| | | |
-----------------------------------------------|-----------|-|-|-|-|-|--
-----------------------------------------------|-----------|-|-|-|-|-|--
1. Unless there is private agreement between particular resolver and
particular server.
6.2 HOST INITIALIZATION 6.2.1 INTRODUCTION This section discusses the initialization of host software across a connected network, or more generally across an Internet path. This is necessary for a diskless host, and may optionally be used for a host with disk drives. For a diskless host, the initialization process is called "network booting" and is controlled by a bootstrap program located in a boot ROM. To initialize a diskless host across the network, there are two distinct phases: (1) Configure the IP layer. Diskless machines often have no permanent storage in which to store network configuration information, so that sufficient configuration information must be obtained dynamically to support the loading phase that follows. This information must include at least the IP addresses of the host and of the boot server. To support booting across a gateway, the address mask and a list of default gateways are also required. (2) Load the host system code. During the loading phase, an appropriate file transfer protocol is used to copy the system code across the network from the boot server. A host with a disk may perform the first step, dynamic configuration. This is important for microcomputers, whose floppy disks allow network configuration information to be mistakenly duplicated on more than one host. Also, installation of new hosts is much simpler if they automatically obtain their configuration information from a central server, saving administrator time and decreasing the probability of mistakes. 6.2.2 REQUIREMENTS 6.2.2.1 Dynamic Configuration A number of protocol provisions have been made for dynamic configuration. o ICMP Information Request/Reply messages
This obsolete message pair was designed to allow a host
to find the number of the network it is on.
Unfortunately, it was useful only if the host already
knew the host number part of its IP address,
information that hosts requiring dynamic configuration
seldom had.
o Reverse Address Resolution Protocol (RARP) [BOOT:4]
RARP is a link-layer protocol for a broadcast medium
that allows a host to find its IP address given its
link layer address. Unfortunately, RARP does not work
across IP gateways and therefore requires a RARP server
on every network. In addition, RARP does not provide
any other configuration information.
o ICMP Address Mask Request/Reply messages
These ICMP messages allow a host to learn the address
mask for a particular network interface.
o BOOTP Protocol [BOOT:2]
This protocol allows a host to determine the IP
addresses of the local host and the boot server, the
name of an appropriate boot file, and optionally the
address mask and list of default gateways. To locate a
BOOTP server, the host broadcasts a BOOTP request using
UDP. Ad hoc gateway extensions have been used to
transmit the BOOTP broadcast through gateways, and in
the future the IP Multicasting facility will provide a
standard mechanism for this purpose.
The suggested approach to dynamic configuration is to use
the BOOTP protocol with the extensions defined in "BOOTP
Vendor Information Extensions" RFC-1084 [BOOT:3]. RFC-1084
defines some important general (not vendor-specific)
extensions. In particular, these extensions allow the
address mask to be supplied in BOOTP; we RECOMMEND that the
address mask be supplied in this manner.
DISCUSSION:
Historically, subnetting was defined long after IP, and
so a separate mechanism (ICMP Address Mask messages)
was designed to supply the address mask to a host.
However, the IP address mask and the corresponding IP
address conceptually form a pair, and for operational
simplicity they ought to be defined at the same time
and by the same mechanism, whether a configuration file
or a dynamic mechanism like BOOTP.
Note that BOOTP is not sufficiently general to specify
the configurations of all interfaces of a multihomed
host. A multihomed host must either use BOOTP
separately for each interface, or configure one
interface using BOOTP to perform the loading, and
perform the complete initialization from a file later.
Application layer configuration information is expected
to be obtained from files after loading of the system
code.
6.2.2.2 Loading Phase
A suggested approach for the loading phase is to use TFTP
[BOOT:1] between the IP addresses established by BOOTP.
TFTP to a broadcast address SHOULD NOT be used, for reasons
explained in Section 4.2.3.4.
6.3 REMOTE MANAGEMENT 6.3.1 INTRODUCTION The Internet community has recently put considerable effort into the development of network management protocols. The result has been a two-pronged approach [MGT:1, MGT:6]: the Simple Network Management Protocol (SNMP) [MGT:4] and the Common Management Information Protocol over TCP (CMOT) [MGT:5]. In order to be managed using SNMP or CMOT, a host will need to implement an appropriate management agent. An Internet host SHOULD include an agent for either SNMP or CMOT. Both SNMP and CMOT operate on a Management Information Base (MIB) that defines a collection of management values. By reading and setting these values, a remote application may query and change the state of the managed system. A standard MIB [MGT:3] has been defined for use by both management protocols, using data types defined by the Structure of Management Information (SMI) defined in [MGT:2]. Additional MIB variables can be introduced under the "enterprises" and "experimental" subtrees of the MIB naming space [MGT:2]. Every protocol module in the host SHOULD implement the relevant MIB variables. A host SHOULD implement the MIB variables as defined in the most recent standard MIB, and MAY implement other MIB variables when appropriate and useful. 6.3.2 PROTOCOL WALK-THROUGH The MIB is intended to cover both hosts and gateways, although there may be detailed differences in MIB application to the two cases. This section contains the appropriate interpretation of the MIB for hosts. It is likely that later versions of the MIB will include more entries for host management. A managed host must implement the following groups of MIB object definitions: System, Interfaces, Address Translation, IP, ICMP, TCP, and UDP. The following specific interpretations apply to hosts: o ipInHdrErrors Note that the error "time-to-live exceeded" can occur in a host only when it is forwarding a source-routed datagram.
o ipOutNoRoutes
This object counts datagrams discarded because no route
can be found. This may happen in a host if all the
default gateways in the host's configuration are down.
o ipFragOKs, ipFragFails, ipFragCreates
A host that does not implement intentional fragmentation
(see "Fragmentation" section of [INTRO:1]) MUST return the
value zero for these three objects.
o icmpOutRedirects
For a host, this object MUST always be zero, since hosts
do not send Redirects.
o icmpOutAddrMaskReps
For a host, this object MUST always be zero, unless the
host is an authoritative source of address mask
information.
o ipAddrTable
For a host, the "IP Address Table" object is effectively a
table of logical interfaces.
o ipRoutingTable
For a host, the "IP Routing Table" object is effectively a
combination of the host's Routing Cache and the static
route table described in "Routing Outbound Datagrams"
section of [INTRO:1].
Within each ipRouteEntry, ipRouteMetric1...4 normally will
have no meaning for a host and SHOULD always be -1, while
ipRouteType will normally have the value "remote".
If destinations on the connected network do not appear in
the Route Cache (see "Routing Outbound Datagrams section
of [INTRO:1]), there will be no entries with ipRouteType
of "direct".
DISCUSSION:
The current MIB does not include Type-of-Service in an
ipRouteEntry, but a future revision is expected to make
this addition.
We also expect the MIB to be expanded to allow the remote
management of applications (e.g., the ability to partially
reconfigure mail systems). Network service applications
such as mail systems should therefore be written with the
"hooks" for remote management.
6.3.3 MANAGEMENT REQUIREMENTS SUMMARY
| | | | |S| |
| | | | |H| |F
| | | | |O|M|o
| | |S| |U|U|o
| | |H| |L|S|t
| |M|O| |D|T|n
| |U|U|M| | |o
| |S|L|A|N|N|t
| |T|D|Y|O|O|t
FEATURE |SECTION | | | |T|T|e
-----------------------------------------------|-----------|-|-|-|-|-|--
Support SNMP or CMOT agent |6.3.1 | |x| | | |
Implement specified objects in standard MIB |6.3.1 | |x| | | |
7. REFERENCES This section lists the primary references with which every implementer must be thoroughly familiar. It also lists some secondary references that are suggested additional reading. INTRODUCTORY REFERENCES: [INTRO:1] "Requirements for Internet Hosts -- Communication Layers," IETF Host Requirements Working Group, R. Braden, Ed., RFC-1122, October 1989. [INTRO:2] "DDN Protocol Handbook," NIC-50004, NIC-50005, NIC-50006, (three volumes), SRI International, December 1985. [INTRO:3] "Official Internet Protocols," J. Reynolds and J. Postel, RFC-1011, May 1987. This document is republished periodically with new RFC numbers; the latest version must be used. [INTRO:4] "Protocol Document Order Information," O. Jacobsen and J. Postel, RFC-980, March 1986. [INTRO:5] "Assigned Numbers," J. Reynolds and J. Postel, RFC-1010, May 1987. This document is republished periodically with new RFC numbers; the latest version must be used. TELNET REFERENCES: [TELNET:1] "Telnet Protocol Specification," J. Postel and J. Reynolds, RFC-854, May 1983. [TELNET:2] "Telnet Option Specification," J. Postel and J. Reynolds, RFC-855, May 1983. [TELNET:3] "Telnet Binary Transmission," J. Postel and J. Reynolds, RFC-856, May 1983. [TELNET:4] "Telnet Echo Option," J. Postel and J. Reynolds, RFC-857, May 1983. [TELNET:5] "Telnet Suppress Go Ahead Option," J. Postel and J.
Reynolds, RFC-858, May 1983.
[TELNET:6] "Telnet Status Option," J. Postel and J. Reynolds, RFC-
859, May 1983.
[TELNET:7] "Telnet Timing Mark Option," J. Postel and J. Reynolds,
RFC-860, May 1983.
[TELNET:8] "Telnet Extended Options List," J. Postel and J.
Reynolds, RFC-861, May 1983.
[TELNET:9] "Telnet End-Of-Record Option," J. Postel, RFC-855,
December 1983.
[TELNET:10] "Telnet Terminal-Type Option," J. VanBokkelen, RFC-1091,
February 1989.
This document supercedes RFC-930.
[TELNET:11] "Telnet Window Size Option," D. Waitzman, RFC-1073,
October 1988.
[TELNET:12] "Telnet Linemode Option," D. Borman, RFC-1116, August
1989.
[TELNET:13] "Telnet Terminal Speed Option," C. Hedrick, RFC-1079,
December 1988.
[TELNET:14] "Telnet Remote Flow Control Option," C. Hedrick, RFC-
1080, November 1988.
SECONDARY TELNET REFERENCES:
[TELNET:15] "Telnet Protocol," MIL-STD-1782, U.S. Department of
Defense, May 1984.
This document is intended to describe the same protocol as RFC-
854. In case of conflict, RFC-854 takes precedence, and the
present document takes precedence over both.
[TELNET:16] "SUPDUP Protocol," M. Crispin, RFC-734, October 1977.
[TELNET:17] "Telnet SUPDUP Option," M. Crispin, RFC-736, October
1977.
[TELNET:18] "Data Entry Terminal Option," J. Day, RFC-732, June 1977.
[TELNET:19] "TELNET Data Entry Terminal option -- DODIIS Implementation," A. Yasuda and T. Thompson, RFC-1043, February 1988. FTP REFERENCES: [FTP:1] "File Transfer Protocol," J. Postel and J. Reynolds, RFC- 959, October 1985. [FTP:2] "Document File Format Standards," J. Postel, RFC-678, December 1974. [FTP:3] "File Transfer Protocol," MIL-STD-1780, U.S. Department of Defense, May 1984. This document is based on an earlier version of the FTP specification (RFC-765) and is obsolete. TFTP REFERENCES: [TFTP:1] "The TFTP Protocol Revision 2," K. Sollins, RFC-783, June 1981. MAIL REFERENCES: [SMTP:1] "Simple Mail Transfer Protocol," J. Postel, RFC-821, August 1982. [SMTP:2] "Standard For The Format of ARPA Internet Text Messages," D. Crocker, RFC-822, August 1982. This document obsoleted an earlier specification, RFC-733. [SMTP:3] "Mail Routing and the Domain System," C. Partridge, RFC- 974, January 1986. This RFC describes the use of MX records, a mandatory extension to the mail delivery process. [SMTP:4] "Duplicate Messages and SMTP," C. Partridge, RFC-1047, February 1988.
[SMTP:5a] "Mapping between X.400 and RFC 822," S. Kille, RFC-987, June 1986. [SMTP:5b] "Addendum to RFC-987," S. Kille, RFC-???, September 1987. The two preceding RFC's define a proposed standard for gatewaying mail between the Internet and the X.400 environments. [SMTP:6] "Simple Mail Transfer Protocol," MIL-STD-1781, U.S. Department of Defense, May 1984. This specification is intended to describe the same protocol as does RFC-821. However, MIL-STD-1781 is incomplete; in particular, it does not include MX records [SMTP:3]. [SMTP:7] "A Content-Type Field for Internet Messages," M. Sirbu, RFC-1049, March 1988. DOMAIN NAME SYSTEM REFERENCES: [DNS:1] "Domain Names - Concepts and Facilities," P. Mockapetris, RFC-1034, November 1987. This document and the following one obsolete RFC-882, RFC-883, and RFC-973. [DNS:2] "Domain Names - Implementation and Specification," RFC-1035, P. Mockapetris, November 1987. [DNS:3] "Mail Routing and the Domain System," C. Partridge, RFC-974, January 1986. [DNS:4] "DoD Internet Host Table Specification," K. Harrenstein, RFC-952, M. Stahl, E. Feinler, October 1985. SECONDARY DNS REFERENCES: [DNS:5] "Hostname Server," K. Harrenstein, M. Stahl, E. Feinler, RFC-953, October 1985. [DNS:6] "Domain Administrators Guide," M. Stahl, RFC-1032, November 1987.
[DNS:7] "Domain Administrators Operations Guide," M. Lottor, RFC- 1033, November 1987. [DNS:8] "The Domain Name System Handbook," Vol. 4 of Internet Protocol Handbook, NIC 50007, SRI Network Information Center, August 1989. SYSTEM INITIALIZATION REFERENCES: [BOOT:1] "Bootstrap Loading Using TFTP," R. Finlayson, RFC-906, June 1984. [BOOT:2] "Bootstrap Protocol (BOOTP)," W. Croft and J. Gilmore, RFC- 951, September 1985. [BOOT:3] "BOOTP Vendor Information Extensions," J. Reynolds, RFC- 1084, December 1988. Note: this RFC revised and obsoleted RFC-1048. [BOOT:4] "A Reverse Address Resolution Protocol," R. Finlayson, T. Mann, J. Mogul, and M. Theimer, RFC-903, June 1984. MANAGEMENT REFERENCES: [MGT:1] "IAB Recommendations for the Development of Internet Network Management Standards," V. Cerf, RFC-1052, April 1988. [MGT:2] "Structure and Identification of Management Information for TCP/IP-based internets," M. Rose and K. McCloghrie, RFC-1065, August 1988. [MGT:3] "Management Information Base for Network Management of TCP/IP-based internets," M. Rose and K. McCloghrie, RFC-1066, August 1988. [MGT:4] "A Simple Network Management Protocol," J. Case, M. Fedor, M. Schoffstall, and C. Davin, RFC-1098, April 1989. [MGT:5] "The Common Management Information Services and Protocol over TCP/IP," U. Warrier and L. Besaw, RFC-1095, April 1989. [MGT:6] "Report of the Second Ad Hoc Network Management Review Group," V. Cerf, RFC-1109, August 1989.
Security Considerations There are many security issues in the application and support programs of host software, but a full discussion is beyond the scope of this RFC. Security-related issues are mentioned in sections concerning TFTP (Sections 4.2.1, 4.2.3.4, 4.2.3.5), the SMTP VRFY and EXPN commands (Section 5.2.3), the SMTP HELO command (5.2.5), and the SMTP DATA command (Section 5.2.8). Author's Address Robert Braden USC/Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292-6695 Phone: (213) 822 1511 EMail: Braden@ISI.EDU