+++ /dev/null
-Network Working Group P. Mockapetris
-Request for Comments: 1035 ISI
- November 1987
-Obsoletes: RFCs 882, 883, 973
-
- DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
-
-
-1. STATUS OF THIS MEMO
-
-This RFC describes the details of the domain system and protocol, and
-assumes that the reader is familiar with the concepts discussed in a
-companion RFC, "Domain Names - Concepts and Facilities" [RFC-1034].
-
-The domain system is a mixture of functions and data types which are an
-official protocol and functions and data types which are still
-experimental. Since the domain system is intentionally extensible, new
-data types and experimental behavior should always be expected in parts
-of the system beyond the official protocol. The official protocol parts
-include standard queries, responses and the Internet class RR data
-formats (e.g., host addresses). Since the previous RFC set, several
-definitions have changed, so some previous definitions are obsolete.
-
-Experimental or obsolete features are clearly marked in these RFCs, and
-such information should be used with caution.
-
-The reader is especially cautioned not to depend on the values which
-appear in examples to be current or complete, since their purpose is
-primarily pedagogical. Distribution of this memo is unlimited.
-
- Table of Contents
-
- 1. STATUS OF THIS MEMO 1
- 2. INTRODUCTION 3
- 2.1. Overview 3
- 2.2. Common configurations 4
- 2.3. Conventions 7
- 2.3.1. Preferred name syntax 7
- 2.3.2. Data Transmission Order 8
- 2.3.3. Character Case 9
- 2.3.4. Size limits 10
- 3. DOMAIN NAME SPACE AND RR DEFINITIONS 10
- 3.1. Name space definitions 10
- 3.2. RR definitions 11
- 3.2.1. Format 11
- 3.2.2. TYPE values 12
- 3.2.3. QTYPE values 12
- 3.2.4. CLASS values 13
-
-
-
-Mockapetris [Page 1]
-\f
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- 3.2.5. QCLASS values 13
- 3.3. Standard RRs 13
- 3.3.1. CNAME RDATA format 14
- 3.3.2. HINFO RDATA format 14
- 3.3.3. MB RDATA format (EXPERIMENTAL) 14
- 3.3.4. MD RDATA format (Obsolete) 15
- 3.3.5. MF RDATA format (Obsolete) 15
- 3.3.6. MG RDATA format (EXPERIMENTAL) 16
- 3.3.7. MINFO RDATA format (EXPERIMENTAL) 16
- 3.3.8. MR RDATA format (EXPERIMENTAL) 17
- 3.3.9. MX RDATA format 17
- 3.3.10. NULL RDATA format (EXPERIMENTAL) 17
- 3.3.11. NS RDATA format 18
- 3.3.12. PTR RDATA format 18
- 3.3.13. SOA RDATA format 19
- 3.3.14. TXT RDATA format 20
- 3.4. ARPA Internet specific RRs 20
- 3.4.1. A RDATA format 20
- 3.4.2. WKS RDATA format 21
- 3.5. IN-ADDR.ARPA domain 22
- 3.6. Defining new types, classes, and special namespaces 24
- 4. MESSAGES 25
- 4.1. Format 25
- 4.1.1. Header section format 26
- 4.1.2. Question section format 28
- 4.1.3. Resource record format 29
- 4.1.4. Message compression 30
- 4.2. Transport 32
- 4.2.1. UDP usage 32
- 4.2.2. TCP usage 32
- 5. MASTER FILES 33
- 5.1. Format 33
- 5.2. Use of master files to define zones 35
- 5.3. Master file example 36
- 6. NAME SERVER IMPLEMENTATION 37
- 6.1. Architecture 37
- 6.1.1. Control 37
- 6.1.2. Database 37
- 6.1.3. Time 39
- 6.2. Standard query processing 39
- 6.3. Zone refresh and reload processing 39
- 6.4. Inverse queries (Optional) 40
- 6.4.1. The contents of inverse queries and responses 40
- 6.4.2. Inverse query and response example 41
- 6.4.3. Inverse query processing 42
-
-
-
-
-
-
-Mockapetris [Page 2]
-\f
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- 6.5. Completion queries and responses 42
- 7. RESOLVER IMPLEMENTATION 43
- 7.1. Transforming a user request into a query 43
- 7.2. Sending the queries 44
- 7.3. Processing responses 46
- 7.4. Using the cache 47
- 8. MAIL SUPPORT 47
- 8.1. Mail exchange binding 48
- 8.2. Mailbox binding (Experimental) 48
- 9. REFERENCES and BIBLIOGRAPHY 50
- Index 54
-
-2. INTRODUCTION
-
-2.1. Overview
-
-The goal of domain names is to provide a mechanism for naming resources
-in such a way that the names are usable in different hosts, networks,
-protocol families, internets, and administrative organizations.
-
-From the user's point of view, domain names are useful as arguments to a
-local agent, called a resolver, which retrieves information associated
-with the domain name. Thus a user might ask for the host address or
-mail information associated with a particular domain name. To enable
-the user to request a particular type of information, an appropriate
-query type is passed to the resolver with the domain name. To the user,
-the domain tree is a single information space; the resolver is
-responsible for hiding the distribution of data among name servers from
-the user.
-
-From the resolver's point of view, the database that makes up the domain
-space is distributed among various name servers. Different parts of the
-domain space are stored in different name servers, although a particular
-data item will be stored redundantly in two or more name servers. The
-resolver starts with knowledge of at least one name server. When the
-resolver processes a user query it asks a known name server for the
-information; in return, the resolver either receives the desired
-information or a referral to another name server. Using these
-referrals, resolvers learn the identities and contents of other name
-servers. Resolvers are responsible for dealing with the distribution of
-the domain space and dealing with the effects of name server failure by
-consulting redundant databases in other servers.
-
-Name servers manage two kinds of data. The first kind of data held in
-sets called zones; each zone is the complete database for a particular
-"pruned" subtree of the domain space. This data is called
-authoritative. A name server periodically checks to make sure that its
-zones are up to date, and if not, obtains a new copy of updated zones
-
-
-
-Mockapetris [Page 3]
-\f
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-from master files stored locally or in another name server. The second
-kind of data is cached data which was acquired by a local resolver.
-This data may be incomplete, but improves the performance of the
-retrieval process when non-local data is repeatedly accessed. Cached
-data is eventually discarded by a timeout mechanism.
-
-This functional structure isolates the problems of user interface,
-failure recovery, and distribution in the resolvers and isolates the
-database update and refresh problems in the name servers.
-
-2.2. Common configurations
-
-A host can participate in the domain name system in a number of ways,
-depending on whether the host runs programs that retrieve information
-from the domain system, name servers that answer queries from other
-hosts, or various combinations of both functions. The simplest, and
-perhaps most typical, configuration is shown below:
-
- Local Host | Foreign
- |
- +---------+ +----------+ | +--------+
- | | user queries | |queries | | |
- | User |-------------->| |---------|->|Foreign |
- | Program | | Resolver | | | Name |
- | |<--------------| |<--------|--| Server |
- | | user responses| |responses| | |
- +---------+ +----------+ | +--------+
- | A |
- cache additions | | references |
- V | |
- +----------+ |
- | cache | |
- +----------+ |
-
-User programs interact with the domain name space through resolvers; the
-format of user queries and user responses is specific to the host and
-its operating system. User queries will typically be operating system
-calls, and the resolver and its cache will be part of the host operating
-system. Less capable hosts may choose to implement the resolver as a
-subroutine to be linked in with every program that needs its services.
-Resolvers answer user queries with information they acquire via queries
-to foreign name servers and the local cache.
-
-Note that the resolver may have to make several queries to several
-different foreign name servers to answer a particular user query, and
-hence the resolution of a user query may involve several network
-accesses and an arbitrary amount of time. The queries to foreign name
-servers and the corresponding responses have a standard format described
-
-
-
-Mockapetris [Page 4]
-\f
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-in this memo, and may be datagrams.
-
-Depending on its capabilities, a name server could be a stand alone
-program on a dedicated machine or a process or processes on a large
-timeshared host. A simple configuration might be:
-
- Local Host | Foreign
- |
- +---------+ |
- / /| |
- +---------+ | +----------+ | +--------+
- | | | | |responses| | |
- | | | | Name |---------|->|Foreign |
- | Master |-------------->| Server | | |Resolver|
- | files | | | |<--------|--| |
- | |/ | | queries | +--------+
- +---------+ +----------+ |
-
-Here a primary name server acquires information about one or more zones
-by reading master files from its local file system, and answers queries
-about those zones that arrive from foreign resolvers.
-
-The DNS requires that all zones be redundantly supported by more than
-one name server. Designated secondary servers can acquire zones and
-check for updates from the primary server using the zone transfer
-protocol of the DNS. This configuration is shown below:
-
- Local Host | Foreign
- |
- +---------+ |
- / /| |
- +---------+ | +----------+ | +--------+
- | | | | |responses| | |
- | | | | Name |---------|->|Foreign |
- | Master |-------------->| Server | | |Resolver|
- | files | | | |<--------|--| |
- | |/ | | queries | +--------+
- +---------+ +----------+ |
- A |maintenance | +--------+
- | +------------|->| |
- | queries | |Foreign |
- | | | Name |
- +------------------|--| Server |
- maintenance responses | +--------+
-
-In this configuration, the name server periodically establishes a
-virtual circuit to a foreign name server to acquire a copy of a zone or
-to check that an existing copy has not changed. The messages sent for
-
-
-
-Mockapetris [Page 5]
-\f
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-these maintenance activities follow the same form as queries and
-responses, but the message sequences are somewhat different.
-
-The information flow in a host that supports all aspects of the domain
-name system is shown below:
-
- Local Host | Foreign
- |
- +---------+ +----------+ | +--------+
- | | user queries | |queries | | |
- | User |-------------->| |---------|->|Foreign |
- | Program | | Resolver | | | Name |
- | |<--------------| |<--------|--| Server |
- | | user responses| |responses| | |
- +---------+ +----------+ | +--------+
- | A |
- cache additions | | references |
- V | |
- +----------+ |
- | Shared | |
- | database | |
- +----------+ |
- A | |
- +---------+ refreshes | | references |
- / /| | V |
- +---------+ | +----------+ | +--------+
- | | | | |responses| | |
- | | | | Name |---------|->|Foreign |
- | Master |-------------->| Server | | |Resolver|
- | files | | | |<--------|--| |
- | |/ | | queries | +--------+
- +---------+ +----------+ |
- A |maintenance | +--------+
- | +------------|->| |
- | queries | |Foreign |
- | | | Name |
- +------------------|--| Server |
- maintenance responses | +--------+
-
-The shared database holds domain space data for the local name server
-and resolver. The contents of the shared database will typically be a
-mixture of authoritative data maintained by the periodic refresh
-operations of the name server and cached data from previous resolver
-requests. The structure of the domain data and the necessity for
-synchronization between name servers and resolvers imply the general
-characteristics of this database, but the actual format is up to the
-local implementor.
-
-
-
-
-Mockapetris [Page 6]
-\f
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-Information flow can also be tailored so that a group of hosts act
-together to optimize activities. Sometimes this is done to offload less
-capable hosts so that they do not have to implement a full resolver.
-This can be appropriate for PCs or hosts which want to minimize the
-amount of new network code which is required. This scheme can also
-allow a group of hosts can share a small number of caches rather than
-maintaining a large number of separate caches, on the premise that the
-centralized caches will have a higher hit ratio. In either case,
-resolvers are replaced with stub resolvers which act as front ends to
-resolvers located in a recursive server in one or more name servers
-known to perform that service:
-
- Local Hosts | Foreign
- |
- +---------+ |
- | | responses |
- | Stub |<--------------------+ |
- | Resolver| | |
- | |----------------+ | |
- +---------+ recursive | | |
- queries | | |
- V | |
- +---------+ recursive +----------+ | +--------+
- | | queries | |queries | | |
- | Stub |-------------->| Recursive|---------|->|Foreign |
- | Resolver| | Server | | | Name |
- | |<--------------| |<--------|--| Server |
- +---------+ responses | |responses| | |
- +----------+ | +--------+
- | Central | |
- | cache | |
- +----------+ |
-
-In any case, note that domain components are always replicated for
-reliability whenever possible.
-
-2.3. Conventions
-
-The domain system has several conventions dealing with low-level, but
-fundamental, issues. While the implementor is free to violate these
-conventions WITHIN HIS OWN SYSTEM, he must observe these conventions in
-ALL behavior observed from other hosts.
-
-2.3.1. Preferred name syntax
-
-The DNS specifications attempt to be as general as possible in the rules
-for constructing domain names. The idea is that the name of any
-existing object can be expressed as a domain name with minimal changes.
-
-
-
-Mockapetris [Page 7]
-\f
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-However, when assigning a domain name for an object, the prudent user
-will select a name which satisfies both the rules of the domain system
-and any existing rules for the object, whether these rules are published
-or implied by existing programs.
-
-For example, when naming a mail domain, the user should satisfy both the
-rules of this memo and those in RFC-822. When creating a new host name,
-the old rules for HOSTS.TXT should be followed. This avoids problems
-when old software is converted to use domain names.
-
-The following syntax will result in fewer problems with many
-
-applications that use domain names (e.g., mail, TELNET).
-
-<domain> ::= <subdomain> | " "
-
-<subdomain> ::= <label> | <subdomain> "." <label>
-
-<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
-
-<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
-
-<let-dig-hyp> ::= <let-dig> | "-"
-
-<let-dig> ::= <letter> | <digit>
-
-<letter> ::= any one of the 52 alphabetic characters A through Z in
-upper case and a through z in lower case
-
-<digit> ::= any one of the ten digits 0 through 9
-
-Note that while upper and lower case letters are allowed in domain
-names, no significance is attached to the case. That is, two names with
-the same spelling but different case are to be treated as if identical.
-
-The labels must follow the rules for ARPANET host names. They must
-start with a letter, end with a letter or digit, and have as interior
-characters only letters, digits, and hyphen. There are also some
-restrictions on the length. Labels must be 63 characters or less.
-
-For example, the following strings identify hosts in the Internet:
-
-A.ISI.EDU XX.LCS.MIT.EDU SRI-NIC.ARPA
-
-2.3.2. Data Transmission Order
-
-The order of transmission of the header and data described in this
-document is resolved to the octet level. Whenever a diagram shows a
-
-
-
-Mockapetris [Page 8]
-\f
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-group of octets, the order of transmission of those octets is the normal
-order in which they are read in English. For example, in the following
-diagram, the octets are transmitted in the order they are numbered.
-
- 0 1
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | 1 | 2 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | 3 | 4 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | 5 | 6 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-Whenever an octet represents a numeric quantity, the left most bit in
-the diagram is the high order or most significant bit. That is, the bit
-labeled 0 is the most significant bit. For example, the following
-diagram represents the value 170 (decimal).
-
- 0 1 2 3 4 5 6 7
- +-+-+-+-+-+-+-+-+
- |1 0 1 0 1 0 1 0|
- +-+-+-+-+-+-+-+-+
-
-Similarly, whenever a multi-octet field represents a numeric quantity
-the left most bit of the whole field is the most significant bit. When
-a multi-octet quantity is transmitted the most significant octet is
-transmitted first.
-
-2.3.3. Character Case
-
-For all parts of the DNS that are part of the official protocol, all
-comparisons between character strings (e.g., labels, domain names, etc.)
-are done in a case-insensitive manner. At present, this rule is in
-force throughout the domain system without exception. However, future
-additions beyond current usage may need to use the full binary octet
-capabilities in names, so attempts to store domain names in 7-bit ASCII
-or use of special bytes to terminate labels, etc., should be avoided.
-
-When data enters the domain system, its original case should be
-preserved whenever possible. In certain circumstances this cannot be
-done. For example, if two RRs are stored in a database, one at x.y and
-one at X.Y, they are actually stored at the same place in the database,
-and hence only one casing would be preserved. The basic rule is that
-case can be discarded only when data is used to define structure in a
-database, and two names are identical when compared in a case
-insensitive manner.
-
-
-
-
-Mockapetris [Page 9]
-\f
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-Loss of case sensitive data must be minimized. Thus while data for x.y
-and X.Y may both be stored under a single location x.y or X.Y, data for
-a.x and B.X would never be stored under A.x, A.X, b.x, or b.X. In
-general, this preserves the case of the first label of a domain name,
-but forces standardization of interior node labels.
-
-Systems administrators who enter data into the domain database should
-take care to represent the data they supply to the domain system in a
-case-consistent manner if their system is case-sensitive. The data
-distribution system in the domain system will ensure that consistent
-representations are preserved.
-
-2.3.4. Size limits
-
-Various objects and parameters in the DNS have size limits. They are
-listed below. Some could be easily changed, others are more
-fundamental.
-
-labels 63 octets or less
-
-names 255 octets or less
-
-TTL positive values of a signed 32 bit number.
-
-UDP messages 512 octets or less
-
-3. DOMAIN NAME SPACE AND RR DEFINITIONS
-
-3.1. Name space definitions
-
-Domain names in messages are expressed in terms of a sequence of labels.
-Each label is represented as a one octet length field followed by that
-number of octets. Since every domain name ends with the null label of
-the root, a domain name is terminated by a length byte of zero. The
-high order two bits of every length octet must be zero, and the
-remaining six bits of the length field limit the label to 63 octets or
-less.
-
-To simplify implementations, the total length of a domain name (i.e.,
-label octets and label length octets) is restricted to 255 octets or
-less.
-
-Although labels can contain any 8 bit values in octets that make up a
-label, it is strongly recommended that labels follow the preferred
-syntax described elsewhere in this memo, which is compatible with
-existing host naming conventions. Name servers and resolvers must
-compare labels in a case-insensitive manner (i.e., A=a), assuming ASCII
-with zero parity. Non-alphabetic codes must match exactly.
-
-
-
-Mockapetris [Page 10]
-\f
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-3.2. RR definitions
-
-3.2.1. Format
-
-All RRs have the same top level format shown below:
-
- 1 1 1 1 1 1
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | |
- / /
- / NAME /
- | |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | TYPE |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | CLASS |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | TTL |
- | |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | RDLENGTH |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
- / RDATA /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-
-where:
-
-NAME an owner name, i.e., the name of the node to which this
- resource record pertains.
-
-TYPE two octets containing one of the RR TYPE codes.
-
-CLASS two octets containing one of the RR CLASS codes.
-
-TTL a 32 bit signed integer that specifies the time interval
- that the resource record may be cached before the source
- of the information should again be consulted. Zero
- values are interpreted to mean that the RR can only be
- used for the transaction in progress, and should not be
- cached. For example, SOA records are always distributed
- with a zero TTL to prohibit caching. Zero values can
- also be used for extremely volatile data.
-
-RDLENGTH an unsigned 16 bit integer that specifies the length in
- octets of the RDATA field.
-
-
-
-Mockapetris [Page 11]
-\f
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-RDATA a variable length string of octets that describes the
- resource. The format of this information varies
- according to the TYPE and CLASS of the resource record.
-
-3.2.2. TYPE values
-
-TYPE fields are used in resource records. Note that these types are a
-subset of QTYPEs.
-
-TYPE value and meaning
-
-A 1 a host address
-
-NS 2 an authoritative name server
-
-MD 3 a mail destination (Obsolete - use MX)
-
-MF 4 a mail forwarder (Obsolete - use MX)
-
-CNAME 5 the canonical name for an alias
-
-SOA 6 marks the start of a zone of authority
-
-MB 7 a mailbox domain name (EXPERIMENTAL)
-
-MG 8 a mail group member (EXPERIMENTAL)
-
-MR 9 a mail rename domain name (EXPERIMENTAL)
-
-NULL 10 a null RR (EXPERIMENTAL)
-
-WKS 11 a well known service description
-
-PTR 12 a domain name pointer
-
-HINFO 13 host information
-
-MINFO 14 mailbox or mail list information
-
-MX 15 mail exchange
-
-TXT 16 text strings
-
-3.2.3. QTYPE values
-
-QTYPE fields appear in the question part of a query. QTYPES are a
-superset of TYPEs, hence all TYPEs are valid QTYPEs. In addition, the
-following QTYPEs are defined:
-
-
-
-Mockapetris [Page 12]
-\f
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-AXFR 252 A request for a transfer of an entire zone
-
-MAILB 253 A request for mailbox-related records (MB, MG or MR)
-
-MAILA 254 A request for mail agent RRs (Obsolete - see MX)
-
-* 255 A request for all records
-
-3.2.4. CLASS values
-
-CLASS fields appear in resource records. The following CLASS mnemonics
-and values are defined:
-
-IN 1 the Internet
-
-CS 2 the CSNET class (Obsolete - used only for examples in
- some obsolete RFCs)
-
-CH 3 the CHAOS class
-
-HS 4 Hesiod [Dyer 87]
-
-3.2.5. QCLASS values
-
-QCLASS fields appear in the question section of a query. QCLASS values
-are a superset of CLASS values; every CLASS is a valid QCLASS. In
-addition to CLASS values, the following QCLASSes are defined:
-
-* 255 any class
-
-3.3. Standard RRs
-
-The following RR definitions are expected to occur, at least
-potentially, in all classes. In particular, NS, SOA, CNAME, and PTR
-will be used in all classes, and have the same format in all classes.
-Because their RDATA format is known, all domain names in the RDATA
-section of these RRs may be compressed.
-
-<domain-name> is a domain name represented as a series of labels, and
-terminated by a label with zero length. <character-string> is a single
-length octet followed by that number of characters. <character-string>
-is treated as binary information, and can be up to 256 characters in
-length (including the length octet).
-
-
-
-
-
-
-
-
-Mockapetris [Page 13]
-\f
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-3.3.1. CNAME RDATA format
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / CNAME /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-CNAME A <domain-name> which specifies the canonical or primary
- name for the owner. The owner name is an alias.
-
-CNAME RRs cause no additional section processing, but name servers may
-choose to restart the query at the canonical name in certain cases. See
-the description of name server logic in [RFC-1034] for details.
-
-3.3.2. HINFO RDATA format
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / CPU /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / OS /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-CPU A <character-string> which specifies the CPU type.
-
-OS A <character-string> which specifies the operating
- system type.
-
-Standard values for CPU and OS can be found in [RFC-1010].
-
-HINFO records are used to acquire general information about a host. The
-main use is for protocols such as FTP that can use special procedures
-when talking between machines or operating systems of the same type.
-
-3.3.3. MB RDATA format (EXPERIMENTAL)
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / MADNAME /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-MADNAME A <domain-name> which specifies a host which has the
- specified mailbox.
-
-
-
-Mockapetris [Page 14]
-\f
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-MB records cause additional section processing which looks up an A type
-RRs corresponding to MADNAME.
-
-3.3.4. MD RDATA format (Obsolete)
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / MADNAME /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-MADNAME A <domain-name> which specifies a host which has a mail
- agent for the domain which should be able to deliver
- mail for the domain.
-
-MD records cause additional section processing which looks up an A type
-record corresponding to MADNAME.
-
-MD is obsolete. See the definition of MX and [RFC-974] for details of
-the new scheme. The recommended policy for dealing with MD RRs found in
-a master file is to reject them, or to convert them to MX RRs with a
-preference of 0.
-
-3.3.5. MF RDATA format (Obsolete)
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / MADNAME /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-MADNAME A <domain-name> which specifies a host which has a mail
- agent for the domain which will accept mail for
- forwarding to the domain.
-
-MF records cause additional section processing which looks up an A type
-record corresponding to MADNAME.
-
-MF is obsolete. See the definition of MX and [RFC-974] for details ofw
-the new scheme. The recommended policy for dealing with MD RRs found in
-a master file is to reject them, or to convert them to MX RRs with a
-preference of 10.
-
-
-
-
-
-
-
-Mockapetris [Page 15]
-\f
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-3.3.6. MG RDATA format (EXPERIMENTAL)
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / MGMNAME /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-MGMNAME A <domain-name> which specifies a mailbox which is a
- member of the mail group specified by the domain name.
-
-MG records cause no additional section processing.
-
-3.3.7. MINFO RDATA format (EXPERIMENTAL)
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / RMAILBX /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / EMAILBX /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-RMAILBX A <domain-name> which specifies a mailbox which is
- responsible for the mailing list or mailbox. If this
- domain name names the root, the owner of the MINFO RR is
- responsible for itself. Note that many existing mailing
- lists use a mailbox X-request for the RMAILBX field of
- mailing list X, e.g., Msgroup-request for Msgroup. This
- field provides a more general mechanism.
-
-
-EMAILBX A <domain-name> which specifies a mailbox which is to
- receive error messages related to the mailing list or
- mailbox specified by the owner of the MINFO RR (similar
- to the ERRORS-TO: field which has been proposed). If
- this domain name names the root, errors should be
- returned to the sender of the message.
-
-MINFO records cause no additional section processing. Although these
-records can be associated with a simple mailbox, they are usually used
-with a mailing list.
-
-
-
-
-
-
-
-
-Mockapetris [Page 16]
-\f
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-3.3.8. MR RDATA format (EXPERIMENTAL)
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / NEWNAME /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-NEWNAME A <domain-name> which specifies a mailbox which is the
- proper rename of the specified mailbox.
-
-MR records cause no additional section processing. The main use for MR
-is as a forwarding entry for a user who has moved to a different
-mailbox.
-
-3.3.9. MX RDATA format
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | PREFERENCE |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / EXCHANGE /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-PREFERENCE A 16 bit integer which specifies the preference given to
- this RR among others at the same owner. Lower values
- are preferred.
-
-EXCHANGE A <domain-name> which specifies a host willing to act as
- a mail exchange for the owner name.
-
-MX records cause type A additional section processing for the host
-specified by EXCHANGE. The use of MX RRs is explained in detail in
-[RFC-974].
-
-3.3.10. NULL RDATA format (EXPERIMENTAL)
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / <anything> /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-Anything at all may be in the RDATA field so long as it is 65535 octets
-or less.
-
-
-
-
-Mockapetris [Page 17]
-\f
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-NULL records cause no additional section processing. NULL RRs are not
-allowed in master files. NULLs are used as placeholders in some
-experimental extensions of the DNS.
-
-3.3.11. NS RDATA format
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / NSDNAME /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-NSDNAME A <domain-name> which specifies a host which should be
- authoritative for the specified class and domain.
-
-NS records cause both the usual additional section processing to locate
-a type A record, and, when used in a referral, a special search of the
-zone in which they reside for glue information.
-
-The NS RR states that the named host should be expected to have a zone
-starting at owner name of the specified class. Note that the class may
-not indicate the protocol family which should be used to communicate
-with the host, although it is typically a strong hint. For example,
-hosts which are name servers for either Internet (IN) or Hesiod (HS)
-class information are normally queried using IN class protocols.
-
-3.3.12. PTR RDATA format
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / PTRDNAME /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-PTRDNAME A <domain-name> which points to some location in the
- domain name space.
-
-PTR records cause no additional section processing. These RRs are used
-in special domains to point to some other location in the domain space.
-These records are simple data, and don't imply any special processing
-similar to that performed by CNAME, which identifies aliases. See the
-description of the IN-ADDR.ARPA domain for an example.
-
-
-
-
-
-
-
-
-Mockapetris [Page 18]
-\f
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-3.3.13. SOA RDATA format
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / MNAME /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / RNAME /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | SERIAL |
- | |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | REFRESH |
- | |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | RETRY |
- | |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | EXPIRE |
- | |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | MINIMUM |
- | |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-MNAME The <domain-name> of the name server that was the
- original or primary source of data for this zone.
-
-RNAME A <domain-name> which specifies the mailbox of the
- person responsible for this zone.
-
-SERIAL The unsigned 32 bit version number of the original copy
- of the zone. Zone transfers preserve this value. This
- value wraps and should be compared using sequence space
- arithmetic.
-
-REFRESH A 32 bit time interval before the zone should be
- refreshed.
-
-RETRY A 32 bit time interval that should elapse before a
- failed refresh should be retried.
-
-EXPIRE A 32 bit time value that specifies the upper limit on
- the time interval that can elapse before the zone is no
- longer authoritative.
-
-
-
-
-
-Mockapetris [Page 19]
-\f
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-MINIMUM The unsigned 32 bit minimum TTL field that should be
- exported with any RR from this zone.
-
-SOA records cause no additional section processing.
-
-All times are in units of seconds.
-
-Most of these fields are pertinent only for name server maintenance
-operations. However, MINIMUM is used in all query operations that
-retrieve RRs from a zone. Whenever a RR is sent in a response to a
-query, the TTL field is set to the maximum of the TTL field from the RR
-and the MINIMUM field in the appropriate SOA. Thus MINIMUM is a lower
-bound on the TTL field for all RRs in a zone. Note that this use of
-MINIMUM should occur when the RRs are copied into the response and not
-when the zone is loaded from a master file or via a zone transfer. The
-reason for this provison is to allow future dynamic update facilities to
-change the SOA RR with known semantics.
-
-
-3.3.14. TXT RDATA format
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- / TXT-DATA /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-TXT-DATA One or more <character-string>s.
-
-TXT RRs are used to hold descriptive text. The semantics of the text
-depends on the domain where it is found.
-
-3.4. Internet specific RRs
-
-3.4.1. A RDATA format
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ADDRESS |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-ADDRESS A 32 bit Internet address.
-
-Hosts that have multiple Internet addresses will have multiple A
-records.
-
-
-
-
-
-Mockapetris [Page 20]
-\f
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-A records cause no additional section processing. The RDATA section of
-an A line in a master file is an Internet address expressed as four
-decimal numbers separated by dots without any imbedded spaces (e.g.,
-"10.2.0.52" or "192.0.5.6").
-
-3.4.2. WKS RDATA format
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ADDRESS |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | PROTOCOL | |
- +--+--+--+--+--+--+--+--+ |
- | |
- / <BIT MAP> /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-ADDRESS An 32 bit Internet address
-
-PROTOCOL An 8 bit IP protocol number
-
-<BIT MAP> A variable length bit map. The bit map must be a
- multiple of 8 bits long.
-
-The WKS record is used to describe the well known services supported by
-a particular protocol on a particular internet address. The PROTOCOL
-field specifies an IP protocol number, and the bit map has one bit per
-port of the specified protocol. The first bit corresponds to port 0,
-the second to port 1, etc. If the bit map does not include a bit for a
-protocol of interest, that bit is assumed zero. The appropriate values
-and mnemonics for ports and protocols are specified in [RFC-1010].
-
-For example, if PROTOCOL=TCP (6), the 26th bit corresponds to TCP port
-25 (SMTP). If this bit is set, a SMTP server should be listening on TCP
-port 25; if zero, SMTP service is not supported on the specified
-address.
-
-The purpose of WKS RRs is to provide availability information for
-servers for TCP and UDP. If a server supports both TCP and UDP, or has
-multiple Internet addresses, then multiple WKS RRs are used.
-
-WKS RRs cause no additional section processing.
-
-In master files, both ports and protocols are expressed using mnemonics
-or decimal numbers.
-
-
-
-
-Mockapetris [Page 21]
-\f
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-3.5. IN-ADDR.ARPA domain
-
-The Internet uses a special domain to support gateway location and
-Internet address to host mapping. Other classes may employ a similar
-strategy in other domains. The intent of this domain is to provide a
-guaranteed method to perform host address to host name mapping, and to
-facilitate queries to locate all gateways on a particular network in the
-Internet.
-
-Note that both of these services are similar to functions that could be
-performed by inverse queries; the difference is that this part of the
-domain name space is structured according to address, and hence can
-guarantee that the appropriate data can be located without an exhaustive
-search of the domain space.
-
-The domain begins at IN-ADDR.ARPA and has a substructure which follows
-the Internet addressing structure.
-
-Domain names in the IN-ADDR.ARPA domain are defined to have up to four
-labels in addition to the IN-ADDR.ARPA suffix. Each label represents
-one octet of an Internet address, and is expressed as a character string
-for a decimal value in the range 0-255 (with leading zeros omitted
-except in the case of a zero octet which is represented by a single
-zero).
-
-Host addresses are represented by domain names that have all four labels
-specified. Thus data for Internet address 10.2.0.52 is located at
-domain name 52.0.2.10.IN-ADDR.ARPA. The reversal, though awkward to
-read, allows zones to be delegated which are exactly one network of
-address space. For example, 10.IN-ADDR.ARPA can be a zone containing
-data for the ARPANET, while 26.IN-ADDR.ARPA can be a separate zone for
-MILNET. Address nodes are used to hold pointers to primary host names
-in the normal domain space.
-
-Network numbers correspond to some non-terminal nodes at various depths
-in the IN-ADDR.ARPA domain, since Internet network numbers are either 1,
-2, or 3 octets. Network nodes are used to hold pointers to the primary
-host names of gateways attached to that network. Since a gateway is, by
-definition, on more than one network, it will typically have two or more
-network nodes which point at it. Gateways will also have host level
-pointers at their fully qualified addresses.
-
-Both the gateway pointers at network nodes and the normal host pointers
-at full address nodes use the PTR RR to point back to the primary domain
-names of the corresponding hosts.
-
-For example, the IN-ADDR.ARPA domain will contain information about the
-ISI gateway between net 10 and 26, an MIT gateway from net 10 to MIT's
-
-
-
-Mockapetris [Page 22]
-\f
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-net 18, and hosts A.ISI.EDU and MULTICS.MIT.EDU. Assuming that ISI
-gateway has addresses 10.2.0.22 and 26.0.0.103, and a name MILNET-
-GW.ISI.EDU, and the MIT gateway has addresses 10.0.0.77 and 18.10.0.4
-and a name GW.LCS.MIT.EDU, the domain database would contain:
-
- 10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
- 10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
- 18.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
- 26.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
- 22.0.2.10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
- 103.0.0.26.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
- 77.0.0.10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
- 4.0.10.18.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
- 103.0.3.26.IN-ADDR.ARPA. PTR A.ISI.EDU.
- 6.0.0.10.IN-ADDR.ARPA. PTR MULTICS.MIT.EDU.
-
-Thus a program which wanted to locate gateways on net 10 would originate
-a query of the form QTYPE=PTR, QCLASS=IN, QNAME=10.IN-ADDR.ARPA. It
-would receive two RRs in response:
-
- 10.IN-ADDR.ARPA. PTR MILNET-GW.ISI.EDU.
- 10.IN-ADDR.ARPA. PTR GW.LCS.MIT.EDU.
-
-The program could then originate QTYPE=A, QCLASS=IN queries for MILNET-
-GW.ISI.EDU. and GW.LCS.MIT.EDU. to discover the Internet addresses of
-these gateways.
-
-A resolver which wanted to find the host name corresponding to Internet
-host address 10.0.0.6 would pursue a query of the form QTYPE=PTR,
-QCLASS=IN, QNAME=6.0.0.10.IN-ADDR.ARPA, and would receive:
-
- 6.0.0.10.IN-ADDR.ARPA. PTR MULTICS.MIT.EDU.
-
-Several cautions apply to the use of these services:
- - Since the IN-ADDR.ARPA special domain and the normal domain
- for a particular host or gateway will be in different zones,
- the possibility exists that that the data may be inconsistent.
-
- - Gateways will often have two names in separate domains, only
- one of which can be primary.
-
- - Systems that use the domain database to initialize their
- routing tables must start with enough gateway information to
- guarantee that they can access the appropriate name server.
-
- - The gateway data only reflects the existence of a gateway in a
- manner equivalent to the current HOSTS.TXT file. It doesn't
- replace the dynamic availability information from GGP or EGP.
-
-
-
-Mockapetris [Page 23]
-\f
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-3.6. Defining new types, classes, and special namespaces
-
-The previously defined types and classes are the ones in use as of the
-date of this memo. New definitions should be expected. This section
-makes some recommendations to designers considering additions to the
-existing facilities. The mailing list NAMEDROPPERS@SRI-NIC.ARPA is the
-forum where general discussion of design issues takes place.
-
-In general, a new type is appropriate when new information is to be
-added to the database about an existing object, or we need new data
-formats for some totally new object. Designers should attempt to define
-types and their RDATA formats that are generally applicable to all
-classes, and which avoid duplication of information. New classes are
-appropriate when the DNS is to be used for a new protocol, etc which
-requires new class-specific data formats, or when a copy of the existing
-name space is desired, but a separate management domain is necessary.
-
-New types and classes need mnemonics for master files; the format of the
-master files requires that the mnemonics for type and class be disjoint.
-
-TYPE and CLASS values must be a proper subset of QTYPEs and QCLASSes
-respectively.
-
-The present system uses multiple RRs to represent multiple values of a
-type rather than storing multiple values in the RDATA section of a
-single RR. This is less efficient for most applications, but does keep
-RRs shorter. The multiple RRs assumption is incorporated in some
-experimental work on dynamic update methods.
-
-The present system attempts to minimize the duplication of data in the
-database in order to insure consistency. Thus, in order to find the
-address of the host for a mail exchange, you map the mail domain name to
-a host name, then the host name to addresses, rather than a direct
-mapping to host address. This approach is preferred because it avoids
-the opportunity for inconsistency.
-
-In defining a new type of data, multiple RR types should not be used to
-create an ordering between entries or express different formats for
-equivalent bindings, instead this information should be carried in the
-body of the RR and a single type used. This policy avoids problems with
-caching multiple types and defining QTYPEs to match multiple types.
-
-For example, the original form of mail exchange binding used two RR
-types one to represent a "closer" exchange (MD) and one to represent a
-"less close" exchange (MF). The difficulty is that the presence of one
-RR type in a cache doesn't convey any information about the other
-because the query which acquired the cached information might have used
-a QTYPE of MF, MD, or MAILA (which matched both). The redesigned
-
-
-
-Mockapetris [Page 24]
-\f
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-service used a single type (MX) with a "preference" value in the RDATA
-section which can order different RRs. However, if any MX RRs are found
-in the cache, then all should be there.
-
-4. MESSAGES
-
-4.1. Format
-
-All communications inside of the domain protocol are carried in a single
-format called a message. The top level format of message is divided
-into 5 sections (some of which are empty in certain cases) shown below:
-
- +---------------------+
- | Header |
- +---------------------+
- | Question | the question for the name server
- +---------------------+
- | Answer | RRs answering the question
- +---------------------+
- | Authority | RRs pointing toward an authority
- +---------------------+
- | Additional | RRs holding additional information
- +---------------------+
-
-The header section is always present. The header includes fields that
-specify which of the remaining sections are present, and also specify
-whether the message is a query or a response, a standard query or some
-other opcode, etc.
-
-The names of the sections after the header are derived from their use in
-standard queries. The question section contains fields that describe a
-question to a name server. These fields are a query type (QTYPE), a
-query class (QCLASS), and a query domain name (QNAME). The last three
-sections have the same format: a possibly empty list of concatenated
-resource records (RRs). The answer section contains RRs that answer the
-question; the authority section contains RRs that point toward an
-authoritative name server; the additional records section contains RRs
-which relate to the query, but are not strictly answers for the
-question.
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris [Page 25]
-\f
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-4.1.1. Header section format
-
-The header contains the following fields:
-
- 1 1 1 1 1 1
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ID |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- |QR| Opcode |AA|TC|RD|RA| Z | RCODE |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | QDCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ANCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | NSCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | ARCOUNT |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-ID A 16 bit identifier assigned by the program that
- generates any kind of query. This identifier is copied
- the corresponding reply and can be used by the requester
- to match up replies to outstanding queries.
-
-QR A one bit field that specifies whether this message is a
- query (0), or a response (1).
-
-OPCODE A four bit field that specifies kind of query in this
- message. This value is set by the originator of a query
- and copied into the response. The values are:
-
- 0 a standard query (QUERY)
-
- 1 an inverse query (IQUERY)
-
- 2 a server status request (STATUS)
-
- 3-15 reserved for future use
-
-AA Authoritative Answer - this bit is valid in responses,
- and specifies that the responding name server is an
- authority for the domain name in question section.
-
- Note that the contents of the answer section may have
- multiple owner names because of aliases. The AA bit
-
-
-
-Mockapetris [Page 26]
-\f
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- corresponds to the name which matches the query name, or
- the first owner name in the answer section.
-
-TC TrunCation - specifies that this message was truncated
- due to length greater than that permitted on the
- transmission channel.
-
-RD Recursion Desired - this bit may be set in a query and
- is copied into the response. If RD is set, it directs
- the name server to pursue the query recursively.
- Recursive query support is optional.
-
-RA Recursion Available - this be is set or cleared in a
- response, and denotes whether recursive query support is
- available in the name server.
-
-Z Reserved for future use. Must be zero in all queries
- and responses.
-
-RCODE Response code - this 4 bit field is set as part of
- responses. The values have the following
- interpretation:
-
- 0 No error condition
-
- 1 Format error - The name server was
- unable to interpret the query.
-
- 2 Server failure - The name server was
- unable to process this query due to a
- problem with the name server.
-
- 3 Name Error - Meaningful only for
- responses from an authoritative name
- server, this code signifies that the
- domain name referenced in the query does
- not exist.
-
- 4 Not Implemented - The name server does
- not support the requested kind of query.
-
- 5 Refused - The name server refuses to
- perform the specified operation for
- policy reasons. For example, a name
- server may not wish to provide the
- information to the particular requester,
- or a name server may not wish to perform
- a particular operation (e.g., zone
-
-
-
-Mockapetris [Page 27]
-\f
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- transfer) for particular data.
-
- 6-15 Reserved for future use.
-
-QDCOUNT an unsigned 16 bit integer specifying the number of
- entries in the question section.
-
-ANCOUNT an unsigned 16 bit integer specifying the number of
- resource records in the answer section.
-
-NSCOUNT an unsigned 16 bit integer specifying the number of name
- server resource records in the authority records
- section.
-
-ARCOUNT an unsigned 16 bit integer specifying the number of
- resource records in the additional records section.
-
-4.1.2. Question section format
-
-The question section is used to carry the "question" in most queries,
-i.e., the parameters that define what is being asked. The section
-contains QDCOUNT (usually 1) entries, each of the following format:
-
- 1 1 1 1 1 1
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | |
- / QNAME /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | QTYPE |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | QCLASS |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-QNAME a domain name represented as a sequence of labels, where
- each label consists of a length octet followed by that
- number of octets. The domain name terminates with the
- zero length octet for the null label of the root. Note
- that this field may be an odd number of octets; no
- padding is used.
-
-QTYPE a two octet code which specifies the type of the query.
- The values for this field include all codes valid for a
- TYPE field, together with some more general codes which
- can match more than one type of RR.
-
-
-
-Mockapetris [Page 28]
-\f
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-QCLASS a two octet code that specifies the class of the query.
- For example, the QCLASS field is IN for the Internet.
-
-4.1.3. Resource record format
-
-The answer, authority, and additional sections all share the same
-format: a variable number of resource records, where the number of
-records is specified in the corresponding count field in the header.
-Each resource record has the following format:
- 1 1 1 1 1 1
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | |
- / /
- / NAME /
- | |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | TYPE |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | CLASS |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | TTL |
- | |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | RDLENGTH |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
- / RDATA /
- / /
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-where:
-
-NAME a domain name to which this resource record pertains.
-
-TYPE two octets containing one of the RR type codes. This
- field specifies the meaning of the data in the RDATA
- field.
-
-CLASS two octets which specify the class of the data in the
- RDATA field.
-
-TTL a 32 bit unsigned integer that specifies the time
- interval (in seconds) that the resource record may be
- cached before it should be discarded. Zero values are
- interpreted to mean that the RR can only be used for the
- transaction in progress, and should not be cached.
-
-
-
-
-
-Mockapetris [Page 29]
-\f
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-RDLENGTH an unsigned 16 bit integer that specifies the length in
- octets of the RDATA field.
-
-RDATA a variable length string of octets that describes the
- resource. The format of this information varies
- according to the TYPE and CLASS of the resource record.
- For example, the if the TYPE is A and the CLASS is IN,
- the RDATA field is a 4 octet ARPA Internet address.
-
-4.1.4. Message compression
-
-In order to reduce the size of messages, the domain system utilizes a
-compression scheme which eliminates the repetition of domain names in a
-message. In this scheme, an entire domain name or a list of labels at
-the end of a domain name is replaced with a pointer to a prior occurance
-of the same name.
-
-The pointer takes the form of a two octet sequence:
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- | 1 1| OFFSET |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-The first two bits are ones. This allows a pointer to be distinguished
-from a label, since the label must begin with two zero bits because
-labels are restricted to 63 octets or less. (The 10 and 01 combinations
-are reserved for future use.) The OFFSET field specifies an offset from
-the start of the message (i.e., the first octet of the ID field in the
-domain header). A zero offset specifies the first byte of the ID field,
-etc.
-
-The compression scheme allows a domain name in a message to be
-represented as either:
-
- - a sequence of labels ending in a zero octet
-
- - a pointer
-
- - a sequence of labels ending with a pointer
-
-Pointers can only be used for occurances of a domain name where the
-format is not class specific. If this were not the case, a name server
-or resolver would be required to know the format of all RRs it handled.
-As yet, there are no such cases, but they may occur in future RDATA
-formats.
-
-If a domain name is contained in a part of the message subject to a
-length field (such as the RDATA section of an RR), and compression is
-
-
-
-Mockapetris [Page 30]
-\f
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-used, the length of the compressed name is used in the length
-calculation, rather than the length of the expanded name.
-
-Programs are free to avoid using pointers in messages they generate,
-although this will reduce datagram capacity, and may cause truncation.
-However all programs are required to understand arriving messages that
-contain pointers.
-
-For example, a datagram might need to use the domain names F.ISI.ARPA,
-FOO.F.ISI.ARPA, ARPA, and the root. Ignoring the other fields of the
-message, these domain names might be represented as:
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 20 | 1 | F |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 22 | 3 | I |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 24 | S | I |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 26 | 4 | A |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 28 | R | P |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 30 | A | 0 |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 40 | 3 | F |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 42 | O | O |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 44 | 1 1| 20 |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 64 | 1 1| 26 |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
- 92 | 0 | |
- +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
-
-The domain name for F.ISI.ARPA is shown at offset 20. The domain name
-FOO.F.ISI.ARPA is shown at offset 40; this definition uses a pointer to
-concatenate a label for FOO to the previously defined F.ISI.ARPA. The
-domain name ARPA is defined at offset 64 using a pointer to the ARPA
-component of the name F.ISI.ARPA at 20; note that this pointer relies on
-ARPA being the last label in the string at 20. The root domain name is
-
-
-
-Mockapetris [Page 31]
-\f
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-defined by a single octet of zeros at 92; the root domain name has no
-labels.
-
-4.2. Transport
-
-The DNS assumes that messages will be transmitted as datagrams or in a
-byte stream carried by a virtual circuit. While virtual circuits can be
-used for any DNS activity, datagrams are preferred for queries due to
-their lower overhead and better performance. Zone refresh activities
-must use virtual circuits because of the need for reliable transfer.
-
-The Internet supports name server access using TCP [RFC-793] on server
-port 53 (decimal) as well as datagram access using UDP [RFC-768] on UDP
-port 53 (decimal).
-
-4.2.1. UDP usage
-
-Messages sent using UDP user server port 53 (decimal).
-
-Messages carried by UDP are restricted to 512 bytes (not counting the IP
-or UDP headers). Longer messages are truncated and the TC bit is set in
-the header.
-
-UDP is not acceptable for zone transfers, but is the recommended method
-for standard queries in the Internet. Queries sent using UDP may be
-lost, and hence a retransmission strategy is required. Queries or their
-responses may be reordered by the network, or by processing in name
-servers, so resolvers should not depend on them being returned in order.
-
-The optimal UDP retransmission policy will vary with performance of the
-Internet and the needs of the client, but the following are recommended:
-
- - The client should try other servers and server addresses
- before repeating a query to a specific address of a server.
-
- - The retransmission interval should be based on prior
- statistics if possible. Too aggressive retransmission can
- easily slow responses for the community at large. Depending
- on how well connected the client is to its expected servers,
- the minimum retransmission interval should be 2-5 seconds.
-
-More suggestions on server selection and retransmission policy can be
-found in the resolver section of this memo.
-
-4.2.2. TCP usage
-
-Messages sent over TCP connections use server port 53 (decimal). The
-message is prefixed with a two byte length field which gives the message
-
-
-
-Mockapetris [Page 32]
-\f
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-length, excluding the two byte length field. This length field allows
-the low-level processing to assemble a complete message before beginning
-to parse it.
-
-Several connection management policies are recommended:
-
- - The server should not block other activities waiting for TCP
- data.
-
- - The server should support multiple connections.
-
- - The server should assume that the client will initiate
- connection closing, and should delay closing its end of the
- connection until all outstanding client requests have been
- satisfied.
-
- - If the server needs to close a dormant connection to reclaim
- resources, it should wait until the connection has been idle
- for a period on the order of two minutes. In particular, the
- server should allow the SOA and AXFR request sequence (which
- begins a refresh operation) to be made on a single connection.
- Since the server would be unable to answer queries anyway, a
- unilateral close or reset may be used instead of a graceful
- close.
-
-5. MASTER FILES
-
-Master files are text files that contain RRs in text form. Since the
-contents of a zone can be expressed in the form of a list of RRs a
-master file is most often used to define a zone, though it can be used
-to list a cache's contents. Hence, this section first discusses the
-format of RRs in a master file, and then the special considerations when
-a master file is used to create a zone in some name server.
-
-5.1. Format
-
-The format of these files is a sequence of entries. Entries are
-predominantly line-oriented, though parentheses can be used to continue
-a list of items across a line boundary, and text literals can contain
-CRLF within the text. Any combination of tabs and spaces act as a
-delimiter between the separate items that make up an entry. The end of
-any line in the master file can end with a comment. The comment starts
-with a ";" (semicolon).
-
-The following entries are defined:
-
- <blank>[<comment>]
-
-
-
-
-Mockapetris [Page 33]
-\f
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- $ORIGIN <domain-name> [<comment>]
-
- $INCLUDE <file-name> [<domain-name>] [<comment>]
-
- <domain-name><rr> [<comment>]
-
- <blank><rr> [<comment>]
-
-Blank lines, with or without comments, are allowed anywhere in the file.
-
-Two control entries are defined: $ORIGIN and $INCLUDE. $ORIGIN is
-followed by a domain name, and resets the current origin for relative
-domain names to the stated name. $INCLUDE inserts the named file into
-the current file, and may optionally specify a domain name that sets the
-relative domain name origin for the included file. $INCLUDE may also
-have a comment. Note that a $INCLUDE entry never changes the relative
-origin of the parent file, regardless of changes to the relative origin
-made within the included file.
-
-The last two forms represent RRs. If an entry for an RR begins with a
-blank, then the RR is assumed to be owned by the last stated owner. If
-an RR entry begins with a <domain-name>, then the owner name is reset.
-
-<rr> contents take one of the following forms:
-
- [<TTL>] [<class>] <type> <RDATA>
-
- [<class>] [<TTL>] <type> <RDATA>
-
-The RR begins with optional TTL and class fields, followed by a type and
-RDATA field appropriate to the type and class. Class and type use the
-standard mnemonics, TTL is a decimal integer. Omitted class and TTL
-values are default to the last explicitly stated values. Since type and
-class mnemonics are disjoint, the parse is unique. (Note that this
-order is different from the order used in examples and the order used in
-the actual RRs; the given order allows easier parsing and defaulting.)
-
-<domain-name>s make up a large share of the data in the master file.
-The labels in the domain name are expressed as character strings and
-separated by dots. Quoting conventions allow arbitrary characters to be
-stored in domain names. Domain names that end in a dot are called
-absolute, and are taken as complete. Domain names which do not end in a
-dot are called relative; the actual domain name is the concatenation of
-the relative part with an origin specified in a $ORIGIN, $INCLUDE, or as
-an argument to the master file loading routine. A relative name is an
-error when no origin is available.
-
-
-
-
-
-Mockapetris [Page 34]
-\f
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-<character-string> is expressed in one or two ways: as a contiguous set
-of characters without interior spaces, or as a string beginning with a "
-and ending with a ". Inside a " delimited string any character can
-occur, except for a " itself, which must be quoted using \ (back slash).
-
-Because these files are text files several special encodings are
-necessary to allow arbitrary data to be loaded. In particular:
-
- of the root.
-
-@ A free standing @ is used to denote the current origin.
-
-\X where X is any character other than a digit (0-9), is
- used to quote that character so that its special meaning
- does not apply. For example, "\." can be used to place
- a dot character in a label.
-
-\DDD where each D is a digit is the octet corresponding to
- the decimal number described by DDD. The resulting
- octet is assumed to be text and is not checked for
- special meaning.
-
-( ) Parentheses are used to group data that crosses a line
- boundary. In effect, line terminations are not
- recognized within parentheses.
-
-; Semicolon is used to start a comment; the remainder of
- the line is ignored.
-
-5.2. Use of master files to define zones
-
-When a master file is used to load a zone, the operation should be
-suppressed if any errors are encountered in the master file. The
-rationale for this is that a single error can have widespread
-consequences. For example, suppose that the RRs defining a delegation
-have syntax errors; then the server will return authoritative name
-errors for all names in the subzone (except in the case where the
-subzone is also present on the server).
-
-Several other validity checks that should be performed in addition to
-insuring that the file is syntactically correct:
-
- 1. All RRs in the file should have the same class.
-
- 2. Exactly one SOA RR should be present at the top of the zone.
-
- 3. If delegations are present and glue information is required,
- it should be present.
-
-
-
-Mockapetris [Page 35]
-\f
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- 4. Information present outside of the authoritative nodes in the
- zone should be glue information, rather than the result of an
- origin or similar error.
-
-5.3. Master file example
-
-The following is an example file which might be used to define the
-ISI.EDU zone.and is loaded with an origin of ISI.EDU:
-
-@ IN SOA VENERA Action\.domains (
- 20 ; SERIAL
- 7200 ; REFRESH
- 600 ; RETRY
- 3600000; EXPIRE
- 60) ; MINIMUM
-
- NS A.ISI.EDU.
- NS VENERA
- NS VAXA
- MX 10 VENERA
- MX 20 VAXA
-
-A A 26.3.0.103
-
-VENERA A 10.1.0.52
- A 128.9.0.32
-
-VAXA A 10.2.0.27
- A 128.9.0.33
-
-
-$INCLUDE <SUBSYS>ISI-MAILBOXES.TXT
-
-Where the file <SUBSYS>ISI-MAILBOXES.TXT is:
-
- MOE MB A.ISI.EDU.
- LARRY MB A.ISI.EDU.
- CURLEY MB A.ISI.EDU.
- STOOGES MG MOE
- MG LARRY
- MG CURLEY
-
-Note the use of the \ character in the SOA RR to specify the responsible
-person mailbox "Action.domains@E.ISI.EDU".
-
-
-
-
-
-
-
-Mockapetris [Page 36]
-\f
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-6. NAME SERVER IMPLEMENTATION
-
-6.1. Architecture
-
-The optimal structure for the name server will depend on the host
-operating system and whether the name server is integrated with resolver
-operations, either by supporting recursive service, or by sharing its
-database with a resolver. This section discusses implementation
-considerations for a name server which shares a database with a
-resolver, but most of these concerns are present in any name server.
-
-6.1.1. Control
-
-A name server must employ multiple concurrent activities, whether they
-are implemented as separate tasks in the host's OS or multiplexing
-inside a single name server program. It is simply not acceptable for a
-name server to block the service of UDP requests while it waits for TCP
-data for refreshing or query activities. Similarly, a name server
-should not attempt to provide recursive service without processing such
-requests in parallel, though it may choose to serialize requests from a
-single client, or to regard identical requests from the same client as
-duplicates. A name server should not substantially delay requests while
-it reloads a zone from master files or while it incorporates a newly
-refreshed zone into its database.
-
-6.1.2. Database
-
-While name server implementations are free to use any internal data
-structures they choose, the suggested structure consists of three major
-parts:
-
- - A "catalog" data structure which lists the zones available to
- this server, and a "pointer" to the zone data structure. The
- main purpose of this structure is to find the nearest ancestor
- zone, if any, for arriving standard queries.
-
- - Separate data structures for each of the zones held by the
- name server.
-
- - A data structure for cached data. (or perhaps separate caches
- for different classes)
-
-All of these data structures can be implemented an identical tree
-structure format, with different data chained off the nodes in different
-parts: in the catalog the data is pointers to zones, while in the zone
-and cache data structures, the data will be RRs. In designing the tree
-framework the designer should recognize that query processing will need
-to traverse the tree using case-insensitive label comparisons; and that
-
-
-
-Mockapetris [Page 37]
-\f
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-in real data, a few nodes have a very high branching factor (100-1000 or
-more), but the vast majority have a very low branching factor (0-1).
-
-One way to solve the case problem is to store the labels for each node
-in two pieces: a standardized-case representation of the label where all
-ASCII characters are in a single case, together with a bit mask that
-denotes which characters are actually of a different case. The
-branching factor diversity can be handled using a simple linked list for
-a node until the branching factor exceeds some threshold, and
-transitioning to a hash structure after the threshold is exceeded. In
-any case, hash structures used to store tree sections must insure that
-hash functions and procedures preserve the casing conventions of the
-DNS.
-
-The use of separate structures for the different parts of the database
-is motivated by several factors:
-
- - The catalog structure can be an almost static structure that
- need change only when the system administrator changes the
- zones supported by the server. This structure can also be
- used to store parameters used to control refreshing
- activities.
-
- - The individual data structures for zones allow a zone to be
- replaced simply by changing a pointer in the catalog. Zone
- refresh operations can build a new structure and, when
- complete, splice it into the database via a simple pointer
- replacement. It is very important that when a zone is
- refreshed, queries should not use old and new data
- simultaneously.
-
- - With the proper search procedures, authoritative data in zones
- will always "hide", and hence take precedence over, cached
- data.
-
- - Errors in zone definitions that cause overlapping zones, etc.,
- may cause erroneous responses to queries, but problem
- determination is simplified, and the contents of one "bad"
- zone can't corrupt another.
-
- - Since the cache is most frequently updated, it is most
- vulnerable to corruption during system restarts. It can also
- become full of expired RR data. In either case, it can easily
- be discarded without disturbing zone data.
-
-A major aspect of database design is selecting a structure which allows
-the name server to deal with crashes of the name server's host. State
-information which a name server should save across system crashes
-
-
-
-Mockapetris [Page 38]
-\f
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-includes the catalog structure (including the state of refreshing for
-each zone) and the zone data itself.
-
-6.1.3. Time
-
-Both the TTL data for RRs and the timing data for refreshing activities
-depends on 32 bit timers in units of seconds. Inside the database,
-refresh timers and TTLs for cached data conceptually "count down", while
-data in the zone stays with constant TTLs.
-
-A recommended implementation strategy is to store time in two ways: as
-a relative increment and as an absolute time. One way to do this is to
-use positive 32 bit numbers for one type and negative numbers for the
-other. The RRs in zones use relative times; the refresh timers and
-cache data use absolute times. Absolute numbers are taken with respect
-to some known origin and converted to relative values when placed in the
-response to a query. When an absolute TTL is negative after conversion
-to relative, then the data is expired and should be ignored.
-
-6.2. Standard query processing
-
-The major algorithm for standard query processing is presented in
-[RFC-1034].
-
-When processing queries with QCLASS=*, or some other QCLASS which
-matches multiple classes, the response should never be authoritative
-unless the server can guarantee that the response covers all classes.
-
-When composing a response, RRs which are to be inserted in the
-additional section, but duplicate RRs in the answer or authority
-sections, may be omitted from the additional section.
-
-When a response is so long that truncation is required, the truncation
-should start at the end of the response and work forward in the
-datagram. Thus if there is any data for the authority section, the
-answer section is guaranteed to be unique.
-
-The MINIMUM value in the SOA should be used to set a floor on the TTL of
-data distributed from a zone. This floor function should be done when
-the data is copied into a response. This will allow future dynamic
-update protocols to change the SOA MINIMUM field without ambiguous
-semantics.
-
-6.3. Zone refresh and reload processing
-
-In spite of a server's best efforts, it may be unable to load zone data
-from a master file due to syntax errors, etc., or be unable to refresh a
-zone within the its expiration parameter. In this case, the name server
-
-
-
-Mockapetris [Page 39]
-\f
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-should answer queries as if it were not supposed to possess the zone.
-
-If a master is sending a zone out via AXFR, and a new version is created
-during the transfer, the master should continue to send the old version
-if possible. In any case, it should never send part of one version and
-part of another. If completion is not possible, the master should reset
-the connection on which the zone transfer is taking place.
-
-6.4. Inverse queries (Optional)
-
-Inverse queries are an optional part of the DNS. Name servers are not
-required to support any form of inverse queries. If a name server
-receives an inverse query that it does not support, it returns an error
-response with the "Not Implemented" error set in the header. While
-inverse query support is optional, all name servers must be at least
-able to return the error response.
-
-6.4.1. The contents of inverse queries and responses Inverse
-queries reverse the mappings performed by standard query operations;
-while a standard query maps a domain name to a resource, an inverse
-query maps a resource to a domain name. For example, a standard query
-might bind a domain name to a host address; the corresponding inverse
-query binds the host address to a domain name.
-
-Inverse queries take the form of a single RR in the answer section of
-the message, with an empty question section. The owner name of the
-query RR and its TTL are not significant. The response carries
-questions in the question section which identify all names possessing
-the query RR WHICH THE NAME SERVER KNOWS. Since no name server knows
-about all of the domain name space, the response can never be assumed to
-be complete. Thus inverse queries are primarily useful for database
-management and debugging activities. Inverse queries are NOT an
-acceptable method of mapping host addresses to host names; use the IN-
-ADDR.ARPA domain instead.
-
-Where possible, name servers should provide case-insensitive comparisons
-for inverse queries. Thus an inverse query asking for an MX RR of
-"Venera.isi.edu" should get the same response as a query for
-"VENERA.ISI.EDU"; an inverse query for HINFO RR "IBM-PC UNIX" should
-produce the same result as an inverse query for "IBM-pc unix". However,
-this cannot be guaranteed because name servers may possess RRs that
-contain character strings but the name server does not know that the
-data is character.
-
-When a name server processes an inverse query, it either returns:
-
- 1. zero, one, or multiple domain names for the specified
- resource as QNAMEs in the question section
-
-
-
-Mockapetris [Page 40]
-\f
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- 2. an error code indicating that the name server doesn't support
- inverse mapping of the specified resource type.
-
-When the response to an inverse query contains one or more QNAMEs, the
-owner name and TTL of the RR in the answer section which defines the
-inverse query is modified to exactly match an RR found at the first
-QNAME.
-
-RRs returned in the inverse queries cannot be cached using the same
-mechanism as is used for the replies to standard queries. One reason
-for this is that a name might have multiple RRs of the same type, and
-only one would appear. For example, an inverse query for a single
-address of a multiply homed host might create the impression that only
-one address existed.
-
-6.4.2. Inverse query and response example The overall structure
-of an inverse query for retrieving the domain name that corresponds to
-Internet address 10.1.0.52 is shown below:
-
- +-----------------------------------------+
- Header | OPCODE=IQUERY, ID=997 |
- +-----------------------------------------+
- Question | <empty> |
- +-----------------------------------------+
- Answer | <anyname> A IN 10.1.0.52 |
- +-----------------------------------------+
- Authority | <empty> |
- +-----------------------------------------+
- Additional | <empty> |
- +-----------------------------------------+
-
-This query asks for a question whose answer is the Internet style
-address 10.1.0.52. Since the owner name is not known, any domain name
-can be used as a placeholder (and is ignored). A single octet of zero,
-signifying the root, is usually used because it minimizes the length of
-the message. The TTL of the RR is not significant. The response to
-this query might be:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris [Page 41]
-\f
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- +-----------------------------------------+
- Header | OPCODE=RESPONSE, ID=997 |
- +-----------------------------------------+
- Question |QTYPE=A, QCLASS=IN, QNAME=VENERA.ISI.EDU |
- +-----------------------------------------+
- Answer | VENERA.ISI.EDU A IN 10.1.0.52 |
- +-----------------------------------------+
- Authority | <empty> |
- +-----------------------------------------+
- Additional | <empty> |
- +-----------------------------------------+
-
-Note that the QTYPE in a response to an inverse query is the same as the
-TYPE field in the answer section of the inverse query. Responses to
-inverse queries may contain multiple questions when the inverse is not
-unique. If the question section in the response is not empty, then the
-RR in the answer section is modified to correspond to be an exact copy
-of an RR at the first QNAME.
-
-6.4.3. Inverse query processing
-
-Name servers that support inverse queries can support these operations
-through exhaustive searches of their databases, but this becomes
-impractical as the size of the database increases. An alternative
-approach is to invert the database according to the search key.
-
-For name servers that support multiple zones and a large amount of data,
-the recommended approach is separate inversions for each zone. When a
-particular zone is changed during a refresh, only its inversions need to
-be redone.
-
-Support for transfer of this type of inversion may be included in future
-versions of the domain system, but is not supported in this version.
-
-6.5. Completion queries and responses
-
-The optional completion services described in RFC-882 and RFC-883 have
-been deleted. Redesigned services may become available in the future.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris [Page 42]
-\f
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-7. RESOLVER IMPLEMENTATION
-
-The top levels of the recommended resolver algorithm are discussed in
-[RFC-1034]. This section discusses implementation details assuming the
-database structure suggested in the name server implementation section
-of this memo.
-
-7.1. Transforming a user request into a query
-
-The first step a resolver takes is to transform the client's request,
-stated in a format suitable to the local OS, into a search specification
-for RRs at a specific name which match a specific QTYPE and QCLASS.
-Where possible, the QTYPE and QCLASS should correspond to a single type
-and a single class, because this makes the use of cached data much
-simpler. The reason for this is that the presence of data of one type
-in a cache doesn't confirm the existence or non-existence of data of
-other types, hence the only way to be sure is to consult an
-authoritative source. If QCLASS=* is used, then authoritative answers
-won't be available.
-
-Since a resolver must be able to multiplex multiple requests if it is to
-perform its function efficiently, each pending request is usually
-represented in some block of state information. This state block will
-typically contain:
-
- - A timestamp indicating the time the request began.
- The timestamp is used to decide whether RRs in the database
- can be used or are out of date. This timestamp uses the
- absolute time format previously discussed for RR storage in
- zones and caches. Note that when an RRs TTL indicates a
- relative time, the RR must be timely, since it is part of a
- zone. When the RR has an absolute time, it is part of a
- cache, and the TTL of the RR is compared against the timestamp
- for the start of the request.
-
- Note that using the timestamp is superior to using a current
- time, since it allows RRs with TTLs of zero to be entered in
- the cache in the usual manner, but still used by the current
- request, even after intervals of many seconds due to system
- load, query retransmission timeouts, etc.
-
- - Some sort of parameters to limit the amount of work which will
- be performed for this request.
-
- The amount of work which a resolver will do in response to a
- client request must be limited to guard against errors in the
- database, such as circular CNAME references, and operational
- problems, such as network partition which prevents the
-
-
-
-Mockapetris [Page 43]
-\f
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- resolver from accessing the name servers it needs. While
- local limits on the number of times a resolver will retransmit
- a particular query to a particular name server address are
- essential, the resolver should have a global per-request
- counter to limit work on a single request. The counter should
- be set to some initial value and decremented whenever the
- resolver performs any action (retransmission timeout,
- retransmission, etc.) If the counter passes zero, the request
- is terminated with a temporary error.
-
- Note that if the resolver structure allows one request to
- start others in parallel, such as when the need to access a
- name server for one request causes a parallel resolve for the
- name server's addresses, the spawned request should be started
- with a lower counter. This prevents circular references in
- the database from starting a chain reaction of resolver
- activity.
-
- - The SLIST data structure discussed in [RFC-1034].
-
- This structure keeps track of the state of a request if it
- must wait for answers from foreign name servers.
-
-7.2. Sending the queries
-
-As described in [RFC-1034], the basic task of the resolver is to
-formulate a query which will answer the client's request and direct that
-query to name servers which can provide the information. The resolver
-will usually only have very strong hints about which servers to ask, in
-the form of NS RRs, and may have to revise the query, in response to
-CNAMEs, or revise the set of name servers the resolver is asking, in
-response to delegation responses which point the resolver to name
-servers closer to the desired information. In addition to the
-information requested by the client, the resolver may have to call upon
-its own services to determine the address of name servers it wishes to
-contact.
-
-In any case, the model used in this memo assumes that the resolver is
-multiplexing attention between multiple requests, some from the client,
-and some internally generated. Each request is represented by some
-state information, and the desired behavior is that the resolver
-transmit queries to name servers in a way that maximizes the probability
-that the request is answered, minimizes the time that the request takes,
-and avoids excessive transmissions. The key algorithm uses the state
-information of the request to select the next name server address to
-query, and also computes a timeout which will cause the next action
-should a response not arrive. The next action will usually be a
-transmission to some other server, but may be a temporary error to the
-
-
-
-Mockapetris [Page 44]
-\f
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-client.
-
-The resolver always starts with a list of server names to query (SLIST).
-This list will be all NS RRs which correspond to the nearest ancestor
-zone that the resolver knows about. To avoid startup problems, the
-resolver should have a set of default servers which it will ask should
-it have no current NS RRs which are appropriate. The resolver then adds
-to SLIST all of the known addresses for the name servers, and may start
-parallel requests to acquire the addresses of the servers when the
-resolver has the name, but no addresses, for the name servers.
-
-To complete initialization of SLIST, the resolver attaches whatever
-history information it has to the each address in SLIST. This will
-usually consist of some sort of weighted averages for the response time
-of the address, and the batting average of the address (i.e., how often
-the address responded at all to the request). Note that this
-information should be kept on a per address basis, rather than on a per
-name server basis, because the response time and batting average of a
-particular server may vary considerably from address to address. Note
-also that this information is actually specific to a resolver address /
-server address pair, so a resolver with multiple addresses may wish to
-keep separate histories for each of its addresses. Part of this step
-must deal with addresses which have no such history; in this case an
-expected round trip time of 5-10 seconds should be the worst case, with
-lower estimates for the same local network, etc.
-
-Note that whenever a delegation is followed, the resolver algorithm
-reinitializes SLIST.
-
-The information establishes a partial ranking of the available name
-server addresses. Each time an address is chosen and the state should
-be altered to prevent its selection again until all other addresses have
-been tried. The timeout for each transmission should be 50-100% greater
-than the average predicted value to allow for variance in response.
-
-Some fine points:
-
- - The resolver may encounter a situation where no addresses are
- available for any of the name servers named in SLIST, and
- where the servers in the list are precisely those which would
- normally be used to look up their own addresses. This
- situation typically occurs when the glue address RRs have a
- smaller TTL than the NS RRs marking delegation, or when the
- resolver caches the result of a NS search. The resolver
- should detect this condition and restart the search at the
- next ancestor zone, or alternatively at the root.
-
-
-
-
-
-Mockapetris [Page 45]
-\f
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- - If a resolver gets a server error or other bizarre response
- from a name server, it should remove it from SLIST, and may
- wish to schedule an immediate transmission to the next
- candidate server address.
-
-7.3. Processing responses
-
-The first step in processing arriving response datagrams is to parse the
-response. This procedure should include:
-
- - Check the header for reasonableness. Discard datagrams which
- are queries when responses are expected.
-
- - Parse the sections of the message, and insure that all RRs are
- correctly formatted.
-
- - As an optional step, check the TTLs of arriving data looking
- for RRs with excessively long TTLs. If a RR has an
- excessively long TTL, say greater than 1 week, either discard
- the whole response, or limit all TTLs in the response to 1
- week.
-
-The next step is to match the response to a current resolver request.
-The recommended strategy is to do a preliminary matching using the ID
-field in the domain header, and then to verify that the question section
-corresponds to the information currently desired. This requires that
-the transmission algorithm devote several bits of the domain ID field to
-a request identifier of some sort. This step has several fine points:
-
- - Some name servers send their responses from different
- addresses than the one used to receive the query. That is, a
- resolver cannot rely that a response will come from the same
- address which it sent the corresponding query to. This name
- server bug is typically encountered in UNIX systems.
-
- - If the resolver retransmits a particular request to a name
- server it should be able to use a response from any of the
- transmissions. However, if it is using the response to sample
- the round trip time to access the name server, it must be able
- to determine which transmission matches the response (and keep
- transmission times for each outgoing message), or only
- calculate round trip times based on initial transmissions.
-
- - A name server will occasionally not have a current copy of a
- zone which it should have according to some NS RRs. The
- resolver should simply remove the name server from the current
- SLIST, and continue.
-
-
-
-
-Mockapetris [Page 46]
-\f
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-7.4. Using the cache
-
-In general, we expect a resolver to cache all data which it receives in
-responses since it may be useful in answering future client requests.
-However, there are several types of data which should not be cached:
-
- - When several RRs of the same type are available for a
- particular owner name, the resolver should either cache them
- all or none at all. When a response is truncated, and a
- resolver doesn't know whether it has a complete set, it should
- not cache a possibly partial set of RRs.
-
- - Cached data should never be used in preference to
- authoritative data, so if caching would cause this to happen
- the data should not be cached.
-
- - The results of an inverse query should not be cached.
-
- - The results of standard queries where the QNAME contains "*"
- labels if the data might be used to construct wildcards. The
- reason is that the cache does not necessarily contain existing
- RRs or zone boundary information which is necessary to
- restrict the application of the wildcard RRs.
-
- - RR data in responses of dubious reliability. When a resolver
- receives unsolicited responses or RR data other than that
- requested, it should discard it without caching it. The basic
- implication is that all sanity checks on a packet should be
- performed before any of it is cached.
-
-In a similar vein, when a resolver has a set of RRs for some name in a
-response, and wants to cache the RRs, it should check its cache for
-already existing RRs. Depending on the circumstances, either the data
-in the response or the cache is preferred, but the two should never be
-combined. If the data in the response is from authoritative data in the
-answer section, it is always preferred.
-
-8. MAIL SUPPORT
-
-The domain system defines a standard for mapping mailboxes into domain
-names, and two methods for using the mailbox information to derive mail
-routing information. The first method is called mail exchange binding
-and the other method is mailbox binding. The mailbox encoding standard
-and mail exchange binding are part of the DNS official protocol, and are
-the recommended method for mail routing in the Internet. Mailbox
-binding is an experimental feature which is still under development and
-subject to change.
-
-
-
-
-Mockapetris [Page 47]
-\f
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-The mailbox encoding standard assumes a mailbox name of the form
-"<local-part>@<mail-domain>". While the syntax allowed in each of these
-sections varies substantially between the various mail internets, the
-preferred syntax for the ARPA Internet is given in [RFC-822].
-
-The DNS encodes the <local-part> as a single label, and encodes the
-<mail-domain> as a domain name. The single label from the <local-part>
-is prefaced to the domain name from <mail-domain> to form the domain
-name corresponding to the mailbox. Thus the mailbox HOSTMASTER@SRI-
-NIC.ARPA is mapped into the domain name HOSTMASTER.SRI-NIC.ARPA. If the
-<local-part> contains dots or other special characters, its
-representation in a master file will require the use of backslash
-quoting to ensure that the domain name is properly encoded. For
-example, the mailbox Action.domains@ISI.EDU would be represented as
-Action\.domains.ISI.EDU.
-
-8.1. Mail exchange binding
-
-Mail exchange binding uses the <mail-domain> part of a mailbox
-specification to determine where mail should be sent. The <local-part>
-is not even consulted. [RFC-974] specifies this method in detail, and
-should be consulted before attempting to use mail exchange support.
-
-One of the advantages of this method is that it decouples mail
-destination naming from the hosts used to support mail service, at the
-cost of another layer of indirection in the lookup function. However,
-the addition layer should eliminate the need for complicated "%", "!",
-etc encodings in <local-part>.
-
-The essence of the method is that the <mail-domain> is used as a domain
-name to locate type MX RRs which list hosts willing to accept mail for
-<mail-domain>, together with preference values which rank the hosts
-according to an order specified by the administrators for <mail-domain>.
-
-In this memo, the <mail-domain> ISI.EDU is used in examples, together
-with the hosts VENERA.ISI.EDU and VAXA.ISI.EDU as mail exchanges for
-ISI.EDU. If a mailer had a message for Mockapetris@ISI.EDU, it would
-route it by looking up MX RRs for ISI.EDU. The MX RRs at ISI.EDU name
-VENERA.ISI.EDU and VAXA.ISI.EDU, and type A queries can find the host
-addresses.
-
-8.2. Mailbox binding (Experimental)
-
-In mailbox binding, the mailer uses the entire mail destination
-specification to construct a domain name. The encoded domain name for
-the mailbox is used as the QNAME field in a QTYPE=MAILB query.
-
-Several outcomes are possible for this query:
-
-
-
-Mockapetris [Page 48]
-\f
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- 1. The query can return a name error indicating that the mailbox
- does not exist as a domain name.
-
- In the long term, this would indicate that the specified
- mailbox doesn't exist. However, until the use of mailbox
- binding is universal, this error condition should be
- interpreted to mean that the organization identified by the
- global part does not support mailbox binding. The
- appropriate procedure is to revert to exchange binding at
- this point.
-
- 2. The query can return a Mail Rename (MR) RR.
-
- The MR RR carries new mailbox specification in its RDATA
- field. The mailer should replace the old mailbox with the
- new one and retry the operation.
-
- 3. The query can return a MB RR.
-
- The MB RR carries a domain name for a host in its RDATA
- field. The mailer should deliver the message to that host
- via whatever protocol is applicable, e.g., b,SMTP.
-
- 4. The query can return one or more Mail Group (MG) RRs.
-
- This condition means that the mailbox was actually a mailing
- list or mail group, rather than a single mailbox. Each MG RR
- has a RDATA field that identifies a mailbox that is a member
- of the group. The mailer should deliver a copy of the
- message to each member.
-
- 5. The query can return a MB RR as well as one or more MG RRs.
-
- This condition means the the mailbox was actually a mailing
- list. The mailer can either deliver the message to the host
- specified by the MB RR, which will in turn do the delivery to
- all members, or the mailer can use the MG RRs to do the
- expansion itself.
-
-In any of these cases, the response may include a Mail Information
-(MINFO) RR. This RR is usually associated with a mail group, but is
-legal with a MB. The MINFO RR identifies two mailboxes. One of these
-identifies a responsible person for the original mailbox name. This
-mailbox should be used for requests to be added to a mail group, etc.
-The second mailbox name in the MINFO RR identifies a mailbox that should
-receive error messages for mail failures. This is particularly
-appropriate for mailing lists when errors in member names should be
-reported to a person other than the one who sends a message to the list.
-
-
-
-Mockapetris [Page 49]
-\f
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-New fields may be added to this RR in the future.
-
-
-9. REFERENCES and BIBLIOGRAPHY
-
-[Dyer 87] S. Dyer, F. Hsu, "Hesiod", Project Athena
- Technical Plan - Name Service, April 1987, version 1.9.
-
- Describes the fundamentals of the Hesiod name service.
-
-[IEN-116] J. Postel, "Internet Name Server", IEN-116,
- USC/Information Sciences Institute, August 1979.
-
- A name service obsoleted by the Domain Name System, but
- still in use.
-
-[Quarterman 86] J. Quarterman, and J. Hoskins, "Notable Computer Networks",
- Communications of the ACM, October 1986, volume 29, number
- 10.
-
-[RFC-742] K. Harrenstien, "NAME/FINGER", RFC-742, Network
- Information Center, SRI International, December 1977.
-
-[RFC-768] J. Postel, "User Datagram Protocol", RFC-768,
- USC/Information Sciences Institute, August 1980.
-
-[RFC-793] J. Postel, "Transmission Control Protocol", RFC-793,
- USC/Information Sciences Institute, September 1981.
-
-[RFC-799] D. Mills, "Internet Name Domains", RFC-799, COMSAT,
- September 1981.
-
- Suggests introduction of a hierarchy in place of a flat
- name space for the Internet.
-
-[RFC-805] J. Postel, "Computer Mail Meeting Notes", RFC-805,
- USC/Information Sciences Institute, February 1982.
-
-[RFC-810] E. Feinler, K. Harrenstien, Z. Su, and V. White, "DOD
- Internet Host Table Specification", RFC-810, Network
- Information Center, SRI International, March 1982.
-
- Obsolete. See RFC-952.
-
-[RFC-811] K. Harrenstien, V. White, and E. Feinler, "Hostnames
- Server", RFC-811, Network Information Center, SRI
- International, March 1982.
-
-
-
-
-Mockapetris [Page 50]
-\f
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- Obsolete. See RFC-953.
-
-[RFC-812] K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC-812,
- Network Information Center, SRI International, March
- 1982.
-
-[RFC-819] Z. Su, and J. Postel, "The Domain Naming Convention for
- Internet User Applications", RFC-819, Network
- Information Center, SRI International, August 1982.
-
- Early thoughts on the design of the domain system.
- Current implementation is completely different.
-
-[RFC-821] J. Postel, "Simple Mail Transfer Protocol", RFC-821,
- USC/Information Sciences Institute, August 1980.
-
-[RFC-830] Z. Su, "A Distributed System for Internet Name Service",
- RFC-830, Network Information Center, SRI International,
- October 1982.
-
- Early thoughts on the design of the domain system.
- Current implementation is completely different.
-
-[RFC-882] P. Mockapetris, "Domain names - Concepts and
- Facilities," RFC-882, USC/Information Sciences
- Institute, November 1983.
-
- Superceeded by this memo.
-
-[RFC-883] P. Mockapetris, "Domain names - Implementation and
- Specification," RFC-883, USC/Information Sciences
- Institute, November 1983.
-
- Superceeded by this memo.
-
-[RFC-920] J. Postel and J. Reynolds, "Domain Requirements",
- RFC-920, USC/Information Sciences Institute,
- October 1984.
-
- Explains the naming scheme for top level domains.
-
-[RFC-952] K. Harrenstien, M. Stahl, E. Feinler, "DoD Internet Host
- Table Specification", RFC-952, SRI, October 1985.
-
- Specifies the format of HOSTS.TXT, the host/address
- table replaced by the DNS.
-
-
-
-
-
-Mockapetris [Page 51]
-\f
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-[RFC-953] K. Harrenstien, M. Stahl, E. Feinler, "HOSTNAME Server",
- RFC-953, SRI, October 1985.
-
- This RFC contains the official specification of the
- hostname server protocol, which is obsoleted by the DNS.
- This TCP based protocol accesses information stored in
- the RFC-952 format, and is used to obtain copies of the
- host table.
-
-[RFC-973] P. Mockapetris, "Domain System Changes and
- Observations", RFC-973, USC/Information Sciences
- Institute, January 1986.
-
- Describes changes to RFC-882 and RFC-883 and reasons for
- them.
-
-[RFC-974] C. Partridge, "Mail routing and the domain system",
- RFC-974, CSNET CIC BBN Labs, January 1986.
-
- Describes the transition from HOSTS.TXT based mail
- addressing to the more powerful MX system used with the
- domain system.
-
-[RFC-1001] NetBIOS Working Group, "Protocol standard for a NetBIOS
- service on a TCP/UDP transport: Concepts and Methods",
- RFC-1001, March 1987.
-
- This RFC and RFC-1002 are a preliminary design for
- NETBIOS on top of TCP/IP which proposes to base NetBIOS
- name service on top of the DNS.
-
-[RFC-1002] NetBIOS Working Group, "Protocol standard for a NetBIOS
- service on a TCP/UDP transport: Detailed
- Specifications", RFC-1002, March 1987.
-
-[RFC-1010] J. Reynolds, and J. Postel, "Assigned Numbers", RFC-1010,
- USC/Information Sciences Institute, May 1987.
-
- Contains socket numbers and mnemonics for host names,
- operating systems, etc.
-
-[RFC-1031] W. Lazear, "MILNET Name Domain Transition", RFC-1031,
- November 1987.
-
- Describes a plan for converting the MILNET to the DNS.
-
-[RFC-1032] M. Stahl, "Establishing a Domain - Guidelines for
- Administrators", RFC-1032, November 1987.
-
-
-
-Mockapetris [Page 52]
-\f
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- Describes the registration policies used by the NIC to
- administer the top level domains and delegate subzones.
-
-[RFC-1033] M. Lottor, "Domain Administrators Operations Guide",
- RFC-1033, November 1987.
-
- A cookbook for domain administrators.
-
-[Solomon 82] M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET
- Name Server", Computer Networks, vol 6, nr 3, July 1982.
-
- Describes a name service for CSNET which is independent
- from the DNS and DNS use in the CSNET.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris [Page 53]
-\f
-RFC 1035 Domain Implementation and Specification November 1987
-
-
-Index
-
- * 13
-
- ; 33, 35
-
- <character-string> 35
- <domain-name> 34
-
- @ 35
-
- \ 35
-
- A 12
-
- Byte order 8
-
- CH 13
- Character case 9
- CLASS 11
- CNAME 12
- Completion 42
- CS 13
-
- Hesiod 13
- HINFO 12
- HS 13
-
- IN 13
- IN-ADDR.ARPA domain 22
- Inverse queries 40
-
- Mailbox names 47
- MB 12
- MD 12
- MF 12
- MG 12
- MINFO 12
- MINIMUM 20
- MR 12
- MX 12
-
- NS 12
- NULL 12
-
- Port numbers 32
- Primary server 5
- PTR 12, 18
-
-
-
-Mockapetris [Page 54]
-\f
-RFC 1035 Domain Implementation and Specification November 1987
-
-
- QCLASS 13
- QTYPE 12
-
- RDATA 12
- RDLENGTH 11
-
- Secondary server 5
- SOA 12
- Stub resolvers 7
-
- TCP 32
- TXT 12
- TYPE 11
-
- UDP 32
-
- WKS 12
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Mockapetris [Page 55]
-\f
+++ /dev/null
-
-
-
-
-
-
-Network Working Group R. Droms
-Request for Comments: 2131 Bucknell University
-Obsoletes: 1541 March 1997
-Category: Standards Track
-
- Dynamic Host Configuration Protocol
-
-Status of this memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Abstract
-
- The Dynamic Host Configuration Protocol (DHCP) provides a framework
- for passing configuration information to hosts on a TCPIP network.
- DHCP is based on the Bootstrap Protocol (BOOTP) [7], adding the
- capability of automatic allocation of reusable network addresses and
- additional configuration options [19]. DHCP captures the behavior of
- BOOTP relay agents [7, 21], and DHCP participants can interoperate
- with BOOTP participants [9].
-
-Table of Contents
-
- 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
- 1.1 Changes to RFC1541. . . . . . . . . . . . . . . . . . . . . . 3
- 1.2 Related Work. . . . . . . . . . . . . . . . . . . . . . . . . 4
- 1.3 Problem definition and issues . . . . . . . . . . . . . . . . 4
- 1.4 Requirements. . . . . . . . . . . . . . . . . . . . . . . . . 5
- 1.5 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
- 1.6 Design goals. . . . . . . . . . . . . . . . . . . . . . . . . 6
- 2. Protocol Summary. . . . . . . . . . . . . . . . . . . . . . . 8
- 2.1 Configuration parameters repository . . . . . . . . . . . . . 11
- 2.2 Dynamic allocation of network addresses . . . . . . . . . . . 12
- 3. The Client-Server Protocol. . . . . . . . . . . . . . . . . . 13
- 3.1 Client-server interaction - allocating a network address. . . 13
- 3.2 Client-server interaction - reusing a previously allocated
- network address . . . . . . . . . . . . . . . . . . . . . . . 17
- 3.3 Interpretation and representation of time values. . . . . . . 20
- 3.4 Obtaining parameters with externally configured network
- address . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
- 3.5 Client parameters in DHCP . . . . . . . . . . . . . . . . . . 21
- 3.6 Use of DHCP in clients with multiple interfaces . . . . . . . 22
- 3.7 When clients should use DHCP. . . . . . . . . . . . . . . . . 22
- 4. Specification of the DHCP client-server protocol. . . . . . . 22
-
-
-
-Droms Standards Track [Page 1]
-\f
-RFC 2131 Dynamic Host Configuration Protocol March 1997
-
-
- 4.1 Constructing and sending DHCP messages. . . . . . . . . . . . 22
- 4.2 DHCP server administrative controls . . . . . . . . . . . . . 25
- 4.3 DHCP server behavior. . . . . . . . . . . . . . . . . . . . . 26
- 4.4 DHCP client behavior. . . . . . . . . . . . . . . . . . . . . 34
- 5. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . .42
- 6. References . . . . . . . . . . . . . . . . . . . . . . . . . .42
- 7. Security Considerations. . . . . . . . . . . . . . . . . . . .43
- 8. Author's Address . . . . . . . . . . . . . . . . . . . . . . .44
- A. Host Configuration Parameters . . . . . . . . . . . . . . . .45
-List of Figures
- 1. Format of a DHCP message . . . . . . . . . . . . . . . . . . . 9
- 2. Format of the 'flags' field. . . . . . . . . . . . . . . . . . 11
- 3. Timeline diagram of messages exchanged between DHCP client and
- servers when allocating a new network address. . . . . . . . . 15
- 4. Timeline diagram of messages exchanged between DHCP client and
- servers when reusing a previously allocated network address. . 18
- 5. State-transition diagram for DHCP clients. . . . . . . . . . . 34
-List of Tables
- 1. Description of fields in a DHCP message. . . . . . . . . . . . 10
- 2. DHCP messages. . . . . . . . . . . . . . . . . . . . . . . . . 14
- 3. Fields and options used by DHCP servers. . . . . . . . . . . . 28
- 4. Client messages from various states. . . . . . . . . . . . . . 33
- 5. Fields and options used by DHCP clients. . . . . . . . . . . . 37
-
-1. Introduction
-
- The Dynamic Host Configuration Protocol (DHCP) provides configuration
- parameters to Internet hosts. DHCP consists of two components: a
- protocol for delivering host-specific configuration parameters from a
- DHCP server to a host and a mechanism for allocation of network
- addresses to hosts.
-
- DHCP is built on a client-server model, where designated DHCP server
- hosts allocate network addresses and deliver configuration parameters
- to dynamically configured hosts. Throughout the remainder of this
- document, the term "server" refers to a host providing initialization
- parameters through DHCP, and the term "client" refers to a host
- requesting initialization parameters from a DHCP server.
-
- A host should not act as a DHCP server unless explicitly configured
- to do so by a system administrator. The diversity of hardware and
- protocol implementations in the Internet would preclude reliable
- operation if random hosts were allowed to respond to DHCP requests.
- For example, IP requires the setting of many parameters within the
- protocol implementation software. Because IP can be used on many
- dissimilar kinds of network hardware, values for those parameters
- cannot be guessed or assumed to have correct defaults. Also,
- distributed address allocation schemes depend on a polling/defense
-
-
-
-Droms Standards Track [Page 2]
-\f
-RFC 2131 Dynamic Host Configuration Protocol March 1997
-
-
- mechanism for discovery of addresses that are already in use. IP
- hosts may not always be able to defend their network addresses, so
- that such a distributed address allocation scheme cannot be
- guaranteed to avoid allocation of duplicate network addresses.
-
- DHCP supports three mechanisms for IP address allocation. In
- "automatic allocation", DHCP assigns a permanent IP address to a
- client. In "dynamic allocation", DHCP assigns an IP address to a
- client for a limited period of time (or until the client explicitly
- relinquishes the address). In "manual allocation", a client's IP
- address is assigned by the network administrator, and DHCP is used
- simply to convey the assigned address to the client. A particular
- network will use one or more of these mechanisms, depending on the
- policies of the network administrator.
-
- Dynamic allocation is the only one of the three mechanisms that
- allows automatic reuse of an address that is no longer needed by the
- client to which it was assigned. Thus, dynamic allocation is
- particularly useful for assigning an address to a client that will be
- connected to the network only temporarily or for sharing a limited
- pool of IP addresses among a group of clients that do not need
- permanent IP addresses. Dynamic allocation may also be a good choice
- for assigning an IP address to a new client being permanently
- connected to a network where IP addresses are sufficiently scarce
- that it is important to reclaim them when old clients are retired.
- Manual allocation allows DHCP to be used to eliminate the error-prone
- process of manually configuring hosts with IP addresses in
- environments where (for whatever reasons) it is desirable to manage
- IP address assignment outside of the DHCP mechanisms.
-
- The format of DHCP messages is based on the format of BOOTP messages,
- to capture the BOOTP relay agent behavior described as part of the
- BOOTP specification [7, 21] and to allow interoperability of existing
- BOOTP clients with DHCP servers. Using BOOTP relay agents eliminates
- the necessity of having a DHCP server on each physical network
- segment.
-
-1.1 Changes to RFC 1541
-
- This document updates the DHCP protocol specification that appears in
- RFC1541. A new DHCP message type, DHCPINFORM, has been added; see
- section 3.4, 4.3 and 4.4 for details. The classing mechanism for
- identifying DHCP clients to DHCP servers has been extended to include
- "vendor" classes as defined in sections 4.2 and 4.3. The minimum
- lease time restriction has been removed. Finally, many editorial
- changes have been made to clarify the text as a result of experience
- gained in DHCP interoperability tests.
-
-
-
-
-Droms Standards Track [Page 3]
-\f
-RFC 2131 Dynamic Host Configuration Protocol March 1997
-
-
-1.2 Related Work
-
- There are several Internet protocols and related mechanisms that
- address some parts of the dynamic host configuration problem. The
- Reverse Address Resolution Protocol (RARP) [10] (through the
- extensions defined in the Dynamic RARP (DRARP) [5]) explicitly
- addresses the problem of network address discovery, and includes an
- automatic IP address assignment mechanism. The Trivial File Transfer
- Protocol (TFTP) [20] provides for transport of a boot image from a
- boot server. The Internet Control Message Protocol (ICMP) [16]
- provides for informing hosts of additional routers via "ICMP
- redirect" messages. ICMP also can provide subnet mask information
- through the "ICMP mask request" message and other information through
- the (obsolete) "ICMP information request" message. Hosts can locate
- routers through the ICMP router discovery mechanism [8].
-
- BOOTP is a transport mechanism for a collection of configuration
- information. BOOTP is also extensible, and official extensions [17]
- have been defined for several configuration parameters. Morgan has
- proposed extensions to BOOTP for dynamic IP address assignment [15].
- The Network Information Protocol (NIP), used by the Athena project at
- MIT, is a distributed mechanism for dynamic IP address assignment
- [19]. The Resource Location Protocol RLP [1] provides for location
- of higher level services. Sun Microsystems diskless workstations use
- a boot procedure that employs RARP, TFTP and an RPC mechanism called
- "bootparams" to deliver configuration information and operating
- system code to diskless hosts. (Sun Microsystems, Sun Workstation
- and SunOS are trademarks of Sun Microsystems, Inc.) Some Sun
- networks also use DRARP and an auto-installation mechanism to
- automate the configuration of new hosts in an existing network.
-
- In other related work, the path minimum transmission unit (MTU)
- discovery algorithm can determine the MTU of an arbitrary internet
- path [14]. The Address Resolution Protocol (ARP) has been proposed
- as a transport protocol for resource location and selection [6].
- Finally, the Host Requirements RFCs [3, 4] mention specific
- requirements for host reconfiguration and suggest a scenario for
- initial configuration of diskless hosts.
-
-1.3 Problem definition and issues
-
- DHCP is designed to supply DHCP clients with the configuration
- parameters defined in the Host Requirements RFCs. After obtaining
- parameters via DHCP, a DHCP client should be able to exchange packets
- with any other host in the Internet. The TCP/IP stack parameters
- supplied by DHCP are listed in Appendix A.
-
-
-
-
-
-Droms Standards Track [Page 4]
-\f
-RFC 2131 Dynamic Host Configuration Protocol March 1997
-
-
- Not all of these parameters are required for a newly initialized
- client. A client and server may negotiate for the transmission of
- only those parameters required by the client or specific to a
- particular subnet.
-
- DHCP allows but does not require the configuration of client
- parameters not directly related to the IP protocol. DHCP also does
- not address registration of newly configured clients with the Domain
- Name System (DNS) [12, 13].
-
- DHCP is not intended for use in configuring routers.
-
-1.4 Requirements
-
- Throughout this document, the words that are used to define the
- significance of particular requirements are capitalized. These words
- are:
-
- o "MUST"
-
- This word or the adjective "REQUIRED" means that the
- item is an absolute requirement of this specification.
-
- o "MUST NOT"
-
- This phrase means that the item is an absolute prohibition
- of this specification.
-
- o "SHOULD"
-
- This word or the adjective "RECOMMENDED" means that there
- may exist valid reasons in particular circumstances to ignore
- this item, but the full implications should be understood and
- the case carefully weighed before choosing a different course.
-
- o "SHOULD NOT"
-
- This phrase means that there may exist valid reasons in
- particular circumstances when the listed behavior is acceptable
- or even useful, but the full implications should be understood
- and the case carefully weighed before implementing any behavior
- described with this label.
-
-
-
-
-
-
-
-
-
-Droms Standards Track [Page 5]
-\f
-RFC 2131 Dynamic Host Configuration Protocol March 1997
-
-
- o "MAY"
-
- This word or the adjective "OPTIONAL" means that this item is
- truly optional. One vendor may choose to include the item
- because a particular marketplace requires it or because it
- enhances the product, for example; another vendor may omit the
- same item.
-
-1.5 Terminology
-
- This document uses the following terms:
-
- o "DHCP client"
-
- A DHCP client is an Internet host using DHCP to obtain
- configuration parameters such as a network address.
-
- o "DHCP server"
-
- A DHCP server is an Internet host that returns configuration
- parameters to DHCP clients.
-
- o "BOOTP relay agent"
-
- A BOOTP relay agent or relay agent is an Internet host or router
- that passes DHCP messages between DHCP clients and DHCP servers.
- DHCP is designed to use the same relay agent behavior as specified
- in the BOOTP protocol specification.
-
- o "binding"
-
- A binding is a collection of configuration parameters, including
- at least an IP address, associated with or "bound to" a DHCP
- client. Bindings are managed by DHCP servers.
-
-1.6 Design goals
-
- The following list gives general design goals for DHCP.
-
- o DHCP should be a mechanism rather than a policy. DHCP must
- allow local system administrators control over configuration
- parameters where desired; e.g., local system administrators
- should be able to enforce local policies concerning allocation
- and access to local resources where desired.
-
-
-
-
-
-
-
-Droms Standards Track [Page 6]
-\f
-RFC 2131 Dynamic Host Configuration Protocol March 1997
-
-
- o Clients should require no manual configuration. Each client
- should be able to discover appropriate local configuration
- parameters without user intervention and incorporate those
- parameters into its own configuration.
-
- o Networks should require no manual configuration for individual
- clients. Under normal circumstances, the network manager
- should not have to enter any per-client configuration
- parameters.
-
- o DHCP should not require a server on each subnet. To allow for
- scale and economy, DHCP must work across routers or through the
- intervention of BOOTP relay agents.
-
- o A DHCP client must be prepared to receive multiple responses
- to a request for configuration parameters. Some installations
- may include multiple, overlapping DHCP servers to enhance
- reliability and increase performance.
-
- o DHCP must coexist with statically configured, non-participating
- hosts and with existing network protocol implementations.
-
- o DHCP must interoperate with the BOOTP relay agent behavior as
- described by RFC 951 and by RFC 1542 [21].
-
- o DHCP must provide service to existing BOOTP clients.
-
- The following list gives design goals specific to the transmission of
- the network layer parameters. DHCP must:
-
- o Guarantee that any specific network address will not be in
- use by more than one DHCP client at a time,
-
- o Retain DHCP client configuration across DHCP client reboot. A
- DHCP client should, whenever possible, be assigned the same
- configuration parameters (e.g., network address) in response
- to each request,
-
- o Retain DHCP client configuration across server reboots, and,
- whenever possible, a DHCP client should be assigned the same
- configuration parameters despite restarts of the DHCP mechanism,
-
- o Allow automated assignment of configuration parameters to new
- clients to avoid hand configuration for new clients,
-
- o Support fixed or permanent allocation of configuration
- parameters to specific clients.
-
-
-
-
-Droms Standards Track [Page 7]
-\f
-RFC 2131 Dynamic Host Configuration Protocol March 1997
-
-
-2. Protocol Summary
-
- From the client's point of view, DHCP is an extension of the BOOTP
- mechanism. This behavior allows existing BOOTP clients to
- interoperate with DHCP servers without requiring any change to the
- clients' initialization software. RFC 1542 [2] details the
- interactions between BOOTP and DHCP clients and servers [9]. There
- are some new, optional transactions that optimize the interaction
- between DHCP clients and servers that are described in sections 3 and
- 4.
-
- Figure 1 gives the format of a DHCP message and table 1 describes
- each of the fields in the DHCP message. The numbers in parentheses
- indicate the size of each field in octets. The names for the fields
- given in the figure will be used throughout this document to refer to
- the fields in DHCP messages.
-
- There are two primary differences between DHCP and BOOTP. First,
- DHCP defines mechanisms through which clients can be assigned a
- network address for a finite lease, allowing for serial reassignment
- of network addresses to different clients. Second, DHCP provides the
- mechanism for a client to acquire all of the IP configuration
- parameters that it needs in order to operate.
-
- DHCP introduces a small change in terminology intended to clarify the
- meaning of one of the fields. What was the "vendor extensions" field
- in BOOTP has been re-named the "options" field in DHCP. Similarly,
- the tagged data items that were used inside the BOOTP "vendor
- extensions" field, which were formerly referred to as "vendor
- extensions," are now termed simply "options."
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Droms Standards Track [Page 8]
-\f
-RFC 2131 Dynamic Host Configuration Protocol March 1997
-
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | op (1) | htype (1) | hlen (1) | hops (1) |
- +---------------+---------------+---------------+---------------+
- | xid (4) |
- +-------------------------------+-------------------------------+
- | secs (2) | flags (2) |
- +-------------------------------+-------------------------------+
- | ciaddr (4) |
- +---------------------------------------------------------------+
- | yiaddr (4) |
- +---------------------------------------------------------------+
- | siaddr (4) |
- +---------------------------------------------------------------+
- | giaddr (4) |
- +---------------------------------------------------------------+
- | |
- | chaddr (16) |
- | |
- | |
- +---------------------------------------------------------------+
- | |
- | sname (64) |
- +---------------------------------------------------------------+
- | |
- | file (128) |
- +---------------------------------------------------------------+
- | |
- | options (variable) |
- +---------------------------------------------------------------+
-
- Figure 1: Format of a DHCP message
-
- DHCP defines a new 'client identifier' option that is used to pass an
- explicit client identifier to a DHCP server. This change eliminates
- the overloading of the 'chaddr' field in BOOTP messages, where
- 'chaddr' is used both as a hardware address for transmission of BOOTP
- reply messages and as a client identifier. The 'client identifier'
- is an opaque key, not to be interpreted by the server; for example,
- the 'client identifier' may contain a hardware address, identical to
- the contents of the 'chaddr' field, or it may contain another type of
- identifier, such as a DNS name. The 'client identifier' chosen by a
- DHCP client MUST be unique to that client within the subnet to which
- the client is attached. If the client uses a 'client identifier' in
- one message, it MUST use that same identifier in all subsequent
- messages, to ensure that all servers correctly identify the client.
-
-
-
-
-Droms Standards Track [Page 9]
-\f
-RFC 2131 Dynamic Host Configuration Protocol March 1997
-
-
- DHCP clarifies the interpretation of the 'siaddr' field as the
- address of the server to use in the next step of the client's
- bootstrap process. A DHCP server may return its own address in the
- 'siaddr' field, if the server is prepared to supply the next
- bootstrap service (e.g., delivery of an operating system executable
- image). A DHCP server always returns its own address in the 'server
- identifier' option.
-
- FIELD OCTETS DESCRIPTION
- ----- ------ -----------
-
- op 1 Message op code / message type.
- 1 = BOOTREQUEST, 2 = BOOTREPLY
- htype 1 Hardware address type, see ARP section in "Assigned
- Numbers" RFC; e.g., '1' = 10mb ethernet.
- hlen 1 Hardware address length (e.g. '6' for 10mb
- ethernet).
- hops 1 Client sets to zero, optionally used by relay agents
- when booting via a relay agent.
- xid 4 Transaction ID, a random number chosen by the
- client, used by the client and server to associate
- messages and responses between a client and a
- server.
- secs 2 Filled in by client, seconds elapsed since client
- began address acquisition or renewal process.
- flags 2 Flags (see figure 2).
- ciaddr 4 Client IP address; only filled in if client is in
- BOUND, RENEW or REBINDING state and can respond
- to ARP requests.
- yiaddr 4 'your' (client) IP address.
- siaddr 4 IP address of next server to use in bootstrap;
- returned in DHCPOFFER, DHCPACK by server.
- giaddr 4 Relay agent IP address, used in booting via a
- relay agent.
- chaddr 16 Client hardware address.
- sname 64 Optional server host name, null terminated string.
- file 128 Boot file name, null terminated string; "generic"
- name or null in DHCPDISCOVER, fully qualified
- directory-path name in DHCPOFFER.
- options var Optional parameters field. See the options
- documents for a list of defined options.
-
- Table 1: Description of fields in a DHCP message
-
- The 'options' field is now variable length. A DHCP client must be
- prepared to receive DHCP messages with an 'options' field of at least
- length 312 octets. This requirement implies that a DHCP client must
- be prepared to receive a message of up to 576 octets, the minimum IP
-
-
-
-Droms Standards Track [Page 10]
-\f
-RFC 2131 Dynamic Host Configuration Protocol March 1997
-
-
- datagram size an IP host must be prepared to accept [3]. DHCP
- clients may negotiate the use of larger DHCP messages through the
- 'maximum DHCP message size' option. The options field may be further
- extended into the 'file' and 'sname' fields.
-
- In the case of a client using DHCP for initial configuration (before
- the client's TCP/IP software has been completely configured), DHCP
- requires creative use of the client's TCP/IP software and liberal
- interpretation of RFC 1122. The TCP/IP software SHOULD accept and
- forward to the IP layer any IP packets delivered to the client's
- hardware address before the IP address is configured; DHCP servers
- and BOOTP relay agents may not be able to deliver DHCP messages to
- clients that cannot accept hardware unicast datagrams before the
- TCP/IP software is configured.
-
- To work around some clients that cannot accept IP unicast datagrams
- before the TCP/IP software is configured as discussed in the previous
- paragraph, DHCP uses the 'flags' field [21]. The leftmost bit is
- defined as the BROADCAST (B) flag. The semantics of this flag are
- discussed in section 4.1 of this document. The remaining bits of the
- flags field are reserved for future use. They MUST be set to zero by
- clients and ignored by servers and relay agents. Figure 2 gives the
- format of the 'flags' field.
-
- 1 1 1 1 1 1
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |B| MBZ |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- B: BROADCAST flag
-
- MBZ: MUST BE ZERO (reserved for future use)
-
- Figure 2: Format of the 'flags' field
-
-2.1 Configuration parameters repository
-
- The first service provided by DHCP is to provide persistent storage
- of network parameters for network clients. The model of DHCP
- persistent storage is that the DHCP service stores a key-value entry
- for each client, where the key is some unique identifier (for
- example, an IP subnet number and a unique identifier within the
- subnet) and the value contains the configuration parameters for the
- client.
-
- For example, the key might be the pair (IP-subnet-number, hardware-
- address) (note that the "hardware-address" should be typed by the
-
-
-
-Droms Standards Track [Page 11]
-\f
-RFC 2131 Dynamic Host Configuration Protocol March 1997
-
-
- type of hardware to accommodate possible duplication of hardware
- addresses resulting from bit-ordering problems in a mixed-media,
- bridged network) allowing for serial or concurrent reuse of a
- hardware address on different subnets, and for hardware addresses
- that may not be globally unique. Alternately, the key might be the
- pair (IP-subnet-number, hostname), allowing the server to assign
- parameters intelligently to a DHCP client that has been moved to a
- different subnet or has changed hardware addresses (perhaps because
- the network interface failed and was replaced). The protocol defines
- that the key will be (IP-subnet-number, hardware-address) unless the
- client explicitly supplies an identifier using the 'client
- identifier' option. A client can query the DHCP service to
- retrieve its configuration parameters. The client interface to the
- configuration parameters repository consists of protocol messages to
- request configuration parameters and responses from the server
- carrying the configuration parameters.
-
-2.2 Dynamic allocation of network addresses
-
- The second service provided by DHCP is the allocation of temporary or
- permanent network (IP) addresses to clients. The basic mechanism for
- the dynamic allocation of network addresses is simple: a client
- requests the use of an address for some period of time. The
- allocation mechanism (the collection of DHCP servers) guarantees not
- to reallocate that address within the requested time and attempts to
- return the same network address each time the client requests an
- address. In this document, the period over which a network address
- is allocated to a client is referred to as a "lease" [11]. The
- client may extend its lease with subsequent requests. The client may
- issue a message to release the address back to the server when the
- client no longer needs the address. The client may ask for a
- permanent assignment by asking for an infinite lease. Even when
- assigning "permanent" addresses, a server may choose to give out
- lengthy but non-infinite leases to allow detection of the fact that
- the client has been retired.
-
- In some environments it will be necessary to reassign network
- addresses due to exhaustion of available addresses. In such
- environments, the allocation mechanism will reuse addresses whose
- lease has expired. The server should use whatever information is
- available in the configuration information repository to choose an
- address to reuse. For example, the server may choose the least
- recently assigned address. As a consistency check, the allocating
- server SHOULD probe the reused address before allocating the address,
- e.g., with an ICMP echo request, and the client SHOULD probe the
- newly received address, e.g., with ARP.
-
-
-
-
-
-Droms Standards Track [Page 12]
-\f
-RFC 2131 Dynamic Host Configuration Protocol March 1997
-
-
-3. The Client-Server Protocol
-
- DHCP uses the BOOTP message format defined in RFC 951 and given in
- table 1 and figure 1. The 'op' field of each DHCP message sent from
- a client to a server contains BOOTREQUEST. BOOTREPLY is used in the
- 'op' field of each DHCP message sent from a server to a client.
-
- The first four octets of the 'options' field of the DHCP message
- contain the (decimal) values 99, 130, 83 and 99, respectively (this
- is the same magic cookie as is defined in RFC 1497 [17]). The
- remainder of the 'options' field consists of a list of tagged
- parameters that are called "options". All of the "vendor extensions"
- listed in RFC 1497 are also DHCP options. RFC 1533 gives the
- complete set of options defined for use with DHCP.
-
- Several options have been defined so far. One particular option -
- the "DHCP message type" option - must be included in every DHCP
- message. This option defines the "type" of the DHCP message.
- Additional options may be allowed, required, or not allowed,
- depending on the DHCP message type.
-
- Throughout this document, DHCP messages that include a 'DHCP message
- type' option will be referred to by the type of the message; e.g., a
- DHCP message with 'DHCP message type' option type 1 will be referred
- to as a "DHCPDISCOVER" message.
-
-3.1 Client-server interaction - allocating a network address
-
- The following summary of the protocol exchanges between clients and
- servers refers to the DHCP messages described in table 2. The
- timeline diagram in figure 3 shows the timing relationships in a
- typical client-server interaction. If the client already knows its
- address, some steps may be omitted; this abbreviated interaction is
- described in section 3.2.
-
- 1. The client broadcasts a DHCPDISCOVER message on its local physical
- subnet. The DHCPDISCOVER message MAY include options that suggest
- values for the network address and lease duration. BOOTP relay
- agents may pass the message on to DHCP servers not on the same
- physical subnet.
-
- 2. Each server may respond with a DHCPOFFER message that includes an
- available network address in the 'yiaddr' field (and other
- configuration parameters in DHCP options). Servers need not
- reserve the offered network address, although the protocol will
- work more efficiently if the server avoids allocating the offered
- network address to another client. When allocating a new address,
- servers SHOULD check that the offered network address is not
-
-
-
-Droms Standards Track [Page 13]
-\f
-RFC 2131 Dynamic Host Configuration Protocol March 1997
-
-
- already in use; e.g., the server may probe the offered address
- with an ICMP Echo Request. Servers SHOULD be implemented so that
- network administrators MAY choose to disable probes of newly
- allocated addresses. The server transmits the DHCPOFFER message
- to the client, using the BOOTP relay agent if necessary.
-
- Message Use
- ------- ---
-
- DHCPDISCOVER - Client broadcast to locate available servers.
-
- DHCPOFFER - Server to client in response to DHCPDISCOVER with
- offer of configuration parameters.
-
- DHCPREQUEST - Client message to servers either (a) requesting
- offered parameters from one server and implicitly
- declining offers from all others, (b) confirming
- correctness of previously allocated address after,
- e.g., system reboot, or (c) extending the lease on a
- particular network address.
-
- DHCPACK - Server to client with configuration parameters,
- including committed network address.
-
- DHCPNAK - Server to client indicating client's notion of network
- address is incorrect (e.g., client has moved to new
- subnet) or client's lease as expired
-
- DHCPDECLINE - Client to server indicating network address is already
- in use.
-
- DHCPRELEASE - Client to server relinquishing network address and
- cancelling remaining lease.
-
- DHCPINFORM - Client to server, asking only for local configuration
- parameters; client already has externally configured
- network address.
-
- Table 2: DHCP messages
-
-
-
-
-
-
-
-
-
-
-
-
-Droms Standards Track [Page 14]
-\f
-RFC 2131 Dynamic Host Configuration Protocol March 1997
-
-
- Server Client Server
- (not selected) (selected)
-
- v v v
- | | |
- | Begins initialization |
- | | |
- | _____________/|\____________ |
- |/DHCPDISCOVER | DHCPDISCOVER \|
- | | |
- Determines | Determines
- configuration | configuration
- | | |
- |\ | ____________/ |
- | \________ | /DHCPOFFER |
- | DHCPOFFER\ |/ |
- | \ | |
- | Collects replies |
- | \| |
- | Selects configuration |
- | | |
- | _____________/|\____________ |
- |/ DHCPREQUEST | DHCPREQUEST\ |
- | | |
- | | Commits configuration
- | | |
- | | _____________/|
- | |/ DHCPACK |
- | | |
- | Initialization complete |
- | | |
- . . .
- . . .
- | | |
- | Graceful shutdown |
- | | |
- | |\ ____________ |
- | | DHCPRELEASE \|
- | | |
- | | Discards lease
- | | |
- v v v
- Figure 3: Timeline diagram of messages exchanged between DHCP
- client and servers when allocating a new network address
-
-
-
-
-
-
-
-Droms Standards Track [Page 15]
-\f
-RFC 2131 Dynamic Host Configuration Protocol March 1997
-
-
- 3. The client receives one or more DHCPOFFER messages from one or more
- servers. The client may choose to wait for multiple responses.
- The client chooses one server from which to request configuration
- parameters, based on the configuration parameters offered in the
- DHCPOFFER messages. The client broadcasts a DHCPREQUEST message
- that MUST include the 'server identifier' option to indicate which
- server it has selected, and that MAY include other options
- specifying desired configuration values. The 'requested IP
- address' option MUST be set to the value of 'yiaddr' in the
- DHCPOFFER message from the server. This DHCPREQUEST message is
- broadcast and relayed through DHCP/BOOTP relay agents. To help
- ensure that any BOOTP relay agents forward the DHCPREQUEST message
- to the same set of DHCP servers that received the original
- DHCPDISCOVER message, the DHCPREQUEST message MUST use the same
- value in the DHCP message header's 'secs' field and be sent to the
- same IP broadcast address as the original DHCPDISCOVER message.
- The client times out and retransmits the DHCPDISCOVER message if
- the client receives no DHCPOFFER messages.
-
- 4. The servers receive the DHCPREQUEST broadcast from the client.
- Those servers not selected by the DHCPREQUEST message use the
- message as notification that the client has declined that server's
- offer. The server selected in the DHCPREQUEST message commits the
- binding for the client to persistent storage and responds with a
- DHCPACK message containing the configuration parameters for the
- requesting client. The combination of 'client identifier' or
- 'chaddr' and assigned network address constitute a unique
- identifier for the client's lease and are used by both the client
- and server to identify a lease referred to in any DHCP messages.
- Any configuration parameters in the DHCPACK message SHOULD NOT
- conflict with those in the earlier DHCPOFFER message to which the
- client is responding. The server SHOULD NOT check the offered
- network address at this point. The 'yiaddr' field in the DHCPACK
- messages is filled in with the selected network address.
-
- If the selected server is unable to satisfy the DHCPREQUEST message
- (e.g., the requested network address has been allocated), the
- server SHOULD respond with a DHCPNAK message.
-
- A server MAY choose to mark addresses offered to clients in
- DHCPOFFER messages as unavailable. The server SHOULD mark an
- address offered to a client in a DHCPOFFER message as available if
- the server receives no DHCPREQUEST message from that client.
-
- 5. The client receives the DHCPACK message with configuration
- parameters. The client SHOULD perform a final check on the
- parameters (e.g., ARP for allocated network address), and notes the
- duration of the lease specified in the DHCPACK message. At this
-
-
-
-Droms Standards Track [Page 16]
-\f
-RFC 2131 Dynamic Host Configuration Protocol March 1997
-
-
- point, the client is configured. If the client detects that the
- address is already in use (e.g., through the use of ARP), the
- client MUST send a DHCPDECLINE message to the server and restarts
- the configuration process. The client SHOULD wait a minimum of ten
- seconds before restarting the configuration process to avoid
- excessive network traffic in case of looping.
-
- If the client receives a DHCPNAK message, the client restarts the
- configuration process.
-
- The client times out and retransmits the DHCPREQUEST message if the
- client receives neither a DHCPACK or a DHCPNAK message. The client
- retransmits the DHCPREQUEST according to the retransmission
- algorithm in section 4.1. The client should choose to retransmit
- the DHCPREQUEST enough times to give adequate probability of
- contacting the server without causing the client (and the user of
- that client) to wait overly long before giving up; e.g., a client
- retransmitting as described in section 4.1 might retransmit the
- DHCPREQUEST message four times, for a total delay of 60 seconds,
- before restarting the initialization procedure. If the client
- receives neither a DHCPACK or a DHCPNAK message after employing the
- retransmission algorithm, the client reverts to INIT state and
- restarts the initialization process. The client SHOULD notify the
- user that the initialization process has failed and is restarting.
-
- 6. The client may choose to relinquish its lease on a network address
- by sending a DHCPRELEASE message to the server. The client
- identifies the lease to be released with its 'client identifier',
- or 'chaddr' and network address in the DHCPRELEASE message. If the
- client used a 'client identifier' when it obtained the lease, it
- MUST use the same 'client identifier' in the DHCPRELEASE message.
-
-3.2 Client-server interaction - reusing a previously allocated network
- address
-
- If a client remembers and wishes to reuse a previously allocated
- network address, a client may choose to omit some of the steps
- described in the previous section. The timeline diagram in figure 4
- shows the timing relationships in a typical client-server interaction
- for a client reusing a previously allocated network address.
-
-
-
-
-
-
-
-
-
-
-
-Droms Standards Track [Page 17]
-\f
-RFC 2131 Dynamic Host Configuration Protocol March 1997
-
-
- 1. The client broadcasts a DHCPREQUEST message on its local subnet.
- The message includes the client's network address in the
- 'requested IP address' option. As the client has not received its
- network address, it MUST NOT fill in the 'ciaddr' field. BOOTP
- relay agents pass the message on to DHCP servers not on the same
- subnet. If the client used a 'client identifier' to obtain its
- address, the client MUST use the same 'client identifier' in the
- DHCPREQUEST message.
-
- 2. Servers with knowledge of the client's configuration parameters
- respond with a DHCPACK message to the client. Servers SHOULD NOT
- check that the client's network address is already in use; the
- client may respond to ICMP Echo Request messages at this point.
-
- Server Client Server
-
- v v v
- | | |
- | Begins |
- | initialization |
- | | |
- | /|\ |
- | _________ __/ | \__________ |
- | /DHCPREQU EST | DHCPREQUEST\ |
- |/ | \|
- | | |
- Locates | Locates
- configuration | configuration
- | | |
- |\ | /|
- | \ | ___________/ |
- | \ | / DHCPACK |
- | \ _______ |/ |
- | DHCPACK\ | |
- | Initialization |
- | complete |
- | \| |
- | | |
- | (Subsequent |
- | DHCPACKS |
- | ignored) |
- | | |
- | | |
- v v v
-
- Figure 4: Timeline diagram of messages exchanged between DHCP
- client and servers when reusing a previously allocated
- network address
-
-
-
-Droms Standards Track [Page 18]
-\f
-RFC 2131 Dynamic Host Configuration Protocol March 1997
-
-
- If the client's request is invalid (e.g., the client has moved
- to a new subnet), servers SHOULD respond with a DHCPNAK message to
- the client. Servers SHOULD NOT respond if their information is not
- guaranteed to be accurate. For example, a server that identifies a
- request for an expired binding that is owned by another server SHOULD
- NOT respond with a DHCPNAK unless the servers are using an explicit
- mechanism to maintain coherency among the servers.
-
- If 'giaddr' is 0x0 in the DHCPREQUEST message, the client is on
- the same subnet as the server. The server MUST
- broadcast the DHCPNAK message to the 0xffffffff broadcast address
- because the client may not have a correct network address or subnet
- mask, and the client may not be answering ARP requests.
- Otherwise, the server MUST send the DHCPNAK message to the IP
- address of the BOOTP relay agent, as recorded in 'giaddr'. The
- relay agent will, in turn, forward the message directly to the
- client's hardware address, so that the DHCPNAK can be delivered even
- if the client has moved to a new network.
-
- 3. The client receives the DHCPACK message with configuration
- parameters. The client performs a final check on the parameters
- (as in section 3.1), and notes the duration of the lease specified
- in the DHCPACK message. The specific lease is implicitly identified
- by the 'client identifier' or 'chaddr' and the network address. At
- this point, the client is configured.
-
- If the client detects that the IP address in the DHCPACK message
- is already in use, the client MUST send a DHCPDECLINE message to the
- server and restarts the configuration process by requesting a
- new network address. This action corresponds to the client
- moving to the INIT state in the DHCP state diagram, which is
- described in section 4.4.
-
- If the client receives a DHCPNAK message, it cannot reuse its
- remembered network address. It must instead request a new
- address by restarting the configuration process, this time
- using the (non-abbreviated) procedure described in section
- 3.1. This action also corresponds to the client moving to
- the INIT state in the DHCP state diagram.
-
- The client times out and retransmits the DHCPREQUEST message if
- the client receives neither a DHCPACK nor a DHCPNAK message. The
- client retransmits the DHCPREQUEST according to the retransmission
- algorithm in section 4.1. The client should choose to retransmit
- the DHCPREQUEST enough times to give adequate probability of
- contacting the server without causing the client (and the user of
- that client) to wait overly long before giving up; e.g., a client
- retransmitting as described in section 4.1 might retransmit the
-
-
-
-Droms Standards Track [Page 19]
-\f
-RFC 2131 Dynamic Host Configuration Protocol March 1997
-
-
- DHCPREQUEST message four times, for a total delay of 60 seconds,
- before restarting the initialization procedure. If the client
- receives neither a DHCPACK or a DHCPNAK message after employing
- the retransmission algorithm, the client MAY choose to use the
- previously allocated network address and configuration parameters
- for the remainder of the unexpired lease. This corresponds to
- moving to BOUND state in the client state transition diagram shown
- in figure 5.
-
- 4. The client may choose to relinquish its lease on a network
- address by sending a DHCPRELEASE message to the server. The
- client identifies the lease to be released with its
- 'client identifier', or 'chaddr' and network address in the
- DHCPRELEASE message.
-
- Note that in this case, where the client retains its network
- address locally, the client will not normally relinquish its
- lease during a graceful shutdown. Only in the case where the
- client explicitly needs to relinquish its lease, e.g., the client
- is about to be moved to a different subnet, will the client send
- a DHCPRELEASE message.
-
-3.3 Interpretation and representation of time values
-
- A client acquires a lease for a network address for a fixed period of
- time (which may be infinite). Throughout the protocol, times are to
- be represented in units of seconds. The time value of 0xffffffff is
- reserved to represent "infinity".
-
- As clients and servers may not have synchronized clocks, times are
- represented in DHCP messages as relative times, to be interpreted
- with respect to the client's local clock. Representing relative
- times in units of seconds in an unsigned 32 bit word gives a range of
- relative times from 0 to approximately 100 years, which is sufficient
- for the relative times to be measured using DHCP.
-
- The algorithm for lease duration interpretation given in the previous
- paragraph assumes that client and server clocks are stable relative
- to each other. If there is drift between the two clocks, the server
- may consider the lease expired before the client does. To
- compensate, the server may return a shorter lease duration to the
- client than the server commits to its local database of client
- information.
-
-3.4 Obtaining parameters with externally configured network address
-
- If a client has obtained a network address through some other means
- (e.g., manual configuration), it may use a DHCPINFORM request message
-
-
-
-Droms Standards Track [Page 20]
-\f
-RFC 2131 Dynamic Host Configuration Protocol March 1997
-
-
- to obtain other local configuration parameters. Servers receiving a
- DHCPINFORM message construct a DHCPACK message with any local
- configuration parameters appropriate for the client without:
- allocating a new address, checking for an existing binding, filling
- in 'yiaddr' or including lease time parameters. The servers SHOULD
- unicast the DHCPACK reply to the address given in the 'ciaddr' field
- of the DHCPINFORM message.
-
- The server SHOULD check the network address in a DHCPINFORM message
- for consistency, but MUST NOT check for an existing lease. The
- server forms a DHCPACK message containing the configuration
- parameters for the requesting client and sends the DHCPACK message
- directly to the client.
-
-3.5 Client parameters in DHCP
-
- Not all clients require initialization of all parameters listed in
- Appendix A. Two techniques are used to reduce the number of
- parameters transmitted from the server to the client. First, most of
- the parameters have defaults defined in the Host Requirements RFCs;
- if the client receives no parameters from the server that override
- the defaults, a client uses those default values. Second, in its
- initial DHCPDISCOVER or DHCPREQUEST message, a client may provide the
- server with a list of specific parameters the client is interested
- in. If the client includes a list of parameters in a DHCPDISCOVER
- message, it MUST include that list in any subsequent DHCPREQUEST
- messages.
-
- The client SHOULD include the 'maximum DHCP message size' option to
- let the server know how large the server may make its DHCP messages.
- The parameters returned to a client may still exceed the space
- allocated to options in a DHCP message. In this case, two additional
- options flags (which must appear in the 'options' field of the
- message) indicate that the 'file' and 'sname' fields are to be used
- for options.
-
- The client can inform the server which configuration parameters the
- client is interested in by including the 'parameter request list'
- option. The data portion of this option explicitly lists the options
- requested by tag number.
-
- In addition, the client may suggest values for the network address
- and lease time in the DHCPDISCOVER message. The client may include
- the 'requested IP address' option to suggest that a particular IP
- address be assigned, and may include the 'IP address lease time'
- option to suggest the lease time it would like. Other options
- representing "hints" at configuration parameters are allowed in a
- DHCPDISCOVER or DHCPREQUEST message. However, additional options may
-
-
-
-Droms Standards Track [Page 21]
-\f
-RFC 2131 Dynamic Host Configuration Protocol March 1997
-
-
- be ignored by servers, and multiple servers may, therefore, not
- return identical values for some options. The 'requested IP address'
- option is to be filled in only in a DHCPREQUEST message when the
- client is verifying network parameters obtained previously. The
- client fills in the 'ciaddr' field only when correctly configured
- with an IP address in BOUND, RENEWING or REBINDING state.
-
- If a server receives a DHCPREQUEST message with an invalid 'requested
- IP address', the server SHOULD respond to the client with a DHCPNAK
- message and may choose to report the problem to the system
- administrator. The server may include an error message in the
- 'message' option.
-
-3.6 Use of DHCP in clients with multiple interfaces
-
- A client with multiple network interfaces must use DHCP through each
- interface independently to obtain configuration information
- parameters for those separate interfaces.
-
-3.7 When clients should use DHCP
-
- A client SHOULD use DHCP to reacquire or verify its IP address and
- network parameters whenever the local network parameters may have
- changed; e.g., at system boot time or after a disconnection from the
- local network, as the local network configuration may change without
- the client's or user's knowledge.
-
- If a client has knowledge of a previous network address and is unable
- to contact a local DHCP server, the client may continue to use the
- previous network address until the lease for that address expires.
- If the lease expires before the client can contact a DHCP server, the
- client must immediately discontinue use of the previous network
- address and may inform local users of the problem.
-
-4. Specification of the DHCP client-server protocol
-
- In this section, we assume that a DHCP server has a block of network
- addresses from which it can satisfy requests for new addresses. Each
- server also maintains a database of allocated addresses and leases in
- local permanent storage.
-
-4.1 Constructing and sending DHCP messages
-
- DHCP clients and servers both construct DHCP messages by filling in
- fields in the fixed format section of the message and appending
- tagged data items in the variable length option area. The options
- area includes first a four-octet 'magic cookie' (which was described
- in section 3), followed by the options. The last option must always
-
-
-
-Droms Standards Track [Page 22]
-\f
-RFC 2131 Dynamic Host Configuration Protocol March 1997
-
-
- be the 'end' option.
-
- DHCP uses UDP as its transport protocol. DHCP messages from a client
- to a server are sent to the 'DHCP server' port (67), and DHCP
- messages from a server to a client are sent to the 'DHCP client' port
- (68). A server with multiple network address (e.g., a multi-homed
- host) MAY use any of its network addresses in outgoing DHCP messages.
-
- The 'server identifier' field is used both to identify a DHCP server
- in a DHCP message and as a destination address from clients to
- servers. A server with multiple network addresses MUST be prepared
- to to accept any of its network addresses as identifying that server
- in a DHCP message. To accommodate potentially incomplete network
- connectivity, a server MUST choose an address as a 'server
- identifier' that, to the best of the server's knowledge, is reachable
- from the client. For example, if the DHCP server and the DHCP client
- are connected to the same subnet (i.e., the 'giaddr' field in the
- message from the client is zero), the server SHOULD select the IP
- address the server is using for communication on that subnet as the
- 'server identifier'. If the server is using multiple IP addresses on
- that subnet, any such address may be used. If the server has
- received a message through a DHCP relay agent, the server SHOULD
- choose an address from the interface on which the message was
- recieved as the 'server identifier' (unless the server has other,
- better information on which to make its choice). DHCP clients MUST
- use the IP address provided in the 'server identifier' option for any
- unicast requests to the DHCP server.
-
- DHCP messages broadcast by a client prior to that client obtaining
- its IP address must have the source address field in the IP header
- set to 0.
-
- If the 'giaddr' field in a DHCP message from a client is non-zero,
- the server sends any return messages to the 'DHCP server' port on the
- BOOTP relay agent whose address appears in 'giaddr'. If the 'giaddr'
- field is zero and the 'ciaddr' field is nonzero, then the server
- unicasts DHCPOFFER and DHCPACK messages to the address in 'ciaddr'.
- If 'giaddr' is zero and 'ciaddr' is zero, and the broadcast bit is
- set, then the server broadcasts DHCPOFFER and DHCPACK messages to
- 0xffffffff. If the broadcast bit is not set and 'giaddr' is zero and
- 'ciaddr' is zero, then the server unicasts DHCPOFFER and DHCPACK
- messages to the client's hardware address and 'yiaddr' address. In
- all cases, when 'giaddr' is zero, the server broadcasts any DHCPNAK
- messages to 0xffffffff.
-
- If the options in a DHCP message extend into the 'sname' and 'file'
- fields, the 'option overload' option MUST appear in the 'options'
- field, with value 1, 2 or 3, as specified in RFC 1533. If the
-
-
-
-Droms Standards Track [Page 23]
-\f
-RFC 2131 Dynamic Host Configuration Protocol March 1997
-
-
- 'option overload' option is present in the 'options' field, the
- options in the 'options' field MUST be terminated by an 'end' option,
- and MAY contain one or more 'pad' options to fill the options field.
- The options in the 'sname' and 'file' fields (if in use as indicated
- by the 'options overload' option) MUST begin with the first octet of
- the field, MUST be terminated by an 'end' option, and MUST be
- followed by 'pad' options to fill the remainder of the field. Any
- individual option in the 'options', 'sname' and 'file' fields MUST be
- entirely contained in that field. The options in the 'options' field
- MUST be interpreted first, so that any 'option overload' options may
- be interpreted. The 'file' field MUST be interpreted next (if the
- 'option overload' option indicates that the 'file' field contains
- DHCP options), followed by the 'sname' field.
-
- The values to be passed in an 'option' tag may be too long to fit in
- the 255 octets available to a single option (e.g., a list of routers
- in a 'router' option [21]). Options may appear only once, unless
- otherwise specified in the options document. The client concatenates
- the values of multiple instances of the same option into a single
- parameter list for configuration.
-
- DHCP clients are responsible for all message retransmission. The
- client MUST adopt a retransmission strategy that incorporates a
- randomized exponential backoff algorithm to determine the delay
- between retransmissions. The delay between retransmissions SHOULD be
- chosen to allow sufficient time for replies from the server to be
- delivered based on the characteristics of the internetwork between
- the client and the server. For example, in a 10Mb/sec Ethernet
- internetwork, the delay before the first retransmission SHOULD be 4
- seconds randomized by the value of a uniform random number chosen
- from the range -1 to +1. Clients with clocks that provide resolution
- granularity of less than one second may choose a non-integer
- randomization value. The delay before the next retransmission SHOULD
- be 8 seconds randomized by the value of a uniform number chosen from
- the range -1 to +1. The retransmission delay SHOULD be doubled with
- subsequent retransmissions up to a maximum of 64 seconds. The client
- MAY provide an indication of retransmission attempts to the user as
- an indication of the progress of the configuration process.
-
- The 'xid' field is used by the client to match incoming DHCP messages
- with pending requests. A DHCP client MUST choose 'xid's in such a
- way as to minimize the chance of using an 'xid' identical to one used
- by another client. For example, a client may choose a different,
- random initial 'xid' each time the client is rebooted, and
- subsequently use sequential 'xid's until the next reboot. Selecting
- a new 'xid' for each retransmission is an implementation decision. A
- client may choose to reuse the same 'xid' or select a new 'xid' for
- each retransmitted message.
-
-
-
-Droms Standards Track [Page 24]
-\f
-RFC 2131 Dynamic Host Configuration Protocol March 1997
-
-
- Normally, DHCP servers and BOOTP relay agents attempt to deliver
- DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using
- uicast delivery. The IP destination address (in the IP header) is
- set to the DHCP 'yiaddr' address and the link-layer destination
- address is set to the DHCP 'chaddr' address. Unfortunately, some
- client implementations are unable to receive such unicast IP
- datagrams until the implementation has been configured with a valid
- IP address (leading to a deadlock in which the client's IP address
- cannot be delivered until the client has been configured with an IP
- address).
-
- A client that cannot receive unicast IP datagrams until its protocol
- software has been configured with an IP address SHOULD set the
- BROADCAST bit in the 'flags' field to 1 in any DHCPDISCOVER or
- DHCPREQUEST messages that client sends. The BROADCAST bit will
- provide a hint to the DHCP server and BOOTP relay agent to broadcast
- any messages to the client on the client's subnet. A client that can
- receive unicast IP datagrams before its protocol software has been
- configured SHOULD clear the BROADCAST bit to 0. The BOOTP
- clarifications document discusses the ramifications of the use of the
- BROADCAST bit [21].
-
- A server or relay agent sending or relaying a DHCP message directly
- to a DHCP client (i.e., not to a relay agent specified in the
- 'giaddr' field) SHOULD examine the BROADCAST bit in the 'flags'
- field. If this bit is set to 1, the DHCP message SHOULD be sent as
- an IP broadcast using an IP broadcast address (preferably 0xffffffff)
- as the IP destination address and the link-layer broadcast address as
- the link-layer destination address. If the BROADCAST bit is cleared
- to 0, the message SHOULD be sent as an IP unicast to the IP address
- specified in the 'yiaddr' field and the link-layer address specified
- in the 'chaddr' field. If unicasting is not possible, the message
- MAY be sent as an IP broadcast using an IP broadcast address
- (preferably 0xffffffff) as the IP destination address and the link-
- layer broadcast address as the link-layer destination address.
-
-4.2 DHCP server administrative controls
-
- DHCP servers are not required to respond to every DHCPDISCOVER and
- DHCPREQUEST message they receive. For example, a network
- administrator, to retain stringent control over the clients attached
- to the network, may choose to configure DHCP servers to respond only
- to clients that have been previously registered through some external
- mechanism. The DHCP specification describes only the interactions
- between clients and servers when the clients and servers choose to
- interact; it is beyond the scope of the DHCP specification to
- describe all of the administrative controls that system
- administrators might want to use. Specific DHCP server
-
-
-
-Droms Standards Track [Page 25]
-\f
-RFC 2131 Dynamic Host Configuration Protocol March 1997
-
-
- implementations may incorporate any controls or policies desired by a
- network administrator.
-
- In some environments, a DHCP server will have to consider the values
- of the vendor class options included in DHCPDISCOVER or DHCPREQUEST
- messages when determining the correct parameters for a particular
- client.
-
- A DHCP server needs to use some unique identifier to associate a
- client with its lease. The client MAY choose to explicitly provide
- the identifier through the 'client identifier' option. If the client
- supplies a 'client identifier', the client MUST use the same 'client
- identifier' in all subsequent messages, and the server MUST use that
- identifier to identify the client. If the client does not provide a
- 'client identifier' option, the server MUST use the contents of the
- 'chaddr' field to identify the client. It is crucial for a DHCP
- client to use an identifier unique within the subnet to which the
- client is attached in the 'client identifier' option. Use of
- 'chaddr' as the client's unique identifier may cause unexpected
- results, as that identifier may be associated with a hardware
- interface that could be moved to a new client. Some sites may choose
- to use a manufacturer's serial number as the 'client identifier', to
- avoid unexpected changes in a clients network address due to transfer
- of hardware interfaces among computers. Sites may also choose to use
- a DNS name as the 'client identifier', causing address leases to be
- associated with the DNS name rather than a specific hardware box.
-
- DHCP clients are free to use any strategy in selecting a DHCP server
- among those from which the client receives a DHCPOFFER message. The
- client implementation of DHCP SHOULD provide a mechanism for the user
- to select directly the 'vendor class identifier' values.
-
-4.3 DHCP server behavior
-
- A DHCP server processes incoming DHCP messages from a client based on
- the current state of the binding for that client. A DHCP server can
- receive the following messages from a client:
-
- o DHCPDISCOVER
-
- o DHCPREQUEST
-
- o DHCPDECLINE
-
- o DHCPRELEASE
-
- o DHCPINFORM
-
-
-
-
-Droms Standards Track [Page 26]
-\f
-RFC 2131 Dynamic Host Configuration Protocol March 1997
-
-
- Table 3 gives the use of the fields and options in a DHCP message by
- a server. The remainder of this section describes the action of the
- DHCP server for each possible incoming message.
-
-4.3.1 DHCPDISCOVER message
-
- When a server receives a DHCPDISCOVER message from a client, the
- server chooses a network address for the requesting client. If no
- address is available, the server may choose to report the problem to
- the system administrator. If an address is available, the new address
- SHOULD be chosen as follows:
-
- o The client's current address as recorded in the client's current
- binding, ELSE
-
- o The client's previous address as recorded in the client's (now
- expired or released) binding, if that address is in the server's
- pool of available addresses and not already allocated, ELSE
-
- o The address requested in the 'Requested IP Address' option, if that
- address is valid and not already allocated, ELSE
-
- o A new address allocated from the server's pool of available
- addresses; the address is selected based on the subnet from which
- the message was received (if 'giaddr' is 0) or on the address of
- the relay agent that forwarded the message ('giaddr' when not 0).
-
- As described in section 4.2, a server MAY, for administrative
- reasons, assign an address other than the one requested, or may
- refuse to allocate an address to a particular client even though free
- addresses are available.
-
- Note that, in some network architectures (e.g., internets with more
- than one IP subnet assigned to a physical network segment), it may be
- the case that the DHCP client should be assigned an address from a
- different subnet than the address recorded in 'giaddr'. Thus, DHCP
- does not require that the client be assigned as address from the
- subnet in 'giaddr'. A server is free to choose some other subnet,
- and it is beyond the scope of the DHCP specification to describe ways
- in which the assigned IP address might be chosen.
-
- While not required for correct operation of DHCP, the server SHOULD
- NOT reuse the selected network address before the client responds to
- the server's DHCPOFFER message. The server may choose to record the
- address as offered to the client.
-
- The server must also choose an expiration time for the lease, as
- follows:
-
-
-
-Droms Standards Track [Page 27]
-\f
-RFC 2131 Dynamic Host Configuration Protocol March 1997
-
-
- o IF the client has not requested a specific lease in the
- DHCPDISCOVER message and the client already has an assigned network
- address, the server returns the lease expiration time previously
- assigned to that address (note that the client must explicitly
- request a specific lease to extend the expiration time on a
- previously assigned address), ELSE
-
- o IF the client has not requested a specific lease in the
- DHCPDISCOVER message and the client does not have an assigned
- network address, the server assigns a locally configured default
- lease time, ELSE
-
- o IF the client has requested a specific lease in the DHCPDISCOVER
- message (regardless of whether the client has an assigned network
- address), the server may choose either to return the requested
- lease (if the lease is acceptable to local policy) or select
- another lease.
-
-Field DHCPOFFER DHCPACK DHCPNAK
------ --------- ------- -------
-'op' BOOTREPLY BOOTREPLY BOOTREPLY
-'htype' (From "Assigned Numbers" RFC)
-'hlen' (Hardware address length in octets)
-'hops' 0 0 0
-'xid' 'xid' from client 'xid' from client 'xid' from client
- DHCPDISCOVER DHCPREQUEST DHCPREQUEST
- message message message
-'secs' 0 0 0
-'ciaddr' 0 'ciaddr' from 0
- DHCPREQUEST or 0
-'yiaddr' IP address offered IP address 0
- to client assigned to client
-'siaddr' IP address of next IP address of next 0
- bootstrap server bootstrap server
-'flags' 'flags' from 'flags' from 'flags' from
- client DHCPDISCOVER client DHCPREQUEST client DHCPREQUEST
- message message message
-'giaddr' 'giaddr' from 'giaddr' from 'giaddr' from
- client DHCPDISCOVER client DHCPREQUEST client DHCPREQUEST
- message message message
-'chaddr' 'chaddr' from 'chaddr' from 'chaddr' from
- client DHCPDISCOVER client DHCPREQUEST client DHCPREQUEST
- message message message
-'sname' Server host name Server host name (unused)
- or options or options
-'file' Client boot file Client boot file (unused)
- name or options name or options
-'options' options options
-
-
-
-Droms Standards Track [Page 28]
-\f
-RFC 2131 Dynamic Host Configuration Protocol March 1997
-
-
-Option DHCPOFFER DHCPACK DHCPNAK
------- --------- ------- -------
-Requested IP address MUST NOT MUST NOT MUST NOT
-IP address lease time MUST MUST (DHCPREQUEST) MUST NOT
- MUST NOT (DHCPINFORM)
-Use 'file'/'sname' fields MAY MAY MUST NOT
-DHCP message type DHCPOFFER DHCPACK DHCPNAK
-Parameter request list MUST NOT MUST NOT MUST NOT
-Message SHOULD SHOULD SHOULD
-Client identifier MUST NOT MUST NOT MAY
-Vendor class identifier MAY MAY MAY
-Server identifier MUST MUST MUST
-Maximum message size MUST NOT MUST NOT MUST NOT
-All others MAY MAY MUST NOT
-
- Table 3: Fields and options used by DHCP servers
-
- Once the network address and lease have been determined, the server
- constructs a DHCPOFFER message with the offered configuration
- parameters. It is important for all DHCP servers to return the same
- parameters (with the possible exception of a newly allocated network
- address) to ensure predictable client behavior regardless of which
- server the client selects. The configuration parameters MUST be
- selected by applying the following rules in the order given below.
- The network administrator is responsible for configuring multiple
- DHCP servers to ensure uniform responses from those servers. The
- server MUST return to the client:
-
- o The client's network address, as determined by the rules given
- earlier in this section,
-
- o The expiration time for the client's lease, as determined by the
- rules given earlier in this section,
-
- o Parameters requested by the client, according to the following
- rules:
-
- -- IF the server has been explicitly configured with a default
- value for the parameter, the server MUST include that value
- in an appropriate option in the 'option' field, ELSE
-
- -- IF the server recognizes the parameter as a parameter
- defined in the Host Requirements Document, the server MUST
- include the default value for that parameter as given in the
- Host Requirements Document in an appropriate option in the
- 'option' field, ELSE
-
- -- The server MUST NOT return a value for that parameter,
-
-
-
-Droms Standards Track [Page 29]
-\f
-RFC 2131 Dynamic Host Configuration Protocol March 1997
-
-
- The server MUST supply as many of the requested parameters as
- possible and MUST omit any parameters it cannot provide. The
- server MUST include each requested parameter only once unless
- explicitly allowed in the DHCP Options and BOOTP Vendor
- Extensions document.
-
- o Any parameters from the existing binding that differ from the Host
- Requirements Document defaults,
-
- o Any parameters specific to this client (as identified by
- the contents of 'chaddr' or 'client identifier' in the DHCPDISCOVER
- or DHCPREQUEST message), e.g., as configured by the network
- administrator,
-
- o Any parameters specific to this client's class (as identified
- by the contents of the 'vendor class identifier'
- option in the DHCPDISCOVER or DHCPREQUEST message),
- e.g., as configured by the network administrator; the parameters
- MUST be identified by an exact match between the client's vendor
- class identifiers and the client's classes identified in the
- server,
-
- o Parameters with non-default values on the client's subnet.
-
- The server MAY choose to return the 'vendor class identifier' used to
- determine the parameters in the DHCPOFFER message to assist the
- client in selecting which DHCPOFFER to accept. The server inserts
- the 'xid' field from the DHCPDISCOVER message into the 'xid' field of
- the DHCPOFFER message and sends the DHCPOFFER message to the
- requesting client.
-
-4.3.2 DHCPREQUEST message
-
- A DHCPREQUEST message may come from a client responding to a
- DHCPOFFER message from a server, from a client verifying a previously
- allocated IP address or from a client extending the lease on a
- network address. If the DHCPREQUEST message contains a 'server
- identifier' option, the message is in response to a DHCPOFFER
- message. Otherwise, the message is a request to verify or extend an
- existing lease. If the client uses a 'client identifier' in a
- DHCPREQUEST message, it MUST use that same 'client identifier' in all
- subsequent messages. If the client included a list of requested
- parameters in a DHCPDISCOVER message, it MUST include that list in
- all subsequent messages.
-
-
-
-
-
-
-
-Droms Standards Track [Page 30]
-\f
-RFC 2131 Dynamic Host Configuration Protocol March 1997
-
-
- Any configuration parameters in the DHCPACK message SHOULD NOT
- conflict with those in the earlier DHCPOFFER message to which the
- client is responding. The client SHOULD use the parameters in the
- DHCPACK message for configuration.
-
- Clients send DHCPREQUEST messages as follows:
-
- o DHCPREQUEST generated during SELECTING state:
-
- Client inserts the address of the selected server in 'server
- identifier', 'ciaddr' MUST be zero, 'requested IP address' MUST be
- filled in with the yiaddr value from the chosen DHCPOFFER.
-
- Note that the client may choose to collect several DHCPOFFER
- messages and select the "best" offer. The client indicates its
- selection by identifying the offering server in the DHCPREQUEST
- message. If the client receives no acceptable offers, the client
- may choose to try another DHCPDISCOVER message. Therefore, the
- servers may not receive a specific DHCPREQUEST from which they can
- decide whether or not the client has accepted the offer. Because
- the servers have not committed any network address assignments on
- the basis of a DHCPOFFER, servers are free to reuse offered
- network addresses in response to subsequent requests. As an
- implementation detail, servers SHOULD NOT reuse offered addresses
- and may use an implementation-specific timeout mechanism to decide
- when to reuse an offered address.
-
- o DHCPREQUEST generated during INIT-REBOOT state:
-
- 'server identifier' MUST NOT be filled in, 'requested IP address'
- option MUST be filled in with client's notion of its previously
- assigned address. 'ciaddr' MUST be zero. The client is seeking to
- verify a previously allocated, cached configuration. Server SHOULD
- send a DHCPNAK message to the client if the 'requested IP address'
- is incorrect, or is on the wrong network.
-
- Determining whether a client in the INIT-REBOOT state is on the
- correct network is done by examining the contents of 'giaddr', the
- 'requested IP address' option, and a database lookup. If the DHCP
- server detects that the client is on the wrong net (i.e., the
- result of applying the local subnet mask or remote subnet mask (if
- 'giaddr' is not zero) to 'requested IP address' option value
- doesn't match reality), then the server SHOULD send a DHCPNAK
- message to the client.
-
-
-
-
-
-
-
-Droms Standards Track [Page 31]
-\f
-RFC 2131 Dynamic Host Configuration Protocol March 1997
-
-
- If the network is correct, then the DHCP server should check if
- the client's notion of its IP address is correct. If not, then the
- server SHOULD send a DHCPNAK message to the client. If the DHCP
- server has no record of this client, then it MUST remain silent,
- and MAY output a warning to the network administrator. This
- behavior is necessary for peaceful coexistence of non-
- communicating DHCP servers on the same wire.
-
- If 'giaddr' is 0x0 in the DHCPREQUEST message, the client is on
- the same subnet as the server. The server MUST broadcast the
- DHCPNAK message to the 0xffffffff broadcast address because the
- client may not have a correct network address or subnet mask, and
- the client may not be answering ARP requests.
-
- If 'giaddr' is set in the DHCPREQUEST message, the client is on a
- different subnet. The server MUST set the broadcast bit in the
- DHCPNAK, so that the relay agent will broadcast the DHCPNAK to the
- client, because the client may not have a correct network address
- or subnet mask, and the client may not be answering ARP requests.
-
- o DHCPREQUEST generated during RENEWING state:
-
- 'server identifier' MUST NOT be filled in, 'requested IP address'
- option MUST NOT be filled in, 'ciaddr' MUST be filled in with
- client's IP address. In this situation, the client is completely
- configured, and is trying to extend its lease. This message will
- be unicast, so no relay agents will be involved in its
- transmission. Because 'giaddr' is therefore not filled in, the
- DHCP server will trust the value in 'ciaddr', and use it when
- replying to the client.
-
- A client MAY choose to renew or extend its lease prior to T1. The
- server may choose not to extend the lease (as a policy decision by
- the network administrator), but should return a DHCPACK message
- regardless.
-
- o DHCPREQUEST generated during REBINDING state:
-
- 'server identifier' MUST NOT be filled in, 'requested IP address'
- option MUST NOT be filled in, 'ciaddr' MUST be filled in with
- client's IP address. In this situation, the client is completely
- configured, and is trying to extend its lease. This message MUST
- be broadcast to the 0xffffffff IP broadcast address. The DHCP
- server SHOULD check 'ciaddr' for correctness before replying to
- the DHCPREQUEST.
-
-
-
-
-
-
-Droms Standards Track [Page 32]
-\f
-RFC 2131 Dynamic Host Configuration Protocol March 1997
-
-
- The DHCPREQUEST from a REBINDING client is intended to accommodate
- sites that have multiple DHCP servers and a mechanism for
- maintaining consistency among leases managed by multiple servers.
- A DHCP server MAY extend a client's lease only if it has local
- administrative authority to do so.
-
-4.3.3 DHCPDECLINE message
-
- If the server receives a DHCPDECLINE message, the client has
- discovered through some other means that the suggested network
- address is already in use. The server MUST mark the network address
- as not available and SHOULD notify the local system administrator of
- a possible configuration problem.
-
-4.3.4 DHCPRELEASE message
-
- Upon receipt of a DHCPRELEASE message, the server marks the network
- address as not allocated. The server SHOULD retain a record of the
- client's initialization parameters for possible reuse in response to
- subsequent requests from the client.
-
-4.3.5 DHCPINFORM message
-
- The server responds to a DHCPINFORM message by sending a DHCPACK
- message directly to the address given in the 'ciaddr' field of the
- DHCPINFORM message. The server MUST NOT send a lease expiration time
- to the client and SHOULD NOT fill in 'yiaddr'. The server includes
- other parameters in the DHCPACK message as defined in section 4.3.1.
-
-4.3.6 Client messages
-
- Table 4 details the differences between messages from clients in
- various states.
-
- ---------------------------------------------------------------------
- | |INIT-REBOOT |SELECTING |RENEWING |REBINDING |
- ---------------------------------------------------------------------
- |broad/unicast |broadcast |broadcast |unicast |broadcast |
- |server-ip |MUST NOT |MUST |MUST NOT |MUST NOT |
- |requested-ip |MUST |MUST |MUST NOT |MUST NOT |
- |ciaddr |zero |zero |IP address |IP address|
- ---------------------------------------------------------------------
-
- Table 4: Client messages from different states
-
-
-
-
-
-
-
-Droms Standards Track [Page 33]
-\f
-RFC 2131 Dynamic Host Configuration Protocol March 1997
-
-
-4.4 DHCP client behavior
-
- Figure 5 gives a state-transition diagram for a DHCP client. A
- client can receive the following messages from a server:
-
- o DHCPOFFER
-
- o DHCPACK
-
- o DHCPNAK
-
- The DHCPINFORM message is not shown in figure 5. A client simply
- sends the DHCPINFORM and waits for DHCPACK messages. Once the client
- has selected its parameters, it has completed the configuration
- process.
-
- Table 5 gives the use of the fields and options in a DHCP message by
- a client. The remainder of this section describes the action of the
- DHCP client for each possible incoming message. The description in
- the following section corresponds to the full configuration procedure
- previously described in section 3.1, and the text in the subsequent
- section corresponds to the abbreviated configuration procedure
- described in section 3.2.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Droms Standards Track [Page 34]
-\f
-RFC 2131 Dynamic Host Configuration Protocol March 1997
-
-
- -------- -------
-| | +-------------------------->| |<-------------------+
-| INIT- | | +-------------------->| INIT | |
-| REBOOT |DHCPNAK/ +---------->| |<---+ |
-| |Restart| | ------- | |
- -------- | DHCPNAK/ | | |
- | Discard offer | -/Send DHCPDISCOVER |
--/Send DHCPREQUEST | | |
- | | | DHCPACK v | |
- ----------- | (not accept.)/ ----------- | |
-| | | Send DHCPDECLINE | | |
-| REBOOTING | | | | SELECTING |<----+ |
-| | | / | | |DHCPOFFER/ |
- ----------- | / ----------- | |Collect |
- | | / | | | replies |
-DHCPACK/ | / +----------------+ +-------+ |
-Record lease, set| | v Select offer/ |
-timers T1, T2 ------------ send DHCPREQUEST | |
- | +----->| | DHCPNAK, Lease expired/ |
- | | | REQUESTING | Halt network |
- DHCPOFFER/ | | | |
- Discard ------------ | |
- | | | | ----------- |
- | +--------+ DHCPACK/ | | |
- | Record lease, set -----| REBINDING | |
- | timers T1, T2 / | | |
- | | DHCPACK/ ----------- |
- | v Record lease, set ^ |
- +----------------> ------- /timers T1,T2 | |
- +----->| |<---+ | |
- | | BOUND |<---+ | |
- DHCPOFFER, DHCPACK, | | | T2 expires/ DHCPNAK/
- DHCPNAK/Discard ------- | Broadcast Halt network
- | | | | DHCPREQUEST |
- +-------+ | DHCPACK/ | |
- T1 expires/ Record lease, set | |
- Send DHCPREQUEST timers T1, T2 | |
- to leasing server | | |
- | ---------- | |
- | | |------------+ |
- +->| RENEWING | |
- | |----------------------------+
- ----------
- Figure 5: State-transition diagram for DHCP clients
-
-
-
-
-
-
-
-Droms Standards Track [Page 35]
-\f
-RFC 2131 Dynamic Host Configuration Protocol March 1997
-
-
-4.4.1 Initialization and allocation of network address
-
- The client begins in INIT state and forms a DHCPDISCOVER message.
- The client SHOULD wait a random time between one and ten seconds to
- desynchronize the use of DHCP at startup. The client sets 'ciaddr'
- to 0x00000000. The client MAY request specific parameters by
- including the 'parameter request list' option. The client MAY
- suggest a network address and/or lease time by including the
- 'requested IP address' and 'IP address lease time' options. The
- client MUST include its hardware address in the 'chaddr' field, if
- necessary for delivery of DHCP reply messages. The client MAY
- include a different unique identifier in the 'client identifier'
- option, as discussed in section 4.2. If the client included a list
- of requested parameters in a DHCPDISCOVER message, it MUST include
- that list in all subsequent messages.
-
- The client generates and records a random transaction identifier and
- inserts that identifier into the 'xid' field. The client records its
- own local time for later use in computing the lease expiration. The
- client then broadcasts the DHCPDISCOVER on the local hardware
- broadcast address to the 0xffffffff IP broadcast address and 'DHCP
- server' UDP port.
-
- If the 'xid' of an arriving DHCPOFFER message does not match the
- 'xid' of the most recent DHCPDISCOVER message, the DHCPOFFER message
- must be silently discarded. Any arriving DHCPACK messages must be
- silently discarded.
-
- The client collects DHCPOFFER messages over a period of time, selects
- one DHCPOFFER message from the (possibly many) incoming DHCPOFFER
- messages (e.g., the first DHCPOFFER message or the DHCPOFFER message
- from the previously used server) and extracts the server address from
- the 'server identifier' option in the DHCPOFFER message. The time
- over which the client collects messages and the mechanism used to
- select one DHCPOFFER are implementation dependent.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Droms Standards Track [Page 36]
-\f
-RFC 2131 Dynamic Host Configuration Protocol March 1997
-
-
-Field DHCPDISCOVER DHCPREQUEST DHCPDECLINE,
- DHCPINFORM DHCPRELEASE
------ ------------ ----------- -----------
-'op' BOOTREQUEST BOOTREQUEST BOOTREQUEST
-'htype' (From "Assigned Numbers" RFC)
-'hlen' (Hardware address length in octets)
-'hops' 0 0 0
-'xid' selected by client 'xid' from server selected by
- DHCPOFFER message client
-'secs' 0 or seconds since 0 or seconds since 0
- DHCP process started DHCP process started
-'flags' Set 'BROADCAST' Set 'BROADCAST' 0
- flag if client flag if client
- requires broadcast requires broadcast
- reply reply
-'ciaddr' 0 (DHCPDISCOVER) 0 or client's 0 (DHCPDECLINE)
- client's network address client's network
- network address (BOUND/RENEW/REBIND) address
- (DHCPINFORM) (DHCPRELEASE)
-'yiaddr' 0 0 0
-'siaddr' 0 0 0
-'giaddr' 0 0 0
-'chaddr' client's hardware client's hardware client's hardware
- address address address
-'sname' options, if options, if (unused)
- indicated in indicated in
- 'sname/file' 'sname/file'
- option; otherwise option; otherwise
- unused unused
-'file' options, if options, if (unused)
- indicated in indicated in
- 'sname/file' 'sname/file'
- option; otherwise option; otherwise
- unused unused
-'options' options options (unused)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Droms Standards Track [Page 37]
-\f
-RFC 2131 Dynamic Host Configuration Protocol March 1997
-
-
-Option DHCPDISCOVER DHCPREQUEST DHCPDECLINE,
- DHCPINFORM DHCPRELEASE
------- ------------ ----------- -----------
-Requested IP address MAY MUST (in MUST
- (DISCOVER) SELECTING or (DHCPDECLINE),
- MUST NOT INIT-REBOOT) MUST NOT
- (INFORM) MUST NOT (in (DHCPRELEASE)
- BOUND or
- RENEWING)
-IP address lease time MAY MAY MUST NOT
- (DISCOVER)
- MUST NOT
- (INFORM)
-Use 'file'/'sname' fields MAY MAY MAY
-DHCP message type DHCPDISCOVER/ DHCPREQUEST DHCPDECLINE/
- DHCPINFORM DHCPRELEASE
-Client identifier MAY MAY MAY
-Vendor class identifier MAY MAY MUST NOT
-Server identifier MUST NOT MUST (after MUST
- SELECTING)
- MUST NOT (after
- INIT-REBOOT,
- BOUND, RENEWING
- or REBINDING)
-Parameter request list MAY MAY MUST NOT
-Maximum message size MAY MAY MUST NOT
-Message SHOULD NOT SHOULD NOT SHOULD
-Site-specific MAY MAY MUST NOT
-All others MAY MAY MUST NOT
-
- Table 5: Fields and options used by DHCP clients
-
- If the parameters are acceptable, the client records the address of
- the server that supplied the parameters from the 'server identifier'
- field and sends that address in the 'server identifier' field of a
- DHCPREQUEST broadcast message. Once the DHCPACK message from the
- server arrives, the client is initialized and moves to BOUND state.
- The DHCPREQUEST message contains the same 'xid' as the DHCPOFFER
- message. The client records the lease expiration time as the sum of
- the time at which the original request was sent and the duration of
- the lease from the DHCPACK message. The client SHOULD perform a
- check on the suggested address to ensure that the address is not
- already in use. For example, if the client is on a network that
- supports ARP, the client may issue an ARP request for the suggested
- request. When broadcasting an ARP request for the suggested address,
- the client must fill in its own hardware address as the sender's
- hardware address, and 0 as the sender's IP address, to avoid
- confusing ARP caches in other hosts on the same subnet. If the
-
-
-
-Droms Standards Track [Page 38]
-\f
-RFC 2131 Dynamic Host Configuration Protocol March 1997
-
-
- network address appears to be in use, the client MUST send a
- DHCPDECLINE message to the server. The client SHOULD broadcast an ARP
- reply to announce the client's new IP address and clear any outdated
- ARP cache entries in hosts on the client's subnet.
-
-4.4.2 Initialization with known network address
-
- The client begins in INIT-REBOOT state and sends a DHCPREQUEST
- message. The client MUST insert its known network address as a
- 'requested IP address' option in the DHCPREQUEST message. The client
- may request specific configuration parameters by including the
- 'parameter request list' option. The client generates and records a
- random transaction identifier and inserts that identifier into the
- 'xid' field. The client records its own local time for later use in
- computing the lease expiration. The client MUST NOT include a
- 'server identifier' in the DHCPREQUEST message. The client then
- broadcasts the DHCPREQUEST on the local hardware broadcast address to
- the 'DHCP server' UDP port.
-
- Once a DHCPACK message with an 'xid' field matching that in the
- client's DHCPREQUEST message arrives from any server, the client is
- initialized and moves to BOUND state. The client records the lease
- expiration time as the sum of the time at which the DHCPREQUEST
- message was sent and the duration of the lease from the DHCPACK
- message.
-
-4.4.3 Initialization with an externally assigned network address
-
- The client sends a DHCPINFORM message. The client may request
- specific configuration parameters by including the 'parameter request
- list' option. The client generates and records a random transaction
- identifier and inserts that identifier into the 'xid' field. The
- client places its own network address in the 'ciaddr' field. The
- client SHOULD NOT request lease time parameters.
-
- The client then unicasts the DHCPINFORM to the DHCP server if it
- knows the server's address, otherwise it broadcasts the message to
- the limited (all 1s) broadcast address. DHCPINFORM messages MUST be
- directed to the 'DHCP server' UDP port.
-
- Once a DHCPACK message with an 'xid' field matching that in the
- client's DHCPINFORM message arrives from any server, the client is
- initialized.
-
- If the client does not receive a DHCPACK within a reasonable period
- of time (60 seconds or 4 tries if using timeout suggested in section
- 4.1), then it SHOULD display a message informing the user of the
- problem, and then SHOULD begin network processing using suitable
-
-
-
-Droms Standards Track [Page 39]
-\f
-RFC 2131 Dynamic Host Configuration Protocol March 1997
-
-
- defaults as per Appendix A.
-
-4.4.4 Use of broadcast and unicast
-
- The DHCP client broadcasts DHCPDISCOVER, DHCPREQUEST and DHCPINFORM
- messages, unless the client knows the address of a DHCP server. The
- client unicasts DHCPRELEASE messages to the server. Because the
- client is declining the use of the IP address supplied by the server,
- the client broadcasts DHCPDECLINE messages.
-
- When the DHCP client knows the address of a DHCP server, in either
- INIT or REBOOTING state, the client may use that address in the
- DHCPDISCOVER or DHCPREQUEST rather than the IP broadcast address.
- The client may also use unicast to send DHCPINFORM messages to a
- known DHCP server. If the client receives no response to DHCP
- messages sent to the IP address of a known DHCP server, the DHCP
- client reverts to using the IP broadcast address.
-
-4.4.5 Reacquisition and expiration
-
- The client maintains two times, T1 and T2, that specify the times at
- which the client tries to extend its lease on its network address.
- T1 is the time at which the client enters the RENEWING state and
- attempts to contact the server that originally issued the client's
- network address. T2 is the time at which the client enters the
- REBINDING state and attempts to contact any server. T1 MUST be
- earlier than T2, which, in turn, MUST be earlier than the time at
- which the client's lease will expire.
-
- To avoid the need for synchronized clocks, T1 and T2 are expressed in
- options as relative times [2].
-
- At time T1 the client moves to RENEWING state and sends (via unicast)
- a DHCPREQUEST message to the server to extend its lease. The client
- sets the 'ciaddr' field in the DHCPREQUEST to its current network
- address. The client records the local time at which the DHCPREQUEST
- message is sent for computation of the lease expiration time. The
- client MUST NOT include a 'server identifier' in the DHCPREQUEST
- message.
-
- Any DHCPACK messages that arrive with an 'xid' that does not match
- the 'xid' of the client's DHCPREQUEST message are silently discarded.
- When the client receives a DHCPACK from the server, the client
- computes the lease expiration time as the sum of the time at which
- the client sent the DHCPREQUEST message and the duration of the lease
- in the DHCPACK message. The client has successfully reacquired its
- network address, returns to BOUND state and may continue network
- processing.
-
-
-
-Droms Standards Track [Page 40]
-\f
-RFC 2131 Dynamic Host Configuration Protocol March 1997
-
-
- If no DHCPACK arrives before time T2, the client moves to REBINDING
- state and sends (via broadcast) a DHCPREQUEST message to extend its
- lease. The client sets the 'ciaddr' field in the DHCPREQUEST to its
- current network address. The client MUST NOT include a 'server
- identifier' in the DHCPREQUEST message.
-
- Times T1 and T2 are configurable by the server through options. T1
- defaults to (0.5 * duration_of_lease). T2 defaults to (0.875 *
- duration_of_lease). Times T1 and T2 SHOULD be chosen with some
- random "fuzz" around a fixed value, to avoid synchronization of
- client reacquisition.
-
- A client MAY choose to renew or extend its lease prior to T1. The
- server MAY choose to extend the client's lease according to policy
- set by the network administrator. The server SHOULD return T1 and
- T2, and their values SHOULD be adjusted from their original values to
- take account of the time remaining on the lease.
-
- In both RENEWING and REBINDING states, if the client receives no
- response to its DHCPREQUEST message, the client SHOULD wait one-half
- of the remaining time until T2 (in RENEWING state) and one-half of
- the remaining lease time (in REBINDING state), down to a minimum of
- 60 seconds, before retransmitting the DHCPREQUEST message.
-
- If the lease expires before the client receives a DHCPACK, the client
- moves to INIT state, MUST immediately stop any other network
- processing and requests network initialization parameters as if the
- client were uninitialized. If the client then receives a DHCPACK
- allocating that client its previous network address, the client
- SHOULD continue network processing. If the client is given a new
- network address, it MUST NOT continue using the previous network
- address and SHOULD notify the local users of the problem.
-
-4.4.6 DHCPRELEASE
-
- If the client no longer requires use of its assigned network address
- (e.g., the client is gracefully shut down), the client sends a
- DHCPRELEASE message to the server. Note that the correct operation
- of DHCP does not depend on the transmission of DHCPRELEASE messages.
-
-
-
-
-
-
-
-
-
-
-
-
-Droms Standards Track [Page 41]
-\f
-RFC 2131 Dynamic Host Configuration Protocol March 1997
-
-
-5. Acknowledgments
-
- The author thanks the many (and too numerous to mention!) members of
- the DHC WG for their tireless and ongoing efforts in the development
- of DHCP and this document.
-
- The efforts of J Allard, Mike Carney, Dave Lapp, Fred Lien and John
- Mendonca in organizing DHCP interoperability testing sessions are
- gratefully acknowledged.
-
- The development of this document was supported in part by grants from
- the Corporation for National Research Initiatives (CNRI), Bucknell
- University and Sun Microsystems.
-
-6. References
-
- [1] Acetta, M., "Resource Location Protocol", RFC 887, CMU, December
- 1983.
-
- [2] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor
- Extensions", RFC 1533, Lachman Technology, Inc., Bucknell
- University, October 1993.
-
- [3] Braden, R., Editor, "Requirements for Internet Hosts --
- Communication Layers", STD 3, RFC 1122, USC/Information Sciences
- Institute, October 1989.
-
- [4] Braden, R., Editor, "Requirements for Internet Hosts --
- Application and Support, STD 3, RFC 1123, USC/Information
- Sciences Institute, October 1989.
-
- [5] Brownell, D, "Dynamic Reverse Address Resolution Protocol
- (DRARP)", Work in Progress.
-
- [6] Comer, D., and R. Droms, "Uniform Access to Internet Directory
- Services", Proc. of ACM SIGCOMM '90 (Special issue of Computer
- Communications Review), 20(4):50--59, 1990.
-
- [7] Croft, B., and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951,
- Stanford and SUN Microsystems, September 1985.
-
- [8] Deering, S., "ICMP Router Discovery Messages", RFC 1256, Xerox
- PARC, September 1991.
-
- [9] Droms, D., "Interoperation between DHCP and BOOTP", RFC 1534,
- Bucknell University, October 1993.
-
-
-
-
-
-Droms Standards Track [Page 42]
-\f
-RFC 2131 Dynamic Host Configuration Protocol March 1997
-
-
- [10] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A Reverse
- Address Resolution Protocol", RFC 903, Stanford, June 1984.
-
- [11] Gray C., and D. Cheriton, "Leases: An Efficient Fault-Tolerant
- Mechanism for Distributed File Cache Consistency", In Proc. of
- the Twelfth ACM Symposium on Operating Systems Design, 1989.
-
- [12] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD
- 13, RFC 1034, USC/Information Sciences Institute, November 1987.
-
- [13] Mockapetris, P., "Domain Names -- Implementation and
- Specification", STD 13, RFC 1035, USC/Information Sciences
- Institute, November 1987.
-
- [14] Mogul J., and S. Deering, "Path MTU Discovery", RFC 1191,
- November 1990.
-
- [15] Morgan, R., "Dynamic IP Address Assignment for Ethernet Attached
- Hosts", Work in Progress.
-
- [16] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792,
- USC/Information Sciences Institute, September 1981.
-
- [17] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1497,
- USC/Information Sciences Institute, August 1993.
-
- [18] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
- USC/Information Sciences Institute, October 1994.
-
- [19] Jeffrey Schiller and Mark Rosenstein. A Protocol for the Dynamic
- Assignment of IP Addresses for use on an Ethernet. (Available
- from the Athena Project, MIT), 1989.
-
- [20] Sollins, K., "The TFTP Protocol (Revision 2)", RFC 783, NIC,
- June 1981.
-
- [21] Wimer, W., "Clarifications and Extensions for the Bootstrap
- Protocol", RFC 1542, Carnegie Mellon University, October 1993.
-
-7. Security Considerations
-
- DHCP is built directly on UDP and IP which are as yet inherently
- insecure. Furthermore, DHCP is generally intended to make
- maintenance of remote and/or diskless hosts easier. While perhaps
- not impossible, configuring such hosts with passwords or keys may be
- difficult and inconvenient. Therefore, DHCP in its current form is
- quite insecure.
-
-
-
-
-Droms Standards Track [Page 43]
-\f
-RFC 2131 Dynamic Host Configuration Protocol March 1997
-
-
- Unauthorized DHCP servers may be easily set up. Such servers can
- then send false and potentially disruptive information to clients
- such as incorrect or duplicate IP addresses, incorrect routing
- information (including spoof routers, etc.), incorrect domain
- nameserver addresses (such as spoof nameservers), and so on.
- Clearly, once this seed information is in place, an attacker can
- further compromise affected systems.
-
- Malicious DHCP clients could masquerade as legitimate clients and
- retrieve information intended for those legitimate clients. Where
- dynamic allocation of resources is used, a malicious client could
- claim all resources for itself, thereby denying resources to
- legitimate clients.
-
-8. Author's Address
-
- Ralph Droms
- Computer Science Department
- 323 Dana Engineering
- Bucknell University
- Lewisburg, PA 17837
-
- Phone: (717) 524-1145
- EMail: droms@bucknell.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Droms Standards Track [Page 44]
-\f
-RFC 2131 Dynamic Host Configuration Protocol March 1997
-
-
-A. Host Configuration Parameters
-
- IP-layer_parameters,_per_host:_
-
- Be a router on/off HRC 3.1
- Non-local source routing on/off HRC 3.3.5
- Policy filters for
- non-local source routing (list) HRC 3.3.5
- Maximum reassembly size integer HRC 3.3.2
- Default TTL integer HRC 3.2.1.7
- PMTU aging timeout integer MTU 6.6
- MTU plateau table (list) MTU 7
- IP-layer_parameters,_per_interface:_
- IP address (address) HRC 3.3.1.6
- Subnet mask (address mask) HRC 3.3.1.6
- MTU integer HRC 3.3.3
- All-subnets-MTU on/off HRC 3.3.3
- Broadcast address flavor 0x00000000/0xffffffff HRC 3.3.6
- Perform mask discovery on/off HRC 3.2.2.9
- Be a mask supplier on/off HRC 3.2.2.9
- Perform router discovery on/off RD 5.1
- Router solicitation address (address) RD 5.1
- Default routers, list of:
- router address (address) HRC 3.3.1.6
- preference level integer HRC 3.3.1.6
- Static routes, list of:
- destination (host/subnet/net) HRC 3.3.1.2
- destination mask (address mask) HRC 3.3.1.2
- type-of-service integer HRC 3.3.1.2
- first-hop router (address) HRC 3.3.1.2
- ignore redirects on/off HRC 3.3.1.2
- PMTU integer MTU 6.6
- perform PMTU discovery on/off MTU 6.6
-
- Link-layer_parameters,_per_interface:_
- Trailers on/off HRC 2.3.1
- ARP cache timeout integer HRC 2.3.2.1
- Ethernet encapsulation (RFC 894/RFC 1042) HRC 2.3.3
-
- TCP_parameters,_per_host:_
- TTL integer HRC 4.2.2.19
- Keep-alive interval integer HRC 4.2.3.6
- Keep-alive data size 0/1 HRC 4.2.3.6
-
-Key:
-
- MTU = Path MTU Discovery (RFC 1191, Proposed Standard)
- RD = Router Discovery (RFC 1256, Proposed Standard)
-
-
-
-Droms Standards Track [Page 45]
-\f
+++ /dev/null
-
-
-
-
-
-
-Network Working Group S. Alexander
-Request for Comments: 2132 Silicon Graphics, Inc.
-Obsoletes: 1533 R. Droms
-Category: Standards Track Bucknell University
- March 1997
-
- DHCP Options and BOOTP Vendor Extensions
-
-Status of this memo
-
- This document specifies an Internet standards track protocol for the
- Internet community, and requests discussion and suggestions for
- improvements. Please refer to the current edition of the "Internet
- Official Protocol Standards" (STD 1) for the standardization state
- and status of this protocol. Distribution of this memo is unlimited.
-
-Abstract
-
- The Dynamic Host Configuration Protocol (DHCP) [1] provides a
- framework for passing configuration information to hosts on a TCP/IP
- network. Configuration parameters and other control information are
- carried in tagged data items that are stored in the 'options' field
- of the DHCP message. The data items themselves are also called
- "options."
-
- This document specifies the current set of DHCP options. Future
- options will be specified in separate RFCs. The current list of
- valid options is also available in ftp://ftp.isi.edu/in-
- notes/iana/assignments [22].
-
- All of the vendor information extensions defined in RFC 1497 [2] may
- be used as DHCP options. The definitions given in RFC 1497 are
- included in this document, which supersedes RFC 1497. All of the
- DHCP options defined in this document, except for those specific to
- DHCP as defined in section 9, may be used as BOOTP vendor information
- extensions.
-
-Table of Contents
-
- 1. Introduction .............................................. 2
- 2. BOOTP Extension/DHCP Option Field Format .................. 4
- 3. RFC 1497 Vendor Extensions ................................ 5
- 4. IP Layer Parameters per Host .............................. 11
- 5. IP Layer Parameters per Interface ........................ 13
- 6. Link Layer Parameters per Interface ....................... 16
- 7. TCP Parameters ............................................ 17
- 8. Application and Service Parameters ........................ 18
- 9. DHCP Extensions ........................................... 25
-
-
-
-Alexander & Droms Standards Track [Page 1]
-\f
-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
-
-
- 10. Defining new extensions ................................... 31
- 11. Acknowledgements .......................................... 31
- 12. References ................................................ 32
- 13. Security Considerations ................................... 33
- 14. Authors' Addresses ........................................ 34
-
-1. Introduction
-
- This document specifies options for use with both the Dynamic Host
- Configuration Protocol and the Bootstrap Protocol.
-
- The full description of DHCP packet formats may be found in the DHCP
- specification document [1], and the full description of BOOTP packet
- formats may be found in the BOOTP specification document [3]. This
- document defines the format of information in the last field of DHCP
- packets ('options') and of BOOTP packets ('vend'). The remainder of
- this section defines a generalized use of this area for giving
- information useful to a wide class of machines, operating systems and
- configurations. Sites with a single DHCP or BOOTP server that is
- shared among heterogeneous clients may choose to define other, site-
- specific formats for the use of the 'options' field.
-
- Section 2 of this memo describes the formats of DHCP options and
- BOOTP vendor extensions. Section 3 describes options defined in
- previous documents for use with BOOTP (all may also be used with
- DHCP). Sections 4-8 define new options intended for use with both
- DHCP and BOOTP. Section 9 defines options used only in DHCP.
-
- References further describing most of the options defined in sections
- 2-6 can be found in section 12. The use of the options defined in
- section 9 is described in the DHCP specification [1].
-
- Information on registering new options is contained in section 10.
-
- This document updates the definition of DHCP/BOOTP options that
- appears in RFC1533. The classing mechanism has been extended to
- include vendor classes as described in section 8.4 and 9.13. The new
- procedure for defining new DHCP/BOOTP options in described in section
- 10. Several new options, including NIS+ domain and servers, Mobile
- IP home agent, SMTP server, TFTP server and Bootfile server, have
- been added. Text giving definitions used throughout the document has
- been added in section 1.1. Text emphasizing the need for uniqueness
- of client-identifiers has been added to section 9.14.
-
-
-
-
-
-
-
-
-Alexander & Droms Standards Track [Page 2]
-\f
-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
-
-
-1.1 Requirements
-
- Throughout this document, the words that are used to define the
- significance of particular requirements are capitalized. These words
- are:
-
- o "MUST"
-
- This word or the adjective "REQUIRED" means that the item is an
- absolute requirement of this specification.
-
- o "MUST NOT"
-
- This phrase means that the item is an absolute prohibition of
- this specification.
-
- o "SHOULD"
-
- This word or the adjective "RECOMMENDED" means that there may
- exist valid reasons in particular circumstances to ignore this
- item, but the full implications should be understood and the case
- carefully weighed before choosing a different course.
-
- o "SHOULD NOT"
-
- This phrase means that there may exist valid reasons in
- particular circumstances when the listed behavior is acceptable
- or even useful, but the full implications should be understood
- and the case carefully weighed before implementing any behavior
- described with this label.
-
- o "MAY"
-
- This word or the adjective "OPTIONAL" means that this item is
- truly optional. One vendor may choose to include the item
- because a particular marketplace requires it or because it
- enhances the product, for example; another vendor may omit the
- same item.
-
-1.2 Terminology
-
- This document uses the following terms:
-
- o "DHCP client"
-
- A DHCP client or "client" is an Internet host using DHCP to
- obtain configuration parameters such as a network address.
-
-
-
-
-Alexander & Droms Standards Track [Page 3]
-\f
-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
-
-
- o "DHCP server"
-
- A DHCP server of "server"is an Internet host that returns
- configuration parameters to DHCP clients.
-
- o "binding"
-
- A binding is a collection of configuration parameters, including
- at least an IP address, associated with or "bound to" a DHCP
- client. Bindings are managed by DHCP servers.
-
-2. BOOTP Extension/DHCP Option Field Format
-
-
- DHCP options have the same format as the BOOTP 'vendor extensions'
- defined in RFC 1497 [2]. Options may be fixed length or variable
- length. All options begin with a tag octet, which uniquely
- identifies the option. Fixed-length options without data consist of
- only a tag octet. Only options 0 and 255 are fixed length. All
- other options are variable-length with a length octet following the
- tag octet. The value of the length octet does not include the two
- octets specifying the tag and length. The length octet is followed
- by "length" octets of data. Options containing NVT ASCII data SHOULD
- NOT include a trailing NULL; however, the receiver of such options
- MUST be prepared to delete trailing nulls if they exist. The
- receiver MUST NOT require that a trailing null be included in the
- data. In the case of some variable-length options the length field
- is a constant but must still be specified.
-
- Any options defined subsequent to this document MUST contain a length
- octet even if the length is fixed or zero.
-
- All multi-octet quantities are in network byte-order.
-
- When used with BOOTP, the first four octets of the vendor information
- field have been assigned to the "magic cookie" (as suggested in RFC
- 951). This field identifies the mode in which the succeeding data is
- to be interpreted. The value of the magic cookie is the 4 octet
- dotted decimal 99.130.83.99 (or hexadecimal number 63.82.53.63) in
- network byte order.
-
- All of the "vendor extensions" defined in RFC 1497 are also DHCP
- options.
-
- Option codes 128 to 254 (decimal) are reserved for site-specific
- options.
-
-
-
-
-
-Alexander & Droms Standards Track [Page 4]
-\f
-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
-
-
- Except for the options in section 9, all options may be used with
- either DHCP or BOOTP.
-
- Many of these options have their default values specified in other
- documents. In particular, RFC 1122 [4] specifies default values for
- most IP and TCP configuration parameters.
-
- Many options supply one or more 32-bit IP address. Use of IP
- addresses rather than fully-qualified Domain Names (FQDNs) may make
- future renumbering of IP hosts more difficult. Use of these
- addresses is discouraged at sites that may require renumbering.
-
-3. RFC 1497 Vendor Extensions
-
- This section lists the vendor extensions as defined in RFC 1497.
- They are defined here for completeness.
-
-3.1. Pad Option
-
- The pad option can be used to cause subsequent fields to align on
- word boundaries.
-
- The code for the pad option is 0, and its length is 1 octet.
-
- Code
- +-----+
- | 0 |
- +-----+
-
-3.2. End Option
-
- The end option marks the end of valid information in the vendor
- field. Subsequent octets should be filled with pad options.
-
- The code for the end option is 255, and its length is 1 octet.
-
- Code
- +-----+
- | 255 |
- +-----+
-
-3.3. Subnet Mask
-
- The subnet mask option specifies the client's subnet mask as per RFC
- 950 [5].
-
- If both the subnet mask and the router option are specified in a DHCP
- reply, the subnet mask option MUST be first.
-
-
-
-Alexander & Droms Standards Track [Page 5]
-\f
-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
-
-
- The code for the subnet mask option is 1, and its length is 4 octets.
-
- Code Len Subnet Mask
- +-----+-----+-----+-----+-----+-----+
- | 1 | 4 | m1 | m2 | m3 | m4 |
- +-----+-----+-----+-----+-----+-----+
-
-3.4. Time Offset
-
- The time offset field specifies the offset of the client's subnet in
- seconds from Coordinated Universal Time (UTC). The offset is
- expressed as a two's complement 32-bit integer. A positive offset
- indicates a location east of the zero meridian and a negative offset
- indicates a location west of the zero meridian.
-
- The code for the time offset option is 2, and its length is 4 octets.
-
- Code Len Time Offset
- +-----+-----+-----+-----+-----+-----+
- | 2 | 4 | n1 | n2 | n3 | n4 |
- +-----+-----+-----+-----+-----+-----+
-
-3.5. Router Option
-
- The router option specifies a list of IP addresses for routers on the
- client's subnet. Routers SHOULD be listed in order of preference.
-
- The code for the router option is 3. The minimum length for the
- router option is 4 octets, and the length MUST always be a multiple
- of 4.
-
- Code Len Address 1 Address 2
- +-----+-----+-----+-----+-----+-----+-----+-----+--
- | 3 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-3.6. Time Server Option
-
- The time server option specifies a list of RFC 868 [6] time servers
- available to the client. Servers SHOULD be listed in order of
- preference.
-
- The code for the time server option is 4. The minimum length for
- this option is 4 octets, and the length MUST always be a multiple of
- 4.
-
-
-
-
-
-
-Alexander & Droms Standards Track [Page 6]
-\f
-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
-
-
- Code Len Address 1 Address 2
- +-----+-----+-----+-----+-----+-----+-----+-----+--
- | 4 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-3.7. Name Server Option
-
- The name server option specifies a list of IEN 116 [7] name servers
- available to the client. Servers SHOULD be listed in order of
- preference.
-
- The code for the name server option is 5. The minimum length for
- this option is 4 octets, and the length MUST always be a multiple of
- 4.
-
- Code Len Address 1 Address 2
- +-----+-----+-----+-----+-----+-----+-----+-----+--
- | 5 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-3.8. Domain Name Server Option
-
- The domain name server option specifies a list of Domain Name System
- (STD 13, RFC 1035 [8]) name servers available to the client. Servers
- SHOULD be listed in order of preference.
-
- The code for the domain name server option is 6. The minimum length
- for this option is 4 octets, and the length MUST always be a multiple
- of 4.
-
- Code Len Address 1 Address 2
- +-----+-----+-----+-----+-----+-----+-----+-----+--
- | 6 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-3.9. Log Server Option
-
- The log server option specifies a list of MIT-LCS UDP log servers
- available to the client. Servers SHOULD be listed in order of
- preference.
-
- The code for the log server option is 7. The minimum length for this
- option is 4 octets, and the length MUST always be a multiple of 4.
-
- Code Len Address 1 Address 2
- +-----+-----+-----+-----+-----+-----+-----+-----+--
- | 7 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-
-
-Alexander & Droms Standards Track [Page 7]
-\f
-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
-
-
-3.10. Cookie Server Option
-
- The cookie server option specifies a list of RFC 865 [9] cookie
- servers available to the client. Servers SHOULD be listed in order
- of preference.
-
- The code for the log server option is 8. The minimum length for this
- option is 4 octets, and the length MUST always be a multiple of 4.
-
- Code Len Address 1 Address 2
- +-----+-----+-----+-----+-----+-----+-----+-----+--
- | 8 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-3.11. LPR Server Option
-
- The LPR server option specifies a list of RFC 1179 [10] line printer
- servers available to the client. Servers SHOULD be listed in order
- of preference.
-
- The code for the LPR server option is 9. The minimum length for this
- option is 4 octets, and the length MUST always be a multiple of 4.
-
- Code Len Address 1 Address 2
- +-----+-----+-----+-----+-----+-----+-----+-----+--
- | 9 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-3.12. Impress Server Option
-
- The Impress server option specifies a list of Imagen Impress servers
- available to the client. Servers SHOULD be listed in order of
- preference.
-
- The code for the Impress server option is 10. The minimum length for
- this option is 4 octets, and the length MUST always be a multiple of
- 4.
-
- Code Len Address 1 Address 2
- +-----+-----+-----+-----+-----+-----+-----+-----+--
- | 10 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-3.13. Resource Location Server Option
-
- This option specifies a list of RFC 887 [11] Resource Location
- servers available to the client. Servers SHOULD be listed in order
- of preference.
-
-
-
-Alexander & Droms Standards Track [Page 8]
-\f
-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
-
-
- The code for this option is 11. The minimum length for this option
- is 4 octets, and the length MUST always be a multiple of 4.
-
- Code Len Address 1 Address 2
- +-----+-----+-----+-----+-----+-----+-----+-----+--
- | 11 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-3.14. Host Name Option
-
- This option specifies the name of the client. The name may or may
- not be qualified with the local domain name (see section 3.17 for the
- preferred way to retrieve the domain name). See RFC 1035 for
- character set restrictions.
-
- The code for this option is 12, and its minimum length is 1.
-
- Code Len Host Name
- +-----+-----+-----+-----+-----+-----+-----+-----+--
- | 12 | n | h1 | h2 | h3 | h4 | h5 | h6 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-3.15. Boot File Size Option
-
- This option specifies the length in 512-octet blocks of the default
- boot image for the client. The file length is specified as an
- unsigned 16-bit integer.
-
- The code for this option is 13, and its length is 2.
-
- Code Len File Size
- +-----+-----+-----+-----+
- | 13 | 2 | l1 | l2 |
- +-----+-----+-----+-----+
-
-3.16. Merit Dump File
-
- This option specifies the path-name of a file to which the client's
- core image should be dumped in the event the client crashes. The
- path is formatted as a character string consisting of characters from
- the NVT ASCII character set.
-
- The code for this option is 14. Its minimum length is 1.
-
- Code Len Dump File Pathname
- +-----+-----+-----+-----+-----+-----+---
- | 14 | n | n1 | n2 | n3 | n4 | ...
- +-----+-----+-----+-----+-----+-----+---
-
-
-
-Alexander & Droms Standards Track [Page 9]
-\f
-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
-
-
-3.17. Domain Name
-
- This option specifies the domain name that client should use when
- resolving hostnames via the Domain Name System.
-
- The code for this option is 15. Its minimum length is 1.
-
- Code Len Domain Name
- +-----+-----+-----+-----+-----+-----+--
- | 15 | n | d1 | d2 | d3 | d4 | ...
- +-----+-----+-----+-----+-----+-----+--
-
-3.18. Swap Server
-
- This specifies the IP address of the client's swap server.
-
- The code for this option is 16 and its length is 4.
-
- Code Len Swap Server Address
- +-----+-----+-----+-----+-----+-----+
- | 16 | n | a1 | a2 | a3 | a4 |
- +-----+-----+-----+-----+-----+-----+
-
-3.19. Root Path
-
- This option specifies the path-name that contains the client's root
- disk. The path is formatted as a character string consisting of
- characters from the NVT ASCII character set.
-
- The code for this option is 17. Its minimum length is 1.
-
- Code Len Root Disk Pathname
- +-----+-----+-----+-----+-----+-----+---
- | 17 | n | n1 | n2 | n3 | n4 | ...
- +-----+-----+-----+-----+-----+-----+---
-
-3.20. Extensions Path
-
- A string to specify a file, retrievable via TFTP, which contains
- information which can be interpreted in the same way as the 64-octet
- vendor-extension field within the BOOTP response, with the following
- exceptions:
-
- - the length of the file is unconstrained;
- - all references to Tag 18 (i.e., instances of the
- BOOTP Extensions Path field) within the file are
- ignored.
-
-
-
-
-Alexander & Droms Standards Track [Page 10]
-\f
-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
-
-
- The code for this option is 18. Its minimum length is 1.
-
- Code Len Extensions Pathname
- +-----+-----+-----+-----+-----+-----+---
- | 18 | n | n1 | n2 | n3 | n4 | ...
- +-----+-----+-----+-----+-----+-----+---
-
-4. IP Layer Parameters per Host
-
- This section details the options that affect the operation of the IP
- layer on a per-host basis.
-
-4.1. IP Forwarding Enable/Disable Option
-
- This option specifies whether the client should configure its IP
- layer for packet forwarding. A value of 0 means disable IP
- forwarding, and a value of 1 means enable IP forwarding.
-
- The code for this option is 19, and its length is 1.
-
- Code Len Value
- +-----+-----+-----+
- | 19 | 1 | 0/1 |
- +-----+-----+-----+
-
-4.2. Non-Local Source Routing Enable/Disable Option
-
- This option specifies whether the client should configure its IP
- layer to allow forwarding of datagrams with non-local source routes
- (see Section 3.3.5 of [4] for a discussion of this topic). A value
- of 0 means disallow forwarding of such datagrams, and a value of 1
- means allow forwarding.
-
- The code for this option is 20, and its length is 1.
-
- Code Len Value
- +-----+-----+-----+
- | 20 | 1 | 0/1 |
- +-----+-----+-----+
-
-4.3. Policy Filter Option
-
- This option specifies policy filters for non-local source routing.
- The filters consist of a list of IP addresses and masks which specify
- destination/mask pairs with which to filter incoming source routes.
-
- Any source routed datagram whose next-hop address does not match one
- of the filters should be discarded by the client.
-
-
-
-Alexander & Droms Standards Track [Page 11]
-\f
-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
-
-
- See [4] for further information.
-
- The code for this option is 21. The minimum length of this option is
- 8, and the length MUST be a multiple of 8.
-
- Code Len Address 1 Mask 1
- +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
- | 21 | n | a1 | a2 | a3 | a4 | m1 | m2 | m3 | m4 |
- +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
- Address 2 Mask 2
- +-----+-----+-----+-----+-----+-----+-----+-----+---
- | a1 | a2 | a3 | a4 | m1 | m2 | m3 | m4 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+---
-
-4.4. Maximum Datagram Reassembly Size
-
- This option specifies the maximum size datagram that the client
- should be prepared to reassemble. The size is specified as a 16-bit
- unsigned integer. The minimum value legal value is 576.
-
- The code for this option is 22, and its length is 2.
-
- Code Len Size
- +-----+-----+-----+-----+
- | 22 | 2 | s1 | s2 |
- +-----+-----+-----+-----+
-
-4.5. Default IP Time-to-live
-
- This option specifies the default time-to-live that the client should
- use on outgoing datagrams. The TTL is specified as an octet with a
- value between 1 and 255.
-
- The code for this option is 23, and its length is 1.
-
- Code Len TTL
- +-----+-----+-----+
- | 23 | 1 | ttl |
- +-----+-----+-----+
-
-4.6. Path MTU Aging Timeout Option
-
- This option specifies the timeout (in seconds) to use when aging Path
- MTU values discovered by the mechanism defined in RFC 1191 [12]. The
- timeout is specified as a 32-bit unsigned integer.
-
- The code for this option is 24, and its length is 4.
-
-
-
-
-Alexander & Droms Standards Track [Page 12]
-\f
-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
-
-
- Code Len Timeout
- +-----+-----+-----+-----+-----+-----+
- | 24 | 4 | t1 | t2 | t3 | t4 |
- +-----+-----+-----+-----+-----+-----+
-
-4.7. Path MTU Plateau Table Option
-
- This option specifies a table of MTU sizes to use when performing
- Path MTU Discovery as defined in RFC 1191. The table is formatted as
- a list of 16-bit unsigned integers, ordered from smallest to largest.
- The minimum MTU value cannot be smaller than 68.
-
- The code for this option is 25. Its minimum length is 2, and the
- length MUST be a multiple of 2.
-
- Code Len Size 1 Size 2
- +-----+-----+-----+-----+-----+-----+---
- | 25 | n | s1 | s2 | s1 | s2 | ...
- +-----+-----+-----+-----+-----+-----+---
-
-5. IP Layer Parameters per Interface
-
- This section details the options that affect the operation of the IP
- layer on a per-interface basis. It is expected that a client can
- issue multiple requests, one per interface, in order to configure
- interfaces with their specific parameters.
-
-5.1. Interface MTU Option
-
- This option specifies the MTU to use on this interface. The MTU is
- specified as a 16-bit unsigned integer. The minimum legal value for
- the MTU is 68.
-
- The code for this option is 26, and its length is 2.
-
- Code Len MTU
- +-----+-----+-----+-----+
- | 26 | 2 | m1 | m2 |
- +-----+-----+-----+-----+
-
-5.2. All Subnets are Local Option
-
- This option specifies whether or not the client may assume that all
- subnets of the IP network to which the client is connected use the
- same MTU as the subnet of that network to which the client is
- directly connected. A value of 1 indicates that all subnets share
- the same MTU. A value of 0 means that the client should assume that
- some subnets of the directly connected network may have smaller MTUs.
-
-
-
-Alexander & Droms Standards Track [Page 13]
-\f
-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
-
-
- The code for this option is 27, and its length is 1.
-
- Code Len Value
- +-----+-----+-----+
- | 27 | 1 | 0/1 |
- +-----+-----+-----+
-
-5.3. Broadcast Address Option
-
- This option specifies the broadcast address in use on the client's
- subnet. Legal values for broadcast addresses are specified in
- section 3.2.1.3 of [4].
-
- The code for this option is 28, and its length is 4.
-
- Code Len Broadcast Address
- +-----+-----+-----+-----+-----+-----+
- | 28 | 4 | b1 | b2 | b3 | b4 |
- +-----+-----+-----+-----+-----+-----+
-
-5.4. Perform Mask Discovery Option
-
- This option specifies whether or not the client should perform subnet
- mask discovery using ICMP. A value of 0 indicates that the client
- should not perform mask discovery. A value of 1 means that the
- client should perform mask discovery.
-
- The code for this option is 29, and its length is 1.
-
- Code Len Value
- +-----+-----+-----+
- | 29 | 1 | 0/1 |
- +-----+-----+-----+
-
-5.5. Mask Supplier Option
-
- This option specifies whether or not the client should respond to
- subnet mask requests using ICMP. A value of 0 indicates that the
- client should not respond. A value of 1 means that the client should
- respond.
-
- The code for this option is 30, and its length is 1.
-
- Code Len Value
- +-----+-----+-----+
- | 30 | 1 | 0/1 |
- +-----+-----+-----+
-
-
-
-
-Alexander & Droms Standards Track [Page 14]
-\f
-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
-
-
-5.6. Perform Router Discovery Option
-
- This option specifies whether or not the client should solicit
- routers using the Router Discovery mechanism defined in RFC 1256
- [13]. A value of 0 indicates that the client should not perform
- router discovery. A value of 1 means that the client should perform
- router discovery.
-
- The code for this option is 31, and its length is 1.
-
- Code Len Value
- +-----+-----+-----+
- | 31 | 1 | 0/1 |
- +-----+-----+-----+
-
-5.7. Router Solicitation Address Option
-
- This option specifies the address to which the client should transmit
- router solicitation requests.
-
- The code for this option is 32, and its length is 4.
-
- Code Len Address
- +-----+-----+-----+-----+-----+-----+
- | 32 | 4 | a1 | a2 | a3 | a4 |
- +-----+-----+-----+-----+-----+-----+
-
-5.8. Static Route Option
-
- This option specifies a list of static routes that the client should
- install in its routing cache. If multiple routes to the same
- destination are specified, they are listed in descending order of
- priority.
-
- The routes consist of a list of IP address pairs. The first address
- is the destination address, and the second address is the router for
- the destination.
-
- The default route (0.0.0.0) is an illegal destination for a static
- route. See section 3.5 for information about the router option.
-
- The code for this option is 33. The minimum length of this option is
- 8, and the length MUST be a multiple of 8.
-
-
-
-
-
-
-
-
-Alexander & Droms Standards Track [Page 15]
-\f
-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
-
-
- Code Len Destination 1 Router 1
- +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
- | 33 | n | d1 | d2 | d3 | d4 | r1 | r2 | r3 | r4 |
- +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
- Destination 2 Router 2
- +-----+-----+-----+-----+-----+-----+-----+-----+---
- | d1 | d2 | d3 | d4 | r1 | r2 | r3 | r4 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+---
-
-6. Link Layer Parameters per Interface
-
- This section lists the options that affect the operation of the data
- link layer on a per-interface basis.
-
-6.1. Trailer Encapsulation Option
-
- This option specifies whether or not the client should negotiate the
- use of trailers (RFC 893 [14]) when using the ARP protocol. A value
- of 0 indicates that the client should not attempt to use trailers. A
- value of 1 means that the client should attempt to use trailers.
-
- The code for this option is 34, and its length is 1.
-
- Code Len Value
- +-----+-----+-----+
- | 34 | 1 | 0/1 |
- +-----+-----+-----+
-
-6.2. ARP Cache Timeout Option
-
- This option specifies the timeout in seconds for ARP cache entries.
- The time is specified as a 32-bit unsigned integer.
-
- The code for this option is 35, and its length is 4.
-
- Code Len Time
- +-----+-----+-----+-----+-----+-----+
- | 35 | 4 | t1 | t2 | t3 | t4 |
- +-----+-----+-----+-----+-----+-----+
-
-6.3. Ethernet Encapsulation Option
-
- This option specifies whether or not the client should use Ethernet
- Version 2 (RFC 894 [15]) or IEEE 802.3 (RFC 1042 [16]) encapsulation
- if the interface is an Ethernet. A value of 0 indicates that the
- client should use RFC 894 encapsulation. A value of 1 means that the
- client should use RFC 1042 encapsulation.
-
-
-
-
-Alexander & Droms Standards Track [Page 16]
-\f
-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
-
-
- The code for this option is 36, and its length is 1.
-
- Code Len Value
- +-----+-----+-----+
- | 36 | 1 | 0/1 |
- +-----+-----+-----+
-
-7. TCP Parameters
-
- This section lists the options that affect the operation of the TCP
- layer on a per-interface basis.
-
-7.1. TCP Default TTL Option
-
- This option specifies the default TTL that the client should use when
- sending TCP segments. The value is represented as an 8-bit unsigned
- integer. The minimum value is 1.
-
- The code for this option is 37, and its length is 1.
-
- Code Len TTL
- +-----+-----+-----+
- | 37 | 1 | n |
- +-----+-----+-----+
-
-7.2. TCP Keepalive Interval Option
-
- This option specifies the interval (in seconds) that the client TCP
- should wait before sending a keepalive message on a TCP connection.
- The time is specified as a 32-bit unsigned integer. A value of zero
- indicates that the client should not generate keepalive messages on
- connections unless specifically requested by an application.
-
- The code for this option is 38, and its length is 4.
-
- Code Len Time
- +-----+-----+-----+-----+-----+-----+
- | 38 | 4 | t1 | t2 | t3 | t4 |
- +-----+-----+-----+-----+-----+-----+
-
-7.3. TCP Keepalive Garbage Option
-
- This option specifies the whether or not the client should send TCP
- keepalive messages with a octet of garbage for compatibility with
- older implementations. A value of 0 indicates that a garbage octet
- should not be sent. A value of 1 indicates that a garbage octet
- should be sent.
-
-
-
-
-Alexander & Droms Standards Track [Page 17]
-\f
-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
-
-
- The code for this option is 39, and its length is 1.
-
- Code Len Value
- +-----+-----+-----+
- | 39 | 1 | 0/1 |
- +-----+-----+-----+
-
-8. Application and Service Parameters
-
- This section details some miscellaneous options used to configure
- miscellaneous applications and services.
-
-8.1. Network Information Service Domain Option
-
- This option specifies the name of the client's NIS [17] domain. The
- domain is formatted as a character string consisting of characters
- from the NVT ASCII character set.
-
- The code for this option is 40. Its minimum length is 1.
-
- Code Len NIS Domain Name
- +-----+-----+-----+-----+-----+-----+---
- | 40 | n | n1 | n2 | n3 | n4 | ...
- +-----+-----+-----+-----+-----+-----+---
-
-8.2. Network Information Servers Option
-
- This option specifies a list of IP addresses indicating NIS servers
- available to the client. Servers SHOULD be listed in order of
- preference.
-
- The code for this option is 41. Its minimum length is 4, and the
- length MUST be a multiple of 4.
-
- Code Len Address 1 Address 2
- +-----+-----+-----+-----+-----+-----+-----+-----+--
- | 41 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-8.3. Network Time Protocol Servers Option
-
- This option specifies a list of IP addresses indicating NTP [18]
- servers available to the client. Servers SHOULD be listed in order
- of preference.
-
- The code for this option is 42. Its minimum length is 4, and the
- length MUST be a multiple of 4.
-
-
-
-
-Alexander & Droms Standards Track [Page 18]
-\f
-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
-
-
- Code Len Address 1 Address 2
- +-----+-----+-----+-----+-----+-----+-----+-----+--
- | 42 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-8.4. Vendor Specific Information
-
- This option is used by clients and servers to exchange vendor-
- specific information. The information is an opaque object of n
- octets, presumably interpreted by vendor-specific code on the clients
- and servers. The definition of this information is vendor specific.
- The vendor is indicated in the vendor class identifier option.
- Servers not equipped to interpret the vendor-specific information
- sent by a client MUST ignore it (although it may be reported).
- Clients which do not receive desired vendor-specific information
- SHOULD make an attempt to operate without it, although they may do so
- (and announce they are doing so) in a degraded mode.
-
- If a vendor potentially encodes more than one item of information in
- this option, then the vendor SHOULD encode the option using
- "Encapsulated vendor-specific options" as described below:
-
- The Encapsulated vendor-specific options field SHOULD be encoded as a
- sequence of code/length/value fields of identical syntax to the DHCP
- options field with the following exceptions:
-
- 1) There SHOULD NOT be a "magic cookie" field in the encapsulated
- vendor-specific extensions field.
-
- 2) Codes other than 0 or 255 MAY be redefined by the vendor within
- the encapsulated vendor-specific extensions field, but SHOULD
- conform to the tag-length-value syntax defined in section 2.
-
- 3) Code 255 (END), if present, signifies the end of the
- encapsulated vendor extensions, not the end of the vendor
- extensions field. If no code 255 is present, then the end of
- the enclosing vendor-specific information field is taken as the
- end of the encapsulated vendor-specific extensions field.
-
- The code for this option is 43 and its minimum length is 1.
-
- Code Len Vendor-specific information
- +-----+-----+-----+-----+---
- | 43 | n | i1 | i2 | ...
- +-----+-----+-----+-----+---
-
-
-
-
-
-
-Alexander & Droms Standards Track [Page 19]
-\f
-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
-
-
- When encapsulated vendor-specific extensions are used, the
- information bytes 1-n have the following format:
-
- Code Len Data item Code Len Data item Code
- +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
- | T1 | n | d1 | d2 | ... | T2 | n | D1 | D2 | ... | ... |
- +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
-
-8.5. NetBIOS over TCP/IP Name Server Option
-
- The NetBIOS name server (NBNS) option specifies a list of RFC
- 1001/1002 [19] [20] NBNS name servers listed in order of preference.
-
- The code for this option is 44. The minimum length of the option is
- 4 octets, and the length must always be a multiple of 4.
-
- Code Len Address 1 Address 2
- +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+----
- | 44 | n | a1 | a2 | a3 | a4 | b1 | b2 | b3 | b4 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+----
-
-8.6. NetBIOS over TCP/IP Datagram Distribution Server Option
-
- The NetBIOS datagram distribution server (NBDD) option specifies a
- list of RFC 1001/1002 NBDD servers listed in order of preference. The
- code for this option is 45. The minimum length of the option is 4
- octets, and the length must always be a multiple of 4.
-
- Code Len Address 1 Address 2
- +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+----
- | 45 | n | a1 | a2 | a3 | a4 | b1 | b2 | b3 | b4 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+----
-
-8.7. NetBIOS over TCP/IP Node Type Option
-
- The NetBIOS node type option allows NetBIOS over TCP/IP clients which
- are configurable to be configured as described in RFC 1001/1002. The
- value is specified as a single octet which identifies the client type
- as follows:
-
- Value Node Type
- ----- ---------
- 0x1 B-node
- 0x2 P-node
- 0x4 M-node
- 0x8 H-node
-
-
-
-
-
-Alexander & Droms Standards Track [Page 20]
-\f
-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
-
-
- In the above chart, the notation '0x' indicates a number in base-16
- (hexadecimal).
-
- The code for this option is 46. The length of this option is always
- 1.
-
- Code Len Node Type
- +-----+-----+-----------+
- | 46 | 1 | see above |
- +-----+-----+-----------+
-
-8.8. NetBIOS over TCP/IP Scope Option
-
- The NetBIOS scope option specifies the NetBIOS over TCP/IP scope
- parameter for the client as specified in RFC 1001/1002. See [19],
- [20], and [8] for character-set restrictions.
-
- The code for this option is 47. The minimum length of this option is
- 1.
-
- Code Len NetBIOS Scope
- +-----+-----+-----+-----+-----+-----+----
- | 47 | n | s1 | s2 | s3 | s4 | ...
- +-----+-----+-----+-----+-----+-----+----
-
-8.9. X Window System Font Server Option
-
- This option specifies a list of X Window System [21] Font servers
- available to the client. Servers SHOULD be listed in order of
- preference.
-
- The code for this option is 48. The minimum length of this option is
- 4 octets, and the length MUST be a multiple of 4.
-
- Code Len Address 1 Address 2
- +-----+-----+-----+-----+-----+-----+-----+-----+---
- | 48 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+---
-
-8.10. X Window System Display Manager Option
-
- This option specifies a list of IP addresses of systems that are
- running the X Window System Display Manager and are available to the
- client.
-
- Addresses SHOULD be listed in order of preference.
-
-
-
-
-
-Alexander & Droms Standards Track [Page 21]
-\f
-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
-
-
- The code for the this option is 49. The minimum length of this option
- is 4, and the length MUST be a multiple of 4.
-
- Code Len Address 1 Address 2
-
- +-----+-----+-----+-----+-----+-----+-----+-----+---
- | 49 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+---
-
-8.11. Network Information Service+ Domain Option
-
- This option specifies the name of the client's NIS+ [17] domain. The
- domain is formatted as a character string consisting of characters
- from the NVT ASCII character set.
-
- The code for this option is 64. Its minimum length is 1.
-
- Code Len NIS Client Domain Name
- +-----+-----+-----+-----+-----+-----+---
- | 64 | n | n1 | n2 | n3 | n4 | ...
- +-----+-----+-----+-----+-----+-----+---
-
-8.12. Network Information Service+ Servers Option
-
- This option specifies a list of IP addresses indicating NIS+ servers
- available to the client. Servers SHOULD be listed in order of
- preference.
-
- The code for this option is 65. Its minimum length is 4, and the
- length MUST be a multiple of 4.
-
- Code Len Address 1 Address 2
- +-----+-----+-----+-----+-----+-----+-----+-----+--
- | 65 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-8.13. Mobile IP Home Agent option
-
- This option specifies a list of IP addresses indicating mobile IP
- home agents available to the client. Agents SHOULD be listed in
- order of preference.
-
- The code for this option is 68. Its minimum length is 0 (indicating
- no home agents are available) and the length MUST be a multiple of 4.
- It is expected that the usual length will be four octets, containing
- a single home agent's address.
-
-
-
-
-
-Alexander & Droms Standards Track [Page 22]
-\f
-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
-
-
- Code Len Home Agent Addresses (zero or more)
- +-----+-----+-----+-----+-----+-----+--
- | 68 | n | a1 | a2 | a3 | a4 | ...
- +-----+-----+-----+-----+-----+-----+--
-
-8.14. Simple Mail Transport Protocol (SMTP) Server Option
-
- The SMTP server option specifies a list of SMTP servers available to
- the client. Servers SHOULD be listed in order of preference.
-
- The code for the SMTP server option is 69. The minimum length for
- this option is 4 octets, and the length MUST always be a multiple of
- 4.
-
- Code Len Address 1 Address 2
- +-----+-----+-----+-----+-----+-----+-----+-----+--
- | 69 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-8.15. Post Office Protocol (POP3) Server Option
-
- The POP3 server option specifies a list of POP3 available to the
- client. Servers SHOULD be listed in order of preference.
-
- The code for the POP3 server option is 70. The minimum length for
- this option is 4 octets, and the length MUST always be a multiple of
- 4.
-
- Code Len Address 1 Address 2
- +-----+-----+-----+-----+-----+-----+-----+-----+--
- | 70 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-8.16. Network News Transport Protocol (NNTP) Server Option
-
- The NNTP server option specifies a list of NNTP available to the
- client. Servers SHOULD be listed in order of preference.
-
- The code for the NNTP server option is 71. The minimum length for
- this option is 4 octets, and the length MUST always be a multiple of
- 4.
-
- Code Len Address 1 Address 2
- +-----+-----+-----+-----+-----+-----+-----+-----+--
- | 71 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-
-
-
-
-Alexander & Droms Standards Track [Page 23]
-\f
-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
-
-
-8.17. Default World Wide Web (WWW) Server Option
-
- The WWW server option specifies a list of WWW available to the
- client. Servers SHOULD be listed in order of preference.
-
- The code for the WWW server option is 72. The minimum length for
- this option is 4 octets, and the length MUST always be a multiple of
- 4.
-
- Code Len Address 1 Address 2
- +-----+-----+-----+-----+-----+-----+-----+-----+--
- | 72 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-8.18. Default Finger Server Option
-
- The Finger server option specifies a list of Finger available to the
- client. Servers SHOULD be listed in order of preference.
-
- The code for the Finger server option is 73. The minimum length for
- this option is 4 octets, and the length MUST always be a multiple of
- 4.
-
- Code Len Address 1 Address 2
- +-----+-----+-----+-----+-----+-----+-----+-----+--
- | 73 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-8.19. Default Internet Relay Chat (IRC) Server Option
-
- The IRC server option specifies a list of IRC available to the
- client. Servers SHOULD be listed in order of preference.
-
- The code for the IRC server option is 74. The minimum length for
- this option is 4 octets, and the length MUST always be a multiple of
- 4.
-
- Code Len Address 1 Address 2
- +-----+-----+-----+-----+-----+-----+-----+-----+--
- | 74 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-8.20. StreetTalk Server Option
-
- The StreetTalk server option specifies a list of StreetTalk servers
- available to the client. Servers SHOULD be listed in order of
- preference.
-
-
-
-
-Alexander & Droms Standards Track [Page 24]
-\f
-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
-
-
- The code for the StreetTalk server option is 75. The minimum length
- for this option is 4 octets, and the length MUST always be a multiple
- of 4.
-
- Code Len Address 1 Address 2
- +-----+-----+-----+-----+-----+-----+-----+-----+--
- | 75 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-8.21. StreetTalk Directory Assistance (STDA) Server Option
-
- The StreetTalk Directory Assistance (STDA) server option specifies a
- list of STDA servers available to the client. Servers SHOULD be
- listed in order of preference.
-
- The code for the StreetTalk Directory Assistance server option is 76.
- The minimum length for this option is 4 octets, and the length MUST
- always be a multiple of 4.
-
- Code Len Address 1 Address 2
- +-----+-----+-----+-----+-----+-----+-----+-----+--
- | 76 | n | a1 | a2 | a3 | a4 | a1 | a2 | ...
- +-----+-----+-----+-----+-----+-----+-----+-----+--
-
-9. DHCP Extensions
-
- This section details the options that are specific to DHCP.
-
-9.1. Requested IP Address
-
- This option is used in a client request (DHCPDISCOVER) to allow the
- client to request that a particular IP address be assigned.
-
- The code for this option is 50, and its length is 4.
-
- Code Len Address
- +-----+-----+-----+-----+-----+-----+
- | 50 | 4 | a1 | a2 | a3 | a4 |
- +-----+-----+-----+-----+-----+-----+
-
-9.2. IP Address Lease Time
-
- This option is used in a client request (DHCPDISCOVER or DHCPREQUEST)
- to allow the client to request a lease time for the IP address. In a
- server reply (DHCPOFFER), a DHCP server uses this option to specify
- the lease time it is willing to offer.
-
-
-
-
-
-Alexander & Droms Standards Track [Page 25]
-\f
-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
-
-
- The time is in units of seconds, and is specified as a 32-bit
- unsigned integer.
-
- The code for this option is 51, and its length is 4.
-
- Code Len Lease Time
- +-----+-----+-----+-----+-----+-----+
- | 51 | 4 | t1 | t2 | t3 | t4 |
- +-----+-----+-----+-----+-----+-----+
-
-9.3. Option Overload
-
- This option is used to indicate that the DHCP 'sname' or 'file'
- fields are being overloaded by using them to carry DHCP options. A
- DHCP server inserts this option if the returned parameters will
- exceed the usual space allotted for options.
-
- If this option is present, the client interprets the specified
- additional fields after it concludes interpretation of the standard
- option fields.
-
- The code for this option is 52, and its length is 1. Legal values
- for this option are:
-
- Value Meaning
- ----- --------
- 1 the 'file' field is used to hold options
- 2 the 'sname' field is used to hold options
- 3 both fields are used to hold options
-
- Code Len Value
- +-----+-----+-----+
- | 52 | 1 |1/2/3|
- +-----+-----+-----+
-
-9.4 TFTP server name
-
- This option is used to identify a TFTP server when the 'sname' field
- in the DHCP header has been used for DHCP options.
-
- The code for this option is 66, and its minimum length is 1.
-
- Code Len TFTP server
- +-----+-----+-----+-----+-----+---
- | 66 | n | c1 | c2 | c3 | ...
- +-----+-----+-----+-----+-----+---
-
-
-
-
-
-Alexander & Droms Standards Track [Page 26]
-\f
-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
-
-
-9.5 Bootfile name
-
- This option is used to identify a bootfile when the 'file' field in
- the DHCP header has been used for DHCP options.
-
- The code for this option is 67, and its minimum length is 1.
-
- Code Len Bootfile name
- +-----+-----+-----+-----+-----+---
- | 67 | n | c1 | c2 | c3 | ...
- +-----+-----+-----+-----+-----+---
-
-9.6. DHCP Message Type
-
- This option is used to convey the type of the DHCP message. The code
- for this option is 53, and its length is 1. Legal values for this
- option are:
-
- Value Message Type
- ----- ------------
- 1 DHCPDISCOVER
- 2 DHCPOFFER
- 3 DHCPREQUEST
- 4 DHCPDECLINE
- 5 DHCPACK
- 6 DHCPNAK
- 7 DHCPRELEASE
- 8 DHCPINFORM
-
- Code Len Type
- +-----+-----+-----+
- | 53 | 1 | 1-9 |
- +-----+-----+-----+
-
-9.7. Server Identifier
-
- This option is used in DHCPOFFER and DHCPREQUEST messages, and may
- optionally be included in the DHCPACK and DHCPNAK messages. DHCP
- servers include this option in the DHCPOFFER in order to allow the
- client to distinguish between lease offers. DHCP clients use the
- contents of the 'server identifier' field as the destination address
- for any DHCP messages unicast to the DHCP server. DHCP clients also
- indicate which of several lease offers is being accepted by including
- this option in a DHCPREQUEST message.
-
- The identifier is the IP address of the selected server.
-
- The code for this option is 54, and its length is 4.
-
-
-
-Alexander & Droms Standards Track [Page 27]
-\f
-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
-
-
- Code Len Address
- +-----+-----+-----+-----+-----+-----+
- | 54 | 4 | a1 | a2 | a3 | a4 |
- +-----+-----+-----+-----+-----+-----+
-
-9.8. Parameter Request List
-
- This option is used by a DHCP client to request values for specified
- configuration parameters. The list of requested parameters is
- specified as n octets, where each octet is a valid DHCP option code
- as defined in this document.
-
- The client MAY list the options in order of preference. The DHCP
- server is not required to return the options in the requested order,
- but MUST try to insert the requested options in the order requested
- by the client.
-
- The code for this option is 55. Its minimum length is 1.
-
- Code Len Option Codes
- +-----+-----+-----+-----+---
- | 55 | n | c1 | c2 | ...
- +-----+-----+-----+-----+---
-
-9.9. Message
-
- This option is used by a DHCP server to provide an error message to a
- DHCP client in a DHCPNAK message in the event of a failure. A client
- may use this option in a DHCPDECLINE message to indicate the why the
- client declined the offered parameters. The message consists of n
- octets of NVT ASCII text, which the client may display on an
- available output device.
-
- The code for this option is 56 and its minimum length is 1.
-
- Code Len Text
- +-----+-----+-----+-----+---
- | 56 | n | c1 | c2 | ...
- +-----+-----+-----+-----+---
-
-9.10. Maximum DHCP Message Size
-
- This option specifies the maximum length DHCP message that it is
- willing to accept. The length is specified as an unsigned 16-bit
- integer. A client may use the maximum DHCP message size option in
- DHCPDISCOVER or DHCPREQUEST messages, but should not use the option
- in DHCPDECLINE messages.
-
-
-
-
-Alexander & Droms Standards Track [Page 28]
-\f
-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
-
-
- The code for this option is 57, and its length is 2. The minimum
- legal value is 576 octets.
-
- Code Len Length
- +-----+-----+-----+-----+
- | 57 | 2 | l1 | l2 |
- +-----+-----+-----+-----+
-
-9.11. Renewal (T1) Time Value
-
- This option specifies the time interval from address assignment until
- the client transitions to the RENEWING state.
-
- The value is in units of seconds, and is specified as a 32-bit
- unsigned integer.
-
- The code for this option is 58, and its length is 4.
-
- Code Len T1 Interval
- +-----+-----+-----+-----+-----+-----+
- | 58 | 4 | t1 | t2 | t3 | t4 |
- +-----+-----+-----+-----+-----+-----+
-
-9.12. Rebinding (T2) Time Value
-
- This option specifies the time interval from address assignment until
- the client transitions to the REBINDING state.
-
- The value is in units of seconds, and is specified as a 32-bit
- unsigned integer.
-
- The code for this option is 59, and its length is 4.
-
- Code Len T2 Interval
- +-----+-----+-----+-----+-----+-----+
- | 59 | 4 | t1 | t2 | t3 | t4 |
- +-----+-----+-----+-----+-----+-----+
-
-9.13. Vendor class identifier
-
- This option is used by DHCP clients to optionally identify the vendor
- type and configuration of a DHCP client. The information is a string
- of n octets, interpreted by servers. Vendors may choose to define
- specific vendor class identifiers to convey particular configuration
- or other identification information about a client. For example, the
- identifier may encode the client's hardware configuration. Servers
- not equipped to interpret the class-specific information sent by a
- client MUST ignore it (although it may be reported). Servers that
-
-
-
-Alexander & Droms Standards Track [Page 29]
-\f
-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
-
-
- respond SHOULD only use option 43 to return the vendor-specific
- information to the client.
-
- The code for this option is 60, and its minimum length is 1.
-
- Code Len Vendor class Identifier
- +-----+-----+-----+-----+---
- | 60 | n | i1 | i2 | ...
- +-----+-----+-----+-----+---
-
-9.14. Client-identifier
-
- This option is used by DHCP clients to specify their unique
- identifier. DHCP servers use this value to index their database of
- address bindings. This value is expected to be unique for all
- clients in an administrative domain.
-
- Identifiers SHOULD be treated as opaque objects by DHCP servers.
-
- The client identifier MAY consist of type-value pairs similar to the
- 'htype'/'chaddr' fields defined in [3]. For instance, it MAY consist
- of a hardware type and hardware address. In this case the type field
- SHOULD be one of the ARP hardware types defined in STD2 [22]. A
- hardware type of 0 (zero) should be used when the value field
- contains an identifier other than a hardware address (e.g. a fully
- qualified domain name).
-
- For correct identification of clients, each client's client-
- identifier MUST be unique among the client-identifiers used on the
- subnet to which the client is attached. Vendors and system
- administrators are responsible for choosing client-identifiers that
- meet this requirement for uniqueness.
-
- The code for this option is 61, and its minimum length is 2.
-
- Code Len Type Client-Identifier
- +-----+-----+-----+-----+-----+---
- | 61 | n | t1 | i1 | i2 | ...
- +-----+-----+-----+-----+-----+---
-
-
-
-
-
-
-
-
-
-
-
-
-Alexander & Droms Standards Track [Page 30]
-\f
-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
-
-
-10. Defining new extensions
-
- The author of a new DHCP option will follow these steps to obtain
- acceptance of the option as a part of the DHCP Internet Standard:
-
- 1. The author devises the new option.
- 2. The author requests a number for the new option from IANA by
- contacting:
- Internet Assigned Numbers Authority (IANA)
- USC/Information Sciences Institute
- 4676 Admiralty Way
- Marina del Rey, California 90292-6695
-
- or by email as: iana@iana.org
-
- 3. The author documents the new option, using the newly obtained
- option number, as an Internet Draft.
- 4. The author submits the Internet Draft for review through the IETF
- standards process as defined in "Internet Official Protocol
- Standards" (STD 1). The new option will be submitted for eventual
- acceptance as an Internet Standard.
- 5. The new option progresses through the IETF standards process; the
- new option will be reviewed by the Dynamic Host Configuration
- Working Group (if that group still exists), or as an Internet
- Draft not submitted by an IETF working group.
- 6. If the new option fails to gain acceptance as an Internet
- Standard, the assigned option number will be returned to IANA for
- reassignment.
-
- This procedure for defining new extensions will ensure that:
-
- * allocation of new option numbers is coordinated from a single
- authority,
- * new options are reviewed for technical correctness and
- appropriateness, and
- * documentation for new options is complete and published.
-
-11. Acknowledgements
-
- The author thanks the many (and too numerous to mention!) members of
- the DHC WG for their tireless and ongoing efforts in the development
- of DHCP and this document.
-
- The efforts of J Allard, Mike Carney, Dave Lapp, Fred Lien and John
- Mendonca in organizing DHCP interoperability testing sessions are
- gratefully acknowledged.
-
-
-
-
-
-Alexander & Droms Standards Track [Page 31]
-\f
-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
-
-
- The development of this document was supported in part by grants from
- the Corporation for National Research Initiatives (CNRI), Bucknell
- University and Sun Microsystems.
-
-12. References
-
- [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
- Bucknell University, March 1997.
-
- [2] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 1497,
- USC/Information Sciences Institute, August 1993.
-
- [3] Croft, W., and J. Gilmore, "Bootstrap Protocol", RFC 951,
- Stanford University and Sun Microsystems, September 1985.
-
- [4] Braden, R., Editor, "Requirements for Internet Hosts -
- Communication Layers", STD 3, RFC 1122, USC/Information Sciences
- Institute, October 1989.
-
- [5] Mogul, J., and J. Postel, "Internet Standard Subnetting
- Procedure", STD 5, RFC 950, USC/Information Sciences Institute,
- August 1985.
-
- [6] Postel, J., and K. Harrenstien, "Time Protocol", STD 26, RFC
- 868, USC/Information Sciences Institute, SRI, May 1983.
-
- [7] Postel, J., "Name Server", IEN 116, USC/Information Sciences
- Institute, August 1979.
-
- [8] Mockapetris, P., "Domain Names - Implementation and
- Specification", STD 13, RFC 1035, USC/Information Sciences
- Institute, November 1987.
-
- [9] Postel, J., "Quote of the Day Protocol", STD 23, RFC 865,
- USC/Information Sciences Institute, May 1983.
-
- [10] McLaughlin, L., "Line Printer Daemon Protocol", RFC 1179, The
- Wollongong Group, August 1990.
-
- [11] Accetta, M., "Resource Location Protocol", RFC 887, CMU,
- December 1983.
-
- [12] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191,
- DECWRL, Stanford University, November 1990.
-
- [13] Deering, S., "ICMP Router Discovery Messages", RFC 1256,
- Xerox PARC, September 1991.
-
-
-
-
-Alexander & Droms Standards Track [Page 32]
-\f
-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
-
-
- [14] Leffler, S. and M. Karels, "Trailer Encapsulations", RFC 893,
- U. C. Berkeley, April 1984.
-
- [15] Hornig, C., "Standard for the Transmission of IP Datagrams over
- Ethernet Networks", RFC 894, Symbolics, April 1984.
-
- [16] Postel, J. and J. Reynolds, "Standard for the Transmission of
- IP Datagrams Over IEEE 802 Networks", RFC 1042, USC/Information
- Sciences Institute, February 1988.
-
- [17] Sun Microsystems, "System and Network Administration", March
- 1990.
-
- [18] Mills, D., "Internet Time Synchronization: The Network Time
- Protocol", RFC 1305, UDEL, March 1992.
-
- [19] NetBIOS Working Group, "Protocol Standard for a NetBIOS Service
- on a TCP/UDP transport: Concepts and Methods", STD 19, RFC 1001,
- March 1987.
-
- [20] NetBIOS Working Group, "Protocol Standard for a NetBIOS Service
- on a TCP/UDP transport: Detailed Specifications", STD 19, RFC
- 1002, March 1987.
-
- [21] Scheifler, R., "FYI On the X Window System", FYI 6, RFC 1198,
- MIT Laboratory for Computer Science, January 1991.
-
- [22] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
- USC/Information Sciences Institute, July 1992.
-
-13. Security Considerations
-
- Security issues are not discussed in this memo.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Alexander & Droms Standards Track [Page 33]
-\f
-RFC 2132 DHCP Options and BOOTP Vendor Extensions March 1997
-
-
-14. Authors' Addresses
-
- Steve Alexander
- Silicon Graphics, Inc.
- 2011 N. Shoreline Boulevard
- Mailstop 510
- Mountain View, CA 94043-1389
-
- Phone: (415) 933-6172
- EMail: sca@engr.sgi.com
-
-
- Ralph Droms
- Bucknell University
- Lewisburg, PA 17837
-
- Phone: (717) 524-1145
- EMail: droms@bucknell.edu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Alexander & Droms Standards Track [Page 34]
-\f
projects / platform / upstream / connman.git / commitdiff