Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 1123

Requirements for Internet Hosts - Application and Support

Pages: 98
Internet Standard: 3
STD 3 is also:  1122
Updates:  08220952
Updated by:  134921815321596677669210
Part 4 of 4 – Pages 72 to 98
First   Prev   None

Top   ToC   RFC1123 - Page 72   prevText


      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 for more information on this

              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


         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.
Top   ToC   RFC1123 - Page 73  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.

                 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.
  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.
  Unused Fields: RFC-1035 Section 4.1.1

            Unused fields in a query or response message MUST be zero.
  Compression: RFC-1035 Section 4.1.4

            Name servers MUST use compression in responses.

                 Compression is essential to avoid overflowing UDP
                 datagrams; see Section
  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

                 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.
Top   ToC   RFC1123 - Page 74
      6.1.3  SPECIFIC ISSUES
  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

            (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.
Top   ToC   RFC1123 - Page 75
                 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

  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

            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

                 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.
Top   ToC   RFC1123 - Page 76
                 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

                 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.

                 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.
Top   ToC   RFC1123 - Page 77  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.

                      This will prevent applications that immediately
                      retry soft failures (in violation of Section 2.2
                      of this document) from generating excessive DNS

            (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

                      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
Top   ToC   RFC1123 - Page 78
                 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.

                      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.

  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.

                 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

                 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.
Top   ToC   RFC1123 - Page 79  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.

                 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

                 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].
  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.
Top   ToC   RFC1123 - Page 80
                 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

                 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

            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.

                 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.
  Local Host Table

                 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

                 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
Top   ToC   RFC1123 - Page 81
                 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.

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

                 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
Top   ToC   RFC1123 - Page 82
            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.
 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

                 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
Top   ToC   RFC1123 - Page 83
                 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

            (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

                 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

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

                      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,
Top   ToC   RFC1123 - Page 84
                      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.


                                               |           | | | |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               |    |x| | | | |
Use QCLASS=* unnecessarily                     |    | |x| | | |
  Use QCLASS=IN for Internet class             |    |x| | | | |
Unused fields zero                             |    |x| | | | |
Use compression in responses                   |    |x| | | | |
                                               |           | | | | | |
Include config info in responses               |    | | | | |x|
Support all well-known, class-indep. types     |    |x| | | | |
Easily expand type list                        |    | |x| | | |
Load all RR types (except MD and MF)           |    |x| | | | |
Load MD or MF type                             |    | | | | |x|
Operate when root servers, etc. unavailable    |    |x| | | | |
RESOLVER ISSUES:                               |           | | | | | |
                                               |           | | | | | |
Resolver support multiple concurrent requests  |    | |x| | | |
Full-service resolver:                         |    | | |x| | |
  Local caching                                |    |x| | | | |
Top   ToC   RFC1123 - Page 85
  Information in local cache times out         |    |x| | | | |
  Configurable with starting info              |    | |x| | | |
Stub resolver:                                 |    | | |x| | |
  Use redundant recursive name servers         |    |x| | | | |
  Local caching                                |    | | |x| | |
  Information in local cache times out         |    |x| | | | |
Support for remote multi-homed hosts:          |           | | | | | |
  Sort multiple addresses by preference list   |    | |x| | | |
                                               |           | | | | | |
TRANSPORT PROTOCOLS:                           |           | | | | | |
                                               |           | | | | | |
Support UDP queries                            |    |x| | | | |
Support TCP queries                            |    | |x| | | |
  Send query using UDP first                   |    |x| | | | |1
  Try TCP if UDP answers are truncated         |    | |x| | | |
Name server limit TCP query resources          |    | | |x| | |
  Punish unnecessary TCP query                 |    | | | |x| |
Use truncated data as if it were not           |    | | | | |x|
Private agreement to use only TCP              |    | | |x| | |
Use TCP for zone transfers                     |    |x| | | | |
TCP usage not block UDP queries                |    |x| | | | |
Support broadcast or multicast queries         |    | | |x| | |
  RD bit set in query                          |    | | | | |x|
  RD bit ignored by server is b'cast/m'cast    |    |x| | | | |
  Send only as occasional probe for addr's     |    | |x| | | |
RESOURCE USAGE:                                |           | | | | | |
                                               |           | | | | | |
Transmission controls, per [DNS:2]             |    |x| | | | |
  Finite bounds per request                    |    |x| | | | |
Failure after retries => soft error            |    |x| | | | |
Cache temporary failures                       |    | |x| | | |
Cache negative responses                       |    | |x| | | |
Retries use exponential backoff                |    | |x| | | |
  Upper, lower bounds                          |    | |x| | | |
Client handle Source Quench                    |    | |x| | | |
Server ignore Source Quench                    |    | | |x| | |
USER INTERFACE:                                |           | | | | | |
                                               |           | | | | | |
All programs have access to DNS interface      |    |x| | | | |
Able to request all info for given name        |    |x| | | | |
Returns complete info or error                 |    |x| | | | |
Special interfaces                             |    | | |x| | |
  Name<->Address translation                   |    |x| | | | |
                                               |           | | | | | |
Abbreviation Facilities:                       |    | | |x| | |
Top   ToC   RFC1123 - Page 86
  Convention for complete names                |    |x| | | | |
  Conversion exactly once                      |    |x| | | | |
  Conversion in proper context                 |    |x| | | | |
  Search list:                                 |    | | |x| | |
    Administrator can disable                  |    | |x| | | |
    Prevention of excessive root queries       |    |x| | | | |
      Both methods                             |    | |x| | | |

1.   Unless there is private agreement between particular resolver and
     particular server.
Top   ToC   RFC1123 - Page 87

      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

      6.2.2  REQUIREMENTS
  Dynamic Configuration

            A number of protocol provisions have been made for dynamic

            o    ICMP Information Request/Reply messages
Top   ToC   RFC1123 - Page 88
                 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.

                 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
Top   ToC   RFC1123 - Page 89
                 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
  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
Top   ToC   RFC1123 - Page 90

      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.


         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.
Top   ToC   RFC1123 - Page 91
         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

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

              The current MIB does not include Type-of-Service in an
              ipRouteEntry, but a future revision is expected to make
Top   ToC   RFC1123 - Page 92
              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.


                                               |           | | | |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| | | |
Top   ToC   RFC1123 - Page 93

   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.


   [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: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.
Top   ToC   RFC1123 - Page 94
        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

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


   [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

   [TELNET:18] "Data Entry Terminal Option," J. Day, RFC-732, June 1977.
Top   ToC   RFC1123 - Page 95
   [TELNET:19] "TELNET Data Entry Terminal option -- DODIIS
        Implementation," A. Yasuda and T. Thompson, RFC-1043, February


   [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:1]  "The TFTP Protocol Revision 2," K. Sollins, RFC-783, June


   [SMTP:1]  "Simple Mail Transfer Protocol," J. Postel, RFC-821, August

   [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.
Top   ToC   RFC1123 - Page 96
   [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.


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


   [DNS:5]  "Hostname Server," K. Harrenstein, M. Stahl, E. Feinler,
        RFC-953, October 1985.

   [DNS:6]  "Domain Administrators Guide," M. Stahl, RFC-1032, November
Top   ToC   RFC1123 - Page 97
   [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.


   [BOOT:1] "Bootstrap Loading Using TFTP," R. Finlayson, RFC-906, June

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


   [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.
Top   ToC   RFC1123 - Page 98
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,,, 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