diff options
| author | Marcel Holtmann <marcel@holtmann.org> | 2012-09-19 14:31:52 +0200 |
|---|---|---|
| committer | Marcel Holtmann <marcel@holtmann.org> | 2012-09-19 14:31:52 +0200 |
| commit | f53c0b996d359405d645ec67801c6ceb0143c2fa (patch) | |
| tree | 256e0c1fd201d4e4813900da546b46cd03019248 /doc | |
| parent | 250dcb84a157e3a186634238cd40d04f206d97af (diff) | |
| download | connman-f53c0b996d359405d645ec67801c6ceb0143c2fa.tar.gz connman-f53c0b996d359405d645ec67801c6ceb0143c2fa.tar.bz2 connman-f53c0b996d359405d645ec67801c6ceb0143c2fa.zip | |
doc: Remove copies of DNS and DHCP specifications
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/rfc1035.txt | 3077 | ||||
| -rw-r--r-- | doc/rfc2131.txt | 2523 | ||||
| -rw-r--r-- | doc/rfc2132.txt | 1907 |
3 files changed, 0 insertions, 7507 deletions
diff --git a/doc/rfc1035.txt b/doc/rfc1035.txt deleted file mode 100644 index b1a9bf5a..00000000 --- a/doc/rfc1035.txt +++ /dev/null @@ -1,3077 +0,0 @@ -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - diff --git a/doc/rfc2131.txt b/doc/rfc2131.txt deleted file mode 100644 index f45d9b86..00000000 --- a/doc/rfc2131.txt +++ /dev/null @@ -1,2523 +0,0 @@ - - - - - - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - diff --git a/doc/rfc2132.txt b/doc/rfc2132.txt deleted file mode 100644 index e9c4f4b3..00000000 --- a/doc/rfc2132.txt +++ /dev/null @@ -1,1907 +0,0 @@ - - - - - - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - -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] - |