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